《软件工程-理论、方法与实践》课件第3章

第3章面向对象系统建模3.1面向对象基本概念3.2统一建模语言UML3.34 + 1视图3.4软件系统模型3.5面向对象系统模型3.6软件建模工具RationalRose本章小结习题

3.1面向对象基本概念

3.1.1对象

对象(Object)是系统中用来描述客观事物的一个实体，是构成系统的一个基本单位。一个对象由一组属性和对这组属性进行操作的一组方法(服务)组成。

属性和服务是构成对象的两个基本要素。属性是用来描述对象静态特征的一个数据项。服务是用来描述对象动态特征(行为)的一个操作序列。人们在开发一个软件系统时，会在一定的范围(也称问题域)内考虑和认识与目标系统有关的实体和事物，并用系统中的对象抽象地表示这些事物。在系统中，对象只描述客观事物本质的、与系统目标有关的特征，而不考虑那些非本质的、与系统目标无关的特征。同时，对象是属性和服务的结合体，对象的属性值只能由这个对象的服务来读取和修改。3.1.2类

类(Class)是具有相同属性和服务的一组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，其内部包括属性和服务两个主要部分。

类表示了一组相似的对象，是创建对象的有效模板，用它可以产生多个对象。类所代表的是一个抽象的概念或事物，在客观世界中实际存在的是类的实例，即对象。以学校教学管理系统为例，“学生”是一个类，其属性有姓名、性别、学号等，可以定义“选课”、“成绩查询”等操作。一个具体的学生“王雷”是一个对象，也是学生类的实例。3.1.3封装

封装(Encapsulation)是把对象的属性和服务结合成一个独立的系统单位，并尽可能隐藏对象的内部细节。

封装是面向对象方法的一个重要原则，系统中把对象看成是属性和服务的结合体，使对象能够集中而完整地描述一个具体事物。封装的信息隐蔽作用反映了事物的相对独立性，如果从外部观察对象，只需要了解对象所呈现的外部行为(即做什么)，而不必关心它的内部细节(即如何做)。与封装密切相关的概念是可见性，它是指对象的属性和服务允许对象外部存取和引用的程度。

在软件领域中，封装要求对象以外的部分不能随意存取对象的内部数据(属性)，从而有效地避免了外部错误对它的影响，使软件的错误能够局部化，大大降低了查错和排错的难度。另外，当对象内部需要修改时，由于它只通过少量的服务接口对外提供服务，便大大减少了内部修改对外部的影响，即减少了修改引起的“波动效应”。封装也有副作用，如果强调严格的封装，则对象的任何属性都不允许外部直接存取，因此就要增加许多没有其他意义、只负责读或写的服务，从而给编程工作增加了负担，也增加了运行开销。为了避免这一点，往往会采取一些比较灵活的做法，即允许对象有不同程度的可见性。3.1.4继承

继承(Inheritance)是指两个类之间具有的一种关系，子类可以自动拥有父类的全部属性和服务。

继承简化了人们对现实世界的认识和描述，在定义子类时不必重复定义那些已在父类中定义过的属性和服务，只要说明它是某个父类的子类，并定义自己特有的属性和服务即可。例如：考虑轮船和客轮两个类，轮船具有吨位、时速、吃水线等属性和行使、停泊等服务，客轮具有轮船的全部属性和服务，又有自己的特殊属性(如载客量)和服务(供餐)，因此客轮是轮船的子类，轮船是客轮的父类。一个类可以是多个父类的子类，它从多个父类中继承属性与服务，称为多继承(MultipleInheritance)。例如客轮既是一种轮船又是一种客运工具，它可以继承轮船和客运工具这两个类的属性和服务。

与父类/子类等价的其他术语有一般类/特殊类、超类/子类、基类/派生类等。

继承对软件复用是十分有益的。如果将面向对象方法开发的类作为可复用的组件，那么在开发新系统时可以直接复用这个类，也可以将其作为父类通过继承实现复用，从而大大扩展了复用的范围。3.1.5消息

消息(Message)是对象发出的服务请求，一般包括提供服务的对象标识、服务标识、输入信息和应答信息等。

面向对象技术的封装机制使对象各自独立，各司其职，消息机制则为它们提供了交互途径，使对象之间能够相互协作，实现系统的目标。面向对象系统的消息通常表现为对象之间的方法调用，

