GRASP

Contents

GRASP [“General Responsibility Assignment Software Patterns”1] est un ensemble de “patterns” (en français, « Modèles, patrons ») utilisés en orienté-objet qui nous aident pour l'assignation des responsabilités.

Dans le cadre des GRASP [“General Responsibility Assignment Software Patterns”1], les solutions proposées sont généralement intuitives, et tiennent plus du bon sens que d'une ligne de conduite forcée.

Rappel : Un “pattern” (en français, « Modèle, patron ») doit répondre à certains aspects essentiels :

  • Un “pattern”3 a un nom évocateur, qui représente bien l’essence même de son existence.
    Exemple : le “pattern”3 “Singleton” (en français, « Instance unique »).
  • Un “pattern”3 résout un problème.
    Exemple : une classe ne peut avoir qu’une et une seule instance.
  • Un “pattern”3 fourni une solution.
    Exemple : il faut créer une méthode statique de la classe qui retourne l’instance unique ou Singleton.


Les GRASP [“General Responsibility Assignment Software Patterns”1] sont répartis en 9 domaines (5 au départ, les 4 derniers ont été ajoutés par la suite) :
  1. “Information Expert” (en français, « expert en Information »)(plus d'information).
  2. “Creator” (en français, « Créateur »)(plus d'information).
  3. “Low Coupling” (en français, « faible couplage »)(plus d'information).
  4. “High Cohesion” (en français, « forte cohésion »)(plus d'information).
  5. “Controller” (en français, « contrôleur »)(plus d'information).
  6. “Polymorphism” (en français, « polymorphisme »)(plus d'information).
  7. “Indirection” (en français, « indirection »)(plus d'information).
  8. “Pure Fabrication” (en français, « fabrication pure »)(plus d'information).
  9. “Protected Variations” (en français, « variations protégées »)(plus d'information).

Contents Haut

GRASP Expert

Problème :

A qui pouvons nous attribuer une responsabilité ?

Si les responsabilités sont mal réparties, les classes logicielles vont être difficilement maintenables , plus dure à comprendre, et avec une réutilisation des composants peu flexible.

Solution :

Affecter à une classe les responsabilités correspondants aux informations dont elle dispose.

Contents Haut

GRASP Creator

Problème :

Qui peut avoir la responsabilité de créer une nouvelle instance de la classe ?

Solution :

Donner à la classe A la responsabilité de créer des instances de la classe B si :
  • Une classe A agrége des instances de la classe B
  • Une classe A contient des instances de la classe B
  • Une classe A utilise des instances d’une classe B
  • Une classe A possède les données nécessaires à l’initialisation des instance de classe B.

NB :

Une agrégation est une association entre un tout et ses parties.
Nous représenterons une agrégation par un trait terminé par un losange vide.

Une composition est une forme d’agrégation, mais pour laquelle la partie ne peut survivre sans son tout.
Nous représenterons une composition par un trait terminé par un losange plein.

Contents Haut

GRASP Low Coupling

Problème :

Comment réduire les dépendances et augmenter la réutilisation ?

Solution :

Le couplage exprime la relation étroite qu’un élément (Classe, Système ou sous système) entretien avec un ou des autres éléments. Un élément faiblement couplé ne possède pas ou peu de dépendances vis a vis d’autres éléments.
Nous veillerons donc à assigner une responsabilité en gardant un niveau de couplage (de dépendance) bas.

Nous sommes souvent en présence du “Low Coupling”7 dans les situations suivantes :
  • Une classe A détient un attribut de la classe B
  • Une classe A implémente une méthode qui fait référence à la classe B
  • Une classe A est une sous-classe de la classe B
  • Une classe A utilise l'interface B.

Contents Haut

GRASP High Cohesion

Problème :

Comment répartir les responsabilités et garder un niveau de complexité gérable ?

Solution :

La cohésion est le degré de spécialisation des responsabilités d’un composant, d'une classe. Nous devons veiller à augmenter la cohésion lors de l'assignation des responsabilités. Si une classe contient un nombre trop élevé de méthodes, nous devons vérifier si une collaboration avec d'autres objets ne nous permettrait pas d'avoir un petit nombre de méthodes qui ne doivent pas effectuer trop de tâches.
La multiplication des disciplines à responsabilité accroît exponentiellement le risque d’erreurs intrinsèques à cette classe.

Contents Haut

GRASP Controller

Problème :

Qui détient les responsabilités de la gestion des événements système ?

Solution :

Nous devons affecter à une classe la responsabilité d’un message système.

Une classe Contrôleur doit être crée si elle répond à l’un des cas suivants :
  • La classe représente une contrôleur de façade, c’est à dire l’interface d’accès à l’ensemble d’un système.
  • La classe représente le scénario issu d’un “use case” (en français, « cas d’utilisation »)(?), nommé en général "Session", et qui est chargé de traiter tous les événements systèmes contenus dans un scénario de cas d’utilisation.

Contents Haut

English translation

You have asked to visit this site in English. For now, only the interface is translated, but not all the content yet.

If you want to help me in translations, your contribution is welcome. All you need to do is register on the site, and send me a message asking me to add you to the group of translators, which will give you the opportunity to translate the pages you want. A link at the bottom of each translated page indicates that you are the translator, and has a link to your profile.

Thank you in advance.

Document created the 22/05/2005, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/analyse-grasp.html

The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.

Notes
  1. ↑a,b,c,d,e,f General Responsibility Assignment Software Patterns : corresponds to « Modèles généraux d'affectation des responsabilités » en français

  2. ↑a,b,c GRASP : “General Responsibility Assignment Software Patterns” (en français, « Modèles généraux d'affectation des responsabilités »)

  3. ↑a,b,c,d,e,f patterns : corresponds to « Modèles, patrons » en français

  4. ↑ Singleton : corresponds to « Instance unique » en français

  5. ↑ Information Expert : corresponds to « expert en Information » en français

  6. ↑ Creator : corresponds to « Créateur » en français

  7. ↑a,b Low Coupling : corresponds to « faible couplage » en français

  8. ↑ High Cohesion : corresponds to « forte cohésion » en français

  9. ↑ Controller : corresponds to « contrôleur » en français

  10. ↑ Polymorphism : corresponds to « polymorphisme » en français

  11. ↑ Indirection : corresponds to « indirection » en français

  12. ↑ Pure Fabrication : corresponds to « fabrication pure » en français

  13. ↑ Protected Variations : corresponds to « variations protégées » en français

  14. ↑ use case : corresponds to « cas d’utilisation » en français

Contents Haut

References

  1. book Language of the document:uk Software Engineeging : ECIS, Assigning Responsabilities (2005)

These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.

Contents Haut