20种软件架构体系风格特点（东南大学期末复习sa）

20种软件架构风格

概述：

1.数据流风格
2.主程序/子程序风格
3.面向对象风格
4.层次化风格
5.事件驱动风格
6.解释器风格
7.基于规则的系统风格
8.仓库风格
9.黑板系统风格
10.C2风格
11.客户机/服务器风格
12.浏览器/服务器风格
13.平台/插件风格
14.面向Agent风格
15.面向方面软件架构风格
16.面向服务架构风格
17.正交架构风格
18.异构风格
19.基于层次消息总线的架
构风格
20.模型-视图-控制器风格
总结整理了20 种考试要考的软件架构风格，基本是全的

一：数据流风格

• 特征：
  • 数据的可用性决定着处理是否执行
  • 系统结构由数据在各处理之间的有序移动决定
  • 在纯数据流系统中，处理之间除了数据交换没有任何其他的交互
• 处理：数据到达时被激活，无数据时不工作
• 基本组件：数据处理单元（Comp）
• 组件的端口：输入端口（I）和输出端口（O）
• 组件的计算模型：从输入端口读数，经过计算/处理，然后写到输出端口
• 连接件：数据流
• 接口角色：Reader和 Writer
• 

1.批处理（Batch Sequential）

• 批处理（Batch Sequential）
  • 基本组件：独立的应用程序
  • 连接件：某种类型的介质，完整的数据
  • 特点：
    • 近乎线性；
    • 每个处理步骤是一个独立的程序；
    • 每一步在前一步结束后才开始；
    • 数据必须是完整的，以整体的方式传播。

2.管道-过滤器（Pipe- Filter ）

自我理解：就是过滤器处理数据，管道是连接件，就是数据流

1. 概述

• 应用场景：数据源源不断地产生，系统需要对这些数据进行若干处理(分析、计算、转换等)。
• 基本组件：过滤器（功能模块）
  • 每个过滤器组件中都封装了一个处理步骤
  • 数据源点和数据终止点可以看作是特殊的过滤器
• 连接件：管道（数据流）

2. 过滤器Filter

• 过滤器的作用：将源数据变换成目标数据
• 过滤器的变换方式： （丰富）增加，（精练）删减，（转换）改变，分解，合并等
• 过滤器的特性：独立性
  • 过滤器是独立运行的组件
    • 非临近的过滤器之间不共享状态
    • 过滤器自身无状态
  • 过滤器对其处理上下连接的过滤器“无知
    • 对相邻的过滤器不施加任何限制
  • 结果的正确性不依赖于各个过滤器运行的 先后次序
    • 各过滤器在输入具备后完成自己的计算。完整 的计算过程包含在过滤器之间的拓扑结构中。

3. 管道

• 管道Pipe
  • 管道是单向流动的。
  • 管道可以有缓冲区。

4. 优点

• 由于每个组件行为不受其他组件的影响，整个系统的行为易于理解

  • 使得软件组件具有良好的隐蔽性和高内聚、低耦合的特点，允许设计者将整个系统的输入/输出行为看成是多个过滤器行为的简单合成；

• 管道-过滤器风格支持功能模块的复用

  • 任何两个过滤器，只要它们之间传送的数据遵守共同的规约，就可以相连接。每个过滤器都有自己独立的输入输出接口，如果过滤器间传输的数据遵守其规约，只要用管道将它们连接就可以正常工作

• 基于管道-过滤器风格的系统具有 较强的可维护性和可扩展性

  • 旧的过滤器可以被替代，新的过滤器可以添加到已有的系统上。软件的易于维护和升级是衡量软件系统质量的重要指标之一， 在管道-过滤器模型中，只要遵守输入输出数据规约，任何一个过滤器都可以被另一 个新的过滤器代替，同时为增强程序功能， 可以添加新的过滤器。这样，系统的可维护性和可升级性得到了保证。

• 支持一些特定的分析，如吞吐量 计算和死锁检测等

  • 利用管道-过滤器风格的视图，可以很容易 得到系统的资源使用和请求的状态图。然后，根据操作系统原理等相关理论中的死锁检测方法就可以分析出系统目前所处的状态，是否存在死锁可能及如何消除死锁等问题。

