第二章软件体系结构的研究与发展

《第二章软件体系结构的研究与发展》由会员分享，可在线阅读，更多相关《第二章软件体系结构的研究与发展（63页珍藏版）》请在金锄头文库上搜索。

1、第二章第二章 软件体系结构的研究与发展软件体系结构的研究与发展2.1 2.1 软件工程设计和软件体系结构软件工程设计和软件体系结构2.1.1 2.1.1 软件设计的目标软件设计的目标 软件设计的最终目标是在时间和各类资源环境的限制下，最大限度地满足用户的需要。但是，软件系统的应用领域问题在变化，软件的设计和硬件运行环境在变化，用户的需求在变化，这一切对软件设计提出了更高的要求。软件设计不仅需要完成系统设定的功能和性能要求，更需要在可理解、易维护、可扩充方面达到高的水平，以满足用户对软件需求不断变化的要求。为此，对软件提出了以下设计目标：1. 1. 设计应该是便于维护和升级的，因而应该是模块设计

2、应该是便于维护和升级的，因而应该是模块化的化的 设计应该是由那些易于替换、自成体系的基本组件构成的，这样，可以大大有利于初期的开发和后期的维护。2. 2. 设计应该是便于移植的设计应该是便于移植的 设计的部分以及整个设计都应该可以在不同的环境下获得重用。该设计目标的目的在于能够把开发成功的设计从一种环境移植到另一种环境下运行。 软件可移植性主要取决于移植先后运行环境的差异程度、软件描述语言的差别和软件结构设计的优劣。一般地说，先后运行环境差异小的、软件描述语言差别小的、结构设计良好的软件移植性能好。3. 3. 设计应该具有适应性设计应该具有适应性 设计应该具有适应用户需求变化而变化的能力。4.

3、 4. 设计过程应该受到理性化的控制设计过程应该受到理性化的控制 一个正在发展的设计，不论结构多么复杂，如果都可以被其负责正确性的人员深刻、全面的理解，就说明该设计是受到理性化控制的（Intellectual Control）。 “理性化控制”要求设计者对所采取的技术和设计的结构具有深刻清晰的认识和理解。 受到理性化控制的设计必然是结构清晰合理、关系明确可控、表达简洁正确、并易于理解的。5. 5. 设计应该表现出概念的完整性设计应该表现出概念的完整性 设计应该表现出整体的协调、一致和可预测性，也就是概念完整性（Conceptual Integrity）。即，不论多少人参与了设计和实施，系统结构

4、应该反映为统一的。2.1.2 2.1.2 软件设计中出现的问题软件设计中出现的问题1. 设计对于需求的变化缺乏配合2. 软件过程控制对于维持设计的正确性缺乏保障3. 软件产品通常缺乏概念完整性2.1.3 2.1.3 针对问题提出的软件设计思想针对问题提出的软件设计思想 软件的描述在经历了从机器和汇编语言、高级语言、模块语言、面向对象语言的变革后，开始走向基于对象、控件、模块、服务器、浏览器、组件等的“软件组装”时代。对于软件的发展，要求我们从更高、更宏观、更抽象的层面上把握和控制软件的组成和设计实施。1. 1. 强调信息隐蔽的单元概念强调信息隐蔽的单元概念 注重系统由具有对外隐藏信息的独立部件

5、组合构成的思想，把系统的行为看作是具有关联关系的部件间行为的作用。这样，减少了对设计知识的依赖，强化了设计单元和单元之间的关联性。2. 2. 应用基于操作和数据封装构成的单元设计技术应用基于操作和数据封装构成的单元设计技术 该思想是信息隐蔽的具体体现，有许多外在形式，例如：抽象数据类型、对象、对象关系、状态机、控件、组件/中间件、服务器等。3. 3. 应用专门的机制可靠地处理并发控制和分布系统应用专门的机制可靠地处理并发控制和分布系统问题问题 这表现在并发和分布控制部件结构描述的规范化和标准化方面。例如，有关的进程和线程调度和控制模型、共享资源管理模型、分布系统的消息处理机制。应用封装技术，将

