服装软件建模技术

本章将介绍面向服装软件建模中的UML建模语言，并通过实例来介绍如何使用UML来进行建模。UML是软件和系统开发的标准建模语言，它主要以图形的方式对系统进行分析、设计。开发人员主要使用UMI。来构造各种模型，以便描述系统的需求和设计。本章先从面向对象建模开始对软件开发过程中的模型及如何建模进行描述，然后对UML建模中的9种模型图分成用例模型图(用例图)、静态模型图(类图、对象图、组件图和配置图)和动态模型图(活动图、顺序图、协作图和状态图)进行一一介绍。通过对本章的学习，读者能深刻体会到使用UML对系统建模带来的高效性和简捷性。

面向对象建模
建模是为了能够更好地理解正在开发的系统。所谓模型，就是为了理解事物而对事物做出的一种抽象模拟，是对事物的一种无歧义的书面描述。通常，模型由一组图示符号和组织这些符号的规则组成，利用它们来定义和描述问题域中的术语和概念。更进一步讲，模型是一种思考工具，利用这种工具可以把知识规范地表示出来。模型可以帮助思考问题、定义术语、在选择术语时做出适当的假设，并且可以保持定义和假设的一致性。
在系统设计中采用模型化设计的一个重要原因是简化系统设计的复杂性。模型化可以帮助用户从高层理解系统，使用户专注于系统设计的重要部分，收集关键信息，而不需要关心一些无关的部分。模型是组织大量信息的一种有效机制。
通过建模，可以达到4个目的：
(1)有助于按照实际情况或按照所需要的样式对系统进行可视化。
(2)能够规约系统的结构或行为。
(3)给出指导构造系统的模板。
(4)对做出的决策进行文档化。
为了开发复杂的软件系统，系统分析人员应该从不同的角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。对于那些因过分复杂而不能直接理解的系统，特别需要建立模型。建模的目的主要是为了减少复杂性，人的头脑每次只能处理一定数量的信息，模型通过把系统的重要部分分解成人的头脑一次能处理的若干个子部分，从而减少系统的复杂程度。
用面向对象方法开发软件，通常需要建立三种形式的模型，它们分别是描述系统数据结构的对象模型，描述系统控制结构的动态模型和描述系统功能的功能模型。这三种模型都涉及数据、控制和操作等共同的概念，只不过每种模型描述的侧重点不同。这三种模型从三个不同但又密切相关的角度模拟目标系统，它们各自从不同侧面反映了系统的实质性内容，综合起来则全面地反映了对目标系统的需求。一个典型的软件系统组合了上述三方面的内容，软件系统使用数据结构(对象模型)，执行操作(动态模型)，并且完成数据值的变化(功能模型)。

UML简介
UML是一种标准的建模语言，是用来为面向对象开发系统的产品进行说明、可视化和编制文档的方法。它主要以图形的方式对系统进行分析、设计。软件工程领域在1995—1997年取得了前所未有的进展，其成果超过了软件工程领域过去15年来的成就总和。其中最重要、具有划时代重大意义的成果之一就是UML的出现。从第一个UML标准1．0于1997年推出以来，软件产业界支持UML的各种工具和平台也被迅速推出，UML及其平台已被广泛应用于软件开发的各个阶段，包括分析、设计、测试、实现、配置和维护过程。由于UML已由国际对象管理组织(ObjectManagementGroup，0MG)标准化为软件建模的统一语言，因此在工业界、学术界已被广泛承认与采用。在世界范围内，UML是面向对象技术领域内占主导地位的标准建模语言。
UML的核心是由视图(Views)、图(Diagrams)、模型元素(ModelElements)和通用机制(GeneralMechanism)等几部分组成。
视图用来表示被建模系统的各个方面(从不同的目的出发，为系统建立多个模型，这些模型都反映同一个系统，且具有一致性)。视图由多个图(Diagrams)构成，它们不是一张简单的图片，而是在某一个抽象层上对系统的抽象表示。同时不同视图之间存在一些交叉，因此一幅图可以作为多个视图的一部分。如果要为系统建立一个完整的模型图，只需要定义一定数量的视图，每个视图表示系统的一个特殊的方面就可以了。另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。UML中具有多种视图，细分起来共有用例视图、逻辑视图、并发视图、组件视图和配置视图5种。
用例视图定义系统的外部行为，帮助人们理解和使用系统。用例视图包括用例图(UseCase)和活动图(ActivityDiagram)。它的主要作用是描述系统的功能需求，找出用例和执行者。同时它也是系统的中心，决定了其他视图的开发。
逻辑视图描述了支持用例视图的逻辑结构，它包括类图(ClassDiagram)、状态图(StateDiagram)、顺序图(SequenceDiagram)、协作图(CollaborationDiagram)和活动图。它的主要作用是描述如何实现系统内部的功能及系统的静态结构和因发送消息而出现的动态协作关系。
并发视图主要描述形成系统并发与同步机制的线程和进程，是逻辑视图面向进程的变体。它包含顺序图、协作图、状态图、活动图、组件图(ComponentDiagram)和配置图(DeploymentDiagram)。
组件视图描述代码部件的物理结构以及各组件之间的依赖关系。一个组件可能是一个资源代码部件、一个二进制部件的物理结构或一个可执行部件，它包含逻辑类或实现类的有关信息。它主要是由组件图来描述的。
配置视图定义系统中软件硬件的物理体系结构，如计算机、硬件设备以及它们相互间的连接。它主要是由配置图来描述的。
每一种UML的视图都是邮一个或多个图组成的，一个图就是系统架构在某个侧面的表示，所有的图一起组成了系统的完整视图。UML定义了9种不同的图的类型，把它们有机结合起来就可以描述系统的所有视图。UML建模结构图可以分为两大类：一类是静态图，包括用例图、类图、对象图、组件图和配置图；另一类是动态图，包括顺序图、协作图、状态图和活动图。
UML利用若干视图从不同的角度来描述一个系统，每种视图由若干幅模型图进行描述，每幅模型图由若干个模型元素来描述。模型元素代表面向对象中的类、对象、用例、接口、包、消息和关系等概念，是构成图的最基本的常用概念。一个模型元素可以用在多个不同的图中，无论怎样使用，它总是具有相同的含义和相同的符号表示。模型元素包括事物和事物之间的关系，是UML中重要的组成部分。
通用机制用于表示其他信息，如注释、模型元素的语言等。另外，它还提供扩展机制，使UML能够适应一个特殊的方法，或扩充至一个组织或用户。

