這個定義有幾個關鍵字:
-
使用案例實例。
定義中所參照的序列,實際上是系統中的特定事件流程,或是一個實例。可能的事件流程有許多,許多可能會非常類似。如果要讓使用案例模型成為可以理解,您應該將類似的事件流程群組在單一使用案例中。識別和說明使用案例,實際上便是識別和說明一組相關的事件流程。
-
系統執行。 這表示系統提供使用案例。參與者會與系統的使用案例實例通訊。
-
可觀察的結果值。
您可以將值放在順利執行的使用案例上。使用案例應該確定參與者可以執行含可識別的值之作業。在判斷使用案例的正確層次或精細度時,這非常重要。正確層次是指實現的使用案例不會太小。在特定情況下,您可以利用使用案例來作為組織的規劃單元,其中包含作為系統之參與者的個體。
-
動作。 動作是一個計算或演算程序。當參與者提供信號給系統時,或當系統取得時間事件時,便會呼叫動作。動作可能隱含將信號傳輸給發出呼叫的參與者或其他參與者。動作是不可分割的,這表示它會完整執行,或完全不執行。
-
特定參與者。 參與者是尋找正確使用案例的關鍵,這尤其是因為參與者可協助您防止使用太大的使用案例。
例如,請設想一個視覺化的建模工具。這個應用程式實際上有兩個參與者:開發人員和系統管理員,開發人員在工具支援之下開發系統,系統管理員則負責管理工具。每個這些參與者都有他自己的系統需求,因此,需要一組自己的使用案例。
系統功能由不同的使用案例來定義,每個使用案例都代表一個特定的事件流程。使用案例的說明定義在執行使用案例時,系統會發生什麼。
在自動櫃員機中,客戶可以在帳戶中提款、在帳戶之間轉帳,或檢查帳戶餘額。這些功能對應於您可以利用使用案例來代表的流程。
每個使用案例都有它自己要執行的作業。已收集的使用案例構成系統所有可能的使用方式。您只需要觀察使用案例作業的名稱,就能大致瞭解這個使用案例。
以下是當您識別使用案例時,一組非常有用的問題:
-
對於您所識別的每個參與者,系統會執行哪些作業?
-
需要向參與者通知系統中的特定事件嗎?
-
參與者需要向系統通知突然發生的外部變更嗎?
-
系統會提供商業的正確行為嗎?
-
您所識別的使用案例能夠執行所有特性嗎?
-
哪些使用案例會支援和維護這個系統?
-
必須在系統中修改或建立哪些資訊?
以下是經常會被忽略的使用案例類型,因為它們不代表系統通常的主要功能:
-
系統啟動和停止。
-
維護系統。例如,加入新使用者和設定使用者設定檔。
-
維護系統所儲存的資料。例如,系統建構成與舊式系統並列運作,在兩者之間,資料需要同步。
-
修改系統行為時所需要的功能。建立新報告的功能便是一個範例。
如果您發展了商業使用案例模型和商業分析模型,這些構件便是識別使用案例的好起點。
在詳述的初期反覆中,只有少數使用案例(含架構重要性的使用案例)會有任何超出簡要說明的詳細說明。您一律應該先開發使用案例的概要(採逐步的格式),再深入細節。這份逐步概要應該是您第一次嘗試定義使用案例事件流程的結構(請參閱下面的事件流程 - 結構)。請一律從使用案例的基本流程開始。在取得基本流程概要的某些共識之後,您便可以關聯於基本流程來加入替代流程應該有的內容。
詳述將結束之時,您計劃詳細說明的所有使用案例都應該已經完成。
您的模型中常常會有非常簡單的使用案例,它們不需要事件流程的詳細說明,只需要逐步的概要便已足夠。這項決策的準則是讀者類型的使用者對使用案例的意義沒有不同意見,且設計者和測試人員都接受逐步格式所提供的詳細程度。說明系統中某些資料之簡單輸入或擷取作業的使用案例便是範例。
一組使用者系統互動(或對話),究竟是單一或多重使用案例,通常很難決定。請設想回收機的使用情況。客戶將存放項目(如罐頭、瓶子和箱子)插入回收機中。客戶插入所有存放項目之後,便按下按鈕,這時會列印收據。之後,他便可以用這份收據來換錢。
請問,插入存放項目是一個使用案例,要求收據又是另一個使用案例嗎? 或它們只是一個使用案例?
這裡有兩個動作,但這兩個動作若是分開,對客戶而言沒什麼用。相反地,所有插入動作及取得收據是完整的對話,這就是客戶所需要的價值(對他有意義)。因此,從插入第一個存放項目到按下按鈕和取得收據是一個完整的對話,完整的對話便是完整的使用情況,這就是一個使用案例。
另外,您要將這兩個動作放在一起,以便同時檢視它們、同時修改它們、同時測試它們、撰寫它們的手冊,以及一般地將它們當作單一單元來管理它們。在大型系統中,這就非常明顯。
使用案例說明當參與者與系統互動來執行使用案例時,系統中會發生什麼。使用案例並不去定義系統藉由協同作業的物件在內部執行作業的方式。這個部分保留給使用案例實現化來顯示。
範例:
在電話範例中,除了其他事項,使用案例還指出系統會在話筒舉起時發出信號,之後,系統再接收號碼、尋找接收端、使接收端電話鈴響、連接呼叫、傳話等。
在執行系統中,使用案例的實例並不對應於實作模型中的任何特定物件(例如,程式碼中的類別實例)。相反地,它對應於參與者所呼叫且作為一組物件中的一段事件序列來執行的特定事件流程。換句話說,使用案例的實例對應於實作之物件在通訊中的實例。這稱為使用案例的實現化。相同的物件通常會參與多個使用案例的實現化。例如,在銀行業系統「存款」和「提款」這兩個使用案例的實現化中,也可能使用特定帳戶物件。這不表示這兩個使用案例進行通訊,只表示它們的實現化使用相同的物件。
您可以將單一事件流程視為由多個子流程所組成,這些子流程共同產生整體事件流程。您可以在其他使用案例的事件流程中,重複使用子流程的說明。單一使用案例事件流程說明中的子流程,可能與其他使用案例的事件流程是共用的。在設計時,您應該讓相同物件針對所有相關的使用案例來執行這個共用的行為;也就是說,這個行為只應該由一組物件來執行,不論究竟是哪個使用案例在執行作業,都是如此。
範例:
在自動櫃員機系統中,「提款」和「檢查餘額」使用案例事件流程的起始子流程是相同的。這兩個使用案例的事件流程都是從檢查卡片的身分及客戶的個人存取碼開始。
使用案例實例可以遵循的路徑數目幾乎是無限,但可以列舉。這些路徑代表在事件流程說明中,開放給使用案例實例的選項。所選的路徑會隨著事件而不同。事件類型包括:
-
參與者的輸入。例如,參與者可以從多個選項中,決定接著要執行的動作。
範例:
在回收機系統的「回收項目」使用案例中,客戶一律會有兩個選項:繼續投入另一個存放項目,或取得退回項目的收據。
-
檢查內部物件或屬性的值或類型。例如,如果值大於或小於特定值,事件流程便可能有所不同。
範例:
在自動櫃員機系統的「提款」使用案例中,如果客戶要求的金額超出帳戶金額,事件流程會有所不同。因此,使用案例實例會遵循不同的路徑。
如果系統允許,多個使用案例的實例及相同使用案例的多個實例可以並行運作。在使用案例的建模中,您可以假設使用案例的實例可以同時作用,且不會發生衝突。預期設計模型會解決這個問題,因為使用案例的建模並不說明事物的運作方式。檢視這一點的方式之一,是假設每次只會有單一使用案例實例在主動式,且這個實例是一個不可分割的動作。在使用案例的建模中,「解譯機器」被認為是速度無限快,因此,使用案例實例的序列化不成為問題。
每個使用案例都應該有一個名稱,指出它與參與者互動所完成的事項。名稱必須是可供瞭解的幾個字。任兩個使用案例都不能用相同的名稱。
範例:
以下是「回收機」範例中之「回收項目」使用案例的名稱變式範例:
-
接收存放項目
-
正在接收存放項目
-
退回存放項目
-
存放項目
使用案例的簡要說明應該反映它的目的。當您撰寫說明時,請參閱使用案例所涉及的參與者、名詞解釋,以及(必要的話)定義新的概念。
範例:
以下是回收機系統中「回收項目」和「加入新的瓶子類型」使用案例的簡要說明樣本:
回收項目:使用者利用這個機器來自動計算所有退回項目(瓶子、罐子和箱子),取得收據。現金出納機(機器)會兌現這份收據。
加入新的瓶子類型:您可以在機器中加入新的瓶子類型,首先是從「學習模式」開始,依照退回項目的方式插入 5 個樣本。在這個方式之下,機器就可以測量瓶子,學習識別它們。管理者要指定新瓶子類型的退款金額。
使用案例的事件流程包含從使用案例模型工作衍生而來的最重要的資訊。它應該清楚說明使用案例的事件流程,且應該足以讓外人輕易瞭解它。請記住,事件流程應該呈現系統要做什麼,而不是系統是如何設計來執行所需要的行為。
以下是事件流程的內容準則:
-
說明使用案例如何開始和結束。
-
說明在參與者和使用案例之間交換什麼資料。
-
除非對系統行為的瞭解有此需要,否則,不說明使用者介面的細節。例如,如果事先知道應用程式是 Web 型應用程式,使用一組有限的 Web
專用名詞通常會比較好。否則,人們可能會認為您的使用案例文字太抽象。將併入專有名詞的詞彙可能是「導覽」、「瀏覽」、「超鏈結」、「網頁」、「送出」和「瀏覽器」等。不過,您最好不要依照在建立「頁框」或「網頁」之間的界限假設時所採用的相同方式來併入指向「頁框」或「網頁」的參照
- 這是一項關鍵性的設計決策。
-
說明事件流程,而不只是功能。為了強制執行這一點,請用「當參與者...」來作為每個動作的開頭。
-
只說明屬於使用案例的事件,不說明其他使用案例中發生了什麼,或系統外發生了什麼。
-
用語避免模糊。
-
詳細說明事件流程 - 所有關於「什麼」的問題,都應該回答。請記住,測試設計者將利用這份文字來識別測試案例。
如果您在其他使用案例中使用特定詞彙,請務必在這個使用案例中使用完全相同的詞彙,它們的意義相同。如果要管理共用詞彙,請將它們放在名詞解釋中。
事件流程有兩個主要部分:基本事件流程和替代事件流程。基本事件流程應該涵蓋當執行使用案例時,「通常」會發生的情況。替代事件流程涵蓋與正常行為相關的選用或異常特性的行為,以及正常行為的變式。您可以將替代事件流程想成從基本事件流程中「繞道」,有些會返回基本事件流程,有些會結束執行使用案例。
事件流程的一般結構。直的箭頭代表基本事件流程,曲線代表與正常路徑相關的替代路徑。有些替代路徑會返回基本事件流程;有些則會結束使用案例。
基本事件流程和替代事件流程應該進一步結構化成為步驟或子流程。在執行這項作業時,您的主要目標應該是文字的可讀性(另請參閱下面的事件流程 -
樣式一節)。簡略的規則是子流程應該是使用案例內的一個行為區段,它有清楚的目的,且具備「不可分割」,也就是說,所說明的動作全都執行,或全都不執行。您也許需要幾個層次的子流程,但可以的話,應該避免,因為文字會更複雜,更難理解。您可以利用活動圖來說明事件流程的結構,請參閱工作成果準則:使用案例中的活動圖。
這類寫下且形成連續子區段結構的文字,對讀者而言,原本就隱含了子流程會形成序列。為了避免誤解,您一律應該指出子流程的順序是否固定。這類考量通常與下列項目相關:
-
商業規則。例如,使用者必須先獲授權,之後,系統才能提供特定資料。
-
使用者介面設計。例如,系統不應強制執行符合某些人直覺、但不符合另一些人直覺的特定行為序列。
如果要釐清替代事件流程要放在結構中的什麼位置,您必須針對基本事件流程的每個「繞道」說明下列事項:
-
替代行為可以插入基本事件流程的哪裡。
-
啟動替代行為之前,必須先實現的條件。
-
在哪裡、如何回復基本事件流程,以及使用案例如何結束。
範例:
這是回收機系統「退回項目」使用案例中的替代子流程。
2.1. 瓶子卡住
如果在第 1.5 節「插入存放項目」中,一個瓶子卡在閘口,閘邊的感應器和測量閘會偵測到這個問題。傳送帶會停止,機器會發出警報來呼叫操作員。機器會等操作員指示問題已修正。之後,機器會繼續基本流程的第 1.9 節。
在上述範例中,替代事件流程插在基本事件流程的特定位置上。另外,還有替代事件流程可插在多個位置上,有些甚至可以插在基本事件流程的任何位置。
範例:
這是回收機系統「退回項目」使用案例中的替代子流程。
2.2. 移除面板
如果有人移除回收機的面板,可能會停止壓縮罐頭。在沒有面板的情況下,不可能壓縮罐頭。這個移除動作也會啟動一個警報來通知操作員。重新蓋上面板之後,機器會從基本事件流程中的停止位置回復作業。
如果替代事件流程很簡單,只在基本事件流程區段中說明它(使用某些非正式的「if-then-else」建構)會很吸引人。這個情況應該避免。太多替代事件流程會使正常行為看不清楚。另外,將替代路徑併入基本事件流程區段中,會使文字更加「貌似虛擬程式碼」,更難閱讀。
一般而言,擷取事件流程的某些部分,個別說明這些部分,可以增加基本事件流程的可讀性,且可以改進使用案例及使用案例模型的結構。 您可以將擷取部分建模如下:
-
如果它是基本事件流程的簡單變式、選項或例外,擷取部分便建模成基礎使用案例內的替代事件流程。
-
如果它是您想要封裝起來,供其他使用案例重複使用的東西,擷取部分便建模成基礎使用案例中的明確併入使用案例(請參閱工作成果準則:併入關係)。
-
如果基礎使用案例的基本事件流程是完整的,也就是說,它定義了開頭和結尾,擷取部分便建模成基礎使用案例中的隱含併入使用案例(請參閱工作成果準則:延伸關係)。延伸流程的本質應該是您偏好將它隱藏在基礎使用案例的說明中,使它看起來比較不複雜。
-
如果上述任何替代項目都不適用,擷取部分便建模成基本事件流程中的子流程,可能是作為另一個選項。例如,在「維護員工資訊」使用案例中,可能會有用來新增、刪除和修改員工資訊的個別子流程。
您可以用許多樣式來說明使用案例。我們在範例中顯示了用三個不同樣式來說明的「管理訂單」使用案例基本事件流程,它們的主要差別在於正式的程度。第一個樣式顯示在範例 1
之下,建議您採用這個樣式,因為它很容易瞭解,事物的發生次序也清楚明白。文字分成編號的具名小節。號碼可讓您更容易參照小節。小節名稱可讓讀者在瀏覽文字時,只看標題就能很快得到事件流程的概觀。
在下面的範例 2 中,事件流程的說明無法釐清事物的發生次序。如果您用這個樣式來撰寫,您和其他人可能會遺漏關於系統的重要事項。
下面的範例 3
顯示另一個樣式,如果您覺得事件順序很難清楚表示,它可能很有幫助。這個虛擬程式碼樣式比較精確,但如果不是技術人員,文字不好讀,也不好吸收,當您想要快速掌握事件流程時,尤其如此。
1.1. 使用案例開始
當操作員參與者告訴系統去建立測量訂單時,這個使用案例便告開始。之後,系統會擷取所有網路元素參與者、它們的測量物件以及這個特定操作員所能使用的對應測量功能。可用的網路元素便是作業中的網路元素,以及操作員有權存取的網路元素。測量功能的可用性會隨著特定測量物件類型已設定的項目而不同。
1.2. 配置測量訂單
系統可讓操作員參與者選取要測量的網路元素,再顯示所選的網路元素可以使用哪些測量物件。系統可讓操作員從測量物件選取,再選取要針對每個測量物件來設定的測量功能。
系統讓操作員輸入測量訂單的文字備註。
操作員告訴系統去完成測量訂單。系統回應時,會產生唯一的測量訂單名稱,且會設定應該進行測量的時間、頻率和時間長度的預設值。對每位操作員而言,預設值都是唯一的。之後,系統會讓操作員編輯這些預設值。
1.3. 起始設定訂單
操作員告訴系統去起始設定測量訂單。之後,系統將記錄負責建立的操作員身分、建立日期,以及測量訂單的「排程」狀態。
1.4. 使用案例結束
系統向操作員確認測量訂單的起始設定,其他參與者也可以檢視測量訂單。
|
說明使用案例:在這個樣式中,文字很容易閱讀,事件流程也很容易遵循。在您的說明中,請儘量採用這個樣式。
訂購者可以建立訂單來從網路元素中收集測量資料。
系統會指派訂單的唯一名稱和預設值,指示測量的長度和時間以及重複的頻率。訂購者可以編輯這些值。
訂購者必須進一步指定可以接受哪些測量功能、網路元素和測量物件。訂購者也可以在訂單中加入個人備註。
定義好必要的資訊之後,會建立一份新的訂單,並利用定義好的屬性、建立者名稱和建立日期來起始設定。這時訂單的狀態會設為「已排程」。(狀態的可能值如下:已排程、執行中、已完成、已取消和錯誤。)
之後,使用者介面會收到已建立新訂單的通知,也會收到指向新訂單的參照,以便顯示它。
|
說明使用案例:這個樣式可讀,但沒有清楚的事件流程。
'管理訂單' (使用者身分)
REPEAT
<= '顯示管理訂單功能表'
IF ( => '建立訂單' (測量函數,
網路元素, 測量物件)) THEN
系統找到唯一名稱、何時執行測量和執行多久的預設值。
<= '顯示訂單' (預設屬性)
REPEAT
=> '編輯訂單' (要變更的屬性, 屬性的新值)
<= '更新畫面' (新屬性)
UNTIL (已定義所有屬性)
REPEAT
IF ( => '編輯訂單' (要變更的屬性, 屬性的新值))
THEN <= '更新畫面' (新屬性)
ELSIF ( => '儲存訂單' (訂單識別, 屬性)) THEN
建立訂單,在系統中以定義屬性、
建立者的名稱、建立日期及
'排程' 狀態來起始設定。
<= '建立新訂單' (訂單)
ENDIF
UNTIL (=> '結束')
ENDIF
UNTIL '結束管理訂單'
|
說明使用案例:作者在這裡選取了使用虛擬程式的正式樣式。這個樣式造成很難快速擷取流程步驟,但如果很難精確擷取事件流程,它就可能很有幫助。
「管理訂單」使用案例事件流程的完整說明(包括它的替代流程),看起來可能如下:
1. 基本事件流程
1.1. 使用案例開始
當操作員參與者告訴系統去建立測量訂單時,這個使用案例便告開始。之後,系統會擷取所有網路元素參與者、它們的測量物件以及這個特定操作員所能使用的對應測量功能。可用的網路元素便是作業中的網路元素,以及操作員有權存取的網路元素。測量功能的可用性會隨著特定測量物件類型已設定的項目而不同。
1.2. 配置測量訂單
系統可讓操作員參與者選取要測量的網路元素,再顯示所選的網路元素可以使用哪些測量物件。系統可讓操作員從這些測量物件選取,再選取要針對每個測量物件來設定的測量功能。
系統讓操作員輸入測量訂單的文字備註。
操作員告訴系統去完成測量訂單。系統回應時,會產生唯一的測量訂單名稱,且會設定應該進行測量的時間、頻率和時間長度的預設值。對每位操作員而言,預設值都是唯一的。之後,系統會讓操作員編輯這些預設值。
1.3. 起始設定訂單
操作員告訴系統去起始設定測量訂單。之後,系統將記錄負責建立的操作員身分、建立日期,以及測量訂單的「排程」狀態。
1.4. 使用案例結束
系統向操作員確認測量訂單的起始設定,其他參與者也可以檢視測量訂單。
2. 替代事件流程
2.1. 沒有可用的網路元素
如果在「1.1 使用案例開始」中,沒有任何網路元素可用來測量這個操作員,系統就會通知這個操作員。之後,使用案例便告結束。
2.2. 沒有可用的測量功能
如果在「1.2 配置測量訂單」中,所選網路元素沒有可用的測量功能,系統會執行操作員,且可讓操作員選取其他網路元素。
2.3. 取消測量訂單
在使用案例執行期間,系統允許操作員隨時取消所有動作。之後,系統會返回使用案例啟動之前的狀態,並結束使用案例。
在使用案例的特殊需求中,您說明了事件流程所未涵蓋的使用案例所有需求。這些都是將影響設計模型的非功能需求。 另請參閱工作成果準則:使用案例模型中關於非功能需求的討論。您可以將這些需求組織在「使用性」、「可靠性」、「效能」和「可替代性」等種類中,但其中只有極少數不會特別受益於這類分組。
範例:
在回收機系統中,「退回存放項目」使用案例可能會有如下特殊需求:
機器必須能夠識別可靠性超出 95% 的存放項目。
前置條件和後置條件這兩個觀念非常適合用來釐清事件流程開始和結束的方式。不過,請只在使用案例的聽眾覺得它有附加價值時,才使用它。
前置條件是使用案例開啟之前,系統及其週遭項目必須具備的狀態。後置條件是使用案例結束之後,系統所能具備的狀態。
注意事項如下:
-
前置或後置條件所說明的狀態應該是使用者能夠觀察的狀態。「使用者已登入系統」或「使用者已開啟文件」都是可觀察的狀態範例。
-
前置條件是使用案例何時可以啟動的一項限制。它並不是啟動使用案例的事件。
-
使用案例的前置條件並不是單一子流程的前置條件,不過,您可以定義子流程層次的前置條件和後置條件。
-
無論執行了哪些替代流程,都應該符合使用案例的後置條件;並不是只有主流程才應如此。如果可能有失敗項目,您會將它涵蓋在後置條件中,指出「動作已完成,或如果有失敗項目,便沒有執行這個動作」,而不只是「動作已完成」。
-
當您搭配延伸關係來使用後置條件時,請注意,延伸使用案例並不會引進違反基礎使用案例後置條件的子流程。
-
後置條件可以是使用案例非常有力的說明工具。您首先要定義使用案例假設要實現什麼 - 後置條件。之後,您可以說明如何達到這個狀況所需要的事件流程。
範例:
ATM 機器「提款」使用案例的前置條件:客戶有針對個人發放且符合讀卡機的卡片、核發了一個 PIN 號碼,並向銀行系統註冊。
ATM 機器「提款」使用案例的後置條件:在使用案例結束時,所有帳戶和交易日誌平衡,重新起始設定與銀行系統的通訊,且卡片已退還給客戶。
使用案例因為延伸點而有可能延伸。它有名稱,以及一份使用案例事件流程內之一或多個位置的參照清單。延伸點可以參照使用案例中兩個行為步驟之間的單一位置。另外,它也可以參照一組離散的位置。
使用具名延伸點可協助您分開延伸使用案例的行為規格和基礎使用案例的內部細節。您可以修改或重新安排基礎使用案例,只要延伸點的名稱保持不變,延伸使用案例就不受影響。
這時,您向未將行為可能延伸的位置載入說明基礎使用案例事件流程的文字中。另請參閱工作成果準則:延伸關係。
範例:
在電話系統中,抽象使用案例「顯示發話端身分」可以延伸「發出呼叫」使用案例。這是一項選用服務,通常稱為「來電識別碼」,接收方可能已要求它,也可能未要求它。「發出呼叫」使用案例中的延伸點說明看起來可能如下:
名稱:顯示識別碼
位置:在「1.9 接收端電話鈴聲」之後。
您可以選擇在使用案例所擁有的使用案例圖(偶而會有多圖)中,說明使用案例如何關聯於參與者和其他使用案例。如果使用案例涉及許多參與者,或關聯於許多其他使用案例,這就很有幫助。這類圖有「本端」特性,因為它只是從單一使用案例的角度來顯示使用案例模型,無意說明整個使用案例模型的一般事實。另請參閱工作成果準則:使用案例圖。
|