软件体系结构

November 2, 2021 × 10.8k words × 39 minutes

01 概述

软件体系结构（Sofrware Architecture）是分析与设计之间的桥梁，但着重设计理念和方法。体系结构模型显示了软件系统构件之间的连接关系。

1-1 目的意义

其在软件生命周期（Waterfall Model, 瀑布模型）中的位置：

SA的目标：

代表系统公共的高层次抽象
- 系统大部分相关人员将其作为一个互相理解的基础
- 形成统一认识，互相交流
早期设计决策的体现
- 明确对系统实现的约束条件
- 决定开发和维护的组织结构
- 制约系统的质量属性、预测质量
- 有助循序渐进的原型设计
- 可以作为培训的基础
是可传递和可重复的模型

1-2 知识结构

1-3 基于构件

系统由构件的集合及它们间的关系组成，这样的系统可以成为更大的系统的组成元素。

1-3-1 基于构件的软件工程

基于构件的软件工程（Component-Based Software Engneering）通过复用力度合适的构件，扩展、组装构件来构建软件系统。即 软件开发 = 构件开发 + 基于SA的构件组装。

1-3-1-1 复用的层次

代码（算法）复用
设计复用
分析与测试的复用
……

1-3-1-2 构件技术

构件（Component）指语义完整、语法正确、有可复用价值的软件单元。

结构上，是语义描述、通信接口、实现代码的复合体
行为上，是有一定功能、独立工作、与其他构件配合协调工作的程序体

面向对象（Object Orientation, OO）技术达到类级重用（粒度太小）。

现有成熟平台、产品和流派：CORBA、Java、.Net、Web服务……

组装、配置与部署

组装 - 适当修改构件互相连接
配置 - 通过配置，同一构件可被多次部署，表现出不同的实例

1-3-2 编译器案例

编译器复合构件Compiler包括三个成员构件

语法分析器 Parser - 检查语法，构造语法树
语义分析器 Semanticizer - 用语法树检查文本的语义正确性
代码生成器 Code Generator - 便历语法树生成机器代码

1-3-2-1 语法分析器

component Parser is  //语法分析器 
	provides:        //提供给外界的 
		function Initialize() ; 
        function FileName() return String;    
    requires:        //外部需要的 
        function Semantize(Tree) ; 
        function Generate(Tree) ; 
end component;

1-3-2-2 语义分析器

component Semanticizer is //语义分析器
     provides:
        function Semantize(Tree) ; 
        function Incremental-Semantize(Context:Tree; Addition:Tree) ; 
    requires: 
        function FileName() return String; 
end component;

1-3-2-3 代码生成器和编译器

component CodeGenerator is //代码生成器 
    provides: 
        function Generate(Tree) ; 
    requires: 
        function Semantize(Context:Tree; Addition:Tree) ; 
end component; 

component Compiler is //编译器
    provides: 
        function Initialize() ; 
end component;

1-3-2-4 构件间关系

component body Compiler is 
    reference: 
        Parser，Semanticizer，CodeGenerator; 
    instance: 
        Parser P; Semanticizer S; CodeGenerator G; 
    connection: 
        P.Semantize to S.Semantize; 
        P.Generate to G.Generate; 
        S.FileName to P.FileName; 
        G.Semantize to S.Incremental-Semantize; 
    mapping: 
        Initialize to P.Initialize; 
end component;

1-4 设计的层次

层次化软件设计可在多个层次上设计系统，每一层处理不同的设计关注点。

最少三层的软件设计层次

体系结构级：系统性能与构件间的整体联系【构成元素是模块】
代码级：算法和数据结构【构成元素是编程语言原语】
执行级：包括存储器的映射，数据格式匹配，堆栈和寄存器的分配【构成元素是硬件支持的位模式】

1-5 其他相关

1-5-1 体系结构风格

描述特定系统组织方式的惯用范例（反映众多系统共有的结构和语义）；独立于实际问题，强调通用组织结构，比如管道线，客户机-服务器等。

1-5-2 设计模式

程序/应用级别的复用。

包含固有问题的解决方案；规范了小粒度的结构成分，独立于程序语言。强调直接复用的程序结构，处理系统设计/实现中特殊的重复出现的问题。

1-5-3 应用框架

系统级别的复用。

可复用的设计构件，规定了应用的体系结构，阐明了整个设计，协作构件之间的依赖关系、责任分配和控制流程。表现为一组抽象类及实例间的协作方法。

1-6 设计原则

抽象（集中主要特征，隐藏细节）
分而治之（横向按层次分解问题或纵向分解后相互配合）
封装和信息隐藏（留出统一形式的访问方式）
模块化（划分软件为可独立访问的成分，支持重用）
高内聚和低耦合（软件内关联紧，软件间关联松）
关注点分离（分离（非）/关注点，适应关注点间的部分）
策略和实现的分离（上下文相关的决策独立于执行算法）
接口和实现的分离（信息隐蔽性，可维护性）

