虽然软体体系结构已经在软体工程领域中有着广泛的套用，但迄今为止还没有一个被大家所公认的定义。许多专家学者从不同角度和不同侧面对软体体系结构进行了刻画，较为典型的定义有：

软体体系结构

（1）Mary Shaw和David Garlan认为软体体系结构是软体设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协定、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。软体体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协定，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等

（2）Kruchten指出，软体体系结构有四个角度，它们从不同方面对系统进行描述：概念角度描述系统的主要构件及它们之间的关係；模组角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各种代码和库函式在开发环境中的组织。

（3）Hayes Roth则认为软体体系结构是一个抽象的系统规範，主要包括用其行为来描述的功能构件和构件之间的相互连线、接口和关係。

（4）David Garlan和Dewne Perry于1995年在IEEE软体工程学报上又採用如下的定义：软体体系结构是一个程式/系统各构件的结构、它们之间的相互关係以及进行设计的原则和随时间进化的指导方针。

（5）Barry Boehm和他的学生提出，一个软体体系结构包括一个软体和系统构件，互联及约束的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需求。

（6）1997年，Bass，Ctements和Kazman在《使用软体体系结构》一书中给出如下的定义：一个程式或计算机系统的软体体系结构包括一个或一组软体构件、软体构件的外部的可见特性及其相互关係。其中，"软体外部的可见特性"是指软体构件提供的服务、性能、特性、错误处理、共享资源使用等。

与最初的大型中央主机相适应，最初的软体结构体系也是Mainframe结构，该结构下客户、数据和程式被集中在主机上，通常只有少量的GUI界面，对远程资料库的访问比较困难。随着PC的广泛套用，该结构逐渐在套用中被淘汰。在80年代中期出现了Client/Server分散式计算结构，应用程式的处理在客户（PC机）和伺服器（Mainframe或Server）之间分担；请求通常被关係型资料库处理，PC机在接受到被处理的数据后实现显示和业务逻辑；系统支持模组化开发，通常有GUI界面。Client/Server结构因为其灵活性得到了极其广泛的套用。但对于大型软体系统而言，这种结构在系统的部署和扩展性方面还是存在着不足。

软体体系结构

Internet的发展给传统套用软体的开发带来了深刻的影响。基于Internet和Web的软体和套用系统无疑需要更为开放和灵活的体系结构。随着越来越多的商业系统被搬上Internet，一种新的、更具生命力的体系结构被广泛採用，这就是为我们所知的“三层/多层计算”。

。客户层（client tier） 用户接口和用户请求的发出地，典型套用是网路浏览器和胖客户（如Java程式）

。伺服器层（server tier） 典型套用是Web伺服器和运行业务代码的应用程式伺服器

。数据层（data tier） 典型套用是关係型资料库和其他后端（back-end）数据资源, 如 Oracle和SAP、 R/3等

三层体系结构中，客户（请求信息）、程式（处理请求）和数据（被操作）被物理地隔离。三层结构是个更灵活的体系结构，它把显示逻辑从业务逻辑中分离出来，这就意味着业务代码是独立的，可以不关心怎样显示和在哪里显示。业务逻辑层现在处于中间层，不需要关心由哪种类型的客户来显示数据，也可以与后端系统保持相对独立性，有利于系统扩展。三层结构具有更好的移植性，可以跨不同类型的平台工作，允许用户请求在多个伺服器间进行负载平衡。三层结构中安全性也更易于实现，因为应用程式已经同客户隔离。应用程式伺服器是三层/多层体系结构的组成部分，应用程式伺服器位于中间层。

如图所示，应用程式伺服器运行于浏览器和数据资源之间，一个简单的实例是，顾客从浏览器中输入一个定单，web伺服器将该请求传送给应用程式伺服器，由应用程式伺服器执行处理逻辑，并且获取或更新后端用户数据。

兴起

