根据我们关注的角度不同，可以将架构分成三种：

1.逻辑架构、软体系统中元件之间的关係，比如用户界面、资料库、外部系统接口、商业逻辑元件等等。

从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB伺服器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

一个物理架构的例子

2. 物理架构、软体元件是怎样放到硬体上的。　比如下面这张物理架构图描述了一个分布于北京和上海的分散式系统的物理架构，图中所有的元件都是物理设备，包括网路分流器、代理伺服器、WEB伺服器、套用伺服器、报表伺服器、整合伺服器、存储伺服器、主机等等。

3.系统架构、系统的非功能性特徵，如可扩展性、可靠性、强壮性、灵活性、性能等。　系统架构的设计要求架构师具备软体和硬体的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。　此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。 　首先，一个软体系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬体上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。　其次，进行软体设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特徵。这些决定中会有很多是一旦作出，就很难更改的。　根据作者的经验，一个基于资料库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的资料库套用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。

为了讨论和分析软体构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软体构架文档记录有这种描述。

我们决定以多种构架视图来表示软体构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。

构架视图显示了软体构架如何分解为构件，以及构件如何由连线器连线来产生有用的形式 【PW92】，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。典型

构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”【KRU95】。它包括：

用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。

逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。

实施视图：包括实施模型及其从模组到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模组分配的情况。它是实施模型的子集。

进程视图：包括所涉及任务（进程和执行绪）的描述，它们的互动和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。

配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在分散式系统中才需要该视图。它是部署模型的一个子集。 构架视图记录在软体构架文档中。您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。对于简单系统，可以省略 4+1 视图模型中的一些视图。

构

虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关：

模型的结构，即组织模式，例如分层。 基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。 几个关键场景，它们表示了整个系统的主要控制流程。 记录模组度、可选特徵、产品线状况的服务。

构架视图在本质上是整体设计的抽象或简化，它们通过捨弃具体细节来突出重要的特徵。在考虑以下方面时，这些特徵非常重要：系统演进，即进入下一个开发周期。 在产品线环境下复用构架或构架的一部分。 评估补充质量，例如性能、可用性、可移植性和安全性。 向团队或分包商分配开发工作。 决定是否包括市售构件。 插入範围更广的系统。

构架模式是解决复发构架问题的现成形式。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。构架模式示例

【BUS96】 根据构架模式最适用的系统的特徵将其分类，其中一个类别处理更普遍的结构问题。下表显示了 【BUS96】 中所提供的类别和这些类别所包含的模式。

软体架构（software architecture）是一系列相关的抽象模式，用于指导大型软体系统各个方面的设计。软体架构是一个系统的草图。软体架构描述的对象是直接构成系统的抽象组件。各个组件之间的连线则明确和相对细緻地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连线通常用接口_(计算机科学)来实现。

软体体系结构是构建计算机软体实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软体架构师或者系统架构师陈述软体构架以作为满足不同客户需求的实际系统设计方案的基础。

软体构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特徵。

测试软体架构

在“软体构架简介”中，David Garlan 和 Mary Shaw 认为软体构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协定；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”【IEEE98】。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。在 Rational Unified Process 中，软体系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行互动。

从和目的、主题、材料和结构的联繫上来说，软体架构可以和建筑物的架构相比拟。一个软体架构师需要有广泛的软体理论知识和相应的经验来事实和管理软体产品的高级设计。软体架构师定义和设计软体的模组化，模组之间的互动，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

是一般而言，软体系统的架构（Architecture）有两个要素：

它是一个软体系统从整体到部分的最高层次的划分。　一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。　详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

规则架构师的角色

建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。　在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关係统设计成败的最重要决定，必须经过非常慎重的研究和考察。

软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软体系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。

培养构架师

这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程式设计师会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。

但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设定专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。