CN1629869A - 产生和管理商业过程集成解决方案的系统和方法 - Google Patents

Abstract

产生并管理商业过程集成解决方案的系统和方法包括根据实体的定义的商业目的和目标，对商业策略建模，所述商业策略包括表现商业度量和主动性的要素；用包括过程任务、工件流和工件库的商业过程要素，和包括合并关键性能指标的商业承诺要素，对所述实体的商业操作建模；用操作模型的工件和过程要素映射策略模型的要素；测量商业性能并比较性能度量和所述关键性能指标。由于过程度量和比较的结果，在解决方案开发周期内，可持续改进所述商业策略和操作模型过程要素。还实现一种商业级建模语言，以便正规表示商业操作。

Description

产生和管理商业过程 集成解决方案的系统和方法

技术领域

本发明涉及商业系统和基础结构，更具体地说，涉及产生和管理商业过程集成解决方案的系统和方法。

背景技术

从根据用户知识和现有文献的商业过程着手，产生操作和管理该商业过程的优化IT解决方案目前是一项成本高、费时的任务。目前，商业过程建模的实用性有限，即主要在包括徒手绘制的图表的文档中说明商业过程建模，缺少正规的语义学。结果从而包含只能在代码级共享的非结构化解决方案知识。此外，完成的解决方案不易于或者不能自动与初始的过程模型一致，商业过程性能难以测量，并且难以用于重建商业过程。

目前已知的关于该问题的解决方案的成本效率不高，时间效率也不高，此外，并不覆盖整个端对端商业过程。例如，Holosofx是一种产生商业过程模型和工作流的流行工具，但是不能用于产生其它必需的组件，例如应用适配器或商业对象。Crossworlds InterChangeServer是一种实现商业对象和商业逻辑操作的工具，但是不进行商业过程建模或工作流产生和处理。

从而，非常需要为商业过程集成和管理解决方案提供一种系统和方法。

此外，非常需要提供一种商业级建模语言，所述语言正规地从各个方面，包括作为信息技术(IT)执行模型的实现基础的策略操作和执行观点，描述功能商业模型，并便于与商业过程开发生存期内改变商业目的和目标相应的商业过程重建。

发明内容

本发明的目的是提供一种节省成本并且节省时间的解决方案，所述解决方案提供商业过程集成和管理解决方案，尤其是可产生商业过程的IT解决方案的新过程。

根据本发明的优选实施例，提供一种产生商业集成和管理解决方案的完整系统和方法。本发明的创新点在于建模的商业活动和解决方案产生过程中每个步骤的输出的正规定义。在每个步骤中，根据明确的模式和规范，产生一个或多个文档或其它工件。用软件实现的算法使关键步骤自动化，或者通过用图形用户界面利用工具，帮助关键步骤。模式和规范使工作产物有效，确保与其它组件和整个模型的兼容性。另一关键要素是在极早阶段中引入关键性能指标，接下来实现软件探测器，以便收集商业过程性能数据。一旦部署该解决方案，则向商业分析员报告这些数据，以便调整性能和重构商业过程。

在这些目的的实现中，向商业过程解决方案的整个生命周期提供全面的方法和工具集，包括：1)策略层的商业策略建模；2)操作层的商业过程建模，在操作模型中，用承诺和关键性能指标定义商业过程度量结果；3)过程模型到信息技术(IT)解决方案的转换，IT解决方法由预定类型的解决方案工件组成，包括：商业对象，自适应商业对象，宏流，微流，EAI适配器，B2B连接器，用户互作用屏幕流；4)模型的模拟，以便进行静态和动态分析；5)关键性能指标到IT解决方案中IT探测器的映射；6)在一组集成的图形工具中定义IT解决方案工件的细节；7)把解决方案工件绑定和部署到特定运行时平台；8)监视并报告由来自探测器的事件数据服务的关键性能指标测量的商业过程性能；和9)代理的可选调用，以便推荐和/或实现对商业过程的提高其性能的改变。

附图说明

结合附图，根据下面的详细说明，对本领域的技术人员来说，本发明的目的、特征和优点将变得显而易见，其中：

图1是图解说明根据本发明的产生自适应商业解决方案的模型驱动方法的一般方框图；

图2图解说明了根据本发明的端对端商业过程建模系统和组件100；

图3图解说明了根据本发明的商业解决方案产生生命周期；

图4图解说明了表现商业运作观点的商业运作规范(BopS)模型。

具体实施方式

本发明定义一种过程，借助该过程，能够产生商业过程的IT解决方案。在每个步骤中，产生可供未来步骤之用的，或者在以后在其它解决方案的产生过程中，重复使用的一组具体的工件。

图1描述了产生自适应商业解决方案的模型驱动方法10。在该方法中，捕捉商业语义，随后直接实现改变商业的IT变化。该方法包括：(1)为每个主要的用户角色和用途，在恰当的抽象层建立商业的模型的步骤，和(2)相对于彼此以及相对于IT基础结构，映射、变换和连接这些模型，从而操纵模型对应于操纵实现代码。操纵模型而非操纵代码的优点在于一般来说，和代码相比，模型更易于理解和操纵。例如，如同面向对象的Java开发人员不希望操纵汇编代码那样，需要修改商业操作的商业用户-不论是经营范围(a line of business)管理员，商业分析员或商业过程设计专家-并不希望操纵Java代码或者甚至BPEL(商业过程执行语言)脚本来理解当前的过程或者改变当前的过程。相反，经营范围管理员希望操纵形象的商业操作模型，形象的商业操作模型是关于该用户和用途的商业语义的恰当抽象层。

如图1中所示，方法10包括使模型变成可执行的代码的步骤。用于三种主要用户角色和组织用途的三级模型包括：1)例如以记分卡(目的的量化)和目标(可度量的目标)的形式定义商业目的和目标的策略模型12。由执行者21，或者类似的商业专业人员进行这种策略建模；2)操作模型14以商业过程、承诺和映射到记分卡以便与它们的关键目标比较的KPI(关键字性能指标)量度(metrics)定义商业做什么。这种操作建模由经营范围(Line-of-Business)(LOB)管理员(manager)31、商业分析员或类似的商业级用户进行。在策略模型的产生中，提供数据链接结构，以便借助操作模型映射策略模型。最好，操作模型14被半自动变换成3)以独立于平台的方式，用具体的应用、数据源、人员和合作者定义如何执行商业操作的执行模型16。这种执行建模由例如IT设计师或类似的IT专业人员进行。在策略模型的产生中，提供软件数据结构，以便把操作模型变换成执行模型。最后，需要进行一些开发，以便连接独立于平台的执行工件(artifact)和诸如WAS J2EE或MS.NET平台之类具体的平台实现模型18，并通过利用Web服务实现专用API。这种实现建模由例如IT开发人员51、或者类似的IT专业人同进行。

