USER ID BorrowCopy Loans COPY ID Copies user? date? copy?
Fig. 4.5: Diagram showing the BorrowCopy operation in the library system.
The notation used is deliberately similar to that used to represent data flow diagrams. The operation name is put inside a circle as shown, as in Yourdon, for example. Inputs and outputs are drawn inside rectangular boxes. These are similar to the terminators of data flow diagrams in Yourdon. The sets from which inputs and outputs are drawn are indicated as shown. The dotted arrow is again used to indicate that data modelling is being used. The direction of the dotted arrow will signify whether an input or an output is being modelled. An output arrow would go into the output box and the output itself would have a shriek mark decoration - as in Z.
The system substates that are affected or needed by the operation are
represented in the same way that data stores are in Yourdon. The solid arrows are also significant. Thus we see that the Users substate will not be changed by the operation. Its contents are only read. The Copies substate is both read and written to as the status of the borrowed copy will be changed to borrowed. The Loans substate is not read, but is written to.
In the same way that the system entity diagram can be transformed into Z using the R, A, T, O, R part of the method, so too can the operation diagram be turned into Z, once the state schema has been produced. The diagram will enable the specifier to write down immediately what the signature of the operation schema is. The signature of the BorrowCopy operation is thus the following:
________ BnrrawConv ______________________________________________ ALibrary EUsers ACopies ALoans users? : USERJD copy?: COPYJD date? : DATE
ALibraryis needed because we wish to bring into scope all the before and after states of the library and their collective properties. EUsersis included to alert us to the fact that the state variables in the Userssubsystem are not being changed. ACopiesand
ALoansare, strictly speaking, not needed because the appropriate before and after states of the Copiesand Loanssubsystems are already in scope. Their inclusion alerts us explicitly to the fact that these subsystems are changed by the operation. The inputs,
users?, copy?and date?are those indicated on the operation diagram.
As with the production of the state schema previously, the use of the diagram does not help with the predicate part of the operation schema. This, however, can be written and systematically produced with reference to preconditions and
4.8 Discussion.
In this chapter we have traced the development of the OPERATOR method from its initial abstract but systematic approach to developing the system state schema to the fuller form it now takes with its diagramming front end and its system
partitioning mechanism. Of note is the fact that the approach does comprise a method for going systematical from the system entities, identifiable graphically, to the system state schema in a way that addresses complexity in large systems. Of note also is the way in which the OPERATOR approach addresses the strengths and weaknesses of mathematics as a specification language.
Initially the diagramming notation allows the specifier to work interactively with the client to capture the essential features of the system state, including any key structural issues. Boxes and arrows are intuitively simple to work with and model well the hierarchical properties of the system. Data modelling (via the dotted arrows) does not have to involve the client and nothing is lost by not including the data modelling at this stage. Operations can also be represented as operation diagrams and drawn up with the client with direct reference to only the system entity diagrams. Again, data modelling via the dotted arrows does not have to feature on the diagrams at this stage. The diagrams thus serve to help the specifier through the abstraction bottleneck [Nor93] and at the same time facilitate effective communication at a crucial time with the system user or client.
Once the specifier and client are happy that the system requirements are being captured, the specifier can go away and via OPERATOR systematically produce the state schema, and the operation schemas as indicated above, bringing to bear all the power and formality of the mathematically based Z notation. Any revisions as a result of applying OPERATOR can be illustrated graphically and discussed with the client. All that remains now is to animate the Z specification that has been developed to
enable the client to see, this time, the system in action. Animation is the subject of the next three chapters. Further discussion of OPERATOR is given in chapter 8.
REFERENCES IN CHAPTER 4
Sem91. Semmens, L. and Allen, P., Using Yourdon and Z: an approach to formal specification, Proceedings of the Fifth Annual Z User Meeting, Nicholls, J.E., Ed., Springer-Verlag, London, 1991.
Ran91. Randell, G., Data Flow Diagrams and Z, Proceedings of the fith annual Z User Meeting, Nicholls, J.E., Ed., Springer-Verlag, London, 1991.
Pol93. Polack, F., Whiston, M., and Mander, K., The SAZ Project: Integrating SSADM and Z, in FME '93 - Industrial Strength Formal Methods, Lecture Notes in Computer Science, Woodcock, J.C.P and Larson, P.G., Eds., Springer-Verlag, London, 1993.
Sul93. Sully, P., Modelling the World with Objects, 2nd edition, Prentice-Hall International, 1993.
Gra91. Gravell, A., M., What is a goodformal specification?, in proceedings of the Fifth Annual Z User Meeting, Nicholls, J.E., Ed., Springer-Verlag, London, 1991.
Spi92. Spivey, J. M., The Z Notation: A Reference Manual, 2nd Edition, Prentice Hall International, 1992.
Coo92. Cooper, D., Mardell, J., Meehan, A., Norcliffe, A. and Valentine, S., A Z Readers Course, Shefield Hallam University Pavic Publications in Assn. with the D.T.I., 1992.
Nor91. Norcliffe, A. and Slater, G., Mathematics o f Software Construction, Ellis HorwoodLtd., 1991.
Nor93. Norcliffe, A., Computer Aided Modelling, in Proceedings of the Eighteenth Undergraduate Mathematics Teaching Conference, Yardley, P. (Ed.), Shell Centre Publications, 1993.