Skip to main content
SpringerLink
Log in

F-Alloy: a relational model transformation language based on Alloy

  • Special Section Paper
  • Published:
Software & Systems Modeling Aims and scope Submit manuscript

Abstract

Model transformations are one of the core artifacts of a model-driven engineering approach. The relational logic language Alloy has been used in the past to verify properties of model transformations. In this paper we introduce the concept of functional Alloy modules. In essence a functional Alloy module can be viewed as an Alloy module representing a model transformation. We describe a sublanguage of Alloy called F-Alloy specifically designed to concisely specify functional Alloy modules. The restrictions on F-Alloy’s syntax are meant to allow efficient execution of the specified transformation, without the use of backtracking, by an adapted interpretation algorithm. F-Alloy’s semantics is given in this paper as a direct translation to Alloy; hence, F-Alloy specifications are also analyzable using the powerful automatic analysis features of Alloy.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2

(adapted from [6])

Fig. 3

(adapted from [6])

Fig. 4

(adapted from [10])

Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13
Fig. 14
Fig. 15
Fig. 16
Fig. 17
Fig. 18

Similar content being viewed by others

Notes

  1. http://lightning.gforge.uni.lu.

  2. Stands for Functional Alloy as it is used to specify functions.

  3. The notion of persistence is abstracted away and the naming of column make abstractions of inheritance.

  4. ~association is the inverse relation of association mapping an AssociationClass to an Association. The expression a.~association hence returns the AssociationClass adorning association a.

  5. \(\hat{}R\) returns the smallest relation \(R'\) containing R and being transitive, while \(^*R\) returns the smallest relation \(R'\) containing R and being both transitive and reflexive.

  6. We have omitted the constraints that express multiplicities and disjointedness in \(\varphi \)—e.g., that each table should have at least one column, or that no two RDBMSElement should have the same name.

  7. We relax here the Alloy terminology in which instance usually means valid instance.

  8. With the possibility that \( m_{\mathrm{src}} = m_{\mathrm{dst}} \).

  9. At index 0 as name is declared as a sequence of string.

  10. http://alloy.mit.edu/alloy/documentation/alloy-api/index.html.

  11. https://goo.gl/fyvqRg.

  12. https://projects.eclipse.org/projects/modeling.mmt.qvtd.

  13. We note that this is not the case anymore since the release of the ATL 2009 compiler.

  14. http://lightning.gforge.uni.lu/examples.

