On challenges of model transformation from UML to Alloy

Abstract

The Unified Modeling Language (UML) is the de facto language used in the industry for software specifications. Once an application has been formally specified, Model Driven Architecture (MDA) techniques can be applied to generate code from such specifications. Since implementing a system based on a faulty design requires additional cost and effort, it is important to analyse the UML models at earlier stages of the software development lifecycle. This paper focuses on utilizing MDA techniques to deal with the analysis of UML models and identify design faults within a specification. Specifically, we show how UML models can be automatically transformed into Alloy which, in turn, can be automatically analysed by the Alloy Analyzer. The proposed approach relies on MDA techniques to transform UML models to Alloy. This paper reports on the challenges of the model transformation from UML class diagrams and OCL to Alloy. Those issues are caused by fundamental differences in design philosophy of UML and Alloy. To facilitate better representation of Alloy concepts in the UML, the paper draws on the lessons learnt and presents a UML profile for Alloy.

Agile validation of model transformations using compound F-Alloy specifications

“…Alloy modules can also be exploited to specify model transformations [2,4]. In this paper we focus on the study of exogenous model transformations [20] that take one source model as input and produce one target model as output.…”

“…In the context of model driven software engineering, Alloy and its accompanying tool the Alloy Analyzer have been used to validate properties of models [1,6] and model transformations [2,4]. However, the analysis of model transformation specifications expressed in Alloy has some important limitations.…”

An OCL-Based Framework for Model Transformations

“…Many other works focus on the translation of the transformation to a formal domain for model checking such as Alloy in [21], Promela in [22], and Maude in [23].…”

From UML and OCL to Relational Logic and Back

“…First, this operation creates a binary relation via comprehension which relates each element of the source collection to the evaluation result of the respective body expression. For instance, the OCL expression Set{1,2,3}->collect(i|i*i) would yield the intermediate relation [ [1,1], [2,4], [3,9]]. The transformation respects the fact that the result of collect must be flattened.…”

“…This approach allows us to explicitly benefit from the efficient handling of relational logic in Kodkod. While explaining the transformation, we focus on important modeling aspects and concepts which have not been concerned or adequately treated in other UML and OCL model validation approaches based on relational logic [1,27], e. g., n-ary associations and association classes at the UML side, as well as the undefined value and essential operations like collect and navigation via n-ary associations and association classes at the OCL side. This transformation approach is supported by a tool classified as a model validator which processes a class diagram and OCL invariants as well as information (in form of partial object diagrams and properties like the minimum and maximum number of objects and links, or attribute value domains) determining the search space, that is, the set of model instances to be examined.…”