六十年代的软体危机使得人们开始重视软体工程的研究。起初，人们把软体设计的重点放在数据结构和算法的选择上，随着软体系统规模越来越大、越来越複杂，整个系统的结构和规格说明显得越来越重要。软体危机的程度日益加剧，现有的软体工程方法对此显得力不从心。对于大规模的複杂软体系统来说，对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已经变得明显重要得多。在此种背景下，人们认识到软体体系结构的重要性，并认为对软体体系结构的系统、深入的研究将会成为提高软体生产率和解决软体维护问题的新的最有希望的途径。自从软体系统首次被分成许多模组，模组之间有相互作用，组合起来有整体的属性，就具有了体系结构。好的开发者常常会使用一些体系结构模式作为软体系统结构设计策略，但他们并没有规範地、明确地表达出来，这样就无法将他们的知识与别人交流。软体体系结构是设计抽象的进一步发展，满足了更好地理解软体系统，更方便地开发更大、更複杂的软体系统的需要。

软体体系结构的生命周期模型

事实上，软体总是有体系结构的，不存在没有体系结构的软体。体系结构（Architecture）一词在英文里就是"建筑"的意思。把软体比作一座楼房，从整体上讲，是因为它有基础、主体和装饰，即作业系统之上的基础设施软体、实现计算逻辑的主体应用程式、方便使用的用户界面程式。从细节上来看每一个程式也是有结构的。早期的结构化程式就是以语句组成模组，模组的聚集和嵌套形成层层调用的程式结构，也就是体系结构。结构化程式的程式（表达）结构和（计算的）逻辑结构的一致性及自顶向下开发方法自然而然地形成了体系结构。由于结构化程式设计时代程式规模不大，通过强调结构化程式设计方法学，自顶向下、逐步求精，并注意模组的耦合性就可以得到相对良好的结构，所以，并未特别研究软体体系结构。

我们可以作个简单的比喻，结构化程式设计时代是以砖、瓦、灰、沙、石、预製梁、柱、屋面板盖平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预製件盖高楼大厦。构件怎样搭配才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种套用领域需要什幺构件（医院、工厂、旅馆）？有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑（即体系结构）更能满足用户的需求？如同土木工程进入到现代建筑学一样，软体也从传统的软体工程进入到现代面向对象的软体工程，研究整个软体系统的体系结构，寻求建构最快、成本最低、质量最好的构造过程。

软体体系结构虽脱胎于软体工程，但其形成同时借鉴了计算机体系结构和网路体系结构中很多宝贵的思想和方法，最近几年软体体系结构研究已完全独立于软体工程的研究，成为计算机科学的一个最新的研究方向和独立学科分支。软体体系结构研究的主要内容涉及软体体系结构描述、软体体系结构风格、软体体系结构评价和软体体系结构的形式化方法等。解决好软体的重用、质量和维护问题，是研究软体体系结构的根本目的。

自20世纪90年代后期以来，软体体系结构的研究成为一个热点。广大软体工作者已经认识到软体体系结构研究的重大意义和它对软体系统设计开发的重要性，开展了很多研究和实践工作。

从软体体系结构研究的现状来看，当前的研究和对软体体系结构的描述，在很大程度上来说还停留在非形式化的基础上。软体构架师仍然缺乏必要的工具，这种工具应该是显式描述的、有独立性的形式化工具。

在目前通用的软体开发方法中，其描述通常是用非形式化的图和文本，不能描述系统期望的存在于构件之间的接口，不能描述不同的组成系统的组合关係的意义。难以被开发人员理解，更不能用来分析其一致性和完整性等特性。

C2风格的体系结构

当一个软体系统中的构件之间几乎以一种非形式化的方法描述时，系统的重用性也会受到影响，在设计一个系统结构过程中的努力很难移植到另一个系统中去。对系统构件和连线关係的结构化假设没有得到显式的、形式化的描述时，把这样的系统构件移植到另一个系统中去将是有风险的，甚至是不可能的。

软体体系结构研究如果仅仅停留在非形式化的框图阶段，已经难以适应进一步发展的需要。为支持基于体系结构的开发，需要有形式化建模符号、体系结构说明的分析与开发工具。从软体体系结构研究的现状来看，在这一领域近来已经有不少进展，其中比较有代表性的是美国卡耐基梅隆大学（Carnegie Mellon University）的Robert J．A11en于l997年提出的Wright系统。Wright是-种结构描述语言，该语言基于一种形式化的、抽象的系统模型，为描述和分析软体体系结构和结构化方法提供了一种实用的工具。Wright主要侧重于描述系统的软体构件和连线的结构、配置和方法。它使用显式的、独立的连线模型来作为互动的方式，这使得该系统可以用逻辑谓词符号系统，而不依赖特定的系统实例来描述系统的抽象行为。该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。从这些特性的分析来说，Wright系统的确适用于对大型系统的描述和分析。

研究软体体系结构的首要问题是如何表示软体体系结构，即如何对软体体系结构建模。根据建模的侧重点的不同，可以将软体体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。在这5个模型中，最常用的是结构模型和动态模型。

（1）结构模型

这是一个最直观、最普遍的建模方法。这种方法以体系结构的构件、连线件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是体系结构描述语言。

管道/过滤器风格的体系结构

（2）框架模型

框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

（3）动态模型

动态模型是对结构或框架模型的补充，研究系统的"大颗粒"的行为性质。例如，描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。这类系统常是激励型的。

（4）过程模型

过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。

（5）功能模型

该模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。它可以看作是一种特殊的框架模型。

这5种模型各有所长，也许将5种模型有机地统一在一起，形成一个完整的模型来刻画软体体系结构更合适。例如，Kruchten在1995年提出了一个"4+1"的视角模型。"4+1"模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软体体系结构。每一个视角只关心繫统的一个侧面，5个视角结合在一起才能够反映系统的软体体系结构的全部内容。"4+1"模型如图1所示。

图1 "4+1"模型

软体开发模型是跨越整个软体生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软体开发活动各阶段之间的关係。目前，常见的软体开发模型大致可分为三种类型:

（1）以软体需求完全确定为前提的瀑布模型。

（2）在软体开发初始阶段只能提供基本需求时採用的渐进式开发模型,如螺旋模型等。

（3）以形式化开发方法为基础的变换模型。

所有开发方法都是要解决需求与实现之间的差距。但是，这三种类型的软体开发模型都存在这样或那样的缺陷，不能很好地支持基于软体体系结构的开发过程。因此，研究人员在发展基于体系结构的软体开发模型方面做了一定的工作。例如，为了形象地表示体系结构的生命周期，北京邮电大学的周莹新博士建立了一个软体体系结构的生命周期模型，该模型如图2所示。图2 软体体系结构的生命周期模型

数据抽象和面向对象风格的体系结构

软体体系结构的开发是大型软体系统开发的关键环节。体系结构在软体生产线的开发中具有至关重要的作用，在这种开发生产中，基于同一个软体体系结构，可以创建具有不同功能的多个系统。在软体产品族之间共享体系结构和一组可重用的构件，可以增加软体工程和降低开发和维护成本。

一个产品线代表着一组具有公共的系统需求集的软体系统，它们都是根据基本的用户需求对标準的产品线构架进行定製，将可重用构件与系统独有的部分集成而得到的。採用软体生产线式模式进行软体生产，将产生巨型编程企业。但目前生产的软体产品族大部分是处于同一领域的。

软体体系结构贯穿于软体研发的整个生命周期内，具有重要的影响。这主要从以下三个方面来进行考察：

：软体体系结构是一种常见的对系统的抽象，代码级别的系统抽象仅仅可以成为程式设计师的交流工具，而包括程式设计师在内的绝大多数系统的利益相关人员都藉助软体体系结构来进行彼此理解、协商、达成共识或者相互沟通的基础。

：软体体系结构是我们所开发的软体系统最早期设计决策的体现，而这些早期决策对软体系统的后续开发、部署和维护具有相当重要的影响。这也是能够对所开发系统进行分析的最早时间点。

：软体体系结构是关于系统构造以及系统各个元素工作机制的相对较小、却又能够突出反映问题的模型。由于软体系统具有的一些共通特性，这种模型可以在多个系统之间传递，特别是可以套用到具有相似质量属性和功能需求的系统中，并能够促进大规模软体的系统级复用。

对软体体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以共享同一个实现代码。只要系统是使用常用的、规範的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为"客户/伺服器"模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

下面是Garlan和Shaw对通用体系结构风格的分类：

（1）数据流风格：批处理序列；管道/过滤器

（2）调用/返迴风格：主程式/子程式；面向对象风格；层次结构

（3）独立构件风格：进程通讯；事件系统

（4）虚拟机风格：解释器；基于规则的系统

（5）仓库风格：资料库系统；超文本系统；黑板系统

限于篇幅，在本文中，我们将只介绍几种主要的和经典的体系结构风格和它们的优缺点。有关新出现的软体体系结构风格，将在后续文章中进行介绍。

C2体系