在这些映射、变换和连接就位的情况下，原始事件，交易23以及环境数据可被捕捉并集合到商业量度中，例如投资收益率(ROI)或每股收益(EPS)，以便与商业活动监视(BAM)控制板(dashboard)中的商业承诺和目标比较。通过多个反馈循环25a-25c，连续优化/检测和响应(CO/SaR)技术随后可提供管理操作例外的决策支持，并提前建议改变商业过程，以便最佳地实现商业目标。最后，主要通过操纵模型而不是代码-和传统的商业变换事务相比，需要少得多的时间和成本，现在能够直接把商业方向方面的变化从策略模型向下传送到IT基础结构。这允许和修改模型一样快速和容易地修改商业过程。

图2图解说明了端对端商业过程建模系统100和各个组件。在优选实施例中，ABS原理的第一步骤103是用外部定义的商业内容，填充商业级建模(BLM)库，例如存储器装置或数据库110。上述商业专业人员，例如执行者可实现收集或产生保存在库110中的外部定义的商业内容的商业策略造模工具或任意类似方法。该内容包括(但不限于)现有的或者需要通过会见商业过程中涉及的人员而产生的商业过程的文献。接下来在步骤106涉及利用商业分析员(例如商业操作管理员)产生商业操作的形式模型，例如通过利用称为Business ViewEditor(BE)的工具。BE是允许商业用户或分析员以图表200的形式，产生商业过程的模型的图形工具，图表200的每个组件和连接都具有明确的含义。该商业过程的图形表示200在符合某一模式(schema)，例如XML模式的文档中，具有对应的文本表示。如同这里更详细说明的那样，这种模式提供包括建模过程任务、商业工件流和工件库(repository)的商业操作的子模型的形式过程。商业过程模型200可保存在相同的商业级模型(BLM)库110中，以便稍后取出、重复使用、定制或修改，或者保存在另一类似的库中(未示出)。如同这里更详细说明的那样，用规定商业的操作观点的称为BOpS(商业操作规范)的形式语言描述商业过程模型。实现称为TransformationWizard 150(变换向导)的工具的另一步骤108被用于把BLM 200变换成IT级模型(ILM)250。在作为参考包含于此的同时待审的美国专利申请No.＿＿(美国律师编号YOR920030143US1(16596))中更详细地说明了这种变换过程。

更具体地说，Transformation Wizard 150可自动把商业级模型变换成IT级模型(ILM)250。Transformation Wizard可由使用不同的方法产生解决方案的IT体系结构的一种或多种备选算法自动操作。算法识别将在ILM 250中使用的必需组件，包括(但不限于)诸如商业对象201、自适应实体(自适应商业对象)202、屏幕流203、宏流(macroflow)和工作流(workflow)204，微流(可自动执行的任务)205，和应用(application)或企业对企业适配器206之类组件。自适应实体是关于商业对象可具有的各种状态和商业对象能够经历的转变的规定。工作流是一系列的活动，其中的一些活动涉及人类交互作用。应用适配器是允许独立的应用和商业过程集成的软件。企业对企业适配器是使外部商业合作人能够与商业过程结合的软件。

步骤115由IT开发人员51进行，IT开发人员51实现运行时(runtime)开发工具185，例如IT级Editor或“Binding Wizard”工具(未示出)，可用于查看或修改这一级的工件。一般来说，采用一个或多个IT级Artifact Editor(工件编辑器)来进一步指定每个组件的细节。这是必要的，因为对于商业级模型来说，包含足以充分定义IT级的所有组件的足够细节不现实。分别取回(如果先前已经产生)或产生用于现有应用和商业合作人的适配器。从资产库400取回这些适配器，和ILM中的工件一起被“Binding Wizard(绑定向导)”工具用于产生组件之间的绑定，随后把这些绑定保存在资产库400中。具体地说，Binding Wizard使用定义的适配器和ILM库中的命令产生具体的绑定。

另一种运行时开发工具是产生可部署的解决方案，例如文件，并把它们部署在本地或远程机器上的Package Generator(包产生器)。即，根据选择的软件和硬件平台和技术，产生平台专用组件，整个解决方案被打包并保存在运行时工件库500中。该包随后随时可以测试和部署在客户的环境中。

图3描述了在开发生命周期275中，是如何产生和管理商业解决方案的。如图所示，查找预期解决方案的商业目标包括如同这里更详细说明的那样，利用诸如BOpS之类商业过程建模语言，形式表现商业操作模型280；对诸如模拟引擎283之类的相关“运行时”平台进行静态和动态分析282的分级结构。如同这里说明的那样，建立预期的解决方案需要开发体系结构模型285，开发IT工件287，随后产生集成中件(WBI)289。由此，通过执行产生商业观察模型290，定制商业活动监视器292，和实现查看模型的探测器(供给模型)和控制板295的步骤，观察和监视商业过程。观察和监视数据被反馈(297)给第一层次，以便进一步改进和找到最佳解决方案。

如上所述，根据商业操作规范(BOpS)描述商业过程模型，BOpS是一种商业级建模语言。商业级模型提供商业操作的形式表现，反映过程和商业政策，客户要求，限制因素和解决方案环境。商业分析员和经营范围用户将定义这种模型。

可独立于任意IT实现，单独把商业级模型用于成本分析，过程模拟，资源分配或优化研究。BOpS模型的一个预期用途是用作这类独立应用的基础。另外，BOpS模型预定被用作IT实现的起点和顶极“托架(bracket)”：作为起点，因为将提供帮助把模型改进到可执行的解决方案层次的辅助工具和过程；作为顶级“托架”，因为BOpS模型将保持与部署的解决方案互锁，并用作商业活动监视，基于实时数据的过程分析和过程重构的基础。

BOpS模型的其它扩展可覆盖资源分配和部署，记帐和收费，资产管理，安全性，目录和组织结构，企业信息模型，内部和外部联系渠道等的企业模型。预期BOpS模型用作建立企业的模型的几乎各个方面的公共核心和起点。

BOpS模型是企业所有者的观点的形式表现。第二种定位BOpS的方式和解决方案开发生命周期相关：它是解决方案的第一形式表现，在初始机会评估和要求收集，策略公式化之后，并在任意IT体系结构确定之前。

另一种定位BOpS的方式和对解决方案建模的粒性(granularity)相关：这是商业级用户认识到的最细致的表现。从商业用户的观点来看，BOpS任务，资源和工件是“原子的”(一个人可把发票撕成碎片，或者折卸计算机，但是结果不再被看作“商业文档”或“系统资源”)。

商业系统的观点有三种。表现商业是什么的操作观点，描述商业为何如此的策略观点，和描述商业如何如此的执行观点。商业过程建模的多数工作集中于执行层。基于表示商业的操作观点的最佳方式是集中于商业处理的工件和影响这些工件的生命周期的商业要素的思想，建立BOpS。这些商业要素分成三类：代表在这些工件的环境中实现的不可还原的商业功能的商业任务，用作这些工件的存储器的工件库，和定义关于商业要素的聚合的布局的商业过程。BOpS描述的商业模型还被分解成三个子模型。信息模型捕捉商业工件和商业事件。功能模型捕捉商业过程，商业任务和工件库。资源模型捕捉角色和资源组。

