A reusable framework for creating domain-specific design environments must support a set of abstract modeling concepts that are generic enough to be applicable to a wide range of domains. These concepts might include containment (composition, aggregation, hierarchy), module interconnection, multi-aspect modeling, inheritance and textual/numerical attributes. Selected concepts are "instantiated," i.e. customized, for each target domain, possibly multiple times, to support domain concepts directly. The key idea in the MIC framework is the consistent application of a meta-level architecture. MIC follows the standard four-layer metamodeling architecture applied in the specification of CDIF and UML depicted in Figure below.

There is one predefined language in this scheme, the metamodeling language, that must be rich enough to describe modeling languages for a wide variety of domains. (As a consequence, it can describe itself in the form of a meta-metamodel.) A metamodel specifies a domain modeling language which, in turn, is used to specify models of artifacts in the particular domain. The key in this four-layer architecture is that a lower layer is always described in terms of the next higher layer.

To illustrate these ideas, consider the metamodel of a simplistic Finite State Machine (FSM) language shown in the figure. The metamodeling language in MIC is the UML class diagram notation. The State Machine UML class on the right hand side is a container that can hold States. Transitions are associations between States. Below the metamodel an example model in the FSM language is shown. Notice that information specifying how concepts are to be visualized need to be part of the metamodel, but are omitted in this example for simplicity.

Constraints

The metamodels fully specify the domain modeling language, or more precisely, its concrete syntax. They do not, at least not entirely, specify the static semantics of the language. By static semantics we mean the set of rules that specify the well-formedness of domain models. UML class diagrams do allow the specification of some basic rules, for example, the multiplicity of associations. For more complex semantic specifications, however, UML includes the Object Constraint Language (OCL), a textual predicate logic language. MIC adopts OCL as well; metamodels consist of UML class diagrams and OCL constraints.

Consider the example depicted in the figure on the MetaGME homepage. Suppose the finite state machines in the target domain must not allow state transitions from a state to itself. A UML class diagram alone cannot specify such a rule. Rather, the following OCL expression must be attached to States:

        self.transTo->forAll(s | s <> self)

where self and forAll are OCL keywords, while transTo is a role name of the Transition association. These constraints are relatively straightforward to check programmatically. The expressions need to be evaluated in the context of every applicable model object. Notice that this problem is quite different from the well-known constraint satisfiability problem. Its time-complexity is polynomial in the number of model objects.

Metamodel Composition

Just as the reusability of domain models from application to application is essential, the reusability of metamodels from domain to domain is also an important consideration. Ideally, a library of metamodels of important sub-domains should be made available to the metamodeler, who can extend and compose them together to specify domain languages. These sub-domains might include different variations of signal-flow, finite state machines, data type specifications, fault propagation graphs, petri-nets, etc. The extension and composition mechanisms must not modify the original metamodels, just as subclasses do not modify baseclasses in OO programming. Then changes in the metamodel libraries, reflecting a better understanding of the given domain, for example, propagate to the metamodels that utilize them. Furthermore, by precisely specifying the extension and composition rules models specified in the original domain language can be automatically translated to comply with the new, extended and composed, modeling language.

The GME metamodeling language is based on UML class diagrams. However, to support metamodel composition, some new operators are necessary. The equivalence operator is used to represent the union of two UML class objects. The two classes cease to be separate entities, but form a single class instead. Thus, the union includes all attributes, compositions and associations of each individual class. Equivalence can be thought of as defining the "join points" or "composition points" of two or more source metamodels. New operators were also introduced to provide finer control over inheritance. When the new class needs to be able to play the role of the base class, but its internals need not be inherited, we use interface inheritance. In this case, all associations and those compositions where the base class plays the role of the child are inherited. On the other hand, when only the internals of a class are needed by a subclass, we use implementation inheritance. In this case, all the attributes and those compositions where the base class plays the role of the parent are inherited. Notice that the union of these two new inheritance operators is the "regular" UML inheritance.

MetaGME User Interface

The figure below shows the metamodel of a hierarchical signal flow language. Notice the use of UML stereotypes for specifying how to map UML classes to GME concepts like Atom, Model or Connection. There are four aspects in the metamodeling environment altogether. In addition to the class diagram aspect that is shonw below, constraints, aspects and attributes are specified in separate aspects to manage visual clutter. The environment also supports multi-sheet diagrams through the use of proxies, that are references to UML classes in other sheets (i.e. metamodels).