软件体系结构

一、概述

软件危机（重）

主要表现

• 成本日益增长
• 开发进度难以控制
• 软件质量差
• 维护困难

产生原因

• 用户需求不明确
• 软件规模越来越大
• 软件复杂度越来越高

软件重用

在两次或多次开发的过程中，重复使用相同或相近的元素的过程

可重用的元素（重）

• 代码
• 设计文档
• 测试用例
• 需求分析文档
• 框架
• 设计过程
• 领域知识

构件（最小函数最大类）

• 语义完整、语法正确、有可重用价值的单位软件   
• 是软件重用过程中可明确辨识的系统
• 结构上是语义描述、通信接口和实现代码的复合体

构件模型（规模——越大越好？越小越好？）

青鸟模型：外部接口+内部接口

逻辑功能 类图

开发组件包图

进程问文章顺序序列活动

物理部署图

 构件获取

• 开发新的构件
• 购买
• 从历史遗留工程中提取
• 去构件库中查找需要的构件
• 由现有构件做适应性修改

可重用技术和领域之间的关系

领域具有内聚性和稳定性——前提
可重用信息具有领域特定性——约束

领域工程

构件管理（重）

对大量的构件进行有效的管理，方便构建的存储、检索和提取
构件的描述；名称、功能、参考函数、版本号等

人员及权限管理

公共用户 注册用户 构建提供者 一般系统管理员 超级系统管理员

软件项目的风险承担者

开发团队，项目经理，客户，组织管理层，合作伙伴等 

关键词法

• 浏览
• 关键字匹配

优点：简单易行
缺点：不便于查询

刻面法

• 构造查询
• 检索构件
• 排序

优点：方便查找相似构件
缺点：查询程序太难做

超文本法

• 一个或多个关键字匹配
• 返回相关文档
• 用户通过超链跳转浏览

优点：操作人性化
缺点：容易差跑题了

二、软件体系结构建模

软件体系结构的建立应位于需求分析之后，软件设计之前，在建立软件体系结构时，设计师主要从结构的角度对整个系统进行分析，选择恰当的构件、构件间的相互作用以及他们的约束，最后形成一个系统框架以满足用户的需求，为软件设计奠定基础。

每个软件系统都有多个风险承担者：最终用户、开发人员、系统工程师、项目经理等

2.1软件体系结构（重）

软件体系结构是具有一定形式的结构化元素即构件的集合，包括处理构件、数据构件和连
接构件。

软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。

软件体系结构的反作用

• 影响开发组织结构
• 影响开发组织目标
• 影响客户对下一个系统的要求
• 构建过程中丰富团队经验，影响后续设计
• 改变行业人员学习和实践的技术环境

 软件体系结构的商业周期

2.2  4+1模型视图

• 每个视图只关心系统的一个侧面，结合在一起才能反映系统的软件体系结构的全部内容
• 在每个视图上均独立地应Perry & Wolf 的公式，即定义一个所使用的元素集合（构件、容器、连接件）

逻辑视图（静态）

主要是整个系统的抽象结构表述
关注系统提供最终用户的功能
不涉及具体的编译即输出和部署
通常用BOOCH标记法，或在UML中用类图表示

开发视图（静态）

主要侧重软件模块的组织和管理，为编程人员服务
软件可以通过程序库或子程序进行组织，从而可以由不同的人员进行开发
主要考虑软件内部需求，要充分考虑软件开发的容易程度，重用性，软件的通用性，充分考虑由于具体开发工具不同而带来的局限性。

在UML中用组件图，包图表示

• 常用层次风格
• 采用4-6层子系统
• 仅进行相邻交互
• 层次越低，通用性应越强

进程视图（动态）

侧重系统的运行特性
关注非功能需求（性能、可用性、并发性）
定义逻辑视图中的各个类的操作是在哪一个线程中被执行
可以描述成多层抽象
每个级别分别关注不同的方面
最高层抽象中：进程结构＝构成一个执行单元的一组任务 | 独立、分布 | 通过逻辑网络相互通信

 举例

物理视图（动态）

如何把软件映射到硬件上
关注系统性能、规模、可靠性等

UML中可以用部署图表示

 举例

