Refinement Using µ-charts: The Compaq Grand Slam Cup Case Study Revisited

Transcription

1 Refinement Using µ-charts: The Compaq Grand Slam Cup Case udy Revisited Hubert Baumeister Institut für Informatik Universität München Oettingenstr München, Germany Christoph Maier FAST e.v. Arabellastr München, Germany Martin Rappl Institut für Informatik TU München Arcisstr München, Germany Peter Scholz BMW Technik GmbH München, Germany Abstract In practice, software systems are often developed on an ad hoc basis using at most some semi-formal diagrams to describe the desired system behavior. This often leads to systems with unintended behavior. One also lacks the means to prove properties of the system. On the other hand, a lot of formal specification formalisms exist that allow to specify a system in a formal way and prove properties of the system. However, these formalisms are considered as not applicable to real world software engineering by practitioners. In this paper, we try to refute this consideration by specifying a real world application, the Compaq Grand Slam Cup live scoring board [2], with µ-charts [5], a statecharts-like formal specification method. Keywords: Formal Specification, Refinement, atecharts, Case udy 1 Introduction In practice, software systems are often developed on an ad hoc basis using at most some semi-formal diagrams to describe the desired system behavior. This often leads to systems with unintended behavior. One also lacks the means to prove properties of the system. On the other hand, a lot of formal specification formalisms exist that allow to specify a system in a formal way and prove properties of the system. However, these formalisms are considered as not applicable to real world software engineering by practitioners. In this paper we try to refute this consideration by specifying This work was partially supported by the Bayerische Forschungsstiftung. appeared in the proceedings of the 17th Annual AoM/IAoM conference on computer science, San Diego, California USA, August 6 8, 1999, Number 2 Part B, pages Maximilian Press Publishers baumeist@informatik.uni-muenchen.de cma@fast.de rappl@in.tum.de Peter.Scholz@bmw.de a real world application, the Compaq Grand Slam Cup live scoring board [2], with µ-charts [5], a formal specification method. The formalism of µ-charts is a dialect of the well known statecharts by Harel [1], with a precise definition of syntax and semantics and a refinement calculus. The requirements of the system, which is formally developed in this paper, are taken from a case study done within the FORSOFT project A2 Distributed Systems in Open Networks 1 in the context of the Internet Web site engineering for the Compaq Grand Slam Cup 1997 in Munich [2]. This site includes an applet to watch a live scoring of the current game via Internet. To this end, two applications were designed and developed: the applet itself and a server to read the scoring data and generate the data feed for the applet. The design of these applications is used to demonstrate the practical relevancy of µ-charts in the development of Internet applications. The paper is structured as follows: in Section 2, we give a short introduction to the statechart formalism and define the syntax and semantics of our dialect, the µ-chart formalism. Next, the refinement calculus for µ-charts is introduced. Based on this theory, the specification of the two applications is developed step by step in Section 3, by applying the rules of the refinement calculus. The paper concludes with a short summary of the advantages gained by using a formal specification method. 2 µ-charts This section introduces µ-charts, which are a visual formalism for the state-based description of reactive systems. Despite of being a visual formalism, µ-charts have welldefined syntax and a formal semantics. In Scholz [4] a design process, based on µ-charts, is presented, comprising abstract description of reactive systems, systematic transformation of abstract specifications into detailed specifica

