PRACTICAL METHODS AND TOOLS FOR SPECIFICATION J. Ludewig ETH Zurich, Institut fUr Informatik CH 8092 Zurich Contents O. Introduction 1. Fundamentals 1.1 Life Cycle Model 1.2 Cost Distribution 1.3 Terminology 1.4 Why Semi-formal Specification ? 2. Principles of Specifications 2.1 Qualities of Specifications 2.2 Useful Properties of Specifications 2.3 Specification Systems Requirements 2.4 General Structure of a Specification System 3. Specification Systems: Some Examples (each of the following subheadings consists of three paragraphs: .1 The Method; .2 The Language; .3 The Tools) 3.1 SADT (Structured Analysis and Design Technique) 3.2 SA (Structured Analysis) and proMod (Projektmodell) 3.3 PSLIPSA (Problem Statement Language I P. S. Anatyzer) 3.4 SREM (Software Requirements Engineering Methodology) 3.5 EPOS (Entwicklungs- und Projektmanagement orientiertes S pezifikatio nssystem) 3.6 PRADOS (Projekt-Abwicktungs- und Dokumentations-System) 4. Management Aspects 5. Conclusions 6. Appendix: References. and Addresses of Supptiers Note: Hans Matheis has used an earlier version of this paper for preparing a paper on languages for real-time software specification . Some of his extensions have been integrated here. Our descriptions of specification systems are based on the malerial available to us. This information may not be complete, or up to date. Therefore, we are sorry in case some features are not reported correctly. Please refer to the material available from the suppliers (see 6.2). 175 O. Introduction This Is a course on Specification. Since it is based on experiences in the field of Software Engineering. It applies primarily to SoHware Specificalions. Many observations and reports indicate. however. that. from specification aspects. there is not much difference between Information processing systems in general and software in particular. Therefore, most of this course applies also to System Specification . In the first chapter. some fundamentals are discussed. These include the life cycle model and the distribution of costs over the various activities. some definitions. and a rationale for semi-formal specification . The second chapter provides a general outline of a specification system. whose desirable properties are deduced from the qualities of good specifications. In the third chapter. we present some typical specificalion systems. The primary goal is to show some typical features of such systems rather than to describe them in detail. The fourth chapter addresses management aspects. In chapter 5. some generat conclusions are drawn. The appendix (chapter 6) contains a bibliography on speCification. and a list of suppliers. 1. Fundamentals 1.1 Life Cycle Model Only very small systems can be built in the same way as primitive peoples build houses. As soon as the system is slightly complex. a systematic approach is necessary. The sequence of steps to be taken from the first idea to operation and further on until the system is discarded. is called the System life Cycle. Though there are many different life cycle models. they are all based on the distinction between certain activities or phases, namely analysis and specification design implementation integration operation and maintenance. Note that the life cycle may be used as a phase model. or a model of activities, or a list of roJes . In the sequel, the second meaning is assumed. Recently. the life cycle concept has been attacked by several authors. not only because it does not reflect the experiences of many projects. but also because alternative ways of building systems (for instance by prototyping) are ignored. See the references in 6. t .6. 176 1,2 Cost Distribution About two thirds of the total cost of software are caused by activities wh ich take place when the software is already operational (Le. during maintenance) (Boehm, 1976). Therefore, every attempt to reduce the high cost of software has to focus on maintenance. (Note that there is an important difference between maintenance of hardware and of software: while hardware is actually maintained, i.e. the original stale is conserved or restored, software is corrected, extended, or adapted to new requirements, i. e. it is modified. A program is different from its original state after maintenance.) There are three ways of reducing the need for maintence: reduce need for correction reduce effort for modification reduce total volume (by using standard components or old software) A good specification contributes to each of these subgoals. Therefore, the overall goal is not to reduce the effort for specification, but rather to invest more in specification in order to save much more during maintenance (and also during design and implementation). 1,3 Terminology 1.3.1 SpeCification To date, we have not achieved a slable and well recognized terminology in Software Engineering. fn the sequel, we use a Simple, pragmatiC definition of "specitication" (from Kramer et aI., 1982): A description of an object stating its properties of Interest. It usually implies that the description should try to be precise, testable, and formal. It is recommended that "specification" be used with some attribute, e.g. requirement specification. Specification is frequently used to mean functional specification which contains both requirements and design aspects. This (orm of use is imprecise. Many more relevant terms are defined by the fEEE (1983) . Specifications are written and read by many people, like analysts , customers, managers, and programmers. Since these people differ greatly in th eir background, education, and interest, they have usually not the same idea of what a specification should look like. Tools, which can change the representation of a given information automatically, can help to meet the requirements of more than just one single group. 177 1.3.2 The System Triangle When we talk about programming systems, or specification systems, we distinguish three components, or sets of components, namely methods, languages, and tools. Methods indicate how to proceed, like rocipes in a cookbook. Language s restrict the set of possible statements to a particular universe of discourse, and to a certain syntactical representation. Tools check, store, and transform such statements. All three are strongly Interrelated by the abstract concepts of the (specification-) system. Note that the term "methodology" means "science of methods", though it is often misused for "method". Figure 1 exemplifies th e system triangle: Concepts Tools Fiaure 1: System triangle 1.3.3 Levels of Formality There are languages of various formality. For our purposes, we distinguish four levels of formality, or styles : Style Syntax Semantics Examples informal not (prec.) defined not (prec.) defined natur. languages formatted restricted not (prec.) defined forms semi-formal defined partially defined pseudo-code formal defined defined progr. languages 178 For coding programs, we use a formal language. (Though the semantics of most programming languages are not precisely defined, if at all , there is always a translator which provides a de·facto·definition.) All other documents are written in informal language, sometimes on forms. Forms impose certain restrictions to the way natural language is used, and require the user to answer all relevant questions. Semi·formal languages are comparatively new; their first application was in program design languages (pseudo code). 1.4 Why semi-formal Specifjcation ? This paper does not treat formal specification. This does not mean that formal techniques are not important. However, they are not yet in a stale that users in industry could really apply them. Semi·formal specification, i.e. an approach which is based on semi·formal specification languages, has (at least for the time being) several advantages: The languages can be learned and understood with limited effort by people who did not have extensive training in formal methods Documents resemble those written in natural language Incomplete and vague information fits better in such a system On the other hand, semi-formal specification systems are superior to traditional informal specifications because many deficiencies which would be buried in plain text become visible it can be stored in, and retrieved form, a data base automatic tools can be used for checking and for changing the representation . Oegree 01 Formalization Development with System for 100 % _ •• _. ___ • ___________ • _. _ _ / ~~mi'~o~~~~ ~~~c:r:c~tlon supported by Spec.System ......~=-:-...",.. Traditional Development Phase Idea Specific. Design Coding Test ... Figure 2: Degree of Formalization during the Software Life Cycle 179 Figure 2 shows schematically how the software development process is Influenced by a system for semi-formal specification. In the traditional approach, there Is practically no formalized information until the software is coded. Then, full formalization must be achieved in a single step. This method Is, as we all know, error prone, because there are many misunderstandings, inconsistencies, simple errors and other shortages in the specs which are not discovered, because the document produced next, i.e. the code, can onty be understood at the level of single instructions. tn the modern approach, there are much better chances for detecting deficiencies of the specs, and Improving them. To summarize the message of this paragraph: Specification systems do not shorten the specification phase, but improve the quality of the resulting document. 2. Principles of Specification 2,1 Qualities of