Spatio-temporal features of FocusST

Spatio-temporal features of FocusST Maria Spichkova

arXiv:1610.07884v1 [cs.SE] 25 Oct 2016

RMIT University, Melbourne, Australia [email protected]

Abstract. In this technical report we summarise the spatio-temporal features and present the core operators of FocusST specification framework. We present the general idea of these operators, using a Steam Boiler System example to illustrate how the specification framework can be applied. FocusST was inspired by Focus [11], a framework for formal specification and development of interactive systems. In contrast to Focus, FocusST is devoted to specify and to analyse spatial (S) and timing (T) aspects of the systems, which is also reflected in the name of the framework: the extension ST highlights the spatio-temporal nature of the specifications.

1

Introduction

This report summarises our current work on specification and development of safety-critical systems focusing on the spatio-temporal aspects. We present here the core operators and features of the FocusST specification framework, with the goal to provide a basis for further spatio-temporal analysis of the system properties as well as an interface for the further connection of the FocusST to other frameworks and techniques. FocusST has a high potential for further extensions. For example, Alzahrani et al. [1] proposed spatio-temporal metamodel for property based testing, where the proposed instantiations of a generic modelling language can be TLA+ and FocusST . FocusST was inspired by Focus [11], a framework for formal specification and development of interactive systems. In our earlier work we developed an extension to Focus with the goal to cover the timing aspects and to provide a specification and verification methodology Focus on Isabelle [23, 30]. Focus on Isabelle allows to specify system in a way that makes further proofs of their properties easier and scalable. The methodology also provides a schematically translation to a Higher-Order Logic representation for Isabelle/HOL, an interactive semi-automatic theorem prover Isabelle [20]. This allows us to verify the system properties (that are specified in the extended Focus framework) using Isabelle/HOL semi-atomatically, also applying its component Sledgehammer [6] to benefit from automated sub-goals verification using first-order automatic theorem provers (ATPs) and satisfiability modulo theories (SMT) solvers in interactive proofs. Other advantages of Focus on Isabelle are (1) a well-developed theory of composition; (2) representation of processes within a system [24]; (3) feasibility

shown on a number of auto motive case studies, also formalising the core aspects of the FlexRay communication protocol [22, 19, 18, 13, 12]. FocusST was developed on the basis of the extended Focus, while giving a special attention to

– the human factor analysis within formal methods [25, 26, 29] to increase the readability and understandability of the formal specifications; – spatio-temporal aspects of the safety-critical systems, which is also reflected in the name of the framework: the extension ST highlights the S patioT emporal nature of the specifications. As result, it allows us to create concise formal specifications that are easy to read and to understand. The FocusST specification layout is similar to Focus (which layout was inspired by Z specification language, cf. [32, 33]), but it has many new features to increase the readability and understandability of the specification. General ideas on the FocusST modelling of components controlling behaviour of safetycritical systems in their physical environment were introduced in [28]. In this report we go further and provide a systematic review of the core features and operators. To discuss the general idea of these operators and features, we use a Steam Boiler System example to illustrate how the specification framework can be applied. Alur and Dill [2, 4] introduced timed automata that are nowadays One of the most well-established models for the specification and verification of real-time system design. Timed automata have many advantages and many application areas, but they assume perfect continuity of clocks which may not suit to specification of embedded system with instantaneous reaction times. Timed automata also do not prevent Zeno runs [14]: an infinite number of transitions in a finite period of time cannot be excluded. This problem was solved in an extended version of timed automata presented [21, 10]. FocusST provides a completely different solution to this problem: the Zeno runs are excluded on the syntactical level. Here fe follow approach of Henzinger et al. [15] that any timed transition system can be discretised without loss of generality. As FocusST is based on Focus on Isabelle, we can even switch from one time granularity to another using predefined operators. Outline: The rest of the report is organised as follows. Section 2 presents the core data datypes and the notion of the timed FocusST streams. In Section 3 we introduce the basic FocusST operators as well as spation-temporal aspects of the language. Section 4 presents the core structure of the FocusST specifications. In Section 5 we discuss a number of special features of the language that were introduced to increase its readability and understandability. Section 6 illustrates the presented ideas using an example specification of a steam boiler system. Section 7 summarises and concludes the report.

2

Data Types and Streams

