ABP_J2EE

ABP_J2EE平台技术体系

您现在的位置:首页 - ABP_J2EE平台技术体系

1.ABP_J2EE敏捷业务平台的技术简介



ABP_J2EE敏捷业务平台是面向企业信息化、电子政务等信息化领域,以模型驱动为核心思想,通过建立并执行声明式业务模型(Declared Domain Model),直接产生相应业务系统软件的支撑软件。

ABP_J2EE敏捷业务平台是新一代的业务基础软件平台。融合了SOAService-Oriented Architecture)、模型驱动架构(MDA)、声明式编程(Declared Programming)等先进思想理论。提出了以声明式业务模型(Declared Domain Model)为核心的,模型驱动系统的软件构建方法,彻底颠覆了传统的软件构建方法,实现了免代码开发可快速重构的新的软件开发模式,大大提高了软件的构建效率和面对客户需求多变的适应性。


2.ABP_J2EE敏捷业务平台采用的关键技术



ABP_J2EE敏捷业务平台主要采用了元模型、SOA、业务系统建模等关键技术:

元模型是声明式业务模型(Declared Domain Model)的模型。

SOA(Service-Oriented Architecture)是当前系统集成的最优解决方案,业务基础软件平台构建的业务系统将全面支持SOA,为客户信息化集成解决信息化“孤岛”问题提供了坚实的基础。

业务系统建模是构建基于元模型体系的业务模型,形成对业务系统的完整描述。

ABP_J2EE敏捷业务平台主要具有以下创新性:

