1. UML – UnifiedModelingLanguage2/4 : diagrammes statiques Yannick Prié Département Informatique – Faculté des Sciences et Technologies Université Claude Bernard Lyon 1 2011-2012

2. Objectifs de ce cours Apprendre la syntaxe et la sémantique des diagrammes statiques les plus importants Améliorer au passage la compréhension de différents principes objets 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

3. Plan Diagrammes de classes Diagrammes d’objets Diagrammes de paquetages Diagrammes de composants Diagrammes de déploiement 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

4. Diagrammes de classes : présentation générale Diagrammes fondamentaux les plus connus, les plus utilisés Présentent la vue statique du système représentation de la structure et des déclarations comportementales classes, relations, contraintes, commentaires… Permettent de modéliser plusieurs niveaux conceptuel (domaine, analyse) implémentation (code) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

6. structure / comportement / relations / sémantiquecommuns

7. Représentation

8. rectangle à trois compartiments

9. nom

10. attributs

11. opérations

12. plus ou moins de détails suivant les besoins

13. Nom : singulier, majuscule (en général)

14. ex. : Fichier, Client, Compte, ChatNomDeClasse attribut 1 attribut 2 opération 1 opération 2 AutreClasse 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

15. Relations entre classes/ liens entre objets Association les instances des classes sont liées possibilité de communication entre objets relation forte : composition Généralisation/spécialisation les instances de la sous-classe sont des instances de la super-classe (niveau conceptuel) héritage (niveau implémentation) Dépendance la modification d’une classe peut avoir des conséquences sur une autre Réalisation une classe réalise une interface 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

16. Un exemple Elément de réseau 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

17. Utilisation des diagrammes de classes Expression des besoins modélisation du domaine Conception spécification : gros grain Construction implémentation : précis rétro-ingénierie 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 On peut modéliser n’importe quel domaine avec des classes 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

18. Petit exercice Dessiner un diagramme de classe du domaine avec les classes suivantes étudiant enseignant cours salle de classe 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

20. /nom : attribut dérivé (calculé)

21. souligné : attribut statique (de classe)

22. {frozen} : disparu de UML2 ; à utiliser quand-même2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

24. couleur : enum {gris, noir}

25. marque : chaine

26. télétexte : booléen = vrai

27. chaines [5…*] : canal {ordered}

28. enceintes[2..6] : haut-parleur

29. type : typeTV {frozen}

30. volume : parallépipède = (600,650,500)valeur_x() : réel valeur_y() : réel longueur() : réel 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

31. Opérations de classes visibilité nom (liste de paramètres) : type-retour {propriétés} argument ::= direction nom : type = valeur-défaut public + privé - protégé # paquetage~ asbtractquery… in | out | inout Remarques notation : opération abstraite / opération statique opérations = comportement d’une classe, trouvées en examinant les diagrammes d’interaction méthode = implémentation d’une opération dont elle spécifie l’algorithme ou la procédure associée pré et post-conditions, description du contenu : commentaires + OCL 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

32. Opérations : exemple « visuel » Fenêtre « precondition » p1 != p2 … « constructor » +Fenêtre(p1:Point, p2:Point) … +surface() : Réel {query} … « update » #couleur(in newcolor : color = ‘J’) … « method » public int surface() { return … } Renvoie | x2 –x1 | * | y2 – y1 | 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

33. « Visuel » Fenêtre { abstract,auteur = yp, statut = testé } +forme : zone = [100,100] #visibilité : booléen = faux +forme_défaut : rectangle -xptr : Xwindow « Visuel » Fenêtre +afficher() +masquer() +créer -attachXWindow(xwin : Xwindow) forme : zone visibilité : booléen afficher() masquer() Autres exemples de classes « enumeration »Couleur rougeblanc bleu Contrôleur d’entrée -- gère les événements en entrée Responsabilités s’afficherse masquer Fenêtre Responsabilités de la classe 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

34. Associations nom association  x..y x..y Classe 1 Classe 2 rôle 1 rôle 2 Nom : forme verbale, sens de lecture avec flèche Rôles : forme nominale, identification extrémité association Multiplicité : 1, 0..1, 0..*, 1..*, n..m Mots-clés : set, ordered set (uniques) ; bag, list (doublons)  actionnaire * * 1..* * Entreprise Personne employeur employé  travaille pour Services Industrielle Les associations ont une durée de vie, sont indépendantes les unes des autres, sont héritées, comme les attributs 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

35. Associations : exemple Association réflexive  travaille pour Société nom Personne nom 0..* 1..* patron 0..1 employeur employé {ordered, set} dirige  * emploie  employés Représentation d’une collection 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

37. ne peutrecevoir de messages sinon

38. liens plus oumoins permanents : voir “Visibilités”

39. Multiplicité

40. nombred’instancesd’uneclasse en relation avec une instance d’uneautreclasse

