GME: Generic Modeling Environment

Overview

The Generic Modeling Environment is a configurable toolkit for creating domain-specific modeling and program synthesis environments. The configuration is accomplished through metamodels specifying the modeling paradigm (modeling language) of the application domain. The modeling paradigm contains all the syntactic, semantic, and presentation information regarding the domain; which concepts will be used to construct models, what relationships may exist among those concepts, how the concepts may be organized and viewed by the modeler, and rules governing the construction of models. The modeling paradigm defines the family of models that can be created using the resultant modeling environment.

The metamodeling language is based on the UML class diagram notation and OCL constraints. The metamodels specifying the modeling paradigm are used to automatically generate the target domain-specific environment. The generated domain-specific environment is then used to build domain models that are stored in a model database or in XML format. These models are used to automatically generate the applications or to synthesize input to different COTS analysis tools.

GME has a modular, component-based architecture depicted in the figure below.

The thin storage layer includes components for the different storage formats. Currently, a fast proprietary binary file format and an XML format are supported.

The Core component implements the two fundamental building blocks of a modeling environment: objects and relations. Among its services are distributed access (i.e. locking) and undo/redo.

Two components use the services of the Core: the MgaMeta and the MgaModel. The MgaMeta defines the modeling paradigm, while the MgaModel implements the GME modeling concepts for the given paradigm. The MgaModel uses the MgaMeta component extensively through its public COM interfaces. The MgaModel component exposes its services through a set of COM interfaces as well.

The user interacts with the components at the top of the architecture: the GME User Interface, the Model Browser, the Constraint Manager, Interpreters and Add-ons.

Add-ons are event-driven model interpreters. The MgaModel component exposes a set of events, such as "Object Deleted," "Set Member Added," "Attribute Changed," etc. External components can register to receive some or all of these events. They are automatically invoked by the MgaModel when the events occur. Add-ons are extremely useful for extending the capabilities of the GME User Interface. When a particular domain calls for some special operations, these can be supported without modifying the GME itself.

The Constraint Manager can be considered as an interpreter and an add-on at the same time. It can be invoked explicitly by the user and it is also invoked when event-driven constraints are present in the given paradigm. Depending on the priority of a constraint, the operation that caused a constraint violation are aborted. For less serious violations, the Constraint Manager only issues a warning message.

The GME User Interface component has no special privileges in this architecture. Any other component (interpreter, add-on) has the same access rights and uses the same set of COM interfaces to the GME. Any operation that can be accomplished through the GUI, can also be done programmatically through the interfaces. This architecture is very flexible and supports extensibility of the whole environment.

Modeling Concepts

The vocabulary of the domain-specific languages implemented by different GME configurations is based on a set of generic concepts built into GME itself. The choice of these generic concepts is the most critical design decision. GME supports various concepts for building large-scale, complex models. These include: hierarchy, multiple aspects, sets, references, and explicit constraints.

A Project contains a set of Folders. Folders are containers that help organize models, just like folders on a disk help organize files. Folders contain Models. Models, Atoms, References, Connections and Sets are all first class objects, or FCO-s for short. Atoms are the elementary objects - they cannot contain parts. Each kind of Atom is associated with an icon and can have a predefined set of attributes. The attribute values are user changeable. A good example for an Atom is an AND or XOR gate in a gate level digital circuit model.

Models are the compound objects in our framework. They can have parts and inner structure. A part in a container Model always has a Role. The modeling paradigm determines what kind of parts are allowed in Models acting in which Roles, but the modeler determines the specific instances and number of parts a given model contains (of course, explicit constraints can always restrict the design space). For example, if we want to model digital circuits below the gate level, then we would have to use Models for gates (instead of Atoms) that would contain, for example, transistor Atoms. This containment relationship creates the hierarchical decomposition of Models. If a Model can have the same kind of Model as a contained part, then the depth of the hierarchy can be (theoretically) unlimited. Any object must have at most one parent, and that parent must be a Model. At least one Model does not have a parent; it is called a root Model.

Aspects provide primarily visibility control. Every Model has a predefined set of Aspects. Each part can be visible or hidden in an Aspect. Every part has a set of primary aspects where it can be created or deleted. There are no restrictions on the set of Aspects a Model and it's parts can have; a mapping can be defined to specify what Aspects of a part is shown in what Aspect of the parent Model.

