活动:
|
用途
|
|
角色:设计员 | |
频率:每个设计子系统一次。 | |
步骤 | |
输入工件: | 生成的工件: |
工具向导: | |
更多信息: | |
工作流程明细: |
用途 | 指定子系统的内部行为。 确定满足子系统行为需求所需的新设计类或设计子系统。 |
子系统内模型元素的协作应该用显示子系统行为如何实现的序列图来记录。子系统在接口上实现的每个操作都应该有一个或多个记录的序列图。该图归该子系统所有,并用于设计子系统的内部行为。
如果子系统的行为高度依赖于状态并代表一个或多个控制线程,那么状态机一般在描述子系统行为时更有用。这种情况下的状态机通常与活动类一起用来表示系统(或者这种情况下的子系统)的控制线程的分解,并在状态表图中有所描述,请参阅指南:状态表图。
在子系统内可能有独立的执行线程,这由活动类表示。
示例:
子系统协作执行系统要求的某一行为,这可以用序列图表示:
该图显示子系统的接口如何用于执行场景。特别是对于“网络处理”子系统,我们发现了子系统必须支持的特定接口(在这种情况下是 ICoordinator)和操作。我们还发现“网络处理”子系统依赖于 IBHandler 和 IAHandler 接口。
在子系统内部,我们发现了 ICoordinator 接口是如何实现的:
“协调程序”类充当 ICoordinator 接口的“代理”,处理接口操作并协调接口行为。
该“内部”序列图确切地显示了哪些类提供接口,内部需要发生什么情况才能提供子系统的功能,以及哪些类从子系统向外发送消息。该图阐明了内部设计,这对于内部设计复杂的子系统是必不可少的。它还能使读者很容易了解子系统行为,这样就有希望使其在各环境中可重用。
创建这些“接口实现”图时,可能有必要创建新的类和子系统来执行所要求的行为。流程与“用例分析”中所定义的类似,但我们处理的是接口操作而不是用例。对于每个接口操作,确定在当前子系统中执行该操作所需要的类(或者在所要求的行为很复杂的某些情况下,为包含的子系统)。在现有类/子系统无法提供所要求的行为的情况下,创建新的类/子系统(但先尝试重用)。
创建新的设计元素时,应强制重新考虑子系统内容和边界。要小心避免两个不同子系统中的类实际相同。存在这样的类则意味着子系统边界可能定得不大好。定期重新访问活动:确定设计元素,这可重新平衡子系统职责。
有时创建两个单独的子系统内部模型会很有用,一个是以子系统客户端为目标的规范,而另一个是以实施者为目标的实现。规范可以包括“理想”的类和协作,根据理想的类和协作来描述子系统的行为。另一方面,实现则更与实施紧密相符,并可能演变为实施。有关设计子系统规范和实现的更多信息,请参阅指南:设计子系统、子系统规范和实现。
用途 | 记录子系统的内部结构。 |
记录子系统的内部结构,创建一个或多个类图来显示子系统所包含的元素以及它们的相互关联。一个类图应该就足够了,但使用多个类图可降低复杂度并提高可读性。
类图示例如下所示:
订单输入系统的类图示例。
子系统的内部内容是作为组件来建模的,该内容还可以在组件图中的组件矩形内表示。这种表示法还让我们将该子系统的交互点包含到系统的其它部分中,这是通过其接口来实现的。
组件图示例如下所示,该图描绘了“订单”子系统、其内部内容以及其提供的和所要求的接口。
“订单”子系统的组件图示例
因为组件是结构化的类,因此它可以紧密封装起来,方法是强制从外部通过服从所声明接口的端口进行通信,这使得该组件的规范和互连接更为精确。这种表示法使我们能够通过连接器“传导”部件实例,以在组件实施中扮演特定的角色(有关其它信息,请参阅概念:结构化的类)。
下面显示的是使用接口和端口的“订单”子系统的组合结构图示例。
“订单”子系统的组合结构图示例
此外,可能需要通过状态表图来记录子系统可能会呈现的状态,请参阅指南:状态表图。子系统本身所包含的类的描述是在活动:类设计中进行处理的。
用途 | 记录子系统所依赖的接口。 |
当一个子系统所含的元素使用另一子系统所包含元素的某个行为时,封闭的子系统之间就建立了依赖关系。为了提高重用性并降低维护依赖关系,我们希望根据对子系统的特定接口的依赖关系来表示这一点,而不是根据对子系统本身或者对子系统中所包含元素的依赖关系来表示。
这样做的原因有两方面:
创建依赖关系时,请确保子系统所包含的模型元素与其它子系统所包含的模型元素之间没有任何直接依赖关系或关联。还要确保各子系统和各接口之间没有循环的依赖关系;一个子系统不能既实现某一接口而又依赖于该接口。
如下所示,可以直接绘制出子系统之间以及子系统和包之间的依赖关系。如果这样显示依赖关系,则说明一个子系统(例如“发票管理”)直接依赖于另一个子系统(“支付调度管理”)。
使用直接依赖关系的子系统分层示例
当有可能将一个子系统替换为另一个子系统时(它们有相同的接口),依赖关系可以绘制到该子系统实现的一个接口,而不是绘制到子系统本身。这就允许使用任何实现相同接口的其它模型元素(子系统或类)。使用接口依赖关系,则允许使用可替代的设计元素来设计灵活的框架。
使用接口依赖关系的子系统分层示例
使用直接依赖关系的子系统分层示例
使用接口依赖关系的子系统分层示例
关于更多信息,请参阅 UML 1.x 与 UML 2.0 之间的差别。
Rational Unified Process
|