架构设计4+1视图的作用与关系

设计一个大型的软件系统是一个非常复杂的工作。这个软件系统需要能够满足业务需求 ，达成软件的可靠性、可用性、安全性、性能、容量等质量属性要求，要能够在相应的物理环境上执行，这需要硬件、驱动、操作系统、基础平台、开发框架等大量周边服务或组件，还需要开发几十、数百万的代码，才能够实现。

设计这样一个复杂的系统，必然需要一个或数个设计团队协作配合才能够完成。而要让这些设计人员能够良好的沟通交流，必须对系统有一个统一的认识才能够完成；同时，要将设计转化为实现，需要更多产品、开发、测试人员协同工作。

因此，必须有一种方法，能够让设计人员将一个系统进行自顶向下的设计分解，并形成合理的抽象描述。4+1视图就是这样一种复杂系统的架构设计方法。

4+1视图

Use-Case View

中文可以称为用例视图或场景视图。即4+1中的1。从上图可以看到，4+1中的4个视图都是围绕着用例视图为核心的。

用例视图是一种需求分析技术，通常采用UML的用例图进行设计。通过用例视图的设计过程，可以正确的识别系统的用户和其它系统（Actor）、系统边界（Boundary）和用例（Use Case），并对系统的功能场景进行充分的分析，以确定系统提供的功能可以满足用户需求。

用例视图之所以是4+1视图的核心，是因为它确定了以下信息，而其它4个视图都是需要围绕着这些信息进行设计：

• 系统边界：有了边界，才能够确定系统的设计范围；同时，通过边界能够识别出系统需要与用户或其它系统进行交互；
• 系统用户：明确的用户定义是系统需求分析的先决条件；
• 功能和场景：通过识别出系统与用户或其它系统的交互，可以分析出系统需要提供哪些功能，以及这些功能存在哪些应用场景；

因此，用例视图并不限于使用UML的用例图进行设计，也可以使用其它方法，比如使用图表进行描述。只要能够清晰的定义出以上几点，就达到了目的。

Logical View

中文称为逻辑视图，是所有这些视图中最不可或缺的视图。在很多系统设计中，如果系统的功能、场景等比较清晰（比如有明确协议定义的系统），可能会对用例视图进行简化，但却不可以没有逻辑视图。

逻辑视图是对系统职责的的逐级划分，下面TensorFlow的逻辑视图示例，这里描述了TensorFlow中各个功能组件，从这个图中，基本可以对TensorFlow有一个大颗粒度的了解。

TensorFlow逻辑架构

除了对系统职责进行划分，逻辑视图通常还要求对各逻辑元素间的关系，也就是接口进行描述。增加逻辑元素的接口进行描述对系统的设计和实现非常重要。因为软件设计最重要的原则就是高内聚、低耦合，一个满足此原则的系统不应该存在不合理的依赖关系，比如下层与上层间的反向依赖，或是循环依赖等。

一般，逻辑架构元素决定了开发组织（根据康威定律，反之亦然）。因此，逻辑元素的边界和接口也是后续多个开发组织之间进行接口控制的关系依据。设计合理的逻辑架构，可以提升团队的沟通效率，进而提升整个系统的交付效率和质量。

Implementation View

中文称为实现视图或开发视图。在开发视图中，主要包括两部分信息：

• 对逻辑架构元素，描述其代码位置，可以是代码仓位置，或代码目录，或是开源软件的版本信息等
• 系统的构建，即如何将代码编译成二进制交付件（比如.so/.bin）。这个构建信息需要包括构建依赖、构建工具链、构建环境信息

一个设计良好的开发视图，应该能够满足以下要求：

• 通过逻辑架构元素，能够找到它所有代码和所有的二进制交付件
• 每一个代码源文件，都能够找到它所属的逻辑架构元素
• 每一个二进制交付件，都能够找到它集成了哪些逻辑架构元素

Deployment View

中文称为部署视图，有时也称为物理视图。

开发出的软件系统，最终是要运行在物理或软件环境上。物理环境可能是服务器、PC机、移动终端等物理设备；软件环境可以是虚拟机、容器、进程或线程。部署视图就是对这个部署信息进行描述，包括：

• 二进制交付件，与软件环境的部署关系
• 软件环境与物理环境的部署关系

通过逻辑视图、开发视图加部署视图，我们已经可以知道系统中每一个逻辑架构元素、每一份代码，最终会运行在什么位置上。反向也可以通过运行环境上，找到所有其上运行的逻辑架构元素和代码。

Process View

中文称为过程视图、运行视图或处理视图。

逻辑视图、开发视图和部署视图，描述的都是系统的静态信息，到现在为止我们还缺少对系统动态行为的描述，而运行视图就是用来描述系统中的动态信息的。运行视图最常见的设计工具就是UML的序列图。

运行视图的设计，最常见的是逻辑架构元素之间的交互关系，比如消息交互、服务调用或API调用。如下图所示。

UML序列图

在运行视图中，除了要关注组件间的交互关系，通常还需要考虑并发、抢占、关键资源（比如锁）访问等。

总结

通过4+1视图，我们可以形成一个系统的抽象描述，组织中的所有成员，都要围绕着这个抽象进行设计、实现、验证，并在系统演进中不断完善修正它们。

当然，4+1视图并不能覆盖系统的所有内容，比如系统中使用了哪些关键的技术，或是系统中关键的数据结构和表的设计，在这里都没能体现出来。这需要我们再结合其它的设计技术来完善补充，才能让我们的系统设计更加完整。