BUAAOO 第四單元 & 課程總結

1. 第四單元：StarUml文件解析

本單元採用了圖模型解析UML。

UML文件能夠抽象爲圖、子圖、邊的邏輯結構。

在實現中，圖的節點包括類、接口、屬性，子圖包括狀態圖、順序圖等。

採用了三次遍歷UML元素的方法建圖，第一遍遍歷建點，第2、三次遍歷設置屬性、連邊，實現圖對象的初始化。這裏借鑑了一些python程序設計的思路，經過迭代器、選擇器快速完成數據處理，實現起來代碼編寫效率比較高。

類、接口節點繼承自可繼承節點抽象類，實現了對繼承的判斷。

總流程爲：

umlInteraction交互 - parser建圖 - graph節點存儲信息 & 定義查詢方法 - umlInteraction交互

2. 架構設計總結

第三次第四次架構較爲簡單，這裏主要藉助JML規則、UML圖的知識，對前兩次做業的架構進行回顧。

2.1 對象概念的提取

面向對象的第一步就應當是提取出對象概念，並找出繼承、關聯關係，進行封裝。

在表達式求導做業中，對象概念的提取的原則是規則。對於初等函數，須要實現的求導規則爲：

• 線性法則

• 乘除法則（萊布尼茨公式）

• 鏈式法則

• 特殊函數求導（冪函數、三角函數、對數函數、指數函數、....）

經過這些法則理論上生成任何初等函數的導數。即在初等函數範圍內，求導規則具備完備性。

基於這種思想，結合表達式樹模型完成了對象概念的提取。每個表達式樹上的節點做爲一個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文件解析，一樣採用的是圖模型。而這裏使用的是查詢的內容的邏輯結構爲對象。包括類、接口、屬性、狀態圖、順序圖等。

2.2 對象建立模式

第一單元表達式求導課程中，第一次討論了對象建立模式的問題。

這一單元主要的程序設計爲:

表達式讀取 --> 表達式元素對象 --> 調用元素求導方法 --> 調用元素輸出方法

不過在一開始表達式讀取模塊中，使用了狀態機模型，但實現的較爲複雜，難以維護。在第二次、第三次做業中，參考了工廠設計模式。一個重要的改進就是強化了狀態機模型和表達式元素對象之間的耦合關係。對於每一類表達式元素，採起獨立的解析器，各個解析器分層解析。每個解析器相似於一個工廠。

這種方式的優點在於，較好地將需求中的概括定義和表達式元素對象的結構映射在了設計架構中。一個還應當改進的方面是循環依賴問題，能夠經過抽象出統一的解析器接口，再對解析器對象進行組裝來解決。相似於抽象工廠模式。

---

在第二單元做業中，採用了這種在再組裝的策略。分別爲執行器模塊、調度器模塊、策略模塊、電梯模塊。各個模塊在MainClass完成對接，模塊之間的實現細節對其餘模塊不可見。這樣就避免了模塊組裝時產生的循環依賴問題，能夠理解爲全部模塊都依賴於規則集合，而組裝的過程又依賴於所有規則集合、模塊實現集合。

抽象工廠模式/再組裝的優點在於，採用了「模塊化」的生產理念，各個部門在同一的規則下行事，部門與規則之間的聯繫強於部門之間的聯繫，避免出現部門之間的循環依賴，或者說互相扯皮、推卸責任、「拋皮球」狀況的發生。

先進的社會是法治的。

---

而在第四次做業中，採用了三次遍歷UML元素的方法建圖，第一遍遍歷建點，第2、三次遍歷設置屬性、連邊，實現圖對象的初始化。這裏借鑑了一些python程序設計的思路，經過迭代器、選擇器快速完成數據處理，實現起來代碼編寫效率比較高。

其實不管哪一種對象構建模式，都應遵循貼近實際、簡潔易維護的原則。貼近對象數據結構，問題的邏輯結構，不要刻意迎合某個設計模式。無論黑貓白貓，能捉老鼠的就是好貓。

3. 對面向對象方法的理解

面向對象的方法是對事物刻畫的一種方式。

從宏觀層面上來看，世界的構造具備同構性。例如，地球繞太陽運動，而月球又繞地球運動。從科學的角度來看，這背後具備類似的物理原理和數學規則，能夠經過數學方法進行抽象。

面向對象將這種規則化轉化到了程序中，天然而然地誕生了抽象、分層、複用的特性。

科學的一個重要方法是「奧卡姆剃刀原理」。即「如無必要,勿增實體」。面向對象做爲規則的描述體，也具備 「封裝，繼承，多態」的相似特色。「封裝」對外部訪問的限制，「繼承」即對重複規則的限制，「多態」即對接口信息量的限制，同名接口能夠處理更多信息。

面向對象也是工程學的協做方法。從工程化的角度而言，標準化是必不可少的部分。標準化意味着對產品、模塊的行爲有確切的約束，咱們只須要知道標準就能夠進行協做，而無需知道對方的生產過程。

所以一個高效的程序應知足模塊化、高耦合、低內聚的特色。

一個成功的面向對象的系統應是完備、簡潔、高效的。

4. 課程收穫

• 思考、實踐、總結了面向對象程序設計的方法論
• 學習了併發程序的設計方法
• 學習了JML語言和UML建模方法
• 實踐了Python、Junit測試方法
• 簡單實踐了一些優化方法

5. 課程建議

• 但願能夠改進教學的順序，JML、UML兩個單元能夠先講，由於這兩個單元偏向理論，而另外兩個單元偏向應用，且更爲綜合。
• 但願JML、UML單元能夠佈置一些開放性的做業。
• 但願之後在線課程老師能夠出鏡，而且將視頻按知識點分塊。一些MOOC是這樣的，感受效果會明顯更好些。