软件架构设计：程序员向架构师转型必备(第二版) 读书笔记

简介

软件架构

组成派：计算组件及组件之间的交互

• 关注软件架构实践的客体：软件，以软件本身为描述对象
• 分析了软件的组成，即软件由承担不同计算任务的组件组成，组件通过相互交互完成更高层次的计算

决策派：不仅关注软件本身的结构与行为，还关注使用、功能性、性能、弹性、重用、可理解性、经济和技术限制及权衡，以及美学等

• 关注架构实践中的主体：人，以人的决策为描述对象
• 归纳了架构决策的类型，架构决策不仅包括软件系统组织、元素、子系统和架构风格等几类决策，还包括众多非功能需求的决策

架构设计是分与合的艺术

软件架构是一系列有层次的决策：

• 模块如何划分
• 每个模块的职责如何
• 每个模块的接口如何定义
• 模块间采用何种交互机制
• 开发技术如何选型
• 如何满足约束和质量要求
• 如何适应可能发生的变化

架构设计过程是一颗决策树

1 理解需求

2 高层切分：划分子系统

3 N轮切分，进一步分解，划分更小单元

系统、子系统、框架都有架构，软件由组件“递归”而成

架构视图

核心思想：为用户而设计，不仅满足用户要求的功能，还要满足用户期望的质量

为客户设计：考虑客户的业务目标、上线时间要求、时间限制、集成需要等

为开发人员设计：可扩展性、可重用性、可移植性、易理解性、可测试性等软件开发质量属性

为管理人员设计：搞清楚“模块+交互”才能够分工合作

不同的架构视图分别关注不同方面，针对不同实践目标和用途。最常用的是“逻辑架构视图”和“物理架构视图”

架构设计的实现脉络

洞察节奏三原则

• 看透需求
• 架构大方向正确 先设计概念架构
• 设计好架构的各个方面 多视图设计法

架构设计过程

需求分析

• 需求捕获：了解用户或客户希望软件系统在哪些方面提供什么样的帮助 《需求采集卡》
• 需求分析：整理捕获的需求，获得系统、条理和全面的需求，即搞清楚软件系统要“做什么” ，目前主要使用“用例”技术，关注功能需求、质量和约束等方面 《软件需求规格说明书》
• 系统分析：如何实现需求，即“怎么做” 《数据流图、分析类图、鲁棒图、序列图》等

• 功能需求：职责协作链

二维需求观

ADMEMS矩阵

软件研发与交付过程总图

• 质量需求：运行期质量属性和开发期质量属性

质量是完善架构设计的驱动力

• 约束需求:设计不自由

业务环境因素、使用环境因素、构建环境因素、技术环境因素

需求分析主线“三横两纵”：横按顺序进行，纵持续不断进行

• 三横
  • 确定系统目标
  • 研究高层需求
  • 建立用例模型
• 两纵
  • 需求沟通、需求启发、需求验证
  • 确定非功能需求

用例技术：

• 用例图(全,覆盖面)
  • 从总体上反应了用户需求
  • 稳定反应用户级需求
  • 参与者Actor：参与系统交互的角色和系统
  • 用例Use Case：动词，从参与者的角度描述
• 用例简述、用户故事
  • 以文字形式说明用例图的信息
  • 行为需求的简化描述
• 用例规约(深，覆盖点)
  • 行为需求的规格描述
  • 因为精确所以易变
  • 界定软件系统的行为需求
  • 包括简要说明、主事件流、备选事件流、前置条件、后置条件和优先级等
• 用例实现、鲁棒图
  • 用例实现=协作
  • 刻画为了实现用例定义的功能：需要哪些类，类之间的交互关系
  • 初步设计,从功能需求向设计方案的过渡

避免需求遗漏的技巧

• 业务流程
  • 尽可能广泛地勾画可能的业务场景
  • 识别各类型业务步骤：全手工型、IT辅助型、IT全自动型
• 角色找全
  • 需要和哪些外部系统交互
  • 谁使用系统的主要功能
  • 谁需要系统支持他们的日常工作
  • 谁来维护和管理系统
  • 系统操作需要哪些硬件

概念化阶段：

• 愿景分析：解决项目、产品或解决方案的起源问题，针对系统目标、主要特性、功能范围和成功要素进行构思并达成一致 《愿景与范围文档》通常是MRD、PRD、项目立项书

愿景分析=业务目标+范围+Feature+上下文图

刻画高层需求三剑客：

• 风险评估
• 可行性分析
• 项目进度和成本粗略预估

领域建模

业务决定功能，功能决定模型，领域模型精化后作为核心组件

领域模型是公认的促使oo项目成功的最佳实践之一。领域模型是团队交流的基础，常用类图和状态图表示

确定关键需求

