新浪博客

学习用例图（UML）

2014-06-12 15:00阅读：

http://blog.sina.cn/dpool/blog/u/1900681680

1.什么是用例图？


1. 用例图是显示谁将是相关的用户,用户希望系统提供什么服务以及用户需要为系统提供的服务
2. 用例图最常用来描述系统以及子系统
3. 用例是由参与者驱动的 ,参与者可以说人也可以是某一事物

2.用例图六要素




  • 参与者（Actor）
  • 用例（UseCase）
  • 关联关系（Association）
  • 包含关系（Include）
  • 扩展关系（Extend）
SPAN>
  • 泛化关系（Generalization





2.1参与者（Actor）

  • 是系统外部的一个实体
  • 参与用例的执行过程
  • 通过向系统输入或请求系统输入某些事件来触发系统的执行
  • 由参与用例时所担当的角色来表示
  • 每个参与者可以参与一个或多个用例
如图所示参与者的表示形式：

2.1.1 参与者的类型


  • 1. 系统用户
  • 2 与所建造的系统交互的其他系统
  • 3 一些可以运行的进程




在用例图中使用泛化关系来描述多个参与者之间的公共行为





2.2 用例

2.2.1用例的作用


  • 外部可见的系统功能单元
  • 在不揭示系统内部构造的前提下定义连贯的行为
  • 不是需求会功能的规格说明，但是也能展示和体现其所描述的过程中的需求情况


2.2.2如何识别用例


识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的，然后对这些事件流进行简要说明 注明条件等等

2.2.3 用例图的属性


1. 事件流 描述一个用例在执行时,执行者和系统之间的交互过程.这个过程包含多个分支


包括 1. 基本流 对用例中常规和预期路径的描述
2. 备选流 由于受到其他因素的影响,用例执行了其他的路径

2.前置条件

是该用例执行的前提条件,用来描述在什么条件下可以开始执行一个事件流

3.后置条件

说明用例结束时系统的状态
注：前置条件和后置条件可以用于用例的验证和评审


3.关联关系

表示参与者与用例之间进行通信 不同的参与者可以访问相同的用例

4.包含关系

用例可以简单地包含提供者用例具有的行为，并把所包含的用例行为作为自身的一部分




5.扩展关系

  • 扩展用例被定义为基础用例的增量扩展
  • 基础用例提供扩展点以增加新的行为
  • 扩展用例提供插入片段以插入到基础用例的扩展点上


6.泛化关系

由泛化关系不由得想起了继承， 这二者的最大区别在于，泛化是父类泛化出子类， 子类继承父类 。子类表示父类的特殊形式




ps:

对于用例图中的四种关系，我个人认为，在画图的过程中，一般直接是Actor 的行为的用例几乎都是关联关系，而当这些用例中还包含其他的用例时，也就衍生出了 扩展 包含的关系。也就是说是子功能级的细化


7.用例图的建模技术

1.语境建模


  • 识别系统外部的参与者。
  • 将类似参与者组织成泛化的结构层次。
  • 在需要加深理解的地方，为每个参与者提供一个构造型。
  • 将参与者放入到用例图中，并说明参与者与用例之间的通信路径。

2.需求建模


  • 识别系统的外部参与者来建立系统的语境。
  • 考虑每一个参与者期望的行为或需要系统提供的行为。
  • 把这些公共的行为命名为用例。
  • 确定提供者用例和扩展用例。
  • 对这些用例、参与者和它们之间的关系建模。
  • 用注释修饰用例。



8.用例图画图步骤


  • 确定系统涉及的总体信息
  • 确定参与者
  • 确定系统的用例
  • 利用工具进行画图


由于现在我正在学习机房收费系统的UML图，这里就以此为例

首先我的机房收费系统参与者包含三个 ： 一般用户 操作员 管理员
我的用例就是此系统中每个模块下的各个功能，例如在我的一般用户模块下：包含查询学生上机记录，查询余额，修改密码等等功能，这些都是用例 ，确定好用例就可以画图了
下面是部分图




通过对这些知识的了解，画一个用例图就很容易了

9.用例图总体


用例图就总结了这么多，日后还要继续的总结和完善。如有不足请多指点！ 没有着手的时候感觉好难画，可真正的去做的时候，豁然开朗了！ 下面的知识会更加精彩

我的更多文章

下载客户端阅读体验更佳

APP专享