用例视图
人们在进行软件开发时，无论是采用面向对象方法还是传统方法，首先要做的就是了解需求。由于用例图是从用户角度来描述系统功能的，所以在进行需求分析时，用例图可以更好地描述系统应具备什么功能。用例图由开发人员与用户经过多次商讨而共同完成，面向服装软件建模的其他部分都是从用例图开始的。这些图以每一个参与系统开发的人员都可以理解的方式列举系统的业务需求。
用例视图中可以包含若干个用例(UseCase)。用例图用来表示系统能够提供的功能(系统用法)，一个用例是系统功能(ffl法)的一个通用描述。用例视图是其他视图的核心和基础，其他视图的构造和发展依赖于用例图中所描述的内容。因为系统的最终目标是提供用例视图中描述的功能，同时附带一些非功能的性质，因此用例视图影响着其他视图。同时，用例视图还可用于测试系统是否满足用户的需求和验证系统的有效性。
在UML中，用例用椭圆来表示。它用来记录用户或外界环境从头到尾使用系统的一系列事件。用户被称为“活动者”(Actor)，活动者可以是人，也可以是另一个系统。它与当前的系统进行交互，向系统提供输入或从系统中获得输出，用一个人形(Stickman)来表示。用例图显示了用例和活动者、用例与用例之间以及活动者与活动者之间的关系。关系描述模型元素之间的语义连接。在UML中，关系使用实线来表示，实线可以有箭头，也可以没有箭头。
1．活动者
活动者是指在系统外部与系统交互的人或其他系统，他以某种方式参与系统内用例的执行。当划分了系统的范围并明确了系统边界后，从系统应用的角度出发，找寻那些与系统进行信息交换(包括数据信息和控制信息)的外部事物，包括系统使用人员、硬件设备及外部系统，来确定执行者。可以从以下角度来寻找和确定活动者：
(1)使用系统主要功能的人。
(2)需要借助于系统完成日常工作的人。
(3)维护、管理系统，保证系统正常工作的人。
(4)系统是否使用外部资源。
(5)系统和已经存在的系统是否存在交互。

2．用例
用例代表的是一个完整的功能，是活动者想要系统做的事情。它是特定活动者对系统的“使用情况”。用例一般具有以下特征：
(1)用例总是由活动者开始的。用例所代表的功能必须由活动者激活，然后才能执行。
(2)用例总是从活动者的角度来编写的。由于用例描述的是用户的功能需求，只能从用户的角度出发才能真正了解用户需要什
么样的功能。
(3)用例具有完全性。
用例是一个完整的描述。虽然在编程实现时，一个用例可以被分解成为多个小用例(函数或方法)，每个小用例之间可以互相调用执行，但是只有最终产生了返回给活动者的结果值，才能说用例执行完毕。
实际上，从识别活动者起，发现用例的过程就已经开始了。对于已识别的活动者，可以从以下一些角度发现用例：
(1)活动者需要从系统中获得哪种功能?
(2)活动者需要读取、产生、修改、删除或是存储系统中的某种信息吗?
(3)需要将外部的哪个变化告知系统吗?
(4)需要将系统的哪个事件告知活动者吗?
(5)如何维护系统?

3．用例图内元素的关系
一般将活动者和用例之间的关系称为通信，而用例与用例之间可以存在的关系分为泛化(Generalization)、包含(Include)、扩展(Extend)和使用(Use)4种。另外，活动者与活动者之间也可以存在泛化关系。
(1)泛化关系。
UML中的泛化关系就是通常所说的继承关系，表示几个元素的某些共性。它是通用元素和具体元素之间的一种分类关系。在UML中，用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素。
例如在买票系统中，个人购买和团体定购都是买票的特例，肯定有一些共同的特征，将这些共同的特征抽象出来，定义一个“买票”的基本用例(基用例)，个人购买和团体购买从“买票”的基用例继承。可以用如图4．3所示的用例图来表示。
如果多个活动者之间存在很多共性，就可以使用泛化来分解共性行为。
(2)包含关系。
包含关系指的是两个用例之间的关系，其中一个用例(基用例)的行为包含另一个用例的功能。如果两个以上的用例有相同的功能，则可以将这个功能分解到另一个用例中，基用例则包含了分解出来的新用例的功能。
包括关系是比较特殊的依赖关系，它们比一般的依赖关系多了一些语义。在包含关系中，箭头的指向是从基本用例到包含用例，也就是说，
基本用例依赖于包含用例。
(3)扩展关系。
扩展关系的基本含义与泛化关系类似，但对扩展用例有更多的限制，即基用例必须有若干个“扩展点”。而扩展用例只能在扩展点上增加新的行为和含义。也就是说，扩展关系允许一个用例(可选)扩展另一个用例(基用例)提供的功能。与包含关系一样，扩展关系也是依赖关系，而包含关系是特殊的依赖关系，这两个关系都是把相同功能分离到另一个用例中。在UML中，对扩展用例有更多的规则限制：
·基本用例可以是独立的。
·在一定条件下，基本用例的动作可由另外一个用例扩展而来。
·基本用例必须注明若干“扩展点”，扩展用例只能在这些扩展点上增加一个或多个新的动作。
·通常将一些常规的动作放在一个基本用例中，将非常规动作放在它的扩展用例中。在UML中使用<<extend>>表示扩展关系，箭头的方向是从扩展用例到基用例。
例如，在自动售货机系统中，“售货”是一个基本的用例，如果顾客购买罐装饮料，售货功能可以顺利完成。但是，如果顾客要购买用纸杯装的散装饮料，则不能执行该用例提供的常规动作，而要做些改动。我们可以修改售货用例，使之既能提供销售罐装饮料的常规动作又能提供销售散装饮料的非常规动作。我们可以把常规动作放在售货用例中，把非常规动作放置于销售散装饮料用例中，这两个用例之间的关系就是扩展关系，如图4．6所示。