41. pour chaque association

42. deuxdécisionsàprendre : deuxextrémités

43. Directionnalité

44. bidirectionnalité par défaut, evtexplicitée

45. restriction de la navigation àune direction2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 =

46. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Personne A pour titulaire Compte {XOR} Entreprise A pour titulaire Associations et contraintes visible sur  1 {ordered} Fenêtre Ecran 2..* 2..* situé sur  association navigable Point d’intersection Segment 0..* est de type  TypeVéhicule Véhicule {Véhicule.charge < Typevéhicule.chargeMax} charge chargeMax 1..* Historique Événement {add only, ordered}

48. Pour choisir

49. attribut (texte) pour les types de données

50. objets dont l’identité n’est pas importante

51. association pour insister sur les classes2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Commande +dateDeRéception: Date[0..1] +estPrépayée: Booléen[1] +lignes: LIgneDeCommande[*] {ordered} (Fowler, 2004) 0..1 * 1 Commande Booléen Date +estPrépayée +dateDeRéception 1 lignes{ordered} * LigneDeCommande

53. Agrégation

54. non nommée, structure d’arbre sous-jacente (pas de cycle), rôle prépondérant d’une extrémité

55. Composition

56. non partage des éléments composants, création et destruction des composants avec le composite 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Elément Agrégat 1..* 0..* Elément Composite 0..* 1

58. asymétrie et lien de subordination entre instances des deux classes (agrégation/composition) ouindépendance des objets (association) ?

59. propagation d’opérationsoud’attributs du tout vers les parties ? (agrégation/composition)

60. création et destruction des parties avec le tout ? (composition)

61. Remarquesimportantes

62. dans le doute, toujoursutiliserune association : c’est la moinscontrainte

63. pour certains experts, ilfautoublierl’agrégation

64. agrégation = “placebo denué de sens”2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

66. Quelques indices pour l’utilisation

67. un attribut est lié à une association

68. la durée de vie des instances de la CA dépend de l’association

69. association N..N entre deux classes + informations liées à l’association2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Réalise  * Assiste  * 2..* Personne Réunion Participation attention Participation 1 1 * Personne Réunion attention 2..*

70. Commande LigneDeCommande produit 1 Associations qualifiées Equivalent UML des dictionnaires Sélection d’un sous-ensemble des objets qui participent à l’association à l’aide d’une clé. cet attribut est propriété de l’association 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Contient  Commande LigneDeCommande 1 1..* Contient  1

72. Instance de l’association = n-uplet des attributs des instances impliquéesResponsabilité Exemple SSII libellé taux_horaire forfait_prestation (nb_heures) Département Employé nom budget * base calcul nom heures_travail rattachement source dépenser() encaisser() Prestation (nb_heures) * * Associations n-aire 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

74. niveau conceptuel

75. organisation : un concept est plus général qu’un autre

76. niveau implémentation

77. héritage des attributs et méthodes

78. Pour une bonne classification conceptuelle

79. principe de substitution / conformité à la définition

80. toutes les propriétés de la classe parent doiventêtrevalables pour les classes enfant

81. « A est une sorte de B » (mieux que « A est un B »)

82. toutes les instances de la sous-classe sont des instances de la super-classe (définition ensembliste)

83. Spécialisation

84. relation inverse de la généralisation2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 A A B C B C

85. Hiérarchie de classes Facture pour date adresse montant_frcs Livraison 1 1..n Discriminant Association commune montrée au niveau le plus haut imprimer() expédier() {complete} destination Facture_export Facture_France devise_paiement montant_devise taux_TVA montant_ttc convertir(devise) calcul_ttc() 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Autres contraintes {incomplete}, {disjoint}, {overlapping}

87. la sous-classe a des attributs et/ou des associations supplémentaires pertinents

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. 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. Définir une super-classe

91. les sous-classes sont conformes aux principes de substitution et « sorte-de »

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 superclasse2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 (Larman, 2005)

94. Attention aux conflits : ilfaut les résoudre

95. Possibilitéd’utiliseraussidélégationsou interfaces{overlapping} {disjoint} Généralisation multiple 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

96. Interfaces et classes abstraites 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Un diagramme à comprendre !

97. Interface et utilisation : notation UML2 UML1 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

98. Classes paramétrables (templates) T, Nbl:Entier, Nbc:Entier Remarque : les classes paramétrables sont disponibles en C++ depuis longtemps, en JAVA depuis 1.5 Tableau -éléments: T[nbc, nbc] +Elément(ligne,col) : T +Elément(e : T; ligne, col : Entier) « bind » <T_Case,Nbl_8,Nbc_8> Echiquier Tableau<TRéel, Nbl3, Nbc3> Deux notations de la paramétrisation d'une classe paramétrable 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

100. Contient

101. ports : points de connexion avec l’environnement(evt. interne)

