Generation and Validation of Traces between Requirements and Architecture based on Formal Trace Semantics

(1)

ContentslistsavailableatScienceDirect

The Journal of Systems and Software

jo u r n al h om e p a g e :w w w . e l s e v i e r . c o m / l o c a t e / j s s

Generation and validation of traces between requirements and architecture based on formal trace semantics

Arda Goknil

^a^,∗

, Ivan Kurtev

^b

, Klaas Van Den Berg

^c

aAOSTEResearchTeam,INRIA,SophiaAntipolis,France

bNspyre,Dillenburgstraat25-3,5652AMEindhoven,TheNetherlands

cSoftwareEngineeringGroup,UniversityofTwente,7500AEEnschede,TheNetherlands

a r t i c l e i n f o

Articlehistory:

Received2August2012

Receivedinrevisedform2October2013 Accepted2October2013

Availableonlinexxx

Keywords:

Tracegenerationandvalidation Requirementsmetamodel Tracemetamodel Softwarearchitecture

a b s t r a c t

Thesizeandcomplexityofsoftwaresystemsmakeintegrationofthenew/modiﬁedrequirementstothe softwaresystemcostlyandtimeconsuming.Theimpactofrequirementschangesonotherrequirements, designelementsandsourcecodeshouldbetracedtodeterminepartsofthesoftwaretobechanged.

Considerableresearchhasbeendevotedtorelatingrequirementsanddesignartifactswithsourcecode.

Lessattentionhasbeenpaidtorelatingrequirements(R)witharchitecture(A)byusingwell-defined semanticsoftraces.TracesbetweenR&Amightbemanuallyassigned.Thisistime-consuming,anderror prone.Tracesmightbeincompleteandinvalid.Inthispaper,wepresentanapproachforautomatic tracegenerationandvalidationoftracesbetweenrequirements(R)andarchitecture(A).Requirements relationsandarchitectureverificationtechniquesareused.Atracemetamodelisdefinedwithcommonly usedtracetypesbetweenR&A.Weusethesemanticsoftracesandrequirementsrelationsforgenerating andvalidatingtraceswithatoolsupport.Thetoolprovidesthefollowing:(1)generationandvalidationof tracesbyusingrequirementsrelationsand/orverificationofarchitecture,(2)generationandvalidation ofrequirementsrelationsbyusingtraces.ThetoolisbasedonmodeltransformationinATLandterm- rewritinglogicinMaude.

1. Introduction

Today’ssoftwaresystemsarecomplexartifactsoftendeployed inahighlydynamiccontext.Therequirementsofsoftwaresystems changecontinuouslyandnewrequirementsemergefrequently.In ordertoreduce thecostfor implementingtherequired system changes,itisimportanttoapplychangemanagementasearlyas possibleinthesoftwaredevelopmentcycle.Requirementstraceabil- ityisconsideredcrucialinchangemanagementforestablishingand maintainingconsistencybetweensoftwaredevelopmentartifacts.

Whenchangesintherequirementsareproposed,thetraceability informationisusedtocalculatetheimpactofthesechanges on othersoftwareartifactssuchasrequirements,architecture,source codeandtestcases.

Traceability is the ability to follow the usageof an artifact throughout the software development process. For example, a requirementmaybetraced forwardtothearchitectural design, detaileddesign,and sourcecodecomponentsthatimplementit andbackwardtoitsstakeholdersandbusinesscontext.Traceability

∗Correspondingauthor.Tel.:+33761447052.

E-mailaddresses:arda.goknil@inria.fr,ardagoknil@gmail.com(A.Goknil), ivan.kurtev@nspyre.nl(I.Kurtev),vdberg.nl@gmail.com(K.VanDenBerg).

hasbeenrecognizedasanimportantqualityproperty(Rameshand Jarke,2001)which,however,isexpensiveanddifﬁculttoachieve inpractice.Itreliesontheavailabilityofahighvolumeoftrace relations(simplycalledtracesortracelinksinthispaper)between artifacts.Mostapproachesfocusonachievingtraceabilitybetween requirementsandsourcecodeorbetweendesignandsourcecode (Antonioletal.,2002;Egyed,2003;Grechaniketal.,2007;Hayes etal.,2006).Lessattentionhasbeenpaidtorelatingrequirements withsoftwarearchitecture.

Establishingtracesbetweenrequirementsandarchitecturefor change management may bebeneﬁcial due toseveral reasons.

Determiningthechangesinsourcecodecanbedifﬁcultbecause codecontainsmanydetailsandthereisanabstractiongapbetween therequirements,therationaleforchangeandtheimpactedcode.

Incontrast,thearchitectureisatahigherlevelofabstractionandis generallyofasmallersizethanthecode.Softwarearchitectsbase theirarchitecturaldesigndecisionsontheessentialsystemrequire- mentsthusmakingdirectrelationsbetweentherequirementsand thearchitecture.Inadditiontothat,inmanycasesasoftwarearchi- tectureexpressedinaprecisearchitecturaldescriptionlanguage (ADL)canbeusedforautomaticcodegeneration.Thissupports automatictraceabilityfromarchitecturetocode.

http://dx.doi.org/10.1016/j.jss.2013.10.006

(2)

currentpracticesthetraceinformationemergingduringarchitec- turaldesignis eithercompletelylostoronly partiallycollected.

Manual trace assignment is time-consuming and may lead to invalidandincompletetraces.Theprocessofestablishingandval- idatingtracesshouldbeautomatedasmuchaspossibleinorderto reducetheoverallchangemanagementcosts.

Inthispaper,wepresentanapproachforgenerationandvali- dationoftracesbetweenR&A(requirementsandarchitecture).Our goalistoimprovethecurrentlyobservedpracticesbyproviding a degreeof automationthatallows faster tracegeneration and improvestheprecisionoftracesbyvalidatingthem.

Thetraces,therequirementsandthearchitecturedescriptions areuniformlyrepresentedasmodels.We builtonourprevious work(Goknilet al., 2011) onmodeling software requirements.

Requirementsspeciﬁcationsarecapturedinmodelsthatcontain requirementsandtypedrelationsamongthem.Thesemanticsof theserelationsisformalizedinFirst-orderlogic(FOL).

ArchitectureDescription Languages(ADLs) gainedsigniﬁcant attentionintheresearchcommunityandanumberoflanguages wereproposed.Theircurrentindustrialadoptionisreportedtobe lowwithsomeexceptions,forexample,intheembeddedsystems domain.LanguagesKoala(vanOmmeringetal.,2000),EAST-ADL (Cuenotetal.,2011)andArchitecture Analysisand DesignLan- guage(AADL)(SAE,2010)areusedforspecifying andanalyzing architecturesofembeddedsystems.Inparticular,EAST-ADLand AADLareindustrydrivenstandardsproposedbycompaniesinthe automotiveandavionicsdomain.

InthispaperweuseAADLbecauseoftheavailabilityofformal dynamicsemanticsofthelanguage.Thesemanticsallowsveriﬁ- cationandsimulationofarchitectureswhichisa mainenabling factorinourapproach.WeusedynamicsemanticsforpartofAADL (Ölveczkyetal.,2010a,b)expressedinrewritinglogicsupportedby theMaudelanguageandtools(Claveletal.,2002,2007).

WeproposetwomechanismstogeneratetracesbetweenR&A.

Theﬁrstmechanismusesarchitectureveriﬁcationtechniques.A givenrequirementisformulatedasapropertyintermsofthearchi- tecture.Thearchitectureisexecutedandastatespaceisproduced.

Iftheproperty issatisﬁed,the elementsintheexecution trace aftertheveriﬁcationarecollectivelyresponsibleforthesatisfac- tionofthegivenrequirement.Tracelinksareestablishedbetween therequirement andthearchitecturalelements. Here,theterm

‘executiontrace’referstothesequenceofstatesinthesuccess- fulexecutionofthearchitecture.Itdiffersfromtheterms‘trace link’and‘tracerelation’thatareusedtodenoteatraceabilitycon- nectionbetweentwomodelelements(e.g.arequirementandan architecturalelement).Thegenerationprocessisfullyautomatic oncethepropertytobeverifiedisprovidedbythearchitect.We limitourselvestoverificationoffunctionalrequirementsonly.Non- functionalrequirementssuchasperformance,real-timeproperties, andothersoftenrequireformalismsandverificationtoolsdifferent thantheonesusedinourwork.

The second mechanism uses the requirements relations togetherwithexisting tracelinks. Weensurethat therelations betweenrequirementsareproperlypreservedintheirimplemen- tationin thearchitecture.This preservation is alsousedin the conceptofsoftwarereﬂexionmodelswhererelationsbetweenele- mentsinhigh-levelmodelsarepreservedintheirimplementations (Murphyetal.,1995).Requirementsrelationsarereﬂectedinthe relationsamongthetracedarchitecturalelements.Basedonanini- tialsetoftracesnewtracesareautomaticallyinferredbyusingthe requirementsrelations.

Thevalidationoftracesalsousesarchitectureveriﬁcationand relationpreservation.Iftheveriﬁcationofarequirementfailsthen theassignedtraces(ifany)maybeinvalid.Similarly,invalidtraces may be present if there is a difference betweenthe manually assignedandthegeneratedtraces.

TheapproachissupportedbyatoolbasedonEclipseModel- ingFramework,theATLmodeltransformationlanguage(Jouault etal., 2008;Jouaultand Kurtev, 2006), and theMaude toolset (Claveletal.,2002,2007).Thetoolprovides:(1)generationand validationoftracesbyusingrequirementsrelationsand/orveriﬁ- cationofarchitecture,(2)generationandvalidationofrequirements relations by using traces. One part of the approach is manual (uses manually assigned traces) and the other part is semi- automaticbecause,whileitstillgeneratestracesautomatically– thesethenneedtoberesolvedbyhumanusersifcontradictions existbetweenthemanuallyassignedandautomaticallygenerated traces.

This paper is structured as follows. Section 2 describesthe approach. Section3 brieﬂy introducestheelements ofrequirements models. This is needed for understanding the trace generationand validation process. Section 4 presentsthe trace metamodel and deﬁnitions of thetracetypes. In Section5, we providetheformalizationofthetracetypes.Section6introduces anillustrativeexampleusedinthefollowingsections.Section7 describesthedetailsofgeneratingandvalidatingtraces.Section8 explainsthetoolsupport.InSection9wegiveabriefdiscussionfor theoverallapproach.Section10presentsasurveyoftherelated work.Section11concludesthepaper.

2. Overviewoftheapproach

Aswealready mentionedthemanualprocessofestablishing tracesis time consumingand errorprone.Theideabehind our approachistostartwithasetofinitialtracesandtograduallyvali- datethemandinfernewtraces.Thevalidationandinferencecanbe appliediterativelyuntilasufﬁcientamountoftraceabilityinforma- tionisachieved.Thesetofinitialtracescanbeeitherautomatically derivedbyexecutingthearchitectureormanuallyassignedbythe architect.

Whiletherearemanyresearchapproachesthatstructureand formalizerequirements,thepracticesofmanysoftwarecompanies arestillbasedontextualrequirementsspeciﬁcations.Furthermore, thearchitectsoftendesignthesoftwarearchitecturebasedonthe requirementswithoutdocumentingthemajordesigndecisionsand designalternatives.Inthisway,valuabletraceinformationislostor remainsincompleteandunreliable.Thishampersthemaintenance andevolutionofthesoftwaresystem.

Ourapproachaimsatimprovingthissituationobservedinthe currentpractices byprovidinga degreeofautomationthatwill maketracegenerationfasterandwillimprovetheprecisionofthe traces.Theprecisionoftracescanbeimprovedintwoways.First, byusingarchitecturalveriﬁcation,wemaydiscovertracesthatoth- erwisewouldbemissedincaseofmanualassignmentandinformal reasoning.Second,byusingtracevalidation,wemayrevealtraces thatarefalsepositivetraces.

Fig.1 givesthe requirementsand architecturalmodels with tracesintheapproach.Weassumethatpartofthestructureof arequirementsdocumentis madeexplicitandrepresentedina requirementsmodel.Inthisrespectwerelyonourpreviouswork (Gokniletal.,2011)onrequirementsmodeling.Itgivesthedetails ontheprocessofextractingmodelsfromrequirementsdocuments andthetoolTRICthatsupportsit.Therequirementsmodelsconsist ofrequirementsandtypedrelationsamongthem.

Tracesare established (automatically or manually) between requirementsmodelsandarchitecturalmodels.Weassumethat thearchitectureisexpressedinamodelinglanguageandwedo notconsidertheprocess(ifany)thatmayguidethedesignofthe architectureandthetransitionfromtherequirementstothearchi- tecture.Intheworstcasetheremaybeinitiallynotraceinformation betweenR&A.

(3)

Fig.1. Requirementsandarchitecturalmodelswithtraces.

We support two types of traces between R&A: satisfies and allocatedTo.The maindifferencebetweenthem ishowtheyare established:satisfiestracesareestablishedautomaticallybasedon architectureverificationandreasoningoverexistingtraces.allocat- edTotracesareusuallyassignedmanuallybythesoftwarearchitect.

Theymaybederivedfromalreadyexistingtracescollectedduring thearchitecturaldesignphase.

Asatisfiestracerelatesasetofarchitecturalelementstoasingle requirement(InFig.1weshowindividuallinksasarrowsandthe setofthetracedelementsaresurroundedbyanoval).Thesetof tracedarchitecturalelementsistheminimalsetthatisresponsi- bleforfulfillingtherequirement.Thesatisfiestracesareestablished afterverifyingtherequirementoverthearchitecturalmodel.The verificationisdonebyreformulatingtherequirementasaformula intemporallogicandcheckingthisformulaintheMaudemodel checker. Thisis possiblebecausetheused architecturalmodels areexpressedinasubsetofAADLthathasexecutablesemantics definedasMaude rewriterules.Iftheformulaevaluatestotrue thentheelementsfromtheexecutiontraceofthemodelchecker areconsideredtosatisfytherequirement.

Ithastobenotedthatsomeapproachesforrequirementstrace- abilityconsidertherelationswithinasinglemodelastraces.For example,therequirementsrelationsreﬁnesandrequiresarecon- sideredasin-modeltraces.Inthispaperwedealonlywithtraces betweenR&A.

Inmanyreallifeprojectsthenumberofrequirementsislarge anditisnotfeasibletoverifyeveryrequirementinthedescribed manner.Thesoftwarearchitectmaychoosetoverifyonlythemost criticalrequirementsandtomanuallyassignthetracesfortherest.

ManuallyassignedtracesareoftypeallocatedTo.Theyexpressthe expectationofthesoftwarearchitectthatacertainsetofarchi- tecturalelementsisresponsibleforfulﬁllingagivenrequirement.

SincetheallocatedTotracesaremanuallyassigned theymaybe invalidand/orincomplete.

Ourapproachsupportsvalidationoftracesbyusingrelations amongrequirements. Fig.1 shows threerequirementsand two relationsamong them:reﬁnesand requires.The meaningofthe supportedrelationsamongrequirementsisexplainedindetailin

Section3.Therelationsamongrequirementshavetobereflectedby therelationsamongthetracedarchitecturalelements.Forexample, ifrequirementR1refinesR3(seeFig.1)thearchitecturalelements thatsatisfyR₁mustbeasubsetofthearchitecturalelementsthat satisfyR₃.Indeed,Fig.1showsthatthis isthecase. Ifthis con- straintisnotfulfilledthentheestablishedtracesareconsidered asinvalid. Ina similarwayifonerequirementrequires another requirementthenthesetsofthetracedarchitecturalelementsmust have anon-empty intersection. Thecompletedefinitions of the constraintsimposedbytherelationsamongrequirementsonthe tracedarchitecturalelementsaregiveninSection7.2.

Theseconstraintscanalsobeusedtoinfernewtracesonthe basisofasetofinitialtracesandthegivenrelationsamongrequire- ments.

In case of detection of invalid traces the software architect needstorevisitthemanuallyassignedtraces andeventually to verifythem.Anotherreasonforinvalidtracesisthattherequire- mentsmodelisnotcorrectandsomeoftheassignedrequirements relationsdonothold.Inthiswayourapproachalsosupportscor- rectionsintherequirementsatalaterstagewhenthearchitecture andthetracesmayrevealinvalidornon-detectedrelationsamong requirements.

These basic mechanisms of automatic generation of satisﬁes traces,tracevalidation,andinferencebasedonrequirementsrela- tions can be combined in various scenarios that the software architectcanfollow.Fig.2givestheoverviewoftheapproachwith inputsandoutputsinthescenarios.

