A picture is worth a thousand words. In this module, we returned to analysis phase, but this time instead of looking at documentation, we're looking at diagrams or pictures. Sometimes diagrams are the best way to convey or communicate information about what our system is supposed to do. In this video specifically, we'll start with a type of diagram called a data flow diagram and after this video, you'll be able to describe the purpose of a data flow diagram, as well as list the components of these diagrams. Finally, we'll compare these diagrams to use case diagrams, which we looked at earlier. But first, let's take a look at where we are. This is the systems development life cycle that we presented at the beginning of the course. As I mentioned, as a systems analyst, we're going to do most of our work in the analyze phase. We're still going to be in analysis phase or analyzed phase as we look at the different types of diagrams that we might draw to help describe what our system might do. In future modules, we'll take a look at the design and implementation phase. Specifically in this module, we'll be looking at the different types of diagrams that you can draw in order to communicate the requirements of the system. We've already looked at diagrams or excuse me, documentation that we produced during the plan phase. We've also looked at the kinds of documentation we produce in analysis phase. Specifically, we focused on requirements, test cases, and use cases. In this module, we'll focus on two major types of diagrams that you might draw during the analysis phase. These are process models, which we usually use a data flow diagram for and then data models, which we use something called an entity relationship diagram for. But we're going to start with data flow diagrams and the various components of them. You might remember something like this from the beginning of the course. This is called a context diagram. Now, actually a context diagram is really just a special subset of data flow diagram. You can think of it as the top level data flow diagram, it shows the relationship of a system to its external entities. In this case, we have a textbook example of a tune source digital music downloads system. You can think of this like Apple's iTunes basically, an online music store. The context diagram that you see here, shows the relationship with the system to external entities such as customers, payment clearing houses, and marketing managers. Of course, in a real life scenario, this would be much more complicated. We've simplified it here for the purposes of discussion. There are three major components in a data flow diagram. We start with a process. Processes in a data flow diagram typically appear in a box with rounded corners. They have a name and we'll talk about how to pick a name for each process, as we move ahead and then we typically give them a number. In the context diagram, you'll see here that we represent the system itself as one big process and we usually by convention, give it the number 0. We'll show you how the numbering scheme works in future videos. Also in a data flow diagram, we have these boxes. These boxes represent what are called external entities. These are people or other systems that might want to interact with the system in some way. Finally, we have the arrows that represent the flow of data between external entities and processes or in between processes themselves. We'll talk about a lot of rules for how you draw these arrows and you'll see that this diagram really has a very specific syntax to it, so that it can be properly understood by a wide range of people. There are multiple different types of notation out there for data flow diagrams. Most of the examples that you'll see in this course use something called Gane and Sarson notation. There's also another one, another notation out there called DeMarco Yourdon. Both of these notations are used equally and you'll see a few examples of DeMarco Yourdon, but most of what we do, we'll use the Gane and Sarson symbols. You can see here the Gane and Sarson symbols represent processes with a box, with rounded corners. Both types of notations use an arrow to represent a data flow. We'll also talk about data stores, which can be anything from a computerized database, down to a filing cabinet or even just a stack of papers on your desk. You can see there's slight differences in how data stores are represented and external entities are represented in both notations as a box. As I mentioned, in a future video, we'll talk about specific rules as to how you connect these items in your diagram. Finally, let's talk about the relationship of the data flow diagram to the use case diagram, which we looked at in previous lessons. There is a relationship although, it's not necessarily as strong as we would like. There are some things that are usually identical between the two. So, for example, external entities in our data flow diagrams generally match up with the actors from our use case diagrams, also the title which is essentially the name of the system can be shared. However, data flow diagrams represent the flow of data, whereas use case diagrams are really representing a relationship between actors and use cases. So, in a use case diagram you won't necessarily have labeled flows of data. The process names in our data flow diagram are usually similar to the use case names for our use case diagrams. However, there's often a minor difference because in our use case diagram, we focus on the user's perspective, while on the data flow diagram we might focus on the organization or the corporate perspective. We'll dig into the various details of data flow diagrams in future lessons. One last note in data flow diagrams, we typically represent additional detail by providing additional data flow diagrams. So, for example, we start with a context diagram that you see here, that has the primary system with the number 0 and in a future video, we'll show you how to decompose this into additional diagrams that provide additional detail. On the other hand, if you take a use case diagram as we learned earlier, the detail for use case diagrams is often in detailed use cases will include steps, preconditions, post conditions, and all of the components and elements we talked about in that lesson. From this point, we're going to take a look at data flow diagrams, we'll go into additional detail into how you'd put these diagrams together and the rules to make sure that your diagram communicates something effective to system engineers.