02 软件体系结构描述语言

需要统一的形式化的描述

系统架构师
- 在系统架构中找到共性特征
- 在各个方案中作出原则性选择
- 体系结构设计工具
结构约束

2-1 软件体系结构描述语言

软件体系结构描述语言（Architecture Description Language, ADL）关注粗粒度的软件体系结构元素（构件和连接件）及其整体的互连结构。

是对体系结构进行验证、演化、分析的前提和基础。关注整个应用的高层结构。

2-1-1 ADL能力

构造能力 - 使用较小的独立体系结构元素建造大的软件系统
抽象能力 - 不关心具体的实现细节
复用能力 - 构件、连接件、SA都可复用
组合能力 - 局部结构被描述，进而支持动态变化
异构能力 - 不同SA描述关联存在
分析推理能力 - 进行多种性能和功能上的推导

2-1-2 软件体系结构模型

（Garlan & Shaw模型）：

1	SA = {Components, Connectors, Constraints}

对比：

2-1-2-1 基本要素一构件

系统中主要的计算元素和数据存储。有独立功能可复用的模板单元。

特点：1) 构件间相互独立（封装）；2) 通过接口（Interface）与外部环境交互；3) 接口由一组端口组成，每个端口为一个交互点；4) ADLs支持构件建模，描述其计算功能、结构特征。

不同构件类型：

部件类型	部件支持的相互作用类型
模块（Module）	过程调用、数据共享
对象（Object）	方法调用
过滤器（Filter）	数据流
过程（Process）	消息传递、远程过程调用（RPC）、通讯协议、同步
数据文件（Data File）	读/写
数据库（Database）	模式（Schema）、查询语言

2-1-2-2 基本要素二连接件

表示构件间的交互。

特点：1) 构件的粘合剂；2) 复杂情况由连接件实现构件交互；3) 有的连接件多于两个角色，如广播。

可与构件不同，不与实现系统中的编译单元对应。
可以是共享变量、表入口、缓冲区、SQL语句等；
也可表达体系结构级复杂通信协议；
通过构造连接器类型将这些协议系统化、抽象并复用。

2-1-2-3 基本要素三配置

构件与连接件之间的拓扑逻辑和约束。

构件端口与连接件角色之间显式连接。关注：1) 构件是否正确连接；2) 接口是否匹配；3) 通讯是否正确。

理想情况

从配置中澄清系统结构
不需研究组件与连接件就能使构建系统的各种参与者理解系统
可用文本/图像

2-2 不同语言

不同语言强调了体系结构的不同侧面。

C2; 支持基于消息传递风格的用户界面系统描述
UniCon; 支持异构的构件和连接类型并提供了关于体系结构的高层编译器
Wright. 支持体系结构构件之间交互的说明分析

2-2-1 ACME

由卡耐基梅隆大学Garlan等人创建的一门体系结构描述语言。

严格来说，ACME不是真正意义上的ADL，是一种体系结构变换语言，提供一种在不同ADL的体系结构规范描述之间实现变换的机制。

支持从不同方面对体系结构进行描述 1) 结构；2) 属性；3) 约束；4) 类型和风格。

2-2-1-1 结构

其中结构实体：1) 系统；2) 构件；3) 连接件；4) 端口；5) 角色；6) 表述；7) 表述映射。

示例，用ACME描述C/S体系结构范例

System simple_CS = {
	Component client = { Port sendRequest }
	Component server = { Port receiveRequest }
	Connector rpc = { Roles{caller, callee} }
	
	Attachments : {
		client.sendRequest to rpc.caller;	
		//Client的发送请求端口绑定到rpc的caller角色
		
		server.receiveRequest to rpc.callee	
		//Server的接受请求端口绑定到rpc的callee角色
	}
}

图形化描述：

2-2-1-2 属性

ACME支持任意的属性列表对体系结构进行注释。

构件通过接口规约定义了一组属性（功能/非功能属性）；连接件通过协议规约定义了一组属性（接口类型、事件发生顺序和对交互的承诺）。

示例：

System simple_CS = {
	Component client = { 
		Port sendRequest;
		Properties {
			requestRate : float = 17.0;
			sourceCode : externalFile = "CODE-LIB/client.c"
		}
	}
	
	Component server = { 
		Port receiveRequest;
		Properties {
			idempotent : boolean : true;
			maxConcurrentClients : integer = 1;
			multithreaded : boolean = false;
			sourceCode : externalFile = "CODE-LIB/server.c"
		}
	}
	
	Connector rpc = { 
		Roles caller, callee;
		Properties {
			synchronous : boolean = true;
			maxRoles : integer = 2;
			protocol : WrightSpec = "..."
		}
	}
	
	Attachments : {
		client.sendRequest to rpc.caller;
		server.receiveRequest to rpc.callee	
	}
}

2-2-2 UML

以统一建模语言UML从不同侧面（视点、视图、模型）描述系统的结构。

