[教学研究]用例图元素之间的关系

[教学研究]用例图元素之间的关系用例图元素之间的关系

用例图中包含的元素除了系统边界、角色和用例，另外就是关系。包括:角色之间的关系、用例之间的关系、用例和角色之间的关系。

角色之间的关系

由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

用例之间的关系:

(1)包含关系:基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。

简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。

(2)泛化关系:代表一般于特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

泛化(Generalization)在面向对象的技术中无处不在，下图给出了一个使用泛化的用例图:

在用例图中，角色和用例都能够泛化。角色的泛化/继承很容易理解，因为角色本来就是类(Class)，它是一种版型(stereotype)为Actor的类，所以角色的继承直观而自然。但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展(extended)和包含(include)两种泛化的特例。扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。

(3)扩展关系: 扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。

它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例:

a.表明用例的某一部分是可选的系统行为(这样，您就可以将模型中的可选行为和必选行为分开);

b.表明只在特定条件(如例外条件)下才执行的分支流;

c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。

图中的第二个例子中，在还书的过程中，只有在例外条件(读者遗失书籍)的情况下，才会执行赔偿遗失书籍的分支流。

用例与角色之间的关系

用例由角色发起，一个用例必须至少与一个执行者关联。如何画UML用例图Tag: UML , 包含 , 用例 , 用例图 , 用例描述 , 统一建模 , 范化 | Author: bts | UML用例图是非常有用的一种图，在需求分析中，可以让人们从繁重的文档中解脱出来，并且促使人们在做需求时能够更加准确、直观的表现自己的意思。常用的语言文字往往是不能将一种事物表达得秀清晰，这时候就需要用其它的方式来进行表达，用例图就是其中一种很好的方法，当然用例图不仅仅只是做为需求分析专用，他强大的应用性还可以用于其它很多地方，这里就不详细说明了。画UML的工具有很多，个人首推IBM的ROSE，建议大家用这款工具来画例图，如果有时间，我会写一篇初级教程。接下来还是介绍一下用例图吧。

1.首先简单介绍一下UML.

UML(统一建模语言，Unified Modeling Language)是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画

哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

2.用例建模

是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。

用例建模可分为用例图和用例描述。用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。

3.用例图的说明

这里得说明一下参与者.参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。如下图

接下来就是用例了，用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是 UML对用例的正式定义，初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。如下图系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画

在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显。(在画图时可省略)

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

4.接下来就是要说说用例描述了，可以说好的用例描述直接决定工程的质量。用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。

对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括:简要描述(说明)、前置(前提)条件、基本事件流、其他事件流、异常事件流、后置(事后)条件等等。下面说说各个部分的意思:

简要描述:对用例的角色、目的的简要描述;

前置条件:执行用例之前系统必须要处于的状态，或者要满足的条件;

基本事件流:描述该用例的基本流程，指每个流程都“正常”运作时所发生的

事情，没有任何备选流和异常流，而只有最有可能发生的事件流; 其他事件流:表示这个行为或流程是可选的或备选的，并不是总要总要执行它们;

异常事件流:表示发生了某些非正常的事情所要执行的流程; 后置条件:用例一旦执行后系统所处的状态;

话说最近接触到了不少实用的新知识，今天先来说下对用例图的最新理解吧，改明儿再好好的写一篇关于RUP的文章。

虽然从07年就开始接触用例图这一概念，但确从来没有写过用例文本，在以

前做过的项目中更多的是对着用例图写概要设计报告或其它文档。曾经也疑惑过既