HAL Id: inria-00399493
https://hal.inria.fr/inria-00399493
Submitted on 30 Jun 2009
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Franck Fleurey, Benoit Baudry, Alain Nicolas, Erwan Breton, Jean-Marc Jézéquel
To cite this version:
Franck Fleurey, Benoit Baudry, Alain Nicolas, Erwan Breton, Jean-Marc Jézéquel. Generating regres- sion tests for software migration. [Research Report] RR-6971, INRIA. 2008, pp.46. �inria-00399493�
a p p o r t
d e r e c h e r c h e
N0249-6399ISRNINRIA/RR--6971--FR+ENG
N° 6971
June 2009
Centre de recherche INRIA Rennes – Bretagne Atlantique
of the funtionalities of the legaysystem. Regression testing anbeused to
performthisvalidation. However,inmostmigrationprojetsthespeiations
and testasesforthelegayappliation areobsolete. Inthis ontext, produ-
ingandrunningthetestsanrepresentmorethan50%oftheoverallmigration
ost. Model-driven migrationis basedon thereverse engineeringof models of
legay systems for modernization. In this paper, we report on an experiene
where these models where used to derivefuntional test senarios. Based on
these models, wehavedenedseveraltest riteriato qualifythe obtainedtest
senarios. The models and riteria fortest generation were developed for the
migrationofalarge-salebankingappliation.
Key-words: softwaremigration,model-drivenengineering,model-basedtest-
ing,testgeneration,regressiontesting
Thisworkwasdoneintheontextofthe INRIAindustrialpost-doofFrankFleurey
atSodifranein2007-2008.
∗
SINTEF,Oslo,Norwayfrank.eureysintef.no
†
INRIA,Rennes,Franebbaudryirisa.fr
‡
Sodifrane,Nantes,Frane{ebreton,aniolas}sodifrane.fr
§
UniversityofRennes,Rennes,Franejezequelirisa.fr
Résumé: Softwaremodernizationprojetsonsist oftheredesignofalegay
appliationanditsmigrationtoanovelplatform. Thevalidationofthemigra-
tionstepis amajoronernsineithasto hektheexatpreservationofthe
funtionalitiesof thelegay system. Regressiontestinganbeused toperform
thisvalidation. However,inmostmigrationprojetsthespeiationsandtest
ases for the legay appliation are obsolete. In this ontext, produing and
running thetests anrepresent morethan 50%of the overall migration ost.
Model-drivenmigrationisbasedonthereverseengineeringofmodelsoflegay
systems for modernization. In this paper, we report on an experiene where
thesemodelswhereusedtoderivefuntionaltestsenarios. Basedonthesemo-
dels,wehavedenedseveraltestriteriatoqualifytheobtainedtestsenarios.
Themodelsandriteriafortestgenerationweredevelopedforthemigrationof
alarge-salebankingappliation.
Mots-lés : softwaremigration, model-driven engineering,model-basedtes-
ting,testgeneration,regressiontesting
expeted results. Then, themigrated systemis valid ifall these tests passon
thisnewversionofthesystem: thisindiatesthatthemigratedsystemhasthe
samebehaviourasthelegaysystem. Themainreasonfortheprohibitiveost
ofvalidationisthelakofaurateandupdatedspeiationsandreferenetest
senariosfor the legay system. This implies that the referene tests haveto
begeneratedatthetimeofthemigration,andthatthisgenerationanonlybe
basedontherunninglegaysystemandontheknowledgeofthelegayapplia-
tionsusers. Thisleadstoanexpensiveproessinwhihbothlegayappliation
domainexpertsandtestersofthemigrationteamhavetobeinvolved.
For example, let us onsider how Sodifrane, the ompany with whih we
haveollaboratedforthiswork,dealswiththegenerationofreferenetest se-
narios. Currently, it asks itsustomers to produe thereferene tests for the
legay appliations. Theprodution ofgoodtest senariosis veryostlyboth
for Sodifrane and for its ustomer beause it requires anumberof iterations
between thedomain experts who write thetests and themigration team who
hekstheir overage. Mostof this proess is manualand the ommuniation
betweenthedomainexpertsandthemigrationteamisdiultbeauseoftheir
dierent expertises: domain experts know how to use the appliation but do
notknowhow itis madewhereas thedeveloperanonlygivefeedbakat the
odelevel. Thistimeandeortmustbespentsinethereferenetestsenarios
are aritial partof theagreement betweentheompanyand its lient: they
speifytheminimal qualityrequiredbythelientforthemigratedsystem.
Twoimportant fatorshaveto beonsidered to redue theostof theval-
idation: tehniquesandtest riteriatoassist thesystematigenerationof test
senarios, and models that anbeused withoutinvolvingthe appliation do-
mainexperts. Thesetehniquesshouldassistthetestersinsuhawaythatthey
donotneedtounderstandpreiselyallthebusinessonernsinordertoreate
relevanttest senariosortoimprovethequalityof existingsenarios. Wean
notiethatonebenetofthisverypartiulartestingproessisthat aomplete
oraleisavailable forfree: thelegaysystem anprovidetheexpeted output
foranyinputsenario.
Theobjetiveofthisworkistoproposeatestingtehniquethatwouldallow
Sodifraneto:
1. Create thereferene testsrequired to developand validate themigrated
appliationwithoutthehelpofdomainexperts(i.e. withoutinvolvingthe
lient).
2. Provideregressiontests tothelienttogether withthemigrated applia-
tion. These tests are valuableto thelientas theyan be used for any
furtherevolutionoftheappliation.
Thisdoumentisorganisedasfollows. Setion2presentsindetailthemodel-
based approah developped by Sodifrane for software migration. Setion 3
presentsaset oftest riteriabasedonthe modelsused for migration. Setion
4details howthe approahan be ompleted using strutural test generation
tehniques. Finaly,setion5onludesthisreport.
2 Software migration using MDE
Positioned from the mid 80's on IT servies dediated to Banks and Insur-
aneCompanies,Sodifranehasdevelopedastronglegaymodernizationexper-
tisebasedonsoftwaresolutionstoindustrialize transformationprojets. Sine
1994, Sodifrane hasadopted and promoted model-driven engineering(MDE)
approahesformodernizationprojets. Ithasindustrializedmodel-driventeh-
niques for reverse-engineering, ode analysis and transformation and for rep-
resenting and manipulating information systems. These solutions allow the
ompany to propose eient and protable solutionsfor migration and mod-
ernizationofsoftwarelegaysystems.
Thishapterpresentsthemodel-drivenmigrationproessdevelopedatSod-
ifrane. This proess inludes automatianalysis of the existing ode, reverse
engineeringofabstrathigh-levelmodels,modeltransformationtotarget plat-
form models and ode generation. We detail the dierent meta-models and
transformationsthat areproduedfor theautomationof these steps. Wealso
disusswhatartefatsanbediretlyreusedandwhihonesneedtobeadapted
fromoneprojettoanother. Sodifranehasdevelopedatoolsuiteformodelma-
nipulationalledModel-In-Ation(MIA)thatisusedasabasisforautomating
themigration.
2.1 Model-driven migration proess
The onstant evolution of software tehnology leads to ontinuous migrations
ofsoftwareomponents. Theseprojetsmaybemotivated bydierentreasons
suh asthe obsoleseneof atehnology,the pressureofusers, ortheneed to
build asingleoherentinformation systemwhen mergingompanies. Mostof
thetimesoftwaremigration isahievedthroughthefull re-developmentofthe
legay appliation. Model-driven software development oersan opportunity
forinreasingtheautomationinsoftwaremigration.
The full automation of migration is diult to ahieve not only beause
of the distane between the legay platform and the new platform but also
in order to ensure the quality of the new appliation. Most of the time, the
objetiveof migration is not to simply "ompile" the legay appliation to a
newplatformbut to reate anewversionofthe appliationusing stateofthe
artdevelopmenttehniques. Thisis neessaryto ensurethemaintainabilityof
Figure1: Model-drivenmigrationpriiple
thenewappliationandtoleveragethelatesttehnologiesintermsofgraphial
userinterfaes,distributionandmobility.
Inthefollowing,setion2.1.1rstpresentsthegeneralproessdevelopedby
Sodifrane for model-drivenmigration, setion 2.1.2 disussesthe automation
of theproessand setion2.1.3details howthis proessis adaptedin pratie
alongthephasesofamigrationprojet.
2.1.1 Migrationgeneral proess
Figure1presentsthegeneralproessdevelopedbySodifraneformodel-driven
migration. Thisproessismainly dividedin foursteps.
Therststep isthe parsingofthe ode ofthe legayappliation, to build
aompletemodelof theodeoftheappliation. Thisstepanbedividedinto
two stages: rst a parser builds an abstrat syntax tree from the ode and,
thenthissyntaxtreeisproessedbyatransformationtobuildanatualmodel
that onforms to the meta-model of the legaylanguage. Duringthe seond
stage,allthesymbolssuhastypes,variablesorfuntionallsareresolvedand
properlyboundto theappropriatemodel elements. Thisisaneessarystepto
allowforaeientanalysisofthelegaysystem. Themeta-modeldenotedLon
gure1orrespondstothemeta-modelofthelegayappliationimplementation
language.
Theseond stepisareverse-engineeringfrom theodemodeltoaplatform
independentmodel. Theroleofthisstepistoabstrathigh-levelviewsfromthe
modeloftheode. Thisstepisimplementedbymodeltransformationsfromthe
legaylanguagemeta-model(L)toapivotmeta-model. Thepivotmeta-model used by Sodifrane is a platform independent meta-model alled ANT whih
ontainspakagesto represent:
Statidatastrutures(loseto theUMLlass diagram).
Ations andalgorithms(itinludes animperativeationlanguage).
Graphialuserinterfaesandwidgets.
Appliationnavigation.
Figure2: ExerptoftheANTnavigationmeta-model
The navigation is the most high level view of the ANT meta-model. Fig-
ure2showsan exerptof thismeta-model. It onnetsdialog elements whih
orrespondtoGUIforms,transitionsbetweenformsandtheirGUIeventswith
operationsin thelassmodel.
All ANTviewshavetobereatedthroughmodeltransformationsfromthe
modeloftheodeofthelegayappliation. Inordertobeabletoreatehigh-
levelviews,suhasamodelofthegraphialuserinterfaeofthelegayapplia-
tion,themodeltransformationshaveto relyonaknowledgeof thelibrariesof
thelegayplatformandonodingonventions(orodepatternsintroduedby
tools)that wereusedduringthedevelopmentofthelegayappliation. Thisis
thereasonwhy, even ifthelegayplatformsfor severalmigration projetsare
similar, the legay ode must be arefully studied in order to properly adapt
themigration toolstoeverysingleprojet.
The third step is the transformation of the ANT model into a platform
spei modelof theappliation. Thisstepis implementedusingmodeltrans-
formationsfrom theANT meta-modelto the UML meta-model. These trans-
formations are design transformations whih rene the platform independant
views of the pivot model to t the target platform. Againat this stage, it is
importanttoadapt thetransformation to meetthe requirementsofeveryus-
tomer. This issue is disussed with more details and illustrated on aspei
projetinsetion3.3.
Thelast stepisthegeneration oftheodeofthenewappliation fromthe
platformspeimodel. Toimplementthisstep,Sodifraneusestemplate-based
text generation tools in order to be ableto easily ustomize ode generation
aordingtotheustomers requirements. Thespei toolsused bySodifrane
fortheimplementationof model-transformationsand ode generationarepre-
sentedsetion2.2.
2.1.2 Automation in the migrationproess
Toreduetheostofmigrationthegoalistoahieveanoptimumautomationin
themigrationproess. However,thisshouldnotimpatthequalityin termsof
design, performanes ormaintainabilityoftheresultingappliation. Sinethe
legayappliationisfully-exeutableandthetargetplatformisusuallypowerful
enough, oneould argue that themigration should be ompletely automated.
Itis theoretiallypossible: itwould betheequivalentofwritingaompilerfor
thelegaylanguagethat targetsthenewplatform.
However,asstatedin theprevioussetion,migration, andespeiallyin the
ontext of modernization, is more than just reating anexeutable versionof
theappliationontopofthenewplatform. Thegoalistodesigntheappliation
forthenewplatforminorderto makeitmoreeient,morereliable,easierto
maintainoreasiertoextendthanthelegayappliation. Inpratiethismeans
thatthenewodeshouldrespettheodingstandardsandbestpratiesofthe
targetplatformlanguages,itshouldtakeintoaountthespeirequirements
related to the software development proess used by the ustomer ompany,
thereshould bemodelsforthenewappliation,et.
InthemigrationproessimplementedbySodifranethe rsttwosteps(as
presentedongure1)areusuallyompletelyautomated,i.e. alltheinformation
fromthelegaysystemisrepresentedinthepivotmodel. Thisistoonentrate
the manualeorton the transformationfrom the pivot model to the newap-
pliationandavoidhavingtodealmanuallywiththelegayodeasawhole. If
someelementsofthe legayodeannottproperlyin thepivot model,these
elementsareapturedasnotesortagsandpresentedtothedeveloperwhenthe
orrespondingpartsof theappliation aretransformedorgenerated.
Tomaximizetheeienyofthemigrationproess,thetasksthatareleftto
thedeveloperhavetobelearlyidentiedandthedevelopershouldbeprovided
withalltheinformationheorsheneeds. Thisistakenintoaountinthedesign
ofthe transformationsandodegenerators. Forexamplein thease ofaJava
odegenerator,T ODOdiretivesanbegeneratedforeverypieeofodethat
requires manual inspetion, re-fatoringorompletion. This T ODO diretive
anontainthe kindofworkthat has tobedoneand referenesto themodel
elementsthat arerelevantto it. TheT ODO diretivesare summarized intoa
tasklistwhihgivesthedeveloperalearviewofwhathastobedone.
2.1.3 Migration projet phases
Priorto the atualmigration and implementationof the newappliation, the
design, the implementation and the validation of a projet spei migration
proess must be ompleted. This inludes the parsing of legay languages,
reverseengineeringtransformations,high-leveldesignofthenewappliationand
mappingsbetweenthestruturesofthelegayappliationandtheoneptsof
thetargetplatform. Allthesetasksrequiresomeeortduetotheiromplexity
and their overall inuene on the migration projet. In the projetstruture
used by Sodifrane, asrepresented ongure 3, there are three projet phases
before theatualmigrationanstart.
Therstphaserepresentedongure3isatehnialanalysis. Itsobjetive
istostudythelegayplatform,denethetargetplatformandspeifythetools
thatare neededbythemigration proess. This phaseis ruial forthemigra-
tion projet. It is used to estimate the eort that would be required for the
developmentofthetoolsandthetotaleortthatwouldberequiredforthemi-
gration. Attheendofthetehnialstudyatotalontratualprieisproposed
to theustomer. During thetehnialstudy a small omponent of thelegay
appliationis usuallymigrated using generitoolsand manuallyompleted to
maththeodethat would beproduedusingthenal tools. Thisservesasa
testforthetoolspeiationsandasademonstrationoftheresultingodethe
ustomeranexpet. IfboththeprieproposedbySodifraneandthequality
ofthemigratedodearesatisfatorytotheustomer,theprojetanarryon.
Theseondphaserepresentedongure3isatooldevelopmentphase. The
objetiveisto developallthe toolsthat havebeenspeiedfor themigration
proess. Most of thetime thetoolsdonothaveto bedevelopedfrom srath
butareratherre-usedoradaptedfrompreviousprojets. However,mostofthe
timeevenifthelanguageisthesame,thelanguageversionandtheodingstyle
mightbedierentandrequiresomeadaptation.
Thethird phaserepresentedongure3isapilotprojet. Theobjetiveof
thepilotprojetistovalidateandnetunethemigrationproessandthetools
ituses. Italsoservesasademonstrationoftheviabilityoftheproessandallows
measuringitseienypreisely. Duringthisphase,aomponentofthelegay
appliationisusedasabenhmarkforthemigrationproess. Thisomponent
hastobehosentobeasrepresentativeaspossibleoftheomponentsoflegay
appliation. Inpratie thedevelopmentof thepilot projetis trulyatesting
and debugging phase for the migration tools. For this reason it is usually a
lot longer than the migration of aomparable omponentone the migration
proess is fully-funtional. At the end of the pilot projet, the ustomer is
provided with a nal prie for the projet and has a sample of how the new
appliationwouldlook like.
Projetsseldom haveto stopafter the pilotprojet: the atual migration
usuallystartsshortlyafterwards. Thepreparationofamodel-drivenmigration
proessanbequitelong(thethreephasesdesribedpreviouslyusuallyrequire
around6monthstoompletebutanlastuptoayearonspeiprojetssuh
astheonedesribedinsetion3.3),butonetheproessisupandrunning,the
migrationrateanbefarmorerapidthanwithanyompetingtehniques. This
isdisussedinsetion3.4,butbeforethat,thenextsetionpresentsthemodel-
driven engineering tools used by Sodifrane to pratially implement model-
drivenmigration.
Figure4: Model-In-Ationtoolsuitearhiteture
2.2 Model-In-Ation (MIA) tool suite
Implementingthe migrationproess presentedin theprevioussetion requires
advaned, salable and reliable toolsfor model transformation and ode gen-
eration. For both the needs of migration projet and development projets,
Sodifrane hasdeveloped Model-In-Ation (MIA)[23℄, asuiteof model-driven
engineeringtools. Thissetiongivesaquikoverviewofthesetools.
Figure4presentsasimplied arhiteturediagramfortheMIA tools. One
oftheessentialrequirementforaompanylikeSodifraneistobeabletoadapt
toanyspeimodelingtehnologyusedbytheirlients. InthedesignofMIA
this hasbeentakeninto aountbyreatingagenerimodelingplatformthat
anonnetthroughvarious driverstoexisting repositoriesand modelers. On
topofthis generimodelinglayerthesuiteis omposedof twomain produts:
MIA-Transformation formodel-to-modeltransformation and MIA-Generation
forodegeneration.Eahofthesetoolsisdividedinthreetypesofomponents:
Coreenginesformodeltransformationsandodegeneration. Theseom-
ponentsare ontopof themeta-modelingAPI and donothaveanyuser
interfae. Theyareresponsiblefortheexeutionofmodeltransformations
andodegenerators.
Developmentenvironmentsformodeltransformationsandodegenerators
(MIAArhitetenvironments). Theseenvironmentsareusedbysoftware
arhitets to design and implement the model transformations andode
generatorsrequiredbyMDE projets.
Userenvironments for model transformation and ode generators (MIA
developerenvironments). Therearenotonlystandaloneversionsofthese
tools but also plug-in versions that integrate diretly in the IDEs and
modelersofthesoftwaredevelopers.
MIA-Transformationisarule-basedmodel-to-modeltransformationengine.
Amodeltransformationisdened byasetofrulesdenedbetweensomeinput
meta-models and some output meta-models. Eah rule is omposed of three
elements:
