敏捷時代的建模：敏捷團隊的擴張除了代碼還需要什么?(2)

　　圖3,“應保留的”與“臨時的”敏捷模型

　　應保留的模型

　　在不同的情況下(人員數量、系統的重要度、需求的穩定程度、是否企業級系統或者嵌入式系統)，應保留的模型種類也不同?；谖业慕涷瀬砜?，以下幾種模型可以成為應保留的模型：

　　架構的類圖/包圖

　　領域模型的類圖/實體關系圖

　　關鍵用例的用例圖 + 時序圖/協作圖

　　雖然我們主要使用的是UML方式，但你也不必刻意遵守嚴格的UML規格。之所以選擇它是因為它提供了種類豐富的標準圖形，并且關于它的各種教材也已經很多了。另外，用于表現數據與流程的實體關系圖(ERD)與數據流圖(DFD)也會由于相同的原因而在某些地方使用到。

　　圖4以圖形方式顯示了這三種應保留的模型的角色。簡單地說，“架構”表現了系統結構，“領域模型”表現了問題領域中的關鍵概念，而“關鍵用例”則為系統的使用方式提供了示例。

　　圖4，架構、領域模型以及關鍵用例

　　接下來我會以我的某個團隊中所使用的真實示例與圖片，分別解釋這三個模型。

　　1. 架構的類圖/包圖

　　架構是對整個系統的一種結構化展示，它經常以類圖或者包圖的典型方式顯現全局的層次(tier或layer)。舉例來說，一個包含用戶界面與數據庫的應用程序，經常按照從用戶界面到數據庫進行水平分層，用例將跨越這些層以實現它的功能。

　　像“MVC”(模型-視圖-控制器)這樣的架構模式也可以作為一個全局架構。圖5是某個架構的包圖的示例，很顯然它是基于某種MVC架構設計的。

　　團隊中的每個人都應該理解架構中的各個部件的角色與作用，這樣才能保證團隊成員所編寫的代碼處于架構中的正確位置。

　　在這張圖的多個包之間顯式地表現了“依賴項”的存在，這樣做是為了避免不必要的耦合或循環依賴。因為從架構的視角來說，內部包的循環依賴是最糟糕的問題，它會提高測試的難度，并且增加編譯的時間。

　　(單擊圖片以放大)

　　圖5，架構的類圖/包圖(示例)

　　2. 領域模型的類圖或實體關系圖

　　領域模型描述了應用程序所在的領域中的概念分類。在人員交流的層面上，領域模型的詞匯集將成為“Ubiquitous Language”，并且在全體項目相關人員之間使用，包括用戶、領域專家、業務分析師、測試與開發者。

　　而在編碼的層面上，領域模型對于為各種編程結構選擇合適的命名也是非常重要的，包括類、數據、方法以及其它各種協定。概念分類(經常稱為“實體”)中的很大一部分會被映射到數據庫中的某個持久化數據結構，并且它們的生命周期往往會長于應用程序本身。通常來說，如果你的應用程序選擇了某種“MVC”架構，那么你的領域模型(或者說實體)會駐留于你的邏輯架構中的“M”(模型)包內。而在Ruby on Rails類型的應用程序中，實體關系圖將會更加適用于表達某個領域模型，因為模型與關系型數據庫的關系更加直接與緊密了。

　　還要注意的一點是，領域模型是隨著時間進化的。由于領域處于問題理解與通信的核心地帶，因此怎樣維護在團隊中(或更大一些的范圍，如整個社區)不斷發展的領域模是一個很大的主題，這一點在Eric Evans的領域驅動設計(DDD)一書中進行了詳細的討論。

　　圖6是某個以類圖方式表現的領域模型示例，它用一張圖表現了整個領域。

　　(單擊圖片以放大)

　　圖6，領域模型的類圖(示例)

　　3. 關鍵用例的用例圖與時序圖/協作圖

　　關鍵用例經常從用戶角度表現系統的使用方式，有兩個原因讓我們決定將它作為保留模型的一部分。首先，開發者經常會鉆進解決方案細節中，而遺忘了系統的用戶是誰，以及他們想在系統中完成什么任務。用例能夠幫助他們回到用戶的視角，同時它也是與用戶對話的一種良好的方式(其它文檔更適合給技術人員看)。

　　其次，用時序圖或協作圖方式表現關鍵用例以及它們的運作過程對于開發者來說是一個很好的示范。它們描述了系統架構中不同層次的對象如何協同工作，以完成用戶的目標。它表現了一個從用戶界面到數據庫的縱切面的實際示例，并且告訴你如何在整個架構中實現某個用例。

　　關鍵用例不必完整到覆蓋所有的情況，只需挑選那些典型的用例，并使它們保持簡單。

　　(單擊圖片以放大)

　　圖7，關鍵用例的用例圖(示例)

　　(單擊圖片以放大)

　　圖8，關鍵用例機制???的協作圖(示例)

　　圖7是用例圖的一個示例，它使得系統的用戶與經典場景更加清晰化。它不需要非常完整，但應該表現出系統的上下文情況。標為黃色的用例(“創建類圖”)被選為某個用例示例，具體的設計分解體現在圖8的協作圖中。通過這一示例，團隊能夠將他們對架構圖與領域模型圖(表現在圖5與圖6中)如何完成關鍵用例中所描述的特性的理解進行分享。請再次看看圖4中架構、領域模型與關鍵用例這三者的關聯吧。

　　你可以在畫這些圖時使用工具，以簡化維護工作，然后將它們打印到一張大紙上并粘貼到墻上。這面墻就會成為建模研討會的討論場所了(我在下一節中會很快討論到這部分)。

原文轉自：http://www.kuqin.com/shuoit/20131123/336470.html