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

(1)

ContentslistsavailableatScienceDirect

The

Journal

of

Systems

and

Software

jo u rn al h om epa 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

a_AOSTE_Research_Team,_INRIA,_Sophia_Antipolis,_France

b_Nspyre,_{Dillenburgstraat}_25-3,₅₆₅₂_AM_Eindhoven,_The_Netherlands

c_Software_Engineering_Group,_University_of_Twente,₇₅₀₀_AE_Enschede,_The_Netherlands

a

r

t

i

c

l

e

i

n

f

o

Articlehistory:

Received2August2012

Receivedinrevisedform2October2013

Accepted2October2013

Available online 24 October 2013 Keywords:

Tracegenerationandvalidation

Requirementsmetamodel

Tracemetamodel

Softwarearchitecture

a

b

s

t

r

a

c

t

Thesizeandcomplexityofsoftwaresystemsmakeintegrationofthenew/modifiedrequirementstothe 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.ThetoolisbasedonmodeltransformationinATLand term-rewritinglogicinMaude.

1. Introduction

Today’ssoftwaresystemsarecomplexartifactsoftendeployed inahighlydynamiccontext.Therequirementsofsoftwaresystems changecontinuouslyandnewrequirementsemergefrequently.In ordertoreduce thecostfor implementingtherequired system changes,itisimportanttoapplychangemanagementasearlyas possibleinthesoftwaredevelopmentcycle.Requirements traceabil-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 theirarchitecturaldesigndecisionsontheessentialsystem require-mentsthusmakingdirectrelationsbetweentherequirementsand thearchitecture.Inadditiontothat,inmanycasesasoftware archi-tectureexpressedinaprecisearchitecturaldescriptionlanguage (ADL)canbeusedforautomaticcodegeneration.Thissupports automatictraceabilityfromarchitecturetocode.

The design of software architectures is a highly creative andcomplexengineeringtaskoftenperformedmanually.Inthe

(2)

currentpracticesthetraceinformationemergingduring architec-turaldesignis eithercompletelylostoronly partiallycollected. Manual trace assignment is time-consuming and may lead to invalidandincompletetraces.Theprocessofestablishingand val-idatingtracesshouldbeautomatedasmuchaspossibleinorderto reducetheoverallchangemanagementcosts.

Inthispaper,wepresentanapproachforgenerationand vali-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 Design Lan-guage(AADL)(SAE,2010)areusedforspecifying andanalyzing architecturesofembeddedsystems.Inparticular,EAST-ADLand AADLareindustrydrivenstandardsproposedbycompaniesinthe automotiveandavionicsdomain.

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

WeproposetwomechanismstogeneratetracesbetweenR&A. Thefirstmechanismusesarchitectureverificationtechniques.A givenrequirementisformulatedasapropertyintermsofthe archi-tecture.Thearchitectureisexecutedandastatespaceisproduced. Iftheproperty issatisfied,the elementsintheexecution trace aftertheverificationarecollectivelyresponsibleforthe satisfac-tionofthegivenrequirement.Tracelinksareestablishedbetween therequirement andthearchitecturalelements. Here,theterm ‘executiontrace’referstothesequenceofstatesinthe success-fulexecutionofthearchitecture.Itdiffersfromtheterms‘trace link’and‘tracerelation’thatareusedtodenoteatraceability con-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 betweenrequirementsareproperlypreservedintheir implemen-tationin thearchitecture.This preservation is alsousedin the conceptofsoftwarereﬂexionmodelswhererelationsbetween ele-mentsinhigh-levelmodelsarepreservedintheirimplementations (Murphyetal.,1995).Requirementsrelationsarereﬂectedinthe relationsamongthetracedarchitecturalelements.Basedonan ini-tialsetoftracesnewtracesareautomaticallyinferredbyusingthe requirementsrelations.

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

TheapproachissupportedbyatoolbasedonEclipse Model-ingFramework,theATLmodeltransformationlanguage(Jouault etal., 2008;Jouaultand Kurtev, 2006), and theMaude toolset (Claveletal.,2002,2007).Thetoolprovides:(1)generationand validationoftracesbyusingrequirementsrelationsand/or veriﬁ-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 of require-ments 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 approachistostartwithasetofinitialtracesandtogradually vali-datethemandinfernewtraces.Thevalidationandinferencecanbe appliediterativelyuntilasufﬁcientamountoftraceability informa-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,wemaydiscovertracesthat oth-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 architectureandthetransitionfromtherequirementstothe archi-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 tracedarchitecturalelementsistheminimalsetthatis responsi-bleforfulfillingtherequirement.Thesatisfiestracesareestablished afterverifyingtherequirementoverthearchitecturalmodel.The verificationisdonebyreformulatingtherequirementasaformula intemporallogicandcheckingthisformulaintheMaudemodel checker. Thisis possiblebecausetheused architecturalmodels areexpressedinasubsetofAADLthathasexecutablesemantics definedasMaude rewriterules.Iftheformulaevaluatestotrue thentheelementsfromtheexecutiontraceofthemodelchecker areconsideredtosatisfytherequirement.

Ithastobenotedthatsomeapproachesforrequirements trace-abilityconsidertherelationswithinasinglemodelastraces.For example,therequirementsrelationsreﬁnesandrequiresare con-sideredasin-modeltraces.Inthispaperwedealonlywithtraces betweenR&A.

