小心想過頭，使用案例建模的4項警訊

在《Use Case Driven Object Modeling With UML: A Practical Approach》書上所提出的十五條分析癱瘓警訊中，有四條是跟使用案例模式有關的警訊。

使用案例建模
所謂的使用案例模式，主要包含了使用案例圖（use case diagram）和使用案例敘述（use case narrative）。

使用者介面
假設，我們手上的專案是舊有系統改建的話，可以先行分析現存的使用者介面，迅速繪製出相關的使用案例圖，供使用者參考。

分析癱瘓警訊
此處我們將繼續討論十五條分析癱瘓警訊中，編號4到7這四條跟使用案例模式有關的警訊。

十大撰寫使用案例需避免的錯誤
使用案例易學難精，所以原著作者提到的十項需避免的錯誤，其實很值得我們參考與討論。使用案例建模

先澄清所謂的使用案例模式，主要包含了使用案例圖（use case diagram）和使用案例敘述（use case narrative），它在ICONIX方法中的位置如圖1所示。不過，使用案例敘述的內容以文字為主，所以它不屬於UML2的一部分，也因此並沒有標準的寫法。

圖1：使用案例模式


雖然，原著的章節安排是先談到模式領域的概念，接著才談到使用案例模式的概念，可是由交易樣式（transaction patterns）來看，ICONX方法似乎也可以先進行使用案例建模。實務上，先建構使用案例模式的正三角形法，如圖2所示。或者，使用案例模式與類別圖同時建構，如圖3的倒三角形法。這兩種方法皆可行，並沒有標準的作法。

圖2：正三角形法


圖3：倒三角形法


我則認為，或許把正三角形法和倒三角形法兩者合併起來，形成如圖4的循環星形法，可能會更貼近一般實務上的做法。

圖4：循環星形法


針對圖4的循環星形法，其分析步驟如下：

1.建構使用案例圖

2.編寫使用案例敘述

3.繪製類別圖

3.1找出類別（不含屬性及操作）

3.2建立類別之間的結合關係（不含個體數目）

4.建立循序圖（不含參數）

5.細緻循序圖（含參數）

6.細緻類別圖

6.1定出操作

6.2找出屬性

6.3定出個體數目使用者介面

仔細看到ICONIX方法中，在建構使用案例模式之前，可以先構思畫面雛型（GUI prototype），並且由此獲得有用的資訊，有助於繪製使用案例圖及撰寫使用案例敘述，如圖5所示。

圖5：畫面雛型


假設，我們手上的專案是舊有系統改建的話，可以先行分析現存的使用者介面，迅速繪製出相關的使用案例圖，供使用者參考。如果開發全新的系統，也可以一邊思考使用者介面，一邊繪製使用案例圖。譬如，參考圖6的舊系統畫面設計文件，我們可能繪製出如圖7的使用案例圖。

圖6：使用者介面

圖7：使用案例圖（局部）


其實，使用案例跟使用者介面，兩者之間的關係，一向是若即若離，要是能夠維持著「有點黏又不會太黏」的關係的話，那就再好不過了。不過，說起來很簡單，執行起來卻不是那麼容易。

由於，使用者介面的變動性極高，所以要是使用案例模式中涉及了太多使用者介面的細節時，也會導致使用案例模式受到變動的影響。因此，如何可以從畫面雛型獲取對建構使用案例模式有用的資訊，同時還讓兩者可以保持適度的距離，我想這是執行上最困難的地方。分析癱瘓警訊

此處我們將繼續討論十五條分析癱瘓警訊中，編號4到7這四條跟使用案例模式有關的警訊。

分析癱瘓警訊4 別嘗試寫使用案例，直到你知道使用者將做什麼為止。（Don’t try to write use case until you know what the users will actually be doing.）

我們通常採用使用案例模式來表達系統提供給外部使用者的系統服務，所以在不知道使用者對系統的真正期望之前，所構思出來的使用案例都只能算是預先設想，日後還是需要經過使用者的確認。

