The primary purpose of everything we do in analysis phase is communication. Just like the English language has grammar, there is a special syntax for preparing our data flow diagrams, so that other people can understand them in an unambiguous manner. In this video, we'll start to dig into this syntax a little bit so you can prepare data flow diagrams that make sense to system designers. After this video, you'll be able to describe the purpose of higher level data flow diagrams as well as evaluate whether a data flow diagram is balanced. Finally, we'll teach you how to decompose a data flow or a system into processes. Let's start by taking a look at how we provide additional detail in our data flow diagrams. On the left, what you see here is a context diagram as we introduced in a previous video. This context diagram can then be decomposed into what's called a level zero data flow diagram. The context diagram shows the overall system with it's relationship to the external entities. The level zero data flow diagram shows the major processes that make up the system. As I mentioned, there are specific rules for coming up with these processes as well as specific rules for drawing all of the lines that you see here. Let's take a look at those. We start perhaps the easiest step which is to take the external entities from our context diagram and effectively replicate them on our level zero data flow diagram. That part is fairly easy. Next, we take the system from our context diagram and we decompose that into a set of constituent processes. These are called the level zero processes. They are essentially the highest level processes that you can think of in the system. So here, in our example, we have the tune source digital music downloads system, we decompose that into three level zero processes, search and browse our tunes, purchase tunes, and promote our tunes which might be done by our marketing managers. Now again, this is an overly simplistic example but it gives you the idea. How do we figure out what our level zero processes should be? Well, ideally we've already prepared some use cases and we have a use case diagram. So, let's go to that. We can see that the level zero processes in our DFD roughly correspond to the use cases from our use case diagram. Now, this isn't a hard and fast rule but if you don't know where to start, this is a good place to start. You go the use case diagram, pull the use cases, make those your level zero processes, and at least it gives you a starting point. Finally in our diagram, we want to make sure we're in our level zero diagram, we include new and additional information. In particular, we include these data stores. You see them here labeled with things like D one, D two, and so on. Each of this is a place where we store some data. We'll talk in a bit about the difference between physical and logical data flow diagrams, but for the purposes of this step, it's important that the data stores represent the what, and not necessarily the how. So, these data stores might end up being databases on a computer, or they might be like a set of files in a filing cabinet, or as simple as a stack of papers on your desk. But we add in the data stores do not appear in the context diagram, however, they do appear here on the level zero data flow diagram. One last concept and this is perhaps the most difficult concept to understand but the most important when it comes to making sure that your DFD is actually add clarity to the system, is that the different levels of data flow diagram needs to be balanced. What we've done here is we've decomposed the level zero DFD, into a level one DFD. So, we've taken our search and browse tunes process and we've decomposed that further still into something called a level one DFD that you see on the right of your screen. In the level one DFD, we've labeled our processes with numbers like 1.1, 1.2, and so on to show that these are effectively decompositions of the process on the higher level diagrams. It's important that these be balanced and what we mean by that is that, every data flow in or out of this process on the level zero DFD needs to be accounted for on the level one DFD and so on down the line. So, in this case, we've got the relevant data stores and notice we only include data stores that interact with process one, on the level zero DFD. Then from there, we checked to make sure that all of the various arrows that go into or out of the process are accounted for, in the level one DFD. I encourage you to take a minute, study the diagram, and try to convince yourself whether or not this is the case. You might be curious about the web promotions data flow that you see in the upper right. We can see in the level zero DFD on the left, that web promotions goes in, as well as time to buy comes out on the bottom. It might be hard to find these in the level one DFD on the right, but you can see that they're both accounted for and they're both going or coming from or going to their proper respective data stores. Balancing, while it might seem like a tedious task, helps ensure that there are no inconsistencies in our data flow diagram that might lead to confusion when we get to time to implement our system