102. parties : fragment structuré de la classe

103. connecteurs : connexions de deux parties au sein de la classeclient:personne ajoutBillet priorité 0..1 priorité:NiveauEtat élément:Billet[1..*]

105. possèdentleurpropre thread

106. dans un environnementmultitâche: IHM (UML1 : en gras)

108. abstraction : différentsniveauxd’abstraction

109. ex. «refine»,«trace», «derive»

110. permission d’utilisation (cf. friend en C++)

111. ex. «permit»

112. utilisation

113. ex. «use»,«create», «call», «parameter»

114. Conseil

115. utiliser une dépendance pour tout ce qui n’est pas spécifié«refine» Classe A Classe A1 passage concept / implémentation «permit» Dictionnaire Cellule permission d’utilisation «create» Tableau Case utilisation Relations de dépendance 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

116. Liens, visibilité et dépendances Lien => possibilité d’envoyer un message d’un objet à un autre Deux types de liens Lien durable : visibilité d’attribut ou globale se matérialise par une association entre classes Lien temporaire : visibilité paramètre ou locale résulte d’une utilisation temporaire d’un objet par un autre se matérialise par une dépendance entre classes ex. passage de paramètre : « parameter », variable locale à une méthode : « local » attention à ne pas oublier ces dépendances ! 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 A «parameter» op1(c:C) 1: op2() B :A :B C +op2()

117. Plan Diagrammes de classes Diagrammes d’objets Diagrammes de paquetages Diagrammes de composants Diagrammes de déploiement 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

119. les objets et leurs liens

120. objets = spécification d’instances

121. Quand les utiliser ?

122. pour montrer un contexte

123. collaborations sans messages

124. quand une structure complexe est trop difficile à comprendre avec un diagramme de classe

125. ex. : récursivité, associations multiples, etc.Etienne:Personne Personne employé patron Jean-Luc:Personne patron

126. Nom de l’objet souligné Objets anonymes ou non Objets classifiés ou non Nom objet Nom objet : classe : classe Rex Rex : Chien : Chien Objets 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

128. modéliser un jeu

129. comme un objet unique avec des opérations sur le jeu

130. comme jeu d’objets individuels avec leurs opérations

131. Classe structurée (UML2)

132. Utiles pour les diagrammes de communication pour s’adresser

133. à l’objet qui représente la collection (Meute)

134. aux objets dans la collection (Chien)2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 : Chien : Meute 4..* :Meute :Chien[4..*]

135. Plan Diagrammes de classes Diagrammes d’objets Diagrammes de paquetages Diagrammes de composants Diagrammes de déploiement 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

137. organiser les éléments et les diagrammes du modèle, notamment les classes

138. partitionner, hiérarchiser

139. clarifier

140. les nommer

141. un paquetage définit un espace de nom

142. deux éléments ne peuvent avoir le même nom dans un paquetage

143. Un paquetage

144. contient des éléments

145. y compris d’autres paquetages : hiérarchie

146. peut importer d’autres paquetages

147. peut posséder des interfacesDate A B C E D

148. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Diagramme de paquetage Notation Rose

149. Dépendances entre paquetages Découlent des dépendances entre éléments des paquetages notamment les classes Les dépendances ne sont pas transitives modifier Fournisseur n’oblige pas obligatoirement à modifier Clientèle 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

151. hiérarchies de paquetages contenant diagrammes et éléments

152. Organisation des classes en paquetages pour

153. contrôler la structure du système

154. comprendre et partager

155. obtenir une application plus évolutive et facile à maintenir

156. ne pas se faire déborder par les modifications

157. viser la généricité et la réutilisabilité des paquetages

158. avoir une vue claire des flux de dépendances entre paquetages

159. il s’agit de les minimiser 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

161. équivalent à chemin absolu

162. ex. paquetage java::util, classe java::util::Date

163. Stéréotypes de dépendance

164. « import » : les éléments passent dans l’espace de nommage

165. ex. classe Date depuis le paquetage qui importe

166. « access » : sont accessibles

167. ex. classe java::util::Date depuis le paquetage qui importe2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

169. fermeture commune

170. les classes changent pour des raisons similaires

171. réutilisation commune

172. les classes doivent être réutilisées ensemble

173. Indépendance par rapport aux autres paquetages

174. Un paquetage d’analyse contient généralement moins de 10 classes2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

175. Bien gérer les dépendances Les minimiser pour maintenir un couplage faible (voir patterns) dépendances unidirectionnelles cf. associations navigables pas de cycles de dépendances ou au moins pas de cycles inter-couches stabilité des dépendances plus il y a de dépendances entrantes, plus les interfaces de paquetage doivent être stables 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

177. soit simples regroupements

178. soit des véritables sous-systèmes opérationnels

179. comportement + interfaces

180. Paquetage vu de l’extérieur

