All too often we see languages with virtually no
navigation constructs, leaving the task of navigation to functions generated in each
object type. For example, a Button object type may be given a function
???triggeredTransitions(),??? which answers all the transitions that are connected to
this button. This will work ?¬?ne in a single metamodel, in a single model, where each
Button is used in only one graph. However, if the Button is reused in several graphs, or
worse in several metamodels, there is no way there can be a single answer to that
function: which transitions are triggered depends on which graph we are in, and in
some types of graph Buttons may not be used at all for triggering transitions. Lack of
language-level navigation constructs thus kills reuse, and inhibits metamodel
evolution.
With language-level navigation, the context of the call is known at runtime??”
including which graph and object we are in. A command like ???do >Transitions??? will
effectively evaluate to something like ???currentGraph.relationships(currentObject,
Transition).??? (See ???Reuse of Objects in Models??? in Section 14.3.1 for more details on
the underlying issues.)
Many-to-Many Mapping Between Graphs, Generators and Output
Files A ???version 1.0??? tool will generally assume that a single model or single
generator maps to a single output ?¬?le.
Pages:
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730