Show in Frame No Frame
Previous Next Title Page Contents Search

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.

Family Tree notation

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.

GOPPRR types in Family Tree

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.

Family Tree simple metamodel

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+.

Show in Frame No Frame
Previous Next Title Page Contents Search