6、具有并发和分布功能需求的处理数据和逻辑包装成对象、控件、组件或服务器，而应用系统地设计只是拼接或组装这些具有并发或分布处理能力的部件。4. 4. 提出基于模型的系统结构和设计方法提出基于模型的系统结构和设计方法 各类设计模式、领域系统框架、体系结构风格等概念，属于该方面。 这些在总结了通用和领域专用系统设计理论的经验基础上建立的概念，从特定的适应性上建立了问题的组成和关系框架，构成了系统设计问题求解的普遍适应的模型。5. 5. 明确提出软件体系结构的设计思想明确提出软件体系结构的设计思想 包括：软件的模型、结构、关系、实现、界面、性能、配置、测试、可能的扩展。2. 2 2. 2 什么是软件体系

7、结构什么是软件体系结构2.2.1 2.2.1 关于软件体系结构的认识发展（略）关于软件体系结构的认识发展（略）2.2.2 2.2.2 当前对软件体系结构的认识当前对软件体系结构的认识 从不同角度出发，研究者对体系结构的定义不同，没有形成标准、一致的认识。概括不同观点会发现，他们都支持这样的观点：即：软件体系结构包括系统总体组织、全局控制、通信协议、同步、数据存取、设计元素的功能、设计元素的组织、规模、性能、设计方案选择等。目前对软件体系结构在如下几个方面有较统一的认识：（1）体系结构是关于软件的系统级层次上的组成和行为的，是设计过程中不可缺少的一个阶段，对复杂软件的后期设计活动起着重要的决定作

8、用。（2）体系结构是由软部件和部件之间的联系组成，软部件又有它自身的体系结构。（3）部件的描述有 3 个方面：计算功能、结构特性、其他特性。 计算功能计算功能是指部件实现的整体功能； 结构特性结构特性描述与其它部件的组织和联系方法，这是体系结构中最重要的内容； 其他特性其他特性描述了部件的执行效率、处理能力、环境要求和整体特性等方面的要求，如：时间、空间、精确度、安全性、保密性、带宽、吞吐量和最低软硬件要求等。（4）目前没有哪个关于软件体系结构的描述可以说是完整的。关于什么是部件、什么是部件之间的联系并没有明确界定。软部件可以是对象、库、产品、组件、数据库或其他更加广泛的概念。 关于软件体系结

9、构的不同认识表现在两个方面：体系结构的范畴体系结构的范畴和描述形式上描述形式上。 关于范畴，软件体系结构是否仅仅局限在软件的上层结构和关系的处理上？ 所有开发方法都是要解决需求与实现之间的差距。以这种思想看体系结构，它应该建立在下层描述的基础上，而不应该仅仅局限在上层的形式上。否则，体系结构的设计就只有“概念”上的意义，而无软件工程实施的作用。 关于描述形式，以下的软件概念是否应该包含在体系结构的描述种，对此有不同的认识：用户界面、数据字典、数据流图、状态图、交互图、使用图、顺序图、程序控制流、异常处理、动态数据处理、动态结构演变等。2.3 2.3 软件体系结构的意义和目标软件体系结构的意义和

10、目标 软件体系结构的一个重要目标是产生关于软件系统及其组成部件的一致的视图集合，其表达形式可以满足系统用户和软件开发个阶段、各层次设计与维护人员的需要。它在用户需求和设计实施人员的系统规范之间提供了过渡的桥梁。2.3.1 2.3.1 体系结构在软件开发中的意义体系结构在软件开发中的意义1. 1. 软件体系结构的意义软件体系结构的意义（1）软件体系结构是软件开发过程初期的产品，但是对于开发进度和软件质量的一切资金和劳务投入，它是可以获得的最好回报；（2）与开发的其他设计活动比较，体系结构的活动成本和代价要低得多。因此，体系结构设计是形成低投资高回报的重要因素；（3）软件体系结构的意义还表现在，正

11、确有效的体系结构设计会给软件开发带来极大便利。2. 2. 软件体系结构的作用软件体系结构的作用 软件体系结构可以为软件开发和维护发挥重要作用。（1）通过认识和理解体系结构可以使系统的高层次关系得到全面表达和深刻理解；（2）获得正确的体系结构常常是软件系统设计成功的关键，错误选择可能导致灾难性的后果；（3）全面深入地理解软件体系结构，才可以是设计者在复杂的问题面前做出正确的选择；（4）系统体系结构对于复杂系统的高层次性能的分析是至关重要的；（5）熟练掌握体系结构的概念和描述，可以使软件设计者之间、设计者和用户之间快速方便的交流知识、经验和新设计思想；（6）在体系结构的全局思想指导下的任何系统维护

12、、扩充和升级，不会因修改和扩充而破坏整体的完整和一致性。2.3.2 2.3.2 软件体系结构的目标软件体系结构的目标 软件体系结构关心的是如何将复杂的软件系统划分为主/子系统、以及如何规范子系统的构成和性能。其主要目标就是建立一个一致的系统及其部分的视图集，并以能够满足终端用户和后期设计者需要的结构形式表达。因此，软件体系结构有两个特定的广泛目标：一个外向目标外向目标，建立满足终端用户要求的系统需求；一个内向目标内向目标，建立满足后期设计者需要以及易于系统实现、维护和扩展的系统部件构成。 外向需求目标关心的是为满足终端用户的需要系统应该做些什么。它要在系统实现之前寻找并确保系统的适应性。 内向

13、需求目标关心的是如何使系统满足用户的需求，为此需要建立哪些软件模块、它们的结构、它们之间的关系和规范如何等。2.3.3 2.3.3 与其它软件设计活动的关系与其它软件设计活动的关系 尽管软件体系结构与其后的软件设计形成了软件开发的整个活动，但是体系结构分析设计与其后的软件设计有着根本的不同。（1）体系结构分析的起点是模糊的；（2）用户和体系结构分析者之间的文化和知识差异，远大于结构分析者与系统实现者之间的差异；（3）体系结构分析处理的是需要更高层抽象的系统部件或子系统，而不是哪些诸如变量、函数、过程等的较低层次的概念；（4）设计活动往往不是局限在单一的组织机构中，而是需要软件组织和系统工程机构

14、之间的协调合作；（5）体系结构分析活动发生在整个工程的开始阶段，其作用则是贯穿整个设计实施过程的，而其后果如何往往需要到工程接近完工时才能显现出来。因此，结构分析错误所造成的代价往往是很高的。2.4 2.4 软件体系结构的发展（略）软件体系结构的发展（略）2.5 2.5 软件体系结构的研究范畴软件体系结构的研究范畴 软件体系结构的问题正在诸如软件重用、领域应用系统、软件组织模式的实现、体系结构语言、体系结构设计的形式化、体系结构设计环境和工具中受到关注。有关软件体系结构的研究大致分为 5 类。 通过提供体系结构语言对体系结构和特性进行描述； 关于体系结构经验知识的研究； 关于特殊应用领域体系结

15、构框架的研究； 关于基于体系结构的软件设计开发环境和工具的研究； 关于体系结构的形式化的研究。2.5.1 2.5.1 与体系结构有关的研究：风格、设计模式、与体系结构有关的研究：风格、设计模式、框架框架 软件系统通常有个总体的结构，其构成虽然不规范，但常用风格一般都是公认的。这些公认的、被多次使用的系统结构被称作结构风格、设计模式、（设计）框架。1.1.体系结构风格体系结构风格(Architecture Styles)(Architecture Styles) 结构风格以结构组织为特性定义了一个软件系统族，表达了部件和它们之间的关系。体系结构风格在应用的约束下，表达了部件以及部件之间的关系，以