In both Focus and FocusST , the systems are built out of components, where the component specifications are based on the notion of streams that represent communication histories of directed channels.. However, they have different syntax and semantics for streams: – Focus: Input and output streams of a component can be timed (taking into account timing aspects) or untimed (abstracting from all timing aspects). M ω denotes in Focus the set of all timed streams, M ∞ and M ∗ denote the sets of all infinite and all finite timed streams over the set M respectively. Timed streams are mappings of natural numbers N to the single messages, where a message√ can be either a data message of some type o time tick (represented by ): Mω = M∗ ∪ M∞ √ def S M ∗ = n∈N ([1..n] → M ∪ { }) √ def M ∞ = N+ → M ∪ { } – FocusST : Input and output streams of a component are always timed, as spatio-temporal aspects are the core of the framework. The (timed) streams are mappings from N to lists of messages within the corresponding time intervals. Thus, these streams are infinite per default, but they could be empty completely or from a certain point which is represented by empty time intervals hi. More precisely, FocusST has streams of two kinds:  Infinite timed streams are used to represent the input and the output streams;  finite timed streams are used to argue about a timed stream that was truncated at some point of time. The base data types we use in FocusST are Bool, the type of truth values, N, the type of natural numbers, and Bit, the type of bit values 0 and 1. Definitions of an enumeration and list types are inherited from the Focus specification language, and can be represented in two ways that have the same semantics: type T = e1 | · · · | en

enumeration type

type T = {e1 , . . . , en }

enumeration type

type L = N

∗

list type over N

The FocusST records type RV is defined also using the Focus rules, where con1 , . . . , conn and sel11 , . . . , selknn are constructors and selectors respecivelly: type RV = con1 (sel11 ∈ T11 , . . . , selk11 ∈ Tk11 ) ... | conn (sel1n ∈ T1n , . . . , selknn ∈ Tknn )

Infinite timed streams of type T are defined by a functional type N ⇒T∗ Finite timed streams of type T are defined by list of lists overt this type, i.e., (T ∗ ) ∗ where T ∗ denotes a list of elements of type T .

3

Basic Operators

The operator s t represents tth time interval of the stream s. hi denotes an empty list (an empty time interval). ha1 , . . . , am i denotes a list of m elements a1 , . . . , am . The predicate msgs (k ) holds if each time interval of the stream s has at most k elements. Thus, msgs (1) would mean that each time interval of s either has a single element or is empty. The predicate ts(s) ensures that each time interval of the stream s contains exactly one message. Thus, we can say that ts(s) implies msgs (1) but not vice versa. We also allow to use standard logical quantifiers ∀ and ∃ as well as the following operators: ∧ denotes AND, ∨ denotes OR, = denotes equality, → denotes implication. To refine the time granularity, we use the operator s 'n . This operator splits every time interval of the stream s into n time intervals. We have defined three versions of this operator: – to locate all messages from the original time interval to the first of the n corresponding intervals, – to locate all messages from the original time interval to the last of the n corresponding intervals, – to distribute the messages from the time interval of the original stream over the n corresponding intervals. To make the time granularity more coarse, we use the operator s .n . It joins n time intervals of the stream s into a single time interval. The time stamp operator tm returns for a timed stream s and a natural number k an index of time interval in which the k th message in the stream s is transmitted. S s filters away messages from each time interval The filtering operator M ○ of the timed stream s if these messages do not belong to the filtering set M . To represent real objects that can physically change their location in space, we define so-called sp-objects. An sp-object is defined not only by its behavioural specification but also by a tuple < location, speed , direction, radius, occupiedspace > In FocusST this tuple is specified using

– a special global (in the scope of the system specification) constant rad associated with an elementary so-object to represent the radius of the maximal space the sp-object can “cover” in the worst case; In the case an sp-object S is a composition (system) of a number of other sp-objects, we calculate its rad by analysing which space its subcomponents can occupy in the worst case: S .rad = max (WCX , WCY )/2 WCX and WCY being the maximum extensions of all of the subcomponents of S in direction x respective y; – four special global (in the scope of the system specification) variables to store for each sp-object its  current location ∈ Space (i.e., central point of the sp-object),  current speed ∈ N,  current direction ∈ Directions, and  current rzone ∈ Zone. The type Space is a tuple of two Cartesian coordinates xx and yy defined over N: def

