软件体系结构论文.docx
《软件体系结构论文.docx》由会员分享，可在线阅读，更多相关《软件体系结构论文.docx（11页珍藏版）》请在冰豆网上搜索。
软件体系结构论文
论软件体系结构
软件体系结构：
软件总体结构的抽象表示，或以此为研究对象的学科。
软件体系结构具有如下几种含义。
规定性含义软件体系结构由结构元集、结构形以及结构理三部分组成，即软件体系结构≡（结构元集，结构形，结构理）其中，结构元集为一组构成软件的结构元。
结构元有三类，即处理元、信息元和连接元。
处理元为对信息元施行处理的构件，信息元为处理元的处理对象，连接元负责构件间的连接。
结构形包括特性、联系以及权重。
特性用以约束结构元的选取，联系则约束结构元间的交互与组织，权重表示特性及联系的重要程度。
结构理刻画体系结构人员选取体系结构风格、结构元、结构形的动因与根据。
体系结构风格是各种特定体系结构中结构元与结构形的抽象，它不如特定体系结构约束严格，亦不如特定体系结构完备。
例如，有分布式风格，多进程风格等，它们强调的只是特定体系结构的某些方面。
描述性含义软件体系结构由构件集、连件集、模式以及约束集四部分组成，即软件体系结构（构件集，连件集，模式，约束集）其中，构件集表示构成软件的一组组成元素，连件集为一组连件，用以刻画各构件间的交互，模式为软件设计风格的描述，反映由构件及连件构成软件的构成原则，约束集中的约束表示对模式所加的限制条件。
例如，在客户一服务器系统中，客户与服务器均为构件，构件间交互的描述（如过程调用、事件广播等）为连件，客户一服务器模式为模式，具体系统中对模式所加条件为约束。
多视面含义软件体系结构为软件的一个或多个结构，每一结构反映一种视面，即软件体系结构；结构集结构≡（构件集，外部可见特性集，联系集）其中，构件集表示构成软件的一组组成元素，外部可见特性反映为其他构件可利用该构件所作的假定，联系用以沟通相关构件。
由于软件体系结构可有多个结构，从而可有多类构件、多种联系，故在定义中并不指明何类构件与何种联系。
常用的结构类型有模块结构、进程结构和概念结构等。
常用的视面有代码视面、模块视面、执行视面以及概念视面。
其中惯常理解的软件体系结构反映了概念视面。
学科含义以前述各种含义的软件体系结构为研究对象的学科或谓在研究与开发前述各种含义的软件体系结构中所涉及的理论、原则、方法、技术所形成的学科。
软件体系结构发展不久，迄今未见被普遍接受的单一定义，然而，它对软件的后续开发过程以及品质量的影响举足轻重，已成为软件工程的重要研究方面，且其重要性将与日俱增。
软件设计自从计算机诞生之日起，就存在着显式或是隐式的危机。
而1968年，在Garmish召开的国际软件工程会议上人们迫切地感到了软件危机给计算机软件产业的发展带来的巨大阻力。
软件危机的两个最大的问题便是：
随着计算机软件技术的日新月异，软件的规模越来越大，软件复杂度越来越高。
伴随着这两个问题的日益突出，整个软件系统结构的设计与规格说明便显得比在早期软件开发中占有重要地位的算法选择和计算问题的数据结构更为重要。
代码级别的软件复用已经远远不能满足大型软件开发的需求。
由此便引入了软件体系结构这一概念。
软件产品线体系结构的研究
软件体系结构的开发是大型软件系统开发的关键环节。
体系结构在软件生产线的开发中具有至关重要的作用，在这种开发生产中，基于同一个软件体系结构，可以创建具有不同功能的多个系统。
在软件产品族之间共享体系结构和一组可重用的构件，可以增加软件工程和降低开发和维护成本。
一个产品线代表着一组具有公共的系统需求集的软件系统，它们都是根据基本的用户需求对标准的产品线构架进行定制，将可重用构件与系统独有的部分集成而得到的。
采用软件生产线式模式进行软件生产，将产生巨型编程企业。
但目前生产的软件产品族大部分是处于同一领域的。
软件体系结构的形式化方法研究
软件体系结构研究如果仅仅停留在非形式化的框图阶段，已经难以适应进一步发展的需要。
为支持基于体系结构的开发，需要有形式化建模符号、体系结构说明的分析与开发工具。
从软件体系结构研究的现状来看，在这一领域近来已经有不少进展，其中比较有代表性的是美国卡耐基梅隆大学（CarnegieMellonUniversity）的RobertJ．A11en于l997年提出的Wright系统。
Wright是-种结构描述语言，该语言基于一种形式化的、抽象的系统模型，为描述和分析软件体系结构和结构化方法提供了一种实用的工具。
Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。
它使用显式的、独立的连接模型来作为交互的方式，这使得该系统可以用逻辑谓词符号系统，而不依赖特定的系统实例来描述系统的抽象行为。
该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。
从这些特性的分析来说，Wright系统的确适用于对大型系统的描述和分析。
软件体系结构的定义：
从抽象角度来说，软件体系结构包含对于用于构建系统的元素，元素之间的互操作，指导系统构成的模式以及模式上的约束的描述。
大体上说来，一个特定系统风格就是由组件集以及各个组件集之间的交互定义的。
这些软件系统风格便可以用在大型系统设计中。
虽然人们在很多年前就认识到了软件体系结构的设计使整个软件开发中的关键元素，但是对于软件体系结构的定义直至今日也没有达成一个共识。
以下是在软件体系结构理论发展的若干年中比较有影响力的定义：
软件体系结构是具有一定形式的结构化元素，即组件的集合，包括处理组件、数据组件和连接组件。
处理组件负责对数据进行加工，数据组件是被加工的信息，连接组件把体系结构的不同部分组组合连接起来。
这一定义注重区分处理组件、数据组件和连接组件，这一方法在其他的定义和方法中基本上得到保持。
软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。
体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。
软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计组件功能定义，物理分布与合成，设计方案的选择、评估与实现等。
一个程序或计算机系统的软件体系结构包括一个或一组软件组件、软件组件的外部的可见特性及其相互关系。
其中，“软件外部的可见特性”是指软件组件提供的服务、性能、特性、错误处理、共享资源使用等。
通过对若干定义的学习和研究，我将为软件体系结构下一个这样的定义：
软件体系结构为软件系统提供了结构、行为和属性的高级抽象，由构成系统的元素描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理，是构建于软件系统之上的系统级复用。
软件体系结构的影响【DefinitionofSoftwareArchitecture】
软件体系结构贯穿于软件研发的整个生命周期内，具有重要的影响。
这主要从以下三个方面来进行考察：
（1）利益相关人员之间的交流：
软件体系结构是一种常见的对系统的抽象，代码级别的系统抽象仅仅可以成为程序员的交流工具，而包括程序员在内的绝大多数系统的利益相关人员都借助软件体系结构来进行彼此理解、协商、达成共识或者相互沟通的基础。
（2）系统设计的前期决策：
软件体系结构是我们所开发的软件系统最早期设计决策的体现，而这些早期决策对软件系统的后续开发、部署和维护具有相当重要的影响。
这也是能够对所开发系统进行分析的最早时间点。
（3）可传递的系统级抽象：
软件体系结构是关于系统构造以及系统各个元素工作机制的相对较小、却又能够突出反映问题的模型。
由于软件系统具有的一些共通特性，这种模型可以在多个系统之间传递，特别是可以应用到具有相似质量属性和功能需求的系统中，并能够促进大规模软件的系统级复用。
常用软件体系结构
一个小型的软件可能具有一种软件体系结构，而大型的软件一般由多种软件体系结构组成，软件体系结构没有定性的说只有几种风格，但是经过长期的大型软件设计与分析，人们总结出了一些最为常用的软件体系结构风格，总共有五种，分别是：
◆数据流风格【DataFlowStyle】
数据流风格的体系结构中，我们可以在系统中找到非常明显的数据流，处理过程通常在数据流的路线上“自顶向下、逐步求精”，并且，处理过程依赖于执行过程，而不是数据到来的顺序。
比较有代表性的是批作业序列风格、管道/过滤器风格。
在管道/过滤器风格的软件体系结构中，每个组件都有一组输入和输出，组件读输入的数据流，经过内部处理，然后产生输出数据流。
这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。
因此，这里的组件被称为过滤器，这种风格的连接器就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。
此风格特别重要的过滤器必须是独立的实体，它不能与其它的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。
一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
编译器系统就具备典型的管道系统风格的体系结构。
在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。
管道/过滤器风格的软件体系结构具有许多很好的特点：
（1） 使得软组件具有良好的隐蔽性和高内聚、低耦合的特点；
（2） 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；
（3） 支持软件复用。
（4） 系统维护和增强系统性能简单。
新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；
（5） 允许对一些如吞吐量、死锁等属性的分析；
（6） 支持并行执行。
每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。
这比下面将要阐述的一种“主-子程序风格”的单线程操作要灵活得多。
这种系统结构的弱点是：
（1） 通常导致进程成为批处理的结构。
这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
（2） 不适合处理交互的应用。
当需要增量地显示改变时，这个问题尤为严重。
（3） 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
◆调用/返回风格的体系结构【Call-and-ReturnStyle】
调用/返回风格的体系结构在过去的30年之间占有重要的地位，是大型软件开发中的主流风格的体系结构。
这类系统中呈现出比较明显的调用/返回的关系。
调用/返回风格在常用软件体系结构风格中内涵是比较丰富的，分为：
主-子程序风格，面向对象概念中的对象体系结构风格，以及层次型系统风格三种子风格。
主-子程序风格的体系结构是一种经典的编程范型，主要应用在结构化程序设计当中。
这种风格的主要目的是将程序划分为若干个小片段，从而使程序的可更改性大大提高。
主-子程序体系结构风格有一定的层次性，主程序位于一层，下面可以再划分一级子程序，二级子程序甚至更多。
需要特别注意的是主-子程序体系结构风格是单线程控制的。
同一时刻只有一个孩子结点的子程序可以得到父亲结点的控制。
总结一下主-子程序体系结构风格的特点：
（1）由于单线程控制，计算的顺序得以保障。
（2）并且有用的计算结果在同一时刻只会产生一个。
（3）单线程的控制可以直接由程序设计语言来支持
（4）分层推理机制：
子程序的正确性与它调用的子程序的正确性有关。
对象风格的体系结构：
抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。
这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。
这种风格的组件是对象，或者说是抽象数据类型的实例。
对象是一种被称作管理者（Manager）的组件，因为它负责保持资源的完整性（例如实现对属性，方法的封装）。
对象是通过函数和过程调用来交互的。
对象风格的体系结构具有以下的特点：
（1）对象抽象使得组件和组件之间的操作以黑箱的方式进行。
（2）封装性使得细节内容对外部环境得以良好的隐藏。
对象之间的访问是通过方法调用来实现的。
（3）考虑操作和属性的关联性，封装完成了相关功能和属性的包装，并由对象来对它们进行管理。
（4）使用某个对象提供的服务并不需要知道服务内部是如何实现的。
数据抽象和面向对象风格的体系结构在现代的软件开发中广泛应用。
但是，面向对象体系结构也存在着某些问题：
（1）对象之间的耦合度比较紧：
为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。
只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。
（2）必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。
例如A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是不可预测的。
分层风格的体系结构是将系统组织成一个层次结构，每一层为上层提供服务，并作为下层的客户端。
在分层风格的体系结构中，一般内部的层只对相邻的层可见。
层之间的连接器（conector）通过决定层间如何交互的协议来定义。
这种风格支持基于可增加抽象层的设计。
这样，允许将一个复杂问题分解成一个增量步骤序列的实现。
由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。
分层风格的体系结构有许多可取的属性：
（1）支持基于抽象程度递增的系统设计：
使设计者可以把一个复杂系统按递增的步骤进行分解；
（2）支持功能增强：
因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；
（3）支持复用：
只要提供的服务接口定义不变，同一层的不同实现可以交换使用。
这样，就可以定义一组标准的接口，而允许各种不同的实现方法。
但是，分层风格的体系结构也有其不足之处：
（1）并不是每个系统都可以很容易地划分为分层风格的体系结构，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；
（2）很难找到一个合适的、正确的层次抽象方法。
总结一下调用/返回风格的软件体系结构：
这类架构中的组件就是各种不同的操作单元（例如，子程序、对象、层次），而连接器则是这些对象之间的调用关系（例如，主-子程序调用，或者对象的方法以及层次体系结构中的协议）。
调用-返回结构的优点在于，容易将大的架构分解为一种层次模型，在较高的层次，隐藏那些比较具体的细节，而在较低的层次，又能够表现出实现细节。
在这类体系结构中，调用者和被调用者之间的关系往往比较紧密。
在这样的情况下，架构的扩充通常需要被调用者和所有调用者都进行适当的修改。
◆虚拟机风格的体系结构【VirtualMachineStyle】
虚拟机风格的体系结构设计的初衷主要是考虑体系结构的可移植性。
这种体系结构力图模拟它运行于其上的软件或者硬件的功能。
这种体系结构在很多场合都有用途：
⏹ 它可以被用于模拟或者测试尚未构建成的软硬件系统，它还可以模拟灾难，（例如飞行模拟器，安全攸关的系统，这些在现实生活中测试太过于危险并且牺牲太大。
⏹ 虚拟机的例子有：
解释器，机遇规则的系统，通用语言处理程序。
我们用解释器作一个例子，通过虚拟机特定模块的解释步骤如下所示：
⏹ 解释引擎从被解释的模块中选择一条指令；
⏹ 基于这条指令，引擎更新虚拟机内部的状态；
⏹ 上述过程反复执行；
由于对程序的中断，查询和在运行时的修改能力，通过虚拟机来执行模块大大提高了其稳定性，但是由于在执行过程中附加了额外的计算量，性能方面必然会受到影响。
在虚拟机结构中，组件是被模拟的机器和实际的机器，而连接器则是一组转换规则，这组转换规则能够在保持被模拟的机器中的虚拟状态和逻辑不变的前提下，将操作转换为实际的机器中能够被理解的操作。
这类架构的突出特点是：
⏹ 在虚拟机器环境中运行的代码不必须了解虚拟机的具体细节。
⏹ 一旦运行环境发生变化，只需要重写虚拟机本身，而不是整个系统。
⏹ 通常虚拟机会限制在其中运行的软件的行为，特别是那些以实现跨平台为目的的虚拟机，如Java虚拟机和.NETCLR。
这类虚拟机往往希望虚拟机器的代码完全不了解虚拟机以外的现实世界。
这是在灵活性、效率与软件跨平台性之间进行的一种折衷。
⏹ 能够使系统的结构更具层次性，使用虚拟机提供的设施编写的代码，可以不考虑虚拟机以外的实际环境，而在正确地实现了这种虚拟机的环境中执行。
虚拟机架构的缺点是灵活性略显不足，无法最大限度地发挥操作系统和硬件的性能（在
虚拟机中运行的应用程序并不了解实际的硬件和操作系统的特性。
◆独立组件风格的体系结构【IndependentComponentsStyle】
独立组件风格的体系结构由很多独立的通过消息交互的过程或者对象组成。
这种软件体系结构通过对各自部分计算的解耦操作来达到易更改的目的。
它们之间相互的传输数据，但是不直接控制双方。
消息可能传递给：
指定的参与项（交互过程风格）；
未指定的参与项使用发布/登陆范型（事件风格）。
事件系统风格是独立组件风格的一个子风格。
其中的每一个独立组件在它们的相关环境中声明它们希望共享的数据，这个环境便是未指定的参与项。
事件系统会充分利用消息管理器（messagemanager）在消息传递到消息管理器的时候来管理组件之间的交互，和调用组件。
组件会注册它们希望提供或者希望收到的信息的类型。
随后它们会发送这个注册的类型给消息管理器，这个消息管理器可能是一个对象引用。
通信处理风格也是独立组件风格的一个子风格。
这是一个多处理系统。
客户端-服务器风格是一个非常著名的风格。
这种风格设计的目标是达到可测量性的需求。
服务器用于向一个或者多个客户端提供数据服务，这个环境经常与网络连接一起出现。
客户端向服务器发出一个请求，服务器同步地或者异步地执行客户端的请求。
如果工作是同步的，服务器将返回给客户端数据和客户端控制权，如果是异步的，服务器只返回给客户端数据，因为这个时候服务器有自己的控制线程。
独立组件架构的特点是：
⏹ 系统由松耦合的一些独立运行的计算单元构成，这些单元之间通过消息传递信息。
一般情况下，这些独立的计算单元能够自主地完成一些计算任务。
⏹ 消息的发出者通常并不知道谁会接收并处理这些消息，更不了解这些消息是如何被处理的。
⏹ 由于系统基于消息，因此有较好的并发性能，容错性和可伸缩性。
⏹ 独立组件系统中通常不存在比较明显的主-从结构。
通常只有一个比较弱的服务器，甚至没有服务器。
◆仓库风格的体系结构【DataCentered（Repositories）Style】
在仓库风格中，有两种不同的组件：
中央数据结构（用于说明当前状态），和独立组件（在中央数据存贮上执行），仓库与外组件间的相互作用在系统中会有大的变化。
控制原则的选取产生两个主要的子类。
若输入流中某类时间触发进程执行的选择，则仓库是一个传统型数据库；系统中的组件通常包括数据存储区，以及与这些存储区进行交流的进程或处理单元，而连接器则是对于存储区的访问。
这类系统中，数据处理进程往往并不直接发生联系，它们之间的联系主要是通过共享的数据存储区来完成的。
这种现象非常类似于在独立组件架构中的情况。
另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。
（1）知识源：
知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。
（2）黑板数据结构：
黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
（3）控制：
控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
仓库风格的体系结构的优点在于可扩充性比较强，模块间耦合比较松散，便于扩充。
软件体系结构风格为系统级别的软件复用提供了可能。
然而，对于应用体系结构风格来说，由于视角的不同，系统设计师有很大的选择空间。
要为系统选择或设计某一个体系结构风格，必须根据特定项目的具体特点，进行分析比较后再确定，体系结构风格的使用几乎完全是特化的。
随着软件研发技术的不断进步，软件体系结构的五种模式也不能完全代表体系结构的基本构成了，从而诞生了：
正交软件体系结构，三层C/S体系结构，C/S与B/S混合软件体系结构等。
不同的结构有不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际需要进行选择，以解决实际问题。
升级会员 