Welcome back, last lesson, we talked about the behavioral, hierarchical Jackson structured design. The main features of this representation of design was that it was behavioral, static, and hierarchical. It was behavioral in the sense that it described what the software should do. It was static in that it did not represent a flow of actions or data. And it was hierarchical in that it allowed decomposition of broad tasks or behaviors into smaller tasks. Data flow diagrams are similar, except that they are functional and dynamic, besides being hierarchical. There are four basic symbols used in the data flow diagram. The first is a circle. A circle represents an operation or a function which translates inputs into outputs. The circle typically has a label in it that tells us what that operation does. Second, there are boxes which represent an external source or sink of information. By external, we mean outside the system which is being described. Third, there is a label with a bar on the top and a bar on the bottom. These are data stores within the system. Fourth, and finally, there are arcs. These are curved lines with an arrow at one end, which shows the direction of data flow. Typically, the arcs are labeled with a description of the data flowing along the line. Now, here's a high-level data flow diagram from a project I worked on many years ago. You can see that there are four steps in the process that's being represented. To explain, this process describes how a resident of an assisted living facility, or a nursing home, would obtain medication. The first bubble is to obtain a prescription. The second bubble is to have that prescription filled. The third is to create a schedule for when the medication ought to be administered. And the fourth is to actually make a record of when the medication is administered. The large arcs in the data flow diagram show that patient and prescription information flow from the write prescription bubble to the fill prescription bubble. We'll look more closely at fill prescription in a minute. The arc from fill prescription to create schedule contains patient information, prescription information, and fill information. Patient information might tell us a patient's name, what facility she's at, what room she is in, and so forth. Prescription information is what the prescriber intended the patient to have, in terms of dose, route of administration, for example, by mouth, by injection, and so on. And some frequency, daily, before meals, upon waking, and so forth. The fill data, okay, the prescription may have said ten-milligram tablets to be given every morning before eating. The fill data might say that these are five-milligram tablets, and so two are to be given each morning, and so forth. Let's look a little more closely at the fill prescription step. We see that in addition to the patient and prescription data flowing in and the patient prescription and fill data going out, we have an external store called user/auth, user authorization. This might be a single-login system for company business or a secure network. It's outside the medical system, and the bubble simply uses that to ensure that whoever's accessing the functionality has permission to do so. Then there are the three data stores, one for medications, one for prescriptions, one for providers. The medications database might be a system that gives you labeling and warning information about various medications. It may also maintain stock information if this is a large pharmacy. The provider's data file would be a list of doctors and other permitted to prescribe drugs. And finally, there's a prescriptions data store, but wait, you say, prescription data for the patient is flowing into the bubble. Why do we need another source of prescription information? That's because one of the major responsibilities of pharmacists is to understand drug interactions, which means having access to all the patient's previous and current prescriptions. Of course, the prescription is then filled, and then sent on its way with the patient. Next, we'll look at a decomposition of the previous bubble. For decomposition to be valid, it must have the same number of inputs and outputs as the bubble being decomposed. Now, because this is not a course on how to run a pharmacy, I won't go into a lot of detail about how the diagram works. However, the important points are that the single fill prescription bubble is decomposed into six steps. We saw something like this when we were looking at Jackson structured design diagrams in the last lesson. The difference here is that we have a definite sense of step-by step-process, and we show the data, which flows into and out of each step. At this point in the module, you've seen two hierarchical types of design. We're next going to look at a design concept that is different altogether. This is design using the language Z.
