软件架构受涉众所驱动

    正如在早期的章节里所描述的，一个构架满足许多涉众的需求。因此架构的过程必须适应所有这些涉众，以确保他们的关系——特别是那些极有可能对软件构架产生影响的——能够被了解，被阐明，能够得到协调及有效的处理，也有必要将相关的涉众融入到对这些关系处理的每一次复审之中。

    在架构过程中不应低估适应所有涉众所付出的努力。涉众影响着架构过程的许多方面，包括集中需求条件的方式，构架的文档记录样式以及构架的评估方法。

    软件架构经常需要做出折衷

    假定给出影响软件构架的诸多因素，很显然软件架构过程需要做出折衷。通常情况是在需求中做出权衡，同时也要考虑涉众来帮助做出正确的折衷。一个折衷的例子就是性能价格比：添加更多的问题处理能力会增加性能，但是要以成本为代价。这可能代表一个需求的冲突，假设架构师已经努力地找到所有可解决方案，这就是一个要由有需求冲突的涉众来解决的问题。

    另一种折衷体现在解决方案上：例如，用一种技术代替另一种技术，或是用第三方的部分代替另一方，或者甚至用一组模式来取代另外的一组。作出折衷无法避免，也不应避免。构架师的一项工作就是考虑可选择的方案并在它们之间作出折衷。

    软件架构受益于过去的经验

    架构师们很少“白手起家”。正如前面提到的，他们积极地寻找已经汇集成册的经验，包括架构模式、设计模式以及已经成形的部分等等。换句话说，架构师努力获取那些可再度利用的资源。只有那些最无知的架构师才放弃考虑过去的经验。

    当问题重复发生时，可重复使用的资源就是解决方案；可重复使用的资源就是一种在重复使用时已经在脑海中得到提炼的资源。
    一个软件构架中的元素可以在当前系统的前后关系里再度使用，与此同时，一个架构师可能也已经将其构架或者其中的一些元素作为可再度使用的资源，用于当前系统之外。

    软件架构既是自上而下也是自下而上的

    许多软件构架是按照自上而下方式来设计的：1）在定义构架之前掌握涉众需求并加以研究；2）设计架构元素；3）实现这些元素。尽管如此，一个软件构架很少完全按照这个自上而下的方式进行架构，普遍情况是采取相反的方式，从已经创造出来的实现软件中汲取教训，比如说概念论证。在某种程度上，软件构架按照自下而上的方式是由于指定的设计或实现方案的约束，在这种情况下这些元素是给定的，软件构架必须适应它们。例如，约束可能是设计将在现在系统上使用关系数据库或者接口。

    成功的架构师们承认，架构的方法是必要的，并且他们的软件架构是按照自上而下和自下而上两种方式创建的。这可以被认为是“中间的”架构解决方法。

    结束语

    这篇文章重点说明的是软件构造过程的主要特征。

    致谢

    这篇文章的内容来源于一本即将出版的新书，暂时叫做“软件架构建立过程”。最后，我衷心的感谢对内容提出宝贵意见的人们，他们是Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Holger Heuss，Kelli Houston，Luan Doan-Minh，Philippe Kruchten，Nick Rozanski，Dave Williams，和Eoin Woods。

    注解

    1IEEE Computer Society，强软件系统的架构描述的IEEE推荐实践：IEEE 标准 1472000，2000。

    2 Bran告诉我，他为Philippe Kruchten将这张图画在了餐巾纸上。

    3 取自“Reusable Asset Specification”， 对象管理组织，文档号 04-06-06，2004年六月。