標籤:
第16章 對象圖
有時,呈現出系統在某個特定時刻的狀態是非常有用的。和一個正在運行系統的快照類似。UML對象圖展示了在一個給定時刻擷取到的對象、關係和屬性值。
不過,你應該對花太多的對象圖保持警惕。在大部分的情況下,它們都可以從相應的類圖中直接推匯出來,因此沒有多少用處。
第17章 用例
在所有的UML圖中,使用案例圖是最令人迷惑也是最沒有用處的。我建議出來系統邊界外,忽略掉所有其他的圖。系統邊界圖樣本如下:
大矩形是系統邊界。矩形內的所有東西都是將要開發的系統的組成部分。矩形外面是作業系統的參與者。參與者可以是人也可以是其他系統或裝置。
第18章 順序圖
順序圖示UML使用者最常繪製的動態模型。但是不要為每個方法都建立順序圖。 當你需要立即向某個人解釋一組對象的協作方式或者當自己想要把這種協作關係可視化時,才使用順序圖。把順序圖當作一種偶爾使用以磨練自己分析能力的工具,不要把它們當作必須的文檔。
18.1 基礎知識
18.1.1 對象、生命線、訊息及其他
典型的順序圖:
時間軸是垂直方向的,訊息出現的位置越低,就越晚發送。注意GetEmployee訊息中e變數的使用,Employee和e其實是同一個對象。GetEmployee的傳回值就指向Employee對象的引用。EmployeeDB是一個類,所以它的名字下面沒有底線。這意味著GetEmployee只能是一個靜態方法。
18.1.2 建立和析構
建立一個對象,畫一條線終結在要建立的對象,如下:
對應的代碼:
public class ShapeFactory{ public Shape MakeSquare() { return new Square(); }}
把一個對象釋放給記憶體回收行程:
對應代碼:
public class TreeMap{ private TreeNode topNode; public void Clear() { topNode = null; }}
18.1.3 簡單迴圈
畫簡單迴圈的方法是在需要重複發送訊息的周圍畫一個框。然後在一個中括弧中包含迴圈條件。
18.1.4 時機和場合
不要繪製具有大量對象和訊息的順序圖。沒人能夠理解,也沒有人願意去看。這是一種巨大的時間浪費。如果覺得順序圖是必要的,問一下自己是否能夠把它分解成以小組情境。
團隊應該致力於建立出具有表達力、易讀的代碼。代碼越是能夠描述自己,你就越不需要圖示,整個項目就越好。
一般來講,高層試圖要比低層試圖更有用一些。
18.2 進階概念
18.2.1 迴圈和條件
18.2.2 耗費時間的訊息
以撥打電話為例子,正常的呼叫電話如下:
失敗的撥打電話如下:
18.2.3 非同步訊息
樣本如下:
18.2.4 多線程
樣本如下,T1,T2是線程的名字:
18.2.5 主動對象
一個具有獨立內部線程的對象,這種對象叫做主動對象。它們顯示為粗體邊框,如下所示:
18.2.6 向介面發送訊息
樣本如下:
通過介面向其衍生類別型發送訊息:
18.3 結論
順序圖就是一個工具。要按照其設計意圖使用。在白板前使用它們來即時地和他人進行溝通。在簡短的文檔中使用它們記錄系統中的那些核心、重要的協作。
就順序圖而言,過少比過多要好。你總可以在以後需要時再畫一幅順序圖。
摘自:《敏捷式軟體開發 (Agile Software Development):原則、模式與實踐(C#版)》Robert C.Martin Micah Martin 著
轉載請註明出處:
JesseLZJ
出處:http://jesselzj.cnblogs.com
敏捷式軟體開發 (Agile Software Development):原則、模式與實踐——第16章 對象圖、第17章 用例、第18章 順序圖