软件体系结构——4+1视图

The “4+1” View Model of Software Architecture
架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。
架构视图如同在建筑学中的不同种类的蓝图。

1. 背景
软件架构文档过分强调软件开发的某一个方面。
架构不能解决所有风险承担者所关注的问题。
每个软件系统都有多个风险承担者：最终用户、开发人员、系统工程师、项目经理等。
软件工程师欲使用单张视图来捕捉所有的系统架构要点，努力地在单一视图中表达超过其表达限度的蓝图。

Philippe Kruchten, Architectural Blueprints — The “4+1” View Modelof Software Architecture.
使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的问题集合。
2. 视图模型 An ArchitecturalModel 

   
软件架构涉及到抽象、分解和组合、风格和美学。
逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
过程视图（Process View），捕捉设计的并发和同步特征。
物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
开发视图（Development View），描述了在开发环境中软件的静态组织结构。

逻辑架构：
视　角：最终用户
关注点：功能性需求，即在为用户提供服务方面系统所应该提供的功能。
表示法：Booch标记法，UML（类图、交互图、顺序图、状态图），E-R图。
系统分解为一系列的关键抽象，表现为对象或对象类的形式。它们采用抽象、封装和继承的原理。
分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。


逻辑架构视图示例（UML类图）

进程架构
进程是构成可执行单元任务的分组。
视　角：系统集成者
关注点：非功能性需求，如并发性、分布性、系统完整性、容错性。
表示法：Booch标记法，UML（活动图、交互图、状态图）。
进程架构可以在多层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过LAN或者WAN连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。
软件被划分为一系列单独的任务。任务是独立的控制线程，可以在处理节点上单独地被调度。
区别主要任务、次要任务。


进程架构视图示例（UML活动图）

开发架构：
视　角：程序员、软件项目经理
关注点：软件开发环境下实际模块的组织（受开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制）。
表示法：Booch标记法，UML（包图）。
产品线的基础。
软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。
子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。


开发架构视图示例（UML包图）

物理架构：
视　角：系统工程师
关注点：依赖于硬件的非功能性需求，如可用性、可靠性、性能吞吐量和可伸缩性等。
表示法：UML（部署图）。
分别用于开发和测试、部署的物理配置。
软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。


物理架构视图示例（UML部署图）

场景：
视　角：所有视图的用户、评估人
关注点：系统一致性、验收。
表示法：用例文本，UML（用例图）。
在某种意义上场景是最重要的需求抽象。
该视图是其他视图的冗余（因此“＋1”）。
场景视图的两个作用：
作为一项驱动因素来发现架构设计过程中的架构元素。
作为架构设计结束后的一项验证和说明功能。



视图间的关联
Correspondence Between the Views
各视图并不是完全正交的或独立的。视图的元素根据某种设计规则和启发式方法与其他视图中的元素相关联。


从逻辑视图到进程视图 From the Logical to the Process View
在逻辑视图中，每个对象均是主动的，具有潜在的“并发性”。为每个对象实施各自的控制线程，在目前的技术状况下是不现实的。
对象是并发的，必须以某种抽象形式来调用它们的操作。
同时使用两种策略来决定并发的程度和定义所需的过程集合：
从内至外：由逻辑架构开始。
由外至内：从物理结构开始。
其结果是将类和对象映射至一个任务集合和进程架构中的进程。

从逻辑视图到开发视图 From the Logical View to the Development View
逻辑视图和开发视图非常接近，但具有不同的关注点。项目规模越大，视图间的差距也越大。

从进程视图到物理视图 From the Process View to the Physical View
进程和进程组以不同的测试和部署配置映射至可用的物理硬件。


模型的应用 Application of the Model

模型的剪裁 Tailoring the Model：
并不是所有的软件架构都需要“4＋1”个视图。无用的视图可以从架构描述中省略。
场景对于所有的情况均适用。

迭代过程：
场景驱动的方法。
开始阶段：
基于风险和优先级为某次迭代选择一些场景，形成“稻草人式的架构”，并对场景进行描述，以识别主要的抽象。将所发现的架构元素分布到四个蓝图中。然后实施、测试该架构，捕获经验教训。
循环阶段：
重新评估风险。扩展考虑的场景，选择能够减轻风险或提高结构覆盖的额外的少量场景。试着在原架构中描述这些场景，发现额外的架构元素，更新四个主要视图。根据变更修订现有场景，升级实现工具以支持新的场景。测试、评审视图，捕获经验教训。
终止循环。

架构的文档化 Documenting the architecture
架构的文档化：软件架构文档。软件设计准则。
标题
变更历史
目录
图清单
范围
引用
软件架构
架构目标与约束
逻辑架构
过程架构
开发架构
物理架构
场景
规模及性能
质量
附录
缩写词表
定义
设计原则

总结：
“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。
“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。
思考：
框架、架构和设计模式的区别？
软件架构文档中的视图是否越多越好？