很自然地发现对商业操作建模涉及对语句的三种基本组成：主语(行动者)，动词(动作)和宾语(工件)建模。从而，如图4中所示，BOpS模型300具有三个部分：资源模型(描述行动者)302；功能模型(描述动作)304；和信息模型(描述工件)306。资源模型302描述行动者和他们的能力。资源308(可以是人力资源，自动化资源，或外部资源)有资格充任角色，角色被定义为完成任务的能力的聚合。角色309可被“划分范围(scoped)”，这种情况下，这些能力具有任务实例(或工件)相关性。注意资源可被组织(商业单位，部门，合作人)所有。功能模型304以商业过程，商业任务和用作企业处理的工件的存储器的工件库的形式，描述动作。这里同样确定模型的一致性：哪些任务利用何种资源处理哪些工件，任务如何通过工件的交换，被互连(排序)。最后，信息模型306描述商业任务互换的工件(“文档”，“工作产品”)312和商业事件(“消息”、“信号”)。另外，它表征任务环境和商业谓词(predicate)，任务环境保持任务需要的临时信息，商业谓词模拟关于所有信息模型组成的约束，以及所有信息模型组成之间的关系。

如图4中所示，图中图解说明了和BOpS一起工作的两个互补模型的应用。商业过程承诺(commitment)语言(BPCL)316用于指定商业操作的关键性能指标(KPI)318。包括模式322的模拟模型320规定商业操作的模拟参数。

