Inventing a new mini language or GUI to
specify such sequences should not, however, be necessary. Instead, it is better that the
tool simply uses its existing generator language. The language is designed for
navigating models and outputting text, which is exactly what this task calls for. If the
language is at a high level of abstraction, even a graphic designer who is not a
programmer could use it.
Using the generator language also allows us to go further a?¬?eld in the search for text
content to display. For instance, a role may pick up information from its object or port,
to show more exactly what the connection is doing. Since the context of the whole
graph is available while drawing a symbol, we can also use symbols to provide
information about the graph as a whole: errors, warnings, metrics, and so on, as
mentioned above.
The downside of complicated generators is that there is no way to know when their
content may have changed. If the generator can read any information from this graph,
and possibly any subgraph or supergraph, the content could change after almost any
operation. If the generator language is powerful enough to pick up representational
information (e.g., object positions) or external information (e.g., the results of a
system call), there is no hope. A spreadsheet may be simple enough that a smart
recalculate algorithm can cope with most cases, but a DSM tool is more complicated.
Pages:
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726