功能模型（用例图）
静态模型（类、构件、组合结构图）
动态模型（时序、通信、活动图）
配置模型（配置图）

【软工】中详述

2-3 4+1视图模型

描述系统的高级抽象为中心，不关心具体的建模细节，划分了体系结构建模和传统软件结构的界限。

逻辑视图 | 最终用户 - 系统的功能需求
开发视图 | 编程人员 - 软件模块的组织和管理
过程视图 | 系统集成人员 - 系统运行特征、非功能需求
物理视图 | 系统工程人员 - 把软件映射到物理硬件上

Rational Unified Process

03 体系结构风格

新的软件开发要求构件技术。

从面向对象到基于构件的软件生产：

3-1 核心模型

软件体系结构核心模型：

构件 - 粒度合适的可复用单元
连接件 - 构件间的交互
配置 - 构件和连接件拓扑逻辑和限制
端口
角色

3-1-1 公共框架/组成成分

公共框架：构件 + 连接件。

一个体系结构风格定义了构件和连接件的符号集，及其如何组合的约束集合。

3-1-2 选择原则

特定风格给出了软件系统的特定组织模式，设计者容易识别哪种风格适于解决哪种问题。

构件和连接件的类型
构件间的控制如何被共享和传递
数据如何被共享
数据和控制是如何交互的
优缺点
特性

3-2 通用风格

通用风格解决一些典型问题。

通用体系结构风格表：

高级别问题分解（High Level Decomposition）
- 管道过滤器（Pipes & Filters）
- 分层系统（）
- 黑板知识库（Blackboard）
- 面向对象（OO）
独立组件和分布式系统（Independent Components）
- 事件驱动（Event Systems）
- 中间层经纪人（Broker）

3-2-1 管道过滤器风格

每一处理步骤由一个过滤器（构件）完成，这些过滤器由携带数据的管道（连接件）连接起来。

过滤器Filters - 从输入源读入一个数据流，并从输出池写出另一数据流
管道Pipes - 把一个过滤器的输出传送到另一过滤器作为输入

通过不同组合方式连接过滤器可以提供处理数据的不同方式。

可解决的问题

自然分为几个步骤（一系列独立的增量计算/转换）
可能需要重组步骤
不连续步骤不共享信息/状态

范例（编译器）

3-2-2 面向对象风格

对现实世界的自然建模方法。1) 封装；2) 继承；3) 重用。对象是构件实例。

数据的表示和相关操作被封装为抽象数据类型
抽象数据类型只有封装的特点，没有继承的特点

优点

和现实世界有对应关系
隐藏实现细节，可在不影响客户的前提下改变实现细节
内部表达的保护

缺点

对象之间交互需要知道彼此的标识
多个对象对同一资源的访问（访问控制）

3-2-3 分层系统

构件

组织为层次结构
内（下）层对外（上）层提供服务
外（上）层是内（下）层客户
相邻可见

连接件

层次间的协议，规定了层次间的交互方式。

特性

抽象，依赖性本地化，可交换替代性，重用性。

可解决的问题

系统有不同层次的抽象层
请求向下（内）传递，通知向上（外）传递
层间有稳定的界面

范例

分层通信协议

3-2-4 仓库系统及知识库

在仓库风格中，两种构件：中央数据结构说明当前状态，独立构件集合对中央数据单元进行操作。仓库与构件间的相互作用在系统中会有很大的变化。

两种控制策略：1) 输入数据流中的事务指令触发；2) 中央数据结构的当前状态。

3-2-4-1 黑板知识库

用一个中央黑板数据结构用来描述对一个问题的不完全解决方案。

一些独立的知识源可以分别针对问题的某部分进行求解。1) 只同黑板通信；2) 对该不完全解决方案可读/建议修改；3) 通过一个控制组件完成（监视黑板状态）

可解决的问题

对复杂数据解释（信号处理、语音识别）
不知道对某问题有决定性的解决性方案
对问题不同部分可能需要不同代表性的解决框架
对不同的问题解决者，可能没有组合它们贡献的固定策略
可能需要和不确定的知识打交道

3-2-4-2 范例

语音识别：

优点

有限范围内容易实现不同的问题解决者和诱导启发式的控制方法
知识源可重用，规模上伸缩性好
系统在有限范围内可容忍不可靠的问题解决者

缺点

测试困难
难以保障最佳解决方案
控制策略通常需要启发诱导
计算开销大
并行处理可行（同步/锁机制引入）

3-2-5 独立组件

两种：1) 通信进程（Communicating Processes）；2) 事件驱动。

3-2-5-1 通信进程

消息在命名的参与者间传播。

构件：独立进程

连接件：消息传递（点对点，同步或异步；RPC）

3-2-5-2 事件驱动

未命名的参与者间隐式调用。

不直接调用一个过程，而是发布或广播一个或多个事件，构件通过注册与事件关联的进程表示对该事件的兴趣。

事件发布者不知道哪些构件会受到事件的影响。

