架构考试-软件架构

包含软件架构设计、软件架构评估、软件架构风格三个部分核心内容的梳理。架构设计内容包括架构基本概念、架构4 1视图、ABSD、软件产品线、软件复用、软件中间件等；架构评估包括软件质量属性、架构评估基本概念和方法；架构风格包括主要的架构风格的概念、特点、示例等

软件架构设计

• 软件架构概念
  • 软件架构定义
    • 软件架构为软件系统提供了一个结构、行为和属性的高级抽象
  • 软件架构风格
    • 是特定应用领域的惯用模式，反应了领域中多个系统共有的结构和语义特性，并指导如何将各个模块和子系统有效组织成一个完整的系统
    • 架构定义一个词汇表和一组约束，词汇表中包含一些构件和连接件类型，而这组约束指出系统如何将这些构件和连接件组合起来。
  • 架构的作用
    • 项目关系人进行交流的手段
    • 可传递和可复用的模型，通过研究软件架构可能预测软件的质量
    • 使推理和控制的更改更加简单，有助于循序渐进的原型设计，可作为培训的基础
  • 软件架构=软件结构体系
  • 架构设计就是需求分配，即将满足需求的职责分配到组件上
  • 软件架构侧重描述软件系统的非功能属性
  • 软件架构结构
    • 软件架构结构根据其所展示元素的广义性质，可以被分为三个主要
    • 类别
      • 1)模块结构将决策体现为一组需要被构建或采购的代码或数据单元。
      • 2)构件连接器结构将决策体现为系统如何被结构化为一组具有运行时行为和交互的元素。
      • 3)分配结构将决策体现为系统如何在其环境中关联到非软件结构，如CPU、文件系统、网络、开发团队等。
  • 软件结构设计内容
    • 体系结构设计
    • 数据设计
    • 接口设计
    • 过程设计
• 软件架构的发展历程
• 架构的4+1视图
  • 逻辑视图
    • 从结构化视角，描述该系统对用户提供的所需功能服务所具备的组件结构和数据结构，以及一些边界约束条件，清晰的描述给用户提供的功能需求服务是如何构建的
  • 开发视图
    • 从结构化视角和行为视角，去描述实现系统功能的各个组件和模块是如何实现的
  • 进程视图（过程视图）
    • 描述系统各个组件和模块是如何进行通信的
  • 物理视图
    • 描述软件和硬件的映射关系
  • 场景（质量场景）
    • 描述系统的参与者（用户）与系统功能用例的关系，使用场景描述软件系统的非功能需求--软件质量属性
    • 质量场景描述
      • 刺激源
        • 生成该刺激的实体，可能是人、计算机系统或其他激励器
      • 刺激
        • 刺激到达系统时可能产生的影响，即需要考虑和关注的情况
      • 环境
        • 该刺激在某条件内发生，如系统可能正处于过载情况
      • 制品
        • 系统中受刺激的部分，可能是某个制品被刺激
      • 响应
        • 刺激到达后所采取的行动
      • 响应度量
        • 当响应发生时，应能够以某种方式对应其度量，用于对是否满足需求的测试
      • 从风险承担者的角度对系统的交互进行描述 ，一般采用刺激、环境、响应三个方面进行描述
    • 质量场景示例
      • 在线购物网站
        • 刺激源：用户在购物网站浏览一个商品并点击了“加入购物车”按钮。
        • 刺激：用户执行了加入购物车的操作。
        • 环境：系统正在正常运行，网络连接稳定。
        • 制品：在线购物网站。
        • 响应：网站将商品添加到购物车并显示购物车内的商品列表。
        • 响应度量：系统在95%的情况下在3秒内成功将商品添加到购物车
      • 航空订票系统
        • 子主题
          • 刺激源：用户在航空订票网站搜索从A到B的航班，并选择一个航班。
          • 刺激：用户选择了航班并点击了“预订”按钮。
          • 环境：系统正在正常运行，网络连接稳定。
          • 制品：航空订票系统。
          • 响应：系统显示所选航班的详细信息，并接受用户的预订。
          • 响应度量：系统在98%的情况下在4秒内成功显示航班详细信息和接受预订请求。
