优秀程序员画好软件系统架构图的三步法（一）

​ 作为软件开发人员，在工作中难免要画很多架构图，对于如何画架构图很多人其实是不清楚的，也不知道什么场景下该使用哪种架构图。本文将为大家分享关于如何画好系统架构图的方法和技巧。

在聊如何画好系统架构图之前，先简单聊下什么是架构。架构一词最早来源于建筑学，后来随着软件开发行业的兴起，为了解决软件开发过程遇到的问题，软件开发先驱们吸取了人类几千年建筑设计实践中积累的大量经验和教训，逐渐形成软件架构的概念，并慢慢流行起来。

在建筑体系结构中，设计师使用建筑图纸描述建筑物的总体布局，将复杂的建组物分解为各种基本结构，这些基本结构之间相互联系从而构成一个复杂的建筑。对应地，在软件开发中，我们需要从顶层对软件系统做架构设计，将整个系统拆分成不同的组件，并设计整体的控制结构，组件之间的关系等。软件架构与建筑架构不同的是，建筑架构是静态的，各基本结构的关系在建完成后就确定了。软件架构是动态的，在软件运行过程中，各组件的关系及行为是根据运作规则动态改变的。

软件架构指的是软件系统的顶层结构（Rank），就像建筑设计里的图纸，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule），如下图所示：

架构图是为了抽象的表示软件系统的整体系统框架、各个组件之间的相互关系，以及软件系统的演进方向的视图。简单的说就是用图将4R架构的元素展现出来。

通常来说，我们绘制架构图的目的是为了解决团队之间的沟通障碍，通过架构图可以便捷的与团队其他成员进行沟通，减少歧义，最终让整个团队成员能够达成共识。当然架构图也是软件系统设计很有价值的沉淀产物。

4+1 视图是现代软件开发中经常被使用到的架构蓝图，它为不同的利益相关者提供4种不同的视角和1种场景来阐述架构的设计意图，以便减少认知和交流的成本。

逻辑视图：系统提供给用户的功能，对应UML的类图和状态图。

处理视图：系统的处理过程，对应UML的序列图和活动图。

开发视图：程序员角度看系统的逻辑组成，对应UML的包图（package图）。

物理视图：系统工程师角度看系统的物理组成，对应UML的部署图。

场景视图：用户角度看系统需要实现的需求，对应UML的用例图。

国内企业很少使用4+1视图来描述架构，具体原因大概如下：

现代软件系统架构复杂度增加，4+1视图是1995年提出的概念，当时的系统大部分还是单体系统，现在是分布式系统，架构复杂度高很多。

绑定UML图，由于UML使用一堆图形画图，太丑了，画出来的架构图不直观。

理解困难：4+1视图的逻辑视图，开发视图，处理视图比较容易混淆。

如何画好架构图，下一篇文章分享，感兴趣的话可以关注。

我是齐戈，一个10余年大厂工作经验的老程序员，关注我，带你成长。

​