软件复用与项目需求变化

软件复用与项目需求变化

软件复用本质是为了快速适应不断变化的需求(adapttochangingneeds)，两者目标是一致的，但是当我们过于注重软件复用(如组件复用componentreuse又译构件复用)时，千万需要牢记：快速适应不断变化的需求是根本目的，它的重要性要重于组件复用技术本身。本文总结了软件复用的不同层次：设计复用、组件架构复用以及业务模型复用，复用技术的不断发展正是由于适应变化需求的要求不断提高导致，本人从2002年开始从事复用技术研究，最初从复用层次底层设计模式开始，在国内媒体第一次全面分析了GoF设计模式，经过这几年发展，亲身体会复用技术已经进入了一个新的阶段。1、适应需求变化现如今是一个计划赶不上变化的时代，企业竞争力逐渐表现在企业适应变化能力的竞争，谁能更快适应市场的变化，谁就能够在竞争中胜出，这种快速适应能力如果靠“人民战争”无疑是不现实的，软件可以帮助我们来适应这种快速变化。谈到这里，稍微再说明一下国人软件教育的误区，不错，软件曾经是科学计算的工具，因此，我们非常注重软件的算法和数据结构，甚至将之作为数学的衍生物，但是，现如今已经成为一种帮助我们快速响应变化的有力工具，如果我们的教育背景中只有算法和数据结构，能够编制出应付快速变化的软件吗?很显然，他们是风马牛不相及，由此可见国人软件概念和软件教育的落后性，在这样的软件认识背景下，固然设计模式的崇高位置得不到确立，软件设计被抛弃在脑后，编制出的大多数企业软件系统根本不具备应付变化的能力，程序员拒绝频繁更改程序，甚至借助技术原因阻扰软件的频繁更改，这种软件程序员和软件用户之间的矛盾可以称为miscommunication，miscommunication是导致软件系统的失败一个重要原因。国内早就有着名言论：“不上ERP等死;上了ERP找死”，如果你的企业不上ERP，那么你的企业就不能借助软件应付快速的市场等环境变化，那么必然会被淘汰;但是，如果上了一个不注重“适应需求变化”的ERP软件系统，那就是企业被僵化的ERP软件框死，丧失了使用ERP的根本目的。适应需求变化则成为现代软件系统一个孜孜不倦的追求目标，那么如何实现呢?原则：给予人们可以裁剪他们系统的能力应适应需求变化，建立一个适应需求变化的系统，允许系统在一系列小的、可控制的步骤上进行改变。2、组件诞生将不变的通用的东西抽象出来，以达到在不同项目中重用复用，将我们有限的精力集中在项目具体变化和特点上。当然这些抽象复用的东西之间彼此必须是松耦合，这样才能根据需求挑选组合。让我们先回顾一下软件的发展史，软件开发的发展史实际是一部我们思维不断抽象拔高的发展过程，这种抽象概念非常类似于建模的思考方式：概要贴切地描述事物，忽视次要的细节。抽象体现在软件开发上就是每个具体项目需要完成的代码行数量越来越少。从1970到1980这段时间，软件开发从机器语言到汇编语言。进而发展到高级语言，甚至一些CASE工具，面向功能编程发展到面向对象编程，功能模块重用细化到类的重用，类的重用是最初是通过设计模式实现的。进入90年代中期，诞生了基于组件的开发模式(CBD：componentbaseddevelopment)，CBD将抽象概念带往了一个新的方向，与减少代码数量相反，CBD将功能各个方面细化分离到不同的、相互隔离层中，如表现层、业务逻辑层、持久层、安全层以及核心层等，并且可以管理这些组件之间的依赖关系，通过这种分离，我们可以提纯细化组件功能，进而产生可以重用的框架，如Struts框架可以重用在大部分应用系统的表现层中,StrutsJdonFrameworkHibernate是一个框架组合，代表一种架构设计，这种架构设计其实可以重用在大部分应用系统，这种重用我称之为架构级别重用。3、组件复用软件组件(Softwarecomponents)是软件提供业务或技术功能的基本单元或元素，这些单元可以独立地被部署、他们可以自我管理并且被虚拟部署到网络的任何地方，业务组件((Businesscomponents)执行业务逻辑、遵循一定的业务规则并且管理相应的数据(数据库操作称为managecorporatedata);而技术组件(Technicalcomponents)则提供相应的平台以便业务组件可以依赖其上运行，例如权限、组件管理等。JdonFramework/Spring都属于一种技术组件框架，而我们具体项目的业务层代码如果能够提炼可以复用，则是业务组件;JdonFramework/Spring则都提供了业务组件赖于运行的一些核心底层机制，特别是组件的管理，如组件的创建、组件的获得、组件的资源管理、组件的消亡等生命周期支持，所以，我们可以在JdonFramework/Spring中加入自己的业务组件，当然，JdonFramework还提供了Session等状态管理的支持功能，为业务组件提供了更广阔的生命周期支持。组件复用技术以前是停留在编译前期，也就是说：我们在编程时，导入所需要的其他组件Jar包，然后混同我们的项目编译部署，但是这需要通过专业技术人员实现，很显然是不能适应原则中第一句：给予人们可以裁剪他们系统的能力应适应需求变化，[整理]这里的“人们”应该是指软件最终用户，应该给予用户自己改变系统的能力，也就是说：需要提供软件系统运行时能够动态改变自身的能力。组件复用技术以前停留在软件编译阶段，现在则更靠前，必须在软件运行阶段，当然对技术要求相当高，需要语言支持RTTI(简单又神秘的Class.forName发挥作用了)，这在"Evolution,Architecture,andMetamorphosis"一文中被认为是Metamorphosis，现在由于AOP技术出现，AOP有一种动态Weaving技术，实际就是在软件运行时实现动态拦截，这样给予终端用户更大的改变系统能力，他们基本可以以动态插拔的概念实现多个组件的组合运行。在"AOPvsDecorator"一文中，我把编译阶段的组件组合方式(我更愿意称为静态组合)和运行时组合等两种处理方式，合并称为过滤器模式，如果你希望采取组件可插拔式的复用，就可以使用过滤器模式。4、组件可插拔更换为什么说组件的可插拔非常重要?组件重用目的是为了更好地适应需求变化，但是有了组件重用不代表就快速适应需求变化，因为组件本身也会产生设计错误(提炼得不够抽象或者组件很难以替代)，这就必然导致软件系统得维护成本提高，那么快速适应需求变化的目标也就成为一纸空文。实践证明：组件设计问题已经成为导致软件开发失败的一个主要因素。组件设计有两个主要风险：组件提纯的纯度和组件的替代方式。提炼的纯度也就是抽象的高度，组件的抽象程度越高，当然可重用范围越广，但是往往我们只有经历多个项目后，才发现自己的组件提炼还欠火候，这实际是组件的提炼过程成本。组件提练虽然取决于人为设计因素，但是在实现手段上也依赖于组件的替换方式，通过经常反复频繁的微调和更换，才能将组件不断提炼向理想状态靠拢，所以，必须有一种方便的组件替换方式提供频繁更换支持，我们总不希望更换组件象以前更换汽车发动机火花塞一样，需要拆开汽车，打开发动机那样麻烦吧?参考PC电脑硬件设计：更新CPU或内存条，只要直接插拔就可以，这些部件和母版都是一种松散的、可插拔的关系，如果软件组件替换是动态的可插拔更加方便终端用户在软件系统交付后，根据需求改变他们的系统。组件可插拔本质上是这些组件必须是最大化的松耦合，彼此依赖影响非常小，换句话说：如果实现了可插拔更换，说明你的组件已经实现松耦合了。那就有可能设计一种软件框架：它能够为每个部件提供非常棒的服务访问，软件组件是松耦合’looselycoupled’，这些组件的大部分通过几行代码就可以实现替换。目前这种方便的实现方式是使用XML进行组件的配置。JdonFramework/Spring都是这样的一种框架，JdonFramework更进步的是：JF框架本身的组件也是可以替换的，例如你希望在JF中使用Spring的配置文件，那么你只要做一个Spring配置文件的解析组件，然后替换JF框架原来的XML解析器就可以了。无论EJB2/EJB3等在这方面要稍逊于Ioc/AOP框架，对于支持EJB3的JBoss4这样架构，需要动态更换AOP拦截器还不是很方便，因为JBoss4本身组件没有象JF那样做到可插拔配置，不过，JBoss5已经开始走上这条路，使用一个微核心来管理所有的可插拔组件，我曾经在"JBoss5迎来中间件彻底的可配置时代"一文中提出组件是否方便替换是衡量一个组件框架的重要指标。在最近的TheServerSide文章’ServiceAccess’tothesoftwarecomponents中，[收集]主要是谈论了表现层组件的替换访问方式，GIF这样图片组件不可以随意控制调整，基本不能复用，但是通过SVG或XUI等支持XML组件动态替换技术的使用，则可以实现显示图形组件的复用。5、SOA在软件运行时，给予用户动态插拔式更换组件，达到复用的组件更加适合变化的需求，这是软件业追求的目标，而SOA(ServiceOrientedArchitecture)则是从另外一种方向,也是在运行时提供用户一种改变系统的能力。SCBA(ServicesandComponentsBasedArchitecture),SCBA是通过减少需求变化带来的传递损耗和时间来实现的，当需求变化时，SOA的服务将支持跟进变化和替换。SCBA更强调的是一种业务过程重用，而且是跨组织跨多个专业域范围的，例如我以前说的四色图实际是对跨域范围的业务总结，特别是ERP域范围，大多数企业系统都是由MI等四种原始模型组成的，例如JiveJdon3看上去只是一个论坛系统，实际不只是，它的Message模型可以重用在网站内容系统、新闻发布系统、电子商务系统