恰如其分的软件架构

恰如其分的软件架构 思维导图，系统设计，以及对性能、安全和可扩展性等系统质量所产生的影响；对系统恰如其分地施加约束，以便系统获得我们所需质量属性的一门艺术。

恰如其分的软件架构

• 软件架构
  • 定义
    • 系统设计，以及对性能、安全和可扩展性等系统质量所产生的影响
    • 解释系统所需的结构体集合，包括软件元素、元素间的相互关系，以及二者各自的属性
    • 对系统恰如其分地施加约束，以便系统获得我们所需质量属性的一门艺术
      • 不做什么与能做什么同等重要
  • 场景
    • 解空间小
      • 可行的解决方案后选项少
    • 失败风险高
    • 质量要求高
    • 领域新
    • 产品系列化
  • 三个层次
    • 架构无关
      • 不考虑架构，不刻意挑选架构（其实实现还是有架构的）
    • 专注架构
      • 审慎地挑选架构
    • 提升架构
      • 更为严格的“专注架构”
      • 以保证系统的某一目标或属性为目标去设计架构
      • 目标或属性已被架构保证，具体开发者开发具体模块时可以不再考虑
• 风险驱动模型
  • 风险
    • 察觉到失败的概率×察觉到的影响
  • 只针对察觉到的风险建立有限的架构模型
  • 付出的努力应该与风险相称
    • 风险小就可以不用在前期设计的那么详细
  • 步骤
    • 识别风险，排定优先级
    • 选择并运用一组技术
    • 评估风险降低的程度
  • 局限性
    • 难以识别所有风险
    • 难以准确衡量风险的优先级
    • 接受局限性，做出恰如其分的设计
• 基本概念
  • 模型（建模）
    • 简单问题
      • 无需抽象即可解决
    • 复杂问题
      • 现实世界的问题在抽象模型中体现
      • 在建模领域中解决问题
      • 将解决方案映射回现实世界
    • 对细节进行取舍，简化模型能够增强推理能力
    • 从一个较小的模型开始进行并不完善的推理是必要的，完整系统太大难以分析
    • 先决定解决什么问题，再确定适合的模型
  • 不变量
    • 那些永恒为真的断言（约束）
  • 关系
    • 指定
      • 确保在不同模型中，相似元素互为对应关系
    • 细化
      • 相同模型在底层细节和高层细节之间的关系
    • 视图（投影）
      • 显示了模型的细节子集，包括了细节之间的转换
      • 可以形象的理解为，从某个角度观察模型，或从某个过程观察模型
    • 分割和组合
    • 分类和泛化
      • 泛化就是把多个子类型归入一个更通用的超类型
    • 封装
      • 分离元素的实现和接口
      • 与外部交互时可以只关心接口，忽略内部细节，简化分析难度
    • 嵌套
      • 元素内部可以由更小的元素组成
    • 绑定
      • 必须遵循的模式
    • 依赖
      • 当一个模块发生变化时，另一个模块也会发生变化
    • 
• 软件架构的概念模型
  • 领域模型
  • 设计模型
  • 代码模型
  • 
• 领域模型
  • 表达某一领域永恒的事实
  • 对现实领域的一种简化
  • 视图
    • 成员定义及属性
    • 成员间的关系
    • 成员间交互的场景
    • 可以分多种视图来呈现
• 设计模型
  • 边界模型
    • 对接口的承诺，不呈现实现细节
    • 包括系统的行为，系统和外部交互的数据，以及系统的质量属性
  • 内部模型
    • 对边界模型的细化，呈现更多实现细节
  • 质量属性
    • 没有代码可以直接负责质量，质量是从架构和设计中逐渐浮现出来的
    • 质量可能比较难量化，但是可以排优先级，有冲突时可以决定优先保证谁
  • 视图
    • 用例图
      • 体现功能，以及活动者与之交互的关系
      • 定时器是一种特殊的活动者
      • 展示系统可以做什么，不关心执行顺序
      • 可以用活动图展现用例的合法执行顺序
      • 
    • 系统上下文图
      • 体现与外部的通信关系
      • 连接器
        • 通信通道
      • 端口
        • 与通信通道交互的接口
      • 

