RéingenierieRéingenierie: : Thi lTechnique pour la ...

Faculté des Sciences de l’Ingéniorat Faculté des Sciences de l’Ingéniorat Département d’informatiqueDépartement d’informatiquep qp q

RéingenierieRéingenierie: : T h i lT h i lTechnique pour la Technique pour la

Maintenance de logicielsMaintenance de logiciels1 P é té

Maintenance de logicielsMaintenance de logiciels1 Présenté par:

Dr Nora BOUNOURDr Nora BOUNOUR

RÉINGÉNIERIE “REENGINEERING”

La Réingénierie “Reengineering” est définit comme suit :

C’est l’examen et la modification du système pour corrigerles fautes, améliorer la conception ou les performances, etmodifier le produit pour satisfaire des exigencesmodifier le produit pour satisfaire des exigencesd’amélioration ou de changement [Chikovsky 90].

C’est l’altération d’un logiciel dans le but de le reconstruiresous une nouvelle forme censée être meilleure. Même sielle peut être utilisée pour des changements mineurs, elleelle peut être utilisée pour des changements mineurs, elleest souvent utilisée pour remplacer les logiciels âgés(héritage) «Legacy systems » [Swebock 04].

2

Master 2 ILC Maintenance: Techniques et Outils

2

Fondamentalement un nouveau système est Fondamentalement, un nouveau système estgénéré à partir d'un système opérationnel, tel quele nouveau système possède de meilleurs facteursle nouveau système possède de meilleurs facteursde qualité. Les facteurs de qualité de logicielssouhaités comprennent la fiabilité, l'exactitude,

é é é él'intégrité, l'efficacité, la maintenabilité, laconvivialité, la flexibilité, la testabilité,l'interopérabilité la réutilisation et la portabilitél interopérabilité, la réutilisation et la portabilité.

3


3

LES CONCEPTS DE LA RÉINGÉNIERIE

L’abstraction et le raffinement sont les concepts cléstili é d l dé l t d l i i l t l dutilisés dans le développement de logiciels, et les deux

concepts sont également utiles dans la réingénierie.

Principe de l’abstraction. Le niveau d'abstraction de lareprésentation d'un système peut être progressivementreprésentation d un système peut être progressivementdéveloppé en remplaçant successivement les détails parune information abstraite.

Principe de raffinement. Le niveau d'abstraction de lac pe de a e e t e eau d abst act o de areprésentation du système est progressivement diminuéen remplaçant successivement certains aspects du

è é 4


système avec plus de détails 4

5

Figure 1. Levels of abstraction and refinement. © 1992 IEEE


5

Niveau conceptuel Au plus haut niveau Niveau conceptuel. Au plus haut niveaud'abstraction, le logiciel est décrit en termes deconcepts de très haut niveau et sa raison d'êtreconcepts de très haut niveau et sa raison d être(pourquoi ? pourquoi le système existe-t-il ?)

Niveau des besoins. A ce niveau, lescaractéristiques fonctionnelles (quoi ?) du systèmesont décrites à un niveau élevé, (que permet defaire le système ?)

6


6

Niveau de la conception Au niveau de la Niveau de la conception. Au niveau de laconception-raffinement, les caractéristiques dusystème (quoi ? et comment ?), à savoir, lessystème (quoi ? et comment ?), à savoir, lesprincipaux composants, le style architectural descomposants, les interfaces entre les composants,

éles algorithmes, structures de données internesmajeures, et les bases de données sont décrites endétaildétail.

Niveau d’implémentation Ceci est le plus bas Niveau d’implémentation. Ceci est le plus basniveau d'abstraction dans la hiérarchie. À ce niveau,le système est décrit à un niveau très faible en 7


le système est décrit à un niveau très faible en 7

PRINCIPE D'ALTÉRATION

En plus des deux principes de l'abstraction et de En plus des deux principes de l abstraction et deraffinement, un principe optionnel appelé altérationsous-tend de nombreuses méthodes desous tend de nombreuses méthodes deréingénierie.

Principe d'altération. Tout changement effectuép gà la représentation d’un système est connu commel'altération. L’altération n’implique aucunh t d é d l' b t ti t ’i lichangement au degré de l'abstraction, et n’implique

pas une modification, ou une suppression ou ajoutd’informationd information.

8


8

La Figure 2 montre l'utilisation des trois principes La Figure 2 montre l utilisation des trois principesfondamentaux pour expliquer les caractéristiques deréingénierie.

9


9

RESTRUCTURATION

Un autre terme étroitement liée à «l’Altération» est Un autre terme étroitement liée à «l Altération» estla restructuration.