Space = N × N The type Directions represents an angle in the Cartesian coordinate system: def

Directions = {0, . . . , 359} The type Zone is a tuple of Cartesian coordinates of two spatial points X and y (minX , minY , maxX , maxY ) defined over N, where X correspond to the upper left corner and Y corresponds to the upper right corner of the corresponding zone. def

Space = N × N × N × N The behavioural specification of the corresponding component can contain constrains on the speed, direction, and location of the so-object as well as on spatiotemporal dependencies among the so-objects in the system. While verifying the corresponding properties we can ensure, for example, that the object does not exceed its speed limit, does enter specific areas or does not collide with another so-object. For composite so-objects we also have additional constraints: ∀ S , C : C ∈ subcomp(S ) → (S .rzone.minX ≤ S .C .rzone.minX ∧ S .rzone.minY ≤ S .C .rzone.minY ) ∧ (S .rzone.maxX ≥ S .C .rzone.maxX ∧ S .rzone.maxY ≥ S .C .rzone.maxY ) ∀ k , S , C : C ∈ subcomp(S ) → (k ≤ S .rzone.minX → (k + S .C .rad ) ≤ S .C .location.xx )

4

Core Structure of FocusST Specifications

A template for a general FocusST specification is presented below: ComponentName in

x1 : InType1 , . . . , xm : InTypem

out

y1 : OutType1 , . . . , yn : OutTypen

timed

local v1 ∈ VarType1 , . . . , vk ∈ VarTypek init v1 = varValue1 , . . . , vk = varValuek asm A1 A2 ...

FirstAssumptionFormula SecondAssumptionFormula

gar I1 y10 = yValue1 I2 y20 = yValue2 ... ∀t ∈ N : B1 FirstProperty B2

SecondProperty

B3 ...

ThirdProperty

The in and out sections are used to specify input and output streams of the corresponding types: – x1 , . . . , xm are input streams of the types InType1 , . . . , InTypem , respectively; – y1 , . . . , yn are input streams of the types OutType1 , . . . , OutTypen , respectively. The local variables and their initial values are specified in the sections local and init: v1 , . . . , vk are local variables of the types VarType1 , . . . , VarTypek and with the initial values varValue1 , . . . , varValuek , respectively. We specify every component using assumption-guarantee-structured templates. This helps avoiding the omission of unnecessary assumptions about the system’s environment since a specified component is required to fulfil the guarantee only if its environment behaves in accordance with the assumption.

The keyword asm lists the assumption that the specified component demands from its environment, for example that all the input streams should contain exactly one message per time interval (i.e., to be time-synchronous). The component behaviour that should be guaranteed in the case all assumptions are fulfilled, is then described in the specification section gar. Each formula in the assumption and guarantee-section is numbered. For easier referencing, we propose to number assumptions by A1, A2, A3, . . . , initial guarantees by I 1, I 2, I 3, . . . , and the core guaranteed behavioural properties by B 1, B 2, B 3, . . . . The behavioural properties are usually either defined over all time intervals t ∈ N or are presented by the corresponding predicates, e.g., ts. Under the initial guarantees we understand the initial values on the output streams: in the case of strongly-causal components we might need to specify output values explicitly. The guaranteed behaviour is specified as a special form of timed automata that we name Timed State Transition Diagrams (TSTDs). A TSTD can be described in as a diagram , a textual form, or a special kind of tables including a number of new operators that work on time intervals. For a real-time system S with a syntactic interface (IS  OS ), where IS and OS are sets of timed input and output streams respectively, a TSTD corresponds to a tuple (State, state0 , IS , OS , →), in which State is a set of states, state0 ∈ State is the initial state, and → ⊆ (State × IS × State × OS ) represents the transition function of the TSTD.

5

Readability and Usability

FocusST allows to use so-called implicit else-case constructs. That means, if a variable is not listed in the guarantee part of a transition, it implicitly keeps its current value. An output stream not mentioned in a transition will be empty. In a component model, one often has transitions with local variables that are not changed. Also, frequently outputs are not produced, e.g., in the case when a component gets no input or some preconditions necessary to produce a nonempty output are violated. In many formal languages this kind of invariability has to be defined explicitly in order to avoid underspecified component specifications. To make our formal language better understandable for programmers, we use in FocusST so-called implicit else-case constructs. That means, if a variable is not listed in the guarantee part of a transition, it implicitly keeps its current value. An output stream not mentioned in a transition will be empty. We also do not require to introduce auxiliary variables explicitly: The data type of a not introduced variable is universally quantified in the specification such that it can be used with any data value. To increase readability of the model, we use the following colour notation:

– Components: strongly-causal elementary components are presented by blue blocks, weakly-causal elementary components are presented by green blocks, where the white blocks denote composite components; – Streams: the streams fulfilling the ts property are marked red, the streams fulfilling the msg(1) property are marked blue, all other streams are marked black.

6

Example: Steam Boiler

The main idea of the steam boiler specification was taken from [11]. The steam boiler has a water tank, which contains a number of gallons of water, and a pump, which adds 10 gallons of water per time unit to its water tank, if the pump is on. At most 10 gallons of water are consumed per time unit by the steam production, if the pump is off. The steam boiler has a sensor that measures the water level. Initially, the water level is 500 gallons, and the pump is off. The specification group SteamBoiler consists of the following components: SystemReq (general requirements specification), ControlSystemArch (system architecture), SteamBoiler, Converter, and Controller. We define the data type WaterPumpState to denote the state of the steam boiler pump: type WaterPumpState = PumpOn | PumpOff The specification SystemReq describes the requirements for the steam boiler system: (1) in each time interval the system outputs it current water level in gallons and this level should always be between 200 and 800 gallons; (2) the system outputs the information on the water level each time interval. The specification Controller describes the controller component of the system. The controller is responsible for switching the steam boiler pump on and off, and it remembers the current state of the pump as its local state. The behaviour of this component is asynchronous to keep the number of control signals (to switch the pump on and off) as small as possible. It is weakly-causal, having no delays in his output. SystemReq out currentWaterLevel : N asm A1

true

gar B1 B2

ts(currentWaterLevel ) ∀ t ∈ N : 200 ≤ ft.currentWaterLevel j ≤ 800

timed

ControlSystemArch

timed

Converter   controlSignal  

controlSignalTS  

SteamBoiler  

waterLevel  

Controller  

waterLevelOut  

Controller in

waterLevel : N

out

controlSignal : Bit

local pump ∈ WaterPumpState init pump = PumpOff asm A1

ts(waterLevel )

gar ∀t ∈ N : B1 pump = PumpOff ∧ ft.waterLevel t > 300 → pump 0 = PumpOff ∧ controlSignal t = hi B2

pump = PumpOff ∧ ft.waterLevel t ≤ 300 → pump 0 = PumpOn ∧ controlSignal t = h1i

B3

pump = PumpOn ∧ ft.waterLevel t < 700 → pump 0 = PumpOn ∧ controlSignal t = hi

B4

pump = PumpOn ∧ ft.waterLevel t ≥ 700 → pump 0 = PumpOff ∧ controlSignal t = h0i

timed

The original Focus specification of the Controller component, cf. [11], uses mutually recursive functions on and off to specify the local state of the component. To increase the understandability of the specification, we simply use the component state instead of mutually recursive functions. In this particular case, we can also provide a semantically equivalent specification of controller that consist of a single formula combined out of if-then-else-fi constructs: Controller in

waterLevel : N

out

controlSignal : Bit

timed

local pump ∈ WaterPumpState init pump = PumpOff asm A1

ts(waterLevel )

gar ∀t ∈ N : B1 if pump = PumpOff then if ft.waterLevel t > 300 then pump 0 = PumpOff ∧ controlSignal t = hi else pump 0 = PumpOn ∧ controlSignal t = h1i fi else if ft.waterLevel t < 700 then pump 0 = PumpOn ∧ controlSignal t = hi else pump 0 = PumpOff ∧ controlSignal t = h0i fi fi

The specification SteamBoiler describes steam boiler component, which has to control the current water level every time interval. The initial water level is specified to be 500 gallons. For every point of time the following must be true: – if the pump is off, the boiler consumes at most 10 gallons of water (i.e., any number of gallons between 0 and 10), – if the pump is on, at most 10 gallons of water (i.e., any number of gallons between 0 and 10) will be added to its water tank. The Converter component simply converts the asynchronous output produced by the controller to time-synchronous input for the steam boiler.

SteamBoiler in

