2.3.3　模型元素

可以在图中使用的基本概念统称为模型元素。模型元素使用相关的语义、关于元素的正式定义和确定的语句来准确定义。模型元素在图中用相应的元素符号来表示。模型元素可以划分为面向对象的事物的描述和对事物关系的描述。利用相关元素符号可以把模型元素形象直观地表示出来。一个元素符号可以存在于多个不同类型的图中，但是具体以怎样的方式出现要依据图的相关规则来确定。下面按照事物和关系来划分这些模型元素并加以说明。

1．事物

事物是UML模型中面向对象的基本模块，它们在模型中属于静态部分。事物作为对模型中最具有代表性的成分的抽象，在UML中，定义了四种基本的面向对象的事物，分别是结构事物、行为事物、分组事物和注释事物。

（1）结构事物（Structural Thing）

结构事物是UML模型中的名词部分，这些名词往往构成模型的静态部分，负责描述静态概念和客观元素。在UML规范中，一共定义了七种结构事物。这七种结构事物分别是类、接口、协作、用例、主动类、构件和节点。下面分别对这七种结构事物进行说明。

• 类（Class）。如前面所叙述的一样，UML中的类完全对应于面向对象分析中的类，它具有自己的属性和操作。因而在描述的模型元素中，也应当包含类的名称、类的属性和类的操作。它和面向对象的类拥有一组相同属性、相同操作、相同关系和相同语义的抽象描述。一个类可以实现一个或多个接口。类的可视化描述通常如图2-11所示。
• 接口（Interface）。接口由一组操作的定义组成，但是它不包括对操作的实现进行详细的描述。接口用于描述一个类或构件的一个服务的操作集。它描述元素的外部可见的操作。一个接口可以描述一个类或构件的全部行为或部分行为。接口很少单独存在，往往依赖于实现接口的类或构件。接口的图形表示如图2-12所示。

• 协作（Collaboration）。协作用于对一个交互过程的定义，它是由一组共同工作以提供协作行为的角色和其他元素构成的一个整体。通常来说，这些协作行为大于所有元素行为的总合。一个类可以参与到多个协作中，在协作中表现了系统构成模式的实现。在Rational Rose中，没有给协作提供单独的符号，在标准的UML符号元素中，它的符号如图2-13所示。
• 用例（Use case）。用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段交互行为。用例是对一组动作序列的抽象描述。系统执行这些动作将产生一个对特定的参与者有价值而且可观察的结果。用例可结构化系统中的行为事物，从而可视化地概括系统需求。用例的表示如图2-14所示。

• 主动类（Active class）。主动类的对象（也称主动对象）有自动启动控制的活动，因为主动对象本身至少拥有一个进程或线程，每个主动对象由它自己的事件驱动控制线程来控制与其他主动对象并行执行。被主动对象所调用的对象是被动对象。它们只在被调用时接受控制，而当它们返回时将控制摒弃。被动对象被动地等待其他对象向它发出请求，这些对象所描述的元素的行为与其他元素的行为并发执行。主动类的可视化表示和一般类的表示相似，特殊的地方在于其外框为粗线。在许多UML工具中，主动类的表示和一般类的表示并无区别。在后面有关协作图的章节中，会对主动对象进行详细的介绍。
• 构件（Component）。构件是定义良好接口的物理实现单元，它是系统中物理的、可替代的部件。它遵循且提供一组接口的实现，每个构件体现了系统设计中特定类的实现。良好定义的构件不直接依赖于其他构件而依赖于构件所支持的接口。在这种情况下，系统中的一个构件可以被支持正确接口的其他构件所替代。在每个系统中都有不同类型的部署构件，如JavaBean、DLL、Applet和可执行exe文件等。在Rational Rose中，使用如图2-15所示的形式来表示构件。
• 节点（Node）。节点是系统在运行时切实存在的物理对象，表示某种可计算资源，这些资源往往具有一定的存储能力和处理能力。一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点。一个节点可以代表一台物理机器，或代表一个虚拟机器的节点。在Rational Rose中，包含两种节点，分别是设备节点和处理节点。这两种节点的表示方式如图2-16所示，它们在图形表示上稍有不同。

（2）行为事物（Behavioral Thing）

行为事物是指UML模型的相关动态行为，是UML模型的动态部分，它可以用来描述跨越时间和空间的行为。行为事物在模型中通常使用动词来表示，例如“上课”“还书”等。可以把行为事物划分为两类，分别是交互和状态机。

