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 的目標等級分為三種:
  • 目標摘要等級
  • 使用者目標等級
  • 子功能目標等級
Copyright © 2012. Huan-Lin 學習筆記 - All Rights Reserved
Powered by Blogger
Template Design by Cool Blogger Tutorials
Published by Templates Doctor