软件体系结构的艺术[按需印刷]
![软件体系结构的艺术[按需印刷]](http://images.china-pub.com/ebook15001-20000/16511/zcover.jpg?2011-11-25 8:39:03)
点击看大图
基本信息
- 作者： （美）Stephen T.Albin [作译者介绍]
- 译者： 刘晓霞 郝玉洁
- 丛书名： 软件工程技术丛书/设计系列
- 出版社：机械工业出版社
- ISBN：7111134389
- 上架时间：2004-1-15
- 出版日期：2004 年1月
- 开本：16开
- 页码：265
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 综合
内容简介回到顶部↑
本书给出独立于任意特定工程过程或组织成熟程度的软件体系结构设计方法，为软件体系结构设计师提供做出软件体系结构决策和建立有效软件体系结构所必需的信息和工具。本书包括方法、设计表示及模型、技术（如面向对象和面向组件的技术）、参考模型、体系结构框架、分析、设计、体系结构模式等方面的透彻介绍和应用。
本书不仅适合大型软件系统的体系结构设计师使用，而且特别适合较小、不太成熟的软件开发组织的体系结构设计师使用，同时，本书也可作为对软件体系结构设计感兴趣的广大读者的参考读物。
软件体系结构是软件开发的一个新课题，是随着软件系统的复杂性不断增加应运而生的；软件正在成为许多系统的主要组成部分．因此．很有必要建立新的；准则、原理和标准，应对不断增加的复杂性。
本书试图综合和提取这些信息，填补软件体系结构设计理念的空白，提供建立有效软件体系结构所必需的信息和工具。主要内容包括：
方法学、设计表示及模型、技术、参考模型、体系结构框架等如何将设计模式应用到自己的软件设计之中独立于任意特定工程过程或组织成熟程度的软件体系结构设计方法。
本书不仅适合大型软件系统的体系结构设计师使用，而且特别适合较小、不太成熟的软件开发组织的体系结构设计师使用，同时，本书也可作为对软件体系结构设计感兴趣的广大读者的参考读物。
软件体系结构是软件开发的一个新课题，是随着软件系统的复杂性不断增加应运而生的；软件正在成为许多系统的主要组成部分．因此．很有必要建立新的；准则、原理和标准，应对不断增加的复杂性。
本书试图综合和提取这些信息，填补软件体系结构设计理念的空白，提供建立有效软件体系结构所必需的信息和工具。主要内容包括：
方法学、设计表示及模型、技术、参考模型、体系结构框架等如何将设计模式应用到自己的软件设计之中独立于任意特定工程过程或组织成熟程度的软件体系结构设计方法。
目录回到顶部↑
译者序
前言
第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
前言
第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
译者序回到顶部↑
本书是一本关于软件体系结构设计的书籍。书中探讨了软件体系结构的概念、方法、用途等问题，但对软件体系结构概念本身并没有给出非常明确的定义。作者希望读者通读全书后自己形成软件体系结构的一个完整概念。这样做很有道理，因为软件体系结构这个概念本身就是一个不断发展的概念，而且还存在着多种定义和说法。
不过，为了方便读者，译者在此先给出一个粗浅的说法，供读者阅读本书时参考。译者认为，可以这样描述软件体系结构，即：软件体系结构是软件开发的一个新学科，它是针对软件系统及软件系统要解决的问题的复杂性不断增加而出现的。它研究软件系统的基本组织情况，研究软件系统的组件、组件相互之间的关系、相对于环境的关系、指导系统设计和发展的原则等问题。目的是提高软件设计的质量，生产出高质量、满足用户需求的软件系统。
从本书内容可知，作者具有丰富的系统工程理论知识，对各种开发方法、模型和知识表示方法、建模理论都相当熟悉，并有自己独到的见解。作者具有丰富的软件工程经验和程序设计语言知识，书中列举的许多例子都是作者在软件工程实践中亲身经历的事情。在需要用程序设计语言来举例的地方，作者基本上都是采用C++和Java语言，这表示作者对当前最流行的程序设计语言C++和Java也很了解。这里对作者做这样的介绍，目的不是吹嘘作者，而是想说明本书是一本用来指导软件工程实践的好书，作者不是一个光会写文章的空头理论家。本书比较抽象，有的读者阅读本书时难免会产生疑问，“这家伙说的这些东西太玄了，有用吗？太空洞了吧，有实践背景吗？”。译者在初读此书时也有这样的想法。不过，读完全书后，这种想法就完全消失了。译者阅读此书的经验是：要耐心往下读，细细体会。读者在读完全书后会觉得耳目一新，在理论上提高一个层次，会觉得对自己以后的软件工程实践有很大的指导意义。要想真正掌握本书中的理论和方法，要反复读几遍，而且还要将这些理论应用于实践。
阅读本书时要注意书中所列出的参考文献。对很多方法和模型，作者都是一带而过，如果没有相应的背景知识，不易理解本书的内容。
本书不仅适合大型软件系统的体系结构设计师使用，而且也适合较小、不太成熟的软件开发组织的软件体系结构设计师使用。本书提供了生成有效软件体系结构的实际指导。
参加本书翻译的主要人员有：刘晓霞、郝玉洁。全书由钟鸣同志审校。担任部分翻译及校对工作的人员还有：石永平、王君、张文、魏允韬、田晓涛、耿娜、何江华、梅刚、孙登峰、樊伟、李安娜、李晓军、赵彦萍等。
由于译者水平有限，难免有错误或不当之处，敬请读者批评指正。
译 者
2003年6月
不过，为了方便读者，译者在此先给出一个粗浅的说法，供读者阅读本书时参考。译者认为，可以这样描述软件体系结构，即：软件体系结构是软件开发的一个新学科，它是针对软件系统及软件系统要解决的问题的复杂性不断增加而出现的。它研究软件系统的基本组织情况，研究软件系统的组件、组件相互之间的关系、相对于环境的关系、指导系统设计和发展的原则等问题。目的是提高软件设计的质量，生产出高质量、满足用户需求的软件系统。
从本书内容可知，作者具有丰富的系统工程理论知识，对各种开发方法、模型和知识表示方法、建模理论都相当熟悉，并有自己独到的见解。作者具有丰富的软件工程经验和程序设计语言知识，书中列举的许多例子都是作者在软件工程实践中亲身经历的事情。在需要用程序设计语言来举例的地方，作者基本上都是采用C++和Java语言，这表示作者对当前最流行的程序设计语言C++和Java也很了解。这里对作者做这样的介绍，目的不是吹嘘作者，而是想说明本书是一本用来指导软件工程实践的好书，作者不是一个光会写文章的空头理论家。本书比较抽象，有的读者阅读本书时难免会产生疑问，“这家伙说的这些东西太玄了，有用吗？太空洞了吧，有实践背景吗？”。译者在初读此书时也有这样的想法。不过，读完全书后，这种想法就完全消失了。译者阅读此书的经验是：要耐心往下读，细细体会。读者在读完全书后会觉得耳目一新，在理论上提高一个层次，会觉得对自己以后的软件工程实践有很大的指导意义。要想真正掌握本书中的理论和方法，要反复读几遍，而且还要将这些理论应用于实践。
阅读本书时要注意书中所列出的参考文献。对很多方法和模型，作者都是一带而过，如果没有相应的背景知识，不易理解本书的内容。
本书不仅适合大型软件系统的体系结构设计师使用，而且也适合较小、不太成熟的软件开发组织的软件体系结构设计师使用。本书提供了生成有效软件体系结构的实际指导。
参加本书翻译的主要人员有：刘晓霞、郝玉洁。全书由钟鸣同志审校。担任部分翻译及校对工作的人员还有：石永平、王君、张文、魏允韬、田晓涛、耿娜、何江华、梅刚、孙登峰、樊伟、李安娜、李晓军、赵彦萍等。
由于译者水平有限，难免有错误或不当之处，敬请读者批评指正。
译 者
2003年6月
前言回到顶部↑
软件体系结构常常与低层设计和技术堆叠相混淆。技术供应商与流行的以技术为中心的杂志往往又传播了这种误解。结果，许多软件工程师生成的所谓体系结构描述只不过是令人反胃的技术层次图。典型的企业应用体系结构通常是所谓的体系结构层次图，它描述一个自下至上从持久层到业务逻辑层（或中间层）再到表示层的体系结构层次。这种表示方法没有传达系统如何处理系统的功能或非功能的需求，它只是显示所使用的技术以及这些技术如何集成。
我们做一个试验，假定应用程序体系结构的层次直接映射为具体的技术：表示层由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 Unified Process）和能力成熟度模型（Capability Maturity Model，CMM）等。提高软件质量的另一种方法是不采用极为面向计划的过程，而是采用敏捷过程并利用诸如RAD和极限编程（XP）等技术。
大多数充当软件体系结构设计师角色的软件工程师都很少或者从来没有受过软件体系结构学科方面的培训，这主要是因为现在还没有建立良好的理论或标准的大学课程。从未经过培训的软件编程人员从试验和挫折中获得了编程技巧，但大量原理、模式和技术被人们所认知都要经历一个重复发现的过程。从业人员和研究人员已经开始记载软件设计和工程过程的可重用模式。业内积累的这些知识已经作为原理和模式记载在书籍、会议文献和技术杂志中。但是，现在的软件体系结构设计师很少有时间跟踪这些信息，更不用说有足够的时间将其综合进实践知识之中。本书的目的是综合和提取这些信息，以便软件体系结构设计师，特别是新入门的软件体系结构设计师能够填补他们对软件体系结构设计的理解方面的空白。
本书给出独立于任意特定工程过程或组织成熟程度的软件体系结构设计方法。它给软件体系结构设计师提供了进行软件体系结构决策以及建立有效的软件体系结构所必需的信息和工具。本书包括方法、设计表示及模型、技术（如面向对象和面向组件的技术）、参考模型、体系结构框架、分析、设计、体系结构模式等方面的透彻介绍和应用。
没有任何一本书籍可作为软件体系结构设计师的手册。软件体系结构设计的内容既广泛又深入，而且是不断发展的。本书内容主要集中在软件体系结构设计师怎样建立软件体系结构上。书中概述了这个学科及其方法，向读者介绍了本学科的内容范围。鉴于许多软件体系结构的书籍主要集中于过程或基于技术的观点，所以本书内容主要围绕着软件体系结构设计的基本原理、模型、技术来组织。
本书主要集中于软件体系结构设计师必须实践的设计方法和技术。泛泛阅读本书的人不可能成为很好的体系结构设计师；必须应用所学到的知识，以便理解应该怎样使用它们以及怎样最好地应用它们。例如，有效使用面向对象设计的一个障碍是实际定义合适的对象及关系的技能。而UML及面向对象的程序设计语言只能帮助表达设计，而不能帮助建立良好的设计。另一个障碍是解决方案的好坏取决于问题描述的好坏。如果问题描述含混、错误、遗漏，则设计过程就相当于没有输入（“垃圾进/垃圾出”）。
本书的目的
软件开发组织的要求使软件设计人员无所适从。特别是较小的开发组织更是如此，他们没有标准的开发过程，或者没有较多的软件体系结构设计经验。这些组织大约占目前存在的软件组织的70%。这些组织中的大多数不能实施昂贵的方法或采用正式的软件设计规格说明方法，原因很多，如时间或金钱方面的培训成本、支持相应方法的工具成本、宣讲相应方法的时间和个人精力方面的成本、在尽力构造软件的同时引入一种新方法的风险、对有效的软件结构设计过程的实际重要性缺乏理解，等等。软件开发组织需要实施改进软件体系结构的一些实践活动，但不能要求他们一晚上就改变。通常，软件体系结构设计师是导致这种改变的人员。
本书特别适合较小的、不太成熟的软件开发组织（主要进行特殊开发）的软件体系结构设计师。它提供了生成有效软件体系结构的实际指导。它将：
?提供对软件体系结构基础概念的透彻理解
?作为获得软件体系结构方面信息以及了解具体思想流派的指路图
?讲授经典的软件体系结构设计风格、模式、启发方法、方法学和模型
我们做一个试验，假定应用程序体系结构的层次直接映射为具体的技术：表示层由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 Unified Process）和能力成熟度模型（Capability Maturity Model，CMM）等。提高软件质量的另一种方法是不采用极为面向计划的过程，而是采用敏捷过程并利用诸如RAD和极限编程（XP）等技术。
大多数充当软件体系结构设计师角色的软件工程师都很少或者从来没有受过软件体系结构学科方面的培训，这主要是因为现在还没有建立良好的理论或标准的大学课程。从未经过培训的软件编程人员从试验和挫折中获得了编程技巧，但大量原理、模式和技术被人们所认知都要经历一个重复发现的过程。从业人员和研究人员已经开始记载软件设计和工程过程的可重用模式。业内积累的这些知识已经作为原理和模式记载在书籍、会议文献和技术杂志中。但是，现在的软件体系结构设计师很少有时间跟踪这些信息，更不用说有足够的时间将其综合进实践知识之中。本书的目的是综合和提取这些信息，以便软件体系结构设计师，特别是新入门的软件体系结构设计师能够填补他们对软件体系结构设计的理解方面的空白。
本书给出独立于任意特定工程过程或组织成熟程度的软件体系结构设计方法。它给软件体系结构设计师提供了进行软件体系结构决策以及建立有效的软件体系结构所必需的信息和工具。本书包括方法、设计表示及模型、技术（如面向对象和面向组件的技术）、参考模型、体系结构框架、分析、设计、体系结构模式等方面的透彻介绍和应用。
没有任何一本书籍可作为软件体系结构设计师的手册。软件体系结构设计的内容既广泛又深入，而且是不断发展的。本书内容主要集中在软件体系结构设计师怎样建立软件体系结构上。书中概述了这个学科及其方法，向读者介绍了本学科的内容范围。鉴于许多软件体系结构的书籍主要集中于过程或基于技术的观点，所以本书内容主要围绕着软件体系结构设计的基本原理、模型、技术来组织。
本书主要集中于软件体系结构设计师必须实践的设计方法和技术。泛泛阅读本书的人不可能成为很好的体系结构设计师；必须应用所学到的知识，以便理解应该怎样使用它们以及怎样最好地应用它们。例如，有效使用面向对象设计的一个障碍是实际定义合适的对象及关系的技能。而UML及面向对象的程序设计语言只能帮助表达设计，而不能帮助建立良好的设计。另一个障碍是解决方案的好坏取决于问题描述的好坏。如果问题描述含混、错误、遗漏，则设计过程就相当于没有输入（“垃圾进/垃圾出”）。
本书的目的
软件开发组织的要求使软件设计人员无所适从。特别是较小的开发组织更是如此，他们没有标准的开发过程，或者没有较多的软件体系结构设计经验。这些组织大约占目前存在的软件组织的70%。这些组织中的大多数不能实施昂贵的方法或采用正式的软件设计规格说明方法，原因很多，如时间或金钱方面的培训成本、支持相应方法的工具成本、宣讲相应方法的时间和个人精力方面的成本、在尽力构造软件的同时引入一种新方法的风险、对有效的软件结构设计过程的实际重要性缺乏理解，等等。软件开发组织需要实施改进软件体系结构的一些实践活动，但不能要求他们一晚上就改变。通常，软件体系结构设计师是导致这种改变的人员。
本书特别适合较小的、不太成熟的软件开发组织（主要进行特殊开发）的软件体系结构设计师。它提供了生成有效软件体系结构的实际指导。它将：
?提供对软件体系结构基础概念的透彻理解
?作为获得软件体系结构方面信息以及了解具体思想流派的指路图
?讲授经典的软件体系结构设计风格、模式、启发方法、方法学和模型
)
加载中...
