第一章

 

就在同一时期，其他的相关研究也正逐渐起步。这些研究的目的是试图从那些非正式、

 

不标准的经验知识中，提炼和组织出构造软件架构可利用的、相似的问题解决手段和设计

 

风格。这样，研究的成果就可以被不同的领域、在解决相似的问题时所重用。这些研究都

 

是针对当时一些著名系统进行分析和总结的，试图识别出那些通用的系统架构风格和设计

 

手法。其中，由Gregory Andrews领导的研究小组，分析和识别了很多不同类型系统的架

 

构形式；由Robert Allen和David Garlan领导的研究小组，尝试找到和应用一些通用的方

 

法来描述不随型的系统结构。他们的不懈努力最终奠定了后人前进的基石。1992年以后，

 

后人在他们研究成果的基础上，完善和建立了一些著名的系统架构风格，例如：pipe-filter

 

架构风格、repository架构风格、隐式调用、流程协同等。他们的研究成果和基础思想，直 到今天还被很多文章引用。

 

架构基本概念和模型的确立它是以五个方面的长足进展为标志的：架构推述语言的发展、 初步的架构表述及分析规則的制定、架构元素及架构风格的分类研究、架构的评估方法（例 如SAAM)、可借鉴的架构视角（例如4+1视角）。处于这个阶段的人们下意识地把主要

 

的精力放在了所有软件系统结构中可能具有的共性方面。希望通过总结性的研究，发现那 些在实践中反复出现的、具有共性的结构；并且能够把这些发现以比较严格的逻辑和规则 统一描述出来，以方便业界同行的交流、改进和重用。

 

Redwine/Riddle模型表明，在概念确立阶段还需要不断地提炼和完善所研究问题的结 构。架构评估技术和方法就是在这个时期应运而生的。早期的架构设计人员通过自己长年 的实践经验意识到：要设计一个架构，并检验该架构的有效性，一般是先明确该系统在质 量方面的要求（即要解决的问题)，然后从众多候选问题的解决方法中选用最适当的方法， 这样的过程就是后来架构领域经常提到的一个用语一 “设计决策”。只有系统在质量方面 的要求与设计决策完全对应起来，才能确保该系统架构是有效的。所以该时期出现的一些 常用方法有：Richard W. Selby与Ronald Reimer提出的衡量大型软件系统内各个部件互 联关系的标准；AT&T公司提供给架构师的检查列表；C.Smith提出的基于系统的不同属性 要求（例如性能要求）而可以采用的架构分析评估方法等。综合上面这些经验，R.Kazman 等人在1994年汇总形成了更为通用的架构评估方法SAAM (Software Architecture Analysis Method)。

 

概念确立阶段的最后的一个重要实践总结，是为后人发扬光大的“架构视角 (Architecture View)” 概念。其实，早在 1974 年，D. L. Pamas 在《On a “buzzword”: hierarchical structure》一文中就已经为架构视角的研究开创了先河。他在对众多软件系统 进行研究后提出了自己的成果：不同的软件系统运用不同形式的结构来构建和表述，是因 为不同的构建形式能够满足不同的工程需求和目标。之后，架构视角的研究本身也经历了 自己完整的Redwine/Riddle周期。期间出现了众多高质童的研究结果，当中最著名的是 P.Kruchten在1995年提出的“4+1”视角，他为以后的架构实践莫定了坚实的基础。当 今设计领域经常应用的那些UML视图，就是一个很典型的例子。

1992年至1996年期间，国际上开始组织众多国际会议（例如软件设计国际大会）， 明显地完成了 Redwine/Riddle模型中概念确立阶段的职能：沟通基本思想和概念并形成统

 

技术完全稳定下来，这为1998年后架构技术的大规模工程应用奠定了基础。Len Bass、 Paul Clements、C.Hofmeister及R.Nord等人都纷纷在这个阶段把架构的理论投入到实践 中。他们面对不同类型的真实系统，严格应用和校验了架构前期发展的结果。后来发表的 —些研究结果，代表了他们为架构领域成熟做出的重要贡献。同时，前期总结提炼出的种 种系统架构风格(Architectural Style)也演化成了真正意义上的系统架构模式(Architectural Pattern)。架构模式与设计模式（Design Pattern)结合在一起，实现了系统设计上比较严 格的高低层次搭配。

 

同期，软件架构领域内的系统及架构分析与评估也逐渐走向了完善。例如：Robert Allen 与David Garlan的研究，大量地集中在针对一些真实系统的架构设计所进行的正式而全面 的分析，从而试图识别出系统髙层架构、设计方面与功能、质量要求不一致的方面，从而 避免了系统实施阶段的大量设计修改。SEI的R. Kazman在1994年最早提出的架构评估 方法SAAM,经过5年的实践检验，在不同领域、不同系统中得到了锤炼（例如SAAM方 法曾经在美国国家航天局的一些软件项目中得到了宝贵的实践经验)，并最终在1999年成功演化为业界备受推崇的软件架构分析及评估方法ATAM (Architecture Tradeoff Analysis Method)。最终，P.CIements 在 2001 年提交的研究结果，与 P. Clemente 和 R. Kazman 在2002年发表的论著，成为这个时期系统及架构分析与评估方面成熟的标志和里程碑。 这两个重要的研究成果,是基于当时p. Clements和R. Kazman分别选定的一些业务领域， 针对该业务领域内的一些生产运行系统或正在开发的新系统进行的分析评估，从而总结出 的架构评估实战经验，为后人提供了难得的架构设计与分析指导。

 