Scenario1. Generatingtracesbyusingveriﬁcationofarchitecture.

Thisscenariotakesthereformulatedrequirement(s)and the architectureasinput.Thereformulatedrequirementsarelogical formulasoverthearchitecture.Theformulasarecheckedbythe Maudemodelchecker.Iftheresultispositive,satisﬁestracesare generated.Ifacounterexampleisfound,allthearchitecturalele- mentsusedinthecounterexampleareconsideredtoberelatedto therequirementwiththeallocatedTotraces.Thesoftwarearchitect shouldinspecttheinputmodelsforerrors.

(4)

T

TrraacceeGGeenneerraattiioonn&&

V Vaalliiddaattiioonn

IInnppuutt R

Reeqquuiirreemmeennttss M Mooddeell R

Reeqquuiirreemmeennttss M Meettaammooddeell

IInnssttaanncceeooff

IInnppuuttTTrraaccee M Mooddeell T

Trraaccee M Meettaammooddeell

IInnppuutt A Arrcchhiitteeccttuurree

M Mooddeell A

Arrcchhiitteeccttuurree M Meettaammooddeell

R Reeqquuiirreemmeennttss

M Meettaammooddeell IInnssttaanncceeooff

T Trraaccee M Meettaammooddeell IInnssttaanncceeooff

E Errrroorr M Meettaammooddeell IInnssttaanncceeooff

R Reeffoorrmmuullaatteedd R Reeqquuiirreemmeenntt

C

Coonnssttrraaiinnttssbbaasseeddoonn S

SeemmaannttiiccssooffTTrraacceess a

anndd RReeqquuiirreemmeennttss R Reellaattiioonnss L

Liinneeaarr T Teemmppoorraall

L

Looggiicc ÊÊx^xp^prreês^ss^seêd^dⁱⁱⁿⁿ

O Ouuttppuutt R Reeqquuiirreemmeennttss

M Mooddeell

O OuuttppuuttTTrraaccee

M Mooddeell

O Ouuttppuutt EErrrroorr

M Mooddeell

Fig.2. Overviewoftheapproach.

Scenario2. Validatingtracesbyusingveriﬁcationofarchitecture.

Inthisscenario,amanuallyassignedsetofallocatedTotraces is checked. The reformulated requirement(s) is veriﬁed in the waydescribedinScenario1.Thevalidationphasecomparesthe assignedtraceswiththearchitecturalelementsintheveriﬁcation output.Theinvalidassignedtracesarereportedintheoutputerror model.

Scenario 3. Generating/validating traces by using requirements relations.

Thisscenario takes therequirementsmodel, an initialtrace model and constraints in Fig. 2 as input. The constraints

specify how therelations among requirementsare reﬂected in thearchitecture.Newtracesareinferredforrequirementswith- outtracesthatarerelatedtorequirementswithassignedtraces.

Therequirementsrelations areusedtoinfernewtraces andto validatetheexistingtraces.Theoutputtracemodelcontainsthe generated traces.Invalid traces arereportedin anoutputerror model.

Scenario4. Generating/Validatingrequirementsrelationsbyusing tracesbetweenR&A.Thisscenarioisconcernedonlywithanalysis oftherequirementsmodelbasedontraceabilityinformation.The relationsamongarchitecturalelementsmayrevealnewrequire- mentsrelations,orthelackofsuchrelationsbetweenthetraced

RequirementsModel -name:String

Requirement -ID:Integer -name:String -description:String -priority:Priority -reason:String -status:Status

1

*

Relationship -name:String 1

-source * 1

-fromSource

-target 1..*

-fromTarget

Refines

Requires PartiallyRefines Conflicts Contains

«enumeration»

Status +proposed +analyzed +accepted +rejected +replaced

«enumeration»

Priority +neutral +lowCritical +critical +veryCritical

Fig.3.Requirementsmetamodel.

(5)

-name:String RequirementsModel

-ID : Integer -name:String -description:String -priority:Priority -reason : String -status:Status Requirement

1

*

-name:String Relationship 1

-source * 1 -target 1..*

Refines

Requires PartiallyRefines Conflicts Contains RequirementsMetamodel

-name:String TraceModel

-id:Integer -isGenerated:Boolean -description:String

Trace 1

*

Satisfies

AllocatedTo TraceMetamodel

-name:String ArchitectureModel

-id:Integer -name:String ArchitecturalElement 1

*

Component ArchitectureMetamodel

1

-subComponents

* 1

*

Fig.4.Tracemetamodelforrequirementsandarchitecture.

requirements.Theoutputrequirementsmodelcontainsthegen- eratedrequirementsrelations.Theoutputerrormodel contains the invalid requirements relations in the input requirements model.

Ingeneral,theidentiﬁedinvalidtracesandnewrequirements relationsare justsuggestionsfor thearchitect.Theyhave tobe checkedbythearchitectfortheﬁnaldecision.

3. Requirementsmetamodel

Therequirementsmodelsinourapproachconformtoameta- modelthatcontainselementscommonlyfoundintheliterature onrequirementsmodeling.Themetamodeldeﬁnesrequirement classwithitsattributesandrelationsbetweenrequirements.We leftoutotherelementssuchasgoals,stakeholders,andtestcases.

Fig.3givestherequirementsmetamodel.

(6)

The requirements are captured in a requirements model. A requirements model contains requirements and their relations.

Basedon(SWEBOOK)wedeﬁnearequirementasfollows:

Deﬁnition1. Requirement:Arequirementisa descriptionof a systempropertyorpropertieswhichneedtobefulﬁlled.

A requirement has a unique identiﬁer (ID), name, textual description,priority,rationale,andstatus.Asystempropertycanbe acertainfunctionalityoranyqualityattribute.Inthisrespect,our requirementsrelationtypesandtheirformalizationareapplicable tobothfunctionalandnon-functionalrequirements.

Weidentifiedfivetypesofrelations:requires,refines,partially refines,contains,andconflicts.Intheliterature,theserelationsare informallydefinedasfollows.

Definition 2. Requires relation: A requirement R1 requires a requirementR₂ifR₁isfulfilledonlywhenR₂isfulfilled.

Definition3. Refinesrelation:ArequirementR₁refinesarequire- mentR₂ if R₁ isderived from R₂ by adding moredetails toits properties.

Thereﬁnedrequirement(R2)canbeseenasanabstractionof thereﬁningrequirement(R₁).

Deﬁnition4. Containsrelation:ArequirementR₁containsrequire- mentsR₂...RnifR₂...RnarepartsofthewholeR₁(part-whole hierarchy).

Thisrelationshipenablesacomplexrequirementtobedecom- posed into parts. A composite requirement may state that the systemshalldoAandBandC,whichcanbedecomposedintothe requirementsthatthesystemshalldoA,thesystemshalldoB,and thesystemshalldoC.Forthisrelation,allpartsarerequiredinorder tofulﬁllthecomposingrequirement.

Definition5. Partiallyrefinesrelation:ArequirementR₁partially refinesarequirementR2 ifR1isderivedfromR2byaddingmore detailstopropertiesofR₂andexcludingtheunrefinedproperties ofR₂.

OurassumptionhereisthatR₂canbedecomposedintoother requirementsand thatR1 reﬁnesa subsetofthesedecomposed requirements.Thisrelationcanbedescribedasaspecialcombina- tionofcontainsandreﬁnesrelations.Itismainlydrawnfromthe decompositionofgoalsingoal-orientedrequirementsengineering (vanLamswerdee,2001).

Definition6. Conflictsrelation:ArequirementR1conflictswitha requirementR₂ifthefulfillmentofR₁excludesthefulfillmentof R₂andviceversa.

Theconﬂictsrelationaddressesacontradictionbetweenrequire- ments.Weconsiderconﬂictsasabinaryrelation.

Thedeﬁnitionsgivenaboveareinformal.Thesemanticsofthe relationsisformalizedinﬁrst-orderlogic(FOL).Thisallowsinfer- ringnewrequirementsrelationsandcheckingtheconsistencyin requirementsmodels.Inthispaperwewillusetheinformaldef- initions givenabove. For thedetailed descriptionof theformal semantics of the requirements and the relations, the reader is referredtoourpreviouswork(Goknil,2011;Gokniletal.,2011).

4. Tracemetamodel

Tracesarecollectedinmodelsthatconformtothetracemeta- modelwhichcontainstwotracetypesSatisﬁesandAllocatedTo.

