Principes généraux dans l’attribution des responsabilités

Les modèles sont les meilleurs principes pour l’attribution des responsabilités à des objets.

Les modèles sont des guides à la création de méthodes du logiciel. Ils sont des solutions aux problèmes communs qui surviennent souvent. Dans ce module, le modèle GRASP (General Responsability, Assignment Software Patterns) va être utilisé. Le modèle GRASP a le format suivant :

Nom du modèle : Le nom donné au modèle

Solution : La description de la solution du problème Problème : Description du problème que le modèle résout

Plus simplement, un motif est une paire problème/solution ayant un nom et qui peut être appliqué à de nouveau contexte, avec des conseils sur la façon de l’appliquer dans des situations nouvelles. Les modèles GRASP incluent les cinq modèles de base suivants : Expert,

Créateur,

Haute Cohésion, Faible Couplage et Contrôleur.

GRASP 1 : Expert

C’est un modèle très simple qui est utilisé plus que tout autre modèle dans l’attribution des responsabilités. La classe Expert est la classe qui possède les informations nécessaires pour

Exemple :

Figure 4.10 : Diagramme de collaboration pour obtenir le prix d’un produit Ceci peut être résumé comme suit :

Classe Responsabilité

Vente Connaît la vente totale

LignedeVente Connaît le Sous-total de chaque ligne d’article SpecificationProduit Connaît le prix des produits

GRASP 2: Créateur

La création des objets est l’une des activités les plus courantes dans un système orienté objet. Il pose la question “qui devrait être responsable de la création d’instances d’une classe particulière ?” Attribuer par exemple à la classe B la responsabilité de créer une instance de la classe A, si l’une des conditions est vraie :

B contient A B enregistre A

B regroupe (agrège) A B utilise étroitement A

B dispose des données d’initialisation de A

Par exemple, dans le système Terminal de point de vente à travers un terminal, qui devrait être responsable de la création d’une instance LignedeVente, partant du modèle Créateur, nous devrions rechercher une classe qui agrège, contient des instances LignedeVent. Comme Vente contient plusieurs objets LignedeVente, le motif Créateur suggère que Vente est le bon candidat pour avoir la responsabilité de la création des instances LignedeVente comme le montre la Figure 4.11. Cela signifie que la méthode “creerLigneProduit” sera définie dans la classe Vente.

Unité 4 : Conception Orientée Objet et Traduction Dans un Langage

Figure 4.11 : Diagramme de collaboration pour créer un LignedeVente GRASP 3 : Haute Cohésion

La cohésion ou la cohérence est la force des dépendances au sein d’un sous-système. La cohésion est une mesure de la façon dont les responsabilités d’une classe sont fortement liées et orientées. Il est le “ciment” interne avec laquelle un sous-système est construit. Un composant est cohésif si tous ses éléments sont orientés vers une tâche et les éléments sont essentiels pour effectuer la même tâche. Si un sous-système contient des objets non liés entre eux, la cohérence est faible. Une haute cohésion est souhaitable.

Une classe avec une haute cohésion a des responsabilités fonctionnelles fortement liées, et ne pas faire énormément de travail. Ces classes ont un petit nombre de méthodes avec de simples mais très connexes fonctionnalités. Dans une bonne conception orientée objet, chaque classe ne devrait pas faire trop de travail. Il faut juste attribuer quelques méthodes à une classe et déléguer une partie des travaux pour s’acquitter de la responsabilité à d’autres classes.

Les abstractions clés séparées à partir d’un contrôleur sont : Alarme

Ascenseur Portes Registres

GRASP 4 : Faible Couplage

Le couplage est une mesure de la manière dont une classe est fortement reliée à; a connaissance de, ou s’appuie sur d’autres classes. Une classe avec un bas (ou faible)

couplage n’est pas dépendante de nombreuses autres classes. Lorsque nous attribuons une responsabilité à une classe, nous aimerions affecter les responsabilités de manière à ce que le couplage entre les classes demeure faible.

Dans l’exemple ci-dessous pour le cas d’utilisation “effectuerPaiement” et avec la considération du couplage faible, la deuxième conception est préférable parce qu’elle n’a pas besoin d’un lien supplémentaire entre Terminal et Paiement. Cette attribution de la responsabilité est également justifiable parce qu’il est raisonnable de penser qu’une classe Vente utilise étroitement la classe Paiement.

Première conception :

Seconde conception

Figure 4.13 : Vente crée le paiement avec couplage faible GRASP 5 : Contrôleur

Qui gère un événement système? Attribuer la responsabilité pour la manipulation d’un message d’événement système à une classe qui représente l’une de ces options :

Représente l’ensemble du système, l’appareil ou d’un sous-système (contrôleur de façade).

Représente un scénario de cas d’utilisation à l’intérieur duquel le l’événement système se produit (Cas d’utilisation ou contrôleur de session)

Unité 4 : Conception Orientée Objet et Traduction Dans un Langage

Un contrôleur est une interface objet non-utilisateur qui est responsable de la gestion des événements d’entrée du système, et le contrôleur définit la méthode pour l’opération du système correspondant à l’événement d’entrée du système. Une solution possible est d’ajouter/introduire une nouvelle classe, et le faire siéger entre l’acteur et les classes métiers.

Le nom de ce contrôleur est généralement appelé <nom>Handler. Le gestionnaire (Handler) lit les commandes de l’utilisateur puis décide vers quelles classes les messages doivent être dirigés. Le gestionnaire est la seule classe qui serait autorisée à lire et afficher. Le système reçoit les événements externes d’entrée, impliquant habituellement une interface utilisateur graphique exploitée par une personne.

Le modèle Contrôleur prend la forme suivante : Tableau 4.3 : Modèle Contrôleur

Nom du Modèle Contrôleur

Solution Attribuer la responsabilité de la gestion de l’évènement (entrée) système à une classe qui représente l’un des choix suivants :

Représente le “système général” (contrôleur de façade).

Représente l’ensemble de l’entreprise ou organisation (contrôleur de façade).

Représente quelque chose dans le monde réel qui est actif (par exemple, le rôle d’une personne) qui pourrait être impliquée dans la tâche (contrôleur de rôle).

Représente un gestionnaire artificiel de tous les événements (entrée) du système d’un cas d’utilisation, généralement appelé “<UseCaseName>Handler”

(contrôleur de cas d’utilisation).

Problème Qui devrait être responsable de la gestion des événements d’entrée d’un système ?

Conclusion

Dans cette activité, vous avez appris comment utiliser le modèle GRASP pour attribuer des responsabilités à une classe en vous basant sur les principes généraux qu’il met à notre disposition. Les cinq principaux modèles de base GRASP ont été étudiés.

Evaluation

1. Expliquer clairement les aspects suivants du modèle objet : 2. Modèle Contrôleur

Activité 4.3 - La conception du système Terminal de point de vente