软件架构设计

一、考点分布

• 软件架构的概念（※※※）
• 基于架构的软件开发（※※※※）
• 软件架构风格（※※※※※）
• 特定领域软件架构（※※※）
• 软件质量属性（※※※※※）
• 软件架构评估（※※※※）
• 软件产品（※※※）
• 构件与中间件技术（※※※）

二、软件架构的概念 

架构的本质

• 软件架构为软件系统提供了一个结构、行为和属性的高级抽象。
• 软件架构风格是特定应用领域的惯用模式，架构定义一个词汇和一组约束

架构的作用

• 软件架构是项目干系人进行交流的手段
• 软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量
• 软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础

软件架构=软件体系结构

架构设计就是需求分配，即将满足需求的职责分配到组件上。

三、架构发展历程

架构的4+1视图

 四、软件架构风格-ADL

        ADL是一种形式化语言，它底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。

ADL三个基本要素：

• 构件：计算或数据存储单元
• 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
• 架构配置：描述体系结构的构件与连接件的连接图

 五、基于架构的软件开发方法-概念

ABSD方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。

ABSD方法有三个基础：

1. 功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术
2. 通过选择架构风格来实现质量和业务需求
3. 软件模块的使用

视角与视图：从不同的视角来检查，所以会有不同的视图

用例用来捕获功能需求、特定场景用来捕获质量需求。

六、软件架构风格

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

6.1 数据流风格 

基本思想：把数据分步骤处理

优点：

• 松耦合
• 良好的重用性/可维护性
• 可扩展性（标准接口适配）
• 支持并行

缺点：

• 交互性较差
• 复杂性较高
• 性能较差（每个过滤器都需要解析与合成数据）

典型实例

• 传统编译器
• 网络报文处理

数据流分格

• 批处理序列：大量整体数据、无需用户交互
• 管道-过滤器：流式数据、弱用户交互

6.2 调用/返回风格 

调用返回风格

• 主程序/子程序：面向过程
• 面向对象：对象的方法调用
• 分层：层与层之间的方法调用

分层架构风格

分层风格的优缺点

优点：良好的重用性，只要接口不变可用在其他处；可维护性；可扩展性好，支持递增设计。

缺点：并不是每个系统都方便分层；很难找到一个合适的、正确的层次抽象方法；不同层次之间耦合度高的系统很难实现。

特点：各个层次的组件形成不同功能级别的虚拟机；多层相互协同工作，而且透明。

6.3 独立构件风格

保证构件相互独立：不直接交互

优点：松耦合；良好的重用性/可修改性/可扩展性

缺点：构件放弃可对系统计算的控制。一个构件触发一个事件时，不确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程调用的顺序；数据交互问题；由于过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。

特点：系统由若干个子系统构成且成为一个整体；系统有统一的目标；子系统有主从之分；每一子系统有自己的事件收集和处理机制。

6.4 虚拟机风格

解释器结构

规则为中心

基于规则的系统构成：规则集、规则解释器、规则/数据选择及工作内存，一般用在人工智能领域和DSS（决策支持系统）中。

6.5 仓库风格

 

仓库：用来存储数据的构件

仓库风格

• 黑板系统
  • 优点：可更改性和可维护性；可重用的知识源；容错性和健壮性
  • 缺点：测试困难；不能保证有好的解决方案；难以建立好的控制策略；低效；开发困难；缺少并行机制
  • 特点：在以数据为中心的基础上，使用中心数据触发业务逻辑部件
  • 典型实例：语言识别、模式识别、图像处理、知识推理
• 数据库系统
  • 特点：以数据为中心

 6.6 闭环控制风格

闭环控制风格也叫过程控制

适合嵌入式系统，用于解决简单闭环控制问题

经典应用：空调温控、定速巡航

6.7 C2风格

C2架构的基本规则：

• 构件和连接件都有一个顶部和一个底部
• 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连
• 一个连接件可以和任意数目的其他构件和连接件连接
• 当两个连接件进行直接连接时，必须由其中一个底部到另一个顶部

6.8 MDA

         MDA也叫模型驱动架构，MDA将平台无关模型映射成平台相关模型，最后再映射成代码，代码不需要人工写，是形式化方法的产物。

MDA的三个核心模型

• 平台独立模型（PIM）：具有高抽象层次、独立任何实现技术的模型
• 平台相关模型（PSM）：为某种特定实现技术量身定做，让你用这种技术可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM
• 代码Code：用源代码对系统的描述（规约）。每个PSM都被变成代码。

 七、特定领域软件架构（DSSA）

DSSA：以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。

DSSA类型

• 垂直域：相同领域，深入
• 水平域：不同领域，平移

参与DSSA的人员

1. 领域专家：有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
2. 领域分析人员：领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。
3. 领域设计人员：领域设计人员应有经验的软件设计人员来担任
4. 领域实现人员：领域实现人员应由有经验的程序设计人员来担任

专家是提高策略的，其他成员负责干活的

DSSA建立过程

三层次模型

 八、软件架构评估

8.1 质量属性

8.2 性能

        性能指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

