读书人

站在巨人的肩膀下-学习用例图(UML)

发布时间: 2013-02-19 11:11:40 作者: rapoo

站在巨人的肩膀上--学习用例图(UML)
1.什么是用例图?

1. 用例图是显示谁将是相关的用户,用户希望系统提供什么服务以及用户需要为系统提供的服务

2. 用例图最常用来描述系统以及子系统

3. 用例是由参与者驱动的 ,参与者可以说人也可以是某一事物

2.用例图六要素

参与者(Actor)用例(UseCase)关联关系(Association)包含关系(Include)扩展关系(Extend)泛化关系(Generalization


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

如图所示参与者的表示形式:站在巨人的肩膀下-学习用例图(UML)

2.1.1 参与者的类型

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


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

站在巨人的肩膀下-学习用例图(UML)

2.2 用例 2.2.1用例的作用

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

2.2.2如何识别用例

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

2.2.3 用例图的属性

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

包括 1. 基本流 对用例中常规和预期路径的描述

2. 备选流 由于受到其他因素的影响,用例执行了其他的路径

2.前置条件

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

3.后置条件

说明用例结束时系统的状态

注:前置条件和后置条件可以用于用例的验证和评审


3.关联关系 表示参与者与用例之间进行通信 不同的参与者可以访问相同的用例4.包含关系 用例可以简单地包含提供者用例具有的行为,并把所包含的用例行为作为自身的一部分站在巨人的肩膀下-学习用例图(UML)
5.扩展关系 扩展用例被定义为基础用例的增量扩展 基础用例提供扩展点以增加新的行为 扩展用例提供插入片段以插入到基础用例的扩展点上

站在巨人的肩膀下-学习用例图(UML)
6.泛化关系 由泛化关系不由得想起了继承, 这二者的最大区别在于,泛化是父类泛化出子类, 子类继承父类 。子类表示父类的特殊形式

站在巨人的肩膀下-学习用例图(UML)


ps:

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


7.用例图的建模技术1.语境建模

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

2.需求建模

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

8.用例图画图步骤

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

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

首先我的机房收费系统参与者包含三个 :一般用户 操作员 管理员

我的用例就是此系统中每个模块下的各个功能,例如在我的一般用户模块下:包含查询学生上机记录,查询余额,修改密码等等功能,这些都是用例 ,确定好用例就可以画图了

下面是部分图

站在巨人的肩膀下-学习用例图(UML)


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

9.用例图总体


站在巨人的肩膀下-学习用例图(UML) 用例图就总结了这么多,日后还要继续的总结和完善。如有不足请多指点! 没有着手的时候感觉好难画,可真正的去做的时候,豁然开朗了! 下面的知识会更加精彩

2楼miliermili3天前 16:38
还是不够清晰
1楼yudandan103天前 16:35
呵呵 继续改进! 目前就理解这么多了

读书人网 >其他相关

热点推荐