例如：

//Callamethodassociatedwithabuffer

//objectthatreturnsthenextvalueinthebuffer

v=circularBuffer.Get();在基于服务(Service-Based)的系统中，消息是采用XML描述的一段文本信息。例如：

<env:Envelopexmlns:env=“/2001/06/soap-envelope”>

<env:Header>

<abc:Extension1xmlns:abc=“/stuff”

env:mustUnderstand=“1”/>

<abc:Extension2xmlns:def=“/ext”

env:mustUnderstand=“1”/>

</env:Header>

<env:Body>

…

</env:Body>3.1.6关联

关联是对象属性之间的静态关系，它通过对象的属性来表现对象之间的依赖关系。

在面向对象的术语中，对象之间的实例连接被称为链接(Link)，而存在实例连接的对象类之间的联系称为“关联”(Association)。例如，“教师”与“学生”是两个独立的类，它们之间存在“教学”关系，这种联系是通过类中的“教学课程”、“时间”、“地点”等属性建立起来的。关联存在多重性，用以描述一个关联的实例中有多少个相互连接的对象。关联的多重性是一个取值范围的表达式或者一个具体值，可以精确地表示多重性为1、0或1.(0..1)、多个(0..*)、一个或多个(1..*)，如果需要还可以标明精确的数值。3.1.7聚合和组合

聚合是一种特殊形式的关联。聚合表示类之间整体与部分的关系。在对系统进行分析与设计时，需求描述中的“包含”、“组成”、“分为……部分”等词常常意味着存在聚合关系。

组合表示的也是类之间的整体与部分的关系，但组合关系中的整体与部分具有同样的生存期。也就是说，组合是一种特殊形式的聚合。3.1.8多态性

多态性(Polymorphism)是指在父类中定义的属性或服务被子类继承后，可以具有不同的数据类型或表现出不同的行为。

在具有继承关系的一个类层次结构中，不同层次的类可以共享一个操作，但却有各自不同的实现。当一个对象接收到一个请求时，它根据其所属的类，动态地选用在该类中定义的操作。多态性机制不但为软件的结构设计提供了灵活性，还减少了信息冗余，明显提高了软件的可复用性和可扩充性。多态性的实现需要OOPL提供相应的支持，与多态性实现有关的语言功能包括：重载(Overload)、动态绑定(DynamicBinding)、类属(Generic)。

3.2统一建模语言UML

3.2.1UML的特点及组成

UML的主要特点可归纳为以下几点：

(1)统一的标准。UML已被OMG接受为标准的建模语言，越来越多的开发人员开始使用UML进行开发，越来越多的开发厂商开始支持UML。

(2)面向对象。UML是支持面向对象软件开发的建模语言。

(3)独立于过程。UML不依赖于特定的软件开发过程，这也是UML能被众多软件开发人员接受的一个原因。

(4)概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用。图3.1是UML的构成图，UML中有三类主要元素：基本构造块(BasicBuildingBlock)、语义规则(Rule)和公共机制(CommonMechanism)。图3.1UML的构成

UML主要包括三个基本构造块，即事物(Things)、关系(Relationships)和图(Diagrams)；五个方面的语义规则，即命名(Name)、范围(Scope)、可见性(Visibility)、完整性(Integrity)和可执行性(Execution)；四种公共机制，即说明(Specification)、修饰(Adornment)、通用划分(CommonDivision)和扩展机制(ExtensibilityMechanism)，其中扩展机制包括版型、标记值和约束三种类型。3.2.2UML事物

1．结构事物(Structuralthings)

结构事物是模型中的静态部分，用以呈现概念或实体表现元素，是软件建模中最常见的元素，共有以下七种：

(1)类(Class)。类是指具有相同属性、方法、关系和语义对象集合；图3.2所示为类的UML符号。图3.2类的UML符号属性定义格式如下：

[可见性]属性名[:类型][=缺省值]

操作定义格式如下：

[可见性]操作名[(参数列表)][:返回值类型]关于属性和操作的可见性一般有三种情况：

● public+：公有的(缺省值)，对于一个给定的类，任何一个带有可见性的外部类都可以使用该特征；

● protected#：受保护的，类的任何子类都可以使用该特征；