Dans le contexte de la réingénierie, le terme«restructuration» est défini comme la«restructuration» est défini comme latransformation d'une forme de représentation à uneautre au même niveau d’abstraction tout enpréservant le comportement extérieur du système.

10


10

PROCESSUS DE RÉINGÉNIERIE

Avant qu'un système logiciel puisse être maintenu:

Il doit être analysé, en effet, un modèle mental du logiciel doit êtreconstruit dans lequel les décisions de conception sont bien représentéesconstruit dans lequel les décisions de conception sont bien représentées.

Les modifications sont ensuite implémentées.p

Les éléments du cycle de vie de la réingénierie de logiciely g gsont alors:

la rétro-ingénierie « Reverse Engineering »,t l dé l t F d E i i et le redéveloppement « Forward-Engineering »

11


11

Ce processus est formellement présenté par Ce processus est formellement présenté parJacobson et Lindstorm par l'expression suivante :

Reengineering = Reverse engineering + Δ + Forward engineering.

I Jacobson and F Lindstrom 1991 Re-engineeringI. Jacobson and F. Lindstrom. 1991. Re engineeringof Old Systems to an Object-oriented Architecture.Proceedings of the ACM Conference on ObjectOriented Programming Systems Languages andApplications, October 1991. ACM Press, New York,NY pp 340 350 12


NY. pp. 340–350. 12

CYCLE DE VIE DE LA RÉINGÉNIERIE DU LOGICIEL

13


13

REDÉVELOPPEMENT “FORWARD ENGINEERING”

C’est le processus traditionnel permettant de passer des C est le processus traditionnel permettant de passer desabstractions de haut niveau et de la conception logiqueindépendante de l’implémentation à la mise en œuvrephysique d'un système.

14


14

MODEL OF SOFTWARE REENGINEERING. 1992 IEEE1992 IEEE

15


15

LES TYPES DE MODIFICATION

Le modèle de la figure 3 suggère qu'un système existant peut Le modèle de la figure 3 suggère qu un système existant peut être restructuré par l'un des quatre chemins suivants :

(recode, redesign, respecify, rethink).

Les modifications au sein d'un groupe particulier se traduisent Les modifications au sein d un groupe particulier se traduisentpar des modifications dans les niveaux d'abstractioninférieurs. Par exemple, un besoin se traduit par de nombreuxélé t d ti t t d ti téléments de conception, et un composant de conception estréalisée par un bloc de code source. Ainsi, un petitchangement dans un composant de conception peut

16


nécessiter plusieurs modifications au code. 16

RecoderRecoder.Les modifications au niveau du code source sontff t é d f l ti ( h i )effectuées au moyen de reformulation (rephrasing)

et de traduction du programme. Dans cettedernière approche un programme est transformédernière approche, un programme est transforméen un programme dans un langage différent.D'autre part, la reformulation maintient lep ,programme dans le même langage.

17


17

EXEMPLES

Normalization reduces a program to a program in a Normalization reduces a program to a program in a sublanguage, that is to a subset of the language, with the purpose of decreasing its syntacticwith the purpose of decreasing its syntactic complexity. Elimination of GOTO dans un programme sont des examples de normalization de programme.

Optimization is a transformation that improves the execution time or space performance of a program.

Refactoring is a transformation that improves the d i f b f t t i t 18


design of a program by means of restructuring to better understand the new program

18

Reconcevoir Reconcevoir.Les caractéristiques de conception du logiciel sont modifiéespar la reconception dusystème. Les Changements généraux de la conception dulogiciel incluent :

(i) la restructuration de l'architecture ;(ii) la modification du modèle de données du système ;(iii) l l t d' éd d' l ith t(iii) le remplacement d'une procédure ou d'un algorithme par un autre

plus efficace.

19


19

Respécifier Respécifier.Cela implique de changer les caractéristiques desbesoins du système de deux façons :besoins du système de deux façons :

(i) changement de la forme des besoins

(ii) (ii) changement de la portée des besoins. Lapremière façon se réfère seulement à lapremière façon se réfère seulement à lamodification de la forme des besoins existants, ledernier type de changements inclut lesmodifications comme l'ajout de nouveaux besoins,la suppression de certains besoins et la

difi ti d t i b i i t t 20


modification de certains besoins existants. 20

Repenser Repenser.Ceci implique de modifier les caractéristiquesconceptuelles du système ceci peut conduire leconceptuelles du système, ceci peut conduire lesystème à un changement fondamental. Latransition du développement pour les téléphonespp p pcellulaires ordinaires vers le développement dessmartphones est un exemple de « Rethink ».