现在借助这里更详细说明的每个语言结构的细节，概略说明BOpS的语法。在最高层，BOpS使用商业模型结构定义商业的操作观点。商业模型中包括的是信息模型、功能模型和资源模型。下面本说明书使用非正式的语法描述XML片断的XML文法：语法表现成XML实例，但是数值指示数据类型而不是数值；粗体文法前面一直没有介绍，在例子中也不特别关心粗体文法；<--description-->是来自一些“other”名称空间的元素的占位符(类似于XSD中的##other)；如下把字符附到元素、属性和<！--description-->上：“？”(0或1)，“*”(0或更大)，“+”(1或更大)。字符“[”和“]”用于表示包含的项可相对于“？”、“*”或“+”字符看作一组；被“|”隔开和被“(”和“)”聚合在一起的元素和属性意味着语义替换物；XML名称空间前缀(下面定义)被用于指示正被定义的元素的名称空间；始于＜？xml的例子包含和本说明书相符的足够信息；其它例子是片断，并且为了相符，需要指定额外的信息；以文法的正规定义的形式提供XSD模式。下面借助如上所述的语言的基本结构，说明基础商业模型的语法结构：

 <businessModel name＝”string”targetNamespace＝”anyURI”？

        expressionLanguage＝”anyURI”？

        xmlns＝”http://www.ibm.com/2002/07/business-process/bops/”>

           <informationModel>

                    informationmodel

           </informationModel>

           <functionalModel>

                    <businessProcess name＝”ncname”abstract＝”true|false”？extemal＝”true|false”？

                                    automatic＝”true|false”？transactional＝”true|false”？compensation＝”true|false”？>+

                             businesselement(businessProcess，businessTask，artifactRepository)*

                    </businessProcess>

                    <businessTask name＝”ncname”automatic＝”true|false”？transactional＝”true|false”？

                                  compensation＝”true|false”？>*

                             businesselement(businessTask)

                    </businessTask>

                    <artifactRepository name＝”ncname”>*

                           businesselement(aritifactRepository)

                    </artifactRepository>

           </functionalModel>

           <resourceModel targetNamespace＝”any URI”>？

                    <roles>？

                           <role name＝”string”>+

                                    <scopes？

                                            <scope name＝”string”？value＝”string”>+

                                    </scopes>

                           </role>

                    </roles>

                    <resources>

                           resourceGroup

                    </resources>

           </resourceModel>

           <constraints/>？

                    tConsttaints？

           </constraints>

  </bops>

根据所示的基本结构，顶级属性如下所示：其属性定义模型的名称的“name”；其属性定义文档的目标名称空间的“targetNamespace”；其属性规定过程中使用的表达语言的“expressionLanguage”。该属性的当前默认是由在http://www.w3.org/TR/1999/REC-xpath-19991116的XPath 1.0规范的URI表示的XPath 1.0；“informationModel”描述上面提及的和商业的操作观点有关的工件和商业事件；“functionalModel”描述上面提及的过程、任务、工件库及他们的利用端口和链接的互连；“resouce Model”描述和商业操作相关的上述组织角色和资源组；“constraints”描述确保BOpS商业模型的语义正确性的约束条件。

功能模型

如上所述，标记“businesselement”可以是下述任意之一：businessProcess；businessTask；和artifactRepository。<businessProcess>结构描述具有如下基本语言结构的商业过程：

 <businessProcess name＝”ncname”abstract＝”true|false”？external＝”true|false”？

                 automatic＝”true|false”？transactional＝”true|false”？compensation＝”true|false”？>

         ports？

         <links>？

                   <link fromport＝”ncname”toport＝”ncname”/>*

         </links>

         businesselement(businessProcess，businessTask，artifactRepository)*

         roles？

 </businessProcess>

<businessTask>结构描述如下所述的商业任务：

 <businessTask name＝”ncname”automatic＝”true|false”？transactional＝”true|false”？

              compensation＝”true|false”？>

         ports？

         <taskContext>？

                  <contextVariable name＝”ncname”type＝”qname”？value＝”string”？>*

                           <predicate name＝”ncname”expression＝”string”/>？

                  </contextVariable>

         </taskContext>

         roles？

         <trigger timer＝”true|false”？self＝”true|false”？>？

                    <port id＝”ncname”/>*

         </trigger>

 </busincssTask>

<artifactRepository>结构描述如下所述的工件：

 <artifactRepository name＝”ncname”label＝”string”？>

           ports？

 </artifactRepository>

如下描述上面涉及的标记“ports”：

 <ports>

           <port name＝”string”direction＝”in|out|in-out|out-in”predicate＝”string”？identityPassed＝”true|false”？

 proxyOf＝”ncname”？>*

                     choice

                                <businessArtifactType name＝”ncname”/>

                                <businessEventType name＝”ncname”/>

                     choice

                     <predicate name＝”ncname”expression＝”string”/>？

           </port>

 </ports>

信息模型

如下描述上面涉及的标记“informationmodel”：

<businessArtifactType name＝”ncname”type＝”qname”？/>*

<businessEventType name＝”ncname”type＝”qname”？/>*

<predicate name＝”ncname”expression＝”string”/>*

资源模型

如下描述上面涉及的标记“roles”：

 <roles>

         <role roleref＝”qname”？>*

                   <brm：role>？

                   ...

                   <brm：role>

         </role>

 </roles>

如下描述上面涉及的标记“resourceGroup”：

 <resource name＝”string”aggregationType＝”bag|sequence|alternative？”>*

          tAtomicResource

          resourceGroup

 </resource>

 <humanResource name＝”string”aggregationType＝”bag|sequence|alternative？”>*

        tAtomicResource

        <humanResource name＝”string”aggregation Type＝”bag|sequence|alternative？”/>*

 </humanResource>

 <systemResource name＝”string”aggregationType＝”bag|sequence|alternative？”>*

         tAtomicResource

         <systemResource name＝”string”aggregationType＝”bag|sequence|alternative？”/>*

 </systemResource>

 <externalResource name＝”string”aggregationType＝”bag|sequence|alternative？”>*

          tAtomicResource

          <externalResource name＝”string”aggregationType＝”bag|sequence|alternative？”/>*

 </externalResource>

如下描述上面涉及的标记“tAtomicResource”：

 <attributes>？

            <attribute name＝”string”value＝”string”？>+

                       <description/>*

            </attribute>

 </attributes>

 <roles>

            <role name＝”string”>+

                     <scope name＝”string”？value＝”string”>*

            </role>

 </roles>

约束

利用Boolean Xpath描述约束条件，并且对于语义要正确的模型来说，约束条件必须被评价为真。如下描述上面涉及的标记“tConstraints”：

  <constraints>？

            <constraint name＝”ncname”expression＝”string”>*

                      <description/>？

            </constraint>

  </constraints>

BOpS商业模型捕捉商业操作的关键工件的生命周期和影响生命周期的商业事件。利用商业谓词捕捉操作层的商业逻辑。商业工件、商业事件和商业谓词是BOpS信息模型的基础。

  <xs：complexType name＝″tArtifact″>

           <xs：attribute name＝″name″type＝″xs：NCName″use＝″required″/>

           <xs：attribute name＝″type″type＝″xs：QName″use＝″required″/>

  </xs：complexType>

BOpS商业模型捕捉商业操作的关键工件的生命周期和影响生命周期的商业事件。利用商业谓词捕捉操作层的商业逻辑。商业工件、商业事件和商业谓词是BOpS信息模型的基础。

商业工件

还提供了使用BOpS定义本例商业的操作观点和描述商业的核心结构。就旅行社的例子来说，旅行预定过程对客户的计划旅程，识别所需的一段飞行航程和宾馆预定。它随后产生负责预定航班和宾馆的子过程。如果所有预约在预定时限内被确认，则打印旅行计划并将其发给客户。

如上所述，BOpS通过商业要素，以工件类型的流的形式捕捉商业工件的生命周期。工件类型的基数属性表示关于某一工件类型的实例的任何限制。工件类型还识别该工件类型的信息变量。工件或者由商业任务处理，或者驻留于工件库中。工件具有下述属性：name：ncname-规定工件的名称；和type：qname-规定工件的类型。它是一个限定(qualified)名称，从而它可在另一名称空间中。工件由其类型属性描述，其类型属性是一个限定名称(参考名称空间)。例证的工件的语法结构如下：

 <xs：complexTypename＝″tArtifact″>

           <xs：attribute name＝″name″type＝″xs：NCName″use＝″required″/>

           <xs：attribute name＝″type″type＝″xs：QName″use＝″required″/>

 </xs：complexType>

商业事件

商业事件(例如来自客户的传真或电话)可传送工件参考或工件内容的副本。从而，商业事件具有下述属性：name，例如指定工件的名称的“ncname”；和type，例如指定工件的类型的“qname”。它是一个限定名称，从而它可在另一名称空间中。商业事件由其类型属性描述，其类型属性是一个限定名称(参考名称空间)。商业事件的语法结构如下：

 <xs：complexType name＝″tBusinessEvent″>

           <xs：complexContent>

                     <xs：extension base＝″tArtifact″/>

           </xs：complexContent>

 </xs：complexType>

商业谓词

商业谓词是用模型中的信息变量和/或工件属性来表示的条件逻辑的表达式。商业谓词可用在BOpS模型中的下述部分中：Port-作为其赋值(evaluation)确定工件是否通过该端口的布尔表达式；ContextVarable-作为其赋值设置变量的数值的正则表达式；和Constraint(s)-作为其赋值验证模型的布尔表达式。利用XPath表述谓词。它具有下述属性：name：ncname-谓词的独特名称；和expression：string：用工件、商业事件或环境变量表示的XPath表达式。谓词的语法结构如下：

 <xs：complexType name＝″tPredicate″>

           <xs：attribute name＝″name″type＝″xs：NCName″ use＝″required″/>

           <xs：attribute name＝″expression″type＝″xs：string″use＝″required″/>

 </xs：compplexType>

如上所述，商业功能模型包括商业要素及他们的连接。商业要素是功能模型中的一般结构，即，它被表示为商业过程，商业任务或者表示为工件库。根据商业工件(例如购买定单，客户记录，合同，发票)的核心概念，建立商业功能模型。注意利用信息模型的结构描述商业工件和商业事件的结构，而用操作模型描述他们的生命周期；商业事件(例如计时器信号，警报，通知)在商业任务之间被交换。商业任务具有工件和事件进出的端口。端口通过链接被连接。此外，模型表征当任务中未处理工件时，商业工件留驻于其中的工件库，和把任务、工件以及潜在嵌套的过程聚合成更大的操作单元的商业过程。注意商业功能模型和现有的多个“流模型”之间的根本区别在于在BOpS中，不存在任何流。只存在由到达的工件或事件产生的任务，进行某些工作，最后发送事件和工件，发送的事件和工件又会产生其它任务。这产生通过工件和事件的交换而连接的“互作用任务网”。可遵循特定工件的路径，并定义所遭遇的任务的顺序为“过程”或“流”。但是，借助这种方法，可按照多个方式把特定BOpS模型分解成多个流，对于处理多个工件的任务来说，甚至不清楚他们属于哪个流或过程。虽然BOpS中的“商业过程”结构可用，但是这实际上应被看作“复合任务”，因为从外部来看，它看起来并且表现得完全像一项任务，具有发送或接收工件和事件的端口。唯一的区别在于对于过程来说，他们的内部操作结构在BOpS内被进一步分解，而基本任务则不是这样的。在资源模型中定义角色，并从商业模型查阅角色。角色识别谁能实现商业功能。

商业要素

商业要素是抽象的结构体。商业过程、商业任务和工件库都扩展商业要素。商业要素的语法结构如下：

 <xs：complexType name＝″tBusinessElement″>

          <xs：complexContent>

                    <xs：extension base＝″bops：tExtensibleElements″>

                              <xs：sequence>

                                        <xs：element name＝″ports″type＝″bops：tPorts″minOccurs＝″0″/>

                                        <xs：element name＝″description″type＝″xs：string″minOccurs＝″0″/>

                              </xs：sequencc>

                              <xs：attributc name＝″name″type＝″xs：NCName″usc＝″required″/>

                    </xs：extension>

          </xs：complexContent>

          </xs：complexType>

端口定义商业要素的接口。端口具有下述属性：

name：ncname-端口的名称；

方向(入|出|入-出|出-入)-端口中信息流的方向。具体地说，“入”表示在该端口接收商业工件或商业事件。如果端口被定义成触发端口，它将触发(参见任务触发器)任务的开始。它必须通过链接连接到对应的“出”端口；“出”表示通过该端口发送商业工件或商业事件。输出端口不能被指定成任务的触发器(参见任务触发器)。它必须通过链接，连接到对应的“入”端口。“入-出”表示接收对商业工件的请求，并回送相应的响应。入-出端口不能被指定为任务的触发器(参见任务触发器)。这些端口对所有商业要素都有效，并且通常在工件库内规定。它必须通过链接，连接到对应的“出-入”端口；“出-入”表示发送关于商业工件的请求，并接收对应的响应。如果该端口被定义成触发端口，则它将触发(参见任务触发器)任务的开始。这里任务是根据预定的条件，监听/轮询某一或某些工件。这些端口对任务和进程有效(对工件库无效)。它必须通过链接，连接到对应的“入-出”端口。

predicate：string-其赋值确定端口是否有效的布尔XPath表达式。信息只能流经有效端口；

identifyPassed：是表示工件的身份是否作为信息流的一部分被传递的布尔(真|假)值。在任意情况下，只有一个商业要素能够持有某一工件的身份。商业要素通过其“identifyPassed”属性被设置为“真”的“出”或“入-出”端口释放工件身份。商业要素通过其“identifyPassed”属性被设置为“真”的“入”或“出-入”端口接收工件身份。默认值被设置成真；

proxyOf：ncname指示对物理端口的参考。该属性表示该端口是一个代理端口，实际上指的是另一端口。它只适用于非抽象过程(它们必须具有涉及属于其子过程、任务和库的端口的端口)。

端口的语法结构如下：

  <xs：complexType name＝″tPorts″>

            <xs：sequence maxOccurs＝″unbounded″>

                      <xs：elcment name＝″port″type＝″bops：tPort″/>

            </xs：sequence>

  </xs：complexType>

  <xs：complexType name＝″tPort″>

            <xs：sequence>

                      <xs：choice>

                                <xs：element name＝″businessEventType″type＝″bops：tBusinessEventRef″/>

                                <xs：element name＝″businessArtifactType″type＝″bops：tBusincssArtifactRef″/>

                      </xs：choice>

                      <xs：element name＝″predicate″type＝″bops：tPredicate″minOccurs＝″0″/>

            </xs：sequence>

            <xs：attribute name＝″name″type＝″xs：NCName″use＝″required″/>

            <xs：attribute name＝″direction″type＝″tPortDrection″use＝″required″/>

            <xs：attribute name＝″predicate″type＝″xs：NCName″use＝″optional″/>

            <xs：attribute name＝″identityPassed″type＝″xs：boolean″use＝″optional″default＝″true″/>

            <xs：attribute name＝″proxyOf″type＝″xs：NCName″use＝″optional″/>

  </xs：complexType>

  <xs：simpleType name＝″tPortDirection″>

            <xs：restriction base＝″xs：string″>

                        <xs：enumeration value＝″in″/>

                        <xs：enumeration value＝″out″/>

                        <xs：enumeration value＝″in-out″/>

                        <xs：enumeration value＝″out-in″/>

            </xs：restriction>

  </xs：simpleType>

商业过程是商业要素，即商业任务、工件库和支持分层结构的其它商业过程的集合。商业过程具有下述属性-

name：ncname-规定商业过程的名称

abstract：布尔值(真|假)-其抽象属性被设置成“真”的过程不被分层分解成更多的任务和工件库，而被看作不透明要素。它只包含定义其接口的端口和指示谁能实现其功能的角色。如果未规定抽象属性，则该值被默认为“假”。

external：布尔值(真|假)-外部属性被设置成“真”的商业过程表示它在BOpS正在建模的商业的企业范围之外。当前版本的BOpS模仿企业的操作和在这些操作环境中，该企业与其合作人的交互作用。如果未规定外部属性，则认为外部属性为“假”。除非另作规定，否则外部过程必定是抽象的(例如，制造商不会定义其供应商的商业过程)。

automatic：布尔值(真|假)-自动属性被设置成“假”的商业过程表示该商业过程需要人的干预才能完成。该过程内的所有任务继承自动属性，并且如果需要，可超越该属性。如果未规定自动属性，则认为自动属性为“真”。

transactional：布尔值(真|假)-事务属性被设置成“真”的商业过程表示整个过程被看作长运行事务，即，如果在过程的执行中产生异常，那么整个商业过程状态应被重置为开始执行商业过程之前的状态。如果未规定事务属性，则认为事务属性为“假”。所有任务继承其父过程的事务属性。

compensation：布尔值(真|假)-补偿属性被设置成“真”的商业过程表示在它需要被“退回重来”(rolled back)的情况下，它支持补偿。如果未规定补偿属性，则认为补偿属性为“假”。所有任务继承其父过程的补偿属性。

商业模型必定包含至少一个商业过程。商业过程由商业要素(过程、任务、工件库)，端口，链接和角色组成。端口规定商业过程的接口。角色规定谁有权执行商业过程代表的商业功能。链接连接包含在商业过程中的商业要素的端口，规定工件通过商业要素的流。链接具有下述属性：

fromport：ncname-对端口id的引用。端口的方向必须是“出”或“出-入”。

toport：ncname-对端口id的引用。端口的方向必须是“入”或“入-出”。

链接的语法结构是：

 <xs：complexType name＝″tLinks″>

           <xs：sequence>

                     <xs：element name＝″link″type＝″bops：tLink″maxOccurs＝″unbounded″/>

           </xs：sequence>

 </xs：complexType>

 <xs：complexType name＝″tLink″>

           <xs：attribute name＝″fromport″type＝″xs：NCName″use＝″required″/>

           <xs：attribute name＝″toport″type＝″xs：NCName″use＝″required″/>

 </xs：complexType>

商业过程的语法结构是：

 <xs：complexType name＝″tProcess″>

           <xs：complexContent>

                     <xs：extension base＝″bops：tBusinessElement″>

                                <xs：sequence>

                                          <xs：element name＝″links″type＝″bops：tLinks″minOccurs＝″0″/>

                                          <xs：element name＝″businessProcess″type＝″bops：tProcess″minOccurs＝″0″

 maxOccurs＝″unbounded″/>

                                          <xs：element name＝″businessTask″type＝″bops：tTask″minOccurs＝″0″

 maxOccurs＝″unbounded″/>

                                          <xs：element name＝″artifactRepository″type＝″bops：tArtifactRepository″

 minOccurs＝″0″maxOccurs＝″unbounded″/>

                                          <xs：element name＝″roles″type＝″bops：tRoles″minOccurs＝″0″/>

                                </xs：sequence>

                                <xs：attribute name＝″abstract″type＝″xs：boolea″use＝″optional″default＝″false″/>

                                <xs：attribute name＝″external″type＝″xs：boolean″use＝″optional″default＝″false″/>

                                <xs：attribute name＝″automatic″type＝″xs：boolean″use＝″optional″default＝″true″/>

                                <xs：attribute name＝″transactional″type＝″xs：boolean″use＝″optional″default＝″false″/>

                                <xs：attribute name＝″compensation″type＝″xs：boolean″use＝″optional″default＝″false″/>

                     </xs：extension>

           </xs：complexContent>

 </xs：complexType>

商业任务

商业任务是商业模型中不可还原的功能商业要素。商业任务作用于工件。任务具有下述属性：

name：ncname-规定商业任务的名称

automatic：布尔值(真|假)-自动属性被设置成“假”的商业任务表示该商业任务需要人的干预才能完成。所有任务继承其父过程的自动属性，并且如果需要，可超越该属性。如果未规定自动属性，则认为自动属性为“真”。

transactional：布尔值(真|假)-事务属性被设置成“真”的商业任务表示该任务是transactional，即，如果在任务的处理中产生异常，那么整个任务应退回重来。如果未规定事务属性，则认为事务属性为“假”。所有任务继承其父过程的事务属性。

compensation：布尔值(真|假)-补偿属性被设置成“真”的商业任务表示在发生异常的情况下，它支持补偿。如果未规定补偿属性，则认为补偿属性为“假”。所有任务继承其父过程的补偿属性。

商业任务由端口、任务环境(task context)、角色和触发器组成。商业任务应具有至少一个端口，而任务环境、角色和触发器是可选的。角色被用于识别谁有权执行该商业任务。

商业任务的语法结构是：

<xs：complexType name＝″tTask″>

         <xs：complexContent>

                   <xs：extension base＝″bops：tBusinessElement″>

                              <xs：sequence>

                                        <xs：element name＝″taskContext″type＝″bops：tTaskContext″minOccurs＝″0″/>

                                        <xs：element name＝″roles″type＝″bops：tRoles″minOccurs＝″0″/>

                                        <xs：element name＝″trigger″type＝″bops：tTrigger″minOccurs＝″0″/>

                              </xs：sequence>

                              <xs：attribute name＝″automatic″type＝″xs：boolean″use＝″optional″default＝″true″/>

                              <xs：attribute name＝″transactional″type＝″xs：boolean″use＝″optional″default＝″true″/>

                              <xs：attribute name＝″compensation″type＝″xs：boolean″use＝″optional″default＝″false″/>

                   </xs：extension>

         </xs：complexContent>

</xs：complcxType>

任务环境(context)

对于一项任务，可定义一个或多个“contextVariables”。任务环境定义任务专用信息。这种信息的可能用途是：

定义可在端口中的布尔表达式(表示成谓词)内使用的变量，其赋值确定某一端口是否有效。

把数值分配给范围变量。任务的资源分配取决于范围变量的正确分配。

任务环境的语法结构是：

<xs：complexType name＝″tTaskContext″>

          <xs：sequence>

                    <xs：element name＝″contextVariable″type＝″bops：tContextVariableAttribute″

maxOccurs＝″unbounded″/>

          </xs：sequence>

</xs：complexType>

<xs：complexType name＝″tContextVariableAttribute″>

          <xs：complexContent>

                    <xs：extension base＝″bops：tAttribute″>

                              <xs：sequence>

                                        <xs：element name＝″predicate″type＝″bops：tPredicate″minOccurs＝″0″/>

                              </xs：sequence>

                    </xs：extension>

          </xs：complexContent>

</xs：complexType>

触发器

任务是当被触发时，开始处理，并在某一合理时间之后保证停止的功能单元。根据下述情况触发任务：当通过“入”端口输入工件时；当库中存在工件时(这种情况下，回收机构通过“出-入”端口触发任务)；由计时器触发；或者由它本身触发。

触发器的语法结构是：

<xs：complexType name＝″tTrigger″>

          <xs：sequence>

                    <xs：element name＝″port″minOccurs＝″0″maxOccurs＝″unbounded″>

                              <xs：complexType>

                                       <xs：attribute name＝″name″type＝″xs：NCName″use＝″required″/>

                              </xs：complexType>

                    </xs：element>

          </xs：sequence>

          <xs：attribute name＝″timer″type＝″xs：boolean″use＝″optional″default＝″false″/>

          <xs：attribute name＝″self″type＝″xs：boolean″use＝″optional″default＝″false″/>

</xs：complexType>

商业工件库

工件库是商业工件的集结区。工件库的一个实例只能持有特定的一种工件。工件库被用于模仿与商业模型中的定购约束条件的时间相关性。工件库具有下述属性：name-ncname-规定工件库的名称。端口定义工件库的接口。由于工件库只能持有一种工件，因此具有端口必须引用相同的工件类型。有效的端口方向是“入”、“出”和“入-出”。

工件库的语法结构是：

<xs：complexType name＝″tArtifactRepository″>

          <xs：complexContcnt>

                    <xs：extension base＝″bops：tBusinessElement″/>

          </xs：complexContent>

</xs：complexType>

资源模型

资源模型描述执行商业任务的行动者，以及他们的能力。执行商业任务的一组能力定义一个角色。行动者被模拟成资源，资源有资格充任角色，如果他们能够执行对应的任务。如果资源可用，并且不受范围条件限制(参见下面)，则他们可被分配给供执行的这些任务。注意在模型的这一层次，没有区分“执行(performing)”和“帮助(assisting)”资源。这两者之间的界限模糊不清，通常参与任务实现的资源将被占用，消耗，或者被收费，而和他们是“执行”资源还是“帮助”资源无关。即使资源能够执行某一商业功能(即它有资格充任对应角色)，也存在关于其执行某一任务的能力的限制，取决于任务实例。例如，公司中的几个人可能是购买定单的“批准者”，但是根据定购产品的类型和价格，不是每个人都有资格批准每份定单。引入范围的概念，来模拟资源能力的这种取决于实例的限制性。

资源

资源可以是人力资源或自动化资源(机器或系统资源)。另外，外部资源类型可被引入超出过程所有者控制之外，过程所有者未知或者与过程所有者不相关的模型资源(不透明资源)中。虽然三种资源(人力、系统、外部)在模型的这一层次看起来相同，但是在扩展和改进中，例如对于过程模拟或IT实现来说，差异变得明显。例如，人力资源最终可映射成公司名录簿中的条目。系统资源将由应用、机器或自动化工具实现，并且需要连接器或适配器，以便参与自动化过程执行。在通过量模拟(资源的数量和可用性未知，或者无限)，成本计算(由第三方招致的他们的成本)和IT实现(他们的交互作用需要B2B网关)方面，外部资源不同于其它两类资源。

资源用成本和可用性表征，应被看作具有区别身份(例如会计Bill Smith，SAP System 4224，航线预定服务www.flyright.com)的“确实”过程行动者。资源不会与角色混淆，角色只指示能力(例如，制造专家，旅行代理，导购(lead buyer)，开支帐批准者)。同一角色可由具有不同成本特性的资源扮演：例如，根据谁批准开支帐，执行该任务，每小时的成本会显著变化。如同下面更详细说明的那样。

作为一个示例，人力资源可以是会计部门的某一雇员，或者一组四个IT专家。系统资源的一个例子是SAP R/3系统。外部资源的一个例子是航线预定服务。

 <？xml version＝″1.0″encoding＝″UTF-8″？>

 <resourceModel>

          <resources>

                    <humanResource name＝″Accounting Clek 01″/>

                    <humanResource name＝″Accounting Clerk 02″/>

                    <systemResource name＝″SAP System 4224-A″/>

                    <extemalResource name＝″www.flyright.com″/>

         </resources>

 </resourceModel>

资源可被聚合。人力资源、系统资源或外部资源的聚合定义同一类型的一种新(复合)资源。类型不同的资源的聚合产生一种类型不明(un-typed)的资源。组合类型不明的资源和任意资源将再次产生一种类型不明的资源。例如，人力资源的聚合可被看作“团队”或“工作组”。当经常组合使用人力资源和系统资源时，定义系统资源的聚合，以及人力资源和系统资源的混合体(mixed bag)是有益的。例如，记帐过程需要由会计部门的成员和公司结算系统组成的资源；营救行动需要直升机、飞行员和医师。

此外，资源聚合可被嵌套，允许三种基本聚合类型：袋子(bag)(无序集合)；序列(有序集合)；和选择权(替换物)。如果没有指定聚合类型，则默认为袋子。当分配复合资源时，袋子的分配将把它包含的所有资源连接到该任务。选择权的分配指示将分配该集合中的资源之一；其选择受可用性、范围或其它运行时约束条件，但是在资源模型中没有指示挑选某一特定资源的顺序或偏爱。分配序列的语义学和分配选择权(将挑选一个资源)的语义学类似，但是，序列预先定义产生该选择中的某一偏爱或优先权。资源袋的一个例子是工作组；序列的一个例子是依据成本或速度排序的货运服务清单；选择权的一个例子是公司的一组司机。

<resourceModel>

         <resources>

                  <humanResource name＝″The Hauling Squad″aggregationType＝″bag″>

                         <！--sameas previous example，but aggregation type made explicit-->

                         <humanResource name″Al″/>

                         <humanResource name＝″Bob″/>

                         <humanResource name＝″Chuck″/>

                         <humanResource name＝″Dan″/>

                  </humanResource>

                  <resource name＝″Shipping Service″aggregationType＝″sequence″>

                            <resource name＝″The Overnight Express″/>

                            <resource name＝″The Courier Service″/>

                            <resource name＝″The Postal Service″/>

                  </resource>

                  <humanResource name＝″Limousine Driver″aggregationType＝″choice″>

                            <humanResource name＝″A.Abrams″/>

                            <humanResource name＝″B.Baker″/>

                            <humanResource name＝″C.Chung″/>

                  </humanResource>

         </resources>

</resourceModel>

最后，资源可被组织所有，组织可以是内部组织(例如部，部门)或者是企业外部的组织(例如企业合作人，外部服务提供者)。但是，模拟这些组织，他们的分层结构，以及他们的资源所有权在核心模型的范围之外。可在例如用于过程模拟的模型扩展中增加这样的能力。

角色

通过向资源分配角色，描述资源的功能能力，角色被定义成执行商业任务的能力的聚合。在商业过程的IT实现中，角色被频繁用于表示执行商业功能的授权或许可。在基于BOpS的企业安全模型中，可按照这种方式延伸这里提出的角色概念。对资源的角色的分配可被划分范围(scoped)，这种情况下，资源的扮演角色的能力未关于所有任务实例得到普遍准许，相反取决于手边的任务。例如，汽车制造商定义采购代理商的公司导购。导购的工作是确保生产资料的购买合同符合公司的采购策略。在公司采购过程中，该角色会聚合“批准空白定单”，“改变供应商评级”和“设置供应商份额限制”的能力。但是，具有导购角色的雇员实际是否执行这些任务取决于购买的材料的类型(其所谓的日用品类型)以及供应商的地理位置。从而，依据供应商位置和日用品类型，划分导购角色的范围。这种划分范围的导购角色的例子是：“从美国供应商购买的轮胎的导购”，“从德国供应商购买的任意类别的材料的导购”或者“减震器的全球导购”。

 <resourceModel>

          <！--Declaring the lead buyer role-->

          <roles>

                    <role name＝″lead buyer″/>

          </roles>

          <！--Dcclaring a Lead Buyer，and down-scoping her lead buyer role-->

          <resurces>

                  <resource name＝″Patricia Goldman″>

                           <roles>

                                     <role name＝″lead buyer″>

                                              <scope name＝″commodity type″value＝″tires″/>

                                              <scope name＝″supplier location″value＝″United States″/>

                                     </role>

                           </roles>

                  </resource>

          </resources>

 </resourceModel>

在BOpS中，范围被模拟成分配给资源的角色的名值对。他们下划分(“down-scope”)资源的角色。范围名称定义范围的领域(例子是：日用品类型，供应商位置，销售区域，客户状态)，范围值定义该领域内，范围的限制(例如，日用品类型＝64，供应商位置＝德国，销售区域＝EMEA，客户状态＝高级，...)。下划分分配给资源的角色-称为资源限定-隐含要求关于要求这种范围受限角色的每项任务定义“划分(scoping)算法”：它必须把任务的每个实例映射到关于它所需角色定义的不同范围领域中。

在上面的例子中，汽车制造商的采购过程包括将由导购执行的合同批准任务。该任务具有相关的划分算法，该算法确定每个合同的适用的日用品类型和供应商位置。这将涉及分析合同，并查寻定购的生产资料的每个册列项目的日用品类型。它还涉及在供应商数据库中查寻供应商的地理位置。

如果从相同领域分配数个范围，则作为结果的范围是他们的联合。在依据领域形成范围的联合之后，总的范围被定义成跨越领域的笛卡尔产物。从而，例如，其范围被定义成(销售区域＝德国，销售区域＝奥地利，销售区域＝瑞士)的销售代理负责这三个讲德语的国家(三个范围的联合)。其范围被定义成(日用品类型＝灯泡，日用品类型＝刮片，供应商位置＝德克萨斯州，供应商位置＝亚利桑那州，供应商位置＝新墨西哥州)的导购负责从位于这三个州的供应商购买灯泡和刮片(联合的笛卡尔产物)。

 <resoureeModel>

           <roles>

                     <role name＝″sales agent″/>

                     <role name＝″lead buyer″/>

           </roles>

           <resources>

                     <resource name＝″Sales Agent Germany and Alpine Countries″>

                              <roles>

                                       <role name＝″sales agent″>

                                               <scope name＝″sales region″value＝″Germany″>

                                               <scope name＝″sales region″value＝″Austria″/>

                                               <scope name＝″sales region″vulue＝″Switzerland″/>

                                       </role>

                              </roles>

                     </resource>

                     <resource name＝″Lead Buyer 007″>

                              <roles>

                                       <role name＝″lead buyer″>

                                               <scope name＝″commodity type″value＝″light bulbs″/>

                                               <scope name＝″commodity type″ value＝″wiper blades″/>

                                               <scope name＝″supplier location″value＝″Texas″/>

                                               <scope name＝″supplier location″value＝″Arizona″/>

                                               <scope name＝″supplier location″value＝″New Mcxico″/>

                                       </role>

                              </roles>

                     </resource>

           </resources>

 </resourceModel>

国家的各州)，公司单位(公司组内各个部门内的各部)，或者产品的类别。把范围定义成这种结构中的一个节点等同于将其定义成一组全部从属叶子。从而，例如电子设备制造商定义销售主管角色，从而销售主管负责某一地理区域。分层构成公司的销售区域，地理区域(北美，拉美，EMEA，亚太)位于顶层，单个国家位于下一层，国家内的州或省位于最下层。