● private–：私有的，只有类本身可以使用该特征。

(2)接口(Interface)。接口是指类或组件所提供的服务

(操作)，描述了类或组件对外可见行为。图3.3为接口的两种UML符号，左边的为接口的简化表示，右边的为接口完整

表示，定义了一个接口(类)ActionListener，它具有两个方法actionPerformed()和test()。图3.4展示了两种符号的使用情况，且表明接口MouseMotionListener由类EventHandler来实现。图中的虚线空心箭头表示两者之间的实现关系。图3.3接口的UML符号图3.4接口两种符号的使用

(3)协作(Collaboration)。协作定义了事物间的交互操作。在前面的讨论中，我们知道面向对象的系统是由类的协作来完成相应的行为，在UML中，协作可以用来描述这些类的协作，包括和其他事物及元素的协作。UML中协作用虚线构成的椭圆表示，见图3.5。图3.5部分结构事物符号

(4)用例(UseCase)。用例定义了一个系统或系统的部分行为，是对一组动作序列的描述，为参与者产生一个可观察的执行结果，如报表打印用例。用例的UML符号见图3.5。

(5)活动类(ActiveClass)。活动类的对象有一个或多个进程或线程。活动类和类很相像，只是其对象所代表的元素的行为和其他元素是同时存在的。在UML中活动类的表示法和类相同，只是边框用粗线条。

(6)组件(Component)。组件是物理的、可替换的部分，包含接口集合，例如COM、JavaBEANS等。组件的UML符号见图3.5。

(7)节点(Node)。节点是系统在运行时存在的物理元素，代表一个可计算资源，通常占用一些内存，具有处理能力，如一个Web服务器。节点的UML符号见图3.5。

2．行为事物(Behavioralthings)

行为事物是指UML模型中动态部分，代表语句里的“动词”，表示模型中随着时空不断变化的部分，包括两类：

(1)交互(Ineraction)：交互是一组对象在特定上下文中，为达到特定目的而进行的一系列消息交换，如一个方法调用Move()。交互的UML符号见图3.6。

(2)状态机(StateMachine)：状态机由一系列对象状态组成。状态机的UML符号见图3.6。图3.6行为事物

3．分组事物(Groupingthings)

分组事物用于对模型进行分解描述。目前只有一种分组事物，即包(package)。结构事物、行为事物甚至分组事物都有可能被放在一个包中，以利于模型的简化和理解。在系统模型中，包常被用于表示子系统和描述软件体系结构，如通信控制子系统包。包纯粹是一种逻辑概念，只存在于开发阶段，而组件是物理概念，在系统运行时也存在。分组事物的UML符号见图3.7。图3.7分组事物

4．注释事物(Annotationalthings)

注释事物是UML模型解释部分。注释事物的UML符号如图3.8所示。图3.8注释事物3.2.3UML关系

UML的关系用于对事物之间的关系建模，关系分为四种类型：关联(Association)、泛化(Generalization)、依赖(Dependency)和实现(Realization)，其模型符号表示如图3.9所示，其中聚合是一种特殊的关联。图3.9UML的关系依赖是一种使用关系，它说明一个事物的变化会影响另一个使用它的事物，依赖关系不只是限于类之间。图3.9中支付类payment依赖于订单类order。类的依赖可能由如下几种原因引起：

●一个类向另一个类发送消息。

●一个类是另一个类的数据成员。

●一个类是另一个类的某个操作参数。3.2.4UML图

UML图由事物及事物间的关系构成，共有九类图，可用于不同过程阶段、不同角度的系统建模和过程建模。这九类图分别是用例图、类图、包图、组件图、部署图(实施图)、状态图、顺序图、协作图和活动图。

1．用例图

用例图是从系统参与者(actor)的角度所理解的系统功能以及参与者与用例(Usecase)间的交互。用例图用于定义阶段的需求建模。在UML中，用例模型由若干个用例图来描述，用例图的主要元素是用例和参与者及它们之间的关系，如图3.10所示。图3.10用例图

(1)用例。从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。在UML中，用例被定义成系统执行的一系列动作，动作执行的结果能被参与者感受到。概括地说，用例有以下特点：

●用例捕获某些用户可见的需求，实现一个具体的用户目标，如注册用例Register。

