UML中各种图的画法全Word格式.docx
《UML中各种图的画法全Word格式.docx》由会员分享,可在线阅读,更多相关《UML中各种图的画法全Word格式.docx(23页珍藏版)》请在冰豆网上搜索。
![UML中各种图的画法全Word格式.docx](https://file1.bdocx.com/fileroot1/2022-11/15/2feafdb0-ba44-482e-91bd-8fa74bde3e07/2feafdb0-ba44-482e-91bd-8fa74bde3e071.gif)
当在一个类图上画一个类元素时,你必须要有顶端的区域,下面的二个区域是可选择的(当图描述仅仅用于显示分类器间关系的高层细节时,下面的两个区域是不必要的)。
·
类名:
如果是抽象类,则采用斜体
类属性列表:
name:
attributetype
如flightNumber:
Integer,这是最常见的表达形式
attributetype=defaultvalue
如
balance:
Dollars=0,这是带有默认值的表达形式
类方法列表:
name(parameterlist):
typeofvaluereturned
注意:
在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。
然而,用于生成代码的类图,要求类的属性类型必须限制在由程序语言提供的类型之中,或包含于在系统中实现的、模型的类型之中。
2.继承的表示:
为了在一个类图上建模继承,从子类(要继承行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。
类名BankAccount和withdrawal操作使用斜体。
这表示,BankAccount类是一个抽象类,而withdrawal方法是抽象的操作。
换句话说,BankAccount类使用withdrawal规定抽象操作,并且CheckingAccount和SavingsAccount两个子类都分别地执行它们各自版本的操作。
3.接口的表示:
一个类和一个接口不同:
一个类可以有它形态的真实实例,然而一个接口必须至少有一个类来实现它。
在UML2中,一个接口被认为是类建模元素的特殊化。
因此,接口就象类那样绘制,但是长方形的顶部区域也有文本“interface”。
继承用带箭头或三角形的实线表示,实现用带箭头或三角形的虚线表示
4.可见性的表示:
在面向对象的设计中,存在属性及操作可见性的记号。
UML识别四种类型的可见性:
public,protected,private及package。
UML规范并不要求属性及操作可见性必须显示在类图上,但是它要求为每个属性及操作定义可见性。
为了在类图上显示可见性,放置可见性标志于属性或操作的名字之前。
虽然UML指定四种可见性类型,但是实际的编程语言可能增加额外的可见性,或不支持UML定义的可见性。
表4显示了UML支持的可见性类型的不同标志。
UML支持的可见性类型的标志
标志
可见性类型
+
Public
#
proteted
-
private
~
package
5.关联的表示:
双向(标准)的关联
关联是两个类间的联接。
关联总是被假定是双向的;
这意味着,两个类彼此知道它们间的联系,除非你限定一些其它类型的关联。
一个双向关联用两个类间的实线表示。
在线的任一端,你放置一个角色名和多重值。
图6显示Flight与一个特定的Plane相关联,而且Flight类知道这个关联。
因为角色名以Plane类表示,所以Plane承担关联中的“assignedPlane”角色。
紧接于Plane类后面的多重值描述0...1表示,当一个Flight实体存在时,可以有一个或没有Plane与之关联(也就是,Plane可能还没有被分配)。
图6也显示Plane知道它与Flight类的关联。
在这个关联中,Flight承担“assignedFlights”角色;
图6的图告诉我们,Plane实体可以不与flight关联(例如,它是一架全新的飞机)或与没有上限的flight(例如,一架已经服役5年的飞机)关联。
关联的一方关联对象位于直线的上端,关联数目位于同侧的直线下端,另一方则相反
多重值和它们的表示
可能的多重值描述
表示
含义
0..1
0个或1个
1
只能1个
0..*
0个或多个
*
1..*
1个或多个
3
只能3个
0..5
0到5个
5..15
5到15个
单向关联
在一个单向关联中,两个类是相关的,但是只有一个类知道这种联系的存在。
一个单向的关联,表示为一条带有指向已知类的开放箭头(不关闭的箭头或三角形,用于标志继承)的实线。
如同标准关联,单向关联包括一个角色名和一个多重值描述,但是与标准的双向关联不同的时,单向关联只包含已知类的角色名和多重值描述。
简单的说就是OverdrawAccountReport中包含了BankAccount属性,而BankAccount中不需要包含OverdrawnAccountsReport对象
6.聚合的表示:
聚合是一种特别类型的关联,用于描述“总体到局部”的关系。
在基本的聚合关系中,部分类的生命周期独立于整体类的生命周期。
举例来说,我们可以想象,车是一个整体实体,而车轮轮胎是整辆车的一部分。
轮胎可以在安置到车时的前几个星期被制造,并放置于仓库中。
在这个实例中,Wheel类实例清楚地独立于Car类实例而存在。
然而,有些情况下,部分类的生命周期并不独立于整体类的生命周期--这称为合成聚合。
举例来说,考虑公司与部门的关系。
公司和部门都建模成类,在公司存在之前,部门不能存在。
这里Department类的实例依赖于Company类的实例而存在。
让我们更进一步探讨基本聚合和组合聚合。
聚合与普通的关联的区别在于:
普通的关联可能只是一个简单的“包含、引用”关系,关联和被关联类之间在逻辑概念上不一定有紧密的联系,而聚合则不同,它表示的是一种内在关系紧密,相互依存,相互包含的概念,其中的一部分是构成另外一部分的不可或缺的成分。
基本聚合
有聚合关系的关联指出,某个类是另外某个类的一部分。
在一个聚合关系中,子类实例可以比父类存在更长的时间。
为了表现一个聚合关系,你画一条从父类到部分类的实线,并在父类的关联末端画一个未填充棱形。
图中清楚的表明了类Car对象包含了另一类Wheel的4个实例,这两者在概念上是密不可分的,其中的一个类是另一个类的构成成分。
菱形表示“包含”,箭头表示被包含的对象,数字4表示包含的数目。
组合聚合
组合聚合关系是聚合关系的另一种形式,但是子类实例的生命周期依赖于父类实例的生命周期。
注意:
组合关系如聚合关系一样绘制,不过这次菱形是被填充的。
7.反射关联的表示:
类也可以使用反射关联与它本身相关联。
起先,这可能没有意义,但是记住,类是抽象的。
当一个类关联到它本身时,这并不意味着类的实例与它本身相关,而是类的一个实例与类的另一个实例相关。
图描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。
然而,因为“manages”的关系角色有0..*的多重性描述;
一个雇员可能不受任何其他雇员管理。
三、UML中的对象图:
实例的记号和类一样,但是取代顶端区域中仅有的类名,它的名字是经过拼接的:
InstanceName:
ClassName如Donald:
Person
因为显示实例的目的是显示值得注意的或相关的信息,没必要在你的模型中包含整个实体属性及操作。
相反地,仅仅显示感兴趣的属性及其值是完全恰当的。
UML2也允许在实体层的关系/关联建模。
绘制关联与一般的类关系的规则一样,除了在建模关联时有一个附加的要求。
附加的限制是,关联关系必须与类图的关系相一致,而且关联的角色名字也必须与类图相一致。
四、UML中的角色图:
建模类的实例有时比期望的更为详细。
有时,你可能仅仅想要在一个较多的一般层次做类关系的模型。
在这种情况下,你应该使用
角色
记号。
角色记号类似于实例记号。
为了建立类的角色模型,你画一个方格,并在内部放置类的角色名及类名,作为实体记号,但是在这情况你不能加下划线。
角色图和对象图的一个明显区别就是:
对象图每个对象名称下面都加了下划线,而角色图没有
以下是:
序列图
序列图主要用于按照交互发生的一系列顺序,显示对象之间的这些交互。
很象类图,开发者一般认为序列图只对他们有意义。
然而,一个组织的业务人员会发现,序列图显示不同的业务对象如何交互,对于交流当前业务如何进行很有用。
除记录组织的当前事件外,一个业务级的序列图能被当作一个需求文件使用,为实现一个未来系统传递需求。
在项目的需求阶段,分析师能通过提供一个更加正式层次的表达,把用例带入下一层次。
那种情况下,用例常常被细化为一个或者更多的序列图。
组织的技术人员能发现,序列图在记录一个未来系统的行为应该如何表现中,非常有用。
在设计阶段,架构师和开发者能使用图,挖掘出系统对象间的交互,这样充实整个系统设计。
序列图的主要用途之一,是把用例表达的需求,转化为进一步、更加正式层次的精细表达。
用例常常被细化为一个或者更多的序列图。
序列图除了在设计新系统方面的用途外,它们还能用来记录一个存在系统(称它为“遗产”)的对象现在如何交互。
当把这个系统移交给另一个人或组织时,这个文档很有用。
Java应用程序由许多类所构成,是Java实现面向对象应用程序的核心。
类图主要描述Java应用程序中各种类之间的相互静态关系,如类的继承、抽象、接口以及各种关联。
要利用UML设计Java应用程序,仅仅使用类图来描述这些静态关系,利用可视化工具,要实现Java应用程序的代码自动生成,是远远不够的。
我们还必须描述各种类相互之间的协作关系、动态关系,如时间序列上的交互行为。
其中UML序列图就是用来描述类与类之间的方法调用过程(或消息发送)是如何实现的。
一、UML中的新元素-框架:
在UML2中,框架元件用于作为许多其他的图元件的一个基础,但是大多数人第一次接触框架元件的情况,是作为图的图形化边界。
当为图提供图形化边界时,一个框架元件为图的标签提供一致的位置。
在UML图中框架元件是可选择的。
除了提供一个图形化边框之外,用于图中的框架元件也有描述交互的重要的功能,例如序列图。
在序列图上一个序列接收和发送消息(又称交互),能通过连接消息和框架元件边界,建立模型(如图2所见到)。
对于序列图,图的标签由文字“sd”开始。
当使用一个框架元件封闭一个图时,图的标签需要按照以下的格式:
图类型图名称。
UML规范给图类型提供特定的文本值。
(举例来说,sd代表序列图,activity代表活动图,usecase代表用例图)。
二、UML中的序列图:
序列图主要