? 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 从分析到设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。