论坛首页 综合技术论坛

UML之UseCase学习总结

浏览 2499 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (2) :: 隐藏帖 (0)
作者 正文
   发表时间:2009-12-15   最后修改:2009-12-15
问题:
  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 保险公司回绝索赔、告知索赔者、记录所有相关活动、终止。
 
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics