1 Formal Specification of Software: Why and When?

Transcription

1 1 Formal Specification of Software: Why and When? 1.1 Purpose of Specifications Definitions Specification is the precise definition of properties of a technical product or its development process. The term specification refers either to a phase or activity in the development process, or a document resulting from a specification activity. Specifications of software systems can be classified according to their usage in the development process: requirements specification: general definition of properties to be fulfilled by the developed system; problem specification (or functional specification): definition of tasks to be performed by the developed system; design specification: definition of the internal structure of the developed system and of corresponding specific tasks to be performed in the system implementation; module / class specification: definition of the tasks to be performed by a specific part of the software system, possibly including a definition of the internal structure of this part; test specifications: definition of tasks to be performed to demonstrate the correct functioning of the developed system; process specifications: general definition of tasks to be performed in the process of developing a software system. This classification largely follows the well-known basic structure of the software development process, where there exist (independent of any specific process model) the clearly defined activities of analysis (of requirements and proposed solution), design (on various levels) and validation, accompanied by a "meta-level" of process control. A different classification can be made according to the aspect of the system being described: File: fss1 Page: 1

2 functional aspect structural aspect dynamic aspect behavioural aspect non-functional aspect development process aspect Each of these views can be applied to the system as a whole (globally) and on particular parts of a system (locally). Not all aspects are equally important for all usage of specifications in software development: requirements specification: global functional and non-functional aspects problem specification: global functional aspect and global structural aspect design specification: all kinds of aspects, mainly global aspects module / class specification: local aspects only process specifications: development process aspect and global structural aspect test specifications: development process aspect, functional and behavioural aspects In the context of formal specification, the term specification is often (but without any true reason) restricted to requirements and problem specifications. 1 Nevertheless, for this lecture, specifications will be essentially treated as regarding the problem, design and module/class usage from a functional aspect. Other variants of specification can be treated formally as well, of course Why do we need specifications? Specifications are key to development contracts and procurement decisions. Specifications are key to resource and time planning of a development project. 1 B.Meyer, On Formalism in Specifications: Specification is the software lifecycle phase concerned with precise definition of the tasks to be performed by the system. File: fss1 Page: 2

3 Specifications are key to software documentation, software understanding and software adaptation Languages used for specifications Still the most frequent choice for specification languages in practice is natural language combined with informal graphical illustrations. However, for many aspects of system specification, there are wellestablished languages ( language meant as including graphical languages here). The most important examples are: functional aspect: global functional aspects: data flow diagrams, use case diagrams local functional aspects: "pseudo-code" structural aspect: class diagrams, entity-relationship diagrams, block diagrams, physical deployment diagrams dynamic aspect: state machines (with in/output) behavioural aspect: interface definition languages, sequence diagrams, process descriptions non-functional aspect: tables with measurable values development process aspect: workflow description formalisms These languages have gradually found their way into industrial development practice as part of so-called software development methods. The recently standardised Unified Modeling Language (UML) 2 contains well-defined diagrammatic notations for all aspects mentioned above. It is obvious that the functional aspect is not yet covered appropriately by the above-mentioned languages. Therefore, functional aspects are still mostly covered by natural language specifications, even where UML is in use. The next section illustrates some of the problems with specification of system functionality. 2 See G. Booch et al, The Unified Modeling Language. Online UML resource center: File: fss1 Page: 3

4 1.2 Specification Examples Natural language specification: The Seven Sins of the Specifier 3 The following example specification is a problem specification dealing with the functional aspect of a small system. It is taken from the literature and was prepared with special care for preciseness and completeness, as is proven by some history of attempts to properly specify the problem. Nevertheless, it shows clear deficiencies. Example 1: 4 The program s input is a stream of characters whose end is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as: break characters BL (blank) or NL (new line); nonbreak characters all others except ET; the end-of-text indicator ET. A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET. The program s output should be the same sequence of words as in the input, with the exception that an oversize word (i.e. a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e. a variable, Alarm, should have the value TRUE). Up to the point of an error, the program s output should have the following properties: 1. A new line should start only between words and at the beginning of the output text, if any. 2. A break in the input is reduced to a single break character in the output. 3 This section based on B. Meyer, On Formalism in Specifications. 4 J. Goodenough, S. Gerhart, Towards a theory of test: Data selection criteria, in Current Trends in Programming Methodology Vol. 2, T. Yeh (ed.), Prentice-Hall 1977, pp Cited according to B. Meyer. File: fss1 Page: 4

5 3. As many words as possible should be placed on each line (i. e. between successive NL characters). 4. No line may contain more than MAXPOS characters (words and BLs). B. Meyer identifies the following seven sins of the specifier : Noise (dt. Rauschen): Unnecessary text that diverts the attention of the reader. - Repetitions should not be avoided in specifications. Variant: Remorse (dt. Reue bzw. Nachtrag): Restrictions to a specification element are made where the element is used and not where it is defined. Silence (dt. Schweigen bzw. Auslassung): Omission of specification elements that are considered obvious by the specifier. Contradiction (dt. Widerspruch): Inconsistent statements made in the specification. Overspecification (dt. Überspezifikation): Description of a solution instead of pointing out the problem. - Error handling should not be described in detail in a functional specification. Ambiguity (dt. Mehrdeutigkeit): Statements that can be interpreted in several different ways. Forward reference (dt. Vorwärtsverweis): Usage of a concept before its proper definition. Wishful thinking (dt. Wunschdenken): Description of features in such a way that solutions cannot realistically be validated against the feature Mathematical formulation B. Meyer gives a precise mathematical specification of Example 1. Below some parts of the problem are reformulated to illustrate his way of specification. Example 1 (Meyer s version): Short breaks. Let a be a sequence of characters. We define SINGLE_BREAKS(a) as the set of subsequences of a such that no two consecutive characters are break characters. File: fss1 Page: 5

6 SINGLE_BREAKS(a) = def {s SUBSEQUENCE(a) i 2..length(s) s(i 1) BREAK_CHAR s(i) BREAK_CHAR} Next, we define COMPACTED(a) as the subset of SINGLE_BREAKS(a) containing those sequences of maximum length: COMPACTED(a) = def MAX_SET(SINGLE_BREAKS(a), length) (In a similar style, here follow definitions for the line length limitation, for the usage of a minimal number of lines and for the combination of the three conditions.) This style of definition achieves high precision, by applying mathematical thinking to software specification. However, readability and acceptance by the software engineering community are very poor Use case diagram When applying the diagrammatic notations of UML (or other software development methods) to Example 1, a rather trivial diagram is obtained like the following use-case diagram in UML: format text <<include>> <<include>> break lines fill lines reduce breaks <<include>> Motivation for formal specification languages The examples show an obvious gap in the description of functional properties of software systems. Formal specification languages intend to File: fss1 Page: 6

7 achieve the same level of precision as a purely mathematical approach, apply structuring concepts known from programming languages, make specifications machine-processable, keep the specifications as readable as possible. (But: Special education will always be required for dealing with highprecision specifications.) 1.3 Formality Definitions A typical definition of the term formal is something like: A method/language is formal if it has a sound mathematical basis. A more practical definition is derived from a philosophical idea from the 17 th century (G.W. Leibniz), with roots even in classical philosophy (Aristoteles). Leibniz formulated the vision that at some point in time there will be no need for philosophical disputes since philosophers simply could sit down and calculate which opinion is right. This applied formal logic idea is behind modern formal software specification languages. Definition: A language is called formal if it has a precisely defined semantics that relates the syntactical form of a specification in the language with a precisely defined semantic domain. A language is informal if it is not formal, i.e. if its semantics rely on human interpretation of the specifications, in particular on the chosen identifiers. A language is semi-formal if it contains formal as well as informal sublanguages or language layers. A good test for formality of a specification is to rename all identifiers to meaningless symbols like a and x, and to check whether the semantics is still equivalent. More precisely, a formal specification language is defined as follows 5 : 5 According to J. Wing, A specifier s introduction to formal methods. File: fss1 Page: 7