References

  1. Akehurst, D.H., Kent, S., Patrascoiu, O.: A relational approach to defining and implementing transformations between metamodels. Softw. Syst. Model. 2, 215–239 (2003)

    Article  Google Scholar 

  2. Anastasakis, K., Bordbar, B., Georg, G., Ray, I.: On challenges of model transformation from UML to Alloy. Softw. Syst. Model. 9, 69–86 (2010)

    Article  Google Scholar 

  3. Anastasakis, K., Bordbar, B., Küster, J.M.: Analysis of model transformations via Alloy. In: Proceedings of the 4th MoDeVVa Workshop: Model-Driven Engineering, Verification, and Validation, pp. 47–56 (2007)

  4. Arendt, T., Biermann,E., Jurack, S., Krause, C., Taentzer, G.: Henshin: advanced concepts and tools for in-place emf model transformations. In: Model Driven Engineering Languages and Systems, pp. 121–135 (2010)

  5. Baresi, L., Spoletini, P.: On the use of Alloy to analyze graph transformation systems. In: Graph Transformations, pp. 306–320 (2006)

  6. Bézivin, J., Rumpe, B., Schürr, A., Tratt, L.: Model transformations in practice workshop. In: Satellite Events at the MoDELS 2005 Conference, pp. 120–127 (2006)

  7. Czarnecki, K., Helsen, S.: Classification of model transformation approaches. In: Proceedings of the 2nd OOPSLA Workshop on Generative Techniques in the Context of the Model Driven Architecture, pp. 1–17 (2003)

  8. Gammaitoni, L., Kelsen, P.: F-Alloy: an Alloy based model transformation language. In: Theory and Practice of Model Transformations, pp. 166–180 (2015)

  9. Gammaitoni, L., Kelsen, P., Glodt, C.: Designing languages using lightning. In: International Conference on Software Language Engineering, pp. 77–82 (2015)

  10. Gammaitoni, L., Kelsen, P., Ma, Q.: Agile validation of higher order transformations using F-Alloy. In: 2016 10th International Symposium on Theoretical Aspects of Software Engineering (TASE), pp. 125–131. IEEE (2016)

  11. Gammaitoni, L., Kelsen, P., Mathey, F.: Verifying modelling languages using lightning: a case study. In: 11th MoDeVVa Workshop: Model-Driven Engineering, Verification and Validation, pp. 19–28 (2014)

  12. Georg, G., Bieman, J., France, R.B.: Using Alloy and UML/OCL to specify run-time configuration management: a case study. In: pUML, pp. 128–141. Citeseer (2001)

  13. Gerber, A., Lawley, M., Raymond, K., Steel, J., Wood, A.: Transformation: the missing link of MDA. In: Graph Transformation, pp. 90–105 (2002)

  14. Giese, H., Hildebrandt, S., Lambers, L.: Toward bridging the gap between formal semantics and implementation of triple graph grammars. In: Proceeding of the 7th MoDeVVa Workshop: Model-Driven Engineering, Verification, and Validation, pp. 19–24 (2010)

  15. Hermann, F., Ehrig, H., Orejas, F., Golas, U.: Formal analysis of functional behaviour for model transformations based on triple graph grammars. In: International Conference on Graph Transformation, pp. 155–170. Springer (2010)

  16. Jackson, D.: Software Abstractions. MIT Press, Cambridge (2012)

    Google Scholar 

  17. Jouault, F., Allilaire, F., Bézivin, J., Kurtev, I.: ATL: a model transformation tool. Sci. Comput. Program. 72, 31–39 (2008)

    Article  MathSciNet  MATH  Google Scholar 

  18. Katebi, H., Sakallah, K.,A., Marques-Silva, J.: Empirical study of the anatomy of modern sat solvers, volume 6695 LNCS of Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), pp. 343–356 (2011)

  19. Lano, K.: Catalogue of model transformations. Available at: https://nms.kcl.ac.uk/kevin.lano/tcat.pdf

  20. Lightning tool website. http://lightning.gforge.uni.lu

  21. Macedo, N., Cunha, A.: Implementing QVT-R bidirectional model transformations using Alloy. In: Fundamental Approaches to Software Engineering, pp. 297–311 (2013)

  22. Mens, T., Van Gorp, P.: A taxonomy of model transformation. Electron. Notes Theor. Comput. Sci. 152, 125–142 (2006)

    Article  Google Scholar 

  23. OMG. Meta object facility query/view/transformation specification (2011)

  24. Schürr, A.: Specification of graph translators with triple graph grammars. In: Proceedings of the 20th International Workshop on Graph-Theoretic Concepts in Computer Science (WG ’94), Herrsching. Springer (1995)

  25. Schürr, A.: Specification of graph translators with triple graph grammars. In: Graph-Theoretic Concepts in Computer Science, pp. 151–163 (1995)

  26. Schürr, A., Klar, F.: 15 years of triple graph grammars. In: Graph Transformations, pp. 411–425 (2008)

  27. Steinberg, D., Budinsky, F., Merks, E., Paternostro, M.: EMF: Eclipse Modeling Framework. Pearson Education, London (2008)

    Google Scholar 

  28. Taghdiri, M., Jackson, D.: A lightweight formal analysis of a multicast key management scheme. In: International Conference on Formal Techniques for Networked and Distributed Systems, pp. 240–256. Springer (2003)

  29. Tisi, M., Martínez, S., Jouault, F., Cabot, J.: Refining models with rule-based model transformations. PhD dissertation, INRIA (2011)

  30. Troya, J., Vallecillo, A.: A rewriting logic semantics for ATL. J. Object Technol. 10, 1–29 (2011)

    Article  Google Scholar 

  31. Van Deursen, A., Klint, P., Visser, J.: Domain-specific languages: an annotated bibliography. ACM Sigplan Not. 35(6), 26–36 (2000)

    Article  Google Scholar 

