LU3IN012: Génie Logiciel

COURS 3: REVERSE ENGINEERING

Objectifs du cours

u Préciser les différences sémantiques entre modèle UML (partie diagramme de classes)
et code (Java)

u Présenter l’opération de Reverse Engineering et en identifier les gains et les limites

u Présenter la différence entre modèle UML et diagramme UML

 Différences sémantiques entre
Java et UML (1)

u UML est conçu pour faciliter la construction d’applications orientées objet

u Concepts des diagramme de classes = concepts orientés objet: classe, propriété, opération, …

u UML = Unified Modeling Language

u Créé pour unifier tous les langages de modélisation d’applications orientées objet

u UML a sa propre sémantique orientée objet

u UML et Java présentent des similitudes et des différences de sémantique

 Différences sémantiques entre
Java et UML (2)

Concepts UML inexistants dans les langages de programmation

u Association
u Pas d’association en Java, e.g. impossible de préciser que deux références appartenant à deux classes
correspondent à la même association et que l’une est l’opposée de l’autre.
u Import entre packages
u En Java: la notion de package n’existe qu’à travers la notion de classe
u En UML: la notion de package existe indépendamment de la notion de classe + import directement
entre les packages
u Direction des paramètres
u En UML: in, out, inout, return
u En Java: direction implicite, correspond uniquement aux directions in et return d’UML
 Différences sémantiques entre
Java et UML (3)

Concepts des langages de programmation inexistants en UML

u Corps des méthodes
u définit la logique de l’application. UML ne permet pas de définir le traitement associé aux opérations
u Sémantique d’appel d’opération
u En Java: sémantique d’appel synchrone + « asynchrone » avec thread
u En UML, aucune sémantique d’appel d’opération imposée
u API
u En Java: API riche
u En UML: aucune API
 Différences sémantiques entre
Java et UML (4)

