CPSC 333 --- Lecture 11 --- Wednesday, January 31, 1996 "Modern Structure Analysis --- Continued" At the end of "Step B," we have one data flow diagram that includes one terminator, "Instructor," as well as nine processes (which I'll be calling "event-level" process, since each handles all of the system's response to one event): 1. Enter New Student Data Flows from Instructor: ID number, name 2. Display Student Info Data Flows from Instructor: ID number Data Flows to Instructor: student info 3. Enter New Course Data Flows from Instructor: discipline code, course number, title 4. Change Course Info Data Flows from Instructor: discipline code, course number, title 5. Delete Course Data Flows from Instructor: discipline code, course number 6. List Course Info Data Flows from Instructor: discipline code, course number Data Flows to Instructor: title, registered students, passed students 7. Enter Student Registration Data Flows from Instructor: ID number, discipline code, course number 8. Enter Student Withdrawal Data Flows from Instructor: ID number, discipline code, course number 9. Enter Student Completion Data Flows from Instructor: ID number, discipline code, course number C) Introduce Data Stores and Connections to/from Them from/to Processes Add data stores needed to remember information created by the system's response to one (asynchronous) event and accessed and/or modified during the system's response to later events. This information might be accessed and/or modified during the system's response to two or more events --- in which case the data store would appear to be "shared" by two or more of the "event-level" processes created in step (B), once data flows between data stores and processes had been added. On the other hand (but less commonly) it might only be needed for multiple occurrences of the same (kind of) event --- and it might appear that only one process communicates with the data store. Add data flows between the data stores and processes, for creation, modification, deletion, and reading of information in the data store (as needed). The event list will be useful here, since it includes the information you need to decide which stores needed to be accessed or modified in order to respond to events --- as well as which stores needed to be accessed for thorough error checking. If an entity relationship diagram has been developed for the system then an "initial" set of data stores can be derived from this diagram. For example, data stores called "Students," "Courses", "Registrations" (corresponding to the relationship "is registered in") and "Completions" (corresponding to the relationship "has passed," which could also have been named, "has passed"), are obtained by looking at this ERD for Version 2 of the "Student Information System." Additional stores corresponding to a small (fixed) amount of information, rather than a data table, might need to be added. This isn't necessary for this example. The following data flows between processes and data stores are added to the data flow diagram for Version 2 of the "Student Information System" at this point: New Data Flows to/From Process 1 (Enter New Student): Add a data flow, "student," to the data store "Students." Show this as a data flow for creating a new instance (and its addition to the store). New Data Flows to/from Process 2 (Display Student Info): Add a data flow, "student," from the data store "Students." Add a data flow, "completions," from the data store "Completions." Add a data flow, "registrations," from the data store "Registrations." New Data Flows to/from Process 3 (Enter New Course): Add a data flow, "course," to the data store "Courses." Show this as a data flow for creation of a new instance (and its addition to the store). New Data Flows to/from Process 4 (Change Course Info): Add a data flow, "course," to the data store "Courses." Show this as modification of an existing instance. New Data Flows to/from Process 5 (Delete Course): Add a data flow, "registrations," from the data store "Registrations." Add a data flow, "completions," from the data store "Completions." Add a data flow, "course," to the data store "Courses." Show this as a deletion of an existing instance from the store. New Data Flows to/from Process 6 (List Course Info): Add a data flow, "course," from the data store "Courses." Add a data flow, "completions," from the data store "Completions." Add a data flow, "registrations," from the data store "Registrations." New Data Flows to/from Process 7 (Enter Student Registration): Add a data flow, "student," from the data store "Students." Add a data flow, "course," from the data store "Courses." Add a data flow, "completion," from the data store "Completions" (for error checking --- to ensure that the student hasn't already taken and passed the course) Add a data flow, "registration," to the data store "Registrations." Show this as creation of a new instance (and its addition to the store). New Data Flows to/from Process 8 (Enter Student Withdrawal): Add a data flow, "student," from the data store "Students." Add a data flow, "course," from the data store "Courses." Add a data flow, "completion," from the data store "Completions" (for error checking --- to ensure that the student hasn't already taken and passed the course) Add a data flow, "registration," to the data store "Registrations." Show this as deletion of an existing instance from the data store. New Data Flows to/from Process 9 (Enter Student Completion): Add a data flow, "student," from the data store "Students." Add a data flow, "course," from the data store "Courses." Add a data flow, "registration," to the data store "Registrations." Show this as deletion of an existing instance from the data store. Add a data flow, "completion" to the data store "Completions." Show this as a creation of a new instance (and its addition to the data store). At this point it would be a good idea to check that each data store corresponding to the ERD is used. There should be a way to create, modify, delete, and read instances of entities, associative objects, weak entities, and subtypes. There should be a way to create, delete, and check for the existence of (that is, read) instances of relationships. A check on this example would suggest that the set of "event" is incomplete, because these don't include any way to delete instances of the object "Course" or of the relationship "has passed" (and the corresponding data store, "Completions"). As I've said before, there probably *should* be at least one more event, whose response by the system includes deletion of these. At this point, you have a data flow diagram that describes the entire system. Unfortunately, - it will be huge; - it will include processes that haven't yet been described using process specifications. It's likely that some of the processes are really too complex to be described using a reasonably sized process specification. ...so we're not finished yet. D) "Level Up" Towards Context Diagram Use the data flow diagram resulting from C as a "first draft" for the level 1 data flow diagram for your system. While the diagram is too large --- that is, it includes more than seven data stores and processes --- perform the following steps. a) Choose some small set of the processes in this diagram that either - have similar functions (so it would make sense to group them together), or - share access to one of the data stores or both. b) Choose a name for a new process that includes all the processes in your set of subprocesses. c) Replace the set of processes in the level 1 diagram by the new, more general, process you've created. d) Create a lower level diagram "refining" the new process, that includes all the processes in the set you've just removed from the level 1 diagram. e) Now, move the data stores: for each data store S: - If *all* the processes that send and/or receive data flows to/from S are in the set of processes that you've moved to a lower level, then move the data store S to the same lower lower diagram that now includes these processes - Otherwise, keep the data store S on the level 1 diagram ... so that there will still be *exactly one* occurrence of S somewhere on the data flow diagrams. f) Use "conservation of flow" to add data flows to and from the new process on the level 1 diagram (based on the data flows to and from the processes you've moved to a lower level) Once all this has been done (so that the level 1 diagram contains at most seven data stores and processes), - Create a context diagram for the system (referring to the level 1 diagram, and using "conservation of flow") to decide which data flows should be shown to/from the system bubble from/to the terminator - Since the terminators are all shown on the context diagram, they can (and should) be removed from the context diagram. - Now, add new process numbers for the processes that are left on the level 1 diagram, and for the processes in the lower level diagrams you've created. Consider the diagram obtained in step (C) for Version 2 of the "Student Information System." This includes nine processes and four data stores, so it's too large. We'll start to fix this by moving the pair of processes "Enter New Student" and "Display Student Info" to a lower level diagram. We'll name the "higher level" process that replaces them on the level 1 diagram "Process Student Information" It isn't possible to move any data stores off the level 1 diagram, because there are processes remaining on the level 1 diagram (such as "Enter Student Registration") that access all of them. (Note that if Processes 7, 8, and 9 *didn't* do thorough error checking, including accessing the data store "Students," then it would be possible to move the data store "Students" down to the lower level diagram that includes processes "Enter New Student" and "Display Student Info"). Checking the data flows to and from the processes "Enter New Student" and "Display Student Info," we see that the following data flows must be included to and from "Process Student Info" on the level 1 diagram: - "ID number," from the Instructor to the process - "name," from the Instructor to the process - "student info," from the process to the Instructor - "student," from data store "Students" to the process - "registrations," from data store "Registrations" to the process - "completions," from data store "Completions" to the process - "student," from the process to the data store "Student" --- and shown as creation of a new instance We now have two diagrams: - Level 1 Diagram: Includes the terminator "Instructor," the data stores "Students," "Courses," "Registrations," and "Completions," and eight processes: - Process Student Information - Enter New Course - Change Course Info - Delete Course - List Course Info - Enter Student Registration - Enter Student Withdrawal - Enter Student Completion - Level 2 Diagram: Refines "Process Student Information" and includes two processes: - Enter New Student - Display Student Info The level 1 diagram is still too large, so we'll select another set of processes --- "Enter New Course," "Change Course Info," "Delete Course," and "List Course Info," to move down into a new level 2 diagram. These will be replaced by a new process, "Process Course Information," on the level 1 diagram. Again, it isn't possible to move any data stores down to level 2 along with these processes (and, again, it *would* be possible to move "Courses" down if the processes "Enter Student Registration," "Enter Student Withdrawal," and "Enter Student Completion" didn't do thorough error checking). Conservation of flow can be used to decide which data flows should go to and from "Process Course Information" on the level 1 diagram. These are as shown on Figure 1 in the "Data Flow Diagrams for the Student Information System" handout distributed last week. We now have three diagrams: - Level 1 Diagram: Includes the terminator "Instructor," the data stores "Students," "Courses," "Registrations," and "Completions," and five processes: - Process Student Information - Process Course Information - Enter Student Registration - Enter Student Withdrawal - Enter Student Completion - Level 2 Diagram: Refines "Process Student Information" and includes two processes: - Enter New Student - Display Student Info - Level 2 Diagram: Refines "Process Course Information" and includes four processes: - Enter New Course - List Course Info - Delete Course - Change Course Info Finally, we will move the set of processes "Enter Student Registration," Enter Student Withdrawal," and "Enter Student Completion" down to level 2 and replace them on the level 1 diagram by a new process, "Process Course Registrations and Completions." No data stores can be moved down. Conservation of flow is used to decide which data flows should be shown to and from "Process Course Registrations and Completions." At this point we have a level 1 diagram and three level 2 diagrams refining each of the three processes shown at level 1. The level 1 diagram includes four data stores and three processes, and is small enough. The terminator "Instructor" is moved to the context diagram. Conservation of flow is used to figure out which data flows should appear on the context diagram. Now the processes on the level 1 diagram, and each of the level 2 diagrams, are numbered. The result is shown as Figures 1--5 on the "Data Flow Diagrams for the Student Information System" handout that was distributed last week. One problem --- having a data flow diagram that is too large --- has been solved. However, we still need to add process specifications, and some of the current "bottom" processes may be too complex to be modeled this way.