• 管道-过滤器风格具有并发性

  • 每个过滤器作为一个单独的执行任务，可以与其它过滤器并发执行。过滤器的执行是独立的，不依赖于其它过滤器的。在实际运行时，可以将存在并发可能的多个过滤器看作多个并发的任务并行执行，从而大大提高系统的整体效率，加快处理速度。

5. 缺点

• 管道-过滤器风格往往导致系统处理过程的成批操作。

  • 根据实际设计的需要，设计者也需要对数据传输进行特定的处理（如为了防止数据泄漏而采取加密等手段，或者使用了底层公共命名），导致过滤器必须对输入、输出管道中的数据流进行解析或反解析**，增加了过滤器具体实现的复杂性。系统性能不高。**

• 交互式处理能力弱

  • 管道-过滤器模型适于数据流的处理和变换， 不适合为与用户交互频繁的系统建模。在这种模型中，每个过滤器都有自己的数据， 这些数据或者是从磁盘存储器中读取来，或者是由另一个过滤器的输出导入进来，整个系统没有一个共享的数据区。这样， 当用户要操作某一项数据时，要涉及到多个过滤器对相应数据的操作，其实现较为复杂。由以上的缺点，可以对每个过滤器增加相应的用户控制接口，使得外部可以对过滤器的执行进行控制。

3.使用场景

1. 能够把任务分解成为一系列固定顺序的计算单元 ，并且彼此间只通过数据传递交互的场景均可应用
2. UNIX的shell中编写的程序
   传统编译器
   信号处理领域
   并行计算
   功能编程
   分布式系统
3. 其实就是上一个操作的输出可以作为下一个操作的输入的地方，比如编译器就是词法分析的结果作为语法分析的输入这种的操作

二：调用/返回风格

1.主程序/子程序风格

1. 定义：通过逐步分解和逐步细化得到系统架构，即将**大系统分解为若干模块(模块化)，**主程序调用这些模块实现完整的系统功能
   该架构风格从功能的观点设计系统
   主程序的正确性依赖于它所调用的子程序的正确性

2. 组成

• 组件：主程序和子程序
• 连接件为调用-返回机制
• 拓扑结构为层次化结构。
• 

3. 一个例子：

4. 优缺点分析：

• 优点：

• 结构化程序设计的典型风格，相对于
  非结构化设计逻辑清晰，易理解。

• 开发过程采用逐步细化，将大系统分
  解为若干模块（模块化）。

• 缺点：

• 对数据存储格式的变化将会影响几乎所有的模块。

• 结构化程序在规模变大时会难理解、难测试、难维护。

• 这种分解方案难以支持有效的复用。随着程序规模的增大，大量函数、变量之间的关系错综复杂，要抽取可重用的代码往往变得十分困难。

2.面向对象风格

1. 定义：是80年代初期提出的一种新型的程序设计方法， 它彻底改变了过去数据流、事物流分析方式的缺点，采用直接对问题域进行自然抽 象的方法，并逐渐发展成包括面向对象分析、设计、编程、测试、维护等一整套内容的完整体系。

   该架构风格从现实世界中客观存在的事物出发，强调直接以问题域中的事物为中心来思考问题、认识问题，根据这些事物的本质特征，将其抽象为系统中的对象，并作为系统中的基本构成单位。

2. 特点

   • 对象负责维护其表示的完整性（通常是通过保持其表示上的一些不变式来实现的）
   • 对象的表示对其他对象而言是隐蔽的。抽象数据类型的使用，以及面向对象系统的使用已经非常普遍。

3. 优缺点

• 优点
  • 对象隐藏了其实现细节，所以可以在不影响其它对象的情况下改变对象的实现， 不仅使得对象的使用变得简单、方便，而且具有很高的安全性和可靠性。
  • 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合
• 缺点
  • 当一个对象和其它对象通过过程调用等方式进行交互时，必须知道其它对象的标识。 无论何时改变对象的标识，都必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。

4. 应用场景
   适用于中心问题是确定和保护相关信息主体，特别是代表性信息的应用

5. 组件等

• 系统模型：localized state maintenance
• 组件：管理器(e.g,servers,.objects,abstract data types)
• 连接件：procedure call
• 约束：decentralized,.usually single thread

3.层次结构，层次化风格