16、及相关的合成和设计规则。 一般说来，体系结构风格表示了软件系统的一种特别的基本结构，以及相关的构造方法。结构风格也包含了在什么情况下使用和如何使用，以及结构风格的不变性和特例，还包括其应用的约束条件和后果。 广泛提及的体系结构风格包括：管道和过滤器管道和过滤器（Pipes and Filters）、数据抽象或对象数据抽象或对象（Data Abstraction and Object Oriented ）、隐式调用隐式调用/ /消息消息（Event-Based/Implicit Invocation）、层次层次（Layered System）、仓库（Repositories）、解释解释器器（In

17、terpreters）、过程控制过程控制（Process Control）、分布式系统分布式系统（Distributed System）、客户客户/ /服务器服务器（Client/Server）、主程序主程序/ /子程序子程序（Main/Subprograms）、状态转换状态转换（State Transition）、专用领域专用领域（Domain Specific Styles）等。管道和过滤器（管道和过滤器（Pipes and FiltersPipes and Filters）: : 是为处理数据流的系统提供的一种模式。它是由过滤器和管道组成的.每个处理步骤都被封装在一个过滤器组件中,数据通

18、过相邻过滤器之间的管道进行传输。每个过滤器可以单独修改,功能单一,并且它们之间的顺序可以进行配置。例如，编译器。 隐式调用隐式调用/ /消息消息（Event-Based/Implicit Invocation）：）： 基于事件的隐式调用的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。 例如，中断处理机制。例如，中断处理机制。 从“风格”的含义看，体系结构风格应该是一些对软件构成带有整体性、普遍性、一般性的结构和结构关系的方法

19、。在软件设计中，遵循这些风格的构成原则，对于软件的开发和维护都是十分有益的。2.2.设计模式设计模式(Design Patterns)(Design Patterns) 大量在众多应用中普遍存在的软件结构和结构关系，他们在不同的领域中获得应用，成为了处理特定问题的高效和成熟的设计模板，称为“模式(Pattern)”。 许多以前形成的编程原则形成了设计模式的基础，这些原则包括：抽象、封装、信息隐蔽、模块化、耦合、策略与实现的分离、接口与实现的分离等。 目前已经提出的设计模式分三个类型：构造型模构造型模式式、结构型模式结构型模式、行为型模式行为型模式。各类的具体模式包括以下内容：构造型（创建型）模

20、式构造型（创建型）模式： 构造型模式抽象了实例化过程。它们帮助另一个系统独立于如何创建、组合和表示它的那些对象。一个类构造型模式使用继承改变被实例化的类，而一个对象构造型模式将实例化委托给另一个对象。 构造型模式有构造型模式有：抽象工厂(Abstract Factory)、构造器(Builder)、工厂(Factory Method)、原型(Prototype)、单例(Singleton)、整体-部分(Whole-Part)、计数指针(Counted-Pointer)、视图句柄(View Handler)。抽象工厂：抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。

21、工厂：工厂：定义一个用于创建对象的接口，让子类决定实例化哪一个类。使一个类的实例化延迟到其子类。原型：原型：用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。单例：单例：保证一个类仅有一个实例，并提供一个访问它的全局访问点。结构型模式结构型模式：结构型模式涉及到如何组合类和对象以获得更大的结构，采用继承机制来组合接口或实现。一个简单的例子是采用多重继承方法将两个以上的类组合成一个类，结果这个类包含了所有父类的性质。这一模式尤其有助于多个独立开发的类库协同工作。 结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法。因为可以在运行时刻改变

