Java Reference
In-Depth Information
4.1.1 Notation Design
Most people are familiar with the work of Edward Tufte (/
www.edwardtufte.
com/)
on the visual display of information. Although Tufte originally focused on
the display of data, many of the concepts he presented can apply to the develop-
ment of a graphical notation for your DSL.
If you've read Tufte's topics or attended his lectures, you know that he rec-
ommends that everyone use 30-inch monitors or better. Being confined to an
undersized, low-resolution monitor will kill your dreams of effectively modeling
any domain using a diagramming surface. The human brain is capable of pro-
cessing a large amount of high-density information, more so than we are likely
to display using the current 2D limitations of our underlying Graphical Editing
Framework (GEF) infrastructure. A proposed addition to GEF promises to pro-
vide support for 3D, which should introduce an opportunity to improve, yet
complicate, the current situation.
One of Tufte's key messages is to not include gratuitous or redundant
notational elements in your display of information. For example, consider the
Unified Modeling Language (UML) use case diagram. Actors are associated with
use cases, yet each actor is represented by a stick figure along with a role name
label. Typically, the stick figure is larger than the label. Why not just have the text
label indicating the role name and a link representing its association? Why do we
need the stick figure at all? Or, if we must have a graphic, why not a simple label
icon? Because the stick figure is typically the same for all actors, no additional
information is conveyed, and because the only other main figure is the use case
oval connected by a line, it would not be hard to distinguish role names from
their associated use cases. The point is, we should strive to eliminate “noise”
when designing a graphical notation. Just because we have nifty tools such as
GMF to produce graphical notations doesn't mean we should abandon these
basic principles. Arguably, GMF's default settings should produce “clean” dia-
grams instead of illustrate all its bells and whistles. Another example to consider
when designing your notation is the Ecore diagram and several diagrams like it
that use icons to adorn each attribute and method. In the absence of a distin-
guishing characteristic that indicates visibility, cardinality, or navigability, simply
including an icon for these elements is gratuitous. Icons do provide a degree of
visual appeal (“eye candy”) for the diagram, but there should always be an
option to hide such elements.
The topic
The UML Profile for Framework Architectures,
by Marcus
Fontoura, et al., offers a published example of how to improve the density of
information of a UML class diagram. In the topic, an alternative display of inher-
itance information is added to a class to indicate either a flattened or a hierar-
chical representation. Instead of simply adding a static icon for an attribute or
Search WWH ::
Custom Search