软件体系结构和系统设计

发表于 | 分类于

什么是软件架构

SEL: 软件架构是整个程序或计算系统的结构，包含了程序的元素和外部可见的元素属性，以及它们之间的关系。

软件架构做什么

  • 架构定义了结构：组件接口、组件的交流和依赖、组件的职责
  • 架构定义了组件的交流：数据传输机制、控制流
  • 架构传达了NFRs：技术约束、商业约束、质量约束
  • 架构是设计的高层抽象视图

PS:

  • 联系
  • 软件工程
  • 技术知识
  • 风险管理

软件架构如何而来

  • 需求
  • 商业和技术决定的集合
  • 受以下因素影响：
    • 系统利益相关址
    • 开发组织
    • 架构师
    • 系统环境

架构的视图

  • 逻辑视图：定义了必要的元素和关系
  • 进程视图：描述了元素间的交流、依赖
  • 物理视图：进程和元素到硬件的映射
  • 开发视图：捕捉软件内部组件的组织
  • 架构用例：描述了架构的需求

架构活动过程

  • 活动
    • 为软件创造商业用例
    • 理解需求
    • 设计选择架构
    • 与利益相关者交流架构
    • 分析评估架构
    • 实现架构
    • 保证一致性
  • 四大步骤
    • 发现ASRs
    • 架构设计
    • 完成视图和文档
    • 架构评估
  • 生命周期
    • 架构设计
    • 架构合成
    • 架构评估
    • 架构实现
    • 架构维护

架构知识领域

  • 软件设计基础概念
    • 设计概念常识
    • 上下文：软件开发生命周期：需求、设计、构造\测试
    • 设计过程
    • 在设计中使用技术
  • 关键点
    • 并发、控制和处理时间，分布式，异常处理，交互系统，持久化
  • 软件的结构和架构
    • 架构的结构和观点
    • 架构的模式和风格
    • 设计模式
  • 软件设计方法
    • 架构方法：ADD
    • 设计方法：DSDM
  • 软件设计质量分析和评估
    • ATAM
  • 设计模块化和展示
    • UML

为何架构十分重要

  • 提供交流的途径
  • 显示最早的设计决策
  • 促进质量属性的实现
  • 影响质量
  • 讨论潜在变化
  • 将变化分为三类：local, non-local, architectural
  • 是透明和可复用的抽象
  • 是产品通用的基础

选件要求

  • 功能需求
    • 功能需求描述了如何给利益相关者产生价值
    • 功能需求描述了系统的职责
  • 质量需求
    • 质量需求用于检验功能需求以及整个系统的质量
  • 约束
    • 约束描述了设计中零自由度的决策

场景

  • stimulus
  • source
  • response
  • response measure
  • artifact
  • environment

质量属性设计决策的7大分类

  • Allocation of responsibilities
  • Coordination model
  • Data model
  • Management of resources
  • Mapping among architectural elements
  • Binding time decisions
  • Choice of technology

质量属性

  • Availability
    • 发现错误的时间
    • 修正错误的时间
    • 重启应用的时间
  • Interoperability
    • 系统之间通过接口交换信息的属性，包括交换和正确理解信息
  • Modifiability
    • 评估一个更改要消耗的时间和金钱
  • Performance
    • 关于系统满足时间要求的能力
    • 处理时间和阻塞时间
  • Security
    • 关于系统保证信息和数据安全的能力
  • Testability
    • 关于系统能否通过测试证明出错的能力
  • Usability
    • 用户完成某一项任务的容易性

Availability Tactics

  • 发现错误
  • 从错误恢复
  • 防止错误

Interoperability Tactics

  • 服务定位
  • 服务管理

Modifiability Tactics

  • 减少模块大小
  • 提高内聚
  • 减少耦合
  • 延迟绑定

Performance Tactics

  • 控制资源需求
  • 资源管理

Security Tactics

  • 攻击检测
  • 攻击抵抗
  • 攻击反应
  • 攻击恢复

Testability Tactics

  • 控制和观察系统状态
  • 限制复杂度

Usability Tactics

  • 支持用户自发操作：暂停
  • 支持系统自发操作：维护任务模式

如何获取ASRs

  • 从需求文档中获取
  • 从利益相关人员获取
  • 理解商业目标
  • 从质量属性效用树中获取

