工作流程明细:
|
该工作流程明细的目的是优化系统设计。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
主题 |
|
该工作流程明细有以下目标:
此部分提供与该工作流程明细有关的附加信息的链接。
在精化阶段中开始。通过构造和移交阶段重现。
必需
通常,一个人员或小型团队负责一组设计元素(通常是包含其它设计元素的一个或多个包或子系统)。该人员/团队负责充实包或子系统中包含的元素的设计详细信息:完成所有操作定义和与其它设计元素的关系的定义。活动:类设计侧重于优化类设计元素的设计,而活动:子系统设计侧重于将映射到子系统自身的行为分配给包含的设计元素(包含的类或子系统)。
负责设计类的个人也应具有实施语言的知识,以及该类使用的算法或技术的知识。负责子系统的个人或团队应更多才,能够决定设计元素之间适当的功能分区,并能够理解各种设计选择中涉及的内在权衡。
当优化个别设计元素时,必须优化用例实现以反映设计元素职责的演化。通常,一个人员或小型团队负责优化一个或多个相关的用例实现。添加或优化设计元素时,需要重新考虑用例实现并在它们过时时进行更新,或设计模型中的改进可以简化用例实现。负责用例实现的个人或团队应对用例所需的行为以及在设计元素之间分配该行为的不同方法的权衡有更广泛的了解。另外,因为他们负责选择将执行用例的元素,他们需要对设计元素自身的外部(公共)行为有较深的理解。
通常这里的工作由个人或小型团队执行,并在团队之间需要通知更改的地方使用非正式的组间交互。优化设计元素时,职责经常在他们之间转移,需要同时更改大量设计元素和用例实现。因为职责的相互作用,几乎不可能让设计团队成员以完全隔离的方式工作。为将设计工作集中在所需的系统行为上(如用例实现所表达的),出现了一个典型的交互模式:
因为该过程本身是迭代的,“迭代的所有必需行为”的条件将根据生命周期中的位置而有所不同:
注意在开始实施和测试活动之前,不需要完成迭代的设计。随着设计的演化而部分地实施和测试它,可能是验证和优化设计的一种有效方法,即使在迭代中也是如此。
Rational Unified Process
|