作業: 使用案例分析
這項作業說明如何從使用案例中,開發分析層次的使用案例實現化。
規範: 分析 設計
目的
  • 識別執行使用案例事件流程的類別
  • 利用使用案例實現化,將使用案例行為散佈於這些類別
  • 識別類別的責任、屬性和關聯
  • 附註架構機制的用法
關係
步驟
建立分析使用案例實現化
目的 建立用來表示使用案例行為的建模元素。 

使用案例是大部分初期分析和設計工作的核心焦點。為了能夠在以需求為中心的作業和以分析/設計為中心的作業之間進行轉換,工作成果:使用案例實現化扮演了橋樑的角色,它提供將分析和設計模型中的行為追蹤回使用案例模型的方法,同時也組織環繞著使用案例概念的各項協同作業。

如果使用案例實現化尚不存在,請在分析模型中,建立使用案例的分析使用案例實現化。分析使用案例實現化的名稱應該與相關聯的使用案例相同,它應該建立起從分析使用案例實現化到相關使用案例的「實現」關係。

如需使用案例實現化的相關資訊,請參閱技術:使用案例實現化

補充使用案例說明
目的 擷取其他必要的資訊,以便瞭解專為了系統客戶而撰寫的使用案例說明所可能遺漏的必要的系統內部行為。 

各個使用案例的說明並不一定足以用來找到分析類別和及其物件。客戶通常會覺得系統內部事件的相關資訊很無趣,因此,使用案例說明可能會省略這些資訊。在這些情況下,使用案例說明讀起來像一個「黑盒」說明,關於系統如何回應參與者動作的內部細節,若不是遺漏,就是說明過於簡略。因此,如果要尋找執行使用案例的物件,您必須有從內部角度來看的系統動作「白盒」說明。

範例

在自動櫃員機 (ATM) 的情況中,系統客戶可能喜歡說:

「ATM 驗證銀行客戶的卡。」

來描述系統的使用者身分鑑別行為。對客戶而言,這已經夠了,但它並沒有提供在 ATM 內實際發生什麼來驗證卡片的真正觀念。

為了在足以識別物件的詳細層次上,形成系統如何運作的內部圖像,我們可能需要其他資訊。以 ATM 卡片驗證活動為例,展開的說明會如下:

「ATM 將客戶的帳號和 PIN 傳給 ATM 網路來進行驗證。如果客戶號碼和 PIN 相符,ATM 網路會傳回成功,這時會授權客戶進行交易,否則,ATM 網路會傳回失敗。」

這個詳細程度提供了需要哪些資訊的清楚觀念(帳號和 PIN),以及負責鑑別的人(ATM 網路,它是使用案例模型中的一個參與者)。從這項資訊中,我們可以識別出兩個可能的物件(含有帳號和 PIN 這兩個屬性的客戶物件,以及 ATM 網路介面)及它們的責任。

請檢查使用案例說明,看是否已清楚定義了系統的內部行為。系統的內部行為不容有任何模糊,才能清楚系統必須執行什麼動作。這時不需要定義負責執行這個行為之系統(物件)內的元素,只要有必須執行什麼的清楚定義就行了。

這個詳細資料的資訊來源包括能夠協助您定義系統必須執行哪些動作的領域專家。當考慮特定系統行為時,「系統執行這件事是什麼意思?」是一個好問題。如果系統執行這個行為時所採取的動作,其定義不足以回答這個問題,可能是仍有其他資訊有待發現。

以下是補充事件流程說明的選擇方案:

  • 完全不說明。如果您覺得互動圖很容易瞭解,或對應使用案例的事件流程提供了充足的說明,便可能如此。
  • 補充現有的事件流程說明。請在現有文字無法清楚表示系統應該採取什麼動作的區域中,新增事件流程的增補說明。
  • 將它描述成完整的文字流程,有別於「外部」使用案例事件流程說明。當系統內部行為與系統外部行為很不同時,適合採用這個方式。在這個情況下,便有理由採用與分析使用案例實現化相關,而非與使用案例相關的完全獨立的說明。
從使用案例行為中尋找分析類別
目的 識別一組能夠執行使用案例所說明之行為的候選模型元素(分析類別)。 

