UML之UseCase学习总结

[b]问题：[/b]
UseCase是什么东西？有什么作用？

[b]背景：[/b]
UseCase其实就是使用案例。是从UML中引申出来的一种功能多样的记录性文档。越来越发现需要很重要，但是现实大家都知道，需求是很不确定。这就所谓世界万物无时无刻不在变化。在学校读软件工程的时候，也许老师是教需求本身是相对变动的。因此很多刚出来的朋友，口头就常常挂着，需求又变了。其实你要知道需求一定是相对稳定的。因此这里这个UseCase就是一个记录和用户进行交谈的时候，记录和图像展现的一个工具，同时也是保证在需求变动的时候可以参考当时的UseCase进行需求变更后的分析。

[b]作用：[/b]
有人说：UseCase只是用做需求的吗？其实这个不好定位。因为UseCase也可以体现企业中的工作流程。所以如果你要知道它有什么作用，那么就看你是谁？你想让他表达什么？你是处于什么位置，你什么时候用？

[b]变化：[/b]
现在外面在看看UseCase的变化，如果你说UseCase是死的，那我觉得其实是你的态度是死的。UseCase是可以变化成很多的UML图比如：序列图、抽取实体、工作流等待。

[b]步骤：[/b]
编写一个UseCase相当于写作文，并且怎么让任何人一看就明白，这个复杂。但是建议尽量写简单句。
[list]
[*] 明确指出设计范围与系统边界的名称
[*] 列出所有可能参与的者(分清主次参与者)
[*] 列出参与者的使用目的
[*] 进行新增、删除或者合并一些使用目的一致的使用案例
[*] 选择一个使用案例，然后对其进行详细的描述。
[*] 找出使用案例的关系人与其利益、事件条件与事前保证
[*] 写出使用案例的主要的成功情景
[*] 尽量写出成功情景中可能出现的扩充情况
[*] 针对扩充的情况，写出它们的处理步骤
[*] 把比较复杂的流程分解成多个子使用案例；不重要、比较小的子使用案例则合并回到调用它的使用案例中（类似递归）
[*] 检查调整后的使用案例。
[/list]
建议：使用案例的主流程的步骤不超过8步。多了的话，就考虑分解。

[b]实例[/b]
[quote]
使用案例： 车祸索赔

[b]主要参与者：[/b] 索赔者
[b]设计范围：[/b] 保险公司
[b] 关系人与利益：[/b]
索赔者———— 尽可能得到赔偿
保险公司———— 尽可能付出最少的合理金额
保险部门———— 知道所有要知道是条文（法律或者规则）
[b]事件条件：[/b] 无
[b]最小事后保证：[/b] 保险公司要把索赔与所有活动登录到历史记录中
[b]成功事后保证：[/b] 索赔者跟保险公司都同意一个赔偿金额；索赔者得到这个金额。
[b]触发事件：[/b] 索赔者要求索赔
[b]主要成功情景：[/b]

1. 索赔者根据具体资料索赔
2. 保险公司检查索赔者是否拥有有效保单
3. 保险公司指定经销商检查这个个案
4. 保险公司检查所有相关细节都在保单条文范围内。
5. 保险公司付钱给索赔者并结束这个个案

[b]扩充情景：[/b]1a 索赔资料不完整：
1a1. 保险公司要求补全缺少资料
1b2. 索赔者提供不足资料
2a 索赔者没有有效保单
2a1 保险公司回绝索赔、告知索赔者、记录所有相关活动、终止。
4a 这件意外事件违反保单的基本条文
4a1 保险公司回绝索赔、告知索赔者、记录所有相关活动、终止。
[/quote]