●用例由参与者激活，并提供确切的值给参与者，如参与者Student提供注册请求激活用例Register，并将注册结果返回给参与者Student。

●用例可大可小，但必须是对一个具体的用户目标实现的完整描述。

(2)参与者。参与者是指用户在系统中所扮演的角色。参与者在用例图中是用类似人的图形来表示，但参与者未必是人。例如，参与者也可以是一个外部系统，该外部系统可能需要从当前系统中获取信息，与当前系统进行交互。

(3)用例之间的关系。用例之间有扩展、使用、组合三种关系，扩展和使用是继承关系的另一种体现形式。组合则是把相关的用例打成包，当作一个整体看待。

图3.11为自动售货机系统的用例图。图3.11自动售货系统的用例图

2．类图

类图通常包含以下四项内容：类、接口、关系和协作。类图可以包含注释的约束，如图3.12所示，其中类的关系如下：

(1) BankCustomer和ATM类间为关联关系。

(2) BankCustomer和Account是组合关系，它们具有同样的生命周期。

(3) Acount对象中包含0或多个Transaction对象。

(4) CurrentAccount和SavingsAccount类继承Account类。图3.12ATM类图

3．包图

构成包的模型元素称为包的内容，包的内容可以是一个类图也可以是另一个包图。包与包之间不能共用一个相同的模型元素。例如在图3.13中，“系统内部”包由“保险单”包和“客户”包组成，我们把“保险单”包和“客户”包称为“系统内部”包的内容。图3.13包图

包与包之间允许建立依赖、泛化等关系。例如，在图3.13中“保险单填写界面”包依赖于“保险单”包，整个“系统内部”包依赖于“数据库界面”包。可以使用继承关系中“一般”和“特殊”的概念来说明通用包和专用包之间的关系。例如，“Oracle界面”包和“Sybase界面”包继承“数据库界面”包。在图3.13中，通过“数据库界面”包，“系统内部”包既可以使用Oracle的界面也可以使用Sybase的界面。这是因为和类的继承关系类似，专用包必须与通用包的界面一致。通用包可标记为{abstract}，表示该包只是定义了一个界面，具体实现由专用包完成。

4．组件图

可执行组件是一个可执行的程序文件，是链接所有二进制组件所得到的结果。一个可执行组件代表在处理器上运行的可执行单元。

在UML中，组件的图示符号是左边带有一个椭圆和两个小长条形的大长方形。组件间的依赖关系用一条带箭头的虚线表示。图3.14是组件图的例子。图3.14组件图

5．部署图

(1)节点和连接。节点(node)是存在于运行时的代表计算资源的物理元素，节点一般都具有一些内存，而且常常具有处理能力。

节点可以代表一个物理设备以及运行在其上的软件系统，例如，一台UNIX主机、一个PC终端、一台打印机、一台通信设备等。在图3.15中，“客户端PC”和“保险后台服务器”就是两个节点。在UML中，节点用一个立方体来表示。图3.15部署图

(2)组件和接口。在部署图中，组件代表可执行的物理代码模块(可执行组件的实例)，在逻辑上它可以与类图中的包或类对应。因此，部署图描述的是运行时各个包或类在节点的分布情况。如图3.15所示，“保险后台服务器”节点中包含“保险系统”、“保险对象数据库”和“保险系统配置”三个组件。

在面向对象方法中，并不是类和组件等元素的所有属性和操作都对外可见，它们对外提供的可见操作和属性称为接口。接口用一端是小圆圈的直线来表示。在图3.15中，“保险系统”组件提供了一个名字叫“配置”的接口。部署图中还显示了组件之间的依赖关系：“保险系统配置”组件通过这个接口依赖于“保险系统”组件。

(3)对象。在一个面向对象的软件系统中运行着许多对象。由于可以把组件看作是与包或类对应的物理代码模块，因此，组件中应该包含一些运行的对象。部署图中的对象与对象图中的对象表示方法相同。在图3.15中，“保险系统配置”组件包含“配置保险策略”和“配置用户”两个对象。

6．状态图

状态图中定义的状态有以下几种：

●初态；状态图的起始点，一个状态图只能有一个初态。

●终态：是状态图的终点，一个状态图可以有多个终态。

●中间状态：可包括三个区域：名字域、状态变量与活动域。

●复合状态：可以进一步细化的状态称作复合状态。

