主题

简介 回到页首

设计必须充分定义系统,以便可以明确地实施该系统。怎样才算充分随项目和公司的不同而不同。

在某些情况中设计就像一个草稿,仅制作到确保足以使实施者可以继续的程度就可以了(“草稿与代码”方法)。规范程度随实施者的经验、设计的复杂性以及设计可能被误解的风险而变化。

在其它情况中,将设计制作到其可被自动转换成代码的程度。这通常涉及对标准 UML 的扩展,以表示特定于语言和/或环境的语义。

设计还可能是分层的,例如以下情况:

  • 高级别设计模型,拟订整个系统概况
  • 子系统规范模型,准确地指定了系统中的主要子系统所需的接口和行为
  • 子系统内部的详细设计模型

../../artifact/ar_devcs.htm -- This hyperlink in not present in this generated website开发案例应定义如何以项目的特定过程实现设计模型,以及如何或是否将模型关联到其它模型以及实施。应在../../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website特定于项目的指南中捕获该详细信息。

以下部分描述与设计和实施有关的一些不同选项,并讨论这些方法的益处和缺点。

草稿和代码 回到页首

一个常见的设计方法是在非常抽象的级别勾画出设计,然后直接转换为代码。设计模型的维护是手工的。

在此方法中,使设计类成为几个代码级别类的抽象。建议将每个设计类映射到一个“头”类,然后可以用几个“助手”类执行其行为。可以使用“助手”类实施复杂属性,或构建实现操作所需的数据结构。在设计中,不对“助手”类建模且仅对关键属性、关系和头类定义的操作建模。此类模型的目的是抽象出可由实施者完成的详细信息。

扩展该方法以将其应用到其它设计模型元素。可能已设计过比代码级别接口更抽象的接口等。

双向工程 回到页首

在双向工程环境中,设计模型发展成可变为代码的可视说明的详细级别。同步代码及其可视说明(有工具支持)。

以下是用于表示双向工程环境中的设计模型的一些选项。

高级别设计模型和详细设计模型 回到页首

在此方法中,维护两个级别的设计模型。每个高级别设计元素都是双向模型中一个或多个详细元素的抽象。例如,设计类可能映射到一个“头”类和几个“助手”类,就和先前“草稿和代码”方法中描述的一样。从高级别设计模型元素到双向模型元素的可跟踪性可以帮助维护两个模型之间的一致性。

虽然这可以帮助抽象出较不重要的详细信息,但必须将该益处与为维护模型之间的一致性所需的工作量相权衡。

单个演化设计模型 回到页首

在此方法中,有单个设计模型。初始设计元素草稿演化成可以与代码同步的程度。各种图(例如那些用于描述设计用例实现的图)初始引用草稿设计类,但最终将引用特定于语言的类。按需要维护设计的高级别描述,如:

  • 系统的逻辑结构的图,
  • 子系统/组件规范,
  • 设计模式/机制。

这样的模型易于维护与实施的一致性。

规范和实现模型 回到页首

相关方法是按照主要子系统的规范定义设计,详细至可以对它们编译客户端实施的程度。

子系统实现的详细设计的建模和维护可以与此规范模型分开。

请参阅指南:设计子系统以获取与子系统规范和实现以及何时应使用它们相关的指南。



Rational Unified Process   2003.06.15