《快速适应项目中的需求变化与软件复用.docx》由会员分享，可在线阅读，更多相关《快速适应项目中的需求变化与软件复用.docx（5页珍藏版）》请在三一文库上搜索。
1、快速适应项目中的需求变化与软件复用适应需求变化现如今是一个计划赶不上变化的时代，企业竞争力逐渐表现在企业适应变化能力的竞争，谁能更快适应市场的变化，谁就能够在竞争中胜出，这种快速适应能力如果靠“人民战争”无疑是不现实的，软件可以帮助我们来适应这种快速变化。国内早就有著名言论：不上ER有死；上了ERP死，如果你的企业不上ERP那么你的企业就不能借助软件应付快速的市场等环境变化，那么必然会被淘汰；但是，如果上了一个不注重适应需求变化”的ER哪件系统，那就是企业被僵化的ERP软件框死，丧失了使用ERP的根本目的。适应需求变化则成为现代软件系统一个孜孜不倦的追求目标，那么如何实现呢？原则：给予人们可以
2、裁剪他们系统的能力应适应需求变化，建立一个适应需求变化的系统，允许系统在一系列小的、可控制的步骤上进行改变。组件诞生将不变的通用的东西抽象出来，以达到在不同项目中重用复用，将我们有限的精力集中在项目具体变化和特点上。当然这些抽象复用的东西之间彼此必须是松耦合，这样才能根据需求挑选组合。让我们先回顾一下软件的发展史，软件开发的发展史实际是一部我们思维不断抽象拔高的发展过程，这种抽象概念非常类似于建模的思考方式：概要贴切地描述事物，忽视次要的细节。抽象体现在软件开发上就是每个具体项目需要完成的代码行数量越来越少。从到这段时间，软件开发从机器语言到汇编语言。进而发展到高级语言，甚至一些CASH具，面
3、向功能编程发展到面向对象编程，功能模块重用细化到类的重用，类的重用是初是通过设计模式实现的。组件复用JdonFramework/Spring都属于一种技术组件框架，而我们具体项目的业务层代码如果能够提炼可以复用，则是业务组件；JdonFramework/Spring则都提供了业务组件赖于运行的一些核心底层机制，特别是组件的管理，如组件的创建、组件的获得、组件的资源管理、组件的消亡等生命周期支持，所以，我们可以在JdonFramework/Spring中加入自己的业务组件，当然，JdonFramework还提供了Session等状态管理的支持功能，为业务组件提供了更广阔的生命周期支持。组件复用技
4、术以前是停留在编译前期，也就是说：我们在编程时，导入所需要的其他组件Jar包，然后混同我们的项目编译部署，但是这需要通过专业技术人员实现，很显然是不能适应原则中句：给予人们可以裁剪他们系统的能力应适应需求变化，这里的“人们”应该是指软件终用户，应该给予用户自己改变系统的能力，也就是说：需要提供软件系统运行时能够报考改变自身的能力。组件复用技术以前停留在软件编译阶段，现在则更靠前，必须在软件运行阶段，当然对技术要求相当高，需要语言支持RTTI（简单又神秘的Class.forName发挥作用了），这在Evolution,Architecture,andMetamorphosis”一文中被认为是Me
5、tamorphosis,现在由于AOP技术出现，AOP有一种报考Weaving技术，实际就是在软件运行时实现报考拦截，这样给予终端用户更大的改变系统能力，他们基本可以以报考插拔的概念实现多个组件的组合运行。在AOPvsDecoratoL文中，我把编译阶段的组件组合方式（我更愿意称为静态组合）和运行时组合等两种处理方式，合并称为过滤器模式，如果你希望采取组件可插拔式的复用，就可以使用过滤器模式。组件可插拔更换为什么说组件的可插拔非常重要？组件重用目的是为了更好地适应需求变化，但是有了组件重用不代表就快速适应需求变化，因为组件本身也会产生设计错误（提炼得不够抽象或者组件很难以替代），这就必然导致软
6、件系统得维护成本提高，那么快速适应需求变化的目标也就成为一纸空文。实践证明：组件设计问题已经成为导致软件开发失败的一个主要因素。组件设计有两个主要风险：组件提纯的纯度和组件的替代方式。提炼的纯度也就是抽象的高度，组件的抽象程度越高，当然可重用范围越广，但是往往我们只有经历多个项目后，才发现自己的组件提炼还欠火候，这实际是组件的提炼过程成本。组件提练虽然取决于人为设计因素，但是在实现手段上也依赖于组件的替换方式，通过经常反复频繁的微调和更换，才能将组件不断提炼向理想状态靠拢，所以，必须有一种方便的组件替换方式提供频繁更换支持，我们总不希望更换组件象以前更换汽车发动机火花塞一样，需要拆开汽车，打开
7、发动机那样麻烦吧？参考PC电脑硬件设计：更新CPU或内存条，只要直接插拔就可以，这些部件和母版都是一种松散的、可插拔的关系，如果软件组件替换是报考的可插拔更加方便终端用户在软件系统交付后，根据需求改变他们的系统。组件可插拔本质上是这些组件必须是化的松耦合，彼此依赖影响非常小，换句话说：如果实现了可插拔更换，说明你的组件已经实现松耦合了。那就有可能设计一种软件框架：它能够为每个部件提供非常棒的服务访问，软件组件是松耦合looselycoupled这些组件的大部分通过几行代码就可以实现替换。目前这种方便的实现方式是使用XML进行组件的配置。JdonFramework/Springfb这样的种框架，
8、JdonFramework更进步的是：JF框架本身的组件也是可以替换的，例如你希望在JF中使用Spring的配置文件，那么你只要做一个Spring配置文件的解析组件，然后替换JF框架原来的XML解析器就可以了。无论EJB2/EJB等在这方面要稍逊于Ioc/AOP框架，对于支持EJB3的JBoss4这样架构，需要报考更换AOP拦截器还不是很方便，因为JBoss4本身组件没有象JF那样做到可插拔配置，不过，JBoss5已经开始走上这条路，使用一个微核心来管理所有的可插拔组件，我曾经在JBoss5迎来中间件彻底的可配置时代一文中提出组件是否方便替换是衡量一个组件框架的重要指标。SOA在软件运行时，给
9、予用户报考插拔式更换组件，达到复用的组件更加适合变化的需求，这是软件业追求的目标，而SOA(ServiceOrientedArchitecture则是从另外一种方向也是在运行时提供用户一种改变系统的能力。SCBA(ServicesandComponentsBasedArchitecture),SCBA!过减少需求变化带来的传递损耗和时间来实现的，当需求变化时，和替换。SOA的服务将支持跟进变化SCBAM强调的是一种业务过程重用，而且是跨组织跨多个专业域范围的,例如我以前说的四色图实际是对跨域范围的业务总结，特别是ERP范围，大多数企业系统都是由MI等四种原始模型组成的，例如JiveJdon3看上去只是一个论坛系统，实际不只是，它的Message模型可以重用在网站内容系统、新闻发布系统、电子商务系统、仓库管理系统、资源管理系统等跨域范围中（部分已经实现）。既然业务过程和IT系统可以跨组织跨域重用，那么类似软件系统的维护和开发就不必再重新开发，JiveJdon3的Message模型重用在新闻发布系统中，我需要把JiveJdon3的项目拷贝到新闻发布系统中，然后再针对新闻发布系统特点做些裁剪修改，这这种复制业会带来工作量和维护量，而SCBA可以解决这个问题，通过运行时single-copyreuse分享各种服务功能。总结