Skip to main content
SpringerLink
Log in

Eugenia: towards disciplined and automated development of GMF-based graphical model editors

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

Abstract

EMF and GMF are powerful frameworks for implementing tool support for modelling languages in Eclipse. However, with power comes complexity, implementing a graphical editor for a modelling language using EMF and GMF requires developers to handcraft and maintain several detailed interconnected models through a loosely guided, labour-intensive, and error-prone process. We demonstrate how the application of metamodel annotation and model transformation techniques can help to manage the complexity of GMF and EMF and deliver significant productivity, quality, and maintainability benefits. We present Eugenia, an open-source tool that implements the proposed approach, illustrate its functionality with an example, evaluate it through an empirical study, and report on the community’s response to the tool.

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
Fig. 3
Fig. 4
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
Fig. 19
Fig. 20
Fig. 21
Fig. 22
Fig. 23
Fig. 24

Similar content being viewed by others

Notes

  1. Ecore is the object-oriented metamodelling language of EMF.

  2. http://voelterblog.blogspot.com/2009/06/gmf-is-still-awful.html.

  3. The transformation also supports copying Boolean annotations, but the code for this has been omitted for conciseness.

  4. http://www.eclipse.org/emfatic.

  5. simplem2 stands for simple metamodel.

  6. @namespace is a built-in annotation in Emfatic and is not processed by the transformation.

  7. http://community.bonitasoft.com/blog/customize-your-gmf-editor-customizing-templates.

  8. Additional examples are available on the Epsilon website: http://eclipse.org/epsilon/doc/articles/#eugenia.

  9. http://www.eclipse.org/epsilon/doc/articles/eugenia-gmf-tutorial/.

  10. The complete source code is available under http://dev.eclipse.org/svnroot/modeling/org.eclipse.epsilon/trunk/examples/org.eclipse.epsilon.eugenia.bpmn and http://dev.eclipse.org/svnroot/modeling/org.eclipse.epsilon/trunk/examples/org.eclipse.epsilon.eugenia.bpmn.diagram.custom.

  11. http://www.eclipse.org/epsilon/forum.

  12. https://code.google.com/p/rbcodegen (Last accessed: May 2013).

  13. http://seblog.cs.uni-kassel.de/wp-content/uploads/2011/11/Uebung2.pdf (Last accessed: April 2013).

  14. http://astreo.ii.uam.es/~jlara/doctorado.2010/3_DSLs_tecnologias.pdf (Last accessed: April 2013).

  15. http://www.uio.no/studier/emner/matnat/ifi/INF5120/v11/undervisningsmateriale/Lecture4_ModelTransformation.pdf (Last accessed: April 2013).

  16. http://github.com/chelder86/ArcadeTongame (Last accessed: May 2013).

  17. http://wikis.uca.es/wikiPILI/index.php/Videojuegos_Educativos_DSL (Last accessed: May 2013).

  18. http://www.cs.york.ac.uk/postgraduate/modules/mode.html (Last accessed: February 2014).

  19. http://www-01.ibm.com/software/websphere.

  20. http://www.topcased.org/.

  21. http://www.eclipse.org/papyrus/.

  22. https://code.google.com/a/eclipselabs.org/p/spray.

  23. http://www.moskitt.org.

  24. http://www.eclipse.org/modeling/emft/?project=eef#eef.

  25. http://umlcanvas.org/.

  26. http://www.eclipse.org/epsilon/doc/eugenia/.

  27. For an example involving phantom nodes, the reader can refer to http://eclipse.org/epsilon/doc/articles/eugenia-phantom-nodes/.

