IO-refinement in Z - BCS

18 Pages·1999·0.19 MB·English

IO-refinement in Z
Eerke Boitenand JohnDerrick
ComputingLaboratory,UniversityofKent
Canterbury,Kent,U.K.
(cid:3)
Abstract
Wepresent ageneralisationof datarefinement inZ,calledIO-refinement, thatallowschanges ininput andoutput
parametersofoperations. Severalinformalmotivationsforthedesirabilityofsucharefinementrelationaregiven,
followedbyaformalderivationthatdemonstratesitstheoreticalsoundness. ItisprovedthatIO-refinementindeed
generalizesdatarefinement. SeveraltheoremsarepresentedthatgivesufficientconditionsforIO-refinementtohold
insimplersituations,e.g.justaddinginputsandoutputs.SomeexamplesoftheuseofIO-refinementarealsogiven.
Keywords:datarefinement,Z,interfacerefinement,input/output
1 Introduction
Data refinementis a well-established techniquefor transformingformalspecificationsin an abstractdata type style
intooneswhichare perceivedto be closerto an eventualimplementation. In particular,fortheformalspecification
notationZ[16,18]rulesfordatarefinementhavebeengiven. Theserulesalsoallowfortheoperationsofanabstract
datatypetohaveinputandoutputparameters. However,theyallowonlyverylimitedchangestotheseparametersin
refinement. (Infact, mostrepresentationsofthese rulessuggestnochangeispossible atall. See foran exampleof
whatisallowedSection3.1ofthispaper.)
OurparticularinterestinZrefinementisforitsuseasasemanticsforpartialspecificationinZ,aswewillexplain
inmoredetailinSection2.1. Inbrief,acollectionof(“partial”)specificationsissatisfiedbyany(full)specification
which is a development of each of them. Traditionaldata refinementin Z comes very close to having all desirable
propertiesforsuchadevelopmentrelation.Oneproblem,however,isthatitforcesustospecifyallpossibleinputsand
outputsofeveryoperationineachpartialspecification. Thisdoesnotseemveryconvenient,andthuswehavelooked
for a generalisation of Z data refinement which allows a little more freedom in this respect. Such a generalisation
(called IO-refinement) is discussed in this paper, and we expect its relevance goes beyond providing semantics to
partialspecificationinZ.
ThenextsectionextensivelydiscussespossiblemotivationsforallowingchangeofIO-parameters,bygivingvari-
ousanswerstothequestion“WhyIO-refinement?”. Thelastoftheseisthatitispossibletogeneralisethederivation
of Z refinement given in the most authoritative account of Z refinement [18]. Section 3 contains this generalised
derivation. In subsequentsections, a definitionof IO-refinementis given,based on thisderivation. We show thatit
generalisesordinaryZrefinement.TheconditionsforIO-refinementturnouttobeverygeneral,andasaconsequence
ofthat,fairlyhardtouse. Forthisreason,wealsopresentrulesforusingIO-refinementinarestrictedwaywhichare
mucheasiertouse. Also,someexamplesofitsusearepresented.
Beforewemoveontoanswering“WhyIO-refinement?”,letusrecalltheconditionsfordatarefinementasgiven
in[16],andpresentthetraditionalZexample,sosomeoftheanswerscanrefertothat.
This work was partially funded by EPSRC under grant number GR/K13035. More information about our work can be found at
(cid:3)
http://www.cs.ukc.ac.uk/people/staff/eab2/refine/.
3rdNorthernFormalMethodsWorkshop,1998 1
IO-refinementinZ
1.1 Traditional DataRefinement: Conditions
GivenabstractdatatypesA andC ,thenCisa(forwardssimula-
tion1)datarefinementofAi=ft(hAeSretaexteis;AtsOanpsa;bAstIrnacitti)onsche=m(aCState;COps;CInit)
Abs
AState;CState
Pred
suchthatthefollowingconditionshold:
initialisation
8CState(cid:15)CInit)(9AState(cid:15)AInit^Abs)
andtheoperationsin and canbematchedinpairs bothwithinputx Xandoutputy Y,such
thatforeachofthoseApaOirpssthefoCllOowpsingtwoconditionshold: AOp;COp ?: !:
applicability shouldbedefinedonallrepresentativesof onwhich isdefined:
COp AState AOp
x X pre pre
8AState; CState; ?: (cid:15) AOp^Abs ) COp
correctness wherever is defined, should produce a result related by to one that could have
produced: AOp COp Abs AOp
x X y Y
0
8pArSetate; CState; CState ; ?: ; !: (cid:15)
0 0
AOp^COp^Abs ) 9AState (cid:15)Abs ^AOp
The abstraction schema is often given as an additional implicit parameter of the data refinement relation, and is
sometimescalledaretrieverelation;theapplicabilityconditionissometimescalledtermination. Iftheconcreteand
abstractstatespacesareidentical,thelattertwoconditionsreduceto
applicability shouldbedefinedwhenever isdefined:
COp AOp
x X pre pre
8AState; ?: (cid:15) AOp ) COp
correctness wherever isdefined, shouldproducearesultthat couldhaveproduced:
AOp COp AOp
x X y Y pre
8AState; ?: ; !: (cid:15) AOp^COp ) AOp
andwecallthisoperationrefinement.
1.2 Infamous Example
Everyarea in formalmethodshas its canonicalexamples. For Z, it is notthe factorialfunction, nor the alternating
bitprotocol. Anynew techniqueforZshouldpreferablybeillustratedwithSpivey’s example[16],
whichis BirthdayBook
[NAME;DATE]
BirthdayBook AddBirthday
known:PNAME (cid:1)BirthdayBook
birthday:NAME !7 DATE name?:NAME
dom
date?:DATE
known= birthday name
?62known
0
birthday =birthday[fname? 7! date?g
1Notallvalidrefinements canbeprovedusingforwardssimulation, inthemostgeneralcaseoneneedsinadditiontherulesforbackwards
simulation(cf.[12]). MostpresentationsofrefinementinZincludingthisoneconcentrateonforwardssimulationonly([18]beinganexception).
Wesuspecthoweverthatthesolutionmaynotlieingivingadditionalrulesforbackwardssimulation,butratherthatadefinitionofactionrefinement
inZwillencompassboth.
3rdNorthernFormalMethodsWorkshop,1998 2
IO-refinementinZ
In a section of the book called “Strengthening the specification” Spivey describes how an indication of success or
failurecanbeaddedtothis:
already-known not-known
REPORT ::= ok j j
Success AlreadyKnown
result!:REPORT (cid:4)BirthdayBook
name?:NAME
result!=ok
result!:REPORT
name
?2kanlroeawdny-known
result!=
Nowarobustversionof isgivenby:
AddBirthday
b
RAddBirthday =((AddBirthday^Success)_AlreadyKnown)
Formally, however, none of the operations described so far is a refinement of 2, so in what sense is
itstrengthened? Maybea notionofrefinementexistswhich formalisesthe“streAndgdthBenirinthg”dathyatSpiveyhadin mind
there.
2 Why IO-refinement?
Wecouldthinkof(atleast)sixpossiblereasonsforwantingorallowingrefinementofinputandoutputparametersin
Z operations. One aspectof the questioncan be rephrasedas: why wouldwe call (which
onlyaddsaconstantoutput)arefinementof ? However,someoftheaAnsdwdeBrsirinthddicaayte^tSheucpcoessssibilityor
desirabilityofIO-refinementsmuchmoreraAdidcadlBthiratnhtdhaayt–forexample,tomatchnotionsofconformanceofobject
interfaces.
AreaderwhoisalreadyconvincedoftheusefulnessofIO-refinementmaysafelyskiptherestofthissection.
2.1 The Non-conformistAnswer
Surelyit’sonlyaconvention?
We have a particular interest in alternative definitions of refinement for Z, because we wish to use Z for partial
specification (or viewpoint specification), as explained in [4, 3]. In our framework [7], the meaning of a partial
specificationisthesetofallitspossibledevelopmentsaccordingtoaparticulardevelopmentrelation–andtheobvious
developmentrelationforZis(data)refinement.Compositionoftwopartialspecifications,inthatapproach,isfinding
theirmostgeneralcommonrefinement. In[4]wehaveshownhowtogeneratealeastcommonrefinementoftwoZ
specifications with this purposein mind. This type of partial specification, however, only allows viewpointswhich
satisfythefollowingrestrictions:
1. Eachoperationineverypartialspecificationcanbeinvokedbytheenvironment,i.e.noneofthemareinternal.
(Refinementallowsweakeningofpreconditions,whichisundesirableforinternaloperations. AtZUM’97[6],
therewereatleastfourpaperswhichtoucheduponthisissue.)
2. Allpartialspecificationsareatthesamelevelofgranularity,e.g.nosingleoperationinonepartialspecification
correspondstoalargercollectionofoperationsinanother.
3. Allpartialspecificationsofoneoperationhaveexactlythesameinputsandoutputs.
2However, isarefinementof andof . Infact,duetothepreconditionsofthese
operationsbeinRgAdidsdjoBinitr,tithidsathyeirleastcommonreAfindedmBeinrtt.hday^Success AlreadyKnown
3rdNorthernFormalMethodsWorkshop,1998 3
IO-refinementinZ
Thefirstofthese restrictionsisremovedbya slightgeneralisationofZ refinement,calledweakrefinement[9]. The
second one suggests a movetowardsaction refinement. This paper aims at relaxingthe third restriction, which ap-
pearstobeorthogonaltotheothertwo. We wish toallowviewpointswhichneedonlydescribepartoftherequired
functionalityofanoperation–itseemslogicaltoapplythisprincipletoinputsandoutputsaswell,particularlyinthe
object-basedcontextsinwhichwewishtouseviewpointspecification(cf.[7]). Forexample,inasystemwhichlogs
alluserrequests,thespecificationofaparticularrequestinthe“user”viewpointshouldnothavetohavea output
–theseshouldonlyoccurinthespecificationofthatsamerequestinthe“logger”viewpoint.3 log!
Acomparableargumentcanbefoundin[11],whichdemonstratestheusefulnessofseparatinguserinterfaceand
functionalityinZ.Ourworkcanbeviewedasanaturalextensionoftheirs,inthatitstudieshowrefinementcombines
withthisseparation.
ClearlyonewayoutforuswouldbetoleaveZrefinementforwhatitis,anddefinea“new”refinementrelationfor
Zfromscratch. Itmightsolveourproblem,butwethinkitwouldbemuchmoreprofitabletostayascloseaspossible
togenerallyacceptedapproaches.Fortunately,aswillbemadeclearlater,thisposesnoseriousproblems.
2.2 The InformalAnswer
Addingaconstantoutputshouldn’thurt,shouldit?
From the perspective of “information content”, there is no differenceat all between observing that a particular op-
erationoccurs, andobservingthatitoccurswith a particularoutputwhichis knownalwaysto havethesame value.
Thisseemssimilartogivinganoperationadifferentname–whichisallowedinZdatarefinement. Also,onemight
wonderwhetherthenameofanoutputshouldhaverelevanceinZrefinement–inmostlanguagesoutputsdonothave
names,onlytypes.AnotherbranchofourresearchisconcernedwithrelatingspecificationsinZwithspecificationsin
otherformalnotations.Forsomeofthese,e.g.LOTOS[8]wehaveindeedneededtoadopttheconventionthatnames
ofoutputs(andinputs)areirrelevantinZ.
Theargumentherewillbecontinuedinamoreformalwayinotheranswers.“Thereisnodifferenceatall”would
suggestmorethanjustrefinement–itsuggestsequivalence,forexampleinthesenseofrefinementinbothdirections.
Notethatherewetalkabout“observing”anoperationhappening–thisisfullyinaccordancewiththemodelusedin
[18]toderiveZrefinement,whichwewillalsobeusinglatertoderiveamoregeneralrefinementrelation.
2.3 The Perspective ofOperationInterfaces
Ifnooneislookingat ,thereisnodifference.
result!
The standard Z view of refinement (simulation) between abstract data types is that the environment observes the
occurrenceofoperations,andforeachofthose,allitsinputsandoutputswiththeirnamesandtypes.Asaconsequence
ofthis,thetypesofinputandoutputparametersmaynotbechanged4,thoughtherefinementconditionsdoallowtheir
declarationstochange5.
Lookingat these restrictions from the perspectivesof operation interfaces and object-orientedstyle typing, this
allseemsmorerestrictivethannecessary. We would, likein interfacedefinitionlanguages,anoperation’sinterface,
viewedasatype,tobesatisfiedbyoperationswhoseinterfacesaresubtypesofthattype:takinginputsandoutputsfrom
extendedsets;addinginputsandoutputs(bygeneralisingimaginedconstantinputsandoutputstovariableones). The
typesystemofZ(beingessentiallyflat)isnotwellsuitedfordefiningsubtypingdirectly. Wewillinstead(implicitly)
3Onemightpointoutthatthiscouldberesolvedbyhavingthelogasastatevariableintheloggerviewpointonly,whichiscorrect. However,
suchaquasi-solution illustrates exactly thepointwewishtomake: Zrefinementallows near-unlimited change ofstatevariables, andnoneof
input/outputvariables.
4Strictlyspeaking,inthisinterpretationthenamesofoperationsshouldnotbechangedinrefinementeither.However,givingthe“concrete”and
“abstract”operationsdifferentnamessolvestheproblemofdeterminingwhich“version”theoperationname(e.g.inarefinementproofobligation)
refersto.AsomewhatcleanerapproachtothisistakeninB[1],whereoperationnamesareexplicitlyrequiredtobethesameafterrefinement,but
theretheproofobligationsneedtorefertomoreconstituentsoftheoperationdefinitionthantheonesforZ.
5Thisisanobviousconsequencefromthepossibilitytomoveinformationbetweendeclarationsandpredicatesofaschema. Thesetstheinput
andoutputparametersaretakenfrommaybeextendedtoanylargersetlyingwithinthesametype,orrestrictedtoanysubsetcontainingallvalues
actuallyallowedbytheoperation.
3rdNorthernFormalMethodsWorkshop,1998 4
IO-refinementinZ
define subtyping as the existence of functions with particular properties that relate the types. The conditions that
emergeforinputsandoutputsaredifferent,asonemighthaveexpectedfromissuesofcovarianceandcontravariance
infunctionsubtyping.
Intheresearchareaofobject-orientedlanguages,theneedforinterfacerefinementhasindeedbeenacknowledged.
The most striking example of this is the work of Mikhajlovaand Sekerinski [14] on class refinement and interface
refinement,whichindependentlyofourworkcomesupwithverysimilarrulesandconditionsforalterationofinputs
andoutputsinrefinement.
2.4 A Schema Calculus Answer
Schemaconjunctiongenerallyprecludesrefinement–butthroughapplicability,notthroughcorrectness.
It is well known in the Z community that the interplay between refinement and the schema calculus is not always
smooth. The conjunctionof two operations, for example, may not be a refinementof either even when a common
refinementofthetwoexists[4]. Conversely,thedisjunctionoftwooperationsisonlytheleastcommonrefinementof
bothiftheirsignaturesareidenticalandtheyareidenticalwheretheirpreconditionsoverlap(e.g.whentheprecondi-
tionsareexclusive[2],likefor and above). Amorepositiveresultisthe
following. AlreadyKnown AddBirthday^Success
Theorem1 Theoperation b P isanoperationrefinementof if
COp=(AOp^ ) AOp
1. hasthesamesignatureas ,i.e.Pdoesnotrefertovariablesnotin ;
COp AOp AOp
2. pre pre ,i.e.Pdoesnothavetheeffectofexcludingbefore-valuesthat allowed.
COp= AOp AOp
Proof Thecorrectnessconditionisautomaticallyguaranteedbythesecondcondition. Thesecondconditionabove
is onlya formalstrengtheningof theapplicabilitycondition,since pre P pre followsfromthefirst
condition. (AOp^ ) ) AOp
2
Ofthetwoconditionsoftheabovetheorem,surelythesecondoneshouldbeconsideredthemajorone. Nowlookat
and ...Theirpreconditionsareequal,sotheyonlyfailtobeintherefinement
rAedladtBionirbthecdaauyseofAthdedfiBrsitr,tmhdinaoyr^sSynutcaccetiscsal,condition. Clearlyfromthisperspectiveremovingthatcondition,and
thusputtingtheseoperationsinarefinementrelation,wouldnotbeveryrevolutionary.
This line of reasoning, however, will not be pursued much further in the rest of this paper, because even if we
managetoovercometheproblemdescribedabove,itstillseemsimpossibletocompletelyremoveallproblemsbetween
schemacalculusandrefinement.
2.5 A Mathematical Answer
A 11 A
(cid:2) (cid:24)=
Contrarytowhatwassuggestedbythepreviousanswer,inmovingfrom to ,
“conjunction”is really irrelevant, being only a consequenceof Z’s syntacAtidcdaBl ciortnhvdenatyionsA.dCdoBnisridtherdathye^fSoullcocweisnsg
tautologiesonsets(inmathematics,notinZ):
A x x A B y y B
=f j 2 g =f j 2 g
Nowcombinethesesetcomprehensionsinaparticularsyntacticway,byconcatenatingtheirdeclarationsandtaking
theconjunctionoftheirpredicates:
xy x A y B
f ; j 2 ^ 2 g
3rdNorthernFormalMethodsWorkshop,1998 5
IO-refinementinZ
Now would we call the resulting set A B ? Of course not – what is being constructed is a product set. The same
goesfor –ma^ybewe shouldsaythatitisunfortunatethatproductschemasinZappearas
conjunctiAondsd6B,biercthaudsaeyp^rSoduuccctessassaconceptaretooimportanttobelumpedinwithconjunctions.
Once we have established that denotes a product schema, let us consider its factors.
is peculiar, in that it has oAndlydBonirethpodsasyib^lSeuinchcaebssitant. Viewed as a set of bindings, it is a singleton set.
OSuneccneostsionofequivalenceinatheoryofproductsisthatofisomorphism,andtheproductofasetAwithasingleton
set is isomorphic to A. (This formalises the argument given in the “informal” answer.) There is another pair of
isomorphictypesinvolvedintheseschemas. Considerthetypeofalloutputsof –therearenone. One
way of modelling a value from an empty producttype is by defining it to be tAheddanBoinrytmhdoauysunique value * of the
predefinedtype11. Theoutputsignatureof is itself,andtheproductofthesetwooutputsignatures
isisomorphic(ifnotequal!)to ,anSduiscocmesosrphiScutocc11es.s
IsomorphismsbetweenstateSsucchceemssasinZinducedatarefinementsinbothdirections. Isn’titstrangethatisomor-
phismsbetweeninput-oroutputtypesdonot?
Asaresponsetothisquestionweexpecttohear“inputsandoutputsareobserved,whereasstatesarenot”. This
isanacceptableanswerwithincertainlimits,aswillbeexplainedinSection3.1. However,takingadifferentviewon
thisintroducesnoinconsistenciesornewanomalies.
“Isomorphism” again suggests IO-refinement in both directions. It is clear that less stringent conditions will
sufficeforhavingIO-refinementinonedirectiononly. Suchconditionswillemergefromthederivationgiveninthe
nextsection.
Finally,wewouldliketopointoutthesimilaritybetweenthisissueandthegeneralisationorembeddingstrategy
inprogramtransformation[15](orindeedinproofsingeneral):inputtypescanbeextendedbygeneralisingconstants
tovariables;outputtypescanbegeneralisedaslongastheoriginallyrequiredoutputcanbereconstructedfromit.
2.6 A Methodical Answer
Wecanderiveit,soitmustbeokay.
Woodcock and Davies [18] motivate the Z data refinement conditions by deriving them from a characterisation of
simulationsbetweenabstractdatatypes,modelledasbinaryrelations. Usingexactlythesamesetup,bygeneralising
identityfunctionstomoregeneralfunctionsintheirderivation,wemanagedtoobtainconditionsforageneralisedtype
ofrefinement,whichwecallIO-refinement.Thisinvolvesonlyaverymarginalrelaxationinthe“rulesofthegame”,
verysimilartotheimplicationsofhavinginitialisationsobservable.
Of course, a formalderivation, howeverreassuring, on its own means nothing. However, the generalisation we
chooseistheobviousonegivenWoodcockandDavies’derivation(replacingexplicitoccurrencesofidentityfunctions
by more general functions), and the resulting refinement relation encompasses all the relaxations suggested by the
answersabove,andpossiblyquiteafewmore.
Stepney,CooperandWoodcockinrecentwork[17]havealsoobservedthatmorepowerfulrulesthanthestandard
rulesforZcanbederivedfromthebinaryrelationcharacterisation.
3 A Derivation of the Conditions for IO-refinement
InthissectionwewillderiveconditionsforIO-refinementinaderivationthatgeneralisesthederivationofrefinement
fromsimulationin [18, pages254-255]. In orderto appreciatethe subtleties ofIO-refinement,we first needto dis-
cuss the issue of unwinding– transforminga system where allinputoccursat initialisation and alloutputoccursat
finalisationintoonewhereeveryoperationcanhaveinputoroutput.
3.1 Unwinding: the Relationbetween InitialisationsandInput
ThecanonicaltheoryofsimulationsonwhichthenotionofrefinementinZisbased[12,13]isoneofbinaryrelations.
A“run”ofthesystemconsistsofthreeparts:aninitialisation,asequenceofoperations,andafinalisation.Ifthestate
6Thereisastronganalogyherewithproductsinrelational(database)algebraappearingasnaturaljoins.
3rdNorthernFormalMethodsWorkshop,1998 6
IO-refinementinZ
space of the environmentis G andthe state space of the system isS, then initialisation is a relationbetween G and
S;everyoperationisarelationonS;andthefinalisationisarelationbetweenSandG. Asin[18],letusconcentrate
onasystemwhichhasonlyoneoperation–multipleoperations,eachwiththeirowninput/outputtypes,wouldmake
everythingthatfollowsunnecessarilycomplicated.Thissimplificationhastheadditionalconsequencethat,apartfrom
the initialisation condition for data refinement(which is unaffectedby our modified derivation), IO-refinementis a
conditiononasinglepairofoperations.WewillsometimessaythatanoperationIO-refinesanotheronewhenstrictly
speakingwearetalkingaboutthesystems,eachconsistingofoneoperationandtheimpliedstate,refiningeachother.
Thefirstpartofthederivationin[18](“relaxing”)resultsinconditionsfordatarefinementofasystemasdescribed
above,i.e.onewithnoindividualinputsoroutputsforeveryoperation. Theseconditionsaretherelationalversions
of the correctness and applicability conditions given in Section 1.1. For a relation to refine a relation given
abstractionrelationr: co ao
dom r r (2)
o o
( ao)C( 9co) (cid:18) ao9
ran dom r dom (3)
( ao C ) (cid:18) co
Aparticularclassofsuchsystemsisinterpretedasmodellingasystemwithinputsandoutputsforeveryoperation,
namely ones where the following is the case. The state contains two sequences, an input sequence and an output
sequence. Initially,theoutputsequenceisempty;inthefinalstate,theinputsequenceisempty. Everytimean(the)
operationisexecuted,thefirstvalueisremovedfromtheinputsequence,andavalueisaddedtotheendoftheoutput
sequence.Theoutcomeoftheoperationdoesnot(directly)dependonanyothervalueintheinputoroutputsequence.
Example4 Thesystem(callitA)
xSState Init Op
0
: State (cid:1)y SAtate
x a
0 ?:
= p
(it has no outputs, to simplify the presentation) is modelled by the system (let us call it A ) where all inputs are
(cid:3)
providedatinitialisationtime,whichis
xSState Init Op
0
: seqA State (cid:1)State
x a p y
inps: 0
= [hdinps= ?]
0
inps =tlinps
2
Thedescriptionat the levelof binaryrelationsof this constructionuses a numberof auxiliaryfunctionsdefined
below, which willalso be used in ourmodifiedderivation. removesoneinputfromthe inputsequence; is a
kindofparallelcomposition; addsanoutputtotheoustppluittsequence. k
merge
ABC
[ ; ; A] seq B seqC A B seqB seqC
split: (cid:2)( 1 (cid:2) ) ! ( (cid:2) )(cid:2)( (cid:2) )
sA seq B seqC
8 : ; iss: 1 ; oss: (cid:15)
split( ;(is;os))=(( ;headis);(tailis;os))
W X Y Z
[ ; ;W; ] Y X Z W X Y Z
k :( $ )(cid:2)( $ ) ! (cid:2) $ (cid:2)
W Y X Z wW xX yY zZ
8(cid:26)w: x $ y;z(cid:27): $ ; :w ; y: ; : x; : z(cid:15)
( ; )7!( ; ) 2 (cid:26)k(cid:27) , 7! 2 (cid:26)^ 7! 2 (cid:27)
3rdNorthernFormalMethodsWorkshop,1998 7
IO-refinementinZ
ABC
[ ; ; ] A C seqB seqC A seqB seqC
merge:( (cid:2) )(cid:2)( (cid:2) ) ! (cid:2)( (cid:2) )
sA oC seqB seqC
8 : ; : ; is: ; os: (cid:15)
so s o
a
merge(( ; );(is;os))=( ;(is;os h i))
Usingtheseoperations,therelationbetweenanoperation inasystemwithIOanditscounterpart inasystem
s
withoutIOis op op
s o o
op =split9(opkid)9merge
where the identity relation ensures that the rest of the input and output sequence are unaffected in the current
operation. id
Thesecondpartofthederivationthentranslatestherefinementconditionsbetween and (substitutingthese
s s
for and in(2)and(3))intoconditionsbetween and ,usingasaretrieverelatiaoononthceoextendedstate
ao co ao co
r r seq seq (5)
s
= kid[ Inp]kid[ Outp]
where and are the types of the input and output of . The conditions that result, when translated to
conditioInnsponZsOchuetmpas,arethosegiveninSection1.1. op
Note, however,that there is a small problemwith representinga system with inputin the way describedabove.
(This is not observed in [18], but solved by the more general rules in [17].) It is best illustrated by means of an
example.
Example6 Continuing from Example 4, assume that A, the set from which the input parameter y is taken is
properlycontainedinanothersetB. Clearlythefirstsystemcanberefinedbyreplacingthedeclarationof?y in by
y B,andletuscallthissystemB.NowB isequaltoA ,exceptforthedeclarationof , whichisno?woOfptype
(cid:3) (cid:3)
se?q:B. However,B failstobeaforwardsimulationrefinementof A ! Considertheconditiinopns
(cid:3) (cid:3)
0 0 0
8CState (cid:15)CInit)9Astate (cid:15)AInit^Abs
whichinthisparticularcase(abstractionrelationisinjectionofabstractstatespaceintotheconcreteone)translatesto
x S seqB x a seqAwhichisfalseforAbeingapropersubsetofB
0 0 0 0
2
8 : ; inps : (cid:15) = ) inps 2 :
Conclusion:after“unwinding”,refinementsareallowedthatwerenotallowedbefore.
Therelevanceofthisproblemisasfollows.Whenusinginput-refinement,theinitialisationconditionfor“allinput
at initialisation” translates to: for everyconcrete input, there is an abstract inputwhich is linked to it by the input-
transformer. Thisimpliesthatnewinputsmayfreelybeadded,butthatnoinputmayhaveitstypeextended. Thisis
clearlyundesirablegivenourmotivations,buttheissueneedstoberesolvedfor“standard”Zrefinementaswell.
Ofcoursetheproblemis inviewingtheinitialisationsasindependent. Forthe“inputasinitialisation”notion,it
is importantto realise that the inputs are providedby the environment. In the originalrelationalrefinementset-up,
initialisationandfinalisationarefunctionsfrom-andtotheenvironment,respectively.Inotherwords,afairmodelof
A wouldhaveasitsinitialisation:
(cid:3)
Init
0
State seqA
inps?:
x a
0
=
0
inps =inps?
suchthat,withappropriatelymodifiedrefinementrulesforinitialisationswithinputs,A wouldstillberefinedbyB .
(cid:3) (cid:3)
Thisconstructionsolvestheparadoxinherentin[18]–inthefollowingderivationweassumethatasimilarconstruction
canalsobegiventodischargetheundesirableconditionforIO-refinementderivingfromtheinitialisationcondition.
[17]presentsasolutionwhichisessentiallysimilar,byalwayskeepingareferencetotheglobalenvironmentGinthe
refinementrules.
3rdNorthernFormalMethodsWorkshop,1998 8
IO-refinementinZ
3.2 The Derivation
Inthissectionweparaphrasethesecondpartofthederivationin[18],allowingforaneasycomparisonbetweenthe
two. The crucialstep lies in generalising the identity functionsin (5) to arbitrarymaps. We will use the following
relationalgeneralisationof“map”:
AB
[ ; A] B seqA seqB
(cid:3)
:( $ )!( $ )
A B seqA seqB
8(cid:26): $ ; as: ; bs: (cid:15)i dom i i
(cid:3)
(as;bs) 2 (cid:26) , #as=#bs^ 8 : as(cid:15)(as ;bs )2(cid:26)
Thestartingpointofourderivationistheassumptionthatwehaverefinementrulesforaparticularrelationbetween
concreteandabstractstatesforasetofoperationsthathavenoinputsoroutputs. Ifwewanttoderivesimilarcondi-
tionsforoperationsthatdohaveinputsandoutputs, we needto applythe standardmethod: thestate containsextra
componentsrepresentingthesequenceofinputsstilltobedealtwithandthesequenceofoutputsalreadycomputed.
Assume we wish to compare operations and which consume input and produce output. Their equivalent
operationsthatexpectinputandoutputsequenacoesarecgoivenby
s o o
ao =split9(aokid)9merge
and similarly for . Given a relation r between states without input and output sequences, we must construct an
s
equivalentrelationcothatactsontheenhancedformofthestate. Ifrisarelationoftype
AState$CState
thenwerequirearelationr oftype
s
seq seq seq seq
AState(cid:2)( AInp (cid:2) AOutp) $ CState(cid:2)( CInp (cid:2) COutp)
inordertocompare and . Forthecomparisontomakesense,thetwooperationsshouldhavelistsofoutputsand
s s
inputsthatareequalalyolong.cMo oreover,therelationbetweeninputandoutputsequencesshouldbebetweenelements
incomparablepositionsonly. Nottoassumethatwouldimplythesystemcheatedinsomeway–bymakinguseof
“future”inputor“past”output,forexample. Iftherelationbetweenindividualinputelementsis andthatbetween
individualoutputelementsis ,therelationr betweenenhancedstatesisthendefinedby: it
s
ot
r r
s (cid:3) (cid:3)
=( kit kot )
Forr nottoexcludecombinationsofstatesinr,weneedtorequirethat and aretotalontheabstractinputand
s
outputtypes.(Thisconditionisformallyalittletoostrict–itrulesoutinpuittandoouttputtransformerswhichreducethe
inputandoutputtypestothevaluesthatcanactuallyoccur. However,thiscanstillbedoneasoperationrefinement,
usingjustpredicates.)
Therulesforthecorrectnessofaforwardssimulationrequirethat
dom r r
s so s so s
( ao )C( 9co ) (cid:18) ao 9
whichrequirementisequivalentto
dom r r
o o
( ao)C(( kit)9co) (cid:18) ao9( kot)
Theotherrequirement,that isdefinedeverywherethat isdefined,leadstoasecondconstraint7:
s s
co ao
ran dom r dom
(( ao)C( kit)) (cid:18) co
7[18]has inthecorrespondingcondition–itshouldbe .
id[Output] id[Input]
3rdNorthernFormalMethodsWorkshop,1998 9
IO-refinementinZ
Thefirstderivationin[18]alsocontainsaninitialisationconditionthatneedstoholdbetweentheinitialisationsof
thetwosystemsinvolved,whichisclaimedtobeindependentfromthe“unwinding”constructionandthusdoesnot
changeforthesecondderivation.Thisisnotstrictlytrue,asdemonstratedabove.Similarly,thisconditionwouldhave
its effecton our modifiedversionof unwinding. The resulting conditionwould be that foreveryconcrete input, an
abstractinputexists. (ComparewiththesituationinExample6.)
Inaddition,afinalisationconditionexistsforasimulationtoholdbetweentwosystemswithnoinputsoroutputs.
ThisconditionbecomesmootinWoodcockandDavies’unwinding,butinourmodifiedapproachithasanimportant
consequence:
o (cid:24)
(ot 9 ot )(cid:18)id[AOutp]
whichistosay, needstobeinjective. Thisconditionguaranteesthatdifferentabstract(“original”)outputscanbe
distinguishedinothteconcretecasesbecausetheirconcreterepresentationswillbedifferentaswell.
Thenextsection will define the analoguesof the retrieverelation forchanginginputsand outputsin refinement
steps,calledIO-transformers,andsomeothernotationsusefulforexpressingtheIO-refinementrulesattheZschema
level.
4 IO-transformers
Forconvenience,wefirstdefinethenotionofasignature.
Definition7(Signatures) ForaschemaS,itssignature Sanditsinputandoutputsignatures Sand Saregiven
by (cid:6) ? !
S S S
(cid:6) = _ :
S “allcomponentsofSwhosenamesdon’tendin!” S
! =(cid:6)(9 (cid:15) )
S “allcomponentsofSwhosenamesdon’tendin?” S
2
? =(cid:6)(9 (cid:15) )
By definition of schema negation, a signature schema has all componentsdeclared as being from their type (rather
thanasubsetofit)andaneverywheretruepredicate(whichweusuallyforgetabout). IfShasnoinputs, Sturnsout
tobe true,theschemawhoseonlyinhabitantistheemptybinding(similarlyfor SifShasnooutputs.)T?hisschema
plays[ther]oleoftheunittype11mentionedinSection2.5. !
Thefollowingoperationsonnames,whichextendcomponentwisetosignatures(similarlytothestandardconven-
tionfordecorations)aredefined.
Definition8(Decorationsforinputandoutput) Forallx,x x;x x .
2
?= ! != ?
(Theoverlineoperatorischosenin analogywith CCS - in pipingcommunicationwhentheyare bothpresentin the
rightdirection,xandxbecomehidden.)
Wewillneedtochangeinputsandoutputsofoperationschemaswithout(directly)affectingtheirchangesonthe
state. For that purposewe will use schemaswhich contain inputsand outputsonly, which will be connectedto the
operationsusingpiping . HayesandSanders[11]usepipinginmuchthesameway: torepresenttheequivalentof
relationalcompositionfo(cid:29)rinputsandoutputsinZschemas. Theyusetheterm“representationschema”forwhatwe
call“transformers”.
An input transformerfor a schema is an operation whose outputs exactly match the schema’s inputs, and whose
signatureismadeupofinput-andoutputcomponentsonly;similarlyforoutputtransformers.
3rdNorthernFormalMethodsWorkshop,1998 10