UNIFIED MODELING LANGUAGE (UML) 6 is the de facto
standard for representing object-oriented designs. It
does a fine job of recording designs, but it has a severe
problem: its diagrams don’t convey what humans
need to know, making the diagrams difficult to
understand. This is why most software developers use
UML only when forced to. 1
For example, the UML diagrams in Figures 1 and 2
portray the embedded software in a fax machine.
While these diagrams are attractive, they do not even
tell you which objects control which others. Which
object is the topmost controller over this fax machine?
You don’t know. Which object(s) control the Modem
object? You don’t know.
People understand an organization,
such as a corporation, in terms of a
control hierarchy. When faced with an
organization of people or objects, the
first question usually is: “What’s controlling all this?” Surprisingly, UML
has no concept of one object controlling another. Consequently, in every
type of UML diagram, no object appears to have greater or lesser control
than its neighbors. This absence of a
control hierarchy in software design
does much harm in the following ways:
˲ Designs are difficult to understand.
Showing no hierarchy is like portraying
a corporation by drawing a line between
every pair of employees who interact
with each other. Such a chart would
rapidly become incomprehensible spaghetti. An organizational chart is drawn
as a control hierarchy for good reason:
people can readily understand them,
regardless of the corporation’s size.
˲Because any object can interact
with any other object in any way desired, code structure slides into disorganization as people add features and
interactions to objects during design
˲ Maintenance becomes slower and
more error-prone because learning
curves are steeper. In addition, maintainers can and do insert hacks anywhere, causing code to decay.
These problems mean designs tend
to become messy during both initial
implementation and maintenance, resulting in more bugs and delays.
The Basics of an IDAR Graph
To be useful, a graph that portrays
software design must communicate
in a way that humans understand. An
organization of objects in software is
analogous to a human organization,
and almost without exception, an organization of people is portrayed as a
control hierarchy, with the topmost
person having the broadest span of
control. Based on this idea, Figure 3 is
a simple IDAR graph that portrays part
of the same fax machine design shown
in Figures 1 and 2, but expressed as a
Article development led by
An improvement over UML.
BY MARK A. OVERTON