软件架构设计：程序员向架构师转型必备（第2版）

这是一篇关于软件架构设计：程序员向架构师转型必备（第2版）的思维导图，主要内容包括：第11章 架构验证，第1章 从程序员到架构师，第4章 架构设计过程，第8章 确定关键需求，第7章 领域建模，第6章 用例与需求，第5章 需求分析，第2章 解析软件架构概念，模块划分专题 (自顶向下vs.自底向上，垂直切分vs.水平切分)，第3章 理解架构设计视图，第10章 细化架构设计，第9章 概

软件架构设计：程序员向架构师转型必备（第2版）

• 第9章 概念架构设计
  • 针对重大需求、特色需求、高风险需求，形成稳定的高层架构设计成果
  • 概念架构“是什么”？
    • Dana Bredemeyer等专家定义
      • 概念架构满足“架构=组件+交互”的基本定义，仅关注高层组件（high-level components）。
      • 对高层组件的“职责”进行了笼统的界定（informal specification），并给出了高层组件之间的相互关系（Architecture Diagram）。
      • 不应涉及接口细节（withoutinterface detail）。
    • 实践定义：直指系统目标的设计思想、重大选择
      • 直指目标
        • 能够跨平台、跨产品复用软件模块；
        • 避免不同产品之间的代码复制、反复开发和版本增殖问题。
      • 设计思想
        • 应用层、服务层、ECU 抽象层、微控制器抽象层的分离
        • RTE（Runtime Environment）构件运行环境,构件生命周期、运行、通信管理
      • 重大选择
        • 在集中式、分布式上，AUTOSAR选择了分布式架构
        • 复杂设备驱动的设计选择的是“一体化”
      • 汽车电子AUTOSAR——跨平台复用
  • 概念架构“长什么样”？
  • 概念架构设计
    • “关键需求进，概念架构出”的过程
      • 针对关键功能，运用鲁棒图进行设计
      • 针对关键质量，运用目标—场景—决策表设计
    • 概念架构≠理想化架构
      • 单纯采用功能需求驱动的方式（理想化架构）
    • 概念架构≠细化架构
      • 比较策略化而未必全面
      • 比较强调重点机制的确定而不一定非常完整
  • 概念架构“怎么设计”？
    • 从功能需求向设计过渡
      • 用例规约向设计概念过渡困难
        • · 用例是面向问题域的，设计是面向机器域的，这两个“空间”之间存在映射；
        • · 用例技术本身不是面向对象的，而设计应该是面向对象的，这是两种不同的思维方式；
        • · 用例规约采用自然语言描述，而设计采用形式化的模型描述，描述手段也不同。
    • 从质量需求向设计过渡
      • 使笼统的非功能目标明确化
        • “本系统应该具有较高的高性能”等寥寥几个字来直接做设计，“思维跨度”就太大了，设计很难有针对性。
    • 1.针对功能需求的设计：鲁棒图建模技术
      • 鲁棒图“是什么”
        • 由Ivar Jacobson于1991年发明
        • 用以回答“每个用例需要哪些对象”的问题
        • 初步设计 + 检查用例规约是否正确和完善了
      • 鲁棒图“画什么”
        • 3种元素
          • 边界对象
            • 对模拟外部环境和未来系统之间的【交互】进行建模
            • 负责接收外部输入、处理内部内容的解释、并表达或传递相应的结果
          • 控制对象
            • 对【行为】进行封装，描述用例中事件流的控制行为
          • 实体对象
            • 对【信息】进行描述，它往往来自领域概念，和领域模型中的对象有良好的对应关系
        • 从一个个用例规约等功能需求描述着手，基于鲁棒图建模术，不断发现场景背后应该有哪些不同的职责
          • 研究功能如何和外部 Actor 交互而发现边界对象
          • 研究功能实现需要的行为而发现控制对象
          • 研究实现功能所需要的必要信息而发现实体对象
      • 鲁棒图“怎么画”
        • 增量建模
          • 建模过程
            • 识别最“明显”的职责
            • 开始考虑职责间的关系，并发现新职责
            • 继续考虑职责间关系，并发现新职责
          • 用“不断完善”的方式，把各种必要的职责添加进鲁棒图的过程
          • “不断完善”是靠设计者问自己问题来驱动的，用例规约定义的各种场景是“输入”
    • 2.针对质量需求的设计：目标—场景—决策表
      • 场景思维
        • 一种将笼统需求明确化的需求刻画技术
      • 场景思维的工具
        • 场景卡
        • 目标—场景—决策表
        • 要考虑的场景评估因素包括：价值大小、代价大小、开发难度高低、技术趋势、出现几率等。
  • 概念架构设计实践要领
    • 要领1：功能需求与质量需求并重
    • 要领2：概念架构设计的1个决定、4个选择
      • 决定
        • 如何划分顶级子系统
      • 选择
        • 架构风格选型。
        • 开发技术选型。
        • 二次开发技术选型。
        • 集成技术选型。
    • 要领3：备选设计
      • 为什么要这样设计？
      • 有没有其他设计方式?
    • 实际应用——PM Suite贯穿案例之概念架构设计
      • 第1步：通过初步设计，探索架构风格和高层分割 （对一组“关键功能”进行了探索性的初步设计）
        • 首先，识别你认为最“明显”的职责
        • 接下来，开始考虑职责间的关系、并发现新职责，不断迭代
        • 再继续迭代，考虑职责间关系；发现新职责；增量地建模
        • 增量建模技巧的“哲学”是：先把显而易见的设计明确下来，使模糊的设计受到最大程度的启发。
      • 第2步：选择架构风格，划分顶级子系统
        • 思维过程，用“目标-场景-决策表”可以更清晰地刻画
      • 第3步：开发技术、集成技术与二次开发技术的选型
      • 第4步：评审3个备选架构，敲定概念架构方案