活动则列出了在该状态时要执行的事件和动作，即响应事件的内部动作或活动的列表，定义为：

事件名(参数表[条件])/动作表达式通常有三个标准事件：

entry事件：用于指明进入该状态时的特定动作。

exit事件：用于指明退出该状态时的特定动作。

do事件：用于指明在该状态中时执行的动作。

图3.16描述了login状态。一个对象的状态变迁称为状态迁移。通常是由事件触发的，事件是激发状态迁移的条件或操作。在状态图中，一般应标出触发转移的事件表达式。如果转移上未标明事件，则表示在源状态的内部活动执行完毕后自动触发转移。

图3.17描述了电梯升降的状态图。电梯升降有5个状态，状态之间的箭头表示迁移和引起状态迁移的事件。图3.16login状态

图3.17电梯状态图

7．顺序图

顺序图描述了一组交互对象间的交互方式，它表示完成某项行为的对象和这些对象之间交互(传递消息)的时间顺序。顺序图由对象、生命线、控制焦点、消息等组成，如图3.18所示，其中对象生命线是一条垂直的虚线，表示对象存在的时间。控制焦点是一个细长的矩形，表示对象执行一个操作所经历的时间段；消息是对象之间的一条水平箭头线，表示对象之间的通信。图3.18打电话的顺序图

8．协作图

协作图用于描述相互协作的对象间的交互关系和链接(Link)关系，链接是关联的实例。虽然顺序图和协作图都描述对象间的交互关系，但它们的侧重点不同：顺序图着重表现交互的时间顺序，协作图则着重表现交互对象的静态链接关系。

图3.19是一个打印文件的协作图，图中有三个对象：“Computer”、“PrinterServer”和“Printer”。图3.19打印文件的协作图协作图和顺序图的区别在于，协作图呈现真正的对象及其链接，在许多情况下有利于理解对象的交互；而顺序图更易帮助理解对象的交互在时间顺序上的关系。建模对象协作的一般原则是：当需要关注对象之间的交互时，选择协作图，如果只需了解对象交互的时间顺序则选择顺序图。

9．活动图

图3.20是一个打印操作的活动图，当调用PrintAllCustomer操作(在CustomerWindow类中)时动作开始。第一个活动是在屏幕上显示一个打印消息；第二个动作是创建一个PS(postscript)文件；第三个动作是把所创建的PS文件发送给打印机；第四个动作是从屏幕上删除消息。图3.20打印操作的活动图

3.34 + 1视图

Kruchten提出了基于UML的“4 + 1”视图模型，从5个不同的视角——用例视图(Usecaseview)、设计视图(Designview)、进程视图(Processview)、实现视图(Implementationview)、分布视图(Deploymentview)来描述软件体系结构。每一种视图从一个角度聚焦系统的一个侧面，从而使不同的人员关注系统的不同方面。4 + 1视图则可反映出系统的全部内容，如图3.21所示。图3.214 + 1视图

(1)用例视图采用用例模型描述系统应该具有的功能集，即系统应提供给最终用户的服务。

(2)设计视图描述系统的设计模型，用来揭示系统的结构及系统构件的协作情况。

(3)进程视图侧重于系统的运行特性，主要关注一些非功能性的需求，如系统的性能、并发特性、分布特性、容错能力等。

(4)实现视图由一些独立的组件和文件组成，常采用组件图描述实现模块及其之间的依赖关系。

(5)分布视图主要采用部署图来描述系统的物理架构，将系统的硬件拓扑结构呈现给开发人员、集成人员和测试人员。

3.4软件系统模型

通常一个软件系统的开发过程，需要一系列的模型来描述问题和整个系统，这种描述较之自然语言的描述更易于理解。在分析过程中，模型的作用一方面可以增进对现存系统的理解，另一方面有助于对新系统的说明。在设计过程中，模型呈现了系统的解决方案。一般来说系统模型通常包括以下几种：

(1)系统的上、下文模型。对系统的上下文和外部环境建模，如用例图。

(2)体系结构模型。反映构成系统的部件及其它们之间的关系，如包图。

(3)数据处理模型。说明数据在系统中是如何被处理的，如数据流图。

(4)组成模型。说明系统元素间的构成关系，如实体-关系图、类图。