2 tions and formal verification through model checking. µ- charts are a variant of Harel s statecharts [1], which, however, avoid the semantic problems and inconsistencies of the latter and are therefore better suited as a basis for distributed implementations of a specification. The basic building block of µ-charts are sequential automata. More complex µ-charts can be built from other µ- charts by using parallel composition, hierarchical decomposition and hiding. With every µ-chart S there is associated an input interface In Sµ, consisting of a set of input signals and an output interface Out Sµ, which is a set of output signals, such that In Sµ and Out Oµ are disjoint. An input event is a finite subset of In Sµ and an output event a finite subset of Out Sµ. Given an infinite sequence of input events, a µ-chart S produces an infinite sequence of output events. S may be deterministic; in this case S produces always the same sequence of output events for a given sequence of input events. If S is non-deterministic, S may produce different sequences of output events for the same sequence of input events. Thus, the denotation of a µ-chart is a relation between the set of infinite sequences of input events and the set of infinite sequences of output events. 2.1 Sequential Automata A sequential automaton consists of states and transitions. ates are shown as rectangles with rounded corners and transitions by arrows from the source state to the target state. Each state has a name, which is written inside the rectangle; however, if not needed further, the name of a state may be omitted. The execution of sequential automata is based on a discrete time model. At each instant in time, a sequential automaton is in exactly one state. At the beginning it is in one of the states marked as initial by an arrow going from a small solid filled circle to the initial state. Note that in the case of several initial states, an arbitrary of these states is chosen. µ-charts have no final state as they are intended to model the behavior of reactive systems, which react forever and thus do not terminate. Transitions have labels of the form condition/action. An automaton can proceed in one step from one state to another via a transition, performing the action associated with that transition, if its condition evaluates to true. If there are several transitions whose conditions evaluate to true, one of these transitions is chosen at random. A particular feature of µ-charts is their behavior if there exists no transition whose condition evaluates to true. In this case, the behavior of the automaton is chaotic, that is, it may perform any action. To ease writing, the condition part and/or the action part may be omitted. A missing condition part means that the transition can be always performed and a missing action part means that no actions are performed. A condition is either a signal, which means that the condition is true if this signal occurs in the current input event, or a condition is a boolean expression built from other conditions with its usual semantics. For example, for the expression s to be true, the signal s may not occur in the current input event. An action is either skip, which means that no action is performed, a signal s, which means that if the action is executed then the signal s occurs in the current output event, or the parallel composition of two actions a 1 and a 2, denoted by a 1 a 2. In addition, a set of integer variables V l is associated to an automaton; the conditions can refer to the value of these variables and actions can modify them. The initial values of the variables are given as statements key value as part of the initial states. Thus, the syntax of conditions c and actions a is as follows: c :: true false e 1 e 2 e 1 e 2 s i c c 1 c 2 a :: skip Y : e s o e 1 e 2 where s i is an input signal, s o an output signal, Y ¾ V l denotes a variable, n an arbitrary integer and e 1 and e 2 are arithmetic expressions given by: e :: n Y e 1 binop e 2 Here binop denotes the usual binary operations on integers, such as addition, subtraction or multiplication. The input interface of an automaton is the collection of all signals used in the condition part of a transition and the output interface is the collection of all signals used in the action part of some transition. stop stop/x : 0 running stopped x 0 tick/x : x 1 tick start Figure 1: Example of a Sequential Automaton As an example of a sequential automaton, Fig. 1 shows a model of a stopwatch. The input interface consists of the signals start, stop and tick and the output interface is empty. In the initial state the variable x is 0 and the stopwatch is in state stopped. The signal tick models the ticks of a global clock. While in stopped, the signal tick does not change the value of x. When pressing the start button, modeled by the signal start, the automaton moves to state running. While in running, the signal tick increments x by one. When receiving stop, the automaton moves to state stop again. Note that this transition does not reset x to 0. This only happens when receiving stop in state stopped. 2

