These tools are based on a two-level architecture:
system designs are stored in ?¬?les or a repository, whose schema is programmed and
compiled into the modeling tool. This ???hard-coded??? part de?¬?nes what kind of models
can be made and how they can be processed. Most importantly, only the tool vendor
can modify the modeling language, because it is ?¬?xed in the code. Metamodel-based
technology removes this limitation and allows ?¬‚exible modeling languages. This is
achieved by adding one level above the level of modeling languages, as illustrated by
the top right box of Fig. 3.1.
Metamodel-based tools follow a three-level architecture. The lowest, the model
level, is similar to that of CASE tools. It includes system designs as models. The
middle level contains a model of the language, that is, a metamodel. A metamodel
includes the concepts, rules, and diagramming notations of a given language. For
example, a metamodel may specify concepts like a ???use case??? and an ???actor,??? how
TOOLING FOR DSM 59
they are related, and how they are represented. However, instead of being embedded
in code in the tool, as in a ?¬?xed CASE tool, the modeling language is stored as data in
the tool.
Unlike aUMLor CASE tool, a metamodel-based tool allows the user to access and
modify the language speci?¬?cations.
Pages:
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134