The simplest way to express a relationship between two objects in GME is with a Connection. Connections can be directed or undirected. Connections can have Attributes themselves. In order to make a Connection between two objects they must have the same parent in the containment hierarchy (and they also must be visible in the same Aspect, i.e. one of the primary Aspects of the Connection). The paradigm specifications can define sev-eral kinds of Connections. It is also specified what kind of object can participate in a given kind of Connection. Connections can further be restricted by explicit Constraints specifying their multiplicity, for instance.

A Connection can only express a relationship between objects contained by the same Model. Note that a Root Model, for example, cannot participate in a Connection at all. In our experience, it is often necessary to associate different kinds of model objects in different parts of the model hierarchy or even in different model hierarchies altogether. References support these kind of relationships well. References are similar to pointers in object oriented programming languages. A reference is not a "real" object, it just refers to (points to) one. In GME, a reference must appear as a part in a Model. This establishes a relationship between the Model that contains the reference and the referred-to object. Any FCO, except for a Connection, can be referred to (even references themselves). References can be connected just like regular model objects. A reference always refers to exactly one object, while a single object can be referred to by multiple References. If a Reference refers to nothing, it is called a Null Reference. This can act as a placeholder for future use, for example

Connections and References are binary relationships. Sets can be used to specify a relationship among a group of objects. The only restriction is that all the members of a Set must have the same container (parent) and be visible in the same Aspect.

Some information does not lend itsef well to graphical representation. GME provides the facility to augment the graphical objects with textual attributes. All FCOs can have different sets of Attributes. The kinds of Attributes available are text, integer, double, boolean and enumerated.

Folders, FCOs (Models, Atoms, Sets, References, Connections), Roles, Constraints and Aspects are the main concepts that are used to define a modeling paradigm. In other words, the modeling language is made up of instances of these concepts. In an object-oriented programming language, such as Java, the corresponding concepts are the class, interface, built-in types, etc. Models in GME are similar to classes in Java; they can be instantiated. When a particular model is created in GME. it becomes a type (class). It can be subtyped and instantiated as many times as the user wishes. The general rules that govern the behavior of this inheritance hierarchy are:

Only attribute values of model instances can be modified. No parts can be added or deleted.

Parts cannot be deleted but new parts can be added to subtypes.

This concept supports the reuse and maintenance of models because any change in a type automatically propagates down the type hierarchy. Also, this makes it possible to create libraries of type models that can be used in multiple applications in the given domain.

GME Extensibility

GME identifies data and tool integration as one of its primary application areas, so data access and standards-compliant extensibility is one of its primary design goals. Hence, GME is completely component-based with public interfaces among its components. Most notably, the GME editor, i.e. the visualization component, the model storage and logic, and the meta-modeling module is separated by interfaces which are accessible to user-written components as well, thus giving them access level identical to that of the GME editor. Since the component model is COM, the primary languages for integration are C++ and Visual Basic, while Java, Python, etc. access is also available. Access is bi-directional, and fully transactional, which makes different 'on-line modeling' scenarios feasible. For example, the GME user interface itself can be used as the user interface of a generated application to provide feedback to the user in terms of the models. Furthermore, the bi-directional access makes it possible to convert legacy data into models in an automated fashion.

Programming at the component level is somewhat challenging in the sense that it requires advanced transaction control and event handling. Several alternatives provide easier access through simpler interfaces (albeit with limited functionality). First, the GME pattern-based report language provides simple reporting capabilities by interpreting macro definitions in a simple text input file. A more complex interface is layered on top of the COM interfaces providing an easy-to-use extensible C++ API. GME also provides bi-directional XML access for both model and meta-model information.

GME User Interface

The native graphical user interface of GME is shown in the figure below. The picture shows a model of an signal flow graph loaded. In this simple model, only Models, Atoms and Connections are used. The window on the right hand side shows the Model Browser that displays the whole project in a tree-like fashion. The Aggragate tab displays the containment hierarchy, while the Inheritance tab shows the type inheritance hierarchy. The Meta tab provides an overview of the modeling paradigm specifications. The bottom window is the Part Browser where all the parts that are available in the current aspect of the current model are shown. Notice that two tabs indicate the aspects of the signal flow model: SignalFlow and Parameter.

MetaGME

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

Download

Contrib

Here is a list of GME tools, utilities, paradigms and other contributions to the baseline tool environment. External contributions are also solicited. If you feel that your work is potentially useful for other GME users, please send an email to Akos Ledeczi.