UML用例图-笔记

UML笔记

一、用例图（User Case）

用例的基本特征：

1、一个完整的用例定义由参与者、前置条件、场景和后置条件构成，如下图所示：

2、用例是相互独立的

         说明：不需要与其他用例交互而独自完成参与者的目的；

                     任何一个用例必须对于参与者来说有实际的目的以及意义

3、用例必须是由参与者发起的，不存在没有参与者的用例，用例不应该自己启动，也不应该主动启动

4、用例必然是以动宾短语的形式出现的

         用例必须有一个动作和动作的受体，而不仅只是一个单独的行为。

5、一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至是部署单元

用例的粒度：

1、 在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。

2、 在系统建模阶段，用例视角是针对计算机的，因此用例的粒度是以一个用例能够描述操作者与计算机的一次完整交互为宜。

用例的获取：

1、 用例的定义是参与者来驱动的

2、 用例的来源是参与者对系统的期望

3、 发现用例的前置条件就是发现参与者

4、 确定参与者的同时就是确定了系统的边界

理解用例的主角：

1、 主角是位于系统边界之外的

2、 主角对系统有着明确的期望和明确的回报要求

3、 主角的期望和回报要求在系统边界之内的

理解用例需求的特征：

1、 一个明确的有效的目标才是一个用例的来源

2、 一个真实的目标应该完备地表达主角的期望

3、 一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果

用例和功能的误区：

1、 用例的分析过程是面向对象的

2、 功能点的分析过程是面向过程的

3、 描述一个事物，从如下三个观点出发：

l  这个事物是什么

l  这个事物能做什么

l  人们能够用这个事物做什么

4、使用者的观点其实就是用例的观点

5、用例和功能的区分如下：

l  功能是脱离使用者的愿望而存在的

l  功能是孤立的，给一个输入，通过计算就有一个固定的输出；而用例是系统性的，是由谁来在什么情况下使用一个什么样的功能

l  如果非要从功能的角度解释 用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对这些不同的应用场景，这些“功能”体现不同的组合方式。必须是先有场景，才有了功能的

6、 UML中其实是没有功能这个词的

用例粒度的误区：

1、 在同一个需求阶段，必须保持所有的用例的粒度在同一个量级上

2、 用例粒度必须建立在合适的边界上，比如系统级别、业务级别

3、 抽象层次决定于用例的粒度

用例之间的关系：

1、 扩展关系，表示用例场景中某个支流，由特定的扩展点出发而被启动的。它与包含关系的区别是，扩展表示是可选的，而不是必须的，这就意味着即使没有扩展用例，基本用例也是完整的；如果有多个扩展用例，在同一时间用例实例也只有一个。

扩展关系的原则：表明用例的某一部分是可选的系统行为。

2、 包含关系，基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果，但基本用例和包含用例都不能访问对方的属性。

包含关系的原则：

l  包含用例是的必需的，而不是可选的，没有包含用例，基本用例就是不完整的

3、 泛化关系，表示两个对象之间的继承关系，箭头所指的方向表示父类

备注：用例之间的关系，通常只需要两种关系来描述就可以了，包含和扩展。

本文转自一米一阳光博客园博客，原文链接：    <b>http://www.cnblogs.com/candle806/archive/2013/03/15/2961474.html</b>，如需转载请自行联系原作者