本书给出独立于任意特定工程过程或组织成熟程度的软件体系结构设计方法，为软件体系结构设计师提供做出软件体系结构决策和建立有效软件体系结构所必需的信息和工具。本书包括方法、设计表示及模型、技术（如面向对象和面向组件的技术）、参考模型、体系结构框架、分析、设计、体系结构模式等方面的透彻介绍和应用。
本书不仅适合大型软件系统的体系结构设计师使用，而且特别适合较小、不太成熟的软件开发组织的体系结构设计师使用，同时，本书也可作为对软件体系结构设计感兴趣的广大读者的参考读物。
无
软件体系结构常常与低层设计和技术堆叠相混淆。技术供应商与流行的以技术为中心的杂志往往又传播了这种误解。结果，许多软件工程师生成的所谓体系结构描述只不过是令人反胃的技术层次图。典型的企业应用体系结构通常是所谓的体系结构层次图，它描述一个自下至上从持久层到业务逻辑层（或中间层）再到表示层的体系结构层次。这种表示方法没有传达系统如何处理系统的功能或非功能的需求，它只是显示所使用的技术以及这些技术如何集成。
我们做一个试验，假定应用程序体系结构的层次直接映射为具体的技术：表示层由Java Servlets和Java Server Pages（JSP）组成；业务层由Enterprise JavaBeans（EJB）组成；而持久层为一个关系数据库管理系统（RDBMS）。对于某些简单的系统，在体系结构层次与具体的技术之间存在一对一的对应关系。但在系统功能更为复杂时，这种假定就成了谬论。表示逻辑可能不仅由Java Servlets和JSP组成，而且还由EJB和存储在关系数据库中的数据（如用户设置）组成。业务逻辑可能不仅由中间层EJB对象组成，而且还由存储过程和数据库触发器以及其他组件技术（如业务规则引擎和工作流引擎）组成。
本人曾经不得不重新设计一个系统，该系统具有的惟一体系结构描述只是这样一种技术堆叠。它描述作为一种建立中间层应用编程接口（API）的灵活途径，怎样在Java Servlets和Enterprise JavaBeans之间传递可扩展标记语言（eXtensible Markup Language，XML）文档。但是，关于该系统怎样由一个主要的业务逻辑子系统、一个安全子系统和一个报表子系统来组成却什么也没说。它只讨论XML文档怎样与关系数据库的表互相映射。这个项目的工程师通常在白板上绘出包括这三个子系统以及其他几个功能模块的系统图。事实上，这些都不是模块。它们之间不存在间隔或分离问题。报表模块由某种从数据库表中查询数据的用户界面代码组成，而系统的其他功能也对这些数据库表进行操作。安全逻辑只是系统的一个方面。系统并不存在可辨别的安全模块，安全逻辑嵌在遍及系统的许多对象中。开发机构围绕表示层和其他东西构造系统，将用户界面当做一个真正的模块。结果，生成的系统难于开发和维护，相应的成本也高。
软件体系结构设计需要从多种视点进行系统设计。软件工程中采用的常见视点为：技术堆叠（或物理）视图、对象（或数据）模型和用例（或行为）视图。这些视点是有用且必要的，因为它们覆盖了许多类型的设计决策，反映了诸如功能、信息和物理结构等许多系统质量属性。但它们不反映系统的许多其他的重要质量属性，如可修改性、可建造性、安全性、可靠性、性能，也不反映非操作性的或面向业务的质量属性，如减少开发和维护成本的能力。
用这种单一的以技术为中心的视图来表示一个体系结构的问题在于，我们只看到了多维系统的一个垂直面。许多的体系结构决策不能用该视图来表示。如果这是我们所建立的惟一视图，则我们可能忽略了针对系统不利之处的其他视图。
一个常被忽略的体系结构视点是一个系统的组件或子系统视图。根据定义，系统是相互协作的组件的集合。若不用这个视图，整个系统似乎是一个单一的模块，尽管工程师会谈论安全子系统或报表子系统。在白板上绘制几个方框或箭头很容易，但如果这些方框和箭头不代表什么东西，我们就不应该为它们操心。
一个模块具有清晰的接口，其他模块可以导入这个接口。模块内部可以随意改动。Java数据库连接（Java DataBase Connectivity，JDBC）驱动程序就是一个例子。应用程序依赖于公布的JDBC Java接口。许多供应商都进行了实现，但他们的实现全都遵循相同的接口，因此可以被替换。如果不对其他元素进行改动，一个代码元素就不能用另一实现替代，则该代码元素就不是一个模块。使一个系统模块化的东西是在模块之间以及设计和实现这些模块的开发小组之间共享的相对少量的信息。把整个系统当做一个单一的模块只会使开发人员和管理人员感到灰心。
在上面的系统中，系统最初的一个分解是把报表系统与操作（或事务处理）系统分离。结果很好，特别是这个分解很简单。系统分解后，不再存在针对操作表进行查询所带来的性能问题，不再有操作和报表互相缠绕的用例，系统更容易开发和维护。事后来说，把系统分解成这样两个模块似乎是很显然和很平常的。但是，如果没有人从这个视点看待系统，就不那么明显了，所导致的问题会是很大的。这个小小的设计决策甚至可被表示成一个软件体系结构模式：将操作数据与分析数据分离，使两者松散耦合，从而可以独立地设计、开发和维护它们，这样系统可能具有更好的性能。
软件体系结构是软件开发的一个新学科，它是针对软件系统及软件系统要解决的问题的复杂性不断增加而出现的。软件正在成为许多系统的主要成分，因此，很有必要建立新的准则、原理和标准，使我们能以某种方式应对不断增加的复杂性。
关于怎样改善软件危机状况，一直存在着许多观点。一种方法是提高软件开发过程的质量。在这种学院式的想法中，认为可以利用迭代开发技术、快速应用开发（RAD）工具、频繁的集成和测试来改进质量，并且保持详细记录以便建立一些历史数据，用于在未来的产品周期中改进软件开发过程。它使用迭代/增量开发过程，如Rational统一过程（Rational UnifieProcess）和能力成熟度模型（Capability Maturity Model，CMM）等。提高软件质量的另一种方法是不采用极为面向计划的过程，而是采用敏捷过程并利用诸如RAD和极限编程（XP）等技术。
大多数充当软件体系结构设计师角色的软件工程师都很少或者从来没有受过软件体系结构学科方面的培训，这主要是因为现在还没有建立良好的理论或标准的大学课程。从未经过培训的软件编程人员从试验和挫折中获得了编程技巧，但大量原理、模式和技术被人们所认知都要经历一个重复发现的过程。从业人员和研究人员已经开始记载软件设计和工程过程的可重用模式。业内积累的这些知识已经作为原理和模式记载在书籍、会议文献和技术杂志中。但是，现在的软件体系结构设计师很少有时间跟踪这些信息，更不用说有足够的时间将其综合进实践知识之中。本书的目的是综合和提取这些信息，以便软件体系结构设计师，特别是新入门的软件体系结构设计师能够填补他们对软件体系结构设计的理解方面的空白。
本书给出独立于任意特定工程过程或组织成熟程度的软件体系结构设计方法。它给软件体系结构设计师提供了进行软件体系结构决策以及建立有效的软件体系结构所必需的信息和工具。本书包括方法、设计表示及模型、技术（如面向对象和面向组件的技术）、参考模型、体系结构框架、分析、设计、体系结构模式等方面的透彻介绍和应用。
没有任何一本书籍可作为软件体系结构设计师的手册。软件体系结构设计的内容既广泛又深入，而且是不断发展的。本书内容主要集中在软件体系结构设计师怎样建立软件体系结构上。书中概述了这个学科及其方法，向读者介绍了本学科的内容范围。鉴于许多软件体系结构的书籍主要集中于过程或基于技术的观点，所以本书内容主要围绕着软件体系结构设计的基本原理、模型、技术来组织。
本书主要集中于软件体系结构设计师必须实践的设计方法和技术。泛泛阅读本书的人不可能成为很好的体系结构设计师；必须应用所学到的知识，以便理解应该怎样使用它们以及怎样最好地应用它们。例如，有效使用面向对象设计的一个障碍是实际定义合适的对象及关系的技能。而UML及面向对象的程序设计语言只能帮助表达设计，而不能帮助建立良好的设计。另一个障碍是解决方案的好坏取决于问题描述的好坏。如果问题描述含混、错误、遗漏，则设计过程就相当于没有输入（“垃圾进/垃圾出”）。
本书的目的
软件开发组织的要求使软件设计人员无所适从。特别是较小的开发组织更是如此，他们没有标准的开发过程，或者没有较多的软件体系结构设计经验。这些组织大约占目前存在的软件组织的70%。这些组织中的大多数不能实施昂贵的方法或采用正式的软件设计规格说明方法，原因很多，如时间或金钱方面的培训成本、支持相应方法的工具成本、宣讲相应方法的时间和个人精力方面的成本、在尽力构造软件的同时引入一种新方法的风险、对有效的软件结构设计过程的实际重要性缺乏理解，等等。软件开发组织需要实施改进软件体系结构的一些实践活动，但不能要求他们一晚上就改变。通常，软件体系结构设计师是导致这种改变的人员。
本书特别适合较小的、不太成熟的软件开发组织（主要进行特殊开发）的软件体系结构设计师。它提供了生成有效软件体系结构的实际指导。它将：
* 提供对软件体系结构基础概念的透彻理解
* 作为获得软件体系结构方面信息以及了解具体思想流派的指路图
* 讲授经典的软件体系结构设计风格、模式、启发方法、方法学和模型
本书的组织
软件体系结构方面的多数著作主要针对软件的结构而不是产生软件结构的设计过程和启发方法。软件模式的书籍在这方面提供了许多帮助，因为它们不仅给出抽象的软件结构，还提供基于这些模式生成体系结构的一些技术。但是，有些东西似乎被忽略了，那就是软件设计的基础，尤其从体系结构的观点来看更是如此。
本书提供了设计方法、过程、实践、启发方法、模式的综合见解，使读者能更好地理解软件体系结构的内容范围，同时本书还对从分析到实现的软件体系结构设计的全过程提供了实际指导。
第1章“软件体系结构介绍”探索软件体系结构的起源。软件设计的基本问题（由软件危机构成）是：软件的开发成本很昂贵，但它的质量通常很低，并且常常推迟交付。软件开发已经经历了几次较小的革命或模式改变，目的是解决这些问题。每种新的模式都引入了新技术，但解决这些问题的方式基本相同。
软件体系结构是一门新兴的学科，它致力于在比程序设计语言更高的层次上进行软件设计。在构造一个软件系统前，根据体系结构设计模型或体系结构描述，可以推导出它的许多质量属性。
第2章“软件产品生命周期”介绍软件体系结构在软件产品开发生命周期中的作用。目前存在着许多软件开发的方法和观点（称为开发生命周期模型）。不同的风险承担者具有不同的观点，所关心的东西也不相同，他们需要看到不同的信息以评估进展和质量情况。体系结构提供了生命周期的另一种视点，这种视点涉及建立一种系统设计，以平衡所有风险承担者所关心的问题。
第3章“体系结构设计过程”给出体系结构设计过程的一种通用模型。一个问题的设计解决方案可能是一个具体的人工制品（如源代码），也可能是一个抽象的人工制品（如高层模型）。软件设计是将抽象的问题描述提炼成可执行代码的一种过程。这个过程的中间产物是对问题解决过程有帮助的一系列模型。
设计是找出或发现问题解决方案的过程。设计方法帮助我们寻找这些解决方案。模型是一种管理方法，控制设计发现的复杂性。模型给出解决特定问题的基本知识，同时抑制可能与问题不相干并且只会干扰设计过程的其他知识。
第4章“软件设计介绍”给出软件设计的基本方法和技术。软件设计可被视为一种心理活动，其中设计人员将设计原理应用于某些问题中以得出解决方案。在一个系统的设计方法学中，我们通常提出多个可能的解决方案以减少项目失败的风险；也就是说，我们要寻找解决方案。第5章“复杂性和模块化”给出复杂性、模块化和设计的体系结构层次概念的精确定义。复杂性是我们打算用软件开发工具和软件开发方法对其加以控制的主要目标之一。如果不加控制，复杂性可能会导致项目推迟交付、超出预算或被取消。复杂性可用事物的互相联系来度量。为了呈现一个系统或过程的复杂性，必须将它分解成多个互相联系的组成部分。我们称这些联系为依赖关系（dependency）。本章给出表示复杂系统的一个基本工具：设计结构矩阵（DSM）。
设计结构矩阵可帮助发现合适的系统模块以及模块之间共享的设计决策（称为设计规则）。
设计要找出解决问题的方案。在第6章“模型和知识表示”中，我们看到，问题和解决方案是系统知识的两种形式。为寻找解决方案，必须了解问题。系统知识具有层次，这个层次从系统的属性类型、这些属性的值、能够产生这些属性值的生成模型、实现此生成模型的物理系统等最基础知识开始。模型是一种手段，用来获取和表示被设计系统的知识。
在第7章“体系结构表示”中，我们学习有关描述软件系统组件结构的问题。软件的经典视图具有相当成熟的建模概念。但没有足以表达多种体系结构风格的标准体系结构描述语言，目前的状况仍然是这样。本章把模型的话题深入到更具体的体系结构表示领域。
第8章“质量模型和质量属性”介绍经典的系统质量属性，并介绍体系结构设计怎样处理它们。理解系统需要理解其质量属性。经典的软件质量属性包括功能性、安全性、性能、可靠性和可修改性等。
第9章“体系结构设计原则”介绍可帮助找出系统组件的特定方法和技术。将设计原则应用在设计方法和技术的范围内。
第10章“应用体系结构风格和模式”给出体系结构风格的概念，并说明它是怎样影响体系结构设计过程的。体系结构风格是从现有系统的体系结构获得的一般化知识。有一个较小的基本体系结构风格集合，从中可以导出某种体系结构。
第11章“理解元模型”继续讨论体系结构模型这个主题。元模型是一个用来建立模型的模型。定义良好的元模型可通过再利用领域知识来帮助发现和建立体系结构设计。参考模型可以是描述领域特定问题分解的元模型。参考模型可以是一个行业标准，如公用仓库元模型、工作流参考模型或软件设计文献中给出的非正式模型。在这一章中，我们将看到在体系结构设计过程中怎样使用元模型。
第12章“建立体系结构描述”给出关于软件密集型系统的描述的IEEE建议准则，Std. 1471。这是一个基于多视图概念的软件体系结构描述的标准框架。
第13章“使用体系结构框架”继续讨论体系结构描述这个话题。在这一章中，给出体系结构的4+1视图模型和ISO的开放式分布计算参考模型（RM-ODP），作为建立一个体系结构描述的特定框架。RM-ODP是一个强有力的模型，它描述体系结构的五个标准视点：企业视点、信息视点、计算视点、工程视点和技术视点。遵照每个视点的元模型，软件体系结构设计师可以建立用各种抽象状态表示系统的一系列体系结构模型。
本书以第14章“软件体系结构质量”结束。第14章返回到设计的体系结构层次的质量这个主题。质量不能在一个系统中测试出来，必须被设计出来。在实际构造系统前，可以评估一个系统的候选体系结构以了解所描述系统的质量属性特征。可以评价软件体系结构的描述，以便能够理解该系统的许多潜在的质量属性，其中包括可修改性、性能和可靠性。每个质量属性都可以利用不同的评价技术来评价。
本书的读者对象
新的软件体系结构设计师往往都是有经验的软件工程师。但是，软件工程师开始在体系结构层次上设计软件系统时，必须对头脑中的模型做一些转变。他们以前关于面向对象程序设计的知识仍然可用，但必须在不同的程度上使用，即在不同的抽象层次上使用。本书对于理解怎样设计一个软件系统，甚至怎样设计一个模块都是很有用的。这些设计原则可以应用于软件设计的许多层次。有经验的软件体系结构设计师会找到拓宽其知识面、给他们提供软件体系结构设计新鲜观念的新素材。
技术管理人员将会更加了解软件体系结构设计过程、体系结构风格及生成它们的技术。这使得管理人员能更有效地建立项目组、项目计划、项目进度，并且实施计划重用，进行设计审查，选择合适的过程框架。体系结构、组织、过程是相互交织在一起的。系统的体系结构会影响实现该系统的组织及过程的结构。技术管理人员还会了解到：一个系统的体系结构能够满足许多与业务和发展有关的需求。
读者应该具有下列一个或多个方面的经验（取决于读者想从本书中学习什么）：
* 用诸如C++或Java等语言进行面向对象的程序设计
* 管理面向对象的项目
* 面向对象的分析与设计
* 其他一些系统的分析与设计技术（如结构化分析）
(美)Stephen T.Albin：Stephen T.Albin: Stephen T.Albin是北加州的软件工程师和技术顾问，曾经开发了多个商用的企业应用软件、软件平台和技术。他是ACM和IEEE计算机和工程管理协会的会员。
刘晓霞 郝玉洁 等：暂无简介
本书是一本关于软件体系结构设计的书籍。书中探讨了软件体系结构的概念、方法、用途等问题，但对软件体系结构概念本身并没有给出非常明确的定义。作者希望读者通读全书后自己形成软件体系结构的一个完整概念。这样做很有道理，因为软件体系结构这个概念本身就是一个不断发展的概念，而且还存在着多种定义和说法。
不过，为了方便读者，译者在此先给出一个粗浅的说法，供读者阅读本书时参考。译者认为，可以这样描述软件体系结构，即：软件体系结构是软件开发的一个新学科，它是针对软件系统及软件系统要解决的问题的复杂性不断增加而出现的。它研究软件系统的基本组织情况，研究软件系统的组件、组件相互之间的关系、相对于环境的关系、指导系统设计和发展的原则等问题。目的是提高软件设计的质量，生产出高质量、满足用户需求的软件系统。
从本书内容可知，作者具有丰富的系统工程理论知识，对各种开发方法、模型和知识表示方法、建模理论都相当熟悉，并有自己独到的见解。作者具有丰富的软件工程经验和程序设计语言知识，书中列举的许多例子都是作者在软件工程实践中亲身经历的事情。在需要用程序设计语言来举例的地方，作者基本上都是采用C++和Java语言，这表示作者对当前最流行的程序设计语言C++和Java也很了解。这里对作者做这样的介绍，目的不是吹嘘作者，而是想说明本书是一本用来指导软件工程实践的好书，作者不是一个光会写文章的空头理论家。本书比较抽象，有的读者阅读本书时难免会产生疑问，“这家伙说的这些东西太玄了，有用吗？太空洞了吧，有实践背景吗？”。译者在初读此书时也有这样的想法。不过，读完全书后，这种想法就完全消失了。译者阅读此书的经验是：要耐心往下读，细细体会。读者在读完全书后会觉得耳目一新，在理论上提高一个层次，会觉得对自己以后的软件工程实践有很大的指导意义。要想真正掌握本书中的理论和方法，要反复读几遍，而且还要将这些理论应用于实践。
阅读本书时要注意书中所列出的参考文献。对很多方法和模型，作者都是一带而过，如果没有相应的背景知识，不易理解本书的内容。
本书不仅适合大型软件系统的体系结构设计师使用，而且也适合较小、不太成熟的软件开发组织的软件体系结构设计师使用。本书提供了生成有效软件体系结构的实际指导。
参加本书翻译的主要人员有：刘晓霞、郝玉洁。全书由钟鸣同志审校。担任部分翻译及校对工作的人员还有：石永平、王君、张文、魏允韬、田晓涛、耿娜、何江华、梅刚、孙登峰、樊伟、李安娜、李晓军、赵彦萍等。
由于译者水平有限，难免有错误或不当之处，敬请读者批评指正。
译 者
2003年6月
第1章 软件体系结构介绍 1
1.1 软件开发的演变 1
1.2 软件工程基础 4
1.2.1 可重用资源 5
1.2.2 通用程序设计语言 6
1.2.3 专用程序设计语言 6
1.2.4 建模语言和表示法 7
1.3 软件体系结构的元素 7
1.3.1 组件、连接器和质量 8
1.3.2 体系结构描述 10
1.3.3 软件体系结构与软件设计方法学 11
1.3.4 体系结构的类型 12
1.4 本章小结 14
第2章 软件产品生命周期 15
2.1 管理的视图 16
2.1.1 初始阶段 18
2.1.2 细化阶段 18
2.1.3 构造阶段 18
2.1.4 移交阶段 19
2.2 软件工程的视图 19
2.2.1 需求分析和规格说明 21
2.2.2 设计 22
2.2.3 实现和测试 22
2.2.4 部署和维护 23
2.3 工程设计的视图 23
2.3.1 产品计划：信息规格说明 26
2.3.2 概念设计：原则规格说明 26
2.3.3 具体设计：布局规格说明 26
2.3.4 详细设计：生产规格说明 27
2.4 体系结构设计的视图 27
2.4.1 预设计阶段 29
2.4.2 域分析阶段 29
2.4.3 示意设计阶段 30
2.4.4 设计开发阶段 30
2.4.5 建造阶段 30
2.5 各种视图的综合 31
2.6 本章小结 33
第3章 体系结构设计过程 35
3.1 理解问题 36
3.2 确定设计元素及其关系 38
3.2.1 定义系统上下文环境 42
3.2.2 确定模块 42
3.2.3 描述组件和连接器 45
3.3 评价体系结构 46
3.4 转换体系结构 46
3.5 本章小结 48
第4章 软件设计介绍 49
4.1 软件体系结构设计中的问题 49
4.2 功能、形式和制造：维特鲁威风格的三和弦 51
4.2.1 功能和产品计划 52
4.2.2 形式和交互设计 52
4.2.3 认知摩擦和体系结构设计 53
4.2.4 制造 55
4.2.5 应用的体系结构 55
4.2.6 例子 55
4.3 设计范围 58
4.3.1 设计的任务和活动 58
4.3.2 体系结构与工程设计 63
4.4 设计的心理学和哲学 63
4.4.1 问题、障碍和解决方案 64
4.4.2 亚里士多德的推理 65
4.5 设计的一般方法 67
4.5.1 有目的的思维 67
4.5.2 分析 68
4.5.3 抽象 69
4.5.4 综合 69
4.5.5 通用启发方法 70
4.6 本章小结 72
第5章 复杂性和模块化 75
5.1 复杂性 78
5.1.1 理解复杂性 78
5.1.2 粒度和上下文 79
5.2 模块化 83
5.2.1 体系结构和模块 84
5.2.2 导入和导出 84
5.2.3 耦合与内聚 85
5.2.4 设计元素和设计规则 86
5.2.5 任务结构矩阵 90
5.2.6 模块化操作 91
5.3 本章小结 97
第6章 模型和知识表示 99
6.1 模型是什么 99
6.1.1 模型语言 101
6.1.2 模型和人的理解 102
6.2 模型的用途 102
6.2.1 系统分析模型 104
6.2.2 系统推理模型 104
6.2.3 系统设计模型 105
6.3 模型的作用 105
6.3.1 风险承担者与体系结构设计师之间的沟通 106
6.3.2 设计决策和设计评估 106
6.3.3 详细设计的指导原则 107
6.3.4 可重用技术的人工制品 107
6.4 问题域和方案域建模 107
6.4.1 问题域模型 108
6.4.2 方案域模型 108
6.5 视图 109
6.5.1 目标和目的模型 110
6.5.2 行为/功能模型 112
6.5.3 信息/数据模型 114
6.5.4 形式模型 114
6.5.5 非功能/性能模型 116
6.6 本章小结 117
第7章 体系结构表示 119
7.1 体系结构表示的目的 119
7.2 软件体系结构表示基础 121
7.3 体系结构描述语言 123
7.3.1 设计语言元素 124
7.3.2 第一类连接器 128
7.3.3 模块和组件 128
7.3.4 例子：C2 SADL 130
7.3.5 应用ADL 131
7.4 本章小结 132
第8章 质量模型和质量属性 135
8.1 过程和产品质量 136
8.2 确定质量需求 137
8.2.1 度量质量属性 138
8.2.2 质量需求和体系结构设计 138
8.2.3 系统知识和质量属性 139
8.2.4 达到质量标准的障碍 139
8.2.5 常见的质量属性误解 140
8.3 理解质量模型 142
8.4 用质量属性进行体系结构设计 149
8.4.1 功能性 149
8.4.2 性能（有效性） 151
8.4.3 可修改性 152
8.4.4 可用性和可靠性 152
8.4.5 适用性 153
8.4.6 可移植性 153
8.5 体系结构和质量模型 154
8.6 本章小结 155
第9章 体系结构设计原则 157
9.1 体系结构级的设计 157
9.1.1 应用设计原则 158
9.1.2 使用系统的思想 159
9.1.3 例子 159
9.2 用设计操作进行体系结构设计 160
9.2.1 分解 161
9.2.2 复制 163
9.2.3 压缩 165
9.2.4 抽象 165
9.2.5 资源共享 166
9.3 功能设计策略 167
9.3.1 自监控 167
9.3.2 恢复 168
9.3.3 仪器检测 168
9.4 本章小结 169
第10章 应用体系结构风格和模式 171
10.1 定义体系结构模式和风格 172
10.1.1 激活模型 174
10.1.2 风格和质量属性 176
10.2 常见的体系结构风格 177
10.2.1 数据流系统 177
10.2.2 调用返回系统 179
10.2.3 独立组件 182
10.2.4 虚拟机 182
10.2.5 库 183
10.3 应用体系结构风格的例子 184
10.4 本章小结 188
第11章 理解元模型 191
11.1 理解元模型 192
11.2 使用参考模型 196
11.2.1 Seeheim模型 197
11.2.2 arch/slinky模型 199
11.2.3 企业应用参考模型 201
11.2.4 技术堆叠和体系结构层次 203
11.3 描述软件组件的基本元模型 205
11.4 例子：内容管理系统参考模型 206
11.4.1 域模型 207
11.4.2 内容协作参考模型 209
11.4.3 内容管理参考模型 211
11.5 本章小结 212
第12章 建立体系结构描述 213
12.1 体系结构描述的标准化 213
12.2 建立体系结构描述 215
12.2.1 确定体系结构描述 216
12.2.2 确定风险承担者 216
12.2.3 选择视点 217
12.2.4 确定视点 218
12.2.5 确定视图 222
12.2.6 记录视图的不一致 223
12.2.7 建立对体系结构基本原理的阐述 223
12.3 使用体系结构描述 224
12.3.1 建立现有系统的体系结构描述 225
12.3.2 进行体系结构评估 225
12.3.3 规格说明的语用 225
12.4 本章小结 226
第13章 使用体系结构框架 227
13.1 软件体系结构框架 227
13.1.1 体系结构框架的哲学 228
13.1.2 体系结构框架的目标 229
13.1.3 方法学和体系结构框架 230
13.2 体系结构的4+1视图模型 230
13.2.1 与IEEE 1471的关系 231
13.2.2 逻辑视点 232
13.2.3 过程视点 232
13.2.4 开发视点 234
13.2.5 物理视点 234
13.2.6 场景视点 234
13.2.7 模型超载 235
13.2.8 用Unified Process建造体系结构 235
13.3 开放式分布处理参考模型 237
13.3.1 企业视点 237
13.3.2 信息视点 239
13.3.3 计算视点 240
13.3.4 工程视点 240
13.3.5 技术视点 241
13.4 本章小结 241
第14章 软件体系结构质量 243
14.1 评估软件体系结构的重要性 244
14.1.1 内容出版系统的例子 245
14.1.2 企业应用的例子 246
14.2 怎样提高质量 246
14.2.1 系统化的设计过程 247
14.2.2 正确地理解问题 248
14.2.3 评估软件体系结构 250
14.3 体系结构评价 253
14.4 评估可修改性 255
14.5 评估性能 258
14.6 本章小结 261
参考文献 263
