第10章05(面向对象设计)

用UML建模当我们利用UML建造系统时，在系统开发的不同阶段有不同的模型，并且这些模型的目的是不同的。在分析阶段，模型的目的是捕获系统的需求，并建立基本的“真实世界”的类和协作的模型。在设计阶段，模型的目的是在考虑了实现环境的情况下，将分析模型扩展为运转的技术方案。在实现阶段，模型是那些编制并编译的实际源代码。最后，在部署阶段，模型解释了系统是如何在物理结构中部署的。在各个不同模型和系统开发的不同阶段之间，是通过那些明确定义的关系和特性来保持相互联系的。尽管各个阶段的模型不同，但是，通常它们都是通过对早期模型的内容进行扩展而建立的。正因为如此，所有的模型都应该保存，这样就可以容易地回顾、重做或扩展初始的分析模型，并且接着在设计阶段的模型和实现阶段的模型中逐渐引入所做的改变，如下图1所示。图1用几个不同模型描述的系统用UML建模UML是独立于系统开发阶段的，这意味着同一种通用语言和同一个UML图可以用在不同开发阶段，为不同事情建模。这取决于建模人员的决定：模型应该覆盖的目的和范围。UML这种建模语言只是为用户提供利用一种富有表现力的和连贯一致的方式创建模型的能力。当我们利用UML建立模型时，该任务应该通过一种方法或一个过程来进行管理，后者概要说明了将要采取的不同步骤，以及如何实现这些步骤。一般来说，这样的过程将任务划分为需求分析阶段/分析阶段/设计阶段/实现阶段/部署阶段的连续的迭代步骤。用UML建模最后，模型被实现为某种原型，用于评估实际方案中的所有不足之处。这些不足包括功能遗漏、性能低劣或开发费用太高。如果出现这些不足，开发人员应该返回到相应的步骤，以消除它们。如果问题比较严重，那么开发人员可能不得不返回到最初的集体讨论和草案拟定阶段，重新开始上述过程。如果问题比较小，那么开发人员或许只需要改变部分组织结构或模型的规格说明就可以了。这里，应注意，在完成了一个UML图的绘制之后，并不能立即着手进行建立原型这一步工作，而是应该在多个UML图可以一起建立原型时才能够开始进行这项工作。这种原型可以是临时利用的东西，用完就可丢弃，它仅仅是为了评估才建立的；如果建立原型这一步是成功的，那么它就成为系统实际开发过程中的一个迭代过程。第十章面向对象的设计方法本章采用基于UML的面向对象设计方法将分析模型转换为设计模型。如第六章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成。设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。为完成分析模型到设计模型的转换过程，设计人员必须处理以下任务：（1）针对分析模型中的用例，设计实现方案。实现方案用UML交互图表示。（2）设计技术支撑设施。在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。例如，数据的持久存储服务、安全控制服务和远程访问服务等。在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。（3）设计用户界面。（4）针对分析模型中的领域概念模型以及第(2)(3)两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整的标示类之间的关系。此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。面向对象的软件设计过程如图10.1所示。设计师10.1设计用例实现方案用例是系统的功能描述，它并不关心这些功能是如何实现的。这就意味着这些用例将在系统中被实现，也就是将那些职责（负责完成用例描述中所描述的动作）分配给系统中的多个对象（相互合作，负责实现描述的功能）。实现一个用例的任务就是将该用例描述中那些不同步骤和动作（在用例描述文本中或活动图中描述的内容）转换为各个类、类的操作以及这些类之间的关系。它是这样描述的：将该用例中的每一步职责分配给参与此协作（实现了该用例）的所有类。用例描述中的每一步都被转换为多个类（这些类参与了实现该用例的协作）的操作。也就是说，用例中描述的一步动作将被转换为这些类的多个操作。这时，用例中的动作和对象（指那些参加协作的类的对象）交互中的一个操作之间，不太可能是一对一的关系。同时也要注意：一个类可以参与多个用例，所以类的全部职责是它在所有用例中扮演的所有角色的集合。10.1设计用例实现方案UML的交互图（顺序图、协作图）适于用例实现方案的表示。因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。10.1.1顺序图功能：顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传送的时间顺序。在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。对象标识方式：顺序图中的对象一般以“对象名：类名”的方式标识，但也可以采用缩写形式“对象名”或者“：类名”。对象的下方用垂直虚线表示对象的生命线，即对象在某段时间内存在。对象生命的终结用生命线下方的叉号“×”表示。附着在对象生命线上的矩形框表示对象在此段时间内活跃。对象间的通信表现为对象的生命线之间的消息传递。在消息边上需附加消息名和消息参数，有时也以顺序号强调消息的时序。消息的源对象和目标对象可以相同，这种消息称为自调用（self-call）。顺序图可以在消息名前面的方括号中书写条件表达式，表明仅当条件成立时，该消息才发送。还可以在方括号的前面或者直接在消息名的前面加上迭代标记“*”，以表示一条消息对同一类的多个对象的对次发送。顺序图的左边可带有描述信息，以阐明消息发送的时刻、动作执行情况、两条消息之间的时间间隔以及约束信息等。还可以在消息边上附加文字注解信息，以增强顺序图的可理解性。典型的顺序图如图10.2所示。（P233）消息在面向对象的编程中，两个对象之间的交互是通过一个对象向另一个对象发送消息来实现的。值得注意的是，这里所提到的“消息”不能严格地从字面上去理解，因为消息是在一个通信协议中被“发送”的。绝大多数情况下，消息都是通过简单的操作调用来实现的。当一个对象调用另一个对象中的某操作时，一旦该操作被执行完，控制就会返回到调用者，同时还可能会返回一个值。当然，消息也可以是一个真正的通过某种通信机制（或者通过网络，或者位于一台计算机内部）而发送的消息，这样的消息在实时系统中最为常见。在所有的动态图（顺序图、协作图、状态图和活动图）中，消息都可以作为一种表示对象之间通信手段的方式而显示出来。在UML图形上，一个消息被绘制为一条位于该消息的发送者和接收者之间的带箭头的直线，箭头类型指示了消息的类型。UML的消息有如下四种类型：（1）简单消息（simplemessage）。以一种简单、抽象的函数表示对象之间的信息传递，不考虑通信过程的内部细节。简单消息在UML顺序图中用普通的有向箭头表示。简单消息象征一个平直的控制流。简单消息显示了控制是如何从一个对象传递到另一个对象的，这个过程中并没有描述任何有关对象之间通信的细节信息。当对象之间通信的细节信息不为我们所知，或者对我们无关紧要时，就可以在UML图中使用简单类型。它也可以用于显示一个同步消息的返回；在绘制时应该从处理该消息的对象引向调用者，表示控制正在传回来（也可能会同时传回一些结果）。（2）同步消息（synchronousmessage）消息源发出消息后，必须等待消息处理过程完毕并返回处理结果，才可继续执行后续操作。前面所述的自调用消息应该是同步的。同步消息的表示图元与简单消息相同，这表明UML在缺省状态下认为简单消息即为同步消息。一个嵌套的控制流，一般是作为操作调用来实现的。只有在处理该消息的操作结束之后（包括作为处理过程的一部分而发送的任何进一步的消息），调用者才能够恢复继续执行。消息的返回可以在顺序图中以一个简单消息的形式显示，或者当该消息已经被处理时其返回可以是隐含的。主动对象之间的同步消息表明了等待语义：发送者在继续执行之前会一直等待该消息被处理完（例如，发送者会等待接收者准备好处理该消息，并等待接收者在处理完该消息后做出肯定答复）。（3）异步消息（asynchronousmessage）异步消息：异步的控制流，其中没有显式的到调用者的返回消息。对象之间的异步消息表明了不等待语义；消息源发出消息后，不必等待消息的处理过程的返回，即可继续执行自己的后续操作。异步消息主要用于描述实时系统中的并发行为。异步消息在UML顺序图中用一种特别的单向箭头表示，见图10.2中的“msg1”（P233）。（4）返回消息（returnmessage）。表示前面发送的消息的处理过程完成后的返回结果。返回消息应该是同步的。在许多情况下，可以隐藏返回消息，但也可显示地标出返回消息以示强调。返回消息用虚线有向箭头表示，见图10.2中的“msg6”(P233)。一个对象可以通过发送标准消息“new”来创建另一个对象。当一个对象被删除或自我删除时，该对象生命线上的相应时间点应该用叉号(对生命线终结符)标识。UML的消息类型：消息类型注解在UML图中，简单消息和同步消息可以组合成一条线，线的一端是同步消息箭头，而另一端则是简单消息的返回箭头。这表明控制的返回实际上是非常快捷的（在操作调用之后几乎马上返回）。图３消息类型注解10.1.2协作图功能：协作图用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和协作图都用来描述对象间的交互关系，但它们的侧重点不同。顺序图强调消息交互的时间，而协作图则强调交互对象间的静态链接关系。从外观看，协作图并不采用单独的维度来表示时间的推移，因此，协作图中的对象可以在二维平面中自由占位。对象之间的链接用于表示消息传递的通道，消息标示于链接之上，消息的箭头指明消息的传递方向。在协作图中，消息的描述内容包含名称、参数、返回值以及序列号，返回值和序列号是可选的。虽然协作图不突出强调消息传递的时间序，但借助于序列号同样可以表达时间序：序列号较大的消息发生于较晚的时刻。消息序列号可以采用线性编号，但采用适当的多级编号会使消息之间的结构关系更清晰。例如：在图10.3中（P234）“1.1msg2”表明msg2是“对象1”为了处理“1.msg1”而发送的第一条消息；“1.2msg4”表明msg4是“对象1”为了处理“1.msg1”而发送的第二条消息；“1.1.1msg3”表明msg3是“对象2”为了处理“1.1msg2”而发送的第一条消息依此类推。如果一个对象在消息的交互过程中被创建，则可在对象名称之后标以{new}。类似地，如果一个对象在交互期间被删除，则可在对象名称之后标以{destroy}。典型的协作图如图10.3（P234）所示，该协作图与图10.2等价。10.1.3提取边界类、实体类和控制类一、主要类1.边界类边界类用于描述目标软件与外部环境之间的交互.边界对象（BoundaryObject）紧邻着系统的边界（但仍然属于系统内部）。它们与系统外部的参与者打交道，后者通过这些边界对象与系统内部的其他类型对象进行消息交互。边界类并负责实现如下功能：(1)界面控制。包括输入数据的格式及内容转换、输出结果的呈现以及软件运行过程中界面的变化与切换等。(2)外部接口。实现目标软件系统与外部系统或外部设备之间的信息交流和互操作。主要关注跨目标软件系统边界的通信协议。(3)环境隔离。将目标软件系统与操作系统、数据库管理系统、应用服务器中间件等环境软件进行交互的功能与特性封装于边界类中，使目标软件系统的其余部分尽可能地独立于环境软件。在UML类图中，边界类往往附加UML构造型《boundary》作为特别标识。例如：“家庭保安系统”中的边界类有“输入键盘接口类”、“传感器接口类”、“警报器接口类”、“报警电话接口类”和“显示面板接口类”。实体类表示目标软件