第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。

如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

为完成这一转换过程，设计人员必须处理以下任务：（1）针对分析模型中的用例，设计实现方案。

实现方案用UML交互图表示。

（2）设计技术支撑设施。

在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。

这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。

例如，数据的持久存储服务、安全控制服务和远程访问服务等。

在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。

（3）设计用户界面。

（4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。

此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。

面向对象的软件设计过程如图8-1-1所示。

图8-1-1 面向对象的软件设计过程第一节设计用例实现方案UML 的交互图（顺序图、协作图）适于用例实现方案的表示。

因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。

该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。

一、顺序图顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。

在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。

顺序图中的对象一般以“对象名：类名”的方式标识，但也可以仅采用缩写形式“对象名”或者“：类名”。

对象的下方用垂直虚线表示对象的生命线，即对象在某段时间内存在。

对象生命的终结用生命线下方的叉号“′”表示。

附着在对象生命线上的矩形框表示对象在此段时间内活跃。

对象间的通信表现为对象的生命线之间的消息传递。

在消息边上需附加消息名和消息参数，有时也以顺序号强调消息的时序。

消息的源对象和目标对象可以相同，这种消息称为自调用（self-call）。

可以在消息名前面的方括号中书写条件表达式，表明仅当条件成立时，该消息才发送。

还可以在方括号的前面或者直接在消息名的前面加上迭代标记“*”，以表示一条消息对同一类的多个对象的多次发送。

顺序图的左边可带有描述信息，以阐明消息发送的时刻、动作执行情况、两条消息之间的时间间隔以及约束信息等。

还可以在消息边上附加文字注解信息，以增强顺序图的可理解性。

典型的顺序图如图8-1-2所示。

UML的消息有如下4种类型：（1）简单消息（simple message）。

以一种简单、抽象的函数表示对象之间的信息传递，不考虑通信过程的内部细节。

简单消息在UML顺序图中用普通的有向箭头表示。

（2）同步消息（synchronus message）。

消息源发出消息后，必须等待消息处理过程完毕并返回处理结果，才可继续执行后续操作。

前面所述的自调用消息应该是同步的。

同步消息的表示图元与简单消息相同，这表明UML在缺省状态下认为简单消息即为同步消息。

（3）异步消息（synchonous message）。

消息源发出消息后，不必等待消息处理过程的返回，即可继续执行自己的后续操作。

异步消息主要用于描述实时系统中的并发行为。

异步消息在UML顺序图中用一种特别的单向箭头表示，见图8-1-2中的“msg1”。

图8-1-2 典型的顺序图（4）返回消息（return message）。

表示前面发送的消息的处理过程完成后的返回结果。

返回消息应该是同步。

在许多情况下，可以隐藏返回消息，但也可显式地标出返回消息以示强调。

返回消息用虚线有向箭头表示，见图8-1-2中的“msg6”。

一个对象可以通过发送标准消息“new”来创建另一个对象。

当一个对象被删除或自我删除时，该对象生命线上的相应时间点应该用叉号（对象生命线终结符）标识。

二、协作图协作图用于描述相互合作的对象间的交互关系和链接关系。

虽然顺序图和协作图都用来描述对象间的交互关系，但它们的侧重点不同。

顺序图强调消息交互的时间序列，而协作图则强调交互对象间的静态链接关系。

从外观看，协作图并不采用单独的维度来表示时间的推移，因此，协作图中的对象可以在二维平面中自由占位。

对象之间的链接用于表示消息传递的通道，消息标示于链接之上，消息的箭头指明消息的传递方向。

协作图中，消息的描述内容包含名称、参数、返回值以及序列号是可选的。

虽然协作图不突出强调消息传递的时间序，但借助于序列号同样可以表达时间序：序列号较大的消息发生于较晚的时刻。

消息序列号可以采用线性编号，但采用适当的多级编号会使消息之间的结构关系更清晰，例如，在图8-1-3中，“1.1msg2 ”是“对象1”为了处理“1.mag1 ”而发送的第二条消息，“1.1.1msg3”表明mag3“是对象2”为了处理“1.1 msg2”而发送的第一条消息，依此类推。

如果一个对象在消息的交互过程中创建，则可在对象名称之后标以｛new｝。

类似地，如果一具对象在交互期间被删除，则可在对象名称之后标以｛destroy｝。

典型的协作图如图8-1-3所示，该协作图与图8-1-2等价。

图8-1-3 典型的协作图三、提取边界类、实体类和控制类边界类用于描述目标软件系统与外部环境之间的交互，并负责实现如下功能：（1）界面控制。

包括输入数据的格式及内容转换、输出结果的呈现以及软件运行过程中界面的变化与切换等。

（2）外部接口。

实现目标软件系统与外部系统或外部设备之间的信息交流和互操作。

主要关注跨越目标软件系统边界的通信协议。

（3）环境隔离。

将目标软件系统与操作系统、数据库管理系统、应用服务器中间等环境软件进行交互的功能与特性封装于边界类之中，使目标软件系统的其余部分尽可能的独立于环境软件。