场景

重要系统活动的抽象
最重要的需求抽象
联系4个视图

 2.3软件体系结构的生命周期

需求分析阶段
体系结构需求包括需求获取、生成类图、对类分组、将类打包成构件和需求评审等过程。

建立软件体系结构阶段
选择合适的体系结构风格，把体系结构需求阶段已确认的构件映射到体系结构中，产生一个中间结构，分析构件之间的相互作用和关系，对中间结构进行细化。

设计阶段
主要是对系统进行模块化并决定描述各个构件间的详细接口、算法和数据类型的选定，对上支持建立体系结构阶段形成的框架，对下提供实现基础。

实现阶段
设计阶段设计的算法及数据类型进行程序语言表示，满足设计体系结构和需求分析的要求，从而得到满足设计需求的目标系统。

2.4软件体系结构设计核心模型

构件 端口 配置 连接件 角色

构件

构件定义：构件是一个数据单元或一个计算单元，它由构件的对象的集合、属性的集合、动作的集合和端口的集合组成。

抽象表示为C = （O,A,X,P），
O 是构件的所有对象的集合；
A 是构件属性的集合；
X 是构件动作的集合；
P 是构件端口的集合。

构件是具有某种功能的可重用的软件模版单元
从其内容角度看，表现为：计算元素、数据存储
从其形式角度看，表现为：原子构件、复合构件
构件的接口：一组端口

构件之间的关系

顺序结构（顺序运算）
选择结构（选择运算）
循环结构

 连接件
构件间的交互依据内容分类：
表现为：管道、过程调用、事件广播……
连接件的接口：一组角色

连接件是构件运算的实现，它是一个6元组
<ID,Role,Beha,Msgs,Cons,Non-Func>
其中，Role为连接件和构件的交互点的集合，它由一个四元组定义
Role=<Id,Action,Event,LConstrains>

配置

拓扑逻辑和约束

2.5软件体系结构

定义：设论域为U，
(1)构件是一个软件体系结构
(2)连接件是一个软件体系结构
(3)构件经有限次连接（运算）后是软件体系结构。
软件体系结构记为A=<C,O>,其中C表示组成体系结构的构件集合，O表示构件运算的集合

性质：

• 封闭性：即构件与构件、构件与体系结构、体系结构与体系结构连接后仍是一个体系结构。
• 层次性：即体系结构可由构件连接而成，而体系结构又可以再经过连接组成新的更大的体系结构。
• 可扩充性：即一个满足条件的新构件可以通过连接加入到结构中。

三、软件体系结构风格

什么决定了软件体系结构风格？控制原则、质量属性

• 控制原则    它描述了如何激发每一个构件来处理信息，以及如何在构件间传输数据。
•  质量属性    为解决特定问题所关注和满足的特定需求

3.1 经典风格

◎ 数据流风格：批处理序列；管道/过滤器。

◎ 调用/返回风格：主程序/子程序；面向对象风格；层次结构。

◎ 独立构件风格：进程通讯；事件系统。

◎ 虚拟机风格：解释器；基于规则的系统。

◎ 仓库风格：数据库系统；超文本系统；黑板系统。

3.2管道过滤器风格

优点：
构件间耦合关系降低，易于分解问题，实现重用
易于维护和扩展
为系统的运行分析提供便捷条件
支持并发计算

缺点：
不适合处理交互频繁的应用
数据解析、合成麻烦

扩展形式：管线、有界管道、批处理

 3.3数据抽象和面向对象系统

优点：

• 封装性、便于重用
• 可实现交互

缺点：

• 调用使得修改被传播

3.4事件驱动风格

事件：监听事件、声明事件

构成：事件消费者、事件生产者、事件管理器

基本结构：

• 事件监听接口和事件监听器
• 事件监听的注册和注销

特征：

• 是面向对象风格的变体
• 事件接触者不知道哪些构件会被这些事件影响
• 无法预知和假定构件的处理顺序

优点：

• 为重用提供支持
• 为系统改进提供方便

缺点：

• 弱化了对系统计算的控制能力
• 有数据共享的负担
• 系统逻辑关系复杂

 3.5分层系统

特点：

