Geen cache-versie.

Caching uitgeschakeld. Standaardinstelling voor deze pagina:ingeschakeld (code LNG204)
Als het scherm te langzaam is, kunt u de gebruikersmodus uitschakelen om de cacheversie te bekijken.

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) :
  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).

Inhoudsopgave 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.

Inhoudsopgave 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.

Inhoudsopgave 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.

Inhoudsopgave 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.

Inhoudsopgave 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.

Inhoudsopgave Haut

Nederlandse vertaling

U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.

Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.

Bij voorbaat dank.

Document heeft de 22/05/2005 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/uml-grasp.html

De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.

Notes

  1. a,b,c,d,e,f General Responsibility Assignment Software Patterns : komt overeen met « 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 : komt overeen met « Modèles, patrons » en français

  4.  Singleton : komt overeen met « Instance unique » en français

  5.  Information Expert : komt overeen met « expert en Information » en français

  6.  Creator : komt overeen met « Créateur » en français

  7. a,b Low Coupling : komt overeen met « faible couplage » en français

  8.  High Cohesion : komt overeen met « forte cohésion » en français

  9.  Controller : komt overeen met « contrôleur » en français

  10.  Polymorphism : komt overeen met « polymorphisme » en français

  11.  Indirection : komt overeen met « indirection » en français

  12.  Pure Fabrication : komt overeen met « fabrication pure » en français

  13.  Protected Variations : komt overeen met « variations protégées » en français

  14.  use case : komt overeen met « cas d’utilisation » en français

Inhoudsopgave Haut

Referenties

  1. boek Taal van het document:uk Software Engineeging : ECIS, Assigning Responsabilities (2005)

Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.

Inhoudsopgave Haut