Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Process Specifications
This material was covered during lectures on January 31, 1997.
A process specification is used to specify requirements for one process on a data flow diagram, more precisely and in more detail than is possible using the data flow diagram alone.
If a system is represented using a single data flow diagram, then there should be a process specification for each one of the processes shown on the diagram.
We will see shortly that a system can also be represented using a set of data flow diagrams. In this case, then there should be a process specification for each process that is not refined to produce another data flow diagram; this will be explained again when ``leveled sets of data flow diagrams'' have been introduced.
A process specification should include the following components
This can be an algorithm for generation of the outputs from the inputs, but it doesn't need to be.
For example, suppose we had a process called "Decrement," which took a single integer x as input, and produced a single integer y as output. The assertion
x = y + 1,
(which is either ``true'' or ``false,'' once integer values have been chosen for x and y) gives a rule that will allow you to decide whether a value for y would be correct as an output, when the process received a given value for x as input.
Instead of this, you could include an extremely simple algorithm:
y := x - 1
You should avoid using an algorithm (and give a rule instead) if such a rule is easy to describe, or especially if there are several different algorithms that software designers and implementers could choose in order to do the job later on, and you don't want to ``bias'' the choice of algorithm now by including one in the process specification.
Sometimes, though, the easiest (and, perhaps, only straightforward) way to describe an acceptable output is to give an algorithm that computes it. As well, it's sometimes the case that you're told that a specific algorithm must be used, in which case you'd better list it!
For example, a process specification that corresponds to Process #1 in the previous data flow diagram might be as follows.
Process Name: Register Student
Process Number: 1
Inputs: ID number, name
Outputs: status message, student
Assumptions:
Data management subsystem is correct. That is, if it is provided with an instance of ``student'' whose ID number is not already in use (and is asked to add it to the data table), then this will be added to the data table and no other change will be made. otherwise, an error message will be returned and no change will be made to the data table at all.
Error Conditions:
Relationships between Inputs and Outputs:
Note that the above ``error conditions'' are things that this process really can detect. Furthermore, if the stated ``assumption'' really is true, then the second ``error condition'' would be equivalent to the condition that ``the ID number is already in use.''
The ``assumption'' given above is, essentially, that another part of the system that is being specified does work correctly. In this course, it'll be perfectly acceptable if you always ``assume'' this is the case - at least, at the beginning of requirements analysis - and if you leave this kind of assumption out.
In the above example, ``student[ID number]'' refers to the value of the attribute ``ID number'' for the instance of ``student'' that is being created, and so on.
Instead of the above six ``relationships,'' between inputs and outputs, given for the case that errors haven't been detected, the part of the process specification corresponding to ``behaviour in the absence of errors'' could have been given as a very short algorithm. You might show when errors are detected and reported, at the same time:
if inputs from Instructor are syntactically correct then
student[ID number] := ID number
student[first name] := name[first name]
student[middle initial] := name[middle initial]
student[last name] := name[last name]
student[status] := `registered'
Send student to the data store to be added
if data store reported success then
status message := `ok'
else
status message := `ID number is already in use'
end if
else
status message := `Syntax error in input(s)'
end if
The error messages given in the above algorithm certainly shouldn't be the ones that are ultimately used. At some point, later on during requirements analysis, details concerning a human computer interface will be settled, and more helpful (or polite) error messages will be chosen.
Now, there certainly are guidelines for the formation of error messages. Among other things, they should be informative, polite, and constructive. They should also be consistent: If the same error condition is checked in several processes then, ideally, the same error message should be used in all cases. Error messages for different conditions should also use consistent wordings, reported using a consistent interface, and so on. A small amount of additional material about this is generally covered in CPSC 451; more than that is included in CPSC 481.
Some authors, including Pont, use a different format in process specifications. In particular, they specify processing details (including error handling, as well as normal processing) by a sequence of pairs of preconditions and postconditions.
A precondition specifies properties of or relationships between the inputs that have been supplied to the process. The corresponding postcondition specifies expected properties of the corresponding outputs, as well as relationships between the inputs and outputs that are expected to hold.
When several precondition-postconditions pairs are given then (to be safe), it shouldn't ever be possible to satisfy more than one of the preconditions at the same time.
Now, in order to specify the same kinds of details that have been described above (for error detection, and normal behaviour), using precondition-postcondition pairs, you might include a ``precondition'' for each error condition that should be checked, and a corresponding ``postcondition'' that specifies that error handling that should be performed - provided that it isn't possible for two or more error conditions to arise at the same time. If that's possible, then you might need to do something more complicated, like including a precondition-postcondition pair for each possible combination of error conditions. Either way, you should include (at least) one more precondition-postcondition pair - with the precondition signifying that ``No errors were detected,'' and with the postcondition specifying ``Normal processing.''
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Process Specifications