软件架构概述

• 从需求分析到软件设计之间的过渡过程称为软件架构
• 需求分配，将满足需求的职责分配到组件上
• 提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成
• 指定了系统的组织结构和拓扑结构，显示了系统需求和构件之间的对应关系
• 根本目的：解决软件的复用、质量和维护问题
• 包括：提出架构模型、产生架构设计和进行设计评审等活动
• 主要关注：软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构
• 便于技术人员和非技术人员就软件设计进行交互，展现软件的结构、属性与内部交互关系
• 是项目干系人进行交流的手段
• 是推理和控制的更改更加简单
• 是可传递和可复用的模型，通过研究软件架构可能预测软件的质量

软件架构设计与声明周期

• 对于整个软件开发阶段的帮助
  • 需求分析阶段：研究问题空间和解空间，关注两个问题：如何根据需求模型构建 SA 模型，如何保证模型转换的可追踪性
  • 设计阶段：SA 研究关注的最早和最多的阶段。SA 研究包括：SA 模型的描述、SA 模型的设计与分析方法，以及对 SA 设计经验的总结和复用
  • 实现阶段：实现 SA 设计向实现的转换，主要研究
    • 基于 SA 的开发过程支持
    • 从 SA 向实现过渡的途径
    • 基于 SA 的测试技术
  • 构件组装阶段：在较高层次上实现系统，SA 设计模型起到了系统蓝图的作用，研究内容包括
    • 支持可复用构件的互联
    • 组装时如何检测并消除体系结构失配的问题
  • 部署阶段：作用如下
    • 高层的体系结构视图
    • 可以分析部署方案的质量属性
  • 后开发阶段：部署安装后的阶段，围绕维护、演化、复用等方面。主要研究 动态软件体系结构、体系结构恢复与重建
    • 动态软件体系结构：体系结构会在运行时发生改变。运行时变化分为两类：内部执行、外部请求。包括两部分研究：设计阶段的支持、运行时刻基础设施
    • 体系结构恢复与重建：没有考虑 SA 的情况，从这些系统中恢复或重构体系结构

构件

• 独立可交付的功能单元，外界通过接口访问其提供的服务
• 由一组通常需要同时部署的原子构件组成。是一个模块和一组组件。是部署、版本控制和替换的基本单位
• 大多数原子构件永远都不会被单独部署，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族
• 一个模块是不带单独资源的原子构件
• 一个单独的包被编译成多个单独的类文件
• 模块是一组类和可能的非面向对象的结构体
• 构件的特性
  • 独立部署单元
  • 第三方的组装单元
  • 没有外部可见状态
• 一个构件可以包含多个类元素，但一个类元素只能属于一个构件
• 对象的特性
  • 一个实例单元
  • 可能具有状态
  • 封装了自己的状态和行为
• 构件接口：消息的格式、模式和协议的标准化，关注输入输出的消息的标准化
• 面向构件的编程 COP：关注如何支持建立面向构件的解决方案
• 常用的构件标准：
  • EJB：三种类型：会话 Bean、实体 Bean 和消息驱动 Bean。实现应用中关键的业务逻辑，创建基于构件的企业级应用程序
  • COM：微软
  • CORBA：分为三个层次
    • 对象请求代理 ORB：最底层，是分布对象系统中的软总线
    • 公共服务：定义在 ORB 之上
    • 公共设施：最上层，定义了组件框架

软件架构风格

• 描述某一特定应用领域中系统组织方式的管用模式
• 定义一个系统家族，即一个架构定义、一个词汇表和一组约束
• 词汇表中包含一些构件和连接件类型，约束指出系统是如何将这些构件和连接件组合起来的
• 反映了领域中众多系统多共有的结构和语义特性，指导如何将各个模块和子系统有效地组织成一个完整的系统
• 一个核心问题是能否达到架构级的软件复用
• 定义了用于描述系统的术语表和一组指导构件系统的规则
• 五大风格：
  • 数据流风格：面向数据流，按照一定的顺序从前向后执行程序，代表风格：批处理序列、管道-过滤器
  • 调用返回风格：构件间存在互相调用关系，一般是显式调用。代表风格：主程序/子程序、面向对象、层次结构
  • 独立构件风格：通过事件触发、异步执行。代表风格：进程通信、事件驱动系统
  • 虚拟机风格：自定义了一套规则供使用者使用。代表风格：解释器、基于规则的系统
  • 仓库风格：以数据为中心，所有的操作都是围绕建立的数据中心进行。代表风格：数据库系统、超文本系统、黑板系统
• 数据流风格
  • 批处理序列：构件之间指通过数据传递交互，每一步必须在其前一步结束后才能开始
  • 管道-过滤器：前一个构件的输出作为后一个构件的输入
  • 早期编译器即采用此架构
  • 二者区别在于批处理前后构件不一定有关联，而是作为整体传递。管道过滤器是前一个输出作为后一个输入，前面执行到部分可以开始下一个的执行
