在构架的模块分解结构的最初几个层次相当稳定后，就可以把这些模块分配给开发小 组。所得到的结果就是第2章所讨论的工作分配视图。该视图或者将模块分配给现有的开 发单元，或者定义新的单元。
早在1968年，构架与其开发者的密切关系就引起了有关人土的关注。[Conway 68, 29]曾做过如下阐述：
任取系统中的两个结点x和y。它们要么通过某个路径相连.要么不相连。（也就是说， 它们或者以某种能影响系统操作的方式通信，或者不进行这样的通信。）如果有分支存在， 则负责这两个节点开发的设计小组X和Y肯定已进行过协商，并就这两个节点的通信接口 规范达成了一致。而另一方面，如果x和y这两个节点之间没有分支，则这两个子系统之间就没有通信，因而这两个开发小组也就不需要协商，x和y之间也就没有分支。
Conway做这一阐述的目的是要说明怎样将开发组织的结构和系统的结构区分幵来 (至少是从通信路径这一方面），但开发组织的结构和系统的结构这两者之间的关系是双 向的，而且这种双向性是必要的。
构架对组织结构的影响是显而易见的。一旦对所要开发的系统的构架达成了共识，就 要将各个大模块的开发分配给各个小组，从而就产生了能够体现出各个小组的工作分解结 构。每个小组可以按自己的模式进行开发（或者采用整个系统所规定的开发模式）。对于 大型系统而言，这些幵发小组吋能分别属于不同的子幵发商。开发实践可能包括以下项目. 如用于通信的公告牌和网页、针对文件的命名规则以及配質控制系统。所有这些都可能随 开发小组的不同而不同，对大型系统的开发更是如此。而且，要为每个小组建立质量保证 及测试规程，每个小组也都需要建立联系以便于相互协调。
所以，组织中的各个小组分别负责各个模块的幵发。在小组内部需要有非常便于沟通 的机制：需耍频繁地共享大量以详细设计决策的形式山现的信息。在各个小组之间，需要进行的沟通就没有这么多了，但这种沟通也是很关键的（Fred Brooks认为，如果不认真管 理小组之间进行沟通的开销，可能会使项目开发陷入困境）。当然此时假定了系统在设计 时已经进行了合理的问题分离。
如果不能满足这些设计标准，系统就会非常复杂。实际上，开发小组的结构和对小组 间交流的控制就是影响大型项目幵发成功与否的重要因素。如果小组间的交流确实比较复杂。那就意味着这些小组所要开发的元素之间的交互过于复杂，或者是在开发之前没有充 分明确对这些元素的需求。在这种情况下，不仅需要在小组内部进行大量的交流，而且在 小组之间也需要频繁进行交流。这要求进行大量的协商，而且经常需要重新确定元素及其 接口。像软件系统一样，开发小组也应该努力做到松耦合、高内聚。
为什么开发小组的结构反映了模块分解结构？信息隐臧原则——系统模块分解结构 的设计原则——要求各个模块把可能发生变化的细节封装起来或隐藏起来，即要建立删除掉可变细节、向其用户（这里就是该系统的其他模块）提供公共而统一的服务集的接口。 这就意味着每个模块都构成自己的小领域：在这里我们使用“领域"來指某一专门知识或 专门技术领域。这有助于小组和分解结构的模块间自然地达到一致，如下面的示例所示：
•该模块是系统的用户接口层。它提供给其他模块的应用编程接口独立于用来向用 户提供信息的特定用户接口部件（单选按钮、拨号盘、对话框等)，因为这些部 件可能会发生变化。这里的领域就是这类用户接口部件的集合。
• 该模块是隐藏了可用处理器数量和调度算法的进程调度程序。这里的领域就是进 程调度和各种合适的算法。
•该模块是A-7E系统构架（参见第3章）的物理模型模块。该模块把用来计箅物
理环境的某些值的方程封装了起来。这里的领域就是数值分析（因为必须实现这 些方程以保证在数字计算机上运算的足够准确性）和航空电子学。
把模块看作是极小的领域使我们认识到，充分发挥各位开发人员的能力的最有效的办 法就是根据他们的专业特长进行合理的安排。只有模块结构允许这样做。下面的引文中将 会讲到，开发组织有时会添加独立于构架结构的专门小组。
幵发姐织对构架的彫响更为微妙，但它与构架对开发组织（即构建该构架所描述的系 统的群体）的影响一样重要。假设您是某个数据库应用系统开发小组的成员，被分到为某 个设计应用程序构架的小绀中。则您很可能会把面临的问题看成是一个数据庳问题。考虑 应该采用什么样的数椐库系统或是否应该自己构建一个数据库系统，或假定数据访问是以
査询的形式进行的等问题。因此，您主张对数据存储与管理、査询的形式及实现等问题分 别采用各种不同的子系统。电信小组的成员则从电信的角度看待该系统.对于这个人来说， 数据库（很可能对之不感兴趣）只是一个子系统而已。
第1章讨论了组织方面的问题、以前的经验以及采用或幵发某些技巧的愿望将会如何 影响构架，上面的场景就是这种影响将会如何体现出来的一个具体的例子。随着组织在某一领域开发工作的继续进行，就会形成作为进一步承揽业务的手段的-些制品，且会有专 门的小组对这些制品进行维护。我们将在第14章和第15章讨论这一问题。
7.4创建骨架系统
对构架进行了充分设计，并且团队为开始构建构架做好准备后，就可以构造骨架系统 了.这-阶段的思想是提供一种基本能力，以-种对项目有利的顺序实现系统的功能。
经典的软件工程实践建议把代码的各个部分淸晰地区分开來，以能够分别添加系统的 各个部分和对系统进行独立测试。然而，应该把哪些部分独立出来？如果以构架做指导， 实现顺序就比较消楚了。
首先，实现处理构架组件的执行和交互的软件部分。这可能要求生成实时系统中的调 度程序：实现规则引擎（带有规则的原型集）以控制在基于规则的系统中规则的激发：实 现多进程系统中的进程同步机制或客户机/服务器系统中的客户机/服务器的协同。通常请况下，基本交互机制是由第三方中间件提供的，在这种情况下任务就变成了安装而非实现。在该通信或交互基础结构的顶层，您可能希望安装最简单的功能，这些功能只是激起一些固定的行为。这时，您就拥有了一个运行系统。这为添加有用功能提供了基础。
现在，可以选择把提供功能的哪些元素添加到该系统中。这种选择可能是根据以下因素做出的：首先处理问题最多的部分来降低风险；或现有幵发人员的类型和水平：或尽可能快地将有用的产品推向市场。
选择了提供下一个功能增量的元素后，就可以采用使用结构（第2章)，以获知应该 在系统中采用什么软件來支持该功能（与占位符相反)。
随着该过程的继续，系统的增量越来越大，直到软件幵发完毕。在任何时候集成和测 试任务都不会很多，在每个增量中都很容易找到最近引入的错误的源。用较小的增量进行开发时，预算和进度的可预测性更强，因此，管理和市场营销活动更容易进行。
甚至区分幵来的代码部分都有助于为系统幵发的完成铺平道路。这些占位程序都遵循 最终系统所要求的相同接口.因此，即使缺乏高宝真的功能，它们也有助于理解和测试组 件间的交互。这些占位程序组件可以用两种方式模拟这种交互：产生硬编码的无创造性的 输出（真实编码的预定输出），或者从某个文件中读取输出。它们还可以对系统生成--个综合负载，以估计在已开发完成的工作版本中实际处理所需要的时间。这有助于在早期理 解系统性能需求，包括性能交互和瓶颈。
根据Cusumano和Selby所说，演变交付生命期是微软公司所采用策略的基础。微软 公司在使用这一方法时，在产品开发的早期阶段创建“完整的"骨架系统，并且频繁地（经 常是在一夜之间）重新创建出能“工作”但又与最终系统有差距的系统。这种做法的效果不错，可以得到一个工作系统，并且随时都可以认为这个工作系统的特性己经足够了，然 后推出该产品。但问题是，第一个完成该系统的某个部分的开发小组要对接口做出定义， 而随后开发出的所有子系统都得符合这个接口的耍求。这实际上将对系统比较复杂的部分 不利，因为它们需耍进行更多的分析，因此不太可能先对其接口做出定义。这将使复杂的 子系统更加复杂。所以，我们建议首先对骨架子系统中的接口进行协商，然后再运用骨架 系统来提高开发效率。
7.5小 结
构架设计必须按需求分析进行，但不需要在需求分析完成后再开始构架设计。实际上, 在确定了关键的构架驱动因素后，就可以开始构架设计了。当设计了构架的足够多的部分 后（再次说明一下，必要等到构架设计完成时），就可以开发骨架系统了。该骨架系统是 在上面进行迭代开发（以及其在任何一个点交付的能力）的框架。
第4章和第5章讲述的质量属性场景和战术对构架设计非常关键。ADD是一种自上 而下的设计过程，它使用质量属性需求来定义适当的构架模式.并使用功能需求来实例化由该模式给定的模块类型。
构架通过确定所必需的通信路径.确定了某种级别的组织结构。现有的组织结构通过 为组织部门提供专门技术和既得利益，同样也对构架产生了影响。
7.6可进一步参阅的文献
[McConnell 96]将演变交付生命期作为软件开发生命期模型中的“一流”模型进行了说明。 其目的是支持具有上市时间压力且产品的功能具有不同优先级的组织，因为它能够 组织将产品的任何一次迭代发布出去。当与骨架系统的构造结合在一起，并关注使用结构时，就可以实现某次产品发布中的特性，以最大化对市场的影响„
Christopher Alexander关于构架（建筑型）设计模式的开创性工作奠定了软件设计模
式工作的基础。其著作[Alexander 77]是了解和学习设计模式的必读之物。（这些书对于建筑也有帮助。）
关于软件设计模式，最常提到的作者是所谓的“ 四人帮”[Gamma 95]。[Buschmann 96]
将一组构架样式编档为设计模式，从而把这两者联系了起来。
[Brooks 95]是所有软件工程师的必读参考书，该书的修订版对基于构架的迭代开发的优点进行了讨论，特别是还以微软的实践为例进行了阐述。
[Bosch 00a]提供了一种不同于ADD的构架设计方法，该方法首先考虑划分来实现功能，然后转换该划分以实现其他质量属性。
[Kruchten 00]对Rational统一过程进行了描述。[Cusumano 95]对微软的开发实践进行了详细描述。
7.7讨论题
⑴构架影响着负责开发各模块的开发小组，而所开发的这些模块组成了构架。通常反映在开发小组中的构架的结构是模块化分解。如果以构架层次上的其他常见结构（如进程结构）作为开发小组的基础，优缺点是什么？
（2）ADD提供了一种“粘连”需求的方法。构架驱动因素得到了满足，还必须在为这些驱动因素开发的设计方案的环境中满足其他需求。对分解设计策略来说，还有什么其 他的粘连方法？为什么不能用一个分解满足所有这些需求？