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, extensible architecture that uses MS COM for integration. GME is easily extensible; external components can be written in any language that supports COM (C++, Visual Basic, C#, Python etc.). GME has many advanced features. A built-in constraint manager enforces all domain constraints during model building. GME supports multiple aspect modeling. It provides metamodel composition for reusing and combining existing modeling languages and language concepts. It supports model libraries for reuse at the model level. All GME modeling languages provide type inheritance. Model visualization is customizable through decorator interfaces.

Technical Overview

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.