软件复用简述

软件复用的主要思想是，将软件看成是由不同功能部分的“组件”所组成的有机体，每一个组件在设计编写时可以被设计成完成同类工作的通用工具，这样，如果完成各种工作的组件被建立起来以后，编写一特定软件的工作就变成了将各种不同组件组织连接体来的简单问题，这对于软件产品的最终质量和维护工作都有本质性的改变。软件复用(SoftwareReuse)是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的成本。软件复用不仅仅是对程序的复用，它还包括对软件开发过程中任何活动所产生的制成品的复用，如项目计划、可行性报告、需求定义、分析模型、设计模型、详细说明、源程序、测试用例等。这里有一点需要区分清楚的是，在一个系统中多次使用一个相同的软件成分，则不称作复用，而称作共享；对一个软件进行修改，使它运行于新的软硬件平台也不称作复用，而称作软件移植。（1）代码的复用包括目标代码和源代码的复用。其中目标代码的复用级别最低，历史也最久，当前大部分编程语言的运行支持系统都提供了连接（Link）、绑定(Binding)等功能来支持这种复用。源代码的复用级别略高于目标代码的复用，程序员在编程时把一些想复用的代码段复制到自己的程序中，但这样往往会产生一些新旧代码不匹配的错误。想大规模的实现源程序的复用只有依靠含有大量可复用构件的构件库。如”对象链接及嵌入”（OLE）技术，既支持在源程序级定义构件并用以构造新的系统，又使这些构件在目标代码的级别上仍然是一些独立的可复用构件，能够在运行时被灵活的得新组合为各种不同的应用。（2）设计的复用设计结果比源程序的抽象级别更高，因此它的复用受实现环境的影响较少，从而使可复用构件被复用的机会更多，并且所需的修改更少。这种复用有三种途径，第一种途径是从现有系统的设计结果中提取一些可复用的设计构件，并把这些构件应用于新系统的设计；第二种途径是把一个现有系统的全部设计文档在新的软硬件平台上重新实现，也就是把一个设计运用于多个具体的实现；第三种途径是独立于任何具体的应用，有计划地开发一些可复用的设计构件。（3）分析的复用这是比设计结果更高级别的复用，可复用的分析构件是针对问题域的某些事物或某些问题的抽象程度更高的解法，受设计技术及实现条件的影响很少，所以可复用的机会更大。复用的途径也有三种，即从现有系统的分析结果中提取可复用构件用于新系统的分析；用一份完整的分析文档作输入产生针对不同软硬件平台和其它实现条件的多项设计；独立于具体应用，专门开发一些可复用的分析构件。（4）测试信息的复用主要包括测试用例的复用和测试过程信息的复用。前者是把一个软件的测试用例在新的软件测试中使用，或者在软件作出修改时在新的一轮测试中使用。后者是在测试过程中通过软件工具自动地记录测试的过程信息，包括测试员的每一个操作、输入参数、测试用例及运行环境等一切信息。这种复用的级别，不便和分析、设计、编程的复用级别作准确的比较，因为被复用的不是同一事物的不同抽象层次，而是另一种信息，但从这些信息的形态看，大体处于与程序代码相当的级别。由于软件生产过程主要是正向过程，即大部分软件的生产过程是使软件产品从抽象级别较高的形态向抽象级别较低的形态演化，所以较高级别的复用容易带动较低级别的复用，因而复用的级别越高，可得到的回报也越大，因此分析结果和设计结果在目前很受重视。用户可购买生产商的分析件和设计件，自己设计或编程，掌握系统的剪裁、扩充、维护、演化等活动。不同层面的复用（1）技术层面的复用通常包含三类:①通用基本组件:是应用系统的基本构成成分，如基本的数据结构、用户界面元素等，它们大同小义的存在于各种应用系统中。②领域共性组件:是应用系统所属领域的共性构成成分，它们存在于该领域的各个应用系统中。③应用专用组件:是每个应用系统的特有构成成分。应用系统开发中的重复劳动主要在于前两类构成成分的重复开发。在应用系统的前两类中，越靠底层的部分越容易复用，所以人们在软件复用方面的研究和应用经历了从底层到高层的过程，先后经历了库函数、面向对象、软件组件、开发框架等。目前各种开发框架复用已经得到广泛应用，例如在系统整体结构设计规划，包括全局组织与控制结构，组件间通信、同步和数据访问的协议，伸缩性和性能设计选择等。由于开发框架本身的通用性造成其组件粒度比较小，抽象程度比较高。所以，开发框架复用覆盖了可复用软件组件的所有活动。当开发同一领域中的新应用时，可以根据开发模型复用确定新应用的需求规格，并以此为基础选择可复用组件进行组装，从而形成新系统。（2）业务层面的复用许多开发者的软件复用大多是从技术角度出发的，例如J2EE组件框架是一个以库、类和接口形式提供的基础架构，最终构成应用的业务逻辑和表现/控制逻辑则要由建立在这个框架上的业务组件实现。而实际上，应用软件最终要解决的却是应用问题或者说是业务问题，如果软件能够在更高层次的业务层面上进行大范围复用，那么对提高软件开发效率的作用将会更大。由于大部分软件的开发过程是从抽象级别较高的形态向抽象级别较低的形态演化，所以较高级别的复用容易带动较低级别的复用，因而复用的级别越高，可得到的回报也越大。因为无论使用哪种技术，都需要首先形成一个个遵循一定业务规则、执行一定业务逻辑并管理一定数据，可在某一领域内多种项目中重复使用的组件。他们不同于Struts、JdonFramework、Hibernate这样的技术组件或者由技术组件形成的框架，后者并不能解决特定的业务问题，而是为业务组件提供赖以生存的运行基础。快速适应需求变化的软件复用-转载(2007-10-1318:46:54)转载▼原文:软件复用本质是为了快速适应不断变化的需求（adapttochangingneeds），两者目标是一致的，但是当我们过于注重软件复用（如组件复用componentreuse又译构件复用）时，千万需要牢记：快速适应不断变化的需求是根本目的，它的重要性要重于组件复用技术本身。本文试图阐述两者概念比较以及时下流行的组件复用技术概要。适应需求变化现如今是一个计划赶不上变化的时代，企业竞争力逐渐表现在企业适应变化能力的竞争，谁能更快适应市场的变化，谁就能够在竞争中胜出，这种快速适应能力如果靠“人民战争”无疑是不现实的，软件可以帮助我们来适应这种快速变化。谈到这里，稍微再说明一下国人软件教育的误区，不错，软件曾经是科学计算的工具，因此，我们非常注重软件的算法和数据结构，甚至将之作为数学的衍生物，但是，现如今已经成为一种帮助我们快速响应变化的有力工具，如果我们的教育背景中只有算法和数据结构，能够编制出应付快速变化的软件吗？很显然，他们是风马牛不相及，由此可见国人软件概念和软件教育的落后性，在这样的软件认识背景下，固然设计模式的崇高位置得不到确立，软件设计被抛弃在脑后，编制出的大多数企业软件系统根本不具备应付变化的能力，程序员拒绝频繁更改程序，甚至借助技术原因阻扰软件的频繁更改，这种软件程序员和软件用户之间的矛盾可以称为miscommunication，miscommunication是导致软件系统的失败一个重要原因。国内早就有著名言论：“不上ERP等死；上了ERP找死”，如果你的企业不上ERP，那么你的企业就不能借助软件应付快速的市场等环境变化，那么必然会被淘汰；但是，如果上了一个不注重“适应需求变化”的ERP软件系统，那就是企业被僵化的ERP软件框死，丧失了使用ERP的根本目的。适应需求变化则成为现代软件系统一个孜孜不倦的追求目标，那么如何实现呢？原则：给予人们可以裁剪他们系统的能力应适应需求变化，建立一个适应需求变化的系统，允许系统在一系列小的、可控制的步骤上进行改变。组件诞生将不变的通用的东西抽象出来，以达到在不同项目中重用复用，将我们有限的精力集中在项目具体变化和特点上。当然这些抽象复用的东西之间彼此必须是松耦合，这样才能根据需求挑选组合。让我们先回顾一下软件的发展史，软件开发的发展史实际是一部我们思维不断抽象拔高的发展过程，这种抽象概念非常类似于建模的思考方式：概要贴切地描述事物，忽视次要的细节。抽象体现在软件开发上就是每个具体项目需要完成的代码行数量越来越少。从1970到1980这段时间，软件开发从机器语言到汇编语言。进而发展到高级语言，甚至一些CASE工具，面向功能编程发展到面向对象编程，功能模块重用细化到类的重用，类的重用是最初是通过设计模式实现的。进入90年代中期，诞生了基于组件的开发模式（CBD：componentbaseddevelopment），CBD将抽象概念带往了一个新的方向，与减少代码数量相反，CBD将功能各个方面细化分离到不同的、相互隔离层中，如表现层、业务逻辑层、持久层、安全层以及核心层等，并且可以管理这些组件之间的依赖关系，通过这种分离，我们可以提纯细化组件功能，进而产生可以重用的框架，如Struts框架可以重用在大部分应用系统的表现层中，，Struts+JdonFramework+Hibernate是一个框架组合，代表一种架构设计，这种架构设计其实可以重用在大部分应用系统，这种重用我称之为架构级别重用。组件复用软件组件(Softwarecomponents)是软件提供业务或技术功能的基本单元或元素，这些单元可以独立地被部署、他们可以自我管理并且被虚拟部署到网络的任何地方，业务组件（(Businesscomponents)执行业务逻辑、遵循一定的业务规则并且管理相应的数据（数据库操作称为managecorporatedata）；而技术组件(Technicalcomponents)则提供相应的平台以便业务组件可以依赖其上运行，例如权限、组件管理等。JdonFramework/Spring都属于一种技术组件框架，而我们具体项目的业务层代码如果能够提炼可以复用，则是业务组件；JdonFramework/Spring则都提供了业务组件赖于运行的一些核心底层机制，特别是组件的管理，如组件的创建、组件的获得、组件的资源管理、组件的消亡等生命周期支持，所以，我们可以在JdonFramework/Spring中加入自己的业务组件，当然，JdonFramework还提供了Session等状态管理的支持功能，为业务组件提供了更广阔的生命周期支持。组件复用技术以前是停留在编译前期，也就是说：我们在编程时，导入所需要的其他组件Jar包，然后混同我们的项目编译部署，但是这需要通过专业技术人员实现，很显然是不能适应原则中第一句：给予人们可以裁剪他们系统的能力应适应需求变化，这里的“人们”应该是指软件最终用户，应该给予用户自己改变系统的能力，也就是说：需要提供软件系统运行时能够动态改变自身的能力。组件复用技术以前停留在软件编译阶段，现在则更靠前，必须在软件运行阶段，当然对技术要求相当高，需要语言支持RTTI（简单又神秘的Class.forName发挥作用了），这在Evolution,Architecture,andMetamorphosis一文中被认为是Metamorphosis，现在由于AOP技术出现，AOP有一种动态Weaving技术，实际就是在软件运行时实现动态拦截，这样给予终端用户更大的改变系统能力，他们基本可以以动态插拔的概念实现多个组件的组合运行。在AOPvsDecorator一文中，我把编译阶段的组件组合方式（我更愿意称为静态组合）和运行时组合等两种处理方式，合并称为过滤器模式，如果你希望采取组件可插拔式的复用，就可以使用过滤器模式。组件可插拔更换为什么说组件的可插拔非常重要？组件重用目的是为了更好地适应需求变化，但是有了组件重用不代表就快速适应需求变化，因为组件本身也会产生设计错误（提炼得不够抽象或者组件很难以替代），这就必然导致软件系统得维护成本提高，那么快速适应需求变化的目标也就成为一纸空文。实践证明：组件设计问题已经成为导致软件开发失败的一个主要因素。组件设计有两个主要风险：组件提纯的纯度和组件的替代方式。提炼的纯度也就是抽象的高度，组件的抽象程度越高，当然可重用范