Download references

Author information

Authors and Affiliations

  1. University of Luxembourg, Esch-sur-Alzette, Luxembourg

    Loïc Gammaitoni & Pierre Kelsen

Authors
  1. Loïc Gammaitoni
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Pierre Kelsen
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Loïc Gammaitoni.

Additional information

Communicated by Prof. Alfonso Pierantonio, Jasmin Blanchette, Francis Bordeleau, Nikolai Kosmatov, Prof. Gabriele Taentzer, Prof. Manuel Wimmer.

F-Alloy to Alloy translation procedures

F-Alloy to Alloy translation procedures

In this appendix, we provide procedures in pseudocode describing how each type of constraint identified in Sect. 7 is automatically generated.

We recall that the notation in which the pseudocode is provided has the following properties:

  • Keywords structuring the code are highlighted in bold and are written in uppercase.

  • Variables names are highlighted in bold and are written in lowercase.

  • Text and numbers are highlighted in italic.

  • Function names (in declarations and in calls) are highlighted in bold and italic.

  • Expressions of the form “WITH var: description” consists in providing a syntactic description of the variable, consisting of syntactical constructs and terminals. Each syntactical construct counts as a variable declaration, the variable being initialized following the value of the described variable var. Each of such “syntactic variable” is highlighted in blue, to differentiate them from terminals and other possibly already defined variables.

1.1 Map disjunction

The Map Disjunction function, given in Listing 9, first identifies (via nested loops) each pair of mappings (different from one another) having ranges typed by the same signature. For each such pair, a constraint is written enforcing that the intersection between atoms in the range of those mappings is empty, i.e., no disjoint mappings have overlapping ranges.

figure am

1.2 Map injectiveness

The Map Injectiveness function, given in Listing 10, iterates over each mapping declared in the f-module and writes an Alloy constraint enforcing that each element in the range of a given map has at most one preimage.

figure an

1.3 Predicate association

The Predicate Association function , given in Listing 11, iterates over all mappings declared in the f-module and writes an Alloy constraint enforcing that for each mapping, each combination of atoms typed after the domain of the mapping is mapped to an atom in the range if and only if the said combination satisfies the guard. Also, the value predicate should be satisfied given as parameters the satisfying combination of domain atoms and their associated atom in the range.

As delete mappings do not have range, the function simply writes an Alloy expression that ensures that combinations of atoms in the domain are to be part of the delete mapping if and only if they satisfy the guard.

figure ao

1.4 Minimal assignment

The Minimal Assignment function, given in Listing 13, iterates over maps declared in the f-module. For each map, it iterates over fields declared in the signature typing its range. It then writes a constraint limiting the cardinality of that field to be that expected from the assignment defined by strict and step rules of the associated value predicate and by loose rules of other value predicates. To do so, it relies on the COUNT function which returns an Alloy expression yielding the expected cardinality.

figure ap
figure aq

1.5 IO disjunction

The IO disjunction function iterates (via nested loops) over pairs of mappings (not forcibly different) and writes an Alloy expression ensuring that the domain of one is disjoint from the range of the other.

figure ar

1.6 Constraint framing

The first part of the Constraint Framing function, given in Listing 15, writes two Alloy expressions defining the set of atoms contained in the input and output instance of the f-module, respectively.

The second part rewrites facts of the input module as predicates and writes in a fact of the translated f-module an Alloy expression enforcing those predicates to hold given the set of all input and output atoms as parameters, respectively.

figure as

1.7 Minimum output

The Minimum Output function, given in Listing 16, iterates over all signatures declared in the output module and writes an Alloy expression enforcing the set of all atoms typed by each of these signatures to be equal to the union of atoms in the range of mappings whose range is typed by the given signature.

figure at

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Gammaitoni, L., Kelsen, P. F-Alloy: a relational model transformation language based on Alloy. Softw Syst Model 18, 213–247 (2019). https://doi.org/10.1007/s10270-017-0630-9

Download citation

  • Received:

  • Revised:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10270-017-0630-9

Keywords

Search

Navigation