What is IDAR? It’s a better way of designing software and of graphing designs. IDAR makes designs so clear that they resist the usual slide into messiness that wastes your time. And their vivid clarity helps you to notice bugs before they are coded, saving even more of your time. Here are free articles about IDAR:

• The first article about this method was published by the ACM (Association of Computing Machinery), which is an old and prestigious organization of computer science professionals. The article titled “The IDAR Graph” appeared in the May 2017 issue of ACM Queue, and is freely available online here.
• The above article was also published in the July 2017 issue of the ACM’s flagship paper magazine, the Communications of the ACM (CACM).
• For the second free article, scroll down.

The definitive description of the IDAR method (and IDAR graphs) is this $25 book (365 pages) written by Mark A. Overton, the inventor of IDAR graphs. The two articles contain enough information to get you started. But if you wish to learn the many features of IDAR graphs, how to gauge the goodness of designs, and the useful new design patterns that accompany IDAR graphs, you can order the book from Amazon or Barnes and Noble.

Scroll down to read the second article...

An Overview of The IDAR Method and IDAR Graphs

Last updated: April 7, 2018

Synopsis

IDAR graphs are a more understandable way of portraying the designs of object-oriented software than UML. In fact, and this is surprising, IDAR graphs are the only effective way we have of portraying how software operates. In addition, this graphing technique is upheld by four rules governing design. Those rules, plus some additional criteria for gauging the goodness of designs, changes software development from an art into a proper field of engineering. That’s a strong statement, but I justify it below.

UML is Hard to Understand

The UML diagram above is for an astrology application. The lines between classes indicate which classes know about each other. An arrowhead indicates that the knowledge is one-way. Based on this diagram, do you understand how this software operates? Me neither. For example, which object controls all this? You don’t know. Which objects are managers versus workers? You don’t know. This diagram fails to convey what you need to know most: the hierarchy of control.

Imagine trying to portray the structure of a corporation by drawing a line between every pair of employees who talk to each other. Such a talks-to diagram would rapidly become incomprehensible spaghetti like this:

Real-life UML class- and communication-diagrams for large programs actually look like this because they show all talks-to relationships. What a mess! Talks-to diagrams are useless.

IDAR is Easy to Understand

Instead of the talks-to spaghetti that UML provides, people need to see an organization such as a corporation expressed as a hierarchy of command, with the highest manager at the top, down through lower layers of management, and with the workers at the bottom. This approach also works well with software.

This IDAR graph portrays the same astrology application as seen earlier, but now you can see the levels of control in it. A downward arrow connecting two boxes (objects) means that the upper object commands the lower one, forming a superior-subordinate relationship, like a boss and a worker. A floating arrow represents secondary communications between objects called “notices”. Commands and notices are merely method-calls, and are usually labeled by their arrows.

In this graph, you see that AstroGUI is the top-level controller, and that Forecaster commands Random to getFiction (i.e., Forecaster calls a command-method in Random named getFiction). The fiction is returned to Forecaster in the fiction notice. UML told you none of this. IDAR graphs are much more informative than UML diagrams.

Object-oriented programming (OOP) has a feature called “inheritance” which creates an attractive hierarchy in UML. Unfortunately, this is a hierarchy of categories, which is of little use. For example, an inheritance hierarchy could show that a Fan is in the Device category (superclass). But that doesn’t help you because you need to know which objects control the Fan. IDAR provides a hierarchy of control, which is what humans need.

The Rules

• Identify: You must identify each public method in an object as either a command or a notice. From its caller’s viewpoint, a notice only imports or exports needed information.
• Down: When graphing the calls to commands among objects, the arrows must point down. In this graph, an arrow connecting two boxes means that code in the upper object (box) calls one or more commands in the lower object.
• Aid: A command or notice may, unknown to its callers, aid its own object by performing part or all of a previously commanded action.
• Role: Write a brief role 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.

It’s important to remember that commands and notices are methods. Therefore, an object commands another object by calling a command (method) in the target object. In other words, the way you command another object to do something is by calling a command (method) in it. Likewise, an object notifies another by calling a notice (method) in it.

These four rules form the foundation of IDAR, but there are additional rules about drawing IDAR graphs. For example, an elongated hexagon denotes a subsystem, a dashed arrow denotes a dataflow, and a horizontal line (called a “rail”) is used to group subordinates under one or more superiors, analogously to a corporate organizational chart. A “free notice” is one that does not follow a command-arrow. On the graph, first draw a dummy dashed line (with no arrowhead) connecting the two objects, and then draw the free notice’s floating arrow next to it. Also, a notice can be carried back on a method-return of a command as its function-value or via a changed parameter. Such a “rider notice” is not drawn with a floating arrow, but is labeled next to the command-label with a caret followed by its name, as in ^result. Finally, a class that produces multiple instances is drawn as a stack of boxes labeled with the class name, such as Multiple in the figure below, which illustrates these additional features of IDAR graphs.

