| UML是一种通用的建模语言，其表达能力相当的强，不仅可以用于软件系统的建模，而且可用于业务建模以及其它非软件系统建模。UML综合了各种面向对象方法与表示法的优点，从提出之日起就受到了广泛的重视并得到了工业界的支持。 本章将按视图、模型元素、图以及公共机制依次介绍UML的构造和基本元素，以使得读者对UML有一个总体了解，其具体细节将在后续章节中详细描述。 2.1 视图 建模方法由建模语言和建模过程两部分构成。其中建模语言是用来表述设计方法的表示法，建模过程是对设计中所应采取的步骤的描述。UML是一种建模语言，它在很大程度上独立于建模过程。在实际建模中，建模人员最好把UML用于以用案驱动的、以体系机构为中心的、迭代的和渐增式的开发过程中。 一般而言，软件系统的体系结构给出了软件系统的组织、组成系统的构造元素及其接口的选择、系统的行为和体系结构风格等信息。也就是说，它不仅关心系统的结构和行为等功能性需求，而且也涉及系统的性能、易理解性、易复用性等非功能性需求。如图2-1所示，UML利用用户模型视图、结构模型视图、行为模型视图、实现模型视图和环境模型视图来描述软件系统的体系结构。其中： 
用户模型视图由专门描述最终用户、分析人员和测试人员看到的系统行为的用案组成，它实际上是从用户角度来描述系统应该具有的功能。用户模型视图所描述的系统功能依靠外部用户或者另外一个系统来激活，为用户或者另一系统提供服务，从而实现用户或另一系统与系统的交互。系统实现的最终目标是提供用户模型视图中所描述的功能。在UML中，用户模型视图是由用案图组成。 结构模型视图描述组成系统的类、对象以及它们之间的关系等静态结构，用来支持系统的功能需求，即描述系统内部功能是如何设计的。结构模型视图由类图和对象图构成，主要供设计人员和开发人员使用。 行为模型视图主要用来描述形成系统并发与同步机制的线程和进程，其关注的重点是系统的性能、易伸缩性和系统的吞吐量等非功能性需求。行为模型视图利用并发来描述资源的高效使用、并行执行和处理异步事件。除了讲系统划分为并发执行的控制线程之外，行为模型还必须处理通信和这些线程及进程之间的同步问题。行为模型视图主要供系统开发人员和系统集成人员使用，它由序列图、协作图、状态图和活动图组成。 实现模型视图用来描述系统的实现模块、它们之间的依赖关系以及资源分配情况。这种视图主要用于系统的配置管理，它是由一些独立的构件组成的。实现模型视图由构件图组成。其中构件是代码模块，不同类型的代码模块形成不同的构件。实现模型视图主要供开发人员使用。 环境模型视图用来描述物理系统的硬件拓扑结构。例如，系统中的计算机和设备的分布情况以及它们之间的连接方式，其中计算机和设备统称为节点。在UML中环境模型视图是由部署图来表示的。系统部署图描述了系统构件在节点上的分布情况，即用来描述软件构件到物理节点的映射。部署图主要供开发人员、系统集成人员和测试人员使用。 上面每一种视图反映了系统的一个特定方面，不同人员可以单独的使用其中每一种视图，从而可以关注特定的体系结构问题。但在通常情况下，由于系统的最终目标是提供用户模型视图中描述的功能以及其它一些非功能性需求，因此，用户模型视图是其它视图的核心基础，其它视图的构造都依赖与用户模型视图中所描述的类容。 细心的读者已经发现，每一种UML图都是由多个图组成的，每一种图都是体系结构某个侧面的表示，各种图实际上是一致的，所有的图在一起组成了系统的完整视图。如图2-2所示，UML中总共提供了用案图、类图、对象图、序列图、协作图、状态图、活动图、构建图和部署图9种图。根据它们描述的是系统的静态结构还是动态行为，可以将它们分为静态图和动态图两类。再进一步介绍这9中UML图时，先了解下什么是模型元素： 
2.2 模型元素 所有包含语义的元素都是模型元素。模型元素可以有名字，每个模型元素有与其类型相符的命名空间。在UML图中，模型元素用其相应的符号来表示。一个模型元素可以出现在多个不同类型的图中，在不同的图中以何种形式出现须遵循一定的UML规则。 图2-3中给出了UML图中最基本的设施。设施是对模型中最具有代表性成分的抽象，关系把设施结合在一起，图则聚合了相关的设施。 
在UML中，设施可以分为结构设施、行为设施、分组设施和注释设施4大类。 结构设施是UML模型的静态部分，主要用来描述概念或者物理元素，包括类、接口、协作、用案、主动类、构件和结点7种设施。其中： 类 是对一组具有相同属性、相同动作、相同关系和相同语义对象的描述，一个类实现了一个或多个接口。在图形上类用带有类名、属性和操作的矩形框来表示。对象是类的实例，其名字有下划线。模板类是参数化类，它用部分重叠的两个矩形来表示。 接口 描述了一个类或构件的一个服务操作集，即定义了元素的外部可见行为。接口定义的是一组操作的描述，而不是操作的实现。在图形上，接口用一端带有小圆圈的直线来表示，它通常依附在实现接口的类或构件上。 协作 定义了一个交互，是由一组通过共同工作以提供某协作行为的角色和其它元素构成的一个实体。一个给定的类可以参与几个协作。在图形上，协作用一个通常仅包含名字的虚线椭圆表示。 用案 用一组动作序列的描述，系统执行这些动作之后将产生一个对特定参与者可以观察且有价值的结果。在图形上，用案用一个通常包含名字的实现椭圆表示。 主动类 是其对象至少要有一个进程或线程的类，因此它能够启动控制活动。主动类的对象所描述的元素的行为与其它元素的行为为并发，除此以外，它和类是一样的。在图形上，主动类用有粗外框的矩形来表示。 构件 是系统中物理的、可替代的部件，它通常是一个描述了一些逻辑元素的物理包。再图形上，构件用一个带有小方框的矩形来表示。 结点 是在运行是存在的物理元素。它代表一种可计算的资源，通常具有一定的记忆能力和处理能力。在图形上，结点用立方体表示。 行为设施是UML模型的动态部分，它包括如下两类设施： 交互 在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为都可以用一个交互来描述。如图2-3所示，消息可以分为简单消息，同步消息和异步消息等类型。 状态机 描述一个对象或一个交互在在生命周期内响应事件所经历的状态序列，单个类或者一组类之间协作的行为可以用状态机来描述。状态机涉及到状态、变迁和活动.,其中状态用圆角矩形来表示. 分组设施是UML的组织部分。最主要的分组设施是包，它是一种用于把模型元素组织成组的设施，结构设施、行为设施和其它的分组设施都可以放进包里，构件仅在运行时存在，而包只在开发时存在。 注释设施是UML的解释部分，它们用来描述和标注模型的任何元素。通常可以用注释修饰或解释带有约束的图。 模型元素之间的连接关系也是模型元素。入图2-4所示，常见的关系有关联、泛化、依赖和实现4种。其中： 
关联是一种结构关系，它描述了一组链，链是用来连接对象的。聚合是一种特殊的关联，它描述了整体和部分之间的结构关系。关联除可以具有方向外，也可以带有多重性标注和角色名这类修饰符。 泛化是一种特殊（或一般）关系，特殊元素的对象（子元素）可以替代一般元素（父元素）的对象。这样，子元素就可以共享父元素的结构和行为。 依赖是两个设施之间的语义关系，其中一个设施的变化会影响到另外一个设施的语义，它是一条可带方向的虚线来表示的。 实现是依赖和泛化的组合，通常在接口和实现它们的类或构件之间用到这种关系。 2.3 图 图是一组元素的图形表示，通常是由代表设施的顶点和代表关系的弧所构成的联通图。理论上，图可以包含任何设施及其关系的复合。一个典型的模型应该有多个各种类型的图。UML中包含用案图、类图、对象图、序列图、协作图、状态图、活动图、构件图和部署图9种。 2.3.1 用案图 用案图是用于描述一组用案，参与者以及它们之间的连接关系。一个用案图描述了一组动作序列，每一个序列表示系统的外部设施（系统的参与者）与系统本身的交互。从一个特定参与者的角度看，一个用案完成对其有价值的工作。如图2.5所示，用案图仅仅是从参与者使用系统的角度来描述系统中的信息，即站在系统外部查看系统应该具有什么功能，而并不描述该功能在软件内部是如何实现的。用案可以应用于整个系统，也可以应用于系统的一个部分，包括子系统、单个的类或者接口。通常，用案不仅代表这些元素所期望的行为，而且还可以把这些元素用作开发过程中测试用案的基础。 
2.3.2 类图 类图是用于描述一组类、接口、协作以及它们之间的静态关系。在面向对象系统的建模中，类图是最为常用的图，它用来阐明系统的静态结构。事实上类是对一组具有相同属性、操作、关系和语义的对象的描述，其中对类的属性和操作进行描述时的一个最重要的细节就是它的可见性。 类可以以多种形式连接，例如关联、泛化、依赖和实现等。一个典型的系统中通常有若干个类图。一个类图不一定要包含系统中所有的类，一个类可以加到几个类图中。如图2-6给出了一个典型的类图： 
2.3.3 对象图 对象图是类图的实例，用来描述特定运行时刻一组对象之间的关系。也就是说，对象用于描述交互的静态部分，它由参与协作的有关对象组成。但不包括在对象之间传递的任何消息。 在创建对象图时，建模人员并不需要用单个的对象图来描述系统中的每一个对象。事实上，绝大多数系统中都会包含成百上千的对象。用对象来描述系统的所有对象以及它们之间的关系一般是不太现实的。因此，建模人员可以选择所感兴趣的对象极其之间的关系来描述。 对象图中所使用的符号和类图中使用的符号几乎完全相同，区别仅在于对象图的对象名带有下划线，而且类与类之间关系的所有的实例都要画出来。如图2-7A描述了各个类及它们之间的关系，图2-7B是与它对应的对象图。 
2.3.4 序列图 序列图和协作图统称为交互图。其中，序列图用来描述对象之间消息发送的先后次序，阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件。如图2-8所示，序列图是一种强调时间顺序的交互图，其中对象沿横轴方向排列，消息沿纵轴方向排列。 
序列图中的对象生命线是一条垂直的虚线，它表示一个对象在一段时间内存在。 由于序列图中大多数对象都存在于整个交互过程中，因此这些对象全部排列在图的顶部，它们的生命线从图的顶部画到图的底部。每个对象的下方有一个矩形条，它与对象的生命线重叠，它表示该对象的控制焦点。序列图中的消息可以有序号，但由于这种图上的消息已经从纵轴上按时间顺序排序，因此消息序号通常予以省略。 2.3.5 协作图 协作图也是一种交互图，它强调收发消息的对象的组织结构。 协作图和序列图是协作的，它们可以互相转换。在多数情况下，协作图主要对单调的、顺序的控制流建模，但它也可以用来对包括迭代和分支在内的复杂控制流进行建模。 一般而言，建模人员可以创建多个协作图，其中一些是主要的，另外一些是可选择的路径或者异常条件。建模人员可以用包来组织这些协作图，并给每个图起一个合适的名字，以便与其它图区别开。图2-9给出了一个典型的协作图： 
2.3.6 状态图 状态图实际上是一种由状态、变迁、事件和活动组成的状态机。状态图描述从状态到状态的控制流，常用于系统的动态特性建模。在大多数情况下，它用来对反应型对象的行为建模。 在UML中，状态图可以用来对一个对象按事件排序的行为建模。如图2-10所示，一个状态图是强调从状态到状态的控制流的状态机的简单表示。一般而言，状态图是对类所描述的设施的补充说明，它描述了类的所有对象可能具有的状态以及引起状态变化的事件。 
2.3.7 活动图 活动图是状态图的一种特殊情况，其中几乎所有或大多数状态都处于活动状态，而且几乎所有或者大多数变迁都是由源状态中活动的完成触发的。活动图本质上是一种流程图，它描述了从活动到活动的控制流。 可以把活动图看作是新样的交互图，但交互图观察的是传递消息的对象，而活动图观察到的是对象之间传送的消息。尽管两者在语义上的区别很细微，但它们使用不同的方式来看系统的。图2-11给出了一种典型的活动图。 
2.3.8 构件图 构件图是用于描述一组构件之间的组织和依赖关系，用于建模系统的静态实现视图。构件可以是可执行程序集、库、表、文件和文档等，它包含了逻辑类或者逻辑类的实现信息，因此结构模型视图和实现模型视图之间存在映射关系。 构建图中也可以包括包或子系统，它们都是用于将模型元素组成较大的组块。图2-12给出了一个典型的构件图。 
2.3.9 部署图 部署图用来描述系统运行是进行处理的节点以及在节点上活动的构件的配置。部署图用来对系统的环境模型视图进行建模。在大多数情况下，部署图用来描述系统硬件的扩普结构。 在UML中，建模人员可以用类图来描述系统的静态结构，可以用序列图、协作图、状态图、活动图来描述系统的动态行为，而用部署图来描述软件所执行所需的处理器和设备的拓扑结构。图2-13给出了一个典型的部署图： 
2.4 公共机制 UML提供了一些公共机制，以便为图添加一些附加信息，这些信息通常无法用基本的模型元素表示。通常的公共机制包括规约、修饰符和扩展机制。 2.4.1 规约 在UML中，每个模型元素的图形表示法之后都存在一个规约，它以文字的形式描述基本模型元素的语法和语义。例如，在类的图符之后就有一个全面描述该类所拥有哦属性、操作和行为的规约；在视图上，类的图符可能仅展示了部分规约。 事实上，UML图形表示法可视化的描述系统，而UML的规约则用来描述系统的细节。 2.4.2 修饰符 UML中的大多数模型元素都可用唯一的和直接的图形符号来表示，这些图形符号可视化的表示模型元素最重要的信息。例如，类的图形符号展示了类名、操作和属性这些最重要的信息。但也可以给类增添修饰符以给出类规约的细节。例如，用斜体类名表示它是抽象类，用+和#等符号表示属性和操作的可见性。 在UML众多的修饰符中，注释是一种最重要的并且能单独存在的修饰符，它是附加在模型元素或元素集上用来表示约束或注解信息的图形符号。例如，图2-14表示的是一个带修饰符的类，图中的斜体类名表明这个类是抽象类。它有两个公共操作、一个保护操作和一个私有操作。此外，注释还指出了rollback的算法细节在文档exe.doc中。 
2.4.3 扩展机制 由于一种语言即使表达能力再强也难以表示出各种领域中的各种模型在不同时刻所有可能的细微差别，因此，UML提供了扩展机制，使得它可以以受控的方式进行扩展。UML的扩展包括衍型、标记值和约束。 衍型是对UML词汇的扩展，主要用于创建和已有的模型元素相似且针对特定的问题的新种类的模型元素。衍型是用书名号括起来的名字表示的，其位置在其它元素之上。 标记值是对UML元素的语义扩展，主要用于在模型元素的规约中创建新信息。标记值是用花括号括起来的字符串表示的，其位置在其它元素之下。 约束是图UML元素语义的扩展，主要用于增加新的规则或者修改已有的规则。约束是用花括号括起来的字符串表示，并且应该放在所关联的元素附近或者通过依赖关系连接相应的元素。 例如，在图2-15中，衍型exeception使得Overflow成为一个模型元素，EveryQueue中的版本和作者就是标记值，add上的约束(Ordered)使得EveryQueue中的事件按序排列。这3种扩展机制允许建模人员根据项目的需要来对UML进行相应的扩展。 
2.5 小结 本章就视图、模型元素、图以及公共机制依次介绍了一下。 UML中的视图是由用户模型视图、结构模型视图、实现模型视图、行为模型视图和环境模型视图5种视图组成的，它们分别用来描述系统应该具备什么样的功能、静态结构、动态行为、配置以及硬件拓扑结构，其中，用户模型视图是由用案图组成的，结构模型视图由类图和对象图组成，实现模型视图由构件图组成，行为模型视图由状态图、活动图、序列图和协助图组成，环境模型视图由部署图组成。 UML所提供的公共机制使得人们可以为各种图增添一些无法由基本模型元素表示的附加信息。 |