181. classe publique gérant le comportement externe (cf. pattern Façade)

182. interfaces

183. Pour un Paquetages utilisé partout (très stable)

184. mot-clé « global »

185. Utilité pratique d’un paquetage Commun

186. regrouper les concepts largement partagés, ou épars

187. Lien entre paquetages et couches (niveaux)

188. une couche est composée de paquetages 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

189. Plan Diagrammes de classes Diagrammes d’objets Diagrammes de paquetages Diagrammes de composants Diagrammes de déploiement 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

191. partie remplaçable d’un système qui se conforme à des interfaces et fournit la réalisation de ces interfaces

192. doit être compris comme un élément qu'on peut acheter, associer à d'autres composants (cf. HiFi)

193. Division en composants = décision technique et commerciale (Fowler)

194. Représentation 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <<component>> Planificateur Planificateur

196. représenter l’organisation et les dépendances entre les composants logiciels

197. décrire les composants et de leurs relations dans le système en construction

198. Diagramme de composants

199. inclusion des composants

200. relations de fourniture et d’utilisation d’interfaces2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

201. Diagramme de composants Caisse Serveur ventes Driver comptabilité Processeur de transactions File de messages Structure composite, Port Système de comptabilité (Fowler 04) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

203. UML2 : utiliser les artefacts (voir plus loin) pour représenter des structures physiques (jar, dll…)  attention : vérifier quelle syntaxe est utilisée dans les diagrammes de composants que vous avez sous les yeux 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

204. Plan Diagrammes de classes Diagrammes d’objets Diagrammes de paquetages Diagrammes de composants Diagrammes de déploiement 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

205. Diagramme de déploiement Objectif expliquer comment un système décrit statiquement dans un modèle sera concrètement déployé sur une architecture physique distribuée Modéliser l’environnement d’exécution d’un projet Pour cela rendre compte de la disposition physique des différents éléments matériels qui entrent dans la composition d’un système rendre compte de la disposition des programmes exécutables et des composants sur ces matériels 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

206. <<device>> Serveur principal {Memory=8goRaidLevel=5 Processor=2Ghz Xeon} Représentation de l’environnement matériel de déploiement Noeuds avec stéréotype « device » description des caractéristiques attendues processeur, mémoire, système d’exploitation, etc. Relations supports de communication entre nœuds physiques 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <<device>> PDA {OS=Palm OS 4.0} <<Bluetooth>> <<device>> Client {Memory=1go Processor=1Ghz Intel 915 DiskSpace=10 Go} <<TCP-IP>> {sécurisé}

207. Représentation du logiciel déployé Artefact = élément d’information impliqué dans le système Fichiers, logiciel, modèle e.g. fichier de configuration, bibliothèque, exécutable, script, table de BD, etc. un artefact est la manifestation (manifest) d’un élément du modèle 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. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <<artifact>> <<vendor>> Processeurde transactions {VendorName=Toto Version=2.1} <<artifact>> CommandeAchat.jar CommandeAchat.jar

208. Diagramme de déploiement Les artefacts sont déployés sur les nœuds de l’environnement matériel 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <<device>> MachineEnseignant {JDK=1.6 pdfReader=pdf2.0} <<artifact>> tp.jar <<component>> MonTP <<manifest>> <<artifact>> rapport.pdf

209. Exemple de diagramme de composants 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 « station client »:PCStandard « serveur »:DellPowerEdge 3600{OS=RedHat6} <<device>> <<device>> <<device>> « station client »:PCStandard i t r l i t l t r i {OS=Windows} i « browser »:webBrowser JoveGL.exe herculesClient.exe { v e n d o r = r o m a n S o f t } { c o m p o n e n t = G e n e r a l L e d g e r } . HTTP/LAN t t / HTTP/internet C o n t a i n e r E J B t t / i t r t h e r c u l e s B a s e . e a r <<device>> « cluster web server »:Apache2.1 {OS=Solaris{nbCluster=3} h e r c u l e s A R . e a r r r h e r c u l e s A P . e a r JAVA RMI/LAN J D B C I / < < a r t e f a c t > > S G B D O r a c l e h e r c u l e s W e b . e x e

210. Déploiement : raffinements Les nœuds et les artefacts sont instanciables possibilité de réfléchir à un déploiement abstrait (nœuds, artefacts) et à un déploiement concret (instances de nœuds, instances d’artefacts) exemple tel programme de telle version compiléeà telle date tourne tourne sur telle machine physique réelle Possibilité de spécifier des caractéristiques du déploiement d’un artefact 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <<device>> :ServeurCommandes <<artifact>> CommandeAchat.jar <<deploymentSpec>> poDeploy.xml execution=thread transaction=true priority=low

211. A suivre UML 3/4 : diagrammes dynamiques et d’interactions UML 4/4 : concepts avancés 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1