1 Introduction to the Family Tree Modeling Language
To get a better picture of what MetaEdit+ is made for, let us
walk you through the creation of a Domain-Specific Modeling language. Since the
domains you’re familiar with will be different for each evaluator,
let’s take one that everyone knows: the family. What kind of modeling
language is good for modeling families? Of course we could try and (mis)use UML,
but it’s rather over-complicated for this, and we’d have to twist
the semantics a fair bit. Instead, let’s make our own language that is
more like a traditional “family tree”.
The first question to ask is what kinds of core concepts
exist in our example Family Tree domain? As the Family Tree is a simple domain,
we can quite soon figure out what we need. First there has to be a concept of
Person. Each Person must have two other Persons as
Parents, and a Person can be a Parent to his or her
Children. Parents and Children together form a
Family relationship.
In addition to the basic concepts, we also need to know
what information is stored with each concept. A
Person for instance will
need a
First name and a
Last name. Finally, we need to know what
our diagrams will actually look like: we want to have symbols for our concepts.
A quick sketch of a famous TV family can be seen in
Figure 1-1.
Figure 1-1. Sketch of a graphical notation for the Family Tree.
In
order to make a real language implementation out of this sketch and provide tool
support for it, we have to present the structure of our language in a more
formal manner. One way to do this is to create a metamodel for the language. As
the name implies, a metamodel is “a model of a model” that defines
the legal language elements and rules.
In MetaEdit+, metamodels are defined using GOPPRR
metamodeling language. The name is an acronym that stands for
Graph,
Object,
Property,
Port,
Relationship and
Role. These are the metatypes we use when describing modeling languages.
Figure 1-2 illustrates the metatypes with
examples.
Figure 1-2. GOPPRR metatypes as found in Family Tree.
Each
metatype has its function and semantics as follows:
| A
graph is one individual model (usually represented as a
diagram). |
| Objects
are the main elements of graphs (like Persons in our
example). |
| A
relationship connects objects together (like the Family relationship
between Person
objects). |
| A
role connects an object into a relationship (a Person can be either in
Parent or Child role in a Family
relationship). |
| A
port defines the possible additional semantics of how the role connects to the
object. |
| A
property is an attribute characterizing one of the above (like First Name
and Family Name in our example). |
Using
these metatypes we can now put together a metamodel that describes the structure
and basic semantics of our modeling language.
Figure 1-3 presents such a metamodel for the
Family Tree modeling language.
Figure 1-3. Metamodel for the Family Tree modeling language.
The
metamodel above can be read as follows: a Person object (the blue rounded
rectangle) can be in a Family relationship (the orange diamond) with
other Person objects and for each Family relationship there must
be at least two Persons in Parent roles (the green circles).
Optionally there can be more Persons participating in Child roles
(0-N cardinality). Person objects also carry identifying properties
called First name and Family name.
With the sketch notation and metamodel we now have all
basic building blocks we need to start experimenting with our modeling language.
What we need to do next is a proof of concept. So it is time to take a look at
what these things look like in MetaEdit+.