本單元採用了圖模型解析uml。
uml檔案可以抽象為圖、子圖、邊的邏輯結構。
在實現中，圖的節點包括類、介面、屬性，子圖包括狀態圖、順序圖等。
採用了三次遍歷uml元素的方法建圖，第一遍遍歷建點，第
二、三次遍歷設定屬性、連邊，實現圖物件的初始化。這裡借鑑了一些python程式設計的思路，通過迭代器、選擇器快速完成資料處理，實現起來**編寫效率比較高。
類、介面節點繼承自可繼承節點抽象類，實現了對繼承的判斷。
總流程為：
umlinteraction互動 - parser建圖 - graph節點儲存資訊 & 定義查詢方法 - umlinteraction互動第三次第四次架構較為簡單，這裡主要借助jml規則、uml圖的知識，對前兩次作業的架構進行回顧。
物件導向的第一步就應當是提取出物件概念，並找出繼承、關聯關係，進行封裝。
在表示式求導作業中，物件概念的提取的原則是規則。對於初等函式，需要實現的求導規則為：
通過這些法則理論上生成任何初等函式的導數。即在初等函式範圍內，求導規則具有完備性。
基於這種思想，結合表示式樹模型完成了物件概念的提取。每乙個表示式樹上的節點作為乙個item物件存在，同時代表乙個基礎的求導規則體。
對於化簡，實現的部分規則為：
考慮到化簡規則和求導規則的對應關係不清晰，因此單獨建立了化簡介面，在表示式樹上通過遞迴訪問介面方法實現化簡。這種架構的不足之處在於，每乙個化簡規則被分散在了多種表示式樹節點上，不利於維護，而表示式樹節點的分類是根據求導規則進行的。
一種改進方法是對節點物件新增運算規則，化簡法則通過對運算規則的操作間接完成化簡。
另外節點之間化簡搜尋空間非常大，可能還需要一些隨機化方法完成化簡，還應新增一些隨機化的化簡規則。
對於第二單元作業，電梯排程的物件概念提取的原則為狀態。借助uml圖的知識我們可以看到，併發程式可以由時序圖描述，而時序圖中每乙個物件可以被視為乙個狀態機。狀態機之間通過訊息的傳遞完成併發任務。
因此，應當抽取了需要維護狀態的概念作為物件。同時每個物件的狀態數目不宜過多，且內部聯絡緊密，外部聯絡疏鬆。這裡抽取的三個狀態為策略快取、排程板、電梯狀態。
同時，mainclass中的讀取執行緒、executor執行緒作為訊息的發出者，負責保持物件間的協作執行。
graph lr
mainclass--requests-->schedule
mainclass--create-->elevators
schedule--check-->elevators
executor--operate-->elevators
executor--notify-->schedule
schedule--update-->executor
schedule--adapt-->method
第三次作業直接實現了提供的介面。社交網路使用的是圖論模型，這裡使用了點、點集合作為物件。
第四次作業uml檔案解析，同樣採用的是圖模型。而這裡使用的是查詢的內容的邏輯結構為物件。包括類、介面、屬性、狀態圖、順序圖等。
第一單元表示式求導課程中，第一次討論了物件建立模式的問題。
這一單元主要的程式設計為:
表示式讀取 --> 表示式元素物件 --> 呼叫元素求導方法 --> 呼叫元素輸出方法不過在一開始表示式讀取模組中，使用了狀態機模型，但實現的較為複雜，難以維護。在第二次、第三次作業中，參考了工廠設計模式。乙個重要的改進就是強化了狀態機模型和表示式元素物件之間的耦合關係。對於每一類表示式元素，採取獨立的解析器，各個解析器分層解析。每乙個解析器類似於乙個工廠。
這種方式的優勢在於，較好地將需求中的歸納定義和表示式元素物件的結構對映在了設計架構中。乙個還應當改進的方面是迴圈依賴問題，可以通過抽象出統一的解析器介面，再對解析器物件進行組裝來解決。類似於抽象工廠模式。
在第二單元作業中，採用了這種在再組裝的策略。分別為執行器模組、排程器模組、策略模組、電梯模組。各個模組在mainclass完成對接，模組之間的實現細節對其他模組不可見。這樣就避免了模組組裝時產生的迴圈依賴問題，可以理解為所有模組都依賴於規則集合，而組裝的過程又依賴於全部規則集合、模組實現集合。
抽象工廠模式/再組裝的優勢在於，採用了「模組化」的生產理念，各個部門在同一的規則下行事，部門與規則之間的聯絡強於部門之間的聯絡，避免出現部門之間的迴圈依賴，或者說互相扯皮、推卸責任、「拋皮球」情況的發生。
先進的社會是法治的。
而在第四次作業中，採用了三次遍歷uml元素的方法建圖，第一遍遍歷建點，第
二、三次遍歷設定屬性、連邊，實現圖物件的初始化。這裡借鑑了一些python程式設計的思路，通過迭代器、選擇器快速完成資料處理，實現起來**編寫效率比較高。
其實無論哪種物件構建模式，都應遵循貼近實際、簡潔易維護的原則。貼近物件資料結構，問題的邏輯結構，不要刻意迎合某個設計模式。不管黑貓白貓，能捉老鼠的就是好貓。
物件導向的方法是對事物刻畫的一種方式。
從巨集觀層面上來看，世界的構造具有同構性。例如，地球繞太陽運動，而月球又繞地球運動。從科學的角度來看，這背後具有相似的物理原理和數學規則，可以通過數學方法進行抽象。
物件導向將這種規則化轉化到了程式中，自然而然地誕生了抽象、分層、復用的特性。
科學的乙個重要方法是「奧卡姆剃刀原理」。即「如無必要,勿增實體」。物件導向作為規則的描述體，也具有 「封裝，繼承，多型」的類似特點。「封裝」對外部訪問的限制，「繼承」即對重複規則的限制，「多型」即對介面資訊量的限制，同名介面可以處理更多資訊。
物件導向也是工程學的協作方法。從工程化的角度而言，標準化是必不可少的部分。標準化意味著對產品、模組的行為有確切的約束，我們只需要知道標準就可以進行協作，而無需知道對方的生產過程。
因此乙個高效的程式應滿足模組化、高耦合、低內聚的特點。
乙個成功的物件導向的系統應是完備、簡潔、高效的。
BUAA OO第四單元反思與總結
18375182 范競元 第十三次作業主要實現了11個針對類圖的查詢指令。首先，在做這次作業之前，我並沒有對mdj檔案有著很深的了解，因此思考這次作業如何開始花費了我比以前更長的時間 甚至有段時間以為這單元要寫的和jml相似 希望老師上課能夠更加詳細地講一下mdj檔案的結構以及類圖，順序圖和狀態圖中...
OO第四單元與全課程總結
具體架構設計 作業bug分析 由於上面這個類圖實在過於複雜，所以提供了以下簡化類圖 具體架構設計 在具體方法的架構設計方面 本次作業依然通過構造方法中的迴圈遍歷獲取uml圖中已經給出的資訊，並在重新整合後，形成便於查詢的資訊結構 最終儲存到相應的新定義的類中 在查詢方法中，通過呼叫儲存所需資訊的新定...
oo第四單元總結及總課程回顧
第一次作業要求實現的只有對類圖的分析。為了直觀地搭建出乙個類圖，我新建了manager類來處理umlelement以及搭建樹。但由於未能做好時間管理，因此第一次作業未能通過中測。在聽過一些同學分享的第一次作業的思路與架構的討論課後，我直接進行了重構，全部採用hashmap以及hashset的方式儲存...