CM uml-diag-statiques

2 470 vues

Publié le

Publié dans : Formation
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 470
Sur SlideShare
0
Issues des intégrations
0
Intégrations
982
Actions
Partages
0
Téléchargements
111
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

CM uml-diag-statiques

  1. 1. UML – UnifiedModelingLanguage2/4 : diagrammes statiques <br />Yannick Prié<br />Département Informatique – Faculté des Sciences et Technologies<br />Université Claude Bernard Lyon 1<br />2011-2012<br />
  2. 2. Objectifs de ce cours<br />Apprendre la syntaxe et la sémantique des diagrammes statiques les plus importants<br />Améliorer au passage la compréhension de différents principes objets<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  3. 3. Plan<br />Diagrammes de classes<br />Diagrammes d’objets<br />Diagrammes de paquetages<br />Diagrammes de composants<br />Diagrammes de déploiement<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  4. 4. Diagrammes de classes : présentation générale<br />Diagrammes fondamentaux <br />les plus connus, les plus utilisés<br />Présentent la vue statique du système <br />représentation de la structure et des déclarations comportementales<br />classes, relations, contraintes, commentaires…<br />Permettent de modéliser plusieurs niveaux<br />conceptuel (domaine, analyse)<br />implémentation (code)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  5. 5. Classes<br /><ul><li>Descripteurs de jeuxd’objets
  6. 6. structure / comportement / relations / sémantiquecommuns
  7. 7. Représentation
  8. 8. rectangle à trois compartiments
  9. 9. nom
  10. 10. attributs
  11. 11. opérations
  12. 12. plus ou moins de détails suivant les besoins
  13. 13. Nom : singulier, majuscule (en général)
  14. 14. ex. : Fichier, Client, Compte, Chat</li></ul>NomDeClasse<br />attribut 1<br />attribut 2<br />opération 1<br />opération 2<br />AutreClasse<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  15. 15. Relations entre classes/ liens entre objets<br />Association<br />les instances des classes sont liées<br />possibilité de communication entre objets<br />relation forte : composition<br />Généralisation/spécialisation<br />les instances de la sous-classe sont des instances de la super-classe (niveau conceptuel) <br />héritage (niveau implémentation)<br />Dépendance<br />la modification d’une classe peut avoir des conséquences sur une autre <br />Réalisation<br />une classe réalise une interface <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  16. 16. Un exemple<br />Elément <br />de réseau<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  17. 17. Utilisation des diagrammes de classes<br />Expression des besoins <br />modélisation du domaine<br />Conception<br />spécification : gros grain<br />Construction<br />implémentation : précis<br />rétro-ingénierie<br />Les diagrammes de classes permettent de représenter toute modélisation en classes, que ce soit des classes implémentées en machine ou non<br />On peut modéliser n’importe quel domaine avec des classes<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  18. 18. Petit exercice<br />Dessiner un diagramme de classe du domaine avec les classes suivantes<br />étudiant<br />enseignant<br />cours<br />salle de classe<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  19. 19. Attributs<br />Visibilité nom : type [multiplicité ] = valeur_initiale {propriétés}<br />Facultatif <br />public +<br />privé -<br />protégé #<br />paquetage~<br />Facultatif<br />ex. couleurs : Saturation [3]<br />points : Points [2..*]<br />Facultatif<br />mais impératif pour<br />l’implémentation<br />Facultatif<br />ex. <br />{frozen} mise à jour interdite<br />{obligatoire} valuation oblig.<br /><ul><li>Remarques
  20. 20. /nom : attribut dérivé (calculé)
  21. 21. souligné : attribut statique (de classe)
  22. 22. {frozen} : disparu de UML2 ; à utiliser quand-même</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  23. 23. Attributs : exemple<br />Vecteur<br />- x : réel<br />- y : réel<br />+ /longueur<br />- couleur [3] : réel<br />-créateur = "yp" {frozen}<br />Télévision<br /><ul><li> on/off : Bouton
  24. 24. couleur : enum {gris, noir}
  25. 25. marque : chaine
  26. 26. télétexte : booléen = vrai
  27. 27. chaines [5…*] : canal {ordered}
  28. 28. enceintes[2..6] : haut-parleur
  29. 29. type : typeTV {frozen}
  30. 30. volume : parallépipède = (600,650,500)</li></ul>valeur_x() : réel <br />valeur_y() : réel<br />longueur() : réel<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  31. 31. Opérations de classes<br />visibilité nom (liste de paramètres) : type-retour {propriétés}<br />argument ::= direction nom : type = valeur-défaut<br />public +<br />privé -<br />protégé #<br />paquetage~<br />asbtractquery…<br />in | out | inout<br />Remarques<br />notation : opération abstraite / opération statique<br />opérations = comportement d’une classe, trouvées en examinant les diagrammes d’interaction<br />méthode = implémentation d’une opération dont elle spécifie l’algorithme ou la procédure associée <br />pré et post-conditions, description du contenu : commentaires + OCL<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  32. 32. Opérations : exemple<br />« visuel »<br />Fenêtre<br />« precondition »<br /> p1 != p2<br />…<br />« constructor »<br />+Fenêtre(p1:Point, p2:Point)<br />…<br />+surface() : Réel {query}<br />…<br />« update »<br />#couleur(in newcolor : color = ‘J’)<br />…<br />« method » <br /> public int surface()<br />{ return …<br />}<br />Renvoie<br />| x2 –x1 | * | y2 – y1 | <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  33. 33. « Visuel »<br />Fenêtre<br />{ abstract,auteur = yp,<br />statut = testé }<br />+forme : zone = [100,100]<br />#visibilité : booléen = faux<br />+forme_défaut : rectangle<br />-xptr : Xwindow<br />« Visuel »  <br />Fenêtre<br />+afficher()<br />+masquer()<br />+créer<br />-attachXWindow(xwin : Xwindow)<br />forme : zone<br />visibilité : booléen<br />afficher()<br />masquer()<br />Autres exemples de classes <br />« enumeration »Couleur<br />rougeblanc<br />bleu<br />Contrôleur d’entrée<br />-- gère les événements en entrée<br />Responsabilités<br />s’afficherse masquer <br />Fenêtre<br />Responsabilités de la classe<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  34. 34. Associations<br />nom association <br />x..y<br />x..y<br />Classe 1<br />Classe 2<br />rôle 1<br />rôle 2<br />Nom : forme verbale, sens de lecture avec flèche<br />Rôles : forme nominale, identification extrémité association<br />Multiplicité : 1, 0..1, 0..*, 1..*, n..m<br />Mots-clés : set, ordered set (uniques) ; bag, list (doublons)<br /> actionnaire<br />*<br />*<br />1..*<br />*<br />Entreprise<br />Personne<br />employeur<br />employé<br /> travaille pour<br />Services<br />Industrielle<br />Les associations ont une durée de vie, sont indépendantes les unes des autres, sont héritées, comme les attributs<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  35. 35. Associations : exemple<br />Association réflexive<br /> travaille pour<br />Société<br />nom<br />Personne<br />nom<br />0..*<br />1..*<br />patron<br />0..1<br />employeur<br />employé {ordered, set}<br />dirige <br />*<br />emploie <br />employés<br />Représentation <br />d’une collection<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  36. 36. Associations : remarques<br /><ul><li>Tout objet doitêtre accessible via un lien
  37. 37. ne peutrecevoir de messages sinon
  38. 38. liens plus oumoins permanents : voir “Visibilités”
  39. 39. Multiplicité
  40. 40. nombred’instancesd’uneclasse en relation avec une instance d’uneautreclasse
  41. 41. pour chaque association
  42. 42. deuxdécisionsàprendre : deuxextrémités
  43. 43. Directionnalité
  44. 44. bidirectionnalité par défaut, evtexplicitée
  45. 45. restriction de la navigation àune direction</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />=<br />
  46. 46. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Personne<br />A pour titulaire<br />Compte<br />{XOR}<br />Entreprise<br />A pour titulaire<br />Associations et contraintes<br />visible sur <br />1<br />{ordered}<br />Fenêtre<br />Ecran<br />2..*<br />2..*<br />situé sur <br />association navigable<br />Point d’intersection<br />Segment<br />0..*<br />est de type <br />TypeVéhicule<br />Véhicule<br />{Véhicule.charge < Typevéhicule.chargeMax}<br />charge<br />chargeMax<br />1..*<br />Historique<br />Événement<br />{add only, ordered}<br />
  47. 47. Propriétés : caractéristiques structurelles des classes <br /><ul><li>Concept unique regroupant attributs et associations monodirectionnelles : équivalence des représentations
  48. 48. Pour choisir
  49. 49. attribut (texte) pour les types de données
  50. 50. objets dont l’identité n’est pas importante
  51. 51. association pour insister sur les classes</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Commande<br />+dateDeRéception: Date[0..1]<br />+estPrépayée: Booléen[1]<br />+lignes: LIgneDeCommande[*] {ordered}<br />(Fowler, 2004)<br />0..1<br />*<br />1<br />Commande<br />Booléen<br />Date<br />+estPrépayée<br />+dateDeRéception<br />1<br />lignes{ordered}<br />*<br />LigneDeCommande<br />
  52. 52. Agrégation et composition<br /><ul><li>Associations asymétriques, fortes
  53. 53. Agrégation
  54. 54. non nommée, structure d’arbre sous-jacente (pas de cycle), rôle prépondérant d’une extrémité
  55. 55. Composition
  56. 56. non partage des éléments composants, création et destruction des composants avec le composite </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Elément<br />Agrégat<br />1..*<br />0..*<br />Elément<br />Composite<br />0..*<br />1<br />
  57. 57. Composition, agrégation et association<br /><ul><li>Quelques questions à se poser
  58. 58. asymétrie et lien de subordination entre instances des deux classes (agrégation/composition) ouindépendance des objets (association) ?
  59. 59. propagation d’opérationsoud’attributs du tout vers les parties ? (agrégation/composition)
  60. 60. création et destruction des parties avec le tout ? (composition)
  61. 61. Remarquesimportantes
  62. 62. dans le doute, toujoursutiliserune association : c’est la moinscontrainte
  63. 63. pour certains experts, ilfautoublierl’agrégation
  64. 64. agrégation = “placebo denué de sens”</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  65. 65. Classes d’association<br /><ul><li>Pour ajouterattributs et opérationsà des associations
  66. 66. Quelques indices pour l’utilisation
  67. 67. un attribut est lié à une association
  68. 68. la durée de vie des instances de la CA dépend de l’association
  69. 69. association N..N entre deux classes + informations liées à l’association</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Réalise <br />*<br />Assiste <br />*<br />2..*<br />Personne<br />Réunion<br />Participation<br />attention<br />Participation<br />1<br />1<br />*<br />Personne<br />Réunion<br />attention<br />2..*<br />
  70. 70. Commande<br />LigneDeCommande<br />produit<br />1<br />Associations qualifiées<br />Equivalent UML des dictionnaires<br />Sélection d’un sous-ensemble des objets qui participent à l’association à l’aide d’une clé. <br />cet attribut est propriété de l’association<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Contient <br />Commande<br />LigneDeCommande<br />1<br />1..*<br />Contient <br />1<br />
  71. 71. <ul><li>Groupe de liens entre au moinstrois instances
  72. 72. Instance de l’association = n-uplet des attributs des instances impliquées</li></ul>Responsabilité<br />Exemple SSII<br />libellé<br />taux_horaire <br />forfait_prestation<br />(nb_heures)<br />Département<br />Employé<br />nom<br />budget <br />*<br />base calcul<br />nom<br />heures_travail <br />rattachement<br />source<br />dépenser()<br />encaisser()<br />Prestation<br />(nb_heures)<br />*<br />*<br />Associations n-aire<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  73. 73. Généralisation / spécialisation<br /><ul><li>Deux interprétations
  74. 74. niveau conceptuel
  75. 75. organisation : un concept est plus général qu’un autre
  76. 76. niveau implémentation
  77. 77. héritage des attributs et méthodes
  78. 78. Pour une bonne classification conceptuelle
  79. 79. principe de substitution / conformité à la définition
  80. 80. toutes les propriétés de la classe parent doiventêtrevalables pour les classes enfant
  81. 81. « A est une sorte de B » (mieux que « A est un B »)
  82. 82. toutes les instances de la sous-classe sont des instances de la super-classe (définition ensembliste)
  83. 83. Spécialisation
  84. 84. relation inverse de la généralisation</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />A<br />A<br />B<br />C<br />B<br />C<br />
  85. 85. Hiérarchie de classes<br />Facture <br />pour<br />date<br />adresse<br />montant_frcs<br />Livraison<br />1<br />1..n<br />Discriminant<br />Association commune montrée au niveau le plus haut<br />imprimer()<br />expédier()<br />{complete}<br />destination<br />Facture_export<br />Facture_France<br />devise_paiement<br />montant_devise<br />taux_TVA<br />montant_ttc<br />convertir(devise)<br />calcul_ttc()<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Autres contraintes {incomplete}, {disjoint}, {overlapping}<br />
  86. 86. Conseils pour la classification conceptuelle<br /><ul><li>Partitionner une classe en sous-classes
  87. 87. la sous-classe a des attributs et/ou des associations supplémentaires pertinents
  88. 88. par rapport à la superclasse ou à d’autres sous-classes, la sous-classe doit être gérée, manipulée, on doit agir sur elle ou elle doit réagir différemment, et cette distinction est pertinente
  89. 89. le concept de la sous-classe représente une entité animée (humain, animal, robot) qui a un comportement différent de celui de la superclasse, et cette distinction est pertinente
  90. 90. Définir une super-classe
  91. 91. les sous-classes sont conformes aux principes de substitution et « sorte-de »
  92. 92. toutes les sous-classes ont au moins un même attribut et/ou une même association qui peut être extrait et factorisé dans la superclasse</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />(Larman, 2005)<br />
  93. 93. <ul><li>Autorisée en UML
  94. 94. Attention aux conflits : ilfaut les résoudre
  95. 95. Possibilitéd’utiliseraussidélégationsou interfaces</li></ul>{overlapping}<br />{disjoint}<br />Généralisation multiple <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  96. 96. Interfaces et classes abstraites<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Un diagramme à comprendre !<br />
  97. 97. Interface et utilisation : notation<br />UML2<br />UML1<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  98. 98. Classes paramétrables (templates)<br />T, Nbl:Entier, Nbc:Entier<br />Remarque : les classes paramétrables sont disponibles en C++ depuis longtemps, en JAVA depuis 1.5<br />Tableau<br />-éléments: T[nbc, nbc] <br />+Elément(ligne,col) : T<br />+Elément(e : T; ligne, col : Entier)<br />« bind » <T_Case,Nbl_8,Nbc_8><br />Echiquier<br />Tableau<TRéel, Nbl3, Nbc3><br />Deux notations de la paramétrisation d'une classe paramétrable<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  99. 99. Classes structurées<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Commande<br /><ul><li>Description de la structure d’implémentation interne d’une classe
  100. 100. Contient
  101. 101. ports : points de connexion avec l’environnement(evt. interne)
  102. 102. parties : fragment structuré de la classe
  103. 103. connecteurs : connexions de deux parties au sein de la classe</li></ul>client:personne<br />ajoutBillet<br />priorité<br />0..1<br />priorité:NiveauEtat<br />élément:Billet[1..*]<br />
  104. 104. Classes actives<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Thread 1<br />: Calcul principal<br />Thread 2<br /><ul><li>Classedont les instances sont des objetsactifs
  105. 105. possèdentleurpropre thread
  106. 106. dans un environnementmultitâche</li></ul>: IHM<br />(UML1 : en gras)<br />
  107. 107. <ul><li>3 grands types
  108. 108. abstraction : différentsniveauxd’abstraction
  109. 109. ex. «refine»,«trace», «derive»
  110. 110. permission d’utilisation (cf. friend en C++)
  111. 111. ex. «permit»
  112. 112. utilisation
  113. 113. ex. «use»,«create», «call», «parameter»
  114. 114. Conseil
  115. 115. utiliser une dépendance pour tout ce qui n’est pas spécifié</li></ul>«refine»<br />Classe A<br />Classe A1<br />passage concept / implémentation<br />«permit»<br />Dictionnaire<br />Cellule<br />permission d’utilisation<br />«create»<br />Tableau<br />Case<br />utilisation<br />Relations de dépendance<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  116. 116. Liens, visibilité et dépendances<br />Lien => possibilité d’envoyer un message d’un objet à un autre<br />Deux types de liens<br />Lien durable : visibilité d’attribut ou globale<br />se matérialise par une association entre classes<br />Lien temporaire : visibilité paramètre ou locale<br />résulte d’une utilisation temporaire d’un objet par un autre<br />se matérialise par une dépendance entre classes<br />ex. passage de paramètre : « parameter », variable locale à une méthode : « local »<br />attention à ne pas oublier ces dépendances !<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />A<br />«parameter»<br />op1(c:C)<br />1: op2()<br />B<br />:A<br />:B<br />C<br />+op2()<br />
  117. 117. Plan<br />Diagrammes de classes<br />Diagrammes d’objets<br />Diagrammes de paquetages<br />Diagrammes de composants<br />Diagrammes de déploiement<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  118. 118. Diagrammes d’objets<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />patron<br />Denis:Personne<br /><ul><li>Pour représenter un instantané du système
  119. 119. les objets et leurs liens
  120. 120. objets = spécification d’instances
  121. 121. Quand les utiliser ?
  122. 122. pour montrer un contexte
  123. 123. collaborations sans messages
  124. 124. quand une structure complexe est trop difficile à comprendre avec un diagramme de classe
  125. 125. ex. : récursivité, associations multiples, etc.</li></ul>Etienne:Personne<br />Personne<br />employé<br />patron<br />Jean-Luc:Personne<br />patron<br />
  126. 126. Nom de l’objet souligné<br />Objets anonymes ou non<br />Objets classifiés ou non<br />Nom objet<br />Nom objet : classe<br />: classe<br />Rex<br />Rex : Chien<br />: Chien<br />Objets<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  127. 127. Objets dans une collection<br /><ul><li>Multi-objet (UML1)
  128. 128. modéliser un jeu
  129. 129. comme un objet unique avec des opérations sur le jeu
  130. 130. comme jeu d’objets individuels avec leurs opérations
  131. 131. Classe structurée (UML2)
  132. 132. Utiles pour les diagrammes de communication pour s’adresser
  133. 133. à l’objet qui représente la collection (Meute)
  134. 134. aux objets dans la collection (Chien)</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />: Chien<br />: Meute<br />4..*<br />:Meute<br />:Chien[4..*]<br />
  135. 135. Plan<br />Diagrammes de classes<br />Diagrammes d’objets<br />Diagrammes de paquetages<br />Diagrammes de composants<br />Diagrammes de déploiement<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  136. 136. Paquetage<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />util<br />util<br />util<br />Date<br />Contenu diagramme<br />Contenu listé<br /><ul><li>Mécanisme général pour
  137. 137. organiser les éléments et les diagrammes du modèle, notamment les classes
  138. 138. partitionner, hiérarchiser
  139. 139. clarifier
  140. 140. les nommer
  141. 141. un paquetage définit un espace de nom
  142. 142. deux éléments ne peuvent avoir le même nom dans un paquetage
  143. 143. Un paquetage
  144. 144. contient des éléments
  145. 145. y compris d’autres paquetages : hiérarchie
  146. 146. peut importer d’autres paquetages
  147. 147. peut posséder des interfaces</li></ul>Date<br />A<br />B<br />C<br />E<br />D<br />
  148. 148. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Diagramme de paquetage<br />Notation Rose<br />
  149. 149. Dépendances entre paquetages<br />Découlent des dépendances entre éléments des paquetages <br />notamment les classes<br />Les dépendances ne sont pas transitives <br />modifier Fournisseur n’oblige pas obligatoirement à modifier Clientèle<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  150. 150. Utilisation des diagrammes de paquetages<br /><ul><li>Organisation globale du modèle mis en place
  151. 151. hiérarchies de paquetages contenant diagrammes et éléments
  152. 152. Organisation des classes en paquetages pour
  153. 153. contrôler la structure du système
  154. 154. comprendre et partager
  155. 155. obtenir une application plus évolutive et facile à maintenir
  156. 156. ne pas se faire déborder par les modifications
  157. 157. viser la généricité et la réutilisabilité des paquetages
  158. 158. avoir une vue claire des flux de dépendances entre paquetages
  159. 159. il s’agit de les minimiser </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  160. 160. Paquetage et nommage<br /><ul><li>Noms pleinement qualifiés
  161. 161. équivalent à chemin absolu
  162. 162. ex. paquetage java::util, classe java::util::Date
  163. 163. Stéréotypes de dépendance
  164. 164. « import » : les éléments passent dans l’espace de nommage
  165. 165. ex. classe Date depuis le paquetage qui importe
  166. 166. « access » : sont accessibles
  167. 167. ex. classe java::util::Date depuis le paquetage qui importe</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  168. 168. Principes du découpage en paquetages<br /><ul><li>Cohérence interne du paquetage : relations étroites entre classes
  169. 169. fermeture commune
  170. 170. les classes changent pour des raisons similaires
  171. 171. réutilisation commune
  172. 172. les classes doivent être réutilisées ensemble
  173. 173. Indépendance par rapport aux autres paquetages
  174. 174. Un paquetage d’analyse contient généralement moins de 10 classes</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  175. 175. Bien gérer les dépendances<br />Les minimiser pour maintenir un couplage faible (voir patterns)<br />dépendances unidirectionnelles<br />cf. associations navigables<br />pas de cycles de dépendances<br />ou au moins pas de cycles inter-couches<br />stabilité des dépendances <br />plus il y a de dépendances entrantes, plus les interfaces de paquetage doivent être stables<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  176. 176. Paquetages : remarques variées<br /><ul><li>Les paquetages peuvent être considérés comme
  177. 177. soit simples regroupements
  178. 178. soit des véritables sous-systèmes opérationnels
  179. 179. comportement + interfaces
  180. 180. Paquetage vu de l’extérieur
  181. 181. classe publique gérant le comportement externe (cf. pattern Façade)
  182. 182. interfaces
  183. 183. Pour un Paquetages utilisé partout (très stable)
  184. 184. mot-clé « global »
  185. 185. Utilité pratique d’un paquetage Commun
  186. 186. regrouper les concepts largement partagés, ou épars
  187. 187. Lien entre paquetages et couches (niveaux)
  188. 188. une couche est composée de paquetages </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  189. 189. Plan<br />Diagrammes de classes<br />Diagrammes d’objets<br />Diagrammes de paquetages<br />Diagrammes de composants<br />Diagrammes de déploiement<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  190. 190. Composants<br /><ul><li>Partie modulaire de conception d’un système qui masque son implémentation derrière un jeu d’interfaces externes
  191. 191. partie remplaçable d’un système qui se conforme à des interfaces et fournit la réalisation de ces interfaces
  192. 192. doit être compris comme un élément qu'on peut acheter, associer à d'autres composants (cf. HiFi)
  193. 193. Division en composants = décision technique et commerciale (Fowler)
  194. 194. Représentation </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br /><<component>><br />Planificateur<br />Planificateur<br />
  195. 195. Diagrammes de composants<br /><ul><li>Objectif
  196. 196. représenter l’organisation et les dépendances entre les composants logiciels
  197. 197. décrire les composants et de leurs relations dans le système en construction
  198. 198. Diagramme de composants
  199. 199. inclusion des composants
  200. 200. relations de fourniture et d’utilisation d’interfaces</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  201. 201. Diagramme de composants<br />Caisse<br />Serveur ventes<br />Driver comptabilité<br />Processeur de transactions<br />File de messages<br />Structure composite, <br />Port<br />Système de comptabilité<br />(Fowler 04)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  202. 202. Remarque<br /><ul><li>UML1 : composant = n'importe quel élément, y compris fichiers, bibliothèque, etc.
  203. 203. UML2 : utiliser les artefacts (voir plus loin) pour représenter des structures physiques (jar, dll…) </li></ul> attention : vérifier quelle syntaxe est utilisée dans les diagrammes de composants que vous avez sous les yeux<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  204. 204. Plan<br />Diagrammes de classes<br />Diagrammes d’objets<br />Diagrammes de paquetages<br />Diagrammes de composants<br />Diagrammes de déploiement<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  205. 205. Diagramme de déploiement<br />Objectif<br />expliquer comment un système décrit statiquement dans un modèle sera concrètement déployé sur une architecture physique distribuée<br />Modéliser l’environnement d’exécution d’un projet<br />Pour cela<br />rendre compte de la disposition physique des différents éléments matériels qui entrent dans la composition d’un système<br />rendre compte de la disposition des programmes exécutables et des composants sur ces matériels<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  206. 206. <<device>><br />Serveur principal<br />{Memory=8goRaidLevel=5<br />Processor=2Ghz Xeon}<br />Représentation de l’environnement matériel de déploiement<br />Noeuds avec stéréotype « device »<br />description des caractéristiques attendues<br />processeur, mémoire, système d’exploitation, etc.<br />Relations<br />supports de communication entre nœuds physiques<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br /><<device>><br />PDA<br />{OS=Palm OS 4.0}<br /><<Bluetooth>><br /><<device>><br />Client<br />{Memory=1go<br />Processor=1Ghz Intel 915<br />DiskSpace=10 Go}<br /><<TCP-IP>><br />{sécurisé}<br />
  207. 207. Représentation du logiciel déployé<br />Artefact = élément d’information impliqué dans le système<br />Fichiers, logiciel, modèle<br />e.g. fichier de configuration, bibliothèque, exécutable, script, table de BD, etc.<br />un artefact est la manifestation (manifest) d’un élément du modèle <br />e.g. une classe (élément du modèle) a pour manifestations un fichier source .java, un fichier compilé .class et un fichier .html lié à la javadoc.<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br /><<artifact>><br /><<vendor>><br />Processeurde transactions<br />{VendorName=Toto<br />Version=2.1}<br /><<artifact>><br />CommandeAchat.jar<br />CommandeAchat.jar<br />
  208. 208. Diagramme de déploiement<br />Les artefacts sont déployés sur les nœuds de l’environnement matériel<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br /><<device>><br />MachineEnseignant<br />{JDK=1.6<br />pdfReader=pdf2.0}<br /><<artifact>><br />tp.jar<br /><<component>><br />MonTP<br /><<manifest>><br /><<artifact>><br />rapport.pdf<br />
  209. 209. Exemple de diagramme de composants<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />« station client »:PCStandard<br />« serveur »:DellPowerEdge 3600{OS=RedHat6}<br /><<device>><br /><<device>><br /><<device>><br />« station client »:PCStandard<br />i<br />t<br />r<br />l<br />i<br />t<br />l<br />t<br />r<br />i<br />{OS=Windows}<br />i<br />« browser »:webBrowser<br />JoveGL.exe<br />herculesClient.exe<br />{<br />v<br />e<br />n<br />d<br />o<br />r<br />=<br />r<br />o<br />m<br />a<br />n<br />S<br />o<br />f<br />t<br />}<br />{<br />c<br />o<br />m<br />p<br />o<br />n<br />e<br />n<br />t<br />=<br />G<br />e<br />n<br />e<br />r<br />a<br />l<br />L<br />e<br />d<br />g<br />e<br />r<br />}<br />.<br />HTTP/LAN<br />t<br />t<br />/<br />HTTP/internet<br />C<br />o<br />n<br />t<br />a<br />i<br />n<br />e<br />r<br />E<br />J<br />B<br />t<br />t<br />/<br />i<br />t<br />r<br />t<br />h<br />e<br />r<br />c<br />u<br />l<br />e<br />s<br />B<br />a<br />s<br />e<br />.<br />e<br />a<br />r<br /><<device>><br />« cluster web server »:Apache2.1<br />{OS=Solaris{nbCluster=3}<br />h<br />e<br />r<br />c<br />u<br />l<br />e<br />s<br />A<br />R<br />.<br />e<br />a<br />r<br />r<br />r<br />h<br />e<br />r<br />c<br />u<br />l<br />e<br />s<br />A<br />P<br />.<br />e<br />a<br />r<br />JAVA RMI/LAN<br />J<br />D<br />B<br />C<br />I<br />/<br /><<br /><<br />a<br />r<br />t<br />e<br />f<br />a<br />c<br />t<br />><br />><br />S<br />G<br />B<br />D<br />O<br />r<br />a<br />c<br />l<br />e<br />h<br />e<br />r<br />c<br />u<br />l<br />e<br />s<br />W<br />e<br />b<br />.<br />e<br />x<br />e<br />
  210. 210. Déploiement : raffinements<br />Les nœuds et les artefacts sont instanciables<br />possibilité de réfléchir à un déploiement abstrait (nœuds, artefacts) et à un déploiement concret (instances de nœuds, instances d’artefacts)<br />exemple <br />tel programme de telle version compiléeà telle date tourne tourne sur telle machine physique réelle<br />Possibilité de spécifier des caractéristiques du déploiement d’un artefact<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br /><<device>><br />:ServeurCommandes<br /><<artifact>><br />CommandeAchat.jar<br /><<deploymentSpec>><br />poDeploy.xml<br />execution=thread<br />transaction=true<br />priority=low<br />
  211. 211. A suivre<br />UML 3/4 : diagrammes dynamiques et d’interactions<br />UML 4/4 : concepts avancés<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />

×