一般而言，專案剛開始的時候，誰都不清楚使用者對系統的真實期望為何，甚至很多時候，就連使用者自己都不一定清楚自己的想法。或者，即便使用者清楚自己的期望，但卻不一定能夠說明清楚。再或者，即便使用者清楚自己的期望，而且也認為自己已經跟系統分析師說得很清楚了，卻也無法保證系統分析師能夠正確解讀使用者的意圖。所以，該怎麼辦呢？

最好，使用者和系統分析師雙方，可以透過看得到的使用案例圖及使用案例敘述，溝通並澄清雙方腦海中的想法。也就是說，我們是透過不斷嘗試寫出使用案例的過程，才能夠真正知道使用者將做什麼，而不是直到知道了使用者將做什麼之後，才畫出使用案例圖，或者寫出使用案例敘述。

分析癱瘓警訊5 花費數週的時間，只是為了建造出精緻完善的使用案例模式。（Don’t spend weeks building elaborate, elegant use case models that you can’t design from.）

建構使用案例模式時，最好可以建造的快，也修正的快。切勿花太多時間想要繪製出完善的使用案例圖，或者編寫出精緻的使用案例敘述，因為這樣不僅會花費太多時間，也會為了投入太多而抗拒修改。在這種狀況和心態之下，很容易讓專案陷入分析癱瘓的窘境。

分析癱瘓警訊6 別浪費時間去擔心，倒底該採用包含關係、擴充關係、亦或是使用關係。（Don’t spin your wheels worrying about whether to use includes, extends, and/or uses.）

首先要澄清的是，「使用關係」（uses）是UML早期的名稱，這項關係後來改稱為「包含關係」（includes）。因此，在新版的UML2裡頭，使用案例之間已經沒有「使用關係」了。

其實，無論是包含關係或者是擴充關係，其目的都是為了想要重用使用案例。如果，我們發現數個使用案例中，有相同的部分，便可以將相同之處抽離出來，並且透過包含關係或是擴充關係，來連結原先的使用案例與抽離出來的新的使用案例。

透過包含關係，使用案例可以將其它使用案例內部的流程包含進來成為自己的流程。舉例來說，如果我們打電話向銀行的客服人員提出掛失信用卡的申請時，客服人員都會先核對來電者的身分。還有，如果我們去電要求更改帳單寄送地址時，客服人員也會先核對來電者身分，如圖8所示。

圖8：核對身分


在這樣的情況下，我們會發現掛失信用卡及更改帳單寄送地址這兩項使用案例的內部，有相同的流程，所以將相同的部分抽離出來，形成另一個稱為「核對身分」的新使用案例，如圖9所示。

圖9：包含關係


有些時候，在發生特定條件時，才會額外執行某一段流程。這種情況，不能使用包含關係，而是要用擴充關係。簡言之，包含關係一定會執行，而擴充關係則依條件而定。舉例來說，有些自動櫃員機在提款服務中，額外提供換百元鈔的擴充服務，如圖10所示。

圖10：加換百元鈔


由於，換百元鈔不是獨立的服務，它僅是提款流程中的一個擴充選項，所以我們可以使用擴充關係來表達這樣的設計，如圖11所示。

圖11：擴充關係


不過，我發現很多UML初學者過於濫用包含關係或擴充關係，或者喜歡對倒底該使用哪一種關係爭論不休。其實使用案例之間的關係跟類別之間的關係，兩者的特性恰好相反。類別鮮少單獨存在，但是使用案例卻可以單獨存在。過於濫用包含關係或擴充關係，反而很容易誤將使用案例切割過細，破壞了使用案例的完整性。

分析癱瘓警訊7 別把時間浪費在，冗長且複雜的使用案例樣板上頭。（Don’t waste time with long and involved use case templates.）

由於，使用案例敘述並非UML2標準的一部分，所以並沒有標準的使用案例敘述樣板。在網路上可以搜尋到一堆不同的使用案例敘述樣板，有的簡單，有的極為複雜。

最原始的使用案例敘述格式，其實只有兩個主要部分：其一是主要流程（basic flow），另一為替代流程（alternate flow）。主要流程記載使用案例正常執行的情況，替代流程則記載使用案例執行主要流程期間，可能發生的錯誤或特殊情況。 以圖12自動櫃員機的提款使用案例為例，提款的主要流程為：

