Just like a written or spoken language, data flow diagrams have their own syntax, and just like a written or spoken language, we can make mistakes that lead to errors of clarity or essentially an ambiguity in what we're trying to communicate. In this lesson, we'll take a look at some of the rules for drawing data flow diagrams to make them as clear as possible, and we'll also take a look at the different types of data flow diagrams. If you've seen a data flow diagram before, you might be looking at some of the examples that are on the screen thinking, "Hey Ken, that's not a data flow diagram," because something you've seen is different than what you've seen before. That's because there are different types of data flow diagrams, and we'll look at the different types. After this video, you'll be able to identify errors in a data flow diagram, as well as name the notation used to draw a particular diagram. Finally, you'll be able to list and describe the different types of data flow diagrams and where they might be useful. Let's start by taking a look at some of the rules for our data flow diagrams. We see that every process has a unique name that is an action-oriented verb phrase. So, it usually starts with a verb. Also, every process has to have at least one input and at least one output. If a process does not have any data flowing into it, then it's something we might call a miracle because it creates information. On the other hand, if a process only has data flowing into it with no data flowing out, then we call that process a black hole for reasons that should be obvious. I'm going to put on the screen a sample data flow diagram. I ask you to take a minute while the video pauses, and look at the data flow diagram, see if you can identify a black hole, a miracle, and also study the diagram carefully for anything else that might look suspicious. Let's take a look at where these examples occur in this particular diagram. If we look carefully here at process 3.1.2, create a new bank account, you can see that there are three data flows coming in, but no data flows going out. This is our black hole. If we look just below that, down here at process 3.1.3, you can see, freeze member account number has information coming out of it, but no information coming in. This is something that we would call a miracle. If we look far on the right of the diagram, over at process 3.1.1, it says generate an employee bank statement. Well, this isn't necessarily a miracle or a black hole because it has data flowing in and data flowing out. It does look suspicious because can we really generate an employee bank statement with only the address as input? This is what I would call a semantic error. Instead, in other words, it's an error in the meaning of the diagram, and it might lead to a lack of clarity down the road. Identifying syntax errors, like black holes and miracles, is often easy because you don't need any familiarity with the domain of the system. On the other hand, identifying semantic errors, like this one, is much harder and usually requires reviewing the diagram with your business subject matter expert. I remember when I started my career, I worked for a company named Cargill in their grain division. My background is computer science. So, I knew very little about grain trade. I had to rely on the grain traders to tell me whether or not something made sense, and this is the kind of thing you want to run by your customer to see if it makes sense. Let's take a look at a few more guidelines and rules for our data flow diagrams. Again, the goal of all of these is not to be legalistic, but it's for clarity purposes. Every process should have or every data flow has a unique name that is a noun and a description that goes along with that. A data flow should connect to at least one process. That basically means that we shouldn't have any data flowing between our external entities in the diagram, and we shouldn't have any data flowing between data stores. All data should flow into or out of a particular process. Then, data flows only in one direction. This means that you shouldn't have any two-headed arrows. If we do have a situation where data flows from one process to another in both directions, then we should have two arrows in the diagram, one going one way, one going the other way, and properly labeled. The rest of what you see on the screen here are all good ideas to help improve the clarity of your diagrams. But in most cases, you'll find that in real-world situations, you often need to violate them in order to most closely approximate the process that you're modeling. This is a data flow diagram, and it probably looks different than what we've been showing so far. What you're seeing here is a data flow diagram in a different notation. This is what's called DeMarco/Yourdon notation. If you remember, when we introduced data flow diagrams, we talked about two major different types of notation, and I am just giving you this as an example of the other notation. You might come across this in industry and I wanted you to be exposed to it so that you'd be able to identify what it is. For the most part, the meaning in the semantics is the same. The shapes are just slightly different. Let's finish up by talking about four different types of data flow diagrams. As I mentioned, if you've seen the data flow diagram before taking this course or watching this video, it might have looked different than what we're showing on the screen. That's because we use different types of data flow diagrams for different situations. Sometimes, we use a data flow diagram to document our as-is process. In fact, most analysis starts by understanding how things are currently done. You'd be surprised to how little understanding there is some times of the current process, and sometimes, even the process of analyzing the current procedures will lead to new insights. So, we often start by drawing a data flow diagram that represents the current process. This is an example here of a simple inventory system that has interactions with the supplier, inventory reports, and stock on hand. We can also draw data flow diagrams to represent what we call our to-be process. So, for example, we might draw data flow diagram like you see on the screen that represents the process as we wish it to be. So, we have an as-is data flow diagram, as well as a to-be data flow diagram. After that, we get into logical and physical data flow diagrams. I often start by making a logical data flow diagram. This focuses on the what but not the how. A physical data flow diagram, on the other hand, adds in detail as to how particular tasks are performed or how data is stored. So, what you see here is an example of a physical and a logical data flow diagram approximating the same process. What you have on the right side of the screen is a logical data flow diagram. You'll notice that it does not make any reference to specific physical implementations of some of the processes and the data stores. On the other hand, on the left-hand side of your screen, on the upper-left, what you see here is a physical data flow diagram. This diagram often has specific names as you can see here, as well as specific locations where we might store particular information. The best approach is usually to start by drawing a physical as-is data flow diagram. This is nice and concrete. So, you talk about who does the current process, where things are currently stored, and so on. You then take that through a process of refinement to get to a logical DFD that represents the current process. You can then transform that logical DFD into a logical DFD that represents the to-be process. Then, in your final step, you can take the logical to-be DFD and translate it into a physical to-be DFD that describes the new system as you wish it would be.
