主题

决定如何执行工作流程 到页首

应就分析与设计规程的工作流程做出以下决策:

  • 通过查看分析与设计:工作流程,决定如何执行工作流程。研究图及其警戒条件,以及指南。决定执行哪些工作流程明细,以及执行的顺序。 
  • 决定要执行分析与设计工作流程明细的哪些部分。以下几部分可相对独立于剩余部分而引入。

工作流程的部分

注释

用户界面设计 有些项目决定不设计用户界面。一个原因可能是用户界面易于开发。 如果您决定不进行用户界面设计,则意味着您不开发导航图和用户界面原型。 
数据库设计 只在实体将要存储在数据库中的情况下使用。如果您决定不进行数据库设计,则意味着您不开发任何数据模型。 

  • 决定在项目生命周期内何时引入工作流程的每个部分。有时可以一直等到精化阶段,才开始引入分析与设计规程。 例如,如果进行开发的领域已得到很好的理解,且开发工作没有过高的性能需求(或其它非功能性需求),并将以经过认真试验的体系结构为基础,那么在先启阶段构造原型的需要将很小。

将决策 下,作为项目特定流程的一部分。

决定如何使用工件 到页首

决定要使用哪些工件和每个工件的使用方法。下表描述了必需的工件和只用于某些情况的工件。 关于如何定制每个工件的更多详细信息,以及该特定工件的优缺点的讨论,请阅读每个工件的标题为“定制”的部分。

对于每个工件,决定应如何使用工件:必须、应该、可以或不能。

工件 用途

定制(可选,建议使用)

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

可选

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

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

导航图用户界面原型

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

可选

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

设计模型

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

建议大多数项目使用。

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

设计类设计包

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

建议大多数项目使用。

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

用例实现

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

建议大多数项目使用。

接口

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

建议大多数项目使用。

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

设计子系统

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

建议大多数项目使用。

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

事件

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

信号

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

建议用于实时系统。

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

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

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

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

可选。

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

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

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

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

建议大多数项目使用。

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

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

建议大多数项目使用。

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

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

建议大多数项目使用。


根据项目的需要定制每个工件。关于定制注意事项,请参阅工件的描述页

决定使用哪些报告 到页首

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

决定如何复审 到页首

决定每个工件的复审级别,请决定如何复审和核准分析与设计的结果,以及对结果复审到何种程度。

设计复审的优点有:

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

设计复审的缺点有:

  • 它会耗费时间和资源。 
  • 如果管理不当,则很容易被误用。

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

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

关于复审及不同类型的复审的更多信息,请参阅../workguid/wg_rview.htm -- This hyperlink in not present in this generated website工作指南:复审

决定是否生成代码 到页首

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



Rational Unified Process   2003.06.15