Le document présente un cours sur le langage de modélisation unifié (UML), en se concentrant principalement sur les diagrammes de classes et leur utilisation pour modéliser des systèmes. Il aborde la syntaxe et la sémantique des diagrammes de classes, les relations entre classes, ainsi que les concepts d'agrégation, de composition et d'héritage. Des exemples pratiques et des exercices sont également fournis pour illustrer les concepts abordés.

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

2. Objectifs de ce coursApprendre la syntaxe et la sémantique des diagrammes statiques les plus importantsAméliorer au passage la compréhension de différents principes objets2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

3. PlanDiagrammes de classesDiagrammes d’objetsDiagrammes de paquetagesDiagrammes de composantsDiagrammes de déploiement2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

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

5. ClassesDescripteurs de jeuxd’objets

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, ChatNomDeClasseattribut 1attribut 2opération 1opération 2AutreClasse2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

15. Relations entre classes/ liens entre objetsAssociationles instances des classes sont liéespossibilité de communication entre objetsrelation forte : compositionGénéralisation/spécialisationles instances de la sous-classe sont des instances de la super-classe (niveau conceptuel) héritage (niveau implémentation)Dépendancela modification d’une classe peut avoir des conséquences sur une autre Réalisationune classe réalise une interface 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

16. Un exempleElément de réseau2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

17. Utilisation des diagrammes de classesExpression des besoins modélisation du domaineConceptionspécification : gros grainConstructionimplémentation : précisrétro-ingénierieLes diagrammes de classes permettent de représenter toute modélisation en classes, que ce soit des classes implémentées en machine ou nonOn peut modéliser n’importe quel domaine avec des classes2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

18. Petit exerciceDessiner un diagramme de classe du domaine avec les classes suivantesétudiantenseignantcourssalle de classe2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

19. AttributsVisibilité nom : type [multiplicité ] = valeur_initiale {propriétés}Facultatif public +privé -protégé #paquetage~Facultatifex. couleurs : Saturation [3]points : Points [2..*]Facultatifmais impératif pourl’implémentationFacultatifex. {frozen} mise à jour interdite{obligatoire} valuation oblig.Remarques

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

23. Attributs : exempleVecteur- x : réel- y : réel+ /longueur- couleur [3] : réel-créateur = "yp" {frozen}Télévision on/off : Bouton

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éellongueur() : réel2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

31. Opérations de classesvisibilité nom (liste de paramètres) : type-retour {propriétés}argument ::= direction nom : type = valeur-défautpublic +privé -protégé #paquetage~asbtractquery…in | out | inoutRemarquesnotation : opération abstraite / opération statiqueopérations = comportement d’une classe, trouvées en examinant les diagrammes d’interactionmé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 + OCL2010-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 : zonevisibilité : booléenafficher()masquer()Autres exemples de classes « enumeration »CouleurrougeblancbleuContrôleur d’entrée-- gère les événements en entréeResponsabilitéss’afficherse masquer FenêtreResponsabilités de la classe2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

34. Associationsnom association x..yx..yClasse 1Classe 2rôle 1rôle 2Nom : forme verbale, sens de lecture avec flècheRôles : forme nominale, identification extrémité associationMultiplicité : 1, 0..1, 0..*, 1..*, n..mMots-clés : set, ordered set (uniques) ; bag, list (doublons) actionnaire**1..**EntreprisePersonneemployeuremployé travaille pourServicesIndustrielleLes associations ont une durée de vie, sont indépendantes les unes des autres, sont héritées, comme les attributs2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

35. Associations : exempleAssociation réflexive travaille pourSociéténomPersonnenom0..*1..*patron0..1employeuremployé {ordered, set}dirige *emploie employésReprésentation d’une collection2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

36. Associations : remarquesTout objet doitêtre accessible via un lien

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 PersonneA pour titulaireCompte{XOR}EntrepriseA pour titulaireAssociations et contraintesvisible sur 1{ordered}FenêtreEcran2..*2..*situé sur association navigablePoint d’intersectionSegment0..*est de type TypeVéhiculeVéhicule{Véhicule.charge < Typevéhicule.chargeMax}chargechargeMax1..*HistoriqueÉvénement{add only, ordered}

47. Propriétés : caractéristiques structurelles des classes Concept unique regroupant attributs et associations monodirectionnelles : équivalence des représentations

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*1CommandeBooléenDate+estPrépayée+dateDeRéception1lignes{ordered}*LigneDeCommande

52. Agrégation et compositionAssociations asymétriques, fortes

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émentAgrégat1..*0..*ElémentComposite0..*1

57. Composition, agrégation et associationQuelques questions à se poser

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

65. Classes d’associationPour ajouterattributs et opérationsà des associations

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..*PersonneRéunionParticipationattentionParticipation11*PersonneRéunionattention2..*

70. CommandeLigneDeCommandeproduit1Associations qualifiéesEquivalent UML des dictionnairesSélection d’un sous-ensemble des objets qui participent à l’association à l’aide d’une clé. cet attribut est propriété de l’association2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Contient CommandeLigneDeCommande11..*Contient 1

71. Groupe de liens entre au moinstrois instances

72. Instance de l’association = n-uplet des attributs des instances impliquéesResponsabilitéExemple SSIIlibellétaux_horaire forfait_prestation(nb_heures)DépartementEmployénombudget *base calculnomheures_travail rattachementsourcedépenser()encaisser()Prestation(nb_heures)**Associations n-aire2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

73. Généralisation / spécialisationDeux interprétations

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 AABCBC

