Comparison of Diagramming Methods
When it comes to recording the results of a system analysis, there are so many diagramming tools and methods available that it can be difficult deciding which one to use. This paper compares the various graphical diagrams used in system analysis, focusing on those documentation models that have become industry standards. It is targeted for the reader who has an introduction to standard diagramming methods including flowcharts, entity-relationship, data-flow, and object-oriented diagrams, but not necessarily their supporting methodologies. We will explore the differences among the diagramming models used primarily within these methodologies.
If you've had some exposure to these tools  (even informally), this may help you get a better understanding of which diagramming model  should be used under different analysis conditions and settings. Under optimal conditions, your methodology will tell you, but no methodology is perfect, so this isn't always the case either. Let me begin by describing an academically-correct development environment.
A methodology is the result of someone having studied a method of system development. A complete methodology outlines the steps that a developer has to go through from the inception of a software product, through its development and implementation life cycle, and terminating only when the product becomes obsolete.
The documentation of the activities in these steps is often facilitated by graphical diagrams which concisely represent various aspects of the system that is being modeled. System analysts usually employ at least one methodology, especially the structured analysis techniques which result in data-flow and entity-relationship diagrams. However, there are some analysts (and many programmers) who are not familiar with any methodologies, or they may be unable to commit to a particular one.
Even without the use of a methodology, however, it is possible to use a diagramming method and reap some benefits of a methodology without completely understanding it - I'm living proof. Some diagramming methods are even simple enough to learn just by viewing a few examples. In addition, inexpensive diagramming tools facilitate diagramming with or without a supporting methodology. Some languages (e.g. Microsoft's Visual series) even provide diagramming tools with barely a hint that methodology is being implemented (or they pick one you're not using). This just encourages the no-holds-barred, seat-of-the-pants kind of development that exists beyond the confines of a methodology, an environment that most programmers actually prefer.
Developers such as these may find (as I have) that the diagramming tools at hand provide a variety of ways to represent the same diagram, with no guide as to which method is best. In some cases, the supporting methodologies don't help you decide either. So, which one do you choose?
Unfortunately, to apply the best solution to your problem, you have to be familiar with all the tools available to you. I don't know what tools you have, but Visio is right at my fingertips. So if you'll pretend you're me for a moment, I can walk you through the problems I've encountered and we can both learn something from this exercise. First, let's make sure I haven't lost you already.
Let's assume that you have a good, powerful, but easy-to-use diagramming tool such as Visio. Visio provides a variety of templates  that directly correlate with a particular methodology (apparently). Each template has 15-30 icons, complete with descriptions, that you can drag and drop on your diagram to begin documenting your system. I'm not promoting Visio, or even condoning its use - it's just been available at two of my workplaces, so I use it.
Let's further assume that you have an idea about which diagram you want to create. For some types of diagrams, there's only one template to select. However, if you're designing (documenting) a database system or an object-oriented system, you'll have to make a choice. These are two of the areas where the greatest variety of methodologies exist, and where you will need the most help in deciding which template to use. Unfortunately, these are the areas where most new development is currently concentrated.
Before discussing the details of any template or methodology, there are two principles that are common to all diagramming techniques. First, the context of a diagram must be clear, and second, each diagram must present a view of the system that is independent of other views.
A diagram's context must be fully understood by its title, title block, a reference to a larger (smaller) context, or some combination thereof. Time and version dependencies should also be considered. Care to waste your time writing a new program - from an old database document? A date and time stamp will resolve any confusion. If you can expect a second version to be made (almost always), a version identification will also help. Some media (e.g. the Internet) facilitate keeping a document within context, while others (e.g. paper) require extra care.
If there will be more than one type of diagram for a system, each diagram type must be Orthogonal to all the others. Orthogonal projections show aspects of a system from perspectives that are fully independent of each other. In the same way that an architect views a building plan from front, side and planar elevations (relating to the perpendicular x, y and z axes), we we want to view a system from similar orthogonal views. Given a 3-dimensional system, any 2-dimensional view will hide components that occur in the other dimension. The same principle applies when you move from a physical, 3-dimensional system to a software system which can have even more independent dimensions. Having multiple perspectives ensures that there aren't any portions of the system that remain hidden or under-analyzed.
Now that we've established a context for our discussion, let's evaluate some of the methodologies in which we have overlapping diagramming techniques. I've chosen three to discuss in detail: entity-relationship diagrams, data-flow diagrams, and object-oriented diagrams. It would have been best to select orthogonal techniques, but as you'll see, there is some overlap even within these well-established practices.
Logic Flow Charts
Flowcharts are no longer considered a modern technology, but it may be the only type of diagram some users have been exposed to. Flowcharts focus mostly on decisions, a special type of process that now appears in data-flow and object diagrams. However, if you do need to document a logical decision flow, there are two Visio templates available, described below.
Language Level Diagrams
This Visio stencil contains shapes useful for creating functional decomposition diagrams and program structure diagrams. One particular icon, flowchart shapes, can be used to create conventional flowcharts. This Visio smart shape can be morphed into any of the four shapes used in flowcharts. A summary of conventional flow charting technique is as follows:
Also known as Chapin Charts, Nassi-Schneiderman (N-S) diagrams  are a modern alternative to flowcharts for the following reasons:
Entity Relationship Diagrams
As the name describes, an entity-relationship diagram (ERD) is used to model the entities that a computer system records information about, and the relationships between those entities. The evolution of an ERD typically progresses either from scratch (through an interview process) or is reverse-engineered from an existing database schema. The varieties of ERD's therefore support various stages of development, beginning with a user-readable form that allows validation of a design, and culminating in versions that are used by developers to validate a design at detailed and/or summary levels.
Many developers and CASE tools still use Bachman's crow-foot notation  to indicate the cardinality of a relationship. Where necessary, a relationship type is often written on or near the line that represents a relationship. Since the Bachman notation is unique only in representing the relationship (a line), and Visio allows you to draw a line anywhere and/or change the line-ends anywhere a line is drawn, the Bachman crow-foot notation can be used with any other template.
Chen's original method  is the basis for many writings on ERD's [3, 12]. While the traditional aspects of entities and relationships are represented as boxes and lines (respectively), there are a number of unique attributes to his present method :
Visio's Martin ERD template is based on the symbols used in the Martin notation  to draw object-oriented analysis and design diagrams. This notation has the following attributes:
A diagram that uses all of these notation elements simultaneously can be very elaborate and potentially confusing. By conventional techniques, an ERD will only contain entity, data item, and relationship symbols, while the remaining elements (especially activity and event items) usually appear in an object diagram.
Data Flow Diagrams
The formal, structured analysis approach employs the data-flow diagram (DFD) to assist in the functional decomposition process. I learned structured analysis techniques from DeMarco , and those techniques are representative of present conventions. To summarize, DFD's are comprised of four components:
The following templates are described with respect to these conventions. These Visio templates include nodes with a sub-paging feature that facilitates creating subordinate diagrams, and in navigating multi-tiered models after a design has been completed.
Chris Gane / Trish Sarson
The Gane/Sarson method  stresses the identification of each node to help reference process narratives that further define each component either in plain text or pseudocode.
Yourdon and Coad
This Visio template, based on the Yourdon and Coad method , includes components for creating data-flow diagrams and also object state diagrams. Some unique attributes of their DFD notation include:
Object Oriented Diagrams
Given the presence of four Visio object-oriented diagram templates, and the fact that many of the diagramming methods contribute to UML emerging as a standard , it is instructive to review each template and note its features.
Sally Shlaer and Stephen Mellor
The Shlaer/Mellor method  is considered an older technique that should be used on existing projects that have not migrated to UML . The major components of this model include:
Rumbaugh's methodology, the Object Modeling Technique (OMT) , defines class, object, state, and data-flow diagrams to model a system analysis and design. Rumbaugh is a major contributor to UML (described below) and the Fusion method . Unique attributes of OMT object models include:
The Object Modeling Technique also allows two different models of data to be displayed in the same diagram. By doing so, one diagram can show two different levels of association.
Booch's notation  is generally regarded as the most complete for representing object-oriented systems . Unfortunately, the notation is also complex and can lead to fragmented or duplicated information across model diagrams. Booch considers himself more of a developer than a methodologist, so he concentrates more on the results of system analysis and design than its process. He is a major contributor to UML, and has also made his notation a property of the public domain.
His notation includes six types of diagrams: class, object, state transition, interaction, module, and process. The Visio Booch template supports all of these except state transition, which is supported with the Rumbaugh template.
Unified Modeling Language
The Unified Modeling Language (UML) is "a language for specifying, constructing, visualizing and documenting the artifacts of a software-intensive system" . UML has evolved from the work of Grady Booch, James Rumbaugh, and Ivar Jacobsen, associates at Rational Corporation. These three assimilated their respective technologies into a single specification that was published in January, 1997. With the help of the Object Management Group , UML is rapidly becoming an industry standard documentation method.
UML does not mandate a particular development process, although it was designed to support a variety of object-oriented development processes. It is hoped that the existence of a widely-accepted documentation standard may contribute to a standardized process.
A system that has been documented with UML will be comprised of one or more of the following documents:
Use-Case diagrams are based on Jacobsen's OOSE methodology  and have the following features:
With at least a basic guide as to their use, diagramming tools can be wonderful instruments for documenting a system analysis and design. Although it is helpful to have a methodology to support development activities, there are many instances where they are not used. But even though a diagramming tool was designed to be used with a methodology, the lack of a developer's access to the methodology need not be a hindrance to the use of the diagramming tool.
A developer must select a set of diagram templates that serve his or her needs either by relying on a prescribed methodology or by exploring the capabilities of the diagramming tool and comparing the diagramming methods that are available within the tool. As tools become more versatile, this choice becomes more difficult to make. Fortunately, industry trends such as UML are helping to limit choices and yet retain the versatility that developers need.