工件流

    在与现场的所有涉众确定了职责矩阵之后，下一个步骤是添加更多详细信息。在此阶段，我们着重于在职责矩阵中已经定义的工件之间的关系。

    一般而言，工件流在一个单独的会议中被设定，同时建立工件之间的关系。设想我们对以下的工件达成了一致：前景、用例模型、软件架构文档、用例规格说明、用例实现和组件。那么做出关于它们之间关系的提议是非常容易的。我们只专注于工件之间的关系，而不关心哪些角色使用它们，或负责创建它们。参见图 2 中的例子，其中使用了被提及的工件。

   
    图 2：工件流实例

    前景和用例模型之间的关系是直接的，单向关系。用例模型 源自于前景。这不意味着用例模型只能够包含来自于前景的元素。用例模型应该表示与前景相同的范围，只是更详细。任何前景范围以外的用例模型元素都应该引起一场关于调整前景或从用例模型中去掉超出范围的元素的讨论。

    软件架构文档（SAD）也源自于前景，并且上面进行的观察在这里也是有效的。软件架构文档也收到来自于用例模型的输入，由于在 SAD 中，我们需要一个对认为哪个用例在架构上是很重要 —— 也就是，哪个来自于系统的核心 —— 的描述。而用例模型又是随后的用例规格说明 的来源。应该再次出现关于用例的详细说明，但如果用例详细说明中存在用例模型范围以外的功能，那么我们需要决定是否应该调整用例规格说明或用例模型。

    在用例实现中，我们满足了功能和非功能的规范，也就是说，用例规格说明和 SAD。用例实现只包含来自于用例规格说明但不出自于 SAD 的元素。换句话说，如果 SAD 中的指示，连同实际的用例规格说明对开发人员来说足够构建用例的代码，那么用例实现 就是空的。在实践中，我们将用例实现文档作为参考。在那种情况下（我们与所有的涉众达成一致），我们构建代码，并且根据 SAD 测试和编制文档。

    工件流有一个优点。项目中的主要流是以简洁的格式直接可见的。另外，出现在活动流中的主要流也是直接可见的。

    结束语

    职责矩阵和工件流给出了开发案例主要部分的简洁、但完整的概述。当使用本文中说明的策略进行定义时，一定要确保新的 RUP 方法是根植于公司这些年来所积累的非常好的实践中的。