UML之UseCase学习总结

问题：
  UseCase是什么东西？有什么作用？

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

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

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

步骤：
编写一个UseCase相当于写作文，并且怎么让任何人一看就明白，这个复杂。但是建议尽量写简单句。

• 明确指出设计范围与系统边界的名称
• 列出所有可能参与的者(分清主次参与者)
• 列出参与者的使用目的
• 进行新增、删除或者合并一些使用目的一致的使用案例
• 选择一个使用案例，然后对其进行详细的描述。
• 找出使用案例的关系人与其利益、事件条件与事前保证
• 写出使用案例的主要的成功情景
• 尽量写出成功情景中可能出现的扩充情况
• 针对扩充的情况，写出它们的处理步骤
• 把比较复杂的流程分解成多个子使用案例；不重要、比较小的子使用案例则合并回到调用它的使用案例中（类似递归）
• 检查调整后的使用案例。

建议：使用案例的主流程的步骤不超过8步。多了的话，就考虑分解。

实例

引用

使用案例： 车祸索赔

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

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

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