1. 概述
1.1 软件架构(SA)
- 概念
- Software Architecture
- 指系统的一个或者多个结构,结构中包括:
- 软件的构件
- 构件的外部可见属性
- 构件的相互关系
- 意义:
- 分析设计对需求的有效性
- 在设计变更相对容易的阶段,考虑体系结构可能的选择方案
- 降低与软件构造相关联的风险
1.2 软件架构设计(SAD)
- Software Architecture Design
- 作用:是构建软件的初始蓝图
- 架构设计考虑的两个层次
- 数据设计
- 体系结构设计
- 关注点:软件构件的结构、属性、交互作用
2. 软件架构设计与生命周期
2.1 需求分析阶段
教材中本节没有说“需求分析阶段”的事情,只说了需求模型向SA模型转换的问题,这应该是设计阶段的工作,因此将在设计阶段说明
2.2 设计阶段
- 目的:设计软件架构模型
- 包括: S A 模型的描述、 S A模型的设计与分析方法、对 S A 设计经验的总结与复用等
2.2.1 需求模型向SA模型的转换
- 主要关注两个问题:
- 如何转换(如何根据需求模型构建S A模型)
- 如何追踪(保证模型转换的可追踪性)
- Use Case 图向SA 模型转换
- 转换:经过词法分析、经验规则来完成
- 可追踪性:通过表格或 Use Case Map维护
2.2.3 SA模型描述的研究
有关S A模型描述的研究分为3个层次:
1)SA的基本概念
- 研究内容:
- SA模型的元素组成
- 组成元素之间的组织原则
- S A描述方法:构件和连接子的建模
连接子:随着软件架构研究的深入,构件间的互联机制逐渐独立出来,成为与构件同等级别的实体,称为连接子
2)体系结构描述语言(ADL)
- 概述:
- Architecture Description Language
- 支持构件、连接子及其配置的描述语言
ADL 对连接子的重视成为区分 ADL和其他建模语言的重要特征之一
- 典型的 ADL:UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL和 ABC/ADL等
3)SA模型的多视图表示
- 概述:
- 从不同的视角描述特定系统的体系结构
- 从而得到多个视图
- 将这些视图组织起来以描述整体的SA模型
- 体现了关注点分离的思想
- 多视图方案:
- 4+1模型:逻辑视图、进程视图、开发视图、物理视图、统一的场景
- Hofmesiter的4视图模型(了解即可):概念视图、模块视图、执行视图和代码视图
- Views and Beyond模型(了解即可):模块视图、构件、连接子视图、分配视图
- 和ADL的结合
- 优点
- 使系统更易于理解
- 方便系统相关人员之间进行交流
- 有利于系统的一致性检测
- 有利于系统质量属性的评估
- 多视图描述S A模型的标准:
- 统一建模语言 (UML)
- IEEE标准1471-2000(软件密集型系统体系结构描述推荐实践)
- 开放分布式处理参考模型 (RM-ODP)
- IBM的Zachman框架等。
- 优点
2.3 实现阶段
2.3.1 实现阶段的SA研究
- 研究基于SA的开发过程支持
如项目组织结构、配置管理等。
- 寻求从 SA 向实现过渡的途径
如将程序设计语言元素引入S A阶段、模型映射、构件组装、复用中间件平台等。
- 研究基于 SA 的测试技术
2.3.2 配置管理
使用配置管理的原因:
对于大型软件系统而言,由于参与实现的人员较多,所以需要提供适当的配置管理手段。
- SA的配置管理:
- 引入能够有效扩充现有配置管理的能力
- 引入版本、可选择项 (Options)等信息
- 行为:分析和记录不同版本构件和连接子之间的演化,从而可用来组织配置管理的相关活动
2.3.3 高层SA模型和底层实现之间的差距
- 缩小差距的手段:封装底层的实现细节、模型转换、精化
- 典型方法:
- 在S A 模型中引入实现阶段的概念(如引入程序设计语言元素等)
- 通过模型转换技术,将高层的S A模型逐步精化成能够支持实现的模型
- 通过构件组装的方式
- 封装底层的实现细节,使之成为较大粒度构件
- 在S A指导下通过构件组装的方式实现系统
- 往往需要底层中间件平台的支持
2.4 构件组装阶段
2.4.1 研究内容
- 如何支持可复用构件的互联
即对 S A设计模型中规约的连接子的实现提供支持。
- 如何检测并消除体系结构失配问题
2.4.2 ADL对连接子的支持
- 将连接子转换为具体的程序代码或系统实现的语言
如 UniCon定义了Pipe、FileIO、ProcedureCall 等
- 支持从S A模型生成代码的体系结构描述语言
如 C2SADL、Rapide等,也都提供了一定的机制以生成连接子的代码。
2.4.3 中间件支持的连接子
- 中间件的作用:遵循特定的构件标准,为构件互联提供支持,并提供相应的公共服务
如安全服务、命名服务等
- 中间件对连接子的作用:
-
提供了构件间跨平台交互能力,且遵循特定的工业标准
如CORBA、J2EE、COM等
-
提供强大的公共服务能力,更好地保证最终系统的质量属性
-
- 中间件的选择:设计阶段连接子的规约
- 中间件导向的体系结构风格 (Middleware-Induced Architectural Style)
2.4.4 检测并消除体系结构失配
-
概念:
- 在软件复用的过程中,由于待复用构件对最终系统的体系结构和环境的假设 (Assumption)与实际状况不同而导致的冲突
-
失配的原因:
- 由构件引起的失配
由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配
- 由连接子引起的失配
包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配
- 由于系统成分对全局体系结构的假设存在冲突引起的失配
- 由构件引起的失配
-
失配的解决(
教材说了又仿佛没说
)- 检测出失配问题
- 通过适当的手段消除失配问题。
2.5 部署阶段
- SA 对软件部署作用:
- 提供体系结构视图来描述部署阶段的软硬件模型
- 基于SA模型可以分析部署方案的质量属性,从而选择合理的部署方案。
- 部署需要考虑的问题:待部署软件构件的互联性、硬件的拓扑结构、硬件资源占用等
2.6 后开发阶段
- S A 研究主要围绕维护、演化、复用等方面来进行
- 典型的研究方向包括动态软件体系结构、体系结构恢复与重建等:
2.6.1 动态软件体系结构
传统的S A研究设想体系结构总是静态的,即软件的体系结构一旦建立,就不会在运行时刻发生变动。但人们在实践中发现,现实中的软件往往具有动态性,即它们的体系结构会在运行时发生改变。
1)软件架构的变化
SA在运行时发生的变化包括两类
- 软件内部执行所导致的体系结构改变。
举例:
- 很多服务器端软件会在客户请求到达时创建新的构件来响应用户的请求
- 某个自适应的软件系统可能根据不同的配置状况采用不同的连接子来传送数据
- 软件系统外部的请求对软件进行的重配置
举例:
- 很多软件在系统升级时不能停机,导致了体系结构动态地发生变化
2)动态SA研究
-
动态体系结构所要研究的内容
如何在设计阶段捕获体系结构的这种动态性,并进一步指导软件系统在运行时刻实施这些变化,从而实现系统的在线演化或自适应甚至自主计算 -
现阶段,动态SA研究可分为以下两个部分:
- 体系结构设计阶段的支持
主要包括变化的描述、如何根据变化生成修改策略、描述修改过程、在高抽象层次保证修改的可行性以及分析、推理修改所带来的影响等。
- 运行时刻基础设施的支持
主要包括系统体系结构的维护、保证体系结构修改在约束范围内、提供系统的运行时刻信息、分析修改后的体系结构符合指定的属性、正确映射体系结构构造元素的变化到实现模块、保证系统的重要子系统的连续执行并保持状态、分析和测试运行系统等。
2.6.2 体系结构恢复与重建
1)概述
- SA重建:指从已实现的系统中获取体系结构的过程
- 输出:一组体系结构视图
2)重建方法
现有的体系结构重建方法:
- 手工体系结构重建
- 工具支持的手工重建
- 对手工重建提供辅助支持
- 包括获得基本体系结构单元、提供图形界面允许用户操作 S A模型、支持分析S A模型等。
- 对手工重建提供辅助支持
- 通过查询语言来自动建立聚集
- 使用范围:较大规模的系统
- 基本思路是:
- 在逆向工程工具的支持下分析程序源代码
- 将得到的体系结构信息存入数据库
- 通过适当的查询语言得到有效的体系结构显示
- 其他技术(如数据挖掘)
3. 软件架构的重要性
3.1 满足系统的品质
- 系统品质如:性能、安全性、可维护性等
- 品质的评估:通过架构设计文档化
3.2 使受益人达成一致的目标
没有要记忆的内容
3.3 支持计划编制过程
- 支持项目计划和项目管理的活动
例如,细节划分、日程安排、工作分配、成本分析、风险管理和技能开发等
- 协助估算项目成本
例如:使用第三方组件的成本,支持开发的所有工具的成本
- 支持技术风险的管理
- 制订风险的优先次序
- 确定恰当的风险缓解策略
3.4 对系统开发的指导性
没有有价值的信息
3.5 能够有效地管理复杂性
架构设计过程考虑组件地递归分解,把大问题分解成很多小问题,再逐个解决。
3.6 为复用奠定了基础
- 体系架构的建立,能够支持大粒度的资源复用
- 降低成本
- 提高质量
3.7 能够降低维护费用
- 结合恰当的系统维护机制,提高了系统的可维护性
- 系统的适应性
- 可扩充性
3.8 能够支持冲突分析
- 软件构架确定了:
- 主要的组件和它们之间的交互作用
- 组件之间的依赖性
- 这些组件对于需求的可追溯性
- 因此:
- 需求的改变可以通过组件的影响来分析
- 组件的影响可以在依靠它的其他组件上分析出来