Component-based Coalgebraic Specification and Verification in RSL

UNU/IISTInternational Institute forSoftware TechnologySun Meng and Bernhard K.Aichernig October2002UNU/IIST and UNU/IIST ReportsUNU/IIST(United Nations University International Institute for Software Technology)is a Research and Training Centre of the United Nations University(UNU).It is based in Macau,and was founded in1991.It started oper-ations in July1992.UNU/IIST is jointly funded by the Governor of Macau and the governments of the People’s Republic of China and Portugal through a contribution to the UNU Endownment Fund.As well as providing two-thirds of the endownment fund,the Macau authorities also supply UNU/IIST with its office premises and furniture and subsidise fellow accommodation.The mission of UNU/IIST is to assist developing countries in the application and development of software tech-nology.UNU/IIST contributes through its programmatic activities:1.Advanced development projects,in which software techniques supported by tools are applied,2.Research projects,in which new techniques for software development are investigated,3.Curriculum development projects,in which courses of software technology for universities in developingcountries are developed,4.University development projects,which complement the curriculum development projects by aiming tostrengthen all aspects of computer science teaching in universities in developing countries,5.Schools and Courses,which typically teach advanced software development techniques,6.Events,in which conferences and workshops are organised or supported by UNU/IIST,and7.Dissemination,in which UNU/IIST regularly distributes to developing countries information on interna-tional progress of software technology.Fellows,who are young scientists and engineers from developing countries,are invited to actively participate in all these projects.By doing the projects they are trained.At present,the technical focus of UNU/IIST is on formal methods for software development.UNU/IIST is an internationally recognised center in the area of formal methods.However,no software technique is universally applicable.We are prepared to choose complementary techniques for our projects,if necessary.UNU/IIST produces a report series.Reports are either Research R,Technical T,Compendia C or Adminis-trative A.They are records of UNU/IIST activities and research and development achievements.Many of the reports are also published in conference proceedings and journals.Please write to UNU/IIST at P.O.Box3058,Macau or visit UNU/IIST’s home page:,if you would like to know more about UNU/IIST and its report series.Armando Haeberer,DirectorUNU/IISTInternational Institute forSoftware TechnologyP.O.Box3058MacauSun Meng and Bernhard K.AichernigAbstractComponent-based software development has become a popular paradigm in software engineering.From the theoretical point of view,components can be seen as coalgebras.We present a coalgebraic technique for component-based system specification and verification which is based on RSL,the wide spectrum specification language of the RAISE method.A bisimulation relationship between components is de-fined for reuse of components and used in the behavior verification of specification development.Final coalgebras are used to construct the minimal implementations of given specifications.Sun Meng is a Fellow at UNU/IIST on leave from the School of Mathematical Science of Beijing Uni-versity,China,where he is a Ph.D candidate.His research interests include category theory,coalgebra theory,Object-Oriented method,formal method in software development,and formal semantics for mod-eling languages.His email address is sm@.Bernhard K.Aichernig is a Research Fellow at UNU/IIST.He is also an assistant professor at the Institute for software Technology at the Graz University of Technology in Austria.His research interests include the synergies of testing and formal development methods,techniques of refinement,and require-ments engineering supported by formal specification languages.His email address is bka@. Copyright c2003by UNU/IIST,Sun Meng and Bernhard K.AichernigContents iIntroduction1 1Category theory provides a proper abstration level for interpreting the difference between algebras and coalgebras.Let be an endofunctor on the category,a-algebra is a pair consisting of a set and a map, whereas a-coalgebra is a pair consisting of a set and a function.An algebra tells us how to construct elements in and a coalgebra shows the observations on.Two elements and are bisimilar if there is a bisimulation relation with .In this case we write it as.Another important concept in coalgebra theory is the notion of invariant which is defined by Hermida and Jacobs with predicate lifting in[HJ98].An invariant is a predicate on the state space of a coalgebraFinal coalgebras are of particular interest because of the following property which is the coinductive proof principle(cpp).where is the unique arrow from to.This construction can be used for the polynomial functors because they preserve limits along such countable chains.Final coalgebras has been used as the canonical domains of semantics.In[Acz94],a semantics of CCS is shown by exploiting thefinal coalgebra of an endofunctor as the operational model of CCS.[TR98] shows that thefinal coalgebra is a suitable operational model where behaviourally equivalent elements are indistinguishable.An interplay between initial algebra andfinal coalgebra semantics which is the basis of the categorical approach to structural operational semantics is presented in[Tur96,TP97].3Coalgebraic Specification and Verification in RSLIn this section,we will use a banking system example to illustrate the component based algebra-coalgebraic specification and development between specifications with different styles,such as applicative,impera-tive and concurrent ones.A bank in the system composes a set of accounts.Each account belonging to a bank has an owner,a balance and a unique account identifier.Customers of a bank can open and close an account,credit and debit money to an account,and transfer an amount from an account to another account.The UML conceptural model of this system is given in Figure1.Describing such a system in a formal way would be useful in reducing the ambiguity of the functions of the system.In the following it is shown how the components of such a system are specified via RSL specifications appropriately.AclasstypeAccountvaluebalancea:Account Nat Account,debita:Accountaxioma:Account,m:Natbalance a(a,m))balancea(debit a(a)mpre balancea(accountA component is represented by the observerandReport No.267,October2002UNU/IIST,P.O.Box3058,Macauexpr1valuewhich is used for creating new bank accounts.The values in this specification can be seperated into three categories:constructors()and actions(such as).Constructors are algebraic operations for creating new states.Initial states are used in coalgebraic specification formalisms to model such con-structors as shown in[Jac96b].Both observers and actions can be seen as coalgebraic operations,and the difference between them lies in the form of the coalgebraic functors.For the observers,the associated functor has the form(or written as)which yields an observable element in corresponding to input elements in(which may be empty,that means,no input parameter is needed to get the observable element and the form of the corresponding functor is)and does not change the state space.For actions,the associated functors has the form which does affect the state space.In this example,the functions for the observers and actions are given as:Based on the observations and actions,the behavior equivalence(bisimulation)relationship between two components with the same observers and actions can be defined as follows:A specification does not need to in-terpret equal as,where is an account and is an integer,but rather as a state bisimular to.For example,the type may be implemented as a sequence of con-secutive changes.That is,take as the set offinite sequence of integers,for an arbitrary account,define,andIL and ACCOUNTILclasstypeAccount Intvaluebalance:Account Natbalance(a)if a then0elsehd(a)balance(tl(a))end,credit:Account Nat Accountcredit(a,m)m a,debit:Account Nat Accountdebit(a,m)m apre balance(a)m,account:AccountendINclasstypeAccount Natvaluebalance:Account Natbalance(a)a,credit:Account Nat Accountcredit(a,m)a m,debit:Account Nat Accountdebit(a,m)a mpre balance(a)m,account:Account0endThe bisimulation relationship between two components for the ACCOUNTIN,ACCOUNTIN,AL:ACCOUNTIL and one state ACCOUNTReport No.267,October2002UNU/IIST,P.O.Box3058,MacauIN anddefinition of balance in ACCOUNTIN,ACCOUNT4All the theorems in this paper are either proved in PVS or the result is obvious and proved by hand.ININ,AL:ACCOUNTA and the statechart diagram,we can see that the functionReport No.267,October2002UNU/IIST,P.O.Box3058,MacauA specification,the statechart diagram in Figure3has shown such an implementation explicitly.To represent it in RSL specification,wefirst need to define a type for the account states appeared in the statechart and a value to check the state of an account(it’s a trivial definition in this example because there is only one state in the statechart diagram,but such definition is needed sometimes when there are more states):typeAccountState Okvalueacstatea should satisfy the following axioms:axioma:Account,m:Natacstate a(a)m(acstate a(a,m))Ok)(balance a(a,m))balancea(a)Ok balance a(debita(debit a(a)),The function might be implemented by a conditional expression to deal with the different cases,where we use the set offinite sequences of integers as the type as previously:typeAccount Intvaluedebita(a,m)a(a)m thenaelsea mendThe error handling approach here exploits a“guard”which checks whether a predicate(precondition) is true before it calles a function.However,the condition also may be checked during the execution of the function instead of before it is called.This is the question called discovery propagation in[The95]. Generally,Including the check of conditions within the function being called typically means changing the result type of the function to indicate success or failure,and this leads to the recovery propagation problem which deals with the problem of handling the errors at the appropriate level and three main ways are provided and discussed in[The95]:To use some variable in which an appropriate error indication is deposited;To define a new type for the result of functions within which errors may arise;To provide an extra channel on which errors may be reported.3.3Transformation of RSL Component Specification from Applicative to Imperative The applicative RSL specifications follow a“functional programming”style.Inside this style,(refine-ment)proofs are much simpler than in the imperative paradigm.However,the intended implementation style is likely to be imperative.Fortunately,the RAISE method provides the systematic approach to do transformations between applicative specifications and imperative ones.It is comparatively easy to change a RSL component specification from applicative to imperative and vice versa.The method is described as follows:First,the“type of interest”,that is,the type of the variables that being observed or modified by the values,are identified.Consider the in the applicative account specification as an example:valuebalancea:Account Nat Accountwhere is an action of.In the imperative case,the variable(s)of type arefirst created,and then the values are represented as follows:variablei:Unit read act Natcreditacts on a value of type Unit,read the value of variable and returns a result with type Nat.Here the type Unit is used as the parameter type for a function without parameters.For the functionIclassvariableact:Natvalueaccounti:Unit read act Int,crediti:Nat write act Unitaxiomaccounti()act,m:Natcrediti(m)act:act mpre balanceReport No.267,October2002UNU/IIST,P.O.Box3058,MacauAscheme BANKin:X.Key read any Bool,addaccount:X.Key write any Unit,deposit:X.Key Nat write any Unit,withdraw:X.Key Nat write any Unit,balance:X.Key read any Nat,transfer:X.Key X.Key Nat write any Unit axiomk:X.Keynewbank();isaccount(k2);isaccount(k2);trueelse let x is account(k2);x endend,k1,k2:X.Keyremove in(k1)if k1k2then removein(k1)in removeis used to check whether an account is in the set of active accounts of the bank.are used to open and close an account.and are used to credit and debit an amount to an account.is for checking the money in one account.is for transfering an amount from one account to another one.These operations match exactly what a bank offers to outside.A real bank system should be concurrent which permits different operations being executed simultane-ously.RSL provides combinators for specifying concurrent evaluation of expressions,and sequential specifications can also be developed into concurrent ones as following:First define an object which is the instance of the sequential module.objectI:BANKS,ACCOUNTC(X:class type Key end)classobjectS:BANKin:X.Key in any out any Bool,addaccount:X.Key in any out any Unit,deposit:X.Key Nat in any out any Unit,withdraw:X.Key Nat in any out any Unit,balance:X.Key in any out any Nat,transfer:X.Key X.Key Nat in any out any Unitaxiomk:X.Key(main()–newbank())–removeaccount(k1))–removeaccount(k1)else(main()–remove account(k1)end,k:X.Key,test:Bool Unit(main()–newbank())–test(isaccount(k1))–test(isaccount(k1))–test(true)else(main()–test(is account(k1)end,k:X.Key,m:Natmain()–deposit(k,m)S.deposit(k,m);main(),k:X.Key,m:Natmain()–withdraw(k,m)if balance(k)m then S.withdraw(k,m);main()else main()end,k1,k2:X.Key,m:Natmain()–transfer(k1,k2,m)if balance(k1)m then S.withdraw(k1,m);S.deposit(k2,m);main()else main()endendI scheme.This is a common encapsula-tion technique in component based software development,which prevents contents inside a component from being accessed by others except through specified observers and operations.scheme ENCAPSULATED I hide act in ACCOUNTof inclasstypeSetvalueempty:Set,add:E.Elem Set Set,remove:E.Elem Set Set,setin:E.Elem Set Boolis of(s)of(empty),e:E.Elem,s:Setset of(s),e:E.Elem,s:Setset of(s)eendscheme LIST(E:class type Elem end)classtypeSet E.Elemvalueempty:Set,add:E.Elem Set Setadd(e,s)e s,remove:E.Elem Set Setremove(e,s)case s of,h tif h e then remove(e,t)else h remove(e,t)endend,isin(e,s)case s offalse,h t e h isis hidden in the specification SET,that means this function can not be called from outside,but only within the component itself.Therefore,it does not need to be implemented in the refinement of this specification.This is different from the traditional data/algebra refinement[AKK99] and program refinement[BvW98]approaches.For specifications which involve hidden values,and the axioms in the specifications are formulated in terms of these hidden values,an implementation of such specification may not cover the hidden values,therefore it might be impossible to check whether the axioms hold in the implementation.Such implementations are called behavior refinement in[JT01].To verify whether a concrete specification is a behavior refinement of an abstract one,we need to check that every model of the concrete specification should be observable indistinguishable to some model of the abstract one.seperately.An-coalgebra incorporates all the observers and actions of the component SET.Moreover,to make the coalgebra a model of the specification,it should satisfy the axioms in the specification,which are represented via the hidden valueas a model of LIST where is the list of and an arbitrary model of SET with the empty set as its initial state,there is a bisimilarity.Here means bisimular up to the natural transformation which projects all the functors of a specification into its public interfaces,such a relationship is called“publicly indistinguishable”in[JT01].According to Definition3.1,we can define the with naturally as follows:This is indeed an appropriate bisimulation:if,then for any,,and for every,and. Every behavior of SET is realised without implementing the hidden valueSETin(e,s)L.isin(e1,S.add(e2,s))L.isin(e1,S.remove(e2,s))L.isSETSETSETLISTcontext:LISTscheme Eof:Set E.Elem-setset.This value does not affect the behavior of the component because this observer is a conservative extension.Then,we get the theorem as follows:context:SET,EELIST:axiomin class object E:class type Elem end end(LIST(E)SET(E))end4Final Coalgebras:the Best ImplementationFinal coalgebras,which are the canonical domains of interpretation for the behavior of systems,are of particular interest in the research of coalgebra theory.Thefinal coalgebra semantics complement the standard initial algebra approach.Thefinal coalgebra of the interface functor for a component,if it exists, forms an operational model of the component where behaviourally equivalent states are indistinguishable and specifies the characterisation of the behaviors observable.For every polynomial functor,afinal coalgebra does exist[Rut00].Jacobs[Jac96b]gives an explicit description of the construction offinal coalgebras for polynomial func-tors.Proposition4.1(Lemma6in[Jac96b])Thefinal coalgebra of the polynomial functor on the category of sets can be described as a set of infinite trees where,,.is the concatenation of sequences from.The interpretations of are given byThis proposition only gives thefinal coalgebras for a functor(the signature of an interface),whereby the axioms in a specification are ignored.A natural consideration is tofind thefinal coalgebra in the category of coalgebras satisfying the axioms,and thisfinal coalgebra gives us the“best possible”implementation of the corresponding component specification.Therefore,tofind thefinal coalgebra of a component specification includes two steps:1.Firstfind thefinal coalgebra of the interface functor of the specification by applying Proposi-tion4.1;e the axioms in the specification to cut down the carrier set of thefinal coalgebra resulting fromthefirst step and get the proper subcoalgebra.Consider the bank account specification as an example.From thein the specification.The single element in shows the error handling approach described in Section3.2.Afinal coalgebra over this functor is given with carrier by applying Proposition4.1where corresponds to andHere becauseFrom the interpretation of the operations,we can getoperation as follows:(3) Now,we get a subset which consists of thoseand satisfy thatas followsas follows:andThen we get a descending chain,and take the limit of this chain,the result isis completely determined by its value on the empty list.HenceisConclusion and Future Work25A.The implementation of this specification corresponding to thefinal coalgebra is given in the specification ACCOUNTIN is a correct and minimal implementation of ACCOUNT。