Fig.4showsthetracemetamodeltogetherwithpartsofrequire- ments and architecture metamodels. We use AADL to specify architecturalmodels.AfragmentoftheAADLmetamodelisgiven inthebottompartofFig.4.

TheAllocatedToand Satisﬁes relationsare deﬁned asfollows (OMG,2010;RameshandJarke,2001;Wasson,2006):

Deﬁnition7. AllocatedTotrace:ArequirementRisallocatedtoa setofarchitecturalelementsEifthesystempropertiesrelatedtoE aresupposedtofulﬁllthesystempropertiesgiveninR.

Thearchitectcantrackwhichcomponentwilltakecareofwhat requirementbyusingAllocatedTotraces(RameshandJarke,2001).

Definition8. Satisfiestrace:AsetofarchitecturalelementsEsat- isfiesarequirementRifthesystempropertiesrelatedtoEfulfillthe systempropertiesgiveninR.

ASatisfiestraceisactuallyanimplicationdependencybetween thesystempropertiesgiven intherequirementand thesystem propertiesdesignedinthearchitecture.Thearchitecturesatisfies therequirementifthefulfillmentofarchitecturesystemproper- tiesimpliesthefulfillmentofthesystempropertiesgiveninthe requirement.

AnAllocatedTotrace is assigned when thefulfillment ofthe requirementisexpected.ASatisfiestraceisassignedorgenerated whenthefulfillmentoftherequirementisassured.

Theliteratureproposesseveraltypesoftraces,whicharesimi- lartoSatisﬁesandAllocatedTobutnameddifferently.Forexample, Khanetal.(2008)proposesixtypesoftraces.Theydifferonlyin thetypeofthesourcerequirement.Inourapproachweabstract themetamodelfromthisdetailthuskeepingonlytheverygeneric typesSatisﬁesandAllocatedTo.

5. Formalizationoftracetypes

AsoftwarearchitecturemodelAMisamodelconformingtothe AADLmetamodel.Fortheformalizationoftracetypesitissufﬁ- cienttoconsiderarchitecturalmodelsassetsofmodelelements.

ThetypesofarchitecturalelementsintheusedsubsetofAADLare System,Process,ThreadGroup,Thread,SubProgram,DataStore,Port, DataAccessandConnector.

TracetypesaresubsetsofCartesianproductsofsets.Wedeﬁne SatisﬁesandAllocatedTotracetypesasfollows:

Satisfies⊆℘(SAE)×SRandAllocatedTo⊆SR×℘(SAE) (1)

PR

P_A Refining

System

Architecture Model-AM

Modeling

Model Checking isa property

of isapropertyof

satisfied+ executiontrace

violated+ counterexample

Fig.5.SchematicviewoftherelationbetweenPRandPA.

(7)

R1 R3 R2

contains contains

R5

requires

R6

requires

refines

requires

R4 refines

requ ires R10

R7

R8 requires refines

partiallyrefines

R9 partiallyrefines

R12 R11

requires

requ ires

Fig.6. PartofrequirementsmodelforRPMsystem.

whereSR isthesetofrequirementsin therequirementsmodel RMand SAEisthesetofarchitecturalelementsinthesoftware architecturemodelAM.℘(SAE)denotesthepowersetofSAE.

TheintuitionbehindtheAllocatedTotracetypeisthatapartof softwarearchitectureisplanned/expectedtobeanimplementa- tionofasetofrequirements.FortheSatisﬁestraceswehavethe followingadditionalconstraint.

LetRbearequirementandE_Abeasetofarchitecturalelements wherePRisaformulathatrepresentsRandP_Aisaformulawhose truthvaluedependsonE_A.WerequirethefollowingfortheSatisﬁes tracetype:

E_ASatisﬁesRiffthefollowingstatementholds:

ThefulﬁllmentofPAimpliesthefulﬁllmentofPR (2)

ForagivenpropertyP_Athatthearchitecturehastosatisfy,we areinterestedinidentifyingthesmallestsetofarchitecturalele- mentsE_AthatareresponsibleforfulﬁllingP_A.ToidentifyE_A,P_Ais expressedinanysuitablelogicsuchasLinearTemporalLogic(LTL)or Computation-TreeLogic(CTL).ThepropertyP_Athuscanbechecked overthearchitecturemodelAMbyusingarchitectureveriﬁcation techniques.

Fig.5givestheschematicviewoftherelationbetweenPRand PA.ThedefinitionoftheSatisfiestracetypeformalizestheintuition thatapartofsoftwarearchitectureisanimplementationofaset ofrequirements.PRisapropertythatthefinaldevelopedsystem mustsatisfy.Asoftwarearchitectureisamodelofsuchasystem thatrevealssomesolutiondesigndecisions.Therefore,P_Rshould bepreservedinthearchitecture.Itisreformulatedintermsofthe architecture,thusobtainingtheformula P_A thatcanbechecked overthearchitecture.P_Aisalsoapropertyofthefinalsystembut expressedinadifferentlevelofabstractioncomparedtoP_R.The architecturalelementsinE_Aarethosethat areintheexecution trace¹ofcheckingP_A.TherefinementofP_RtoP_Aandthemodeling ofthearchitectureareperformedmanually.

Thesoftware architecture model usuallyimplements allthe architecturally significant requirements. Not all requirements haveequalsignificancewithregardstothearchitecture.Accord- ingtoMalanand Bredemeyer(2002), architecturallysignificant

1Theconceptofexecutiontraceisdifferentfromthetraceandtracerelation.An executiontraceisasequenceofstatesintheveriﬁcationofanarchitecture.

requirementsarethosethat(1)captureessentialfunctionalityof thesystem,(2)exercisemanyarchitecturalelements,(3)challenge thearchitecture,(4)highlightidentifiedissues/risks,(5)exemplify stringentdemandsonthearchitecture(e.g.performancerequire- ments),(6)arelikelytochange,and(7)involvecommunication andsynchronizationwithexternalsystems.Everyarchitecturally significantrequirementshouldbesatisfiedandeveryarchitectural elementshouldcontributetoatleastonerequirement.Wedefine theSatisfiesrelationbetweentherequirementsmodelRMandthe architecturemodelAM:

TheArchitectureModelAMsatisﬁestheRequirementsModel RMiffthefollowingtwostatementsholdwhereRisarequire- ment,SARisthesetofarchitecturallysigniﬁcantrequirements intherequirementsmodelRM,AEisanarchitecturalelement andSAEisthesetofarchitecturalelementsinthearchitecture modelAM:

∀AE(AE∈SAE→∃EA∃R(EA∈℘(SAE)∧AE∈EA∧

Satisfies(EA,R))) (3)

∀R((R∈SAR∧¬refined(R))→∃EA(EA∈℘(SAE)∧

Satisfies(EA,R))) (4)

refined(R)istrueiffRisrefinedbyoneormorerequirementsin therequirementsmodel.With(4)weensurethatthemostconcrete requirementsarealwayssatisfiedbythesoftwarearchitecture.

6. Example:RemotePatientMonitoringsystem

TheapproachoutlinedsofarwillbeillustratedwiththeRemote PatientMonitoring(RPM)systemexample.RPMwasdevelopedby acompanyintheNetherlandsandhadalreadybeenimplemented andrunningwhenwestartedstudyingthesystem.TheRPMsys- temhasthefollowingstakeholders:patients,doctors,andthesystem administrator.Themaingoalistoenablemonitoringthepatients’

conditionssuchasbloodpressure,heartrate,andtemperature.For instance,apatientcarriesasensorformeasuringthebodytemper- atureandthevaluesaretransmittedtoacentralsystemwherethey arestored.

Inordertoapplyourapproach,wemodeledthetextualrequire- ments in the RPM requirements document and their relations accordingtothesemanticsoftherelationtypes.Therequirements modelwascreatedinTRIC,ourtoolfor requirementsmodeling

(8)

andinference(seeTRIC).SomeoftherequirementsforRPMcan befoundinAppendixA.Here,twoexamplesareshown:

Requirement6requiresRequirement3.

Requirement3. Thesystemshallmeasurebloodpressureandtem- peraturefromapatient.

Requirement6. Thesystemshallstoredatameasuredbysensorsin thecentralstorage.

Fig.6showstherelevantpartoftherequirementsmodel.