(5)分类模型。描述系统元素的分类关系，如对象类/继承关系图说明实体间怎样具有共同特性。

(6)激励-响应模型。描述系统对事件的响应，如状态转换图说明系统对来自内部和外部事件的响应，描述由此而发生的状态变化。3.4.1上下文(Context)模型

系统边界一旦确定，接下来的分析活动就是定义系统上下文和系统与环境之间的依赖关系。图3.22说明了一个ATM系统的上下文模型，描述了ATM系统和银行其他系统的边界关系。图3.22ATM系统的上下文从图3.22可以看出，自动柜员机与账户数据库、支行账户系统、信息安全系统、使用数据库和一支行柜台系统之间存在连接与交互，使用数据库是用以监控ATM的使用情况，而柜台系统则提供备份和打印服务。所有这些子系统都独立于ATM机系统本身，因此该模型很好地呈现了ATM系统及其上下文环境。3.4.2体系结构(Architectural)模型

一般地说，体系结构清楚地表达了系统的构成组件以及它们之间的作用关系和语义。这些组件又可以用来构成更大、更复杂的组件或系统。在理想情况下，体系结构描述的各个组成部分都是独立定义的，可以在不同的场合中得到重用。

在UML模型中，体系结构可以用包图来描述。图3.23描述了现代编译器的体系结构，包代表了子系统/组件。其中语法分析树和符号表是整个系统的共享数据，编译器的各个部件生成、更新、访问语法分析树和符号表、调试器和编辑器也会访问符号表。图3.23编译器体系结构3.4.3数据流模型

数据流模型用来描述数据是怎样一步步在处理序列中流动的。数据在一个处理阶段被转换，然后进入下一个阶段，当数据流图用于软件设计时，这种处理或者转换在最终生成的程序中将是一个个程序功能模块。

在图3.24使用的符号中，圆边矩形代表每个处理步骤，箭头表示数据的流动方向，平行线代表数据存储，矩形代表外部交互方。图3.24仓库管理的数据流图

数据流模型是从功能角度来看待系统而得到的模型表示，对数据的每一个变换用一个处理过程来描述。它不仅可以用来描述系统内的处理过程，有时还能有效地描述系统的上下文。数据流模型可以描述不同系统间以及子系统之间交换信息的过程。这些子系统不一定是一个单一的功能模块，例如，某一个子系统可能是一个存储服务器，并具有相当复杂的存储管理功能。3.4.4数据模型

UML没有为此模型引进专门的描述符号，这是因为UML是面向对象的，开发过程和模型数据用对象和对象间的关系来表达。这里将实体视为一个简单的没有操作的对象类，这样可以用UML类模型以及在类之间建立名字关联的方法表示出数据模型。

数据模型常常和数据流模型一起用来描述系统的信息结构，图3.25示意了某校教学管理的数据模型。图3.25某校教学管理的语义数据模型简单地说，数据字典就是系统模型中出现的所有名字的列表，除名字以外还包括对有关命名实体的描述，以及其他的一些相关信息，如创建日期、创建者和实体的表示。如果名字代表一个复合对象，就会有对其组成的描述。

数据字典的实例如表3.1所示，其中的名字来自于图3.25中设计的语义数据模型。为简化表示，删去了一部分名字，简化了一些关联的描述。一个较完备的数据字典入口应当含有数据源，例如一个类型声明，也要给出数据的使用者。

3.5面向对象系统模型

对象类是对具有相同属性、操作的一组对象的抽象。对象具有对象类中描述的属性和服务，是一个可执行的实体。对象是对象类的实例，一个对象类可以有无数的实例。通常系统分析阶段只关注对象类及对象类间的关系。而在面向对象系统中，一般需要对对象类间的静态结构和动态行为进行建模，而类的继承和聚合模型呈现了类之间的重要结构关系，顺序图则是类之间交互行为的重要模型。3.5.1对象结构模型

1．类继承

UML的泛化关系可以用来对类的继承关系建模，一个从子类指向父类的的空心箭头，意味着父类是子类的泛化。图3.26是ATM系统模型中类继承关系的一个简单描述，对于银行账户类型进行分析，可以将这些账户类型建模为一个继承关系，其中CurrentAccount和SavingsAccount类从Account类继承而来。图3.26继承

