[软件架构训练基础教程-4]技术所有权

　　由于对象技术是占有统治地位的商业范式，所以我们了解可用于软件系统架构的主要的商业技术是很重要的。其中主要的两类包括专利软件和开放系统软件。

　　专利软件

　　专利软件（Proprietary software）是单个厂商的非兼容标准的产品。该厂商控制了多个重复的产品版本中的软件的形式和功能。目前的系统在建立的时候，它们在很高程度上依赖于商业软件。商业软件是软件重复使用的主要的形式，并且实际上它是单个企业中的一种更加高效的重复使用的形式。

　　因经营规模的扩大而得到经济节约是商业软件成为更加强大的重复使用的形式的一个原因。软件的大量副本被分发给客户，并且软件的除错和质量控制的程度远远超过了即使最大的终端用户企业的内部开发能力。当终端用户企业依赖于专利软件的时候，他们都是依赖于该厂商对于已有能力的持续的支持，并且从结构上说，很多终端用户依赖的厂商主张的很多的未来特性都将被添加到软件中。当专利软件以公共规范或标准的形式包装的时候，该规范通常成为单个软件实现的直接表现。

　　通常，当专利规范进入到公共领域的时候，这种专利实现一般不会被改变。当实际上没有必要修改下层技术的时候，它留下的印象是专利软件也可能成为一种开放系统的标准。当成千上万的软件许可被分发并且在已有的软件系统上运行的时候，这种现象特别真实。当专利技术向前发展的时候，厂商使用软件概念的唯一的解释来描述它们的产品。这种解释可能包括对面向对象原则的基本原理的修改。

　　 “我们规定建筑物的形状；从那以后建筑物就规定了我们的形式。”——Sir Winston Spencer Churchill

　　专利技术的最重要的方面是应用程序接口（API）的规定。专利软件的API定义了某种专利实现与增值应用软件（可能是独立软件厂商或最终用户提供建立的系统）之间的边界。随着专利软件技术通过多种方式演化，应用程序编程接口也可能改变。

　　新的能力仍然在持续不断地添加到专利软件中，这加剧了应用程序编程接口的复杂性。在很多情形中，专利软件的编程接口的复杂性远远超过了最终用户组织需要的功能。接着最终用户组织试图用多种方式管理这种复杂性就变为合适的了。

　　作为给专利编程接口增加新能力的补充，厂商有时可能会废弃软件中的一些接口。这样做会对应用软件产生重大的维护方面的影响。随着专利软件通过多种方式的演化，持续地升级软件以保持与专利厂商提供的主流支持活动同步，这一点对于用户很重要。当最终用户的系统落后了两个以上周期的时候，通常必须重新购买或完全重新修复该商业软件，这样才能与当前版本同步。很多最终用户发现在产品版本的少数周期中应用程序接口几乎全部是废弃的。

　　总之，专利软件版本和编程接口的演化成为应用程序开发人员和独立的软件厂商为了保持与可以使用的和受到支持的软件同步的单调的工作。这是应用程序用户和专利软件厂商之间的冲突，因为厂商利润的大部分可能由软件升级包的销售来驱动。

　　开放系统软件

　　另一类主要的商业软件是开放系统技术（图1）。从本质上说开放系统技术与专利技术是不同的。在开放系统技术中，多个厂商达成一致的规范，而这种规范不依赖于专利实现。这就是大多数正式的标准活动和多数社团标准活动的情形，它正在变得更加流行。在开放系统技术中，各种规范都支配着实现的行为。

图1.专利技术(a)和开放系统技术 (b)

　　它的关键的好处是多个厂商的实现接口的一致性。其它的优点还有术语和软件接口的一致，这是因为开放系统技术要求多个厂商达成一致。另一个优点是技术规范水平的增强和生命周期的延长。由于产品的开发是通过多个厂商组织并行进行的，引发市场需求的相应市场活动也是同步的和协调的。开放系统技术关键的优点之一是它提供了商业软件厂商之间的互通性。开放式系统和专利技术之间的差异对于面向对象的系统尤其明显，而它正在成为应用程序开发的主流，因为对象技术已经成为商业技术的主流。

　　商业信息技术一直在演化。日益满足应用程序需求的额外能力正在添加进来，并且通过商业技术逐渐可以使用了。但是在基础能力的商业技术（例如操作系统和编程语言）方面仍然需要大量的彻底的改造。

　　在有些商业技术（例如办公自动化、字处理和电子表格）中，很多功能被持续不断地重新组织并提供给最终用户，却没有显著的性能扩充。在很多人看来，商业端的技术演化的速度相对于竞争性的应用程序开发者的需求的增长较慢。商业技术的发布是为了满足大量用户的需求。这种软件的一般性超越了任何个别应用程序用户的需求。为了改变商业技术以满足应用程序的需求，就需要软件的配置和安装，它定制商业软件以适合特定应用程序的需要（图2）。

图2.商业软件的定制

　　定制商业技术的需求通常称为profiling。作为定制软件的补充，我们需要用牢固的特定应用软件来建立应用系统。因为对于多数应用需求来说，商业上可以使用的能力相对原始，所以这种需求驱动着一种不断增长的需求——建立越来越多的特定应用软件来完善应用系统的架构。随着系统从单用户演化到部门级再演化到企业级应用程序，其互通性也更强，可供使用的商业软和单独的用户软件之间的功能差异还会不断增加。

　　应用软件系统的架构在系统如何支持用户需求方面显得日益重要。电信行业之外的多数系统都是使用面向过程或其它的范式集成的，而这样做通常会造成无效的解决方案。实际上，对于共同开发组织建立的系统来说，大多数软件项目在完成时就被认为是失败的。从架构的观点来看，其中很多系统都类似于图3（a）中stovepipe系统中的构造。在stovepipe系统中有大量集成的软件模块，每个软件模块都有独特的软件接口，这些独特的软件接口分别与一种程序的实现相对应。

图3. Stovepipe系统（a）和组件架构（b）

　　系统集成的时候，它的不同部分之间存在很多一对一的依赖关系。这些依赖关系都是独特的集成方案。伴随着系统的大小随着模块数量不断增长，依赖关系的数量按模块数量的平方增长。这样的复杂性的增加带来了很多负面效果。特别是，随着系统的演化，修改和扩展变得越来越困难了。系统扩展恰恰是应用程序开发中的主要的成本驱动因素；它大约占了所有软件成本的一半【Horowitz 1993】。

　　建立系统的可选的方法之一是包含计划好的软件接口的定义，由它提供跨越集成方案的更高层次的一致性。组件架构是一种使用了一致的应用程序编程接口、跨越多个软件子系统实例所定义的应用系统（图4）。组件架构减少了软件模块之间的依赖关系，而依赖关系的减少使系统可以扩展，并且支持更大规模的集成。适当地建立的组件系统的软件集成的复杂性依赖于建立该系统所需要的软件模块的数量。