JetBrains just released version 1.0 of its Meta Programming System.
The screencasts provided by Markus Völter are very nice. They show how the Java base language can be extended by a lock abstraction, which is translated to some best practice lock code by the generator component afterwards. This seems to be a good example of growing a language as motivated by Guy L. Steele Jr.
I wonder whether multiparadigm programming could be supported that way more straightforwardly. So, one could not only generate imperative code from imperative abstractions, but one also could generate imperative code from an embedded functional program, right? Also it seems to be promising to integrate visual languages. That way, one could specify a method's body not only by Java code, but alternatively with, say, activity diagrams. However, currently only the creation of editors for textual and tabular representations seems to be supported.
All in all, MPS is a promising system, but regarding performance there seems to be plenty of potential for improvements (it took really long to load the simplest possible language for the first time, which raises the question how long it would take to load something real - on the other hand the system seems to be bootstrapped, which usually is an indicator of maturity). The language oriented programming approach as a whole of course is also heavily disputed, cf. this discussion.
Showing posts with label modeling. Show all posts
Showing posts with label modeling. Show all posts
July 24, 2009
July 18, 2009
Alligator Eggs (for the last time)
Now I have also constructed an editor for alligator eggs. This editor is different from Torsten's editor with the nice animation discussed some days ago. My editor provides syntax-based user assistance instead, i.e. the user gets help in creating syntactically correct alligator eggs expressions. Whereas Torsten's editor has been created with DiaMeta (syntax defined by a class diagram), my approach relies on the DiaGen framework (syntax defined by a graph grammar).
Here is a screencast:
And here is the executable jar.
The underlying hyperedge replacement grammar is very straightforward and close to the textual lambda grammar:
Here is a screencast:
And here is the executable jar.
The underlying hyperedge replacement grammar is very straightforward and close to the textual lambda grammar:
July 15, 2009
Alligator Eggs revisited (again)
The video about the animated editor for Alligator Eggs has raised some questions on where the editor is available for download. Therefore, Torsten has provided an executable jar. Feel free to try it out yourself!
Actually, the success of this video on youtube (more than 3.000 views already) really motivates me to implement syntax-based assistance for the language of alligator eggs. The language is tree-based, i.e., context-free, so that the developed approach is applicable. I hope to find some time in the near future to this end.
Actually, the success of this video on youtube (more than 3.000 views already) really motivates me to implement syntax-based assistance for the language of alligator eggs. The language is tree-based, i.e., context-free, so that the developed approach is applicable. I hope to find some time in the near future to this end.
Business Process Models
In the last weeks I have developed an editor for business process models with syntax-based user assistance as described in previous blog posts. A screencast of this editor is shown below:
The editor is provided for download as an executable jar.
Concepts and realization are described in S. Mazanek, M. Minas. Business Process Models as a Showcase for Syntax-based Assistance in Diagram Editors. Appears in Proc. of the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems (MODELS 2009), 2009. The original publication will be available at www.springerlink.com.
The editor is provided for download as an executable jar.
Concepts and realization are described in S. Mazanek, M. Minas. Business Process Models as a Showcase for Syntax-based Assistance in Diagram Editors. Appears in Proc. of the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems (MODELS 2009), 2009. The original publication will be available at www.springerlink.com.
July 05, 2008
Constraint Logic Programming and Diagram Completion
I got stimulating feedback after my last post on diagram completion. For instance, I was not aware of the SmartEMF project of Anders Hessellund et al. They aim at extending EMF with an inference engine to facilitate reasoning about models. Interestingly, they also get some guidance that way. A similar approach has been realized in the AToM3 tool by Sagar Sen et al. They also employ constraint logic programming to infer model completions.
The diagram completion presented in my last post has been incorporated into the DiaGen tool which is based on hyperedge replacement grammars. However, metamodels are more popular nowadays for language specification. I already introduced the DiaMeta tool on this blog. It is based on DiaGen, but allows the generation of free-hand editors out of a metamodel-based specification. Syntax analysis then can be mapped to the solution of a constraint satisfaction problem. It would be interesting to see if the approaches of Hessellund and Sen could be used to get similar diagram completion for DiaMeta.
Dear readers, please continue to comment on my posts or give feedback by mail. I appreciate this very much. If your own project is related somehow to visual languages, do not hesitate and send me a short summary. I gladly post and/or discuss it here on this blog.
Further reading:
The diagram completion presented in my last post has been incorporated into the DiaGen tool which is based on hyperedge replacement grammars. However, metamodels are more popular nowadays for language specification. I already introduced the DiaMeta tool on this blog. It is based on DiaGen, but allows the generation of free-hand editors out of a metamodel-based specification. Syntax analysis then can be mapped to the solution of a constraint satisfaction problem. It would be interesting to see if the approaches of Hessellund and Sen could be used to get similar diagram completion for DiaMeta.
Dear readers, please continue to comment on my posts or give feedback by mail. I appreciate this very much. If your own project is related somehow to visual languages, do not hesitate and send me a short summary. I gladly post and/or discuss it here on this blog.
Further reading:
- Anders Hessellund, Krzysztof Czarnecki, Andrzej Wasowski: Guided Development with Multiple Domain-Specific Languages. In Proc. of MODELS'07, 2007
- Sagar Sen, Benoit Baudry, and Hans Vangheluwe: Domain-specific model editors with model completion. In Multi-paradigm Modelling Workshop at MoDELS'07, 2007.
- Mark Minas: Syntax analysis for diagram editors: A constraint satisfaction problem. In Proc. of the Working Conference on Advanced Visual Interfaces (AVI'2006), 2006.
February 22, 2008
Bidirectional synchronization
The effort of blogging already seems to pay off as I start to get mails with interesting references to related work. Yesterday Miguel Garcia pointed me to his workshop paper Bidirectional Synchronization of Multiple Views of Software Models.
What I liked about the paper is its discussion of related work and the references that give a very comprehensive overview of the state of the art in this field, i.e., Miguel discusses with a bird's eye view approaches to solve the view update problem like program inversion, lenses, QVT, ATL and TGG (triple graph grammars, to be discussed in the future). Indeed, in my research on diagram editors I currently have to deal with the problem of reflecting changes on the abstract syntax level back to concrete syntax (and vice versa, of course).
Abstract of Miguel's paper:
Current best-practices for defining Domain-Specific Modeling Languages call for metamodeling techniques, which do not take into account the future use of such languages in multiview design environments. Tool implementers have tried a variety of ad-hoc techniques to maintain views in-synch, with modest results. To improve this state of affairs, a declarative approach is elaborated to automate multiview synchronization, building upon existing metamodeling techniques and recent advances in the field of function inversion for bidirectionalization. An application of these ideas to EMOF and a discussion of the resulting Declarative MVC software architecture are also provided. A significant benefit of the approach is the resulting comprehensive solution to a recurrent problem in the software modeling field.
I look forward to further external contributions!
What I liked about the paper is its discussion of related work and the references that give a very comprehensive overview of the state of the art in this field, i.e., Miguel discusses with a bird's eye view approaches to solve the view update problem like program inversion, lenses, QVT, ATL and TGG (triple graph grammars, to be discussed in the future). Indeed, in my research on diagram editors I currently have to deal with the problem of reflecting changes on the abstract syntax level back to concrete syntax (and vice versa, of course).
Abstract of Miguel's paper:
Current best-practices for defining Domain-Specific Modeling Languages call for metamodeling techniques, which do not take into account the future use of such languages in multiview design environments. Tool implementers have tried a variety of ad-hoc techniques to maintain views in-synch, with modest results. To improve this state of affairs, a declarative approach is elaborated to automate multiview synchronization, building upon existing metamodeling techniques and recent advances in the field of function inversion for bidirectionalization. An application of these ideas to EMOF and a discussion of the resulting Declarative MVC software architecture are also provided. A significant benefit of the approach is the resulting comprehensive solution to a recurrent problem in the software modeling field.
I look forward to further external contributions!
January 06, 2008
ER diagrams
In the last days I had to deal a lot with entity relationship (ER) diagrams, because I have to conduct exercises for a database course. ER diagrams have been developed in the seventies by Chen and are a widely used visual language for the conceptual design of database systems. Further in my last post I described the tool AToM3 whose main formalism is ER.
This figure is from the wikipedia article and shows an exemplary ER diagram.
To my surprise there seem to be no freeware or open source tools that allow the drawing of ER diagrams in the commonly used notations, i.e. the original one by Chen plus some conservative extensions like Min-Max etc. I have tried several of the free tools referenced in the wikipedia article on ER like BrModelo (only in portuguese language), Ferret (platform-specific and not very feature-rich), MySQL workbench (proprietary notation and MySQL-focused) and even some of the commercial ones like SmartDraw and MS Visio. But none of them is as feature-rich as one might expect in the context of such an old visual language.
Using DiaMeta, for instance, it would be possible to specify a compliant and feature-rich ER editor in a very short time. One even could apply a EMF-based model transformation with, e.g., ATL to derive the corresponding database schema.
Did I miss a tool that is freely available, provides an interface in English language and conforms to the widely-adopted concrete syntax? Any further references are greatly appreciated.
This figure is from the wikipedia article and shows an exemplary ER diagram.
To my surprise there seem to be no freeware or open source tools that allow the drawing of ER diagrams in the commonly used notations, i.e. the original one by Chen plus some conservative extensions like Min-Max etc. I have tried several of the free tools referenced in the wikipedia article on ER like BrModelo (only in portuguese language), Ferret (platform-specific and not very feature-rich), MySQL workbench (proprietary notation and MySQL-focused) and even some of the commercial ones like SmartDraw and MS Visio. But none of them is as feature-rich as one might expect in the context of such an old visual language.
Using DiaMeta, for instance, it would be possible to specify a compliant and feature-rich ER editor in a very short time. One even could apply a EMF-based model transformation with, e.g., ATL to derive the corresponding database schema.
Did I miss a tool that is freely available, provides an interface in English language and conforms to the widely-adopted concrete syntax? Any further references are greatly appreciated.
AToM3
I am back from vacation and continue reporting about the seminar talks. On 29.11.07 we discussed the tool AToM3, a research project of Hans Vangheluwe and Juan de Lara.
AToM3 is an acronym for "A Tool for Multi-formalism and Meta-Modelling". From my point of view its main features are:
AToM3 is a very interesting research tool. There are a lot of publications discussing particular aspects of the tool and its theoretical foundations. However, it seems not to be ready for production settings yet. Parts of the documentation are outdated and even the Hello-World example caused several exceptions (but I got it up and running) and useless warnings like "Bad things will happen". However, as a researcher in the area of graph transformation you have to deal with the tool or at least with the publications by all means.
Further reading:
AToM3 is an acronym for "A Tool for Multi-formalism and Meta-Modelling". From my point of view its main features are:
- meta CASE-tool: specify a visual language (formalism) and generate an environment
- homogeneous view on metamodelling: define models in a particular formalism and use them directly as a formalism again, for instance, a petri net formalism can be defined using the ER (entity relationship) formalism and in the following real petri nets can be drawn; most of AToM3 can be bootstrapped (even user interaction)
- model transformations: internally models are represented as graphs, graph grammars can be defined and used for model transformation
AToM3 is a very interesting research tool. There are a lot of publications discussing particular aspects of the tool and its theoretical foundations. However, it seems not to be ready for production settings yet. Parts of the documentation are outdated and even the Hello-World example caused several exceptions (but I got it up and running) and useless warnings like "Bad things will happen". However, as a researcher in the area of graph transformation you have to deal with the tool or at least with the publications by all means.
Further reading:
December 15, 2007
DiaMeta
So, today I continue blogging here. Kindly excuse the fairly long period without a post. The submission deadline for the conference GTVMT was so rapidly approaching...
The next talk in our seminar was about DiaMeta, the successor of the diagram editor generator DiaGen. In contrast to DiaGen DiaMeta is based on a metamodel instead of a hypergraph grammar. Not that metamodels are more powerful: this truly is not the case. But people are so familiar with drawing class diagrams aka metamodels that nowadays metamodel-based tools are more popular.
DiaMeta is based on the Eclipse Modeling Framework we already have discussed (there also is an experimental version based on MOF, see references below). This is very benefitial from an application integration point of view, because the abstract syntax of diagrams can be serialized in standard compliant XMI.
The most interesting point to know about syntax analysis is that it is basically performed by solving a constraint satisfaction problem. This important correlation has been noticed by Minas 2006. Therefore DiaMeta has to make heavy use of the powerful reflective features EMF provides.
The picture shows the overall DiaMeta architecture. There are two important differences to DiaGen. The first one is that the reducer does not create a reduced hypergraph model any more, but instead a so-called instance graph. This is a graph whose nodes are marked with class names of the metamodel and whose edges represent references. However, these annotations do not have to be the concrete object types (they even can be names of abstract classes). It is the task of the so-called checker, the second important difference!, to map these nodes to non-abstract classes and instantiate corresponding objects. The instance graph is therefore used as a constraint net that can be solved using the information given in the metamodel, e.g. references, inheritance relationships, cardinalities, etc. This is described in detail in the first paper mentioned in Further reading.
Further reading:
The next talk in our seminar was about DiaMeta, the successor of the diagram editor generator DiaGen. In contrast to DiaGen DiaMeta is based on a metamodel instead of a hypergraph grammar. Not that metamodels are more powerful: this truly is not the case. But people are so familiar with drawing class diagrams aka metamodels that nowadays metamodel-based tools are more popular.
DiaMeta is based on the Eclipse Modeling Framework we already have discussed (there also is an experimental version based on MOF, see references below). This is very benefitial from an application integration point of view, because the abstract syntax of diagrams can be serialized in standard compliant XMI.
The most interesting point to know about syntax analysis is that it is basically performed by solving a constraint satisfaction problem. This important correlation has been noticed by Minas 2006. Therefore DiaMeta has to make heavy use of the powerful reflective features EMF provides.
The picture shows the overall DiaMeta architecture. There are two important differences to DiaGen. The first one is that the reducer does not create a reduced hypergraph model any more, but instead a so-called instance graph. This is a graph whose nodes are marked with class names of the metamodel and whose edges represent references. However, these annotations do not have to be the concrete object types (they even can be names of abstract classes). It is the task of the so-called checker, the second important difference!, to map these nodes to non-abstract classes and instantiate corresponding objects. The instance graph is therefore used as a constraint net that can be solved using the information given in the metamodel, e.g. references, inheritance relationships, cardinalities, etc. This is described in detail in the first paper mentioned in Further reading.
Further reading:
- Generating meta-model-based freehand editors. Minas, Proc. of 3rd International Workshop on Graph Based Tools (GraBaTs'06), 2006.
- Syntax analysis for diagram editors: A constraint satisfaction problem. Minas, In Proc. of the Working Conference on Advanced Visual Interfaces (AVI'2006), 2006.
- Generating visual editors based on Fujaba/MOFLON and DiaMeta. Minas, Proc. Fujaba Days 2006
- DiaMeta website
November 26, 2007
ATL and AMW
The next talk in our seminar was about ATL, the ATLAS transformation language. The talk took place on November 15, 2007, the same day we already discussed MOF QVT. The main difference between ATL and QVT is, that QVT is just a specification whereas ATL is both a language AND an implementation.
We just recall the essence of model transformation. Say, we want to define a model transformation between two metamodels MMa and MMb (think of them as source and target language). Such a transformation allows us to transform instances Ma of MMa into instances Mb of MMb. Usually the metamodels have to conform to a common metametamodel MMM. Further we usually have a transformation metamodel MMt, i.e. a language our transformation Mt can be defined in.
ATL is based on the Eclipse platform. Here it can, for instance, be used to define transformations between Ecore models. The picture on the left side shows how the picture above (both taken from the ATL Starter Guide) is instantiated by ATL.
We cannot discuss the differences of ATL and QVT here in detail (there is a paper addressing their alignment, see below), however, we can give some reasons why ATL also is important:
Note, that a nice thing about model transformation is that you can even transform transformations. There is an ATL usecase QVT2ATLVM that transforms a QVT transformation to an ATL transformation.
Further reading:
We just recall the essence of model transformation. Say, we want to define a model transformation between two metamodels MMa and MMb (think of them as source and target language). Such a transformation allows us to transform instances Ma of MMa into instances Mb of MMb. Usually the metamodels have to conform to a common metametamodel MMM. Further we usually have a transformation metamodel MMt, i.e. a language our transformation Mt can be defined in.
ATL is based on the Eclipse platform. Here it can, for instance, be used to define transformations between Ecore models. The picture on the left side shows how the picture above (both taken from the ATL Starter Guide) is instantiated by ATL.
We cannot discuss the differences of ATL and QVT here in detail (there is a paper addressing their alignment, see below), however, we can give some reasons why ATL also is important:
- Model transformation is young. We do not have as many experiences in the field as we should have to define a standard already. Therefore a broader variety of tools and languages is useful.
- ATL works. It is smoothly integrated into Eclipse, well-documented, has its own IDE (debugger, etc.) and an active community that gladly offers support via the newsgroup, etc. For QVT there are tools already, however, they are not that mature yet.
- ATL is different. It provides interesting concepts not included in QVT. AMW (ATLAS Model Weaver), for instance, is the ATL way to describe model transformations on a more abstract level. Further ATL offers e.g. rule refinement (copy all elements that are not addressed by a rule) and a model handler abstraction layer, i.e. different model handlers can be used (e.g. for EMF, MDR, etc.).
Note, that a nice thing about model transformation is that you can even transform transformations. There is an ATL usecase QVT2ATLVM that transforms a QVT transformation to an ATL transformation.
Further reading:
- ATL
- Atlas Model Weaver (AMW)
- On the Architectural Alignment of ATL and QVT, Jouault, F., and Kurtev, I., Proceedings of ACM Symposium on Applied Computing (SAC 06)
November 23, 2007
UML2 Certification Guide
This is a short review of the book "UML2 Certification Guide - Fundamental & Intermediate Exams" by Weilkiens and Oesterreich.
The purpose of the book is to prepare for the UML exams of the OMG, a way to certify different levels of knowledge about the UML.
This book is NOT for learning UML. It does not focus on UML diagrams, but on the abstract syntax of UML as defined in the specification. The book is structured in three parts: an introduction that provides information about the history of UML, the OMG and the exams, and two main parts introducing the examination relevant knowledge for the OCUP Fundamental exam and the OCUP Intermediate exam, respectively.
Good:
Bad:
Conclusion: If the book really covers exactly the material of the exams - as the authors claim - it is valuable in this respect. Further on several example questions are provided that may also be helpful. However, on the OMG site the examination relevant parts of the specification are also given as colored tables of contents. And since the book is not that good from a methodical point of view people that are familiar with reading specifications may not really need the book. However, since the price is ok I do not regret having bought it. But reading the specification is still necessary.
Further reading:
The purpose of the book is to prepare for the UML exams of the OMG, a way to certify different levels of knowledge about the UML.
This book is NOT for learning UML. It does not focus on UML diagrams, but on the abstract syntax of UML as defined in the specification. The book is structured in three parts: an introduction that provides information about the history of UML, the OMG and the exams, and two main parts introducing the examination relevant knowledge for the OCUP Fundamental exam and the OCUP Intermediate exam, respectively.
Good:
- complete coverage of examination relevant parts of specification (at least the authors claim so)
- example questions
- price ok
Bad:
- not self-contained: concepts crucial for understanding the diagrams like
union andsubsets are not introduced at all, the stucture of the specification is not discussed (infrastructure, superstructure, mof, etc.) - too many annoying little errors
- didactically not state of the art
Conclusion: If the book really covers exactly the material of the exams - as the authors claim - it is valuable in this respect. Further on several example questions are provided that may also be helpful. However, on the OMG site the examination relevant parts of the specification are also given as colored tables of contents. And since the book is not that good from a methodical point of view people that are familiar with reading specifications may not really need the book. However, since the price is ok I do not regret having bought it. But reading the specification is still necessary.
Further reading:
MetaEdit+
MetaEdit+ is a commercial tool for both the design and use of (domain-specific) modeling languages (a meta-CASE-tool).
The underlying metamodeling language in MetaEdit+ is called GOPPRR and is very simple. There are just Properties and Non-Properties (which in turn can have Properties again). Non-Property-Types are Graph, Object, Port, Role and Relationship, and for each of these types there is a creation wizzard/form.
A feature that distinguishes MetaEdit+ from other tools is its symbol editor. You do not have to specify the concrete syntax by hand. Rather you just draw the component in a WYSIWYG-style which makes the object creation process very simple. In particular it is not necessary to define the mapping between abstract and concrete syntax explicitly like in GMF (to be discussed in a later post).
The relationships are specified by providing a so-called binding that tells the system which object types may be linked together and in which roles. The graph tool finally lets you draw the instances of your metamodel, your diagrams. As the name of this tool already suggests MetaEdit+ is best-suited for graph-like languages. Languages that make heavy use of spatial relations (like VEX, NSD and others) are difficult to create in MetaCASE. However, a lot of practically relevant languages have a graph structure.
Some advantages of MetaEdit+:
And some little disadvantages:
Conclusion: This tool is definitely worth a try. It is well suited for the rapid development of CASE tools for all kinds of graph-like visual languages.
Further reading:
The underlying metamodeling language in MetaEdit+ is called GOPPRR and is very simple. There are just Properties and Non-Properties (which in turn can have Properties again). Non-Property-Types are Graph, Object, Port, Role and Relationship, and for each of these types there is a creation wizzard/form.
A feature that distinguishes MetaEdit+ from other tools is its symbol editor. You do not have to specify the concrete syntax by hand. Rather you just draw the component in a WYSIWYG-style which makes the object creation process very simple. In particular it is not necessary to define the mapping between abstract and concrete syntax explicitly like in GMF (to be discussed in a later post).
The relationships are specified by providing a so-called binding that tells the system which object types may be linked together and in which roles. The graph tool finally lets you draw the instances of your metamodel, your diagrams. As the name of this tool already suggests MetaEdit+ is best-suited for graph-like languages. Languages that make heavy use of spatial relations (like VEX, NSD and others) are difficult to create in MetaCASE. However, a lot of practically relevant languages have a graph structure.
Some advantages of MetaEdit+:
- great support, I even got a personal web demonstration with special emphasis on my specific questions
- easy to install and use
- feature-rich, e.g. nice editor for components
- lots of examples and documentation
- highly integrated
- Model2Code transformation possible
And some little disadvantages:
- no explicit support for spatial relations
- closed source, expensive (its a commercial tool after all, evaluation is free and they also provide an academic license, though)
- no free-hand editing like e.g. in DiaGen/DiaMeta (to be described later)
- version control not so good (but possible, some best practices are suggested)
Conclusion: This tool is definitely worth a try. It is well suited for the rapid development of CASE tools for all kinds of graph-like visual languages.
Further reading:
- MetaEdit+ Workbench for the design of modeling languages
- MetaEdit+ Modeler to use (i.e. create instances of) an already defined modeling language
- Advanced Tooling for Domain-Specific Modeling: MetaEdit+, Tolvanen et al., 2007
November 17, 2007
MOF QVT
This post is about MOF QVT (Query/View/Transformation), a model transformation language we also discussed in the course of our seminar (November 15, 2007). First of all lets briefly explain these three terms:
The focus of MOF QVT is clearly on transformations.
Transformations can be classified in several ways. We describe some providing examples at the same time:
Similar to programming languages different paradigms are possible to describe a model transformation: operational (the sequence of steps necessary to produce the result) and declarative (only relationships between model elements are described). QVT follows a hybrid approach, i.e. both paradigms are supported.
The abstract syntax of QVT itself is defined using MOF. However, in the specification a textual as well as a visual notation for the definition of a transformation are given.
We cannot introduce these languages here in detail, however, we provide a short teaser (taken directly from the specification, chapter 7):
This is an excerpt from the classical example, the transformation of a class diagram to a relational database schema, a relational description of the mapping between a class and a table. Visually this can be expressed as shown in the image on the left side.
QVT is a very new language so tool support is quite limited up to now. The operational part is implemented e.g. in the tool SmartQVT. In the next post I will shortly introduce ATL, the ATLAS transformation language, that is not a QVT implementation but that provides a very mature and widely-used model transformation language on its own.
At the moment there is a lot of discussion on how to bring together graph transformation (see, e.g., my introductory post about Graph Transformation) and QVT. I will discuss this together with the introduction of triple graph grammars in a later post.
Further reading:
- A query basically is an expression evaluated over a model. OCL is a prominent example of a query language that we will discuss in a future post.
- A model completely derived from another model is called a view. Mostly views are not persistent and cannot be changed independent from their base model.
- A program that generates a target model from a source model is called a transformation.
The focus of MOF QVT is clearly on transformations.
Transformations can be classified in several ways. We describe some providing examples at the same time:
- horizontal vs. vertical: In contrast to horizontal transformations a vertical transformation changes the level of abstraction. Examples: class diagram to relational database schema (horizontal), model to code (vertical)
- unidirectional vs. bidirectional: Direction of the transformation and the way how changes can be propagated
- input/output cardinalities: number of input and output models
Similar to programming languages different paradigms are possible to describe a model transformation: operational (the sequence of steps necessary to produce the result) and declarative (only relationships between model elements are described). QVT follows a hybrid approach, i.e. both paradigms are supported.
The abstract syntax of QVT itself is defined using MOF. However, in the specification a textual as well as a visual notation for the definition of a transformation are given.
We cannot introduce these languages here in detail, however, we provide a short teaser (taken directly from the specification, chapter 7):
relation UML2Rel {
checkonly domain uml1
c:Class {name = n, attribute = a:Attribute{name = an}}
checkonly domain r1
t:Table {name = n, column = col:Column{name = an}}
}
This is an excerpt from the classical example, the transformation of a class diagram to a relational database schema, a relational description of the mapping between a class and a table. Visually this can be expressed as shown in the image on the left side.
QVT is a very new language so tool support is quite limited up to now. The operational part is implemented e.g. in the tool SmartQVT. In the next post I will shortly introduce ATL, the ATLAS transformation language, that is not a QVT implementation but that provides a very mature and widely-used model transformation language on its own.
At the moment there is a lot of discussion on how to bring together graph transformation (see, e.g., my introductory post about Graph Transformation) and QVT. I will discuss this together with the introduction of triple graph grammars in a later post.
Further reading:
November 15, 2007
EMF and MOF
On November 8, 2007 the student presentation about the metamodeling frameworks EMF and MOF took place. Note, that on this blog there will be many more posts about EMF and MOF (in fact, theses metamodeling frameworks are an essential part of my research), so that this initial post is just to give you a start.
So, why do we need metamodels? In computer science we usually describe objects of the real world in terms of models, e.g. by providing a UML class diagram. Advantages of this approach are, amongst others, that we gain more understanding of the particular application domain. A modeling language itself can be very complex as well. For instance, the UML specification consists of hundreds of pages. For such a modeling language it is even more important to be defined as formal and precise as possible, so it is quite self-evident to apply the modeling approach to the modeling language itself. Dealing with a modeling language itself is called metamodeling to avoid confusion. The classical picture on the left from the UML Infrastructure specification (chapter 7) provides a good understanding of this issue. You see that the components of a class diagram can be modeled by (you probably already guess it) a class diagram again. For instance, we could define, that a class may contain several attributes and so on (a composition association between the metaclasses Class and Attribute).
So the language UML is defined on level M2. However, we are not ready yet. We still have not specified how a language like UML can be defined. We raise the level of abstraction once more and get MOF, a language to describe languages (calm down, you do not have to learn yet another language from scratch, because MOF makes heavy use of the well-known class diagrams). Of course we could continue this procedure ad infinitum, but here are the good news: MOF can be described just using itself. So we are done (at least at the moment ;-)).
Why do we need yet another modeling framework? Is MOF not enough to describe arbitrary languages? Yes, in principle it is. But it has two disadvantages:
In contrast, EMF is widely used. It is integrated in the popular Eclipse platform, provides a powerful code generator and is easy to use. Its Metametamodel is called Ecore. You can think of it as the practically relevant subset of MOF (some quite useful features of MOF, however, are lost).
To conclude, the main advantages of Metamodeling are:
Further reading:
Metalayers up to MOF
So, why do we need metamodels? In computer science we usually describe objects of the real world in terms of models, e.g. by providing a UML class diagram. Advantages of this approach are, amongst others, that we gain more understanding of the particular application domain. A modeling language itself can be very complex as well. For instance, the UML specification consists of hundreds of pages. For such a modeling language it is even more important to be defined as formal and precise as possible, so it is quite self-evident to apply the modeling approach to the modeling language itself. Dealing with a modeling language itself is called metamodeling to avoid confusion. The classical picture on the left from the UML Infrastructure specification (chapter 7) provides a good understanding of this issue. You see that the components of a class diagram can be modeled by (you probably already guess it) a class diagram again. For instance, we could define, that a class may contain several attributes and so on (a composition association between the metaclasses Class and Attribute).
So the language UML is defined on level M2. However, we are not ready yet. We still have not specified how a language like UML can be defined. We raise the level of abstraction once more and get MOF, a language to describe languages (calm down, you do not have to learn yet another language from scratch, because MOF makes heavy use of the well-known class diagrams). Of course we could continue this procedure ad infinitum, but here are the good news: MOF can be described just using itself. So we are done (at least at the moment ;-)).
EMF
Why do we need yet another modeling framework? Is MOF not enough to describe arbitrary languages? Yes, in principle it is. But it has two disadvantages:
- The MOF language is very powerful. Yes, indeed this can be a disadvantage, because you have to understand the concepts to use it. And the standard is very big.
- The MOF language lacks tool support. Currently there is no widely used and mature tool for MOF. This may change in the future. The research tool MOFLON is quite powerful already and may fill this gap.
In contrast, EMF is widely used. It is integrated in the popular Eclipse platform, provides a powerful code generator and is easy to use. Its Metametamodel is called Ecore. You can think of it as the practically relevant subset of MOF (some quite useful features of MOF, however, are lost).
To conclude, the main advantages of Metamodeling are:
- Precise definition of languages
- Helpful for developing CASE tools
- Use of Reflection possible (exploiting information about the model at runtime)
Further reading:
- OMG's MOF
- MOF Specification
- MOFLON, a MOF diagram editor and meta-CASE tool
- EMF Website
- Eclipse Modeling Framework, Budinsky, Steinberg, Merks, Ellersick, Grose, 2003: standard book, however, do not buy it now but wait for the new version that will appear very soon
Subscribe to:
Posts (Atom)