恰如其分的软件架构

• 软件架构
  • 定义
    • 系统设计，以及对性能、安全和可扩展性等系统质量所产生的影响
    • 解释系统所需的结构体集合，包括软件元素、元素间的相互关系，以及二者各自的属性
    • 对系统恰如其分地施加约束，以便系统获得我们所需质量属性的一门艺术
      • 不做什么与能做什么同等重要
  • 场景
    • 解空间小
      • 可行的解决方案后选项少
    • 失败风险高
    • 质量要求高
    • 领域新
    • 产品系列化
  • 三个层次
    • 架构无关
      • 不考虑架构，不刻意挑选架构（其实实现还是有架构的）
    • 专注架构
      • 审慎地挑选架构
    • 提升架构
      • 更为严格的“专注架构”
      • 以保证系统的某一目标或属性为目标去设计架构
      • 目标或属性已被架构保证，具体开发者开发具体模块时可以不再考虑
• 风险驱动模型
  • 风险
    • 察觉到失败的概率×察觉到的影响
  • 只针对察觉到的风险建立有限的架构模型
  • 付出的努力应该与风险相称
    • 风险小就可以不用在前期设计的那么详细
  • 步骤
    • 识别风险，排定优先级
    • 选择并运用一组技术
    • 评估风险降低的程度
  • 局限性
    • 难以识别所有风险
    • 难以准确衡量风险的优先级
    • 接受局限性，做出恰如其分的设计
• 基本概念
  • 模型（建模）
    • 简单问题
      • 无需抽象即可解决
    • 复杂问题
      • 现实世界的问题在抽象模型中体现
      • 在建模领域中解决问题
      • 将解决方案映射回现实世界
    • 对细节进行取舍，简化模型能够增强推理能力
    • 从一个较小的模型开始进行并不完善的推理是必要的，完整系统太大难以分析
    • 先决定解决什么问题，再确定适合的模型
  • 不变量
    • 那些永恒为真的断言（约束）
  • 关系
    • 指定
      • 确保在不同模型中，相似元素互为对应关系
    • 细化
      • 相同模型在底层细节和高层细节之间的关系
    • 视图（投影）
      • 显示了模型的细节子集，包括了细节之间的转换
      • 可以形象的理解为，从某个角度观察模型，或从某个过程观察模型
    • 分割和组合
    • 分类和泛化
      • 泛化就是把多个子类型归入一个更通用的超类型
    • 封装
      • 分离元素的实现和接口
      • 与外部交互时可以只关心接口，忽略内部细节，简化分析难度
    • 嵌套
      • 元素内部可以由更小的元素组成
    • 绑定
      • 必须遵循的模式
    • 依赖
      • 当一个模块发生变化时，另一个模块也会发生变化
    • 
• 软件架构的概念模型
  • 领域模型
  • 设计模型
  • 代码模型
  • 
• 领域模型
  • 表达某一领域永恒的事实
  • 对现实领域的一种简化
  • 视图
    • 成员定义及属性
    • 成员间的关系
    • 成员间交互的场景
    • 可以分多种视图来呈现
• 设计模型
  • 边界模型
    • 对接口的承诺，不呈现实现细节
    • 包括系统的行为，系统和外部交互的数据，以及系统的质量属性
  • 内部模型
    • 对边界模型的细化，呈现更多实现细节
  • 质量属性
    • 没有代码可以直接负责质量，质量是从架构和设计中逐渐浮现出来的
    • 质量可能比较难量化，但是可以排优先级，有冲突时可以决定优先保证谁
  • 视图
    • 用例图
      • 体现功能，以及活动者与之交互的关系
      • 定时器是一种特殊的活动者
      • 展示系统可以做什么，不关心执行顺序
      • 可以用活动图展现用例的合法执行顺序
      • 
    • 系统上下文图
      • 体现与外部的通信关系
      • 连接器
        • 通信通道
      • 端口
        • 与通信通道交互的接口
      •