【用VS2010動手學UML第10回】UML用例圖不可或缺的用例敘述

只透過用例圖的圖形化表達，是不足夠的，還有許多繁瑣的需求細節需要透過一般的文字，細膩地記錄下來才行。因此，在實務上，除了用例圖，我們還會產出文字格式的「用例敘述」（Use Case Narrative）。所以說，用例圖與用例敘述，圖文相依，缺一不可。

不過，由於用例敘述不是UML標準的一部分，因此並沒有標準的用例敘述格式可以使用。至於VS2010/UML，也理所當然地，並沒有提供任何的用例敘述格式了。但若打開VS2010/UML用例圖工具箱時，可以看到有一個中級概念「產出物」（Artifact），這可用來連結某一個用例與它的敘述文件檔（用例敘述），或者是根據用例所產出的其他細部設計圖。

如果你對用例敘述有興趣深入，可以參考《寫給SA的UML/UseCase實務手冊》一書，該書花了許多篇幅在細談用例圖與用例敘述。

子系統
我們已經介紹了大部分的用例圖初級概念，只剩下一個初級概念還沒介紹，那就是「子系統」（Subsystem）。不過，除此之外，前兩回介紹參與者和用例的性質表時，也保留了「能見度」（Visibility）以及「主體」（Subject）這兩個欄位，也會在此處一併說明。

圖1 主體[UML母模]

其實，在UML母模中，並沒有「子系統」這個元素，不過有一個「主體」，如圖1所示。但是，兩者並不是毫無關係，事實上，子系統正是最常見的一種主體。

簡單來說，主體會實現用例，而參與者則是位於主體外部，會與主體互動以便達成某個特定的目標。所以，即便在用例圖中，我們並未正式繪製出主體的圖示，也無妨，因為主體的界線本來就存在於參與者和用例之間了。

圖2 課務系統

當然，我們還是可以使用子系統的圖示，直接標示出實現用例的主題。再者，如果該專案中，同時開發多個子系統的話，更可以透過子系統圖示，明確指出該用例圖在描述哪個子系統，如圖2所示。

這時，我們再回過頭來打開查看課程細節的用例性質表查看，可以發現它的「主體」欄位處，自動出現了「課務系統」這個子系統名稱了，如圖3所示。

圖3 主體

圖4 四種能見度

最後，我們來看能見度的概念，請你打開能見度欄位，如圖4所示。

你可以看到在UML中預設了四個等級的能見度，分別為：

● 公開（Public）：公開等級的元素，代表沒有任何限制，所有的其他元素都可以使用它。一般來說，用例的能見度通常是公開等級的元素，所以只要跟它有結合關係的參與者，都可以使用公開用例。

● 私有（Private）：私有等級的元素，代表最嚴密的限制，僅供自己專用，所有的其他元素都「不」可以使用它，公開等級完全相反。

● 保護（Protected）：保護等級的能見度配合一般化關係使用，它的嚴密程度比私有等級開放些，除了自用外，透過一般化關係向下繼承的子元素，也可以使用保護等級的元素。

● 套件（Package）：套件等級的能見度配合「套件」（Package）使用，除了自用外，同套件的其他元素也可以使用套件等級的元素。我們至今還未談過套件，應該會在類別圖和套件圖的系列文章中，才深入談論套件。簡單來說，套件是一種群集機制，我們可以用它來將相關的元素群集在一起。

其實，參與者或用例的能見度特性，同樣價值不高，因為能見度主要用在類別的屬性和操作上頭。所以，這邊我們就先簡單介紹一下，等到談類別圖時，我們再來多談一些吧！

用例敘述
一開始我們就提到，用例圖還需要搭配文字形式的用例敘述，來記錄參與者和系統的互動細節。但是，用例敘述並不是UML標準的一部分，所以並沒有標準的用例敘述格式。