构件：对象/进程

连接件：事件-过程的绑定

显式调用 vs 隐式调用

优点

计算和协作分开
系统维护和重用
- 无静态和固定对象名字的依赖
- 系统重用（注册事件引入新构件）和演化（不改变接口构件替代/升级）和集成容易
可并行调用

缺点

构件放弃了自身对系统计算的控制
数据交换：通过事件交互数据的系统需要依赖共享缓冲区，整体性能和资源管理可能会成为问题
正确性检验：需要考虑发布事件时事件激发的上下文
需要一个关注事件的机制，事件，注册，策略调度
间接通信意味着一些性能的损失

案例

DSMS中数据一致性约束的实现
程序调试工具中变量监视器对变量值的刷新
IDE中自动语法检查
天气预报手机短信

联系Android中事件处理机制！

Class myListener implements ActionListener {
	
    actionPerformed(ActionEvent e)  { 
        
        // code to handle the event
    } 

}
.
.
.
Button b = new Button();
b.addActionListener(new myListener());

3-3 分布式系统

分布式系统是多个处理机通过通信线路互联而构成的松散耦合的系统。

分布性。结点分布松散耦合
自治性。结点内自主控制
并行性。大任务划分成小任务在不同结点上运行
全局性。单一的、全局的进程通信机制

主要类型

C/S
- 面向服务的体系结构Service-Oriented Architecture
Broker
- CORBA
P2P

示例

3-3-1 Client/Server

构件 1) 客户机；2) 服务器；3) 网络。

3-3-1-1 胖客户机（二层C/S）

服务器（后台）负责数据管理，客户机（前台）负责用户的交互任务。

第一层：用户界面

第二层：数据库管理服务

3-3-1-2 瘦客户机（三层C/S）

两层C/S是以局域网为中心且以单一服务器为主，难以扩展到Internet。

三层C/S增加了一个中间层的应用服务器，包含了所有的业务逻辑，而客户机只是表示层，所以也称为“瘦客户机”。

第一层：用户界面

第二层：中间层Broker（应用服务器）

第三层：数据库管理服务

3-3-1-3 Broker

通过远程服务调用分离客户机与服务器。集中处理某一业务逻辑，提高灵活性、可维护性、重用性、可扩展性。

典型范例

多代理系统（Multi-Agent Systems）通常是通过Brokers（JADE）来协调的
Brokers是基于高级的通讯协议（FIPA-ACL）来提供传递消息的标准机制
CORBA （3.5章节）也用到Brokers：Object Request Broker (ORB)

优点

位置透明，C和S不需知道彼此具体位置，通过拥有唯一标识的代理进行
Broker容易被调整、适应新的业务需求
隔离表示层和数据层，未授权的用户难以绕过并非法访问数据
- 提供了安全管理和控制机制
逻辑功能上划分明确，各层可并行开发
组件关联关系容易被调整

缺点

容错性差
效率有限
测试困难

3-3-2 Browser/Server

三层应用结构的一种实现方式。

下图缺Web Server <–>DB部分

数据库服务器
应用程序以网页的形式存放于Web服务器上
系统安装、维护全在服务端完成
相对C/S更好提高业务覆盖范围

优点

Information hiding 信息隐藏 //Web浏览器和服务器共同工作，他们之间信息隐藏、模块化
Abstraction 抽象 //浏览器几乎都以同样的方式工作
Encapsulation 封装 //数据和程序与用户分离
Concurrency 并发 //允许多位用户同时请求对同一页面的浏览

3-4 过程控制

持续运行的系统用于过程控制。范例：温度控制器。

控制环路中 1) 具有某些构件；2) 构件间保持特殊关系。

过程变量

过程变量是可以度量的过程属性，可通过传感器获得的值。

被控变量

必须被系统控制的过程变量。

设定点

被控变量的目标值。

目标

把被控变量维持到或接近于目标值。

3-4-1 开环系统

不用关于过程变量的信息来调整系统。

几乎不适合于真实世界的物理过程。

3-4-2 闭环系统

用关于过程变量的信息来操控过程变量。

范例：反馈控制系统

核心部分

计算元素
- 过程定义（过程变量改变机制）
- 控制算法
数据元素
控制环路方案

3-5 异构体系结构

很难用同一种风格或模式创建一个复杂系统，通常用几种风格组合而成。

04 案例研究 - 移动机器人

从需求到体系结构选择到实现

从给定需求规格说明，可建立许多可能的体系结构
从一个给定的体系结构描述，可以得到许多的系统实现

问自己 (￣﹏￣；)

ROS（Robot Operating System）是哪种风格？

4-1 需求获取/分析

构建一个系统来操作移动机器人，以处理外部传感器和传动装置，且相应速度和工作环境中的系统行为相匹配。

软件功能

采集从外部传感器发送的输入信号
操作车轮和其他可移动零件的运动
规划未来的移动路线

其他因素

