Use Case 的擴充(extension)關係
這張圖得第一個問題,是它看起來還是以功能切割(funtional decomposition)的方式來思考,只是以 Use Case Diagram 的方式呈現。
另一個值得注意地方,是圖中使用了 Use Case 的擴充關係(<
- <
> 關係可以在現存的使用案例中插入新的行為片段。 - 就基本使用案例而言,在設計時對於擴充使用案例的內容其實是一無所知的,基本使用案例只是標示出可與擴充使用案例介接的點。實際上,基本使用案例即便沒有介接任何的擴充使用案例,本身的流程也已經非常完整,這點和 <
> 關係非常不同。包含關係的基本使用案例若沒有內含使用案例時,本身是不完整的。 進一步來說,就是擴充點事實上並不存在於基本使用案例的事件流程中,甚至,擴充點比較像是一層薄膜覆蓋在事件流程的上面。 - 基本使用案例的的流程並不會知道(或不擔心)哪裡是可以擴充的,所以可以使用 <
> 來任意地擴充基本使用案例中的流程。 - 擴充使用案例(Extension Use Case)一般來說都不是完整的使用案例,也因為如此,所以擴充使用案例是不能具體化的,它們通常擁有多個行為片段,並且是要插入其他使用案例的步驟中。
- 請你在你覺得有需要時才寫出擴充使用案例,對大家來說,擴充使用案例是很難理解或維護的。不過,在兩種情況下我們可能會需要用到擴充使用案例。最常見的情況是:在某個使用案例中,使用者可能會用到許多非同步或中斷性服務,這些服務都不該影響到基本使用案例。......另一種情況是你希望在已確定不改的需求文件中增加一點東西。
- 我們之所以發明擴充關係,第一個原因是因為不想修改之前系統的需求文件。
以上文字摘自這兩本書:趙光正翻譯的《使用案例寫作實務:寫作指南、秘訣與範本》,以及邱孝賢,康凱雄合譯的《UML 物件導向系統分析與設計》。如果你的工作需要撰寫 Use Case,或者想要學習物件導向分析設計,這兩本書應該會有不少幫助。
話說回來,如果前面的例子不適合用擴充關係,那應該用什麼關係?繼承?應該不至於。<
- 目標摘要等級
- 使用者目標等級
- 子功能目標等級