(1) 声明式业务模型(Declared Domain Model

(2) ABP_J2EE敏捷业务平台的元模型

(3)SOA(Service-Oriented Architecture)的全面支持

(4) 灵活强大的规则引擎

(5)跨技术平台的ABP_J2EE敏捷业务平台执行引擎

(6)分布式异构数据库的应用系统集成开发

北京虎蜥软件技术有限公司已经研发的成果:

ABP_J2EE敏捷业务平台的元模型的构建

系统建模工具的原型开发

J2EE/.NET的执行引擎的原型开发

基本验证了声明式对象的技术可行性

支持分布式、异构数据库的集成应用开发

采用了AJAX技术实现了J2EE执行引擎的表现层

2.1. ABP_J2EE敏捷业务平台的关键技术

2.1.1.      声明式业务模型(Declared Domain Model

基于元模型、业务模型、声明式编程等理论,提出了“声明式业务模型”的概念。“声明式业务模型”是可支持SOA的、可被ABP_J2EE敏捷业务平台理解的、可直接执行形成最终软件系统的业务模型。

“声明式业务模型”分析吸收了CIM-OSA (Computer Integrated Manufacturing Open System Architecture)模型、集成信息系统结构ARIS(ARchitecture of Integrated information Systems)IDEF(ICAM DEFinition Method)等多种业务模型体系的优点,充分结合ABP_J2EE敏捷业务平台的体系结构提出适合业务基础软件平台的一套业务模型。从功能模型、业务对象模型、流程模型、组织模型、界面模型等几方面对企业的业务进行描述分析。

功能模型主要描述系统的功能,相关的业务逻辑和规则。业务对象模型主要描述系统的业务对象的属性和相关服务。流程模型主要描述系统的业务流程和相关的处理信息。组织模型描述业务相关的组织结构和隶属关系。界面模型描述业务处理相关的信息展现。

2.1.2. ABP_J2EE敏捷业务平台的元模型

ABP_J2EE敏捷业务平台的元模型是“声明式业务模型”的“模型”,是实现ABP_J2EE敏捷业务平台的基础,平台的元模型符合OMG(Object Management Group 国际对象管理组织)的MOF(Meta-Object Facility 元对象设施)规范。元模型从承担职责的角度分为功能元模型、业务对象元模型、服务元模型、工作流元模型、组织元模型、UI元模型等。其中功能元模型主要描述业务功能的静态结构;业务对象元模型描述业务范围内的各种业务对象;服务元模型主要完成业务过程,同时负责功能元模型之间的交互;工作流元模型主要参考WFMC(国际工作流管理联盟)、BPEL(Business Process Execution Language)等多种主流工作流模型,同时结合ABP_J2EE平台的其他元模型,提出的工作流元模型;组织元模型通过组织元模型之间的职责关系可以实现灵活的组织结构;UI元模型实现了菜单、面板、表格、表格元素、功能树等的UI元素的元模型,可以实现复杂的界面表现。

2.1.3. SOAService-Oriented Architecture)的全面支持

声明式业务模型(Declared Domain Model)的核心是声明式业务对象(Declared Domain Object),声明式业务对象拥有属性和服务,系统级的服务由声明式业务对象的服务通过规则引擎定义的业务逻辑组织建立起来。系统级的服务和声明式业务对象的服务可以直接发布为Web Service,从而最大化的支持了SOA,实现系统间的无缝集成,彻底解决“信息化孤岛”的问题。

2.1.4.      规则引擎

随着企业级应用的复杂化,需求不断的随着业务规则的变化而变化,使得企业应用中的业务逻辑需要同开发人员的技术架构相分离,需要将这些业务规则从软件中抽取出来,进行集中的管理,使之能够在不同的时段(包括运行时),可以动态的对业务规则进行修改,而不用修改和维护系统,规则引擎基于此目的而提出的。

规则引擎可以看作是一套软件组件,它负责将应用程序中的业务规则(业务逻辑)抽取出来,使用预定义的语义模块编写业务决策,可以接受数据输入并对业务规则(业务逻辑)。

ABP_J2EE平台创建的系统中的服务支持规则引擎,可以灵活定义服务之间的执行规则,规则引擎将自动解析业务规则来实现复杂的企业业务逻辑。通过业务规则的抽取定义和隔离,大大降低了实现复杂业务逻辑的复杂性,降低了应用系统的维护和可扩展性成本。

2.1.5.      跨技术平台的ABP_J2EE平台执行引擎

借鉴模型驱动架构(MDA)的思想,一套独立的“声明式业务模型”在不同技术平台上的执行引擎可以产生相应技术平台的应用系统。如一套CRM业务模型建立完成后,在不同技术平台上将产生相应的CRM系统,从而最大化满足客户针对技术平台不同的需求,达到了“One Model Run Anywhere”的目标。

和传统的MDA思想不同的是,ABP_J2EE平台的执行引擎,并不是通过模型产生代码然后编译发布为不同的系统的方式,而是通过直接动态解释执行系统的业务模型来实现系统。这种模式正式吸取了声明式编程(Declared Programming)的思想精髓。

2.1.6.      分布式异构数据库的应用系统集成开发

考虑到当前客户应用环境的各种情况,而且新的系统构建可能要和很多已有的系统进行直接集成或开发或升级,支持分布式、异构数据库的集成开发能够更好的适应客户的应用环境。

2.2. 总体技术方案

ABP_J2EE敏捷业务平台是在企业建模理论、MDA思想、声明式编程方法的指导下,结合我们多年的应用系统开发实施经验,规划出的应用系统软件解决方案。

当前客户的信息化环境具有多样性的特点。信息化建设程度具有较大的差异,考虑到这种复杂性,支持各种应用系统(现有的和未来实施的)的集成应用已经成为信息化建设的重点目标。为了实现这个目标,ABP_J2EE平台全面可支持SOA的思想进行设计开发,通过ABP_J2EE平台构建的应用系统,其功能全部可以直接发布为web service,实现不同应用系统之间的互联互通,满足客户信息化集成的需求,彻底解决客户信息化“孤岛”的问题。

ABP_J2EE平台的应用场景是对客户需求进行业务分析,建立声明式业务模型,执行引擎自动构建相应的应用系统,无需编码,这样就把应用系统的需求多变性体现在业务模型上。需求的变化是客观的,是必然的。通过建模工具实时根据需求的变化,修改业务模型,业务模型的修改驱动应用系统的变化。实现了应用系统的快速构建、升级,真正达到随需而变的效果。

ABP_J2EE平台提供了Microsoft .NET、J2EE、Ruby等多种技术平台上的执行引擎,可以达到一个业务模型驱动构建多个技术平台的应用系统的效果,实现了应用系统在技术平台方面的“跨平台性”,满足了客户应用中技术平台的多样性需求,并且为客户升级最新技术平台做好了准备,最大可能得保护用户投资。

ABP_J2EE平台结构示意图

ABP_J2EE敏捷业务平台主要包括三大部分:元模型、应用系统业务建模工具、应用系统执行引擎。

元模型是“声明式业务模型”的模型,是实现ABP_J2EE平台的基础,为ABP_J2EE平台提供一个完整的框架。元模型的实例是要实现的应用系统的业务模型。在元模型体系下,业务模型是通过元数据进行描述,业务元数据是业务模型结构的描述,业务模型是业务元数据的实现。

元模型从承担职责的角度分为业务对象元模型、服务元模型、工作流元模型、组织元模型、UI元模型等。业务对象元模型、属性元模型、服务元模型、参数元模型形成了ABP_J2EE平台的“声明式可执行对象”的可执行模型。

业务对象元模型主要描述业务功能的静态结构,服务元模型主要完成业务逻辑,同时负责业务对象元模型之间的交互;工作流元模型主要完成业务流程及业务对象元模型的协作;组织元模型通过组织元模型之间的职责关系可以实现灵活的组织结构,UI元模型实现了菜单、面板、表格、表格元素、功能树等的UI元素的元模型,可以实现复杂的界面表现。

应用系统业务建模工具主要用来对业务系统建模,考虑到大量的交互操作,决定采用传统Client/Server模式以增加良好的用户体验。业务建模工具主要包括:组织建模、功能建模、业务对象建模、业务流程建模等功能。同时包括应用系统界面层、服务层、对象层的定制和修改功能。通过建模工具的模型有效性检查可以确定模型的正确性。各种元模型的序列化可支持XML、数据库等多种形式。考虑到维护和使用的方便,还可以支持Access/HSQL DB等嵌入式文件数据库。

应用系统执行引擎通过解析业务模型(即元数据),形成最终的业务系统。 基于模型驱动架构(MDA)的思想,进一步提出了“可执行声明式模型”概念,ABP_J2EE平台的“声明式业务对象”是直接可被执行的。“声明式业务对象”的执行过程比标准的MDA层次减少了中间模型转化的层次,可直接被执行引擎驱动产生应用系统。ABP_J2EE平台提供了多个技术平台(JAVA,.NET,RUBY等)的执行引擎,可以广泛运行在多种操作系统平台上,如Window,Linux,UNIX(HP/SUN Solias/IBM AIX)等。目前主要计划开发基于J2EE和.Net两大技术平台的执行引擎。

已经研发完成和正在研发的内容有:

1.   元模型体系的构建。已经构建完成了基本的元模型体系,可分为领域元模型和UI元模型两大部分。领域元模型可细化分为业务对象元模型、属性元模型、服务元模型、参数元模型型、规则元模型、组织元模型、流程元模型等;UI元模型可细化分为面板元模型、表格元模型、表格元素元模型、菜单元模型、功能树元模型等。

2.   J2EE/.NET的执行引擎的原型开发。J2EE执行引擎的原型已经基本开发完成,并且有了试用项目。NET 执行引擎处于规划开发阶段。根据职责可以把执行引擎细分为业务逻辑引擎、界面引擎、规则引擎、工作流引擎等。界面引擎可以解析UI模型包括面板、表格、表格元素等,形成界面呈现给用户,并且可以接受用户录入(或其他系统传递的参数),把录入数据传给业务逻辑引擎。业务逻辑引擎解析领域模型,接受界面引擎的参数,完成业务逻辑。业务逻辑引擎和规则引擎结合可以完成更复杂的业务逻辑。

3、系统建模工具的模型持久化部分已经基本完成,可以通过网页的表单方式维护模型,但是模型的图形显示、图形建模还处于筹划阶段。模型持久化部分采用虎蜥公司自己的O/R Mapping 解决方案OrFlying 完成,为以后的图形建模提供了有效接口。

4、可扩展的UI层设计。采用HMVC(层叠式模型、视图、控制器)的设计模式设计思想,UI层可以独立变化。ABP_J2EE平台支持多个UI方式的呈现。

将要研发的内容:

1、声明式ABP_J2EE平台的图形建模工具

当前的系统建模工具主要是一个相对简单的系统模型维护系统,基本实现了模型建立和维护的工作,但距离一个方便、快速、集成化的建模工具还是比较远的。开发一个集成化的可视化的方便地专用建模工具,可以大大提高系统建模和模型修改的工作效率。主要包括:

(1)应用系统功能模型的图形化设计界面 包括各应用系统的建立,以及系统模块功能的树列表,是系统功能模型设计和维护的实现。

(2)组织模型的图形化设计界面 包括对应用系统相关的组织结构以及用户、角色权限等进行建模,是系统组织模型设计和维护的实现。

(3)声明式业务对象的图形化设计界面 包括业务对象、属性、服务、参数等的设计和修改,是系统业务对象模型设计和维护的实现。

(4)业务流程的图形化设计界面 包括对系统中各种流程进行建模,是业务流程模型设计和维护的实现。

(5)系统界面模型的图形化设计界面 包括界面模型的面板、表格、表格元素、控制器等的修改和设置,是系统界面模型设计和维护的实现。

(6)向导工具 包括一些常用的系统功能集成化向导工具,如:对象维护向导(自动根据对象的基本属性和服务设置对象增加、修改、删除、浏览的功能)、主子表表单维护向导(定义常用的主子表结构的表单及相关的增加删除和修改的功能)、条件查询向导(定义常用的根据定制条件查询数据的界面)、结构树设计向导(提供数结构定义的向导)等。通过这些工具,可以大大提高模型建立和修改的工作效率。

(7)系统工具 包括编码生成器、操作日志管理、系统信息管理等一些通用功能的灵活实现。

系统功能如下图所示:

2、“声明式业务模型”和元模型的完善和扩展

结合目前原型系统的初步应用经验,将进一步规划和设计软件的元模型体系。现在的系统提供了在业务模型体系层面扩展,提供了插件和脚本支持。下一步要在元模型层面引入“扩展点机制”。扩展点分为主要的4类:数据、功能、界面和业务过程扩展点。针对不同扩展点的具体特点将采用不同机制实现不同类型的扩展点。扩展点机制可以在不改变元模型的情况下,动态的扩展元模型的描述能力。
在特定领域上,计划在企业信息化和电子政务这两个较为广泛的应用上,形成较完备的领域“声明式业务模型”体系。

3、设计开发ABP_J2EE平台的执行引擎(J2EE/.NET两个版本)

J2EE执行引擎的原型系统已经基本开发完成,并且有了试用项目。通过实际项目的应用,发现了模型的一些问题和很多需要改进的功能。综合原有设计,进一步规划设计了J2EE版的执行引擎。新版本的执行引擎将充分考虑实际应用中遇到的问题,将提供更加稳定更加灵活的执行引擎。

.Net版本的执行引擎是在全面参考J2EE版本的执行引擎设计方案的基础上,并结合.Net技术的特点进行设计开发。

PHP、RUBY等其他技术平台上的执行引擎将开展部分研究工作,并作一些原型系统的验证。

4、设计开发在元模型上支持Web Service

根据元模型体系的下一步设计,要进一步完善元模型的描述能力,在元模型上支持Web Service ,从而在领域模型上透明支持Web Service。同时,设计和开发ABP_J2EE平台的Web Service自动发布工具。该工具可以直接产生用户扩展服务的WSDL文件,并且自动发布为Web Service供其他系统调用。

5B/S模式中界面层将提供两种以上的UI层缺省实现。

现在ABP_J2EE平台已经提供基于DOJO AJAX 实现。AJAX 是一种One Page ,One Application(一个应用只需要一个页面)的富客户端实现手段,是Web2.0中的最核心的技术。下一步还要提供基于传统MVC框架(Struts,WebWork)的实现,以便对传统应用提供更好的集成性。随着下一代用户界面描述语言(XUL,XAML)的逐渐成熟,为了使得UI层能够支持新一代界面描述语言,将进行这方面的研究和初步原型系统开发验证。

2.3. 技术路线

ABP_J2EE平台吸收了建模理论、MDA思想、声明式编程方法等先进思想,在多年的应用系统开发实施经验上而提出的快速构建应用系统的解决方案。ABP_J2EE平台拥有独有的元模型体系、模型建模工具、模型执行引擎。 元模型体系是核心,是对业务模型(如MIS,ERP,CRM等的模型)进行了高层的抽象而形成的;模型建模工具可以构建基于元模型体系的声明式模型;模型执行引擎直接执行声明式模型形成最终的业务系统;在元模型层次上支持Web Service,从而最终的业务系统可以透明得支持SOA

传统软件开发一般需要经历需求分析,设计,开发测试,维护等四个阶段。阶段间的递进可以看成阶段模型的演化和抽象,这种演化关系可以看成需求模型—>设计模型—>代码—>业务系统。但是,现在的软件工程很难保证模型间转换信息的一致性,需求模型不可能100%得转换为设计模型,由于人的差异,设计模型和需求模型间可能相差很远。设计模型到代码存在同样的问题,并且需求的变更会造成非常复杂的级联模型修改工作。传统软件开发很容易造成项目的拖期和失败。

基于上述的原因,减少模型转换层次,构建从需求模型到业务系统直接转换得到了大家的共识。现在以及有一些探索方案如“可执行UML”,“可执行的DSL”等。但是这些方案都不成熟,现在还无法构建复杂的企业应用。

虎蜥软件经过多年探索研发的“ABP_J2EE敏捷业务平台”是一种可行的成熟“声明式业务模型到业务系统直接转换”方案,可以构建复杂的企业应用,几个试用项目也证明了这一点。ABP_J2EE平台的“模型建模工具”可以支持绝大多数的信息管理系统建模可以建立复杂的功能模型、流程模型、组织模型等,软件客户和软件开发商可以共同在“模型建模工具”上建立需求模型,保证需求不被错误理解,需求的变化也可以用“模型建模工具”快速修改。这些用“模型建模工具”构建的业务模型都是基于ABP_J2EE平台“元模型”体系的,业务上不同的复杂逻辑,UI上不同的界面表现都被元模型统一表示。基于“元模型”体系的“模型执行引擎”解析建立好的“声明式业务模型”,形成最终的业务系统,“模型执行引擎”可以基于多个技术平台(Microsoft .NETJ2EERuby),这样使得同一个“业务模型”可以在多个技术平台执行。

2.4. 技术实现依据

ABP_J2EE敏捷业务平台的架构设计参考吸收了当今软件领域最先进的架构思想,模型设计参考了建模领域几大主流建模体系的思想,系统界面控制和数据层分别参考了在企业应用开发领域有广泛引应用的成熟的开源组件的设计思想。从理论和实际上保证了系统设计的有效性和可实现性。

基于先进的理论体系和成熟的组件,同时结合虎蜥软件在企业应用开发多年的开发实施经验,以及多年的平台型产品的探索和研发,ABP_J2EE平台的研发前期顺利完成了元模型的设计,同时开发了应用系统业务建模工具和基于J2EE技术平台的执行引擎的原型系统,并且把原型系统应用在实际的项目中进行检验和验证。通过实际项目的应用,给产品设计提供了真实可信的第一手材料,同时也验证了ABP_J2EE平台设计思想的先进性和正确性,证明了ABP_J2EE平台这种软件产品完全能够实现,并且达到预期的目的。这些都给ABP_J2EE平台的设计和实现提供了最有力的验证和依据。

ABP_J2EE平台产品架构设计方面主要参考了SOAService-Oriented Architecture)、模型驱动架构(MDA)、声明式编程(Declared Programming)、面向对象(Object Oriented)的先进思想;



  • SOAService-Oriented Architecture



