Business Process Modeling

Contrasting Data Flow Diagrams (DFD) and Unified Modeling Language (UML)

 

Karanja Kiburi                                                           MIS 488 Systems Analysis

November 11, 2002                                                    Prof. Vicki Sauter   

 

Introduction

Systems Analysis and Design at first glance, doesn’t seem like it should be difficult. All that is required is to sit down with the customer, figure out what they want the system to do. Employ the latest and greatest software languages and tools, some capable of generating code to build the application. Prototype, test and efficiently deploy the new client application. In reality, this is far from the truth for numerous reasons, the greatest being that the systems analyst and the software team fail to have a proper understanding of the business, or the business changes so frequently that the software cannot keep up. With the emergence of e-centric solutions, the need for understanding both technology and the business is magnified and necessary to successfully develop software solutions. The role of Business Modeling in specifying and documenting complex software systems has become more important and is becoming an industrial approach to software engineering.

History

Since the 1960s, systems analysts have faced the task of describing business processes in order to build information systems that improve the performance of the business units in which those processes occur. This is true whether the analyst is designing a system to automate a structured task, such as order entry, or to support a less structured objective, such as business strategy formation. [j] Unlike other types of analysts and consultants, systems analysts do not have the luxury of modeling a process and then walking away; the information systems they design have to function day-in and day-out as a successful process. Due to these factors, systems analysts put considerable effort into developing ways of understanding processes that can translate directly into information system specifications.

These specifications, often demanding detailed descriptions of database structures, records, and fields, are explicit and structured. [c] Part of the systems analysis challenge arises from this mismatch between the knowledge that most organizations have of their internal processes and the kind of knowledge that a computer system needs in order to accomplish useful work. From a systems design point of view, processes are difficult to describe for the following reasons:

  1. Processes tend to be understood differently by each person working within them (ask three different people how "the process works"; get five different answers).
  2. Processes sustain many variations. An order entry process, for example, may work one way for first-time customers, one way for large customers, one way for small customers, one way for former customers. [g,j].
  3. Processes can prove very complex. Again, an order entry process that seems quite simple at one level (e.g., I tell you what I want, you send it to me) proves very complex in large organizations that operate through many functional departments spread across a wide geographical area (e.g., you send a purchase order, which goes to an order entry clerk, who produces an internal purchase order, which goes to Shipping, where a warehouse assistant writes a shipping manifest, which gets sent to Accounting, where it gets matched with both the original and internal purchase orders, etc., etc.). [1,g,j]
  4. An existing business process is not guaranteed to be optimally effective. This is a long-winded way of saying that not everything in every organization works as well as it was intended to (big surprise, right?). This statement of the obvious highlights another, perhaps less obvious point: sooner or later, most managers look to information systems as a tool for fixing problems that exist within current processes. In other words, they look for ways to use systems to redesign processes. Sometimes this is as simple as using a systems development project as an excuse for changing how an organization does its work [1,g,j]. At other times, the system development project itself will suggest specific ways in which to redesign a process.

What is Business process modeling?

A business is a complex system, consisting of hierarchical organization of departments and their functions. Some of these functions spread horizontally across several departments. Business modeling is an abstraction that assists the analyst in understanding the business by modeling the goals, processes, resources (such as people, machines, and material) and rules. [9]

What is the Purpose of Business Modeling?

“The purpose of business modeling is to enable systems to be successfully used in new business processes and new product developments, for solving business problems”. This is a result of all stakeholders understanding both the business and the IT systems. This understanding is demonstrated in the business, IT system, and technological infrastructure specifications. The specifications are modeled traditionally using Data Flow Diagrams (DFD) and more recently using Unified Modeling Language (UML). [8]

 

Data Flow Diagrams

History

From late 1970s early 1980s, systems analysts began to resolve the conflicts between managerial and information-systems design perspectives. This solution described processes by focusing exclusively on the data that each process generated. “This notion suggested that by focusing on data movement and the processing activities that occurred within a business process, one could simplify process descriptions in ways that supported successful information systems”. [4] This idea proved valuable as systems analysis techniques based on this perspective now dominate most systems analysis and software engineering work.

 