22、对象组合关系，所以对象组合方式具有更大的灵活性，而这种机制用静态类组合是不可能实现的。结构型模式有结构型模式有：适配器(Adapter)、桥接(Bridge)、合成(Composite)、装饰器(Decorator)、外观(Facade)、享元(Fly Weight)、代理(Proxy)、主从(Master-Slave)、模型-视图-控制(Model-View-Controller)、表示-抽象-控制(Presentation-Abstraction-Controller)。适配器：适配器：将一个类的接口转换成客户希望的另外一个接口。桥接：桥接：将抽象部分与它的实现部分分离，使它们都可以独立的

23、变化。合成：合成：将对象组合成树形结构以表示“部分-整体”的层次结构。装饰器：装饰器：动态地给一个对象添加一些额外的职责。外观：外观：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。享元：享元：运用共享技术有效地支持大量细粒度的对象。代理：代理：为其它对象提供一种代理以控制对这个对象的访问。行为型模式：行为型模式：行为模式涉及到算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信模式。这些模视刻划了在运行时难以跟踪的复杂的控制流。他们将你的注意力从控制流转移到对象之间的联系方式上来。 行为型模式使用继承机制

24、在类间分派行为。行为型模式有行为型模式有：责任链(Chain of Responsibility)、命令(Command Prccessor)、解释器(Interpreter)、迭代器(Iterator)、协调器(Mediator)、备忘录(Memento)、观察者(Observer)、状态(State)、策略(Strategy/Policy)、模版方法(Template Method)、访问者(Visitor)、生存周期(Life Cycle)、发送-接收者(Forwarder-Receiver)、客户-分嵌-服务器(Client-Dispatcher-Server)、出版-订购者(Publ

25、isher-Subcriber)、反射(Reflection)。责任链：责任链：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。命令：命令：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。解释器：解释器：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语句中的句子。迭代器：迭代器：提供一种方法顺序访问一个聚合对象中的各个元素，而不需要暴露该对象的内部表示。协调器：协调器：用一个中介对象来封装一系列的对象交互。备忘录：备忘录：在不破坏封装性的前提下，捕获一个对象的内部状态，

26、并在该对象之外保存这个状态。观察者：观察者：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。状态：状态：允许一个对象在其内部状态改变时改变它的行为。策略：策略：定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。模版方法：模版方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。访问者：访问者：表示一个作用于某对象结构中的各元素的操作。 在软件设计中，这些模式起到了诸如建筑学中砖、瓦、各种水泥预制件、各式门窗等所起的作用。他们通过重用软件实践中的经验规范了系统的构成结构，加快了软件的设计和实施，为保证软件的质量提供了可靠稳

27、定的基础。3. 3. 框架框架(Framework)(Framework) 框架主要是关于应用领域问题的已建立的系统结构，所以也称作应用框架。从设计模式角度看，应用框架是一个给定应用领域中的完全的软件系统模式，是大粒度的可复用部件。从体系结构角度看，框架是一个领域体系结构。 从组成上看，框架是一个等待实例化的完整的系统，它定义了一个软件系统的族和关系，并提供了创建它们的基本构件模块。框架也定义了设置具体功能更改的插件位置。在面向对象环境中，框架由多个抽象和具体的类组成，或是一个具有特定关系的类族（集合）。 框架的实例化包括了现存类的组合和子类化。为特定领域设计的框架被称作应用框架(Applic

28、ation Framework)，框架规定了应用的体系结构，定义了它的构成、类和对象的分割，各部件的职能、类和对象的协作关系、以及控制流程。 应用框架又可分成冷点冷点(Frozen Spots)和热点热点(Hot Spots)。冷点定义了软件系统的完整结构，包括它的基本部件和部件间的关系。在应用框架的任何实例中它们保持不变。热点描述了应用框架中的那些随具体应用需求不同的部分。热点的设计应考虑到一般化和通用，对应用需要的变化应该具有适应性。4. 4. 体系结构风格、设计模式、框架的区别体系结构风格、设计模式、框架的区别 体系结构风格和设计模式概念之间存在相似和不同之处。 从框架的应用看，设计模式