• 每个层次为上一层提供服务
• 它同时作为用户调用下层的功能
• 严格的分层
• 半透明的分层

优点：

• 支持基于抽象程度递增的系统设计
• 良好的扩展性
• 支持重用

缺点：

• 层次划分困难
• 适用性受限

3.6仓库系统及知识库

要素：
两类构件：中央数据单元+外部构件
控制策略：两类构件间的交互方式

分类：
传统数据库型（被动）
黑板系统（主动）

中央数据单元是系统的核心，存储数据和系统状态数据
知识源是相互独立的，通过黑板系统完成交互
控制单元是非独立单元

优点：
易于增加数据的生产者和消费者
良好的知识库扩展性
易于保证数据的同步、一致性

3.7C2（层次网络+消息驱动）

组织规则：
顶、底
构件不能直接相连
连接件之间自由连接
连接件的直接相连是有序的

工作方式：请求＋通知

特点：
基底独立性
构件只见交互只能通过消息传递实现
多线程

四、全局软件体系结构

4.1C/S结构

 C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。

服务器任务：
保证数据库安全性
控制数据库并发访问
确保数据的一致性
数据备份与恢复

客户端任务：
提供交互界面
提交请求，接收信息
对客户端数据执行应用逻辑要求 

4.2 三层C/S结构

 两层C/S的弊端：
软硬件的组合和集成能力有限，难以扩展至大型项目中
软硬件的组合及集成能力有限
客户机负荷过重
数据安全性不好

• 应用的各层可以并行开发，可以选择各自最适合的开发语言
• 利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。

表示层（用户接口部分）：
用户与应用间的对话
检查用户的输入和显示数据（只检查形式和取值范围）

功能层（应用本体）：
处理业务逻辑

数据层：
数据库的读写

4.3B/S风格

优势：

• 维护升级简单、高效
• 服务覆盖范围大

劣势：

• 应用服务器负荷重一数据处理和响应速度慢
• 安全控制能力弱
• 数据动态交互性不强

4.4CORBA（公共对象请求代理）

CORBA体系结构是对象管理组织（OMG）为解决分布式处理环境(DCE)中，硬件和软件系统的互连而提出的一种解决方案

ORB：carba展开工作的核心，是关键的通信机制，处理对象间的消息分布，是一种透明机制

主要任务：对象定位、对象激活、对象通讯

CORBA的主要构成要素

• ORB
• 接口定义语言（IDL）
• 接口池（IR）
• 动态调用接口（DII）
• 对象适配器（OA） 

接口定义语言：统一的描述服务器对象接口，不涉及对象的具体实现，面向对象语言

接口池：分布式计算环境中所有可用服务器对象的接口表示使得动态搜索接口和动态构造请求即参数成为可能

动态调用接口：提供标准函数供用户动态创建请求动态构造请求参数

对象适配器：屏蔽内部实现细节，为服务器提供抽象接口

特点：

• 引入中间件做事务代理
• 实现客户与服务对象的完全隔离
• 提供软总线机制
• 基于面向对象的开发

4.5正交体系结构

组成原则：

1. 线索可看成是子系统，它由完成不同层次功能的构件组成，同一线索上的构件相互间是一种调用关系，每一条线索完成整个系统中相对独立的一部分功能
2. 层是具有相同抽象级别的构件构成的
3. 每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的
4. 如果线索是相互独立的，即不同线索中的构件之间没有相互调用，那么这个结构就是完全正交的

 举例

优点：
结构清晰，易于理解
易修改，可维护性强
可移植性强，重用粒度大

 4.6层次消息总线（HMB）

HMB风格基于层次消息总线、支持构件的分布和并发，构件之间通过消息总线进行通信
消息总线是系统的连接件，负责消息的分派、传递、过滤及处理结果的返回

各个构件挂接在消息总线上，向总线登记感兴趣的消息类型；构件发送的消息由总线传送到其他构件，处理结果也由总线返回
不要求各个构件具有相同的地址空间或局限在同一台机器上，可较好地刻画分布式并发系统

HMB风格的构件模型包括接口、静态结构和动态行为

 静态结构要点：

• 自顶向下层次化分解
• 总线间无直接的连接

