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

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

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

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

　
　　　　　　　　　　　　　　　　　　　　　图1：软件架构相关术语的模型

图1中阴影框里的元素直接来自于IEEE标准1471，它们之间的相互关系阐明的是一个系统及其构架的诸多特征：

• 一个系统有一个构架。
• 一个系统完成一项任务。
• 一个系统存于一个环境中，并受这个环境的影响。
• 一个系统有一个或多个涉众。
• 一个构架对应一条构架描述。
• 一条构架描述识别一个或多个涉众。
• 一条构架描述识别一条或多条关联。
• 一条构架描述提供理由。
• 一个涉众有一条或多条关联，一条关联对一个或多个涉众都很重要。
  
  图1中另外那些不是来自IEEE标准1471的元素和相互关系，显示在非阴影框中，可描述如下：
  
• 一个团队组负责一个开发项目。
• 一个开发项目遵循一个开发流程。
• 一个开发项目交付给一个系统。
• 开发流程包括软件架构。
• 项目组里包含一个架构师。
• 架构师负责软件架构。
• 架构师是涉众中的一种。
• 架构最终得出一个软件构架。
• 架构师创造出软件构架。
• 软件架构是一门科学

虽然软件构架是一门新生事物，但它已被公认为一门学科。而随之而来的是将重点放在使软件架构过程日趋成熟的技术、方法和资源上。推进这一趋势的方法之一就是利用现有的知识体系。概括地说，就是架构师们在开发一个新的构架时寻求已经通过检验的解决方案，而不是重蹈覆辙，将以往的软件构架、构架设计模型以及其他一些可再度使用的元素中可以借鉴的经验汇集成册。

尽管如此，软件架构过程要想在任何地方都和土木工程的架构过程一样成熟，仍有一段路要走。这种成熟可以体现在很多层面上，包括标准的运用，对最佳实行方案、技术以及方法的理解上。因此，基于这一点，一个架构师的经验对于一个项目的成功有很大的影响。

软件架构是一门艺术

尽管软件架构被认为是一门科学，但有些时候具备一定的创造力是十分必要的，在处理一些从未见过的奇特的系统时这一点就尤为重要。在这种情况下，可能没有成形的经验可以借鉴。就如同一个画家在面对一张空白的画板时需要灵感一样，架构师们有时会视他们的工作为一门艺术而不是一门科学。当然在很大程度上，软件架构的艺术层面是很小的。即使是面对一个极为新奇的系统，通常的做法也是借鉴别处的解决办法，处理之后使其适应用这个系统。

随着软件架构过程日渐成为主流，它极有可能不再被认为是只有“被挑出的极少数人”可以理解的一系列神秘的实践行为，而是一系列被广泛接受的、建立在科学基础之上的、定义明确并通过检验的实践行为。

软件架构跨越很多学科

在软件开发过程中架构师需要涉及许多学科。架构师涉及最多的学科是软件设计，尽管如此，架构师也很关注其他的一些学科。例如，在需求分析里，架构师要确保对于利害关系的需求条件尤为了解，同时也懂得区分这些需求的优先次序。架构师参与实现工作，他们详细地说明用来组织源代码以及可执行的工作产品的实现结构。架构师们还参与测试工作，确保架构结构具有可测性并能通过测试。架构师负责开发环境中的一些特定元素，特别是建立一些特定的指针。架构师们还帮助制定配置管理策略，因为配置管理结构（用来支持版本管理的）经常影响已经定义好的软件架构。架构师与项目管理人紧密合作，正如这个文章系列中的第二部分所提到的，架构师已经成为项目计划中的一员。

当谈及软件架构的范围时，我需要提到架构和设计的关系。尽管架构师尤为重视设计学，但并非所有的设计都可以认为是软件架构。因为一个架构只是关注那些十分重要的元素，而并不是所有的设计元素都对架构有重要意义。例如，用户界面屏幕的详细设计通常认为对架构没有任何意义，最好是留给用户界面设计者来完成。这种思路同样应用于其他的系统元素，例如那些支持业务逻辑或数据逻辑的元素。架构师只在必要时加以限制，而许多设计方面的决策都是留给设计者们来完成的。

架构是时刻进行的行为

经验表明，软件架构并不是在项目初期一蹴而就的事情，而是贯穿整个项目的始终。在整个项目里，通过交付给可执行软件的一系列迭代递增的程序，软件架构也日趋成熟。在每一次交付过程中，软件构架都会变得更加稳定完善。这就很好地解释了什么是架构师贯穿项目始终的重点。

成功的软件架构行为是以结果为导向的。因此，架构师的重点会因预期结果随时间变化而变化。这一点如图2所示，图2由Bran Selic绘制。

　　　　　　　　　　　　　　　　　　图2：随时间变化的工程重点

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

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

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

软件架构受涉众所驱动

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

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

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

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

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

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

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

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

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

许多软件构架是按照自上而下方式来设计的：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。

注解

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

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

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