障碍物可能会阻挡机器人的移动路线
传感器的输入信号可能非常弱
机器人的电力可能使用完
机械的局限性可能会限制移动的精确性
机器人可能会处理有毒材料
不可预知的事件可能要求它具有快速响应
……

四项基本需求

该体系结构必须能协调有准备的行为和反应行为
- 为完成指定目标（采集岩石标本）而采取的行动
- 由环境引起的反应行为（如避开障碍）
该体系结构必须能处理不确定性
- 应对矛盾的传感器读数或其他不完整、不可靠的信息
该体系结构必须能应对操作和环境中固有的危险
- 通过容错、安全、性能等方面考虑
- 保持机器人操作及其环境的完整性
- 如电力下降、有毒气体、门意外打开时，不至于导致灾难
该体系结构必须能给予设计者灵活性
- 任务改变时的重新配置

4-2 方案分析

考虑四种有代表的体系结构设计

Lozano的控制环路
Elfes的分层组织结构
Simmons的任务控制体系结构
Shafer的黑板组织结构应用

4-2-1 控制环路（闭环）

开环用于大多数工业机器人，任务预先设定，无需更多考虑环境因素。

闭环用于移动机器人，加入反馈机制。

闭环范例更适合简单的机器人系统，该系统只处理很少的外部事件，且任务不需要复杂的分解。

4-2-1-1 行为和反应

闭环结构简单，机器人与外界的交互非常清晰。

闭环总是假定环境的变化是连续的，且需要连续的反应（通过开关阀门逐渐控制温度、压力）；然而机器人需要经常面对完全不同的、不连续的事件，而在不同行为模式中转换（如在控制操纵器的运动和调整底座位置间做出选择来避免失去平衡）－闭环没有说明怎样处理这种模式转换。

对于复杂性任务，控制环路并没有给出将软件分解成几个协作构件的方法（如机器狗需同时完成走路、踢球、射门这样综合性任务－细节的缺失）

4-2-1-2 不确定性

对于不确定性，控制环路偏爱通过迭代来降低未知性。试探和错误处理程序通过动作和响应来消除每次循环中的可能性。

但对于更细致的处理，没有提供一个基本循环来集成这些操作的框架，也没有提供委托独立实体进行操作的框架。

4-2-1-3 应对危险

闭环范例提供对容错度和安全性的支持。

因为它的结构简单，使得复制操作更加容易，并能减少系统中错误发生的几率。

4-2-1-4 灵活性

主要构件（监视器、传感器、发动机）是彼此分开的，并能够被独立地替换。

微小的修改必须在模块中进行，并且改动不会在体系结构的细节层次上反映出来。

4-2-2 分层体系结构

总体上提供了一个合理组织构架的框架，因为对不同层角色的描述是精确的。

缺陷是当现实过程中牵扯到更深层次的细节时，这种模型通常会完全失效；通信模式不可能遵循这种体系结构所规定的层次结构。

4-2-2-1 行为和反应

定义更多的执行委托任务的构件，分层模型避开了一些控制环路方案面临的问题。

分层模型专用于自动控制的机器人，所以它揭示了针对这种机器人所必须解决的问题（如传感器集成）；另外它定义了抽象层（机器人控制与导航）来指导设计；第4层现实世界建模和第7层全局计划有助于机器人整体行为的把握（有准备的和反应性的）。

但是这种分层体系结构并不适合现行的数据和控制流模式：分层模型要求请求和服务必须在相邻的两层进行，现实中信息交换并不是直接的。

4-2-2-2 不确定性

抽象层的存在满足了处理不确定性的需要。

通过在较高层加入可以用到的知识，使得在最低层中不确定的事物在较高层中会变得确定。比如外界模型中的上下文能够提供某些线索来消除相矛盾的传感器数据中的歧义

4-2-2-3 应对危险

可以从不同角度分析数据和命令，将多个检查和平衡操作合并到系统中。

抽象机制满足了容错性和被动的安全性：你坚持什么都不做（联系抽象类便于理解）。

性能和主动安全性需要缩短通信路径：你必须去做某些事而不是避免做某些事。

4-2-2-4 灵活性

层次间的依赖性使得构件的替换和添加更加困难。层次间复杂的关系使得解读每一次变化都会令人头疼。

4-2-3 隐式调用

内嵌于任务控制体系结构（Task-Control Architecture），已应用于众多移动机器人上，如漫步者
用隐式调用来协调任务间的交互。

整体上提供了对机器人的任务协调的全面支持；功能强大，非常适合复杂的机器人项目。

4-2-3-1 行为和反应

一方面是任务树，另一方是异常、窃听、监控器，这些为有准备的动作（任务树）和响应行为（外部环境或事件触发的行为）提供了清晰的划分。

多个任务可以在同一时刻并发处理，并且这些处理是相互独立的（左移和前移），其他两个模型不能明确地处理并发，这是和该模型的明显区别。

4-2-3-2 不确定性

解决不确定性不够清晰，如果存在不可估计的情况：