(4)使用关系。
使用关系也是一种继承关系。在使用关系中，一个用例使用另一个用例的功能和行为。在UML中，用例之间的使用关系的图形描述和用例的继承关系一样，用一条带空心箭头的实线连接一个子用例和一个父用例，实线上方标明构造型<<use>>表明两个用例是使用关系。在系统分析与设计中，可以从以下几点考虑来定义用例之间的关系：
·一个用例偶尔使用另一个用例的功能描述时，采用继承关系。
·两个以上用例重复处理同样的动作，可以采用使用关系和包含关系。
·用例要采用多种控制方式对异常或任选动作进行处理时，采用扩展关系。
如图4．8所示的自动售货机系统中，“供货”与“收货款”这两个用例的开始动作都是“打开机器”用例，而它们的最后动作都是“关闭机器”用例，“供货”与“收货款”用例在执行时必须使用这两个用例。“售货”是一个基本用例，定义的是销售罐装饮料，而用例“销售散装饮料”则是在继承了“售货”的一般功能的基础上进行了修改，增加了新的功能，因此是“售货”用例的扩展。
动态模型图

活动图
用例图显示系统应该做什么，活动图则指明了系统将如何实现它的目标。活动图显示链接在一起的高级动作，代表系统中发生的操作流程。活动图用来描述面向对象系统的不同组件之间建模工作流和并发过程行为。
活动图用来描述采取何种动作、做什么(对象状态改变)、何时发生(动作序列)以及在何处发生(泳道)。在UML中，活动图可以用做下述目的：
·描述一个操作执行过程中所完成的工作(动作)，这是活动图最常见的用途。
·描述对象内部的工作。
·显示如何执行一组相关的动作以及这些动作如何影响它们周围的对象。
·显示用例的实例如何执行动作以及如何改变对象状态。
·说明在一次商务活动中人(角色)的工作流组织和对象是如何工作的。
在运行着的系统中，各种对象时刻都处于某种活动状态中，正是这一系列的活动完成了某些特定的系统功能(用例)要求。活动图本质上是一种流程图，其中几乎所有或大多数的状态都处于活动状态，它描述从活动到活动的控制流。用来建模工作流时，活动图可以显示用例内部和用例之间的路径；活动图还可以向读者说明需要满足什么条件用例才会有效，以及用例完成后系统保留的条件或者状态；在活动图建模时，常常会发现前面没有想到、附加的用例。在某些情况下，常用的功能可以分离到它们自己的用例中，这样便大大减少了开静府阳程序的时间。

1、活动图的基本要素
活动图的基本元素包括活动、迁移、起始活动、终止活动、条件判定以及并发活动，如果图4.9所示。
起始活动显示地表示活动图中一个工作流程的开始，用实心圆表示；在一个活动图中，只有一个起始活动。终止活动表示了一个活动图的最后和终结活动，用实心圆外加一个小圆圈来表示；在一个活动图中，可以有0个或多个终止状态。活动图中的动作用一个圆角四边形表示。动作之间的转移用带有箭头的实线来表示，称为迁移，箭头上可以还带有条件或者动作表达式。
条件用来约束转移，条件为真时迁移才可以开始。用菱形符号来表示决策点，决策符号可以有一个或多个进入转移，两个或更多的带有条件的外出迁移。可以将一个迁移分解成两个或更多的迁移，从而导致并发的动作。所有的并行迁移在合并之前必须被执行。一条粗黑线表示将迁移分解成多个分支，并发动作同样用粗黑线来表示分炙的合并，粗黑线称为同步棒。

2．泳道
活动图告诉人们发生了什么，但是不能告诉该项活动由谁来完成。对于程序设计而言，活动图没有指出每个活动是由哪个类负责。而对于建模而言，活动图没有表达出某些活动是由哪些人或哪些部门负责。虽然可以在每个活动上标记出其所负责的类或者部门，但难免带出诸多麻烦。泳道的引用解决了这些问题。
泳道将活动图划分为若干组，每一组指定给负责这组活动的业务组织，即对象。在活动图中泳道区分了负责活动的对象，它明确地表示了哪些活动是由哪些对象进行的。在包含泳道的活动图中每个活动只能明确地属于一个泳道。

