用power designer画用例图方法

画用例图

用例图

组成：系统边界。参与者。用例。关系。

参与者：Actor不是人，而是指参与用例时担当的角色。

如果一个角色的操作是由另一个角色代理完成的，请建立该角色到另外角色之间的依赖。

怎样识别参与者呢？

1. 是谁向系统提供的信息呢. 2. 谁向系统获取信息。 3. 谁操作系统。 4. 系统使用哪些外部资源

5. 系统是否和已经存在的系统交互

系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。

用例分析可以认为是对系统功能的分解。 怎样确定用例的粒度呢？

用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个左右。用例是系统级的抽象的描述，不是细化的（是做什么，非怎样做）。对复杂系统可以划分为若干个子系统处理。 怎样获取用例呢？

参与者希望系统执行什么任务？

参与者在系统中访问哪些信息（创建、存储、修改、删除等）？ 需要将外界的哪些信息提供给系统？ 需要将系统的那个事件告诉参与者？

如何维护系统？

UML中的四种关系。 关联（association）

包含（include）

扩展（extend）泛化（generalization） 关联关系

描述参与者和用例之间的关系。 用单向箭头，表示谁启动用例。

每个用例都有角色启动，除了包含和扩展用例。

包含。

是指两个用例之间的关系。其中一个用例（基本用例，base use case）的行为包含了另一个用例（包含用例，inclusion use case）的行为。

如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用力拉可以和这个用例建立包含关系。

上面的例子就是说查询、提款和转账三个用例都有一个一致的功能，所以将这个功能提取出来为一个用例。且这三个用例和提取出的这个用例之间是包含的关系。 执行基本用例的时候也可以执行被包含的用例，被包含的用例也可以单独执行。

如果一个用例的功能太多时，可以用包含关系建模成两个或多个小用例

扩展。

也是指两个用例之间的关系。一个用例可以被定义为基础用例的增量的扩展，称作为扩展关系。扩展关系是把新的行为插入到已有的用例中方法。基础用例即使没有扩展用例的执行不会涉及扩展用例，只有在特定的条件发生，扩展用例才被执行。

泛化（继承）。

一个用例和其几种情形的用例间构成泛化关系。往往父用例表示为抽象用例。 任何父用例出现的地方子用例也可出现。

1 对用例的描述。

1. 用例图：只能描述系统的大概功能，是一种视图。 2. 用例描述：更详细地描述用例的功能。 2 用例描述的组成

用例名称，简要说明/描述，优先级，参与者，前置条件，基本事件流，其他事件流，扩展点，后置条件。

事件流：就是用例执行时，由一序列活动组成的控制流。 基本事件流：对用例中常规、预期路径的描述。

扩展事件流：主要是对一些异常情况、选择分支进行描述。 前置条件：在用例启动时参与者（actor）与系统应置于什么状态。 后置条件：用例结束时系统应置于什么状态。

以上述的\新增书籍信息\为例，说明如何细化用例描述。 1. 用例的概要描述

用例名称：新增书籍（UCO1）

简要说明：录入新购书籍信息，并自动存储建档。 事件流：基本事件流和扩展事件流。

本文来源：https://www.bwwdw.com/article/4l8t.html