架构师思维学习

1.软件架构概念

阅读路径

1. 架构入门：2-3-12-13-14-15
2. 大系统架构设计：8-9，概念架构设计
3. 从需求到架构：

2.架构视图

什么是架构视图

1. 架构视图的本质是分而治之，从不同的角度角度设计系统，特别是复杂的系统。
2. 常用逻辑视图+物理视图
3. 每个视图关注不同的方向，针对不同的实现和目标
4. 对系统的某一方面的简化描述，忽略与其无关的实体。

• 架构视图要考虑不同人员的交流

1. 运维关系部署视图
2. 开发关系模块接口交互视图

为谁设计

• 用户而设计：帮助用户实现生活和工作中的目标，如削铅笔，给小学生和美术师用的肯定不一样。
• 为客户设计：客户不等于用户，如公司老板是客户，公司员工是用户。需要根据客户的业务需要和其他软性要求进行设计，帮客户达到目标。
• 为开发人员设计：不仅要考虑客户的要求，还要考虑在开发过程中的扩展性，可移植性，易理解性，可重复性等。
• 为管理人员设计：在开发团队中人员相互依赖，从模块+交互层面理解架构，从何更新在开发过程中分派和执行开个过程和团队协作。

逻辑视图+物理视图

• 物理视图：计算机连接到计算机
• 逻辑视图：客户端连接到服务期

逻辑视图

• 软件系统由那些逻辑元素构成，以及逻辑元素之间的关系。
• 核心任务识别模块和规划接口，了解模块之间关系和交互方式。

物理视图

• 组成系统的物理元素，物理元素之间关系，部署在硬件上的策略
• 物理层：客户端、web层、业务层
• 并发控住单元：进程、线程
• 运行时视实体：组件、对象、消息
• 数据：持久化数据、共享数据、传输数据

设计实现

• 逻辑架构中职责划分的决策，体现为分层、子系统和模块的划分，从静态视角为详细设计和编程实现提供指导。
• 逻辑架构规定了不同逻辑单元之间的交互接口和交互机制，编程中进行实现。
• 交互机制：方法调用，消息调用，远程调用。
• 物理架构关注运行时的情况，规定了软件如何使用进程和线程时间期望的并发处理。关注主动单元调用哪些被动单元，和通过哪些调用方式。

实现项目练习

使用技巧

• 分而治之：逻辑分解和物理分解
• 迭代式设计：不同架构视图的设计交替进行、迭代展开。逻辑职责的划分逐步清晰，促进物理分布设计，反之亦然。

迭代1

• 逻辑架构设计

• 物理架构设计

迭代2：

• 逻辑架构设计

 

• 物理架构设计

4设计过程

4.1洞察三原则

1. 看透需求：深入了解需求和领域模型需求成果
   1. 需要要全：功能需求，质量需求，约束需求缺一不可。
   2. 矛盾关系：各项需求间的矛盾关系，无法做到面面俱到，需要权衡。
   3. 追溯关系：下级需求覆盖上级需求，需求实现系统目标。
2. 正确架构方向：生成关键需求级概念架构
   1. 合理的架构模式
   2. 合理的集成技术
3. 设计好架构的各方面：通过多视图方法细化架构，通过架构原型验证架构
   1. 逻辑视图：分层分模块
   2. 开发视图：技术选型组合
   3. 运行视图：进程线程
   4. 物理视图：物理机部署
   5. 数据视图：数据存储

4.2洞察过程步骤

1. 需求分析：全面认识需求及相互影响
   1. 两纵三横
      1. 一纵：需求沟通：
      2. 二纵：确定非功能需求：
      3. 一横：确定系统目标
      4. 二横：使用范围+feature+上下文图研究高层需求
      5. 三横：建立用例模型
2. 领域建模:精化问题领域，确定系统功能范围。
   1. 业务决定功能，功能决定模型
   2. 领域模型的输入：功能和可扩展性，即现在的功能和未来的功能，也是驱动领域模型的因素，评审领物模型的依据。