• 调用返回风格
  • 主程序子程序：把问题划分为若干处理步骤，构件即为主程序和子程序。过程调用作为交互机制，充当连接件
  • 面向对象：构件是对象，连接件即对象间的交互方式，对象是通过函数和过程调用来交互的
  • 层次结构：构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。修改某一层，最多影响相邻两层
    • 优点
      • 将一个复杂问题分解成一个增量步骤序列的实现
      • 越靠近底层、抽象级别越高
      • 为软件复用提供了强大的支持
    • 缺点
      • 并不是每个系统都可以很容易的划分为分层的模式
      • 很难找到一个合适的、正确的层次抽象方法
• 独立构件风格
  • 进程通信：构件是独立进程，连接件是消息传递。消息传递方式可以是点对点、异步或同步方式，以及远程过程调用
  • 事件驱动系统：触发或广播一个或多个事件。某个事件被触发时，系统自动调用在这个事件中注册的所有过程
  • 优点：为软件复用提供了强大的支持，为构件的维护和演化带来了方便
  • 缺点：构件放弃了对系统计算的控制
• 虚拟机风格
  • 解释器：包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个技术解释引擎当前工作状态的数据结构、一个记录源代码被解释执行进度的数据结构，执行效率低
  • 基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和 DSS 中
• 仓库（数据共享）风格
  • 数据库系统：构件有两大类：中央共享数据源和多个独立处理单元，处理单元对数据元素进行操作
  • 黑板系统：包括知识源、黑板和控制三部分。知识源包含若干独立计算的不同单元，提供解决问题的知识。黑板是一个全局数据库。知识源响应是通过黑板状态的变化来控制的。通常应用在对于解决问题没有确定性算法的软件
  • 超文本系统：构件以网状链接方式互相连接，在构件之间按照人类的联想思维方式任意跳转到相关构件。通常应用在互联网
  • 现代编译器的集成开发环境一般采用数据仓库
• 闭环控制
  • 软件与硬件之间可以粗劣的表示为一个反馈循环
• C2 体系结构风格
  • 
  • 通过连接件绑定在一起的按照一组规则运作的并行构件网络，组织规则如下
    • 构件和连接件购有一个顶部和一个底部
    • 构件的顶部链接到某连接件的底部，构件的底部则应连接到某连接件的顶部，构件与构件之间的直接连接是不允许的
• 

层次架构风格

• 两层 C/S 架构：客户端和服务器都有处理功能，现在已不常用
• 三层 C/S 架构
  • 将处理功能独立出来。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上
  • 各层在逻辑上保持相对独立
  • 灵活有效的选用相应的平台和硬件系统
  • 可以并行开发
  • 整个系统的管理层次也更加合理和可控制
  • 关键在于各层之间的通信效率
• 三层 B/S 架构
  • 将客户端变为用户客户端上的浏览器，应用服务器变成网络上的 WEB 服务器
  • 0 客户端架构
• 富互联网应用 RIA
  • RIA 是一种用户接口
  • 结合了 C/S 架构反应速度快、交互性强的优先与 B/S 架构传播范围广及容易传播
  • 简化并改进了 B/S 架构的用户交互
  • 数据能够被缓存在客户端
  • 本质还是 0 客户端，高速网络实现必要插件在本地的快速缓存
• MVC 架构
  • 控制器：处理用户交互部分
  • 模型：处理应用程序数据逻辑部分
  • 视图：处理数据显示部分
• MVP 架构：将 Controller 换成了 Presenter（呈现），目的就是完全切断 View 与 Model 之间的联系
• MVVM 架构：目的是分离视图 View 和 模型 Model，VM 即 ViewModel

面向服务的架构风格 SOA

• 粗粒度、松耦合的服务架构
• 服务是一种为了满足某项业务需求的操作、规则等逻辑组合
• 管理员可以直接管理开发人员所构建的相同服务，多个服务通过企业服务总线提出服务请求
• 关键目标：实现 IT 资产重用的最大化
• 特征：
  • 可从企业外部访问
  • 随时可用
  • 粗粒度接口
  • 服务分级
  • 松散耦合
  • 可重用的服务及服务接口设计管理
  • 标准化的接口
  • 支持各种消息模式
  • 精确定义的服务接口
• 从基于对象到基于构件到基于服务：架构越来越松散耦合、粒度越来越粗、接口越来越标准
• 基于服务的构件与传统构件的区别
  • 粗粒度
  • 接口标准，主要是 WSDL 接口
  • 实现与语言无关
  • 通过构件容器提供 QoS 的服务