因此，在接下來的內容中，我們會先介紹一個簡單的用例敘述格式，然後再說明VS2010/UML如何使用「產出物」（Artifact）元素，來連結用例圖示和用例敘述文檔。

其實，你可以在網路上搜尋到許多用例敘述格式，或者在很多書中、文章及UML工具中，都可以發現有用例敘述的文件格式。比較可惜的是，VS2010/UML未能提供用例敘述格式供我們使用。用例敘述格式
你要是沒有屬意的用例敘述格式，我建議一開始你可以先採用下列格式，然後再逐步發展你自己的格式。在下列的用例敘述格式的設計上，我盡量保持十個欄位，如果你有自行擴充的欄位，可以歸為第二層級，如下：

1. 簡介（Introduction）

1.1 用例編號（ID）：唯一的用例編號，方便我們追蹤用例的開發情況。
1.2 用例名稱（Title）：以動詞起頭，用詞具體明確，最好讓觀看的人看了馬上就可以得知，這個用例會提供什麼樣的產出或服務。

1.3 內容摘要（Abstract）：一、兩句具體明確的簡要說明，最好可以讓觀看者一目暸然、立即理解。

1.4 參與者（Actors）：這欄位跟用例圖上的參與者一致。

1.5 重要性（Importance）：系統分析師可以給一個數值，用來標示出這個用例的重要性。最好「別用」連續性的數字，比方說1代表最重要、2代表次重要、3代表普通重要等等，諸如此類的連續性數字，別用。改採用差距較大的數字，方便從中插入其他重要性的用例，比方說：100代表最重要、90代表次重要、50代表普通重要，這樣如果臨時遇到需要插入一個介於90～100間重要程度的用例時，你才會方便插入。

1.6 初始估算（Initial Estimate）：可以使用「人日」（man-day）做單位，初步估算一下完成整個用例的所需的工時。比方說，這個用例大約需要3個人力，而且花費5天時間，那就可以估15人日。然後，也可以使用特殊數字代表特殊情況，像是使用0代表「已經完工」，使用-1代表「還未估算」。

2. 主要流程（Basic Flow）：這個用例正常的執行過程，可以採用條列式方式撰寫，而且每個句子以「主詞／動詞／受詞」的格式撰寫。再者，主詞只有兩種：參與者或系統；因為用例敘述主要在描述參與者和系統兩者的互動過程，所以用例敘述中的主詞只有這兩者。

3. 替代流程（Alternative Flows）：用例執行主要流程的過程中，可能發生的例外情況。同樣建議你採用條列式的描述方式，較為明確清晰。

4. 子流程（Subflows）：在用例敘述中，局部可重用的流程，可以放到子流程中。

5. 關鍵情節（Key Scenarios）：系統分析師可以列出幾種重要且常見的使用情節，日後編寫「測試案例」（Test Case）時，便可以參考此處的情節描述。

6. 重要展示（Key Demo）：簡單描述如何展示這個用例，讓開發人員知道當這個用例開發完成之後，展示給客戶看的時候，應該會是怎樣的展示過程。

7. 條件（Conditions）

7.1 前置條件（Preconditions）：用例執行「前」，必須成立的條件；前置條件不成立的話，將無法啟動這個用例。

7.2 後置條件（Postconditions）：用例執行「後」，必須成立的條件；後置條件不成立的話，代表這個用例並沒有完整執行。

7.3 企業規則（Business Rules）：問題領域中重要且必須遵守的企業規則或特殊的運算公式。

8. 擴充點（Extension Points）：配合擴充關係使用，如果有其他小用例擴充這個用例的話，可以在此處列出在什麼樣的條件或情況下，這個大用例會啟動執行擴充的小用例。

9. 特殊需求（Special Requirements）：這個用例所必須遵守的非功能性需求，可以條列在這個地方。

10. 補充資訊（Additional Information）

10.1 資料定義（Data Definitions）：中英文對照、簡單的定義，以及範例。

10.2 畫面雛型（UI Prototypes）：簡單的假畫面，不需要設計的太詳盡或細膩。

