UML的9种图例的定义用途画法总结Word格式.docx

UML的9种图例的定义用途画法总结Word格式.docx

《UML的9种图例的定义用途画法总结Word格式.docx》由会员分享，可在线阅读，更多相关《UML的9种图例的定义用途画法总结Word格式.docx（38页珍藏版）》请在冰豆网上搜索。

因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。

还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。

系统边界是用来表示正在建模系统的边界。

边界表示系统的组成局部，边界外表示系统外部。

系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。

因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

箭头用来表示参与者和系统通过相互发送信号或消息进展交互的关联关系。

箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

元素之间的关系：

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

关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。

角色之间的关系：

角色之间的关系。

由于角色实质上也是类，所以它拥有与类一样的关系描述，即角色之间存在泛化关系〔泛化关系可以先简单理解为继承〕，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

用例之间的关系：

●包含关系：

根本用例的行为包含了另一个用例的行为。

根本用例描述在多个用例中都有的公共行为。

包含关系本质上是比拟特殊的依赖关系。

它比一般的依赖关系多了一些语义。

在包含关系中箭头的方向是从根本用例到包含用例。

在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。

在UML1.3以后的版本中用例之间是包含和扩展这两种关系。

●泛化关系：

它的意思和面向对象程序设计中的继承的概念是类似的。

不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。

在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

●扩展关系

扩展关系的根本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规那么限制，根本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。

与包含关系一样，扩展关系也是依赖关系的版型。

在扩展关系中，箭头的方向是从扩展用例到根本用例，这与包含关系是不同的。

　　用例的泛化、包含、扩展关系的比拟。

一般来说可以使用“isa〞和“hasa〞来判断使用那种关系。

泛化和扩展关系表示用例之间是“isa〞关系，包含关系表示用例之间是“hasa〞关系。

扩展与泛化相比多了扩展点，扩展用例只能在根本用例的扩展点上进展扩展。

在扩展关系中根本用例是独立存在。

在包含关系中执行根本用例的时候一定会执行包含用例。

〔1〕如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个根本用例对另一个的引用。

〔2〕当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。

〔3〕当描述正常行为的变形希望采用更多的控制方式时，可以在根本用例中设置扩展点，使用扩展关系。

扩展关系比拟难理解，如果把扩展关系看作是带有更多规那么限制的泛化关系，可以帮助理解。

通常先获得根本用例，针对这个用例中的每一个行为提问：

该步骤会出什么过失？

该步骤有不同的情况吗？

该步骤的工作怎样以不同的方式进展等，把所有的变化情况都标识为扩展。

通常根本用例很容易构造，而扩展用例需要反复分析、验证。

当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的局部从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。

用例之间的关系举例：

包含：

业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以与修改都要在用例详述中描述，过于复杂；

如果分成新建用例、编辑用例和删除用例，那么划分太细。

这时包含关系可以用来理清关系。

扩展：

系统中允许用户对查询的结果进展导出、打印。

对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。

导入、打印和查询相对独立，而且为查询添加了新行为。

泛化：

子用例将继承父用例的所有结构、行为和关系。

子用例可以使用父用例的一段行为，也可以重载它。

父用例通常是抽象的。

4、画法例子

二、类图

类图Classdiagram通过显示出系统的类以与这些类之间的关系来表示系统。

类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。

在系统分析阶段将类分成三种类型：

实体类、边界类、控制类

边界类用于描述外部参与者与系统之间的交互。

识别边界类可以帮助开发人员识别出用户对界面的需求。

实体类主要是作为数据管理和业务逻辑处理层面上存在的类别；

它们主要在分析阶段区分。

实体类的主要职责是存储和管理系统部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。

控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序。

类图的目的是显示建模系统的类型，描述组成系统的对象容与对象之间的关系。

类名

类的UML表示是一个长方形，垂直地分为三个区，如图1所示。

顶部区域显示类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的〔当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的〕。

图1显示一个航线班机如何作为UML类建模。

正如我们所能见到的，名字是Flight，我们可以在中间区域看到Flight类的3个属性：

flightNumber，departureTime和flightDuration。

