UML學習筆記——細化階段迭代二三

Elaboration細化迭代二

chapter26 GoF設計模式

一、適配器（GoF）

二、Factory工廠模式

問題： 有特殊考慮（例如存在複雜建立邏輯、爲了改良內聚而 分 離建立職責等）時，應該由誰來負責建立對象？

建立稱爲工廠的純虛構對象來處理這些建立職責

一般用單實例類來訪問工廠模式

三、Singleton單實例類

問題： 對象須要全局可見性和單點訪問（訪問的都是同一個對象）

對類定義靜態方法以返回單實例

例如工廠類中定義一個靜態方法，返回本身的惟一實例，那麼其餘類能夠方便地經過調用這個方法得到工廠對象的引用

通常使用緩式初始化即調用獲取某個對象的方法時才建立這個對象，而預初始化是在調用前就已經建立了這個對象（靜態成員），預先建立可能會佔用資源，而且有的對象的建立邏輯複雜

四、Strategy策略

問題： 何設計變化但相關的算法或政策？如何設計才能使這些算法或政策具備可變動的能力？

在單獨的類中分別定義每種算法/策略，並使其擁有共同的接口

策略是基於多態的，對變化的算法/政策提供了防止變異，一般由工廠建立

五、Composite組合

問題： 何可以像處理非組合（原子）對象同樣，處理一組對象 或 具備組合結構的對象呢？

定義組合和原子對象的類，使他們實現共同的接口

基於多態提供防止變異

六、Facade外觀

問題： 對一組徹底不一樣的實現或接口，須要公共、統一的接口。可能會與子系統內部的大量事物產生耦合，或者子系統的實現可能會改變。

對於子系統定義的惟一接觸點——使用外觀對象封裝子系統。該外觀對象提供惟一和統一的接口，並負責與子系統構件進行協助。

外觀是「前端」對象，是子系統服務的惟一入口；子系統的實現和其餘構件是私有的，並不對外部構件可見。外觀對子系統實現的變化提供防止變異。

書上講的不清不楚的，但我感受這個其實像api

七、Observer觀察者

問題： 同類型的訂閱者對象關注於發佈者對象的狀態變化或事件，而且想要在發佈者產生事件時以本身獨特的方式做出反應。此外，發佈者想要保持與訂閱者的低耦合。如何對此進行設計呢？

定義「訂閱者」或「監聽器」接口，訂閱者實現此接口。發佈者能夠動態註冊關注某事件的訂閱者，並在事件發生時通知他們。

View對象和Model對象都有可能變化，但它們不直接耦合，只要接口不變彼此的改變就不容易影響到對方；其實像MVVM的思想，視圖UI與業務邏輯分開，只有數據綁定在一塊兒，極大下降了耦合性

---

Elaboration細化迭代三

chapter28 活動圖

chapter29狀態機圖

上面都看書，很簡單

---

chapter30 用例關聯

一、include包含關係

當兩個或多個獨立用例中存在重複，想避免冗餘時，能夠將重複的部分分解出去爲一個子功能用例（或者不想原用例過於複雜分解一部分出去），使用包含關係包含重複的部分

二、extend拓展關係

拓展部分過於複雜或者原始用例的拓展部分不便於添加，能夠將要拓展的內容做爲子功能級別的拓展用例

---

chapter31 領域模型的精化

一、Generalization泛化關係

概念子類集合的全部成員都是其超類集合的成員，子類 is-a 超類 （ 注意不是類，是領域模型裏面的概念類 ）

子類的屬性和關聯必須100%與超類一致

二、abstract conceptual class 抽象概念類

若是類C的每一個成員也必須是子類的成員，則C被稱爲抽象概念類(有點像抽象類的實例只能是其非抽象的子類同樣，也就是說這個類不能實例化)

三、association class 關聯類

四、關聯受限

五、reflexive association 自反關聯

後面的章節都是一些拓展和實戰，不太算重點我也沒什麼筆記就不放了

參考文獻 (美)Carig Larman著. UML模式和應用(原書第三版)[M]. 李洋等譯. 機械工業出版社, 2006-05 單純是我的的學習/複習筆記，對課本知識點的總結概括，本身也是用markdown作的筆記就順手發上來