you need to know which objects with
broader roles command these devices. An inheritance hierarchy portrays
categories, which are seldom helpful
except in GUIs; it does not portray
what you need to know—the hierarchy of roles.
Comparing UML to IDAR. An easy
way to compare UML and IDAR is to
follow an operation—for example,
sending a fax. The sequence numbers on the commands and notices
in Figure 4 indicate that after the user
presses the Send button on the control
panel, the CtlPanel object calls the
sendPressed notice in Fax, which
is clearly the main controller over the
entire fax machine, and it commands
Send to sendFax. Based on its high
position in the hierarchy, you can see
that Send handles the high-level aspects of sending faxes. It commands
Connect to connect to the receiving
machine, and Connect in turn commands Modem to take the phone off
the hook via the hookUpDn method.
After Connect gets the dial Tone notice from Modem, it commands Modem
to dial and waits for its answered notice. Connect then sends a connected
notice back to Send. The figure also
shows that Send commands Scanner
to scan, and that data (the dashed arrows) will flow from Scanner into ImageProc and then into the Modem via
the pixelRow and xferBulk notices.
This graph reveals the structure of this
software and how it works.
Figures 1, 2, and 6 are the UML
class, communication, and sequence
diagrams, respectively, for the same
fax machine design. The communication diagram (Figure 2) has the same
sequence numbers as the IDAR graph,
making comparison easier.
Let’s use the UML diagrams to
show how a fax is sent. Which objects
have primary roles? It’s hard to tell.
Which interactions among objects are
the most important? It’s hard to tell.
Which objects are controllers versus
workers? It’s hard to tell. The best you
can do is follow messages sequentially on the communication or sequence
diagram, and even then it is difficult
to determine which objects control
which others, or which objects have
broad versus narrow roles. UML fails
to convey roles or their ranks, making
designs hard to understand.
Benefits of IDAR Graphs
IDAR graphs provide several advantages over UML, two of which are predominant.
Ease of understanding. An IDAR
graph is easier for developers to understand than the corresponding class,
communication, and sequence diagrams in UML for the following reasons:
˲ The role hierarchy in IDAR is a gen-
eralized form of the AH (means-end
abstraction hierarchy) employed in
cognitive engineering, 7 which is known
to impart understanding by means of
the why-what-how triad. This triad con-
sists of an object, its superiors, and its
subordinates. It provides the following
insights: the purposes of the object’s
superiors tell you why the object exists;
the role of the object tells you what it
does; and the purposes of its subordi-
nates indicate how it works. UML lacks
an AH, so it cannot tell you why an ob-
ject exists or how it works.
˲ The hierarchy in an IDAR graph
reveals which objects control which
Figure 3. Incomplete IDAR graph of a fax machine design.
Figure 4. Complete IDAR graph of a fax machine.