软件架构的过程

软件架构被公认为软件开发领域的一门新兴学科。作为软件架构系列文章的第三篇，本文描述的是在软件工程的生命周期里软件架构师正在进行的各类活动。

　　在这个系列里，我的 第一篇文章描述的是什么是软件架构， 第二篇文章 讲述软件架构师这个角色的特征。第三部分是建立在以前讨论的基础之上，而且所考虑的主题或者特征都是在软件架构过程这个框架下。

软件架构活动：定义及范围

　　根据IEEE标准，软件架构活动代表了

　　这样一系列活动：定义、记录、维持、改进一个软件构架并确保其正确执行。

　　软件架构的范围相当宽泛。图1展示的模型详细地说明了软件架构过程的各个方面。这个模型来自IEEE标准1471，架构师所关注的软件架构各个方面都可以此模型作为参考。

　　图2表明，在工程早期，架构师着眼于发现，重点是理解系统所涉及的范围并识别其主要特征及所有相关的风险——所有的要素对软件构架都有显著的影响。然后重点转向创造，主要是开发一个可以为整个实现过程提供牢固基础的稳定的构架。最终，重点放在了实现上面，这个时候大部分的发现和创造开始起作用。

　　应该注意到，发现、创造和实现并不是严格按顺序来的。例如，随着架构模型的建立，在项目早期会有一些实现过程。而随着过程的深入理解和实现架构中某些元素的不同策略的提出，在项目后期将会有一些发现。

　　请记住，直到系统交付架构过程才被完成，因此，架构师必须一直关注软件构架直至项目结束。一旦一个项目的软件构架稳定下来，人们总是希望架构师离开这个项目，将这一珍贵的资源用于其他的项目。然而，直到项目后期仍有一些架构方面的决策需要制定。实际上，还有介于两者之间的情况，一旦影响软件架构的重大决策制定出来，架构师就成为项目组中的一名兼职人员。不管怎样，架构师不应该完全脱离这个项目。当然还有一种更加灵活的情况，那就是由一个团队来履行架构师这个角色，这个团队里的一些成员可能去参予其他的项目，而另外一些则留下来继续确保这个系统架构的完整性。

软件架构受涉众所驱动

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

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

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

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

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

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

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

　　当问题重复发生时，可重复使用的资源就是解决方案；可重复使用的资源就是一种在重复使用时已经在脑海中得到提炼的资源。

　　一个软件构架中的元素可以在当前系统的前后关系里再度使用，与此同时，一个架构师可能也已经将其构架或者其中的一些元素作为可再度使用的资源，用于当前系统之外。

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

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

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

结束语

　　这篇文章重点说明的是软件构造过程的主要特征。下个月的文章是软件架构系列文章的最后一篇，其重点放在将软件构架作为IT基础资源的益处上。

致谢

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

注解

1 IEEE Computer Society，强软件系统的架构描述的IEEE推荐实践：IEEE 标准 1472000，2000。
2 Bran告诉我，他为Philippe Kruchten将这张图画在了餐巾纸上。
3 取自“Reusable Asset Specification”， 对象管理组织，文档号 04-06-06，2004年六月。

来源：技术专家