1. 定义：在分层系统（Layered System）中，系统被组织成若干个层次，每个层次由一系列组件组成；层次之间存在接口，通过接口形成call/return的关系——下层组件向上层组件提供服务，上层组件被看作是下层组件的客户端。（层次化早已经成为一种复杂系统设计的普遍性原则。）

.

3. 分层：在分层架构中，组件被划分成几个水平层，每个层在应用中执行特定角色。

• 表现层
• 业务层
• 持久层
• 数据库层
• ◦ (有些情况下将业务层和持久层结合在一起
  成为一个单独的业务层)

4. 应用场景和组件等

• 应用场景：适用于涉及可以按层次结构安排的不同服务类别的应用程序
• 系统模型：不透明(不透明的)层次结构
• 组件：通常复合composites are most often collections of procedures
• 连接件：depends on structure of components; often procedure calls under restricted visibility（在受限条件下可见）
• 约束：单线程

5. 特点

• 分层架构中的每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。
  • 即：当请求从一个层移动到另一个层时，它必须经过它正下方的层，以到达该层下面的下一层。
  • 例如，源自表现层的请求必须首先经过业务层，然后在最终到达数据库层之前到达持久层。
• 大的问题分解为若干个渐进的小问题，逐步解决，隐藏了很多复杂度
• 修改一层，最多影响两层，而通常只能影响上层。接口稳固，则谁都不影响
• 上层必须知道下层的身份，不能调整层次之间的顺序

6. 优缺点

• 优点
  • 支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
  • 支持扩展。每一层的改变最多只影响相邻层。
  • 支持重用。只要给相邻层提供相同的接口，它允许系统中同一层的不同实现相互交换使用。
• 缺点
  • 不是所有系统都容易用这种模式来构建；
  • 定义一个合适的抽象层次可能会非常困难，特别是对于标准化的层次模型。
  • 层层相调，影响性能

4.风格变种：客户端/服务器风格

1. 定义：客户机和服务器是两个相互独立的逻辑系统，为了完成特定的任务而形成一种协作关系。

• 客户机(前端，front-end)：业务逻辑、与服
  务器通讯的接口；
• 服务器(后端：back-end)：与客户机通讯的接
  口、业务逻辑、数据管理

2.一般的，客户机为完成特定的工作向服务器发出请求；服务器处理客户机的请求并返回结果。

• 客户机程序和服务器程序
  配置在同一台计算机上时：
  采用消息、共享存储区和
  信号量等方法实现通信连
  接。
• 客户机程序和服务器程序
  配置在分布式环境中时：
  通过远程调用（Remote
  Produce Call，RPC）协议
  来进行通信。

4.1 两层c/s架构

1. 形象图：
   
2. 处理流程图
   
3. 优点缺点
   
   

4.2 三层c/s架构

1. 示意图
   

2. 流程图
   

3. 相较于两层cs的优点

• 合理地划分三层结构的功能，可以使系统的逻辑结构更加清晰，提高软件的可维护性和可扩充性。
• 在实现三层C/S架构时，可以更有效地选择运行平台和硬件环境，从而使每一层都具有清晰的逻辑结构、良好的负荷处理能力和较好的开放性。
• 在C/S架构中，可以分别选择合适的编程语言并行开发。
• 系统具有较高的安全性。

4. 注意的问题

• 如果各层之间的通信效率不高，即使每一层的硬件配置都很高，系统的整体性能也不会太高
• 必须慎重考虑三层之间的通信方法、 通信频率和传输数据量，这和提高各层的独立性一样也是实现三层C/S架构的关键性问题。

4.4 浏览器/服务器风格

1. 定义等
   浏览器/服务器风格是三层C/S风格的一 种实现方式。

   主要包括浏览器，Web服务器和数据库服务器。

   与三层C/S结构的解决方案相比，B/S架构在客户机上采用了WWW浏览器， 将Web服务器作为应用服务器。

   B/S架构核心是Web服务器，数据请求、 网页生成、数据库访问和应用程序执行全部由Web服务器来完成。

   在B/S架构中，系统安装、修改和维护全在服务器端解决，客户端无任何业务逻辑。

2.优点缺点

• 优点
  • 客户端只需要安装浏览器，操作简单， 能够发布动态信息和静态信息。
  • 运用HTTP标准协议和统一客户端软件，能够实现跨平台通信。
  • 开发成本比较低，只需要维护Web服务器程序和中心数据库。客户端升级可以通过升级浏览器来实现。
