System Diagram Essentials

By J. W. Rider

October 2004


Information about a system or program being developed is often communicated from the customer to the developer in graphic form.  The diagram types described here are not the only ones that may be used.  However, most diagrams in vogue offer one or more of the following concepts to accentuate a particular aspect of a system or computer program under development.


The diagrams described in this document are control flow diagrams (or “flowcharts”), data flow diagrams (or DFDs), context or collaboration diagrams, function decomposition hierarchies, referential or modular decomposition hierarchies, class hierarchy, state diagrams (or “statecharts”), use case diagrams and Venn (set) diagrams.  Activity diagrams are mentioned briefly, but for the most part those have both state and control flow characteristics.


What follows are not bona-fide examples of the kinds of diagrams discussed.  Most of these diagrams would have several steps/processes/objects and be connected by dozens of lines.  This documents only addresses the essence of the techniques, abbreviating a larger diagram with only a very few items.  You should certainly learn more about any specific diagramming technique before using it.  However, if you’re on the spot and get asked “what does it mean to have ‘A’ and ‘B’ connected here?” you’ll be able to answer “It depends” and elaborate from there.



Control flow diagrams (or “flowcharts”) break a process down to a finite number of steps that get executed one at a time.  In a single-threaded system, only one of the steps is being executed.  The control flow governs how the next step to be executed is determined.



Control flow does not say anything about what the inputs and outputs of steps A and B are.  It does not address why we might want to perform step A and then step B.  It does not address how steps A and B get performed internally.  In general, when a step completes, only a single arrow emerges from the box.  A special case step called a “decision” will cause one of two or more paths to be followed based upon some condition that exists when the decision is executed.  These diagrams start and stop with terminal steps.


Recursion, where the exit path from one step merges into a path that eventually reenters the same step, is commonplace.  This creates cycles or “loops” within the flowchart and requires the use of decisions.  In connection with control flow, programmers don’t call this phenomenon “recursion.”  They use a more specific term called iteration or “looping.”  Programmers reserve the term recursion for cycles in referential hierarchies (discussed later in this document).


Nesting is accomplished by replacing a single step in a control flow diagram with a control flow that is more complicated.  Nesting is commonplace but, if carried to extreme, creates diagrams too complex to understand.



Data flow diagrams (or “DFDs”) are somewhat similar to control flow diagrams.  However, rather than showing the strict order of execution of steps, the DFD shows how processes depend upon one another for information.


Data flow simply shows that information needed by one process is created in another process.  Process A could have many such outputs.  Process B could have multiple inputs.  Value C could have various parts output by multiple processes.  Value C could be input into multiple processes.  Some processes will get their inputs from outside the system.  The outputs of some processes may not be used by other processes and represent the outputs of the system.


Data flow does not describe the order in which processes are performed.  Despite the apparent ordering, nothing in the data flow diagram suggests that A must be finished before starting B.   The Value C may be output and input at arbitrary times. A convenient way to understand the data flow is to envision all the processes as working simultaneously.


Recursion is commonplace.  Engineers call it “feedback.”


Nesting is rarely used explicitly.  It is far more common to elaborate details about the contents of any process in a separate diagram.  This creates an implicit hierarchy.  The top of the hierarchy is called a “Level 0” diagram.  It usually just consists of a single node that represents “the system” and shows all external inputs to and outputs from the system.  More detailed diagrams get higher level numbers the further from the level 0 diagram that they are. 


The dual interpretation of a data flow diagram is to represent data at the nodes and the processes by the arrows.  Sometimes, this is called “process flow.” In that case, the diagram above would be translated as “Process C uses value A in order to output value B.



Context (collaboration) diagrams abstract many of the nuances of a data communication relationship between objects within a system or program.

On the surface, this looks like simple, one-way data flow.  To be sure, object A could send information to object B this way.  However, it’s also possible for object A to be sending a query to object B and receive information that B has previously stored.


For object-oriented programmers, this diagram is often interpreted to mean that the message-sending object A contains a line of code that looks something like “result=B.C(arguments);”.  That’s just the simplest implementation.  It implies that the object A is taking all the action.  However, there’s no requirement in context diagrams that the objects reside in the same namespace, which is how A knows what B’s name is.  A more elaborate interpretation is “Some channel(s) of communication exists between the two objects.  At some point in time, object B selects a channel for receiving, and object A selects a channel for sending message C to object B.  Object A may or may not know which object is the receiver of the message.  Object B may or may not return a result from this message transmission.  It is the channel that needs to know where the receiver is.  Multiple messages could be passed back and forth through the same channel.  Object A can send messages to multiple objects.  Object B can receive messages from multiple objects.


