一 从软件危机谈起
　　软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。20世纪60年代末至20世纪70年代初，"软件危机"一词在计算机界广为流传。事实上，几乎从计算机诞生的那一天起，就出现了软件危机，只不过到了1968年在原西德加密施（Garmish）召开的国际软件工程会议上才被人们普遍认识到。
　　1 软件危机的表现
　　（1）软件成本日益增长
　　在计算机发展的早期，大型计算机系统主要是被设计应用于非常狭窄的军事领域。在这个时期，研制计算机的费用主要由国家财政提供，研制者很少考虑到研制代价问题。随着计算机市场化和民用化的发展，代价和成本就成为投资者考虑的最重要的问题之一。20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%-20%。但随着软件产业的发展，软件成本日益增长。相反，计算机硬件随着技术的进步、生产规模的扩大，价格却不断下降。这样一来，软件成本在计算机系统中所占的比例越来越大。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右。
　　而且，该数字还在不断地递增，下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。
　　（2）开发进度难以控制
　　由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不一样的。例如：工厂里要生产某种机器，在时间紧的情况下可以要工人加班或者实行"三班倒"，而这些方法都不能用在软件开发上。
　　在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过程很难保证按预定的计划实现，给项目计划和论证工作带来了很大的困难。
　　BROOK曾经提出："在已拖延的软件项目上，增加人力只会使其更难定期完成"。事实上，软件系统的结构很复杂，各部分附加联系极大，盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和办理等方面的问题将更为严重。
　　许多重要的大型软件开发项目，网站SEO，如IBM OS/360和世界范围的军事命令控制系统（WWMCCS），在耗费了大量的人力和财力之后，由于离预定目标相差甚远不得不宣布失败。
　　（3）软件质量差
　　软件项目即使能按预定日期完成，结果却不尽人意。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。程序的一些微小错误可以造成灾难性的后果，例如，有一次，在美国肯尼迪发射一枚阿脱拉斯火箭，火箭飞离地面几十英里高空开始翻转，地面控制中心被迫下令炸毁。后经检查发现是飞行计划程序里漏掉了一个连字符。就是这样一个小小的疏漏造成了这支价值1850万美元的火箭试验失败。
　　在"软件作坊"里，由于缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，很多功能只是程序员的"一厢情愿"而已，这是造成软件不能今人满意的重要因素。
　　（4）软件维护困难
　　正式投入使用的软件，总是存在着一定数量的错误，在不同的运行条件下，软件就会出现故障，因此需要维护。但是，由于在软件设计和开发过程中，没有严格遵循软件开发标准，各种随意性很大，没有完整的真实反映系统状况的记录文档，给软件维护造成了巨大的困难。特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。
　　另外，软件修改是一项很"危险"的工作，对一个复杂的逻辑过程，哪怕做一项微小的改动，都可能引入潜在的错误，常常会发生"纠正一个错误带来更多新错误"的问题，从而产生副作用。
　　有资料表明，工业届为维护软件支付的费用占全部硬件和软件费用的40%-75%。
　　2 软件危机的原因
　　从软件危机的种种表现和软件作为逻辑产品的特殊性可以发现软件危机的原因：
　　（1）用户需求不明确
　　在软件开发过程中，用户需求不明确问题主要体现在四个方面：
　　◇ 在软件开发出来之前，用户自己也不清楚软件的具体需求；
　　◇ 用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；
　　◇ 在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；
　　◇ 软件开发人员对用户需求的理解与用户本来愿望有差异。
　　（2）缺乏正确的理论指导
　　缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化，也是发生软件危机的一个重要原因。
　　（3）软件规模越来越大
　　随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数办理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏办理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。
　　（4）软件复杂度越来越高
　　软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处?quot;复杂问题"。所谓"复杂问题"的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。
　　3 如何克服软件危机
　　人们在认真地研究和分析了软件危机背后的真正原因之后，得出了"人们面临的不光是技术问题，更重要的是办理问题。办理不善必然导致失败。"的结论，便开始探索用工程的方法进行软件生产的可能性，即用现代工程的概念、原理、技术和方法进行计算机软件的开发、办理和维护。于是，计算机科学技术的一个新领域--软件工程诞生了。
　　软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及办理方法。软件工程包括三个要素：
　　（1）方法。软件工程方法为软件开发提供了"如何做"的技术，是完成软件工程项目的技术手段；
　　（2）工具。软件工具是人类在开发软件的活动中智力和体力的扩展和延伸，为软件工程方法提供了自动的或半自动的软件支撑环境；
　　（3）过程。软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。
　　迄今为止，软件工程的研究与应用已经取得很大成就，它在软件开发方法、工具、办理等方面的应用大大缓解了软件危机造成的被动局面。
　　二 构件和软件重用
　　1 软件重用
　　软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相近软件元素的过程。软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识。通常，把这种可重用的元素称作软构件，可重用的软件元素越大，我们就说重用的粒度越大。
　　使用软件重用技术可以减少软件开发活动中大量的重复性工作，这样就能提高软件生产率，降低开发成本，缩短开发周期。同时，由于软构件大都经过严格的质量认证，并在实际运行环境中得到校验，因此，重用软构件有助于改善软件质量。此外，大量使用软构件，软件的灵活性和标准化程度也可望得到提高。
　　在这里，我们只是为了后面的行文方便，简单地介绍了软件重用技术的概念和作用。软件重用本身是一门博大精深的技术，有兴趣的读者可以进一步查阅有关资料和书籍。
　　2 构件
　　一般认为，构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辩识的系统；结构上，它是语义描述、通讯接口和实现代码的复合体。简单地说，构件是具有一定的功能，能够独立工作或能同其它构件装配起来协调工作的程序体，构件的使用同他的开发、生产无关。从抽象程度来看，面向对象技术已达到了类级重用(代码重用)，它以类为封装的单位。这样的重用粒度还太小，不足以解决异构互操作和效率更高的重用。构件将抽象的程度提到一个更高的层次，它是对一组类的组合进行封装，并代表完成一个或多个功能的特定办事，也为用户提供了多个接口。整个构件隐藏了具体的实现，只用接口提供办事。
　　近年来，构件技术发展迅速，已形成三个主要流派，分别是IBM的CORBA 、Sun的Java平台和Microsoft的COM+。
　　如果把软件系统看成是构件的集合，那么从构件的外部形态来看，构成一个系统的构件可分为5类：
　　（1）独立而成熟的构件。独立而成熟的构件得到了实际运行环境的多次检验，该类构件隐藏了所有接口，用户只需用规定好的命令进行使用。例如，数据库办理系统和操作系统等。
　　（2）有限制的构件。有限制的构件提供了接口，指出了使用的条件和前提，这种构件在装配时，会产生资源冲突、覆盖等影响，在使用时需要加以测试。例如，各种面向对象对象程序设计语言中的基础类库等。
　　（3）适应性构件。适应性构件进行了包装或使用了接口技术，把不兼容性、资源冲突等进行了处理，可以直接使用。这种构件可以不加修改地使用在各种环境中。例如ActiveX等。
　　（4）装配的构件。装配的构件在安装时，已经装配在操作系统、数据库办理系统或信息系统不同层次上，使用胶水代码（Blue Code）就可以进行连接使用。目前一些软件商提供的大多数软件产品都属这一类。
　　（5）可修改的构件。可修改的构件可以进行版本替换。如果对原构件修改错误、增加新功能，可以利用重新"包装"或写接口来实现构件的替换。这种构件在应用系统开发中使用得比较多。
　　基于构件的软件开发通常包括构件获取、构件分类和检索、构件评估、适应性修改以及将现有构件在新的语境下组装成新的系统。构件获取可以有多种不同的途径：
　　（1）从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件；
　　（2）通过遗产工程，将具有潜在重用价值的构件提取出来，得到可重用的构件；
　　（3）从市场上购买现成的商业构件，即COTS构件；
　　（4）开发新的符合要求的构件。
　　一个企业或组织在进行以上决策时，必须考虑到不同方式获取构件的一次性成本和以后的维护成本，做出最优的选择。
　　三 软件体系结构
　　1 软件体系结构的兴起
　　六十年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要。软件危机的程度日益加剧，现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已经变得明显重要得多。在此种背景下，人们认识到软件体系结构的重要性，并认为对软件体系结构的系统、深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径。
　　自从软件系统首次被分成许多模块，模块之间有相互作用，组合起来有整体的属性，就具有了体系结构。好的开发者常常会使用一些体系结构模式作为软件系统结构设计策略，但他们并没有规范地、明确地表达出来，这样就无法将他们的知识与别人交流。软件体系结构是设计抽象的进一步发展，满足了更好地理解软件系统，更方便地开发更大、更复杂的软件系统的需要。
　　事实上，软件总是有体系结构的，不存在没有体系结构的软件。体系结构（Architecture）一词在英文里就是"建筑"的意思。把软件比作一座楼房，从整体上讲，是因为它有基础、主体和装饰，即操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。从细节上来看每一个程序也是有结构的。早期的结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构，也就是体系结构。结构化程序的程序（表达）结构和（计算的）逻辑结构的一致性及自顶向下开发方法自然而然地形成了体系结构。由于结构化程序设计时代程序规模不大，通过强调结构化程序设计方法学，自顶向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构，所以，并未特别研究软件体系结构。
　　我们可以作个简单的比喻，结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大厦。构件怎样搭配才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种应用领域需要什么构件（医院、工厂、旅馆）？有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑（即体系结构）更能满足用户的需求？如同土木工程进入到现代建筑学一样，软件也从传统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的体系结构，寻求建构最快、成本最低、质量最好的构造过程。
　　软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的一个最新的研究方向和独立学科分支。软件体系结构研究的主要内容涉及软件体系结构描述、软件体系结构风格、软件体系结构评价和软件体系结构的形式化方法等。解决好软件的重用、质量和维护问题，是研究软件体系结构的根本目的。
　　2 软件体系结构的定义
　　虽然软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义。许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画，较为典型的定义有：
　　（1）Dewayne Perry和A1ex Wo1f曾这样定义：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。
　　（2）Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定义，软件开发，物理分布与合成，设计方案的选择、评估与实现等。
　　（3）Kruchten指出，软件体系结构有四个角度，它们从不同方面对系统进行描述：概念角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织。
　　（4）Hayes Roth则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。
　　（5）David Garlan和Dewne Perry于1995年在IEEE软件工程学报上又采用如下的定义：软件体系结构是一个程序／系统各构件的结构、它们之间的相互关系以及进行设计的原则和随时间进化的指导方针。
　　（6）Barry Boehm和他的学生提出，一个软件体系结构包括一个软件和系统构件，互联及约束的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需求。
　　（7）1997年，Bass，Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中，"软件外部的可见特性"是指软件构件提供的办事、性能、特性、错误处理、共享资源使用等。
　　总之，软件体系结构的研究正在发展，软件体系结构的定义也必然随之完善。在以后的文章里，如果不特别指出，我们将使用软件体系结构的下列定义：
　　软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。