Database Reference
In-Depth Information
parent can participate in. Two additional operators are available to provide fi ner-grained
control over the inheritance relation. These were specifi cally designed to support metamodel
composition. Implementation inheritance propagates all of the parent's attributes, but only
the containment association — where the parent functions as the container — to the child
type. No other associations are inherited in this case. Interface inheritance allows no attribute
inheritance, but does allow full association inheritance, with one exception: containment
relations where the parent functions as the container are not inherited. Note that the union
of the two special inheritance operators gives the common inheritance, and their intersec-
tion is null.
Just as the reusability of domain models from application to application is essential,
the reusability of meta-models from domain to domain is also an important consideration.
In GME, a library of meta-models of important sub-domains is made available to the meta-
modeler, who then can pick and choose from them, extend and compose them together
to specify new domain languages. The extension and composition mechanisms must not
modify the original meta-models for two reasons. First, changes in the meta-model libraries,
refl ecting a better understanding of the given domain, for example, should propagate to the
meta-models that utilize them. Second, by precisely specifying the extension and composi-
tion rules, using inheritance and equivalence operators, for instance, models specifi ed in the
original domain language can be automatically translated to comply with the new, extended
and composed, modeling language. This is a simple and elegant solution to the well-known
model migration problem. (For more detail on metamodel composition please see Ledeczi,
Nordstrom, Karsai, Volgyesi & Maroti, 2001).
TYPES AND INSTANCES
Model reuse and tools for information maintenance between similar models is a natural
requirement in large-scale models or where model composition is heavily used. The provided
solutions in GME — types and instances — resemble those of object-oriented programming
languages. The only signifi cant difference is that in GME, model types are similar in appear-
ance to model instances; they too are graphical, have attributes and contain parts.
By default, a model created from scratch — based on a meta-type — is a type. A subtype
or an instance of a model can be created with a simple operation, and both will depend on
the type they are created from. There is one signifi cant rule that differentiates subtypes from
instances. New parts are allowed in a subtype, but not in an instance. Otherwise, contained
children can be renamed, set membership can be changed and references can be redirected
in both subtypes and instances. However, objects in the containment hierarchy cannot be
removed in either subtypes or instances.
The advantage of using types is clear: any modifi cation in a type model propagates
down the inheritance hierarchy. For example, if a part is deleted in a type, the same part
will be automatically removed in all of its instances and subtypes — even in instances of
the subtypes — all the way down the inheritance tree.
Types can contain other types as well as instances as parts. The mixture of aggrega-
tion and type inheritance introduces another kind of relationship between objects. This is
best illustrated through an example. In Figure 1, there are two root type models: the
Engine
and the
Car
. The car contains an instance of an engine,
V6
, and an
ABS
type model. V6 is
ABS
an instance of the Engine; this relationship is indicated by the dashed line. Aggregation is
indicated by solid lines.
