CN103513976B - 业务流程建模方法及装置 - Google Patents

Abstract

本发明公开了一种业务流程建模方法及装置。其中，该方法包括：根据统一建模语言（UML）类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型；为业务流程建立表示两个业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型；根据多个逻辑关系模型连接每个业务能力接口模型，并编排业务流程获得编排后的业务流程的框架代码。通过本发明，解决了用动态图来表示业务流程的局限的问题，进而能够达到方便第三方更容易地使用业务，降低开发者对编程能力和业务能力接口理解的要求，最终为用户提供了一个所见即所得的业务能力及功能使用体验的效果。

Description

业务流程建模方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种业务流程建模方法及装置。

背景技术

随着电信网络的逐步开放，具有特定功能的电信业务能力接口也越来越多。第三方开发者希望能够更容易地使用这些电信业务能力接口，降低对电信业务能力接口的理解、以及程序设计能力的要求。基于此目的，有必要通过图形化业务建模方式来为用户提供一个所见即所得的电信业务能力及功能使用体验。

作为可以为面向对象软件设计提供统一的、标准的、可视化的建模语言，UML（Unified Modeling Language，统一建模语言）描述了一个系统的静态结构和动态行为，将系统描述为一些离散的相互作用的对象并最终为外部用户提供一定功能的模型。在UML中，UML图包括静态图和动态图，类图属于静态图，用来表示类的属性、操作，以及类与类之间的关系；动态图则用来表示系统对象的动态变化。在传统的业务流程编排中，使用UML进行业务流程编排时都是利用类图来表示对象，运用动态图来实现业务流程编排，这充分利用到了静态图和动态图的优点。但是，类图在使用时，只能描述一个对象或是两个对象之间的关系（例如，实现、继承等），而不能描述动态的业务流程及逻辑迁移。而在利用动态图来表示业务流程编排时又存在另外一个问题，即动态图涉及到的对象不能准确地描述一个具体的业务能力或其接口，动态图的对象只存在一个属性-“对象名称”，而且，现存所有的UML建模软件中，没有一个动态图能够实现流程到代码的自动生成。

针对当前基于UML进行业务流程建模中，类图不能描述动态的业务流程及逻辑迁移，动态图涉及到的对象不能准确地描述一个具体的业务能力或其接口，而且无法实现流程到代码的自动生成的问题，目前尚未提出有效的解决方案。

发明内容

本发明提供了一种业务流程建模方法及装置，以至少解决上述问题。

根据本发明的一个方面，提供了一种业务流程建模方法，包括：根据统一建模语言（UML）类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型；为业务流程建立表示两个业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型；根据多个逻辑关系模型连接每个业务能力接口模型，并编排业务流程获得编排后的业务流程的框架代码。

优选地，根据统一建模语言（UML）类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型，包括：将每个业务能力接口封装为一个UML类图，其中，每个UML类图能够指示其对应的业务能力接口所具备的业务功能；根据每个UML类图指示的业务功能为UML类图对应的业务能力接口建立一个业务能力接口模型。

优选地，在根据每个UML类图指示的业务功能为UML类图对应的业务能力接口建立一个业务能力接口模型之后，方法还包括：为每个业务能力接口模型定义模型属性；为每个业务能力接口模型定义模型功能，并进行封装。

优选地，模型属性包括：模型背景、模型形状、业务名称以及模型图标。

优选地，模型功能包括：业务功能和函数调用功能，其中，函数调用功能能够调用的函数中包括业务能力接口对应的业务的源代码。

优选地，为业务流程建立表示两个业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型，包括：判断业务流程在逻辑迁移过程中的连接源模型和连接目的模型是否属于业务能力接口模型；在判断结果为是的情况下，建立连接源模型和连接目的模型之间的逻辑关系模型。

优选地，获得编排后的业务流程的框架代码，包括：根据转换机制将编排后的业务流程转换为框架代码，其中，转换机制是对业务能力接口模型和逻辑关系模型进行映射得到的。

优选地，每个业务能力接口模型中包括唯一的业务能力模型身份ID；每个逻辑关系模型中包括唯一的逻辑关系模型身份ID。

根据本发明的另一方面，提供了一种业务流程建模装置，包括：第一建立模块，用于根据统一建模语言（UML）类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型；第二建立模块，用于为业务流程建立表示两个业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型；编排模块，用于根据多个逻辑关系模型连接每个业务能力接口模型，并编排业务流程获得编排后的业务流程的框架代码。

优选地，第一建立模块包括：封装单元，用于将每个业务能力接口封装为一个UML类图，其中，每个UML类图能够指示其对应的业务能力接口所具备的业务功能；第一建立单元，用于根据每个UML类图指示的业务功能为UML类图对应的业务能力接口建立一个业务能力接口模型。