Context diagrams are useful for showing how a proposed system may behave for a specific example or scenario. They are hardly ever intended to be complete.  Theoretically, the merging of all context diagrams should show the complete message traffic that all objects within the system must implement.



Hierarchy diagrams occur in a variety of flavors.  Sometimes, hierarchy is implied.  This would be the case of taking a single DFD process and elaborating it in a separate DFD. Explicit hierarchy diagrams have been used to illustrate business organization, family trees, and the directory structure of file systems. 


Topical outlines are equivalent to hierarchy diagrams.


For system development, three distinct hierarchy diagrams are used commonly.  One shows functional decomposition. Another shows referential dependency.  The third shows characteristic inheritance.  It’s easy to mix the three, but doing so causes considerable confusion.



Functional decomposition looks to the inside of the superior thing (or “function”) and shows what subordinate things (“sub-functions”) compose the superior.  Although, the terminology here uses “function,” the subordinates are not separate items from the superior.  The subordinates are inherently a part of the superior item.  In ideal decomposition, the superior function consists of nothing other than its subordinates, and the subordinates are either a partition of the superior (the subordinates share nothing in common; e.g., a year is composed of 12 months), or orthogonal (e.g., a physical box has a volume determined by height, breadth, and depth).  Subordinates are not separate processes.


No arrow is usually drawn on these diagrams.  Instead, the superior function is placed physically over its subordinate components.


Generally, the superior function has multiple sub-functions. Generally, the subordinate function is subordinate to only one superior function, but multiple superiors are feasible.  This gives the functional hierarchy a unique tree-like graph that is cycle-free.  Cycles (having a subordinate be the superior of one its superiors; also known as a “recursive” definition) are not sensible in functional decomposition from an implementation standpoint.  However, recursive techniques do exist for analytical purposes.


Nesting is explicit with a functional decomposition.  That’s exactly what is being shown.


Equivalent diagrams include Venn (set) diagrams (at the end of this document) and Warnier-Orr diagrams (example follows immediately).

Warnier-Orr Diagram



Another type of hierarchy diagram shows referential dependencies.  Unlike functional decomposition, each subordinate box in a reference hierarchy represents something that exists separately from its superior.

Referential hierarchies look much like functional decompositions.  The superior step references (or “calls”) the subordinate step in order to accomplish what the superior is expected to do.  At this point, the superior step is suspended until the subordinate step completes.  When the subordinate step finishes, the superior step continues from where it was suspended.


In programming, this is often called “modular decomposition”.  The entire diagram would show which modules/functions/subroutines are called by others. Step A may call multiple sub-steps.  Step B may be called from multiple super-steps.  The diagram both starts and stops with the top-most step.


Recursion may occur.  Indeed, a step may call itself in order to solve a problem.  This often makes recursion a useful technique for programmers. However, recursion complicates the diagramming, and the techniques for showing recursion in diagramming are not standard.


This diagram shows nesting explicitly.  Additional nesting is usually not exhibited, but would be used possibly to show functional decomposition (previously in this document).



Class diagrams look much like hierarchy diagrams.  In fact, the diagrams are sometimes referred to as “class hierarchies.”  Depending upon your object-orientation, classes are either the “blueprint” for the objects mentioned in the context diagrams, or classes are the encapsulation of the essential similarities between existing objects.  Analysts should always take the latter viewpoint; engineers and programmers should take the former viewpoint.  Designers have to think of them as both.

Inheritance dependencies are sometimes called “is-A” relationships.  The super class A may have multiple subclasses. The number of super classes that a subclass may have is a matter of heated debate.  For analytical purposes, subclasses easily are permitted multiple super classes.  One programming language, C++, permits multiple super classes (“multiple inheritance”) in implementation.  Other object-oriented languages use a “single inheritance” model or restrict the nature of super classes in some way to permit a limited form of multiple inheritance.


Recursion is never permitted in class inheritance hierarchies.  You cannot be your own grandfather.


Nesting of classes within other classes is permitted.


Additional associations may exist between classes to show composition of properties (state variables or “has-A” relationships) within a class.  One use of these associations is to show the channels of communication that exist in context/collaboration diagrams (discussed earlier in the document). Recursion is common within these additional associations.



State diagrams (or “statecharts”) show relatively high-level transitions that result when the system or program is stimulated by outside events.

