Thou unnecessary letter! William Shakespeare, King Lear, II: 2.
10.1 Introduction.
In this final chapter we list areas of research that will need to be considered to take forward the work that has already been started on writing and animating Z specifications.
For simplicity we look at writing and animation separately. In particular we concentrate on how OPERATOR might be developed further and the research that is needed to improve Zappa.
10.2 Areas for future research - Developing OPERATOR further.
The OPERATOR approach certainly contains the beginnings of a method. However, this method needs to be defined more sharply and the separate steps of the method expanded.
A tighter definition of an object is needed so that system objects can be readily identified at the beginning of the method.
The has/have properties of objects that then flow also need tighter definition - and possibly need expanding in scope - so that all system entities can be identified with confidence. Whilst the present method has enabled complete specifications to be drawn up for the relatively simple systems to which it has been applied, there is no guarantee that the method will be capable of identifying all the entities in more complex systems.
The R step of the method is designed primarily to identify binary relations. . Again, it is not clear that all systems can be specified in terms of sets of entities and
binary relations. An approach for identifying general system relationships is needed as well.
Data modelling is also not well developed in the method as it stands and further research to enable this first vital link with the Z notation is needed.
In essence then, the steps of the method need to be defined yet again and developed further to enable the approach to have wider applicability. We are aware that research on all these aspects of developing OPERATOR further is being carried out by Tamarin Othman at Sheffield Hallam University [Oth95]. Recent discussions suggest that Object Oriented Analysis is proving useful in attacking many of the areas mentioned - particularly when systems are complex.
There is no reason why the OPERATOR method should cease with the identification of state variables and the signatures of operation schemas. Systematic ways of arriving at data variants together with pre and post conditions for specifying operations must now be researched.
The whole issue of addressing complexity and structuring large specifications needs to be researched more fully and clear ways for developing specifications of complex systems formulated. The approach outlined works for the systems considered so far, but needs to be extended to include the concept of different levels of
subsystems.
Along with all of this needs to be developed the associated diagramming notation.
Finally, once the OPERATOR method has been more sharply defined and the separate steps expanded, then tool support to enable the developer to use the method easily and consistently needs to be provided. Once again, we are aware that work aimed at supporting the method with a prototype CASE tool is being carried out by Tamarin Othman at Sheffield Hallam University. The outcomes of this research are awaited.
10.3 Areas for further research - Developing the Crystal Approach and Zappa further.
Areas of further development for the Crystal approach and for Zappa have already been briefly indicated in chapters 6 and 7, respectively. A library of Z functions might be supplied for Crystal, written in C and interfaced with the Crystal shell.
Zappa can be expanded by adding algorithms to cater for additional
constructed types. The reusability of existing ZAL code in Zappa makes this less of a task as it may at first seem.
At present Zappa assumes that a single state schema is at the heart of a specification and that state variables have global scope. This is inadequate if Zappa is to be able to animate large systems. Provision will have to be made to implement the schema calculus of Z faithfully, schema inclusion in particular.
As we have presented only anecdotal evidence here, work still has to be done to investigate the efficacy of the Crystal approach and Zappa in terms of validation of user requirements.
The restrictions on the style of Z required for animation by Zappa highlights an important and general issue regarding the use and development of animators and other
CASE tools for Z: What in Z is 'animatable' and how restrictions on the writing of Z specifications, imposed by tools, affect the formal software development process are areas that we feel need careful consideration. We are aware that research considering 'animatability', and the definition and specification of an 'ideal* animator for Z, is being carried out by Alistair Jack at Sheffield Hallam University [Jac95].
Formal methods will surely play a part in the future development of software engineering, either as fully developed methods in their own right or as tools within existing structured software engineering approaches. Software systems will continue to become more complex, widespread and safety critical. Formal methods will be required to exert scientific rigour on the software development process, and, with well
developed techniques and computer-based tools to aid in the process, will become ever more important.
Finally, we hope that what has been presented here will add a little to the experience and knowledge of practitioners and researchers in this challenging field.
REFERENCES IN CHAPTER 10
Oth95. Othman, M., T., A., B., registration for degree of MPhil: Developing and validating a methodology and supporting tool for writingformal Z specifications, Sheffield Hallam University, October, 1995.
Jac95. Jack, A , registration for degree of MPhilYPhD: Definition and Specification o f a Z Animator, Sheffield Hallam University, July, 1995.