Inmanyreallifeprojectsthenumberofrequirementsislarge anditisnotfeasibletoverifyeveryrequirementinthedescribed manner.Thesoftwarearchitectmaychoosetoverifyonlythemost criticalrequirementsandtomanuallyassignthetracesfortherest. ManuallyassignedtracesareoftypeallocatedTo.Theyexpressthe expectationofthesoftwarearchitectthatacertainsetof archi-tecturalelementsisresponsibleforfulﬁllingagivenrequirement. SincetheallocatedTotracesaremanuallyassigned theymaybe invalidand/orincomplete.

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

Section3.Therelationsamongrequirementshavetobereﬂectedby therelationsamongthetracedarchitecturalelements.Forexample, ifrequirementR1reﬁnesR3(seeFig.1)thearchitecturalelements

thatsatisfyR1mustbeasubsetofthearchitecturalelementsthat

satisfyR3.Indeed,Fig.1showsthatthis isthecase. Ifthis

con-straintisnotfulﬁlledthentheestablishedtracesareconsidered asinvalid. Ina similarwayifonerequirementrequires another requirementthenthesetsofthetracedarchitecturalelementsmust have anon-empty intersection. Thecompletedeﬁnitions of the constraintsimposedbytherelationsamongrequirementsonthe tracedarchitecturalelementsaregiveninSection7.2.

Theseconstraintscanalsobeusedtoinfernewtracesonthe basisofasetofinitialtracesandthegivenrelationsamong require-ments.

In case of detection of invalid traces the software architect needstorevisitthemanuallyassignedtraces andeventually to verifythem.Anotherreasonforinvalidtracesisthatthe require-mentsmodelisnotcorrectandsomeoftheassignedrequirements relationsdonothold.Inthiswayourapproachalsosupports cor-rectionsintherequirementsatalaterstagewhenthearchitecture andthetracesmayrevealinvalidornon-detectedrelationsamong requirements.

These basic mechanisms of automatic generation of satisﬁes traces,tracevalidation,andinferencebasedonrequirements rela-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,allthearchitectural ele-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

T Trraaccee M Meettaammooddeell

E Errrroorr M Meettaammooddeell

R Reeffoorrmmuullaatteedd R Reeqquuiirreemmeenntt

C

Coonnssttrraaiinnttssbbaasseeddoonn S

SeemmaannttiiccssooffTTrraacceess a anndd RReeqquuiirreemmeennttss R Reellaattiioonnss L Liinneeaarr T Teemmppoorraall L

Looggiicc EExxpprreesssseeddiinn

O Ouuttppuutt R Reeqquuiirreemmeennttss M Mooddeell O OuuttppuuttTTrraaccee

M Mooddeell

O Ouuttppuutt EErrrroorr

M Mooddeell

Fig.2. Overviewoftheapproach.

Scenario2. Validatingtracesbyusingverificationofarchitecture. Inthisscenario,amanuallyassignedsetofallocatedTotraces is checked. The reformulated requirement(s) is verified in the waydescribedinScenario1.Thevalidationphasecomparesthe assignedtraceswiththearchitecturalelementsintheverification 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.Newtracesareinferredforrequirements with-outtracesthatarerelatedtorequirementswithassignedtraces. Therequirementsrelations areusedtoinfernewtraces andto validatetheexistingtraces.Theoutputtracemodelcontainsthe generated traces.Invalid traces arereportedin anoutputerror model.

Scenario4. Generating/Validatingrequirementsrelationsbyusing tracesbetweenR&A.Thisscenarioisconcernedonlywithanalysis oftherequirementsmodelbasedontraceabilityinformation.The relationsamongarchitecturalelementsmayrevealnew require-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

(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 * 1 *

Fig.4.Tracemetamodelforrequirementsandarchitecture.

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

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

3. Requirementsmetamodel

Therequirementsmodelsinourapproachconformtoa meta-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)wedefinearequirementasfollows: Definition1. Requirement:Arequirementisa descriptionof a systempropertyorpropertieswhichneedtobefulfilled.

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.

Deﬁnition 2. Requires relation: A requirement R1 requires a

requirementR2ifR1isfulﬁlledonlywhenR2isfulﬁlled.

Definition3. Refinesrelation:ArequirementR1refinesa

require-mentR2 if R1 isderived from R2 by adding moredetails toits

properties.

Thereﬁnedrequirement(R2)canbeseenasanabstractionof

thereﬁningrequirement(R1).

Deﬁnition4. Containsrelation:ArequirementR1contains

require-mentsR2...RnifR2...RnarepartsofthewholeR1(part-whole

hierarchy).

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

Deﬁnition5. Partiallyreﬁnesrelation:ArequirementR1partially

reﬁnesarequirementR2 ifR1isderivedfromR2byaddingmore

detailstopropertiesofR2andexcludingtheunreﬁnedproperties

ofR2.

OurassumptionhereisthatR2canbedecomposedintoother

requirementsand thatR1 reﬁnesa subsetofthesedecomposed

requirements.Thisrelationcanbedescribedasaspecial combina-tionofcontainsandreﬁnesrelations.Itismainlydrawnfromthe decompositionofgoalsingoal-orientedrequirementsengineering (vanLamswerdee,2001).