特定域软件体系结构DSSA

什么是架构模式pattern

  • 是在不断尝试中找到的一种设计的集合
  • 可复用
  • 一种架构的类别
  • 包括：上下文、问题和解决方案

Model patterns

  • 分层模式
    • 上下文：层，只能访问下层
    • 优点：
      • 逻辑分离
      • 限制数据暴露
    • 缺点：
      • 添加层会增加成本和系统复杂度
      • 影响性能

Component-Connector patterns

  • 代理模式
    • 上下文：服务器、客户端、中间人、服务器代理、客户端代理，客户端和服务器通过代理提供接口，通过中间人交流
    • 优点：
      • 服务位置透明
    • 缺点：
      • 提高复杂度
      • 导致单点失效
      • 成为攻击对象
      • 难以测试
  • MVC模式
    • 上下文：model、view、controller
    • 优点：
      • 视图层修改方便
    • 缺点：
      • 复杂度高不适用于简单界面
      • 不支持一些高级界面工具
  • 管道过滤模式
    • 上下文：管道、过滤器，管道的输出是过滤器的输入，反之亦然
    • 优点：
      • 将复杂任务分开，方便部署计算密集型任务
      • 复杂任务分解，提高复用
    • 缺点：
      • 不适合内部交互系统
      • 大量独立的过滤器导致大量计算开销
      • 不适合长时间计算
  • 客户端服务器模式
    • 上下文：客户端、服务器，客户端连接服务器
    • 优点：
      • 满足个性化要求
    • 缺点：
      • 服务器可能成为瓶颈
      • 服务器可能单点失效
      • 功能放置在客户端还是服务器的决策复杂并且难以修改
  • 点对点模式
    • 上下文：peer，独立运行，通过request／reply连接其他peer
    • 优点：
      • 资源分散，无需中间环节，避免性能瓶颈
    • 缺点；
      • 管理安全、数据持久化、数据／服务可用性、备份和恢复的复杂度提高
      • 小型对等网络难以一直保持性能和可用性
  • 面向服务模式
    • 上下文：
      • 组件：服务提供者、服务消费者、服务、ESB、注册中心
      • 连接件：SOAP、REST、异步信息连接
    • 优点：
      • 从已有的服务上建立商业过程，组件复用和解耦
    • 缺点：
      • 复杂难以实现
      • 难以控制独立服务的演化
      • 服务和中间件成为性能的瓶颈
  • 发布订阅模式
    • 上下文：任何C&C组件都有发布订阅模式，订阅消息的组件会收到发布消息的组件的信息
    • 优点：
      • 降低耦合
    • 缺点：
      • 提高延迟，降低可量测性，难以预测信息的分发时间
      • 分发信息不能保证
  • 共享数据模式
    • 上下文：共享数据存储、数据访问组件、数据读写连接件
    • 优点：
      * 提供统一接口方便操作
      • 缺点：
        • 共享数据存储模块成为性能瓶颈
        • 共享数据存储模块单点失效
        • 生产者和消费者的耦合

Allocation patterns

  • 多链模式
    • 上下文：tier，软件组件的逻辑分组，is part of将组件分入tier，communicate with是tier之间的交流，allocate to是tier映射到计算平台
    • 优点：
      • 分离组件到层，部署在不同的物理平台
    • 缺点：
      • 大量的开销和复杂度
  • 映射归纳模式
    • 上下文：map、reduce
    • 优点：
      • 为并行计算提供框架，提高运行速度
    • 缺点：
      • 如果数据集合不够大，将没有理由使用
      • 如果不能将数据集合划分为大小相近的集合，将丧失并行计算的优势
      • 需要多重归纳的操作将难以安排

模式和策略Patterns and Tactics

  • tactics更简单，密度更小
  • patterns包含不同的设计决策
  • patterns和tactics共同构建了整个架构基础的工具
  • tactics是patterns设计的架构的基础材料
  • patterns里的tactics可能是为了一个目的，也可能是不同的目的

设计策略Design Strategy

  • abstraction
  • decomposition
  • divide & conquer
  • generation and test
  • iteration
  • reuse

