前言
按照惯例，在这里写下我对软件体系结构的一点理解和认识
软件工程是一门研究利用工程化的方法，构建维护有效的实用的高质量的软件的学科，东北林业大学软件工程专业核心课，就是按照软件生命周期的课来安排的，将每一个生命周期中的过程都抽象成一门课来给学生讲解，软件体系结构这门课是继需求分析和系统分析之后的一门课
需求分析教会了我们如何进行需求获取、需求分析和需求验证，最后形成需求规格说明书，系统分析教会了我们如何抽象出合理的类图，而软件体系结构讲的是如何把类抽象成构件以及如何合理的安排这些构件（或者类）
概述
软件重用
在两次或多次开发的过程中，重复使用相同或相近的元素的过程
可重用的元素
- 代码
- 设计文档
- 测试用例
- 需求分析文档
- 框架
- 设计过程
- 领域知识
构件
- 语义完整、语法正确、有可重用价值的单位软件
- 是软件重用过程中可明确辨识的系统
- 结构上是语义描述、通信接口和实现代码的复合体
构件模型（规模——越大越好？越小越好？）
青鸟模型：外部接口+内部接口
构件获取
- 开发新的构件
- 购买
- 从历史遗留工程中提取
- 去构件库中查找需要的构件
- 由现有构件做适应性修改
可重用技术和领域之间的关系
领域具有内聚性和稳定性——前提
可重用信息具有领域特定性——约束
构件管理
对大量的构件进行有效的管理，方便构建的存储、检索和提取
构件的描述；名称、功能、参考函数、版本号等
关键词法
优点：简单易行
缺点：不便于查询
刻面法
优点：方便查找相似构件
缺点：查询程序太难做
超文本法
优点：操作人性化
缺点：容易差跑题了
软件体系结构
软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
软件体系结构的反作用
- 影响开发组织结构
- 影响开发组织目标
- 影响客户对下一个系统的要求
- 构建过程中丰富团队经验，影响后续设计
- 改变行业人员学习和实践的技术环境
软件体系结构的商业周期
软件体系结构建模
软件体系结构的建立应位于需求分析之后，软件设计之前，在建立软件体系结构时，设计师主要从结构的角度对整个系统进行分析，选择恰当的构件、构件间的相互作用以及他们的约束，最后形成一个系统框架以满足用户的需求，为软件设计奠定基础。
4+1模型视图
每个视图只关心系统的一个侧面，结合在一起才能反映系统的软件体系结构的全部内容
在每个视图上均独立地应Perry & Wolf 的公式，即定义一个所使用的元素集合（构件、容器、连接件）
逻辑视图（静态）
主要是整个系统的抽象结构表述
关注系统提供最终用户的功能
不涉及具体的编译即输出和部署
通常用BOOCH标记法，或在UML中用类图表示
开发视图（静态）
主要侧重软件模块的组织和管理，为编程人员服务
软件可以通过程序库或子程序进行组织，从而可以由不同的人员进行开发
主要考虑软件内部需求，要充分考虑软件开发的容易程度，重用性，软件的通用性，充分考虑由于具体开发工具不同而带来的局限性。
- 常用层次风格
- 采用4-6层子系统
- 仅进行相邻交互
- 层次越低，通用性应越强
进程视图（动态）
侧重系统的运行特性
关注非功能需求（性能、可用性、并发性）
定义逻辑视图中的各个类的操作是在哪一个线程中被执行
可以描述成多层抽象
每个级别分别关注不同的方面
最高层抽象中：进程结构＝构成一个执行单元的一组任务 | 独立、分布 | 通过逻辑网络相互通信
物理视图（动态）
如何把软件映射到硬件上
关注系统性能、规模、可靠性等
场景
重要系统活动的抽象
最重要的需求抽象
联系4个视图
软件体系结构的生命周期
需求分析阶段
体系结构需求包括需求获取、生成类图、对类分组、将类打包成构件和需求评审等过程。
建立软件体系结构阶段
选择合适的体系结构风格，把体系结构需求阶段已确认的构件映射到体系结构中，产生一个中间结构，分析构件之间的相互作用和关系，对中间结构进行细化。
设计阶段
主要是对系统进行模块化并决定描述各个构件间的详细接口、算法和数据类型的选定，对上支持建立体系结构阶段形成的框架，对下提供实现基础。
实现阶段
设计阶段设计的算法及数据类型进行程序语言表示，满足设计体系结构和需求分析的要求，从而得到满足设计需求的目标系统。
软件体系结构设计核心模型
构件
构件定义：构件是一个数据单元或一个计算单元，它由构件的对象的集合、属性的集合、动作的集合和端口的集合组成。
抽象表示为C = （O,A,X,P），
O 是构件的所有对象的集合；
A 是构件属性的集合；
X 是构件动作的集合；
P 是构件端口的集合。
构件是具有某种功能的可重用的软件模版单元
从其内容角度看，表现为：计算元素、数据存储
从其形式角度看，表现为：原子构件、复合构件
构件的接口：一组端口
构件之间的关系
顺序结构（顺序运算）
选择结构（选择运算）
循环结构
顺序运算定理：
连接件
构件间的交互依据内容分类：
表现为：管道、过程调用、事件广播……
连接件的接口：一组角色
连接件是构件运算的实现，它是一个6元组
<ID,Role,Beha,Msgs,Cons,Non-Func>
其中，Role为连接件和构件的交互点的集合，它由一个四元组定义
Role=<Id,Action,Event,LConstrains>
配置
拓扑逻辑和约束
软件体系结构
定义：设论域为U，
(1)构件是一个软件体系结构
(2)连接件是一个软件体系结构
(3)构件经有限次连接（运算）后是软件体系结构。
软件体系结构记为A=<C,O>,其中C表示组成体系结构的构件集合，O表示构件运算的集合
性质：
- 封闭性：即构件与构件、构件与体系结构、体系结构与体系结构连接后仍是一个体系结构。
- 层次性：即体系结构可由构件连接而成，而体系结构又可以再经过连接组成新的更大的体系结构。
- 可扩充性：即一个满足条件的新构件可以通过连接加入到结构中。
软件体系结构风格
什么决定了软件体系结构风格？控制原则、质量属性
管道过滤器风格
优点：
构件间耦合关系降低，易于分解问题，实现重用
易于维护和扩展
为系统的运行分析提供便捷条件
支持并发计算
缺点：
不适合处理交互频繁的应用
数据解析、合成麻烦
扩展形式：管线、有界管道、批处理
数据抽象和面向对象组织
优点：
封装性、便于重用
可实现交互
缺点：
调用使得修改被传播
事件驱动风格
事件：监听事件、声明事件
构成：事件消费者、事件生产者、事件管理器
基本结构：
事件监听接口和事件监听器
事件监听的注册和注销
特征：
是面向对象风格的变体
事件接触者不知道哪些构件会被这些事件影响
无法预知和假定构件的处理顺序
优点：
为重用提供支持
为系统改进提供方便
缺点：
弱化了对系统计算的控制能力
有数据共享的负担
系统逻辑关系复杂
分层系统
每个层次为上一层提供服务
它同时作为用户调用下层的功能
严格的分层
半透明的分层
优点：
支持基于抽象程度递增的系统设计
良好的扩展性
支持重用
缺点：
层次划分困难
适用性受限
仓库系统及知识库
要素：
两类构件：中央数据单元+外部构件
控制策略：两类构件间的交互方式
分类：
传统数据库型（被动）
黑板系统（主动）
黑板系统
中央数据单元是系统的核心，存储数据和系统状态数据
知识源是相互独立的，通过黑板系统完成交互
控制单元是非独立单元
优点：
易于增加数据的生产者和消费者
良好的知识库扩展性
易于保证数据的同步、一致性
C2（层次网络+消息驱动）
组织规则：
顶、底
构件不能直接相连
连接件之间自由连接
连接件的直接相连是有序的
工作方式：请求＋通知
特点：
基底独立性
构件只见交互只能通过消息传递实现
多线程
全局软件体系结构
C/S结构
服务器任务：
保证数据库安全性
控制数据库并发访问
确保数据的一致性
数据备份与恢复
客户端任务：
提供交互界面
提交请求，接收信息
对客户端数据执行应用逻辑要求
三层C/S结构
两层C/S的弊端：
软硬件的组合和集成能力有限，难以扩展至大型项目中
软硬件的组合及集成能力有限
客户机负荷过重
数据安全性不好
表示层（用户接口部分）：
用户与应用间的对话
检查用户的输入和显示数据（只检查形式和取值范围）
功能层（应用本体）：
处理业务逻辑
数据层：
数据库的读写
优点：
在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性
允许更灵活有效地选用相应的平台和硬件系统，在处理负荷能力上与处理特性上分别适应于结构清晰的三层
应用的各层可以并行开发，可以选择各自最适合的开发语言
利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层
关键问题：
三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能
设计时必须慎重考虑三层间的通信方法、通信频度及数据量
CORBA（公共对象请求代理）
CORBA体系结构是对象管理组织（OMG）为解决分布式处理环境(DCE)中，硬件和软件系统的互连而提出的一种解决方案
ORB：carba展开工作的核心，是关键的通信机制，处理对象间的消息分布，是一种透明机制
主要任务：对象定位、对象激活、对象通讯
接口定义语言：统一的描述服务器对象接口，不涉及对象的具体实现，面向对象语言
接口池：分布式计算环境中所有可用服务器对象的接口表示
使得动态搜索接口和动态构造请求即参数成为可能
动态调用接口：提供标准函数供用户动态创建请求动态构造请求参数
对象适配器：屏蔽内部实现细节，为服务器提供抽象接口
特点：
引入中间件作为事务代理，完成客户机向服务对象方提出的业务请求
实现客户与服务对象的完全分开，客户不需要了解服务对象的实现过程以及具体位置
提供软总线机制，使得在任何环境下、采用任何语言开发的软件只要符合接口规范的定义，均能够集成到分布式系统中
CORBA规范软件系统采用面向对象的软件实现方法开发应用系统，实现对象内部细节的完整封装，保留对象方法的对外接口定义
正交体系结构
组成原则：
1 线索可看成是子系统，它由完成不同层次功能的构件组成，同一线索上的构件相互间是一种调用关系，每一条线索完成整个系统中相对独立的一部分功能
2 层是具有相同抽象级别的构件构成的
3 每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的
4 如果线索是相互独立的，即不同线索中的构件之间没有相互调用，那么这个结构就是完全正交的
三层线索 五层结构
优点：
结构清晰，易于理解
易修改，可维护性强
可移植性强，重用粒度大
层次消息总线（HMB）
HMB风格基于层次消息总线、支持构件的分布和并发，构件之间通过消息总线进行通信
消息总线是系统的连接件，负责消息的分派、传递、过滤及处理结果的返回
各个构件挂接在消息总线上，向总线登记感兴趣的消息类型；构件发送的消息由总线传送到其他构件，处理结果也由总线返回
不要求各个构件具有相同的地址空间或局限在同一台机器上，可较好地刻画分布式并发系统
在对系统持续可用性要求较高时，需要在不必对软件进行重新编译和加载的前提下，为最终用户提供系统定制和扩展的能力
动态删除和增加构件：
系统功能需要扩充时，增加新的构件，只需登记消息响应
系统功能裁减或某构件出现问题时，删除构件，需阻塞一些消息
用增强功能或改正错误的新构件替换旧构件
动态改变构件响应的消息类型：
构件可以动态地改变对外提供的服务
消息过滤：
通过消息过滤机制，解决某些构件集成的不匹配问题
HMB风格的构件模型包括接口、静态结构和动态行为
接口
HMB风格的构件接口是一种基于消息的互联接口，可以较好地支持体系结构设计。构件之间通过消息进行通讯，接口定义了构件发出和接收的消息集合
HMB有两个显著的特点：
一是降低构件之间的耦合：构件只对消息本身感兴趣，不关心消息如何产生；切断构件之间的直接联系
二是构件对外来消息进行响应后，可能导致状态的变迁；同一构件在不同状态下收到同样消息可能作出不同的响应
当某个事件发生后，系统或构件发出相应的消息，消息总线负责把该消息传递到此消息感兴趣的构件
按照响应方式的不同，消息可分为同步消息和异步消息
互补端口（通过消息总线进行通信）：除消息进出构件的方向不同外，消息的名称、参数、返回结果类型完全相同的两个端口
消息总线
消息登记：构件需要向总线登记响应的消息集合
消息分派和传递：总线负责消息的分派、传递，并负责处理结果的返回；总线是逻辑上整体，物理上可跨越多个机器(位置透明)
消息过滤：总线提供消息的转换和阻塞
构件静态结构
HMB风格支持自顶向下的层次化分解，复合构件由简单子构件构成；
子构件通过复合构件内部的消息总线连接，各层次的消息总线在逻辑功能上一致；
子构件还可进一步再分，整个系统用统一的方式描述。
构件的动态行为
构件的行为就由外来消息的类型唯一确定，即一个消息和构件的某个操作之间存在着固定的对应关系
更通常的情况是，构件的行为同时受外来消息类型和自身当前所处状态的影响
可用有限状态自动机来描述
异构结构风格
不同结构有不同的处理能力的优点和缺点，系统应根据实际需要来选择，以解决实际问题
内外有别
优点：外部用户不直接访问数据库服务器，能保证企业数据库的相对安全。企业内部用户的交互性较强，数据查询和修改的响应速度较快
缺点：企业外部用户修改和维护数据时，速度较慢，较烦琐，数据的动态交互性不强
查改有别
凡是维护和修改都是c/s结构，凡是查询都是b/s结构
体现了B/S体系结构和C/S体系结构的共同优点。但因为外部用户能直接通过Internet连接到数据库服务器，企业数据容易暴露给外部用户，给数据安全造成了一定的威胁
互联系统构成的系统
系统是总分结构，可分成若干部分，每个部分作为单独的系统开发；整个系统通过一组互连系统实现，互连系统之间相互通信，履行
上级系统(superordinate system)：体现整体性能
从属系统(subordinate system)：子系统，上级系统模型中所指定内容的一个实现
关键点
上级系统独立于其从属系统，每个从属系统仅仅是上级系统模型中所指定内容的一个实现，并不属于上级系统功能约束的一部分
软件体系结构评估
软件体系结构的质量属性
性能（*）
系统的响应能力
可靠性（*）
容错性：发成错误行为时进行内部修复
健壮性：保护程序不受错误输入和错误使用的影响
可用性（*）
系统能够正常运行的时间的比例
安全性（*）
系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图和拒绝服务的能力
可修改性（*）
能够快速地以较高的性能价格比对系统进行变更的能力
可维护性：在错误发生后“修复”软件系统，对其他构件的负面影响最小化
可扩展性：使用新特性扩展软件系统，使用改进版本替换构件并删除不需要或不必要的特性和构件
结构重组：重新组织软件系统的构件及构件间的关系
可移植性：使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器
功能性
系统所能完成所期望的工作的能力
可变性
体系结构经扩充或变更而成为新体系结构的能力
集成性
系统能与其他系统协作的程度
互操作性
作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用
基本概念
敏感点：体系结构决策采用不同的性能属性,同时这些属性在风险评估中是一些关键性的因素,当进行评价时,它们是体系结构的敏感点，一个或多个构件，或构件之间的关系的特性
权衡点：(加密级别-安全性、性能)是影响多个质量属性的特性，是多个质量属性的敏感点
风险承担者：
在项目管理领域中指“项目干系人”或“涉众”
场景：
要进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制叫做“场景”
场景用刺激、环境和响应进行描述
刺激：场景中解释或描述风险承担者怎样姻法与系统的交互部分
环境：描述刺激发生时的情况
响应：系统如何通过体系结构对刺激做出反应
基于场景的评估方式（ATAM）
ATAM不但揭示了体系结构如何满足特定的质量目标，而且提供了这些质量目标如何交互，即他们之间是如何权衡的
6个步骤不是瀑布过程，中途可以跳转迭代
描述ATAM方法
向风险承担者介绍评估方法
介绍ATAM方法步骤简介
介绍获取分析技术
介绍评估结果
描述业务动机
产品经理要使参会人员理解待评估系统
包括系统的功能需求、约束条件、目标环境和体系结构的驱动因素
描述体系结构
设计师对体系结构进行相对应的描述
内容包括技术约束、与本系统交互的其他系统、用以满足质量要求的软件结构方法
确定体系结构方法
设计师通过理解体系结构方法来确定体系结构
生成质量属性效用树
分析体系结构描述方法
通过效用树对体系结构的方法进行考察
讨论和分级场景
集体讨论用例场景和改变场景（成长场景、考察场景）
成长场景：体系结构中短期的改变
考察场景：体系结构根本性改变
分析体系结构方法
每人30%场景数量的票数进行投票
对比得票数最高的场景和效用树中优先级最高的节点、对存在的差异进行调整和解释
得到对每个场景影响最大的质量属性
描述评估结果
文档化的体系结构方法
场景及其优先级
基于属性的问题
效用树
风险决策
文档化的无风险决策
敏感点和权衡点
基于度量的评估方式（SAAM）
形成场景
描述体系结构
对场景进行分类和确定优先级
直接场景：体系结构可直接支持该场景，不需要修改
间接场景：必须对体系结构进行一些修改，如：增加构件、删除构件、修改接口等
确定优先级还是投票，可参考ATAM的投票方式
对间接场景的单个评估
对于直接场景，体系结构设计师需要讲清所评估的体系结构如何执行这些场景
对于间接场景，体系结构设计师应说明需要对体系结构进行什么修改
对于间接场景，预估修改、涉及到的构件数量和工作量
评估场景的相互作用
当两个或多个间接场景要求更改体系结构的一个构件的时候，就称这些场景在一组构件上相互作用
场景的相互作用暴露了功能分配
语义上不相关的场景相互作用可能说明是功能分离的不够好
形成总体评估
将场景和业务目标联系起来，评价是否达到标准
基于体系结构的软件设计方法（ABSD）
设计元素
ABSD是一个递归的方法，体系结构通过该方法得到细化直到产生构件和类
视角和视图
考虑体系结构时，重要的是从不同的视角来检查，促使设计师考虑体系结构不同的属性
视图与4+1模型视图类似
用例和质量属性
在使用用例捕获动能需求的同时，通过特定场景来捕获质量需求，这些场景称为质量场景
质量场景必须包括预期的刺激和非预期的刺激
ABSD的生命周期
ABSD方法的输入：
抽象功能需求，包括变化的需求和通用的需求
用例
质量因素
约束
ABSD方法定义的设计元素
按照下图进行分解，一个实际构件反映了一个软件元素（类）
设计元素的产生顺序
广度遍历
深度遍历
设计元素的活动
逻辑视图、并发视图、配置视图都可以开始
注意：
注重领域知识
新技术的融合
个人经验
反馈环用于保证各种视图都在考虑的范围之内
逻辑视图
创建并发视图
创建配置视图
基于体系结构的软件开发模型
体系结构需求
体系结构设计
体系结构文档化
体系结构需求规格说明
测试体系结构需求的质量设计说明书
体系结构复审
外部人员参加复审（没参与设计的）
识别潜在风险，发现设计的错误
体系结构实现
体系结构演化
