修訂歷程
日期 |
版本 |
說明 |
作者 |
|
|
|
|
|
|
|
|
使用案例建模準則
本準則集的目的是要確定「使用案例」模型保持一致。它提供有關如何記載「使用案例」的指引,以及有關經常發現的「需求指定元和系統分析師」問題之相關主題的一般說明。
您可以如現狀使用或調整這些準則來符合大部分專案的需求。
請參閱 Rational Unified Process 名詞解釋。
無
本準則集編排成兩個區段,第一個區段說明我們偏好的使用案例建模方式,第二個部分提供使用案例模型的內容準則,以及模型內之元素的命名準則。
使用案例將使用隨 Rational Unified Process 提供的範本來撰寫,其中會修正某些樣式和版面配置來符合適用的專案說明文件標準。
「參與者」與「使用案例」之間的關聯稱為「通訊」關係。建議這個關聯是單向的。在使用這個建模策略下,我們將區分下列項目:
q
作用中的參與者
當「參與者」起始(或觸發)「使用案例」的執行時,「參與者」會被視為「參與者-使用案例」對組中的主動者。通訊關係上的箭頭指向「使用案例」。
q
被動參與者
當「使用案例」起始通訊時,「參與者」會被視為「參與者-使用案例」對組中的被動者。「被動參與者」通常會是我們的系統必須與其通訊的外部系統或裝置。通訊關係上的箭頭指向「參與者」。
會作出這項建議的原因是,主動及被動參與者的概念對「使用案例」模型的讀者有加值的作用。
在第一個實例中,建議您避免使用這些關係。會作出這樣的建議是因為,誤用這些關係所可能造成雜亂及混淆的可能性,遠超過它們有助於簡化「使用案例模型」的可能性。最佳的作法是一開始避免這種類型的分解,而考慮在流程中的稍後階段使用這些關係。這些關係可用來:
1、 析出兩個或多個使用案例之共同行為的因素。
2、 從基本使用案例中分析出對於瞭解使用案例之主要目的並非必要的行為,只有其結果是重要的。
3、 顯示在一組行為區段集中可能有一或數個行為區段可以在基本使用案例中的延伸點上插入。
但是它們應只在它們有加值作用(幫助簡化及管理使用案例模型)的地方使用。
併入關係說明行為區段,此區段被插入使用案例實例中,執行基本使用案例。它是一種在本質上類似子常式的機制,最常用來分析常見行為的因素。
請參閱 Rational Unified Process 中的併入關係之準則, 以取得詳細資料。
延伸關係是較難以利用的關係,主要是因為延伸使用案例對於基本使用案例不明。一般的評註是,在大部分的商業系統中,有幾個是這種關係非常有用的地方。不過,請記住,規則固定都會有例外,而且在某些情況下,這項機制可能非常有用。
請參閱 Rational Unified Process 中的延伸關係之準則, 以取得詳細資料:
一般而言,使用「參與者一般化」可以將要開發之系統的使用者所扮演的不同角色定義得更好。 這在具有不同「種類」之一般使用者的應用程式中非常有用。在這種方式下,只有相關的功能會呈現給每一個種類的使用者,而我們也能夠依據這種分組來控制存取權。
簡略的規則:每一個使用案例都只會被一位「參與者」起始。您可以置換這項「規則」,但是在該情況下,使用案例說明必須調整此決定。
來自大學企業領域的範例:
「圖書館員」和「教授」是「大學領域」中的兩個現有角色(參與者)的範例。這些角色有一些共同的任務,還有一些他們在「企業」中的角色所特有的任務。以下顯示加以建模的偏好方式。
請參閱準則: Actor Generalization 以取得詳細資料。
在某些情況下,在文字式的事件流程之外,另併入「互動」圖來說明使用案例事件的「高階」流程是非常有幫助的。建議您在 Rational Rose 中為此繪製一個序列圖。僅包含參與者與界限物件之間的通訊(涵蓋輸入和輸出訊息),並將系統視為黑箱。使用具有定義於使用案例事件流程之邏輯名稱的界限物件,但是在這一點上不將它們指派給類別。
每個使用案例不一定都要有相對應的互動圖: 它是選用的工作成果。
活動圖對於協助定義、釐清及完成使用案例中的事件流程非常有助益,建議在 Rational Rose 中建立這些事項的模型。有一個不錯的簡略規則是考慮對複式使用案例(包含數個替代流程和(或)異常狀況流程)使用「活動圖」。活動圖顯示使用案例中的流程之決策樹。
每個使用案例不一定都要有相對應的活動圖: 它是選用的工作成果。
如需有關「使用案例」的一般資訊及相關準則,請參閱 Rational Unified Process。
如需有關「參與者」的一般資訊及相關準則,請參閱 Rational Unified Process。
每一個具體的使用案例是否都與至少一位參與者關連?如果不是,表示有問題;沒有與參與者互動的使用案例是多餘的,您將加以移除或識別相對應的參與者。
在某些情況下,多位參與者可以在使用案例互動中扮演某一部分。請務必檢查在一個使用案例中使用多位參與者是否有效(請參閱「參與者一般化」)。
參與者是否有直覺性的及敘述性的名稱?使用者及客戶是否都能瞭解該名稱?參與者名稱與他們的角色相對應非常重要。如果不然,請變更它們。
您應參閱「使用案例模型」,確定您對使用案例中的每位參與者使用的都是正確的參與者名稱。
將會保持一致地使用參與者名稱來撰寫使用案例規格。將會小心確定參與者名稱既清楚又明確。
請勿通指「參與者」;而應使用用來唯一識別或定義參與者的實際名稱。您可以將參與者名稱當作在一組系統互動集中所扮演的角色來考量。
使用案例名稱將會是唯一、直覺且闡明的,以便它清楚且明確地定義從使用案例中所取得的值的顯著結果。
有一個檢查使用案例名稱的好方法是: 調查客戶、業務代表、分析師及開發人員是否全部都瞭解使用案例的名稱和說明。請記住: 您是站在參與者的觀點定義值的顯著結果。
每一個使用案例名稱將說明使用案例支援的行為。此名稱將結合已執行的動作以及「已執行動作的」關鍵元素。這是最常是簡單的「動詞/ 名詞」組合。應從觸發使用案例之參與者的角度來為使用案例命名。範例包括:「登錄課程」、「選取執教課程」。
使用案例將包含簡要說明。這項說明的長度至少將有 1 個段落,且不超過 3 個段落。這項說明將涵蓋使用案例的主要目的、 價值主張和概念。
在有加值作用的地方,可以將簡短範例 "story" 與簡要說明一起併入,幫助提供進一步的環境。這個範例通常會遵循「基本流程」,而若有幫助的話,則會併入資料值。
使用案例內的系統需求將會用祈使語氣撰寫。已優先選擇「將會」取代「應該」和「必須」,以保持一致地說明需求。將會避免使用默示需求為可選用或未定義的被動詞彙,例如「應該」、「可能是」、「等等」、「可能」、「可以」。
使用案例中使用的所有「商業詞彙」將定義於專案的「名詞解釋」。如果「使用案例」中有的商業詞彙不在名詞解釋中,則該詞彙必須:
1、 新增至名詞解釋,其中包括簡要說明(最多一個段落)。
2、 在使用案例中變更,以反映定義於名詞解釋的正確「商業詞彙」。
使用案例將會明確陳述其中系統負責呈現動作作為可供參與者選取之可用選項的地方。在大部分的情況下,可用的選項應作為基本流程的一部分呈現,並作為相對應替代流程中的第一個陳述式中的進入點被參照。
在整個使用案例中,將會固定使用像是「新建」、「修改」、「取消」、「刪除」、「確定」和「列印」等術語: 將不會使用不同的術語參照相同的邏輯動作。將會特別注意,確定「替代流程」中使用的「動作術語」與基本流程中使用的那些「動作術語」相符。
每次參與者與系統之間的互動變更焦點(參與者與系統之間)時,行為的下一個區段將從新的段落開始。從參與者先開始,然後是系統。
句子的開頭必須是「<參與者名稱> 將會 xxxxx」或「系統將會 xxxx」。一律正確地完整描述參與者名稱,而不要用任何縮寫。
每一個替代流程和子流程都會明確且清楚地定義進入流程的所有可能的進入點,並會以離開流程的所有可能的離開點結束。
備用流程也會明確敘述跳出點,以及參與者繼續進行的下一個位置 - 它會回到基本流程中的某特定步驟或是結束。
在事件流程由於繁複的行為而變得雜亂的地方,或是單一流程在長度上超過實際列印頁的地方,可以使用子流程來提升明確性及管理複雜性。子流程的撰寫方式將會是,將詳細行為的自行包含、邏輯群組移至子流程,並在事件流程內以摘要格式參照這項行為。
使用案例規格將會包含一組條件集(又稱為假設),預期這些條件會在使用案例開始之前(前置條件)以及使用案例結束之後(後置條件)為真。請注意,使用案例可能有若干種結束方式,應照著各方式說明「後置條件」。
在資訊尚未定義或尚未決定的地方,使用案例將會包含對問題或元素的參照,並且會包含位置保留元:TBD。
有一些於事件流程期間無法自然說明的額外需求,這些需求將被定義為增補需求。至於使用案例特有的那些需求,這些將會定義於使用案例規格的「特殊需求」區段。
至於那些適用於全系統的需求(特別是那些本質為非功能的需求),將會定義於一或多個各別的增補規格文件。
範例包括:
可靠性: - 系統必須是可用的 24 x 7。
- 系統必須執行達 48 小時 MTBF。
效能: - 系統必須在預期的正常負載狀況下提供不超過 5 秒的線上回應。
將會比對「UI 原型/ 設計」來交叉核對使用案例內容,以確保使用案例或「UI 原型/ 設計」中沒有遺漏任何系統需求。在必須對使用案例進行變更的情況下,將會採取下列動作: 將會註記對「UI 原型」的變更,作為將來動作的討論。
提供了下列準則以協助發現「異常狀況流程」:
針對使用案例中的每一個步驟,考量什麼地方可能會出問題。您可以將每一個唯一的異常狀況都記錄為「異常狀況流程」。在某些情況下,單一的「異常狀況流程」會在使用案例之間通用,例如「逾時」。要記錄的重要資訊是企業需求是什麼,以及何時發生異常狀況,亦即,參與者應經歷什麼?