29、可被看作是构建框架的建筑组块，它解决的是软件系统的相对局部和小粒度的构成问题。 从设计模式的应用看，框架可被看作是在某个给定应用领域中软件的整体系统模式，它解决软件的上层、全局的结构问题，当然了也提供了中层和低层的支持。 体系结构风格与设计模式和框架很相似，但他们存在以下不同：（1）体系结构风格只描述应用的整体结构框架，模式存在于规模不同的范畴，从定义应用系统基本结构的体系结构模式，到对给定问题实现的详细设计；（2）体系结构风格是相互独立的，但一个模式依赖于它包含的更小的规模、与它交互的模式和包含它的更大的模式；（3）和体系结构风格相比，模式和框架更加面向具体问题。结构风格从独立于实际设计情形

30、的观点来表现设计技巧，它偏重于计算机概念；而模式和框架表示了对具体的设计问题，并对它提出的解决方案，所有的一切都是从解决具体问题的观点出发。2.5.2 2.5.2 体系结构的观点体系结构的观点 对体系结构的不同认识反映在看待体系结构的不同观点上，形成了不同的体系结构的概念和描述形式。已经提出的观点包括：结构风格、设计模式、软件四视图、模型和关键部件、ADL描述语言。1. 1. 体系结构的风格观点体系结构的风格观点 在软件设计的实践中，随着人们对于某些特殊组织结构的频繁出现和应用价值的提高，发展并提出了一些相对固定的设计结构，称为体系结构风格(Architecture Styles)。 曾经提出

31、的体系结构风格由 9 大类：(1)数据流系统(Dataflow System)，它包括顺序批处理、管道和过滤器；(2)调用-返回系统(Call-and-return System)，它包括主程序和子程序、面向对象系统、层次结构；(3)独立部件(Independent Components)，它包括通信进程、事件隐式调用；(4)虚拟机(Virtual Machines)，它包括解释器、规则基系统；(5)以数据为中心的系统（库）(Data-Centered System/Repositories)，它包括数据库、超文本系统、黑板系统； (6)特殊领域风格(Domain-Specific Softw

32、are Architecture)，例如过程控制、模拟器；(7)特殊结构风格，例如分布式处理、状态转移系统；(8)不同风格合成建立的异构结构(Heterogeneous Architecture)；(9)最初始、也是最基本的主程序/子程序。 一个结构风格定义了由部件和连接的类型描述的一个词汇集合，以及如何将这些部件和连接类型结合的一个约束集合。2. 2. 面向模式的软件体系结构面向模式的软件体系结构 面向模式的软件体系结构概念把软件看成是各类模式的结合。它扩充了设计模式的概念，把模式（Pattern）划分成体系结构模式( Architecture Patterns)、设计模式(Design P

33、atterns)、惯用式(Idiom)。不同类模式在系统结构中解决不同层面的结构问题。 体系结构模式包含有层次(Layers)、过滤-管道(Pipes and Filters)、黑板(Blackboard)、分布系统(Distributed System)、模型-视图-控制(Model-View-Controller)、表达-抽象-控制(Presentation-Abstraction-Controller) 、微核(Microkernel)、反射(Reflection)等。 设计模式包括：整体-部分(Whole-Part) 、主从(Master-Slave) 、代理(Proxy) 、命令处理