• 架构描述语言
  • ADL
    • 一种形式化语言
    • 三个基本要素
      • 构件
        • 计算或数据的存储单元
      • 连接件
        • 用于构件之间交互模型的体系结构构造块及其支配这些交互的规则
      • 架构配置
        • 描述体系结构中构件与连接件的连接图
• 基于架构的开发方法（ABSD）
  • 特征
    • 能很好的支持软件的复用
    • 是一个自顶而下，逐渐细化的方法，软件系统通过该方法逐渐细化体系结构，直到能产生软件的构件和类
    • 架构驱动
      • 强调由业务、质量和功能需求的组合驱动架构设计
  • 用例用来捕获功能需求，场景（刺激、环境、响应）用来捕获质量需求
  • 用视角与视图描述软件架构
    • 4+1视图
  • 三个基础
    • 功能的分解
    • 通过选择架构风格来实现质量和业务需求
    • 软件模板的使用
  • 开发过程
    • 架构需求
      • 步骤
        • 获取需求
          • 需求库
            • 需求的复用
        • 生成类图
        • 对类进行分组
        • 把类打包成构件
        • 需求评审
    • 架构设计
      • 步骤
        • 提出架构模型
        • 映射构件
        • 分析构件相互作用
        • 产生架构
        • 设计评审
    • 架构文档化
      • 输出两个文档
        • 架构规格说明书
        • 测试架构需求的质量设计说明书
      • 三大注意事项
        • 从使用者角度就那些编写
        • 必须分发给所有与系统相关的开发人员
        • 必须保证开发者手上的文档是最新的
      • 软件文档的完整性和质量是软件架构成功的关键因素
    • 架构复审
      • 目的是标识潜在的风险，及早发现架构设计中的缺陷和错误
    • 架构实现
      • 分析与设计
      • 构件实现
      • 构件组装
      • 系统测试
    • 架构演化
      • 需求变化归类
      • 架构演化计划
      • 构件变动
        • 构件库
      • 更新构件的相互作用
      • 构件组装与测试
      • 技术评审
      • 演化后的架构
• 软件产品线-双生命周期模型
  • 模型
    • 领域工程
      • 领域分析-领域设计-领域实现
    • 应用工程
      • 需求分析-系统设计-系统实现
• 软件架构复用
  • 软件架构重用是一个解释性、交互式和反复迭代的过程，包括了多项活动。信息提取通过分析系统现有设计和实现工件来构造它的模型。其结果用于在后续活动中构造系统的视图。数据库构建活动把模型中包含的元素和关系转换为数据库中的标准存储格式。视图融合活动包括定义和操作数据库中存储的信息，理顺、加强并建立起元素之间的连接。
  • 重构由两个主要活动组成：可视化和交互记及模式定义和识别。前者提供了一种让用户操作架构元素的机制，后者则提供了用于架构重构的设施。
  • 分类
    • 机会复用
      • 指开发过程中只要发现可复用的资产，就对其进行复用
    • 系统复用
      • 指开发之前，进行规划，以决定哪些进行复用
• 构件与中间件技术

软件架构评估

• 为什么要进行软件架构评估
  • 架构是软件的主体结构，如果主体结构出错，将导致整个软件开发失败。如果开发过程中进行大量的修改，或者开发完成后不符合需求，这是极大的风险。
