Database Reference
In-Depth Information
Complex and reusable constraints can be defi ned in constraint functions that can be
called from constraints or other functions. They even support recursion. Function parameters
enable the constraint developer to formalize reoccurring defi nitions in a generic form.
One of the most powerful facilities of the constraint system is the browser that provides
an interactive window to the constraint database. The browser displays the defi nition, state
and other attributes of each available constraint. Selected constraints can be evaluated on
demand or can be disabled temporarily by the user. In addition to the constraints defi ned
in the meta-model, the model builder is able to add and remove custom constraints at the
modeling level.
The constraint debugger assists the modeler in discovering erroneous constraint defi -
nitions. The stack of evaluated expressions, along with the current values of all variables,
are displayed in the debugger. The evaluation tracking facility can be turned off when the
designer is confi dent in the correctness of the constraint defi nitions.
VISUALIZATION
The modeling framework provides different kinds of graphical interfaces to the model
database. The primary display area represents models as separate windows showing contained
objects as icons and lines. The physical position of these objects can be arranged arbitrarily
and independently in each aspect of the model. The connection paths are controlled by a
powerful real-time autorouter. The object positions in different aspects can be selectively
synchronized to help clean up large models.
The model browser uses a different visualization approach, displaying the model hier-
archy as a tree where non-leaf (composite) nodes can be collapsed or expanded on demand.
While this method provides less control and information on a specifi c node, it reveals the
whole model hierarchy.
The third interface displays model information in tabular format, similar to a spread-
sheet, which supports batch editing and consistency checking nicely.
Finally, it is the main editing window where most of the model creation and modifi cation
takes place. Model visualization can be customized to fi t the target modeling methodology.
All object drawing and mouse handling operations are assigned to a software component,
called a decorator, outside of the regular user interface. Whenever these operations need to
be executed the GME editor calls the decorator registered for the current modeling language
through a predefi ned interface. GME comes with a default decorator and some samples. Any
modeling paradigm can have a custom decorator implementing domain-specifi c visualiza-
tion. Decorators have full access to the model database to be able to provide context-based
visualization for the decorated objects. The graphical framework may send update requests
to a specifi c decorator with a given frequency, if animated visualization is requested.
EXTENSIBILITY
GME was designed with extensibility as one of the most important goals. The tool
has a modular component architecture, shown in Figure 3. At the bottom, different storage
formats, ranging from relational databases through a fast proprietary binary fi le format to
XML, are supported. Two key components of the GME are GMeta and GModel. The GMeta
component defi nes the modeling paradigm, while GModel implements the GME modeling