3．活动图建模步骤
活动图描述用例图，用活动流来描述系统参与者和系统之间的关系。建模活动图也是一个反复的过程，活动图具有复杂的动作和工作流，检查修改活动图时也许会修改整个工程。所以有条理地建模会避免许多错误，从而提高建模效率。在建模活动图时，可以按照以下5步来进行：
(1)标识需要活动图的用例。
(2)建模每一个用例的主路径。
(3)建模每一个用例的从路径。
(4)添加泳道来标识活动的事务分区。
(5)改进高层活动并添加到更多活动图。
下面以学生成绩管理系统中，学生对成绩查询用例建模活动图为例来介绍如何建立活动图：
首先应该标识用例图，把学生查询成绩这个用例从完整的用例图中独立出来，具体的用例图如图4．10所示。
然后建立主路径，表示主要的流程，如图4．11所示。
活动图的主路径描述了用例图的主要工作流程，此时的活动图没有任何转移条件或错误处理。建模从路径的目标就是进一步添加活动图的内容，包括判断、转移条件和错误处理等。在主路径的基础上完善活动图，如图4．12所示。
在活动图中，加入泳道能够清晰地表达出各个活动由哪些部分负责。前面已经完成了对从路径的添加，虽然完整地描述了用例但从整体上来看图形很杂乱。为了解决图形杂乱的问题，可以为活动图添加泳道。
活动图建模的最后一步强调了反复建模的观点。在这一步中，需要退回到活动图中添加更多的细节。在大多数情况下，要退回活动图选择复杂的活动，不管是一个活动还是所有活动。对于这些复杂的活动，需要更进一步进行建模带有开始状态和结束状态完整描述活动的活动图。最后的活动图如图4．13所示。

4．活动图中的并发与同步活动
在活动图中，一个动作(或活动)状态的迁移可以分劈成两个或多个导致并行动作(或活动)状态的迁移；若干个来自并行动作(或活动)的迁移也可以接合成一个迁移。值得注意的是，一个动作(或活动)状态迁移分劈后，在接合之前并行迁移上的活动必须全部完成。也就是说，动作状态的同步分劈和同步接合要成对出现。在一个同步分劈与同步接合对中，可以嵌套另一个同步分劈与同步接合对。图4．14中就出现了同步分劈与同步接合对。

顺序图
在面向对象方法中，对象之间通过发送消息来相互通信，消息发送应遵循一定的通信协议。当一个对象调用另一个对象的操作时，消息通常是通过简单的操作调用来实现的。一条消息被画成从消息的发送者指向接收者的一个箭头线，线上标有消息内容标识。消息一旦发送，系统控制权便从发送者转移到接收者。当一个操作被执行后，控制权将返回给消息发送者，并携带一个回送值。
对象之间的通信可以同步进行，也可以异步进行。在UML中，消息的分类可以从两个角度区分，一是从消息触发的动作来区分，二是从消息的过程控制流进行区分。通过发送消息可以触发的动作包括：
·创建一个对象或释放一个对象。
·调用另一个对象的操作。
·调用本对象的操作。
·发送信息给另一个对象。
·返回值给调用者。
消息分为简单消息、同步消息、异步消息和返回消息4种，如图4．15所示。
1．简单消息简单消息——————————哼
表示控制流，用带叉形箭头的实箭线表示。它展示了控
制如何从一个对象传递到另一个对象，但不描述任何通信的
细节。当通信细节不清楚或在图中涉及不到时，使用这种消
息类型。
2．同步消息
同步消息一
异步消息一
返回消息…一一一一一一一一÷
图4．15UMI．中消息类型
它是一种嵌套的控制流，用带实心三角形箭头表示。同步消息通常用操作调用来实现。这种消息的处理一般在被调用的操作执行后，调用者再继续执行。当消息被处理完后，可以回送一个简单消息，或者是隐含地返回。
3．异步消息
它是异步控制流，用带半叉的实箭线表示。它没有明显的返回信息回送给调用者。消
息的发送者在发送消息后就继续执行，而不等待消息的处理。这种通信方式通常用于对象并发执行的实时系统。
4．返回消息
表示控制流从过程调用的返回，用带叉形箭头的虚箭线表示。一般可以省略，隐含表示每一个调用都有一个配对的调用返回。省略时，返回值可以标在初始调用的箭线上。对于非过程控制流，包括并行处理和异步消息，表示返回的虚箭线不能省略。
顺序图用来描述对象之间动态的交互关系，着重体现对象间消息传递的时间顺序，是一种强调消息的时序交互图。它由活动者、对象、消息、生命线和激活期组成。在UMI。中，对象表示为一个矩形，其中对象名称标有下标线；消息在顺序图中由有标记的箭头表示；生命线由虚线表示，激活期由薄薄的矩形框表示。

