任务:封装体设计
此任务描述了封装体设计的特性。
规程:分析和设计
用途
  • 详述并优化封装体的描述。
关系
角色主执行者: 其他执行者:
输入必需: 可选:
输出
流程使用情况
主要描述

封装体用于定义系统中的并发执行线程。封装体可以嵌套到任意深度,也可以与设计(被动)类有关联。此活动对每个封装体执行一次,包括在此任务范围内识别的新的封装体。

 UML 2.0 表示法

注意封装体的当前 RUP 表示基于 UML 1.5 表示法。该表示法的大部分内容可以在 UML 2.0 中使用概念:结构化类表示。

请参阅UML 1.x 和 UML 2.0 之间的区别以获取更多信息。

步骤
创建端口并与协议绑定

考虑封装体职责,创建一组初始的端口类。这些端口类代表到封装体的“接口”。端口类代表工作产品:协议的实现,而后者又代表一组用于与封装体进行通信的信号。

创建端口时,请考虑核对表:协议来确定协议是否恰当。端口应该反映单组相关的职责;拥有一个范围类似的协议使它能够在数个封装体中重用。一旦选择了适当的协议,就将端口绑定到该适当的协议。

验证封装体交互

一旦端口绑定到了协议上,就必须对封装体的外部行为进行评价和验证。用手动走查方法或自动模拟工具,通过模拟将执行封装体行为的事件来测试封装体的行为。验证还将考虑与设计中的封装体进行交互的封装体。使用自动工具,在封装体内撰写桩模块代码,以允许端口被测试。在协议或端口定义中或者在封装体职责中检测到错误时,请对封装体、端口和协议定义作出适当的更改。

定义封装体状态机

一旦验证了封装体端口和协议,就定义封装体的内部行为。使用状态表图定义封装体的行为。参考:指南:状态表图。其他一般的封装体信息可以从指南:封装体核对表:封装体中获取。

定义状态

首先,确定封装体可以存在的状态。状态必须是唯一的(封装体不能同时处于两种状态)而且是描述性的。有关更多信息,请参阅适当的指南和检查点。

定义状态转换

一旦定义了状态,就考虑状态之间的转换。转换代码看起来应该像较高级别的应用程序伪码,它应该基本上由实时操作系统服务调用组成,例如框架服务、时间服务、端口操作、封装体操作和被动类操作。

在将详细代码添加到封装体转换时:

  • 如果代码将在其他转换中有用,请考虑将它委托给封装体操作。
  • 考虑代码是否实施符合封装体的职责的能力。

在定义封装体操作时:

  • 考虑功能是否将可以在任何时候从封装体的任何转换中使用,以及所做的任何工作是否在系统的其他地方有用。它是否在考虑将它委托给被动类功能。
  • 如果代码太针对应用程序了,而无法存储在某个数据类中,请考虑为该代码创建其他的数据类作为抽象。
  • 如果代码处理数据结构操纵(例如,维护列表),或者执行复杂(多于 1 条线)计算,那么它就应该被推到数据类中。
定义被动类的需求

根据封装体状态机,检验封装体引用的被动类。如果对这些类有新的要求,就需要生成变更请求来影响要求的更改。如果识别了新的类,那么就应该把对这些类的要求(最具体的说就是对它们所要求的操作)收集起来,并应该创建类。这些类将在任务:类设计中进一步描述。

简介封装体继承

封装体继承用于实施泛化-专门化,来利用多态性、重用实施。这里的关键字是“实施” - 这是一个主要用于重用封装体的内部结构,而不是封装体的外部行为的方法。

继承经常误用于实现那些本来可以使用更简单的设计方法来更轻松实现的事物。

将继承用于泛化-专门化

继承有三种类型。将它们从复杂性最低(最尽人意)到最高(最不尽人意)排列,分别是:

  • 接口继承 - 只继承端口和协议,这是最理想的继承类型
  • 结构继承 - 继承接口加上结构容器分层结构(对框架有用)
  • 行为继承 - 除了接口和结构继承外,还复用行为代码和状态机

结构和行为继承会带来一些问题:

  • 对超类作出更改时,继承提供的非常强烈的耦合程度造成对子类的级联的更改。
  • 覆盖和删除子类中的超类行为和结构的需要表示没有对继承进行正确使用(通常用于策略性的代码重用)。重构类和封装体以及委托的适当使用是更适当的策略。
  • 继承意味着将设计决策沿着类层次结构向上移动,造成不尽人意的设计和编译依赖关系。 

其他问题包括:

  • 决策可能并非在所有的使用情形中都适当。
  • 引入继承实际上使重用更困难,因为设计元素会耦合得更紧密。
  • 设计变得更脆弱,因为使决策无效的任何新要求都会造成大问题。
  • 设计必须极端灵活才能补偿,而要做到这一点往往很困难。这就是使设计可重用框架如此困难的原因!

所有包含结构/行为的设计都有内在的决策和假设(明确或隐含)。要问的关键问题是:您完全确信,决策/假设将总是有效吗?如果不是的话,您可以做什么来除去它或者使它有更改的可能?

验证封装体行为

作为最后的步骤,封装体的行为必须得到评价和验证。应该用手动走查方法或自动模拟工具,通过模拟将执行封装体行为的事件来测试封装体的行为。此外,还应该验证封装体的内部结构,确保不但验证了外部行为,还验证了它的内部实施。可能需要使用自动工具撰写桩模块代码,来模拟被动数据类以及封装体与之交互的外部封装体的实施。检测到的缺陷应该记录下来,并应该对封装体定义作出适当的更改。

更多信息