尋找一組候選的分析類別,是從單純敘述必要的行為轉換成說明系統如何運作之系統轉換的第一步。在這項工作中,分析類別用來代表一些模型元素的角色,這些模型元素用來提供必要的行為,以實現使用案例所指定的功能需求以及增補需求所指定的非功能需求。當專案焦點移到設計時,這些角色會發展成一組實現使用案例的設計元素。

使用案例分析所識別的角色主要用來表現特定系統應用程式專用行為和特定領域專用行為的最上層行為。界限類別和控制類別通常會發展成應用程式層的設計元素,實體類別則會發展成特定領域專用的設計元素。較低層的設計元素通常是從這裡識別的分析類別所用的分析機制發展而來。

這裡所說明的技術利用三個不同的系統角度來推動識別候選類別。這三個不同的角度是系統及其參與者之間的界限、系統所用的資訊,以及系統的邏輯控制。對應的類別模板、界限、實體和控制等是分析期間的一些方便,到了設計時,就沒有這些方便了。

識別各個類別只表示:應該識別、命名它們,以及用幾句話來簡要說明它們。

如需識別分析類別的相關資訊,請參閱技術:分析類別。如需分析使用案例實現化的相關資訊,請參閱技術:使用案例實現化

如果已在特定專案專用的準則中說明了特定分析機制和/或分析型樣,這些應該用來作為分析類別的另一個「靈感」來源。

將行為散佈於分析類別
目的 透過分析類別的協同作業來表現使用案例行為。確定各分析類別的責任。 

對於每個獨立的子流程(情境),請執行下列動作:

  • 建立一或多個互動圖(通訊或序列圖)。使用案例的主要事件流程通常需要至少一個圖,每個備用/例外流程也需要至少一個圖。有複雜計時或決策點的子流程,通常會需要幾個分開的圖;您也可以將太長,不容易用一個圖來表現的複雜流程簡化。
  • 逐步通過情境的事件流程來識別分析類別,找出負責必要行為的分析類別,以確保分析使用案例實現化提供了使用案例所需要的所有行為。
  • 在互動圖中說明分析類別之間互動。 互動圖也應該顯示系統與參與者的互動(互動應該開始於參與者,因為參與者一律會呼叫使用案例)。
  • 併入代表所用使用案例之控制類別的類別。 (每個延伸使用案例都使用個別的互動圖,只顯示延伸使用案例的變式行為。)

範例通訊圖

接收存放項目使用案例的通訊圖。

如果已在特定專案專用的準則中說明了特定分析機制和/或分析型樣,這些應該反映在責任的配置和產生的互動圖中。

說明責任
目的 說明從使用案例行為中識別出來之物件的類別責任。 

責任是關於物件可因應要求來提供之項目的敘述。責任會發展成設計類別的一或多項作業(通常是多項);它們的特性可以用下列方式來描述:

  • 物件可以執行的動作
  • 物件所維護且提供給其他物件的知識

每個分析類別都應該有幾項責任;只有一項責任的類別可能太簡單,責任在一打以上的類別已達責任的終極界限,可能應該分割成幾個類別。

所有物件當然都可以建立和刪除;除非在建立或刪除物件時,物件會執行某些特殊行為,否則不需要重述這些明顯的內容。(如果有特定關係存在,有些物件可能無法移除。)

尋找責任

責任是從互動圖中的訊息衍生而來。請針對每個訊息來檢查訊息所送往之物件的類別。如果責任還不存在,請建立一項新責任來提供所要求的行為。

其他責任會從非功能需求衍生而來。當您建立新的責任時,請檢查非功能需求,以瞭解是否有適用的相關需求。請加強責任的說明,或建立新責任來加以反映。

產生責任文件

責任的文件說明是簡短的責任名稱(最多幾個字)和簡短的說明(最多幾個句子)。說明會指出物件要執行什麼動作來履行責任,當呼叫這項責任時,會傳回什麼結果。

說明屬性和關聯
目的 定義分析類別所依賴的其他類別。
定義類別必須知道的其他分析類別中之事件。
定義分析類別負責維護的資訊。 

為了完成責任,類別經常會依賴其他類別來提供必要的行為。關聯用來說明跨類別的關係,可協助我們瞭解類別的耦合性;更深入瞭解類別耦合性及儘可能歸納耦合性,可協助我們建置更好、更具復原力的系統。

下列步驟定義類別的屬性及類別之間的耦合性:

定義屬性

