MDA中的一致性检查对精化的改进

理论计算机科学电子笔记137（2005）151-161www.elsevier.com/locate/entcs通过MDA中的一致性检查进行改进Richard F.作者：Dmitrios S.Kolovos和Fiona A.C.波兰1约克大学计算机科学系英国约克摘要精化是对象建模组的模型驱动架构倡议中的一个关键实践。然而，实践是松散的定义，超载，并开放误解。 在本文中，我们概述了正在进行的工作，通过一致性检查为精化提供精确的定义，不仅在MDA的上下文中，而且更普遍地用于各种领域的模型驱动开发。保留字：模型驱动架构，一致性，可跟踪性，细化。1介绍模型驱动开发（MDD）试图提高软件和系统工程师执行任务的抽象级别。这是通过强调模型的使用来实现的--即，抽象-在工程过程中开发的工件。模型是感兴趣的现象的表示，并且通常比所表示的工件更容易修改、更新模型使用合适的建模语言来表达; UML是MDD中广泛使用和认可的标准[12]。1电邮地址：paige@cs.york.ac.uk网站，dkolovos@cs.york.ac.uk，fiona@cs.york.ac.uk1571-0661 © 2005 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2005.04.029152R.F. Paige等人理论计算机科学电子笔记137（2005）151MDD不是一种开发方法或过程;它是可以实现的以多种方式，例如，通过极限编程，Rational统一过程，B方法，或精化演算。MDD中的关键要素是构建和转换适合开发项目目的的模型。在构建和转换中使用的语言和过程将因项目而异模型驱动架构（MDA）[1]是对象建模组（OMG）[2]的一项倡议，旨在为MDD提供标准方法。虽然MDD没有规定使用特定的技术或工具，也没有规定要遵循的特定过程或步骤序列，但MDA需要使用标准建模语言- UML-和应该遵循的元步骤 模型和系统的开发也许令人惊讶的是，细化是MDA中的一个关键概念。这是令人惊讶的，有两个原因。首先，MDA中规定的语言是基于UML的，并且通常不提供人们在基于精化的方法中可能期望的形式化级别。其次，MDA中使用的语言是多视图的，因此很难用它们实现无缝的基于精化的开发。尽管细化是MDA中的一个（甚至可能是）关键概念，但这个术语的定义很松散，容易引起误解。这部分是因为MDA中使用的建模语言中存在相对的半正式性;但也是因为MDA目前相对不成熟。在本文中，我们报告正在进行的工作，在MDD和MDA的背景我们建议这些一致性规则可以用来提供MDA中细化的正式定义我们从MDA的简要概述开始，并给出其（非正式的）精化概念然后，我们描述模型的一致性（在MDD和MDA的上下文中），然后建议如何使用一致性来实现细化。最后，我们讨论了目前和今后的工作。这项工作的一部分是在欧盟综合项目“Modelware”[ 11 ]的背景下进行的2背景及相关工作2.1MDA概述通过MDD可以获得许多建议的好处，特别是提高了可移植性和生产率。模型驱动架构（Model-Driven Architecture）试图通过定义用于指定模型的公共语言和用于生成模型的公共步骤序列R.F. Paige等人理论计算机科学电子笔记137（2005）151153因此，MDA试图在实现MDD的好处的同时，也提高互操作性（不同的项目可以共享模型），并使其更容易通过标准化系统开发流程整合数据和应用程序。MDA中的一个关键思想是平台的概念，以及相应的平台无关性。MDA指南将平台定义为[1]：“......一组子系统和技术，通过接口和特定的使用模式提供一组连贯的功能。. . ” Platform independence means that asystem must be modelled in such a way that the model is inde- pendent 这是模糊的，包括像CORBA、.NET和J2EE这样的平台，当然也可以包括操作系统和编程语言。这种抽象模型被称为平台无关模型（PIM），与包括平台细节的模型相反，即，平台特定模型（PSM）。MDA过程涉及连续的细化。细化步骤一般有两种类型。• 转换（也称为映射），生成一种新的模型，例如，将PIM转换为PSM，或者将PSM转换为可执行代码。这种转换通常会为模型添加细节。通过与精化演算的类比，这些变换通过做出设计决策来减少非确定性，例如，如何表示数据，如何实现消息传递。• 内部细化，是应用于模型的语义保持变换，并且产生相同类型的模型，例如，将PIM细化为新的PIM。整个MDA过程如图所示。1.一、通常，阶段之间的反馈（例如，在PSM和PIM之间）将被获得和使用。 这可能使之成为可能--尽管可能并不可取- 保持PIM和PSM一致，例如，通过逆向工程技术。什么是有效的细化步骤是一个有趣的问题。MDA的思想是，预先定义的转换（用标准的转换语言，QVT [6]）将被应用，以便从PIM到PSM，或者从PSM到代码。自定义（通常是手写的）细化步骤将用于细化特定类型的模型，例如，从PIM到PIM后一种类型的转换通常取决于应用程序上下文。因此，一般来说，假设许多正在应用的转换之前已经被MDA专家验证过，因此可以安全地应用-假设应用转换的规则得到遵守2。然而，这并不能帮助验证自定义、手写2例如，将UML中的多个泛化替换为单个154R.F. Paige等人理论计算机科学电子笔记137（2005）151Fig. 1. MDA连续细化/转型过程但是，对于必须验证要存储在MDA库中的可重用转换的MDA专家来说，2.2MDA中的细化MDA指南在MDA的定义和细化的概念上是模糊的该指南从PIM、PSM和其他模型（如域模型）的角度定义了MDA精化被非正式地定义为转换MDA模型的过程PIM到PSM，PSM到代码，PIM到PIM）。MDA指南将PIM和PSM区分为不同抽象级别的模型，例如，PIM处于比PSM更高的抽象级别。然而，多年来对精化演算和编程方法的研究，特别是对广谱语言的研究，表明这样的区别是没有帮助的：从具有不同属性的规范（或MDA术语，模型）的角度思考更有成效例如，在Hehner的断言编程[ 13 ]中类似地，在摩根要正式定义MDA中的细化，有四种选择。一泛化和委托可能包括一个前提条件，即（a）PIM中存在多个泛化的实例，（b）被泛化的类并非都是抽象的，以及(c)目标语言支持我们正在使用的委托模式的特定实例化R.F. Paige等人理论计算机科学电子笔记137（2005）151155可以翻译MDA中使用的核心语言，即， UML或UML的子集转换成形式语言，如Z、B或规范语句。 已经进行了表达这种翻译的工作，但这都受到限制，例如，不完整性，难以实现一致性等。第二种选择是促进细化的正式定义，例如，最弱的先决条件，并表示它在MDA的条款，例如，在UML中。UML是否适合表达精化的正式定义是有争议的第三种选择出现在催化方法[15]中，是使用UML关联对细化检索关系进行建模。这是有吸引力的和轻量级的，尽管不完整，因为它提供了精化的必要可跟踪性特征，但不提供表示检索关系所需的特定约束;后者需要某种形式的谓词逻辑。第四种选择是根据模型的一致性来定义细化我们将在下一节探讨这一点。3基于一致性的MDA细化定义MDA有两个基本部分：用于表达模型的语言和应用于模型的转换。MDA 中使用的语言通常是基于UML 的，因此是建立在Meta ObjectFacility（MOF）之上的[10]，这是定义语言的核心语言。因此，MDA中使用的转换是根据MOF及其核心结构定义的，例如，类、对象、特征。在MDA中定义精化的严格方法是为MOF提供一个形式化的语义，然后根据这个语义形式化地定义精化。很可能这将是难以使用携带实际的细化和细化步骤;此外，为MOF提供通用的形式语义是具有挑战性的。此外，使用这种通用的形式化语义在基于MOF的语言（如UML）中执行精化可能并不简单，并且需要开发人员不仅使用形式化语义，而且使用MOF来执行精化步骤。与这种严格定义MDA中的精化方法相关的困难是在定义语言之后将形式分析技术附加到半形式语言的典型尝试。由于所使用的语言的分层性质，MDA中的困难可能更加明显，即，UML以MOF的形式定义在MDA中定义细化的另一种可能更轻量级的方法是根据一致的模型来定义它。这是我们在Modelware项目中采用的方法，现在我们概述一下通用技术，156R.F. Paige等人理论计算机科学电子笔记137（2005）151∈∈从一些定义开始。3.1模型一致性模型是感兴趣的现象的表示。表示可以是具体的（例如，写在纸上、画在白板上、屏幕上）或者可以不写（例如，系统模型的视图是从感兴趣的一个角度对系统的显式描述。感兴趣的视角依赖于语言和模型，但典型的视角包括：行为视角、架构视角、用户/利益相关者视角。视图通常捕获系统模型的子集，但情况并非总是如此。例如，在MDA中，PSM的可执行实现是系统模型的视图，但它不是子集，因为它可以完整地执行。在UML中，典型的视图包括结构视图（由类图提供）和行为视图（由状态图提供）。图可以用来表达模型的一个或多个视图;非图形化语言也可以用来捕获视图。图表是用一种语言表达的。语言本身由语法和元模型组成，元模型定义了语言的良构性约束。例如，UML类图的元模型将包含一个约束，声明图中的所有类必须具有唯一的名称。模型的一致性很重要。我们在续集中严格定义了一致性，但非正式地说，一致性模型是至少有一个实现的模型。不一致的模型可能包括错误或遗漏。如果模型是多视图（例如，由UML中的类和通信图组成在序列图中发送的消息实际上不能根据类图发送。我们现在正式定义模型一致性。设L是一种语言，由符号N和元模型MM组成，后者是一组规则。UML的元模型在对象约束语言（OCL）中指定了它的规则。对于任何模型m，我们说m在语言中（写作mL）如果以下两个条件成立。(i) msatN，即，根据语言L的抽象或具体语法规则，m在语法上是有效的。(ii) 对于每个元模型规则r，m和r，即，m满足语言L的每个良构性约束。我们可以对模型一致性使用相同的定义;即，如果m Lm是一致的。这需要两个简单的扩展，如下所示。第一个R.F. Paige等人理论计算机科学电子笔记137（2005）151157----是为了澄清语言L支持多种观点的定义，即，模型M可以使用两个或多个图来表达（语法上），并且这些图可以重叠（语义上）。例如，UML拥有类图和通信图，并且（语义上）这些图可以重叠。我们通过更精确地定义符号N来表达这一点。我们说N是多视图符号，即， 的N =V 1，V 2，...，V n其中每个Vi都是一个有自己语法的图表。 它可以想象--甚至很可能--每个Vi都将导出与图所呈现的视图有关的元模型规则的等价类;我们可以将元模型表示为：MM = R 1，R 2，.，Rn，Rall，其中Ri是与图Vi有关的规则的集合，并且R all是与两个或更多个图有关的规则的集合。R all是多视图一致性规则的集合。 对于现有的语言R来说，所有的规则都可能不是一个完整的规则集，因此我们可能想要添加新的规则。为了扩展规则，我们写道：MM={R1，R2，...， Rn} R所有R新其中R new是一组新的一致性规则;它们是否是特定于域的与一致性检查过程无关3.2一致性规则的类型一般来说，上一节中描述的规则是两种类型之一：结构规则（与用于表示模型的图的结构属性相关）和基于状态的规则（与表示模型的图的状态相关）。后者有时被称为行为规则。结构规则通常不难检查，通常需要检查一个或多个图是否满足元模型中的相关规则考虑一种由类和序列图组成的语言（例如，UML的子集）。这种语言的规则集将包括类和序列图的元模型子集，以及如下所示的一组规则。• 所有类都至少在模型的一个协作图中与一个实例一起出现• 序列图中使用的所有方法和属性都对应于类图中现有的方法;必须有签名匹配。• 如果类A的一个实例调用了序列图中类B的一个方法，这个调用通过依赖关系出现在类图中• 类图中的所有公共方法至少出现在一个序列图中（完整性）一个公共方法不出现在序列158R.F. Paige等人理论计算机科学电子笔记137（2005）151图可能会产生一个带有操作“建议将此方法更改为私有”规则• 参与序列图的对象不是抽象或接口类型。我们可以在OCL中表达这样的规则（以及其他规则），以便执行OCL评估。这个过程非常简单，易于实现。例如，下面的OCL片段实现了上面列表中的第一条规则。package Foundation：：Core context Class--检查所有类是否至少出现在一个--协作图--步骤1：选择模型的所有--步骤2：检查是否至少存在一个实例--在至少一个协作图中，--分类器包括当前类inv出现在协作中：self.model.allContents（）->select（me| me.oclIsTypeOf（协作））-> exists（c| c.oclAsType（协作）.allContents（）-> exists（o| o.oclAsType（Instance）.classifier->includes（self）））端包基于状态的规则更难检查。行为图表（例如，通信图（UML中的通信图）意味着改变参与元素状态的动作和事件序列。因此，模型可能在结构上是一致的，但其状态--其元素的状态- 可能会偏离理想状态从这个角度来看，可以确定两种可能的不一致：• 在行为图中发生动作后，必须检查所有其他视图（即，整个系统）保持一致的状态，即所有元素的不变量保持不变。• 对于与参与的模型元素的不变量相矛盾的操作，可能存在先决条件（守卫）。因此，在正常情况下，这些行动永远不会发生。3.3MDA中的一致性在MDA中，结构化和基于状态的规则不足以完全捕获模型一致性，因为整个系统模型被分成几个部分，例如，PIM和PSM。因此，必须应用上一节中讨论的规则来检查一致性。此外，还必须检查至少另外两种一致性。• PIM和PSM之间的一致性：这种类型的一致性确保了R.F. Paige等人理论计算机科学电子笔记137（2005）151159在从平台无关模型过渡到平台特定模型的过程中，这些信息不会丢失或被误解。在这一类别中，可以应用前面讨论的规则。• PSM与域的一致性：每个域（例如，信息系统、数据库设计）具有不应被打破的特定于领域的规则。由于这些规则可能不直接由建模语言语法强加，因此额外的机制，即， 必须应用原型或元模型细化，以确保它们的应用。因此，对于每个不同的应用程序域，必须检查一组特定于域的规则PIM-PSM一致性可以通过几种方式进行检查。最简单的方法是通过分析来检查一致性，方法与第3.2节中讨论的方法大致相同。换句话说，捕获跨模型一致性规则（例如，使用OCL）。由于这些规则是跨模型的（即，在PIM和PSM概念方面进行了详细说明）。这通常需要一个集成的PIM和PSM元模型来捕获规则。相同的方法可以用于PSM域一致性：域模型（例如，对于数据库）具有元模型和语法，因此可以以与PIM-PSM一致性相同的方式捕获跨模型一致性规则。这进一步证明了PIM、PSM和MDA中的其他模型之间的区别并不总是特别有用。3.4MDA改进是模型一致性我们已经将MDA过程描述为一个连续的细化过程，产生不同类型的模型（例如，PIM、PSM、域）。我们还建议，这些不同类型的模型之间的区别并不总是特别有用。关键思想是，在MDA过程中，模型被定义和修改，产生的新模型必须“细化”错误构建的模型。我们认为，MDA中细化的一个合理的、轻量级的定义就是模型一致性。定义3.1[MDA细化]：在MDA开发的上下文中，如果模型B与A一致，则模型A由模型B细化，即， A和B遵守以下规则。(i) A和B都遵守各自语言的元模型良构规则。(ii) A和B都遵守任何多视图一致性规则（例如，A可以是从类和序列图构造的模型;这些必须是内部一致的）。160R.F. Paige等人理论计算机科学电子笔记137（2005）151(iii) A和B必须遵守与其上下文相关的任何跨模型一致性规则。例如，如果A是PIM，B是PSM，则必须满足与A到B的转换相关的所有PIM-PSM一致性规则。类似地，如果A是PSM，B是域模型，则必须满足所有PSM域一致性规则。这个定义比前面讨论的定义MDA细化的一些替代方案有优势。• 它是轻量级的，并且不需要使用形式化的技术，而形式化的技术虽然是理想的并且适合于解决问题，但可能会让MDA开发人员感到不快。• 它是模块化和可扩展的：不同的应用领域和建模语言可以定义自己的精化概念，同时遵循MDA中固有的相同底层过程和原则集。它也与MDA的转换性质兼容：一致性规则，因此refinements，可以在不同的域中重用。• 它可以使用MDA开发人员应该熟悉和可用的工具来实现（在3.5节中讨论）这种方法的缺点通常与合理性和完整性有关：虽然上述定义是精确的，但它不是正式的，因此不可能检查定义是否合理和完整（即，所有合法的MDA细化都可以用它来表示）。此外，它确实需要大量的工作来建立一个3.5实施MDA细化实现MDA细化的上述定义通常是直接的，尽管它确实需要元建模方面的专业知识。我们在Modelware项目中采用的方法是使用OCL引擎实现一致性规则（包括跨模型一致性规则）。这个OCL引擎提供了一个OCL解析器、类型检查器和规则检查器，这些检查器可以模拟模型中的规则。模型本身是用MOF兼容语言编写的（即，UML的简介规则检查过程是全自动的，如果规则失败，则以开发人员可以理解的方式提供反馈。MDA开发人员是否认为这种方法是可用的和有用的，还有待观察。R.F. Paige等人理论计算机科学电子笔记137（2005）1511614结论我们已经报告了在欧盟综合项目的背景下正在进行的关于模型一致性和制定MDA细化的精确定义的工作我们试图将两者等同起来，以便提供一种轻量级的MDA细化定义，吸引MDA开发人员，同时为设计和实现工具支持提供足够的精度测试将是项目中的工业合作伙伴和更大的MDA社区作为一个整体是否会找到适合他们任务的精化定义，并可用于大规模建模和精化项目。引用[1] 对象管理组，“模型驱动架构官方网站”。网址：http://www.omg.org/mda网站。[2] 对象管理组，官方网站。网址：http://www.omg.org/网站。[3] 巴斯特，W.，A. Kleppe和J. Warmer，[4] Fowler，M.，“平台独立的误用”。网址：http://www.martinfowler.com/bliki/PlatformIndependentMalapropism.html[5] 安布勒，西南， 网址：http://www.sdmagazine.com/documents/s=826/sdm0406e/[6] “Meta Object Facility Queries-Views-Transformations”. 网址：http://neptune.irit.fr/Biblio/qvtspecification.shtml[7] 对象管理组，“XMI规范”。网址：http://www.omg.org/technology/documents/formal/xmi.htm[8] Fowler，M.，模型驱动架构（Model Driven Architecture）网址：http://www.martinfowler.com/bliki/ModelDrivenArchitecture.html网站。[9] Mellor，S.J.， 网址：http://www.omg.org/mda/mdafiles/AgileMDA.pdf网站。[10] 对象管理组，网址：http://www.omg.org/mof/网站。[11] Modelware IST项目，URL：http://www.modelware-ist.org。[12] 对象管理组，网址：http://www.omg.org/uml/网站。[13] 海纳急诊室A Practical Theory of Programming（Second Edition），Springer-Verlag，2003.[14] 摩根，CC， “Programming from Specifications (Second Edition)”, Prentice-Hall,[15] D'Souza，D.，和A. Wills，