The diagrams described in this document are Control Flow diagrams (Flowcharts), Data Flow Diagram, Use Case Diagram, Entity-Relationship Diagram, and State-Transition Diagram. Activities in each diagram are mentioned briefly. Most of these diagrams have several steps/processes/objects. After explain you briefly details in each diagram, I then compare the diagrams in term of the purpose of each diagram in the system analysis. Finally, I then summarized the briefly details of diagrams and how system analysts or users applied it into the analysis of real system.
Flowchart is the schematic representation of a process. It is the earliest and best known diagramming tools. It is also known as Control flow diagram. Flowchart allows users to graphically view the process and also helps them including audiences easily understand the content and easily find flaws in the process. It breaks a process down to a finite number of steps that get executed one at a time. Thus, if the flowcharts accurately describe the content carried out within them in the diagram, they can be used for analysis. It actually does not say anything about what the inputs and outputs of each step are. It does not address how each step performs internally. Flowchart can be used by systems analysts in order to document process specifications.
Flowcharts will be the useful diagramming tools for the system analysis activity when it is concerned with the user implementation. The users, the system analysts and the implementation team can discuss those implementation constraints that must be imposed upon the system. They, for example, can determine the boundary of the system and the details of the interaction between the systems and the users.
However, there are several reasons that most system analysts actually do not use detailed flowcharts for process specifications.
Flowcharts are composed of many symbols but the common flowcharts are composed of three basic symbols: Arrows, Diamonds and Rectangles.
Flowcharts may also contain other symbols such as page connectors when your diagram is too big to fit in one page, input/output which is represented by parallelogram and etc.
Unlike Data Flow Diagrams which are used to describe data flow within the system, flow charts are typically used to describe the detailed logic of a business process or business rule.
Figure 1: The example of the Flow Chart.
Data flow diagram is a graphical representation of the flow of data through an information system. It is one of the most commonly used systems-modeling tools, particularly in the operational system in which functions of the system are the most important and more complex than the data that the system manipulates. Rather than showing the strict order of execution of steps, it shows how processes depend on one another for information. It shows data flow from external into the system and shows how the data moved from one process to another process. Data flow diagrams are one of the three essential perspectives of Structured Systems Analysis and Design Method (SSADM).
System analysts use it as a tool for modeling and analyzing the processes in the system. It helps analysts to visualize the data processes since data enter to the system, and then they are used by the system until they are returned to the environment. Analysts also use DFDs to study alternative information handling procedures during the process of designing new information services. In addition, Data Flow Diagrams can be used for compared the new system and the old system. With this comparison, system analysts can find the gap between two systems and the effectiveness of the improved system.
Although Data Flow Diagram is one of the power tools for analyzing the systems, the system analysts must keep in mind that it provides only one view of the system. It focuses mainly on the function-oriented view. So, if the systems are more concerned with data relationships than the functions, Data Flow Diagram will be less important. Instead, system analysts must concentrate mainly on developing the Entity-Relationship Diagrams. Alternatively, the State-Transition Diagrams will be the most importance if the time-dependent behavior of the system dominated all other issues.
A data flow diagram illustrates the processes, data stores, and external entities in a business or other system and the connecting data flows. There are only four symbols for a data flow diagram: Squares or Ovals, Circle or Rounded Rectangles, Arrows, and Open-ended Rectangles.
Nonetheless, the data flow diagram doesn’t answer a lot of procedural questions that you might have when looking at the DFD. All the questions related to procedural details are normally modeled within Flowcharts or other procedural modeling tools. Some examples of the procedural questions are what the criteria for moving data from one process to another process and what the order in which the processes are performed.
Furthermore, there are several common modeling rules that you need to follow when creating Data Flow Diagrams.
In the real projects, data flow diagrams are considerably large and complex. So we need to avoid drawing the whole system in only one diagram. System analysts organize the overall DFD in a series of levels so that each level provides successively more detail about a portion of the level above it. The top-level DFD is called a context diagram which represents the system as a single process. It consists of only one circle representing the entire system, the data flows showing the interaction between the system and the external terminators. There is no data stores appear on a context diagram because the data stores of the systems are conceptually inside the one process. The context diagrams are useful for showing how a proposed system may behave for a specific example or scenario. The next level DFD are called Level-0 DFD, Level-1 DFD, and so on. Level-0 diagram is the decomposition of the one process from the context diagram into two to nine high-level processes. Then, each process in the Level-0 diagram can be decomposed into the next level.
In order to properly create many levels of data flow diagram, you must understand two concepts: decomposition and balancing.
Figure 2: The example of the Data Flow Diagram.
In the Unified Modeling Language (UML), a use case diagram is a sub class of behavioral diagrams. Use Case Diagram is one of the Object Oriented Diagrams. It shows how a system interacts with the external entities. So, it is relatively sparse about the details of how the system behaves internally and how the external environment is configured. Indeed, Use Case Diagram shows what we want the system to do rather than describe how it can be accomplished. One of the major benefits of this diagram is communication.
There are four major symbols in the Use Case Diagrams: Use cases, Actors, and Associations and System boundary.
ˇ Use Cases describe a sequence of actions. Those actions must provide the measurable value to an actor. It is represented by horizontal ellipse.
ˇ Actors are a person, group of people, organization, or external system the plays a role in one or more interactions with your system. Furthermore, it can be networks, communication devices, computers, or other programs on the same computer. It is represented by stick figure.
ˇ Associations or Communications indicate the interaction described by a use case. It is represented by lines connecting between use cases and actors with an optional arrowhead on one end of the line. Notice that the arrowheads in Use Case diagram is used for indicating the direction of the initial invocation of the relationship or to indicate the primary actor, while the arrowheads of Data Flow Diagram is used for showing the flow of data in the system.
ˇ System boundary is the rectangle around the use cases. Anything within this boundary is the functionality in scope of the system.
System analysts and designers must remember that interaction among actors is not shown in the Use Case Diagrams. Thus, the system boundary should reexamine if the interaction between actors is essential to a coherent description of the desired behavior. Furthermore, Actors are formed based on the role we set. So, the different actors may actually be the same person.
There are three major types of Use Case Relationships: Include Extend, and Generalization or Inheritance.
Figure 3: The example of the Use Case Diagram.
Entity-Relationship Diagrams is a network model that describes the stored data layout of a system at a high level of abstraction. For the system analyst, the benefit of using Entity-Relationship Diagram is that it concentrates on the relationships between data stores on the Data Flow Diagram that can be seen only in the process specification. Since Data Flow Diagram mainly focuses on the function that the system perform not the data that the system need, using Entity-Relationship Diagram is important to capture another part of system analysis which concentrates mainly on the data in the system.
There are four major components of an Entity-Relationship Diagram: Objects or Entities, Relationships, Associative object type indicators, and Supertype/Subtype indicators.
ˇ Entities represent set of objects in the real world. Entities are represented by rectangles. It has three main characteristics. First, each entity can be identified uniquely in some way. Student, for example, must be able to distinguish from one another by student identities, or name because if students are the same, then Student is meaningless in Entity-Relationship Diagram. Second, each entity must play a necessary role in the system. In other words, objects which have no role in the system can not put into the system. Third, each entity can be described by one or more data elements. For instance, Textbook can be described by one attribute or one data element, ISBN. Also, it can be described by combined attributes (Title, Author, Published Date, and Edition).
ˇ Relationships represent set of connections between entities. It captures how two or more entities are related to one another. Diamond symbols are used for identify relationships. We must keep in mind that the relationship represents something that must not be calculated or derived mechanically by the system. Also, more than one relationship can occur between objects.
ˇ Associative object type indicator represents something that functions both as an object and a relationship.
ˇ Subtype/Supertype indicators represent objects and one or more subcategories connected by a relationship. For example, Student can be connected with Part-time Student and Full-time Student via unnamed relationship. So in this case, Student is Supertype and Part-time Student and Full-time Student are subtypes. Also, all data elements in supertype can be applied to subtypes and subtype have additional data elements to identify themselves.
Figure 4: The example of the Entity-Relationship Diagram.
State-Transition Diagram (STD) is the graphical representation of the system that created for dealing with the time-dependent behavior of a system. Examples for the time-dependent systems are process control, telephone switching systems, high-speed data acquisition systems, and military command and control systems. However, if the system is dealing with inputs from many terminals or high-speed inputs from other systems, then it may have the same kind of time-dependent issues. So, system analysts must be familiar with this modeling tool.
There are two major components for this diagram: States, Changes of State, and Conditions and Actions.
ˇ System States are represented by rectangles. States are the sets of circumstances or attributes characterizing a person or thing at a given time. Keep in mind that States are something in the system that waiting for something from external environment to occur or waiting for a current activity in the environment to change to some other activity.
ˇ Changes of State is shown by the arrows. It represents the change from one state to another by connecting the relevant pair of states. Note that a system can have only one initial state but can have multiple final states.
ˇ Conditions and Actions are shown next to the arrow connecting two related states. Condition explains the cause of changing the state and Action explain what the system takes when it changes state. Remember that condition is some event in the external environment that the system is capable of detecting, not the change in the system.
Each diagramming tool is aimed at a different portion of the analytical process. Flow Charts are useful tools when system analysts or users want to represent either the processing or decision logic flows within the particular process, with its associated inputs and outputs, or the flows of an entire system, with all the various types of processing, preparation, inputs, outputs, data storage media, and other hardware which are associated with it. Unlike Flow Charts, Data Flow Diagram does not show the strict order of execution steps but it shows how processes depend upon one another for information. Data Flow Diagram focuses mainly on the functions performed by a system. One of the major benefits of a Use Case Diagram is communication. By looking at the Use Cases, they know what functionality will be included in the system. Unlike Data Flow Diagram, Entity-Relationship focuses entirely on the data relationships, without providing any information about the functions that create or use the data. State-Transition Diagram focuses mainly on the time-dependent behavior of a system.
Each of these diagrams focuses on critical aspect of the system we are modeling. It means that the person reading the model is also focusing on one critical aspect. So, we should make sure that we are drawing the diagram that is focused on that critical aspect. That is, Data Flow Diagram focuses the reader’s attention on the functions in the system. Entity-Relationship focuses on the data relationships and State-Transition Diagram focuses on the timing characteristics of the system.
Control flow diagrams or Flowchart are the schematic representation of a process. They break a process down to a finite number of steps that get executed one at a time. It does not focus on what the inputs and outputs are and also does not address why we perform those process on each step. It just tells us about when the decision is required in the system and what process step will be executed next based on those decisions. Data Flow Diagram is a graphic representation of a system. It consists of data flows, processes, sources, destinations and stores. Unlike Flow Charts, Data Flow Diagram does not show the strict order of execution steps but it shows how processes depend upon one another for information. Use Case Diagram shows you some of the use cases in your system, some of the actors in your system, and the relationships between them. It shows what we want our system to do, but it does not explain the way how those requirements can be accomplished. Entity-Relationship Diagrams is a network model that describes the stored data layout of a system at a high level of abstraction.  Unlike Data Flow Diagram, it highlights relationships between data stores on the Data Flow Diagram that can be seen only in the process specification. The state-transition diagram is a powerful modeling tool for describing the required behavior of real-time system.
Each diagram shows a different aspect of some complex system. Any system of sufficient complexity can be derived from different diagrams. System Analyst must realize that to successfully analysis the systems, they need to understand the main information they got from each diagramming tool. One diagramming tool may not enough for analyzing the system and they may require using multiple diagrams. Also, it is important to remember that diagrams are documentations. It is a means of communication between groups of human beings and needs to be understandable to both senders and receivers.
What diagrams need to be develop depend on the kind of system you are developing. For example, if the system you are analyzing has complex functions but relatively trivial data structures, Data Flow Diagram will be the best tool. However, in many cases of the real systems, they are required that system analysts must be dealing with more than one diagramming tools.
 Ed Yourdon – Just Enough Structured Analysis – Chapter15, http://www.yourdon.com/strucanalysis/chapters/ch15.html, Last accessed November 15, 2006.
 Introduction to Flow Charts, http://www.agilemodeling.com/artifacts/flowChart.htm, Last updated April 03, 2006.
 Ed Yourdon – Just Enough Structured Analysis – Chapter 9, http://www.yourdon.com/strucanalysis/chapters/ch9.html, Last accessed November 15, 2006.
 Introduction to Data Flow Diagram, http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm, Last updated April 03, 2006.
 Introduction to UML 2 Use Case Diagram, http://www.agilemodeling.com/artifacts/useCaseDiagram.htm, Last updated April 03, 2006.
 Ed Yourdon – Just Enough Structured Analysis – Chapter 12, http://www.yourdon.com/strucanalysis/chapters/ch12.html, Last accessed November 16, 2006.
 Entity-relationship model, http://en.wikipedia.org/wiki/Entity-relationship_model, Last modified November 10, 2006.
 Ed Yourdon – Just Enough Structured Analysis – Chapter 13, http://www.yourdon.com/strucanalysis/chapters/ch13.html, Last accessed November 16, 2006.
 Use case Vs. Dataflow diagrams, http://www.laynetworks.com/use%20case%20vs.%20dataflow%20diagram.htm, Last accessed November 16, 2006.
 Flow Charts, http://deming.eng.clemson.edu/pub/tutorials/qctools/flowm.htm, Last accessed November 20, 2006.
 Data Flow Diagram, http://jin.wa.gov/standards/justiceCommonArchitecture/data.htm, Last accessed November 20, 2006.
 ConceptDraw WebWave Samples: Web-Site Structure Design, http://www.conceptdraw.com/products/img/ScreenShots/cd5/uml/UML_Use-case-diagram.gif, Last accessed November 22, 2006.
 Entity-relationship Diagram, http://searchcrm.techtarget.com/sDefinition/0,290660,sid11_gci333128,00.html, Last accessed November 22, 2006.
 The State Transition Diagram, http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/node10.html, Last accessed November 22, 2006.
 Modern Systems Analysis and Design,
 Flow Chart, First Edition, John Ashbery, ISBN: 0679402012.
 Structured analysis and system specification, Tom DeMarco, ISBN: 0138543801
 Fundamentals of Database Systems,
 Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
 Learning SQL, First Edition, Alan Beaulieu, ISBN: 0596007272.
 The unified modeling language, Jean Bézivin, Pierre-Alain Muller, ISBN: 3540662529
 Modern structured analysis, Edward Yourdon, ISBN: 0135986249
 Use Case Modeling - Page 28, Kurt Bittner, and Ian Spence, ISBN 0201709139
 Technical Data Requirements for Systems Engineering and Support, Thomas F. Walton, ISBN: 0138968780
 Analyzing Business Information Systems: An Object-Oriented Approach, Shouhong Wang, ISBN: 0849392403