第一节：视图间的关联
图1 整体结构
用例视图（Use Cases Vie：最初称为场景视图（Scenarios）,关注最终用户需求,为整个技术架构的上线文环境.通常用UML用例图和活动图描述。
逻辑视图（Logical view）：主要是整个系统的抽象结构表述，关注系统提供最终用户的功能，不涉及具体的编译即输出和部署,通常在UML中用类图,交互图,时序图来表述,类似与我们采用OOA的对象模型。
开发视图(Development View)： 描述软件在开发环境下的静态组织，从程序实现人员的角度透视系统,也叫做实现视图(implementation view).开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图,包图来表述. 开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
进程视图 （Process view）：关注系统动态运行时,主要是进程以及相关的并发、同步、通信等问题。进程视图 和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题,在UML中通常用活动图表述。
物理视图（Physical view ）：通常也叫做部署视图(deployment view),是从系统工程师解读系统，关注软件的物流拓扑结，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
第二节 详细介绍各个部分如何应用及例子
1 逻辑架构：
视 角：最终用户
关注点：功能性需求，即在为用户提供服务方面系统所应该提供的功能。
表示法：Booch标记法，UML（类图、交互图、顺序图、状态图），E-R图。
系统分解为一系列的关键抽象，表现为对象或对象类的形式。它们采用抽象、封装和继承的原理。
分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。
图2：逻辑架构的图例1
2 处理架构
进程是构成可执行单元任务的分组。
视 角：系统集成者
关注点：非功能性需求，如并发性、分布性、系统完整性、容错性。
表示法：Booch标记法，UML（活动图、交互图、状态图）。
进程架构可以在多层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过LAN或者WAN连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。
软件被划分为一系列单独的任务。任务是独立的控制线程，可以在处理节点上单独地被调度。
区别主要任务、次要任务。
图3：逻辑架构的图例2
3 开发架构：
视 角：程序员、软件项目经理
关注点：软件开发环境下实际模块的组织（受开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制）。
表示法：Booch标记法，UML（包图）。
产品线的基础。
软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。
子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。
图4：逻辑架构的图例3
4 物理架构：
视 角：系统工程师
关注点：依赖于硬件的非功能性需求，如可用性、可靠性、性能吞吐量和可伸缩性等。
表示法：UML（部署图）。
分别用于开发和测试、部署的物理配置。
软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。
图5：逻辑架构的图例4
5 场景：
视 角：所有视图的用户、评估人
关注点：系统一致性、验收。
表示法：用例文本，UML（用例图）。
在某种意义上场景是最重要的需求抽象。
该视图是其他视图的冗余（因此“＋1”）。
场景视图的两个作用：
作为一项驱动因素来发现架构设计过程中的架构元素。
作为架构设计结束后的一项验证和说明功能。
图6：逻辑架构的图例5