8 Definition A formal specification language is a triple <Syn, Sem, Sat> where Syn and Sem are sets and Sat Syn Sem is a relation between them. Syn is called the syntactic domain of the language, Sem is called its semantic domain and Sat is called its satisfaction relation. Typically, the syntactic domain of a formal specification language is defined in the same way as the syntax of a programming language, i.e. by a context-free grammar and context conditions. The ultimate semantic domain of software specification is, of course, the set of programs. This is appropriate for specifications to be applied on the level of fine-grain module and class design. However, for more abstract specifications, e.g. problem and requirement specifications, it is necessary to use more abstract concepts as semantic domains (e.g. algebras or set-theoretic models). These concepts introduce intermediate layers of abstraction between programs and specifications. Warning: Theoreticians and practicians have a completely different idea of formality. The above definition is the theoretician s view. For a practician, everything is formal which puts some restriction onto the form of the text being written Application areas for formal specification Some of the pioneers of formal specification claimed a revolutionary paradigm shift in software development from traditional informal development to tool-supported formal development. This has turned out as unrealistic but still there is some truth in this prediction. Software development for large systems does not use, and will not use for the foreseeable future, formal specifications as a complete replacement for other notations and development methods. However, the practically used specification languages show a clear trend towards higher formalisation, in order to enable better tool support. Moreover, there are a number of application areas where formal specification plays a very important role: Highly reliable systems for safety-critical applications Definition of standards File: fss1 Page: 8

9 Local enhancements of semi-formal specifications Contract-proof definition of black box software (componentware) Semantics definition for semi-formal specification languages Formal specification languages have had a rather slow (mathematics-like) evolution in the past. However, the convergence with practical engineering may lead to rather fast developments within the years to come. 1.4 Overview of Formal Specification Languages History of Software Specification Languages For a long period starting in the 1960s, many completely different and competing specification languages and development methods existed. Moreover, there was a clear separation between formal specification languages (research on which was mathematically oriented) and pragmatic software engineering methods (which were developed by industry consultants mainly). The most important steps of development in the area of formal specification were: C.A.R. Hoare writes on An Axiomatic Basis for Computer Programming 6 and Proof of Correctness of Data Representations 7, and describes the idea of specification of a program by its properties B. Liskov/S.N. Zilles 8 and J. Guttag 9 introduce the concept of an abstract data type E.W. Dijkstra defines the calculus of weakest preconditions Clear is described by R.Burstall and J. Goguen probably the first algebraic specification language. 6 Communications of the ACM Vol. 12, 1969, pp Acta Informatica Vol. 1, 1972, pp B. Liskov, S.N. Zilles, Specification Techniques for Data Abstractions, IEEE Transactions on Software Engineering Vol. 1, 1975, pp J. Guttag, The Specification and Application to Programming of Abstract Data Types, Ph.D. Thesis, University of Toronto, E.W. Dijkstra, A Discipline of Programming, Prentice-Hall File: fss1 Page: 9

10 1988 The algebraic specification language OBJ3 is developed at the SRI (Stanford) C. Jones defines VDM the Vienna Definition Method The Oxford Programming Research Group develops the Z specification language 13. A more programming-oriented variant of it called B 14 is developed with high industrial engagement (BP Laboratories) The algebraic specification language Larch 15 is developed at MIT and Digital SRC. since 1991 Development of object-oriented extensions of specification languages, e.g. Object-Z 16 and CafeOBJ Development of the "unifying" algebraic specification language CASL (Common Algebraic Specification Language) in the context of the European CoFI (Common Framework Initiative) project. Several separate lines of development are contained in this list, each of them again separated into different schools. Algebraic and axiomatic approaches (Clear, OBJ, Larch, CafeOBJ) Model-based approaches (VDM, Z, B) 11 J. Goguen (ed.), Algebraic Specification with OBJ, Cambridge University Press, to appear. 12 C. Jones, Systematic Software Development with VDM, Prentice.Hall 1986 (2 nd ed. 1990). 13 J. M. Spivey, The Z Notation A Reference Manual, Prentice-Hall 1988 (2 nd ed. 1992). 14 J.-R. Abrial, The B-Book, Cambridge University Press J. Guttag, J. Horning, Larch: languages and tools for formal specification, Springer S. Stepney, R. Barden, D. Cooper (eds.), Object-orientation in Z, Springer R. Diaconescu, K. Futatsugi, CafeOBJ Report, Wolrd Scientific File: fss1 Page: 10