会创建一个试验性的任务树
如果任务树中基本假设被证明是错误的，那么异常处理程序会不断地修改它直到正确为止

4-2-3-3 应对危险

异常、窃听、监控器这些特点使其考虑了性能、安全性、容错性这些问题。

还可以通过冗余来实现容错：为同一个信号注册多个处理者，如果一个处理者不可用，将请求发送给其他处理者可以继续提供服务。多个处理者并发地处理针对同一请求的多个事件，性能也会提高

4-2-3-4 灵活性

隐式调用使得增量开发和构件的替换更为直接。在不影响现有构件的情况下，很容易在中心服务器注册新的处理者、异常、窃听器或监控器。

4-2-4 黑板体系结构

构件

captain（指挥）：总监控器；map navigator（地图导航）：高层路线规划程序；lookout（监视）：为获取路标而监控环境的模块；pilot（驾驶）：底层的路线规划程序和发动机控制器。

感知子系统：这个模块接收来自多个传感器的原始输入并将它们整合成一致的解释。

整体上来说，基于数据库内容的隐式调用机制－黑板体系结构具有模拟任务协作的能力；满足了以灵活的方式协调和解决不确定性的需求；这些能力稍逊于基于任务控制体系结构的隐式调用相应的能力。

4-2-4-1 行为和反应

构件（感知子系统中的模块）通过黑板系统的共享知识库来进行通信，每个模块只对某种信息感兴趣。

数据库可以立刻向这些模块发送它们需要的信息，或者当其他模块向数据库插入这些信息后，再向这些模块发送它们需要的信息。

lookout可以监视某种地理特征，当感知子系统存储的图像与描述相匹配，数据库就会通知lookout，虽然有时构件间直接交互更自然，但控制流必须符合黑板的运行机制。

4-2-4-2 不确定性

黑板也是一种解决矛盾和不确定性情况的方式。

所有的数据都保持在黑板数据库中，负责处理不确定性的模块通过在数据库中注册来获取必需的数据，如lookout需检测路标的距离或颜色等时，通过感知子系统协调来自不同的传感器输入，可解决不确定性和输入的矛盾。

4-2-4-3 应对危险

通过黑板数据库进行通信和通过隐式调用的中心消息服务器进行通信的方式非常相似（对照：黑板状态变化／消息事件触发）。

定义了独立模块以观测数据库中意外事件或危险情况的信号，正是这些模块保证了反应速度、安全性、可靠性。

4-2-4-4 灵活性

和隐式调用一样，黑板体系结构风格支持并发以及发送者和接受者分离，这样有利于维护。

4-2-5 方案比较

各体系结构在控制方式、通信、构件特征等方面上的本质不同决定了它们满足需求的不同程度。

PS：ROS应该是黑板知识库风格，每个node是黑板知识库里的子模块，master也作为一个node。那么，黑板是啥呢？

05 分布式体系结构

A distributed architecture is an architecture supporting the development of applications and services that can exploit a physical architecture consisting of multiple, autonomous processing elements. Those elements do not share primary memory but cooperate by sending messages over the network.

流行的分布式体系结构

CORBA（OMG），J2EE（Sun），.Net（Microsoft）

J2EE和.Net
- 分布式体系结构上所提供的开发平台支持事务完整性、消息传递、目录服务、安全、异常处理、远程访问
- 开发人员只需集中精力在构件功能上，无需关心所有的底层技术基础
SOA（面向服务的体系结构）
- 将异构平台上的不同功能部件（服务）通过接口和规范整合在一起，实现了松耦合的分布式计算
3层/n层体系结构
- 提出了中间件，是分布式体系结构／分布式计算的基础

5-1 基于CORBA的分布式构件技术

对象请求代理（Object Request Broker, ORB）提供了CORBA基础架构说明。

针对ORB，OMG（对象管理协会）进一步提出CORBA技术规范，主要内容包括1) 接口定义语言（Interface Definition Language, IDL）；2) 接口池（Interface Repository, IR）；3) 动态调用接口（Dynamic Invocation Interface, DII）；4) 对象适配器（Object Adapter, OA）。

5-1-1 定义的对象

5-1-1-1 CORBA服务

CORBA Service提供实现对象的基本功能。为创建对象、对象访问控制、对象生命期控制、对象引用等提供了一套基本功能服务，是底层支持的必须服务。

对象的命名服务
对象交易服务
持久对象服务（Persistent State Service）

标准的CORBA Service：

5-1-1-2 CORBA设备

CORBA Facility包括

水平CORBA设备：各种工业部门中。针对所有类型CORBA应用的元素，不考虑设备使用的领域，包括了用户接口和系统管理设备
垂直CORBA设备：只在特殊垂直市场和工业中针对某些应用的功能，也称领域CORBA设备，如银行会计业中的分期付款、制造业中的自动化控制设备等

5-1-1-3 应用对象

Application Object 处于 OMA（对象管理体系）层次结构的最顶层。

