Limitations of IDAR Graphs
IDAR graphs do have the following limitations:
˲ Object level. IDAR is intended
for object-level and subsystem-level
design, so it’s neither an ADL (
architecture description language) nor a
system modeling language. For modeling a system, OPM (Object Process
Methodology) 1 is a strong contender.
˲ Requires centralized control. IDAR
relies on control being organized as a
command hierarchy, making it unsuitable for decentralized software with
distributed control. The top levels of
such software should be modeled in
another way. At some level, however,
the components of decentralized software are amenable to centralized control and can be designed using IDAR
graphs like ordinary software.
˲ Less expressive than UML. UML
can portray more views of designs than
IDAR. For example, an IDAR graph is
incapable of portraying transitions
among states, deployment onto processors, or generalizations among
classes. UML has diagrams for these
and other aspects of design, and they
should be employed when appropriate.
A Pilot Program
An important program was designed,
coded, and deployed at Northrop Grumman using IDAR graphs. Responsible
for calibration and testing of circuit
boards and systems, the program is being used on the production line of an
electronic product. We are forbidden
from publishing this proprietary design,
but we can say it has 23,000 lines of C++
code and is complex enough to have 38
classes, four subsystems, and 10 threads
to handle various realtime matters. This
medium-size program is not a toy.
Several people wrote and modified
this program over several years, so it
had become somewhat messy and was
not even object oriented. The program
consisted solely of tests, and I was
charged with adding much nontest
functionality to it, more than doubling
its size. Thus, more than half of the
code represents new design.
The existing code was refactored,
creating objects conforming to the
IDAR rules. I then designed and added
the new capabilities in stages. During
this process, unexpected requirements
were added to the project, stress-test-
ing the IDAR approach. IDAR graphs
accomplished the following:
˲ Maintained clarity throughout de-
sign and implementation. Interactions
among objects were so clear that any
potential problems of misunderstand-
ings among objects were avoided;
˲Easily accommodated several
changes and additions to the require-
ments. The hierarchy’s clarity made
it obvious where changes required by
new features should be made;
˲ Enforced good organization;
˲Did not impose excessive con-
straints on the design. The four rules
provided enough flexibility that the
design did not need to be contorted in
order to satisfy them; and,
˲ Made design easier because the
rules provided guidance. The top and
bottom objects are easy to define, and
defining objects between those anchor
objects is not difficult. This ease of de-
sign was a surprise because imposing
four rules would be expected to make
designing more difficult, not easier.
Based on its results, those of us familiar with this effort believe the chief
benefits of IDAR graphs over UML are
their great clarity and enforcement of
good organization. This pilot program
was a strong success, and managers
were pleased enough that they arranged
for IDAR to be taught to the other software developers.
In addition to this pilot program,
many trial designs have been created
using IDAR graphs, and four life-size
applications are described in The
IDAR Method of Software Design. 5
A hierarchy of roles appears to be essential for clearly portraying the design
of any centralized organization, whether it consists of people or objects. The
inability of today’s object-oriented
programming technology to represent
this crucial kind of hierarchy is surprising, and perhaps its absence has been
accepted based on the incorrect belief
that an inheritance hierarchy is a suitable substitute.
An IDAR graph is clearer than UML
for two main reasons: It reveals the hi-
erarchy of roles and the breadths of
those roles; and the triads (why-what-
how) offer deeper insights into the na-
ture of objects. UML cannot provide
these. Given that IDAR graphs are clear-
er than UML, and that the four rules un-
derlying them resist messiness, devel-
opers should produce fewer bugs when
designing and implementing software
using IDAR graphs. The result will be
improved quality and timeliness.
This article contains enough in-
formation to enable readers to create
designs using IDAR graphs. For more
information, you can download the
slides from a presentation at the IEEE
Software Technology Conference in
2014.4 Also, refer to The IDAR Method of
Software Design, 5 which not only details
this method (and related topics), but
also includes the four life-size applica-
tions mentioned in this article.
Acknowledgments. I am indebted
to Jim Ray for his consistent support
of the IDAR method. Thanks to Jim
Wilk and Dorothy Kennedy for their
unswerving support. Sammy Messian
managed the pilot program that used
IDAR and values it for the fine results
it produced. All four are managers at
UML Fever: Diagnosis and Recovery
Alex E. Bell
Coding for the Code
Friedrich Steimann and Thomas Kühne
Software Development with Code Maps
Robert DeLine, Gina Venolia, and Kael Rowan
1. Dori, D. Why significant UML change is unlikely.
Commun. ACM 45, 11 (2002), 82–85.
2. Kiczales, G., et al. Aspect-oriented programming.
Proceedings of the 11th European Conference on
Object-Oriented Programming: (1997), 220–242.
3. Moody, D., van Hillegersberg, J. Evaluating the
visual syntax of UML: An analysis of the cognitive
effectiveness of the UML family of diagrams. Software
Language Engineering. Springer-Verlag, Berlin,
Heidelberg, 2009, 16–34.
4. Overton, M. Command graphs: a significant
improvement to OOP/OOD. IEEE Software Technology
Conference, 2014; http://conferences.computer.org/
stc/2014/ index.html or http://www.ieee-stc.org.
5. Overton, M. 2014. The IDAR Method of Software
Design. CreateSpace, Seattle, WA, 2014.
6. Rumbaugh, J., Jacobson, I., Booch, G. Unified Modeling
Language Reference Manual, 2nd ed. Addison-Wesley,
Boston, MA, 2004.
7. Vicente, K. Cognitive Work Analysis. Lawrence
Erlbaum Associates, Mahway, NJ, 1999, 174–176.
Mark Overton is a software engineer at Northrop
Grumman working on various parts of software-defined
radios. He previously worked at HP, contributing to both
the architecture and implementation of all-in-one printers,
particularly their scanners.
Copyright held by owner/author.
Publication rights licensed to ACM. $15.00.