三重图文法的工具集成

理论计算机科学电子笔记148（2006）113-150www.elsevier.com/locate/entcs三重图文法的工具集成- 一项调查AlexanderKöonigs，Andy Schürr1达姆施塔特工业实时系统实验室D-64283 Darmstadt，德国摘要目前，各工业部门（汽车、电信等）的典型软件和系统工程项目。 涉及数百名开发人员使用相当多的不同工具。 因此，项目的数据作为一个整体分布在这些工具上。 因此，有必要使不同工具数据库之间的关系可见，并保持它们彼此一致。 这仍然是一场噩梦，因为缺乏特定领域的可适应工具，数据集成解决方案，支持可追溯性链接的维护、半自动一致性检查以及更新传播。目前使用的解决方案通常是手工编码的工具对之间的单向转换。 在本文中，我们提出了一种基于规则的方法，允许声明性地指定数据集成规则。 它的基础是形式主义三重图语法的一部分，并使用有向图来表示符合MOF的（Meta）模型。 作为 结果，我们给出了一个答案OMG的要求，建议为一个符合MOF的“查询，意见，模型驱动应用程序开发（MDA）领域中的一种“模型驱动和转换”（QVT）方法。关键词：工具集成，模型集成，三重图文法，QVT，MDA1引言如今，复杂系统工程项目的开发过程通常涉及数百名地理上分布的开发人员。常用的流程模型（例如瀑布模型，Rational统一过程，V模型）将这些过程细分为不同的相互关联的开发阶段或工作流程。开发人员被分配到一个特定的阶段或工作流程;他们通常1电子邮件：{koenigs|schuerr}@ es.tu-darmstadt.de1571-0661 © 2006 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2005.12.015A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113114ATA功能测试CTE XL系统要求门产品DWindchill软件功能Matlab/Together图1.一、 一个特定软件系统工程过程中的不同工具使用专门支持特定任务和操作特定类型文档的CASE工具。图1描述了这种类型的一个小示例，即用于各种汽车系统工程项目的工具链的子集。系统的功能性和非功能性需求存储在基于数据的需求工具Doors中。这些需求要求在Matlab和Together中指定和建模的软件功能。系统的硬件设计是用硬件描述语言完成的。Catia用于计算机辅助设计、工程和制造。使用CTE XL规定功能测试。最后，利用Windchill对整个项目的数据进行管理。因此，项目的开发文档通常作为一个整体分布在不同工具的专有数据存储库当开发人员在这些同时发展的独立数据存储库上工作时，他们面临着在越来越不一致的文档集上工作的风险因此，迫切需要工具支持，以保持独立工具存储库的数据处于一致状态，有时甚至需要考虑特定于域的完整性这种工具/数据集成支持已经成为“热门研究课题”大约15年了，但仍然没有得到满意的解决。过去引入的一种流行的集成方法是基于所谓的消息服务器，如HP-Soft-Bench [16]或ToolTalk [15]等商业产品中所使用的。这些系统具有基本的面向控制和面向事件的[4]集成机制，但不允许指定文档之间的一种更面向数据的方法是基于所谓的兼容性映射[17]。这种方法在一个通用的数据库上工作，但对功能文档依赖的规范只提供了很差的支持。在同一时间引入的其他方法将整个项目数据库建模为属性语法树，并将一致性检查作为属性评估规则来实现。例如水星[21]HW-设计HDL作者ECU-外壳CATIAA. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113115o对属性值从一个文档传播到另一个文档提供了一些支持Gandalf[19]和Centaur[3]使用了更复杂的属性语法树概念，并支持任意嵌套的文档。所有这些方法的主要缺点是缺乏对一致性恢复数据更新的任何工具支持。为了克服标准属性语法的这种缺陷，引入了基于解决方案的属性耦合语法[18]它们使用一个语法树的属性评估规则属性耦合文法以及目前提出的数据集成方法的一个严重缺点是它们是面向批处理的和单向的。它们将源文档转换为目标文档，但不是相反。TransformGen[46]是第一次尝试以双向方式看待源文档和目标文档TransformGen半自动生成的单向和面向批处理的转换工具，用于两个方向，使用相关字符串语法的单一规范作为输入。这种将不同的字符串/树语言的语法与图形语言联系起来的想法已经得到了推广，并为本文提出的集成方法奠定了基础。Pratt在这方面做了初步的工作，他在很多年前就引入了对文法的概念[38]最近，工具/数据集成问题已经被对象管理组（OMG）及其对符合MOF的“查询、视图和转换”标准（QVT）的请求提案重新处理，但尚未解决RFP首先要求使用OMGMOF是一种标准的建模语言规范，用于在本文中，我们给出了一个调查的工具/数据集成方法的基础上，MOF和所谓的三重图语法方面的QVT-RFP。三重图语法（TGG）是10年前作为独立的声明性模型集成形式主义而发明的[43]。正在进行的研究活动的主题是将TGG应用于OMG标准的世界[22]。本文的目的是使用OMG标准MOF的术语来总结基于TGG的工具集成方法的基本思想，并将此演示与先前发布的相当简单形式的TGG的正式定义因此，本文是[22]和[43]摘录的组合TGG已被用于将关系数据库系统迁移到面向对象的数据库系统[20]，用于IPSEN环境中的工具集成[25]，以及用于FUJABA项目中的图一致性管理[51]。出于演示的目的，我们将使用一个与实际汽车项目相关的运行示例该项目涉及发展A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113116带有雨量传感器的挡风玻璃雨刷。本文选择的工具集成场景涉及Telelogic的工具Doors [49]，用于以自然语言定义系统需求，以及Borland的工具Together[6]，用于统一建模语言（UML）2的 用 例 和 类 图 的 可 视 化 定 义 [35]。图2显示了保存在Doors和Together中的部分数据3图2a是车门的屏幕截图，显示了挡风玻璃刮水器系统要求的一个小切口。 首先介绍了一些枚举类型，它们在不同的地方使用，以区分我们系统的不同操作模式。此外，子部分的层次结构有助于将系统需求组织为所谓的功能的相关组和子组。每个特性描述都有一个采用用例驱动需求工程方法的结构除此之外，它们区分激活触发器、先决条件和后置条件、对所考虑的系统特征的或多或少的详细描述等等。图2b展示了一个用Together创建的用例图，它可视化了我们的需求。它以图形化的方式描述了系统功能（用例）和涉众（参与者）之间的关系，以及用例依赖形式的不同功能之间的交互此外，它表明我们已经满足了这样的决定，即特征组1.3.1擦拭及其子特征1.3.1.1垂臂开关擦拭和1.3.1.2擦拭用于洗涤之间的层次关系并不表示将复杂特征分解为相互作用的子特征，而是一种细化关系。垂臂开关刮水和刮水清洗是风挡刮水器的两种不同的工作模式，它们从普通的超模式刮水“继承”了因此，图2a中的功能层次结构被转换为图2b中的概括层次结构，而不是将其映射到包含用例图的包的层次结构这是一个很好的例子，在这种情况下，工具集成解决方案的用户必须在不同的选项中选择如何将一个工具创建的子模型转换为另一个工具的相关子模型。最后，图2c显示了一个类图，它代表了基于图2b的用例图和系统fea的第一个相当幼稚的系统设计2本文中提出的数据集成规则仅用于演示目的。 实践中使用的规则更为复杂，但没有系统地使使用我们的模型集成形式主义的所有可用功能。因此，它们不太适合解释我们的方法。3在工具的上下文中，我们使用文档和数据这两个术语。在Meta建模的上下文中，我们相应地讨论模型和对象. 最后，我们在图语法的上下文中使用术语图和节点A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113117DropArmSwitchWipingWipingForWashing下拉臂开关清洗和擦拭洗涤泵擦拭擦拭器a）、b）、摇臂开关泵c）、点火图二、示例需求、用例和类图文档擦拭擦拭器垂臂开关刮水擦拭洗涤点火<<延伸>><<包括>><<包括>>擦洗洗涤A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113118图2a的定义在这种情况下，我们决定为系统的任何（传感器/执行器）参与者引入一个接口包装器类，并以单独类的形式实现每个功能传感器将其数据发送到相应的特征类，而特征类计算并传播所需的数据以控制所有执行器。此外，将用例之间的泛化关系转换为类之间的泛化关系是相当明显的，而将扩展和包含依赖转换为类的聚合是否是最明显的解决方案是一个争论的问题相关的正在进行的研究活动的主题是提出一套更复杂的特定于领域的模型映射规则，以支持系统需求和体系结构的共同进化在第2章中，我们解释了[22]中我们引入元建模作为一个众所周知的技术来描述文档的结构。我们添加了三重图语法的概念，以便写下规则，这些规则以声明方式描述文档之间的对应关系，以便将它们集成。从这些声明性规则中，我们将在第3章中推导出操作性规则。这些操作规则可以应用于完成不同的集成任务。在第四章中，我们回顾了在[43]中提出的三重图文法的形式。我们在第5章继续介绍OMG在此基础上，介绍了相关的方法，并对它们进行了比较，同时也与我们的方法进行了比较。最后，第六章对全文进行了总结，并讨论了尚待解决的问题和未来的工作.2介绍我们的方法在本章中，我们将介绍我们的工具/数据集成方法，该方法允许声明性地指定一致性检查和恢复集成规则。我们首先介绍元建模作为一个众所周知的技术，指定的抽象语法和静态语义的数据保持在软件系统工程工具。此外，我们使用元建模来声明不同工具的数据存储库之间的对应链接类型。最后，我们介绍了三重图语法的思想，用于指定声明式数据集成规则。稍后我们将看到，这些三重图语法规则可以被自动地转换成操作模型转换规则的不同集合，这些操作模型转换规则然后负责检查元模型的一致性并在所有方向上在相关元模型之间传播变化A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）1131190..*容器0.. 1包图-name：String10..*用例-name：String11TRGsrc0..*0 ..*泛化图三. 符合MOF 2.0的UML用例图元模型2.1元建模元建模是一种众所周知的技术，用于定义软件系统工程工具中数据的抽象语法和静态语义[45]。我们使用MOF 2.0版[33]，这是OMG为此目的的标准语言规范。图3显示了一个符合MOF 2.0的UML用例图Meta模型的一部分，如Together中所定义的这个元模型不是用例图的“真实”UML元模型的一个裁剪此外，它（当然）不能表示UML工具的图元素，这些图元素经常（错误地）用于聚集逻辑上相关的建模元素，因此，在定义数据集成规则时不应该被忽略。图3的元模型指出，在To- gether中的UML用例图由作为包层次结构的叶子的图每个Diagram都有一系列的codeCase。此外，可通过泛化关系4将多个实例彼此关联。有了这样一个文档的元模型，我们就可以将文档中包含的数据表示为符合元模型的UML对象图。图4显示了UML用例图的UML对象图表示的一部分4扩展和包含关系以及参与者在下面的示例中没有使用，因此在这里省略。A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113120：案例name =“WipingForWashing”：案例名称=“DropArmSwitchWiping”：推广：推广：案例name =“Wiping”：图表：包装name =“清洗擦拭”我们的运行示例的文档（cf.图2b）. 因此，我们可以为存储在Doors中的需求文档见图4。 UML用例图的部分UML对象图表示我们的工具/数据集成方法的基本思想是在不同工具的数据存储库的元素之间创建和维护使用我们希望相互集成的工具的元模型，我们也可以为对应链接编写元模型该元模型将元素从一个工具的元模型映射到另一个工具的元模型的元素，反之亦然。图5描述了在挡风玻璃雨刷项目中声明对应链接所需的三个元模型。图5a显示了需求文档的元模型 图5c回顾了用例图的元模型。最后，图5b 使 用 这 两 种 工 具 的 元 模 型 来 声 明 所 需 的 对 应 链 接 类 型 。 从 包IntegrationSchema 中 定 义 的 要 集 成 的 元 模 型 中 导 入 的 类 在 包IntegrationSchema中以灰色呈现。在我们的方法中，我们要求要被集成的元模型被组织起来，如图6所示。每个工具的元模型定义在 一个单独的包，如果需要，它可以包含子包这些包中的每一个都可以包含任何符合MOF 2.0的描述工具数据结构的此外，我们还有第三个层次的包，标记为原型Integration。这些包包含所需通信链接的元模型。我们要求每个对应链接类型声明必须与图7中描述的相匹配。声明的链接类型可以有一个任意的名称，并且必须用原型Integration标记。这个构造型表明了这样一个事实，即当我们使用标准的UML 1.x CASE工具定义元模型时，我们当前（错误地）使用集成构造型的UML类来定义MOF2.0关联A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113121要求0..*0.. 1公司简介特征-name：String-name：String11srctrg0..*0 ..*依赖产品展示架构工具B<<进口>>架构工具A<<进口>><<集成>>集成架构c）、（a）（b）图五. 工具图六、我们方法中的元模型组织直接支持所有元建模概念的适当的MOF 2.0编辑器的实现几乎已经完成，作为UML CASE工具框架FUJABA的新插件[30]。将来它将用于Meta建模的目的，并提供更复杂的支持，用于在包中组织元模型、专门化关联等。任何（MOF）关联（如图7所示）都有两个端点。端点指向来自工具Meta模型的相应元素。每个端部可以携带多重性。通常，这些多重性指定工具B中有多少个元素对应于工具A中的一个元素，反之亦然。如果没有为关联端提供多重性，我们假设多重性为1。这些多重性稍后用于检查（半）自动创建的对应链接的一致性和完整性。在我们的运行示例中，隐式定义的多重性约束要求，例如，所有的需求文档实例的类PackageGroup、Feature和Departure 都 映 射 到 一 个 用 例 文 档 的 对 应 类 Package 、 PackageCase 和Relationship集成架构公司简介<<集成>>数据组包关系包-name：String-name：String特征<<集成>>联系我们用例-name：String-name：String依赖<<集成>>依赖关系关系0..*容器0.. 1包图-name：String10..*用例-name：String11TRGsrc0..*0..*泛化企业案例A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113122<<集成>>AnotherRelation一<<集成>>AB关系B1 1图7.第一次会议。对应链接类型声明的原型此外，链接类型声明可以继承自另一个链接类型声明，这样我们就能够构建对应链接类型的建模域规范请注意，MOF 2.0现在提供了本文中没有讨论的泛化和细化关联所需的方法它们对于定义可重用和可适应的元模型集成规范非常重要对于MOF 2.0关联的泛化和细化（重新定义和子集化）语义的未决问题的讨论，读者可以参考[1]。2.2积分规则在声明了对应关系的类型之后，我们现在需要一种语言来指定必须满足的条件，以便将对应关系视为一致的。一个明显的可能性是使用一种文本语言，如对象约束语言（OCL） [34]。例如，如果我们想声明一个类型为PockureGroupPackageRelation的对应链接是一致的，如果带有标识符fg的附加PockureGroup的名称与带有标识符p的附加Package的名称相同，我们可以写这样的东西：fg.namep.name。 这是一个简单明了的道理。现在让我们来看第二个例子。 我们想声明，如果带有标识符f的附加特征的名称与带有 标 识 符 uc 的 附 加 实 例 的 名 称 相 同 ，并 且 f 包 含 在 通 过 类 型 为FgureGroupPackageRelation fgpr的对应链接链接到包p的FgureGroup fg中，并且包p最终包含uc，则类型为FgureGroup CaseRelation的对应链接是一致的。在文本约束语言中，所需的约束定义看起来像f.name=f.fg.fgr.p.uc.name。虽然所考虑的约束仍然是非常基本的，但这个表达式更难想象和理解，特别是在没有我们在这里省略的图形的情况下A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113123故意的如果对应关系是否一致的条件变得更复杂，情况会变得更糟解决的办法是使用一个图形符号来定义一致性条件。只有那些不能合理地以图形方式表达的部分条件，才应该以文本方式表达例如，这涉及到名字相等的条件大约30年前，人们发明了图语法，目的是用图形来定义视觉语言的语法和静态语义[37，42]。与元模型结合使用时，它们正好提供了适当的方法来定义约束，这些约束决定了我们的对应关系的一致性图形语法，或者更准确地 说 ， 编 程 图 形 转 换 系 统 已 经 被 各 种 集 成 可 视 化 编 程 环 境 （ 如PROGRES[47]，FUJABA[30]，AGG[48]或DiaGen[26]）改编和实现。这些环境已经并且仍然被成功地用作元CASE工具，用于原型化集成的CASE和编程工具集[29]。有关各种形式的图语法、可用实现和相关成功故事的进一步细节，读者可以参考“为了能够将OMG对象（MOF类实例）显然对应于具有类型标签的属性节点，而链接（MOF关联实例）被解释为具有类型标签的有向二元边。工具元模型被解释为图模式或类型图，定义了节点和边的类型以及相关的属性[47]。除了图模式之外，图语法还提供了一组图重写规则。这些规则描述了如何创建符合图形语法的任何图形每个规则都提供了一个左手边，它指定了在构建下的图中必须找到的模式，以便应用该规则。此外，每个规则都提供了一个右侧，该右侧指定了一个模式，该模式将替换其左侧的选定匹配，作为规则应用的结果图8描绘了图重写规则的第一示例图8a使用具有分离的左手侧和右手侧的图重写规则符号。这种符号被PROGRES和许多其他的图重写系统方法所使用。为了将参数化的规则Because Case应用于正在构造的图，该图必须至少具有A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113124：图表<<新品展示>><<新品展示>>：案例名称= xa) String（x：String）：：=b) String（x：String）图8.第八条。图重写规则示例一个图节点。在已经选择了规则的左手侧的可能匹配之一之后，将规则的右手侧与其左手侧之间的差异在应用规则之后，图得到了一个新的RISKCase节点，其name属性值由规则的参数x提供此新的“关系图案例”链接到先前选定的“关系图”节点。图8b以一种折叠样式描绘了与FUJABA中使用的相同的规则。这种折叠规则的左侧由没有任何原型的节点和边6，右手边包括所有未标记的节点和边以及所有用原型new标记的节点和边。我们在下面使用折叠样式它是首选的符号，只要使用单调规则，不删除任何节点和边缘的图形。作为一个例子，我们现在为我们的UML用例图展示一个图语法规则的子集。我们记得图3中所示的元模型充当图图9列出了所需的图形语法规则。请注意，我们使用了两个规则，左边是空的，来定义这样一个文法的额外需要的开始图或公理这些规则只能应用于空图，从而创建一个仅包含一个Package或一个Diagram节点的图规则“包”允许使用提供的名称创建一个新的包。相应地，规则“关系图”允许创建一个新的关系图。规则addPackage描述了添加一个新的Package，它是现有Package的一部分。相应地，addDiagram描述了添加一个新的Diagram，它是现有Package的一部分。通过使用规则addBullCase，我们可以向现有的Diagrams 中 添 加 新 的 BullCase 。 最 后 ， 我 们 可 以 通 过 应 用 规 则addGeneralization，通过Generalization关系来连接现有的实例。图10演示了5节点和边的删除是通过删除规则左手边的差异来处理的。图的右侧和右侧6一般来说，标记为原型delete的节点和边也属于规则：图表：图表：案例名称= xA. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113125<<新品展示>>：图表a) String（x：String）<<新品展示>>：包装名称= xb) 图（）c) addPackage（x：String）：包装<<新品展示>><<新品展示>>：包装名称= xd) addDiagram（x：String）：包装<<新品展示>><<新品展示>>：图表名称= xe) String s（x）：图表<<新品展示>><<新品展示>>：案例名称= xf)addGeneralization（）：案例<<新闻>> trg<<新品展示>>：推广<> src：案例见图9。 图重写规则图9中引入的图重写规则的应用程序序列看起来像是创建图4中的UML对象图表示。我们首先应用规则WIPINGWASHING（“WipingWashing”）。这步骤创建一个名为WipingWashing的新包。然后我们添加一个使用规则addDiagram（）将新的Diagram添加到此包。通过应用规则addWiping Case（“Wiping”），我们将一个名为Wiping的Wiping Case添加到图中。 我们用不同的参数值再应用这个规则两次，以创建另外两个实例。最后，我们使用规则addGeneralization（）两次来创建Generalization关系。相应地，我们也可以为需求文档编写一个图形语法为了进一步地-关于各种形式的图文法及其基于范畴论、一阶/二阶逻辑和集合论的形式定义，读者可以参考[11]和本文的第4我们的两个图语法被单独使用，现在创建并表征所有元模型一致的需求文档或用例文档（对象图）的语言。通常，给定的图语法仅创建模式一致（元模型一致）图的条件不能被静态地检查。前面提到的系统PROGRES使用例如静态类型系统来保证所创建的边仅连接正确类型的节点一旦涉及到复杂的多重性约束或属性约束，它就诉诸于运行时检查这是一个主题，A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113126a）、包装（“WipingWashing”）=>b）、addDiagram（）=>c）、添加工具箱（“擦拭”）=>e）、addPush Case（“DropArmSwitchWiping”）addPushCase（“WipingForWashing”）=>f）的addGeneralization（）addGeneralization（）=>图10个。图重写规则的连续应用正在进行的研究活动，以开发验证技术和工具，这些技术和工具在编译时保证给定的一组图重写规则不违反给定的一组静态语义规则（例如，以条件图模式或OCL表达式的形式）[5，50，40]。此外，我们不能保证一个特定的图文法生成所有的模式一致图。相反，我们使用图语法来描述所有元模型兼容的用例图和需求文档的子集，这些子集可以相互映射而不违反任何模型间一致性条件。更确切地说，我们使用三重语法（TGG）来指定相关图（模型，开发文档，工具数据存储库）之间的对应链接的一致性条件。三重图文法推广了Pratt [38]在30年前提出的对文法的思想，用于同时指定从文本文件到抽象语法图的解析 TGG介绍，[43]对于使用第三所谓的对应图连接的图对之间的双向变换的声明性规范，没有更合适的手段。TGG规则首先使用一对图重写规则描述两个图的所有同时推导;第三个图重写规则用于检查和创建两个图的相关节点之间的对应链接作为侧效应。 的这种组合：包装name =“WipingWashing”：图表：案例name =“Wiping”：案例名称=“DropArmSwitchWiping：案例name=“WipingForWashing：包装name =“WipingWashing”：包装name =“WipingWashing”：图表：案例name =“Wiping”：推广：推广：案例名称=“DropArmSwitchWiping：案例name=“WipingForWashing：图表name =“Wiping”：案例name =“WipingWashing”：包装：包装name =“WipingWashing”：图表A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113127必须同时应用的三个图重写规则是选择名称“三重图语法”的原因为了保持文档之间的一致性，将三重图文法的思想应用于实践是不切实际的。这意味着所有开发文档或模型将同时发展此外，所有文件将始终保持一致。不幸的是，这种情况通常如下：我们有许多文档是同时发展的。我们希望自动创建可追溯性的通信链接，并在需要项目数据库的一致状态时不时自动修复任何不一致之处因此，TGG是集成规则的声明性规范，对于工具集成目的并不直接有用。 从这些声明性规范中，可以自动导出操作图重写规则。这些操作图重写规则然后用于实现所需的数据/工具集成服务（参见图1）。第三章）。像普通的图文法一样，三元组图文法也有图模式[25]。 三元图文法模式简单地由一对简单图模式加上一个对应图模式组成，该对应图模式引入了实现不同图的节点之间的连接所需的所有额外的节点和边类型。在我们的示例中，这个角色由图5中的元模型扮演。此外，TGG提供了一组三元组图重写规则。图11列出了这样的三元组图重写规则的示例TGG规则创建由三个子组件组成的初始图（ax- iom）。图11中的TGG规则的左侧部分创建了一个新的属于需求子图的PackageGroup节点，其右侧部分创建了一个属于单独用例子图的新的Package节点，而其中间部分在两个新节点之间建立了所需的对应结构（一个节点和两个边），作为所有文档的图的第三子图。或者在MOF元建模术语中重新表述其效果，该规则在不同的模型中创建两个对象，并通过在它们之间创建对应链接将这些新对象相互形式为fg.name = p.name的约束确保相应对象的名称相同。这种相等性是通过使用附加到新的对应关系链接上的单独约束来强制执行的，而不是仅仅使用单个规则参数来确定两个对象名称的值，原因如下：一方面，创建需求文档和用例文档所需的属性值之间的明确分离，另一方面，跨越文档边界的约束简化了A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113128后来，从TGG规则中推导出了操作图重写规则图 11 的 第 二 和 第 三 个 TGG 规 则 将 类 EQUIPUREGroup 或FeatureandPackage 或 EQUIPCase 的 相 关 子 组 件 添 加 到 类EQUIPUREGroup 和 Package 的 已 经 相 关 的 对 象 对 。 最 后 ， 规 则addDependencyAndGeneralization 负 责 创 建 一 对 Dependency 和Generalization链接，用于连接适当类的已相关对象对。 请注意，我们已经省略了附加的负规则应用条件，该条件保证在给定的一对Feature对象（实例对象）之间创建的Dependency链接（实例链接）不超过一个。单对对象之间的这种多个链接不仅从相关模型的局部角度来看是无用的，而且还会导致自动创建对应链接的问题。 如何将一个模型中的平行链接连接到另一个模型中的相应平行链接是不清楚的。可以顺序地应用如图11中介绍的三元组图重写规则，以便创建符合三元组图语法的三元组图，即，以同时创建一对一致的文档或模型以及它们之间所需的对应链接。我们在图12中演示了规则的应用。在图12a中，我们应用了规则PURCHUREGroupAndPackage，用于同时创建PURCHUREGroup、Package和它们之间的PURCHUREGroupPackageRelation类型的对应链接。 然后，我们应用规则addaddingureAndaddingCase来推导图12b中描述的情况。在我们的方法中，我们要求三元组图重写规则必须符合图13中的三元组图重写规则原型。这意味着每个三元组图重写规则具有正好两个主对象a和b，它们同时被创建并由新的对应链接abr链接。另外，两个主对象都可以被提供有新对象被插入其中的本地上下文此外，该规则可以具有任意数量的对应链接。它们描述了两个文档的局部上下文对象之间必须存在的关系;否则，所考虑的规则不能被应用。此外，约束可以被附加到新的对应链接，其也必须保持该属性约束可能仅由涉及对象属于不同的模型7. 此外，该规则可能会产生仲裁-[7]今后研究活动的主题是允许更一般形式的属性约束，并使用众所周知的约束编程技术来导出修复违反约束的A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113129a）、b）、c）、d）、见图11。 三元组图重写规则在每一侧连接到选定的唯一主要对象次级对象在规则应用时创建，但不通过对应链接进行链接图13没有描述这些要求对应关系用例String s（x：String，y：String）<<新闻动态>>新闻动态>>fg：企业<<新闻>>：数据库组包关系名称= x<<新品展示>><>p：包装名称= y约束：== p.namefg.nameString s（x：String，y：String）：企业简介：数据库组包关系：包装<<新品展示>><<新品展示>><<新品展示>>fg：企业简介名称= x<<新品展示>><<新品展示>>：数据库组包关系<<新品展示>><<新品展示>>p：包装名称= y约束：== p.namefg.nameString s（x：String，y：String）：企业简介：数据库组包关系：包装<<新品展示>><<新品展示>><<新品展示>>f：特征名称= x<<新品展示>><<新品展示>>： 联系我们<<新品展示>><>uc：微处理器案例约束：== uc.namef.nameaddDependencyAndGeneralization（）：特点：联系我们：案例<> src<> src<<新闻动态>>新闻动态>><<新品展示>>：Dependency：Dependency依赖关系<<新品展示>><<新品展示>>：推广<<新闻>> trg<<新闻>> trg：特点：联系我们：案例A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113130文档间关系当地情况当地情况约束：<约束表达式><<新品展示>>B：B<<新品展示>><<新品展示>>abr：AB关系<<新品展示>><<新品展示>>a：Aa）、b）、见图12。 三元组图重写规则图13岁一个三元组图重写规则的原型当一个模型的单个对象被转换成另一个模型中的一组相关对象最后，我们的TGG规则可能永远不会删除任何对象，原因有两个：首先，TGG用于生成一致的文档对的语言，而不是操作文档对，即删除对象和边是不需要的操作此外，限制我们自己的图语法与单调的规则，只有我们避免了陷阱的一旦允许节点或边删除规则，图语法分析问题，即识别由给定的图语法生成的所有图的问题，变得几乎不可行。直到今天，只有非常有限的一类图文法是已知的，它们保证了相关解析算法的多项式空间和时间复杂度[41]。不幸的是，检查文档对的一致性或基于TGG规范将一个文档转换为另一个文档本质上需要解决给定TGG的简单图形语法组件的解析问题依靠上面提到的所有约束，我们只需要访问所考虑的所有对象。要求对应关系WipingWashing（“WipingWashing”，“WipingWashing”）||V用例p：包装addaddaddureAndrender Case（“Wiping”，“Wiping”）||p：包装fucr：查询案例关系uc：电子邮件name =“Wiping”f：特征name =“Wiping”name =“WipingWashing”name =“WipingWashing”fgr：文件组包关系fg：企业简介name =“WipingWashing”name =“WpingWashing”fgr：文件组包关系fg：企业简介A. Königs，A.Schürr/Electronic Notes in Theoretical Computer Science 148（2006）113131文档间关系String s（x：String，y：String）：包装<<新品展示>><<新品展示>><<新品展示>>f：特征名称= x<<新品展示>>uc：电子邮件当地情况当地情况约束：==uc.namef.name名称= y<<新品展示>><<新品展示>>：联系我们新闻>><

下载后可阅读完整内容，剩余1页未读，立即下载