Thesolidarrowsindicatetherelationsgivenbytherequire- mentsengineer.For simplicity,wedidnotincludetherelations inferredbyTRIC.Weconstructedthearchitectureofthesystem byreverseengineeringthesourcecode.Fig.7givestheoverview of the RPM architecture in AADL visual syntax. The complete explanationof theabbreviationsof thecomponentsis given in AppendixB.

Fig.7shows themostabstractcomponents(systemandpro- cessinAADL).Thesecomponentscontainothercomponentswhich arenotrepresentedinFig.7.TheSD(SensorDevice)component containsthesensorscarriedbythepatient.Thesensorsperform measurementsataregularinterval. TheSDsendsthemeasure- mentstotheHPC(HostPersonalComputer)component through theSDC(SensorDeviceCoordinator).TheSDCistheZigBeenetwork coordinator.Thedetailsofthecoordinatingtasksareomittedinthe description.TheHPCconsistsoftheSDM(SensorDeviceManager),AS (AlarmService)andWS(WebServer)processsubcomponents.The SDMstoresthemeasurementsandgeneratedalarmsinthedata stores(TempalarmsandTempMeasfortemperaturealarmsand measurements).TheWSservesasaweb-interfaceforthedoctors.

TheASforwardsthealarmstotheCPC(ClientPersonalComputer) component.TheCPCisusedbythedoctorstomonitorpatients.

TheAR(AlarmReceiver)processintheCPCreceivesthealarmsfrom theASandnotiﬁesthedoctoraboutthealarms.TheWC(WebClient)

process uses theWS to retrievethe measurementsand alarms storedbytheSDM.

Fig.7showsonlysystemsandprocessesintheRPMarchitecture.

AADLprovidesalso supportfor threadand subprogram compo- nents.Thecomputationofthesystemismodeledassubprogram andthreadbehavior.ThecurrentversionoftheAADLsemantics (Ölveczkyetal.,2010a;Ölveczkyetal.,2010b)inMaudeallows modelingsubprogramandthreadbehaviorbyusingAADL’sbehav- ioralannexwithaﬁnitesetofstatesandasetofstatevariables.The RPMarchitecturehasbehavioralannexesfordynamicbehaviorof threadsineachsystemcomponent.

Thefollowingpresentstheimplementationofthethreadinthe SDMcomponent(SDMThread)forstoringbloodpressuremeasure- ments.It shows atransition systemwithstatevariables where each transition contains a guard ([sdmbloodedp2?(inMessage)]

in line 17) on the existence of events/data in the input ports (sdmbloodedp2inline17),andonthevalueofthedatareceived (inMessageinline17).

1 thread SDM_Thread 2 features

3 sdm_blood_edp2: in event data port Behavior::integer;

4 sdm_blood_strg: out event data port Behavior::integer;

5 properties

6 Dispatch_Protocol => aperiodic;

7 end SDM_Thread;

8

9 thread implementation SDM_Thread.i 10 annex behavior_specification {**

11 states

12 s0: initial complete state;

13 bloodStored: complete state;

14 state variables

15 inMessage: Behavior::integer;

16 transitions

17 s0 -[sdm_blood_edp2?(inMessage)]-> bloodStored { sdm_blood_strg!(inMessage); };

18 **};

19 end SDM_Thread.i;

ThethreadabovehaseventdataportsSDMBLOODEDP2inline 3andSDMBLOODSTRGinline4forbloodmeasurements.Since theDispatchProtocolofthethreadis aperiodic(seeline6),this threadisactivateduponreceivinginput.Thethreadhass0asthe initialstate(line12)andbloodStoredasthecompletestate(line13).

Ifthethreadisinthes0stateandreceivesthemeasureddataat theSDMBLOODEDP2eventdataport, thenthereceiveddatais storedintheSDMBLOODSTRGdataportandthebloodStoredstate isreached(line17).

7. Generatingandvalidatingtraces

Afterexplainingpartsoftherequirementsmodelandthearchi- tectureofRPM wecanshowanapplicationofourapproachfor generationandvalidationoftraces.Section7.1explainsthever- iﬁcationoffunctionalrequirements.Section7.2givesthedetails

(9)

Fig.7. OverviewoftheRPMarchitecture.

aboutthetracegenerationby usingrequirementsrelations and veriﬁcationresults;Section7.3presentsthetracevalidation.

7.1. Veriﬁcationoffunctionalrequirements

The purpose of the verification is to check if requirements arecorrectlyimplementedinthearchitecture.Verificationresults serveasaninputforbothtracegenerationandtracevalidation activities(Scenarios 1and 2 inSection 2).Fig.8 illustratesthe verificationoffunctionalrequirements.

Arequirementunderverification isreformulatedasaformal descriptionoftherequiredbehaviorofthearchitecture(reformulate andusesinFig.8).Therequirementisfirstdescribedasaformalized scenario,andthendescribedasapropertyspecification(Boudiaf etal.,2008;Pelliccioneetal.,2009;Postetal.,2009).Theformalized scenarioisapairofpredicates<pre,post>encodingtheprecondition prethat isfulfilledbeforetheexecutionofthescenarioandthe postconditionpostthatisexpectedtobefulfilledaftertheexecution ofthescenario.ThepropertyspecificationisexpressedasanLTL formulathatcanbeevaluatedbytheMaudemodelchecker.

The availability of a dynamic semantics of AADL makesthe architecturalmodelsexecutable.Weusetheformalsemanticsof behavioralAADLmodelsinMaudeimplementedbyÖlveczkyetal.

(2010a,b).Theexecutionisasimulationofthesystemtobebuiltat thearchitecturallevel.Thearchitectureisexecutedfortheformal- izedscenarioandastatespaceisproduced(simulateinFig.8).Inour exampleastatedescribesthelociofdatavalueswithinthearchi- tecture.Anexecutiontraceisthesetofstatesandstatetransitions whicharegeneratedifthereformulatedrequirementissatisﬁed.

Counterexampleisthesetofstateswhicharegeneratedwherethe reformulatedrequirementisnotsatisfied.Alltheusedarchitectural elementsinanexecutiontraceareconsideredcollectivelyrespon- sibleforfulfillingarequirement.Therefore,theyaretheelements forwhichaSatisfiestracewillbeestablished.

Example. ReformulationofRequirements Considerthefollowingrequirement

Requirement5Thesystemshallstorepatientbloodpressuremea- suredbythesensorinthecentralstorage.

Fig.9isthepartoftheRPMarchitecturedevelopedforthesys- tempropertygiveninRequirement5.

Requirement 5 is reformulated as a formalized scenario as follows:

Formalized Scenario: (contains(SDBLOODEDP1, DI)), (contains(SDMBLOODSTRG,DI))

ThescenariostatesthatifthedatainstanceDIiscontainedbythe dataportSDBLOODEDP1ofSensor2(SDcomponentinFig.7),then

thedatainstanceDIisstoredinthedatastoreSDMBLOODSTRGof thecomponentSDMafterexecutingthearchitecture(seeFig.7).

The dynamic behavior of a threadis deﬁned in AADLusing AADL’sbehavioral annexwithaﬁnite setof statesand asetof statevariables.IntheRPMarchitecture,thesubprogramexecu- tionforstoringthebloodpressuredatainthecentralstorageis implementedasastatetransitionsysteminthethreadsdmTh(see Section6).ThesdmThthreadhasstatesbloodStored,temperature- Stored,highTemperature,lowTemperatureandidle.Whenthedata instanceDIisstoredinthedatastoreSDMBLOODSTRGofthecom- ponentSDM,thestateofthesdmThthreadinthestatetransition systemissettothebloodStoredstate.

The formalized scenario is the ﬁrst step toreformulate the requirementintermsofthearchitecture.Thenextstepistocon- structtheappropriateLTLformula.Theformulaisthefollowing:

LTL formula in Maude: (mc initializeThreads({MAIN system Wholesys. imp}) |=u<>((MAIN->hpc->sdm->sdmTh) @ blood- Stored).)

TheformulastatesthatifthedatainstanceDIiscontainedbythe dataportSDBLOODEDP1ofSensor2,theneventuallyinthefuture thestateinthestatetransitionsysteminthesdmThthreadisset tothebloodStoredstate(thedatainstanceDIisstoredbythedata storeSDMBLOODSTRGoftheSDMcomponent).Pleasenotethat thedatainstanceDIiscreatedintheinitialstatebyatestthreadin theRPMmodel.Therefore,theLTLformuladoesnotexplicitlyindi- catethedatainstanceDIandthedataportSDBLOODEDP1ofSensor 2.TheinitializeThreads({MAINsystemWholesys.imp})intheformula createstheinitialstate.MAIN->hpc->sdm->sdmThdenotesthe fullcomponentnameofthesdmThthreadcomponent.The@blood- StoredstatesthatthestateofthesdmThthreadisthebloodStored.

