1. 架构方法

1.1 什么是架构

软件架构，是有关软件整体与组件的抽象描述，用于指导大型软件系统各个方面的设计。



架构是给谁做的？—— 相关方

架构需要重点关注什么？—— 相关方的关注点

架构由什么组成？—— 一系列架构元素及元素间的关系

架构师的产出是什么？ —— 架构文档

架构怎么描述？ —— 架构视图。根据不同相关方的关注点，来描述架构视图

架构元素间的关系? —— 静态关系和动态关系

1.2 什么是架构师

架构师是做架构设计，对系统架构负责的那个人。

1.3 架构师主要职责

1. 编写架构设计文档

2. 开发编程框架

3. 重构软件代码

4. 设计系统架构

5. 进行技术选型，解决技术应用中的问题

6. 优化系统性能

7. 模块分解与微服务架构重构

8. 大数据应用

9. 沟通管理

1.4 架构师主要能力

1. 编程能力

2. 基础技术掌握能力

3. 常用技术产品的理解与应用能力

4. 性能优化与分析故障的能力

5. 常用架构模式和框架的理解与应用能力

6. 建模以及设计文档的方法和能力

7. 业务理解与功能模块及非功能模块拆解能力

8. 快速学习能力

9. 沟通与领导能力

2. 软件建模与设计文档

2.1 什么是模型

模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴含在模型中。

通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。

领域问题经过分析抽取得到概念模型，从概念模型中提取系统需求，分析系统需求，设计得到问题的解决方案。

2.2 为什么要建造模型

建造传统模型的目的：为了证明某件事物能够工作

建造传统模型的前提：建造模型的成本低于建造实物的成本



建造软件模型的目的：

• 为了与他人沟通

• 为了保存软件设计的最终成功

• 前提：除非模型比代码更能说明问题

2.3 何时何处画图

2.3.1 何时画图

• 讨论交流时

• 最终设计文档(只保留少量的、重要的图，避免设计过多内容和实现细节)

2.3.2 何处画图

• 白板

• 绘图工具，如Visio,Aastah

• draw.io

2.4 UML

2.4.1UML简介

什么是UML?

Unified Modeling Language,统一建模语言，以图形方式描述软件的概念



UML可用来描述：

某个问题领域、构思中的软件设计、已经完成的软件实现

2.4.2 UML图的分类

2.4.2.1 静态图

静态图——通过描述类、对象和数据结构以及它们之间存在的关系，来描述软件要素中不变的结构。

• 用例图

• 对象图

• 类图

• 组件图

• 包图

• 部署图

2.4.2.1 动态图

动态图——通过描绘执行流程或者实体状态变化的方式，来展示软件实体在执行过程中的变化过程。

• 协作图

• 活动图

• 时序图

• 状态图

2.5 4+1视图模型



软件架构 = { 元素，形式，关系/约束}

单一的视图无法完整地表达架构，因此需要具备完备的视图集

2.5.1 逻辑视图

相关方：客户、用户、开发组织管理者

视角：系统的功能元素，以及它们的接口、职责、交互

主要元素：系统、子系统、功能模块、子功能模块，接口

用途：开发组织划分，成本/进度的评估

2.5.2 开发视图

相关方：开发相关人员、测试人员

视角：系统如何开发实现。

主要元素：描述系统的层，分区，包，框架，系统统用服务，业务统用服务，类和接口，系统平台和相关基础框架。

用途：指导开发组织设计和开发实现。

2.5.3 物理视图

相关方：系统集成商、系统运维人员。

视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置。

主要元素：物理节点以及节点的通信。

2.5.4 过程视图

相关方：性能优化，开发相关人员。

视角：系统运行时线程、进程的情况。

主要元素：系统进程，线程以及处理队列等。

2.5.5 场景视图

相关方：用户，设计和开发人员

视角：概括了架构上最重要的场景(最典型或者最有风险)及其非功能性需求，通过这些场景的实现， 阐明了架构的广度或众多架构元素运行的方式。