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