Embed Size (px)
Citation preview
Comparing three graphical DSL editors: AToM3,
MetaEdit+ and Poseidon for DSLs
Philip De Smedt
Abstract
Domain specific modeling (DSM) is a software engineering methodology fordesigning and developing complex systems. Modeling a system through agraphical domain-specific language (DSL) allows the user to rapidly iteratethrough different prototypes and represent them at various levels of abstrac-tion. This papers investigates three different graphical DSL editors and com-pares them based on a set of fixed criteria. All DSL editors will be evaluatedbased on a case study. A simple domain-specific language for the simula-tion of traffic will be built. Afterwards, all three solutions are compared andsummarized in a feature table.
Keywords:Domain specific modeling, domain-specific language, AToM3, MetaEdit+,Poseidon
1. Introduction
Modern software design has reached a complexity that requires well-defined engineering methods and model-based approaches to ensure correct-ness. Complex systems are becoming extremely heterogeneous and the manyengineering disciplines that are involved in system design all require problem-specific formalisms. In order to address these issues, developers have turnedto modeling and simulation techniques (1). A company expert defines adomain-specific language in a DSL tool and a set of generators will trans-form models to certain artifacts the company needs (like source code). Thisarticle discusses three different graphical domain-specific language editorsand compares them by means of a case study. In this particular case, a sim-ple traffic formalism is built in AToM3 (2), MetaEdit+ (3) and Poseidon for
Preprint submitted to Elsevier June 29, 2011
DSLs (4).
This article first introduces the traffic formalism that will be considered insection 2. Section 3 discusses the various DSL editors and compares thembased on some fixed set of criteria 1. Next, section 4 concentrates on theresults of the previous comparison section. Finally, a conclusion based onthese results is presented in the final section.
2. Problem Statement
A simple traffic formalism is built in respectively AToM3, MetaEdit+ andPoseidon for DSLs. All functionality should be the same in every solution.A typical solution consists of some basic building blocks, such as differenttypes of road segments (road, fork and join), a traffic light and a capacityobject that is able to limit the number of cars on each road segment. Garageobjects are used to generate cars and a sink represents the end of a road, soall road models containing a sink segment are considered finite.
Within each DSL editor, a meta-model for the traffic formalism is con-structed. Based on the editors’ idioms, certain protocols have been followed.Section 3 handles about the differences and similarities in each of these DSLtools.
3. Comparison
3.1. AToM3
AToM3 is a tool for multi-paradigm modeling under development at theModeling, Simulation and Design Lab (MSDL) at McGill University in Canada.Its two main tasks are meta-modeling and model transformation. The toolis completely written in Python, but is currently only available for Win-dows and Linux due to some incompatibilities on Mac OS with python-tklibraries. AToM3 offers a Python API and delivers built-in meta-models likeEntity-Relationship, Petri Nets and Finite State Automata.
1Please note that not necessarily all features have been tested in every tool, but onlythose needed for the case study. Tools may offer more useful features and the mostimportant ones will therefore be covered briefly.
2
3.1.1. Documentation
AToM3 provides some illustrated tutorials on how to use the tool. Thesetutorials handle about basic and advanced functionality, as well as the cre-ation of graph grammars. A particularly interesting section in the documen-tation is the AToM3 programming tutorial: the use of the AToM3 PythonAPI. This document describes the AToM3 API and other design issues whichcan be of interest if the developer is planning to modify AToM3 itself, developa complex meta-model or graph grammar.
3.1.2. Abstract Syntax
AToM3 allows the creation of metamodels through a formalism calledCD ClassDiagramsV3. The formalism is made out of two basic buildingblocks, namely a class and an association between two classes. Classes canbe inherited, as shown in figure 1. This figure illustrates the traffic formalismin AToM3. Models and meta-models are stored as Abstract Syntax Graphs(ASG) whose nodes and links are typed, and their relationships are subjectto constraints dictated by the formalism (5). One of the main advantagesin AToM3 is its use of n-ary relationships. Objects in AToM3 are allowedto have a relationship with an arbitrary number of other objects. These so-called hyperedges are especially useful when a particular object should beassociated with more than one other object.
3.1.3. Concrete Syntax
AToM3 does not create generic symbols by default. Language developersshould create or import their own custom symbols in the AToM3 vectortool. This aspect creates a very strong binding between the abstract andconcrete syntax, for there can only be a graphical representation of a conceptwhen the developer has specified one. Symbols may contain text or propertyvalues extracted from their abstract syntax objects and can only have onerepresentation.
3.1.4. Semantics
Semantics specification is one of the great powers of AToM3. For everyclass in a meta-model, it is possible to specify a numerous amount of con-straints. Python is AToM3’s main language, so it’s the language that is usedto write constraints as well. Constraints are rules that cannot be violated bythe end-user. In our traffic formalism, they are used to ensure correctnessin models. For each constraint you should specify its action (like CREATE
3
Figure 1: Traffic formalism in AToM3.
or EDIT) and when to check it (is it a pre -or postcondition?). The use ofconstraints in AToM3 is very intuitive and they are easy to use. It certainlyis one of the showpieces of this modeling tool. Figure 2 shows an exampleof an AToM3 constraint. This constraint in particular ensures that a road,fork or join segment has a maximum of two incoming connections. It will becalled every time an EDIT or CONNECT action has been executed on oneof these segments.
4
Figure 2: AToM3 post-condtion constraint, called on an edit and connect action.
3.2. MetaEdit+
MetaEdit+ is a completely integrated, repository-based environment forbuilding and using domain-specific languages and code generators. MetaEdit+is currently available for Mac OS, Windows and Linux. It offers an exten-sive Java API to communicate with models from outside the workbench.The MetaEdit+ API uses the widely supported and open SOAP standardto communicate with your models (3). From within the MetaEdit+ tool, itis possible to set up a SOAP server and generate a web service definitionlanguage (WSDL). Through this WSDL, Java stubs are generated and theAPI tool is launched within minutes. Next to the API, MetaEdit+ also of-fers MERL, the MetaEdit+ Reporting Language. MERL is used to definegenerators for code (C/C++/Java/...) and documentation. Metacase claimsto offer a language that is able to generate code in any language or formatthe developer wants. However, MERL will not be discussed since it is out ofthe scope of the case study.
3.2.1. Documentation
MetaEdit+ offers various DSM resources. This includes a detailed Work-bench User’s Guide which discusses every aspect of metamodeling in MetaEdit+.All methods provided by the API are described as well. A single point ofcriticism in the guide is the rather brief explanation of the API methods andthe few examples it delivers. However, Metacase offers a forum inhabitedby experts who’ll give advice on every topic within hours. This certainly
5
is a strong advantage for MetaEdit+, probably due to its commercial sta-tus. Next to the user’s guide, developers are able to watch several webcasts,read articles, blogs, brochures and even listen to podcasts. Generally, Meta-case provides really good and clear documentation, but some points couldcertainly be refined.
3.2.2. Abstract Syntax
MetaEdit+ provides support in the creation of different modeling lan-guages through metamodels. Metamodels in MetaEdit+ are defined throughthe GOPPRR modeling language (Graph-Object-Property-Port-Role-Relationship).A graphical metamodel is described as a set of objects in the GOPPRR lan-guage. All GOPPRR tools support single inheritance. Figure 3 illustratesthe traffic metamodel in the GOPPRR modeling language.
Figure 3: Traffic formalism in the GOPPRR modeling language.
The figure above contains all elementary objects of the GOPPRR meta-modeling language. The blue rectangular shapes represent the objects. Ob-jects may contain properties (as in the Capacity and Light object). The di-amond shaped rectangles between objects are called relationships. Togetherwith the green circles (roles), they form the binding between two objects.Inheritance is introduced through the grey arrows between objects.
6
3.2.3. Concrete Syntax
MetaEdit+ provides generic symbols for each object in the GOPPRRmetamodeling language. However, users are able to to specify custom sym-bols for objects, roles and relationships in their models. Using a vectortool or importing graphics files, language developers specify these symbols.Symbols may contain text or property values extracted from their abstractsyntax objects. Moreover, symbols or their parts may be shown based on acertain condition, and if one representation does not suffice for the developer,MetaEdit+ offers multiple representations per concept.
3.2.4. Semantics
In MetaEdit+, language developers are able to specify constraints to en-sure correctness of the model. These constraints may be invoked while a useris editing a model or they could be imposed during or after another action(like model saving or model transformation). The MetaEdit+ constraint toolis very easy to use, but has limited expressibility. Moreover, the constrainttool only covers the following constraints:
• object connectivity in a relationship or a role (an object can be in aspecified binding for a certain number of times)
• object occurrence in a model (an object can only occur a specifiednumber of times)
• ports involved in a relationship (all ports of a certain type must havethe same value for a specified property)
• uniqueness of a property (e.g. an object of a certain type must have aunique value for a specified property)
If the developer wants to specify more advanced constraints, the MERLgenerator should be used. However, for our car formalism, the basic con-straint tool offers all functionality needed to constrain our models.
7
3.3. Poseidon for DSLs
Poseidon for DSLs is a modeling tool that allows the creation of domain-specific modeling languages. The tool is integrated within Eclipse and shouldtherefore be platform independent. Metamodels are created according tothe ECore metamodeling language, which is part of the Eclipse ModelingFramework (EMF). Poseidon for DSLs provides two graphical editors:
• Poseidon for ECore: a graphical editor to create your own metamodel.
• Poseidon: a graphical editor to create your own models, based on ametamodel.
All metamodels created in Poseidon for ECore can be synthesized toJava code. The Java code, together with the specification of diagrams andtools, can then generate the graphical modeling environment called Poseidon.A serious disadvantage for Poseidon for DSLs is the fact that it does notcontain a transformation tool. Models are saved to EMF and can readilybe loaded into Eclipse and processed in model transformation tools such asopenArchitectureWare. Its sole purpose is the modeling of domain-specificlanguages.
3.3.1. Documentation
Poseidon for DSLs comes with an extensive amount of documentation. Itcontains a tutorial for developing a Petri Net editor (instructions for creatingthe metamodel and corresponding models) and two references, respectivelyfor Poseidon for DSLs and Poseidon for ECore.
Poseidon for DSLs User Guide Poseidon for DSLs is a framework fordeveloping a graphical modeling language for your domain (DSL - DomainSpecific Language). To develop your own graphical modeling language withPoseidon for DSLs, you need our distribution of Eclipse and a ”template”workspace to start from. The ”template” workspace contains Poseidon forDSLs runtime, a set of XText models (this is where you define nodes, edges,tools etc. for you graphical modeling language) and a set of classes which canbe used as a API for more detailed customization of your editor (Gentleware(6)).
Poseidon for Ecore User Guide Poseidon for ECore is a graphical editor
8
created with Poseidon for DSL framework. It is a graphical editor for EMFECore models. Eclipse IDE provides a tree editor for ECore models, Po-seidon for ECore provides a fully functional graphical ECore editor. Usageof the editor is pretty straight-forward (assuming that you are familiar withECore) (Gentleware (7)).
3.3.2. Abstract Syntax
Poseidon for ECore is a graphical editor that allows the creation of ECoremodels. It consists of an extension which makes it possible to create anECore model that can be used as a metamodel. After loading this exten-sion, language developers are provided three basic elements. All objects ina metamodel should be inherited from these building blocks. PoseidonCore-NamedElement represents a simple node in the future graphical editor. Po-seidonCoreNamespace is used for nodes that are capable of containing othernodes. This element is not used in our traffic formalism. However, it could beuseful when one wants to model a petri net editor, where a place contains to-kens. Alternatively, we could make our cars part of the roads they’re drivingon. A road element could therefore inherit from PoseidonCoreNamedEle-ment. PoseidonCoreDirectedRelationship represents an edge in the futuregraphical editor. This abstract type represents all the relationships betweenobjects. The basic elements, together with the traffic formalism are illus-trated in figure 4.
Figure 4: Traffic formalism in the Poseidon for ECore metamodeling language.
9
3.3.3. Concrete Syntax
After the creation of the metamodel, a graphical model editor based onthe metamodel is created. This graphical editor, Poseidon, makes it possibleto edit and create your own models. Poseidon is generated from a set oftextual DSLs (XText). However, before a language developer can start mod-eling, he should specify all diagram nodes and tools used in his (meta)model.The specification of a diagram node requires one basic element, the meta-model element, and two strongly recommended elements, the icon and theshape of this node. All nodes (or symbols) in Poseidon get a default repre-sentation which can be customized by specifying the icon and shape of thisnode. However, it is not possible to specify or create a custom image fora node. For example, the node Sink that consumes all cars in the trafficformalism looks as follows:
node Sink {metamodel element : Sinkicon : ”end−s t a t e ”shape : ROUNDED RECTANGLE
}Other properties like the minimum and maximum size can easily be set.
Using this textual DSL, language developers can easily modify the graphicalrepresentation of their nodes. The node tool Sink simply refers to the diagramnode. By defining this tool, Poseidon knows the representation and behaviourof its corresponding diagram tool.
node too l Sink {diagram node : Sink
}
3.3.4. Semantics
Like the diagram nodes and tools, semantics should be specified in atextual DSL. A user is able to create rules for all the PoseidonCoreDirect-edRelationship elements. For example, in our traffic formalism, a garagegenerates cars and sends them through an output object to the next roadsegment. To make the life of our modelers easier, we could automaticallycreate an output when creating the relationship between a garage and anoutput. This is done in the following rule:
r u l e s f o r GarageToOutput {
10
from Garage c r e a t e Output}
Another example in the model of a Petri Net editor is the following:
r u l e s f o r Arc {from Place c r e a t e Trans i t i onfrom Trans i t i on c r e a t e Place
}
This rule automatically creates all objects needed when trying to connecta Place to a subsequent Place, that is not even there yet.
4. Results
This section consists of a summary of all the evaluation criteria used toevaluate each modeling tool. The columns in the comparison table representrespectively the AToM3 tool, MetaEdit+ and Poseidon for DSLs. Every rowdiscusses a new criteria.
11
Pra
ctic
alC
ompar
ison
ofth
eed
itor
sAToM
3M
etaEdit+
Poseidon
forDSLs
Sp
eed
ofD
evel
opm
ent
13hou
rs11
hou
rs4
hou
rs*
Docu
men
tati
on+
++
++
++
+R
epos
itor
yN
oY
esN
oP
latf
orm
Lin
ux,
Win
dow
sL
inux,
Win
dow
s,M
acO
SX
Win
dow
sP
rice
Fre
eF
ree/
150
EU
R/9
500
EU
R**
Fre
e/69
9E
UR
***
Inte
grat
ion
Sta
ndal
one
Sta
ndal
one
Ecl
ipse
*N
otr
ansf
orm
atio
nan
dsi
mula
tion
was
invo
lved
.P
osei
don
for
DSL
sdoes
not
conta
ina
tran
sfor
mat
ion
tool
.**
Fir
st30
day
sar
efr
ee.
An
intr
oduct
ory
lice
nse
ispri
ced
at15
0eu
ros
and
afu
lllice
nse
isav
aila
ble
for
9500
euro
s.**
*F
ree
vers
ion
does
not
offer
model
exp
ort
capab
ilit
ies.
Tec
hnic
alC
ompar
ison
ofth
eed
itor
sAToM
3M
etaEdit+
Poseidon
forDSLs
Tra
nsf
orm
atio
nto
olY
esY
esN
oA
PI
Yes
(Pyth
on)
Yes
(Jav
a)L
imit
ed(J
ava)
Abst
ract
Synta
x*
Cla
ssD
iagr
amG
OP
PR
RE
Cor
eC
oncr
ete
Synta
xV
ecto
rto
olV
ecto
rto
olT
extu
alD
SL
Bin
din
gb
etw
een
AS
and
CS
Har
dSof
tSof
tR
elat
ionsh
ips
N-a
ryN
-ary
Bin
ary
Con
stra
ints
Use
r-defi
ned
Lim
ited
No
*H
owis
the
Abst
ract
Synta
xsp
ecifi
ed?
How
do
we
spec
ify
inw
hic
hw
ayth
ela
ngu
age
com
pon
ents
shou
ldb
eco
nnec
ted
toea
chot
her
?
12
5. Conclusion
Clearly, every editor has its own advantages and disadvantages. MetaEdit+offers a standalone modeling tool that is available for the main platforms(Windows, Linux and Mac OS) and is pretty well documented. The devel-opers’ workspace is maintained online through a repository, which means allyour work is kept safe. The tool also provides an extensive transformationand generation tool, complemented by an extensive API. Metamodels aredefined through the GOPPRR modeling language. The metamodels thusmade are read by MetaEdit+ to configure itself to provide the support envi-ronment for the modeling language. Its main advantage is probably the useof n-ary relationships between objects in metamodels. However, there are afew drawbacks as well. The price of a standard license for MetaEdit+ is veryhigh, it has got a rather limited constraint tool and its user interface coulduse a redesign. However, language developers can try the MetaEdit+ toolfor free during the first 30 days and are able to buy an introductory licenseafterwards (limited to one per company).AToM3 on its turn offers almost the same functionality but it is clearly moresensitive for bugs and errors. It is a free tool, but it has got no onlinerepository available. Furthermore, in comparison with MetaEdit+, AToM3’sconstraint tool is more free-form and customizable for a developer’s purposes.Finally, Poseidon for DSLs has very limited functionality. It does not shipwith a transformation tool and the free version has got no export features touse the model with other transformation tools.
Developers looking for a reliable and safe tool to start domain-specific model-ing could pick either one of the three editors. In my opinion, MetaEdit+ andAToM3 get the big things right, with MetaEdit+ slightly in favor. AToM3’sshortcomings are no major flaws, and in the end it is a subjective matterthat is best evaluated in the context of a concrete problem domain.
13
[1] P. Mosterman and H. Vangheluwe. Computer Automated Multi-Paradigm Modeling: An Introduction. 2004
[2] McGill MSDL. A tool for Multi-formalism and meta-modeling.http://atom3.cs.mcgill.ca/
[3] Metacase. A Domain-specific modeling environment.http://www.metacase.com/
[4] Gentleware. Create domain-specific modeling languages with Poseidonfor DSLs. http://www.gentleware.com/poseidon-for-dsls.html
[5] J. de Lara and H. Vangheluwe. Computer Aided Multi-Paradigm Mod-elling to Process Petri-Nets and Statecharts.
[6] Gentleware. Poseidon for DSLs User Guide.http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon-for-dsls/user-guide/Poseidon for DSLs Documentation.html
[7] Gentleware. Poseidon for ECore User Guide.http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon-for-ecore/Poseidon for ecore Documentation.html
14
