系统架构设计师学习之路（33）

6.3 基于UML的软件开发过程

6.3.3 面向对象的设计方法
面向对象的软件设计过程如图所示。

1.设计用例实现方案
UML的交互图（顺序图、协作图）适于用例实现方案的表示。该设计方法包含如下三个步骤：
（1）提取边界类、实体类和控制类
边界类用于描述目标软件系统与外部环境之间的交互，并负责实现如下功能：

• 界面控制。包括输入数据的格式及内容转换、输出结果的呈现以及软件运行过程中界面的变化写切换等。
• 外部接口。实现目标软件系统与外部系统或外部设备之间的信息交流和互操作。主要关注跨越目标软件系统边界的通信协议。
• 环境隔离。将目标软件系统与操作系统、数据库管理系统、应用服务器中间件等境软件进行交互的功能与特性封装于边界类之中，使目标软件系统的其余部分尽可能地独立于环境软件。

在UML类图中，边界类往往附加UML构造型<< boundary>>作为特别标识。
实体类 表示目标软件系统中具有持久意义的信息项及其操作。实体类的操作具有“内向收敛”的特征，它们仅向目标软件系统的其余部分提供读/写信息项内容的必要的操作接口，并不涉及业务逻辑处理。实体类的UML构造型为<< entity>>。
控制类 作为完成用例任务的责任承担者，协调、控制其他类共同完成用例规定的功能或行为。对于比较复杂的用例，控制类通常并不处理具体的任务细节，但是它应知道如何分解任务，如何将子任务分派给适当的辅助类，以及如何在辅助类之间进行消息传递和协调。控制类的UML构造型为<< control>>。
通常情况下，执行者与用例之间的一种通信连接对应一个边界类。但是，如果两个以上的用例与同一执行者交互，并且这些交互工具有共同行为、完成相同或类似的任务，就可以考虑用同一边界类实现用例与执行者之间的交互。这就意味着边界类的作用范围可以超越单个用例。
（2）构造交互图
UML交互图，以交互图作为用例的精确实现方案。
如前所示，用例描述中已包含事件流说明。事件流中的事件应直接对应于交互图中的消息，而事件间的先后关系体现为交互图中的时序，对消息的响应则构成消息接收者的职责。这种职责在后续的设计活动中将确立为类的方法。
在UML顺序图中，从左往右依次是：

• 用例的主动执行者
• 用户界面的边界类
• 控制类
• 辅助类和实体类
• 作为外部接口和环境隔离层的边界类
• 位于目标软件系统边界之外的被动执行者

如此布局之后，在顺序图中不应该出现穿越控制类生命线的消息，即主动执行者向边界类发出命令，边界类将命令进行适当转换后传送至控制类，控制类通过消息请求辅助类、实体类的帮助，协调、控制它们共同完成来自主动执行者的命令。在此过程中，控制类或辅助类可以向右侧的边界类发送消息，将信息或外部处理请求由边界类传向外部系统（被动执行者）。
在用例描述中，许多用例除主事件流外，往往还包含备选事件流，以说明在某些特殊或异常情况下的事件和响应动作序列。为了易于理解，在设计模型中应该用分离的UML交互图分别表示事件流和每个备选事件流。
（3）根据交互图精化类图
在UML交互图中，对每个类的对象都规定了它必须响应的消息以及类的对象之间的消息传递通道。前者对应于类的操作，后者则对应于类之间的连接关系。
因此可以利用交互图精化分析模型中的类图，将交互图中出现的新类添加到原有类图中，并且对相关的类进行精化，定义其属性和操作。
原则上，每个类都应该有一个操作来响应交互图中指向其对象的那条消息。但是，这并不意味着消息与操作一定会一一对应，因为类的一个操作可能具有响应多条消息的能力。同理，两个类之间的一条连接关系也可以为多条消息提供传递通道。
根据交互图确立类的属性。类的操作完成消息响应责任的能力来源于两方面的知识，一是类本身具有的信息，即类的属性；二是类能够找到的其他类，通过其他类协助其完成消息响应。在综合考虑着两个因素后。类的操作应该明确哪些子任务可通过消息传递路径委托给其他类完成，哪些子任务必须由自身完成。根据后一种子任务的需要，结合领域和业务知识即可推导出类应具有的属性。