The‘<>’intheLTLformulastates‘eventuallyinthefuture’.TheLTL formulacanbecheckedonthegeneratedstatespaceinMaude.The formulaexempliﬁesthepropertyP_AinFig.5.

7.2. Generatingtraces

Accordingtothedeﬁnitionof tracetypes,a Satisﬁestraceis generated betweenthe architectural elementsin theexecution traceandtherequirementthatissuccessfullychecked.Acounter examplemeansthatalthoughtherequirementisallocatedtothe architectural elements, i.e.,theyareinvolved in theimplemen- tation of this requirement,the architecture doesnot satisfy it.

AllocatedTotracecan begenerated but theSatisﬁestraceis not present.

WemodiﬁedthetransitionrulesinMaudetobeabletorecord thearchitecturalelementsmatchedandaffectedbythetransition rules.Theserecordedelementsbelongtotheexecutiontraceand formthesetE_Ausedinthedeﬁnitionofthetracelinktypes.The

(10)

Fig.8.Veriﬁcationoffunctionalrequirements.

modiﬁcationaddsanattributecalledUsedtothecomponentclasses intheAADLmetamodel.EachtransitionrulesetstheattributeUsed ofthematched/affectedarchitecturalelementtotrue.

ThesearchcommandoftheMaudemodelcheckerreturnsan executiontraceiftherequirementissatisfied.Theremightbemul- tipleexecutiontracesinwhichtherequirementissatisfied.Inthis case,theSatisfiestraceisgeneratedfortheusedarchitecturalele- mentsineachexecutiontrace.

Thesecondwaytogeneratetracesistousetherequirements relations(seeScenario3 inSection2).Wedeﬁned severalcon- straintsthatspecifyhowarelationbetweentworequirementsis reﬂectedinthearchitecture.TheconstraintsareshowninFig.10.

Theyarealsousedtogeneraterequirementsrelationsfromtraces (seeScenario4inSection2).InFig.10,alltheconstraintsaregiven fortheSatisﬁestraces.Thesameconstraintsarealsovalidforthe assignedAllocatedTotraces.

Fig.10(a)postulatesthattheintersectionofthetracedarchi- tectural elements for two requirements is non-empty if one requirementrequiresanother.Fig.10(b)illustratesthatthearchi- tecturalelementsthatsatisfyarefiningrequirementalsobelongto thesetofarchitecturalelementsthatsatisfiestherefinedrequire- ment.ConstraintssimilartotheoneinFig.10(b)arevalidfortraces withtheContainsandPartiallyRefinesrelations(seeFig.10(c)and (d)).

InordertogeneratetheSatisfiestracesforR1inFig.10(b),(c) and(d),allotherrequirements(R₂,R₃,...,R_k)shouldbesatisfiedby thearchitecture.Forinstance,ifoneoftherefiningrequirements (R2,R3,...,R_k)in Fig.10(d)is notsatisfiedbythearchitecture, therefined requirement(R1) is not satisfiedeither. Thepartial refinementmightnotbecomplete(Fig.10(d)).Inthiscase,even ifallrefiningrequirementsaresatisfied,theSatisfiestraceisgen- eratedonlyifitisconfirmedthattheunrefinedpropertiesarealso satisfied.TheSatisfiestracefor theunrefinedpropertiesinR₁ is establishedbyverification.

Example. GenerationofTracesbyUsingVeriﬁcationofArchitecture InSection7.1,wegaveanexamplereformulationofarequire- mentaspropertyspeciﬁcationinMaude.Weshowhowtogenerate tracesforRequirement5(seeScenario1).TheLTLformulais:

LTL formula in Maude: (mc initializeThreads({MAIN system Wholesys.imp}) |=u<>((MAIN-> hpc->sdm ->sdmTh) @blood- Stored).)

Afterrunningthemodel checker, the formula istrue which meansthat Requirement5 is satisﬁed bythe architecture.The searchcommandreturnsanexecutiontraceforRequirement5:

SearchCommandinMaude:

(utsearch[1]

initializeThreads({MAINsystemWholesys.imp})=>*{C:Conﬁguration}

suchthat

((locationofcomponent(MAIN->hpc->sdm->sdmTh)in C:Conﬁguration)==bloodStored.)

In the utsearch command above, the initializeThreads({MAIN systemWholesys. imp}) createsthe initialstate where thedata instanceDIiscontainedbythedataportSDBLOODEDP1ofSen- sor2.The(locationofcomponent(MAIN->hpc->sdm->sdmTh) inC:Conﬁguration)returnsthestateinthetransitionsysteminthe sdmThthread,which shouldbethebloodStoredstate(‘==blood- Stored’).‘=>*’inthecommandindicatestheformoftherewriting prooffromtheinitialstateuntilthestatewherethestateinthetran- sitionsysteminthesdmThthreadisthebloodStoredstate.Then,the utsearchcommandtriestoreachthatstatefromtheinitialstate.

Theﬁeldusedofthearchitecturalelementsmatchedbythetran- sitionrulesissettotrueinthelaststateofthecounterexample.

OurtoolgeneratestheSatisﬁestracelinksbetweenRequirement5 andthearchitecturalelementsusedintheexecutiontrace.Fig.11 showsthegeneratedSatisﬁestracelinksforRequirement5.

Theveriﬁcationresult,andthereforethetraces,dependsonthe reformulationoftherequirementtobechecked.Misinterpretation

Fig.9.PartoftheRPMarchitecture.

(11)

Fig.10.Constraintsbasedonsemanticsoftracesandrequirementsrelations.

oftherequirementandwrongreformulationarecausesforpoten- tialfalsepositiveandmissedtraces.Incaseofcorrectmodelsand correctreformulation,thegeneratedtracesaretheactualtraces.

Tracescanalsobegeneratedbyusingveriﬁcationofarchitecture andrequirementsrelations(seeScenarios1and3).Considerthe followingexamplefortheRPMsystem.

Example. GenerationofTracesbyUsingVeriﬁcationofArchitecture andRequirementsRelations

WeﬁrstgeneratetracelinksforRequirement4.

Requirement4Thesystemshallstorepatienttemperaturemeasured bythesensorinthecentralstorage.

InthemodelinFig.6,Requirement4andRequirement5reﬁne Requirement6.

Requirement6Thesystemshallstoredatameasuredbysensorsin thecentralstorage.

Basedontheconstraintsin Fig.10,thesetof thegenerated Satisﬁestraces forRequirement6 isthe unionof thetracesets forRequirement4andRequirement5.Fig.12showsthegener- atedSatisﬁestracesforRequirement6byusingtherequirements relations.

The following exampleillustrates thegeneration of require- mentsrelationsbyusingtraces(Scenario4).

Example. GenerationofRequirementsRelationsbyUsingTraces Considerthefollowingrequirements.

Requirement4Thesystemshallstorepatienttemperaturemeasured bythesensorinthecentralstorage.

Requirement12Thesystemshallenablethedoctortoretrieveall storedtemperaturemeasurementsforapatient.

Inthepreviousexample,wealreadystatedthatRequirement4 issatisfiedbythearchitecture.Itcanbeshownthatthearchitecture alsosatisfiesRequirement12.TheSatisfiestracelinksaregenerated forRequirement12accordingly.

Fig.13showsthenon-emptyintersectionoftracesforRequire- ment4andRequirement12.BasedontheconstraintsinFig.10, there mightbea RequiresrelationbetweenRequirement4 and Requirement12.Thepresenceofsuchrelationshouldbedecided bytherequirementsengineer. Inourexamplewecanconclude thatRequirement12requiresRequirement4sinceitisnotpossible toobtainanydata(Requirement12)iftheyhavenotbeenstored beforethat(Requirement4).

(12)

satisfies

R5

sd_blood_edp1

sd_blood_edp3 sd_blood_edp4 sdc_blood_edp1 sdc_blood_edp2

sdc_blood_edp4 sdc_blood_edp6

sdcThr

sdm_blood_edp1

sd_blood_edp2 sdThr sdc_blood_edp3 sdc_blood_edp5

hpc_blood_edp1

sdm_blood_strg sdm_blood_edp2

EA5

Satisfies(EA5, R5)

sdmThr

Fig.11.Generated‘Satisﬁes’traceforrequirement5byusingveriﬁcationresults.

Itshouldbenotedthatanon-emptyintersectionoftracesdoes notalwaysleadtorequiresrelation.Thefulﬁllmentoftworequire- mentsmayrelyona commonfunctionalityof thesystem.This commonlyusedfunctionalitywillbethendemonstratedbycom- montracedelementsinthearchitecture.

7.3. ValidatingTraces

Validationoftracesaimsatidentifyingthetraceswhichdonot obeythetracesemanticsandtherelatedconstraints.Thishelpsto eliminatefalsepositivetracesandtodetectmissingtraces.Inaddi- tion,aviolationoftheconstraintsinFig.10mayindicateinvalid relationsamongrequirements.Theserelationsneedtoberecon- sideredbytherequirementsengineerandthesoftwarearchitect.

Validationbasedonrequirementsrelationscanbeusedintwo ways (seeScenarios 3and 4).First, thearchitectmay conclude that aninvalid traceisa truepositive and then hereconsiders therequirementsrelations(Scenario4).Second,thearchitectmay concludethatrequirementsrelationsareallvalid,andthenhe/she identiﬁestheinvalidtraces(Scenario3).

Ourapproachalsoprovidesvalidationoftracesbyusingveri- ﬁcationresults(Scenario2).Thisappliestothemanuallyassigned AllocatedTotraces.TheassignedAllocatedTotracesandthegener- atedSatisﬁestracesforarequirementarevalidatedbasedonthe comparisonoftracesinFig.14.

R

4

satisfies satisfies

R

5

sdThr sdcThr sdmThr

sd_blood_edp1

E

_A4

E

_A5

Satisfies(E

A4

, R

4

) Satisfies(E

A5

, R

5

)

E

A6

R

6

refines refines

satisfies

Satisfies(E

A6

, R

6

) E

A6

= E

A4

U E

A5 sd_blood_edp2

sd_blood_edp3 sd_blood_edp4 sdc_blood_edp1 sdc_blood_edp2 sdc_blood_edp3 sdc_blood_edp4 sdc_blood_edp5 sdc_blood_edp6 hpc_blood_edp1 sdm_blood_edp1

sdm_blood_edp2 sdm_blood_strg sd_temp_edp1 sd_temp_edp2

sd_temp_edp3 sd_temp_edp4 sdc_temp_edp1 sdc_temp_edp2

sdc_temp_edp3 sdc_temp_edp4 sdc_temp_edp5 sdc_temp_edp6

hpc_temp_edp1

sdm_temp_edp1 sdm_temp_edp2

sdm_temp_strg

Fig.12. Generated‘Satisﬁes’tracesforrequirement6byusingrequirementsrelations.

(13)

R

4

satisfies satisfies

R

12

sdmThr sd_temp_edp1

sdm_temp_edp1

wc_temp_req_edp1

E

A4

E

A12

Satisfies(E

_A4

, R

₄

) Satisfies (E

_A12

, R

₁₂

)

requires ?

sd_temp_edp2 sd_temp_edp3 sd_temp_edp4 sdc_temp_edp1 sdc_temp_edp2 sdc_temp_edp3 sdc_temp_edp4 sdc_temp_edp5 sdc_temp_edp6

hpc_temp_edp1 sdm_temp_edp2

sdm_temp_strg

sdThr

sdcThr

wc_temp_req_edp2

cpc_temp_req_edp1

cpc_temp_req_edp2 wc_temp_req_edp3

wc_temp_req_edp4

hpc_temp_req_edp1

hpc_temp_req_edp1 ws_temp_req_edp1

ws_temp_req_edp2 ws_temp_req_edp3

ws_temp_req_edp4 wsThr

wcThr

Fig.13. Generated‘Requires’relationforrequirement4andrequirement12.

•If(GST\AAT)isnon-empty,theneithersomeofthegenerated Satisﬁestraces(GST\AAT)arefalsepositivesorsomeofthetraces aremissedwhileassigningtheAllocatedTotraces.Falsepositive Satisﬁestracesin(GST\AAT)maybecausedbymisinterpretation oftherequirementand/orwrongreformulation.

•If(AAT\GST) is non-empty,then either someof the assigned AllocatedTotraces(AAT\GST)arefalsepositivesorsomeofthe SatisﬁestracesaremissedwhilegeneratingtheSatisﬁestraces.

Again,amisinterpretationoftherequirementandwrongreform- ulationmaycausemissingSatisﬁestraces.

Fortherequirementswhicharenotsatisﬁedbythearchitecture, theAllocatedTotracesaregeneratedfromthecounterexample.The assignedandgenerated AllocatedTotracesforarequirementare

validatedbasedonthecomparisonoftracesin Fig.15 whichis similartothecomparisontableinFig.14.

Thesoftwarearchitectshouldcheckthedifferenceofthesets (GAT\AATandAAT\GAT)andconcludeaboutthevalidityoftraces.

Thefollowing isan exampleofvalidation of tracesbyusing veriﬁcationofarchitecture(seeScenario2).

Example. ValidationofTracesbyUsingVerificationofArchitecture TheexampleinSection7.2showsthegeneratedSatisfiestraces forRequirement5.Fig.16showsthegeneratedSatisfiesandthe initiallyassignedAllocatedTotracesforRequirement5.

ThetracesinFig.16arevalidatedaccordingtotheVenndiagram in Fig. 14. Although Requirement5 is allocated to thecompo- nentsASand CPCAR,thesecomponentsarenotinvolved inthe

Fig.14.Venndiagramforgenerated‘Satisﬁes’andassigned‘AllocatedTo’tracesforarequirement.

(14)

Fig.15.Venndiagramforgeneratedandassigned‘AllocatedTo’tracesforarequirement.

Satisﬁestraces.WeconcludedthatthetwoinitiallyassignedAllo- catedTotracestothecomponentsASandCPCARarefalsepositives.

Thefollowingistheexamplewheretherequirementsrelation isidentiﬁedinvalidbasedontheconstraintsinFig.10(seeScenario 4).

Example. ValidationofRequirementsRelationsbyUsingTraces Fig.17showstheassignedAllocatedTotracesforRequirement 10andRequirement6.Intherequirementsmodel,Requirement10 reﬁnesRequirement6(seeFig.6).

Requirement6Thesystemshallstoredatameasuredbysensorsin thecentralstorage.

Requirement10 Thesystemshallstoreallgeneratedtemperature alarmsinacentraldatabase.

Basedontheconstraintsandbyanalyzingrequirements, we concludedthattheReﬁnesrelationbetweenRequirement10and Requirement6isinvalid.Indeed,storingatemperaturealarmis differentthanstoringadataaboutthepatientcondition.Alarms arenotconsideredasmeasureddata.

Removalof theReﬁnesrelationautomaticallyremoves some inferredrequiresrelationsintherequirementsmodel(seeGoknil etal.,2011forinferringrequirementsrelations).Here,wedonot illustratetheupdateoftherequirementsmodelinFig.6.

Forthevalidationoftracesandrequirementsrelationsforcases likewehaveinFigs.16and17,ourtoolgivesthetracesandrequire- mentsrelationswhichdonotobeytheconstraints.Thearchitect shoulddecidethateitherthetracesortherequirementsrelations areinvalid.

AllocatedTo

sd_blood_edp1

E

_{A5_A}

Satisfies(E

A5_S

, R

5

) AllocatedTo(R ,

₅

E

_{A5_A}

) R

₅

Satisfies

as

cpc_ar

E

A5_S

sd_blood_edp2 sd_blood_edp3 sd_blood_edp4 sdThr

sdc_blood_edp1 sdc_blood_edp2 sdc_blood_edp3 sdc_blood_edp4 sdc_blood_edp5 sdc_blood_edp6 sdcThr hpc_blood_edp1

sdm_blood_edp1 sdm_blood_edp2 sdm_blood_strg sdmThr

Fig.16.Generated‘Satisﬁes’andassigned‘AllocatedTo’tracesforrequirement5.

(15)

AllocatedTo

EA10 EA6

AllocatedTo(EA10,R10) AllocatedTo(R6,EA6) R6

R10

AllocatedTo

refines

sd_temp_edp1 sd_temp_edp2 sd_temp_edp3 sd_temp_edp4

sdThr

sdc_temp_edp1 sdc_temp_edp2 sdc_temp_edp3 sdc_temp_edp4 sdc_temp_edp5 sdc_temp_edp6

sdcThr

hpc_temp_edp1 sdm_temp_edp1 sdm_temp_edp2

sdmThr

sdm_temp_strg sd_blood_edp1 sd_blood_edp2 sd_blood_edp3 sd_blood_edp4 sdc_blood_edp1 sdc_blood_edp2 sdc_blood_edp3 sdc_blood_edp4 sdc_blood_edp5 sdc_blood_edp6 hpc_blood_edp1

sdm_blood_edp1 sdm_blood_edp2 sdm_blood_strg sd_temp_alarm_edp1 sd_temp_alarm_edp2

sd_temp_alarm_edp3 sdc_temp_alarm_edp1 sdc_temp_alarm_edp2 sdc_temp_alarm_edp3 sdc_temp_alarm_edp4 sdc_temp_alarm_edp5

sdc_temp_alarm_edp6 hpc_temp_alarm_edp1 sdm_temp_alarm_edp1 sdm_temp_alarm_edp2

sdm_temp_alarm_strg

Fig.17. Assigned‘AllocatedTo’traceswithaninvalidrequirementsrelation.

8. Toolsupport

Webuiltatoolthatsupportsourapproach.Thetoolwasdemon- stratedinECMFA-TraceabilityWorkshop(ECMFA-TW2010)andis describedin(Gokniletal.,2010).Thissectionismainlybasedon (Gokniletal.,2010).InSection8.1,wedepicttheusageofthetool inthecontextofaprocessformodelingrequirementsandarchi- tecture.Section8.2givesthearchitectureofthetoolanditsmain features.Section8.3evaluatesthetool.

8.1. Themodelingprocess

Fig.18givesaUMLactivitydiagramoftheprocess.

TheprocessinFig.18consistsofthefollowingactivities:

8.1.1. Modelingrequirementsanddesigningarchitecture

Thisactivitytakestherequirementsdocumentand produces theinputrequirementsmodel,inputarchitecturemodelandinput trace model. The software architect assigns someinitial traces betweenrequirementsandarchitecture.Itisamanualactivity.

Themodelingprocessisseparatedintothreeactivities:reformulatingrequirements,generatingtraceandvalidatingtrace.

8.1.2. Reformulatingrequirements

Thesoftwarearchitectmanuallyreformulatesrequirementsin termsoflogicalformulas.

8.1.3. Verifyingarchitecture

Theactivitycheckswhethertherequirementsaresatisﬁedby thearchitecture.ItisdoneautomaticallyinMaude.

8.1.4. Generatingtrace

Itisanautomatedactivity.Ifonlyrequirementsrelationsand initialtracesareused,theactivityisperformedaftertheactivity modelingrequirements&designingarchitecture.

8.1.5. Validatingtrace

Thisactivitytakestheinputtracemodel,requirementsmodel, architecturemodelandproducesanoutputerrormodel.Theactiv- ityisautomatic.However,theinterpretationoftheerrorsinthe tracemodelshouldbedonemanuallybythesoftwarearchitect.

The process in Fig. 18 is iterative. The requirements engi- neerand/orthe softwarearchitectmayreturn tothemodeling requirementsanddesigning architectureactivityinorder toﬁx requirementsrelations,traces,andthearchitecture.Ifthereisno needtoupdatethemodels,theprocessisterminated.

8.2. Toolarchitecture

Thetoolcontainsﬁvecomponents(roundedboxesinFig.19):

(a)ModelCheckerpartofMaudetoolset,(b)TraceGeneratorusing VeriﬁcationResultsinATL,(c)TraceGeneratorusingRequirements RelationsinATL,(d)TraceValidatorusingATL,and (e)Require- mentsRelationGeneratorusingTracesinATL.

8.2.1. ModelcheckerinMaude

Theveriﬁcation and simulationare performedbythemodel checkerand theruleexecution engineof Maude. Thearchitec- turalmodeloriginallyexpressedinAADListransformedtoaMaude term(Moment2-AADL).TheAADLmetamodelisencodedasaset ofsorts.ThedynamicsemanticsofAADLisgiveninrewritingrules (Ölveczkyetal.,2010a,b).

8.2.2. TracegeneratorusingveriﬁcationresultinATL

Theinputofthecomponentistheexecutiontraceandcounter example.ThecomponentisimplementedasanATLtransformation.

8.2.3. TracegeneratorusingrequirementsrelationsinATL

TheinputofthecomponentistheInputArchitectureModel,the InputTraceModel,andtheInputRequirementsModel.Thecompo- nentisimplementedasanATLtransformation.Itgeneratesnew tracesbasedontherequirementsrelationsandtheconstraintsin Fig.10.

(16)

Fig.18.Modelingprocesswithtracegenerationandvalidation.

Torepresenttheoutputofthetwotracegeneratorcomponents, weusetwodifferentoutputtracemodelsinordertostatethatthe outputsdonothavetobethesame.

8.2.4. TracevalidatorinATL

TheinputofthecomponentistheInputArchitectureModel,the InputTraceModel,andtheInputRequirementsModel.Thecompo- nentchecksthevalidityofassignedtracesbetweenR&Abyusing veriﬁcationoutputorrequirementsrelations.Itcanalsocheckthe validityofrequirementsrelationsbyusingtracesbetweenR&A.

8.2.5. RequirementsrelationgeneratorusingtracesinATL

Thecomponentgeneratesnewrequirementsrelationsbasedon tracesintheInputTraceModel.

Themostimportantfeaturesofthetoolareverifyingarchitecture, displayinggeneratedtraces,anddisplayinginvalidtraces.

8.2.6. Verifyingarchitecture

WeusetheOpen-Source AADLToolEnvironment (OSATE)– Topcased which includes an AADL front-end and architecture

analysis capabilities as plug-ins. The plug-in (Moment2-AADL) developedbyArturBoronatisusedtogenerateMauderepresenta- tionofAADLmodelswhichcanbesimulatedandveriﬁed.Fig.20 showstheOSATE-TopcasedwithAADL-Maudeplugin.

8.2.7. Displayinggeneratedtraces

WeuseEclipsemodeleditor(seeFig.21)todisplaytheOutput TraceModel.

8.2.8. Displayinginvalidtraces

TheoutputerrormodelofvalidatingtraceactivityinFig.18is displayedintheEclipsemodeleditor(seeFig.22fortheoutput tracemodel).

InFig.22theright-handsideofthewindowshowstheOutput ErrorModel.Themodelcontainsrequirementsandrequirements relationswhichcausetheinvalidityinthetracemodel.Thearchi- tecturalelementstracedfromtherequirementsintheerrormodel canbereachedinthetracemodelinFig.21.

(17)

T

TrraacceeGGeenneerraattiioonn&&VVaalliiddaattiioonn

IInnppuuttTTrraaccee M Mooddeell

IInnppuutt R

Reeqquuiirreemmeennttss M Mooddeell

IInnppuutt A

Arrcchhiitteeccttuurree M Mooddeell

O

OuuttppuuttEErrrroorr M Mooddeell R

Reeffoorrmmuullaatteedd R

Reeqquuiirreemmeenntt MMooddeell C Chheecckkeerriinn

M Maauuddee

A

ArrcchhiitteeccttuurreeMMooddeellwwiitthh E

ExxeeccuuttiioonnTTrraacceeoorr C

Coouunntteerr EExxaammppllee

T

Trraaccee GGeenneerraattoorr uussiinngg V

VeerriiffiiccaattiioonnRReessuullttiinn A

ATTLL

T

TrraacceeGGeenneerraattoorr u

ussiinnggRReeqquuiirreemmeennttss R

ReellaattiioonnssiinnAATTLL

R

ReeqquuiirreemmeennttssRReellaattiioonn G

Geenneerraattoorruussiinngg T

TrraacceessiinnAATTLL T

Trraaccee VVaalliiddaattoorr iinnAATTLL

O

OuuttppuuttTTrraaccee M Mooddeell22

O Ouuttppuutt R

Reeqquuiirreemmeennttss M Mooddeell O

Ouuttppuutt TTrraaccee M Mooddeell 11

Fig.19.Overviewofthetoolarchitecture.

Fig.20.OSATEwithAADL-Maudeplugin.