21


21

les stratégies de la réingénierie logicielleg g g

Les Trois stratégies de la réingénierie sont : Les Trois stratégies de la réingénierie sont :

Réécriture (rewrite)Réécriture (rewrite),Retravailler (rework),R l ( l )Remplacer (replace).

22


22

La stratégie Rewrite Au moyen de l’altération La stratégie Rewrite. Au moyen de l altération,un système opérationnel est transformé en unnouveau système, tout en préservant le niveaunouveau système, tout en préservant le niveaud'abstraction du système initial.

24


24

La stratégie Rework La stratégie « Retravailler » La stratégie Rework. La stratégie « Retravailler »applique les trois principes. Tout d'abord, par lebiais du principe d'abstraction, permet d'obtenir unebiais du principe d abstraction, permet d obtenir unereprésentation du système avec moins de détailsque ce qui est disponible à un niveau donné.

è è éEnsuite, le modèle du système reconstitué esttransformé dans la représentation du système cible,au moyen d'une altération sans changer le niveauau moyen d une altération, sans changer le niveaud'abstraction. Enfin, par le biais de raffinement, unenouvelle représentation appropriée du système estou e e ep ése tat o app op ée du systè e estcréée à un niveau inférieur de l'abstraction.

25


25

La stratégie Replace Dans le but de changer La stratégie Replace. Dans le but de changerune certaine caractéristique d'un système :

(i) le système est reconstruit à un niveau d'abstractionplus élevé en cachant les détails de la caractéristique

(ii) une représentation appropriée pour le système ciblet é é é à i d' b t ti i fé iest générée à un niveau d'abstraction inférieur par

application de raffinement.

26


26

CLASSIFICATION DES TRANSFORMATIONS[ CHIKOVSKY 90]

27


27

TABLE 1. TAXONOMIE DE CHIKOFSKY ANDCROSS [CHIKOVSKY 90]CROSS [CHIKOVSKY 90]

28


28

LA RESTRUCTURATION

L’objectif premier de la restructuration est d’améliorer lamaintenabilité du code pour diminuer les coûts demaintenance.

Au-delà de cet objectif, la rénovation a des implications suré éla stratégie d’évolution des applications. En effet, lorsqu’une

application devient trop difficile à maintenir le managementa deux options :a deux options :

Réécrire l’application Réécrire l application. Remplacer l’application par une autre application.

29


29

LA RESTRUCTURATION

Elle désigne une activité qui transforme la structure interne d’ung qprogramme ou d’un logiciel sans changer de niveau d’abstraction etsans modifier ou ajouter de nouvelles fonctions. Elle visesans modifier ou ajouter de nouvelles fonctions. Elle visehabituellement à accroître la qualité technique d’une application ouà présenter un ou plusieurs composants sous une autre formeà présenter un ou plusieurs composants sous une autre forme.

Elle n’ajoute aucune fonctionnalité au système et ne répond pas àun besoin fonctionnel des utilisateurs.

30


30

LA RESTRUCTURATION

Cette activité de restructuration recouvre différents types d’actions, qui vonts’adapter à la façon dont est fait le logiciel. On va recourir souvent à troisétapes de travail :

1. la restructuration des flux : Le but de ce travail de nettoyage du code est deretrouver une structure globale tout à fait cohérente sur l’application.

on va tenté d’améliorer la structure globale des modulescomposants l’application. Ceci va se traduire par exemple par leregroupement de fonctions/méthodes éparpillées dans diversmodules, de classer les diverses fonctions avec plus decohérence. 31


31

LA RESTRUCTURATION

2 é l ’ ff l’ l h d d f2. La restructuration peut également s’effectuer sur l’algorithmique du code, afin

de le rendre plus efficace, ou plus clair.

On va dans cette phase supprimer le code mort et les variables non utilisées On va dans cette phase, supprimer le code mort et les variables non utilisées,supprimer les fichiers devenus inutiles,

remplacer par exemple les structures IF ELSE IF imbriqué par des structuresremplacer par exemple les structures IF ELSE IF imbriqué par des structuresCASE, plus clair, et surtout moins coûteux en temps de calcul (L’interprétationd’un case consomme une seule évaluation d’instruction booléenne, tandis qu’il ya autant d’instructions et de test évalués que de IF imbriqués).

3. Normalisation des noms dans code.

32


32

RéingenierieRéingenierie: : Thi lTechnique pour la ...

Documents

Transcript of RéingenierieRéingenierie: : Thi lTechnique pour la ...