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