在UML 类图中，边界类往往附加UML 构造型<<boundary>>作为特别标识。

例如，“家庭保安系统”中的边界类有“输入键盘接口类”、“传感器接口类”、“警报器接口类”、“报警电话接口类”和“显示面板接口类”。

实体在表示目标软件系统中具有持久意义的信息项及其操作。

实体类的操作具有“内向收敛”特征，它们仅向目标软件系统的其余部分提供读／写信息项内容的必要的操作接口，并不涉及业务逻辑处理。

实体类的UML构造型为<<entity>>。

例如，“家庭保安系统”中的“异常事件”即为实体类。

控制类作为完成用例任务的责任承担者，协调、控制其他类共同完成用例规定的功能或行为。

对于比较复杂的用例，控制类通常并不处理具体的任务细节，但是它应知道如何分解任务，如何将子任务分派给适当的辅助类，以及如何在辅助类之间进行消息传递和协调。

控制类的UML构造型为<<control>>。

例如，“家庭保安系统”中的“用户命令处理器”和“监测器”均为控制类。

在讨论了边界类、实体类和控制类和基本概念之后，下面介绍如何从分析模型中的用例描述和领域概念模型出发获取这些类。

通常情况下，执行者与用例之间的一种通信连接对应一个边界类。

但是，如果两个以上的用例与同一执行者交互，并且这些交互具有共同的行为、完成相同或类似的任务，就可以考虑用同一边界类实现用例与执行者之间的交互。

这就意味着边界类的作用范围可以超越单个用例。

实体类主要来源于领域概念模型。

有时也需要认真研读用例描述，从中发掘具有持久意义的信息项。

如果执行者的属性需要持久保存，也可以建立相应于执行者的实体类。

假设一个实体类A仅仅被系统中的另一个类B 引用，并且系统无需关心类A有行为特征，那么为了简化设计模型，应将类A中的信息项直接作为类B的属性。

反之，如果类A被系统中的多个类引用，或者类A具有不容忽略的行为特征，那么应将类A作为独立的实体类。

一般而言，一个用例通常对应一个控制类。

如果不同用例的任务较多类似之处，也可以考虑在多个用例的实现方案中共享一个控制类。

不过，此种情况应审慎对待，因为对于不同的且例，其事件流的逻辑结构鲜有雷同，它们所需要的控制、协调行为往往会有差异。

此外，对于那些事件流非常简单的用例，可以不设独立的控制类，直接在边界类中设置控制、协调功能，边界类在实体类的帮助下完成用例要求的功能及行为。

四、构造交互图在标识边界类、实体类和控制类之后，接下来的任务是将分析模型中的用例描述转化成UML交互图，以交互图作为用例的精确实现方案。

如前所述，用例描述中已包含事件流说明。

事件流中的事件应直接对应于交互图中的消息，而事件间的先后关系体现为交互图中的时序，对消息的响应则构成消息接收者的职责。

这种职责在后续的设计活动中将被确立为类的方法。

对于比较复杂的用例而言，仅仅依靠控制类、边界类和实体并不能很好地解决问题，因为我们不能使单个控制类过于宏大和复杂，让它既承担控制、协调的任务，又承担复杂的计算任务。

因此，在设计复杂用例的实施方案时，应考虑为控制类设置一些独立的辅助类，让控制类将一些任务委托给辅助类完成。

例如，在图5-3-4所示的“家庭保安系统”类图中，“系统配置管理器”和“日志管理器”就是这种意义上的辅助类。

在UM顺序图中，用例的主动执行者应位于最左侧，紧邻其右的类的作为用户界面的边界类，再往右是控制类。

控制类的右侧应旋转辅助类和实体类，它们的右侧是人秋外部接口和环境隔离层的边界类，最右侧是痊于目标软件系统边界之外的被动执行者。

如此布局之后，在顺序图中不应该出现穿越控制类生命线的消息，即主动执行者向边界类发出命令，边界类将命令进行适当转换后传送至控制类，控制类通过消息请求辅助类、实体类的帮助，协调、控制它们共同完成来自主动执行者的命令。

在此过程中，控制类或辅助害可以向右侧的边界类发送消息，将信息或外部处理请求由边界类传向外部系统（被动执行者）。

按照上述而已规则绘制的典型的顺序图如图8-1-4所示。

图8-1-4 典型布局规则下的顺序图在用例描述中，许多用例除主事件流外，往往还包含备选事件流，以说明在某些特殊或异常情况下的事件和响应动作序列。

为易于理解，在设计模型中应该用分离的UML交互图分别表示事件流和每个备选事件流。

由于顺序图能够非常直观地表达事件（消息）的时序，所以它比协作图更多地用于描述用例的实现方案。

但是，当需要强调类之间的联系或连接时，就需要绘制协作图。

协作图的而已规则是：控制类位于中心，主动执行者和作为用户界面的边界类位于左上方，作为外部接口和环境隔离层的边界类位于右上方，辅助类和实体类分别位于控制类的左下方和右下方。