• 缺点
  • 个性化程度比较低，所有客户端程序的功能都是一样的。
  • 客户端数据处理能力比较差，加重了Web服务器的工作负担，影响系统的整体性能。
  • 在B/S架构中，数据提交一般以页面为单位**，动态交互性不强**，不利于在线事物处理（Online Transaction Processing，OLTP）。
  • B/S架构的可扩展性比较差，系统安全性难以保障
  • B/S架构的应用系统查询中心数据库，其速度要远低于C/S架构。

三：以数据为中心的风格

1. 特点：注册表中保存了系统的所有硬件和软件配置信息；这些信息影响或控制系统/应用软件的行为，应用软件安装/运行/卸载时对其进行添加/修改/删除信息，以达到改变系统功能和控制软件运行的目的。（就是通过修改注册表控制软件运行或者改变系统功能）

1.仓库风格

1. 基本思想：仓库是存储和维护数据的中心场所

2. 流程图
   

3. 组件等

• 组件：
  • 中心数据结构组件，表示当前数据的状态
  • 相对独立的组件集合，各个功能模块（子系统）等
• 连接jian:
  • 数据仓库与独立组件之间的交互
    • 如果由输入流中事务触发系统相应的进程执行，这种知识库是传统的数据库型知识库；
    • 如果由中心数据结构的当前状态触发系统相应的进程执行，这种知识库称为黑板知识库。

4. 优点，缺点

• 优点
  • 便于模块间的数据共享
  • 方便模块的添加、更新和删除
  • 避免了知识源的不必要的重复存储等。
• 缺点
  • 对于各个模块，需要一定的同步/加锁机制保证数据结构的完整性和一致性等

5. 应用实例
   
   

2.黑板系统风格

1. 定义

• 一个大问题被分解为若干个子问题
• 每个子问题的解决需要不同的问题表达方式 和求解模型，分别设计求解程序
  • 每个求解程序具有某一特定领域的知识，可解决 某一方面的问题；
  • 这些程序是相互独立的，之间不存在相互调用，也不存在可事先确定的操作顺序；
  • 根据问题求解过程中的状态来动态决定各个专门 程序之间的操作顺序，它们之间通过协同工作共同完成整个问题的求解；
  • 专门的控制程序负责根据问题求解的状态来调用 最恰当的求解程序，从而形成一种随机性的执行 次序。

2. 系统风格

• 黑板系统（Blackboard System）是传统上被用于信号处理方面进行复杂解释的应用程序，以及松散耦合的组件访问共享数据的应用程序。
• 黑板架构实现的基本出发点是已经存在一个对公共数据结构进行协同操作的独立程序集合。
• 例如：自然语言处理、语音处理、模式识别、图像处理等

3. 组成部分
   

• 基本结构
  

4. 流程

• 全局数据库，用来存储数据、传递信息，包含解域的全部状态
• 解决问题过程中的状态数据，以层次形式组织起来
• 知识源对黑板进行修改，逐渐找到问题的解
• 各知识源之间的通讯和交互只通过黑板进行

5. 各个组件的特点

• 知识源
  • 知识源是描述某个独立领域问题的知识及其处理方法的知识库
  • 知识源分别存放且相互独立
  • 他们通过黑板进行通讯 ，合作求出问题的解
  • 通常知识源具有“ 条件- 动作”的形式 。当条件满足时 ，知识源被触发 ，其动作部分增加或修改黑板上的内容。
• Control 控制器
  • 时刻监视黑板状态变化
  • ◦ 对黑板上信息的当前状态进行判断和评价
  • 当黑板的状态满足了知识源的执行条件时，该知识源被控制器触发并进行计算，然后将结果更新到黑板上
  • 这种更新又导致其他知识源参与计算并更新黑板，直到找到问题解为止

6. 应用示例
   
7. 优缺点

• 优点
  • 便于多客户共享大量数据，他们不关心数据何时有的、谁提供的、怎样提供的。
  • 既便于添加新的作为知识源代理的应用程序，也便于扩展共享的黑板数据结构。
  • 知识源可重用
  • 支持容错性和健壮性
