架构设计："4+1"视图
概念
“4+1”视图，是指从5个不同视角来描述软件体系结构。
“4+1”分别指：
- 逻辑视图
- 过程视图
- 物理视图
- 开发视图
- 场景/用例 视图
逻辑架构的描述可以围绕前四个视图进行组织，然后结合用例或场景进行说明，形成第五个视图。
每个视图只关心系统的一个侧面，5个视图结合起来，才能反映系统的全部内容。
关于视图
软件设计可以从不同的概念角度进行描述和记录，这些角度通常被称为视图。
“视图表示软件体系结构的一部分，它显示软件系统的特定属性”
不同的视图涉及与软件相关的不同问题。
总之，软件设计是由设计过程产生的多方面的产物，通常由相对独立的正交视图组成，可以结合建筑视图理解。
逻辑视图
当使用面向对象的设计方法时，逻辑视图对应设计的对象模型，常用描述方法有UML类图、E-R图。
逻辑架构主要支持功能需求，即系统应该为用户提供什么样的服务。
系统被分解成一组关键抽象，以对象或对象类的形式从问题中表述。
类的设计遵循抽象、封装和继承的原则，这种分解不仅是为了进行功能分析，也是为了理清系统各个部分的通用机制和设计元素。
过程视图
过程架构关注设计的并发和同步方面，考虑了一些非功能性需求，比如性能和可用性。
过程视图可以在几个抽象层次上进行描述，每个抽象层次处理不同的关注点：
- 在最高层次上关注进程，进程分布在由LAN或WAN连接的一组硬件资源上，作为一组独立执行的通信程序逻辑网络。
- 多个逻辑网络可以同时存在，共享相同的物理资源。
主要任务是通过一组定义良好的任务间通信机制进行通信：基于同步和异步消息的通信服务、远程过程调用、事件广播等。
次要任务是可以通过集合或共享内存进行通信，避免重大任务在同一过程或处理节点上进行配置假设。
物理视图
物理视图描述软件到硬件的映射，主要反映在分布式方面。
物理架构主要考虑系统的非功能性需求，如可用性、可靠性（容错性）、性能（吞吐量）和可扩展性。
常见物理配置：
- 测试
- 为不同站点或不同客户部署系统
开发视图
开发视图描述软件在其开发环境中的静态组织。
开发架构的重点：
- 对软件开发环境中实际软件模块进行组织
- 将软件打包成小的程序库，或者打包成可以由一个或少量开发人员开发的子系统
系统的开发架构由模块和子系统图表示，表示成“导出”和“导入”关系。只有当软件的所有元素都被识别之后，才能描述完整的开发架构。
在很大程度上，开发架构考虑发展的便利性、软件管理、重用或通用性，以及工具集或编程语言施加的约束。
开发视图是需求分配的基础，便于开发团队分配工作，有助于成本评估和提前计划、监控项目进度、软件重用、可移植性和安全性的推理。通过开发视图，容易得出项目开发人员的分工配置。
实际应用中，开发视图会在逻辑视图的基础上增加大量内容，比如大量接口、辅助类等。
场景/用例 视图
架构的描述决策可以围绕前四个视图进行组织，然后由一些选定的用例或场景（成为第五个视图）进行说明。
其他四个视图中的元素，可以通过一些重要的场景或用例进行更好的展示，比如：
- 构造更符合用例的实例
- 描述一些关联脚本，如对象之间或进程之间的交互
总结
并非所有的软件架构都需要完整的“4+1”视图。
无用的视图可以从架构描述中省略，例如：
- 如果只有一个处理器，则不需要物理视图
- 如果只有一个进程或程序，则不需要进程视图
- 对于非常小的系统，有可能逻辑视图和开发视图非常相似，不需要单独描述
场景视图在任何情况下都有用。
