GRASP
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) :
- “Information Expert” (en français, « expert en Information »)(plus d'information).
- “Creator” (en français, « Créateur »)(plus d'information).
- “Low Coupling” (en français, « faible couplage »)(plus d'information).
- “High Cohesion” (en français, « forte cohésion »)(plus d'information).
- “Controller” (en français, « contrôleur »)(plus d'information).
- “Polymorphism” (en français, « polymorphisme »)(plus d'information).
- “Indirection” (en français, « indirection »)(plus d'information).
- “Pure Fabrication” (en français, « fabrication pure »)(plus d'information).
- “Protected Variations” (en français, « variations protégées »)(plus d'information).
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.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.
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.
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.
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.
Version en cache
20/11/2024 19:43:13 Cette version de la page est en cache (à la date du 20/11/2024 19:43:13) afin d'accélérer le traitement. Vous pouvez activer le mode utilisateur dans le menu en haut pour afficher la dernère version de la page.Document créé le 22/05/2005, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/analyse-grasp.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
- ↑a,b,c,d,e,f General Responsibility Assignment Software Patterns : correspond à « Modèles généraux d'affectation des responsabilités » en français
- ↑a,b,c GRASP : “General Responsibility Assignment Software Patterns” (en français, « Modèles généraux d'affectation des responsabilités »)
- ↑ Singleton : correspond à « Instance unique » en français
- ↑ Information Expert : correspond à « expert en Information » en français
- ↑ Creator : correspond à « Créateur » en français
- ↑ High Cohesion : correspond à « forte cohésion » en français
- ↑ Controller : correspond à « contrôleur » en français
- ↑ Polymorphism : correspond à « polymorphisme » en français
- ↑ Indirection : correspond à « indirection » en français
- ↑ Pure Fabrication : correspond à « fabrication pure » en français
- ↑ Protected Variations : correspond à « variations protégées » en français
- ↑ use case : correspond à « cas d’utilisation » en français
Références
Software Engineeging : ECIS, Assigning Responsabilities
(2005)
Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.