为了用文件证明范围领域的分层结构，或者为了列举所有可能的范围值，可把一组许可的范围值宣称为角色定义的一部分。如果存在这样的“范围”声明，则资源资格的范围限制必定是这样声明的范围的子集。例如，航空公司定义客户服务代表角色，其范围由客户状态限定。客户服务代表的角色定义列举银、金和白金作为客户状态的三种可能范围值。从而，宣称客户状态＝None或客户状态＝All的客户服务代表会是一个错误。如果在客户服务代表角色下没有宣称任何范围值，则关于客户状态的任何值应是许可的。在下面的XML例子中还表示了上面介绍的，依据地理区域划分范围的销售主管角色。角色宣称包括公司的销售区域的分层结构。

约束模型

约束模型描述对于语义上有效的BOpS模型，必须被满足的约束条件。它反映模型的操作语义学。约束有两种类型：1)元数据约束，它是需要高于模式约束条件规定的语义约束条件。这些是模式层约束条件(但是不能由模式指定)，通常与所有实例文档有关；2)模型约束，它是实例文档特有的语义约束条件。这些约束条件反映需要被评估，以便使模型有效的商业规则/逻辑。

虽然关于本发明的例证实施例，具体表示和说明了本发明，不过对本领域的技术人员来说，在不脱离本发明的精神和范围的情况下，可做出形式和细节方面的前述及其它变化，本发明的精神和范围只由附加的权利要求限定。