2.设计技术支撑方案
在许多软件项目中，应用功能往往都需要一组技术支撑机制为其提供服务。
例如，对分布式应用软件（包括电子商务应用、企业ERP系统等）而言，需要数据持久存储服务、安全控制服务、分布式事务管理服务、并发与同步控制服务和可靠消息服务等。
技术支撑方案应该为多个用例的软件实现提供技术服务，所以，它应该成为整个目标软件系统中全局性的公共技术平台。当需求发生变化时，技术支撑方案应具有良好的稳定性。这就要求软件设计者选用开放性和可扩充性较好的技术支撑方案。如果目标软件系统的顶层架构采用分层方式，那么技术支撑方案应该位于层次结构中的较低层次。
技术支撑方案的设计一方面取决于目标软件系统对公共技术服务的需求，另一方面取决于设计人员对软件技术手段的把握和选取。

3.设计用户界面
（1）熟悉用户并对用户进行分类
（2）按用户类别分析用户的工作流程与习惯
（3）设计命令系统并进行优化
（4）设计用户界面的各种细节
（5）增加用户界面专用的类与对象
利用快速原型演示，改进界面设计。为人机交互部分构造原型，是界面设计的基本技术之一。为用户演示界面原型，让他们直观感受目标软件系统的使用方法，并评判系统是否功能齐全、方便好用。

4.精化设计模型
对模型进行改进的活动可以分为精化和合并两种，一般先从精化开始。
首先，由于初始架构模型已经包括总原则和层结构两部分的内容。
现在要做的工作是根据需求和架构原则来划分不同的粗粒度组件。
粗粒度组件来源于分析活动中的业务实体。把具有很强相关性业务实体组合起来，形成一个集合。集合内部关系错综复杂，同时集合向外部提供服务接口。这样的集合称为粗粒度组件。
粗粒度组件对外的接口和内部的实现是相区分的。粗粒度组件的形式有很多，Java平台上的jar包、Windows平台上的dll文件，甚至古老的.o或.a文件都可以是粗粒度组件的表现形式。
设计优秀的粗粒度组件应该只是完成一项功能，这一点是它与子系统的主要区分。
粗粒度组件是可以跨越层次的。粗粒度组件拥有持久化的行为，拥有业务逻辑，需要表示层的支持。这样看来，它所属的轴向和层次的轴向是相互垂直的。粗粒度组件来源于需求。需求阶段产生的需求说明书或是用例模型将是粗粒度组件开发的基础。
在拥有了需求工作之后，我们需要对需求进行功能性的划分，将需求分为几个功能组，这样我们基本上就可以得到相应的粗粒度组件了。如果系统比较庞大，可以对功能组再做细分。这取决于粗粒度组件之间的复杂关系，最后的结果也将包含大量的组件和复杂的逻辑。过大的范围，则会导致粗粒度组件难以重用，导致粗粒度组建称为一个子系统。
在得到了粗粒度组件之后，下面的工作主要分为两个部分：第一个部分：定义不同的粗粒度组件之间的关系；第二部分：在粗粒度组件的基础上定义业务实体或是定义细粒度组件。
细粒度组件有更好的重用性，并使架构设计的精化工作更进一步。
按Jacobson推荐的面向对象软件工程（OOSE）的做法，我们需要从软件的目标领域中识别出关键性的实体，或者说是领域中的名词。然后决定实体属于哪些粗粒度组件。
最初得到的组件模型可能并不完善，需要对其进行修改。可能某个组件中的类太多了，过于复杂，就需要对其进行进一步精化、分为更细的组件，也许某个组件中的类太少了，需要和其他的组件进行合并。也许有的组件之间存在重复的要素，可以从中抽取出共性部分，形成新的组件。组件分析的过程并没有一种标准的做法，只能根据具体的案例来分析。
最后的模型将会明确包含几个经过精化之后的粗粒度组件。粗粒度组件之间的关系也会进行一次重新定义。