下载掌阅APP，畅读海量书库
立即打开
4.3 UML的建模机制
UML是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。它记录了对必须构造的系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息控制。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域，以及各种开发工具，UML是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。UML包括概念的语义，表示法和说明，提供了静态、动态、系统环境及组织结构的模型。它可被交互的可视化建模工具所支持，这些工具提供了代码生成器和报表生成器。UML标准并没有定义一种标准的开发过程，但它适用于迭代式的开发过程。它是为支持大部分现存的面向对象开发过程而设计的。
UML不是一种可视化的编程语言，但是UML描述的模型可与各种编程语言直接相连，即可把用UML描述的模型映射成编程语言。
UML2.x中包括14种不同的图，分为表示系统静态结构的静态模型（包括类图、对象图、复合结构图、构件图、部署图、包图），以及表示系统动态结构的动态模型（包括用例图、活动图、状态机图、顺序图、通信图、定时图、交互概观图、制品图）。
用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。它确定了一个和系统参与者进行交互、并可由系统执行的动作序列。用例模型描述的是外部执行者（Actor）所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。
在UML中，用例表示为一个椭圆。图4-2显示了一个个人图书管理系统的用例图。其中，“新增书籍信息”、“查询书籍信息”、“修改书籍信息”、“登记外借情况”、“查询外借情况”、“统计金额与册数”等都是用例的实例。
图4-2 用例图示例
参与者（Actor）代表与系统接口的任何事物或人，它是指代表某一种特定功能的角色，参与者都是虚拟的概念。在UML中，用一个小人表示参与者。
图4-2中的“图书管理员”就是参与者。对于该系统来说，可以充当图书管理员角色的可能有多个人，由于他们对于系统而言均起着相同的作用，扮演相同的角色，因此只使用一个参与者表示。切忌不要为每一个可能与系统交互的真人画出一个参与者。
可以通过以下问题来帮助你寻找到系统的相关参与者。
用例（Use Case）是对系统行为的动态描述，它可以促进设计人员、开发人员与用户的沟通，理解正确的需求，还可以划分系统与外部实体的界限，是系统设计的起点。在识别出参与者之后，可以使用下列问题帮助识别用例：
图4-3 包含关系示例图
两个用例之间的关系可以主要概括为两种情况。一种是用于重用的包含关系，用构造型<<include>>表示；另一种是用于分离出不同的行为，用构造型<<extend>>表示。
（1）包含关系： 当你可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个组件来实现某一个用例的部分功能是很重要的事时，应该使用包含关系来表示它们。
（2）扩展关系： 如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情。我们可以断定将这个用例分为一个主用例和一个或多个辅用例描述可能更加清晰。
图4-4 扩展关系示例图
在面向对象建模技术中，对象是指现实世界中有意义的事物具有封装性和自治性的特点，而类是指具有相同属性和行为的一组对象。类（Class）、对象（Object）和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统，其类模型和对象模型揭示了系统的结构。在UML中，类和对象模型分别由类图和对象图表示。类图技术是OO方法的核心。图4-5显示了一个小型图书管理系统的类图。
图4-5 类图
对象与我们对客观世界的理解相关。它通常用来描述客观世界中的某个具体的事物。因为类（Class）是对一组具有相同属性，表现相同行为的对象的抽象。因此，对象是类的实例（Instance）。在UML中，类的可视化表示为一个划分成3个格子的长方形（下面两个格子可省略）。图4-5中，“书籍”、“借阅记录”等都是一个类。
（1）类的命名： 最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语，应明确、无歧义，以利于开发人员与用户之间的相互理解和交流。
（2）类的属性： 中间的格子包含类的属性，用以描述该类对象的共同特点。该项可省略。图4-5中“书籍”类有“书名”、“书号”等特性。UML规定类的属性的语法为：“可见性属性名：类型=默认值{约束特性}”。
（3）类的操作（Operation）： 该项可省略。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能，但是它们被约束在类的内部，只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。UML规定操作的语法为“可见性：操作名（参数表）：返回类型{约束特性}”。
类图描述了类和类之间的静态关系。定义了类之后，就可以定义类之间的各种关系。
在建立抽象模型时，由于很少有类会单独存在，大多数都将会以某种方式彼此通讯，因此我们还需要描述这些类之间的关系。关系是事物间的连接，在面向对象建模中，有四个很重要的关系。
（1）依赖关系。 有两个元素A、B，如果元素A的变化会引起元素B的变化，则称元素B依赖（Dependency）于元素A。在UML中，使用带箭头的虚线表示依赖关系，如图4-6所示。
在类中，依赖关系有多种表现形式，如：一个类向另一个类发消息；一个类是另一个类的成员；一个类是另一个类的某个操作参数等。
（2）泛化关系。 泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线表示，箭头指向父类，如图4-7所示。
图4-6 依赖关系的图示
图4-7 泛化关系的图示
在UML中，对泛化关系有三个要求：
在如图4-5所示的例子中，“书籍”与“非计算机类书籍”之间就是泛化关系。
（3）关联关系。 关联（Association）表示两个类的实例之间存在的某种语义上的联系。例如，一个老师在某学校工作，一个学校有多间教室。我们就认为教室和学校、学校和教室之间存在着关联关系。
关联关系为类之间的通信提供了一种方式，它是所有关系中最通用、语义最弱的。关联关系通常可以再细分成以下几种。
（4）实现关系。 实现关系是用来规定接口和实现接口的类或组件之间的关系。接口是操作的集合，这些操作用于规定类或组件的服务。在UML中，使用一个带空心箭头的虚线表示，如图4-9所示。
图4-8 聚合关系的图示
图4-9 实现关系的图示
类图（Class Diagram）描述类和类之间的静态关系。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。类图是面向对象建模中最重要的模型。
UML中对象图与类图具有相同的表示形式。对象图可以看做是类图的一个实例。对象是类的实例，对象之间的链（Link）是类之间的关联的实例。对象与类的图形表示相似，均为划分成两个格子的长方形（下面的格子可省略）。上面的格子是对象名，对象名下有下画线；下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复杂的类图的一个实例。
交互图（Interactive Diagram）是表示各组对象如何依某种行为进行协作的模型。通常可以使用一个交互图来表示和说明一个用例的行为。在UML中，包括两种不同形式的交互图，分别是强调对象交互行为顺序的顺序图，强调对象协作的协作图，它们之间没有什么本质不同，只是排版不尽相同而已。
顺序图（Sequence Diagram）用来描述对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。顺序图允许直观地表示出对象的生存期。在生存期内，对象可以对输入消息做出响应，并且可以发送信息。图4-10是顺序图示例。
图4-10 顺序图示例
正如图4-10所示，顺序图存在两个轴，水平轴表示不同的对象，即图中的Client、Factory、Product等；而垂直轴表示时间，表示对象及类的生命周期。
对象间的通信通过在对象的生命线间画消息来表示。消息的箭头指明消息的类型。顺序图中的消息可以是信号、操作调用或类似于C++中的RPC（Remote Procedure Calls）和Java中的RMI（Remote Method Invocation）。当收到消息时，接收对象立即开始执行活动，即对象被激活了。通过在对象生命线上显示一个细长矩形框来表示激活。
消息可以用消息名及参数来标志，消息也可带有顺序号。消息还可带有条件表达式，表示分支或决定是否发送消息。如果用于表示分支，则每个分支是相互排斥的，即在某一时刻仅可发送分支中的一个消息。
协作图（Collaboration Diagram）用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和协作图都用来描述对象间的交互关系，但侧重点不一样。顺序图着重体现交互的时间顺序，协作图则着重体现交互对象间的静态链接关系。图4-11是与图4-10相对应的协作图。
图4-11 协作图示例
状态图（State Diagram）用来描述对象状态和事件之间的关系。我们通常用状态图来描述单个对象的行为。它确定了由事件序列引出的状态序列，但并不是所有的类都需要使用状态图来描述它的行为。只有那些具有重要交互行为的类，我们才会使用状态图来描述。
图4-12是一个数码冲印店的订单状态图实例，正如图4-12所示，状态图包括以下部分。
图4-12 状态图示例
（1）状态： 又称为中间状态，用圆角矩形框表示；
（2）初始状态： 又称为初态，用一个黑色的实心圆圈表示，在一张状态图中只能够有一个初始状态；
（3）结束状态： 又称为终态，在黑色的实心圆圈外面套上一个空间圆，在一张状态图中可能有多个结束状态；
（4）状态转移： 用箭头说明状态的转移情况，并用文字说明引发这个状态变化的相应事件是什么。
一个状态也可能被细分为多个子状态，如果将这些子状态都描绘出来的话，那这个状态就是复合状态。
状态图适合用于表述在不同用例之间的对象行为，但并不适合于表述包括若干协作的对象行为。通常不会需要对系统中的每一个类绘制相应的状态图，而会在业务流程、控制对象、用户界面的设计方面使用状态图。
活动图用来表示系统中各种活动的次序，它的应用非常广泛，既可用来描述用例的工作流程，也可以用来描述类中某个方法的操作行为。活动图是由状态图变化而来的，它们各自用于不同的目的。活动图依据对象状态的变化来捕获动作（将要执行的工作或活动）与动作的结果。活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的变迁可能需要事件的触发）。
图4-13给出了一个基本活动图的例子。
正如图4-13所示，活动图中与状态图类似，包括了初始状态、终止状态，以及中间的活动状态，每个活动之间，也就是一种状态的变迁。在活动图中，还引入了以下几个概念。
图4-13 活动图示例
（1）判定： 说明基于某些表达式的选择性路径，在UML中使用菱形表示。
（2）分叉与结合： 由于活动图建模经常会遇到并发流，因此在UML中引入了如图4-13所示的粗线来表示分叉和结合。
在前面说明的基本活动图中，虽然能够描述系统发生了什么，但无法说明完成这个活动的对象。针对OOP而言，这就意味着活动图没有描述出各个活动由哪个类来完成。要想解决这个问题，可以通过泳道来解决这一问题。它将活动图的逻辑描述与顺序图、协作图的责任描述结合起来。下面是一个使用了泳道的例子，如图4-14所示。
图4-14 带泳道活动图示例
在活动图中对象可以作为活动的输入或输出，对象与活动间的输入/输出关系由虚线箭头来表示。如果仅表示对象受到某一活动的影响，则可用不带箭头的虚线来连接对象与活动。
在活动图中可以通过信号的发送和接收标记来表示信号的发送和接收，发送和接收标志也可与对象相连，用于表示消息的发送者和接收者。
构件图是面向对象系统的物理方面进行建模时要用的两种图之一。它可以有效地显示一组构件，以及它们之间的关系。构件图中通常包括构件、接口，以及各种关系。图4-15所示是一个构件图的例子。
图4-15 构件图示例
通常构件指的是源代码文件、二进制代码文件和可执行文件等。而构件图就是用来显示编译、链接或执行时构件之间的依赖关系。例如，在图4-15中，就是说明QueryClient.exe将通过调用QueryServer.exe来完成相应的功能，而QueryServer.exe则需要Find.exe的支持，Find.exe在实现时调用了Query.dll。
通常，我们使用构件图可以完成以下工作。
（1）对源代码进行建模： 这样可以清晰地表示出各个不同源程序文件之间的关系。
（2）对可执行体的发布建模： 如图4-15所示，将清晰地表示出各个可执行文件、DLL文件之间的关系。
（3）对物理数据库建模： 用来表示各种类型的数据库、表之间的关系。
（4）对可调整的系统建模： 例如，对于应用了负载均衡、故障恢复等系统的建模。
在绘制构件图时，应该注意侧重于描述系统的静态实现视图的一个方面，图形不要过于简化，应该为构件图取一个直观的名称，在绘制时避免产生线的交叉。
部署图，也称为实施图，它和构件图一样，是面向对象系统的物理方面建模的两种图之一。构件图是说明构件之间的逻辑关系，而部署图则在此基础上更近一步，描述系统硬件的物理拓扑结构，以及在此结构上执行的软件。部署图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件，常常用于帮助理解分布式系统。
图4-16就是与图4-15对应的部署图，这样的图示可以使系统的安装、部署更为简单。在部署图中，通常包括以下一些关键的组成部分。
节点（Node）代表一个物理设备，以及其上运行的软件系统，如一台Windows NT主机、一个PC终端、一台打印机、一个传感器等。
如图4-16所示，“客户端：PC”和“服务器”就是两个节点。在UML中，使用一个立方体表示一个节点，节点名放在左上角。节点之间的连线表示系统之间进行交互的通信路径，在UML中被称为连接。通信类型则放在连接旁边的“”之间，表示所用的通信协议或网络类型。
图4-16 部署图示例
在部署图中，构件代表可执行的物理代码模块，如一个可执行程序。逻辑上构件可以与类图中的包或类对应。例如在图4-15中，“服务器”节点中包含“QueryServer.exe”、“Find.exe”和“Query.dll”3个构件。
在面向对象方法中，类和构件等元素并不是所有的属性和操作都对外可见。它们对外提供了可见操作和属性，称为类和构件的接口。界面可以表示为一头是小圆圈的直线。在图4-16中，“Query.dll”构件提供了一个“查询”接口。