Claims (25)

1、一种产生并管理商业过程集成解决方案的系统，包括：

根据实体的定义的商业目的和目标，对商业策略建模的装置，所述商业策略包括代表商业度量和主动性的要素；

用包括过程任务、工件流和工件库的商业过程要素，对所述实体的商业操作建模的装置，所述商业过程要素包含关键性能指标；和

用操作模型的工件和过程要素映射策略模型的要素的数据结构装置，

测量商业性能并比较性能和所述关键性能指标的装置，其中由于过程度量和比较的结果，在解决方案开发周期内，可持续改进所述商业策略和操作模型过程要素。

2、按照权利要求1所述的系统，还包括把操作模型要素转换成独立于平台的信息技术(IT)可执行解决方案模型的装置，所述可执行的解决方案模型包括商业解决方案工件。

3、按照权利要求2所述的系统，其中解决方案工件包括代表商业文档或材料、合同或工作产物的商业对象。

4、按照权利要求2所述的系统，其中解决方案工件包括捕捉和状态相关的行为的自适应商业对象。

5、按照权利要求2所述的系统，其中解决方案工件包括代表可中断的过程流的宏流，和代表不可中断的过程流的微流。

6、按照权利要求2所述的系统，其中解决方案工件包括转换数据，并与应用软件接口的应用适配器。