8.3 可用性

        可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。注意当遇到可用性和可靠性，两者相似，但优先选可用性。

 8.4 安全性

安全性：指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。

安全性分为

• 机密性（信息不泄露給未授权的用户）
• 完整性（防止信息被篡改）
• 不可否认（不可抵触）
• 可控性（对信息的传播及内容具有控制的能力）

8.5 可修改性

        可修改性：指能够快速地以较高的性能价格对系统进行变更的能力。通常以某些变更为基准，通过考察这些变更的代价衡量可修改性。

8.6 易用性和可测试性

易用性：关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类

可测试性：指通过测试提示软件缺陷的容易程度。例如提供远程调试接口，支持远程调试

九、敏感点、权衡点等 

敏感点是一个或多个构件（和/或构件之间的关系）的特性。

权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点是指构件设计中潜在的、存在问题的架构决策所带来的隐患。

非风险点是指不会带来隐患，一般“xxx要求是可以实现（或接受）的”方式表达。

十、软件架构评估

 10.1 权衡点中质量属性的相关性问题

10.2 架构评估方法

• 基于调查问卷（检查表）的方式
• 基于度量的方式
• 基于场景的方式

场景：是从风险承担者的角度与系统交互的简短描述

场景从六个方面描述：刺激源、刺激、制品、环境、响应、响应度量

基于场景的评估方法

• 软件架构分析法（SAAM）：最初关注可修改性，后扩充到可移植性、可扩充性等
• 架构权衡分析法（ATAM）：主要针对：性能、实用性、安全性可修改性
• 成本效益分析法（CBAM）：在ATAM基础上建立的，软件的“经济”模型

10.3 SAAM

SAAM：最初用于分析架构可修改性，后扩展到其他质量属性。

10.4 ATAM

ATAM：在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评估和折中。

10.5 质量效用树

M：中级 L：低级 H:高级

十一、软件产品线

软件产品线把共性的事物抽离出来复用

软件产品线-组织结构

• 设立独立的核心资源小组
• 不设立独立的核心资源小组
• 动态的组织结构

要成功实施产品线，主要取决于以下因素

• 对该领域具备长期和深厚的经验
• 一个用于构建产品的好的核心资源库
• 好的产品线架构
• 好的管理（软件资源、人员组织、过程）支持

十二、软件复用

软件复用（重用）是多次不同的软件开发过程中重复使用相同或相似的软件元素的过程。

软件元素包括：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识

复用的维度

• 水平复用：不分行业领域，通用
• 垂直复用：分行业领域，专用

十三、构件的复用

 构件复用的步骤

1. 检索与提取构件
   1. 基于关键字检索
   2. 刻面检索法
   3. 超文本检索法
2. 理解与评价构件
   1. 复用构件，准确理解构件，特别对构件修改使用时
   2. 为到达目的，必须要求构件的开发过程遵循公共标准
   3. 一般构件库的文档会说明构件的功能与行为、相关的领域知识、可适应性约束条件与例外情形、可以预见的修改部分及修改方法
3. 修改构件
   1. 理想可以直接复用构件，但多数情况需要进行修改
   2. 为了减少构件的修改工作量，需要在开发构件将构件的功能。行为和接口设计做成抽象化、通用化和参数化
   3. 构件库中弱无可修改使用的构件，则按新需求开发构件，并存入构件库
4. 组装构件
   1. 构件组装有基于功能、基于数据和基于面向对象的组装三种方式
   2. 组装失配问题：由构件引起的失配、由连接子引起和由系统成分对全局体系结构的假设存在冲突引起的失配等

十四、 构件与中间技术-概念

构件的定义

• 定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
• 定义2：构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。
• 定义3：构件是一个独立分布的功能部分，可以通过其接口访问它的服务。

构件的由来

构件系统架构的特性

• 构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成
• 构件框架是一种专用的体系结构（通常围绕一些关键的机制），同时，也是一组固定地作用于构件层次机制的策略
• 概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则
• 构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署
• 一个原子构件是一个模块和一组资源
• 模块是一组类和可能的非面向对象的结构体，比如过程或函数
• 资源是一个类型化的项的固定集合
• 资源这个概念可以包含代码资源，进而包含模块。问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源。在“纯对象”的方法中，资源是外部化的不可改变的对象--不可改变是因为构件没有持久化的标志，而且复制不能被区分。

中间件是一类构件，是一类系统软件

中间件技术的优点

• 面向需求。即设计师集中精力于业务逻辑本身
• 业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互模式
• 设计与实现隔离。
• 隔离复杂的系统资源
• 符合标准的交互模型。中间件实现架构的模型，实现了标准的协议
• 软件复用
• 提供对应用软件的管理。基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分

中间件的分类

构件的三大标准

• CORBA
• J2EE（EJB）
  • 会后bean：实现业务逻辑，负责完成服务端与客户端的交互
  • 实体bean：实现O/R映射，简化数据库的开发工作
  • 消息驱动Bean：处理并发与异常访问
• DNA2000

CORBA的结构

伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端的请求

对象适配器：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便它们使用ORB内部的某些功能

对象请求代理：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。