软件体系结构

Chapter 0 —— 引子

1.软件危机

软件危机是指计算机软件开发和维护过程中遇到的一系列严重问题。包括两方面的问题：
（1）如何开发软件以满足日趋复杂的需求
（2）如何维护数量不断膨胀的软件产品

2.软件工程

（1）将系统化的、规范化的可量化的方法应用于软件的开发运行和维护，即将工程应用于软件。

（2）对（1）中所述方法的研究

3.软件工程的发展阶段

传统软件工程、面向对象的软件工程、构件软件工程、面向服务的软件工程

4.软件工程的基本方法

复用、分而治之、优化折中

Chapter 1 —— 概述

1.1 软件体系结构

（1）定义

软件体系结构定义了软件的局部与总体计算部件的构成，以及他们之间的相互关系。
总的来说，软件体系结构是由结构和功能各异、相互作用的部件集合，按照层次构成的。
体系结构=部件 + 连接件 + 约束
体系的核心模型由5种元素组成：构建、连接体、配置、端口和角色

（2）体系结构的类别

概略型
需求型
设计型

（3）SA对SE的贡献

开发团队的组织结构
需求获取
设计方案的选择
分析和描述复杂系统的高层属性
人员交流
技术进步

（4）软件质量

SE的目标是软件质量（运行时质量、非运行时质量、体系结构质量）
影响质量的因素：
功能、正确、性能、安全、鲁棒性、可信性、健壮性、易用性、适应性、移植性、重用性、集成性、可测性、兼容性、经济效益

1.2 当前的软件设计

（1）体系结构的设计选择对软件的长远成功是至关重要的

（2）体系结构描述具有不规范性

（3）软件体系结构理论和工具是解决软件复杂性和工程设计的必由之路

1.3 软件设计的层次

结构级
代码级
执行级

1.4 软件结构与软件工程

实现体系结构指导下的软件工程设计，关键在于建立软件构件的分析和构造的方法。
软件复用是技术的范畴
软件体系结构风格为大粒度的软件重用提供机会。

1.5 软件体系结构的知识体系

软件的体系结构应该是一个关于软件构成方面的具有层次性的知识体系
软件硬件层、基础控制描述层、资源和管理调度层、系统结构模式层、领域应用层

Chapter 2 —— 软件体系结构的研究和发展

2.1 软件工程设计和软件体系结构

（1）软件设计目标

在时间和各类资源限制下，最大程度地满足用户需求。

便于维护和升级，因此应该是模块化的
设计应该是便于移植的（移植比重新设计花费要小很多）
设计具有适应性
设计过程应该收到理性的控制
设计应该表现出概念的完整性

（2）软件设计中出现的问题

对于需求变化缺乏配合
过程控制对于维持软件设计的正确性缺乏保证
软件产品缺乏概念完整性

2.2 什么是软件体系结构

（1）Garlan and Shaw精简的定义为：

体系结构 = 组件 + 连接件 + 约束

（2）当前对软件体系结构的认识

体系结构是关于软件的系统级层次上的组成和行为的，是设计过程中不可缺少的一个阶段，对复杂软件的后期设计活动起着重要决定作用。
体系结构是由软部件和部件之间的联系组成，软部件又有自身的体系结构。
部件描述有3个方面：计算功能、结构特性、其他特性。
目前，没有哪个关于软件体系结构的描述可以说是完整的。关于什么是部件，什么是部件之间的联系并没和明确的界定。
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition.

2.3 软件体系结构的意义和目标

（1）软件体系结构在软件开发中的意义

软件体系结构是软件开发过程初期的产品，对于开发进度和软件质量的一切资金和劳务投入，可以获得最好的回报。
体系结构设计是形成的投资高汇报的重要因素。
正确有效的体系结构设计会给软件开发带来极大的便利。

（2）软件体系结构的目标

