HAL Id: hal-00795028
https://hal.inria.fr/hal-00795028
Submitted on 27 Feb 2013
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Using UML sequence diagrams as basis for a formal test description language
Simon Pickin, Jean-Marc Jézéquel
To cite this version:
Simon Pickin, Jean-Marc Jézéquel. Using UML sequence diagrams as basis for a formal test description language. Proc. of Fourth International Conference on Integrated Formal Methods IFM2004, Apr 2004, Canterbury, United Kingdom. �hal-00795028�
formal test description language
?
SimonPickin 1
andJean-MarcJezequel 2
1
Dpto.deIngenieraTelematica,UniversidadCarlosIIIdeMadrid,Spain
Simon.Pickin@it.uc3m.es
2
IRISA,CampusdeBeaulieu,UniversitedeRennes,France
Abstract. Aformal, yetuser-friendly, testdescription languagecould
increase the possibilities for automation in the testing phase while at
the same time gaining widespread acceptance. Scenario languages are
currently one of the most popular formats for describing interactions
betweenpossiblydistributedcomponents.Thequestionofgivingasolid
formalbasistoscenariolanguagessuchasMSChasalsoreceivedalotof
attention.Inthisarticle,wediscussusingoneofthemostwidely-known
scenario languages, UMLsequence diagrams, as the basis for a formal
testdescriptionlanguageforuseinthedistributedsystemcontext.
1 Introduction
Testing iscrucial to ensuring softwarequalityand thetesting phaseabsorbsa
large proportion of development costs.Despite this fact, testing remainsmore
of a craft than a science. As a result, the productivity gains to be obtained
from amoresystematic treatmentof testing, andfrom the consequentgreater
level ofautomation in thetesting phase,are potentiallyverylarge.Theuse of
aformaltest descriptionlanguageisakeypartofsuchasystematictreatment,
asexplainedin [24].
Oneof the main bents of such alanguage is theability to abstract away
fromthelessimportantdetail.Aswellasbeingcrucialtomanagingcomplexity,
abstraction isthemeansbywhich platform-independentdescriptionsaremade
possible.Graphicalanalysisanddesignlanguagesareattheheartofrecentmoves
toraisethelevelofabstractioninusualsoftwaredevelopmentpractice.However,
the lackof a formal basisto the most widely-used of these languages,such as
UML, limits the extent to which they can be used to facilitate automation.
Among such graphicallanguages,scenariolanguagesare becoming popularfor
describinginteractionsbetweenpossibly-distributedcomponents,duetothefact
thattheypresentthecommunicationsandthetemporalorderingsbetweenthem
?
This workwas initiated inthe COTE project of the FrenchRNTL research pro-
choice fordescribingtestsin whichthecommunicationaspectispredominant.
Inthis article we discuss dening a formal test descriptionlanguagebased
on UML sequence diagrams and give an overview of such a language called
TeLa,originally developedin theCOTEproject[12](an earlyversionof TeLa
ispresentedin[20]).Insodoing,wedealwiththemainsemanticissuesinvolved
in using UML sequence diagrams, and scenario languages in general, as the
basisforaformallanguage,in ourcase,foratestdescriptionlanguage.Despite
theimportance ofthese issues, giventhe rapiduptakeof UML, thereis alack
of detailed analyses of them in the literature, not least in the oÆcial UML
documentation.HereweprovidesuchananalysisnotonlyforUML1.4/1.5[16]
sequence diagrams but also for the sequence diagrams of the upcoming UML
2.0[17] standard.
Wechose to baseourlanguageon UMLin order to increasethechances of
the work having some industrial impact, notably in widely-used development
processes and CASE tools. In addition, this choice should make testing more
accessible,notonlydue totheuser-friendlysyntaxbut alsosince:foraSystem
Under Test (SUT) that is an implementation of a model designed in UML, if
thetestlanguageisalsobasedonUML,therelationbetweenthetestsand(part
of) the designmodel ismore manifest. In thecomponent testing context, this
accessibilityalso facilitatestheuseof testsascomponentdocumentation. This
documentation can be viewed as a typeof constructivecontract, asan instal-
lation aid, asaregressiontesting aidin caseof changes in theimplementation
of thecomponentorof itsenvironment,etc.TeLawasconceivedasatest lan-
guageforcomponent-basedapplications.TheuseofTeLaastheinterfacetothe
Umlaut UML simulatorand theTGVtestsynthesistoolin theCOTEproject
istreatedin[21].
Wecurrentlyrestrictourinterestto black-boxtesting,thoughscenariolan-
guagescouldalso beused forsometypesof grey-boxtesting. Weaim ourlan-
guage at a higher level of abstraction than, for example, TTCN [6] for which
ascenario-basedgraphicalsyntaxhasalso beendevelopedin recentyears.The
UMLTestProle,see[18],istestimonytotheindustrialinterestinaUML-based
testdescriptionlanguage.TheworkonTeLareportedonherebegunbeforethat
ontheTestProleandthoughthetwoapproacheshavesimilaritiestheyarenot
currentlycompatible,seeSection3.4.
InSection2andSection3weanalysethesuitabilityofUML1.4/1.5sequence
diagrams andUML 2.0sequencediagrams,respectively.In Section4wegivea
avouroftheTeLalanguageandinSection5wepresentsomeimportantaspects
ofitssemantics.InSection6wedrawconclusions fromthiswork.
2 Suitability of UML 1.4/1.5 Sequence Diagrams
Inthis section wetacklethe issueof basingaformal testdescription language
onUML 1.4/1.5sequence diagrams,astheyare denedin the UMLstandard.
increasedasdiscussedin Section2.3.
2.1 Semanticinconsistencies ofUML 1.4/1.5Sequence Diagrams
IntheUML1.4/1.5specications,thesemanticsofsequencediagramsisdened
intermsoftworelationsbetweenmessages,predecessorandactivator,inaman-
ner similar to [13]. Predecessorrelates a message sent by a method to earlier
messagessentbythesamemethod while activatorrelatesamessagesentbya
method to themessage that invoked that method. Two messagescan then be
said to be onthe samecausal owif this pair of messagesis in thetransitive
closureoftheunionofthesetworelations.Clearly,messagescanonlybeordered
iftheyare onthesamecausalow.
UML 1.4/1.5sequence diagrams betray theirorigins,which lie in procedu-
raldiagrams|diagramsinvolvingasinglecausalowandin which allcallsare
synchronous|used to describe the behaviour of centralised OO programmes.
Theyrepresentanattemptto generalisethese proceduraldiagrams toincorpo-
ratetreatmentofconcurrency,asynchronouscalls,activeobjects,etc.Unfortu-
nately,theresultinggeneralisationisnotconsistent.
Intheircurrentstate,then,UML 1.4/1.5sequencediagramsare unsuitable
foruseasthebasisforaformaltestdescriptionlangaugepitchedatarelatively
high-levelofabstraction.Inthefollowingsectionswepresentthemainproblems
withtheUML1.4/1.5semantics.
The sequence numbering notation. This notation is inconsistent in the
followingsense.Concurrencyissupposedtobemodelledusingthethreadnames
andexplicitpredecessorspartofthenotation.However,thispartofthenotation
appearstoassumethatmessagesemittedondierentlifelinescanberelatedvia
the predecessorrelation, e.g. see Fig.3-71 of [16],contradicting the semantics
(in particular, the semantics of theactivation partof the sequence numbering
notationthatusesthedotnotation!).
Moreover,theactivationpartof thisnotationis unworkableexcept incom-
pletecausalows.Theuseofguards,guardedloopsandbranchingwouldmake
itevenmoreunworkable.
Focus barsand asynchronous messages/ active objects. Itisnotclear
from theUMLstandardwhether theuseoffocusbars(or, equivalently,nested
sequencenumbers)isallowedordesirableinthepresenceofasynchronousmes-
sagesand/oractiveobjects.However,iffocusbarsarenotused,accordingtothe
semantics,noorderingrelationscanbeinferredbetweenasynchronousmessages
emittedondierentlifelines.
There is little in the standard to justify other interpretations such as that
speciedwithoutcompletecausalows.Sequencediagramscannotthereforebe
usedforspecication,whereabstractionisfundamental,butonlyforrepresent-
ingcompleteexecutiontraces.
Lackof orderingbetween dierentcausal ows. Evenwhenrepresenting
acomplete execution trace,messages ondierent causal ows arenot ordered
w.r.t.eachother.
Inparticular,asignalis acausalsink that isonly relatedto messagesthat
precede it on the same causal ow. Thus, it has no temporal relation to any
messageemittedorreceivedonthereceivinglifelineexceptcausalancestors.
Similarly, amessage emitted spontaneously by an activeobjectis a causal
sourcethat isonly relatedtomessagesthat succeediton thesamecausal ow
(andeventhis,onlyiffocusbars/nestedsequencenumbersareused,seeabove).
Thus, it has no temporal relation to any message emitted or received on the
emittinglifelineexceptcausaldescendants.
The notion of a message being\completed". Thepredecessorrelationis
said to relate \completed"messages on alifeline. In the caseof asynchronous
messages,howdoesthesenderknowwhenamessagehas\completed"?
The denition of active / passiveobject. Thevaguenessofthe denition
ofcontrolowschemeinUML, i.e.theconceptofactive/passiveobject,means
that theexactroleofthisconceptinsequencediagramsisnotclear.
2.2 Clarifying the Semanticsof Sequence Diagrams
Inthissectionwemodifythesemanticsofsequencediagramstosolvetheprob-
lemsdiscussedin Section2.1.
An Interworking-Style or \Message-Based" Semantics. The most ob-
vious solution to the problems discussed in the previous section is to remove
theactivatorrelationfromthesemanticsandsimplyrelatemessagesemittedon
thesameorondierentlifelinesviathepredecessorrelation 3
.Thesemantics is
thereforedenedas apartialorder ofmessages.
Thereareseveralwaysinwhichpredecesorrelationsbetweenmessagescould
be inferred from a sequence diagram. The most intuitive solution is to use a
semanticssimilartothat ofinterworkings[14],but which alsoallowstheuseof
synchronouscallsandfocusbars.Notethat such asemanticscannotberelated
to theUML1.4/1.5metamodel(i.e.theabstract syntax), sincetheadditionof
loops andbranching(see below)couldleadto innite depth, andeveninnite
width, metamodelstructures.
3
Intheabsenceofanactivatorrelation,thequestionarisesastotheroleofthefocus
bar,apartfromrelatingsynchronousinvocationmessagestothecorrespondingreply
style semantics is not well-adapted to distributed system description. Neither
is it well-adapted to test description since, in the case of messagessent (resp.
received) by the tester to (resp. from) the SUT, the tester behaviour to be
describedencompassesonlytheemission(resp.reception)ofthemessagebythe
testerbutnotitsreception(resp.emission)bytheSUT.
Asemanticswhichdistinguishesemissionandreceptioneventsisclearlymore
suitable for describing tester behaviour. We are therefore led to use a partial
order of events semantics, similar to that of MSC [10] rather than a partial
orderofmessagessemantics,simliartothatofinterworkings.
A Message-Based SemanticsInside an Event-Based Semantics. Inor-
der to be able to use the simplicity of the interworking-stylesemantics when
appropriate, we dene amessage-basedsemanticsasarestriction of anevent-
basedsemantics,extendingtheworkof [4],see [19]for details.This enablesus
tospecifywhenrequiredthatanydiagram,orevenpartofadiagram,thatsat-
isesthe RSC(RealisablewithSychronousCommunication)property[2],is to
beinterpretedusingthemessage-basedsemantics.
Amongthe multiple usesof this facility, when modelling centralised imple-
mentationsitcanbeusedtoavoidclutteringupdiagramswithsynchronization
messages.In theCOTE project, thisfacility wasused to representthe output
oftheTGVtestsynthesistoolin sequence-diagramform,see[21].
2.3 Increasing the Expressiveness ofSequence Diagrams
As well as being ill-dened, UML 1.4/1.5 sequence diagrams are lacking con-
structs whichare essentialforatest descriptionlanguageofthetypediscussed
in theintroduction.Thoughmostofthese constructscouldalsobeseenascru-
cialto otherusesofsequencediagrams,herewedonotaddressthiswiderissue
but concentrate,instead,ontest description.Inlooking forsuitableconstructs,
weseekinspirationfromtheMSCstandard.Inthefollowingsectionswediscuss
boththe constructs we will need to add and theexisting constructswhich we
will needto modify.However,before doingso,webriey discussthesignicant
limitationsthatwedonotaddress.
Perhapsthemostimportantoftheselimitationsistheabsenceofagatecon-
struct and of a parallel operator, unlike the situation in MSC. This is due to
thecomplexityoftheirinteractionwiththeloopoperator,whichwouldmakeit
alltooeasytoproduce unimplementablesequence diagrams.Onthedownside,
thelackofaparalleloperatormaymakeitdiÆculttodescribecertaintypesof
distributed testing scenariosinvolvingconcurrentchoices. Twoimportantlimi-
tationswhicharesharedwithMSC,namelytheabsenceofamulti-castconstruct
andtheinabilitytospecifythecreationofanarbitrarynumberofcomponents,
changes requires ameansof composing diagrams sequentially. Sequentialcom-
positionisalsoessentialforrepresentingdierentalternativecontinuations,see
thesectiononbranching,below.
Useof theevent-basedsemantics meansthatweak sequentialcomposition|
thatusedintheMSCstandard|isessentialforcompositionality,thatis,inorder
forbehaviourtobeconservedifadiagramissplitintoasequenceofsmallerdia-
grams.Thoughweaksequentialcompositionisthemostsuitabledefaultcompo-
sitionmechanism,wealsorequireawayofexplicitlyspecifyingstrongsequential
composition,thatis,compositioninwhichalleventsoftherstdiagramprecede
alleventsoftheseconddiagram,inordertodescribethesequentialexecutionof
dierenttestcases.Thisisneededtomodeltestcaseterminationwhichinvolves
aglobal syncronisation in order for aglobal verdict to be reached. This latter
typeofsequentialcompositionhasnocounterpartinMSC.
Internal Action. Modelling component creation/destructionin the presence
of lifeline decomposition requires a construct for specifying the creation of a
subcomponentonalifeline.Representingdatamanipulationrequiresaconstruct
forspecifyingassertionsandassignmentsonalifeline.Thesethreetypesofaction
could be placedin aninternal action locatedat aprecise position onalifeline
inasimilarwaytotheMSCinternalaction.Semantically,lifelineterminationis
alsoviewedasaninternalaction. Finally, an\escape"internalaction,allowing
otherlanguagecodetobeinserted(subjecttohypothesesonitseects)ishighly
desireablein theUML context.
Unlike in MSCs, for more exibility when used in conjuntion with lifeline
decomposition, we allow assignment and assertion internal actions to straddle
severallifelines,thusinvolvingimplicitsynchronisations.
Branching. We require a construct to specify the situation in which several
alternativesarepossible.
Ifthetesterhasseveralpossiblealternativeemissionactions,wewouldnor-
mallyexpecttheconditionsdeterminingwhichactionischosentobefullyspec-
ied in the test description. However, in the case where the SUT has several
possiblealternativeemissionactions,inblack-boxtesting, theconditionsdeter-
mining which action is chosen may depend on details of the internal state of
theSUTthatareunknowntothetester,particularlyiftheSUTisaconcurrent
and/ordistributed system.Thislatterphenomenon issometimesreferredto as
observable non-determinism. We requirea choice construct that is suÆciently
generalto beabletodescribeindenitechoices,i.echoicesinvolvingobservable
non-determinism.
The\presentationoption"branchingconstructofUML1.4/1.5sequencedi-
agramsisunsuitableforthefollowingreasons:
volvingbranchingcanonlybeguaranteedtobeunambiguousifcausalows
arecompletelyspecied,
{ ifguardsarenotmutuallyexclusive,thesamebehaviourmaydescribechoice
orconcurrencydependingondatavalues;withanynon-trivialdatalanguage,
therefore,thequestionofwhetheragivenconstructalwaysdenotesachoice
willoftenbeundecidable.
These propertiesmakethisconstructof littleuseforspecication.Aconstruct
similartothealternativesofMSCswouldanswerourrequirements.
Loops. Werequireaconstructforspecifyinggeneraliterativebehaviour.
The recurrenceconstruct of UML 1.4/1.5 sequence diagrams is unsuitable
sinceit wasconceived forusewith lifelinesrepresentingmulti-objects,without
themeaningofemissionsandreceptionsofothermessagesonsuchlifelinesbeing
claried.The\presentationoption"iterationconstructofUML1.4/1.5sequence
diagrams is unsuitable since it can onlybe used to specify a nite number of
iterations.AconstructsimilartotheMSCloopwouldanswerourrequirements.
ExplicitConcurrency(Coregion).Werequireaconstructtoexplicitlybreak
thedefaultorderingonlifelines,e.g.tospecifyamulti-castperformedbyanSUT
component,wherethetesterneitherknows,norcares,abouttheorderinwhich
themessagesareemitted.
TheexplicitpredecessorpartoftheUMLsequencenumberingnotationisun-
suitableduetoitsambiguityinthepresenceofloopsanditsuser-unfriendliness.
AconstructsimilartotheMSCcoregionwouldanswerourrequirements.How-
ever, we will be led to use a coregion construct that is richer than the MSC
coregion. InMSC, focus barshaveno semantics. An importantpartof these-
manticswegivetofocusbarsbelowconcernstheirinteractionwithcoregions.
Synchronisation Messages/LocalOrderings. Werequireameansofex-
plicitly ordering twoeventswhich would not otherwisebeordered. Where the
two events are on the same lifeline, this can be used in conjunction with the
coregiontospecifymorecomplexconcurrentbehaviour.
InMSC, the general ordering construct is used for this purpose. However,
wewouldprefertosyntacticallydistinguishgeneralorderingsbetweeneventson
thesamelifelineandthosebetweeneventsondierentlifelines.WhiletheMSC
syntaxis adequatefortheformer, weprefer touse a\virtual synchronisation"
messageforthelatter 4
Semantics of Focus Bars. In UML 1.4/1.5 sequence diagrams, focus bars
are usedto representmethodexecutions. Thisconceptis avaluableone in the
context of object- and component-basedapplications. We would thereforelike
4
ofanactivatorrelation.FocusbarshavebeenintroducedinMSCsbuthaveno
formalsemantics.Weconsiderthissituation ratherunsatisfactory.
Asstatedabove,focusbarsrelaterequesttoreplyinsynchronousinvocations.
SincewewillnotusetheUML1.4/1.5sequence-diagramsemantics,wecandene
theuseoffocusbarstobeoptionalwithasynchronousinvocationswithoutlosing
orderingbetweeneventsondierentlifelines.
Wepropose toformalisethesemantics oftheinteraction offocusbarswith
coregions as follows. If a focus bar falls within the scope of a coregion, the
orderingrelationsbetweentheeventsinthescopeofthefocusbarareunaected
bythatcoregion.Thus,afocusbarfallinginsideacoregionisashorthandfora
set oflocalorderings,seeFig.1foranexample.
Inaddition,however,weproposethatpassivenessof thelifelineinquestion
imposes aconstrainton theordering relationsbetween theeventsin the focus
barscope,ontheonehand,andtheothereventsofthecoregionthat arenotin
thefocusbarscope,ontheother.Forexample,inFig.1,Tester2beingpassive
correspondsto theconstraintthatneitheroftheevents!m
1
and!m
8
canoccur
between?m
2 and!r
2
orbetween?m
5 and!m
7
,where?(resp.!)signiesreception
(resp.emission).Thisdependenceoftheorderingpropertiesonthecontrolow
scheme models the implementation of concurrency on passive components as
beingviataskschedulingratherthanviaexecutionthreads.
Fig.1.Focusbars falling insidethe scope of acoregion(l.h.s.); equivalentorderings
denotedusing thelocalorderingconstruct(r.h.s.).
Caremustbetakenas regardsthemeaning offocusbarsin thepresenceof
lifelinedecomposition,particularlyifthelifelineisspeciedtobepassive.Inthis
lattercase,itturnsoutthatwewillneedtoobligetheconservationoffocusbars
