Software Specification Methods

p

o

c

act1

to receiveA(a,p)

inv

p

to be collected

(a) The Action to invoice

a

invoiced

act4

p.ref == a

to invoice(o,inv,p)) o

a

c

(o.product == p) & (o.qtity <= p.amount)

warehouse

stock

(b) The Action to receiveA

cancel request

ready

c

cr

act3

infOrd c

cr.id == o to cancel(cr,o) o

!

to receiveO(infOrd,o)

o

o

pending

deleted

(c) The Action to cancel

(d) The Action to receiveO

Figure 18.5: The nets showing the enabling and resulting states of each action To give an overview of the semantics of such a net, let’s consider the net of Action act1 (Clerk, to invoice, {Order, Invoice, Product}), Figure 18.5(a). Each place of the net corresponds to a state variable and its value is the set of instances that are in this very state. This set is called the marking of the place, and its element, called tokens, are instances of the place’s type. A marking of the net is

Petri Nets with Objects

343

the marking of all places. So, a marking of the considered net is a set of clerks in the place ready, a set of orders in the places pending, another one in the place invoiced, etc. Tokens remain in the same place until they are involved in a transition occurrence. The transition act1 may occur (or is enabled) under a marking of the net if: 1. there exists a binding of its variables with tokens such that the variable of each input arc is bound to a token lying in the corresponding place; and 2. this binding evaluates the guard of the transition to true. Thus act1 may occur under a marking including at least a clerk c in the place ready, an order o in the place pending and a product p in the place stock such that (o.product == p) & (o.qtity <= p.amount) holds. When act1 may occur, its occurrence (or firing) causes the execution of its body (an instance of the Operation to invoice) and also changes the marking of its surrounding places: tokens bound to input variables are removed from input places, and tokens bound to output variables are put into output places; an output variable that does not appear on any input arc is assumed to be bound to a “new“ instance that appears in no token of the marking. Thus, the occurrence of act1 moves o from the pending place to the invoiced place, put a new invoice into the to be collected place, and changes the value of p by means of its function takeout. If the marking of the net makes it possible to build several bindings that involve distinct tokens, act1 may occur concurrently more that once, one time for each binding. For instance, if the places ready, pending and stock contain enough tokens to have four bindings that evaluate the guard of act1 to true, four occurrences of this transition may take place simultaneously. The same holds for bindings concerning other transitions. Now, we need information on the Action instances that may occur concurrently and on the non-determinism of the system. Question 16: What about the concurrency constraints? Answer: A clerk performs only one action at a time, he cannot concurrently perform several actions. Of course, clerks do not work in turn: different clerks can simultaneously take part to different Action instances. An Entity instance can be involved in only one action at a time; as a consequence, an order cannot be concurrently invoiced and cancelled, two orders that refer to the same product cannot be concurrently ordered, and a product cannot be involved in concurrent occurrences of to invoice and to receiveA. But different Entity instances can take part to concurrent Action instances. As for Operations, there is no additional constraint: if the above constraints are satisfied, any Operation may occur concurrently with others and with itself. Question 17: When two actions can both occur but cannot occur concurrently (for instance, because they involve the same clerk or the same product), what are the priority rules which decide which action will occur first?

344

Software Specification Methods

Answer: Actions involving the Operation to cancel have a higher priority than the other Actions. When two pending orders referring to the same product may be invoiced, the order that is arrived first is invoiced first. These rules do not solve all conflicts, so the system features some amount of non-determinism that is solved by the choices of clerks.

cancel request cr

act3

deleted

o

cr.id == o

receivedA

c

to cancel(cr,o)

receivedO o

a infOrd

act2

c

c

to receiveO(infOrd,o)

act4

p.ref == a to receiveA(a,p)

o

ready pending

a

p

stock

o

c

p

act1

warehouse

(o.product == p) & (o.qtity <= p.amount) to invoice(o,inv,p)) o

inv

invoiced

to be collected

Figure 18.6: The activity net of clerks (case 2) Several nets may be combined into a single one, by merging either places or transitions. In the first case, a place of a net is merged with a place of another net, or with several such places. In the second case, transitions of the nets are merged [HUB 90]. We are now provided with all the information allowing formalizing, in the net of Figure 18.6, the activity of clerks. This net is obtained by merging the nets of the Actions (Figure 18.5) through their common places. In order to account for the communications between a net and its environment, it is possible to distinguish entry places and result places. Entry places are input communication channels intended to receive tokens from the environment of the net and have only output transitions. Conversely, result places are output communication

Petri Nets with Objects

345

channels intended to supply tokens to the environment and have only input transitions. Here, places receivedO, cancel request and receivedA are entry places enabling clerks to receive entities from customers and suppliers (this fact results from the answer to the first question), while there is no result place. At the initial marking, places ready, stock and warehouse respectively contain the actual clerks, products and articles of the company. According to the statement of the case, an order is never rejected; if the ordered product is not in stock, or if the ordered quantity is greater than the amount of the ordered product, the order is delayed as long as this situation holds. According to concurrency constraints, several orders may be invoiced concurrently provided that they do not reference the same product, the to invoice and to receiveA Operations cannot occur concurrently for the same product. The priority rules are ensured by the following properties that do not appear on the graphical representation of Figure 18.6: the transition corresponding to Action act3 has a higher priority – the other transitions cannot occur if it is enabled; the set of orders in place pending is ranked as a queue – the first arrived order is invoiced or cancelled first, if possible. When a system includes several Actor types, their Activity nets are composed by merging their common entry and result places (asynchronous communication) or their common transition (synchronous communication). This results in a net describing the Control Structure of the whole system. The analysis techniques of the Petri net theory [MUR 89] may be applied either on the activity net of an Actor or on the net of the whole system. As an example, analyzing the flow of tokens checks that: • • • •

the clerks are steadily in the ready state; the products are steadily in the stock state; the articles are in the receivedA or warehouse states; an informalOrder in the state receivedO gives raise either to a deleted order, or to an invoiced order and a to be collected invoice.

To analyse the actions that may occur within a net, its entry and exit places have to be avoided. Then it is possible to compute the sequences of sets of actions that may occur, the actions that constitute a loop, the possibility of deadlocks, and so on.

18.10 Natural language description of the specifications The purpose of our conceptual framework is to structure the informal description of a system, and the questions are just the ones which make it possible to obtain such a description. As a consequence, the natural language description of the case comes down to the concatenation of the answers to the questions. As for the formal model, it mainly comes down to Figures 18.2 and 18.5(a) for Case 1, and to Figures 18.2 and 18.6 and Answer 10.2 for Case 2.

346

Software Specification Methods

18.11 Comments about our treatment of the case study This chapter shows how to model a simple case study using the Petri Net with Object formalism within a conceptual framework to guide the modeling process. The considered case study is very simple. Thus, it cannot show to what extent this approach make it possible to master the complexity of real systems, whereas issuing tractable and understandable models of complex systems is an essential challenge. In addition, the simplicity of the case enables the illustration of only a part of the expressive power of the formalism. The other drawback of the case is that it is not a system, while our approach is intended to cope with realistic systems that counterbalance their in-flows and out-flows. For instance, the company would have to send the invoices, to deliver the ordered articles, to collect the customers’ payments, and so on. Consequently, the consistency of the company’s behavior cannot be validated using the analysis techniques of Petri nets. In addition, no attention is paid to the organizational structure of the company, so that the interactions among the Actor instances are very poor. On the other hand, this case study is appropriate to show some essential features of the approach. With regard to the conceptual framework, we have shown that it provides the domain specialists and the modelers with a shared language, and that it defines a standard pattern for the informal description of systems. With regard to Petri Net with Objects, we have shown that this formalism allows drawing simple models of simple systems. The questions raised by the formalism specialists are not grounded upon technical considerations related to the formalism, but on the common conceptual framework. Thus, the domain specialist is only required to reply to questions that are of his concern – the knowledge of the system – and he is not consulted for issues that are a matter for the formalism specialist. Both the domain and the formalism specialists contribute to work out the model within their scope of competence. This drastically increases the reliability of their respective contribution. The conceptual and formal models are very close to each other, so that the modeler encounters no cognitive difficulty to build a mental representation of the system. In addition, these series of questions are not specific to the system under consideration and follow a standard pattern determined by the conceptual framework (for the importance of standards in Software Engineering, see e.g. [GHE 91]). These series of questions have to be viewed as a standard outline for presenting the informal description of a system and not as the copying out of the talk between the domain specialist and the modeler. These series are not the script of the questions actually raised by the modeler in order to gain the information he needs about the system. They are only the report of their conversation. First, the detail of the actual dialogue is of no interest, since it depends on characteristics of the involved peoples such as their ability to clearly express their thought, their experience in modeling, and so on. Second, it is unlikely that the domain specialist is able to provide right away a complete and unambiguous answer to each question. It is more likely that during

Petri Nets with Objects

347

the modeling process he refines his answers as he improves his understanding of the system. The order according to which the questions are introduced in this chapter – the system’s interface, the identification of the types, the Entities, the Operations, the Actors and the Control Structure – does not correspond to a strict sequence of modeling steps. The Petri Net with Objects formalism is a notation, not a methodology. Nevertheless, each question corresponds to a task that has to be done during any modeling process, and the order of questions is not arbitrary. In any case, the issues concerning the system’s interface deserve special attention; they are of great importance, because the interaction of a system with its environment most often partly determines its structure and its behavior. The avoidance of forward references in the presentation requires that the identification of the Operation, Actor and Entity types come before their detailed study, and that the components of Actions are well defined before the description of the Control Structure. As for the questions about Entities, Operations and Actors, they may be introduced in any order. Finally, we would stress the relevance of Petri nets to deal with the behavioral aspect of systems. To justify this claim, we will have a look at other ways to use it. First of all, let’s consider the activity net of Figure 18.6: removing all places but the ready one results in the Task net of Figure 18.4, and removing transition act4 and all places that have not the type order results in the life cycle net of Figure 18.3. Thus, these three behavioral structures are closely related: life cycles and task nets are the projection of the system’s Control Structure on the Entities and the Actors respectively. In order to break down the Control Structure of the system, we have made the choice to associate to each Actor the part of the Control Structure concerning the Action it performs. Doing so, Actors have been emphasized, because they are responsible for triggering the Action occurrences, and play a role that Entities are denied. Another way to build the Petri net model of the Control Structure of a system is to start from the life cycle nets of Entities and to compose them. To this end, these nets are combined by merging the transitions corresponding to the same Action, after an eventual renaming of variables labeling the arcs. The resulting net is the same than the one obtained by composing the activity nets of Actors. Yet another solution to build the Petri net of the Control Structure is to consider the Procedures, or Use Cases [FOW 97], since the activity of a system may often be breakdown into procedures. As an example, the Operations to receiveO, to cancel and to invoice of our company are certainly steps of a procedure process order, which starts upon the arrival of an informalOrder and terminates when either the order has been cancelled or the ordered articles have been delivered and paid by the customer. Thus, it is possible to break down the Control Structure of a system by drawing, for each procedure, one net that describes the part of the Control Structure concerning the Actions of this procedure. The Control Structure of the whole system is then obtained by composing these procedure nets through the fusion of their common places. Again, the resulting net is the same as the one obtained by

348

Software Specification Methods

the two other ways. Thus, the Control Structure of a system may be obtained by focusing the modeling process either on Actors, on Entities or on Use Cases, according to the most problematic features of the system under consideration. For instance, it is relevant to draw the nets of the procedures in order to highlight how the system elaborates replies for environment’s requests. This also makes it possible to mix these strategies, or to use them concurrently and then to verify that they lead the same model. Of course, procedure nets and actor behaviors are tightly related and the ones stem from the others, even when procedures involve several actors or an actors participate to several procedures. As a conclusion, we have proposed a conceptual framework allowing designers to decide what are the relevant questions according to the characteristics of the case under consideration. Such a framework is usable as a map, making designers aware of the ways coming to the desired model of the system, so that they can choose the modeling process which is the most appropriate. We believe that any modeling approach needs such a conceptual framework to become mature, and that the one proposed in this chapter is general enough to improve the practice of many formal description techniques. Bibliography [CHI 91] Chiola G., Dutheillet C., Franceschinis G., Haddad S. “On Well-Formed coloured Nets and their Symbolic Reachability Graph”. In: Rozenberg G. (Ed.) Advances in Petri Nets 91, Lecture Notes in Computer Science Vol. 524, Springer-Verlag, 1991 [FOW 97] Fowler M., Scott K. UML Distilled, Applying the Standard Object Modelling Language. Addison-Wesley, 1997 [GEN 81] Genrich H., Lautenbach K. “System Modelling with High Level Petri Nets”. Theoretical Computer Science 13, North-Holland, 1981 [GHE 91] Ghezzi C., Jazayeri M., Mandrioli D. Fundamentals of Software Engineering. Prentice-Hall, 1991 [HUB 90] Huber P., Jensen K., Shapiro R.M. “Hierarchies in Coloured Petri Nets”. In: Application and Theory of Petri Nets 1990, Lecture Notes in Computer Science Vol. 483, Springer-Verlag, 1990 [JEN 87] Jensen K. “Coloured Petri Nets”. In: Brauer W., Reisig W., Rozenberg G. (Eds.) Petri Nets: Applications and Relationships to Other Models of Concurrency Part I, Lecture Notes in Computer Science Vol. 254, Springer-Verlag, 1987 [MUR 89] Murata T. “Petri Nets: Properties, Analysis and Applications”. Proc. of the IEEE, 77(4):541–580, 1989 [REI 85] Reisig W. “Petri Nets with Individual Tokens”. Theoretical Computer Science 41:185–213, North-Holland, 1985 [SIB 85] Sibertin-Blanc C. “High Level Petri Nets with Data Structure”. In: Proceedings of the 6th European Workshop on Application and Theory of Petri Nets, Espoo, Finland, June 1985

Petri Nets with Objects

349

[SIB 91] Sibertin-Blanc C. “Cooperative Objects for the Conceptual Modeling of Organizational Information Systems”. In: Van Assche F., Moulin B., Rolland C. (Eds) Proceedings of the IFIP TC8 Conference on The Object-Oriented Approach in Information Systems, North-Holland, Qu´ebec, October 1991 [SIB 00] Sibertin-Blanc C. “Cooperative Objects: Principles, Use and Implementation”. In: Agha G., De Cindio F. (Eds.) Petri Nets and Object Orientation, Lectures Notes in Computer Science vol 2001, Springer-Verlag, 2000 [SIB 05] Sibertin-Blanc C. “The EPO+CS formalism for conceptual modeling”. 6th Systems Science European Congress, 19-22 September 2005, Paris. [YOU 89] Yourdon E., Constantine L. Structured Design: Fundamental of a Discipline of Program and Systems Design. Prentice Hall, 1989

This page intentionally left blank

Part IV

Comparison and Glossary

This page intentionally left blank

Chapter 19 A Comparison of the Specification Methods

Marc F RAPPIER, Henri H ABRIAS and Pascal P OIZAT

In this chapter, our goal is to provide a qualitative comparison of the specification methods introduced in this book. Our intention is not to rank methods in terms of quality or productivity. It would require a much larger sample of specifications, developed within a controlled experiment, to reach valid conclusions about quality or productivity. We have selected a set of attributes which describe several properties of specification methods. The definitions of these attributes are provided in the first section. In the second section, attributes are evaluated for each method; the results are described in a set of tables. The reader may then compare methods by comparing the values of their attributes. 19.1 Attributes of specification methods Table 19.1 enumerates the attributes and their possible values. Attributes are then defined and illustrated with simple examples. 19.1.1 Paradigm This attribute characterizes how the specification notation describes the system behavior. We identified four general paradigms: state machine, algebra, process algebra and logic. To illustrate this attribute, we have chosen a very simple system, a latch (i.e., a Boolean device), for which example specifications are provided. A latch has three operations: reset, which sets the latch to zero; f lip, which changes the internal state of the latch; and valueOf , which returns the internal state of the latch.

State machine : The specification describes a transition relation on a set of states. Transitions are labeled by events. The transition relation may take several

354

Software Specification Methods

No. 1 2 3 4 5 6 7 8 9 10 11 12

Attribute paradigm formality graphical representation object-oriented concurrency executability usage of variables non-determinism logic provability model checking event inhibition

Values algebra, logic, process algebra, state machine, informal, semi-formal, formal yes, no yes, no yes, no yes, no yes, no yes, no yes, no yes [tool], no yes [tool], no yes, no

Table 19.1: List of specification method attributes forms. The set of states can be enumerated (as in an automaton) or it can be described by a set of variables with their possible values. Example 1: A Mealy finite state machine [CAS 99] is based on set enumeration. In the example below, the symbol λ can be interpreted in a number of ways, including that the output is a don’t-care value, a mute message, or the absence of output. Inputs = {reset, f lip, valueOf } Outputs = {0, 1, λ} States = {zero, one} Initial State = zero Transition Function = { (zero, reset) 7→ zero, (zero, f lip) 7→ one, (zero, valueOf ) 7→ zero, (one, reset) 7→ zero, (one, f lip) 7→ zero, (one, valueOf ) 7→ one } Output Function = { (zero, reset) 7→ λ, (zero, f lip) 7→ λ, (zero, valueOf ) 7→ 0, (one, reset) 7→ λ, (one, f lip) 7→ λ, (one, valueOf ) 7→ 1 } Example 2: State machine based on state variables.

A Comparison of the Specification Methods

355

List of operations : reset, flip, valueOf List of variables : s of type Boolean Initialisation of variables : s := 0 Definition of operations ∆ reset = s := 0 ∆ flip = if s = 0 then s := 1 else s := 0 ∆ valueOf = return s

Algebra: The specification describes a set of operations defined on a set of types (also called sorts or carrier sets) [WIR 90]. An event is represented by a function (also called an operation). The behavior of functions is given by a set of equations (axioms) stating how functions are related: Example 3: Algebraic specification of a latch. Sorts : Latch, N at Signatures of functions : zero : a constant of sort Latch reset : a function from Latch to Latch f lip : a function from Latch to Latch valueOf : a function from Latch to N at 0 : a constant of sort N at 1 : a constant of sort N at Axioms for all x of sort Latch reset(x) = zero f lip(f lip(x)) = x valueOf (zero) = 0 valueOf (f lip(zero)) = 1

Process algebra: It is a special kind of algebra. Its operations are applied to elementary processes and events to describe how events may occur. Example 4: Process algebraic specification of a latch using the CSP notation [HOA 85]. List of events (alphabet) : reset, f lip, valueOf , 0, 1 Definitions of processes ∆ LAT CH = ZERO ∆ ZERO = (reset → ZERO | f lip → ON E | valueOf → 0 → ZERO) ∆ ON E = (reset → ZERO | f lip → ZERO | valueOf → 1 → ON E)

356

Software Specification Methods

Logic: The specification consists essentially of a set of formulas expressed in some particular logic (e.g., first-order logic, higher-order logic like COQ, ELF, HOL, ISABELLE, PVS). Some formalisms, like COQ, also support a notion of computation using λ-calculus. It should not be confused with the use of formulas within a particular notation. For instance, the invariant of a B specification is given by a first-order formula, but a B specification is not just a set of formulas; it also includes operations, which are not formulas (but they may also include formulas). The logic paradigm is a very general one; it can be used to encode state transitions, algebras and process algebras. Note that the paradigm attribute should not be confused with the semantics of a notation. The semantics of a notation is concerned with the meaning of specification texts. For instance, the meaning of an operation in the B notation can be described using a set of axioms relating the precondition and the postcondition of an operation. This style of semantics is called a weakest precondition semantics [DIJ 76]. Another style is to associate a mathematical object to each specification text. For instance, the semantics of a B operation can also be given by a pair (D, R), where D is the set of initial states for which the operation terminates and R is the set of pairs (s, s′ ) such that the operation started in s may terminate in s′ . 19.1.2 Formality This attribute characterizes the syntax and the semantics of the notation. It has three possible values.

Informal: the syntax is not formally specified. Typically, the specification is given in natural language. Semi-formal: the syntax of the notation is formally specified, but it does not have a formal semantics. Example 5: A data flow diagram used in SAZ [POL 00] includes processes, arrows, data stores and external entities. There are precise rules describing how these elements can be combined. For instance, an arrow must have a source and a destination. The source and the destination must be a process, a data store or an external entity. The notation does not have a formal semantics. For instance, there are no rules to determine if two diagrams are equivalent (aside from being syntactically identical), or if an implementation satisfies a data flow diagram.

Formal: the syntax of the notation is formally specified, and it has a formal semantics. Example 6: An operation in the B notation [ABR 96] has a weakest precondition semantics. It is possible to determine (prove) that two operations are equivalent, or that an implementation satisfies a specification.

A Comparison of the Specification Methods

357

19.1.3 Graphical representation This attributes determines if the notation includes a graphical representation (e.g., pictures, diagrams, graphs). It has two possible values: yes or no. 19.1.4 Object oriented This attributes determines if the notation uses the following concepts: inheritance, class, polymorphism and encapsulation [MEY 97]. It has two possible values: yes or no. 19.1.5 Concurrency A notation allows the modeling of concurrency if a system can be described in terms of processes which may communicate. It has two possible values: yes or no. Example 7: CSP allows the modeling of concurrency. The system P || Q is made of processes P and Q. 19.1.6 Executability This attribute determines if the specification can be executed to simulate the system behavior. Note that specifications can be non-deterministic. In such a case, the interpreter either computes the set of possible outcomes and asks the users to pick one, or it picks an outcome in a random manner. Note also that an interpreter (animator) does not need to be efficient. This attribute has two possible values: yes or no. 19.1.7 Usage of variables This attribute determines if variables can be used to denote values in the system. It has two possible values: yes or no. The use of variables fosters abstraction, because it avoids the enumeration of all possible values. Example 8: Examples 3 and 2 use variables. CSP [HOA 85] allows variables, but we have not used any in Example 4. A Mealy state machine (Example 1) does not allow variables. 19.1.8 Non-determinism This attribute determines if the notation allows non-determinism. It has two possible values.

yes: a specification may offer a choice between several outcomes for a computation.

358

Software Specification Methods Example 9: Consider the specification of a machine that must change a dollar for a set of coins. The specification may leave the choice of the algorithm for the selection of the set of coins to be made at the design stage. The specification may look like this: let C be a set of coins returned by the machine. X valueOf (c) = 1 c∈C

no: a specification is always deterministic. 19.1.9 Logic This attributes determines if the notation includes some first-order (or higher-order) logic notation. Logic is useful to express properties in an abstract manner. This attribute has two possible values: yes and no. Note that a notation may not include logic, but its semantics may be defined in some logic. Example 10: CCS [MIL 89] does not include a logic notation. However, its semantics is defined in terms of a set of inference rules expressed in a logic notation. There is also a logic for reasoning about the equivalence of CCS specifications, or proving properties about CCS specifications. Example 11: B includes a logic notation; hence the value of attribute logic for B is yes. 19.1.10 Provability This attributes determines if properties about the specification can be proved using a formal proof system. It has two possible values: yes and no. When the method is supported by a tool, the word “tool” is added. Example 12: In the latch specification of example 3, one may prove that: valueOf (f lip(reset(x))) = 1 19.1.11 Model checking This attributes determines if properties about the specification can be checked by enumeration of the system states. It has two possible values: yes and no. When the method is supported by a tool, the word “tool” is added. 19.1.12 Event inhibition An event is the execution of an operation (or an action). A system is said to allow the inhibition of events if the set of operations it offers to the environment may vary over time. If several operations are offered, the environment picks one of them (external

A Comparison of the Specification Methods

359

non-determinism) and the operation is executed (i.e., the event occurs). If two events are independent (i.e., they do not share variables), they can be executed in parallel. It has three values: yes, no and N/A (not applicable, when there is no native notion of event in the method). Example 13: The B notation as defined in [ABR 96] does not allow event inhibition. All operations of a B machine are always offered to (or can be invoked by) the environment. If an operation is invoked, it may either terminate or fail. Example 14: A Mealy machine (see [CAS 99]) does not allow event inhibition. Its transition function and its output function must be total; hence, it always offers all its operations to the environment. Example 15: Process algebras, action systems [BAC 83] and the extension of the B notation as defined in [ABR 98, BUT 96] allow event inhibition. 19.2 A qualitative description of the methods Tables 19.2, 19.3, and 19.4 provide a description of each method with respect to the attributes defined in the previous section. Note that these tables refers to the methods as they are described in the book; they do not consider their various extensions. Bibliography [ABR 96] Abrial, J.-R.: The B-Book, Cambridge University Press, 1996. [ABR 98] Abrial, J.-R., Mussat, L.: “Introducing Dynamic Constraints in B”, in B’99: Recent Advances in the Development and Use of the B Method, Bert, D. (Ed.), LNCS 1393, Springer-Verlag, 1998, 83–128. [BAC 83] Back, R. J. R., Kurki-Suonio, R: “Decentralization of process nets with centralized control”, in 2nd ACM SIGACT-SIGOPS Symp. on Principles of Distributed Computing, Montr´eal, Qu´ebec, Canada, 1983, 131–142. [BOO 94] Booch., G.: Object-Oriented Analysis and Design with Applications, 2nd edition, Benjamin-Cummings, 1994. [BUT 96] Butler, M., Wald´en, M.: “Distributed System Development in B”, in First Conference on the B Method, Habrias, H. (Ed.), Institut de Recherche en Informatique de Nantes, Nantes, France, 1996, 155-168. [CAS 99] Cassandras C.G., Lafortune S.: Introduction to Discrete Event Systems, Kluwer Academic Publishers, 1999,97–100 [DIJ 76] Dijkstra, E.W.: A Discipline of Programming, Prentice Hall, 1976. [HOA 85] Hoare, C.A.R.: Communicating Sequential Process, Prentice Hall, 1985. [MEY 97] Meyer, B.: Object-Oriented Sotware Construction, Second Edition, Prentice Hall, 1997. [MIL 89] Milner, R.: Communication and Concurrency, Prentice Hall, 1989. [MOR 90] Morgan, C.: Programming from Specifications, Prentice Hall, 1990.

360

Software Specification Methods

[POL 00] Polack F.: SAZ: “SSADM”, in this book. [WAL 98] Wald´en M.: “Layering Distributed Algorithmes within the B Method”, in B’98: Recent Advances in the Develpment and Use of the B Method,LNCS 1393, Bert, D. (Ed.), LNCS 1393, Springer-Verlag, 1998, 244–250. [WIR 90] Wirsing: “Algebraic Specification”, in Handbook of Theretical Computer Science, Vol. B , van Leewen, J. (Ed.), Elsevier, 1990,675–788. [YOU 89] Yourdon, E.: Modern Structured Analysis, Yourdon Press, 1989.

A Comparison of the Specification Methods

method name

paradigm

formality

Action Systems ASM

state transition state transition state transition state transition algebra logic process algebra state transition process algebra state transition state transition state transition state transition state transition state transition state transition state transition

B Event B CASL COQ EB3 Estelle (e-)LOTOS Petri Nets with Objects SAZ SDL TLA+ UML-B UML-Z VHDL Z

objectoriented

formal

graphical representation no

formal

yes

yes

formal

no

no

formal

no

no

formal formal formal

no no yes

no no no

formal

no

no

formal

no

yes

formal

yes

yes

formal

yes

yes

formal

yes

yes

formal

no

no

formal

yes

yes

formal

yes

yes

semiformal formal

no

no

no

no

no

Table 19.2: List of specification method attributes – Part 1

361

362

Software Specification Methods

method name Action Systems ASM B Event B CASL COQ EB3 Estelle LOTOS Petri Nets Petri Nets with Objects SAZ SDL TLA+ UML-B UML-Z VHDL Z

concurrency

executability

non-determinism

yes

usage of variables yes

yes yes no no no no yes yes yes yes yes

yes yes yes yes yes yes yes yes yes yes

yes yes yes yes yes yes yes yes no yes

yes yes yes yes yes yes yes yes yes yes

no yes yes yes no yes no

yes yes no yes no yes yes

yes yes yes yes yes yes yes

yes yes yes yes yes no yes

Table 19.3: List of specification method attributes – Part 2

yes

A Comparison of the Specification Methods

method name Action Systems ASM B Event B CASL COQ EB3 Estelle (e-)LOTOS Petri Nets Petri Nets with Objects SAZ SDL TLA+ UML-B UML-Z VHDL Z

logic

provability yes

model checking yes

event inhibition yes

yes yes yes yes yes yes yes no yes no no

yes, tool yes, tool yes, tool yes, tool yes, tool yes yes no no no

yes, tool yes yes no no yes yes yes, tool yes, tool yes

yes no yes N/A N/A no yes yes yes yes

yes yes yes yes yes no yes

yes, tool yes yes yes, tool yes, tool yes yes, tool

yes yes yes, tool yes yes yes yes

no yes yes no no no no

Table 19.4: List of specification method attributes – Part 3

363

This page intentionally left blank

Chapter 20 Glossary

Henri H ABRIAS, Pascal P OIZAT and Marc F RAPPIER

“The difficulty is that the graphical notation itself is perfectly clear, but the meaning of boxes and diamonds and lines is very obscure and uncertain.” M. Jackson [JAC 95] This glossary covers the most important concepts used by the chapters of the book, with which the authors assume familiarity. We have focused on the meanings of their contextual usage. Consequently, our definitions may not cover all generally accepted meanings of a given concept. Mathematical symbols U

Used, for instance in Z, to denote distributed bag union.

⊑ Used, for instance in Z, to denote bag inclusion. ⊥ (bottom) The least element in a lattice. Also used to denote the undefined element. It is a way to totalize functions: the domain of the function is extended with a special element, written ⊥. [] Used to denote the choice. Notation invented by Dijkstra. = b Used to denote definition (for instance in B).

== Used to denote definition (for instance in Z) or equality within algebraic specifications axioms. def

= Used to denote definition (for instance in CCS).

366

Software Specification Methods

∆

= Used to denote definition in VDM. ǫ Used to denote an unobservable event that does not change the state of a system and the empty string in regular expressions. See Stuttering 3 Used to denote finally (eventually) in temporal logic. 2 Used to denote globally (always) in temporal logic. 7→ (maplet) Used to denote an ordered pair as in P aris 7→ F rance. This is also written as (P aris, F rance). |=M Consider a family of formulas T on a first order language L. An interpretation M is a model of T , written |=M T if M is a model for every formula of T . See Satisfiability N1 Used to denote the set of natural numbers without 0. <+ Used to denote overriding in B. ⊕ Used to denote overriding in Z. |= Semantic turnstile. Used to express logical entailment, semantic entailment or semantic implication. By considering a closed formula P and a family Γ of closed formula, Γ |= P expresses that P is a semantic entailment of Γ, i.e., that every model of Γ is also a model of P . See Model ⊢ Syntactic turnstile. Used to express a relation of deductive consequence. Theorems are expressed as in the following example: ⊢ 5 > 0. [ ] Used in B to denote a sequence as in [P aris, Lyon, M arseille]. This is written in Z as < P aris, Lyon, M arseille >. \ Used (as in Z) to denote the substraction of sets. − is also used (as in B). Also used to denote hiding. Example: (a → P 1 [] b → P 2) \ {b} is the process (a → P 1 [] b → P 2) except that the b event is hidden. := Used to denote a substitution or an assignment.

Glossary

367

A Abstraction Process consisting of treating things that are different as if they were the same. Example: Hoare, Dijkstra, Milner are abstracted as professors, and professors are abstracted as being persons. Davis and Hersh [DAV 82] make a distinction between abstraction as idealization and abstraction as extraction. Example: • idealization: from the line drawn on a physical thing to the mathematical concept of line. In the end, we may lose or abandon all notions of what a straight line “really is”, and merely replace it (if we are at the level of axiomatics) with statements of how the straight line acts or combines. • extraction: from the K¨onigsberg map to the graph extracted by Euler. Abuse of notation “In mathematics, abuse of notation occurs when an author uses a mathematical notation in a way that is not formally correct but that seems likely to simplify the exposition while being unlikely to introduce errors or cause confusion [WIK 05].” Example: In B, f (x) := 5 is an abuse of notation because f (x) is used here as a variable for a substitution. f (x) := 5 is an abbreviation for f := f <+{(x 7→ 5)}. Action 1. In action systems, an action consists of a guard and a command. The guard is a predicate describing the states in which the action may be executed. The command describes how the state changes when the action is executed. 2. In TLA+ , an action is true or false on a step, which is a pair of states – an old state, described by unprimed variables, and a new state, described by primed variables [LAM 94]. Example: x′ = x + 1 ∧ y ′ = y 3. An action is an output in an automaton. 4. In the UML state charts notation, an action can be associated to transitions, the entry in a state or the exit from a state.

368

Software Specification Methods See Agent, Automaton

Agent 1. In CCS, systems are modeled as algebraic expressions called agents. The events that a system can perform are modeled as actions of the agent. def

Example: A = in.out.0 defines an agent A which may engage in action in, then in action out and then stops (0 denotes the inactive agent). 2. In semi-formal methods such as UML, an agent is an actor outside the system. Agents are usually not modeled. Algebra A (single sorted) algebra consists of a set of values (called carrier set) and operations (including constants) over this set. Sorts correspond to type names. Algebras are the models of algebraic specifications, and algebraic specifications are a way to specify using signatures and axioms the properties of a system whose models will be algebras. Example: The naturals (N, integers greater than 0) with the 0, successor and + functions. Example: The naturals modulo n (example, naturals modulo 2) with the 0, +1 and + functions taking into account the modulo. See Algebraic semantics, Algebraic specification, Sort Algebraic semantics In algebraic semantics, we consider three concepts: the specification of an abstract type, the theory denoted by the specification, and the algebras that satisfy the theory. An algebra satisfies a theory if all equations in the theory hold in the algebra, after translating the operation symbols of the theory into the operations of the algebra. We also say that the algebra is a model for the theory [WAT 91]. This means that, given an algebraic specification, one can associate to it (as its semantics) the set of all models (algebras) satisfying the axioms. Example: To the following specification: sorts Nat opns 0 : → Nat succ : Nat → Nat + : Nat, Nat → Nat

Glossary

369

axioms for all x : Nat x+0 == x for all x : Nat, y : Nat succ(x)+y == succ(x+y) one can associate the two models (algebras) given in entry Algebra. See Algebra, Algebraic specification Algebraic specification An algebraic specification is made up of two parts: • a signature which defines sorts (types) and operations (functions and constants); • the properties of the operations using axioms. Algebraic specifications can be structured, importing simpler specifications (defining simpler sorts and operations in a simple specification which will be used in a structured one). Some algebraic specification languages also enable the definition of relations between sorts (subsorting). Example: /* Algebraic specification of a stack */ /* sorts */ import element, bool sorts stack /* operation */ opns empty : → stack push : stack, element → stack pop : stack → stack top : stack → element isEmpty : stack → bool /* axioms */ axioms isEmpty(empty) == true for all e : element, s : stack isEmpty(push(s,e)) == false // partial definition, pop(empty) is not defined forall e : element, s : stack pop(push(s,e)) == s

370

Software Specification Methods // partial definition, top(empty) is not defined forall e : element, s : stack top(push(s,e)) == e See Algebraic semantics, Axiom, Signature, Sort

Always See Globally Analysis 1. To split a totality into elements. Example: Lexical analysis is the process of taking an input string (a sequence) of characters and producing a sequence of symbols called lexical tokens. 2. Informal study of the requirements. 3. Analysis is opposed to Design. Note: there are no industry-wide accepted definitions for the terms “requirement”, “analysis”, or “design” in computing. See Structured analysis Animation of a specification Execution of a specification. Note: some authors consider that, by definition, a specification is not executable. See Execution Architectural description An architectural description is a high-level representation of the structure of a system or application. It describes the components that build this structure and their interrelations. See Architecture (Software) Architecture (Software) Level of software design where the structure and global properties of the system are described [GAR 95]. It focuses on those aspects of design and development that cannot be adequately addressed within the modules that form the system [SHA 96]. Asynchronous • “A complete asynchronous model is one with no concept of real time. It is assumed that messages are eventually delivered and processes eventually respond, but no assumption is made about how long it may take.” [LAM 90] • Systems have an asynchronous behavior if one component can do nothing while another changes state.

Glossary

371

• Parallelism is said to be synchronous when the system owns a global clock which, at regular time intervals, pilots the execution of the processes. On the other hand, parallelism is said to be asynchronous when each process can evolve with its own rythm but, to ensure global consistency, must synchronize with other when trying to access to shared resources. • Within concurrent object formalisms, communication among objects is performed through remote method invocation. This can be either blocking (synchronous) and the callee is put in a waiting state until the results of the method come back, or non-blocking (asynchronous) [GAR 03]. Attribute See Property Automaton An automaton is defined by a finite alphabet Σ, a finite set of states Q, an initial state q0 ∈ Q, and a transition function δ from Q × Σ to Q. It may also contain a set of final states F ⊆ Q. One can define automata with outputs. When the outputs are on the transitions, it is called a Moore automaton. When the outputs are on the states it is called a Mealy automaton. Note: the markings of a Petri nets are the states of an automaton. The firing of a transition of the Petri net may or may not produce a new marking that is or is not a new state of the automaton.

Automaton (Regular vs. Buchi) ¨ 1. A regular automaton accepts all the strings which yield a final state. 2. A B¨uchi automaton accepts all infinite strings which pass an infinite number of times by a final state. For any temporal logic formula, there is a B¨uchi automaton that accepts all strings which satisfy this formula. See Model checking Axiom A statement accepted without a formal proof. In an algebraic specification, the axioms are logical sentences describing the behavior of the operations by relating them with equations. Example: : pop(push(stack, el)) = el is an equation of a stack relating operations pop and push. See Algebraic specification Axiom of choice In the axiomatic set theory. Given any set S of mutually exclusive non-empty sets, there is at least one set that contains exactly one element in common with each of the non-empty sets. Intuitively speaking, the axiom of choice says that if you have a collection of bins, each containing at least one

372

Software Specification Methods object, then you can pick exactly one object from each bin and gather them all in another bin – even if there are infinitely many bins, and no “rule” telling you which object to pick from each. For finite sets, the axiom of choice follows from the other axioms of the set theory [WIK 05], [DEV 92].

Axiomatic semantics An axiomatic semantics consists of a set of algebraic laws (commutativity, associativity, . . .) enabling one to demonstrate terms equivalence [GAR 03]. See Operational semantics

B Bag (or multiset). A bag b of X is defined as: b ∈ X → 7 N1. A purse can be seen as a bag: purse ∈ COIN → 7 N1, purse = {(1euro, 3), (2euros, 1), (50cents, 2)}. Behavior • Description or specification of the authorized transformations of the system state, or of the sequences of events which the system may accept, produce or engage in. • “By a behavior, we mean an infinite sequence of states [LAM 94].” See Automaton, Event, Stuttering Bijection (or one-to-one correspondance) A bijection is a function that associates two sets in such a way that one and only one member of its range is paired with each member of its domain. A bijection is injective and surjective. The inverse of a bijection is a bijection. Represented by ֌ → (total bijection) and ֌ → 7 (partial bijection) in Z and B. See Injection, Surjection Bound variable A variable which is present in a predicate or an expression and not free. See Free variable Bubtangle “A rectangle with rounded corners. A bubtangle instantly combines the best characteristics of the circle and the rectangle. It is highly compatible and, crucially, doesn’t make the technological investment in the circle or rectangle obsolete. Moreover, it settles any argument as to whether to use a circle or rectangle, and lets analysis teams apply themselves to more important problems instead. It is about 75% a rectangle and about 50% a bubble, making a bubtangle worth roughly 125%. It is non-procedural, user-friendly and relational. It is compatible ADA [BOA].” See Entity-relationship (ER) diagram

Glossary

373

Buchi ¨ automaton See Automaton (Regular v.s. B¨uchi)

C Cardinality of a relationship Notation used in semi-formal methods to express constraints on a relation. These constraints can be described in mathematics by the terms: partial function, total function, injection, surjection, bijection, etc. The term multiplicity is also used. Example: Cardinalities are written 1 − 1, 1 − n, 0 − n, n − m in the Merise notation, or with ∗, 1 in class diagrams of the UML notation. For instance, a 1:1 relationship between a class A and a class B is a total bijective function from A to B. Carrier set See Algebra, Sort Channel A channel is an abstraction on which events or signals transit. In behavioral specification languages, the following terms are used as synonyms: gate (e.g., LOTOS), port (e.g., CCS). See Port Characteristic function The characteristic function of a subset s of a set S is the function with domain S, whose value is 1 at each point in s and 0 at each point that is in S but not in s. Clause 1. In logic and declarative programming (e.g., in the Prolog language), a Horn clause is a disjunction of literals and can be interpreted as a (conditional) statement. In classical logic, we can rewrite (p ∧ q ∧ . . . ∧ t) ⇒ u following the clause: (¬ p) ∨ (¬ q) ∨ . . . ∨ (¬ t) ∨ u. 2. Paragraph in a specification. Example: The specification of an abstract B machine has clauses such as: MACHINE, VARIABLES, INVARIANT. Clock See Simulation Closed formula A formula without free variable. A proposition is a closed formula without quantifiers. See Free variable Closed-system vs open-system specification • Closed-system specifications are specifications that are satisfied by all behaviors in which both the system and its environment perform correctly.

374

Software Specification Methods • Open-system specifications, also called rely/guarantee specifications, are specifications that are satisfied by all behaviors in which the system performs correctly as long as the environment does [LAM 88].

Command See Action, Dijkstra’s Guarded Command Language Completeness 1. An axiom set is said to be complete if it is not possible to add an independent axiom, that is, if all well-formed formulas either follow from or are inconsistent with the original set of axioms. 2. Completeness can be defined with some underlying domain that the axioms are intended to describe. If we have a model of the underlying domain, we can define completeness in terms of whether or not everything that is true in the model is provable from the axioms. 3. “A complete specification describes all relevant aspects of the behavior of a system [LIS 86].” 4. “A specification is complete if it captures all the user requirements. Completeness cannot be proved [MIL 94].” See G¨odel (First incompleteness theorem), Model Compositionality 1. This means that the meaning of the whole is a function of the meaning of the parts (Frege’ Principle). The meaning of a complex expression is fully determined by its structure and the meanings of its constituents. 2. Compositionality principle of G. Frege: If S(E) is a sentence containing an expression E, and S(E ′ ) is the same sentence but with E replaced by an expression E’ with the same meaning as E, then S(E) and S(E ′ ) must have the same truth value. The fact that it is possible to construct a specification, or a proof from other specifications or proofs. See Denotational semantics Concurrency 1. When two processes interact with each other [HOA 85]. 2. Systems “where there is more than one process existing at a time” [ROS 98]. 3. When multiple processes execute in parallel, share critical resources and synchronize.

Glossary

375