• 第10章 细化架构设计
  • 每个视图都是从特定角度规划系统的分割与交互，都是（架构的定义）“组件+交互”的一种体现
  • 5视图方法
    • 职责划分（逻辑视图）
      • 设计手段举例：分模块、分层、划分垂直功能子系统，为模块/层/子系统定义接口……
    • 程序单元组织（开发视图）
      • 设计手段举例：开发语言选型、Application Framework选择、编译依赖关系……
    • 控制流组织（运行视图）
      • 设计手段举例：多进程技术、多线程技术、中断服务程序……
    • 物理节点安排（物理视图）
      • 设计手段举例：PC机、服务器、单片机的选型与互联……
    • 持久化设计（数据视图
      • 设计手段举例：关系数据库、实时数据库、文件、Flash……
  • 5个视图、15个设计任务
    • 逻辑架构=模块划分+接口定义+领域模型
      • 模块划分
        • · 从需求层面的“功能树”，启发“功能模块”的划分。
        • · 水平分层，促进模块分解。
        • · 通用模块和通用机制的识别。
        • · 现代的用例驱动的模块划分过程。
        • · 传统的模块化思维。
      • 接口定义
        • 协作决定接口
      • 领域模型细化
    • 开发架构=技术选型+文件划分+编译关系
      • 各种开发技术选型
        • 一是选定开发语言
        • 二是选择开发工具
        • 三是选择程序库（Library）和框架（Framework）
      • 程序文件划分到具体工程（Project）
      • 程序文件之间的编译依赖关系
    • 物理架构=硬件分布+软件部署+方案优化
    • 运行架构=技术选型+控制流划分+同步关系
      • 并发技术选型
        • 进程
        • 线程
        • 中断服务程序
      • 控制流划分
      • 控制流间同步关系
    • 数据架构=技术选型+存储格式+数据分布
      • 持久化技术选型
      • 数据存储格式
      • 数据分布策略
• 第11章 架构验证
  • 原型技术
    • 水平原型vs.垂直原型
    • 抛弃原型vs.演进原型
  • 架构验证
    • 原型法
      • 垂直演进原型
    • 框架法
      • 架构设计方案用框架的形式实现
    • 测试运行期质量，评审开发期质量
