Use Case 的擴充（extension）關係

在最近 reivew 的一個 Use Case Diagram 裡面，發現有用到 Use Case 的擴充關係。那張圖看起來類似這樣：

這張圖得第一個問題，是它看起來還是以功能切割（funtional decomposition）的方式來思考，只是以 Use Case Diagram 的方式呈現。

另一個值得注意地方，是圖中使用了 Use Case 的擴充關係（<>），也就是標示為 "延伸" 的 stereotype（這張圖是用 IBM RSA v6 畫的，它把 <> 翻譯為 "延伸"）。就 <> 關係的定義來看，用在這裡並不恰當。以下是我從書中節錄出來有關擴充關係的定義和使用時機：

• <> 關係可以在現存的使用案例中插入新的行為片段。
• 就基本使用案例而言，在設計時對於擴充使用案例的內容其實是一無所知的，基本使用案例只是標示出可與擴充使用案例介接的點。實際上，基本使用案例即便沒有介接任何的擴充使用案例，本身的流程也已經非常完整，這點和 <> 關係非常不同。包含關係的基本使用案例若沒有內含使用案例時，本身是不完整的。進一步來說，就是擴充點事實上並不存在於基本使用案例的事件流程中，甚至，擴充點比較像是一層薄膜覆蓋在事件流程的上面。
• 基本使用案例的的流程並不會知道（或不擔心）哪裡是可以擴充的，所以可以使用 <> 來任意地擴充基本使用案例中的流程。
• 擴充使用案例（Extension Use Case）一般來說都不是完整的使用案例，也因為如此，所以擴充使用案例是不能具體化的，它們通常擁有多個行為片段，並且是要插入其他使用案例的步驟中。
• 請你在你覺得有需要時才寫出擴充使用案例，對大家來說，擴充使用案例是很難理解或維護的。不過，在兩種情況下我們可能會需要用到擴充使用案例。最常見的情況是：在某個使用案例中，使用者可能會用到許多非同步或中斷性服務，這些服務都不該影響到基本使用案例。......另一種情況是你希望在已確定不改的需求文件中增加一點東西。
• 我們之所以發明擴充關係，第一個原因是因為不想修改之前系統的需求文件。

以上文字摘自這兩本書：趙光正翻譯的《使用案例寫作實務：寫作指南、秘訣與範本》，以及邱孝賢，康凱雄合譯的《UML 物件導向系統分析與設計》。如果你的工作需要撰寫 Use Case，或者想要學習物件導向分析設計，這兩本書應該會有不少幫助。

話說回來，如果前面的例子不適合用擴充關係，那應該用什麼關係？繼承？應該不至於。<> ？從語意來看，可以解釋為「經費申請」包含另外三個子 Use Case，似乎說得通。但 Use Case 的 <> 關係比較像是函式呼叫的動作，個人是不會這樣用。在不使用新的 stereotype 的前提下，我會把［經費申請］底下的三個 Use Cases 獨立出去，成為另一個「目標等級」（註1）較低的 Use Case Diagram。

註1：在《使用案例寫作實務：寫作指南、秘訣與範本》當中，Cockburn 把 Use Case 的目標等級分為三種：

• 目標摘要等級
• 使用者目標等級
• 子功能目標等級