6.1 从分析到设计
? 1、準備高質量的”用例模型 ”…
? OOAD的主要輸入！Use Case is the main input of OOAD
1.1 用例模型
? 用例模型的組成
? 參與者
? 用例（取名：短小精悍的動名詞，如“取錢”、“修改密碼）
? 用例描述 （作為領域模型的輸入、設計的輸入、開發的輸入…)
? 系統邊界
? 系統順序圖
? 操作契約（待講）
? 用例模型是客戶、開發單位、設計人員、編程人員之間的合約
1.2 參與者 Actor
? Actor
? 位于系統之外并和系統進行交互的一類事物（人、物、其他軟件子系統等）
? 參與者主要有三類
? 主要參與者Primary – 這類用戶希望通過新系統實現自己的商業目標
? 為什么 ？他們是用例的主要來源
? 例如，POS系統的 cashier
? 協助性參與者Supporting – 提供支持，比如關于第三方軟件接口
? 為什么？為了澄清外部接口、協議等
? 例如， POS系統的信用卡支付的授權認證服務
? 幕后參與者 Offstage – 對系統功能感興趣，但不是很強烈
? 為什么？為了保證所有想到的參與者都考慮了，盡可能滿足所有人的期望，這些參與 者的愿望一? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 般不需要實現，有余力時可以做一下
? 例如， POS系統的政府稅收代理人員
1.3 用例 Use Case
? 用例
? 系統為響應參與者引發的一個事件而執行的一系列的處理/動作，這些處 理應該為參與者產生一種有價? ? ? ? ? ? ? ? ? ? 值的結果
? 用例描述的三種詳細程度
? 簡短格式 brief
? 一段扼要的總結，通常是主事件流
? 在早期階段的分析中很有用，標識系統范圍、可能的風險等
? 隨意的 casual （寫到哪里是哪里！）
? 非正式的一段、一段描述，每一段也許是一個場景scenarios
? 正式的 fully
? 根據指定的格式，一步步地描述每個動作，包括前置條件、后置條件、成功保證、約 束等
? 重要的用例，都需要有詳細的描述。有助于建立詞匯表、抽取概念類、評估風險等
? 在后續的迭代過程中，可能需要來回修改這些描述
? 至少有10%的關鍵用例，必須以這種方式來描述
1.3 用例 Use Case，Example
? 簡短或者隨意格式案例 Brief or Casual format
? For example, use case “Process Sale”:
? A customer arrives at a checkout with items to purchase
? The cashier uses the POS system to record each purchased item
? The system presents a running total and line-item details
? The customer enters payment information, which the system validates and records
? The system updates inventory
? The customer receives a receipt from the system and then leaves with the items
1.4 系統邊界
? 選擇系統邊界Choose system boundary | scope | border
? Is the cashier an actor of system?
? Is Credit authorization our responsibility?
? 原則“屁股決定腦袋！”
1.5 發現所有“主要參與者”及其目標
? Find all primary actors and their goals
? Who does what or needs what ?
? Rather than asking “what you do” ask “what is your role, goal, interest”
? Analyze events
? Remember stakeholders and their goals
? E.g , Cashier wants easy processing while management wants efficient and secure processing
? 千萬不要把“老板”的要求給疏忽了 ！
1.6 標識“合適的”用例
? 如何判斷一個用例是否是一個合適的用例 ？
? ①用例是否描述了應該做什么，而不是如何做？
? ②用例的描述是否采取了參與者的視點？
? 在確定用例的關鍵特征時，應該依據參與者的視點。也就是說，應該從參與者如何使 用系統的角? ? ? ? ? ? ? ? ? ? ? ? ? ? ?度出發定義用例，而不是從系統自身的角度
? ③用例是否對參與者有價值？
? 用例不是動作步驟的任意集合，它必須為參與者提供可辨識的價值
? ④用例描述的時間流是否是一個完整場景？
? 每一個用例必須描述出，在一個給定場景下參與者將如何使用系統的完整事件流。這 有助于避免? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 產生單步用例、部分用例或者功能分解用例
? ⑤是否所有的參與者、用例都有相應的關聯用例或關聯參與者？
? 判斷方法：三種
? Boss test
? Can you excuse your time doing THIS ?
? EBP（Elementary Business Process ）test
? 一個人于某個時刻在某個地點所執行的任務，以響應業務事件，該任務能夠增加可量化的業務 價? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 值，并使數據保持一致的狀態
? 例如，批準一筆信貸、確定訂單價格
? 規模測試 Size test
? Remember that use case(s) will be processed in your time boxes
? 下列用例是否合適?
? Negotiate a Supplier Contract（太大！）
? Handle Returns（OK）
? Log On（如果你一整天都在登錄，老板會不滿意的）
? Move Piece on Game Board（太小！）
小結
? 用例模型是OOAD的重要輸入
? 參與者的三種類型
? 用例描述的三種細節程度
? 系統的邊界
? 定義“合適“的用例
轉載于:https://www.cnblogs.com/mayZhou/p/10548352.html
總結
以上是生活随笔為你收集整理的6.1 从分析到设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： UOJ#310.【UNR #2】黎明前的
- 下一篇： 复合数据类型，英文词频统计