127627-Rétro-Ingénierie Des Modèles

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
Ministre de lEnseignement Suprieur et de la Recherche Scientifique Universit El Hadj Lakhdar BATNA
Facult des Sciences et des Sciences de lingnieur
Dpartement dInformatique
N dordre : Srie :
Mmoire prsent en vue de lobtention du diplme
Magister en Informatique
Option: Systme dInformation et Connaissance
SUJET DU MMOIRE :
Rtro-ingnierie des modles comportementaux dUML 2
Prsent le : 28 /09 /2010 Par : Wahab ROUAGAT

Composition du jury : Dr. Brahim BELATTAR Dr. Tewfik ZIADI Dr. Allaoua CHAOUI Pr. Nacerdine ZAROUR Dr. Ezeddine BILAMI Prsident Rapporteur Rapporteur Examinateur Examinateur (Matre de confrences luniversit de Batna). (Matre de confrences lUniversit de Paris 6 France) (Maitre de confrences luniversit de Constantine). (Professeur lUniversit de Constantine). (Maitre de confrences luniversit de Batna).
Ddicace
La louange est Allah Le Clment et Le Misricordieux et que la prire et le salut de mon Seigneur soient sur son Prophte et son Serviteur Mohammed ( Je ddie cet humble travail : A mes trs chers parents, faible tmoignage de ma reconnaissance pour leurs inestimables efforts consentis dans lunique souci de ma russite et de mon bien tre ; A mes frres, mes surs, et tous les membres de la famille ROUAGAT et MIMI ; A ma chrie ma fidle fiance ; A tous mes amis et toutes personnes ayant contribu de prs ou de loin la ralisation de ce mmoire ; A Mr. Haroun CHENCHOUNI. ).
Remerciements
Au terme de ce modeste travail, je tiens exprimer ma gratitude et prsenter mes vifs remerciements tous ceux qui ont particip de prs ou de loin sa ralisation. Je rends un hommage particulier : - Au Dr. Tewfik ZIADI, du Laboratoire dInformatique (Universit de Paris 6, France) : Celui qui a toujours apprci mes initiatives et qui ma encourag atteindre mes objectifs. - Au Dr. Allaoua CHAOUI de luniversit de Constantine, celui qui ma aid dans la ralisation de ce travail, notamment par ses conseils trs utiles. - Ma gratitude va galement aux honorables membres de jury qui ont bien voulu prendre le soin de lire ce manuscrit et de juger ce travail : Dr. Brahim BELATTAR (Matre de confrences luniversit de Batna) Pr. Nacerdine ZAROUR (Professeur lUniversit de Constantine). Dr. Ezeddine BILAMI (Maitre de confrences luniversit de Batna). - A toute personne ma enseign, depuis le primaire jusqu luniversit. Merci tous ceux qui ont particip la ralisation de ce travail. - A tous les collgues, enseignants-chercheurs, responsables et staff administratif du dpartement dInformatique de lUniversit de Batna, en particulier Mr. Boubakeur AZOUI.
Table de matire
TABLE DE MATIRE .................................................................................................................... 1 LISTE DES FIGURES ..................................................................................................................... 4 INTRODUCTION ........................................................................................................................... 6 PARTIE 1 : TAT DE LART ......................................................................................................... 9 CHAPITRE 1 : RTRO-INGNIERIE ........................................................................................... 10 1. 2. 3. 4. Introduction ................................................................................................................. 10 Origine et Dfinition de la rtro-ingnierie ................................................................. 10 Apports de la rtro-ingnierie logiciel ......................................................................... 11 tapes de la rtro-ingnierie ....................................................................................... 12 4.1 Collection de donnes ........................................................................................... 12 Techniques de collection dinformations ....................................................... 12
4.1.1 4.2 4.3 5. 6.
Extraction dinformations pertinentes .................................................................. 13 Visualisation........................................................................................................... 14
La rtro-ingnierie des logiciels orients objet ........................................................... 15 Conclusion .................................................................................................................... 16
CHAPITRE 2 : LANGAGE DE MODLISATION UNIFI (UML) ................................................. 17 1. 2. 3. 4. Introduction ................................................................................................................. 17 Historique dUML ......................................................................................................... 17 La Mta-Modlisation .................................................................................................. 18 Les Diagrammes dUML2 ............................................................................................. 19 4.1 4.2 Les machines tat ............................................................................................... 20 Les diagrammes de squence................................................................................ 21 Les interactions .............................................................................................. 21 Les mcanismes de composition .................................................................... 22
4.2.1 4.2.2 5.
Conclusion .................................................................................................................... 26
CHAPITRE 3 RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX .................................. 27
1. 2.
Introduction ................................................................................................................. 27 Etat de l'art sur la rtro-ingnierie des modles comportementaux d'UML .............. 27 2.1 2.2 Travaux de la rtro-ingnierie des machines tats ............................................ 27 Travaux de la rtro-ingnierie des diagrammes de squence dUML .................. 28 Travaux bass sur l'analyse statique ............................................................... 28 Travaux bass sur l'analyse dynamique ......................................................... 29 Travaux bass sur l'analyse hybride ............................................................... 34
2.2.1 2.2.2 2.2.3 2.3
Discussion et conclusion ........................................................................................ 35
PARTIE 2 : CONTRIBUTION .................................................................................................... 38 CHAPITRE 4 : APPROCHE INCRMENTALE.............................................................................. 39 1. 2. 3. Introduction ................................................................................................................. 39 Exemple pour illustration............................................................................................. 39 Approche incrmentale ............................................................................................... 40 3.1 3.2 La Collection de traces........................................................................................... 41 Construction incrmentale du diagramme de squence ...................................... 45 Dtection des oprateurs ................................................................................ 48 Fragment combin avec loprateur "loop" ....................................................... 48 Fragment combin avec loprateur "opt" ......................................................... 51 Fragment combin avec loprateur "alt" .......................................................... 53 Fragment combin avec loprateur "seq" ......................................................... 56
3.2.1 a) b) c) d) 4.
Conclusion .................................................................................................................... 57
CHAPITRE 5 IMPLMENTATION ............................................................................................... 58 1. Outils dimplmentation .............................................................................................. 58 1.1 1.2 1.3 2. Outils de collection de traces ................................................................................ 58 Stockage des donnes ........................................................................................... 61 API UML2 ............................................................................................................... 63
Application de lapproche sur lexemple Vente ........................................................... 64
2.1
Cas dutilisation ..................................................................................................... 64
CONCLUSION ET PERSPECTIVES ............................................................................................... 70 1. 2. 3. valuation .................................................................................................................... 70 Discussion des rsultats ............................................................................................... 70 Perspectives ................................................................................................................. 71
RFERENCES ............................................................................................................................. 72 ANNEXES ................................................................................................................................... 76 (1) Code de dtection des fragments combins de type "loop"....................................... 76 (2) Code source de lapplication Vente.......................................................................... 77
Liste des figures

FIG.1.1. MODLE DARCHITECTURE DES OUTILS PAR [3] ...................................................... 11 FIG. 1.2. TAPES PRINCIPALES DE LA RTRO-INGNIERIE...................................................... 12 FIG. 1.3. GRAPHE DINTERACTION GNR AVEC PROGRAM EXPLORER [44] ..................... 15 FIG. 2.1. LARCHITECTURE QUATRE NIVEAUX DE LOMG ................................................. 19 FIG. 2.2. EXEMPLE DE MACHINE TAT ................................................................................. 21 FIG. 2.3. UNE PARTIE DU MTA-MODLE DES DIAGRAMMES DE SQUENCE DUML2 .......... 22 FIG. 2.4. EXEMPLE DUN DS DANS UML2.0 ET SES CONCEPTS .............................................. 23 FIG. 2.5. EXEMPLE DES RFRENCES VERS LES DS DANS UML2 .......................................... 23 FIG. 2.6. EXEMPLE DUN DIAGRAMME DE SQUENCE COMBIN ............................................ 25 FIG. 2.7. EXEMPLE DUN DIAGRAMME DE VUE DENSEMBLE DINTERACTION DANS UML2 . 25 FIG. 3.1. CFG ET SON DIAGRAMME DE SQUENCE CORRESPOND [1] ..................................... 29 FIG. 3.2. DS APRS LEXCUTION DE DEUX ITRATIONS DUNE BOUCLE [7] ......................... 30 FIG. 3.3. ARCHITECTURE DE JAVAVIS [7] ............................................................................ 31 FIG. 3.4. MTA-MODLE DE DIAGRAMME DE SCNARIO BRIAND ET AL. [12] ....................... 32 FIG. 3.5. MTA-MODLE DE TRACE BRIAND ET AL. [12] ........................................................ 32 FIG. 3.6. APPARIEMENT ENTRE TRACE ET SQUENCE MTA-MODLES BRIAND ET AL. [12] 33 FIG. 4.1. LA CONSTRUCTION INCRMENTALE DU DIAGRAMME DE SQUENCE...................... 41 FIG. 4.2. TRACES
DE LAPPLICATION
VENTE
AVEC LES DONNES DENTRE DE CHAQUE
TRACE ....................................................................................................................................... 42
FIG. 4.3. EXEMPLE DE TRACE ................................................................................................. 43 FIG. 4.4. LA DCOMPOSITION DES TRACES EN BLOCS ............................................................. 48 FIG. 4.5. DS DE VENTE APRS APPLICATION DE LALGORITHME DTECTION DE LOOP. ........ 50 FIG. 4.6. DS DE VENTE APRS LAPPLICATION DE LALGORITHME DTECTION DE OPT ........ 53 FIG. 4.7. DS FINAL DE LAPPLICATION VENTE......................................................................... 57 FIG. 5.1. CODE SOURCE DE LEXEMPLE LOOP.JAVA .............................................................. 58 FIG. 5.2. VERSION NON INSTRUMENT DE LA MTHODE M1(). ............................................... 59 FIG. 5.3. VERSION INSTRUMENT DE LA MTHODE M1(). ...................................................... 59 FIG. 5.4. TRACE 2 DE LAPPLICATION VENTE GNRE PAR LOUTIL MODEC .................... 60 FIG. 5.5.
TRACE2 ADAPT DE LAPPLICATION VENTE ............................................................ 61
FIG. 5.6. LE MODLE RELATIONNEL INTERMDIAIRE ........................................................... 62 FIG. 5.7. VUE INITIALE DE LA TABLE MESS_TR ..................................................................... 65 FIG. 5.8. VUE FINALE DE LA TABLE MESS_TR ........................................................................ 66 4
FIG. 5.9. VUE FINALE DE LA TABLE COMBINED_FRAGMENTS ................................................ 67 FIG. 5.10. VUE FINALE DE LA TABLE OPERANDS .................................................................... 67 FIG. 5.11. LE DIAGRAMME DE SQUENCE GNR AFFICH PAR UN DITEUR ECLIPSE ...... 68 FIG. 5.12. UNE
PARTIE DU
DS
REPRSENTE UN FRAGMENT COMBIN SOUS FORME DUN
DOCUMENT UML...................................................................................................................... 69
INTRODUCTION
Introduction
Les systmes logiciels sont devenus trs importants dans notre vie quotidienne. Ils contrlent les machines de payement, les instruments mdicales, les systmes de tlcommunication et plusieurs dautres systmes. A cause de leur intrt et leur vaste domaine dapplication, tout comportement non dsir ou erreur de fonctionnement peut engendrer des pertes dargent, arrts de services et des risques de vies. La fiabilit de logiciels devient donc un facteur suprme. Dautre part, lvolution de besoins et le
changement continu de contextes de fonctionnement ncessitent la mise jour et la maintenance courante de ces systmes. Dans le cycle de vie de dveloppement des applications logicielles, ltape de maintenance est ltape la plus critique, et elle consomme environ 90% de lensemble des ressources utilises [5]. La tache principale de la maintenance est de comprendre lapplication en analysant sa structure et lorganisation de ses composants afin de fixer les problmes et/ou dajouter des nouvelles caractristiques [5]. Utiliser directement le code source pour comprendre une application est une tache difficile pour trois raisons principales : 1) les applications sont de plus en plus complexes et leur code source est dispers sur des milliers voir des millions de lignes de code. 2) les applications, principalement les anciennes (connues par lappellation legacy systems ), sont souvent codes dans des langages de programmations obsoltes peu connus actuellement par les mainteneurs1. 3) la maintenance est souvent ralise par des individus qui nont pas t impliqus dans le codage de lapplication. Ainsi, les mainteneurs ont besoin de disposer dune reprsentation abstraite permettant de grer la complexit des applications. Dautre part, il est important que cette reprsentation soit dcrite dans un langage universel connu par un trs grand nombre de mainteneurs.
La rtro-ingnierie logicielle est le champ du gnie logiciel permettant de rpondre aux besoins des mainteneurs. Elle est dfinie comme le domaine qui a pour but danalyser le code du logiciel et de le reprsenter automatiquement sous une forme abstraite pour que sa
Nous utilisons dans le reste de ce document le mainteneur pour dsigner toute personne implique dans la
tache de maintenance.
INTRODUCTION maintenance et sa comprhension soient plus faciles [6]. La rtro-ingnierie des modles UML sintresse reprsenter le logiciel sous forme de modles UML. En effet, Le langage unifi de modlisation UML (Unified Modeling Language)
1
propose un ensemble de
notations (appels diagrammes UML ) pour reprsenter dune manire abstraite les diffrents aspects dune application. Les deux aspects principaux considrs dans UML sont laspect structurel et laspect comportemental. Laspect structurel dcrit larchitecture statique de lapplication. Les diagrammes de classes, de composants sont des exemples de diagrammes UML permettant de reprsenter laspect structurel des applications. Laspect comportemental dcrit principalement les interactions entre les objets pour raliser les fonctionnalits de lapplication. Les diagrammes de squence et les machines tats sont les principaux diagrammes comportementaux dUML. La rtro-ingnierie des modles UML a attir beaucoup dattentions ces dernires annes. Dune part au sein des outils CASE UML o cette fonctionnalit est intgre dans la quasi-totalit des outils UML [63]. Dautre part au sein de la communaut acadmique o plusieurs travaux de recherche se sont intresss ce sujet. Cependant, et comme nous allons voir par la suite les travaux existants, plusieurs constats dinsuffisance sont dgags : 1. La majorit des travaux existants, autour de la rtro-ingnierie des modles UML, sintresse seulement laspect structurel notamment les diagrammes de classes. 2. Le peu existant qui sintresse laspect comportemental et principalement aux diagrammes de squence ne gnre que des modles correspondants un seul scnario2 particulier dexcution du systme. 3. La majorit des travaux existants ne supporte pas la nouvelle version des
diagrammes de squence dans UML2 et en particulier les oprateurs dinteraction rcemment introduits. 4. Les solutions proposes sont trs lies aux langages et plateformes dans lesquels se tournent les systmes tudis. Dans ce travail, nous proposons en premier lieu un tat de lart autour du domaine de la rtro-ingnierie logicielle. Nous nous sommes principalement intresss la rtroingnierie des diagrammes de squence dUML. Nous prsentons une tude comparative des travaux existants dans ce contexte. Par la suite, nous proposons de revisiter ce problme de
Dans le reste de ce document nous utilisons conjointement diagramme UML et modle UML pour
dsigner la mme chose.

2
Le mot scnario dsigne lensemble de donnes dentre choisi dans une instance dexcution dun systme.
INTRODUCTION rtro-ingnierie des diagrammes de squence dUML2 en produisant une nouvelle approche. Cette approche est base sur une analyse dynamique du systme et prend lentre un ensemble de traces collectes dans les diffrentes sessions dexcutions du systme considr. Nous avons dvelopp des heuristiques qui permettent de dtecter les diffrents types doprateurs dinteraction et construire un diagramme de squence dUML reprsentant le comportement global du systme tudi. Notre approche est implmente dans un prototype outil et valide sur une tude de cas. Le reste de ce document est divis en deux partie : 1) tat de lart 2) Contribution. Dans la premire partie nous prsenterons en premier lieu le domaine de la rtro-ingnierie et les travaux existants dans le contexte des modles comportementaux dUML. La deuxime partie va prsenter notre approche en dtaillant ses diffrentes tapes.
Partie 1 : tat de lart
CHAPITRE I
LA RTRO-INGNIERIE
Chapitre 1 : Rtro-ingnierie
1.
Introduction
Dans ce chapitre nous explorons la rtro-ingnierie en prsentant ses diffrents
domaines dapplication dans la littrature. Nous nous sommes intresss particulirement la rtro-ingnierie lis au domaine du gnie logiciel. Nous dterminons ses apports et ses tapes principales, ses approches existantes et les diffrents niveaux dabstraction viss par la rtroingnierie oriente objet.
2.
Origine et Dfinition de la rtro-ingnierie