3. 确定关键需求：从需求中筛选关键需求
4. 概念架构设计：必须重视关键功能和关键质量，1个决定4个选型
   1. 决定如何划分顶级子系统
   2. 架构风格选型
   3. 开发技术选型
   4. 集成技术选型
   5. 二次开发技术选型
5. 细化概念设计：关注模块+接口。
6. 架构验证

4.3架构设计速查手册

5需求分析过程

5.1软件研发交互过程

1. 概念化：系统质量
2. 需求分析：需求结果
3. 架构设计：技术架构
4. 开发与测试：可执行的系统
5. 验收及交付：交付的系统

5.2愿景与范围文档（市场需求文档、产品需求文档、项目立项书）

1. 业务需求
   1. 背景
   2. 业务机遇
   3. 业务目标
   4. 客户或市场需求
   5. 提供给客户的价值
   6. 业务风险
2. 项目愿景及解决方案
   1. 项目愿景陈述
   2. 主要特征
   3. 假设和依赖环境
3. 范围和局限性
   1. 首次发布范围
   2. 后续发布范围
   3. 局限性和专用性
4. 业务环境
   1. 客群描述
   2. 项目优先级
5. 产品成果的因素

5.3上下文图

帮助说明需求范围的方式，描述了待开发系统与周围所有事务之间的界限和联系。

1. 要点一：内容原则，关注本系统及与其有关联的因素，不关注系统内部功能和结构。
2. 要点二：形式原则，以黑盒形式标识本系统，放在上下文中央，其他相关因素环绕周围。

 5.4愿景分析（需求调研）方法

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

5.5需求分析

什么是软件需求：软件要为用户做什么。

分析活动：

• 需求捕获：获取知识的过程。必须理解用户所从事的活动，了解软件能帮助用户他们哪些
• 需求分析：挖掘和整理知识的过程，在获取知识的基础上进行。
• 系统分析：系统怎么做，针对问题，收集相关资料，了解产生问题的原因，解决提出问题的方法和可行方案，以满足系统需求和预定目标。

5.6二位需求观与ADMEMS矩阵

• 需求是分层次：根据不同层次的涉众
  • 组织级：业务目标、预期投资、工期要求、符合的标准及与老系统的整合等
  • 用户级：用户私有系统辅助完成哪些活动？质量要求？环境特殊性等。
  • 开发级：开发人员需要实现什么，开发周期，维护时间，开发团队与架构的影响。

• 从不同方面考虑需求：
  • 功能需求：体现各级直接目标的要求，功能需求描述系统应该做什么
  • 质量属性：运行期质量+开发期质量
  • 约束条件：业务环境+使用环境+构建环境+技术环境

 

 5.7产品质量属性

 

5.8 需求如何影响架构

• 功能需求，发现职责的依据
  • 每个功能都由一条"职责协作链"完成，用来讲职责分到子系统，界定子系统接口，确定交互机制。，推动架构设计。
• 质量需求，完善架构设计的功力
  • 基于当前的设计架构，进一步考虑质量需求，对架构进行细化、调整或重构，使架构更加完善。
  • 架构设计质量和功能缺一不扣。
• 约束需求，对架构设计的影响分为几类
  • 直接制约设计决策，必须在window系统上运行
  • 转化为功能需求的约束，使用最新的系统版本，版本更新。
  • 转化为质量需求的约束，操作人员老年人，要求易用性。

6用例图与需求

• 用例图参与者Actor用例Use Case,体现用户与系统的交互
• 鲁棒图来建模用例实现，从功能需求到设计方案

4个用例技术的作用

• 用例图总体反应用户需求
• 用例简述是行为需求的简化
• 用户规约描述行为需求
• 用户实例鲁棒图确定初步设计

实践场景

1. 用例图+用例简素：用于需求捕获，也许简单的需求分析，覆盖需求，需求变更影响少。
2. 用户规约：用于需求分析和需求规定定义，为参与者带来的价值结果。
3. 用例实现-鲁棒图：用于初步设计，

