Rétro-ingéniérie. Jean-Yves Didier

Transcription

1 Rétro-ingéniérie Jean-Yves Didier L objectif de ce TD est de construire une représentation graphique permettant d avoir une vue synthétique du code source d un logiciel. Il s agit donc de faire de la rétro-ingénierie ou reverse engineering sur un programme existant. Cela sera également l occasion de réviser ou de découvrir des notions associées au langage Java introduit l an passé. Enfin, cela permettra d introduire quelques notations du langage UML pour construire le diagramme de classes d une application. 1 Documentation des classes Pour chacune des classes données dans l annexe A, déterminer leurs attributs et leurs méthodes. Nous représenterons ces classes sous la forme d une classe documentée en UML, c est à dire un rectangle avec 3 compartiments, à l instar de ce que l on peut voir à la figure 1 : le premier compartiment contient le nom de la classe ; le deuxième compartiment contient la liste des attributs ; le troisième compartiment contient la liste des méthodes. Fraction numerateur : Integer=0 denominateur : Integer=1 valeur : Float + Fraction(n : Integer, d : Integer=1) : Fraction + getvaleur() : Float + getnumerateur() : Integer + getdenominateur() : Integer + setnumerateur(n : Integer) : void + setdenominateur(d : Integer) : void FIGURE 1 Classe documentée représentant une fraction En tant qu éléments des classes, les attributs possèdent une représentation très codifiée légèrement différentes de celle que l on trouve dans les programmes Java. La forme générale de cette représentation est la suivante : visibilité nom: type[= valeur_defaut] La valeur par défaut est optionnelle. Les différentes visibilités sont notées de la manière suivante : + : public l attribut est accessible depuis n importe quelle classe ; : privé l attribut n est accessible que dans le code de la classe ; # : protégé l attribut n est accessible que par sa classe contenante et ses sous-classes ; 1

2 Les opérations ont également une représentation codifiée et possèdent de nombreux points communs avec les attributs. Leur forme générale est la suivante : visibilité nom( bloc_param1, bloc_param2,...) : type_retour Les paramètres possèdent aussi leur notation. Si l on détaille chaque bloc, cela donne : nom: type[=valeur_defaut] Cette représentation permet de connaître la structure de chaque classe sans avoir à regarder le code : on sait ce qu elles contiennent et ce qui sera exploitable directement. Nous allons maintenant voir comment on peut dégager la structure globale du programme en représentant graphiquement les liens entre les différentes classes. 2 Représentation des relations entre les classes L objectif de cette partie est de dégager la structure du programme développé. Nous allons donc représenter sur un même dessein les quatre classes précédentes sous forme de classes non documentées, c est à dire de rectangles contenant le nom de la classe. 2.1 Mise en évidence de l héritage Quelles sont les classes qui héritent d une autre? Rajouter, si nécessaire, les super-classes sur le diagramme. On représentera les relations d héritage entre les classes en utilisant une ligne au bout de laquelle se trouve un triangle (voir figure 2). SuperClasse SousClasse FIGURE 2 Exemple de représentation d un héritage 2.2 Mise en évidence des autres relations La relation la plus simple Certaines classes utilisent d autres classes. Nous allons représenter ce lien sous la forme d une flèche partant de la classe qui utilise et pointant la classe utilisée. Au dessus de cette flèche figurera un verbe indiquant la nature de la relation (par exemple «utilise» ou «instancie», etc.) comme le montre la figure 3. Sous la flèche, près de chacune des classes impliquées dans la relation, se situent des cardinalités (appelées aussi multiplicités). La notation usuelle est sous la forme min..max. Si le maximum est inconnu, alors il sera noté *. Dans l exemple ci-dessous, une requête est associée à un et un seul serveur et le serveur acceptera aucune ou potentiellement plusieurs requêtes. Serveur accepte * Requete FIGURE 3 Exemple de représentation d une relation entre deux classes Représentez les liens entre classes que vous pourrez trouver sur votre ébauche de diagramme. 2