Daprs [4], la rtro-ingnierie revient aux annes de la rvolution industrielle. Elle
est semblable la recherche scientifique o les chercheurs essayent dinventer des plans et des cartes aux phnomnes naturels. La seule diffrence est que la rtro-ingnierie concerne les objets crs par lhomme (des appareils mcanique, des composants lectronique, des programmes informatique, ). Dune faon gnrale, la rtro-ingnierie est le processus dextraction de connaissances ou de concevoir des reprsentations partir de tout ce qui est construit par lhomme. Dans le contexte de lingnierie logicielle, le terme rtro-ingnierie a t dfini en 1990 par Chikofsky et Cross dans [3] comme le processus danalyse dun systme pour (1) identifier les composants du systme et leurs interrelations, et (2) crer des reprsentations du logiciel dans une autre forme ou dans un niveau dabstraction plus lev. La rtro-ingnierie a t traditionnellement vue comme un processus en deux tapes : lextraction des informations et labstraction. Ltape dextraction des informations analyse les artefacts du logiciel pour recueillir des donnes brutes, tandis que ltape dabstraction cre des vues et documents orients utilisateur partir des donnes brutes [25]. Chikofsky et Cross ont prsent une structure de base pour les outils implmentant la rtro-ingnierie (voir Fig.1.1.). Le logiciel tudi est analys et les rsultats de cette analyse sont stocks dans une base dinformations. Par la suite, ces informations sont utilises pour produire diffrentes vues du logiciel, comme les diagrammes, les rapports, et les mtriques. .
10
CHAPITRE I
LA RTRO-INGNIERIE
Fig.1.1. Modle darchitecture des outils par [3]
3.
Apports de la rtro-ingnierie logiciel

La rtro-ingnierie est trs utile aux dveloppeurs des logiciels. En effet, ils lutilisent
comme un moyen de coopration et collaboration autour des logiciels qui ne disposent pas (ou qui disposent partiellement) de la documentation. Ils peuvent lutiliser aussi pour tudier et amliorer les logiciels concurrents. De plus, la rtro-ingnierie permet dvaluer la qualit et la robustesse dun logiciel. Elle est galement le moyen essentiel dans les diffrentes taches de ltape de maintenance qui reprsente une tape trs importante dans le cycle de vie de logiciel. En effet, une enqute effectue aux USA en 1986 auprs de 55 entreprises a rvl que 53% du budget total dun logiciel est affect la maintenance [27]. La rtro-ingnierie facilite les taches de
maintenances car elle permet de proposer aux personnes intervenant dans la maintenance des reprsentations plus abstraites qui leur permet de comprendre le logiciel pour le tenir jour en fonction des nouveaux besoins des utilisateurs. En plus de faciliter la maintenance de logiciels, six autres objectifs de la rtro-ingnierie ont t identifi dans [3] : Faire face la complexit. Gnrer diffrentes vues. Recouvrir des informations perdues. Dtecter leffet de bord. Synthtiser des abstractions de haut niveau. Faciliter la rutilisation.
11
CHAPITRE I
LA RTRO-INGNIERIE
4.
tapes de la rtro-ingnierie
Le schma gnrale de la rtro-ingnierie comme il a t identifi dans [3] se compose
de trois tapes principales est illustr dans la Figure Fig. 1.2. : 1) collection de donnes, 2) extraction dinformations pertinentes, 3) visualisation. Nous dcrivons dans les sections suivantes chacune de ces trois tapes.
chantillonnage, Filtrage, Compression,
Extraction dinformations pertinentes
Collection de donnes
Visualisation
Analyse : hybride, Dynamique & Statique
Formes Personnelles & Standards
Fig. 1.2. tapes principales de la rtro-ingnierie
4.1
Collection de donnes Cette tape consiste analyser le systme pour obtenir les donnes ncessaires la
comprhension de ses diffrents aspects structurels et comportementaux. Il existe plusieurs techniques de collection dinformations qui peuvent tre classes en trois catgories : analyse statique, analyse dynamique et analyse hybride. 4.1.1 1) Techniques de collection dinformations Lanalyse statique. Dans ce type de techniques, les informations sont collectes
directement auprs du code compil ou du code source d'un programme sans l'excuter. Les informations peuvent tre recueillies dans le cadre statique, par le contrle des flux de donnes ou par l'insertion d'annotations dans le code pour marquer les points d'intrt et de guider cette analyse. Un exemple doutils qui suivent ce type danalyse, comporte les dsassembleurs qui permettent dobtenir partir de code machine binaire un texte dans un langage assembleur, et les d-compilateurs qui essayent de produire des codes sources de langages de haut-niveau partir des codes binaires.
12
CHAPITRE I 2)
LA RTRO-INGNIERIE
Lanalyse dynamique. Selon [18], lanalyse dynamique est lanalyse des proprits
dun programme en cours dexcution. Limportance de lanalyse dynamique est drive de ses caractristiques essentielles qui sont : 1) La prcision des informations : Avec lanalyse dynamique, il est possible de collecter prcisment les informations pertinentes qui ne comprennent que des comportements possibles. 2) Dpendance aux entres des programmes : lanalyse dynamique est caractrise par le fait que ses rsultats sont lis aux donnes dentres et de sorties de programme.. Cela permet daider les dveloppeurs comprendre le logiciel en tudiant comment il change son comportement en fonction des diffrentes entres et sorties [26]. Il existe plusieurs techniques danalyse dynamique pour la collection des donnes. Parmi ces techniques nous citons : les outils de contrle du systme, linstrumentation du code source, linstrumentation du byte code (code intermdiaire), linstrumentation de la machine virtuelle et lutilisation des dbogueurs personnaliss [5]. Par ce type danalyse la collection des informations se traduit par la gnration des traces. Une trace montre les valeurs des variables du programme, l'tat de la pile d'excution, les occurrences d'appels des mthodes, l'tat des threads ou toute autre information d'excution [26]. 3) Analyse hybride. Lanalyse hybride permet de combiner conjointement lanalyse
statique et lanalyse dynamique pour la collection des donnes. Cela permet de profiter des avantages des deux types danalyse. En effet, les informations collectes par lanalyse statique peuvent fournir une connaissance gnrale sur le comportement du systme et lanalyse dynamique permet de lamliorer. 4.2 Extraction dinformations pertinentes Ltape prcdente permet de collecter des donnes brutes et de grand volume. Donc, Il devient ncessaire de nettoyer ces donnes avant quelles soient utilises dans ltape de visualisation, cest le rle de ltape dextraction dinformations pertinentes. Particulirement dans lanalyse dynamique, Une trace de grand volume pose un problme majeur qui est la perte de linformation utile dans la totalit dinformations collectes. Par consquence, plusieurs techniques de lextraction dinformations pertinentes ont t dveloppes telles que lchantillonnage et la technique de cacher des composants [23] :
13
CHAPITRE I
LA RTRO-INGNIERIE
L'chantillonnage. L'chantillonnage est un moyen intressant de rduire la taille de la trace, il a t utilis dans AVID [45]. Il s'agit de choisir seulement un chantillon de la trace de l'analyse au lieu dutiliser toute la trace. Cependant, trouver les bons paramtres d'chantillonnage n'est pas une tche facile, et mme si certains paramtres vont bien pour comprendre une caractristique, il n'est pas vident quils soient utiles avec une autre. Cacher de Composants. Une autre faon de rduire la taille de la trace est de cacher certaines de ses composants. Par exemple, l'analyste peut dcider de cacher toutes les invocations d'une mthode spcifique. 4.3 Visualisation La visualisation est une tape cruciale pour la rtro-ingnierie. La faon dont l'information est prsente aux dveloppeurs ou aux mainteneurs affecte fortement l'utilit de ltape d'analyse ou les techniques dextraction dinformations pertinentes. Il existe deux choix de visualisation, soit dutiliser des diagrammes bien dfinis et largement adopts (standards) comme ceux dUML, ou dutiliser des notations propre lanalyste (Personnelle) o la visualisation constitue le principe d'une technique de rtro-ingnierie [25]. Des exemples d'outils capables de visualiser l'information extraite statiquement incluent loutil Rigi [43], CodeCrawler [41], et sv3D [42]. Certains de ces outils, comme Rigi, visent montrer des vues d'architecture. Autres outils, comme sv3D, fournissent des techniques de visualisation en 3D de paramtres dartefacts du logiciel. Loutil CodeCrawler combine la capacit de montrer les entits des logiciels et leurs relations, avec la possibilit de visualiser les paramtres du logiciel en utilisant les vues poly-mtriques, qui montrent les diffrents paramtres en utilisant la largeur, la longueur et la couleur. Certains outils de visualisation, tels que Program Explorer [44], permet de visualiser des informations dynamiques (e.g. les interactions entre les objets) en les modlisant sous forme dun graphe orient appel graphe dinteraction (voir Fig. 1.3.). Les nuds reprsentent les objets et les arcs reprsentent les mthodes appeles. Les arcs sont tiquets par les temps dappel et retour des mthodes.
14
CHAPITRE I
LA RTRO-INGNIERIE
Fig. 1.3. Graphe dinteraction gnr avec Program Explorer [44]
5.
La rtro-ingnierie des logiciels orients objet

La comprhension des dapplications orientes-objet est une tche difficile qui se doit
de surmonter les particularits de ce paradigme. En effet, mme si ses particularits sont les points forts de ce type de programmation, elles lvent lanalyse et la comprhension des applications orientes-objet un autre niveau de difficult. Le cas du polymorphisme et la liaison dynamique rendent les traditionnels outils danalyse inadquats. Lobjectif essentiel de la rtro-ingnierie oriente-objet est de voir le systme par une vue descriptive dans le niveau dabstraction adquat [6]. Pour mieux comprendre les fonctionnalits dun logiciel il est trs ncessaire de choisir le bon niveau dabstraction [23] : Niveau instruction Ce niveau inclut lexcution de chaque instruction du code. La majorit des outils ne supporte pas cette vue lexception des dbogueurs. Ce niveau dabstraction va bien avec les activits spcifiques de maintenance comme la fixation des bugs. Niveau communication inter-thread Ce niveau soccupe de visionner les interactions entre les threads du systme. Peu sont les outils qui prisent en charge ce type dinteraction, et si cest le cas, souvent les autres niveaux sont omis comme dans Jinsight [1O]. Niveau objet Ce niveau concerne la visualisation des interactions des mthodes entre les objets. Ce niveau peut tre utile pour dtecter les fuites de mmoire et autres tranglements de performance. La majorit des outils supporte ce niveau. Niveau classe Dans ce niveau, les objets de la mme classe sont substitus par le nom de leurs classes. Ce niveau, qui est support par la majorit des outils, va bien avec les activits qui 15
CHAPITRE I
LA RTRO-INGNIERIE
requirent de haut-niveau de comprhension du comportement du systme, tels que le recouvrement de la documentation, et la comprhension de quelles classes implmentent une caractristique particulire. Niveau architectural Ce niveau consiste grouper des classes dans des clusters et montrer comment les composants du systme inter-actent les uns les autres.
6.
Conclusion
Lactivit de la rtro-ingnierie est trs importante car elle permet de comprendre un
systme existant en produisant des artefacts dun niveau dabstraction suprieur au code. Dans ce chapitre nous avons prsent les apports de la rtro-ingnierie et nous avons tudi ses tapes principales. cause de sa prsence importante dans lindustrie, le standard UML et ses modles taient lun des plus importants domaines dapplication de la rtro-ingnierie des systmes orients-objet. Dans le chapitre suivant nous allons prsenter le langage de modlisation unifi (UML) en se concentrant sur les modles comportementaux. Par la suite, le chapitre 3 prsente une tude dtaill autour de la rtro-ingnierie des modles comportementaux dUML.
16
CHAPITRE II
LANGAGE DE MODLISATION UNIFI (UML)
Chapitre 2 : Langage de Modlisation Unifi (UML)

1. Introduction
La description de la programmation par objets a fait ressortir ltendue du travail conceptuel ncessaire : dfinition des classes, de leurs relations, des attributs et mthodes, des interfaces etc. Pour programmer une application, il ne convient pas de se lancer tte baisse dans lcriture du code : il faut dabord organiser ses ides, les documenter, puis organiser la ralisation en dfinissant les modules et tapes de la ralisation. Cest cette dmarche antrieure lcriture que lon appelle modlisation, son produit est un modle [27]. Un modle est une reprsentation abstraite et simplifie (i.e. qui exclut certains dtails), dune entit (phnomne, processus, systme, etc.) du monde rel envie de le dcrire, de lexpliquer ou de le prvoir. Modle est synonyme de thorie, mais avec une connotation pratique : un modle, cest une thorie oriente vers laction quelle doit servir. Concrtement, un modle permet de rduire la complexit dun phnomne en liminant les dtails qui ninfluencent pas son comportement de manire significative. Il reflte ce que le concepteur croit important pour la comprhension et la prdiction du phnomne modlis. Les limites du phnomne modlis dpendent des objectifs du modle. Dans ce chapitre nous prsentons le langage unifi de modlisation UML avec ses notions et notations les plus importantes en montrant leurs faveurs aux intrts de la modlisation des systmes.
2.
Historique dUML
Dans les annes 90, une multitude de mthodes ont t proposes afin de renforcer la
spcification et la documentation de logiciel (Booch, OMT, OOSE, mthodes orientes objet, et autres). Cette diversit a engendr un problme dinteroprabilit entre les outils de modlisation qui a ralenti ladoption des mthodes de dveloppement de logiciels bass sur les modles. Dans ce contexte troubl par diffrents langages de modlisation, Grady Booch, Ivar Jacobson et Jim Rumbaugh ont propos le langage unifi de modlisation (UML Unified Modeling Language) [28]. UML a t conu pour unifier diffrentes notations graphiques de modlisation, tre le plus gnral possible et tre extensible afin de prendre en charge des contextes non prvus. UML est bas sur les fondements de lapproche objets, cest
17
CHAPITRE II
un langage visuel ddi la modlisation et cest un support fondamental pour gnrer des programmes. La premire version dUML a t publie en 1997 par lOMG. Depuis, UML est devenue la rfrence pour la cration de modles pour lanalyse et la conception de logiciels.
3.
La Mta-Modlisation
Un mtamodle est une spcification utilise pour crer des modles conformes (
cette spcification), par exemple, le mtamodle dUML. Depuis ses premires versions, le standard UML est caractris par sa smantique dfinie par une approche de mta-modlisation. Un mta-modle est la dfinition des constructions et des rgles de cration des modles. Le mta-modle dUML dfinit donc la structure que doit respecter tout modle UML. Le mta-modle dUML1.x est dfini dans un seul document, cependant le standard UML2 est maintenant divis en deux documents : UML2 Infrastructure [29] et UML2 Superstructure [28]. UML Infrastructure dcrit les constructions fondamentales utilises pour la dfinition dUML2 sous forme dune librairie dinfrastructure (Infrastructure Library). UML Superstructure rutilise et raffine la librairie dinfrastructure et dfinit le mta-modle proprement dit, vu par les utilisateurs. Lapproche de mta-modlisation adopte par lOMG est connue comme une hirarchie quatre niveaux [36] (voir la Figure 2.1) : Niveau mta-mta-modle (M3). M3 est le niveau mta-mta-modle, il dfinit le langage de spcification du mta-modle. Le MOF (Meta Object Facility) est un exemple dun mtamta-modle. Niveau mta-modle (M2). M2 est le niveau mta-modle. Le mta-modle dUML se situe ce niveau et il est spcifi en utilisant le MOF, c..d. les concepts du mta-modle dUML sont des instances des concepts de MOF. La Figure 2.1 montre deux mta-classes du mtamodle UML : Class et Association. Niveau modle (M1). M1 correspond au niveau des modles UML des utilisateurs. Les concepts dun modle UML sont des instances des concepts du mta-modle UML. La Figure 2.1 montre un extrait de diagramme de classes pour une application bancaire contenant deux classes Account et Customer lies par une association UML. Les deux classes sont des instances de la mta-classe Class et le lien est une instance de la mta-classe Association du mta-modle UML.
18
CHAPITRE II
Niveau objets (M0). M0 correspond au niveau des objets lexcution. Il sagit ici de deux objets must et acc des instances des deux classes Customer et Account respectivement. Le mta-modle dUML est dcrit en utilisant une partie de la notation dUML lui mme. Les concepts suivants sont utiliss : Les classes dUML, pour dcrire les mta-classes. Les attributs, pour dcrire les proprits attaches une mta-classe. Les associations, pour dcrire des liens entre les mta-classes. Les paquetages (packages), pour regrouper les mta-classses par domaine.
Fig. 2.1. Larchitecture quatre niveaux de lOMG
4.
Les Diagrammes dUML2