需求与技术关系

7领域建模的应用

        领域模型将领域概念（行业术语）以可视化的方式抽象成为一套模型，不仅关注重要的领域概念，还刻画出领域概念间的关系。

领域模型最常用的两张图表示：类图和状态图

• 类图

• 状态图

 领域模型和文字说明相结合，选择适合的表达方式。

7.1领域模型在开发活动中的重要作用

• 为需求提供领域知识和领域词汇
• 软件界面设计和领域模型有着密切的关系
• 模型的合理性影响软件系统的可扩展性
• 领域模型精化后将作为业务层的核心
• 是持久化数据模型的重要参考

7.2领域模型与需求分析的关系

• 领域模型提供的词汇表应成为所有团队成员所使用的语言核心，作为团队交流基础。
• 在需求捕获和分析过程中，与客户交流的语境。

 7.3建模步骤-需求人员

1. 概念角色，活动，工件
   1. 角色是对个人或者团队的职责规定
   2. 活动就是角色执行的工作单元
   3. 工件就是工作的成品或半成品
2. 概念关系
   1. 角色的职责：体验在他执行的活动或负载的工件上
   2. 活动可以是工件的输入，也可能使用工件。
   3. 工件是由活动产生的。
3. 建立并管理基线，
   1. 基线需要进行评审
   2. 要受配置和变更管理控制
4. 配置和变更完成建立并管理基线任务
   1. 置于配置和变更管理下的工件称为配置项，配置项是工件的子类
   2. 基线由过个配置项组成的快照，受配置和变更控制是基线的必要条件

 7.4开发人员的领域知识

1. 领域模型作为理解领域的手段，就如通过代码重构理解系统。
2. 领域知识的核心是领域概念之间的关系，包括对应关系，包含关系，因果关系等。
3. 领域模型强项在于通过对复杂领域进行概念抽象和关系抽象建立模型，对领域知识总体上把握。

7.5功能决定如何建模，模型决定功能扩展

• 更好的扩展性，需要由内到外进行构建软件。
• 变化无处不在：交互方式变化，数据存储方式变化，系统对接多样性
• 变化并非无常：在系统的问题领域在大多数情况下是不变的，变的值是对外交互方式。
• 领域模型决定了软件系统功能的范围：对现实世界一定程度的抽象，根据目的忽略掉一些对象和关系。
• 领域模型影响软件的可扩展性：在一定程度上支持未来可能出现的新需求。

8确定关键需求

8.1什么决定架构

• 用例驱动轮：用例不能覆盖非功能需求
• 质量决定轮：质量和功能都会对架构影响
• 经验决定轮：架构是一门艺术

8.2关键需求决定架构，其余需求验证架构

• 关键需求包括功能，质量和约束，只考虑功能就会太过理想化

8.3如何确定关键需求

架构师如何确定关键需求

1. 不同质量属性间通常具有相互制约性，需要权衡哪些是重点目标
2. 功能需求很多时，需要控住需要分析的功能个数。

确定质量需求步骤

1. 为了提高开发软系统的被认可程度，考虑需要提高哪方面的质量需求。
2. 从分考虑质量间的相互制约和促进关系，调整不同资料属性的标准。
3. 还必须满足各种约束性需求
4. 可以利用ADMEMS+文档模板

确定关键功能需求

1. 核心功能：业务层接口必须反应这些功能
2. 必做功能：需要参考客户方的情况，对于业务系统来说运营功能高于管理功能
3. 高风险功能：基于务实考虑，需要把风险高的功能为了关键功能
4. 独特功能：除前3点功能外的独特功能
5. 关键功能集不存在标准答案，事后才能证明功能覆盖性，根据经验进行设计。
6. 关键功能的比例根据实际情况，不能太多也不能太少。

小系统与大系统分水岭

行业领导者的架构也需要分析关键需求

9确定概念架构

概念架构是指系统目标的设计思想，重大选择。可以说明方案的技术优势，也可以叫做市场架构。

什么是概念架构

