1、第2章 软件体系结构 第2章 软件体系结构 2.1 软件体系结构的产生与发展软件体系结构的产生与发展2.2 软件体系结构建模软件体系结构建模2.3 基于体系结构的描述基于体系结构的描述2.4 基于体系结构的软件设计基于体系结构的软件设计2.5 小结小结第2章 软件体系结构 2.1 软件体系结构的产生与发展软件体系结构的产生与发展20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要。软件危机的程度日益加剧，现有的软件工程方法对此显得力不从心。对于大规模的复杂软件
2、系统来说，对总体的系统结构设计和规格说明的选择比起对计算的算法和数据结构的选择已经变得明显重要很多。在此背景下，人们认识到软件体系结构的重要性，并认为对软件体系结构的系统、深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径。第2章 软件体系结构 自从软件系统首次被分成许多模块，模块之间有相互作用，组合起来有整体的属性，软件系统就具有了体系结构。好的开发者常常会使用一些体系结构模式作为软件系统结构的设计策略，但他们并没有规范地、明确地表达出来，这样就无法将他们的知识与别人交流。软件体系结构是设计抽象的进一步发展，满足了更好地理解软件系统，更方便地开发更大、更复杂的软件系统的需
3、要。事实上，软件总是有体系结构的，不存在没有体系结构的软件。体系结构(Architecture)一词在英文里就是“建筑”的意思。把软件比作一座楼房，从整体上讲，是因为它有基础、主体和装饰，即操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。从细节上来第2章 软件体系结构 看每一个程序也是有结构的，早期的结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构，也就是它的体系结构。结构化程序的程序(表达)结构和(计算的)逻辑结构的一致性及自顶向下的开发方法自然而然地形成了体系结构。由于在结构化程序设计时代程序的规模不大，通过强调结构化程序设计方法学，自顶
4、向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构，所以并未去特别研究软件体系结构。第2章 软件体系结构 我们可以作个简单的比喻，结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大厦。构件怎样搭配才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种应用领域需要什么构件(医院、工厂、旅馆)？有哪些实用、美观、强度高、造价合理的构件骨架使建造出来的建筑(即体系结构)更能满足用户的需求？如同土木工程进入到现代建筑学一样，软件也从传统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的
5、体系结构，寻求建构最快、成本最低、质量最好的构造过程。第2章 软件体系结构 软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法。最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的一个最新的研究方向和独立的学科分支。软件体系结构研究的主要内容涉及软件体系结构描述、软件体系结构风格、软件体系结构评价和软件体系结构的形式化方法等。解决好软件的重用、质量和维护问题，是研究软件体系结构的根本目的。第2章 软件体系结构 2.1.1 软件体系结构的定义软件体系结构的定义虽然软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被
6、大家所公认的定义。许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画，较为典型的定义有：(1)Dewayne Perry和Alex Wolf曾这样定义：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。这一定义注重区分处理构件、数据构件和连接构件，该特点在其他的定义和方法中基本上得到了保持。第2章 软件体系结构(2)Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。体系结构
7、问题包括总体组织和全局控制，通信协议，同步与数据存取，给设计元素分配特定功能，设计元素的组织、规模和性能，在各设计方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，包括全局组织和全局控制结构，关于通信、同步与数据存取的协议，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等。第2章 软件体系结构(3)Kruchten指出，软件体系结构有四个角度，它们从不同方面对系统进行描述：概念角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织。(4)
8、Hayes Roth则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。(5)David Garlan和Dewne Perry于1995年在IEEE软件工程学报上又发表了如下定义：软件体系结构是一个程序/系统各构件的结构及其相互关系，以及进行设计的原则和随时间进化的指导方针。第2章 软件体系结构(6)Barry Boehm和他的学生提出，一个软件体系结构包括一个软件和系统构件、互联及约束的集合、一个系统需求说明的集合以及一个基本原理，用以说明这一构件、互联和约束能够满足系统需求。(7)1997年，Bass、Ctements和Kazman在使
9、用软件体系结构一书中给出如下定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件外部的可见特性及其相互关系。其中，“软件外部的可见特性”是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。第2章 软件体系结构 综上所述，软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，而且显示了系统需求和构成元素之间的对应关系，提供了一些设计决策的基本原理。第2章 软件体系结构 2.1.2 软件体系结构的发展史软件体系结构的发展史在软件系
10、统的规模迅速增大的同时，软件开发方法也经历了一系列的变革。在此过程中，软件体系结构也由最初模糊的概念发展成为渐趋成熟的理论和技术。20世纪70年代以前，尤其是在以ALGOL 68为代表的高级语言出现以前，软件开发基本上都是汇编程序设计，此阶段系统规模较小，很少明确考虑系统结构，一般不存在系统建模工作。70年代中后期，由于结构化开发方法的出现与广泛应用，软件开发中出现了概要设计与详细设计，而且主要任务是数据流设计与控制流设计，因此，此时软件结构已作为一个明确的概念出现在系统的开发中。第2章 软件体系结构 20世纪80年代初到90年代中期，是面向对象开发方法兴起与成熟的阶段。由于对象是数据与基于数
11、据之上操作的封装，因而在面向对象开发方法下，数据流设计与控制流设计则统一为对象建模。同时，面向对象方法还提出了一些其他的结构视图，如在OMT(Object Modeling Technology，对象建模技术)方法中提出了功能视图、对象视图与动态视图(包括状态图和事件追踪图)；在Booch方法中则提出了类视图、对象视图、状态迁移图、交互作用图、模块图、进程图；而1997年出现的统一建模语言(UML)则用功能模型(用例视图)、静态模型(包括类图、对象图、构件图、包图)、动态模型(协作图、顺序图、状态图和活动图)、配置模型(配置图)描述应用系统的结构。第2章 软件体系结构 20世纪90年代以后则进
12、入基于构件的软件开发阶段，该阶段以过程为中心，强调软件开发采用构件化技术和体系结构技术，要求开发出的软件具备很强的自适应性、互操作性、可扩展性和可重用性。此阶段中，软件体系结构已经作为一个明确的文档和中间产品存在于软件开发过程中；同时，软件体系结构作为一门学科逐渐得到人们的重视，并成为软件工程领域的研究热点。因而Perry和Wolf认为：未来的年代将是研究软件体系结构的时代。纵观软件体系结构技术的发展过程，从最初的“无体系结构”设计到现行的基于体系结构的软件开发，可以认为经历了四个阶段：第2章 软件体系结构(1)“无体系结构”设计阶段，以汇编语言进行小规模应用程序开发为特征。(2)萌芽阶段，出
13、现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征。(3)初期阶段，出现了从不同侧面描述系统的结构模型，以UML为典型代表。(4)高级阶段，以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了体系结构模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型为标志。由于概念尚不统一，描述规范也不能达成一致认识，在软件开发实践中软件体系结构尚不能发挥重要作用。第2章 软件体系结构 2.1.3 软件体系结构的研究现状软件体系结构的研究现状(1)形成研究热点，仍处于非形式化水平。自20世纪90年代后期以来，软件体系结构的研究成为一个热点。广大软件工作者已经认识到软件体系
14、结构研究的重大意义和它对软件系统设计开发的重要性，开展了很多研究和实践工作。从软件体系结构研究的现状来看，当前的研究和对软件体系结构的描述，在很大程度上来说还停留在非形式化的基础上。软件构架师仍然缺乏必要的工具，这种工具应该是显式描述、有独立性的形式化工具。第2章 软件体系结构 在目前通用的软件开发方法中，对软件体系结构的描述通常采用非形式化的图和文本，不能描述存在于构件之间的接口，更不能描述不同的系统组成成分间的组合关系。这种描述方法难以被开发人员理解，不能用来分析其一致性和完整性等特性。当一个软件系统中的构件几乎以一种非形式化的方法描述时，系统的重用性也会受到影响，在设计一个系统结构过程中
15、的努力很难移植到另一个系统中去。对系统构件和连接关系的结构化假设没有得到显式的、形式化的描述时，把这样的系统构件移植到另一个系统中去将是有风险的，甚至是不可能的。第2章 软件体系结构(2)软件体系结构的形式化方法研究。软件体系结构研究如果仅仅停留在非形式化的框图阶段，已经难以适应进一步发展的需要。为支持基于体系结构的开发，需要有形式化建模符号、体系结构说明的分析与开发工具。从软件体系结构研究的现状来看，在这一领域近来已经有不少进展，其中比较有代表性的是美国卡耐基梅隆大学(Carnegie Mellon University)的Robert J.Allen于1997年提出的Wright系统。Wr
16、ight是一种结构描述语言，该语言基于一种形式化的、抽象的系统模型，为描述和分析软件体系结构和结构化方法提供了一种实用的工具。Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法，它使用显式的、独立的连接模型来作为交互的方式，这使得该系统可以用逻辑谓词符号第2章 软件体系结构 系统，而不依赖特定的系统实例来描述系统的抽象行为。该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。从这些特性的分析来说，Wright系统的确适用于对大型系统的描述和分析。(3)软件体系结构的建模研究。研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模的侧重
17、点的不同，可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。在这5种模型中，最常用的是结构模型和动态模型。这一问题将在后续章节中进一步详细阐述。第2章 软件体系结构(4)发展基于体系结构的软件开发模型。软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为以下三种类型：以软件需求完全确定为前提的瀑布模型。在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型等。以形式化开发方法为基础的变换模型。第2章 软件体系结构 所有开发方法都是要解决需求
18、与实现之间的差距，但是，这三种类型的软件开发模型都存在这样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程。因此，研究人员在发展基于体系结构的软件开发模型方面做了一定的工作。(5)软件产品线体系结构的研究。软件体系结构的开发是大型软件系统开发的关键环节。体系结构在软件生产线的开发中起着至关重要的作用。在这种开发生产中，基于同一个软件体系结构，可以创建具有不同功能的多个系统。在软件产品族之间共享体系结构和一组可重用的构件，可以增加软件工程和降低开发、维护成本。第2章 软件体系结构 一个产品线代表着一组具有公共的系统需求集的软件系统，它们都是根据基本的用户需求对标准的产品线构架进行定制，将可
19、重用构件与系统独有的部分集成而得到的。采用软件生产线模式进行软件生产，将产生巨型编程企业，但目前生产的软件产品族大部分是处于同一领域的。第2章 软件体系结构 2.1.4 软件体系结构的影响软件体系结构的影响软件体系结构贯穿于软件研发的整个生命周期，具有重要的影响。这主要从以下三个方面来进行考察：(1)相关人员之间的交流。软件体系结构是一种常见的对系统的抽象。代码级别的系统抽象仅仅可以成为程序员的交流工具，而包括程序员在内的绝大多数系统的利益相关人员都借助软件体系结构来进行彼此理解、协商、达成共识或者相互沟通。第2章 软件体系结构(2)系统设计的前期决策。软件体系结构是我们所开发的软件系统最早期
20、设计决策的体现，而这些早期决策对软件系统的后续开发、部署和维护都有相当重要的影响，这也是能够对所开发系统进行分析的最早时间点。(3)可传递的系统级抽象。软件体系结构是关于系统构造以及系统各个元素工作机制的相对较小、却又能够突出反映问题的模型。由于软件系统具有的一些共通特性，这种模型可以在多个系统之间传递，特别是可以应用到具有相似质量属性和功能需求的系统中，并能够促进大规模软件的系统级复用。第2章 软件体系结构 2.1.5 软件体系结构的发展方向软件体系结构的发展方向当前，体系结构仍是一个非常新的研究领域，其概念还相当模糊。但软件体系结构作为软件工程领域中的一个组成部分，已经取得了长足的发展，受
21、到大多数软件系统设计和研究人员的重视。(1)各种体系结构描述语言之间的信息互换。现有的体系结构描述语言大多是与领域相关的，所以不利于对不同领域体系结构的说明，但这些针对不同领域的体系结构描述语言在某些方面又大同小异，造成资源的冗余。其实，大多数体系结构描述语言具有一系列的共同概念，如何用一种公共形式把各种语言综合起来，从而能够交换各种体系结构描述信息，将是今后软件体系结构研究和实践的重点之一。第2章 软件体系结构(2)设计工具和环境。软件体系结构设计既然作为软件工程的一部分，它的计算机辅助实现手段是相当重要的。我们应当开发出一些软件工具来实现体系结构的描述和分析，还应开发转换工具以实现阶段成果
22、的自动转换，例如把需求规格说明自动转换为构件等。目前关于这方面的研究成果很少，特别是可以应用到实际项目开发中的工具和环境就更少。(3)体系结构再工程。当今软件系统的规模变得越来越大，结构也越来越复杂，同时从头开始构建的大系统数量在急剧地减少，因而很多遗留系统正在被逐步地利用。从遗留系统软件代码和系统中抽取结构信息，经过描述、统一、抽象、一般化与实例化等处理，可总结出系统的体系结构。第2章 软件体系结构 在这种情况下，软件再工程变得越来越重要，因为它提供了一条把遗留系统转换为可进化系统的现实可行的途径，是一种可以改进人们对软件的理解和改进软件本身的活动。这类研究的目的是为一些特定的应用领域的软件
23、系统提供一些体系结构框架，如控制系统、移动机器人和用户接口界面等，通过这些框架可以很方便地构造一个新的软件系统。第2章 软件体系结构 2.2 软件体系结构建模软件体系结构建模研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模的侧重点的不同，可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。在这5种模型中，最常用的是结构模型和动态模型。(1)结构模型。结构模型是一个最直观、最普遍的建模方法。这种方法以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性
24、质等。研究结构模型的核心是体系结构描述语言。第2章 软件体系结构(2)框架模型。框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。(3)动态模型。动态模型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例如，描述系统的重新配置或演化。其动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。这类系统常是激励型的。(4)过程模型。过程模型研究构造系统的步骤和过程，因而其结构是遵循某些过程脚本的结果。(5)功能模型。功能模型认为体系结构由一组功能构件按层次组成，下层为上层提供服务。它可以看做是一种
25、特殊的框架模型。第2章 软件体系结构 2.2.1 “4+1”视图模型视图模型上面提到的5种模型各有所长，也许将5种模型有机地统一在一起，形成一个完整的模型来刻画软件体系结构更合适。例如，Kruchten在1995年提出了一个“4+1”的视角模型。“4+1”模型从5个不同的视角(包括逻辑视角、过程视角、物理视角、开发视角和场景视角)来描述软件体系结构，每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容。“4+1”模型如图2.1所示。第2章 软件体系结构 图2.1 “4+1”模型第2章 软件体系结构 1逻辑视图逻辑视图逻辑视图(logic view)主要支持系
26、统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图(class diagram)来描述逻辑视图。我们可以从Booch标记法中导出逻辑视图的标记法，从体系结构级的范畴来考虑这些符号，用Rational Rose进行体系结构设计。图2.2是逻辑视图中使用的符号集合。第2章 软件体系结构 图2.2 逻辑视图中使用的符号集合第2章 软件体系结构 类图用于表示类的存在以及类与类之
27、间的关系，是从系统构成的角度来描述正在开发的系统的。一个类的存在不是孤立的，类与类之间以不同方式互相合作，共同完成某些系统功能。关联关系表示两个类之间存在着某种语义上的联系，其真正含义要由附加在横线上的一个短语予以说明。在表示包含关系的图符中，带有实心圆的一端表示整体，相反的一端表示部分；在表示使用关系的图符中，带有空心圆的一端连接在请求服务的类，相反的一端连接在提供服务的类；在表示继承关系的图符中，箭头由子类指向基类。第2章 软件体系结构 逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型并使其贯穿于整个系统。例如，图2.3是某通信系统体系
28、结构(ACS)中的主要类。ACS的功能是在终端之间建立连接，这种终端可以是电话机、主干线、专用线路、特殊电话线、数据线或ISDN线路等，不同线路由不同的线路接口卡来支持。线路控制器对象的作用是译码并把所有符号加入到线路接口卡中；终端对象的作用是保持终端的状态，代表本条路线的利益参与协商服务；会话对象代表一组参与会话的终端，使用转换服务(目录、逻辑地址映射到物理地址、路由等)和连接服务，在终端之间建立语音路径。第2章 软件体系结构 图2.3 通信系统体系结构逻辑视图第2章 软件体系结构 对于更大规模的系统来说，体系结构级中可能包含数十甚至数百个类。例如，图2.4是一个空中交通管制系统的顶级类图，
29、该图包含了8组类。第2章 软件体系结构 图2.4 空中交通管制系统的顶级类图第2章 软件体系结构 2开发视图开发视图开发视图(development view)也称模块视图(module view)，主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。开发视图要考虑软件内部的需求，如软件开发的容易性、软件重用、软件的通用性，还要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。与逻辑视
30、图一样，我们可以使用Booch标记法中的某些符号来表示开发视图，如图2.5所示。第2章 软件体系结构 图2.5 开发视图中使用的标记符号第2章 软件体系结构 在开发视图中，最好采用46层子系统，而且每个子系统只能与同层或更低层的子系统通信，这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。而且，设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样可以保证应用程序的需求发生改变时，所做的改动最小。开发视图所用的风格通常是层次结构风格。例如，图2.6表示的是空中交通管制系统的5层结构图。图2.6是图2.4的开发视图。第1层和第2层组成了一个领域无关的分布式基础设施，贯
31、穿于整个产品线中，并且与硬件平台、操作系统或数据库管理系统等无关。第3层增加了空中交通管制系统的框架，以形成一个领域特定的软件体系结构。第4层使用该框架建立一个功能平台。第5层则依赖于具体客户和产品，包括了大部分用户接口以及外部系统接口。第2章 软件体系结构 图2.6 空中交通管制系统的5层结构第2章 软件体系结构 3进程视图进程视图进程视图(process view)侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性，进程视图强调并发性、分布性、系统集成性和容错能力。它也定义了逻辑视图中的各个类的操作具体是在哪一个线程(thread)中被执行的。进程视图可以描述成多层抽
32、象，每个级别分别关注不同的方面。在最高层抽象中，进程结构可以看做是构成一个执行单元的一组任务，也可看成一系列独立的、通过逻辑网络相互通信的程序，它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。通过进程视图可以从进程测量一个目标系统最终的执行情况。例如在以计算机网络作为运行环第2章 软件体系结构 境的图书管理系统中，服务器需对来自各个不同的客户机的进程进行管理，决定某个特定进程(如查询子进程、借还书子进程)的唤醒、启动、关闭等操作，从而控制整个网络协调、有序地工作。我们通过扩展Booch对Ada任务的表示法来表示进程视图。从体系结构角度来看，进程视图的标记元素如图2.7所示。第2章 软
33、件体系结构 图2.7 进程视图中使用的标记符号第2章 软件体系结构 有很多风格适用于进程视图，如管道和过滤器风格、客户/服务器(多客户/单服务器，多客户/多服务器)风格等。图2.8是2.2.1节中的ACS系统的局部进程视图。在图2.8中，所有终端均由同一个终端进程进行处理，由其输入队列中的消息驱动。控制器对象在组成控制器进程的三个任务之一中执行，慢周期(200ms)控制器任务扫描所有挂起(suspend)终端，把任何一个活动的终端置入快周期(10ms)控制器任务的扫描列表；快周期控制器任务检测任何显著的状态改变，并把改变的状态传递给主控制器任务；主控制器任务解释改变，通过消息与相应的终端进行通
34、信。在这里，通过共享内存来实现在控制器进程中传递消息的功能。第2章 软件体系结构 图2.8 ACS系统的局部进程视图第2章 软件体系结构 4物理视图物理视图物理视图(physical view)主要考虑如何把软件映射到硬件上，它通常要考虑系统性能、规模、可靠性等，以解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的结点上时，各视图中的构件都直接或间接地对应于系统的不同结点。因此，从软件到结点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响要小。大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一起，以多种形式出现，也可单独出现。图2.9是物理视图的标记元素集合。第
35、2章 软件体系结构 图2.9 物理视图中使用的标记符号第2章 软件体系结构 图2.10所示是一个大型ACS系统可能的硬件配置，图2.11和图2.12是进程视图的两个不同的物理视图映射，分别对应一个小型的ACS和一个大型的ACS。图中，C、F和K是三个不同容量的计算机类型，支持三个不同的可执行文件。第2章 软件体系结构 图2.10 ACS系统的物理视图第2章 软件体系结构 图2.11 具有进程分配的小型ACS系统的物理视图第2章 软件体系结构 图2.12 具有进程分配的大型ACS系统的物理视图第2章 软件体系结构 5场景场景场景(scenarios)可以看做是那些重要系统活动的抽象，它使4个视图
36、有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系；同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间的相互作用。场景可以用文本表示，也可以用图形表示。例如，图2.13是一个小型ACS系统的场景片段，相应的文本表示如下过程：小王的电话控制器检测和验证电话从挂机到摘机状态的转变，且发送一个消息以唤醒相应的终端对象。第2章 软件体系结构 终端分配一定的资源，且通知控制器发出某种拨号音。控制器接收所拨号码并传给终端。终端使用编号计划分析号码。当一个有效的拨号序列进入时，终端打开一个会话。从以上分析可知，逻辑视图和
37、开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统，则比较注重于从进程视图和物理视图来描述系统。第2章 软件体系结构 图2.13 本地呼叫场景的一个原型第2章 软件体系结构 2.2.2 软件体系结构的核心模型软件体系结构的核心模型综合软件体系结构的概念，体系结构的核心模型由五种元素组成：构件、连接件、配置(configuration)、端口(port)和角色(role)。其中构件、连接件和配置是最基本的元素。构件是具有某种功能的可重用的软件模板单元
38、，表示了系统中主要的计算元素和数据存储。构件有两种：复合构件和原子构件。复合构件由其他复合构件和原子构件连接而成；原子构件是不可再分的构件，底层由实现该构件的类组成。这种构件的划分提供了体系结构的分层表示能力，有助于简化体系结构的设计。第2章 软件体系结构 连接件表示了构件之间的交互。简单的连接件如管道(pipe)、过程调用(procedure call)、事件广播(event broadcast)等。更为复杂的交互有客户/服务器(client/server)通信协议、数据库和应用之间的SQL连接等。配置表示了构件和连接件的拓扑逻辑和约束。另外，构件作为一个封装的实体，只能通过其接口与外部环境
39、交互。构件的接口由一组端口组成，每个端口都表示了构件和外部环境的交互点。通过不同的端口类型，一个构件可以提供多重接口。一个端口可以非常简单，如过程调用，也可以表示更为复杂的界面(包含一些约束)，如必须以某种顺序调用的一组过程调用。第2章 软件体系结构 连接件作为建模软件体系结构的主要实体，同样也有接口。连接件的接口由一组角色组成，每一个角色都定义了该连接件表示的交互参与者。二元连接件有两个角色，如RPC的角色为caller和callee，pipe的角色是reading和writing，消息传递连接件的角色是sender和receiver。有的连接件有多于两个的角色，如事件广播有一个事件发布者角
40、色和任意多个事件接收者角色。综上所述，我们可将软件体系结构的核心模型表示为图2.14。第2章 软件体系结构 图2.14 软件体系结构的核心模型第2章 软件体系结构 2.2.3 软件体系结构的生命周期模型软件体系结构的生命周期模型对于软件项目的开发来说，一个清晰的软件体系结构是首要的。传统的软件开发过程可以划分为从概念直到实现的若干个阶段，包括问题定义、需求分析、软件设计、软件实现及软件测试等。软件体系结构的建立应在需求分析之后，软件设计之前。在建立软件体系结构时，设计者主要从结构的角度对整个系统进行分析，选择恰当的构件、构件间的相互作用以及它们的约束，最后形成一个系统框架以满足用户的需求，为软
41、件设计奠定基础。下面从各个阶段的功能出发，分析这几个层次之间的关系。第2章 软件体系结构 1需求分析阶段需求分析阶段需求分析阶段的任务是根据需求，决定系统的功能。在此阶段，设计者应对目标对象和环境做细致深入的调查，收集目标对象的基本信息，从中找出有用的信息。这是一个抽象思维、逻辑推理的过程，其结果是生成软件规格说明。需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，需求分析过程主要是获取用户需求，确定系统中所要用到的构件。第2章 软件体系结构 体系结构需求包括需求获取、生成类图、对类分组、把类打包成构件和需求评审等过程。其中需求获取主要是定义开发人员必须实现的软件功能，使得用
42、户能完成他们的任务，从而满足业务上的功能需求。与此同时，还要获得软件质量属性，满足一些非功能需求。获取了需求之后，就可以利用工具(例如Rational Rose)自动生成类图，然后对类进行分组，简化类图结构，使之更清晰。分组之后，再把类簇打包成构件，这些构件可以分组合并成更大的构件。最后进行需求评审，即组织一个由不同代表(如分析人员、客户、设计人员、测试人员)组成的小组，对体系结构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求、类的分组是否合理以及构件合并是否合理等。第2章 软件体系结构 2建立软件体系结构阶段建立软件体系结构阶段在这个阶段，体系结构设计师
43、主要从结构的角度对整个系统进行分析，选择恰当的构件，根据构件间的相互作用关系以及对它们的约束，形成一个系统框架以满足用户需求，为设计奠定基础。在建立体系结构的初期，选择一个合适的体系结构风格是首要的。选择了风格之后，把在体系结构需求阶段已确认的构件映射到体系结构中，将产生一个中间结构。然后，为了把所有已确认的构件集成到体系结构中，必须认真分析这些构件的相互作用和关系。一旦决定了关键构件之间的相互作用和关系，就可以在前面得到的中间结构的基础上进行细化。第2章 软件体系结构 3设计阶段设计阶段设计阶段主要是对系统进行模块化并决定描述各个构件间的详细接口、算法和数据类型，对上支持建立软件体系结构阶段
44、所形成的框架，对下提供实现基础。一旦设计了软件体系结构，我们必须邀请独立于系统开发的外部人员对体系结构进行评审。第2章 软件体系结构 4实现阶段实现阶段实现阶段将设计阶段设计的算法及数据类型用程序语言表示，以满足设计体系结构和需求分析的要求，从而得到满足设计需求的目标系统。整个实现过程是以复审后的文档化的体系结构说明书为基础的，每个构件都必须满足软件体系结构中说明的对其他构件的责任。这些决定(即实现的约束)是在系统级或整个项目范围内做出的，每个构件上工作的实现者是看不见的。在体系结构说明书中，已经定义了系统中的构件与构件之间的关系。在体系结构层次上，因为构件接口约束对外唯一地代表了构件，所以可
45、以从构件库中查找符合接口约束的构件，必要时还可开发新的满足要求的构件。第2章 软件体系结构 然后，按照设计提供的结构，通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成。最后一步是测试，包括单个构件的功能性测试和组装应用的整体功能与性能测试。由此可见，软件体系结构在系统开发的全过程中起着基础的作用，是设计的起点和依据，同时也是装配和维护的指南。与软件本身一样，软件体系结构也有其生命周期，图2.15形象地表示了体系结构的生命周期。第2章 软件体系结构 图2.15 软件体系结构的生命周期模型第2章 软件体系结构(1)软件体系结构的非形式化描述。在软件体系结构的非形式化描述(s
46、oftware architecture informal description)阶段，对软件体系结构的描述尽管常用自然语言，但是该阶段的工作却是创造性和开拓性的。一种软件体系结构产生时，其思想通常是简单的，并常常由软件设计师用非形式化的自然语言表示概念、原则。例如，客户/服务器体系结构就是为适应分布式系统的要求，从主从式演变而来的一种软件体系结构。第2章 软件体系结构(2)软件体系结构的规范描述和分析。软件体系结构的规范描述和分析(software architecture specification and analysis)阶段通过运用合适的形式化数学理论模型对第1阶段的体系结构的非形
47、式化描述进行规范定义，从而得到软件体系结构的形式化规范描述，以使软件体系结构的描述精确、无歧义，进而分析软件体系结构的性质，如无死锁性、安全性、健壮性等。分析软件体系结构的性质有利于在系统设计时选择合适的软件体系结构，避免盲目选择。第2章 软件体系结构(3)软件体系结构的求精及其验证。软件体系结构的求精及其验证(software architecture refinement and verification)阶段对已设计好的软件体系结构进行验证和求精。大型系统的软件体系结构总是通过从抽象到具体、逐步求精而达到的。一般来说，抽象是人们在处理复杂问题和对象时必不可少的思维方式，软件体系结构也不例
48、外，但是过高的抽象却使软件体系结构难以真正在系统设计中实施。如果软件体系结构的抽象粒度过大，就需要对体系结构进行求精、细化，直至其能够在系统设计中实施为止。在软件体系结构的每一步求精过程中，需要对不同抽象层次的软件体系结构进行验证，以判断较具体的软件体系结构是否与较抽象的软件体系结构的语义一致，能否实现抽象的软件体系结构。第2章 软件体系结构(4)软件体系结构的实施。软件体系结构的实施(software architecture enactment)阶段将求精后的软件体系结构实施于系统的设计中，并将软件体系结构的构件和连接件等有机地组织在一起，形成系统设计的框架。(5)软件体系结构的演化和扩展
49、。当体系结构实施后，就进入软件体系结构的演化和扩展(software architecture evolution and extension)阶段。在实施软件体系结构时，性能、容错、安全性、互操作性、自适应性等非功能性质将影响软件体系结构的扩展和改动，这称为软件体系结构的演化。由于对软件体系结构的演化常常由非功能性质的非形式化需求描述引起，因而需要重复第(1)步。如果由于功能和非功能性质对以前的软件体系结构进行演化，就要涉及软件体系结构的理解，需要进行软件体系结构的逆向工程和再造工程。第2章 软件体系结构(6)软件体系结构的提供、评价和度量。软件体系结构的提供、评价和度量(software
50、architecture provision，evaluation and metric)阶段根据将软件体系结构实施于系统设计后系统的实际运行情况，对软件体系结构进行定性的评价和定量的度量，以利于对软件体系结构的重用，并取得经验教训。(7)软件体系结构的终结。如果一个软件系统的软件体系结构进行了多次演化和修改，软件体系结构已变得难以理解，甚至不能达到系统设计的要求，不能适应系统的发展，这就说明该软件体系结构已经过时，应该摈弃，以全新的满足系统设计要求的软件体系结构取而代之。这个阶段被称为软件体系结构的终结(software architecture termination)阶段。第2章 软件体