La notation UML est dcrite sous forme dun ensemble de diagrammes. La premire
gnration dUML (UML1.x), dfinit neuf diagrammes pour la documentation et la spcification des logiciels. Dans UML2.0 Superstructure [28], quatre nouveaux diagrammes ont t ajouts : il sagit des diagrammes de structure composite (Composite structure diagrams), les diagrammes de paquetages (Packages diagrams), les diagrammes de vue
19
CHAPITRE II
densemble dinteraction (Interaction overview diagrams) et les diagrammes de synchronisation (Timing diagrams). Ils sont regroups dans deux classes principales : Diagrammes statiques. Regroupe les diagrammes de classes, les diagrammes dobjets, les diagrammes de structure composite, les diagrammes de composants, les diagrammes de dploiement, et les diagrammes de paquetages. Diagrammes comportementaux. Regroupe Les diagrammes de squence, les diagrammes de communication (nouvelle appellation des diagrammes de collaboration dUML1.x), les diagrammes dactivits, les machines tats, les diagrammes de vue densemble dinteraction, et les diagrammes de synchronisation. Les travaux existants autours de la rtro-ingnierie des modles comportementaux dUML sintressent particulirement aux deux types de modles savoir : les diagrammes de squence et les machines tats. Ainsi, nous prsentons en dtail ces deux types de modles dans les sections suivantes. 4.1 Les machines tat Les scnarios tels que les diagrammes de squence dUML dcrivent la coopration de plusieurs objets pour raliser une fonctionnalit. Cependant la spcification du comportement dun seul objet est le domaine des techniques de modlisation orientes tats. Les machines tats et ses variantes comme les statecharts de Harel [62] sont des exemples de ces techniques. Une machine tats dUML (une variante des statecharts de David Harel) est gnralement associe une classe particulire. Elle dcrit le comportement complet de tous les objets instances de la classe. Le comportement dun objet est dcrit par un ensemble dtats et de transitions. La Figure 2.2 montre les concepts de base dune machine tat dUML. Les tats dcrivent certaines conditions sur lobjet et les transitions indiquent les ractions possibles de lobjet avec le respect des conditions de ltat courant et les vnements qui dclenchent ces ractions. Une transition est dfinie par : Un vnement dclencheur de la transition. Une condition garde de la transition. Une action excute lorsque la transition est tire.
20
CHAPITRE II
Fig. 2.2. Exemple de machine tat
4.2
Les diagrammes de squence Montrent les interactions entre les objets dont la reprsentation se concentre sur la
squence des interactions selon un point de vue temporel. Dans ce qui suit, nous prsentons en dtail ce type de diagramme car il est lobjet de notre recherche. Le standard UML2 a apport une refonte majeure aux diagrammes de squence. Il est maintenant possible de dcrire et spcifier les exigences sous forme dun ensemble de diagrammes de squence de base et par la suite de les composer en utilisant des oprateurs pour obtenir des scnarios plus complexes. Aussi, les diagrammes de squence dans UML2 sont maintenant considrs comme des collections partiellement ordonnes dvnements (au lieu des collections ordonnes de messages dans UML1.x), ce qui introduit la concurrence et lasynchronisme et permet la dfinition de comportements plus complexes [36]. 4.2.1 Les interactions Les diagrammes de squence dans UML2 [29] sont dfinis dans la section Interaction de UML2 Superstructure. La Figure 2.3 rsume cette section. La mta-classe Interaction spcifie une unit de comportement dcrivant lchange dinformation entre un ensemble dobjets dans un diagramme de squence. La mta-classe Lifeline spcifie un objet dans une interaction. InteractionFragment est une partie dinteraction. La composition entre une interaction et InteractionFragment spcifie quune interaction peut englober un ensemble de sous-interactions. CombinedFragment dfinit une composition dun ensemble de
InteractionOperand en utilisant un oprateur dinteraction (nous discutons plus en dtail la composition des diagrammes de squence ci-dessous). Chaque message est dfini par deux vnements : un vnement spcifiant son mission et un autre spcifiant sa rception. Lvnement dmission dun message prcde toujours lvnement de sa rception [29].
21
CHAPITRE II
Fig. 2.3. Une partie du mta-modle des diagrammes de squence dUML2
Une nouvelle notation des diagrammes de squence a t introduite dans UML2. Un diagramme de squence dUML2 est maintenant dcrit par un cadre rectangulaire libell par le mot cl sd (pour Sequence Diagram) dans le coin gauche suprieur. La Figure 2.4 montre la notation dun diagramme de squence simple dans UML2. 4.2.2 Les mcanismes de composition Comme nous lavons mentionn ci-dessus, la grande nouveaut dans la nouvelle gnration des diagrammes de squence dUML2 est la possibilit de composer les diagrammes de squence pour spcifier des comportements plus complexes. La composition des diagrammes de squence dUML2 est introduite par le moyen de deux mcanismes de base : les rfrences vers les DS et les oprateurs dinteractions.
22
CHAPITRE II
Fig. 2.4. Exemple dun DS dans UML2.0 et ses concepts
Les rfrences vers les DS. UML2 introduit la notion doccurrence dinteraction pour permettre un diagramme de squence de rfrencer un autre diagramme de squence. Une occurrence dinteraction est en quelque sorte un raccourci [29] vers une copie du contenu dune interaction. Le diagramme de squence SD2 dans la Figure 2.5 rfrence le diagramme de squence SD1. La rfrence vers un diagramme de squence est dcrite par un cadre rectangulaire libell par le mot cl ref dans le coin gauche suprieur ; le nom de DS rfrenc est spcifi au milieu du cadre.
Fig. 2.5. Exemple des rfrences vers les DS dans UML2
23
CHAPITRE II
Les oprateurs dinteraction. Les DS dUML2 peuvent tre composs en utilisant un ensemble doprateurs appels Oprateur dinteraction. Les oprateurs de composition possibles dans UML2 sont dfinis dans le mta-modle par lnumration
InteractionOperatorKind (voir Figure 2.3). Un oprateur dinteraction est associ une interaction combine (CombinedFragment -voir Figure 2.3) et il compose un ensemble doprandes dinteraction (InteractionOperand - voir la Figure 2.3). Nous dcrivons dans ce qui suit les oprateurs fondamentaux : La squence (seq). Loprateur de squence seq spcifie une squence faible entre les comportements des oprandes [28]. La composition squentielle faible signifie que les vnements situs dans le premier DS sur une ligne de vie particulire doivent tre excuts avant les vnements de deuxime DS situs sur la mme ligne de vie [28]. Mais seq nimpose pas de synchronisation entre des lignes de vie diffrentes. Lalternative (alt). Loprateur alt dfinit un choix entre les comportements dun ensemble de DS. Litration (loop). Loprateur loop spcifie litration de comportement dun DS. La squence forte (strict). Loprateur strict spcifie une composition squentielle forte. Au contraire de loprateur seq, o lordre est seulement impos sur les vnements sur la mme ligne de vie, loprateur strict spcifie que tous les vnements (quelle que soit leur localisation) du premier DS doivent tre excuts avant les vnements du deuxime DS. La composition parallle (par). Loprateur par spcifie que les vnements des oprandes peuvent tre excuts en parallle, c..d. dans nimporte quel ordre ou en concurrence. Option (opt). Loprateur opt spcifie un choix entre le comportement dun DS ou un comportement vide. Cet oprateur est quivalent une alternative o le deuxime oprande est une interaction vide (sans vnements). La composition des diagrammes de squence dUML2 est dcrite dans des diagrammes de squence combins. La Figure 2.6 montre un exemple de diagramme de squence combin qui rfrence et compose trois diagrammes de squence : SD1, SD2 et SD3. Les oprateurs de composition dans les diagrammes de squence combins sont dcrits par des cadres rectangulaires avec un coin gauche suprieur labellis par loprateur (seq, alt, loop..etc). Les oprandes pour les oprateurs de squence, dalternative, et de paralllisme sont spars par des lignes horizontales discontinues. La composition squentielle peut tre aussi implicitement donne par lordre relatif de rfrence aux diagrammes de squence. Par exemple le DS CombinedSD dans la Figure 2.6, 24
CHAPITRE II
est quivalent lexpression : loop (SD1 seq (SD2 alt SD3)). UML2.0 propose aussi une autre notation pour la spcification de la composition des diagrammes de squence dans ce qui est appel les diagrammes de vues densemble dinteractions (qui sont en quelque sorte des diagrammes dactivits dont les activits sont des DS). La Figure 2.7 montre un exemple de diagramme de vues densemble dinteractions ; il est quivalent lexpression : SD1 seq (SD2 alt SD3).
Fig. 2.6. Exemple dun diagramme de squence combin
Fig. 2.7. Exemple dun diagramme de vue densemble dinteraction dans UML2
25
CHAPITRE II
5.
Conclusion
Notre choix des modles dUML pour la rtro-ingnierie est motiv par la prosprit
remarquable acquise par ce langage dans les domaines de modlisation et dveloppement des logiciels et son volution continue. Ainsi de son intgrit, complicit, et la possibilit dchange et communication dispose aux dveloppeurs. Comme nous lavons indiqu ci-devant dans lintroduction, les modles UML sont classs en deux catgories : les modles statiques qui dcrivent la structure et les modles dynamiques qui dcrivent le comportement. Une bonne comprhension dun systme ne peut tre acheve que par linclusion des deux aspects statique et dynamique, nanmoins peu sont les travaux de la rtro-ingnierie qui soccupent des modles comportementaux. Dans le chapitre suivant nous allons entamer la rtro-ingnierie des modles comportementaux.
26
CHAPITRE III
RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX
Chapitre 3 Rtro-ingnierie des modles comportementaux

1. Introduction
Dans ce chapitre nous nous intressons aux travaux de la rtro-ingnierie des modles comportementaux dUML. Comme nous lavons prsent au chapitre 2, les deux principaux types de modles comportementaux dUML sont les machines tats et les diagrammes de squence. Nous prsentons principalement les travaux concernant les machines tat et les diagrammes de squence. Ces deux notations dUML sont les plus intressantes dans les recherches existantes. Dans la section suivante nous prsentons un tat de lart qui est divis en deux parties. La premire partie prsente les travaux lis aux machines tat. Cependant, la deuxime partie est consacre une tude dtaille concernant la rtro-ingnierie des diagrammes de squence. Notre tude lie aux diagrammes de squence est plus dtaills que celle concernant les machines tats car notre sujet de recherche sintresse en particulier aux diagrammes de squence dUML. Nous concluions ce chapitre par la discussion des limites des travaux tudis et en fixant le cadre gnrale de notre approche que nous proposons dans la seconde partie de cette thse.
2.
2.1
Etat de l'art sur la comportementaux d'UML
rtro-ingnierie
des
modles
Travaux de la rtro-ingnierie des machines tats Plusieurs travaux de la rtro-ingnierie de machines tat ont t proposs [55, 56, 54,
57, 59]. Whaley et al dans [56] ont utilis le code source (analyse statique) en tant que base pour la rtro-ingnierie des machines tat, mais ils ont augment leur analyse avec des traces dynamiques du systme. Cette approche demande une certaine forme d'analyse de la structure du code source en fonction de ses donnes et contrle de flux. L'ide de construire des machines tat prsentant le comportement d'un programme partir des exemples dexcution (i.e des traces) a t propose initialement par Biermann et Feldman dans [57]. Ils ont propos un algorithme appel K-tails qui construit une machine tats partir de chaque trace en premier temps. Par la suite, ces machines tats vont tre fusionnes en se basant sur la similitude de leur comportement. Un autre algorithme appel QSM (Query-driven State Merging) [58] similaire k-tail et se base aussi sur la fusion des tats pour construire une machine tats globale. 27
CHAPITRE III
Walkinshaw et al dans le travail [59] ont propos une technique qui utilise lalgorithme QSM pour la rtro-ingnierie dune machine tat partir d'un ensemble de traces. Dans [26] Duarte a utilis une combinaison des informations statiques et dynamiques pour l'extraction des modles LTS (Labelled Transition Systems) partir de code source Java, suivant l'approche hybride. Les informations recueillies statiquement sont lies au systme de contrle de flux. Pour la partie dynamique, Duarte a utilis conjointement les informations de trace et les valeurs des variables du programme. Yuan et al dans [61] proposent une autre mthode d'extraction de machines tat pour un systme appel Brastra. Cette approche permet l'extraction automatique des machines tats partir des excutions des tests unitaire. 2.2 Travaux de la rtro-ingnierie des diagrammes de squence dUML Dans cette section nous prsentons une tude dtaille des travaux existants autours de la rtro-ingnierie des diagrammes de squence dUML. Les travaux existants sont prsents selon la technique de collection de donnes (voir section 4.1.1 dans le chapitre 1) utilise, savoir : analyse statique, analyse dynamique et analyse hybride. 2.2.1 Travaux bass sur l'analyse statique Parmi les travaux existants nous citons le travail de Rountev et al dans [1] qui propose un algorithme pour la rtro-ingnierie des diagrammes de squence dUML 2.0 par lanalyse statique du flux de contrle de code source java. Ils ont propos un mapping entre le graphe des flux de contrle gnral (CFG) et les diagrammes de squence dUML. Lobjectif ayant t de reprsenter le comportement itratif et conditionnel inter-procdural du systme sous forme dun diagramme de squence. La figure Fig. 3.1 illustre un exemple du mapping entre le CFG et le diagramme de squence dUML 2.
28
CHAPITRE III
Fig. 3.1. CFG et son diagramme de squence correspond [1]
Lanalyse statique permet de construire un diagramme de squence avec les fragments combines : alt, loop etc., cependant les diagrammes de squence obtenus ne montrent que les interactions entre les classes et ils ne permettent pas au dveloppeur de dterminer combien dobjets dune classe peuvent exister lexcution, ni de dire combien dappels de mthodes peuvent effectuer entre ces objets. 2.2.2 Travaux bass sur l'analyse dynamique La majorit des travaux existants utilise les techniques danalyse dynamique pour la collection de donnes. Dans la suite de cette section nous prsentons une tude dtaille de ces travaux. Dans [5], Janice a propos une mthode pour la rtro-ingnierie des diagrammes de squence en excutant le systme pour un seul cas dutilisation. Lapproche utilise linstrumentation du code intermdiaire pour construire les traces. Linstrumentation se concentre sur les messages de cration dobjet (les constructeurs), les messages dappel des mthodes et les contrles des flux de donnes de types itratif et alternatif. Oechsle et Schmitt dans [7] ont dvelopp loutil JAVAVIS qui permet aux utilisateurs de comprendre ce qui se passe lors de lexcution dun programme Java. Loutil est bas sur linterface de dbogage Java (JDI) pour visualiser le comportement dynamique 29
CHAPITRE III
sous forme dun diagramme dobjet et de squence (voir Fig. 3.2.) JAVAVIS se compose structurellement de deux parties essentielles (voir fig. 3.3): linterface de dbogage Java (JDI) qui se charge du contrle, et le noyau Vivaldi qui permet de gnrer les diagrammes. Dans [10] De Pauw et al. ont conu un outil appel Jinsight qui a pour but de visualiser plusieurs facettes du comportement du systme en se basant sur des traces dexcution. La technique dinstrumentation de la machine virtuelle a t utilise pour collecter ces traces. Loutil Jinsight implmente une technique dextraction de patrons qui a t propose pour simplifier les vues par limination des rptitions des messages.
Fig. 3.2. DS aprs lexcution de deux itrations dune boucle [7]
30
CHAPITRE III
Fig. 3.3. Architecture de JAVAVIS [7]
Briand et al dans [11] ont propos une mthode pour la rtro-ingnierie des diagrammes de squence partir des traces dexcution. Ils ont dfini deux mta-modles : le premier mta-modle dcrit les diagrammes de squence, et le dernier dcrit les traces dexcution. Un mapping entre les deux mta-modles est propos pour montrer la faon de driver un diagramme de scnario partir dune trace dexcution. Ce mapping, illustr dans la figure fig. 3.5., est dfini par un ensemble de contraintes consistantes dOCL (Object Constraint Language). Les traces sont gnres par linstrumentation du code source. Le diagramme de squence obtenu condense la trace dun ct (la squence des messages rpte napparatra quune seule fois avec une condition de rptition), et ajoute plus dinformations dun autre (la condition sous laquelle un appel est effectu est reporte dans le diagramme de scnario). Parmi les limites de ce travail est que son contexte est restreint sur une seule excution du systme qui correspond un seul cas dutilisation. Le rsultat obtenu est donc un diagramme de squence incomplet appel diagramme de scnario qui dnote seulement ce qui se passe dans un seul scnario particulier. Aussi, les imbrications ne sont plus supportes et toutes les classes sont instrumentes car il ny a pas de technique de slection partielle. Dans [12] Briand et al. ont complt leur travail [11] avec prise en charge des systmes distribus, mais avec un peu de diffrence o ils se sont bass sur linstrumentation du code intermdiaire (byte code). Ainsi quils ont instrument le code source pour dtecter les flux de control itratifs et conditionnels. La mme stratgie de mapping entre les deux
31
CHAPITRE III
mta-modles en dfinissant des rgles dcrites dans OCL est poursuivi comme il est indiqu dans fig. 3.4, fig. 3.5, et fig. 3.6.
Fig. 3.4. Mta-modle de diagramme de scnario Briand et al. [12]
Fig. 3.5. Mta-modle de trace Briand et al. [12]
32
CHAPITRE III
Fig. 3.6. Appariement entre trace et squence mta-modles Briand et al. [12]
Guhneuc et Ziadi dans [13] ont propos une approche danalyse dynamique pour la rtro-ingnierie des modles comportementaux dUML 2.0 (diagrammes de squence et machines tats). Lapproche est dfinie en trois tapes : Etape 1. Construire des diagrammes de squence de base partir de fichiers de traces gnrs par loutil danalyse dynamique Caffeine [38]. Etape 2. La composition de diagrammes de squence de base. Etape 3. La synthse des diagrammes dtats. Une fois les diagrammes de squence auraient t gnrs, ils produisent des machines tats automatiquement en utilisant une mthode existante [60] pour la synthse de machines tats. Une analyse de haut niveau concernant le contrle de conformit et lidentification des patrons a t aussi propose. Dans [16], la technique de dbogage a t utilise dans le dveloppement dun outil danalyse dynamique appel JavaTracer. Cet outil sauvegarde des traces lors de lexcution dun programme Java. Il met la faveur de lutilisateur de choisir les classes et les mthodes tracer. Loutil JavaTracer pourvoit des dtails sur les vnements dexcution sous forme de
33
CHAPITRE III
messages en indiquant lobjet appelant, lobjet appel, et la mthode excute pour en produire des diagrammes de squence. De plus des travaux prsents, il existe certains travaux qui se sont intresss extraire des informations plus utiles et pertinentes partir des traces dexcution : Richner et Ducasse dans [8] ont prsent une approche pour recouvrir les collaborations dans un logiciel implment dans un langage orient objet. Lapproche prend en entre une trace dexcution puis elle condense ces informations en reprsentant le comportement du programme par des patrons de collaboration. Enfin, elle prsente ces informations aux dveloppeurs en termes de classe expditrice, classe rceptrice, mthode invoque et patrons de collaboration. Dans [20] Hamou-Lhadj a propos une technique danalyse de traces dynamiques en rsumant leur contenu. La technique prend une trace dexcution lentre et gnre son rsum en sortie. Lauteur a inspir des techniques existantes de rsum de textes. Ces techniques permettent de reprsenter un texte par ces ides principales en vitant les dtails. Kuhn et al dans [21] ont propos une approche danalyse des traces dexcution des caractristiques (fonctions) de logiciels en utilisant la mthode de recherche dinformation LSI (Latent semantic indexing). Cette analyse a pour but didentifier les similarits entre les caractristiques en se basant sur les traces, ainsi de classifier les classes selon leurs frquences dans les traces.
2.2.3
Travaux bass sur l'analyse hybride Une tentative d'utilisation de cette approche est prsente dans [39], o les
informations statiques sont analyses afin de confirmer l'existence dinvariants dduits en se basant sur les informations dynamiques. Les auteurs ont russi dmontrer l'utilit de complter les informations dynamiques par des informations statiques. Toutefois, leur approche applique les deux types d'analyses, par consquence, elle ncessite l'utilisation de deux outils diffrents: l'un pour dduire les invariants des informations dynamiques et lautre pour vrifier ces invariants auprs des informations statiques. Dans [6], Systa a considr les deux aspects statique et dynamique, le premier pour modliser la structure statique du systme cibl, tant que le dernier pour modliser le comportement dexcution. Un environnement exprimental appel Shimba a t construit pour supporter la rtro-ingnierie des systmes logiciels Java en visant les deux aspects structurel et comportemental. Les informations statiques sont extraites partir des fichiers de classes de code intermdiaire Java (Java bytecode), par contre les informations dynamiques 34
CHAPITRE III
dvnements sont gnres aprs lexcution du systme sous un dbogueur JDK adapt baptis JDebugger. Le prototype Shimba intgre deux outils existants Rigi [43] et SCED. Aprs leur extraction, les informations statiques sont visualises dans lenvironnement Rigi, cependant, loutil de modlisation dynamique SCED est utilis pour la visualisation des informations dynamique sous forme de diagramme de scnarios. Grace aux techniques de JDebugger, Shimba a support le contrle des flux, ce qui permet lutilisateur dapercevoir les diffrentes structures conditionnelles Java (if, while, ..). Lenvironnement Shimba implique lutilisateur de dtecter les lments qui implmentent la fonction souhaite. Cela nest pas trs pratique dans de nombreuses situations. Antoniol et al dans [14] ont dvelopp un outil danalyse des applications web appel Wanda. Une approche de quatre tapes a t propose : 1) Analyse et instrumentation. 2) Lextraction des informations 3) Labstraction des modles 4) Prsentation des rsultats. Les auteurs de [14] ont combin les deux types de mthodes danalyse : statique et dynamique en se basant fortement sur la dernire qui sexprime par lanalyse de: Pages web HTML et PHP (instrumentation). Les variables denvironnement http. Les Cookies, les enttes, et les fonctions de gestion de sessions Les bases de donnes et fichiers dE /S. Les invocations des services web. Les accs aux bibliothques.
A la fin de cette analyse, plusieurs types de diagrammes dUML vont tre gnrs dont : diagramme de composant, diagramme de dploiement, diagramme de squence, et diagramme de classe.
2.3 Discussion et conclusion Le tableau 3.1 rcapitule les travaux tudis dans ce chapitre. Pour chaque travail, nous dcrivons le type de la mthode danalyse de systme utilise, la technique de collection de donnes considre et le niveau dabstraction vis.
35
CHAPITRE III
Travail Mthode danalyse suivie

