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

這張圖看起來還是以結構化的功能切割方式來思考，只是以 Use Case Diagram 的方式呈現。不過還好，已經沒有「經費申請補助作業」、「預算項目設定作業」...等「XX 作業」的寫法。

其中一個比較 tricky 的地方，是使用了 Use Case 的擴充關係（由於工具的緣故，圖中的 stereotype 名稱是 "延伸"）。以擴充關係的定義和用途來看，用在這裡並不恰當。以下是我從書中節錄出來有關擴充關係的定義和使用時機：

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

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

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

 

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

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