85. Hiérarchie de classesFacture pourdateadressemontant_frcsLivraison11..nDiscriminantAssociation commune montrée au niveau le plus hautimprimer()expédier(){complete}destinationFacture_exportFacture_Francedevise_paiementmontant_devisetaux_TVAmontant_ttcconvertir(devise)calcul_ttc()2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Autres contraintes {incomplete}, {disjoint}, {overlapping}

86. Conseils pour la classification conceptuellePartitionner une classe en sous-classes

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)

93. Autorisée en UML

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 abstraites2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Un diagramme à comprendre !

97. Interface et utilisation : notationUML2UML12010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

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

99. Classes structurées2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 CommandeDescription de la structure d’implémentation interne d’une classe

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:personneajoutBilletpriorité0..1priorité:NiveauEtatélément:Billet[1..*]

104. Classes actives2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Thread 1: Calcul principalThread 2Classedont les instances sont des objetsactifs

105. possèdentleurpropre thread

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

107. 3 grands types

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 AClasse A1passage concept / implémentation«permit»DictionnaireCellulepermission d’utilisation«create»TableauCaseutilisationRelations de dépendance2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

116. Liens, visibilité et dépendancesLien => possibilité d’envoyer un message d’un objet à un autreDeux types de liensLien durable : visibilité d’attribut ou globalese matérialise par une association entre classesLien temporaire : visibilité paramètre ou localerésulte d’une utilisation temporaire d’un objet par un autrese matérialise par une dépendance entre classesex. 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:BC+op2()

117. PlanDiagrammes de classesDiagrammes d’objetsDiagrammes de paquetagesDiagrammes de composantsDiagrammes de déploiement2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

118. Diagrammes d’objets2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 patronDenis:PersonnePour représenter un instantané du système

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:PersonnePersonneemployépatronJean-Luc:Personnepatron

126. Nom de l’objet soulignéObjets anonymes ou nonObjets classifiés ou nonNom objetNom objet : classe: classeRexRex : Chien: ChienObjets2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

127. Objets dans une collectionMulti-objet (UML1)

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: Meute4..*:Meute:Chien[4..*]

135. PlanDiagrammes de classesDiagrammes d’objetsDiagrammes de paquetagesDiagrammes de composantsDiagrammes de déploiement2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

136. Paquetage2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 utilutilutilDateContenu diagrammeContenu listéMécanisme général pour

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 interfacesDateABCED

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

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

150. Utilisation des diagrammes de paquetagesOrganisation globale du modèle mis en place

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

160. Paquetage et nommageNoms pleinement qualifiés

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

168. Principes du découpage en paquetagesCohérence interne du paquetage : relations étroites entre classes

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épendancesLes minimiser pour maintenir un couplage faible (voir patterns)dépendances unidirectionnellescf. associations navigablespas de cycles de dépendancesou au moins pas de cycles inter-couchesstabilité des dépendances plus il y a de dépendances entrantes, plus les interfaces de paquetage doivent être stables2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

176. Paquetages : remarques variéesLes paquetages peuvent être considérés comme

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. PlanDiagrammes de classesDiagrammes d’objetsDiagrammes de paquetagesDiagrammes de composantsDiagrammes de déploiement2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

190. ComposantsPartie modulaire de conception d’un système qui masque son implémentation derrière un jeu d’interfaces externes

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>>PlanificateurPlanificateur

195. Diagrammes de composantsObjectif

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 composantsCaisseServeur ventesDriver comptabilitéProcesseur de transactionsFile de messagesStructure composite, PortSystème de comptabilité(Fowler 04)2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

202. RemarqueUML1 : composant = n'importe quel élément, y compris fichiers, bibliothèque, etc.

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 yeux2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

204. PlanDiagrammes de classesDiagrammes d’objetsDiagrammes de paquetagesDiagrammes de composantsDiagrammes de déploiement2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

205. Diagramme de déploiementObjectifexpliquer comment un système décrit statiquement dans un modèle sera concrètement déployé sur une architecture physique distribuéeModéliser l’environnement d’exécution d’un projetPour celarendre compte de la disposition physique des différents éléments matériels qui entrent dans la composition d’un systèmerendre compte de la disposition des programmes exécutables et des composants sur ces matériels2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

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

207. Représentation du logiciel déployéArtefact = élément d’information impliqué dans le systèmeFichiers, logiciel, modèlee.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=TotoVersion=2.1}<<artifact>>CommandeAchat.jarCommandeAchat.jar

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

209. Exemple de diagramme de composants2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 « station client »:PCStandard« serveur »:DellPowerEdge 3600{OS=RedHat6}<<device>><<device>><<device>>« station client »:PCStandarditrlitltri{OS=Windows}i« browser »:webBrowserJoveGL.exeherculesClient.exe{vendor=romanSoft}{component=GeneralLedger}.HTTP/LANtt/HTTP/internetContainerEJBtt/itrtherculesBase.ear<<device>>« cluster web server »:Apache2.1{OS=Solaris{nbCluster=3}herculesAR.earrrherculesAP.earJAVA RMI/LANJDBCI/<<artefact>>SGBDOracleherculesWeb.exe

210. Déploiement : raffinementsLes nœuds et les artefacts sont instanciablespossibilité 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éellePossibilité de spécifier des caractéristiques du déploiement d’un artefact2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <<device>>:ServeurCommandes<<artifact>>CommandeAchat.jar<<deploymentSpec>>poDeploy.xmlexecution=threadtransaction=truepriority=low

211. A suivreUML 3/4 : diagrammes dynamiques et d’interactionsUML 4/4 : concepts avancés2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1