外向目标：建立满足终端用户要求的系统需求。
内向目标：建立满足后期设计者需要以及易于系统实现、维护和扩展的系统部件构成

2.4 软件体系机构的研究范畴

软件体系结构描述语言和工具（ADL）
产品线和标准：企业 -> 需求 -> 架构 -> 系统
软件体系结构风格以及风格的应用
体系结构文档化

Chapter 3 —— 软件体系结构的层次性

3.1 体系结构的基础和层次特性

从建筑学看软件的构成：基础、层次、模式、角色划分

（1）从建筑的基础性看软件构成

地基、材料、材料构成三个方面从根本上决定了建筑物的结构、性能、功用、建造方法，形成了建筑的基础。
构造软件同样需要基础。计算机硬件结构、软件的基本组成、构成软件的可用组块三个方面。

（2）从建筑的层次性看软件构成

建筑是由基本材料到基础构件再到整体框架逐层次发展和构成的历程。
软件的体系结构也是由使用最基本的材料开始，到认识常用基础构件再到组装和构造整体框架的发展过程。

（3）从建筑的组合性看软件构成

形态和构件组成了建筑模式。20多年建立了现代建筑学的250余种“场景－问题－解决方案”模式，涵盖不同的规模和形态
这些建筑学的思想在软件结构的研究中也得到了重视，提出并发展了软件“软件设计模式”的概念,进而又提出了“软件体系结构模式”的概念。

（4）从建筑业看各个角色的划分。

补充：

**软件的物质基础：
软件设计的物质基础是当前的计算机硬件，它决定了软件设计和实现的出发点。
软件的结构基础：

软件结构基础的思想和概念

3.2 软件体系结构的层次结构模型

（1）任何软件的完整结构都具有层次关系:

特定的软件需要特定的硬件环境运行
不存在不需要下层支持的抽象的上层结构或框架
层次性是软件体系结构的不变性质，是软件构成的共同规律

（2）软件体系结构的层次结构模型（6层）：

软件体系结构的层次结构模型

计算机硬件（硬件基础层）：软件运行的物质基础
软化的硬件层：在硬件结构和性能抽象的基础上，实现硬件的操作和控制描述（处理器：状态和指令集合中断：状态和中断服务）
基础控制描述层：建立在高级程序语言描述上的纯粹软件描述层，包括了高级语言所支持的所有程序控制和数据描述概念（程序设计语言、结构化分析、面向对象分析设计）
资源和管理调度层：在基础控制描述层建立的一切数据对象和操作，都需要在操作系统的协调和控制下才能实际的实现其设计的作用和功能（进程控制、分时系统、消息机制、I/O etc ）
系统结构模式层：最高层次的软件结构概念、属于体系结构风格或系统级别的设计模式、最高的抽象描述层（解释器、编译器、编辑器、管道/过滤器、黑板、C/S 、B/S、框架 etc.）
应用层：从纯粹应用领域出发所建立的系统结构概念（企业管理、公文处理、控制系统、CAD系统、ERP系统）

3.3 从层次模型看软件体系结构

数据库、网络、存储器，JavaEE、Spring ，etc.
层次模型对软件体系结构的认识：
- 体系结构是关于软件的构成部件及其连接的分层的结构框架
- 体系结构包括软件的内在概念和外在操作结构
- 体系结构分析与设计涵盖并指导着从逻辑结构设计到运行实现的软件工程的全部过程

Chapter 4 —— 软件体系结构的设计原理

（1）体系结构设计中遵循的原理

