The control specification (CSPEC) represents the behavior of the system (at the level from which it has been referenced) in two different w...
The control specification (CSPEC) represents the behavior of the system (at the level from which it has been referenced) in two different ways. The CSPEC contains a state transition diagram that is a sequential specification of behavior. It can also contain a program activation table—a combinatorial specification of behavior. It is now time to consider an example of this important modeling notation for structured analysis.
Figure below depicts a state transition diagram for the level 1 control flow model for SafeHome. The labeled transition arrows indicate how the system responds to events as it traverses the four states defined at this level. By studying the STD, a software engineer can determine the behavior of the system and, more important, can ascertain whether there are "holes" in the specified behavior. For example, the STD indicates that the only transition from the reading user input state occurs when the start/stop switch is encountered and a transition to the monitoring system status state occurs. Yet, there appears to be no way, other than the occurrence of sensor event, that will allow the system to return to reading user input. This is an error in specification and would, we hope, be uncovered during review and corrected.
Examine the STD to determine whether there are any other anomalies. A somewhat different mode of behavioral representation is the process activation table. The PAT represents information contained in the STD in the context of processes, not states. That is, the table indicates which processes (bubbles) in the flow model will be invoked when an event occurs. The PAT can be used as a guide for a designer who must build an executive that controls the processes represented at this level. A PAT for the level 1 flow model of SafeHome software is shown in figure below. The CSPEC describes the behavior of the system, but it gives us no information about the inner working of the processes that are activated as a result of this behavior.
The Process Specification
The process specification (PSPEC) is used to describe all flow model processes that appear at the final level of refinement. The content of the process specification can include narrative text, a program design language (PDL) description of the process algorithm, mathematical equations, tables, diagrams, or charts. By providing a PSPEC to accompany each bubble in the flow model, the software engineer creates a "minispec" that can serve as a first step in the creation of the Software Requirements Specification and as a guide for design of the software component that will implement the process.
To illustrate the use of the PSPEC, consider the process password transform represented in the flow model for SafeHome. The PSPEC for this function might take the form:
PSPEC: process password
The process password transform performs all password validation for the SafeHome system. Process password receives a four-digit password from the interact with user function. The password is first compared to the master password stored within the system. If the master password matches, <valid id message = true> is passed to the message and status display function. If the master password does not match, the four digits are compared to a table of secondary passwords (these may be assigned to house guests and/or workers who require entry to the home when the owner is not present). If the password matches an entry within the table, <valid id message = true> is passed to the message and status display function. If there is no match, <valid id message = false> is passed to the message and status display function.
If additional algorithmic detail is desired at this stage, a program design language representation may also be included as part of the PSPEC. However, many believe that the PDL version should be postponed until component design commences.