• 缺点
  • 不同的知识源代理对于共享数据结构要达成一致，而且，这也造成对黑板数据结构的修改较为困难——要考虑到各个代理的调用。
  • 需要一定的同步/加锁机制保证数据结构的完整性和一致性，增大了系统复杂度。

四：虚拟机风格

1.解释器风格

1. 基本思想：解释器(Interpreter) 是一个用来执行其他程序的程序，它针对不同的硬件平台实现了一个虚拟机，将高抽象层次的程序翻译为低抽象层次所能理解的指令，以弥合程序语义所期望的与硬件提供的计算引擎之间的差距。
   
2. 组成部分
   
3. 优缺点

• 优点
  • 它有利于实现程序的可移植性和语言的跨平台能力；
  • 可以对未来的硬件进行模拟和仿真，能够降低测试所带来的复杂性和昂贵花费
• 缺点
  • 额外的间接层次导致了系统性能的下降，如在不引入JIT（Just In Time）技术的情况下，Java应用程序的运行速度相当慢。

4. 和编译器对比

• 编译器不会执行输入的源程序代码，而是将其翻译为另一种语言
• 在解释器中，程序源代码被解释器直接****加以执行。
• 解释器的执行速度要慢于编译器产生的目标代码的执行速度，但是却低于编译器“编译+链接+执行”的总时间
• 解析器执行速度之所以慢，是因为每次解释执行的时候，都需要分析程序的结构，而编译代码则直接执行而无需重复编译
• 解释器对内存的分配是在解释时才进行的；而编译器则是在编译时就规划好了变量的内存使用方案，因此运行时直接将程序代码装入内存并执行即可

5. 三种策略

• 传统解释器：解释器直接读取源代码并加以执行；
• 字节码解释器：源代码首先被“编译”为高度压缩和优化的字节码，但并不是真正的机器目标代码，因而与硬件平台无关；编译后得到的字节码然后被解释器加以解释（Java，Perl，PHP，Python）
  
• 实时编译器JIT (Just-in-time) Complier：实时编译JIT中，字节码在运行时被编译为本机的目标代码
  
  

2.基于规则的系统风格

1. 核心思想：将业务逻辑中可能频繁发生变化的代码从源代码中分离出来
2. 示例：
   
3. 优点：

• 降低了修改业务逻辑的成本
  ◦ 缩短了开发时间
  ◦ 将规则外部化，可在多个应用之间共享
  ◦ 对规则的改变将非常迅速并且具有较低的
  风险

4. 组件：类似解释器
   
5. 比较
   

五：事件驱动风格

1. 基本思想
   不直接调用一个过程，而是发布或广播一个或多个事件。系统中的其它组件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时， 系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其它模块中过程的隐式调用。

事件：是指可以被系统识别的、发生在界面上的用户动作或者状态变化。

2. 一般步骤

• 确定响应事件的元素；
• 为指定元素确定需要响应的事件类型；
• 为该元素的相应事件编写事件处理程序；
• 将事件处理程序绑定到指定元素的指定事件。

3. 特点

• 事件发布者不知道哪些组件会受到事件的影响；组件不能对事件的处理顺序，或者事件发生后的处理结果做任何假设。

• 从架构上来说，事件驱动系统的组件提供了一个过程集合和一组事件。

• 过程可以使用显示的方法进行调用，也可以由组件在系统事件中注册。当触发事件时，会自动引发这些过程的调用。

• 连接件既可以是显示过程调用，也可以是一种绑定事件声明和过程调用的手段。

4. 优点

• 事件声明者不需要知道哪些组件会影响事件，组件之间关联较弱。

• 提高软件复用能力。只要在系统事件中注册组件的过程，就可以将该组件集成到系统中。

• 系统便于升级。只要组件名和事件中所注册的过程名保持不变，原有组件就可以被新组件替代。

5. 缺点

• 组件放弃了对计算的控制权，完全由系统来决定。
• 存在数据交换问题。
• 该风格中，正确性验证成为一个问题。

6. 适用范围

• 隐式调用

• 断点处理

• 事件及消息机制win32

• 数据库管理系统中一致性约束

• 用户界面中数据表示与管理数据的应用程序的分离

• 语法导向的增量语义检查

六：其他风格

1.c2风格：

1. 基本概念：通过连接件 绑定在一起的按照一组规则运作的并行组件网络。该规则规定了所有组件之间的交互必须通过异步消息机制来实现