• 概念架构是关注高层组件及交互关系
• 定义了高层组件的边界
• 不涉及接口细节

概念架构长什么样

• 概念架构贵在针对性：直指目标，设计思想和重大决策
• 对比分析几种可能的架构
• 了解竞争对手的产品及架构
• 售前关注的就是概念架构
• 投标的也是概念架构

怎么设计概念架构

从关键需求到概念架构

1. 需求分析
2. 用例技术
3. 领域建模
4. 关键需求
5. 关键功能设计，鲁棒图
6. 关键质量，目标-场景-决策表设计
7. 概念架构不等于立项化架构、细化架构。
8. 左手功能，右手质量

功能工具

鲁棒图

        鲁棒（Robustness）性，也叫健壮性，与容错性相似。

鲁棒图的三个元素

• 边界对象：模拟外部环境和未来系统之间的交互
  • 接收外部输入
  • 处理内部内容的解释
  • 表达或传递响应结果
• 控住对象：对行为进行封装，描述用例中事件流的控住。
• 实体对象：对信息进行描述，一般来自领域概念中的对象属性。

 质量工具

• 场景思维技术是一种将笼统的需求明确化思维和技术

场景5要素

• 影响来源：系统内外的触发因素
• 如何影响：影响来源触发了什么影响
• 受影响对象：默认为本系统
• 问题或价值：被影响出现的问题，或体现了什么价值
• 所处环境：影响时的环境或上下问题。
• 可以是用场景卡进行收集

 

 

 

 概念架构设计要领

1. 功能需求和质量需求并重
2. 概念架构设计的1决定和4选择
   1. 决定如何划分顶级子系统
   2. 架构风格选型
   3. 开发技术选型
   4. 二次开发技术选型
   5. 集成技术选型
3. 备选设计：需要考虑为什么这样设计、有没有其他设计方式？

10确定概念架构的细化架构

5视图法

1. 逻辑视图：职责划分，分模块、分层、垂直子系统，他们之间的接口
   1. 模块划分
   2. 接口定义
   3. 领域模型
2. 开发视图：程序单元组织，开发语言，框架，一类关系
   1. 技术选型
   2. 文件划分
   3. 编译关系
3. 运行视图：控制流组织，多进程技术、多线程技术，终端服务程序等
   1. 技术选型
   2. 控住流划分
   3. 同步关系
4. 物理视图：PC、服务期、单片机的选型和互联
   1. 硬件分布
   2. 软件部署
   3. 方案优化
5. 数据视图：持久化设计。关系数据库，实时数据库，文件系统等
   1. 技术选型
   2. 存储格式
   3. 数据分布

 11验证架构设计

12.功能划分

1. 功能如何划分
2. 如何分层，如何封装与交互
3. 从需求用例到模块结构设计步骤
4. 水平切分，垂直切分，专用通用分离

12.1功能树

• 通过需求分析，选择和确定系统必须具有的功能和特性
• 是一种系统功能表达结构，可分为功能大类、功能组和功能项。

        "功能分解"不等于"结构分解"

• 从问题领域（现实需求）到解决方案（从软件架构，再到软件系统）
• 功能树是功能分解结构，功能模块结构图是系统结构分解的结果示意图
• 功能树刻画的问题领域，功能模块结构图反应的是解决方案
• 功能树关注需求，功能模块结构图关注设计
• 功能树是通过需求分析得到，功能模块结构图则是通过设计得出

12.2从功能树到功能模块

1. 绘制需求用例图
2. 得到功能模块划分结构

第一步：绘制功能树

• 获取需求途径：需求文档、用户沟通和分析类似产品
• 功能树的可以有多种结构：树形，列表，模块 ，目录等

第二步：评审功能树

• 面向使用，体现使用的价值
• 全面覆盖，没有范围遗漏

第三步：从功能树到功能模块的划分

1. 业务上紧密相关的划分到一起，因为会用到相同的函数、数据等，高内聚，松耦合。
2. 公共功能会同时支撑多组功能实现，可以单独模块化。

