While a similar approach has worked well for
rules, with symbols its limitations are reached too quickly. The difference probably
lies in the fact that the kinds of rules that are needed are to be found from the domain of
metamodeling, with elements such as objects, relationships, and properties, whereas
the kinds of symbols that are needed are to be found from each modeling language??™s
own problem domain. Trying to ?¬?x the set of possible symbols ahead of time means
restricting them to simple geometrical ?¬?gures or those used in other, mostly generic,
modeling languages. An important part of DSM is that the symbols should be
WHAT IS NEEDED IN A DSM ENVIRONMENT 375
evocative of the domain concepts they represent, and to do that requires free
combination of the basic graphical elements??”lines, curves, text, and so on??”to make
domain-speci?¬?c symbols.
There seems little point in describing the features of a graphical symbol editor
here: it should simply behave like a normal vector graphics editor. The difference is in
the integration with the modeling language de?¬?nitions: a given symbol is de?¬?ned for a
particular object, relationship or role type. Text elements will thus normally be
references to the properties de?¬?ned in the type, and the editor should be integrated
with the de?¬?nitions to make selecting the right property easy.
Pages:
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718