ADD

  • 确认需求
  • 选择一个元素进行分解
  • 为该元素确认ASRs
    • importance, difficulty
  • 选择符合ASRs的设计理念
    • 确认设计关注点
    • 为次要关注度列出不同的模式／策略
    • 选择合适的模式／策略
    • 决定ASRs和模式／策略之间的关系
    • 获取架构视图
    • 评估并解决不一致问题
  • 列出架构元素，分配职责
  • 为元素定义接口
  • 确认需求，为元素构造约束
  • 重复以上步骤

ADD的输入

  • 功能需求
  • 设计约束
  • 质量属性

ADD的输出

  • 软件元素
  • 角色
  • 职责
  • 特性
  • 关系

为什么要文档化

  • 更好的交流架构设计决定
  • 帮助理解决策
  • 更新设计者关于当前决定的记忆
  • 锻炼设计架构的能力
  • 支持分布式团队

文档化的挑战

  • 没有标准化
  • 大型系统花费时间长
  • 逼近deadline和架构不断变化的性质对文档化有害
  • 注释缺失

文档化的七条原则

  • 以读者的视角完成文档
  • 避免不必要的重复
  • 避免歧义
  • 使用标准组织
  • 记录理由
  • 保持文档接近最新
  • 审查文档保证契合目的

Styles的分类

  • Module style
  • C&C style
  • Allocation style

Style/Pattern/View

  • Style: 元素和关系类型的特化，以及如何使用的约束
    • 不包含上下文和问题
  • Pattern: 软件的基本结构组织模式
    • 关注问题和上下文
  • View: 一些元素的表示和之间的关系

模块视图：强调静态

  • Views:
    • Decomposition View
    • Uses View
    • Generalization View
    • Layered View
    • Aspects View
    • Data model View
  • Elements: 提供一致职责的单元，职责内聚的单元
  • Relations: is part of/depends on/is a
  • Constraints: 不同模块有不同的约束
  • Usage:
    • 代码的蓝图
    • 变更影响分析
    • 计划开发
    • 要求可追踪的分析
    • 联系功能和其基于的代码结构
    • 支持工作分配，执行时间表和预算信息的定义
    • 展示系统需要处理的信息结构

C&C视图：强调动态

  • Views:
    • Pipe-and-filter View
    • Client-server View
    • Peer-to-peer View
    • SOA View
    • Publish-subscribe View
    • Shared-data View
  • Elements: Components(进程和数据) & Connectors(连接Components)，运行时的情况
  • Relations:
    • Attachment依附
    • Interface delegation接口委托
  • Constraints:
    • 组件只能直接依赖于连接件
    • 连接件只能直接依赖于组件
    • 联系只能在兼容的端口和规则下产生
    • 接口委托只能在两个兼容的端口／规则下产生
    • 连接件不能独立存在
  • Usage:
    • 展示系统如何运行
    • 以指定的结构和运行时元素的行为指导开发
    • 帮助解释系统运行时质量属性

分配视图：周围环境

  • Views:
    • Deployment View
    • Install View
    • Work assignment View
    • Other allocation Views
  • Elements: 单元到运行时环境的映射
    • Software element
    • Environmental element
  • Relations:
    • Allocated to
  • Constraints: 因视图而不同
  • Usage:
    • 解释性能、可获得性、安全性
    • 解释分布式开发和团队工作分配
    • 解释并行访问软件版本
    • 解释系统安装的形式与机制

质量视图

  • Views:
    • Security View
    • Performance View
    • Reliability View
    • Communication View
    • Exception View

视图文档化

  • 建立利益相关者／视图的表格
  • 合并视图
    • 确认上面表格中的小视图
    • 找到小视图与更大的视图元素之间的联系以合并视图
  • 优先级和分布
    • 分解视图
    • 80/20原则

视图以外的信息

  • 文档信息：版本控制
  • 文档目录
  • 视图之间的映射

为什么要评估

  • 大型项目经常要迟交
  • 重新设计，大量的返工
  • 提早发现问题
  • 传播架构的最佳实践
  • 为管理层提供更好的技术和项目信息
  • 确定培训能对经常发生的问题产生广泛影响的领域
  • 提高与COTS组件供应者的交互

什么时候评估

  • 获取阶段
  • 演化／更新阶段
  • 设计阶段
  • 构建阶段