Note: concurrent and parallel are generally used as synonymous terms. Conditional correctness See Correctness Constructions (Calculus of) Variant of the type theory defined by Th. Coquant. Basis of the Coq theorem proving system. Constructor A constructor function is a member function of a class used to create an object instance of this class and possibly also populate some or all of that object instance’s attributes. For an abstract data type T , a constructor is a function for which T appears on the right side hand of the arrow. See Inductive type Correctness • Total correctness concerns necessity for a program, when started in an initial state satisfying a precondition, to establish the postcondition and to terminate. • Partial correctness concerns necessity for a program, when started in an initial state satisfying a precondition, to establish the postcondition should it terminate. “The statement that a program is ‘partially’ correct can be misleading, since it suggests that there is something wrong with the program. ‘Conditional correctness’ is the term introduced and favoured by C.A.R. Hoare (...) [BAC 03]” See Liveness, Safety property CTL* Computational tree logic (CTL*). A temporal logic which uses state operators which “select” states (N f – Next: f has to hold at the next state (this operator is sometimes noted X instead of N ), Gf – Globally: f has to hold on the entire subsequent path, F f – Finally: f eventually has to hold (somewhere on the subsequent path) and path operators which “select” paths, for instance: Af – All: f has to hold on all paths starting from the current state. Ef – Exists: there exists at least one path starting from the current state where f holds.

D Dataflow “Dataflow and data-driven are radical departures from the traditional approach based on the von Neumann or a control-driven computation model. In the von Neumann model, a piece of processor sequentially fetches instructions and data from memory for execution. In the dataflow execution model, a program is represented as a graph in which nodes can be viewed as virtual processors. They execute as soon as the input operands become available on the input edges. There is no concept of memory. The concept of memory in a

376

Software Specification Methods control-driven model introduces states in which every update of a memory location implies a state transition. This state-driven nature of the von Neumann model makes it a sequential model. In the data-driven model, a piece of data is not represented as a static entity (memory) whose value can be updated time after time. Instead, it is a dynamic entity that is produced once and consumed by another instruction (fine-grained dataflow) or by a set of instructions, i.e., by a program entity (coarse-grained dataflow) [GAN 96].”

Dataflow diagram A graphical representation used in semi-formal methods. It shows how data is processed. No formal semantics is given, although some have been proposed. Not to be confused with the dataflow paradigm of programming. See Dataflow Data model Notation (mostly graphical) used in semi-formal methods to express a state invariant. See Invariant Data type Set of objects together with a set of operations characterizing the behavior of the objects [LIS 86]. See Algebraic specification Deadlock A concurrent system is deadlocked if no component can make any progress, generally because each one is waiting for communication with the others [ROS 98]. Decidable A formal system is decidable when a procedure exists which answers yes if a conjecture is a theorem or else replies no. See Semi-decidable Defensive style vs. generous style In a defensive style of specifying/programming, the specifier/programmer protects his program from a bad usage by adding tests to take into account the cases where the main part of the program must not be executed. In other terms, the operations are defined to be total on their parameters. In a generous (or offensive) style of specifying/programming, the specifier/programmer considers that the preconditions of the operation has to be checked by the calling programs [ABR 96]. Definition A definition is a name given to a piece of specification. It is an abbreviation. To expand a definition is to replace the name by the piece of specification. The following symbols are used to denote a definition: == (in Z), = b (in B), def (in CCS). Denotation Following G. Frege, the expressions 7, seven, sept, 1111111, VII, 111, 21/3 have the same denotation. The morning star and the evening star denote

Glossary

377

the same planet, namely Venus, but express different senses. Example: “All the well-formed terms denote a “value” of a given sort” [BAU 06]. See Expression Denotational semantics The meaning is expressed in terms of a mathematical function from a notation to its denotation. “The denotational method defines each notation and formula of the language as denoting some value in a mathematical domain which is understood independently, say as a function, or as a set of trajectories, or in general as some kind of observation of the properties and behavior of the program when executed [HOA 98].” Example: A functional Java program denotes a mathematical function from initial program state and program inputs to final program state and program outputs. Example: A terminating Java program denotes a mathematical function from initial program state and program inputs to final program state and program outputs. A non-terminating Java program denotes a set of trajectories, each trajectory being a sequence of program states. Description A description is a statement of some of the actual attributes of a product, or a set of products. A description is a predicate on observable attributes of a product. A description may include attributes that are not required. Example: A description of the 747 aircraft would tell us that it has a funny looking bump on top at the front [HIN 95]. Design The transformation of a specification into an executable implementation. Example: To decide to use a file instead of an array to implement a set is a design decision. Deterministic A system is deterministic if its next state depends only on the current input and the current state, and the next output depends only on the current state. See Interactive system Dijkstra’s Guarded Command Language GCL has been defined by E. W. Dijkstra for Predicate transformer semantics. “The BNF has been extended. {. . .} should be read as ‘followed by zero or more instances of the enclosed’.” <statement> ::= | | ‘‘other statements’’

378

Software Specification Methods ::= if fi :: = do od ::= { [] } ::= → ::= ::= <statement> {; <statement> } The semicolons in the guarded list have the usual meaning: when the guarded list is selected for execution, its statements will be executed successively in the order from left to right; a guarded list will only be selected for execution in a state such that its guard is true. Note that a guarded command by itself is not a statement: it is a component of a guarded command set from which statements can be constructed. If the guarded command set consists of more than one guarded command, they are mutually separated by the separator []; our text is then an arbitrarily ordered enumeration of an unordered set; i.e., the order in which the guarded commands of a set appear in our text is semantically irrelevant. Our syntax gives two ways of construction a statement out of a guarded command set. The alternative construct is written by enclosing it by the special bracket pair if . . . fi. If in the initial state, none of the guards is true, the program will abort; otherwise, an arbitrary guarded list with a true guard will be selected for execution. Note: if the empty guarded command set were allowed if fi would be semantically equivalent to ‘abort’. (End of note.) (. . . ) The repetitive construct is written down by enclosing a guarded command set by the special bracket pair do . . . od. Here a state in which none of the guards is true will not lead to abortion but to proper termination; the complementary rule, however, is that it will only terminate in a state in which none of the guards is true: when initially or upon completed execution of a selected guarded list one or more guards are true, a new selection of a guarded list with a true guard will take place; and so on. When the repetitive construct has terminated properly, we know that all its guards are false. Note: if the empty guarded command set were allowed do od would be semantically equivalent to ‘skip’. (End of note.)” [DIJ 75][DIJ 06]

Distributed Spread out across space. It is more appropriate to speak of a distributed view of a system. A hardware designer views an ordinary sequential computer as a distributed system, since its components are spread across several circuit boards, while a Pascal programmer views the same computer as nondistributed [MIL 90]. Divergence “A divergence is a trace which aborts.” [SIN 06] Divergence is the possibility of a process to enter into an infinite sequence of internal actions, for example when processes can communicate infinitively with each other without

Glossary

379

ever communicating externally. This is sometimes termed ‘livelock’ or ‘infinite internal chatter’ [ROS 98]. A divergent state is a state which may engage in an infinite loop of internal actions. Domain of a relation Considering a relation R, from S (the source of R) to T (its target), R ∈ S ↔ T , the domain of R, is the set of the elements of S related to one or several elements of T . The set of the elements of T related to the elements of S is called its codomain or range (Figure 20.1). Domain

Range or codomain

Ordered pair Source

Target

Figure 20.1: Source, target, domain and range

Domain assumption “A statement of domain knowledge or domain assumption is an indicative property intended to be relevant to the software development project [ZAV 97].” Dynamics This term is used for the specification of the state changes (Example: c := c+1) or of the sequences of events permitted (Examples: i) any elevator request must ultimately be satisfied, ii) the elevator never traverses a floor for which a request is pending without satisfying this request). Called also behavioral ´ 01]. specification [BER See Statics

E Efficiency requirements Under this expression, space, time resources consumption and quality of services requirements are taken into account. However, these are seldom taken into account in specifications. Enabled A transition or an operation is enabled when its guard holds. Entity-relationship (ER) diagram A diagram where sets of entities are represented by rectangles and relations between these sets by diamonds or by bubtangles.

380

Software Specification Methods Names of attributes are written inside the rectangles and inside the diamonds (or sometimes they are written inside ovals connected to their owning entity sets by a line). An attribute of an entity set is a function from the entity set to the sets of values of the attribute. Amongst the attributes the key attributes are distinguished. Cardinalities are used to express the type of the relations (function, total or partial, injection, etc.). Generally ER diagrams are used to express data models. See Cardinality of a relationship, Data model

Equivalence In process algebras, it is possible to characterise equivalence between agents in a number of different ways. There is a stronger notion of equivalence which does not distinguish between internal and external actions and a weaker notion that attemps to consider only external actions. Both of them rely on the fact that two processes must first of all generate the same set of action sequences [FEN 96]. Event 1. An event produces a state change in a system, a state change that the system cannot perform without the reception of the event. So event is synonymous with information. 2. An event occurs instantaneously and causes transitions from one state to another state. It can be external, arriving from the outside of the system under consideration, or it can be internal, viewed as the change in the value of a predicate caused by the operations of the system itself. 3. Following Hoare [HOA 85], to describe the pattern of behavior of objects, we have first to decide what kinds of event or action will be of interest. The actual occurrence of each event in the life of an object should be regarded as an instantaneous or an atomic action without duration. There is no need to make a distinction between events which are initiated by the object and those which are initiated by some agent outside the object (avoidance of the concept of causality). Event and Action are synonymous for several authors. Event and Signal are synonymous for several authors. See Process, Stuttering Eventually See Finally Executable The property for a specification to be executable on a computer. A specification can be considered as not to be executable because a specification can be non-deterministic and have operations with preconditions (preconditions are not in the code of an executable operation). A final implementation is executable. See Animation of a specification

Glossary

381

Execution 1. An execution is a sequence (either finite or infinite) of states [HIN 95]. 2. The run of a program on a computer. See Trace, Animation of a specification Expression An expression is also called term. See Term Expressiveness 1. Ability to express something in a given language. 2. If concepts expressible in one language cannot be expressed in another language, we can say that the latter is less expressive than the former. 3. A language is less expressive than another one if it can be used less easily or if it makes something impossible to write or more complicated than it would be in the other language. Example: First order predicate logic is more expressive thant the propositionnal calculus. One cannot really say that temporal logic is more expressive than predicate logic with reference to definition 1. For instance, 2P could be translated into predicate logic in this way: ∀t • P (t). However, with the use of specific temporal modal operators, temporal properties are more easily and more concisely written in temporal logic (there is no need for additional temporal variables). Extended It is said of a notation or a method when it adds new features to the basic version. For instance, Petri nets have been extended with colored tokens or events and process algebras with datatypes (ex.: LOTOS). See Pure (Process algebra)

F Failure A failure for a process P is a trace, t, together with a set, S, of actions, in a state where execution of t can either reach a state in which there is a livelock or no action from S is enabled [SIN 06]. Fairness (Assumptions) “A fairness property expresses that, under certain conditions, an event will occur (or will fail to occur) infinitely often. We also speak of repeated liveness (and sometimes of repeated reachability). (. . . ) with regard to liveness properties, it is useful to distinguish between using temporal formulas as hypotheses and using them as properties subject to verification. Fairness

382

Software Specification Methods

P P

P

P

P

P

P

P

Figure 20.2: 32P (used in weak fairness) and 23P (used in strong fairness) P Figure 20.3: 3P (Finally P ) properties are very often used as hypotheses. (. . . ) [we can have] a situation in which a liveness property subject to verification depends on a fairness hypothesis. (. . . ) This terminology applies to fairness properties of the form ‘If P is continuously requested, then P will be granted (infinitely often)’. • weak fairness: Views ‘P is continuously requested’ as applying to situations in which P is requested without interruption” • strong fairness: Views ‘P is continuously requested’ as meaning more generally that P is requested in an infinitely repeated manner, possibly with interruptions (Figure 20.2). The strong/weak terminology is explained by the fact that a strong fairness property implies the corresponding weak fairness property, while the converse is generally false. Morever, constructing schedulers ensuring a weak fairness ´ 01].” property is easier than doing it for strong fairness [BER • weak fairness: 32requested(P ) ⇒ 23granted(P ) • strong fairness: 23requested(P ) ⇒ 23granted(P ) Feasible event Event for which the transition function is defined. See Automaton Finally An operator of the modal logic, noted 3, read possibly. In temporal logic, it is also noted F (Finally). “3P asserts that P is true at some future time (Figure 20.3). Since P is eventually true if and only if it is not always false, 3P is equivalent to ¬ 2 ¬ P [LAM 88]” See Eventually, Globally, Temporal logic Firing a transition When a transition is enabled, it is said that it can be fired or that it can occur.

Glossary

383

Formal development If it is possible to prove mathematically that each refinement satisfies the specification, we say that the development process is formal. Formal language The syntax of the language is formally specified, and it has a formal semantics. Formal method A formal method is a set of tools and notations (with a formal semantics) used to specify unambiguously the requirements of a computer system. It supports proofs of properties of this specification and proofs of correctness of an eventual implementation with respect to this specification [HIN 95]. Formal semantics Three main methods have been developed for giving a semantic description of programming languages: 1. The operational approach. We define an “abstract machine”, which has a state, possibly with several components, and some set of primitive instructions. We define the machine by specifying how the components of the state are changed by each of the instructions. Then we define the semantics of our particular programming language in terms of that. 2. The denotational approach. We give “semantic valuation functions”, which map syntactic constructs in the program to the abstract values (numbers, truth values, functions, etc.) which they denote. 3. The axiomatic approach. We associate an “axiom” with each kind of statement in the programming language, which states what we may assert after execution of that statement in terms of what was true beforehand [STO 89]. Formal verification “Formal verification means having a mathematical model of a system, a language for specifying desired properties of the system in a concise, comprehensible and unambiguous way, and a method of proof to verify that the specified properties are satisfied. When the method of proof is carried out substantially by machine, we speak of automatic verification [McM 93].” Free variable “A variable is said to have a free occurrence in a predicate or in an expression if: (1) it is present in such a formula and (2) it is present in a subformula which is not under the scope of a quantifier introducing that same variable as its quantified variable. Example: In ∀n • n ∈ N AT ⇒ n > x, variable x has a free occurrence, whereas variables n and y have no free occurrences. This is true for y because it does not appear at all, and for n because it appears only in a formula that is within the scope of a quantifier [ABR 96].” See Bound variable

384

Software Specification Methods

P

P

P

P

P

P

P

P

Figure 20.4: 2P (Globally P ) Function 1. In mathematics, a function from one set to another one is a relation (a subset of the cartesian product of the first set with the second set, i.e., a set of ordered pairs) such that each element of the first set corresponds at most one element of the second set. If all the elements of the first set relates to elements in the second set, the function is called total. If not, it is called partial. Represented by → (total function) and → 7 (partial function) in Z and B [ABR 96]. 2. In semi-formal methods, pseudo-algorithmic description of an operation. See Functional, Lambda-calculus Functional 1. In mathematics, the fact that a relation is a function. 2. The fact that a specification is independent from the way (data structure, algorithm) it will be implemented. 3. Some methods distinguish between data specification (in formal terms, the state invariant), functional specification (a specification, in terms of mathematical function of the operations) and behavioral specification (a specification, in terms of automaton, of the sequencing of operations). Functional property When time and space efficiency is not taken into account. They are many other non-functional properties: usability, maintenability, portability, etc. Example:

1. Every order is the order of only one client.

2. To obtain a mark for an examination, a student has to be on the list of the students present at this examination.

G Globally A temporal logic operator noted 2 or G (Globally). The formula 2P asserts that P is true now and at all future times [LAM 88]. 2 3P specifies that P is true infinitely often.

Glossary

385

Example: 2[x′ = x + 1] (TLA) is read Always (2): the value of x in the next state (x’) equals its value in the current state (x) plus 1. See Eventually, Fairness, Temporal logic G¨odel (First incompleteness theorem) “These two systems (the system of Principia Mathematics, the axiom system for set theory of Zermelo-Fraenkel) are so extensive that all methods of proof used in mathematics today have been formalized in them, i.e., reduced to a few axioms and rules of inference. It may therefore be surmised that these axioms and rules of inference are also sufficient to decide all mathematical questions which can in any way at all be expressed formally in the systems concerned. It is shown (...) that this is not the case, and that in both the systems mentioned there are in fact relatively simple problems in the theory of ordinary whole numbers [note: i.e., more precisely, there are undecidable propositions in which besides the logical constants – (not), ∧ (or), (x) (for all) and = (identical with), there are no other concepts beyond + (addition) and . (multiplication), both referred to natural numbers, and where the prefixes (x) can also refer only to natural numbers.] which cannot be decided from the axioms. This situation is not due in some way to the special nature of the systems set up, but holds for a very extensive class of formal systems, including, in particular, all those arising form the addition of a finite number of axioms to the two systems mentioned, provided that thereby no false propositions of the kind ¨ 92] described between [ ] become provable.” Kurt G¨odel [GOD This theorem basically states that, for any formal theory in which basic arithmetical facts are provable, either the theory is inconsistent (i.e., it contains a contradiction) or it is possible to construct an arithmetical statement which is neither provable nor refutable in the theory. Ground model In ASM (Abstract State Machine)[BOR 06], “The most abstract model is a ground model, i.e., the result of a formalization process of the informally given description which remains conceptually and notationally as close as possible to the latter and thereby can be inspected by the user for its adequacy.” Note: in algebraic specifications, a term without any variable at all is called ground. eq(zero, zero) is a ground term [LEE 90]. Guard A guard is a predicate describing the state in which the action may be executed. Where the guard does not hold, the operation (substitution in the B method) is said to be non-feasible. The difference between a guard and a precondition is in the fact that a preconditionned operation can be executed if the precondition does not hold while a guarded operation cannot be executed if the guard does not hold. See Action, Dijkstra’s Guarded Command Language, Precondition

386

Software Specification Methods

I Identifier • In programming languages, names of language entities such as variables, procedures, etc. Keywords are reserved identifiers with special naming. • Considering a set of objects S and a set of values I, a bijective function from I to S is an identification function. The elements of I are identifiers. Sometimes, the identification function considered is only a partial surjective function. Example: OrderNumber is an identifier of Orders if every Order has one and only one value of the set of OrderNumbers and an element of the set OrderNumber is the order number of one and only one Order. Key is a synonym used in the database community. The key of a n-ary relational schema R (c1, c2, ..., cn) is a subset of the schema element (c1, c2, ...) identifying the tuples of the relations instances of the relational schema R. A relation being a set, c1, c2, ..., cn is a key, but not necessary one of the minimal keys. See Unique Implementation bias An implementation bias is the inclusion, in the requirements, of information that does not concern the application domain. Incremental specification A specification built, starting from a first abstract specification and, step by step, adding new details without introducing unexpected side-effects. See Refinement Indeterministic choice The fact that the rule indicating what operation or what object will be chosen is not specified. Indicative property See Domain assumption Inductive type An inductive type T is defined by providing a finite number of functions to T , called the constructors of T . Constructors are assumed to be: • non-overlapping, that is, the values returned by two different constructors are necessarily different; • injective, that is, applying a given constructor to different values returns different values. The paradigmatic example is the type N of natural numbers, with two constructors: Zero, which has 0 argument and Succ, which has one argument of type N.

Glossary

387

Replacing Succ with a constructor B with two arguments yields a type of binary tree skeletons. More involved examples include Abstract Syntax Trees (each rule corresponds to a constructor) and infinitely branching trees (with a constructor having as argument a function from N to T ). Enumerated types are just a special (degenerated) case of inductive types, where all constructors have zero argument. In particular, no recursion is involved. The name “inductive type” is coupled with the following fact. Each inductive type T comes with a proof rule, which is just simple induction when T is N, allowing us to prove P (x) for all x in T . Basically, for a general inductive type, this proof rule states: prove it for each contructor, assuming that P (a), P (b), ... when a constructor has arguments a, b, ... of type T . In the degenerate case of an enumerated type, this boils down to reasoning on the different cases (J.-F. Monin). Injection (Sometimes called a one-to-one mapping, but this may cause confusion with bijection.) An injection is an injective function, i.e., a function associating two sets in such a way that different members of the domain are paired with different members of the target set. Represented by ֌ (total injection) and ֌ 7 (partial injection) in Z and B. See Bijection, Surjection Interactive system “In interactive systems, clients ask for accesses or resources that the system grants or allocates if and when possible. The class covers operating systems, databases, networking, distributed algorithms, etc. The computer (network) is the leader of the interaction, and clients want to be served. The main concerns are deadlock avoidance, fairness, and coherence of distributed information. (. . . ) Large scale systems can have components of type interactive and reactive. For instance, driving an airplane is mostly reactive, while communicating with the ground is mostly interactive. An automatic teller machine is reactive except the interactive communication with the bank. Interactive and reactive systems differ deeply on the key issue of bahavioral determinism. Interactive systems are naturally viewed as being non-deterministic [BER 98].” See Reactive system Interleaving “A sequence s is an interleaving of two sequences t and u if it can be split into a series of two subsequences, with alternate subsequences extracted from t and u.” Example: s = h1, 6, 3, 1, 5, 4, 2, 7i is an interleaving of t and u, where t = h1, 6, 2, 7i and u = h3, 1, 4i [HOA 85] Intuitionnist logic (or constructive logic). In classical logic, the existence of a mathematical object is demonstrated without constructing an example of it. This approach is rejected by intuitionnist logic which does not accept the excluded

388

Software Specification Methods middle principle (P ∨ ¬ Q). This principle makes it possible to prove P ∨ ¬ P in a case where neither P nor ¬ P are provable. This is because, using proof by contradiction (also called indirect proof or reductio ad absurdum), P ∨ ¬ P can be proven from the fact that its negation is contradictory, and this without ever deciding which, from P or ¬ P is demonstrated. Intuitionist logic does not admit such proofs. It is as logic where the value of a proposition is given by its set of proofs. For instance, with Φ(P ) being the set of proof for P , to prove P ∧ Q one has to prove both P and Q. The set of proofs for P ∧ Q, Φ(P ∧ Q), is equal to the cartesian product Φ(P ) × Φ(Q) [SCI 05].

Invariant A predicate that the variables of a system have to establish for every state of the system. An invariant property is an example of safety property. See Safety property

K Key See Identifier Kleene closure The set of all finite strings, including the empty one (ǫ) of elements of a set E. It is written: E ∗ and read E star. Example: E = {a, b, c} E ∗ = {ǫ, a, b, c, aa, ab, ac, ba, bb, bc, ca, cb, cc, aaa, ...} See Regular expression

L Lambda calculus (λ-calculus) The λ-calculus consists of a single transformation rule (variable substitution) and a single function definition scheme. The λcalculus is universal in the sense that any computable function can be expressed and evaluated using this formalism. In λ-calculus, every expression stands for a function with a single argument; the argument of the function is in turn a function with a single argument, and the value of the function is another function with a single argument. A function is anonymously defined by a λ-expression which expresses the function’s action on its argument. For instance, the “addtwo” function f (x) = x + 2 would be expressed in λ-calculus as λx.x + 2 (or equivalently as λy.y + 2; the name of the formal argument is immaterial) and the number f (3) would be written as (λx.x + 2)3. Function application is left associative: f xy = (f x)y. Consider the function which takes a function as argument and applies it to the argument 3: λx.x3. This latter function could be applied to our earlier “add-two”

Glossary

389

function as follows: (λx.x3)(λx.x + 2). It is clear that the three expressions (λx.x3)(λx.x + 2) and (λx.x + 2)3 and 3 + 2 are equivalent. A function of two variables may be expressed in λ-calculus as a function of one argument which returns a function of one argument. For instance, the function f (x, y) = x − y could be written as λx.λy.x − y. The three expressions (λx.λy.x − y)7 2, (λy.7 − y)2, and 7 − 2 are equivalent. It is this equivalence of λ-expressions which in general cannot be decided by an algorithm [WIK 05]. Lemma During the proof of a theorem C, it can be useful to prove an intermediate theorem I that is then used in the proof of C. I is called a lemma. Literal The value (an integer, a string of characters) of a variable or of a constant. It is not a name representing values during the execution of the program. Liveness property 1. Liveness properties assert that something must happen [LAM 88]. 2. “Liveness = total correctness” [MIL 89] 3. Synonymous of eventually property (the fact that humans die is a liveness property!). 4. “Liveness properties deal with eventualities – events which must occur at some finite but unbounded time [McM 93].” Example: The aircraft will eventually take off. See Finally, Livelock, Safety property Livelock See Divergence Logic (First-order) The first-order logic or first-order predicate calculus permits the formulation of quantified statements such as “there exists (∃) an x such that . . . ” or “for any (∀) x, it is the case that . . . ” x is an individual variable and not a predicate variable. See Logic (Higher-order) Logic (Higher-order) Logic where the quantifiers (∀, ∃) can be applied to predicate variables and not only to individual variables. It can express statements such as “for every property P , it is the case that ...” (∀P ) or ”there exists a property P such that ..” (∃P ). See Logic (First-order)

390

Software Specification Methods

M Mealy automaton See Automaton Method 1. Process followed to attain a goal. 2. Tool box including concepts, heuristics, processes to be followed, notations, syntactic editors, type checkers, automatic provers, etc. Methodology The study of methods. Miracle (Law of the Excluded Miracle) See Precondition (Weakest) Modal A modal is an expression (like necessarily or possibly) that is used to qualify the truth of a judgement. Under the term modal logic, one finds temporal logic, deontic logic, belief logic, etc. See Temporal logic Model 1. A model is a product; it is neither a description nor a specification. Often it is a product that has some, but not all, of the properties of the “real product”. Example: “A model of the 747 aircraft may fit on my desk and be unable to fly.” Parnas in [HIN 95] See Description, Specification 2. “Mathematics can be used to represent, or model, the world.” Example: The equation e = mc2 was Albert Einstein’s way of expressing a belief about the relationship between energy e and mass m (c denotes the speed of light) [GRI 93]. 3. Consider the mathematical structure of order. We do not know what is the meaning of the relation and the meaning of the elements. Now, if a meaning is given for the elements and for the relation, one has a model of the structure. Example: If the elements are summits of mountains and the relation is “is higher than”, we have a geographical model. If the elements are employees of a company and the relation is “is the chief of”, we have a model of power.

Glossary

391

Following this definition, the landscape is amodel of the map. Algebras give meaning to, or are models for abstract types [WAT 91]. See Algebraic semantics 4. “To an observer B, an object M is a model of an object O to the extent that B can use M to answer questions that interest him about O [MIN 68].” Example: A program written in Fortran can be considered as a model of an associated piece of software to write in Assembly language. 5. “A model is a class of possible imaginary universes. To make our model meaningful, we require a theory that predicts some or all of the possible observations that might be made of the model. An observation generally takes the form of the truth or falsehood of a predicate, or statement about the model [McM 93].” Model-based A type of specification where the specification is based on a model specified elsewhere. Example: In Z, VDM, ASM or B (model-based methods), the specifications are constructed on the model of sets and relations. In algebraic specifications, even the specification of sets is constructed. Therefore, algebraic specifications do not use the term set, but the term sort to speak about types. see Sort, State-based specification Model checking “Exhaustive method to verify properties of a system. A formal model of the system is constructed, under the form of an automaton, for example. Then, with a language of properties specification, such as temporal logic, properties are formally specified. Finally, an algorithm states if the system verifies the property. The algorithm is implemented in a model checker. Model checkers may propose an example of execution not respecting the prop´ 01]” erty. [BER “Unfortunately, modeling complex system as finite state machines has an inherent disadvantage which is commonly known as the state explosion problem. Thus, model checking is capable of dealing efficiently with very large state machines, but not with systems that are made up of a large number of small finite state machines, nor with systems that manipulate data [McM 93].” Symbolic model checking is an approach to the state explosion problem. Module A module consists of a private data structure and a set of access-programs being the only way to access the data structure. Moore automaton See Automaton

392

Software Specification Methods

Multiplicity of a relationship See Cardinality of a relationship

N Non-determinism • A system exhibits non-determinism if two executions of it may behave differently when given exactly the same inputs [ROS 98]. • “In between two subsequent communications the process usually engages in some internal action. These proceed autonomously at a certain speed and are not visible to the user. However, as a result of such internal actions, the process behavior may appear non-deterministic to the user [BER 01].” Non-determinism permits to abstract some behavior (it can be in fact a deterministic behavior) that one decides to not describe in details. In a method such as B, non-determinism is reduced during the refinement process. One distinguishes: – non-determinism on control: amongst a set of execution paths, one will be chosen but one does not explicit the condition of the choice; – non-determinism on data: choice amongst a set of values. As an example, x :∈ {1, 2, 3} in B is read: “x becomes an element of the set {1, 2, 3}.” Non-formal The syntax is not formally specified. Typically, the specification is given in natural language. Notation In the domain of specifications, notation is used as synonymous of language. The vocabulary of a notation can be formed of graphical or textual elements.

O Object-based A language with objects which does not provide direct support for inheritance [CAR 85]. Object method

1. Method putting into practice the object paradigm.

2. In object-based or object methods, a function associated with particular object class. Object orientation Specification paradigm using the concepts of inheritance, class, polymorphism, and encapsulation [MEY 97].

Glossary

393

Object-oriented A language with objects which provides direct support for inheritance [CAR 85]. Observational equivalence Usually used in context of process algebra. “Observational equivalence, meaning that an observer cannot distinguish between two processes by any experiment [McM 93]”. S Operator S “Operators are different from functions. Consider the operator , where S is the union of all S elements of S. We cannot define a function union so that union[S] equals S for all sets of S. The domain of union would have to be a set that contains all sets, and there is no such set (if there were, we would encounter Russell’s paradox) [LAM 98].” Operational description Synonymous for the description of the dynamics of a system. Operational semantics • The meaning is expressed in terms of execution. • The operational semantics of a programming language describes how a valid program is interpreted as sequences of computational steps. These sequences are then the meaning of the program. An operational semantics can be constructed by providing a state transition system. • An operational semantics corresponds to a transition relation which expresses that a term B may perform an action L and evolve to become term B ′ . This semantics implicitly defines a mapping between a term B and an automaton which describes possible evolutions of B (transitions of the automaton being labeled by actions L of B) [GAR 03]. See Automaton, Denotational semantics, Execution Orthogonal 1. An orthogonal design guarantees that operations within one of its components neither create nor propagate side-effects to other components. 2. An orthogonal state is a composite state consisting of concurrent substates (in Harel Statecharts). See Structured automata Overloading “Overloading means letting one symbol stand for many different functions, using types to determine which function is intended. The symbol ‘+’ could denote addition over types NAT, INT, and REAL [LAM 98].”

394

Software Specification Methods

Overriding (of a relation by another one) The overriding (r1<+r2, in B or r1 ⊕ r2, in Z), of a relation r1 by a relation r2 is the relation obtained by taking all the pairs of r2 and all the pairs of r1 without those pairs whose first elements are also the first elements of some pairs of r2. Such a construct is of particular interest when r1 and r2 are functions since it will have the effect of forming a new function [ABR 96]. Example: With the functions r1 = {1 7→ a, 3 7→ a, 4 7→ c, 9 7→ d} and r2 = {1 7→ e, 7 7→ a, 3 7→ a}, we have r1<+r2 = {1 7→ e, 3 7→ a, 4 → 7 c, 9 7→ d, 7 7→ a}

P Parallelism The fact for two or more processes to run at the same time. See Concurrency Partial vs. total • A relation or a function is total if each element of its source has an image, otherwise it is said to be partial. • An operation is total if for all permitted (i.e., of correct type) values of its parameters it produces a result, else it is said to be partial. Port “Explicitly naming in a process the other processes to which it synchronizes would limit the reusability level of such processes out of the context they have been defined for. Therefore, the port (gate, channel, ...) concept has been introduced to name connections between processes [GAR 03].” Postcondition “For instance, if we want to make a machine capable of computing the greatest common divisor (GCD), we could demand of the final state that it satisfies (1) x = GCD(X, Y ). We call (1) the (desired) ‘postcondition’, ‘post’ because it imposes a condition upon the state in which the system must find itself after its activity.” E.W. Dijskstra in [DIJ 76]. A postcondition is a predicate that must always hold just after the execution of some section of code (domain of proof of programs) or after an operation (domain of formal specifications). Example: in a Hoare triple of the form {P }C{Q}, where P and Q are predicates and C is a command, P is called the precondition and Q the postcondition. Such a triple is read: “Whenever P holds for the state before the execution of C, then Q will hold afterwards”. Note that if C does not terminate, then there is no “after”, so Q can be any statement at all. Indeed, one can choose Q to be always evaluated to false to express that C does not terminate. Precise In specification, the term is used as a synonym for unambiguous.

Glossary

395

Precondition (Sufficient) “The way in which we use predicates (as a tool for defining sets of initial or final states) for the definition of the semantics of programming language constructs has been directly inspired by Hoare, the main difference being that we have tightened things up a bit: while Hoare introduces sufficient preconditions such that the mechanisms will not produce the wrong result (but may fail to terminate) we shall introduce necessary and sufficient – i.e., socalled ‘weakest’ – preconditions such that the mechanisms are guaranteed to produce the right result [DIJ 75].” Precondition (Weakest) “We shall use the notation wp(S, R), where S denotes a statement list and R some condition on the state of the system, to denote the weakest precondition for the initial state of the system such that activation of S is guaranteed to lead to a properly terminating activity leaving the system in a final state satisfying the postcondition R. Such a wp – which is called “a predicate transformer” because it associates a precondition to any postcondition R – has, by definition, the following properties (F denotes, by definition, the condition that is satisfied by no state at all, T denotes the condition that, by definition, is satisfied by all states): 1. For any S, we have for all states: wp(S, F ) = F (the so-called Law of the Excluded Miracle). 2. For any S and any two postconditions, such that for all states P ⇒ Q, we have for all states: wp(S, P ) ⇒ wp(S, Q). 3. For any S and any two postconditions P and Q, we have for all states wp(S, P ) and wp(S, Q)) = wp(S, P ∧ Q). 4. For any deterministic S and any postconditions P and Q we have for all states (wp(S, P ) ∨ wp(S, Q)) = wp(S, P ∨ Q). For non-deterministic mechanisms S the equality has to be replace by an implication; the resulting formala follows from the second property.” [DIJ 75] wp(S, R) is written [S]R in B, and is read “The substitution S establishes the predicate R”. Example: Considering the invariant x ∈ {1, 2, 3, 4}, x ∈ {1, 2, 3} is the weakest precondition of the operation x := x + 1 for this invariant (postcondition). x ∈ {1} is a stronger precondition. When the precondition does not hold, the operation (substitution in the B method) is said to abort because it cannot establish anything. See Guard Predicate transformer A predicate transformer is a total function mapping between two predicates on the state space of a program. The weakest precondition is the

396

Software Specification Methods canonical predicate transformer of sequential imperative programming. Following the B notation, with x and y integers, [x := y − 5](x > 10), read as the substitution “x becomes equal to y − 5”, establishes the predicate “x > 10”. Applying the weakest precondition, we obtain (the value of x in the predicate is replaced by y − 5): y − 5 > 10, i.e., y > 15.

Primed vs. unprimed variable In specification languages such as Z and TLA+ , unprimed variables refer to the values of the variables before the operation and the primed variables refer to their values after the operation. Example: x′ = x + 1. Process • “The word process is used to stand for the behavior pattern of an object, insofar as it can be described in terms of the limited set of events selected as its alphabet [HOA 85].” • “A process is a piece of software that may never stop; however it might often wait passively to be activated by the receipt of certain stimuli [COO 98].” See Program, Software system Profile (of a function/operation) Specification of the parameters of the function/operation. Sometimes signature is used instead of profile. Program • “A program is a specification which is constructed only from statements that can be executed on a computer or from statements that can be compiled into executable statements.” [FRA 95] • “A program is a piece of software that takes data, carries out a calculation (executes an algorithm), delivers results, and stops. In principle, all the data is available before execution starts [COO 98].” See Process, Specification Progress property A program never gets into a state where no further transitions are possible. See Liveness property Property 1. Consider two sets of objects not necessarily disjoint and a function from one set to the other. A property is the name given to such a function. Example: With the sets Students, Date, we can have the properties (functions) of type Students → Date: birth-date, first registration date, wedding date.

Glossary

397

We can have a function from a set to a power set, as for example a function courses followed from the set Student to the power set of Course. In database terminology and object-oriented specifications, such a property is sometimes said to be multivalued. Attribute is also used as a synonymous for property. 2. Consider a set S of objects and a subset s of objects from S, this set can be considered as a unary relation. Given any element of set S, the property P of being in the subset is either true or f alse. Formally, P ∈ S → {true, f alse}. 3. In mathematics and in algebraic specifications, a property is an axiom or a theorem. 4. In state-based specifications, a property is a part of the invariant. The cardinalities of a relationship (see Cardinality of a relationship) express a property. Property (positive vs. negative) 1. Positive: Every execution of the system satisfies the property. 2. Negative: No execution of the system satisfies the property. Pure (Process algebra) Process algebra without data extension. Example: pure CCS, basic LOTOS. See Extended

R Range of a relation See Domain of a relation Reactive programming language “A programming language is called reactive if the behavior of its program can be observed or even altered at stable states intermediate between initiation and termination [HOA 98].” Reactive vs sequential language “A programming language is called reactive if the behavior of its programs can be observed or even altered at stable states intermediate between initialisation and termination. To distinguish intermediate states from final ones, we introduce another Boolean variable wait, which is true when the program is in a stable intermediate state, and which is false when the program has terminated (. . .). A sequential language does not need a wait variable, because there are no intermediate observations, and so it would always be false [HOA 98].”

398

Software Specification Methods

Reactive system 1. “In reactive or reflex systems, the computer role is to react to external stimuli by producing appropriate outputs in a timely way, the leader of the interaction being the environment. Reactive systems are prominent in industrial process control, airplane or automobile control, embedded systems, audio or video protocols, bus interfaces, systems or man-machines interfaces drivers, signal processing, etc. In reactive systems, the pace of the interaction is determined by the environment, not by the computers. Most often, clients cannot wait. The main concerns are correctness (safety) and timeliness [BER 98].” See Interactive system 2. “Systems that usually exhibit concurrent or parallel execution, where many individual processes and sub-components are running at the same time, perhaps competing for shared resources, yet coordinating their activities to achieve a common goal. These processes and sub-components may be geographically dispersed so that the computation is then distributed. The cardinal characteristic of reactive systems, however, is the ongoing nature of their computation. Ideally, reactive systems exhibit non-terminating behavior [EME 95].” A non-reactive program is a program which does not have to react to the user interactions (being it a human or not). A reactive program will have to react to such interactions. Example: A program which computes the square root of a natural is nonreactive. Its specification can be a definition of the square root properties without giving an algorithm for its computation. Example: An Automatic Teller Machine is a reactive system. Its specification will be given in terms of acceptable behaviors of the banking automaton. Example: Operating Systems, Communication protocols, Automatic Vending Machines or Cash Dispensers [MOL 96]. Reduction Consists of transforming the verification problem to a similar problem in a smaller state space. β-reduction: rule in the lambda-calculus which consists of replacing, in a function application, a bound variable (function parameter) by the applied term. Example: The lambda-term (λx.x+2)3 can be β-reduced into the 3+2 lambdaterm. See Lambda-calculus, Bound variable Refinement The word is used in at least three distinct senses:

Glossary

399

1. An operation OConc is a refinement of an operation OAbst if the precondition of OConc is weaker than the preconditon of OAbst and OConc is less non-deterministic than OAbst. 2. The fact of adding details about the functionality of the system. 3. The fact of decomposing a system into sub-systems and their relations (usages, interactions, etc.). Regular expression A regular expression is defined recursively as follows. Given a finite alphabet A: 1. ⊘ is a regular expression denoting the empty set, ǫ is a regular expression denoting the set {ǫ}, and {a} is a regular expression denoting the set {a}, for all a ∈ A. 2. If r and s are regular expressions, then rs, (r + s), r∗ , s∗ are regular expressions. 3. There are no regular expressions other than those constructed by applying rules 1 and 2 above a finite number of times. Regular expressions can express the class of languages accepted by finite state automata: regular languages. Example: (a + b)c∗ denotes the language: L = {ǫ, a, b, ac, bc, acc, bcc, accc, bccc, ...} Depending on the authors, (a+b)c∗ is written: (a|b)c∗ , (a∪b)c∗ , (a+b).c∗ or (a, b)c∗ . The Jackson structure diagrams are a graphical representation of regular expression. Relation In mathematics, a binary relation from a set S to a set T is a subset of the cartesian product A × B. An element of a binary relation is an ordered pair. A n-ary relation is a relation on n sets (not necessarily disjoint). See Function, Property, Unique Relationship Term used in semi-formal methods. It can be interpreted by the mathematical term relation. Requirement “A requirement is an optative property, intended to express the desires of the customer concerning the software development project [ZAV 97].”

400

Software Specification Methods

S Safety property 1. “Safety = partial correctness”. [MIL 89] 2. Something bad never happens. An invariant property is a safety property. 3. The system never enters a bad state. Example: An aircraft should never go below a specified altitude, except during takeoff and landing. See Globally, Liveness property Satisfiability Whether there exists a model for a given (e.g., specification formula). See Model, Model checking Seamless development “In computer program development as in sewing, concealing the seam is often desirable so that the finished work looks like one object rather than two joined together.” “Use the same techniques through the process, for analysis, architecture, design, implementation, maintenance, debugging. It’s called seamless development, removing artificial gaps between project steps.” [MEY 02] “Seamless is somewhat similar to the term transparent. Both mean that the user of something is unburdened by having to see what went into making it [WHA 05].” Semi-decidable A procedure is semi-decidable when it answers yes if the conjecture it is requested to prove is a theorem else does not reply. See Decidable Semi-formal The syntax of the notation is formally specified, but it does not have a formal semantics. Sequence A sequence is a function whose domain is an interval of the form 1..n where n is a natural number. Example: [2, 2, 5] = {(1 7→ 2), (2 7→ 2), (3 7→ 5)}. Although the sets {1, 2} and {2, 1} denote the same set, the sequences [1, 2] and [2, 1] are different. See Trace Signal 1. In a synchronous language such as Signal, “a signal is a sequence of values of the same type which are present at some instants. The set of instants where the signal is present is the clock of the signal.” [HOU 02] In Esterel,

Glossary

401

a pure signal does not carry any information within it; only its presence or absence can be detected by the system. Thus, a pure signal is typeless. A valued signal is a typed signal and carries a value whenever it is emitted; the type of a valued signal indicates the kinds of values that the signal can carry. 2. In a language such as SDL, a signal is a message, a data transmitted between computational processes. Signature See Profile Simulation 1. In theoretical computer science, the term simulation represents a relation between state transition systems. 2. “Discrete simulation means the simulation of a discrete simulation program. Discrete simulation means the simulation of a system in which all changes in the state of the system may be assumed to happen at certain discrete instants of time. The system being simulated is usually a set of individual activities which are largely independent, although they interact with each other; examples are customers at a store, ships in a harbor, people in a corporation, etc. In a discrete simulation, we proceed by doing whatever is to be done at a certain instant of simulated time, then advance the simulated clock to the next time when some action is scheduled to occur.” 3. “By contrast, a continuous simulation would be simulation of activities which are under continuous changes, such as traffic moving on a highway, spaceships traveling to other planets, etc. Continuous simulation can often be satisfactorily approximated by discrete simulation with very small intervals between steps; however, in such a case we usually have synchronous discret simulation, in which many parts of the system are slightly altered at each discrete time interval, and such an application generally calls for a somewhat different type of program organization than the kind considered here.” [KNU 73] Simulation schemes There are two discrete-events simulation schemes: • the event scheduling scheme, where feasible events are generated; • the process-oriented simulation scheme, where every entity in the system undergoes a sequence of actions [CAS 99].

402

Software Specification Methods

Software systems “Software systems are collections of inter-linked programs and/or processes controlled externally or by other programs/processes. [COO 98]” See Program, Process Sort A name for a set of values. See Algebraic specifications Source of a relation See Domain of a relation Specification 1. A specification is a statement of properties required for a product, or a set of products. Example: A specification of the A380 aircraft would tell us, among other things, that it must be able to carry 840 persons a distance of 14,800 km [HIN 95]. 2. “A specification of a product is a description of the way it is intended to behave [HOA 85].” Example: For a vending machine, the fact that after the introduction of a sufficient amount of money, the machine delivers a drink. Statecharts See Structured automata State-based specification A type of specification where the specification consists, among other things, of an invariant of the state of the system that must be preserved by the operations of the system. Example: Z, VDM or B are state-based specification languages. See Model-based Statics “The statics correspond to the definition of the state whereas the dynamics corresponds to that of operations [ABR 96].” See Dynamics Structure Mathematical term. A structure is a set of objects with a set of operations. The meaning of the objects and of the operations is not given. When this meaning is given, we have a model of the structure. See Model Structured analysis In the 1980s, structured was a buzzword like object in the 1990s and models in the current decade [OMG]. Structured comes from the principles of programming using basic algorithmic control structures (if, while) composing them by sequencing and nesting, like object analysis comes nowadays

Glossary

403

from object languages. All the methods at this time were qualified structured. In the late 1970s, structured analysis included dataflow diagrams and structure charts for modeling program structure. In the late 1980s, they included entityrelationship diagrams and state-transition diagrams and were named “modern structured analysis methods” [YOU 89]. Structured automata Harel automata (named statecharts) have states called “hierarchical” which are themselves automata. When the system is in a state S1, then depending on this state kind, the system is in a state of every substate of S1 or the system is in one substate of S1 only [HAR 98]. See Orthogonal Stuttering 1. Stuttering (step) corresponds to a sequence of states in which some variables do not change their values. Stuttering appears when variables are hidden, and therefore plays a crucial role in refinement. In TLA, two traces which are only different up to stuttering satisfy the same TLA formula. “Stuttering steps make it unnecessary to consider finite behaviors. An execution in which a system halts is represented by an infinite behavior in which the variables describing that system stop changing after a finite number of steps. When a system halts, it does not mean that the entire universe comes to an end.” 2. Event ǫ, also called stuttering event, which denotes an unobservable event that do not cause a change in the state of the system. See Behavior Synchronous communication This has been introduced by Hoare in his Communicating Sequential Processes (CSP) language. A CSP communication operation waits until a corresponding communication operation can be executed in another process (handshaking, rendezvous) [LAM 90]. System “(...) anything that interacts with its environment in a discrete (digital) fashion across a well-defined boundary [LAM 88].” Statechart See Structured automata Surjection A surjection is a surjective function, i.e., a function associating to sets in such a way that every member of the target set is the image of at least one member of the domain. The range is thus its entire target. Represented by → → (total surjection) and → → 7 (partial surjection) in Z and B. See Bijection, Injection

404

Software Specification Methods

