Activity:设计组件
此活动的目的是优化系统的设计。
描述工作分解结构团队分配工作产品使用
关系
父代活动
描述

此活动具有以下目标:

  • 通过作出设计元素如何实现其所需行为的详细信息,优化设计元素的定义。
  • 根据已确定的新设计元素,优化和更新用例实现(即,保持用例实现更新)
  • 复审设计
属性
事件驱动
多次出现
正在进行
可选
已计划
可重复
人员配备

通常,一个人员或小型团队负责一组设计元素(通常是包含其他设计元素的一个或多个包或子系统)。该人员/团队负责充实包或子系统中包含的元素的设计详细信息:完成所有操作定义和与其他设计元素的关系的定义。任务:封装体设计侧重于根据封装体和(被动或数据)类的系统中功能的递归分解。任务:类设计侧重于优化被动类设计元素的设计,而任务:子系统设计侧重于将映射到子系统自身的行为分配给包含的设计元素(包含的封装体和类或子系统)。通常子系统主要用作粗粒度的模型组织结构,而封装体用于大批工作和“普通”类(大部分用于信息的被动存储)。

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

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

使用
使用指导信息

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

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

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

  • 注重精化阶段中对体系结构有重要意义的行为。忽略所有其他的“细节”。
  • 在构造阶段中,将向设计的完整度和一致性转移,以便在构造阶段结束时不再有未解决的设计问题。

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