UML類關系個人總結

UML類關系個人總結

2.泛化和實現很好區分，不必細說，區分關聯和依賴關系的方法：關聯在語義上有表現類實例之間的對應關系，所以有重數的概念(一對一，一對多等)，依賴在語義上強調類與類的關系，沒有重數的概念。

3.雖然在語義上，組合是聚合的一種特殊形式，稱為組合聚合(Composite Aggregation)，強調組合者管理被組合者的全部生命周期，圖上卻把它們畫成同級。因為，習慣上把沒有特殊說明的聚合看成是共享聚合(Shared Aggregation)，應使用空心菱形與組合聚合(Composite Aggregation)進行區分。這樣分類，要強調在設計階段要嚴格區分一個聚合是共享聚合還是組合聚合，選擇不同符合。

4.多元關聯在UML圖中并不常見，認為程序員習慣上把一個多元關聯處理成多個二元關聯，這似乎是人類大腦處理復雜關系的本能方式，大家很自然的就會這樣做。

5.創建與實例化的語義很相似，許多資料沒有講清它們的區別。我認為，實例化專用于工廠類的，強調一個類的某個方法創建并返回了另一個類的實例，也就是說有工廠類中有一個方法，其行為的定義就是實例化對象。而創建關系有所不同，創建者的一個方法創建了另一個類的實例但不返回，此方法要完成其他行為需要創建這個實例而已。

6.細化關系出現在同一個概念的不同版本之間，同一個概念在不同的設計階段可能出現不同版本，后出現的的版本是先前版本的細化，一般用不到。因為我認為一個概念的不同版本不應該出現在同一個UML圖中，對同一個圖，一般只表現當前設計階段下的模型，沒必要包含歷史不同版本。

7.跟蹤關系也是表現的不同模型中的相似概念，但不要求精確的對應關系。我總結有兩種場景：不同開發階段的模型，如設計階段的模型中的一個類trace需求階段模型的另一個概念；不同子系統的模型，如客戶端模型的一個用于顯示數據的類trace服務端模型的一個保存數據的類。

8.替代關系也挺特殊，一個東東可以替代另外一個東東，在泛化和實現中其實是隱藏了替代關系的，如繼承關系中，子類能替代父類，實現同一接口的不同類也能互相替代。個人認為泛化和實現都實現替代的機制，單獨列出一個替代關系，是讓它用于其他機制實現的替代關系，如：C++使用運算符重載機制，自己定義一個大整數類型，可以代替內置的整數類型，這就沒有使用繼承機制。

9.大多數使用(usage)關系，大多數情況下，其實沒有必要再細分類型。具體的使用方式叫給源代碼說明就可以了。更何況，一個類使用另外一個類，可能既包含調用(call)又包含創建(creation)，這時候用使用來概括就可以了。

【UML類關系個人總結】相關文章：

工程類個人總結05-25

工程類個人總結05-25

建筑類個人總結范文09-08

銷售類個人工作總結03-25

工程類個人工作總結05-25

工程類個人工作總結09-09

建筑類個人工作總結02-23

工程類個人工作總結05-25

勞動關系工作總結03-22

判斷關系代詞與關系副詞05-04