VIP: A Visual Editor and Compiler for
v-Promela
?
MoatazKamel 1
andStefanLeue 2
1
DepartmentofElectricalandComputerEngineering
UniversityofWaterloo
Waterloo,OntarioN2L3G1, Canada
m2kamel@uwaterloo.ca
http://fee.uwaterloo.ca/~m2k amel
2
InstitutfurInformatik
Albert-Ludwigs-UniversitatFreiburg
D-79110Freiburg,Germany
http://www.informatik.uni-freib urg. de/~l eue
leue@informatik.uni-freiburg. de
Abstract. We describe the Visual Interface to Promela (VIP) tool
thatwehaverecentlyimplemented.VIPsupportsthevisualeditingand
maintenanceofv-Promelamodels.v-Promelaisavisual,object-oriented
extensiontoPromela, theinput languageto theSpin modelchecker.
Weintroducethe v-Promelanotationas supportedbythe VIPeditor,
discussPromelacodegeneration,anddescribetheprocessofproperty
validation for the resulting models.Our discussioncenters around two
casestudies,acallprocessing systemandtheCORBAGIOPprotocol.
1 Introduction
AsDavisarguesin [2],asignicantreturnofinvestmentcanbeexpectedwhen
investingresourcesintotheearlystagesofthesoftwaredesigncycle:inparticular,
xing design aws at the requirements stage can be 200 times less expensive
thanxingthematthemaintenancestage.Evencorrectionsatthearchitectural
designstagecanbe50timesmorecosteÆcientthanatthemaintenancestage.
The inherent complexity of concurrent real-time systems makes it necessary
to employ mechanized,formally supported methods to analyzeearly life-cycle
artifacts. In this context the main questions to be answered are whether the
requirementsareconsistentandcorrectwiththeintendedbehaviorofthesystem,
andwhether thesystem'sdesigncorrectlyimplementstherequirements.
Ithasbeenshownthatstate-basedmodelingandautomaticmodelchecking
isaneectivetoolforansweringthesequestionsforconcurrentreactivesystems.
Recent advances in model checking research have made verication based on
?
Theworkdocumentedinthispaperwaslargelyperformedwhile thesecondauthor
waswiththeUniversityofWaterloo.Weare currentlyworkingonapublicrelease
versionoftheVIPtool,interestedpartiesarerequestedtocontacttheauthors.
First. publ. in: Lecture notes in computer science, No. 1785 (2000) , pp. 471-486
Konstanzer Online-Publikations-System (KOPS) URL: http://www.ub.uni-konstanz.de/kops/volltexte/2008/6195/
URN: http://nbn-resolving.de/urn:nbn:de:bsz:352-opus-61954
ever,theintroductionof formalmethods in thesoftwareengineeringprocess is
oftenhamperedbytextualinterfacesladenwithmathematicalnotations.Visual
formalisms,ontheotherhand,appeartoenjoybroadacceptanceinengineering
practice.
Withtheeverincreasingcomplexityofconcurrent,reactivesystemsthatcon-
tinuetobedesigned,therequirementsandhigh-leveldesignmodelsarebecom-
ing sizeable artifacts themselves. In order to facilitate themodel development
process, we propose the alignment of the modeling language of a state-of-the
art formalanalysis toolwith thestateoftheart visual,object-orientedhierar-
chical notations used in current softwaredevelopment.This has the benet of
fostering maintainability and evolvability of these models while increasing the
chances thatthemodelsactuallyexpresstheintentionsofthedesignersandin-
creasingtheacceptanceofformalanalysis inthepracticalsoftwareengineering
community.
In this paperwe present the prototype of agraphical user interface-based
toolcalledtheVisualInterfacefor Promela(VIP)thatwehavedeveloped.VIP
supports a visual language called v-Promela which is the graphical extension
of Promela, theinputlanguageforthemodel checkerSpin[8]. Thetoolpro-
videsgraphicaleditingcapabilitiesforv-Promelamodelsandgeneratesstandard
Promelacode from thegraphicalrepresentation. Inthe process ofdescribing
VIPwealsoshowhowmodelingofcomplexreal-timesystemsforthepurposeof
formalanalysiscanbebasedonastate-of-theartvisualobject-orientednotation,
andthat eÆcienttoolsupportcanbeprovided.
RelatedWork. VIPsupports visualmodelingusing v-Promela.Thev-Promela
notation hasrst beendescribed in [13] and[5]. The designof v-Promelawas
guidedbyanumberofdesiderata.First,wedesiredtousePromela/Spinval-
idation technology without any changes to the existing model checker.Hence
everyfeatureofv-PromelahadtobecompilableintoPromela.Next,wewerein-
terestedinavisualnotationthatwouldcapturebothstructuralandbehavioral
modeling aspects. We were also interested in providing hierarchical modeling
and object-oriented concepts. Finally, wehaveattempted to comply asfar as
possible with existing oremerging software design methodology standards for
concurrentreal-timesystems.As aconsequence,thev-Promela notationinher-
itedlargelyfromtheUML-RTnotation[16].UML-RT, whichevolvedfromthe
ROOMnotation [15],is supported byan industrial-strengthcasetool(ROSE-
RT)andisexpectedtobeaprominentplayerin thereal-time systemsdomain
in comingyears. Someofthe syntacticas wellas someofthesemanticaspects
ofUML-RTare notcompletely speciedat thistime. Theauthors ofUML-RT
suggest that these missing aspects can be derived from the denitions of the
syntax and semanticsof ROOMas givenin [15].Thedevelopment of theVIP
toolisdescribedin moredetailin [10]which alsodiscussessomemodications
tool,andweillustratetheuseofVIPinSection3throughanexample.InSection
4wediscussthev-Promelacompilerimplementedin VIP.InSection5weshow
howto performproperty validation in thecontext of ourapproach. Finally,in
Section6wediscussfurtherissuesrelatedtotheimplementationofVIP,andwe
concludeinSection7.
2 VIP Architecture
Tosupporttheeditingandmaintenanceofv-Promelamodelswehavedeveloped
the VIP(Visual Interface to Promela)tool. Figure 1illustrates the functional
architectureofVIP.Wewill describethefunctionalityoftheVIPeditorin the
followingsection.Theeditedv-PromelamodelsarecompiledintoPromelacode
byVIP,andtheresultingPromelamodelscanbe validatedbytheSpinmodel
checker.Spinerrortracescanthenbere-interpretedinthecontextoftheoriginal
v-Promelamodel.Currently,there-interpretationhastobedonemanually.To
store v-Promelamodels, wecurrently use JAVA class serialization. Theuse of
this feature ofthe JAVA DevelopmentToolkitsavedconsiderabledevelopment
time, however, to allow better future expandability we are currently working
onimplementingstorageandretrievalfunctionalitybasedonXML [17]schema
denitions andanXMLparser.
00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000
11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111 11111111111111111111
Promela results, trails Spin
properties models, existing
VIP (editor, compiler) classes
JAVA serialized
compiled Promela
XML schema
Fig.1.VIPtoolarchitecture.
Fig.2.POTSModeleditor.
3 Modeling in VIP
InthisSectionwedescribethemainfeaturesoftheVIPgraphicaluserinterface.
AsarunningexampleweuseasimpliedPlain OldTelephony System(POTS)
PhoneHandlerprocesses containedin theenvironmentof the POTS system.
TheUserprocessesrepresentthebehaviorofthetelephoneswhichcommunicate
withPhoneHandlerprocesseswhichrepresentthecallprocessingsoftwareinside
theswitch.ThePhoneHandlerprocessesareresponsibleforrespondingtoevents
fromtheUserprocessesaswellascommunicatingwithotherPhoneHandlersin
orderto establishavoiceconnection.
3.1 Structural Modeling
Model Editor. The Model Editor is the starting point for creating v-Promela
models. It allows the user to dene the basic elements of a v-Promela model:
capsule classes, protocol classes, and data classes. From the model editor the
usercan openeditorsforeachoneoftheabovementionedbasicelements.From
the model editor, the usercan also save themodel orgenerate Promelacode.
Figure 2 illustrates the model editor for the POTS example. It species three
capsuleclasses,three protocolclasses,andadataclass.
Fig.3. PhoneHandler cap-
sulestructure.
Fig.4.StructureofPOTSsystem.
StructureEditor TheStructureEditordisplaystheinternalstructureofachosen
capsuleclassusingthev-Promelagraphicalnotation.Thestructuremayconsist
ofothercapsuleinstances,buers,synchronizers,ports,andconnectors.Changes
to the structure ofthe capsuleclass are automatically reectedin otherviews
that containaninstanceofthecapsuleclass.
Figure4representsthePOTSsystemstructure.Concurrentobjectsarecalled
capsules in accordancewith theUML-RTterminology.ThePOTS systemcon-
sistsofahigh-levelcapsuleclasscalledPOTS.Itisdecomposedintofourcontained
1
InordertoobtainmodelsthatcanbetranslatedintoPromelaallv-Promelamodels
mustbe closedsystems.Therefore,the environmentbehaviormustbe modeledas
capsuleclassesisfurtherrened.However,Figure3illustratestheinternalstruc-
ture denition of the PhoneHandlercapsule class. The black and white boxes
at theborderof thecapsuledenotein andoutboundports,respectively.Ports
representmessagepassinginterfacesforcapsules.Incontrasttov-Promelawhere
portsareeitheruni-orbi-directional,allportsinVIPareuni-directional.Incor-
poratingbi-directionalportsintoVIPispartoffuture improvementswhichare
in-progress.Thetypeofaportisaprotocol class,seebelowforadiscussionof
theirdenition.Portsneed tobeconnectedto ports in othercapsuleinstances
toenablemessagestobeexchanged.Connectors,asindicatedbythelabeledar-
rowsinFigure4,areusedtoestablishconnectionsbetweenports.Theconnector
labelshowsthenameoftheconnectorandthemessagebueringcapacityofthe
connectorwithinbrackets.Onlyportsofidenticaltypecanbeconnected,anda
connectormustjoin anout-porttoanin-port.
Acapsuleinstance can haveanassociatedreplicationfactor that isgreater
or equal to 1. Thereplication factorspecies the numberof capsule instances
that will be generated at instantiation time. Forsimplicity of presentation all
capsuleinstancesinthePOTSexamplehaveareplicationfactorof1.
Fig.5.ProtocolclassdenitionforPOTSmodel.
Protocol Classes. A Protocol class consists of a name and a list of message
classes.Eachmessageclasshasanamewhichidentiesthemessagetypeandan
associated messagebody type.Figure 5illustrates theprotocol class denition
forthePOTSexample.Thenamesoftheprotocolclassesaswellasthemessage
classnamesareindicativeofsignalspassedinatelephoneswitch.
Data Classes. Figure 6 illustrates the denition of data classes in VIP based
on the available Promela data types. If a data class is mapped onto a basic
Promeladata type it merelyservesas analias for that type.However,a data
class denition canalso take advantageof the typedef construct in Promela.
Figure 6showsthedenition ofthedata classsubscribernumberasarecord
consistingofashort integereldareacodeandanintegereldphonenumber.
ComparedtothedatatypecapabilitiesoflanguageslikeUML-RTthev-Promela
exhaustive model-checking by Spin. The right side of Figure 6 shows how a
data class denition is used to dene a message body type. The dialdigit
messageof theUserToSwitchprotocolis dened tohaveamessagebody type
ofsubscribernumber.
Fig.7.Dataobjectdenition.
Fig.8.Deningportsbased
onprotocolclassdenitions.
Data Objects. Data objects are instances of data classes that can be used in
expressions.Theyaredenedasattributesofcapsuleclasses.Figure7illustrates
the denition of adata object phnumberwithin the Usercapsule class asan
instanceofthesubscribernumberdataclass.Adataobjectmayalsobedened
to beanarray.
BuersandSynchronizers. UML-RTisveryrigidinthewaythatitallowsinter-
processcommunicationtohappen.Communicationbetweenprocessestakesplace
exclusively through point-to-point message exchanges via ports. In contrast,
Promela allows arbitrary sets of processes to share channels or to synchro-
nize via rendez-vous channels. In order to permit the more general modeling
approach that Promela makes possible, v-Promela introduces the concepts of
consumerproblemsaswellassemaphores.
3.2 BehaviorModeling
Behaviorin v-Promelaismodeled usinghierarchical,communicatingextended
nitestatemachines.
Hierarchical State-Machines. Thebehavioreditorin VIPallowsforeditingthe
statemachine associatedwith acapsuleclass. Inthe POTSexample, onlythe
UserandPhoneHandlercapsules havestatemachinesassociatedwiththem, as
illustratedin Figures9and10.Thetop-levelstateofanystatemachinehasthe
name TOP. To illustrate the hierarchical nature of state machines in VIP, the
renementoftheawaitdigitstateofFigure9isshowninFigure10.Itshould
benotedthatinthecurrentimplementationofVIPweconsidertwostateswith
identicalnamelabelstodenotedierentstates.Weusevariousiconsinsidethe
statesymbolstoexpressattributesofthestates.Asanexample,thecircleinthe
lowerleftcorneroftheidlestateinFigure9indicatesthat thisstatehasbeen
marked as a valid end state, and the icons in the awaitdigitstate indicate
that thisstatehasarenementandthatentrycodehasbeendenedforit.
CircledX andE symbolsindicate exit andentrypointsfor multi-leveltran-
sitions, respectively. Typical for the use of hierarchical state machines is the
occurrenceofchainedand grouptransitions. Forinstance, ifthePhoneHandler
capsuleis in any statecontained within the awaitdigit statethis state may
beexitedifthetransitionlabeledonhook initssuperstateexecutes.v-Promela
andVIPallowforexplicitreturnorreturntohistorysemanticsforhierarchical
statemachines.If anentrypointisnotconnectedto acontainedstate,there-
turnto historysemanticswill bechosenintheeventofanincomingtransition.
Otherwise,theexplicitreturntoacontainedstateisindicatedbyanarrowfrom
theentrypointtothecontainedtargetstate.
Fig.9.PhoneHandlerTOPstate.
Fig.10. PhoneHandler TOP:awaitdigit
state.
sitiondiagrams havenoexecutablesemantics,theyaremerelyused toidentify
thetransitionandtoenhancereadabilityofthestatemachinemodel.Toattach
enablingconditionsandexecutablecodeto astatemachine transitionweopen
thetransition's propertyeditor, asshown in Figures 11and 12.There are two
formatsforspecifyingtransition code.Figure 11showstheUMLstyleofden-
ingtransitioncode.Thecodeconsistsrstofaneventspecicationwhichinour
implementationconsistsofthereceptionofamessagefromaport.Intheeditor
weusepull-downmenusthatallowtheuserrsttoselectaportfromwhichthe
messageis tobereceived,and second to selectamessagetypefrom thelist of
all messagesthat are allowablefor theselected port. A guardcan be specied
as a side-eect free Promelaexpression. The chosen semantics is that only if
the specied messageis receivableand the guardis truewill thetransition be
taken.TheactioncanbeanarbitraryPromelacodefragmentandwilltypically
contain a send statement for a message. Care has to be taken that the code
specied here is alwaysexecutable and does not contain internal control ow
loops. Thecurrent versionof VIPdoesnotparse the actioncodeand henceit
is theresponsibility ofthemodelerto ensurethat thecodeis meaningful.The
secondformat,illustratedin Figure12showsthemoreliberalwayofdeninga
transition.UnlikeUML-RT,v-Promelatransitionscanbetriggeredbytheexe-
cutabilityofanyPromelastatement,in thiscaseabooleanexpressionspecied
in the event clause. If the event clause evaluates to true then the action part
willbeexecuted.Inthisexampleamessageoftypebusytoneissenttotheport
toUser.
AsillustratedinFigure13,stateentryandexitcodewillbeexecutedwhen-
ever astate is entered orexited,respectively. In ourexample this means that
fromwhicheverstateweentertheawaitdigitstatewewill applyadialtone
signal to the user. This hasbearing on theformat in which transition code is
specied.Itcouldbearguedthattransitioncodecouldbespeciedbysimplyal-
lowinganarbitraryPromelastatementtobeattachedtoatransition.However,
exitcodeshouldbeexecutedpriortoexecutingthetransitioncode,whichwould
beimpossibleif wewerenotdistinguishing atriggeringeventin the transition
code.
4 The VIP Compiler
ThebasicprinciplesofthePromelacodegenerationarethatcapsulesaremapped
onto proctypes, protocols onto mtype declarations, and that ports with their
connectors as well as buers and synchronizers are mapped onto channel dec-
larations. Message bodies are implemented as record structures (typedefs in
Promelaparlance)withoneeldforeverymessagetypethattheprotocolcom-
prises.DataobjectsaremappedontoPromelavariables.Foramoreextensive
discussionwereferto[14,5,10].
Ports. Ports form part of the interface to capsule classes. Accordingly, the
Fig.11.Promelacodeinactionportionof
transitiondenition.
Fig.13.Entrycodedenition.
list of the corresponding capsule class proctype. On instantiation of a proc-
type,theVIPcompilergeneratestheproperargumentstobindthecorrectcon-
nectors to the ports. For instance, in the POTS example the POTS proctype
containsachannel declarationof theformchan toUser2105717128 = [1] of
SwitchToUser 2
.ThedenitionoftheUserproctypedeclarestwoports(from-
Switch andtoSwitch):proctype User(chan fromSwitch, toSwitch ).Inthe
body of the POTS proctype, the User proctype is instantiated and its ports
are bound by thecode run User( toUser2105717128, fromUser2016588168
). This scheme hasthe desirableproperty that ports canbereferenced within
theproctypewithoutregardforwhichchannelmaybeconnectedtoit.
State Machine Encoding. The v-Promelacontrol statescould beimplemented
intwoways:a)byusingPromelavariables,orb)byusingPromelacontrolstate
labels and goto statements. Measurements documented in [10] suggest that,
while the state vector size for both variants is identical, the state space size
for varianta) isabouttwice thesize for variantb). Wethereforeimplemented
variantb)inVIP.Thestatenamelabelischosensuchthatitstartswiththestate
nameinthev-PromelamodelandtheVIPcompileraddsanumericsequenceto
disambiguatestateswithidenticalv-Promelanames.
Transition Code. ThecodegeneratedfortransitionsspeciedintheUMLstyle
startswith checkingwhether thespeciedmessagereception eventisavailable
by polling the relevant channel. The resultis conjoined with theevaluation of
the guard which yields the transition's enabling condition. The ring of the
transition will cause the sequential execution of the following code fragments:
2
TheVIPcompilerdisambiguateselementnamesbyconcatenatingauniqueidentier
then theactioncodeassociatedwith thetransition, followedbyentrycodefor
thenewstateandnallythegotointothesuccessorcontrolstate.Promeladoes
not allowpolling thestate of synchronous rendez-vouschannels. Therefore,in
suchcasestherst partofthetransition codeconsistsonly oftherendez-vous
communication, and any specied guard will be ignored. Figure 14 illustrates
this mechanism for the offhook transition from the idle state of Figure 9.
To enhance comprehensibility of the code, the compiler automatically inserts
meaningfulcommentsevenifnoentryorexitcodehasbeenspecied.Notethat
the transition modeled here is a chained multi-level transition from the idle
state into the wait sub-state contained in the awaitdigit state (c.f. Figure
10),andthattheentrycodedenedforawaitdigit,i.e.,toUser!dialtoneis
executedduringthis transition.
if
idle1723158139:
:: fromUser?[offhook] && true ->
fromUser?UserToSwitch_msg;
/* exit idle */
/* action offhook_ */
/* entry await_digit */
toUser!dialtone;
/* entry wait */
goto wait2091208315
...
fi
Fig.14.TransitioncodeforUML-style.
if
/* correct_connectreq_audibler ing */
:: received_ph_num.phone_numbe r == 1 ->
/* exit digit_received */
/* action
correct_connectreq_audibler ing */
toOtherHandler!connectreq;
toUser!audiblering;
/* exit await_digit */
/* action connectreq */
/* entry originator */
/* action untitled */
/* entry party_ringing */
goto party_ringing1956295048
Fig.15. Transition code for free-form
chainedtransition
Figure 15 illustrates the generated code for the VIP free form format for
transition code specication.In thiscasethe enablingconditionisspeciedby
anequalitytestonthevalueofavariable.Theexamplealsoillustratesachained
transition,i.e., onethat crossesnestinglevelsin thehierarchicalstatemachine.
All relevantentryand exit code specied along the transition chain is inlined
intothetransitioncodewhich,incertaincases,allowsittobeprocessedasone
atomicaction 3
.
Priority Schemes for Group Transitions. Theimplementation ofgrouptransi-
tions depends on the priority model the user wishes to adopt. Three possible
transitionpriorityschemesarepossible.Intherstscheme,higher-level(group)
3
Promelaallowsnon-blockingstatementstobegroupedintoanatomicclausewhich
{if
:: fromUser?[offhook] ...
fi } unless {
if
:: fromUser?[onhook]...
:: fromOtherHandler?[disconnect] ...
fi}
Fig.16.Priorityongrouptransition
{if
:: fromUser?[onhook] ...
:: fromOtherHandler?[disconnec t] ...
fi } unless {
if
:: fromUser?[offhook] ...
fi}
Fig.17.Priorityonlocaltransition
ringing2063158907:
if
:: fromUser?[offhook] ...
:: fromUser?[onhook] ...
:: fromOtherHandler?[disconnect] ...
fi
Fig.18.Transitioncodewithequalpriority
transitionscould takepriorityoverlower-leveltransitions.Alternatively, lower-
leveltransitions could take priority overhigher-leveltransitions. Finally, both
highandlow-leveltransitionscanbegivenequalpriority.InVIP,allthreeprior-
ityschemeshaveimplementedwiththeuserhavingcontroloverwhichschemeis
used.EqualpriorityisthedefaultinVIP.Itisimplementedsimplybycombining
bothhigh-levelandlow-leveltransitioncodeasseparateconditionsin thesame
if ... fistatementasillustratedinFigure18.Promelasemanticsdictatethat
multipleenabledconditionsinanifstatementarechosennon-deterministically
resultinginequalpriorityamongalternatives.Theothertwopriorityschemesare
implementedusingthePromelafAgunlessfBgconstructwhichpre-emptsstate-
mentsinA ifthestatementinBbecomesexecutable.Therstpriorityscheme
isimplementedbyplacinghigh-leveltransition code inBandlow-levelcodein
A.Thesecondschemeimplementsthereverse.Figures16and17illustrateboth
oftheseschemes.Notethatonlythenon-pre-emptiveschemecomplieswiththe
run-to-completionsemanticsofUML-RTasdescribedin [15].
5 Property Validation
Property validation of VIP-synthesized models currently relies on using the
Spin model checkerto analyzethe generatedPromelamodels. Theinterpreta-
tionofthevalidationresultsthatSpinproducesinthecontextofthev-Promela
modelcurrentlyreliesonmanualinterpretation.Wediscusstwovalidationcase
the intentionof revealing mostof thesignicantfeatures of v-Promelaassup-
portedbyVIP.Asaconsequence,littleattentionwaspaidtodevelopingaaw-
less model of POTS. The described POTS model is not free of deadlock. We
havelabeledtheidlestateinthePhoneHandlerprocessandtheonhookstate
in the Userprocess asend-states and anend-state check in Spin easily shows
a trace that terminates with one process an invalid end-state. This is mainly
due tothe factthat wehavenotsynchronizedtheUserandPhoneHandlerin-
teractions. Thus,the Usercanrepeatedlygenerate offhookand onhookevent
sequences that will eventually ll up the channel to the PhoneHandler. Also,
callprocessingsoftwareisrarely\live",i.e.,itonlysatisestriviallivenessprop-
erties.AprogresstestinSpin easilyshowsoffhookandonhookcyclesthatdo
notimplysystemprogress.
We therefore decided to answer the questionof whether our POTS model
wasatallcapableofdoingit'sveryraisond'^etre,namelytoconnecttwophones.
Inordertoshowthatsuchascenarioexists,weformulatetheconverseproperty
(namely,thatthescenariodoesnotexist)andhopethat Spinwouldrefutethe
claim byshowingus atrailto thecontrary. Theproperty we seek to proveis:
\thereexistsascenarioinwhichbothPhoneHandlerprocessesareintherespec-
tiveconversationstates." Theconverseof theproperty is:\it is neverthecase
that,atthesametime,onePhoneHandlerprocessreachestheconversationstate
foranoriginatorandtheotherreachestheconversationstateforaterminator."
This property isrepresentedby theLTL formula:!<>(p && q)where pand q
aredened inSpinbythestatepropositions:
#define p (PhoneHandler[2]@conversation_orig1985130888)
#define q (PhoneHandler[3]@conversation_term2034323067)
TheseexpressionsarereferredtoasremotereferencesinPromelaparlance.The
expression PhoneHandler[2]@conversationorig1985130888is aboolean ex-
pressionthatevaluatestotrueiftheprocessnamedPhoneHandlerwithprocess
id equalto2isatthecontrolstatelabeledconversationorig1985130888.
Shortlyafter runningthe model checkeron theaboveclaim, anerror trace
wasfound. As expected, theerror tracethat Spin foundshowed ascenarioin
whichbothPhone Handlerprocesseswereintherespectiveconversationstates.
Thevalidation requiredmatchingappr. 448,000states,680,000transitions and
45.5MByteofmemory.
Validation of CORBA GIOP. In a previous work we modeled and formally
validated the Common Object Request Broker Architecture (CORBA) Gen-
eral Inter-ORB Protocol (GIOP) [4]using Promela/Spin validation technol-
ogy[11].Inthatwork,ahand-builtmodelofGIOPwasdevelopedandvalidated
in Promela.Subsequently, av-Promela model of GIOP was created using the
VIP tool. The v-Promela model of GIOP has the equivalent functionality of
thescaled-down,hand-built model that wasvalidated in[11].It comprisestwo
User, twoServer,one GIOPClient and twoGIOPAgent processes. Themodel
structureisshowninFigure19.Behaviorofthevariouscapsulesisdenedusing
CertainlimitationsoftheVIPtoolcauseddiÆcultyin expressingthestruc-
tureofthemodelinanaturalway.Forexample,replicationofcapsuleinstances
was not implemented in the tool at the time the experiments were run and
therefore,multipleinstancesofcapsuleshadtobeexplicitlyshowninthemodel.
Similarly,replicatedports andchannels were alsonotavailable in thetooland
thus,buerswereusedto emulate thedesiredcommunicationstructure.
Inthev-PromelamodelofGIOP,messagesdestinedtotheGIOPClientfrom
either ofthe Userprocessesare mergedinto a singlebuer called toClientU.
Similarly,messagesdestined for theGIOPClientfrom either of theGIOPAgent
processesare mergedinto abuercalledtoClientL. Inthe oppositedirection,
theGIOPClientmaysendmessagestotheUserorGIOPAgentbyplacingthemin
thetoUserandtoAgentLbuersrespectively.Themessagesaretaggedwiththe
Promelaprocess id (pid)of thereceiving processwhich onlyreceivesmessages
that containitspidasatag.
Model PropertyStatevectorDepthStates TransitionsMemoryusage
hand-builtsafety 244byte 119 77,261 92,566 17.697Mb
VIP safety 256byte 171 8,704 13,236 4.590Mb
hand-builtprogress 248byte 229 237,157534,157 49.032Mb
VIP progress 260byte 223 13,641 36,376 5.819Mb
Table1.Vericationofsafetyandprogresspropertiesofhand-builtversusautomati-
callygeneratedcode.
Thischeckedforinvalidend-statesandassertionviolations.Equivalentassertions
wereplacedin bothmodelsto checkfor invalidconditionssuch as receptionof
aReplywhen noRequestwasoutstanding.Also,end-state labelswereplaced
inbothmodelstoidentifyvalidend-statesineachprocess.Tovalidateprogress
propertiesaprogresslabelwasinsertedinto themodelswheretheUserprocess
reachestheUReplyRecvdstate.Bothmodelsranwithnoviolationsonthesafety
as wellas theprogressproperties. Theresultsare shownin Table1.As can be
seen,theVIPgeneratedcode,althoughitrequiredalargerstatevector,resulted
in a signicantly smaller state space. This can be attributed to two factors.
First,thestateencodingoftheVIPgeneratedmodelusesgotostatementswhile
thehand-builtmodelusesaneventloopconstructin whichcontrol stateswere
represented through variables. It wasshown in [10] that this dierence alone
can account for a doubling in state space size. Second, the hand-built model
usesglobal variablesfor allchannelswhereas,the VIPgeneratedcodedeclares
channels asbeing local variables of the Env process. In [10] it was also shown
that theuse ofglobalvariablescanreduce theeectivenessof thepartial order
reductionalgorithmandthus alsocontributesto alargerstatespace.
Tomodeltheoccurrenceofeventsin thestate-basedmodelcheckerSpinwe
used the previouslydescribedconcept of remote referencing. Forexample, the
remotereference:
#define p (GIOPAgent[5]@SRequestSent)
refersto alabelSRequestSentintroducedinto theactionpartofthetransition
code within a state-machine in the GIOPAgent capsule. It corresponds to the
stateaftertheSRequestmessagehasbeensent.
For the hand-built GIOP model, ten high-level requirements (HLR) were
formulated and veried in [11]. Of the ten requirements, two were explicitly
checked on the VIPgenerated code for the GIOP model. Someother require-
ments were checked implicitly through the use of assertions. All requirements
that were checkedwere exhaustivelyveriedsuccessfully ontheVIPgenerated
model. Thisservesto conrmthat therequiredbehaviorspresentinthehand-
builtmodelarealsopresentintheVIPmodelandthattheVIP-generatedcode
doesnotcauseaprohibitivestatespacesizepenalty.
6 VIP Implementation
VIP wasimplementedin theJavaprogramminglanguageusing SunMicrosys-
tem's freely available Java Development Toolkit version 1.2. This allowed us
to achieve a highly portable tool while leveraging Java's extensive GUI sup-
port. In developing VIP we adhered to a strict model-view separation which
has enhancedexibility and reuse in the design. Toachievemaintainability, a
quintessentialrequirementintheacademicenvironmentinwhichVIPwasbuilt,
allclass structureshavebeendocumentedin UML. Thegraphicaleditors used
libraries.
Asdiscussedin[10],VIPcontainsasetofapproximately30well-formedness
rules,themajorityofwhicharecheckedwheneveramodelcomponentischanged
asaresultofchanges intheview.Anexampleruleisthat \... aconnectorcan
only connect Portsthatareprotocolcompatible..."
7 Conclusions
WeintroducedtheVIPtoolwhichpermitsthecreationandeditingofv-Promela
modelsaswellasthecompilationofthesemodelsintoPromelacode.Weshowed
that the resulting models are analyzableusing standardSpin model checking
technology.
Thecurrent versionof VIPsupportsmany features ofv-Promela.A major
thrust in research and development eortwill be needed to develop VIP into
a comprehensive CASEtool for requirements and high-leveldesign. First, the
aspect of property specication is currently not supported very strongly. We
hopethat an incorporation ofideas stemming from thetemporal logic speci-
cationpatternapproach[3]andfromgraphicalintervallogics[12]willfacilitate
thespecicationof requirements.Wewillalsodesignwaysofrelievingtheuser
from having to build hooks inside the synthesized Promelacode, for example
byintroducinglabels,byallowingpropertyformulaetorefertostatesandvari-
ablesin thev-Promelamodel.Next,weplantofeed theSpinvalidationresults
backinto theVIPenvironmentincluding ananimationofsimulationanderror
tracesinside VIP 4
.Wealsointend to explore linking thev-Promela models to
other model checking tools by suitable intermediate representations asfor in-
stancethe IF representation[1].The questionofthe dierentpriorityschemes
forimplementingtransitioncodehashighlightedtheneedforparametricseman-
tics in ordertoremaincompatible withothermodelingtoolsand methods.We
plan,inparticular,todevelopasetofsemanticoptionsthatwillallowanalyzing
modelswhichhavesemanticsidenticaltoUML-RT.Finally,someconceptsfrom
v-Promelasuch asstructuraland behavioralinheritance aswellas data object
scopinghavenotyetbeenimplementedandweplanto addtheseaswell.
Wehopethatbyreconcilinganindustrialstandardvisualmodelinglanguage
like UML-RT with the input language of a model checker, and by providing
suitabletool support wecancontributeto increasing theacceptanceof formal
methodsin thepracticalsoftwareengineeringcommunity.
Acknowledgements. TheNexuscomponentthatVIPuseswasjointlydeveloped
withChristopherTrudeau.
References
1. M.Bozga, L.Ghirvu,S.Graf,L.Mounier,andJ.Sifakis. TheIntermediateRep-
resentationIF:Syntaxandsemantics. Technicalreport,Verimag,Grenoble,1999.
4
UpperSaddleRiver,NewJersey,USA,1993.
3. MatthewB.Dwyer,GeorgeS.Avrunin,andJamesC.Corbett. PropertySpeci-
cationPatternsfor FiniteStateVerication. InProceedings ofthe2ndWorkshop
onFormalMethodsinSoftware Practice,March1998. Foraccessto thepatterns
catalogseeURLhttp://www.cis.ksu.edu/~dwyer /spe c-pa ttern s.ht ml.
4. ObjectManagement Group. TheCommonObjectRequest Broker:Architecture
andSpecication. Revision2.1,August1997.
5. G.J.HolzmannandS.Leue.Towardsv-Promala,avisual,object-orientedinterface
forXspin. Unpublishedmanuscript,1998.
6. G.J.Holzmannand Margaret H.Smith. A practicalmethodfor theverication
ofevent-drivensoftware. InProc.ICSE99,pages597{607,LosAngeles,CA,USA,
May1999. invited.
7. G. J. Holzmann and Margaret H. Smith. Software model checking. In Proc.
FORTE/PSTV1999, pages 597{607,Beijing, China, October1999. Kluwer. in-
vited.
8. G.J. Holzmann. ThemodelcheckerSpin. IEEE Trans.onSoftwareEngineering,
23(5):279{295, May1997. Specialissue onFormalMethodsinSoftwarePractice.
9. W.Janssen,R. Mateescu,SMauw,P.Fennema,andP.vanderStappen. Model
checkingformanagers.InTheoreticalandPracticalAspectsofSPINModelCheck-
ing, Proceedings of the 5thand 6thInternational SPINWorkshops, volume1680
ofLecture NotesinComputer Science,pages92{107.SpringerVerlag,September
1999.
10. M. Kamel. On the visual modeling and verication of concurrent sys-
tems. Master's thesis, University of Waterloo, 1999. Available from URL
http://fee.uwaterloo.ca/~m2kame l/re sear ch/th esis .ps.
11. M. Kameland S.Leue. Formalizationand Validationof theGeneralInter-ORB
Protocol(GIOP)usingPromelaandSpin.SoftwareToolsforTechnologyTransfer,
1999. Toappear.
12. G.Kutty,Y.S.Ramakrishna,L.E.Moser,L.K.Dillon,andP.M.Melliar-Smith.
Agraphicalintervallogictoolsetforverifyingconcurrentsystems.InC.Courcou-
betis,editor,ComputerAidedVerication,5thInternationalConference,CAV'93,
volume697ofLectureNotesinComputerScience,pages138{153.SpringerVerlag,
1993.
13. S.Leue and G.Holzmann. v-Promela:A Visual, Object-Oriented Languagefor
SPIN. InProceedingsof the2ndIEEESymposiumonObject-Oriented Real-Time
DistributedComputing(ISORC'99),SaintMalo,France,pages14{23.IEEECom-
puterSocietyPress,May1999.
14. S.Leue and G.Holzmann. v-Promela:A Visual, Object-Oriented Languagefor
SPIN. InProceedingsof the2ndIEEESymposiumonObject-Oriented Real-Time
Distributed Computing ISORC'99, pages 14{23. IEEE Computer Society, May
1999.
15. B.Selic,G.Gullekson,andP.T.Ward.Real-TimeObject-OrientedModelling.John
Wiley&Sons,Inc.,1994.
16. B.SelicandJ.Rumbaugh. UsingUMLfor modelingcomplexreal-timesystems.
http://www.objectime.com, March1998.
17. W3C. Extensible Markup Language (XML) - W3C Recommendation.
http://www.w3.org/TR/REC-xml, February1998.
