Software System Analysis and Design | 4

用例的概念

用例（use case），或使用案例、用況，是軟件工程或系統工程中對系統如何反應外界請求的描述，是一種經過用戶的使用場景來獲取需求的技術。每一個用例提供了一個或多個場景，該場景說明了系統是如何和最終用戶或其它系統互動，也就是誰能夠用系統作什麼，從而得到一個明確的業務目標。編寫用例時要避免使用技術術語，而應該用最終用戶或者領域專家的語言。用例通常是由軟件開發者和最終用戶共同創做的。

用例和場景的關係？什麼是主場景或 happy path？

• 用例是是一組相關的成功和失敗的場景（success and failure scenarios），這些場景是用於描述一個actor使用系統去support一個目標（goal）。
• 主成功場景或happy path是用例從觸發事件開始，一步一步執行，最終知足用例利益的步驟集合。

• 主成功場景應該包括如下信息：

  • 兩個執行者之間的交互。如，用戶提交了訂單。
  • 爲保證主成功場景得以繼續的確認。如，系統確認用戶密碼。
  • 主成功場景推動過程當中的內部變化。如，系統扣除用戶帳戶餘額。

用例有哪些形式？

• 摘要：簡潔的一段式概要，一般用於主成功場景。在早期需求分析過程當中，爲快速瞭解主題和範圍，一般花費少許時間快速編寫。
• 非正式形式：非正式的段落格式，用幾個段落覆蓋不一樣的場景。
• 詳述：詳細編寫全部步驟和各類變化，同時具備補充部分，如前置條件和成功保證。肯定並以摘要形式編寫大量用例後，在第一次需求討論中，詳細地編寫其中少許的具備重要架構意義和高價值的用例。

對於複雜業務，爲何編制完整用例很是難？

複雜業務的場景較多，場景較爲複雜。在前期的考慮中，很難不遺漏一些業務條件和需求，且這些需求條件還可能發生變化。因此對於複雜業務，編制完整用例且不遺漏情景、良好地安排每一個場景、場景內元素地關係很是困難。

什麼是用例圖？

用例圖是描述系統與其餘外部系統以及用戶之間交互的圖形，即用例圖描述了誰將使用
系統，用戶但願以什麼方式與系統交互。用例圖肯定系統中所包含的參與者、用例和二者之間
的對應關係， 它描述的是關於系統功能的一個概述， 描述軟件應具有哪些功能模塊以及這些模
塊之間的調用關係。 用例圖包含了用例和參與者， 用例之間用關聯來鏈接以求把系統的整個結
構和功能反映給非技術人員（一般是軟件的用戶）。

用例圖的基本符號與元素？

• 參與者：表示與您的應用程序或系統進行交互的用戶、組織或外部系統。用一個小人表示。

• 用例(Use Case): 用例就是外部可見的系統功能，對系統提供的服務進行描述。 用橢圓表示

• 子系統(Subsystem)：用來展現系統的一部分功能，這部分功能聯繫緊密。

• 關係

  • 用例圖中涉及的關係有：關聯、泛化、包含、擴展；

  • 關聯(Association)：表示參與者與用例之間的通訊，任何一方均可發送或接受消息。

    • 【箭頭指向】：指向消息接收方
      

  • 泛化(Inheritance)：就是一般理解的繼承關係，子用例和父用例類似，但表現出更特別的行爲；子用例將繼承父用例的全部結構、行爲和關係。子用例可使用父用例的一段行爲，也能夠重載它。父用例一般是抽象的。

    • 【箭頭指向】：指向父用例
      

  • 包含(Include)：包含關係用來把一個較複雜用例所表示的功能分解成較小的步驟；

    • 【箭頭指向】：指向分解出來的功能用例
      

  • 擴展(Extend)：擴展關係是指 用例功能的延伸，至關於爲基礎用例提供一個附加功能。

    • 【箭頭指向】：指向基礎用例
      

  • 依賴(Dependency)：表示源用例依賴於目標用例；

    • 【箭頭指向】：指向被依賴項
      
• 項目(Artifact)：用依賴關係把某個用例依賴到項目上。
  

用例圖的畫法與步驟