T Target of a relation See Domain of a relation Temporal logic It is a specialized logic to write formulae expressing the sequencing of observable events or states in time. It uses operators such as: X (for next state), F (for a future state) and G (for all the future states). Taking into account a set P of propositions, a classical, (i.e., non temporal) propositional logic formula associates a truth value with each subset of P . A temporal logic formula associates (depending on the kind of logic) a truth value with each sequence (path) of subsets of P (linear-time logic) or with each computation tree defined on these subsets (branching-time logic, e.g., CTL, CTL*). Term A term is a part of a text denoting something and it is a nonsense to say that a term is true or not. A term is opposed to a predicate. true, 7, {2, 7, 3}, (F rance, P aris), A ∪ B are terms. 2 = 3, A ⊆ B are predicates. The terms true, true ∨ f alse, ¬ f alse are different syntactic ways of describing the same semantic truth value true (modulo the axioms if we consider an algebraic specification). In B, for instance, x ∈ {1, 2, 3} is a predicate. We can prove (or not) that this predicate is established by an operation. It has no sense to speak about the proof of a term. In B, a predicate can be transformed into a term with the operator bool, bool(x ∈ {1, 2, 3}) = true if x has the value 1, bool(x ∈ {1, 2, 3}) = f alse if x has the value 5. btrue and bf alse are distinguished from true and f alse. btrue is the predicate always evaluated to true. true is a term. In algebraic specifications, well-formed terms denote “values” of a given sort. See Expression Tools A semi-formal notation may be supported by tools like editors and syntax checkers. A formal notation, thanks to its formal semantics, may also be supported by interpreters, theorem provers, model checkers and test case generators. Support for informal notations is limited to general purpose editors using templates for documents. Trace 1. “A trace of the behavior of a process is a finite sequence of symbols recording the events in which the process has engaged up to some moment in time.” [HOA 85] 2. The set of the traces of a process is the set of all the sequences of actions that this process can engage in. 3. “A trace is simply a history of the communications between a process and its environment [McM 93].”

Glossary

405

Note: some authors restrict the word trace for finite sequences. [BER 01] See Sequence Type

1. A given set from which other sets can be constructed with cartesian product and power set operator. The terms basic set or basic type are used in Z notation. 2. An abstract data type. An object is of type T if the operations of the type T can be applied to it. See Algebraic specification

Typing (strong) “Requirement that the left and right sides of all assignments have identical type [DIJ 90].”

U Undecidable An undecidable problem is one for which an algorithm cannot be written and guaranteed to halt in finite time, even with unbounded time and memory. The “halting problem” is not decidable because a program cannot be written to tell you if a program will not halt for a given input. See Semi-decidable Unique The linguistic expression “unique value” is often used in the literature of semi-formal methods. In fact, every value is unique by definition. Every natural number, for instance, is unique. A value is an expression. {a, b, d}, 1, {1 7→ a, 3 7→ h, 1 7→ f } are values. Several variables can have the same value. Usually, “a value is unique”, has one of the following meanings: 1. the value of a variable is not a set of values whose cardinality is greater than one. Example: Considering the set A = {a, b, c, d} and the invariant: v1 ∈ A ∧ v2 ⊆ A ∧ v1 = a ∧ v2 = {{a}, {b, d}}, v1 is said to have a unique value. v2 is said to have a multiple value; 2. the variable is an identifier of the tuples of a relation. If a n-ary relation is represented by a table with n columns and if there is a function from the elements of the first column to the elements of the other columns, the same value does not appear more than one time in this first column (unicity constraint or key constraint). See Identifier Universality For a formalism adapted to the specification of a type of system (for instance, for asynchronous systems), the principle of being useful in all the

406

Software Specification Methods domains where this type of system is at work and not to be tied to a particular domain [GAR 03].

V Valid specification A specification that captures exactly what the client has in mind and that does not contain any inconsistencies [DOO 95]. Verification It may have different meanings: 1. Mathematical proof of properties 2. Agreement with the client about the specification produced by the specifier. It cannot then be the result of an automated process. This is also called validation.

W Weakest precondition See Precondition (Sufficient), Precondition (Weakest), Predicate transformer