1.自動櫃員機顯示歡迎畫面。

2.存戶插入晶片金融卡。

3.自動櫃員機請存戶輸入六位數字的晶片金融卡密碼。

4.存戶鍵入六位數字，並按下確認鍵。

5.自動櫃員機連線到銀行主機，確認晶片金融卡的密碼。

6.存戶身分確認之後，自動櫃員機顯示主選單。

7.存戶選擇提款服務。

8.自動櫃員機請存戶輸入低於三萬元的提款金額。

9.存戶鍵入提款金額，並按下確認鍵。

10.自動櫃員機連線到銀行主機，確認提款金額低於帳戶餘額。

11.自動櫃員機請銀行主機，執行扣款動作。

12.自動櫃員機退出晶片金融卡。

13.存戶取回晶片金融卡。

14.自動櫃員機吐出紙鈔。

15.存戶取走紙鈔。

圖12：提款


存戶在提款的過程中，可能會出現下述的替代流程：

4.a【密碼位數不符】—如果存戶輸入晶片金融卡的密碼位數未滿或多於六位數字的話，自動櫃員機將請存戶重新鍵入。

5.a【密碼錯誤】—如果存戶輸入晶片金融卡的密碼錯誤次數累積三次以內，自動櫃員機將請存戶重新輸入密碼。若是密碼輸入錯誤超過三次，自動櫃員機不退回晶片金融卡，並且請存戶使用緊急電話通知銀行人員。

9.a【提款金額過大】—如果存戶提款金額大於三萬元時，自動櫃員機將請存戶重新鍵入低於三萬元的提領金額。

9.b【非千元倍數】—如果存戶提款金額非千元整數時，自動櫃員機將請存戶重新鍵入千元整數的提領金額。

10.a【餘額不足】—如果存戶提款金額高於帳戶餘額時，自動櫃員機將請存戶重新鍵入低於帳戶餘額的提領金額。

12.a【取卡逾時】—如果存戶在十秒內未取回晶片金融卡，自動櫃員機將提醒存戶盡速取回晶片金融卡。

14.a【取鈔逾時】—如果存戶在十秒內未取走紙鈔，自動櫃員機將提醒存戶盡速取回紙鈔。十大撰寫使用案例需避免的錯誤

使用案例敘述不是UML2標準的一部分，這是它的壞處，但同時也是它的好處。因為它不是標準的一部分，所以並沒有標準的格式以及制式的寫法。不同的觀點、不同的顆粒度、不同的細緻度、不同的語態、不同的用途等等，這些都會讓使用案例敘述大不相同，但也因此百花齊放、創意十足。

使用案例易學難精，所以原著作者提到的十項需避免的錯誤，其實很值得我們參考與討論。

1.編寫功能性需求，而不是編寫使用腳本。（Write functional requirements instead of usage scenario text.）

簡單來說，一項「功能性需求」（functional requirement）是系統該達成的一個事項，而「使用腳本」（usage scenario text）則是一段敘述，說明使用者使用系統以獲得某項結果所經歷的過程。

以自動櫃員機為例，我們如果在文件中寫著「自動櫃員機將具備提款功能」這是功能性需求的描述。使用腳本就不是一句話這麼簡單了，而是像一段散文式的描述存戶與自動櫃員機互動的過程，像是：

「存戶將晶片金融卡插入自動櫃員機，並且鍵入六位數的密碼。自動櫃員機連線到銀行主機，以便驗證晶片金融卡密碼的正確性。待密碼驗證通過後，存戶輸入低於三萬元且為千元倍數的提款金額。自動櫃員機確認帳戶餘額足以支付提款金額後，將扣款、並且退回晶片金融卡、以及吐出紙鈔。存戶在取回晶片金融卡以及紙鈔之後，完成提款動作。」

很多時候，功能性需求與使用案例不會單純的一對一對應。有時候，一個功能性需求會涉及數個使用案例；或者，一個使用案例同時達成數個功能性需求，也是很常見的狀況。

2.描述屬性與方法，而不是描述使用情況。（Describe attributes and methods rather than usage.）

