6.2.1-UC基本資料

寫給SA的UML/MDA實務手冊
----------
第6章-分析系統流程
6.2-PIM-1：分析系統流程

6.2.1-UC基本資料

• UC名稱：一個UC擁有一份UC敘述，所以UC敘述文件裡面，一定要標示出對應的UC名稱。
• UC編號：UC敘述是UC的一部分，所以UC敘述沒有自己的編號，而是拿UC的編號當作UC敘述的編號。
• UC簡述：只需三言兩語，簡潔說明該UC，以增強UC敘述的可理解性。
• UC圖：在UC敘述的開頭處附上相關的UC圖件，不僅可以一目暸然地得知UC的名稱、參與者名稱等，也豐富了UC敘述的表達方式，擺脫文字格式的單調性。
• 系統：就是提供此UC的系統名稱。有時候在所附上的UC圖件裡可能出現負責提供此UC的系統名稱。
• 參與者：參與者可能具備不同特質，所以有時會將其細分，例如細分成「啟動者」及「支援者」。
• 相關UC：常見的相關性有兩方面，其一是執行UC前必須先行執行過某相關UC，其二是執行UC期間可能驅動其他的包含UC(Inclusion Use Case)，或是因條件符合驅動其他的擴充UC(Extension Use Case)。

就系統內觀而言，各UC在其幕後都是共用同一群物件。也就是說，UC之間自然就具有「共用物件」之關係。但是，由於UC圖只呈現系統外觀，所以在UC圖裡看不到這種關係。在外觀方面，UC之間有兩種關係，分別是「包含」(Include)和「擴充」(Extend)關係。

兩個UC之間可以有「包含」關係，用以表示某一個UC的對話流程中，包含著另一個UC的對話流程。一旦出現數個UC都有部份相同的對話流程時，將相同的流程記錄在另一個UC中；前者稱為「基礎UC」(Base UC)，後者稱為「包含UC」(Inclusion UC)。

如此一來，這些基礎UC就可以共享包含UC，而且未來其他的UC只要建立了包含關係，就可以立即享用已經在其他UC定義好的相同對話流程了。在基金模擬個案中，投資人只要上網申購單筆基金，就會收到一封交易成功的通知電郵，如圖6-1所示。

圖6-1:  包含關係

由於，投資人上網申購定期定額基金，也會包含一段電郵交易通知對話流程，此時可以使用包含關係，重用已經寫好的「電郵交易通知」系統UC，如圖6-2所示。此時，針對「網路申購定期定額基金」系統UC敘述，系統分析師就不需要再重寫一次「電郵交易通知」的敘述了。

圖6-2:  重用包含UC

簡言之，包含關係是來自於抽象的動作(Abstraction)，即從數個不同的UC 之中，抽離出共同的部分，而成為可以重用的UC。系統分析師必需為每個UC撰寫UC敘述，一旦將共同的敘述抽象出來，就不必在「網路申購單筆基金」和「網路申購定期定額基金」的UC敘述中重複描述出「電郵交易通知」了。

這一來，就大大簡化了「網路申購單筆基金」和「網路申購定期定額基金」的UC敘述內容了。此外，當系統分析師有必要去修改「電郵交易通知」的UC敘述時，也不必更動到「網路申購單筆基金」和「網路申購定期定額基金」的UC敘述內容了。

兩個UC之間可以有「擴充」關係，用以表示某一個UC的對話流程，可能會依條件臨時插入另一個UC的對話流程中；前者稱為「擴充UC」(Extension UC)，後者稱為「基礎(Base UC)。

有了擴充關係後，便可以將特定條件下才會引發的流程記錄於擴充UC中。當執行基礎UC期間，可以只是單純地執行基礎UC所記載的流程；但是在特定條件發生時，則會額外插入並執行擴充UC所記載的流程。在基金模擬個案中，理專代客申購單筆基金之後，可以依投資人要求列印申購收執聯，如圖6-3所示。

圖6-3:  擴充關係

簡言之，擴充關係來自於UC內執行活動的過程有分為主要過程(Main Course)及可選擇性過程(Alternative Course)。在基金模擬個案中，有些投資人可能跟理專認識多年，所以在臨櫃申購基金時，也不需要理專列印申購收執聯給他。有些投資人較為謹慎，所以會要求理專列印申購收執聯。申購基金的過程是主要過程，而列印申購收執聯則為可選擇性過程。