CN101414945A - 一种信息系统的构建平台系统及其方法 - Google Patents

Abstract

本发明公开了一种信息系统的构建平台系统，能更好的满足企业信息系统建设的需求，更能适应未来的变化，成为随需应变的信息系统。其技术方案为：系统包括：用户接口层模块，提供用户登录系统的入口，包含用于支持客户端设备的用户接口适配器；数据服务层模块，以WEB服务的形式提供对数据库的访问，通过集中统一地管理所有数据来消除信息孤岛；业务流程层模块，面向数据服务层的WEB服务，通过以业务为组成单元的建模方式定义和实现业务流程，通过与自己分离解耦的数据服务层访问数据库。本发明应用于信息系统领域。

Description

一种信息系统的构建平台系统及其方法

技术领域

本发明涉及使用计算机进行业务管理的系统和方法，尤其涉及一种构建计算机管理信息系统(数字神经系统)的软件平台系统及其实现方法。

背景技术

进入21世纪的企业，处于快速变化的环境中，信息系统必须提供必要的技术来满足企业发展、法规遵从等要求，并提供更广泛的服务。但是，在当前的软件架构下，IT团队始终处于被动状态，面临的挑战日益严峻，在满足不断变化的业务需求与不能实现随需应变的信息系统之间，存在着越来越大的差距。

企业IT系统当前面临的问题是，没有针对它的一套架构方法，产品孤岛之间的数据使用不一致，无法实现客户的单一视图。渠道集成或“客户接触点”集成可能引起包括高度的复杂性、高昂的成本，缺乏足够的灵活性及可扩展性等诸多问题。

目前的信息系统如图1所示，这种信息系统的架构具有以下的特点：(1)各个应用单独开发，各自为政，其数据库也单独设计，形成一个个信息孤岛。(2)开发各个应用所采用的理念、方法、技术不一样，没有考虑应用间流程的集成和交互，没有统一的接口。(3)每个应用都有自己的用户管理和安全控制机制，没有统一的门户。(4)缺少全面的管理控制功能。(5)应用的业务流程大都是硬编码程序，应变能力差。

基于上述架构的信息系统，必然存在以下的缺陷：(1)每个应用各自为政，形成一个个信息孤岛，应用和业务流程的无缝集成很难实现。(2)系统结构和功能僵化，应变能力差，无法快速应对变化，需要不断投入人力物力进行系统改造和升级，甚至推倒重来。(3)缺少帮助业务人员进行业务创新和管理创新的技术手段。(4)缺乏统一的系统门户，业务人员疲于应付，工作效率低下。(5)随着应用的增多，管理的复杂度增加，管理和安全存在失控的危险。

鉴于目前的IT架构存在的问题，后来提出了面向服务的架构(Service-Oriented Architecture，SOA)。SOA是基于标准的、松散耦合的面向服务的架构。基于Web服务的SOA架构与过去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准(如XML和SOAP)提供了在各不同厂商解决方案之间的交互性。而松散耦合将分布计算中的参与者隔离开来，交互两边某一方的改动并不会影响到另一方。这两者的结合意味着公司可以实现某些Web services而不用对使用这些Web services的客户端的知识有任何了解。但是目前的实现方法是在现有的各个应用各自为政的IT架构的基础上，添加SOA的组件，以期取得良好的效果。

