Centrum Wiskunde & InformaticaFormal aspects of component softwareM. Sun, B. SchatzSEN-E0902Centrum Wiskunde & Informatica (CWI) is the national research institute for Mathematics and Computer Science. It is sponsored by the Netherlands Organisation for Scientific Research (NWO).CWI is a founding member of ERCIM, the European Research Consortium for Informatics and Mathematics.CWI's research has a theme-oriented structure and is grouped into four clusters. Listed below are the names of the clusters and in parentheses their acronyms.Probability, Networks and Algorithms (PNA)Software Engineering (SEN)Modelling, Analysis and Simulation (MAS)Information Systems (INS)Copyright © 2009, Centrum Wiskunde & InformaticaP.O. Box 94079, 1090 GB Amsterdam (NL)Science Park 123, 1098 XG Amsterdam (NL)Telephone +31 20 592 9333Telefax +31 20 592 4199ISSN 1386-369X Sun Meng & Bernhard Sch tz (Eds.)äFormal Aspects ofComponent Software6th International Workshop, FACS 2009Eindhoven, the Netherlands2-3 November, 2009Pre-ProceedingsFormal aspects of component software ABSTRACT This is the pre-proceedings of 6th International Workshop on Formal Aspects of Component Software (FACS'09). 2000 Mathematics Subject Classification: 00 1998 ACM Computing Classification System: A.0 Keywords and Phrases: Proceedings PrefaceThis volume contains the proceedings of the 6th International Workshop on Formal Aspects ofComponent Software (FACS09). FACS’09 was held in Eindhoven, the Netherlands on November2-3, 2009 as a satellite event of the Formal Methods Week.The objective of FACS’09 is to bring together researchers in the areas of component software andformal methods to promote a deep understanding of this paradigm and its applications. Component-based software has emerged as a promising paradigm to deal with the ever increasing need for mas-tering systems’ complexity, for enabling evolution and reuse, and for bringing sound production andengineering standards into software engineering. However, many issues in component-based soft-ware development remain open and pose challenging research questions. Formal methods consistof mathematically-based techniques for the specification, development and verification of softwareand hardware systems. They have shown their great utility for setting up the formal foundationsof component software and working out challenging issues such as mathematical models for compo-nents, their composition and adaptation, or rigorous approaches to verification, deployment, testingand certification.FACS’09 is the 6th event in a series of workshops, founded by the International Institute forSoftware Technology of the United Nations University (UNU-IIST). The first FACS workshop wasco-located with FM’03 (Pisa, Italy, September 2003). The following FACS workshops were organ-ised as standalone events, respectively at UNU-IIST in Macau (October 2005), at Charles Universityin Prague (September 2006), at INRIA in Sophia-Antipolis (September 2007), and at University ofMa´laga in Spain (September 2008).FACS’09 was scheduled as part of the first Formal Methods Week (FMweek), to be hosted byTechnische Universiteit Eindhoven in Eindhoven, the Netherlands, in November 2009. The sci-entific program includes 13 regular papers and 2 invited talks, delivered by Gert Do¨hmen fromAIRBUS Deutschland GmbH, Hamburg, Germany and by Jan Rutten from CWI, Amsterdam, theNetherlands. Each paper was reviewed by at least three Program Committee members. The entirereviewing process was supported by the EasyChair Conference System.We would like to express our gratitude to all the researchers who submitted their work to theworkshop and to all colleagues who served on the Program Committee and helped us in preparinga high-quality workshop program. We are also most grateful to the invited speakers for the willing-ness to present their research and to share their own perspectives on formal methods for componentsoftware at the workshop.Without the support of TU Eindhoven, CWI and UNU-IIST this workshop could not havehappened. We are most grateful to all organizing institutions and staff for supporting FACS andproviding an organizational framework for the workshop. In particular, we are deeply indebted toErik de Vink and Tijn Borghuis at TU Eindhoven, Jos van der Werf and Jan Schipper at CWI, andKitty Chan Iok Sam at UNU-IIST Macau, for their help in managing the practical aspects of thisevent.Sun Meng and Bernhard Scha¨tzFACS’09 PC ChairsOrganizationSteering CommitteeZhiming Liu (IIST UNU, Macau, China, coordinator)Farhad Arbab (CWI, The Netherlands)Luis Barbosa (Universidade do Minho, Portugal)Carlos Canal (University of Ma´laga, Spain)Markus Lumpe (Swinburne University of Technology, Australia)Eric Madelaine (INRIA, Sophia-Antipolis, France)Vladimir Mencl (Charles University, Prague, Czech Republic, and University ofCanterbury, New Zealand)Corina Pasareanu (NASA Ames Research Center, USA)Sun Meng (CWI, the Netherlands)Bernhard Scha¨tz (Technical University of Munich, Germany)Programme ChairsSun Meng (CWI, the Netherlands)Bernhard Scha¨tz (Technical University of Munich, Germany)Programme CommitteeFarhad Arbab (CWI, The Netherlands)Luis Barbosa (Universidade do Minho, Portugal)Frank S. de Boer (CWI, The Netherlands)Christiano Braga (Universidad Complutense de Madrid, Spain)Carlos Canal (Universidad de Ma´laga, Spain)Paolo Ciancarini (Universita di Bologna, Italy)Rolf Hennicker (Ludwig-Maximilians-Universitaet Muenchen, Germany)Atsushi Igarashi (Kyoto University, Japan)Einar Broch Johnsen (Universitetet i Oslo, Norway)Ying Liu (IBM China Research, China)Markus Lumpe (Swinburne University of Technology, Australia)Eric Madelaine (INRIA, Centre Sophia Antipolis, France)Corina Pasareanu (NASA Ames, USA)Frantisek Plasil (Charles University, Czech Republic)Anders Ravn (Aalborg University, Denmark)Ralf Reussner (Universitaet Karlsruhe, Germany)Heinrich Schmidt (RMIT University, Australia)Marjan Sirjani (University of Tehran, Iran, and Reykjavik University, Iceland)Volker Stolz (UNU-IIST, MACAU)Carolyn Talcott (SRI International, USA)Dang Van Hung (Vietnam National University, Vietnam)Naijun Zhan (IOS, China)External ReviewersAdam, LudwigBauer, SebastianBurger, ErikCruz, DanielaGrabe, ImmoGroenda, HenningHammer, MoritzHansen, Rene RydhofHenrio, LudovicJaghouri, MahdiKhakpour, NargesKnudsen, JohnKupberberg, MichaelLuo, LingyunMartins, MarioMorisset, CharlesOndrej, SeryPoch, TomasPrisacariu, CristianSalau¨n, GwenSteffen, MartinTruong, HoangWang, ShulingKofron, JanTable of ContentsInvited TalksComponent-based design for avionics systems 1Gert Doehmen (AIRBUS Deutschland GmbH, Germany)Coalgebraic Methods for Component Connectors 3Jan Rutten (CWI, the Netherlands)Component InteractionAction Prefixes: Reified Synchronization Paths in Minimal Component Interaction Automata 5Markus Lumpe (Swinburne University of Technology, Australia)Behaviour Protocols for Interacting Stateful Components with Ports 21Sebastian S. Bauer (Ludwig-Maximilians-Universita¨t Mu¨nchen, Germany)Rolf Hennicker (Ludwig-Maximilians-Universita¨t Mu¨nchen, Germany)Stephan Janisch (Ludwig-Maximilians-Universita¨t Mu¨nchen, Germany)VerificationA Boolean algebra of contracts for assume-guarantee reasoning 37Yann Glouche (INRIA, France)Paul Le Guernic (INRIA, France)Jean-Pierre Talpin (INRIA, France)Thierry Gautier (INRIA, France)Automated formalisation for verification of diagrammatic models 53James Williams (University of York, UK)Fiona Polack (University of York, UK)Model Checking of Component Protocol Conformance – Optimizations by Reducing False Negatives 69Andreas Both (University of Halle, Germany)Wolf Zimmermann (University of Halle, Germany)Components and ServicesReachability in Tree-Like Component Systems is PSPACE-Complete 85Nils Semmelrock (University Mannheim, Germany)Mila Majster-Cederbaum (University Mannheim, Germany)Composition of Services with Constraints 99Philippe Balbiani (IRIT-CNRS, France)Fahima Cheikh (IRIT-CNRS, France)Pierre-Cyrille He´am (LSV-CNRS-INRIA, France)Olga Kouchnarenko (INRIA-CASSIS-LIFC, France)Using Assertions to Enhance the Correctness of Kmelia Components and their Assemblies 115Pascal Andre (University of Nantes, France)Gilles Ardourel (University of Nantes, France)Christian Attiogbe (University of Nantes, France)Arnaud Lanoix (University of Nantes, France)Reconfiguration and AdaptationA Formal Framework for Structural Reconfiguration of Components under Behavioural Adaptation 131Antonio Cansado (University of Ma´laga, Spain)Carlos Canal (University of Ma´laga, Spain)Javier Cubo (University of Ma´laga, Spain)Gwen Salau¨n (University of Ma´laga, Spain)PobSAM: Policy-based Managing of Actors in Self-Adaptive Systems 147Narges Khakpour (Tarbiat Modares University, Iran)Saeed Jalili (Tarbiat Modares University, Iran)Carolyn Talcott (SRI International, USA)Marjan Sirjani (Reykjavk University, Iceland, University of Tehran and IPM, Iran)MohammadReza Mousavi (Eindhoven University of Technology, The Netherlands)Composition and DeploymentA systematic approach to construct compositional behaviour models for network-structured safety-criticalsystems 163Johannes Kloos (Fraunhofer Institute for Experimental Software Engineering, Germany)Robert Eschbach (Fraunhofer Institute for Experimental Software Engineering, Germany)A lightweight approach to customizable composition operators for Java-like classes 179Giovanni Lagorio (Universita` di Genova, Italy)Marco Servetto (Universita` di Genova, Italy)Elena Zucca (Universita` di Genova, Italy)Integrating extra-functional properties in component deployment dependencies 195Meriem Belguidoum (TELECOM Bretagne, France, Universite´ Mentourie, Algeria)Fabien Dagnat (TELECOM Bretagne, France)FACS 2009Component-based design for avionics systemsGert Do¨hmenAIRBUS Operations GmbHHAMBURG, GermanyEmail: gert.doehmen@airbus.comAbstractCurrent trend in aeronautics goes from system-specific avionics to a network of standardized processing-and I/O-modules, so-called Integrated Modular Avionics (IMA) platform, which can host different systems.It necessitates advanced processes and methods to provide a cost-efficient development of software-intensivesystems. The talk will discuss current and future IMA and how a component-based approach can pave theway from functional and extra-functional requirements of a system to its implementation to be hosted byIMA.This paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs12FACS 2009Coalgebraic Methods for ComponentConnectorsJan RuttenCWIAmsterdam, the NetherlandsEmail: Jan.Rutten@cwi.nlAbstractWe present a small toolset of coalgebraic structures and methods (mainly streams, Mealy automata, andcoinduction) and illustrate their use in the modelling of component connectors.This paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs34FACS 2009Action Prefixes: Reified Synchronization Paths inMinimal Component Interaction AutomataMarkus Lumpe1Faculty of Information & Communication Technologies, Swinburne University of TechnologyP.O. Box 218, Hawthorn, VIC 3122, AUSTRALIAAbstractComponent Interaction Automata provide a fitting model to capture and analyze the temporal facets of hierarchical-structuredcomponent-oriented software systems. However, the rules governing composition, as is typical for all automata-based ap-proaches, suffer from combinatorial state explosion, an effect that can have significant ramifications on the successful appli-cation of the Component Interaction Automata formalism to real-world scenarios. We must, therefore, find some appropriatemeans to counteract state explosion – one of which is partition refinement through weak bisimulation. But, while this tech-nique can yield the desired state space reduction, it does not consider synchronization cliques, i.e., groups of states thatare interconnected solely by internal synchronization transitions. Synchronization cliques give rise to action prefixes thatcapture pre-conditions for a component’s ability to interact with the environment. Current practice does not pay attentionto these cliques, but ignoring them can result in a loss of valuable information. For this reason we show, in this paper, howsynchronization cliques emerge and how we can capture their behavior in order to make state space reduction aware of thepresence of synchronization cliques.Keywords: Component Interaction Automata, Partition Refinement, Emerging Properties1 IntroductionComponent-based software engineering has become the prevalent trend in present-day soft-ware and system engineering [6]. In this approach the focus is on well-defined interfaces[3,7,11,26] that provide appropriate means for decomposing an engineered system into log-ical and interacting entities, the components, and constructing their respective aggregations,the composites, to yield the desired system functionality at matching levels of abstractionand granularity. Moreover, according to this technique, new components are created bycombining pre-existing ones with new software, the glue [24], using only the informationpublished in the interface specifications of the components being composed.Component interfaces can convey a variety of information [1] that collectively form acontractual specification. Ideally, all assumptions about a component’s environment shouldbe stated explicitly and formally as part of the interface specification [25]. However, eventhough interfaces must be organized in such a way that contractual specifications guaranteesafe deployment in new contexts, the information contained in these interfaces must not1 Email: mlumpe@swin.edu.auThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs5M. Lumpeprovide any instruments to circumvent component encapsulation. On the other hand, thepurpose of contractual specifications is to prevent errors, at both design time and run-time.Therefore, component contracts should impose a well-balanced set of constraints to enforcecontractual obligations, but must be defined in a manner so that the reasons why a particularcontract verification has failed are self-evident [4].In this paper, we are concerned with the specification of behavioral and synchroniza-tion contracts [1] between interacting components. In particular, we study the effectivenessof Component Interaction Automata [2,5], an automata-based modeling language for thespecification of hierarchical-structured component-based systems. Components synchro-nize through answering mutual service requests. However, some service requests shouldonly occur in certain situations [23] depending on the component’s readiness to satisfy agiven request (pre-condition) and its cumulative interaction profile (post-condition). Thedescription of these temporal aspects corresponds best to finite automata in which accept-able service requests are modeled as state transitions between activating sets (i.e., states ofthe modeling automaton) [23].Unfortunately, automata-based formalisms suffer from combinatorial state explosion, amajor obstacle to the successful application of these approaches for the specification of theinteractive behavior in component-based systems. More precisely, to capture the completebehavior of an automata-based system, we need to construct the product automaton of thesystem’s individual components [10]. This operation exhibits exponential space and timecomplexity and the resource consumption quickly reaches a level at which an effectivespecification of a composite system is not feasible anymore [13]. We need, therefore,workable abstraction methods that allow for a reduction of the composite state space atacceptable costs.For this reason, we have developed a bisimulation-based partition refinement algorithmfor Component Interaction Automata [13]. Partition refinement [9,20] is a state space re-duction technique that, driven by a corresponding equivalence relation, merges separateequivalent states into one unifying representative. On termination, partition refinementyields a new automaton that reproduces the behavior of the original one up to the definedequivalence, but isminimal (i.e., a fixed-point) with respect to the number of required states.Partition refinement can effectively reduce the size and complexity of composite com-ponent interaction automata [13]. There are, however, instances in which partition refine-ment produces unexpected outcomes. In particular, we observe a frequent appearance ofnew, non-deterministic transitions in minimal composite component interaction automata,even when there were none before. These non-determistic transitions can cause harm, astheir elimination may require exponentially more states [10], which is clearly not a desir-able scenario.Upon closer inspection we find that these new non-deterministic transitions are directlylinked to states with internal component synchronizations that become unified as resultof partition refinement. Following network theory [17], these states form synchronizationcliques, groups of states, that embed in their structure regular sublanguages over an alpha-bet of internal component synchronizations. The sentences of these regular sublanguagesserve as prefixes (or pre-conditions) in the interface of a given composite component in-teraction automaton. Before refinement, these prefixes are woven into the fabric of thecomposite automaton. Partition refinement, however, is blind for this additional informa-tion, as, independent of its presence, observable equivalence is always preserved between6M. Lumpethe original and the reduced automaton.Synchronization cliques are intrinsic to automata-based approaches that enumerate in-ternal synchronization actions [6,2,5,14,27] rather than modeling them by τ – a perfect ac-tion [16]. As a consequence, an external observer can monitor not only the occurrences ofinternal synchronizations (through the passing of time), but also the order in which actionsactually trigger the internal synchronizations. We can capture the alternating sequencesof states and internal synchronization actions in synchronization paths [5,13]. However,weak bisimulation is an equivalence relation that abstracts from internal actions, resultingin a loss of information, including the ability to monitor the sequence of internal synchro-nizations. We show, in this paper, that we can recover this information by representing theexisting synchronization paths in a system as action prefixes in the corresponding reducedcomponent interaction automaton.The rest of this paper is organized as follows: in Section 2, we review the ComponentInteraction Automata formalism and demonstrate its expressive power on a tailored ver-sion of a simple e-commerce application. We proceed by developing the core ingredientsof observable equivalence and partition refinement for component interaction automata inSection 3 and construct, in Section 4, the machinery to distill action prefixes from syn-chronization cliques. We discuss possible implications of the existence of synchronizationcliques in Section 5 and conclude with a brief summary of our main observations and anoutlook to future work in Section 6.2 The Component Interaction Automata Modeling LanguageI/O Automata [14], Interface Automata [6], and Team Automata [27] have all emerged aslight-weight contenders for capturing concisely the temporal aspects of component-basedsoftware systems. These formalisms use an automata-based language to represent boththe assumptions about a system’s environment and the order in which interactions with theenvironment can occur. However, none of these models cater directly for multiple instan-tiations of the same component within a single system or allow for a more fine-grainedspecification of hierarchical relationships between organizational entities in a system.These restrictions have been relaxed in Component Interaction Automata [2,5]. In thisapproach we find two new concepts: a hierarchy of component names and structured la-bels. The former provides us with a means to record the architecture of a composite system,whereas the latter paves the way to specify the action, the originating component, and thetarget component in the transitions of component interaction automata, a feature that al-lows us to disambiguate multiple occurrences of the same component (or action) within asingle system. Specifically, the Component Interaction Automata formalism supports threeforms of structured labels: (−, a, n), receive a from the environment as input at compo-nent n, (n, a,−), send a from component n as output to the environment, and (n1, a, n2),components n1 and n2 synchronize internally through action a.TheComponent Interaction Automata formalism uses component identifiers to uniquelyidentify specific component instances in a given system. However, a given componentidentifier can occur at most once in a composite component interaction automaton. This re-quirement addresses a frequent difficulty in the specification of component-based systems– the difference between components and component instances [12]. The I/O Automataand Interface Automata formalisms, for example, do not distinguish between components7M. Lumpeand their instances. Every specification involves only instances. It is for this reason thatall actions of composed components have to be pairwise disjoined [6,14] (i.e., a singlecomponent can occur at most once in a composite system). In contrast, the Component In-teraction Automata formalism distinguishes between components and their instances. Eachcomponent is instantiated with a unique identifier that we use also to disambiguate the cor-responding component transitions. Consider, for example, a component C that defines aninput via action a and two instances of C, named A and B. Then the structured labels forthe input transitions ofA andB are (−, a, A) and (−, a, B), respectively. The unique com-ponent identifiers A and B are what allows for the safe coexistence of multiple instancesof the same component (or action) in a given system.We presuppose an infinite set A of component identifiers. A hierarchy of componentnames is defined as follows [5]:Definition 2.1 A hierarchy of component names H is defined recursively by• H = (a1, ..., an), where a1, ..., an ∈ A are pairwise disjoint component identifiers andS(H) = ∪ni=1{ai} denoting the set of component identifiers of H;• H = (H1, ...,Hm), whereH1, ...,Hm are hierarchies of component identifiers satisfying∀ 1 ≤ i, j ≤ m, i 6= j : S(Hi) ∩ S(Hj) = ∅ and S(H) = ∪mi=1S(Hi) denoting the setof component identifiers of H .Definition 2.2 A component interaction automaton C is a quintuple (Q,Act , δ, I,H)where:• Q is a finite set of states,• Act is a finite set of actions,• δ ⊆ Q×Σ×Q is a finite set of labeled transitions, where Σ ⊆ {(S(H)∪ {−}×Act ×S(H) ∪ {−})}\ {({−} ×Act × {−})} is the set of structured labels induced by C,• I ⊆ Q is a non empty set of initial states, and• H is a tuple denoting C’s hierarchical composition structure.Each component interaction automaton is further characterized by two sets of P ⊆ Act ,the provided actions, and R ⊆ Act , the required actions, which capture the automaton’senabled interface with an environment. We write CPR to denote an automaton C that isinput-enabled in P and output-enabled in R.In the original definition [2,5], the set of provided actions P and the set of requiredactions R originate from a secondary specification outside the Component Interaction Au-tomata formalism. Incorporating these architectural constraints into the specification ofcomponent interaction automata does not affect the underlying composition rules, but rathermake the relationship with the associated automata more explicit and ease the computationof composition [13]. We abbreviate, however, the annotation in a natural way if an automa-ton is enabled in all actions and omit the corresponding specification.As motivating example, consider a simple electronic commerce system with three par-ticipants [10]: a Customer, a Store, and a Bank. The behavior of the composite systemis as follows. The customer may initiate a transaction by passing a voucher to the store.The store will then redeem this voucher with the bank (i.e., the bank will eventually de-posit money into the store’s account) and, through a third party, ship the ordered goods. Inaddition, the customer may cancel the order before the store had a chance to redeem the8M. Lumpe(Customer)(Store)(Bank)((Customer), (Store), (Bank))paycanceltransfershipredeemcancelFig. 1. A simple e-commerce system.voucher, in which case the voucher will be returned to the customer immediately. We allowthe customer to cancel an order with either the store or the bank. The high-level interactionprotocol for this system is shown in Figure 1.We can model Customer, Store, and Bank as component interaction automata as fol-lows. We write (Customer), (Store), and (Bank) to denote the architecture of the com-ponent interaction automata Customer, Store, and Bank. More precisely, the three automataare primitive (or plain) components with an opaque structure (i.e., no explicit hierarchicalrelationships):Customer = ({c0, c1}, {pay, cancel},{(c0, (Customer, pay,−), c1), (c1, (Customer, cancel ,−), c0)},{c0}, (Customer))Store = ({s0, s1, s2, s3, s4, s5}, {pay, redeem, transfer , ship},{(s0, (−, pay, Store), s1), (s1, (Store, redeem,−), s2), (s1, (−, cancel , Store), s0),(s2, (−, transfer , Store), s3), (s2, (Store, ship,−), s4), (s3, (Store, ship,−), s5),(s4, (−, transfer , Store), s5)}, {s0}, (Store))Bank = ({b0, b1, b2, b3}, {cancel , redeem, transfer},{(b0, (−, cancel , Bank), b1), (b0, (−, redeem, Bank), b2),(b1, (Bank, cancel ,−), b0), (b2, (Bank, transfer ,−), b3)},{b0}, (Bank))The Customer automaton has two states and two output transitions (i.e., customer re-quests). The Store automaton, on the other hand, defines six states and seven transitions andguarantees that orders will only be shipped, if the payment voucher has been redeemed suc-cessfully. The Store receives a voucher (i.e., action pay), money (i.e., action transfer ), ora cancelation as input and issues as output the shipment of goods and the request to redeemthe voucher. Finally, the Bank automaton, defining four states and four transitions, medi-ates Customer and Store. If the Store has not yet cashed the voucher, then the Customercan still cancel the order and receive a refund. The Bank will forward a cancelation noticeto the Store. If the Store has already submitted the voucher, then the Bank will eventuallytransfer funds to the Store. At this point, the Customer cannot cancel the order anymore.The composition of component interaction automata is defined as the cross-productover their state spaces. Furthermore, the sets P and R determine, which input and outputtransitions occur in the composite system (i.e., interface with the environment). By con-vention, if any state is rendered inaccessible in the composite automaton, then we remove9M. Lumpe(Customer,pay,Store)(Customer,cancel,Store)(Store,redeem,Bank) (Bank,transfer,Store)(Bank,cancel,Store)(Bank,transfer,Store)(Customer,cancel,Bank) (Store,ship,−) (Store,ship,−)((Customer), (Store), (Bank))s4c1b2s0c0b0 s2c1b2s5c1b3s3c1b3s1c0b1s1c1b0shipFig. 2. The composite e-commerce component interaction automaton.it immediately from the state space in order to obtain the most concise result. The behaviorof the composite automaton is completely captured by its reachable states.Definition 2.3 Let SPR = {(Qi,Act i, δi, Ii,Hi)}i∈I be a system of pairwise disjoint com-ponent interaction automata, where I is a finite indexing set and P,R are the providedand required actions. Then CPR = (∏i∈I Qi,∪i∈IAct i, δSPR ,∏i∈I Ii, (Hi)i∈I) is a com-posite component interaction automaton where qj denotes a function∏i∈I Qi → Qj , theprojection from product state q to jth component state q andδSPR= δOldSync ∪ δNewSync ∪ δInput ∪ δOutputwithδOldSync = {(q, (n1, a, n2), q′) | ∃i ∈ I : (qi, (n1, a, n2), q′i) ∈ δi ∧∀j ∈ I, j 6= i : qj = q′j},δNewSync = {(q, (n1, a, n2), q′) | ∃i1, i2 ∈ I, i1 6= i2 : (qi1 , (n1, a,−), q′i1 ) ∈ δi1 ∧(qi2 , (−, a, n2), q′i2 ) ∈ δi2 ∧ ∀j ∈ I, i1 6= j 6= i2 : qj = q′j},δInput = {(q, (−, a, n), q′) | a ∈ R ∧ ∃i ∈ I : (qi, (−, a, n), q′i) ∈ δi ∧∀j ∈ I, j 6= i : qj = q′j},δOutput = {(q, (n, a,−), q′) | a ∈ P ∧ ∃i ∈ I : (qi, (n, a,−), q′i) ∈ δi ∧∀j ∈ I, j 6= i : qj = q′j}.The composition rule builds the product automaton for a given system SPR . It does soby simultaneously recombining the behavior of all individual component interaction au-tomata {(Qi,Act i, δi, Ii,Hi)}i∈I . The transitions of the composite automaton result fromfour sets: the transposed preexisting internal synchronizations δOldSync of the individualcomponent interaction automata, the newly formed internal synchronizations δNewSync dueto interactions between the individual component interaction automata, and the sets δInputand δOutput , the transposed remaining interactions of the product automaton with the envi-ronment.Applied to our e-commerce system, we can denote the composition of the three com-ponents Customer, Store, and Bank using the following expression:S{ship}∅ = {Customer, Store,Bank},which yields a composite automaton with 7 reachable states (out of 48 product states).Moreover, due to the architectural constraintsP = {ship} andR = ∅ the composite systemcan only interact with its environment by emitting a ship action. A graphical representationof the composite system is shown in Figure 2.10M. Lumpe3 Observable Equivalence and Partition RefinementThe problem of combinatorial state explosion does not only occur when constructing newcomposite components or systems, but also when we wish to study their inherent prop-erties [13]. A measure to alleviate state explosion is partition refinement [13,9,20,18,8],which allows, by means of some equivalence relation, for the identification of states thatexhibit the same interactive behavior with respect to an external observer. Partition refine-ment merges equivalent states into one and removes the remaining superfluous states andtheir transitions from the system. We use bisimulation [19], in particular a notion of weakbisimulation [13,16], as the desired observable equivalence relation for the reduction ofcomponent interaction automata. From an external observer’s point of view, weak bisim-ulation yields a co-inductive testing strategy in which two component interface automatacannot be distinguished, if they only differ in their internal synchronizations.However, the Component Interaction Automata formalism requires an additional crite-rion to be met: two component interaction automata A and B are considered equivalent,if and only if they are bisimular and adhere to the same underlying composition structure[13]. In other words, any technique to reduce the complexity of a given component inter-action automaton has also to retain its underlying hierarchical composition structure. Thismeans, two states q, p with transitions (q, (−, a, A), r) and (p, (−, a, B), r) must not beequated, as the target components in the transition labels differ.An important element in the definition of an observable equivalence relation over com-ponent interaction automata is the notion of synchronization path.Definition 3.1 If (n1, a1, n′1) · · · (nk, ak, n′k) ∈ Σ are internal synchronizations of a com-ponent interaction automaton C, then we write q ∗=⇒ p to denote the reflexive transitiveclosure ofq(n1,a1,n′1)−−−−−−→ r1(n2,a2,n′2)−−−−−−→ · · ·(nk−1,ak−1,n′k−1)−−−−−−−−−−−→ rk−1(nk,ak,n′k)−−−−−−→ p,called synchronization path between q and p.Synchronization paths give rise to weak transitions.Definition 3.2 If l ∈ Σ is a structured label, then q l=⇒ p is a weak transition from q to pover label l, if there exists r, r′ such thatq∗=⇒ r l−→ r′ ∗=⇒ p.Using the concept of weak transitions, we can define now a weak bisimulation overcomponent interaction automata.Definition 3.3 GivenA = (QA,ActA, δA, IA,H) andB = (QB,ActB, δB,H), two com-ponent interaction automata with an identical composition hierarchy H , a binary relationR ⊆ Q×Q with Q = QA ∪QB is a weak bisimulation, if it is symmetric and (q, p) ∈ Rimplies, for all l ∈ Σ, Σ = ΣA ∪ ΣB being the set of structured labels induced by A andB,• whenever q l−→ q′, then ∃p′ such that p l=⇒ p′ and (q′, p′) ∈ R.Two component interaction automataA andB are weakly bisimilar, writtenA ≈ B, if theyare related by some weak bisimulation.11M. LumpeUsing the preceding definition, we can find a new automaton, R{ship}∅ , capable of re-producing the interactive behavior of our e-commerce systems up to weak bisimulation.R{ship}∅ (cf. Figure 3) satisfies two requirements: (i) it interacts with the environmentthrough the structured label (Store, ship,−), and (ii) it adheres to the hierarchical compo-sition structure ((Customer), (Store), (Bank)).(Store,ship,−)((Customer), (Store), (Bank))r0 r1 shipFig. 3. The weakly-bisimular e-commerce component interaction automatonR{ship}∅ .To show thatR{ship}∅ and S{ship}∅ = {Customer, Store,Bank} are indeed observableequivalent with respect to an external observer, we have to find a weak bisimulationR suchthatR{ship}∅ ≈ S{ship}∅ . Such a relation exists and is defined asR = r ∪ r−1 withr= {(s0c0b0, r0), (s1c1b0, r0), (s1c0b1, r0), (s2c1b2, r0), (s3c1b3, r0),(s4c1b2, r1), (s5c1b3, r1)}.There are only two states in S{ship}∅ , s2c1b2 and s3c1b3, that require the automatonR{ship}∅to move. Consider, for example, state s2c1b2 of S{ship}∅ . Since (s2c1b2, r0) ∈ R andS{ship}∅ can perform (s2c1b2, (Store, ship,−), s4c1b2), we select (r0, (Store, ship,−), r1)as a matching transition of R{ship}∅ that yields the pair (s4c1b2, r1) ∈ R, as required. Forall states in S{ship}∅ other than s2c1b2 and s3c1b3, R{ship}∅ pauses, since all internal syn-chronization have been factored out inR{ship}∅ .The global tactic for the computation of bisimularity is partition refinement, whichfactorizes a given state space into equivalence classes [9,20,18,8]. The result of partitionrefinement is a surjective function that maps the elements of the original state space to itscorresponding representatives of the computed equivalence classes. Partition refinementalways yields a minimal automaton.In the heart of partition refinement is a splitter function that determines the granularityof the computed equivalence classes. A splitter for component interaction automata is aboolean predicate γ : Q × Σ × S 7→ {true, false}, where S ⊆ 2Q is a set of candidateequivalence classes for C = (Q,Act , δ, I,H), the component interaction automaton inquestion.Definition 3.4 Let q ∈ Q be a state, P ′ ∈ S be candidate equivalence class, and l ∈ Σ bea structured label for a component interaction automaton C = (Q,Act , δ, I,H). Thenγ(q, l, P ′) := true if there is p ′ ∈ P ′ such that ql=⇒ p ′,false otherwiseWe obtain with this definition a means of expressing the computation of a weakly-bisimular component interaction automaton as the possibility of a set of its states, P , toevolve into another set of states, P ′, with the same observable behavior, where P ′ is theequivalence class of P .12M. LumpeDefinition 3.5 Let γ be a splitter function generating weakly-bisimular equivalence classesfor a component interaction automaton C = (Q,Act , δ, I,H). Thenrefine(X, l, P ′) :=∪P∈X(∪v∈{true,false}{q | ∀q ∈ P. γ(q, l, P ′) = v})− {∅}The actual refinement process is defined by a procedure, refine : X ×Σ×S ×X , thattakes a set of partitions X ∈ X , a structured label l ∈ Σ, and a candicate equivalence classP ′ ∈ S to yield, possibly new, candidate equivalence classes. Partition refinement, startingwithX = {Q} as initial partition set, repeatedly applies refine toX and its derivatives forall l ∈ Σ until a fixed-point is reached [9].When applied to our composite e-commerce system S{ship}∅ , partition refinement com-putes the following equivalence classes:{r0 = {s0c0b0, s1c1b0, s1c0b1, s2c1b2, s3c1b3}, r1 = {s4c1b2, s5c1b3}},which correspond exactly to the weak bisimulation R, shown earlier. More precisely, wecan use these equivalence classes to construct the automatonR{ship}∅ .4 Action PrefixesPartition refinement, up to weak bisimulation, can eliminate most if not all, as in caseof R{ship}∅ , internal synchronizations from a given component interaction automaton. Itprovides, therefore, a suitable abstraction method that lets system designers focus on theessence of the behavioral protocol defined by a given component interaction automaton.As shown in Section 3, when using the perspective of an external observer, only the out-put (Store, ship,−) remains in the interface of R{ship}∅ , a significant improvement withrespect to the original complexity of S{ship}∅ .(−,d,A2)(A1,c,−)(A1,a,A2)(−,d,A2)(A2,b,A1)(A1,c,−)((A1), (A2))q1q0q0q1q0q0q1q1cd(a) A{c}{d}((A1), (A2))(−,d,A2) (A1,c,−)(A1,c,−) (−,d,A2)r1 r2r0 cd(b) A-R{c}{d}Fig. 4. The weakly-bisimular component interaction automata A{c}{d} and A-R{c}{d}.Unfortunately, there are also situations in which partition refinement can eliminate in-formation, which, in itself, can be viewed vital for the understanding of the interactivebehavior of a component interaction automaton. Consider, for example, the two automataA{c}{d} and A-R{c}{d}, shown in Figure 4. Both are weakly-bisimular, A{c}{d}, however, containsa subgraph that produces a condition similar to the small-world effect [17]. In particu-lar, the states q0q0 and q1q1 in automaton A{c}{d} form a synchronization clique generat-ing two distinct regular sublanguages, Lq0q0 = {(ab)n|n ≥ 0} ∪ {b(ab)m|m ≥ 0} andLq1q1 = {a(ba)n|n ≥ 0}∪ {(ba)m|m ≥ 0}, of synchronization paths, which can originatefrom any clique state and terminate in the designated state q0q0 and q1q1, respectively.13M. LumpeThe prefix strings emerging from these sublanguages define pre-conditions that determine,when the transitions (r0, (−, d, A2), r1) and (r0, (A1, c,−), r2) can actually occur in thereduced automaton A-R{c}{d}.Definition 4.1 Let C = (Q,Act , δ, I,H) be a component interaction automaton and X ∈X be a set of equivalence classes up to weak bisimulation for C. Then a synchronizationclique is a non-empty directed graph (V,E), where V ⊆ Q is a set of clique states andE ⊆ δ is a set of internal synchronizations (q, (n, a, n′), p) with q, p ∈ V and q 6= p, ifthere exists P ∈ X such that q, p ∈ P .A synchronization clique appears, when partition refinement creates new reflexive in-ternal synchronizations due to mapping the endpoints of these transitions onto the sameequivalence class. By default, we can ignore preexisting reflexive internal synchroniza-tions, as they can occur, interleaving, in any order. However, the newly formed reflexiveinternal synchronizations are of a different kind, as their non-reflexive originals encode aspecific partial order over internal synchronizations. This property is lost in the refinementprocess. We can, however, recover it through the notion of action prefixes. For example, inA-R{c}{d} the transition (r0, (−, d, A2), r1)may occur only after a, possibly empty, sequenceof internal synchronizations over actions b and a, captured by the prefix [b](ab)∗ that rei-fies the required synchronization path to arrive in state q0q0 from synchronization clique{q0q0, q1q1}. In other words, the internal synchronizations have disappeared in A-R{c}{d},but we can use the prefix [b](ab)∗ to reenforce the existing pre-condition for the occurrenceof transition (r0, (−, d, A2), r1) in A-R{c}{d}. That is, (r0, (−, d, A2), r1) can occur withoutany proceeding internal synchronizations, only after a single b, or only after a sequence ofpaired a’s and b’s.The presence of synchronization cliques can cause even more worries, as illustrated inFigure 5. The automaton B{c}∅ is defined as the composition of the following two automataB1 and B2 2 :B1 = ({q0, q1}, {a, b, c},{(q0, (B1, a,−), q1), (q0, (B1, c,−), q1), (q1, (−, b, B1), q0)},{q0}, (B1))B2 = ({q0, q1}, {a, b, c},{(q0, (−, a, B2), q1), (q0, (B2, c,−), q1), (q1, (B2, c,−), q0), (q1, (B2, b,−), q0)},{q0}, (B2))The composition of B1 and B2, the automaton B{c}∅ , yields also a synchronizationclique generating the corresponding sublanguages Lq0q0 = {(ab)n|n ≥ 0}∪{b(ab)m|m ≥0} and Lq1q1 = {a(ba)n|n ≥ 0} ∪ {(ba)m|m ≥ 0}. Unlike A{c}{d}, however, the reduc-tion of B{c}∅ results in a non-deterministic specification (cf. Figure 5(b)). It is transition(q0, (B1, c,−), q1) of B1 that enables this phenomenon, not the flip-flop between B2’sstates over c. Fortunately, action prefixes provide us with the means to disambiguate theconflicting transitions. In particular, (r0, (B2, c,−), r1) can only occur after a synchro-2 These automata have been especially designed to reproduce an effect, which we have observed in many system specifica-tions that we have analyzed over time [13].14M. Lumpe(B2,c,−)((B1), (B2))(B2,c,−)(B2,c,−)(B2,b,B1)(B1,a,B2)(B1,c,−)(B1,c,−)(B2,c,−)q0q0q0q1 q1q1q1q0c(a) B{c}∅(B2,c,−)((B1), (B2))(B2,c,−) (B1,c,−)/(B2,c,−)(B2,c,−)/(B1,c−)r0r1 r2c(b) B-R{c}∅Fig. 5. The weakly-bisimular component interaction automata B{c}∅ and B-R{c}∅ .nization sequence [b](ab)∗, whereas (r0, (B2, c,−), r2) is enabled by [a](ba)∗. The pre-fixes [b](ab)∗ and [a](ba)∗ capture the possible corresponding reified synchronization pathswithin automaton B{c}∅ induced by synchronization clique {q0q0, q1q1}, as illustrated inFigure 6.(B1,a,B2)(B2,b,B1)(B2,c,−)q0q0q0q1 q1q1(a) Prefix [b](ab)∗.(B2,b,B1)(B1,a,B2)(B2,c,−)q0q0q1q1q1q0(b) Prefix [a](ba)∗.Fig. 6. The prefix-giving interaction sequences in B{c}∅ .Definition 4.2 Let C = (Q,Act , δ, I,H) be a component interaction automaton, Σ be theinduced alphabet of C, and (V,E) be a synchronization clique in C. Then a finite actionprefix generator is a quadruple CP = (V,Act , E, qP ), where• V is the set of clique states,• Act = {a|(q, (n, a, n′), p) ∈ E} is the prefix alphabet,• E = {(q, a, p)|(q, (n, a, n′)p) ∈ E} is the prefix transition function,• qP ∈ V is a prefix state, if there is l ∈ Σ such that qP l−→ p′ ∈ δ, p′ 6∈ V , andall states in V are start states. We write AP [q] to denote the action prefix generator forprefix state q. If WP is the set of all prefix strings that AP [q] accepts in q, we say thatWPis the action prefix language of AP [q] and write L(AP [q]) = WP .An action prefix generator simultaneously explores all possible paths in a synchroniza-tion clique in order to distill the required action prefixes for a given prefix state. Froma technical point of view, a prefix generator iterates over all clique states in (V,E) andconstructs for each a finite state machine whose language is the union of all acceptedaction prefixes for a given prefix state. For example, in automaton B{c}∅ , both states inthe synchronization clique {q0q0, q1q1} are prefix states and the generated languages areL(AP [q0q0]) = {b0:1(ab)n|n ≥ 0} and L(AP [q1q1]) = {a0:1(ba)m|m ≥ 0}, which we15M. Lumpedenote by the action prefixes [b](ab)∗ and [a](ba)∗. On the other hand, state q1q1 in au-tomaton A{c}{d} (cf. Figure 4(a)) is not a prefix state and we, therefore, obtain only a prefixfor state q0q0 (i.e., [b](ab)∗).Definition 4.3 Let C = (Q,Act , δ, I,H) be component interaction automaton, q l−→ q′ ∈δ, and AP [q] = α be an action prefix, then q/α/l−→ q′ is a α-prefixed transition, with/α/l =(−, /α/a, n) if l = (−, a, n),(n, /α/a,−) if l = (n, a,−), and(n1, /α/a, n2) if l = (n1, a, n2).Returning to the reduced automaton B-R{c}∅ (cf. Figure 5(b)), we can obtain a deter-ministic version B-R’{c}∅ by applying the generated prefixes to the conflicting transitions:B-R’{c}∅ = ({r0, r1, r2}, {a, b, c},{(r0, (B2, /[b](ab)∗/c,−), r1), (r0, (B2, /[a](ba)∗/c,−), r2), (r0, (B1, /[b](ab)∗/c,−), r2),(r1, (B2, c−), r0), (r1, (B1, c,−), r0), (r2, (B2, c,−), r0)},{r0}, ((B1), (B2))B-R’{c}∅ is, naturally, not weakly-bisimular to B-R{c}∅ , as prefixed transitions producea different behavior. However, we can restore bisimularity by erasing the added prefixes.We can think of prefixes as types [4], or more precisely sequence types [23], that explicitlyrecord interaction constraints of the reduced component interaction automaton.The composition of action prefixes is defined in the usual way. The composition of a re-fined automaton, containing prefixed transitions, with another automaton and the successiverefinement may yield new action prefixes that have to be incorporated into the final result.We use the regular concatenation operation to built composite action prefixes. For exam-ple, if an existing action prefix [f ](ef )∗ needs to be prefixed by [b](ab)∗, then the newlycomposed action prefix becomes [f ](ef )∗[b](ab)∗. That is, before an interaction prefixedwith [f ](ef )∗[b](ab)∗ can occur, the corresponding component interaction automata musthave performed a, possibly empty, sequence of internal synchronizations over actions f ande, followed by a, possibly empty, sequence of internal synchronizations over actions b anda.Finally, we need to incorporate the prefix mechanism into the composition rule (cf.Definition 2.3) for new synchronizations, δNewSync . We use the tags ‘?’ to indicate a prefixassociated with an input action and ‘!’ to denote a prefix originating from an output action.Definition 4.4 Let q1(n1,/α1/a,−)−−−−−−−−→ q′1 and q2(−,/α2/a,n2)−−−−−−−−→ q′2 be two prefixed transitionsthat synchronize according to Definition 2.3. Then q(n1,/?α1!α2/a,n2)−−−−−−−−−−−→ q′ is the resultingprefixed synchronization transition, where ?α1!α2 is an atomic directional prefix.Two component interaction automata can synchronize through matching complemen-tary structured labels. These labels may, in turn, occur prefixed as result of a previousrefinement of the underlying automata. These prefixes, however, cannot simply be con-catenated as regular prefixes. Each prefix encodes either an input constraint or an output16M. Lumpeconstraint, which we both must retain. On the surface, this appears cumbersome, but wefacilitate the use of directional prefixes by considering them atomic, as if they were plainactions. We only require, as for all prefixes, that they are well-formed, that is, they areregularly composed of elements from the set, Act , of actions.5 DiscussionWe cannot underestimate the computational needs for the construction of a composite com-ponent interaction automaton. For example, even for a relatively small system consisting ofcomponents with no more than 4 states, the resulting product automaton requires easily inexcess of 16,000 states with approx. 880,000 transitions and can take more than 6 hours tocompute on a PC equipped with a 2.2 GHz dual-core processor and 2GB of main memory[13].To study different means for an effective specification and construction of componentinteraction automata, we have developed an experimental composition framework for Com-ponent Interaction Automata in PLT-Scheme [21] that provides modular support for thespecification, composition, and refinement of component interaction automata [13]. Allanalysis and transformation functions in the system are timed and can be controlled by avariety of parameters to fine-tune the induced operational semantics of an operation. Thesystem also generates information about frequencies and distributions of states and transi-tions within composite automata, data that allows for an independent statistical analysis ofthe effects of composition and refinement.One of the rather unexpected findings, while conducting experiments in our composi-tion framework, is the existence of synchronization cliques in component interaction au-tomata. To explain their presence, we have adopted some of the terminology that has beendeveloped in network theory in order to characterize properties of complex networks [17].Of particular interest are small-world networks that have been discovered in an astonishingnumber of natural phenomena, but also in software systems. Potanin et al. [22] have stud-ied Java programs and detected power laws in object graphs indicating that object-orientedsystems form scale-free networks [17]. A consequence of the existence of power laws inobject-oriented systems is that there is no typical size to objects [22]. We find a similarproperty, both, in component interaction automata and emerging synchronization cliques.But there remains a curiosity as to why synchronization cliques exist. We do not finda similar phenomenon in process-based models [24,9,16,12,15]. There is, however, a dif-ference in the way internal sysnchronizations are represented. Process-based formalismsuse a special symbol, τ , to denote the handshake between two matching, interacting pro-cesses. The synchronization of processes takes place internally. From an external ob-server’s point of view, we notice the occurrence of a process synchronization through adelay between adjacent interactions with the environment. Milner [16] calls τ a perfectaction, which arises from a pair of complementary input- and output-actions. What makesτ special is the observable equivalence between a sequence P1τ−→ P2 τ−→ · · · τ−→ Pnof process synchronizations and a single synchronization P1τ−→ Pn. A similar conceptdoes not exist in Component Interaction Automata and its predecessors I/O Automata andInterface Automata. We cannot equate a sequence of internal synchronizations in a com-ponent interaction automaton with a single action. First, such an abstraction would ignorethe inherent partial order defined by a synchronization sequence and second, there exists17M. Lumpeno designated action in the Component Interaction Automata formalism that can subsumeinteraction sequences under one umbrella. Moreover, the precise sequence of internal syn-chronizations conveys a valuable information. For example, the Store will only issue theaction (Store, ship,−) after a successful interaction with the Bank to redeem the paymentvoucher (cf. Figure 2). This knowledge is vital for the understanding of the behavior of thewhole e-commerce system S{ship}∅ .We have chosen regular expressions like [b](ab)∗ rather than fresh action labels to de-note action prefixes in order to make pre-conditions to interactions as explicit as possible.This works well for simple prefixes. Experiments have shown, however, that the prefixescan grow in complexity rather quickly, rendering this structural technique unwieldy. Wecan envision a nominal approach to the specification of action prefixes in which we assigneach action prefix a unique identifier and add a corresponding lookup table to the specifi-cation of the component interaction automata in question.Finally, the outcome of partition refinement can be improved even further, if we erasethe information about the underlying composition hierarchy by making the analyzed com-ponent primitive before refinement [13]. The composition of multiple instances of thesame component can produce identical sub-structures in the resulting composite automa-ton. However, the unique component identifiers used to disambiguate shared actions pre-vent partition refinement from simplifying common sub-structures into a single, unifyingone. We can overcome this difficulty by creating a fresh image of a given component in-teraction automaton in which all component names are the same. We will lose, though, theinformation, which particular sub-component participates in an actual occurring interactionwith the environment.6 Conclusion and Future WorkIn this paper we have discussed some of the effects that partition refinement can producewhen we apply this state space reduction technique to Component Interaction Automataspecifications. We use weak bisimulation as underlying equivalence relation to drive therefinement process. From an external observer’s point of view, weak bisimulation yields ameans to hide internal intra-component synchronizations.While a corresponding implementation of partition refinement for Component Interac-tion Automata specifications is feasible and effective, its application has revealed a specificproperty of component interaction automata that mandates an additional analysis to recoverpre-conditions encoded in so-called synchronization cliques. A synchronization clique isa subgraph of internal intra-component synchronizations that define guards for componentinteractions with the environment. Partition refinement removes synchronization cliquesfrom the specification of given component interaction automaton. But, in this paper, wehave presented a workable solution to restore pre-conditions in reduced automata, whennecessary.We are only beginning to understand the emerging properties of software systems ingeneral and component-based software systems in particular. There is sufficient evidencefor the existence of small-world networks in software. To further our knowledge in thisarea, in future work we aim at studying network effects in component interaction automataspecifications. In particular, we seek to explore possibilities to (i) predict the presence ofsynchronization cliques, (ii) estimate the reduction ratio, and (iii) use frequency distribu-18M. Lumpetions to monitor evolutionary changes in component interaction automata specifications.References[1] Beugnard, A., J.-M. Je´ze´quel, N. Plouzeau and D. Watkins, Making Components Contract Aware, IEEE Computer 32(1999), pp. 38–45.[2] Brim, L., I. Cˇerna´, P. Varˇekova´ and B. Zimmerova, Component-Interaction Automata as a Verification-OrientedComponent-Based System Specification, SIGSOFT Software Engineering Notes 31 (2006), pp. 1–8.[3] Broy, M., A Core Theory of Interfaces and Architecture and Its Impact on Object Orientation, in: R. H. Reussner, J. A.Stafford and C. A. Szyperski, editors, Architecting Systems with Trustworthy Components, LNCS 3938 (2004), pp.26–47.[4] Cardelli, L., Type Systems, in: Handbook of Computer Science and Engineering, CRC Press, 1997 pp. 2208–2236.[5] Cˇerna´, I., P. Varˇekova´ and B. Zimmerova, Component Substitutability via Equivalencies of Component-InteractionAutomata, Electronic Notes in Theoretical Computer Science 182 (2007), pp. 39–55.[6] de Alfaro, L. and T. A. Henzinger, Interface Automata, in: V. Gruhn and A. M. Tjoa, editors, Proceedings ESEC/FSE2001 (2001), pp. 109–120.[7] de Alfaro, L., T. A. Henzinger and M. Stoelinga, Timed Interfaces, in: S.-V. A. L. and J. Sifakis, editors, Proceedingsof 2nd International Conference on Embedded Softare (EMSOFT 2002), LNCS 2491 (2002), pp. 108–122.[8] Habib, M., C. Paul and L. Viennot, Partition Refinement Techniques: An Interesting Algorithmic Tool Kit, InternationalJournal of Foundations of Computer Science 10 (1999), pp. 147–170.[9] Hermanns, H., “Interactive Markov Chains: The Quest for Quantified Quality,” LNCS 2428, Springer, Heidelberg,Germany, 2002.[10] Hopcroft, J. E., R. Motwani and J. D. Ullman, “Automata Theory, Languages, and Computation,” Pearson Education,2007, 3rd edition.[11] Lee, E. A. and Y. Xiong, System-Level Types for Component-Based Design, in: T. A. Henzinger and C. M. Kirsch,editors, Proceedings of 1st International Workshop on Embedded Software (EMSOFT 2001), LNCS 2211 (2001), pp.237–253.[12] Lumpe, M., “A pi-Calculus Based Approach to Software Composition,” Ph.D. thesis, University of Bern, Institute ofComputer Science and Applied Mathematics (1999).[13] Lumpe, M., L. Grunske and J.-G. Schneider, State Space Reduction Techniques for Component Interfaces, in: M. R. V.Chaudron and C. Szyperski, editors, CBSE 2008, LNCS 5282 (2008), pp. 130–145.[14] Lunch, N. A. and M. R. T. Tuttle, Hierarchical Correctness Proofs for Distributed Algorithms, in: Proceedings of theSixth Annual ACM Symposium on Principles of Distributed Computing, Vancouver, British Columbia, Canada, 1987,pp. 137–151.[15] Mateescu, R., P. Poizat and G. Salau¨n, Adaptation of Service Protocols Using Process Algebra and On-the-FlyReduction Techniques, in: Proceedings of ICSOC 2008, LNCS 5364 (2008), pp. 84–99.[16] Milner, R., “Communication and Concurrency,” Prentice Hall, 1989.[17] Newman, M. E. J., The Structure and Function of Complex Networks, SIAM Review 45 (2003), pp. 167–256.[18] Paige, R. and R. E. Tarjan, Three Partition Refinement Algorithms, SIAM Journal on Computing 16 (1987), pp. 973–989.[19] Park, D., Concurrency and Automata on Infinite Sequences, in: P. Deussen, editor, 5th GI Conference on TheoreticalComputer Science, LNCS 104 (1981), pp. 167–183.[20] Pistore, M. and D. Sangiorgi, A Partition Refinement Algorithm for the pi-Calculus, Information and Computation 164(2001), pp. 264–321.[21] PLT Scheme, “v372,” http://www.plt-scheme.org (2008).[22] Potanin, A., J. Noble, M. R. Frean and R. Biddle, Scale-Free Geometry in OO Programs, Commun. ACM 48 (2005),pp. 99–103.[23] Puntigam, F., Coordination Requirements Expressed in Types for Active Objects, in: M. Aksit and S. Matsuoka, editors,Proceedings ECOOP ’97, LNCS 1241 (1997), pp. 367–388.[24] Schneider, J.-G. and O. Nierstrasz, Components, Scripts and Glue, in: L. Barroca, J. Hall and P. Hall, editors, SoftwareArchitectures – Advances and Applications, Springer, 1999 pp. 13–25.[25] Seco, J. C. and L. Caires, A Basic Model of Typed Components, in: E. Bertino, editor, Proceedings of ECOOP 2000,LNCS 1850 (2000), pp. 108–128.[26] Szyperski, C., “Component Software: Beyond Object-Oriented Programming,” Addison-Wesley / ACM Press, 2002,Second edition.[27] ter Beek, M. H., C. A. Ellis, J. Kleijn and G. Rozenberg, Synchronizations in Team Automata for Groupware Systems,Computer Supported Cooperative Work 12 (2003), pp. 21–69.1920FACS 2009Behaviour Protocols for InteractingStateful Components with Ports 1Sebastian S. Bauer, Rolf Hennicker, Stephan JanischInstitut fu¨r InformatikLudwig-Maximilians-Universita¨t Mu¨nchen{bauerse, hennicker, janisch}@pst.ifi.lmu.deAbstractWe propose a formal foundation for behaviour protocols of interacting components with (encapsulated)data states. Formally, behaviour protocols are given by labelled transition systems which specify the orderof operation invocations as well as the allowed changes of data states of components in terms of pre- andpostconditions. We study the compatibility of protocols and we consider their composition which yields abehaviour protocol for a component assembly. Behaviour protocols are equipped with a model-theoreticsemantics which describes the class of all correct component or assembly implementations. Implementationmodels are again formalised in terms of labelled transition systems and the correctness notion is based on analternating simulation relation between protocol and implementation which takes into account control anddata states. As a major result we show that our approach is compositional, i.e. that correct implementationmodels of compatible protocols compose to a correct implementation of the resulting assembly protocol.Keywords: Behaviour protocol, pre- and postcondition, stateful component, compositionality1 IntroductionComponent-based software development has received much attention not only inpractice but also in theory during the last decade. Thereby an important role isplayed by formal specifications of component behaviours which are usually basedon a control-flow oriented perspective describing the sequences of actions a com-ponent can perform when interacting with its environment; cf., e.g., [12]. Someapproaches also consider data that can be transmitted by value passing messagesbut less attention has been directed towards the integration of data states thata component can possess and which are typically specified by invariants and pre-and postconditions in sequential systems. Frameworks like CSP-OZ [6] or rCOS [8]support this facility but they do not distinguish (at least semantically) betweeninput and output actions and their expressive power is limited to cases where theeffect of an operation is specified independently of the control-flow behaviour of1 This research has been partially supported by the GLOWA-Danube project 01LW0602A2 sponsored bythe German Federal Ministry of Education and Research.This paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs21Bauer, Hennicker, Janischa component. Other approaches are based on symbolic transition systems with astrong focus on the generation of abstractions for model checking [1,5] but they donot study formal correctness notions to relate specifications and implementationswhich is needed in a top-down development process. The goal of this work is toprovide a formal foundation for interacting stateful components with a clear separa-tion between specification and implementation such that the latter can still choose“among the possibilities left by the specification”; see [1]. Of crucial importance is,of course, the study of component composition and preservation of local correctnessin global contexts. In this paper we propose an integrated framework which takesinto account control flow and the evolution of component data states as well asthe discrimination of input and output for distinguishing operation reception andoperation calls. In particular, we are interested in a contract-based specificationstyle where the caller of an operation can formulate its assumptions and guaranteeswith respect to the data state of the called component. On this basis we studycompatibility of specifications, which are called behaviour protocols hereafter.As a roadmap for this paper we follow the ideas of de Alfaro and Henzinger [3]who have studied interface automata, their refinement, their compatibility and theircomposition and we aim at an extension of these ideas by taking into account state-ful components, where components are equipped with local data states to allowfor an evaluation of pre- and postconditions attached to the labels of a behaviourprotocol. In the context of data states we cannot use the same formalism for speci-fication and refinement (implementation) of component behaviour which both havebeen formalised in terms of interface automata in [3,4]. Though labelled transitionsystems still provide an appropriate basis, the crucial difference here is that for thepurpose of behaviour specification labels must include logical predicates describingpre- and postconditions while for modelling component implementations labels mustrepresent concrete actions like operation invocations which can occur in concretestates of an implementation. As a consequence, we must adjust the alternating sim-ulation relation used by de Alfaro and Henzinger in an appropriate way. Therebyan important role is played by so-called observers which determine the visible statesof components.After providing the necessary technical preliminaries we introduce the mainstructural elements of our component model in Sect. 2. We study compatibility ofbehaviour protocols of different components (and assemblies) which are supposedto be composed via connectors between open ports of components (and assemblies)in Sect. 3. Our notion of compatibility extends the corresponding notion in [4] byrequiring that if an operation can be called by one component such that the requiredprecondition is satisfied then the connected component must be able to treat theoperation invocation in the specified way. We define the (synchronous) compositionof behaviour protocols which turns out to have the expected properties (see below)if the protocols are compatible.In the next step, in Sect. 4, we focus on component (and assembly) implemen-tations which are formalised as labelled transition systems whose states are dividedinto a control part and a data part and whose transitions carry labels which rep-resent sending or receiving of concrete operation invocations for particular actualparameters. We define a correctness notion for implementations in the spirit of22Bauer, Hennicker, Janischthe alternating simulation relation used for refinements in [4] which requires thatany specified input must be accepted by an implementation and that, conversely,any possible output of an implementation must be admitted by the behaviour pro-tocol. In the context of data states the alternating simulation relation between abehaviour protocol and an implementation model is, however, more involved sinceit has to take into account pre- and postconditions in protocols which must be re-lated to the (visible) data states of component implementations when transitionsare performed. Our main theorem shows that the proposed concepts for protocolcompatibility and implementation correctness work smoothly together. This means,two implementation models which are locally correct w.r.t. compatible behaviourprotocols compose to a correct implementation model of the composed behaviourprotocol.Preliminaries. Our approach is based on labelled transition systems to formalisethe control-flow aspects of component behaviours. A labelled transition system(LTS) M = (Q, q0, L,∆) consists of a set Q of states, an initial state q0 ∈ Q, a setL of labels, and a transition relation ∆ ⊆ Q×L×Q. If (q, l, q′) ∈ ∆, l is enabled atq. M is called L′-enabled, for a set L′ ⊆ L of labels, if for any reachable state q ∈ Qand label l ∈ L′ there is at least one transition in ∆ such that l is enabled at q.To deal with the specification and implementation of the externally visible datastates of components we use observer signatures. An observer signature ΣObs con-sists of a set of (visible) state variables. A ΣObs-data state σ : ΣObs → V assigns toeach state variable in ΣObs a value in some predefined data universe V. The classof all ΣObs-data states is denoted by D(ΣObs). For any observer signature ΣObs, weassume given a set S(ΣObs) of state predicates ϕ and a set T (ΣObs) of transitionpredicates pi with associated sets var(ϕ) and var(pi) of variables. State predicatesrefer to single states and transition predicates refer to pre- and poststates. Weassume that state predicates ϕ ∈ S(ΣObs) are equipped with a satisfaction relationσ; ρ ϕ for states σ ∈ D(ΣObs) and valuations ρ : var(ϕ)→ V. Similarly, for tran-sition predicates pi ∈ T (ΣObs) we assume a satisfaction relation σ, σ′; ρ pi, for twostates σ, σ′ ∈ D(ΣObs) and valuation ρ : var(pi) → V. For ϕ ∈ S(ΣObs), we write ϕ to express that ϕ is universally valid, i.e. σ; ρ ϕ for all states σ ∈ D(ΣObs)and for all valuations ρ : var(ϕ) → V. Universal validity of transition predicates isdefined in the analogous way. We assume that state predicates (transition predi-cates resp.) are closed under the usual logical connectives (like ∧,⇒, etc.) with theusual interpretation. In some occasions we will use state predicates in combinationwith transition predicates. Then a state predicate ϕ ∈ S(ΣObs) is considered as aspecial transition predicate where σ, σ′; ρ ϕ is defined by σ; ρ ϕ. We do notfix a particular syntax for observer signatures, observers, and predicates here. Inthe examples unprimed symbols refer to the prestate and primed symbols to thepoststate of a transition.2 Component ModelIn this section we summarize the structural concepts of our component model whichextends the one in [7] by introducing observer signatures for ports and components.We do, however, not consider hierarchical components here and we make the sim-23Bauer, Hennicker, Janischplifying assumption that names of ports and components are globally unique.Components interact with each other by using operations which belong to theprovided and required interfaces of their ports. An operation op is of the formopname(Xin) where Xin is a (possibly empty) sequence of input variables. 2 Wewrite varin(op) to refer to the input variables of an operation op. An interface is apair (ΣObs,Op) consisting of an observer signature ΣObs and a set Op of operations.A port signature (Iprov, Ireq) consists of a provided interface Iprov and a requiredinterface Ireq. Throughout this paper when we talk about a port P , we alwaysassume given a port declaration P : Σ where Σ is a port signature and P is a globallyunique port name. We write prv(P ) for the provided interface of Σ, obsprv (P ) forthe observer signature and opnsprv (P ) for the operations of prv(P ). The operationsin opnsprv (P ) are offered at port P and the observer signature obsprv (P ) definesthe possible obervations that can be made at this port (about the data state ofits owning component). Symmetrically, we write req(P ) for the required interfaceof Σ, obsreq(P ) refers to the observer signature and opnsreq(P ) to the operationsof the required interface of req(P ). In this case, the operations in opnsreq(P ) arerequired from components which are connected to P and the observer signatureobsprv (P ) defines which observations are required about the data states of connectedcomponents.Components encapsulate data states and interact with their environment viaports. The data states of a component can only be observed via observers whichare determined by the component’s observer signature. The access points of acomponent are given by ports. Formally, a component signature (ΣObs, (P : ΣP )P∈I)consists of an observer signature ΣObs and a finite family of port declarations P :ΣP . In the following when we talk about a component C, we always assume givena component declaration C : Σ where Σ is a component signature and C is aglobally unique component name. We write obs(C) to refer to the observer signatureand ports(C) to refer to the ports declared in Σ. We require that for all portsP ∈ ports(C), obsprv (P ) = obs(C), i.e. on each port all observers of its owningcomponent are visible. 3 For a port P , cmp(P ) denotes its owning component.For building assemblies we connect ports of components. If P1 and P2 are portssuch that req(P1) = prv(P2) and req(P2) = prv(P1), then K : {P1, P2} is a (binary)connector declaration where K is a globally unique connector name. In the followingwhen we talk about a connector K, we always assume given a connector declarationof the form K : {P1, P2} and we write ports(K) to refer to its set of ports {P1, P2}.An assembly A = 〈(C : ΣC)C∈I ; (K : {PK1 , PK2 })K∈I′〉 consists of a finite familyof component declarations C : ΣC and a finite family of connector declarationsK : {PK1 , PK2 }. We write cmps(A) to refer to the components of the assembly,conns(A) to refer to its connectors and we define ports(A) =⋃{ports(C) | C ∈cmps(A)}. The open ports of A, i.e., the ports which are not connected, are givenby open(A) = ports(A) \ ⋃{ports(K) | K ∈ conns(A)}. For the above definitionsto make sense, we require that (i) only ports of components inside A are connected,2 For the sake of simplicity we do not consider output variables here which, however, could be easilyintegrated in our framework.3 In general, the observers of a port could be a subset of the component’s observers or should be relatedby an abstraction function. This could be methodologically desirable to emphasize the difference betweenport and component protocols which, however, goes beyond the scope of this paper.24Bauer, Hennicker, Janischi.e., for all K ∈ conns(A) we have that ports(K) ⊆ ports(A); and (ii) there is atmost one connector for each port, i.e., if P ∈ ports(A) and K,K ′ ∈ conns(A) withP ∈ ports(K)∩ ports(K ′), then K = K ′. Finally, composition of two assemblies A1and A2 via a connector K : {P1, P2} with Pi ∈ open(Ai) for i = 1, 2 is denoted byA = A1 +K A2 and defined by cmps(A) = cmps(A1) ∪ cmps(A2) and conns(A) =conns(A1) ∪ conns(A2) ∪ {K : {P1, P2}}.S Turnstile OKT OperatorFigure 1. Components of the turnstile system.Example 2.1 Our running example models a turnstile located at the entrance ofa subway. The static structure of the system is given by the assembly depicted inFig. 1. It consists of two components, Turnstile and Operator, which are connectedvia their ports O and T . The port S of the turnstile is left open. The observersignatures and the provided and required operations on each port will be explainedlater when the behaviour protocols of the two components are discussed.3 Behaviour Protocols and their CompatibilityBehaviour protocols are a means to specify the observable behaviour of componentsand assemblies. For components they specify the legal sequences of operation in-vocations on the ports of a component, their invocation conditions and their effectwith respect to the (visible) data state of a component. For assemblies behaviourprotocols specify on the one hand, the legal interactions between connected compo-nents (taking into account the components’ states) and, on the other hand, the legalsequences of invocations on those ports which are left open in the assembly. We startby introducing the syntax of behaviour protocols which are given by appropriatelabelled transition systems.Protocol labels are divided into labels LP(P ) for ports P and labels LP(K) forconnectors K; see Fig. 2. Labels for ports model either receiving (?) or sending(!) of a message. Messages which are supposed to be received must correspond tooperations of the provided interface of a port while messages which can be sentmust correspond to operations of the required interface of a port. Protocol labelscan be equipped with pre- and postconditions represented by state and transitionpredicates of the respective observer signatures. A label [ϕ]?P.m[pi] for a portP expresses that port P is ready to receive an operation invocation of m underthe assumption that the precondition ϕ holds, and after the execution of m thepostcondition pi is ensured. In this case ϕ must be a state predicate and pi atransition predicate over the observer signature of the provided interface of port P .A label [ϕ]!P.m[pi] describes the sending of an invocation of m on port P with theguarantee of the precondition ϕ upon operation call and with the expectation thatpi holds when the operation is finished. Here ϕ must be a state predicate and pi atransition predicate over the observer signature of the required interface of port P .For a connector K which connects two ports Pi and Pj , a label [ϕ]Pi .K Pj .m[pi]stands for the synchronised sending, reception and execution of an operation m via25Bauer, Hennicker, Janisch1. Labels LP (P ) for a port P , m ∈ opnsprv (P ), n ∈ opnsreq (P ):• [ϕ]?P.m[pi] where ϕ ∈ S(obsprv (P )), var(ϕ) ⊆ varin(m), pi ∈ T (obsprv (P )), var(pi) ⊆ varin(m)• [ϕ]!P.n[pi] where ϕ ∈ S(obsreq (P )), var(ϕ) ⊆ varin(n), pi ∈ T (obsreq (P )), var(pi) ⊆ varin(n)2. Labels LP (K) for a connector K : {P1, P2}, m ∈ opnsprv (Pj), i, j ∈ {1, 2}, i 6= j:• [ϕ]Pi .K Pj .m[pi] where ϕ ∈ S(obsprv (Pj)), var(ϕ) ⊆ varin(m), pi ∈ T (obsprv (Pj)), andvar(pi) ⊆ varin(m)3. Labels LP (A) for an assembly A: LP (A) = SP∈open(A) LP (P ) ∪SK∈conns(A) LP (K)Figure 2. Labels for protocols.the connected ports Pi and Pj . In this case the pre- and postconditions must bepredicates over the observer signature obsreq(Pi) (which is the same as obsprv (Pj)since required and provided interfaces of connected ports coincide). For an assemblyA the protocol labels in LP(A) are those labels which correspond to connectors orto open ports of A.Definition 3.1 [Behaviour Protocol]Let A be an assembly. A behaviour protocol for A, also called A-protocol, is an LTSF = (S, s0,LP(A),∆) where S is a finite set of protocol states, s0 ∈ S is the initialprotocol state, LP(A) is the set of protocol labels, and ∆ is a finite protocol transitionrelation. The class of all A-protocols is denoted by Prot(A).Here and in the following all definitions and results are provided for assembliesbut they carry over to components since a component C can be identified witha degenerated assembly 〈{C}; ∅〉 which contains only the component C and noconnectors. From the methodological point of view behaviour protocols for a properassembly A correspond to architecture protocols in [11] while behaviour protocolsfor components C correspond to frame protocols in [11] and to interface automatain [3].Example 3.2 Let us now come back to the turnstile example with the assemblyshown in Fig. 1. For the observer signature of the Turnstile component we usetwo visible state variables: fare for the actual costs of a trip, and passed for thenumber of persons that have already passed the turnstile. The turnstile has twoports S and O. At port S no operation is required and two operations are provided:coin(x : int) for dropping a coin with amount x into the turnstile’s slot, and pass()for passing through the turnstile. At port O the turnstile requires an operationalarm() to inform the operator that a client has tried to pass the turnstile withoutpaying and an operation ready() is provided to switch off the alarm mode.Fig. 3 presents the frame protocol FT of component Turnstile. If in the initialstate LOCKED a coin is deposited whose value is at least the required fare theturnstile becomes unlocked. In the state UNLOCKED a person can pass throughthe turnstile with the effect that the number of passed persons is increased by oneand the state LOCKED is reached again. If a person tries to pass the turnstilewithout dropping a coin into its slot this causes the turnstile to send out an alarmon its port O. On the same port the alarm can be shut off by invoking ready.The frame protocol FO of component Operator is shown in Fig. 4. It says that an26Bauer, Hennicker, Janischoperator can invoke ready whenever an alarm has been received. If a protocol labelshows no explicit pre- or postcondition we implicitly assume the trivial predicatetrue. For instance, in the turnstile protocol of Fig. 3 the transition with label?S.pass() between the states LOCKED and ON ALERT has the implicit pre- andpostcondition true (and hence is underspecified) while for the same operation calledin state UNLOCKED the postcondition is passed′ = passed + 1. This shows thatthe effect of an invocation of a particular operation may indeed depend on thesource state where the operation is called which can be conveniently specified bythe behaviour protocols as introduced here.UNLOCKED LOCKEDALARMON ALERT!O.alarm()?S.pass()[passed ′ = passed + 1][x ≥ fare]?S.coin(x) ?O.ready()?S.pass()Figure 3. Protocol FT of component Turnstile.IDLE?T.alarm()!T.ready()ALARMFigure 4. Protocol FO of component Operator.Two behaviour protocols can be combined to an assembly protocol that de-scribes the behaviour of a system with interacting components. For this purpose weintroduce a composition operator K which composes two protocols in accordancewith a connector K between ports P1 and P2. The composition synchronises tran-sitions whose labels match on corresponding inputs and outputs on P1 and P2 andvice versa. For instance, a transition with label [ϕ1]!P1.op[pi1] of the first protocolis synchronised with a transition with label [ϕ2]?P2.op[pi2] of the second protocolwhich yields a transition with label [ϕ1 ∧ ϕ2]P1 .K P2.op[pi1 ∧ pi2]. The resultingtransition expresses a correct communication which can only occur if both precon-ditions and both postconditions are satisfied. Thus by protocol composition viaa connector K with ports(K) = {P1, P2}, two transitions with matching labels inLP(P1) and LP(P2) are synchronised to a single transition with label in LP(K).Transitions with labels in LP(P1) ∪ LP(P2) which can not be matched are deletedand all other transitions are interleaved.Definition 3.3 [Protocol Composition]For i ∈ {1, 2}, let Ai be assemblies, Pi ∈ open(Ai), Fi = (Si, s0,i,LP(Ai),∆i) ∈Prot(Ai), and let K : {P1, P2} be a connector. The protocol composition of F1 andF2 via K is defined byF1 K F2 = (S1 × S2, (s0,1, s0,2),LP(A1 +K A2),∆)where ∆ is the least relation satisfying: if (s1, s2) ∈ S1 × S2 then27Bauer, Hennicker, Janisch(1) for i, j ∈ {1, 2}, i 6= j, for all op ∈ opnsreq(Pi), li = [ϕi]!Pi.op[pii] ∈ LP(Pi),and lj = [ϕj ]?Pj .op[pij ] ∈ LP(Pj), if (si, li, s′i) ∈ ∆i and (sj , lj , s′j) ∈ ∆j then((s1, s2), [ϕi ∧ ϕj ]Pi .K Pj .op[pii ∧ pij ], (s′1, s′2)) ∈ ∆;(2) for all l1 ∈ LP(A1) \ LP(P1) and s2 ∈ S2,if (s1, l1, s′1) ∈ ∆1 then ((s1, s2), l1, (s′1, s2)) ∈ ∆;(3) for all l2 ∈ LP(A2) \ LP(P2) and s1 ∈ S1,if (s2, l2, s′2) ∈ ∆2 then ((s1, s2), l2, (s1, s′2)) ∈ ∆.The composition operator for protocols is associative (up to equivalence of pre-conditions and of postconditions). It is related to the synchronous product of sym-bolic transition systems defined in [5] where synchronisation vectors are used in-stead of corresponding input/output labels. While in [5] predicates occurring inlabels always refer to the data states of the owning component, in our approachwe distinguish between send labels, whose predicates refer to the data states of theconnected component, and receive labels whose predicates refer to the data statesof the owning component.Apparently, the conjunctions of the preconditions and of the postconditions usedin the protocol composition do, in general, not allow for independent implementabil-ity which can only be ensured if the protocols to be composed are compatible. Twoprotocols are compatible w.r.t. a connector K if their transitions with send labels ona port of K can be mutually simulated by corresponding transitions with a match-ing input label on the opposite port. In particular, the pre- and postconditions ofmatching labels must subsume each other in the usual covariant manner where it isallowed to weaken preconditions and to strengthen postconditions; cf., e.g. [9,13].Formally, we define protocol compatibility by using the following compatibility re-lation (which is a particular kind of a mutual simulation relation).Definition 3.4 [Compatibility Relation]For i ∈ {1, 2}, let Ai be assemblies, Pi ∈ open(Ai), Fi = (Si, s0,i,LP(Ai),∆i) ∈Prot(Ai), and K : {P1, P2} be a connector. A K-compatibility relation for F1 andF2 is a relation R ⊆ S1 × S2 such that for all (s1, s2) ∈ R the following holds:(1) for i, j ∈ {1, 2}, i 6= j, for all li = [ϕi]!Pi.op[pii] ∈ LP(Pi), if (si, li, s′i) ∈ ∆i,then there exists a transition (sj , lj , s′j) ∈ ∆j with lj = [ϕj ]?Pj .op[pij ] ∈ LP(Pj)such that (s′i, s′j) ∈ R, (ϕi ⇒ ϕj), and (ϕi ∧ pij ⇒ pii);(2) for all l1 ∈ LP(A1) \ LP(P1), if (s1, l1, s′1) ∈ ∆1 then (s′1, s2) ∈ R;(3) for all l2 ∈ LP(A2) \ LP(P2), if (s2, l2, s′2) ∈ ∆2 then (s1, s′2) ∈ R.Condition (1) formalises the requirements that for every operation call specifiedby a protocol there must exists a corresponding reception specified by the otherprotocol, with the conditions on pre- and postconditions as explained above. Byconditions (2) and (3) compatibility must be independent of other transitions notinvolved in communications on K.Definition 3.5 [Protocol Compatibility]Let F1, F2, K be as in Def. 3.4. F1 and F2 are K-compatible if there exists aK-compatibility relation R for F1 and F2 such that (s0,1, s0,2) ∈ R.28Bauer, Hennicker, Janisch1. Labels L(P ) for a port P , m ∈ opnsprv (P ), n ∈ opnsreq (P ):• ?P.(m, ρ) where ρ : varin(m)→ V• (T, !P.(n, ρ)) where T ⊆ D(obsreq (P )), ρ : varin(n)→ V2. Labels L(K) for a connector K : {P1, P2}, m ∈ opnsprv (Pj), i, j ∈ {1, 2}, i 6= j:• Pi .K Pj .(m, ρ) where ρ : varin(m)→ V3. Labels L(A) for assembly A: L(A) = SP∈open(A) L(P ) ∪SK∈conns(A) L(K)Figure 5. Labels for implementation models.4 Protocol Implementation and CompositionalityIn this section we define a formal semantics for behaviour protocols in terms oftheir correct implementations and we study compositionality of implementationsand protocols. For the formalisation of implementations we follow a model-theoreticapproach where an implementation is represented by an input-enabled labelled tran-sition system, also called implementation model.The states of an implementation model must carry information for both, thecontrol flow and the evolution of data states. To discriminate the two aspects wedistinguish between control states and data states. As already explained in thepreliminaries a (visible) data state is determined by the values of the observers ofa given observer signature. Hence, for a component C, a (visible) data state is anelement σ ∈ D(obs(C)). The underlying state space of C in an implementationmodel is then formed by the cartesian product CtrlC ×QC of a set of control statesCtrlC and a set of data states QC ⊆ D(obs(C)). The state space of an assembly isformed by the cartesian product of the state spaces of all contained components.We will now define the different labels occurring in implementation models. Im-plementation labels are divided, like protocol labels, into labels L(P ) for ports Pand labels L(K) for connectors K; see Fig. 5. The labels in L(P ) describe the ac-tions of receiving or sending an operation invocation on port P . A label of the form?P.(m, ρ) expresses the reception of an invocation of a provided operation m on portP with actual parameters determined by a valuation ρ : varin(m)→ V. A transitionlabelled with ?P.(m, ρ) connects the state where the operation is called with thestate after execution of the operation. Hence the implementation models consideredhere assume atomic operation executions. We do not model non terminating pro-grams here which could, however, be easily integrated by using partial transitionswhich lead to an undefined state ⊥. A label of the form (T, !P.(m, ρ)) expressesthat the implementation sends out an operation call of m with actual parametersρ provided that the receiver is in some state determined by T . More precisely, T isa set of data states over the observer signature of the connected component whichmodels the fact that the implementation only invokes m if the visible data stateof the receiver component belongs to T . In a concrete implementation this wouldmean that the sender component performs in an atomic action a test on the datastate of the receiver component (by means of the observers) and, depending on theresult, invokes the required operation. Implementation models for assemblies mustalso include labels for communication via connectors. For a connector K between29Bauer, Hennicker, Janischports P1 and P2, the set L(K) consists of labels of the form P1 .K P2.(m, ρ) whichexpress the synchronised operation invocation (m, ρ) sent on P1 and received onP2. The target state of a transition labelled by P1 .K P2.(m, ρ) is reached whenthe operation has finished its execution. For an assembly A the implementationlabels in L(A) are those labels which correspond to connectors or to open ports ofA. Moreover, the set of input labels L?(A) of A is given by all labels in L(A) ofthe form ?P.(m, ρ) where P ∈ open(A). Implementation models are required to beL?(A)-enabled, i.e. all provided operations on the open ports of an assembly canbe called in each reachable state.Definition 4.1 [Implementation Model]For an assembly A, an A-implementation model (A-implementation for short) is anL?(A)-enabled LTS M = (Q, q0,L(A),∆) with state spaceQ =∏C∈cmps(A)CtrlC ×QCwhere for each component C ∈ cmps(A), CtrlC is a set of control states and QC ⊆D(obs(C)) is a set of (visible) data states of C. The class of all A-implementationsis denoted by Impl(A). For a state q ∈ Q and a component C ∈ cmps(A) wewrite qC for the projection of q to the state of the component C which is a pairqC = (c, σ) ∈ CtrlC ×QC . We write δ(qC) to refer to the data state part σ of qC .We require that implementation models are well-formed : A component’s statemay only be changed by a transition whose label involves a port of the component.More specifically, the data state of a component C can only be changed by a tran-sition whose label has the form ?P.(m, ρ) or P1 .K P.(m, ρ) where P is a port of C.The formalisation of well-formedness of implementation models is straightforwardand omitted here.Let us now discuss implementation correctness for an implementation model Mw.r.t. a given protocol F . The behaviour protocol F can be considered as a contractbetween the implementor and the users of provided and required operations. Fromthe implementor’s point of view this means that it can be assumed that, first, aprovided operation is only called in a state where the call is admissible accordingto the protocol and, secondly, that the given precondition for the invoked operationis satisfied. Under these assumptions the implementation must ensure that afterthe execution of the operation the given postcondition is satisfied and that one canproceed as specified by the protocol. If the user does not meet the implementor’sassumptions then the implementation can have an arbitrary behaviour. From theuser’s point of view the contract principle imposes the obligation that a requiredoperation is only invoked in accordance with the protocol; in particular the givenprecondition must be satisfied. Then the user can assume that the given postcondi-tion holds after execution of the operation and that she/he can proceed as specifiedby the protocol. It may still be useful to remark that an implementation modelplays, in general, the role of an implementor and the role of a user. The imple-mentor’s role is shown by transitions with labels of the form ?P.(m, ρ) while theuser’s role is shown by transitions with labels of the form (T, !P.(m, ρ)). The aboveconsiderations can be formalised by adapting the concept of an alternating simula-30Bauer, Hennicker, Janischtion relation for interface automata in [3] to our needs where we have to deal withpredicates on the specification level and with data states on the implementationlevel. In this context the alternating simulation relation contains pairs (s, q), wheres is a protocol state and q denotes an assembly state; i.e. q determines, for eachcomponent C in the assembly, the component’s control and data state qC = (c, σ).The simulation relation is alternating, because reception of messages as specified inthe protocol must be simulated in the implementation model, and conversely, everysending of a message in the model must be simulated by the protocol.Definition 4.2 [Alternating Simulation Relation]Let A be an assembly, F = (S, s0,LP(A),∆F , I) ∈ Prot(A) be an A-protocol, andM = (Q, q0,L(A),∆M ) ∈ Impl(A). An alternating simulation relation between Fand M is a relation R ⊆ S ×Q such that for all (s, q) ∈ R,(1) for all P ∈ open(A), C = cmp(P ),(a) for all labels l = [ϕ]?P.op[pi] ∈ LP(P ) and for all ρ : varin(op)→ V,if (s, l, s′) ∈ ∆F and δ(qC); ρ ϕ then for all transitions (q, ?P.(op, ρ), q′) ∈∆M it holds (s′, q′) ∈ R and δ(qC), δ(q′C); ρ pi;(b) for all labels l = (T, !P.(op, ρ)) ∈ L(P ), if (q, l, q′) ∈ ∆M then there exists atransition (s, [ϕ]!P.op[pi], s′) ∈ ∆F such that for all σ ∈ T it holds σ; ρ ϕand (s′, q′) ∈ R;(2) for all K : {P1, P2} ∈ conns(A), C1 = cmp(P1), C2 = cmp(P2) it holds:for i, j ∈ {1, 2}, i 6= j, for all labels l = Pi.KPj .(op, ρ) ∈ L(K), if (q, l, q′) ∈ ∆Mthen there exists a transition (s, [ϕ]Pi .K Pj .op[pi], s′) ∈ ∆F such that (s′, q′) ∈R, δ(qCj ); ρ ϕ and δ(qCj ), δ(q′Cj ); ρ pi.Conditions (1)(a) and (1)(b) formalise the contract principle behind protocolsas described above. Condition (2) expresses that communications between com-ponents on the implementation level must be simulated by corresponding protocoltransitions. Thus we do not treat communications as invisible actions which areabstracted in a refinement relation because for assembly implementations it is stillimportant that communications conform to the protocol. At a later stage one canstill abstract from communications and build a composite component arround anassembly which, however, goes beyond the scope of this paper.We can now define correctness of assembly models w.r.t. assembly protocols interms of alternating simulation relations.Definition 4.3 [Implementation Correctness]Let A be an assembly, F = (S, s0,LP(A),∆F ) ∈ Prot(A) be an A-protocol, andM = (Q, q0,L(A),∆M ) ∈ Impl(A). M is a correct A-implementation of F , if thereexists an alternating simulation relation R between F and M such that (s0, q0) ∈ R.The class of all correct A-implementations of F is denoted by JF K.Implementation models can be composed to build larger systems from smallerones. For this purpose we introduce the operator ⊗K which composes two imple-mentation models in accordance with a connector K between ports P1 and P2. Thecomposition of two models M1, M2 synchronises transitions concerning the con-nected ports if their labels, e.g. (T, !P1.(op, ρ)) and ?P2.(op, ρ), express the sameoperation invocation (op, ρ) and if M1 meets M2 in a state whose visible data part31Bauer, Hennicker, Janisch(of the connected component) lies in the set T which has guarded the send message.The remaining messages on the connected ports P1 and P2 are removed. Transitionswith labels not in L(P1) ∪ L(P2) are interleaved in the model composition.Definition 4.4 [Model Composition]For i ∈ {1, 2}, let Ai be assemblies, Mi = (Qi, q0,i,L(Ai),∆i) ∈ Impl(Ai), Pi ∈open(Ai), and let K : {P1, P2} be a connector. The model composition of M1and M2 via K is defined by M1 ⊗K M2 = (Q, q0,L(A),∆) where A = A1 +K A2,Q = Q1 × Q2, q0 = (q0,1, q0,2), and the transition relation ∆ is the least relationsatisfying(1) for i, j ∈ {1, 2}, i 6= j, for all op ∈ opnsreq(Pi), ρ : varin(op)→ V,if (qi, (T, !Pi.(op, ρ)), q′i) ∈ ∆i and (qj , ?Pj .(op, ρ), q′j) ∈ ∆jand δ(qj,cmp(Pj)) ∈ T , then ((q1, q2), Pi .K Pj .(op, ρ), (q′1, q′2)) ∈ ∆;(2) for all l1 ∈ L(A1) \ L(P1) and q2 ∈ Q2,if (q1, l1, q′1) ∈ ∆1 then ((q1, q2), l1, (q′1, q2)) ∈ ∆;(3) for all l2 ∈ L(A2) \ L(P2) and q1 ∈ Q1,if (q2, l2, q′2) ∈ ∆2 then ((q1, q2), l2, (q1, q′2)) ∈ ∆.The composition operator ⊗K is associative and is straightforward to show thatit preserves well-formedness of implementation models.We are now able to present our final compositionality result which says thattwo correct implementation models with compatible protocols can be composed toa correct implementation model of the composed protocol. Often this is also calledindependent implementability [3]: Under the assumption of compatible protocols,any correct implementation of the first protocol composed with any correct imple-mentation of the second protocol yields a correct implementation of the composedspecification, i.e., protocols can be independently implemented.Theorem 4.5 For i ∈ {1, 2}, let Fi be Ai-protocols, Pi ∈ ports(Ai),Mi ∈ Impl(Ai),and let K : {P1, P2} be a connector. If M1 ∈ JF1K, M2 ∈ JF2K, and F1, F2 are K-compatible, then M1 ⊗K M2 ∈ JF1 K F2K.Proof For i ∈ {1, 2}, let Si be the state space of Fi and Qi be the state space ofMi. By assumption there exist alternating simulation relations R1 ⊆ S1 × Q1 andR2 ⊆ S2 × Q2, and a K-compatibility relation Rcompat ⊆ S1 × S2 for F1 and F2.For proving the correctness of M1 ⊗K M2 we must find an alternating simulationrelation R between F1K F2 and M1⊗KM2 such that ((s0,1, s0,2), (q0,1, q0,2)) ∈ R.We define R by((s1, s2), (q1, q2)) ∈ R :⇐⇒ (s1, q1) ∈ R1 and (s2, q2) ∈ R2 and (s1, s2) ∈ Rcompat.It is straightforward to show that R is indeed an alternating simulation relation asrequired. 2The following example illustrates that protocol compatibility is indeed manda-tory for the validity of Thm. 4.5.Example 4.6 Fig. 6 shows two connected components C and D which are specifiedby the protocols FC and FD resp. We assume that the state predicate ϕ is not32Bauer, Hennicker, Janischequivalent to true. Then FC and FD are obviously not compatible because thelabel !P.a in FC has the (implicit) precondition true. Moreover, extracts of twocorrect implementations MC ∈ JFCK and MD ∈ JFDK are given which show therelevant transitions for this example. In the graphical presentation of MD we use thefollowing “relaxed” notations: The indicated initial state denotes a set of reachablestates which contains the concrete initial state which we assume does not satisfy ϕ;the transition labelled with {ϕ}?Q.a stands for a set of transitions {(q, ?Q.(a, ρ), q′) |δ(q); ρ ϕ} and, similarly, the transition labelled with {¬ϕ}?Q.a stands for a set oftransitions. The implementation model MD is correct since for any call of a on portQ which meets MD in a data state satisfying ϕ it shows the specified behaviour,otherwise it may show arbitrary behaviour; in our case, MD sends out b on theopen port R. In the model composition MC ⊗K MD, the message b will indeed besent out but this is not an admissible action according to the protocol compositionFC K FD. Thus the theorem does not hold without the assumption of compatibleprotocols.!P.a!P.(a, ρ)PKQ RC DFCMC{¬ϕ}?Q.(a, ρ){ϕ}?Q.(a, ρ)[ϕ]?Q.a!R.(b, ρ′)FDMDFigure 6. Incompatible protocols.Theorem 4.5 is strongly related to the compositionality result of de Alfaro andHenzinger which was formulated for refinements of interface automata; cf. [4]. Asalready mentioned before a crucial difference in our approach is that, caused by thetreatment of data states, we use two different formalisms for specification and forimplementation: finite behaviour protocols and implementation models (with possi-bly infinitely many states). On the specification level we have required compatibilityof protocols while on the implementation level this requirement is trivially satisfiedsince implementation models are input-enabled. This is also the reason why it wasnot necessary to restrict the parallel composition operator to compatible states asdone in [4].5 Concluding RemarksWe have proposed a formalism for specification and implementation of componentand assembly behaviour which integrates the aspects of control flow and evolvingdata states. A simpler form of the current approach has been presented in [2]where components and assemblies were not considered and where a program canonly play one role, either being a user or being the provider of a set of operations.So two different correctness notions were considered in [2], user correctness andimplementation correctness, and no alternating simulation was used. Moreover,33Bauer, Hennicker, Janischwe have focused on a sequential approach in [2] where the correctness notion forimplementations allows to utilise postconditions to infer properties of the connectedcomponent’s data states. If, for instance, in two subsequent operation calls thepostcondition of the first operation implies the precondition of the second one, theinvocation of the latter would be safe in a sequential system even without queryingthe data state again. Obviously, this would, in general, not work for systems ofconcurrently running components as considered here, because there might be someinterfering operation executions (invoked on different ports) in between possiblychanging the component’s data state in an unexpected way. There are essentiallythree ways out of this problem:• Blocking of operation execution until the precondition is satisfied (which is sug-gested in [10] for asynchronous communication but which requires possibly costlydeadlock and liveness analysis).• Querying the data state of the target component to check the precondition beforean operation is called; in this case the query and the operation execution mustbe combined to an atomic action (which is the model supported here at the costof flexibility and performance).• Architectural constraints or protocol constraints on access to shared observers(which is still an issue for further investigation).There are several directions in which the current approach can be further de-veloped. First, it is straightforward to integrate state invariants for components.It should also not be difficult to take into account hierarchically structured compo-nents as considered in [7]. A real challenge will be to study to what extent the ideaspresented here can be transferred to asynchronously communicating componentswhich use FIFO buffers for transmitting messages.Acknowledgment. We would like to thank Moritz Hammer for careful readingof a draft of this paper and the anonymous reviewers for many valuable hints andsuggestions on the previous, submitted version of this paper. In particular, theircomments have shown that we needed a simplification of the presentation. There-fore we have decided to simplify behaviour protocols and implementation modelssuch that, differently to the pure form of behaviour protocols in [11], the events ofemitting an operation invocation and getting the corresponding response are notdistinguished anymore; symmetrically, also the events of receiving an operation in-vocation and sending the response are not distinguished here. As a consequence,the current formalisation assumes that operation executions are atomic. The moregeneral case would allow for an arbitrary interleaving of operation executions; butthen to get the compositionality theorem one needs to impose appropriate restric-tions to ensure that the change of data states is consistent to the single views ofeach user of a component.References[1] T. Barros, R. Boulifa, and E. Madelaine. Parameterized models for distributed java objects. In Davidde Frutos-Escrig and Manuel Nu´n˜ez, editors, Formal Techniques for Networked and Distributed Systems(FORTE 2004), 24th IFIP WG 6.1 International Conference, volume 3235 of Lect. Notes Comp. Sci.,pages 43–60. Springer, 2004.34Bauer, Hennicker, Janisch[2] S. S. Bauer and R. Hennicker. Views on behaviour protocols and their semantic foundation. InA. Kurz and A. Tarlecki, editors, Proc. 3rd Conference on Algebra and Coalgebra in Computer Science(CALCO’09), to appear 2009.[3] L. de Alfaro and T. A. Henzinger. Interface Automata. In Proceedings of the Ninth Annual Symposiumon Foundations of Software Engineering, pages 109–120. ACM Press, 2001.[4] L. de Alfaro and T. A. Henzinger. Interface-based Design. In Manfred Broy, Johannes Gru¨nbauer,David Harel, and C. A. R. Hoare, editors, Engineering Theories of Software-intensive Systems, volume195 of NATO Science Series: Mathematics, Physics, and Chemistry, pages 83–104. Springer, 2005.[5] F. Fernandes and J.-C. Royer. The STSLib project: Towards a formal component model based on STS.Electr. Notes Theor. Comput. Sci., 215:131–149, 2008.[6] C. Fischer. CSP-OZ: a combination of Object-Z and CSP. In H. Bowman and J. Derrick, editors, Proc.2nd IFIP Workshop on Formal Methods for Open Object-Based Distributed Systems (FMOODS), pages423–438, Canterbury, UK, 1997. Chapman and Hall, London.[7] R. Hennicker, S. Janisch, and A. Knapp. On the Observable Behaviour of Composite Components.In Carlos Canal and Corina Pasareanu, editors, Proc. 5th Int. Wsh. Formal Aspects of ComponentSoftware (FACS’08), to appear 2009.[8] Z. Liu, J. He, and X. Li. rCOS: Refinement of Component and Object Systems. In Frank S.de Boer, Marcello M. Bonsangue, Susanne Graf, and Willem P. de Roever, editors, Formal Methods forComponents and Objects, Third International Symposium (FMCO 2004), volume 3657 of Lect. NotesComp. Sci., pages 183–221. Springer, 2004.[9] B. Meyer. Object-Oriented Software Construction. Prentice–Hall, Upper Saddle River, New Jersey,2nd edition, 1997.[10] P. Nienaltowski, B. Meyer, and J. S. Ostroff. Contracts for concurrency. Form. Asp. Comput.,21(4):305–318, 2009.[11] F. Plasil and S. Visnovsky. Behavior protocols for software components. IEEE Trans. Software Eng.,28(11):1056–1076, 2002.[12] A. Rausch, R. Reussner, R. Mirandola, and F. Plasil, editors. The Common Component ModelingExample: Comparing Software Component Models, volume 5153 of Lect. Notes Comp. Sci. Springer,2008.[13] H. Wehrheim. Behavioural Subtyping in Object-Oriented Specification Formalisms. Habilitation thesis,Universita¨t Oldenburg, 2002.3536FACS 2009A Boolean algebra of contracts forassume-guarantee reasoningYann Glouche1 Paul Le Guernic Jean-Pierre TalpinThierry GautierINRIA, Unite´ de Recherche Rennes-Bretagne-AtlantiqueCampus de Beaulieu, 35042 Rennes Cedex, FranceAbstractContract-based design is an expressive paradigm for a modular and compositional specification of programs.It is in turn becoming a fundamental concept in mainstream industrial computer-aided design tools forembedded system design. In this paper, we elaborate new foundations for contract-based embedded systemdesign by proposing a general-purpose algebra of assume/guarantee contracts based on two simple concepts:first, the assumption or guarantee of a component is defined as a filter and, second, filters enjoy the structureof a Boolean algebra. This yields a structure of contracts that is a Heyting algebra.1 IntroductionCommon methodological guidelines for attacking the design of large embedded ar-chitectures advise the validation of specifications as early as possible and an iterativevalidation of each refinement or modification made to the initial specification, untilthe implementation of the system is finalized. Additionally, cooperative component-based development requires to use and to assemble components, which have beendeveloped by different suppliers, in a safe and consistent way [10,15]. These com-ponents have to be provided with their conditions of use and guarantees that theyhave been validated when these conditions are satisfied. This represents a notionof contract. Contracts are now often required as a useful mechanism for valida-tion in robust software design. Design by Contract, as advocated in [26], is beingmade available for usual languages like C++ or Java. Assertion-based contracts ex-press program invariants, pre- and post-conditions, as Boolean type expressions thathave to be true for the contract being validated. We adopt a different paradigmof contract to define a component-based validation technique in the context of asynchronous modeling framework. In our model, a component is represented byan abstract view of its behaviors. It has a finite set of input/output variables to1 Partially funded by the EADS Foundation.This paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs37Y. Glouche, P. Le Guernic, J-P. Talpin, T. Gautiercooperate with its environment. Behaviors are viewed as multi-set traces on thevariables of the component. The abstract model of a component is thus a process,defined as a set of such behaviors.A contract is a pair (assumptions, guarantees). Assumptions describe propertiesexpected by a component to be satisfied by the context (the environment) in whichthis component is used; on the opposite guarantees describe properties that aresatisfied by the component itself when the context satisfies the assumptions. Sucha contract may be documentary; however, when a suitable formal model exists,contracts can be subject to some formal verification tool. We want to providedesigners with such a formal model allowing “simple” but powerful and efficientcomputation on contracts. Thus, we define a novel algebraic framework to enableformal reasoning on contracts. It is based on two simple concepts.First, the assumptions and guarantees of a component are defined as process-filters: assumptions filter the processes (sets of behaviors) a component may acceptand guarantees filter the processes a component provides. A process-filter is theset of processes, whatever their input and output variables are, that are compatiblewith some property (or constraint), expressed on the variables of the component.Second and foremost, we define a Boolean algebra to manipulate process-filters.This yields an algebraically rich structure which allows us to reason on contracts(to abstract, refine, combine and normalize them). This algebraic model is basedon a minimalist model of execution traces, allowing one to adapt it easily to aparticular design framework.A characteristic of this model is that it allows one to precisely handle the vari-ables of components and their possible behaviors. This is a key point. Indeed,assumptions and guarantees are expressed, as usual, by properties constraining orrelating the behaviors of some variables. What has to be considered very carefullyis thus the “compatibility” of such constraints with the possible behaviors of othervariables. This is the reason why we introduce partial order relations on processesand on process-filters. Moreover, having a Boolean algebra on process-filters allowsone to formally, unambiguously and finitely express complementation within thealgebra. This is, in turn, a real advantage compared to related formalisms andmodels.PlanThe article is organized as follows. Section 2 introduces a suitably general alge-bra of processes which borrows its notations and concepts from domain theory [1].A contract (A,G) is viewed as a pair of logical devices filtering processes: the as-sumption A filters processes to select (accept or conversely reject) those that areasserted (accepted or conversely rejected) by the guarantee G. Process-filters aredefined in Section 3 and contracts in Section 4. Section 5 discusses application ofour model to the synchronous Signal language. Related works are further discussedin Section 6. Section 7 concludes the presentation. Detailed proofs of all propertiespresented in this article are available in a technical report [12].2 An algebra of processesWe start with the definition of a suitable algebra for behaviors and processes. Usu-ally, a behavior describes the trace of a discrete process (a Mazurkiewicz trace [24] or38Y. Glouche, P. Le Guernic, J-P. Talpin, T. Gautiera tuple of signals in Lee’s tagged signal model [18]). We deliberately choose a moreabstract definition in order to encompass not only sequences of Boolean, integer,real variables but also behaviors of more complex systems such as hybrid systemsor, on the contrary, simpler “behaviors” associating scalar values with variables, torepresent execution cost, memory size, etc. In this paper we focus the presentationon usual process behaviors.Definition 2.1 [Behavior] Let V be an infinite, countable set of variables, and Da set of values; for Y, a finite set of variables included in V (written Y ⊂ V), Ynonempty, a Y-behavior is a function b : Y → D.The set of Y-behaviors is denoted by BY =∆ Y → D. Definition 2.1 is extendedto the empty variable domain: B∅ =∆ ∅ (there is no behavior associated with theempty set of variables). For Y, a finite set of variables included in V, Y nonempty,c a Y-behavior, X a (possibly empty) subset of Y, c|X is the restriction of c on X,c|X =∆ {(x,c(x))|x ∈ X}, c|∅ =∆ ∅; then c|Y = c.In Figure 1, the x, y-behaviors b1 and b2 are functions from the variables x, y tofunctions that denote signals. Behavior b1 is a discrete sampling mapping a domainof time represented by natural numbers to values. Behavior b2 associates x, y tocontinuous functions of time.Figure 1. Examples of behaviors.We define a process as a set of behaviors on a given set of variables.Definition 2.2 [Process] For X, a finite set of variables (X ⊂ V), an X-process pis a nonempty set of X-behaviors.Thus, since B∅ = ∅, there is a unique ∅-process, designated by Ω =∆ {∅}; Ω hasthe empty behavior as unique behavior. The empty process is denoted by f =∆ ∅.Since Ω does not have any variable, it has no effect when composed (intersected)with other processes. It can be seen as the universal process, for constraint conjunc-tion, in contrast with f, the empty set of behaviors, the use of which in constraintconjunction always results in the empty set. f can be seen as the null process.For X, a finite set of variables (X ⊂ V), we denote by PX =∆ P(BX) \ {f} theset of X-processes (P∅ = {Ω}). P =∆ ∪(X ⊂ V) PX denotes the set of all processes.The domain of behaviors in an X-process p is denoted by var(p) =∆ X.A process is a nonempty set of behaviors. Then we extend P to P? =∆ P ∪ {f}and ∀X ⊂ V, PX to P?X =∆ PX ∪ {f}. Moreover, we extend the definition of var(p)to var(f) =∆ V.The following operators will be used to define filters and contracts: the comple-mentary of a process p in PX is a process in P?X; the restriction of a process p inPX to Y ⊆ X ⊂ V is the abstraction (projection) of p to Y; finally, the extensionof p in PX to Y ⊂ V, Y finite, is the process on Y that has the same constraints asp.39Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierDefinition 2.3 [Complementary, restriction and extension] For X, a finite set ofvariables (X ⊂ V), the complementary p˜ of a process p ∈ PX is defined by p˜ =∆(BX \ p). Also, B˜X = f. When X, Y are finite sets of variables such that X ⊆Y ⊂ V, we define by q|X =∆ {c|X|c ∈ q} the restriction q|X ∈ PX of q ∈ PY and byp|Y =∆ {c ∈ BY|c|X ∈ p} the extension p|Y ∈ PY of p ∈ PX. Hence, we have q|∅ =Ω, q|var(q) = q, Ω|Y = BY and p|var(p) = p.Figure 2. Complementary, restriction and extension of a process.The complementary p˜ of a process p defined on the variables x and y, Figure 2,consists of all behaviors defined on x, y not belonging to p. The restriction p|{x, y}of a process p defined on x, y, z, consists of its projection on the restricted domain;right, the extension p|{x, y, z} of a process p defined on x, y is the largest processdefined on x, y, z whose restriction on x, y is equal to p.The set P?X, equipped with union, intersection and complementary, extendedwith f˜ = BX, is a Boolean algebra with supremum P?X and infimum f. Thedefinition of restriction is extended to f, the null process, with f|X =∆ {c|X|c ∈ ∅}= f. Since V is the set of all variables, the definition of extension is simply extendedto f, with f|V =∆ f. The process extension operator induces a partial order ,such that p q if q is an extension of p to variables of q; the relation , used todefine filters, is studied below.Definition 2.4 [Process extension relation] The process extension relation isdefined by: (∀ p ∈ P) ( ∀ q ∈ P) (p q) =∆ ((var(p) ⊆ var(q)) ∧ (p|var(q) = q))Thus, if (p q), q is defined on more variables than p; on the variables of p, qhas the same constraints as p; its other variables are free. This relation extends toP? with (f f).Property 2.5 (P?,) is a poset.Checking transitivity, antisymmetry and reflexivity is immediate.In this poset, the upper set of a process p, called ex-tension upper set, is the set of all its extensions; itis denoted by p↑ =∆ {q ∈ P|p q}. The extensionupper set is illustrated in Figure 3.To study properties of extension upper sets, we char-acterize the set of variables that are constrained by agiven process: we write that a process q ∈ P controlssome variable y, if y belongs to var(q) and q is notequal to the extension on var(q) of its projection on(var(q)\{y}). Figure 3. Extension upper set.40Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierThis is illustrated in Fig-ure 4, there is some be-havior b in q that hasthe same restriction on(var(q)\{y}) as some be-havior c in Bvar(q) such thatc does not belong to q;thus q is strictly included in(q|(var(q)\{y}))|var(q) . Figure 4. Controlled (left) and non-controlled (right) variable y in aprocess q.Formally, a process q ∈ P controls a variable y, written (q y), iff (y ∈ var(q))and q 6= ((q|(var(q)\{y}))|var(q)). A process q ∈ P controls a variable set X, written(qX), iff (∀ x ∈ X) (q x).Moreover, is extended to P? with f V. Note that if a process p controls X,this does not imply that, for all x ∈ X, y ∈ X, x 6= y, (p|(X\{x})) controls y: it maybe the case that x is constrained in p by y; then if x is “removed” (by the projectionon other controlled variables), y may be free in this projection. We define a reducedprocess (the key concept to define filters) as being a process that controls all of itsvariables.Definition 2.6 [Reduced process] A process p ∈ P? is reduced iff p var(p).For instance, Ω is reduced. On the contrary, BX is never reduced when X is notempty. Reduced processes are minimal in (P,). We denote by Oq, called reductionof q, the (minimal) process such thatOq q (p is reduced iff Op = p). For all X, wehaveOBX = Ω.Figure 5 illustrates the reductionOq of a processq and a process p, in the extension upper setOq↑. Assuming that var(q) = ({x1...n} ∪ {y1...m})and that q controls the variables {x1...n}, we havevar(Oq) = {x1...n}; the process p is such that p ∈ Oq↑with var(p) ⊆ ({x1...n} ∪ {y1...m} ∪ {z1...l}); it con-trols the variables {x1...n}, and {y1...m} ∪ {z1...l} isa set of free variables, such thatOq =Op.Figure 5. Reduction of a process.Property 2.7 The complementary p˜ of a nonempty process p strictly included inBvar(p) is reduced iff p is reduced; then p˜ and p control the same set of variablesvar(p).From the above, the extension upper setOp↑ of the reduction of p is a (principal)filtered set [1]: it is nonempty and each pair of elements has a lower bound. ThenOp↑ is composed of all the sets of behaviors, defined on variable sets that includethe variables controlled by p, as maximal processes (for union of sets of behaviors)that have exactly the same constraints as p (variables that are not controlled by pare also not controlled in the processes ofOp↑). We also observe that var(Oq) is thegreatest subset of variables such that q var(Oq). For a process q ∈ P?, we extendthe definition of var() to the extension upper set of its reduction by var(Oq↑) =∆var(Oq). Notice that f↑ = {f}.41Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierWe define the inclusion lower set of a set of processes to capture all the subsetsof behaviors of these processes. Let R ⊆ P?, R↓⊆ is the inclusion lower set of R for⊆ defined by R↓⊆ =∆ {p ∈ P?|( ∃ q ∈ R) (p ⊆ q)}. Hence, none of the processesbut f belongs to the inclusion lower set of the extension upper set of f; on thecontrary, all processes belong to the inclusion lower set of the extension upper setof Ω: [Of↑]↓⊆ = {f} and [OΩ↑]↓⊆ = P?.3 An algebra of filtersIn this section, we define a process-filter by the set of processes that satisfy a givenproperty. We propose an order relation (v) on the set of process-filters Φ. Weestablish that (Φ,v) is a Boolean algebra. A process-filter R is a subset of P? thatfilters processes. It contains all the processes that are “equivalent” with respect tosome constraint or property, so that all processes in R are accepted or all of thembut f are rejected. A process-filter is built from a unique process generator byextending it to larger sets of variables and then by including subprocesses of these“maximal allowed behavior sets”.Definition 3.1 [Process-filter] A set of processes R is a process-filter iff ( ∃ r ∈ P?)((r =Or) ∧ (R = [r↑]↓⊆)). The process r is a generator of R (R is generated by r).The process-filter generated by the reduction of a process p is denoted by p̂=∆ [Op↑]↓⊆. The generator of a process-filter R is unique, we refer to it asOR. Ωgenerates the set of all processes (including f) and f belongs to all filters. Formally,( ∀ p,r,s ∈ P?), we have:(p ∈ r̂) =⇒ (var(Or) ⊆ var(p)) r̂ = ŝ⇐⇒ Or = Os Ω ∈ r̂ ⇐⇒ r̂ = P?Figure 6 illustrates how a process-filter is generated from a process p (depicted bythe bold line) in two successive operations. The first operation consists of buildingthe extension upper set of the process:it takes all the processes that are compatible withp and that are defined on a larger set of variables.The second operation proceeds using the inclusionlower set of this set of processes: it takes all theprocesses that are defined by subsets of behaviorsfrom processes in the extension upper set (in otherwords, those processes that remain compatible whenadding constraints, since adding constraints removesbehaviors).Figure 6. Example of process-filter.We denote by Φ the set of process-filters. We call strict process-filters the process-filters that are neither P? nor {f}. The filtered variable set of a process-filter R isvar(R) defined by var(R) =∆ var(OR).We define an order relation on process-filters, which we call relaxation, and writeR v S to mean that R is less wide than S.42Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierDefinition 3.2 [Process-filter relaxation] For R and S, two process-filters, let Z= var(R) ∪ var(S). The relation S relaxes R, written R v S, is defined by:{f} v S (R v {f})⇐⇒ {f} = R (R v S⇐⇒OR|Z ⊆OS|Z)The relaxation relation defines the structure of process-filters, which is shownto be a lattice.Lemma 3.3 (Φ,v) is a lattice of supremum P? and infimum {f}. Let R and S betwo process-filters, V = var(R) ∪ var(S), RV =OR|Vand SV =OS|V. ConjunctionR u S, disjunction R unionsq S and complementary R˜ are defined by:{f} u R =∆ {f} R u S =∆ [O(RV ∩ SV)↑]↓⊆ R˜ =∆ [O˜R↑]↓⊆{f} unionsq R =∆ R R unionsq S =∆ [O(RV ∪ SV)↑]↓⊆ P˜? =∆ {f}{˜f} =∆ P?If R 6= {f} then R˜ 6= {f} andO˜R = (Bvar(R) \OR) is reduced and var(R) = var(R˜).Let us comment the definitions of these operators. Conjunction of two strictprocess-filters R and S, for instance, is obtained by first building the extensionof the generatorsOR andOS on the union of the sets of their controlled variables;then the intersection of these processes, which is also a process (set of behaviors)is considered; since this operation may result in some variables becoming free (notcontrolled), the reduction of this process is taken; and finally, the result is theprocess-filter generated by this reduction. The same mechanism, with union, isused to define disjunction. And the complementary of a strict process-filter R isthe process-filter generated by the complementary of its generatorOR.The process-filter conjunction RuS of two strict process-filters R and S is thegreatest process-filter T = RuS that accepts all processes that are accepted by Rand by S.Example 3.4 Let x, a variable taking values in {0,1,2,3} and u, y, v three variablestaking values in {0,1}; let r ∈ P{u, x, y}, s ∈ P{x, y, v}, two reduced processes definedbyr = {b|b(u) ∈ {0, 1} ∧ b(x) ∈ {0, 1} ∧ b(y) ∈ {0, 1}} ∪ {{(u, 1), (x, 2), (y, 0)}}s = {b|b(x) ∈ {0, 1} ∧ b(y) ∈ {0, 1} ∧ b(v) ∈ {0, 1}} ∪ {{(x, 3), (y, 1), (v, 0)}}We observe that r {u, x, y}; u and y are free in r when x is 0 or 1; v is free whateverthe value of x is in r. We also have s {x, y, v}; y and v are free in s when x is 0 or1; thus u is free whatever the value of x is in s. From the above definitions, we havethat p =∆ r ∩ s = {b|b(u) ∈ {0, 1} ∧ b(x) ∈ {0, 1} ∧ b(y) ∈ {0, 1} ∧ b(v) ∈ {0, 1}}andOp = {b|b(x) ∈ {0, 1}}.The process-filter disjunction RunionsqS of two strict process-filters R and S is thesmallest process-filter T = RunionsqS that accepts all processes that are accepted by Ror by S.Example 3.5 Let x, a variable taking values in {0,1,2,3} and u, y, v three variablestaking values in {0,1}; let r ∈ P{u, x, y}, s ∈ P{x, y, v}, two reduced processes such thatr = {b|b(u) ∈ {0, 1} ∧ b(x) ∈ {0, 1} ∧ b(y) = 0}s = {b|b(x) ∈ {0, 1} ∧ b(y) = 1 ∧ b(v) ∈ {0, 1}}43Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierHence, p =∆ r ∪ s = {b|b(u) ∈ {0, 1} ∧ b(x) ∈ {0, 1} ∧ b(y) ∈ {0, 1} ∧ b(v) ∈ {0, 1}}andOp = {b|b(x) ∈ {0, 1}}.Now we can state a first main result, which is that process-filters form a Booleanalgebra.Theorem 3.6 (Φ,v) is a Boolean algebra with P? as 1, {f} as 0 and the comple-mentary R˜.Variable elimination operators are defined on process-filters.Definition 3.7 [Variable elimination in process-filter] Let x be a variable, R aprocess-filter, and X =∆ var(R). The E-elimination of x in R, noted R|∃x, isthe projection of R on controlled variables other than x. The generator of the U-elimination of x in R (U-elimination of x in R is noted R|∀x) contains the behaviorsofOR restricted on X\{x} for which x is free inOR.R|∃x=∆̂(OR)|X\{x}, x ∈ XR, otherwiseR|∀x =∆˜˜R|∃xNotice that R|∀x v R v R|∃x.Example 3.8 Let R, a process-filter generated by ((x > 0) ⇒ (y > 0)) ∧ ((y >0) ⇒ (z > 0)). Then R|∃x is generated by ((y > 0) ⇒ (z > 0)) and R|∀x isgenerated by ((y > 0) ∧ (z > 0)).4 An algebra of contractsWe define the notion of assume/guarantee contract and propose a refinement rela-tion on contracts.Definition 4.1 [Contract] A contract C = (A,G) is a pair of process-filters. var(C),the variable set of C = (A,G), is defined by var(C) =∆ var(A) ∪ var(G). C =∆Φ×Φ is the set of contracts.Usually, an assumption A is an assertion on the be-havior of the environment (it is typically expressed onthe inputs of a process) and thus defines the set of be-haviors that the process has to take into account. Theguarantee G defines properties that should be guar-anteed by a process running in an environment wherebehaviors satisfy A.Figure 7 depicts a process p satisfying the contract(A,G) (p̂ is the process-filter generated by the reduc-tion of p).Figure 7. A process p satisfyinga contract (A,G).A process p satisfies a contract C = (A,G) if all its behaviors that are acceptedby A (i.e., that are behaviors of some process in A), are also accepted by G; thisis made more precise and formal by the following definition.Definition 4.2 [Satisfaction] Let C = (A,G) a contract; a process p satisfies C,written p C, iff (p̂ u A) v G.Property 4.3 p C ⇐⇒ p̂ v (A˜ unionsq G)44Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierWe define a preorder relation that allows to compare contracts. A contract(A1,G1) is finer than a contract (A2,G2), written (A1,G1) ;(A2,G2), iff all pro-cesses that satisfy the contract (A1,G1) also satisfy the contract (A2,G2).Definition 4.4 [Satisfaction preorder](A1,G1);(A2,G2) iff ( ∀ p ∈ P)((p (A1,G1))=⇒ (p (A2,G2)))The preorder on contracts satisfies the following property:Property 4.5 (A1,G1) ;(A2,G2) iff (A˜1 unionsq G1) v (A˜2 unionsq G2)Definition 4.6 [Refinement of contracts] A contract C1 = (A1,G1) refines a con-tract C2 = (A2,G2), written C1 4 C2, iff (A1,G1) ;(A2,G2), (A2 v A1) and G1v (A1 unionsq G2).Refinement of contracts amounts to relaxing assumptions and reinforcing promisesunder the initial assumptions. The intuitive meaning is that for any p that satisfiesa contract C, if C refines D then p satisfies D. Our relation of refinement formalizessubstitutability.Figure 8. Refinement of contracts.Figure 8 depicts a contract (A1,G1)that refines a contract (A2,G2).Among contracts that can be used torefine an existing contract (A2,G2), wechoose those contracts (A1,G1) that“scan” more processes than (A2,G2)(A2 vA1) and that guarantee less pro-cesses than those of A1unionsqG2. But otherchoices could have been made.By definition of the satisfaction pre-order, we can express the refinement relationin the algebra of process-filters as follows:Property 4.7 (A1,G1)4 (A2,G2) iff A2 vA1, (A2uG1)vG2 and G1 v (A1unionsqG2).The refinement relation (4) defines the poset of contracts, which is shown to bea lattice. In this lattice, the union or disjunction of contracts is defined by theirleast upper bound and the intersection or conjunction of contracts is defined bytheir greatest lower bound.Lemma 4.8 (Composition of contracts) Two contracts C1 = (A1,G1) and C2= (A2,G2) have a greatest lower bound C = (A,G) , written (C1 ⇓ C2), definedby:A = A1unionsqA2 and G = ((A1uA˜2uG1)unionsq(A˜1uA2uG2)unionsq(G1uG2))and a least upper bound D = (B,H), written (C1 ⇑ C2), defined by:A = A1uA2 and G = (A˜1uG1)unionsq(A˜2uG2)unionsq(A1uG2)unionsq(A2uG1)A Heyting algebra H is a bounded lattice such that for all a and b in H thereis a greatest element x of H such that the greatest lower bound of a and x refinesb [6]. For all contracts C1 = (A1,G1), C2 = (A2,G2), there is a greatest elementX = (I,J) of C such that the greatest lower bound of C1 and X refines C2, with:I = (A˜1uA2)unionsq(A1uA2uG1uG˜2) J = G2unionsq(A1uA˜2)unionsq(A1uG˜1)unionsq(A˜2uG˜1)Then our contract algebra is a Heyting algebra. In particular, it is distributive.45Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierTheorem 4.9 (C, 4) is a Heyting algebra with supremum ({f},P?) and infimum(P?,{f}).Let x a variable, C = (A,G) a contract, the elimination of x in C is the contractC\x defined by C\x =∆ (A|∀x,G|∃x).Property 4.10 A contract C refines the elimination of a variable in C: C 4 C\x5 Application to the Signal languageIn the synchronous multiclocked model of Signal [19], a process (noted p), consists ofthe synchronous composition (noted p |q) of equations on signals (noted x = y f z).A signal x consists of an infinite flow of values that is discretely sampled accordingto the pace of its clock. A set of tags t is to denote symbolic periods in timeduring which transitions take place. It samples a signal over a countable series ofcausally related tags. Then the events, signals, behaviors and processes are definedas follows:- an event e is a pair consisting of a tag t and a value v,- a signal s is a function from a chain of tags to a set of values,- a behavior b is a function from a set of names to signals,- a process p ∈ P is a set of behaviors that have the same domain.Synchronous composition p |q consists of the simultaneous solution of the equa-tions in p and q at all times.Definition 5.1 [Synchronous composition of processes] The synchronous compo-sition of two processes p,q ∈ P is defined by: p |q =∆ { b ∪ c | (b, c) ∈ p × q ∧b|var(p) ∩ var(q) = c|var(p) ∩ var(q) }In the context of component-based or contract-based engineering, refinementand substitutability are recognized as being fundamental requirements [9]. Refine-ment allows one to replace a component by a finer version of it. Substitutabilityallows one to implement every contract independently of its context of use. Theseproperties are essential for considering an implementation as a succession of stepsof refinement, until final implementation. As noticed in [27], other aspects might beconsidered in a design methodology. In particular, shared implementation for dif-ferent specifications, multiple viewpoints and conjunctive requirements for a givencomponent.Considering the synchronous compositon of Signal processes and the greatestlower bound as a composition operator for contracts, we have:Property 5.2 Let two processes p,q ∈ P, and contracts C1, C2, C′1, C′2 ∈ C.(1) C1 4 C2 =⇒ ((p C1) =⇒ (p C2)) (4) ((p C1) ∧ (q C2)) =⇒ ((p |q) (C1 ⇓ C2))(2) C1 ;C2 ⇐⇒ ((p C1) =⇒ (p C2)) (5) ((p C1) ∧ (p C2)) ⇐⇒ (p (C1 ⇓ C2))(3) If C′1 4 C1 and C′2 4 C2 then C′1 ⇓ C′2 4 C1 ⇓ C2(1) and (2) relate to refinement and implementation; (3) and (4) allow forsubtitutability in composition; (5) addresses multiple viewpoints.In [13], we develop a module system based on our paradigm of contract for theSignal formalism, and applied it to the specification of a component-based designprocess. This module system, embedding data-flow equations defined in Signalsyntax, has been implemented in OCaml. It produces a proof tree that consists of46Y. Glouche, P. Le Guernic, J-P. Talpin, T. Gautier1/ an elaborated Signal program, that hierarchically renders the structure of thesystem described in the original module expressions, 2/ a static type assignment,that is sound and complete with respect to the module type inference system, 3/a proof obligation consisting of refinement constraints, that are compiled as anobserver or a temporal property in Signal.The property is then tended to Signal’s model-checker, Sigali [21], which allowsto prove or disprove that it is satisfied by the generated program. Satisfaction im-plies that the type assignment and produced Signal program are correct with theinitially intended specification. The generated property may however be used forother purposes. One is to use the controller synthesis services of Sigali [20] to auto-matically generate a Signal program that enforces the property on the generatedprogram. Another, in the case of infinite state system (e.g. on numbers), would beto generate defensive simulation code in order to produce a trace if the property isviolated.We now illustrate the distinctive features of our contract algebra by consideringthe specification of a four-stroke engine and its translation into observers in thesynchronous language Signal.Figure 9. State machine of 4-stroke engine cycle.Figure 9 represents a state ma-chine that denotes the successiveoperation modes of a 4-stroke en-gine: Intake, Compression, Com-bustion and Exhaust. They aredriven by the camshaft whose po-sition is measured in degrees.The angle of the camshaft defines a discrete timing reference, the clock cam, mea-sured in degrees CAM◦, of initial value 0. Transitions in the state machine are trig-gered by measures of the camshaft angle. The variables cam, Intake, Compression,Combustion, Exhaust model the behavior of the engine. We wish to define a con-tract to stipulate that intake always takes place in the first quarter on the camshaftrevolution. To do this, we define the generator of a process-filter for the assumption.It should be a measure of the environmental variable cam. Namely cam should bein the first quarter. Under these assumptions, the state machine should be guar-anteed to be in the intake mode, hence the generator of the process-filter for theguarantee: AIntake=∆(cam mod 360 < 90) GIntake=∆IntakeThe generic structure of processes in contracts finds a direct in-stance and compositional translation into the synchronous multi-clocked model of computation of Signal. Using Signal equations:AIntake = true when(cam mod360 < 90)GIntake = true when intake default falseA subtlety of the Signal language is that the contract not only talks about thevalue, true or false, of the signals, but also about the status of the signal names,present or absent. Hence, the signal AIntake is present and true iff cam is presentand less than 90. Hence, in Signal, the complementary of the assumptions issimply defined by A˜Intake = false when AIntake default true to mean that it istrue iff cam is absent or bigger than 90. Notice that, for a trace of the assumptionsAIntake, the set of possible traces corresponding to A˜Intake is infinite (and dense)since it is not defined on the same clock as AIntake.47Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierAIntake = 1 0 1 0 1 0 1 0 1 and A˜Intake = 0 0 0 0 0 or 0 1 1 1 0 1 1 0 1 1 0 1 0 1 . . .It is also worth noticing that the clock of A˜Intake (its reference in time) need not beexplicitly related to or ordered with AIntake or GIntake: it implicitly and partiallyrelates to the cam clock.Notice that our model of contract is agnostic as to a particular model of com-putation and accepts a generic domain of behaviors. Had we instead consideredexecutable specifications, such as synchronous observers [22], it would have beenmore difficult to compositionally define the complementary of a proposition with-out referring to a global reference of time in the environment (e.g., a clock for thecamshaft), hence abstracting every assumption or guarantee with respect to thatglobal clock. This does not need to be the case in the present example. Besideits Boolean structure, our algebra supports the capability to compositionally refinecontracts (without altering or abstracting individual properties) and accepts bothsynchronous and asynchronous specifications.Figure 10. Model of 4-stroke engine cycle.For instance, consider a more precisemodel of the 4-stroke engine foundin [3](Figure 10). To additionally requirethat, while in the intake mode, the engineshould reach the EC state (Exhaust closes)between 5 and 20 degrees, one will simplycompose (greatest lower bound) the intakecontract with the additional one:AEC = true when(4 < cam mod 360 < 21) GEC = true when EC default falseContracts can be used to express exclusion properties. For instance, when theengine is in the intake mode, one should not start compression.Aexcl=∆OTDC Gexcl=∆¬FBDCIn addition to the above safety properties, contracts can also be used to expressliveness properties. For instance, consider the protocol for starting the engine. Abattery is used to initiate its rotation. When the engine has successfully started,the battery can be turned off. We can specify a contract to guarantee that enginecycles are properly counted. We write cycle′ for the next value of the variable cycle.Acount=∆Exhaust Gcount=∆cycle′ = cycle + 1Another contract is defined to specify that the starter battery (starter) will even-tually be turned off after a few cycles. We write F () for the future property of LTL.Alive=∆(cycle > 0) Glive=∆F (¬starter)6 Related workThe use of contracts has been advocated for a long time in computer science [23,14]and, more recently, has been successfully applied in object-oriented software engi-neering [25]. In object-oriented programming, the basic idea of design-by-contractis to consider the services provided by a class as a contract between the class andits caller. The contract is composed of two parts: requirements made by the classupon its caller and promises made by the class to its caller.In the context of software engineering, the notion of assertion-based contract hasbeen adapted for a wide variety of languages and formalisms but the central notion48Y. Glouche, P. Le Guernic, J-P. Talpin, T. Gautierof time and/or trace needed for reactive system design is not always taken intoaccount. For instance, extensions of OCL with linear or branching-time temporallogics have been proposed in [28,11], focusing on the expressivity of the proposedconstraint language (the way constraints may talk about the internals of classes andobjects), and considering a fixed “sequence of states”. This is a serious limitationfor concurrent system design, as this sequence becomes an interleaving of that ofindividual objects.In the theory of interface automata [2], the notion of interface offers benefitssimilar to our notion of contracts and for the purpose of checking interface com-patibility between reactive modules. In that context, it is irrelevant to separate theassumptions from guarantees and only one contract needs to be and is associatedwith a module. Separation and multiple views become of importance in a moregeneral-purpose software engineering context. Separation allows more flexibilityin finding (contra-variant) compatibility relations between components. Multipleviews allows better isolation between modules and hence favor compositionality. Inour contract algebra as in interface automata, a contract can be expressed withonly one filter. To this end, a filtering equivalence relation [12] (that defines theequivalence class of contracts that accept the same set of processes) may be usedto express a contract with only one guarantee filter and with its hypothesis filteraccepting all the processes (or, conversely, with only one hypothesis filter and aguarantee filter that accepts no process).In [7], a system of assume-guarantee contracts with similar aims of genericity isproposed. By contrast to our domain-theoretical approach, the EC Speeds projectconsiders an automata-based approach, which is indeed dual but makes notions suchas the complementary of a contract more difficult to express from within the model.The proposed approach also leaves the role of variables in contracts unspecified, atthe cost of some algebraic relations such as inclusion.In [16], the authors show that the framework of interface automata may beembedded into that of modal I/O automata. [27] further develops this approachby considering modal specifications. This consists of labelling transitions that maybe fired and other that must. Modal specifications are equipped with a parallelcomposition operator and refinement order which induces a greatest lower bound.The GLB allows addressing multiple-viewpoint and conjunctive requirements. Withthe experience of [7], the authors notice the difficulty in handling interfaces havingdifferent alphabets. Thanks to modalities, they propose different alphabet equal-izations depending on whether parallel composition or conjunction is considered.Then they consider contracts as residuations G/A (the residuation is the adjoint ofparallel composition), where assumptions A and guarantees G are both specified asmodal specifications. The objectives of this approach are quite close to ours. Ourmodel deals carefully alphabet equalization. Moreover, using synchronous compo-sition for processes and greatest lower bound for process-filters and for contracts,our model captures both substitutability and multiple-viewpoint.In [22], a notion of synchronous contracts is proposed for the programminglanguage Lustre. In this approach, contracts are executable specifications (syn-chronous observers) timely paced by a clock (the clock of the environment). Thisyields an approach which is satisfactory to verify safety properties of individual49Y. Glouche, P. Le Guernic, J-P. Talpin, T. Gautiermodules (which have a clock) but can hardly scale to the modeling of globallyasynchronous architectures (which have multiple clocks).In [8], a compositonal notion of refinement is proposed for a simpler stream-processing data-flow language. By contrast to our algebra, which encompasses theexpression of temporal properties, it is limited to reasoning on input-output typesand input-output causality graph.The system JASS [5] is somewhat closer to our motivations and solution. Itproposes a notion of trace, and a language to talk about traces. However, it seemsthat it evolves mainly towards debugging and defensive code generation. For em-bedded systems, we prefer to use contracts for validating composition and hope touse formal tools once we have a dedicated language for contracts. Like in JML [17],the notion of agent with inputs/outputs does not exist in JASS, the language isbased on class invariants, and pre/post-conditions associated with methods.Our main contribution is to define a complete domain theoretical framework forassume-guarantee reasoning. Starting from a domain-theoretical characterization ofbehaviors and processes, we build a Boolean algebra of process-filters and a Heytingalgebra of contracts. This yields a rich structure which is: 1/ generic, in the way itcan be implemented or instantiated to specific models of computation; 2/ flexible,in the way it can help structuring and normalizing expressions; 3/ complete, in thesense that all combinations of propositions can be expressed within the model.Finally, a temporal logic that is consistent with our model, such as for instancethe ATL (Alternating-time Temporal Logic [4]) can directly be used to expressassumptions about the context of a process and guarantees provided by that process.7 ConclusionStarting from the choice of an abstract characterization of behaviors as functionsfrom variables to a domain of values (Booleans, integers, series, sets of taggedvalues, continuous functions), we introduced the notion of process-filters to formallycharacterize the logical device that filters behaviors from process much like theassumption and guarantee of a contract do. In our model, a process p fulfils itsrequirements (or satisfies) (A,G) if either it is rejected by A (it is then out of thescope of the contract (A,G)), or it is accepted by G.Our main results are that the structure of process-filters is a Boolean algebraand that the structure of contracts is a Heyting algebra, respectively. This richstructure allows for reasoning on contracts with great flexibility to abstract, refineand combine them. Moreover, contracts are not limited to expressing safety prop-erties, as is the case in most related frameworks, but encompass the expression ofliveness properties. This is all again due to the central notion of process-filter.In the aim of assessing the generality and scalability of our approach, we aredesigning a module system based on the paradigm of contract for Signal and ap-plying it to the specification of a component-based design process. The paradigmwe are putting forward is to regard a contract as the behavioral type of a module orcomponent and to use it for the elaboration of the functional architecture of a sys-tem together with a proof obligation that validates the correctness of assumptionsand guarantees made while constructing that architecture.50Y. Glouche, P. Le Guernic, J-P. Talpin, T. GautierReferences[1] Abramsky S. and Jung A. Domain theory. In Handbook of logic in computer science (vol. 3): semanticstructures, pages 1–168. Oxford University Press, 1997.[2] Alfaro L. and Henzinger T. A. Interface automata. In ESEC / SIGSOFT FSE, pp. 109–120, 2001.[3] Andre´ C., Mallet F., and Peraldi-Frati M.-A. A multi-form time approach to real-time system modeling.Research Report RR 2007-14-FR, I3S, 2007.[4] Alur, R., Henzinger, T., and Kupferman, O. Alternating-time Temporal Logic. In Journal of the ACM,v. 49, ACM Press, 2002.[5] Bartetzko D., Fischer C., Mo¨ller M., and Wehrheim H. Jass - Java with assertions. In Havelund, K.,Rosu, G. eds : Runtime Verification, Volume 55 of ENTCS(1):91–108, 2001.[6] Bell John L. Boolean Algebras and Distributive Lattices Treated Constructively, Math. Logic Quarterly45, 1999.[7] Benveniste A., Caillaud B., and Passerone R. A generic model of contracts for embedded systems. InResearch report N◦6214, INRIA-IRISA, S4 Team, 2007.[8] Broy, M. Compositional refinement of interactive systems. Journal of the ACM, v. 44. ACM Press,1997.[9] Doyen L., Henzinger T. A., Jobstmann B., and Petrov T., Interface theories with component reuse, InProceedings of the 8th ACM & IEEE International conference on Embedded software, EMSOFT’08,2008, pp. 79-88.[10] Edwards S., Lavagno L., Lee E.A., and Sangiovanni-Vincentelli A. Design of Embedded Systems:Formal Models, Validation, and Synthesis. In Proceedings of the IEEE, 85(3), pages 366–390, 1997.[11] Flake S. and Mueller W. An ocl extension for realtime constraints. In Lecture Notes in ComputerScience 2263, pp. 150–171, 2001.[12] Glouche Y., Le Guernic P., Talpin J.-P., and Gautier T. A boolean algebra of contracts for logicalassume-guarantee reasoning. Research Report RR 6570, INRIA, 2008.[13] Glouche Y., Talpin J.-P., Le Guernic P., and Gautier T. A module language for typing by contracts. InNasa Formal Methods Symposium, Springer, 2009.[14] Hoare C.A.R. An axiomatic basis for computer programming. In Communications of the ACM, pp.576–583, 1969.[15] Kopetz H. Component-Based Design of Large Distributed Real-Time Systems. In Control EngineeringPractice, 6(1), pages 53–60, 1997.[16] Larsen K.G., Nyman U., and Wasowski A. Modal I/O automata for interface and product line theories.In Programmming Languages and Systems, 16th European Symposium on Programming, ESOP’07, ser.Lecture Notes in Computer Science, vol. 4421. Springer, 2007, pp. 64-79.[17] Leavens G. T., Baker A. L., and Ruby C. JML: A notation for detailed design. In Kilov H., Rumpe B.,and Simmonds I., editors, Behavioral Specifications of Businesses and Systems, pp. 175–188. KluwerAcademic Publishers, 1999.[18] Lee E.A., Sangionanni-Vincentelli A., A framework for comparing models of computation. In IEEEtransaction on computer-aided design, v. 17, 1998.[19] Le Guernic P., Talpin J.-P., and Le Lann J.-C. Polychrony for system design. Journal for Circuits,Systems and Computers, Special Issue on Application Specific Hardware Design, 2003.[20] Marchand, H., Bournai, P., Le Borgne, M., Le Guernic, P. Synthesis of Discrete-Event Controllers basedon the Signal Environment, Discrete Event Dynamic System: Theory and Applications, v. 10(4), 2000.[21] Marchand, H., Rutten, E., Le Borgne, M., Samaan, M. Formal Verification of programs specified withSignal: Application to a Power Transformer Station Controller. Science of Computer Programming, v.41(1). Elsevier, 2001.[22] Maraninchi F. and Morel L. Logical-time contracts for reactive embedded components. In In 30thEUROMICRO Conference on Component-Based Software Engineering Track, ECBSE’04, Rennes,France, 2004.[23] Martin A. and Lamport L. Composing specifications. In ACM Trans. Program. Lang. Syst. 15, pp.73–132, 1993.[24] Mazurkiewicz A. Basic notions of trace theory. In Lecture Notes In Computer Science, v. 354, pp. 285- 363, 1989.[25] Meyer B. Object-Oriented Software Construction, Second Edition. ISE Inc., Santa Barbara, 1997.[26] Mitchell R. and McKim J. Design by Contract, by Example, Addison-Wesley, 2002.[27] Raclet J.-B., Badouel E., Benveniste A., Caillaud B., Passerone R. Why are modalites good for InterfaceTheories? In 9th International Conference on Application of Concurrency, 2009.[28] Ziemann P. and Gogolla M. An extension of ocl with temporal logic. In Critical SystemsDevelopment with UML-Proceedings of the UML’02 workshop, Technische Universita¨t Mu¨nchen,Institut fu¨r Informatik, 2002.5152FACS 2009Automated formalisation for verification ofdiagrammatic modelsJames R. Williams 1,2Department of Computer ScienceUniversity of York, York, UKFiona A. C. Polack 3Department of Computer ScienceUniversity of York, York, UKAbstractSoftware engineering uses models to design and analyse systems. The current state-of-the-art, various formsof model-driven development, uses diagrams with defined abstract syntax but relatively-lose translationalapproaches to semantics, which makes it difficult to perform rigorous analysis and verification of models.Here, we present work-in-progress on tool support for formal verification of diagrammatic models. Thework builds on Ama´lio’s rigorous template-based approach to formalisation, which formally expresses theintended semantics of both the diagram notation and modelled system, along with standard correctnessconjectures and, in many cases, proof of these conjectures.Keywords: formal verification, model-driven development, tool-support1 IntroductionIn practical software engineering, diagrammatic approaches are widely used forsketching, specifying and designing systems. There are challenges in applying formalanalysis to these approaches, either because the semantics is inadequately defined,or because the level of detail of the semantics does not admit interesting or use-ful formal analysis. Conversely, the formal notations used in verification of criticalsystems and in academia are considered inaccessible by many practical engineers[21,12,27]. If it were possible to provide access to formal analysis without great1 We would like to thank: Dimitrios Kolovos, without whose help and Epsilon tool-suite we could nothave produced this tool; Nuno Ama´lio, Faculte´ des Sciences, de la Technologie et de la Communication,University of Luxembourg, whose doctoral work on GeFoRME and FTL form the basis of the tool; LeoFreitas and Ian Toyn, for advice on CZT and CADiZ; Richard Paige for comments on earlier drafts; andthe UK National Research and Training Initiative: Large-Scale Complex IT Systems for part sponsorship.2 Email: james@jamesrobertwilliams.co.uk3 Email: fiona@cs.york.ac.ukThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs53Williams and Polackcost, the rigour and reliability of diagrammatic models could be significantly en-hanced. For many years, people have sought to combine formal and diagrammaticapproaches so that formal type-checking and proof of properties can be used toexplore the correctness and internal consistency of diagrams. However, few inte-grations have found favour, either because formalisation does not meet engineeringneeds, or because engineers are exposed to the formalisation and formal model.In an attempt to bring formalisms into practical engineering, Ama´lio [3] pro-poses a generative framework for rigorous model engineering (GeFoRME) that ap-plies template-based translation to diagrammatic models. Formal templates cap-ture the intended semantics of diagram concepts as well as the modelled system. Awell-founded template language (the formal template language, FTL [3,8]) makesit possible to generate not only formal models but also standard consistency con-jectures and, in many cases, their proofs. Ama´lio demonstrates an instance ofGeFoRME called UML+Z, comprising a library of templates that capture the ob-ject semantics of UML. Instantiating the templates with details from UML diagramsresults in a Z model that conforms to Ama´lio’s object-oriented (OO) Z structuring,ZOO [4,7,3,10]. UML+Z has been used on small case studies [3,9] of conventionalobject-oriented models including UML class and state diagrams and Catalysis [19]snapshots. It has also been used in an attempt to formalise part of the meta-objectfacility [2] and on a model of autonomous objects [10]. The GeFoRME approachprovides ease of construction, strong semantic support, and traceability betweenthe formal and diagrammatic models. If templates adequately capture the seman-tics of source-model concepts, and the source model is syntactically correct, thenthe transformation produces a type-correct formal model, on which the conjecturesconstructed by template translation are true by construction [6,8].In all the work with UML+Z, however, a major inhibiting factor is the lack of toolsupport for management and instantiation of templates. The GeFoRME approachemploys a formal translation. Translation is a conventional way of considering “in-tegrated methods” (reviewed in, for example, [17]), but it is essentially the sameas the model transformations that are characteristic of model-driven development(MDD) – the family of approaches to tool-supported practical software developmentthat focuses on the construction and manipulation of primarily-diagrammatic mod-els [29]. As in formal translation, MDD model transformation defines a mappingfrom a source model to a target model [11]. The mapping, or transformation defi-nition, comprises transformation rules which specify how each modelling constructis transformed. In transforming diagrammatic models to formal models, we ap-ply a model-to-text (as opposed to model-to-model) transformation. Model-to-texttransformation is most commonly used for code generation [1], so is appropriate forgenerating, for instance, the LATEX (or any other) markup for a formal notation.This paper presents a tool for the management and instantiation of FTL tem-plates. The tool currently supports the UML+Z translation, as well as a meansto extend the template base; the tool and GeFoRME are sufficiently generic thatthe approach could also support other diagrammatic source and formal target lan-guages. The tool provides the interaction necessary for a na¨ıve user to generate aformal model and automatically verify it using existing Z tools. In addition, thetool supports expert users who wish to extend the template repertoire or provide54Williams and Polacknew specialisations of the tool.In the next section, we introduce Ama´lio’s template-based formalisation. Insection 3 we describe the tool support, and in section 4 we illustrate the capabilitiesof UML+Z, the translation tool and support for different user levels. In section5, we discuss the advantages and limitation of the work so far, and consider theextensions to the tool and the template library.2 Ama´lio’s Template-based FormalisationIn [9], Ama´lio motivates his work by identifying some shortcomings of diagrammaticapproaches to software engineering that can be addressed by practical formalisation.He notes the need to model concepts that cannot be expressed diagrammatically– constraints and model properties – and considers the general problem of seman-tics. Diagrammatic approaches such as entity-relationship modelling and UML arewidely used in practical software engineering, and the notations have well-definedabstract syntax (for instance, UML is defined using metamodels, based on the con-cept of reflectivity). However, the semantics of concepts such as class, associationand generalisation, are under-specified. In most cases, the semantics is clarifiedonly when a diagrammatic model is converted to code – thus, a class diagram thatforms the basis for a Java program assumes a Java semantics, but the same dia-gram used to create a C++ program assumes a C++ semantics. In the case ofUML (and related domain-specific modelling notations), annotations are added todiagrams using notations such as the object constraint language, OCL. The rela-tionship between the modelling notations and the constraint language is defined atthe abstract syntax level. An obvious connotation of this situation is that whilstproperties of models can be demonstrated informally (for example, by animation),analysis of consistency or model properties is not consistent across modellers ormodelling tools. In practice, little attention is paid to consistency across model-views or between diagrams and constraint expressions. Note that this problem isnot unique to diagrammatic models: insufficient semantic underpinning was also aproblem for Z, ultimately addressed in its ISO standardisation.Most attempts to associate formal semantics to diagrammatic modelling assigna specific formal meaning to each diagrammatic concept. Whilst this significantlyreduces ambiguity, and admits formal analysis, the formalisation assumes a single,fixed semantics for each concept [9] – and the semantics that is assumed is oftenonly apparent to the formalist. One well-known example is the UML to Object-Ztranslation, which imposes the semantics of Object-Z inheritance on UML general-isation [15,14]. By contrast, Ama´lio’s approach [3] builds on ideas of pattern-baseddevelopment [20] and problem-driven methods [22] to advocate a framework forrigorous, but practical MDD [9]; concept semantics are captured explicitly in thetemplates, so a different semantics simply requires use of a different set of tem-plates. The traceability provided by the template transformation approach allowsengineers to work with the diagrams, which, in effect, form a graphical interfacefor the formality that lies beneath. In many cases, Ama´lio’s approach allows theformalism to be completely hidden from the developer.Ama´lio devised the Formal Template Language (FTL) [3,8] as the rigorous un-355Williams and Polackderpinning to the GeFoRME framework, supporting proof with template represen-tations. Having captured patterns of formal development (e.g. a model structure) inFTL, reasoning can be applied at the pattern level using meta-proof. For example, aprecondition of an operation can be calculated or an initialisation conjecture provedto establish meta-theorems that apply when the concept templates are instantiated[3,8]. The FTL templates and translation process are illustrated in Figure 1 (whichalso shows the subsequent automation, covered in section 3).The existing UML+Z templates and meta-theorems relate to Ama´lio’s ZOOstructuring for Z [7,3]. ZOO uses standard Z – and can easily adapt to pre-standardisation dialects such as the Z/Eves variant. Unlike Object-Z [30], ZOOdoes not require any extension to the Z language or its tool support. Ama´lio showshow a ZOO model is built incrementally using template instantiation. Structuralcomponents are views representing the main OO concepts: objects, classes, associa-tions and system. An object is an atom, a member of the set of all possible objectsand of the set of possible objects of its class [10]. The class structure uses a promotedZ abstract data type [16]; it is represented by an intensional structure that definesthe common properties of the class’s objects, and an extensional structure, thatdefines the class as the set of its objects. The formal association structure formstuples of the classes’ objects using a Z relation. A system is an ensemble of classesand associations. Additional properties (constraints, conjectures) are expressed onthe appropriate views.2.1 Template Instantiation: Ama´lio’s Bank Case StudyOne of Ama´lio’s case studies is a banking system. Ama´lio’s formalisation of twoclasses from his example demonstrates in outline how template instantiation works.Ama´lio gives further descriptions in [3,9,8,6,4].The class diagram, figure 2, shows two classes – Customer and Account. Theassociation, holds, allows an instance of Customer to have zero or more accounts,and an instance of Account to have exactly one customer. The Account class hasoperations to withdraw money, to deposit money, to getBalance for an account; tosuspend and to reactivate an account. The state changes caused by the Accountoperations are described in figure 3. The formalisation is demonstrated here for theAccount class, illustrated in figure 1.Select FTL templates The templates needed to instantiate the Account classcomprise those for the intensional and extensional definition of a class, and thosefor the initialisation of the class (initialisation is a formal technique that capturesa potential start-state for the system, and then proves that this is a valid stateof the system) – see “FTL Template (Typeset from Latex)” in figure 1.Select class diagram concepts and instantiate templates Each template isinstantiated by replacing placeholders (e.g. : ) with relevant con-cept and type names from the UML diagram. Where a template includes a FTLlist (e.g. J. . .K(sep,empty) ), the statement is instantiated once for each element –shown in figure 1 as the instantiation of attributes of the Account class.Select operation templates and identify operation effects For each opera-tion on a class, the template instantiation depends on the type of operation.56Williams and PolackFTL Template (Typeset from Latex)\begin{zed}\ltdelm CL\rtdelm ST ::= \ltdelm iSt\rtdelm \llbracket | \ltdelm oSt\rtdelm \rrbracket\end{zed}\begin{schema}{\ltdelm Cl\rtdelm} \llbracket \ltdelm at\rtdelm : \ltdelm aT\rtdelm \rrbracket \\st : \ltdelm Cl\rtdelm ST\\\where\ltdelm CLI\rtdelm\end{schema}\begin{schema}{\ltdelm Cl\rtdelm Init}\ltdelm Cl\rtdelm'\\\llbracket \ltdelm ii\rtdelm? : \ltdelm iiT\rtdelm \rrbracket \where\ltdelm pI\rtdelm \\\llbracket \ltdelm at\rtdelm' = \ltdelm iv\rtdelm \rrbracket \\st' = \ltdelm iSt\rtdelm\end{schema}\begin{zed}AccountST ::= active | suspend\end{zed}\begin{schema}{Account} accountNo : ACCID\\ balance : Integer\\ atype : ACCTYPE\\st : AccountST \end{schema}\begin{schema}{AccountInit}Account \\ accountNo? : ACCID \\ balance? : Integer \\ atype? : ACCTYPE \\ AccountSt'\where accountNo' = accountNo? \\ balance' = 0 \\ atype' = atype? \\ st' = active\end{schema}[* Print the list of states *]\begin{zed}[%=c.name%]ST ::= [%=initialState.name%] [%for (s in otherStates) { %] | [%=s.name%] [%}%]\end{zed}[* State space *]\begin{schema}{[%=c.name%]}[%for (p in c.ownedAttribute) {%] [%=p.name%] : [%=p.type.name%]\\[%}%]st : [%=c.name%]ST \end{schema}[* State initialisation *]\begin{schema}{[%=c.name%]Init}[%=c.name%] \\[%for (p in c.ownedAttribute) {%] [%=p.name%]? : [%=p.type.name%] \\ [%}%][%=c.name%]St'\where[%for (p in c.ownedAttribute) {%] [%=p.name%]' = [%=p.default%] \\ [%}%]st' = [%=initialState.name%]\end{schema}1. View as Latex2. Translate to EGL3. Instantiate (Amálio's bank example - Account class)4. View as ZEGL TranslationInstantiationFTL LatexGenerated Z part-specificationFig. 1. The steps of a UML+Z Translation, with examples of the type-set and LATEX formats involved57Williams and PolackCustomername: NAME = name?address : ADDRESS = address?ctype : CUSTTYPE = ctype?withdraw(in amount : NAT)deposit(in amount : NAT)getBalance(out bal : INT)suspend()reactivate()accountNo : ACCID = accountNo?balance : INT = 0atype : ACCTYPE = atype?Accountholds1 0..*Fig. 2. Extract from Ama´lio’s bank system class diagram [3]active suspended[balance=0]delete[balance=0]deletewithdraw,deposit,getBalance deposit,getBalancesuspendreactivateFig. 3. Extract from Ama´lio’s bank system state diagram [3]Details of the operation are not included in class diagrams, but can be extractedfrom other UML diagrams or from diagram annotations, or can be entered bythe user. For instance, the withdraw operation is identified as an update oper-ation that changes the state of the system (the alternative is observe). Here,the attribute value that changes is balance, and the operation uses the formula,balance − amount?, where amount? is the input to the operation.Identify states from state diagram The state diagram shows which systemstates need to be represented, but these have to be interpreted in terms of theclasses and attributes. For instance, in figure 3, the two states are active andsuspended. The appropriate template instantiation adds an “attribute”, st: ac-countST, to the formal representation of Account. Template instantiation thenconstructs the formal definition of the attribute type accountST, which here re-sults in the expression, accountST ::= active|suspended, shown in figure 1.Instantiate initialisation templates Initialisation in Z is an operation that hasonly an after-state, represented in post-condition predicates. Unlike other oper-ations, it can be generated automatically by setting all attributes to a defaultvalue or an input. The initialisation template is shown in “FTL Template (Type-set from Latex)” of figure 1, and its instantiation is shown in the “Generated Zpart-specification”. Note that primed components (e.g. Account’ ) are the after-states of an operation, and queried components (e.g. atype? ) are inputs. Theinitialisation of the state attribute st’ is derived from the state diagram, since thestart event in the state diagram points to the first state of the system – in the Ac-count example, st’ = active. In addition to the initialisation specification shownin figure 1, a Z conjecture is generated, that the initialisation state is a valid stateof the system. This is associated to one of the meta-theorems (discussed above),58Williams and Polackand is true by construction if the Z model is type-correct.3 The AUtoZ ToolThe AUtoZ tool (www.jamesrobertwilliams.co.uk/autoz.php) provides automa-tion for Ama´lio’s UML+Z process, outlined in section 2.1. This section describesdesign criteria for the tool. It then outlines the design of the Automatic formalisa-tion of UML to Z tool framework, AUtoZ.3.1 Tool RationaleThe motivation of enhancing the rigour of practical software engineering means thatthe tool has to be readily accessible to software engineers. The tool should integratewith existing software engineering tools, and should be able to inter-operate directlywith existing diagramming and formal support tools.Ama´lio’s GeFoRME is a generic framework, which can be specialised for differentdiagrammatic and formal notations, so the tool needs to be modifiable to othernotations.The tool needs to catalogue the existing UML+Z templates efficiently and sup-port the addition of new templates and meta-proofs: there is potential to extend theexisting UML+Z templates with a wide range of alternative concept semantics. Thisrequirement highlights the need to provide support for both basic transformation-and-analysis use, and expert maintenance of the template libraries.3.2 Tool DesignThe AUtoZ tool is a framework on which different instance tools can be built. Thetwo instances that currently exist are AUtoCADiZ and AUtoZ/Eves. AUtoZ is aplug-in for the Eclipse development environment, which is used as the basis formany modelling and model-management activities in software engineering.The tool requires serialised input of a diagram whose concepts (abstract syntax)can be selected. Common MDD diagramming tools provide serialised XMI output,and are underpinned by a metamodel that defines the abstract syntax (concepts) ofthe notation. This allows concepts and their labels to be automatically extractedfrom diagrams, to instantiate the FTL templates. Here, we use the existing Eclipsemodelling plug-in, UML2 (www.eclipse.org/uml2/), since it supports UML 2.xmodelling, uses a standard metamodel-based approach to abstract syntax, and sitswithin the Eclipse development environment. However, in principle AUtoZ coulduse XMI output from many other modelling tools.To represent the FTL templates as model transformation mappings, we convertthe FTL format to Epsilon EGL. Epsilon (www.eclipse.org/gmt/epsilon) pro-vides a suite of integrated model-management tools [25,24], as part of the Eclipse-GMT project. EGL, the Epsilon Generation Language, supports model-to-texttransformation. An EGL run configuration specifies a file containing the XMI sourcemodel, and a file containing EGL transformation rules to be executed on the sourcemodel, as described in [26]. The AUtoZ Eclipse plug-in is a customised EGL runconfiguration that executes the transformations on a UML2 XMI source model to59Williams and PolackUser InteractionUML2 Plug-inAUtoZ ProcessesAUtoZ Run Config FileOperationOperationAttributeAttributeClass NameOperationOperationAttributeAttributeClass NameState StateEGL/FTLTemplateCatalogueEpsilonZ Spec.Theorem ProverOutput MessageMessage ConverterMessagegeneratesgeneratesgeneratesRaw FTL TemplatesEGL Translation ProcessFig. 4. AUtoZ workflow. UML2 and Epsilon are existing Eclipse facilities. The theorem prover can be anysuitable formal analysis tool, and is called automatically by the AUtoZ tool instance.Table 1Some of the FTL-to-EGL conversionsFREE TEXT: FTL (typeset) subCl : CLASS → CLASSFTL (LATEX) subCl : CLASS \to CLASSEGL subCl : CLASS \to CLASSPLACEHOLDER: FTL (typeset) : FTL (LATEX) \ltdelm x \rtdelm : \ltdelm t \rtdelmEGL [%=x.name%] : [%=x.type.name%]LIST: FTL (typeset) J. . .K(sep,empty)FTL (LATEX) \llbracket ...\rrbracket {sep,empty}EGL [% var append : Boolean := false;for (...){if (append){%] sep [%}...;append := true;} %]generate Z LATEX markup, which is then input directly to the formal support toolfor analysis. Figure 4 summarises the workflow of AUtoZ. A developer provides theUML model; the tool calls an AUtoZ run configuration file; Eclipse plug-ins convertUML to Z LATEX via EGL, and call the relevant Z tool. The result of the formalanalysis is returned to the user.The EGL transformation rules are also templates, in a format that is very similarto FTL (though without any formal underpinning). Three typical FTL templatesare shown in Table 1 with their LATEX source, and the corresponding EGL rules.Many of the FTL concepts have a direct equivalent in EGL, and others, such asFTL lists, follow a common pattern in EGL.The component architecture of AUtoZ (figure 5) facilitates development of toolspecialisations and instances integrated with different formal analysis tools. TheAUtoZ framework component is the framework common to any UML+Z tool in-stantiated from the AUtoZ framework, and comprises two Eclipse plug-ins: commonprovides the necessary Eclipse features (dialogues, wizards, tools and launchers),60Williams and PolackCommon Engine<>User InterfaceAUtoZ FrameworkImplementationFig. 5. The generic architecture layers of AUtoZand engine defines the interfaces that specialisations must deploy. The user in-terface component represents the specific tool implementation, also developed asEclipse plug-ins. This allows different versions of AUtoZ using different formaltools to co-exist in the same Eclipse installation.The activities required to transform UML to Z LATEX markup, and to present theLATEX to the formal tool are designed to be completely transparent. This is necessaryto support the basic user, a developer who is well-versed in diagrammatic modellingbut has little interest in formal methods. For such a user, the AUtoZ tools justextend conventional modelling tools with press-button validation of models, withno exposure to the formal underpinning.For the expert user, the AUtoZ tool creates an AUtoZ Eclipse project to managefiles and support creation and editing of new FTL (EGL) templates. The expert userneeds to be familiar with formal methods and able to interact directly with formalnotations and tools, in order to develop new FTL templates and meta-theorems andto write and edit EGL transformation rules corresponding to the FTL templates– perhaps to capture the variant semantics of particular source models. In somecircumstances, an expert user may be needed to complete validation, for instancewhere a particular model has a property that is not captured in a meta-theorem orcannot be discharged automatically.4 Using AUtoCADiZAUtoZ is a generic tool framework. To illustrate its use, we consider an instance ofAUtoZ that uses the CADiZ Z tool. We describe both the basic and expert uses.Space does not allow a detailed analysis, so we simply present a usage scenario forboth the basic and the expert user; further examples are considered in [31].4.1 Basic Use to Validate a UML2 ModelAUtoZ implementations are installed in the Eclipse IDE, and can be selected fromthe AUtoZ folder. A basic user wishing to validate the bank model shown in figures2 and 3 would use the AUtoCADiZ implementation of the tool as described in thefollowing workflow.61Williams and PolackFig. 6. Part of the dialogue used to create a new AUtoCADiZ project.Start a new project The user opens the Eclipse IDE, and uses the File menu toopen a new project dialogue. An AUtoCADiZ project is set up and named, innormal Eclipse style. For example, the user might name the project Spec1, andsave the generated Z LATEX markup to file Spec1.tex. Completion of the set-up(clicking Finish) results in the new project appearing in the Eclipse ProjectExplorer view. A screenshot from this dialogue is shown in figure 6.Diagram creation AUtoCADiZ is linked to the Eclipse UML2 plug-in, which theuser can use to create diagrams such as figures 2 and 3. Some design conventionshave to be followed to facilitate the transformation, notably the definition ofattribute types (used to generate Z given sets and other user-defined types). Atthis stage, the state diagram is associated to the class diagram Account classby naming conventions only, and the transition labelling is simply a list of theoperations responsible for each change of state. On completion, the user savesthe diagrams to the Models directory.Create a run configuration Using the Eclipse Run Configurations dia-logue, the user selects the AUtoCADiZ Template option and New launchconfiguration, associating these to the Spec1 project and Spec1.tex outputfile. The user opts to print the CADiZ output to the console. This run configu-ration is saved.Execute the formalisation Transformation is initiated by running the saved runconfiguration. Almost all of the target Z model is generated directly from theserialised output of the diagramming tool, with no user interaction. However,as in GeFoRME, the Z model of class operations requires detail not in the pre-pared diagrams. Currently, the tool presents a simple dialogue (figure 7) to guide62Williams and Polack(a) Specifying which attributes change (b) Specifying how an attribute changesFig. 7. Part of the user dialogue for input of details for operations. Attributes are taken from the classdiagram. The change formula options reflect the Z types of the selected attributes.the user in adding the required operation details (see section 5.1 for proposedextensions).The tool then completes the generation of the Z LATEX markup, which is passed toCADiZ for type-checking and analysis. The user receives the output from CADiZ atthe console, as requested. Ama´lio has shown that his templates and meta-theoremsproduce type-correct Z when run on a syntactically-correct and consistent UMLmodel [3]. In most cases, therefore, the basic user can expect to get a simpleconfirmation message from CADiZ. We return to this in section 5.1 below.4.2 Expert Use: Working with TemplatesAn expert user needs some understanding of the template languages (EGL, FTL),and the formalisation process. The AUtoZ tools then provide an interface for addingand changing templates. The dialogue to create a project (outlined for AUtoCADiZ,above) provides the appropriate options, which result in a Templates directory be-ing made available for the project, in the Eclipse Project Explorer view. Tem-plates can be edited and added to subfolders containing EGL transformation rules.For example, consider the addition of a new template which lists all of theclasses in the system, named AllClasses(). When creating a new AUtoZ project,the expert user selects an option to include the template catalogue in the projectdirectory. A file is added to the catalogue containing the new EGL template: 1 [∗ Template to l i s t a l l c l a s s e s ∗ ] [% operation A l l C l a s s e s( ) {2 for ( c in Class . a l lOfType ) { %]3 [%=c . name%] \\4 [%]}5 }%] This template can be used in an instantiation by editing the EGL logic file inthe template catalogue (Logic.egl) to include the following:63Williams and Polack 30 . . .31 [∗ import new operat ion ∗ ]32 import ’ A l l C l a s s e s . eg l ’ ;33 . . . 54 . . .55 \ chapter{[%=p . name%] Package}5657 [∗ Cal l the new operat ion ∗ ]58 \ s e c t i o n { L i s t o f C la s s e s in [%=p . name%] Package}59 A l l C l a s s e s ( ) ; . . . To use the modified logic file, the expert uses the run configuration dialogueto select the customised file, in place of the default template catalogue (stored inthe Eclipse plug-in bundle).Further examples of expert use, including template creation, tool customisation,and tool instance creation can be found in [31].5 DiscussionDevelopment of the AUtoZ tool is work in progress. To date, the template instantia-tion of Ama´lio’s bank case study has been completely replicated in the AUtoCADiZtool, and parts have been replicated in AUtoZ/Eves, including the verification ofinstantiated conjectures and meta-theorems. In this section, we outline a numberof future directions for this work.5.1 Research AreasTwo aspects of the tool support require further research, namely the formal speci-fication of operations from UML diagrams, and the handling of messages from theformal tools.Operations Formally specifying UML operations in Z is not a straightforward task,because the details needed to instantiate templates are scattered across UML di-agrams, require interpretation from diagrams, or are simply not amenable torecording in diagrams. The current approach using user dialogues does not scale– even modest UML diagrams often have very large numbers of operations. Fur-ther research is needed to find patterns and commonalities in operation construc-tion that can be used to automatically incorporate operation details from otherdiagrams and minimise user interaction. Furthermore, the tools, and Ama´lio’sUML+Z approach, need extending to exploit pre- and post-conditions written inOCL – an existing body of work on the use of OCL in formalisation (with B orObject-Z target models) [13,28,23] provides a starting point.Error Handling As noted above, the AUtoCADiZ tool currently outputs CADiZerror messages direct to the user. This is unsatisfactory, as the interpretation oftypical CADiZ messages requires some expertise both in CADiZ and in Z. Clearly,the tools cannot truly accessible to modellers and software engineers until theerror messages generated by the Z tools can be related back to the templates,and thus to the inconsistent parts of the UML models.In general, relating the error messages to diagrammatic models is the most64Williams and Polackimportant hurdle to overcome if non-expert practitioners are to be able to useformally-underpinned tools to analyse diagrammatic models. One direction wouldbe to develop another intermediate language into which formal tool messages canbe translated, and have the intermediate language manage the mapping back todiagrammatic model components. This task is complicated by the diverse waysin which formal tools present messages. There is some new work on traceabilityand message generation using Epsilon, which may offer a way forward [18].5.2 Extensions to the ToolAutomatic template translation In describing the tool, we have shown thatFTL maps readily on to EGL, and we note that an expert user involved in tem-plate maintenance would need to be familiar with both languages. FTL is alsoneeded for meta-theorems and proof work, because of its formal underpinnings[3]. We have the groundwork for an automatic translation from FTL to EGL;when implemented it will allow the expert user to maintain templates using eitherFTL or EGL.Template catalogue Williams [31] discussed various necessary improvements tothe cataloguing of Ama´lio’s FTL templates, but the tool currently relies on copy-ing the templates to the AUtoZ project. A better solution would be to have acentral, physically browsable catalogue, and annotated templates, as well as waysto add custom templates to the general catalogue. Note that it is not enoughto provide an interactive catalogue; we need to provide support for template-validation, using Ama´lio’s approach to meta-theorems and the relevant formalanalysis tools.Examples and help Whilst the AUtoZ tools present a solution to the shortage offormally-trained software engineers, potential basic users of the tool still need tounderstand how to validate models with the tools. We would like to add examplemodels and Z specifications as training and reference literature. The EclipseExamples Project (www.eclipse.org/examples) could host such examples andhelp for new tool users.Improved run configuration The current run configuration does not providesuitable checkpoints in the process of generation and analysis of formal mod-els. For example, the user has to generate a complete Z specification and passit to the formal tool for analysis; if the run configuration has not been set upproperly, and the connection to the formal tool is not achieved (for example, anenvironment variable has not been set), then the user has to start again and re-generate the Z specification. This could be addressed by providing some checkingof the run configuration file before execution. Furthermore, generated Z mod-els could easily be saved to file before being passed to the formal analysis tool.A logical next step would then be lazy re-generation, which only re-generatesparts of models that have changed. Epsilon tools can be used to compare models,though some further work is needed to identify the FTL template connotationsof changes to diagrams.Inclusion of Ama´lio’s templates for inheritance and composition Severalparts of UML+Z are not yet included in the AUtoZ tool template repertoire. In65Williams and Polackparticular, Ama´lio considers various semantics of inheritance [3] and proposestemplates for the formalisation of composition relations [5], including the proofthat models remain consistent on deletion of a composed class.Linkage to CZT The Community Z Tools (CZT) initiative (czt.sourceforge.net) offers a range of support tools for Z, including parsers, translators, type-checking and a Unicode markup for Z. It would be useful to investigate integrationof AUtoZ tools into this formal project.Generalising tool support Ama´lio [3] developed a generic formalisation frame-work, GeFoRME, of which UML+Z is one specialisation. The AUtoZ tool couldbe made more generic by converting the components of the AUtoZ frameworklayer to a GeFoRME Framework, upon which any GeFoRME Framework appli-cation could be built. Under this development, AUtoZ would be constructed as aspecific instance of the GeFoRME framework, with AUtoCADiZ, AUtoZ/Eves asimplementations. Other GeFoRME frameworks, such as a UML+B Framework,could be built upon the same structures. Such a product-line architecture wouldallow massive reuse of components and powerful tools. There is also the potentialto generalise the handling of source models.6 ConclusionThe AUtoZ tools are a practical contribution to the verification, through formalanalysis, of diagrammatic models. The work exploits the component-based UML+Zformalisation of Ama´lio, itself motivated by the desire to make formal analysisaccessible to diagrammatic modellers. We have described the tools, the levels ofuse that they support, and the potential for generalisation and extension. Workingwithin the Eclipse IDE and an established MDD tool suite, makes this style offormalisation both practical and usable in state-of-the-art diagram-based softwaremodelling, and in model-driven engineering.References[1] Aagedal, J., A. Berre, R. Gronmo, J. Neple and T. Oldevik, Toward standardised model to texttransformations, in: Model Driven Architecture Foundations and Applications, LNCS 3748 (2005),pp. 239–253.[2] Abdul Sani, A., “Formal Analysis of Metamodel: an evaluation of an approach using ZOO templatesto derive a Z model of part of EMOF,” Master’s thesis, Computer Science, University of York (2007).[3] Ama´lio, N., “Generative frameworks for rigorous model-driven development,” Ph.D. thesis, Dept.Computer Science, Univ. of York (2007).[4] Ama´lio, N. and F. Polack, Comparison of formalisation approaches of UML class constructs in Z andObject-Z, in: ZB 2003, LNCS 2651 (2003), pp. 339–359.[5] Ama´lio, N., F. Polack and S. Stepney, Modular UML semantics: Interpretations in Z based on templatesand generics, in: FACS’03 Workshop (2003), pp. 81–100, technical Report 284: www.iist.unu.edu/newrh/III/1/docs/techreports/report284.html.[6] Ama´lio, N., F. Polack and S. Stepney, Formal proof from UML models, in: ICFEM04: Formal Methodsand Software Engineering, LNCS 3308 (2004), pp. 418–433.[7] Ama´lio, N., F. Polack and S. Stepney, An object-oriented structuring for Z based on views, in: ZB 2005,LNCS 3455 (2005), pp. 262–278.66Williams and Polack[8] Ama´lio, N., F. Polack and S. Stepney, A formal template language enabling metaproof, in: FM 2006:Formal Methods, LNCS 4085 (2006), pp. 252–267.[9] Ama´lio, N., F. Polack and S. Stepney, Frameworks based on templates for rigorous model-drivendevelopment, in: IFM 2005 Doctoral Symposium, ENTCS 191 (2007), pp. 3–23.[10] Ama´lio, N., F. Polack and J. Zhang, Autonomous objects and bottom-up composition in ZOO appliedto a case study of biological reactivity, in: ABZ2008, LNCS 5238 (2008), pp. 323–336.[11] Bast, W., A. Kleppe and J. Warmer, “MDA explained: the model driven architecture: Practice andpromise,” Addison-Wesley, 2003.[12] Bowen, J. P. and M. G. Hinchey, Seven more myths of formal methods, IEEE Software 12 (1995),pp. 34–41.[13] Broda, K., D. Roe and A. Russo, Mapping UML models incorporating OCL constraints into Object-Z,Technical report, Imperial College London (2003).[14] Carrington, D. and S.-K. Kim, Using integrated metamodeling to define OO design patterns with Object-Z and UML, in: Asia-Pacific Software Engineering Conference (2004), pp. 528–537.[15] Carrington, D. and S.-K. Kim, A tool for a formal pattern modeling language, in: ICFEM, LNCS 4260(2006), pp. 568–587.[16] Davies, J. and J. Woodcock, “Using Z: Specification, Refinement, and Proof,” Prentice-Hall, 1996.[17] Docker, T. W. G., R. B. France and L. T. Semmens, Integrated structured analysis and formalspecification techniques, The Computer Journal 35 (1992), pp. 600–610.[18] Drivalos, N., K. J. Fernandes, D. S. Kolovos and R. F. Paige, Engineering a DSL for softwaretraceability, in: Software Languages Engineering 2008, LNCS 5452 (2009), pp. 151–167.[19] D’Sousa, D. and A. C. Wills, “Object Components and Frameworks with UML: the Catalysis approach,”Addison-Wesley, 1998.[20] Gamma, E., R. Helm, R. Johnson and J.Vlissides, “Design Patterns: Elements of Resusable Object-Oriented Software,” Addison-Wesley, 1995.[21] Hall, A., Seven myths of formal methods, IEEE Software 7 (1990), pp. 11–19.[22] Jackson, M., Formal methods and traditional engineering, The Journal of Systems and Software 40(1998), pp. 191–194.[23] Kleppe, A. and J. Warmer, Object-Z to OCL dictionary, www.klasse.nl/ocl/oz-ocl-mapping.pdf.[24] Kolovos, D. S., “An Extensible Platform for Specification of Integrated Languages for ModelManagement,” Ph.D. thesis, Computer Science, University of York (2008).[25] Kolovos, D. S., R. F. Paige and F. A. C. Polack, Epsilon development tools for Eclipse, in: EclipseSummit (2006).[26] Kolovos, D. S., R. F. Paige, F. A. C. Polack and L. M. Rose, The Epsilon Generation Language, in:EC-MDA, LNCS 5095 (2008), pp. 1–16.[27] Le Charlier, B. and P. Flener, Specifications are necessarily informal or: Some more myths of formalmethods, The Journal of Systems and Software 40 (1998), pp. 275–296.[28] Ledang, H. and J. Souquie`res, Integration of UML and B specification techniques: Systematictransformation from OCL expressions into B, in: APSEC ’02 (2002), p. 495.[29] Schmidt, D. C., Model-driven engineering, IEEE Computer (39), pp. 25–31.[30] Smith, G., “The Object-Z Specification Language,” Kluwer, 2000.[31] Williams, J. R., “AUtoZ: Automatic formalisation of UML to Z,” MEng thesis, Computer Science,University of York (2009), www.jamesrobertwilliams.co.uk/publications/WilliamsMEng.pdf.6768FACS 2009Model Checking of Component ProtocolConformance – Optimizations by ReducingFalse NegativesAndreas Both and Wolf Zimmermann 1Institute of Computer ScienceUniversity of HalleHalle (Saale), GermanyAbstractIn previous work we defined a conservative representation, capturing the behavior of an abstraction ofa component-based system and a protocol (based on interactions) to be verified. We have achieved tomodelling unbound concurrency and unbound recursion within this abstraction. It turned out that theprotocol checking problem is undecidable. Therefore an overapproximation of this protocol checking problemis used. This overapproximation is checked for counterexamples. Due to the overapproximation, someof these counterexamples are spurious, i. e. they cannot occur. In this work we introduce an a prioriapproach to avoid spurious counterexamples. More concrete, when searching for a counterexample in theoverapproximation we cut branches in the search space that will definitely lead to spurious counterexamples.Keywords: verification, protocol conformance, component-based systems, components, model checking,static analysis, process rewrite systems1 MotivationDeveloping software contains nowadays a big share of reusing previously developedsoftware called components. Often these components were developed a long time agoby different developers, third party companies, in different programming languages,supplied as binary code, or as distributed components (e. g., web services). Thus,there is a big interest in components which can be composed to reliable systems. Wesupport this with a verification process [2]. Here, we will improve the verification.This reduces the additional costs of the verification and raises the quality of theverification results.Creating reliable stateful components is not easy, because the developer hasto prevent and catch every possible error, which might possibly be caused by adifferent sequence of interactions with this component. We bypass this problemby allowing the developer to define sequences of allowed interactions (with the1 Email: andreas.both@informatik.uni-halle.de and wolf.zimmermann@informatik.uni-halle.deThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs69Both, Zimmermannconsidered component) called protocol. The user of a component is responsible forthe protocol being obeyed (protocol conformance). A tool should support the userof components to verify the protocol conformance. Hence, an error caused by anunexpected interaction can be discovered statically. Moreover, only the abstractionsof the used components are required. It is not necessary to know the source code.This ensures a better (re)usability of previously developed components.In [3,2] we have shown how we can use Process Rewrite Systems (PRS) [14]to capture the behavior of source code conservatively. PRS unify Petri netsand Pushdown Automata. Hence they allow recursion and parallelism withoutrestrictions on the calling depth of procedures and the number of concurrent threads,respectively. In the rest of this article, we call this unbound recursion and unboundparallelism. Moreover, in these works we defined a process implementing the staticverification of the interactions of applications.It turned out that the protocol conformance checking problem is undecidable [3].Therefore we overapproximated the protocol conformance checking by representingat least the behavior of the forbidden interactions and the behavior of the consid-ered program as a PRS, named Combined Abstraction. If there is no derivation fromthe initial to a final state in the Combined Abstraction, then there is no forbiddeninteraction according to the protocol, i. e., the protocol conformance is guaranteed.However, if such a derivation is found, it might be a counterexample. Due to theundecidability of the protocol conformance checking problem, this counterexampledoes not necessarily lead to a forbidden interaction. We call such counterexamplesspurious. In a previous work [4] we defined a counterexample-guided abstractionrefinement loop (CEGAR-loop) improving the verification speed. For this ap-proach we took the advantages of the PRS-hierarchy, which classifies the PRS bythe allowed operators. Since a counterexample is checked after it has been found,we call such approaches a posteriori. Because of the fact that all counterexamplesof a conservative approximation have to be verified in the real software (manuallyor tool supported), every spurious counterexample causes an expensive checkingin detail. Thus, a large number of spurious counterexamples reduces the practicalapplicability of a verification.In this work, we improve the search for counterexamples by cutting off branchesin the search tree that definitely lead to spurious counterexamples. The problemof finding a derivation from an initial to final state is at least EXPSPACE-hard(because of the subsumed Petri net, cf. [11]).The paper is organized as follows. In Section 2 we describe the protocol confor-mance problem, introduce PRS, and we shortly review our verification process. Alsowe further discuss the idea behind the construction of the Combined Abstraction.In Section 3 we analyze reasons for spurious counterexamples, while in Section 4we show how to avoid these spurious counterexamples by using a specialized searchstrategy. Moreover, we present an algorithm implementing this search. Therebybranches are cut off by precomputing infeasible paths. The paper finishes with aconsideration of the related work in Section 5 and the conclusion and future workin Section 6.70Both, Zimmermanninterface I0 {sync void n(I1); }interface I1 {sync void z();sync void p();sync void m();async void o(); }interface I2 {sync void a();sync void b();}I1I0 n*I1 zpm*(op|po)I1I2 component C0 impl. I0void main() {// initializationsnew Thread(C2.a());C2.b();C1.p();}void n(I1 ref) {if (…) {ref.m();} else {C1.o();C1.p();}}I2(ba+)*I2I0 component C1 impl. I1void z() {if(…){this.m();}}void p() {// calculations}void m() {if(…){C0.n(this);}}void o() {C2.b();}p1p2p3p4p5p6p7p8p9p10p11p12 component C2 impl. I2void a() {C1.z();this.val = 1;}void b() {r=param/this.val;this.val--;}p14p15p16p17Calculations influencing only the dataflow and result types are omitted. Relevant program points aremarked with pi. Synchronous remote method calls are performed blocking, asynchronous remote methodcalls are performed non-blocking.Fig. 1. Example with three interfaces and derived components.2 Foundations2.1 ProtocolsA protocol describes the allowed use of all callable operations (cf. interfaces) of asingle component or instance 2 , respectively. It can be used to verify (incomingremote) invocations dynamically, and also to verify statically, if the component isalways used in the manner specified by the protocol. In this work, we considerstatic verification. Among other scopes of applications, protocols can be used toavoid uncaught exceptions (cf. [3]) during the execution of a component or to obeybusiness rules (cf. [2]).Creating and verifying service protocols can help to ensure the restrictions ofbusiness rules. For example, we use an SSO-component 3 with the following actions:register and sign in (action a), sign in (b), optionally change password (c), logout(d). The component could have the following protocol (business rule) formulated asregular expression: ((a|b)c∗d)∗. This protocol should be obeyed by every caller ofthe component. We will check automatically, using the mentioned SSO-componentprotocol, whether an application (assembled from components) obeys the definedconstraints.In accordance with other works [22,19,7] we use finite state machines(short: FSM) to represent the protocol PC of a component C. The FSMPC=ˆ(QPC ,ΣPC ,→PC , IPC , FPC ) is defined as usual, i. e., QPC is a finite set of states,ΣPC is a finite set of atomic actions, →PC⊆ QPC ×ΣPC ×QPC is a finite set of tran-sition rules, IPC ∈ QPC is the initial state, FPC ⊆ QPC is the set of final states.The protocol we use here contains only the callable operations (not the abstrac-tion of the component as in e. g., [18]). Thus the protocol can be fixed, while thecomponent implementation is exchanged.Figure 1 shows an example of a component system implementing different in-2 We use the term component for simplification.3 Single Sign On. A component which provides the functionality of a login/logout/session management, sodifferent applications can use this mechanism to verify a user.71Both, Zimmermann((p2||((p6||p3).p7))||((p3||p5).p9.p4)).p1p3p5p9p4p1p3p7p2p6Fig. 2. Example of process-algebraic expression and corresponding cactus stack.terfaces. The protocols of the interfaces are shown as regular expressions. We willconsider only the protocol of the component C2 4 . This component might crashon a division by zero exception, if it is called e. g., with the sequence a b b. If theprotocol (ba+)∗ is obeyed, this crash can be avoided.The use of a component C in a system S assembled from components is theset of all possible sequences of method invocations to C (described in the followingsubsection). Thus, this can also be modeled as a language L(ΠS,C). Hence theprotocol conformance checking is equivalent to check whether L(ΠS,C) ⊆ L(PC),where L(PC) is a regular language defined by the protocol PC of the component C.2.2 Process Rewrite Systems (PRS)Many approaches (e. g., [19,7,16]) model the use of required interfaces in component-based systems by regular languages obtained by finite transducers. In [22] it is shownthat this approach leads to false positives if recursion is present. Thus we needa representation for the abstraction of the behavior of the source code that cancapture every control-flow path conservatively to find all possible errors.The natural execution model for capturing unbound recursion and unboundconcurrency uses states that are represented as a cactus stack (tree of stacks). Ifa procedure call in a process is executed, a stack frame is pushed on a stack. If anew parallel process is started, a new stack grows for this process (like in a saguarostack, cf. Figure 2). Hence an execution transforms a cactus stack into a cactusstack.A cactus stack naturally represents a process-algebraic expression (and viceversa). If a procedure frame p1 is called on a stack p, this is represented by p1.p. Ifa fork to a process p2 on a stack p with the frame p1 happens, this is representedby (p1||p2).p. Thus, we can model state transformations by transforming process-algebraic expressions into process-algebraic expressions. Process Rewrite Systems[14] are a descriptive technique for such transformations. Let PEX(Q) be theset of process-algebraic expressions over a finite set Q of atomic processes and thebinary operators ”.” (for sequential composition, associative) and ”||” (for parallelcomposition, commutative and associative).A Process Rewrite System is defined as Π=ˆ(Q,Σ, I,→, F ), where Q is a finite setof atomic processes, Σ is a finite alphabet over actions, I ∈ Q is the initial process,→⊆ PEX(Q)×(Σunionmulti{λ})×PEX(Q) is a set of process rewrite rules, F ⊆ PEX(Q)is a finite set of final processes. The process ε denotes the empty process. It is theidentity on ”||” and the left identity on ”.”.We introduce a special action λ /∈ Σ, denoting no relevant interac-tion or empty word. The process rewrite rules define a derivation relation4 All other protocols can be checked using the similar way.72Both, ZimmermannSystem Ab-stractionΠS,CCombinedAbstractionΠCScounter-examplesccompose single com-ponent abstractionsintersect withone protocol PCcompute counterexamples(model checking)Fig. 3. Verification process.p1λ→ p3||p2, p2 a→ p14.p2′, p2′ λ→ ε, p5 λ→ p6,p3b→ p16.p4, p4 p→ p10.ε, p5 λ→ p7, p6 m→ p11.ε,p7o→ p12||p8, p8 p→ p10.ε, p9 m→ p11.ε, p9 λ→ ε,p10λ→ ε, p11 n→ p5.ε, p11 λ→ ε, p12 b→ p14.ε,p14z→ p9.p15, p15 λ→ ε, p16 λ→ p17, p17 λ→ ε(a) Constructed system abstraction ΠS of the ex-ample in Figure 1.p1λ→ p3||p2, p2 a→ p14.p2′, p2′ λ→ ε, p5 λ→ p6,p3b→ p16.p4, p4 λ→ p10.ε, p5 λ→ p7, p6 λ→ p11.ε,p7λ→ p12||p8, p8 λ→ p10.ε, p9 λ→ p11.ε, p9 λ→ ε,p10λ→ ε, p11 λ→ p5.ε, p11 λ→ ε, p12 b→ p14.ε,p14λ→ p9.p15, p15 λ→ ε, p16 λ→ p17, p17 λ→ ε(b) ΠS,C2, considers only the interactions of com-ponent C2 in Figure 4a.Fig. 4. Example: Constructed system abstraction ΠS of the example in Figure 1 and ΠS,C2.⇒∈ PEX(Q)× Σ∗ × PEX(Q) by the following inference rules (a ∈ Σ, x ∈ Σ∗):(t1a→ t2) ∈ Πt1a⇒ t2,t1a⇒ t2t1.t3a⇒ t2.t3,t1a⇒ t2t1||t3 a⇒ t2||t3,t1a⇒ t2t3||t1 a⇒ t3||t2,t1x⇒ t2 t2 a⇒ t3t1x a=⇒ t3The second rule formalizes that only the frames on the top of the stacks of a cactusstack can be considered for transformations. The third and forth rule specify thatany stack in a cactus stack can be considered (i. e., each of the processes currentlybeing executed can be selected for state transformations). Thus, these two rulesmodel interleaving semantics.L(Π)=ˆ{w : ∃f ∈ F |I w⇒ f} is the language accepted by Π.Pushdown automata are represented by the class of PRS, which allow no paralleloperator. In contrast Petri nets are represented by the class of PRS, which allowno sequential operator. Thus PRS allowing the use of both operators unify thebehavior of pushdown automata and Petri nets.Mayr shows in [14] that the rules of any PRS can be transformed into a normalform, i. e., the LHS and the RHS has one of the forms t1, t1.t2 or t1||t2, where t1and t2 are atomic processes. We assume in this work that every PRS has beentransformed into a PRS in normal form, and that the LHS contains at most the||-operator. In [14] this restriction is called Process Algebra Nets (PAN). It can han-dle unbound recursion and unbound parallelism including synchronization. In thiswork, we use PAN as representation of the behavior of the considered components.The verification process (cf. Figure 3) creates an abstraction ΠS of the systembehavior. Each possible interaction between components is represented by ΠS .In Figure 4a we see the abstraction of the system composed by the abstractionsof the components C1, C2 and C3 (cf. Figure 1). The transformation takes thecontrol-flow into account. Thus every execution path is captured by the abstraction.The abstraction can be made compositional by adding a variation of PRS to thecomponents description. The process of obtaining this description is fully automatic.For details we refer to [3,2]. For checking protocol conformance to a component C,only interactions to C of ΠS are considered. This can be achieved by replacing allinteractions by λ, that do not belong to the interfaces of C by λ, cf. Figure 4b. Wedenote this PRS by ΠS,C .Now, a PRS ΠCS is constructed such that L(ΠCS ) ⊇ L(PC) ∩ L(ΠS,C), i. e., ΠCScontains all sequences of interactions that are forbidden 5 by the protocol PC of one5 These sequences are represented by the inverted protocol, i. e., the inverted FSM PC accepting thecomplement L(PC)=ˆΣ∗ \ L(PC).73Both, ZimmermannR1C = {(v, p, v′′) a−→ (v′, p′, v′′) : (v a→PC v′) ∧ (pa→ΠS,C p′) with v′′ ∈ QPC }RλC = {(v, p, v′) λ→ (v, p′, v′) : (p λ→ΠS,C p′); with v, v′ ∈ QPC }R1Seq = {(v, p, v′′′) a−→ (v′, p′, v′′).(v′′, p′′, v′′′) :(v a→PC v′) ∧ (pa→ΠS,C p′.p′′) with v′′, v′′′ ∈ QPC }RλSeq = {(v, p, v′′) λ→ (v, p′, v′).(v′, p′′, v′′) : (p λ→ΠS,C p′.p′′) with v′, v′′ ∈ QPC }R1PFork = {(v, p, v′′) a−→ (v′, p′, v′′)||(v′, p′′, v′′) : (v a→PC v′) ∧ (pa→ΠS,C p′||p′′) with v′′ ∈ QPC }RλPFork = {(v, p, v′) λ→ (v, p′, v′)||(v, p′′, v′) : (p λ→ΠS,C p′||p′′) with v, v′ ∈ QPC }R1PSync = {(v, p, v′′)||(v, p′, v′′) a−→ (v′, p′′, v′′) : (v a→PC v′) ∧ (p||p′a→ΠS,C p′′) with v′′ ∈ QPC }RλPSync = {(v, p, v′)||(v, p′, v′) λ→ (v, p′′, v′) : (p||p′ λ→ΠS,C p′′) with v, v′ ∈ QPC }R0 = {(v, p, v′′) λ→ (v′, p, v′′) : (v a→PC v′) with p ∈ QΠS,C }Rε = {(v, ε, v) λ→ ε : with v ∈ QPC }Fig. 5. Rules for creating the Combined Abstraction ΠCS .component C (i. e., PC) but nevertheless exists in the program S. It is not possibleto construct a PAN such that L(ΠCS ) = L(PC) ∩ L(ΠS,C) since it is undecidablewhether L(ΠS,C) ⊆ L(PC) [3], but it is decidable whether L(ΠCS ) = ∅ [14]. TheCombined Abstraction ΠCS is also a PRS in the same class of the PRS-hierarchy (cf.[14]) as ΠS . Thus every error can be found, because the Combined Abstraction ΠCScontains all paths from the initial program point to the final state: I ∗⇒ ε.The transition rules→ΠCS = R1C∪RλC∪R1Seq∪RλSeq∪R1PFork∪RλPFork∪R1PSync∪RλPSync ∪ R0 ∪ Rε of the Combined Abstraction ΠCS are computed by using thedirectives in Figure 5. The construction is similar to the intersection of PDA andFSM (cf. [9]). All process constants are triples (vi, pk, vj) where vi, vj ∈ QPC andpk ∈ QS . A triple (vi, pk, vj) encodes the situation, where pk should be rewritten tothe empty process pkw⇒ΠS ε, while the state vi of the FSM PC is transformed intovj accepting the same word w: viw⇒PC vj . A constant (vj , ε, vj) is equivalent to theempty word, because the targeted protocol state is reached and process constantshave been eliminated (cf. Rε in Figure 5). Technical details of the construction ofthe Combined Abstraction ΠCS can be found in [2].Finally, the ΠCS is model checked. The result contains counterexamples c. Thesederivation paths c : I0w⇒ ε of ΠCS are equivalent to possible sequences of interactionsw. In Figure 7 a counterexample c0 is constructed while model checking a givenCombined Abstraction. In Step 1 and Step 2 of the derivation a rule is used includedin R1PFork and R1C , respectively. The resulting term (v1, p1, v2)||(v2, ε, v2) containstwo subterms with a different first entry of the triple, but the protocol can only bein one state (because it is defined globally). To synchronize these entries in step 3the rule ((v1, p1, v2)λ→ (v2, p1, v2)) ∈ R0 is used.The transition rules of the sets R1C , R1Seq, R1PFork and R1PSync are called actionrules, because the protocol states and the process constants are changed while per-forming an interaction between components. On the other hand RλC , RλSeq, RλPFork,RλPSync perform no protocol action. They are called λ-rules. The set R0 containsrules, which we call sleep rules. These are needed to anticipate the interactions per-formed in a parallel thread (interleaving semantics) and to synchronize the protocolstates of the transition rules.74Both, Zimmermannprocess-algebraicexpressions:cactus stacks:protocol states:p2p1v1=v1(v2, p1, v3)||(v2, p3, v3)p2p1v26=v1(v1, p1, v3)||(v2, p3, v3) λ⇒p2p1v1=v1(v1, p1, v3)||(v1, p2, v3) b⇒With the transition rules (v1, p2, v3)b→ (v2, p3, v3) ∈ R1C and (v1, p1, v3)λ→ (v2, p1, v3) ∈ R0.Fig. 6. Example: Synchronization of cactus stack in Combined Abstraction.Given system abstraction (initial constant p0): p0a→ p1||p1 p1 b→ ε p1 λ→ εGiven inverted protocol (initial state v0, final state v2): v0a→ v1 v1 b→ v2Generated Combined Abstraction (initial constant (v0, p0, v2), only rules required for counterexamples):(v0, p0, v2)a−→ (v1, p1, v2)||(v1, p1, v2) (v1, p1, v2) b−→ (v2, ε, v2) (v1, p1, v2) λ→ (v2, p1, v2)(v1, p1, v2)λ→ (v1, ε, v2) (v1, ε, v2) λ→ (v2, ε, v2) (v2, p1, v2) λ→ (v2, ε, v2)(v0, p0, v2)λ→ (v1, p0, v2) (v1, p0, v2) λ→ (v2, p0, v2)Computed counterexamples:c0=ˆ(v0, p0, v2)a⇒(v1, p1, v2)||(v1, p1, v2) b⇒(v1, p1, v2)||(v2, ε, v2) λ⇒(v2, p1, v2)||(v2, ε, v2)λ⇒ (v2, ε, v2)||(v2, ε, v2) λ⇒ (v2, ε, v2) λ⇒ εc1=ˆ(v0, p0, v2)a⇒(v1, p1, v2)||(v1, p1, v2) λ⇒ (v1, p1, v2)||(v1, ε, v2) λ⇒(v1, p1, v2)||(v2, ε, v2)λ⇒ (v1, ε, v2)||(v2, ε, v2) λ⇒(v2, ε, v2)||(v2, ε, v2) λ⇒ (v2, ε, v2) λ⇒ εc2=ˆ(v0, p0, v2)a⇒(v1, p1, v2)||(v1, p1, v2) b⇒(v1, p1, v2)||(v2, ε, v2) λ⇒ (v1, p1, v2) b⇒(v2, ε, v2) λ⇒ εFig. 7. Example: Spurious False Negatives.An example can be seen in Figure 6. There we represent a part of the derivationc0 in Figure 7. The first applied transition rule (action rule) changes the protocolstate in the second triple only. Thus two protocol states v1 and v2 exist in the term.This is not possible, because the protocol state is global. To translate the protocolstate v1 into v2 a sleep rule is applied in the second step.However, some of the counterexamples might not occur (e. g., because of over-approximation). We call these counterexamples false negatives. False negativescannot generally be avoided, since the protocol conformance checking problem isundecidable, as soon as unbound parallelism and unbound recursion are taken intoaccount [3].Table 1 summarizes the notations in this paper.3 Structure of False NegativesWhile solving the model checking problem for protocol conformance checking, a bigissue is to ensure that not too many false negatives are created. This is important,because every reported counterexample has to be validated in the verified sourcecode because of the conservative approximation of the behavior. This is an expensivetask, thus the effort should be reduced as much as possible.False negatives can be classified into the following categories:• Real false negatives: Because the source code abstractions are created withoutany data flow or detailed control flow analysis, it is possible that a trace could be75Both, ZimmermannNotation DescriptionPC protocol of a component C (represented as FSM or regular expression)ΠS system abstraction of a full component-based systemΠS,C system abstraction, considering only the interactions of a component CΠCS Combined Abstraction of a component CPEX(Q) set of process-algebraic expressionss, t process-algebraic terms, s, t ∈ PEX(Q)v states of an (inverted) protocol, v ∈ PCa, b, λ interactions in the considered system, a, b ∈ Σ, no interaction λ /∈ Σw, x, y, λ sequences of interactions, w, x, y ∈ Σ∗, empty sequence of interactions λp, ε atomic processes, p ∈ Q, empty process, ε ∈ QTable 1Notations used in this paper.contained in the component abstraction that does not correspond to any executionpath of the implementation.• Spurious false negatives: We construct an approximated intersection of the lan-guages described by the system and by the considered inverted protocol. There-fore it is possible to get false negatives.If a precise behavior abstraction is assumed, spurious counterexamples caused byan inappropriate number of interactions are likely to occur. While computing coun-terexamples it is possible that these contain too many or too few interactions. Thereachability analysis for PRS may compute counterexamples, e. g., in Figure 7:(i) The counterexample c1 has too few interactions. The sleep rules are used forreaching the final state of the protocol without interactions. Due to statechanges in the system abstraction without interactions, the final state ε can bereached.(ii) The counterexample c2 has too many interactions. Consecutive applications ofaction rules lead to a process-algebraic expression that can be reduced to ε ifadditional action rules are applied.Remark: The full setting of the example in Figure 7 can be found in the appendix.4 Reducing the Number of False NegativesIn this section we will describe an extension of the reachability analysis of PAN,while using the information about interactions of the considered software encodedin the Combined Abstraction. This will eliminate the false negatives caused by aninappropriate number of interactions.4.1 Basic IdeaA counterexample c is a sequence of interactions w used to create a derivationfrom the initial constant I to the final constant ε: I w⇒ ε. This sequence has to becontained in the language of the inverted protocol PC (inverted protocol FSM), thuswe can check w ∈ L(PC). Using this approach we can eliminate the counterexamplesc1 and c2 of Figure 7.However, this check requires the explicit construction of a spurious counterex-ample. Here, our goal is to avoid this explicit construction. First, this leads to a76Both, ZimmermannGiven system abstraction rules (initial constant p0): p0a→ p1||p1, p1 b→ ε, p1 λ→ εGiven inverted protocol (initial state v0, final state v2): v0a→ v1, v1 b→ v2, v2 b→ v2A computable counterexample: c2 of Figure 7Fig. 8. Adapted example of Figure 7: language inclusion results in an impractical output (impractical,because it is difficult to capture the invalidity of the computed counterexample).more efficient search for counterexamples. Second, the above might give false hintsto how counterexamples can be derived. The latter is demonstrated by the exampleof Figure 8: The counterexample c2 can be constructed in the same way as in Figure7. However, the language inclusion check does not fail, because the word w of c2 iscontained in the language of the inverted protocol: w = abb ∈ L(abb∗). A closer lookshows, that c2 contains two transitions from the protocol state v1 to v2 using the in-teraction b. As we know this is not possible, because only one interaction is allowedat one point in time (interleaving semantics). This situation is confusing, since de-velopers might conclude erroneously from c2, that it is a false negative. Hence thisapproach looses some pieces of information about the generated counterexamples.The idea is now, when a protocol state change happens in one of the terms wherea rule is applicable (head terms), then we first change the protocol state in the otherhead terms before we continue the search. We call this heuristic the Round-robinreachability. The derivation of c0 in Figure 7 follows this strategy.4.2 The Round-robin Reachability AlgorithmIn this section we prove that this heuristic does not exclude non-spurious counterex-amples. Figure 9 shows a backtracking algorithm implementing this strategy.It uses the following notations:• As can be seen from the inference rules defining the derivations, the derivation re-lation in a term (p1.u1|| . . . ||pn.un).un+1, where n > 0, u1, . . . , un+1 ∈ PEX(Q),p1, . . . , pn ∈ Q is only applied to one of the terms pi. Formally, we definethe notion of the set of heads H(t) for a process-algebraic term t ∈ PEX(Q)inductively as follows: The multiset of (atomic) heads H(t) and the multiset ofsynchronization possibilities S(t) of a PRS term t is defined as follows:H(p)=ˆ{{p}} S(t)=ˆ{{pi||pj : pi, pj ∈ H(t), pi 6= pj ∨ ξA(t)(pi) ≥ 2}}H(t1.t2)=ˆH(t1)H(t1||t2)=ˆH(t1)||H(t2)Where ξA(t) denotes the number of elements ina multiset A and p, p1, p2 ∈ Q, t1, t2 ∈ PEX(Q)Intuitively the heads are the top stack frames in a cactus stack. E. g., theheads in Figure 2 are {{p2, p3, p3, p5, p6}} and the synchronization possibilitiesare {{p2||p3, p2||p3, p2||p5, p2||p6, p3||p3, p3||p5, p3||p6, p3||p5, p3||p6, p5||p6}}. As wecan see the synchronization properties are an overapproximation – e. g., p5||p6can not be transformed using PRS rules into the given cactus stack – but thisdefinition satisfies our needs.Property 1 If in a PRS Π a rule δ : t1b→ t2 is applied to process-algebraic termt (i. e., t b⇒ t′), then there is a head h ∈ H(t) or a synchronization possibilityh ∈ S(t), s. t. t′ is obtained from t by replacing h by h′ by the same rule δ, where77Both, Zimmermann(1) Algorithm newReach :(2) Input: PRS Term t(3) Output: Derivation tw⇒ ε if it exists, false otherwise(4) if t = ε then return ε;(5) let R be the set of rules applicable to t;(6) foreach δ ∈ R do(7) t′ := t;(8) case δ of(9) t1λ→ t2:(10) t′ := apply δ to t′;(11) if newReach(t′) = t′ w⇒ ε(12) then return tλ⇒ t′ w⇒ ε ;(13) t1a→ t2:(14) choose h ∈ H(t′) ∪ S(t′)(15) t′ := apply δ at h of t′ ;(16) d := ta⇒ t′;(17) foreach h′ ∈ H(t′) ∧ ps(h′) 6= ps(t2)(18) let δ′ be the corresponding sleep rule of δ;(19) t′ := apply δ′ at h′ of t′(20) d := dλ⇒ t′;(21) od;(22) esac(23) if newReach(t′) = t′ w⇒ ε return d aw⇒ ε;(24) od;(25) return false;Fig. 9. Round-robin reachability algorithm in pseudo code.hb⇒ h′.Property 1 states that any action rule is either applied to a top frame of a cactusstack or it synchronizes two threads (i. e., it merges two stacks into one).• Corresponding sleep rule: A rule δ ∈ R0 of the considered Combined AbstractionΠCS which is created by using a rule va→ v′ of the protocol PC is called the sleeprule corresponding to an action rule t1a→ t2.• A protocol state of a process-algebraic term is the set of protocol states. Theprotocol state of a triple (v, p, v′) is v. Formally we define the function ps(t) fora process-algebraic term t ∈ PEX(Q) as follows: ps(t) = {v : (v, p, v′) ∈ H(t)}.In the algorithm (cf. Figure 9) it is valid: if an action rule δ is applied to onehead, all other heads are rewritten to the corresponding protocol state by usingsleep rules corresponding to δ (cf. line 17-21).At line 14 of the algorithm we choose one head h ∈ H(t) or one synchronizationpossibility h ∈ S(t) of the current term t to apply δ: h a⇒ h′. Following the definitionof action rules this means that the protocol state of h could differ from the one ofh′. At line 17 we ensure that all other heads are imitating rewriting of the protocolstate in h′ while applying a corresponding sleep rule.Thus in every derivation step, if one action rule δ has been applied, then allheads are translated into the same protocol state by applying the correspondingsleep rules of δ to extend the derivation d. Hence the problems of the languageinclusion are eliminated:• It is ensured that only one protocol transition is performed in one derivation stepof the Combined Abstraction.• It is checked in every derivation step, whether such a derivation will create spu-rious false negatives.78Both, ZimmermannThe following theorem states that each non-spurious counterexample can beconstructed by the Round-robin reachability.Theorem 4.1 Let ΠS,C be a system abstraction (considering component C), PCbe the inverted protocol of component C, and w ∈ Σ∗, such that t w⇒ΠS,C ε fora term t ∈ PEX(QΠS,C ) and v w⇒PC f for a protocol state v ∈ QPC and a finalprotocol state f ∈ FPC . Then there is a process-algebraic expression s ∈ QΠCS overthe Combined Abstraction such that s w⇒ ε and |ps(s)| = 1, i. e., the protocol statesin the heads are equal.The proof of Theorem 4.1 requires some technical definitions and lemmas. Lets ∈ PEX(QΠCS ) be a process-algebraic expression over the Combined AbstractionΠCS . The process-algebraic expression F(s) ∈ PEX(QΠS,C ) over the system abstrac-tion ΠS,C ”forgets” the protocol states in s. Formally:F((v, p, v′)) = p ∀(v, p, v′) ∈ QΠCSF(s.s′) = F(s).F(s′) ∀s, s′ ∈ PEX(QΠCS )F(s||s′) = F(s)||F(s′) ∀s, s′ ∈ PEX(QΠCS )E. g., F((v1, p2, v5)||(v1, p3, v2).(v2, p4, v5)) = p2||p3.p4. Furthermore let F−1(t) ={s|F(s) = t}.The following lemma states that ”λ-derivations” t λ⇒ΠS,C t′ in the system ab-straction ΠS,C can be transformed into corresponding λ-derivations sλ⇒ΠCS s′ in theCombined Abstraction ΠCS :Lemma 4.2 Let t, t′ ∈ PEX(QΠS,C ) such that t λ⇒ΠS,C t′. Then, for all s′ ∈F−1(t′), there is an s ∈ F−1(t) such that the following properties are satisfied.(i) s λ⇒ΠCS s′ using only rules δ ∈ RλC ∪RλSeq ∪RλPFork ∪RλPSync.(ii) (v, p, v′) ∈ H(s) iff there is a p′ ∈ QΠS,C such that either (v, p′, v′) ∈ H(s′) or(v, p, v) ∈ H(s′).Remark: 2. implies that ps(s) = ps(s′), i. e., no state change in the protocol happens.Proof. Straightforward induction on the construction of t λ⇒ΠS,C t′. 2Lemma 4.3 states that the Round-robin derivation can always be constructed,if there is exactly one protocol state change, i. e., an action rule is applied (cf. line14-21 in Figure 9).Lemma 4.3 Let t1, t2 ∈ PEX(QΠS,C ) two process-algebraic expressions over thesystem abstraction ΠS,C such that t1a⇒ΠS,C t2 for an a ∈ Σ by application of asingle rule δ. If in the protocol PC , there is a state transition va→PC v′, then forany s2 ∈ F−1(t2) satisfying ps(s2) = {v′}, there is a s1 ∈ F−1(t1) such that thefollowing properties are satisfied:(i) ps(s1) = {v}(ii) s1a⇒ΠCS s′ λ⇒ΠCS s2 where s1a⇒ΠCS s′ uses a single rule δ ∈ R1C∪R1Seq∪R1PFork∪79Both, ZimmermannR1PSync and s′ λ⇒ΠCS s2 only uses rules δ which are corresponding sleep rules ofva→PC v′.Proof. (of Lemma 4.3)Case 1: δ=ˆ(p a→ΠS,C p′) or δ=ˆ(p a→ΠS,C p′||p′′) or δ=ˆ(p||p′′ a→ΠS,C p′). Then, theremust be a protocol state v′′ ∈ QPC such that (v′, p′, v′′) ∈ H(s2). Suppose thatH(s2) \ {(v′, p′, v′′)} = {(v′, p1, v1), . . . , (v′, pn, vn)}. Then a derivation s′n λ⇒ΠCSs′n−1λ⇒ΠCS . . .λ⇒ΠCS s′1λ⇒ΠCS s′0 = s2 where s′i−1 is the result of the application ofthe rule (v, pi, vi)λ→ΠCS (v′, pi, vi) at head (v, pi, vi) of term s′i, i = n, . . . , 1. Thus,only corresponding sleep rules of v a→ΠCS v′ are applied, and (v′, p′, v′′) ∈ H(s′n) isthe only atomic process with a protocol state different from v. By induction onthe construction of t1a⇒ΠS,C t2, one can prove that s a⇒ΠCS s′n using (v, p, v′′) a→ΠCS(v′, p, v′′), (v, p, v′′)||(v, p′, v′′) a→ΠCS (v′, p′′, v′′) for a v′′ ∈ QPC , or (v, p, v′′) a→ΠCS(v′, p′, v′′)||(v′, r′′, v′′), respectively.Case 2: δ = p a→ΠS,C p′||p′′. Then there is a protocol state v′′ ∈ QPC such that(v′, p′, v′′) ∈ H(s2), and (v′, p′′, v′′) ∈ H(s2). The rest of the proof is analogousexcept that H(s2) \ {{(v′, p′, v′′), (v′, p′′, v′′)}} is used. 2Proof. (of Theorem 4.1)Induction on w:w = λ: By Lemma 4.2, there is a s ∈ F−1(t) such that s λ⇒ΠS,C ε and, since v λ⇒PC fimplies v = f , H(s) = {{f}}.w = ax: for an a ∈ Σ and x ∈ Σ∗.Then, t ax⇒ΠS,C ε has the form t λ⇒ΠS,C t1 a⇒ΠS,C t2 x⇒ΠS,C ε, and v w⇒PC f has theform v a⇒PC v′ x⇒PC f .By induction hypothesis, there is an s2 ∈ PEX(QΠCS ) such that s2a⇒ΠCS ε and|ps(s2)| = 1. By Lemma 4.3, there is an s1 ∈ PEX(QΠCS ) such that s1a⇒ΠCS s2,where ⇒ΠCS is constructed according to Round-robin reachability. By Lemma 4.2,there is an s ∈ PEX(QΠCS ) such that sλ⇒ΠCS s1 only using rules of R0 and |ps(s)| =1. Thus s λ⇒ΠCS s1a⇒ΠCS s2x⇒ΠCS ε. 2Corollary 4.4 If w ∈ L(ΠS,C) ∩ L(PC), then there is a Round-robin reachabilityderivation t w⇒ΠCS ε in the Combined Abstraction ΠCS , where t ∈ QΠCS is the initialstate of ΠCS .Hence the reachability problem can be solved by using the Round-robin reach-ability and will create fewer false negatives. This leads to a better applicabilitybecause a component developer or quality management representative has to checka lower number of counterexamples. Moreover, because we cut branches during theverification, it will probably be finished faster.Finally, considering the example in Figure 7, the counterexamples c1 and c2 arenot created while using the Round-robin reachability. This will also reduce thenumber of false negatives in Figure 1, because Figure 7 was a simplification of thebehavior of the system abstraction shown in Figure 4b.80Both, Zimmermann5 Related WorkMany works on static protocol-checking of components consider local protocol check-ing on FSMs. The same approach can also be applied to check protocols of objects inobject-oriented systems. The idea of static type checking by using FSMs goes backto Nierstrasz [15]. His approach uses regular languages to model the dynamic behav-ior of objects, which is less powerful than context-free grammars (CFG). Therefore,the approach cannot handle recursive call-backs. In [12] object-life cycles for thedynamic exchange of implementations of classes and methods using a combinationof the bridge/strategy pattern are considered. This approach also bases on FSMs.The approach comprises dynamic as well as static conformance checking. Tenzerand Stevens [21] investigate approaches for checking object-life cycles. They assumethat object-life cycles of UML-classes are described using UML state-charts and thatfor each method of a client, there is a FSM that describes the calling sequence fromthat method. In order to deal with recursion, Tenzer and Stevens add a rathercomplicated recursion mechanism to FSMs. It is not clear whether this recursionmechanism is as powerful as pushdown automata and therefore could accept generalcontext-free languages. All these works are for sequential systems. Schmidt et al. [8]propose an approach for protocol checking of concurrent component-based systems.Their approach is also FSM-based and unable to deal with recursive call-backs.An alternative approach for an investigation of protocol conformance is the use ofprocess algebras such as CSP (e. g., [1]). These approaches are more powerful thanFSMs and context-free grammars. However, mechanized checking requires somerestrictions on the specification language. For example, [1] uses a subset of CSPthat allows only the specification of finite processes. At the end the conformancechecking is reduced to checking FSMs similar to [8].In [16] behavioral protocol conformance is used to describe a problem similar toours. In contrast to our approach the developer has to define not only the allowedreceivable calls but also the calls of the component. This approach can not handlerecursive callbacks, since the verification is reduced to finite state model checking.Many works use process algebras as abstractions for the formal (behavioral)analysis of e. g., BPEL applications. In [6] FSP were used, while in [20] CCS wasused. Process algebras are similar to PAN considered in our work. These works donot verify behavior in our sense (protocol conformance).The approach improved in this paper is represented in [2]. It is a generalizationof [22,3]. In [22] recursion is modeled by CFG, so only sequential behavior is con-sidered. Moreover, recursive callbacks are already respected. The model checkingproblem is discussed in [5].In our previous work [3,2] (1, G)-PRS (named PA-processes) and (P,G)-PRS(named PAN) are used to model the abstraction of components and we show theapplicability of this process for verifying component-based systems. This requiresanother model checking algorithm, which is already defined [13], but to our knowl-edge not implemented yet.Other works discuss the model checking of PRS. While [17] generates overap-proximations of the execution paths, underapproximations of the reachable configu-rations are computed in [10] (bounded model checking). In contrast to these works81Both, Zimmermannwe only focus on the interpretation of the information included in our representationmodel.To our knowledge no other work exists, where an a priori approach is imple-mented to reduce the number of false negatives during the model checking.6 Conclusions and Future WorkOur verification approach ensures properties based on interaction protocols of pro-grams which include unbound recursion and unbound parallelism. This leads to ahigher quality of software, because the protocol conformance can be checked beforethe deployment. Every error will be found.In this paper we have shown how we can use the special properties of the repre-sentation defined in earlier works to reduce the number of false negatives. We callthis approach Round-robin reachability, because it balances the derivation stepsapplied on each parallel term. This improvement reduces the costs of the qualitycheck, because fewer counterexamples have to be reviewed to find the real errors.We assume that, most spurious counterexamples might be removed in an industrialenvironment.Although this improved verification process can not reduce the complexity of theverification in a general case, we assume that in an industrial setting the verificationwill be finished much faster. To check this assumption is part of our future work.Currently, we validate our approach in an industrial case study of component-based systems written in Python and C/C++. We can create abstractions of sourcecodes written in Python, already. Presently, we are creating generator of abstrac-tions for C/C++ source code. Early results show that our approach is capable offinding errors or unexpected behavior in real programs. In future work we will createabstractions of BPEL and PHP source codes, considering Java is also planned.We thank the anonymous referees for their helpful comments.References[1] R. Allen and S. Garlan. A formal basis for architectural connection. ACM Transactions on SoftwareEngineering and Methodology, 6(3):213–249, 1997.[2] Andreas Both and Wolf Zimmermann. Automatic protocol conformance checking of recursive andparallel bpel systems. In IEEE Sixth European Conference on Web Services (ECOWS ’08), pages81–91, November 2008.[3] Andreas Both and Wolf Zimmermann. Automatic protocol conformance checking of recursive andparallel component-based systems. In Michel R. V. Chaudron, Clemens A. Szyperski, and RalfReussner, editors, Component-Based Software Engineering, 11th International Symposium (CBSE2008), volume 5282 of LNCS, pages 163–179. Springer, October 2008.[4] Andreas Both and Wolf Zimmermann. A step towards a more practical protocol conformance checkingalgorithm. In 35th Euromicro Conference on Software Engineering and Advanced Applications, SEAA2009. IEEE Computer Society, August 2009.[5] A. Bouajjani, J. Esparza, and O. Maler. Reachability analysis of pushdown automata: Application tomodel checking. In CONCUR’97: Proc. of the 8th Int. Conf. on Concurrency Theory, volume 1243 ofLNCS, pages 135–150. Springer, 1997.[6] Howard Foster, Sebastia´n Uchitel, Jeff Magee, and Jeff Kramer. Model-based analysis of obligations inweb service choreography. In AICT/ICIW, page 149, 2006.[7] J. Freudig, W. Lo¨we, R. Neumann, and M. Trapp. Subtyping of context-free classes. In Proc. 3rdWhite Object Oriented Nights, 1998.82Both, Zimmermann[8] H. W. Schmidt, B. J. Kra¨mer, I. Poernemo, and R. Reussner. Predictable component architectures usingdependent finite state machines. In Proc. of the NATO Workshop Radical Innovations of Software andSystems Engineering in the Future, volume 2941 of LNCS, pages 310–324. Springer, 2002.[9] John E. Hopcroft and Jeffrey D. Ullman. Introduction to Automata Theory, Languages andComputation. Addison-Wesley, 1979.[10] Akash Lal, Tayssir Touili, Nicholas Kidd, and Thomas Reps. Interprocedural analysis of concurrentprograms under a context bound. 2007.[11] R. J. Lipton. The reachability problem requires exponential space. 62, New Haven, Connecticut: YaleUniversity, Department of Computer Science, Research, January 1976.[12] W. Lo¨we, R. Neumann, M. Trapp, and W. Zimmermann. Robust dynamic exchange of implementationaspects. In TOOLS 29 – Technology of Object-Oriented Languages and Systems, pages 351–360. IEEE,1999.[13] Richard Mayr. Combining petri nets and pa-processes. In TACS’97: Proc. of the Third Int. Symposiumon Theoretical Aspects of Computer Software, pages 547–561, London, UK, 1997. Springer.[14] Richard Mayr. Process rewrite systems. Information and Computation, 156(1-2):264–286, 2000.[15] Oscar Nierstrasz. Regular types for active objects. In Oscar Nierstrasz and Dennis Tsichritzis, editors,Object-Oriented Software Composition, pages 99–121. Prentice-Hall, 1995.[16] Pavel Parizek and Frantisek Plasil. Modeling of component environment in presence of callbacks andautonomous activities. In Richard F. Paige and Bertrand Meyer, editors, TOOLS (46), volume 11 ofLecture Notes in Business Information Processing, pages 2–21. Springer, 2008.[17] Gae¨l Patin, Mihaela Sighireanu, and Tayssir Touili. Spade: Verification of multithreaded dynamic andrecursive programs. In Werner Damm and Holger Hermanns, editors, CAV, volume 4590 of LNCS,pages 254–257. Springer, 2007.[18] Frantisek Plasil and Stanislav Visnovsky. Behavior protocols for software components. IEEETransactions on Software Engineering, 28(11):1056–1076, 2002.[19] R. H. Reussner. Counter-constraint finite state machines: A new model for resource-bounded componentprotocols. In Proc. of the 29th Annual Conf. in Current Trends in Theory and Practice of Informatics,volume 2540 of LNCS, pages 20–40. Springer, 2002.[20] Gwen Salau¨n, Lucas Bordeaux, and Marco Schaerf. Describing and reasoning on web services usingprocess algebra. International Conference on Web Services, 0:43, 2004.[21] J. Tenzer and P. Stevens. Modelling recursive calls with uml state diagrams. In 6th Int. Conf. onFundamental Approaches to Software Engineering (FASE’03), volume 2621 of LNCS, pages 135–149.Springer, 2003.[22] Wolf Zimmermann and Michael Schaarschmidt. Automatic checking of component protocols incomponent-based systems. In Welf Lo¨we and Mario Su¨dholt, editors, Software Composition, volume4089 of LNCS, pages 1–17. Springer, 2006.Complete Example of Figure 7System abstraction: ΠS,C = ({p0, p1, p2}, {a, b, λ}, p0, {p0 a→ p1, p1 b→ ε, p1 λ→ ε}, {ε})Inverted protocol: PC = ({v0, v1, v2}, {a, b}, {v0 a→ v1, v1 b→ v2}, v0, {v2})Combined Abstraction: ΠCS = ({v0, v1, v2} × {p0, p1, p2} × {v0, v1, v2}, {a, b, λ},(v0, p0, v2),R1C ∪RλC ∪R1PFork ∪R0 ∪Rε, {ε} )Non-optimized sets of transition rules of ΠCS :R1C = {(v1, p1, v0) b→ (v2, ε, v0), (v1, p1, v1) b→ (v2, ε, v1), (v1, p1, v2) b→ (v2, ε, v2)}RλC = {(v0, p1, v0) λ→ (v0, ε, v0), (v0, p1, v1) λ→ (v0, ε, v1), (v0, p1, v2) λ→ (v0, ε, v2),(v1, p1, v0)λ→ (v1, ε, v0), (v1, p1, v1) λ→ (v1, ε, v1), (v1, p1, v2) λ→ (v1, ε, v2),(v2, p1, v0)λ→ (v2, ε, v0), (v2, p1, v1) λ→ (v2, ε, v1), (v2, p1, v2) λ→ (v2, ε, v2)}R1PFork = {(v0, p0, v0) a→ (v1, p1, v0)||(v1, p1, v0), (v0, p0, v1) a→ (v1, p1, v1)||(v1, p1, v1),(v0, p0, v2)a→ (v1, p1, v2)||(v1, p1, v2)}R0 = {(v0, p0, v0) λ→ (v1, p0, v0), (v0, p0, v1) λ→ (v1, p0, v1), (v0, p0, v2) λ→ (v1, p1, v2), (v0, p1, v0) λ→(v1, p1, v0), (v0, p1, v1)λ→ (v1, p1, v1), (v0, p1, v2) λ→ (v1, p1, v2), (v1, p0, v0) λ→ (v2, p0, v0),(v1, p0, v1)λ→ (v2, p0, v1), (v1, p2, v2) λ→ (v2, p1, v2), (v1, p1, v0) λ→ (v2, p1, v0), (v1, p1, v1) λ→(v2, p1, v1), (v1, p1, v2)λ→ (v2, p2, v2), (v0, ε, v0) λ→ (v1, ε, v0), (v0, ε, v1) λ→ (v1, ε, v1), (v0, ε, v2)λ→ (v1, ε, v2), (v1, ε, v0) λ→ (v2, ε, v0), (v1, ε, v1) λ→ (v2, ε, v1), (v1, ε, v2) λ→ (v2, ε, v2)}Rε = {(v0, ε, v0) λ→ ε, (v1, ε, v1) λ→ ε, (v2, ε, v2) λ→ ε}8384FACS 2009Reachability in Tree-Like Component Systemsis PSPACE-CompleteMila Majster-Cederbaum1Department of Computer ScienceUniversity MannheimMannheim, GermanyNils Semmelrock 2Department of Computer ScienceUniversity MannheimMannheim, GermanyAbstractThe reachability problem in component systems is PSPACE-complete. We show here that even the reacha-bility problem in the subclass of component systems with “tree-like” communication is PSPACE-complete.For this purpose we reduce the question if a Quantified Boolean Formula (QBF) is true to the reachabilityproblem in “tree-like” component systems.Keywords: Component-Based Modeling, Architectural Constraints, Reachability, PSPACE-Completeness1 IntroductionIn component-based modeling techniques the size of the global state space of asystem is in the worst case exponential in the number of its components. Thisproblem is often referred to as the effect of state space explosion. Thus, checkingproperties of a component-based system by exploring the state space very quicklybecomes inefficient. Here we explore the complexity-theoretical classification ofreachability.As a formal model for component-based systems we consider here interactionsystems [8], a formalism for component-based modeling which offers in general anarbitrary degree of synchronization. Reachability in general interaction systems wasproved to be PSPACE-complete [15] similar to results in 1-safe Petri nets [6].1 Email:mcb@informatik.uni-mannheim.de2 Email:nsemmelr@informatik.uni-mannheim.deThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs85Majster-Cederbaum, SemmelrockTree-like component systems are component systems where the communicationstructure forms a tree. This is an important class of systems which has been earlystudied e.g. in [9,5] and more recently e.g. in [4,12].Here we show that even in the subclass of tree-like interaction systems thereachability problem (and therefore proving deadlock-freedom as well) is PSPACE-complete. We also sketch that deciding progress in tree-like interaction systems isPSPACE-complete.2 Interaction SystemsInteraction systems are a component-based formalism, i.e. a system is composedof subsystems called components. Components are put together by some kind ofglue-code. Interaction systems are defined in two layers. The first layer, the in-teraction model, describes the interfaces of the components and the glue-code of asystem by connecting the interfaces of the components. The second layer describesthe behavior of the components, which is here given in form of labeled transitionsystems.Definition 2.1 Let K = {1, . . . , n} be a finite set of components. For each i ∈ Klet Ai be a finite set of ports such that ∀i,j∈Ki 6= j ⇒ Ai ∩ Aj = ∅. An interactionmodel is a tuple IM := (K, {Ai}i∈K , C), where C is a set such thata) ∀c ∈ C : c ⊆ ⋃i∈KAi,c)⋃c∈Cc =⋃i∈KAi.b) ∀c ∈ C∀i ∈ K : |c ∩Ai| ≤ 1 andThe elements of C are called connectors. Let for c ∈ C and i ∈ K i(c) := c∩Aibe the set of ports of i which participate in c, i.e. |i(c)| ≤ 1.Let Ti = (Qi, Ai,→i, q0i ) for i ∈ K be a labeled transition system with a finiteset of states Qi, a transition relation →i⊆ Qi×Ai×Qi and an initial state q0i ∈ Qi.A transition system Ti for i ∈ K models the behavior of component i. We will writeqiai→i q′i instead of (qi, ai, q′i) ∈→i.Definition 2.2 An interaction system is a tuple Sys := (IM, {Ti}i∈K). Thebehavior of Sys is given by the transition systemT = (QSys, C,→, q0) wherea) QSys :=∏i∈KQi is the state space,b) q0 = (q01, . . . , q0n) ∈ QSys is the initial state andc) →⊆ QSys × C × QSys is the transition relation with q c→ q′ iff for all i ∈ Kqii(c)→i q′i if i(c) 6= ∅ and qi = q′i otherwise.Definition 2.3 Let Sys be an interaction system and T = (QSys, C,→, q0) theassociated global transition system. A global state q ∈ QSys is called reachable iffthere is a path that leads from the initial state q0 to q in T .86Majster-Cederbaum, SemmelrockAs mentioned we focus on a structural constraint on interaction systems. Moreprecisely we look at the important class of interaction systems such that the glue-code describes a tree-like communication pattern, i.e. components never form acycle with respect to their connectors.A tree-like communication structure induces an important class of component-based systems. Many interesting systems belong to this class, e.g. hierarchicalsystems or networks built by a master-slave operator [9]. For these reasons, thisclass of component systems has been studied intensely e.g. in [3,4,5,12].Definition 2.4 Let IM = (K, {Ai}i∈K , C) be an interaction model. The interac-tion graph G∗ = (K,E) of IM is an undirected graph with {i, j} ∈ E iff there isa connector c ∈ C with i(c) 6= ∅ and j(c) 6= ∅.An interaction model IM is called tree-like iff the associated interaction graphG∗ is a tree. An interaction system Sys is called tree-like if its associated interactionmodel is tree-like.Remark 2.5 Note, that a tree-like interaction system with a set C of connectorsimplies that on all c ∈ C |c| ≤ 2.Example 2.6 Consider the dining philosophers problem with n philosophers andn forks. The philosophers, respectively the forks, are labeled with 0, . . . , n− 1. Thephilosophers are placed in order around a table such that between philosopher i andi+1 (we assume modulo n arithmetics) fork i is placed. We construct an interactionsystem such that each philosopher and each fork corresponds to a component. Leti ∈ {0, . . . , n− 1} then philosopher i is modeled by component Phili with the set ofports APhili := {t lefti, t righti, p lefti, p righti} such that the ports are modeling,from left to right: “take left fork”, “take right fork”, “put left fork back on the table”and “put right fork back on the table”. Fork i is modeled by component Forki withthe set of ports AForki := {takei, releasei}.The following connectors describe the synchronization between the philosophersand the forks, corresponding to the seating order.take lefti := {t lefti, takei} take righti := {t righti, takei−1}put lefti := {p lefti, releasei} put righti = {p righti, releasei−1}Consider the problem for n = 3 philosophers, then the set K of components is givenby K = {Phil0, Phil1, Phil2, Fork0, Fork1, Fork2} and the set C of connectors byC := {take lefti, take righti, put lefti, put righti|i = 0, . . . , 2}. The interactionmodel is given by IM = (K, {Ai}i∈K , C). The corresponding interaction graph G∗for IM is given in Figure 1 and forms a cycle.3 QBF Reduction to Tree-Like Interaction SystemsWe will show that reachability in tree-like interaction systems is PSPACE-complete.The PSPACE-hardness will be proved by a reduction from QBF [7]. PSPACE-hardness of reachability in general interaction systems was shown by a reduction87Majster-Cederbaum, SemmelrockPhil0Fork0Phil1Fork1Phil2Fork2Fig. 1. Interaction graph G∗ for the interaction model IM .from reachability in 1-safe Petri nets [15]. To show the PSPACE-hardness of reach-ability in 1-safe Petri nets a reduction from QBF was used [6].3.1 ReductionReachability in tree-like interaction systems is in PSPACE. Given a tree-like inter-action system and a global state q one can guess a sequence of connectors (becausePSPACE=NPSPACE) and check in linear space if it leads from the initial state q0to q. At any time we story exactly one global state from which we guess a validsuccessor state. To prove the PSPACE-hardness we present a reduction from the va-lidity problem for Quantified Boolean Formulas (QBF) to the reachability problemin tree-like interaction systems.3.1.1 QBFAn instance of QBF [7] is given as a well-formed quantified Boolean formula whereits variables x1, . . . , xn are all bound and distinct. Without loss of generality welook at QBF instances over the grammarP ::= x|¬P |P ∧ P |∃x.P.In the following we will assume that a QBF formula is built over this grammar. LetH be a QBF then the question is if H is true. The language TQBF is defined asthe set of true QBF instances and is well known to be PSPACE-complete.There is a straightforward, recursive algorithm called eval to determine whethera QBF P given over the grammar above is in TQBF.Algorithm 11 eval(P )2 if(P = x)3 return value(x)4 if(P = ¬P ′)5 return ¬eval(P ′)6 if(P = P ′ ∧ P ′′)7 return eval(P ′) ∧ eval(P ′′)8 // P = ∃x.P ′ is the only remaining possibility9 return eval(P ′x=true) ∨ eval(P ′x=false)In line 9 P ′x=true denotes the subformula P ′ with true assigned to the variable x.88Majster-Cederbaum, SemmelrockIn line 3 value(x) returns the truth value that is assigned to x. This is possiblebecause every variable x in H is bound by an existential quantifier and therefore atruth value is assigned in line 9. Obviously, H ∈ TQBF ⇔ eval(H) = true.3.1.2 RISTLet IST be the class of tree-like interaction systems. For Sys ∈ IST let Reach(Sys) ⊆QSys be the set of reachable states. LetRIST :=⋃Sys∈IST({Sys} ×QSys) .For (Sys, q) ∈ RIST we want to decide if q is reachable in Sys. Let TRIST ⊆ RISTbe the set of true RIST instances, i.e.TRIST =⋃Sys∈IST({Sys} ×Reach(Sys)) .In the following we will introduce for a QBF H a tree-like interaction system SysHand a global state qt such thati) H ∈ TQBF ⇔ (SysH , qt) ∈ TRIST andii) the size of SysH is polynomial in the size of H.The idea for the construction of SysH can be sketched as follows: the interactionsystem basically simulates the evaluation of the formula H, as in algorithm eval(see Algorithm 1), based on the syntax tree of H. The subformulas of H are thecomponents of the system, and the interaction model describes the propagation oftruth values between the nodes of the syntax tree.Example 3.1 Consider the formula H = ¬∃x1.(x1 ∧ ¬x1). The associated inter-action graph G∗H of IMH is given in Figure 2 where components with highlightedframes denote components that do not model subformulas ofH. IMH is constructedaccordingly to the following reduction.H′H=¬P1∃x1.P2P3 ∧ P4x11 ¬P5x21x′1Fig. 2. Interaction graph G∗H of IMH .We now describe in detail how SysH is constructed:3.1.3 ComponentsLet H be a QBF with variables x1, . . . , xn and K2 = {x′i|xi is a variable in H}. Theset of components K2 is needed to avoid cycles in the interaction graph. Generally,89Majster-Cederbaum, Semmelrockthere may be several occurrences of a variable xi in H. Let xi occur ki times fori = 1, . . . , n as a subformula in H, then we assume that the jth occurrence ofvariable xi is renamed in H as xji for j ∈ {1, . . . , ki}.Let KH = K1 ∪K2 ∪ {H ′} be a set of components such thatK1 = {P |P is a subformula of H}. The component H ′ is an auxiliary componentwhich simplifies the definition of the behavior of the components in K1.Given a truth assignment to the variables, subformulas are assigned true or false.Therefore, when we mention an assignment to a component in K1 ∪K2 we refer tothe assignment of the subformula that is modeled by this component.In the following we will give the port sets of the components. Many ports, indifferent components, serve the same purpose and only differ in their subscripts.Once such a port is introduced it will not be explicitly explained again.Port sets of components modeling variablesFor i = 1, . . . , n and j = 1, . . . , ki the component P = xji ∈ K1 represents the jthoccurrence of variable xi in H. The set AP of ports is given byAP := {aP , tP , fP , rP t} ∪ {rPxlt, rPxlf |l = 1, . . . , n}.• aP abbreviates “activate P” and starts the evaluation of P .• tP respectively fP confirm that currently true respectively false is assigned to P.• rPxlt abbreviates “P receives instruction to set xl true”. If l = i then true isassigned to P . For i 6= l rPxlt has no effect on P . The same applies to rPxlfsetting xl to false.• rP t has the function to assign true to P .Port sets for negated formulasA component modeling a negation, i.e. a subformula of the form P = ¬P1 has thefollowing set of ports APAP := {e1P , aP , sub1P t, sub1P f, tP , fP , rP t, s1P t} ∪{rPxlt, rPxlf, s1Pxlt, s1Pxlf |l = 1, . . . , n}.• e1P abbreviates “evaluate the first subformula of P” and evaluates the subformulaP1.• sub1P t (abbreviates “subformula 1 is true”) respectively sub1P f affirm that P1 wasevaluated true respectively false.• According to the structure of a negation fP (abbreviates “P = ¬P1 is false”) isenabled if P1 was evaluated true. Conversely tP is enabled if P1 was evaluatedfalse.• As above rPxlt models that P receives the instruction to set xl true. On theother hand s1Pxlt (“set xl true in the first subformula of P”) models that P itselfsends the instruction to set xl to true to P1. The same applies to s1Pxlf if xlneeds to be set to false.• s1P t has the function to set the truth assignment of P ’s subformula P1 to true.90Majster-Cederbaum, SemmelrockPort sets for conjunctionsThe component that models a conjunction, i.e. a subformula of the form P = P1∧P2has the set of portsAP := {aP , e1P , e2P , sub1P t, sub1Pf, sub2P t, sub2P f, tP , fP , rP t, s1P t, s2P t} ∪{rPxlt, rPxlf, s1Pxlt, s1Pxlf, s2Pxlt, s2Pxlf |l = 1, . . . , n}.This is the only formula that has two direct subformulas. P = P1 ∧ P2 needsto evaluate P1 and P2, therefore there are ports e1P and e2P . Similarly there aresub1P t, sub1Pf , sub2P t, sub2Pf for actually receiving the truth values of P1 and P2.Likewise, s1Pxlt and s2Pxlt model that P needs to set xl to true in its first and secondsubformula and respectively s1Pxlf and s2Pxlf to false.Port sets for existentially quantified formulas and associated component x′iIn the interaction system SysH a component for a subformula of the form P =∃xi.P1 with i = 1, . . . , n needs to have access to the current truth assignment of thevariable xi. For this purpose the set of components K2 was introduced. Let xi bethe variable that is quantified by the subformula P = ∃xi.P1. The component x′imodels the truth assignment of xi. The set of ports Ax′i is given byAx′i := {rxit, rxif, txi , fxi}.txi respectively fxi affirm that the current state of x′i is true respectively false. rxitassigns x′i true. Analogously rxif switches the assignment to false.The port set AP for P = ∃xi.P1 is given byAP := {aP , e1P , sub1P t, sub1P f, tP , fP , xit, xif, sxit, sxif, rP t, s1P t} ∪{rPxlt, rPxlf, s1Pxlt, s1Pxlf |l = 1, . . . , n}.aP , e1P , sub1P t, sub1Pf , tP and fP act similarly to the corresponding ports of theother components specified above. xit confirms that true is assigned to xi, and sxitsets xi to true if the current assignment is false. On the other hand xif confirmsthat false is assigned to xi, and sxif assigns false to xi if that is not the case.Port set for the auxiliary component H ′Given the syntax tree for H, whose root is labeled H, H ′ can be interpreted as adirect dummy predecessor formula of H without any logical operator. The set ofports AH′ is given byAH′ := {e1H′ , sub1H′t, sub1H′f, s1H′t, endH′}.All ports but endH′ act exactly as the ports described above. It will be shown thatthe formula H is in TQBF iff the component associated with H is evaluated true,i.e. sub1H′t can interact eventually. When the evaluation of the QBF H has beensimulated, i.e. H ′ reached a state that represent the fact that H was evaluated trueor false, then the port endH′ becomes enabled. This only assures that the behaviorof H ′ does not deadlock.91Majster-Cederbaum, Semmelrock3.1.4 ConnectorsWe will now define a set C of connectors. Let P ∈ K1∪{H ′} be a subformula whichis not an occurrence of a variable. P can have one direct subformula which is P1or two direct subformulas P1 and P2. If P needs the truth value of Pk, k ∈ {1, 2},to be evaluated then the evaluation in Pk needs to be activated. This is realized bythe synchronization of ekP and aPk . Furthermore P can ask Pk for its current truthvalue. These interactions are realized byeval P → Pk := {ekP , aPk} P ask Pk true := {subkP t, tPk}P ask Pk false := {subkP f, fPk}for k ∈ {1, 2}. These connectors already connect all components in K1 ∪ {H ′} andresult in an interaction graph that is related to the syntax tree of the QBF H.If P needs all occurrences of variable xi to be set to true or false a directinteraction with the components that model these variables would lead to a cyclein the associated interaction graph. Therefore, P passes this information to itssubformulas, i.e. skPxit in P has to synchronize with rPkxit in Pk where Pk is a directsubformula of P . Let i ∈ {1, . . . , n}. The following connectors, for k ∈ {1, 2}, realizethe synchronizations needed to propagate the information to switch a variable.set xi true P → Pk := {skPxit, rPkxit}set xi false P → Pk := {skPxif, rPkxif}If the QBF H is true, we need all components to be in one fixed state – thiswill be a state that models the assignment true. In fact, the component H ′ willobserve if H is true and reach a fixed state. To assure that all components canreach a fixed state, a similar technique as above is used. A component can set thetruth assignment of the components that represent its subformulas to true by thefollowing connector for k ∈ {1, 2}.set Pk true P → Pk := {skP t, rPkt}Consider a subformula of the form P = ∃xi.P1 ∈ K1 and the associated compo-nent x′i ∈ K2. The component representing P can assign x′i the truth value true orfalse and can ask x′i whether the current truth assignment is true or false. This isrealized byset x′i true := {sxit, rxit} ask truex′i := {xit, txi}set x′i false := {sxif, rxif} ask falsex′i := {xif, fxi}IF H ′ reaches a state that indicates that H was evaluated true or false, i.e. thesimulation of the evaluation of H is finished, then the unary connector evaluated :={endH′} becomes enabled.92Majster-Cederbaum, SemmelrockLet C be the set of connectors given by{eval P → Pk, P ask Pk true, P ask Pk false|P ∈ K1 ∪ {H ′} with succ. Pk}∪{set x′i true, set x′i false, ask truex′i , ask falsex′i |x′i ∈ K2}∪{set Pk true P → Pk|P ∈ K1 ∪ {H ′} with succ. Pk}∪{set xi true P → Pk, set xi false P → Pk|P ∈ K1with succ. Pk, i ∈ {1, . . . , n}}∪{evaluated}.So far we have the interaction model IMH := (KH , {AP }P∈KH , C). This wayany QBF formula H over the grammar, given above, can be mapped to an interac-tion model IMH .Remark 3.2 The interaction graph G∗H , associated to IMH , is a tree, as it isconstructed along the syntax tree and augmented with the components H ′ and x′ifor i = 1, . . . , n without forming cycles.3.1.5 Local BehaviorThe local behavior of the components is given by labeled transition systems. Everysystem has one state labeled t and one labeled f . These states model the fact thateither true respectively false was assigned to this component or it was evaluatedtrue respectively false. The initial state will be denoted by an ingoing arrow.Figure 3(a) depicts the transition system of the component modeling the jthoccurrence of variable xi. Figure 3(b) gives the local behavior of a component x′i ∈K2. The behavior of H ′ is given in 3(c). The transition systems for a variable xji anda x′i ∈ K2 are self-explanatory. If in TH′ the port e1H′ is performed, i.e. componentH needs to be evaluated, then TH′ waits to perform either sub1H′t or sub1H′f . Thisports can only be performed if TH reaches its state labeled t respectively f . It willbe shown that this indicates whether the associated QBF is true or false.tfrP xifrP xit,rP ttP ,aP ,rP xlt(l = 1, . . . , n),rP xlf(l 6= i)fP , aP ,rP xlf(l = 1, . . . , n),rP xlt(l 6= i)(a) P = xjitfrxifrxittxifxi(b) x′ifte1H′sub1H′ t sub1H′fs1H′tendH′endH′(c) H′Fig. 3. Transition systems Txjifor a component xji (a), Tx′ifor x′i (b) and TH′ for the component H′ (c).In Figure 4 the transition system for a component of the form P = ¬P1 ispictured. Note, that for better readability, the transition system in Figure 4(a)is not completely displayed. In system 4(a) the transitions and states pictured inFigure 4(b) and 4(c) have to be included between the states labeled t and f forl = 1, . . . , n.93Majster-Cederbaum, Semmelrockf te1Psub1P t sub1P faP aPfP tP(a) P = ¬P1f trP xltrPxlfrP xltrP xlfs1Pxlts1P xlf(b) Section of 4(a)and 5(a), for l ∈{1, . . . , n}f trP t rP ts1P t(c) Section of 4(a)Fig. 4. Main section of the transition systems T¬P1 (a), part of T¬P1 for l ∈ {1, . . . , n} (b), part of T¬P1(c).In Figure 5 the transition system for a component of the form P = ∃xi.P1is pictured. For better readability, the transition system in Figure 5(a) is notcompletely displayed. In system 5(a) the transitions and states pictured in Figure4(b) and 5(b) have to be included between the states labeled t and f for l = 1, . . . , n.tfsxits1P xitxite1Psub1P f sub1P tsxifs1P xifxifaPaPtPfP(a) P = ∃xi.P1f trP t rP tsxit, xit s1P t(b) Section of 5(a)Fig. 5. Main sections of the transition system T∃xi.P1 (a), part of T∃xi.P1 (b).In Figure 6 the transition system for a component of the form P = P1 ∧ P2 ispictured. Note, that the transition system in Figure 6(a) is not completely displayed.The transitions and states pictured in Figure 6(b) and 6(c) have to be includedbetween the states labeled t and f for l = 1, . . . , n.94Majster-Cederbaum, Semmelrockfte1Psub1P f sub1P taPe2Psub2P fsub2P taPfPtP(a) P = P1 ∧ P2f trP xltrP xlfrP xltrP xlfs1P xlts1P xlfs2P xlts2P xlf(b) Section of 6(a),for l ∈ {1, . . . , n}f trP t rP ts1P t s2P t(c) Section of 6(a)Fig. 6. Transition system TP1∧P2 .The resulting interaction system is denoted by SysH := (IMH , {TP }P∈KH ).Theorem 3.3 Let H be a QBF over the grammar P ::= x|¬P |P ∧ P |∃x.P andSysH the associated interaction system obtained from the reduction. Let qt be theglobal state in which all components are in their state labeled t, thenH ∈ TQBF ⇔ (SysH , qt) ∈ TRIST.The proof of Theorem 3.3 can be found in the Appendix of [14].4 QBF Reduction to Progress in Tree-Like InteractionSystemsBy minor modification of the reduction given above it is possible to show thePSPACE-completeness of the progress property in tree-like interaction systems. Atfirst we give some definitions to introduce progress in interaction systems and thengive an overview why it is PSPACE-complete to decide this property in tree-likeinteraction systems. In general interaction systems progress is PSPACE-complete[15], so progress in tree-like interaction systems is in PSPACE.Definition 4.1 Let Sys be an interaction system and T = (QSys, C,→, q0) theassociated global transition system. A global state q ∈ QSys is called a deadlock ifno connector is enabled in q, i.e. there is no c ∈ C and q′ ∈ QSys such that q c→ q′.A system Sys is free of deadlocks if there is no reachable state q ∈ QSys suchthat q is a deadlock.Definition 4.2 Let Sys be a deadlock-free interaction system. A run of Sys isan infinite sequence σq0c1→ q1 c2→ q2 . . . ,with ql ∈ QSys and cl ∈ C for l ≥ 1.95Majster-Cederbaum, SemmelrockDefinition 4.3 Let Sys be a deadlock-free interaction system with components K.k ∈ K may progress in Sys if for every run σ k participates infinitely often in σ.An instance of the progress problem in interaction systems is given by a tuple(Sys, k) where Sys is a deadlock-free interaction system with components K andk ∈ K. The question is if k may progress in Sys.We modify SysH as follows:We introduce an additional component called pro with the set of ports Apro :={tpro} and the behavior given by the transition system Tpro in Figure 7. The ideais to embed pro in SysH such that tpro will participate infinitely often in every runσ iff H is true.t tproFig. 7. Transition system Tpro for the component pro.In addition we modify the component H ′ as follows. The set of ports AH′ of thecomponent H ′ is now given byAH′ := {e1H′ , sub1H′t, sub1H′f, s1H′t, end trueH′ , end falseH′},i.e. endH′ is removed and the ports end trueH′ and end falseH′ are added. Themodified behavior of H ′ is given by the transition system TH′ in Figure 8.fte1H′sub1H′t sub1H′fs1H′ tend falseH′end trueH′Fig. 8. Modified transition system TH′ for the component H′.In addition, the connector evaluated is removed von the set C of connectors,and the two following connectors are added.evaluated true := {end trueH′ , tpro},evaluated false := {end falseH′}.It is easy to see that the connector evaluated true is the only connector that isenabled if the state qt is reached. In this case, evaluated true will perform in-finitely often, i.e. the component pro will participate infinitely often. Therefore thecomponent pro may progress iff H is true.5 Conclusion and Related WorkWe investigated a complexity issue for component-based systems. In [6] the reach-ability in 1-safe Petri nets was proven to be PSPACE-complete and [15] used this96Majster-Cederbaum, Semmelrockresult to show the PSPACE-completeness of the reachability problem in component-based systems. Here we restricted ourselves to tree-like systems and showed thateven in this class deciding reachability is PSPACE-complete.We conjecture that this result can be still strengthened such that it shouldbe possible to show that even for the class of linear interaction systems, wherethe interaction graph forms a sequence of components, the reachability problemis PSPACE-complete. Given these complexity issues it makes sense to look forconditions that can be tested in polynomial time and guarantee a desired property.For general component systems this is pursued e.g. in [1,2,10,11,13,16]. Fortree-like component systems [3,4,5,12] have followed this approach and in particularestablished conditions that ensure deadlock-freedom.References[1] Robert Allen and David Garlan. A Formal Basis for Architectural Connection. ACM Transactions onSoftware Engineering and Methodology, 6:213–249, 1997.[2] Paul Attie and Hana Chockler. Efficiently Verifiable Conditions for Deadlock-Freedom of LargeConcurrent Programs. In Proceedings of VMCAI’05, LNCS 3385, pages 465–481, 2005.[3] H. Baumeister, F. Hacklinger, R. Hennicker, A. Knapp, and M. Wirsing. A Component Model forArchitectural Programming. In Proceedings of FACS’05, volume 160 of ENTCS, pages 75–96. Elsevier,2006.[4] Marco Bernardo, Paolo Ciancarini, and Lorenzo Donatiello. Architecting Families of Software Systemswith Process Algebras. ACM Trans. on Software Engineering and Methodology, 11:386 – 426, October2002.[5] Stephen D. Brookes and A. W. Roscoe. Deadlock Analysis in Networks of Communicating Processes.Distributed Computing, 4:209–230, 1991.[6] Allan Cheng, Javier Esparza, and Jens Palsberg. Complexity Results for 1-safe Nets. In TheoreticalComputer Science, pages 326–337. Springer-Verlag, 1995.[7] M. R. Garey and D. S. Johnson. Computers and Intractability : A Guide to the Theory of NP-Completeness (Series of Books in the Mathematical Sciences). W. H. Freeman, January 1979.[8] Gregor Go¨ssler and Joseph Sifakis. Composition for Component-Based Modeling. Sci. Comput.Program., 55(1-3):161–183, 2005.[9] Charles A. R. Hoare. Communicating Sequential Processes. Prentice-Hall International series incomputer science. Prentice-Hall International, Englewood Cliffs, NJ [u.a.], 1985.[10] Paola Inverardi and Sebastia´n Uchitel. Proving Deadlock Freedom in Component-Based Programming.In FASE ’01: Proceedings of the 4th International Conference on Fundamental Approaches to SoftwareEngineering, pages 60–75, London, UK, 2001. Springer-Verlag.[11] M. Majster-Cederbaum, M. Martens, and C. Minnameier. A Polynomial-Time Checkable SufficientCondition for Deadlock-Freedom of Component-Based Systems. Lecture Notes in Computer Science,4362/2007:888–899, 2007.[12] Mila Majster-Cederbaum and Moritz Martens. Compositional Analysis of Deadlock-Freedom for Tree-Like Component Architectures. In EMSOFT ’08: Proceedings of the 7th ACM international conferenceon Embedded software, pages 199–206, New York, NY, USA, 2008. ACM.[13] Mila Majster-Cederbaum, Moritz Martens, and Christoph Minnameier. Liveness in Interaction Systems.Electron. Notes Theor. Comput. Sci., 215:57–74, 2008.[14] Mila Majster-Cederbaum and Nils Semmelrock. Reachability in Tree-Like Component Systems isPSPACE-Complete. Technical Report TR-2009-004, University of Mannheim, Germany, 2009.[15] Mila E. Majster-Cederbaum and Christoph Minnameier. Everything Is PSPACE-Complete inInteraction Systems. In ICTAC, pages 216–227, 2008.[16] Christoph Minnameier and Mila Majster-Cederbaum. Cross-Checking – Enhanced Over-Approximationof the Reachable Global State Space of Component-Based Systems, 2009. submitted for puplication.9798FACS 2009Composition of Servies with ConstraintsBalbiani, Cheikh1 ,2IRIT-CNRS, Toulouse, FraneHéam3LSV-CNRS-INRIA, Cahan, FraneKouhnarenko4INRIA-CASSIS-LIFC, Besançon, FraneAbstratComposition of Web servies onsists of the interleaving of the sequene of ations exeuted by the ele-mentary servies in aordane with a lient speiation. We model Web servies as automata exeutingations and also sending and reeiving messages. This paper provides a theoretial study for three servieomposition problems, and in partiular for the problem of omputing a Boolean formula whih exatlyharaterises the onditions required for servies to answer the lient's request. New omplexity results areestablished for these problems within the framework of servie omposition with onstraints.Keywords: Composition, Déidability.1 Introdution and Related WorkServie oriented omputing [23℄ is a programming paradigm whih onsiders ser-vies as elementary omponents. From these omponents, distributed appliationsare realised in aordane with a lient speiation. To realise some distributedappliations, elementary omponents have to be omposed. The omposition prob-lem has been investigated sine the 2000's with many solutions proposed [3,2,17℄.Often, servies are seen as nite automata. In this ase, the lient speiation isgiven by a nite automaton whih represents all omputations that a lient wantsthe servies to exeute. By exeuting their transitions, servies modify their envi-ronment and that of the lient. The problem of ombining servies beomes that of1Email: Philippe.Balbianiirit.fr2Email: Cheikirit.fr3Email: pheamlsv.ens-ahan.fr4Email: Olga.Kouhnarenkolif.univ-fomte.frThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs99Balbiani, Cheikh, Heam and Kouchnarenkoomposing automata, like in [3,2℄. In other ases, servies are able to send and toreeive messages. Client speiation is then given by a logial formula whih repre-sents lient's goals he wants servies to reah. By ommuniating together, serviesmodify their knowledge and those of their lient (see, e.g., [17℄). This paper followsthe line of reasoning suggested in [5,6,7,8℄, whih onsists in giving the semantisof servies by means of automata. The paper partiularly fouses on the followingproblem: Given servies A1, . . ., An and the request A of a lient, an A1, . . ., Anbe organised as to answer A? The originality of our approah onsists in modelingthe servies by Boolean automata, i.e. nite automata extended with parametriBoolean onditions. The main motivation for using this model is to manage ondi-tional ations or ommuniations of A1, . . ., An. For instane, a onditional ationmay be, for some i, j ∈ {1, . . . , n}, that Ai aepts to ommuniate with Aj if andonly if Aj has a seurity ertiate given by some authority. A onditional ationmay also be, for some i, j ∈ {1, . . . , n}, that Ai aepts to answer Aj only if the IPaddress of Aj is in a seleted area. This kind of onditions frequently appear whenspeifying servies. As far as we know, the omposition problems studied in theliterature do not handle this kind of onditions. This paper provides a theoretialstudy for three servie omposition problems, and in partiular for the problem ofomputing a Boolean formula φ whih exatly haraterises the onditions requiredfor A1, . . ., An to answer the lient's request. The paper is organised as follows.Setion 2 introdues the formal bakground. In Setion 3, we formally dene thevaluation deision problem, the Boolean formula deision problem and the Booleanformula synthesis problem for both simulation-based relations and trae-based re-lations. Setions 4 and 5 ontains our omplexity results. Finally we onlude insetion 6.Related Work In the ontext of nite automata, many researh works on omplex-ity results for various nite automata ompositions have been done.In [10℄, the authors investigated the following problem: given n +m nite au-tomata A1, . . . ,An+m, what is the omplexity of deiding whether A1 × . . .×An isequivalent to An+1× . . .×An+m. The lass of problems onsidered in [10℄ is for nonat systems, i.e. one requires that n ≥ 2 andm ≥ 2. Another ruial dierene w.r.t.our work onerns the produt. In [10℄, the produt is partially synhronised but,ontrarily to our work, synhronisation does not produe ε-transition but labeledtransitions. Their main result shows that the above deision problem is EXPTIME-hard for any relation between the simulation preorder and bisimulation, and that itis EXSPACE-hard for any relation between trae inlusion and the intersetion ofready trae equivalene.A more general problem is onsidered in [20℄ where the produt is loser to ourssine some ations an be hidden, i.e. replaed by an ε-transition. The author provedthat for non at systems the equivalene heking is PSPACE-hard for any relationbetween bisimilarity and trae equivalene, and that the problem is EXPSPACE-omplete for trae equivalene, and EXPTIME-omplete for bisimilarity. It wasalso onjetured in [20℄ that the problem is EXPTIME-hard for any relation be-tween bisimilarity and trae equivalene. This onjeture was enhaned and provedin [22℄: the problem is EXPTIME-hard for any relation between bisimilarity andtrae preorder.100Balbiani, Cheikh, Heam and KouchnarenkoIn [15℄, it is shown that deiding whether A is simulated by A1× . . .×An is stillEXPTIME-hard. In this work, the onsidered produt is asynhronous.Several reent works fous on the use of nite automata based models to addressWeb servies omposition problems. In [18,17℄, the authors propose a model whereWeb servies ompositions expressed in BPEL are formally dened by state transi-tion systems with ommuniating and internal (unobservable) ations. In [17℄, thismodel was enrihed using a knowledge base, and in [9℄ using a theory. These ap-proahes were applied to pratial appliations in [24,12,11℄. In [1,21℄, Web serviesare dened by PWL-S douments and modelled by guarded nite automata. A sim-ilar approah is investigated in [16℄ where Web servies are dened in BPEL. In [14℄,the authors model by Input/Output automata Web servies interfaes desribed inBPEL, OWLS and WSDL.2 PreliminariesLet P be a nite set of Boolean variables (with typial members denoted p, p′, . . .),Σa be a ountable set of asynhronous ations (with typial members denoted α,β, . . .) and Σs be a ountable set of synhronous ations (with typial membersdenoted σ, τ , . . .). We will assume that P , Σa and Σs are disjoint.Finite automataA nite automaton is a tuple A = (Q,E, I, F ) where• Q is a nite set of states,• E is a funtion from Q×Q into the set of all nite subsets of Σa∪({?, !}×Σs)∪{ǫ},• I ⊆ Q is the set of initial states and F ⊆ Q is the set of nal states.For all x ∈ {?, !}, for all σ ∈ Σs, (x, σ) will be denoted xσ.A is said to be ǫ-free i E is a funtion from Q × Q into the set of all nitesubsets of Σa ∪ ({?, !} × Σs). We shall say that A is weakly asynhronous i Eis a funtion from Q × Q into the set of all nite subsets of Σa ∪ {ǫ}. A is saidto be strongly asynhronous i E is a funtion from Q × Q into the set of allnite subsets of Σa. Given a weakly asynhronous automaton A, let E∗ be thefuntion from Q × Q into the set of all nite subsets of Σa suh that for all q, r ∈Q, for all α ∈ Σa, α ∈ E∗(q, r) i there are sequenes (q0, q1, . . . , qm), (r0, r1, . . . ,rn) ∈ Q+ suh that•for all positive integers i, if i ≤ m then ǫ ∈ E(qi−1, qi),•for all positive integers j, if j ≤ n then ǫ ∈ E(rj−1, rj),• α ∈ E(qm, r0),• q0 = q and rn = r.In this ase, a run of A on a sequene (α1, . . . , αk) ∈ Σ∗a is a sequene (q0, q1, . . . ,qk) ∈ Q+ suh that for all positive integers i, if i ≤ k then αi ∈ E∗(qi−1, qi), q0 ∈I and qk ∈ F . Moreover, the traes of A, denoted tr(A), is the set of all sequenes(α1, . . . , αk) ∈ Σ∗a suh that there is a run of A on (α1, . . . , αk).101Balbiani, Cheikh, Heam and KouchnarenkoA1 : q1 q2(p1 ∨ p2, α)(¬p2, !σ1)(¬p1 ∧ p2, ?σ2)A2 : r1 r2(p3, ?σ1)(¬p3, α)Figure 1. Boolean automata A1 and A2.Boolean automataThe set B(P ) of all Boolean formulas (with typial members denoted φ, ψ, . . .)is dened by: φ ::= p | ⊥ | ¬φ | (φ ∨ φ), with p ∈ P . The other onstruts aredened as usual. In partiular, ⊤ = ¬⊥ and (φ ∧ ψ) = ¬(¬φ ∨ ¬ψ). A valuationis a funtion from P into {0, 1}. Every valuation V gives rise to a funtion V̂ fromB(P ) into {0, 1} in the usual way. A Boolean automaton is a tuple A = (Q,E, I, F )where• Q is a nite set of states,• E is a funtion from Q×Q into the set of all nite subsets of B(P )×(Σa∪({?, !}×Σs) ∪ {ǫ}),• I ⊆ Q is the set of initial states and F ⊆ Q is the set of nal states.The notions of ǫ-freeness, weak asynhroniity and strong asynhroniity aredened for Boolean automata in the same way as they are dened for nite automata.As example, take the ase of the Boolean automata A1 and A2 from Fig. 1, withΣa = {α} and Σs = {σ1, σ2}.SynhronisationLet A1 = (Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn) be ǫ-free Boolean automata.Their synhronisation, denoted A1 ⊗ . . .⊗An, is the weakly asynhronous Booleanautomaton A = (Q,E, I, F ) dened by:• Q = Q1 × . . .×Qn,• E is the funtion from Q×Q into the set of all nite subsets of B(P )× (Σa∪{ǫ})suh that for all q, r ∈ Q, for all φ ∈ B(P ),· for all α ∈ Σa, (φ, α) ∈ E(q, r) i there is i ∈ {1, . . . , n} suh that q ≡i r and(φ, α) ∈ Ei(qi, ri),· (φ, ǫ) ∈ E(q, r) i there are i1, i2 ∈ {1, . . . , n}, there are φi1 , φi2 ∈ B(P ),there is σ ∈ Σs suh that i1 6= i2, q ≡i1,i2 r, either (φi1 , (?, σ)) ∈ Ei1(qi1, ri1)and (φi2 , (!, σ)) ∈ Ei2(qi2 , ri2) or (φi1 , (!, σ)) ∈ Ei1(qi1 , ri1) and (φi2 , (?, σ)) ∈Ei2(qi2 , ri2) and φ = φi1 ∧ φi2 .• I = I1 × . . . × In and F = F1 × . . . × Fn,the binary relations ≡i,≡i1,i2 ⊆ Q× Q being suh that for all q, r ∈ Q, q ≡i r ifor all j ∈ {1, . . . , n}, if i 6= j then qj = rj and q ≡i1,i2 r i for all j ∈ {1, . . . , n},if i1 6= j and i2 6= j then qj = rj. Consider, as example, the Boolean automata A1and A2 from Fig. 1 and A1 ⊗A2 from Fig. 2.102Balbiani, Cheikh, Heam and Kouchnarenkoq1, r1 q2, r1 q1, r2 q2, r2(p1 ∨ p2, α)(p3 ∧ ¬p2, ǫ)(p1 ∨ p2, α)(¬p3, α) (¬p3, α)Figure 2. Boolean automata A1 ⊗A2.A : q1 q2(p1 ∨ p2, α)(¬p2, !σ1)(¬p1 ∧ p2, ?σ2)V (p1) = 0, V (p2) = 1AV : q1 q2α?σ2Figure 3. Boolean automaton A and the assoiated automaton AV .From Boolean automata to nite automataLet A = (Q,E, I, F ) be a Boolean automaton and V be a valuation. The inter-pretation of A through V , denoted AV , is the nite automaton A′ = (Q′, E′, I ′, F ′)dened by:• Q′ = Q,• E′ is the funtion from Q′ ×Q′ into the set of all nite subsets of Σa ∪ ({?, !} ×Σs) ∪ {ǫ} suh that for all q, r ∈ Q′,· for all α ∈ Σa, α ∈ E′(q, r) i there is φ ∈ B(P ) suh that (φ, α) ∈ E(q, r) andV̂ (φ) = 1,· for all x ∈ {?, !}, for all σ ∈ Σs, xσ ∈ E′(q, r) i there is φ ∈ B(P ) suh that(φ, xσ) ∈ E(q, r) and V̂ (φ) = 1,· ǫ ∈ E′(q, r) i there is φ ∈ B(P ) suh that (φ, ǫ) ∈ E(q, r) and V̂ (φ) = 1,• I ′ = I and F ′ = F .As example, take the ase of A and AV from Fig. 3.Trae inlusion and trae equivaleneLet A = (Q,E, I, F ), A′ = (Q′, E′, I ′, F ′) be weakly asynhronous nite au-tomata. We shall say that A is trae-inluded in A′, denoted A ⊑ A′, i tr(A) ⊆tr(A′). A is said to be trae-equivalent to A′, denoted A ≡ A′, i A ⊑ A′ and A′⊑ A.Simulation and bisimulationLet A = (Q,E, I, F ), A′ = (Q′, E′, I ′, F ′) be weakly asynhronous nite au-tomata. We dene a binary relation Z ⊆ Q × Q′ suh that dom(Z) ∩ I 6= ∅ andran(Z)∩ I ′ 6= ∅ to be a simulation of A by A′, denoted Z: A ←− A′, i for all q ∈103Balbiani, Cheikh, Heam and KouchnarenkoQ, for all q′ ∈ Q′, if q Z q′ then•for all α ∈ Σa, for all r ∈ Q, if α ∈ E∗(q, r) then there is r′ ∈ Q′ suh that r Zr′ and α ∈ E′∗(q′, r′),•if q ∈ I then q′ ∈ I ′ and if q ∈ F then q′ ∈ F ′.Note: dom(Z) and ran(Z) respetively denote the domain of Z and the range of Z.If there is a simulation Z of A by A′ then we write A ←− A′. We dene a binaryrelation Z ⊆ Q×Q′ to be a bisimulation between A and A′, denoted Z: A ←→ A′,i Z: A ←− A′ and Z−1: A′ ←− A. If there is a bisimulation between A and A′then we write A ←→ A′.3 Composition of Servies3.1 Formal denitionsLet R ∈ {⊑,≡,←−,←→}. The valuation deision (VD) problem for R is denedby:•input: a strongly asynhronous nite automaton A = (Q,E, I, F ) and ǫ-freeBoolean automata A1 = (Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn),•output: hek if there is a valuation V suh that A R (A1 ⊗ . . . ⊗An)V .The Boolean formula deision (BFD) problem for R is dened by:•input: a strongly asynhronous nite automaton A = (Q,E, I, F ), ǫ-free Booleanautomata A1 = (Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn) and a Boolean formulaφ,•output: hek if for all valuations V , A R (A1 ⊗ . . .⊗An)V i V̂ (φ) = 1.The Boolean formula synthesis (BFS) problem for R is dened by:•input: a strongly asynhronous nite automaton A = (Q,E, I, F ) and ǫ-freeBoolean automata A1 = (Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn),•output: nd out a Boolean formula φ suh that for all valuations V , A R (A1 ⊗. . .⊗An)V i V̂ (φ) = 1.The questions we are interested in are: Is there a valuation of these servies suhthat the desired omposition is possible (VD problem)? How to ompute a booleanformula φ over these prediates that is true i the desired omposition is possible(BFS problem)?3.2 Motivating ExampleConsider three servies S1, S2, S3.Servie S1 provides an on-line booking for European football math plaes thatwill take plae in Madrid. This servie is modeled by the automaton A1 in Fig. 4.When S1 reeives a request for a football plae (ticket_req) booking, it hekswhether there is available plaes having the desired prie (ation c_v). This hekan be done if and only if the request is provided by a non blak listed supporter(prediate ¬pblack). If there is no available plae, S1 informs the requester by the104Balbiani, Cheikh, Heam and KouchnarenkoA1 : q1 q2(⊤, ticket_req) (¬pblack, c_v)q3 q4(⊤, !ask_bank1)(⊤, no_ticket)q5(⊤, ?resp_bank1)(⊤, send_ticket)Figure 4. Boolean automaton A1A2 : q1 q2(⊤, flight_req) (psh ∨ pnat, c_f)q3 q4(⊤, !ask_bank2)(⊤, no_flight)q5(⊤, ?resp_bank2)(⊤, send_flight)Figure 5. Boolean automaton A2A3 : q1q2(pcert1, ?ask_bank1)q3(pcc ∨ ppp, pay_ok)q4(pcert2, ?ask_bank2)q5(pcc ∨ ppp, pay_ok)(⊤, !resp_bank1)(⊤, !resp_bank2)Figure 6. Boolean automaton A3ation no_ticket. If there is a tiket, S1 asks the bank servie (S3) for the tiketpayment (ations !ask_bank1). If the bank answers the payment is Ok (message?resp_bank1), the tiket is sent to the requester (ation send_ticket).Servie S2 sells ight tikets. It is modeled by the automaton A2 in Fig. 5.S2 works like S1 but sells tikets only for people who do not need a Visa foroming to Spain, thus either people whose nationality is in a given list (prediatepnat), or if the starting point of the ight is in the Shengen Spae (prediate psh).The servie S3 is the bank servie modeled by the automaton A3 in Fig. 6.S3 aepts request from servies having a seurity ertiate (prediate pcertimeans that Si has suh a ertiate). Then, if the buyer has either a redit ard(prediate pcc) or a paypal aount (prediate ppp), and if the payment is OK (inorder to not overload the example, we do not model this ommuniating point; wejust enode it by the ation pay_ok), the bank validates the payment to the relatedservie.As the reader an see, servies an be omposed to provide the intented servieS (depited in Fig. 7), with several onditions on the value of prediates pnat, pcert1,,et.105Balbiani, Cheikh, Heam and KouchnarenkoA : q1 q2ticket_reqq3c_vno_ticketq4flight_reqq5c_fno_flightq6pay_okpay_okq7send_ticketsend_flightFigure 7. Automaton A4 Trae Inlusion and Trae EquivaleneLet us reall that given two nite automata A1 and A2, testing whether A1 ⊑ (A2an be done in PSPACE.Upper boundLet A = (Q,E, I, F ) be a strongly asynhronous nite automaton and A1 =(Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn) be ǫ-free Boolean automata. We now de-ne a deterministi algorithm whih returns the value aept i there is a valuationV suh that A ⊑ (A1 ⊗ . . . ⊗An)V :(i) for all valuations V(a) ompute (A1 ⊗ . . . ⊗An)V ;(b) hek if A ⊑ (A1 ⊗ . . .⊗An)V ;(ii) if one of these alls returns the value aept then return the value aeptelse return the value rejet;Obviously, the deterministi algorithm above is exponential-spae-bounded. Simi-larly, an exponential-spae-bounded deterministi algorithm whih returns the valueaept i there is a valuation V suh that A ≡ (A1 ⊗ . . .⊗An)V an be dened.As a result,Proposition 4.1 Let R ∈ {⊑,≡}. The VD problem for R is in EXPSPACE.Similarly,Proposition 4.2 Let R ∈ {⊑,≡}. The BFD problem for R is in EXPSPACE.Let A = (Q,E, I, F ) be a strongly asynhronous nite automaton and A1 =(Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn) be ǫ-free Boolean automata. We nowdene a deterministi algorithm whih returns a Boolean formula φ suh that for allvaluations V , A ⊑ (A1 ⊗ . . .⊗An)V i V̂ (φ) = 1:(i) φ := ⊥;(ii) for all maximal onsistent onjuntions ψ of P -literals(a) ompute the unique valuation V suh that V̂ (ψ) = 1;(b) ompute (A1 ⊗ . . . ⊗An)V ;() if A ⊑ (A1 ⊗ . . .⊗An)V then φ := φ ∨ ψ;Obviously, the deterministi algorithm above is exponential-spae-bounded. Simi-larly, an exponential-spae-bounded deterministi algorithm whih returns a Boolean106Balbiani, Cheikh, Heam and Kouchnarenkoformula φ suh that for all valuations V , A ≡ (A1⊗ . . .⊗An)V i V̂ (φ) = 1 an bedened. As a result,Proposition 4.3 Let R ∈ {⊑,≡}. The BFS problem for R is solvable by means ofan exponential-spae-bounded deterministi algorithm.Lower boundTo prove that the VD problem for ⊑ is EXPSPACE-hard, we give a polynomialtime redution of the universality problem for regular expressions with squaring,whih is known to be EXPSPACE-hard [13℄, to the VD problem for ⊑. The set ofall regular expressions with squaring (with typial members denoted exp, exp′, . . .)is dened by:exp ::= α | ǫ | (exp ◦ exp) | (exp ∪ exp) | exp+ | exp2.The number of ourrenes of operators ǫ, ◦, ∪, + and 2 in regular expression exp withsquaring is denoted op(exp). Every regular expression exp with squaring gives riseto a language denoted lang(exp) in the usual way. Let σ1, σ2, . . . be an enumerationof Σs. Given a regular expression exp with squaring, let n = 2× op(exp). Let A =(Q,E, I, F ) be the strongly asynhronous nite automaton dened as follows: Q ={q}, E is the funtion from Q×Q into the set of all nite subsets of B(P )×Σa suhthat for all q, r ∈ Q, for all φ ∈ B(P ), for all α ∈ Σa, (φ, α) ∈ E(q, r) i φ = ⊤, I ={q} and F = {q}. For all positive integers i, if i ≤ n then let Ai = (Qi, Ei, Ii, Fi) bethe ǫ-free Boolean automaton dened as follows: Qi = {q1i, q2i}, Ei is the funtionfrom Qi×Qi into the set of all nite subsets of B(P )× (Σa∪ ({?, !}×Σs)) suh thatfor all q, r ∈ Qi, for all φ ∈ B(P ),•for all α ∈ Σa, (φ, α) 6∈ Ei(q, r),•for all x ∈ {?, !}, for all σ ∈ Σs, (φ, xσ) ∈ Ei(q, r) i φ = ⊤, x = ?, σ = σi, q =q1i and r = q2i or φ = ⊤, x = !, σ = σi, q = q2i and r = q1i,Ii = {q1i} and Fi = {q2i}. Let A0 = (Q0, E0, I0, F0) be the ǫ-free Boolean automatondened by indution on exp as follows:Basis: Case exp = α. In this ase, A0 = (Q0, E0, I0, F0) is dened as follows: Q0= {qI , qF}, E0 is the funtion from Q0 × Q0 into the set of all nite subsets ofB(P )× (Σa ∪ ({?, !} × Σs)) suh that for all q, r ∈ Q0, for all φ ∈ B(P ),•for all β ∈ Σa, (φ, β) ∈ E0(q, r) i q = qI , r = qF , φ = ⊤ and β = α,•for all x ∈ {?, !}, for all σ ∈ Σs, (φ, xσ) 6∈ E0(q, r),I0 = {qI} and F0 = {qF }. The Boolean automaton A0 is represented in Fig. 8. Thereader may easily verify that for all valuations V , lang(exp) = tr(AV0 ). Remarkthat 0 = n. Note also that I0 and F0 are singletons.qI qF(⊤, α)Figure 8. Finite automaton A0 in the ase exp = α.107Balbiani, Cheikh, Heam and KouchnarenkoHypothesis: exp′ and exp′′ are regular expressions with squaring suh that thereis an ǫ-free Boolean automaton A′0 = (Q′0, E′0, I ′0, F ′0) suh that for all valuationsV , lang(exp′) = tr((A′0 ⊗ A1 ⊗ . . . ⊗ An′)V ) where n′ = 2 × op(exp′) and thereis an ǫ-free Boolean automaton A′′0 = (Q′′0 , E′′0 , I ′′0 , F ′′0 ) suh that for all valuationsV , lang(exp′′) = tr((A′′0 ⊗A1 ⊗ . . . ⊗An′′)V ) where n′′ = q × op(exp′′). We alsoassume that I ′0, F ′0, I ′′0 and F ′′0 are singletons.Step: The ases exp = ǫ, exp = exp′ ◦ exp′′, exp = exp′ ∪ exp′′ and exp = exp′+are similar.Case exp = exp′2. In this ase, A0 = (Q0, E0, I0, F0) is dened as follows: Q0 =Q′0∪{qI , q, r, qF }, E0 is the funtion from Q0×Q0 into the set of all nite subsetsof B(P )× (Σa ∪ ({?, !} × Σs)) suh that for all s, t ∈ Q0, for all φ ∈ B(P ),•for all β ∈ Σa, (φ, β) ∈ E0(s, t) i s, t ∈ Q′0 and (φ, β) ∈ E′0(s, t),•for all x ∈ {?, !}, for all σ ∈ Σs, (φ, xσ) ∈ E0(s, t) i s, t ∈ Q′0 and (φ, xσ) ∈E′0(s, t) or s = qI , t = q′I , φ = ⊤, x = ! and σ = σn′+1 or s = q′F , t = q, φ =⊤, x = ! and σ = σn′+2 or s = q, t = qI , φ = ⊤, x = ? and σ = σn′+1 or s =q′F , t = r, φ = ⊤, x = ? and σ = σn′+2 or s = r, t = qF , φ = ⊤, x = ? and σ= σn′+1,I0 = {qI} and F0 = {qF}. The Boolean automaton A0 is represented in Fig. 9.The reader may easily verify that for all valuations V , lang(exp) = tr((A0⊗A1⊗. . .⊗An′ ⊗An′+1⊗An′+2)V ). Remark that n′+2 = n. Note also that I0 and F0are singletons.A′0qI q′I q′Fr qFq(⊤, !σn′+1)(⊤, ?σn′+2)(⊤, !σn′+2)(⊤, ?σn′+1)(⊤, ?σn′+1)Figure 9. Finite automaton A0 in the ase exp = exp′2.The reader may easily verify that lang(exp) = Σ∗a i there is a valuation V suh thatA ⊑ (A0 ⊗A1 ⊗ . . .⊗An)V . Similarly, the reader may easily verify that lang(exp)= Σ∗a i there is a valuation V suh that A ≡ (A0 ⊗A1 ⊗ . . .⊗An)V . As a result,Proposition 4.4 Let R ∈ {⊑,≡}. The VD problem for R is EXPSPACE-hard.Similarly,Proposition 4.5 Let R ∈ {⊑,≡}. The BFD problem for R is EXPSPACE-hard.Aording to Meyer and Stokmeyer [13℄, for all deterministi Turing mahinesM solving the universality problem for regular expressions with squaring, there exists108Balbiani, Cheikh, Heam and Kouchnarenkoa onstant c > 1 suh that M needs at least spae cn on some input of length n forinnitely many n. Suppose that there is a deterministi algorithm f solving the BFSproblem for R and suh that for all onstants c > 1, f needs at least spae cn onsome input of length n for nitely many n only. Let Mf be the deterministi Turingmahine that behaves as follows given a regular expression exp with squaring:(i) Mf omputes n = 2× op(exp);(ii) Mf omputes the strongly asynhronous nite automaton A = (Q,E, I, F )dened as above;(iii) for all positive integers i, if i ≤ n then Mf omputes the ǫ-free Boolean au-tomaton Ai = (Qi, Ei, Ii, Fi) dened as above;(iv) Mf omputes the ǫ-free Boolean automaton A0 = (Q0, E0, I0, F0) dened byindution on exp as above;(v) Mf simulates f on input A and A0 and A1, . . ., An until it is about to returna value φf ;(vi) if φf is a Boolean tautology then return the value aept else return the valuerejet;Obviously, Mf solves the universality problem for regular expressions with squaringand for all onstants c > 1 Mf needs at least spae cn on some input of length n fornitely many n only: a ontradition. As a result,Proposition 4.6 Let R ∈ {⊑,≡}. For all deterministi algorithms f solving theBFS problem for R, there exist a onstant c > 1, suh that f needs at least spae cnon some input of length n for innitely many n.5 Simulation and BisimulationLet us reall that given two nite automata A1 and A2, testing whether A1 simulatesA2 an be done in polynomial time.Upper boundLet A = (Q,E, I, F ) be a strongly asynhronous nite automaton and A1 =(Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn) be ǫ-free Boolean automata. We now de-ne a deterministi algorithm whih returns the value aept i there is a valuationV suh that A ←− (A1 ⊗ . . .⊗An)V :(i) for all valuations V(a) ompute (A1 ⊗ . . . ⊗An)V ;(b) hek if A ←− (A1 ⊗ . . .⊗An)V ;(ii) if one of these alls returns the value aept then return the value aeptelse return the value rejet;Obviously, the deterministi algorithm above is exponential-time-bounded. Simi-larly, an exponential-time-bounded deterministi algorithm whih returns the valueaept i there is a valuation V suh that A ←→ (A1⊗ . . .⊗An)V an be dened.As a result,Proposition 5.1 Let R ∈ {←−,←→}. The VD problem for R is in EXPTIME.109Balbiani, Cheikh, Heam and KouchnarenkoLet A = (Q,E, I, F ) be a strongly asynhronous nite automaton, A1 =(Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn) be ǫ-free Boolean automata and φ bea Boolean formula. We now dene a deterministi algorithm whih returns thevalue aept i for all valuations V , A ←− (A1 ⊗ . . .⊗An)V i V̂ (φ) = 1:(i) for all valuations V(a) ompute (A1 ⊗ . . . ⊗An)V ;(b) ompute V̂ (φ);() hek if A ←− (A1 ⊗ . . .⊗An)V i V̂ (φ) = 1;(ii) if all these alls returns the value aept then return the value aept elsereturn the value rejet.Obviously, the deterministi algorithm above is exponential-time-bounded. Simi-larly, an exponential-time-bounded deterministi algorithm whih returns the valueaept i for all valuations V , A←→ (A1⊗ . . .⊗An)V i V̂ (φ) = 1 an be dened.Proposition 5.2 Let R ∈ {←−,←→}. The BFD problem for R is in EXPTIME.Let A = (Q,E, I, F ) be a strongly asynhronous nite automaton and A1 =(Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn) be ǫ-free Boolean automata. We nowdene a deterministi algorithm whih returns a Boolean formula φ suh that for allvaluations V , A ←− (A1 ⊗ . . . ⊗An)V i V̂ (φ) = 1:(i) φ := ⊥;(ii) for all maximal onsistent onjuntions ψ of P -literals(a) ompute the unique valuation V suh that V̂ (ψ) = 1;(b) ompute (A1 ⊗ . . . ⊗An)V ;() if A ←− (A1 ⊗ . . .⊗An)V then φ := φ ∨ ψ;Obviously, the deterministi algorithm above is exponential-time-bounded. Simi-larly, an exponential-time-bounded deterministi algorithm whih returns a Booleanformula φ suh that for all valuations V , A ←→ (A1 ⊗ . . .⊗An)V i V̂ (φ) = 1 anbe dened. As a result,Proposition 5.3 Let R ∈ {←−,←→}. The BFS problem for R is solvable by meansof an exponential-time-bounded deterministi algorithm.Lower boundBy giving a polynomial time redution of the simulation problem of a stronglyasynhronous nite automaton by means of a produt of strongly asynhronous niteautomata, whih is known to be EXPTIME-hard [15℄, to the VD problem for←−,we prove that the VD problem for ←− is EXPTIME-hard. Given a stronglyasynhronous nite automaton A = (Q,E, I, F ) and strongly asynhronous niteautomata A1 = (Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn), let A′1 = (Q′1, E′1, I ′1, F ′1),. . ., A′n = (Q′n, E′n, I ′n, F ′n) be the ǫ-free Boolean automata dened as follows: Q′i =Qi, E′i is the funtion from Q′i×Q′i into the set of all nite subsets of B(P )× (Σa ∪({?, !} × Σs)) suh that for all q, r ∈ Q′i, for all φ ∈ B(P ),•for all α ∈ Σa, (φ, α) ∈ E′i(q, r) i φ = ⊤ and α ∈ Ei(q, r),110Balbiani, Cheikh, Heam and Kouchnarenko•for all x ∈ {?, !}, for all σ ∈ Σs, (φ, xσ) 6∈ E′i(q, r),I ′i = Ii and F′i = Fi. The reader may easily verify that A ←− A1⊗ . . .⊗An i thereis a valuation V suh that A ←− (A′1 ⊗ . . .⊗A′n)V . As a result,Proposition 5.4 The VD problem for ←− is EXPTIME-hard.Similarly,Proposition 5.5 The BFD problem for ←− is EXPTIME-hard.Proof We prove that the Boolean formula deision problem for←− is EXPTIME-hard by giving a polynomial time redution of the simulation problem of astrongly asynhronous nite automaton by means of a produt of stronglyasynhronous nite automata, whih is known to be EXPTIME-hard [15℄,to the Boolean formula deision problem for ←−. Given a strongly asyn-hronous nite automaton A = (Q,E, I, F ) and strongly asynhronous nite au-tomata A1 = (Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn), let A′1 = (Q′1, E′1, I ′1,F ′1), . . ., A′n = (Q′n, E′n, I ′n, F ′n) be the ǫ-free Boolean automaton dened as aboveand φ = ⊤. Suppose that A ←− A1 ⊗ . . . ⊗An. Hene, there is a simulation Z ofA by A1 ⊗ . . . ⊗ An. Let V be a valuation. Obviously, Z is a simulation of A by(A′1⊗ . . .⊗A′n)V . Therefore, for all valuations V , A ←− (A′1⊗ . . .⊗A′n)V i V̂ (φ) =1. Reiproally, suppose that for all valuations V , A←− (A′1⊗ . . .⊗A′n)V i V̂ (φ) =1. Let V be a valuation. Thus, there is a simulation Z of A by (A′1⊗. . .⊗A′n)V . Ob-viously, Z is a simulation of A by A1⊗. . .⊗An. Consequently, A←−A1⊗. . .⊗An.2We prove that the VD problem for←→ is PSPACE-hard by giving a polynomialtime redution of the aeptane problem of a linear-spae-bounded deterministiTuring mahine, whih is known to be PSPACE-hard, to the VD problem for←→. Let acc, α1, α2, . . . be an enumeration of Σa. Given a linear-spae-boundeddeterministi Turing mahineM = (QM , q0M , q1M ,ΣM , δM ) and a word w ∈ Σ∗M , let nbe the length ofw. Let Σf = {acc, α1, . . . , αn}. Let A = (Q,E, I, F ) be the stronglyasynhronous nite automaton dened as follows: Q = (QM ×{1, . . . , n})∪ {⊥}, Eis the funtion from Q×Q into the set of all nite subsets of B(P )× Σf suh thatfor all (q, i), (r, j) ∈ Q, for all φ ∈ B(P ),•for all α ∈ Σf , (φ, α) ∈ E((q, i), (r, j)) i φ = ⊤, α = αi and there are u, v ∈ ΣM ,there is d ∈ {−1,+1} suh that δM (q, u, r, v, d) is dened and j = i+ d or φ = ⊤,α = acc, q = q1M , r = q1M and j = i,•for all α ∈ Σf , (φ, α) ∈ E((q, i),⊥) i φ = ⊤, α 6= acc and α 6= αi or for all r ∈QM , for all u, v ∈ ΣM , for all d ∈ {−1,+1}, δM (q, u, r, v, d) is not dened,•for all α ∈ Σf , (φ, α) 6∈ E(⊥, (r, j)),•for all α ∈ Σf , (φ, α) ∈ E(⊥,⊥) i φ = ⊤ and α 6= acc,I = {(q0M , 1)} and F = ∅. Let A1 = (Q1, E1, I1, F1), . . ., An = (Qn, En, In, Fn) bethe ǫ-free Boolean automata dened as follows: Qi = (QM ×ΣM) ∪ {⊥i}, Ei is thefuntion from Qi×Qi into the set of all nite subsets of B(P )× (Σf ∪ ({?, !}×Σs))suh that for all (q, u), (r, v) ∈ Qi, for all φ ∈ B(P ),•for all α ∈ Σf , (φ, α) ∈ Ei((q, u), (r, v)) i φ = ⊤, α = αi and there is d ∈ {−1,+1}suh that δM (q, u, r, v, d) is dened,111Balbiani, Cheikh, Heam and Kouchnarenko•for all α ∈ Σf , (φ, α) ∈ Ei((q, u),⊥i) i φ = ⊤, α 6= acc and α 6= αi or for all r∈ QM , for all v ∈ ΣM , for all d ∈ {−1,+1}, δM (q, u, r, v, d) is not dened,•for all α ∈ Σf , (φ, α) 6∈ Ei(⊥i, (r, v)),•for all α ∈ Σf , (φ, α) ∈ Ei(⊥i,⊥i) i φ = ⊤ and α 6= acc,•for all x ∈ {?, !}, for all σ ∈ Σs, (φ, xσ) 6∈ Ei((q, u), (r, v)),•for all x ∈ {?, !}, for all σ ∈ Σs, (φ, xσ) 6∈ Ei((q, u),⊥i),•for all x ∈ {?, !}, for all σ ∈ Σs, (φ, xσ) 6∈ Ei(⊥i, (r, v)),•for all x ∈ {?, !}, for all σ ∈ Σs, (φ, xσ) 6∈ Ei(⊥i,⊥i),Ii = {(q0M , wi)} and Fi = ∅. Suppose that M does not aept w. Let Z ⊆ Q ×(Q1 × . . .×Qn) be the binary relation suh that• (q, i) Z ((q1, u1), . . . , (qn, un)) i q = qi and (q0M , 1,w) =⇒∗M (q, i, u1 . . . un),• · Z (·, . . . , ·,⊥i, ·, . . . , ·),• ⊥ Z (·, . . . , ·).The reader may easily verify that there is a valuation V suh that Z is a bisimulationbetween A and (A1 ⊗ . . . ⊗ An)V . Hene, there is a valuation V suh that A ←→(A1 ⊗ . . . ⊗ An)V . Reiproally, suppose that there is a valuation V suh thatA ←→ (A1 ⊗ . . . ⊗ An)V . Therefore, there is a bisimulation Z between A and(A1 ⊗ . . .⊗An)V . Obviously, M does not aept w.Proposition 5.6 The VD problem for ←→ is PSPACE-hard. The BFD problemfor ←→ is PSPACE-hard.6 ConlusionThis paper presented dierent new omplexity results for the VD problem and theBFD problem within the framework of servie omposition with onstraints. To sumup, the results are given in snapshot of our work below.R valuation deision problem Boolean formula deision problem≡ EXPSPACE-omplete EXPSPACE-omplete⊆ EXPSPACE-omplete EXPSPACE-omplete← EXPTIME-omplete EXPTIME-omplete↔ PSPACE-hard PSPACE-hardin EXPTIME in EXPTIMEAs pointed out by the above table, a still open question is to evaluate the exat om-plexity of the valuation deision problem for ←→ and the Boolean formula deisionproblem for ←→: are they in PSPACE or are they EXPTIME-hard? Moreover,we foused on the identiation of a relevant abstration to manage onditionalations in the servie omposition problem. In the future, we intend to explorepratial algorithmi approahes to handle the Boolean formula synthesis problem.112Balbiani, Cheikh, Heam and KouchnarenkoReferenes[1℄ Berardi, D., D. Calvanese, G. De Giaomo, R. Hull, M. Meella: Automati omposition of transition-based semanti Web servies with messaging. In: Very Large Data Bases. ACM (2005) 613624.[2℄ Berardi, D., D. Calvanese, G. De Giaomo, M. Lenzerini, M. Meella: Automati servies ompositionbased on behavioral desriptions. Int. Journal of Cooperative Information Systems 14 (2005) 333376.[3℄ Berardi, D., F. Cheikh, G. De Giaomo, F. Patrizi: Automati servie omposition via simulation. Int.Journal of Foundations of Computer Siene 19 (2008) 429451.[4℄ Berardi, D., M. Pistore, P. Traverso: Automati Web servie omposition by on-the-y belief spaesearh. In: Proeedings of ICAPS'06, (2006) 358361.[5℄ Foster, H.: A Rigorous Approah to Engineering Web Servie Compositions. Thesis of the Universityof London (2006).[6℄ Foster, H., S. Uhitel, J. Magee, J. Kramer: WS-Engineer: a model-based approah to engineering Webservie ompositions and horeography. In: Test and Analysis of Web Servies. Springer (2007) 87119.[7℄ Fu, X., T. Bultan, J. Su: Analysis of interating BPEL Web servies. In: Int. World Wide WebConferene. ACM (2004) 621630.[8℄ Héam, P.-C., O. Kouhnarenko, J. Voinot: How to handle QoS aspets in Web servies substitutivityveriation. In: Enabling Tehnologies: Infrastruture for Collaborative Enterprises. IEEE (2007) 333338.[9℄ Homan, J., P. Bertoli, M. Pistore: Web servie omposition as planning, revisited. In: Proeeedings ofAAAI'07 AAAI (2007) 10131018.[10℄ Laroussinie, F., Ph. Shnoebelen: The state explosion problem from trae to bisimulation equivalene.In: Foundations of Software Siene and Computational Strutures. Springer (2007) 192207.[11℄ Maroni, A., M. Pistore, P. Poianti, P. Traverso: Automated Web servie omposition at work: theamazon/mps ase study In: Proeedings of ICWS'07, IEEE, (2007) 767774.[12℄ Maroni, A., M. Pistore, P. Traverso: Automated omposition of Web servies: the astro approah In:IEEE Data Engineering Bulletin 31 (2008) 2326.[13℄ Meyer, A., L. Stokmeyer: The equivalene problem for regular expressions with squaring requiresexponential spae. In: Swithing and Automata Theory. IEEE (1972) 125129.[14℄ Mitra, S., R.J. Kumar, S. Basu: Automates CHoregrapher Synthesis for Web servie omposition usingI/O Automata. In: Proeedings of ICWS'07 IEEE (2007) 364371.[15℄ Musholl, A., I. Walukiewiz: A lower bound on Web servies omposition. In: Foundations of SoftwareSiene and Computational Strutures. Springer (2007) 274286.[16℄ Pathak, J., S. Basu, R. Lutz, V. Honavar: Parallel web servie omposition in mosoe: A horegraphybased approah. In: Proeedings of ECOWS'96, IEEE (2006) 312.[17℄ Pistore, M., A. Maroni, P. Bertoli, P. Traverso: Automated omposition of Web servies by planningat the knowledge level. In: Pro. of the 19th Int. Joint Conf. on Artiial Intelligene (2005) 12521259.[18℄ Pistore, M., P. Traverso, P. Bertoli: Automated omposition of Web servies by planning inasynhronous domains. In: Proeedings of ICAPS'05, AAAI, (2005) 212.[19℄ Pistore, M., P. Traverso, P. Bertoli, A. Maroni: Automated synthesis of omposite BPEL4WS webservies.. In: Proeedings of ICWS'05, IEEE, (2005) 293301.[20℄ Rabinovih, A.: Complexity of equivalene problems for onurrent systems of nite agents. In:Information and Computation (1997). volume 139, 111129.[21℄ Sardina, S., F. Patrizi, G. De Giaomo:Behaviour omposition in the presene of failure. In: Proeedingsof KR'08, AAAI, (2008). 640650.[22℄ Sawa, D.: Equivalene Cheking of Non-at Systems Is EXPTIME-Hard. In: Int. Conf. on ConurrenyTheory. Springer (2003), 237250.[23℄ Singh, M., M. Huhns: Servie-Oriented Computing. Semantis, Proess, Agents. Wiley (2005).[24℄ Trainotti, M., M. Pistore, G. Calabrese, G. Zao, G. Luhese, F. Barbon, P. Bertoli, P. Traverso:Sipporting omposition and exeution of Web servies. In: Proeedings of ICSOC'05, Springer, (2005).495501.113114FACS 2009Using Assertions to Enhance the Correctness ofKmelia Components and their AssembliesPascal André, Gilles Ardourel, Christian Attiogbé,Arnaud LanoixLINA CNRS UMR 6241 - University of Nantes2, rue de la HoussinièreF-44322 Nantes Cedex, FranceEmail: {FirstName.LastName}@univ-nantes.frAbstractThe Kmelia component model is an abstract formal component model based on services. It is dedicated tothe specification and development of correct components. This work enriches the Kmelia language to allowthe description of data, expressions and assertions when specifying components and services. The objectiveis to enable the use of assertions in Kmelia in order to support expressive service descriptions, to supportclient/supplier contracts with pre/post-conditions, and to enhance formal analysis of component-basedsystem. Assertions are used to perfom analysis of services, component assemblies and service compositions.We illustrate the work with the verification of consistency properties involving data at component andassembly levels.Keywords: Component, Assembly, Datatype, Assertions, Property Verification1 IntroductionThe Kmelia component model [7] is an abstract formal component model dedicatedto the specification and development of correct components. A formal componentmodel is mandatory to check various kind of properties for component-based softwaresystems: correctness, liveness, safety; to find components and services in librariesaccording to their formal requirements; to refine models or to generate code. Thekey concepts of Kmelia are component, service, assembly and composition. Oneimportant feature is the use of services as first class entities. A service has a state,a dynamic behaviour which may include communication actions, an interface madeof required and provided subservices. The composition of components is based onthe interaction between their linked services. Linking components by their servicesin component assemblies establishes a bridge to service oriented abstract models.In [7] we introduced the syntax and semantics for the core model and language. Ithas been incrementally enriched later. We mainly focused on the dynamic aspects ofcomposition: interaction compatibility in [7] and component protocols with servicecomposition in [6]. Following this incremental approach, we consider in this articleThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs115Andre et al.an enrichment of the data and expressions in the kmelia model and its impact onthe language syntax, its semantics and the verification of properties. Our guidingobjective is twofold: 1) enable the definition of assertions (with invariant, pre/postconditions, and properties of services, components, and compositions), 2) increasethe expressiveness of the action statements so as to deal with real size case studies.Assertions are useful (i) to define contracts 1 on services; contracts increase theconfidence in assembly correctness and they are a pertinent information when lookingfor candidates for a required service, (ii) to ensure the consistency of componentsrespecting the invariant. The actions implement a functional part of the serviceswhich should then be proved to be consistent with the contracts. Therefore thecorrectness verification aspects of the Kmelia model is enhanced.Motivations. Modelling real life systems requires the use of data types to handlestates, actions and property descriptions. The state of the art shows that most of theabstract components models [4,13,24,12]. They enable various verifications of theinteraction correctness but they lack expressiveness on the data types and do notprovide assertions mechanisms and the related verification rules. As an example,in Wright the dynamic part based on CSP is largely detailed (specification andverification) while the data part is minor [4]. In the proposal of [22] the data typesare defined using algebraic specifications, which are convenient to marry with thesymbolic model checking of state transition systems but this proposal does not dealwith contracts and assertions.Contribution. In this work, we enrich the Kmelia model with data and assertionsat the service and composition levels in order to deal with safe services, componentconsistency and assembly contracts. First, the Kmelia language is enriched withdata and assertions so as to cover in an homogeneous way structural, dynamic andfunctional correctness with respect to assertions. Second, we deal with state spacevisibility and access through different levels of nested components; in addition toservice promotion we define variable promotions and the related access rules fromcomponent state in component compositions. Last, feasibility of proving componentcorrectness using the assertions is presented. We show how structural correctness isverified and how the associated properties are expressed with the new data language.To design it , we have established a trade off 2 between the desired expressivenessof our language and the verification concerns. To avoid the separation of analysistools and to work on the same abstract model, we advocate for an approach whereboth data and dynamic part are integrated in a unique Kmelia language.The article is structured as follows. Section 2 gives an overview of the Kmeliaabstract model and introduces its new features. In Section 3 a working example isintroduced to illustrate the use of data and assertions. The formal analysis issueis treated in Section 4; we present various analysis to be performed and we focuson component consistency and on checking assembly links. The formal analysis arebased on the formal descriptions of Section 2 also many details are omitted in thispaper. Section 5 concludes the article and draws some discussions and perspectives.1 Our contract definitions are related to classical results of works such as design-by-contracts [20].2 We thought to encapsulate statements from other formal data languages such as Z, B, OCL or CASL,with the idea to reuse existing tool supports for checking syntax and properties. That approach was notconvincing due to a lack of expressiveness, or a weak tool support or integration problems.116Andre et al.2 The Kmelia Model and its new FeaturesWe enriched the Kmelia language of [7] to allow the description of datatypes, ex-pressions and first order logic predicates. This section revisits the Kmelia model,focusing on its new features.2.1 Data types and expressionsWe enrich the Kmelia language by designing a small but expressive data language.This enables us to deal homogeneously with the expression of the properties relatedto the component level and to the composition level.Basic types such as Integer , Boolean, Char, String with their usual operatorsand semantics are permitted. Abstract data types like record, enumeration, range,arrays and sets are allowed in Kmelia. User-defined record types are built over theabove basic types. Specific types and functions may be defined and imported fromlibraries. A Kmelia expression is built with constants, variables and elementaryexpressions built with standard arithmetic and logical operators. An assignment ismade of a variable at the left hand side and an expression at the right hand side.Assertions (pre-/post-conditions and invariants) are first order logic predicates.In a post-condition of a service, the keyword old is used to distinguish the before andafter variable states. This is close to OCL’s pre or Eiffel’s old keywords. Guardsin the service behaviour are also predicates. All the assertions must conform to anobservability policy described in Section 2.3.2.2 ComponentsA component is one element of a component type. A component is referenced witha variable typed using the component type; for example c :C where c is a variableand C a component type. The access to a state variable v of c is denoted c .v.A component type C is a 8-tuple 〈W,A,N ,M, I,D, ν, CS〉 with:• W = 〈T, V, type, Inv, Init〉 the state space where T is a set of types, V a set ofvariables, type : V → T the function that map variables to types, Inv an invariantdefined on V and Init the initialisation of the variables of V .• A a finite set of elementary actions (based on the expressions).• N a finite set of service names with NP (provided services) and NR (requiredservices) two disjoint finite sets of names 3 : N = NP unionmultiNR.• M a finite set of message names.• I = IP unionmultiIR the component interface which is the union of two disjoint finite setsof names IP and IR such that IP ⊆ NP ∧ IR ⊆ NR.• D is the set of service descriptions with the disjoint provided services (DP ) andrequired services (DR) sets: D = DP unionmulti DR.• ν : N → D is the function mapping service names to service descriptions. More-over there is a projection of the N partition on its image by ν:s ∈ NP ⇒ ν(s) ∈ DP ∧ s ∈ NR ⇒ ν(s) ∈ DR3 unionmulti denotes the disjoint union of sets117Andre et al.• CS is a set of constraints related to the services of the interface of C in order tocontrol the usage of the services.Observability of the component state. To preserve the abstraction and en-capsulation of components, the state of a component is accessed only through itsprovided services. Nevertheless to understand the specification of a service (i.e. itscontract) we need to observe its context (an exposed part of its component statespace). Similarly a composite component requires observable informations from itscomponents. Therefore we define V O as the subset of the observable variables of V .Consequently the state invariant Inv is composed of an observable (InvO defined onV O) and a non-observable part. The notion of observability is also applied to servicepre/post conditions with the specific rules described in section 2.3. Observability isa kind of visibility related to contracts.2.3 ServicesThe behaviour of a component relies on the behaviours of its services which area kind of concurrent processes. A service models a functionality activated by acall. An activated service runs its behaviour and shares the component state withother activated services of the same component. During its evolution a service mayactivate other services by calling them or communicate with them by messages. Dueto dependencies and interactions between services, the actions of several activatedservices may interleave or synchronise. Only one action of an activated service maybe observed at time. Formally a service s of a component with type C 4 is definedby a 3-tuple 〈IS, lW,B〉 with:• The service interface IS is defined by a 6-tuple 〈σ, µ, vW, P re, Post,DI〉 where· σ is the service signature 〈name, param, ptype, Tres〉 with name ∈ N , parama set of parameters, ptype : param → T the function mapping parameters totypes and Tres ∈ T the service result type;· vW = 〈vT, vV, vtype, vInv, vInit〉 is a virtual state space with vT a set of types,vV a set of variables, vtype : vV → vT the function mapping context variables totypes and vInv an invariant defined on vV and vInit the optional initialisationof the variables of vV ;· µ is a set of message signatures 〈mname,mparam,mptype〉 wheremname ∈M,mparam and mptype are similar to those of the service signature;· Pre is a pre-condition defined on the union of the variables in V, vV, andparam: V ∪ vV ∪ param;· Post is a post-condition defined on V ∪ vV ∪ param ∪ { result }, where thepredefined result variable of type Tres denotes the service result;· DI is the service dependency ; it is composed by services on which the currentservice depends. DI is a 4-tuple 〈sub, cal, req, int〉 of disjoint sets wheresub ⊆ N P (resp. cal ⊆ NR, req ⊆ NR, int ⊆ N P ) contains the providedservices names (resp. the ones required from the caller, from any component orfrom the component itself) in the scope of s.4 and by extension a service of a component c : C118Andre et al.• lW = 〈lT, lV, ltype, lInv, lInit〉 is the local state space where lT is a set of types,lV a set of local variables, ltype : lV → lT the function mapping local variables totypes, lInv a local state invariant defined on lV (mostly lInv = true) and lInitthe initialisation of the variables of lV .• The behaviour B of a service s is an extended labelled transition system (eLTS) withstate and transitions. The necessary details are given on the example of Section 3.The full background is provided online in references [7,6].The state space lW local to a service is used only in the service behaviour B butnot used in the assertions.Virtual state spaces. A required service is an abstraction of a service provided byanother component. Since that component is unknown when specifying the requiredservice, it may be necessary to describe this “imaginary” component. We introducethe notion of a virtual state space vW in order to abstract the service context. Fora provided service this virtual context is always empty.Observability vs. service state space. Let s be a service of a component type C.The distinction between observable and non-observable variables of the componentstate space is revisited 5 according to the following table:Service Variables Invariantstate space Observable part Non-observable part Observable part Non-observable partProvided s V O V InvO InvRequired s vV V vInv InvThe pre-/post-conditions of s must respect the well-formedness rules related tothe observable, non-observable and virtual contexts according to the following table:Service pre-condition post-conditionAssertions Observable Non-observable Observable Non-observablescope PreO PreNO PostO PostNOProvided s V O ∪ param none V O ∪ param ∪ { result } V ∪ param ∪ { result }Required s vV ∪ param V ∪ param vV ∪ param ∪ { result } noneFigure 1 summarises (in the context of a composition as described in Section 2.4)the relations between state spaces, observability and contracts. The boxes denotecomponents (a, b) and compositions (c). The grey (resp. white) "funnel" denoteprovided (resp. required) services.prov Ba : Aprov ApreOpost NOpost Oreq AC_VO Vint Areq BpreOpost OvVb : BC_VO Vprov Bvmapreq Ac : CObservabilityFunction callService callAssemblylinkPromotionlinkpreNOMappingFig. 1. State variables scope and assertion scope5 it is not a partition here because of the supplementary variables in param and result119Andre et al.The observable pre-/post-conditions of service provA (resp. reqB) refer to theobservable state V O of a (resp. the virtual state vV of reqB). These conditions willbe used to check the contracts implicitly supported by the assembly links and thecomposition links. In particular the virtual state vV of reqB should map with a sub-set of V of a. Non-observable pre-conditions (resp. post-conditions) are meaninglessfor a provided service (resp. required service) because they prevent safe assemblyand promotion contracts. The non-observable pre-condition of service reqB givescall conditions on the (caller) component state variablesV of b. The non-observablepost-condition of service provA refer locally to the whole state V of a and shouldestablish the non-observable part of the invariant of a.2.4 Assembly and CompositionAn assembly is a set of components that are linked (horizontal composition) throughtheir services. An assembly is one element of an assembly type. An assembly linkassociates a required service to a provided one. Considering the rich interface of aKmelia service (see 2.3), we need an explicit matching mechanism, to link properlythe 6-tuples defining given service interfaces; therefore, additionally to signaturesand dependency (via sublinks) mapping we now define context and message map-pings. When needed, message or service parameters re-ordering must be handledthrough adaptation mechanisms [5].Assembly context and message mapping. Consider a required service sr of acomponent cr of type CR linked to a provided service sp of another component cpof type CP . The virtual state space variables (vVsr) of sr must be “instantiated”using the observable variables of sp (V OCP ) by a mapping (total) function vmap :vVsr → exp(V OCP ) where exp(X) denotes an expression over the variables of X.Each message name of sr is mapped to a message name of sp by a mapping (total)function mmap : mnamesr → mnamesp.A composition is the encapsulation of an assembly into a component (the compos-ite) where some features (variables and services) of the nested components can bepromoted at the composite level. Promotion links are used to promote services. Themappings and rules are similar to the ones of assembly, they are not detailed here.State variables promotion. An observable variable vo ∈ V OC from a compo-nent c : C can be promoted as a variable vp ∈ VCP of a composite componentcp : CP . Formally, there are a function prom : VCP → V OC which establishes thevariable promotion, i.e. a bridge between the variable names. In the Kmelia syntax,(vp, vo) ∈ prom, is written vp FROM c.vo. The promoted variables retain their types(type(vp) = type(vo)) and are accessed (read-only at the composite level) in theireffective contexts using a service of the sub-component that defines the variables.This guarantees the encapsulation principle.Now Kmelia services are equipped with expressive means (pre-/post-conditions,observability, virtual context) to describe contracts. Section 3 illustrates them ona working example. They are used to check services and assemblies correctness asdescribed in Section 4.120Andre et al.3 A Working ExampleThe example is a simplified Stock Management application including a vending mainservice. This process manages product references (catalog) and product storage(stock). Administrators have specific rights, they can add or remove referencesunder some consistency business rules such as: a new reference must not be in thecatalog or a removable reference must have an empty stock level.Function callService callAssemblylinkPromotionlinkvendingauthorisationsm : StockManagerdeleteReferencestoreorderauthorisationgetNewReferencedisplay ...newReferenceask_codeincreaseItemremoveItemdecreaseItemaddItemcodeve : VendorvendingStockSystemFig. 2. Simplified Assembly of the Stock Case StudyThe system is designed as a reusable component type StockSystem. It encapsu-lates an assembly of two components: sm:StockManager and ve:Vendor. The formeris the core business component to manage references and storage. The latter is thesystem access interface. The main vending service is promoted at the StockSystemlevel. In this paper we focus only on the addItem and newReference services. Ac-cording to the vending service, a user may add a new item in the stock managementusing the required service addItem of the Vendor component.r equ i r ed addItem ( ) : I n t e g e rI n t e r f a c esubprov ides : { code }V i r t ua l Va r i ab l e sc a t a l o g F u l l : Boolean ;cata logEmpty : Boolean // p o s s i b l y c a t a l o g S i z eV i r t ua l I n v a r i a n t not ( cata logEmpty and c a t a l o g F u l l )Pre not c a t a l o g F u l l//No LTSPost ( Re s u l t <> noRe f e r ence ) i m p l i e s ( not cata logEmpty )EndThe required service addItem is fulfilled with the provided service newReferencewhich gets a new reference and performs the update of the system if there is anavailable new reference (see the listing 2). The links and sublinks are explicitlydefined in the composition part of a composite component, as detailed in the listing 3.The nested services represent the service dependency DI. For example, therequired service addItem provides a special code subservice 6 . Similarly the providedservice newReference requires a ask_code service from its caller (see the calrequiresdeclaration in the interface of newReference in the listing 1).Inside the components, the different arrows represent various kind of calls: func-tion call (with no side effects), service call (according to the service dependency).6 In Kmelia, a subservice of a service s, is a service that belongs to the interface (subprovides) of s.121Andre et al.The newReference service calls the display function (declared in the predefined Kmelialibrary), a service getNewReference required internally (from the same component)and the ask_code service required to its caller.Data types in Kmelia. The data types are explicitly defined in a TYPES clauseor in the shared libraries (predefined or user-defined). As an example, the followinglibrary (named Stocklib ) declares some specific types, functions and constants.TYPESProduct I tem : : s t r u c t { i d : I n t e g e r ; desc : S t r i n g ; qu an t i t y : I n t e g e r } ;CONSTANTSmaxRef : I n t e g e r := 100 ;emptySt r i ng : S t r i n g := "" ;noRe f e r ence : I n t e g e r := −1 ;noQuant i ty : I n t e g e r := −1These data types in this part are quite concrete; more abstract data types are in theprocess to be included in the predefined library.A Kmelia component and observable state. The listing 1 is an extract fromthe Kmelia specification of the StockManager component. The state of StockManagerdeclares among the other variables, the observable variable catalog which can beused for context mapping in the assembly links but also in promoted variables forcomposite components. Two arrays ( plabels and pstock) are used to stock the labelsof current references and their available quantity. The invariant states that: thecatalog has an upper bound; all references in the catalog have a label and a quantity;the unknown references have no entries in the two arrays pstock and plabels . Theassertions in Kmelia are possibly named predicates; the labels in front of the invariantlines are names used in this specification.Listing 1: Kmelia specification StockManager StateCOMPONENT StockManagerINTERFACEprov ides : { newRefe rence , r emoveRe fe rence , s t o r e I t em , o rd e r I t em }r e qu i r e s : { a u t h o r i s a t i o n }USES {STOCKLIB}TYPESRe f e r en c e : : range 1 . .maxRefVARIABLESvendorCodes : setOf I n t e g e r ; // a u t h o r i s e d a dm i n i s t r a t o r sobs c a t a l o g : setOf Re f e r en c e ; // product i d = i n d e x o f the a r r a y sp l a b e l s : ar ray [ R e f e r en c e ] o f S t r i n g ; // produc t d e s c r i p t i o nps tock : ar ray [ R e f e r en c e ] o f I n t e g e r // produc t q u an t i t yINVARIANTobs @borned : s i z e ( c a t a l o g ) <= maxRef ,@re f e r e n c ed : f o r a l l r e f : Re f e r en c e | i n c l u d e s ( c a t a l o g , r e f ) i m p l i e s( p l a b e l s [ r e f ] <> emptySt r i ng and ps tock [ r e f ] <> noQuant i ty ) ,@no t r e f e r e n c ed : f o r a l l r e f : Re f e r en c e | e x c l u d e s ( c a t a l o g , r e f ) i m p l i e s( p l a b e l s [ r e f ] = emptySt r i ng and ps tock [ r e f ] = noQuant i ty )INITIALIZATIONc a t a l o g := emptySet ;vendorCodes := emptySet ; // f i l l e d by a r e q u i r e d s e r v i c ep l a b e l s:= a r r a y I n i t ( p l a b e l s , emptySt r i ng ) ; // c o n s i s t e n t w i th . .ps tock := a r r a y I n i t ( p s tock , noQuant i ty ) ; // . . empty c a t a l o gA Kmelia service with its assertions. The listing 2 gives the specification ofthe provided service newReference. It provides a new reference if its running goeswell. The pre-condition is that the catalog does not reach its maximal size. Thepost-condition is decomposed into several observable/non-observable named parts.122Andre et al.It states that we may have a result ranging in 1. .maxRef or no reference at all, inthe latter case the catalog remains unchanged.Listing 2: Kmelia specification Provided Service with assertionsprov ided newRefe rence ( ) : I n t e g e r // Re su l t = Produc t Id or noRe f e r enceI n t e r f a c ec a l r e q u i r e s : {ask_code} #r e q u i r e d from the c a l l e ri n t r e q u i r e s : { getNewReference }Preobs s i z e ( c a t a l o g ) < maxRef #the c a t a l o g i s not f u l lVar i ab l e s # l o c a l to the s e r v i c ec : I n t e g e r ; # c : i n pu t code g i v en by the u s e rr e s : Re f e r en c e ;d : S t r i n g ; # produc t d e s c r i p t i o nI n i t i a l i z a t i o nr e s := noQuant i ty ;BehaviorI n i t i # the i n i t i a l s t a t eF ina l f # a f i n a l s t a t e{ i −− c := __CALLER ! ! ask_code ( ) −−> e1 ,# ge t s the password on the ask_code ( s e r v i c e ) channe le1 −− [ not ( c i n vendorCodes ) ]d i s p l a y (" add ing a r e f e r e n c e i s not a l l owed ") −−> end ,e1 −− [ c i n vendorCodes ] __CALLER ? msg(d ) −−> e2 ,# ge t s the p roduc t d e s c r i p t i o ne2 −− [ d = emptySt r i ng ]d i s p l a y (" add ing an EmptySet d e s c r i p t i o n i s not a l l owed ") −−> end ,e2 −− [ d <> emptySt r i ng ] r e s := __SELF ! ! getNewReference ( ) −−> e4 ,e4 −− { c a t a l o g := i n c l u d i n g ( c a t a l o g , r e s ) ; //add new r e f e r e n c eps tock [ r e s ] := 0 ; // d e f a u l t s t o ck i s n u l lp l a b e l s [ r e s ] := d // produc t d e s c r i p t i o n i s the one p r o v i d ed}−−> end ,end −− __CALLER ! ! newRefe rence ( r e s ) −−> f# the c a l l e r i s i n fo rmed from the Re s u l t and the s e r v i c e ends .}Postobs @resu l tRange : ( ( Re s u l t >= 1 and Re su l t <= maxRef ) or ( Re s u l t = noRe f e r ence ) ) ,obs @r e s u l tVa l u e : ( Re s u l t <> noRe f e r ence ) i m p l i e s ( no t I n ( o l d ( c a t a l o g ) , Re su l t )and c a t a l o g = add ( o l d ( c a t a l o g ) , Re su l t ) ) ,obs @no r e su l tVa l u e : ( Re s u l t = noRe f e r ence ) i m p l i e s Unchanged{ c a t a l o g } ,@refAndQuant i ty : ( Re s u l t <> noRe f e r ence ) i m p l i e s( p s tock [ R e s u l t ] = 0 and p l a b e l s [ R e s u l t ] <> emptySt r i ng and( f o r a l l i : Re f e r en c e | ( i <> Re su l t ) i m p l i e s( p s tock [ i ] = o l d ( p s tock ) [ i ] and p l a b e l s [ i ] = o l d ( p l a b e l s ) [ i ] ) ) ) ,@NorefAndQuant ity : ( Re s u l t = noRe f e r ence ) i m p l i e s Unchanged{ ps tock , p l a b e l s }The behaviour of a service defines a list of transitions e1 −−label−−> e2 wheree1 and e2 are state names. A transition label is a guarded combination of actions[guard] action∗. An action is either an elementary action from A (expression) ora communication action (service interaction). The syntax of a communication ac-tion is channel( ! | ? | ? | !! ) message(param∗) where the channel denotes a referencein the service dependency DI, the single char operators are message interactions(send/receive) and the double char operators are service interactions (call, result).The channel _CALLER stands for the caller service, _SELF stands for a service ofthe same component (internal call), _rs stands for a required service. In this articlewe will not consider further the behaviour.Context and message mappings. The context and message mappings (see 2.4)are specified in assembly links. In the listing 3, variables of the virtual contextof addItem are associated with an expression on the variables of the context ofnewReference i.e. the observable state variables of the component sm. In this exam-ple, there are no message mapping because only the standard msg message (declaredin the predefined Kmelia library) is used.123Andre et al.Listing 3: Kmelia specification StockSystemCOMPONENT StockSystemINTERFACEprov ides : { vend ing }r e qu i r e s : { a u t h o r i s a t i o n }COMPOSITIONAssemblyComponentssm : StockManager ;ve : VendorLinks // ////////// assemb ly l i n k s //////////l r e f : p−r sm . newRefe rence , ve . addItemcon t e x t mappingve . cata logEmpty == empty (sm . c a t a l o g ) ,ve . c a t a l o g F u l l == s i z e (sm . c a t a l o g ) = MaxInts u b l i n k s : { l c od e }l c od e : r−p sm . ask_code , ve . code. . .End // assemb lyPromotionL inks // ////////// promot ion l i n k s //////////l v end : p−p ve . vend ing , SELF . vend ingl a u t : r−r sm . a u t h o r i s a t i o n , SELF . a u t h o r i s a t i o nEND_COMPOSITIONIn the next section, we show how this Kmelia specification is analysed using ourCOSTO 7 tool and a specific verification approach using the B method and tools.4 Formal Analysis and ExperimentationsComponents, assemblies and compositions should be analysed according to variousfacets. Tables 1 and 2 give an overview of the verification requirements that weconsider to validate a Kmelia specification. Some of them were achieved before, inparticular the behavioural compatibility of services and components, treated in [7]:it was achieved using model-checking techniques provided by existing tools (Loto-s/CADP 8 and MEC 9 ); the involved parts of the Kmelia specifications were auto-matically translated into the input languages of these tools and checked.In this section, we address aspects related to data type checking and assertionchecking; the main goal is to analyse parts of a Kmelia specification using its newfeatures such as the assertions. Formal verification tools are necessary to checkassertions consistency. Our approach consists in reusing existing tools such as theB tools and especially the Rodin 10 framework. We design a systematic verificationmethod that enables us to reuse the proof obligations generated by the B tools forour specific purpose.Event-B and Rodin framework. Rodin is a framework made of several toolsdedicated to the specification and proof of Event-B models. Event-B [1] extends theclassical B method [2] with specific constructions and usage; it is intended to themodelling of general purpose systems and for reasoning on them. Proof obligations(POs) are generated to ensure the consistency of the considered model, i.e. thepreservation of the INVARIANT by the EVENTS. Other POs ensure that a refinedmodel is consistent, i.e. the abstract INVARIANT is preserved and the refined events7 COmponent Study TOolkit dedicated to the Kmelia language8 http://www.inrialpes.fr/vasy/cadp/9 http://altarica.labri.fr/wiki/tools:mec_410http://rodin-b-sharp.sourceforge.net124Andre et al.Analysis StatusStatic rules: Scope + name resolution + type-checking doneObservability rules in progress (see 2.3)Component interface consistency doneServices dependency consistency:DI well-formed vs. I and D (component) doneDI vs. B (eLTS)Simple constraint checking (parameters, query, protocol, . . . ) in progressLocal eLTS checking (deadlocks, guard, subprovides, . . . ) in progressInvariant consistency vs. pre/post conditions:provided services : InvO ∧ PreO ⇒ PostO ∧ InvO experimental (a)Inv ∧ Pre⇒ PostNO ∧ Inv experimental (b)required services : vInv ∧ PreO ⇒ PostO ∧ vInv experimental (c)Consistency between service assertions and eLTS: not yeteLTS vs. Post the post condition should be establishedrequired service R calls vs. PreR the context must ensure the precondition(local+virtual)eLTS vs. subprovided service SP annotations PreSP the context mustensure the precondition (local)Table 1Formal analysis of a simple Kmelia componentAnalysis StateStatic rules: Scope + name resolution + type-checking doneObservability rules: promoted variables doneLink/sublink consistency: assembly and composition done [7]signature matchingservice dependency matching (subprovides, callrequires)context mapping (cm function) and observability rulesmessage mappingAssembly Link Contract correctness:cm(PreOR)⇒ PreOP experimental (d)PostOP ⇒ cm(PostOR) experimental (e)Provided Promotion Link Contract correctness: PP is at the compositelevelcm(PreOP P )⇒ PreOP experimental (f)PostOP ⇒ cm(PostOPP ) experimental (g)Required Promotion Link Contract correctness: RR is at the compositelevelcm(PreOR)⇒ PreORR experimental (h)PostORR ⇒ cm(PostOR) experimental (i)eLTS (behaviour) compatibility done [7]Table 2Formal analysis of a Kmelia assembly and compositionsdo not contradict their abstract counterparts.POs can be discharged automatically or interactively, using the Rodin provers.Verifying Kmelia specifications using Event-B. The main idea is, first to con-sider a part of the Kmelia specification involved in the property to be verified (aservice, a component, a link of an assembly, an assembly, etc), then to build fromthis part of the specification, a set of (Event-)B models in such a way that the POsgenerated for them correspond to the specific obligations we needed to check theKmelia specification assertions. Using B to validate components assembly contracts125Andre et al.has been investigated in [15,18].We systematically 11 build some Event-B models, with an appropriate structureas explained below, to check some of the proof obligations presented in Tables 1and 2. The Event-B models are currently built by hand.(i) For each component and its provided services, we generate an Event-B model.The proof of the consistency of this model ensures the proof of the rules (a)and (b) for the invariant consistency at the Kmelia level.(ii) For each required service (and its “virtual context”) we have to generate anEvent-B model. Its B consistency establishes the rule (c).(iii) For each assembly link between a required service req and a provided one prov,we give an Event-B model of the observable part of prov, which refines theEvent-B model of the required service req previously checked.• the consistency proof of the Event-B model ensures the rule (a) for the in-variant consistency at the Kmelia level;• the refinement proof establishes both the rules (d) and (e) for the Kmeliaassembly correctness.Fig. 3. RodinWe are not going to deal in this article with the details of the translation pro-cedure 12 . Kmelia invariant and pre-condition translations are quite systematic,whereas the post-condition concept does not exist into the B language. There-fore we abstract the post-condition by using an ANY substitution that satisfiesthe post-condition (once translated) as proposed in the context of UML/OCL to B11applying defined rules which are not yet fully automatised12The specifications and results are available in http://www.lina.sciences.univ-nantes.fr/coloss/projects/kmelia/index_en.php126Andre et al.translations [19]. Figure 3 depicts the Event-B translation into Rodin of the servicenewReference of StockManager.Experimental results. Applying our method on the case study presented in Sec-tion 3, we obtain the Event-B models structured as depicted in Fig 4. These modelsare studied within Rodin; it tooks a few hours to write and check the models.We can verify the Kmelia components StockManager and Vendor before checkingthe assembly StockSystem. The Event-B model StockManager is used to prove thepreservation of the invariant assertions by the provided services. The refinementv_addItem_sm_newReference is used to check the assembly link between the ser-vices newReference and addItem. The Table 3 gives an idea about the number ofPOs that are to be discharged to ensure the correctness of the Kmelia specification.Studying the example within Rodin revealed some errors in our initial Kmeliaspecification. For example, the post-condition of newReference was wrong; one ofthe associated POs could not be discharged. After the feedback in our Kmelia spec-ifications, the error was corrected.MODEL StockManager_ ask_codeEVENTS ask_codeREFINEMENT sm_ask_code_ v_codeEVENTS code_obs SEESREFINEMENT v_addItem_ sm_newReferenceVARIABLES catalogEVENTS newReference_obs CONTEXT StockLibCONSTANTS References MaxRef NullInt NoQuantity NoReference......from KmeliaStockManagercomponentfrom KmeliaVendor componentMODEL StockManagerVARIABLES vendorCodes catalog plabels pstockEVENTS newReference deleteReference store order getNewReferenceMODEL VendorVARIABLES orders vendoridEVENTS vending codeMODEL Vendor_ addItemVARIABLES catalogFull catalogEmptyEVENTS addItemSEESREFINES REFINESFig. 4. Event-B ModelsAuto. Manual TotalStockManager 16 3 19Vendor_addItem 2 1 3v_addItem_sm_newReference22 1 23Table 3Rodin Proof obligationsIn a general manner, the assertions associated to Kmelia services help us to ensurethe correctness of the assembly link by considering the required-provided relationshipas a refinement from the required service to the provided one. When the assertionsare wrong, the proofs fail, which means the assembly link is wrong.5 Discussion and ConclusionIn this article we have presented enrichments to the Kmelia abstract componentmodel: a data language for Kmelia expressions and predicates; visibility features forcomponent state in the context of composite components; contracts in the compo-sition of services. The formal specification and analysis of the model are revisitedaccordingly. The syntactic analysis of Kmelia is effective in the COSTO tool thatsupports the Kmelia model. We have proposed a method to perform the necessaryassertions verification using B tools: the contracts are checked through preliminaryexperimentations using the Rodin framework. We have illustrated the contributionwith an example which is specified in Kmelia, translated manually and verified usingRodin.127Andre et al.Discussion. Our work is more related to abstract and formal component modelslike SOFA or Wright, rather than to the concrete models like CORBA, EJB or.NET. The Java/A [9] or ArchJava [3] models do not allow the use of contracts. Wehave already emphasized (see Section 1) the fact that most of the abstract modelsdeal mainly with the dynamic part of the components. Some of them [16,23] takedatatypes and contracts into account but not the dynamic aspects. Some otherones [11,13] delay the data part to the implementation level.In [14] may/must constraints are associated to the interactions defined in thecomponent interfaces to define behavioural contracts between client and suppliers.In Kmelia, the distinction between a supplier constraint and the client is done froma methodological point of view rather than a syntactic rule. The use of B to checkcomponent contracts has been studied in [15,18] in the context of UML components.Fractal [17] proposes different approaches based on the separation of concerns:the common structural features are defined in Fractal ADL [21] ; dynamic behavioursare implemented by Vercors [8] or Fractal/SOFA [12] and the use of assertions arestudied in ConFract [16]. In ConFract contracts are independent entities which areassociated to several participants, not to services and links as in our case; theircontracts support a rely/guarantee mechanism with respect to the (vertical) com-position of components.In [10] a component (a component type in Kmelia) is a model in the sense ofthe algebraic specifications. Dynamic behaviours are associated to components butnot to services, which are simple operations. The component provided and requiredinterfaces are type specifications and composing component is based on interface (ortype) refinement. In Kmelia components are assembled on their services; thereforethe main issue is not to refine types as in [10] but rather to check contracts as in [25].More specifically our case is more related to the plugin matching of [25].Perspectives. Several aspects remain to be dealt with regarding assertions andthe related properties, composition and correctness of component assemblies. First,we need to implement the full chain of assertion verification especially the translationKmlToB which is necessary to automatically derive the necessary Event-B modelsto check the assertions and the assemblies. Second, we will integrate high levelconcepts and relations for data types. In particular, we plan to integrate some kindof objects and inheritance in the type system but also component types. Assertionsin this context are more difficult to specify and to verify.Another challenging point is the support for interoperability with other compo-nent models. We assume that in real component applications, a component assemblyis built on components written in various specification languages. When connect-ing services (or operations) we can at least check the matching of signatures. Ifthe specification language of the corresponding services or components accepts con-tracts (resp. service composition, service behaviour) we can provide correspondingverification means.References[1] J.-R. Abrial and S. Hallerstede. Refinement, Decomposition, and Instantiation of Discrete Models:Application to Event-B. Fundamenta Informaticae, 77(1-2):1–28, 2007.128Andre et al.[2] Jean-Raymond Abrial. The B-Book Assigning Programs to Meanings. Cambridge University Press,1996. ISBN 0-521-49619-5.[3] Jonathan Aldrich, Craig Chambers, and David Notkin. Archjava: connecting software architectureto implementation. In ICSE ’02: Proceedings of the 24th International Conference on SoftwareEngineering, pages 187–197, New York, NY, USA, 2002. ACM.[4] Robert Allen. A Formal Approach to Software Architecture. PhD thesis, Carnegie Mellon, School ofComputer Science, January 1997. Issued as CMU Technical Report CMU-CS-97-144.[5] Pascal André, Gilles Ardourel, and Christian Attiogbé. Adaptation for hierarchical components andservices. Electron. Notes Theor. Comput. Sci., 189:5–20, 2007.[6] Pascal André, Gilles Ardourel, and Christian Attiogbé. Defining Component Protocols with ServiceComposition: Illustration with the Kmelia Model. In 6th International Symposium on SoftwareComposition, SC’07, volume 4829 of LNCS. Springer, 2007. http://www.lina.sciences.univ-nantes.fr/coloss/projects/kmelia/index_en.php.[7] Christian Attiogbé, Pascal André, and Gilles Ardourel. Checking Component Composability. In 5thInternational Symposium on Software Composition, SC’06, volume 4089 of LNCS. Springer, 2006.http://www.lina.sciences.univ-nantes.fr/coloss/projects/kmelia/index_en.php.[8] Tomás Barros, Antonio Cansado, Eric Madelaine, and Marcela Rivera. Model-checking distributedcomponents: The vercors platform. Electron. Notes Theor. Comput. Sci., 182:3–16, 2007.[9] Hubert Baumeister, Florian Hacklinger, Rolf Hennicker, Alexander Knapp, and Martin Wirsing. Acomponent model for architectural programming. Electr. Notes Theor. Comput. Sci., 160:75–96, 2006.[10] Michel Bidoit and Rolf Hennicker. An algebraic semantics for contract-based software components. InProceedings of the 12th International Conference on Algebraic Methodology and Software Technology(AMAST’08), volume 5140 of LNCS, pages 216–231. Springer, July 2008.[11] E. Bruneton, T. Coupaye, M. Leclercq, V. Quéma, and J.-B. Stefani. The Fractal Component Modeland Its Support in Java. Software Practice and Experience, 36(11-12), 2006.[12] Tomáš Bureš, Martin Děcký, Petr Hnětynka, Jan Kofroň, Pavel Parízek, František Plášil, Tomáš Poch,Ondřej Šerý, and Petr Tůma. CoCoME in SOFA, volume 5153, pages 388–417. Springer-Verlag, 2008.[13] Carlos Canal, Lidia Fuentes, Ernesto Pimentel, JosÃľ M. Troya, and Antonio Vallecillo. Adding Rolesto CORBA Objects. IEEE Trans. Softw. Eng., 29(3):242–260, 2003.[14] Cyril Carrez, Alessandro Fantechi, and Elie Najm. Behavioural contracts for a sound compositionof components. In Hartmut König, Monika Heiner, and Adam Wolisz, editors, FORTE 2003, IFIPTC6/WG 6.1), volume 2767 of LNCS, pages 111–126. Springer-Verlag, September 2003.[15] S. Chouali, M. Heisel, and J. Souquières. Proving component interoperability with B refinement.Electronic Notes in Theoretical Computer Science, 160:157–172, 2006.[16] Philippe Collet, Jacques Malenfant, Alain Ozanne, and Nicolas Rivierre. Composite contractenforcement in hierarchical component systems. In Software Composition, 6th InternationalSymposium (SC 2007), volume 4829, pages 18–33, 2007.[17] Thierry Coupaye and Jean-Bernard Stefani. Fractal component-based software engineering. In Object-Oriented Technology, ECOOP 2006, pages 117–129. Springer, 2006.[18] A. Lanoix and J. Souquières. A trustworthy assembly of components using the B refinement. e-Informatica Software Engineering Journal (ISEJ), 2(1):9–28, 2008.[19] Hung Ledang and Jeanine Souquières. Integration of uml and b specification techniques: Systematictransformation from ocl expressions into b. In 9th Asia-Pacific Software Engineering Conference(APSEC 2002). IEEE Computer Society, 2002.[20] B. Meyer. Object-Oriented Software Construction. Professional Technical Reference. Prentice Hall,2nd edition, 1997. http://www.eiffel.com/doc/oosc/.[21] ObjectWeb Consortium. Fractal adl. [Online]. Available: http://fractal.ow2.org/fractaladl/index.html.[Accessed: Jun. 17, 2009], 2009.[22] Sebastian Pavel, Jacques Noye, Pascal Poizat, and Jean-Claude Royer. Java Implementation of aComponent Model with Explicit Symbolic Protocols. In 4th International Symposium on SoftwareComposition, SC’05, volume 3628 of LNCS. Springer, 2005.[23] H. Schmidt. Trustworthy components-compositionality and prediction. J. Syst. Softw., 65(3):215–225,2003.[24] D.M. Yellin and R.E. Strom. Protocol Specifications and Component Adaptors. ACM Transactionson Programming Languages and Systems, 19(2):292–333, 1997.[25] A. M. Zaremski and J. M. Wing. Specification matching of software components. ACM Transactionon Software Engeniering Methodolology, 6(4):333–369, 1997.129130FACS 2009A Formal Framework for StructuralReconfiguration of Components underBehavioural AdaptationAntonio Cansado, Carlos Canal, Gwen Salau¨n, and Javier CuboDepartment of Computer Science, University of Ma´lagaCampus de Teatinos, 29071, Ma´laga, SpainEmails: {acansado,canal,salaun,cubo}@lcc.uma.esAbstractA major asset of modern systems is to dynamically reconfigure systems to cope with failures or componentupdates. Nevertheless, designing such systems with off-the-shelf components is hardly feasible: componentsare black-boxes that can only interact with others on compatible interfaces. Part of the problem is solvedthrough Software Adaptation techniques, which compensates mismatches between interfaces. Our approachaims at using results of Software Adaptation in order to also provide reconfiguration capabilities to black-boxcomponents.This paper provides two contributions: (i) a formal framework that unifies behavioural adaptation andstructural reconfiguration of components; this is used for statically reasoning whether it is possible toreconfigure a system. And (ii), two cases of reconfiguration in a client/server system in which the serveris substituted by another one with a different behavioural interface, and the system keeps on workingtransparently from the client’s point of view.Keywords: Components, reconfiguration, behavioural adaptation, formal methods1 IntroductionThe success of Component-Based Software Development comes from creating com-plex systems by assembling smaller, simpler components. Nevertheless, buildingsystems based on off-the-shelf components is difficult because components mustcommunicate on compatible interfaces. It is even more difficult when the systemmust be able to reconfigure because components must provide reconfiguration ca-pabilities. Here, we understand by reconfiguration the capacity of changing thecomponent behaviour and/or component implementation at runtime [15]. For ex-ample, we are interested in upgrading a component, substituting a component byanother, adding new components to a running system, and so on.In general, components are black-box modules of software that come with be-havioural specifications of their interfaces. Therefore, there is no access to the sourcecode of components, but it is possible to use tool-assisted techniques to analyse theThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs131Cansado, Canal, Salau¨n, Cubobehaviour of a component assembly [5,8]. Some applications of this analysis areused in Software Adaptation [24] to work out behavioural mismatches in the com-ponents’ interfaces. In [19], an adaptation contract defines rules on how mismatchescan be worked out and a tool generates an adaptor that orchestrates the systemexecution and compensates incompatibilities existing in interfaces.On the other hand, there is little support to analyse whether a reconfigurationis safe. Enabling system reconfiguration requires designers to define (i) when acomponent can be reconfigured, (ii) which kind of reconfiguration is supported bythe component, and (iii) which kind of properties the reconfiguration holds. Forexample, ensuring that some parts of the system can be reconfigured without sys-tem disruption. Our approach aims at providing a formal framework that helpsanswering these questions.There are several related approaches in the literature. SOFA 2.0 [8] proposesreconfiguration patterns in order to avoid uncontrolled reconfigurations which leadto errors at runtime. This allows adding and removing components at runtime,passing references to components, etc., under predefined structural patterns. Thereare other more general approaches that deal with distributed systems and softwarearchitectures [12,13], graph transformation [1,23] or metamodelling [11].Our goal is to reconfigure components that have not been designed with recon-figuration capabilities in mind. Moreover, we target reconfiguration of componentsthat may be involved in an ongoing transaction without stopping the system. Thisfits in a context where reconfiguration may be triggered at any moment and acomponent must be substituted at runtime.Since substituting a component usually requires finding a perfect match, re-configuration is usually limited to instances (or subtypes) of the same component.Our approach is to exploit behavioural adaptation to further allow reconfiguration.That is, we target reconfiguration scenarios in which both the former and the newcomponent need some adaptation in order to allow substitution. We build on thebasis that components are provided with behavioural interfaces and the composi-tion with adaptation contracts. Then, we show that in some cases the informationfound in the adaptation contract can be used to endow black-box components withreconfiguration capabilities.This paper’s contributions are: (i) we present a formal model that includesbehavioural adaptation and structural reconfiguration of components. With thisframework it is possible to verify properties of the complete system, including thoseinvolving reconfiguration of a component by another one with a different behaviouralinterface. And (ii), we present two examples of substitutability in which a serveris substituted by another one with a different behavioural interfaces. We also showhow can we build a fault-tolerant system by constraining the system’s behaviour.This paper is structured as follows: Firstly, Section 2 provides some backgroundon formalisms that will be used throughout the paper. Then Section 3 introduces aclient/server system that is used as running example. Section 4 provides the formalmodel that allows structural reconfiguration and behavioural adaptation. Section 5provides applications of our approach for designing reconfigurable systems based on(non-reconfigurable) black-box components. Then, Section 6 presents related workson reconfiguration and behavioural adaptation and Section 7 concludes this paper.132Cansado, Canal, Salau¨n, Cubo2 BackgroundThis work builds on previous work on hierarchical behavioural models [5] and Soft-ware Adaptation [9]. We recall in this section the main definitions that are used inthis paper.2.1 Networks of Synchronised AutomataWe assume that component interfaces are equipped both with a signature (set ofrequired and provided operations), and a protocol. We model the behaviour of acomponent as a Labelled Transition System (LTS). The LTS transitions encode theactions that a component can perform in a given state. In the following definitions,we frequently use indexed vectors: we note x˜I the vector 〈..., xi , ...〉 with i ∈ I ,where I is a countable set.Definition 2.1 [LTS]. A Labelled Transition System (LTS) is a tuple 〈S , s0,L,→〉where S is the set of states, s0 ∈ S is the initial state, L is the set of labels, → isthe set of transitions : →⊆ S × L× S . We write s α−→ s ′ for (s, α, s ′) ∈→.Communication between components are represented using actions relative tothe emission and reception of messages corresponding to operation calls, or internalactions performed by a component. Therefore, in our model, a label is either theinternal action τ or a tuple (M ,D) where M is the message name and D stands forthe communication direction (! for emission, and ? for reception).Definition 2.2 [Network of LTSs]. Let Act be an action set. A Net is a tuple〈AG , J , O˜J ,T 〉 where AG ⊆ Act is a set of global actions, J is a countable set ofargument indexes, each index j ∈ J is called a hole. Oj is the sort of the hole jwith Oj ⊂ Act. The transducer T is an LTS (ST , s0T ,LT ,→T ), and LT = {−→v =〈ag .α˜I 〉, ag ∈ AG , I ⊆ J ∧ ∀ i ∈ I , αi ∈ Oi}Synchronisation between components is specified using Nets [5]. Nets are in-spired by synchronisation vectors [2], that we use to synchronise a number of pro-cesses and can describe dynamic configurations of processes, in which the possiblesynchronisations change with the state of the Net; they are transducers [18].A transducer in the Net is encoded as an LTS whose labels are synchronisationvectors (−→v ), each one describing a particular synchronisation between the actions(α˜I ) of different argument processes; the result of this synchronisation is seen asa global action ag . Each state of the transducer T corresponds to a given config-uration of the network in which a given set of synchronisations is possible. Someof those synchronisations can trigger a change of state in the transducer leading toa new configuration of the network; that is, it encodes a dynamic change on theconfiguration of the system.Definition 2.3 [Sort]. The Sort is the set of actions that can be observed fromoutside the automaton. It is determined by its top-level node, L for an LTS, andAG for a Net:Sort(〈S , s0,L,→〉) = L Sort(〈AG , J , O˜J ,T 〉) = AG133Cansado, Canal, Salau¨n, CuboA Net is a generalised parallel operator. Complex systems are built by combiningLTSs in a hierarchical manner using Nets at each level. There is a natural typingcompatibility constraint for this construction, in term of the sorts of formal andactual parameters. The standard compatibility relation is Sort inclusion: a systemSys can be used as an actual argument of a Net at position j only if it agrees withthe sort of the hole Oj , i.e. Sort(Sys) ⊆ Oj .2.2 Specification of Adaptation ContractsWhile building a new system by reusing existing components, behavioural interfacesdo not always fit one another, and these interoperability issues have to be faced andworked out. Mismatches may be caused by different message names, a messagewithout counterpart (or with several ones) in the partner, etc. The presence ofmismatch results in a deadlocking execution of several components [3,10].Adaptors can be automatically generated based on an abstract description ofhow mismatch situations can be solved. This is given by an adaptation contract.In this paper, the adaptation contract AC between components is specified us-ing vectors [9]. Each action appearing in one vector is executed by one componentand the overall result corresponds to a synchronisation between all the involvedcomponents. A vector may involve any number of components and does not re-quire interactions to occur on the same names of actions. Moreover, a vector maysynchronise actions performed by sub-processes in a hierarchical fashion.For example, a vector v = 〈C 1 : on!,C 2 : activate?〉 denotes that the action on!performed by component C 1 corresponds to action activate? performed by compo-nent C 2. This does not mean that both actions have to take place simultaneously,nor one action just after the other; the adaptor will take into account their respec-tive behaviour as specified in their LTS, accommodating the reception and sendingof actions to the points in which the components are able to perform them.on!activate!on?C1 Adaptoractivate?C2on! on? activate!activate?3 Running ExampleThis section presents the running example used in the following sections. It consistsof a client/server system in which the server may be substituted by an alternativeserver component. This can be needed in case of server failure, or simply for a changein the client’s context or network connection that made unreachable the originalserver. We suppose none of the components have been designed with reconfigurationcapabilities.The client wants to buy books and magazines as shown in its behavioural inter-face in Fig. 1(a). The two servers A and B have behavioural interfaces depicted in134Cansado, Canal, Salau¨n, CuboFigs. 1(c) and 2(b) respectively. Server A can sell only one book per transaction 1 ;on the other hand, server B can sell a bounded number of books and magazines.Initially, the client is connected to server A; we shall call this configuration cA.The client and the server agree on an adaptation contract ACC ,A (see Fig. 1(b)).Naturally, under configuration cA the client can only buy at most one book in eachtransaction but it is not allowed to buy magazines because this is not supportedby server A. The latter is implicitly defined in the adaptation contract (Fig. 1(b))because there is no vector allowing the client to perform the action buyMagazine!.Finally, server A does not send the acknowledgement ack? (see v4 in Fig. 1(b))expected by the client; this must also be worked out by the adaptor.041LOGIN !2PASSWD !LOGOUT !3BUYBOOK ! BUYMAGAZINE ! ACK ?(a) LTS of Client Cv1 = 〈C : login!,A : user?〉v2 = 〈C : passwd !,A : passwd?〉v3 = 〈C : buyBook !,A : buy?〉v4 = 〈C : ack?,A : 〉v5 = 〈C : logout !,A : disconnect?〉(b) Adaptation Contract ACC ,A041USER ?2PASSWD ?DISCONNECT ? 3BUY ?DISCONNECT ?(c) LTS of Server AFig. 1. Configuration cA.In an alternative configuration cB the client is connected to server B whoseprotocol is depicted in Fig. 2(b). Similarly, the client and the server agree onan adaptation contract ACC ,B (see Fig. 2(a)). Under configuration cB , the clientcan buy a bounded number of books and magazines. In Fig. 2(a), we see thatvector v5 allows the client to buy magazines. Moreover, server B sends a differentacknowledgement for each product (see v4 and v6 in Fig. 2(a)).We shall study reconfiguration from cA to cB which substitutes A by B . It isworth noting that A and B do not have the same behavioural interfaces. Not onlyB provides additional functionality w.r.t. A, but also B does not have the samenames for the actions (and potentially the ordering of actions may be different aswell). For instance, v1 of ACC ,A (see Fig. 1(b)) says that the login! action of theclient relates to user? of server A. On the other hand, this login! action must berelated to connect? of server B (see v1 of ACC ,B in Fig. 2(a)).4 Formal ModelThis section provides the formal model that enables reconfiguration and behaviouraladaptation. We define a reconfiguration contract to determine how the system may1 A transaction starts in the LTS’s initial state and ends in the final one. The definition of LTS in Section 2.1does not include final states, though one can understand as final state a state with no outgoing transitions.135Cansado, Canal, Salau¨n, Cubov1 = 〈C : login!,B : connect?〉v2 = 〈C : passwd !,B : pwd?〉v3 = 〈C : buyBook !,B : buyBook?〉v4 = 〈C : ack?,B : bookOk !〉v5 = 〈C : buyMagazine!,B : buyMagazine?〉v6 = 〈C : ack?,B : magazineOk !〉v7 = 〈C : logout !,B : disconnect?〉(a) Adaptation Contract ACC ,B051CONNECT ?2PWD ?DISCONNECT ?3BUYBOOK ?4BUYMAGAZINE ?BOOKOK ! MAGAZINEOK !(b) LTS of Server BFig. 2. Configuration cB .evolve in terms of structural changes. Then, we provide a formal model based onNets for this kind of systems.4.1 Reconfiguration ContractA system architecture consists of a finite number of components. Each configura-tion is a subset of these components connected together by means of adaptationcontracts.Definition 4.1 [Configuration]. A configuration c = 〈P ,AC,S ?〉 is a staticstructural configuration of a system. P is an indexed set of components. AC isan adaptation contract of components in P . S ? is a set of reconfiguration statesdefined upon P ; these are states in which reconfiguration is allowed.Changing a configuration by another is what we call a reconfiguration. Thisis specified in a reconfiguration contract which separates reconfiguration concernsfrom the business logic. Each configuration can be thought of a static system andthe “dynamic” part is specified by a reconfiguration operation. The reconfigurationstates are left out-of-scope in this paper. We assume here they are given by thedesigner, though we show how some of them can be obtained in our examples.Definition 4.2 [Reconfiguration Contract]. A reconfiguration contract R =〈C , c0,→R〉 is defined as:C is a set of static configurations, where ci ∈ C , i ∈ {0..n}, is a static configura-tion. c0 ∈ C is the initial configuration. →R⊆ C×Rop×C is a set of reconfigurationoperation, with reconfiguration operation Rop ⊆ S ?i × S ?j , S ?i ∈ ci ,S ?j ∈ cj .From the definition above, reconfiguration can take place in the middle of a trans-action and the new configuration can have a new adaptation contract. Therefore,this allows reconfiguring a component by another one that implements a differentbehavioural interface. Nevertheless, for guaranteeing consistency this can only hap-pen at predefined states. A state of the source configuration (s?i ) defines when aconfiguration can be reconfigured. On the other hand, a state of the target configu-ration (s?j ) says what is the starting state in the target configuration to resume theexecution.136Cansado, Canal, Salau¨n, CuboExampleIn the running example, there are two configurations:cA = 〈{C ,A},ACC ,A,S ?A〉 and cB = 〈{C ,B},ACC ,B ,S ?B 〉.The reconfiguration contract R = 〈C , cA,→R〉 is given by:C = {cA, cB}, and →R= {cA r−→ cB}, with r = (s?A, s?B ).r must specify the pairs of reconfiguration states on which reconfiguration canbe performed. Since both servers have different behavioural interfaces, it is notstraight-forward to determine how reconfiguration can take place after a transactionbetween the client and the server has started. Therefore, in the simplest scenarioreconfiguration from cA to cB is only allowed at the initial states of the client andthe server. This is specified as a unique reconfiguration state s?i ∈ S ?i , i ∈ {A,B} foreach configuration; more precisely, s?A = {C : s0,A : s0} and s?B = {C : s0,B : s0}.In Section 5 we will study how other pairs of reconfiguration states can be obtained.4.2 Building Verifyable SystemsThis section shows how to build Nets for the reconfiguration contract above. Wehave previously defined the system and now we generate a behavioural model of thecomplete system that can be fed into model-checking tools. There are two benefitsin this approach.Firstly, is it easier to verify properties related to reconfiguration if the completesystem is modelled. In our running example, we can prove that the client may onlybuy magazines if the system is reconfigured towards a configuration cB .Secondly, a Net is close enough to the structure of a program that it should bepossible to implement the Net in a component model framework such as Fractal [7].This would provide us, at runtime, a component system with predictable behaviourunder reconfiguration.As the adaptor represents the interactions between the adapted components,we will use states of the adaptor to identify states in which reconfiguration will beapplied. Let AP be the adapter LTS generated by AC [10], we add a reconfigurationaction rs?i ? for each s?i ∈ S ?. This action leaves the adaptor in same state, definedas the state in which all components are in the state given by s?i .Definition 4.3 [Network of Configuration]. A configuration c = 〈P ,AC,S ?〉,defines a Net cNet = 〈AG , J , O˜J ,T 〉, as:Let AP be the adapter LTS generated by AC, with a reconfiguration action rs?i ?for each s?i ∈ S ?. Each a! ∈ Sort(pi) defines an action v = {pi : a!,AP : a?} ∈AG . Each a? ∈ Sort(pi) defines an action v = {pi : a?,AP : a!} ∈ AG . Eachreconfiguration action rs?i ? defines an action v = {AP : rs?i ?} ∈ AG . Each processpi and AP is an argument of J , with Sort(pi) ⊆ Opi and Sort(AP ) ⊆ OAP .The Net transducer T is defined as: a unique state sT = s0T ∈ ST ; and atransition sTv−→ sT for each v ∈ AG .In the definition above, a Net closely represents a configuration; the root of theNet ’s tree is the synchronisation operator given by the Net’s transducer, and theNet ’s leaves are the components pi and AP . The transducer actions are synchroni-sation vectors that relate actions between pi and the adaptor; note that due to the137Cansado, Canal, Salau¨n, Cuboadaptation process, these actions are exact dual operations. The transducer hasadditional transitions taking care of reconfiguration capabilities, though they arenot used within a configuration.We construct a system that allows reconfiguration between configurations basedon the reconfiguration contract and the construction of a network for a configuration.Definition 4.4 [Network of Reconfiguration Contract]. A R = 〈C , cA,→R〉defines a Net RNet = 〈AG , J , O˜J ,T 〉, with:Each configuration ci ∈ C defines a Net ciNet ∈ J . Each reconfiguration op-eration r defines a process Pr used as argument of J . This process will be incharge of initialising the target configuration. The global actions AG are definedupon the union of the global actions of each configuration, and the reconfigurationtransactions. Formally, AG = [⋃∀ci∈CSort(ciNet )] ∪ {r : ci r−→ cj ∈→R, i 6= j}.The sorts of each configuration ciNet define O˜J , i.e. Sort(ciNet ) = Oi . The Nettransducer T=(ST , s0T ,LT ,→T ) orchestrates the system execution. Each configu-ration Net ciNet is represented by a state si ∈ ST .Actions within a configuration are transitions over the same configuration state,i.e., there is a transition siag−→ si for each ag ∈ Sort(ciNet )\⋃r .For each reconfiguration operation cir−→ cj we add a reconfiguration state sr inthe transducer (see Fig. 3). In this state, only actions within Pr can be performed,i.e., srrα−→ sr where rα are actions in Pr . The reconfiguration starts with an actionrstart = rs?i ? that changes the transducer state from si to sr . Reconfiguration actionsare performed (rα), and finally the system changes to a configuration cj in a statedefined by r by performing the action rend = rs?j ?.sjrendrstartag ∈ ciNet ag ∈ cjNetsrrαsiFig. 3. Transducer representing a reconfiguration from configuration ci to configuration cj .The reconfiguration contract is mapped into a NetRNet . The transducer ofRNetis an LTS that has each of the configurations as states, and transitions representingeither a reconfiguration r or the allowance of a (non-reconfiguring) action ag withina configuration.Each of the configurations ci is mapped into a Net ciNet that is used as anargument of the RNet ’s holes. Hence, we build a tree of processes in which theroot is RNet , the internal nodes are configurations, and leaves are LTSs of thecomponents’ behaviour.Reconfigurations operations eventually move the system from a configurationto another (see Fig. 3). The role of the state sr is to halt system execution andinitialise the new configuration so that it starts at the target reconfiguration state.138Cansado, Canal, Salau¨n, CuboExampleBack to the running example, the first step in creating the Net is to generatethe adaptors AC ,A (Fig. 4(a)) and AC ,B (Fig. 4(b)) in the form of LTSs. This isdone by the Compositor tool [14]. Based on the adaptation contracts, Compositorautomatically generates an adaptor for each configuration that is guaranteed toorchestrate deadlock-free interactions between the client and a server.0f1C:LOGIN ?2A:USER !3C:PASSWD ?4A:PASSWD !5C:BUYBOOK ?8C:LOGOUT ?6A:BUY !7C:ACK !C:LOGOUT ?A:DISCONNECT !(a) Adaptor AC ,A0121C:LOGIN ?2B:CONNECT !3C:PASSWD ?4B:PWD !5C:BUYBOOK ?6C:BUYMAGAZINE ?7C:LOGOUT ?8B:BUYBOOK !9B:BUYMAGAZINE !11B:BOOKOK ?C:ACK !10B:MAGAZINEOK ?C:ACK !B:DISCONNECT !(b) Adaptor AC ,BFig. 4. AdaptorsThe Net for cA is created as follows 2 :(i) We add a reconfiguration action s?Ars?A?−−−→ s?A in the adaptor.(ii) AG has two actions for each vector in ACC ,A, i.e., v1 = 〈C : login!,A : user?〉generates the actions v1! = 〈C : login!,AC ,A : login?〉 and v1? = 〈AC ,A :user !,A : user?〉. AG has the action rs?A? = 〈AC ,A : rs?A?〉.(iii) LTSs of the components and the adaptor are the Net’s holes: J = {C ,A,AC ,A};O˜J = {Sort(C ),Sort(A),Sort(AC ,A)}.(iv) T has a unique state sT , with sTag−→ sT , ag ∈ AG .No initialisation of server B is needed after the reconfiguration because thesystem can only be reconfigured in its initial state. Therefore, Pr is a dummyautomaton with a unique state and no transition.2 For the sake of size, the Net of cB is created in a similar way.139Cansado, Canal, Salau¨n, CuboFinally, we create RNet : the transducer has states sA, sB , srA,B . Non-reconfiguration transitions are: sAag−→ sA, ag ∈ cANet and sBag−→ sB , ag ∈ cBNet .Reconfiguration transitions are: sArs?A?−−−→ srA,B and srA,Brs?B?−−−→ sB .In this example, reconfiguration is only allowed in the initial state. Nevertheless,our goal is to allow reconfiguration in arbitrary states in which the client and theserver have already started a transaction. This is the goal of Section 5.5 Contract-Aware ReconfigurationWe have shown in the previous section that the running example can be reconfiguredat the initial stage of the transaction. Nevertheless, more interesting are scenariosin which reconfiguration can take place at arbitrary stages of the transaction. Withthat purpose, Section 5.1 defines a test that determines whether it is possible toreconfigure the component system at a certain stage of the transaction. Afterwards,Section 5.2 studies how to design a fault-tolerant system in which reconfigurationcan take place between two different configurations back and forth.5.1 History-Aware SubstitutabilityNow, suppose the previous example needs to be reconfigured during an ongoingtransaction between C and A. This would be the case where a client connects to theserver A, logs in, and before disconnecting, A is substituted by B . Unfortunately,A and B do not provide such reconfiguration capabilities and it is not possibleto substitute A by B without behavioural adaptation because they have differentbehavioural interfaces.The client must not abort the ongoing transaction t . Therefore, if the executiontrace of C (σC from now on) is valid in the new configuration cB , then C couldhave been interacting with B from the very beginning. We proceed by initialisingB under this assumption, i.e., finding an execution trace σB such that the actionsperformed by C in t are feasible in cB when B has performed σB .As the adaptor orchestrates the execution between the two parties, wecan use the state of the adaptor as the global system state. We say thatt = 〈σp1 , σp2〉;s Ap1,p2 when actions performed by P1 in σp1 and P2 in σp2 leadthe adaptor Ap1,p2 to state s.Definition 5.1 [Trace Compliant]. Let t ;s AC ,S , with t = 〈σC , σS 〉 where σCand σS are traces of C and S respectively.S ′ is trace compliant to S given t if there exists t ′=〈σC , σS ′〉;s′ AC ,S ′ .Not all components are trace compliant given t . However, if t ′ exists, the newconfiguration cB can reach a (deadlock-free) state s?1 that simulates the executionof cA when the latter reaches the state s?0 . Therefore, it is possible to build a recon-figurable system that starts in a configuration cA and may reconfigure towards aconfiguration cB when the client has performed the actions in t . This reconfigura-tion does not affect the client in the sense it does not need to abort t nor to rollback.In fact, a new transaction t ′ is created such that the client continues working on140Cansado, Canal, Salau¨n, Cubotransparently, though it is warned that the adaptation contract has changed; evenso, its previous actions are valid and considered in the running transaction (t ′).Trace compliance assures that the client’s history is unchanged, though it saysnothing about future actions. Therefore, it is possible to provide new functionalityin the new configuration while maintaining consistency.ExampleIn the running example, the login phase is similar in both configurations fromthe client’s point of view. Therefore, it is easy to notice that both configurationsare trace compliant given σC = {login!; passwd !}. This allows us to define a recon-figuration from the state s?0 = {C : s2,A : s2} to the state s?1 = {C : s2,B : s2}. Theinitialisation required by B is the result of finding t ′, i.e., σB = {connect?; pwd?}(this specifies Pr ). Therefore, meanwhile the client is logged in, the server can besubstituted at runtime by another component with a different behavioural interface.Then, the client may log in server A, and after a reconfiguration to configurationcB the client can buy several books and magazines.On the other hand, cB is not trace compliant to cA given an arbitrary trace σC .For example, if the client has bought a magazine (or several books) in σC , then thistrace cannot be simulated in cA because A only supports transactions in which atone book is sold. Still, cB is trace compliant to cA for traces that do not includebuying several books or at least one magazine; we shall explore this scenario inSection 5.2.5.2 Fault-Tolerant SystemThe previous example allowed reconfiguring the system from cA to cB , thoughreconfiguring the system from cB to cA is only possible on some of the traces per-formed by the client. We investigate here how to design a fault-tolerant system byconstraining the behaviour of the previous system. We will guarantee that serverA can always be substituted by B (and B by A likewise) transparently from theclient’s point of view.One way of ensuring two components are mutually substitutable is by means ofa bisimulation equivalence [22]. A more relaxed equivalence takes into account onlythe behaviour of the servers given the constraints imposed by the environment. Inour case, these constraints are summarised within the adaptors because they expressthe allowed behaviour performed by both parties.An even more relaxed condition checks whether the adaptors AC ,A and AC ,Bare bisimilar 3 from the client’s point of view. There are two options: either toignore the actions performed by the servers, or to map the actions of one server intoanother (through yet another adaptation contract). Both solutions allow servers toimplement different behavioural interfaces; we have chosen to explore the former.Even under this relaxed condition it is difficult to find two servers that provideclients with the same functionalities. More likely is that some of the actions allowedto the client are common in both configurations. Hence, if the system were to workon this reduced behaviour it would be possible to provide reconfiguration capabilities3 We leave open which kind of bisimulation is used; for example, strong, weak, or branching bisimulation.141Cansado, Canal, Salau¨n, Cuboas shown in Section 5.1. Our solution is to create new adaptors that are equivalentfrom the client’s point of view. That is:ARC ,A ≡C ARC ,B iff ∀ t = 〈σC , σA〉;s?0 ARC ,A, ∃ t ′ = 〈σC , σB 〉;s?1 ARC ,B∀ t ′ = 〈σC , σB 〉;s?1 ARC ,B , ∃ t = 〈σC , σA〉;s?0 ARC ,AThese are adaptors that constrain the behaviours of the client and the serverssuch that we can perform reconfiguration at any moment (from the client’s point ofview). They are found as follows:(i) Compute C R = Product((Hide(LA) in AC ,A), (Hide(LB ) in AC ,A)). If C R isdeadlock-free, proceed.(ii) Compute ARC ,A = Product(CR,AC ,A) and ARC ,B = Product(CR,AC ,B ).Product synchronises matching labels of both parties into a new synchronisedaction. Hide makes a set of labels L be internal actions (τ).0f1C:LOGIN ?2B:CONNECT !78C:ACK !9C:LOGOUT ?6B:BOOKOK ?B:DISCONNECT !3C:PASSWD ?4B:PWD !C:LOGOUT ?5C:BUYBOOK ?B:BUYBOOK !C R finds the behaviour that can be performed by the clientin both adaptors. This is done by hiding the actions performedby the servers (LA and LB ) and building the synchronisedproduct. If there are no traces that can be performed by theclient in both adaptors, there is a deadlock in C R and it isnot possible to build a fault-tolerant system. Otherwise, usingC R , we constrain each adaptor to this client behaviour whichyields, by construction, trace compliant ARC ,A and ARC ,B givenany transaction.ExampleIn the running example, the constrained system allows theclient to buy at most one book in each transaction. In fact,we find that ARC ,A ≡ AC ,A but ARC ,B allows only the traces inwhich the client buys a book or nothing at all (see Fig. on theright). In this scenario, either server A or B suits the client’sactions, and thus reconfiguration is possible.Any σC feasible in one of these new adaptors is feasiblein the other. Therefore, we can apply the procedure fromSection 5.1 for finding pairs of states on which reconfigura-tion can be applied. We build this way a system that canbe reconfigured from one configuration to the other back andforth.6 Related WorkDynamic reconfiguration [15] is not a new topic and manysolutions have already been proposed in the context of dis-tributed systems and software architectures [12,13], graphtransformation [1,23], software adaptation [20,19], metamodelling [11], or recon-figuration patterns [8]. On the other hand, Software Adaptation is a recent solution142Cansado, Canal, Salau¨n, Cuboto build component-based systems accessed and reused through their public inter-faces. Adaptation is known as the only way to compose black-box components withmismatching interfaces. However, only few works have focused so far on the recon-figuration of systems whose correct execution is ensured using adaptor components.In the rest of this section, we focus on approaches that tackled reconfigurationaspects for systems developed using adaptation techniques.First of all, in [20], the authors present some issues raised while dynamicallyreconfiguring behavioural adaptors. In particular, they present an example in whicha pair of reconfigurations is successively applied to an adaptor due to the upgradeof a component in which some actions have been first removed and next added. Nosolution is proposed in this work to automate or support the adaptor reconfigurationwhen some changes occur in the system.Most of the current adaptation proposals may be considered as global, since theyproceed by computing global adaptors for closed systems made up of a predefinedand fixed set of components. However, this is not satisfactory when the systemmay evolve, with components entering or leaving it at any time, e.g., for pervasivecomputing. To enable adaptation on such systems, an incremental approach shouldbe considered, by which the adaptation is dynamically reconfigured depending onthe components present in the system. One of the first attempts in this directionis [4], whose proposal for incremental software construction by means of refinementallows for simple signature adaptation. However, to our knowledge the only pro-posal addressing incremental adaptation at the behavioural level is [21,19]. In thesepapers, the authors present a solution to build step by step a system consisting ofseveral components which need some adaptations. To do so, they propose sometechniques to (i) generate an adaptor for each new component added to the system,and (ii) reconfigure the system (components and adaptors) when a component isremoved.Compared to [20,21,19], our goal is slightly different since we do not want todirectly reconfigure adaptor behaviours, but we want to substitute both a compo-nent and its adaptor by another couple component-adaptor while preserving someproperties of the system such as trace compliance.Some recent approaches found in the literature [6,17,16] focus on existing pro-gramming languages and platforms, such as BPEL or SCA components, and suggestmanual or at most semi-automated techniques for solving behavioural mismatch. Inparticular, the work presented in [16] deal with the monitoring and adaptation ofBPEL services at run-time according to Quality of Services attributes. Their ap-proach also proposes replacement of partner services based on various strategieseither syntactic or semantic. Although replaceability ideas presented in this paperare close to our reconfiguration problem, they mainly deal with QoS characteristicswhereas our focus is on behavioural issues.7 ConclusionsThis paper has presented a novel framework that supports the design of reconfig-urable systems. The formal model defines reconfiguration as a transition from a(static) configuration to another. Each configuration specifies a component assem-143Cansado, Canal, Salau¨n, Cubobly with its own set of components and connections, and a reconfiguration contractdefines when the configuration can be reconfigured and which is the starting statein the new configuration in order to resume the execution.We have integrated Software Adaptation in the framework in order to furtherenable reconfiguration. We have shown that, based on adaptation contracts, itis possible to substitute a component by another one that implements a differentbehavioural interface; this potentially includes mismatches in actions, ordering ofactions, and functionality. Briefly, we build on the basis that for some cases it ispossible to find execution traces in which configurations are similar in some sense,and thus it is possible to simulate the execution of a system in another one with adifferent behavioural interface.Perspectives. We have presented an initial step on reconfiguration of componentswith mismatching behavioural interfaces. The framework is expressive and suitablefor our needs and we have presented a case-study of runtime configuration. Thereare many open questions, though, that we wish to continue working on:We have shown that in a simple setting it is possible to find system states inwhich it is safe to perform reconfiguration. Nevertheless, for more general scenariosfinding correspondences between states based on trace compliance is not enough.We believe that it is necessary to refine what are the necessary properties the newconfiguration must hold. For example, by endowing a reconfiguration contract withinvariants under the form of temporal properties.An alternative is to augment component LTSs with sub-transactions. In ourclient/server example, the server would specify that a sub-transaction starts whenbuying a product and ends when the acknowledgement has been sent to the client.Then, it would be possible to buy magazines from server B (which is not supportedby server A), and then substitute B by A.We also plan to address other scenarios in which a component is substituted by acomponent assembly. For example, where the server is substituted by a componentimplemented by a front-end component and a back-end component. Our formalmodel can formalise the behaviour of such systems, though there are new challengeson how to simulate actions of the former configuration in the new one.Finally, we plan to integrate this framework within a component model suchas Fractal. We believe that the model built on Nets can be implemented in theruntime platform of Fractal in order to provide components with safe reconfigurationcapabilities.Acknowledgements. This work has been partially supported by the projectTIN2008-05932 funded by the Spanish Ministry of Science and Innovation, andproject P06-TIC-02250 funded by the Andalusian local Government.References[1] N. Aguirre and T. Maibaum. A Logical Basis for the Specification of Reconfigurable Component-BasedSystems. In Proc. of FASE’03, volume 2621 of LNCS, pages 37–51. Springer, 2003.[2] A. Arnold. Finite transition systems. Semantics of communicating systems. Prentice-Hall, 1994.[3] M. Autili, P. Inverardi, A. Navarra, and M. Tivoli. SYNTHESIS: A Tool for Automatically Assembling144Cansado, Canal, Salau¨n, CuboCorrect and Distributed Component-based Systems. In Proc. of ICSE’07, pages 784–787. IEEEComputer Society, 2007.[4] R. J. Back. Incremental Software Construction with Refinement Diagrams. Technical Report 660,Turku Center for Computer Science, 2005.[5] T. Barros, R. Ameur-Boulifa, A. Cansado, L. Henrio, and E. Madelaine. Behavioural models fordistributed fractal components. Annals of Telecommunications, 64(1):25–43, 2009.[6] A. Brogi and R. Popescu. Automated Generation of BPEL Adapters. In Proc. of ICSOC’06, volume4294 of Lecture Notes in Computer Science, pages 27–39. Springer, 2006.[7] E. Bruneton, T. Coupaye, M. Leclercq, V. Que´ma, and J.-B. Stefani. The fractal component model andits support in java: Experiences with auto-adaptive and reconfigurable systems. Softw. Pract. Exper.,36(11-12):1257–1284, 2006.[8] T. Buresˇ, P. Hnetynka, and F. Pla´sˇil. Sofa 2.0: Balancing advanced features in a hierarchical componentmodel. In SERA ’06: Proceedings of the Fourth International Conference on Software EngineeringResearch, Management and Applications, pages 40–48, Washington, DC, USA, 2006. IEEE ComputerSociety.[9] J. Ca´mara, J. A. Martin, G. Salau¨n, J. Cubo, M. Ouederni, C. Canal, and E. Pimentel. Itaca: Anintegrated toolbox for the automatic composition and adaptation of web services. In ICSE, pages627–630. IEEE, 2009.[10] C. Canal, P. Poizat, and G. Salau¨n. Model-Based Adaptation of Behavioural Mismatching Components.IEEE Transactions on Software Engineering, 34(4):546–563, 2008.[11] A. Ketfi and N. Belkhatir. A Metamodel-Based Approach for the Dynamic Reconfiguration ofComponent-Based Software. In Proc. of ICSR’04, volume 3107 of LNCS, pages 264–273. Springer,2004.[12] J. Kramer and J. Magee. The Evolving Philosophers Problem: Dynamic Change Management. IEEETransactions on Software Engineering, 16(11):1293–1306, 1990.[13] J. Kramer and J. Magee. Analysing Dynamic Change in Distributed Software Architectures. IEEProceedings - Software, 145(5):146–154, 1998.[14] R. Mateescu, P. Poizat, and G. Salau¨n. Adaptation of service protocols using process algebra andon-the-fly reduction techniques. In ICSOC ’08: Proceedings of the 6th International Conference onService-Oriented Computing, pages 84–99, Berlin, Heidelberg, 2008. Springer-Verlag.[15] N. Medvidovic. ADLs and Dynamic Architecture Changes. In SIGSOFT 96 Workshop, pages 24–27.ACM, 1996.[16] O. Moser, F. Rosenberg, and S. Dustdar. Non-Intrusive Monitoring and Adaptation for WS-BPEL. InProc. of WWW’08, pages 815–824, 2008.[17] H. R. Motahari-Nezhad, B. Benatallah, A. Martens, F. Curbera, and F. Casati. Semi-AutomatedAdaptation of Service Interactions. In Proc. of WWW’07, pages 993–1002, 2007.[18] E. Najm, A. Lakas, A. Serouchni, E. Madelaine, and R. de Simone. ALTO: an interactive transformationtool for LOTOS and LOTOMATON. In Proc. of Lotosphere Workshop and Seminar, 1992.[19] P. Poizat and G. Salau¨n. Adaptation of Open Component-Based Systems. In Proc. of FMOODS’07,volume 4468, pages 141–156. Springer, 2007.[20] P. Poizat, G. Salau¨n, and M. Tivoli. On Dynamic Reconfiguration of Behavioural Adaptation. In Proc.of WCAT’06, pages 61–69, 2006.[21] P. Poizat, G. Salau¨n, and M. Tivoli. An Adaptation-based Approach to Incrementally Build ComponentSystems. In Proc. of FACS’06, volume 182, pages 39–55, 2007.[22] I. Cˇerna´, P. Varˇekova´, and B. Zimmerova. Component substitutability via equivalencies of component-interaction automata. Electronic Notes in Theoretical Computer Science (ENTCS) series, 182:39–55,2007.[23] M. Wermelinger, A. Lopes, and J. L. Fiadeiro. A Graph Based Architectural (Re)configurationLanguage. In Proc. of ESEC / SIGSOFT FSE 2001, pages 21–32. ACM, 2001.[24] D. M. Yellin and R. E. Strom. Protocol Specifications and Components Adaptors. ACM Transactionson Programming Languages and Systems, 19(2):292–333, 1997.145146FACS 2009PobSAM: Policy-based Managing of Actors inSelf-Adaptive SystemsNarges Khakpour1 , Saeed Jalili2Tarbiat Modares University, Tehran, IranCarolyn Talcott3SRI International, Menlo Park, CaliforniaMarjan Sirjani4Reykjavk University, Reykjavk, IcelandUniversity of Tehran and IPM, Tehran, IranMohammadReza Mousavi5Eindhoven University of Technology, Eindhoven, The NetherlandsAbstractIn this paper, we present a formal model, named PobSAM (Policy-based Self-Adaptive Model), for modelingself-adaptive systems. In this model, policies are used as a mechanism to direct and adapt the behaviorof self-adaptive systems. A PobSAM model consists of a set of self-managed modules(SMM). An SMMis a collection of autonomous managers and managed actors. Managed actors are dedicated to functionalbehavior while autonomous managers govern the behavior of managed actors by enforcing suitable policies.To adapt SMM behavior in response to changes, policies governing an SMM are adjusted, i.e., dynamicpolicies are used to govern and adapt system behavior. We employ the combination of an algebraic formalismand an actor-based model to specify this model formally. Managers are modeled as meta-actors whosepolicies are described using an algebra. Managed actors are expressed by an actor model. Furthermore, weprovide an operational semantics for PobSAM described using labeled transition systems.Keywords: Adaptive systems, Policy-based Computing, Component-based Design, Algebra, Actor Models1 Email: nkhakpour@modares.ac.ir2 Email: sjalili@modares.ac.ir3 Email: clt@cs.stanford.edu4 Email: msirjani@ut.ac.ir5 Email: m.r.mousavi@tue.nlThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs147Khakpour et al.1 IntroductionMotivation Increasingly, software systems are subjected to adaptation at run-timedue to changes in the operational environments and user requirements. Adapta-tion is classified into two broad categories [1]: structural adaptation and behavioraladaptation. While structural adaptation aims to adapt system behavior by changingsystem’s architecture, the behavioral adaptation focuses on modifying the function-alities of the computational entities.There are several challenges in developing self-adaptive systems. Due to the factthat self-adaptive systems are often complex systems with greater degree of auton-omy, it is more difficult to ensure that a self-adaptive system behaves as intendedand avoids undesirable behavior. Hence, one of the main concerns in developing self-adaptive systems is providing mechanisms to trust whether the system is operatingcorrectly, where formal methods can play a key role.Zhang et al. [2] proposed a model-driven approach using Petri Nets for de-veloping adaptive systems. They also presented a model-checking approach forverification of adaptive system [3,4] in which an extension of LTL with ”adapt”operator was used to specify the adaptation requirements. In this work, systemwas modeled using a labeled transition system. Furthermore, authors in [5,6] usedlabeled transition systems at a low level of abstraction to model and verify embed-ded adaptive systems. Kulkarni et al. [7] proposed a theorem proving approach toverify the structural adaptation of adaptive systems.Flexibility is another main concern to achieve adaptation. Since, hard-codedmechanisms make tuning and adapting of long-run systems complicated, so weneed methods for developing adaptive systems that provide a high degree of flexi-bility. All the proposed formal models hard-code the adaptation logic which leadsto system’s inflexibility. Recently, the use of policies has been given attention as arich mechanism to achieve flexibility in adaptive system. A policy is a rule describ-ing under which condition a specified subject must (can or cannot) do an actionon a specific object. In [8,9,10,11,24], policies are used as a structural adaptationmechanism. Additionally, [12,13] proposed architectures for engineering autonomiccomputing systems that use policies for behavioral adaptations.This paper In this paper we propose a formal model called PobSAM (Policy-based Self-Adaptive Model) for developing and specifying self-adaptive systems thatemploys policies as the principal paradigm to govern and adapt system behavior. Wemodel a self-adaptive system as a collection of interacting actors directed to achieveparticular goals according to the predefined policies. A PobSAM model consistsof a set of Self-Managed Modules(SMMs). An SMM is composed of a collection ofautonomous managers and managed actors. Autonomous managers are meta-actorsresponsible for monitoring and handling events by enforcing suitable policies. Eachmanager adapts its policies dynamically in response to the changing circumstancesaccording to adaptation policies. The behavior of managed actors is governed bymanagers, and cannot be directly controlled from outside.PobSAM has a formal foundation that employs an integration of algebraic for-malisms and Actor-based models. The computational (functional) model of Pob-SAM is based on actor-based models while an algebraic approach is proposed to148Khakpour et al.specify policies of managers. Operational semantics of PobSAM is described withlabeled transition systems. The proposed model is suitable for cases where the setof governing policies of each context is known in advance.In our previous work [14], we proposed a formal model for policy-based self-adaptive systems using an actor-based language Rebeca [15]. In [14], we addedpolicies as rules to the Rebeca code and we focused on policy conflict detection.Combining adaptation concerns with system functionality in [14] increases the com-plexity of the model as well as the formal verification process. In order to addressthese drawbacks, we need an approach in which adaptation concerns are separatedfrom system functionality. Here, we extracted the policy rules, specified by an al-gebraic formalism, from Rebeca code. Moreover, the policies are presented in twoclasses, separating the policies governing the actor behavior from the policies whichdetermine the adaptation strategy (when and how the system passes the adaptationphase safely). Additionally, here we added modules as an encapsulation mechanismin which each module can manage itself autonomously.Contribution Formal methods are proposed for the analysis of adaptive systems,mainly at the low levels of abstraction, and flexible policy-based approaches areproposed for designing adaptive systems without formal foundation. Here, we pro-pose a flexible policy-based approach with formal foundation to support modelingand verification of self-adaptive systems. Policies allow us to separate the rules thatgovern the behavioral choices of a system from the system functionality giving us ahigher level of abstraction; so, we can change system behavior without changing thecode or functionality of the system. We are also concerned about the adaptationstrategy, to pass the adaptation phase safely and at the right moment. As an ex-ample, we are able to change and reason about the scheduling of jobs using policiesindependent of the system code. Although our approach can support both structuraland behavioral adaptation, in this paper, we focus on the behavioral adaptation.The formal foundation, the modular model, and separation of adaptation rules willhelp us in developing rigorous analysis techniques.Structure of the paper This paper is organized as follows. In Section 2 weintroduce an example to illustrate our approach. Section 3 introduces the PobSAMmodel in brief. Sections 4 and 5 introduce the syntax and semantics of PobSAMrespectively. Section 6 presents related work and compares our approach with theexisting approaches. In Section 7, we present our conclusions and plans for thefuture work.2 Smart HomeIn a home automation system, sensors are devices that provide smart home withthe physical properties of the environment by sensing the environment. In addition,actuators are physical devices that can change the state of the world in responseto the sensed data by sensors. The system processes the data gathered by thesensors, then it activates the actuators to alter the user environment according tothe predefined set of policies. Smart homes can have different features. Here, we takeinto account three features including: (1) The lighting control which allows lights toswitch on/off automatically depending on several factors. In addition, the intensity149Khakpour et al.of the lights placed in a room can be adjusted according to the predefined policies.(2) Doors/Windows management that enable inhabitants to manage windows anddoors automatically. In addition, if windows have blinds, these should be rolled upand down automatically too. (3) Heating control which allows inhabitants to adjustthe heating of the house to their preferred value. The heating control will adjustitself automatically in order to save energy.The smart home system is required to adapt its behavior according to thechanges of the environment. To this aim, we suppose that the system runs innormal, vacation and fire modes and in each context it enforces various sets ofpolicies to adapt to the current conditions. For the reason of space, here we onlyidentify policies defined for lighting control module while the system runs in normaland fire modes as follows:Defined policies in the normal modeP1 Turn on the lights automatically when night begins.P2 Whenever someone enters an empty room, the light setting must be set todefault.P3 When the room is reoccupied within T1 minutes after the last person has leftthe room, the last chosen light setting has to be reestablished.P4 The system must turn the lights off, when the room is unoccupied.Defined policies in the fire modeP1 Turn on the emergency light.P2 Disconnect power outlets.P3 When the fire is distinguished, turn off the emergency light.3 Modeling Concepts of PobSAMSelf-Managed Module (SMM) is the policy-based building block of PobSAM. APobSAM is composed of a set of SMMs. An SMM, in turn, may contain a numberof SMMs structured hierarchically. An SMM is a set of actors which can managetheir behavior autonomously according to predefined policies. PobSAM supportsinteractions of an SMM with the other SMMs in the model. To this aim, each SMMprovides well-defined interfaces for interaction with other SMMs. In the smart homecase study, we consider three SMMs including LightClModule, TempClModule andDWClModule to manage lighting, temperature and doors/windows respectively.An SMM structure can be conceptualized as the composition of three layersillustrated in Figure 1.• Managed Actors Layer This layer is dedicated to the functional behavior ofSMM and contains computational actors. Actors are governed by autonomousmanagers using policies to achieve predefined goals. Henceforth, we use the termsmanaged actors and actors interchangeably.• Autonomous Managers Layer Autonomous managers are meta-actors thatcan operate in different configurations. Each configuration consists of two classesof policies: governing policies, and adaptation policies. Using governing policies,150Khakpour et al.Fig. 1. The PobSAM Modelthe manager directs the behavior of actors by sending messages to them. Adap-tation policies are used to switch between different configurations to adapt themodule behavior properly. Moreover, a manager may has its local variables too.• View Layer In PobSAM, each actor provides its required state information tothe relevant managers. Not all aspects of the operational environment have di-rect influence on the behavior of managers, the views provide only the requiredinformation for managers. The view layer is composed of views that providesa view or an abstraction of an actor’s state that is adequate for the managers’needs. The distinction between the underlying computational environment andthe required state information of actors makes analyzing managers much simpler.Example 3.1 In our example, LightClModule module comprises an autonomousmanager named LightMngr, two light actors (light1 and light2 ), an outlet actor anda number of views indicating the overall light intensity of room and the status ofthe lights.4 PobSAM SyntaxFigure 2 shows a typical SMM containing manager meta-actors, views and actors,which we elaborate in the sequel.4.1 ActorsThe encapsulation of state and computation, and the asynchronous communicationmake actors a natural way to model distributed systems. Therefore, we use an actor-based model to specify the computational environment of a self-adaptive system.To this aim, an extension of Rebeca is used. Rebeca [15] is an actor-based languagefor modeling concurrent asynchronous systems which allows us to model the systemas a set of reactive objects called rebecs interacting by message passing. Eachrebec provides methods called message servers (msgsrv) which can be invoked byothers. Each rebec has an unbounded buffer for coming messages, called queue.151Khakpour et al.SMM SMM1ManagersManager ManagerName1(InitialConfiguration11)// definition of local variablesDatatype var1;// manager’s view;// definition of manager’s configurations in terms of// their governing and adaptaion policiesConfigurationsConfigurationName1={gp11,...,gp1m};...EndCPolicies//Definition of governing policies(gps)GoverningPolicyName1: on eventi if condi do actionsi;...//Definition of adaptation policies(aps)AdaptationPolicyName1:on eventj if condj switchto Configuration1 when condk priority Oj;...EndPEndM// definition of other managersEndMSViews//definition of viewsDatatype1 ViewName1 as expr1;Datatype2 ViewName2 as expr2;...EndVActors//definition of actorsreactiveclass Classname1() {Knownrebecs{}Statevars{ Public datatype v1;Private datatype v2;}msgsrv initial() {}msgsrv msgsrv1(){}}main {...Classname1 rebec1(...):(...);...}EndAEndSMMFig. 2. The Typical Syntax of a PobSAM ModelFurthermore, the rebecs’ state variables (statevars) are responsible of capturing therebec state. The known rebecs of a rebec (Knownrebecs) denotes the rebecs towhich it can send messages. In our extension, an actor can expose a number of itsstate variables to the managers (Figure 2). The exposed state variables are used inthe definition of views.Example 4.1 In the LightClModule SMM, the managed layer comprises a set oflight rebecs controlled by LightMngr. We consider a reactive class named Lightto model the lights which contains setIntensity, switchOn and switchOff messageservers as well as intensity and status state variables.4.2 ViewsIn PobSAM, the views are defined in terms of the public state variables of actors. Aview variable could be an actual state variable, or a function or a predicate applied to152Khakpour et al.state variables. Views enable managers not to be concerned about internal behaviorof actors and they provide an abstraction of actor’s state to managers.Example 4.2 In the LightClModule SMM, the LightMngr does not require theexact values of the lights intensities and providing overall intensity as low, mediumor high values is sufficient to decide. The overall intensity is defined based on theintensity statevar of the light rebecs as a view.4.3 ManagersIn our model, policies direct the system behavior, and adaptation is achieved bychanging policies. A manager can be in various configurations enforcing differentpolicy sets. As shown in Figure 2, a manager is defined in terms of its possibleconfigurations, its view of the actor layer and its local variables.Governing PoliciesWhenever a manager receives an event, it identifies all the policies that are trig-gered by that event. For each of these policies, the policy condition is evaluatedif one exists. If the condition evaluates to true, the action part of the triggeredpolicy is requested to execute by instructing the relevant rebecs to perform actionsthrough sending asynchronous messages. We express governing policies using asimple algebra as follows, in which P and Q indicate the policy sets:P,Qdef= P ∪Q|P −Q|P ∩Q|{p}|∅P ∩ Q means that intersection of policy sets P and Q is used to direct actors.P-Q reduces policy set P by eliminating all the policies in the second set Q. P ∪Qrepresents the union of P and Q governing the actors simultaneously. {p} denotes apolicy set with the simple policy p as its member. P ∩Q and P ∪Q are commutativeand associative.A simple action policy p=[o,ε,ψ, α] consists of priority o, event ε , optionalcondition ψ and action α. In PobSAM, events are defined as the execution of amessage server, sending a message to a rebec, creating new actor or holding a specificcondition in the system. Actions can be composite or simple. A simple action is ofthe form r.`(υ) which denotes message `(υ) is sent to actor r. Composite actionsare created by composing simple actions as follows:α, βdef= α;β|α ‖ β|α+ β|[ω?α : β]|r.`(υ)Thus a composite action can be the sequential (α;β) or parallel execution (α ‖ β) ofactions α and β. Also, an action can be chosen to execute non-deterministically(+).Term ([ω?α : β]) represents that action α is chosen to be executed if ω holds, elseβ will be chosen. + and ‖ are commutative and associative.Example 4.3 The governing policies of the lightMngr in the normal configuration153Khakpour et al.are as follows, where night, occpd, rccpd and unoccpd denote events and c1, c2, d1and d2 are arguments indicating the light intensity.pn1def= [1 ,night , true, light1 .switchon() ‖ light2 .switchon()]pn2def= [2 , occpd , true, light1 .setIntensity(d1 ) ‖ light2 .setIntensity(d2 )]pn3def= [3 , rccpd , true, light1 .setIntensity(c1 ) ‖ light2 .setIntensity(c2 )]pn4def= [4 , unoccpd , true, light1 .switchoff () ‖ light2 .switchoff ()]Adaptation PoliciesOne of the main characteristics of a formal model to specify a self-adaptive systemis considering adaptation semantics. To this end, we should deal with a numberof issues such as ”the time at which an adaptation is performed in the system”, ”the time at which the manager’s policies are modified” , ”the time at whichthe enforcement of new policies begin after modifying policies” or ”the ability torestricting the system behavior during adaptation”.Whenever an event requiring adaptation occurs, relevant managers in differentSMMs are informed. However, the adaptation cannot be done immediately andwhen the system reaches a safe state, the managers switch to the new configura-tion. Therefore, we introduce a new mode of operation named adaptation modein which a manager runs before switching to the next configuration. While themanager is in the adaptation mode, it is likely that events occur which need to behandled by managers. To handle these cases, we introduce two kinds of adaptationsnamed loose adaptation and strict adaptation. Under loose adaptation a managerenforces old policies, while under strict adaptation all events will be ignored untilthe manager exits the adaptation mode and the system reaches a safe state. Forexample in our smart home example, when LightMngr is in the fire configurationand there is a request for the vacation mode, while fire has not been put out, itkeeps enforcing policies of the fire configuration by switching to the loose adaptationmode. Also, when LightMngr is in the normal configuration, once fire is detected,it stops enforcing its current policies by switching to the strict adaptation mode.A simple configuration C is defined as C def= 〈P,A〉 where P and A indicatethe governing policy set and the adaptation policy of C respectively. Adaptationpolicies are defined using an algebraic language as follows:Adef= bDcδ,γ,λ,ϑ|A⊕Ain which D, δ , γ , λ and ϑ, respectively denote an arbitrary configuration, the con-ditions of triggering adaptation, the conditions of applying adaptation, adaptationtype (loose or strict) and the priority of adaptation policy. The simple adaptationpolicy, bDcδ,γ,λ,ϑ, specifies when the triggering condition δ holds and there is noother adaptation policy with the higher priority, the manager evolves to the strictor loose adaptation modes based on the value of λ. When the condition of applyingadaptation γ becomes true, it will perform adaptation. Adaptation policies of amanager is defined as the composition, ⊕, of the simple adaptation policies. Here,composition of two policies means that those policies are potentially to be triggered.154Khakpour et al.⊕ is associative and commutative. D is defined as follows where ω is an arbitrarycondition:D,D′ def= [ω?D : D′]|D2D′|CTerms [ω?D : D′] and D2D′ represent conditional and non-deterministic choicesrespectively. In conditional choice, configuration D is chosen if ω holds, else D′ willbe chosen. Non-deterministic choice means that the choice between configuration Dor D′ is made non-deterministically. This operator is associative and commutative.Example 4.4 In our smart home example, there are three configurations includingCn, Cv and Cf . Formal specification of lightMngr ’s configurations are as followsin which pmj denotes policy j defined in mode Cm. vacReq, fire, firePutout andcomebackHome are events while isPutout , isCnfrmd and onVac are lightMngr ’slocal variables. As an example, when the lightMngr is in the fire mode and there isa request for going on vacation, while fire has net been put out, it can not switchto the Cv configuration.Cndef= 〈{pn1 , pn2 , pn3 , pn4}, bCf cfire,true,S ,1 ⊕ bCvcvacReq,isCnfrmd ,L,2 〉Cfdef= 〈{pf1 , pf2 , pf3}, bonVac?Cv : CncfirePutout ,true,L,1 ⊕ bCvcvacRequest ,isPutout ,L,2 〉Cvdef= 〈{pv1 , pv2 , pv3 , pv4 , p5}, bCf cfire,true,S ,1 ⊕ bCnccomebackHome,true,L,2 〉5 Operational Semantics of PobSAM5.1 Operational Semantics of Actors and ViewsThe operational semantics of our extension of Rebeca does not differ from that ofRebeca[15]. However, any changes in state of the rebecs used in the definition ofviews must be reflected to the views. Let I1, I2, . . . , In denote the defined viewsof SMM S and η denote the set of defined events that S is concerned with. Thestate of a view is determined by its current value that is modified by the relatedevents occurring at the actor level. After execution of a message server, the changesof public state variables must be reflected in the views state, too. We specify theoperational semantics of the view layer as a labeled transition system.Let SB, AB and TB ⊆ SB×AB×SB be the set of states, the set of actions and thestate transition relation of the transition system of the actor layer respectively. Thestate transition relation of the view layer TI ⊆ SI ×AI ×SI is defined based on TB,where SI and AI are the set of states and the set of actions of the view layer transi-tion system respectively and SI = 〈I1, I2, ..., In〉. Suppose Ij(x1, x2, .., xm) denotesan arbitrary view defined on public state variables x1, x2, .., xm and Ij |σs denotes thestate of Ij , where its state variables are substituted with their corresponding valuesin state σsinSB. For each triple 〈σs, a, σt〉 ∈ TB, we consider an associated transition〈σ′s, a, σ′t〉 ∈ TI where σ′s = 〈I1|σs , I2|σs, ..., In|σs〉 and σ′t = 〈I1|σt , I2|σt , ..., In|σt〉 ifand only if a∈ η or ∃Ik|1 ≤ k ≤ n ∧ Ik|σs 6= Ik|σt , i.e.σsa−→σt ∈ TB, (a ∈ η) ∨ (∃Ik|1 ≤ k ≤ n ∧ Ik|σs 6= Ik|σt)σ′sa−→ σ′t155Khakpour et al.(NPE1)R = {p|(p.ε ∧ p.ψ) = true} ∧ R 6= ∅M∅,∅C[0] ε,τ−→ [M]R,∅C[0](NPE2) p ∈ R ∧ (@q ∈ R|q.o > p.o)[M]R,∅C[0] p.ε∧p.ψ,enf(p)−−−−−−−−−→ [M]R,pC[p.α](NPE3) α −→ α′[M]R,pC[α+ β] true,τ−→ [M]R,pC[α′](NPE4)[M]R,pC[[ω?α : β]] ω,τ−→ [M]R,pC[α](NPE5)[M]R,pC[[ω?α : β]] ¬ω,τ−→ [M]R,pC[β](NPE6) α→ α′[M]R,pC[α ‖ β] true,τ−→ [M]R,pC[α′ ‖ β](NPE7)[M]R,pC[r.`(υ); r′.`′(υ′)] `,`′ /∈{sendAck,waitAck},τ−−−−−−−−−−−−−−−−→[M]R,pC[r.`(υ); r.sendAck(r′);r′.waitAck(sendAck(r′)); r′.`′(υ′)](NPE8)[M]R,pC[r.`(υ);β]true,send(r,`(υ))−−−−−−−−−−→ [M]R,pC[β](NPE9)[M]R,pC[0] true,τ−→ [M]R−p,∅C[0](NPE10)[M]∅,∅C[0] true,τ−→ M∅,∅C[0]Fig. 3. Rules of policy enforcement5.2 Operational Semantics of ManagersWe use a labeled transition system to define the operational semantics of managersin which labels have two components. The first component indicates the activationcondition of the transition while the second component denotes the action of thetransition. Assume that M is a logical expression defined on state variables, thetransitions are of the form PM,a−→Q meaning “if M holds then P has an action aleading to Q”. Henceforth, we denote a transition by Pµ−→Q where µ = (M,a).The behavior of a manager depends on the mode in which it is running. Amanager can run in different modes such as normal execution, adaptation and policyenforcement. To distinguish managers in different modes, we use different notations.Let [M]sR,pC[α] indicate manager M in the enforcement mode in which,• C is the configuration in which M is running and C def= 〈P,A〉.• R is the set of triggered policies to be enforced.• p is the current policy being enforced by M.• α is the action of a recent policy being executed by M.• s denotes M’s view of current context in addition to its local variables.Ms∅,∅C[0], |M|sR,pC[α] and ‖M‖s∅,∅C[0] indicate M in normal execution, looseadaptation and strict adaptation modes respectively. We ignore s in the definitionof operational semantics of managers.Policy enforcement semanticsWhenever an event is received by a manager, it identifies all the triggered policieswith the policy condition evaluated to true. Then it enforces the identified policies156Khakpour et al.based on their priorities. Once a manager enforces all the triggered policies, itevolves to normal mode. Figure 3 gives rules of policy enforcement.Using NPE1 manager switches to the enforcement mode by identifying the trig-gered policies to be enforced. NPE2 places the action of a policy with the highestpriority in the action part of the manager to be run. NPE3, NPE4 and NPE5 de-fine the semantics of non-deterministic and conditional choices of actions. NPE7 isconsidered to apply two sequential actions in which r′ is an arbitrary actor. To thisaim, we use synchronous message passing provided by Extended Rebeca [16]. Thecorresponding actors of two sequential actions are synchronized after execution ofthe first action. We considered two message servers for each reactive class namedsendAck(r) and waitAck(r) which sends and receives a synchronization messageto and from rebec r respectively. NPE8 expresses sending a message to an actorand removing it from the list of actions to be executed. After applying policy p,NPE9 will remove p from the list of activated policies. When there is no policy tobe enforced, manager will switch to normal execution mode using NPE10.As mentioned above, managers in loose adaptation mode are able to enforcepolicies. Therefore, all the rules introduced for the enforcement mode, except forNPE10, are applicable in loose adaptation mode too.Policy adaptation semanticsFor the sake of readability, we omit p, [α] and R symbols of managers in nor-mal execution and strict adaptation modes. Figure 4 shows rules for adaptation instrict mode in which B, A′ and B′ denote arbitrary adaptation policies. Further-more, F and D′′ denote a simple adaptation policy and an arbitrary configuration,respectively.(SA1) @F ∈ A|(ϑ < F.ϑ ∧ F.δ = true)M〈P, bDcδ,γ,λ,ϑ ⊕A〉 δ∧λ,τ−−−→ ‖M‖〈P, bDcδ,γ,λ,ϑ〉(SA2)‖M‖〈P, bDcδ,γ,λ,ϑ〉 γ,adapt−−−−→M∅,∅D(SA3) M〈P,B〉µ−→M〈P,B′〉M〈P,A⊕B〉 µ−→M〈P,A⊕B′〉 (SA4)M〈P,A〉 µ−→M〈P,A′〉M〈P,A⊕B〉 µ−→M〈P,A′ ⊕B〉(SA5)‖M‖〈P, bDcδ,γ,λ,ϑ〉 µ−→‖M‖〈P, bD′cδ,γ,λ,ϑ〉‖M‖〈P, bD¤D′′cδ,γ,λ,ϑ〉 µ−→‖M‖〈P, bD′cδ,γ,λ,ϑ〉(SA6)‖M‖〈P, bDcδ,γ,λ,ϑ〉 µ−→‖M‖〈P, bD′cδ,γ,λ,ϑ〉‖M‖〈P, bD′′¤Dcδ,γ,λ,ϑ〉 µ−→‖M‖〈P, bD′cδ,γ,λ,ϑ〉(SA7)‖M‖〈P, bω?D:D′cδ,γ,λ,ϑ〉 ω,τ−→‖M‖〈P, bDcδ,γ,λ,ϑ〉(SA8)‖M‖〈P, bω?D:D′cδ,γ,λ,ϑ〉¬ω,τ−→‖M‖〈P, bD′cδ,γ,λ,ϑ〉Fig. 4. Rules of strict adaptationSA1 states that in the case of strict adaptation, when adaptation policy condi-tions hold, manager M switches to the strict adaptation mode. SA2 asserts that157Khakpour et al.when the condition for applying the adaptation holds, M will evolve to normalmode and run configuration D. SA5, SA6, SA7 and SA8 define the semantics ofnon-deterministic and conditional choices of configurations. SA5, SA6, SA7 andSA8 rules have a higher priority than SA2. To this aim, we use the ordered SOS(Structural Operational Semantics) framework [17] and place SA5, SA6, SA7 andSA8 above SA2. Rules of loose adaptation are identical to strict adaptations rulesexcept for SA1 which is as @F ∈ A|(ϑ < F.ϑ ∧ F.δ = true)M〈P, bDcδ,γ,λ,ϑ ⊕A〉δ∧¬λ,τ−→ |M|〈P, bDcδ,γ,λ,ϑ〉(LA1).5.3 Interaction of Managers and ViewsThe other kind of transitions is related to the interaction of managers and viewlayer. Figure 5 demonstrates rules for interaction of managers and the view layerof S where σsa→σt ∈ TI and t indicates the new state of M . sv and tv are definedas the projection of σs and σt on M ’s view respectively, i.e. sv = σs ↑ M.v andtv = σt ↑ M.v. Construct σs ↑ M.v denotes only the state variables of σs that arein M.v too. IR1, IR2, IR3 and IR4 express changing M’s view of the view layerby state changing at the view layer in the normal, enforcement, loose adaptationand strict adaptation modes respectively, where s(t) is union of sv(tv) and lv. lvindicates the current state of M in terms of its local variables.(IR1) σsa−→ σt,∃Ij ∈ s|Ij |σs 6= Ij |σtMs∅,∅〈P,A〉[0]true,τ−→ Mt∅,∅〈P,A〉[0](IR2) σsa−→ σt, ∃Ij ∈ s|Ij |σs 6= Ij |σt[M]s∅,∅〈P,A〉[0]true,τ−→ [M]t∅,∅〈P,A〉[0](IR3) σsa−→ σt, ∃Ij ∈ s|Ij |σs 6= Ij |σt|M|sR,p〈P,A〉[0] true,τ−→ |M|tR,p〈P,A〉[0](IR4) σsa−→ σt, ∃Ij ∈ s|Ij |σs 6= Ij |σt‖M‖s∅,∅〈P,A〉[0]true,τ−→ ‖M‖t∅,∅〈P,A〉[0]Fig. 5. Rules for interaction of managers and the view layer6 Discussion and Related WorkFlexibility of self-adaptive systems is realized by three different features includingseparation of concerns, computational reflection and component-based design [18].We explain how PobSAM can address these requirements in the sequel.PobSAM decouples the adaptation logic of an SMM from its business logic de-scribed at an abstract level using policies. Among the proposed formal approachesto model adaptive systems, [2,20,21] combine the adaptation logic into the busi-ness logics. In [3,6,19] the adaptation concerns have been separated; however, allthe proposed formal models hard-code the adaptation logic which leads to system’sinflexibility. The proposed model permits us to direct/adapt system behavior byenforcing/modifying policies at an abstract level without re-coding actors and man-agers; thereby it leads to increasing system flexibility and scalability.Computational reflection is the ability of a system to monitor and change itsbehavior subsequently. In PobSAM, managers monitor actor’s behavior throughviews and direct/adapt SMMs behavior. Policies provide us a high-level descriptionof what we want without dealing with how to achieve it. Thus, using policies can bea suitable mechanism to determine if the goals were achieved using existing policyrefinement techniques.158Khakpour et al.Furthermore, PobSAM uses SMM as a policy-based building block for a modu-lar model where each component is able to adapt its behavior autonomously. Thisnotion makes PobSAM a suitable model to specify self-organizing and cooperatingsystems too. Although, in this paper we focused on behavioral adaptation, how-ever, PobSAM can support structural adaptation by joining/leaving an actor or anSMM to/from an SMM dynamically, which is an advantage over the most existingapproaches that concentrate on one adaptation type. SMM notion is similar toSelf-Managed Cell (SMC) notion proposed in [13] as a paradigm for engineeringubiquitous systems. In this work, an SMC consists of a set of components thatconstructs an autonomous management domain.One of the main aspects of modeling a self-adaptive system is specifying adapta-tion requirements. To this aim, we introduced a two phases adaptation strategy topass the adaptation phase safely. Upon receiving an adaptation event by a manager,it switches to the adaptation mode. Adaptation mode models transient states dur-ing adaptation. When the system reaches a safe state, the adaptation is completedby evolving the manager to the new configuration. We believe that the modularnature of adaptation policies enables us to express adaptation requirements easilyand at the high-level of abstraction.As stated above, PobSAM has decoupled the adaptation layer from the func-tional layer. Thus, we can verify the adaptation layer independently from the actorlayer provided that we have a labeled transition system modeling view behavior.This feature can decrease the complexity of verification procedure.Dynamic adaptation is a very diverse area of research. While structural adapta-tion has been given strong attention in the research community(see [22]), fewerapproaches tackle behavioral adaptation as we considered. Due to the lack ofspace, we restrict ourselves to present related work done on formal modeling ofself-adaptive systems in addition to applying policy-based approaches in engineer-ing of self-adaptive systems.Formal verification of adaptive systems is a young research area [23] and onlya few research groups already focused on this topic. A model-driven approach wasproposed for developing adaptive systems in [2]. In this approach, there are dif-ferent behavioral variants of a process modeled as Petri Nets. At each time, onePetri Net runs and reconfiguration is carried out by switching between various PetriNets. In another work [3], they modeled a system as a set of steady-state programsamong which the system switches. An extension of LTL with “adapt“ operatorwas used to specify adaptation requirements before, during and after adaptation[4]. Then, they use a model checking approach to verify the system. Kulkarni etal. [7] proposed an approach based on the concept of proof lattice to verify if asystem is in a correct state during and after adaptation in terms of satisfying thetransitional-invariants. Furthermore, Schneider et al. [5] presented a method todescribe adaptation behavior at an abstract level. After deriving transition systemsfrom a system description, they verify the system using model checking. In theirlater work [6], they proposed a framework for model-based development of adaptiveembedded systems using labeled transition systems. In this work, they verify differ-ent properties using theorem proving, model checking and specialized verificationmethods. [19] proposed a coordination protocol for distributed adaptation of the159Khakpour et al.component-based systems and used Colored Petri Nets for formal verification. Inour model, adaptation is performed by applying suitable policies in different con-texts, which in nature differs from the proposed approaches. We have proposed aformal model of policy-based self-adaptive systems using Rebeca concentrated onpolicy conflict detection [14]. Combining adaptation concerns with system func-tionality in this approach causes an increase in the complexity of model as well asformal verification process.Employing policies as a paradigm to adapt self-adaptive systems has been givenconsiderable attention during recent years. Work in [8,9,10,11,24,26] used policiesas the adaptation logic for structural adaptation, while we use policies as a mech-anism for governing as well as adapting system behavior. Furthermore, [24] usedpolicies for a simple type of behavioral adaptation named parameterization, too.[25] proposed an adaptive architecture for management of differentiated networkswhich performs adaptation by enabling/disabling a policy from a set of predefinedQoS policies, but this architecture does not have formal foundation. Anthony [26]presents a policy definition language for autonomic computing systems in whichthe policies themselves can be modified dynamically to match environmental con-ditions. However, this work does not deal with modeling system and it is limitedto proposing an informal policy language.7 Conclusions and Future WorkWe proposed PobSAM as a formal model to develop self-adaptive systems whichuses policies as the main mechanism to govern and adapt the system behavior. Tothis aim, we model a system as the composition of a set of autonomous componentsnamed SMMs. Each SMM contains two types of actors: managed actors that arededicated to the functional layer of system and autonomous managers that coordi-nate actors to achieve the predefined goals using policies. This model integrates twoformal methods including algebra and actor-based model to specify a system. Then,we presented the operational semantics of PobSAM by means of labeled transitionsystems.There is much more research to pursue in the area of verification of self-adaptivesystems. In this paper, we focused on formal modeling of self-adaptive systems.Verification of different properties of adaptation and functional layers of PobSAMmodels is an ongoing work. We are going to implement a tool to support our ap-proach too. As our model can support both behavioral and structural adaptations,our future researches will be concentrated on specifying structural adaptations. Ex-tending this model for modeling self-organizing systems in which managers need tocoordinate together is considered as a future work, too.References[1] C. Hofmeister, “Dynamic Reconfiguration, Ph.D. Thesis” in Computer Science Department, Universityof Maryland, College Park 1993.[2] J. Zhang and B. Cheng, “Model-Based Development of Dynamically Adaptive Software”, in Proceedingsof International Conference on Software Engineering, 2006, pp. 371-380.160Khakpour et al.[3] J. Zhang, H. J. Goldsby, and B. H. C. Cheng, “Modular verification of dynamically adaptive systems”,in the 8th ACM international conference on Aspect-oriented software development, Charlottesville,Virginia, 2009, pp. 161-172.[4] J. Zhang and B. H. C. Cheng, “Using temporal logic to specify adaptive program semantics”, Journalof Systems and Software, Architecting Dependable Systems, vol. 79, pp. 1361-1369, 2006.[5] K. Schneider, T. Schuele, and M. Trapp, “Verifying the adaptation behavior of embedded systems”,in Proceedings of the 2006 international workshop on Self-adaptation and self-managing systems,Shanghai, China, 2006, pp. 16 - 22.[6] R. Adler, I. Schaefer, T. Schuele, and E. Vecchie, “From Model-Based Design to Formal Verificationof Adaptive Embedded Systems”, in Proceedings of International Conference on Formal EngineeringMethods, 2007, pp. 76-95.[7] S. S. Kulkarni and K. N.Biyani, “Correctness of Component-Based Adaptation”, in Component-BasedSoftware Engineering, 2004, pp. 48-58.[8] R. J. Anthony and C. Ekelin, “Policy-driven self-management for an automotive middleware”, inProceedings of 1st International Workshop on Policy-Based Autonomic Computing Florida, USA, 2007.[9] C. Efstratiou, K. Cheverst, N. Davies, and A. Friday, “An Architecture for the Effective Support ofAdaptive Context-Aware Applications”, in Proceedings of the 2nd International Conference in MobileData Management (MDM‘01), Hong Kong, 2001, pp. 15-26.[10] C. Efstratiou, K. Cheverst, N. Davies, and A. Friday, “Utilising the Event Calculus for Policy DrivenAdaptation in Mobile Systems”, in Proceedings of the 3rd International Workshop on Policies forDistributed Systems and Networks, Monterey, California., 2002, pp. 13-24.[11] G. Phil and B. Lynne, “A Framework for Policy Driven Auto-adaptive Systems Using Dynamic FramedAspects”, in Transactions on Aspect-Oriented Software Development II. vol. LNCS 4242, 2006, pp. 30-65.[12] “Autonomic computing”, IBM Systems Journal, vol. 42, 2003.[13] M. Sloman and E. Lupu, “Engineering Policy-Based Ubiquitous Systems”, The Computer Journal, toappear, 2009.[14] N. Khakpour, R. Khosravi, M. Sirjani, and S. Jalili, “A Formal Model for Policy-based Self-AdaptiveSystems”, Submitted, 2009.[15] M. Sirjani, A. Movaghar, A. Shali, and F. S. d. Boer, “Modeling and Verification of Reactive Systemsusing Rebeca”, Fundamenta Informaticae, vol. 63, pp. 385-410, 2004.[16] M. Sirjani, F. d. Boer, A. Movaghar, and A. Shali, “Extended Rebeca: A Component-Based ActorLanguage with Synchronous Message Passing”, in Proceedings of the Fifth International Conference onApplication of Concurrency to System Design: IEEE Computer Society, 2005.[17] M. Mousavi, I. Phillips, M. A. Reniers, and I. Ulidowski, ”Semantics and expressiveness of orderedSOS,” Information and Computation, vol. 207, pp. 85-119, 2009.[18] P. K. McKinley, S. M. Sadjadi, E. P. Kasten, and B. H. C. Cheng, “A Taxonomy of CompositionalAdaptation”, Michigan State University Technical Report MSU-CSE-04-17, 2004.[19] N. H. Kacem, A. H. Kacem, and K. Drira, “A Formal Model of a Multi-step Coordination Protocol forSelf-adaptive Software Using Coloured Petri Nets”, International Journal of Computing and InformationSciences , 2009. To appear.[20] K. N. Biyani and S. S. Kulkarni, “Concurrency and Complexity in Verifying Dynamic Adaptation: ACase Study”, Michigan State University Technical Report MSU-CSE-05-21, August 2005.[21] M. Gudemann, F. Ortmeier, and W. Reif, “Safety and Dependability Analysis of Self-AdaptiveSystems”, in the 2nd International Symposium on Leveraging Applications of Formal Methods,Verification and Validation, 2007, pp. 177-184.[22] J. S. Bradbury, J. R. Cordy, J. Dingel, and M. Wermelinger, “A survey of self-management in dynamicsoftware architecture specifications”, in Proceedings of the International Workshop on Self-ManagesSystems, Newport Beach, USA, 2004.[23] B. H. C. Cheng, H. Giese, P. Inverardi, J. Magee, and R. d. Lemos, “Software Engineering for Self-Adaptive Systems: A Research Road Map”, in Software Engineering for Self-Adaptive Systems 2008.[24] D. Pierre-Charles and L. Thomas, “Towards a Framework for Self-adaptive Component-BasedApplications”, in Proceedings of Distributed Applications and Interoperable Systems. LNCS2893, 2003,pp. 1-14.[25] L. Lymberopoulos, E. Lupu, and M. Sloman, “An Adaptive Policy Based Management Frameworkfor Differentiated Services Networks”, in Proceedings of IEEE Workshop on Policies for DistributedSystems and Networks, Monterey, California, Los Alamitos, California, 2002, pp. 147-158.[26] R. J. Anthony, “Generic Support for Policy-Based Self-Adaptive Systems”, in Proceedings of the 17thInternational Conference on Database and Expert Systems Applications, 2006, pp. 108-113.161162FACS 2009A systematic approach to constructcompositional behaviour models fornetwork-structured safety-critical systemsJohannes Kloos and Robert Eschbach1Testing and InspectionsFraunhofer Institute for Experimental Software EngineeringKaiserslautern, GermanyAbstractThis paper considers the problem of model-based testing of a class of safety-critical systems. These systemsare built up from components that are connected a network-like structure. The number of possible structuresis usually large. In particular, we consider the following issue: For many of these systems, each instanceneeds its own set of models for testing. On the other hand, the instances that should be tested will have tobe chosen so that the reliability statements are generally applicable. Thus, they must be chosen by a domainexpert. The approach in this paper addresses both of these points. The structure of the instance of systemunder test is described using a domain-specific language, so that a domain expert can easily describe a systeminstance for testing. At the same time, the components and composition operators are formalized. Using astructure description written in the DSL, corresponding test models can be automatically generated, allowingfor automated testing by the domain expert. We show some evidence about the feasibility of our approachand about the effort required for modelling an example, supporting our belief that our approach improvesboth on the efficiency and the expressivity of current compositional test model construction techniques.1 IntroductionSafety-critical embedded systems such as control applications in industrial automa-tion or train automation are very complex due to their broad range of possibleapplications. Among these systems, industrial plant controllers, railroad coordina-tion systems, logistic planning systems etc. form a class that is especially adaptableto many different application scenarios. One thing that is common to many of thesesystems is that they control an underlying network of physical entities that are con-nected in some way, often with several hierarchy levels. The network formed by theseentities induces data flows between neighbouring components and vertically throughthe different levels of hierarchy. These data flows are observed and manipulated bythe control system. As an example, a railway control system for a given segmentof the railroad network will use the underlying structure of the tracks, switches and1 Email: 〈firstname〉.〈lastname〉@iese.fraunhofer.deThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs163Kloos and EschbachFig. 1. An example of a hierarchical network structure: The European high-speed railroad network and adetail, Kaiserslautern stationsignals on the lowest level of its internal model, aggregating them into larger controlunits that finally form the network (cf. figure 1). We will call this kind of systemsnetwork-structured systems.To handle the complexity inherent in these structures, one way to constructsuch embedded control systems is a modular, component-based approach. For eachinstallation of such a system, e.g., for a given industrial plant or a given railwaynetwork, an instance of the embedded system is created by instantiating some basiccomponent types and plugging them together in an appropriate way. For many ofthese systems, one finds that the number of possible instances, is huge and effectivelyunbounded.From the perspective of quality assurance it is not clear how to test such ahuge space of instances w.r.t. different quality properties like correctness, safety orreliability. Reliability is one of the most important non-functional quality propertiesof embedded software systems required by contract or different standards like the164Kloos and EschbachIEC 61508 [10], IEC 61511 [9], CENELEC 50126 [3], ISO CD 26262 [11] or DO178B[17]. Measures like mean time between failures (MTBF) or failure rates are typicalreliability indicators.The problems that a tester faces for these systems are twofold: For one thing,which instances should be tested? If one is interested in generally applicable state-ments about system reliability, a set of instances that exercises the handling ofcritical situations is required. In most cases, only a domain expert will be able todecide exactly which instances are relevant here.On the other hand, even if the instances to test are known, one still has togenerate test cases for each of these instances. When one tries to demonstratethe reliability of a system, a large number of test cases per instance is necessary.Multiplied with the number of instances, the amount of required test cases becomeshuge.A common approach to solve the problem of test case construction is the au-tomatic generation of test cases. Among the possible method for generating testcases, model-based test approaches form an important and well-researched subclass.These techniques generate test cases (i.e., test inputs and expected results) fromone or more models that describe the behaviour of the system and/or the system'senvironment. These models are known as test models.When testing for reliability, one usually chooses techniques that generate testcases based on the operational profile of the system, allowing unbiased estimationsof reliability measures. One of these techniques is Model-Based Statistical Testing[20], also known as Statistical Testing. This approach uses a description of thepossible system inputs from a user's point of view to generate test cases. Thisdescription is formalized as a Markov chain of possible input event sequences. Theexpected outputs can either be annotated to the Markov chain, or calculated usinga second model, the system model, for more complicated systems.When trying to apply model-based testing techniques to network-structured sys-tems, one finds that each instance requires test models tailored to the underlyingnetwork structure. To avoid the overhead of generating test models for each instance,it appears worthwhile to construct test models for each instance from some generalinformation and the description of the concrete instance. As the structure of theinstances lends itself to a natural composition-based description, a component-basedapproach seems promising. Naturally, this approach must be designed in such a waythat the instance description given by the domain expert can easily be translatedinto an instance of the test models.Given some method that can be used to construct test models for a network-structured system from pre-defined components and a description of the systeminstance by a domain expert, it becomes possible to carry out testing of this systemwith little work for each instance, as the most labour-intensive step, namely theconstruction of the test model components, has to be done only once, and thetranslation from the domain expert's representation of an instance to test cases canbe fully automated (cf. figure 2). Moreover, this approach allows the domain expertsto carry out (parts of) testing without the burden of having to learn the details oftesting the system under consideration.In this paper, we present an approach called COMPOSE that allows for the165Kloos and EschbachFig. 2. Elements of the approachsystematic compositional construction of test models using domain-specific infor-mation. This approach comprises an integrated technique to describe state-basedcomponent behaviour and compose these components according to a specificationgiven in a domain-specific language.We believe that our approach improves both the efficiency and the expressivitycompared to state-of-the-art work in the compositional construction of test models.In particular, we state the following claims:(i) Constructing one composite model using the modelling techniques of COM-POSE does not require more effort than using other techniques.(ii) The construction of several composite models for different system instances ismore efficient using COMPOSE when compared to other techniques.(iii) The resulting models produce identical test results.The rest of this paper is organized as follows: In section 2, prior work is described.The COMPOSE approach is described in section 3. It is illustrated by a runningexample. Section 4 describes how we plan to evaluate our approach with the claimsstated above, and gives some preliminary results. Finally, we summarize our workand point out further improvements and directions.2 Related WorkMany ideas in this paper are based on common ideas found in component-basedsoftware and model-based engineering. The focus of this paper is not on extendingthese results, but rather on the application of these techniques to software testing,in particular, to model-based testing. It continues the work of a prior case studyfrom the railway domain, which has been described in [12]. As noted there, the useof domain-specific languages for describing compositional models is, in itself, not anew idea; see, e.g., [7].Often, composition operators are given by describing the action of the operatorin natural language, usually together with a mathematical specification (cf. [5,21,13]and various others). We are not aware of any formalizations of composition operatorsin some machine-readable language, except for some simple examples of operatorsfor process calculi [14].Most model-based testing methods are based on automata or Markov chains.166Kloos and EschbachApart from the most commonly described composition operators, namely differentforms of parallel composition [18], some more general operators have been definedin the literature.For Markov chains, only few compositional approaches exist. Parallel composi-tions are obvious candidates, but are subsumed in other approaches. One generalapproach that we found is known as Stochastic Automata Networks [4]. It describesa Markov chain as a set of stochastic automata. These automata can interact us-ing synchronized events (i.e., some transitions of the Markov chains are labelledusing an event name and may only fire simultaneously) and functional rates (i.e.,a transition rate may depend on the current state of some other Markov chain).Another approach is the Test Generation Language [15], which describes how stimu-lation sequences generated by several different Markov chains can be woven into onestimulation sequence for testing. This is done by giving several operators workingon event sequences. In our experience, using a high-level approach like the TestGeneration Language is preferable, as it allows clearer descriptions of intent.For Mealy automata and more general state-event systems, a number of com-positional techniques exist. First of all, Statecharts [6] can be seen as a methodto describe the composition of state-event systems in a compact notation. An-other approach is the use of communicating automata, for example in UPPAAL [2].Further compositional approaches have cropped up in the area of Model-Driven De-velopment. Some of these approaches (e.g. [19]) describes connectors using processcalculi, which is quite close to the approach taken here. As our goal was to havea single technique for the construction of composite Markov chain models and sys-tem models, these approaches were not directly applicable to our problem, as theseapproaches do not provide appropriate handling for Markov chains.Choosing a different point of view, model-based testing needs to generate se-quences of stimulus events. When abstracting away the details of which underlyingmodel is used, we are left with event-generating processes. These processes can benaturally described using process calculi, such as the pi calculus. Indeed, the pi calcu-lus [14] already has a notion and graphical notation for the composition of differentcommunicating processes. By modelling both component models and compositionoperators as communicating processes, one can use this kind of process compositionto easily describe complex models.3 The approachIn the following, the approach sketched above will be described in detail. As arunning example, the construction of a behavioural model for a Train Control System[12,22] will be shown.The approach has five steps:(i) Identify the atomic components.(ii) Determine appropriate composition operators.(iii) Describe the behaviour of the atomic components using finite-state automata.(iv) Define the behaviour of the composition operators, using the stimulus streammodel described below.167Kloos and EschbachS1 S3 S5S2 S4B2B3B5B6B1 B4 B7Fig. 3. An example track layout. Notation: The black triangles labeled S1 etc. are switches. B1 up to B7are blocks, whose borders are the dashes lines.(v) Define a DSL that uses the composition operators and atomic components tobuild a system model from the domain description.Usually, one wishes to have a direct mapping from syntactic components of theDSL to composition operators and atomic components. On the other hand, a trueone-to-one mapping will usually not be possible some information may be implicitin the domain description, or there may be extraneous information.For the example, an assistance system for a railway operating procedure knownas Zugleitbetrieb is modelled. This system is called ZLB-PS. Briefly, the operationof this system can be summarized as follows:(i) ZLB-PS is an assistance system that acts as substitute for the train sheet, apaper form that records the position and movement of trains as well as trackreservations.(ii) ZLB-PS uses track-side equipment (e.g. vacancy detectors) to counter-checkand enforce the train director's decisions. All track-side equipment is controlledby ZLB-PS.(iii) The railroad network is partitioned into blocks, which contain switches andother track-side equipment. Moving a train means moving it from one block toanother.(iv) ZLB-PS can be configured for arbitrary track layouts.(v) For a train to move from A to B, it must first reserve a track and ensure thatthis track is set up. During movement, it must notify the train director ofarrival and may also indicate departure.The track layouts used for ZLB-PS are network-like structures, which motivatesour use of this example. A simple but typical layout is depicted in figure 3.3.1 Identification of atomic componentsIn the first step, the basic components from which the test model is to be built mustbe identified. As a starting point, one starts from the domain expert's view of thesystem, choosing elements of this description as candidates for components. Thesecomponents are then compared against the (informal) description of the system.One may find that some components are not explicitly described in the systemrepresentation chosen above, e.g., with coordination components that have only oneinstance. These components are then added to the candidate set.The candidate set can then be considered element by element. One may findthat an element does not actually contribute to the behaviour being modelled ordoes not have a clear-cut behaviour. In this case, the element should be removed orreplaced be suitable other components.168Kloos and EschbachCompositionoperatorComponentComponentComponentinputoutputresultant componentFig. 4. The mechanics of composition operators; the arrows denote data streamsThis step may be iterated when new information from further steps is available,adding, removing or changing components as required. In any case, one should tryto keep a simple mapping from the DSL to the components.As a first approximation, one finds that the structure of a railroad network ismade up from lengths of track, switches and block borders. Looking at the system'srequirements, it can be seen that the block borders themselves as well as the lengthsof track are not directly considered, but make up parts of a block. Hence, oneexchanges the track and block border components for a block component.Also, signals are mentioned. As they can occur only on block borders, it is clearhow they can be modelled in the domain expert's description: they correspond toblock borders.Finally, it becomes clear that reservations et cetera are described on a level aboveblocks, therefore a small mediating component will be needed as well, the centralinterlocking unit (short CIU). The component types are summarized in Figure 4 asrectangles with thick borders.3.2 Determination of composition operatorsBased on the identified components and the set of possible configurations, one nextidentifies how these components should be composed. The composition of a set ofcomponents yields a new, larger component, allowing a hierarchical description ofthe resulting system.For this approach, one takes a black-box view of the components, describing theirbehaviour solely using streams of events entering and leaving the component. Thejob of the composition operator is to tie together the components by connecting totheir input and output streams and coordinating which data is sent to and receivedfrom each component (cf. Figure 4). The possible composition operators can rangefrom very simple operations, such as a simple scatter/gather operator that simplybroadcasts inputs to all attached components and passes through their outputs, tocomplex and application-specific operators.The railroad example will use two composition operators: At one level, a blockcontains its signals and switches, who can only operate correctly in cooperationwith their environment inside the block. Thus, a low-level composition operator is169Kloos and Eschbachdefined, which describes how a block instance is built up from switch models, signalmodels and the (abstract) model of a general block. This composition operatorneeds additional information, namely the concrete layout of switches, signals andconnections inside the block.The concrete block instances, together with the central interlocking unit, canthen form the description of the complete system. Here, the high-level compositionoperator is used, which describes how the signals from the CIU are distributed tothe concrete block instances. Again, this operator needs extra information, namelywhich blocks are neighbours of a given block.Again, a summary of the composition operators and their application is shownin Figure 4: The composition operators are shown as ellipses, their configurationinformation is given by the italic text and the components that are composed usinga composition operator are connected to it via arrows. The result of a compositionis given by a rectangle (with thin borders) surrounding all necessary information; itforms a new component, which can again be composed with other components.3.3 Describing the atomic componentsThe next step is the description of component behaviour. As single components aremodelled as Mealy machines, one can use various methods in this step, e.g. by directconstruction of the state/transition graph [8], by transformation from Statecharts(cf. [6]) or a wealth of other techniques (e.g., [16]).For the running example, sequence-based specification was chosen because back-wards traceability to the requirements was considered as an important requirement[12]. The application of this method yielded four Mealy machines, which are de-scribed in the paper just referenced.3.4 Describing the composition operatorsNow that the interfaces of the components are known, the composition operatorscan be constructed. To do this, one assumes that each Mealy machine is a (com-municating) process with an event input stream and an event output stream. Therole of a composition operator is thus to describe how several such Mealy machineprocesses can be connected to form a larger component with one or more input andoutput event streams (cf. the section on the determination of composition operators,especially Figure 4.A good way to describe the behaviour of a composition operator is to use a pro-cess calculus, such as CSP or the pi-calculus. The approach described in this paperis based on a (slightly extended) version of pi-calculus [14]. A companion versionof the stochastic pi-calculus exists as well, which is used to describe composition ofMarkov chain-based usage models for software testing. For reference, the followingsyntax is used for the pi calculus:Def ::= name '(' Patterns ')' ':=' ProcProcess definitionProc ::= '0' Null process| '(' Proc ')'| GuardedProcs170Kloos and Eschbach| Proc '|' Proc Parallel composition| 'replicate' Proc Proc is replicated, i.e.,infinitely many parallel copies are created| 'new' Bindings '.' Proc Introduction of new name bindings| name '(' Terms ')' Process instantiationGuardedProcs ::= GuardedProc| GuardedProc '+' GuardedProcsNondeterministic guarded choiceGuardedProc ::= Guard When the guard holds, do nothing| Guard Proc When the guard holds, performnew bindings and execute ProcGuard ::= var '(' Patterns ')' '?' Receive on channel, with data| var '?' Receive on channel, no data| var '(' Terms ')' ' !' Send on channel, with data| var ' !' Send on channel, no dataPatterns ::= Pattern | Pattern ',' PatternsPattern ::= var Accept any name/term, bind to var| '_' Dummy pattern, accept anything| name '(' Patterns ')' Constructor expression| name '(' ')' Empty constructor expressionTerms ::= Term | Term ',' TermsTerm ::= var The binding of var| name '(' Terms ')' Constructor expression| name '(' ')' Empty constructor expressionBindings ::= Binding | Binding ',' BindingsBinding ::= var Normal binding| var ':' 'imm' immediate bindingSemantics for the pi calculus are given in Milner's book [14], while our extensionsare described in a technical report [1].As there is a natural transformation from Mealy machines to pi processes, thecomposition of several Mealy machines using a given composition operator can bedescribed by assuming that the Mealy machines are given by processes M1 to Mk,and the composition operator by C. Then the resulting model is the pi processdefined similar to the following:Composite(in, out) ::=new in1, out1, ..., ink, outk.M1(in1, out1) | ... | Mk(ink, outk)| O(in, out, in1, out1, ..., ink, outk)In the following example, it will be shown that the pi calculus can be used as akind of programming language to describe the operational semantics of the com-position operators. This has several advantages:(i) It is easy to define application-specific operators.(ii) Tool support for model compositions is possible.171Kloos and Eschbach(iii) Operators can be built from other operators using simple language constructs,viz., process instantiation.For ZLB-PS, two composition operators have to be modelled. These compositionoperators built as far as possible using standard operators. At first, consider thegeneral structure of the operators.The high-level composition operator works as follows: An instance of the CentralInterlocking Unit is composed with a set of instances of concrete blocks. Whenevera stimulus describing some operation on a path in the network enters the CentralInterlocking Unit, all blocks on this path are sent the corresponding stimulus in thereservation protocol. If the stimulus has a synchronous response, a transactionalpattern is employed to guarantee that all blocks are in a consistent state.Therefore, the composition operator works as follows: If the central interlockingunit outputs request(f, t), the path from f to t is computed. Next, each pathelement is sent requestin turn. If the request succeeds, the next element in thepath is considered (the end of the path is handled in an appropriate way), and ifthis element is successfully reserved, OK is returned. If the next element fails (be itbecause the element itself failed or some problem happened later in the path), or ifthe request does not succeed, NOK is returned. The handling of tearDown(f, t) isand setupis analogous. On the other hand, the cancelstimulus is simply sent to allrelevant blocks.As a pi-calculus process, this operator can be expressed as follows:// Entrance to the high-level compositionHighLevel(ciu, listBlocks, adjacencies) :=// Initial state: normal operation stateHighLevelNormal(ciu, adjacencies)// Run each block component instance,// all of them in parallel.| Parallel(listBlocks);// The behaviour of the central interlocking unit// when not processing a request.HighLevelNormal(ciu, adjacencies) :=// A request is receivedciu(REQUEST(f, t))? new path, result.// Start three processes:// A path calculation...( CalculatePath(adjacencies, f, t, path)// ... the transaction process that tries// to reserve all the blocks on the path (except// the first, which is a special case) ...| path(first)? Transaction(RESERVE(), path, result)// ... and the process that acts on the result,// providing an answer and entering the appropriate mode.| result(OK())? ciu(OK())!HighLevelRequested(ciu, adjacencies, f, t))172Kloos and Eschbach+result(NOK())? ciu(NOK())! HighLevelNormal(ciu, adjacencies))// A teardown is received; basically, the same handling as for// a request.+ciu(TEARDOWN(f, t))? new path, result.( CalculatePath(adjacencies, f, t, path)| path(first)? Transaction(TEARDOWN(), path, result)| result(what)? ciu(what)! HighLevelNormal(ciu, adjacencies));// The behaviour of the central interlocking unit// when processing a request.HighLevelRequested(ciu, adjacencies, f, t) :=new path, result. (CalculatePath(adjacencies, f, t, path)| ciu(SETUP())? (Tranasction(SETUP(), path, result)|result(what)? ciu(what)!HighLevelNormal(ciu, adjacencies))+ciu(CANCEL())? (Distribute(CANCEL(), path)|HighLevelNormal(ciu, adjacencies));The HighLevel operator uses three helper processes, namely CalculatePath, Trans-action (which implements the transactional pattern) and Distribute (which dis-tributes a stimulus along a path). These processes can be implemented as follows:Transaction(reqType, path, result) :=// end of path: no obstacle to the reservationpath(END())? result(OK())!// still on path: try the request on the current// path element\dots+ path(STEP(s))? s(reqType)! (// if it fails, stop transaction(s(NOK())? result(NOK())!)// if it suceeds, try next element\dots+ s(OK())? new resNext. (Transaction(reqType, path, resNext)// hand down result, and call rollback if necessary| resNext(OK())? result(OK())!+resNext(NOK())? s(ROLLBACK())! result(NOK())!)// Simple recursive implementation of a// "for all elements" operationDistribute(reqType, path) :=path(END())?+ path(STEP(s))? s(reqType)! Distribute(reqType, path);CalculatePath(adjacencies, from, to, path) :=[Code omitted for brevity: A functionthat calculates an arbitrary path throughthe graph given in adjacencies starting atfrom and ending at to. The path is output by sending173Kloos and Eschbacha sequence of STEP(s) terms, one for each vertex on thepath, and finally a END() term.]The implementation of the low-level composition operator can be given in a simi-lar way. It re-uses the definitions of Transaction, Distribute and CalculatePath.Again, we omit the implementation itself for brevity.3.5 Definition of a DSLThe final step of this method is to define a DSL describing instances of the sys-tem and mapping it to applications of the composition operators to appropriatecomponent instances.To describe an instance of a complicated system, domain experts have usuallydeveloped their very own notation, e.g., block diagrams of the system or railroadnetwork diagrams. The language is derived from such a notation, and should bedesigned in a way familiar to domain experts. Additionally, the translation fromsyntactic elements of the language to instances of the components and compositionoperators should be easy to implement. Optimally, each syntactic element maps toa fixed set of component instances and composition operator applications.For the running example, a DSL based on the track layout was chosen (cf. figureFigure 3). It contains, among other information, data on which blocks, switchand signal components exist, and how blocs and switches are interconnected. Forconvenience, an already-existing XML encoding of the track layout was leveraged,which contained large amounts of extraneous information.The elements that were relevant for the model construction were the following:• The definition of a single component. This was used to instance the appropriatecomponent models.• The introduction of a neighbourhood relationship between two blocks. This datawas filled into the block connectivity graph, used by the high-level compositionoperator.• The introduction of the follower sets of a switch, where a follower set describeswhich blocks can be reached when a switch is set in a given position. This infor-mation was preprocessed and then used to fill the low-level connective graph forthe low-level composition operator.• The definition of a single block additionally implies the application of the low-level composition operator to this block and all track devices (i.e., switches andsignals) belonging to this block.Finally, the (implied) CIU instance is created once and the high-level compositionoperator applied to the results of the low-level compositions.For the track layout given in 3, we get the following component instances andcomposition operator applications (see also 5:(i) Five instances of the switch model, one each for S1 to S5.(ii) Seven instances of the block model.(iii) Eight instances of the signal model, two each for the blocks B2, B3, B5 and B6.174Kloos and EschbachFig. 5. The result of the composition. Each model (rectangle) is named by some letters symbolizing itstype (B means block component, S switch, Sig signal and C concrete block) and, optionally, a number.Composition operators are signified by circles, where HL means high-level composition, and LL low-levelcomposition.(iv) One instance of the CIU.(v) Seven applications of the low-level composition operator, namely on for B1 andS1, one for B4 with S2 and S3, one for B7, S4 and S5 and one each for B2,B3, B5 and B6 together with their respective signals. Each of these operatorsyields a concrete block, called C1 to C7.(vi) One application of the high-level composition operator, composing the CIUwith C1 to C7 and yielding the complete system model.4 Experiences from the exampleAs this paper was based on prior work by the authors [12], some limited experienceabout efficiency is available. In particular, the approach described in [12] works alongthe same lines as COMPOSE, with all steps but step 4 of the technique virtuallyidentical. Not surprisingly, we find that the implementation of the compositionoperators as an executable Java program required significantly more effort (a fewman-weeks) compared to their specification as pi-calculus processes (two or threedays).All in all, we find that the COMPOSE approach seems to perform well: It permitsthe production of test models for network-structured systems with acceptable effort.This leads us to formulate several hypotheses:(i) COMPOSE satisfies the requirements described in the introduction: It allowsthe construction of test models for network-structured systems in a way that iscomprehensible for domain experts.(ii) COMPOSE does not require significantly more effort to construct the artifactsfor one composite model than other techniques.(iii) COMPOSE requires significantly less effort to construct several different com-posite models, compared to other techniques.(iv) The models generated using this technique generate the same test cases and/ortest verdicts compared to models built by other techniques.175Kloos and EschbachThese hypotheses will form the basis of a serious evaluation of the COMPOSEapproach. We plan to derive the necessary results by using a controlled experimentand/or an industrial case study. For the comparison to other, existing techniques,Stochastic Automata Networks [4] and Prowell's TGL [15] seem to be the mostappropriate candidates.5 Conclusion and OutlookIn this paper, we have demonstrated an approach called COMPOSE that allowsfor the systematic compositional construction of behavioral models. This approachcomprises an integrated technique to describe state-based component behaviour andcompose these components according to a specification given in a domain-specificlanguage. In our approach, component behaviour is described using Mealy machines,while composition operators can be specified using process calculus expressions. Thisallows a tester or system expert to build models suitable for analysis and model-based testing. On the other hand, the instantiation of a model is described usinga domain-specific language, allowing a domain expert to construct instances of thesystem and environment models for testing without any deeper knowledge aboutthese models. The advantage of this approach is that the domain expert can easilytest the system in as many configurations as he deems relevant and important,without having to worry about constructing test cases or computing test resultsmanually.Our approach is an extension of older work, described in a previous paper [12],where a special case of this approach was demonstrated. The improvement in thispaper is that we can now specify the behaviour of the composition operators moreeasily, so that the approach can be applied with less effort.Starting from here, we plan to do three things. The first task, which is alreadyclose to completion, is the implementation of a tool to support this approach. Next,we plan to apply this approach on different examples, e.g., an example from indus-trial control. Finally, we will investigate how the concepts behind this approach canbe used for quantitative reliability estimation of complex systems.6 AcknowledgementsThe preparation of this work was funded by the Fraunhofer Innovation Cluster Dig-ital Commercial Vehicle Technology. The Fraunhofer Innovation Cluster DigitalCommercial Vehicle Technology is funded by the European Union and the state ofRhineland-Palatinate in the context of the Ziel 2-Programm Rheinland-Pfalz. Theexample used in this paper was created by Siemens Mobility for the ranTest re-search project. The picture of the German railway network is based on a publicdomain picture taken from Wikipedia, cf. http://en.wikipedia.org/wiki/File:Bahn-Streckenkarte_Deutschland.png.176Kloos and EschbachReferences[1] Bauer, T., R. Eschbach, T. Hussain, J. Kloos and F. Zimmermann, Komposition vonbenutzungsmodellen: Operatoren und anwendungsbeispiel, Technical report, Fraunhofer IESE (2009).[2] Behrmann, G., A. David and K. G. Larsen, A Tutorial on Uppaal, in: M. Bernardo and F. Corradini,editors, Formal Methods for the Design of Real-Time Systems: 4th International School on FormalMethods for the Design of Computer, Communication, and Software Systems, SFM-RT 2004, number3185 in LNCS (2004), pp. 200236.[3] EN 50126, Railway Applications The Specification and Demonstration of Reliability, Availability,Maintainability, and Safety (RAMS). (1999), CENELEC, european Standard.[4] Farina, A. G., P. Fernandes and F. M. Oliveira, Representing software usage models with stochasticautomata networks, in: SEKE '02: Proceedings of the 14th international conference on Softwareengineering and knowledge engineering (2002), pp. 401407.[5] Garavel, H. and M. Sighireanu, A graphical parallel composition operator for process algebras,in: Joint International Conference on Formal Description Techniques for Distributed Systems andCommunication Protocols, and Protocol Specification, Testing, and Verification (FORTE/PSTV 99)(1998), pp. 185202.[6] Harel, D., Statecharts: A visual formalism for complex systems, Science of Computer Programming 8(1987), pp. 231274.[7] Haxthausen, A. E. and J. Peleska,Automatic verification, validation and test for railway control systemsbased on domain-specific descriptions, in: S. Tsugawa and M. Aoki, editors, Proceedings of the 10thIFAC Symposium on Control in Transportation Systems (2003), p. (pages unknown).[8] Hopcroft, J. E., R. Motwani and J. D. Ullman, Introduction to Automata Theory, Languages, andComputation, Addison-Wesley Longman Publishing Co., Inc., 1990, 1 edition.[9] IEC 61511, Functional safety: Safety Instrumented Systems for the process industry sector, (2003),IEC.[10] IEC 61508, Functional safety of electrical/electronic/programmable electronic safety related systems,(2005), IEC, (draft).URL http://www.iec.ch/functionalsafety[11] ISO/CD 26262, Road vehicles Functional safety, ISO.[12] Kloos, J. and R. Eschbach, Generating system models for a highly configurable train control systemusing a domain-specific language: A case study, in: 5th Workshop on Advances in Model Based Testing(A-MOST'2009), 2009, p. n/a.[13] Milne, G., The formal description and verification of hardware timing, IEEE Transactions onComputers 40 (1991), pp. 811826.[14] Milner, R., Communicating and Mobile Systems: The pi-Calculus, Cambridge University Press, 1999.[15] Prowell and S.J., Using Markov Chain Usage Models to Test Complex Systems, System Sciences, 2005.HICSS '05. Proceedings of the 38th Annual Hawaii International Conference on (2005), pp. 318c318c.[16] Prowell, S. J. and J. H. Poore, Foundations of Sequence-based Software Specification, IEEE Trans.Softw. Eng. 29 (2003), pp. 417429.[17] DO178B, Software Considerations in Airborne Systems and Equipment Certification, RTCA.[18] Schneider, K., Verification of Reactive Systems - Formal Methods and Algorithms, Texts in TheoreticalComputer Science (EATCS Series), Springer, 2003.[19] Spitznagel, B. and D. Garlan, A compositional formalization of connector wrappers, in: ICSE '03:Proceedings of the 25th International Conference on Software Engineering (2003), pp. 374384.[20] Whittaker, J. A. and J. H. Poore, Statistical Testing for Cleanroom Software Engineering, in: Proc.Twenty-Fifth Hawaii International Conference on System Sciences, 1992, pp. 428436.[21] Yevtushenko, N., T. Villa, R. Brayton and A. Petrenko, Solution of Parallel Language Equations forLogic Synthesis, in: Proceedings of the International Conference on Computer Aided Design, 2001, pp.103110.[22] Zechner, A., Entwurf einer generischen Systemarchitektur für den Zugleitbetrieb, Diplomarbeit, TUBraunschweig (2006).177178FACS 2009A lightweight approach tocustomizable composition operatorsfor Java-like classesGiovanni Lagorio1, Marco Servetto2 and Elena Zucca3Dipartimento di Informatica e Scienze dell’InformazioneUniversita` di GenovaGenova, ItalyAbstractWe propose a formal framework for extending a class-based language, equipped with a given class composition mechanism,to allow programmers to define their own derived composition operators. These definitions can exploit the full expressivepower of the underlying computational language.The extension is obtained by adding meta-expressions, that is, (expressions denoting) class expressions, to conventionalexpressions. Such meta-expressions can appear as class definitions in the class table.Extended class tables are reduced to conventional ones by a process that we call compile-time execution, which evaluatesthese meta-expressions.This mechanism poses the non-trivial problem of guaranteeing soundness, that is, ensuring that the conventional class table,obtained by compile-time execution, is well-typed in the conventional sense.This problem can be tackled in many ways. In this paper, we illustrate a lightweight solution which enriches compile-time execution by partial typechecking steps. Conventional typechecking of class expressions only takes place when theyappear as class definitions in the class table. With this approach, it suffices to introduce a unique common type code formeta-expressions, at the price of a later error detection.Keywords: Modular composition, Java-like languages, Meta-programming, Type systemsIntroductionSupport for code reuse is a key feature which should be offered by programming languages,in order to automate and standardize a process that programmers should, otherwise, do byhand: duplicating code for adapting it to best solve a particular instance of some genericproblem. Two different strategies which can be adopted to achieve code reuse are compo-sition languages and meta-programming.In the former approach programmers can write fragments of code (classes in the caseof Java-like languages) which are not self-contained, but depend on other fragments. Suchdependencies can be later resolved by combining fragments via composition operators, to1 Email: lagorio@disi.unige.it2 Email: servetto@disi.unige.it3 Email: zucca@disi.unige.itThis paper is electronically published inElectronic Notes in Theoretical Computer ScienceURL: www.elsevier.nl/locate/entcs179Lagorio, Servetto and Zuccaobtain different behaviours. These operators form a composition language. Inheritance(single and multiple), mixins and traits are all approaches allowing one to combine classes,hence they define a composition language in the sense above.The limitation of this approach is that the users, provided with a fixed set of compositionmechanisms, cannot define their own operators, as it happens, e.g., with function/methoddefinitions.In meta-programming, programmers write (meta-)code that can be used to generatecode for solving particular instances of a generic problem. In the context of Java-likelanguages, template meta-programming is the most widely used meta-programming facil-ity 4 , as, e.g., in C++, where templates, which are parametric functions or classes 5 , can bedefined and later instantiated to obtain highly-optimized specialized versions. The instanti-ation mechanism requires the compiler to generate a temporary (specialized) source code,which is compiled along with the rest of the program. Moreover, template specialization al-lows to encode recursive computations, that can be thought of as compile-time executions.This technique is very powerful, yet can be very difficult to understand, since its syntax andidioms are esoteric compared to conventional programming. For the same reasons, main-taining and evolving code which exploits template meta-programming is rather complex,see, e.g., [3]. Moreover, well-formedness of generated source code can only be checked “aposteriori”, making the whole process hard to debug.Here, our aim is to distill the best of these two approaches, that is, to couple disci-plined meta-programming features with a composition language, in the context of Java-likeclasses. More precisely, we propose a formal framework for extending a class-based lan-guage, equipped with a given class composition mechanism 6 to allow programmers todefine their own derived composition operators. These definitions can exploit the full ex-pressive power of the underlying computational language.The extension is obtained as follows: meta-expressions, that is, (expressions denoting)class expressions, are added to conventional expressions. Then, such meta-expressions canappear as class definitions in the class table. Extended class tables are reduced to con-ventional ones by evaluating these meta-expressions. This meta-circular approach impliescompile-time execution as in template meta-programming, with the advantage of a familiarmeta-language, since it just coincides with the conventional language the programmers areused to.This mechanism, which is trivial in itself, poses the non-trivial problem of guaranteeingsoundness, that is, ensuring that the conventional class tables, obtained by compile-timeexecution, are well-typed (in the conventional sense).Ideally, typing errors in generated source code should be detected statically, that is,without requiring reduction at the meta-level at all, as it happens, e.g., in MetaML [16].However, this would require to introduce sophisticated types for meta-expressions. In thispaper, we illustrate instead a lightweight solution which enriches compile-time executionby typechecking steps. Conventional typechecking of class expressions only takes placewhen they appear as the right-hand side of class definitions in the class table. With thisapproach, it suffices to introduce a unique common type code for meta-expressions, at the4 A very limited form of meta-programming is offered by Java/C# generics, which are classes parametric in some typeparameters, that can be compiled once. Java generics are a source level feature, which is compiled away, while generics arefully supported by C#.5 Note that C++ supports, along type-parameters, other kinds of template parameters.6 In this paper for sake of simplicity we illustrate the approach on only one composition operator, that is, extends.180Lagorio, Servetto and Zuccaprice of a later error detection.The paper is organized as follows: in Section 1 we informally introduce our approachby means of some examples, in Section 2 we provide a formalization on a very simpleclass composition language, and in Section 3 we summarize the contribution of the paperand draw related and further work. The Appendix contains the proof of soundness. Thispaper is the full version of [8].1 ExamplesIn order to show how to use meta-programming as a tool for better composing software, weintroduce a language allowing one to compose classes by means of some operators. In sucha language, a class declaration associates a class expression with the name of the declaredclass. The simplest form of class expression is the base class, that is, a set of field andmethod declarations. For instance, the literal { int answer() { return 42; } } denotes abase class declaring a single method named answer. In our example language, we can givethe name C to that class body by writing:class C = { int answer() { return 42; } }This is the exact Java syntax, with the exception of the extraneous symbol =. Of course,here the symbol = can be followed by any arbitrarily involved class composition expression,in place of a simple base class literal.Since our aim here is to explain how our approach works, rather than proposing aspecific composition language, for simplicity we consider a very simple language offeringjust a single binary operator, extends, allowing one to combine two classes in a way thatshould feel natural to Java programmers: the left operand extends, that is, overrides, theright operand.For instance, writing{ int a() { return 1; } } extends{ int a() { return 0; } int b() { return 0; } }is equivalent to write:{ int a() { return 1; } int b() { return 0; } }To add a meta-programming facility to this simple language, we allow class (composi-tion) expressions to be used as expressions of a newly introduced type: code.For instance, the following programclass C = {code m() {return { int one() { return 1; } };}}class D = new C().m()declares two classes, C and D. The former, C, declares a single method named m, whichreturns a value of type code. This value, in turn, is a base class declaring the (non-meta)method 7 one. The latter class, D, is declared using an expression that has to be evaluatedin order to obtain the corresponding class body. In this example, the body of D is the valuereturned by the method m of C, so this program could be equivalently written as:7 We call meta-methods the methods involving code manipulation.181Lagorio, Servetto and Zuccaclass C = /* ...as before... */class D = { int one() { return 1; } }One very basic use of this mechanism allows to obtain conditional compilation. Forinstance, in the previous example we could have written:class C = {code m() {if (DEBUG) return /* ...debug version... */;return /* ...as before... */;}}The following (meta-)method:code mixin(code parent) {return { /* ... */ } extends parent;}behaves like a mixin, extending in some way a parent class passed as argument.Note that the code in the extension can select arbitrary fields or methods of the parentclass. This is allowed because we do not typecheck a class expression until it is associatedto a class name in the class table. This choice allows for an incredible leeway in writingreusable code, at the price of a late error detection. The situation is very similar to whathappens with C++ templates [15,13].The class to be used as parent could be constructed, having a generic list type, List<>,by chaining an arbitrary number of classes:code chain(List

 parents){if (parents.isEmpty()) return Object;return parents.head() extends this.chain(parents.tail());}This is indeed similar to mixin composition, with the advantage that the operands of thisarbitrarily long composition do not have to be statically known.Finally, the following example is a graphic library that adapts itself with respect to itsexecution environment, without requiring any extra-linguistic mechanisms: 8class GraphicalLibrary {code produceLibrary() {code result = BaseGraphicalLibrary;String producer = System.getProperty("sys.vcard.brand");if (producer.equals("NVIDIA"))result = NVIDIASupport extends result;else if (producer.equals("ATI"))result = ATISupport extends result;elsethrows new CompilationError("No compatible hardware found");if (System.getProperty("os.name").contains("Windows"))result = CygwinAdapter extends result;return result;}}The method produceLibrary builds a platform-specific library by combining the generic li-brary BaseGraphicalLibrary with the brand-specific drivers (represented by the two classesNVIDIASupport and ATISupport) and wrapping the result, if required on the specific plat-form, with the class CygwinAdapter, which emulates a Linux-like environment on Windowsoperating systems.8 To keep the example compact, we do not detail all the classes named in the example, and we simply assume that they aredeclared elsewhere.182Lagorio, Servetto and Zuccacp :: = class C = ce (conventional) programce :: = C | B | ce extends ce ′ class expressionB :: = {fds mds} base classfds :: = fd field declarationsfd :: = T f ; field declarationmds :: = md method declarationsmd :: = T m(T x ) {return e; } method declaratione :: = x | e.f | e.m(e) | new C(e) | (C )e (runtime) expressionv :: = new C(v) valueT :: = C typeCT :: = 〈C , fds,mhs〉 class typemhs :: = mh method headersmh :: = T m(T ) method header∆ :: = C :CT class type environmentΓ :: = x :T parameter type environmentFigure 1. Syntax and types of the conventional languageIn this way the compilation of the same source produces customized versions of thelibrary depending on the execution platform. In other words, this approach can be usedto write active libraries [2], that is, libraries that interact dynamically with the compiler,providing better services, as meaningful error messages, library-specific optimizations andso on.2 FormalizationFigure 1 shows syntax, values and types of our conventional language, using the overbarnotation to denote a (possibly empty) sequence. 9The top section of the figure defines the syntax, where we assume infinite sets of classnames C , field names f and method names m . As already mentioned, to keep the presen-tation minimal we consider a class composition language with only one operator, extends.This conventional language is very similar to Featherweight Java [6], FJ for short, but theoperator extends composes two class expressions, rather than the name of an existing classwith a class body (base class).Reduction rules are as in FJ and are omitted. The only difference is that look-up, for-mally expressed by the function mbody , needs to be generalized, as shown in Figure 2,to take into account that extends composes two class expressions. We omit the analogoustrivial generalization of the function fields . Values v of the conventional language are as inFJ.9 This notation for metavariables is the analogous of the Kleene-star in BNF style.183Lagorio, Servetto and Zucca(<-DIRECT)∆ ` C, <, ≥, ≤ thatare not available on a string type, etc. Properties are introduced in our deploymentframework in the generic way by introducing them in our metamodel [3]. A deployedentity may be a complete system (defined as a set of components), a component ora service. In our dependency language we add in the provided side a list of propertygenerally denoted by E with their values [p1 = v1, . . . , pn = vn]. For example, aservice s with a property named version of value 1 is denoted by s[version = 1].It is clear that when specifying a service (or a component) a property cannot bebound twice to different values. A property constraint specifies the constraint thatthe matching components or services must ensure. In the context of this paper,constraints on number property type may use any usual comparison operator (>,≥, <, ≤, =, 6=) and constraints on string property type may use only equality orinequality.Finally, a system is composed of components. A component provides (a com-position of) services. Each provided services have a requirement which representsa conditional expression involving other entities. The dependency language gram-mar presented below defines more precisely which kind of composition is possible onprovided right side and on required left side (dependency = required → provided:if requirements are satisfied then services are provided).1973.1 Basic satisfiabilityOur reasoning framework compares the requirement of component dependencies withavailable services and components in the system. For instance, a required services constrained by [version ≥ 3] can be satisfied by an available service s which hasthe property [version = 4]. For this, we define the notion of basic satisfiability of aproperty E in a constraint ϕ and denotes it ϕ ← E (see definition 3.1). Intuitively,this relation is verified if all the names of the constraints ϕ exist in the set of thenames of properties E . To define it more formally, we need to define the notion ofdomain for properties and constraints. The domain is the set of property namesthat appear in either a property or a constraint:dom([]) = ∅, dom([p1O1v1, . . . , pnOnvn] = {p1} ∪ · · · ∪ {pn}where O denote either a comparison operator (for constraints) or a binding op-erator (for properties).Definition 3.1 (Basic satisfiability) A property E is satisfied in a constraintϕ = [p1O1v1, . . . , pnOnvn] if and only if(i) all the names of constraints are included in the set of the property names E :dom(ϕ) ⊆ dom(E)(ii) the constraint ϕ is true when substituting all properties by their values in E :(E(p1)O1v1) ∧ · · · ∧ (E(pn)Onvn)The satisfiability (ϕ← E) of a property of an entity x in the constraint of anotherentity x′ is calculated as follows:(x′, ϕ)← (x, E) = (x′ = x) ∧ (ϕ← E), where x and x′ are components or services.3.2 Dependency specificationDependency specification is represented as the composition of provided services thatrequire a composition of required services and components. Dependencies are com-posed using three operators #, • and ?. Intuitively, these operators correspondrespectively to disjunction (one of the sub-requirements must be met), conjunc-tion (the two sub-requirement must be met) and optional dependency (if the sub-requirement is met, some services may be provided). Dependencies are describedin more details in [2], the formal description follows a grammar based on predicatelogic. In this paper, we extend this grammar by adding properties at the level ofthe provided services and the constraints on the properties at the level of requiredand forbidden components and services (see definition 3.2).Definition 3.2 (Dependencies) The dependencies or intra-dependencies repre-sent the relations between each provided service (which may have extra-functionalproperties) of a component and its requirements (which may have constraints onextra-functional properties). Dependencies are described using the predicate logic198and are specified by the following grammar:D ::= P ⇒ s E | D •D | D #D | ?D P ::= true | P ∧ P | QQ ::= Q ∨Q | ϕ | ¬c ϕ | ¬s ϕ | c ϕ .s ϕ | s ϕ E ::= | [v = value E ′]E ′ ::= | , v = value E ′ ϕ ::= | [v O value ϕ′] ϕ′ ::=|, v O value ϕ′O ::=> | ≥ | < | ≤ | = | 6=The basic dependency P ⇒ s E correspond to a provided service s with proper-ties E which has a requirement P . This requirement is expressed by a term calleda predicate (in conjunctive normal form). Predicates are composed by usual logicaloperators (conjunction and disjunction). It represents: (1) constraints on the systemϕ, (2) a forbidden component with its property constraints ¬c ϕ, (3) a forbiddenservice with its property constraints ¬s ϕ, (4) a service provided by a specific com-ponent with their property constraints c ϕ .s ϕ and (5) a service provided by anycomponent with its property constraints s ϕ. As it is explained earlier, propertiesE represent the set of the corresponding values of properties (variable v, value),constraints ϕ represent the set of the triplet (variable v, operator O, value). In thispaper, we consider variables as strings and values as string, number and booleantypes.For example, we assume that the dependency description of the mail serverpostfix is as follows:([FreeDisk ≥ 1380] ∧ ¬csendmail ∧ slib[version > 1.2]⇒ sMTA[SecLevel = 2])• ?(samavis ⇒ sAV [SecLevel = 2])It means that the component postfix needs 1380kb of free disk space and a serviceslib in a version greater than 1.2 and it conflicts with the component sendmail. Whenthese conditions are satisfied, it can be installed and it will provide the service sMTA(for Mail Transfer Agent) with a security level equal to 2. It may also provide anAnti virus service sAV having security level value equal to 2 if the service samavis isavailable.3.3 Context descriptionThe description of a system is called a context. A context is composed of (1) itsenvironment denoted by E or ctx.E (contains the value of the system properties), (2)the set of its components denoted C, (3) the dependency graph between these com-ponents denoted ctx.G. The structure of (2) and (3) are complex and are describedin more detail below.As a system may contain several instances of the same component, we need toidentify all these instances. For a component c, the instances are named (c, num)where num is the instance number which is already installed in the system (seedefinition 3.3).199Definition 3.3 (CalcNum) The function CalcNum calculates the new compo-nent instance as follows:CalcNum(c, Ctx) = max({0} ∪ {n|(c, n, . . .) ∈ Ctx.C}) + 1The set of installed components contain component information. It is representedby C a set of six-tuples (c, num, Ec,Ps,Fs,Fc) storing for each installed instance of acomponent c its number num, its properties Ec, its provided services Ps, its forbid-den services Fs and its forbidden components Fc. Each provided service is storedtogether with its environment (s, Es). Forbidden services and forbidden componentsare stored with their associated constraints Fs (resp. Fc), they are denoted by(s, ϕs) (resp. (c, ϕc)).Finally, a dependency graph stores all dependencies between components of asystem. It can be viewed as a model of the interconnection between component ofthe system.Indeed, as components can provide several times the same service with differentproperties, it is necessary to identify the services to distinguish them. In our model,the service identifier, denoted by ids.A node of the graph G represents the identifier of an available service (ids =(idc, s, Es)), where idc = (c, num) represents the component identifier (the providerof the service s) and Es represents its properties. An arc is a couple of nodesids1x,ϕc,ϕs7−−−−−→ ids2, where x is the kind of dependency: M for mandatory or O foroptional, ids2 requires ids1 with the constraints ϕc and ϕs, ϕc are constraints on thecomponent which provides the service ids1 and ϕs are constraints on the requiredservice ids1.Constraints must be stored in the graph to be able to ensure the safety of deploy-ment operations that need to change the graph. For example, if a service s1 has thesecurity level (ls = 3) and it is used by another service s2 with a constraint on thesecurity level (ls > 2), let suppose that s1 must be substituted by another services3[ls = 2], s3 cannot replace s1 because the constraint of the service s2 (ls > 2) isnot satisfied by the property of s3. As the structure of the context is rather complex,we define utility functions that calculate the set of available services (resp. compo-nents) AS (resp. AC ) and forbidden services (resp. components) FS (resp. FC )for a given context. AS(ctx) =⋃{Ps | (. . . ,Ps, . . .) ∈ ctx.C}AC (ctx) = {(c, num) | (c, num, . . .) ∈ ctx.C}FS(ctx) =⋃{Fs | (. . . ,Fs, . . .) ∈ ctx.C}FC (ctx) =⋃{Fc | (. . . ,Fc) ∈ ctx.C}Ps is the set of service couples with their properties (s, Es) and Ctx.C representsthe elements (c, num, Ec,Ps,Fs,Fc) describing each component c with its identifiernum, all its properties Ec, all its services Ps, all its forbidden services Fs and all itsforbidden components Fc.Adding properties in components and services and adding constraints on theseproperties in requirements makes difficult the calculation of available and forbiddencomponents and services. The Forbidden function determines whether a providedcomponent or a service are forbidden in the context (see the definition 3.4). Thefunction Available determines whether a required component or a service requiredare available in the context (see definition 3.5).200Definition 3.4 (Forbidden) The Forbidden function checks whether the providedcomponent (c, Ec) respectively a provided service (s, Es) are not forbidden in thecontext by verifying their Satisfiability (see definition 3.1) in the sets FC respectivelyFS with the properties of the corresponding component respectively a service. It isdefined as follows:Forbidden(ctx, c, Ec) = ∃(c′, ϕc) ∈ FC(ctx) | (c′, ϕc)← (c, Ec)Forbidden(ctx, s, Es) = ∃(s′, ϕc) ∈ FS(ctx) | (s′, ϕs)← (s, Es)Definition 3.5 (Available) The functionAvailable checks whether a required com-ponent, a required service or a required service provided by a specific component areavailable in the context. It verifies the satisfiability of available component in theconstraint of the required component. It verifies the satisfiability of available servicein the constraint of the required service and it verifies the satisfiability of availableservice from a specific component in the constraint of the required service from aspecific component. It is defined as follows:Available(ctx, c, ϕc) = ∃(c′, Ec) ∈ AC(ctx) | (c, ϕc)← (c′, Ec)Available(ctx, s, ϕs) = ∃(s′, Es) ∈ AS(ctx) | (s, ϕs)← (s′, Es)Available(ctx, c.s, ϕc, ϕs) =∃(c′,−, Ec,Ps, . . .) ∈ ctx.C | (c, ϕc)← (c′, Ec) ∧ ∃(s′, Es) ∈ Ps | (s, ϕs)← (s′, Es)Finally, when a service is available in a context, we have to know the set ofits identifier. The function CalcIdS is used for this purpose. As it is explainedin context description, the identifiers represent the graph nodes and we use themto distinguish between the different instances of the same service (provided by thesame or different components).Definition 3.6 (CalcIdS) The function CalcIdS calculates the identifiers of therequired services (provided by any component or a precise one) which are available inthe context. It is based on the satisfiability check, i.e., the verification of the requiredservice constraints with properties of available corresponding service properties. Itis defined as follows:CalcIds(ctx, c.s, ϕc, ϕs) ={(c, n, s, Es) | (c, n, Ec,Ps,−,−) ∈ ctx.C ∧ (s, Es) ∈ Ps ∧ (ϕc ← Ec) ∧ (ϕs ← Es)}CalcIds(ctx, s, ϕs) ={(c, n, s, Es) | (c, n, Ec,Ps,−,−) ∈ ctx.C ∧ (s, Es) ∈ Ps ∧ (ϕs ← Es)}4 Deployment descriptionOnce the basic notions of property, dependency and context are defined we canpresent the rules that ensure that deployment operations are safe. In this section,the discussion is centered on the installation and deinstallation operations.4.1 InstallationThe installation process is divided in two phases: a first step ensure componentinstallability (its requirements are satisfied and its provides services do not conflict201Predicates:PTrue: ctx `P truePAnd:C `P P1 ctx `P P2ctx `P P1 ∧ P2POrL:ctx `P Q1ctx `P Q1 ∨Q2POrR:ctx `P Q2ctx `P Q1 ∨Q2PVar:ϕ← ctx.Ectx `P ϕPNotS:¬Available(ctx, s, ϕs)ctx `P ¬ s ϕsPNotC:¬Available(ctx, c, ϕc)ctx `P ¬ c ϕcPServ:Available(ctx, s, ϕs)ctx `P s ϕsPComp:Available(ctx, c.s, ϕc, ϕs)ctx `P c ϕc.s ϕsDependencies:CTriv:ctx `P P ¬Forbidden(ctx, s, Es)ctx `C P ⇒ s EsCAnd:ctx `C D1 ctx `C D2ctx `C D1 •D2COpt: ctx `C ?DCOrL:ctx `C D1ctx `C D1 #D2COrR:ctx `C D2ctx `C D1 #D2Fig. 1. Installability ruleswith the context) and a second step calculate the effect resulting from the installa-tion.4.1.1 InstallabilityInstallability involves (1) ensuring that any required service is available in the context(see definition 3.5), (2) ensuring that none of the components that will be installedis forbidden and also that none of its provided services is forbidden (see definition3.4). It is defined as follows:Definition 4.1 (Installability) A component c with a dependency D and a set ofproperties Ec is installable within a context ctx (ctx `C c : D, Ec) iff the componentwith its corresponding properties is not forbidden and its dependency D is verifiedby the checking rules of Fig. 1. The general installability rule is defined below:CComp:ctx `C D ¬Forbidden(ctx, c, Ec)ctx ` c : D, EcThe installability rules presented in Fig. 1 are similar to those proposed in [2].The difference is in the verification of the availability of required components andservices using satisfiability relation.Simple dependencies P ⇒ s Es are verified if the predicate P is true and s Es isnot forbidden (CTriv). The evaluation of a predicate P in the context ctx followspropositional logic and is presented in the first part of the figure (rules denoted by202GTrue: ctx, id `G true⇒ ∅GAnd:ctx, id `G P1 ⇒ G1 ctx, id `G P2 ⇒ G2ctx, id `G P1 ∧ P2 ⇒ G1 ∪ G2GOr:ctx, id `G Q1 ⇒ G1 ctx, id `G Q2 ⇒ G2ctx, id `G Q1 ∨Q2 ⇒ G1 ∪ G2 GVar: ctx, id `G ϕ⇒ ∅GNotS: ctx, id `G ¬ s′ϕ⇒ ∅ GNotC: ctx, id `G ¬ c′ϕ⇒ ∅GServC:Available(ctx, c′.s′, ϕc, ϕs)ctx, id `G c′ϕc.s′ϕs ⇒ {id′ M,ϕc,ϕs7−−−−−→ id | id′ ∈ CalcIds(ctx, c′.s′, ϕc, ϕs)}GServ:Available(ctx, s′, ϕs)ctx, id `G s′ϕs ⇒ {id′ M,[],ϕs7−−−−→ id | id′ ∈ CalcIds(ctx, s′, ϕs)}Fig. 2. Graph calculation rules`P ). During installability, optional dependencies are ignored (COpt) because suchdependencies may be unavailable without preventing component installation. Theconjunction of dependencies is verified when the two dependencies are valid (CAnd),the disjunction (D1 #D2) means if D1 then COrL else if D2 then COrR.4.1.2 InstallationOnce the component installability is checked using installability rules, the effect ofits installation in the target system must be calculated. This effect gathers the newavailable services (with their properties), the new forbidden services and components(with their constraints) and the new dependencies (as a dependency graph). Beforepresenting the installation rules, we describe first some functions which calculate theinstallation effect.Definition 4.2 (Graph calculation) The dependency graph G is built as compo-nents are deployed. For each component we compute the subgraph that correspondsto it to build the global graph. The subgraph of a component c which providesservices having identifiers ids is calculated from each predicat P of its dependency(ctx, ids `G P ⇒ G) by the rules presented in Fig. 2.The difference between these rules and those presented in [2] is the use of serviceidentifier for as nodes and constraints of components and services as labels. Therules GTrue, GAnd, GOr, GVar, GNotS, GNotC are exactly identical and consists inthe gathering process of new arcs. The two last rules are the only rules that addnew arcs. The rule GServC bind all potential providers of each required service tothe current provided service. The set of providers is calculated using the previouslydefined CalcIds of the definition 3.6. Each new binding is labeled by (M, ϕc, ϕs),meaning that the dependency is mandatory and the constraints imposed on therequired component and its service are ϕc and ϕs. The rule GServ is similar, butlinks the service id with any component providing it.203The second function necessary to calculate installation effect is CalcF that gath-ers of all forbidden entities (services or components).Definition 4.3 (CalcF) The function CalcF calculates the forbidden componentsand the forbidden services using the condition of the dependency predicate. Itcomputes them as follows:CalcF (true) = CalcF (s ϕ) = CalcF (c ϕ.s ϕ) = CalcF (ϕ) = ∅,∅CalcF (P1 ∧ P2) = F1s ∪ F2s ,F1c ∪ F2c where CalcF (Pi) = F is,FicCalcF (Q1 ∨Q2) = F1s ∪ F2s ,F1c ∪ F2c where CalcF (Qi) = Fis,F icCalcF (¬ sϕ) ={{(s, ϕ)},∅ if ¬Available(ctx, s, ϕ)∅,∅ elseCalcF (¬ cϕ) ={∅, {(c, ϕ)} if ¬Available(ctx, c, ϕ)∅,∅ elseDefinition 4.4 (Installation) The installation of a component c with a depen-dency D in a context ctx adds: the new component instance (its number num) withits provided services Ps, forbidden services Fs and forbidden components Fc andthe subgraph (G) (see rules in Fig. 3) into the context.IComp:ctx, c, num `I D ⇒ Ps,Fs,Fc,G num = CalcNum(c, ctx)ctx `I c : D, Ec ⇒ (c, num, Ec,Ps,Fs,Fc),GThe main rule that calculates the effect of the installation is the rule ITriv.The provided services represent the couples of services and their properties (s, Es).The sets of forbidden services and forbidden components are calculated with thefunction CalcF . The dependency graph is calculated using the rules of Fig. 2 whichare denoted by (`G) in the rule ITriv. The function Forbidden checks whether theprovided services with all their properties are not in conflict with the constraints ofthe context.4.1.3 An installation exampleWe assume that the component POSTFIX (denoted by CPX) provides the serviceSMTA with the property version equals to (v = 3) if a set of requirements arefulfilled. These requirements are: Free Disk Space (FDS ≥ 1380), the componentSENDMAIL (CSM ) having a version greater or equal to 2 (v ≥ 2) is forbidden, thelibrary Slib with a version greater or equal to 3 is required (v ≥ 3). The descriptionof POSTFIX dependency is as follows: D1 •D2 :{D1 = [FDS ≥ 1380] ∧ CSM [v ≥ 2] ∧ Slib [v ≥ 3]⇒ SMTA [v = 3]D2 =?(CA [v ≥ 3, NS ≥ 2].Samavis [NS ≥ 3]⇒ SAV [NS = 4])Let's have the following initial context with environment properties E and a setof components C{E = {FDS = 500000, OS = LINUX,RAM = 128};C = {(C1, 1, [], (Slib [v = 3]),∅,∅), (CA, 1, [v = 4, NS = 3], (Samavis [NS = 3]),∅,∅)};The installability proofThe installability proof is demonstrated using the installability rules of the Fig. 1.It is as follows:204ITriv:ctx, ids `G P ⇒ G ¬Forbidden(s, Es) CalcF (P ) = Fs,Fcctx, id `I (P ⇒ s, Es)⇒ {s, Es},Fs,Fc,GINot1:ctx `P ¬Pctx, id `I (P ⇒ s, Es)⇒ ⊥INot2:Forbidden(s, Es)ctx, id `I (P ⇒ s, Es)⇒ ⊥IOpt1:ctx, id `I D ⇒ ⊥ctx, id `I ?D ⇒ ∅,∅,∅,∅IOpt2:ctx, id `I D ⇒ Ps,Fs,Fc,Gctx, id `I ?D ⇒ Ps,Fs,Fc, {s O,ϕc,ϕs7−−−−−→ s′ | s −,ϕc,ϕs7−−−−−→ s′ ∈ G}IAnd1:ctx, id `I D1 ⇒ ⊥ctx, id `I D1 •D2 ⇒ ⊥IAnd2:ctx, id `I D2 ⇒ ⊥ctx, id `I D1 •D2 ⇒ ⊥IAnd3:ctx, id `I D1 ⇒ P1s ,F1s ,F1c ,G1 ctx, id `I D2 ⇒ P2s ,F2s ,F2c ,G2ctx, id `I D1 •D2 ⇒ P1s ∪ P2s ,F1s ∪ F2s ,F1c ∪ F2c ,G1 ∪ G2IOrL:ctx, id `I D1 ⇒ Ps,Fs,Fc,Gctx, id `I D1 #D2 ⇒ Ps,Fc,Fs,GIOrR:ctx, id `I D1 ⇒ ⊥ ctx, id `I D2 ⇒ Ps,Fs,Fc,Gctx, id `I D1 #D2 ⇒ Ps,Fs,Fc,GFig. 3. Installation rulesCCompCAndACtx `C D1?(CA [v ≥ 3, NS ≥ 2].Samavis [NS ≥ 3]⇒ SAV [NS = 4])Ctx `C D1 • D2 ¬Forbidden(Ctx,CPX , [])Ctx ` CPX : D1 • D2A = CTrivBCtx `P [FDS ≥ 1380] ∧ ¬CSM [v ≥ 2] ∧ Slib [v ≥ 3]¬Forbidden(Ctx, SMTA, [v = 3])Ctx `C [FDS ≥ 1380] ∧ ¬CSM [v ≥ 2] ∧ Slib [v ≥ 3]⇒ SMTA [v = 3]B = PTrivPVar500000 ≥ 1380Ctx `P FDS ≥ 1380PNotC¬Available(Ctx,CSM , [v ≥ 2])Ctx `P ¬CSM [v ≥ 2]PServAvailable(Ctx, Slib, [v ≥ 3])Ctx `P Slib [v ≥ 3]Ctx `P [FDS ≥ 1380] ∧ ¬CSM [v ≥ 2] ∧ Slib [v ≥ 3]The installation proofOnce POSTFIX is installable, we compute the installation effect using installationrules of Fig. 3. The context will be updated with new provided services, new for-bidden components, new forbidden services and the new dependency subgraph. D1respectively D2 are demonstrated by the set of inference rules denoted respectively205by A' and B.ICompIAnd3A'Ctx,CPX , 1 `I D1 ⇒ P1s ,F1s ,F1c ,G1BCtx,CPX , 1 `I D2 ⇒ P2s ,F2s ,F2c ,G2Ctx,CPX , 1 `I D1 •D2 ⇒ P1s ∪ P2s ,F1s ∪ F2s ,F1c ∪ F2c ,G1 ∪ G2 1 = CalcNum(CPX , Ctx)Ctx `C CPX : D1 •D2 ⇒ (CPX , 1,P1s ∪ P2s ,F1s ∪ F2s ,F1c ∪ F2c ),G1 ∪ G2A'=ITrivGAndGServAvailable(Ctx, Slib, [v ≥ 3])Ctx,CPX , 1, SMTA, [v = 3] `G Slib [v ≥ 3]⇒ G1 Ctx,CPX , 1, SMTA, [v = 3] `G CSM [v ≥ 2]⇒ ∅Ctx,CPX , 1, SMTA, [v = 3] `G [FDS ≥ 1380]⇒ ∅Ctx,CPX , 1, SMTA, [v = 3] `G P ⇒ G1Forbidden(Ctx, SMTA, [v = 3]) CalcF (P ) = ∅, {(CSM , [v ≥ 2])}Ctx,CPX , 1 `I (P ⇒ SMTA, [v = 3])⇒ {(SMTA, [v = 3])},∅, {(CSM , [v ≥ 2])},G1B=IOpt2ITrivGServAvailable(Ctx, Samavis, [NS ≥ 3])Ctx,CPX , 1, SAV , [NS = 4] `G Samavis [NS ≥ 3]⇒ G2¬Forbidden(Ctx, SAV , [NS = 4]) CalcF (CA [v ≥ 3, NS ≥ 2].Samavis [NS ≥ 3]) = ∅,∅Ctx,CPX `I (CA [v ≥ 3, NS ≥ 2].Samavis [NS ≥ 3]⇒ SAV .[NS = 4])⇒ {(SAV , [NS = 4])},∅,∅,G2Ctx,CPX `I ?(CA [v ≥ 3, NS ≥ 2].Samavis [NS ≥ 3]⇒ SAV .[NS = 4])⇒ {(SAV , [NS = 4])},∅,∅,G2P1s ,F1s ,F1c = {(SMTA, [v = 3])}, {}, {(CSM , [v ≥ 2])}G1 = {(C1, 1, lib [v = 3]) M,[],[v≥3]7−−−−−−−→ (PX, 1, SMTA [v = 3]}P2s ,F2s ,F2c = {SAV [NS = 4]}, {}, {}G2 = {CA [v = 4, NS = 3], 1, Samavis [NS = 3] O,[v≥3,NS≥2],[NS≥3]7−−−−−−−−−−−−−−−−→ PX, 1, SAV [NS = 4]}After the installation of POSTFIX, the context is updated. The resulting depen-dency graph represents the union of G1 and G2 presented above. The componentPOSTFIX (CPX ,1,[],Ps,Fc,Fs) is added to the set of components:C = {(C1, 1, [], (Slib [v = 3]),∅,∅), (CA, 1, [v = 4, NS = 3], (Samavis [NS = 3]),∅,∅),(CPX , 1, [], {(SMTA [v = 3]), (SAV , [NS = 4])}, (SSM [v ≥ 2]),∅)}Notice that any component SENDMAIL (SSM ) having a version greater or equal to 2(v ≥ 2) is forbidden otherwise (if v < 2) the component SSM is not forbidden.4.2 DeinstallationThe deinstallation follows the same approach as installation. The first phase checksthe feasibility of deinstallation, and the second phase calculates the effect of dein-stallation on the context.4.2.1 DeinstallabilityThe principle of verification is exactly the same as presented in [2]. The difference liesin the dependency syntax and management of components and services identifiers(instances). Indeed, we can remove an instance of a component (c, num) if none ofits instances of provided services ids is used necessarily by other components directlyon indirectly (see definition 4.5).Definition 4.5 (Mandatory dependencies (MD)) The set of mandatory depen-dencies (MD) of a service ids in a dependency graph G is the set of nodes that havea mandatory dependencies and belong to all graph paths from ids to the leaves:MD(G, ids) =⋃{{ids′} ∪MD(G, ids′) | ids (M,−,−)7−−−−−→ ids′ ∈ G}206Definition 4.6 (Optional dependencies (OD)) The set of optional dependencies(OD) of a service ids in a dependency graph G is the set of nodes that have optionaldependencies and belong to all graph paths from ids to the leaves:OD(G, ids) =⋃{{ids′} ∪OD(G, ids′) | ids (O,−,−)7−−−−−→ ids′ ∈ G}Definition 4.7 (Deinstallability) A component (c, num) can be deinstalled fromthe context ctx iff all the instances of its provided services are not used by othercomponents in a mandatory way, i.e. there is no mandatory dependency in all pathsfrom all these provided serviced to the graph leaves. It is checked using the followingrule:Check-DI:(c, num, Ec,Ps,−,−) ∈ ctx.C⋃{MD(G, (c, num, s, Es)) | (s, Es) ∈ Ps} = ∅ctx `D (c, num)4.2.2 DeinstallationThe structure of the context containing all instances separately makes it possibleto deinstall an instance only by removing the corresponding tuple from C. There-fore, the deinstallation effect is a set of nodes that have to be removed from thedependency graph and is calculated in the same way as in [2]. The difference lies inthe management of component and service identifiers. The nodes that have to beremoved are those corresponding to the nodes of provided services of correspondingcomponent and those that are used directly or indirectly in an optional way (seedefinition 4.6) and do not use any other service.Definition 4.8 (Deinstallation) The deinstallation rule calculates the set of nodesthat have to be removed from the graph with their corresponding arcs. The removednodes are those provided by the component (c, num) and those which have only op-tional arcs in each path from them to graph leaves and are not tails of any arc. Thecalculation of removing nodes follows this rule:Effet-DI:(c, num, Ec,Ps,−,−) ∈ ctx.Cctx `E (c, num)⇒⋃(s,Es)∈Ps({(s, Es)} ∪ {ids′ ∈ OD(ctx.G, (c, num, s, Es)) | @n, n −7−−→ ids′ ∈ ctx.G})After deinstallation, the component tuple is removed from ctx.C and the set Nis removed from the dependency graph:G \N = {n1 x7−→ n2 | n1 x7−→ n2 ∈ G ∧ n1 /∈ N ∧ n2 /∈ N} where N is the set of nodescalculated by the rule Effet-DI (ctx `E c⇒ N).4.2.3 A deinstallation exampleAn example of dependencies of a component assembly is illustrated in Fig. 4. Thisassembly is composed of the components INTERNET, SECURITY and UPDATE whichare represented in boxes. The intra-dependencies are inside the boxes, the requiredservices are represented in the left side of each box and the provided one are inthe right side. Dependencies can be necessary or optional (represented by dottedline). To update applications the component UPDATE needs (1) a transfer function(transfer), (2) a service web with the version and language constraints: [v ≥ 3, lg =Fr] which is provided by the component INTERNET and must satisfy the constraints[type = ADSL2+, download ≥ 8Mb/s] and (3) may uses a hash function (sha256)207provided by SECURITY. When all these requirements are fulfilled the componentUPDATE provides the service update with the security level and language properties[sl = 4, lg = Fr]. Its provides also the optional service ihm with a graphical userinterface [gui = graph] which depend on the service pluginihm. Fig. 5 shows thedependency graph of this component assembly including the gray part.INTERNET.[type = ADSL2+, download ≥ 8].web[v ≥ 3, lg = Fr]transfersha256pluginihmupdate[sl = 4, lg = Fr]ihm[gui = graph]UPDATEdnstcp-ipweb[v = 3, lg = fr]INTERNETINTERNET[download ≥ 3].web[v ≥ 2]hashsha256[sl = 3]SECURITYFig. 4. Example of a component for the UPDATELet's verify the deinstallation of the component SECURITY with its services (seeFig. 4 and Fig. 5). The service SECURITY.sha256 provided by the componentSECURITY is optional for the component UPDATE. The set of mandatory dependen-cies (MD) of the service provided by the component SECURITY is empty. There-fore, this component is deinstallable. The nodes which are removed from thegraph are calculated by the rule Effect-DI. Indeed, the service UPDATE.update whichis part of the optional dependency of the service SECURITY.sha256 has two re-quirements INTERNET[ϕ].web[ϕ] and C4.transfet, it represents the tail of two arcs.Therefore, the component UPDATE can not be deinstalled. The removed service isSECURITY.sha256. The resultant graph is represented in Fig. 5.C1.tcp-ipC2.dnsINTERNET.web(M, ϕC1 = φ, ϕtcp−ip = φ)(M, ϕC2 = φ, ϕdns = φ)C3.hash SECURITY.sha256(M, ϕINTERNET = [download ≥ 3], ϕweb = [v ≥ 2])C4.transferUPDATE.updateC5.pluginihm UPDATE.ihm(M, ϕC4 = φ, ϕtransfer = φ)(M, ϕINTERNET = [Type = ADSL2+, download ≥ 8], ϕweb = [v ≥ 3, lg = Fr])(O, ϕC5 = φ, ϕpluginihm = φ)Fig. 5. The dependency graph after the deinstallation of the component SECURITY5 Conclusion and Future workIn this paper, we have presented an extension of the deployment formalisation whichis described in [2]. This extension concerns the integration of extra-functional prop-erties in the deployment reasoning engine. Therefore, the description of depen-208dencies, the description of the context and the description of deployment rules areextended by properties and constraints on them. Thus, in the requirement side ofdependencies we express the components and the services constraints and in the pro-vided side of the dependencies we add properties of both services and components.This extension is not limited to the component and service names, its advantageis to be able to manage different instances of the same component and the sameservice according to their properties and depending on requirements and needs.Therefore, we will identify services and components by their instances and not bytheir names. Consequently, the verification of installation deinstallation is basedon instance satisfiability and not only name comparison. For that, deploymentrules presented in [2] are extended to take into account the verification of extra-functional properties. The integration of extra-functional properties in substitutionphase presented in [4] will be treated in another paper.Finally, we plan to deal with deployment policies which are often associatedwith extra-functional properties. These policies are used to control and personalisedeployment. For this reason, we have to formalise policies with their associated rulesfor each deployment phase to improve deployment quality while maintaining safety.References[1] Aagedal, J., Quality of Service Support in Development of Distributed Systems, Phd thesis, Universityof Oslo (2001).[2] Belguidoum, M. and F. Dagnat, Dependency management in software component deployment, in:FACS'06-International Workshop on Formal Aspects of Component Software (2006).[3] Belguidoum, M. and F. Dagnat, Dependability in software component deployment, in: DepCoS-RELCOMEX (2007), pp. 223230.[4] Belguidoum, M. and F. Dagnat, Formalization of component substitutability, in: FACS'07-InternationalWorkshop on Formal Aspects of Component Software (2007).[5] Cheesman, J. and J. Daniels, UML Components: A Simple Process for Specifying Component-BasedSoftware, Addison Wesley Professional, 2001.[6] Clark, A., A. Evans and S. Kent, Engineering Modelling Languages: A Precise Metamodelling Approach,in: Fundamental Approaches to Software Engineering, Grenoble, France, 2002, pp. 159173.[7] G.Ortiz and J. Hernandez, Toward UML Profiles for Web Services and their Extra-FunctionalProperties, in: ICWS '06: Proceedings of the IEEE International Conference on Web Services (2006),pp. 889892.[8] Lamport, L., Specifying Systems: The TLA+ Language and Tools for Hardware and SoftwareEngineers, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2002.[9] Object Management Group, UML profile for schedulability, performance, and time specification,Technical report, OMG (2002).URL http://www.omg.org/cgi-bin/doc?ptc/02-03-02[10] Object Management Group, UML 2.0 OCL Specification., Technical report, OMG (2003).URL http://www.omg.org/cgi-bin/doc?formal/02-06-39[11] Skene, J., D. D. Lamanna and W. Emmerich, Precise service level agreements, in: ICSE '04: Proceedingsof the 26th International Conference on Software Engineering (2004), pp. 179188.[12] Szyperski, C., Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 1998.[13] Vieira, M. and D. Richardson, The role of dependencies in component-based systems evolution, in:IWPSE '02: Proceedings of the International Workshop on Principles of Software Evolution (2002),pp. 6265.[14] Zschaler, S., Formal specification of non-functional properties of component-based software systems: Asemantic framework and some applications thereof, Software and Systems Modelling (SoSyM) (2009),to appear.209210Centrum Wiskunde & InformaticaCentrum Wiskunde & Informatica (CWI) is the national research institute for mathematics and computer science in the Netherlands. The institute’s strategy is to concentrate research on four broad, societally relevant themes: earth and life sciences, the data explosion, societal logistics and software as service.Centrum Wiskunde & Informatica (CWI) is het nationale onderzoeksinstituut op het gebied van wiskunde en informatica. De strategie van het instituut concentreert zich op vier maatschappelijk relevante onderzoeksthema’s: aard- en levenswetenschappen, de data-explosie, maatschappelijke logistiek en software als service.Bezoekadres:Science Park 123AmsterdamPostadres:Postbus 94079, 1090 GB AmsterdamTelefoon 020 592 93 33Fax 020 592 41 99info@cwi.nlwww.cwi.nl

Formal aspects of component software

Abstract

Extracted data

Formal aspects of component software

Abstract

Extracted data

Related items

Related items