• 模块划分专题 (自顶向下vs.自底向上，垂直切分vs.水平切分)
  • 功能树
    • 需求分析的成果
    • 确定系统必须具有的各项功能（Function）与特性（Feature）
    • 功能相近的一组用例一般被划分到了同一个“功能模块”
    • 从“功能组”到“功能模块”
      • 第1步：获得功能树
      • 第2步：评审功能树
        • · 一是面向使用，体现使用价值
        • · 二是覆盖全面，没有范围遗漏
        • “定义良好”的功能树
      • 第3步：粗粒度“功能模块”划分
  • 分层架构
    • 设计思想：分层架构的“封装外部交互”思想
    • 实践技巧：设计分层架构，从上下文图开始
      • 【从需求】上下文图
      • 【到设计】如何分层
  • 用例驱动
    • 描述需求的序列图vs.描述设计的序列图
      • 描述“内外对话”
      • 描述“内部协作”
    • 核心原理：从用例到类，再到模块
      • 两环节、四步骤
        • 需求分析环节
          • 1.用例图定义系统能提供给外部Actor的功能
          • 2.用例规约（用例图可不够）进一步将笼统的“功能”明确定义为“能够为用户带来价值的交互序列”
        • 架构设计环节
          • 1.打破“黑盒”，识别一个用例背后有哪些类，以及设计类之间的交互
          • 2.梳理通过多个用例识别出的这些类，并将它们划分到不同模块
    • 用例驱动的模块划分过程
      • 第1步：实现用例需要哪些类
        • 【技术1】运用鲁棒图，发现实现用例需要哪些类
          • 识别最“明显”的职责
          • 开始考虑职责间的关系，并发现新职责
          • 继续考虑职责间关系，并发现新职责
          • 继续同样的思维方式
        • 【技术2】运用序列图，明确类之间的交互关系
          • 先大局、后细节
          • “分层次”地步步推进建模
      • 第2步：这些类应该划归哪些模块
        • “从好多类，到少数模块”的设计思维过程，一种“归纳”思维，自底向上思考
  • 世上之事的决策，有着两种迥然不同的方法：借助经验和推理分析。 根据功能树切分功能模块和分解上下文图进行分层，大刀阔斧，偏重经验。属前者。 用例驱动的设计方法，密密而织，偏重分析。属后者
  • 模块化
    • 封装驱动设计的4个步骤
      • 【技能项】分层细化
        • 在粗粒度层内进一步“封装”职责形成更细致的层次结构，国外有的专家称之为 Sub-layer
      • 【技能项】分区
        • 将“层”内支持不同功能组的职责分别“封装”到“细粒度模块”中，从而使每个“粗粒度功能模块”由一组位于不同“层”的“细粒度模块”组成。
      • 【技能项】通用模块的分离
        • 模块化和通用模块的分离
      • 【技能项】通用机制的框架化
        • 划分模块时，应将通用机制框架化
        • 机制
          • 软件系统中的机制，是预先定义好的、能够完成预期目标的、基于抽象角色的协作方式
          • 包含了协作关系，同时也包含了协作流程
          • “协作”是“多个对象为完成某种目标而进行的交互”
          • “机制”是特殊的“协作”，只有那些基于抽象角色的协作才算得上机制
            • 基于接口（和抽象类）的协作是机制，基于具体类的协作则算不上机制。
        • 框架
          • 通过某种回调机制进行扩展的软件系统或子系统的半成品
          • 框架的智慧就在于此：为了追求重用所带来的价值量最大化，将容易变化的部分封装成扩展点，并辅以回调机制将它们纳入框架的控制范围之内，从而在兼顾定制开销的同时使被重用的设计成果最多。
          • 划分模块时，应将通用机制框架化
          • 软件框架的具体例子
            • 数据库管理机制
            • 事件通知机制
            • 事务服务机制
            • 权限确认机制
          • 软件单元的粒度越大，则重用所带来的价值量越大，但重用几率越小； 反之，粒度小的软件单元被重用的几率大，但重用所带来的价值量小