類別利用屬性來儲存資訊。明確地說,當資訊符合下列條件時,便使用屬性:

  • 「依值」參照;也就是說,它只是資訊的值,而不是資訊的位置或物件 ID(其中的較重要者)。
  • 只有它所屬的物件「擁有」它;沒有其他物件會參照這項資訊。
  • 由只會取得、設定資訊,或簡單轉換資訊的作業來存取;這項資訊沒有提供值以外的「真正」行為。

另一方面,如果資訊有複雜行為、有兩個或更多物件共用它,或有兩個或更多物件「依參照」來傳遞它,這項資訊就應該建模成個別的類別。

屬性名稱應該是一個清楚指出屬性保留什麼資訊的名詞。

屬性的說明應該描述屬性將儲存什麼資訊;當屬性名稱足以明顯反映儲存的資訊時,它便是選用的。

屬性類型是屬性的簡式資料類型。例如 stringintegernumber

建立分析類別之間的關聯

首先,請研究將行為散佈於分析類別中所產生之互動圖中的鏈結。類別之間的鏈結表示兩個類別的物件必須彼此通訊來執行使用案例。我們開始設計系統之後,可以利用幾種方式來實現這些鏈結:

  • 物件可以有「廣域」範圍,這時系統中的任何物件都可以向它傳送訊息
  • 物件可以接收當作參數傳來的第二個物件,之後,它可以將訊息傳給被傳遞的物件。
  • 物件與訊息所送往的物件可以有永久關聯。
  • 在作業的範圍內,可以建立和毀損物件(也就是「暫時」物件),這些物件算是作業的「本端」物件。

不過,在類別「生命」初期的這個點仍太早,無法做這些決策:我們的資訊尚不足以進行有知識經驗基礎的決策。因此,我們在分析中建立關聯和聚集來代表(和「傳送」)必須在兩個類別的物件之間傳送的任何訊息。(聚集是一種特殊的關聯形式,它表示物件參與「整體/部分」的關係(請參閱技術:關聯技術:聚集))。

我們將在作業:類別設計中,修正這些關聯和聚集。

請每個類別各繪製一份類別圖來顯示每個類別與其他類別的關聯:

範例類別圖,顯示關聯和聚集

訂單項目系統組件的分析類別圖範例

請只將焦點放在實現使用案例所需要的關聯;除非因互動圖而需要,否則,請勿新增您覺得「可能」存在的關聯。

請提供關聯角色名稱和對應關係。

  • 角色名稱應該是一個名詞,表示所關聯的物件相對於關聯物件所扮演的角色。
  • 除非清楚證明是其他情況,否則,假設對應關係是 0..*(零對多)。對應關係 0 隱含這項關聯是選用的;請確定您有這個意圖;如果物件可能不存在,使用這項關聯的作業就必須相應地調整。
  • 您可以指定較窄的對應關係限制(如 3..8)。
  • 在對應關係範圍內,可以指定可能性。因此,如果對應關係是 0..*,在 85% 的情況中預期是 10 和 20,請記下它;在設計期間,這項資訊非常重要。比方說,如果要利用關聯式資料庫來實作持續性儲存庫,較窄的限制有助於組織更好的資料庫表格。

請寫下關聯的簡要說明來指示如何使用關聯,或關聯代表什麼關係。

說明分析類別之間的事件相依性

物件有時需要知道「目標」物件何時發生某項事件,而「目標」並不需要知道事件發生時會需要通知的所有物件。訂閱關聯便是這種事件通知相依性的簡單表示法,它使我們能夠用簡要的方式來表現這個相依性。

兩個物件之間的訂閱關聯表示,當被訂閱的物件發生特定事件時,訂閱起始端的物件會收到通知。訂閱關聯有一項條件,用來定義會使訂閱者收到通知的事件。如需詳細資訊,請參閱技術:訂閱關聯

訂閱關聯的條件應該透過抽象特性來表示,而不是透過它的特定屬性或作業來表示。在這個方式下,關聯起始端的物件會保持與所關聯之實體物件可能變動的內容無關。

在下列情況下,需要訂閱關聯:

  • 物件會受到另一物件內發生的事件影響
  • 必須建立新物件來處理某些事件,例如當發生錯誤時,必須建立一個新視窗來通知使用者
  • 物件需要知道另一個物件何時產生實例、何時變更或毀損

