Business process modeling, or process modeling, is the analytical representation of an organization’s business processes. Successful software development requires planning, analysis, development, implementation and control. In order to turn user requirements into a useful project, businesses have to do process modeling to understand the process flow. In this blog post, we explain how to do process modeling with DFD and ER diagrams.
IT professionals can use different types of diagrams to represent business processes, rules, entities, and organizational units. Today, we’ll take a look at two of them:
- Data Flow Diagrams (DFD)
- Entity Relationship Diagrams (ER)
Both of these tools are a part of process modeling. But, the main difference between them is the type of process modeling they represent.
DFDs are a logical process modeling tool. They describe processes focusing on the flow of information: where data comes from and where it goes. Overall, the logical model represents business processes, not data flow, as we’ll explain below.
ER diagrams are a physical process modeling tool. They represent how systems create and use data. Physical modeling involves the actual design of a database. In short, physical modeling shows how the database model supports the business model.
1. Process modeling with Data Flow Diagrams (DFD)
DFDs describe processes. Their focus is on processes and activities, not on the data. You can use DFD diagrams to analyze an existing system, or model a new one. You should create your DFD diagram, starting from top to bottom, left to right, because that’s how people read them. And to make the process even simpler, you can use some software application like Microsoft Visio, or Visual Paradigm.
DFD Layers & Levels
You should create DFD diagrams on many levels. First, create the context diagrams and then create the other DFD levels. We’ll explain them below.
A context diagram is a top level (also known as “Level 0”) of the data flow diagram. It is an overview of the entire system. Thus, the context diagram contains only one process node (“Process 0”) that describes the general function of the entire system in relationship to external entities. You should draw the context diagram first. Afterwards, continue to the next levels.
Next, divide the overall DFD into many layers with a more detailed view of the data flow diagram. We recommend you to have not more than 3 layers of DFDs. First, represent the overall systems. At the end, make sure that the last layer of your diagram shows all processes at their atomic form.
DFD Levels. The first level DFD shows the main processes within the system. You can break each of these processes into more atomic ones. The graphical depiction actually identifies each source of data. Also, it shows how data sources interact with each other, to reach a common output.
Elements & symbols
- External Entity
An external entity can represent a human, system or subsystem. The external entity is the element where certain data comes from and where it goes tо. It usually stands at the edge of the diagram. You represent external entities with rectangles.
A process is a business activity or function where data is transformed. Therefore, process activities can be manual or computerized. They have at least one input and one output of data.
- Data Store
A data store represents the storage of persistent data required or produces in the process. You represent data stores with an open ended rectangle. Additionally, data stores should contain an identification number and a short description.
- Data Flow
A data flow shows the flow of information. Accordingly, you represent data flows with an arrow that shows the direction.
DFD rules & tips
- Each process should have at least one input and output.
- Each data store should have at least one data flow in and one data flow out.
- Data stored in a system must go through a process.
- All processes in a DFD go to another process or a data store.
- Data stored in a system must go through a process.
2. Process modeling with Entity Relationship Diagrams (ER)
An Entity Relationship Diagram is a flowchart that illustrates how entities (people, objects or concepts) relate to each other within a system. Hence, it increases the understanding of the entire software. Therefore, ER diagrams are especially valuable in relational databases. Read more about relational databases here.
ER shows how the system stores the data in the database. You should use ER diagrams during the design stage of the software development process. Also, they are a useful tool that shows how different system elements interrelate with each other.
Elements & Symbols
- Entities – An entity is a person, object, or a concept. You represent an entity with a rectangle.
- Relationships – They show how entities relate to one another. You represent relationships with diamonds. There are three types of relationships between entities:
- One-to-one – there is just one association (1:1);
- One-to-many – association are not limited to single entities (1:M);
- Many-to-many – many entities are related to many associations (M:N).
We can also differentiate between total and partial participation. In total participation, each entity is involved in the relationship. You represent total participation with double lines.
Partial participation happens when not all entities are involved in the relationship. You represent total participation with single lines. Here are all the relationships combinations in ER and their representation with symbols:
- Attributes– Within each entity, there can be one, or more than one attribute. They provide detailed information about the concept. To represent attributes in an ER diagram, use the ovals.
Business analysts use ER diagrams to model and design relational databases in business processes. ER diagram is often an initial step in determining requirements for an information systems project. To read about ER notation in details, click here.