从软件复用与构件化的视角优化架构

事实上，经过从上面三个方面审视架构，我们已经建立了一个完整的而且比较良好的架
构。但我们还需要从第四个方面在更高的层次审视我们的架构，需要考虑的又一个问题就是
软件的复用。复用可以大大降低后期成本，提高整个软件系统的可升级性与可维护性。我们
可以考虑哪些结构可以使用已经存在的可复用结构和产品，某些结构可以利用 GoF 的设计模
式设计可复用的构件已备后期使用。还需要根据需求分析得出的易变点仔细设计产品结构，
确保后期的变化不至于对产品带来太大的影响。而复用的一个重要的手段，就是面向构件的
方法。
1，软件复用
软件复用是指重复使用“为了复用目的而设计的软件”的过程。在过去的开发实践中，
我们也可能会重复使用“并非为了复用目的而设计的软件”的过程，或者在一个应用系统的
不同版本间重复使用代码的过程，这两类行为都不属于严格意义上的软件复用。
通过软件复用，在应用系统开发中可以充分地利用已有的开发成果，消除了包括分析、
设计、编码、测试等在内的许多重复劳动，从而提高了软件开发的效率，同时，通过复用高
质量的已有开发成果，避免了重新开发可能引入的错误，从而提高了软件的质量。在基于复
用的软件开发中，为复用而开发的软件架构本身就可以作为一种大粒度的、抽象级别较高的
软件构件进行复用，而且软件架构还为构件的组装提供了基础和上下文，对于成功的复用具
有非常重要的意义。
软件架构研究如何快速、可靠地用可复用构件构造系统的方式，着眼于软件系统自身的
整体结构和构件间的互联。其中主要包括：软件架构原理和风格，软件架构的描述和规范，
特定领域软件架构，构件如何向软件构架的集成机制等。
2，面向构件的方法简述
构件也称为组件，面向构件的方法包含了许多关键理论，这些关键理论解决了当今许多
备受挑剔的软件问题，这些理论包括：
构件基础设施
软件模式
软件架构
基于构件的软件开发
构件可以理解为面向对象软件技术的一种变体，它有四点原则区别于其它思想，封装、
多态、后期绑定、安全。从这个角度来说，它和面向对象是类似的。不过它取消了对于继承
的强调。
在面向构件的思想里，认为继承是个紧耦合的、白盒的关系，它对大多数打包和复用来
说都是不合适的。构件通过直接调用其它对象或构件来实现功能的复用，而不是使用继承来
实现它，事实上，在我们后面的讨论中，也会提到面向对象的方法中还是要优先使用组合而
不是继承，但在构件方法中则完全摒弃了继承而是调用，在构件术语里，这些调用称作“代
理”（delegation）。
实现构件技术关键是需要一个规范，这个规范应该定义封装标准，或者说是构件设计的
公共结构。理想状态这个规范应该是在行业以至全球范围内的标准，这样构建就可以在系统、
企业乃至整个软件行业中被广泛复用。构件利用组装来创建系统，在组装的过程中，可以把
多个构件结合在一起创建一个比较大的实体，如果构件之间能够匹配用户的请求和服务的规
范，它们就能进行交互而不需要额外的代码。
3，面向构件的软件模式
面向构件技术的特色在于：迅速、灵活、简洁，面向构件技术之于软件业的意义正如由
生产流水线之于工业制造，是软件业发展的必然趋势。软件业发展到今天，已经不是那种个
人花费一段时间即可完成的小软件。软件越来越复杂，时间越来越短，软件代码也从几百行
到现在的上百万行。把这些代码分解成一些构件完成，可以减少软件系统中的变化因子。
1）面向构件方法模式
面向构件技术的思想基础在软件复用，技术基础是根据软件复用思想设计的众多构件。
面向构件将软件系统开发的重心移向如何把应用系统分解成稳定、灵活、可重用的构件和如
何利用已有构件库组装出随需而变的应用软件。
基于面向构件的架构可以描述为：系统=框架+构件+组建。框架是所有构件的支撑框架;
每个构件实现系统的每个具体功能;组建，可以视为构件的插入顺序，不同构件的组成顺序不
同，其实现的整体功能也就不同。
面向构件技术将把软件开发分成几种：框架开发设计、构件开发设计、组装，如果用现
代的工业生产做比喻，框架设计就是基本的生产机器的开发研究，构件开发就是零件的生产，
组装就是把零件组装成汽车、飞机等等各种产品。
2）面向构件开发的不足之处
（1）系统资源耗费
从软件性能角度看，用面向构件技术开发的软件并不是最佳的。除了有比较大的代码冗
余外，因为它的灵活性在很大程度上是以空间和时间等为代价实现的。
（2）面向构件开发的风险
从细节来看，构件将构件的实现细节完全封装，如果没有好的文档支持，有可能导致构
件的使用结果不是使用者预期的。比如，构件使用者对某构件的出错机制认识不够
3）开放式系统技术
专用软件是由单个供应商生产的不符合统一标准的产品。这些单个供应商通过版本更换
来控制软件的形式与功能。但是谁这系统越来越复杂，当一个系统建立起来以后，往往更倾
向于依赖于通用的商业软件，这种依赖往往成为内部软件复用的非常有效的形式。正是这种
状态，我们需要讨论一下开放式系统技术这个问题。
商业软件成为复用的有效形式，主要原因是规模经济的作用，通用的商业软件的质量，
往往超过终端用户自主开发能力。
商业软件也可以在某个领域内实现专有，也就是提供应用程序接口（API）为应用软件
提供服务。当软件不断升级的过程中，这些接口的复杂性可能超出用户的需要，这就需要有
复杂性的控制。
一个解决方案就是实现开放式系统技术，开放式系统技术与专有技术有根本的不同。在
开放式系统技术中，由供应商组织来开发独立于专有实现的规范，所有的供应商实现的接口
都严格的一致，并且规定了统一的术语，这样就可以是软件的生命周期得以延长，这种开放
式系统技术特别适合于面向对象的方法。
为了使商业技术能适应各种应用需求，对软件开发和安装就有一定的要求，这种要求称
之为配置（profiling），适当的配置软件的嵌入也称为开放是软件的一个特点。
从架构的角度来看，不少系统结构具有大量的一对一接口和复杂的相互连接关系，这种
模型被称之为“烟囱”模型，当系统规模增大以后，这种关系会以平方律的速度增加，复杂
性的增加会带来相当多的问题，尤其是升级和修改越来越难以进行，而系统的可扩展性恰恰
是开发成本的重要部分。
为此，我们可以建立一个称之为对象管理器的层，用于统一协调各个对象的沟通，从可
维护性角度这是一个比较好的结构，但是在某些特别强调效率的点可以避开它。系统的架构
的一个重要原则就是对软件接口定义一个已经规划的定义，为系统集成方案提供更高的统一
性，软件的子系统部分要由应用程序接口来定义。这样，就削弱了模块之间的依赖性，这样
的系统就比较容易扩展和维护，并且支持大规模的集成。
经过从四个方面审视我们的架构，经过分析、权衡、设计和部分编码，我们就可以得到
一个稳固的架构。这个架构经过经过评审，就可以作为后期开发的基础架构.