在底部区域中我们可以看到Flight类有两个操作：

delayFlight和getArrivalTime。

图1:

Flight类的类图

类属性列表

类的属性节〔中部区域〕在分隔线上列出每一个类的属性。

属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。

如下格式：

name:

attributetype

flightNumber:

Integer

继续我们的Flight类的例子，我们可以使用属性类型信息来描述类的属性，如表1所示。

表1：

具有关联类型的Flight类的属性名字

属性名称

属性类型

flightNumber

Integer

departureTime

Date

flightDuration

Minutes

在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的〔例如，分钟，美元，等等〕。

然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。

在类图上显示具有默认值的特定属性，有时是有用的〔例如，在银行账户应用程序中，一个新的银行账户会以零为初始值〕。

UML规允许在属性列表节中，通过使用如下的记号作为默认值的标识：

attributetype=defaultvalue

举例来说：

balance:

Dollars=0

显示属性默认值是可选择的；

图2显示一个银行账户类具有一个名为balance的类型，它的默认值为0。

图2：

显示默认为0美元的balance属性值的银行账户类图。

类操作列表

类操作记录在类图长方形的第三个〔最低的〕区域中，它也是可选择的。

和属性一样，类的操作以列表格式显示，每个操作在它自己线上。

操作使用以下记号表现：

name（parameterlist）:

typeofvaluereturned

图3显示，delayFlight操作有一个Minutes类型的输入参数--numberOfMinutes。

然而，delayFlight操作没有返回值。

1当一个操作有参数时，参数被放在操作的括号；

每个参数都使用这样的格式：

“参数名：

参数类型〞。

图3：

Flight类操作参数，包括可选择的“in〞标识。

当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数。

这个可选择的指示器以“in〞或“out〞出现，如图3中的操作区域所示。

一般来说，除非将使用一种早期的程序编程语言，如Fortran，这些指示器可能会有所帮助，否那么它们是不必要的。

然而，在C++和Java中，所有的参数是“in〞参数，而且按照UML规，既然“in〞是参数的默认类型，大多数人将会遗漏输入/输出指示器。

继承

在面向对象的设计中一个非常重要的概念，继承，指的是一个类〔子类〕继承另外的一个类〔超类〕的同一功能，并增加它自己的新功能〔一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人〕的能力。

为了在一个类图上建模继承，从子类〔要继承行为的类〕拉出一条闭合的，单键头〔或三角形〕的实线指向超类。

考虑银行账户的类型：

图4显示CheckingAccount和SavingsAccount类如何从BankAccount类继承而来。

图4:

继承通过指向超类的一条闭合的，单箭头的实线表示。

在图4中，继承关系由每个超类的单独的线画出，这是在IBMRationalRose和IBMRationalXDE中使用的方法。

然而，有一种称为树标记的备选方法可以画出继承关系。

当存在两个或更多子类时，如图4中所示，除了继承线象树枝一样混在一起外，你可以使用树形记号。

图5是重绘的与图4一样的继承，但是这次使用了树形记号。

图5:

一个使用树形记号的继承实例

抽象类与操作

细心的读者会注意到，在图4和图5中的图中,类名BankAccount和withdrawal操作使用斜体。

这表示，BankAccount类是一个抽象类，而withdrawal方法是抽象的操作。

换句话说，BankAccount类使用withdrawal规定抽象操作，并且CheckingAccount和SavingsAccount两个子类都分别地执行它们各自版本的操作。

然而，超类〔父类〕不一定要是抽象类。

标准类作为超类是正常的。

关联

当你系统建模时，特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模。

有五种关联。

在这一局部中，我将会讨论它们中的两个--双向的关联和单向的关联，而且我将会在Beyondthebasics局部讨论剩下的三种关联类型。

请注意，关于何时该使用每种类型关联的详细讨论，不属于本文的围。

相反的，我将会把重点集中在每种关联的用途，并说明如何在类图上画出关联。

双向〔标准〕的关联

关联是两个类间的联接。

关联总是被假定是双向的；

这意味着，两个类彼此知道它们间的联系，除