• 交互（Interaction）。交互是指在特定的语境（Context）中，一组对象为共同完成一定的任务，而进行的一系列消息交换而组成的动作，以及在消息交换的过程中形成的消息机制。因此，在交互中包括一组对象、连接对象间的消息，以及消息发出的动作形成的有序序列和对象间的普通连接。交互的可视化表示主要通过消息来表示。消息由带有名字或内容的有向箭头来表示，如图2-17所示。
• 状态机（State Machine）。状态机是一个类的对象所有可能的生命历程的模型，因此状态机可用于描述一个对象或一个交互在其生命周期内所经历的状态序列。当对象探测到一个外部事件后，它依照当前的状态做出反应，这种反应包括执行一个相关动作或转换到一个新的状态中去。单个类的状态变化或多个类之间的协作过程都可以用状态机来描述。利用状态机可以精确地描述类对象的行为。状态的可视化表示如图2-18所示。

（3）分组事物（Grouping Thing）

分组事物是UML对模型中的各种组成部分进行事物分组的一种机制。可以把分组事物当成是一个“盒子”，那么不同的“盒子”就存放不同的模型，从而模型在其中被分解。目前只有一种分组事物，即包（Package）。UML通过包（Package）这种分组事物来实现对整个模型的组织，包括对组成一个完整模型的所有图形建模元素的组织。

包是一种在概念上对UML模型中各个组成部分进行分组的机制，它只存在于系统的开发阶段。在包中可以包含有结构事物、行为事物和分组事物。包的使用比较自由，可以根据自己的需要划分系统中的各个部分，例如可以按外部Web服务的功能来划分这些Web服务。包是用来组织UML模型的基本分组事物，它也有变体，如框架、模型和子系统等。包的表示方法如图2-19所示。

（4）注释事物（Annotational Thing）

注释事物是UML模型的解释部分，用于进一步说明UML模型中的其他任何组成部分。我们可以用注释事物来描述、说明和标注整个UML模型中的任何元素。有一种最主要的注释事物，称为注释（Note，或称为注解）。

注释是依附于某个元素或一组建模元素之上，对这个或这一组建模元素进行约束或解释的简单注释符号。注释的一般形式是简单的文本说明。注释可以帮助我们更加详细地解释要说明的模型元素所代表的内容。注释的符号表示如图2-20所示。在方框内，填写需要注释的内容。

2．关系

在前文提到，UML模型是由各种事物以及这些事物之间的各种关系构成的。关系是指支配、协调各种模型元素存在并相互作用的规则。UML中主要包含四种关系，分别是依赖、关联、泛化和实现。

（1）依赖（Dependency）关系

依赖关系指的是两个事物之间的一种语义关系，当其中一个事物（独立事物）发生变化就会影响另外一个事物（依赖事物）的语义。如图2-21所示，反映了事物NewClass依赖于事物NewClass2。

（2）关联（Association）关系

关联关系是一种事物之间的结构关系，用它来描述一组链，链是对象之间的连接。关联关系在系统开发中经常会被用到，系统元素之间的关系如果不能明显地由其他三类关系来表示，都可以被抽象成为关联关系。关联关系可以是聚合（Aggregation）或组合（Composition），也可以是没有方向的普通关联关系。聚合是一种特殊类型的关联，它描述了整体和部分间的结构关系。组合也是一种关联关系，描述了整体和部分间的结构关系，表示部分是不能够离开整体而独立存在。如图2-22所示，反映了职员和经理之间的关联关系。职员是雇员，经理是雇主，这是对这种关联关系角色的定义。

（3）泛化（Generalization）关系

泛化关系是事物之间的一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象，也就是在面向对象的方法论中常常提起的继承。通过继承，子元素具有父元素的全部结构和行为，并允许在此基础上再拥有自身特定的结构和行为。在系统开发过程中，泛化关系的使用并没有什么特殊的地方，只要注意能清楚明了地刻画出系统相关元素之间所存在的继承关系即可。如图2-23所示，反映了货车和运输工具之间的泛化关系。

（4）实现（Realization）关系

实现关系也是UML元素之间的一种语义关系，它描述了一组操作的规约和一组对操作的具体实现之间的语义关系。在系统的开发中，通常在两个地方需要使用实现关系，一种是用在接口和实现接口的类或构件之间；另一种是用在用例和实现用例的协作之间。当类或构件实现接口时，表示该类或构件履行了在接口中规定的操作。如图2-24所示，描述的是类对接口的实现。