面向对象行为模型：UML一致性管理与模型转换

理论计算机科学电子笔记109（2004）57-69www.elsevier.com/locate/entcs面向对象行为模型约翰·M. Küster1帕德博恩大学计算机科学、电气工程和数学系德国帕德博恩摘要随着统一建模语言在不同环境中的使用，定义和检查自定义一致性条件的能力越来越重要。通常，一致性检查依赖于现有的形式化分析工具，如模型检查器，并需要将模型转换为这些工具的输入语言。不一致性处理技术旨在系统地处理由这种一致性检查检测到的不一致性。不一致的解决方案通常涉及更改模型，在软件工程师的指导下或在理想情况下完全自动化。因此，在使用正式分析工具进行一致性检查的情况下，这些工具的输出必须以软件工程师可以理解的形式呈现在本文中，我们开发了一个面向对象的行为模型的不一致处理的概念，并讨论如何图转换可以用于重建UML模型从分析工具产生的输出。保留字：一致性管理，UML，模型转换，模型分析1介绍随着统一建模语言[10]被用于不同的环境（由应用领域，方法和平台给出），定义和检查自定义一致性条件的能力越来越重要。除了作为用户定义的UML概要文件的一部分的OCL中的良好格式规则之外，几乎没有对自定义规范和一致性条件检查的支持。特别是，不向开发人员1电子邮件地址：jkuester@uni-paderborn.de1571-0661 © 2004 Elsevier B. V.根据CC BY-NC-ND许可证开放访问。doi：10.1016/j.entcs.2004.02.05658J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）57指定行为一致性条件，如状态图和序列图之间的兼容性的特定概念如果要在不同的上下文中成功地使用UML，则需要方法和工具支持来指定和检查语法和语义级别上的一致性条件在[3，1]中，我们开发了一种在基于UML的开发中进行一致性管理的方法我们定义一致性概念的方法是通过将模型部分转换为形式化方法，该方法提供语言和工具支持来制定和验证语义一致性条件。翻译是通过Meta模型级别的图转换规则来指定的[7，1]。根据开发过程和应用领域，可以定义到不同语义域的不同翻译。采用这种方法，可以处理不同形式的一致性：水平一致性问题，涉及同一抽象级别的较大模型的子模型，以及属于开发过程中不同阶段的子模型之间发生的垂直一致性问题（通常需要表达特定细化条件的一致性条件）。此外，可以定义语法一致性条件以及语义一致性条件。一致性检查通过翻译一个或多个子模型并检查指定的一致性条件来指定。在不一致的情况下，需要支持软件工程师处理不一致的不一致处理活动，例如解决或容忍它。到目前为止，没有一般的概念，面向对象的行为模型的语义一致性条件方面的不一致性处理是可用的。这些模型的不一致性处理是复杂的，因为一致性检查的结果是根据用于这种方法的形式语言给出的，并且这种不一致性的校正通常需要在不一致性模型语义中对模型进行复杂的改变。在本文中，我们研究了面向对象行为模型的不一致性处理问题，遵循我们在[3]中提出的一致性管理的一般方法首先，我们简要报告现有的工作一致性检查，介绍一个例子的一致性问题。然后，我们阐述了不一致性处理的概念最后，我们专注于使用图形转换过程中的不一致性处理重建UML模型从模型检查器产生的输出。J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）5759p1帽子1<<连接器>>连接器p2caps2SC1_p1SC2_p2简单的协作SC2SC1S1S4S4S1/发送bD/send cBSC保护S2/send dS3S3S2S1CSC2_p2.bS2SC1_p1.cS4S3SC1_p2.dFig. 1.一致性问题示例2使用一致性检验方法我们将首先介绍一个行为一致性问题，称为UML-RT [13]中的协议一致性，现在也出现在核心UML中2.0具体说明[11]。在图1中，示出了两个结构化对象caps1和caps2，它们通过连接器经由两个端口p1和p2连接。连接到该连接器的是在方案状态图SCProt中建模的行为。结构化对象的行为在两个状态图中指定，命名为SC1和SC2。直觉上，执行结构化对象的状态图所产生的交互应该符合协议状态图中指定的协议为了确保在这种情况下的行为一致性，一个正式的一致性概念是必要的。这样的一致性概念包括一组子模型类型（在这种情况下，协议状态图，结构化对象和协作的状态图），这些子模型类型到一个共同的语义域的映射和一组一致性条件形式化的一致性的非正式注意到的形式。使用这种形式一致性概念，可以在开发过程中引入一致性检查以确保一致性：在一致性检查中，将具体的子模型转换为语义域，然后评估一致性条件。对于协议一致性，我们可以定义两个不同的一致性条件：对于弱协议一致性，我们要求结构化对象状态图的所有相互作用的轨迹必须包含在协议状态图的轨迹集中。对于强协议的一致性，我们额外假设，所有的痕迹的协议状态图必须发生在系统中。通过引入发送另一个事件的另一个转换来扩展状态图SC1将违反弱协议一致性的条件。60J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）57删除SC2的最后一个转换将违反协议强一致性的条件。在以前的工作中，我们已经报告了这样一个一致性概念的细节。作为运行示例，我们选择了形式化方法CSP [8]和模型检查器FDR [4]来评估一致性条件。为了支持软件工程师完成转换子模型和定义一致性检查的复杂任务，我们开发了一致性工作台[2]。简单地说，这个工作台允许定义UML模型到语义域的基于规则的翻译，以及将一致性检查定义为工作流，组成翻译活动并触发外部模型检查器。目前，一致性工作台包含状态图和协作到CSP的预先定义的翻译关于协议一致性，一致性工作台产生的结果当前是违反一致性条件的跟踪。3不一致性处理：基础与技术不一致性处理[14]是一个活动和技术的概念，旨在处理多视图软件开发中的不一致性根据基于模型的开发中使用的语言和抽象的类型，已经开发了非常不同的不一致性处理技术。一般来说，人们可以区分变化的行动和不变化的行动，以及容忍或解决不一致的一般决定不一致处理包括识别该等行动以及评估其成本及评估未能解决不一致的风险关于面向对象模型的不一致性处理，我们将只讨论处理它们的操作，将风险和成本的评估留给未来的工作。关于面向对象模型的不一致处理方法的要求，首先，该方法应该允许软件工程师解决不一致问题。此外，它应该避免引入新的不一致，并应直接在UML模型中执行最后，为了不给软件工程师强加太多的工作，这种方法至少应该是半自动化的。此外，对于面向对象行为模型的一致性管理方法，还存在特定的不一致性处理要求：• 应该重用模型给出的不一致信息J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）5761语义域误差轨迹模型Submodel 1Submodel n子模型显示不一致翻译与抽象回注模型检查器图二. 一致性检查和回注检查员（e. G.对不一致性的跟踪），并将其充分地呈现给软件工程师，• 必须依靠软件工程师来解决不一致的• 必须允许软件工程师指导不一致的解决方案，• 应该可以集成到一致性工作台中。特别是，解决方案必须依赖于软件工程师的要求非常重要。 这是因为改变在没有软件工程师的交互的情况下，通常不进行建模。作为一个简单的例子，考虑序列图和状态图之间的一致性问题如果一个场景不能被状态图实现，就会出现一个常见的一致性问题。这里，原则上有两种解决不一致的方法：从有效场景集中删除场景，或者将场景添加到状态图支持的行为中。虽然工具支持删除一个场景或添加一个场景是可能的（e。G.通过从一组序列图[15]调整状态图合成的工作），必须由软件工程师做出决定。另外，改变状态图以支持另一场景可能是困难的，并且还影响与场景相关的其他行为。因此，在这种情况下，很难完全自动化状态图的改变。为了实现不一致性管理，重要的是检测不一致性。这是通过一致性检查来执行的然而，这种一致性检查的结果是根据语义域中的语言给出的。在不一致的情况下，这通常是对62J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）57错误状态为了便于软件工程师使用，这种对错误状态的跟踪应该以源语言的形式给出，在我们的例子中是UML。因此，问题是将模型检查器的输出翻译回源语言UML。在这里，可以区分两种方法，在下文中称为反向注释：我们可以注释现有的UML模型，或者我们可以构建一个新的UML模型来说明不一致性。作为现有模型的注释示例，考虑在序列图中建模的不一致时序约束的一致性问题这里，应该在已经存在的序列图中显示一个提到不一致性的注释如果我们构建一个序列图，显示协议违反发生的场景，那么就会出现构建一个新UML模型的例子。在图2中，说明了反向注释的问题。由于从UML模型中抽象出用于执行一致性检查的语义域的transla- tion，因此反向注释的问题并不简单，因为在反向注释的过程中，为了对软件工程师有用，必须达到原始的抽象级别使用反向注释技术，可以显示一个UML模型，说明发现的不一致性。为了使软件工程师能够解决不一致性，通常需要进一步的支持。这种支持通常取决于底层一致性概念i的类型。e.对于大范围的不一致性，可能需要非常不同类型的支持对软件工程师的一种可能的支持包括模拟。在前面的示例中，可以沿着协议违规的跟踪来模拟整个模型。这样的模拟可以在UML模型级别上完成，包括在反向注释期间创建的序列图。进一步的支持包括用于包括或移除违反协议的跟踪的半自动算法：可以扩展协议状态图以还包括跟踪，或者可以限制单个状态图不包括跟踪。这可以通过在状态图上定义的特殊算法来完成。在下文中，我们将把自己限制在回注的问题上.4基于图变换的UML模型的反向标注到示出的问题的反向注释，考虑由FDR模型检查器在控制器中产生的跟踪J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）5763接收器发送者名称=：留言名称=：留言UMLname =UMLname =：生命线：生命线名称=：留言发送接收器图三. 重建模型违反协议的文本。 对于简单的例子，我们得到把它拿出来。把b，AB，它的A，p发送出去。把c，AB，它的B，p发送出去。sendd这表示结构化对象的系统在UML级别上执行跟踪。b，SC1p1。c，SC2p2。可能未包含在错误协议状态图中的数据反向注释的目标是从CSP中给出的这样一个跟踪构造一个UML模型，帮助软件工程师处理UML模型中的不一致。与反向注释相关的一个问题是，我们必须能够表达与源UML模型兼容的信息：在转换和抽象到语义域CSP的过程中，我们可能已经将UML中的概念重命名为CSP，并遗漏了UML模型的细节。例如，在具体的例子AB itsB p出。send b对应于经由端口p2发送SC 2，即信息out。发送是在转换为CSP时添加的内容。此外，消息b的接收者的细节已经被省略，并且在CSP跟踪中不可见。这里需要的是一种方法，它允许我们在将CSP错误跟踪转换回UML模型时重构所需的抽象级别。这种方法必须首先与从UML到CSP的转换交织在一起。在那里，必须确定并存储回注所需的信息。我们解决这个问题的概念如下：当设计从UML到CSP 的转换时（即，e.当抽象时），必须确定哪些方面是从更抽象的CSP模型重构UML模型所必需的。这些方面必须被映射到一个所谓的重构模型中，然后在不一致性处理过程中，该模型可以用于生成/反向注释在图3中，我们为我们的运行示例展示了这样一个重建模型从一个简单的轨迹重建序列图所需的信息，作为FDR模型检查器的输出，可以描述如下：64J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）57p1俄.西RHRT图四、 复合规则p 1，由rS、rH和rT组成首先，对于交互的每个参与者，应该在序列图中显示生命线。在具体的交互中，我们需要为SC1和SC2分别设置一条生命线.其次，必须在重建模型中标记由另一个对象发送到另一个对象的每个消息。此外，我们需要重新构造发送者和接收者的UML名称，为此，我们在生命线中包含UMLname和CSP name在下文中，我们将假设存在一组图转换规则，用于将UML状态图和协作转换为CSP。这方面的细节可以在[6]中找到总体目标是构建一个序列图，其中包含参与协议的对象的生命线，以及对协议违反的跟踪。一般的方法是使用CSP中给出的迹信息和重构模型来构造目标模型，即所需的序列图。反向注释本身将使用图形变换来指定。我们将使用同步复合图变换[9]，这是一种自适应三重图变换[12]。这样的复合变换已经被用于生成CSP模型在considerable。简单地说，一个复合变换可以用一组复合图变换规则来描述。复合图变换规则本身由固定数量的图变换规则组成，其中每个图变换规则描述模型的变换在复合转换规则中，所有的转换规则都通过使用共同变量来耦合。形式上，通过在属性顶点处连接所有单独的转换规则，复合转换规则可以由类型化属性图转换规则表示。为了从CSP中给出的迹构造序列图，我们做：生命线UMLname = X>：生命线UMLname = Y>：生命线UMLname = X>：生命线UMLname = Y>：互动：生命线：生命线名称= X>名称= Y>J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）5765p2俄.西RHRT图五. 复合规则p 2，由rS、rH和rT组成使用由三个变换组成的复合变换，一个用于称为rS的轨迹，一个用于称为rH的重建模型，一个用于称为rT的目标模型。总的来说，我们需要两个复合转换规则，第一个生成一个空的序列图，如图4所示，另一个根据CSP跟踪迭代填充序列图。在图4中，我们展示了生成空序列图的复合规则p1在UML 2.0中，这样一个空的序列图由一个交互和两个生命线组成。生命线根据重建模型中保存的生命线命名，使用每个生命线的UMLname注意，在这种情况下，rH具有相同的左侧和右侧，并且不改变重建模型。在图5中，显示了复合规则p2，用于开始从CSP跟踪生成序列图。该规则在跟踪中匹配对象的名称和接收到的消息的名称，然后在接收消息的重构模型中找到对应的生命线。请注意，这里我们假设消息名称是不相交的，否则在重建模型中可能会出现多个匹配。从轨迹重构序列图的主要思想包含在rT中，r T是复合规则p2中包含的第三个变换。在这里，在r S和r H中匹配的信息被组装以在序列图中创建新的模型元素：对于由CSP跟踪中的对象发送的消息（由对象表示。发送消息），则具有该名称的新消息发送者发送者：留言接收器覆盖覆盖覆盖后之前接收事件sendEventn =混乱>：留言：事件发生：事件发生：一般订购名称= Y>名称= X>：生命线覆盖：生命线接收器UMLname = Y>UMLname = Y>：生命线：生命线名称=混乱>名称=混乱>：留言CSP名称=UMLname = X>CSP名称=UMLname = X>：生命线：生命线<休息>.send_mess>，rest>名称= Y>名称= X>：生命线：生命线：互动：互动66J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）57俄.西RHRT见图6。 复合规则p3，由rS、rH和rT组成在序列图中创建并附加到相应的生命线。这里注意，接收消息的生命线仅 通 过 使 用 重 建 模 型 才 知 道 。 此 外 ， 还 创 建 了 两 个 新 的EventOccurrences，以及它们之间的GeneralOrdering其中一个事件表示消息的发送，另一个事件表示消息的接收。这些事件发生被相应地附加到生命线和消息中。在应用规则p2一次之后，一个只有一个消息交换的序列图就存在了.因此，对于每个要引入的额外消息，我们将应用规则p3，它遵循p2的基本思想，但处理已经存在于生命线上的EventOccurrences的情况：在UML 2.0的序列图中，生命线上的所有事件都是有序的。为了实现这一点，我们必须在两个现有生命线中将所有现有的事件发生附加到新创建的事件发生。这是通过在rT的左侧使用两个多对象来完成的，每个生命线一个，并相应地附加新创建的事件发生现在我们将规则p1和p2应用于模型检查器给出的样本轨迹和图3中的重建模型。我们假设规则p1和p2只应用一次，而规则p3尽可能长时间地应用在我们的方法中，这样的控制流程可以正式指定（详细信息参见[9]）。这里请注意，没有无限规则应用程序可以发生，因为每个应用程序都会减少CSP跟踪的大小。在应用规则p1之后，我们得到一个空的序列图，p3.send_mess>，rest><休息>：生命线发送者CSP名称=UMLname = X>：生命线发送器CSP名称=UMLname = X>：留言名称=混乱>：留言名称=混乱>：生命线：生命线UMLname = Y>receiverUMLname = Y>receiver覆盖：生命线名称= Y>覆盖：生命线名称= X>覆盖覆盖：Event：Event发生率before before：一般订购：一般订购：一般订购覆盖覆盖后：事件发生接收事件后后之前：留言：事件发生sendEventn =混乱>：事件发生：事件发生名称= Y>名称= X>：生命线：生命线：互动：互动J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）5767：互动p1p2覆盖见图7。 应用规则p1和p2在应用规则p2之后，我们得到了如图7所示的序列图(note我们只将重构的序列图显示为元模型实例，而忽略了重构模型和CSP跟踪模型）。5结论在本文中，我们讨论了面向对象的行为模型的不一致性处理问题。这类模型的不一致性处理是困难的，因为通常行为一致性检查是在外部语义域中执行的。我们首先介绍了不一致性处理的要求，并开发了主要技术：在不一致性处理中，处理不一致性的预定义准则以及向软件工程师说明不一致性的模拟方法非常重要。特别是，反向注释技术i.e. 重新构建一个新的UML模型或修改现有的UML模型以包含额外的信息，对于成功、方便地处理面向对象的行为模型的不一致性是至关重要的。在本文的第二部分，我们详细阐述了回注问题。已经引入了重构模型的概念，其用于在翻译到语义域期间保存回注内所需的信息。我们已经进一步阐述了如何现有的方法，图转换，使用的规则为-垫的复合规则，已经成功地用于翻译UML模型到一个语义域也可以用于回注释。覆盖覆盖后之前接收事件sendEventn=：留言：事件发生：事件发生：一般订购名称=名称=：生命线：生命线：互动名称=：生命线名称=：生命线68J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）57我们的反向注释方法已经通过一个简单的例子进行了说明，在这个例子中，CSP跟踪被用于构造UML序列图。未来的工作可以在以下几个方面进行：首先，必须深入研究不同的一致性问题，可能会导致更丰富的转换集回注释的回注释的问题第一个想法是也包括负跟踪，并利用UML提供的丰富的模型元素集。此外，区分强制性行为和潜在行为可能是有用的（参见Haugen等人[5]）。其次，我们的目标是将我们的回注释技术纳入一致性分析。此外，还应开发专门的出租等技术引用[1] G. 恩杰尔斯河 他是凯尔，还有J。 M. Ku？ster. 基于UML元模型的基于规则的分布式对象集成。In M. Gogolla和C. Kobryn，编辑，UML 2001 -统一建模语言。建模语言、概念和工具第四届国际会议，加拿大多伦多，2001年10月1-5日，会议记录，LNCS第2185卷，第272-287页。Springer-Verlag，2001.[2] G. 恩杰尔斯河 他是凯尔，还有J。 M. Ku？st er. 在基于UML的开发中进行一致性管理的一种方法。在P. Stevens、J. Whittle和G. Booch，编辑，UML 2003 -统一建模语言。建模语言和应用。第6届国际会议，旧金山，10月20 - 24日，美国，会议记录，LNCS第2863卷，第356-359页。Springer-Verlag，2003.[3] G. Engels，J. M. 库斯特湖 Groen ewegen，andR. 嘿，嘿，嘿。一种面向对象行为模型一致性分析方法Volker Gruhn，编辑，第8届欧洲软件工程会议（ESEC）论文集，第186-195页。ACM Press，2001.[4] 正式系统欧洲（有限公司）。 故障-发散-修正：FDR 2用户手册，1997年。[5] - 是的Haugen和K.史卓伦 STAIRS -使用细化语义分析交互的步骤。 在P. Stevens、J. Whittle和G.Booch，编辑，UML 2003 -统一建模语言。建模语言和应用。第6届国际会议，旧金山，10月20 -24日，美国，会议记录，LNCS第2863卷，第388-402页。Springer-Verlag，2003.[6] R. Heckel，J. M. Kuést err，N. Band en err，B. 你好，我。 Jahn ich，C. K oep ke和M。我们是一伙的。Aut o m at ischeQu alitéatssiche rung vonUMLMod ellen. Ber ichtderProjekt gg pe.Technical ReportTR-RI-03-245，Universit？tPaderborn，December2003。[7] R. Heckel，J. M. Küster和G. 你好。这两种方法都是基于语义域的UML建模方法。在H.- J.Kreowski 和 P. Knirsch ， 编 辑 ， Proceedings of the Programgraph Workshop on AppliedGraph Transformation，第11-22页[8] C. A. R.霍尔通信顺序进程。 普伦蒂斯·霍尔1985年[9] J. M. 库斯特河 H eckel，andG. 嗯。确定和验证通用模型的形式。在J. Hosking和P. Cox，编辑，IEEE Symposium on Human Centric ComputingLanguages and Environments （HCC2003）-Auckland，October 28-October 31 2003，Auckland， New Zealand，Proceedings，pages 145-152中。IEEE计算机学会，2003年。[10] 对象管理组（OMG）。 OMG统一建模语言规范，版本1.5. OMG文件formal/03-03-01，2003年3月。J.M. Küster/Electronic Notes in Theoretical Computer Science 109（2004）5769[11] 对象管理组（OMG）。UML 2.0 Superstructure最终采用规范。OMG文件pts/03-08-02，2003年8月。[12] A.很 好 。graptranlator 的 性 能 与 三 重 graphgrammars 有 关 。InTinhofer ， 编 辑 ，Proceedings WGLNCS 903，Springer-Verlag，1994年。[13] B.塞利克使用UML建模复杂的实时系统。In F. Mueller和A. Bestavros，编者，《嵌入式系统的语言、编译器和工具》，计算机科学讲义第1474卷，第250-262页。Springer-Verlag，1998.[14] G. Spanoudakis和A.齐斯曼软件工程中的不一致性管理：调查和开放研究问题。软件工程与知识工程，2：329[15] J. Whittle和J. Schumann。从场景生成状态图设计。在第22届软件工程国际会议上，爱尔兰利默里克，会议记录，第314- 319323. IEEE Computer Society Press，2000.