在满足用户的业务需求方面，工作流管理系统不必事先之道问题域的相关信息，而是将业务流程描述作为输入并管理流程实例的执行。目前的业务流程建模技术存在以下的不足：(1)对业务流程中活动之间的关系的分析不全面，基本划分成串行关系和并行关系二类(分支、循环、子流程等关系本质上都可归于这二类)，导致无法对复杂的业务和管理活动建模。(2)建模元素的设置不合理，建模元素过多，用户不易理解。例如，将事件与活动分开，而活动中却也可以包含事件。将活动之间的某些关系或路径用专门的元素来表示(如branch，Fork、Join、Merge等元素)，而它们中的大多数本来是可以直接用活动之间的连接线来直观表示的。(3)以流程(Process)为管理单位，管理粒度太大，无法实现层次化精细化的管理，也无法实现自动流程与人工流程的完美结合。(4)无法表达复杂的业务流程，建立的流程模型一般不能直接运行，一部分需要靠编程实现。(5)现在的业务建模还离不开技术，不懂软件技术的一般用户无法定义，因此项目的实施离不开技术人员。(6)业务流程实现时所作的变动使之无法与定义的业务流程模型保持同步。由于以上的缺陷，导致目前的工作流管理系统还存在许多的不足，无法取代现有的应用系统，只能作为现有应用系统的补充。

发明内容

本发明的目的在于解决上述问题，提供了一种信息系统的构建平台系统，能更好的满足企业信息系统建设的需求，更能适应未来的变化，成为随需应变的信息系统。

本发明的另一目的在于提供了一种通过上述的构建平台系统进行业务处理的方法。这种以业务(任务)为中心的模式可以大大简化甚至取消传统的固定的组织结构，形成灵活的、以任务为中心的组织结构，有助于改善现有组织结构总是跟不上实际需要的情形，使组织反应迅速，增强组织的应变能力。

本发明的技术方案为：本发明揭示了一种信息系统的构建平台系统，包括：

用户接口层模块，提供用户登录系统的入口，包含用于支持客户端设备的用户接口适配器；

数据服务层模块，以WEB服务的形式提供对数据库的访问，通过集中统一地管理所有数据来消除信息孤岛；

业务流程层模块，面向数据服务层的WEB服务，通过以业务为组成单元的建模方式定义和实现业务流程，通过与自己分离解耦的数据服务层访问数据库。

上述的信息系统的构建平台系统，其中，该用户接口层模块包括一显示代码配置单元，接收用户设定的配置参数自动生成显示代码。

本发明还揭示了一种通过上述的信息系统的构建平台系统进行业务处理的方法，包括：

(1)建立业务数据库和数据访问服务层；

(2)接收用户管理信息的定义并保存在平台系统的数据库中，并为角色分配权限；

(3)接收对访问业务数据库的WEB服务的定义并保存在平台系统的数据库中；

(4)接收任务定义并保存在平台系统的数据库中，定义的任务是一个自包含的对象，任务既包含业务流程同时又是业务流程的组成单元，任务是可重用的业务建模单元也是可单独执行和单独管理的业务单元，而且任务包括任务属性、任务的输入信息和正文信息、任务的分解结构、任务调用的WEB服务、任务发送的邮件要素；

(5)在接收到任务产生请求后，根据定义的任务属性产生任务实例，并从有权执行本任务的用户列表中选择任务的接收者，产生任务后同时修改任务实例的任务关系。

上述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(4)进一步包括：

(4.1)定义任务输入信息和任务正文信息以及两者之间的信息映射；

(4.2)指定任务调用的WEB服务；

(4.3)定义任务关系，任务关系即业务流程，任务之间的关系包括父子关系、前后关系、并列关系三种；

(4.4)定义任务接口，任务接口分为用于接收产生任务实例的指令的输入接口和用于发送产生任务实例的指令的输出接口；

(4.5)定义任务关系建模的元模型；

(4.6)指定任务关系中任务节点的类型，任务节点的类型分为正常型、永久型、多实例型、重复型和临时型；

(4.7)指定任务间的信息映射，为每对有产生关系的任务间指定信息映射关系；

上述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(4.1)的任务输入信息和任务正文信息用XML信息结构表示，两者之间的信息映射用XML格式来保存。

上述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(4.2)还包括分别指定任务正文信息与WEB服务的输入参数和输出参数之间的信息映射。

上述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(4.7)中指定的信息映射关系通过图形界面实现。

上述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(2)和步骤(3)之间还包括：

接收元素类型的定义，并将其保存在平台系统的数据库中，其中元素用于组成任务的正文信息结构。