Focusing on data enabled systems analysts to extract only the details necessary to the development of the information system from the mounds of detail collected to describe organizational processes. This simplified process view offered insights for potential process redesigns. “This approach analyzes data flows, enables analysis form observations of current practice in an organization to understanding key characteristics of current practice, key characteristics of improved practice, and potential redesigns that could become future practice to support improved business performance”. [4]

What are Data Flow Diagrams?

Data Flow Diagrams (DFDs) are a structured analysis technique that allows an analyst to put together a graphical representation of data processes throughout the organization. DFDs are the traditional process modeling technique and the most used technique for process modeling. The data flow approach emphasizes the logic underlying the system. By using a combination of four symbols, an analyst can create a pictorial depiction of the processes that will eventually provide solid systems documentation. [k]

What are the advantages?

The advantages of the data flow approach over the narrative explanations are:

·         Freedom from committing to the technical implementation of the system too early. The symbols do not specify the physical aspects of implementation.

 

·         Understanding of the interrelatedness of the systems and subsystems communication

 

·         Communicating current system knowledge to users through data flow diagrams.

·         Analysis of a proposed system to determine if the necessary data and processes have been defined.

 

Symbols Used:

Four basic symbols are used to chart data movement on data flow diagrams are:

·         A double square, - used to depict an external entity (another department, a business, a person or a machine) that can send data to receive data from the system.

 

·         An arrow, - shows movement of data from one point to another, with the head of the arrow pointing toward the data’s destination. Data flows occurring simultaneously can be depicted through use of parallel arrows.

 

·         A rectangle with rounded corners, - is used to show the occurrence of a transforming process. Processes always denote a transformation of the data.

 

·         An open-ended rectangle, - represents a data store.

DFD Deliverables and Goals:

The primary deliverables from process modeling are a set of sound interrelated data flow diagrams that result form analyzing and documenting a system or organizations processes. These diagrams should be drawn systematically beginning with the analyst conceptualizing the data flows from a top-down perspective. These deliverables are:

 

1.      Make a list of business activities and use it to determine various [1]

·         External entities

·         Data Flows

·         Processes

·         Data Stores

 

2.      Create a context diagram which shows external entities and data flows to and from the system, without showing any detailed processes or data stores. [1]

 

3.      Draw diagram 0, the next level. Show processes, but keep them general. Show data stores also at this level. [1]

 

4.      Create a child diagram for each of the processes in Diagram 0. [1]

5.      Develop a physical dataflow diagram from the logical data flow. Distinguish between manual and automated processes, describe actual files and reports by name, and add controls to indicate when processes are complete or errors occur. [1]

 

6.      Partition the physical data flow diagram by separating or grouping parts of the diagram in order to facilitate programming and implementation. [1]

 

 

 

 

 

An example:

 

Figure 1: An example of a Data Flow Diagram

 

Unified Modeling Language (UML)

History:

During the 1990s, various techniques for the analysis and design of Object-Oriented systems were developed and used widely throughout the IT industry. Among the most popular is Unified Modeling Language (UML), developed by Grady Booch, Ivar Jacobson, and James Rumbaugh. Each was the primary author of independent Object-Oriented Modeling methods: Booch, the “Booch” Method; Jacobson, the “Object-Oriented Software Engineering” method (OOSE); and Rumbaugh, the “Object Modeling Technique” (OMT). The three men collaborated to unify their methods, resulting in UML. The object management group, an organization founded by the leading organizations in the IT industry, adopted UML as a standard for modeling object-oriented modeling systems in 1997. The standardization further solidified UML as the leader in Object-Oriented analysis and design methods. [8,b]

What is UML?

Unified Modeling Language, a general-purpose notational language for specifying and visualizing complex software, especially large object-oriented (O-O) projects. UML provides a standardized set of tools to document the analysis and design of a software system. The UML toolset includes diagrams that allow people to visualize the construction of an O-O system, similar to the way blue prints allow people to visualize the construction of a building. Whether the systems analyst is working by himself or as part of a large development effort, the documentation that is created with UML provides an effective means of communication between the development team and the businesspersons on a project. Attempts at defining standards for UML development processes, such as the Rational Unified Process [7] or Select Perspective [2], are often configurable. This allows UML to be adapted or modified to suit the project at hand. UML does not prescribe a specific way of how it should be used in a project; there is no specific or correct way of using it.