References

  1. Hutchinson, J., Whittle, J., Rouncefield, M., Kristoffersen, S.: Empirical assessment of MDE in industry. In: Proceedings of ICSE, pp. 471–480. ACM, New York (2011)

  2. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: EMF: Eclipse Modelling Framework. Eclipse Series, 2nd edn. Addison-Wesley Professional, Reading (2008)

    Google Scholar 

  3. Wienands, C., Golm, M.: Anatomy of a visual domain-specific language project in an industrial context. In: ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems (MoDELS), pp. 453–467, Denver, CO, USA (2009)

  4. Kolovos, D.S., Rose, L.M., Abid, S.Bin., Paige, R.F., Polack, Fiona A.C., Botterweck, G.: Taming EMF and GMF using model transformation. In: Proceedings of the 13th International Conference on Model Driven Engineering Languages and Systems: Part I, MODELS’10, pp. 211–225. Springer, Berlin (2010)

  5. Kolovos, D.S., Paige, R.F., Polack, F.A.C.: The epsilon transformation language. In: Proceedings of 1st International Conference on Model Transformation (ICMT), Zurich, Switzerland (2008)

  6. Eclipse Foundation. Epsilon modeling GMT component. http://www.eclipse.org/gmt/epsilon

  7. Kolovos, D.S., Paige, R.F., Polack, F.A.C.: The epsilon object language. In: Proceedings of European Conference in Model Driven Architecture (EC-MDA) 2006, Volume 4066 of LNCS, pp. 128–142, Bilbao, Spain (2006)

  8. El Kouhen, A., Dumoulin, C., Gerard, S., Boulet, P.: Evaluation of modeling tools adaptation. Technical report, Laboratoire d’Intégration des Systèmes et des Technologies - LIST, LIFL - DART - LIFL - DART, Laboratoire d’Informatique Fondamentale de Lille - LIFL, LIFL - DART/Émeraude (2012)

  9. Baetens, N.: Comparing graphical DSL editors: AToM3, GMF, MetaEdit+. Technical report, University of Antwerp (2011)

  10. Seehusen, F., Stølen, K.: An evaluation of the graphical modeling framework (GMF) based on the development of the CORAS tool. In: Jordi, C., Eelco, V. (eds.) Theory and Practice of Model Transformations, Volume 6707 of Lecture Notes in Computer Science, pp. 152–166. Springer, Berlin (2011)

    Google Scholar 

  11. Sun, Y., Wienands, C., Felser, M.: Applying model-driven design and development to distributed time-triggered systems. In: Proceedings of 2nd International Conference on Engineering and Meta-Engineering (2011)

  12. Dayibas, O., Oguztuzun, H.: Kutulu: A domain-specific language for feature-driven product derivation. In: Computer Software and Applications Conference (COMPSAC), 2012 IEEE 36th Annual, pp. 105–110 (2012)

  13. Demirli, E., Tekinerdogan, B.: Save: software architecture environment for modeling views. In: 2011 9th Working IEEE/IFIP Conference on Software Architecture (WICSA), pp. 355–358 (2011)

  14. Di Ruscio, D., Malavolta, I., Muccini, H., Pelliccione, P., Pierantonio, A.: Developing next generation ADLs through MDE techniques. In: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering—Volume 1, ICSE ’10, pp. 85–94. ACM, New York, NY (2010)

  15. Pena, C., Villalobos, J.: An MDE approach to design enterprise architecture viewpoints. In: 2010 IEEE 12th Conference on Commerce and Enterprise Computing (CEC), pp. 80–87 (2010)

  16. Sun, Y., Gray, J., Bulheller, K., Baillou, N.: A model-driven approach to support engineering changes in industrial robotics software. In: France, R.B., Kazmeier, J., Breu, R., Atkinson, C. (eds.) Model Driven Engineering Languages and Systems, Volume 7590 of Lecture Notes in Computer Science, pp. 368–382. Springer, Berlin Heidelberg (2012)

    Google Scholar 

  17. Noguero, A., Calvo, I.: FTT-Modeler: a support tool for FTT-CORBA. In: 2012 7th Iberian Conference on Information Systems and Technologies (CISTI), pp. 1–6 (2012)

  18. Calvillo, J., Román, I., Roa, L.M.: Empowering citizens with access control mechanisms to their personal health resources. Int. J. Med. Inform. 82(1), 58–72 (2013)

    Article  Google Scholar 

  19. Frantz, R.Z., Reina Quintero, A.M., Corchuelo, R.: A domain specific language to design enterprise application integration solutions. Int. J. Coop. Inf. Syst. 20(02), 143–176 (2011)

    Article  Google Scholar 

  20. García, J., García, F.O., Pelechano, V., Vallecillo, A., Vara, J.M., Vicente-Chicote, C. (eds).: Desarrollo de software dirigido por modelos: conceptos, métodos y herramientas. Ra-Ma (2013)

  21. Williams, J.R., Poulding, S., Rose, L.M., Paige, R.F., Polack, F.A.C.: Identifying Desirable Game Character Behaviours Through the Application of Evolutionary Algorithms to Model-Driven Engineering Metamodels, vol. 6956. Springer, Berlin (2011)

    Google Scholar 

  22. García-Domínguez, A., Kolovos, D.S., Rose, L.M., Paige, R.F.: Inmaculada Medina-Bulo. EUnit: a unit testing framework for model management tasks. In: Proceedings of the 14th International Conference on Model Driven Engineering Languages and Systems, MODELS’11, pp. 395–409. Springer, Berlin (2011)

  23. Schnepel, E.: GenGMF: efficient editor development for large meta models using the graphical modelling framework. In: Proceedings of special interest group on model-driven software engineering (SIG-MDSE) (2008)

  24. Temate, S., Broto, L., Tchana, A., Hagimont, D.: A high level approach for generating model’s graphical editors. In: 2011 Eighth International Conference on Information Technology: New Generations (ITNG), pp. 743–749 (2011)

  25. MetaCase. Meta-Edit+. http://www.metacase.com

  26. Generic Modeling Environment. http://www.isis.vanderbilt.edu/Projects/gme

  27. De Lara, J., Vangheluwe, H.: Using AToM3 as a meta-CASE tool. In: Proceedings of 4th International Conference on Enterprise Information Systems, pp. 642–649, Ciudad Real - Spain (2002)

