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 [13] (even informally), this may help you get a better understanding of which diagramming model [14] 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 [15] 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.

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.

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:

1. Functions, or processses, are represented by rectangles.
2. Decisions are represented by diamonds.
3. Inputs are represented by parallelograms.
4. Outputs are represented by a hardcopy symbol (a rectangle with a wavy bottom edge).

Also known as Chapin Charts, Nassi-Schneiderman (N-S) diagrams [16] are a modern alternative to flowcharts for the following reasons:

1. N-S diagrams are an alternative to pseudocode.
2. An N-S diagram can be drawn using text and lines (or completely with ASCII characters).
3. N-S diagrams show processing by series, by selection, or by iteration.
4. N-S diagrams are read from top to bottom.
5. N-S diagrams are more structured than flowcharting (one start, one end).

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 [10] 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 [2] 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 [4]:

1. The cloud symbol represents aggregations of smaller ER diagrams, in the context of a logical design (as opposed to a physical design).
2. The double-box represents a weak entity, which is dependent on its parent entity. Note: Visio does not support this feature.
3. A diamond symbol represents a type of relationship.
4. Relationship adornments are added adjacent to the lines to indicate connectivity (I, M, N) and cardinality, e.g. "(0,3)".
5. The data-structure diagram (an alternate form of the ERD) uses arrows to show I:M relationships.
6. Circles represent the attributes of an entity, although Visio labels this icon as value.
7. A human figure represents a user icon.

Visio's Martin ERD template is based on the symbols used in the Martin notation [9] to draw object-oriented analysis and design diagrams. This notation has the following attributes:

1. Rectangles and ovals represent entities and attributes (or data items), as with Chen's notation.
2. Simple lines indicate relationships, and adornments are added adjacent to the lines to indicate the type of relationship (written) and its connectivity (0, 1, *).
3. A line with a midpoint arrow indicates a message or data-flow.
4. Simple lines connected by a dot indicate a boolean and/or computation.
5. A rounded rectangle represents activity.
6. A large arrow represents an event.
7. A triangle with a numeric label represents a connection.

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.

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 [7], and those techniques are representative of present conventions. To summarize, DFD's are comprised of four components:

1. External interactors are represented by a rectangle.
2. Data stores are represented by an open rectangle (2 or 3 sides).
3. Processes are represented by any rounded object (a circle, oval, or square with rounded corners). A DFD process may represent system function at one of various levels, atomic through aggregate.
4. Data flows are represented by arrows, with labels indicating their content.

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.

The Gane/Sarson method [8] stresses the identification of each node to help reference process narratives that further define each component either in plain text or pseudocode.

1. A data store is represented as an open rectangle (3 sides, open on the right).
2. Processes are represented by a rounded upright rectangle, subdivided into sections for a reference value, a process description, and an optional location specifier.

This Visio template, based on the Yourdon and Coad method [5], includes components for creating data-flow diagrams and also object state diagrams. Some unique attributes of their DFD notation include:

1. A data store is represented as two parallel, horizontal lines.
2. Processes are represented by a circle, and adorned with a double circle for multiple processes (indicating that further decomposition exists at a lower level). Note: the oval process should be reserved for object or class 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 [17], it is instructive to review each template and note its features.

The Shlaer/Mellor method [18] is considered an older technique that should be used on existing projects that have not migrated to UML [19]. The major components of this model include:

• Domain chart - used to partition the system into domains and subsystems.
• Information Model - used to build a static analysis model of a system. This shows objects, relationships, and inheritance structures, and define class attributes and methods. Designate primary keys and formalize relationships.
• State model - used to analyze the object's behavior over time.
• Process Diagram, or Action Data Flow Diagram, for an action shown in the State Model.
• Object Communication Model (OCM) - summarizes the asynchronous event communication between state models in the system.
• Object Access Model (OAM) - summarizes the synchronous communication between state models and object instance data.

Rumbaugh's methodology, the Object Modeling Technique (OMT) [11], 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 [6]. Unique attributes of OMT object models include:

• Object diagram

1. Object nodes are subdivided into sections for data and processes.
2. Object attributes are shown as text, not as separate nodes.
3. Ternary associations between objects are shown as diamonds, with lines connecting the participants.
4. Inheritance relationships are shown as lines with various line ends.
5. Cardinality characteristics are shown as relationship adornments.

• State-transition diagram (dynamic model)

1. Processes are shown as ovals.
2. The initial state process is identified with a filled-in dot and an arrow that points to the first state. Similarly, the final state is indicated by an arrow pointing to a circled dot.
3. State transitions are identified with a notation "a / b", where event a causes action b.

• Data-flow diagram (functional model)