对类层次进行分析并非易事，分析人员需要对所要分析的领域有充分的了解。

在图3.26中，每一个对象都只从一个父类中继承属性及操作，但多重继承的情况也存在。一个对象类可以同时从多个类继承属性和操作，这样它的属性和操作就是所有父类的属性和操作的和。

2．对象聚合

对象聚合和组合是除了类继承关系外的一种重要的结构关系，对象聚合是指一个对象类由其他一组对象组合而成。聚合模型用来建模对象类间的这种组合关系，UML中的聚合关系符号是尾端为一菱形的线段。图3.27是一个ATM相关类的聚合模型，图中ATM类由卡扫描设备类CardScanner、现金出口类CashDispenser和显示屏类DisplayScreen组成。图3.27聚合

3．类模型

类是面向对象系统的基本构成元素，类模型用于建模系统中这些类的构造关系。采用类模型可以描述一个系统或子系统由那些类构成，而类之间的继承、聚合、依赖等关系如何，类模型展示了系统中类之间的静态协作结构。图3.28是采用UML类图来描述的ATM部分类之间的结构关系。图3.28ATM系统局类图3.5.2对象行为模型

顺序图是建模为完成某项行为、对象间按时间展开的交互协作过程，在面向对象的相关概念中，被认为是对场景的描述，也是对事件流的描述。因此常用于描述一个用例行为的实现，如图3.29即采用顺序图，完成了一个在线下载行为的实现。对象间的交互操作由带标签的箭头来指示，顺序由上至下。首先，图书馆用户访问目录，查看是否有需要的项目，如果有，发出对该项目的许可证License申请请求，如果获取到下载许可证，则下载请求将送给提供下载服务的网络服务器对象，网络服务器压缩下载内容后发送给该用户。图3.29电子科目的发放

3.6软件建模工具RationalRose

RationalRose是Rational公司出品的基于UML的功能强大的可视化建模工具，是分析、设计面向对象系统的工具。可以运行RationalRose的系统平台包括了目前大多数的主流操作系统，如Windows9x、Windows2000/XP、Solaris、AIX和HP-UX等。利用Rose可以在不同的开发阶段，从不同的角度为软件系统的开发建立模型。

采用Rose模型进行系统构建的过程如图3.30所示。图3.30基于Rose面向对象系统实现过程

RationalRose可以根据模型产生框架代码，它可以与多种开发环境无缝集成并支持多种开发语言，其中包括：VisualBasic、Java、PowerBuilder、C++、ADA、SmallTalk、XMLDTD等，因此，RationalRose是整个项目开发的有效工具。当模型发生改变时，代码也会相应改变。同时，Rose也具有逆向工程功能，当在Rose中修改代码时，相应的对象模型也会发生改变。

RationalRose不仅拥有强大的功能，而且具有方便友好的用户界面，如图3.31。它可以帮助软件开发人员高效地进行软件开发。图3.31Rose的用户界面

Rose的用户界面包括以下几个部分：

(1)菜单条包含了所有的Rose命令和操作。

(2)标准工具栏用于快速访问Rose中的常用命令和操作。

(3)浏览窗口采用树状层次结构，用于在Rose模型中进行浏览。通过浏览窗口可以快速地访问Rose模型中的各个模型元素。

(4)文档窗口用于为模型元素建立说明文档。

(5)框图工具栏用于在模型图中添加各种模型元素，其内容因打开的UML模型图的类型不同而不同。

(6)框图窗口用于显示和编辑Rose模型中的各种UML模型图。当增删框图窗口中的模型元素时，Rose会自动更新浏览窗口中的内容；同样，当修改浏览窗口中的模型元素时，相应地，修改也会自动反映在框图窗口中。

Rose模型文件的扩展名是 .mdl，要创建模型，可以执行下列步骤。

从菜单栏选择【File】→【New】，或者单击标准工具栏中的【New】按钮，弹出新建对话框，选择要用的模板，单击【OK】按钮。如果不使用模板，单击【Cancel】按钮。

如果选择使用模板，Rose会自动装入此模板的默认包、类和组件。模板提供了每个包中的类和接口，并有相应的属性和操作。通过创建模板，可以收集类和组件，便于作为基础设计和建立多个系统。如果单击【Cancel】按钮，表示创建一个空项目，用户要