Download references

Acknowledgments

Parts of this work were supported by the European Commission’s Seventh Framework Programme, through Grant #611125 (MONDO). Other parts of this work were supported by the doctoral scholarship PU-EPIF-FPI-C 2010-065 from the University of Cádiz and by the MoDSOA Project (TIN2011-27242) of the National Research, Development and Innovation Program of the Spanish Ministry of Science and Innovation. The authors would also like to thank Adolfo Sanchez-Barbudo Herrera and Horacio Hoyos Rodriguez for their help with the evaluation experiments discussed in Sect. 5.

Author information

Authors and Affiliations

  1. University of York, York, UK

    Dimitrios S. Kolovos, Louis M. Rose & Richard F. Paige

  2. University of Cádiz, Cádiz, Spain

    Antonio García-Domínguez

Authors
  1. Dimitrios S. Kolovos
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Antonio García-Domínguez
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Louis M. Rose
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Richard F. Paige
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Dimitrios S. Kolovos.

Additional information

Communicated by Dr. Juha-Pekka Tolvanen.

Appendix: List of annotations supported by Eugenia

Appendix: List of annotations supported by Eugenia

The complete list of metamodel annotations currently supported by Eugenia is given below. Features of GMF that are not made available via annotations can be managed using the polishing transformation mechanism. An up-to-date reference guide to the annotations of Eugenia is available on the Epsilon website.Footnote 26

1.1 gmf.diagram

Denotes the root EClass for the editor. Only one (non-abstract) EClass must be annotated as gmf.diagram. The annotation accepts the following details.

  • diagram.extension (optional): the file extension for the diagram file;

  • model.extension (optional): the file extension for the domain (EMF) model;

  • onefile (optional): specifies whether the domain model and the diagram should be stored in the same file;

  • rcp (optional): specifies whether the editor is intended to be part of a Rich Client Platform product;

  • units (optional): the units for the diagram (e.g. Pixels).

1.2 gmf.node

Applies to an EClass and denotes that its instances should appear on the diagram as nodes. The annotation accepts the following details.

  • figure (optional): the figure that will represent the node. Can be set to rectangle, ellipse, rounded (default), svg (see svg.uri), polygon (see polygon.x and polygon.y) or to the fully qualified name of a Java class that implements the GMF Figure interface;

  • border.color (optional): an RGB color (e.g. 255, 0, 0) that will be set as the node’s border color;

  • border.style (optional): the style of the node’s border. Can be set to solid (default), dash or dot;

  • border.width (optional): an integer that specifies the width of the node’s border;

  • color (optional): an RGB color that specifies the node’s background color;

  • label: the name(s) of the EAttribute(s) of the EClass, the value(s) of which will be displayed as the label of the node. If label.placement is set to none, this detail is not required;

  • label.icon (optional): if set to true (default), a small icon appears on the left of the label;

  • label.parser (optional): indicates the unqualified name of the class that will parse the text entered by the user into the label;

  • label.edit.pattern (optional): similar to label.pattern, but only for editing the label;

  • label.pattern (optional): if more than one attributes are specified in the label, the format detail is necessary to specify how their values will be rendered in the label. The format follows the Java Message Format style (e.g. {0} : {1}). The same pattern is used for editing and viewing the label.

  • label.view.pattern (optional): similar to label.pattern, but only for viewing the label;

  • label.placement (optional): defines the placement of the label in relation to the node. Can be set to internal, external, or none (in which case, no label will be shown);

  • label.text (optional): defines the default text to be used when the EAttribute(s) in label are not set. By default, it is set to the name of the EClass;

  • label.readOnly (optional): a value of true denotes that the label cannot be changed in the generated diagram editor;

  • margin (optional): inset margin (5 units by default) for the node;

  • phantom (optional): defines if the node is phantom (true/false). Phantom nodes are particularly useful in order to visualise containment references using links instead of spatial containment;Footnote 27

  • polygon.x (when figure is set to polygon): list of space-separated integers with the X coordinates of the polygon used as figure;

  • polygon.y (when figure is set to polygon): list of space-separated integers with the Y coordinates of the polygon used as figure;

  • resizable (optional): a value of false disables all the resize handles for the node;

  • size (optional): a GMF dimension that will be used as the node’s preferred size (e.g. 10, 5);

  • svg.uri (when figure is set to svg): URI of the .svg file to be used as figure for the node. For instance, platform:/plugin/my.plugin/my.svg will access the my.svg file in the my.plugin plugin.

