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.