34、(Command Prccessor) 、视图句柄(View Handler) 、发送-接受(Forwarder-Receiver) 、客户-分发-服务(Client-Dispatcher-Server) 、发布-订购(Publisher-Subcriber)等。 惯用式包含确保只生成单个类对象的Singelton、简化和确保动态对象安全处理的计数指针(Counted-Pointer)等。 面向模式的观点也认为软件体系结构是由部件和关系构成的。但特别强调它是软件设计的产物。它把部件分为：控制器(Controller)、协调器(Coordinator)、界面(Interface)、服务提供器(S

35、erver Provider)、信息保持器(Information Holder)、结构(Structuring)。 它把诸如状态(State)、通信(Communication)、数据流(Data Flow)、视图(View)等看成是表示系统部分特殊特性的方面，特性包括功能特性(Functional Property)和非功能特性(Non- Functional Property)。3. 3. 体系结构的四视图观点体系结构的四视图观点 该观点把软件体系结构看成是由四种描述视图而构成的。他们分别是：概念体系结构(Conceptual Architecture)、模块体系结构(Module Ar

36、chitecture) 、代码体系结构(Code Architecture) 、运行体系结构(Execution Architecture) 。 概念体系结构包括：部件、连接器、性能等，影响它的主要因素是应用问题的分解和划分。 模块体系结构包括：子系统、模块、引入(Imports)、引出(Exports)、模块的界面、管理、控制和一致性等，它受到软件的设计原则、组织结构和软件技术的影响。 代码体系结构包括：文件、目录、库、包含(Includes)、软件的配置管理、系统建造等，它受到语言、工具和外部系统等因素的影响。 运行体系结构包括：任务、线程、进程、性能、调度、动态分配和不同的执行系统之间的

37、接口等，它主要受到硬件体系结构、运行环境、性能和通信机制等因素的影响。 另有类似的四视图的观点：把软件体系结构看成是由：逻辑视图(Logical View)、处理视图(Process View) 、物理视图(Physical View) 、开发视图(Development View) 。其中，逻辑视图是设计的概念模型，例如实体关系模型、对象模型等；处理视图包括：并发、同步、异步等；物理视图是软件向硬件以及分布配置的映射；开发视图是软件在开发环境中的静态组织结构。4. 4. 体系结构的模型和关键部件观点体系结构的模型和关键部件观点 软件模型包括：过程抽象、对象和数据抽象、顺序/条件/循环设计模型

38、、分布设计模型、分布并行设计模型、激发-响应机制的原子活动模型、应用环境模型、任务和控制过程的程序执行模型等。 四个关键部件是：系统边界(Software Boundary)、系统服务和系统客户(System Client, System Server)、系统界面(Interface Mapping)、事务管理(Transaction Managers)。 系统边界是应用问题所包含或排除的系统能力的界定；系统界面是系统与其运行环境的交互手段和方法，它反映了系统边界外信息与系统边界内数据模型的映射关系；系统服务也称为实体模型，提供了系统内在的状态数据模型；系统客户是为满足用户需求所提供的操作表达

39、；事务管理在系统界面的作用下与外部设备交互信息。5. 5. 体系结构的体系结构的 ADL ADL 观点观点 ADL：体系结构描述语言(Architecture Description Languages) 讲义：P27-P282.5.3 2.5.3 领域结构风格领域结构风格 所谓领域体系结构是一类面向应用领域的软件体系结构风格，它是相对通用体系结构风格而言的。 讲义：P292.5.4 2.5.4 体系结构的描述语言体系结构的描述语言 讲义：P29-P322.5.5 2.5.5 体系结构的形式化体系结构的形式化 讲义：P322.5.6 2.5.6 体系结构的工具和环境体系结构的工具和环境 软件体

40、系结构研究的最终目的是减少复杂应用系统开发的代价、提高系统开发的效率和质量。它借助于公共和通用体系结构组块的装配，使得软件开发从细粒度的代码向粗粒度的结构部件以及它们之间的关系的转移。 为了支持基于体系结构的软件开发，需要体系结构描述语言和工程工具环境的支持。在此，描述语言是核心，工具环境是工作舞台。 需要为基于体系结构的软件开发的工具环境提供以下支持，他们是系统体系结构的：规范设计、多视图表达、性能分析、分层细化、代码生成、运行配置和动态行为描述。其中：（1）规范设计：为体系结构的设计描述提供选择、指导、建议、约束和错误检测。（2）多视图表达：软件系统开发中的不同角色，例如系统结构师、开发者