7、按照权利要求2所述的系统，其中解决方案工件包括转换数据，并与外部商业系统接口的企业-企业连接器。

8、按照权利要求2所述的系统，其中解决方案工件包括使用户能够与解决方案相互作用的入口工件。

9、按照权利要求2所述的系统，还包括按照使所述解决方案工件可绑定或部署到一个或多个具体的运行时平台的方式，定义一个或多个所述IT解决方案工件的细节的装置。

10、按照权利要求2所述的系统，其中所述变换装置把所述关键性能指标变换成IT可执行解决方案模型中的IT探测器，所述探测器实时监视和报告由在操作模型中定义的所述关键性能指标测量的商业过程性能。

11、按照权利要求1所述的系统，还包括推荐或实现对商业过程的改变，以便在所述商业测量装置看来改进其性能的装置。

12、按照权利要求1所述的系统，其中所述测量和比较商业性能的装置包括至少在策略、操作、执行和实现模型之一中实现模拟模型的模拟装置。

13、按照权利要求1所述的系统，其中对所述实体的商业操作建模的所述装置包括实现正规表现所述商业操作的商业级建模语言。

14、按照权利要求1所述的系统，其中正规表现所述商业操作的所述商业级建模语言按照某一模式对商业操作建模。

15、按照权利要求14所述的系统，其中所述模式代表包括与所述商业实体的操作观点有关的工件和商业事件的信息模型。