• 质量属性
  • 性能
    • 系统的响应能力，即要经过多少时间才能对某个事件做出响应或者某段时间内系统能处理的事件的个数
    • 性能战术
      • 资源需求
        • 提高计算效率
        • 减少计算开销
        • 管理事件率
        • 控制采样频率
      • 资源管理
        • 引入并发
        • 维持多个副本
        • 增加可用资源
      • 资源仲裁
        • 资源调度策略
          • 先入先出
            • 排队
          • 固定优先级
          • 动态优先级
          • 静态调用
    • 示例
      • 响应时间小于1S
    • 性能评估
      • 主要目的是评价信息系统在性能方面的表现，找出系统可能存在的性能瓶颈。
      • 常见的Web服务器性能评估方法有基准测试、压力测试和可靠性测试等，
      • 评价Web服务器的主要性能指标有最大并发连接数、响应延迟和吞吐量等。
  • 可靠性
    • 定义：指软件系统在一定时间内无故障运行的能力
    • 子特性
      • 容错性
        • 也称为鲁棒性
        • 指软件系统在一些非正常情况下仍能正常运行的能力
      • 健壮
      • 易恢复性
  • 可用性
    • 定义：系统能够正常运行的时间比例
    • 可用性战术
      • 错误检测
        • 命令/响应---ping/echo
        • 心跳
        • 异常
      • 错误恢复
        • 表决
        • 冗余
        • 备件
      • 错误预防
        • 进程监视器
        • 事务
        • 从服务器删除
    • 示例
      • 系统支持7*24小时运行
      • 系统故障，1小时内恢复
      • 主服务器故障，1分钟切换到备用服务器
  • 安全性
    • 定义：系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或者拒绝服务的能力
    • 划分为
      • 机密性
      • 完整性
      • 不可否认性（不可抵赖）
      • 可控性
    • 安全性战术
      • 抵御攻击
        • 身份验证
        • 用户授权
        • 数据加密
        • 数据完整性
        • 限制暴露
        • 限制访问
      • 检测攻击
        • 入侵检测
      • 从攻击中恢复
        • 识别：审计追踪
        • 恢复：冗余
    • 示例
      • 防SQL注入
      • 用户信息数据库授权必须99.9%可用
  • 可修改性
    • 定义：能够快速地以较高的性价比对系统进行变更的能力
    • 子特性
      • 可维护性
        • 易分析性、易改变性、稳定性、易测试性
      • 可扩展性
        • 软件因新需求或需求变化而增加新功能的能力，也称为灵活性
      • 可移植性
        • 适应性、易安装性、易替换性
        • 将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度
      • 结构重组
    • 可修改性战术
      • 局部化修改
        • 维持语义的一致性
        • 预期期望的变更
        • 泛化模块
        • 限制可能的选择
        • 抽象通用服务
      • 防止连锁反应
        • 隐藏信息
        • 维持现有接口
        • 限制通信路径
        • 使用仲裁者
      • 推迟绑定时间
        • 运行时注册
        • 配置文件
        • 多态
        • 组件更换
        • 遵守已定义的协议
    • 示例
      • 调整登录页，必须在1人天内完成
  • 易用性
    • 定义：关注的是对用户来说完成某个期望任务的容易程度和系统提供的用户支持种类
    • 示例
      • 界面友好
      • 用户学习使用系统时间不超过2小时
    • 子特性
      • 易学性
      • 易操作性
      • 易理解性
  • 可测试性
    • 定义：通过测试揭露软件缺陷的容易程度
    • 示例
      • 提供远程调试接口，支持远程调试
  • 互操作性
    • 定义：指本软件系统与其他系统交换数据和相互调用服务的难以程度
• 架构评估
  • 基本概念
    • 敏感点
      • 影响系统某个质量属性的一个或者多个构件的特性
    • 权衡点
      • 影响系统多个质量属性的特性，是多个质量属性的敏感点
      • 示例
        • 非对称加密会提高安全性但是会影响性能
    • 风险点
      • 架构设计中潜在的、存在问题的架构决策所带来的隐患
    • 非风险点
      • 指不会带来隐患，一般以“XX要求是可以实现（接受的）”方式表达
  • 评估方法
    • 基于问卷调查（检查表）的方式
    • 基于度量的方式
    • 基于场景的方式
      • 分析方法
        • 软件架构分析法SAAM
          • 最初只关注可修改性，后扩充到可移植性、可扩充性
          • 步骤
            • 场景开发
            • 架构描述
            • 单个场景评估
            • 场景交互
            • 总体评估
          • 主要输入
            • 问题描述
            • 需求声明
            • 体系结构描述
        • 架构权衡分析法ATAM
          • 有SAAM发展而来，主要针对：性能、实用性、安全性、可修改性，在系统开发前对这些质量属性进行评价和折中
          • 阶段
            • 场景和需求收集
            • 架构视图和场景实现
            • 属性模型构造与分析
            • 折中
          • 效用树
            • 采用效用树对质量属性进行分类和优先级排序
            • 组成
              • 树根
              • 质量属性
              • 属性分类
              • 质量属性场景
        • 成本效益分析法CBAM
          • 在ATAM基础上建立的，软件的“经济”模型
      • 示例
        • 见软件架构4+1视图的场景视图

软件架构风格

