Use case modeling

Use case diagram

在UML中是利用使用個案圖(Use Case Diagram)來描述系統的主要的使用個案(Use Case)及其對應的使用者，使用個案圖有幾個重要的元件：使用個案(Use Case)、行為者(Actor)。

Use case

使用個案(Use Case)就是系統的主要功能(情境)，然而，使用個案的觀點在於系統應該提供什麼功能，而不是系統如何提供這些功能。系統如何提供這些功能可以用Sequence Diagram來表達。

通常一個使用個案圖只會有3到9個使用個案。一個使用個案是一個使用情境而不是一個功能或一個單一需求，例如，選課是個使用個案，選課的情境中需要看到選課清單，需要加選課程，需要退選課程，以這樣的狀況就不應該將選課分為三個不同的使用個案，而是將看到選課清單，需要加選課程，需要退選課程列為選課中的三個步驟。在這個階段，需要知道的是系統有哪些重要的行為者，他們使用系統的情境為何，所以，不應該列出系統的基本功能(如:登入、登出、修改個人資料)。一般而言，當系統超過9個個案的話，就應該考慮將系統切割為不同的系統了(細節請參考Ashrafi & Ashrafi, 2009,pp.233-238)。

Actor

每個使用個案只能有一個主要行為者(primary actor)，可以有多個次要行為者(secondary actor / supporting actor)，行為者是個角色不一定是人，也有可能是另一個系統(細節請參考Ashrafi & Ashrafi, 2009,pp.187-188)。每一個使用個案只會有一個主要行為者，如果發現有超過一個主要行為者，而且不同行為者扮演的角色一樣(如:組長和組員在「互評」及「查詢互評結果」中的角色一樣)，則以一般化來表示 (如:組員是組長的一般化) (細節請參考Ashrafi & Ashrafi, 2009, pp.223-224)。有時候，我們會分不清楚角色與身份，例如，櫃台也可以為自己的親朋好友購買產品，但是，這時候，他或她的角色便是購買者，而不是櫃台。就像有些老師也可能同時是學校的學生，每個人都有可能扮演不同的角色，當扮演不同角色時，就會有對應的使用個案。

常犯的錯誤

• 將行為者分為會員、非會員、管理者(或者分為使用者、管理者)，這樣的分法似乎沒什麼錯，但是卻誤會了行為者的意義，因為行為者主要談的是角色，要由使用者扮演的角色去分析，所以，以房屋買賣為例，應該分為：購屋者、售屋者、仲介，有一些人會說，購屋者也可以是售屋者，然而，行為者談的是角色，是每一個使用個案所對應的角色，售屋者的角色是刊登房屋資訊，購屋者則是利用購屋需求尋找房屋，他們在買賣的過程中提供及需要不同的資訊，所以，不應該將購屋者及售屋者混為會員(或使用者)。
• 另一個常會混淆的觀念是使用個案間的相依關係：包含(Include)、擴充(Extend)、一般化(Generalization)，包含的個案的完成是要靠被包含的個案來達成，通常是將不同使用個案中共享的部份獨立出來，以包含來表示；通常擴充的使用個案是增加原有使用個案的功能，例如：「刷卡」是擴充「結帳」，被擴充的個案(如:「結帳」)本身就是個完整的使用個案；而一般化則是表示一個新的使用個案是原有的使用個案的一個變種，表示改寫或新增一般化使用個案中的步驟 (細節請參考Ashrafi & Ashrafi, 2009,pp.225-232)。

延伸閱讀

• Fundamental UML Use Case Diagram with Astah (5:06)
  • Use case diagram基本概念
  • 如何使用Astah畫Use case diagram
• 3.02_Modeling Use Case Elements
  • Use case diagram基本概念 (3:27)
• 3.03_A Use Case Diagram for an ATM (3:49)
  • Use case diagram範例
• 3.04_The ''include'' Dependency (4:18)
• 3.05_The ‘’extend‘’ Dependency (3:53)
• 3.06_Generalization (4:40)

Use case description