16、按照权利要求1所述的系统，其中所述模式表示包括过程、任务、工件库和他们的互连的商业功能。

17、按照权利要求1所述的系统，其中所述模式表示包括角色和资源组的资源。

18、一种产生和管理商业过程集成解决方案的方法，包括：

a)根据实体的定义的商业目的和目标，对商业策略建模，所述商业策略包括表现商业度量和主动性的要素；

b)用包括过程任务、工件流和工件库的商业过程要素，和包括合并关键性能指标的商业承诺要素，对所述实体的商业操作建模；

c)用操作模型的工件和过程要素映射策略模型的要素；和

d)测量商业性能并比较性能度量和所述关键性能指标，其中由于过程度量和比较的结果，在解决方案开发周期内，可持续改进所述商业策略和操作模型过程要素。

19、按照权利要求18所述的方法，还包括把操作模型要素转换成独立于平台的信息技术(IT)解决方案模型的步骤，所述解决方案模型包括商业解决方案工件。

20、按照权利要求19所述的方法，其中解决方案工件包括从下述组中选出的一个或多个：商业对象、自适应商业对象、宏流、微流、应用适配器、企业-企业连接器和入口工件。

21、按照权利要求19所述的方法，还包括定义一个或多个所述IT解决方案工件的细节，把所述解决方案工件绑定或部署到一个或多个具体的运行时平台的步骤。

22、按照权利要求21所述的方法，还包括下述步骤：把所述关键性能指标变换成IT可执行解决方案模型中的IT探测器，所述探测器能够实现由定义的所述关键性能指标测量的商业过程性能的实时监视和报告。

23、按照权利要求22所述的方法，还包括推荐或实现对商业过程的改变，以便从所述监视看来改进其性能的步骤。

24、按照权利要求19所述的方法，还包括实现正规表现所述商业操作的商业级建模语言，所述商业操作的所述表现根据某一模式对商业操作建模。

25、一种包含多个指令的计算机存储设备，所述多个指令实现产生并管理商业过程集成解决方案的方法，所述方法包括下述步骤：

a)根据实体的定义的商业目的和目标，对商业策略建模，所述商业策略包括表现商业度量和主动性的要素；

b)用包括过程任务、工件流和工件库的商业过程要素，和包括合并关键性能指标的商业承诺要素，对所述实体的商业操作建模；

c)用操作模型的工件和过程要素映射策略模型的要素；和

d)测量商业性能并比较性能度量和所述关键性能指标，其中由于过程度量和比较的结果，在解决方案开发周期内，可持续改进所述商业策略和操作模型过程要素。

Images