优选地，第二建立模块包括：判断单元，用于判断业务流程在逻辑迁移过程中的连接源模型和连接目的模型是否属于业务能力接口模型；第二建立单元，用于在判断结果为是的情况下，建立连接源模型和连接目的模型之间的逻辑关系模型。

优选地，每个业务能力接口模型中包括唯一的业务能力模型身份ID；每个逻辑关系模型中包括唯一的逻辑关系模型身份ID。

通过本发明，采用基于UML类图进行动态业务流程的编排，为用户提供了一个完全图形化的业务流程编排过程，同时生成相应的框架代码的方式，解决了用动态图来表示业务流程的局限的问题，进而能够达到方便第三方更容易地使用业务，降低开发者对编程能力和业务能力接口理解的要求，最终为用户提供了一个所见即所得的业务能力及功能使用体验的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的业务流程建模方法流程图；

图2是根据本发明优选实施例的业务流程建模方法流程图；

图3是根据本发明优选实施例的业务流程编排流程图；

图4是根据本发明优选实施例的业务流程编排效果图；

图5是根据本发明优选实施例的动态业务流程编排模型转换的JAVA框架代码示意图；

图6是根据本发明实施例的业务流程建模装置的结构框图；以及

图7是根据本发明优选实施例的业务流程建模装置的结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

首先，对本发明实施例提供的业务流程建模方法的思路进行一个简要介绍：在UML建模开发环境中将业务能力接口进行封装为类图，其中，每一个业务能力接口都可以看作是一个类，用类的方法和属性来表示这个业务能力的功能。每一个业务能力的封装可以看作成一个类的实例的封装。进而，增加新的关系模型用于描述业务流程的逻辑迁移过程，新的关系模型区别于原先UML类图中的关系模型，代表所连接的类图之间的逻辑关系，用于表示业务能力接口的状态转移。进一步，为业务能力接口模型与描述逻辑迁移过程的关系模型创建对应的功能框架代码。其中，每个新建立的业务能力接口模型和关系模型需要预先代码封装。最后，选择代表所需业务能力接口的模型，根据逻辑关系，选择新的逻辑关系模型，并连接相关的多个业务能力接口模型，完成业务流程编排，从而通过正向工程（UML类图转换为代码）获得所编排的业务流程对应的框架代码。

图1是根据本发明实施例的业务流程建模方法流程图，如图1所示，该方法主要包括以下步骤（步骤S102-步骤S106）：

步骤S102，根据统一建模语言（UML）类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型；

步骤S104，为业务流程建立表示两个业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型；

步骤S106，根据多个逻辑关系模型连接每个业务能力接口模型，并编排业务流程获得编排后的业务流程的框架代码。

在本实例中，步骤S102可以这样实施：先将每个业务能力接口封装为一个UML类图，其中，每个UML类图能够指示其对应的业务能力接口所具备的业务功能，再根据每个UML类图指示的业务功能为UML类图对应的业务能力接口建立一个业务能力接口模型。

其中，在根据每个UML类图指示的业务功能为UML类图对应的业务能力接口建立一个业务能力接口模型之后，还可以为每个业务能力接口模型定义模型属性；为每个业务能力接口模型定义模型功能，并进行封装。

在本实例中，模型属性可以包括：模型背景、模型形状、业务名称以及模型图标。

在本实例中，模型功能可以包括：业务功能和函数调用功能，其中，函数调用功能能够调用的函数中包括业务能力接口对应的业务的源代码。

在本实例中，步骤S104可以这样实施：判断业务流程在逻辑迁移过程中的连接源模型和连接目的模型是否属于业务能力接口模型，在判断结果为是的情况下，建立连接源模型和连接目的模型之间的逻辑关系模型。

在本实例的步骤S106中，在获得编排后的业务流程的框架代码时，可以通过这样的方式来实现：根据转换机制将编排后的业务流程转换为框架代码，其中，转换机制是对业务能力接口模型和逻辑关系模型进行映射得到的。

在本实例中，每个业务能力接口模型中包括唯一的业务能力模型身份ID；每个逻辑关系模型中包括唯一的逻辑关系模型身份ID。

下面结合图2至图5以及优选实施例对上述业务流程建模方法的具体流程进行详细说明。

图2是根据本发明优选实施例的业务流程建模方法流程图，如图2所示，该方法主要包括以下步骤（步骤S202-步骤S214）：

步骤S202，使用UML类图建立业务能力接口模型。