3 2.3 Les agrégations Une agrégation est une forme de relation particulière traduisant le fait que certaines classes sont constituées d objets appartenant à d autres classes. Sur votre diagramme précédemment tracé, vous allez promouvoir certaines de vos relations en agrégations. Pour le faire, vous pourrez supprimer le verbe de la relation et ajouter un losange vide au bout du trait reliant les deux classes associées (le losange est du côté du contenant et la pointe de la flèche disparaît) comme on peut le voir à la figure 4. Bibliotheque * Livre FIGURE 4 Exemple d agrégation 3 Conclusion Regarder le diagramme finalement obtenu. La structure du programme analysé vous semble t elle plus claire? Le procédé brièvement appliqué ici est souvent utilisé lorsque l on doit s approprier un code source que l on du mal à analyser car il permet de se faire rapidement une idée des relations entre les classes et d avoir une vision de la structure des classes sans regarder ce qui se passe en détail à l intérieur de ces dernières. A Code source du programme à analyser Classe ProducerConsumerTest p u b l i c c l a s s ProducerConsumerTest p u b l i c s t a t i c void main ( S t r i n g [ ] a r g s ) CubbyHole c = new CubbyHole ( ) ; P r o d u c e r p1 = new P r o d u c e r ( c ) ; Consumer c1 = new Consumer ( c ) ; System. o u t. p r i n t l n ( " Thread a c t i f \ t A c t i o n \ t O b j e t \ t C y c l e s d a t t e n t e " ) ; System. o u t. p r i n t l n ( " " ) ; p1. s t a r t ( ) ; c1. s t a r t ( ) ; 3

4 Classe Producer p u b l i c c l a s s P r o d u c e r extends Thread p r i v a t e CubbyHole cubbyhole ; p u b l i c P r o d u c e r ( CubbyHole c ) cubbyhole = c ; p u b l i c void run ( ) s e t P r i o r i t y ( Thread. MIN_PRIORITY ) ; Classe Consumer f o r ( i n t i = 0 ; i < 1 0 ; i ++) i n t t i m e s = 0 ; while (! cubbyhole. p u t ( i ) ) t i m e s ++; System. o u t. p r i n t l n ( " P r o d u c t e u r \ t a mis \ t " + i + " \ t " + t i m e s ) ; p u b l i c c l a s s Consumer extends Thread p r i v a t e CubbyHole cubbyhole ; p u b l i c Consumer ( CubbyHole c ) cubbyhole = c ; p u b l i c void run ( ) s e t P r i o r i t y ( Thread. MAX_PRIORITY ) ; i n t v a l u e = 0 ; f o r ( i n t i = 0 ; i < 1 0 ; i ++) i n t t i m e s = 1; do t r y v a l u e = cubbyhole. g e t ( ) ; catch ( MagicCubbyHoleException e ) System. o u t. p r i n t l n ( e. getmessage ( ) ) ; System. e x i t ( 1 ) ; t i m e s ++; while ( v a l u e == 1); System. o u t. p r i n t l n ( " Consommateur \ t p r e n d \ t " + v a l u e + " \ t " + t i m e s ) ; 4

5 Classe CubbyHole p u b l i c c l a s s CubbyHole p r i v a t e i n t c o n t e n t s = 1; p r i v a t e i n t o l d c o n t e n t s = 1; p r i v a t e boolean a v a i l a b l e = f a l s e ; p u b l i c synchronized i n t g e t ( ) throws MagicCubbyHoleException i f ( a v a i l a b l e == f a l s e ) t r y w a i t ( ) ; catch ( I n t e r r u p t e d E x c e p t i o n e ) return 1; a v a i l a b l e = f a l s e ; randomsleep ( ) ; i f ( c o n t e n t s o l d c o n t e n t s!= 1) throw new MagicCubbyHoleException ( " S e r a i t ce de l a magie? : l e consommateur prend " + c o n t e n t s ) ; o l d c o n t e n t s = c o n t e n t s ; n o t i f y ( ) ; return c o n t e n t s ; p u b l i c synchronized boolean p u t ( i n t v a l u e ) i f ( a v a i l a b l e == t rue ) t r y w a i t ( ) ; catch ( I n t e r r u p t e d E x c e p t i o n e ) return f a l s e ; a v a i l a b l e = t rue ; randomsleep ( ) ; c o n t e n t s = v a l u e ; n o t i f y ( ) ; return t rue ; p u b l i c s t a t i c void randomsleep ( ) t r y Thread. s l e e p ( ( i n t ) ( Math. random ( ) 1 0 ) ) ; catch ( I n t e r r u p t e d E x c e p t i o n e ) 5