上述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(5)之后还包括：

(6)根据任务定义的任务正文信息架构、任务正文信息和显示格式来显示任务的信息；

(7)接收用户对任务的操作，调用该操作对应的WEB服务以访问业务数据库，这些操作包括退回、委托、开始、执行、结束、追回。

上述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(7)之后还包括：

(8)接收用户对任务的管理，包括显示任务、取消任务、修改任务实例关系、指定共享用户和角色、改变任务的用户。

本发明对比现有技术有如下的有益效果：本发明通过完全基于SOA的三层体系结构：用户接口层模块、数据服务层模块以及业务流程层模块，数据集中统一管理，消除了信息孤岛。而且数据服务层模块和业务流程层模块完全分离并解耦，增加了系统的适应性和灵活性。本发明还基于XML和WEB服务技术，通过WEB服务访问应用数据库。本发明的系统以任务为组成单元，每一级任务都有一定的自主性，使得信息系统的建设摆脱了对技术人员的依赖，信息系统的建设完全由用户主导，可实现用户想要的任何业务流程。所有员工共同参与，而且大大简化了IT基础架构，使得使用和维护简单，一般业务人员就能胜任大部分工作。

附图说明

图1是传统的信息系统的架构示意图。

图2是本发明的信息系统的构建平台系统的较佳实施例的架构示意图。

图3是本发明的通过上述的信息系统的构建平台系统进行业务处理的方法的较佳实施例的流程示意图。

图4是图3实施例中定义任务步骤的子流程图。

图5是本发明的一个示例BUG管理系统的BUG状态变化图。

图6是BUG管理系统的BUG业务流程图。

图7是BUG管理系统的编程管理业务流程图。

图8是BUG管理系统的开发管理业务流程图。

图9是业务建模的图形元素的示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的描述。

本发明的信息系统的构建平台系统是一种基于SOA架构的以业务为中心的企业信息系统平台，集业务、管理、交流和协作为一体。这种构建平台系统能实现各种业务流程，集成所有的应用和服务，让所有人协同工作，并能适应环境的不断变化。因此，这种构建平台系统是一个以人为本的数字神经系统平台，组织中的任何人，只要进入这个系统，就能参与任何项目，获取任何信息，完成任何业务。

信息系统的构建平台系统的实施例

图2示出了本发明的构建平台系统的一个实施例的架构。请参见图2，本实施例的构建平台系统分为三大层：用户接口(UI)层模块10、业务流程层模块12和数据服务层模块14。对于用户接口层模块10来说，提供用户登录整个系统的入口，包含支持各种UI设备的适配器(Adaptor)，可支持WEB浏览器、移动终端等各种客户端设备。较佳的，用户接口层模块10还包括显示代码配置单元100，接收用户设定的配置参数自动生成显示代码，消除了开发显示程序的需要。对于数据服务层模块12，与业务流程层模块12彻底分离，以WEB服务的形式提供对数据库16的访问，通过集中地统一地管理所有数据来消除信息孤岛。对于业务流程层模块12，通过以业务为组成单元的建模方式来定义和实现业务流程，通过数据服务层模块14来访问数据库16。以上的用户接口层模块10、业务流程层模块12和数据服务层模块14相互独立，各层模块的变化不会影响要其他的层次，这使得各层模块可以单独改变。由于业务流程层模块14完全是面向数据服务层模块14的WEB服务的，因此对整个构建平台系统而言，是真正面向SOA架构的系统。

数据服务层模块14不用考虑业务流程的实现，从全局着手，按企业业务数据需求和数据本身应有的结构和关系来设计，对数据的访问以WEB服务的方式提供，同时保证数据的完整性和一致性。这提供了以下的优点：由于不用考虑业务流程的实现，因此开发变得更为容易和稳定；由于与业务流程分离，因此不会受到对方变化的影响；由于数据服务层模块14可以供业务流程层模块12中的任何业务流程访问，轻易实现数据的共享和集中统一管理。

