Le document traite de la réutilisation dans la conception informatique, mettant en avant des patrons de conception et des principes fondamentaux tels que la réutilisation de code et l'abstraction. Il présente les patrons GRASP pour l'attribution des responsabilités dans la conception orientée-objet, en soulignant l'importance du faible couplage et de la forte cohésion. Des exemples concrets illustrent comment appliquer ces principes dans le cadre de la programmation et de l'analyse des systèmes logiciels.

1. Réutilisation dans les SI : patrons de conceptionYannick PriéDépartement Informatique – Faculté de Sciences et TechnologiesUniversité Claude Bernard Lyon 12011-2012

2. Introduction : réutilisationConstante de la conception d’outils en général

3. nécessité pratique depuis qu’il y a des outils, et que ceux-ci évoluent

4. Exemples = comment concevoir

5. une chaise ?

6. un tournevis ?

7. un bateau ?

8. un parc ?2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 2

9. Réutilisation en informatiqueRéutilisation de tout ce qui a été mis en place depuis les débuts de l’informatique

10. codage, réseaux, normes, principes, etc.

11. Réutilisation de code

12. composants / librairies / services

13. à utiliser / acheter / fabriquer

14. frameworks

15. à utiliser en les spécialisant

16. Réutilisation de modèles de données

17. schémas

18. Réutilisation de principes de conception

19. IHM

20. Tendance générale informatique

21. dès que quelque chose se révèle pertinent

22. abstraction / réutilisation / normalisation2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 3

23. PlanIntroduction sur les patternsPatrons GRASP Design patterns2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 4

24. Généralités sur les patternsPatternsolution classique à un problème de conception classique dans un contexte donnéPattern de conceptionstructure et comportement d’une société de classesdescription nommée d’un problème et d’une solution avec conseils d’application 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 5

25. Description d’un patternNom du pattern : un ou deux motsPermet essentiellement d’en parler

26. N’est pas significatif en soi Problème : quand appliquer le pattern ?explication du problème et de son contexte

27. solution : description abstraite

28. Élément de conception, relation, responsabilités, collaborationExemple d’utilisation du patternDiscussion : conseils sur la façon de l’appliquer Avantages, inconvénients, conseils d’implémentation, variantes…2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 6

29. Refactoring / réingénierieDéfinitionréécriture de parties de code pour obtenir des services équivalents avec une conception meilleure Quand ?Il existe des indicateurs de problèmes (code smells)Une fois identifiés, on peut corriger le codeExemples (www.refactoring.com)You have a code fragment that can be grouped together.Turn the fragment into a method whose name explains the purpose of the method.You have a class that is in a package that contains other classes that it is not related to in function. Move the class to a more relevant package. Or create a new package if required for future use. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 7

30. PlanIntroduction sur les patternsPatrons GRASPDesign patterns2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 8

31. Conception objet :Réduction du décalage des représentationsDécalage des représentations entre

32. la façonhumaine, conceptuelle de penser le domaine

33. « un échiquier a des cases »

34. les objets logiciels correspondants

35. un objet Echiquier contient des objets Case

36. vs. un objet Echiquier contient 4 objets 16Cases

37. vs. un objet TYR43 contient des EE25

38. Ce décalage doit être réduit au maximum

39. Les concepts du domaine évoluent peu, les objets peuvent suivre l’évolution

40. adaptation, réutilisation2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 9

41. Conception objetpilotée par les responsabilitésMétaphore

42. communauté d’objets responsables qui collaborent (cf. humains) dans un projet (rôles)

43. Principe

44. penser l’organisation des composants (logiciels ou autres) en termes de responsabilités par rapport à des rôles, au sein de collaborations

45. Responsabilité

46. abstraction de comportement (contrat, obligation) par rapport à un rôle

47. une responsabilité n’est pas une méthode

48. les méthodes s’acquittent des responsabilités2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 10

49. Deux catégories de responsabilités pour les objetsSavoir

50. connaître les données privées encapsulées

51. connaître les objets connexes

52. connaître les attributs à calculer ou dériver

53. Faire

54. faire quelque chose soi-même (ex. créer un autre objet, effectuer un calcul)

55. déclencher une action d’un autre objet

56. contrôler et coordonner les activités d’autres objets2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 11

57. Exemple (agence de voyage)SavoirRéservation est responsable de la connaissance de son numéro et du voyageur associéVol est responsable de savoir s’il reste des placesFaireClient est responsable de la construction des réservations2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 12

58. Patterns GRASPGeneral ResponsabilityAssignment Software PatternsEnsemble de patterns généraux d’affectation de responsabilités pour aider à la conception orientée-objetraisonner objet de façon méthodique, rationnelle, explicableUtile pour l’analyse et la conceptionréalisation d’interactions avec des objetsRéférence : Larman 20042010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 13

59. 9 patterns GRASPExpert en informationCréateurFaible couplageForte cohésionContrôleurPolymorphismeFabrication pureIndirectionProtection des variations2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 4 grands principes de conception et d’évaluation : Expert, Créateur, Faible couplage, Forte cohésion2 outils : Fabrication pure et Indirection3 applications des précédents : Contrôleur, Polymorphisme, Protection des variations14