controlSignalTS : Bit

out

waterLevel , waterLevelOut : N

asm A1

ts(controlSignalTS )

gar I1

waterLevel 0 = h500i

B1

timed

waterLevel = waterLevelOut

∀t ∈ N : B2 ∃ r ∈ N : 0 < r ≤ 10 ∧ if controlSignalTS t = h0i then waterLevel t+1 = hft.waterLevel t − r i else waterLevel t+1 = hft.waterLevel t + r i fi

Converter in

controlSignal : Bit

out

controlSignalTS : Bit

local currentControlSignal ∈ Bit init currentControlSignal = 0 asm A1

msg1 (controlSignal )

gar B1

ts(controlSignalTS )

∀t ∈ N : B2 if controlSignal t 6= hi then currentControlSignal 0 = ft.controlSignal t else currentControlSignal 0 = currentControlSignal fi B3

controlSignalTS t = hcurrentControlSignal i

timed

7

Conclusions

The understandability, comprehensibility and scalability of the formal specifications have been hypothesized as hindering factors for their adoption in industry. Jones et al. [17], Jackson [16], Atzeni et al. [3] as well as Bennion and Habli [5] presented promising approaches in the context of industrial projects: lightweight formal methods, where the lightweight verification does not require special expert and can be assigned to the testing group. To make a formal method really adopted, it should be not only sound, but also comprehensive and easyto-understand. In this report we presented a summary of the core operators and features of the FocusST specification framework. The goal of this summary is to provide a basis for further spatio-temporal analysis of the system properties as well as an interface for the further connection of the FocusST to other frameworks and techniques. The framework was developed with a special attention to the human factor analysis within formal methods to increase the readability and understandability of the formal specifications. To discuss the general idea of these operators and features and to illustrate how the specification framework can be applied, we use a Steam Boiler System example, which is one of the common examples to present interactive systems. Our future research direction comprises work on the modelling levels for spatio-temporal systems, that reflect the idea of remote integration/interoperability testing in a virtual environment [7, 8, 27], as well as on the optimisation of the verification methodology focusing on the spatial aspects and the corresponding case studies.

References 1. N. Alzahrani, M. Spichkova, and J. Blech. Spatio-temporal model for property based testing. Software Technologies: Applications and Foundations, (HumanOriented Formal Methods), 2016. 2. R. Alur and D. L. Dill. A Theory of Timed Automata. Theoretical Computer Science, 126:183–235, 1994. 3. Atzeni, A., Su, T., and Montanaro, T. (2014). Lightweight formal verification in real world, a case study. In Advanced Information Systems Engineering Workshops, pages 335–342. Springer. 4. R. Alur and P. Madhusudan. Decision Problems for Timed Automata: A Survey. In SFM, pp. 1–24, 2004. 5. Bennion, M. and Habli, I. (2014). A candid industrial evaluation of formal software verification using model checking. In Companion Proceedings of the 36th International Conference on Software Engineering, pages 175–184. ACM. 6. J. C. Blanchette, S. B¨ ohme, and L. C. Paulson. Extending Sledgehammer with SMT solvers. In N. Børner and V. Sofronie-Stokkermans, editors, Automated Deduction, volume 6803 of Lecture Notes in Computer Science, pages 116–130. Springer, 2011.

