软件架构视图
方法指导过程，过程包含步骤。
所谓软件架构就是关于如何构建软件的一些最重要的设计的决策，这些决策往往是围绕将系统分为哪些部分、各部分之间如何交互展开的。不同的涉众看待软件架构的视角是不同的。软件架构是抽象的概念，所以在软件架构概念与实践之间，似乎存在某种“鸿沟”——即缺失某种概念，而这种概念可以“链接”软件架构的概念和实际的开发实际的需要，为不同涉众理解和交流架构提供更专一的视角。为了在软件架构纯概念和实践之间搭起一座桥梁，可以引入软件架构视图的概念。软件架构师应当时时牢记：为用户而设计，不仅满足用户要求的功能，也要达到用户期望的质量。架构师也必须为客户而设计，适合的才是最好的。架构师还应该为开发人员而设计，关注软件的“开发期质量属性”（可扩展性、可移植性、易理解性和易测试性等非功能需求，都是属于软件开发期质量属性），为开发人员而设计。软件越来越复杂，单兵作战已经不再是普遍的软件开发方式，取而代之的是团队开发，而团队开发又反过来使软件开发更加复杂，因为现在不仅仅要面临技术复杂性的问题了，还有管理复杂性的问题。软件架构从大局着手，就技术方面的重大问题做出决策，构造一个由粗粒度模块组成的解决方案，从而可以把不同模块分配给不同小组分头开发。另一方面，软件架构设计方案规定了各模块之间如何交互的机制和接口，在开发小组之间起到“沟通桥梁”和“合作契约”的作用。配置管理员应该能够从软件架构方案中了解到开发出来的软件以什么样的目录结构存在，以及编译过后的软件目标模块放到哪个目录等决定，并以此作为制定配置管理基本方案的基础。所以，架构师应该为项目相关不同的角色而设计。软件架构师必须做到内外兼修、各层并重。只有这样，软件架构才能和它“包含了关于如何构建软件的一些最重要的设计决策”的“地位”相符。
一个软件架构视图是对与从某一视角或某一点上看到的系统所作出的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。软件架构的每个视图分别关注不同的方面，针对不同的目标和用户。软件架构师应当提供不同的软件架构视图，以便交流和传递设计思想。每个软件架构视图关注软件架构不同的方面，使问题得以清晰和简化，利于软件架构师完成架构设计的工作。项目不同角色观察软件架构的视角各不相同，每个视角涉及的需求和技术也不尽相同，所以将软件架构视图用作软件归档的手段是顺利成章的：但更为重要的是，软件架构视图可以被相对独立地分析和设计，这就使得软件架构师可以暂时撇开其他问题、专注于特定问题进行深入的分析和设计。
最常用的两种架构视图：逻辑架构视图和物理架构视图。当观察和描述事物大局的时候，逻辑架构和物理架构是最常用的角度。软件逻辑架构设计的三大核心任务：识别功能块；规划功能块的接口；明确功能块之间的使用关系和使用机制。软件的逻辑架构是架构设计思维的重要方法。用例技术已经成为捕获功能需求的事实标准，所以逻辑架构的设计往往是从用例分析开始的。基于用例的分析方法使逻辑架构的设计变得比较有序——通过对每个关键用例的分析，从逻辑上将用例实现为一组功能块的特定组合，最后综合这些用例分析成果，得到整个软件系统的逻辑架构。物理架构可以反映出软件系统运行时的组织情况。“物理元素”就进程、线程以及作为类的运行时实例的对象等，而进程调度、线程同步、进程或线程通信等则进一步反映物理架构的动态行为。物理层和分别有关，通过将一个整体的软件系统划分为不同的物理层次，可以把它部署到分别在不同位置的多台计算机上，从而为远程访问和负载均衡等问题提供了手段。物理层是大粒度的物理单元，它最终是由粒度更小的组件、模块和进程等单元组成。逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上。逻辑架构中关于职责划分的决策，体现为层、子系统和模块等的划分决定，从静态视角为详细设计和编程实现提供切实的指导；有了分解就必然产生协作，逻辑架构还规定了不同逻辑单元之间的交互接口和交互机制，而编程工作必须实现这些接口和机制。所谓交互机制，就是指不同软件单元之间的交互手段。交互机制可以是本地方法调用、基于RMI的远程方法调用、异步消息等。至于物理架构，它关注的是软件系统在计算机中运行期间的情况。软件的物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等需求。物理层作为组成软件系统的物理单元，最终又要映射到具体的硬件，这也是物理架构设计要考虑的，对于分布式软件系统的设计而言尤其不可或缺。
不同的视图支持不同的目标和用途。
软件架构师有许多工作要做：
- 要满足性能、持续可用性等方面的需求，架构师必须深入研究软件系统运行期间的情况、制定相应的设计决策，这些需求被称为软件的“运行期质量属性”；
- 而要满足可扩展性、可重用性等方面的需求，则要求架构师深入研究软件系统开发期间的情况，制定相应的设计决策，这些需求被称为软件“开发期质量属性”；
- 约束是一类特殊的需求，带有一定强制性，架构师制定的架构决策必须满足这些限制；
- 为了满足功能需求，架构师必须规划组成软件系统的所有模块，为他们分配不同职责，使这些模块可以通过协作完成功能需求。
架构师必须明确区分功能需求、约束、运行期质量属性和开发期质量属性等不同种类的需求。
架构设计的5视图方法包括：逻辑架构、开发架构、运行架构、物理架构、数据架构。逻辑架构关注功能，它们可能是逻辑层、功能模块和类等。开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装和部署到物理机器上，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。数据架构关注持久化数据的存储方案，不仅包括实体及实体关系的数据存储格式，还可能包括数据传递、数据复制和数据同步等策略。
逻辑架构的设计着重考虑功能需求，系统应当向用户提供什么样的服务。逻辑架构的关注点主要是行为或职责的划分。逻辑架构的静态方面关注抽象职责的划分，其动态方面关注承担不同职责的逻辑单元之间的交互。开发机构的设计着重考虑开发周期质量属性，例如可用性、可扩展性、易理解性和易测试性等。开发架构的关注点是在软件开发环境中软件模块的实际组织方式。运行架构的设计着重考虑运行期质量属性，例如性能、可伸缩性、持续可用性和安全性等。运行架构的关注点是系统的并发与同步等问题，这势必涉及到进程和线程等技术。运行架构的静态方面关注软件的运行时单元结构，其动态方面则关注运行时单元之间的交互机制。物理架构的设计着重考虑“安装和部署需求”，另外物理架构还应关注相关的可靠性、可伸缩性、持续可用性、性能和安全性等方面。数据架构的设计着重考虑“数据需求”。数据架构的关注点是持久化数据的组织、数据传输、数据复制和数据同步等策略。
五种架构视图，反映的是同一个软件系统的不同设计方面，它们最终合在一起才是完整的架构设计方案，所以不同的架构视图之间势必有相互支撑的关系。所谓保持架构视图之间的同步，就是保证不同视图之间是相互解释而不是相互矛盾的。如果需要，可以引入新的架构视图，从而更加突出和明确地制定和表达特定方面的架构决策。另外，约束是必须遵守和考虑到的，每个架构设计视图都应该注意这一点。五种不同的元素撑起了不同的思维空间，从而使每个架构视图重点覆盖不同种类的需求。
概念架构和实际架构
实际的软件架构设计过程是，一般应先进行概念性架构的设计，把最关键的设计要素和交互机制确定下来，然后再考虑具体技术的运用，设计出实际架构。概念性架构是对系统设计的最初构想。概念性架构没有严格的定义，而且也不应该过于严格的定义。概念性架构包括一些高层次的设计选择，对未来软件系统的质量和功能都起着关键影响。复杂系统的设计往往不能一蹴而就，而概念性架构就是最初的架构设计成果。
经典的分层架构的层指逻辑层（Layer），而现在的分布式应用的分层架构是指物理层（Tier）。逻辑层是一种功能和职责的组织单元，而物理层要求功能和责任的高聚合性，只不过往往是通过多个逻辑层映射到一个物理层这种方式实现的。
虽然概念性架构都跳不出“架构=组件+交互”的基本定义，但它们描述架构的具体方式还是差异很大的：有的重视逻辑层，有的重视物理层，有的通过隐喻表明机制，有的看上去似乎就是一些设计元素的组合。不同的概念性架构图中，“连接”所代表的含义千差万别：有的是依赖方向，有的是控制方向，有的是数据流向。由于概念架构的高度抽象性，使得同属一类的许多软件产品的概念性架构是趋同的。概念性架构非常相似，实际架构却可能有很大的差异。概念性架构往往和具体技术的运用、具体平台的选择无关，而实际架构非常关心这些问题。实际的架构设计方案应该兼顾不同的架构设计视图。概念性架构所包含的高层设计决策终究不会跳出如下多种架构视图的范围——逻辑架构、物理架构、开发架构、数据架构和运行架构。而实际架构必须设计到可以指导开发的程度。但务实地来讲，概念性架构经常从逻辑架构和物理架构的角度制定高层设计决策。
概念性架构是不可直接实现的。概念性架构和实际架构的一些区别，主要涉及到开发人员最关心的点：
接口如何定义；
子系统如何划分；
各子系统或模块之间的如何进行交互；
共同点：概念性架构和实际架构都满足软件架构的概念——无论是“架构=组件+交互”，还是“架构=重要的决策集”。
分层架构往往是我们架构思维的开始，在“分层”的基础上如何深入，细化设计，如何调整往往是架构设计的关键。
概念性架构往往和具体技术的运用和具体平台的选择无关，而实际架构则非常关系这些问题，概念性架构并不规定要采用OO技术，但设计实际架构时往往要考虑如何充分利用OO技术来实现概念性架构。从概念性架构到实际架构，先设计概念性架构，构思关键问题的解决策略；再进行实际架构设计，以保证为开发提供足够的指导和限制。