C2是一种基于组件和消息的架构风格， 适用于GUI软件开发，构建灵活和可扩展的应用系统。

2. C2风格的系统组织规则：

• 组件之间不能直接连接；

• 组件和连接件都有一个顶部和一个底部；

• 组件的顶部应连接到某连接件的底部，组件的底部则应连接到某连接件的顶部；

• 一个连接件可以和任意数目的其他组件和连接件连接；

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

3. 优点

• 可使用任何编程语言开发组件，组件重用和替换易实现；

• 由于组件之间相对独立，依赖较小，因而该风格具有一定扩展能力，可支持不同粒度的组件；

• 组件不需共享地址空间；

• 可实现多个用户和多个系统之间的交互；

• 可使用多个工具集和多种媒体类型，动态更新系统框架结构。

4. 缺点

• 不太适合大规模流式风格系统，以及对数据库使用比较频繁的系统。

5. 适用范围

• 主要用于具有图形化用户界面的应用程序

6. 特点
   C2架构的内部，通信和处理是分开完成的。

2.平台/插件风格：

1. 基本思想：“平台/插件”软件结构将待开发的目标软件分为两部分：
   ◦ 程序的主体或主框架，可定义为平台
   ◦ 功能扩展或补充模块，可定义为插件

2. 平台所完成的功能应为一个软件系统的核心和基础,可以把平台基本功能分为两个部分:
   ◦ 内核功能：是整个软件的重要功能，一个软件的大部分功能因由内核功能完成。
   ◦ 插件处理功能：用于扩展平台和管理插件，为插件操纵平台和与插件通信提供标准平台扩展接口。

3. 插件是能动态插入到平台中的程序模块，提供给系统某一方面的功能，但多个插件能使系统功能完善，完成多个复杂的处理。 插件受到的约束是:
   ◦ 1)插件必须能在运行过程中动态地插入平台和从平台中注销，且不影响系统的运行;
   ◦ 2)当在系统中插入插件后，系统的功能得到扩展或升级;
   ◦ 3)多个插件之间、插件和平台之间不会发生冲突

4. 实现“平台/插件”(Platform / Plug-in) 结构软件需要定义两个标准接口
   ◦ 平台扩展接口：完全由平台实现，插件只是调用和使用
   ◦ 插件接口：完全由插件实现，平台也只是调用和使用。
   ◦ 平台扩展接口实现插件向平台方向的单向通信，插件通过平台扩展接口可获取主框架的各种资源和数据，可包括各种系统句柄，程序内部数据以及内存分配等。
   ◦ 插件接口为平台向插件方向的单向通信，平台通过插件接口调用插件所实现的功能，读取插件处理数据等。

5. 优缺点

• 优点：
  ◦ （1）降低系统各模块之间的互依赖性
  ◦ （2）系统模块独立开发、部署、维护
  ◦ （3）根据需求动态的组装、分离系统
• 缺点
  ◦ 插件是别人开发的可以用到某主程序中的，
  只服务于该主程序，可重用性差。

3.面向Agent风格

1. 基本思想：面向Agent风格（Agent-oriented）的基本思想是认为事物的属性，特别是动态特性在很大程度上受到与其密切相关的人和环境的影响，将影响事物的主观与客观特征相结合抽象为系统中的Agent，作为系统的基本构成单位，通过Agent之间的合作实现系统的整体目标。

• Agent：一个能够根据它对其环境的感知，主动采取决策和行为的软件实体。
• Agent组件：对系统处理的高度抽象，具有高度灵活和高度智能特色的软件实体。
• Agent连接件：对复合型组件的连接，该连接能够提供通信、协调、转换、接通等服务。
• Agent组件有别于以往任何系统的组件类型，其所具有的自主性、智能性、交互性等特性是传统架构对象所不具备的。
• 多Agent系统中的连接件并非显式地将两个不同的组件联系起来。不同Agent之间的联系是根据运行时状态来决定的。

3. 优缺点

• 优点
  ◦ 面向Agent的软件工程方法对于解决复杂问
  题是一种好的技术, 特别是对于分布开放异
  构的软件环境。
• 缺点
  ◦ 大多数结构中Agent 自身缺乏社会性结构描
  述和与环境的交互。

4.面向方面软件架构风格：

1. 基本思想