1．对象
顺序图中所包含的每个对象用一个对象框表示，对象名需带下划线。
(1)对象名后面可以跟“：”及创建该对象的类名。
(2)对象一般位于顺序图的顶部。
(3)交互频繁的对象尽量靠拢，可以使画面清晰。
(4)对整个交互活动进行初始化的对象放在图的最左边。
(5)在交互过程中产生的对象应放在产生该对象的时问点处。
(6)过程中对象改变了属性值、状态或角色，则在生命线上该对象的改变点处画上该对象的图符副本，并注明有关的变更。
2.生命线
对象框下面的一条垂直虚线，称为该对象的生命线，表示该对象的生存时间。
(1)生命线从该对象创建开始到释放，其生存期多长，虚线就有多长。
(2)生命线表示该对象的生命处在休眠期，等待消息的激活。
3．消息
在顺序图中，对象之间消息的传递用两个对象生命线之间的消息箭头线表示，用来指出该对象执行期间的时序。
(1)在顺序图中，不同的消息表示对象间不同的类型的通信。
(2)简单消息表示消息类型未知或与类型无关，或是一个同步消息的返回。
(3)同步消息表示发送对象必须等接收对象完成消息的处理后才能继续执行。
(4)异步消息表示发送对象在消息发送后继续执行，而不等待接收对象的返回消息。
(5)传送延迟可用倾斜的箭头表示，意思是消息发送后需经历一段延迟时间才被接收。
4．激活期
对象生命线上的一个细长方形框，表示该对象的激活时间段。
(1)当一个休眠的对象接收到一个消息时，该对象开始活动，称为激活。
(2)激活展示了某时间点哪个对象能够响应或发送消息，执行动作或活动。
(3)一个激活的对象要么在执行自己的代码，要么在等待另一个对象的返回。
(4)按垂直坐标从上到下的次序读顺序图，可以观察到随时间的前进消息通信的顺序。
(5)激活期长方形的上端与动作的开始时间齐平，下端与动作的完成时问齐平。
(6)激活期外，对象处在休眠期，什么事都不做，但它仍然存在，等待消息的激活。
下面通过对学生成绩管理系统中的学生成绩查询用例来介绍如何建立顺序图。
分析学生成绩查询用例，主要的事件流如下：
(1)学生进行登录界面。
(2)学生输入登录信息并登录。
(3)系统对登录信息进行验证。
(4)登录成功则出现查询主界面；登录失败则回到登录界面。
(5)学生输人查询信息。
(6)系统对学生输入的信息进行查询。
(7)数据库中有相关的成绩信息则在界面中显示出来；没有相关成绩的信息则在界面返回查询错误信息。
从事件流中发现本用例涉及以下对象：
(1)界面。
(2)对于业务层的操作，也应该有对象进行处理。
(3)事件流中设计的活动者有学生和数据库。
最后，分析对象、活动者之间的交互消息，本用例主要有以下交互：
(1)学生通过界面发送登录界面。
(2)界面向控制对象发送登录信息。
(3)控制对象向数据库请示验证登录。
(4)登录成功则显示查询界面。
(5)登录失败则返回登录界面。
(6)学生向界面输入查询信息。
(7)将查询信息传送到控制对象。
(8)控制对象将查询信息发送到数据库进行查询。
(9)若有相关信息则返回成绩信息；若查询失败则返回查询错误信息。

协作图
协作图和顺序图都可以用来描述系统对象之间的交互。顺序图强调一组对象之间操作调用的时间顺序，协作图则强调这组对象之间的关系。协作图中包含一组对象及其相互间的关联，通过关联上传递的消息描述组成系统的各个成分之间如何通过协作以实现系统的行为。协作图由活动者、对象、连接和消息等基本元素组成。
1．对象
与顺序图一样，协作图中的对象也用短式标记，即在一个方框内标识对象名。对象一般在协作图中担当一个具体的角色，可以把对象名写为对象的角色名。如果不标明角色名，则说明该对象角色为匿名对象。
2．连接
在协作图中，对象之间的连接用连接两个对象的实线表示。在连接上可以标明角色名。连接角色名用来说明连接路径，规定在交互中对象之间连接的角色类型。
3．消息
将协作图画成对象图，图中的消息箭头表示对象之间的消息流，消息上标以序号，说明消息发送的顺序，还可以指明条件、重复和回送值等。一个协作图从一个引起整个系统交互或协作的消息开始，例如调用某一个操作。
顺序图和协作图都描述交互，但是顺序图强调的是时间，而协作图强调的是空间。连接显示真正的对象以及对象间是如何联系在一起的。在协作图中，对象同样是用一个对象图符来表示的，箭头表示消息发送的方向，而消息的执行顺序则由消息的编号来标明。协作图中的消息由标记在连接上方的带有标记的箭头表示。
协作图更侧重于说明哪些对象之间有消息传递，而不像顺序图那样侧重于在某种特定的情形下对象之间传递消息的时序性。与顺序图中从上而下的生命线相比，通过编号来看消息执行的时间顺序显然要困难得多。但是，协作图中对象间灵活的空间布局使人们可以更方便地展示另外一些有用信息。例如，更易于显示对象之间的动态连接关系。
协作图中消息执行顺序的编号方案有很多种，可以自行挑选，最常用的有以下两种方案。
(1)从1开始，由小到大顺序排列。
(2)一种小数点制编号方案，其中整数位常常用来表示模块号。
如图4．17所示是一个蜂窝电话的协作图。
顺序图和协作图语义是等价的，可以在不丢失任何信息的情况下，从一种图转换成另一种图。虽然协作图和顺序图均显示了交互，但它们强调了不同的方面。顺序图清晰地显示了时间次序，但没有显式地指明对象间的关系。协作图清晰地指明了对象间的关系，但时间次序必须从顺序号来获得。顺序图最常用于场景显示，协作图更适合显示过程设计细节。