41、、经理、客户，需要以不同的视角观察认识系统结构。为不同角色提供适当的视图、并保持各视图之间关系的一致，是提供多视图服务的关键。（3）性能分析：体系结构的描述一般是用于大型、分布和并发系统设计的。从体系结构的层面提供系统性能的评价，可大大减少设计错误造成的代价。在体系结构级别完成这种分析要比在代码级别容易得多。因此，体系结构的性能分析是体系结构工具环境开发的一个主要焦点。（4）分层细化：由于软件开发的阶段和渐进性，支持体系结构细化的重要性是很明显的。在这方面有效工具的支持对于提高设计的信心是必不可少的。（5）代码生成：任何软件设计和模拟的最终目标都是产生执行系统。因此使工具环境能够提供源代码生成

42、是十分重要的。（6）动态行为描述：软件工具环境为基于体系结构的系统提供分析以确保系统特性的实现，这里包括体系结构和实现代码之间的对应关系，确保系统关键部分地正确运行，并在应用系统运行时分析和测试功能和特性。2.6 2.6 软件体系结构与其它软件技术软件体系结构与其它软件技术 软件体系结构与传统软件技术研究的不同之处在于它把原来从不同角度和不同观点出发建立的分散、非系统、非形式化的关于软件构成的思想经过研究分析和归纳总和，建立了统一可用于软件系统设计、分析、构造、实现的符号和概念体系。 从程序设计语言的研究出发，建立了程序的顺序、条件、循环、中断的基本控制描述；建立了数据、过程、对象等部件单元；

43、建立了程序运行的存储分配、异常处理、库、动态连接等的模型；建立了基于编译或解释的软件系统的概念模型和实现技术等。这些为复杂软件的描述实现提供了基本的方法、工具和环境。 从操作系统和网络技术的研究出发，提出了软件构成的（操作系统和网络结构的）层次结构模型、任务和进程调度、共享资源管理、同步控制、消息处理机制、基于窗口的程序结构、分布式处理等，这些为复杂软件的构成和运行结构的建立提供了支持，并逐渐形成了软件体系结构的层次风格、消息处理风格、分布式处理风格、可视化软件结构风格和动态连接库（DLL）、注册表等控制结构。 从面向对象技术的研究出发，提出了软件的对象模型、继承、多态性、控件、可视控件、组件

44、、OLE对象嵌入、面向对象的分析与设计技术OMT 、统一的模型语言UML等。面向对象对整个软件技术研究的作用是全面的、巨大的。 从软件的概念模型研究出发，提出了数据结构、抽象数据类型、类、对象、对象关系、实体、实体关系、模式、框架、设计模式等概念，这些都为复杂软件系统的描述和构成提供了抽象概念和模型。 从数据库研究出发，提出了以服务于事务和信息处理为主的概念和模型，包括实体、实体关系、数据库、客户/服务器等。 从软件工程研究出发，提出了基于数据字典和数据流的结构分析和设计方法，基于对象和扩充实体关系模型、功能模型、交互图、活动图、状态图的面向对象的分析和设计的OMT、Booch、UML方法。

45、从Internet应用技术出发，提出了公共网关接口CGI、动态网页ASP、WWW服务和浏览器、多层体系结构等概念，建立了基于HTML解释语言的浏览器/信息服务器的应用体系结构，与面向对象技术的结合，建立了基于COM、CORBA组件服务的多层应用体系结构。 从应用软件开发研究出发，针对特定应用领域的特点，提出了众多应用领域的软件构成框架，形成了体系结构研究中的领域体系结构风格。 从人工智能研究出发，针对人工智能问题提出了诸如神经网络、语义网络、状态空间、状态转移和扩充转移网络、图搜索、剪枝和启发式搜索、非单调推理、非确定性推理、遗传算法、Agent智能体等概念。建立了谓词演算和规约、生成规则、知识调度黑板的软件体系结构。2.7 2.7 软件体系结构的现状软件体系结构的现状 讲义：P35-37