1. Processes are shown as ovals.
2. Data stores are shown as two parallel, horizontal lines (similar to Yourdon and Coad).

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 [1] is generally regarded as the most complete for representing object-oriented systems [6]. 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.

The Unified Modeling Language (UML) is "a language for specifying, constructing, visualizing and documenting the artifacts of a software-intensive system" [20]. 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 [21], 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
• Static structure diagrams (Class diagrams)
• State diagrams (activity diagrams)
• Sequence diagrams
• Collaborations
• Implementation diagrams (component and deployment diagrams)
• Stereotypes

Use-Case diagrams are based on Jacobsen's OOSE methodology [22] and have the following features:

1. An agent is represented by a human stick-figure.
2. A use case (or process) is represented by an oval
3. A use (or interaction) is represented by a double-arrow line.
4. The system boundary is shown by a large rectangle. Actors are shown outside, use cases are shown inside, and interactions between them cross the system boundary.

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.

1. Booch, G. Object-Oriented Analysis and Design, With Applications, 2^nd ed. Redwood City, CA: The Benjamin / Cummings Publishing Co., Inc., 1994.
2. Chen, Peter. "The Entity-Relationship Model: Toward a Unified View of Data" ACM Transactions on Database Systems I (I). March 1976, pp 8-46.
3. Chen, Peter. The Entity-Relationship Approach to Logical Database Design. Wellesley, MA: QED Information Sciences, c1977.
4. Chen, Peter, et. al. (ed.), Conceptual Modeling: Current Issues and Future Directions, Berlin, Germany: Springer-Verlag, 1999.
5. Coad, P. and E. Yourdon, Object-Oriented Analysis, 2^nd Edition, Englewood Cliffs, NJ: Prentice-Hall, 1991.
6. Coleman, Derek, Object-Oriented Development: The Fusion Method, Englewood Cliffs, NJ: Prentice-Hall, 1999, pp. 191-198.
7. DeMarco, Tom. Structured Analysis and System Specification / A Yourdon Book, Yourdon Inc., NY, 1979.
8. Gane, Chris and Trish Sarson. Structured Systems Analysis. Englewood Cliffs, NJ.: Prentice-Hall, 1979.
9. Martin, James and O'Dell, Object-Oriented Methods: A Foundation, Upper Saddle River, NJ: Prentice-Hall, 1998, p. 52.
10. Rob, Peter and Carlos Coronel. Database Systems. Course Technology (Div. of International Thomson Publishing): Cambridge, MA, 1997. p 260.
11. Rumbaugh, J., M. Blaha, W. Premlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Englewood Cliffs, NJ: Prentice Hall International, 1991.
12. Teory, Tobey J. Database Modeling and Design: The Entity Relationship Approach. San Mateo, CA: Morgan Kaufmann, 1990.

Web Resources

13. College of Staten Island, the City University of New York, "Case Tool Index", http://unlser1.unl.csi.cuny.edu/faqs/software-enginering/tools.html, last update unknown, last accessed: 11/26/1999.
14. Excel Software, "Software Models", http://www.excelsoftware.com/models.html, Last modified: (unknown), last accessed: 11/27/1999.
15. Visio Corporation, Software Diagramming Stencils (Untitled), http://www.visio.com/solutions/directory/software/diagramming/stencils/index.html, ã 1997-99, last accessed: 11/26/1999.
16. Paul R. Seesing, "Basic Systems Analysis Tools for Computer Users", http://www.open.org/~prslkg/sy_chap.htm, ã 1993, last accessed: 11/26/1999.
17. Visual Object Modelers, Inc., "Visual UML Product Information", http://www.visualobjectmodelers.com/products.htm, last updated: 11/18/1999, last accessed: 11/26/1999.
18. Dr. John Osmundson, "11.0 Software Engineering Related Management Issues", http://www.stl.nps.navy.mil/~josmund/SWmgmt11o/sld033.htm, Last modified: 5/19/1999, last accessed: 11/27/1999.
19. Popkin Software, "Shlaer/Mellor", http://www.popkin.com/products/sa2001/object/ shlaer.htm, Last updated: 11/24/1999, last accessed: 11/27/1999.
20. Rational Software Corporation, "UML Resource Center: Unified Modeling Language, Standard Software Notation", http://www.rational.com/uml, ã 1995-99, last accessed: 11/26/1999.
21. Object Management Group, "Object Management Group Home Page", http://www.omg.org, ã 1997-1999, last accessed: 11/27/1999.
22. Edward Kenworthy, "PG to Use Case Modelling", http://www.zoo.co.uk/~z0001039 /PracGuides /pg_use_cases.htm, Last modified: 12/2/1997, last accessed: 11/27/1999.

Author: Keith Stiern

Source Address: http://www.umsl.edu/~s1028363/DiagrammingMethods.html

Created: November 28, 1999