• SOA 中的关键
  • UDDI：用于 WEB 服务注册统一描述、发现和集成
  • WSDL：将 Web 服务描述定义为一组服务访问点，用于描述服务
  • SOAP：用于交换 XML 编码信息的轻量级协议，用于传递信息
  • XML：表示数据的基本格式，用于数据交换
• 三种实现方式
  • Web Service：服务提供者、服务注册中心、服务请求者
  • 服务注册表
    • 服务注册
    • 服务位置
    • 服务绑定
  • 企业服务总线 ESB：一根管道，用来连接各个服务节点。集成基于不同协议的不同服务，ESB 做了消息转化、解释以及路由，让不同服务互联互通
    • 包括客户端、基础架构服务、核心集成服务
    • 特点
      • 总线作用
      • 描述服务的元数据和服务注册管理
      • 传递数据，转换数据
      • 发现、路由、匹配和选择

软件架构复用

• 软件产品线是一组软件密集系统，共享一个公共的、可管理的特性集，是以规定的方式用公共的核心资产集成开发的
• 复用类型包括
  • 机会复用：只要发现有可复用即复用
  • 系统复用：在开发前就进行规划以决定哪些需要复用
• 复用的基本过程包括三个阶段
  • 构造/获取可复用的软件资产
  • 管理这些资产（构件库）
  • 针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统

特定领域软件架构

• DSSA，专用于一类特定类型的任务的软件构件的集合
• 特定的问题领域，支持在一个特定领域中多个应用的生成
• 垂直域：一个特定领域中的通用的软件架构，是一个完整的架构
• 水平域：多个不同的特定领域之间的相同的部分的小工具
• 三个基本活动
  • 领域分析：目标是获得领域模型（领域需求），识别信息源，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型
  • 领域设计：目标是获得 DSSA，DSSA 描述在领域模型中表示的需求的解决方案，适应领域中多个系统的需求的一个高层次的设计
  • 领域实现：目标：依据领域模型和 DSSA 开发和组织可重用信息
• 参与 DSSA 的四种角色
  • 领域专家：包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等
  • 领域分析人员：具有知识工程北京的有经验的系统分析员担任
  • 领域设计人员：由有经验的软件设计人员来担任
  • 领域实现人员：由有经验的程序设计人员来担任
• 建立 DSSA 的过程
  • 定义领域范围
  • 定义领域特定的元素
  • 定义领域特定的设计和实现需求的约束
  • 定义领域模型和架构
  • 产生、搜集可复用的产品单元
• 三层次模型
  • 领域开发环境：产出参考结构、参考需求、架构、领域模型、开发工具
  • 领域特定的应用开发环境
  • 应用执行环境

基于架构的软件开发

• ABSD，架构驱动，强调由业务、质量和功能需求的组合驱动架构设计，强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求
• 设计活动可以从项目总体功能框架明确就开始
• 三个基础
  • 功能的分解
  • 通过选择架构风格来实现质量和业务需求
  • 软件模板的使用
• 递归的
• ABSD 六步
  • 架构需求：掌握标识构件的三步骤：需求获取 → 生成类图 → 对类进行分组 → 把类打包成构件 → 需求评审
  • 架构设计：将需求阶段的标识构件映射成构件
  • 架构文档化：产出架构规格说明、测试架构需求的质量设计说明书
  • 架构复审：外部人员（独立于开发组织之外的人，如用户代表和领域专家）参加的复审
  • 架构实现：用实体来显示出架构，实现构件，构件组装成系统
  • 架构演化：对架构进行改变，按需求增删构件，使架构可复用

软件系统的质量属性

• 可分为
  • 开发期质量属性
  • 运行期质量属性
• 质量属性场景是一种面向特定质量属性的需求，由 6 部分组成
  • 刺激源：生成该刺激的实体，最终用户、开发人员、系统管理员
  • 刺激：当刺激到达系统时需要考虑的条件，希望增加、删除、修改等
  • 环境：刺激在某些条件内发生，设计、编译 、构建、运行时
  • 制品：某个制品被刺激，用户界面、平台、环境或与目标系统交互的系统
  • 响应：在刺激到达后采取的行动，查找架构中需要修改的位置、进行修改且不会影响其他功能、对所做的修改进行测试、部署修改
  • 响应度量：如成本、努力、资金，对其他功能或质量属性所造成的影响的程度

软件架构评估