Multi trace Niveau dabstraction vis objet classe Technique de collection de donnes Dbogage instrument
Opt, loop, break, alt Loop, alt
Oprateurs dinteraction supports
statique dynamique hybride Rountev et al. [1] Janice [5] Oechsle et Schmitt [7] DePauw et al. [10] Briand et al. [11] Briand et al. [12] Guhne uc et al. [13] Wendeha ls [16] Richner et Ducasse [8]
X X X X X X X X X X X X
/ Non
X X X X
X byte
code
Non
Non
X
machine virtuelle
Non
X X
X code
source
loop
Non
X byte
code
Loop, alt
Oui Non
X byte
code
/ /
X X
Non
Nimmer
et al. [39] Systa [6] Antoniol et al. [14]
Non Non Non
X X code
source
/ /
Tableau 3.1 Travaux de la rtro-ingnierie des diagrammes de squence UML
En tudiant de prs les travaux existants, plusieurs limites peuvent tre identifies que nous rsumons autour des points suivants : La majorit des travaux existants ne considre quune seule trace dexcution du systme en entre dans la rtro-ingnierie des diagrammes de squence. Cela est justifi en particulier par la difficult de faire combiner plusieurs traces dexcution du mme systme [5]. En effet, il est difficile de savoir quand deux occurrences d'une action dans deux traces diffrentes correspondent la mme action spcifique dans le code.
36
CHAPITRE III
Tenant de ltude des travaux existants, nous proposons de revisiter le problme de la rtro-ingnierie des diagrammes de squence dUML par une nouvelle approche. Notre approche utilise la technique danalyse dynamique de code, en particulier nous proposons danalyser les traces dexcution dun systme pour en construire des diagrammes de squence dUML2 avec une prise en compte des oprateurs dinteractions.
37
PARTIE 2 : Contribution
38
CHAPITRE IV
APPROCHE INCRMENTALE
Chapitre 4 : Approche Incrmentale

1. Introduction
Comme nous lavons soulign dans le chapitre prcdent, la majorit des travaux existants dans le contexte de la rtro-ingnierie des diagrammes de squence dUML permet de gnrer principalement des diagrammes de squence en se basant sur un seul scnario dexcution du systme. Donc, Les diagrammes de squence obtenus ne correspondent qu une seule trace, par consquent, ils ne donnent quune vision partielle du comportement du systme.
Dans ce chapitre, nous proposons une nouvelle approche revisitant le problme de rtroingnierie des diagrammes de squence dUML2 partir dun systme logiciel. Contrairement aux travaux existants, notre approche considre plusieurs traces dexcution. Dans ce qui suit, nous prsentons en dtail notre approche et nous lillustrons sur un simple exemple qui concerne un systme de vente classique.
2.
Exemple pour illustration