业务流程层模块12定义和实现各种业务流程，以及各种业务之间或者跨系统业务之间的集成。负责整个构建系统的管理、控制、交流和协作。在业务流程层模块12还植入了安全机制，任何人只能访问已授权的业务和数据。

对于本发明实施例的构建平台系统来说，类似于一个地球架构。数据库类似于地球的地核，保存数据。数据服务层模块14类似于地幔，充当对数据库访问的门户，而且将数据库和业务流程层模块12隔离解耦。业务流程层模块12类似于地幔之上的生物圈，各种业务相当于生物圈内的各种生物群落。用户接口层模块10相当于用户登录系统的一个端口。

通过信息系统的构建平台系统进行业务处理的方法的实施例

图3示出了本发明的通过上述的信息系统的构建平台系统进行业务处理的方法的较佳实施例的流程。

第一步是建立业务数据库和访问该业务数据库的数据访问服务层(DAS)，这一步是在系统之外实现的。

第二步是接收用户管理信息的定义并保存在构建平台系统的数据库中，同时为角色分配权限(对应图3的步骤①)。这一步可由构建平台系统中的用户管理子模块来实现，具体包括：定义组织结构，包括公司、机构和部门；定义角色及其对任务的执行权限；定义用户信息以及为用户分配角色。而定义好的这些组织结构、角色以及用户信息都保存在数据库中。一般而言，为角色分配的权限包括任务的使用权限、任务的执行权限以及任务的产生权限，使用权限是指用户能否在任务种类列表中看到任务并在定义任务时使用它，执行权限是指能否接收和执行该任务种类，产生权限是指能否直接产生该任务的实例。

第三步是接收元素类型的定义并将其保存在构建平台系统的数据库中，元素用于组成任务的正文信息结构(对应图3的步骤②)。这一步可由构建平台系统中的元素定义子模块来实现，在该构建平台系统中，每个任务都有它的信息结构(Schema)，而信息结构是由不同类型的元素组成的。因此在定义任务之前需要先定义任务要用到的元素类型，特别是一些任务要用到的复杂元素类型。值得注意的是，这一步骤并不是必须的，在定义任务信息结构的后续步骤中也可以直接定义元素类型，但是只有在本步骤中定义的元素类型才是可以被所有的任务共享的。定义好的元素类型用XML Schema格式保存在数据库中。

第四步是接收访问业务数据库的WEB服务的定义并保存在构建平台系统的数据库中(对应图3的步骤③)。这一步可由构建平台系统的WEB服务定义子模块来实现。WEB服务指的是访问业务数据库的服务，位于数据访问服务层(DAS)。在本发明的构建平台系统中，任务可能要引用或调用各种WEB服务，在定义任务之前，先要对这些WEB服务进行定义。这里所谓的定义，就是将网络上已经存在的WEB服务登记到构建平台系统中，以供定义任务时使用。对于非查询的WEB服务，应该定义WEB服务的调用成功返回码，以判断调用WEB服务是否成功。通常在定义一个WEB服务时会将WEB服务的所有方法都导入。定义好的WEB服务也用XML Schema格式保存在数据库中。

第五步是接收任务的定义并保存在构建平台系统的数据库中(对应图3的步骤④)。这一步可由构建平台系统的任务定义子模块来实现。