架构面前需求是不平等的，关键需求（功能、质量、约束）决定架构，其余需求验证架构

“目标错误”比“遗漏需求”更糟

• 确定关键质量
  • 为了提高开发软件系统的被认可程度，应着重提高哪些方面的质量属性要求
  • 充分考虑质量属性的相互制约或促进关系
  • 满足各种约束条件（经济因素、时间、企业现状、未来发展等）
• 确定关键功能
  • 核心功能
  • 必做功能
  • 高风险功能
  • 独特功能

概念架构设计

概念架构是高层架构工作成果的核心，框定了架构大方向，常被用于《方案建议书》、《系统白皮书》、《宣传彩页》，用于说明产品优势，也被称作”市场架构“

• 如何划分顶级子系统
• 架构风格选型
• 开发技术选型
• 集成技术选型
• 二次开发技术选型

特点：

• 直指目标：以关键需求为目标
• 设计思想：明确设计思想
• 重大选择：进行重大设计选择

方法：

• 针对关键功能，运用鲁棒图进行设计
  • 用例面向问题域，设计面向机器域
  • 用例不面向对象，设计面向对象
  • 用例规约采用自然语言描述，设计采用形式化的模型描述
  • 鲁棒图：边界对象、控制对象、实体对象
  • 增量建模思维方式
• 针对关键质量，运用目标-场景-决策表设计
  • 场景思维：影响来源、如何影响、受影响对象、问题或价值、所处环境

细化架构设计

概念架构没有设计到“模块+接口”一级，细化架构必须关注“模块+接口”

• 5视图法 多视图法不是多阶段实施，不应瀑布式设计视频，而应迭代式同步设计
  • 
  • 逻辑架构：
    • 核心任务：模块划分、接口定义、领域模型细化
      • 识别模块
      • 规划模块的接口
      • 明确模块之间的使用关系和使用机制
    • 静态：包图、类图、对象图
    • 动态：序列图、协作图、状态图、活动图
  • 开发架构：
    • 核心任务：技术选型、文件划分、编译关系
    • 包图、类图、组件图
    • 程序文件划分到具体工程
    • 程序文件之间的编译依赖关系
  • 物理架构：
    • 识别物理元素
    • 识别物理元素之间的关系
    • 物理元素部署到硬件上的策略
    • 核心任务：硬件分布、软件部署、方案优化
  • 运行架构：
    • 核心任务：并发技术选型、控制流划分、同步关系
  • 数据架构：
    • 核心任务：持久化技术选型、数据存储格式、数据分布策略

      架构验证

      架构验证的输出成果是“架构原型”，侧重于将存在“风险”的那些设计尽早开发出来，并通过执行测试等手段判断“风险”是否被解决

  

• 水平原型（行为原型）：用户 交互层界面布局和界面流转逻辑
• 垂直原型（结构原型）：实现某个功能
• 抛弃原型：验证后弃用
• 演进原型：验证后完善作为正式系统的起点

架构验证方法

• 原型法：垂直演进原型，适用于项目型开发
• 框架法：将框架设计方案用框架的形式实现，并在此基础上评估验证，适用于产品型开发生命周期长、应用版本多的特点
• 测试运行期质量
• 评审开发期质量

粗粒度功能模块划分

• 功能树
  • 功能树是一种功能分解结构，功能模块结构图是对系统进行结构分解的结果示意图
  • 功能树属于需求分析层面，刻画问题域。功能模块结构图属于设计层面，刻画解决方案
• 功能模块划分方法
  • 从“功能组”到“功能模块”。实现“高内聚”和“低耦合”的功能组内模块关系

总体架构设计：将一个综合“系统”划分成多个顶级子系统，每个顶级子系统都是可交付的实体

分层架构

设计分层架构，从上下文图开始

• 展示层、业务层、数据层
• UI（用户界面）、SI（系统交互层）、PD（问题领域层）、DM（数据管理层）

用例驱动的模块划分

从用例到类，再到模块

• 描述需求的序列图：描述“内外对话”
• 描述设计的序列图：描述“内部协作”

步骤

1 用例图描述为外部actor提供的功能

2 用例规约将功能描述为”能够为用户带来价值的交互序列“

3 识别一个用例后有哪些类，以及类之间的交互(鲁棒图、序列图)

4 梳理多个用例，识别出这些类，并将类划分到不同模块（包图）

模块划分的4步骤方法

• 自顶向下
  • 运用层（水平切分）
  • 功能模块（垂直切分）
• 自底向上
• 用例驱动(先识别类，再照给出模块)

封装驱动设计方法

• 研究需求（上下文图，功能树）
• 粗粒度分层
• 细粒度划分模块
• 用例驱动的模块划分结构评审、优化

参考

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆

• 读书笔记 (61)

• 读书笔记 (61)