面向对象分析与设计 课件 第5、6章 类图建模、顺序图与通信图建模

第5章类图建模学习目标

理解和掌握类图的概念，理解和掌握类图的构成元素及其表示法

理解和掌握从用例图导出结构模型的一般方法

理解和掌握类图的基本建模策略和一般建模方法

深刻理解和领会类图的意义和作用第5章类图建模面向对象分析过程中，用例建模过程的实质也是一个功能分析的过程，其直接结果是得到了目标系统的功能模型。但实际上我们可以得到的不仅仅是一个功能模型，事实上我们还可以如从这些用例以及这些用例的动作序列中找到与这个用例相关的业务逻辑、业务实体以及非功能属性等等，这些都是影响目标系统的重要因素。本节我们将主要讨论类图模型及其建模方法，同时还讨论如何从用例模型中找到相应的类（或对象），从而建立目标系统的类图模型（也称为概念模型或结构模型）。值得一提的是，在分析阶段建立的类图模型并不一定就是目标系统的最终结构模型，大多数情况下，分析阶段建立的类图模型仅仅是系统的概念模型，而到系统设计阶段还需要进一步细化为目标系统的结构模型。本章将讨论类图模型的表示和建模方法，以及如何从功能模型导出概念模型。5.1类图的构成元素类图模型的主要构成元素不外乎类和类之间的关系两大部分。其具体的构成元素包括：类、对象、继承、关联、聚合、组合和依赖等元素，还包括类型、接口、信号等模型元素。类图模型的主要用途在于描述系统的静态结构，它是软件模型中最重要的结构模型。本小节将详细介绍类图的主要构成元素和相关的基本概念。5.1.1类和对象类(class)被定义为具有相同属性和行为的全体对象构成的集合，实际上也代表了对对象的一种分类，分类的依据则是这些对象所具有的属性和方法。类所描述的并不是某个特定实体的特定行为，而仅用于描述同一类对象(一类对象)所具有的共同特征。UML中，使用带有类名、属性和操作的矩形框表示类。其中，类名是类的名字，在同一个上下文中，类名不允许重复。属性和操作分别表示类所拥有的属性和操作的集合。5.1.1类和对象UML类属性和方法的一般格式如下：[作用域][可见性]属性名[：数据类型[=缺省值]][作用域][可见性]方法名([[in/out]参数名[:数据类型],…])：参数列表中，关键字in表示输入参数，out表示输出参数。5.1.1类和对象例如，图5-1给出了一个类的图形表示实例，图中Employee是类名，Name、EmployeeID和Title是属性。GetPhoto(p:Photo)、GetPersonRecord()和GetContactInfomation()则是这个类的方法。图5-1类的图形表示5.1.1类和对象程序设计语言中，通常称不能实例化的类为抽象类，而称可以实例化的类为具体类。UML支持抽象类和具体类的描述，UML默认的类是具体类，其外观是类名用正常体表示。而抽象类的外观则是类名使用斜体的形式表示。如图5-1中的类就表示了一个抽象类。与类相关一个问题是属性和方法的可见性问题。UML中，类属性和方法的可见性被定义分为公共、私有和保护三个级别。在UML类的图形表示中，使用+、-和#分别表示公共、私有和保护这三种可见性。缺省的可见性是公共可见性。5.1.1类和对象如图5-1中，Name、EmployeeID和Title等三个属性的可见性均是私有可见性。GetPhoto()和GetContactInfo()方法的可见性则是公共的。5.1.1类和对象面向对象程序语言中，属性和方法的作用域被分为类作用域和实例作用域两种情况。类作用域是指类中不依赖类的实例而存在的属性和方法。无论是否创建类的实例，类中具有类作用域的属性和方法就已经存在并可以访问。而当创建了一个或多个类的实例时，类类作用域的属性和方法也没有因为这些实例的创建而建立多个不同的副本。与类作用域相反，实例作用域则是指类中其存在性和访问性均依赖于实例的属性和方法。UML类中，使用正常体和斜体的属性或方法名来表示具有作用域，斜体表示类作用域，正常体则表示实例作用域。UML默认的作用域是实例作用域。5.1.1类和对象与类属性和方法相关的最后一个问题是数据类型问题，UML以标准UML数据类型、程序设计语言的数据类型和自定义数据类型等三种方式支持数据类型。UML类中，属性、方法以及方法的形式参数和返回值等均可以使用这些数据类型。如图5-1中，属性EmployeeID的数据类型int就是一个标准的数据类型。而方法GetPhoto()的返回值类型（Photo）则可以看作是一个类或自定义的数据类型。5.1.2类（或对象）之间的关系严格地说，在面向对象系统中，类之间的关系主要是指类之间的泛化关系。而对象之间的关系却可以是多样的，面向对象方法将它们抽象成依赖、关联、聚合、组合等四种关系。虽然这些关系描述的是对象之间的关系，但UML却统一地使用类图来描述这些关系，并为它们定义了相应的表示法。因此，类图模型中的关系就被概括成依赖、关联、聚合、组合和泛化这五种关系。值得注意的是，在概念上严格地区分类关系与对象关系之间的联系和区别，将是从事面向对象分析与设计工作的极为重要的基本思维方式和工作基础。5.1.2类（或对象）之间的关系1．依赖关系（Dependency）对于两个对象来说，如果一个对象（或类）的属性或行为发生的某种变化将会引起另一个对象（或类）的属性或行为发生必要的改变，那么就称这两个对象（或类）之间存在某种依赖关系。UML使用类图描述对象之间的依赖关系，这种方式可以更容易地描述目标系统中对象（或类）之间存在的依赖关系。对象之间的依赖关系的实质是指系统中存在的某种耦合关系。UML使用一个带有箭头的虚线表示类之间的依赖关系。5.1.2类（或对象）之间的关系