对于业务流程的建模方式，本发明通过以下两个方面来实现。首先是完全面向业务的建模，构建平台系统将所有的业务活动包装成任务，因此面向业务建模就是面向任务建模。这里的任务是一个自包含的对象，既包含业务流程，同时又是业务流程的组成单元。任务既是可重用的业务建模单元，也是可单独执行和可单独管理的业务单元。面向任务建模的好处有：(1)由于任务封装了活动的所有细节，大大简化了业务建模的复杂度；(2)任务可直接反映和表达业务需求，一般用户都可以理解和操作，不需要技术人员的参与，这就消除了业务需求与软件实现之间的鸿沟，能更快更好地满足用户的需求；(3)可重用性强，定义好的任务可以很容易地放到别的任务中，就象搭积木一样；(4)任务比目前业界流行的“基于构件开发”中的构件更“软”和更“轻”，构件是物理上存在的程序代码，需要软件开发人员编程实现，而任务是用户就可以定义的对象，因此更容易改变，改变花费的代价更小，更能适应业务的变化；(5)由于任务包含了WEB服务，用户可以透明地访问网络上的WEB服务，不管它们位于何处，任务将网络上的资源无缝地集成起来了；(6)由于各种业务都是基于相同的单元(任务)构建并在同一种平台上运行，它们之间的“集成”将不会有任何障碍，业务流程的集成问题将成为历史；(7)由于任务定义后可直接运行，因此用户可随时改变他们的业务流程，系统的建设完全由用户主导。

虽然传统的业务建模方法中也有“任务”的概念，但是它们的“任务”与本发明的“任务”有着以下本质的区别：(1)传统的“任务”与“流程”是不同的对象，“任务”是不可再分的原子活动，“任务”是属于“流程”或“子流程”的。而在本发明的构建平台系统中，一切活动皆是任务，“流程”也是任务，所以，任何任务都可属于任务，也可包含其它的任务。构建平台系统中没有“流程”和“子流程”对象。(2)传统的“任务”与“事件”是分开的，而在构建平台系统中，事件是属于任务的，任务之外并没有单独的事件。(3)传统的“任务”简单，只是流程图中的一个节点，不是可重用的业务建模单元。(4)传统的“任务”不是可单独管理的业务单元，是以“流程”为单位进行管理的。(5)传统的“任务”一般不能直接运行，一般需要开发相对应的构件或控件才能运行。

其次本发明的业务建模是通过模拟生物体细胞来设计任务的。本发明的构建平台系统中的任务包括任务属性(如执行模式、度量等)、任务的输入信息和正文信息(可包含WEB服务引用)、任务的分解结构(任务关系)、任务调用的WEB服务以及任务发送的邮件等要素。与生物体细胞相似，任务带有一定的信息，且都可以分解/分裂为更小的单元或组成更大的单元，而且都可以与其他单元形成一定的关系。在构建平台系统中，每个用户都可以产生任务。每个任务可以分解为更小的任务，同时又可以是更大的任务的组成部分，任务之间有一定的关系。使用这种方式能够构建非常复杂的信息系统，并能高效利用资源、对内部和外部的扰动保持高度的弹性、适应所处环境的变化。而且在这个系统中，每一个组成部分都有一定程度的自主性，都能够在没有上一层组织的协助下，在其所处的特定层次上掌握环境和处理问题。同时也能接受来自上层整体的指导，在某种意义上受上层整体的控制。自主性保证了部分(小的整体)是稳定的，能够在干扰下生存，而对上层整体的服从又确保了更大的整体的有效运转。

定义任务的步骤还可以进一步细分为如图4所示的子流程。下面结合图4对该步骤进行进一步的描述。

步骤S50：定义任务输入信息和任务正文信息以及两者之间的信息映射。

一般产生一个任务时需要输入一些信息，以让任务接收者明白做什么，这称为任务的输入信息，任务输入信息的结构用XML Schema表示。产生任务时，任务输入信息一般由产生的任务通过任务间信息映射输入，直接产生任务时则由手工输入。

任务的正文信息即任务的内容，是显示任务时看到的信息。任务正文信息可能包括任务产生者输入的一些信息和任务接收者输入的信息。任务的正文信息中可包含对WEB服务的引用。可以对任务正文信息中的元素定义附加属性，也称为用户接口属性，主要用来控制元素的显示和输入。任务正文信息的结构用XML Schema来表示。

任务输入信息与任务正文信息之间的信息映射用XML格式保存，在产生任务时构建平台系统自动将输入信息的值转换到正文信息中。

步骤S51：指定任务调用的WEB服务。

