“4+1”架构模型
- 逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
- 过程视图（Process View），捕捉设计的并发和同步特征。
- 物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
- 开发视图（Development View），描述了在开发环境中软件的静态组织结构。
- 场景视图
逻辑视图（LogicalView）
逻辑试图用来描述系统的功能需求，即在为用户提供服务方面系统所应该提供的功能。在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（ProblemDefinition)。在面向对象技术中，表现为对象或对象类的形式，采用抽象、封装和继承的原理。用对象模型来代表逻辑视图，可以用类图（Class Diagram）来描述逻辑视图。借助于类图和类模板的手段 ，类图用来显示一个类的集合和它们的逻辑关系：关联、使用、组合、继承等。相似的类可以划分成类集合。类模板关注于单个类，它们强调主要的类操作，并且识别关键的对象特征。
逻辑视图的表示法：
构件(Components)：类、类服务、参数化类、类层次
连接件(Connectors)：关联、包含聚集、使用、继承、实例化
逻辑视图的风格采用面向对象的风格，其主要的设计准则是试图在整个系统中保持单一的、一致的对象模型，避免就每个场合或过程产生草率的类和机制的技术说明。
过程视图（ProcessView）
又称“进程视图”，又称“处理视图”，考虑一些非功能性的需求，如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起，即定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。过程视图侧重系统的运行特性。服务于系统集成人员，方便后续性能测试。
Ø 构件：进程、简化进程、循环进程
Ø 连接件：消息、远程过程调用（RPC）、双向消息、事件广播 。
过程视图：关注进程、线程、对象等运行时概念，以及相关的并发、同步和通信等问题。
进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序（叫作”processes”）的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过 LAN 或者 WAN 连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。
接着，我们可以区别主要任务、次要任务。主要任务是可以唯一处理的架构元素；次要任务是由于实施原因而引入的局部附加任务（周期性活动、缓冲、暂停等等）。主要任务的通讯途径是良好定义的交互任务通信机制：基于消息的同步或异步通信服务、远程过程调用、事件广播等。次要任务则以会见或共享内存来通信。在同一过程或处理节点上，主要任务不应对它们的分配做出任何假定。
物理视图（PhysicalView）
又称“部署视图”，主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。物理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性能（吞吐量）和可伸缩性。
软件在计算机网络或处理节点上运行，被识别的各种元素（网络、过程、任务和对象），需要被映射至不同的节点；我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。
物理视图的表示法
Ø 构件：处理器、计算机、其它设备
Ø 连接件：通信协议等
开发视图（DevelopmentView）
描述了在开发环境中软件的静态组织结构，即关注软件开发环境下实际模块的组织，服务于软件编程人员。将软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。
系统的开发架构用模块和子系统图来表达，显示了”输出”和”输入”关系。完整的开发架构只有当所有软件元素被识别后才能加以描述。但是，可以列出控制开发架构的规则：分块、分组和可见性。
开发视图的风格通常是层次结构，每个层为上一层提供良好定义的接口，层次越低，通用性越好。
开发视图的表示方法：
Ø 构件：模块、子系统、层
Ø 连接件：参照相关性、模块/过程调用
大部分情况下，开发架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制。开发架构视图是各种活动的基础，如：需求分配、团队工作的分配（或团队机构）、成本评估和计划、项目进度的监控、软件重用性、移植性和安全性。它是建立产品线的基础。
场景视图
又称“用例视图”，它综合所有的视图。用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。
四种视图的元素通过一组重要场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。在某种意义上场景是最重要的需求抽象，它们的设计使用对象场景图和对象交互图来表示。
场景视图是其他视图的冗余（因此”＋1”），但它起到了两个作用：
作为一项驱动因素来发现架构设计过程中的架构元素。
作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明，又作为架构原型测试的出发点。
作为一项驱动因素，源于迭代开发中有场景驱动（scenario-driven）方法。场景驱动方法认为系统大多数关键的功能以场景（或 use cases）的形式被捕获。关键意味着：最重要的功能，系统存在的理由，或使用频率最高的功能，或体现了必须减轻的一些重要的技术风险。
架构设计文档模板
- 引言
整体介绍一下项目情况
1.1 编写目的
文档目的和阅读对象说明
1.2 名词和术语
【可选】名词和术语定义或解释 - 需求概述
2.1 关键功能需求
关键功能需求描述。关键功能包括核心功能、独特功能、其他影响架构决策的功能
2.2 关键质量需求
核心非功能需求识别与描述，如安全性、扩展性、性能等
2.3 系统约束
当前系统的约束或既定条件。特别是针对留存系统的架构设计这一块要重点说明。 - 系统场景
3.1 系统上下文
系统的参与者和关联的外部系统
3.2 系统用例
系统用例设计。用例图。 - 技术选型
技术选型决策。包括语言选择、核心技术组件选型、开发平台、运行环境等。 - 总体架构
概要性描述系统的全局设计结果 - 逻辑视图
6.1 子系统或组件划分
系统或组件的识别和分解
6.2 逻辑结构
系统的逻辑结构、组件关系、包关系 - 过程视图
7.1 通信协议
【可选】通信方案、协议定义
7.2 系统过程
系统的时序图、进程调用、活动图等 - 部署视图
系统的部署结构，部署图 - 数据视图
9.1 数据模型
核心数据模型及关联关系，类图
9.2 数据库设计
【可选】数据库表设计，性能考虑等，E-R图
9.3 接口设计
9.3.1 内部接口设计
【可选】系统内部各模块之间的接口设计
9.3.2 外部接口设计
【可选】与外部系统的接口设计，如WEB接口 - 关键问题设计
关键问题解决方案
10.1 关键功能设计
关键功能设计方案，核心技术等
10.2 关键质量设计
关键非功能问题设计方案，如安全性、扩展性、性能等 - 遗留问题
【可选】遗留问题描述 - 附录
【可选】参考资源等
备注：
（1）该架构设计模板整体上采用“4+1”视图模型，但是将“逻辑视图”和“开发视图”合并为“逻辑视图”，同时添加了“数据视图”概念。
（2）该架构设计模板比较适合中小型项目、系统或模块的设计，并不适合复杂的企业级架构设计。
附件
参考资源
http://www.cnitpm.com/pm/21856.html
http://www.uml.org.cn/zjjs/200910264.asp
http://blog.csdn.net/zxs9999/article/details/38703471