12.3总体架构设计

• 总体架构设计是将综合系统切分成多个可交付的顶级子系统。
• 可分为前端系统、后端系统、切入式系统、中间件等。还包括一些组件和插件等特殊顶级子系统。

13如何分层

13.1分层架构 

三层结构

• 展现出：展示和接收数据，与用户进行交互
• 业务层：处理业务逻辑
• 数据层：进行数据存储操作，增删改查

四层结构

• 用户界面UI：封装用户交互，屏蔽交互方式。
• 系统交互SI：封装硬件和外部系统的交互
• 问题领域PD:问题领域和业务领域的抽象，及其功能实现。
• 数据管理DM:数据持久化管理，数据库和数据文档等。

 13.2分层技巧

设计思想：分层的“封装外部交互”思想

• 外部用户交互：终端用户、管理员
• 外部系统交互：支付平台
• 外部硬件交互：打印机，摄像头
• 外部数据库交互：数据库，文件系统

上下文图

• 上下文图是一种需求描述

• 上下文图的三种画法

  • 顶层数据流图

  • 用例图

  • 框图

分层步骤

1. 是否存在UI交互层：告警系统没有UI交互
2. UI交互从包含的职责有哪些：用户操作界面，管理员界面，报表展示界面
3. 系统交互层是否存在，包含哪些:外部支付系统，短信系统等。
4. 数据层是否存在，包含哪些：是否包含数据持久化内容
5. 问题领域包含哪些：系统具体的业务功能

14从用例到模块划分

• 需求序列图：描述系统内外部的交互
• 设计序列图：描述系统内部交互

用例规约

• 描述用例的主语包括外部用户和待开发的系统

用例

• 用例名称：注销用户
• 简要说明：帮助系统用户注销用户信息
• 事件流：
  • 操作人员进入系统注销用户界面
  • 操作人员输入用户账号
  • 系统展示用户账号的信息
  • 操作人员确认账号信息是否一致后进行注销
  • 系统收到确认注销后，删除用户信息，并返回注销结果。

15模块划分的4个步骤

15.1思考方式

1. 自顶向下
   1. 水平切分：分层
   2. 垂直切分：功能划分
2. 自低向上：识别类，归纳模块，用例驱动
3. 拍脑袋：根据经验很灵感

 设计技巧

• 弄清层、功能模块和细颗粒模块，有助于划分设计
• 层属于粗颗粒，根据不同关注点进行分层。
• 功能模块属于粗颗粒，对应一个功能组，可能根据功能组进行开发分工
• 细颗粒模块必然属于某一分层中
• 细颗粒模块一般也会在每个粗颗粒的功能模块中

 15.2模块划分的四个步骤

 15.2.1封装驱动设计EDD方法的四个步骤

综合运用分层、分层细化、功能模块、通用模块和通用机制框架化等多种方法进行细粒度模块划分

1. 研究需求
   1. 对模块划分帮助最大的需求成果是上下文图和功能树
   2. 要带着质疑的心态去研究、评价和确认。
2. 粗粒度分层
3. 细粒度划分
   1. 分层细化：在粗粒度层内进行更细致的分层，如服务调度层和服务层
   2. 分区：将分层内对功能组进行封装得到细粒度谋爱。
   3. 通用模块分离：被上层模块使用越多的模块为通用模块，分离有利于提高重用性，减少重复代码。
   4. 通用机制框架化：
      1. 预先定义的、能够完成预期目标的、基于抽象角色的协作方式，包含协作关系和协作流程
      2. 协作是多个对象为完成目标进行的交互
      3. 机制是特殊的协作
      4. 基于接口和抽象类的协作是机制，基于具体类的不是机制
      5. 面向对象就是编程方面的机制
4. 用例驱动的模块划分结构评审及优化
   1. 系统难点部分的设计，多使用用例驱动方法
   2. 场景和用例也是驱动设计评审的核心思维

总结：确定分层架构以后，需要进行细粒度模块划分，使用的方法都封装思想