Pour illustrer les diffrentes tapes de notre approche nous allons utiliser lapplication
Vente. Il sagit dune simple application dvelopp en Java, dont le code est montr dans lannexe, permettant des vendeurs de crer des ventes darticles. Pour raliser cette cration, le vendeur envoie un ordre de cration dune nouvelle vente et il peut par la suite ajouter des articles et calculer la somme. Lajout des articles et le calcul de la somme peut tre rpt autant de fois que le nombre d'articles commands. Aprs, soit un bon de livraison ou une facture doit tre tablie, pour quelle soit signe par le vendeur. Enfin, la cration d'un bon de paiement est l'objet de choix pour le client. La figure Fig. 4.7. illustre le diagramme de squence de cette application. Nous distinguons les classes suivantes : La classe Vendor reprsente le vendeur qui initialise lactivit de vente avec les paramtres suivants : nbr_article : dsigne le nombre darticles de la vente courante. isInvoice : indique si une facture doit tre tablie ou non. isPayslip : indique si un bon de paiement doit tre tabli ou non. Les donnes avec lesquelles sont initialiss ces paramtres sont eux mme les donnes dentre qui prcisent le comportement de lapplication dans chaque session dexcution.
39
CHAPITRE IV
La classe Vendor contient galement les mthodes signInvoice() , signDelivery() , signPayslip() qui reprsentent le visa des paperasses tablies par le vendeur. La classe sale qui reprsente la vente contient la mthode newSale(), celle-ci cre une nouvelle instance de vente, ainsi contient la mthode addArticle() qui ajoute les articles commands. La classe de calcule Calcul contient la mthode calculAmount(float newValue,
float oldValue)
qui fait calculer la nouvelle somme de la vente aprs lajout dun nouveau
article. La classe Delivery qui soccupe aux bons de livraison contient la mthode getDelivery(), cette dernire tablit un bon de livraison pour la vente sil est command par le client. La classe Invoice qui soccupe aux factures contient la mthode getInvoice(), cette dernire tablit une facture pour la vente si la facture nest pas t command par le client. La classe Payslip qui soccupe aux bons de paiement contient la mthode getPaysliph(), cette dernire tablit un bon de payement pour la vente sil est command par le client.
3.
Approche incrmentale
Notre approche est illustre dans la figure Fig. 4.1. Elle suit le schma gnral des
approches du reverse-engineering (cf. chapitre 1) et elle se compose principalement de deux tapes, dont la premire concerne la collection de traces. Ces traces sont enregistres en excutant le systme instrument1 plusieurs fois pour couvrir les scnarios possibles. La deuxime tape est la construction incrmentale dun diagramme de squence complet2, elle consiste appliquer progressivement des heuristiques sur lensemble dinformation collectes dans ltape prcdente. Dans ce qui suit nous allons voir en dtail ces deux tapes en illustrant chaque tape sur lexemple de vente.
1 2
On utilise un outil dinstrumentation pour obtenir une version instrument du systme cibl. Un diagramme de squence complet reprsente le comportement gnral dun systme pas seulement le
comportement du systme dans un scnario particulier.
40
CHAPITRE IV
Collection de donnes
Construction du DS
Fig. 4.1. La construction Incrmentale du diagramme de squence
3.1
La Collection de traces Lobjectif de la premire tape est de collecter les traces dexcution du systme
logiciel dont nous voudrions construire des diagrammes de squence en appliquant la rtroingnierie. Comme il est prsent dans le chapitre 1, la technique adquate pour la collection de traces est lanalyse dynamique. Dans notre approche nous avons choisi dutiliser un outil existant danalyse dynamique permettant la collection de traces pour les systmes logiciels Java. Cet outil est appel MoDec[5]. La collection des traces dexcution du systme ncessite de lexcuter plusieurs fois en changeant les donnes dentre. En effet, le comportement du systme est fortement li son environnement et en particulier les donnes introduites par l'utilisateur pour initialiser les variables spcifiques du systme. Ainsi, une session d'excution ne suffit pas pour identifier le comportement gnral du systme. En effet, les interactions alternatives et itratives ne peuvent tre dtectes quen prcisant les valeurs appropries des conditions "if, else if" et "while, for, repeat ...". Il faut donc rpter cette phase autant de fois que le nombre de 41
CHAPITRE IV
diffrentes entres du systme pour collecter les traces pertinentes. Cependant excuter le systme pour couvrir toutes les entres possibles du systme est irraliste car la plage des valeurs de donnes est souvent infinie. Dans notre approche nous avons pos lhypothse de lexistence dun utilisateur expert qui connat les diffrentes valeurs dentres du systme eur permettant dobtenir les traces les plus pertinentes et de couvrir toutes les fonctionnalits possibles du systme. Dans le cas de lexemple dillustration Vente, nous avons constat que trois sessions , dexcution sont suffisantes pour observer les comportements possibles. Cela en changeant les donnes dentre dans chaque excution. La figure Fig. 4.2 montre les traces obtenues dans chaque session et leurs correspondantes donnes dentre dentre.
Trace 1 Agent|main|Vendor Vendor|newSale|Sale Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|getDelivery|Delivery Delivery|signDelivery|Vendor Trace 2 Agent|main|Vendor Vendor|newSale|Sale Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|getInvoice|Invoice Invoice|signInvoice|Vendor Sale|getPayslip|Payslip Payslip|signPayslip|Vendor Trace 3 Agent|main|Vendor Agent|main|Vendor Vendor|newSale|Sale Vendor|newSale|Sale Sale|addArticle|Sale Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|calculAmount|Calcul Sale|addArticle|Sale Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|calculAmount|Calcul Sale|addArticle|Sale Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|calculAmount|Calcul Sale|addArticle|Sale Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|calculAmount|Calcul Sale|getDelivery|Delivery Sale|getDelivery|Delivery Delivery|signDelivery|Vendor Delivery|signDelivery|Vendor Sale|getPayslip|Payslip Sale|getPayslip|Payslip Payslip|signPayslip|Vendor Payslip|signPayslip|Vendor
nbr_article = 3 isInvoice = false isPayslip = false
nbr_article = 1 isInvoice = true isPayslip = true
nbr_article =4 isInvoice = false isPayslip = true
Fig. 4.2. Traces de lapplication Vente avec les donnes dentre de chaque trace races
La Trace 1 par exemple est obtenu en excutant le systme du vente avec les obtenue cutant variables dentre : nbr_article = 1 inInvoice = false et isPayslip = false Chaque trace est 1, false. une squence de statements ou chaque statement montre l change de message entre deux lchange objets du systme. Dans ce qui reste, nous prsentons une formalisation des traces que nous manipulerons par la suite pour gnrer les diagrammes de squence.
42
CHAPITRE IV Trace
Nous appelons trace la suite dvnements dappel de mthodes enregistrs aprs une session dexcution du systme tudi. Ainsi, nous appelons Statement tout un vnement enregistr dans une trace. Dfinition 1. Une STATEMENT est un tuple ST=sender :SENDER, METHOD, receiver :RCEIVER o : (i) (ii) (iii) SENDER est la classe de lobjet sender qui invoque la mthode ; RECEIVER est la classe de lobjet receiver qui excute la mthode ; METHOD est la mthode.
Fig. 4.3. Exemple de Trace
Dfinition 2. Une TRACE est un tuple TR=ST, L, < o : (i) (ii) (iii) ST est lensemble de STATEMENT; L N est la taille de la trace o N est lensemble des entiers positifs; < : est une relation dordre total dans ST.
Exemple 1 La figure Fig. 4.3. montre un exemple de trace dont : St1=O1, m1, O2 STATEMENT o sender =O1, receiver =O2, et METHOD =m1.
Exemple 2 Soit Tr TR un exemple de trace illustr dans la figure Fig. 4.3. nous avons : Tr= {St1, St2, St3, St4, St5, St6} o St1=O1, m1, O2, St2=O2, m2, O3, St3=O3, m3, O2, St4=O2, m4, O1, St5=O3, m3, O2, St6=O2, m4, O1. 43
CHAPITRE IV Des fonctions pour la manipulation des traces
Dans ce qui suit nous dfinissons lensemble des fonctions que nous allons utiliser plus tard dans nos algorithmes : Soit Tr TR une trace et St1, St2 ST sont deux STATEMENTs de Tr, et l sa taille : 1) St1 < ST2 ssi St1 est situ avant St2 ; 2) RANG est la fonction qui renvoie lordre dune STATEMENT dans une trace : : ,
N est lensemble dentiers positifs, 3) SubTrace est la fonction qui renvoie une sous-trace dune trace : : , ,
4) FirstStatement est la fonction qui rtrouve la premire STATEMENT dune trace : : Lquivalence suivante est correcte : , 1
5) LastStatement est la fonction qui rtrouve la dernire STATEMENT dune trace : : Lquivalence suivante est correcte : ,
6) Successor est la fonction qui renvoie la Statement qui succde une Statement donne : : , Les quivalences suivantes sont correctes : , , , , , 1
7) Predecessor est la fonction qui renvoie la Statement qui prcde une Statement donne : Predecessor Predecessor 44 ,
CHAPITRE IV Les quivalences suivantes sont correctes : Predecessor , , 1 Predecessor , ,
8) SuccessorSet est la fonction qui renvoie lensemble des Statements qui succde une Statement donne : : , Les quivalences suivantes sont correctes : , 1 , , , , , 1
9) PredecessorSet est la fonction qui renvoie lensemble des Statements qui prcde une Statement donne : : , Les quivalences suivantes sont correctes : , 1 , 1 , : Soient : subTr1 et subTr2 deux sous-traces :
1 1, 2 2 1,
, , 1
10) isEquivalent est la fonction qui vrifie si deux sous-traces sont quivalentes ou non : 1, 1, 2 2 | :
2,
3.2 Construction incrmentale du diagramme de squence La deuxime tape de notre approche consiste gnrer un diagramme de squence UML reprsentant le comportement du systme spcifi dans les traces obtenues dans la premire tape. Les diagrammes de squence que nous souhaitons obtenir sont des instances du mta-modle d'UML 2.1.2 (cf. chapitre 2). Ces diagrammes peuvent tre construits en utilisant la correspondance entre les concepts du mta-modle et les lments des traces. Chaque objet qui apparat dans la trace sera transform en un Lifeline dans le diagramme de 45
CHAPITRE IV
squence et les mthodes excutes seront transformes en Messages. Toutefois, la question cruciale dans cette phase, concerne lidentification des fragments combins. Autrement dit, comment peut-on dtecter les oprateurs d'interaction : loop, opt, et alt, partir des traces? La solution que nous proposons pour dtecter les oprateurs dinteractions consiste construire un diagramme de squence dune manire incrmentale tape par tape, tel quil est dcrit dans la figure Fig. 4.1. Cette construction est base sur lidentification des squences dvnements rptes qui sont les fragments combins avec loprateur loop, et en se basant sur les divergences entre les traces pour identifier les fragments combins avec les oprateurs opt et alt. Le diagramme de squence doit voluer progressivement jusqu la fin du traitement. En effet, le diagramme de squence obtenu partir de la premire itration est enrichi par la deuxime, et ainsi de suite. Avant de prsenter les algorithmes permettant de construire le diagramme de squence, partir des traces nous prsentons ci-dessous une formalisation des diagrammes de squence dUML et les fonctions permettant leurs manipulations. Diagramme de squence Dfinition 3. Un BasicSequenceDiagram est un tuple BasicSD=M, L, <= o : (i) M est un ensemble de message. Un message est dfini par : m= (sender, name, receiver) o : sender, receiver L ; (ii) L est lensemble de lifelines participants dans le diagramme de squence ; (iii) <= est une relation dordre partiel dans M.
Dfinition 4. Un CombinedFragment est un tuple CF=Operands, Operator o : (i) Operands est un ensemble de BasicSequenceDiagram ; (ii) Operator est une numration : seq, opt, alt, loop.
Dfinition 5. Un SequenceDiagram est un tuple SD=CFs, < o : (i) CFs est un ensemble de CombinedFragment ; (ii) < est une relation dordre total dans CFs.
46
CHAPITRE IV
Des fonctions pour la manipulation des diagrammes de squence Dans ce qui suit nous dfinissons lensemble des fonctions que nous allons utiliser dans nos algorithmes : 1) SetOperand (messages) est la fonction qui assigne un ensemble de messages un BasicSequenceDiagram . 2) GetOperand (message) est la fonction qui retourne le nom du BasicSequenceDiagram assign un message. 3) newOperand(name) est la fonction qui cre un basicSequenceDiagram dans un CombinedFragment. 4) newCombinedFragment(name, operator) est la fonction qui cre un combinedFragment dans un sequenceDiagram. Nous utilisons dans nos algorithmes de dtection des oprateurs dinteraction la notion de bloc . Ci-dessous, nous prsentons cette notion de bloc ainsi quun ensemble de fonctions. Bloc Notre approche actuelle sintresse des applications sans imbrications (i.e. pas de structure itrative ou conditionnelle imbriqu dans une autre). Les suites de statements dune trace peuvent tre regroupes en blocs en fonction de leurs comportements communs. Le comportement gnral d'un systme peut tre vu donc comme une squence de blocs (voir figure Fig. 4.4.), semblable la squence des fragments combins dans le mta-modle du diagramme de squence dUML2. Les blocs sont considrs comme des conteneurs de statements, et ils respectent le mme ordre dans toutes les traces. Le contenu dun bloc peut tre diffrent dune trace une autre en fonction de la nature de son comportement. Un bloc peut tre vide dans une trace en fonction des conditions structurelles (comportement optionnel ou itratif), et il doit contenir des statements dans toutes les traces (comportement permanent ou alternatif) (voir figure Fig. 4.4.). En gnral, un SequenceDiagram se compose dune squence de blocs, o chaque bloc peut contenir une squence de messages (BasicSequenceDiagram ). Comme les Traces reprsentent le mme comportement du SequenceDiagram, ils respectent la mme squence de blocs, o chaque bloc peut contenir une suite de Statements. Une Statement dune Trace ressemble un message dans un SequenceDiagram, donc, on parle dun bloc de Statements
47
CHAPITRE IV
ou dun bloc de messages pour dsigne la mme chose. Nous introduis introduisons ci-dessous un ensemble de fonctions manipulant les blocs : 1) GetBloc (Statement) est la fonction qui retourne lordre du bloc du Statement. dune 2) GetBlocSubTrace(bloc, Trace) est la fonction qui retourne les Statements dun bloc dans une Trace. 3) isEmptyBloc(bloc, Trace) est la fonction qui vrifie quun bloc est vide dans une Trace. on 4) isExistStatement(Statement, bloc, Trace) est la fonction qui vrifie quune Statement existe dans un bloc dune Trace. 5) GetBlocOperand(bloc, Trace) est la fonction qui retourne le nom du BasicSequenceDiagram des messages dun bloc.
bloc1 'permanent'
st1 st2
st3 st3 st3
bloc1 'permanent'
st1 st2
bloc1 'permanent'
st1 st2
bloc2 'loop'
bloc2 'loop'
st3
bloc2 'loop'
bloc3 'alt'
st1 st3
bloc3 'alt'
st4 st5
bloc3 'alt'
st1 st3
bloc4 'opt'
st5 st4
bloc4 'opt'
bloc4 'opt'
st5 st4
bloc5 'loop'
st1 st2
bloc5 'loop'
st1 st2 st1 st2
bloc5 'loop'
Trace 1
Trace 2
Fig. 4.4. La dcomposition des traces en blo blocs
Trace 3
3.2.1
Dtection des oprateurs
a) Fragment combin avec loprateur "loop" Hypothse. Comme nous lavons prsent dans le chapitre 2 (UML), loprateur dinteraction loop permet de spcifier une itration (i.e. boucle) dun ou de plusieurs messages. Lhypothse que nous utilisons pour dtecter les fragments combins avec loprateur thse loop est base donc sur la prsence dune rptition dune squence de statements dans
48
CHAPITRE IV
les traces considres. En effet, pour chaque trace dexcution, le fait quon voit la mme squence de statements continument (plus qu'une fois), nous constatons l'existence dun fragment combin de type "loop". Algorithme. Lalgorithme que nous proposons pour dtecter loprateur loop appel Algo1 et illustr ci-dessous. Il prend en entre une trace et un SequenceDiagram qui est initialement vide. Cet algorithme doit tre appliqu sur toute trace. Enfin, on obtient comme rsultat un SequenceDiagram avec des CombinedFragments doprateur "loop". Le principe de cet algorithme est bas sur le parcours squentiel de toutes les statements. Pour chaque Statement (4, 13), on cherche sa premire occurrence (7, 8), si une occurrence est trouve (14) on vrifie lquivalence des successeurs de la Statement avec les successeurs de son occurrence (15). Si lquivalence est correcte on adapte le SequenceDiagram (16, 21) et on cherche les itrations ventuelles de la squence dtecte (22, 28). Algo1;
Inputs : Tr=(M,T,<) Trace, SD=(Fc,<) SequenceDiagram Outputs : SD avec fc=(F,Op) CombinedFragment where Op = loop Variables i :integer; m, succ , next: Statement; detected: Boolean; Tr1: Trace; 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: Begin SD:=null; m:= FirstStatement (Tr) ; For i :=1 to T do begin detected:=false; succ= successor (m, Tr); If (m=succ) then Detected:= true Else begin succ:= successor(succ,Tr); If (succ = null) go to 14:; Else go to 7:; end If (detected) then begin If (isEquivalent(successorSet(succ,Tr),predecessorSet(succ,Tr))) then begin SD.newCombinedfragment(cf,loop); cf. newOperand(opd) ; opd. SetOperand(succ+ successorSet (succ,Tr)) ; opd. SetOperand(m+ predecessorSet(succ,Tr)) ; next := successor(LastStatement (successorSet(succ,Tr)),Tr) ; Tr1:= successorSet (next,Tr); While (Tr1<> ) then If (isEquivalent(successorSet (succ,Tr),Tr1) then;begin opd. SetOperand(next + successorSet (next,Tr)); next := successor(LastStatement (successorSet (next)),Tr) ; Tr1:= successorSet (next,Tr) ;
49
CHAPITRE IV
27: end 28: Else begin m:=next; go to 31:; end 29: End 30: Else begin succ:= successor(succ,Tr); go to 7:;end 31: End 32: Else m :=successor(m,Tr); 33: End 34: end Algo 1
Discussion. Nous devons excuter cette routine pour chaque trace, et le plus grand nombre de traces analyses implique le plus grand nombre de CombinedFragments doprateur "loop" dtects. Prenons cet exemple : For (int i=0; i<variable; i++){ O1.M1(); O2.M2(); } Ce code ressemble un CombinedFragment doprateur "loop", mais il ne peut pas tre dtect dans une session dexcution o variable=0 . Si variable=0 dans toutes les sessions dexcution, ce CombinedFragment ne peut jamais tre dtect, ce quexplique le besoin daide auprs lexpert du systme tudi. Illustration. Aprs avoir appliqu ce premier algorithme sur les traces de lexemple de Vente, nous avons obtenu le diagramme de squence illustr dans la Figure Fig. 4.5. Ce diagramme de squence comporte les CombinedFragments de type loop.
sd Sale
:vendor
:sale :calcul
newSale()
loop
addArticle()
calculAmount()
Fig. 4.5. DS de Vente aprs application de lalgorithme dtection de loop.
50
CHAPITRE IV b) Fragment combin avec loprateur "opt"
Hypothse. Loprateur dinteraction opt permet de spcifier dans un diagramme de squence

quun ou plusieurs messages sont optionnels. Lhypothse que nous avons adopt pour dtecter cet oprateur consiste parcourir tous les blocs et si une statement est absente dans un bloc dune trace on va mettre cette statements dans un CombinedFragment avec un oprateur opt .
Algorithme. Lalgorithme Algo2 ci-dessous permet de dtecter loprateur dinteraction opt . Il prend en entre toutes les traces et le diagramme de squence obtenu aprs lapplication de lAlgorithme Algo1 i.e., un diagramme de squence avec seulement des oprateurs loop et il renvoie comme rsultat un SequenceDiagram avec
CombinedFragments doprateurs "loop, opt". Pour chaque Statement appartenant linteraction principale Global_SD (6,7), en commenant par la premire (5), on confirme lexistence de ses occurrences dans le reste des traces au mme bloc (8, 10), et si cela est confirm alors on adapte le type du bloc de la trace courante au type indiqu par les autres traces (12, 16). Dans le cas contraire (i.e. absence doccurrences au moins dans une trace), on marque le bloc comme optionnel (18).
Algo2:
Inputs : Tr1,Tr2, ,TrN=(M,T,<) Trace, SD=(Fc,<) SequenceDiagram avec fc=(F,Op) CombinedFragment where Op = loop Outputs : SD=(Fc,<) SequenceDiagram avec fc=(F,Op) CombinedFragment where Op = <loop, opt>. Variables i,j,k, bloc :integer; m: Statement; oper,operOpt:BasicSequenceDiagram; 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: Begin SD.newCombinedfragment(cf,opt); cf. newOperand(operOpt) ; for k:=1 to N do // N is the number of traces m:= FirstStatement (Trk) ; For i :=1 to T do begin // T is the number of Statements of Trace If (GetOperand(m)=Global_SD) then begin // Global_SD is the default name of the BasicSequenceDiagram bloc:=GetBloc(m); // find the bloc order of current Statement for j:=1 to N<>k do begin // N<>k do not compare Trace with itself if(isExistStatement(m, bloc, Trj)) then begin // check existence of current statement in other trace at the same bloc Oper:= GetBlocOperand(bloc,Trj); if (oper<>Global_SD) then begin oper.SetOperand(GetBlocSubTrace(bloc, Trk)); m:= successor(LastStatement(GetBlocSubTrace(bloc, Trk)), Trk); i:=RANG(m,Trk)-1; j:=N+2;
51
CHAPITRE IV
16: 17: 18: 19: 20: 21: 22: 23: 24: end 25: end 26: end algo2 end end else begin operOpt.SetOperand(m); m:= successor(m,Trk); j:=N+2; end end if (j=N) then m:= successor(m,Trk);
ce point tous les messages optionnels sont dtects inclus ceux qui sont rellement alternatifs, parce que tout message alternatif est optionnel et pas linverse. En outre, le modle commun de la squence des blocs des traces est juste entrain dtre dtermin, il contient des blocs de types "loop", "permanent", et "opt". Il est prvu que les messages optionnels qui se cachent et apparaissent ensemble, soient appartenir au mme CombinedFragment alternatif ou optionnel. Discussion. Comme le cas des interactions itratives, si une condition na pas t ralise dans toutes les traces, alors le CombinedFragment optionnel correspondant ne serait jamais dtect. Illustrations. Aprs lapplication de ce deuxime algorithme le prcdent diagramme de squence de vente est enrichi par toutes les CombinedFragments de type "opt" comme il est dcrit dans la figure Fig. 4.6.
52
CHAPITRE IV
sd Sale
:vendor
:sale :calcul
newSale()
loop
addArticle() :invoice calculAmount() :delivery :payslip
opt
getInvoice() signInvoice()
opt
getDeliveryOrder() signDeliveryOrder
opt
getPaySlip() signPaySlip()
Fig. 4.6. DS de Vente aprs lapplication de lalgorithme dtection de opt
c) Fragment combin avec loprateur "alt" Hypothse. Le cas de loprateur "alt" est le cas le plus complexe, car il dpend fortement des divergences entre les diffrentes traces. A ce stage-l notre SequenceDiagram contient des messages ordonns certains appartenant aux oprandes de type "loop", dautres sont permanentes, et le reste est optionnel. Pour dtecter loprateur dinteraction "alt", nous avons tabli quelques rgles pour confirmer la prsence dun bloc alternative : a) Tous les statements apparaissant dans le mme bloc dune trace ne sont pas des alternatives (elles peuvent tre alternatives une autre squence de statements). b) Chaque statement dun bloc dune trace est candidate dtre alternative aux autres statements absentes de son bloc. c) Chaque bloc dans toutes les traces doit contenir exactement une parmi les squences de statements alternatives. d) Le comportement alternatif qui contient plus dlments (i.e., operands) est slectionn comme le CombinedFragment de type "alt" pour le bloc.
53
CHAPITRE IV
En appliquant ces rgles, on peut filtrer les blocs optionnels qui sont rellement alternatifs et on les adapte. Avant dentamer lalgorithme de dtection de CombinedFragments de type alt nous expliquons dabord les deux procdures longestAltChain et decomposeChain : La chaine alternative la plus longue (longestAltChain). Selon la rgle b) nous composons la chane alternative la plus longue, cest le cas o chaque statement dun bloc est alternative aux autres statements : Soit {mes1, mes2, .., mesk} lensemble des statements dun bloc dans toutes les traces, alors la
chaine alternative la plus longue est mes1+ mes2+ ..+ mesk o + signifie alternatif.
La dcomposition de la chaine (decomposeChain). Si une chane alternative ne respecte pas la rgle a), cette chane doit tre dcompose un nombre spcifique de sous-chaines qui respectent la rgle a). La chane alternative principale doit tre racine, par la suite les nouvelles sous-chanes alternatives vont tre construites en se basant sur la chane racine. Cette dernire peut tre construite en liminant les statements prsentes dans le bloc de la trace en cours de traitement : <root-chain> = <old-chain> <trace blocs statements> En respectant les rgles a) et b), on peut construire un nombre de sous-chanes gale au nombre des combinaisons sans rptition construites en utilisant les statements du bloc de la trace courante:
!
! !
j: nombre de statements du bloc de la trace courante. partir de chaque combinaison de statements on construit une nouvelle chane alternative en se basant sur la chane racine comme suit : <sub-chain> = <root-chain> + <combined-Chain > Exemple: Soit lensemble de statements dun bloc dune trace {m1, m2, m3} alors : NbrChains = 7 et sub-chains = {<<root-chain> + m1>, <<root-chain> + m2>, <<root-chain> + m3>, <<root-chain> + m1m2>, <<root-chain> + m1m3>, <<root-chain> + m2m3>, <<root-chain> + m1m2m3>}.
54
CHAPITRE IV
Algorithme. Lalgorithme Algo3 prend en entre toutes les traces initiales et un SequenceDiagram avec CombinedFragments doprateurs "loop, opt" qui est le rsultat de lapplication des algorithmes Algo1 et Algo2 . Il renvoie comme rsultat un SequenceDiagram avec CombinedFragments doprateurs "loop, opt, alt". Pour dtecter des CombinedFragments doprateur "alt", on doit assembler toutes les statements de chaque bloc optionnel dans toutes les traces, puis on construit, en utilisant ces statements, la chane alternative la plus longue (11). Cette chane va tre compare avec les statements du bloc dans la premire trace, qui soit lignorer totalement (si la rgle c) nest pas respecte) (12,15), ou ils supposent sa dcomposition (18), alors respectivement, on supprime (16) ou on dcompose (19) la chane. Dans le cas contraire o la chane est accepte par les statements du bloc, on la maintient. Les chaines rcemment composes et celles qui sont maintenues vont tre compares avec les statements du bloc des autres traces. Enfin, on applique la rgle d) pour crer les CombinedFragment doprateur "alt" (25, 26). Algo 3 :
Inputs : Tr1,Tr2, ,TrN=(M,T,<) Trace, SD=(Fc,<) SequenceDiagram avec fc=(F,Op) CombinedFragment where Op = <loop, opt>. Outputs : SD=(Fc,<) SequenceDiagram avec fc=(F,Op) CombinedFragment where Op = <loop, opt,alt>. Variables i,j,k, bloc :integer; m: Statement; oper,operOpt:BasicSequenceDiagram; StatementSet :set of Statements; chainSet,subChainSet: set of chains, altCF: array of CombinedFragment; 1: Begin 2: For k:=1 to N do // N is the number of traces 3: m:= FirstStatement (Trk) ; 4: for i :=1 to T do begin // T is the number of Statements of Trace 5: if (GetOperand(m)=operOpt) then begin // operOpt is an operand of type opt 6: bloc:=GetBloc(m); // find the bloc order of current Statement 7: StatementSet:=; chainSet:=; 8: For j:=1 to N do begin 9: StatementSet:= StatementSet+GetBlocSubTrace(bloc, Trj); 10: end 11: chain:= longestAltChain(StatementSet); chainSet:= chainSet+chain; 12: for j:=1 to N do begin 13: subChainSet:=; 14: for (every: chain chainSet) do begin 15: if (isIgnored(chain, GetBlocSubTrace(bloc, Trj))) then 16: deleteFromChainSet(chain); 17: else 18: if (chainRequireDecomposition) then begin 19: decomposeChain(chain, subChainSet); 20: deleteFromChainSet(chain); 21: end
55
CHAPITRE IV
22: end 23: chainSet:=chainSet+subChainSet; 24: end 25: altCF[bloc]:= SD.newCombinedfragment(ChooseLongestAltChain(chainSet),alt); 26: altCF[bloc]. newOperand(oper) ; 27: for j:=1 to N do begin 28: oper.SetOperand(GetBlocSubTrace(bloc, Trj)); 29: m:= successor(LastStatement(GetBlocSubTrace(bloc, Trk)), Trk); 30: i:=RANG(m,Trk)-1; 31: end 32: end 33: end 34: end Algo 3
Cet algorithme commence par enfermer toutes les squences alternatives possibles, puis il emploie une mthode dexclusion itrative en respectant les combinaisons de statements des blocs dans chaque trace. Finalement, on obtient soit zro, un, ou plusieurs chanes alternatives appropries toutes les combinaisons de statements du bloc dans toutes les traces, automatiquement la chaine la plus longue est choisie (rgle d)). Nous rappelons que lordre dapplication de ces trois algorithmes est trs important, et si on change cet ordre, les rsultats ne seront plus achevs. Illustrations. Aprs lapplication de ce dernier algorithme le prcdent diagramme de squence de vente est enrichi par toutes les CombinedFragments de type "alt" la figure Fig.4.7. montre le diagramme de squence final de lapplication Vente, celui-ci comprend les trois types de CombinedFragment savoir : loop, opt et alt. d) Fragment combin avec loprateur "seq" Comme nous avons indiqu ci-dessus dans la section 4.2.2 du chapitre II, le diagramme de squence dUML2 supporte deux types doprateurs de squence, dont : 1) loprateur "seq" (pour la squence faible) et 2) loprateur "strict". Tous les CombinedFragments qui sont dtects par nos algorithmes (doprateur "opt", "alt" ou "loop"), sont en squence de type "seq" selon lordre de leurs messages tel quil est montr dans la figure Fig. 4.7. Finalement le diagramme de squence est compltement construit. Il nous reste que lexploiter en lexposant aux utilisateurs par des techniques de visualisation, ou par des outils UML (cf. Fig 5.12.).
56
CHAPITRE IV
Fig. 4.7. DS final de lapplication Vente
4.
Conclusion
Dans ce chapitre nous avons prsent en dtail notre approche de la rtro-ingnierie
des diagrammes de squence dUML2 partir dun systme logiciel. Elle se rsume essentiellement dans deux tapes : 1. Collection des traces : en instrumentant le logiciel cibl puis on lexcute autant de fois que le nombre de scnarios possibles. 2. Construction du diagramme de squence complet : en appliquant itrativement les heuristiques et traitements de dtection des oprateurs "loop, opt, alt" dans lordre prcis. Dans le chapitre prochain nous allons voir les dtails de limplmentation de lapproche prsente.
57
CHAPITRE V
IMPLMENTATION
Chapitre 5 Implmentation
Lobjectif de ce chapitre est de prsenter les dtails dimplmentation de lapproche incrmentale, o nous dcrivons les outils, langages et plateformes util utilises. Ainsi, nous prsentons les vues progressives de notre solution par rapport lexemple dillustration Vente.
1.
Outils dimplmentation
Nous avons choisi le langage Java et les bases de donnes Access pour impl implmenter
notre solution. 1.1 Outils de collection de traces ction Parmi plusieurs outils de collection de trace pour les systmes logiciels Java, nous traces avons choisi celui de Janice [5] appel MoDec. Celui ci est un outil dinstrumentation de code Celui-ci intermdiaire Java (java bytecode) (voir fig. 5.1 fig. 5.2., fig. 5.3.), donc il a comme 5.1., ), avantage de ne pas toucher le code source ce qui donne la possibilit de modifier le code et de relancer linstrumentation nouveau. Une autre option trs intressante est galement fournie par loutil MoDec o lutilisateur peut choisir parmi les classes du programme celles quil lutilisateur veut faire suivre et instrumenter.
Fig. 5.1. Code source de lexemple Loop.java
58
CHAPITRE V
IMPLMENTATION
Fig. 5.2. Version non instrument de la mthode m1().
Fig. 5.3. Version instrument de la mthode m1().
Aprs linstrumentation du bytecode par MoDec, et en lanant lexcution du s programme instrument un fichier de trace va tre gnr (voir fig. 5.4 ). Ce fichier contient 5.4.). tous les vnements de construction et de destruction des objets des classes instrument instrumentes, ainsi les vnements dappel et de retour de ses mthodes invoques sont aussi enregistrs. La forme de traces collectes peut diffrer dun outil un autre, ce qui nous a obligs de dvelopper un adaptateur qui rorganise les traces dans une nouvelle forme adapte o chaque
59
CHAPITRE V
IMPLMENTATION
trace se compose dune suite de statements, et chaque statement dans une ligne de la trace se compose de lobjet appelant, la mthode excute, et lobjet appel. Le rle de ladaptateur est de restructurer la trace dans une forme approprie aux traitements de ltape de la construction du diagramme. Un exemple de cette forme est illustr dans la figure Fig. 5.5.
Trace 2 METHOD entry public static void main(String[] args) CALLEE Vendor -1 METHOD CONSTRUCTOR entry public void <init>() CALLEE Sale 1333195 CONSTRUCTOR CONSTRUCTOR exit public void <init>() CALLEE Sale 1333195 CONSTRUCTOR METHOD entry public void newSale(int nbr_article, boolean isInvoice, boolean isPayslip) CALLEE Sale 1333195 METHOD METHOD entry public static float addArticle() CALLEE Sale -2 METHOD METHOD exit public static float addArticle() CALLEE Sale -2 METHOD CONSTRUCTOR entry public void <init>() CALLEE Calcul 10730689 CONSTRUCTOR CONSTRUCTOR exit public void <init>() CALLEE Calcul 10730689 CONSTRUCTOR METHOD entry public float calculAmount(float newValue, float oldValue) CALLEE Calcul 10730689 METHOD METHOD exit public float calculAmount(float newValue, float oldValue) CALLEE Calcul 10730689 METHOD CONSTRUCTOR entry public void <init>() CALLEE Invoice 29181730 CONSTRUCTOR CONSTRUCTOR exit public void <init>() CALLEE Invoice 29181730 CONSTRUCTOR METHOD entry public void getInvoice() CALLEE Invoice 29181730 METHOD METHOD entry public static void signInvoice() CALLEE Vendor -2 METHOD METHOD exit public static void signInvoice() CALLEE Vendor -2 METHOD METHOD exit public void getInvoice() CALLEE Invoice 29181730 METHOD CONSTRUCTOR entry public void <init>() CALLEE Payslip 15980197 CONSTRUCTOR CONSTRUCTOR exit public void <init>() CALLEE Payslip 15980197 CONSTRUCTOR METHOD entry public void getPayslip() CALLEE Payslip 15980197 METHOD METHOD entry public static void signPayslip() CALLEE Vendor -2 METHOD METHOD exit public static void signPayslip() CALLEE Vendor -2 METHOD METHOD exit public void getPayslip() CALLEE Payslip 15980197 METHOD METHOD exit public void newSale(int nbr_article, boolean isInvoice, boolean isPayslip) CALLEE Sale 1333195 METHOD METHOD exit public static void main(String[] args) CALLEE Vendor -1 METHOD
Fig. 5.4. Trace 2 de lapplication Vente gnre par loutil MoDec
60
CHAPITRE V
IMPLMENTATION
Trace 2 Agent|main|Vendor Vendor|newSale|Sale Sale|addArticle|Sale Sale|calculAmount|Calcul Sale|getInvoice|Invoice Invoice|signInvoice|Vendor Sale|getPayslip|Payslip Payslip|signPayslip|Vendor