C2体系结构风格可以概括为：通过连线件绑定在一起的按照一组规则运作的并行构件网路。C2风格中的系统组织规则如下：

（1）系统中的构件和连线件都有一个顶部和一个底部；

（2）构件的顶部应连线到某连线件的底部，构件的底部则应连线到某连线件的顶部，而构件与构件之间的直接连线是不允许的；（3）一个连线件可以和任意数目的其它构件和连线件连线；

层次系统风格的体系结构

（4）当两个连线件进行直接连线时，必须由其中一个的底部到另一个的顶部。

图3是C2风格的示意图。图中构件与连线件之间的连线体现了C2风格中构建系统的规则。

图3 C2风格的体系结构

C2风格是最常用的一种软体体系结构风格。从C2风格的组织规则和结构图中，我们可以得出，C2风格具有以下特点：

（1）系统中的构件可实现套用需求，并能将任意複杂度的功能封装在一起；

（2）所有构件之间的通讯是通过以连线件为中介的异步讯息交换机制来实现的；

（3）构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制执行绪之类的相关性假设。

管道/过滤器

在管道/过滤器风格的软体体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连线件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。此风格特别重要的过滤器必须是独立的实体，它不能与其它的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网路输出的正确性并不依赖于过滤器进行增量计算过程的顺序。

图4是管道/过滤器风格的示意图。一个典型的管道/过滤器体系结构的例子是以Unix shell编写的程式。Unix既提供一种符号，以连线各组成部分(Unix的进程)，又提供某种进程运行时机制以实现管道。另一个着名的例子是传统的编译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。

图4 管道/过滤器风格的体系结构

管道/过滤器风格的软体体系结构具有许多很好的特点：

（1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；

（2）允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；

（3）支持软体重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连线起来；

（4）系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；

（5）允许对一些如吞吐量、死锁等属性的分析；

（6）支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。

但是，这样的系统也存在着若干不利因素。

（1）通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。

（2）不适合处理互动的套用。当需要增量地显示改变时，这个问题尤为严重。

（3）因为在数据传输上没有通用的标準，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的複杂性。

数据抽象和面向对象

抽象数据类型概念对软体系统有着重要作用，目前软体界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函式和过程的调用来互动的。

图5是数据抽象和面向对象风格的示意图。图5 数据抽象和面向对象风格的体系结构

黑板系统的组成

面向对象的系统有许多的优点，并早已为人所知：

（1）因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。

（2）设计者可将一些数据存取操作的问题分解成一些互动的代理程式的集合。

但是，面向对象的系统也存在着某些问题：

（1）为了使一个对象和另一个对象通过过程调用等进行互动，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。

（2）必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那幺，C对B的使用所造成的对A的影响可能是料想不到的。

基于事件的隐式调用

基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模组中的过程的调用。

从体系结构上说，这种风格的构件是一些模组，这些模组既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。

基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件互动的补充形式。

支持基于事件的隐式调用的套用系统很多。例如，在编程环境中用于集成各种工具，在资料库管理系统中确保数据的一致性约束，在用户界面系统中管理数据，以及在编辑器中支持语法检查。例如在某系统中，编辑器和变数监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下时，它声明该事件，由系统自动调用处理程式，如编辑程式可以卷屏到断点，变数监视器刷新变数数值。而Debugger本身只声明事件，并不关心哪些过程会启动，也不关心这些过程做什幺处理。

隐式调用系统的主要优点有：

（1）为软体重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。

（2）为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。

隐式调用系统的主要缺点有：

（1）构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会回响它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被 调用的顺序。

（2）数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行互动。在这些情况下，全局性能和资源管理便成了问题。

（3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

层次系统

层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函式外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连线件通过决定层间如何互动的协定来定义，拓扑约束包括对相邻层间互动的约束。

这种风格支持基于可增加抽象层的设计。这样，允许将一个複杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软体重用提供了强大的支持。

图6是层次系统风格的示意图。层次系统最广泛的套用是分层通信协定。在这一套用领域中，每一层提供一个抽象的功能，作为上层通信的基础。较低的层次定义低层的互动，最低层通常只定义硬体物理连线。

图6 层次系统风格的体系结构

层次系统有许多可取的属性：

（1）支持基于抽象程度递增的系统设计，使设计者可以把一个複杂系统按递增的步骤进行分解；

