《软件架构理论与实践》 —1.3　软件架构的发展阶段

1.3　软件架构的发展阶段

软件架构自概念诞生之初便得到了广泛关注，至今已经历了一系列发展阶段。整体上来看，软件架构的发展可以分为如下几个阶段。

1.3.1　基础研究阶段（1968—1994）

术语“软件架构”在1968年的北大西洋公约组织会议上第一次出现，但并没有得到明确定义。直到20世纪80年代，“架构”一词在大部分情况下被用于表示计算机系统的物理结构，偶尔被用于表示计算机指令集的特定体系。从20世纪80年代起，为应对大型软件开发中存在的危机，对软件结构进行描述的方法开始在大型软件开发过程中广泛使用，并在实践中积累了大量经验，经研究者总结归纳，逐渐形成了以描述软件高层次结构为目的的理论体系，实质上形成了软件架构研究领域的雏形。在这一阶段，随着软件规模增大，开发者已经开始尝试模块化的实践，为后续软件架构理论的发展奠定了基础。

具体来说，模块化指的是一种软件开发方法，即把一个待开发的软件分解成若干小的简单的部分，称为模块。每一个模块都独立地开发、测试，最后再组装出整个软件。这种开发方法是对待复杂事物的“分而治之”的一般原则在软件开发领域的具体体现。

在软件中，模块是执行一个特殊任务或实现一个特殊的抽象数据类型的一组例程和数据结构，通常由接口和实现两部分组成。接口使得模块内部的具体实现被隐藏，使得能够面向接口开发而不是面向具体应用开发，体现了良好的封装性，易于独立的开发、修改和测试。

模块化开发方法涉及的主要问题是模块设计的规则，即系统如何分解成模块。在把系统分解成模块时，应该遵循以下规则：①最高模块内聚。也就是在一个模块内部的元素最大限度地关联。只实现一种功能的模块是最高内聚的，具有三种以上功能的模块则是低内聚的。②最低耦合。也就是不同模块之间的关系尽可能弱，以利于软件的升级和扩展。

③模块大小适度。粒度过大会造成模块内部维护困难，而粒度过小又会导致模块间的耦合增加。④模块调用链的深度（嵌套层次）不可过多。⑤接口干净，信息隐蔽。⑥尽可能地复用已有模块。

一般来说，模块的粒度小于服务组件的粒度。服务组件可以在应用之间复用。由于服务的调用通常是基于分布式协议（比如SOAP、HTTP、RMI/IIOP）的，且通常是远程调用，因此出于分布式请求性能的考虑一般粒度比较大。而当只想复用服务中特定的行为时，复制代码或者暴露新的服务接口都不是很好的选择，这时基于模块则可以得到一种更为优雅的解决方案。由于模块比服务粒度更小，而且又是一种部署单元，因此可以将这种特定的行为实现为模块，这样不仅支持复用，同时为组装应用带来了更大的灵活性。

随着全球化的发展趋势和全球化市场竞争压力的增加，一方面企业需要提高业务灵活性和创新能力；另一方面随着IT环境复杂度和历史遗留系统的增加，企业面临新的挑战。模块化的思想恰恰能够帮助企业从根本上解决这一问题，它一方面通过抽象、封装、分解、层次化等基本的科学方法，对各种软件组件和软件应用进行打包，提高对企业现有资产的重用水平和能力；另一方面，基于模块化思想，业界提出了面向服务架构（Service-Oriented Architecture，SOA）思想，它提供一组基于标准的方法和技术，通过有效整合和重用现有应用系统和各种资源实现服务组件化，并基于服务组件实现各种新业务应用的快速组装，帮助企业更好地应对业务的灵活性要求。它通过有效平衡业务的灵活性和IT的复杂度，为开发者提供了新的视角，有效拉近了IT和业务的距离。