˲ Aid. A command or notice may,
unknown to its callers, aid its object by
performing part or all of a previously
˲ Role. A brief role is written for each
object and method that summarizes
the service it offers, avoiding any aspect of its implementation (including
aid). Callers may rely on only what is
stated in roles.
The Down rule ensures every design
is a command hierarchy consisting of
superiors and subordinates (bosses
and workers). This rule produces a
DAG (directed acyclic graph), so it’s
also known as the DAG rule. The Role
rule requires that every method or object fulfill its role, doing no more and
no less, precluding unexpected side effects. The Role and Down rules together
force every design to be a role hierarchy. The Aid rule gives designers more
flexibility by allowing public methods
to help secretly with previously commanded duties, in addition to fulfilling
their own roles. These rules don’t apply
to cross-cutting concerns. 2
It’s also helpful to think in terms
of constraints on public behavior. Commands have one constraint: they must go
down in the hierarchy (Down rule). Notices also have one constraint: they may
only convey information (Identify rule).
Roles are important and warrant
further discussion. A role is a purpose,
responsibility, or duty. The Role rule
requires that every object and method
have a role that can be summarized in
a few words, preferably containing only
one verb. An example is: “Sends a fax.”
In an IDAR graph, the broadest role
(greatest responsibility) is at the top,
and the narrowest (most specialized)
roles are at the bottom.
Inheritance creates a hierarchy, so
why not use it? Unfortunately, inheritance creates a hierarchy of categories,
which is less useful than a hierarchy
To see why, examine Figure 5, which
shows a UML inheritance hierarchy
for a CD player. DiskMotor and LaserMotor are subclasses of Motor, so
they are in the motor category. You care
little about their category, however, because you need to know which objects
control these motors.
Likewise, Laser, Motor, and Au-
dio are subclasses of ElectronicDe-
vice, but that does not help because
spective subsystems, which should be
shown in separate graphs.
A dashed arrow denotes a data flow.
Notice-arrows often parallel a data
flow, because data flows are usually implemented using notices. An example
is the pixelRow notice sent from the
Scanner subsystem to ImageProc.
Notice that the names of some commands and notices in Figure 4 are prefixed with numbers. These optional
sequence numbers show the order of
actions composing an operation. In this
case, they show the sequence of calls to
send a fax. A copy of this graph could be
enhanced to show the sequence for receiving a fax. Such annotated graphs replace sequence diagrams in UML. They
are easier to understand because you can
see which actions are commands versus
responses, in addition to their order.
It might surprise you that the IDAR
graph in Figure 4 is the same design as
the UML diagrams in Figures 1 and 2.
Compare these diagrams. In the IDAR
graph, you can easily see which objects
control which others, thus revealing
how this design operates.
The principles underlying IDAR graphs
can be expressed in the form of four
rules. They form the acronym IDAR, the
namesake of these graphs. The rules are:
˲ Identify. Each public method in an
object is identified as either a command
or a notice. From its caller’s viewpoint, a
notice only imports or exports needed information. A command may do anything.
˲ Down. When graphing the calls to
commands among objects, the arrows
must point down.
Figure 1. UML class diagram for a fax machine.
Figure 2. UML communication diagram for sending a fax.