CPSC 333 --- Lecture 10 --- Monday, January 29, 1996 At this point, you should know what a correct data flow diagram, and a correct leveled set of data flow diagrams, ought to "look like", but nothing's been said about you could construct these... Structured Analysis --- A method for constructing data flow diagrams (and supporting models) in order to model requirements for a system. Main Reference (on reserve in library): E. Yourdon Modern Structured Analysis Yourdon Press (a division of Prentice-Hall), 1989 QA 76.9 S84 Y685 1989 Note: The analysis method has changed pretty drastically over the years; the method for construction of data flow diagrams given in this reference (and described in this course) is *very* different from the method described in "Classical" Structured Analysis. Pressman's books describe still another method for building these diagrams from information about requirements. Yourdon proposed a new method for construction of data flow diagrams after the method proposed in (what he now calls) "Classical Structured Analysis" proved to be unworkable. The "Classical Structured Analysis" method was as follows: "Start from the context diagram, and work from the top down, refining processes and turning them into lower level diagrams, until you end up with processes simple enough to be modeled by process specifications." A) Build an Event List Yourdon now recommends that you start by producing an *event list* --- a list of *external* events, which occur *in the outside world* and to which the system will be expected to respond. A short problem statement will be helpful as you build a first draft of an event list. So will the system's entity relationship diagram, if one has been built --- because it's usually true that instances of every entity, associative object, weak entity, and subtype can be created, modified, and deleted by the system's responses to one or more events; instances of every relationship can be created and deleted by one or more responses to events; and (since there has to be a reason for the system to *need* to remember this information) it should be necessary for the system to refer to each one of the data tables corresponding to the entity relationship diagram, in order to repond to these events. Since an event is something that happens in the *outside world* you should give it a simple name that describes the *external* event that triggers system behaviour, and not the name for the system's internal response instead. It will be useful for later on if you can also identify, for each event, - all inputs that must be supplied from the outside world to the system in order for the system to be able to respond correctly --- and the terminators who supply them - all the outputs that the system will send to the outside world in order to respond to the event --- and the terminators who receive them - any error conditions, corresponding to mistakes the terminators supplying information might make, that the system will be expected to check for and report At this point we are still modeling "essential requirements" and (as discussed when entity relationship diagrams were discussed) assuming that the technology used to implement the system is "perfect". Therefore it isn't necessary, or desirable, to list errors the *system* might have made at this point. Consider Version 2 of the "Student Information System." Here are events that might be included in the event list for this system. 1) Instructor adds a new student. Inputs: name, ID number (from Instructor) Error Conditions: a) Syntactically incorrect inputs b) The ID number corresponds to some student already in the system. 2) Instructor requests student information. Inputs: ID number (from Instructor) Outputs: student info, including the student's name, and a list of the (discipline code and course number for the) courses that the student is registered in, and another list of the courses that the student has passed (to the Instructor) Error Conditions: a) Syntactically incorrect input b) The given ID number doesn't correspond to any student in the system. 3) Instructor adds a new course. Inputs: discipline code, course number, title (from Instructor) Error Conditions: a) Syntactically incorrect inputs b) The discipline code and course number correspond to a course already in the system. 4) Instructor changes course information. Inputs: discipline code, course number, title (from Instructor) Error Conditions: a) Syntactically incorrect inputs b) The discipline code and course number do not correspond to a course already in the system. 5) Instructor deletes course. Inputs: discipline code, course number (from Instructor) Error Conditions: a) Syntactically incorrect inputs b) The discipline code and course number do not correspond to a course already in the system c) There are students who are registered in, or who have passed, the given course. 6) Instructor requests course information. Inputs: discipline code, course number (from Instructor) Outputs: title, registered students (all students registered in the given course), and passed students (all students who have passed the given course) (to Instructor) Error Conditions: a) Syntactically incorrect inputs b) The discipline code and course number do not correspond to a course already in the system. 7) Student registers in a course. Inputs: ID number, discipline code, course number (from Instructor) Error Conditions: a) Syntactically incorrect inputs b) The ID number does not correspond to a student in the system c) The discipline code and course number do not correspond to a course in the system d) The given student is already registered in, or has already passed, the given course. 8) Student withdraws from a course. Inputs: ID number, discipline code, course number (from Instructor) Error Conditions: a) Syntactically incorrect inputs b) The ID number does not correspond to a student in the system c) The discipline code and course number do not correspond to a course in the system d) The given student is not currently registered in the given course. 9) Student passes course. Inputs: ID number, discipline code, course number (from Instructor) Error Conditions: a) Syntactically incorrect inputs b) The ID number does not correspond to a student in the system c) The discipline code and course number do not correspond to a course in the system d) The given student is not currently registered in the given course. Note that this event list is almost certainly incomplete. It's extremely likely that it will be necessary for the Instructor to be able to do all of the following additional things: - Delete a student from the system (along with all the student's course registrations, and information about which courses that student has passed) - Change student information (perhaps by correcting spelling of a name) - Correct information about a "course completion" if the Instructor made a mistake earlier on --- by removing the information that a given student passed a given course from the system As well, additional system outputs are probably necessary --- since these will (eventually) be needed for the system to report the error conditions it found, and to give reasonable "feedback" to the Instructor if the input was acceptable. However, this list is already long (and complex enough) to serve as an example. We'll eventually use it to produce the leveled set of data flow diagrams for Version 2 of the "Student Information System" handed out at the end of the previous lecture. B) Introduce a Process for the System's Response to each Event This is an extremely simple (almost completely mechanical) thing to do. For the next few steps, we'll construct *one huge* data flow diagram that represents the entire system. Later steps will break this up into a leveled set of more readable diagrams and add additional processes (if needed) and process specifications. For each event - choose a reasonable name that describes *what the system does* in order to respond to that event - add a bubble to the diagram, and label it with the name you've just chosen - use the number of the event in the event list as the number for this bubble in the data flow diagram - if they aren't already in the diagram, add, as terminators, all sources of (external) inputs and receivers of outputs corresponding to the system's response to the event. - add data flows between this bubble and the terminators that correspond to this event. If you do this for the event list given in (A), then you will end up with a single data flow diagram that includes - one terminator, with name "Instructor." To improve readability of the diagram, you might have included several copies of this terminator on the diagram - the following nine processes, and the indicated data flows to/from the processes from/to the Instructor: Process 1: Enter New Student Data flows from Instructor: name, ID number Process 2: Display Student Info Data flows from Instructor: ID number Data flows to Instructor: student info Process 3: Enter New Course Data flows from Instructor: discipline code, course number, title Process 4: Change Course Info Data flows from Instructor: discipline code, course number, title Process 5: Delete Course Data flows from Instructor: discipline code, course number Process 6: List Course Info Data flows from Instructor: discipline code, course number Data flows to Instructor: title, registered students, passed students Process 7: Enter Student Registration Data flows from Instructor: ID number, discipline code, course number Process 8: Enter Student Withdrawal Data flows from Instructor: ID number, discipline code, course number Process 9: Enter Student Completion Data flows from Instructor: ID number, discipline code, course number Later steps add data stores and data flows between them and the rest of this system; replace the resulting huge diagram by a leveled set of diagrams; and add lower level diagrams (if needed) and process specifications and a data dictionary in order to produce a "complete" description of the system. We'll continue this process and example in the next lecture.