「被訂閱」的物件通常都是實體物件。實體物件通常是被動的資訊儲存庫,含有通常與其資訊儲存責任相關的任何行為。當實體物件有了改變,許多其他物件通常都需要得知。訂閱關聯使實體物件不需要知道所有這些其他物件,這些物件只是將它的意願「登錄」在實體物件中,當實體物件有了改變,它們就會獲得通知。

目前為止,這都只是「分析花招」:在設計中,我們必須定義這項通知如何確實運作。我們可能會購買一個通知架構,也可能需要自行設計和建置。但目前只需要指出有這種通知就行了。

關聯的方向顯示只有訂閱起始端的物件知道兩個物件之間的關係。訂閱的說明完全在訂閱起始端的物件內。相關聯的實體物件則是依照一般方式來定義,完全不考慮其他物件可能對它的活動感興趣。這也隱含了您可以在不變更所訂閱之物件的情況下,在模型中新增或移除訂閱起始端的物件。

核對分析使用案例實現化
目的 核對個別的分析使用案例實現化,以及識別一組含有一致關係的分析類別。 

分析使用案例實現化的開發是因為分析了特定使用案例。現在,必須核對個別分析使用案例實現化。請檢查分析類別和定義給各項分析使用案例實現化的支援關聯。請識別不一致的情況,加以解決,再移除任何重複情況。例如,兩項不同的分析使用案例實現化可能會包含在概念上相同的分析類別,但由於分析類別是不同的設計者所識別,因此可能用了不同的名稱。 
附註:如果軟體架構師將起始架構定義得很好,就可以大幅減少跨越多個分析使用案例實現化的重複情況(請參閱作業:架構分析)。

當核對模型元素時,請務必將它們的關係列入考量,這一點很重要。如果合併兩個類別,或一個類別取代另一個類別,請務必將原始類別的關係延伸到新類別中。

軟體架構師應該參與核對分析使用案例實現化 ,因為它需要對於商業環境的理解以及關於軟體架構和設計的先見之明,以便選取最能代表問題和解決方案的分析類別。

如需類別的相關資訊,請參閱技術:分析類別

限定分析機制
目的 識別分析類別所用的分析機制(如果有的話)。提供分析類別如何套用分析機制的其他資訊。 

這個步驟檢查每個已識別的分析類別所套用的分析機制。

如果分析類別使用一或多個分析機制,這時擷取的其他資訊會協助軟體架構師和設計者判斷所需要的架構設計機制功能。分析類別的實例數目、實例大小、存取頻率及預期的生命跨距,都是可協助設計者選取適當機制的重要內容。

請針對分析類別所用的每個分析機制來限定選取適當設計和實作機制所需考量的相關特性。這些會隨著機制類型而不同;請在適當之時(或仍有許多不確定之時)提供範圍。不同的架構機制會有不同的特性,因此,這項資訊純粹是描述性的,您只要依照擷取和表達資訊的需要來將它結構化就行了。在分析期間,這項資訊通常都很不確定,但它仍有擷取的價值,因為在發現更多資訊之後,可以修訂推測的預估。

類別及其相關特性所用的分析機制不需要正式擷取;圖中的附註或類別的延伸說明就足以表達資訊。類別發展到這時候的特性資訊極為流動不定,因此,重點是擷取預期的值,而不是拘泥於機制的定義形式。

範例

Flight 類別所用的持續性機制特性可以定義為:

精度:2 至 24 KB/航班

數量:最多 100,000

存取頻率

  • 建立/刪除:100/小時
  • 更新:3,000 更新/小時
  • 讀取:9,000 存取/小時

範例

Mission 類別所用的持續性機制特性可以定義為:

精度:2 至 3 KB/任務

數量:4

存取頻率

  • 建立/刪除:1/天
  • 更新:10/天
  • 讀取:100/小時
建立可追蹤性
目的 維護分析模型和其他模型之間的可追蹤性關係。 

專案的特定專案專用準則會指定分析模型元素所需要的可追蹤性。

比方說,如果使用者介面有個別的模型,將這個模型中的畫面或其他使用者介面元素追蹤到分析模型中的界限類別,就可能很有幫助。

審查結果
目的 確認分析物件符合在系統上設定的功能需求。
確認分析物件和互動一致。 

請在研討會結束時進行正式的審查,這既是一個同步點,也是作業:使用案例分析的結論。

請利用核對清單來處理這項作業的工作成果輸出。



詳細資訊