是符合OMA标准接口的应用程序、进程、类实例等
可被独立定制，必须符合OMA标准接口

OMA中的对象作为服务者被动态引用，以唯一标识提供服务，对象间交互通过ORB实现。

5-1-1-4 ★ORB

OMA的核心部分。

应用对象在分布式对象系统中，以系统客户身份，通过ORB与系统中其他对象完成交互。

Clients see only an object’s interface, never the implementation.

To communicate, the request does not pass directly from client to object implementation.

Instead every request is passed to the client’s local ORB, which manages it.

5-1-2 CORBA规范

ORB
IDL（接口定义语言）
存根（Stub）
框架（Skeleton）
对象适配器（Object Adaptor）
动态调用接口

5-1-2-1 IDL

CORBA利用IDL统一地描述服务器对象（提供服务的对象）的接口，它本身是面向对象的；IDL语言是CORBA中定义的一种中性语言，不涉及对象的具体实现。

CORBA定义了IDL语言到C，C++，Java等语言的映射，使开发商开发支持CORBA体系结构的产品。

示例

IDL对对象接口定义，编译后的代码映射到具体编程语言，产生客户Stub和服务Skeleton。

5-1-2-2 存根和框架

存根（Stub / 桩程序）是客户端代码，客户应用程序通过桩向服务器应用程序发送请求。

框架（Skeleton）是服务端代码，将对象适配器转发的请求调度到对象实现上的适当操作的代码。

5-1-2-3 ORB

把客户请求传递给目标对象，并把目标对象的执行结果返回给请求客户。

位置透明：屏蔽了对象位置、对象实现、对象执行状态、对象通信机制和数据表示。

5-1-2-4 对象适配器

负责接收服务请求，完成实例化服务对象，向对象传送请求，为服务指定引用对象，提供运行环境；

给客户应用提供了一个假象（虚拟环境）：服务对象都是活动着的，随时等待客户应用发来请求。

5-1-3 平台无关性

CORBA/分布式对象风格的平台无关性

CORBA引入了分布式对象风格（Distributed Objects Style）
CORBA定义了一种面向对象的软件构造方法，使不同的应用可以共享由此构造出来的软件构件
每个对象都将其内部操作细节封装起来，同时又向外界提供了精确定义的接口，从而降低了应用系统的复杂性，也降低了软件开发费用
CORBA的平台无关性实现了对象的跨平台引用，开发人员可以在更大范围内选择最实用的对象加入到自己的应用系统之中
CORBA的语言无关性使开发人员可以在更大范围内互相利用别人的编程技能和成果

5-1-4 CORBA特点

引入代理 ORB（Object Request Broker）对象请求代理
- 可重用、可移植、互操作
位置透明
- 客户与服务完全分离
软总线机制
- 平台无关性，接口规范
面向对象的软件实现方法
- 封装，接口特性

5-2 基于服务的体系结构

面向服务的体系结构（Service-Oriented Architecture, SOA）

所有功能定义为独立的服务，服务间相互调用/组合
服务明确接口，通过接口发布、发现、调用服务
可设定服务顺序，形成业务流程

5-2-1 SOA特点

面向对象的粒度级别在类级，是紧耦合的模型；对于重用，它的抽象级别较低
构件通过内聚对象提高了粒度大小和抽象级别
面向对象的设计是实现构件技术的最佳方式，同样构件技术也是实现服务的最佳方式
基于SOA的系统可用构件组装服务，也可用面向对象的设计构建单个服务，但整体是面向服务的

5-2-2 服务

服务是封装成用于业务流程的可重用构件
取决于业务流程，服务可以是细粒度的，也可以是粗粒度的
企业可以将自己的服务向外发布到业务合作伙伴，也可以在组织内部发布服务
服务可以由其它服务组合而成

5-2-2-1 服务消费者

可以是一个应用程序、一个软件模块或需要一个服务的另一个服务；向注册中心**查询服务、绑定服务，根据接口契约执行服务**。

发现操作：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。

5-2-2-2 服务提供者

可通过网络寻址的实体，接受和执行来自消费的请求；将自己的服务和接口契约发布到服务注册中心。

绑定和调用操作：在检索完服务描述后，服务消费者继续根据服务描述中的信息来调用服务。

5-2-2-3 服务注册中心

服务发现的支持者；包含一个可用服务的存储库，允许感兴趣的服务消费者查找服务提供者接口。

发布操作：为了使服务可访问，需要发布服务描述以使服务消费者可以发现和调用它。

5-2-3 基于Web Service的SOA实现

Web服务是实现SOA的最佳方式。

核心技术

XML（eXtensible Markup Language）：Web服务中信息描述和交换的标准方法
SOAP（Simple Object Access Protocol）：为服务消费者和提供者之间的通信定义了基于XML格式的SOAP信封
WSDL（Web Service Definition Language）：定义了服务接口，即服务做些什么，如何访问服务，服务位于何处
UDDI （Universal Description Discovery and Integration）：提供了在Web上描述并发现服务的框架