3 2.2 Parallel Composition Parallel composition is used to construct new µ-charts from other µ-charts by executing them in parallel. The composition is synchronous, that is, there is a common system clock and all the component advance simultaneously at the tick of that clock. Interaction between the components may occur if the input interfaces of the components share signals with the output interfaces. Let S 1 and S 2 be two µ-charts and L be a subset of the set of signals occurring in one of the input interfaces of S 1 and S 2 and also in one of the output interfaces. Any output signal in L, occurring at some point in time in an output event of S 1 and S 2, is assumed to be present the same instant in the input events of S 1 and S 2. If L is empty, no interaction occurs, even if the input-/ output interface of the components share signals. The notation for the parallel composition is a signal set L between two dashed lines separating S 1 and S 2 (cf. Fig. 2). If L is empty, only one dashed line is drawn. 2.3 Signal Hiding S 1 L S 2 Figure 2: Parallel Composition Specifying large systems possibly leads to large charts with many signal names. This may promote name clashes which could be avoided by the utilization of local signal hiding. Given a µ-chart S with input interface I, output interface O and set of signals K then the result of hiding the signals K in S is the µ-chart S ¼ having as input interface I and as output interface the set of signals O without the signals in K. If i is a sequence of input events for which S generates the output sequence o then S ¼ generates the output sequence o ¼ which is the same as o but has all occurrences of elements of K removed. As the notation for hiding we use a rectangle with rounded corners for S and attach a small rectangle with a label denoting the set of hidden signals K (cf. Fig. 3). S K Figure 3: Signal Hiding 2.4 Hierarchical Decomposition Hierarchical decomposition allows further refinement of states in a sequential automaton by other µ-charts. When- σ S Figure 4: Hierarchical Decomposition ever the automaton reaches one of these states, the corresponding µ-chart is activated and runs until an outgoing transition from that state is fired. Assume that we want to decompose state σ into µ-chart S. This is depicted by splitting a state into two compartments, putting σ in the upper compartment and the diagram for S into the lower one (cf. Fig. 4). The semantics of hierarchical decomposition is defined by syntactical transformation of the hierarchical decomposition into parallel composition and hiding. Details of this translation can be found in [4, 5]. 2.5 Refinement It is usually impossible to carry out the transformation from an abstract specification to one that can be used as a basis for implementation in only one step. Rather, such systems will be developed by applying consecutive refinement steps, each step describing the overall system behavior more concrete than the previous one. Given two µ-charts S 1 and S 2 with the same input-/output interface; the system S 1 is a refinement of S 2, written S 2 S 1, if for every sequence of input events i and possible sequences of output events o generated by S 1, o is also a possible output sequence of S 2 with respect to the same input sequence i. This means that the denotation of S 1, which is a relation between input and output sequences, is a subset of the denotation of S 2. However, S 1 and S 2 have not always the same input-/ output interfaces. Usually the refinement is more elaborated than the refined µ-chart and therefore the input-/ output interfaces of the refinement contain additional signals. In this case S 1 is a refinement of S 1, S 2 S 1, if the input-/ output interfaces of S 1 are supersets of the corresponding input-/ output interfaces of S 2 and if for any sequence of input events i, for which S 1 produces a sequence of output events o, S 2 produces the sequence o Out S 1 for the µ sequence of input events i In S 1. The sequence of events µ i In S and o 1 µ Out S 1 are obtained from i and o by removing all the signals not in In S 1 µ and Out S 1 µ, µ respectively. Refinement is transitive, that is, if S 1 is a refinement of S 2 and S 0 is a refinement of S 1 then S 0 is a refinement of S 2. Further, refinement is compositional, that is, for a complex µ-chart, the refinement of one of its components yields a refinement of the overall system. For example, if S is given by a parallel composition of the µ-charts S 1 and S 2 wrt. a set of signals L, and S ¼ 1 is a refinement of S 1, then the parallel composition of S ¼ 1 and S 2 wrt. L is a refinement of S. 3