使用案例關注於使用者與系統之間的互動，而不是系統內部的運作細節，所以不該過於關注在物件的屬性與方法上頭。

3.編寫使用案例敘述，過於簡潔。（Write the use cases too tersely.）

使用案例敘述過於繁瑣，或者過於簡潔，都不是件好事。敘述內容若是太過繁瑣，可能會因為暴露太多細節，因而容易迷失，錯過了重點資訊。不過，要是敘述內容過於簡潔的話，也會成為沒有用的資訊，因為可能連重點資訊都被省略了。 延續前述自動櫃員機的範例，如果提款使用案例敘述簡潔如下，也不是個好的描述：

「存戶插入晶片金融卡，並且輸入密碼。自動櫃員機驗證密碼，並且扣款、退卡、吐鈔。」

4.強迫自己在撰寫使用案例敘述時，完全脫離使用者介面。（Divorce yourself completely from the user interface.）


其實，在撰寫使用案例敘述時，要想將使用者介面完完全全從腦海中剔除，也是極難做到的吧。在我專研UML十多年的經驗中，遇到最多的情況反而是，開發人員太過於依賴使用者介面，以致於寫出來的使用案例敘述內容，根本是畫面操作的過程，而不是使用者與系統的互動過程。

5.避免給邊界物件明確的稱呼。（Avoid explicit names for your boundary objects.）


邊界物件（boundary object）是穩健分析（robustness analysis）裡頭的概念，同時也是使用案例創始人Ivar Jacobson先生所提出來的概念。顧名思義，邊界物件主要在處理使用者與系統之間的溝通，所有來自於系統外部對內的訊息都由邊界物件所承接，而所有來自於系統內部對外的訊息，也都要經過邊界物件。邊界物件的概念我們在穩健分析小節中，才會細談，此處就不再深入細究了。

老實說，我不理解原著作者這一條錯誤的原因，如果讀友們有想到什麼的話，還請不吝來信與我分享。再者，如果我們沒有採用邊界物件的概念的話，似乎也就不會有這一項錯誤的困擾。

不過，我聯想到的是另一個相似的狀況，如果在使用案例敘述中出現物件時，該不該給這個物件明確的名稱？我所謂明確的名稱是指，該物件在整個專案中，唯一且一致的名稱。

舉例來說，如果我們在使用案例敘述中出現了「帳戶」（account）這個物件，那在整個專案中，就都用「帳戶」（account）。倘若出現了「戶頭」或者是「存款帳戶」（savings account），這些都是不同的物件。

當時我遇到的狀況是，專案一開始，系統分析師在某些使用案例敘述中使用「帳戶」，同時也在另外一些使用案例敘述中使用「戶頭」這個字眼，但其實兩者都是相同的概念。

像這類在使用案例敘述中，出現專業字眼時，需不需要強迫一致呢？再者，在類別圖或其他文件中，出現專業字眼時，需不需與使用案例中的名稱一致呢？我們當時的解決之道是，針對這些專業術語編寫「資料字典」（data dictionary），將這些字眼一致化。

即便是現在，我還是認為針對這些專業術語，可以明確就明確，可以一致就一致，至今也沒有因此而遭遇到什麼樣的問題。所以，針對原著作者說別給邊界物件明確的名稱，實在是不解為啥？

6.不以使用者的角度撰寫使用案例敘述，而且還使用被動語態。（Write using a perspective other than the user’s, in passive voice.）

也就是說，一份好的使用案例敘述，最好可以以使用者的角度來撰寫，並且最好可以使用主動語態。不過，我們要先釐清一件事情，所謂以使用者的角度來撰寫使用案例敘述，並不是真的要求使用者自行撰寫使用案例敘述，而是在系統分析師訪談使用者之後，請系統分析師試著站在使用者的角度，或者把自己想像成使用者，來整理編撰使用案例敘述。

相較於使用者的角度，我認為開發人員的角度也是很重要的。而且既然系統分析師才是使用案例的真正作者，實在很難要系統分析師完全脫離開發人員的觀點。 使用者的角度和開發人員的角度，其實還是會有不同，而且通常開發人員的角度會曝露出較多的細節。

