一UML中的事物
构成模型图的一些基本图示符号,它们表示一些面向对象的基本概念。
UML中有四类事物:
Structural Things(结构事物),
Behavioral Things(行为事物),
Group Things(分组事物),
Annotational Things(注释事物)。
二 UML中的四类事物(Things)
(1)结构事物
结构事物是模型中的静态部分,用以呈现概念或实体的表现元素,是软件建模中最常见的元素,共有以下七种:
A类(class)
类是对一组具有相同属性、方法、关系和语义的对象的描述。一个类实现一个或多个接口。
UML图示符号:
B接口(interface)
接口描述了一个类或构件的一个服务的操作集,接口仅仅是定义了一组操作的规范,它并没有给出这组操作的具体实现。
UML图示符号:
C协作(collaboration)
协作定义了一个交互,它是由一组共同工作以提供某协作的角色和其他元素构成的群体,这些协作行为大于所有元素的各行为的总和。因此,协作有结构、行为和维度。一个给定的类可以参与几个协作。
UML图示符号:
D用例(use case)
用例是对一组动作序列的描述,系统执行这些动作将产生一个对特定的参与者有价值且可观察的结果。
UML图示符号:
E主动类(active class)
主动类是这样的一种类,其对象至少拥有一个进程或线程,因此它能控制活动。
UML图示符号:
F构件(component)
构件是系统中物理的、可替代的部件,它遵循且提供一组接口的实现。
UML图示符号:
G节点(node)
节点是在运行时存在的物理元素,它表示了一种可计算的资源,它通常至少有一记忆能力处理能力。一个构件集可以驻留在一个节点内,也可以从一个节点迁移到另一个节点。
UML图示符号:
(2)行为事物
行为事物是UML模型的动态部分。它们是模型中的动词,描述了跨越时间和空间的行为。共有两类主要的行为事物。
A交互(interaction)
交互是这样一种的行为,他由在特定语境中共同完成一定特定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可用一个交互来描述。
interaction涉及一些其他元素,包括消息、动作序列(由一个消息所引起的行为)、links(对象间的连接)。
UML图示符号:
B状态机(state machine)
状态机是这样一种行为,描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素,包括状态转换(发转换的事物)和活动(对一个转换的响应)。
UML图示符号:
(3)分组事物
分组事物是UML模型的组织部分,最主要的分组事物是包(package)。
包(package)
包是把元素组织成组的机制;包是UML中唯一的组织机制。
UML图示符号:
包可以拥有其他元素,这些元素可以是类、接口、构件、节点、协作、用例和图,甚至可以是其他包。
一个包形成了一个命名空间。在一个包中同一种元素的名称必须是唯一的。不同种类的元素可以有相同的名称。
(4)注释事物
注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。有一种主要的注释事物,称为注解。
注解(note)
注解是一个依附于一个元素或一组元素之上,对它进行约束或解释的简单符号。
UML图示符号:
UML有表示基本图示符号之间的关系,它们是:
A、依赖(dependency)
B、 泛化(generalization,也有的称继承)
C、实现(realization)
D、关联(association):而关联又分为普通关联(common association)、聚合(aggregation,也有的称聚集)和组合(composition)。
A依赖(dependency)
依赖关系表示为一个类A使用另一个类B,这种使用关系是具有偶然性的、临时性的、非常弱的,但是类B的变化会影响到类A,是use a关系。
表现在生活中,比如某人要过河,需要借用一条船,此时人与船之间的关系就是依赖;表现在代码层面如果类A依赖于类B,那么类B可以是类A的局部变量,或类A方法的参数,或静态方法的调用。
图示:虚线加箭头(箭头指向的是被依赖的那一方)
举例:
说明:动物有几大特征,比如有新陈代谢,能繁殖。而动物要有生命力,需要氧气、水以及食物等。也就是说,动物依赖氧气和水。他们之间是依赖关系(dependency),用虚线加箭头来表示。
我们再来看一个代码层面上的例子:
说明:如果两个类有结构关系(关联关系),那么就不用依赖关系(两个事物一般都有这个关系)。
B泛化(generalization)
泛化即继承关系。泛化是一种特殊/一般关系,特殊元素(子元素)的对象可替代一般元素(父元素)的对象。用这种方法,子元素共享了父元素的结构和行为。是is-a关系,具体表现为类与类的继承,接口与接口的继承。
泛化指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可以增加它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系;在Java中此类关系通过关键字extends明确标识,在设计时一般没有争议性。
图示:实线+空心三角
举例:
C实现(realization)
实现是类元之前的语义关系,在该关系中一个类元描述了另一个类元保证实现的契约。实现指的是一个class类实现interface接口(可以是多个)的功能;实现是类与接口之间最常见的关系;在Java中此类关系通过关键字implements明确标识,在设计时一般没有争议性。
图示:虚线+空心箭头
举例:
D关联(association)
关联描述了两个或多个类之间的结构性关系。表示类与类之间的联接,它使一个类知道另一个类的属性和方法。关联体现的是两个类、或者类与接口之间语义级别的一种强依赖关系,比如我和我的朋友;这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的,一般是长期性的,而且双方的关系一般是平等的、关联可以是单向、双向的;表现在代码层面,假如类A关联了类B,则类B是类A的全局变量(注意是全局变量,再看看上面的依赖关系),大多数关联都是单向关联,这比较容易维护,关于关联,在生活中我们常会说,类A持有类B的引用。为被关联类B以类属性的形式出现在关联类A中,也可能是关联类A引用了一个类型为被关联类B的全局变量。
(1)普通关联(common association)
1)Association name名称:用以描述该关系的性质。
2)Role角色:当一个类处于关联的某一端时,该类就在这个关系中扮演了一个特定的角色;角色是关联中靠近它的一端的类对另外一端的类呈现的职责。
3)Multiplicity多重性:关联角色的多重性是说明一个关联的实例中有多少个相互连接的对象。
图示:直线
举例:
(2)聚合(aggregation)
聚合关系是特殊的关联关系,是一种强的关联关系,他体现的是整体与部分关系,即has-a的关系,但是整体和部分是可以分离的,注意,是可以分离的。他们可以具有各自的生命周期,部分可以属于多个整体对象,也可以为多个整体对象共享;比如计算机CPU、公司与员工的关系等;表现在代码层面,和关联关系是一致的,只能从语义级别来区分。
普通关联关系的两个类处于同一层次上,是平级的,而聚合关系的两个类处于不同的层次,一个是整体,一个是部分。同时,是一种弱的“拥有”关系。体现的是A对象可以包含B对象,但B对象不是A对象的组成部分。具体表现为,如果A由B聚合成,表现为A包含有B的全局对象,但是B对象可以不在A创建的时刻创建,这句话非常有意义,它在代码中通常体现成依赖注入的setter方法,即A对象可以随时创建B对象,再想想这不就体现了整体和部分是可以分离了吗?创建整体的时候可以不创建部分。
图示:空心菱形+实线+箭头
举例:
(3)组合(Composition)
组合也是关联关系的一种特例,他体现的是一种contains-a(拥有)的关系,这种关系比聚合更强,也称为强聚合;它同样体现整体与部分间的关系,但此时整体与部分是不可分的,整体的生命周期结束也就意味着部分的生命周期结束;比如你和你的大脑;表现在代码层面,和关联关系是一致的,只能从语义级别来区分;表现在代码层面上,如果A由B组成,那么A就包含B的全局变量,并在创建A的同时创建B,在代码上我们通常是使用构造函数进行实现,也是依赖注入中构造函数的实现。
图示:实心菱形+实线+箭头
举例:
E总结
最后,我们来总结一下,泛化和实现就不用多少了,大家都懂的,就是继承和实现接口,重点说下其它的吧,依赖,ClassB体现为ClassA的局部变量,我想用就用,用了就有关系,不用就没关系;关联,ClassB体现为ClassA的全局变量,不管你用不用,反正你知道我的存在了,持有了我的引用。聚合,是特殊的关联关系,用了就加强了关系,不用还是我只知道你的存在。聚合可以方便的持有多个类的引用,如使用List<>,所以当你发现有List<>等集合是可以使用聚合来表示,比如观察者模式的结构。组合,体现最强关系,比如人出身了,必定也有头部吧,不然我真无法想象这个世界了。
涵盖上述四种关系的一个类图:
解释:
1)Window类实现了AbstractWindow接口。
2)ConsoleWindow类和DialogBox类都继承(泛化)自Window类。
3)Window类依赖于Event类,也就是Window类会使用到Event类。
4)Dialog类和Control类互相关联。
0 3【UML基本构造块之三:图】一UML基本构造块之图
UML基本构造块的图是在特定的视角下对系统所作的抽象描述。图是事物集合的分类,UML中包含多种图。我们先来看分类:
UML定义了5类,10种模型图:下图加上非UML规范的包图
五类图定义:
1用例图:从用户角度描述系统功能,并指各功能的操作者。
2静态图:包括类图,包图,对象图。
2.1类图:描述系统中类的静态结构。
2.2包图:是包和类组成的,表示包与包之间的关系,包图描述系统的分层结构。
2.3对象图:是类图的实例。
3行为图:描述系统动态模型和对象组成的交换关系。包括状态图和活动图。
3.1活动图:描述了业务实现用例的工作流程。
3.2状态图:是描述状态到状态控制流,常用于动态特性建模。
4.交互图:描述对象之间的交互关系,包括顺序图和协作图。
4.1顺序图:对象之间的动态合作关系,强调对象发送消息的顺序,同时显示对象之间的交互。
4.2协作图:描述对象之间的协助关系。
5.实现图:
5.1部署图:定义系统中软硬件的物理体系结构。
5.2构件图:描述代码部件的物理结构及各部件之间的依赖关系。
二UML五类十种图概述
1用例图:
(1)用例图(Use-case Diagram)
用例图从用户的角度出发描述系统的功能、需求,展示系统外部的各类角色与系统内部的各种用例之间的关系;用例图描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统,以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素,如系统、参与者和用例,并且显示了这些元素之间的各种关系,如泛化、关联和依赖。
用例图用来描述用户的需求,从用户的角度描述系统的功能,并指出各功能的执行者,强调谁在使用系统,系统为执行者完成哪些功能。
示例:
2静态图:
(2)类图(Class Diagram)
类图用于定义系统中的类,包括描述系统所包含的类、类的内部结构及类之间的关系。类图主要用于描述系统的静态结构。
类图是描述系统中的类,以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型,确切的说,是一种静态模型类型。类图表示类、接口和它们之间的协作关系。
如下图(摘自网络):
(3)对象图(Object Diagram)
对象图与类图极为相似,它是类图的一个具体实例,对象图显示类的多个对象实例,而不是实际的类。它描述的不是类之间的关系,而是对象之间的关系。对象图描述了系统在具体时间点上所包含的对象以及各个对象之间的关系。
如下图(摘自网络):
(4)包图(Package Diagram)
包图表明包及其之间的依赖类图,用于描述系统的分层结构,由包或类组成,表示包与包之间的关系。
如下图(摘自网络):
3 行为图:
(5)状态图(Statechart Diagram)
状态图描述一类对象的所有可能的状态以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态,并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类;该图可以确定类的行为,以及该行为如何根据当前的状态变化,也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。
如下图(摘自网络):
(6)活动图(Activity Diagram)
活动图描述系统中各种活动的执行顺序,描述用例要求所要进行的活动,以及活动间的约束关系,有利于识别并行活动。能够演示出系统中哪些地方存在功能,以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
如下图(摘自网络):
4 交互图:
(7)顺序图(Sequence Diagram,也称为序列图)
顺序图表示对象之间动态合作的关系。描述对象之间的交互顺序,着重体现对象间消息传递的时间顺序,强调对象之间消息的发送顺序,同时也显示对象之间的交互顺序。
顺序图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上,即强调消息是如何在对象之间被发送和接收的。
如下图(摘自网络):
(8)协作图(Collaboration Diagram,也称合作图)
协作图描述对象之间的协作关系,更侧重于说明哪些对象之间有消息的传递。和顺序图相似,显示对象间的动态合作关系。可以看成是类图和顺序图的交集,协作图建模对象或者角色,以及它们彼此之间是如何通信的。
如下图(摘自网络):
如果强调时间和顺序,则使用序列图;如果强调上下级关系,则选择协作图;这两种图合称为交互图。序列图和协作图可以相互转化。
5 实现图:
(9)构件图(Compoment Diagram,也称组件图)
组件图描述代码部件的物理结构以及各部件之间的依赖关系。一个构件可以是一个资源文件、一个二进制文件或者一个可执行文件。
构件图用来建模软件的组件及其相互之间的关系,这些图由构件标记符和构件之间的关系构成。在构件图中,构件是软件单个组成部分,它可以是一个文件,产品、可执行文件和脚本等。
如下图(摘自网络):
(10)部署图(Deployment Diagram,也称实施图或配置图)
部署图定义系统中软硬件的物理体系结构,用来描述实际的物理设备以及它们之间的连接关系。部署图是用来建模系统的物理部署。例如计算机和设备,以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。部署图用于表示一组物理结点的集合及结点间的相互关系,从而建立了系统物理层面的模型。
如下图(摘自网络):
三UML建模机制
从应用的角度看,当采用面向对象方法设计系统时:
首先是描述需求;
其次根据需求建立系统的静态模型,以构造系统的结构;
第三步是描述系统的行为。
其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和部署图等五个图形,是标准建模语言UML的静态建模机制。第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括UML模型图中状态图、活动图、顺序图和协作图等四个图形,是标准建模语言UML的动态建模机制。
因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。
四UML简单示例
显示"Hello World"的简单Java Applet程序,先来看一下代码:
import java.awt.Graphics;
public class HelloWorld extends java.applet.Applet{
public void paint(Graphics g){
g.drawString("Hello World!",10,20);
}
}
根据以上代码结合UML画出下面的几种UML图:
类:
类的关系:
继承层次:
包:
序列图:
构件图:
五UML在软件开发各个阶段的应用
在软件开发各个阶段,使用不同的UML图对系统进行描述。
采用面向对象方法设计软件系统时,使用用例图来描述用户需求;使用类图、对象图、包图、构件图和部署图这5种静态图来描述系统的静态结构;使用顺序图、合作图、活动图和状态图这4种图描述系统动态行为。
需求:采用用例图来描述需求(角色,功能、外部交互)
分析:明确解决问题的细节;采用类图来描述静态结构;采用顺序图、合作图、活动图、状态图来描述动态行为。
设计:给出解决方案;采用类图、包,对类的接口进行设计。
实现:将类用某面向对象语言实现
集成与交付:构建图、包、部署图
测试:单元测试使用类图和类的规格说明书;集成测试使用类图、包、构件图和合作图;系统测试使用用例图测试系统功能。
0 4【UML基本构造块之四:总结】事物是对模型中最具有代表性的成分的抽象;
关系把事物结合在一起;
图聚集了相关的事物。
转自:CSDN