60. Expert (GRASP) ProblèmeQuel est le principe général d’affectation des responsabilités aux objets ? SolutionAffecter la responsabilité à l’expert en informationla classe qui possède les informations nécessaires pour s’acquitter de la responsabilité2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 15

61. Expert : exempleBibliothèque : qui doit avoir la responsabilité de connaître l’identifiant de l’abonné ? De connaître le titre d’un livre ? De connaître la disponibilité d’un exemplaire ?qui doit avoir la responsabilité de connaître le nombre d’exemplaires disponibles ? 0..*emprunte2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 16

62. Expert : exempleCommencer avec la questionDe quelle information a-t-on besoin pour déterminer le nombre d’exemplaires disponibles ?Disponibilité de toutes les instances d’exemplairesPuis Qui en est responsable ?Livre est l’Expert pour cette information2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 17

63. Expert : exemple0..*emprunte2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 18

64. Experts distribuésResponsabilité distribuée

65. Quand l’accomplissement d’une responsabilité nécessite de l’information répartie entre différents objets

66. La tâche globale est décomposée en sous-tâches locales

67. La responsabilité est assurée par la collaboration entre experts « locaux » avec

68. données propres

69. responsabilités correspondantes2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 19

70. Expert : exemple (suite) contient0..*concerne2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 20

71. Expert : exemple (suite) :Bibliothèque1: n=nbLivresEnRayon()1.1: n1=nbExemplaires():Exemplaire1.2: n2=nbExemplaires()1.1.1:d=getDispo()Livres[0]:Livre:Exemplaire1.1.2: d=getDispo()Livres[1]:Livre:Exemplaire1.2.1 d=getDispo()2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 21

72. Expert : discussionLié aux principes objet

73. Encapsulation

74. les objets utilisent leurs propres informations pour mener à bien leurs tâches

75. Collaboration

76. le comportement est distribué entre les classes ayant l’information nécessaire

77. Favorise

78. Couplage faible (GRASP)

79. Systèmes robustes et maintenables

80. Forte cohésion (GRASP)

81. classes légères, faciles à comprendre, à maintenir, à réutiliser2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 22

82. Expert : discussionLe plus utilisé de tous les patterns d’attribution de responsabilités

83. Autres noms (AKA - AlsoKnown As)

84. « Mettre les responsabilités avec les données »

85. « Qui sait, fait »

86. « Faire soi-même »

87. Patterns liés (voir plus loin)

88. Faible couplage

89. Forte cohésion2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 23

90. Créateur (GRASP) Problème

91. Qui doit avoir la responsabilité de créer une nouvelle instance d’une classe donnée ?

92. Solution

93. Affecter à la classe B la responsabilité de créer une instance de la classe A si une - ou plusieurs - de ces conditions est vraie :

94. B contient, agrège ou est composé d’objets A

95. B enregistre des objets A

96. B utilise étroitement des objets A

97. B a les données d’initialisation qui seront transmises aux objets A lors de leur création

98. ie. B est un Expert en ce qui concerne la création de A2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 24

99. Créateur : exempleBibliothèque : qui doit être responsable de la création de Pret? contient0..*concerneBasePret contient des Pret : elle doit les créer.2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 25

100. Créateur : discussionGuide pour attribuer une responsabilité pour la création d’objets

101. une tâche très commune en OO

102. Finalité : trouver un créateur pour qui il est nécessaire d’être connecté aux objets créés

103. favorise le Faible couplage

104. moins de dépendances de maintenance, plus d’opportunités de réutilisation

105. Pattern liés

106. Faible couplage

107. Composite

108. Fabricant2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 26

109. Faible couplage (GRASP)ProblèmeComment minimiser les dépendances ?Comment réduire l’impact des changements ?Comment améliorer la réutilisabilité ?SolutionAffecter les responsabilités des classes de sorte que le couplage reste faibleAppliquer ce principe lors de l’évaluation des solutions possibles2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 27

110. Couplage ? Définition

111. Mesure du degré auquel un élément est lié à un autre, en a connaissance ou en dépend

112. Exemples classiques de couplage de TypeX vers TypeYdans un langage OO

113. TypeX a un attribut qui réfère à TypeY

114. TypeX a une méthode qui référence TypeY

115. TypeX est une sous-classe directe ou indirecte de TypeY

116. TypeY est une interface et TypeXl’implémente

117. Les dépendances sont directement liées au couplage2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 28

118. Faible couplage (suite)Problèmes du couplage fort

119. Un changement dans une classe force à changer toutes ou la plupart des classes liées

120. Les classes prises isolément sont difficiles à comprendre

121. Réutilisation difficile : l’emploi d’une classe nécessite celui des classes dont elle dépend

122. Bénéfices du couplage faible

123. Exactement l’inverse

124. Une classe faiblement couplée a une faible dépendance aux autres classes2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 29

125. Faible couplage (suite)Principe général

126. les classes génériques et réutilisables par nature doivent avoir un faible couplage

127. Mise en œuvre

128. déterminer plusieurs possibilités pour l’affectation des responsabilités

129. comparer leurs degrés de couplage en termes de

130. nombre de relations entre les classes

131. nombre de paramètres circulant dans l’appel des méthodes

132. fréquence des messages

133. …2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 30