Benefits

IDAR graphs impart several benefits, but the most important are ease of understanding and resistance to messiness. These graphs are easier to understand than UML for several reasons:

• For each object in the graph: The nature of its superiors indicates why it exists; the role of the object itself tells you what it does; the object’s subordinates provide hints about how the object works. Cognitive engineers refer to these three forms of insight as the “why-what-how triad”, where the triad consists of an object, its superiors, and its subordinates. UML lacks these triads, so it can’t tell you why an object exists or how it works.
• Research has shown that people understand software as an integrated interplay of its structure and behavior. IDAR provides both in one graph, but UML splits structure and behavior into separate diagrams, hindering comprehension because people are forced to combine them in their minds.
• The hierarchy reveals which objects are high-level controllers versus low-level workers. UML has no concept of levels of authority, badly hurting comprehension.
• In IDAR graphs, command calls are more prominent than notice calls, because they are more important. UML has no concept of degrees of importance.

IDAR graphs resist the natural tendency toward messiness because the four rules provide reasonable constraints on what developers can do. They are not allowed to create spaghetti by calling anything from anywhere. UML provides no defenses against spaghetti-structure.

Surprisingly, imposing these rules makes design easier, instead of harder as you would expect. The rules provide guidance. They require that you have a topmost controller, so that object is obvious. The hierarchy forces you to have bottom level objects, and they are usually obvious as well because they interact with the outside world or contain detailed algorithms. With these top level and bottom level objects anchoring the graph, it’s easier to define the objects between them. UML provides none of this guidance.

IDAR graphs have been employed in a medium-size pilot project at the Northrop Grumman company, and in a variety of life-size trial programs, assuring us that they are both practical and sufficiently flexible.

From Art to Engineering

Art is primarily subjective, with no rules that ensure the artwork will be good. Some heuristic rules are available to the artist which provide assistance, such as matching colors, balance, and not touching the sides and corners of the canvas. Likewise, a software developer is given some heuristic rules, commonly expressed as “smells”. Such rules help avoid creating bad designs, but don’t ensure that designs are good.

On the other hand, a field of engineering employs “design rules” to ensure that the resulting design will be reasonable, meaning that it will work and not be wasteful. For example, there are rules for electrical engineers about placement and lengths of traces on circuit boards. UML and smells provide no analogous way of ensuring that a software design will be reasonable.

Fortunately, IDAR provides the four rules which eliminate messy aspects of designs, and ensure that every design consists of a hierarchy of roles, with the broad roles at the top and narrowest at the bottom. Furthermore, IDAR offers the following criteria for evaluating the quality of a design:

• Clarity: A role such as “sends a packet” is clear because it plainly communicates what the object or method does. An unclear role such as “processes sample-data” leaves you wondering.
• Cohesion: A role has high cohesion if all actions described in it are closely related, being directed toward one purpose. Having multiple purposes (such as side-effects) reduces cohesion.
• Concealment: This is how well a role conceals the details of implementation. A role has high concealment if it tells you what is done rather than how it is done.
• Coupling: This is the visibility and degree to which two objects or methods communicate with each other. There are five principles of good coupling having the acronym SPIED. They are described in the book referenced below.
• Need: This is the extent that a superior needs a subordinate. A couple of common errors in design result in little need for a subordinate.

Although these quality-criteria are partly subjective, they can be assessed as good/medium/poor/unacceptable with decent consistency from person to person. When the four rules are combined with these criteria, we are assured of creating a reasonable design, changing software design from an art into a proper field of engineering. IDAR causes “software engineering” to no longer be an oxymoron.

More Information

• It’s best to obtain the inexpensive book about the IDAR method. Go to any bookseller’s website and search for “IDAR Method Overton” (without the quotation marks), and you will find the book, The IDAR Method of Software Design, by Mark A. Overton. It describes not only IDAR graphs in detail, but also includes a five-step design method, the three criteria for assessing the quality of roles (clarity, cohesion, concealment), the five SPIED principles of creating good coupling along with other important criteria for gauging the goodness of designs, and four life-size sample applications. Here are links to Createspace (which is preferable), Amazon, and Barnes and Noble.
• An article about this method appeared in the May 2017 issue of ACM Queue, and is available online here. This article covers IDAR graphs in more detail than this brief overview.
• The above article was also published in the July 2017 issue of the Communications of the ACM (CACM).
• You can contact Mark Overton at the following email address: idarmethod@companyname.com, but replace the company-name in that address with the name of Google’s free email-service. Also, be sure your subject-line starts with “IDAR”.