状态图
状态图是众多开发人员都十分熟悉甚至经常使用的工具，它描述了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转移。大多数面向对象技术都使用状态图来描述一个对象在其生命周期中的行为，尤其是通过给单个类绘制图以表示该类单个对象的生存期行为。状态图适合于描述跨越多个用例的单个对象的行为，而不适合描述多个对象之问的行为协作。
对象从产生到结束，可以处于一系列不同的状态。状态影响对象的行为，当这些状态的数目有限时，就可以用状态图来为对象的行为建模，显示其生命的整个过程。状态图把系统或对象所经历的状态以及导致状态转变的事件以图的方式显示出来。在画对象的状态图时，需要考虑以下因素：
·对象有哪些有意义的状态。
·如何决定对象的可能状态。
·对象的状态图和其他模型之间如何进行映射。
状态图由表示状态的节点和表示状态之间转换的带箭头的直线组成。若干个状态由一条或者多条转换箭头连接，状态的转换由事件触发。模型元素的行为可以由状态图中的一条通路表示，沿着此通路执行一系列动作。
在UMI。中，状态图由状态、迁移、初始状态、终止状态、条件判定等元素组成。
(1)状态。
状态的图符用一个圆角的矩形框表示。状态图符的长式由状态名、状态变量和内部活动三个部分组成，状态图符的短式只写上状态名就可以了。
(2)迁移。
用实箭线表示，箭尾连接起始状态，箭头连接目标状态。
(3)初始状态。
代表状态图的起始点，本身无状态。初始状态是迁移的开始源点，不是迁移的目标。起始状态由一个实心圆表示。
(4)终止状态。
代表状态图的最终状态，本身无状态，是状态图的终止点。最终状态是迁移的最后目标，不是迁移的源。结束状态由一个圆中套一个实心圆表示。
(5)条件判定。
与程序设计语言中的条件分支类似，条件判定是一个转折点，状态迁移按照满足条件的方向进行。条件判定图符用空心菱形表示，条件判定通常为一个人迁移，多个出迁移。条件是一个逻辑表达式，状态迁移沿判定条件为真的分支触发迁移。
在UML中，建立状态图模型的基本步骤如下：
(1)确定状态图描述的主体，可以是整个系统、一个用例、一个类或一个对象。
(2)确定状态图描述的范围，明确初始状态和最终状态。
(3)确定描述主体在其生存期的各种稳定状态，包括高层状态和可能的子状态。
(4)确定状态的序号，对这些稳定状态按其出现的先后顺序编写序号。
(5)确定触发状态迁移的事件，该事件可以触发状态进行迁移。
(6)附上必要的动作，把动作附加到相应的迁移线上或对应的状态框内。
(7)简化状态图，利用嵌套状态、子状态、分支、分劈、合并和历史状态简化状态图。
(7)简化状态图，利用嵌套状态、子状态、分支、分劈、合并和历史状态简化状态图。
(8)确定状态的可实现性，每一个状态在事件的某些组合触发下都能达到。
(9)确定无死锁状态，死锁状态是任何事件触发都不能引起迁移的状态。
(10)审核状态图，保证状态图中所有事件都可以按设计要求触发并引起状态迁移。
使用同步棒可以显示并发转移，并发转移中可以有多个源状态和目标状态。并发转移表示一个同步将一个控制划分为并发的线程。状态图中使用到同步棒是为了说明某些状态在哪里需要跟上或者等待其他状态。在状态图中同步棒用一条黑色的粗线表示，图4．19显示了使用了同步棒的状态图。
在实际应用中，并不需要为所有的类建立状态图。但人们有时候往往关心某些关键类
的行为，如果为这些类建立状态图，则可以帮助理解所研究的问题。其实，也只有在这种情
况下，才有必要绘制状态图。
在UML软件开发过程中，系统的动模型主要包括对象交互模型和对象的状态模型。
对象交互模型由顺序图和协作图描述，对象的状态模型则由状态图和活动图进行描述。
状态图可以表现一个对象在生存期的行为、所经历的状态序列、引起状态迁移的事件以
及因状态迁移而引起的动作。活动图是描述一个系统或对象动态行为的一种方法，是状态
图的另一种表现形式。活动图的功能主要是记录各式活动和由于其对象状态转换而产生的
各种结果。

状态图与活动图有某些相同点，又有一些不同点。
1。相同点
(1)描述符基本相同。
在活动图与状态图中，除了活动的图符由两边是半圆边线的矩形表示，状态的图符由圆角矩形表示外，其余的描述图符两者完全相同。
(2)可以描述一个系统或对象在生存期间的状态或行为。
状态图用来描述一个对象在生存期的行为、所经历的状态序列、引起状态迁移的事件以及因状态迁移而引起的动作。活动图用来描述一个系统或对象完成一个操作所需要的活动，或者是一个用例实例的活动。
(3)可以描述一个系统或对象在多进行操作中的同步与异步操作的并发行为。
在活动图与状态图中，都有用于描述多进程中的同步与异步操作的分劈与合并的图符。所以，都可以描述一个系统或对象在多进程操作中的同步与异步操作的并发行为。
(4)可以用条件分支图符描述一个系统或对象的行为控制流。

2．不同点
(1)触发一个系统或对象的状态发生迁移的机制不同。
状态图中的对象要发生迁移，必须有一个可以触发状态迁移的事件发生，或有一个满足了触发状态迁移的条件产生。活动图中的活动状态迁移不需要事件触发，一个活动执行完毕可以直接进入下一个活动状态。
(2)描述多个对象共同完成一个操作的机制不同。
状态图一般用来描述一个系统或某个对象在生存期的行为、所经历的状态序列、引起状态迁移的事件以及因状态迁移而引起的动作。状态图采用状态嵌套的方式来描述多个对象共同完成的一个操作。活动图通过采用建立泳道的方法来描述一个系统中几个对象共同完成一个操作或一个用例实例所需要的活动。