Definition6. Conflictsrelation:ArequirementR1conflictswitha

requirementR2ifthefulﬁllmentofR1excludesthefulﬁllmentof

R2andviceversa.

Theconﬂictsrelationaddressesacontradictionbetween require-ments.Weconsiderconﬂictsasabinaryrelation.

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

Tracesarecollectedinmodelsthatconformtothetrace meta-modelwhichcontainstwotracetypesSatisﬁesandAllocatedTo.

Fig.4showsthetracemetamodeltogetherwithpartsof require-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:AsetofarchitecturalelementsE sat-isfiesarequirementRifthesystempropertiesrelatedtoEfulfillthe systempropertiesgiveninR.

ASatisfiestraceisactuallyanimplicationdependencybetween thesystempropertiesgiven intherequirementand thesystem propertiesdesignedinthearchitecture.Thearchitecturesatisfies therequirementifthefulfillmentofarchitecturesystem proper-tiesimpliesthefulfillmentofthesystempropertiesgiveninthe requirement.

AnAllocatedTotrace is assigned when thefulfillment ofthe requirementisexpected.ASatisfiestraceisassignedorgenerated whenthefulfillmentoftherequirementisassured.

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

5. Formalizationoftracetypes

AsoftwarearchitecturemodelAMisamodelconformingtothe AADLmetamodel.Fortheformalizationoftracetypesitis sufﬁ-cienttoconsiderarchitecturalmodelsassetsofmodelelements. ThetypesofarchitecturalelementsintheusedsubsetofAADLare System,Process,ThreadGroup,Thread,SubProgram,DataStore,Port, DataAccessandConnector.

TracetypesaresubsetsofCartesianproductsofsets.Wedeﬁne SatisﬁesandAllocatedTotracetypesasfollows:

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

PR PA Refining System Architecture Model-AM Modeling Model Checking isa p roperty of isapropertyof satisfied+ executiontrace violated+ counterexample

(7)

R1 R3 R2 contains _contains R5 re q u ir e s R6 re q uire s refines requires R4 refin es req uires R10 R7 R8 requires refines par tially refi n es R9 partially refines R12 R11 requ ires requires requ ir_es

Fig.6. PartofrequirementsmodelforRPMsystem.

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

TheintuitionbehindtheAllocatedTotracetypeisthatapartof softwarearchitectureisplanned/expectedtobean implementa-tionofasetofrequirements.FortheSatisﬁestraceswehavethe followingadditionalconstraint.

LetRbearequirementandEAbeasetofarchitecturalelements

wherePRisaformulathatrepresentsRandPAisaformulawhose

truthvaluedependsonEA.WerequirethefollowingfortheSatisﬁes

tracetype:

EASatisﬁesRiffthefollowingstatementholds:

ThefulﬁllmentofPAimpliesthefulﬁllmentofPR (2)

ForagivenpropertyPAthatthearchitecturehastosatisfy,we

areinterestedinidentifyingthesmallestsetofarchitectural ele-mentsEAthatareresponsibleforfulﬁllingPA.ToidentifyEA,PAis

expressedinanysuitablelogicsuchasLinearTemporalLogic(LTL)or Computation-TreeLogic(CTL).ThepropertyPAthuscanbechecked

overthearchitecturemodelAMbyusingarchitectureveriﬁcation techniques.

Fig.5givestheschematicviewoftherelationbetweenPRand

PA.ThedeﬁnitionoftheSatisﬁestracetypeformalizestheintuition

thatapartofsoftwarearchitectureisanimplementationofaset ofrequirements.PRisapropertythattheﬁnaldevelopedsystem

mustsatisfy.Asoftwarearchitectureisamodelofsuchasystem thatrevealssomesolutiondesigndecisions.Therefore,PRshould

bepreservedinthearchitecture.Itisreformulatedintermsofthe architecture,thusobtainingtheformula PA thatcanbechecked

overthearchitecture.PAisalsoapropertyoftheﬁnalsystembut

expressedinadifferentlevelofabstractioncomparedtoPR.The

architecturalelementsinEAarethosethat areintheexecution

trace1_of_checking_P

A.ThereﬁnementofPRtoPAandthemodeling

ofthearchitectureareperformedmanually.

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

1_The_concept_of_execution_trace_is_different_from_the_trace_and_trace_relation._An

executiontraceisasequenceofstatesintheveriﬁcationofanarchitecture.

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

TheArchitectureModelAMsatisﬁestheRequirementsModel RMiffthefollowingtwostatementsholdwhereRisa require-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.TheRPM sys-temhasthefollowingstakeholders:patients,doctors,andthesystem administrator.Themaingoalistoenablemonitoringthepatients’ conditionssuchasbloodpressure,heartrate,andtemperature.For instance,apatientcarriesasensorformeasuringthebody temper-atureandthevaluesaretransmittedtoacentralsystemwherethey arestored.

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

(8)

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

Requirement6requiresRequirement3.

Requirement3. Thesystemshallmeasurebloodpressureand tem-peraturefromapatient.

Requirement6. Thesystemshallstoredatameasuredbysensorsin thecentralstorage.

