软件体系结构——4+1视图（整理资料）
软件体系结构——4+1视图（整理资料）
架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。架构视图如同在建筑学中的不同种类的蓝图。
1. 背景
软件架构文档过分强调软件开发的某一个方面。
架构不能解决所有风险承担者所关注的问题。
每个软件系统都有多个风险承担者：最终用户、开发人员、系统工程师、项目经理等。
软件工程师欲使用单张视图来捕捉所有的系统架构要点，努力地在单一视图中表达超过其表达限度的蓝图。
使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的问题集合。
2. 视图模型 An Architectural Model
软件架构涉及到抽象、分解和组合、风格和美学。RUP4+1架构方法采用用例驱动，在软件生命周期的各个阶段对软件进行建模，从不同视角对系统进行解读，从而形成统一软件过程架构描述。
用例视图（Use Cases View），最初称为场景视图，关注最终用户需求，为整个技术架构的上线文环境.通常用UML用例图和活动图描述。
逻辑视图（Logical view），主要是整个系统的抽象结构表述，关注系统提供最终用户的功能，不涉及具体的编译即输出和部署，通常在UML中用类图，交互图，时序图来表述，类似与我们采用OOA的对象模型
处理视图（Process view）处理视图关注系统动态运行时，主要是进程以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题，在UML中通常用活动图表述。
物理视图（Physical view ）物理视图通常也叫做部署视图(deploymentview)，是从系统工程师解读系统，关注软件的物流拓扑结，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
开发视图(Development View)，描述软件在开发环境下的静态组织，从程序实现人员的角度透视系统，也叫做实现视图(implementation view)。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图，包图来表述。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
1 逻辑架构：
视 角：最终用户
关注点：功能性需求，即在为用户提供服务方面系统所应该提供的功能。
表示法：Booch标记法，UML（类图、交互图、顺序图、状态图），E-R图。
系统分解为一系列的关键抽象，表现为对象或对象类的形式。它们采用抽象、封装和继承的原理。
分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。
逻辑架构视图示例（UML类图）
2 处理架构
进程是构成可执行单元任务的分组。
视 角：系统集成者
关注点：非功能性需求，如并发性、分布性、系统完整性、容错性。
表示法：Booch标记法，UML（活动图、交互图、状态图）。
进程架构可以在多层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过LAN或者WAN连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。
软件被划分为一系列单独的任务。任务是独立的控制线程，可以在处理节点上单独地被调度。
区别主要任务、次要任务。
处理架构视图示例（UML活动图）
3 开发架构：
视 角：程序员、软件项目经理
关注点：软件开发环境下实际模块的组织（受开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制）。
表示法：Booch标记法，UML（包图）。
产品线的基础。
软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。
子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。
开发架构视图示例（UML包图）
4 物理架构：
视 角：系统工程师
关注点：依赖于硬件的非功能性需求，如可用性、可靠性、性能吞吐量和可伸缩性等。
表示法：UML（部署图）。
分别用于开发和测试、部署的物理配置。
软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。
物理架构视图示例（UML部署图）
5 场景：
视 角：所有视图的用户、评估人
关注点：系统一致性、验收。
表示法：用例文本，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
进程和进程组以不同的测试和部署配置映射至可用的物理硬件。
模型的剪裁 Tailoring the Model：
并不是所有的软件架构都需要“4＋1”个视图。无用的视图可以从架构描述中省略。
场景对于所有的情况均适用。
迭代过程：
场景驱动的方法。
开始阶段：
基于风险和优先级为某次迭代选择一些场景，形成“稻草人式的架构”，并对场景进行描述，以识别主要的抽象。将所发现的架构元素分布到四个蓝图中。然后实施、测试该架构，捕获经验教训。
循环阶段：
重新评估风险。扩展考虑的场景，选择能够减轻风险或提高结构覆盖的额外的少量场景。试着在原架构中描述这些场景，发现额外的架构元素，更新四个主要视图。根据变更修订现有场景，升级实现工具以支持新的场景。测试、评审视图，捕获经验教训。终止循环。
总结：
“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。
“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。
思考：
框架、架构和设计模式的区别？
软件架构文档中的视图是否越多越好？
转载自：
1. 软件体系结构——4+1视图（整理资料）
2. 软件架构RUP 4+1 视图模型
转载自原文链接, 如需删除请联系管理员。
原文链接：软件体系结构4+1视图模型，转载请注明来源！