• 数据流风格
  • 子风格
    • 批处理
      • 大量整体数据，无用户交互
    • 管道-过滤器
      • 流式数据，弱用户交互
  • 优点
    • 1、松耦合[高内聚-低合]
    • 2、良好的重用性/可维护性;
    • 3、可扩展性[标准接口适配]
    • 4、良好的隐蔽性;
    • 5、支持并行。
  • 缺点
    • 1、交互性较差;
    • 2、复杂性较高;
    • 3、性能较差(每个过滤器都需要解析与合成数据)
  • 示例
    • 传统编译器
    • 网络报文
• 调用返回风格
  • 分层架构
    • 优点
      • 良好的重用性
      • 可维护性好
      • 可扩展性好
    • 缺点
      • 子主题
      • 并不是每个系统都方便分层
      • 很难找到一个合适的、正确的层次抽象方法
      • 不同层次之间耦合度高的系统很难实现
  • 子风格
    • 主程序/子程序
      • 面向过程
    • 面向对象
      • 对象的方法调用
    • 层次性架构风格
    • C/S架构风格
      • 两层C/S
      • 三层C/S
• 独立构件风格
  • 子风格
    • 进程通信
    • 事件驱动系统（隐式调用）
  • 优点
    • 松耦合
    • 良好的重用性/可维护性/可扩展性
  • 缺点
    • 数据交换的问题
    • 构件放弃了对系统的控制
    • 依赖上下文
• 虚拟机风格
  • 子风格
    • 解释器
      • 适合于需要“自定义规则”的场合
    • 规则系统
      • 在解释器基础上增加了经验规则
      • 适合专家系统
      • 组成结构
        • 规则集
        • 规则解释器
        • 规则/数据选择
        • 工作内存
      • 一般用在人工智能领域和DSS（决策支持系统）中
  • 缺点
    • 复杂度高
  • 示例
    • JAVA虚拟机
• 以数据为中心
  • 子风格
    • 数据库系统（仓库风格）
      • 以数据为中心
    • 黑板系统
      • 示例
        • 语音识别
        • 知识推理
        • 模式识别
        • 图像处理
      • 基于数据库系统，增加了触发机制，有信息交互的功能，使用中心数据触发业务逻辑部件
      • 优点
        • 可更改性和可维护性
        • 可重用的知识源
        • 容错性和健壮性
      • 缺点
        • 测试困难
        • 难以建立好的控制策略
        • 低效
        • 开发困难
        • 缺少并行机制
    • 超文本系统
• 闭环控制架构
  • 适合嵌入式系统，用于解决简单闭环控制问题
  • 属于过程控制架构风格
  • 示例
    • 空调控温
    • 定速巡航
• C2架构风格
  • 基本规则
    • 构件和连接件都有一个顶部和一个底部
    • 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连
    • 一个连接件可以和任意数目的其他构件和连接件连接
    • 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部
• MDA
  • 模型驱动架构
    • 使用模型完成软件的分析、设计、构建、部署、维护等开发活动
    • 形式化开发方法
  • 模型
    • 客观事务的抽象表示
  • 主要目标
    • 可移植性
    • 互通性
    • 可重用性
  • 3种核心模型
    • 平台独立模型PIM
      • 具有高抽象层次、独立于任何实现技术的模型
    • 平台相关模型PSM
      • 为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型
      • PIM会变换成一个或多个PSM
    • 代码Code
      • 用源代码对系统的描述，每个PSM都将被变换成代码
• 特定领域软件架构（DSSA）
  • 定义：以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。
  • 类型
    • 垂直域
      • 相同领域，深入
    • 水平域
      • 不同领域，平移
  • 参与人员
    • 领域专家
      • 主要任务：提供关于领域中系统的需求规约和实现的知识
    • 领域分析人员
    • 领域设计人员
    • 领域实现人员
  • 基本活动及产出物
    • 领域分析
      • 建立领域模型
    • 领域设计
      • 获取DSSA
    • 领域实现
      • 开发和组织可复用信息
  • 建立过程
    • 定义领域范围
    • 定义领域特定的元素
    • 定义领域特定的设计和实现需求约束
    • 定义领域模型和架构
    • 产生、搜集可复用的产品单元
    • 并发的、递归的、反复的、螺旋型的
  • 三层次模型
    • 领域开发环境
      • 领域架构师
      • 共性
    • 领域特定的应用开发环境
      • 应用工程师
      • 特性，定制化开发
    • 应用执行环境
      • 操作员