敏捷式軟體開發 (Agile Software Development)：原則、模式與實踐——第19章 類圖

標籤：

第19章　類圖

19.1 基礎知識
19.1.1 類

　　類一般表示成下面的樣子：

分成格間的類表徵圖以及對應的代碼

　　注意類表徵圖中變數和函數名前面的符合。（-）表示private；（#）表示protected；（+）表示public。

19.1.2 關聯

　　類之間的關聯表示的是那些持有對其他對象引用的執行個體變數。如phone和Button之間的關聯：

一個PhoneBook對象和多個PhoneNumber對象相連（星號表示許多）：

19.1.3 繼承

　　UML中所有的箭頭都指向原始碼依賴的方向。類和類之間的繼承用實線，類和介面之間的繼承用虛線。我建議在白板上畫圖是，不要把箭頭畫成虛線，畫虛線太浪費時間了。

　　繼承關係樣本：

　　實現關係樣本：

等價於如下棒棒糖狀介面：

19.2 類圖樣本

以下為ATM樣本：

看到這幅圖時，你應該能設想出代碼。UI實現的代碼如下：

public abstract class UI :WithdrawalUI, DepositUI, TransferUI{    private Screen itsScreen;    private MessageLog itsMessageLog;    public abstract void PromptForDepositAmount();    public abstract void PromptForWithdrawalAmount();    public abstract void InformInsufficientFunds();    public abstract void PromptForEnvelope();    public abstract void PromptForTransferAmount();    public abstract void PromptForFromAccount();    public abstract void PromptForToAccount();    public void DisplayMessage(string message)    {        itsMessageLog.LogMessage(message);        itsScreen.DisplayMessage(message);    }}

 

19.3 細節

　　在大多數情況下，細節和修飾是不應該加入的，不過，有時候它們卻是有用的。

19.3.1 類衍型

　　類衍型出現在一對文法號（<<>>）之間。C#程式員可以使用兩個標準的衍型：<<interface>>和<<utility>>。

19.3.2 抽象類別

　　把名字寫成斜體的，或者使用（abstract）屬性，即可表示抽象類別：

　　在白板上畫圖時，可以使用非正式的表示：

 

19.3.3 屬性

　　屬性被書寫成以逗號分隔的名字/值對列表。屬性寫在類名右下方：

　　除了{abstract}屬性，我不知道屬性還有什麼用處。就我個人而言，畫UML圖這麼多年，我沒有找到任何使用類屬性有用的地方。

19.3.4 聚集
　　聚集（aggregation）是關聯的一種特殊形式，暗含整體/部分關係。

19.3.5 組合

　　組合（composition）是聚集的一種特殊形式。所有者/所有物關係。

19.3.6 多重性

　　對象可以含有其他對象的數組或者集合，也可比不同的執行個體變數中持有許多其他同類對象。多重性運算式可以是簡單的數字、範圍或者兩者的組合。

允許的多重性格式：

數字——元素的確切數目；

*或者0..*——0個到多個。

0..1——0個或者1個，在C#中，常常用可以為null的引用來實現。

1..*——1個到多個。

3..5——3~5個

0,2..5,9..*——可笑，但卻是合法的。

19.3.7 關聯衍型

<<create>>衍型意味著源建立出目的並把它傳遞給系統的其他部分。

<<local>>衍型意味著建立出來的執行個體的生存期就在建立它的成員函數的範圍之內。

<<parameter>>衍型表示源類通過某個成員函數的參數擷取對目標執行個體的訪問權。虛依賴箭頭線是一種常用且方便的參數表示慣用法。

<<delegate>>衍型表示源類把一個成員函數調用轉交給目標。

19.3.8 內嵌類

　　
19.3.9 關聯類別 

　　雖然多重性關聯告訴我們源和許多目標執行個體相連，但是我們卻無法看出使用了哪種容器類。可以通過關聯類別來描述這一點。

19.4 結論
　　要避免UML中大多數神秘、複雜的特性，只要瞭解經常使用的部分就可以了。過少使用UML幾乎總是比過多使用要好。

 

摘自：《敏捷式軟體開發 (Agile Software Development)：原則、模式與實踐(C#版)》Robert C.Martin    Micah Martin 著

轉載請註明出處：

JesseLZJ
出處：http://jesselzj.cnblogs.com

敏捷式軟體開發 (Agile Software Development)：原則、模式與實踐——第19章　類圖