使用案例模型是系統目標功能及其周遭項目的模型,它用來作為客戶和開發人員之間的合約。整個系統開發過程都以使用案例為統一貫串的執行端緒。相同的使用案例模型是「需求」規範的結果,用來作為「分析和設計」及「測試」規範的輸入。
下圖說明回收機系統使用案例模型的一部分。
使用案例圖,顯示含有參與者和使用案例的使用案例模型。
您可以利用許多方式來建立系統模型,每個方式都可能適用於不同目的。不過,使用案例模型最重要的目的,是與客戶或使用者溝通系統的行為。因此,模型必須很容易理解。
可能與系統互動的使用者及任何其他系統都是參與者。由於參與者代表系統使用者,因此,它們有助於為系統定界,清楚勾勒系統所要做的事。使用案例的開發,是以參與者的需要為基礎。這可以確保系統會符合使用者的預期。
參與者和使用案例都是利用客戶及潛在使用者的需求作為重要資訊而找出來的。當探查使用案例和參與者時,應該簡單說明它們。在詳細說明使用案例之前,客戶應該先檢視使用案例模型來確認所有使用案例和參與者都已找到,且它們共同提供了客戶想要的東西。
在反覆式開發環境中,您將選取每次反覆將詳述的部分使用案例。另請參閱作業:設定使用案例優先順序。
找到參與者和使用案例之後,會詳細說明每個使用案例的事件流程。這些說明顯示系統如何與參與者互動,以及系統在每個個別案例中將執行什麼動作。
最後,會檢視完成的使用案例模型(包括使用案例的說明),開發人員和客戶將利用它來協議系統應該執行的動作。
使用案例模型退化成系統的功能分解,並非少見。如果要避免這個情況,請監視下列症狀:
-
「小型」使用案例,這表示事件流程的說明只是一句話或幾句話。
-
「許多」使用案例,這表示使用案例的數目並不是幾十個,而是有幾百個之多。
-
類似「在這個特定資料執行這項作業」或「利用這個特定資料執行這項功能」等建構的使用案例名稱。例如,「在 ATM 機器中,輸入個人識別號碼」不應該建模成 ATM
機器的個別使用案例,因為沒人會只用系統來執行這個動作。使用案例是為參與者創造價值的完整事件流程。
如果要避免功能分解,您應該確定使用案例模型有助於回答類似下列中的問題:
-
系統的環境定義是什麼?
-
為什麼建置系統?
-
當使用系統時,使用者想得到什麼?
-
系統能為使用者帶來什麼價值?
使用案例顯而易見是擷取系統功能需求的好方法。但非功能需求呢? 它們是什麼?要在哪裡擷取它們?
非功能需求通常分類成使用性、可靠性、效能和可替代性等需求(另請參閱概念:需求)。它們通常都是指定必須符合任何法律和規章需求的需求。它們也可能是因所用的作業系統、平台環境、相容性問題,或任何套用的應用程式標準而有的設計限制。一般而言,您可以說,任何不接受多個設計選項的需求,都應該被視為一項設計限制。
許多非功能需求都套用於個別使用案例,它們都擷取在這個使用案例的內容中。在此情況下,皆於使用案例的事件流程中擷取,或當做使用案例的特殊需求(請參閱準則:使用案例)。
範例:
在回收機系統中,「退回存放項目」使用案例專用的非功能需求可能如下:
機器必須能夠識別可靠性超出 95% 的存放項目。
非功能需求通常套用於整個系統。這類需求擷取在「增補規格」中(請參閱工作成果:增補規格)。
範例:
在回收機系統中,套用於整個系統的非功能需求可能如下:
機器每次只接受一位使用者。
學會如何判斷使用案例應該「開始和結束」於哪個詳細程度,是比較困難的事情之一。從哪裡啟動特性和開始使用案例,在哪裡結束使用案例和開始設計? 我們常常說,使用案例或軟體需求應該指出系統的「目標」("what" the system
does),而不是指出「方法」("how" it does it)。請設想下圖:
一個人的目的地是另一個人的起點。
依您的背景而定,您將利用不同的環境定義來決定您認定的「目標」及「方法」。當判斷使用案例模型是否應該不考慮某個特定細節時,必須將這一點考慮在內。
具體和抽象使用案例有一項區別。具體使用案例是參與者所起始,且是由完整的事件流程構成。「完整」是指使用案例的實例執行參與者所要求的整個作業。
抽象使用案例本身永遠不會產生實例。抽象使用案例會併入到(請參閱準則:併入關係)、延伸至(請參閱準則:準則關係)或一般化(請參閱工作成果準則:使用案例一般化)其他使用案例。當起始具體使用案例時,會建立使用案例的實例。這個實例也會顯現相關抽象使用案例所指定的行為。因此,從抽象使用案例中,不會建立任何個別實例。
這兩者之間的區別很重要,因為參與者所「見到」並在系統中起始的,是具體使用案例。
在表示使用案例是抽象時,您用斜體來寫它的名稱。
範例:
「建立作業」使用案例併入「登記訂單」使用案例中。「建立作業」是一個抽象使用案例。
在倉庫系統中,抽象使用案例「建立作業」併入「登記訂單」使用案例中。當起始「登記訂單」時,會在「登記訂單」事件流程之外建立「登錄訂單」的實例,且會遵循併入的「建立作業」使用案例所說明的事件流程。
「建立作業」永遠不會單獨執行,它一律是作為「登記訂單」 (或它併入其中的任何其他使用案例)的一部分來執行。因此,「建立作業」是一個抽象使用案例。
將使用案例模型結構化,有三個主要原因:
-
讓使用案例更容易瞭解。
-
將許多使用案例內所說明的共用行為分割出來。
-
讓使用案例模型更容易維護。
不過,結構化並不是您要做的第一件事。當您對使用案例行為的瞭解不超出一句簡單說明時,沒必要將使用案例結構化。您至少應該已建立了使用案例事件流程的逐步概要,以確定您是基於對行為足夠精確的瞭解來做決策。
為了建立使用案例的結構,我們有三種關係。您將利用這些關係來分解出使用案例中可供其他使用案例重複使用的片段,或本身是使用案例的特殊化或選項的片段。代表修正部分的使用案例稱為附加使用案例。被修改的使用案例稱為基礎使用案例。
-
如果基礎使用案例有一部分是代表使用案例只依賴結果的功能,而不依賴用來產生結果的方法,這個部分可以分解出來,放在附加使用案例中。這個附加使用案例是利用併入關係明確插入基礎使用案例中。另請參閱準則:併入關係。
-
如果基礎使用案例有選用的部分,或在瞭解使用案例的主要目的時並非必要的部分,這個部分可以分解出來,放在附加使用案例中,以便簡化基礎使用案例的結構。這個附加使用案例是利用延伸關係來隱含地插入基礎使用案例中。另請參閱準則:延伸關係。
-
如果有些使用案例具有共同的行為和結構,也有類似的用途,則可將共同部分抽出放到基礎使用者案例(母項),由其他使用案例(子項)來繼承。 子項使用案例可以在它們繼承自母項使用案例的結構中,插入新的行為及修改現有的行為。另請參閱工作成果準則:使用案例一般化。
您可以利用參與者一般化來顯示參與者如何成為其他參與者的特殊化。另請參閱準則:參與者一般化。
範例:
請設想訂單管理系統的使用案例模型部分。
將一般客戶和網際網路客戶分開很有幫助,因為它們的內容有些不同。不過,由於網際網路客戶會表現客戶的所有內容,因此,您可以用參與者一般化來表示網際網路客戶是客戶的一般化。
這個圖中具體的使用案例是「電話訂購」(客戶參與者所起始)和「網路訂購」(網際網路客戶所起始)。這些使用案例都是更一般化的「下訂單」使用案例的變式,在這個範例中,「下訂單」使用案例是抽象的。「要求型錄」使用案例代表不在「下訂單」主要目的中的選用行為區段。它已經被分解到抽象使用案例中,以簡化「下訂單」使用案例。「提供客戶資料」使用案例代表分解出來的行為區段,因為它是只有結果會影響「下訂單」使用案例的個別功能。其他使用案例也可以重複使用「提供客戶資料」使用案例。在這個範例中,「要求型錄」和「提供客戶資料」都是抽象的。
這個使用案例顯示訂單管理系統的使用案例模型部分。
下表顯示三個不同使用案例關係之間更詳細的比較:
問題
|
延伸
|
併入
|
一般化
|
關係的方向是什麼?
|
附加使用案例參照基礎使用案例。
|
基礎使用案例參照附加使用案例。
|
附加使用案例(子項)參照基礎使用案例(母項)。
|
關係有對應關係嗎?
|
有,在附加端。
|
無。如果您要多次併入相同的行為區段,必須在基礎使用案例指示。
|
無。
|
關係有條件嗎?
|
是。
|
無。如果您要表示併入的條件,您必須在基礎使用案例中明確指示。
|
無。
|
附加使用案例抽象嗎?
|
通常是,但不必然。
|
是。
|
通常不是,但可以是。
|
附加使用案例修改基礎使用案例嗎?
|
延伸使用案例會隱含地修改基礎使用案例的行為。
|
併入使用案例會明確修改基礎使用案例的效果。
|
如果基礎使用案例(母項)產生實例,子項不會影響這個實例。如果要取得附加使用案例的效果,附加使用案例(子項)必須產生實例。
|
基礎使用案例必須完整而有意義嗎?
|
是。
|
與附加使用案例一起,是。
|
如果它是抽象的,否。
|
附加使用案例必須完整而有意義嗎?
|
無。
|
否。
|
與基礎使用案例一起(母項),是。
|
附加使用案例可以存取基礎使用案例的屬性嗎?
|
是。
|
否。併入使用案例是封裝的,它只能「看到」自己。
|
是,藉由一般的繼承機制。
|
基礎使用案例可以存取附加使用案例的屬性嗎?
|
否。當沒有附加使用案例時,基礎使用案例必須形式完整。
|
否。基礎使用案例只知道附加使用案例的作用。附加使用案例是封裝的。
|
否。在這個意義下,當附加使用案例(子項)不存在時,基礎使用案例(母項)必須形式完整。
|
組織使用案例模型使它更容易瞭解的另一方面,是將使用案例分組成套件。使用案例模型可以組織成使用案例套件的階層,「葉節點」是參與者或使用案例。另請參閱準則:使用案例套件。
這個圖顯示使用案例模型階層。箭頭表示可能的擁有權。
每個使用案例的執行都包括與一或多個參與者通訊。使用案例實例一律是由參與者要求系統執行某個動作來啟動。這隱含了每個使用案例都應該有與參與者的通訊關聯。這個規則是為了強迫系統只提供使用者需要的功能,不提供其他東西。如果使用案例存在,但卻沒有發出要求的參與者,就表示使用案例模型或需求出錯。
不過,這個規則仍有些例外:
-
如果使用案例是抽象的(無法個別建立實例),它的行為可能不包括與任何參與者的互動。在這個情況下,這個抽象使用案例不會有任何指向參與者的通訊關聯。
-
如果母項使用案例說明了所有參與者通訊,一般化關係中的子項使用案例便不需要有相關聯的參與者。
-
如果併入使用案例說明了所有參與者通訊,併入關係中的基礎使用案例便不需要有相關聯的參與者。
-
使用案例可以根據排程來起始(如每週一次或每天一次),這表示發起者是系統時鐘。系統時鐘在系統內部 -
使用案例並不是由參與者來起始,而是由內部系統事件來起始。如果使用案例中沒有發生任何其他參與者互動,它就不會關聯於任何參與者。不過,為了更清楚,您可以利用虛擬的「時間」參與者來顯示如何在使用案例圖中起始使用案例。
使用案例模型的調查說明應該:
-
說明哪些是系統的主要使用案例(建置系統的原因)。
-
總結系統的重要技術事實。
-
指出系統界限 - 假設系統不做的事。
-
總結系統環境,如目標平台和現有的軟體。
-
說明系統通常執行的任何使用案例順序。
-
指定使用案例模型所未處理的功能。
範例:
以下是回收機使用案例模型的範例調查說明:
這個模型包含三個參與者和三個使用案例。主要使用案例是「回收項目」,它代表回收機的主要目的。
支援的使用案例如下:
|