• 面向方面的编程(AOP：Aspect Oriented Programming)
  ◦ 一般认为AOP在传统软件架构基础上增加了方面组件(Aspect Component)这一新的构成单元，通过方面组件来封装系统的横切关注点。
  ◦ 系统的有些特性和需求是横切于系统的每一个层面中，并融于系统的每一个组件中，这种特性称为系统的方面(Aspect)需求特性或关注点
  （如系统中的时间要求、业务逻辑、性能、安全性和错
  误检测、QoS监测等。）
• 应用AOP的主要目的----尽量分离“技术问题实现”和“业务问题实现”
  ◦ 它允许开发者能够对横切关注点进行模块化设计；
  ◦ 能够实现分散关注，将通用需求功能从不相关类之中分离出来；
  ◦ 能够实现代码重用。
  
  2.优缺点分析
  ◦ 可以定义交叉的关系，并将这些关系应用于跨模块的、彼此不同的对象模型
  ◦ AOP 同时还可以让我们层次化功能性而不是嵌入功能性，从而使得代码有更好的可读性和易于维护。
  ◦ 它会和面向对象编程可以很好地合作，互补

5.面向服务架构风格

1. 基本思想：

• SOA 是一个组件模型，它将应用程序的不同功能单元（服务）通过这些服务之间定义良好的接口和契约联系起来。

  • 服务(service)是一个粗粒度的、可发现的软件实体。

  • 接口是采用中立的方式进行定义的，应独立于实现服务的硬件平台、操作系统和编程语言， 便于不同系统中的服务以一种统一和通用的方式进行交互。
    

• 服务请求者：可以是服务或者第三方的用户， 通过查询服务提供者在服务注册中心发布的服务接口的描述，通过服务接口描述来通过RPC 或者SOAP进行绑定调用服务提供者所提供的业务或服务。

• 服务提供者：作为服务管理者和创建者，必须将服务描述的接口发布到服务注册中心才能被潜在的服务请求发现，能够为合适的服务请求者提供服务。

• 服务注册中心：相当于服务接口的管理中心， 服务请求者能够通过查询服务注册中心的数据库来找到需要的服务调用方式和接口描述信息。

• 发布：为了便于服务请求者发现，服务提供者将对服务接口的描述信息发布到服务注册中心上。

• 发现：服务请求者通过查询服务注册中心的数据库来找到需要的服务，服务注册中心能够通过服务的描述对服务进行分类， 使服务提供者更快定位所需要的服务范围。

• 绑定和调用：服务请求者在查询到所需要服务描述信息，根据这些信息服务请求者能够调用服务。
  还有一个例子在ppt上

2. 不知道什么标题（优缺点）

• 面向服务软件架构风格在于具有基于标准、松散耦合、共享服务和粗粒度等优势，表现为易于集成现有系统、具有标准化的架构、提升开发效率、降低开发维护复杂度等。

• 通过采用SOA架构，在进行一次开发成本急剧减少的同时，由于系统具有松散耦合的特征使得维护成本也大大减少。

• 优点

  • 灵活性，根据需求变化，重新编排服务。

  • 对IT资产的复用。

  • 使企业的信息化建设真正以业务为核心。业务人员根据需求编排服务，而不必考虑技术细节。

• 缺点

  • 服务的划分很困难。
  • 服务的编排是否得当。
  • 如果选择的接口标准有问题，如主流的Web service之类，会带来系统的额外开销和不稳定性。
  • 对IT硬件资产还谈不上复用。
  • 目前主流实现方式接口很多，很难统一。
  • 目前主流实现方式只局限于不带界面的服务的共享。

• 适用范围

  • 金蝶EAS

6.微服务架构（review里没有，这里就不写了）

7.正交架构风格

1. 基本思想

• 正交软件架构(Orthogonal Software Architecture) 由组织层(Layer)和线索(Thread)的组件(Component)构成。
  ◦ 层是由一组具有相同抽象级别(Level of Abstraction)的组件构成。
  ◦ 线索是子系统的特例，它是由完成不同层次功能的组件组成(通过相互调用来关联)，每一条线索完成整个系统中相对独立的一部分功能。
  ◦ 如果线索是相互独立的，即不同线索中的组件之间没有相互调用，那么这个结构就是完全正交的。
