From an Abstract Object-Oriente Moel to a Reay-to-Use Embee System Controller Stanislav Chachkov, Diier Buchs Software Engineering Laboratory, Swiss Feeral Institute for Technology 1015 Lausanne, Switzerlan {Diier.Buchs,Stanislav.Chachkov}@epfl.ch Abstract. We present an example of a construction of an embee software system - a controller - from the formal specification to executable coe. The CO-OPN (Concurrent Object Oriente Petri Net) formal specification language is use for moelling the controller an the associate harware system with the inherent limitation of its physical components. CO-OPN formal language is base on coorinate algebraic Petri nets. The CO-OPN moel can be use to verify some properties of the controller in the concrete physical environnement. This is achieve by constraine animation of the vali prototype prouce by automatic coe generation. The possibility to incrementally refine the generate coe can be use to obtain a more efficient implementation. 1 Introuction Developing embee reactive software systems nees moelling tools that can capture the properties of the system to evelop as well as the structure of the interactions between the software an its environment. In this paper, we present a formal framework for the evelopment of embee systems from the moelling phase to the implementation. The approach we propose has aopte the object-oriente paraigm as a structuring principle. We have evise a general formalism which can express both abstract an concrete aspects of systems. This approach is calle Concurrent Object-Oriente Petri Nets (CO-OPN)[3][1]. An implementation can be automatically prouce from the abstract CO-OPN moel. We shortly escribe our coe generation techniques. Apart from the problem of proucing programs that respect the abstract moels an their particularities (non-eterminism, atomicity of the events, moularity inuce by Object-Oriente structure,...), we are particularly intereste to match the usual programming principles of the target language. For our purpose they will be the Java notion of component architecture, the JavaBeans moel[10]. In orer to cope with incremental refinement of the automatically generate prototype [6], it is important to be able to interconnect the prouce components with other components or with stanar libraries (for example user interface libraries). This will be achieve by fulfilling the rules of the component moel of target language an by transparently introucing the support for transactions an non-eterminism. We will first briefly explain how to start from a iagram establishing the interconnection of the application to the outsie worl elements an how to prouce, step by step, a moel that will be use to erive automatically a program. An example of a rink ispenser will illustrate our approach. The complete specification an supporting tools can be foun at: http://lglwww.epfl.ch/conform/ CoopnTools The paper is organize as follows. In Section 2, we present the rink ispenser an iscuss the moels that we can prouce using CO-OPN. In section 3, we present our basic mapping metho for generating OO coe from CO- OPN an iscuss implementation problems. In section 4, we iscuss how to use the prouce software for valiation an verification purposes. 2 Moelling with CO-OPN CO-OPN is an object-oriente moelling language, base on Algebraic Data Types (ADT), Petri nets, an IWIM coorination moels [5]. Hence, CO-OPN concrete specifications are collections of ADT, class an context (i.e. coorination) moules [9]. Syntactically, each moule has the same overall structure; it inclues an interface section efining all elements accessible from the outsie, an a boy section incluing the local aspects private to the moule. Moreover, class an context moules have convenient graphical representations which are use in this paper, showing their unerlying Petri net moel. Low-level mechanisms an other features ealing specifically with object-orientation, such as sub-classing an sub-typing, are out of the scope of this paper, an can be foun in [1] [3]. 1
2.1 The Drinks Dispenser In orer to present a concrete example of moelling, we chose to stuy a simple but non-trivial kin of reactive system: a Drink Dispenser Machine (DDM) controller. The aim of this stuy is to elaborate a CO-OPN specification of the ispenser an to explain how to generate the controller program. Moreover, we are intereste to valiate an verify properties of the DDM Controller by using a moel incluing harware parts, an also to verify the DDM in the context of human interaction. Therefore, our moel has three levels: Controller, Machine an Human Interaction (not etaile here). First of all, we will explain the steps that can lea to the CO-OPN moel of the DDM controller. In figure 1, the reaer can have a feeling how this machine usually works. Firstly, the customer has to introuce coins in the machine (1), then s/he has to select the esire rink (2) an finally the ispenser supplies the rink via the bottom rawer (3). 2.90 1 2). DC SB RB LCD givedrink selectdrink returncoins isplay m Controller insertcoin c takecoins returncoins MB adrink SP acontainer price p Figure 2 : Protocol of Controller When aing rinks the service person (SP) communicates with the controller irectly by notifying adrink an acontainer events. The Money Box is compose with two ifferent collectors of coins: the first one keeps coins until the customer chooses a rink or presses the return button, an the secon one receives coins for istribute rinks. Drinks are store in containers. Each container is associate with a kin of rink an a price. Initially, the DDM is empty. The service person installs containers an as rinks to them. The DDM equipment introuce some constraints: the money box has limite capacity, the number of slots for DC an the quantity of bottles in DC are also limite. 2.2 CO-OPN Coorination moel 3 Figure 1 : The rinks ispenser machine (real life view) For such a system we are intereste in a first approach to etermine the components an the various interactions between them. The main concepts use to express the structure an the behaviour of the system are: a coorination moel for escribing the relations between the system components, object orientation for the structure an content of the system, causality relations for the ynamic aspects that must be reflecte with non-eterministic an concurrent behaviours. The controller is a program that coorinates the activities of DDM components: money box (MB), containers of rinks (DC), LCD isplay, rink selection buttons (SB) an return coins button (RB). The controller receives messages from an sens commans to the equipment (figure 2 In this part the various concept of CO-OPN will be introuce in the necessary orer for the moelling of the DDM. As we use a kin of top-own strategy for moelling, we will first start by presenting the interface of the machine given by the top-level coorination entity calle DrinksDispenser context. A useful approach for builing systems compose of many computing entities is to use the high-level concept of coorination programming [12]. The term coorination theory refers to theories about how coorination can occur in various kins of systems. We state that coorination is managing epenencies among activities. Taking a step further in this irection, it appeare that coorination patterns are likely to be applie since the beginning of the esign phase of the software evelopment. This fact gave birth to the notion of coorination evelopment [5]. This process involves the use of specific coorination moels an languages, aapte to the specific nees encountere uring the esign phase as expresse in the rinks ispenser. Due to their intrinsic nature, IWIM (Iealize Workers, Iealize Managers) coorination moels [13] are particularly well suite for the coorination of software elements uring the esign phase [4]. The coorination layer of CO-OPN [5] [3] [4] is a coorination language 2
: selectdrink _ : rink DrinksDispenser selectdrink _ : rink a container _ price _ : rink, money cancel cancel Controller a rink _ : rink returnmoney isplayamount _ : money takemoney givedrink _ : rink adrink _ : rink acontainer _ : rink returncoins takecoins takedrink _ : rink moneybox : PhysicalMoneyBox containers : PhysicalDrinksContainers returnmoney base on a IWIM moel, suite for the formal coorination of object-oriente systems. CO-OPN context moules efine the coorination entities [11], while CO-OPN classes (an objects) efine the basic coorinate entities of a system. CO-OPN allows one to cover the formal evelopment of concurrent software from the first formal specification up to the final istribute software architecture [1]. 2.3 Coorination with Contexts isplayamount _ : money givedrink _ : rink Figure 3 : The rinks ispenser machine moel In figure 3 we can see the DrinksDispenser machine incluing the Controller context an a moel of the physical components PhysicalMoneyBox an PhysicalDrinksContainers, with the input events (or the provie services calle methos - black rectangles) an output events (or the require services calle gates - white rectangles). The Controller context contains sub-components that interact to provie the controller behaviour. The controller sub-components are two objects which are instances of the classes MoneyBox an CentralUnit as epicte in figure 4. In this picture the oriente arcs between methos or gates are use to efine strong synchronization between events. In CO-OPN, it means that the firing of synchronize events is strongly synchronous an atomic. The synchronization of entities in a context is an oriente couple of synchronization expressions of the form: synchro With synchro. Synchronisation expressions are built with the simultaneity, the sequence an the noneterminist operators. The MoneyBox component is evote to managing the money of the ispenser. The CentralUnit component transmits the requests to the specific rink container. The container objects, each containing one kin of rinks, are instantiate by means of the acontainer _ price _ metho that must be calle before the a rink _ metho. In the figure 3, we can observe that the physical components are uplicate by logical components in the controller using simultaneous synchronization (circle with // insie). Controller cancel (2) (1) returnmoney takemoney _ : money currentamount _ : money moneybox : MoneyBox selectdrink _ : rink istribute _ : rink takemoney _ : money returnmoney isplayamount _ : money takemoney cu : CentralUnit givedrink _ : rink Figure 4 : The static components instances insie the Controller context Pushing a rink selection button sens the event selectdrink to the controller. If DDM contains a rink an enough money then commans takemoney an istributedrink are emitte, otherwise nothing is one. Let us explain how this behaviour is efine by the (1) (2) (3) : rink a container _ price _ rink _ rink a 3
Controller context. In orer to express this behaviour we link selectdrink event to a synchronisation: cu.istributedrink.. takemoney.. givedrink. The event selectdrink will complete with success if an only if each of three sub-events are complete with success. cu.istributedrink will check if there is a rink in DDM an enough money in moneybox. If those preconitions are satisfie the system will evolve by removing one rink an moving the money from intermeiary collector to the permanent one. In the case of success takemoney..givedrink will be emitte by controller to connecte equipment (MB an DC). Before explaining the components, we will quickly give an outline of the way values can be efine in CO- OPN, using algebraic ata types. 2.4 ADT Moules CO-OPN ADT moules efine ata types by means of algebraic specifications. Each moule escribes one or more sorts (i.e. names of ata types), along with generators an operations on these sorts. The properties of the operations are given in the boy of the moule, by means of positive conitional equational axioms. For instance, figure 5 escribes the ADTs efining two sorts, coin an rink, efine by several generators an one operation, value _. Having the ADT, it is possible to escribe the ynamic components of a CO-OPN specification: the classes. ADT Drink; Interface Sort rink; Generators Ice Tea, Soa, Beer, Whisky : -> rink; En Drink; ADT Coins; Interface Use Money; Sort coin; Generators 5c,10c,20c,50c : -> coin; 1f,2f,5f : -> coin; Operation value _ : coin -> money; Boy Axioms (value 5c) = 5; (value 10c) = 10; (value 20c) = 20; (value 50c) = ((2*(value 20c))+(value 10c)); (value 1f) = (2*(value 50c)); (value 2f) = (2*(value 1f)); En Coins; Figure 5 : The Drink an Coin ADTs 2.5 Class Moules In this subsection we will show more etail on the classes that compose the DrinksDispenser system, an using this example explain the main elements of a CO- OPN moel. CO-OPN classes are escribe by means of moular algebraic Petri nets with particular parameterise external transitions which are the methos of the class. The behaviour of transitions are efine by so-calle behavioural axioms, similar to the axioms in an ADT. A metho call is achieve by synchronizing external transitions, accoring to the fusion of transitions technique. The axioms have the following shape: Con => eventname With synchro : pre -> post in which the terms have the following meaning: Con is a set of equational conitions, similar to a guar; eventname is the name of a metho with the algebraic term parameters; synchro is the synchronization expression efining the policy of transactional interaction of this event with other events, the ot notation is use to express events of specific objects an the synchronization operators are sequence, simultaneity an non-eterminism. Pre an Post are the usual Petri net flow relation etermining what it is consume an what it is prouce in the object state places. CO-OPN provies tools for the management of graphical an textual representations. kin _ adrink adrink _ : rink init _ : rink rinks _ DrinksContainer ispensedrink _ : rink ispensedrink Figure 6 : The Drinks Container class graphical escription In figure 6 the DrinksContainer class provies methos to moify, in ifferent ways, the state representation of the rink container. For instance, the metho adrink is fireable if a init was performe assigning to the rink container the kin of rinks that can be kept in this container (place kin). A corresponing class PhysicalDrinksContainers (figure 7) is use to moel the physical components of the ispenser. In our example init 4
the main ifference of this class wrt. to the controller class is the introuction of a limit in the number of loaable rinks. This will constrain the behaviour of the whole moel to a finite number of states. We consier that it is a natural way to take into account the physical limitation without overconstraining the controller moel. acontainer _ : rink adrink _ : rink takedrink _ : rink (succ n) n 3 acontainer empty _ container slots 10, (succ n), n, adrink empty _ slots for _ (succ n), takedrink n, (n < 10) = true PhysicalDrinksContainers Figure 7 : The PhysicalDrinksContainer class graphical escription In figure 8, the reaer can see the textual escription of the centralunit Petri net. The axiom ax1 illustrates complex properties that can be abstractly moelle using our formalism. The variable c represents a reference to container objects an is use to select one of the create containers. In ax1 axiom the selecte container will be the one that has the require kin of rink given by the variable. The selection is mae by the metho that succees only when the kins of rink match. This example also illustrates the transactional semantics of CO-OPN (all-or nothing policy of synchronization) expresse in the (this.takemoney p)..(c.ispensedrink ) synchronization that can succee if an only if both methos sequentially succee. 3 Translation of CO-OPN to programming languages Class CentralUnit; Interface Use Drink, Money; Type centralunit; Gate takemoney _ : money; Methos istribute _ : rink; acontainer _ price _ : rink money; adrink _ : rink; Boy Use DrinksContainer; Place container _ price _ : c money; Axioms ax1:this = Self => istribute With (this.takemoney p)..(c.ispensedrink ):: container c price p -> container c price p; ax2:acontainer price p With c.init :: -> container c price p; ax3:adrink With c. adrink :: container c price p -> container c price p; Where this : centralunit; p : money; c : c; : rink; En CentralUnit; Figure 8 : The CentralUnit class textual escription The coe generation process takes a CO-OPN specification as a parameter an prouces a set of Java classes. The object structure of a CO-OPN specification is preserve by the generate coe. One of our primary goals was to fin a "natural" mapping between CO-OPN an Java. In such a mapping of stanar CO-OPN features, constructs like methos or gates are associate to stanar Java features, methos or events respectively. As a result, the interface part of a generate Java component is similar to the interface of the corresponing CO-OPN component, an it is also easy to unerstan/use by a human programmer or evelopment tool. Some powerful aspects of CO-OPN, such as atomic concurrent synchronizations or non-eterminism, o not have a irect equivalent in Java, consequently they are non-trivial to implement. These aspects are, as much as possible, hien in private parts of the generate coe. We will continue by presenting the list of main problems solve in the coe generator. Implementation of ADT using rewrite system [8] as explaine in [7]. The structure of the generate coe allows one to replace parts of it by user coe. Implementation of Classes an Contexts following the JavaBean structure [10] that provie a unifie view of methos an gates. Nevertheless, aitional features such as transactional support an non-eterminism are manage by generate coe. Now we will give more insight in the complex process of generating Java classes an list the main concepts that are use: Transaction Support. The operational interpretation of CO-OPN synchronizations is base on the neste transactions principle [2]. Specific algorithms an ata structures implement commit an abort operations. Non-eterminism. Methos of CO-OPN classes may be non-eterministic in ata an control imensions. Data non-eterminism occurs when a preconition takes values from places. It is possible that many ifferent values match the preconition requirements. The choice from matching values is non-eterministic. Control non-eterminism occurs when more that one metho s axiom can apply in the given system state. Non-eterminism is implemente in prologlike fashion, neste transactions are use to uno changes of system state an coe rewriting to implement the prolog "reo" primitive. 5
Resource Sharing. In CO-OPN, concurrent synchronizations can share the same resources. A specific ata structure that collaborates with the transaction mechanism has been evise to implement the rules of resource sharing. Concurrent Synchronizations. CO-OPN efines three kins of concurrent synchronizations: sequence, simultaneity an non-eterminism. The structure of the neste transaction tree follows the structure of the synchronisation tree. 4 How to use the moels As explaine before the purpose of moelling is not only to prouce the controller, but also to be able to stuy the behaviour of the machine that will be prouce. Now we will present two possibilities of using the coe generator on the CO-OPN moels. First one is the valiation of controller in real environment. The goal of valiation is to insure that the controller can work with real systems. Clearly, the best way to test the software is by installing the controller program on the real rink istributor. Our less expensive approach is to use LEGO RCX [14] or similar system. In this approach a simplifie harware moel of DDM is built with LEGO. The generate program is installe on a PC connecte with the LEGO RCX computer via an infrare port. To avoi limitations of RCX system, a part of the interface of DDM runs on the PC. The resulting system can be use for emonstration purposes an to show its feasibility. The secon possibility is the use of coe generation techniques to observe an verify properties of the whole DDM system without builing it. As explaine before, the DDM moel contains a part that escribes the constraints an the limitations introuce by the physical components. Instea of generating only a controller, we generate the coe for the whole moel for simulation purposes. This coe can be execute to verify useful properties of the moel. A tool (figure 9) exists that enables the user to execute CO-OPN synchronizations on generate coe an watch for execution results. Figure 9 : Interpretor tool An example of a useful property for DDM coul be: If there is enough money in MB an enough rinks then the selectdrink request must always succee. This property is then expresse as CO-OPN synchronisation an submitte to generate coe. The result can then be observe an eventual wrong behaviour etecte. As the state space of the DDM moel is finite (because of limitations introuce by physical moel) a quasi-exhaustive test of such a property is also possible. 5 Future Work an Conclusions In this paper, we presente an attractive methoology for moelling embee systems. Embee software is moelle together with controlle equipment. In our opinion this is a technique that can be use for co-esign. We also propose a technique for automatically transforming a formal specification of a system into executable coe. This technique was valiate on a number of examples, incluing the rinks ispenser case stuy. We plan to continue the evelopment of generation techniques to better suit the purposes of embee software. Generate coe is also use for valiation an verification of the moel. We inten to evelop this research irection in orer to integrate test techniques. References [1] Diier Buchs an Nicolas Guelfi, ``A Formal Specification Framework for Object-Oriente Distribute Systems,'' IEEE TSE, vol. 26, no. 7, July 2000, pp. 635-652. [2] G. Weikum, "Principles an Realization Strategies of Multilevel Transaction Management", ACM Transactions of Database Systems, Vol 16, No 1, pp 132-180, 1991. [3] Olivier Biberstein, Diier Buchs, an Nicolas Guelfi; Object-oriente nets with algebraic specifications: The CO- OPN/2 formalism. In G. Agha, F. De Cinio an G. Rozenberg, eitors, Avances in Petri Nets on Object-Orientation, volume to appear in Lecture Notes in Computer Science. Springer-Verlag, LNCS 2001, pp. 70-127. [4] Diier Buchs an Mathieu Buffo. Rapi prototyping of formally moelle istribute systems. In Frances M. Titsworth, eitor, Proc. of the Tenth International Workshop on Rapi System Prototyping RSP 99. IEEE, june 1999. [5] Mathieu Buffo. Experiences in coorination programming. In Proceeings of the workshops of DEXA 98 (International Conference on Database an Expert Systems Applications). IEEE Computer Society, aug 1998. [6] Christine Choppy an Stéphane Kaplan. Mixing abstract an concrete moules: Specification, evelopment an prototyping. In 12th International Conference on Software Engineering, pages 173 184, Nice, March 1990. [7] Diier Buchs an Jarle Hulaas. Evolutive prototyping of heterogeneous istribute systems using hierarchical algebraic Petri nets. In Proceeings of the Int. Conf. on Systems, Man an Cybernetics, Beijing, China, October 1996. IEEE. [8] Ph. Schnoebelen. Refine compilation of pattern-matching for functionnal languages. Science of Computer Programming, pages 11:133-159, 1988. [9] Olivier Biberstein an Diier Buchs. Structure algebraic 6
nets with object-orientation. In Proc.of the first int. workshop on Object-Oriente Programming an Moels of Concurrency within the 16th Int. Conf. on Application an Theory of Petri Nets, Torino, Italy, June 26-30 1995. [10] Sun Microsystems: JavaBeans specification Version 1.01 (July, 1997). [11] Mathieu Buffo an Diier Buchs. A coorination moel for istribute object systems. In Proc. of the Secon International Conference on Coorination Moels an Languages COORDINATION 97, volume 1282 of Lecture Notes in Computer Science, pages 410 413. Springer Verlag, 1997. [12] Nicholas Carriero an Davi Gelernter. How to Write Parallel Programs. MIT Press, Cambrige an Lonon, 1990. [13] Jeff Kramer, Jeff Magee, Morris Sloman, an Naranker Dulay. Configuring object-base istribute programs in rex. IEEE Software Engineering Journal, 7(2):139 149, 1992. [14] Lego Web site, http:\\minstorms.lego.com 7