静态模型图
类图
面向对象模型的基础是类、对象以及它们之间的关系。可以在不同类型的系统中应用面向对象技术，在不同的系统中描述的类可以是各种各样的。例如，在某个商务信息系统中，类可以是顾客、协议书、发票、债务等；在某个工程技术系统中，类可以是传感器、显示器、I／O卡、发动机等。
在面向对象的处理中，类图处于核心地位，它提供了用于定义和使用对象的主要规则，同时，类图是正向工程(将模型转化为代码)的主要资源，也是逆向工程(将代码转化为模型)的生成物。因此，类图是任何面向对象系统的核心，类图随之也成了最常用的UML图。
类图是描述类、接口以及它们之间关系的图，它显示了系统中各个类的静态结构，是一种静态模型。类图根据系统中的类以及各个类的关系描述系统的静态视图。可以用某种面向对象的语言实现类图中的类。
类图是面向对象系统建模中最常用和最基本的图之一，其他许多图，如状态图、协作图、组件图和配置图等都是在类图的基础上进一步描述了系统其他方面的特性。类图中可以包含7个模型元素，它们分别是：类、接口、依赖关系、泛化关系、关联关系和实现关系等模型元素。在类图中也可以包含注释、约束、包或子系统。
类是构成类图的基础，也是面向对象系统组织结构的核心。要使用类图，需要了解类和对象之间的区别。类是对资源的定义，它所包含的信息主要用来描述某种类型实体的特征以及对该类型实体的使用方法。对象是具体的实体，它遵守类制定的规则。从软件的角度看，程序通常包含的是类的集合以及类所定义的行为，而实际使用的是遵守类规则的对象。
类定义了一组具有状态和行为的对象，这些对象具有相同的属性、操作、关系和语义，其中，属性和关联用来描述状态。属性通常用没有身份的数据值表示，如数字和字符串。关联则用对象之间的关系来表示。行为由操作来描述，方法是操作的实现。
1．寻找类
从用例图中寻找类，一般是从用例的事件流开始，查处事件流中的名词来获得类，在事件流中，名词可以分为角色、类、类属性和表达式4种类型；也可以检查顺序图和协作图中的对象，通过对象的共性来寻找类，顺序图和协作图中的每一个对象都要映射到相应的类。
当然，可能有些类无法通过以上方法找到。
类可以分为实体类(Entity)、边界类(Boundary)和控制类(Contr01)三种类型。实体类保存永久信息。如在学生成绩管理系统中，可以抽象出学生类、老师类、系统管理员等实体类。实体类通常在事件流和交互图中，是对用户最有意义的类，通常采用业务领域术语命名。
边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口以及与其他系统的接口。要寻找和定义边界类，可以检查用例图，每个活动者和用例交互至少要有一个边界类。边界类使活动者能与系统交互。
控制类负责协调其他类的工作，每个用例通常都有一个控制类来控制用例中事件的顺序。在交互图中，控制类具有协调责任，可能有许多控制类在多个用例间共用的情况。

2．类表示
在UML中一个类用一个矩形方框表示，它被分成三个区域。最上面的区域是类名，中间的区域是类的属性，下面的区域是类的操作。类图就是由这些类和表明类之间如何关联的连线组成。

3.类关系
类图由类及类与类之间的关系组成。在类图中，常用的关系主要有关联、聚集、泛化、依赖和实现5种关系。
（1）关联。
关联表示类的实例之间存在的某种关系，定义了对象之间的关系不准则，在应用程序创建和使用关系时，关联提供了维护关系完整性的规则，通常用一个无向线表示。
只要类与类之间存在连接关系就可以用普通关联表示。普通关联的图符号是连接两个类之间的直线。通常，关联是双向的，可在一个方向上为关联起一个名字，在另一个方向上起另一个名字。
在表示关联的直线两端可以写上重数，用“..”分隔开的区间表示，它表示该类有多少个对象与对方的一个对象连接。

(2)聚集。
聚集是一种特殊类型的关联，它指出类间的“整体与部分”关系。聚集是关联的特例，它可以有重数、角色、限制符号等。聚集关联有共享聚集和组合聚集两种。
共享聚集的部分对象可以是任意整体对象的一部分，表泮事物的整体与部分关系较弱的情况，如果整体端的重数不是1，则这种聚集是共享的。空心菱形表示共享聚集，画在代表事物整体的一端。
组合聚集是指整体拥有它的部分，它具有强的物主身份，表示事物的整体与部分关系较强的情况。实心菱形表示组合聚集，画在代表事物整体的一端部分生存在整体中不可分离，它与整体一起存在或消亡。整体的重数必须是。或1，而部分重数可以是任意的。

(3)泛化。
UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。在UMI．中，用一端为空心的三角形连线表示泛化关系，三角形的顶角紧挨着通用元素。
泛化关系描述了“isakindof”(是……的一种)的关系。例如，彩色电视机和黑白电视机都是电视机的一种。在类中，通用元素被称为超类或父类，而具体元素被称为子类。

(4)依赖。
依赖是两个模型元素之间的语义连接，一个是独立的模型元素，另一个是依赖的模型元素，独立元素的变化会影响依赖的元素。例如，一个类把另一个类的对象作为参数，一个类访问另一个类的全局对象，或者一个类调用另一个类的类操作。依赖用带箭头的虚线表示，位于虚线箭头尾部的类(称为用户)依赖于箭头所指向的类(称为供应者)。
在图4．25中，课程表的安排依赖于实际开设的课程。“课程”类是独立的类，而“课程表”类依赖于“课程”类。在“课程表”类中，“增加课程”和“删除课程”这两个都把课程作为对象参数进行调用，一旦课程发生变化，课程表一定会发生变化。任课教师按课程表上课，“教师”类依赖于“课程表”类，课程表发生变化，任课教师也要跟着发生变化。