任务是通过调用WEB服务访问业务数据库的。如果执行任务时需要访问业务数据库，则应该指定任务调用的WEB服务。为了实现任务与WEB服务之间信息的传递，还要分别指定任务正文信息与WEB服务的输入参数与输出参数之间的信息映射。

步骤S52：定义任务关系。

任务关系就是业务流程，定义任务关系实质上就是定义业务流程。任务关系是指任务的分解关系，是属于任务的，因此任务关系的定义是任务定义的组成部分。

任务关系分为三种：父子关系、前后关系和并列关系。其中父子关系是整体与部分的关系，属于不同的任务层次。一个任务只能有一个父任务，但一个任务可以有多个子任务。父任务必须先于子任务产生，子任务必须先于父任务结束。从本质上说父子关系体现了活动的目的性。当两个或多个任务之间的执行有先后顺序时就属于前后关系。前任务和后任务属于相同的任务层次，一个任务可以有多个前任务，也可以有多个后任务。前任务必须先于后任务产生和结束。从本质上看，前后关系反映了活动的时间性。属于并列关系的任务之间没有执行的先后顺序，也即互不影响。从本质上看前后关系反映了活动的时间性。从本质上看并列关系反映了活动的空间性

任务关系必须满足一定的要求：(1)任务只能由它的父任务或前任务产生，或者直接由任务定义产生一个项目，或由输入接口产生。(2)先有父任务，后有子任务；先有前任务，后有后任务。(3)父任务天然有产生子任务的权利，但如果一个任务已经定义为由前任务产生，则它不应该由父任务产生。如果一个任务没有定义为前任务产生，则前任务不能产生它，它只能由父任务产生。

通过上述三种任务关系的排列组合，可以形成各种各样的任务关系，以表示各种各样的业务流程。

步骤S53：定义任务接口。

任务接口用来实现不同流程/系统之间的集成。任务接口分为输入接口和输出接口，其中输入接口用于接收产生任务实例的指令，输出接口用于发送产生任务实例的指令。任务接口不能单独存在，必须依赖于任务存在。任务接口的另一作用是突破了任务之间严格的层次关系和前后关系，作为对它们的有力补充，相当于在任务之间引入了非线性关系。

任务接口功能也是用Web服务实现的。

步骤S54：定义任务关系建模的元模型。

如图9所示，业务建模的图形元素包括：一般任务900；决策任务901；表示汇总与任务902，所有前任务都结束才产生和执行；表示汇总或任务903，任一个前任务结束就产生和执行；表示任务接口904，通常有输入接口和输出接口这两种任务接口；表示任务之间的连线905；表示任务之间的连接和手工产生关系906，箭头由任务指向被产生的任务；表示任务之间的连接和自动产生关系907，箭头由任务指向被产生的任务；表示显示任务时，可以手工跳转到(显示)另一任务908；表示任务执行完成后，自动跳转到(显示)一个任务909；父子关系910，由父任务的上边或下边引出，连接到子任务的左边；前后关系911，由前任务的右边引出，连接到后任务的左边；并列关系912，两个以上任务的左边互相连接在一起。

步骤S55：指定任务关系中任务节点的类型。

一个任务节点的生命周期分为五种类型：正常型，指正常产生和结束的任务，这是默认的类型；永久型，指产生一次，长期存在，且不能结束的任务；多实例型，指可以产生多个实例，且都保存的任务；重复型，指产生一次，可以重复执行，但不结束的任务；临时型，指正常产生和结束，但不需要保存，也不会修改任务关系的任务。

步骤S56：指定任务间的信息映射，为每对有产生关系的任务间指定信息映射关系。

在任务关系中，如果一个任务产生另一个任务，就需要指定产生任务的正文信息与被产生任务的输入参数之间的映射关系。如果该任务由父任务产生，则应指定父任务与它的信息结构间的映射关系；如果该任务由前任务产生，则应指定前任务与它的信息结构间的映射关系。任务关系的定义可以通过上述的图形界面来实现，定义好的任务关系保存在构建平台系统的数据库中，定义后的任务称为任务种类。