在1996年至2003年这个软件架构技术从理论走向实践的重要阶段，为了使工业界的 系统架构与设计活动能够完全符合系统质量所要求的属性，研究人员付出了巨大的努力， 并逐渐在实际应用过程中总结了一些比较全面的经验。Mario R.Barbacci在1996年就己经 认识到了分析和评估系统质量的需求对所设计系统的重要性；他力图通过系统化的方法分 析出质量的要求，并且以此为依据对构建的软件架构进行评测，从而能够科学、系统地使 所进行的架构设计满足质量上的要求（例如系统性能上的需求、可修改性的需求等）。出于近乎相似的目的，Felix Bachmann经过几年的探索和实践，在2003年发表的研究结果中 提出了一系列架构模式。这些模式都是一些有助于实现系统质量的要求而可采用的典型的 战术性手段，即后来所谓的架构战术手段（Achitectural Tactics),以便其他设计人员能够参考他提出的分析和决策模式，方便地从众多架构设计方法中进行抉择，使选择的架构能 够真正满足质量上所要求的特征。

 

软件架构经过1996年至2003年的内部改进和拓展阶段，发展到21世纪初的今天， 己经初步具备了系统设计自动化的模型：即有效地分析和评估质量要求、有效地将质量要 求关联到架构的战术手段、有效地分析和评测所设计的架构的有效性（是否满足质量上的 要求）。这是一个软件架构界的梦想，我们距离梦想成真越来越近了。

 

5.外部改进拓展阶段（1998年至今）

其中，架构风格这个软件架构家族成员的暴风式地普及并商业化，就是最好的一个例 证。当然，它得益于2000年以后迅猛激增的World Wide Web和电子商务的商业推动力^ 经历了 15年的沉淀，架构风格的研究成果如雨后春笋一般出现，它们都成为市场上抢手的 技术：N层的客户端/服务器架构风格、基于代理的架构风格、面向服务的架构风格（SOA)

 

在软件架构技术普及应用阶段的另外一项重要任务是：使已经产品化的新技术能够逐 步地标准化。在架构技术兴起之前，计算机工程界就已经为构件和接口的重用而进行了标 准化工作（例如COM、CORBA、XML等h但是这些特殊构件级的标准化，还不能算是 架构技术的标准化。2000年，ANSI与旧EE总结规范了先前的最佳实践，联合推出了 “大 型复杂软件系统的架构描述”标准，试图推动架构技术在应用领域的规范化和重用能力。 同时其他一些标准也相继出现，其中2005年由SAE (Society of Automotive Engineers) 推出了 AADL(Architecture Analysis & Design Language)这种所谓的“纯架构描述语言”, 作为架构领域的标准。

 

从2000年至今这个架构技术大规模普及的阶段，同时出现了一些很有趣的现象。很 多人根据自己的经验和概念而冠名了许多新的术语。比尔•盖茨就把自己叫做微软的“首 席软件架构师”（当然，他在微软可以随便给自己任何头衔)。OMG组织把自己推出的架构 设计与系统开发的理念冠名为“以模型为驱动的软件架构”-MDA (Model Driven Architecture),它其实就是把商业和应用逻辑的分析和建模，与实现这些逻辑的具体平台 技术割裂开，最终形成一定程度上的模型与实现技术的自动转化。SEI这个著名的学术机 构，发起了一场有趣的活动：为“软件架构”这个词进行定义。截止到2005年，共有来 自24个国家的架构从业人员提交了 156个定义，可见公众对架构技术的热情和参与度。 当然，普及和热情也导致了这样的现象出现：一些人根据个人的理解、经验和兴趣发明了 形形色色每诞的术语了爾如“程序架构师”（Program Architect)，真是让人匪夷所思。

 

如果放眼这个时期的学术界，同样出现了很大的改观。先前的大学里，一般只可能在

 

很明显，从上述这些问题中，我们似乎看到了一个架构从生成、进化、老化到消亡的 过程的影子，如同宇宙万物，架构似乎也存在一个生命周期的概念。笔者借鉴了经典的“倒 浴缸（Revise-BathtubCurve)”模型，在探索架构发展和演化的规律基础上，正式提出了 “架构生命周期（Arch丨tecture Lifecycle)”这个重要概念！

 

把握共同的规律、预知未来的发展、选择最佳的路径，尽可能减少成长的烦恼，尽可 能保持成熟的稳定，让软件研发企业充分享受到属于架构整个生命阶段的华彩，正是研究 架构生命周期的目的之所在！

 

为便于分析’我们将架构生命周期划分为如下5个阶段：架构初步构建阶段、架构逐 步优化阶段、架构成熟阶段、架构老化阶段以及架构消亡阶段，如图1-10所示。

图1-10中需要特别指出的是，在单一产品架构发展的过程中，架构可能会进化到更高 境界的一个层次，那就是产品线架构。随着单一产品架构的消亡，产品线架构横空出世， 生命即将在更高层次演奏出更加华美的乐章。

 

完整的架构生命周期（Architecture Lifecycle),这将是本书的核心思想’也将成为下 述各个章节讨论的主线。本书第4章“软件架构与设计流程”其实就是在谈架构初步构建阶段的核心要点；本书第5章“软件架构及软件质量”、第6章“软件架构的评审”所涉及 的内容都是在谈架构逐步优化阶段的各项任务及最佳实践；本书第7章“软件架构的恢复 与重构”主要探讨架构老化阶段以及架构消亡阶段所发生的各种可能情况。本书第8章“软 件产品线架构”则会升华到架构的另一个生命周期——产品线架构！