抽象：数据抽象、实体抽象、行为抽象、过程抽象、对象抽象、虚拟机抽象
封装：将抽象的属性和行为结合一起，隔离不同的抽象。
数据隐藏：对用户隐藏部件的实现细节。
模块化：代码结构物理分块
关注点分离：不同和无关联的责任应该在软件系统中分离开来，让他们出现在不同的部件中相互协作。
内聚和耦合
充分性、完备性、原始性：
充分性是指部件应该把握住与其进行有意义和高效交互抽象的所有特性；
完整性是指一个部件应该把握住所有与其抽象相关的特性；
原始性是指部件应该完成的操作都可以容易地得到实现（人的价值是最大的）；
策略和实现分离：策略部件负责处理上下文决策、参数选择等，实现部分专注算法的实现。
接口和实现分离：接口规范功能的使用方法，实现部分提供功能的具体方法。
分而治之：将复杂的问题分解为若干个小问题，自上而下的分析，自下而上的实现
层次化

（2）软件的非功能特性

可变性：包括可维护性、可扩展性、可重构性、可移植性
互操作性：不同系统之间相互操作
效率：资源占用、响应时间
可靠性：分为容错性和健壮性，容错性指在发生错误时可以确保正确的系统响应。健壮性不要求错误发生时能够继续运行，而是保证软件能以明确的可接受的方式终止。
可测试性
可重用性：重用其他构件，以及提供给其他构件使用

Chapter 5 —— 部件和连接器

部件和连接器被公认为体系结构的两大类构成部分
部件：软件系统的结构块单元，是功能设计和实现承载体
连接：是部件间建立和维持行为关联信息传递的途径
连接器：实现部件与部件之间联系的特殊机制或特殊部件
连接的实现机制：计算机硬件提供了实现一切连接的基础。高层次的连接建立在低层次之上，实现连接在不同的层次上有不同的概念或方法。
无论多么复杂的连接关系，其实现都是基于以下基本连接机制：过程调用、中断、I/O、DMA、事件、进程、线程、共享、同步、并/串行、并发， etc.

Chapter 6 —— 体系结构的一般描述

1.通用的一般的描述方法

（1）主程序与子程序

结构化思想和概念的提出后，主程序和子程序成为主要的程序设计思想。
这是软件设计最直接、最基本的结构关系。
更复杂的设计包含了库、包、模块、程序覆盖等概念。
主程序与子程序优点：
1. 是一切软件结构的最本质、最基础的形式
2. 代码的效率可以得到最大限度的发挥和提高。
主程序与子程序缺点：
1. 部件的连接关系不明显。 //简单的调用的背后实际上可能较为复杂。
2. 代码维护性差。//简单的调用关系为维护带来了困难。
3. 代码的复用性差。 //单纯的过程不能反映复杂的结构，难以成为复用的单元和基础。

（2）数据抽象和面向对象

数据抽象和面向对象设计是在主程序和子过程设计基础上建立和发展起来的重要的软件描述方法。
数据抽象是面向对象设计的理论基础
类和对象是该描述方法的基础粒度，而非模块或者包。
本质上没有逃出主子程序的思想
面向对象的优点
1. 信息隐藏保证了对象行为的可靠性，Called By Methods。
2. 受封装的独立运行对象把数据和操作捆绑在一起，提高了对象作为一种模块的内聚力，使系统更容易分解成相互作用又相互独立的对象集合。
3. 将操作请求和实现细节的分离使得可能在不影响调用者情况下改变操作的实现，为系统的维护和升级提供了良好的条件。
4. 继承性和封装性提高了复用的可能性和方便性。
面向对象的缺点
1. 对象之间方法的调用必须知道被调用者的标识，造成系统维护上的困难
2. 如果系统分析初期就使用面向对象的方法则可能大大加剧系统分析的复杂性

（3）层次结构

