Checking the conformance of Java classes against algebraic specifications

  • 格式:pdf
  • 大小:301.57 KB
  • 文档页数:20

CheckingtheConformanceofJavaClassesAgainstAlgebraicSpecifications

IsabelNunes,Ant´oniaLopes,VascoVasconcelos,Jo˜aoAbreu,andLu´ısS.ReisFacultyofSciences,UniversityofLisbon,CampoGrande,1749–016Lisboa,Portugal{in,mal,vv,joao.abreu,lmsar}@di.fc.ul.pt

Abstract.Wepresentandevaluateanapproachfortherun-timeconformancecheckingofJavaclassesagainstproperty-drivenalgebraicspecifications.Ourproposalconsistsindetermining,atrun-time,whethertheclassessubjecttoanal-ysisbehaveasrequiredbythespecification.Thekeyideaistoreducetheconfor-mancecheckingproblemtotheruntimemonitoringofcontract-annotatedclasses,aprocesssupportedtodaybyseveralruntimeassertion-checkingtools.Ourap-proachcomprisesaratherconventionalspecificationlanguage,asimplelanguagetomapspecificationsintoJavatypes,andamethodtoautomaticallygeneratemonitorableclassesfromspecifications,allowingforasimple,buteffective,run-timemonitoringofboththespecifiedclassesandtheirclients.

1IntroductionTheimportanceofformalspecificationinsoftwaredevelopmentiswidelyrecognized.Formalspecificationsareusefulfordeveloperstoreuseexistingsoftware.Theyalsohelpprogrammersinunderstandingwhattheyhavetoprovide.Furthermore,theycanbeusedastestoracles,i.e.,systembehaviorcanbecheckedagainstthespecification.Currently,DesignbyContract(DBC)[18]isthemostpopularapproachforformallyspecifyingOOsoftware.Inthisapproach,specificationsareclassinterfaces(Javainter-faces,Eiffelabstractclasses,etc.)annotatedwithpre/postconditionspairsexpressedinaparticularassertionlanguage.Atruntime,theimplementationcanbetestedagainstitsspecificationbymeansofcontractmonitorization.AlthoughtheDBCmethodologyhasbecomeverypopular,programmersrarelyspecifycontracts—thestrongrestrictionstothekindofpropertiesthatarebothexpress-ibleandmonitorable,contributetothefrustrationofbeingleftwithverypoorspecifi-cations.Furthermore,asarguedbyBarnettandSchulte[3],contractspecificationsdonotallowthelevelofabstractiontovaryanddonotsupportspecifyingcomponentsindependentlyoftheimplementationlanguageanditsdatastructures.Algebraicspecification[2,6,10]isanotherwell-knownapproachtothespecifi-cationofsoftwaresystemsthatsupportsahigher-levelofabstraction.Algebraicap-proachescanbedividedintotwoclasses:model-orientedandproperty-driven.Fromthetwo,model-orientedapproachestospecification,liketheonespromotedbyZ[20],Larch[11]andJML[17],definitelyprevailwithintheOOcommunity.Inmostoftheseapproaches,thebehaviorofaclassisspecifiedthroughaveryabstractimplementation,basedonprimitiveelementsavailableinthespecificationlanguage.2IsabelNunes,Ant´oniaLopes,VascoVasconcelos,Jo˜aoAbreu,andLu´ısS.ReisImplementationscanbetestedagainstspecificationsbymeansofruntimeassertion-checkingtools.Thisrequiresanabstractionfunctiontobeexplicitlyprovided.InJML,forinstance,aconcreteimplementationisexpectedtoincludeJMLcodedefiningtherelationbetweenconcreteandabstractstates.Althoughwerecognizetheimportantroleplayedbymodel-basedapproaches,webelievethat,forasignificantpartofpro-grammers,understandingorwritingthiskindofspecificationscanberatherdifficult.Moreover,programmersimplementingaspecificationhavetodefinetheappropriateabstractionmapping,whichcanalsoberatherdifficulttoobtain.Incontrast,foracertainclassofprograms,inparticularforAbstractDataTypes(ADTs),property-drivenspecifications[6,8]canbeverysimpleandconcise:theob-servablebehaviorofaprogramisspecifiedsimplyintermsofasetofabstractproper-ties.Thesimplicityandexpressivepowerofproperty-drivenspecificationsmayencour-agemoreprogrammerstouseformalspecifications.However,thesupportforcheck-ingOOimplementationsagainstproperty-drivenspecificationsisfarfrombeingsatis-factory.Asfarasweknow,itisrestrictedtopreviously-presentedapproaches[1,13],whoselimitationsarediscussedindetailinSection8.ThispaperpresentsanewapproachforruntimecheckingOOimplementationsagainstproperty-drivenspecifications.Thekeyideaistoreducetheproblemtotherun-timemonitoringofcontracts,whichissupportedbymanyruntimeassertioncheckingtools(e.g.,[5,15–17,21]).Theclassesundertestingbecomewrappedbyautomaticallygeneratedclasses.Thewrapperclassesareannotatedwithrun-timecheckablecontractsautomaticallygeneratedfromthecorrespondingspecifications.Adistinguishingfeatureoftheapproachisthatourmodulespecificationsnotonlyspecifybehavioralpropertiesrequiredfromimplementations,buttheyalsodefinetherequiredarchitectureoftheimplementations,i.e.,howtheimplementationshouldbestructuredintermsofclasses.Thisisimportanttosupportreuse:itallowstoenforcethattheimplementationofamoduleMisachievedintermsofclassesthatcanbereusedintheimplementationofothermodulesthathaveelementsincommonwithM.TheapproachistailoredtoJavaandJML[17]butitcouldaswellbedefinedtowardsotherOOprogrammingandassertionlanguages(orotherprogramminglanguageswithintegratedassertions[4,18]).Itcomprisesaspecificationlanguagethatallowsauto-maticgenerationofJMLcontracts,andalanguagefordefiningrefinementmappingsbetweenspecificationmodulesandcollectionsofJavaclasses.Refinementmappingsdefinehowsortnamesaremappedtoclassnamesandoperationsignaturesaremappedtomethodsignatures.Becausethisactivitydoesnotrequireanyknowledgeabouttheconcreterepresentationofdatatypesorcomponentstates,refinementmappingsarequitesimpletodefine.Ourapproachoffersseveralbenefits.Moresignificantly: