关于UML（Unified Model Language：统一建模语言）的相关说明

3.1 UML概述

UML是一个通用的可视化建模语言，是用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。其中制品是指软件开发过程中产生的各种产物，例如模型、源代码、测试用例等。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域及各种开发工具。

3.1.1 UML的产生背景

随着UML被OMG采纳为标准，面向对象领域的方法学大战也宣告结束，这些方法的提出者很多也开始转向UML方面的研究。UML的出现为面向对象建模语言的历史翻开了新的一页，并受到工业界、学术界及用户的广泛支持，它融入了软件工程领域的新思想、新方法和新技术，成为面向对象技术领域占主导地位的建模语言。UML代表了面向对象软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值。

3.1.2 什么是UML

作为一种语言，UML定义了一系列的图形符号来描述软件系统。这些图形符号有严格的语义和清晰的语法。这些图形符号及其背后的语义和语法组成了一个标准，使得软件开发的所有相关人员都能用它来对软件系统的各个侧面进行描述。模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。一个模型元素可以用在多个不同的图中，无论怎样使用，它总是具有相同的含义和相同的符号来表示。

UML可以描述一个系统的静态结构和动态行为，从不同但相互联系的角度对系统建立的模型可用于不同的目的。UML将系统描述为一些离散的相互作用的对象，通过静态结构定义系统中对象的属性和操作及这些对象之间的相互关系。动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。UML还可将模型分解成包的结构组件，以便于软件开发组织将大的系统分解成易于处理的块结构，并理解和控制各个包之间的依赖关系，在复杂的开发环境中管理模型单元。

UML标准并没有定义一种标准的开发过程，但它适用于迭代式的开发过程。它是为支持大部分现存的面向对象开发过程而设计的。UML不是一门程序设计语言，但可以使用代码生成器工具将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML。

UML的主要特点可以归纳为以下几点。

①统一的标准。UML是被OMG（OMG：Object Management Group 是一个国际化的、开放成员的、非盈利性的计算机行业标准协会，该协会成立于1989年。）接受为标准的建模语言，越来越多的开发人员使用UML进行软件开发，越来越多的厂商支持UML。

②面向对象。UML是支持面向对象软件开发的建模语言。

③概念明确，建模表示法简洁，图形结构清晰，可视化、表示能力强大，容易掌握和使用。

④独立于过程。UML不依赖于特定的软件开发过程。

3.1.3 UML中的视图

对于复杂系统建模需要从多个不同的方面来描述。UML用视图来表示被建模系统的各个方面，它是在某一个抽象层次上对系统的抽象表示。UML把软件模型划分为5个视图，每一个视图代表完整系统描述的投影，显示系统的一个特定方面。每一个视图又由一种或多种模型图构成。模型图描述了构成相应视图的基本模型元素及它们之间的相互关系。一个特定视图中的图应该足够简单，便于交流，而且一定要与其他图和视图连贯一致，因而所有视图结合在一起(通过它们各自的图)就描述了系统的完整画面。图3-1显示了UML的视图。另外，通过视图可以把建模语言和系统开发时选择的方法或过程连接起来。

图3-1 UML的视图

1．用例视图

用例视图(Use Case View)用来支持软件系统的需求分析，它定义系统的边界，关注的是系统应该交付的功能，也就是外部参与者所看到的功能。它从系统参与者的角度描述系统的外部行为和静态的功能组合。用例视图的使用者是客户、开发人员及测试人员。客户对系统的期望用法(也就是要求的功能)被当作多个用例在用例视图中进行描述，一个用例就是对系统的一个用法的通用描述。

用例视图是核心，因为它的内容驱动其他视图的开发。系统的最终目标，也就是系统将提供的功能是在用例视图中描述的。同时该视图还有其他一些非功能特性的描述，因此，用例视图将会对所有其他的视图产生影响。另外，通过测试用例视图，可以检验和最终校验系统。这种测试来自两个方面：一方面是客户，可以询问客户“这是您想要的吗?”；另一个方面就是已完成的系统，可以询问“系统是按照要求的方式运作的吗?”。

2．逻辑视图

逻辑视图(Logical View)定义系统的实现逻辑。它描述了为了实现用例视图中提出的系统功能，在对软件系统进行设计时所产生的设计概念(设计概念又称为软件系统的设计词汇)。逻辑视图的使用者主要是开发人员和设计人员。它关注系统的内部，既描述系统的静态结构(类、对象及它们之间的关系)，也描述系统内部的动态协作关系。这种协作发生在为了实现既定功能，各对象之间进行消息传递的时刻。另外，逻辑视图也定义像永久性和并发性这样的特性，同时还定义类的接口和内部结构。对逻辑视图的描述在原则上与软件系统的实现平台无关。它的图形模型包括类图、对象图、状态图、顺序图、协作图及活动图等。

3．组件视图

组件视图(Component View)描述系统的实现模块及它们之间的依赖关系。它的使用者主要是开发人员。组件是不同类型的代码模块，通过代码模块的结构和依赖关系来表示。组件视图中也可以添加组件的其他附加的信息，例如资源分配(为组件服务)或者其他管理信息(如开发工作的进度报告)等。

4．实现视图

实现视图(Implementation View)描述的是组成一个软件系统的各个物理部件，这些部件以各种方式(例如，不同的源代码经过编译，构成一个可执行系统；或者不同的软件组件配置成为一个可执行的系统；以及不同的网页文件，以特定的目录结构，组成一个网站等)组合起来，构成一个可实际运行的系统。实现视图的使用者是开发人员和系统集成人员。该视图由动态图(状态图、协作图，以及活动图)和实现图(组件图和部署图)组成。

5．部署视图

部署视图(Deployment View)描述软件系统在计算机硬件系统和网络上的安装、分发和分布情况。例如，计算机和设备(节点)，以及它们之间是如何连接的。部署视图的使用者是开发人员、系统集成人员和测试人员，并且该视图由部署图表示。部署视图也包括一个显示组件如何在物理结构中部署的映射，例如一个程序或对象在哪台计算机上执行。

3.2 UML的构成

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。

3.2.1  UML的体系结构

UML的体系结构如图3-2所示。UML由三部分组成：基本构造块、规则和公用机制。

图3-2 UML的构成图

 

其中基本构造块又包括三种类型：事物、关系和图。事物划分为以下四种类型。

①结构事物。包括类、接口、协作、用例、主动类、组件和节点。

②行为事物。包括交互机和状态。

③分组事物。UML中的分组事物是包。整个模型可以看成是一个根包，它间接包含了模型中的所有内容。子系统是另一种特殊的包。

④注释事物。注释给建模者提供信息，它提供了关于任意信息的文本说明，但是没有语义作用。

3.2.2 UML的模型元素

UML把可以在图中使用的概念统称为模型元素。UML用丰富的图形符号隐含表示了模型元素的语法，而用这些图形符号组成元模型表达语义，组成模型描述系统结构(或称为静态特征)以及行为(或称为动态特征)。

 

图3-3

UML定义了两类模型元素的图形表示。一类模型元素用于表示模型中的某个概念，如图3-3所示，给出了类、对象、状态、节点、包和组件等模型元素的符号图例。另一类模型元素用于表示模型元素之间相互连接的关系。常见的关系有关联、继承、依赖和实现。这些关系的图形符号如图3-4所示。

图3-4关系的图示符号示例

3.2.3 UML的模型结构

根据UML语义，UML的模型结构可分为四个抽象层次，即元元模型、元模型、模型层和用户模型。它们的层次结构如图3-5所示，下一层是上一层的基础，上一层是下一层的实例。

图3-5

 

元元模型层是组成UML最基本的元素“事物”，代表要定义的所有事物。元元模型定义了元类、元属性、元操作等一些概念。例如，图3-6是一个“元类”的元元模型描述，其中事物概念可代表任何定义的东西。

图3-6

元模型层组成了UML的基本元素，包括面向对象和面向组件的概念。这一层的每个概念都是元元模型中“事物”概念的实例。例如，图3-7是一个元模型示例，其中类、对象、关联等都是元元模型中事物概念的实例。

图3-7元模型示例

模型层组成了UML的模型，这一层中的每个概念都是元模型层中概念的一个实例，这一层的模型通常叫作类模型或类型模型。

用户模型层中的所有元素都是UML模型的例子。这一层中的每个概念都是模型层的一个实例(通过分类)，也是元模型层的一个实例。这一层的模型通常叫作对象模型或实例模型。

3.2.4 UML的模型图

模型通常作为一组图呈现出来，常用的UML模型图有9种，它们是类图、对象图、用例图、顺序图、协作图、状态图、活动图、组件图和部署图。在这9种图中，类图包含类、接口、协同及其关系，它用来描述逻辑视图的静态属性；对象图包含对象及其关系，它用来表示某一类图的一组类的对象在系统运行过程中某一时刻的状态，对象图也是软件系统的逻辑视图的一个组成部分；组件图用来描述系统的物理实现，包括构成软件系统的各部件的组织和关系，类图里的类在实现时，最终会映射到组件图的某个组件，一个组件可以实现多个类，组件图是软件系统实现视图的组成部分；部署图用来描述系统的组件在运行时在运行节点上的分布情况，一个节点可包含一个或多个组件，部署图是软件系统部署视图的组成部分。上述四种模型图主要用来描述软件系统的静态结构。

用例图、顺序图、协作图、状态图和活动图是用来描述软件系统的动态特性。用例图用来描述系统的边界及其系统功能，它由用例和系统外部参与者及其之间的关联关系组成，用例图是用例视图的重要组成部分和内部的动态特性。顺序图和协作图中包含对象和消息，它们是用例视图和逻辑视图的重要组成部分。状态图和活动图主要用于描述对象的动态特性。状态图强调对象对外部事件的响应及相应的状态变迁。活动图描述对象之间控制流的转换和同步机制。

表3-1

表3-1列出了UML的视图和视图所包括的图及与每种图有关的主要概念。

3.2.5 UML建模规则

UML的模型图不是由UML语言成分简单地堆砌而成的，它必须按特定的规则有机地组成合法的UML图。一个完备的UML模型图必须在语义上是一致的，并且和一切与它相关的模型和谐地组合在一起。UML建模规则包括了对以下内容的描述。

①名字：任何一个UML成员都必须包含一个名字。

②作用域：UML成员所定义的内容起作用的上下文环境。某个成员在每个实例中代表一个值，还是代表这个类元的所有实例的一个共享值，由上下文决定。

 

 

 

③可见性：UML成员能被其他成员引用的方式。

④完整性：UML成员之间互相连接的合法性和一致性。

⑤运行属性：UML成员在运行时的特性。

一个完备的UML模型必须对以上内容给出完整的解释。完备的UML模型是建造系统所必需的，但是当它在不同的视图中出现时，出于不同的交流侧重点，其表达可以是不完备的。在系统的开发过程中，模型可以：

①被省略，即模型本身是完备的，但在图上某些属性被隐藏起来，以简化表达；

②不完全，即在设计过程中某些元素可以暂时不存在；

③不一致，即在设计过程中暂时不保证设计的完整性。

提出上述三条建模原则的目的是为使开发人员在设计模型时把注意力集中在某一特定时期内对分析设计活动最重要的问题上，而暂时不迷恋于细节的完美，使模型逐步趋向完备。

3.2.6 UML的公用机制

以图的方式建立模型是不够的，对于各种图中的建模元素，还要按一定的要求进行详细的说明和解释，即用图加上说明规范的方式构成完整的模型。

在UML模型图上使用UML成员进行建模时，需要对UML成员进行描绘。UML使用公用机制为图附加一些信息，这些信息通常无法用基本的模型元素表示。UML对不同的UML成员使用共同的描绘方式，这些方式称为UML共用机制。使用这些共用机制，使得建模的过程更适于掌握，模型更容易被理解。共用机制可被分解为以下四个方面。

(1)规范说明

UML的图形符号是简洁、形象、直观的，而一个有效的软件模型必须提供足够的详细信息以供建造之用，这些构成一个完备模型的详细信息就是模型的规范说明。在模型图上被省略的内容并不代表它不存在于模型之中，模型的完整的或完备的信息是被保存在模型的规范说明中的。

(2)修饰

在图的模型元素上添加修饰，可为模型元素附加一定的语义。例如，类的属性的可见性就是可以选择地被显示出来的。

(3)公共划分

在面向对象的设计中，有许多事物可以划分为抽象的描绘和具体的实例这两种存在形式。

UML提供了事物的这两种两分法表达，被称为公共划分。例如，对象和类使用同样的图形符号。类用长方形表示，并用名字加以标识，当类的名字带有下划线时，则它代表该类的一个对象。另外，还有一种两分法是接口和实现的两分划分。接口定义了一种协议，实现是此协议的实施。UML里这样的接口与实现的两分划分包括接口/类或组件、用例和协同，以及操作和方法。

(4)扩展机制

如同人类的语言需要不断地扩充词汇，以描述各种新出现的事物一样，UML也提供了扩展机制。扩展机制为UML提供了扩充其表达内容的范围的能力。UML的扩展机制包括构造型(版型)、标记值及约束。构造型是对类的进一步的分类。标记值用来扩充UML成员的规范说明。虽然在UML中已经预定义了许多特性，但是用户也可以定义自己的特性，以维护元素的附加信息。任何一种信息都可以附属到某个元素，包括：特定方法的信息、关于建模过程的管理信息、其他工具使用的信息(如代码生成工具)或者是用户希望将其连接到元素的其他类型的信息。约束用来扩充UML成员的语义。

3.3  一个UML的例子

本节通过一个简化银行ATM系统的例子对UML中所使用的模型和视图进行初览，说明如何用各种不同的概念来描述一个系统，以及如何将各种视图组织在一起。这是一个简化了ATM取款处理系统的例子，忽略了有关细节，主要为了说明各种UML图形的概念和基本含义。用户通过输入银行账号(PIN)来确认用户的合法身份，查询有关自己账户的信息，还可以通过ATM机进行存款、取款，或者使用ATM办理转账等事务。当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与银行的计算机交换事务的信息。

3.3.1  用例图

采用用例驱动的分析方法分析需求的主要任务是识别出系统中的参与者和用例，并建立用例模型。用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。用例模型的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。参与者是系统的主体，表示提供或接收系统信息的人或系统。图3-8显示了ATM系统使用用例与参与者之间的交互。

在本例中包括几个用例：取款、存款、付款、转账、查询、修改PIN等。本例中涉及的参与者有：用户、银行业务员、信用系统。银行业务员在特定的情况下可以启动修改PIN用例。

在用户付款时，需要得到信用系统的确认。

图3-8 ATM系统的用例图

3.3.2  活动图

活动图显示了系统的流程，可以是工作流，也可以是事件流。在活动图中定义了流程从哪里开始，到哪里结束，以及在这之中包括哪些活动。活动是工作流期间完成的任务。活动图描述了活动发生的顺序。在本例中用活动图描述满足用例要求所要进行的活动及活动间的约束关系。

图3-9显示了开户的活动。框图中的活动用圆角矩形表示，这是工作流期间发生的步骤。工作流影响的对象用矩形表示。开始状态表示工作流开始，结束状态表示工作流结束。决策点用菱形表示。

图3-9开户的活动图

对象流程显示活动使用或创建的对象和工作流过程中对象如何改变状态。活动图可以分为不同的垂直泳道，每个泳道代表工作流中的不同参与者。通过泳道中的活动可以了解这个参与者的责任。通过查看不同泳道中活动之间的过渡，可以了解谁要与谁进行通信。活动图的用途是对现实世界中的工作流程建模，但活动图也可对软件系统中的活动建模。活动图有助于理解系统高层活动的执行行为，而不涉及建立协作图所必需的消息细节。

3.3.3顺序图

顺序图表示了对象之间传送消息的时间顺序。每一个对象用一条生命线来表示——即用垂直线代表整个交互过程中对象的生命周期。生命线之间的箭头连线代表消息。顺序图可以用来进行一个场景说明——即一个事务的历史过程。图3-10显示了用户张三取款用例的详细过程。

图3-10张三取款的顺序图

取款用例从用户将ATM卡插入读卡机开始，读卡机对象表示为框图顶部的矩形。在确认是合法的ATM卡后，系统询问PIN，并通过显示器对象显示出来。用户输入PIN，系统验证PIN与账户对象，发出合格信息。然后系统向张三提供选项，张三输入取款金额(200元)。系统首先验证账户中的余额不少于200元，然后从账户中扣除200元，再让点钞机提供200元现金，ATM从现金出口吐出现金，并打印账单交给用户。最后系统退出ATM卡。

3.3.4协作图

协作图对在一次交互中有意义的对象和对象间的链建模。对象只有进行交互才有意义。如图3-11所示，表示了取款所涉及的各个对象间的交互关系。在协作图中，直接相互通信的对象之间有一条直线，没有画线的对象之间不直接通信。附在直线上的箭头代表消息。消息的发生顺序用消息箭头处的编号来说明。协作图的一个用途是表示一个类操作的实现。协作图可以说明类操作中用到的参数和局部变量及操作中的永久链。当实现一个行为时，消息编号对应了程序中嵌套调用结构和信号传递过程。

图3-11张三取款的协作图

3.3.5  类图

类图是以类为中心来组织的，类图中的其他元素或属于某个类或与类相关联。在类图中类用矩形框来表示，它的属性和操作分别列在分格中。关系用类框之间的连线来表示，不同的关系用连线上和连线端头处的修饰符来区别。图3-12是AFM系统中与取款用例有关的类图。

图3-12类图

在这个类图中包含读卡机、显示、数字键盘、客户管理、点钞机、事务管理、账户管理和账户八个类。类之间的关系通过连线来表示。例如，客户管理类与点钞机两者需要通信，因此两个类相连；而读卡机与点钞机不进行通信，因而不需要相连。

3.3.6状态图

状态视图是一个类对象所经历的所有历程的模型图。状态由对象的各个状态 和连接这些状态的变迁组成。每个状态对一个对象在其生命周期中满足某种条件的一个时间段建模。当一个事件发生时，它会触发状态间的变迁，导致对象从一种状态转化到另一种新的状态。与变迁相关的活动执行时，变迁也同时发生。状态用状态图来表达。图3—13是银行账目这一对象的状态图。

图3-13状态图

银行账目可能有几种不同的状态，可以打开、关闭或透支。账目在不同状态下的功能是不同的。事件导致账目从一个状态过渡到另一个状态。如果账目打开而客户要取款，则账目可能转入透支状态。这发生在账目结余小于取款额时，在图中显示为[结余<取款额]。状态图可用于描述用户接口或在生命周期中跨越多个不同性质阶段的被动对象的行为，在每一阶段该对象都有自己特殊的行为。

3.3.7  组件图

组件图表示了系统中的各种组件。代码的物理结构用代码组件表示。组件可以是源代码、二进制文件或可执行文件组件。组件包含了逻辑类或逻辑类的实现信息，因此逻辑视图与组件视图之间存在着映射关系。组件之间也存在着依赖关系，利用这种依赖关系可以方便地分析一个组件的变化会给其他的组件带来怎样的影响。组件可以与公开的任何接口一起显示，也可以把它们组合起来形成一个包，在组件图中显示这种组合包。图3-14是ATM客户机的C++组件图。

图3-14组件图

在C++组件图中，每个类有自己的体文件和头文件，因此框图中每个类映射自己的组件。例如，显示类映射ATM显示组件，阴影组件称为包体，表示C++中显示类的体文件(．cpp)。无阴影组件称为包规范，表示C++类的头文件(.H)。组件ATM.EXE是个任务规范，表示处理线程。这里的处理线程是个可执行程序。组件用虚线连接，表示组件间的相关性。例如，读卡机类与显示类相关，即必须有显示类才能编译读卡机类。编译所有类之后，即可创建可执行文件ATMClient.exe。

3.3.8部署图

部署图用来描述位于节点实例上的运行组件实例的安排，描述系统的实际物理结构。节点是一组运行资源，如计算机、设备或存储器。这个视图允许评估分配结果和资源分配，图中表示了系统中的各组件和每个节点包含的组件，节点用立方体图形表示。图3-15是ATM系统的部署。

图3-15部署图

这个图显示了ATM系统的主要布局。ATM系统采用三层结构，分别针对数据库、地区ATM服务器和客户机。ATM客户机的可执行文件在不同地点的多个ATM上运行。ATM客户机通过专用网与地区ATM服务器通信。ATM服务器的可执行文件在地区ATM服务器上执行。地区ATM服务器又通过局域网与运行Oracle的银行数据库服务器通信。打印机与地区ATM服务器连接。