层次化是一种复杂系统设计的带普遍性的设计原则。
层次化设计来源于2个原因：
1. 事物总是从最简单的、带基础的层次开始发生的
2. 来自众多复杂软件设计的实践，几乎所有的系统都是从层次化结构建立起来的
层次结构的变种：松弛的层次结构、通过继承的层次结构
层次结构的实例：虚拟机JVM,API，IS（信息系统，DB是底层），Windows NT
层次结构的优点
1. 层次的复用性
2. 对标准化的支持，允许在不同层使用来自不同商家的产品
3. 依赖本地化，层次间的标准接口通常把代码变化的影响限制在其所在的层次之内，这样做便于支持系统的可移植性和可测试性
4. 可替换性，独立层次的实现能够被功能相同的模块替换。（例如，硬件的可替换性）享用互操作性好处的代价是增加了程序开销。
层次结构的缺点
1. 改变行为的连锁效应。例如，在维护升级时，必须在许多层次上做大量的工作。
2. 低效率。分层结构通常比单一层次的结构效率更低。例如，通信协议在从高层传送信息时需要增加信息头和尾。
3. 包含过多不必要的工作。如果低层次执行某些高层次并不需要的重复的工作，对于软件的整体性能就有消极的影响。高层请求通常会导致多次对低层次的同样的请求，层次数太多还会在层次间传送变量和返回值时带来额外的开销。

2.理论的形式化方法（体系结构的描述）

形式化的定义：用于计算机系统的形式化方法是描述系统性质的基于数学的技术
如果一个方法有良好的数学基础，那么它就是形式化的。
规约方法的目标：无二性、一致性、完整性

（1）体系结构描述语言

几种体系结构描述语言的提出组织和倡导者

ADL建立在形式化的理论基础之上
ADL的功能：能够描述体系结构的组成要素，并能对系统体系结构、体系结构风格进行建模和分析验证的描述语言。
ADL分类：
- 描述软件体系结构配置的ADL：CHAM
- 描述软件体系结构实例的ADL：Rapide
- 描述软件体系结构风格的ADL：Wright
ADL的目标：
1. 精确的语义描述
2. 支持分析推理

（2）类属理论

是一种表达对象关系的数学语言：
1. 提供了概念划分的统一性
  - 类属是由一个对象集合和一个关联两个对象的箭头集合构成的。
  - 对象是以某种逻辑表达的形式规范，箭头定义了这些规范之间的关系。
2. 软件研究者把他看成是表达抽象和依赖关系的工具
3. 在体系结构的部件和连接器描述中都被广泛采用
类属理论可以用于从小的、可重用的部件开始合成系统的形式规范。
当用于规范构造时，通常要求箭头（或形态）保持定理的推理关系。
如果定义了两个规范之间的形态，那么源规范的公理是目标规范的定理。
可以把体系结构定义为一个规范的图，并且在一个相对抽象的层面上证明该体系结构的性质。
可以应用类属理论的细化操作对体系结构的规范进行细化，直到实现。
该方法的一个优点在于结构特性的自动维持。

（3）Z Notation

Z Notation是牛津大学Programming Research Group研究的一种数学语言。
Z Notation使用标准的逻辑操作符和集合操作符以及他们标准的常规语义：
- 集合及其构造形式 + 集合操作符号 + 逻辑操作符号
使用Z Notation可以描述数学对象的模型。这些对象模型与程序计算对象的相似之处是选择Z作为体系结构和软件工程描述语言的原因。
在研究文献和报告中，大量的采用Z Notation作为体系结构的形式化描述。

（4）CSP（通信顺序进程）

CSP是由英国图灵奖获得者C.A.R Hoare于1978年提出的分布式程序设计原型“通信顺序进程”（Communication Sequential Process）
被广泛应用于分布式设计的建模和分析中
CSP提供丰富的描述进程行为的语义集。主要包括语义、实施、行为、组合、并发、通信等。
20世纪90年代，Robert Allen和David Garlan 将CSP用于描述软件体系结构，使用CSP的子集作为描述软件体系结构的语义模型基础。

（5）化学抽象机制ＣＨＡＭ