图5-2对象之间的依赖关系图5-2给出了对象间的依赖关系的类图表示。对于类来说，依赖的确切含义是A类的某个实例访问了某个（或某些）B类实例的某些属性或方法，当B类的属性或方法发生改变时，将会引起A类发生相应的改变。5.1.2类（或对象）之间的关系2．关联关系(Association)关联(Association)关系是对象（或类）之间存在的结构性的关系，其确切的定义是：对于两个对象（或类）来说，如果在一个对象的内部可以访问另一个对象的所有属性和方法时，我们就可以称这两个对象（或类）之间存在着关联关系。如汽车和轮胎、师傅和徒弟、班级和学生之间的关系等。显然，关联关系必然是一种依赖关系。在UML中，使用一条实线连接有关联关系的对象所属的类来表示对象之间的关联关系。而在程序设计语言中，通常采用将一个类的实例或实例引用作为另一个类的成员的方式来实现对象之间的关联关系。5.1.2类（或对象）之间的关系图5-3关联的UML表示关联可以是有方向的，也可以是无方向的。因此，关联可以分成单向关联和双向关联。图5-3给出了类关联的UML表示。其中，（a）给出了双向关联，（b）给出了单向关联的UML表示。双向关联的含义是相互关联的两个对象之间是可以互相访问的，即任何两个相互关联的对象之间可以互相访问；单向关联的含义则是相互关联的两个对象之间的访问则是单向的，如5.3（b）中的A类对象可以访问与之关联的B类对象，反之则不可以。5.1.2类（或对象）之间的关系2．关联关系(Association)关联(Association)关系是对象（或类）之间存在的结构性的关系，其确切的定义是：对于两个对象（或类）来说，如果在一个对象的内部可以访问另一个对象的所有属性和方法时，我们就可以称这两个对象（或类）之间存在着关联关系。如汽车和轮胎、师傅和徒弟、班级和学生之间的关系等。显然，关联关系必然是一种依赖关系。在UML中，使用一条实线连接有关联关系的对象所属的类来表示对象之间的关联关系。而在程序设计语言中，通常采用将一个类的实例或实例引用作为另一个类的成员的方式来实现对象之间的关联关系。5.1.2类（或对象）之间的关系关联角色（Associationrole）可以看成是对参与关联的对象（或实体）在关联中所充当的角色。一般情况下，每个关联都应该含有若干个关联角色。描述关联关系时，通常需要为关联命名和关联角色命名。关联名字用于标识实体间的某种特定联系。关联角色名则表示关联对象在与其关联的对象中所承担的职责。一个关联关系通常包含两个关联角色，角色名可以使类（对象）之间的关系更加明确。5.1.2类（或对象）之间的关系关联角色的多重性表示这种关联角色在与之关联的对象中存在的数量关系。同一个关联的两个关联角色可以有不同的多重性。多重性一般可用一个数值、一个变量或一个范围值来加以表示。其中，*表示多的，其可取值不固定。常见的多重性表示包括：0、1、*、0..1、0..*和1..*等多种形式。将关联角色映射到实现域时，关联角色（包括关联角色名及其多重性）将被映射成对应的类或对象的一个属性。5.1.2类（或对象）之间的关系例如，图5-4中的关联。其中，关联的名字为employ，表示两个对象之间的聘用关系。关联两端的关联角色名分别为cop和staff，其中cop表示Corporation对象在Staffmember对象中所充当的角色名。同样，staff表示Staffmember对象在Corporation对象中所充当的角色名。图5-4关联的角色名和多重性5.1.2类（或对象）之间的关系阅读下列程序代码，会更容易地理解图5-4中各个模型元素或符号的意义。publicclassCorporation{privatestringID;privatestringName;publicStaffmemberstaff[];publicCorporation(){}publicCorporation(stringid,stringname){ID=id;Name=name;}publicAddStaffmember(Staffmemberm){staff.Add(m);}}publicclassStaffmember{privatestringID;privatestringName;publicCorporationcop;publicStaffmember(){}publicStaffmember(stringid,stringname,Corporationc){ID=id;Name=name;Cop=c;}}5.1.2类（或对象）之间的关系最后一个问题是关联关系的实例化问题，实例化具有关联关系时，不仅要实例化相关对象，还需要建立起关联对象之间的链接。假设系统中的Corporation对象为Corporation（001，“阳光股份”），其员工包括：张三、“李四”和“王二”等三个员工。此时，这组对象及其关联关系的实例化过程可以描述如下。Corporationc=newCorporation（001，“阳光股份”）;//实例化Corporation对象；Staffmembers1=newStaffmember（“01”，“张三”,c）；//实例化Staffmember对象；Staffmembers2=newStaffmember（“02”，“李四”,c）；Staffmembers3=newStaffmember（“03”，“王二”,c）；c.AddStaffmember(s1)；c.AddStaffmember(s2)；c.AddStaffmember(s3)；5.1.2类（或对象）之间的关系图5-5中的对象图给出了上述过程实例化出来的关联对象实例。