舉例來說，存戶是自動櫃員機的使用者，若是單純以存戶的角度來繪製使用案例圖的話，可能會得到如圖13。

圖13：使用者的觀點


對於使用者而言，僅關心該如何跟系統互動，以便獲得期望中的服務或產出。但是，對於開發人員而言，除了關心使用者與系統之間的互動之外，同時還會關心系統在提供服務的過程中，是否有其他的連線系統或者硬體設備。因此，開發人員觀點下的自動櫃員機使用案例圖，可能會涵蓋更多的資訊，如圖14表達出與自動櫃員機連線的銀行主機。或者，如圖15將提款和查詢餘額中，相同的登入動作抽離出來，成為另一個新的使用案例。

圖14：開發人員的觀點


圖15：登入


7.僅描述使用者互動的情況，卻忽略了系統的反應。（Describe only user interactions; ignore system responses.）

傳統單欄的散文式寫法，確實很容易忽略系統的反應，如果改用兩欄式的寫法，比較能夠突顯系統的反應。在1993年《The Smalltalk Report》雜誌中，一篇名為〈Designing Scenarios: Making the Case for a Use Case〉的文章裡，作者Rebecca Wirfs-Brock提出了A-S對話式（Actor/System Conversation）的兩欄式寫法，將參與者動作（actor action）與系統反應（system response）分列於版面的左右兩方。

傳統單欄的散文式寫法，在閱讀上以及理解上，都略遜於兩欄式的寫法。兩欄式寫法可以更清楚表達，使用者與系統雙方的職責。實務上，系統分析師可能會在系統處添加一些重要資訊，如果混在單欄裡，很容易忽略了這些重要資訊。兩欄式的寫法最大的缺點是，太佔版面了。

以自動櫃員機的提款使用案例敘述為例，兩欄式的寫法如表16。

圖16：兩欄式使用案例敘述


8.遺漏了替代流程。（Omit text for alternative courses of action.）

其實，使用案例創始人Ivar Jacobson先生，首次提出的使用案例敘述就只有主要流程與替代流程，後續經由其他學者發揚光大之後，才百花齊放，提出各種風格的使用案例敘述。

雖說，替代流程跟主要流程同等重要，但在開發順序上，我還是建議採用循環式的編寫順序。

也就是說，第一輪先編寫主要流程，第二輪才編寫替代流程，不在同一時間撰寫兩者。因為替代流程依賴主要流程而生，如果主要流程有誤，那麼替代流程也可能會受到影響。

9.沒有將焦點放置在使用案例內部，而是關注其他，像是如何達到這一點（前置條件）或是之後會發生什麼事情（後置條件）之類的事情上頭。（Focus on something other than what's “inside” a use case, such as how you get there (precondition) or what happens afterward (postcondition).）


其實，我覺得，除了使用案例內部的主要流程與替代流程外，許多其他的資訊也都很重要。只是在編寫順序和版面上，需要多加注意，像是前面提到優先撰寫主要流程，替代流程次之。

再者，其他像是執行使用案例的前置條件（precondition）及後置條件（postcondition），這些資訊，我認為也很重要。只是在編寫時間安排上，不放在首輪，而且記得將它們獨立出來，別將一大堆細節資訊混在流程敘述中，就可以了。

10.花費一個月的時間，只是為了決定該採用包含關係或是擴充關係。（Spend a month deciding whether to use includes or extends.）

在圖面上多一個圖示，就多花費一項成本，無論看得到佔版面的成本，還是看不到的溝通成本、學習成本。

所以，如果可以不用這些關係，那幹嘛要用。UML初學者很容易因為學了這些概念，就好像以為使用案例之間一定會有包含關係或擴充關係。其實，不盡然，有時候用了反而是濫用或誤用。

撰寫使用案例模式是ICONIX開發方法的第二步驟，下一期要進入第三個步驟，也就是穩健分析，透過穩健圖（robustness diagram）來決定參與使用案例的物件。在穩健分析中，會依照物件用途，將物件分成三類，包括邊界物件（boundary object）、控制物件（control object）和實體物件（entity object），這可是使用案例創始人Ivar Jacobson，在1992年書中提出來的一種建構分析模式的技術。