评估方法

  • SAAM
  • ALMA
  • PASA
  • ATAM

方法的帮助

  • 识别风险
  • 发现敏感点
  • 发现权衡点

ATAM

  • 评估人员：设计者、伙伴、外界人士
  • 阶段0: 参与者和准备阶段
    • 参与者：评估小组领队和决策者
    • 输入：体系结构文档
    • 输出：评估计划
  • 阶段1: 评估1
    • 参与者：评估小组和决策者
    • 输出：
      • 架构简要报告
      • 商业目标
      • 质量属性和场景
      • 质量属性效用树
      • 风险和非风险
      • 敏感点和权衡点
    • 步骤：
      • 表述ATAM
      • 表述商业动机
      • 表述架构
      • 确定使用的架构方法
      • 生成质量属性效用树
      • 分析架构方法
  • 阶段2: 评估2
    • 参与者：评估小组，决策者和利益相关者
    • 输出：
      • 一个从利益相关者集团来的优先级场景列表
      • 风险、商业动机
    • 步骤：
      • 表述ATAM和先前的结果
      • 头脑风暴，划分场景优先级
      • 分析架构方法
      • 展示结果
  • 阶段3: 后续工作
    • 参与者：评估小组和决策者
    • 输出：
      • 最终评估报告

SPL

  • 很多不同但是相关近似的商品
  • Products：Custom Assets（自定义资产） 和 Core Assets（核心资产）
  • 具有一组可管理的公共特性的软件密集性系统的合集，这些系统满足特定的市场需求或任务需求，并且按预定义的方式从一个公共的核心资产集开发得到

可复用性和可修改性

  • 减少LOC
  • 复用：代码复用是最容易的
  • 变动：让代码更加灵活，现在设计，将来复用
    • 根据市场定义产品线范围
    • 设计PLA符合产品线范围
    • 使用重用和变化机制

PLA

  • 复用：find, understand, and use(invoke)
  • variation:
    • Forms of variation 6
      • 包含或删除元素Include or omit elements
      • 每个元素的可变性Variable number of each element
      • 满足接口Interface Satisfaction
      • 参数化Parameterisation
      • 接口挂钩“Hook” interfaces
      • 反射Reflection
    • Software entity varied 3
      • Architecture level – High-level abstract structures
      • Design level – Lower-level abstract structures
      • File level – low-level concrete source structures
        • Binding time 5
      • Coding-time – when you create a coding workspace
      • Compile-time – when you build object code
      • Link-time – when you create your application
      • Initialization-time – when your application starts
      • Run-time – while your application is running

Produce Line Approach

  • 3 Essential Activities
  • 29 Practice Areas
  • 12(22) Practice Patterns

Software Design Practices

  • transformation step改造步骤
  • elaboration step细化步骤，重组设计模式
  • one transformation step, usually preceded and followed by elaboration steps
  • (de-)composition methods自上而下分解／识别实体
  • organization methods受功能需求影响，尊从非功能需求
  • template-based methods提供标准策略

Incremental Development递增开发

  • RAD快速应用开发（敏捷）
  • DSDM动态系统开发方法
    • MoSCoW
    • Feasibility Study可行性研究，是否适合
    • Business Study商业研究，着眼于业务流程组织
    • Functional Model Iteration功能模型迭代，开发的“黑箱”模型系统
    • Design and Build Iteration设计和构建的迭代，混合“白盒”和原型
    • Implementation phase实现阶段，包括用户培训和评估

SSA／SD结构化系统分析与结构化设计

  • initial DFD（数据流图）描述（上下文图）
  • 分层数据流图
  • Transaction Analysis交易分析，将DFD分为易于理解的单元
  • Transform Analysis变化分析，建立结构图
  • 合并结构图创造基础实现计划

JSP

JSD

(Entity-)Structure diagram, Data-flow stream, State-vector; Modeling, Network, Implementation

Summary

Software Design Practices

  • Design Strategies

    • 在两个transformation step之间由elaboration step优化
    • 低层(de-)composition
    • 基于标准template-based

  • Incremental Design

    • RAD, SDSM：functional model, design & build
  • Structured Systems Analysis and Structured Design(SSA/SD)
    • 前面进行分析
    • 后面进行迭代
    • Structure chart