UML状态图和协作图的图形转换解释

理论计算机科学电子笔记130（2005）263-280www.elsevier.com/locate/entcsUML状态图和协作图的图形转换解释Paul Ziemann保罗·齐曼1，2不来梅大学计算机科学系德国KarstenHo？lscher3不来梅大学计算机科学系德国马丁·戈戈拉4不来梅大学计算机科学系德国摘要在本文中，我们继续我们的工作的形式化和验证的UML模型的图形转换系统。我们在这里集中于状态图和协作图，尽管我们的方法也涵盖了用例、类、对象和序列图。 状态图和协作图描述了底层类图的操作，并包括OCL表达式作为保护和消息表达式的一部分。 我们详细说明了生成的图转换规则的状态图和协作图。保留字：UML，图转换，集成形式语义，OCL1571-0661 © 2005 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2005.03.014264P. Ziemann等人理论计算机科学电子笔记130（2005）2631介绍统一建模语言（UML）最近已经成为面向对象软件系统的可视化、规范、构造和文档化的一个被广泛它在工业和研究中得到了很好的建立和使用UML是一种图形化语言，它包含了许多不同的图表类型，用于不同的目的。这些图类型的语法在UML元模型[9]中定义。但是语言构造的语义仅在自然语言中给出。由于UML是用来支持软件工程师构造精确模型的，因此需要一个UML的形式化基础。对象约束语言（OCL）增强了图形符号，允许以文本方式制定图无法表达的约束。OCL的正式定义见[11]。目前，UML的2.0版本即将完成[10]，但语言定义仍然是非正式的。通过将一个给定的UML模型转换成一个图形转换系统，我们为大部分UML提供了一个集成的形式化语义。集成意味着我们的方法中的模型可以包括用例、类、对象、状态图和交互（协作和序列）图。 我们坚持使用UML1.5，但是UML2.0同样包含了我们所涉及的UML概念特别地，协作图在UML 2.0中被称为通信图。图转换系统由图转换规则和工作图组成，工作图表示建模系统的当前状态（因此称为系统状态）系统状态在系统运行期间改变使用我们的方法，建模者可以通过执行系统运行并将他们的期望与这些运行的结果进行比较来验证系统模型。在本文中，我们提出了系统状态的基本概念和翻译的一个给定的UML模型到一个图形转换系统的重点是从状态图和协作图的规则。对我们来说，一个重要的方面是我们的方法集成了OCL。出现在模型中的OCL表达式也用于规则中。申请时1研究部分由EC研究培训网络SegraVis（视觉建模技术的语法和语义集成）和德国研究基金会（DFG）支持，作为合作研究中心637自主协同物流过程的一部分-范式转变及其局限性和项目UML-AID。2 电子邮件地址：ziemann@tzi.de3 电子邮件地址：hoelscher@tzi.de4 电子邮件：gogolla@tziP. Ziemann等人理论计算机科学电子笔记130（2005）263265一个规则，这些表达式被评估。可以找到其他几个作品，通过图形转换为UML的部分提供精确的语义。在[5]中为类、对象和统计图表引入了一个类似于这里提出的集成语义。由于这种方法不包括交互图，因此在[3]中扩展了它，在实例级别上添加交互图然而，操作必须由单个规则指定，因此只考虑原子操作另外，建模者被迫自己用图转换来丰富UML模型，因此这种方法与本文提出的方法相比不是纯粹的UML形式。本工作更详细地讨论了我们在[15]中已经提出的方法，该方法仅通过示例说明了基本概念。在本文中，我们解释的方法在一个更一般的方式。在[14]中，提出了一种基于元建模和图转换组合的UML状态图的形式语义。协作在[4]中被解释为可视化查询，并使用模式匹配转换为图转换规则。在[8]中提出了一种基于图变换在[6]中，重写规则及其操作语义被用于转换UML状态图以进行模型检查。Fujaba工具套件[2]自动地从行为UML图中生成代码，并使用被公式化为故事图的图转换来生成附加功能使用图转换的UML模型之间的一致性分析可以在[1]和[13]中找到。在第一个工作中，图转换用于细化UML实时模型。在CSP的语义域中检查它们的一致性在第二项工作中，类图和序列图之间的一致性检查通过图转换。本文的结构如下。在下一节中，将介绍和解释一个由类、协作和状态图组成的第3节提供了系统状态的一般概述我们的图转换方法和模型到图转换系统的转换的形式背景在第4节中解释，重点是关于消息发送的规则生成。本文最后得出结论。2集成规格与使用为了解释我们的方法的核心机制，我们提供了一个小的示例模型。它只包含后面描述的机制所需的图表，这些图表集中在我们方法的核心部分266P. Ziemann等人理论计算机科学电子笔记130（2005）263客户端1：ICQ客户端1客户* *客户端2聊天*客户端print（line：String）connect（caller：ICQClient，calleeID：ICQClient）establish（c1：ICQClient，c2：ICQClient）receive（line：String）联系我们ICQSessionICQ客户端ICQ服务器处理类、协作和状态图。一个合适的模型还应该包括一个指定初始系统状态的对象图和一个指定用户可以调用的操作的用例图。在这个例子中，我们模拟了一个非常基本的聊天系统，类似于Internet聊天系统ICQ。图1描述了这个模型的类图图1. 示例类图该模型包括三个类ICQServer、ICQClient和ICQSes- sion。一个ICQ服务器可以有任意数量的ICQ客户端，而后者只能是一个ICQ服务器的客户端。ICQClient有一个属性id，它唯一地标识操作客户端的用户。这个ID是在注册过程中创建的，这是用户能够成为ICQ聊天的一部分所必需的。在我们的示例中没有对该配准进行建模。两个ICQClient的实际聊天由类ICQSession管理。当然，ICQ客户端可以参与多个聊天，因此它可以连接到任何数量的会话。1：connect（caller，calleeID）«自我»1.1 ：callee：= self.client->select（id = calleeID）演员«本地»呼叫者1.2 ：create（）«本地»呼叫者C1«本地»«本地»1.3 ：establish（c1=调用方，c2=被调用方）C21.3.2.1b：[line.length =512]打印（line=line）«本地»1.3.2.1a：[line.length =512]打印（line=line）«自我»1.3.1 a：link（ascloud =Chat，session=session，client=c1 ） 1.3.1b ： link （ ascloud =Chat ，session=session ， client=c2 ） 1.3.2 ： receive（line=“established！“）图2. 协作图属于ICQServer和ICQSession类的操作在图2所示的协作图中详细说明。协作图通过可视化通过关联角色交换消息的分类器角色来指定对象的交互。分类器角色被描述为包含标识符和相应类名（分类器角色的基类）的矩形，由冒号分隔。类角色表示在交互中扮演特定角色的对象（对应基类的实例）。关联角色被描述为连接分类角色的边会话：会话客户端2：ICQ客户端服务器：ICQServerP. Ziemann等人理论计算机科学电子笔记130（2005）263267关联角色可以用冒号标记，后跟类图中关联的名称（基本关联）。然而，在示例中没有使用这种机制。特殊的构造型（guillemots中的文本）标记没有基本关联的关联角色。例如，一个分类器角色总是可能通过一个被定型为self的关联角色向自己发送一条消息（如图2所示）2在ICQServer 和 ICQSession 上 ） 。 构造 型 local 指 定 在关 联 角 色一 端 的classier role表示一个局部变量，该变量的名称作为role name。关联角色旁边的箭头表示消息，指向接收分类器角色的方向。消息总是调用某种操作。请注意，操作的调用与其实际执行并不相同。调用被认为是将执行请求放入接收对象的队列中。实心箭头描绘了同步消息，即，在同步消息所调用的操作完成之前，不能发送任何后续消息。异步消息用短箭头表示，但我们的示例不包含异步消息。序列号的嵌套反映了这些消息的顺序以及不同的激活级别。相同嵌套级别上的递增数字表示来自相同激活级别的连续消息调用，例如，1.3是1.2的继承者。如果消息处于相同的激活级别，则它们将从相同的分类器角色发送。如果消息是一个或多个消息的激活器，则增加激活消息的嵌套级别，例如，1.1是已经由消息1激活的消息。 如果存在调用操作的消息，并且由该消息激活的消息序列。因此，协作图显示了指定操作调用的子操作。序列号中出现字母表示并行发送消息，例如，消息1.3.1a和1.3.1b被并行发送。可以在序列号后面的方括号中提供表达式。这个表达式被称为守卫，即，一个布尔表达式，它必须被计算为true，才能实际发送相应的消息。如果守卫评估为false，则不会发送消息。示例协作图详细说明了在两个聊天伙伴之间建立聊天的过程。这里的情况是，许多客户端已经连接到服务器。首先，想要与另一个用户聊天的用户调用ICQ服务器的连接操作（序列号为1的消息）。这些参数是ICQClient调用者（表示聊天通信的用户端）和一个被调用者ID，该被调用者ID包含调用者希望与之进行通信的用户的唯一ID（如上所述）。268P. Ziemann等人理论计算机科学电子笔记130（2005）263建立聊天会话。然后服务器通过选择其内部列表中具有与调用者请求的ID相同的ID的客户端来识别代表被调用者的ICQClient（1.1）。然后它创建一个本地会话（1.2）并调用该会话的建立操作（1.3），提供调用方和被调 用方客户端作为 参数。这 导致调用链接 操作（ 1.3.1a 和1.3.1b），将代表客户端的两个对象链接到该会话，从而实例化关联Chat。这些操作被指定为并行执行。接下来，会话调用自己的操作receive（1.3.2），并使用常量字符串“established！” 作为参数。这是一条消息，通知两个客户端所代表的用户已成功建立连接。这是通过使用常量字符串“established！”并行调用两个客户端的打印操作（1.3.2.1a和1.3.2.1b）来实现的。作为参数。在我们的示例中，保护在我们的模型中不会打印较长的行，这意味着类似于某种针对恶意软件的保护，并用于演示在协作图中如何处理防护在示例协作图中，指定了连接、建立和接收操作另一种称为操作（例如，print）没有被指定，因为没有示出它们调用哪些子操作。请注意，在connect操作的上下文中，操作establish是用实际参数（caller和callee）调用的，但establish激活的消息仅引用establish的形式参数（c1和c2）。届会议receive（line：String）图3. 状态图示例该模型由图3中的状态图完成。一个状态图属于一个类，并且包括由转换连接的状态。转换标记有操作签名和方括号中的可选布尔OCL表达式（保护）。所示的状态图是ICQSession类的状态图，因为这是唯一一个具有相关状态的类。会话的初始状态为挂起。 执行建立操作后，状态变为就绪（相应的转换触发）。现在允许在会话上执行接收操作，并且状态图不会进一步更改其状态。虽然列图通过发送消息指定操作的调用，但状态图旨在可视化操作执行的限制，即，实际操作调用的顺序可能会被处理。如果没有状态图establish（c1：ICQClient，c2：ICQClient）待处理就绪P. Ziemann等人理论计算机科学电子笔记130（2005）263269系统状态操作sig：字符串并发：CallConcurrencyKind*属性1-- 超类子类类*name：String1关联结束协会用户名：type：Type*角色：字符串多重性：字符串2. *1name：String111* 10.. 1 初始状态name：String**状态{xor}1stateOf1NextState**AttributeLink**对象下一个状态2. *1value：值LinkEnd链路1*过程(from（进程）如果一个类存在一个图，那么任何属于它的操作都可以在任何时候被调用。但在当前状态图的情况下，只有当对象处于带有标记有此操作的传出转换的状态时，才允许对对象进行操作。在我们的示例中，如果会话的状态是挂起，则不允许执行接收操作。如果状态为就绪，则也不允许执行建立操作。然而，在其类的状态图中没有描述的操作仍然可以在任何时候执行。 如果一个转换被标记了一个保护，为真，为火。我们图形化模拟的系统运行从未违反状态图中指定的限制3系统状态顾名思义，系统状态表示由UML模型指定的软件系统我们通过类图来定义系统状态的抽象语法，如图所示。四、图4. 系统状态然后，一个具体的系统状态由一个实例化这个类图的对象图来表示。类图的形式基础及其270P. Ziemann等人理论计算机科学电子笔记130（2005）263对象图的实例化可以在[11]中找到系统状态当然可以以更可读的方式可视化，只要包含的信息与定义的抽象语法等效。在系统演化开始之前，系统状态类似于建模者提供的初始对象图。它包含Object类型的节点，表示最初存在的对象，连接到Class类型的节点，表示它们的类。然而，这是可能的，该模型包括指定初始对象状态的状态图。在这种情况下，通过将这些状态描述为State类型的节点并通过State链接将它们连接到相应的对象节点，将这些状态添加到系统状态。相应的类也连接到它们的初始状态的内部原因，有关某些图形转换规则。来自状态图的进一步信息不反映在系统状态中，而是反映在导出的图转换规则中。属于类的操作由连接到其类节点的操作节点描述更准确地说，表示类的操作的操作节点连接到类及其子类。此外，重写操作连接到重写操作所定义的类。未连接到Class节点的操作节点表示用例。对象通过Link和LinkEnd节点链接，这些节点依次连接到Association和AssociationEnd节点。对象的属性由AttributeLink节点表示，这些节点连接到在类上下文中声明属性的Attribute建模系统的系统状态被过程改变图5和图6中描绘了许多不同的过程类型。有原子进程和所谓的OpCall进程，后者表示执行中的用户定义的操作进程在执行时可以有局部变量，因此它们可以连接到存储这些值的LocalVar一些进程类型连接到所有者对象，即，Object节点，表示调用操作的对象。请注意，存在于几个类中的属性值的类型为Value，它包含所有可用的值类型。然而，这里没有涉及的完整性约束确保了实际的值类型对应于type属性给出的类型。原子进程不连接到操作节点，操作节点专门表示类或用例的操作。原子进程表示执行中的预定义操作 它们包括Create、Destroy、Link、Un-link、SetAttribute、SetLocalVar和Return进程. 创建过程用于创建对象。Destroy进程消除给定的对象，并因此连接到表示要销毁的实例的Object节点。链路和P. Ziemann等人理论计算机科学电子笔记130（2005）263271原子过程CreateProcess设置属性进程退货流程链接过程className：StringresultVarName：assocName：StringattributeName：Stringvalue：值type：Typevalue：值0.. 1*SetLocalVarProcessUnlinkProcessDestroyProcessassocName：String*localVarName：String类型：类型值：值0.. 12. *局部变所有者11 所有者2. *name：String类型：类型值：值对象(from系统状态）AtomicProcess过程活化剂 0个..1过程*状态：枚举{等待，活动，完成}seqNo：序列号局部变量*0.. 1复杂工艺name：String类型：类型值：值resultVarName：StringAtomicProcess(from原子过程）- -1 1 所有者操作(from系统状态）对象(from系统状态）1*参数(from系统状态）图5. 过程图6. 原子过程取 消 链 接进 程 创 建 和 销 毁 对 象 节 点 之 间的 链 接 。 SetLoc- alVar 和SetAttribute进程分别更改本地进程变量和对象属性的值返回进程完成其激活器进程并处理潜在的返回值。一个子进程，即，已被另一进程（激活器）调用的进程被连接到调用进程。该活化剂结构代表-272P. Ziemann等人理论计算机科学电子笔记130（2005）263在交互图的UML元模型中显示激活器树所有过程类型都有一个序号和一个状态作为公共属性。序列号取自模型的指定协作状态可以是#waiting、#active或#finished。这将在节中更详细地解释。四、4发送消息在本节中，我们将描述如何构建源自协作图和状态图的规则。描述是一般性的，但我们也会经常参考前面介绍的聊天示例。协作图通过显示操作以特定顺序发送的消息来指定类的操作。图2中的协作图指定了三个操作：类ICQServer的connect（caller：ICQClient，calleeID：String），类ICQSession的estab- lish（c1：ICQClient，c2：ICQClient）和receive（line：String）。消息调用用户定义的操作或预定义的操作，如设置属性值，设置局部变量或创建对象。用户定义的操作是在类图中为特定类声明的操作。例如，消息1.2调用预定义操作，而消息1.3调用用户定义操作。4.1图形变换图转换系统由工作图和一组规则组成，这些规则在应用时重写该图的一部分。我们将代数图模型用于属性图、有向图和标记图及其变换（参见[7]，[12]）。图变换规则由左侧和右侧组成，两者都是如前所述的系统状态。规则通常以下列方式表示。在重写过程中应该保留的节点出现在规则的两侧。它们由位于结肠前面的上隔室中的识别器识别。仅出现在左侧的节点被删除，而仅出现在右侧的节点被添加到工作图中。负应用条件（NAC）被指定为扩展左手侧的图，以便指定工作图中不想要的情况，即，如果有这种情况，就不能适用。布尔OCL表达式形式的应用条件（包括无边检查操作的调用）也可以这些表达式以类似于[11]中的OCL表达式的方式进行评估，因为系统状态图表示一个特殊的对象图，它反过来对应于[11]中解释的正式系统状态。当然，P. Ziemann等人理论计算机科学电子笔记130（2005）263273评估在该系统状态的上下文中而不是在系统状态图中进行。以通常方式表示属性值的变量也可以用于规则的两端。这些变量也可以在规则右侧的OCL表达式中使用，以计算新的属性值。因此，规则的右侧实际上不同于前面定义的系统状态中，属性可以保存一般的OCL表达式，而不仅仅是常量。4.2基础知识在我们的系统状态中，发送消息对应于创建一个状态为#waiting的进程节点。当等待进程被规则激活时，其状态将更改为#active。活动进程表示正在执行的操作。在下文中，我们简单地说，如果一个规则创建了一个流程节点，它就发送一条消息（或调用一个操作）处理用户定义的操作的子操作的调用的规则集被称为执行操作。我们在这里专注于这些规则。因此，让我们假设在系统状态中（在许多其他节点中）有一个用户定义的操作的等待进程（从技术上讲，有一个状态=#waiting的ComplexProcess节点连接到一个节点）。然后，我们需要在操作的协作图中指定的发送消息的规则。在每一条规则中，我们必须决定在什么情况下该规则应该适用，以及消息应该发送到哪个目标。在最简单的情况下（如果没有发送类分类器角色的类的状态图），我们只需要一个发送消息的规则。 规则的框架取决于消息的类型。下面让我们考虑一个调用用户定义操作的消息。我们将以一般的方式描述规则的构造。为此，考虑图7，其示出了类图方案。可以有更多的类、关联、属性和操作，但我们只需要这里显示的功能。图8显示了一个协作图模式，它指定了类Classname a的操作opname a。这个方案再次只显示了我们解释规则构造所需的特性;消息1.x（其中x是自然数）只是这里没有显示的许多其他消息中的一个。图9中描绘了用于发送该消息的规则的一般框架的方案。由于空间原因，规则的左侧和右侧显示在单个图形中：粗体边缘和节点仅显示在右侧。划掉的元素只出现在左侧。在左侧，我们有一个ComplexProcess节点，表示274P. Ziemann等人理论计算机科学电子笔记130（2005）263名称=“var_m”值=var_mv_a_m：LocalVarp_a：复杂过程名称=“var_1”值=var_1v_a_1：LocalVar1：opname_a（parname_a_1：Type_a_1，...，parname_a_k：Type_a_k）：Classname_a：Classname_b活化剂name=“parname_b_n”type=“Type_b_n”value =argexpr_b_nv_b_n：LocalVarsig =“opname_b（...）“status = #waitingseqNo =“1.x”resultVarName=“r”op_b：操作p_b：复杂过程name=“parname_b_1”type=“Type_b_1”value =argexpr_b_1v_b_1：LocalVarname =“Classname_b”o：目标c_b：类Classname_aAssocnameClassname_bopname_a（parname_a_1：Type_a_1，...，parname_a_k：Type_a_k）opname_b（parname_b_1：Type_b_1，...，parname_b_n：Type_b_n）图7. 类图方案演员1.x：opname_b（parname_b_1：Type_b_1=argexpr_b_1，...，parname_b_n：Type_b_n=argexpr_b_n）roleName图8. 指定类Classname a的opname a的协作图方案图9. 发送消息1.x的规则的方案。活化过程我们假设在前面的规则应用程序中，一个正确的流程节点已经用循环标记因此，现在没有必要将此节点连接到Operation节点这允许递归操作调用，而不管内射匹配。一个合适的激活器进程连接到类c a的操作op a，如果我们想通过这个规则发送的消息在协作图中没有前导，则状态为#waiting，否则状态为#active此外，我们有一个Operation节点op b连接到Class节点c b。这表示要执行的操作及其类，因此名称attrib-P. Ziemann等人理论计算机科学电子笔记130（2005）263275OP B和C B的UT被相应地设置（例如，建立相应的ICQSession）。这里未显示的NAC确保动态分派正确工作。最后，有一个对象节点o连接到c b。它是将对其调用操作的对象。在右侧，所有提到的节点也都存在，因为在应用规则时，系统状态图 中 的 相 应 节 点 不 应 该 被 删 除 。 该 规 则 应 该 创 建 一 个 新 的ComplexProcess节点，因此我们添加一个ComplexProcess节点p b，它连接到o和op b。激活剂边连接p b和p a，将p a标识为p b的激活剂。它的状态设置为#waiting，表示消息已发送，操作等待执行。seqNo和resultVarName（如果存在）根据协作图设置（序列号在第一个在我们的例子中，消息1.1调用了一个预定义的操作来设置一个局部变量，它有一个名为callee的结果变量。对于op b的每个参数par b i，我们添加具有相同名称和类型的LocalVar节点v b i。每个v b i都连接到p b。因此，新创建的流程对每个参数都有一个局部变量。 类的值属性v b i，... ..4.3特殊考虑OCL参数表达式中的变量。如果一个被调用的操作有参数，它们在协作图中作为OCL参数表达式给出。这些表达式可以在如上所述的规则中不变地使用。但是，这样的OCL表达式可以包含在应用规则和评估表达式时必须绑定的变量。消息只能包含激活器进程上下文中已知的变量。令变量1，...，var m是包含在参数example中的自由变量。然后，对于每个var i，我们在规则的两侧添加一个LocalVar节点v a i，其中v a i的name属性设置为常量var i，value属性设置为也名为var i的变量。 所有这些地方-Var节点连接到p a。当对任何匹配应用规则时，匹配将每个变量i绑定到一个具体的值，因此可以对表达式进行评估，并将结果插入系统状态图。276P. Ziemann等人理论计算机科学电子笔记130（2005）263同步和异步前置器。如果规则发送的消息在协作图中有一个或多个前置任务，则只有在（1）前置任务消息发送完毕和（2）同步前置任务调用的操作完成后，规则才适用。我们通过为每个前导添加一个进程节点并将其连接到激活器进程p a，激活器边位于规则的左侧来实现这一点 seqNo属性是根据协作关系图设置的，用于标识前置任务。 如果前任是同步的，状态设置为#finished。另一方面，如果它是异步的，则不设置属性状态，因为进程的存在就足够了，那么（即，消息已发送的事实）。不再需要作为前置进程的已完成进程将通过一个特殊的垃圾收集规则（此处不介绍）删除。通过本地或自关联角色发送。如果所考虑的消息是通过具有原型local的关联角色发送的，这意味着消息的接收者在激活器进程的局部变量中被引用。 此变量的名称作为接收分类器角色的角色名称因此，我们在规则的两边添加一个LocalVar节点，并将其连接到p a。它的名称被设置为协作图中的角色名称，它的值被设置为接收对象o。通过这种方式，我们确保通过应用规则，进程被附加到存储在指定局部变量中的对象。如果消息是通过原型self的关联角色发送的，它会被发送到激活器进程当前运行的对象，这意味着我们额外插入了一个从接收对象o到p a的所有者边。通过普通关联角色发送。当经由普通关联角色发送消息时，即，一个没有任何原型的关联角色，建模者还没有具体说明如何确定一个具体的接收者对象。唯一的要求是它与发送者对象链接，链接符合关联角色。这在规则中通过额外的节点和连接来确保。在协作图中，经常会发生这样的情况：在执行协作指定的操作期间，一个分类器角色会收到多条消息。然而，如果两个或多个消息通过普通关联发送，我们到目前为止还不能确保消息被发送到同一个对象，因为不同规则中的接收对象节点可以与系统状态图中的不同对象我们在以下方面确保这一点P. Ziemann等人理论计算机科学电子笔记130（2005）263277方式：通过普通关联规则发送多个消息中的第一个消息的规则将所选接收者存储在激活器进程的新局部变量中。在稍后的交互中通过同一关联角色发送消息的规则与通过本地关联角色发送消息的方式相同。发送并行消息。到目前为止，一个规则只创建一个进程，即，发了一条信息当在协作图中指定多个消息并行发送时，所有这些消息都由一个规则发送。对于每个接收到这些消息之一的分类器，在规则的两侧都有一个Object节点。发送给同一个classifier角色的两条消息会导致两个进程连接到同一个Object节点。单个消息的过程如上所述。警卫守卫是一个布尔OCL表达式，可以写在协作图中的消息前面（在我们的示例中，消息1.3.2.1a和1.3.2.1b有一个守卫）。如果它评估为false，则不应发送消息。然而，在我们的系统状态图中，我们需要在有其他消息等待此消息时处理此消息的信息需要处理出于这个原因，我们总是允许应用相应的规则来发送消息。但是如果guard的评估结果为false，则创建的进程的状态将被设置为#finished。因此，不执行相应的操作，但可以继续以下消息。 这是通过将右侧要创建的流程的状态设置为OCL表达式“if G then#waiting else #finished“来完成的 同样，为了能够在应用规则时评估OCL表达式，我们必须向规则中添加LocalVar节点，如4.3小节所述。States.一个UML类的状态图可以用来指定类中对象的操作执行顺序。在我们的聊天示例中，只有当会话处于挂起状态时，才允许执行建立操作。我们假设一个类的操作，不发生在类的状态图中，允许在任何时候执行。状态图还指定了操作完成后对象的状态。在我们的示例中，一旦完成了建立操作，会话的状态就会变为就绪278P. Ziemann等人理论计算机科学电子笔记130（2005）263因为状态图指定了一个操作是否允许执行，所以我们必须修改通过发送第一个消息（或几个并行的第一个消息）来启动操作的规则。让我们假设我们根据一个操作的协作图来构造发送消息一个类。此外，让我们假设这个类有一个状态图，并且有n个用操作标记的转换。然后，我们将发送协作图的第一条消息的规则拆分为n个版本，这些版本通过连接对象节点的状态节点和可选的应用条件。这个应用条件保存由所考虑的转换的可选保护给出的OCL表达式。因此，该规则仅适用于保护值为true的情况。State节点通过state边或nextState边连接到Object节点。一次只允许一条边。当一个对象通过一个nextState边连接到一个状态时，它不处于常规状态，而是处于两个状态之间。它连接到的状态节点表示对象即将拥有的状态。设上述n个转换中的一个从状态A到状态B。 在规则的相应版本中，我们添加一个Object节点o a，并连接它在具有所有者边缘的规则的两侧中被发送到激活器进程PA。然后，我们将一个State节点添加到左侧，name = A，并使用状态边将其连接到Object节点在右侧，我们添加另一个name = B的State节点，并使用nextState边将其连接到o a因此，如果在系统状态图中与o a节点匹配的对象不处于状态A，则不能应用此规则。另一方面，在一项研究中，如果可以应用该规则，则删除“状态”节点，并将对象连接到其下一个状态。通过用状态边缘替换nextState边缘，“下一这是通过返回规则完成的这里没有描述。5结论和今后的工作我们已经展示了从UML模型到图转换系统的翻译，以便为UML的大部分提供精确的形式化语义。 在本文中，我们专注于图转换规则的构建，这些规则表示在协作图中指定的消息发送。在开始时，我们介绍了一个示例模型，重点是协作和状态图。然后，我们已经描述了系统状态的概念，系统状态是表示建模系统的当前状态的图，并且随着系统的发展而通过图变换规则进行变换。在中心部分，我们已经描述了一个一般的方式，P. Ziemann等人理论计算机科学电子笔记130（2005）263279如何构造与协作图中指定的消息的发送相对应的规则。本说明集中于调用类操作的消息，而不是调用预定义操作（如设置属性值）的消息目前开发的工具，实现本文中讨论的方法。该工具的目的是在系统实际实现之前，可视化UML中指定的系统的演变。它加载了由类、用例、对象和协作图组成的UML模型，生成初始系统状态和图转换规则。然后，用户可以通过逐步应用规则来查看系统的演变。应用程序根据用户对用例（以及参数值）或等待过程的选择来选择规则也可以在当前系统状态下计算OCL表达式。使用我们的工具，用户不需要知道我们方法的细节。只需要知道所考虑的UML图的用法。今后的工作包括完成该工具，包括一个用户友好的图形用户界面。然后，我们的方法可以在案例研究中进行评估，提供有关其有用性的反馈。此外，我们还将研究如何用尚未涉及的UML特性这包括已经涵盖的图表类型的附加功能 另一个需要更广泛研究的重要问题是 我们的方法是如何允许通过检查结果图转换系统来断言UML模型的属性的。引用[1] Engels ， G. ， Heckel ， R. ， Kuéster ， J. M. ， 和 Groneneweegen ， L.（ 2002 年 ） 的 报 告 。Consistency-PreservingMod elEvolut ionthr ou ghTr an sf orm at ion s。我在J'ez'equ el，J. -M. ，Hu ssma nn，H. ，andCook，S.，UML 2002：统一建模语言模型工程、语言、概念和工具。第五届国际会议，德累斯顿，德国，2002年9月/10月，会议记录，LNCS第2460卷，第212-226页。斯普林格。[2] F是cer，T. ，Nier，J. ，Torunski，L. ，和Zündorf，A. （1998年）。StoryDiagrams：一种基于UML和Java的新型图形 在埃里希，H.，Engels，G.， Kreowski，H. J.， Rozenberg，G.，编辑，Proc.Theory and Application to Graph Transformations（TAGT斯普林格。[3] Gogolla，M.，Ziemann，P.，和Kuske，S.（2003年）的报告。面向UML的基于集成图的语义。在Graph Transformation and Visual Modeling Techniques（GT-VMT 2002），ENTCS第72卷中。[4] 黑克尔河和Sauer，S.（2001年）的第10页。通过状态转换加强UML协作图。在Hussmann，H.，编者，FASE 2001，第四届国际软件工程基本方法会议，作为欧洲软件理论与实践联合会议的一部分举行，LNCS第2029卷，第109-123页。斯普林格。[5] Kuske，S.，Gogolla，M.，Kollmann，R.，Kreowski，H.- J.（2002年）。基于图转换的UML类、对象和状态图的集成语义。在Butler，M. 和280P. Ziemann等人理论计算机科学电子笔记130（2005）263Sere，K.，编辑，第三届国际会议综合形式方法（IFM斯普林格。[6] 权，G.（2000年）的第10/2000号决议。重写UML Statecharts模型检查的规则和操作语义。在埃文斯，A.，肯特，S.，和Selic，B.，UML 2000：统一建模语言推进标准。第三次国际会议，联合王国约克，2000年10月，《会议记录》，LNCS第1939卷，第528-540页。斯普林格。[7] L？we，M. ，K或M. ，和Wagner，A. （1993年）。本文提出了一个用于属性图T形变换的代数在睡眠中，R，Plasmeijer河，和van Eekelen，M.，编辑，术语图重写：理论与实践，第185-199页。约翰·威利，纽约。[8] Maggiolo-Schettini，A.和Peron，A.（1994年）。基于图重写的全状态图语义。Schneider，H.和Ehrig，H.，编辑，Proc. GraphTransformationinComputerScience，LNCS的第776卷，第265-279页。斯普林格。[9] OMG（ 2003年） 。 OMG统一 建模 语言 规范 ， 1.5 版， 2003 年 3 月。 Object ManagementGroup，Inc.马萨诸塞州弗雷斯诺，互联网：http://www.omg.org。[10] OMG （ 2004 年 ） 。 UML 2.0 上 层 结 构 最 终 采 用 了 规 范 。 对 象 管 理 组 的 技 术http://www.omg.org/cgi-bin/doc? ptc/2003-09-15。[