第3章、UML 圖形間相關性之分析
3.2 跨階段產物間相關性之分析
3.2.1 from Requirement Capturing to Analysis
從 requirement capturing 階段進到 analysis 階段時，主要工作之一是藉由每一 個 use case 的 detail specification 來產生 analysis 相對應的 collaboration diagram。
每一個 collaboration diagram 代表著一個 use case 裡定義的 scenario，此 diagram 的主要組成元素為 analysis classes 以及該 analysis class 參與此活動的 responsibilities，以 Pay Invoice 這個 use case 為例，圖 3-4 為 Pay Invoice use case 的 basic path 的 collaboration diagram。
任一 collaboration diagram 的 analysis class 與其 responsibility 都是依據 use case scenario 的 specification 來定義的，因此兩者是一一對應的，然而 scenario 的執行流程是以敘述式的語句來表達，這些句子以口語敘述，因此會夾雜著多餘 的語詞如 therefore、later 等，開發人員不易從中判斷需用哪些 analysis classes 及 responsibilities 來表示其合作關係，因此有必要定義一種新的 use case 表示方式 以幫助開發人員易於定義 analysis class 及 responsibility，最好使其能做到一一對 應。
Collaboration diagram 中的每一個 message 代表一個動作，而 analysis class 主要有 boundary class、entity class 及 control class 三種，因此將圖 3-1 的 scenario 改寫為圖 3-5 的形式，表格的欄(Column)代表的是 actor 或是 system，列(Row) 中敘述為所做的動作，每個動作代表一個 responsibility，動作前的數字則是用來 標明動作的順序，巢狀化的動作(nested actions)則以階層式的 sequence number 來 表示。表格內只記載了 flow of event 中的重要動作，在 actor 行內的動作代表是 此 actor 對 system 輸入的資料，而在 system 行內的動作代表此系統所必須負責完 成的動作。表格中的動作可分為下列兩種：
1. 一般性的動作，即由(動詞+名詞)或(動詞+片語)的形式所構成的 responsibility，如 Pay Invoice 範例中的 Get invoice、Generate payment request，這種類型的動作其本身就是一個 responsibility。
2. Loop, branch 等於流程控制有關的動作，如 Pay Invoice 範例中的 if (there is enough money in the buyer’s account)
then schedule payment for this invoice
這種與流程控制有關的動作是由 condition 與 responsibility 所組成，在 這個例子中的 condition 條件是必須滿足”there is enough money in the buyer’s account”，才會啟動其 responsibility (即 schedule payment for this invoice)。
圖 3-4 Pay Invoice use case—basic path 的 collaboration diagram
Buyer System
1. Display invoice list 2. Select an invoice
3. Check invoice to make sure goods were received 3.1 Get invoice
3.2 Get Order Confirmation of this invoice 4. Schedule invoice for payment
5. Schedule payment
5.1 Check account
5.2 if (there is enough money in the buyer’s account) then generate a payment request
5.3 set the status of this invoice to “scheduled”
5.4 send payment transaction to bank 5.5 set the status of this invoice to “paid”
圖 3-5 Pay Invoice use case—basic path 的 scenario 表格
collaboration diagram 的 entity class 代表系統裡 long-lived 且 persistent 的資 料，以名詞的形式描述於 scenario 中，因此 entity class 的名稱可以藉由參考 scenario 裡的重要名詞而得到，為了讓系統可以自動檢查 entity class 名稱是否來 自於 scenario 裡的名詞，使用者可在表格內標示重要的名詞，這些名詞將做為 entity class 名稱的 candidate。圖 3-6 以粗體字的方式標示出 Use Case：Pay Invoice---Basic Path 表格內的重要名詞。
Buyer System
1. Display invoice list 2. Select an invoice
3. Check invoice to make sure goods were received 3.1 Get invoice
3.2 Get Order Confirmation of this invoice 4. Schedule invoice for payment
5. Schedule payment
5.1 Check account
5.2 if (there is enough money in the buyer’s account) then generate a payment request
5.3 set the status of this invoice to “scheduled”
5.4 send payment transaction to bank 5.5 set the status of this invoice to “paid”
圖 3-6 Pay Invoice use case—basic path 的 scenario 表格(標記名詞)
另外由圖 3-6 的 step3.2 可發現 invoice 的內容需有 order number，才能檢查 此貨物是否已送達，因此在表格旁加一欄來做註解如圖 3-7 所示，註解內亦標示 了重要名詞，對未來定義 entity class 的 attribute 有重要助益。
Buyer System U/*Comment*/U
1. Display invoice list
2. Select an invoice
3. Check invoice to make sure goods were received 3.1 Get invoice
3.2 Get Order Confirmation of this invoice
Invoice should have order number, good lists, total price, seller’s account and a status field.
Order Confirmation should have order number, good lists, total price, delivery information and buyer’s personal information.
4. Schedule invoice for payment
5. Schedule payment
5.1 Check account
5.2 if (there is enough money in the buyer’s account) then generate a payment request
5.3 set the status of this invoice to “scheduled”
5.4 send payment transaction to bank 5.5 set the status of this invoice to “paid”
Payment request should have seller’s account, buyer’s account, amount of money, and scheduled date.
圖 3-7 Pay Invoice use case—basic path 的 scenario 表格(加入註解)
Boundary class 負責 actor 與系統的溝通，在 scenario 的表格中若出現 actor 與 system 間有緊鄰著的動作出現(如 Pay Invoice---Basic Path 中的”2. Select an invoice 與”3. Check invoice”，或” 4. Schedule invoice for payment”與”5. Schedule payment”)，則代表為有 actor 與 system 執行 I/O 的動作出現，必須藉 boundary class 作為兩者間的溝通介面，I/O 動作有輸出後接著輸入，及只有輸出兩種，此 boundary class 的 responsibility 必須能執行此動作。預先定義一些 I/O 動作類別的 動詞將有助於判斷該 responsibility 是否為屬於 boundary class 的 responsibility，這 些動詞包含了 system to actor 與 actor to system 兩類，圖 3-8 列出幾個常用的 I/O
第三類 analysis class 為 control class，control class 所扮演的是 controller、
coordinator 或是執行複雜動作的 worker 等角色，系統中的所有 coordination、
transaction、sequencing 以及對其他 object 的控制都是 control class 的
responsibility。由於使用者對於 control class 的產生數量以及每個 control class 的 任務分配並不一定，所以無法藉由參考 scenario 來決定 control class 的數量與名 稱，但從例子中觀察得知若是 scenario 裡的 responsibility 有具有巢狀的形式，則 root 的那個 responsibility 必定是 control class 的 responsibility。
3.2.2 from Analysis to Design
從 analysis 階段進入 design 階段的主要工作是將上個階段的 analysis class 以 design class 來實現、參考 analysis package 以產生 design subsystem、產生各 use case scenario 的 sequence diagram 以描述 design object 互動的關係、定義系統架構並以 deployment diagram 來表示此架構。
由於 sequence diagram 也是代表一 use case scenario 之 object 互動順序關係，
因此與上階段的 collaboration diagram 間有密切關係；analysis class 在設計階段也
需出現，因此兩階段間之 class diagram 也有關係存在。
以下分別由 sequence diagram 及 class diagram 為出發點討論此兩階段產物間 的相關性：
I. Sequence diagram
Sequence diagram 由 design objects 及 messages 兩個元素所組成，圖 3-9 是 pay invoice 的 basic path 的 sequence diagram，sequence diagram 上共有九 個 design objects，這些 design objects 所屬的 design class 是為了要實現 analysis class 的 responsibility 而產生，比較圖 3-9 與圖 3-4 可發現，design class 的數量比 analysis class 的數量多，如多了處理 invoice 的”Invoice Manager”與處理 order confirmation 的”OrderConfirmation Manager”，這兩個 新增的 design class 都是屬於 container class 的類型。這種衍伸結果可知一個 analysis class 會在 design 階段由一個以上的 design classes 所實現，其中有一 個 design class 會繼承原先 analysis class 的名稱以及 responsibility，其他新產 生的 design class 則各有其產生的原因，詳細說明如下。
: Buy er : Pay ment
schedule inv oice f or pay ment select an inv oice checkInv oice( )
getInv oice( )
get( )
getConf irmationInf o( )
get( )
schedulePay ment( )
*[enough money ]: new( ) setStatus(scheduled)
setStatus(scheduled)
send pay ment transaction setStatus(paid)
setStatus(paid)
CheckAccount( )
圖 3-9 Pay Invoice use case—basic path 的 sequence diagram
Sequence diagram 中 design object 所屬的 design class 有部分可以追溯回上階 段的 analysis class，另一部分則是在本階段新增而無法追溯回上個階段的，首先 探討 design class 的產生來源，可先將 design class 分為下列三類：
1. primary design class：可直接 trace 回 analysis class 的 design class 稱為 primary design class。每個 analysis class 都會在 design 階段產生一個 primary design class，這個 primary design class 必須負責實現 analysis class 的 attribute 與 responsibility，例如圖 3-9 中的 Payment Requirement UI、Order Handler 等。Primary design class 的名稱必須與其所追溯回的 analysis class 名稱相同。
2. 輔助 primary design class 的 design class：由於 primary design class 之 responsibility 所採用的 algorithm 過於複雜或是不同 data type 之間的轉 換等原因而產生輔助性質的 design class。
3. 採用既有的 middleware 或 system-software 時，為了將其中的資料型態 轉換為本系統使用的資料型態，或是為了系統可攜性(portability)而加入 的 adaptor classes：這些 design class 是來自於轉換或協調 middleware 或 system-software subsystem 與發展中的系統之差異，或是為了提高系統 可攜性與相容性、降低對於系統外部 underlying infrastructure 的依存度 而產生。
在 analysis 階段有三種類型的 analysis class，分別是 boundary class、
control class、與 entity class，以下將分別敘述在 design 階段實現三種不同類 型 analysis class 所產生的輔助性 design class：
1. UControl classU：具有以下兩種輔助性質的design class。
U(1)為了輔助primary design class完成operation所產生的design class。 Primary design class 中有些較複雜的 responsibilities，將分解為多個
增 design class 的 operation 來完成。
例如某個 control class 具有將一篇文章中某些特定字元出現次數編碼為 Huffman code 的 responsibility，此 responsibility 必須同時考量計算的效能與 相關演算法的使用，若直接將這個複雜的功能放進原本的 primary design class，容易造成實作與維護時的複雜度；為了減少 class 的複雜度，使用者 可能會新增一個負責做 Huffman coding 處理的 design class，並藉由 primary design class 呼叫此新增的 design class 所提供的 operation 來完成這個複雜的 responsibility。
U(2)為了協調兩個design class工作而產生的coordinator class。
這種 design class 的產生情況通常是因為 remote procedure call 或分散式 運算，多個 design classes 被 deploy 到不同的 nodes，此時需要產生新的 design class 負責 coordinate 的工作。例如本地端的 design class A 須要藉由溝通互 動與另一個網路節點上的 design class B 共同完成某一個 responsibility，
design class A 必須等待 design class B 完成某項工作後傳遞資料回來才能繼 續執行下去，這時候使用者可以選擇在本地端新增一個 coordinator class 來 觀測不同節點上 design class 目前的工作處理情形。產生 coordinator class 的 優點是當遠端的 design class 執行發生異常狀態時，本地端的 design class A 不會無謂地一直等待，而是透過 coordinator class 的輔助來提供 design class A 繼續執行所需的預設資料，或是提供 design class A 另一個可以獲得資料的 來源。
2. UEntity classU：具有以下兩種輔助性質的design class。
U(1)輔助管理多筆資料的container class。
依照單一 transaction 中屬於某 entity class 的 object 在系統中所出現的數 量可將 entity classes 分為兩類。
第ㄧ種類型的 entity class 是單一 transaction 可明確指定單一特定 object
的 entity class，這種類型的 object 通常用 object ID 來查詢，而且只會找到一 個 object，例如報表或是提交的表單。
第二種類型的 entity class 則是在單一 transaction 中需要由多個 objects 選取符合指定條件的 objects，通常用數個 attribute 的集合來查詢這類 objects，查詢結果可為多個 objects，例如資料庫中的訂單紀錄或是會員資 料。這種類型的 entity class 需要輔助性質的 container class 來負責查詢的工 作。在 Pay Invoice 範例中的 Invoice 就是這種類型的 entity class，所以必須 產生 container class “Invoice Manager”。
使用者進入 design 階段時，依照這兩種不同的特性來產生 entity class 的輔助性 container class，負責做 object 的 select 與查詢。
例如若有一個第二種類型的 entity class 代表客戶的訂單資料，因為訂單 資料具有很多個資料欄位，查詢時常常需要對各個欄位設定條件以查詢到符 合的資料，此時使用者就必須產生一個從事查詢客戶訂單工作的資料庫 container class，所有的查詢都必須經由這個 container class 才能完成。
U(2)為了實現attribute type的design class。
因為 entity class 或 container class 的 attribute 可能是較複雜的資料結構，
使用者所使用的程式語言本身並不支援, 所以使用者必須新建立 design class 來實現此 attribute type。
同樣重覆上個例子，訂單資料的 entity class 其資料欄位除了單純的訂單 編號、客戶姓名、送貨地址等字串類型的欄位資料外，也可能會有表列式(list)
同樣重覆上個例子，訂單資料的 entity class 其資料欄位除了單純的訂單 編號、客戶姓名、送貨地址等字串類型的欄位資料外，也可能會有表列式(list)