? 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