架构设计："4+1"视图

概念

“4+1”视图，是指从5个不一样视角来描述软件体系结构。
“4+1”分别指：

1. 逻辑视图
2. 过程视图
3. 物理视图
4. 开发视图
5. 场景/用例 视图

逻辑架构的描述能够围绕前四个视图进行组织，而后结合用例或场景进行说明，造成第五个视图。

每一个视图只关心系统的一个侧面，5个视图结合起来，才能反映系统的所有内容。

关于视图

软件设计能够从不一样的概念角度进行描述和记录，这些角度一般被称为视图。

“视图表示软件体系结构的一部分，它显示软件系统的特定属性”

不一样的视图涉及与软件相关的不一样问题。

总之，软件设计是由设计过程产生的多方面的产物，一般由相对独立的正交视图组成，能够结合建筑视图理解。

逻辑视图

当使用面向对象的设计方法时，逻辑视图对应设计的对象模型，经常使用描述方法有UML类图、E-R图。

逻辑架构主要支持功能需求，即系统应该为用户提供什么样的服务。
系统被分解成一组关键抽象，以对象或对象类的形式从问题中表述。

类的设计遵循抽象、封装和继承的原则，这种分解不只是为了进行功能分析，也是为了理清系统各个部分的通用机制和设计元素。

过程视图

过程架构关注设计的并发和同步方面，考虑了一些非功能性需求，好比性能和可用性。
过程视图能够在几个抽象层次上进行描述，每一个抽象层次处理不一样的关注点：

• 在最高层次上关注进程，进程分布在由LAN或WAN链接的一组硬件资源上，做为一组独立执行的通讯程序逻辑网络。
• 多个逻辑网络能够同时存在，共享相同的物理资源。

主要任务是经过一组定义良好的任务间通讯机制进行通讯：基于同步和异步消息的通讯服务、远程过程调用、事件广播等。

次要任务是能够经过集合或共享内存进行通讯，避免重大任务在同一过程或处理节点上进行配置假设。

物理视图

物理视图描述软件到硬件的映射，主要反映在分布式方面。

物理架构主要考虑系统的非功能性需求，如可用性、可靠性（容错性）、性能（吞吐量）和可扩展性。

常见物理配置：

• 测试
• 为不一样站点或不一样客户部署系统

开发视图

开发视图描述软件在其开发环境中的静态组织。

开发架构的重点：

• 对软件开发环境中实际软件模块进行组织
• 将软件打包成小的程序库，或者打包成能够由一个或少许开发人员开发的子系统

系统的开发架构由模块和子系统图表示，表示成“导出”和“导入”关系。只有当软件的全部元素都被识别以后，才能描述完整的开发架构。

在很大程度上，开发架构考虑发展的便利性、软件管理、重用或通用性，以及工具集或编程语言施加的约束。

开发视图是需求分配的基础，便于开发团队分配工做，有助于成本评估和提早计划、监控项目进度、软件重用、可移植性和安全性的推理。经过开发视图，容易得出项目开发人员的分工配置。

实际应用中，开发视图会在逻辑视图的基础上增长大量内容，好比大量接口、辅助类等。

场景/用例 视图

架构的描述决策能够围绕前四个视图进行组织，而后由一些选定的用例或场景（成为第五个视图）进行说明。

其余四个视图中的元素，能够经过一些重要的场景或用例进行更好的展现，好比：

• 构造更符合用例的实例
• 描述一些关联脚本，如对象之间或进程之间的交互

总结

并不是全部的软件架构都须要完整的“4+1”视图。

无用的视图能够从架构描述中省略，例如：

• 若是只有一个处理器，则不须要物理视图
• 若是只有一个进程或程序，则不须要进程视图
• 对于很是小的系统，有可能逻辑视图和开发视图很是类似，不须要单独描述

场景视图在任何状况下都有用。