（1）建立类图基本实体模型对应的父类，该父类通过子类的ID，可以获得子类代表的业务能力接口并存储在父类的列表中，并可对子类对应的业务能力接口进行函数添加、删除、查找、识别等操作。

（2）使用UML类图为某种业务能力接口建立一个业务能力接口模型（属于独立的实体模型），并应继承自类图基本实体模型（即建立业务流程的模型）对应的父类，并给业务能力接口模型定义一个主属性（ID）以便识别。

（3）将业务能力接口模型集成在UML建模工具的开发环境之中。此步骤依赖与具体的集成开发环境。

例如：在查询天气业务的实例中，包括发送查询天气短信和打包接收结果短信这两个业务能力接口，则将这两个能力接口使用类图建立相应的实体模型。

步骤S204，为业务能力接口模型定义模型属性。

为业务能力接口模型定义类图模型属性，包括模型背景，形状及业务名称、图标等特有属性。若一个业务流程编排中多次使用某一个业务能力接口，则此接口的属性在原有基础上加1，如实例中的名称显示为Send1，Send2，但ID不会发生变化。

步骤S206，为业务能力接口模型定义相应的功能并封装。

在本实施例中，业务能力接口模型除了支持类图原先的基本功能，还能通过封装源代码来决定接口的功能,即分别建立针对不同业务模型的函数，将相应业务的源代码存储于此函数之中，若有特殊情况，可将代码做分段处理。存储完成后，等待下一步的调用。

例如，短信天气查询中的SendModel业务能力接口表示的功能为发送查询短信，则建立一个名为SendSource（）的方法，将发送查询天气短信的源代码以字符串的形式存储在其中。

步骤S208，建立表示业务流程的逻辑迁移过程的关系模型。

不同于原UML中类图之间的关系模型，本实施例中，建立了一种新的可表示业务能力接口间逻辑关系的新型关系模型，该关系模型可识别所连接源与所连接目的模型的功能，即若连接源与目的都属于步骤S202中定义的业务能力接口模型父类时，建立源业务接口与目的业务接口之间的逻辑关系方法。

（1）首先建立新型关系模型父类。在实体模型对应的父类中使用了能够识别在此模型后面的连接模型的add（）函数，调用此函数将关系模型和业务能力接口模型连接在了一起。在关系模型的父类中定义获取其连接的两个业务能力接口模型的名称信息函数，通过此函数读取连接目的和源业务能力接口模型的名称属性。

（2）使用UML类图为每一种或所需的逻辑关系（判断/条件循环/无条件循环等）分别建立一种关系模型，并应继承自关系模型父类，并给模型定义一个主属性（ID）以便识别。父类通过此ID，可以获得子类代表的关系模型类型并存储在父类的列表中，并可对子类对应的关系模型进行函数添加、删除、查找、识别等操作。

步骤S210，为新的关系模型进行功能预定义与代码封装。

（1）在通过ID识别出关系模型的类型（如动态调用、条件判定），生成相应的函数来储存代码，通过步骤S208中的步骤（1）找出此关系模型连接的源业务能力接口模型，将连接模型的代码创建在此源业务能力接口源代码的函数中。根据业务编排的逻辑顺序，将代表业务间逻辑迁移过程的关系模型代码放在源业务能力接口代码位置之后。

（2）对于一个业务能力接口模型有一个以上的关系模型相连的情况：为每个关系模型添加一个初始化为0的标签变量，当遍历父类列表时存在此关系，将标签变量置1，多条连接线的变量间建立按位或的关系，若结果为1，则调用封装所有关系模型代码的函数。在封装所有关系模型代码的函数中，要重新判断关系模型的种类，从而决定执行哪些代码模块。

例如，在短信天气查询中，SendModel与GetModel之间的关系为SendModel需要在特定的一个条件下，执行一个函数才能转移到GetModel，则代表此函数的关系模型代码添加在类的执行主体之中，Public class Send{关系模型代码}。根据查询天气业务的原理，可以知道上述这两个类间存在条件判定后调用的关系，即发送查询短信后，若发送的短信内容符合要求，则会进行打包接收。通过上述步骤，建立一个名为Connection1的关系模型，ID为Connection1Model，代码以以下形式封装在函数relation中：