协议及消息传递

Web Service中用SOAP进行协议与消息传递
应用程序请求（封装在XML中）被放入SOAP信封中（也是XML），并从消费者发送到提供者，由提供者发回的响应也采用相同的格式
它基于XML形式提供了一个用于在分散、分布环境中交换结构化和类型化信息的轻量级协议
将成熟的基于HTTP的WEB技术与XML的灵活性和可扩展性组合在了一起
解决了COM，CORBA的协同操作，实现了异构程序和平台间的互操作性

服务栈

5-2-3-1 SOAP

SOAP本身不定义任何应用语义，它只是定义了一种简单的机制，通过一个模块化的包装模型和对模块中特定格式编码的数据的重编码机制来表示应用语义，具有一定灵活性。

① 信封（SOAP Envelop）

它定义了一个整体的表示框架；表示消息内容、处理者信息、以及处理选择要求。

② 编码规则（SOAP Encoding Rules）

定义了一个数据的编序机制；通过这样一个编序机制来定义应用程序中需要使用的数据类型，并可用于交换由这些应用程序定义的数据类型所衍生的实例。

③ SOAP RPC表示（SOAP RPC Representation）

它定义了一个用于表示远程调用和响应的约定。

5-2-3-2 WSDL

Web服务描述语言（WSDL）

用XML格式描述Web服务
描述Web服务的三个属性
- 服务做些什么：服务提供的操作、方法
- 服务位于何处：由特定协议决定的网络地址，如URL
- 如何访问服务：访问服务操作的必要协议
通过WSDL分离了服务接口定义与服务实现，WSDL不包括任何服务实现的细节

5-2-3-3 UDDI

统一描述、发现和集成协议（UDDI）

UDDI提供了在Web上描述并发现服务的框架，它为发布服务和发现服务定义了一个标准接口，这个接口是基于SOAP消息的
服务注册中心是一种服务代理，所有UDDI服务注册信息都存储在服务注册中心，它是在UDDI上需要发现服务的请求者和发布服务的提供者之间的中介
UDDI注册中心提供两种注册方式：公共UDDI注册中心（Public UDDI Registry）和私有UDDI注册中心（Private UDDI Registry）

【完结】

Categories: Software Engineering

01 概述

1-1 目的意义

1-2 知识结构

1-3 基于构件

1-3-1 基于构件的软件工程

1-3-1-1 复用的层次

1-3-1-2 构件技术

1-3-2 编译器案例

1-3-2-1 语法分析器

1-3-2-2 语义分析器

1-3-2-3 代码生成器和编译器

1-3-2-4 构件间关系

1-4 设计的层次

1-5 其他相关

1-5-1 体系结构风格

1-5-2 设计模式

1-5-3 应用框架

1-6 设计原则

02 软件体系结构描述语言

2-1 软件体系结构描述语言

2-1-1 ADL能力

2-1-2 软件体系结构模型

2-1-2-1 基本要素一 构件

2-1-2-2 基本要素二 连接件

2-1-2-3 基本要素三 配置

2-2 不同语言

2-2-1 ACME

2-2-1-1 结构

2-2-1-2 属性

2-2-2 UML

2-3 4+1视图模型

03 体系结构风格

3-1 核心模型

3-1-1 公共框架/组成成分

3-1-2 选择原则

3-2 通用风格

3-2-1 管道过滤器风格

3-2-2 面向对象风格

3-2-3 分层系统

3-2-4 仓库系统及知识库

3-2-4-1 黑板知识库

3-2-4-2 范例

3-2-5 独立组件

3-2-5-1 通信进程

3-2-5-2 事件驱动

3-3 分布式系统

3-3-1 Client/Server

3-3-1-1 胖客户机（二层C/S）

3-3-1-2 瘦客户机（三层C/S）

3-3-1-3 Broker

3-3-2 Browser/Server

3-4 过程控制

3-4-1 开环系统

3-4-2 闭环系统

3-5 异构体系结构

04 案例研究 - 移动机器人

4-1 需求获取/分析

4-2 方案分析

4-2-1 控制环路（闭环）

4-2-1-1 行为和反应

4-2-1-2 不确定性

4-2-1-3 应对危险

4-2-1-4 灵活性

4-2-2 分层体系结构

4-2-2-1 行为和反应

4-2-2-2 不确定性

4-2-2-3 应对危险

4-2-2-4 灵活性

4-2-3 隐式调用

4-2-3-1 行为和反应

4-2-3-2 不确定性

4-2-3-3 应对危险

4-2-3-4 灵活性

4-2-4 黑板体系结构

4-2-4-1 行为和反应

4-2-4-2 不确定性

4-2-4-3 应对危险

4-2-4-4 灵活性

4-2-5 方案比较

05 分布式体系结构

2-1-2-1 基本要素一构件

2-1-2-2 基本要素二连接件

2-1-2-3 基本要素三配置