11 Hoare logic Dijkstra calculus VDM Clear OBJ CafeOBJ Maude Abstract data types Larch CASL Z B Approaches for Concurrent/Reactive Systems For concurrent/reactive systems, even a greater wealth of notations was developed, starting from formalisms like CSP 18, CCS 19 and Petri nets. Unfortunately, the integration with specification languages for sequential systems is still rather limited. Examples for formal specification languages in this area are LOTOS, Esterel and RAISE C.A.R. Hoare, Communicating Sequential Processes, Prentice-Hall R. Milner, A calculus of communicating systems, Springer LNCS Vol. 92, An overview of the current state of the art including real-time extensions is given in G. Blair et al., Formal Specification of Distributed Multimedia Systems, UCL Press File: fss1 Page: 11

12 1.5 Reminder on Mathematical Notation In this section, some basic mathematical notation is recalled which is used at various places throughout this lecture. The purpose of this section is just to make clear the meaning of the formulae that are used at various places in this lecture Sets A set is a collection of elements such that for a given element and a given set it is possible to decide whether the element is contained in the set or not. Construction of a set by enumeration of its elements: BREAK_CHAR = def { BL, NL, TAB } DIGIT = def { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 } LETTER = def { A,..., Z, a,..., z } Membership predicate for an element of a set: BL BREAK_CHAR Construction of a set by set operations: ALFANUM = def LETTER DIGIT Construction of a set by set comprehension: ALFANUM = def { c c LETTER c DIGIT } Set comprehension over a given set: ALFANUM = def { c CHAR c LETTER c DIGIT } Side remark on mathematical background: Russell s paradox: X = def { S ALL_SETS S S } Question: Does X X hold? Construction of sets: Do not use the set of all sets! Set construction should always start from concrete given sets using a number of safe constructions, like power set, tuple, or sequence. File: fss1 Page: 12

13 The power set of a given set: P(S) = { T T S } Note the difference between x and {x}: x S and {x} P(S)! Example: DIGIT P(CHAR) Tuples and Sequences The Cartesian product of sets: S 1 S n = { (x 1,,x n) x 1 S 1 x n S n } Example: CODE = LETTER DIGIT The sequences over a given set: S * = { <x 1,,x n > x 1 S x n S n N } Example: input CHAR * Sequence as function: Let s S *, i.e. s = <x 1,,x n>. Then from s a function can be derived which is also called s: s: {1,,n} S s(i) = x i Example: WORD = def { s CHAR * ( i {1,,length(s)} s(i) ALFANUM) length(s) 0 } Relations and Functions A relation R between sets A and B is a subset of A B. The notation R(x,y) or x R y is used to denote (x, y) R. R is called a function if x A, y1 B, y2 B R(x,y1) R(x,y2) y1 = y2 A is called the from-set of R, B is called the to-set of R. The notation R: A B denotes that R is a function with from-set A and to-set B. File: fss1 Page: 13

14 A proper definition of a function or relation has to define the domain, the range and the relation between domain and range. Please note that this definition describes what is often called a partial function. It is allowed that for some elements of the from-set there is no value of the function. The term domain is often used to denote the elements of the from-set for which the function is defined (and analogously co-domain for the elements in the to-set). Unfortunately, in a part of the literature domain and co-domain are also used as synonyms for from-set and to-set (in the context of total functions). Examples: ISSORTED: N * B ISSORTED(s) = def i {2,,length(s)} s(i 1) < s(i) Let X be an arbitrary set. SUBSEQUENCE: X * P(X * ) SUBSEQUENCE(s) = def { t CHAR * <i 1,,i k > N * t = <s(i 1 ),,s(i k )> ISSORTED(<i 1,,i k >) } Sometimes it is useful to define functions that contain other functions in their domain or range. Example: MAX_SET: X (X N) P(X) MAX_SET(S,f) = def { x X x X f(x) f(x ) } Example The definitions from above give a complete explanation for the example from chapter 1: SINGLE_BREAKS: CHAR * P(CHAR * ) SINGLE_BREAKS(a) = def {s SUBSEQUENCE(a) i {2,...,length(s)} s(i 1) BREAK_CHAR s(i) BREAK_CHAR} File: fss1 Page: 14

15 COMPACTED: CHAR * P(CHAR * ) COMPACTED(a) = def MAX_SET(SINGLE_BREAKS(a), length) File: fss1 Page: 15