What are the Advantages?

Since its standardization by the Object Management group (OMG) in November 1997, the unified modeling language UML has had tremendous impact on how software systems are developed. The role of modeling in specifying and documenting complex software systems is being accepted, and an industrial approach to software engineering is on its way to becoming a reality. With the acceptance of UML, a new generation of tools and processes that use UML have emerged, and important concepts and techniques such as role of architecture, requirements engineering, and tool integration also have been emphasized.

The UML enables the capturing, communicating, and leveraging of knowledge: models capture knowledge (semantics), architectural views organize knowledge in accordance with guidelines expressing idioms of usage, and diagrams depict knowledge (syntax) for communication. This process is very natural and often occurs subtly and sometimes unconsciously in problem solving. [8]

The Symbols

Several development processes that use UML advocate that the system development should start with Use-case Modeling to define the functional requirements of the system. A Use-case describes a specific usage of the system by one or more actors. An actor is a role that a user or another system plays. [4] The objective of use–case modeling is to identify and describe all the use-cases that the actors require form the system. The use-case descriptions are used to analyze and design a robust system architecture that realizes the use cases. This is referred to as “use case driven development”. [7]

 

“How does a systems analyst know when all of the use cases or the correct use cases that best support the business have been identified”? The analyst should model and understand the systems surroundings. Modeling the business surrounding involves answering questions such as:

 

Answers to these questions come from tackling the entire business and looking beyond the function of the information system currently being built. This may involve using techniques other than use-case modeling. [7]

So, what is Use Case Modeling?

Use cases, are a simple and powerful way to express the functional requirements, or behaviors, of a system. They allow description of sequences of events that taken together lead to a system doing something useful. [10] When confronted with a pile of requirements it’s often impossible to make sense of what the authors of the requirements really wanted the system to do. Uses cases reduce the ambiguity of the requirements by specifying exactly when and under what conditions certain behaviors occurs; such as, the sequence of the behaviors can be regarded as a requirement. Use cases are particularly well suited to capture these kinds of requirement although this may sound simple, the fact is that conventional ways of capturing requirements with emphasis on declarative statements, completely fail to capture the dynamics of the systems behavior. Use cases are simple yet powerful way to express the behavior of the system in a way that all stakeholders can easily understand. [5]

The UML Deliverables and Goals:

There are two main types of diagrams in UML: structure diagrams and behavior diagrams. Structural diagrams are used to describe the relationship between classes. They include class diagrams, object diagrams, component diagrams, and development diagrams. Behavioral diagrams can be used to describe the interaction between people (actors) and the use-case. Behavioral diagrams include use-case diagrams, sequence diagrams, collaboration diagrams, state-chart diagrams and activity diagrams. The deliverables are outlined in Table 1 below.

 

Table1: An overall view of UML and its components: Things relationships, and diagrams [8]

UML Category

UML Features

Specific UML Details

Things

Structural things

Classes

 

 

Interfaces

 

 

Collaborations

 

 

Use Cases

 

 

Active Classes

 

 

Components

 

 

Nodes

 

Behavioral Things

Interactions

 

 

State Machines

 

Grouping Things

Packages

 

Annotational Things

Notes

Relationships

Structural relationships

Dependencies

 

 

Aggregations

 

 

Associations

 

 

Generalizations

 

Behavioral Relationships

Communicates

 

 

Includes

 

 

Extends

 

 

Generalizations

Diagrams

Structural diagrams

Class Diagrams

 

 

Object Diagrams

 

 

Component Diagrams

 

 

Deployment Diagrams

 

Behavioral Diagrams

Use Case Diagrams

 

 

Sequence Diagrams

 

 

Collaboration Diagrams

 

 

Statechart Diagrams

 

 

Activity Diagrams

 

The goals of UML are:

 

 

Example:

Figure 2: An example of a UML Use Case Diagram [b]

UML Use Case Diagram

Contrast

Data Flow Diagramming and Unified Modeling Language/Use Cases are tools that are neutral with respect to a methodology, technology, or tool-set. Both concepts make the following possible;