一个CHAM是从定义分子（molecules ） m、m1……和分子溶液（ solutions）s、s1……开始的。
分子构成了CHAM的基本元素，溶液是分子的聚合并被解释为CHAM的状态。
一个CHAM还包含转换规则T、T1……，他们定义了一个转换关系s->s1 ,指示了溶液可以发展（也就是状态变化）的方式。
借助于称为膜的封装结构，任何溶液可以被看成是相对于其他溶液的分子，转换可以被约束和局限在一个膜内。
被称为闭锁的可逆操作用来从溶液中选择提取分子，并把溶液的剩余部分放入一个膜内。膜是半渗透的，只允许特定的分子进入或离开膜。

３.软件体系结构集成环境

目标：

能够描述各种风格的软件系统结构
支持自顶向下（自下而上）的分层细化体系结构元素
确保接口一致
提供一个体系结构知识库存放与体系结构设计相关的设计模式、设计要素、设计需求
具有一个提供数据和控制模型代码的模板生成器
提供体系结构的图形化描述工具，从不同的视角反映体系结构

元素：

体系结构配置文档编辑器
体系结构配置图形编辑器
体系结构视图：文本视图、交互视图、层次视图
体系结构语法分析器
代码模板生成器

（1）UniCon

UnicCon

UnicCon（UNIversal CONnection）是Caregie Mellon 大学的Mary Shaw等人提出并研究的体系结构描述语言和环境。
UnicCon是基于部件和连接器的。即：体系结构的描述模型是由基于可识别的称为部件和连接器的个体元素构成的。
部件和连接器元素都具有类型、规范和实现。
系统支持的部件类型：
模块、计算、共享数据、顺序文件、过滤器、调度的进程、通用
系统支持的连接器类型
文件输入/输出、过程调用/数据访问、RPC、实时调度
体系结构的表达
支持体系结构的图形和文字的表达方式，两者之间可以互相转换。

（2）Wright

Wright体系结构描述语言用于描述软件系统的体系结构
可以描述体系结构的风格、系统族、体系结构实例和单个系统
提供对计算构件和连接件的描述
交互关系：
1. 系构件间的交互关系是指模块之间的通讯
2. Wright体系结构描述语言基于交互
Wright语言的描述：
1. 根据构件、连接件和配置等基本体系结构元素的抽象而构造系统
2. 构件作为计算部件，连接件形式化为交互模式

（3）Darwin

标识符、关键字和函数
1. 与IDL(Interface Description Language)的语法约定相同
2. 标识符：在Darwin系统中，用标识符定义和命名构件的类型、接口类型、参数、常量、端口、实例等。
3. 关键字
4. 函数：Darwin扩展了IDL以支持函数的调用
构件说明
1. 构件说明定义了可以创建一个或多个实例的构件类型。
2. 局部构件（Partial Component Declaration）：构件的类型可以从其他构件类型完全或者局部导出。
3. 通用构件
Darwin系统设计验证
1. Darwin系统的设计验证工具为设计人员提供了一种“What－If”的测试机制。
Darwin系统程序设计
1. 支持增量式开发
2. 工程文件.dw
3. .cc为程序文件
Darwin系统程序结构构造
1. 支持自底向上
2. 支持自顶向下
3. 支持合并构件
4. 支持分组构件

（4）ACME

ACME是Caregie Mellon大学1995年提出并研究的体系结构描述语言和环境
ACME将系统描述成通过连接器实现交互关系的部件的图
采用图形化编辑方式直接描述构件和连接件
ACME的核心概念
1. 部件
  - 是系统描述的基本组块，代表了系统计算的核心
  - 可以用来表达硬件或者软件
2. 连接器
  - 体系结构模型的一个重要特征是把交互看成是建模的概念。这与OO不同。
  - 通过显式的连接器的概念，为明确地表达系统的通信关系提供了机制。
ACME句法结构
Modeling a system with ACME中给出了完整的句法结构描述。

4. 软件工程设计方法与体系结构描述

