The document describes MoDiGen, a model-driven approach for generating graphical editors in Eclipse. MoDiGen uses three domain-specific languages - MoDiGen Core, Shape, and Style - as inputs to a generator. The generator produces Java code, XML files, and properties to implement a graphical editor as an Eclipse plugin. The languages allow defining node and edge diagrams, complex shapes, and styles. When the DSL models are saved, code generation is triggered to build the graphical editor. The approach aims to reduce the effort of developing graphical modeling tools compared to manually coding editors in Eclipse frameworks.
PYFML- A TEXTUAL LANGUAGE FOR FEATURE MODELINGijseajournal
The Feature model is a typical approach to capture variability in a software product line design and implementation. For that, most works automate feature model using a limited graphical notation represented by propositional logic and implemented by Prolog or Java programming languages. These works do not properly combine the extensions of classical feature models and do not provide scalability to implement large size problem issues. In this work, we propose a textual feature modeling language based on Python programming language (PyFML), that generalizes the classical feature models with instance feature cardinalities and attributes which be extended with highlight of replication and complex logical and mathematical cross-tree constraints. textX Meta-language is used for building PyFML to describe and organize feature model dependencies, and PyConstraint Problem Solver is used to implement feature model variability and its constraints validation. The work provides a textual human-readable language to represent feature model and maps the feature model descriptions directly into the object-oriented representation to be used by Constraint Problem Solver for computation. Furthermore, the proposed PyFML makes the notation of feature modeling more expressive to deal with complex software product line representations and using PyConstraint Problem Solver.
When talking about modeling, I think there will be a bundle of terms that will come to our mind, UML, domain driven development, DSL, forward/reverse enginerring, MDD, MDA, BPMN. These technology or methodology have been there for years; And obviously, modeling has proven itself to provide value by improving communication, business-alignment, quality, and productivity. Its applicability includes a number of disciplines such as analysis, design, or development. But why aren’t we all doing Model Driven Development yet?
Evolution in the Large and in the Small in Model-Driven DevelopmentAlfonso Pierantonio
Model Driven Engineering (MDE) is increasingly gaining acceptance in the development of software systems as a mean to leverage abstraction and render business logic resilient to technological changes. Coordinated collections of models and modeling languages are used to describe
applications on different abstraction levels and from different perspectives. In general, both models and metamodels are not preserved from the evolutionary pressure which inevitably affects almost any artifacts, possibly causing a cascade of adaptations which severely affects the modeling languages or the model population.
This talk analyzes the different kinds of co-adaptations which are required, distinguishing among co-evolution in the large and in the small. In particular, the coupling between models and metamodels implies that when a metamodel undergoes a modification, the conforming models require to be accordingly co-adapted. Analogously, whenever a new version of a model is produced, the generated application may require an explicit adaptation of the generated artifacts, especially when specific
assets are not directly reflected by the models and transformations, as for instance when dealing with serialized objects or with page content which is persistently stored in a database.
PYFML- A TEXTUAL LANGUAGE FOR FEATURE MODELINGijseajournal
The Feature model is a typical approach to capture variability in a software product line design and implementation. For that, most works automate feature model using a limited graphical notation represented by propositional logic and implemented by Prolog or Java programming languages. These works do not properly combine the extensions of classical feature models and do not provide scalability to implement large size problem issues. In this work, we propose a textual feature modeling language based on Python programming language (PyFML), that generalizes the classical feature models with instance feature cardinalities and attributes which be extended with highlight of replication and complex logical and mathematical cross-tree constraints. textX Meta-language is used for building PyFML to describe and organize feature model dependencies, and PyConstraint Problem Solver is used to implement feature model variability and its constraints validation. The work provides a textual human-readable language to represent feature model and maps the feature model descriptions directly into the object-oriented representation to be used by Constraint Problem Solver for computation. Furthermore, the proposed PyFML makes the notation of feature modeling more expressive to deal with complex software product line representations and using PyConstraint Problem Solver.
When talking about modeling, I think there will be a bundle of terms that will come to our mind, UML, domain driven development, DSL, forward/reverse enginerring, MDD, MDA, BPMN. These technology or methodology have been there for years; And obviously, modeling has proven itself to provide value by improving communication, business-alignment, quality, and productivity. Its applicability includes a number of disciplines such as analysis, design, or development. But why aren’t we all doing Model Driven Development yet?
Evolution in the Large and in the Small in Model-Driven DevelopmentAlfonso Pierantonio
Model Driven Engineering (MDE) is increasingly gaining acceptance in the development of software systems as a mean to leverage abstraction and render business logic resilient to technological changes. Coordinated collections of models and modeling languages are used to describe
applications on different abstraction levels and from different perspectives. In general, both models and metamodels are not preserved from the evolutionary pressure which inevitably affects almost any artifacts, possibly causing a cascade of adaptations which severely affects the modeling languages or the model population.
This talk analyzes the different kinds of co-adaptations which are required, distinguishing among co-evolution in the large and in the small. In particular, the coupling between models and metamodels implies that when a metamodel undergoes a modification, the conforming models require to be accordingly co-adapted. Analogously, whenever a new version of a model is produced, the generated application may require an explicit adaptation of the generated artifacts, especially when specific
assets are not directly reflected by the models and transformations, as for instance when dealing with serialized objects or with page content which is persistently stored in a database.
Revisiting all aspects of model-driven engineering (application, teaching, verification , tooling, research,...) promoting a lightweight perspective to maximize MDE success and adoption
Model driven software engineering in practice book - chapter 7 - Developing y...Marco Brambilla
Slides for the mdse-book.com - Chapter 7: Developing Your Own Modeling Language.
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
Model-Driven Software Engineering in Practice - Chapter 1 - IntroductionMarco Brambilla
Slides for the mdse-book.com chapter 1: Introduction
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Model-Driven Development of Web Applicationsidescitation
Over the last few years Model-Driven Development (MDD) has been regarded as
the future of Software Engineering, offering architects the possibility of creating artifacts to
illustrate the design of the software solutions, contributing directly to the implementation of
the product after performing a series of model transformations on them. The model-to-text
transformations are the most important operations from the point of view of the automatic
code generation. The automatic generation or the fast prototyping of applications implies an
acceleration of the development process and a reduction of time and effort, which could
materialize in a noticeable cost reduction. This paper proposes a practical approach for the
model-based development of web applications, offering a solution for the layered and
platform independent modeling of web applications, as well as for the automatic generation
of software solutions realized using the ASP.NET technology.
Model-Driven Software Engineering in Practice - Chapter 4 - Model-Driven Arch...Jordi Cabot
Slides for the mdse-book.com chapter 4: MODEL DRIVEN ARCHITECTURE (MDA)
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Our research lines on Model-Driven Engineering and Software EngineeringJordi Cabot
Highlighting some of our research lines (March 2015 Edition)
Learn more about what we do on : http://modeling-languages.com , http://som-research.uoc.edu and http://jordicabot.com
Explicating and Reasoning with Model Uncertainty by Marsha Chechik (ECMFA'14 ...Jordi Cabot
Slides of Marsha Chechik´s Keynote at the European Conference on Modelling Foundations and Applications 2014.
Marsha´s webpage: http://www.cs.toronto.edu/~chechik/
ECMFA webpage: http://ecmfa2014.lcc.uma.es/
Model-Driven Software Engineering in Practice - Chapter 2 - MDSE PrinciplesMarco Brambilla
Slides for the mdse-book.com chapter 2: Model-driven Software Engineering Principles.
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Model-Driven Software Engineering in Practice - Chapter 10 - Managing modelsJordi Cabot
Slides for the mdse-book.com chapter 10: Managing models
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Model-Driven Software Engineering in Practice - Chapter 8 - Model-to-model tr...Jordi Cabot
Slides for the mdse-book.com chapter 8: model-to-model transformations
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Model driven software engineering in practice book - Chapter 9 - Model to tex...Marco Brambilla
Slides for the mdse-book.com chapter 9 - Model-to-text transformations.
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The book is organized into two main parts.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers a wide set of introductory and technical topics, spanning MDE at large, definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, A
Revisiting all aspects of model-driven engineering (application, teaching, verification , tooling, research,...) promoting a lightweight perspective to maximize MDE success and adoption
Model driven software engineering in practice book - chapter 7 - Developing y...Marco Brambilla
Slides for the mdse-book.com - Chapter 7: Developing Your Own Modeling Language.
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
Model-Driven Software Engineering in Practice - Chapter 1 - IntroductionMarco Brambilla
Slides for the mdse-book.com chapter 1: Introduction
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Model-Driven Development of Web Applicationsidescitation
Over the last few years Model-Driven Development (MDD) has been regarded as
the future of Software Engineering, offering architects the possibility of creating artifacts to
illustrate the design of the software solutions, contributing directly to the implementation of
the product after performing a series of model transformations on them. The model-to-text
transformations are the most important operations from the point of view of the automatic
code generation. The automatic generation or the fast prototyping of applications implies an
acceleration of the development process and a reduction of time and effort, which could
materialize in a noticeable cost reduction. This paper proposes a practical approach for the
model-based development of web applications, offering a solution for the layered and
platform independent modeling of web applications, as well as for the automatic generation
of software solutions realized using the ASP.NET technology.
Model-Driven Software Engineering in Practice - Chapter 4 - Model-Driven Arch...Jordi Cabot
Slides for the mdse-book.com chapter 4: MODEL DRIVEN ARCHITECTURE (MDA)
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Our research lines on Model-Driven Engineering and Software EngineeringJordi Cabot
Highlighting some of our research lines (March 2015 Edition)
Learn more about what we do on : http://modeling-languages.com , http://som-research.uoc.edu and http://jordicabot.com
Explicating and Reasoning with Model Uncertainty by Marsha Chechik (ECMFA'14 ...Jordi Cabot
Slides of Marsha Chechik´s Keynote at the European Conference on Modelling Foundations and Applications 2014.
Marsha´s webpage: http://www.cs.toronto.edu/~chechik/
ECMFA webpage: http://ecmfa2014.lcc.uma.es/
Model-Driven Software Engineering in Practice - Chapter 2 - MDSE PrinciplesMarco Brambilla
Slides for the mdse-book.com chapter 2: Model-driven Software Engineering Principles.
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Model-Driven Software Engineering in Practice - Chapter 10 - Managing modelsJordi Cabot
Slides for the mdse-book.com chapter 10: Managing models
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Model-Driven Software Engineering in Practice - Chapter 8 - Model-to-model tr...Jordi Cabot
Slides for the mdse-book.com chapter 8: model-to-model transformations
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
Model driven software engineering in practice book - Chapter 9 - Model to tex...Marco Brambilla
Slides for the mdse-book.com chapter 9 - Model-to-text transformations.
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The book is organized into two main parts.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers a wide set of introductory and technical topics, spanning MDE at large, definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, A
DOOML: A NEW DATABASE & OBJECT-ORIENTED MODELING LANGUAGE FOR DATABASE-DRIVEN...ijseajournal
A database driven web application is a very common software solution to rising business problems.
Modeling the database and the software architecture can be challenging, hence there not being one
combined modeling language for database and software architecture, specifically suited for web
application development. In this paper we present Database object-oriented Modeling Language (DooML)
and its primary Archetype Diagram: a notation for specifying the design of a database schema and
corresponding object-oriented software architecture. It combines the syntax for drawing Entity
Relationship Diagrams, the Relational Model and Universal Modeling Language Class Diagrams as well
to create a mixed diagram, stating database design as well as software design specifications. By default,
DooML ensures that the approach of advanced web application development is model-driven and both
database-oriented as well as object-oriented.
DOOML: A New Database & Object-Oriented Modeling Language for Database-Driven...ijseajournal
Submit your Research Articles!!
International Journal of Software Engineering & Applications(IJSEA)
ISSN:0975-3834 [Online]; 0975-4679 [Print]
ERA Indexed, H Index 31
Web Page URL : https://airccse.org/journal/ijsea/ijsea.html
Issue link: https://airccse.org/journal/ijsea/vol13.html
DOOML: A New Database & Object-Oriented Modeling Language for Database-Driven Web Application Design and Development
Thijs Otter, Inholland University of Applied Sciences, Netherlands
Abstract URL :https://aircconline.com/abstract/ijsea/v13n5/13522ijsea03.html
Article URL :https://aircconline.com/ijsea/V13N5/13522ijsea03.pdf
#modelinglanguage #objectorientedmodeling #databasemodeling #objectorienteddatabasemodeling #archetypediagram #softwaremodelling
Submission System: https://airccse.com/submissioncs/home.html
Contact Us : ijseajournal@airccse.org or ijsea@aircconline.com
Evaluation of meta modeling tools for domain specific modeling language chnjlPG Scholar
A Domain Specific Languages for modeling web pages and provide automatic code generation with a web-testing framework.
The whole process of Meta-modeling in the MetaEdit+ tool rotates around the Meta types represented together as GOPPRR’
Our technique are based on building abstractions of web pages and modeling state-machine-based test behavior using domain specific language
STATICMOCK : A Mock Object Framework for Compiled Languages ijseajournal
Mock object frameworks are very useful for creating unit tests. However, purely compiled languages lack robust frameworks for mock objects. The frameworks that do exist rely on inheritance, compiler directives, or linker manipulation. Such techniques limit the applicability of the existing frameworks, especially when
dealing with legacy code.
We present a tool, StaticMock, for creating mock objects in compiled languages. This tool uses source-tosource
compilation together with Aspect Oriented Programming to deliver a unique solution that does not rely on the previous, commonly used techniques. We evaluate the compile-time and run-time overhead incurred by this tool, and we demonstrate the effectiveness of the tool by showing that it can be applied to
new and existing code
RESILIENT INTERFACE DESIGN FOR SAFETY-CRITICAL EMBEDDED AUTOMOTIVE SOFTWAREcsandit
The replacement of the former, purely mechanical, functionality with mechatronics-based solutions, the introduction of new propulsion technologies, and the connection of cars to their environment are just a few reasons for the continuously increasing electrical and/or electronic
system (E/E system) complexity in modern passenger cars. Smart methodologies and techniques have been introduced in system development to cope with these new challenges. A topic that is often neglected is the definition of the interface between the hardware and software subsystems.
However, during the development of safety-critical E/E systems, according to the automotive
functional safety standard ISO 26262, an unambiguous definition of the hardware-software interface (HSI) has become vital. This paper presents a domain-specific modelling approach for mechatronic systems with an integrated hardware-software interface definition feature. The
newly developed model-based domain-specific language is tailored to the needs of mechatronic system engineers and supports the system’s architectural design including the interface definition, with a special focus on safety-criticality.
RESILIENT INTERFACE DESIGN FOR SAFETY-CRITICAL EMBEDDED AUTOMOTIVE SOFTWAREcscpconf
The replacement of the former, purely mechanical, functionality with mechatronics-based solutions, the introduction of new propulsion technologies, and the connection of cars to their environment are just a few reasons for the continuously increasing electrical and/or electronic system (E/E system) complexity in modern passenger cars. Smart methodologies and techniques have been introduced in system development to cope with these new challenges. A topic that is often neglected is the definition of the interface between the hardware and software subsystems. However, during the development of safety-critical E/E systems, according to the automotive functional safety standard ISO 26262, an unambiguous definition of the hardware-software interface (HSI) has become vital. This paper presents a domain-specific modelling approach for mechatronic systems with an integrated hardware-software interface definition feature. The newly developed model-based domain-specific language is tailored to the needs of mechatronic system engineers and supports the system’s architectural design including the interface definition, with a special focus on safety-criticality
Integrating profiling into mde compilersijseajournal
Scientific computation requires more and more performance in its algorithms. New massively parallel
architectures suit well to these algorithms. They are known for offering high performance and power
efficiency. Unfortunately, as parallel programming for these architectures requires a complex distribution
of tasks and data, developers find difficult to implement their applications effectively. Although approaches
based on source-to-source intends to provide a low learning curve for parallel programming and take
advantage of architecture features to create optimized applications, programming remains difficult for
neophytes. This work aims at improving performance by returning to the high-level models, specific
execution data from a profiling tool enhanced by smart advices computed by an analysis engine. In order to
keep the link between execution and model, the process is based on a traceability mechanism. Once the
model is automatically annotated, it can be re-factored aiming better performances on the re-generated
code. Hence, this work allows keeping coherence between model and code without forgetting to harness the
power of parallel architectures. To illustrate and clarify key points of this approach, we provide an
experimental example in GPUs context. The example uses a transformation chain from UML-MARTE
models to OpenCL code.
MODEL DRIVEN ARCHITECTURE, CONTROL SYSTEMS AND ECLIPSEAnže Vodovnik
This paper describes the use of model driven architecture and its application in control system development. It also presents a prototype solution based on the Eclipse framework implemented by the author.
Anže Vodovnik, Klemen Žagar, Cosylab, Ljubljana, Slovenija
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
MODIGEN: MODEL-DRIVEN GENERATION OF GRAPHICAL EDITORS IN ECLIPSE
1. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
DOI:10.5121/ijcsit.2016.8506 71
MODIGEN: MODEL-DRIVEN GENERATION OF
GRAPHICAL EDITORS IN ECLIPSE
Markus Gerhart1
and Prof. Dr. Marko Boger2
1
Department of Applied computer science, University of Applied Sciences, Konstanz
2
Department of Applied computer science, University of Applied Sciences, Konstanz
ABSTRACT
Domain-specific modeling is more and more understood as a comparable solution compared to classical
software development. Textual domain-specific languages (DSLs) already have a massive impactin contrast
tographical DSLs, they still have to show their full potential. The established textual DSLs are normally
generated from a domain specific grammar or maybe other specific textual descriptions. And advantage of
textual DSLs is thatthey can be development cost-efficient. In this paper, we describe asimilar approach for
the creation of graphical DSLs from textual descriptions. We present a set of speciallydeveloped textual
DSLs to fully describe graphical DSLs based on node and edge diagrams. These are, together with an EMF
meta-model, the input for a generator that produces an eclipse-based graphical Editor. The entire project
is available as open source under the name MoDiGen.
KEYWORDS
Model-Driven Software Development (MDSD), Domain-Specific Language (DSL), Xtext, Eclipse Modeling
Framework (EMF), Metamodel Model-Driven Architecture (MDA), Graphical Editor
1. INTRODUCTION
Domain-Specific Languages (DSLs) have a crucial importance in Model-Driven Engineering
(Also known as Model Driven Software Development (MDSD) or Model Driven Development
(MDD)) (MDE) and Model-Driven Architecture (MDA). A survey of MDE practitioners [24]
shows that MDE users make use of multiple modelling languages. Nearly 40% of participants had
used specially design custom DSLs, 25% had used off-the-shelf DSLs and only UML had been
used more widely than DSLs (used by 85% of participants). Despite the significant assumption of
specially designed DSLs for MDE, we think that existing MDE/MDA solutions for the definition
of custom DSLs areunsuitable. In particular, for the design and generation of a node-and-edge
based graphical DSL.
Despite the significant adoption of custom DSLs for MDE, we think that existing MDE/MDA
solutions for implementing custom DSLs and supporting tool chains are unsuitable for designing
and developing a new node-and-edge graphical DSL. This is due to the high complexity and the
range of applications of existing solutions. There is currently no solution which uses MDSD for
the specific domain of the generation of domain-specific graphical editors.
Eclipse has become one focus point of tooling for model driven approaches. Projects like Eclipse
Modeling Framework (EMF) [2] and Xtext [3] have become very popular in the modelling
community. But most of the current success in Eclipse modelling has been centered around
textual modelling environments. While Eclipse is designed for textual languages it can play out
its textual nature very nicely for this approach. But it is a difficult environment to create graphical
2. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
72
modelling tools. The basic APIs provided by the Eclipse framework; GraphicalEditing
Framework (GEF) [5] and Draw2D [4]; are low level and grant no direct connection to the
semantic and abstract level of a model.
The Eclipse Modelling Frameworkis often used for the semantic part, but offers no specific
support for graphical modelling. A project that attempt to bridge the gap between GEF and EMF
is the Graphical Modeling Framework (GMF) which is now part of the Graphical Modeling
Project (GMP) [6]. It proposes a model-driven approach for the development of domain specific
graphical modeling tools on the basis of GEF and EMF. But the domain specific models
including thedescription of the editor are to be so complex that projects evolved to create these
needed models from a higher perspective (abstract models). The resulting generated artifacts
(program code) was very complex and very difficult to extend for additionally custom
enhancements which could not be designed inside the model. The development environment was
brittle and cumbersome. The GMP provides currently no specific textual or graphic language to
associate a Metamodel with a predefined textual description with the aim to generate a domain
specific Graphical editor.
We present in this paper a generative approach for the creation of graphical modeling tools in
Eclipse. Instead of using the low level APIs of GEF and Draw2D directly, we use the relatively
young Java framework Graphiti [7] which is in the meantime also part of the Graphical Modeling
Project. Graphiti provides a API to build graphical editors in Eclipse and hides the complexity of
the low level tools such as GEF and Draw2D. However, while it is nearly perfectly possible to
create a graphical modeling environmentwith the Graphiti framework, we also think that the API
is well design to generate against it from a higher abstraction level. We developed a set of textual
modeling languages, which serve as input for a generator. The output of the generator is nearly
plain Java code for the API provided by Graphiti as well as all other needed files for the Eclipse
plugin mechanism. The result is a graphical modeling tool in Eclipse for custom-designed node-
and-edge-type diagrams.
With this approach we can reduce the effort to develop a graphical modeling tool so much that the
development of a graphical DSL becomes cost-efficient. Acomparable graphical modeling
environment that is manually developed with the Graphiti framework might require about 20.000
lines of code, our approach generates the needed code-artefacts from only about 500 lines of the
different textual model descriptions. Thus the cost to develop a graphical modeling tool is
reduced so much, that it may be a viable alternative to a textual DSL. Overall we hope to foster
the use of graphical DSLs in MDE-projects and to make the model-driven approach to software
development more attractive in general.
The paper first provides a short overview of the used technologies in the Section 2.Subsequently
the paper reviews related work in the field in Section 3, which is mostly other tools and
techniques for the generation of modeling tools. Our general approach for the model driven
creation of the domain specific editors and the overall architecture of our framework is described
in Section 4. The core contribution of this publication are the developed DSLs to define our own
graphical elements, styles for the graphical elements and the graphical editor itself which are
described in the sub chapters of the general approach. Section 5 illustrates the results of our
approach from different angles. Finally, we summarize the limitations of our research and draw
conclusions in Section 6.
2. BACKGROUND
This section explains shortly the referred techniques, libraries and frameworks.
3. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
73
The Model-Driven Engineering (MDE) is concerned with the automation of software production.
This means that as many artifacts of a software system are derived from formal generative
models. (inspired by [32])
Model-Driven Architecture (MDA) is a concrete approach of the Object Management Group
(OMG) [14], which describes a model-driven approach using its own standards (e.g. UML, MOF,
XMI).
A Domain Specific Language (DSL) [34] or application-specific language is a formal language,
which is designed and implemented for a specific problem area (the so-called domain). The main
goal of the design is to achieve a high degree of problem specificity. The DSL should be able to
represent all the problems of the domain and nothing outside of the domain.
The Eclipse Modeling Framework (EMF) [35] is a framework based on the Eclipse platform, that
is primarily used for model-based code generation. It ranks as the most important component of
the Eclipse Modeling Project, which covers the top level Project from Eclipse the field of model-
based development.
Graphical Editing Framework (GEF) [36] is a low level framework based on the Eclipse platform
for creating graphical editors within Eclipse. Furthermore, GEF helps to create graphical editors
based of an existing data model, which could be design inside of the Eclipse Modeling
Framework. GEF uses the Draw2d-Toolkit for the graphical representation.
Draw2d[37] is a lightweight framework for displaying graphical elements within the Eclipse
environment based on SWT Canvas.Lightweight means in this case that all graphical elements,
which Draw2d calls figures, are simple java objects with different functions for modification and
no corresponding resource in the operating system.The design goal of Draw2d is the creation of
vector graphics withinthe Eclipse ecosystem. The framework is part of GEF, but can also be used
independently.
Graphiti[38] combines the functionality of EMF and GEF, but hides the complexity of using
GEF behind a lightweight but not so powerfulAPI.The diagrams are described by a metamodel
and the diagram data is strictly separated from the actual data. This enables the opportunity of
rendering an existing diagram in different environments without having direct access to the
actualmetamodel instance data.
The Eclipse Graphical Modeling Project (GMP) [39] provides a set of generative components
and runtime infrastructures for developing graphical editors based on EMF and GEF.Thus, the
Graphical Modeling Project represents the collection of all provided frameworks and
technologiesby Eclipse, which are required for the generation of a model-driven solution. This
project combines all model driven approaches by eclipse in one single project.
Xtext[40] is aeclipse plugin for the development and creation of textual domain-specific
languages or simple programming languages.The Pluginusesparts from the Eclipse Modeling
Project such as EMF, GMF, M2T and parts of EMFT. Thedevelopment with Xtext is easy to learn
and provides a smooth start into the model driven engineering.
3. RELATED WORK
Graphical Modeling has received a lot of attention with the standardization of UML and BPMN
as a way to design or document technical systems. However, they pose the problem that the
systems tend to change independent from the models and eventually diverge. Model-driven
4. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
74
approaches alleviates this dilemma by making the model source, generating code from the model.
Thus model-driven software engineering has been an active field of research and development.
An obvious approach is to use UML or BPMN directly, but it turns out that these general
modeling languages are often not specific enough to catch all cases of a domain. For this reason,
the UML version 2.0 included a mechanism to extend the metamodel through stereotypes and
profiles. Such extensions have to be built on the basis of the predefined UML metamodel
elements. This makes it difficult to address the model instances from the generator and makes the
generator difficult to maintain. The tools most used for this approach are Enterprise Architect [9]
and Magic Draw [11]. However, most generator technologies are centered around Eclipse, and
building a solid tool chain can be challenging.
Tools that allow for the development of domain specific graphical modeling languages include
MetaEdit+ [31] and Poseidon for DSL [8]. The integration into an Eclipse-based tool chain is
achieved by an export of the resulting model into a serialized form, usually as XMI.
Eclipse has traditionally been a difficult environment to integrate graphics. Tools and frameworks
to build graphical modeling tools based on Eclipse exist. The fundamental frameworks are GEF
and Draw2D. Building such tools directly on GEF and Draw2D provides very little infrastructure
support and is accordingly very work intensive. The aforementioned GMF improves this through
a generative approach against these APIs. However, the DSLs, the generator and the generated
code of GMF have themselves high complexities. Extending GMF beyond the default generated
behavior can become particularly painful. Tools like Kybele [33] or Eugenia [27][28] also use a
generative approach to build graphical editors for Eclipse. The generated code of these solutions
is difficult to expand and to understand as these build on the low-level APIs GEF or Draw2d.
Their cost-effectiveness drops if the desired functionality is not provided by the default behavior.
The non-commercial tool Meta Programming System (MPS) [12] of the manufacturer Jet brains
provides a range of opportunities and freedoms in the design of their own meta-models. However,
due to the variety of possibilities the complexity of the tool is very high.
Another approach is to drop the use of a graphical modeling environment and instead use a
textual language to express the DSL models. This approach seems to be very successful in
practice. Most known tools are Xtext [3], Spoofax[26] and EMFtext [25].
This paper advocates the approach to build graphical editors directly in Eclipse. We also use a
generative approach, similar to GMF, Kybele or Eugenia, but in contrast to these we avoid to
generate directly against the fundamental libraries GEF and Draw2D. Instead we use a framework
called Graphiti. It is relatively young and has been developed by SAP [13]. The framework hides
the complexity of GEF and Draw2D and adds a high level graph-oriented API. It was intended for
the manual creation of graphical editors inside Eclipse, but it naturally lends itself to a generative
approach. This is what our project proposes. The focus of this paper is on the input to the
generator. This consists of a set of languages to describe node-and-edge-type graphical modeling
languages.
We have identified a similar approach with the project called IMES [10]. The aim of the publicly
funded project is to build graphical editors based on Graphiti for functional nets and other
systems. The project also uses DSLs and model-driven development (MDD) for the generative
creation of the graphical editors. Currently the project is not open source, wasn't presented to the
public and there was no further development since 2011, so it is difficult to compare our approach
with the IMES project.
5. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
4. APPROACH
The MoDiGen project consists of several DSLs, a generator and a runtime environment. The
development environment is Eclipse with a set of plugins. All
homepage of the project, together with installation instructions. For the
the generator, we use a language
developed for the purpose of generating code
Graphiti and some extensions which
not part of Graphiti. The core contribution
are needed for the development of
generated code or the runtime libraries. The DSLs are developed using Xtext.
MoDiGen [1] currently contains
in Figure 1, with different design goals
very simple domain specific graphical editors, this DSL is sufficient. It defines t
simple shapes, styles and the behavior of elements
complexthan a rectangle or circle
todesign complex shapes which consist of
Additionally, it’s possible to configure
of shapes, like color and font, can be defined inline in the Shape
description. In both cases the Style
Figure1.A Model
The role of the Styles DSL is similar to how
Markup Language (HTML). Defined style descriptions
Every time any of these models is saved, the
all neededartefacts and configurations
Plugin mechanism. The Graphical Editor within Eclipse
The three designed languages are described
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
The MoDiGen project consists of several DSLs, a generator and a runtime environment. The
ent environment is Eclipse with a set of plugins. All essentialtools can be found on the
homepage of the project, together with installation instructions. For the main part of the project,
we use a language which is similar to Javaand was specifically designed and
for the purpose of generating code artefacts, called Xtend[3]. The runtime consists of
which we have to develop, because this functionality iscurrently
contribution of this paper is on the designed textual DSLs
ment of a domain specific graphical editor and not directly
generated code or the runtime libraries. The DSLs are developed using Xtext.
three different DSLs- MoDiGen Core, Shape and Style
, with different design goals. The central DSL is the MoDiGen Core language. For
graphical editors, this DSL is sufficient. It defines the mapping of
the behavior of elements to metamodel classes. For shapes that
or circle shape, the Shape DSL is used. The Shape DSL
which consist of primitive forms like rectangles and ellipses.
Additionally, it’s possible to configure placings, resizing policy’s and nesting. The
of shapes, like color and font, can be defined inline in the Shape or separated
tyle language is used to design the layout of the elements
A Model-Driven approach for Graphical Editors
The role of the Styles DSL is similar to how Cascading Style Sheets (CSS) relates to
anguage (HTML). Defined style descriptions can be referenced from all other DSLs.
Every time any of these models is saved, the Model-Driven Generation is triggered and generates
and configurations –Java Code, XML files and Properties - for the Eclipse
Graphical Editor within Eclipse is then ready to use as plugin in Eclipse.
languages are described below in detail.
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
75
The MoDiGen project consists of several DSLs, a generator and a runtime environment. The
can be found on the
main part of the project,
designed and
. The runtime consists of
this functionality iscurrently
textual DSLs, which
directly on the
Style as shown
. The central DSL is the MoDiGen Core language. For
he mapping of
. For shapes that are more
is developed
forms like rectangles and ellipses.
and nesting. The actual design
or separated in a style
to design the layout of the elements.
heets (CSS) relates to Hypertext
can be referenced from all other DSLs.
and generates
for the Eclipse
is then ready to use as plugin in Eclipse.
6. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
4.1. THE MODIGEN CORE LANGUAGE
The most fundamental properties of a graphical
language. This is a simple text file with the ending
such a file initially with some example code. Due to the file
offers features like code completion
makes the languages easy to learn
At the beginning of the MoDiGen model
declaration of the diagram type, followed by aunique
Figure 2). This class serves as the root class for all
used in the generated code as the name of the Graphiti diagram. Afterwards the
EReferenceof the metamodel are mapped to their
the diagram. The mapping is initiatedby
or EReferencedescription. This is mapped to a shape, which can be done in one of two ways.
simple cases the MoDiGen Core D
and lines. For more elaborate shapes the mapping can reference a shape defined in the Shape
DSL. These defined shapes can be referenced by their
later in the paper. It is recommended to define the shapes in the appropriate shape language. As a
result, the clear separation between behavior (M
(style DSL) is observed. Only for very small projects, it is useful to break this rule.
Figure
After the definition of some
somebehaviors of the different shape
example the creation behavior, which defines in which metamodel Attribute the instance is saved
or the palette behavior which specifics the categorization of the elements in the generated editor
Also custom behaviors can be defined. For this, the necessary structural code is generated, the
code defining the behavior needs to be written in Java manually.
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
ANGUAGE
The most fundamental properties of a graphical editor are defined in the MoDiGen Core
language. This is a simple text file with the ending.modigen. The MoDiGen project wizard creates
such a file initially with some example code. Due to the file extension the Xtext environment
completion, syntax highlighting and different other conveniences, which
easy to learn.
of the MoDiGen model description the diagram keyword initializes the
the diagram type, followed by aunique identifier of the EMFmetamodel
the root class for all further defined classes. The diagram type is
used in the generated code as the name of the Graphiti diagram. Afterwards the
el are mapped to their defined appearance and associated
is initiatedby the keyword class followed by the fully qualified EClass
. This is mapped to a shape, which can be done in one of two ways.
MoDiGen Core DSL allows the definition of shapes consisting of rectangles, text
and lines. For more elaborate shapes the mapping can reference a shape defined in the Shape
can be referenced by their unique description. This will be explained
. It is recommended to define the shapes in the appropriate shape language. As a
r separation between behavior (MoDiGen core DSL), form (shape DSL) and design
ly for very small projects, it is useful to break this rule.
Figure2.MoDiGen File Example content
shapes for the new graphical editor, it’s possible to define
of the different shapes. Therefore there are different types of
, which defines in which metamodel Attribute the instance is saved
or the palette behavior which specifics the categorization of the elements in the generated editor
can be defined. For this, the necessary structural code is generated, the
needs to be written in Java manually.
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
76
editor are defined in the MoDiGen Core
. The MoDiGen project wizard creates
the Xtext environment
other conveniences, which
keyword initializes the
metamodelEClass (see
classes. The diagram type is
used in the generated code as the name of the Graphiti diagram. Afterwards the EClass and
associated behavior on
followed by the fully qualified EClass
. This is mapped to a shape, which can be done in one of two ways. For
consisting of rectangles, text
and lines. For more elaborate shapes the mapping can reference a shape defined in the Shape
description. This will be explained
. It is recommended to define the shapes in the appropriate shape language. As a
en core DSL), form (shape DSL) and design
it’s possible to define
types of behaviorsfor
, which defines in which metamodel Attribute the instance is saved
or the palette behavior which specifics the categorization of the elements in the generated editor.
can be defined. For this, the necessary structural code is generated, the
7. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
4.2. DEFINITION OF SHAPES
The core MoDiGen DSL allows the
complexity are needed there is a
some degree a similarity to SVG
DSL allows also primitive shapes like
be combined to complex shape structures
While the shape DSL is based on a context
respectively more opportunities
fast learning and not machine readability
had requirements which SVG
parameters totext fieldsor resizing policies or the programmatic
sizing can be influenced with the
false). In addition, it is also possible to only allow proportional resizing. Shapes can be nested,
allowing for complex graphical elements. The behavior of nested elements in regards to scaling
can be defined by the attribute
horizontal, and fit (according to an algorithm). Shapes can make use of nesting by re
existing shapes or by in-place definition.
nesting consistently throughout the DSL. All forms except for lines, polylines and text
arbitrarily be nested. The Shape DSL is consistently used for
well as for connections. The following section
4.2.1. DEFINITION OF SHAPES
The definition of a shape starts always
unique shape identification (in Figure
identification is used as name of the generated Java class
special characters. This class implements a marker interface
class. The interface description
the ContainerShape and the second one
container which is added
aconcretePictogramElement and all its
configuration information such
functionthatoffers the PictogramElement
because anContainerShape does not allow to save more than one element on the
top layer always contains an invisible rectangle which is able to save multiple child's
actual size of the invisible rectangle
Figure3
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
MoDiGen DSL allows the definition of simple (basic) forms, but if figures
there is a special DSL for the creation of shapes. The shape DSL has to
to SVG, but the design goal differs. Similar to SVG is, that
primitive shapes like polygons,ellipses, rectangles, lines and polylines
omplex shape structures. The biggest difference is that SVG is based on XML.
DSL is based on a context-free grammar. This gives us more freed
for future enhancements. The two main goalsare readability and
not machine readability for the fast programmatic processing. Furthermore, w
currently cannot satisfy, like the definition of the passing of
resizing policies or the programmatic analysis of properties. The re
influenced with the attribute stretching in horizontal and vertical orientation (true or
false). In addition, it is also possible to only allow proportional resizing. Shapes can be nested,
allowing for complex graphical elements. The behavior of nested elements in regards to scaling
ed by the attribute layout. It can have the values fixed (no adjustment), vertical,
horizontal, and fit (according to an algorithm). Shapes can make use of nesting by re
ce definition. Opening and closing curly brackets and are used to
nesting consistently throughout the DSL. All forms except for lines, polylines and text
be nested. The Shape DSL is consistently used for the description of node elements as
The following section explains the definition of shapes in detail
starts always with the predefined keyword shapeand is followed by a
(in Figure 3 the Shape is called BPMN_Event_Mail). This
as name of the generated Java class, therefore is recommended to use no
. This class implements a marker interface IShape and extends the
description provides two differentgetShape()functions: the first one
second one the PictogramElement. The ContainerShape
container which is added as a “placeholder” to the diagram. It
and all its possible nested elements. It is also possible
information such as anchor definitions for the connection anchor options
PictogramElement always contains on the root level an invisible rectangle
does not allow to save more than one element on the top
an invisible rectangle which is able to save multiple child's
invisible rectangle is calculated from contained shapes on every different
3.Creation of a Shape as mail event (BPMN)
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
77
with a higher
L for the creation of shapes. The shape DSL has to
that the Shape
polylines which can
The biggest difference is that SVG is based on XML.
us more freedom in design
readability and
Furthermore, we
the passing of
of properties. The re-
in horizontal and vertical orientation (true or
false). In addition, it is also possible to only allow proportional resizing. Shapes can be nested,
allowing for complex graphical elements. The behavior of nested elements in regards to scaling
. It can have the values fixed (no adjustment), vertical,
horizontal, and fit (according to an algorithm). Shapes can make use of nesting by re-using
are used to mark
nesting consistently throughout the DSL. All forms except for lines, polylines and text can
node elements as
explains the definition of shapes in detail.
is followed by a
). This shape
, therefore is recommended to use no
and extends the DefaultShape
the first one returns
ContainerShapeserves as a
to the diagram. It contains
to save more
ons for the connection anchor options. The
an invisible rectangle,
top layer. So the
an invisible rectangle which is able to save multiple child's in it. The
on every different layer.
8. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
The example in Figure 3 describes how to create an envelope for the
Process Model and Notation (BPMN)
circle. The circle is built with an ellipse
circle is a rectangle, which defines
expressed relative to the surrounding ellipse.
4.2.3. ANCHORAGE ON SHAPES
Anchor points are an important aspect for
where connections can be attached to a shape.
definition of anchor points. There are two predefined anchor types which are called
corners (see Figure 4). The keyword
definition attaches the connection end point
connection line and its decoration
keyword of an anchor type is corners
of the invisible rectangle as well as on the
Figure 4 shows the different anchor types.
After the keyword anchor the predefined anchor
curly bracket is used to define
defined inside the curly brackets. The custom anchor points can be
x and y) or to a relative position
exactlythe defined position within the
relation to the size of the shape with values between 0.0 (
(xoffset - right or yoffset - bottom). The lower part of Figure
the edges of the rhombus for the
side the same anchor point can be defined fixed o
4.2.4. CONNECTIONS AND PLACINGS
A connection always contains a line,
connection must have always a source and a target anchor
a shape. Additionally, connections can have decorationse.g. arrowheads or any kind of a
The example of BPMN describes
has two different decorations. At the one end
also possible to place text fields
e.g. cardinalities or connection descriptions
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
describes how to create an envelope for the mail event of the
otation (BPMN) [29] with the Shape DSL. The entire figure is inside a
an ellipse with the samevalue for width and height. Nested into this
defines the border of the envelope. The position of the rectangle is
ssed relative to the surrounding ellipse. Finally, a polygon completes the entire
important aspect for the design of shapes. Anchor points serve as points
connections can be attached to a shape. The Shape DSL offers four different options
definition of anchor points. There are two predefined anchor types which are called
keyword center is comparable to the Chopbox anchor
attaches the connection end point always to the center of the figure/shape
decoration ends on the outermost shapes border. The second predefined
corners.This predefined value creates anchor points on all corner
as well as on the middle point of the four border sides of the shape.
Figure 4 shows the different anchor types.
the predefined anchor valuescenter or corners can be declared or a
curly bracket is used to define custom anchor positions. Any number of anchor points can be
defined inside the curly brackets. The custom anchor points can be set to fixed coordinates (using
relative position (using xoffset and yoffset). Fix point anchors are placed at
defined position within the created shape. The relative anchor definitions
relation to the size of the shape with values between 0.0 (xoffset - left or yoffset -
bottom). The lower part of Figure 4 shows the creation of anchors on
the edges of the rhombus for the XOR-Gateway in BPMN. As shown in the Figure 4 on the right
can be defined fixed or relative.
Figure4. Anchorage on Shapes
LACINGS
a line, which connects two different or also the same shape
always a source and a target anchor point, which attaches the connection
onnections can have decorationse.g. arrowheads or any kind of a
describes a conditional connection, shown in Figure 5. This conn
different decorations. At the one end the arrowhead and the rhombus at the other
fields directly on the connection to define diagram types which needs
cardinalities or connection descriptions.
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
78
of the Business
entire figure is inside a
width and height. Nested into this
of the envelope. The position of the rectangle is
entire envelope.
serve as points
different options for the
definition of anchor points. There are two predefined anchor types which are called center and
box anchor in [5]. This
to the center of the figure/shape.But the
. The second predefined
on all corners
sides of the shape.
can be declared or a
anchor points can be
coordinates (using
). Fix point anchors are placed at
tive anchor definitions are placed in
- top) and 1.0
shows the creation of anchors on
4 on the right
shape(s). Any
the connection to
onnections can have decorationse.g. arrowheads or any kind of a shape.
. This connection
the arrowhead and the rhombus at the other end. It’s
to define diagram types which needs
9. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
Figure
In Shape DSL connections are defined using the keyword
routing type. Two routing types are
routing. The Manhattan routing is auto
corners. The free form connection is
which can be customized by the user
Placings can be definedon or around a connection
decoration on the connection. The actual
different required attributes (offset, angle and radius
the line where the decoration owns it’s starting point
(beginning) and 1.0 (end). Additionally,
the definition of the angle(0-360 degrees)
on the line, these values have to be zero.B
shapesaround the line, this is very
starting at the offset on the line. This vector
Figure 6 shows such a vector.
Figure
The example in Figure 5 shows
There are two placings on the connection. The first is located at the end (offset=1.0) and is an
arrowhead, drawn as a filled polygon. The othe
(offset=0.0).
4.2.5. DEFINITION OF STYLES
Alayout definition with the style
makes such a style reusable via a
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
Figure5.Connection-Shapes and their Placings
In Shape DSL connections are defined using the keyword connection. It can be followed by a
routing type. Two routing types are currently predefined, the free form and the Manhattan
routing. The Manhattan routing is auto-layouted in vertical and horizontal lines and uses rounded
corners. The free form connection is the easiest routing option because it’s just a straight line,
by the user by adding bend points to the connection.
on or around a connection. Therefore, a placing is a definition for a
The actual position of a placing on a connection depends on
offset, angle and radius). The offset defines the relative
owns it’s starting point. This relative value ranges between 0.0
Additionally, the placing can be positioned around the connection
360 degrees)and radiusattribute. For graphical decorations directly
have to be zero.But for the positioning of text fields or maybe other
very helpful. The combination of angle and radius define a vector
. This vector points to the place where the placing is drawn. The
Figure6. Positioning of placings on Connections
shows aconditional sequence connectionwhich is part of the
There are two placings on the connection. The first is located at the end (offset=1.0) and is an
arrowhead, drawn as a filled polygon. The other is a rhombus placed at the beginning
Alayout definition with the style DSL allows to declare a number of attributes for shapes and
makes such a style reusable via a unique identifier. Common attributes such as background
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
79
. It can be followed by a
defined, the free form and the Manhattan
layouted in vertical and horizontal lines and uses rounded
just a straight line,
placing is a definition for a
on a connection depends on three
relative position on
ranges between 0.0
around the connection with
decorations directly
fields or maybe other
ngle and radius define a vector
is drawn. The
which is part of the BPMN.
There are two placings on the connection. The first is located at the end (offset=1.0) and is an
r is a rhombus placed at the beginning
of attributes for shapes and
background-color
10. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
or line-style can be defined. It’s possible to reference
the style attributes can be set individual
rectangle or polygon. If no style
style declaration. For each level of nesting the style
above. It’s possible to override the i
offers the possibility of a very detailed definition
it makes it easy to change or extend the general appearance of the diagram very quickly.
Figure
A style definition is described in a
with the keywordstyle and
BlackAndWhiteStyle). This style is generated to a Java class
This class implements the interface
class to implement the functiongetStyle()
This procedure maps all defined
definition can contain many different
The line style attribute is responsible for the visu
are predefined solid, dot, dash
definitionspecifies attributes like
attributes of each section, this is just a selection.
Figure 8
The underlining of fonts is currently
feature is at the moment not been reflected in the
enhancement which should be provided in the near future
definition of colors, because Graphiti
color. Graphiti contains only one color definition
colordefines, according to Graphiti,
In MoDiGen we solved thisproblem with a workaround
every style called getFontColor()
color for the font. The usage of
possible options to use them. The first
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
’s possible to reference a defined stylefromany of the three DSLs
can be set individual for shapes or single shape elements such as ellipse,
rectangle or polygon. If no style definition is referenced or specified, the generator usesa
. For each level of nesting the style information is inherited from the next level
It’s possible to override the individual style attributes on each different nesting level.
detailed definition on the look and feel of the shape. Furthermore,
makes it easy to change or extend the general appearance of the diagram very quickly.
Figure 7. Style File Example content
A style definition is described in a text file with the suffix.style. The description of a style begins
and a unique style name see Figure 7 (in the example
). This style is generated to a Java class with the same unique style name.
class implements the interface ISprayStyle. This specified interface forces the generated
getStyle() which returns an instantiation of the Graphiti style class.
efined values of the style definition to the Graphiti Style class.
different attributes e.g. line attributes like line-width
responsible for the visual appearance of a line and the following options
dash, dash-dot anddash-dot-dot. The font section
attributes like font-size, font-color and font-name.There are a variety of other
s is just a selection.
8. Example description of style Inheritance
currently not implementedin the Graphiti Framework. Therefore, this
not been reflected in the DSL as well, but this is
which should be provided in the near future. Another problem of Graphiti is
Graphiti does not allow to differentiate between a font
one color definition - the foreground-color. The
defines, according to Graphiti, everything which is drawn like the line border and the fonts.
we solved thisproblem with a workaround, by generating a different
getFontColor(). This functionreturns a different foreground-color
for the font. The usage of the colors is quite simple, because there are just two different
. The first option is to use the predefined color values like
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
80
a defined stylefromany of the three DSLs or
shapes or single shape elements such as ellipse,
or specified, the generator usesa default
is inherited from the next level
nesting level. This
. Furthermore,
makes it easy to change or extend the general appearance of the diagram very quickly.
. The description of a style begins
(in the example
with the same unique style name.
interface forces the generated
which returns an instantiation of the Graphiti style class.
the Graphiti Style class. A style
or line-color.
of a line and the following options
. The font section of a style
There are a variety of other
Framework. Therefore, this
an important
Another problem of Graphiti is the
does not allow to differentiate between a font- and a line-
. The foreground-
the line border and the fonts.
different methods for
color as the line-
simple, because there are just two different
the predefined color values like white,
11. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
black, gray and many more. The second
provides the definition of the intensity of the red, green and the blue color individually with a
value range between 0 and 255. Therefore,
addition to the color attribute there is an attribute for transparency. A
transparency is between1.00 and 0.00. 1.0
the opposite. If no background-color
In this case the filled attribute value of the
visibility is the same approach as for the
inherit from each other. The root
ISprayStyle followed by a default implementation called
implementation defines all default style attributes
approach can be used in the DSL as well.
and only just a few attributes
BlackAndYellowStyle inherits from the
changed to yellow.
This inheritance mechanism gives the freedom that
addition, it’s also possible to program a style definition
implement the interface theISprayStyle
Shapes and for inheritance. Some nice enhancements as color
be added in the near future and will share the same properties.
4.2.6. INTEGRATION OF STYLES
The style definitioncan be defined in aspecific
definition. For this purpose, the style keyword is used and the
inside the round brackets. With this approach it’s possible to override or define
attributes. This opportunity has only an
elements or other forms on the same layer. This
background-color is set to the blue color for the rectangle.
Figure 9. The different t
The second optionoffers the possibility
use this option, the style class must be
The middle part of the Figure 9
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
. The second option is to use the RGB-structure. This possibility
the intensity of the red, green and the blue color individually with a
255. Therefore, the designer is able to create nearly any color.
color attribute there is an attribute for transparency. A valid value
is between1.00 and 0.00. 1.0 means that the object is fully visible and 0.0
color is intended, the color can be set to transparent.
value of the Graphiti Style class is declared to false. For the line
the same approach as for the background-color used. Styles offer the possibility to
inherit from each other. The root element of the style inheritance hierarchy is the interface
followed by a default implementation called DefaultSprayStyle. This default
nes all default style attributes if no style is specified by the user
approach can be used in the DSL as well. It’s also possible that a style inherits from another style
are changed. Figure 8 describes exactly this case. T
inherits from the BlackAndWhiteStyle and just the background
gives the freedom that all attributes of the style DSL are optional.
o program a style definition manually in Java. It just needs
ISprayStyle and the style is available for referencing in MoDiGen or
nce. Some nice enhancements as color gradients and element shadows will
be added in the near future and will share the same properties.
TYLES INTO SHAPES/CONNECTIONS
can be defined in aspecific external style description or can be part of a
style keyword is used and the different style attributes are defined
With this approach it’s possible to override or define one or more
opportunity has only an effect on the corresponding element and not
elements or other forms on the same layer. This behavior is shown in Figure
is set to the blue color for the rectangle.
different types of Style Integration and inheritance within shapes
optionoffers the possibility to inherit a style definition for a whole shape.
must be referenced by its unique identifier after the keyword style.
9 uses the style class BlackAndYellowStyle for the whole shape.
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
81
This possibility
the intensity of the red, green and the blue color individually with a
the designer is able to create nearly any color. In
value range for the
means that the object is fully visible and 0.00 is exactly
.
to false. For the line-
offer the possibility to
inheritance hierarchy is the interface
. This default
if no style is specified by the user. But this
from another style
case. The style
and just the background-color is
all attributes of the style DSL are optional. In
manually in Java. It just needs to
and the style is available for referencing in MoDiGen or
gradients and element shadows will
part of a shape
style attributes are defined
one or more style
not to the nested
shown in Figure 9. There the
hapes
whole shape. In order to
keyword style.
uses the style class BlackAndYellowStyle for the whole shape.
12. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
82
The complete shape gets with this definition a yellow background. If the same approach is used at
the beginning of the rectangle, then the entire envelope would become yellow, but not the circle.
As shown in the right part of the Figure 9 these two methods can be mixed. The inline defined
attributes of a shape will always overwrite the attributes of the referenced style definition. In
Figure 9 the whole shape is yellow apart from the rectangle, which overrides the color attribute
with the value blue. In our experience, this mixing is very useful.
4.3. THE GENERATED GRAPHICAL EDITOR
The generated graphical editor is a set of fully functional Eclipse Plugin’s. The editor consists of
four divisions. The left area contains the package explorer which contains the different created
diagrams with the option to create new diagram instances. The right area contains the elements
described with the shape DSL in the previous step. In the lower area is the Property View, which
displays properties of elements according to the defined properties in the MoDiGen core DSL.
The area in the center is the main area to draw the new diagram according to the previous defined
Metamodel. Figure 10 shows the editor with an example Diagram of the BPMN.
Figure10. The generated domain-specific graphical editor in Eclipse
5. EVALUATION
The presented generative approach reduces the needed effort to develop a domain specific
graphical modeling tool for the Eclipse framework considerably compared to coding such a
solution manually in Java against the Graphiti API. For every domain object requires the Graphiti
framework a set of features. The generator creates this required Add-, Create-, Layout- and an
UpdateFeature (a lot more planned), which altogether consist of at least 400 lines of code per
domain object. These can be generated from MoDiGen from about 10 lines of code. The factor in
terms of code between the MoDiGen DSLs (10 lines) and the generated Graphiti Code (350 lines)
is approximately 35. For several implemented examples we consistently observed this factor, with
exception of very small diagrams. Figure 11 shows the number of required lines of code in
MoDiGen respectively Java (generated) based on the five diagram types “Petri-Net”, “BPMN”,
“Event-driven Process Chain” (EPC), “Piping and instrumentation Diagram” (P&ID) and “Basic
Class Editor”. The biggest difference of generated Java-Code and additional files (60154 lines of
code) to MoDiGen (1784 lines of code) is evidenced in the business process modeling language
“BPMN”. This can be mainly attributed to the variety of different graphical elements. The
13. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
smallest factor of about 30 results for
of only two Graphical elements ‘(shape and connection) and does not have any complex logic.
Figure11. Lines of Code: MoDiGen vs. Java (Generated)
The division of the lines of code on the three developed languages is shown in Figure
be observed that the main effort lies in the description of graphical elements, which is
demonstrated in the use case of “BPMN” which consists of about 70 Shap
number of lines of code for the styles cannot be directly measured, since this depends on the level
of detail that the domain expert wishes to reach. For simple styles as few as 10 lines can be
sufficient, more complex styles can ta
merely created quite basic styles, which is usually inherited to all elements. The real benefit can
be represented by the ratio of the lines of code necessary in MoDiGen and the generated Java
code, which is shown in Figure 13
Figure
The smallest factor is observed for the Basic Class Editor with a factor of 30. The highest factor
within our set of examples is observed for the Pet
are considered, this results in a mean factor of 36 (Blue line). The green and red lines show the
mean factor without the highest and lowest value included, respectively. If the largest and
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
smallest factor of about 30 results for the very simple chart type “Basic Class Editor”. It consists
‘(shape and connection) and does not have any complex logic.
Lines of Code: MoDiGen vs. Java (Generated)
The division of the lines of code on the three developed languages is shown in Figure
be observed that the main effort lies in the description of graphical elements, which is
demonstrated in the use case of “BPMN” which consists of about 70 Shapes and connections. The
number of lines of code for the styles cannot be directly measured, since this depends on the level
of detail that the domain expert wishes to reach. For simple styles as few as 10 lines can be
sufficient, more complex styles can take up several hundred lines of code. In these examples we
merely created quite basic styles, which is usually inherited to all elements. The real benefit can
be represented by the ratio of the lines of code necessary in MoDiGen and the generated Java
13.
Figure 12. Lines of Code in different DSLs
The smallest factor is observed for the Basic Class Editor with a factor of 30. The highest factor
within our set of examples is observed for the Petri-Net with a factor of 49. If all five examples
are considered, this results in a mean factor of 36 (Blue line). The green and red lines show the
mean factor without the highest and lowest value included, respectively. If the largest and
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
83
the very simple chart type “Basic Class Editor”. It consists
‘(shape and connection) and does not have any complex logic.
The division of the lines of code on the three developed languages is shown in Figure 12. It can
be observed that the main effort lies in the description of graphical elements, which is
es and connections. The
number of lines of code for the styles cannot be directly measured, since this depends on the level
of detail that the domain expert wishes to reach. For simple styles as few as 10 lines can be
ke up several hundred lines of code. In these examples we
merely created quite basic styles, which is usually inherited to all elements. The real benefit can
be represented by the ratio of the lines of code necessary in MoDiGen and the generated Java
The smallest factor is observed for the Basic Class Editor with a factor of 30. The highest factor
Net with a factor of 49. If all five examples
are considered, this results in a mean factor of 36 (Blue line). The green and red lines show the
mean factor without the highest and lowest value included, respectively. If the largest and
14. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
smallest values are not considered, there is a mean factor of above 34. This is indeed a huge
benefit. We believe the generated code to be quite comparable to code that is hand written against
the Graphiti API directly. In addition, the generated code solves a number of i
Graphiti code, that would need to be solved individually in each project otherwise, resulting in
additional complexity.
Figure13. Ratio Lines of Code MoDiGen vs. Java(Generated)
A quite representational DSL is the P
water or gas pipes. It was developed for the Modelling Challenge of the Language Workbench
Challenge in 2012. It consists of 20 domain objects and was described in MoDiGen in about 400
lines of code. This generates about 80 Java Classes with altogether about 15000 lines of code.
Thus we argue that our approach
Eclipse by a significant factor. This should make the development of g
for the Eclipse framework much more attractive
The applications BPMN Modeler 2.0
Editor were used as comparable applications and
applications were both generated and written by
hand written and generated tools are possible. Table 1
application. The number of lines of code w
Lines of Code include on the one hand only the JAVA files (black) and, secondly, all the Lines of
Code of the different Eclipse plugins (red). The
application. This is because many parts of the application are written in HTML, which is not
considered in the calculation of the JAVA files. In the other cases, the difference is very small,
because only configuration files are added.
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
re not considered, there is a mean factor of above 34. This is indeed a huge
benefit. We believe the generated code to be quite comparable to code that is hand written against
the Graphiti API directly. In addition, the generated code solves a number of issues with the
Graphiti code, that would need to be solved individually in each project otherwise, resulting in
Ratio Lines of Code MoDiGen vs. Java(Generated)
is the P&ID, describing pipes and other plumbing for the domain of
water or gas pipes. It was developed for the Modelling Challenge of the Language Workbench
Challenge in 2012. It consists of 20 domain objects and was described in MoDiGen in about 400
s of code. This generates about 80 Java Classes with altogether about 15000 lines of code.
Thus we argue that our approach reduces the development time for developing a graphical DSL in
Eclipse by a significant factor. This should make the development of graphical modelling
much more attractive and useful than in the past.
The applications BPMN Modeler 2.0 [15] [16] , EPC Tools [17], ePNK[18] and Basic Class
Editor were used as comparable applications and analyzed with respect to lines of code. These
applications were both generated and written by hand, slight differences in the functionality of the
ated tools are possible. Table 1 displays the Lines of Code (LOC) per
f lines of code was determined by the tool CLOC [19] [20]
Lines of Code include on the one hand only the JAVA files (black) and, secondly, all the Lines of
Code of the different Eclipse plugins (red). The difference is quite severe for the ECP T
application. This is because many parts of the application are written in HTML, which is not
considered in the calculation of the JAVA files. In the other cases, the difference is very small,
because only configuration files are added.
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
84
re not considered, there is a mean factor of above 34. This is indeed a huge
benefit. We believe the generated code to be quite comparable to code that is hand written against
ssues with the
Graphiti code, that would need to be solved individually in each project otherwise, resulting in
&ID, describing pipes and other plumbing for the domain of
water or gas pipes. It was developed for the Modelling Challenge of the Language Workbench
Challenge in 2012. It consists of 20 domain objects and was described in MoDiGen in about 400
s of code. This generates about 80 Java Classes with altogether about 15000 lines of code.
the development time for developing a graphical DSL in
modellingplugins
and Basic Class
with respect to lines of code. These
differences in the functionality of the
displays the Lines of Code (LOC) per
as determined by the tool CLOC [19] [20]. The shown
Lines of Code include on the one hand only the JAVA files (black) and, secondly, all the Lines of
quite severe for the ECP Tools
application. This is because many parts of the application are written in HTML, which is not
considered in the calculation of the JAVA files. In the other cases, the difference is very small,
15. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
MoDi
Gen
Generate
d
by
MoDiGen
BPMN 1.784 56.263
(60.154)
EPC 436 14.165
(14.761)
P&ID 418 13.659
(14.965)
Petri-
Net
99 4.056
(4.923)
Basic
Class
Editor
60 1.680
(1.819)
The tools BPMN Modeler 2.0 and Basic Class Editor were developed with the help of the
Graphiti Framework and are therefore a very good comparison of generated and manually written
Java (Graphiti) code. The Basic Class Editor is of particular importance. Th
a graphical element and a connection. From Table
manually written code are very close together with respect to the number of lines of code. This
shows that the generated and manually writt
generated and handwritten code can be found at
In addition, the developed languages were evaluated
participants were divided into four
Each participant of the different
MoDiGen. After the short workshop
different tasks sequentially with increasing degree of difficulty
(Task 1), shape (Task 2) and style (Task 3) language separately and in total in the final task.
Figure14. Achieved correct results and Assistance requi
Figure 14 (left side) shows that 90
3 and 80% Task 4 correctly. The right diagram in Figure
without assistance. 55% of the participants did not need
Task 2, 57.5% Task 3 and 65% at Task 4.
approximately 75% and only 35
the definition of complex figures by a textual description requires more exercise
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
Table 1. Lines of Code – CLOC
Generate
MoDiGen
BPMN
Modeler 2.0
EPCTools ePNK Basic
Class
Editor
56.263
(60.154)
117.255
(128.170)
- - -
14.165
(14.761)
- 8.868
(85.151)
- -
13.659
(14.965)
- - - -
(4.923)
- - 36.322
(37.406)
-
(1.819)
- - - 1.732
(1.872)
The tools BPMN Modeler 2.0 and Basic Class Editor were developed with the help of the
Graphiti Framework and are therefore a very good comparison of generated and manually written
Java (Graphiti) code. The Basic Class Editor is of particular importance. This editor only includes
a graphical element and a connection. From Table 1 it can be seen that the generated and the
manually written code are very close together with respect to the number of lines of code. This
shows that the generated and manually written code are comparable. The eclipse projects of the
generated and handwritten code can be found at [21].
the developed languages were evaluated with 40 participants. The
four groups (Bachelor and Master Student, Developers and Others
participant of the different groups received a 4-hour introduction to meta-modeling and in
the short workshop and a lunch break, each participant had to
with increasing degree of difficulty. The tasks were to use the diagram
(Task 1), shape (Task 2) and style (Task 3) language separately and in total in the final task.
Achieved correct results and Assistance required
(left side) shows that 90% of participants could solve Task 1, 72.5% Task 2, 95% Task
% Task 4 correctly. The right diagram in Figure 14 shows that the tasks could be
% of the participants did not need help with the editing of Task 1, 35%
% Task 3 and 65% at Task 4. The second Task could only be processed
35% of the participants did not need help.This is probably because
the definition of complex figures by a textual description requires more exercise and is not such
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
85
Basic
Class
Editor
1.732
(1.872)
The tools BPMN Modeler 2.0 and Basic Class Editor were developed with the help of the
Graphiti Framework and are therefore a very good comparison of generated and manually written
is editor only includes
it can be seen that the generated and the
manually written code are very close together with respect to the number of lines of code. This
en code are comparable. The eclipse projects of the
with 40 participants. The different
er Student, Developers and Others).
modeling and in
break, each participant had to complete 4
. The tasks were to use the diagram
(Task 1), shape (Task 2) and style (Task 3) language separately and in total in the final task.
ipants could solve Task 1, 72.5% Task 2, 95% Task
shows that the tasks could be finished
with the editing of Task 1, 35%
processed correctly by
probably because
and is not such
16. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
as easy with a graphical editor. This
illustration of the defined element
Figure 15 shows the processing time for each user group and task with the fastest, slowest
(perhaps cancelled) and average value. The values are distributed almost homogeneously.
allows the conclusion, that the languages have
almost everybody is able to learn the
29.75 minutes for Task 1, 41,25 minutes for Task 2, 22,25 minutes for Task 3 and 59,5 minutes
for Task 4.
Figure15
The evaluation of the dsl shows that the languages
approaches and the users can use
proved by the high rate of successfully completed tasks.
of CSS within the style language, the evaluation members find their
The creation of graphic elements
possibilities were not directly
processing of the task. After the training, the Diagram languages were considered to be very
compact.
Nevertheless, the evaluation sh
approach. For example, a live preview of the
be very useful. However, this is not an issue of the languages but is an extension of the editor and
tooling. The keyword "ask for"
must be considered whether a renaming is
groups was entirely ignored. Therefore, the question arises whether these are useful or the use
must be described in more detail. The full evaluation plan and report is available at
From this evaluation we conclude that the pr
development of a graphical editor in Eclipse considerably compared to manually written code
against Graphiti, under the constraint that the requirements are met by the generated editor. We
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
. This assumption is supported by the comment that a graphical
defined element would have been very helpful.
shows the processing time for each user group and task with the fastest, slowest
) and average value. The values are distributed almost homogeneously.
that the languages have a certain complexity, especially the shape dsl, but
is able to learn the different languages. On average the participants needed
29.75 minutes for Task 1, 41,25 minutes for Task 2, 22,25 minutes for Task 3 and 59,5 minutes
15. Processing time to completion or abort
shows that the languages includes and combinesa lot ofuseful
use the languages very well separated and in combination
by the high rate of successfully completed tasks. With the integration of some approaches
of CSS within the style language, the evaluation members find their way around very quickly.
of graphic elements with the shape dslwas initially very unfamiliar and the
directly recognized. This problem could be solved with increasing
processing of the task. After the training, the Diagram languages were considered to be very
Nevertheless, the evaluation showed that some weaknesses are present within the presented
or example, a live preview of the defined graphical elements with the shape dsl
. However, this is not an issue of the languages but is an extension of the editor and
tooling. The keyword "ask for" was not understood by a lot of participants. For this
must be considered whether a renaming is meaningful. The diagram language part of the
herefore, the question arises whether these are useful or the use
must be described in more detail. The full evaluation plan and report is available at [22][23]
From this evaluation we conclude that the presented approach reduces the effort for the
development of a graphical editor in Eclipse considerably compared to manually written code
against Graphiti, under the constraint that the requirements are met by the generated editor. We
International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
86
that a graphical live
shows the processing time for each user group and task with the fastest, slowest
) and average value. The values are distributed almost homogeneously. This
, especially the shape dsl, but
languages. On average the participants needed
29.75 minutes for Task 1, 41,25 minutes for Task 2, 22,25 minutes for Task 3 and 59,5 minutes
includes and combinesa lot ofuseful
separated and in combination. This is
With the integration of some approaches
way around very quickly.
nitially very unfamiliar and the
with increasing
processing of the task. After the training, the Diagram languages were considered to be very
within the presented
with the shape dsl would
. However, this is not an issue of the languages but is an extension of the editor and
For this reason, it
part of the action
herefore, the question arises whether these are useful or the use
[22][23].
esented approach reduces the effort for the
development of a graphical editor in Eclipse considerably compared to manually written code
against Graphiti, under the constraint that the requirements are met by the generated editor. We
17. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
87
have indications that the use of Graphiti reduces the effort compared to the use of GEF and
Draw2D, but have no formal evaluation for that.
6. CONCLUSIONS
In this paper we have presented that the development of a graphical DSL with the usage of the
open source framework MoDiGen can be very efficient. We presented an approach for the model
driven generation of graphical modelling tools as part of the Eclipse framework. The
modellingenvironment can be adjusted to the needs of a specific domain. Thisresults in a set of
Eclipse plugins,which supports the defined graphical domain-specific language. It’s not necessary
to be an expert of the field of metamodeling, to develop a domain specificgraphical modelling
tool, because the presented DSLs are quite easy to learn, read and write. The meta model and the
DSLs can be tailored to the specific needs of the domain, therefore the models can be very
specific. In this paper we showed some example elements, but its although possible to use the
same approach for various domain-specific modelling languages.
The described project is currently not finished and still lacks a number of important features
before its use could be recommended in the context of productive development. But this will
improve over time. Examples of such features are improved support for text, the inclusion of
shadowsand the use of rapid buttons. More important is the question of the limitations of the
approach. We see no constrains regarding the graphical editor itself and the provided API by
Graphitiwith respect to the model-driven approach. Unfortunately, the Graphiti Framework did
not provide a lot of features we had expected. For example, Graphiti currently does not support
the design of text like underling. This feature is essential for a class diagram which is part of the
UML. Another limitation is the standard zooming function within Graphiti diagrams and the hole
eclipse environment. The eclipse ecosystemespecially Graphiti zooms by resizing all sizes of the
elements, including the border-size of any element. This leads to a confusing functionality of the
editor.
The generative approach is currently reduced to the cases which are often needed by domain
developers (node and edge diagrams).In UML most diagram types fit into this category. But the
other diagram types such as sequence and the timing diagram could not be implemented
currently. They cannot be described with the presented DSLs without considerable
extensions.Therefore, the generator and the metamodel fit to this cases. Corner cases could be
covered by the manual extension of the generated code. The generated code is well prepared for
this case.
The real limitation is more the development environment in the form of the Eclipse framework.
The aim of Eclipse is to develop a tool for the textual software development.An example of this is
that the storage of a change in a file must be triggered explicitly.This approach is not possible for
the real-time evaluation of model data.This requires a continuous storage for each
change.However, this is hard to achieve in Eclipse.
Other topics, like multi-user collaborative modelling environments, evolution of Metamodels, or
diffing and merging changes in versions of graphical models remain topics of research and are
independent of Eclipse or a model driven approach.
REFERENCES
[1] MoDiGen - A Quick Way of Creating Graphiti (2016). https://www.modigen.de
[2] The Eclipse Foundation: Eclipse Modeling Framework Project (EMF) (2016).
http://www.eclipse.org/modeling/emf/
18. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
88
[3] Itemis AG (2016). http://www.eclipse.org/Xtext
[4] The Eclipse Foundation: Draw2d (2016). http://www.eclipse.org/gef/draw2d/
[5] The Eclipse Foundation: Graphical Editing Framework (GEF) (2016). http://www.eclipse.org/gef/
[6] The Eclipse Foundation: Graphical Modeling Project (GMP).
(2016)http://www.eclipse.org/modeling/gmp/
[7] The Eclipse Foundation: Graphiti: A Graphical Tooling Infrastructure.
(2016)http://www.eclipse.org/graphiti/
[8] Poseidon for DSLs. (2016)http://www.gentleware.com/poseidon-for-dsls.html
[9] Sparx Systems: Enterprise Architect. (2016)http://www.sparxsystems.com/
[10] A DSL for Graphiti Editors (IMES), Research Project.
(2016)http://5ise.quanxinquanyi.de/2011/08/18/a-dsl-for-graphiti-editors/
[11] No Magic Inc.: MagicDraw (2016). https://www.magicdraw.com/
[12] MPS Meta Programming System (2016). http://www.jetbrains.com/mps/
[13] Software Developer SAP (2016). http://www.sap.de
[14] Object Management Group (2016). http://www.omg.org/
[15] Eclipse - BPMN2 Modeler (2016). https://www.eclipse.org/bpmn2-modeler/
[16] GIT Repository - BPMN2 Modeler (2016). https://github.com/eclipse/bpmn2-modeler
[17] Uni Paderborn –EPCTools (2016). http://www2.cs.uni-paderborn.de/cs/kindler/research/EPCTools/
[18] Technical University of Denmark – EPNK (2016). http://www.imm.dtu.dk/ekki/projects/ePNK/
[19] Count Lines of Code – CLOC (2016). http://cloc.sourceforge.net/
[20] Count Lines of Code - CLOC Git (2016). https://github.com/AlDanial/cloc
[21] Implementation Basic Class Editor MoDiGen and JAVA (2016).
http://www.modigen.de/BasicClassEditor/
[22] Evaluation Plan (2016). http://www.modigen.de/evaluation/Evaluierungsplan-MoDiGen-DSLs.htm
[23] Evaluation Report (2016). http://www.modigen.de/evaluation/Evaluationsbericht-MoDiGen-
DSLs.htm
[24] Hutchinson, J., Whittle, J., Rouncefield, M., &Kristoffersen, S. (2011, May). Empiricalassessmentof
MDE in industry. In Proceedingsofthe 33rd International Conference on Software Engineering (pp.
471-480). ACM.
[25] Johannes, J., & Aßmann, U. (2010, October). Concern-based (de) compositionof model-
drivensoftwaredevelopmentprocesses. In International Conference on Model Driven Engineering
Languagesand Systems (pp. 47-62). Springer Berlin Heidelberg.
[26] Kalleberg, K. T., & Visser, E. (2007, March). Spoofax: An
interactivedevelopmentenvironmentforprogramtransformationwithStratego/XT. In A. Johnstone, & T.
Sloane (Eds.), Workshop on Language Descriptions, Tools, andApplications (LDTA 2007) (pp. 47-
50).
[27] Kolovos, D. S., Rose, L. M., Paige, R. F., & Polack, F. A. (2009, May). Raisingthelevelofabstraction
in thedevelopmentof GMF-basedgraphicalmodeleditors. In Proceedingsofthe 2009 ICSE Workshop
on Modeling in Software Engineering (pp. 13-19). IEEE Computer Society.
[28] Kolovos, D. S., Rose, L. M., Abid, S. B., Paige, R. F., Polack, F. A., &Botterweck, G. (2010,
October). Taming EMF and GMF usingmodeltransformation. In International Conference on Model
Driven Engineering Languagesand Systems (pp. 211-225). Springer Berlin Heidelberg.
[29] Object Management Group: Business Process Model and Notation, Speci_cation V2.0.
http://www.omg.org/spec/BPMN/2.0/PDF, Needham, Massachusetts, VereinigteStaaten (2011).
Accessed 2015-01-22
[30] Rubel, D., Wren, J., &Clayberg, E. (2011). The EclipseGraphicalEditing Framework (GEF). Addison-
Wesley Professional.
[31] Smolander, K., Lyytinen, K., Tahvanainen, V. P., &Marttiin, P. (1991, May). MetaEdit—a flexible
graphicalenvironmentformethodologymodelling. InInternational Conference on Advanced
Information Systems Engineering (pp. 168-193). Springer Berlin Heidelberg.
[32] Pietrek, G., & Trompeter, J. (2007). Modellgetriebene Softwareentwicklung-MDA und MDSD in der
Praxis; entwickler. press. Frankfurt am Main.
[33] Vara, J. M., & Marcos, E. (2012). A frameworkfor model-drivendevelopmentofinformationsystems:
Technical decisionsandlessonslearned. Journal of Systems and Software, 85(10), 2368-2384.
[34] Mernik, M., Heering, J., &Sloane, A. M. (2005). Whenandhowtodevelop domain-specificlanguages.
ACM computingsurveys (CSUR), 37(4), 316-344.
19. International Journal of Computer Science & Information Technology (IJCSIT) Vol 8, No 5, October 2016
89
[35] Steinberg, D., Budinsky, F., Merks, E., &Paternostro, M. (2008). EMF: eclipsemodelingframework.
Pearson Education.
[36] Rubel, D., Wren, J., &Clayberg, E. (2011). The EclipseGraphicalEditing Framework (GEF). Addison-
Wesley Professional.
[37] Draw2D, E. Project Homepage.
[38] Refsdal, I. (2011). Comparisonof GMF and Graphiti based on experiencesfromthedevelopmentofthe
PREDIQT tool. University of Oslo.
[39] Gronback, R. C. (2009). Eclipsemodelingproject: a domain-specificlanguage (DSL) toolkit. Pearson
Education.
[40] Moritz Eysholdt and Heiko Behrens. (2010). Xtext: implement your language faster than the quick
and dirty way. In Proceedings of the ACM international conference companion on Object oriented
programming systems languages and applications companion (OOPSLA '10). ACM, New York, NY,
USA, 307-309.
AUTHORS
Markus Gerhart studied business computer science with a focus on Software
Engineering at the University of applied science Konstanz. He then completed a master's
degree in the study program with a focus on business processes modelling and model
driven software development and is currently a PhD student of Prof. Dr. Marko Boger in
the area of the model-driven software development.
Prof. Dr. Marko Boger studied in Karlsruhe (Germany) and Toulouse (France) and
received his doctor degree in Aachen and Hamburg (both Germany). Then he founded the
company Gentleware, which was in the area of graphical modeling one of the leading
tools in 2002. He was actively involved in the standardization of UML 2 as a head of the
working group. Since 2009 he is professor of software engineering and software
architecture at the University of applied science Konstanz.