（2）支持功能增强，因为每一层至多和相邻的上下层互动，因此功能的改变最多影响相邻的上下层；

（3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标準的接口，而允许各种不同的实现方法。

但是，层次系统也有其不足之处：

（1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；

（2）很难找到一个合适的、正确的层次抽象方法。

仓库

在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。

控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一传统型资料库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。

图7是黑板系统的组成。黑板系统的传统套用是信号处理领域，如语音和模式识别。另一套用是松耦合代理数据共享存取。

图7 黑板系统的组成

我们从图4中可以看出，黑板系统主要由三部分组成：

（1）知识源。知识源中包含独立的、与应用程式相关的知识，知识源之间不直接进行通讯，它们之间的互动只通过黑板来完成。

（2）黑板数据结构。黑板数据是按照与应用程式相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。

（3）控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。

信息互换

现有的ADLs大多是与领域相关的，所以不利于对不同领域体系结构的说明。但这些针对不同领域的ADLs在某些方面又大同小异，造成资源的冗余。其实，大多数ADLs具有一系列的共同概念。如何用一种公共形式把各种语言综合起来，使得能够交换各种体系结构描述信息，将是今后软体体系结构研究和实践的重点之一。

设计工具和环境

软体体系结构设计既然作为软体工程的一部分，它的计算机辅助实现手段是相当重要的。我们应当开发出一些软体工具来实现体系结构的描述和分析，开发阶段转换工具，以实现阶段成果的自动转换，例如，把需求规格说明自动转换为构件等。目前关于这方面的研究成果很少，特别是可以套用到实际项目开发中的工具和环境就更少。

体系结构再工程

当今软体系统的规模变得越来越大，结构也越来越複杂，同时从头开始构建的大系统数量在急剧地减少，因而很多遗留系统正在被逐步地利用。从遗留系统软体代码和系统中抽取结构信息，经过描述、统一、抽象、一般化与实例化等处理，可总结出系统的体系结构。

在这种情况下，软体再工程变得越来越重要，因为它提供了一条把遗留系统转换为可进化系统的现实可行的途径，是一种可以改进人们对软体的理解和改进软体本身的活动。这类研究的目的是为一些特定的套用领域的软体系统提供一些体系结构框架，如控制系统、移动机器人和用户接口界面等。通过这些框架可以很方便地构造一个新的软体系统。

作　者：(美)肖

《软体体系结构》

出版社：清华大学出版社

出版时间： 2007

ISBN: 9787302145509

开本：16

定价: 29.80 元

软体体系结构作为从软体设计抽象出来的一门新兴学科，目前已经成为软体工程一个重要研究领域。本书作者MaryShaw和DavidGarlan作为软体体系结构最早的研究者，在体系结构领域做出了大量先导性的工作。

本书共有8章：绪论、软体体系结构风格、案例研究、共享信息系统、软体体系结构描述、软体体系结构的分析与评估、特定领域的软体体系结构和流行的软体体系结构等。本书第1-4章主要译自MaryShaw和DavidGarlan的着作。根据目前软体体系结构的现状、以及编译者多年的教学实践经验，在第1章和第5章加入了部分新的内容，并重新编写了第6章、第7章和第8章。其中第6，7章是在参考了大量相关研究的基础上，结合作者在图书馆领域的亲身实践编写的。

本书可以作为计算机专业研究生和高年级本科生的软体体系结构课程的教材或参考书，也可作为软体开发人员的参考手册。

第1章　绪论

1.1　什幺是软体体系结构

1.2　软体体系结构研究的内容和範畴

1.3　体系结构设计原则

1.4　软体体系结构研究的现状

1.5　全书的安排

第2章　体系结构风格

2.1　体系结构风格

2.2　管道过滤器

2.3　数据抽象和面向对象组织结构

2.4　事件驱动，隐式调用

2.5　分层系统

2.6　知识库

2.7　解释器

2.8　过程控制

2.9　其他常见的体系结构

2.10　异构体系结构

第3章　案例研究

3.1　上下文关键字

3.2　仪器软体

3.3　移动机器人

3.4　定速巡航控制

3.5　複合混合风格的三个案例

第4章　共享信息系统

第5章　软体体系结构描述

第6章　软体体系结构的分析与评估

第7章　特定领域的软体体系结构

第8章　流行的软体体系结构

参考文献

bn-qiange