GME??™s meta-metamodel differs signi?¬?cantly from that of other tools. It has a
strong concept of port coupled with a weak concept of relationship, probably because
of the electrical engineering inheritance: wires are just wires and connect speci?¬?c pins
on components. The tool support also reveals this same balance: all connections
between objects are autorouted as uneditable horizontal and vertical lines. There is no
separate ?¬?rst-class concept for graph, but objects are allowed to contain other objects
to form a hierarchy.
Metamodels are speci?¬?ed in a simple UML-like language, which makes extensive
use of stereotypes to distinguish the various metatypes??”an odd choice in a DSM
environment where different concepts should normally be given different symbols.
Constraints are speci?¬?ed in a dialect of OCL. There is no graphical symbol editor and
only a simple macro-based system for generating reports: all symbols and most
generators are written by hand in C++.
GMEis at level 5 in our scale of tool evolution: a metamodel is turned into a binary
?¬?le, which con?¬?gures a second instance ofGME. Models do not update automatically
when the metamodel is updated: an explicit operation can be chosen to try to update
them, but this will often be unable to complete the update. A secondary scheme
involves exporting the model as XML, upgrading the metamodel, and then
reimporting it; even this will fail if the old model is not completely valid in the new
metamodel.
Pages:
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755