7. J. O. Blech, M. Spichkova, I. Peake, H. Schmidt. Cyber-Virtual Systems: Simulation, Validation & Visualization. In 9th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2014), 2014. 8. J. O. Blech, M. Spichkova, I. Peake, H. Schmidt. Visualization, Simulation and Validation for Cyber-Virtual Systems. In Evaluation of Novel Approaches to Software Engineering, pages 140-154, 2015. 9. D. Bjørner and K. Havelund. 40 years of formal methods. In FM 2014: Formal Methods, pages 42–61. Springer, 2014. 10. P. Bouyer, N. Markey, and O. Sankur. Robust Model-checking of Timed Automata via Pumping in Channel Machines. Formal Modeling and Analysis of Timed Systems, Springer, 2011. 11. M. Broy and K. Stølen. Specification and Development of Interactive Systems: Focus on Streams, Interfaces, and Refinement. Springer, 2001. 12. M. Feilkas, A. Fleischmann, F. H¨ olzl, C. Pfaller, S. Rittmann, K. Scheidemann, M. Spichkova, and D. Trachtenherz. A Top-Down Methodology for the Development of Automotive Software. Technical Report TUM-I0902, TU M¨ unchen, 2009. 13. M. Feilkas, F. Hlzl, C. Pfaller, S. Rittmann, B. Schtz, W. Schwitzer, W. Sitou, M. Spichkova, and D. Trachtenherz. A Refined Top-Down Methodology for the Development of Automotive Software Systems - The KeylessEntry-System Case Study. Technical Report TUM-I1103, TU M¨ unchen, 2011. 14. R. G´ omez and H. Bowman. Efficient detection of zeno runs in timed automata. In Proceedings of the 5th international conference on Formal modeling and analysis of timed systems, FORMATS’07, pages 195–210. Springer-Verlag, 2007. 15. T. Henzinger, Z. Manna, and A. Pnueli. What Good are Digital Clocks? In Colloq. on Automata, Languages and Programming, pp. 545–558. Springer, 1992. 16. Jackson, D. (2001). Lightweight formal methods. In FME 2001: Formal Methods for Increasing Software Productivity, pages 1–1. Springer. 17. Jones, C. B., Jackson, D., and Wing, J. (1996). Formal methods light. Computer, (4):20–22. 18. C. K¨ uhnel and M. Spichkova. FlexRay und FTCom: Formale Spezifikation in FOCUS. Technical Report TUM-I0601, TU M¨ unchen, 2006. 19. C. K¨ uhnel and M. Spichkova. Upcoming Automotive Standards for Fault-Tolerant Communication: FlexRay and OSEKtime FTCom. In Proceedings of EFTS 2006 International Workshop on Engineering of Fault Tolerant Systems, 2006. 20. T. Nipkow, L. C. Paulson, and M. Wenzel. Isabelle/HOL – A Proof Assistant for Higher-Order Logic, volume 2283 of LNCS. Springer, 2002. 21. A. Puri. Dynamical Properties of Timed Automata. Discrete Event Dynamic Systems, 10(1-2):87–113, 2000. 22. M. Spichkova. FlexRay: Verification of the FOCUS Specification in Isabelle/HOL. A Case Study. Technical Report TUM-I0602, TU M¨ unchen, 2006. 23. M. Spichkova. Specification and Seamless Verification of Embedded Real-Time Systems: FOCUS on Isabelle. PhD thesis, TU M¨ unchen, 2007. 24. M. Spichkova. Focus on processes. Tech. Report TUM-I1115, TU M¨ unchen, 2011. 25. M. Spichkova. Human Factors of Formal Methods. In In IADIS Interfaces and Human Computer Interaction 2012. IHCI 2012, 2012. 26. M. Spichkova. Design of formal languages and interfaces: “formal” does not mean “unreadable”. In K. Blashki and P. Isaias, editors, Emerging Research and Trends in Interactivity and the Human-Computer Interface. IGI Global, 2013. 27. M. Spichkova, H. Schmidt, and I. Peake. From Abstract Modelling to Remote Cyber-Physical Integration/Interoperability Testing. In Improving Systems and Software Engineering Conference. 2013.

28. M. Spichkova, J. Blech, P. Herrmann, and H. Schmidt. Modeling spatial aspects of safety-critical systems with focus-st. In MoDeVVa2014 Vol-1235-4, pages 49–58. Ruzica Piskac, Redaktion Sun SITE, 2014. 29. M. Spichkova, H. Liu, M. Laali, and H. W. Schmidt. Human factors in software reliability engineering. In Workshop on Applications of Human Error Research to Improve Software Engineering (WAHESE2015), 2015. 30. M. Spichkova, X. Zhu, and D. Mou. Do we really need to write documentation for a system? In International Conference on Model-Driven Engineering and Software Development (MODELSWARD’13), 2013. 31. M. Spichkova and A. Zamansky. Teaching formal methods for software engineering. In 11th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE), 2016. 32. M. Spivey. Understanding Z – A Specification Language and Its Formal Semantics. Cambridge Tracts in Theoretical Computer Science 3. Camb. Univ. Press, 1988. 33. M. Spivey. The Z Notation: A Reference Manual, 2. Ausgabe. Prentice-Hall International Series in Computer Science. Prentice-Hall, 1992.