用例图含义及画法Word格式.docx

用例图含义及画法Word格式.docx

《用例图含义及画法Word格式.docx》由会员分享，可在线阅读，更多相关《用例图含义及画法Word格式.docx（8页珍藏版）》请在冰豆网上搜索。

一．参与者（Actor）

1．参与者的概念

参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。

参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。

参与着由参与用例时所担当的角色来表示。

在UML中，参与者用名字写在下面的人形图标表示。

每个参与者可以参与一个或多个用例。

它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。

参与者有三大类：

系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。

第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。

命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。

第二类参与者是其它的系统。

这类位于程序边界之外的系统也是参与者。

第三了参与者是一些可以运行的进程，如时间。

当经过一定的时间触发系统中的某个事件时，时间就成了参与者。

２．确定参与者

在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。

（1） 

谁将使用该系统的主要功能。

（2） 

谁将需要该系统的支持以完成其工作。

（3） 

谁将需要维护、管理该系统，以及保持该系统处于工作状态。

（4） 

系统需要处理哪些硬件设备。

（5） 

与该系统那个交互的是什么系统。

（6） 

谁或什么系统对本系统产生的结果感兴趣。

在对参与者建模的过程中，开发人员必须要牢记以下几点。

参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。

参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。

参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。

每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。

每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。

一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。

（7） 

和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。

３．参与者之间的关系

因为参与者是类，所以多个参与者之间可以具有与类相同的关系。

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

如果系统中存在几个参与者，它们既扮演自身的角色，同时也扮演更具

简要说明。

每个用例应当有一个相关的说明，描述该用例的作用，说明应当简明扼要，但应包括执行用例的不同类型的用户和通过这个用例要达到的结果。

前提条件。

用例的前提条件列出用例之间必须满足的条件。

例如，前提条件是另一个用例已经执行或用户具有运行当前用例的权限。

但并不是所有用例都有前提条件。

主事件流和其它事件流。

用例的具体细节在主事件流和其它事件流中描述。

事件流是从用户角度描述执行用例的具体步骤，关注系统“做什么”，而不是“怎么做”。

主事件流和其它事件流包括：

用例如何开始和结束、用例如何与参与者交互、用例的正常流程（主流程）、用例主事件流（其它事件流）的变体和错误流。

事后条件。

事后条件是用例执行完毕后必须为真的条件。

例如，可以在用例完成之后设置一个标识，这种信息就是事后条件。

与前提条件一样，事后条件可以增加用例次序方面的信息，如果要求一个用例执行完后必须执行另一个用，那么就可以在事后条件中说明这一点。

当然，并不是每个用例中都有事后条件。

三用例间的关系

用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。

应用这些关系的目的是为了从系统中抽取出公共行为和其变体。

1．关联关系（Association）

关联关系描述参与者与用例之间的关系，它是用于表示类的挂系的关联元类的实例。

在UML中，关联关系用箭头来表示。

关联关系表示参与者与用例之间的通信。

不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的。

如果两中交互的目的也相同，说明它们的角色是相同的，就可以将它们合并。

２．包含关系（Include）

虽然每个用例的实例都是独立的，但是一个用例可以用其它的更简单的用例来描述。

这有点像通过继承父类并增加附加描述来定义一个类。

一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。

在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。

爱UML中，包含关系表示为虚线箭头交<

<

include>

>

字样，箭头指向被包含的用例。

包含关系把几个用例的公共步骤分离成一个单独的被包含用例。

被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。

用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。

包含关系使一个用例的功能可以在另一个用例中使用，如下所述。

如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。

其它用例可以和这两个用例建立包含关系。

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

要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。

这一点同功能调用有点类似。

事实上，它们在某种程度上具有相似的语义。

３．扩展关系（Extend）

一个用例也可以被定义为基础用例的增量扩展，这被称作扩展关系，扩展关系是把新的行为插入到已有的用例中的方法。

同一个基础用例的几个扩展用例可以在一起应用。

基础用例的扩展增加了原有的语义，此时基础用例而不是扩展用例被作为例子使用。

在UML中，扩展关系表示为虚线箭头加<

extend>

字样，箭头指向被扩展展的用例。

基础用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片片段，这些片段能够被插入到基础用例的扩展点上。

基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。

事实上，基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。

一个用例可能有多个扩展点，每个扩展点可以出现多次。

但是一般情况下，基础用例的执行不和涉及到扩展用例，只有特定的条件发生，扩展用例才被执行。

扩展关系为处理异常或构建灵活的系统框架提供了一种有效的方法。

４．泛化关系（Generalization）

一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。

当父用例能够被使用时，任何子用例也可以被使用。

在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。

在用例泛化中，子用例表示父用例的特殊形式。

子用例从父用例处继承行为和属性，还可以添加、覆盖或改变继承的行为。

如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。

用例建模技术

一．对语境建模

对于一个系统，会有一些事物存在于其内部，而一些事物存在于其外部。

存在于系统内部的事物的任务是完成系统外部事物所期望的系统行为，存在于系统外部并与其进行交互的事物构成了系统的语境，即系统存在的环境。

在UML建模中，用例图对系统的语境进行建模，强调的是系统的外部参与者。

对系统语境建模应当遵循以下的方法：

用以下几组事物来识别系统外部的参与者：

需要从系统中得到帮助以完成其任务的组；

执行系统功能时所必须的组；

与外部硬件或其它软件系统进行交互的组；

为了管理和维护而执行某些辅助功能的组。

将类似的参与者组织成泛化/特殊化的结构层次。

在需要加深理解的地方，为每个参与者提供一个构造型。

将参与者放入到用例图中，并说明参与者与用例之间的通信路径。

二．对需求建模

需求就是根据用户对产品功能的期望，提出产品外部功能的描述。

需要分析所要做的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。

对系统需求建模可以参考以下的方法。

识别系统外部的参与者来建立系统的语境。

考虑每一个参与者期望的行为或需要系统提供的行为。

把公共的行为命名为用例

分解公共行为，放入到新的用例中以供其它的用例使用：

分解异常行为，放入新用例中以延伸为主要的控制流。

简而言之，就是确定提供者用例和扩展用例。

在用例视图中对用例、参与者和它们之间的关系进行建模。