该工作流程明细的目的是优化系统设计。

主题


      分析类
分析类
  分析类
分析类
  设计类
设计类
  接口
接口
设计子系统
设计子系统
  用例
用例
 
               
 
设计员
设计员
 

 
Enterprise JavaBean(EJB)设计
Enterprise
JavaBean(EJB)设计

 
类设计
类设计

 
设计可测性元素
设计可测性元素

 
子系统设计
子系统设计

 
用例设计
用例设计

 
               
      设计模型
设计模型
Enterprise Java Bean(EJB)
Enterprise
Java Bean(EJB)
  设计模型
设计模型
设计类
设计类
  设计包
设计包
可测性类
可测性类
  设计子系统
设计子系统
设计类
设计类
  设计模型
设计模型
设计用例实现
设计用例实现
 
                  接口
接口
设计模型
设计模型
     

      导航图
导航图
设计模型
设计模型
 
       
 
技术复审员
技术复审员
 

 
复审设计
复审设计

 
       
      复审记录
复审记录
 


描述 To top of page

该工作流程明细有以下目标:

  • 通过作出设计元素如何实现其所需行为的详细信息,优化设计元素的定义
  • 根据已确定的新设计元素,优化和更新用例实现(即,保持用例实现更新)
  • 随设计演化复审该设计

相关信息 To top of page

此部分提供与该工作流程明细有关的附加信息的链接。

计时 To top of page

在精化阶段中开始。通过构造和移交阶段重现。

可选性 To top of page

必需

如何配备人员 回到页首

通常,一个人员或小型团队负责一组设计元素(通常是包含其它设计元素的一个或多个包或子系统)。该人员/团队负责充实包或子系统中包含的元素的设计详细信息:完成所有操作定义和与其它设计元素的关系的定义。活动:类设计侧重于优化类设计元素的设计,而活动:子系统设计侧重于将映射到子系统自身的行为分配给包含的设计元素(包含的类或子系统)。

负责设计类的个人也应具有实施语言的知识,以及该类使用的算法或技术的知识。负责子系统的个人或团队应更多才,能够决定设计元素之间适当的功能分区,并能够理解各种设计选择中涉及的内在权衡。

当优化个别设计元素时,必须优化用例实现以反映设计元素职责的演化。通常,一个人员或小型团队负责优化一个或多个相关的用例实现。添加或优化设计元素时,需要重新考虑用例实现并在它们过时时进行更新,或设计模型中的改进可以简化用例实现。负责用例实现的个人或团队应对用例所需的行为以及在设计元素之间分配该行为的不同方法的权衡有更广泛的了解。另外,因为他们负责选择将执行用例的元素,他们需要对设计元素自身的外部(公共)行为有较深的理解。

工作指南 回到页首

通常这里的工作由个人或小型团队执行,并在团队之间需要通知更改的地方使用非正式的组间交互。优化设计元素时,职责经常在他们之间转移,需要同时更改大量设计元素和用例实现。因为职责的相互作用,几乎不可能让设计团队成员以完全隔离的方式工作。为将设计工作集中在所需的系统行为上(如用例实现所表达的),出现了一个典型的交互模式:

  • 由负责的个人或团队优化设计元素
  • 由一个非正式组成的小型团队(大约 2 到 5 个人)找出新设计元素对一组现有用例实现的影响
  • 在讨论过程中,确定对用例实现及参与设计元素的更改
  • 该周期一直重复,直到已设计完该迭代的所有必需行为。

因为该过程本身是迭代的,“迭代的所有必需行为”的条件将根据生命周期中的位置而有所不同:

  • 在精化阶段中,应侧重于在体系结构方面重要的行为,实际上忽略所有其它“详细信息”(或更有可能是“彻底去除”)
  • 在构造阶段中,将向设计的完整度和一致性转移,以便在构造阶段结束时不再有未解决的设计问题。

注意在开始实施和测试活动之前,不需要完成迭代的设计。随着设计的演化而部分地实施和测试它,可能是验证和优化设计的一种有效方法,即使在迭代中也是如此。


Rational Unified Process   2003.06.15