Program state definition is an art and often seems arbitrary.  The basic notion is that the system is always in one state, and never in more than one state (at any given level).  The system remains in that state until a transition is triggered by an external event.  Transitions take no time to occur.  There is no time in which the system is not in one of the defined states.


The system begins in some initialization state.  The system continues until it enters one (of possibly many) termination states.


Entering a state may cause some processes to be executed.  Exiting a state may cause some processes to be executed.  Some processes may be continually executed while in a specific state.  Some processes may be enabled or disabled while transitioning between states.


Recursion is commonplace in state diagrams.  If recursion didn’t occur, you probably wouldn’t want to use a state diagram anyhow.  A state diagram may even show an event looping back on the same state. There is no change of state in those cases, but the exit and entry processes may be triggered.


States may be “nested.”  A nested state usually indicates a functional decomposition within the “super” state.  The term macro-state is often used for the super state.  The macro-state may be composed of multiple micro-states.


The implementation of state diagrams is often in the form of a finite state machine (or “FSM”).  However, all systems have states, whether they use an FSM or not.   A formal FSM is not implied by the existence of a state diagram.


UML has extended the notion of state charts to a slightly more complicated form called an activity diagram.  In essence, the transition between states is replaced by a control flow diagram (described at the beginning of this document).  An activity is like a combination of program steps and program states.  An activity is very much like a canonical state, except that the activity is capable of self-termination when it is finished doing what it is designed to do.  The system then transitions to the next activity or state.



Use case diagrams show how a system or program interacts with external “entities.”  These diagrams are relatively sparse about the details of how the program behaves internally and of how the external environment is configured.


Because the little stick figure looks a biped primate, some beginners think that actors must be human beings.  However, anything that acts beyond the control of the “system” (whatever the thing is that is being described by the collection of use cases), but interacts with the system is a potential actor.  Actors could be networks, communication devices, other computers, or other programs on the same computer. 


Each actor may be associated with multiple use cases.  Each use case may be associated with multiple actors.  Use cases may also interact with other use cases that may be shared.  Actors may show an inheritance hierarchy. 


Use cases are detailed according to how the system is supposed to interact with the actor, but this detail is usually not show explicitly with the diagram.   The overall use case diagram shows “what” we want our system to do, but should in no way describe how it gets accomplished.  In particular, programmers should be cautioned against thinking of use cases as distinct program modules.




Venn diagrams (“set algebra”) are used in mathematical set theory to demonstrate ways in which the elements of different sets are shared.  In development work, they are primarily an analytical tool.


There are only three different practical cases when we start to compare the options.



A and B are intersecting.  They have some parts in common but each includes parts that are not found in the other.”



A and B are disjoint.  They have no parts in common.”


“B is a proper subset of A.  All the parts of B are found in A.  Some parts of A are not found in B. Shows a hierarchical relationship between A and B.”


Obviously, there is some chance that both A and B are exactly the same.  It could happen.  However, if that were the case, you would not be trying to show that relationship by Venn diagram, even though you could. 

For up to three or four objects, the Venn diagram can be useful in demonstrating how relatively complex objects are related.  Beyond three or four objects, the Venn diagram looses some effectiveness with only a couple of exceptions.  One exception is a complete partition of a superset.  This includes the well-known “pie chart” used in statistical analysis.  The other exception is when a cascaded, nesting situation occurs.  You might call this a “bulls-eye chart” from the appearance, but I haven’t really noticed anyone use that term in the literature.  (One term that has been used for this situation is “onion.”  If multiple centers are shown, the diagrams have been called “garlic cloves.”) Because of the limitation, Venn diagrams tend not be all that useful for complicated diagramming. However, they are often insightful in showing how different things compare and contrast.



So, which is the right diagram to use?  Well, “it depends.”  Each of the diagrams shows a different aspect of some complex system.  Any system of sufficient complexity would be able to be diagrammed by any of the techniques mentioned here. However, no one diagram is going to be useful in all situations.  It’s important to remember that diagrams are documentation.  Documentation is a means of communication between groups of human beings, and needs to be understandable to both senders and receivers (the “audience”).   The documentation should also be useful.  In development situations, the reader of the document is going to be expected to implement the diagram in some fashion.  Often, this necessitates a chain of related diagram styles, each showing a slightly different aspect of the system, until a diagram is produced that tells programmer exactly what he/she needs to do.  There should be more than one kind of diagram, just like there’s more than one kind of document in system development.