Architecture Logiciel

1. GRASP
General Responsibility Assignment
Software Principles
Mohamed El yaakoubi

2. Décrits dans le livre de Craig
Larman "Applying UML and
patterns, 3rd edition", les patterns
GRASP sont des généralisations des
patterns GoF, ainsi qu'une
conséquence directe des principes
de la POO.
Larman states that "the critical design tool for software
development is a mind well educated in design principles. It is
not UML or any other technology”

3. Introduction
Object design is sometimes described as some variation of the following:
After identifying your requirements and creating a domain model, then add
methods to the software classes, and define the messaging between the objects
to fulfill the requirements.
Such terse advice is not especially helpful, because there are deep principles and
issues involved in these steps. Deciding what methods belong where, and how
the objects should interact, is terribly important and anything but trivial. It
takes careful explanation, applicable while diagramming and programming.
And this is a critical step, this is at the heart of what it means to develop an
object-oriented system, not drawing domain model diagrams, package diagrams,
and so forth.
Craig Larman

4. Les responsabilités sont liées aux obligations d'un objet en termes de son comportement.
Fondamentalement, ces responsabilités sont des deux types suivants :
• Knowing (Savoir) Les responsabilités de type "Knowing" se réfèrent aux tâches qui
impliquent la connaissance ou l'accès à l'information.
• Doing (Faire) Les responsabilités de type "Doing" se réfèrent aux tâches qui impliquent
l'exécution d'actions ou de comportements.
Doing responsibilities d'un objet comprend :
Knowing responsibilities d'un objet comprend :
Les types de responsabilité
• faire quelque chose (un calcul, créer un autre objet),
• déclencher une action sur un autre objet,
• contrôler et coordonner les activités d'un autre objet
• connaître les valeurs de ses propres attributs (données privées encapsulées),
• connaitre les objets qui lui sont rattachés,
• connaître les éléments qu’il peut calculer ou dériver, cela peut être utilisé pour obtenir des
informations qui ne sont pas directement stockées mais peuvent être déduites à partir des
attributs de l'objet ou des données connexes.

5. Responsibilities are assigned to classes of objects during object
design. For example, I may declare that "a Sale is responsible for
creating SalesLineltems" (a doing), or "a Sale is responsible for
knowing its total" (a knowing). Relevant responsibilities related to
"knowing" are often inferable from the domain model, because of
the attributes and associations it illustrates.

6. • La responsabilité peut être :
o accompli par un seul objet.
o ou un groupe d'objets accomplissent de manière collaborative
• GRASP nous aide à décider quelle responsabilité doit être affecté à quel
objet/classe.
• Identifier les objets et les responsabilités du domaine métier, et identifier
également comment les objets interagissent les uns avec les autres.
Responsabilité:

7. Les principes GRASP décrivent des règles pour affecter les responsabilités aux
classes d'un programme orienté objet pendant la conception
Il y a 9 patterns GRASP :
• Expert en information
• Faible couplage
• Forte cohésion
• Créateur
• Fabrication pure
• Protection des variations
• Polymorphisme
• Contrôleur
• Indirection
Les principes GRASP