• 质量属性
  • 性能：系统响应能力，如响应时间、吞吐量。设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度
  • 可靠性：在意外或错误使用的情况下维持软件系统的功能特性的能力，如 MTTF、MTBF、MTTR。设计策略：心跳、Ping/Echo、冗余、选举
  • 可用性：能够正常运行的时间比例，如故障间隔时间。设计策略：心跳、Ping/Echo、冗余、选举
  • 安全性：系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。设计策略：入侵检测、用户认证、用户授权、追踪审计
  • 可修改性：以较高的性能价格比对系统进行变更的能力。设计策略：接口-实现分类、抽象、信息隐藏
  • 功能性：系统所能完成所期望的工作的能力
  • 可变性：体系结构经扩充或变更而成为新体系结构的能力
  • 互操作性：组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用
• 敏感点：为了实现某种特定的质量属性，一个或多个构件具有的特性
• 权衡点：影响多个质量属性的特性
• 风险点非风险点：可能引起风险的因素/可行的可接受的
• 软件架构评估在架构设计之后，系统设计之前，目的是为了评估所采用的架构能够解决软件系统需求
• 三种常用的评估方式
  • 基于调查问卷（检查表）的方式：问卷调查
  • 基于度量的方式：指定定量指标
  • 基于场景的方式：主要方法
    • 确定应用领域的功能和软件架构的结构之间的映射
    • 设计用于体现待评估质量属性的场景
    • 分析软件架构对场景的支持程度
    • 从三个方面设计场景：刺激、环境、响应
• 基于场景的架构分析方法 SAAM
  • 非功能质量属性的架构分析，最早
  • 特定目标：对描述应用程序属性的文档，验证基本的架构假设和原则
  • 质量属性：主要为可修改性
  • 架构描述：用于架构的最后版本
  • 描述架构的三个主要方面：功能、结构和分配
  • 方法活动：主要输入是问题描述、需求声明和架构描述
  • 五个步骤：场景开发、架构描述、单个场景评估、场景交互和总体评估
• 架构权衡分析法 ATAM：让架构师明确如何权衡多个质量目标
  • 分为四个主要的活动领域
    • 场景和需求收集
    • 体系结构视图和场景实现
    • 属性模型构造和分析
    • 架构评估和折中
  • 强调以属性作为架构评估的核心概念
• 成本效益分析法 CBAM
  • 对架构建立的成本来进行设计和建模
  • 根据投资收益率选择合适的架构
• 其他方法
  • SAEM 方法：将架构看作一个最终产品以及设计过程中的一个中间产品，从外部质量属性和内部质量属性阐述
    • 外部属性指用户定义的质量属性
    • 内部属性指开发者决定的质量属性
    • 包含
      • 规约建模
      • 创建度量准则
      • 评估质量属性
  • SAABNet 方法：用来表达和使用定性知识以辅助架构的定性评估，人工智能
  • SACMM 方法：软件架构修改的度量方法
  • SASAM 方法：对预期架构和实际架构进行映射和比较来静态评估软件架构
  • ALRRA 方法：软件架构可靠性风险评估方法
  • AHP 方法：对定性问题进行定量分析
  • COSMIC+UML 方法：基于度量模型来评估软件架构可维护性的方法

中间件技术

• 中间件：分布式系统环境中处于 OS 和应用程序之间的软件，在不同的技术之间共享资源，将环境和若干应用结合成一个有机的协同工作整体
• 位于客户机/服务器的操作系统之上，管理计算机资源和网络通信
• 有如下特点
  • 一类软件
  • 实现互联，还要实现应用之间的互操作
  • 基于分布式处理的软件，最突出的特点是其网络通信功能
• 任务是使应用程序开发更加容易，隐藏异构系统和分布式系统下低级别编程的复杂度
• 主要的中间件
  • 数据库访问中间件：通过抽象层访问数据库，允许使用相同或相似的代码访问不同的数据库资源。如 ODBC 和 JDBC
  • RPC：分布式应用程序处理方法，使用 RPC 来远程执行一个位于不同地址空间内的过程
  • 面向消息中间件 MOM：利用高效可靠的消息传递机制进行平台无关的数据交流，基于数据通信即逆行分布系统的集成。可在分布环境下扩展进程间的通信，支持多种通信协议。如 IBM 的 MQSeries
  • 分布式对象中间件：对象技术和分布式计算技术。如 OMG 的 CORBA、Sun 的 RMI//EJB、Microsoft 的 DCOM
  • 事务中间件：事务处理监控器 TPM，位于客户和服务器之间，完成事务管理与协调、负载平衡、失效恢复等任务，提高系统的整体性能

典型应用架构

• J2EE 采用多层分布式应用程序模型，四层结构
  • 客户端组件
  • Web 层组件
  • 业务层组件
  • 信息系统层
• JSP：MVC 中的视图 V
• Servlet：MVC 中的控制器 C
• JavaBean：数据封装
• DAO：DAO 与 Bean 合在一起为 MVC 中的模型 M
• 重量级框架：开发麻烦，运行性能高
• 轻量级框架：开发简单，运行性能低
• .Net：只适用于微软系统