软件架构是软件抽象发展到一定阶段的产物，从编程的角度，可以清晰地看到软件抽象层次和表达工具的发展历史 。
- 20 世纪 60 年代是子程序的年代：出现了原始的软件架构，即子程序，并以程序间的调用为连接关系 。
- 20 世纪 70 年代是模块化的年代：出现了数据流分析 、 实体 — 关系图（ E-R 图） 、 信息隐藏等工具和方法，软件的抽象层次发展到了模块级 。
- 20 世纪 80 年代是面向对象的年代：基于模块化的编程语言进一步发展成面向对象的语言，继承性地增加了一种新元素之间的连接关系 。
- 20 世纪 90 年代是框架的年代：标准的基于对象的架构以框架的形式出现了。如电子数据表 、 文档 、 图形图像 、 音频剪辑等可互换的黑箱对象，可以相互嵌入。
- 当前（最近 10 年来）：中间件和 IT 架构作为标准平台出现，用可购买可复用的元素来构建系统，同时，基于架构的开发方法和理论不断成熟。
1 软件架构的定义
软件架构仍在不断发展中，还没有形成一个统一的、公认的定义，这里仅举出几个较权威的定义。
定义1：软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素 、 元素的外部可见属性及它们之间的关系组成。
定义2：软件架构为软件系统提供了一个结构 、 行为和属性的高级抽象，由构成系统的元素的描述 、 这些元素的相互作用 、 指导元素集成的模式及这些模式的约束组成。
定义3：软件架构是指一个系统的基础组织，它具体体现在：系统的构件，构件之间 、 构件与环境之间的关系，以及指导其设计和演化的原则上。（ IEEE1471-2000 ）
1.1 通俗定义
前两个定义都是按 “ 元素 — 结构 — 架构 ” 这一抽象层次来描述的，它们的基本意义相同，其中定义1较通俗。该定义中的 “ 软件元素 ” 是指比 “ 构件 ” 更一般的抽象，元素的 “ 外部可见属性 ” 是指其他元素对该元素所做的假设，如它所提供的服务 、 性能特征等。为了更好地理解软件架构的定义，特作如下说明：
（1）架构是对系统的抽象，它通过描述元素 、 元素的外部可见属性及元素之间的关系来反映这种抽象。因此，仅与内部具体实现有关的细节是不属于架构的，即定义强调元素的 “ 外部可见 ” 属性。
（2）架构由多个结构组成，结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的信息，但是个别结构一般不能代表大型软件架构。
（3）任何软件都存在架构，但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时，则该文档不能反映架构。
（4）元素及其行为的集合构成架构的内容。体现系统由哪些元素组成，这些元素各有哪些功能（外部可见），以及这些元素间如何连接与互动。即在两个方面进行抽象：在静态方面，关注系统的大粒度（宏观）总体结构（如分层）；在动态方面，关注系统内关键行为的共同特征。
（5）架构具有 “ 基础 ” 性：它通常涉及解决各类关键的重复问题的通用方案（复用性），以及系统设计中影响深远（架构敏感）的各项重要决策（一旦贯彻，更改的代价昂贵）。
（6）架构隐含有 “ 决策 ” ，即架构是由架构设计师根据关键的功能和非功能性需求（质量属性及项目相关的约束）进行设计与决策的结果。不同的架构设计师设计出来的架构是不一样的，为避免架构设计师考虑不周，重大决策应经过评审。特别是架构设计师自身的水平是一种约束，不断学习和积累经验才是摆脱这种约束走向自由王国的必经之路。
在设计软件架构时也必须考虑硬件特性和网络特性，因此，软件架构与系统架构二者间的区别其实不大。但是，在大多情况下，架构设计师在软件方面的选择性较之硬件方面，其自由度大得多。因此，使用 “ 软件架构 ” 这一术语，也表明了一个观点：架构设计师通常将架构的重点放在软件部分。
1.2 影响架构的因素
将软件架构置于商业背景中进行观察，可以发现软件架构对企业非常重要。
（1）影响架构的因素。软件系统的项目干系人（客户 、 用户 、 项目经理 、 程序员 、 测试人员 、 市场人员等）对软件系统有不同的要求开发组织（项目组）有不同的人员知识结构 、 架构设计师的素质与经验 、 当前的技术环境等方面都是影响架构的因素。这些因素通过功能性需求 、 非功能性需求 、 约束条件及相互冲突的要求，影响架构设计师的决策，从而影响架构。
（2）架构对上述诸因素具有反作用，例如，影响开发组织的结构。架构描述了系统的大粒度（宏观）总体结构，因此可以按架构进行分工，将项目组为几个工作组，从而使开发有序；影响开发组织的目标，即成功的架构为开发组织提供了新的商机，这归功于：系统的示范性 、 架构的可复用性及团队开发经验的提升，同时，成功的系统将影响客户对下一个系统的要求等。这种反馈机制构成了架构的商业周期。
2 软件架构的重要性
从技术角度看，软件架构的重要性表现为如下几方面。
（1）项目关系人之间交流的平台
软件系统的项目关系人分别关注系统的不同特性，而这些特性都由架构所决定，因此，架构提供了一个共同语言（公共的参考点），项目关系人以此作为彼此理解 、 协商 、 达成共识或相互沟通的基础。架构分析既依赖于又促进了这个层次上的交流。
（2）早期设计决策
从软件生命周期来看，软件架构是所开发系统的最早设计决策的 体现，主要表现为：
- 架构明确了对系统实现的约束条件：架构是架构设计师对系统实现的各方面进行权衡的结果， 是总体设计的体现，因此，在具体实现时必须按架构的设计进行。
- 架构影响着系统的质量属性：要保证系统的高质量，具有完美的架构是必要的（虽然不充分）。
- 架构可以用来预测系统的质量，例如，可以根据经验对该架构的质量（如性能）作定性的判 断。
- 架构为维护的决策提供根据。在架构层次上能为日后的更改决策提供推理、判断的依据。一个富有生命力的架构，应该是在最有可能更改的地方有所考虑（架构的柔性），使其在此点最容易进行更改。
- 架构有助于原型开发。可以按架构构造一个骨架系统（原型），例如，在早期实现一个可执行的特例，确定潜在的性能问题。借助于架构进行成本与进度的估计。
（3）在较高层面上实现软件复用
软件架构作为系统的抽象模型，可以在多个系统间传递（复用），特别是比较容易地应用到具有相似质量属性和功能需求的系统中。产品线通常共享一个架构。产品线的架构是开发组织的核心资产之一，利用架构及其范例进行多系统的开发，在开发时间 、 成本 、 生产率和产品质量方面具有极大的回报。基于架构的开发强调对各元素的组合或装配。系统开发还可以使用其他组织开发的元素，例如购买商业构件。
（4）架构对开发的指导与规范意义不容忽略
架构作为系统的总体设计，它指导后续的详细设计和编码。架构使基于模板的开发成为可能，有利于开发的规范化和一致性，减少开发与维护成本。架构可以作为培训的基础，有利于培养开发团队和培训相关人员。从软件开发过程来看，如果采用传统的软件开发模型（生命周期模型），则软件架构的建立应位于概要设计之前，需求分析之后。
基于架构的软件开发模型则明确地把整个软件过程划分为架构需求、设计、文档化、评 审（评估）、实现、演化等 6 个子过程。
3 架构模型
软件架构作为一个有机的整体，可以分解成多个侧面来认识，每个侧面强调它的不同方面的特征，从而使架构设计师能整体地把握它的重点。我们可以将软件架构归纳成5种模型：结构模型 、 框架模型 、 动态模型 、 过程模型和功能模型。最常用的是结构模型和动态模型。
3.1 五种模型
（1）结构模型
这是一个最直观 、 最普遍的建模方法。这种方法以架构的构件 、 连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置 、 约束 、 隐含的假设条件 、 风格 、 性质。研究结构模型的核心是架构描述语言。
（2）框架模型
框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
（3）动态模型
动态模型是对结构或框架模型的补充，研究系统“大颗粒”的行为性质。例如，描述系统的重新配置或演化。动态可能指系统总体结构的配置 、 建立或拆除通信通道或计算的过程。
（4）过程模型
过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。
（5）功能模型
该模型认为架构由一组功能构件按层次组成，且下层向上层提供服务。它可以看作是一种特殊的框架模型。
3.2 “4+1” 视图模型
这5种模型各有所长，也许将5种模型有机地统一在一起，形成一个完整的模型来刻画软件架构更合适。即将软件架构视为这些模型的统一体，通过这些模型的表述（文档）来完整反映软件架构。例如， Kruchten 在 1995 年提出了一个 “4+1” 的视图模型。 “4+1” 视图模型从5个不同的视角包括逻辑视图 、 进程视图 、 物理视图 、 开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件架构的全部内容。 “4+1” 视图模型如图 1 所示。
（1）逻辑视图
主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象 、 封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的 、 内聚的对象模型贯穿整个系统。
（2）开发视图
也称为模块视图，主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。开发视图要考虑软件内部的需求，如软件开发的容易性 、 软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。
（3）进程视图
侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性 、 分布性 、 系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
（4）物理视图
主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构 、 系统安装 、 通信等问题。当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。
（5）场景
可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。