在使用個案圖之外，也必須針對每一個使用個案進行使用個案情境說明，說明各使用個案之名稱、行為者、目標、前提(pre-condition)、結束狀態(post-condition)、系列事件(正常程序、替代程序與例外程序)。如果有多個行為者，必須註明主要行為者。使用個案的前提一般是註明啟動此使用個案的條件，如：學生必須是在學狀態才可以選課，或者，賣家已經將產品下架及登錄買家，買家才可對賣家進行評分。如果沒有前提，可以留空白。使用個案的結束狀態一般是註明完成此使用個案之後的狀態，如：學生完成網路初選。系列事件是在描述使用者與系統的互動，通常是顧客所進行的動作(如:輸入哪些資料)及所應得到的訊息(如:應該看到什麼樣的計算結果，或得到資料的欄位)，在使用個案中應注重所需要的資料(細節請參考Ashrafi & Ashrafi, 2009,pp.209-223)。

其實不使用替代程序與例外程序也是可以表達整個流程，只是，使用替代程序與例外程序會比較容易閱讀。一般而言，替代程序與例外程序概念類似，然而，完成替代程序可以達到目標，但是，例外程序則不能，例如遇到存貨不足無法購買出版品的處理方式。通常完成替代程序與例外程序後會回到正常程序的下一個步驟，若不回到正常程序，則會在最後說明「完成後結束」或接下來的步驟，如：「完成後執行步驟6」。

Use case其實有不同的寫法 ，不同的教科書採用不同的做法，各有優缺點，未來就請大家依照自己的專題指導老師習慣的想法來寫。一般而言，有三種寫法 (詳參:http://www.wirfs-brock.com/PDFs/Art_of_Writing_Use_Cases.pdf) 。第一種寫法是述說式的 (Narrative)，是以寫文章的方式寫。第二種做法是情境式的 (Scenario)，(Ashrafi & Ashrafi (2009)及大部分的教科書是採取這種方式)，會一個步驟一個步驟寫，每個步驟就是使用者所採取的動作或預期的結果。第三種做法是對話式的 (Conversation) (Satzinger, et al (2012)是以這種方式)，會描述使用者所採取的動作及系統的處理動作及系統提供的反應。

第二種做法又會因為步驟的複雜程度，在處理替代流程(alternative flow)或例外流程(exception)時又有不同的表達方式。

• 以下的表達方式，跟Ashrafi & Ashrafi, 2009的做法類似，但alternative flow的表達方式稍微不同，建議大家依照需求的複雜程度，選擇各位認為容易理解的方式，如果怕別人看不懂，請附上參考資料來源。
  • 第一種做法: 會列出基本流程，當部分步驟(如:第四步)會有替代流程時，第一個替代流程就編為4a，第二個替代流程就編為4b，如果在4a裡有多個步驟就編為4a1,4a2。當替代流程執行完，除非有特別標示，否則就是繼續執行下一個步驟 (如: 5) (詳參: http://pmblog.accompa.com/2009/10/08/use-case-template-example-requirements-management-basics/)
  • 第二種做法，與第一種做法類似，會列出基本流程，每個替代流程會被分割，差別在於如果在4a裡有多個步驟時，因為都是放在4a裡，就只編1, 2。當替代流程執行完，除非有特別標示，否則就是繼續執行下一個步驟 (如: 5) (詳參: http://www.dummies.com/WileyCDA//how-to/content/how-to-create-use-case-description-for-your-busine.html)。
  • 第三種做法，與前兩種類似，只是每個替代流程會被分割 (詳參: http://www.usability.gov/how-to-and-tools/methods/use-cases.html )。
• 當替代流程非常複雜的時候，上面的做法會很難看得懂，所以，有些人就認為應該將情境個別分開寫，這樣的寫法比較接近使用者的觀點(類似user story)及測試的觀點，但是，對於開發者來說就比較難看到全貌，會需要利用活動圖來描述整個使用個案 (詳參: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/use_case_spec_CD5DD9B1.html)
  • 也可以用另一種表達方式，與前面做法不同的是在基本流程中註記分支點 (詳參: http://www.batimes.com/articles/use-case-goals-scenarios-and-flows.html)。