• 正交软件架构是一种以垂直线索组件族为基础的层次化结构
• 其基本思想是把应用系统的结构按功能的正交相关性，垂直分割为若干个线索(子系统)，线索又分为几个层次，每个线索由多个具有不同层次功能和不同抽象级别的组件构成。

2. 特点
   ◦ （1）由完成不同功能的n(n>1)个线索(子系统)组成；
   ◦ （2）系统具有m(m >1)个不同抽象级别的层；
   ◦ （3）线索之间是相互独立的(正交的)；
   ◦ （4）系统有一个公共驱动层(一般为最高层)和公共数据结构(一般为最低层)。
3. 优缺点

• 优点
  ◦ （1）结构清晰，易于理解。由于线索功能相互独立，组件的位置可以清楚地说明它所实现的抽象层次和负担的功能。
  ◦ （2）易修改，可维护性强。由于线索之间是相互独立的，所以对一个线索的修改不会影响到其他线索。
  ◦ （3）可移植性强，重用粒度大。因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现架构级的重用。
• 缺点
  ◦ 在实际应用中，并不是所有软件系统都能完全正交化，或者有时完全正交化的成本太高。因此，在进行应用项目的软件架构设计时，必须反复权衡进一步正交化的额外开销与所得到的更好的性能之间的关系

4. 示例
   

8.异构风格

1. 基本思想：异构架构是几种风格的组合，组合方式可能有如下几种：
   ◦ （1）使用层次结构。一个系统组件被组织成某种架构风格，但它的内部结构可能是另一种完全不同的风格。
   ◦ （2）允许单一组件使用复合的连接件。
2. 优缺点

• 优点
  ◦ （1）选择异构架构风格，可以实现遗留代码的重用。
  ◦ （2）在某一单位中，规定了共享软件包和某些标准，但仍会存在解释和表示习惯上的不同。选择异构架构风格，可以解决这一问题。
• 缺点
  ◦ 不同风格之间的兼容问题有时很难解决

3.示例

9.基于层次消息总线的架构风格

1.基本思想

• JB/HMB风格基于层次消息总线、支持组件的分布和并发，组件之间通过消息总线进行通讯。
• 消息总线是系统的连接件，负责消息的分派、传递和过滤以及处理结果的返回。
• 各个组件挂接在消息总线上，向总线登记感兴趣的消息类型。
• 不要求各个构件具有相同的地址空间或局限在同台机器上，可较好地描述分布式并发系统。
• 
  2.优缺点
   优点
  ◦ （1）JB/HMB风格的构件接口是一种基于消息的互联接口，可以较好地支持架构设计。降低了构件之间的耦合性，增强了构件的重用性。
  ◦ （2）JB/HMB风格支持运行时系统演化，主要体现在可动态增加和删除构件，动态改变构件所响应的消息以及消息过滤这三个方面。
   缺点是重用要求高，可重用性差。

10.模型-视图-控制器风格

1. 基本思想：模型-视图-控制器风格（Model- View-Controller，MVC）主要是针对编程语言Smalltalk 80所提出的一种软件设计模式。

• MVC结构主要包括模型、视图和控制器三部分。

  • 模型(Model, M)：模型是应用程序的核心，它封装了问题的核心数据、逻辑关系和计算功能，提供了处理问题的操作过程。

  • 视图(View,V)：视图是模型的表示， 提供了交互界面，为用户显示模型信息。

  • 控制器(Controller, C)：控制器负责处理用户与系统之间的交互，为用户提供操作接口。

  • 

2. 优缺点

• 优点

  • 多个视图与一个模型相对应。变化——传播机制确保了所有相关视图都能够及时地获取模型变化信息，从而使所有视图和控制器同步，便于维护。

  • 具有良好的移植性。由于模型独立于视图，因此可以方便的实现不同部分的移植。

  • 系统被分割为三个独立的部分，当功能发生变化时，改变其中的一个部分就能满足要求。

• 缺点

  • 增加了系统设计和运行复杂性。
  • 视图与控制器连接过于紧密，妨碍了二者的独立重用。
  • 视图访问模型的效率比较低。由于模型具有不同的操作接口，因此视图需要多次访问模型才能获得足够的数据。
  • 频繁访问未变化的数据，也将降低系统的性能。

3. 适用范围
   MVC被广泛的应用于用户交互程序的设计中。spring