(5)实现
实现是规格说明和其实现之间的关系，它将一种模型元素与另一种模型元素连接起来，如类与接口。虽然实现关系意味着要具有接口一样的说明元素，但是也可以用一个具体实现元素来暗示它的说明必须被支持。例如，实现关系可以用来表示类的一个优化形式和一个简单低效的形式之间的关系。在UML中，实现关系的符号与泛化关系的符号类似，用一条带指向接口的空心三角箭头的虚线表示。

组件是系统中可以进行替换的物理部分，它不仅将系统如何实现包装起来，而且提供一组实现了的接口。所以它表示实现后的实体，也就是物理实体。组件是可以复用的单元，具有非常广泛的定义。每个组件可能包含很多类，实现很多接口。
组件图描述了软件的各种组件和它们之间的依赖关系。组件图中通常包含组件、接口和依赖关系三种元素。每个组件实现一些接口，并使用另一些接口。如果组件间的依赖关系与接口有关，那么可以被具有同样接口的其他组件所替代。
组件是软件的单个组成部分，它可以是一个文件、产品、可执行文件或脚本等。通常情况下，组件代表了将系统中的类、接口等逻辑元素打包后形成的物理模块。

为了加深理解，下面对组件与类之间的异同进行简单的对比。组件和类的共同点是：两者都具有自己的名称、都可以实现一组接口、都可以具有依赖关系、都可以被嵌套、都可以参与交互，并且，都可以拥有自己的实例。它们的区别为：组件描述了软件设计的物理实现，即代表了系统设计中特定类的实现，而类则描述了软件设计的逻辑组织和意图。
例如，在选课系统中包括MainProgram类、People类、FormObject类、ControlObject类、Student类、Registrar类、Course类和DataBase类。People类是Student类和Registrar类的基类，所以Student类和Registrar类依赖于People类。FormObject类和ControlObject类都和Course类相关，FormObject类和ControlObject类依赖Course类。ControlObject类和DataBase类相关，ControlObject类依赖DataBase类，将每个类单独设计成一个组件。

组年图显示软件组件以及它们之间的依赖关系，一般来说，软组件就是一个实际文件，主要有以下几种类型。
（1）源代码组件：一个源代码文件或者是与一个包对应的若干个源代码文件。
（2）二进制组件：一个目标代码文件、静态库文件或者动态链接库文件。
(3)可执行组件：可以在一台处理器上运行的一个可执行的程序单位，即所谓的可执行程序。
因为组件可以是源代码文件、二进制代码文件和可执行文件，所以通过组件图可以显示系统在编译、链接或执行时各软组件之间的依赖关系以及软组件之间的接口和调用关系。接口说明了操作的命令集合。接口背后的关键思想是通过诸如类或子系统这样的类元将功能性规格说明(接口)同它的实现相分离。接口定义了由类元所实现的契约。
接口是基于组件开发的关键，这是关于从插件程序如何构造软件的方法。一个组件可以有多个接口，用于和不同的组件进行通信，在组件图中可以表示出哪些组件与哪一个接口进行通信。

一个面向对象系统模型包括软件和硬件两方面的模型，经过开发得到的软件系统的组件和重用模块，必须配置在某些硬件上予以执行。在UML中，硬件系统体系结构模型由配置图建模。配置图由节点和节点之间的联系组成，描述了处理器、设备和软件组件运行时的体系结构。在这个体系结构中可以看到某个节点上在执行哪个组件，在组件中实现了哪些逻辑元素(类、对象、协作等)，完成了何种功能，最终可以从这些元素追踪到系统的需求分析(用例图)。组成配置图的基本元素有节点、组件、连接、依赖等。
配置图的最基本元素是节点。节点代表计算机资源，通常为处理器或其他硬件设备。节点既可看做类型，也可看做实例。当节点被看做实例时，节点名应有下划线。节点的图符用三维立方体表示，有短式图符和长式图符两种表示形式。
可执行组件实例可以包含在配置图中的节点实例图形符号中，表示它们在该节点实例上驻留并执行。节点与节点之间通过物理连接发生联系，以便从硬件方面保证系统各节点之间的协同运作，如以太网、共享总线等。节点之间，节点与组件之间的联系包括通信关系、依赖关联等。
节点通过通信关联相互连接，连接用一条直线表示，它指出节点之间存在着某些通信路径，并指出通过哪条通信路径可使这些节点问交换对象或发送信息。节点和组件之间，驻留在某一个节点上的组件或对象与另一个节点上的组件或对象之间也可以发生联系，这种联系称为依赖。

配置图建模包括如下步骤：
(1)确定节点。
根据硬件设备和软件体系结构的功能要求统一考虑系统的节点。
(2)确定驻留组件。
根据软件体系结构和系统功能要求分配相应组件驻留到节点上。
(3)注明节点性质。
用UML标准的或自定义的构造型描述节点的性质。
（4）确定节点之间的联系。
如果是简单通信联系，用关联连接描述节点之间的联系；可在关联线上标明使用的通信协议或网络类型。
(5)绘制配置图。
对于一个复杂的大系统，可以采用打包的方式对系统的众多节点进行组织和分配，形成结构清晰具有层次的配置图。

本章小结
统一建模语言UML是国际对象管理组织OMG批准的基于面向对象技术的标准建模语言。通常，使用UML的类图来建立对象模型，使用UML的状态图来建立动态模型，使用UML的用例图来建立功能模型。在UML中把用例图建立起来的系统模型称为用例模型。
本章主要介绍了UML的各种图的画法，结合具体的例子对UML建模中常用的用例图、活动图、交互图、类图、状态图、组件图等做了比较详细的介绍，通过对本章的学习，读者可以充分了解面向对象建模的基本方法。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com