一、定义

          所谓软件架构，指的是软件系统的整体结构，包括软件子元素，这些元素的外部属性以及元素元素之间的关系。

这个定义包含了以下三层意思：

        （1）软件架构是对系统的抽象。它不仅规定了系统有哪些主要软件元素或模块，还定义了这些元素之间是如何交互的。它并不暴露每个元素的内部属性（也叫局部信息），也就是说每个子模块的私有信息是不划归到软件架构的范畴的。需要注意的是，每个元素的外部属性依然是软件架构的一部分。这里所谓的外部属性，指的是一个元素对其他元素所承担的责任实体，包括：提供的服务，所需的服务，性能特征，错误处理以及资源的使用。

           软件元素，一般分为组件，连接器和数据三种。一个组件是软件指令和内部状态的一个抽象单元，通过其接口提供对于数据的转换。一个连接器是对于组件之间的通讯、协调或者合作进行仲裁的一种机制。一个数据是组件通过一个连接器接收或发送的信息元素。

         数据的例子包括字节序列，消息，编码过的参数以及序列化过的对象，但不包括那些永久驻留或组件的私有信息。连接器的例子包括RPC远程过程调用、消息传递协议和数据流等。

         （2）每个软件系统都有一个架构。每个系统都是由一个或多个元素组成，并且这些元素之间都存在一定的关系。只有一个元素的系统是最简单的一种情况。

         （3）系统可能有多个视图。从不同的角度，系统可能获得不同的结构表示图。单单其中一个视图无法代表软件架构。软件架构是所有这些视图的总和。在一般情况下，你可以选择其中一个或几个结构视图用以对软件系统进行分析，理解或团队间沟通。


二、软件架构的作用

2.1 作为沟通媒介

          软件架构勾画了一个公用的框图，可供不同的人参阅，学习和理解。这使得我们对软件系统的理解和沟通更为顺畅，具体体现为：

（1）与用户讨论和协商软件需求；

（2）让客户及时了解我们的软件开发进展及大致成本；

（3）对实施管理层的决定和人力调配起到一定帮助作用。

2.2 对代码实现做出一定的限制

       一方面，软件架构对具体的软件的实现是描述性的，但另一方面，它对软件实现也是有限制性作用的。描述性可以帮助团队更好的理解软件系统，限制性可以对软件的设计和编码做出一定的限制。系统性的资源分配决定对子元素的实现也起到一定的限制作用。软件架构必须做出系统性的取舍和权衡(trade-off).

2.3 对项目的开发和进展起到纲领性作用

（1）可以帮助管理者在团队内部如何划分任务，确保每个团队成员明确自己的职责；

（2）可以帮助管理者做人力和其他开发成本预算。

（3）可以帮助组织开发文档。

（4）可以对软件的集成起到帮助作用；

2.4 定义了软件系统的质量属性。

包括但不限于：安全性、可扩展性、可修改性、可重用性、性能等

2.5 管理和应对变化

软件架构把变化归为三类：

（1）局部性变化。如，修改单个子元素或组件；

 （2）大范围变化。如，多个组件需要被修改；

（3）架构性变化。如修改整个系统拓扑视图，修改组件之间的通信模式或变更元素间的协调机制。

一个好的软件架构，一定是在改动最少的情况下，能够很好的自适应各种变化。

2.6 作为渐增和迭代开发的基础

（1）如建筑领域一样，软件架构应充当一个框架的作用。我们可以往框架填充软件组件。也就是说，软件元素是可以作为插件集成到系统里的；

（2）通过把某些软件功能划分到某个或某几个软件元素，我们可以分而治之，各个击破；

 （3）可以提前通过架构分析出哪些软件元素可能对项目的成功存在风险，进而对资源分配进行调整。

2.6 是一个可重用的模型

某个软件产品线，一般只有一个软件架构。但一个软件架构不应该只能适用于某个系统，它应该是一个模型，可以为多个系统和多种系统服务。软件设计者和开发者可以重用这些模型，受益于该模型，并将它运用到其他软件产品线