4 Using µ-charts has the advantage that there exists conditions on the syntax of µ-charts that ensure sound refinement. In the following we present the conditions for sound refinement needed for the case study in Section 3. The complete set of refinement rules can be found in [4, 5]. Adding Transitions Given a sequential automaton, we can add a transition t from a state σ to σ ¼, provided that whenever the transition t may be performed, there is no other transition with source state σ which can be performed at the same time. This means that if the condition of t is c then for each other transition t i with source state σ and condition c i, c and c i are not allowed to be true at the same time. In this case, the automaton with the added transition is a refinement of the automaton without that transition. Modifying Transitions Given a sequential automaton S which has a transition t from state σ to σ ¼ with condition c and action a. We get a refinement S ¼ of S if we replace the action a by an action a a ¼, where the signals occurring in a ¼ are new signals, that is, are not signals from the output interface of S. We also get a refinement S ¼ of S if we strengthen the condition c to c c ¼¼, provided that there exists another transition t ¼ with source state σ such that t ¼ can be performed, whenever c is true but not c ¼¼. Parallel Composition The parallel composition of S 1 with S 2 with respect to a set of signals L is a refinement of S 1 if S 2 cannot produce any output signals that S 1 can produce and S 2 cannot feed back any input signals for S 1 (cf. Fig. 5). S 1 S 1 Out S 1 µ Out S 2 µ /0 L S 2 L In S 1 µ /0 Figure 5: Refinement of Parallel Composition Hierarchical Decomposition Another rule ensures that the hierarchical decomposition of a state σ within a sequential automaton A into a system S is a refinement of A, provided that S does not produce output signals which are either output- or input signals of A (cf. Fig. 6). 3 The Case udy The following quote from the project offer for the Compaq Grand Slam Cup 1997 (CGSC 97) describes the basic requirements and intentions for the scoring application. A σ A σ S Out Aµ Out Sµ /0 In Aµ Out Sµ /0 Figure 6: Refinement of Hierarchical Decomposition The real time aspect of the content is covered employing a Java applet to replicate the scoring board at the Olympiahalle not only in its appearance, but more importantly, in its informational value.... Actually, the applet serves two purposes. First, mimicking the scoring board at the Olympiahalle, it uses server-push communication to automatically update its display the very instant a point is made during every match. Since this mechanism could prove infeasible for handling several requests from the Internet at the same time, it will be deployed only at the Olympiahalle, serving less than 100 clients at a time. For the Internet, a second applet version using client-pull with a short refresh interval is being developed.... (FAST e.v., CGSC 97 Project offer, p.3) The offer states that there are two versions of the applet. One for people inside the Olympiahalle using server-push communication, and one for people from outside using client-pull communication. -push means that the applet registers itself as a client at the server. The server then sends new scoring data immediately after reading them. Client-pull means that the applet retrieves a file with the actual scoring from the Web site at a specified refresh rate. The basic structure of the system is shown in Fig. 7. It consists of the two components server and applet and of the data file for client-pull communication. The server has two input signals: newfile that signals the existence of a new data file and register, used by the applet to register for the server-push service. The applet has three input signals: update, used by the server to send new data, regok, send by the server after a successful registration for the serverpush service and refresh that tells the applet to reload the data file if it uses client-pull communication. The first behavior specification is shown in Fig. 8. The applet enters nondeterministically the state CP (clientpull) or tries to register for the server-push service by sending the signal register to the server. In the second case it waits until it receives the signal regok and enters then state SP. If it is in state SP it receives new data via signal update, otherwise it reloads the data file after receiving 4