在软件工程中，大量使用自然语言和多种符号。虽然对于分析、设计并结合复审提高了软件的质量，但系统规约中可能产生不一致性、二义性、不完整性等问题。
软件体系结构作为软件工程学科研究软件系统总体结构的一个重要分支而出现，采用自然语言和图形符号描述体系结构就不可避免的具有上述问题。
目前，对于体系结构的描述可以分成两类，但各有优缺点：
1. 把现有的图形化方法应用到体系结构设计中
2. 开发体系结构描述语言: 每种体系结构描述语言都以独立的形式存在，描述语法不同而且互不兼容，这给体系结构描述语言的推广带来了一定的困难。
软件工程设计方法与体系结构描述区别：
1. 软件工程设计方法是针对软件的工程实现所提出的一整套思想和概念，提出的各种模型虽然未提及SA，但也代表了对软件构成的一种视图，也属于SA的范畴。
2. 从描述软件构成结构上看，软件工程设计方法和SA描述的目标一致。软件工程设计强调的是功能和逻辑结构，而SA注重的是与运行和特性相关的结构，包括部件和连接器的规范、接口、规约、非功能特性等。

Chapter 7 —— 设计模式

体系结构的设计模式是构成负责软件的基础和常用单元，解决的是软件的底层或接近底层的结构问题。
自从1991年以来，模式的观念和理论逐渐成为面向对象领域中的热门的话题之一。
设计面向对象的软件比较困难：找对象、归类、定义接口与层次、建立对象间的关系：目的是当前行，对今后具有通用性
但一下子要做到好的设计，好的可复用的面向对象不是说不可能，至少更加的困难。
经验，重复
设计模式使人们可以更加简单方便地复用成功的设计和体系结构，帮助设计者更好更快地完成系统设计。

Others

1. 软件体系结构的“4+1”视图模型

Kruchten 提出了一个"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。

“4+1”视图模型

逻辑视图（logical view）：主要是用来描述系统的功能需求，即系统提供给最终用户的服务。在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（Class Diagram）来描述逻辑视图。

逻辑视图的构件和连接器
开发视图（development view）：主要用来描述软件模块的组织与管理（通过程序库或子系统）。服务于软件编程人员，方便后续的设计与实现。要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：Java SDK，图像处理软件包）。

开发视图的构件和连接器
过程视图（process view）：侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。

过程视图的构件和连接器
物理视图（Physical view）：主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。

物理视图的构件和连接器
场景（Scenaris）:场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。文本、图形表示皆可。

UML和各视图的对应关系

4+1视图	UML
场景视图	use case
逻辑视图	类图
开发视图	类图，组件图
进程视图	无完全对应
部署视图	部署图

2. 体系结构风格

通用体系结构风格表

Garlan和Shaw对通用体系结构风格进行如下分类：
（1）数据流风格：批处理序列、管道/过滤器等；
（2）调用/返回风格：主程序/子程序、面向对象风格、层次结等。
（3）独立构件风格：进程通讯、事件系统等；
（4）虚拟机风格：解释器、基于规则的系统等；
（5）数据中心风格：数据库系统、超文本系统、黑板系统等。
近年来，出现了许多新的体系结构风格，例如客户/服务器（Client /Server）结构、浏览器/服务器（Browser/Server）结构、正交（Orthogonal）结构、专用领域（Domain Specific Styles）、MVC、微核（Microkernel）、反射（ Reflection ）、代理（ Proxy ）等。

3. 一些面向对象的设计法则

（1）优先使用组合而非继承

组合的优点：
- 容器类仅能通过被包含对象的接口对其访问
- 相互依赖小
- 可以动态地定义对象集合
组合的缺点：
- 系统中对象过多
- 必须仔细对接口进行定义
继承的优点：
- 复用父类
- 容易修改
继承的缺点：
- 父类修改会影响子类
- 破坏了封装性

（2）针对接口编程而非实现

（3）开关原则（OCP）

对扩展开放，对修改关闭

（4）Liskov替换原则（LSP）

任何基类可以出现的地方，子类一定可以出现（子类可以替换父类）