1.3 gmf.link

Applies to EClasses that should appear on the diagram as links, and to non-containment EReferences.

1.4 gmf.link (for EClasses)

The annotation accepts the following details.

  • color (optional): the RGB color of the link;

  • incoming (optional): specifies whether the generated editor should allow links to be created from target to source. Defaults to false;

  • label (optional): the names of the EAttributes of the EClass the value of which will be displayed as the label of the link;

  • label.parser (optional): indicates the unqualified name of the class that will parse the text entered by the user into the label;

  • label.text (optional): defines the default text to be used when the EAttribute(s) in label are not set. By default, it is set to the name of the EClass;

  • source: the source non-containment EReference of the link;

  • source.constraint (optional): OCL assertion that should be checked by the graphical editor when creating a link. For instance, \(\mathtt{self <> oppositeEnd}\) would forbid users for creating a link from a node to itself (a self-loop): self is the source of the link, and oppositeEnd is the target of the link;

  • source.decoration (optional): the decoration of the source end of the link. Can be set to none, arrow, rhomb, filledrhomb, square, filledsquare, closedarrow, filledclosedarrow, or the fully qualified name of a Java class that implements the org.eclipse.draw2d.RotatableDecoration interface;

  • style (optional): the style of the link (see border.style above);

  • target : the target non-containment EReference of the link;

  • target.constraint (optional): See source.constraint;

  • target.decoration (optional): See source.decoration;

  • width (optional): the width of the link.

1.5 gmf.link (for non-containment EReferences)

It accepts the following details:

  • color (optional): the RGB color of the link;

  • label (optional): the static text that will be displayed as the label of the link. If no label is specified, the name of the reference is displayed instead;

  • label.text (optional): equivalent to label in this case;

  • source.decoration (optional): See source.decoration above;

  • style (optional): the style of the link (see border.style above);

  • target.decoration (optional): as above;

  • width (optional): the width of the link.

1.6 gmf.compartment (for containment EReferences)

Defines that the containment reference will create a compartment where model elements that conform to the type of the reference can be placed. It accepts the following details:

  • collapsible (optional): when set to false, it prevents the compartment from collapsing (default is true);

  • layout (optional): the layout of the compartment. Can be set to free (default) or list.

1.7 gmf.affixed (for containment EReferences)

Defines that the containment reference will create nodes which are affixed to the edges of the containing node. An example demonstrating affixed references is illustrated in Sect. 5.

1.8 gmf.label (for EAttributes)

Defines additional labels for the containing EClass. These labels will be displayed underneath the default label for the containing EClass. It accepts the following details:

  • label.edit.pattern (optional): like label.pattern, but only for editing the label;

  • label.parser (optional): indicates the unqualified name of the class that will parse the text entered by the user into the label;

  • label.pattern (optional): if more than one attributes are specified in the label, the format detail is necessary to show how their values will be rendered in the label. The format follows the Java Message Format style (e.g. 0: 1). The same pattern is used for editing and viewing the label;

  • label.readOnly (optional): a value of true denotes that the label cannot be changed in the generated diagram editor;

  • label.text (optional): defines the default text to be used when the attribute is not set;

  • label.view.pattern (optional): similar to label.pattern, but only for viewing the label.

All gmf.node and gmf.link annotations also support the following details which can be used to define the appearance of the respective palette tools of the editor.

  • tool.description (optional): the description of the creation tool.

  • tool.large.bundle (optional): the bundle of the large icon of the creation tool.

  • tool.large.path (optional): the path of the large icon of the creation tool.

  • tool.name (optional): the name of the creation tool.

  • tool.small.bundle (optional): the bundle of the small icon of the creation tool.

  • tool.small.path (optional): the path of the small icon of the creation tool.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Kolovos, D.S., García-Domínguez, A., Rose, L.M. et al. Eugenia: towards disciplined and automated development of GMF-based graphical model editors. Softw Syst Model 16, 229–255 (2017). https://doi.org/10.1007/s10270-015-0455-3

Download citation

  • Received:

  • Revised:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10270-015-0455-3

Keywords

Search

Navigation