动态行为：

对系统演化的支持：

• 动态增删构件
• 动态改变构件响应的消息类型
• 支持消息过滤

 4.7异构风格

不同结构有不同的处理能力的优点和缺点，系统应根据实际需要来选择，以解决实际问题

C/S与B/S混合之内外有别模型

 

优点：外部用户不直接访问数据库服务器，能保证企业数据库的相对安全。企业内部用户的交互性较强，数据查询和修改的响应速度较快；

缺点：企业外部用户修改和维护数据时，速度较慢，较烦琐，数据的动态交互性不强。 

C/S与B/S混合之查改有别模型 

体现了B/S体系结构和C/S体系结构的共同优点。但因为外部用户能直接通过Internet连接到数据库服务器，企业数据容易暴露给外部用户，给数据安全造成了一定的威胁。

示例：

 4.8互联系统构成的系统

系统是总分结构，可分成若干部分，每个部分作为单独的系统开发；整个系统通过一组互连系统实现，互连系统之间相互通信，履行
上级系统(superordinate system)：体现整体性能
从属系统(subordinate system)：子系统，上级系统模型中所指定内容的一个实现

 关键点
上级系统独立于其从属系统，每个从属系统仅仅是上级系统模型中所指定内容的一个实现，并不属于上级系统功能约束的一部分

4.9面向服务的架构（SOA）

SOA架构把应用功能部件封装成为独立的服务，与平台、操作系统、应用的编写语言、地域无关，可以在多个不同的应用系统中重用。 

SOA解决的两大目标是：系统整合和随需应变，

 

4.10特定领域软件体系结构DSSA

DSSA就是专用于一类特定类型的任务（领域）的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合

目标就是支持在一个特定领域中多个应用的生成

要点： 严格定义的问题域和/或解决域

• 垂直域
• 水平域 

具有普遍性，使其可用于领域中某特定应用的开发

对整个领域的适合程度的抽象

具有该领域固定的、典型的，在开发过程中可重用的元素

五、软件体系结构描述

5.1软件体系结构描述方法

• 图形表达工具
• 模块内连接语言ML
• 基于软构件的系统描述语言PCL
• 软件体系结构描述语言ADL

非形式化方法主要缺点：

• 语义模糊
• 无法实现系统验证
• 不适于描述体系结构行为 

5.2软件体系结构描述框架标准

5.3软件体系结构描述语言

ADL 是一种用于描述软件系统结构的计算机语言，支持求精、验证、分析

• 构造能力：ADL能够使用较小的独立体系结构元素来建造大型软件系统；
•  抽象能力：ADL使得软件体系结构中的构件和连接件描述可以只关注它们的抽象特性，而不管其具体的实现细节；
• 重用能力：ADL使得组成软件系统的构件、连接件甚至是软件体系结构都成为软件系统开发和设计的可重用部件；
• 组合能力：ADL使得其描述的每一系统元素都有其自己的局部结构，这种描述局部结构的特点使得ADL支持软件系统的动态变化组合；
• 异构能力：ADL允许多个不同的体系结构描述关联存在；
• 分析和推理能力：ADL允许对其描述的体系结构进行多种不同的性能和功能上的多种推理分析

 Unicon

提供对大量构件和连接件的统一访问

六、基于体系结构的软件开发

6.1设计模式

软件模式(Software Patterns)是将模式的一般概念应用于软件开发领域即软件开发的总体指导思路或参照样板

6.2基于体系结构的软件设计方法（ABSD）

设计元素
ABSD是一个递归的方法，体系结构通过该方法得到细化直到产生构件和类

 

视角和视图
考虑体系结构时，重要的是从不同的视角来检查，促使设计师考虑体系结构不同的属性
视图与4+1模型视图类似

用例和质量属性
在使用用例捕获动能需求的同时，通过特定场景来捕获质量需求，这些场景称为质量场景
质量场景必须包括预期的刺激和非预期的刺激

ABSD的生命周期

ABSD方法的输入：
抽象功能需求，包括变化的需求和通用的需求
用例
质量因素
约束

设计元素的产生顺序

广度遍历
深度遍历

设计元素的活动