·         Provide clarity and understanding for all stakeholders who could use the same explicitly defined framework for strategy and contracts.

 

·         Abstraction essential for business and technology leaders, including the Board level, to tame complexity.

 

·         Provide traceability between maintainability of specifications instead of relying on tacit knowledge of gurus.

 

·         Define explicitly the relationships between software artifacts visible to the business and the appropriate fragments of business specifications.

 

 

In contrast, earlier analysis methods were focused on process or data resulting in Data Flow Diagrams, and Entity Relationship Diagrams (ERD). Today, Object oriented (OO) methods blend data and process into objects, and focus on how those objects interact using methods (passing messages).

The old ways

The new way

•Process Oriented Methodology

•Object Oriented Methodology

–Invented in the 1960’s

–Encapsulates data and processes to allow large system

–Focuses on using DFD

  development (millions lines of code)

–Weak for projects over 50k Lines of code

–Getting standardized (UML, CORBA)

–Subject to frequent change  (every time a process

–Slow to be adopted by industry, mostly due to inertia 

  is tweaked, the DFD changes)

  of data and process methods (large installed base)

•Data Oriented Methodology

 

–Introduced in 1976, and primary method,

 

  used from the 1980's to today

 

–Focuses on using the ERD

 

–Doesn’t change as often as the DFD

 

–Shows business rules through cardinality (0, 1, ¥)

 

–Works for systems up to about ½ million lines of code

 

 

When to use Business Modeling:

Business modeling is not appropriate for every software engineering effort. Business models add most value when the application environment is complex and multidimensional, and when many people are directly involved in using the system. For example, if an analyst was building and additional feature to an existing system, in most cases you would not consider business modeling.

Conclusion

DFDs, UML, and Uses Cases are simply various methods or tools used by systems analysts to collect information necessary to determine information systems requirements. Although the modeling of processes for information systems development is over 20 years old, dating back to the beginnings of the philosophy of structured analysis and design, its is just as important for internet applications as it is for more traditional systems.

 

 

 

Bibliography

1.      Hoffer, J. A., George, J. F., Valacich, J. S., "Modern Systems Analysis and Design", 3rd edition, Prentice Hall, 2002

 

2.      Cantor, Murray R. “Object-Oriented Project Management with UML”. John Wiley & Sons, Inc., 1998.

 

3.      Colter, M. “Comparative Examination of Systems Analysis Techniques” MIS Quarterly, Vol. 8, No. 1, June 1984, pp. 51-66

 

4.      Gane, C., T. Sarson. “Structure Systems Analysis and Design Tools and Techniques.” Prentice Hall, 1979

 

5.      Martin, J. “Strategic Data-Planning Methodologies.” Prentice Hall, 1982.

6.      Senn, J.A. “Analysis and Design of Information Systems.” McGraw-Hill, 1984

 

7.      Kruchten, P. “The Rational Unified Process.” Addison-Wesley, 1998

 

8.      Booch, Grady, Ivar Jacobson, and James Rumbaugh. “The Unified Modeling Language Users Guide.” Addison-Wesley, 1998

 

9.      Checkland P.B. “Systems Thinking, Systems, Practice.” John Wiley & Sons, Inc., 1981.

 

10.  Alan M. Davis, “Software Requirements: Objects, Functions, and State.” 1993 Prentice Hall

 

Web resources

 

a)     http://www.techrepublic.com/

 

b)     http://www.rational.com/uml/resources/documentation/index.jsp

 

c)     http://www.umsl.edu/~sauter/analysis/msis488start.html

 

d)     http://www.amis.cba.bgsu.edu/courses/eckb/development/Methodology/methodology

 

e)     http://www.omg.org/uml/

 

f)       http://www.bredemeyer.com/use_cases.htm

 

g)     http://www.smartdraw.com/resources/centers/software/dfd.htm

 

h)     http://www.pols.co.uk/usecasezone/UseCaseConcepts.html

 

i)        http://www.softdocwiz.com/UML.htm

 

j)       http://www.gos.udel.edu/ios/G3OS_data_flows.htm

 

k)      spot.colorado.edu/~kozar/DFD.html

 

l)        http://www.webopedia.com/

 

 

 

 

 

1