Fig. 5.5. trace2 adapt de lapplication Vent Vente
1.2
Stockage des donnes Nous avons reprsent les instances du Mta Modle du diagramme de squence Mta-Modle
dUML2 par un modle de base de donnes relationnel (voir la figure Fig. 5.6), ce modle est un intermdiaire entre lensemble de fichiers de traces (entre) et les outils de visualisation et (entre) de communication (sortie). En effet, nous reposons sur les capacits du langage SQL pour fournir des informations au modle relationnel, traiter et analyser ses informations, et galement pour extraire le diagramme de squence dans une forme adquate (par exemple squence XMI [53]) aux outils UML2. La figure Fig. 5.6 montre les tables principales qui stockent les . informations tout au long des priodes dvolution du diagramme de squence. Dans ce travail initial nous nous sommes concentrs sur les lments indispensables dun diagramme de squence. Cependant, notre modle relationnel reste ouvert pour des nouvelles modifications structurelles. Cet avantage nous permet de faire des volutions futures pour supporter dautres lments du mta modle UML. Notre base de donnes utilise est s mta-modle compose des tables suivantes : Table Mess_Tr : cette table stocke le contenu des traces au dbut sans aucune modification. Le champ Tr_file contient le numro du fichier de trace, Ord_mess stocke l lordre du message tel quil apparat dans le fichier de trace. Le champ Cde_mess contient un code affect pour identifier les messages et leurs occurrences dans tous les fichiers de traces. Obj_Sd, Obj_Rcv, et Mthd sont respectivement lobjet appelant, lobjet appel, et la mthode invoque. Int_fr et lobjet
61
CHAPITRE V
IMPLMENTATION
operand sont utiliss dans la suite des traitements pour sauvegarder respectivement le fragment combin et loprande auxquels appartient un message. Nous pouvons identifier chaque occurrence dun message dans tous les traces par le numro de la trace Tr_file et son ordre Ord_mess. Table Operands : cette table stocke tous les oprandes recouverts tout au long du processus de construction du diagramme. Le champ level indique le niveau dimbrication, rang contient lordre de loprande dtect. name_op contient le nom attribu loprande, ce nom se compose de suffixe "OP" plus les codes des messages appartenant cet oprande spars par des points. Le champ Combined_f rfre au nom de fragment combin auquel appartient cet oprande. Table Combined_fragment : dans cette table nous conservons tous les fragments combins dtects. Le champ level indique le niveau dimbrication, rang contient lordre de fragment combin dans le diagramme de squence, cet ordre ressemble celui de loprateur seq dans le mta-modle du diagramme de squence. name_cf contient le nom attribu au fragment combin, ce nom se compose du suffixe "SD" plus les codes des messages appartenant cet fragment. Le champ operator indique le type doprateur du fragment combin : loop, opt, ou alt. Tandis que le champ operand rfre loprande auquel appartient ce fragment combin dans le cas des imbrications.
Fig. 5.6. Le Modle relationnel intermdiaire
A la fin de lapplication des heuristiques de construction du diagramme de squence le modle relationnel va contenir dans ses tables toutes les informations du diagramme de squence dans une forme structure et facile dtre interroge. La table Combined_fragment contient tous les fragments combins, ces fragments reprsentent le comportement gnral du logiciel tudi. La table operands contient tous les oprandes des fragments combins stocks
62
CHAPITRE V
IMPLMENTATION
dans la table Combined_fragment. Quant la table Mess_Tr, elle garde toujours les informations des objets en interaction et ses mthodes. Pour extraire ces informations vers une reprsentation standard et exploitable par les outils UML2. Nous nous sommes bass sur les requtes SQL pour piloter la transformation des diagrammes de squence au format respectant le standard UML. Cette transformation est ralise en utilisant les primitives de lAPI UML2 que nous allons prsenter dans ce qui suit. 1.3 API UML2 LAPI UML2 est une bibliothque Java qui contient lensemble des classes ncessaires la cration et la gestion automatique de lensemble des modles dUML2 en respectant les rgles et la structure du mta-modle UML2. Cette API permet galement de sauvegarder ces modles dans des fichiers de format standard de lintercommunication XMI. Exemples Pour crer un modle UML : Model myModel = UMLFactory.eINSTANCE.createModel(); Pour crer une interaction UML et initialiser son nom : Interaction interaction=UMLFactory.eINSTANCE.createInteraction(); interaction.setName("myIntercation"); Pour crer un oprande, le relier linteraction, et initialiser son nom : InteractionOperand operand=UMLFactory.eINSTANCE.createInteractionOperand(); operand.setEnclosingInteraction(interaction); operand.setName("OP_0"); Nous avons implment un programme qui se comporte comme un pilote de ces instructions de code afin de gnrer un diagramme de squence respectant le standard UML2.
63
CHAPITRE V
IMPLMENTATION
2.
2.1
Application de lapproche sur lexemple Vente