第六步是在接收到任务产生请求后，根据定义的任务属性产生任务实例，并从有权执行本任务的用户列表中选择任务的接收者，产生任务后同时修改任务实例的任务关系(对应图3的步骤⑤)。

第七步是根据任务定义的任务正文信息架构(XML Schema)、任务正文信息(XML)和显示格式来显示任务的信息(对应图3的步骤⑥)。

第八步是接收用户对任务的操作，这些操作包括退回、委托、开始、执行、结束、追回等。当处理或执行一个任务时，如果为该操作定义了WEB服务，则会调用相应的WEB服务(对应图3的步骤⑦)以访问业务数据库。

第九步是接收用户对任务的管理(对应图3的步骤⑧)，包括显示任务、取消任务、修改任务实例关系、指定共享用户和角色、改变任务的用户。构建平台系统中的管理是基于任务及其相互关系来实现的，只要授予了权限，通过一个任务就可以进入到相关的任务。

构建平台系统的这种以任务(业务)为中心的管理模式，通过定义业务流程(任务关系)，各种相关联的任务已经按业务的内在逻辑联系在了一起，任务之间的协作轻而易举，每个用户只要执行自己的任务，就可以与他人进行紧密的协作。此外在用户之间还可以进行通信交流。

BUG管理系统的示例

图5示出了本发明的一个应用示例—软件开发项目中的BUG管理系统。软件开发中BUG管理因涉及到测试人员、开发人员和项目经理等多个角色，是一项比较繁重的工作。BUG从提交到关闭，有一个完整的生命周期，如果管理得不好，就会影响项目的进度及软件的质量。传统的BUG管理软件虽然对BUG本身进行了较好的管理，但不能让BUG与测试人员和开发人员的工作进行无缝的集成。建立在本发明的构建平台系统上的BUG管理系统很好地解决了这个问题。

首先，分析BUG管理的业务流程。BUG可以分为六个状态：N表示新发现，A表示已指派，F表示已解决，H表示暂不修改，C表示已关闭，X表示已删除。BUG状态的变化路径如图5所示。

然后，设计和建立BUG管理数据库，开发访问BUG管理数据库的WEB服务。比如提交一个BUG服务、查询BUG服务、修改BUG的状态服务等。

再定义BUG管理项目的业务流程(业务关系)，如图6所示。其中“BUG管理”是正常型项目。“提交BUG”是永久型任务，包含WEB服务引用。“BUG查询&选择”是重复型任务，包含WEB服务引用。“判断BUG状态”是决策型任务。“显示新BUG”、“显示已分配BUG”、“显示已解决BUG”、“显示已关闭BUG”、“显示已挂起BUG”、“显示已删除BUG”都是临时型任务，包含WEB服务引用。“挂起BUG”等也是临时型任务，包含WEB服务调用。“分配BUG”通过任务输出接口为编程管理项目中的开发人员产生修正BUG的任务，包含WEB服务调用。“BUG检查”是多实例型任务，接收编程管理系统发送过来的检查BUG任务，让测试人员检查BUG是否真的被修正，如果检查合格测试人员就关闭该BUG，否则就重新提交该BUG，包含WEB服务调用。

编程管理项目的业务流程如图7所示，其中“修正BUG任务”是多实例型任务，接收BUG管理系统发送过来的修正BUG任务，让开发人员修正BUG。当修正完BUG后，开发人员就结束该任务，同时通过输出接口给BUG管理系统发送一个检查BUG的任务，供测试人员使用。

如前所述，整个业务流程的逻辑完全搭建起来，无需任何的硬编码，并且随时可以调整。通过建立在构建平台系统之上的BUG管理项目和编程管理项目，BUG的生命周期就被很好地管理起来，同时与测试人员、开发人员和项目经理等人的工作实现了无缝结合，极大提高了开发项目的工作效率。

