It should thus be possible to associate a condition with an
element or group of elements, comparing a property to a ?¬?xed value. By allowing
dynamic information to be displayed graphically rather than textually, conditional
symbols can play an important role in creating a truly visual language.
More advanced cases may effectively replace the whole symbol with a different
one, depending on the value of a property. This is however somewhat extreme, and
normally motivated by problems elsewhere in the modeling language or tool. Rather
than effectively merging two types into one, separating them by a new property, it is
generally better to keep them as separate types, possibly with a common supertype.
The desire for different symbols is probably telling you something about their
different semantics, and that will probably later be revealed in differences in rules,
properties, and so on.
For individual elements, the conditions may sometimes be more complicated than
a single property. As with the contents of text elements, the next step after properties
could well be the generator language: that can fetch whatever values are necessary for
the condition. On other occasions the value may be from a single property, but the test
will not be simple equality with one of a predetermined set of strings. For such cases it
is useful that conditions can perform wildcard, regular expression, or numeric
comparisons.
Pages:
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728