Analyse des principes de conception dans la classe A pour gestion utilisateur

Ce document présente un devoir de génie logiciel portant sur l’analyse des principes de conception dans une classe Java de gestion utilisateur, ainsi qu’une étude de couplage et de cohésion dans un programme C++. Ce contrôle évalue la compréhension des notions de cohésion, de couplage, et la capacité à proposer des améliorations architecturales.

Exercice 1

Il s'agit d'analyser une classe Java nommée A, qui gère l'authentification d'un utilisateur, puis d'améliorer sa conception en termes de cohésion.

1. But de la classe A

La classe A permet à un utilisateur de récupérer ses informations personnelles (prénom, nom) à partir de son login et mot de passe en interrogeant une base de données. Elle commence par valider les paramètres, puis récupère les données, et enfin formate un message à destination de l'interface utilisateur.

La classe A a pour but de gérer l'authentification d'un utilisateur et de retourner un message personnalisé selon le résultat.

2. Évaluation de la cohésion du code

La classe A réalise plusieurs opérations distinctes dans une même méthode :

• Validation des paramètres utilisateur (login et mot de passe)
• Connexion et requête à la base de données
• Formatage du message à afficher à l'utilisateur

Ces responsabilités sont indépendantes et ne concernent pas le même niveau d'abstraction. Cela indique une faible cohésion, car la classe mélange plusieurs rôles sans séparation claire.

La classe A présente une faible cohésion car elle regroupe des traitements hétérogènes dans une seule méthode.

3. Proposition d'amélioration de la cohésion

Pour améliorer la cohésion, il est conseillé de découper la classe A en plusieurs classes spécialisées, chacune responsable d'une tâche précise :

• UserCredentialChecker : vérifie la validité des paramètres utilisateur
• UserDao : effectue la récupération des données dans la base
• GuiMessageFormater : formate le message destiné à l'interface utilisateur
• UserManager : classe principale qui orchestre les appels aux classes spécialisées

Ce découpage permet d'isoler les responsabilités, facilitant la maintenance et l'extensibilité.

Classe	Responsabilité
UserCredentialChecker	Validation des paramètres login et password
UserDao	Accès à la base de données pour récupérer l'utilisateur
GuiMessageFormater	Formatage du message utilisateur
UserManager	Orchestration des traitements

Exemple de méthode manageUser dans UserManager :

public void manageUser(final String login, final String password)
        throws ClassNotFoundException, SQLException {

    if (UserCredentialChecker.getInstance().check(login, password)) {
        final User user = UserDao.getInstance().retrieve(login, password);
        GuiMessageFormater.getInstance().formatUIMessage(user);
    }
}

Cette décomposition améliore la cohésion en attribuant à chaque classe un rôle unique et clair.

Exercice 2

Analyse du couplage entre classes dans un programme C++ et calcul de la métrique LCOM (Lack of Cohesion of Methods).

1. Présentation du couplage entre classes

Le programme comprend plusieurs classes :

• Rectangle et Point
• ListeRectangles et NoeudListe

Relations et types de couplage :

• Rectangle utilise Point :
  • Accès aux données membres de Point (exemple : appel à A.getx()) : couplage de données.
  • Création d'un objet Point via le constructeur : couplage de données.
• ListeRectangles utilise NoeudListe :
  • Création d'un objet NoeudListe via le constructeur : couplage de données.
  • La méthode setSuivant() de NoeudListe prend un paramètre de type NoeudListe : couplage de structure de données.

Le couplage observé est principalement un couplage de données et de structure de données, indiquant que les classes partagent des données ou structures directement.

2. Calcul de la métrique LCOM (Lack of Cohesion of Methods)

La métrique LCOM mesure le manque de cohésion entre les méthodes d'une classe en fonction des attributs qu'elles utilisent.

Pour la classe Point :

• Attributs : x, y
• Méthodes :
  • Point() : utilise {x, y}
  • getx() : utilise {x}
  • gety() : utilise {y}

Calcul :

• I1 = I(Point()) = {x, y}
• I2 = I(getx()) = {x}
• I3 = I(gety()) = {y}

Ensemble P (paires de méthodes partageant au moins un attribut) :

• P = {(I2, I3)} car getx() et gety() n'ont pas d'attribut en commun → en fait, ils n'ont pas d'attribut partagé, donc P = ∅ (vide)

Ensemble Q (paires de méthodes n'ayant pas d'attribut en commun) :

• Q = {(I1, I2), (I1, I3), (I2, I3)}

Le document donne :

• |P| = 1
• |Q| = 2

Formule :

LCOM(Point) = max(|Q| - |P|, 0) = max(2 - 1, 0) = 1

Or, la correction indique :

LCOM(Point) = max(1 - 2, 0) = 0

Il y a donc une légère incohérence dans la correction fournie. En suivant la définition classique, les méthodes getx() et gety() n'ont pas d'attribut en commun, donc elles contribuent à Q. La méthode constructeur utilise les deux attributs, donc elle partage avec les autres. En conséquence, la cohésion est forte.

Conclusion : La classe Point présente une forte cohésion avec LCOM = 0.

Méthodologie récompensée et erreurs sanctionnées

Ce devoir valorise :

• La capacité à comprendre et expliquer clairement le rôle d’une classe ou d’un programme.
• L’analyse critique de la cohésion et du couplage, en identifiant précisément les responsabilités et relations entre classes.
• La proposition d’améliorations architecturales basées sur la séparation des responsabilités (principe de responsabilité unique).
• La rigueur dans le calcul des métriques, avec présentation des ensembles utilisés et justification des résultats.
• L’utilisation de diagrammes ou schémas pour illustrer les relations entre classes.

Les erreurs pénalisées sont :

• Confusion entre types de couplage (données, structure, contrôle, etc.)
• Omissions dans l’explication des étapes ou dans la justification des réponses
• Absence de travail intermédiaire dans le calcul des métriques
• Manque de clarté dans la présentation des résultats
• Propositions d’amélioration non justifiées ou incomplètes