• 第8章 确定关键需求
  • 什么决定了架构
    • 用例驱动论
      • 需求=功能+质量+约束
      • 用例是功能需求实际上的标准
      • 用例涉及、但不能全面涵盖非功能需求
    • 质量决定论
    • 经验决定论
  • 关键需求决定架构
    • “目标错误”比“遗漏需求”更糟糕
    • 关键需求决定架构，其余需求验证架构
  • 如何确定关键需求
    • 确定关键质量
      • 提高哪些方面的质量属性要求
      • 考虑这些质量属性的相互制约或相互促进关系
      • 必须满足各种约束性需求
    • 确定关键功能
      • 核心功能
      • 必做功能
      • 高风险功能
      • 独特功能
      • 涉及（或串起）的模块最多、协作方式最有代表性的功能需求
• 第7章 领域建模
  • 什么是领域模型
    • 领域模型“是什么”
      • 将领域概念（即领域行话）以可视化的方式抽象成一个或一套模型
    • 领域模型“什么样”
      • 类图
      • 状态图
    • 领域模型“为什么”
      • 为需求定义提供了领域知识和领域词汇
      • 软件界面的设计往往和领域模型关系密切
      • 领域模型是否合理将严重影响软件系统的可扩展性
  • 领域模型的作用
    • 需求人员视角
      • 领域建模与需求分析的关系
      • 促进用户沟通、解决分析瘫痪
        • 第一个困难：用户的参与不够，造成需求分析成果中假设的成分太多。
        • 第二个困难：问题领域太复杂时，需求分析的开展会遇到困难。
    • 开发人员视角
      • 破解“领域知识不足”死结
        • 领域模型作为“理解领域的手段”
        • 理顺概念关系、搞清业务规则
        • 对复杂的领域进行“概念抽象”和“关系抽象”建立模型
    • 功能决定如何建模，模型决定功能扩展
• 第6章 用例与需求
  • 用例技术族
    • 用例图
      • 从总体上反映了【用户需求】
    • 用例简述（用户故事）
      • 【行为需求】的简化描述
    • 用例规约
      • 描述系统的【行为需求】，但属“规格级”详述
    • 用例实现（鲁棒图）
      • 属于设计范畴，确切地讲是【初步设计】
  • 需求分析的三套实践论
    • 小型方法
    • 中型方法
    • 大型方法
• 第5章 需求分析
  • 需求怎么来的？ （需求开发=愿景分析+需求分析）
    • 愿景分析
      • 愿景=业务目标+范围+Feature+上下文图
      • 业务目标、范围、Feature、上下文图的关系
    • 需求分析
      • 需求捕获
        • 是获取知识的过程
      • 需求分析
        • 挖掘和整理知识的过程
        • 搞清楚软件系统要“做什么”
      • 系统分析
        • 涉及“怎么做”的问题
  • 如何判断掌握的需求全不全？ （功能、质量、约束三类需求都不能漏）
    • 需求层次-需求方面矩阵 （ ADMEMS）
      • 需求层次
        • 组织级需求
        • 用户级需求
        • 开发级需求
      • 需求方面
        • 功能需求：更多体现各级直接目标要求
        • 质量属性：运行期质量+开发期质量
        • 约束需求：业务环境因素+使用环境因素+构建环境因素+技术环境因素
  • 从需求向设计转化的关键思维是什么？ （功能、质量、约束影响架构的不同原理是核心）
    • 功能：职责协作链
      • 通过为功能规划职责协作链来发现职责
      • 再将职责分配到子系统等软件单元中去
      • 后续就可以定义接口
      • 确定协作方式
    • 质量：完善驱动力
    • 约束：设计并不自由
      • 直接制约设计决策的约束
      • 转化为功能需求的约束
      • 转化为质量属性需求的约束
  • 需求分析主线中的关键步骤： 三横两纵
    • 三横
      • 确定系统目标
      • 研究高层需求
        • 【技能1】高层需求之确定范围
        • 【技能2】高层需求之定义Feature
        • 【技能3】高层需求之画上下文图
      • 建立用例模型
        • 画用例图
        • 写用例规约
      • 有先后之分
    • 两纵
      • 需求沟通、需求启发、需求验证
      • 确定非功能需求
      • 实践中需要持续不断地进行
