diagrams, attempting to integrate
them mentally, which “unnecessarily
strains developers’ cognitive abilities.”
IDAR eliminates this wasteful mental
effort by combining structure and behavior into one graph.
IDAR’s resulting clarity should produce shorter learning curves and fewer
misunderstandings and oversights,
improving quality and shortening
Packages in UML may be nested,
forming a hierarchy. This hierarchy,
however, does not consist of roles,
and the diagram inside each package is a network and not a hierarchy.
Consequently, a hierarchy of packages doesn’t improve understandability much. Subsystems in IDAR don’t
suffer from these disadvantages, and
thus enjoy the full gain in understandability detailed here.
Note that organizational charts for
corporations remain easy to understand regardless of their size. Because
IDAR graphs are similar, they also
should scale to any size and remain
equally as easy to understand.
Resistance to messiness. A second
important advantage of IDAR graphs
over UML is they hinder the messiness
(disorganization) that occurs when
changes and enhancements are spliced
into code with little regard for maintaining consistency of design. This
claim is backed up by the following sensible constraints from the IDAR rules:
˲ The Identify rule prevents notices
from initiating actions. In practice,
it prevents a developer from creating
spaghetti by scattering notice calls
around, because notices are only allowed to convey needed information.
˲ The Down rule prevents a subordinate from commanding a superior.
˲ The Role rule prevents unexpected
side effects, a common problem.
UML provides none of these defenses against messiness. For example,
suppose you caused the Modem object
in the fax machine to tell the Receive
object to do something. This would
add a line to the two UML diagrams
(Figures 1 and 2) that is inconspicuous
and acceptable. Doing so in the IDAR
graph in Figure 4, however, would violate the Down rule because a subordinate would be commanding a superior.
This is an example of the design decay
that IDAR prevents.
others and, equivalently, which objects
have broad versus narrow roles. In Figure 4, it is obvious that Fax is the top-level controller, and that Send and
Receive are second-to-top-level controllers having rather broad roles. The
corresponding UML diagrams conceal
these helpful control relationships and
˲ The subordinates of each supe-
rior form a closely related group, help-
ing developers to associate functions
with groups of objects. In Figure 4, it
is clear that Connect and Negotiate
are closely related workers under the
same bosses, whereas UML conceals
this tight affiliation. Unlike UML, IDAR
reveals work groups.
˲ In an IDAR graph, command calls
are more prominent than notice calls
because they are more important. UML
conceals degrees of importance.
˲ Throughout history, people have
selected role hierarchies to represent
organizations, indicating that they are
˲ Research by experts in cognitive
theory has shown that UML has severe problems with understandability
(“cognitive effectiveness”). 3 Specifically, UML has “alarmingly high levels of
symbol redundancy and overload” and
poor “visual discriminability.” IDAR
graphs were designed to avoid both of
˲ Other research has revealed that
developers understand software design as an integrated interplay of its
structure and behavior. 1 UML splits
structure and behavior into two or
more separate diagrams, reducing
comprehension as developers are
forced to flip back and forth between
Figure 6. UML sequence diagram for sending a fax.
Laser Audio Motor