UML由图和元模型组成,图是语法,元模型是语义。UML主要包括三个基本构造块:事物(Things)、关系(Relationships)和图(Diagrams)。
1.1 UML的基本构造块
1.1.1事物
事物是是实体抽象化的最终结果,是模型中的基本成员,UML中包含结构事物、行为事物、分组事物和注释事物。
(1)结构事物(Structural things)
结构事物是模型中的静态部分,用以呈现概念或实体的表现元素,是软件建模中最常见的元素,共有以下七种:
类(Class):类是指具有相同属性、方法、关系和语义的对象的集合;
接口(Interface):接口是指类或组件所提供的服务(操作),描述了类或组件对外可见的动作;
协作(Collaboration):协作描述合作完成某个特定任务的一组类及其关联的集合,用于对使用情形的实现建模;
用例(Use Case):用例定义了执行者(在系统外部和系统交互的人)和被考虑的系统之间的交互来实现的一个业务目标;
活动类(Active Class):活动类的对象有一个或多个进程或线程。活动类和类很相象,只是它的对象代表的元素的行为和其他的元素是同时存在的;
组件(Component):组件是物理的、可替换的部分,包含接口的集合,例如COM+ 、JAVA BEANS等;
结点(Node):结点是系统在运行时存在的物理元素,代表一个可计算的资源,通常占用一些内存和具有处理能力。
(2)行为事物(Behavioral things)
行为事物指的是UML模型中的动态部分,代表语句里的"动词",表示模型里随着时空不断变化的部分,包含两类:
交互(ineraction):交互是由一组对象之间在特定上下文中,为达到特定的目的而进行的一系列消息交换而组成的动作;
状态机(state machine):状态机由一系列对象的状态组成。
(3)分组事物(Grouping things)
可以把分组事物看成是一个"盒子",模型可以在其中被分解。目前只有一种分组事物,即包(package)。结构事物、动作事物甚至分组事物都有可能放在一个包中。包纯粹是概念上的,只存在于开发阶段,而组件在运行时存在。
(4)注释事物(Annotational things)
注释事物是UML模型的解释部分。
1.1.2关系
关系是将事物联系在一起的方式,UML中定义了四种关系:
(1)依赖(Dependencies):两个事物之间的语义关系,其中一个事物发生变化会影响另一个事物的语义;
(2)关联(Association):一种描述一组对象之间连接的结构关系,如聚合关系(描述了整体和部分间的结构关系);
(3)泛化(Generalization):一种一般化-特殊化的关系;
(4)实现(Realization) :类之间的语义关系,其中的一个类指定了由另一个类保证执行的契约。
1.1.3图
图是事物集合的分类,UML中包含多种图:
(1)类图(Class Diagram):类图描述系统所包含的类、类的内部结构及类之间的关系;
(2)对象图(Object Diagram):对象图是类图的一个具体实例;
(3)包图(Package Diagram):包图表明包及其之间的依赖类图;
(4)组件图(Compoment Diagram,也称构件图):组件图描述代码部件的物理结构以及各部件之间的依赖关系;
(5)部署图(Deployment Diagram):部署图定义系统中软硬件的物理体系结构;
(6)用例图(Usecase Diagram):用例图从用户的角度出发描述系统的功能、需求,展示系统外部的各类角色与系统内部的各种用例之间的关系;
(7)顺序图(Sequence Diagram):顺序图表示对象之间动态合作的关系;
(8)协作图(Collaboration Diagram):合作图描述对象之间的协作关系;
(9)状态图(Statechart Diagram):状态图描述一类对象的所有可能的状态以及事件发生时状态的转移条件;
(10)活动图(Activity Diagram):活动图描述系统中各种活动的执行顺序。
上述十种图可归纳为五类,如表1.1。
表1.1 UML图分类
类型 | 包含 |
静态图 | 类图、对象图、包图 |
行为图 | 状态图、活动图 |
用例图 | 用例图 |
交互图 | 顺序图、协作图 |
实现图 | 组件图、部署图 |
2.1 用例与用例图
用例是需求分析中最重要的概念,需求表征了一个系统的设计特性、特征和行为,描述一个系统的需求意味着描述了建立在该系统外部的事物与系统之间的契约,契约上声明了期望系统做什么。
我们先来给出一个具体而简单的用例图,即"图书管理系统"用例图,如图2.1。在用例图中主要涉及到参与者(又称角色、执行者)、用例以及二者之间的通讯关联。
图2.1 图书管理系统用例图
参与者
参与者是与系统、子系统或类发生交互的外部用户、进程或其他系统。参与者可以是人、另一个计算机系统或一些可运行的进程。在图2.1中,"读者"和"管理员"即为参与者。参与者之间可以存在泛化关系
用例
用例是外部可见的一个系统功能,这些功能由系统所提供,并通过与参与者之间消息的交换来表达。用例的用途是在不揭示系统内部构造的情况下定义行为序列,它把系统当作一个黑箱,表达整个系统对外部用户可见的行为。
用例之间也可以存在包含、扩展和泛化等关系:
(1)包含关系:用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为做为自身行为的一部分,这被称作包含关系。
(2)扩展关系:扩展关系是从扩展用例到基本用例的关系,它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的,也就是说,扩展用例并不在基本用例中显示。
(3)泛化关系:用例可以被特别列举为一个或多个子用例,这被称做用例泛化。当父用例能够被使用时,任何子用例也可以被使用。
通讯关联
通讯关联用于表示参与者和用例之间的对应关系,它表示参与者使用了系统中的哪些用例(或者说系统所提供的用例被哪些参与者使用)。
通讯关联以箭头或实线表示。若使用箭头,箭头所指方将是对话的被动接受者;如果不强调对话中的主动与被动关系,则可以使用不带箭头的关联实线。
2.2建立用例模型
知道了用例与用例图的概念,我们还需要懂得怎样建立用例模型,即怎样找出参与者、用例以及定义用例的过程。一般来说,建立用例模型的步骤为:
(1)确定谁会直接使用该系统,即参与者(Actor)
(2)选取其中一个参与者;
(3)定义该参与者希望系统做什么,参与者希望系统做的每件事成为一个用例
(4)对每件事来说,何时参与者会使用系统,通常会发生什么,这就是用例的基本过程;
(5)描述该用例的基本过程;
(6)考虑一些可变情况,把他们创建为扩展用例;
(7)复审不同用例的描述,找出其中的相同点,抽出相同点作为共同的用例;
(8)重复步骤2-7找出每一个用例。
3.1类图
在UML中,类图显示了一组类、接口、协作以及它们之间的关系。在UML的静态机制中类图是一个重点,它不但为设计人员所关心,更为实现人员所关注,建模工具也主要依据类图来产生代码(正向)工程。因此,类图在UML的各种图中占据了相当重要的地位。
类
在类图中类用矩形框来表示,它的属性和操作分别列在分格中,若不需要表达详细信息时,分格可以省略。一个类可能出现在好几个图中。同一个类的属性和操作只在一种图中列出,在其他图中可省略。
类间关系
在类图中,除了需要描述单独的类的名称、属性和操作外,我们还需要描述类之间的联系,因为没有类是单独存在的,它们通常需要和别的类协作,创造比单独工作更大的语义。在UML类图中,关系用类框之间的连线来表示,连线上和连线端头处的不同修饰符表示不同的关系。类之间的关系有继承(泛化)、关联、聚合和组合。
(1)继承:指的是一个类(称为子类)继承另外的一个类(称为基类)的功能,并增加它自己的新功能的能力,继承是类与类之间最常见的关系。类图中继承的表示方法是从子类拉出一条闭合的、单键头(或三角形)的实线指向基类。
(2)关联:指的是模型元素之间的一种语义联系,是类之间的一种很弱的联系。关联可以有方向,可以是单向关联,也可以是双向关联。可以给关联加上关联名来描述关联的作用。关联两端的类也可以以某种角色参与关联,角色可以具有多重性,表示可以有多少个对象参与关联。可以通过关联类进一步描述关联的属性、操作以及其他信息。关联类通过一条虚线与关联连接。对于关联可以加上一些约束,以加强关联的含义。
(3)聚合:指的是整体与部分的关系。通常在定义一个整体类后,再去分析这个整体类的组成结构。从而找出一些组成类,该整体类和组成类之间就形成了聚合关系。例如一个航母编队包括海空母舰、驱护舰艇、舰载飞机及核动力攻击潜艇等。需求描述中“包含”、“组成”、“分为…部分”等词常意味着聚合关系。
(4)组合:也表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在,部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。
聚合和组合的区别在于:聚合关系是“has-a”关系,组合关系是“contains-a”关系;聚合关系表示整体与部分的关系比较弱,而组合比较强;聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关,一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象,同时也就删除了代表部分事物的对象。
接下来,我们给出建立类图的步骤:
(1)研究分析问题领域确定系统需求;
类的识别是一个需要大量技巧的工作,寻找类的一些技巧包括:名词识别法;根据用例描述确定类;使用CRC分析法;根据边界类、控制类、实体类的划分来帮助分析系统中的类;参考设计模式确定类;对领域进行分析或利用已有领域分析结果得到类;利用RUP中如何在分析和设计中寻找类的步骤。
(2)确定类,明确类的含义和职责、确定属性和操作;
(3)确定类之间的关系。
3.2对象图
对象图显示某时刻对象和对象之间的关系,是类图的变化,一个对象图可看成一个类图的示例(example),对象图表示的是类的对象实例而不是真实的类。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
对象图中并无新的表示法(除了对象名下要加下划线以外),与类图中的表示法一样,可以认为,只有对象而无类的类图就是一个“对象图”。
在对象图中,对象名可以有三种表示形式:
(1)对象名:类名
(2):类名
(3)对象名
实质上,对象图几乎很少被用到(它包含的信息量太小,仅仅用于呈现某一时刻对象的值,对软件的设计几乎没有太大的帮助),使用远没有类图广泛。
4.1消息
在面向对象领域,两个对象的交互是通过消息的发送和接收来完成的。消息分为简单消息、同步消息和异步消息:
(1)简单消息:只是表示控制如何从一个对象发给另一个对象,并不包含控制的细节;
(2)同步消息:同步意味着阻塞和等待,如果对象A给对象B发送一个消息,对象A会等待对象B执行完这个消息,接着才进行自身的工作;
(3)异步消息:异步意味着非阻塞,如果对象A给对象B发送一个消息,对象A不必等待对象B执行完这个消息,就可以接着进行自身的工作
4.2顺序图
顺序图(也称序列图)是一种交互图(Interaction Diagram,用于描述执行系统功能的各个角色之间相互传递消息的顺序关系,显示跨越多个对象的系统控制流程),强调的是时间和消息的次序,用来说明系统的动态情况,顺序图由参与者、对象、对象生命线和消息组成。一个顺序图显示了一系列的对象(通常是类的实例,也可以代表其他事物的实例,例如协作、组件和节点)和在这些对象之间发送和接收的消息。
图4.2 购买商品顺序图
4.3状态图
状态图是UML中的状态机视图。状态机由对象的各个状态和连接这些状态的转换组成。每个状态对一个对象在其生命期中满足某种条件的一个时间段建模,当一个事件发生时,它会触发状态间的转换,导致对象从一种状态转化到另一新的状态。与转换相关的活动执行时,转换也同时发生。
状态图用于描述对象可以拥有的状态以及引起状态相互转移的事件和条件,它揭示了对象的生命周期,是针对类的一种建模工具。状态是对象前一次操作的结果,事件是引起状态向另一状态转化的活动。所有对象都有状态,但通常只对具有复杂行为的类建立状态图。状态图强调的是事件驱动的对象的动作,这在对反应式系统的建模是相当重要的。
图4.4 GPS终端的状态图
4.4 活动图
活动图用于描述系统、用例、程序模块中的逻辑流程的先后执行次序、并行次序,是对人类组织的现实世界中的工作流程的建模,有助于理解系统高层活动的执行行为。
活动图中的主要概念是"活动",而"活动"的具体含义又取决于作图目的和抽象层次:
(1)当活动图用于描述系统行为时,主要侧重于系统多个用例活动之间相互制约的执行顺序,同时,识别出系统中存在的可以并行进行的用例,此时,活动表示系统要完成的任务;
(2)当活动图用于描述用例时,用于描述用例中的操作执行次序和操作完成的结果,显示多个对象的操作是如何相互结合起来共同完成用例的一个脚本,揭示出操作之间的并行性,为编码实现提供开发并行程序的便利,此时,活动表示类中的方法,即操作。允许将某个组织或执行者要完成的若干操作聚集在泳道中,以明确责任。
活动图用于低层次程序模块的作用类似于流程图,但活动图还可以描述并行操作,而流程图则只能描述串行操作。
4.5协作图
与顺序图一样,协作图也是一种交互图,用于描述对象之间的协作关系,其模型元素与序列图的基本相同,但它侧重于描述对象之间是如何相互连接的,强调的是发送和接收消息的对象之间的组织结构。顺序图着重体现对象间消息传递的时间顺序,协作图着重于哪些对象间有消息传递,表达了对象之间的静态连接关系。顺序图和协作图是同构的,它们相互之间可以转化而不损失信息,依靠工具协作图和顺序图可互相转换。
4.6 UML图之间的关系
连载2-4给出了多种类型的图,这些图之间存在着或直接或间接的关系(如图4.8),这体现了UML中的辩证法。
图4.8 UML图的关系
用例图主要用来描述系统的外部行为;类图和对象图用来定义类和对象以及它们的属性和操作;状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件;顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图强调对象间的动态合作关系;活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
除此之外,我们还没有详细讲解的包图用于描述系统的分层结构,构件图描述代码部件的物理结构及各部件之间的依赖关系,配置图定义系统中软硬件的物理体系结构。
版权声明:本文为博主原创文章,未经博主允许不得转载。