用UML呈現系統分析到設計的變化（上）

在Scrum敏捷開發中，每一個衝刺期就是一小段的反覆（Iteration, 也有另一個常見的譯詞為「循環」），包括了分析、設計、實作、測試等等的開發步驟，以便團隊迅速地修訂錯誤。

每個衝刺期間的一開始也會先舉行衝刺計畫會議，來決定該衝刺期間的待辦項目，以及團隊的衝刺任務。每一個衝刺待辦項目，會在衝刺計畫會議中分解出相關的「任務」（task），並決定處理的優先順序。

以「增刪改查基金公司基本資料」這項待辦項目來說，拆解出來的任務就包括了撰寫使用案例敘述、繪製類別圖(含資料庫規格)、繪製循序圖、編寫單元測試程式、編寫程式碼、程式重構，以及展示準備（含測試）等任務。這些任務正涵蓋了從分析、設計、實作到測試的開發過程。

我們也利用了UML技術，繪製出每一項產品待辦項目的使用案例圖，將產品待辦清單視覺化。另外也使用類別圖表達系統關係，以利後續用循序圖來表達子系統之間的互動狀況。以「增刪改查基金公司基本資料」的待辦項目為例，我們會分別繪製出新增、刪除、修改、查詢四張循序圖，如圖1、圖2、圖3和圖4所示。

圖1 新增基金公司基本資料[循序圖]

圖2 刪除基金公司基本資料[循序圖]

圖3 修改基金公司基本資料[循序圖]

圖4 查詢基金公司基本資料[循序圖]

十分鐘迅速認識循序圖
在UML2目前的十四款圖中，使用案例圖、類別圖和循序圖，是最著名且實用的三款圖。所以，此處我先用十分鐘來簡潔又迅速地認識一下循序圖，並稍微對前面的四張循序圖來做說明，

首先，請你看到圖5的循序圖，一個基本的循序圖的組成和長相，大約就像這張循序圖。至於，循序圖中的重要元素，我們一一條列如下：

圖5 循序圖的基本組成

● 存活線（Lifeline）：循序圖主要在呈現一群物件的互傳訊息的合作過程，所以循序圖面上帶直立虛線的矩形正代表存活的物件。除了傳統的物件矩形以外，也可以採用自訂的物件圖示。

● 訊息（Message）：橫跨在存活線上的帶箭頭線段，即為兩物件之間傳遞的訊息。物件在傳遞訊息時，也可以攜帶參數，參數可以放置在訊息名稱後面的小括號中。此處的訊息，其實可以直接對應到物件

● 操作（Operation），有時我們會慣用雙斜線（//）做為訊息名稱的開頭，提醒開發人員這是分析階段的訊息，並沒有直接對應到物件操作。

● 執行規格（ExecutionSpecification）：存活線上的長條矩形，稱為「執行規格」，代表物件收到訊息之後，將引發並執行的動作。

接著，請你繼續看到圖6的範例。其實，我們可以從循序圖面上判斷訊息發送的順序，並不需要在訊息前面強加序號。

不過，雖說如此，一般在實務上，我們還是喜歡在訊息前面加上序號，這樣有助於溝通討論和編寫文件。

圖6 迴圈片段

再者，UML2的新版循序圖中，添加了「互動片段」（Interaction Fragment）的概念，讓我們可以框住循序圖中的任何一個區塊，然後操作整個區塊內部的互動。

例如圖6中，我們想要取得一組基金公司物件的基本資料時，就可以透過「迴圈片段」（Loop Fragment）執行一個迴圈，對整組基金公司物件發送相同的訊息。

既然，循序圖可以表達物件的存活線，不免就會令人聯想到物件的誕生與刪除。請你先看到圖7中的《create》訊息，我們使用的StarUML軟體提供這個訊息讓我們表達物件的誕生。

圖7 誕生訊息

不過，StarUML此處的圖示並不正確，正確的「誕生訊息」（Create Message）應該是帶開放箭頭的虛線，並且指向存活線的頂端物件處，如圖8所示。由於，誕生訊息非常明確，所以也就不需要再特別標示出《create》字眼了。

圖8 誕生訊息正確的畫法

此外，我們也可以在存活線的底部標示一個大叉叉，意謂著該處發生了一個「消滅事件」（Destruction Event），該物件被刪除了。

最後，我們再來補充一個比較少人使用，但是其實還算實用的概念「狀態定數」（State Invariant）。狀態定數是一種執行期間（runtime）的限制條件（constraint），用來限制存活物件必須遵守該限制條件，否則後續的事件就不會發生。

以圖9為例，我們在新增一筆基金公司資料時，會先檢查看看資料庫裡頭是否已經存在了該基金公司，只有在基金公司的資料未建檔時，才會新增一筆基金公司資料。所以，在這種情況下，我們就在發出4號誕生訊息之前，即時評估isExist是否為false。一旦，「isExist==false」成真（true）時，才會往下執行後續的訊息。

圖9 狀態定數

除了把狀態定數直接擺放在存活線上，也可以放到折角的註解圖示中，或者狀態的圓角矩形中。比較需要特別注意的是，如果是直接放置在狀態圖示中的話，就不需要額外加大括號了。套用ASP.NET MVC2的設計階段循序圖
上面四張圖是設計階段的循序圖，不過，由於我們採用了微軟的ASP.NET MVC2做為此處的技術平臺，因此產出了另一份套用了ASP.NET MVC2的設計階段循序圖，如圖10所示。

圖10 查詢基金公司基本資料[設計階段的循序圖]

接著，我們來看分析階段的類別與設計階段之間的對應，如表1和表2所示。除了基金公司DAO，實作成一般的C#類別（class），其餘的基金公司、增刪改查基金公司UI和增刪改查基金公司UCO這三個類別，則分別套用ASP.NET MVC2的View、Controller和Model。

在訊息的部份，比較大的變動是「取得基金公司基本資料」（圖4訊息4和圖10訊息8），如圖11所示。

圖11 查詢基金公司基本資料[變更]

本來在分析階段的圖4中，是由增刪改查基金公司UCO負責取出基金公司實體物件的屬性值，然後才回傳給前端的增刪改查基金公司UI。

不過，在ASP.NET MVC2的技術架構中，將由Controller將Model傳回給View，讓View主動取出Model中的資料，並且顯示在網頁上。

由於，這是個很大的變動，所以我們得同步回頭修改原先的循序圖，最後改成圖12的模樣。

圖12 查詢基金公司基本資料[修改過的分析圖]

在實務上，如果開發團隊採用的UML工具，有提供從原始程式碼反向產出循序圖的功能，你也可以試著在繪製出分析階段的循序圖之後，先行編寫程式碼，然後透過UML工具反向自動產出細膩的設計階段循序圖。

下一回，我們再接著以「基金公司基本資料」待辦項目的其他功能，來舉例說明設計階段循序圖和分析階段循序圖的差別。