and Emil Sekerinski

Formal Methods for Component Software:The Refinement Calculus PerspectiveMartin B¨u chi and Emil Sekerinski†June4,1997AbstractWe exhibit the benefits of using formal methods forconstructing and documenting component software.Formal specifications provide concise and complete de-scriptions of black-box components and,herewith,pavethe way for full encapsulation.Specifications using ab-stract statements scale up better than pre-postconditionsand allow for‘relative’specifications because they mayrefer to other components.Nondeterminism in specifi-cations permits enhancements and alternate implemen-tations.A formally verifiable refinement relationshipbetween specification and implementation of a com-ponent ensures compliance with the published specifi-cation.Unambiguous and complete contracts are thefoundation of any component market.1IntroductionThe separation of specifications/interfaces and imple-mentations of components is a prerequisite for the es-tablishment of component software.It alleviates thenecessity to distribute source code,thereby protectsthe implementation know-how and avoids overspecifi-cation.Overspecification basically prohibits future en-hancements and alternate implementations.Further-more,separate specifications enable the component in-tegrator to understand the functionality without havingto examine the source code.The lack of easily and quickly understandable,con-cise and complete specifications is the chief reason,why the advantages of the separation between specifica-tions and implementations are not commonly exploited.1We denote by interface the syntactical aspects only and by con-tract both the interface and the behavioral specification.1more,a specification which is created before the com-ponent is implemented,can facilitate a structured devel-opment and,thereby,create more general,robust and efficient components and often also helps to save costs.“When quality is pursued,productivity follows,”K.Fu-jino,as quoted in[14].For a recent overview of formal methods success stories see[10,29].The adaptation of formal specifications has been slow because of difficult notations which differ too much from implementation languages and lack of tool sup-port,but also due to ignorance and prejudice.We aim for a lightweight approach to formal methods,based on a rigorous and general formalism,but without an over-whelmingly rich expressiveness of the language,mod-eling,and analysis in favor of lower costs in terms of time,know-how,and money.We deviate from the clas-sic dogmatic view on formal methods,without aban-doning the foundations.Section2makes a plea for formal specifications as contracts,Sect.3shows why nondeterminism is also relevant for practitioners.Refinement between specifi-cations and implementations to ensure compliance and refinement between different versions of a specifica-tions are the topics of Sect. 4.Section5discusses invariants and temporal properties of components.In Sect.6we sketch some requirements and ideas for a specification language for component contracts.Sec-tion7points to related work and Sect.8draws the con-clusions.2A Plea for Formal ContractsThe buyer of a microprocessor or another chip usually requests a detailed description in form of a data sheet and,quite commonly,also an executable specification in form of a VHDL program.These descriptions form a contract,if a sale takes place.They describe all rele-vant information,such as form factor,voltage,and sig-nal delay in a standard way,that does not require inter-pretation.Contrast this with the typical description of an ActiveX software component:Incomplete plain tex-tual descriptions—often better suited for an advertis-ing leaflet—augmented with a formal part that merely describes the number and types of parameters.No pos-sibility for the customer to verify in advance whether the desired part meets the requirements,hours of trial and error tofind out how the component must be used, testing of a few cases as the only way to gain confi-dence,nothing which guarantees that only functionalityis used which will continue to exist in future versions. With contracts like this,it comes as no surprise that vendor and buyer often don’t agree on what the com-ponent should do.Hence,there is an urgent need for better contracts!A good contract is clear,complete, and concise.A bad contract is ambiguous,misses im-portant points,lays down irrelevant details,and is un-necessarily long.That current contracts,respectively in our terminology interfaces with textual addition,are too weak has also been acknowledged at WCOP’96[27]. The lack of standardized contracts for software compo-nents is due to the high degree of freedom compared to hardware,the immaturity of thefield,the difficulties in automated verification,and the—partly unnecessary —complexity and ill-definedness of common program-ming languages which further complicates verification.J´e z´e quel and Meyer[16]recently argued that the crash of the Ariane5[3]was due to a reuse specifica-tion error.A poorly documented limitation in a compo-nent originally designed for the Ariane4with different physical requirements caused the error.J´e z´e quel and Meyer conclude,that reuse without a contract is sheer folly.Yet,contracts are the most important non-practice in component software.A simple and popular form of contracts is that of as-sumptions,called preconditions,and promises,called postconditions.If a component is used in a correct manner,it has to satisfy its contract,i.e.establish the promised postcondition.If,however,its preconditions are not met,it has no obligations whatsoever and is free to behave arbitrarily(Fig.1).If a system consisting of several components fails do perform the requested job, the failure can be attributed either to a component not fulfilling its contract or to the integration,i.e.,even if all components behave as specified the whole system does not perform correctly.Without formal contracts, locating such errors is much more involved.Pre-and postconditions that are only checked at run-time help to locate errors,but do not prevent them as static analysis does.A program can still fail at a customer’s site with input values which have not been tested.Programmers annotate their programs with pre-and postconditions in order to make them more reliable. During test runs,they are checked at run-time,but for the production version,these checks are often disabled for efficiency reasons.This is like having lifeboats on a ship for a test cruise but getting rid of them for a transat-lantic cruise with passengers because of the additional load.Static analysis,on the other hand,allows only the removal of lifeboats which will provably never be used. 2BenefitsEnsure precond.Server Assume precond. Figure1:Obligations and benefits from pre-and post-conditionsBecause of the deficiencies of run-time only checking, programmers are not inclined to use pre-and postcon-ditions at all.Pre-and postconditions being predicates,they cannot contain calls to other methods,except pure functions. This means that using pre-and postconditions one has to reinvent the wheel afresh for each method,rather than being able to build upon other specifications.Specifica-tions in form of abstract statements are not affected by this scalability problem.Consider the partial specifica-tion of component Buffer using abstract statements: component Bufferb:set of Itemprint(d:Device)=for all x in b do do d.print(x) end BufferIf we were to specify the same component using pre-and postconditions,we would have to expand the defi-nition of the base type Device’s print method incurring a number of disadvantages.The specification of how print ultimately sets the pixels on a device would be rather lengthy and not of our interest here.We loose the information that a method of d is invoked.Reasoning about the program,we cannot use the knowledge that d is of(behavioral)subtype of Device with a more deter-ministic specification.Pre-postcondition specifications contradict encapsulation and specialization.Specifications by abstract statements come close to contracts as proposed by Helm et al.[15].Contracts of Helm et al.specify“behavioral dependencies”between objects in terms of method calls and other constructs. Contracts are expressed in a special purpose language and then have to be linked to the underlying program-ming language.By contrast,we like to see abstract statements as a moderate extension of the underlying programming language for expressing contracts. Changes to the specification of the print method,e.g. improved version decreasing nondeterminism,are not automatically reflected in the specification of Buffer. Pre-postconditions do not support‘relative’specifica-tions in the sense of relying on previous specifica-tions.The loss of self-containedness of abstract state-ment specifications can easily be compensated by a specification browser supporting in place expansion or hypertext-like facilities.We take the view that reentrant calls,po-nent A calling B and B making again a call to A,should also behave according to the specification and not be ad-versely influenced by some internal state components. If reentrant calls should behave differently,it is not clear how this should be specified and whether the imple-mentation must adhere to the call sequence given in the specification.The process of writing a formal specification often leads to more generally useful,easier to integrate,and longer-lived components.Rough edges,special cases, and anomalies resulting from implementation difficul-ties and lack of overview during implementation can often be detected and eliminated by a specification.For example,the above specification of Device states that for all elements in b,the method print is called in an arbitrary order.No element is printed twice,since a set contains an element at most once.If this is desired,we should have used a bag(multiset)rather than a set.If we like that the elements are printed always in the same order,we should have used a sequence rather than a set and an iteration in print.The specification also states that printing an empty buffer is a no–op rather than an error.By writing the specification,or at least parts of it,be-fore starting the implementation,one can benefit from the commonly advocated advantages of a structured de-velopment process[23].Cliff Jones[17]argues that for-malism employed to justify early data structure and de-sign decisions which helps avoid the most costly errors is the most important application of formal methods. Specifications written after the implementation tend to lay down irrelevant details of the specific implementa-tion and lack the desired degree of abstraction.How-ever,as with frameworks,an iterative approach is usu-ally needed and preferred over the waterfall model in order to get very general components.The number of it-erations can be reduced by formal specifications which help to eliminate implementation quirks.For some reasons forced to use a component that comes without a formal contract,it might even be worthwhile to write a specification of it as it is perceived and used.Such a‘contract assumption’can greatly sim-plify testing and reduce the time to evaluate the suitabil-ity of new and alternate versions of the component.A component should not only formally specify its 3own contract,but also the(minimal)contracts of its re-quired components.A calendar component might re-quire a database component which satisfies a certain contract[4,30].The component integrator can choose such a component,or—in a more dynamic scenario—the calendar component can‘shop’for the desired com-ponent at runtime.Formal specifications of required and existing components simplify also the creation of wrappers/adaptors.3Nondeterminism:Avoiding OverspecificationNondeterminism is an approach to deliberately leave a decision open,to abandon the exact predictability of future states.As such,nondeterminism appears to be neither commonly desirable nor is it used in implemen-tation languages.On the other hand,nondeterminism is a fundamental tool for specifications to avoid laying down unnecessary details2.A nondeterministic specification leaves more choice for the implementation,which can be used for optimiza-tions.Even if this degree of freedom is not used in the envisagedfirst implementation,it greatly increases the likelihood that future enhancements and alternate im-plementations can be made compliant with the spec-ification.The earlier specification of the component Buffer is an example.Nondeterminism often enhances the comprehensibil-ity of specifications because the reader does not have to wonder why something has to be exactly in a cer-tain way,when other choices would be as good.Many things are actually nondeterministic and should be ac-knowledged and specified as such. Nondeterminism from an outside perspective often stems form information hiding,where the actual im-plementation is deterministic.A SQL database query without any sorting options returns an arbitrarily sorted list of records;a square root function returns an arbi-trary value satisfying the specified precision.Both im-plementations are deterministic,but the outcomes are determined by hidden state components and implemen-tation details.Nondeterminism can also be present in the imple-mentation.This occurs typically when the implemen-C D def S S C S DIf an implementation of a component constitutes a refinement of its specification,any client designed ac-cording to the specification will work with the imple-mentation.This is exactly what is implied by the above definition.On the other hand,two implementations of a component which are both refinements of the same specification might not be in a refinement relationship to each other(Fig.2a).Hence,it is important that clients only rely on properties guaranteed by the speci-fication.Testing cannot uncover reliance on unspecified implementation features,only formal analysis can. Nierstrasz and Tsichritzis[24]remark that encapsu-lation is violated if clients of a software component must be aware of implementation details not specified in the contract in order to make correct use of a com-ponent.In particular,if changes in the implementation that respect the original contract may affect clients ad-versely,then encapsulation is violated.Clients which rely only on properties specified in the contract never fall into this trap.However,a contract may be too weak so that the corresponding components can not be used intelligently.Unfortunately,fully automatic proving of refine-ments similar to type checking performed by a com-piler does not seem to be feasible in the foreseeable future.Because of this,contracts are approximated by interfaces,guaranteeing only syntactic compatibil-ity.The B-Toolkit[5]and Atelier-B[25],two environ-ments for the B method[2],show,however,that semi-automated refinement proofs are feasible for industrial applications.Automatic proofs of refinement are an ab-solute necessity for components which at runtime shop for other components which satisfy a required contract. Instead of a full refinement proof,automatic test data generation from the specification,approximate reason-ing with upper and lower bounds,finite state analy-sis with binary decision diagrams based on equivalence classes,and relative debugging can be employed to gain confidence in the correctness and to isolate parts merit-ing formal proofs[9,12,11].In relative debugging,an alternative to a full refinement proof stemming from the field of scientific computing[1],the specification and the implementation are executed in lockstep and their states are compared after each statement according to a mapping relation.If we want to better a component,we have to incor-porate the improvements into the specification.Other-wise,they cannot be used by any clients which are only allowed to rely on features guaranteed by the specifica-tion.An advanced component should also be usable by an old client,which knows nothing about the improve-ments.If the new specification is a refinement of the old specification and the new implementation refines the new specification,then by transitivity of refinement it also refines the old specification.Hence,refinement is also an important relationship between different ver-sions of a component’s contract.However,an imple-mentation of the new specification does not necessarily refine an implementation of the old specification(Fig. 2b).In a world where progress is acceptable only if it is compatible with the current state,refinement is a crucial relationship.We have not addressed performance,but the separa-tion of specifications and implementations,which are refinements thereof,permits the replacement of inef-ficient components by efficient components which ad-here to the same specification without any modification to the clients.It also allows for several components pro-viding the same functionality which are tuned for dif-ferent usages,e.g.,set implementations as arrays and as lists.We could even specify an advanced set component as a refinement of the basic set component which pro-vides a meta level method for controlling performance-relevant mapping decisions[18].An implementation of the advanced set component might package the two set implementations into a single component and select the actual data structure according to the preferences set through the meta method.5Invariants and Temporal Prop-ertiesAssume that a counter component,which is initialized to0,provides methods to read the counter value and to increment it by2.A putative refinement might add an increment by1function.A client can use the re-fined component like a basic component.However,if the counter component is used simultaneously by dif-ferent clients and another client is aware of the added functionality,thefirst client might read an odd counter value,which it did consider impossible to happen.The strongest invariant,the predicate characterizing exactly all reachable states,of the basic counter contains only even values.With our definition of refinement,clients cannot rely on observing only states permitted by the 5SpecificationImplementation 1Implementation 2a)b)Specification 1Implementation 1Implementation 2 Specification 2Figure2:Refinement relationshipsstrongest invariant derived from the contract known to them.Alternatively,we could have defined refinement so that added methods may not invalidate the strongest invariant.In this case an increment by1function would not be legal,but an increment by4function would be. Assume that in an alternate refinement of our ba-sic counter,we add a decrement by2function,which does not decrement the counter below0.This refine-ment does not violate the strongest invariant of the ba-sic counter,but leads to additional transition traces.A client of the basic counter might assume that after hav-ing read a value of10,it will never again read a value below10.This temporal property is not preserved by the refinement.An increment by4would add state changes and traces.Depending upon the environment,a client might not be able to observe whether the counter has been in-cremented twice by2or once by4(mumbling invari-ance).Although not stated explicitly,in most component frameworks neither the strongest invariant nor all tem-poral properties derivable from the contract are safe to assume.Nevertheless,many clients do so.In fact,com-ponent designers often want to guarantee that certain in-variants and temporal properties are safe to assume and will be preserved by refinements,but with current IDLs they cannot express this.A component contract could contain a section with a component invariant and as-serted temporal properties.Temporal properties may be expressed in temporal logic,disconnected pairs seman-tics[8],and trace semantics[6].A refinement can only constrain,but not enlarge the set of reachable states as defined in the original invariant.The definition of trace refinement is given by Back and von Wright[6].6Specification LanguageMost specification languages are very close to their mathematical foundations.They are judged by their expressiveness with little attention paid to readabilityby normal programmers,accustomed to programming languages such as Pascal and C++,and suitability to machine analysis.C++owes parts of its success to its resemblance to C,the creators of Java stressed the syn-tactical similarity to C++,and the CORBA IDL is a modified subset of C++.Likenessflattens the learning curve and improves the acceptance.Hence,a specifi-cation language for general use should be similar to a well-known implementation language.Many programming languages are optimized for easy analysis,e.g.,LL1parsability.Tool support for specifi-cation languages all too often comes as an afterthought. This complicates tools even further and hinders their creation.Without tool support,formal specifications loose many of their benefits.A specification which can be executed,respectively simulated with help from the user,can help the designer verify its correctness,and can be used for relative de-bugging of an implementation.For hardware vendors it is common practice to distribute VHDL descriptions of their parts free of charge to prospective clients;like-wise,software component creators could distribute their (executable)specifications which help the customers make more educated buying decisions.We believe that many people are also more willing to write a formal specification if it is executable.It is often impractical,infeasible,unnecessary,or confusing to specify all aspects of a component,e.g. exact output form on screen.Partiality of modeling,fo-cus on essentials and simplicity in design make systems more suitable to analysis by humans and machines. Rather than covering everything,a specification lan-guage should support simplicity.If something cannot be nicely expressed in a specification language and for-mally be handled,it might be best not to use it at all. 7Related WorkThe Interface Specification Language(ISL),a pure extension of the CORBA IDL,developed in the 6Component-Based Software Engineering project at CSTaR Software Engineering Lab supports the descrip-tions of pre-/postconditions of operations,invariants and protocols of interfaces[19].ISL opts for featur-ism,including multiple inheritance across components, rather than simplicity as we promote it.ISL is a sub-language of the Architecture Specification Language, which also includes the Glue Specification Language and the Configuration Specification Language. Participants in the Composable Software Systems project at Carnegie Mellon try to specify not only func-tional behavior of components,but also reliability,per-formance,and security aspects[13].They call concepts similar to refinement behavioral subtyping for classes [20]and matching for components[30].Bertrand Meyer propagates design by contract for component software,albeit of a less formal nature [21,22].Clemens Szyperski and Rosziati Ibrahim are working on the formalization of Microsoft’s COM ob-ject model[28,26]as starting point for a more general investigation in formal methods for component soft-ware.The Object Systems Group at the University of Geneva under Nierstrasz and Tsichritzis have re-searched a number of applications of semi-formal meth-ods to component software[24].8ConclusionsWe have argued that only formal contracts paired with refinement can guarantee full encapsulation of software components,which is the base for improved and alter-nate implementations.Formal contracts lead to a more structured development,more orthogonal and,hence, longer-lived and more generally useful components,of-ten at a lower cost.Nondeterminism is a necessity for providing freedom of implementation.Refinement guarantees that imple-mentations adhere to their specifications and that new versions are plug-compatible.A language for speci-fying contracts,should be similar to well-known im-plementation languages to improve its readability and acceptance and should be designed with tool support in mind.Abstract statements do not have the scala-bility problems of pre-postcondition specifications be-cause they allow for external calls.Formal methods are needed to compensate the loss of the closed-world assumption and the impossibility to test a component in all possible environments.They are,however,no universal panacea nor is their applica-tion very simple,but we regard them as a necessity for the establishment of component software. Acknowledgments We would like to thank the refer-ees for helpful comments,Wolfgang Weck and Ralph Back for a number of fruitful discussions and inspir-ing ideas,and Lars Nielsen and Marcel Mettler for their help with this paper.References[1]David Abramson,Ian Foster,John Michalakes,and Rok Sosic.Relative debugging:A newmethodology for debugging scientific applica-munications of the ACM,39(11):69–77,November1996.[2]J.R.Abrial.The B Book:Assigning Programs toMeanings.Cambridge University Press,1996.[3]European Space Agency.Ariane5:Flight501failure,1996.http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html.[4]´Asgeir´Olafsson and Doug Bryan.On the needfor“required interfaces”of components.InM.Muehlhaeuser,editor,Special Issues in Object-Oriented Programming.dpunkt V erlag Heidel-berg,pages159–165,1997.ISBN3-920993-67-5.[5]B-Core.B-Toolkit.England,1995.[6]R.Back and J.von Wright.Trace refinement ofaction systems.In CONCUR94,pages367–384.LNCS836,Springer V erlag,1994.[7]Ralph J.R.Back and Joackim von Wright.Re-finement Calculus:A Systematic Introduction.Springer V erlag,1997,to appear.[8]Stephen Brookes.Full abstraction for a sharedvariable parallel language.In Proceedings ofthe8th Annual IEEE Symposium on Logic inComputer Science,pages98–109,June1993.Also appeared in Information and Computation127(2):145–163.[9]Marsha Chechik and John Gannon.Automaticanalysis of consistency between requirements anddesigns.In Technical Report CS-TR-3394.1,University of Maryland,College Park,1995.http://www.cs.utoronto.ca/˜chechik/.7[10]Edmund M.Clarke and Jeannette M.Wing.For-mal methods:State of the art and future direc-tions.ACM Computing Surveys,28(10),Decem-ber1996.[11]Craig A.Damon Daniel Jackson and SomeshJha.Faster checking of software specificationsby eliminating isomorphs.In Proc.ACM Conf.on Principles of Programming Languages,1996./afs//project/nitpick/www/home.html.[12]Craig A.Damon,Somesh Jha,and Daniel Jack-son.Checking relational specifications with binary decision diagrams.In Proc.Foun-dations of Software Engineering’96,1996./afs//project/nitpick/www/home.html.[13]David Garlan,Daniel Jackson,Mary Shaw,andJeannette posable software systems,1996./˜Compose/andftp:///project/compose/brief.ps. [14]Carlo Ghezzi,Dino Mandrioli and Mehdi Jazay-eri.Software Engineering.Prentice Hall,1991.[15]Richard Helm,Ian M.Holland,and DipayanGangopadhyay.Contracts:Specifying Behav-ioral Compositions in Object-Oriented Systems.In Proc.of OOPSLA/ECOOP’90Conference on Object-oriented Programming Systems,Lan-guages and Applications,pages169–180,Oct.1990.ACM SIGPLAN Notices25(10).[16]Jean-Marc J´e z´e quel and Bertrand Meyer.Put it inthe contract:The lessons of ariane.IEEE Com-puter,pages129–130,January1997.[17]Cliff B.Jones.A rigorous approach to formalmethods.IEEE Computer,pages20–21,April 1996.[18]Gregor Kiczales.Why are black boxes so hardto reuse.In Proceeding of OOPSLA’94,1994./spl/projects/oi/towards-talk/transcript.html.[19]W.Kozaczynski and J.O.Ning.Concern-drivendesign for a specification language.In Proceed-ings of the8th International Workshop on Soft-ware Specification and Design,Berlin,Germany,March1996.[20]Barbara H.Liskov and Jeanette M.Wing.A be-havioral notion of subtyping.ACM Transactionson Programming Languages and Systems,16(6),November1994.[21]Bertrand Meyer.Applying‘design by contract’.IEEE Computer,25(10):40–51,October1992.See also /doc/manuals/technology/contract/index.html.[22]Bertrand Meyer.Object-Oriented Software Con-struction.Prentice Hall,second edition,1997. [23]Carroll C.Morgan.Programming from Specifica-tions.Prentice Hall,1990.[24]Oscar Nierstrasz and Dennis Tsichritzis,editors.Object-Oriented Software Composition.PrenticeHall,1995.[25]St´e ria M´e diterran´e e.Atelier-B.France,1996.[26]Clemens A.Szyperski.Independently exten-sible systems—software engineering potentialand challenges.In Proceedings of the19thAustralasian Computer Science Conference,Mel-bourne,1996.[27]Clemens A.Szyperski and Cuno Pfister.Component-oriented programming:WCOP’96workshop report.In M.M¨u hlhaeuser,editor,Special Issues in Object-Oriented Programming.dpunkt V erlag Heidelberg,pages127–130,1997.ISBN3-920993-67-5.[28]Clemens A.Szyperski and Rosziati Ibrahim.Formal methods for component software,1997.http://www.fi.au/˜ibrahim/formal.html.[29]WWW Virtual Library.Formal methods./archive/formal-methods.html.[30]Amy M.Zaremsky and Jeannette M.Wing.Spec-ification matching of software components.InSIGSOFT Foundations of Software Engineering,October1995.Also CMU-CS-95-127.8。