网址：http://www.elsevier.nl/locate/entcs/volume51.html13页面向企业间应用集成的形式化框架？Reiko Heckel1 Gregor Engels2部数学与计算机科学学院德国帕德博恩D-33095摘要当今软件开发的一个主要关注点是不同企业的应用程序的集成，例如，通过互联网。这就需要将重点从系统开发转向企业模型的集成和系统的发展。我们提出了一个概念框架的方法来解决这些问题，并讨论其形式化的图形变换的概念。关键词：企业间应用集成，图转换，业务建模，系统建模，演化1引言当今软件工程的主要挑战之一是通过互联网集成应用程序。例如，电子商务或电子商务应用程序将不同企业的服务结合起来，产生一个集成产品。因此，不同的数据格式，计算平台和管理域之间的边界必须被桥接，因为通常，应用程序是在不同的权限下使用不同的过程模型，方法和工具开发的。因此，一个主要的问题是实现不同（子）系统之间的一致性。问题发生在不同的层面，如与业务对象（如账单、会计和客户）以及业务流程（如账单支付或开户）相关的应用程序逻辑层？ 研究部分得到ESPRIT工作组APPLIGRAPH和TMR网络GETGRATS的支持。1 电子邮件地址：reiko@upb.de2 电子邮件地址：engels@upb.dec 2002年由Elsevier Science B出版。V.CC BY-NC-ND许可下的开放访问。2与应用程序组件（如银行系统的电子银行服务器和客户桌面计算机上的相应客户端）有关的软件体系结构级别，以及组件通信所使用的应用程序协议与系统组件（如数据库、Web服务器等）相关的系统架构级别，它们在实际机器上的交互和部署在所有级别上实现一致性的主要方法之一是从一个模型开始，该模型表示对现实世界的实现细节和不相关方面的抽象。如将在下面更详细地解释的，这样的模型可以用于表示当前情况（在整合之前）或之后的预期情况。 在模型的帮助下，不同企业的视图之间的许多不一致和冲突可以通过提高抽象层次和在处理实现问题之前集中在概念问题上来解决。视图的（不）一致性一直是基于视图的开发方法的问题，如[9，14]。在这里，我们必须区分开发过程中的不一致性和运行系统的不同组件。而第一种不一致是系统开发的正常事实，必须接受和处理，例如，通过对冲突进行簿记直到它们被解决，运行系统中的不一致性会导致为避免和错误处理而不断进行的排序，因此应该避免。在本文中，我们感兴趣的是第二种一致性。特别是在应用逻辑层面，一致性问题不能单靠计算机科学家来解决，因为涉及到企业非常基本的概念和流程。因此，它需要领域专家，计算机科学家和用户之间的协商，从两个企业，以检测相应的概念之间的语义关系和冲突。为此，需要一种抽象的语言（这样它就不会强迫处理低级细节）、直观（以便非计算机科学家可以理解）和精确（以便允许检测不同企业的视图之间的不一致和错误面向对象的建模语言，如UML[18]满足了前两个要求，即，它们提供了一种高级、直观的符号来表达所有相关方面。然而，它们一般不允许精确的规范，除非采用特定的语义解释。此外，模型的含义取决于模型的抽象级别、范围和上下文，即，在整个发展过程中的作用。因此，企业间应用程序集成的建模方法（一般来说）需要一个正式的基础和一个明确的概念框架，以精确地确定模型可以扮演的不同角色以及这些角色之间的关系。3在本文中，这些问题将在需求规格说明（与应用程序逻辑有关）的层次上进行讨论，因为由于上述原因，在这里使用模型是最有效的。在下一节介绍概念框架之后，在第3节至第6节中，概述了不同的维度和由此产生的作用，并为可能的形式化提供了参考在第7节中，总结了开放的问题2企业间应用集成主流的基于UML的开发过程，如Uni ed Process[15]或Catalysis[6]，将开发的早期阶段结构化为以下活动：(i) 业务建模，即在不参考任何现有软件系统的情况下，(ii) 要求规范，即，说明待开发系统的预期特性，但不决定如何实现这里的简化假设（引用的方法都知道）是，任务包括从头开始开发一个系统，并且企业的整体运营（业务模型）不会改变。实际上，从这两种描述中，可以推导出以下两个维度业务与系统模型，即我们是对与企业操作相关的所有概念和过程进行建模，还是将自己限制在软件系统模型之前与之后，即，模型描述的是当前的情况（在当前的开发之前）还是（预期的）情况使用这个术语，上面的第1项涉及业务模型/之前，而第2项涉及系统模型/之后。当然，如果任务包括集成不同的应用程序，那么在当前开发任务之前这些应用程序的存在是一个高度相关的问题，而业务本身的发展可能重要，也可能不重要。一个主要的额外方面，特别是对一体化问题，是局部对全局，即，模型的范围可能与一个或另一个企业的视图、这些视图的交集或集成视图有关。在此基础上，企业间应用程序集成的过程（一般来说[24]）可以被视为一种在三维（或多维）空间中导航的方式，以预先定义的顺序访问某些点。更准确地说，每个点都是模型在开发中的潜在作用。4B122、、、、、0、，，s，z010Bjvs. 垂直地示出了系统模型Sj箭头Bj-Sj应描述0从X 0开始用虚线表示 到X 1。国际化顶点Xi;Xi;Xi和Xi。这里，Xi和Xi代表两个本地企业0......_，z0 0，，，，，，s，，，，，，，，，，，，，，，，，，、、 ，zB0，，B0，，，zB1，zB1、、、、、、、、、、、、、、、、、、、、、、- 不，不，、、、、、、、、、、、，，z，，s，、、、，zz，s，、、、、、、b0的、、、、、、、、、、、、、、、、、、、、、、、B1、、、、、、、、、、、、、、、、、、、，J，，，，，S0， zS1，、、、、、、、、 、、、、......、、............ ，，，，，、、J，s，vJz，，，J，s，，，vJzS0，，S0，zS1，zS11， 2 1，2，，，，z，，JS，z，JS1图1.一、企业间应用集成框架过程，并且对于每个特定的过程，必须定义模型实际上必须扮演的角色以及应该完成的顺序。独立于实际开发过程考虑这种多维概念框架的好处是，这些角色之间可能存在预定关系，从而导致不同模型之间的一致性条件。(For例如，一个系统模型应该总是相应的业务模型的简化（如果我们x所有其他维度，（1）独立于生产的顺序框架的不同维度和角色以及它们之间的关系在图中可视化1如下。商业模式维度我我我系统模型是相应业务的简化模型发展前后形势的转换我我不同企业模式的差异，用四个菱形来表示，0 1 2 1 2模型，Xi是两者的共同观点，Xi是相应的综合模型基于这些概念，可以描述一个典型的企业间应用集成的开发过程。为了简单起见（为了预先解释后面介绍的例子），我们假设任务包括两个本地软件系统的集成，同时保留实际的业务流程。因此，演化只会发生在系统模型的层面上。然而，总的来说，如图1所示，我们的框架在两个层次上都适应进化。(i) 逆向工程：业务与系统模型-S1和2 -S2 本文在分析我国实际情况的基础上，B1100B05100系统模型S0 S0 在参考模型S0上集成 到并给出了它们与模型S0;S0的演化关系。再说一遍，2B1=B0约化关系 B1=B0 必须被验证。两家企业。(ii) 商业模式的整合：两种本地商业模式B0 和0 是集成的。这需要建立一个ReferencemodelB0 惠春表示两个局部视图的共享概念和操作，而一个integratedmodelB0 基于公共参考模型。(iii) 系统模型的集成：与业务模型类似，1 2 0S0。必须验证S 实际上是B0的减少，即，的关系B0-S0 必须建立。(iv) 集成系统模型的演化：在本活动中，集成系统模型S0，它在实际开发之前代表两个系统的全局视图，应转换为在实际开发之后集成 系 统 的需 求 规 范 S1 。 由 于 业 务 模 型 是 预 先 确 定 的 （ 即 ，B0=B1），证明了新的系统模型S1 仍 然是业务模型的简化。 （实际上，所有这些都是系统范围的扩展，支持以前手动处理的概念和任务。(v) 局部演化的投影和分析：集成系统的全局模型必须投影到两个局部视图上，了解所需的l o calc变化。因此，模型S1;S1 是1 21 21 1 2 2在下面的四个部分中，我们将给出一些不同模型及其关系的小例子，并参考可能的形式化。然而，在我们的框架的三个维度之前，应该解释每个模型的内部结构，这可以被视为第四个正交维度。3静态、动态和功能方面所有模型由三个子模型组成，分别代表静态、动态和功能方面。使用UML符号，静态方面由类图给出。由于我们处于需求规范的级别，类没有与之关联的方法签名，即，类图仅指定类、关联、属性和约束[15，6]。动态模型通过由动作状态（椭圆形顶点）组成的活动图指定业务流程（系统内部或外部），这些动作状态通过对控制流（实线弧）和/或对象（虚线弧）进行建模的转换连接。此外，还提供了选择（菱形）和分叉/连接（水平条）的符号[18]。功能方面通过被解释为转换规则的实例图（对）来描述前/后条件和动作效果[6]。图2中给出的模型举例说明了这三个方面。 它代表B6银行账户账号blz到店客户端问题支付票据产品总奖金地位包含交出比尔b：账单总额= x状态=已发送b：账单总额= x状态=已关闭110具有合法实体名称输入帐单交出比尔两周后检查BankAccount一周记录付款[转收到][no转移收到]发送警告：客户：客户静态模型动态模型功能模型问题支付图二.商店的商业模式（角色B0）一个商店的商业模式，它将在我们的框架工作中扮演B 0的角色。注意，这样的模型不是经典意义上的面向对象，因为没有动作与对象的关联。在引用的OO过程模型中，这种关联发生在分析阶段的后期。形式上，静态和功能子模型共同形成了一个基于属性图的类型化图转换系统[5]。活动图可以被看作是（高级）Petri网的符号变体（参见，例如，[10]）。在适当的应用条件下，属性图变换可以编码Petri网|因此，这三个方面的正式整合应该是直截了当的。4模型集成当集成两个单独开发的模型时，我们面临两个不同的问题：范围的变化和表示的不兼容性范围的变化意味着模型所描述的世界的片段在从局部到更全局的观点时被放大或缩小因此，当集成两个视图时，我们首先必须理解它们作用域的交集，然后才能真正合并它们。这就是在我们的概念框架中考虑参考模型Xi的动机。一旦这个模型建立起来，并与两个当地的：商店：商店7到：账户余额= y：订单数量= a从事涉及：账户：账户12静态模型功能模型支付关注使用支付关注使用执行自从关切交出比尔关切执行问题问题支付：Bill状态=已关闭：订单数量= x：Bill状态=已关闭：订单数量= x：办事员：账户余额= x：客户：商店：客户：商店：账户余额= y+a：办事员：账户余额= x-a图3.第三章。商店和银行的集成业务模型（角色B 0的静态和功能方面）视图Xi和Xi，交点固定，可以进行积分(more或更少）自动地[8]。建立参考模型时，我们面临着表示不兼容的问题：独立企业的模型可能对相似的概念使用不同的名称，或者对语义不同的概念使用相同的名称。更戏剧性的是，表示可能是不可比较的（例如，因为相同的概念使用类和关联以两种不同的方式建模）。这些冲突必须在参考模型中通过选择一种或另一种表示或提出一种更通用的表示来解决。此外，必须指定从局部表示到参考模型中相应表示的映射。一个集成的业务模型，扮演B0角色 图3和图4所示为我们的框架工作。它代表了图2中的模型与银行业务模型（本文中未给出）的集成。注意不同的表示，例如，银行账户在本地商店视图中建模为单个对象，而在全局模型中由两个不同（但相关）的对象表示类似的情况也发生在汇票上。范围从局部到全局视图的扩展是示例性的，例如，通过像Clerk这样的附加概念，它们在局部视图中没有对应关系合法实体名称使用账号平衡从秩序量执行到店员名称提供关切店客户银行blz法案地位产品包含奖品问题支付：办事员完整的订单：客户：Bill状态=已发送：订单：客户：Bill状态=已发送：订单：办事员8店银行输入帐单：Ord输入订单交出比尔完整的订单[我没有用。[amountavail.]2周后检查银行帐户：通知客户从事涉及...病动态模型见图4。店银一体化商业模式（角色B0的动态方面）在数据库设计领域中，已经深入研究了将不同视图的有冲突的静态模型集成为一个单一的有冲突的整体模型[2，22，4]。为了在实例级别上描述两个视图之间的映射，最有前途的方法似乎是三重图语法[21]，它允许根据对应规则生成双向在功能视图中，我们注意到两个额外的规则，一个来自银行模型，另一个（完整的订单）提供了两个业务之间的链接，如图2中的动态子模型所示四、特别地，两个视图的功能子模型的交互已经在关于基于开放图变换系统的视图和视图集成的一系列论文中被深入研究（参见，例如，[8，13，11]）。假设活动图和Petri网之间的语义类比，动态子模型的集成是[1]的主题。5业务与系统建模业务模型指定了企业的所有（相关）概念、过程和操作，而系统模型只指定了软件系统实际支持的那些概念、过程和操作。(In此外，系统模型通常包括在用例图中捕获的系统用户的规范用例图还可以帮助区分不同的（子）系统，并将主要的用户操作（用例）与执行它们的用户和在本文中，我们忽略了用户模型，并将同一企业内的所有本地子系统视为一个集成系统。91静态模型动态模型输入帐单printBill[转账收到]记录付款功能模型b：总胆红素= x状态=已关闭：Clientb：总胆红素= x状态=已发送支付图五.钱箱系统的模型（角色S 0）从业务模型到系统模型的缩减也是模型范围的一种变化，形式上描述为视图关系[8]。请注意，我们允许重命名，但我们不考虑重新命名，即，详细程度不应改变。图5示出了作为图2中的商店业务模型的简化的钱箱的系统模型。注意，Shop类已经从静态模型中删除了（也就是说，钱箱不知道不同的商店）。从动态模型中，取消了两个动作（检查帐户和警告客户），因为它们是由销售人员执行的，而没有钱箱的帮助。将票据交付操作改为打印票据。在功能模型中，没有被省略的规则（因为相应的动作不再存在）必须被简化为相应类图中的类的实例。例如，从规则打印账单中，商店对象已被删除。6模型演化模型级别的演化预测了对实际系统或业务的更改。如果，如在这里给出的示例中那样，业务模型被保留，则它为更改之前和之后的系统模型提供了公共上下文，即，这两种系统模型都是同一业务打印账单银行账户账号blz到账单总额地位客户端名称支付产品奖包含：Client10：帐户：BiII状态=已发送：订单钱箱EBillingSystem银行输入帐单：或printBill检查订单完整的订单[我没有用。[amountavail.][转账收到]记录付款：B通知客户从事涉及病der动态模型功能模型：办事员支付关注使用支付执行关注，使用见图6。集成系统模型的需求规范（角色S1的动态和功能方面）模型这表明了业务建模的相关性，因为在这种情况下，系统模型的演变主要包括在业务模型的过程和概念中选择应该支持的那些例如，在图6中，示出了演化之后的全局系统模型的动态和功能子模型，其作用为S1 的框架工作。活动图是集成业务模型（图4）中的活动图的简化，但事实上，行动完成订单现在与EBillingSystem相关联，即，一种允许客户在线处理账单和相应的银行转账的系统。相关的规则与图1中的规则四是书记员不再参与。一般来说，商业模式也会发展，例如，因为引入了新软件。在这种情况下，模型之间的关系之前和之后的演变可以表示为（可能部分）映射相关的相应概念。这样的映射可以以不同的方式获得通 过模型转换，即，应用（在所有子模型中）预先定义的进化规则。例如，在[20，3，19，16，7，12]中讨论了这个想法的形式化。作为声明性的实例（例如，基于逻辑的）目标模型的需求规范通过保持或反映重要语义属性的模型之间的某些类同态。完整的订单：帐户：Client：办事员：订单：Client：BiII状态=已发送11一般来说，应该区分模型的重构（即，在保持其语义内容的同时改进模型结构）以及概念的扩展或保留。7结论在本节中，我们希望指出框架中的开放语义问题，作为未来工作的计划。为了得到一个完全形式化的模型概念，有几件事需要更详细地解决，比如Petri网和活动图之间的关系（形式化动态方面），以及开放（高级）Petri网和开放（属性）图转换系统之间的关系（定义功能和动态方面之间的关系）。或多或少开放的问题是，如何扩展视图集成方法与映射同一概念的不同表示的技术。我们已经提到了三重图文法，但它们还没有被纳入[8]中讨论的视图概念中。另一种更通用的方法可以基于主动约束[23]。同样，缺乏包括商业模式在内的一般性进化概念，尽管所引用的基于规则的方法提供了一个很好的起点。引用[1] P. Baldan，A. Corradini，H. Ehrig和R.海克尔使用开放网络的反应系统的组成建模。 In Proc. Consur 2001，Aarhus，August2001.出现。[2] C. Batini，M. Lenzerini和S.航海家数据库模式集成方法的比较分析。ACM计算调查，18（6）：323{364，1986.[3] I. Cla en和M.洛面向对象模型中的模式演化：一种图形转换方法。在Proc. Workshop on Formal Methods at the ISCE'95，Seattle（U.S.A.），1995年。[4] S. 康 莱 德F其 他 数 据 库 系 统 ： KonzeptederDatenintegration. Springer-Verlag，1997.[5] A.科拉迪尼 Montanari 和F. 罗西图形处 理。 Fundamenta Informaticae ， 26（3，4）：241{266，1996.[6] D. D'Souza和A.所意欲UML的组件和框架：催化方法。Addison-Wesley，1998年。[7] G. Engels和R.海克尔图转换作为系统建模和模型演化的统一形式框架。载于Proc. ICALP 2000，LNCS，日内瓦，瑞士，2000年7月史普林格出版社http：//www.uni-paderborn.de/cs/ag-engels/Papers/2000/EngelsIcalp00.pdf。12[8] G.恩格斯河Heckel，G. Taentzer和H.埃里希一种基于参考模型和视图的系统规格说明方法。Int. Journal of Software and Knowledge Engeneering，7（4）：457{477，1997. 预印本网址：//tfs.cs.tu-berlin.de网站。[9] A. Finkelstein，J. Kramer，B. Nuseibeh，M. Goedicke和L.芬克尔斯坦Viewpoints：在系统开发中集成多个视角的框架。软件工程与知识工程，2（1）：31{58， 1992年3月。[10] T.盖尔克大学Goltz和H.维海姆用Petri网对UML动态模型进行语义分析。在大肠Schnieder，编辑，第六届复杂自动化系统开发与运行研讨会论文集，1999。[11] R.海克尔开放图转换系统：并发和反应系统组合建模。博士论文，柏林工业大学， 1998年。http://www.uni-paderborn.de/cs/ag-engels/Papers/1998/HeckelPhD98.pdf。[12] R. Heckel和G.恩格斯。图转换作为动态建模和模型演化的Meta语言。 于T.男人和M。 Wermelinger，编辑，软件演化形式基础国际特别会议，葡萄牙里斯本，2001年3月。与欧洲软件维护和再工程会议（CSMR 2001）同地举行。[13] R. Heckel，G. Engels，H. Ehrig和G.坦策基于开放图变换系统的系统建模的视 图 基 方 法 。 In G. 恩 格 斯 ， H. J. Kreowski 和 G. Rozenberg ， editors ，Handbook of Graph Grammars and Computing by Graph Transformation，Volume2：Applications，Languages，and Tools. World Scienti c，1999.[14] ISO/IEC 10746 ITU-T X.901 X.904。开放分布式处理参考模型，1994年。[15] I. Jacobson，G. Booch和J. Rumbaugh。统一的软件开发过程。艾迪森·韦斯利1999年[16] M.洛进化模式博士后论文，柏林工业大学。Tech. 报告98-4，部门 的Comp.Sci，1997年。[17] M. L哦，M。Kor，和A. 瓦格纳属性图变换的一个代数框架。在核磁共振室。睡吧，M.Plasmeijer和M.C.van Eekelen，编辑，术语图重写：理论与实践，第14章，第185页。John Wiley Sons Ltd，1993年。[18] 对象管理组。 UML规范版本1.3，1999年6月。网址：//www.omg.org网站。[19] J. Padberg ， H. Ehrig 和 L. 里 贝 罗 代 数 高 级 网 变 换 系 统 。 MSCS ， 2 ：217{256，1995.13[20] F.帕里西·普雷西切。图文法的转换。第五届国际图形语法及其在计算机科学中的应用研讨会，Williamsburg '94，LNCS 1073，1996。[21] A. 史昌湖RR. 用三重图文法设计图翻译器。 在Tinhofer，编辑，Proc.WG'94 Int. Workshop on Graph-Theoretic Concepts in Computer Science，编号903 in LNCS，第151页{163. Springer-Verlag，1994.[22] S. Spaccapietra和C.家长视图集成：解决结构冲突的一个步骤。IEEE软件和数据工程学报，6（2）：258{274，1994.[23] A.J.Wi nter和A. 史昌湖RR.程序化图形重写系统的模块和可更新图形视图。技术报告97-3，亚琛工业大学，FG Informatik，1997年10月[24] A. Zamperoni和G.恩格斯。使用 图重写系统的软件工程方面的形式化集成--一个典型的实验？！ InM. Nagl和A. 史昌湖rr，编辑，Proc.Applications ofGraph Transformations With Industrial Relevance （ AGTIVE ） ， Kerkrade （ 荷兰），1999年9月1日，LNCS的第1779卷。Springer-Verlag，2000.
我的内容管理
展开
