UML關係總結——畫uml圖、流程圖、軟件結構圖、類圖、順序圖的方法

UML關係總結

[轉載]

在UML類圖中，常見的有如下幾種關係:泛化（Generalization）,  實現（Realization）,關聯（Association）,聚合（Aggregation）,組合(Composition)，依賴(Dependency)

 

1.泛化(Generalization)

【泛化關係】：是一種繼承關係,它指定了子類如何特化父類的全部特徵和行爲例如：老虎是動物的一種.

【箭頭指向】：帶三角箭頭的實線，箭頭指向父類

2.實現（Realization)

【實現關係】：是一種類與接口的關係，表示類是接口全部特徵和行爲的實現

【箭頭指向】：帶三角箭頭的虛線，箭頭指向接口

3.關聯（Association）

【關聯關係】：是一種擁有的關係,它使一個類知道另外一個類的屬性和方法；如：老師與學生，丈夫與妻子

關聯能夠是雙向的，也能夠是單向的。雙向的關聯能夠有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。

【代碼體現】：成員變量

【箭頭及指向】：帶普通箭頭的實心線，指向被擁有者

 

上圖中，老師與學生是雙向關聯，老師有多名學生，學生也可能有多名老師。但學生與某課程間的關係爲單向關聯，一名學生可能要上多門課程，課程是個抽象的東西他不擁有學生。

 

上圖爲自身關聯：

 

4. 聚合（Aggregation）

【聚合關係】：是總體與部分的關係.如車和輪胎是總體和部分的關係.

聚合關係是關聯關係的一種，是強的關聯關係；關聯和聚合在語法上沒法區分，必須考察具體的邏輯關係。

【代碼體現】：成員變量

【箭頭及指向】：帶空心菱形的實心線，菱形指向總體

 

 

5. 組合(Composition)

【組合關係】：是總體與部分的關係.,沒有公司就不存在部門      組合關係是關聯關係的一種，是比聚合關係還要強的關係，它要求普通的聚合關係中表明總體的對象負責表明部分的對象的生命週期

【代碼體現】：成員變量

【箭頭及指向】：帶實心菱形的實線，菱形指向總體

 

 

6. 依賴(Dependency)

【依賴關係】：是一種使用的關係,因此要儘可能不使用雙向的互相依賴。

【代碼表現】：局部變量、方法的參數或者對靜態方法的調用

【箭頭及指向】：帶箭頭的虛線，指向被使用者

 

各類關係的強弱順序：

泛化= 實現> 組合> 聚合> 關聯> 依賴

下面這張UML圖，比較形象地展現了各類類圖關係：

 

畫uml圖、流程圖、軟件結構圖、類圖、順序圖的方法

[轉載]

軟件開發中，分析和設計時，文檔的編寫和思想的交流，常常要繪製各類各樣的圖。相對於人類的天然語言，描繪複雜結構，圖具備直觀和總體的特徵，有着不可替代的表現力。

軟件開發是創造性的勞動，開發人員幾乎在每一分鐘都要作出某些選擇，每個選擇都好像決定着最後的結果。繪圖的時候也是如此，腦中有完整或不完整的想法，要清晰的表現出來時至關不容易。事實上，我發現許多老手不會畫圖。

在實踐的過程當中，我總結了一些經驗，得出了一些結論。

1. 不畫沒有必要的圖。若是簡單的文字就能說得很清楚，還畫圖幹什麼？對代碼級別的細節，不要畫圖來表現；不要藉助圖來讓你的文檔得變大；畫蛇莫要添足。

2. 忽略底層的細節。軟件是一個多層的東西，一個圖只展示恰當抽象層次之上的細節。一個過細的圖，大量的信息會掩蓋真正重要的東西。好比：在一個流程圖上，不須要把「文件打開的錯誤判斷」也做爲一個分支畫在圖上，除非你「無聊到」要強調這個顯而易見的異常處理；
  
3. 圖不要太大。若是一個圖上包含上百個對象，看起來不舒服，應該化整爲零，使用多個圖，每一個圖描述不一樣的部分。
  
4. 畫純種的圖。圖傳遞的信息應該明確，無歧義。必定要明確圖中的各個組成元素都是什麼東西，整個圖要表現什麼。儘可能使用規範的圖。好比：流程圖中，應關注控制的傳遞，不要有從文件中讀取數據的數據流；軟件結構圖中，描述模塊之間的父子關係的同時，不要有模塊之間的數據流。我常見到這樣的圖：在圖中既有「控制流」，也有「數據流」，不三不四，名之曰「示意圖」。我的認爲，交流時，這種示意圖在白板上隨手畫畫還能夠，決不該該出如今正式的文檔上。這些圖中的控制流，實是一個模糊概念，A->B能夠表示：1)A調用B，把控制傳遞給B；2）A啓動B,把控制傳遞給B；3）A向B傳遞一個控制信號；4)有一個第三者調用A完成後，立刻調用B。

5. 圖的佈局要簡潔，美觀。我據說：書寫大幅的毛筆字，特別講究佈局。一樣道理，畫軟件圖，儘可能密度分佈均勻，減小連線的交叉。 爲了減小連線的交叉， 一樣的單元能夠在圖中出現屢次。

6. 其實並不須要完備的圖。使用UML有三種方式：UML as sketch(草圖)，使用不完備的圖進行系統某一部分或某一方面的內容進行交流；UML as blueprint（籃圖），經過完備的UML圖表現詳細設計的全部決定；UML as programming language，自動精確的UML圖，直接編譯成可執行的代碼（如今好像尚未實現）。Martin Fowler說：使用UML繪製草圖的人，真正關注UML的精髓（大師就是大師，說話就是不同）。所謂「不足勝有餘」，無論什麼圖，圖應該集中表現其關注的方面，恰當的忽略一些細節時必要的。類圖中，每每沒有必要包含類的全部函數合成員說明；在表現對象之間協做的順序圖中，大多時候也沒有必要表現存在的分支和循環。
  
7. 全部的規則都是用來遵照和打破的。上面的全部道理，也並不是是不變的真理。可是，道理被打破之前，你應該瞭解它，熟悉它，批評它，忘記它（追求相似張三丰太極劍的境界）。古人云：事有反道而適權，僞經而和道者。笑傲江湖說：獨孤九劍，無招勝有招。蕭大俠：刪繁就簡，取精用宏。 規勸朋友也規勸本身：連有招的境界還沒有達到，應該知道本身該作什麼。

參考文章：

UML關係總結:

https://blog.csdn.net/woailuo453786790/article/details/51647011

畫uml圖、流程圖、軟件結構圖、類圖、順序圖的方法:

https://blog.csdn.net/claram/article/details/3026152