此外，BUG管理和编程管理又可以组合成更上一级的项目—开发管理项目，开发管理项目业务流程如图8所示。依次类推，开发管理项目又可以和别的项目(比如销售管理项目)组成更上一级的项目(公司管理项目)，直至整个公司的管理都包括进来，形成企业的数字神经系统。

上述实施例是提供给本领域普通技术人员来实现或使用本发明的，本领域普通技术人员可在不脱离本发明的发明思想的情况下，对上述实施例做出种种修改或变化，因而本发明的保护范围并不被上述实施例所限，而应该是符合权利要求书提到的创新性特征的最大范围。

Claims (10)

1、一种信息系统的构建平台系统，包括：

用户接口层模块，提供用户登录系统的入口，包含用于支持客户端设备的用户接口适配器；

数据服务层模块，以WEB服务的形式提供对数据库的访问，通过集中统一地管理所有数据来消除信息孤岛；

业务流程层模块，面向数据服务层的WEB服务，通过以业务为组成单元的建模方式定义和实现业务流程，通过与自己分离解耦的数据服务层访问数据库。

2、根据权利要求1所述的信息系统的构建平台系统，其特征在于，该用户接口层模块包括一显示代码配置单元，接收用户设定的配置参数自动生成显示代码。

3、通过如权利要求1或2所述的信息系统的构建平台系统进行业务处理的方法，包括：

(1)建立业务数据库和数据访问服务层；

(2)接收用户管理信息的定义并保存在平台系统的数据库中，并为角色分配权限；

(3)接收对访问业务数据库的WEB服务的定义并保存在平台系统的数据库中；

(4)接收任务定义并保存在平台系统的数据库中，定义的任务是一个自包含的对象，任务既包含业务流程同时又是业务流程的组成单元，任务是可重用的业务建模单元也是可单独执行和单独管理的业务单元，而且任务包括任务属性、任务的输入信息和正文信息、任务的分解结构、任务调用的WEB服务、任务发送的邮件要素；

(5)在接收到任务产生请求后，根据定义的任务属性产生任务实例，并从有权执行本任务的用户列表中选择任务的接收者，产生任务后同时修改任务实例的任务关系。

4、根据权利要求3所述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(4)进一步包括：

(4.1)定义任务输入信息和任务正文信息以及两者之间的信息映射；

(4.2)指定任务调用的WEB服务；

(4.3)定义任务关系，任务关系即业务流程，任务之间的关系包括父子关系、前后关系、并列关系三种；

(4.4)定义任务接口，任务接口分为用于接收产生任务实例的指令的输入接口和用于发送产生任务实例的指令的输出接口；

(4.5)定义任务关系建模的元模型；

(4.6)指定任务关系中任务节点的类型，任务节点的类型分为正常型、永久型、多实例型、重复型和临时型；

(4.7)指定任务间的信息映射，为每对有产生关系的任务间指定信息映射关系。

5、根据权利要求4所述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(4.1)的任务输入信息和任务正文信息用XML信息结构表示，两者之间的信息映射用XML格式来保存。

6、根据权利要求5所述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(4.2)还包括分别指定任务正文信息与WEB服务的输入参数和输出参数之间的信息映射。

7、根据权利要求6所述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(4.7)中指定的信息映射关系通过图形界面实现。

8、根据权利要求3所述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(2)和步骤(3)之间还包括：

接收元素类型的定义，并将其保存在平台系统的数据库中，其中元素用于组成任务的正文信息结构。

9、根据权利要求3所述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(5)之后还包括：

(6)根据任务定义的任务正文信息架构、任务正文信息和显示格式来显示任务的信息；

(7)接收用户对任务的操作，调用该操作对应的WEB服务以访问业务数据库，这些操作包括退回、委托、开始、执行、结束、追回。

10、根据权利要求9所述的通过信息系统的构建平台系统进行业务处理的方法，其特征在于，步骤(7)之后还包括：

(8)接收用户对任务的管理，包括显示任务、取消任务、修改任务实例关系、指定共享用户和角色、改变任务的用户。

Images