面向服务的体系结构(Service-Oriented ArchitectureSOA,也叫面向服务架构)是指为了解决在Internet环境下业务集成的需要,通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

在软件技术的发展过程中,体系架构经历了以下发展历程:




面向服务的体系结构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。



  • 模型驱动架构(MDA



模型驱动架构(MDA)是一种独立于特定平台和软件供应商的软件体系结构设计和开发方法,它适用于设计、部署、集成等软件开发的整个生命周期。MDA 遵循的是诸如统一建模语言(UML)、可扩展标记语言(XML)和公共对象请求代理体系结构(CORBA)等一系列业界开放标准。

MDA 建模是基于功能,而非基于特定语言、平台或实现技术,它可以简化系统集成、缩短开发周期和节省企业资源。

模型通常以图和文字的形式来描述一个系统及其环境。模型驱动的方法就是利用模型来引导系统的设计、开发和维护。而模型驱动架构即是用系统的模型来生成系统的体系结构。

MDA 有三个视图。

(1)第一个视图叫计算无关视图(CIV,其作用就是将系统基本处理逻辑同平台相关的技术规范分离开来。CIV视图关注于系统的环境和需求,而系统的具体结构和实现是隐藏的。

(2) 第二个视图是平台无关视图(PIV。该视图关注于系统的操作而隐藏了平台相关的细节,该视图可能用一种通用的、平台无关的建模语言如UML来描述。

(3) 第三个视图叫平台相关视图(PSV。该视图关注特定平台的实现细节。

以上三个视图都有其各自相应的模型:

计算无关模型(CIM)通常由业务分析人员创建,展示了系统的业务模型。

平台无关模型(PIM)是系统功能的模型,通常由系统架构师创建。

平台相关模型(PSM)对一个或多个平台的PIM模型的具体实现建模。

MDA 的真正价值在于 CIM 模型可以通过简单的映射转换成 PIM 模型。同样的,PIM 模型也可以映射成 PSM 模型,而 PSM 模型则可以最终转换成具体的实现代码。

如下图所示,右上角的 CIM 模型是整个模型转换过程的起点。CIM 模型转换成 PIM 模型后,系统架构师和设计师即可以创建系统其余部分的模型。设计完成之后,PIM 模型就转换成了一个或多个 PSM 模型。

模型驱动架构 (MDA)

  • 声明式编程(Declared Programming



声明式编程通过一定的语法和规则(如:SQLANT等)来声明特定的需求,然后通过特定的解析器解析执行这个声明,从而达到实现需求的目的。声明式编程是自顶向下的,声明式编程的核心是声明的规则和语法模型,声明式编程必须依赖特定的解析器,声明式编程的结果必须通过解析器解析执行才能达到预期目标。

声明式编程是一种简化设计得方式,在声明式编程中,重点在于“做什么”而不是“如何做”。您声明要系统做什么,而不是列出它为此必须执行的一组操作。例如:数据库查询语言SQL()就是一个规范的示例,您构造声明要检索信息的 SQL 查询;至于如何执行该查询则由数据库解决。参考声明式编程的思想,在系统模型建立只需要声明业务功能和模型做什么,至于如何做则由执行引擎完成,这样大大简化了系统设计的工作量,同时也就方便了系统的改进。

应用系统的业务模型体系和ABP_J2EE平台元模型参考了分析吸收了CIM-OSA (Computer Integrated Manufacturing Open System Architecture)模型、集成信息系统结构ARIS(ARchitecture of Integrated information Systems)IDEF(ICAM DEFinition Method)等多种业务模型体系的优点;



  • CIM-OSA (Computer Integrated Manufacturing Open System Architecture)模型



CIM-OSA体系结构(CIM Open System Architecture)复杂系统建模分析 所用的一组多视图、多层次模型的集合,称为体系结构。CIM-OSA是 欧共体ESPRIT计划中研究“计算机集成制造开放系统体系结构”的一 个课题名称。该课题提出用三座标的一个立方体来表示、描述、分析及 建立CIM系统的过程,如附图所示。

其水平座标表示“逐步具体化过 程”(stepwise instantiation),最左侧表示“通用结构模块”(generic building block),向右则表示由这些模块构成不同行业的“部分通用模型”,再对 部分通用模型中的元素,按企业的实际情况,赋予具体的值,就构成具 体企业的专用模型,故这一座标表示了从一般到特殊的发展过程。垂直 (向下)的座标,表示了系统开发过程中随时间进展的几个阶段,称为 “逐步推导”(stepwise deviation):从 "需求分析”至“设计说明”再到 “实施描述”,每个阶段都有适应其需要和特点的模型。第三个座标表 示“逐步生成”(stepwise generation)过程,它建立了系统不同方面的模型 及其相互关系,这个座标的开放性最为突出。

CIM-OSA提出了功能、 信息、资源和组织四个视图,就是建议从这四个方面来分析全系统,分别建立功能模型、信息模型、资源模型和组织模型,但是四个视图并不是一个限定不可变的数字,而应根据实际分析设计的需要和可能,进行增删。一般来说,功能模型是定义及描述系统功能及需求的最基本模型,由此再生成其它模型,但是在不同模型的建模过程中,对系统各个部分和各个方面的认识会不断深化,因此各种模型之间还会相互补充,不断完善,所以这个方向的箭头是双向的,表示可能存在的迭代过程。整个 体系结构的建模,目的在于描述系统集成的各个方面,又服务于促进系统集成的实现。为了从技术上实现这一集成,CIM-OSA还定义了一个集成平台─“集成基础结构(Integrating Infrastructure)"。它可分为建立企业工程开发环境和企业运行环境,提供通信、经营、信息和前端四种 服务,能把各种不同结构、功能和性质的软件、硬件及用户集成为一个 有机的整体。



  • 集成信息系统结构ARIS(Architecture of Integrated information Systems)



ARIS由德国Saarbruecken大学A.W.Scheer教授提出的集成信息系统体系结构(ARIS Architecture of integrierter Informations System)是一个在西欧比较有影响的CIM 体系结构

ARIS共有四个视图, 即功能视图、数据视图、组织视图和控制视图。其中控制视图起“粘合剂”的作用, 其将系统功能、使用数据和参与组织联系在一起。ARIS采用了五个层次, 各建模层次依次为现行系统分析, 需求定义、设计说明、实施描述和运行维护。其中现行系统分析, 需求定义、设计说明、实施描述层称为系统建立阶段( Build time ),运行维护层称为系统运行阶段(Run time)

(1)功能视图定义了控制模型中的所有功能以及功能之间的层次关系。

(2) 数据视图定义了过程中所用到的数据及数据间的关系。

(3) 组织视图对人员分工、关系、位置和作用以及权限、义务等进行了描述, 组织视图包含企业内部所有相关的职责信息。

(4)控制视图定义了任务的实现, 包含了系统中各功能之间逻辑关系、因果关系、事件关系等。



  • IDEF(ICAM Definition Method)



1981年美国空军公布的ICAM (Integrated Computer Aided Manufacturing) 工程中用了名为“IDEF”的方法。IDEFICAM DEFinition Method的缩写。后来就称之为Integration Definition method,简称不变。刚开始时,此方法由三部分组成:

(1) IDEF0描述系统的功能活动及其联系,在ICAM中建立加工制造业的体系结构模型,其基本内容是SADT(System Analysis and Design Technology)的活动模型方法。这是由Softech公司发展起来的。

(2)IDEF1描述系统信息及其联系,建立信息模型作为数据库设计的依据。这是由Hughes飞机公司为主发展起来的。

(3)IDEF2用于系统模拟,建立动态模型。这是由HOS公司为主发展出来的。

现在KBSI公司已经并正在继续将此方法发展成一个系列,列写如下:

(4)IDEF0  功能模型(Function Modeling)

(5)IDEF1X 数据模型(Data Modeling

(6)IDEF2  仿真模型设计(Simulation Model Design

(7)IDEF3  过程描述获取(Process Description Capture

(8)IDEF4  面向对象设计(Object-Oriented Design

(9)IDEF5  本体论描述获取(Ontology Description Capture

(10)IDEF6  设计原理获取(Design Rationale Capture

(11)IDEF7  信息系统审定(Information System Auditing

(12)IDEF8  人与系统接口设计(Human-System Interface Design) 用户接口建模(User Interface Modeling

(13)IDEF9  经营约束的发现(Business Constraint Discovery)场景驱动信息系统设计(Scenario-Driven IS Design

(14)IDEF10 信息制品建模(Information Artifact Modeling)实施体系结构建模(Implementation Architecture Modeling)

(15)IDEF11 信息工具建模(Information Artifact Modeling

(16) IDEF12 组织设计(Organization Design)组织建模(Organization Modeling

(17) IDEF13 三模式影射设计(Three Schema Mapping Design

(18)IDEF14 网络设计(Network Design

界面层采用了Dojo Ajax界面组件,控制层参考了J2EE最流行的界面框架Struts的设计思想,数据层参考JDOHibernate等数据层组件。



  • DojoAjax



2006年开始,AJAX一下成了关注的技术热点,各种AJAX框架迅速的发展了起来,其中又分为客户端AJAX架构,服务器端AJAX架构等,其中DojoToolkit做为一个优秀的客户端AJAX架构,已经逐渐走入企业应用开发的领域。

作为早期的开源AJAX架构之一,Dojo开始于20049月,由JotSpotAlex Russell所领导。Dojo是一个开源的JavaScript工具包,本身预置了很多模块,可以实现完整的轻量级窗口组件及很多功能。Dojo的包加载机制(Package System)可以实现动态加载所需模块,而且用户可以编写自己的Dojo扩展模块,有很好的灵活性。

Dojo目前最高版本号是0.4.2,它的文件主要由一个包含主要功能的核心代码文件(Dojo.js)和众多的Javascript文件组成。使用时可以根据包机制,动态载入所需模块。

与其它AJAX框架相比,Dojo设计的包加载机制(Package System)和模块化(Libraries)的结构,能保持更好的扩展性,提高执行性能,减轻了用户开发的工作量,并保持一定的灵活性(用户可以自己编写扩展)。

Dojo现在发展迅猛,得到广泛的支持,并成立了Dojo 基金会 , IBM AOL SUN这些大公司和WebWorkTapestryOpen Laszlo等开源团队都是dojo基金会的成员,雄厚的后盾保证了Dojo可以持续的发展下去。



  • Struts



Struts是Apache 基金会Jakarta 项目组的一个Open Source 项目,它采用MVC模式,能够很好地帮助java 开发者利用J2EE开发Web应用。和其他的java架构一样,Struts 也是面向对象设计,将MVC模式"分离显示逻辑和业务逻辑"的能力发挥得淋漓尽致。Structs 框架的核心是一个弹性的控制层,基于如 Java ServletsJavaBeansResourceBundlesXML等标准技术,以及 Jakarta Commons 的一些类库。Struts有一组相互协作的类(组件)、Serlvet以及jsp tag lib组成。基于struts构架的web应用程序基本上符合JSP Model2的设计标准,可以说是一个传统 MVC设计模式的一种变化类型。

Struts有其自己的控制器(Controller),同时整合了其他的一些技术去实现模型层(Model)和视图层(View)。在模型层,Struts可以很容易的与数据访问技术相结合,如 JDBC / EJB ,以及其它第三方类库,如 Hibernate / iBATIS ,或者 Object Relational Bridge(对象关系桥)。在视图层,Struts能够与JSP,包括 JSTL JSF,以及 Velocity 模板,XSLT与其它表示层技术。

Struts 为每个专业的 Web 应用程序做背后的支撑,帮助为你的应用创建一个扩展的开发环境。StrutsJ2EE企业级应用开发中已经得到了广泛的应用,已经成为J2EE应用系统中界面控制层中最主流的框架产品。



  • Hibernate



Hibernate(http://www.hibernate.org/)是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序实用,也可以在Servlet/JSPWeb应用中使用,最具革命意义的是,Hibernate可以在应用EJBJ2EE架构中取代CMP,完成数据持久化的重任。

Hibernate是Java应用和关系数据库之间的桥梁,它负责Java对象和关系数据之间的映射。Hibernate内部封装了通过JDBC访问数据库的操作,向上层应用提供了面向对象的数据访问API。在Java应用中使用Hibernate包含以下步骤。

1)创建Hibernate的配置文件。

2)创建持久化类。

3)创建对象-关系映射文件。

4)通过Hibernate API编写访问数据库的代码。

3.ABP_J2EE敏捷业务平台的架构体系



ABP_J2EE敏捷业务平台在诞生之初,就定位在采用软件工程领域先进的方法论来指导平台的架构设计,并且在平台开发的各个重要阶段,都注重不断的补充行业最新的方法和理论,这注定为ABP_J2EE敏捷业务平台的长远发展打下了坚实的基础。

3.1. ABP_J2EE敏捷业务平台诞生背景

ABP_J2EE敏捷业务平台的诞生最早应该追溯到1998年,ABP_J2EE 核心团队的工程师们在实施MRPII项目中,存在相当多的重复编码工作,最常见的表现在开发很多大同小异的树形结构图、列表显示图、多页夹、信息录入维护页面、查询分析页面等等,这就出现了很多的重复编码,对于一个开发组来讲,不同的开发人员有不同的思维方式和编码习惯,这导致同类型任务交给不同的编码人员来写,出来的代码效率、稳定性差异很大,测试修改需要投入很大的工作量,最为关键的还是这类工作导致工程师们投入了大部分精力在这些重复性的工作中,而没有时间来理解思考业务和设计。

当时的工程师们,也就是现在ABP_J2EE 的核心设计开发人员,针对这类问题,计划开发一些工具插件,来达到减少此类重复工作,经过一年多的努力,形成了最早的ABP_J2EE 的一些插件工具:树结构定制生成插件、列表定义器和执行器插件、表单录入定义工具、统计查询配置工具、多页夹配置工具等,这是ABP_J2EE敏捷业务平台最初的一些插件工具集的雏形,后来还开发出了平台的集成架构。

后来,经过从Visual Basic 6.0 .Net的升级和多次架构改良,ABP_J2EE敏捷业务平台2000年开始逐步成型,并在多个大中型项目中得到客户的高度认可,最终形成了现在的ABP_J2EE

现在ABP_J2EE 还诞生了它的基于J2EE的基础业务平台产品。两个平台可以满足客户在技术架构上的要求,同时也是公司跟踪世界先进软件开发体系进行的技术储备,尽可能保证公司在激烈的市场竞争中取得先机。

基于ABP_J2EE敏捷业务平台的软件开发是一套全新软件开发模式,是传统软件开发模式的一个飞跃,基于ABP_J2EE敏捷业务平台的客户信息化项目,无需实施人员编制大量程序代码,而是通过ABP_J2EE敏捷业务平台灵活的配置工具就可以完成信息系统的大部分构建工作。这种开发方式可以很好的控制项目的实施周期、成本和系统稳定性,同时该系统具有良好的扩展性和与其它系统的兼容性,大幅提高了项目实施的成功率,到目前为止,利用平台实施的所有项目都得到用户的认可。由于采用平台的方式比传统开发方式项目周期大幅缩短,因此还为客户节约了不少投资。

由于ABP_J2EE 敏捷业务平台配置方式的灵活性和快捷方便的特点,使公司能够承诺随时根据用户的特殊需求对系统进行调整,做到真正的随需应变,从而可以为用户提供个性化需求和发展性需求的业务系统。

3.2. ABP_J2EE 技术思想

软件业一直在探讨,如何使软件实现如同传统产业一样的大规模生产。软件工程的提出,便是为了实现这个愿望。然而,虽然软件工程至今已经有了很大的发展,软件的大规模工业化生产仍然没有实现。原因何在?

从软件的本质属性来说,软件的复杂性是软件的本质属性,在这个属性没有改变之前,软件便不会实现同传统产业一样的工厂化生产,只能逐步的逼近。

从软件生产的介质来说,传统产业生产都是有形的物质产品,人的生产活动都受制于生产资料这些物质介质;然而,软件生产的介质,却是无形的人类的思维。物质资料的生产,受制于物质本身的属性,不容易为人类的思维所左右,并且容易被大量复制,这使得工业化大生成为可能。而人类的思维,却是如此的容易变化,更关键的是不能被复制,甚至同一个人,不同时期思维的复制都不可能,这使得软件这个纯粹依赖人的思维活动的生产实现大规模工业化生产是如此的困难。实际上,不仅仅是软件产业,凡是主要生产介质是人本身的活动的产业,都很难实现工业化生产,如咨询、演艺等。

从生产过程来看,对于传统产业来说,产品的设计和生产是分开的。在设计阶段,主要的工作是人的思维,因此,在这个阶段,同软件一样,不是批量生产的。而在生产阶段,主要的对象便是物质资料,并且一切标准已经制定,只需要在流水线上大量复制。对于传统产业来说,设计和生产的界限是如此的明确,并且,生产和设计的比重是如此的悬殊。然而,对于软件产业来说,软件的生产过程便是设计的过程,纯粹的生产过程几乎不存在(或许,光盘的复制算是),这使得软件的生产形态同传统产业必然存在区别。

对于软件的开发过程来说,从业务模型、需求分析、系统架构、系统分析和设计、到最后代码实现,越往前,抽象层次越高,可控性越小,越往后,越接近实际,可控性越大,因此,在软件开发中,核心团队的作用是如此巨大,一个软件产品的成败,核心团队的核心人员的作用在很大程度上是决定性的。对于软件开发来说,如果软件开发要实现工业化生产,必定是从后向前推进,从编码开始。印度模式或许给出了这么一个例子。

因此,我们在软件工程的路上,只是在不断的向工程化的目标迈进,但是,要达到这个目标,可能会花很长的时间。技术上的每一次进步,都使我们向这个目标迈进了一步。在软件工程的发展过程中,技术进步起了非常大,甚至可以说是决定性的作用。随着采用的技术的不同,所采用的管理方法也在不断变化。软件工程技术的很多方面,也是为管理做准备的。优秀的软件开发技术的采用,能够弥补我们在工程化方面的不足,从而使得软件开发更加可控,软件质量更加有保障。

现在,很多开发人员都已经意识到这很重要的一点,那就是,在开发一个应用软件系统的时候,选择一个好的业务系统平台是非常重要的。从底层开始构建应用程序,是一件吃力不讨好的事情,而没有好的业务平台支持的应用软件,则很难想象会是一个好的系统。

软件,从本质上来说,就是现实世界在计算机中的模拟。在考虑应用软件系统架构的时候,实际上,考虑的问题主要在于:处理什么?怎么处理?如何使用?因此,应用软件系统,需要关注的方面,概括起来,主要包括以下三个大类:

1、 处理的对象,也就是数据。

2、 处理的方式,也就是我们的系统如何来处理系统的逻辑。

3、 如何进行交互,这个交互包括用户(使用者),以及外部系统。

在应用软件系统中,数据是处理的基本对象,程序总是以一定的数据结构来表现数据,并且,在使用面向对象语言开发的系统中,数据总是以类和对象的形式表现出来。另外一方面,数据总是需要存储,对于大部分应用软件系统来说,通常会采用关系型数据库来保存数据。这样,由于数据在程序和数据库中表现格式的不一致,就必然要求在两者之间进行映射。这个映射,在面向对象设计语言和关系型数据库之间,通常称为对象/关系型映射,即O/R Mapping

目前,在O/R Mapping部分,在Java平台下,已经有多种可以选择的方案,例如J2EE架构中的Entity Bean,轻量级的JDO,以及开源项目的Hibernate等,由于微软的.Net框架推出时间不长,成熟的O/R Mapping框架并不多见。O/R Mapping框架的选择或者设计是构建应用软件系统的最基本的工作。本书将讨论构建O/R Mapping框架的一些基本理论、概念和方法。

系统的业务逻辑处理,是应用软件系统的核心部分,如何合理的构建业务逻辑、如何提供业务逻辑层的服务,以及表现层如何访问业务逻辑提供的功能,也是应用软件系统需要重点关注的问题。在这个方面,业界已经发展了很多可供选择的范式,如契约式设计、SOA架构(面向服务的架构)等。这些方法指明了设计的方向,同时也需要我们在实际开发中加以应用。

在业务逻辑确定后,随后而来的问题就是,如何向客户端来提供业务逻辑服务,或者说,客户端如何访问这些服务。在多层应用软件系统中,客户端和业务逻辑在物理上可能存在于不同的机器上,也可能存在于同一台机器,但至少,在逻辑上,是存在于两个不同部分,这就涉及到一个问题:这两个层之间如何进行通信?还会涉及到远程过程调用的问题。

当然,现在我们已经有多种技术来远程过程调用,包括Webservice.Net RemotingCorba、甚至EJB等。如此多的实现技术,带来的很大的灵活性,但同时也带来了问题,其中一个就是,有多少种服务端技术,就得有多少种相应的客户端访问技术。甚至,在某些分布式应用系统中,应用逻辑使用不同的技术开发,存在于不同的机器上,有的存在于客户机本机,有的使用.Net Remoting开发,存在于局域网内,有的使用因特网上的Web Service,有的时候,我们希望相同的业务逻辑能够支持不同的客户端。

在这种情况下,我们需要一个一致的服务访问编程模型,以统合不同的服务访问模式,简化系统的开发和部署。一个统一的远程过程调用框架的前景是如此的诱人,以至于每一种方法都试图一统天下,但出于种种原因,最终都没有一家能够做到,最新的Web Service就力图做到这一点。实际上,每一种方法的出现,最终都会带来一个副作用,那就是,可供选择的多了一点,混乱也就又多了一点。在实际的开发过程中,我们也需要一个统一的访问方式来解决这个问题。

本着以上的认识,通过多年的企业信息化的咨询、设计、开发和实施经验,公司逐渐总结出一套比较理想、成熟的开发方式:基于可动态配置的ABP_J2EE 敏捷业务平台开发。在设计开发平台的过程中,开发团队随时跟踪和研究国内外业务基础软件平台的前沿思想,吸收和兼容了(SOA UMLUniform Model LanguageMDAModel Driven Arthitecture))等先进设计方法和标准,保证虎蜥平台的设计思想始终站在软件产业的前沿。

国内企业现在普遍存在的现象是:管理模式千差万别,个性化需求突出,业务流程随企业发展不断在变化,软件供应商以套装软件难以满足客户需要,采用传统方式的二次开发也往往使开发人员陷入泥潭。虎蜥ABP_J2EE 敏捷业务平台的目标就是为了应对这种现象,在平台的整体架构中集成大量业务无关的功能组件,包含如:信息录入与维护、查询、统计分析、图表、报表、外部插件管理、用户界面定制、权限管理等,利用这些功能组件,在详细设计完成后,可以实现客户应用系统的快速的配置开发,另外,由于采用了组件配置的开发方式,对于客户的需求变化就能够通过平台的配置及时改变应用系统,具有很好的灵活性。

下图是基于ABP_J2EE敏捷业务平台开发的信息系统的体系示意图。

基于ABP™ 敏捷业务平台的信息系统体系结构图


ABP_J2EE敏捷业务平台可根据客户的特殊情况,灵活、快速地定制和扩展适合中小企业客户的软件产品,从而可以大大缩短实施周期,降低实施成本,提高实施成功率。这种灵活性可以在保证系统稳定性和可靠性的同时,根据用户的个性化需求定制和扩展企业信息系统,最大程度地保证信息系统和企业同步发展变化。

3.3. ABP_J2EE三层架构体系

我们在解决一个复杂的问题的时候,通常使用的一个技巧就是分解,把复杂的问题分解成为若干个简单的问题,逐步地、分别地解决这几个小问题,最后就把整个问题解决掉。在设计一个复杂的软件系统的时候,同样的,为了简化问题,我们也通常使用的一个技术就是分层,每个层完成自身的功能,最后,所有的层整合起来构成一个完整的系统。

分层是计算机技术中的常用方法,一个典型的例子就是TCP/IP技术的OSI七层模型。在应用软件开发中,典型的就是N层应用软件模型。N层的应用软件系统,由于其众多的优点,已经成为典型的软件系统架构,也已经为广大开发人员所熟知。

ABP_J2EE敏捷业务平台采用三层应用系统架构,系统被划分成以下三个层次:数据库层、应用服务层和用户界面层。如下图所示:





虎蜥 ABP_J2EE敏捷业务平台的分层结构

其中,应用服务层集中了系统的业务逻辑的处理,因此,可以说是应用软件系统中的核心部分。软件系统的健壮性、灵活性、可重用性、可升级性和可维护性,在很大程度上取决于应用服务层的设计。因此,如何构建一个良好架构的应用服务层,是应用软件开发者需要着重解决的问题。

为了使应用服务层的设计达到最好的效果,通常还需要对应用服务层作进一步的职能分析和层次细分。很多开发者在构建应用服务层的时候,把数据库操纵、业务逻辑处理甚至界面显示夹杂在一起,或者,把业务逻辑处理等同于数据库操纵等等,这些缺陷在虎蜥ABP_J2EE敏捷业务平台的设计中都得到了有效的规避。

应用软件系统架构,是软件工程的重要组成部分。设计一个好的框架,其目的很明确,那就是,在目前还没有"银弹"之前,尽最大的可能,提高软件开发的效率和软件质量,把不必要的工作和容易出错的工作,交给框架去处理。

应用服务层,在软件系统中,是一个非常复杂的部分,乍看之下,没有任何规律可行,给人无从下手的感觉。我们的目标,就是尽量化无规律为有规律,把有规律的东西提取出来,形成规范,从而减少今后的开发工作量。其方法,就是对系统进行合理的分层,这样,系统的层次清晰了,每个层次完成的功能就比较单一,就意味着每个层次的都相对更有规律可循,这样,我们就可以把这些有规律的东西交给框架去执行,或者,开发一个辅助工具,来完成这部分的代码编写工作。ABP_J2EE敏捷业务平台就提供了这样一个代码自动生成的工具。在实际开发过程中,能够提供很多便利。这是系统层次清晰带来的另外一个好处。

4.ABP_J2EE敏捷业务平台的模块结构


虎蜥ABP_J2EE 模块主要包含(如下图):

(1)业务对象模型

(2)功能模型

(3)流程模型

(4)机构模型

(5)权限管理工具

(6)界面配置工具

(7)统计决策工具

(8)图表工具

(9)企业建模工具

(10)SOA迁移工具(SOA兼容工具)

5.平台插件工具与平台的关系


虎蜥ABP_J2EE敏捷业务平台由基础架构和各类工具组成,这些工具共分为四类:

(1)基本软件平台工具

(2)信息资源管理工具

(3)基本业务工具

(4)高级业务工具


其中,基础软件平台工具包括:权限管理、配置工具、集成工具、报表工具、查询统计工具等,这些工具作为敏捷业务平台架构不可缺少的部分与ABP_J2EE平台是集成在一起,是业务基础软件平台的基本组成部分,而其他的三类工具(信息资源管理工具、基本业务工具、高级业务工具)则是通过约定的接口,与平台架构进行集成,我们形象的把它们比作插件工具,就像积木一样插接在平台上,和ABP_J2EE 形成有机的整体。但这些工具不是每个系统必要的,而是根据客户的项目的需要来选择。

6.ABP_J2EE敏捷业务平台的信息化实施策略


从软件开发和维护的角度来说,传统的企业应用软件系统实施和开发周期的阶段有:需求分析、设计、编码、测试、发布(实施)、维护(定制、升级等)。如下图所示:

这个过程中,编码、测试是决定和保证质量的重要手段,也是项目成本的主要发生点。然而,对于以标准套件和二次开发这种以项目形式运作的开发行为来说,可以调动的人力资源是有限的,特别是对于项目比较多的软件公司,因而难以保证二次开发人员的数量、质量和时间。另外,二次开发的巨大工作量使得很多实施人员心存畏惧,转而力图推广标准模式等可以减轻开发商负担的实施模式,最终忽略了用户在标准模式和流程之外的需求,降低了实施质量。

虎蜥ABP_J2EE敏捷业务平台以通用的配置平台技术为基础,结合标准功能组件,以需求分析、功能组件设计开发和组件配置为手段,力图在减少编码测试成本的同时,开发符合用户需要的信息化软件产品,提高项目实施的成功率。采用虎蜥ABP_J2EE 敏捷业务平台的开发实施过程如下图所示:


虎蜥敏捷业务ABP_J2EE敏捷业务平台项目实施过程

由于平台各个组件通过长期的配置实践,已经相当稳定,通过用配置活动代替编码和测试可以大大缩短开发周期,获得稳定的客户业务系统。配置平台由专门的开发团队维护,并且针对信息录入、查询、检索和报表以及信息通知、报警、编码、权限控制等功能开发了标准的可配置模块,从而以配置文件代替编码,降低定制难度,使得用户也可以方便地使用平台配置工具配置系统功能。

此外,对于不能通过通用平台解决的功能需求,可以编写符合配置平台接口要求的特别定制的业务组件。通过特定业务组件、ABP_J2EE 敏捷业务平台的基本组件、业务系统通用的业务模块组件协同工作,为客户量身定做出剪裁得当的软件系统。由于大量标准、原子化功能组件的采用,特定业务组件的工作量一个人完全可以胜任。同时,由于功能的组件化,系统问题仅仅被限制在特定业务组件上,其影响范围和可更改性都是可控的,易实现的。

传统的二次开发中经常出现“定制负效应”:后期开发的一些功能影响到整个系统,导致系统进行二次开发的次数越多,系统的稳定性和质量下降的越快的现象。正是由于这个原因,很多软件公司不愿意对产品进行二次开发,即使进行二次开发,也会收取昂贵的费用。而对基于ABP_J2EE 敏捷业务平台进行开发和实施而言,由于平台本身的灵活性和高度可定制性可以快速的满足企业用户的需求,从而在根本上规避了这个问题。

7.ABP_J2EE敏捷业务平台简介



7.1. ABP_J2EE集成配置环境

虎蜥ABP_J2EE敏捷业务平台配置导航图

虎蜥ABP_J2EE 的集成配置平台环境

7.2. ABP_J2EE敏捷业务平台功能列表

系统功能


(1)配置向导

(2)系统命名空间设置

(3)通用代码设置

(4)系统分类

业务对象配置


(1)数据对象设置

(2)数据字典

(3)数据编码

(4)插件配置管理

(5)录入页配置

(6)查询页配置

(7)图表页配置

(8)报表页配置

(9)插件页配置

(10)表单页配置

(11)模糊查询配置

用户界面配置


(1)树视图配置

(2)功能页面配置

(3)菜单配置

页面功能配置


功能操作配置

权限配置


(1)组织结构配置

(2)角色配置

(3)权限设置

配置工具


(1)报表工具

(2)统计分析工具

(3)树视图配置工具

(4)图表配置工具

7.3. 用ABP_J2EE敏捷业务平台版本

公司目前有两个版本的开发平台,均拥有完全的知识产权:

(1) 基于Microsoft .NETC/S版本 ABP_J2EE 2.0

(2) 基于J2EEB/S版本 ABP_J2EE 3.0

7.4. 用ABP_J2EE开发的主要步骤

平台开发的主要步骤(如下图):

(1) 企业建模

(2) 信息建模

(3) 平台配置(配置数据对象、配置页面、配置Tab页、配置树结构、配置查询、配置操作、配置角色、配置菜单、配置权限等)

(4) 软件集成

(5) 软件发布