If the reader can cope
with a shift in metalevel, we can say that the meta-metamodel is in fact a domainspeci
?¬?c modeling language for describing modeling languages. As such, it should aim
to have a good set of concepts for covering all thecommonly foundartifacts ofmodeling
languages. It will probably also have to be built speci?¬?cally for this task: an existing
general-purpose modeling language will tend to be at too low a level of abstraction.
For a ?¬?rst attempt, many people will still try to use an existing general-purpose
modeling language: ER in the 1980s and early 1990s, or UML (or its MOF subset)
nowadays. We can assume something like this as offering the basics of a metametamodel,
which we shall not cover further here. Table 14.1 shows these basic
concepts from ER??”designed for describing databases, UML??”designed for
describing object-oriented code, and OPRR??”designed for describing modeling
languages.
Below we shall look at the extra features whose support will make or break a metametamodel.
???Make or break??? may sound strong, but of all the categories this is the one
that has the greatest effect. If a meta-metamodel is lacking in some area, you will have
to twist your modeling language to ?¬?t it. This will obviously be a burden to you when
metamodeling, probably when building generators, and certainly for the modelers.
Pages:
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701