10.3 待解議題（Issue）：這個用例所延伸出來還需要進一步討論的議題，可以條列於此，如果能夠放入議題追蹤管理系統，那就更棒了。

10.4 其他附件（Appendix）：其他附加的表格文件、會議紀錄、設計文檔等等，都可以把檔案位置或網址連結條列於此，方便管理和追蹤。產出物
雖然，VS2010/UML沒有提供用例敘述格式給我們，但是它在用例圖工具箱中加入了「產出物」（Artifact）和「依賴關係」（Dependency）這兩個元素，如圖5所示。

圖5 用例圖的工具箱

前頭我們已經解釋過了，產出物並不是用例圖的元素，它其實被歸為「部署圖」（Deployment Diagram），但是VS2010/UML用它來連結用例敘述的文檔。至於，依賴關係雖然是個常見的初級概念，但是比較常用在其他的UML圖款中，鮮少用在用例圖中。所以說，VS2010/UML在用例圖工具箱中提供這兩個元素，恰好可以讓我們用來連結用例敘述文檔，如圖6所示。

圖6 產出物與依賴關係

圖7 產出物的圖示

事實上，圖6的產出物圖示還未連結到一個特定的檔案，請你看到圖7產出物圖示的右上角，一旦連結到特定的文檔或網頁時，小圖會不同。而且，倘若連結了特定的檔案，用滑鼠雙擊產出物圖示，VS2010/UML幫我們打開連結的文檔或網頁。

圖8 UML的產出物圖示[StarUML]

不過，特別注意，VS2010/UML的產出物圖示並不是UML的標準圖示，請你看到圖8，右上角出現一個折角的便利貼小圖，才是標準的產出物圖示。

對了，我們還沒談到該到哪裡設定連結的檔案路徑。請你打開產出物的性質表，如圖9所示，性質表中有一個超連結的欄位，可以讓我們設定連結的文檔或網頁。

圖9 產出物的性質表

圖10 產出物[UML母模]

請你繼續看到產出物的性質表，其中的能見度概念，我們就不談了。還有，是否設定為抽象產出物，概念也都跟前頭的抽象概念相同。至於，是否設定為「葉節點」（Is Leaf），我們可以先來看到圖10，這個特性其實是繼承自「可被重新定義的元素」（RedefinableElement）。

其實，是否為葉節點的這個特性，必須搭配一般化的繼承架構來使用，而且這個特性應該放在類別來談，比較有價值。不過，既然這邊提到了，我們就趁機學一學吧！

由於，在一般化架構下的特殊元素（或稱為子元素），可以重新定義繼承而來的屬性、操作或關係等等的特徵。在這種情況下，一般元素（或稱為父元素）的葉節點特性將預設為「否」（False），意謂著日後可以被子元素重新定義。當然，如果將這個特性設定為「真」（True），意謂著日後繼承它的子元素，不可以重新定義繼承來的特徵。

圖11 產出物模版

最後，請你打開產出物的模版，會看到如圖11所示的一堆模版。產出物共有8個模版，其中的實現模版和規格模版繼承自類詞，至於其他6個模版相當好懂，就是系統開發過程中會產出的各種不同實體產出物。

條列說明產出物的八種模版，如下：

● 文件檔（document）：一般的文件檔，但不是程式碼檔或者可執行檔。

● 執行檔（executable）：可以在電腦系統中執行的程式檔案。

● 檔案（file）：系統開發過程中，一併產出的實體檔案。

● 程式庫（library）：靜態或動態的程式庫檔案。

● 實現（realization）：<前面談過了，繼承自類詞的模版，代表含有具體實作的檔案。

● 腳本檔（script）：電腦系統可以直譯的腳本檔。

● 程式檔（source）：擺放原始程式碼的檔案。

● 規格（specification）：前面也談過了，跟實現模版一樣繼承自類詞，代表沒有包含具體實作的檔案。