Z ZF-set theory The axiomatic set theory was developed in response to the discovery of serious flaws (such as Russell’s paradox: in a village, the barber shaves every person who does not shave himself, and no one else. Who shaves the barber?) in na¨ıve set theory. The Zermelo-Fraenkel set theory (ZF-set theory) is based on Zermelo set theory and was further developed by A. Fraenkel and T. Skolem. The Zermelo-Fraenkel axioms without the axiom of choice are usually denoted by ZF. For instance, the empty set axiom, stating that there is a set A such that for any set B, B is not an element of A (A is called empty set), is an axiom of the ZF-set theory. The set theory of the B method uses a special form of the axiom of choice. Bibliography [ABR 96] Abrial, J.-R.: The B-Book, Cambridge University Press, 1996. [BAC 03] Backhouse R.: Program Construction. Calculating Implementation from Specification, Wiley, 2003. [BAU 06] Baumeister H., Bert D.: “CASL”, Chapter 15, in this book. ´ 01] B´erard B. et al.: Systems and Software Verification. Model-Checking Tech[BER niques and Tools, Springer, 2001. [BER 01] Bergstra J.A., Ponse A., Smolka S.A.: Handbook of Process Algebra, North-Holland, 2001.

Glossary

407

[BER 98] Berry G.: The Foundations of Esterel, www.esterel-technologies.com/scientific-papers/overview.html. [BOA] Boar in Datamation (review). [BOR 06] B¨orger E., Gargantini A., Riccorbene E.: “ASM”, Chapter 6, in this book. [BUT 96] Butler, M., Wald´en, M.: “Distributed System Development in B”, in First Conference on the B Method, H. Habrias, Ed., Institut de Recherche en Informatique de Nantes, Nantes, France, 1996, 155–168. [CAR 85] Cardelli L., Wegner P.: “On Understanding Types, Date Abstraction, and Polymorphism” in ACM Computing Surveys, vol. 17(4), December 1985. [CAS 99] Cassandras C.G., Lafortune S.: Introduction to Discrete Event Systems, Kluwer Academic Publishers, 1999, 97–100. [COO 98] Cook J.: Constructing Correct Software, the Basis, Springer, Facit, 1998 [DAV 82] Davis Ph.J. and Hersh R.: The Mathematical Experience, Birkh¨auser, Boston, 1982. [DEV 92] Devlin K.: The Joy of Sets, Fundamentals of Contemporary Set Theory, Springer-Verlag, 1982. [DEN 78] Denning P. J., Dennis J. B. and Qualitz J. E.: Machines, Languages and Computation, Prentice Hall, 1978. [DIJ 75] Dijkstra, E.W.: Guarded Commands, Nondeterminacy, and Formal Derivation of Programs, CACM, 1975. [DIJ 76] Dijkstra, E.W.: A Discipline of Programming, Prentice Hall, 1976. [DIJ 90] Dijkstra, E.W.: Formal Development of Programs and Proofs, series U.T. Year of Programming Series, Addison-Wesley, 1990. [DIJ 06] Dijkstra E.W.: E.W. Dijkstra Archive: The Manuscripts of Edsger W. Dijkstra, 1930-2002, http://www.cs.utexas.edu/users/EWD/. [DOO 95] Doornbos H.: Reductivity Arguments and Program Construction, Thesis Technische Universiteit Eindhoven, The Netherlands, 1995, ISBN: 90-3860098-4. [EME 95] Emerson E.H.: Automated Temporal Reasoning About Reactive Systems in [MOL 96] 111–120. [FEN 96] Fencott C.: Formal Methods for Concurrency, International Thomson Computer Press, 1996 [FRA 95] Frappier M.: A Relational Basis for Program Construction by Parts, PhD Thesis in Computer Science, School of Graduate Studies and Research, University of Ottawa, Canada, May 1995. [GAN 96] Gang Cheng: A Dataflow-Based Software Integration , PhD Thesis, Huazhong University of Science and Technology, 1996. [GAR 03] Garavel H.: “D´efense et illustration des alg`ebres de processus”, Actes de l’Ecole d’´et´e Temps R´eel, ETR 2003, September 2003. [GAR 95] Garlan D., Perry E.: “Introduction to the special issue on software architecture” IEEE TSE 21(4) 1995. ¨ 92] G¨odel K.: On Formally Undecidable Propositions of Principia Mathemat[GOD ica and Related Systems, Reprint, Dover Publications, 1992.

408

Software Specification Methods

[GRI 93] Gries D., Schneider F.D.: Logical Approach to Discrete Math, Texts and Monographs in Computer Science, Springer-Verlag, 1993. [HAR 98] Harel D., Politi M.: Modeling Reactive Systems with Statecharts, The Statemate Approach, McGraw-Hill, 1998. [HEI 96] Heitmeyer C., Mandrioli D. (Eds): Formal Methods fo Real-Time Computing, John Wiley, 1996. [HIN 95] Hinchey, Bowen (Ed.): Applications of Formal Methods, Prentice Hall, 1995. [HOA 85] Hoare C.A.R.: Communicating Sequential Process, Prentice Hall, 1985. [HOA 98] Hoare C.A.R., Jifeng H.: Unifying Theories of Programming, Prentice Hall Series in Computer Science, 1998. [HOU 02] Houssais B.: The Synchronous Language SIGNAL, IRISA, Expresso Project, 2002, http://irisa.fr/espresso/sources/logiciels/SignalPrimer.pdf. [JAC 95] Jackson M.: Software Requirements and Specification, Addison-Wesley, ACM Press, 1995. [JON 90] Jones C.B.: Systematic Software Development Using VDM, 2nd ed., Prentice-Hall International, 1990. [KNU 73] Knuth D.E.: Fundamental Algorithms, The Art of Computer Programming, 2nd ed., Addison-Wesley, 1973. [LAM 88] Lamport L.: “A Simple Approach to Specifying Concurrent Systems”, CACM, 32(1): 32–45, January 1989. [LAM 90] Lamport L., Lynch N.: “Distributed Computing: Models and Methods” in Handbook of Theoretical Computer Science, Vol. B , J. van Leewen (Ed.), Elsevier, 1990, 1157–11196. [LAM 94] Lamport L.: Introduction to TLA, SRC Technical Note 1994-001, December 16, 1994, Digital. [LAM 98] Lamport L., Paulson L.C.: Should Your Specification Language Be Typed?, SRC Research Report, Digital, April 1, 1998. [LEE 90] Leeuwen J.: Formal Models and Semantics, Handbook of Theoretical Computer Science, Vol. B, Elsevier, 1990. [LIS 86] Liskov B., Guttag J.: Abstraction and Specification in Program Development, The MIT Press, McGraw-Hill Book Company, 1986. [McM 93] McMillan K.L.: Symbolic Model Checking, Kluwer Academic Publishing, 1993. [OMG] OMG: Model Driven Architecture, www.omg.org/mda/. [MEA 55] Mealy G. H.: “A method for synthesising sequential circuits”. Bell System Tech. J., 34(5), 1045–1079, September 1955. [MEY 97] Meyer B.: Object-Oriented Software Construction, 2nd ed., Prentice Hall, 1997. [MEY 02] Meyer B.: Eiffel, clairs objets du d´esir, Inaugural lecture, ETHZ, Z¨urich, http://se.ethz.ch/~meyer/publications/inaugural/inaugural.pdf. [MIL 94] Mili A., Desharnais J., Mili F., Frappier M.: Computer Program Construction, Oxford University Press, 1994.

Glossary

409

[MIL 89] Milner R.: Communication and Concurrency, Prentice Hall, 1989. [MIL 90] Milner R.: “Operational and Algebraic Semantics of Concurrent Processes” in Handbook of Theretical Computer Science, Vol. B , J. van Leewen (Ed.), Elsevier, 1990, 1201–1241. [MIN 68] Minsky M.L.: Matter, Mind and Models in Semantics Information Processing, MIT Press, 1968. [MOL 96] Moller F., Birtwistle G. (Eds.): Logics for Concurrency, Structure versus Automata, LNCS No 1043, Springer-Verlag, 1996. 6 [MOO 96] Moore E.F.: “Gedanken-experiments on sequential machines”. Annals of Mathematics Studies, Vol. 34, Automata Studies, 129–153, Princeton University Press, Princeton, NJ, 1956. [POL 06] Polack F.: “SAZ”, Chapter 2, in this book. [SCI 05] Pour la science (Ed.): Les chemins de la logique, Dossier Pour la science, October/December 2005, ISSN: 1246-7685, www.pourlascience.com. [ROS 98] Roscoe A.W.: The Theory and Practice of Concurrency, Prentice Hall, 1998. [SHA 96] Shaw M., Garlan D.: Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall 1996. [SIN 06] Sinclair J.: “Actions Systems”, Chapter 8, in this book. [STO 89] Stoy J.E.: Denotational Semantics: The Scott-Strachey Approach to Programming Language Theory, The MIT Press, 1989. ¨ 99] V¨olzer, Varacca, Kindler: Defining Fairness, Technical Report, Imperial [VOL College, London, 1999. [WAL 98] Wald´en M.: “Layering Distributed Algorithmes within the B Method” in B’98: Recent Advances in the Development and Use of the B Method, D. Bert, Ed., LNCS 1393, Springer-Verlag, 1998, 244–250. [WAT 91] Watt David A.: Programming Language Syntax and Semantics, Prentice Hall, 1991. [WHA 05] Whatis: http://whatis.techtarget.com/definitions. [WIK 05] Wikipedia encyclopedia, www.wikipedia.org. [WIR 90] Wirsing M.: “Algebraic Specification” in Handbook of Theretical Computer Science, Vol. B , J. van Leewen (Ed.), Elsevier, 1990, 675–788. [YOU 89] Yourdon, E.: Modern Structured Analysis, Yourdon Press, 1989. [ZAV 97] Zave P., Jackson M.: Four Dark Corner of Requirements Engineering, in ACM, Transactions on Software Engineering and Methodology, Vol. 6, No. 1, January, 1997, 1–30.

This page intentionally left blank

Index

:=, 366 assignment in E-L OTOS, 243 substitution in B, 46 ==, 365 [ ], 366 2, 366 3, 366 β-reduction, 398 U , 365 def

=, 365

==, 365

<+, 366 ǫ, 366 7→, 366 |=, 366 |=M , 366 N1, 366 ⊕, 366 ⊥, 365 \, 366 ⊑, 49, 365 ⊢, 366 skip, 170 ;, sequence in (E)-L OTOS, 243 ?, set offer in (E)-L OTOS, 242 [] choice in (E)-L OTOS, 243 Guarded command choice, 365 abbreviation definition, 7 abortion, 378 abstract machine, 157 abstract system, 157 abstract data type, 277 abstract model, 157, 158, 163, 170

abstract state, 4, 6 Abstract State Machine (ASM), 103 abstract state variable, 60 abstraction, 160, 367 abuse of notation, 367 action, 121, 139, 259, 331, 367 signature, 261 action system, 139 execution, 139 refinement, 152 semantics, 151 action systems, 367 activity, 219 actor, 331, 368 task, 339 ADT, Abstract Data Type, 233 after state, 4, 6, 9 agent, 368 algebra, 368 algebraic semantics, 368 algebraic specification, 277, 369 constructive, 287 observational, 280 alphabet, 371 alternative construct, 378 always, 366, 370 analysis, 370 animation of a specification, 370 architectural description, 370 architectural specification, 289 architecture (software), 370 association, 60, 259 cardinality, 264 multiplicity constraint, 60 asynchronous, 370

412

Software Specification Methods

Atelier B, 59 attribute, 265, 371, 397 key, 265 non-key attribute, 265 automaton, 371 automaton (B¨uchi), 371 automaton (Mealy), 371 automaton (Moore), 371 automaton (regular), 371 axiom, 371 axiom of choice, 371 axiomatic approach, 383 axiomatic semantics, 372 axioms, 278, 368 B notation, 60 bag, 372 bag inclusion, 365 basic type, 5 before state, 4, 6, 9 before-after predicate, 165 before-after predicate, 170 behavior, 121, 259, 331, 372 behavioral style, 179 bijection, 372 bisimulation, in (E)-L OTOS, 254 block, 217 diagram, 217 reference, 219 substructure, 217 bottom, 365 bound variable, 372 box black, 259 state, 260 branching-time logic, 404 bubtangle, 372 cardinality of a relationship, 373, 397 carrier set, 368 C ASL, 277 CCS, 259, 368 channel, 217, 219, 373 characteristic function, 373

choice, 365 class, 60 attribute, 60 object, instance, 60 classic B, 157 clause, 373 Cleanroom, 259 clock, 400 closed formula, 373 closed system, 157, 374 closed-system specification, 131 coercion, 302 collaboration diagram, 62 actor, 62 guard, 62 message, 62 colored net, 320 command, 139, 367 communication asynchronous, 219 communication diagram, 332 Community Z Tools, 3 completeness, 374 compositionality, 374 conceptual framework, 330 concrete model, 170 concurrency, 105, 134, 374 concurrent, 179, 190 conditional correctness, 375 connection point, 217, 219 consistency proof, 88 existence proof, 88 theorem, 88 Z conjecture initialisation, 88 Z conjecture, 88 constructions (calculus of), 375 constructive specification, 234 constructor, 375, 386 contract, viii control structure, 331 Coq, 293, 375

Index correctness, 76, 375 CSP, 139, 259, 403 CTL*, 375 data model, 376 data type, 376 data type, in E-L OTOS, 242 data type, in L OTOS, 248 data-oriented specification, in (E)-L OTOS, 246 dataflow, 375 dataflow diagram, 376 dataflow style, 179 deadlock, 133, 140, 376 decidable, 376 decision, 220 branch, 220 deductive consequence, 366 defensive style, 376 definition, 365, 376 denotation, 376 denotational semantics, 377 description, 377 design, 377 deterministic, 377 diagram class, 59, 60 collaboration, 59, 61 state, 59, 61 Dijkstra’s guarded command language, 377 distributed, 378 distributed bag union, 365 divergence, 140, 378 domain assumption, 379 domain of a relation, 379 domain restriction, 48 domain subtraction, 48 dynamics, 379 E-LOTOS, Enhancements to Language of Temporal Ordering Specification, 233 EB3 , 259

413

attribute definition, 268 class diagram, 265 input-output rule, 263, 268 process expression, 262, 266 efficiency requirements, 379 enabled, 379 enabled action, 140 entity, 259, 331 entity type, 259 life cycle, 337 structure diagram, 259 entity-relationship (ER) diagram, 379 environment, 332 environment, in (E)-L OTOS, 234 equivalence, 380 equivalence (terms), 372 error report, 11 Estelle, 197 Esterel, 401 Euler, 367 event, 157, 380 EB3 , 260 event B, 157 event B model, 157 event gate, in (E)-L OTOS, 234 event offer, in (E)-L OTOS, 234 event, in (E)-L OTOS, 234 event-based specification, 139 event-driven, 179 ASM, 111 eventually, 366 excluded middle principle, 388 executable, 380 execution, 381 explicit operation, 17 expression, 381 expressiveness, 381 extended, 381 extraction, 367 failure, 381 fairness (assumptions), 381

414

Software Specification Methods

FDT, Formal Description Technique, 233 feasible event, 382 finally, 366, 375, 382 finite automata, 311 firing a transition, 382 firing rule, 312, 320 flow line, 220 formal development, 383 formal langage, 383 formal method, 383 formal semantics, 383 formal template language see FTL, 82 formal verification, 383 frame operation, 86 promotion, 86 free variable, 383 Frege’s Principle, 374 FTL, 82 meta-proof, 82 meta-theorem, 82 templates, 82 instantiation, 82 function, 384 function, in E-L OTOS, 246 functional, 384 functional property, 384 gate, 373 gate, in (E)-L OTOS, 234 generalised substitution, 60 generalised substitutions, 41 generalized substitution, 157 generous style, 376 given set, 5, 60 globally, 366, 375, 384 ground model, 103, 385 guard, 139, 367, 385 G¨odel (first incompleteness theorem), 385

handshaking, 403 hiding, 366 hiding variables, 130 higher order function, 297, 301 logic, 293 Hoare triple, 394 horizontal schema, 12 Horn clause, 373 idealization, 367 identifier, 386 implementation, 60, 122, 123, 133, 199, 204, 210, 212 implementation bias, 386 implicit precondition, 15 incremental specification, 386 independent, 393 indeterministic choice, 386 indicative property, 386 inductive type, 386 information systems, 259 inheritance, 222 inhibitor arcs, 315 initial state, 4 injection, 387 input, 220 interaction/message, 197 interaction/point, 197, 200, 205 interactive system, 387 interleaving, 387 intuitionnist logic, 387 invariance, 157 invariant, 4, 7, 41, 50, 60, 158, 161, 163–171, 325, 388 Jackson structure diagrams, 399 JSD, 259 key, 388 Kleene closure, 262, 388 label

halting problem, 405

definition, 220

Index join, 220 lambda abstraction, 48 lambda calculus (λ-calculus), 388 lambda term, 398 language, 399 lemma, 389 library, in L OTOS, 245 linear-time logic, 404 literal, 216, 389 livelock, 389 liveness, 122, 123, 134 liveness property, 389 logic (first-order), 389 logic (higher-order), 389 logical entailment, 366 LOTOS, 259, 373 LOTOS, Language of Temporal Ordering Specification, 233 LTS, Labelled Transition System, 251 machine abstract, 41, 59 marking, 312 Merise, 373 method, 390 methodology, 390 modal, 390 model, 366, 390 model checking, 132, 135, 391 model-based, 391 model-checking, 251 models, 368 modularity, 130 module, 391 module, in E-L OTOS, 242 module/body, 197, 201–203, 209 module/header, 197, 200, 201, 204 module/instance, 197, 198, 200, 206, 210 multiplicity of a relationship, 392 next, 375 noexit, in L OTOS, 245 non-determinism, 107, 143, 392

415

non-formal, 392 notation, 392 formal, vii semi-formal, vii object method, 392 object orientation, 392 object-based, 392 object-oriented, 392 Object-Z, 4 observational equivalence, 393 offensive style, 376 offspring, 219 one-point rule, 15 open system, 374 open-system specification, 131 operation, 4, 41, 59, 60, 331 precondition, 62, 73 operational approach, 383 operational description, 393 operational semantics, 393 operator, 216, 393 ordered pair, 366 orthogonal, 393 output, 220 overloading, 393 override, 48 overriding, 10, 366 overriding (of a relation by another one), 393 pair construction, 48 parallelism, 108, 197, 371, 394 parent, 219 partial, 394 partial function, 6, 7 Petri net, 311, 329, 371 place, 311 port, 373, 394 input, 219 postcondition, 9, 394 precise, 394 precondition, 4, 9, 92, 154 precondition (sufficient), 395

416

Software Specification Methods

precondition (weakest), 395 predicate transformer, 377, 395 primed/unprimed variable, 396 process, 179, 180, 185, 190, 215, 396 instance, 215 reference, 219 process algebra, 233, 259 process, in (E)-L OTOS, 234 process, in E-L OTOS, 242 process, in L OTOS, 245 process-oriented specification, in (E)L OTOS, 242 profile (of a function/operation), 396 program, 396 progress property, 396 proof, 132, 406 proof obligation, 60, 76, 158, 164, 169– 172, 175 property, 216, 396 property (positive vs negative), 397 property, of formal specification, 253 pure (process algebra), 397 purpose of a specification, 124 range of a relation, 397 re-use of a specification, 130 reachability graph, 324 reactive vs sequential language, 397 reactive programming language, 397 reactive system, 398 reductio ad absurdum, 388 reduction, 398 refinement, 49, 78, 122, 157, 158, 161, 164, 168, 170–172, 175, 176, 392, 398 regular expression, 399 relation, 4, 399 relationship, 399 rely/guarantee specification, 131 rendezvous, 403 requirement, 399 requirements efficiency, viii

functional, viii implementation, viii requirements capture, in L OTOS, 234 resolution function, 180 Russell’s paradox, 406 safety, 123, 135 safety property, 388, 400 satisfiability, 400 SAZ, 21 schema, 3 schema inclusion, 8 schema operators, 12 SDL, 401 seamless development, 400 self, 219 semi-decidable, 400 semi-formal, 400 sender, 219 sequence, 366, 387, 400 sequentialisation, 116 set theory, 157 set comprehension, 7 signal, 179, 180, 185, 215, 380, 400 definition, 219 list, 217, 219 route, 217, 219 signature, 277, 369, 401 operation, 277 predicate, 277 sort, 277 subsort, 278 simulation, 179, 193, 194, 401 simulation schemes, 401 snapshot Catalysis, 89 software systems, 401 sort, 216, 368, 402 source, 379 source of a relation, 402 specification, vii, 402 satisfaction, ix validation, ix

Index specification architecture, 63, 234 specification method, vii specification style, in L OTOS, 234 specification, closed-system, 131 specification, length of, 130 specification, open-system, 131 specification, purpose of, 124 SSADM, 21 data flow diagram, 22 entity life history, 22 entity-relationship diagram, 22 function definition, 22 Requirements Analysis module, 21 Requirements Specification module, 21 stack, 369 state, 4, 121, 219 initial, 219, 220 target, 219 state variables, 157 state component, 6 state diagram, 61 action, 61 event, 61 guard, 61 state, 61 transition, 61 state predicate, 121 state-based specification, 139, 402 statecharts, 402 statics, 402 step, 121 strong fairness, 382 structural style, 179 structure, 390, 402 structured analysis, 402 structured automata, 403 stuttering, 366, 403 stuttering step, 122, 129 subsorting, 369 substitution, 366 conditional, 48 elementary , 46

417

multiple, 48 precondition, 48 substraction of sets, 366 substructure, 219 surjection, 403 synchronisation, in (E)-L OTOS, 245 synchronous communication, 403 system, 215 system/distributed, 197, 198, 210, 212 system/systemactivity, 197, 198 system/systemprocess, 197 target, 379 task, 220 temporal logic, 252, 404 term, 404 termination, 378 testing, 133 Texas, 124 theorem, 366 TLA, 121–122, 403 TLA+ , 121–123 TLATEX, 134 TLC model checker, 132 token, 312, 320 tools, 404 total, 394 total operation, 4, 11 trace, 260, 404 current trace, 266 valid input trace, 262 transaction, 59, 61 transition, 219, 312, 322, 323 Turing machine, 311, 327 type, 216, 405 abstract data type, 216 dependent, 302 inductive, 297 powerset, 222 structure, 222 syntype, 222 theory, 293

418

Software Specification Methods

type correctness in TLA+ , 123, 131, 132 typing (strong), 405 UML, 81, 367, 373 association, 83 multiplicity, 83 attribute, 83 class, 83 class diagram, 82 Model Driven Development, 81 object, 83 object diagram, 89 state diagram, 83 state transition, 83 UML+Z, 81 UML notation, 59, 60 UML stereotype, 61, 63 UML+Z naming convention extensional view (S), 84 operations (∆), 84 relational view (A), 84 undecidable, 405 undefined element, 365 unique, 405 universality, 405 valid specification, 406 validation, 250 of ASMs, 112 validation of models, 89 variable definition, 220 variable hiding, 130 variables (primed), 367 verification, 250, 406 of ASMs, 112 vertical schema, 6 von Neumann, 375 weak fairness, 382 weakest precondition, 41, 151

Yu, Yuan, 132 Z, 22, 81, 139 θ operator, 87 error schema, 27 generic schema, 86 instantiation, 86 initialisation, 86 naming convention promotion frame (Φ), 86 object-oriented style, 84 processing specification, 26 promotion, 86 renaming, 86 schema composition operator(o9), 91 schema calculus, 27 state specification, 24 toolkit UML+Z, 85, 88 UML+Z, 81 views, 84 extensional view, 86 global view, 87 intensional view, 85 relational view, 87 structural view, 84 Z notation, 3–5 Z standard, 3 Z toolkit, 3 Z/EVES tool, 17 ZANS animator, 17 Zermelo-Fraenkel, 385 ZF-set theory, 406 ZTC type-checker, 17

Numerical Methods, Software, and Analysis

Specification and Verification of Object-Oriented Software Components

Foundations of Algebraic Specification and Formal Software Development

Specification by Example: How Successful Teams Deliver the Right Software

Foundations of Algebraic Specification and Formal Software Development

Foundations of Algebraic Specification and Formal Software Development

Spectral Methods in MATLAB (Software, Environments, Tools)

Empirical Methods and Studies in Software Engineering

Spectral Methods in MATLAB (Software, Environments, Tools)

Formal Foundations for Software Engineeing Methods

Component-Based Software Quality - Methods and Techniques

Formal Methods and Software Engineering - ICFEM 2011

Formal Foundations for Software Engineering Methods

Spectral Methods in MATLAB (Software, Environments, Tools)

Spectral Methods in MATLAB (Software, Environments, Tools)

Spectral Methods in MATLAB (Software, Environments, Tools)

Spectral Methods in MATLAB (Software, Environments, Tools)

HTML 4.0 specification

Java Language Specification

Corba - Architecture And Specification

Handbook of elemental specification

JavaMail API Design Specification

Specification for Tunnelling

Specification for Foamed Concrete

Formal Systems Specification: The RPC-Memory Specification Case Study

Dart Programming Language Specification

Specification for Ground Treatment

Java Language Specification

Software

Software

Software Specification Methods

Software Specification Methods

Numerical Methods, Software, and Analysis

Specification and Verification of Object-Oriented Software Components

Foundations of Algebraic Specification and Formal Software Development

Specification by Example: How Successful Teams Deliver the Right Software

Foundations of Algebraic Specification and Formal Software Development

Foundations of Algebraic Specification and Formal Software Development

Spectral Methods in MATLAB (Software, Environments, Tools)

Empirical Methods and Studies in Software Engineering

Spectral Methods in MATLAB (Software, Environments, Tools)

Formal Foundations for Software Engineeing Methods

Component-Based Software Quality - Methods and Techniques

Formal Methods and Software Engineering - ICFEM 2011

Formal Foundations for Software Engineering Methods

Spectral Methods in MATLAB (Software, Environments, Tools)

Spectral Methods in MATLAB (Software, Environments, Tools)

Spectral Methods in MATLAB (Software, Environments, Tools)

Spectral Methods in MATLAB (Software, Environments, Tools)

HTML 4.0 specification

Java Language Specification

Corba - Architecture And Specification

Handbook of elemental specification

JavaMail API Design Specification

Specification for Tunnelling

Specification for Foamed Concrete

Formal Systems Specification: The RPC-Memory Specification Case Study

Dart Programming Language Specification

Specification for Ground Treatment

Java Language Specification

Software

Software

Recommend Documents