逻辑视图、并发视图、配置视图都可以开始

注意：
注重领域知识
新技术的融合
个人经验

反馈环用于保证各种视图都在考虑的范围之内

逻辑视图

创建并发视图

 

创建配置视图

6.3体系结构的设计与演化

设计

 演化

七、软件体系结构评估

7.1软件体系结构评估概述

质量属性

• 性能（*）：系统的响应能力

• 可靠性（*）

  • 容错性：发成错误行为时进行内部修复

  • 健壮性：保护程序不受错误输入和错误使用的影响

• 可用性（*）

• 安全性（*）

• 可修改性（*）：能够快速地以较高的性能价格比对系统进行变更的能力

  • 可维护性：在错误发生后“修复”软件系统，对其他构件的负面影响最小化

  • 可扩展性：使用新特性扩展软件系统，使用改进版本替换构件并删除不需要或不必要的特性和构件

  • 结构重组：重新组织软件系统的构件及构件间的关系

  • 可移植性：使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器

• 功能性

• 可变性：体系结构经扩充或变更而成为新体系结构的能力

• 集成性

• 互操作性

 基本概念

• 敏感点：体系结构决策采用不同的性能属性,同时这些属性在风险评估中是一些关键性的因素,当进行评价时,它们是体系结构的敏感点，一个或多个构件，或构件之间的关系的特性
• 权衡点：(加密级别-安全性、性能)是影响多个质量属性的特性，是多个质量属性的敏感点
• 风险承担者：在项目管理领域中指“项目干系人”或“涉众”
• 场景：
  要进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制叫做“场景”，场景用刺激、环境和响应进行描述

7.2软件体系结构的主要评估方式

基于场景的评估方式涉及的基本活动包括确定应用领域的功能和软件体系结构之间的映射，设计用于体现待评估质量属性的场景以及分析软件体系结构对场景的支持程度。

度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用的层数、构件个数等。

 7.3SAAM评估步骤

形成场景

描述体系结构

对场景进行分类和确定优先级

直接场景：体系结构可直接支持该场景，不需要修改
间接场景：必须对体系结构进行一些修改，如：增加构件、删除构件、修改接口等

确定优先级还是投票，可参考ATAM的投票方式

对间接场景的单个评估

对于直接场景，体系结构设计师需要讲清所评估的体系结构如何执行这些场景
对于间接场景，体系结构设计师应说明需要对体系结构进行什么修改

对于间接场景，预估修改、涉及到的构件数量和工作量

评估场景的相互作用

当两个或多个间接场景要求更改体系结构的一个构件的时候，就称这些场景在一组构件上相互作用

场景的相互作用暴露了功能分配

语义上不相关的场景相互作用可能说明是功能分离的不够好

形成总体评估

将场景和业务目标联系起来，评价是否达到标准

7.4基于场景的评估方式（ATAM）

ATAM不但揭示了体系结构如何满足特定的质量目标，而且提供了这些质量目标如何交互，即他们之间是如何权衡的

6个步骤不是瀑布过程，中途可以跳转迭代

描述ATAM方法

向风险承担者介绍评估方法
介绍ATAM方法步骤简介
介绍获取分析技术
介绍评估结果

描述业务动机

产品经理要使参会人员理解待评估系统
包括系统的功能需求、约束条件、目标环境和体系结构的驱动因素

描述体系结构

设计师对体系结构进行相对应的描述
内容包括技术约束、与本系统交互的其他系统、用以满足质量要求的软件结构方法

确定体系结构方法

设计师通过理解体系结构方法来确定体系结构

生成质量属性效用树

分析体系结构描述方法

通过效用树对体系结构的方法进行考察

讨论和分级场景

集体讨论用例场景和改变场景（成长场景、考察场景）
成长场景：体系结构中短期的改变
考察场景：体系结构根本性改变

分析体系结构方法

每人30%场景数量的票数进行投票

对比得票数最高的场景和效用树中优先级最高的节点、对存在的差异进行调整和解释

得到对每个场景影响最大的质量属性

描述评估结果

文档化的体系结构方法
场景及其优先级
基于属性的问题
效用树
风险决策
文档化的无风险决策
敏感点和权衡点