软件重用已经死亡？软件重用永存？_Java教程

　　许多WebLogic项目的软件架构师或项目负责人已经在重用的努力中备受挫折，而且死板的CASE工具套件用于开发可重用软件时给许多开发人员留下了坏印象。因此，究竟是什么改变了从而使得今天软件重用得以可行？在这个要害时刻，三个要害因素使得人们觉得软件重用计划值得考虑或重新考虑：
　　· 成熟、基于组件的开发环境。
　　· Web服务和面向服务的体系结构。
　　· 面向重用的软件工程过程和工具。
　　我将讨论为什么三个因素中的每一个对于有效软件重用的目标都非常要害，并且许多情况下，在越来越多IT机构中，为什么它们和商业因素结合在一起使软件的重用计划成为标准操作过程中的强制执行部分。
　　
　　成熟的、基于组件的开发环境
　　当回顾过去20年的软件开发时，无论在编程技巧的精巧方面，还是在供开发人员使用的特定于语言的服务方面，我们都可以看到一个稳健的过程。从早期C只有有限的标准库，而且很多事情依靠智力来自己做，到结构化编程的提出，以及到面向对象编程迅速壮大的早期阶段，到CORBA的分布式组件基础结构和服务，到今天的现代J2EE和.NET组件架构，我们可以区分出一些使创建和使用可重用软件可行的主要因素。
　　
　　结构化编程技术对模块调用者使用的明确定义的功能协议概念有所贡献。根据其前提条件、期望的输入和输出参数（包括那些参数的语义）、副作用以及调用所描述函数可能引起的任何违例条件等来定义一个协议，该定义对在调用者和被调用模块之间传递明确的描述。
　　
　　面向对象编程引入了数据封装和多态的概念，它们都对有效的软件重用有所贡献。数据封装避免将底层数据结构暴露于对象的调用者。这些数据结构用于治理持久数据，并答应信息传递给与调用者目标更加准确的方法调用。多态在将调用代码和实现分离的同时，使类的开发人员能够提供含义丰富的抽象，这些抽象与根据特定算法需求调整的内部灵活的实现结合在一起。
　　
　　进一步讨论一下分离的概念，分布组件技术为开发人员提供了定义和部署粗粒度组件接口的能力，其底层实现汇集了一组处理通用数据和功能目标的相关操作。尽管早期组件基础结构提供的工具（如CORBA）有所限制，并且开发人员经常必须成为"火箭科学家"来使所有东西能够正确地协同工作，但是假如做得正确，作为结果，部署后的组件情形将会提供一个有效的、灵活的、可重用的应用程序基础结构。
　　
　　最后，随着两个主要的组件体系结构（J2EE 和.NET）的成熟，为开发人员提供了一个丰富而稳定的平台，在该平台上可以构建和部署它们的组件。这两种体系结构提供的技术服务，例如事务完整性、消息传递和目录服务、安全、异常处理、远程访问，以及许多其他许多服务，他们使开发人员能够将注重力集中在组件功能上，而无需关注工作需要的所有底层技术基础结构。
　　
　　Web服务和面向服务的体系结构
　　我相信您正在迷惑一些问题，"难道Web服务与面向服务的体系结构不具有相同含义吗？面向服务的体系结构是什么样的？它和Web服务有什么区别？"简单来说，面向服务的体系结构是一个这样的体系结构：应用程序功能集中在一起，呈现一种独立于其底层实现的松散耦合形式。这些松散耦合的服务典型地呈现粗粒度能力，这意味着它们通过某种形式的消息传递运行库能够汇集在一起。
　　
　　也可以说，许多（假如不是大多数的话）面向服务的体系结构利用了正被主要应用服务器厂商实现和促进的基于Internet的Web服务基础结构。
　　
　　Web服务和面向服务体系结构的特性鼓励重用，实际上从本质上来说它们也需要重用，因为服务的唯一目标是将一整套功能向多个消费者公开。假如这都不是重用，那什么是呢？另外，因为服务意味着部署一次，就能在适当的位置访问它，它们鼓励跨越应用程序边界的业务流程集合的概念 -- 使一系列支持业务流程的服务交织在一起，业务流程可能通过图形化的设计时用户界面来描述。尽管支持这一概念的工具和底层机制还处于初期，但是一些计划，如BPEL4WS（Business Process Execution Language For Web Services），在启用这种形式的应用程序开发时做出了很大的承诺。尽管期望图形应用程序集合将会完全取代其他开发技术的想法不太现实，但是它确实在那些技术旁找到了自己的位置，并且在这个过程中，鼓励底层服务的更有效的重用。
　　服务和组件之间具有支持软件重用的共生关系。组件通常是服务背后的底层机制，或者完全实现了服务所定义的功能，或者为使用一个或多个遗留系统连接到现代web服务基础结构提供了必需的附带代码。
　　
　　软件工程过程和工具
　　过去的十年已经朝着遵守规则和有效的软件开发环境迈进了一大步。迭代方法，比如RUP（Rational Unified Process）鼓励要害需求的早期发现、实施和提炼。在有规律和及时基础上的增量改进与重量级的瀑布方法有巨大差别，瀑布方法经常导致软件的晚交付，并且无法满足用户需求，这种情况不少，因为用户需求经常会随时间改变。
　　RUP和其他软件开发环境通过在开发过程中引入特定的Software Development Asset （SDA）搜索和重用回顾检查点来鼓励重用。这些搜索和回顾活动发生在开发生命周期的所有层次上，从最初的需求定义，到分析和设计，以及到实施。现代基于UML的建模技术也通过为分析师和开发人员提供一个明确定义功能需求的简单图形方式来鼓励重用。这种形式的需求可以被其他开发工具使用，比如代码生成器、映射引擎和资产元数据资料库。基于UML的IDE工具不仅可以用于创建UML，而且也适用于可重用的知识SDA，例如设计模式到结果代码，自动在源代码和模型之间保持一致。
　　
　　重用的商业例子
　　有了这些工具和技术的帮助，并且经历着不断地消减IT预算的压力，在任何规模的IT机构中都不难看到重用计划的正当理由。Dr. Jeffrey Poulin是闻名的软件行业重用专家，曾经进行了很多研究，指明重用的回报发生在SDA的第一次重用时，他甚至考虑了建立重用资产所需的额外努力。Michael Blechar是Gartner Research的副总裁和研究总监，他指出，"企业可以通过提交的软件资产重用计划充分提高应用程序开发效率和质量，比例可达5:1或更高，同时也减少了上市的时间。考虑到这一点，分析师和开发人员都必须具有查找和重用这些资产的能力"。花些时间研究这些鼓励重用的工具。（我将在以后编辑的文章中更具体地讨论这些过程和工具）。甚至那些看上去很简单的事情，比如向开发团队传播体系结构方面的指导以及通过资产元数据资料库分布的UML模型，通过使用行业和组织的最佳实践来实现的代码，从而获得显著的回报。这样就会大大地减少重新编写代码和增加沉重的维护成本的机会。在您的组织中添加用于定义和分发结构良好的、粗粒度组件和服务的能力，可以加速开发效率，同样重要地，可以大幅度提高应用程序的一致性 -- 可能也会使您在这场交易中成为英雄！