CPSC 333 --- Lecture 12 --- Friday, February 2, 1996 Modern Structured Analysis --- Completed E) "Level Down" Towards Process Specifications At this point you will have a set of "bottom level" processes that must be specified. For the "Student Information System (Version 2)" example we have nine such processes: 1.1) Enter New Student 2.4) Change Course Info 1.2) Display Student Info 3.1) Enter Student Registration 2.1) Enter New Course 3.2) Enter Student Withdrawal 2.2) List Course Info 3.3) Enter Student Completion 2.3) Delete Course Do the following, *until there are no "unspecified" bottom level processes left*. Choose an "unspecified" process P to consider next (I don't care how you make a choice --- "just pick one"). a) Try to create a process specification for P. Use the format given in the examples in the online lecture notes for lecture 8. This *should* be possible to do --- though you may discover that you need more information about what the process really should do (and you may need to ask potential system users for these details). b) If the resulting process specification is short (at most two or three pages long, and ideally even shorter) and simple, then use this process specification, and remove process P from your set of "unspecified" processes. c) Otherwise, since P is too complicated to be specified by a process specification of reasonable size, you should create a new lower level data flow diagram that refines process P. Now, you can remove processes P from your set of "unspecified" processes, but you must add all the processes in the lower level diagram that "refines P" to this set. How to Decompose P? - Use your draft process specification as a guide - It may be possible to take a "functional" approach: Try to identify major "subtasks" in the process specification for P, and add bubbles for each of these in your lower level diagram - Consider also the "data flow" within P. You might decide to add process that validate syntax, and perform necessary cross checking, for individual inputs, or for related sets of inputs. You might also decide to add one more processes that construct and format one or more of the outputs. - NOTE: We haven't added data flows directly between processes until now --- because all the processes we've seen so far have been responsible for dealing with individual *asynchronous* events. Therefore we haven't been able to depend on the processes being active at the same time. Now that we're refining a process responsible for handling *one* event, this isn't the case. You *might* be able to assume that two (or more) processes are active at the same time --- so that these processes *can* communicate directly, and you *can* include data flows directly between them. - Working from your "draft" process specification" for P, create draft process specifications for each of the processes in the lower level diagram that refines P (and throw the old "process specification for P" away). For the "Student Information System (Version 2)" I decided that it wasn't necessary to use lower level data flow diagrams to refine any of the nine bottom level processes I had at the end of step D --- all the "draft" process specifications I created for these were short and simple. These process specifications are in the file lecture_12_pspecs.txt. F) Create a data dictionary You might have been working on this all along, by creating definitions for data flows and data stores as you introduced them to data flow diagrams. Make sure you've included *one* definition for each data flow and each data store. List the definitions in alphabetical order --- this will make it much easier to be sure you've given one definition for everything, and it will make it easier to find information later on. My data dictionary for the data flow diagrams of the "Student Information System (V2)" is in the file lecture_12_data_dictionary.txt. Control Information "Regular" data flow diagrams do not include any way to show states and control information, even though these are useful. "Augmented" data flow diagrams add these. In particular, "augmented" data flow diagrams may include two additional things that regular data flow diagrams cannot. The first of these is a "control flow" between two processes, or between a process and a terminator. A control flow is drawn as a dashed arrow, as shown, for example, in the file lecture_12_control_flow.ps. This is used to show that a "control signal" is being communicated rather than a "regular" data item. A control signal is even simpler than a boolean data item --- because it has only *one* value and is either sent or isn't (in contrast, a boolean data item has *two* possible values). You can think of a control signal as representing the fact that some "button" has been pressed. A "control process" is drawn using a dashed circle, as shown in the file lecture_12_control_process.ps. A control process only receives control signals as inputs, and only produces control signals as outputs. These are useful if a system can be in one of a small number of "states," and maintaining the "system state" is an important part of the system function. Consider, for example, a system that maintains a traffic light. To keep things simple we'll assume there's only one light that controls traffic in one direction. The light can be active ("on") or inactive ("off"). When the light is active, it displays one of three colours --- red, green, or amber. A data flow diagram for a part of this system is given in the file lecture_12_dfd.ps. It shows that a terminator called "Timer" generates control signals that can be used to turn the light on or off, and to change the colour being displayed if the light is on. A control process receives these control signals, and sends other signals --- "Show Red," "Show Green," "Show Amber," or "Turn Off," to report the light's new state to the rest of the system. These outgoing signals are shown as being received by four other "regular" processes, which presumably use this information to do useful work. While you *could* specify a control process using a "process specification," this isn't how such a process is generally specified. Instead, a *state transition diagram* is used as a specification for a control process. A state transition diagram that specifies the "Traffic Light Controller" is shown in the file lecture_12_std.ps. This diagram includes four *states* --- "Inactive," "Red," "Green," or "Amber." As this example illustrates, states are shown on state transition diagrams as rectangles, with each rectangle labeled by the name of the state it represents. The system is assumed to be in *exactly one* state at any time. Possible state changes --- or *transitions* --- are represented by arrows on this diagram. With only one exception, every arrow on the diagram should connect one state to another (or one state to itself) and should have a label (that will be explained in the next paragraph). The exception is an arrow pointing "from nowhere" to a state. This identifies the "start state," which is the state the system can be assumed to be in when the system is first "started up." In the above figure, the state "Inactive" is identified as the start state (so, we assume that the traffic light is initially "off"). Each labeled arrow (that is, all but one arrow on the diagram) is labeled by a horizontal line, with the name of a control signal that is received as *input* by the control process being specified above the line, and with the name of a control signal sent as *output* by the control process below the line. You can think of the "incoming" control signal (that is, the one above the line) as "activating" or "starting" the transition: If the system is in the state that is the source of the arrow, and the control signal at the top of the arrow's label is received, then the system's state changes *instantaneously* to the state that is the destination of the arrow, and the control signal at the bottom of the label is immediately sent out by the control process. Consider, for example, the states "Inactive" and "Red," and the labeled arrow from "Inactive" to "Red" --- that is, the part of the diagram shown in the file lecture_12_transition.ps. The "incoming" control signal for this transition is "On/Off," and the outgoing signal is "Show Red." This part of the diagram can be interpreted as follows: Whenever the system is in state "Inactive," and the control signal "On/Off" is sent to the Traffic Light Controller, the system state changes *instantaneously* to state "Red," and the control signal "Show Red" is sent out from the controller at the same time. In order for a system to be "deterministic," you should not have two or more arrows leading out of any state that are labeled by the same incoming control signal --- otherwise, it wouldn't be clear which transition should be followed out of that state when the incoming control signal was received. As the state transition diagram discussed above shows, it isn't necessary that *every* possible incoming control signal be used as a transition out of every state. Note, in particular, that there is no transition out of the "Inactive" state that corresponds to the incoming signal "Change Colour." You can assume that, if this control signal is ever received when the system is in the "Inactive" state, then the control signal is simply ignored (so that the state isn't changed and no outgoing signal is sent).