Fig.6showstherelevantpartoftherequirementsmodel. Thesolidarrowsindicatetherelationsgivenbythe require-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(systemand pro-cessinAADL).Thesecomponentscontainothercomponentswhich arenotrepresentedinFig.7.TheSD(SensorDevice)component containsthesensorscarriedbythepatient.Thesensorsperform measurementsataregularinterval. TheSDsendsthe measure-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’s behav-ioralannexwithaﬁnitesetofstatesandasetofstatevariables.The RPMarchitecturehasbehavioralannexesfordynamicbehaviorof threadsineachsystemcomponent.

Thefollowingpresentstheimplementationofthethreadinthe SDMcomponent(SDMThread)forstoringbloodpressure measure-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

Afterexplainingpartsoftherequirementsmodelandthe archi-tectureofRPM wecanshowanapplicationofourapproachfor generationandvalidationoftraces.Section7.1explainsthe ver-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.Thearchitectureisexecutedforthe formal-izedscenarioandastatespaceisproduced(simulateinFig.8).Inour exampleastatedescribesthelociofdatavalueswithinthe archi-tecture.Anexecutiontraceisthesetofstatesandstatetransitions whicharegeneratedifthereformulatedrequirementissatisfied. Counterexampleisthesetofstateswhicharegeneratedwherethe reformulatedrequirementisnotsatisfied.Alltheusedarchitectural elementsinanexecutiontraceareconsideredcollectively respon-sibleforfulfillingarequirement.Therefore,theyaretheelements forwhichaSatisfiestracewillbeestablished.

Example. ReformulationofRequirements Considerthefollowingrequirement

Requirement5Thesystemshallstorepatientbloodpressure mea-suredbythesensorinthecentralstorage.

Fig.9isthepartoftheRPMarchitecturedevelopedforthe sys-tempropertygiveninRequirement5.

Requirement 5 is reformulated as a formalized scenario as follows:

Formalized Scenario: (contains(SDBLOODEDP1, DI)), (con-tains(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,thesubprogram execu-tionforstoringthebloodpressuredatainthecentralstorageis implementedasastatetransitionsysteminthethreadsdmTh(see Section6).ThesdmThthreadhasstatesbloodStored, temperature-Stored,highTemperature,lowTemperatureandidle.Whenthedata instanceDIisstoredinthedatastoreSDMBLOODSTRGofthe com-ponentSDM,thestateofthesdmThthreadinthestatetransition systemissettothebloodStoredstate.

The formalized scenario is the ﬁrst step toreformulate the requirementintermsofthearchitecture.Thenextstepisto con-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,theLTLformuladoesnotexplicitly indi-catethedatainstanceDIandthedataportSDBLOODEDP1ofSensor 2.TheinitializeThreads({MAINsystemWholesys.imp})intheformula createstheinitialstate.MAIN->hpc->sdm->sdmThdenotesthe fullcomponentnameofthesdmThthreadcomponent.The @blood-StoredstatesthatthestateofthesdmThthreadisthebloodStored. The‘<>’intheLTLformulastates‘eventuallyinthefuture’.TheLTL formulacanbecheckedonthegeneratedstatespaceinMaude.The formulaexempliﬁesthepropertyPAinFig.5.

7.2. Generatingtraces

Accordingtothedefinitionof tracetypes,a Satisfiestraceis generated betweenthe architectural elementsin theexecution traceandtherequirementthatissuccessfullychecked.Acounter examplemeansthatalthoughtherequirementisallocatedtothe architectural elements, i.e.,theyareinvolved in the implemen-tation of this requirement,the architecture doesnot satisfy it. AllocatedTotracecan begenerated but theSatisfiestraceis not present.

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

(10)

Fig.8.Veriﬁcationoffunctionalrequirements.

modiﬁcationaddsanattributecalledUsedtothecomponentclasses intheAADLmetamodel.EachtransitionrulesetstheattributeUsed ofthematched/affectedarchitecturalelementtotrue.

ThesearchcommandoftheMaudemodelcheckerreturnsan executiontraceiftherequirementissatisfied.Theremightbe mul-tipleexecutiontracesinwhichtherequirementissatisfied.Inthis case,theSatisfiestraceisgeneratedfortheusedarchitectural ele-mentsineachexecutiontrace.

Thesecondwaytogeneratetracesistousetherequirements relations(seeScenario3 inSection2).Wedefined several con-straintsthatspecifyhowarelationbetweentworequirementsis reflectedinthearchitecture.TheconstraintsareshowninFig.10. Theyarealsousedtogeneraterequirementsrelationsfromtraces (seeScenario4inSection2).InFig.10,alltheconstraintsaregiven fortheSatisfiestraces.Thesameconstraintsarealsovalidforthe assignedAllocatedTotraces.

Fig.10(a)postulatesthattheintersectionofthetraced archi-tectural elements for two requirements is non-empty if one requirementrequiresanother.Fig.10(b)illustratesthatthe archi-tecturalelementsthatsatisfyarefiningrequirementalsobelongto thesetofarchitecturalelementsthatsatisfiestherefined require-ment.ConstraintssimilartotheoneinFig.10(b)arevalidfortraces withtheContainsandPartiallyRefinesrelations(seeFig.10(c)and (d)).

InordertogeneratetheSatisﬁestracesforR1inFig.10(b),(c)

and(d),allotherrequirements(R2,R3,...,Rk)shouldbesatisﬁedby

thearchitecture.Forinstance,ifoneofthereﬁningrequirements (R2,R3,...,Rk)in Fig.10(d)is notsatisﬁedbythearchitecture,

thereﬁned requirement(R1) is not satisﬁedeither. Thepartial

refinementmightnotbecomplete(Fig.10(d)).Inthiscase,even ifallrefiningrequirementsaresatisfied,theSatisfiestraceis gen-eratedonlyifitisconfirmedthattheunrefinedpropertiesarealso satisfied.TheSatisfiestracefor theunrefinedpropertiesinR1 is

establishedbyveriﬁcation.

Example. GenerationofTracesbyUsingVeriﬁcationofArchitecture InSection7.1,wegaveanexamplereformulationofa require-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 instanceDIiscontainedbythedataportSDBLOODEDP1of Sen-sor2.The(locationofcomponent(MAIN->hpc->sdm->sdmTh) inC:Conﬁguration)returnsthestateinthetransitionsysteminthe sdmThthread,which shouldbethebloodStoredstate(‘= =blood-Stored’).‘=>*’inthecommandindicatestheformoftherewriting prooffromtheinitialstateuntilthestatewherethestateinthe tran-sitionsysteminthesdmThthreadisthebloodStoredstate.Then,the utsearchcommandtriestoreachthatstatefromtheinitialstate.

Thefieldusedofthearchitecturalelementsmatchedbythe tran-sitionrulesissettotrueinthelaststateofthecounterexample. OurtoolgeneratestheSatisfiestracelinksbetweenRequirement5 andthearchitecturalelementsusedintheexecutiontrace.Fig.11 showsthegeneratedSatisfiestracelinksforRequirement5.

Theveriﬁcationresult,andthereforethetraces,dependsonthe reformulationoftherequirementtobechecked.Misinterpretation

(11)

Fig.10.Constraintsbasedonsemanticsoftracesandrequirementsrelations.

oftherequirementandwrongreformulationarecausesfor poten-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.12showsthe gener-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-emptyintersectionoftracesfor Require-ment4andRequirement12.BasedontheconstraintsinFig.10, there mightbea RequiresrelationbetweenRequirement4 and Requirement12.Thepresenceofsuchrelationshouldbedecided bytherequirementsengineer. Inourexamplewecanconclude thatRequirement12requiresRequirement4sinceitisnotpossible toobtainanydata(Requirement12)iftheyhavenotbeenstored beforethat(Requirement4).

(12)

satisfies

R

5 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

E

A5

Satisfies(E

A5

, R

5

)

sdmThr

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

Itshouldbenotedthatanon-emptyintersectionoftracesdoes notalwaysleadtorequiresrelation.Thefulﬁllmentoftwo require-mentsmayrelyona commonfunctionalityof thesystem.This commonlyusedfunctionalitywillbethendemonstratedby com-montracedelementsinthearchitecture.

7.3. ValidatingTraces

Validationoftracesaimsatidentifyingthetraceswhichdonot obeythetracesemanticsandtherelatedconstraints.Thishelpsto eliminatefalsepositivetracesandtodetectmissingtraces.In addi-tion,aviolationoftheconstraintsinFig.10mayindicateinvalid relationsamongrequirements.Theserelationsneedtobe recon-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).

Ourapproachalsoprovidesvalidationoftracesbyusing veri-ﬁcationresults(Scenario2).Thisappliestothemanuallyassigned AllocatedTotraces.TheassignedAllocatedTotracesandthe gener-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

(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

4

)

Satisfies

(E

A12

, R

12

)

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 SatisfiestracesaremissedwhilegeneratingtheSatisfiestraces. Again,amisinterpretationoftherequirementandwrong reform-ulationmaycausemissingSatisfiestraces.

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 the compo-nentsASand CPCAR,thesecomponentsarenotinvolved inthe

(14)

Fig.15.Venndiagramforgeneratedandassigned‘AllocatedTo’tracesforarequirement.

Satisﬁestraces.Weconcludedthatthetwoinitiallyassigned Allo-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,ourtoolgivesthetracesand require-mentsrelationswhichdonotobeytheconstraints.Thearchitect shoulddecidethateitherthetracesortherequirementsrelations areinvalid. AllocatedTo sd_blood_edp1

E

A5_A

Satisfies(E

A5_S

,

R

5

)

AllocatedTo(

R ,

5

E

A5_A

)

R

5 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

(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.Thetoolwas demon-stratedinECMFA-TraceabilityWorkshop(ECMFA-TW2010)andis describedin(Gokniletal.,2010).Thissectionismainlybasedon (Gokniletal.,2010).InSection8.1,wedepicttheusageofthetool inthecontextofaprocessformodelingrequirementsand archi-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: refor-mulatingrequirements,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.The activ-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. The architec-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.The compo-nentisimplementedasanATLtransformation.Itgeneratesnew tracesbasedontherequirementsrelationsandtheconstraintsin Fig.10.

(16)

Fig.18.Modelingprocesswithtracegenerationandvalidation.

Torepresenttheoutputofthetwotracegeneratorcomponents, weusetwodifferentoutputtracemodelsinordertostatethatthe outputsdonothavetobethesame.

8.2.4. TracevalidatorinATL

TheinputofthecomponentistheInputArchitectureModel,the InputTraceModel,andtheInputRequirementsModel.The compo-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) developedbyArturBoronatisusedtogenerateMaude representa-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.The archi-tecturalelementstracedfromtherequirementsintheerrormodel canbereachedinthetracemodelinFig.21.

(17)

T

Trra

ac

ce

e

G

Ge

en

ne

erra

attiio

on

n

&

V

Va

alliid

da

attiio

on

n

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.

(18)

Fig.21.Outputofthegeneratingtraceactivity.

8.3. Evaluationofthetool

Toolsmaybeevaluatedregardingdifferentqualitieslike usabil-ity,performanceandscalabilityamongothers.Theusabilityofour toolmainlydependsontheusabilityoftheEclipseenvironment andtheavailabledocumentationontheapproach.Forthecounter exampleandexecutiontraces(theoutputofthecomponent Archi-tectureVeriﬁcationinMaude),noGUIisprovided.Foraprototype weconsiderthistobeacceptable.Thissectionreportstheresults oftheconductedperformanceandscalabilitytestsofthetool.The modelcheckingtechniquesweusemayhavescalabilityand per-formanceproblemsinhandlinglargemodelsandnumberofstates. Therefore,wefocusonmodelcheckingpartofourtool.

Performancetestingisconductedtoevaluatethecomplianceof asystemorcomponentwithspeciﬁedperformancerequirements (http://www.aptest.com/glossary.html#S).Therequirementinour testisthatthetoolperformsinareasonabletime(saylessthanone minute)withaveragenumberofarchitecturalelements.An esti-matefortheaveragenumberofarchitecturalelementsisbasedon areportbyMcCormacketal.(2006).Theycharacterizethe differ-encesindesignstructurebetweencomplexsoftwareproductslike MozillaandLinux.Thereportshowsthatthearchitecturalmodelof arealsystemcontainsaround2000modelelements.Wetakethis ﬁndingasabaseforourperformancetests.

Scalabilitytestingisaperformancetestingfocusedonensuring theapplicationundertestgracefullyhandlesincreasesin work-load(http://www.aptest.com/glossary.html#S).The workload in ourperformancetestisthenumberofstates.Ourinterpretation ofscalabilityisthefollowing:thetoolscalesifthetimespentbythe toolincreaseslinearlywhenthenumberofgeneratedstatesincreases linearly.

Ourdependentvariableinthetestsistheelapsedtimefor simu-lationandverification(inseconds).Theindependentvariableused intheperformancetestsisthenumberofelementsinthe archi-tecture.Wedefinethenumberofelementsasfollows:numberof componentinstances+numberoffeatureinstances+numberofport connections,wherecomponent,featureandportconnectionsarethe architecturalelementsinAADL.Theindependentvariableusedin thescalabilitytestisthenumberofstatesgeneratedinthe simula-tion.Wedefinethenumberofstatesinthesimulationasfollows: thenumberofstatesthesimulationisenforcedtoexplore.Thesetwo variablesarecloselyrelatedtoeachother.Ifthenumberof ele-mentsisincreased,itislikelythatthenumberofstatesrequiredfor simulationandverificationalsoincreases.However,thisdoesnot alwayshavetobethecase.Asanexample,considerthatthereare newelementsinthearchitectureforanewsystemproperty.New elementsmaynotincreasethenumberofstatesintheverification ofarchitectureforexistingsystemproperties.

(19)

Fig.22.Outputofthevalidatingtraceactivity.

Memoryconsumptionisnotmeasuredintheperformancetests. Therunsforeachperformancetestareexecutedsixtimesandthe timeis showninTables1 and2.ThetestsaredoneonIntel(R) Core(TM)2Quad CPUQ6600runningat2.40GHz with4096KB cache,and2GBofmemory,runningKubuntu10.04.WeuseCore Maude2.4 forLinux.Themodelsusedintheperformancetests areartiﬁciallycreatedwithcertainnumberofelementsandstates. WeuseaversionofoperationalsemanticsofAADLexcludingthe Table1

Simulationtimesintheperformancetest.

Numberofelements Simulationtime(s)fortheexecutiontrace Numberof states=500 Numberof states=1000 Numberof states=2000 (a)Simulationwithexecutiontrace

2000 7.8 15.9 33.8 2200 8.7 17.5 37.2 2400 9.3 19.4 40.4 2600 10.1 20.9 43.3 2800 10.9 22.4 46.5 3000 11.5 23.9 49.6

Numberofelements Simulationtime(s)forthecounterexample Numberof states=500 Numberof states=1000 Numberof states=2000 (b)Simulationwithcounterexample

2000 2.6 5.2 10.8 2200 2.8 5.7 11.9 2400 3.1 6.3 13.0 2600 3.3 6.7 14.0 2800 3.5 7.2 15.2 3000 3.7 7.7 16.1

real-timesemantics.Theperformanceandscalabilitytestresults mightbedifferentforthereal-timesemanticsencoded in Real-TimeMaude.

8.3.1. Performancetest

Thetestissetupasfollows.Weincreasethenumberof ele-mentsbyaddingcomponents,dataportsanddataportconnections tothearchitecture.Westartwith2000architecturalelementsand endupwith3000architecturalelements.Thenumberofstatesfor eachrunis500,1000and2000.Theresultsoftheperformance test areshownin Table1.Sincetheresultsoftheperformance testmightbedifferentwhentheveriﬁcationresultisan execu-tiontraceoracounterexample,theperformancetestisdonefor

Table2

Simulationtimesinthescalabilitytest.

Numberofstates Simulationtime(s) (a)SimulationinMaude(numberofelements=10,000)

10 1.5 100 9.5 1000 82.1 3000 265.4 4500 401.8 5000 –

(b)Simulationinalloy(numberofelements=38)

20 14.2

40 53.7

60 105.8

80 180.4

(20)

Fig.23.Simulationtimeasthefunctionofthenumberofarchitecturalelements.

bothcases(seeTable1(a)and(b)).Thestandarddeviationofthe dataisapproximately0.3%.

Accordingtotheseperformancetests,thetoolperformsbelow oneminutewithaveragenumberofarchitecturalelementsinareal system.Theincreaseinthesimulationtimeislinearandupto50s for2000states(seeFig.23).

8.3.2. Scalabilitytest

The goalof this test is toinvestigate how the tool handles increasesinthenumber ofstatesoverseveralordersof magni-tude.Theindependentvariableisthenumberofstates.Wealso comparethescalabilitytestresultsofthetoolusingMaudewith theresultsofthetoolusingdifferentsimulationandverification environmentssuchasAlloy(Jackson,2002).Thesameexecution semanticsofAADLinMaudeisencodedinAlloy.Thefirstpartof theperformancetestisdoneinMaudewith10,000architectural elements(seeTable2(a)).Then,thesecondpartoftheperformance testisdoneinAlloy(seeTable2(b)).In(Looman,2009),we inves-tigatedsimulationandverificationinAlloy.WefoundthatAlloyis notsuitableforlargenumberofmodelelementsandstates. There-fore,wechoosetorunthetestinAlloywithasmallernumberof architecturalelements(38elements)(seeTable2(b)).

AccordingtothescalabilitytestresultsbasedonMaude,the sim-ulationtimeincreaseslinearlywhenthenumberofstatesincreases linearly(seeFig.24).WeranoutofmemoryinMaudewhenwetry simulationfor10,000architecturalelementswith5000states.In theAlloyexperiment,thesimulationtimealsoincreaseslinearly whenthenumberofstatesincreases,however,formuchsmaller

numberof architecturalelementsand much smallernumber of states.

Accordingtothesetestresults,weconcludethatourtoolscales muchbetterwhenusingMauderatherthanusingAlloy.

Theresultsdependonthemodelinglanguageandits seman-tics.The results maychange withdifferent AADLsemantics or witha lower level design languagelikeUML class andactivity diagrams.

9. Discussionoftheapproach 9.1. Maintainingtraces

Thedescribedﬁne-grainedtraceabilityapproachhelpsin iden-tifying impactedarchitectural elements ifrequirementschange butafterthechangesthetracesneedtobeupdatedaswell.The needoftracemaintenanceoccurswhen(1)requirementschange, and/or(2)architecturechanges.Withtheadditionallayeroftrace linksinvolvedinthechangemanagementprocesstherequirements engineerandthesoftwarearchitectneed(a)toproposechanges forrequirementsand/orarchitecturalelements,(b)todetermine impactedelementsviatraces,(c)tochangetheimpacted require-ments/architecturalelementsfortheproposedchanges,and (d) ﬁnallytomaintaintraces.

Theimpactofchangesdependsontheirrationale.Forinstance, therequirementsengineermaydeleteapropertyofarequirement becausethis property is not requiredany morefrom the busi-ness/stakeholderpointofview.Thepropertymaybeusedinother requirementsinthemodelanditalsohastobedeletedfromthem. We namethesechanges and theirrationaleasdomainchanges. Domainchangesmodifytheoverallsystempropertiesandrequire changesinthearchitectureinordertosatisfytheupdated/new requirements. Tracesbetween changed requirementsand (un-) changedarchitecturalelementsmightbeinvalidaswellastraces between unchanged requirements and changed architectural elements.

Anothertypeofchangesaresemantics-preservingaccordingto (Buckleyetal.,2005)andweconsidertheirrationaleasrefactoring (seeFowler,1999forrefactoring).Forinstance,therequirements engineermaydeleteapropertyofarequirementtoimprovethe structureofthemodelwithoutmodifyingtheoverallsystem prop-erties.Thispropertystillmustholdintherequirementsmodelafter thechange.Sincethesechangesdonothaveanyimpactonthe overallsystemproperties,thearchitecturethatsatisﬁesthese prop-ertiesdoesnotneedtobechanged.Onlytracesfromthechanged requirementstothearchitecturemightbeinvalid.Basedonthe changerationaleandthechangedelements,thetracesthatneed tobemaintainedaredetermined.Thisprocesscanbeautomated andfollowedbyapplicationofthedescribedtechniquesfortrace generationandvalidation.

9.2. Identifyingchangesinthecode

Ourapproach canbecombinedwithtracegeneration meth-odsandtools(Grechaniketal.,2007;Hayesetal.,2006;Murta et al., 2006) for tracing requirements/architecture to source code.In cases where code is automaticallygenerated fromthe architecture,changesincodecanbetracedandimplemented auto-matically. Sometimesrequirements changes are traced directly to code. It is still beneﬁcial, however, to keep the architec-turesynchronizedwiththecodeandtotracethechangesfrom requirementstothearchitecture.Architecture,among others,is anaidinunderstandingandcommunicatingthedesign of com-plexsystemsand shouldcorrectlyreﬂect itsimplementationin code.

(21)

Fig.24.Simulationtimevs.numberofstatesinalloyandMaude.

9.3. Expressingrequirementsinlogic

Theapproachusesreformulationofrequirementsinaform suit-ableforveriﬁcation.Thiscanbeachallengeforthedevelopersin manyorganizations(Sabaliauskaiteetal.,2010).Thereformulation isapartofthedesignprocessandishardtoautomate.The archi-tectmightstillneedtocheckthegeneratedtraces.Incaseoffalse positivestherequirementsmodelandrelationsshouldbechecked. Therefore,wesuggestaniterativesemi-automaticprocessof apply-ingourapproach.Thesoftwarearchitectcangraduallyimprovethe qualityofthetracesandtherequirements.

Casestudiesconductedwiththeindustry(Ciraci,2009)show thatitishardtoreformulaterequirementsasLTL/CTLformulas. Domain-speciﬁc languages can be used to specify require-mentsofcertaintypethatallowgenerationofLTL/CTLformulas (Ciraci,2009).Startingfromnaturallanguage,SemanticsBusiness VocabularyandRules(SBVR)cansupportreformulationof require-mentsintermsofLTL/CTLformulas.Extendingourapproachwith thiskindoflanguageswilleasethereformulationofrequirements andwillimprovetheusabilityintermsoftheROIforthe traceabil-ity.

9.4. Dealingwithcomplexrequirements

A requirement may describe multiple system properties or a complexsystem propertyamenable todecomposition. In our approachitisnotpossibletoexplicitlystatewhichsub-property inacomplexrequirementfails.Therequirementsengineershould decompose the requirement into sub-parts (by using the Con-tainsrelation)untileachrequirementdescribessufficientlysimple property.Withoutsuchdecomposition,thesatisfiestracesforthe requirementwillbethecollectionoftracesgeneratedfromtheLTL formulasforeachpropertyintherequirement.IfoneoftheseLTL formulasfailsintheverification,itisconcludedthatnotall prop-ertiesintherequirementaresatisfied.Therefore,satisfiestraces cannotbegeneratedforthecomplexrequirementevenifother LTLformulasaresatisfied.Asimilarscenarioisvalidforgenerating tracesbyusingrequirementsrelations.Basedontheconstraintin Fig.10(c)thesatisfiestracesforR1isthecollectionofthesatisfies

tracesfor(R2,...,Rk)where(R1containsR2,...,Rk)isacomplete

decompositionandallcontainedrequirements(R2,...,Rk)are

sat-isﬁed.Ifthecomplexrequirementcanbedecomposedintoother requirementswhereeachrequirementspeciﬁesasingleproperty

representedbyanLTLformula,ﬁrstwecangeneratetracesforthe decomposedrequirementsbyverifyingtheLTLformulasandthen wecancollectivelygeneratethesatisﬁestracesbyusingthe Con-tainsrelation.Here,wehaveanunderlyingassumptionthateach propertyintherequirementcanbetranslatedintoanLTLformula. ForthepropertiesthatcannotberepresentedwithLTLthesoftware architecthastomanuallyassigntraces.

9.5. Manualtraceassignmentandvalidation

Ourapproach supportstwokindsoftracesbetween require-mentsand architecture:SatisfiesandAllocatedTo. Satisfiestraces arediscovered throughtheformalprocess ofchecking require-mentsagainstthearchitecture.Forcaseswhereitisnotpossible toreformulaterequirementsinaformsuitableforverification,the softwarearchitectneedstomanuallyassignmultiplesimilar Allo-catedTotracesatvariouslevelsofgranularity.Forexample,traces fromasubcomponent toarequirementandfromtheenclosing component tothe samerequirement have tobe both assigned manually.Obviously, the lattertrace canbe induced automati-callyfromtheformerbyfollowingthepart-wholerelationsinthe architecture.Giventheusualhighcostandeffortoftraceability, thisdeficiencymayaddanadditionaloverhead.Inordertoreduce theoverhead,themanualtraceassignmentandvalidationcanbe appliedforasmallsetofarchitecturallysignificantrequirements whichcannotbereformulatedintheformsuitableforverification. Ontheotherhand,thelevel ofautomationintheapproachcan beimprovedforcreatingtracesatvariouslevelsofgranularityby exploitingthestructuralsemanticsofarchitecturemodels. 9.6. Completenessofthearchitecture

Thearchitecturedoesnotneedtobecompleteinordertocheck someof itsproperties. Theverification itselfenablesthe archi-tectstodeterminewhichpropertiesarenotsatisfiedyet.Acounter examplemeansthatalthoughtherequirementisallocatedtothe architecturalelements,i.e.,theyareinvolvedinthe implementa-tionofthis requirement,thearchitecturedoesnotsatisfyitand thus,thearchitectureisstillincomplete.Ontheotherhand,some ofthepropertiesintherequirementsmaynotbeconsideredbythe softwarearchitectatall.Inthiscase,itisnotusefultotranslate thesepropertiesintoLTLformulastobeverified.