Concepts communs à UML et aux langages de programmation qui n’ont pas le même sens
u Héritage
u En Java, uniquement de l’héritage simple
u En UML, héritage multiple autorisé
u Types de base
u Java : langage de programmation donc types de bases nombreux (byte, short, int, long, float, double,
boolean, char + autres types définis dans l’API+ types énumérés
u UML : langage de modélisation
u pas besoin d’un système de typage aussi fin que dans un langage de programmation
u peu de types de base: integer, string, boolean, char, real
 Le reverse engineering (1)

u Passage de code Java vers les diagrammes de classes

u Objectif: construire le modèle de la solution à partir de sa matérialisation

u Permet de construire automatiquement la partie du modèle de l’application relative à la vue

structurelle et ciblant le niveau d’abstraction le plus bas

u Intérêt: établir un lien entre le code et le modèle

u Le code est lié au modèle grâce à cette relation
u Les relations de cohérence avec les autres parties du modèle permettent de lier, par transitivité, le code
avec l’intégralité du modèle
Le reverse engineering (2)

Reverse Engineering
 Règles de correspondance du reverse
engineering de Java vers UML (1)

1. A toute classe Java doit correspondre une classe UML portant le même nom que la classe Java.

Etudiant
class Etudiant {
}
 Règles de correspondance du reverse
engineering de Java vers UML (2)

2. A toute interface Java doit correspondre une interface UML portant le même nom que
l’interface Java.

IEtudiant
interface IEtudiant {
}
 Règles de correspondance du reverse
engineering de Java vers UML (3)

3. A tout attribut d’une classe Java doit correspondre une propriété appartenant à la classe UML
correspondant à la classe Java. Le nom de la propriété doit être le même que le nom de l’attribut.
Le type de la propriété doit être une correspondance UML du type de l’attribut Java. Si l’attribut
est un tableau, la propriété peut avoir plusieurs valeurs (en fonction de la taille du tableau).

Etudiant
class Etudiant {
int numero; numéro: integer
nom: string
String nom;
Cours cours[]; cours: Cours[*]
}
 Règles de correspondance du reverse
engineering de Java vers UML (4)

4. A toute méthode d’une classe Java doit correspondre une opération UML appartenant à la
classe UML correspondant à la classe Java. Le nom de l’opération UML doit être le même que celui
de l’opération Java. Pour chaque paramètre de l’opération Java doit correspondre un paramètre
UML de même nom, dont la direction est in et dont le type est le type UML correspondant au type
du paramètre Java.

class Etudiant {
String getNom() { Etudiant
//CODE
}
void setNom(string nom) getNom():string
{ setNom(in nom: string)
//CODE
}
}
 Règles de correspondance du reverse
engineering de Java vers UML (5)

5. Si une classe Java appartient à un package Java, ce dernier doit correspondre à un package
UML correspondant au package Java qui doit contenir la classe UML correspondant à la classe
Java.

package universite; universite

class Etudiant { Etudiant

}
 Règles de correspondance du reverse
engineering de Java vers UML (6)

6. Si une classe Java importe un package Java, ce dernier doit correspondre à une relation
d’import entre le package UML de la classe UML correspondant à la classe Java et le package
UML correspondant au package Java importé.

import cas; universite cas

package universite; Etudiant

class Etudiant {
}
 Règles de correspondance du reverse
engineering de Java vers UML (7)

7. Si une classe Java hérite d’une autre classe Java, les classes UML correspondantes doivent avoir
elles aussi une relation d’héritage UML (appelée aussi généralisation).

Personne

class Etudiant extends Personne{}

Etudiant
 Règles de correspondance du reverse
engineering de Java vers UML (8)

8. Si une classe Java réalise une interface, la classe UML correspondante doit aussi réaliser
l’interface UML correspondante.

IEtudiant

class Etudiant implements IEtudiant{}

Etudiant
 Règles de correspondance du reverse
engineering de Java vers UML (9)

9. Si une méthode Java possède un code de traitement, alors une note UML contenant ce code
doit être attachée à l’opération UML correspondant à l’opération Java.

class Etudiant {
return this.nom;
String getNom() { Etudiant
return this.nom;
}
void setNom(String nom)
{ getNom():string
setNom(in nom: string)
this.nom = nom;
} this.nom = nom;
}
 Règles de correspondance du reverse
engineering de Java vers UML (10)

Nous pouvons considérer qu’il est possible de construire une association dans le modèle UML plutôt
qu’une propriété lorsqu’une classe Java référence une autre classe Java.

La règle n° 3 devient alors :

3. A tout attribut d’une classe Java, nous distinguons trois cas en fonction du type de cet attribut
u type primitif: à l’attribut doit correspondre une propriété appartenant à la classe UML correspondant à
la classe Java. Le nom de la propriété doit être le même que le nom de l’attribut. Le type de la
propriété doit être une correspondance UML du type de l’attribut Java
Etudiant
class Etudiant {
int numero; numéro: integer
nom: string
String nom;
}
 Règles de correspondance du reverse
engineering de Java vers UML (11)

u classe Java: à l’attribut doit correspondre à une association UML entre la classe UML correspondant à la
classe Java de l’attribut et la classe UML correspondant au type de l’attribut Java. Cette association
doit être navigable vers la classe UML correspondant au type de l’attribut Java. Le nom de rôle de la
classe correspondant au type de l’attribut doit être le même que le nom de l’attribut Java (multiplicité =
0..1. ou celle du tableau).

class Etudiant {
cours
Cours cours[]; Etudiant Cours
*
}
 Règles de correspondance du reverse
engineering de Java vers UML (12)

u collection générique (exemple ArrayList<B>): à l’attribut doit correspondre une association UML entre la
classe UML correspondant à la classe Java de l’attribut et la classe UML correspondant au type spécifié
dans la collection générique de l’attribut Java (i.e. B dans l’exemple). La multiplicité sera 0..*. Une note
UML est ajoutée à l’association pour préciser le nom exacte de la collection générique.

class Etudiant {
cours
ArrrayList<Cours> cours[]; Etudiant Cours
*
}

ArrayList
 Intérêts et limites du Reverse Engineering

u Construit la partie structurelle de plus bas niveau d’abstraction du modèle UML à partir de code
Java
u UML fait la distinction entre modèle UML et diagramme UML
u Un diagramme n’est qu’une représentation graphique d’une partie d’un modèle
u Il est possible de définir plusieurs diagrammes pour un même modèle
u Les diagrammes représentent graphiquement l’information contenue dans un modèle. Le
Reverse Engineering ne construit donc pas de diagramme de classes mais une partie du
modèle => plusieurs diagrammes de classes possibles.
u UML définit un type de diagramme particulier pour chacune des vues. Diagramme de classes
=> vue structurelle
 Diagrammes de classe à réaliser après
un reverse engineering
u Les diagrammes de classe « classiques »
u 1 représentant l’intégralité des informations
u 1 représentant uniquement l’ensemble des packages et leurs relations d’import sans montrer leur
contenu
u 1 par package montrant uniquement le contenu d’un package
u 1 permettant de montrer le contenu de la classe et les associations et les liens d’héritage vers les autres
classes
u Au final, le choix des diagrammes à réaliser dépend de l’application
u Il faut construire tous les diagrammes de classes permettant de bien comprendre l’application
 Gains offerts par le Reverse Engineering

u Première opération de modélisation qui permet d’obtenir un gain de productivité

u point d’entrée dans un modèle à partir du code

u Possibilité de générer une documentation de la structure de l’application à l’aide des

diagrammes de classes élaborés

u Possibilité d’élaborer les autres parties du modèle UML tout en gardant une
cohérence avec le code

u Principal atout du Reverse Engineering = lien entre une application existante et un

modèle
 Synthèse

Dans ce cours :
u Différences sémantiques entre UML et les LPOO => UML : sémantique OO qui lui est propre
u Détail des principes du Reverse Engineering => pont sémantique entre un langage de
programmation et UML.
u Indique UNE façon de passer du code Java vers les diagrammes de classes. (utilisée dans la suite de
ce cours).
u Modèle UML ≠ diagramme UML= représentation graphique de l’information contenue dans un
modèle.
u Reverse Engineering => ne génère AUCUN diagramme.

u Avantages offerts par le Reverse Engineering :

u Génération de la documentation technique structurelle d’une application existante
u Etablissement d’un lien entre le code d’une application et le modèle de l’application.