5 newfile register Applet update regok data file Figure 7: System ructure refresh Applet /register regok timeout &!regok SP connerror &!update CP update refresh { update, register, regok } refresh. The server replies with regok when receiving register and sends signal update after receiving newfile. The actions that are needed to read, convert and write the data file are not shown in the diagram. This basic specification is now extended in the following sections using the syntactical rules of µ-charts and some common reasoning where the rules cannot be used directly. Applet /register regok SP CP update refresh { update, register, regok } Figure 9: Refinement: adding transitions is decomposed into two sub states: CONN (connected) and DISC (disconnected). neterror CONN DISC Figure 8: High Level Behavior Specification 3.1 Refinement Adding Transitions The first refinement step is applied to the applet as shown in Fig. 9. Two input signals were added to the applet. To exclude the possibility that the applet waits an infinitely long time for the server to acknowledge a register request with regok, the signal timeout is added. It ensures that the applet switches into clientpull mode after waiting a specific amount of time. It is also possible that the connection to the server breaks while using server-push communication. This error is signaled by connerror. In this case, the applet also switches into client-pull mode. By the rule for adding transitions this is a refinement, because regok and regok timeout cannot be true at the same time and similar for update and update connerror. Hierarchical Decomposition In this step, the basic state of the server is hierarchically decomposed (Fig. 10). If the connection to the supplier of the file containing the raw scoring data goes down, a message should be displayed to allow for immediate action. In addition, a message should be displayed if the network connection is working again. An error in the network connection is modeled with the new input signal of the server neterror. The signal newfile signales that the connection is working again. The basic state Figure 10: Hierarchical Decomposition of the server specification This decomposition is not covered by the syntactical rules because the master (the basic state of the server in Fig. 9) and the slave ( refinement) generate the same output signal, namely update. Nevertheless, it is a correct decomposition because, following the definition of refinement in Section 2.5, each time slave and master receive the signal newfile both generate the signal update. That means the reaction of the slave on receiving newfile is the same as that of the master. Parallel Composition In the next step a monitor component is added to the server (Fig. 11). It is used to enable a person to enter the actual scoring manually if the network connection to the raw data file is down. The monitor has two states: ACT (activated) and DEACT (deactivated). It changes its state to ACT when it receives act. In this state it is possible to enter data manually, modeled by the signal data. This data is sent via signal manfile to the server which in turn sends the data via signal update. The signals to activate and deactivate the monitor are added to the appropriate transitions of the server. This extension was done by first refining to ¼, using the rule for adding transitions and adding new actions to transitions, and then using the rule for parallel composition to ensure that the parallel composition of ¼ and Monitor is a refinement of ¼. By transitivity of the refinement re- 5

6 lation this ensures that the parallel composition is also a refinement of. Monitor data/manfile neterror /act ACT CONN act deact { manfile, act, deact } newfile /update*deact DEACT Monitor data/manfile neterror &!newfile /act ACT CONN DISC act deact { manfile, act, deact } newfile /update*deact manfile &!newfile /update DEACT DISC manfile &!newfile /update Figure 12: Refinement: Removing nondeterminism Figure 11: Parallel Composition: Adding a component Modifying Transitions The last step is to remove some more nondeterminism from the server specification (Fig. 12), which appears when the signals newfile and neterror occur at the same time in state CONN. This nondeterminism is removed by modifying the transition neterror to neterror newfile. This way, the signal newfile has always a higher priority than the other signals. Following the rules for modifying transitions, this refinement is sound, because whenever the signal neterror together with the signal newfile occurs in an event the system can perform a transition from CONN to CONN. 4 Conclusions This study demonstrates the advantages achieved for the specification and design process by using formal methods. Within only four refinement steps a rudimentary µ-chart is being transformed to a more elaborated one with the desired behavior. Furthermore the specification can be automatically translated into the input language of various model-checkers [4], for verifying liveness and safety properties. Malfunctions of the developed systems can be reduced to a minimum. In case of safety critical systems, the use of formal methods is essential. For implementation purposes target code can automatically be generated from the specification [3]. The error-prone process of manual code generation is omitted. References [1] D. Harel. atecharts: A visual formalism for complex systems. Science of Computer Programming, 8: , [2] Christoph Maier and Luis Mandel. An introduction to MOOD 2 specification and design of a live scoring system for the Compaq Grand Slam Cup Technical Report 9711, Institut für Informatik der Ludwig- Maximilians-Universität München, [3] J. Philipps and P. Scholz. Compositional specification of embedded systems with statecharts. In TAP- SOFT 97: Theory and Practice of Software Development, volume 1214 of Lecture Notes in Computer Science. Springer-Verlag, [4] Peter Scholz. Design of Reactive Systems and their Distributed Implementation with atecharts. PhD thesis, Technische Universität München, Institut für Informatik, August Appeared as Technical Report TUM-I9821. [5] Peter Scholz. A refinement calculus for statecharts. In First International Conference on Fundamental Approaches to Software Engineering (FASE 98), number 1382 in LNCS, pages , Lisbon, Portugal, Springer. 6