Cas dutilisation Pour prouver l'efficacit de notre approche, nous avons choisi le processus de vente
comme un cas dutilisation. Nous signalons que la contrainte des imbrications a rendu trs difficile de trouver une application relle pour valider notre approche. Dans ce qui suit nous prsentons lapplication dtaille de notre approche sur lexemple de Vente. Etape 1 : ltape de collection de traces Nous avons obtenu trois diffrentes traces gnres par loutil MoDec, aprs trois sessions dexcution de lapplication Vente (voir Fig. 5.4). Dans ces trois sessions nous avons suivi trois scnarios dexcution en fournissant diffrentes combinaisons de valeurs dentre. Et nous sommes conscients que ces trois scnarios dexcutions sont assez suffisants pour recouvrir le comportement gnral de lapplication Vente. Nous nous sommes intresss aux interactions entre classes, et nous avons substitu les objets de la mme classe par le nom de leur classe. La figure Fig. 4.2 montre les trois traces aprs le filtrage des donnes et ladaptation de la structure des traces pour tre plus simple analyser. A la fin de cette tape, le contenu des trois traces est charg dans la table Mess_Tr, avec quelques informations supplmentaires. Dans cet tat initial, lordre des messages est maintenu, un code identificateur est attribu aux messages, et tous les messages sont considrs initialement appartenant linteraction principale Global_SD tel quil est montr dans la figure Fig. 5.7. Etape 2 : ltape danalyse et construction du diagramme de squence La figure 5.8 affiche le contenu de la table Mess_Tr la fin de cette tape. On peut voir que le contenu de certaines lignes est modifi, prcisment des champs int_fr et operand.
64
CHAPITRE V Mess_Tr
IMPLMENTATION
Tr_file Ord_mess Cde_mess Obj_Sd Obj_Rcv Mthd Int_fr operand 1 1 1 Agent Vendor main Global_SD 1 2 2 Vendor Sale newSale Global_SD 1 3 3 Sale Sale addArticle Global_SD 1 4 4 Sale Calcul calculAmount Global_SD 1 5 3 Sale Sale addArticle Global_SD 1 6 4 Sale Calcul calculAmount Global_SD 1 7 3 Sale Sale addArticle Global_SD 1 8 4 Sale Calcul calculAmount Global_SD 1 9 5 Sale Delivery getDelivery Global_SD 1 10 6 Delivery Vendor signDelivery Global_SD 2 1 1 Agent Vendor main Global_SD 2 2 2 Vendor Sale newSale Global_SD 2 3 3 Sale Sale addArticle Global_SD 2 4 4 Sale Calcul calculAmount Global_SD 2 5 7 Sale Invoice getInvoice Global_SD 2 6 8 Invoice Vendor signInvoice Global_SD 2 7 9 Sale Payslip getPayslip Global_SD 2 8 10 Payslip Vendor signPayslip Global_SD 3 1 1 Agent Vendor main Global_SD 3 2 2 Vendor Sale newSale Global_SD 3 3 3 Sale Sale addArticle Global_SD 3 4 4 Sale Calcul calculAmount Global_SD 3 5 3 Sale Sale addArticle Global_SD 3 6 4 Sale Calcul calculAmount Global_SD 3 7 3 Sale Sale addArticle Global_SD 3 8 4 Sale Calcul calculAmount Global_SD 3 9 3 Sale Sale addArticle Global_SD 3 10 4 Sale Calcul calculAmount Global_SD 3 11 5 Sale Delivery getDelivery Global_SD 3 12 6 Delivery Vendor signDelivery Global_SD 3 13 9 Sale Payslip getPayslip Global_SD 3 14 10 Payslip Vendor signPayslip Global_SD
Fig. 5.7. Vue initiale de la table Mess_Tr
65
CHAPITRE V
IMPLMENTATION
Mess_Tr
Tr_file Ord_mess Cde_mess Obj_Sd Obj_Rcv Mthd Int_fr operand 1 1 1 Agent Vendor main Global_SD 1 2 2 Vendor Sale newSale Global_SD 1 3 3 Sale Sale addArticle SD3.4 OP3.4 1 4 4 Sale Calcul calculAmount SD3.4 OP3.4 1 5 3 Sale Sale addArticle SD3.4 OP3.4 1 6 4 Sale Calcul calculAmount SD3.4 OP3.4 1 7 3 Sale Sale addArticle SD3.4 OP3.4 1 8 4 Sale Calcul calculAmount SD3.4 OP3.4 1 9 5 Sale Delivery getDelivery SDA5.6+7.8 OPA5.6 1 10 6 Delivery Vendor signDelivery SDA5.6+7.8 OPA5.6 2 1 1 Agent Vendor main Global_SD 2 2 2 Vendor Sale newSale Global_SD 2 3 3 Sale Sale addArticle SD3.4 OP3.4 2 4 4 Sale Calcul calculAmount SD3.4 OP3.4 2 5 7 Sale Invoice getInvoice SDA5.6+7.8 OPA7.8 2 6 8 Invoice Vendor signInvoice SDA5.6+7.8 OPA7.8 2 7 9 Sale Payslip getPayslip SDO9.10 OPO9.10 2 8 10 Payslip Vendor signPayslip SDO9.10 OPO9.10 3 1 1 Agent Vendor main Global_SD 3 2 2 Vendor Sale newSale Global_SD 3 3 3 Sale Sale addArticle SD3.4 OP3.4 3 4 4 Sale Calcul calculAmount SD3.4 OP3.4 3 5 3 Sale Sale addArticle SD3.4 OP3.4 3 6 4 Sale Calcul calculAmount SD3.4 OP3.4 3 7 3 Sale Sale addArticle SD3.4 OP3.4 3 8 4 Sale Calcul calculAmount SD3.4 OP3.4 3 9 3 Sale Sale addArticle SD3.4 OP3.4 3 10 4 Sale Calcul calculAmount SD3.4 OP3.4 3 11 5 Sale Delivery getDelivery SDA5.6+7.8 OPA5.6 3 12 6 Delivery Vendor signDelivery SDA5.6+7.8 OPA5.6 3 13 9 Sale Payslip getPayslip SDO9.10 OPO9.10 3 14 10 Payslip Vendor signPayslip SDO9.10 OPO9.10 Fig. 5.8. Vue finale de la table Mess_Tr
Dans la figure Fig. 5.9, la table Combined_fragments contient les fragments combins dtects dans cette tape. Cette table indique lordre, ou bien, la squence des fragments combins dans le champ rang. Dans cette table, Le fragment Global_SD1 et Gllobal_SD2 reprsente lordre des messages permanents respectivement 1 et 2 par rapport aux fragments 66
CHAPITRE V
IMPLMENTATION
combins. Dans la version actuelle dUML, il nexiste pas des fragments combins de type permanent, toutefois, nous avons signal que nous avons besoin de telle reprsentation. SD3.4: un fragment combin avec loprateur "loop" contient deux messages reprsents par les codes: '3' et '4'. SDA5.6+7.8: un fragment combin avec loprateur "alt" contient deux oprandes : '5.6' et '7.8'. SDO9.10 : un fragment combin avec loprateur "opt" contient deux messages reprsents par les codes : '9' et '10'. La table operands (voir Fig. 5.10) montre les oprandes des diffrents fragments combins, nous pouvons connatre le fragment combin de chaque oprandes en consultant les valeurs du champ Combined_f : OP3.4 : un oprande dun fragment combin itratif. OPA5.6 : un oprande dun fragment combin alternatif dont appartiennent deux messages : '5' et '6'. OPO9.10 : un oprande dun fragment combin optionnel. Combined_fragments
level rang name_cf operator operand 0 0 Global_SD seq 1 1 Global_SD1 per 1 2 Global_SD2 per 1 3 SD3.4 loop 1 4 SDA5.6+7.8 alt 1 5 SDO9.10 opt Fig. 5.9. Vue finale de la table Combined_fragments
Operands
level rang name_op Combined_f 1 1 OP3.4 SD3.4 1 3 OPA5.6 SDA5.6+7.8 1 4 OPA7.8 SDA5.6+7.8 1 5 OPO9.10 SDO9.10 Fig. 5.10. Vue finale de la table Operands
Etape 3 : ltape dextraction du diagramme de squence Nous avons utilis des requtes SQL pour extraire les informations ncessaires la visualisation ou lintercommunication du diagramme de squence. En utilisant les primitives de lAPI UML2, nous avons construit le diagramme de squence correspondant lapplication Vente. La figure Fig. 5.11 montre une vue du diagramme de squence dans un 67
CHAPITRE V
IMPLMENTATION
diteur Eclipse. Ainsi, la figure Fig. 5.12 prsente une partie du document UML gnr. Cette partie reprsente un fragment combin, de type "alt", qui contient deux oprandes : OPA5.6 et OPA7.8. Les diagrammes de squ squence dans la figure Fig. 5.11 et dans la figure Fig. 4.7 reprsentent le mme comportement gnral de lapplication Vente, avec seulement deux , diffrences qui sont lobjet Agent et la mthode main (lagent qui lance lexcution de lapplication par sa mthode initiale main). ode
Fig. 5.11. Le Diagramme de squence gnr affich par un diteur Eclipse
68
CHAPITRE V
IMPLMENTATION
<fragment xmi:type="uml:CombinedFragment" xmi:id="_zyrdfmJnEd6iXaV5GJoiXQ" name="SDA5.6+7.8" interactionOperator="alt"> <operand xmi:id="_zyrdf2JnEd6iXaV5GJoiXQ" name="OPA5.6"> <fragment xmi:type="uml:ActionExecutionSpecification" xmi:id="_zyrdgGJnEd6iXaV5GJoiXQ" name="Exec_spe1" start="_zyrdgWJnEd6iXaV5GJoiXQ" finish="_zyrdgmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ExecutionOccurrenceSpecification" xmi:id="_zyrdgWJnEd6iXaV5GJoiXQ" name="StartExec_1" covered="_zyrdYmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ExecutionOccurrenceSpecification" xmi:id="_zyrdgmJnEd6iXaV5GJoiXQ" name="FinishExec_1" covered="_zyrdYmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_zyrdg2JnEd6iXaV5GJoiXQ" name="send_1" covered="_zyrdZWJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_zyrdhGJnEd6iXaV5GJoiXQ" name="receive_1" covered="_zyrdYmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ActionExecutionSpecification" xmi:id="_zyrdhWJnEd6iXaV5GJoiXQ" name="Exec_spe2" start="_zyrdhmJnEd6iXaV5GJoiXQ" finish="_zyrdh2JnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ExecutionOccurrenceSpecification" xmi:id="_zyrdhmJnEd6iXaV5GJoiXQ" name="StartExec_2" covered="_zyrdZmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ExecutionOccurrenceSpecification" xmi:id="_zyrdh2JnEd6iXaV5GJoiXQ" name="FinishExec_2" covered="_zyrdZmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_zyrdiGJnEd6iXaV5GJoiXQ" name="send_2" covered="_zyrdYmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_zyrdiWJnEd6iXaV5GJoiXQ" name="receive_2" covered="_zyrdZmJnEd6iXaV5GJoiXQ"/> </operand> <operand xmi:id="_zyrdimJnEd6iXaV5GJoiXQ" name="OPA7.8"> <fragment xmi:type="uml:ActionExecutionSpecification" xmi:id="_zyrdi2JnEd6iXaV5GJoiXQ" name="Exec_spe4" start="_zyrdjGJnEd6iXaV5GJoiXQ" finish="_zyrdjWJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ExecutionOccurrenceSpecification" xmi:id="_zyrdjGJnEd6iXaV5GJoiXQ" name="StartExec_4" covered="_zyrdY2JnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ExecutionOccurrenceSpecification" xmi:id="_zyrdjWJnEd6iXaV5GJoiXQ" name="FinishExec_4" covered="_zyrdY2JnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_zyrdjmJnEd6iXaV5GJoiXQ" name="send_4" covered="_zyrdZWJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_zyrdj2JnEd6iXaV5GJoiXQ" name="receive_4" covered="_zyrdY2JnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ActionExecutionSpecification" xmi:id="_zyrdkGJnEd6iXaV5GJoiXQ" name="Exec_spe5" start="_zyrdkWJnEd6iXaV5GJoiXQ" finish="_zyrdkmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ExecutionOccurrenceSpecification" xmi:id="_zyrdkWJnEd6iXaV5GJoiXQ" name="StartExec_5" covered="_zyrdZmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:ExecutionOccurrenceSpecification" xmi:id="_zyrdkmJnEd6iXaV5GJoiXQ" name="FinishExec_5" covered="_zyrdZmJnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_zyrdk2JnEd6iXaV5GJoiXQ" name="send_5" covered="_zyrdY2JnEd6iXaV5GJoiXQ"/> <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_zyrdlGJnEd6iXaV5GJoiXQ" name="receive_5" covered="_zyrdZmJnEd6iXaV5GJoiXQ"/> </operand> </fragment>
Fig. 5.12. Une partie du DS reprsente un fragment combin sous forme dun document UML
69
Conclusion et perspective
Conclusion et perspectives
1. valuation
Dans ce travail nous avons revisit le domaine de la rtro-ingnierie des diagrammes de squence dUML2. En premier temps, nous avons ralis un large tat de lart sur ce domaine et autour des travaux existants. Par la suite, nous avons propos une nouvelle approche permettant de construire un diagramme de squence partir de plusieurs traces dexcution du systme. Notre approche a suivi le schma gnral de la rtro-ingnierie et elle se base sur deux tapes principales : la collection des traces et la construction des modles. Pour la collection des traces, nous navons pas construit un nouvel outil de collection de trace, car il existe normment doutils efficaces dans la littrature correspondant aux plusieurs langages et plateformes [38, 52, 46, 50, 47, 48, 49, 51]. Selon lenvironnement du systme cibl nous pouvons choisir loutil de traage adquat, nous ragissons par une petite adaptation dans la partie collection de donnes . De cette faon nous assurons une indpendance vis--vis les langages et les plateformes. Pour la construction des diagrammes de squence, nous avons propos trois algorithmes principaux permettant de dtecter les trois oprateurs dinteraction principaux dUML2 savoir loop , opt et alt . Ces algorithmes nous ont permet de construire un diagramme de squence global reprenant les comportements de toutes les traces considres. Enfin, nous avons utilis lAPI UML2 comme un moyen pour construire des diagrammes de squence qui peuvent tre visualis et manipuls par les outils UML2.
2.
Discussion des rsultats

Lapproche que nous avons propose a quelques avantages par rapports aux travaux
existants que nous pouvons les rsumer dans les points suivants : Notre solution permet de construire un diagramme de squence complet qui reprsente le comportement gnral dun systme, pas seulement un diagramme de squence qui reprsente un comportement partiel du systme. Cette diffrence est en particulier engendre par le fait que nous avons considr plusieurs traces dexcution en entre et pas seulement une. La solution propose est indpendante de langages et plateformes du systme tudi (cf. la discussion ci-dessus).
70
Conclusion et perspective Assurer la portabilit des diagrammes extraits et la possibilit de les traiter automatiquement. Notre approche supporte compltement le standard UML2 et ses rsultats peuvent tre exploits par les outils UML2. Cependant, notre approche ltat actuel a quelques inconvnients : Nous navons pas encore support les applications avec imbrications. Il est aussi difficile davoir en entre des traces qui reprsentent tous les scnarios possibles des applications tudis.
3.
Perspectives
Comme nous lavons soulign ci-dessus, linconvnient majeur de notre approche
concerne le non support des blocs imbriqus. Le problme principal rside dans la faon de dlimiter les blocs dans les diffrentes traces. Nous souhaitons traiter cette limite dans un travail futur. Il nous reste aussi dentamer la dtection des fragments combins avec les oprateurs break, par, etc. et de faire supporter le reste des notations du diagramme de squence dUML tels que : gates, continuants, interactionUse, etc. Un autre axe de recherche future est dextraire dautres types de diagrammes dUML tels que les diagrammes dtats et les diagrammes de communication, soit en utilisant des mthodes de transformation ou bien en utilisant dautres techniques. Nous pensons que par la mthode hybride on peut atteindre les bons rsultats, puisque lutilisation des deux mthodes statique et dynamique engendre une bonne quantit dinformations, nous planifions de trouver une combinaison adquate de ces deux sources dinformations pour une meilleure rtro-ingnierie des modles UML.
71
Rferences
[1] A. Rountev, O. Volgin and M. Reddoch. Static control flow analysis for reverse engineering of UML SD. Workshop on Program Analysis for Software Tools and Engineering. 2005. P. Tonella and A. Potrich. Reverse engineering of the UML class diagram from C++ code in presence of weakly typed containers. In Proceedings of the International Conference on Software Maintenance, pages 376385, Firenze, Italy, 2001. IEEE Computer Society. E. Chikofsky and J. I. Cross. Reverse engineering and design recovery: A taxonomy. IEEE Software, 7(1):1317, Jan 1990. E. Eilam. Reversing: Secrets of Reverse Engineering. Publishing, Inc. ISBN-10: 07645-7481-7. 2005. J. Ka-Yee Ng. Identification of Behavioral and Creational Design Patterns through Dynamic Analysis. Proceedings of the 3rd International Workshop on Program Comprehension through Dynamic Analysis (PCODA), pages 34-42, October 2007. T. Systa. Static and dynamic reverse engineering techniques For Java Software Systems. Ph.D Thesis, University of Tampere, Dept. of Computer and Information Sciences, Report A-2000-4, 2000. R. Oechsle and T. Schmitt. JAVAVIS: Automatic Program Visualization with Object and Sequence Diagrams Using the Java Debug Interface (JDI). Software Visualization, pp. 672-675. 2002. T. Richner and S. Ducasse. Using Dynamic Information for the Iterative Recovery of Collaborations and Roles. Software Maintenance, 2002. Proc. International Conference Software Maintenance (ICSM'02), pp. 34 43, 2002. W. De Pauw, D. Kimelman, and J. M. Vlissides. Modeling object-oriented program execution. In Proceedings of the 8th European Conference on Object-Oriented Programming, 821: 163182. Springer-Verlag, July 1994. W. De Pauw, E. Jensen, N. Mitchell, G. Sevitsky, J. Vlissides, J. Yang. Visualizing the Execution of Java Programs. Revised Lectures on Software Visualization, International Seminar. pp. 151162, 2001. L. C. Briand, Y. Labiche, Y. Miao. Towards the Reverse Engineering of UML Sequence Diagrams. Proceedings of the 10th Working Conference on Reverse Engineering. 2003. L. C. Briand, Y. Labiche, J. Leduc. Toward the Reverse Engineering of UML Sequence Diagrams for Distributed Java Software. Software Engineering, IEEE Transactions on, 32(9): 642-663, Sept. 2006. Y.-G. Guhneuc, T. Ziadi. Automated Reverse-engineering of UML v2.0 Dynamic Models. Proc. ECOOP Workshop Object-Oriented Reengineering, 2005. G. Antoniol, M. Di Penta and M. Zazzara. Understanding Web Applications through Dynamic Analysis. Program Comprehension, 2004. Proceeding 12th IEEE International Workshop. R. Koschke. What architects should know about reverse engineering and Reengineering. Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference. L. Wendehals. Selective Tracer for Java Programs. Proceedings of the 2nd International Fujaba Days 2004, Darmstadt, Germany. September 2004. D. Cooper, B. Khoo, B. R. von Konsky, M. Robey. Java Implementation Verification Using Reverse Engineering. Proceedings of the 27th Australasian conference on Computer science, pp. 203-211, January 01, 2004, Dunedin, New Zealand. 72
[2]
[3] [4] [5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13] [14]
[15] [16] [17]
[18] T. Ball. The Concept of Dynamic Analysis. Proceedings of the 7th European software engineering conference held jointly with the 7th ACM SIGSOFT international symposium on Foundations of software engineering, Toulouse, France. 1999. [19] M. Van Hilst and E. B. Fernandez. Reverse Engineering to Detect Security Patterns in Code. Proccedings the 1st International Workshop on Software Patterns and Quality (SPAQu'07), co-located with 14th Asia-Pacific Software Engineering Conference (APSEC'07), Nagoya, Japan, December 3, 2007. [20] A. Hamou-Lhadj. The Concept of Trace Summarization. Proceedings of the 1st International Workshop on Program Comprehension through Dynamic Analysis colocated with IEEE WCRE, Pittsburg, USA, 2005. [21] A. Kuhn, O. Greevy and T. Grba. Applying Semantic Analysis to Feature Execution Traces. Proceedings IEEE Workshop on Program Comprehension through Dynamic Analysis (PCODA 2005). IEEE Computer Society Press: Los Alamitos CA, 2005. [22] H. Lee, C. Yoo. A Form Driven Object-Oriented Reverse Engineering Methodology. Information Systems, 25 (3): 235259, May 2000. [23] A. Hamou-Lhadj, T. C. Lethbridge. A Survey of Trace Exploration Tools and Techniques. Proceedings of the 2004 conference of the Centre for Advanced Studies on Collaborative research, p.42-55, October 04-07, 2004, Markham, Ontario, Canada. [24] E. Stroulia, T. Systa. Dynamic Analysis for Reverse Engineering and Program Understanding. ACM SIGAPP Applied Computing Review, 10(1): 817, 2002. [25] G. Canfora and M. Di Penta. New Frontiers of Reverse Engineering. International Conference on Software Engineering, 2007 Future of Software Engineering, pp. 326341, May 2007. [26] L. M. Duarte. Behaviour Model Extraction using Context Information. Ph.D. Thesis, Department of Computing, Imperial College London, December 2007. [27] L. Audibert. UML2. d. 2007-2008. [28] OMG. Unified Modeling Language (OMG UML), Superstructure. V2.1.2. November 2007. [29] OMG. Unified Modeling Language (OMG UML), Infrastructure. V2.1.2. November 2007. [30] R. J. Walker, G. C. Murphy, B. Freeman-Benson, D. Wright, D. Swanson, and J. Isaak. Visualizing Dynamic Software System Information through High-level Models. ACM SIGPLAN Notices, 33(10): 271283, October 1998. [31] N. Shi and A. Ronald. Reverse Engineering of Design Patterns for High Performance Computing. In Proceedings of the 2005 Workshop on Patterns in High Performance Computing, 2005. [32] L. Angyal, L. Lengyel, H. Charaf. An Overview of the State-of-The-Art Reverse Engineering Techniques. Proceedings of 7th International Symposium of Hungarian Researchers on Computational Intelligence, 2006. [33] ILogix. Rhapsody, the Rhapsody case tool. http://www.ilogix.com. [34] Rational. Rose, the Rational Rose case tool. http://www.rational.com. [35] Object International. TogetherJ, the TogetherJ case tool. http://www.togethersoft.com. [36] T. Ziadi. Manipulation de Lignes de Produits en UML. Ph.D. Thesis, Universit de Rennes 1, 2004. [37] B. Cornelissen, A. van Deursen, L. Moonen, et A. Zaidman. Visualizing Testsuites to Aid in Software Understanding. Proceedings 11th Conference on Software Maintenance and Reengineering (CSMR), IEEE Amsterdam, Netherlands, 2007; 213222. [38] Y.-G. Gueheneuc, R. Douence, N. Jussien. No Java without Caffeine: A Tool for Dynamic Analysis of Java Programs. Proceedings of the IEEE 17th international Conference on Automated Software Engineering, Sept., 2002. Page, 117. 73
[39] J. W. Nimmer et M. D. Ernst. Automatic Generation of Program Specifications. Intl Symp. on Software Testing and Analysis, pp. 232242, Rome, Italy, July 2002. [40] J. Niere, M. Meyer, and L. Wendehals. User-driven adaption in rule-based pattern recognition. Technical report, tr-ri-04-249, University of Paderborn, Paderborn, Germany, June 2004. [41] M. Lanza and S. Ducasse. Polymetric views - a lightweight visual approach to reverse engineering. IEEE Trans. Software Eng., 29(9):782795, 2003. [42] J. I. Maletic, A. Marcus, and L. Feng. Source Viewer 3D (sv3D) - a framework for software visualization. In Proceedings of the 25th International Conference on Software Engineering (ICSE 2003), May 3-10, 2003, Portland, Oregon, USA, pp. 812 813, 2003. [43] K. Wong, S. Tilley, H. A. Muller, and M. D. Storey. Structural redocumentation: A case study. IEEE Software, 12(1): 4654, Jan. 1995. [44] D. B. Lange and Y. Nakamura. Interactive visualization of design patterns can help in framework understanding. In Proceedings of the Annual ACM SIGPLAN Conferences on Object-Oriented Programming, Systems, Languages, and Applications, pp. 342357, 1995. [45] R. J. Walker, G. C. Murphy, B. Freeman-Benson, D. Swanson, J. Isaak. Visualizing Dynamic Software System Information through High-level Models. In Proc. ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, pp. 271283, British Columbia, Canada, 1998. [46] University of Oregon, TAU: Tuning and Analysis Utilities, http://www.cs.uoregon.edu/research/paracomp/tau/, 1999. [47] A. Chawla and A. Orso. A Generic Instrumentation Framework for Collecting Dynamic Information. SIGSOFT Software Engineering Notes, Section: Workshop on Empirical Research in Software Testing. ACM Press, 29(5):14, September 2004. [48] Sun Microsystems. Java Platform Debugger Architecture(JPDA). Online at http://java.sun.com/products/jpda/index.jsp. Last visited: September 2005. [49] B. Lewis. Recording Events to Analyze Programs. In Object-Oriented Technology. ECOOP 2003 Workshop Reader. Lecture notes on computer science (LNCS 3013), Springer, July 2003. [50] L. Wendehals. Tool Demonstration: Selective Tracer for Java Programs. In Proc. of the 12th Working Conference on Reverse Engineering, Pittsburgh, Pennsylvania, USA, November 2005. [51] A. Vasconcelos, R. Cepda, C. Werner. An Approach to Program Comprehension through Reverse Engineering of Complementary Software Views. Proceedings of the 1st International Workshop on Program Comprehension through Dynamic Analysis (PCODA'05) 2005. [52] F. Fleurey. JTracor. Available at : http://franck.fleurey.free.fr/JTracor/index.htm [53] M. Alanen and I. Porres. Model Interchange Using OMG Standards. Software Engineering and Advanced Applications, 2005. 31st EuroMicro Conference on 30 Aug.-3 Sept. 2005. [54] N. Walkinshaw, K. Bogdanov, and M. Holcombe. Identifying state transitions and their functions in source code. In Testing: Academic and Industrial Conference (TAIC PART06), pages 4958. IEEE Computer Society, 2006. [55] L. M. Duarte, J. Kramer, and S. Uchitel. Model extraction using context information. In O. Nierstrasz, J. Whittle, D. Harel, and G. Reggio, editors, MoDELS, volume 4199 of Lecture Notes in Computer Science, pages 380394. Springer, 2006.
74
[56] J. Whaley, M. Martin, and M. Lam. Automatic Extraction of Object-Oriented Component Interfaces. In Proceedings of the International Symposium on Software Testing and Analysis, July 2002. [57] A. W. Biermann and J. Feldman. On the synthesis of finite state machines from samples of their behavior. IEEE Transactions on Computers, 21:592597, 1972. [58] D. Pierre, L. Bernard, D. Christophe, V. L. Axel. The QSM Algorithm and its Application to Software Behavior Model Induction. Applied Artificial Intelligence, 22 (1):77-115, 2008. [59] N. Walkinshaw, K. Bogdanov, M. Holcombe, and S. Salahuddin. Reverse engineering state machines by interactive grammar inference. In WCRE '07: Proceedings of the 14th Working Conference on Reverse Engineering, pp.209218, Washington, DC, USA, 2007. IEEE Computer Society. [60] T. Ziadi, L. Helouet, and J.-M. Jezequel. Revisiting statechart synthesis with an algebraic approach. In ICSE '04: Proceedings of the 26th International Conference on Software Engineering, pp. 242251, Washington, DC, USA, 2004. IEEE Computer Society. [61] H. Yuan, T. Xie, and E. Martin. Automatic extraction of abstract-object-state machines from unit-test executions. In ICSE '06: Proceedings of the 28th international conference on Software engineering, pp. 835838, New York, NY, USA, 2006. ACM. [62] D. Harel. Statecharts, A visual formalism for complex systems. Science of Computer Programming, 8(3) :231274, 1987. [63] http://www.uml.org/#Links-Tools, 2010.
75
Annexes
(1) Code de dtection des fragments combins de type "loop"
static void cf_construct(Connection Contact) throws SQLException{ Statement Requet=Contact.createStatement(); ResultSet re=Requet.executeQuery("select max(tr_file) from Mess_tr ;"); int tr_file=1; if (re.next()) tr_file= re.getInt(1); re.close(); for (int tr=1;tr<=tr_file;tr++){ Statement Requete1=Contact.createStatement(); ResultSet res= Requete1.executeQuery("select cde_mess, ord_mess from Mess_tr where tr_file="+tr+" order by ord_mess;"); Statement Requete2=Contact.createStatement(); ResultSet res2= Requete2.executeQuery("select count(*)from Mess_tr where tr_file="+tr+";"); if (res2.next()){ if (res.next()){ int taille= (int) res2.getLong(1); int []tab = new int [taille+2]; System.out.println("taille = : "+taille+" tr ="+tr); int j=1; //Copy cde_mess into an array: for (j=0;j<taille;j++){ tab[j]=res.getInt(1); System.out.println("ok : "+tab[j]); res.next(); } // find int_frag: int suit_loop=0; int L=1,cf=0; int h=0; for (j=1;j<taille;j++){ //loop until the end of messages sequence if (tab[j]!=tab[j-L]){ //detect the eventual fragment begin L++; if (j==taille-1){ L=1; h++; j=h; } } else { //Begin detected suit_loop=0; String intf=""; int m=0; int c=0; int f=0; for (m=j+1;m<=j+L;m++){ //loop to check the rest of fragment
76
if (m==j+L){ //this is a loop fragment if (suit_loop==0){ for (int n1=j; n1<m; n1++) { intf+= tab[n1]; } cf++; } else{ System.out.println(" loop suit: "); } if (tab[m]==tab[j]){ //detect the eventual suit of loops j=m; suit_loop=1; } else c=1; } else if (tab[m]!=tab[m-L]){ // no fragment detected: continue f=j; m=f+L+2; } } if (c==1){ //move to the rest after the currant fragment L=1; j=m-1; h=m-1; System.out.println("Parsed messages number: "+j); } } } } } } }
(2)
Code source de lapplication Vente
public class Vendor { /** * @param args */ public static void main(String[] args) { int nbr_article=4; boolean isInvoice=false; boolean isPayslip=true; Sale sale=new Sale(); sale.newSale(nbr_article, isInvoice,isPayslip); }
77
public static void signInvoice(){ System.out.println("Invoice signed"); } public static void signDelivery(){ System.out.println("Delivery signed"); } public static void signPayslip(){ System.out.println("Payslip signed"); } } public class Sale { public void newSale(int nbr_article, boolean isInvoice, boolean isPayslip){ float oldValue=0; System.out.println("New sale created"); for(int i=1;i<=nbr_article;i++){ float newValue=addArticle(); Calcul calcul= new Calcul(); oldValue=calcul.calculAmount(newValue, oldValue); } if(isInvoice){ Invoice invoice= new Invoice(); invoice.getInvoice(); } else { Delivery delivery= new Delivery(); delivery.getDelivery(); } if(isPayslip){ Payslip payslip=new Payslip(); payslip.getPayslip(); } } public static float addArticle(){ System.out.println("New article added"); return 1000; } } public class Calcul { // /* *This method add new amount to the old amount * */ public float calculAmount(float newValue, float oldValue){ System.out.println("Amount calculated"); float amount=newValue+oldValue; return amount; } } public class Delivery { public void getDelivery(){ System.out.println("Delivery printed"); Vendor.signDelivery(); } } public class Invoice { public void getInvoice(){ System.out.println("Invoice printed");
78
Vendor.signInvoice(); } } public class Payslip { public void getPayslip(){ System.out.println("Payslip printed"); Vendor.signPayslip(); } }
79
ABSTRACT Reverse Engineering of UML 2 Dynamic Models Many legacy systems are developed without providing the necessary documentation for future maintenance and evolution. In such cases; maintainers and developers will spend more time and will make a great effort (more cost) in system structure and behavior understanding phase. Despite the great amount of system comprehension step; results are error-prone even if maintainers are themselves the inner developers. The reverse engineering aims to alleviate developers and maintainers in their work by restraining cost and increasing system comprehension precision; and to present results in a human understandable manner. This study proposes a new approach for UML dynamic models reverse engineering; in particular sequence diagrams; by concentrating on the new notions introduced in the resent versions of UML such as combined fragments. We have followed the dynamic method to obtain information on the system. Our approach is composed of two main parts, which are: 1) traces collection and 2) sequence diagram construction. We have presented an overview of the reverse engineering and related works; as well as; our approach implementation details are explained. Furthermore; we have been successful in testing our solution on a modest application, which encourages us to expect new achievements in the future. Keywords: reverse engineering, UML sequence diagram, behavioral models, static analysis, dynamic analysis. RSUM Rtro-ingnierie des modles comportementaux dUML 2 De nombreux anciens systmes sont dvelopps sans fournir la documentation ncessaire pour leur maintenance et leur volution futures. Dans tels cas, les mainteneurs et les dveloppeurs passent plus de temps et fournissent un grand effort (cot en plus) dans la phase de comprhension du comportement et de la structure du systme. Quelle que soit le cot de l'tape de comprhension du systme, les rsultats peuvent tre errons, mme si les mainteneurs sont eux-mmes les premiers dveloppeurs. La rtro-ingnierie vise faciliter le travail des dveloppeurs et des mainteneurs par la rduction du cot dune part et d'accrotre la prcision de comprhension du systme et de prsenter les rsultats d'une manire comprhensible dune autre part. Dans cette tude, nous avons propos une nouvelle approche pour la rtro-ingnierie des modles comportementaux dUML, en particulier les diagrammes de squence, en se concentrant sur les nouvelles notions introduites dans les versions rcentes dUML, tels que les fragments combins. Nous avons suivi la mthode dynamique pour obtenir des informations sur le systme. Notre approche se compose de deux parties principales qui sont : 1) la collection de traces et 2) la construction du diagramme de squence. Nous avons prsent une vue densemble sur le domaine de la rtro-ingnierie et les travaux existants, ainsi, les dtails d'implmentation de notre approche sont expliqus. En outre, nous avons russi le test de notre solution sur une application modeste, ce qui nous pousse raliser de nouvelles recherches dans ce domaine dans le futur. Mots cls : rtro-ingnierie, diagramme de squence dUML, modles comportementaux, analyse statique, analyse dynamique.

127627-Rétro-Ingénierie Des Modèles

Transféré par

Droits d'auteur :

Formats disponibles

127627-Rétro-Ingénierie Des Modèles

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

127627-Rétro-Ingénierie Des Modèles

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

Ministre de lEnseignement Suprieur et de la Recherche Scientifique Universit El Hadj Lakhdar BATNA

Facult des Sciences et des Sciences de lingnieur

Mmoire prsent en vue de lobtention du diplme

Rtro-ingnierie des modles comportementaux dUML 2

Prsent le : 28 /09 /2010 Par : Wahab ROUAGAT

4.1.1 4.2 4.3 5. 6.

Extraction dinformations pertinentes .................................................................. 13 Visualisation........................................................................................................... 14

La rtro-ingnierie des logiciels orients objet ........................................................... 15 Conclusion .................................................................................................................... 16

CHAPITRE 3 RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX .................................. 27

2.2.1 2.2.2 2.2.3 2.3

Discussion et conclusion ........................................................................................ 35

Application de lapproche sur lexemple Vente ........................................................... 64

Cas dutilisation ..................................................................................................... 64

Liste des figures

AVEC LES DONNES DENTRE DE CHAQUE

REPRSENTE UN FRAGMENT COMBIN SOUS FORME DUN

dsigner la mme chose.

Partie 1 : tat de lart

Origine et Dfinition de la rtro-ingnierie

Fig.1.1. Modle darchitecture des outils par [3]

Apports de la rtro-ingnierie logiciel

Extraction dinformations pertinentes

Analyse : hybride, Dynamique & Statique

Formes Personnelles & Standards

Fig. 1.2. tapes principales de la rtro-ingnierie

Fig. 1.3. Graphe dinteraction gnr avec Program Explorer [44]

La rtro-ingnierie des logiciels orients objet

LANGAGE DE MODLISATION UNIFI (UML)

Chapitre 2 : Langage de Modlisation Unifi (UML)

LANGAGE DE MODLISATION UNIFI (UML)

LANGAGE DE MODLISATION UNIFI (UML)

Fig. 2.1. Larchitecture quatre niveaux de lOMG

Les Diagrammes dUML2

LANGAGE DE MODLISATION UNIFI (UML)

LANGAGE DE MODLISATION UNIFI (UML)

Fig. 2.2. Exemple de machine tat

LANGAGE DE MODLISATION UNIFI (UML)

Fig. 2.3. Une partie du mta-modle des diagrammes de squence dUML2

LANGAGE DE MODLISATION UNIFI (UML)

Fig. 2.4. Exemple dun DS dans UML2.0 et ses concepts

Fig. 2.5. Exemple des rfrences vers les DS dans UML2

LANGAGE DE MODLISATION UNIFI (UML)

LANGAGE DE MODLISATION UNIFI (UML)

Fig. 2.6. Exemple dun diagramme de squence combin

LANGAGE DE MODLISATION UNIFI (UML)

RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX

Chapitre 3 Rtro-ingnierie des modles comportementaux

Etat de l'art sur la comportementaux d'UML

RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX

RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX

Fig. 3.1. CFG et son diagramme de squence correspond [1]

RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX

Fig. 3.2. DS aprs lexcution de deux itrations dune boucle [7]

RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX

Fig. 3.3. Architecture de JAVAVIS [7]

RTRO-INGNIERIE DES MODLES COMPORTEMENTAUX

Fig. 3.4. Mta-modle de diagramme de scnario Briand et al. [12]

Fig. 3.5. Mta-modle de trace Briand et al. [12]