Public voidmain（）{

If（）{class a=class.forname（/"getModelname（Target））}

}

步骤S212，将业务能力接口模型与关系模型集成到开发环境中。

此步骤依赖与具体的集成开发环境，主要是以插件方式增加相应的业务接口模型、新型关系模型的视图显示及属性到相应的集成开发环境中。

例如，定义一个继承Eclipse中GEF工具栏的视图区域，GEF中已有函数定义了工具栏的相关属性，在函数变量中填入业务能力接口模型与关系模型的模型名称，图形标识与创建模型的指令。工具栏以列表形式将所有模型列出。

步骤S214，建立业务能力接口模型及关系模型映射为框架代码的转换机制。

（1）在建模环境中集成代码转换选项。

例如，采用Eclipse为集成开发环境，则需通过在Eclipse插件配置文件plugin.xml的extentions中添加菜单popupMenues，其拥有固定的可修改变量，更改后可在开发环境中出现java转换选项。

（2）建立代码转换运行机制：首先遍历业务能力接口模型父类的ID列表，识别业务能力接口后，执行封装其源代码的函数，在此函数中，继续遍历关系模型父类列表，重置关系模型变量，按位或结果为1则调用relation函数，读取关系模型代码。每一个业务能力接口模型分别转换为一个代码文件，显示上述读取完成后的包括业务能力接口与关系模型的源代码。

图3是根据本发明优选实施例的业务流程编排流程图，如图3所示，该流程主要包括以下步骤（步骤S302-步骤S306）：

步骤S302，在工具栏中选取合适的业务接口所对应的类图模型，并对该图形进行操作，自行添加变量、赋值与定义相关功能。

步骤S304，根据业务流程之间的逻辑联系，在关系模型中选择适合的模型，将前后业务进行逻辑连接。

步骤S306，通过代码转换工具选项将上述建立的类图及关系模型转换为框架代码。

至于完成业务流程编排后的结果，请参考图4，图4是根据本发明优选实施例的业务流程编排效果图；为了更清楚地理解通过代码转换工具选项将上述建立的类图及关系模型转换得到的框架代码，也请同时参考图5，图5是根据本发明优选实施例的动态业务流程编排模型转换的JAVA框架代码示意图。

采用上述实施例提供的业务流程建模方法，可以通过基于UML类图进行动态业务流程的编排，为用户提供了一个完全图形化的业务流程编排过程，同时生成相应的框架代码以方便用户的编程实现，进而实现第三方能够更容易地使用业务，降低开发者对编程能力和业务能力接口理解的要求，最终为用户提供了一个所见即所得的业务能力及功能使用体验。

图6是根据本发明实施例的业务流程建模装置的结构框图，该装置用以实现上述实施例提供的业务流程建模，该装置主要包括：第一建立模块10、第二建立模块20以及编排模块30。其中，第一建立模块10，用于根据统一建模语言UML类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型；第二建立模块20，连接至第一建立模块10，用于为业务流程建立表示两个业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型；编排模块30，连接至第二建立模块20，用于根据多个逻辑关系模型连接每个业务能力接口模型，并编排业务流程获得编排后的业务流程的框架代码。

图7是根据本发明优选实施例的业务流程建模装置的结构示意图，如图7所示，在该优选实施例提供的装置中，第一建立模块10可以包括：封装单元12，用于将每个业务能力接口封装为一个UML类图，其中，每个UML类图能够指示其对应的业务能力接口所具备的业务功能；第一建立单元14，连接至封装单元12，用于根据每个UML类图指示的业务功能为UML类图对应的业务能力接口建立一个业务能力接口模型。

在该优选实施例提供的装置中，第二建立模块20可以包括：判断单元22，用于判断业务流程在逻辑迁移过程中的连接源模型和连接目的模型是否属于业务能力接口模型；第二建立单元24，连接至判断单元22，用于在判断结果为是的情况下，建立连接源模型和连接目的模型之间的逻辑关系模型。

在该优选实施例中，每个业务能力接口模型中包括唯一的业务能力模型身份ID；每个逻辑关系模型中包括唯一的逻辑关系模型身份ID。

采用上述实施例提供的业务流程建模装置，可以通过基于UML类图进行动态业务流程的编排，为用户提供了一个完全图形化的业务流程编排过程，同时生成相应的框架代码以方便用户的编程实现，进而实现第三方能够更容易地使用业务，降低开发者对编程能力和业务能力接口理解的要求，最终为用户提供了一个所见即所得的业务能力及功能使用体验。

从以上的描述中，可以看出，本发明实现了如下技术效果：上述实施例是在UML建模软件的环境下完成的，采用基于UML类图进行动态业务流程的编排，为用户提供了一个完全图形化的业务流程编排过程，同时生成相应的框架代码以方便用户的编程实现，实现了用类图及增加新的关系模型来表示业务逻辑迁移的动态流程，实现了全部图形化的业务流程编排，并支持将图形化业务流程编排结果自动转为相应的框架代码。进一步地，能够实现第三方能够更容易地使用业务，降低开发者对编程能力和业务能力接口理解的要求，最终为用户提供了一个所见即所得的业务能力及功能使用体验。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种业务流程建模方法，其特征在于，包括：

根据统一建模语言UML类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型；

为所述业务流程建立表示两个所述业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型；

根据多个所述逻辑关系模型连接每个所述业务能力接口模型，并编排所述业务流程获得编排后的业务流程的框架代码；

其中，所述方法还包括：建立类图基本实体模型对应的父类，该父类通过子类的ID，可以获得子类的业务能力接口并存储在父类的列表中，并可对子类对应的业务能力接口进行函数添加、删除、查找、识别操作；

其中，根据所述UML类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型还包括：继承自类图基本实体模型对应的所述父类，为所述业务能力接口模型定义用于识别的一个主属性ID；将所述业务能力接口模型集成在UML建模工具的开发环境之中。

2.根据权利要求1所述的方法，其特征在于，根据统一建模语言UML类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型，包括：

将每个所述业务能力接口封装为一个所述UML类图，其中，每个所述UML类图能够指示其对应的所述业务能力接口所具备的业务功能；

根据每个所述UML类图指示的业务功能为所述UML类图对应的所述业务能力接口建立一个所述业务能力接口模型。

3.根据权利要求2所述的方法，其特征在于，在根据每个所述UML类图指示的业务功能为所述UML类图对应的所述业务能力接口建立一个所述业务能力接口模型之后，所述方法还包括：

为每个所述业务能力接口模型定义模型属性；

为每个所述业务能力接口模型定义模型功能，并进行封装。

4.根据权利要求3所述的方法，其特征在于，所述模型属性包括：模型背景、模型形状、业务名称以及模型图标。

5.根据权利要求3所述的方法，其特征在于，所述模型功能包括：所述业务功能和函数调用功能，其中，所述函数调用功能能够调用的函数中包括所述业务能力接口对应的业务的源代码。

6.根据权利要求1所述的方法，其特征在于，为所述业务流程建立表示两个所述业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型，包括：

判断所述业务流程在逻辑迁移过程中的连接源模型和连接目的模型是否属于所述业务能力接口模型；

在判断结果为是的情况下，建立所述连接源模型和所述连接目的模型之间的逻辑关系模型。

7.根据权利要求1所述的方法，其特征在于，获得编排后的业务流程的框架代码，包括：

根据转换机制将所述编排后的业务流程转换为所述框架代码，其中，所述转换机制是对所述业务能力接口模型和所述逻辑关系模型进行映射得到的。

8.根据权利要求1至7中任一项所述的方法，其特征在于，

每个所述业务能力接口模型中包括唯一的业务能力模型身份ID；

每个所述逻辑关系模型中包括唯一的逻辑关系模型身份ID。

9.一种业务流程建模装置，其特征在于，包括：

第一建立模块，用于根据统一建模语言UML类图为业务流程所需要的每个业务能力接口建立各自的业务能力接口模型；

第二建立模块，用于为所述业务流程建立表示两个所述业务能力接口模型之间逻辑关系的一个或多个逻辑关系模型；

编排模块，用于根据多个所述逻辑关系模型连接每个所述业务能力接口模型，并编排所述业务流程获得编排后的业务流程的框架代码；

其中，所述装置还包括：建立类图基本实体模型对应的父类，该父类通过子类的ID，可以获得子类的业务能力接口并存储在父类的列表中，并可对子类对应的业务能力接口进行函数添加、删除、查找、识别操作；

其中，所述第一建立模块：继承自类图基本实体模型对应的所述父类，为所述业务能力接口模型定义用于识别的一个主属性ID；将所述业务能力接口模型集成在UML建模工具的开发环境之中。

10.根据权利要求9所述的装置，其特征在于，所述第一建立模块包括：

封装单元，用于将每个所述业务能力接口封装为一个所述UML类图，其中，每个所述UML类图能够指示其对应的所述业务能力接口所具备的业务功能；

第一建立单元，用于根据每个所述UML类图指示的业务功能为所述UML类图对应的所述业务能力接口建立一个所述业务能力接口模型。

11.根据权利要求9所述的装置，其特征在于，所述第二建立模块包括：

判断单元，用于判断所述业务流程在逻辑迁移过程中的连接源模型和连接目的模型是否属于所述业务能力接口模型；

第二建立单元，用于在判断结果为是的情况下，建立所述连接源模型和所述连接目的模型之间的逻辑关系模型。

12.根据权利要求9至11中任一项所述的装置，其特征在于，

每个所述业务能力接口模型中包括唯一的业务能力模型身份ID；

每个所述逻辑关系模型中包括唯一的逻辑关系模型身份ID。