UML的9种图例的定义用途画法总结.docx
《UML的9种图例的定义用途画法总结.docx》由会员分享，可在线阅读，更多相关《UML的9种图例的定义用途画法总结.docx（38页珍藏版）》请在冰豆网上搜索。
UML的9种图例的定义用途画法总结
UML的9种图例的总结
一、用例图
1、定义
用例定义：
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
（这是UML对用例的正式定义，可以这样去理解，用例是参与者想要系统做的事情，用例在画图中用椭圆来表示，椭圆下面附上用例名称）。
用例图定义：
由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。
2、用途
用例图（UserCase）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图主要的作用有三个：
（1）获取需求；
（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。
3、组成元素以及元素之间的关系说明
用例图由参与者（Actor）、用例（UseCase）、系统边界（用矩形表示—注明系统名称）、箭头组成，用画图的方法来完成。
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
元素之间的关系：
用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
角色之间的关系：
角色之间的关系。
由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系（泛化关系可以先简单理解为继承），泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系：
●包含关系：
基本用例的行为包含了另一个用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系本质上是比较特殊的依赖关系。
它比一般的依赖关系多了一些语义。
在包含关系中箭头的方向是从基本用例到包含用例。
在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。
在UML1.3以后的版本中用例之间是包含和扩展这两种关系。
●泛化关系：
它的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
●扩展关系
扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。
与包含关系一样，扩展关系也是依赖关系的版型。
在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。
用例的泛化、包含、扩展关系的比较。
一般来说可以使用“isa”和“hasa”来判断使用那种关系。
泛化和扩展关系表示用例之间是“isa”关系，包含关系表示用例之间是“hasa”关系。
扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。
在扩展关系中基本用例是独立存在。
在包含关系中执行基本用例的时候一定会执行包含用例。
（1）如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。
（2）当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。
（3）当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。
扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。
通常先获得基本用例，针对这个用例中的每一个行为提问：
该步骤会出什么差错？
该步骤有不同的情况吗？
该步骤的工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。
通常基本用例很容易构造，而扩展用例需要反复分析、验证。
当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。
用例之间的关系举例：
包含：
业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
这时包含关系可以用来理清关系。
扩展：
系统中允许用户对查询的结果进行导出、打印。
对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。
导入、打印和查询相对独立，而且为查询添加了新行为。
泛化：
子用例将继承父用例的所有结构、行为和关系。
子用例可以使用父用例的一段行为，也可以重载它。
父用例通常是抽象的。
4、画法例子
二、类图
1、定义
类图Classdiagram通过显示出系统的类以及这些类之间的关系来表示系统。
类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。
在系统分析阶段将类分成三种类型：
实体类、边界类、控制类
边界类用于描述外部参与者与系统之间的交互。
识别边界类可以帮助开发人员识别出用户对界面的需求。
实体类主要是作为数据管理和业务逻辑处理层面上存在的类别；它们主要在分析阶段区分。
实体类的主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。
控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序。
2、用途
类图的目的是显示建模系统的类型，描述组成系统的对象内容与对象之间的关系。
3、组成元素以及元素之间的关系说明
类名
类的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规范允许在属性列表节中，通过使用如下的记号作为默认值的标识：
name:
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部分讨论剩下的三种关联类型。
请注意，关于何时该使用每种类型关联的详细讨论，不属于本文的范围。
相反的，我将会把重点集中在每种关联的用途，并说明如何在类图上画出关联。
双向（标准）的关联
关联是两个类间的联接。
关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除非你限定一些其它类型的关联。
回顾一下Flight的例子，图6显示了在Flight类和Plane类之间的一个标准类型的关联。
图6：
在一个Flight类和Plane类之间的双向关联的实例
一个双向关联用两个类间的实线表示。
在线的任一端，你放置一个角色名和多重值。
图6显示Flight与一个特定的Plane相关联，而且Flight类知道这个关联。
因为角色名以Plane类表示，所以Plane承担关联中的“assignedPlane”角色。
紧接于Plane类后面的多重值描述0...1表示，当一个Flight实体存在时，可以有一个或没有Plane与之关联（也就是，Plane可能还没有被分配）。
图6也显示Plane知道它与Flight类的关联。
在这个关联中，Flight承担“assignedFlights”角色；图6的图告诉我们，Plane实体可以不与flight关联（例如，它是一架全新的飞机）或与没有上限的flight（例如，一架已经服役5年的飞机）关联。
由于对那些在关联尾部可能出现的多重值描述感到疑惑，下面的表3列出了一些多重值及它们含义的例子。
表3:
多重值和它们的表示
表示
含义
0..1
0个或1个
1
只能1个
0..*
0个或多个
*
0个或多个
1..*
1个或多个
3
只能3个
0..5
0到5个
5..15
5到15个
单向关联
在一个单向关联中，两个类是相关的，但是只有一个类知道这种联系的存在。
图7显示单向关联的透支财务报告的一个实例。
图7:
单向关联一个实例：
OverdrawnAccountsReport类BankAccount类，而BankAccount类则对关联一无所知。
一个单向的关联，表示为一条带有指向已知类的开放箭头（不关闭的箭头或三角形，用于标志继承）的实线。
如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。
在图7中的例子中，OverdrawnAccountsReport知道BankAccount类，而且知道BankAccount类扮演“overdrawnAccounts”的角色。
然而，和标准关联不同，BankAccount类并不知道它与OverdrawnAccountsReport相关联。
2
软件包
不可避免，如果你正在为一个大的系统或大的业务领域建模，在你的模型中将会有许多不同的分类器。
管理所有的类将是一件令人生畏的任务；所以，UML提供一个称为软件包的组织元素。
软件包使建模者能够组织模型分类器到名字空间中，这有些象文件系统中的文件夹。
把一个系统分为多个软件包使系统变成容易理解，尤其是在每个软件包都表现系统的一个特定部分时。
3
在图中存在两种方法表示软件包。
并没有规则要求使用哪种标记，除了用你个人的判断：
哪种更便于阅读你画的类图。
两种方法都是由一个较小的长方形（用于定位）嵌套在一个大的长方形中开始的，如图8所示。
但是建模者必须决定包的成员如何表示，如下：
∙如果建模者决定在大长方形中显示软件包的成员，则所有的那些成员4需要被放置在长方形里面。
另外，所有软件包的名字需要放在软件包的较小长方形之内（如图8的显示）。
∙如果建模者决定在大的长方形之外显示软件包成员，则所有将会在图上显示的成员都需要被置于长方形之外。
为了显示属于软件包的分类器，从每个分类器画一条线到里面有加号的圆周，这些圆周粘附在软件包之上（图9）。
图8：
在软件包的长方形内显示软件包成员的软件包元素例子
图9：
一个通过连接线表现软件包成员的软件包例子
在UML2中，了解类图的基础更为重要。
这是因为类图为所有的其他结构图提供基本的构建块。
如组件或对象图（仅仅是举了些例子）。
在下面的部分中，会使用的类图的更重要的方面。
这些包括UML2规范中的接口，其它的三种关联类型，可见性和其他补充。
接口
在本文的前面，我建议你以类来考虑分类器。
事实上，分类器是一个更为一般的概念，它包括数据类型和接口。
关于何时、以及如何高效地在系统结构图中使用数据类型和接口的完整讨论，不在本文的讨论范围之内。
既然这样，我为什么要在这里提及数据类型和接口呢？
你可能想在结构图上模仿这些分类器类型，在这个时候，使用正确的记号来表示，或者至少知道这些分类器类型是重要的。
不正确地绘制这些分类器，很有可能将使你的结构图读者感到混乱，以后的系统将不能适应需求。
一个类和一个接口不同：
一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。
在UML2中，一个接口被认为是类建模元素的特殊化。
因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”，如图10所示。
5
图10：
Professor类和Student类实现Person接口的类图实例
在图10中显示的图中，Professor和Student类都实现了Person的接口，但并不从它继承。
我们知道这一点是由于下面两个原因：
1）Person对象作为接口被定义--它在对象的名字区域中有“interface”文本，而且我们看到由于Professor和Student对象根据画类对象的规则（在它们的名字区域中没有额外的分类器文本）标示，所以它们是类对象。
2）我们知道继承在这里没有被显示，因为与带箭头的线是点线而不是实线。
如图10所示，一条带有闭合的单向箭头的点线意味着实现（或实施）；正如我们在图4中所见到的，一条带有闭合单向箭头的实线表示继承。
更多的关联
在上面，我讨论了双向关联和单向关联。
现在，我将会介绍剩下的三种类型的关联。
（1）关联类
在关联建模中，存在一些情况下，你需要包括其它类，因为它包含了关于关联的有价值的信息。
对于这种情况，你会使用关联类来绑定你的基本关联。
关联类和一般类一样表示。
不同的是，主类和关联类之间用一条相交的点线连接。
图11显示一个航空工业实例的关联类。
图11：
增加关联类MileageCredit
在图11中显示的类图中，在Flight类和FrequentFlyer类之间的关联，产生了称为MileageCredit的关联类。
这意味当Flight类的一个实例关联到FrequentFlyer类的一个实例时，将会产生MileageCredit类的一个实例。
（2）聚合
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。
在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。
举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。
轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。
在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。
然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期--这称为合成聚合。
举例来说，考虑公司与部门的关系。
公司和部门都建模成类，在公司存在之前，部门不能存在。
这里Department类的实例依赖于Company类的实例而存在。
让我们更进一步探讨基本聚合和组合聚合。
●基本聚合
有聚合关系的关联指出，某个类是另外某个类的一部分。
在一个聚合关系中，子类实例可以比父类存在更长的时间。
为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。
图12显示车和轮胎间的聚合关系的例子。
图12:
一个聚合关联的例子
●组合聚合
组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。
在图13中，显示了Company类和Department类之间的组合关系，注意组合关系如聚合关系一样绘制，不过这次菱形是被填充的。
图13:
一个组合关系的例子
在图13中的关系建模中，一个Company类实例至少总有一个Department类实例。
因为关系是组合关系，当Company实例被移除/销毁时，Department实例也将自动地被移除/销毁。
组合聚合的另一个重要功能是部分类只能与父类的实例相关（举例来说，我们例子中的Company类）。
（3）反射关联
现在我们已经讨论了所有的关联类型。
就如你可能注意到的，我们的所有例子已经显示了两个不同类之间的关系。
然而，类也可以使用反射关联与它本身相关联。
起先，这可能没有意义，但是记住，类是抽象的。
图14显示一个Employee类如何通过manager/manages角色与它本身相关。
当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。
图14：
一个反射关联关系的实例
图14描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。
然而，因为“manages”的关系角色有0..*的多重性描述；一个雇员可能不受任何其他雇员管理。
可见性
在面向对象的设计中，存在属性及操作可见性的记号。
UML识别四种类型的可见性：
public，protected，private及package。
UML规范并不要求属性及操作可见性必须显示在类图上，但是它要求为每个属性及操作定义可见性。
为了在类图上的显示可见性，放置可见性标志于属性或操作的名字之前。
虽然UML指定四种可见性类型，但是实际的编程语言可能增加额外的可见性，或不支持UML定义的可见性。
表4显示了UML支持的可见性类型的不同标志。
表4：
UML支持的可见性类型的标志
标志
可见性类型
+
Public
#
Protected
-
Private
~
Package
现在，让我们看一个类，以说明属性及操作的可见性类型。
在图15中，所有的属性及操作都是public，除了updateBalance操作。
updateBalance操作是protected。
图15：
一个BankAccount类说明它的属性及操作的可见性
UML2补充
既然我们已经覆盖了基础和高级主题，我们将覆盖一些由UML1.x增加的类图的新记号。
（1）实例（具体对象）……是一个具体的对象
当一个系统结构建模时，显示例子类实例有时候是有用的。
为了这种结构建模，UML2提供实例规范元素，它显示在系统中使用例子（或现实）实例的值得注意的信息。
实例的记号和类一样，但是取代顶端区域中仅有的类名，它的名字是经过拼接的:
InstanceName:
ClassName
举例来说（有下划线）：
Donald:
Person
因为显示实例的目的是显示值得注意的或相关的信息，没必要在你的模型中包含整个实体属性及操作。
相反地，仅仅显示感兴趣的属性及其值是完全恰当的。
如图16所描述。
图16：
Plane类的一个实例例子（只显示感兴趣的属性值）
然而，仅仅表现一些实例而没有它们的关系不太实用；因此，UML2也允许在实体层的关系/关联建模。
绘制关联与一般的类关系的规则一样，除了在建模关联时有一个附加的要求。
附加的限制是，关联关系必须与类图的关系相一致，而且关联的角色名字也必须与类图相一致。
它的一个例子显示于图17中。
在这个例子中，实例是图6中类图的例子实例。
图17：
图6中用实例代替类的例子
图17有Flight类的二个实例，因为类图指出了在Plane类和Flight类之间的关系是0或多。
因此，我们的例子给出了两个与NX0337Plane实例相关的Flight实例。
（2）角色
建模类的实例有时比期望的更为详细。
有时，你可能仅仅想要在一个较多的一般层次做类关系的模型。
在这种情况下，你应该使用角色记号。
角色记号类似于实例记号。
为了建立类的角色模型，
升级会员 