系統分析與設計 第六週
系統分析與設計 第六週
1 簡答題
1.1 用例的概念
解答：
用例（use case），也稱使用案例、用況；是軟件工程或系統工程中對系統如何反應外界請求的描述，是一種通過用戶的使用場景來獲取需求的技術。每個用例提供了一個或多個場景，該場景說明了系統是如何和最終用戶或其它系統互動，也就是誰可以用系統做什麼，從而獲得一個明確的業務目標。編寫用例時要避免使用技術術語，而應該用最終用戶或者領域專家的語言。用例一般是由軟件開發者和最終用戶共同創作的。
1.2 用例和場景的關係？什麼是主場景或 happy path？
解答：
- 1> 用例與場景的關係
每個用例提供了一個或多個場景，該場景說明了系統是如何和最終用戶或其它系統互動，也就是誰可以用系統做什麼，從而獲得一個明確的業務目標。
- 2> 什麼是主場景或happy path
每個用例都包含一個主場景，這個場景是用戶和系統發生主要交互，是最常用實現用戶目標的場景。
1.3 用例有哪些形式？
解答：
用例有三種常見的形式：
- 1> Brief（high level）
簡潔型，通常是簡短的一段總結，描述主要的成功場景，在早起需求中快速瞭解主題和範圍，可以快速創建。
- 2> Casual
隨意型，非正式的段落格式，涵蓋各種場景的多個段落。
- 3> Fully
完整型，所有的步驟和變化都寫得很詳細，並有支持部分，如先決條件和成功的保證。
1.4 對於複雜業務，爲什麼編制完整用例非常難？
解答：
- 複雜業務活動包含很多用例，他們與過程關係用戶難以理解，功能業務邏輯十分複雜，且非常耗時
- 場景與場景之間存在複雜的關聯，如果場景不夠全面，那麼用例的完整性就難以保障
- 業務與需求本身就是需要不斷迭代來確定的，一直處於變化的狀態
1.5 什麼是用例圖？
解答：
用例圖是由參與者（Actor）、用例（Use Case），邊界以及它們之間的關係構成的用於描述系統功能的視圖。用例圖（User Case）是外部用戶（被稱爲參與者）所能觀察到的系統功能的模型圖。用例圖是系統的藍圖。用例圖呈現了一些參與者，一些用例，以及它們之間的關係，主要用於對系統、子系統或類的功能行爲進行建模。
1.6 用例圖的基本符號與元素？
基本元素如下：
- 1> 參與者(Actor)：表示的是一個系統用戶，也就是與應用程序進行交互的用戶、組織或者外部系統。
- 2> 用例(Use Case)：表示的是對系統提供的功能、服務的一種描述。
- 3> 用例關係：
- 包含關係(Include)：表示用例可以簡單地包含其他用例所具有的行爲，並把它所包含的用例行爲作爲自身行爲的一部分。在UML中常用帶箭頭的虛線表示，箭頭指向被包含的用例。
- 泛化關係(Generalization)：泛化指的是一個父用例可以被特化形成多個子用例，而父用例和子用例之間的關係就是泛化關係。在UML中用空心三角箭頭的實線表示，箭頭指向父用例。
- 關聯關係(Association)：表示的是參與者與用例之間的關係。在UML中常用一條直線，或者是一條帶箭頭的線條來表示，箭頭指向信息接收方。
擴展/延伸關係(Extend)：表示在一定條件下，把新的行爲加入到已有的用例中，獲得的新用例叫做擴展用例，原有的用例叫做基礎用例，相當於爲基礎用例提供一個附加功能。在UML中用帶箭頭的虛線表示，箭頭指向基礎用例。
1.7 用例圖的畫法與步驟
解答：
1> 確定參與者
- 誰將使用該系統的主要功能。
- 誰將需要該系統的支持以完成其工作。
- 誰將需要維護、管理該系統，以及保持該系統處於工作狀態。
- 系統需要處理哪些硬件設備。
- 與該系統那個交互的是什麼系統。
- 誰或什麼系統對本系統產生的結果感興趣。
2> 識別用例
- 特定參與者希望系統提供什麼功能。
- 系統是否存儲和檢索信息，如果是，由哪個參與者觸發。
- 當系統改變狀態時，是否通知參與者。
- 是否存在影響系統的外部事件。
- 哪個參與者通知系統這些事件。
3> 確定用例間的關係
- 用例除了與參與者發生關係外，還可以具有系統中的多個關係，這些關係包括包含關係、擴展關係和泛化關係。應用這些關係的目的是爲了從系統中抽取出公共行爲和其變體。
1.8 用例圖給利益相關人與開發者的價值有哪些？
解答：
用例圖描述了一個系統的主要功能以及怎樣去使用，可以讓人清楚的知道系統的各個模塊以及各部分功能的關係，對系統進行了可視化，在開發過程可以起到指導作用，能夠幫助更合理的進行人員的安排。也可以便於向用戶闡述系統功能。
2 建模練習題（用例模型）
2.1 繪製用例圖
解答：
- 1> 美團外賣
- 2> 貓眼電影
3 回答下列問題
3.1 爲什麼相似系統的用例圖是相似的？
解答：
- 1> 相似系統的主要業務邏輯類似，比如查詢系統通常只是查詢內容的不同，而登錄、註冊、查詢、管理訂單這些基本功能都是相同的，用例的類型基本固定，與子用例的關係也類似。
- 2> 相似系統面向的Actor是相似的，從Actor視角定義的用例也是相似的，連同用例之間的關係都是相似的。這本質是因爲相似系統的功能需求是相似的。
3.2 如果是定旅館業務，請對比 Asg_RH 用例圖，簡述如何利用不同時代、不同地區產品的用例圖，展現、突出創新業務和技術。
解答：
- 1> 利用時代發展的新技能不斷豐富功能，例如越來越精準的數據預測等。
- 2> 不斷把握用戶的需求，根據用戶的需求不斷優化產品。
- 3> 針對不同環境推出符合當地特色服務，例如不同省市尊重當地習俗。
3.3 如何利用用例圖定位創新思路（業務創新、或技術創新、或商業模式創新）在系統中的作用
解答：
通過在用例圖定位的創新思路（標記的創新用例），可以方便項目經理（業務創新）、需求方（商業模式創新）、開發者（技術創新）明確創新點。
3.4 請使用 SCRUM 方法，選擇一個用例圖，編制某定旅館開發的需求（backlog）開發計劃表
解答：
| Name | Imp | Est(man-day) | How to demo | Notes |
|---|---|---|---|---|
| 搜索旅店 | 10 | 3 | 選擇城市；入住離店日期；關鍵字搜索 | 搜索應當預先設置默認值；用戶可對搜索結果進行排序 |
| 預定房間 | 7 | 4 | 選擇旅店；入住離店日期；房間類型；房間數量 | 應排除已被預訂的房間；對房間進行排序 |
| 確認訂單 | 7 | 3 | 填寫入住信息 | 必須填寫：聯繫方式；身份證號 |
| 支付 | 5 | 2 | 選擇付款方式 | 注意多種付款方式的接口；支付失敗後退款 |
| 管理訂單 | 4 | 2 | 查看已支付的訂單；取消訂單 | 取消訂單需要三方確認；退款 |
3.5 根據任務4，參考 使用用例點估算軟件成本，給出項目用例點的估算
解答：
根據用戶點方法，權重分配爲：
- 簡單用例：1 到 3 個事務，權重=5
- 一般用例：4 到 7 個事務，權重=10
- 複雜用例：多於 7 個事務，權重=15
| 用例 | 事務 | 計算 | 權重 |
|---|---|---|---|
| 搜索酒店 | 3 | 2 | 簡單 |
| 預定房間 | 4 | 4 | 一般 |
| 確認訂單 | 3 | 2 | 簡單 |
| 付款 | 2 | 2 | 簡單 |
| 管理訂單 | 2 | 2 | 簡單 |