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的重要输入
参与者的三种类型
用例描述的三种细节程度
系统的边界
定义“合适“的用例