8. Expert ( en Information )
• L'objectif de ce pattern est d'affecter au mieux une responsabilité à une
classe. Afin de réaliser une responsabilité, une classe doit disposer de
l’information nécessaire.
Ainsi, le modèle Expert est un principe relativement intuitif, il s'agit tout
simplement d'affecter à une classe les responsabilités correspondants aux
informations dont elle dispose intrinsèquement (qu'elle possède) ou non
(collaborations d’objets).

9. Exemple
Dans cet exemple simpliste, nous nous situons dans une démarche de gestion de
commandes (au restaurant). Nous allons étudier une application de ce pattern
sur le modèle du domaine suivant :
Exemple de responsabilités dans ce modèle :
Calculer le total de la commande
Calculer le sous total d'une ligne
Connaître le prix d'un plat

10. • La question est de savoir quelles classes peuvent avoir la responsabilité de
donner le total d'une commande.
• Il semble logique que la classe Commande soit la meilleure candidate à
cette responsabilité.
• Il ne faut cependant pas oublier qu'une commande peut être composée de
plusieurs plats, dans des quantités éventuellement différentes.
• Une application de Expert consiste alors à affecter à la classe LignePlat la
responsabilité d'afficher le sous total d'une ligne.
Commande Calculer le total de la commande
LignePlat Calculer le sous total d'une ligne
DescriptionPlat Connaître le prix d'un plat

11. Faible couplage
• la faible dépendance entre les classes,
• la réduction de l'impact des changements dans une classe,
• la réutilisation des classes ou modules.
Couplage typique en OO entre A et B
• A a un attribut qui réfère à B
• A a une méthode qui fait référence à B
• A est une sous-classe directe ou indirecte de B
• A est une interface et B l’implémente
Pour affaiblir le couplage, il faut :
• Diminuer la quantité de paramètres passés entre les modules,
• Favoriser l’abstraction
Le couplage mesure la dépendance entre des classes ou des modules.
Le faible couplage favorise :

12. Exemple
Dans un logiciel de gestion de vente, nous avons les classes suivantes :
Facture
Contient un ensemble de produits facturés
associée à un mode de paiement,
Paiement
Décrit un mode de paiement (espèces, chèque, carte bancaire, à crédit, ...),
Client
Effectue les commandes.
On ajoute une méthode payer() à la classe Client. On étudie le couplage dans les deux cas
suivants :
La méthode payer() crée une instance de Paiement et l'assigne à l'objet Facture.
La méthode payer() délègue l'action à la classe Facture qui crée une instance de Paiement et
l'assigne.
Le couplage est plus faible dans le deuxième cas car la méthode payer() de la classe Client
n'a pas besoin de savoir qu'il existe une classe Paiement, c'est à dire qu'elle ne dépend pas
de l'existence ou non de cette classe.

13. :Client :Sale
:Payment
payer()
create()
addPayment()

14. :Client :Sale
p:Payment
payer()
payer()
create()

15. Ce principe stipule que dans notre système, nous devrions créer le moins de
connexions possible entre nos classes, modules, fichiers, etc.
Moins il y a de connexions, plus le système est stable.
Faible couplage

16. Créateur
Le pattern Créateur est lui aussi un modèle de conception relativement intuitif.
Il consiste en la détermination de la responsabilité de la création d'une
instance d'une classe par une autre.
• Une classe A agrégé 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, etc.
Exemple :
La création d'objets, est guidée par se pattern qui « guide » l'affectation des
responsabilités de création d'instance.

17. :create(quantité)
:Commande
:LignePlat
Dans le même exemple que le pattern Expert en Information, nous pouvons nous poser
la question : Qui à la responsabilité de créer une instance de la classe LignePlat ?
Selon les principes évoqués plus haut, la classe Commande paraît la meilleure candidate.
Le diagramme d'interaction (de séquence) suivant semble ainsi cohérent :
Exemple :

18. Cohésion forte
La cohésion forte, (similaire au SRP, principe de responsabilité unique,
de SOLID). stipule que si vous avez une classe (objet, fichier, etc...) tous
les champs et méthodes ne doivent faire qu'un seul travail bien défini.
Vérifions un exemple :
Nous avons une classe, qui peut envoyer des messages par email, SMS, Slack, etc…
class Sender {
constructor(txt) {}
sendEmail(options) {}
sendSMS(options) {}
sendToSlack(options) {}
}
Cette classe est responsable de l'envoi des messages. Mais, nous pouvons
voir que nous avons 3 canaux différents (par e-mail, SMS et slack),

19. Quel est le problème, vous pouvez demander si nous créons une seule
classe pour les 3 méthodes ?
Le premier problème pourrait être : pour chacun de ces canaux, nous pourrions avoir
une structure d'options différente, une analyse ou une préparation différente avant
l'envoi de méthodes
Le second, cela pourrait être, par exemple, nous avons un autre service/projet et
nous voulons aussi envoyer des SMS. Bien sûr, nous pouvons le créer à zéro, mais, si
nous avons déjà une méthode à cet effet, nous pouvons la réutiliser ?!
Et si on prend notre classe Sender, pour notre nouveau service/projet, que va-t-il se
passer ? Notre classe a 3 méthodes (mais pourrait en avoir 30 ou 50). Mais pour notre
nouveau projet, nous ne voulons qu'une seule méthode pour SMS. Pourquoi devrions-
nous avoir toutes les autres méthodes ?!

20. Protection des variations
Comment obtenir une telle protection ?
En organisant les responsabilités autour d'interfaces stables.
Assigner les responsabilités et concevoir le système de manière à ce que les
modifications de certains de ses éléments n'affectent pas les autres.
Comme solution, il est proposé d'identifier les points de changements ou
d'instabilité possibles et d'attribuer les responsabilités de manière à assurer le
fonctionnement stable du système.
C’est un modèle assez simple et c’est un principe unificateur de tous les
modèles GRASP précédents.

21. Polymorphisme
Le polymorphisme est utilisé lorsqu'il existe plusieurs façons d'accomplir une
tâche et que vous souhaitez découpler les clients de cette tâche des différents
morceaux de code qui implémentent les différentes façons de l'exécuter.
Le principe du polymorphisme est très proche du pattern stratégie de GoF

22. Indirection
Assignez la responsabilité d'indirection (ou de gestion de commandes) entre les objets
pour réduire le couplage. Au lieu de permettre à un objet d'interagir directement avec
un autre objet, introduisez un objet intermédiaire qui gère l'interaction entre les
objets.
Principe d'Indirection (Indirection Principle) :
L'indirection aide à maintenir une faible dépendance entre les objets, ce qui rend le
système plus flexible et évolutif. Elle permet également de réduire la complexité en
séparant les tâches de manière modulaire.

23. Indirection
Attribuer la responsabilité à un objet intermédiaire de servir de médiateur
entre les autres composants ou services afin qu'ils ne soient pas
directement couplés.
L'intermédiaire crée une indirection entre les autres composants.

24. Pure Fabrication
Attribuez un ensemble de responsabilités hautement cohérent à une classe
de « comportement » artificielle ou de commodité qui ne représente pas un
concept de domaine métier; quelque chose composé afin de soutenir une
cohésion élevée, un faible couplage et une réutilisation.
Par exemple, supposons qu’on doit enregistrer les instances de commande
dans une base de données.
En utilisant le principe d’Expert en information, On trouve certaine justification
à attribuer cette responsabilité à la classe Commande elle-même, car la
commande contient les données qui doivent être enregistré.

25. • La tâche nécessite un nombre relativement important de supports orientés base
de donnée, qui ne sont pas liée au concept de la commande, donc la classe
commande devient incohérent.
Mais considérez les implications suivantes :
• L'enregistrement dans une base de données relationnelle est une tâche très
générale pour laquelle de nombreuses classes sont concernées. Placer ces
responsabilités dans la classe Commande suggère qu'il va y avoir une mauvaise
réutilisation ou beaucoup de duplication dans d'autres classes qui font la même
chose.
• Une solution raisonnable consiste à créer
une nouvelle classe qui a la seule
responsabilité à l’épargne des objets
• La classe PersistentStorage est une pure fabrication,

26. Controller
Un Contrôleur est un composant dont la seule responsabilité est la communication
entre l’utilisateur UI et le système.
Le contrôleur est le premier composant non UI qui reçoit l'événement UI et
organise les opérations pour réagir à cet événement. En effet, cela ne correspond à
aucun objet de domaine, même si l'interface utilisateur elle-même peut afficher
des concepts de domaine.