图5-5图5-4中关联的一个实例3．聚合与组合在关联关系中，聚合（Aggregation）关系描述的则是对象之间具有的一种整体和部分之间的关系。如果一个对象是另一个对象的一个组成部分，那么称两个对象之间的关系是一种聚合关系。特别地，当这两个对象具有相同的生命周期时，又称这个聚合关系为组合（Composition）关系。聚合关系可以用一个带有空心菱形框的直线表示，菱形框一端是整体对象，有时也称其为聚合，另一端是部分对象。当聚合关系也是一个组合关系时，这个表示中的菱形框就换成实心的菱形框表示。3．聚合与组合图5-6给出了表示了聚合和组合关系的UML类图表示。图5-6聚合和组合关系的类图表示需要特别指出的是，聚合关系是一种特殊的关联关系，关联关系的一切特性都适用于聚合关系。与一般的关联关系不同的是，聚合关系中，部分对象是整体对象的一个组成部分，它（或它们）承担了整体对象所承担的某个（或某些）系统责任，是整体对象所固有不可分割的一个组成部分。组合关系则强调了部分对象与整体对象之间联系的强度，强调了部分对象与整体对象在生存期方面的紧密联系。建模时，将关联关系建模成组合或聚合需要关注的是两个对象的系统责任与生存期之间的关系。3．聚合与组合在关联关系中，聚合（Aggregation）关系描述的则是对象之间具有的一种整体和部分之间的关系。如果一个对象是另一个对象的一个组成部分，那么称两个对象之间的关系是一种聚合关系。特别地，当这两个对象具有相同的生命周期时，又称这个聚合关系为组合（Composition）关系。聚合关系可以用一个带有空心菱形框的直线表示，菱形框一端是整体对象，有时也称其为聚合，另一端是部分对象。当聚合关系也是一个组合关系时，这个表示中的菱形框就换成实心的菱形框表示。3．聚合与组合例如，图5-6中，产品和零件之间就是一种整体与部分之间的关联关系，每个产品所具有的各项功能通常是由其各个零件及其相互协作承担的，二者是密不可分的。从生存期的角度来看，零件损坏时，只要跟换一个同类型的零件后，产品仍然可以继续使用。此时，产品和零件并不具备相同的生存期。因此，我们使用聚合关系描述二者之间的关系。而圆和圆心则不同，它们之间除了具有整体和部分之间的关系之外。二者的生存期也是完全相同的。圆和圆心分离的结果必然是“圆不是圆，心也不再是圆心”。故我们将其建模成组合关系。很多情况下，将对象之间的关系建模成聚合或组合关系本身并不是客观的，如何建模通常取决于设计者的主观决策，没有必要过分地纠结聚合或组合的选择。4．泛化与特化泛化关系是一种纯粹的类之间的关系。如果一个类拥有了另一个类的所有属性和方法，则称这两个类之间具有泛化关系，同其它模型元素之间的泛化关系的表示方法一样，UML也使用带有空心箭头的直线表示类之间的泛化关系。图5-7继承关系的类图表示4．泛化与特化当多个泛化关系出现在同一个上下文中时，就可能构成一个多层的层次结构。在这个结构中，称比较高层（抽象）的类为超类，比较低层（具体）的类为子类。这意味着超类通常是一种代表了一组类的公共特征的通用类，子类往往是其超类的在某个继承层次上的一个特例。我们把从子类出发设计或创建超类的过程称为泛化（Specialization），反之把由超类开始设计或创建子类的过程称为特化(Generalization)。因此，虽然泛化和特化在本质上没有太大的差别。不同的是，它们代表了不同的构建类层次结构的过程，这意味着，它们建模的目标、出发点和建模顺序均有所不同。实际的软件建模过程中，两种过程往往是混杂在一起进行的，一个良好的层次结构通常要经过一个复杂的设计过程才能获得。泛化关系是一种纯粹的类之间的关系，它并不指明这些类的实例之间存在什么样的链接关系。第6章顺序图与通讯图建模学习目标理解和掌握顺序图和通讯图概念、构成元素和表示法理解和掌握顺序图与通讯图二者之间的联系和区别理解和掌握顺序图和通讯图的建模策略和建模方法深刻理解和掌握顺序图和通讯图建模的意义和作用第6章顺序图与通讯图建模任何一个软件系统均包括静态结构和动态行为两个方面，使用类图可以建模系统的静态行为。而使用顺序图、通讯图、状态图和活动图等四种模型者可以建模系统的动态行为。UML的基本目标不仅仅在于捕获结构方面的关系，而更倾向于捕获过程和事件流。UML交互图几乎借鉴了统一建模语言中的所有其它捕捉对象之间通信表示的图，同时也极大地扩展了的描述复杂控制流的能力。第6章顺序图与通讯图建模UML将顺序图和通讯图统称为交互图，UML定义交互图来强调对象之间的链接和消息通信，而不是与该通信相关联的数据操纵。交互图关注的是对象之间传递的特定消息，以及如何将这些消息聚集在一起以实现特定的功能。交互图可以准确地描绘出哪些对象组成的复合结构可以满足并实现特定的需求。顺序图和通讯图之间存在语义等价的关系，但它们不仅在形式上不尽相同，它们在内容和表达的语义方面也不尽相同。二者一方面是两种语义等价的两种模型，同时它们也都属于状态机模型。而另一方面，二者描述问题的角度和方法也不尽相同，其用途和建模方法也不尽相同。本章将详细介绍顺序图和通讯图的构成元素、用途和建模方法。6.1顺序图的构成元素顺序图是一种由对象和对象之间的消息构成的图，其最主要的特点是其消息传递的时间顺序。是对系统中的若干个对象按照时间顺序所进行的交互所表现出来的行为的一种结构化表示。顺序图的主要作用在于描述系统为实现某个目的而进行的一个过程、完成这个过程所需要的参与者、以及为实现这个过程所需要的这些对象之间的消息传递（合作）。在面向对象方法中，顺序图可用于面向对象分析、面向对象设计和面向对象程序设计等各个阶段。在面向对象分析阶段，顺序图可用于描述用例过程，并有助于捕获系统中的信息流和系统责任。早期分析中获得的对象将被转换成系统角色，对象之间的消息最终被转换成为系统类模型中某个类的操作。而在面向对象设计阶段，顺序图可用于描述某个用例场景或某个类方法，获得的对象将被映射为系统中的对象（类），消息也将被映射为目标系统中的某个（或某些）类方法。顺序图的构成元素包括：生命线（lifeline）、控制焦点（controlfocus）、消息（message）、分支（decision）、撤销(destroy)、组合片段(combinefragement)等。下面将详细介绍这些模型元素的概念和表示方法。6.1.1对象（Object）对象是顺序图的主要构成元素，它表示参与顺序图所表示的过程的主体参与者。其表示与对象图中的表示基本相同。顺序图中可以出现各种对象，这些对象通常包括参与者、边界类、控制类、实体类和普通类等类型的对象。图6-1列出了顺序图中常见的对象。而图6-2则给出了一个包含了各种对象的顺序图的实例。图6-2顺序图的应用实例6.1.1对象（Object）图6-1顺序图中常见的对象6.1.2生命线（lifeline）生命线是从对象图标向下出来的延伸的一条直线，也是和对象紧密联系在一起的一种模型元素，用于表示对象的生存期或生存期内的某个时间片段。事实上，在顺序图中，对象和生命线是不可分割的同一个元素，生命线是对象的一个组成部分，代表了对象的整个或部分生命期。顺序图中即不存在没有生命线的对象，也不存在没有对象的生命线。当然这并不排除生命线分支的概念。6.1.3控制焦点（Focusofcontrol）如果某个对象在某个时刻或时间片段内，它处于其某个操作被正在被执行的状态，那么我们称这个对象处于激活（Active）状态。否则，处于非激活（Deactive）状态。所以，当多个对象参与同一个活动时，并不是每个对象都处于激活状态。即使这些对象之间的活动是并发的，也不太可能每个对象都处于激活状态。控制焦点也称为激活期(Activation)，指生命线上的那些小矩形，它们表示对象处于的激活状态的时间片段。当不同生命线上的控制焦点发生时间片段的重叠时，这可能会引出控制焦点之间的嵌套。图6-3中的顺序图就包含了多个控制焦点之间的嵌套关系。6.1.3控制焦点（Focusofcontrol）图6-3中的顺序图就包含了多个控制焦点之间的嵌套关系。图6-2顺序图的应用实例6.1.4消息（Message）消息是顺序图中最重要的概念，用于表示图中对象之间的通信，即一个对象向另一个对象发送的消息。在顺序图中，消息被表示成携带了某种信息的控制流。按照消息的传递方式，可以将消息分为同步消息(synchronous)和异步消息(asynchronous)两大类。同步消息是指以同步方式发送的消息，通常指对象方法的调用。发送同步消息时，发送者需要与接收者对接收到的消息处理同步，即等待接收者处理完接收到的消息并返回一个确切的消息之后，才能够进行其后续的动作。所以，同步消息必须有一个对应的返回消息，不过，返回消息可以不必显式地出现在顺序图中。对于同步消息来说，还需要存在一个与之对应的返回消息(return)。异步消息(asynchronous)是指对象以异步方式发送的消息。发送异步消息时，发送者既不等待接收者处理完这条消息也不等待接收者的返回消息，而是继续执行其后续的处理。6.1.4消息（Message）与异步消息相伴的是信号，信号可以看成是一组参数或属性构成的集合。也可以看成是以异步方式传递的消息的内容。不同的UML建模软件定义了不同的消息类型的。表6-1给出了Rationalrose建模系统中定义的各种消息，可以看出这些消息并不是对消息概念的严格划分，实际上是消息的不同属性的一种描述。这些不同的消息，适用于不同的建模场景。除了图形符号，UML还使用消息表达式的方式来描述消息。按照对象间交互的形式，可以把消息分成方法调用、发送信号、创建实例和销毁对象等多种形式。其中，最常用的形式就是对象间的方法调用。6.1.4消息（Message）描述方法调用或发送信号的消息的语法格式定义如下：[returnvalue=]message_name(arguments):type_of_return_valuereturn_value：是消息的可选部分，表示存储消息返回值的变量。这个变量可以是发送者的一个属性、整个交互的全局属性、或者是某个拥有交互的类的属性。message_name：表示消息名称，可以是接收者的某个方法名或发送的信号名等。arguments：表示消息参数列表，是一个用逗号分隔的若干个参数构成的列表，其中每个参数都可以是参数名或参数值。type_of_return_value:返回值类型。6.1.4消息（Message）消息类型主要特征符号表示简单消息(Simple)泛指的，不需要详细说明其类型的消息过程调用(procedurecall)与对象的操作对应的消息同步消息(synchronous)以同步方式发送的消息异步消息(asynchronous)以异步方式发送的消息返回消息(return)接收者收到某个消息后，向发送者返回的消息阻止消息(Balking)指接收者不能立即接收，则发送者就要放弃的消息超时消息(Timeout)接收者不能在指定的时间内接收，发送者就要放弃的消息自调用消息(Self)一个对象给自身发送的消息6.1.5条件分支和从属流顺序图中也允许使用分支，这包括条件分支和从属流两种分支。条件分支是指一个对象发送消息的守卫条件。从属流是指从某个对象的生命线上分离出来的一个或多个生命线，用来表示该对象在某个时间片段中所进行的并发活动。图6-4a和图6-4b分别给出了包含条件分支和从属流的顺序图。图6-4a中的A类对象生命线上就添加了一条从属流(生命线)，这描述了A类对象发出的两个消息op1和op2的动作是并发的两个活动。而图6-4b中的两个消息则表示了这两个消息发送条件。然而，并不是每个建模软件的顺序图都支持从属流这样的模型元素。必要时，可以绘制两张不同的顺序图来描述不同的分支。6.1.5条件分支和从属流图6-4包含条件分支和从属流的顺序图a)从属流b)条件分支6.1.6撤销(Destroy)最后再介绍一个顺序图元素，撤销（Destroy）表示在过程中销毁某个对象，也表示这个对象生命期的终止。这个元素通常仅用于顺序图中的某个临时对象。这个对象一般是在顺序图所描述的活动中动态创建起来的，并在其完成了其职责后被撤销。图6-5给出了一个描述了遗传算法的顺序图，图中给出了使用了撤销这一模型元素的例子。6.1.6撤销(Destroy)图6-5包含了撤销元素的顺序图6.1.6撤销(Destroy)图中包含了种群(population)、染色体(chromosome)、基因(Gene)和客户(Client)等四个类的实例。整个顺序图则描述了遗传算法在执行过程中，所有这些对象之间的交互情况。容易看出，图中的所有对象的水平位置并不都是相同的，不同的位置表示了这些对象加入到顺序图所描述的过程的时间的不同。客户(Client)和种群(population)是整个过程的全程参与者，其生命周期最长，它们全程参与了算法的整个过程。染色体(chromosome)对象和基因(Gene)对象则是由种群(population)对象创建的，它们都是在活动开始以后创建的，并在活动结束前就已经被撤销了。图中的创建消息和撤销元素就描述了这样的语义。另外，也容易看出，顺序图中的对象创建和对象撤销应该是成对出现的。这一点，在不同的建模工具中的实现也是不尽相同的。例如，在EnterpriseArchitect中，就严格要求创建和撤销这两个元素成对出现，这可以有效地保证模型的合理性。而RationalRose则没有这样的约束，但这也给了建模人员极大的自由度。6.1.7组合片段(CombinedFragments)为表示顺序图中对象间的交互片段之间的顺序、选择、循环等各种关系方面的约束，UML还定义了组合片段(CombinedFragments)这一模型元素，组合片段的具体定义如下。组合片段可以是一个简单的矩形区域，也可以是一个由多个片段组合而成的片段集合。有时，集合中的每个片段也可以是一个组合片段。图中的每个交互只能属于一个特定的片段，既不允许片段之间的交叉。图6-6使用了组合片段的顺序图6.1.7组合片段(CombinedFragments)事实上，顺序图中的组合片段则可以看成一个由多个交互构成的矩形区域，每个区域还可以依据某种原则分隔成若干个更小的矩形区域，这样，就可以得到整个组合区域的一个划分，此时，可以将每个小矩形区称为一个片段(fragement)。此时，组合片段显然就可以看成是一个由多个片段构成的集合。再考虑划分组合片段的原则，就可以得到组合片段的完整定义了。在顺序图中使用组合片段，可以清晰地描述顺序图中各对象之间的交互在某一方面或多个方面应具有的特性。图6-6所示的顺序图描述了顾客和收纳员等多个对象参与的结算过程，图中使用了“loop”和“alt”两种类型的组合片段的顺序图。其中，第一个组合片段是一个loop类型的组合片段，其内部仅包含了一个片段，其循环条件是”whileitemremaines”。第二个组合片段是一个alt类型的组合片段，其中包含了两个片段，其中第一个片段的条件是“cash”，表示现金支付方式。第二个片段的条件是“creditcard”，表示“信用卡支付”。这两个片段，显然是按条件选择的两个片段。对应了if<condition>then<fragement1>else<fragement1>这样的逻辑。容易理解图中片段的逻辑含义。6.1.7组合片段(CombinedFragments)UML定义了多种不同类型的组合片段，每种组合片段均表达了不同的含义。表6-2给出了EnterpriseArchitect建模工具软件中定义的组合片段类型。表6-2组合区域的分类序号名称关键字作用1分支区域alt区域内各个片段按交互算子的逻辑值划分交互片段2可选区域opt封装可选的交互片段3并发区域par区域内各片段的操作是并发操作4循环区域loop区域内各片段的操作是重复执行的5临界区域critical区域内各片段均是临界区域6无效区域neg断言一个片段是无效片段7有效区域assert标明有效片段，通常封装在consider或ignore算子中8强顺序区域strict标明片段内的交互必须按照严格的顺序进行9弱顺序区域seq标明此组合片段内部各片段之间是弱顺序的10可忽略区域ignore表示在执行期间可以忽略片段中的消息11可跟踪区域consider标明片段中消息的跟踪。和assert一起使用12引用区域ref封装对其它图的引用6.1.7组合片段(CombinedFragments)表中的12种不同类型的片段，对应12种不同的消息组合方式，明确地表达了顺序图中各个交互之间的关系，为顺序图中的各个交互提供了精确和细致描述方法。需要说明的是，并不是每个建模软件都支持组合片段模型元素，而且即使某些软件支持了这种建模元素的建模，但这种表达仍然是面向建模人员的。这也是选择建模工具时需要考虑的一个重要因素。6.2顺序图建模方法顺序图的主要作用在于建模一个过程，这个过程可以是一个用例、场景或类的某个方法。所以顺序图建模可以用于软件开发过程的需求分析、设计和系统实现各个阶段。无论使用顺序图用于描述什么或将顺序图用于软件开发的哪个阶段，顺序图的主要作用均主要体现在找出新的职责、对象（类）和方法和软件开发人员之间的交流两个方面。6.2顺序图建模方法1．找出新的职责、对象（类）和方法。顺序图中最主要的两种元素就是对象（或类）以及它们之间的消息。顺序图建模时，每向图中添加了一个新的对象（或类），就意味着有可能找到了新的对象、类或角色。每添加一条消息，就意味着可能为对应的对象（或类）添加了一个新的方法。事实上，顺序图建模不仅可以用于描述了系统的动态行为，同时也会给系统找到了新的对象、类或角色，同时也可能找到了新的方法。6.2顺序图建模方法2．软件开发人员之间的交流。顺序图直观地表示了目标系统的动态行为，这使得它更适合作为软件开发人员之间的交流的媒介，尤其是设计员与程序员之间的交流。并且这种方式的表达更易于阅读、理解、交流、评价和改进。顺序图的建模过程中，可按照如下基本步骤进行。1．明确顺序图的建模目标和范围顺序图的建模目标包括描述用例、描述一个或多个场景或建模一个方法。建模范围自然就可以是一个用例、场景，也可以是某个类的一个方法。建模目的和建模范围的不同，决定了建模的方法和粒度的不同。越高层次的过程，其粒度往往就粗略一些，涉及到的细节就少一些，层次越低的过程，其粒度就越会更细致一些。因此，建模顺序图时，首先应明确建模的目的和范围是什么。在需求阶段使用顺序图建模时，建模的目的就可能是描述需求。此时，顺序图中的对象就可能仅来自于问题域，而设计域和实现域中所需要的类或方法方面的具体细节就可以被忽略。而在设计阶段使用的顺序图，就可能需要包括大多数甚至全部对象（或类）和它们之间传递的消息，同时也应该尽可能给出这些类和消息的具体细节。6.2顺序图建模方法2．定义顺序图中可以出现的对象（或类）为顺序图找出能够实现建模目标所需要的全部对象（或类），这些对象（或类）可以是已知的对象（或类），也可以是新添加的对象（或类）。建模顺序图时，为对象指定明确的类是一个值得关注的重要问题。对未明确分类的对象进行建模，并不能为建模工作带来实质性的模型增量。对出现在顺序图中的每一个对象，还应该明确其生命期。即指明对象是临时对象还是一个全程参与的对象。全程对象的存在性及其状态构成了顺序图的前置条件。对于临时对象，这要标明这些对象的创建者、创建消息以及撤销符号。顺序图中，对象可以按任意顺序从左向右顺序排列，但排列时应注意排列顺序对图形布局的影响。一般情况下，顺序图中的对象可以按照参与者（或客户类）、边界类、控制类和实体类的顺序排列。6.2顺序图建模方法3．定义消息消息是顺序图中最重要的元素，每个消息都表示了两个对象之间的交互。对于每一个消息，需要明确消息的发送者、接收者、消息名称、消息内容、消息的类型、守卫条件和约束等多方面的建模细节。每条消息都需要明确地指定一个合适的名称，明确指定发出者和接收者，当在现有的对象中找不到合适的接收者时，就意味着发现了新的对象作为消息的接收者。对于每一条消息，当消息表示方法调用时，消息名实际上就是接收者的一个方法名。当接收者没有合适的方法处理这种消息时，一种可能是选择的接收者不合适，需要更换接收者，另一种可能是需要在选择的接收者中添加一个新的合适的方法的接收消息。消息内容是指消息的参数，也可以看成是传递消息的两个对象之间的通信协议。必要时需要为消息指明消息的形式和内容。消息可以有多种不同的类型，建模时可根据建模目标标明消息的类型。不同的建模工具支持不同的消息类型，需要明确区分的包括：消息的同步方式和异步方式；对于同步消息还要区分是过程调用消息、创建消息，还是销毁对象消息。对于返回消息还要考虑是否有可能是一个回调消息等；守卫条件指消息的发送条件，必要时需要指明消息的发送条件，UML没有强制规定发送条件的结构化描述方式，但建模人员还是应该以易于理解的方式描述这些条件。当你的建模工具支持组合片段时，还可以使用组合片段描述图中交互之间的各种关系。这有助于加强对模型的一致性的理解。6.2顺序图建模方法总之，建模时可根据建模目标和建模对象，有选择地建模这些细节。有时为提高工作效率，不必要描述所有具体细节。例如，本书表4-1中所描述的收银用例的基本事件流，就可以建模成如图6-7所示的顺序图。一个完整的用例将有多个事件流，如基本流、异常流和可选流。为一个用例的所有场景建模将得到一个全景的用例描述。从中可以获得用例在某个抽象层次上需要的所有参与者、对象以及对象之间的交互。6.2顺序图建模方法图6-7收银用例的基本事件流6.3通信图的构成元素通信图（CommunicationDiagram）用于表示一个结构事物用于表达静态结构和动态行为的概念组合，表达不同事物相互协作完成一个复杂功能。大多数情况下，通信图与顺序图表述的是相似的信息。通信图强调的是发送和接收消息的对象之间的组织结构。一个通信图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象可以是命名对象或匿名对象，也可以是其他事物的实例，例如协作、组件和结点。可使用通信图来说明系统的动态情况。通信图使描述复杂的程序逻辑或多个平行事务变得更加容易。通信图的主要构成元素包括：对象（Object）、链（Link）和消息（Message）等。其中的对象可以是边界类、控制类和实体类等类型的对象。6.3.1对象（Object）对象是通信图的主要构成元素。在通信图中，对象用一个带有对象名的矩形框来表示。每一个对象可以是命名对象，也可以是一个匿名对象。常见的对象可以是参与者、边界对象、控制对象和实体对象。图6-8列出了通信图中常见的对象。可以看出，通信图中可以出现的对象和顺序图中可以出现的对象是相同的，不同的是通信图中的对象没有生命线了。图6-8通信图中常见的对象6.3.1对象（Object）通信图中的对象也有生命期的描述问题，通信图中对象的生命期可使用一组与对象的创建和撤销有关的约束加以表示。如{new}表示对象创建，{destroy}表示撤销对象，而{transient}表示临时对象。使用时，可将这些约束放在对象名的后面。。6.3.2链接（Link）链接（Link）表示通信图中对象之间的链接关系，也是类关联的实例。表示通信图中的对象之间的链接关系，事实上也是这些对象之间可访问性的一种实现。通信图中，链接用对象之间的一条直线表示。如图6-9中就包含了三个链接，这三个链接分别表示了这些对象之间的链接，当然也表示了这些类之间应该存在的连接关系。6.3.3消息（message）通信图中的消息的含义、分类、表示方法和语法格式与顺序图中的消息基本相同。不同的是，通信图中的消息必须使用标号来表示消息的传递顺序和嵌套关系。图6-9中就包含了多个消息，这些消息的传递顺序和嵌套关系则由这些消息的类型和顺序加以描述。整张通信图就表示了Customer、CardProcessor、Cashier和CashRegister四个对象为完成某个系统任务所进行的协作。它所能带来的模型增量就可能包括：对象（或类）、链（或类关联）、消息（方法）甚至包括某些属性。6.3.3消息（message）图6-9通信图实例6.3.4通信图中的主动对象（ActiveObject）就像前面在第一章中讨论过的，可以根据其行为的自主性将对象划分成主动对象和被动对象。一般情况下，一个软件至少需要含有一个主动对象。只有一个主动对象时，主动对象的概念并不被特别关注。但当系统含有多个主动对象时，情况则完全不同了。主动对象之间的协作就具有并发性这一重要的特点了。通信图中可以包含多个主动对象，主动对象（或主动类）可以用Active属性表示，带有粗框的对象表示。一般情况下，可以考虑将能够接受并处理异步消息的对象建模为主动对象。原因是其可能启动了一个新线程并在这个线程中来处理这个消息，当然有时也可能仅仅把这个消息传递给另一个主动对象，这是这个对象本身也不一定是主动对象。例如，图6-10给出了一个主动对象建模的例子。6.3.4通信图中的主动对象（ActiveObject）图6-10带有主动对象的活动图6.3.4通信图中的主动对象（ActiveObject）图中的控制器（controller）、锅炉（boiler）、温度传感器（TemperatureSensor）和压力传感器（PressureSenser）等四个对象均为主动对象。值得注意的是，图中的消息应使用异步消息来进行描述。6.3.4通信图中的主动对象（ActiveObject）UML使用活动类建模主动对象，活动类实例化后就自己控制它自己的行为，它不能其他对象调用或激活，它可以独立运作，并定义其自己线程的行为。主动对象之间通过异步事件的方式进行通信。一个有趣的问题是，这张含有多个主动对象的通信图可以转换成顺序图吗？使用建模工具提供的转换功能，可得到图6-11所示的顺序图。由于图中的Temperature和Pressure是两个独立的主动对象，所以，它们发出的消息的时间顺序一定是不确定的。而图6-11并没有给出一个对这个问题的准确描述。在图6-11中加入带有并发片段的组合片段可以解决这个问题。另外，图6-10中的通信图中描述了锅炉和两个传感器之间的链接，而在图6-11中的顺序图中，则不能直观地看到这样的链接了。因此，在某些情况下，顺序图和通信图的建模不能单纯地依靠自动转换就可以得到完全等价的结果。6.3.4通信图中的主动对象（ActiveObject）例如，图6-12给出了一张与图6-6等价的活动图，仔细观察一下可以发现，图中不再包含那个表示重复输入的那个frag