• 第4章 架构设计过程
  • 3个原则
    • 看透需求
      • “需求”和“领域模型”
    • 架构大方向正确
      • 正确的概念架构
    • 设计好架构的各个方面
      • 多视图方法“细化架构”， 通过“架构原型”验证架构
  • 6个步骤
    • （1）需求分析
    • （2）领域建模
    • （3）确定关键需求
    • （4）概念架构设计
    • （5）细化架构设计
    • （6）架构验证
• 第3章 理解架构设计视图
  • 设计架构时，架构视图为什么必不可少？
    • 架构师应当为项目相关的不同角色而设计
      • 为“上游”客户负责，满足他们的业务目标和约束条件；
      • 为“上游”用户负责，使他们关心的功能需求和运行期质量属性得以满足；
      • 必须顾及处于协作分工“下游”的开发人员；
      • 必须考虑“周边”的管理人员，为他们进行分工管理、协调控制和评估监控等工作提供清晰的基础。
    • 要做什么？
      • 同时关注多个架构设计视图。
      • 架构视图的本质是“分而治之”
      • 能帮助架构师从不同角度设计，特别是面对复杂系统时“分而治之”地设计是必需的。
  • 什么是架构视图？
    • 一种设计架构、描述架构的核心手段,考虑软件架构的表达与交流
    • 通过“架构视图”作为分而治之的手段
    • 分别专注于架构的不同方面、相对独立地分析和设计不同“子问题”
    • 在多种架构视图中，最常用的是逻辑架构视图和物理架构视图
  • 如何运用“逻辑视图+物理视图”设计一个系统的架构？
    • 逻辑架构
      • 规定了软件系统由哪些逻辑元素组成以及这些逻辑元素之间的关系
      • 组成软件系统的逻辑元素可以是逻辑层（Layer）、功能子系统、模块
      • 核心任务，是比较全面地识别模块、规划接口，并基于此进一步明确模块之间的使用关系和使用机制
    • 物理架构
      • 规定了组成软件系统的物理元素，这些物理元素之间的关系，以及它们部署到硬件上的策略
      • 反映出软件系统动态运行时的组织情况
        • “物理元素”就是进程、线程，以及作为类的运行时实例的对象等，而进程调度、线程同步、进程或线程通信等则进一步反映物理架构的动态行为。
    • 从“逻辑架构+物理架构”到设计实现
      • 架构设计，指导后续的详细设计和编程；而详细设计和编程，贯彻和利用这些设计
      • 辅以分而治之、迭代式设计两个技巧
        • 【分而治之】
          • 逻辑架构进行“逻辑分解”
          • 物理架构进行“物理分解”
          • 分别关注架构的不同方面，利于思维聚焦（相当于化“大问题”为“子问题”）
        • 【迭代式设计】
          • 不同架构视图的设计交替进行、迭代展开
          • 逻辑职责的划分逐步清晰，促进了物理分布设计,反之亦然
• 第2章 解析软件架构概念
  • 软件架构概念的分类
    • 组成派： 架构=组件+交互
      • 将系统描述为计算组件及组件之间的交互
      • 计算组件
        • 处理组件
        • 数据组件
        • 连接组件
      • “组件”可以指子系统、框架（Framework）、模块、类等不同粒度的软件单元，它们可以担负不同的计算职责。
      • （1）关注架构实践中的客体——软件，以软件本身为描述对象； （2）分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算。
    • 决策派： 架构=一组重要决策
      • 软件系统的组织
      • 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为
      • 如何组合这些元素，使它们逐渐合成为更大的子系统
      • 用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合。
      • 软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。
      • （1）关注架构实践中的主体——人，以人的决策为描述对象； （2）归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能需求的决策。
  • 概念思想的解析
    • 软件架构关注分割与交互
      • 架构设计是分与合的艺术
      • 架构=组件+交互，组件和组件之间有交互关系
    • 软件架构是一系列有层次的决策
      • 切分类决策
      • 技术选型类决策
    • 系统、子系统、框架都可以有架构
      • 由组件递归组合而成
• 第1章 从程序员到架构师