产品概述.docx
《产品概述.docx》由会员分享，可在线阅读，更多相关《产品概述.docx（14页珍藏版）》请在冰点文库上搜索。
产品概述
产品概述
VisualRules是什么
VisualRules又称旗正商业规则定制平台，是一个基于规则引擎实现的可视化定制业务逻辑的商业规则管理系统，同时又具有快速开发java软件项目的功能。
VisualRules可以在程序外部对软件项目中所涉及的业务逻辑进行单独管理，并且提供多种语言的API接口供外部程序调用。
VisualRules可以集成到现有的软件项目中，将软件中经常容易发生变化的部分，独立出来由规则库进行管理。
也可以用于直接开发web项目，VisualRules可以为软件项目生成90%以上的程序代码，节约50%以上的软件开发时间以及减少80%以上的软件维护工作量。
VisualRules是开发B/S结构软件项目的利器，特别适用于快速开发基于J2EE结构的软件项目。
其原理是对于J2EE项目，一般其架构分为界面层、业务逻辑层和数据层。
VisualRules提供了数据库管理器，可以生成几乎全部的数据库层代码；提供了规则编辑器可视化快速开发业务逻辑；提供了规则引擎可以动态加载和执行业务逻辑；提供了页面模版编辑器以及页面生成器可以生成大部分界面层代码；提供了在线的业务逻辑管理平台，可以直接供客户（包括非技术人员）直接修改软件项目中实现的业务逻辑。
VisualRules解决了软件开发中一直以来业务逻辑层只能手工书写代码的问题，为业务逻辑层的实现提供了采用类自然语言（业务人员可以理解的语言）的可视化开发工具，以及在线方式的业务逻辑编辑工具直接供业务人员修改逻辑。
背景
当前社会已经开始进入信息时代，越来越多的企业和单位开始应用各种信息化系统来进行公司管理。
包括财务系统、业务系统、办公自动化等等，这些信息化系统对提高企业的竞争力发挥着越来越重要的作用。
同时当前社会是一个竞争日趋加剧的社会，各行业都面临着残酷的竞争，要求企业不断的提高产品质量、服务质量以及降低企业成本，从而要求企业不断的改进业务流程、改善商业模式。
使得为企业服务的信息化系统也必须根据企业的变化而不断的变化，以满足企业新的要求。
同时要求信息化系统的变化快速、安全、稳定。
现存问题
商业需求的不断变化，是目前软件行业面临的最大挑战。
据统计，80％的软件项目最后都面临失败，其主要原因就是因为商业需求的变化造成软件不断的被修改，导致软件问题的持续增加，最后导致失败。
因此软件项目的成败关键看其能否满足客户需求的不断变化。
客户需求的变化最主要表现在业务逻辑方面，目前已经普遍采用的三层架构技术就是希望解决业务逻辑不断变化的问题。
三层架构技术是将软件分为界面层、业务逻辑层和数据层，将界面、逻辑和数据分离，其目的就是为了当业务逻辑变化时，只需修改业务逻辑层的代码而无需改动界面层和数据层的代码。
减少了因为修改代码而产生的问题。
但是仅仅采用三层架构技术在解决客户需求不断变化的问题方面仍然具有很大的局限性。
首先业务逻辑层采用编码来实现，当业务逻辑变化时，需要软件工程师修改程序代码才能实现新的业务逻辑，一般需要经过需求变更、重新设计、编码、调试、测试、发布等阶段，周期往往在1个星期以上。
这样就导致不能快速满足客户的要求，同时手工修改代码也增加了软件不稳定性方面的风险，也大大增加了软件的后期维护成本。
其次，客户需求的变化在某些情况下不仅仅表现在业务逻辑上，有可能会变化数据结构。
这样势必导致修改数据库层和页面层的代码，改动可能会涉及到一些公共的程序代码。
手工修改的工作量很大，而且也增加了项目失败的风险。
解决方法
VisualRules针对以上这些问题，提出了新的基于规则引擎技术以及快速开发平台的解决方案，解决了传统三层架构技术的局限。
VisualRules采用规则引擎技术，将业务逻辑层的业务逻辑进一步分离出来，存储在XML格式保存的规则文件中，由规则引擎解析执行。
同时提供一个可视化的操作界面可供客户直接修改业务逻辑，无须采用程序员编码的方式来实现。
同时，VisualRules为基于web的开发提供了一套完整的web框架以及大量的公共控件，将界面层、业务逻辑层和数据库层彻底分离。
同时其提供数据库管理器满足了数据结构的变化时，可以快速生成全部数据库层代码；提供页面模版编辑器以及页面生成器满足了数据结构变化时，可以快速生成几乎全部界面层。
无须再采用手工编码的方式来满足数据结构的变化。
适用范围
VisualRules的提出是为了解决目前软件项目因为客户需求的不断变动，造成项目延期或者维护成本居高不下等问题。
VisualRules的使用可以有效的减少软件设计和开发的工作量，使得软件项目所需要人手大大降低，有效的减少了项目沟通的问题以及项目管理的难度。
同时VisualRules使得极少的维护人员就可以担当起几个项目的维护，部分维护工作可以直接由客户担当，有效的控制了维护成本。
因此VisualRules最适应于那些需求容易发生变化或者需求最初分析不清的软件项目。
就技术层面而言，需求的变化涉及到三个层面的变化：
业务逻辑层，这是业务需求最容易变化的部分，用户可能会要求定期就发生变化；数据库层，这一层的变化最小，因为业务数据结构一般都不会轻易发生变化，但是如果某些数据库对象参与了业务逻辑的计算过程，必须用于配置一些参数，那么这些数据结构也容易发生变动；界面层，界面层在前期项目开发阶段变化大，后期维护阶段变化相对较少，一般涉及是数据筛选和校验逻辑的变化。
VisualRules的目标就是使软件项目可以随着用户需求的变化而变化，因此VisualRules分别从以上三个层面让软件项目支持需求的变化。
下面分别描述以上三个层面，原先通用的做法以及基于规则平台的解决方法。
对于业务逻辑层，原先通用的做法是采用Struts的form等来定义数据接口，采用Action类来操作业务逻辑。
或者是采用Bean来定义数据接口，采用Spring来定义接口，然后用实现类来定义具体的处理逻辑。
这种做法使得业务逻辑发生变化时，需要去对应的修改实现类中的代码，然后调试、测试、打包、发布。
采用这种方式有几个弊端：
1、变动必须修改代码，因此比如高级程序员才敢改，而且改了发布必须重启服务。
2、业务逻辑绑定了框架，如果框架（如Struts、Spring）遭淘汰，那么原先项目代码将很难重用。
这些都使得业务逻辑的修改变得复杂。
VisualRules提供了规则配置器，可以来设置业务逻辑层所需要的定义的数据处理逻辑以及数据库操作逻辑。
VisualRules将这些配置的逻辑可以直接翻译成java代码并自动编译。
同时提供规则引擎来动态的调用对应的业务逻辑规则包。
基于VisualRules，数据接口不再需要用Form或者Bean类来定义，而是通过一个动态的Map来和规则包进行交互，业务逻辑不再写在代码中，而且存储在规则库中，调用时会自动编译生成对应的java代码。
这样业务逻辑的实现脱离了框架，使得业务逻辑在将来技术的升级时，可以最大限度的得到复用。
同时也方便了业务逻辑的维护和修改，发布时也不用再重启服务。
对于数据库层，原先通用的做法是采用Hibernate或者IBatis等实现数据库对象的接口。
这样一般都需要维护一个数据对象的XML描述，以及自动生成的一些java代码。
Hibernate的采用简化了数据库层的操作，使得用户只需维护XML中的一些结构信息，就可以直接操作表。
但是Hibernate等技术也带来了一些问题，比如性能问题，依赖问题、数据库特性问题等。
最显而易见的，当数据结构变动时，需修改或生成对应的XML，然后发布也需要重启服务。
VisualRules自动从数据库读取字段信息，并且采用List来存储，因此可以使用公共的接口类实现数据库对象的实现。
采用VisualRules的数据库接口，可以实现数据库的变化发布后无需重启服务器。
并且可以直接调用数据库表、视图和存储过程，也可以自定义SQL语句，使用数据库的一些特性语法。
对于页面层，现在页面处理基本有两种处理方式，一种是传统的页面跳转方式，这种方式一般用Struts等来控制跳转，在每个跳转的页面中定义页面展现逻辑；还有一种是基于AJAX提交的方式，这种方式可以采用DWR等直接调用后台的逻辑代码，然后返回数据，数据解析以及展现逻辑完全有一个页面控制。
我们不推荐采用第一种方式来处理页面层，因为修改Struts相关代码必须重启服务，不能实现页面层的动态修改。
我们推荐页面逻辑完全在页面层中控制，然后通过Ajax直接访问服务器中的规则包，然后将结果返回到页面。
VisualRules处理提供Ajax调用规则包的程序框架之外，还采用更加简便的方式来实现页面层。
VisualRules通过页面配置器，直接配置不同的页面所需要设定的参数，然后根据页面模板来生成对应的页面。
因此VisualRules可以为传统掉转方式，生成对应的jsp，也可以根据Ajax提交的特性，生成ext等页面，或者根据其他的框架来生成对应的页面代码。
VisualRules生成的页面代码上传到服务器之后，就可以直接应用，而无需重启服务
因此基于VisualRules进行开发，将每一层最核心的设置单独提出来配置，简化了每一层的开发。
同时也使得维护和测试阶段，修改无需重启服务。
使得业务需求发生变化时，真正实现了软件的随需而变。
VisualRules使得数据库层变得动态，增强了业务逻辑配置的功能，简化了页面层的开发。
以下分不同行业来说明在哪些项目中，可以充分利用VisualRules的这些功能：
金融行业
VisualRules可以用于银行系统用户资格审核、风险分析等项目中，可以用保险项目的核保、险种分析等项目中。
流通行业
VisualRules可以用于商业销售环节的定价策略的分析，返点政策的配置，销售预测，人事奖励机制的设置等。
制造行业
生产排程算法的设定。
电信行业
套餐配置的算法、积分系统等。
在以上这些项目的使用中，充分利用本产品对业务规则的配置功能，实现了这些逻辑的随时可变。
当然在一般的ERP或者企业管理系统中，充分利用本产品对页面层和数据库层的简化功能，实现这类项目的快速开发。
特点价值
VisualRules是在规则引擎基础上发展出来的一款产品，其秉承了规则引擎可以使业务逻辑的变化可以独立于程序之外的特点，同时结合国内软件项目的特点，为数据库层和界面层也提供了独立于程序之外配置的特点，因此本产品不光是一个业务规则管理系统，还是一个基于规则引擎的web快速开发平台。
与国际上其他的业务规则管理系统相比，本产品具有以下特点：
顺序执行的规则引擎算法
传统的业务规则管理系统，其规则引擎的算法基本上会采用reta算法，其基本原理是运行阶段判断哪些规则符合条件，然后去决定其执行轨迹，这类似于人工智能的思想，当然其最初出发点也是为了人工智能判断。
由于业务系统业务逻辑的频繁变动，因此希望可以利用规则引擎来实现业务规则的配置，因此也就自然将reta算法作为业务系统中业务逻辑的执行算法。
但是这两者其实是不一致的，业务系统中的逻辑一般是确定的，有着明确指定的执行先后顺序的。
而reta算法是动态决定顺序的，因此在用reta算法描述业务逻辑时，往往显得非常琐碎，并且其速度也比纯粹用程序描述要慢很多。
VisualRules不再采用难以描述业务逻辑的reta算法，而采用顺序执行的算法来描述业务逻辑。
这样描述业务逻辑和并平时用流程图和文本来描述业务逻辑就没有多少区别。
可以最简单话的配置业务逻辑，同时其速度和手写程序的速度是一致的。
VisualRules是真正的为业务系统中业务逻辑的实现而设计的，是软件项目业务逻辑实现的最佳选择。
公共规则、循环规则、关联决策表
由于规则执行算法基于顺序执行的算法，因此在描述业务逻辑上比reta算法有更多的展现形式，特别是可以通过规则集来定义多个规则的共同条件以形成执行的分支，或者用来描述循环运行的一组规则。
另外在决策表的支持方面也有三种方式，二维决策表、多维决策表以及关联决策表，以更方便的形式来描述逻辑。
同时规则还支持否则如果（elseif）方式的条件，进一步增强了规则描述业务逻辑的能力。
动态的参数接口、数据库接口和Excel接口
传统的规则引擎如JSR94描述的规则引擎调用接口采用Java类来传递值，这种方式使得接口的数据结构不能像规则一样变动。
VisualRules通过Map来传递值，因此其接口的数据结构是可变的。
同时传统的规则引擎一般可以通过设置来直接调用Hibernate等外部数据库对象，这样其实就是通过类和XML来定义了数据库的调用接口，这种方式就不能使数据库对象不能像规则一样灵活变动。
因此VisualRules采用List来定义数据库对象接口，这种方式使得数据库对象也是可变的。
传统的规则引擎一般不能直接操作Excel数据，但是在实际的业务逻辑的应用中，部分数据并没有存储在数据库中，或者需要用Excel来展现数据。
VisualRules可以直接来操作Excel文件。
内存表格
业务系统的业务逻辑实现有个特点，就是基本都是批量处理的处理，并且很多数据存储在数据库中。
但是如果在实现业务逻辑时，频繁的去访问数据库，会使得整个业务逻辑的实现效率很低。
因此VisualRules设计了内存表，可以将数据库中的数据先取出后放到内存表中，然后通过内存表相互之间做匹配或汇总处理。
这样极大的提高了执行效率，而且也增强了业务逻辑层实现的功能。
最小化规则引擎
做开发平台最关键是运行时的稳定和性能。
因此VisualRules采用最小化的规则引擎，规则引擎只处理规则包的加载和调用，不处理规则语法以及规则解析工作。
在开发规则时，开发平台根据规则语法将规则包静态编译成可执行的java代码，这样最大限度的保证的规则运行平台的稳定。
同时将规则的开发平台和运行平台分离，使得运行平台不会随着规则语法以及功能的增强而变化。
基于模板的页面配置开发
在页面表现层的实现上，当前最流行的技术就是采用Ajax来实现界面的表现。
但是在表现逻辑的实现上，一般情况下，我们会基于一套框架（比如Ext、Dojo、JQuery等），然后再通过javascript来编写具体的逻辑代码。
但是这些表现逻辑代码其实是非常晦涩难写的，而且也不能体现所见即所得的效果。
VisualRules将基于框架的组件配置信息单独提出来，通过图形化界面来设定所需要的参数，然后根据模板生成对应的代码。
这种方式类似于代码生成器方式来生成界面层的代码，其开发工作量是最小的。
VisualRules可以取代当前业务逻辑层和数据层所有的操作代码，准确的说，可以取代从Struts、Spring、Hibernate这些相关的代码。
Ajax直接通过通用的Servlet来访问规则包。
这种取代方式，极大的简化了后台代码的开发，同时也使得业务逻辑层更加快速适应业务需求的变化。
规则引擎可以有效的和当前主流的Ajax框架进行交互，也可以在Jsp中，通过java代码来访问。
页面层代码可以通过页面配置器来根据模板生成，也可以手工编写。
基于以上这些特点，使用VisualRules可以为用户带来一些这些价值：
软件系统随需而变
软件系统最大的价值就是体现在系统运行的过程中，随着用户业务的变化，软件能够快速的加以适应，而不是成为业务发展的障碍。
因此软件变更的响应时间以及影响，是衡量软件价值的关键。
VisualRules使得软件系统可以“零时间”响应用户需求的变化，真正的做到了软件系统随需而变。
降低软件成本
采用VisualRules开发软件系统，可以减少项目开发所需要的人员数量，同时也减少了每个人的工作量，使得项目的周期缩短。
因此visualRules可以减少软件开发的成本和缩短软件开发的时间。
同时由于VisualRules提供了方便的配置工具，可以在软件项目后期维护阶段快速适应需求的变化，因此软件的维护阶段，当有需求变更时，不再需要安排程序员去维护。
而是一般的技术支持人员甚至客户本身就可以实现变更工作。
这使得安排一个技术支持人员就可以同时支持多个项目的维护工作。
而不像原先那样，当维护时需要安排原先的程序员来进行对应。
因此使得软件项目整个成本属于完全可控的范围以内。
提高软件复用
VisualRules来实现业务逻辑时，是脱离程序语言来实现。
因此其实现的业务逻辑可以供不同的语言来进行调用，也可以供不同的框架来进行调用。
特别是当前基于web浏览器的富客户端技术不断发展的今天，富客户端框架很有可能会有新的框架进行取舍。
因此业务逻辑脱离这些框架的实现显得尤为关键。
当技术更新时，在新的技术框架的实现下，可以调用原先的业务逻辑代码，这最大限度的保证了原先软件项目的投资。
项目管理
VisualRules使得软件项目的开发时，对于业务逻辑层的开发不再需要编写代码，因此也就无需去管理Struts，Spring，Hibernate哪些相关的类和xml配置文件，甚至部分页面的代码也是自动生成的，因此对应的项目管理工作也要相应的发生改变。
以下针对项目管理的各个方面描述对应的变化：
项目人员角色管理
由于VisualRules极大的简化了软件项目的编码工作，因此软件编码人员不用太多，相应的可以增加业务分析人员以及设计人员的比重，同时可以安排设计人员和业务分析人员，参与一部分规则的配置工作。
在角色的分工上，分为需求分析人员、规则设计人员、数据库设计人员、web框架及页面模板设计人员、规则配置人员、公共代码设计人员、测试人员等角色。
其中系统分析员可以兼任需求分析、规则设计、数据库设计，高级程序员可以兼任web框架及页面模板设计、规则配置、公共代码设计，一般程序员可以担任测试工作以及规则配置工作。
项目文档配置管理
基于VisualRules进行开发，在进行规则配置时，规则包是存储在xml格式的文件中。
因此针对项目代码的配置管理中，首先需要对规则包文件进行配置管理。
然后需要管理由规则包编译生成的可执行文件以及由页面配置器生成的页面代码。
其他的配置管理工作就和一般的软件项目管理是一样的，还需要对需求规则说明书、模块设计说明书、数据库设计说明书、测试用例、测试报告等这些都需要进行对应的配置管理。
项目版本控制
规则包可以指定版本，并且在配置服务器中，可以同时存储多个版本。
当需要执行不同的版本时，只需要替换导入现有的版本即可。
项目开发模式
基于VisualRules的项目开发，可以采用敏捷开发模式。
当分析完整体的功能模块，按照功能点进行快速开发。
可以根据数据库的设计，设计并配置数据处理逻辑，同时可以用页面配置器生成对应的处理页面，进行测试和运行工作。
这些配置页面可以直接作为快速的demo页面或者最终运行的页面。
设计开发
采用VisualRules进行软件项目开发，由于业务人员或者设计人员可以直接参与业务逻辑的实现，因此项目的设计开发工作分工方面会和传统的项目分工工作会有所不同。
作为项目的开发流程而言，仍然分为需求分析阶段、设计阶段、开发阶段、实施阶段和维护阶段。
以下分别描述这些阶段基于VisualRules的开发工作：
需求分析阶段
需求分析阶段关键还是需求规格的描述。
需求分析可以采用文本描述和流程图的方式。
需求分析主要是确定业务的功能点、基本的数据结构以及业务逻辑。
需求分析阶段完成的成果主要是需求规格说明书。
设计阶段
需求分析完成之后，就好考虑技术的实现，因此在设计阶段就要考虑如何将需求的对应成具体的规则包。
我们一般首先根据需求分析模块，然后在模块下面分析各个功能点，每个功能点包括输入数据、输出数据以及具体的逻辑。
每个功能点对应一个规则包，因此每个规则包也包括输入数据、输出数据以及具体的逻辑，当然具体的逻辑也包括如何将数据进行持久化。
设计阶段的主要成功是数据库设计说明书和模块设计说明书。
模块设计中包含了每个功能点的设计。
开发阶段
基于VisualRules的开发就是将设计阶段的功能点用规则包来进行实现，规则包中可以定义具体的录入界面、处理逻辑以及存储结构。
这个阶段其实是取代了详细设计和编码工作。
对于一些特殊要求的功能点，并不能完全采用规则包自带的逻辑配置以及页面来实现。
就需要完成一部分编码工作，然后集成到项目当中。
实施阶段
实施阶段需要完成系统的发布以及试运行工作，这一阶段更多的是根据客户的要求，快速的对系统加以改动。
这一阶段其实就是修改规则包以及一部分手工编码的程序。
由于采用了规则包来实现业务逻辑。
因此这一阶段的修改工作是相当快的。
维护阶段
维护阶段时，主要是针对用户的一些要求进行变更，并且完成发布工作。
这一阶段根据用户的要求修改了程序后，发布工作可以由用户来操作。
更多时候只要替换掉编译后的规则包文件就可以了。
采用VisualRules进行开发，重点是需求分析和概要设计阶段。
这一阶段的工作和普通项目开发的工作量一致。
详细设计和编码的工作量大大缩短，同时实施和维护阶段的需求变化响应时间是非常快的。
部署集成
VisualRules分为开发平台和运行平台，部署和集成和运行平台相关。
目前考虑兼容性，VisualRules配置的规则包编译后生成的代码，已经生成的jsp页面等，支持JDK1.4及以上版本。
VisualRules运行平台主要包括规则引擎、web框架以及生成规则包编译文件以及jsp代码。
如果不通过VisualRules来生成jsp代码，则不需要web框架。
规则引擎和web框架是两个jar文件，可以直接打包放到web工程的lib目录中。
编译后的规则包文件可以打包到web工程的classes下面，也可以指定特定目录，放到特定的目录下。
生成jsp页面是纯粹的jsp页面，因此可以放到web工程的根目录下面。
以下分别说明部署并集成到现有的web工程时，对应的设置：
jar包
部署首先要发布两个jar包，一个是engine.jar，一个是flservlet.jar包。
engine.jar和flservlet都是基于JDK1.4进行编译的。
engine.jar是规则引擎的实现，其内部有个配置文件位于根目录，名为engine.conf。
用户可以通过这个配置文件制定编译后规则包所在路径以及调试、跟踪等特性。
同时engine.jar，需要采用dhcp来实现缺省的数据库链接池。
因此commons-beanutils.jar、commons-collections-3.1.jar、commons-dbcp-1.2.1.jar、commons-digester-1.7.jar、commons-io-1.4.jar、commons-lang-2.1.jar、commons-logging.jar、commons-pool-1.2.jar这几个jakarta的common类库。
如果需要在对象库中用到xml对象，则需要jdom1.0，当前需要的包为xerces.jar、jdom.jar。
另外如果用到内存表以及Excel对象，规则引擎用POI来实现Excel的处理，目前支持的版本是poi3.2，所需的包为poi.jar、poi-contrib.jar、poi-scratchpad.jar。
另外还有一个是和web框架相关的类库flservlet，这个包实现了一些web框架相关的web服务。
其中实现了chart图片。
VisualRules采用jfreechart来实现，目前支持的版本是jfreechart1.0。
相关的类库包括jcommon-1.0.0.jar、jfreechart-1.0.1.jar、gnujaxp.jar。
另外在上传程序的处理上，采用apache的fileupload来实现，相关的类库包括c
升级会员 