1. 肯定參與者，包括:

   • 主要參與者：誰將使用系統的主要功能、誰將須要系統的支持以完成工做等
   • 協做參與者：誰將提供對應的系統功能、誰將維護系統，保證系統處於工做狀態等
   • 幕後參與者：誰會對系統產生的結果感興趣
   • 根據用戶需求識別和創做用例，主要重點在於：
2. 識別使用系統的主要參與者（primary actors）/角色(roles)
3. 識別系統依賴的外部系統
4. 識別用例（服務）
5. 識別用戶級別用例（user goal level）
6. 識別子功能級別的用例（sub function level）
7. 創建 Actor 和 Use Cases 之間的關聯。

用例圖給利益相關人與開發者的價值有哪些？

1. 對於利益相關人：

   • 能夠直觀看到系統的結果和用戶的功能體驗，保證系統按照用戶的需求進行設計。
   • 用例可以根據須要對複雜程度和形式化程序進行增減調節，即可以響應用戶（利益相關人)提出的需求，而用例圖則使得這種調節更加便利，能夠經過修改圖形間的關係實現。

2. 對於開發者來講：

   • 用例圖是設計者設計過程的結論與參考，設計者與開發者之間的交流工具，開發者開發過程的藍圖。
   • 用例圖使得開發者可以更明確地得到需求，更好地理解需求。
   • 用例圖能夠指導開發和測試，同時能夠在整個過程當中對其餘工做流起到指導做用。

---

選擇2-3個你熟悉的相似業務的在線服務系統（或移動 APP），如定旅館（攜程、去哪兒等）、定電影票、背單詞APP等，分別繪製它們用例圖。並知足如下要求：

1. 請使用用戶的視角，描述用戶目標或系統提供的服務
2. 粒度達到子用例級別，並用 include 和 exclude 關聯它們
3. 請用色彩標註出你認爲創新（區別於競爭對手的）用例或子用例
4. 儘量識別外部系統和服務

1. 訂旅館：

1. 定電影票：

---

1. 爲何類似系統的用例圖是類似的？

類似系統面對的參與者和用例是類似的，用例之間的關係也是同構的。用戶預期的功能都是類似的，即不一樣的同類系統必定具備一致基本功能以及帶有本身特點的擴展功能。因此體如今用例圖上也是類似的。

2. 若是是定旅館業務，請對比 Asg_RH 用例圖，簡述如何利用不一樣時代、不一樣地區產品的用例圖，展示、突出創新業務和技術

不一樣時代對預約的酒店的需求不一樣。可讓篩選算法與時俱進，知足一些不一樣的主流要求。且用戶會須要更加優秀、好用、有參考價值的評價系統，也須要隨時更新。而不一樣地區的消費特色不一樣，旅遊勝地和普通城市用戶對於酒店預訂的需求有差異，能夠在用例圖上突出一些特色。

3. 如何利用用例圖定位創新思路（業務創新、或技術創新、或商業模式創新）在系統中的做用

應該經過創新點在圖中的位置來判斷。若是創新位於較高的父級，則做用比較大。若是是子類或者是被包括的關係，則做用相對較小。

4. 請使用 SCRUM 方法，選擇一個用例圖，編制某定旅館開發的需求（backlog）開發計劃表

ID	Name	Imp	Est	How to demo
1	find hotel	10	3	Find the hotel by name or location or type
2	make reservation	7	4	determine hotel, room type, time and then confirm
3	pay reservation	7	3	payment supported by pay system
4	modify reservation	5	2	modify reservation and hotel make approval
5	comment hotel	4	2	Comment of the hotel and show to others

5. 根據任務4，參考 使用用例點估算軟件成本，給出項目用例點的估算

• 根據用戶點方法，對用例分配權重的標準是：

  • 簡單用例：1 到 3 個事務，權重=5
  • 通常用例：4 到 7 個事務，權重=10
  • 複雜用例：多於 7 個事務，權重=15

用例	業務	計算	緣由	UC比重
查找酒店	3	2		簡單
下訂單	7	6		通常
支付	2	1		簡單
修改訂單	3	2		簡單
評論	3	2		簡單