指南:析与设计中的重要决策
本指南描述了在定制流程的“分析和设计”方面时需考虑的一些重要事项。
关系
主要描述

决定如何使用工作产品

决定要使用的工作产品以及使用这些工作产品的方式。除了确定要使用的工作产品之外,定制每个要使用的工作产品来适应项目需求也很重要。 

下表指定了建议使用哪些“分析和设计”工作产品,以及其中哪些被认为是可选的(即,只能在某些情况下使用)。关于其他的定制注意事项,请参阅工作产品描述页面的定制部分。

工作产品 用途

定制(可选,建议使用)

分析模型分析类 分析模型对于在做出设计决策之前更好地理解需求很有用。对于复杂系统,可以维护该模型以对系统进行概念性概述。

可选

在许多项目中,使用初始设计模型来代替分析模型。

在创建了分析模型的项目中,它通常是一个临时工件,将进化成设计模型。

导航图用户界面原型

带有大型和复杂用户界面的项目应考虑用户界面设计。

可选

对于较小的开发工作,不大正式的用户界面设计可能就足够了。

设计模型

大多数系统,甚至是较小的系统,也应在实施之前进行设计,以避免由于设计错误而不得不进行代价高昂的返工。 可视化模型使得设计思路可以方便地传达。正向设计和反向设计的工具可确保与实施模型一致,并节省工作。

建议大多数项目使用。

对于较小的项目,是否使用自动工具并不重要,但如果使用,则会在长时间内对生产率有好处。

设计类设计包

类和包是任何面向对象设计的基本部件。面向对象设计是用于大多数项目的标准设计方法。

建议大多数项目使用。

主要的定制问题是决定将使用哪些构造型(可以在设计指南中找到答案)。

用例实现

提供用例与设计之间的桥梁。

建议大多数项目使用。

界面

接口通常用来独立于实现行为的大粒度组件而定义该行为。

建议大多数项目使用。

基于组件的设计正在成为标准设计方法。

设计子系统

设计子系统用来在提供接口的组件内封装行为。它用来包括类和/或其他子系统的交互。

建议大多数项目使用。

子系统对于提升设计的抽象水平常常是有用的。它们使得系统更易于理解。

事件

对于响应许多外部事件的系统可能有用。 建议用于实时系统。

协议

对于实时系统是必需的。 建议用于实时系统。

信号

对于需要并行性且由事件推动的系统可能有用。

对于实时系统是必需的。

对于需要并行性且由事件推动的系统可能有用。

建议用于实时系统。

封装体

用于实时系统,但也可以用于任何具有高度并行性的系统的建模和设计。

建议用于实时系统。

数据模型 用来描述永久信息的逻辑结构和可能的实际结构。

建议用于使用数据库的项目。

部署模型 显示运行时处理节点的配置、节点之间的通信链路以及驻留在节点上的组件实例和对象。

可选。

许多系统具有多个处理节点,因此需要处理部署模型。不过,它可以作为软件体系结构文档的一部分而包括在内,而不需要作为单独标识的工件存在。

体系结构概念验证 用来确定是否存在某个解决方案,该解决方案满足具有重要体系结构意义的需求。 建议大多数项目使用。

许多项目将使用体系结构概念验证来确定需求的可行性。它可以采取多种形式,例如:

  • 似乎适用于解决方案的一系列已知技术
  • 解决方案的概念模型草图
  • 解决方案的模拟
  • 可执行原型。
引用体系结构 引用体系结构通过重用经证明的解决方案来加快开发速度和减少风险。

建议大多数项目使用。

如果存在合适的引用体系结构材料,则可以显著加快开发速度和减少风险。

软件体系结构文档(SAD) 软件体系结构文档用来对系统进行综合的体系结构概述。此概述有助于理解系统,以及记录主要体系结构决策。

建议大多数项目使用。

软件体系结构的高级概述对于除规模最小的系统之外的所有系统都有用。 与较小型项目相比,复杂系统通常要求更高的详细程度和更多的观察。

用户界面原型 用来在真正的开发工作开始之前展示并测试功能和可用性。它是用来验证设计的有效方法,可防止浪费过多时间。

建议大多数项目使用。



决定使用哪些报告

决定要使用哪些报告,这将取决于可供项目使用的报告工具。如果报告生成工具可用,则建议为面向模型工作产品(例如设计类和用例实现)生成报告。RUP 配置中的现有报告在工作产品描述页面中提供,或按照树形浏览器中的相关工作产品分组。

决定如何复审

确定要使用的每个工作产品所用的复审级别。具体来说,就是确定如何复审和核准“分析与设计”的结果,以及以何种程度对结果进行复审。  

在“分析与设计”期间进行复审的优点包括:

  • 可检测到在测试中不可能或很难检测的问题。例如风格问题和布局。 
  • 它是一种强制采用公共建模风格的方法,并使个人有机会相互学习。
  • 可检测到在项目现阶段测试期间无法检测到的那些缺陷。

在“分析与设计”期间进行复审的缺点包括:

  • 耗费时间和资源。 
  • 若管理不当,很容易被误用。

“分析与设计”复审中可改变的因素有复审技术、资源和范围。下面是关于您能决定在项目中采取什么行动的一些示例:

  • 决定对子系统的本地更改只由一名同事进行复审,该同事开展检查并以书面形式提交结果。
  • 决定设计的哪些部分根本不会进行复审;例如,只为每名项目成员复审某些类,并希望这可以确保该风格的质量与结果的剩余部分类似。
  • 决定软件体系结构文档将在单独的会议期间由客户复审。
  • 决定对重要接口的变更使用正式的复审会议,重要接口即指影响多名项目成员工作的接口。

关于复审级别的更多信息,请参阅指南:复审级别。  

决定是否生成代码

您的设计方式会根据是否从设计模型生成代码而有所不同。如果生成代码,那么设计就需要非常详细。 另一方面,如果不从设计生成代码,则设计中没必要非常详细。相反,设计中的细节必须手动地与代码同步。