Upload
agace-leriche
View
109
Download
0
Embed Size (px)
Citation preview
1
2
U.M.L.Unified Modeling Language
(1ère partie)
Françoise Schlienger
4ème année 2004-2005
Département Informatique
3
Plan de la première partie
• Les méthodes d’analyse de 1960 à 1990 5
• Les méthodes Objet 9
• UML : généralités 16
• Les diagrammes d ’UML 17
• Les mécanismes communs 19
• Les diagrammes de classes 31
• Les diagrammes d ’objets 61
4
Booch
Unified MethodUnified Method0.8
etc...
OOSE(Jacobson et al.)
UML 0.9UML 0.9
1996
etc.ROOMCatalysis
OMGOMG
UML 1.1UML 1.1
Nov. 1997Nov. 1997
UML 1.3UML 1.3
UML 1.4UML 1.4
UML 2.0UML 2.0
Juin 1999Juin 1999
FinFin 200 20011
……
HOOD
OMT (Rumbaugh et al.)
1995
RationalRational
ROOM
Classe-Relation
Fusion
OOSE
Booch
OMT
Fin 1990
5
Méthodes d ’analyse (60-80)
MERISE(1962)
PETRI(1962)
HIPO(1970)
SD(1974)
Idef-0(1974)
LCS(1974)
HDM(1979)
SADT(1976)
SA(1978)
E-R(1976)
SDS(1977)
HOS(1975)
MACH(1980)
DREAM(1978)SARA
(1978)
IA-NIAM(1975)
1960-1974
1975-1980
6
Méthodes d’analyse (60-80)
1960 - 1974
• HIPO : Hierarchy plus Input Process Output (IBM/USA).
• PETRI : les réseaux de Petri ; outil pour la synchronisation (Allemagne)
• LCS : Lois de Construction de Systèmes (Warnier - France).
• SD : Structured Design (IBM : Stevens, Myer, Constantine, USA).
• Idef-0 : Icam definition-0 (DoD, US air force).
1975 - 1980
• IA-NIAM : Niijsen Information Analysis Methodologie, modèle relationnel binaire (Pays Bas).
• E-R : Entity-Relationship model (P. Chen, USA).
• SADT : Structured Analysis Design Technique (D.T. Ross, USA).
• SA : Structured Analysis (F. Yourdon, T. Demarco, USA).
• MERISE : méthode mise au point dans le cadre du ministère de l'industrie (Tardieu, Rochfeld ...)
7
Méthodes d ’analyse (80-90)
HOOD(1987)
OOD-86(1986)
SA-RT-2(1986)
OOA (C&Y)(1989) TOCATTA
(1987)
MASCOT3(1986)STATEMATE1
(1987)
MACH-2(1987)
1985-1990
JSD(1981)
SASD(1981)
MAIA(1984)
OOD-83(1983) SA-RT-1
(1984) CORE(1983)
AXIAL(1984)
SSADM(1982)
1981-1985
8
Méthodes d’analyse (80-90)
1981 - 1985• JSD : Jackson System Development (Michael Jackson, USA).• SASD : Structured Analysis and Structured Design (L. Constantine, USA).• SSADM : Structured Systems Analysis and Design Method (UK)• OOD-83 : Object Oriented Design (G. Booch, USA).• SA-RT-1 : Structured Analysis Real Time (P. Ward, S. Mellor, USA).• AXIAL : (P. Pellaumail, IBM-France).
1985 - 1990• OOA : Object Oriented Analysis (P. Coad, E. Yourdon, USA).• SA-RT-2 : Structured Analysis Real Time (D. Hatley, I. Pirbaï, USA).• HOOD : Hierarchical Object Oriented Design (Agence spatiale européenne).• TOCCATA : Techniques d'Organisation de la Conception par Comportements Abstraits
et Types Abstraits (CGE Alsthom, France).
9
Les méthodes objet
OBJECTORY(1992)
FUSION(1994)
CLASSERELATION
(1991)
OOA(S&M)(1991)
OMT(1991)
G. BOOCH(1991)
OOM(1991)
OBJETSNATURELS
(1991)
MERISE 2(1993)
EUROMETHODE
UML
MERISE +
1990-1995
Actuellement
?
UML 2
10
OOA : Coad et Yourdon* Analyse orientée objets (version 2) P. Coad et E. Yourdon, Masson 1993* Conception orientée objets P. Coad et E. Yourdon, Masson 1993
OOA : Shlaer et Mellor* Object-Oriented Systems Analysis : Modeling the World in Data
S. Shlaer et S. Mellor, Yourdon Press 1988* Object-Lifecycles : Modeling the World in States
S. Shlaer et S. Mellor, Yourdon Press 1992
Grady Booch : méthode orientée Ada 1991* Conception orientée objets et applications
Grady Booch, Addison-Wesley 1992
OOSE : version simplifiée d'Objectory (intéressant pour les aspects USE-CASE)* Le génie logiciel orienté objet
Ivar Jacobson, Christerson, Jonsson, Övergaard, Addison-Wesley 1993
Les méthodes objet (1)
11
Les méthodes objet (2)
Méthode classe-relation
* Ingénierie des objets, Approche classe-relation, application à C++
P. Desfray (version 2), Masson 1993
La méthode FUSION* Object Oriented Development : the FUSION method
D. Colemen, P. Arnold, S. Bodoff, Prentice-Hall, Englewood Cliffs, NJ, 1994
Évolution de Merise Merise/2
* MERISE/2 : modèles et techniques MERISE avancésG. Panet, R. Letouche, Éditions d'organisation 1994
OOM : Orientation Objet pour Merise* De Merise à OOM. Pourquoi changer ?
M. Bouzegoub, A. Rochfeld, Édition Hermès 1996
12
OMT : Rumbaugh et al. * premier livre en 1991, première conférence en France : 1993
* O.M.T. : Modélisation et conception orientées objet (édition française revue et augmentée) Rumbaugh et al., Masson 1995 * O.M.T. : Solution des exercices Rumbaugh et al., Masson 1996
Les méthodes objet (3)
13
UML : Unified Modeling Language
• octobre 94 : Grady Booch (Méthode Booch) et James Rumbaugh (OMT) commencent à unifier leurs 2 méthodes.
--> Unified Method 0.8
• fin 1995 : Ivar Jacobson introduit certains concepts de sa méthode (OOSE)
Langage de modélisation unifié avec pour objectifs de :
- ne plus faire évoluer les méthodes de manière indépendante les unes des autres,
- unifier la sémantique et les notations et amener ainsi une stabilité sur le marché "orienté-objet "
- rassembler leurs efforts pour résoudre des problèmes qu'aucune des trois méthodes ne peut bien résoudre.
14
UML : Unified Modeling Language
• octobre 1996 : UML 0.9 (Unified Modeling Language)diffusion au sein de la "communauté informatique" et intégration des remarques.
• 16 janvier 1997 : le document UML a été soumis à l'OMG (Object Management Group). .
• 14 novembre 1997 : adoption d'UML 1.1 comme standard par l'OMG.• Novembre 1998 : UML 1.3• 2000 : UML 1.4• 2004 : UML 2
Sites officiels : www.omg.orgwww.uml.org
15
Bibliographie
• Modélisation objet avec UML Pierre-Alain Muller, Eyrolles 1997, Eyrolles 2000Pierre-Alain Muller, Nathalie Gaertner, Eyrolles 2003• Intégrer UML dans vos projetsN. Lopez, J. Migueis, E. Pichon, Eyrolles 1997• UML pour l'analyse d'un système d'informationChantal Morley, Jean Hugues, Bernard Leblanc , Dunod 2000
• Le guide de l'Utilisateur UMLGrady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000
nouvelle version prévue pour UML 2 en mai 2005 (en anglais)• Le processus unifié de développement logiciel Grady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000
16
UML : Unified Modeling Language
UML propose :
• des éléments de modélisation qui représentent les abstractions du système en cours de modélisation
• des éléments de visualisation qui procurent des projections textuelles ou graphiques permettant la manipulation des éléments de modélisation
17
Diagrammes d ’UML
• les diagrammes de cas d'utilisation qui représentent les fonctions du système du point de vue de l'utilisateur,
• les diagrammes de classes qui représentent la structure statique en termes de classes et de relations,
• les diagrammes d'objets qui représentent les objets et leurs relations.
• les diagrammes d'états-transitions qui représentent le comportement des classes en termes d'états,
• les diagrammes de séquence qui sont une représentation temporelle des interactions entre les objets.
• les diagrammes de collaboration qui sont une représentation spatiale des objets et de leurs interactions.
18
Diagrammes d ’UML
• les diagrammes d'activités qui représentent le comportement d'une opération en termes d'actions (proches des organigrammes).
• les diagrammes de composants qui représentent les composants physiques d'une application.
• les diagrammes de déploiement qui représentent le déploiement des composants sur des dispositifs matériels.
19
Les mécanismes communs
Sont applicables sur chaque modèle :
• les notes
• les étiquettes
• les contraintes
• les relations de dépendances
• les stéréotypes
20
Les notes
Elles permettent d’ajouter des informations à un modèle comme des commentaires (sans contenu sémantique) mais aussi des exigences, des observations, des révisions ou des explications.
Ceci est une note qui peut être reliée à tout élément de modélisation par des pointillés.
21
Les étiquettes
Nommées également « Tagged values », elles permettent la création de nouvelles informations dans la spécification d’un élément. Elles se présentent sous la forme de paires {nom, valeur}
{version , 3.2} peut être ajouté sur un modèle
Dans les AGL, elles sont souvent utilisées pour indiquer des propriétés relatives à la génération de code.
22
Les contraintes
Elles permettent d’étendre la sémantique d’un élément d’UML en ajoutant de nouvelles règles ou en modifiant celles qui existent déjà.
Elles sont placées entre accolades sans syntaxe particulière.
{ la femme d'une personne est de genre 'féminin'}
{ la mari d'une personne est de genre 'masculin'}
Souhaits de spécialités dans l'ordre de préférence:
ETUDIANT
Nom : string
SPECIALITE
Libellé : string
sesSpé
*
{ordonné}
*
0..1SaFemme
PERSONNE
-Nom-Genre
SonMari0..1
23
Limite des contraintes informelles
PERSONNE
-Nom-Genre
0..1SaFemme
SonMari0..1 P1:PERSONNE
Nom = ‘Paul’Genre = ‘Masculin’
P2:PERSONNE
Nom = ‘Marie’Genre =‘Féminin’
P3:PERSONNE
Nom = ‘Anne’Genre =‘Féminin’
P4:PERSONNE
Nom = ‘Pierre’Genre = ‘Masculin’
SonMari
SonMari
SaFemme
SaFemme
Il faudrait ajouter :Si une personne est mariée, l’épouse du mari de cette personne est elle-même.Si une personne est mariée, l’époux de la femme de cette personne est lui-même.
Besoin de contraintes formelles : OCL
24
Les relations de dépendances (1)
Une dépendance est une relation sémantique entre deux éléments tels qu’un changement
apporté à l’un (élément source) peut affecter la sémantique de l’autre (élément cible).
Elle est représentée par une ligne en pointillés avec une flèche du coté de l’élément cible.
Elle peut être stéréotypée à l'aide d'un stéréotype standard.
E1:ENSEIGNANT
nom = ‘Dupont’
M1:MATIERE
libellé = ‘Génie logiciel’
MATIERE
libellé : string
enseigne >* 1..*
ENSEIGNANT
nom : string
« instantiates » « instantiates »
25
Les relations de dépendances (2)
PERSONNE PROJET
Participe
Responsable
{sous-ensemble}
Une contrainte peut être associée à plusieurs éléments par une relation de dépendance.
1 0..2
* *
- nom- prénom- e-mail
- nom- durée- dateDébut
26
Les stéréotypes
Ce sont des mécanismes d’extensibilité, permettant aux utilisateurs d’ajouter de nouveaux éléments de modélisation.
Les noms des stéréotypes sont mis entre « …. »
Dans une définition de classe on peut préciser
les constructeurs « create » et les destructeur « destroy »,
pour distinguer les différents types d’opérations.
Lorsqu’un stéréotype est utilisé fréquemment, on peut lui associer une notation particulière.
Client
<<actor>>
Client
<<actor>>
Client
CLIENT
<<create>>CLIENT()<<destroy>>Détruire()
27
Le stéréotype paquetage (« package »)
Les packages permettent de regrouper des classes, des associations et éventuellement d’autres packages.
On parle de PRODUIT :: Article
PRODUIT
ARTICLE LOCALISATION
FABRICANT1..*
* 1
*
28
Interface (1)
• Une interface est un ensemble d’opérations utilisées pour décrire un service d ’une classe.
• Contrairement à une classe, elle ne décrit aucune structure (elle ne peut donc pas inclure d’attributs) ni aucune implémentation (elle ne peut donc pas inclure de méthodes qui fournissent l’implémentation d’une opération).
• Une interface est en général liée (liaison de réalisation) à la classe qui la réalise.
• Une interface est représentée par un cercle et son nom. Le nom d’une interface commence généralement par un I.
PERSONNEI-PERSONNE
29
• On peut également représenter une interface par une classe stéréotypée, en indiquant les opérations qu ’elle fournit.
• Quand un objet joue un rôle spécifique, il présente un aspect particulier et les clients attendent un certain comportement.
Interface (2)
PERSONNE«interface»
I-PERSONNE
getHistoEmploi()getRémunération()getPrestation()
« realize »
30
Le stéréotype « interface »
Une interface
Une classe« use »
Une classe
« interface »Vue A
Un utilisateur X
« interface »Vue B
Un utilisateur Y
« use » « use »
« use » caractérise une relation de dépendance
« realize » « realize »
31
Diagrammes de classes / Diagrammes d’objets
32
Il existe plusieurs niveaux de notation :
a) niveau sans détail
PERSONNE
PERSONNE
NomPrénomAdresse
ModifierAdresse
b) niveau détail d'analyse
On y précise : le type des variables (integer, string, date …) les valeurs par défaut les signatures des opérations éventuellement, le niveau de visibilité : + public(accessible par tout utilisateur) par défaut
- privé(accessible seulement par la classe elle-même) # protégé(accessible par les descendants)
c) niveau de détail de conception
Notation des classes
33
• Attribut [ visibilité ] NomAttribut [: type] [= <valeur par défaut>]
•Opération[ visibilité ] NomOpération [(liste Paramètres)] [: typeRetour]
Paramètre[direction] Nom : type[ = valeur par défaut]
direction : in | out | inout (par défaut : in)
Notation des attributs et opérations
NOMDECLASSE
Opération()
Attributs
+EstSur(in p :POINT): boolean
-Longueur :integer =5
SEGMENT
34
Opérations / méthodes
• Une opération définit un service qui peut être demandé à n’importe quel objet de la classe.
• Une méthode est une implémentation d’une opération.
• La méthode associée à une opération fournit un algorithme exécutable. Cet algorithme est donné dans un langage de programmation ou dans du texte structuré.
35
Classe-1 Classe-2
Nom d’association
rôle-1 rôle-2
PERSONNE EstEnfantDe
Mère
Fils
PERSONNE APPARTEMENTLoue >
SonPropriétaire SesPropriétés
Propose >
SonLocataire SaLocation
Association entre classes
^
36
Exactement 1 1Exactement n nPlusieurs (0 ou plus) *Au plus 1 0..11 ou plus 1..*Cardinalité spécifiée 1..2 4
Nombre de propriétaires Nombre d ’appartements proposés
Cardinalité d’une association
PERSONNE APPARTEMENTPropose >1 *
37
Association : un exemple (1)
Un appartement n’a qu’un propriétaire et une personne peut proposer à la location plusieurs appartements (sous-entendu, elle peut aussi ne pas proposer d’appartement).
Remarque : on précisera toujours les noms des rôles. Le nom de l ’association est facultatif.
PERSONNE APPARTEMENT
Propose >1 0..*
SonPropriétaire SesPropriétés
38
Association : un exemple (2)
PERSONNE APPARTEMENT
Propose >1 0..*
SonPropriétaire SesPropriétés
-Code-Adresse-Surface-MontantLoyer
APPARTEMENT a un attribut implicite SonPropriétaire : PERSONNE
Un constructeur « complet » d’appartement doit avoir en paramètres le Code, l ’Adresse, la Surface, le MontantLoyer d ’un nouvel appartement mais aussi une instance de la classe PERSONNE.
39
Un qualificatif est un attribut dont les valeurs permettent de partitionner l’ensemble des objets reliés par la même association à un autre objet. Il permet de réduire la multiplicité effective d’une association
Ex1 : à un nom de fichier dans un répertoire ne correspond qu'un fichier
Les associations qualifiées (1)
REPERTOIRE NomFichier FICHIER11
1
REPERTOIRE **1 FICHIER
NomFichier
40
Ex2 : dans un cabinet médical, chaque médecin peut effectuer des actes de 3 types : visite,consultation, petite chirurgie.
On peut représenter le problème de 2 manières :
Les associations qualifiées (2)
Les actes médicaux sont rattachés au médecin par type.
MEDECIN CodeType ACTE-MEDICAL
MEDECIN * ACTE-MEDICAL1
CodeType
1*
41
Un attribut dérivé est un attribut calculé. Cela signifie qu’il peut être calculé à partir d ’autres informations du système à n’importe quel moment.
(et non pas qu’il a été calculé à un moment donné).
Exemple : pour une personne, l’attribut Age est un attribut calculé à condition que sa DateDeNaissance ait été enregistrée.Un attribut calculé est noté /Attribut
Par contre : si on met à jour une QuantitéEnStock par ajout ou suppression, sans conservertout l’historique des mouvements, alors QuantitéEnStock n’est pas une rubrique calculée.
L’attribut QuantitéEnStock est dit « modifiable » (par défaut tout attribut est « modifiable »)
« gelé » (« frozen ») est réservé aux attributs qui, une fois initialisés, ne peuvent être modifiés.
Attribut dérivé
42
Une association dérivée est une association déduite d’une autre.
Une association dérivée ne se justifie que pour faciliter des traitements.
Association dérivée
ENTREPRISE SERVICE EMPLOYESesServices SesEmployés
SesEmployés
SonService
/Emploi
Le nom de l’association est précédé d’un /
43
Contrairement à Merise, UML autorise :
• Une classe avec une seule instance et des attributs multivalués.
• Les attributs calculés (attributs dérivés) précédés par un / On précise alors, dans une note, la règle de calcul.
• Les associations dérivées (stéréotype « derive ») qui faciliteront un traitement.
Les identificateurs explicites (identifiants) ne sont pas indispensables. Ils ne sont pas soulignés (seuls les attributs de classe sont soulignés).
On peut les préciser à l’aide d’une note.
On peut représenter des « paramètres » (Merise) par le biais de variables de classe.
Remarques sur les classes
{identifier}
44
Contrairement à Merise ...
Exemple
Emploie>
ENTREPRISE
-Nom-Adresse
+ModifierAdresse()+AjouterPersonne()
1
PERSONNE
-Nom-Prénoms-Adresse-DateDeNaissance/-Age
+CréerPersonne()+GetCoordonnées()+CalculerAge
0..*
SesEmployés SonEntreprise
. {Age=DateCourante - DateNaissance}
+AjouterPersonne(in P : PERSONNE)
45
C ’est un type particulier d ’association "composé-composant" ou "partie de"
Agrégation (par référence) : 0..1
EQUIPE SPORT JOUEUR
Un joueur peut faire partie de plusieurs équipes
EQUIPE SPORT JOUEUR
Agrégation-Composition
SesParticipantsSonEquipe
*
SesParticipantsSesEquipes
**
Un objet peut faire partie de plusieurs composites à la fois.
46
Agrégation-Composition
La destruction du composite entraîne la destruction des composants.Un objet ne fait partie que d’un seul composite à la fois.
Composition (par valeur)
1 *
SaCommande SesLignesCOMMANDE LIGNE-COM
La durée de vie d’une ligne (de commande) est incluse dans celle de sa commande
Commande
Ligne annulée
Ligne ajoutée
Ligne non modifiée
Temps
47
Exercice
Réaliser un diagramme de classes permettant :• de représenter un train composé d’un ensemble de
wagons • de représenter les sièges répartis dans les différents
wagons
48
APPARTEMENTPropose >
Classe-Association (Classe associative)
AGENCE0..* 0..*
LOCATIONPrix : realSetPrix(P:real)GetPrix() : real
AGENCE 1
LOCATIONPrix : realSetPrix(P:real)GetPrix() : real
APPARTEMENT0..*0..* 1
49
Elles permettent de regrouper des opérations et des attributs communsà une ou plusieurs classes données et de préciser que les classes les plus spécifiqueshéritent des classes les plus générales.
COMPTE-BANCAIRE-Crédit : integer-Débit : integer….
+Déposer(S:integer)+Retirer(S:integer)+GetSolde()
COMPTE-EPARGNE-Taux : float
+CalculerIntérêts()
Généralisation Spécialisation
Relations de généralisation-spécialisation
50
Qualité d’une association qui permet le passage d’une classe vers une autre.En général, on peut naviguer dans les 2 sens. On peut cependant limiter la navigabilité :
Exemple :CLASSE-1 CLASSE-2
Nom d’association
Il doit être facile de passer directement d’un produit à son fabriquant.La commande d’un produit fait référence à l ’adresse de « SonRéalisateur »
Il y a demande de service (GetAdresse) de PRODUIT à FABRIQUANT.
Navigabilité d’une association
1..* 1SonRéalisateurSesProduits
FABRIQUANT
-Adresse
+GetAdresse()
PRODUIT
-QttéRéappro
+Commander()
51
Un attribut de classe décrit une valeur commune à une classe d'objets dans son ensemble.
Une opération de classe est une opération sur la classe elle- même. La plus commune est celle destinée à créer des nouvelles instances de classe.
Attributs et opérations de classe sont soulignés. (Attention : ne pas les confondre avec les identifiants de Merise.)
ARTICLE
-Référence-PrixHT-NbInstances
+CalculerPrixTTC()+Créer()+CompterInstances()
Attributs et opérations de classes
52
Un ‘ singleton ’ permet de référencer l’instance d ’une classe, unique par construction.
Forme générique d ’une classe implémentant un singleton.
L ’opération getInstance() est chargéede rapporter à l’appelant la référencede l objet unique.
Utilisation fréquente dans le cas d ’objets centralisateurs tels que‘superviseur’, ‘contrôleur’,
Application au design pattern ‘ singleton ’
SINGLETON
Instance : SINGLETON = null
getInstance() : SINGLETON
if (instance == null)instance := newSingleton()
return instance;
Le singleton se charge de construirel’objet lors du premier appel.
53
Classe et Opération abstraites / Polymorphisme
• Classe qui ne peut avoir aucune instance directe ; on écrit son nom en italique.
• Une opération abstraite ne fournit d’implémentation qu’au travers d’une instance d’une classe fille de celle qui la contient.
• Remarque : les noms des éléments abstraits sont écrits en italique ou préfixés par Abs.
FORME
-Nom : string
+CalcSurface()+GetNom()
54
RECTANGLE
- Long : float- Larg : float
+CalcSurface() + Type()
CERCLE
- Rayon : float
+CalcSurface()+ Type()
Opérationspolymorphes
Classe et Opération abstraites / Polymorphisme
FORME
-Couleur : string
+CalcSurface()+Type()
return ’rectangle’ return ’cercle’return Long * Larg
return PI * Rayon * Rayon
55
Attributs et opérations implicites (1)
ETUDIANT
Nom : string
Pour chaque attribut on ajouteimplicitement :
Ces opérations ne sont pas obligatoirement publiques. SetNom peut ne pas exister.
ETUDIANT
Nom : string
<constructeur>Etudiant ()<destructeur>~Etudiant()
<sélecteur ou accesseur>GetNom () : string<modificateur>SetNom (N:string) : bool
Pour la classe on ajoute implicitement :
56
Attributs et opérations implicites (2)
ETUDIANT
Nom : string
ETUDIANT
Nom : stringSonGroupe : GROUPE
<sélecteur ou accesseur>GetSonGroupe () :GROUPE<modificateur>SetSonGroupe(G:GROUPE)RetirerSonGroupe() … si le minimum est à 0
GROUPE
Numéro : int
SonGroupe
0..1
Pour chaque association navigable
de cardinalité 0..1, 1..1 on ajoute :
un attribut
… et les opérations correspondantes
57
Remarque concernant la navigation
ETUDIANT
Nom : string
GROUPE
Numéro : integer
SonGroupe
0..1
Pour un étudiant on peut obtenir son groupe, mais il n’est pas prévud’obtenir la liste des étudiants à partir du groupe.
SesEtudiants
0..*
58
Attributs et opérations implicites (3)
ETUDIANT
Nom : string
ETUDIANT
Nom : stringSesOptions : ensemble(OPTION)
<modificateur>AjouterOption(O:OPTION):boolRetirerOption(O:OPTION):boolGetSesOptions() : ensemble(OPTION)
OPTION
Libellé : string
SesOptions
0..*
Pour chaque association navigable
de cardinalité 0..*, 1..* on ajoute : un attribut de type ensemble,
… et les opérations
pour gérer ce type ensemble.
59
Remarque concernant la navigation
ETUDIANT
Nom : string
OPTION
Libellé : string
SesEtudiants SesOptions
0..* 0..*
Nouvelle hypothèse :
Pour un étudiant on peut obtenir ses options et on veut pouvoir obtenir la liste des étudiants à partir d’une option.
En ajoutant une flèche vers SesEtudiants, on ajoute implicitement SesEtudiants : ensemble (ETUDIANT) dans OPTION et les opérations correspondantes.
60
Attributs et opérations implicites (4)
REPERTOIRE NomFichier FICHIER11
1
Dans répertoire on trouvera une opération :
Chercher (NomFichier : string) : FICHIER
61
Diagrammes d’objets
• Ils modélisent les instances d’éléments qui apparaissent sur les diagrammes de classe.
• Ils montrent un ensemble d ’objets et leurs relations à un moment donné.
– Instances nommées
– Instances anonymes
– Instances avec valeurs d ’attributs
Bouton2:RECTANGLE
Longueur : float = 13.5Nom : string = “bouton-poussoir”
Largeur : float = 3.2
:CERCLE
Bouton1:RECTANGLENomInstance:NOMCLASSE
:NOMCLASSE
62
MATIERE
libellé : string
Diagramme d’objets (exemple)
E1:ENSEIGNANT
nom = ‘Dupont’
E2:ENSEIGNANT
nom = ‘Martin’
E3:ENSEIGNANT
nom = ‘Duval’
M3:MATIERE
libellé = ‘Système’
M1:MATIERE
libellé = ‘Génie logiciel’
M2:MATIERE
libellé = ‘Réseau’
enseigne >* 1..*
ENSEIGNANT
nom : string
63
MATIERE
libellé : string
Diagramme d’objets (nécessité de préciser l’association)
enseigne
enseigne
enseigne
enseigne >* 1..*
ENSEIGNANT
nom : string0..1 *
estResponsable >
estResponsable >
estResponsable >
E1:ENSEIGNANT
nom = ‘Dupont’
E2:ENSEIGNANT
nom = ‘Martin’
E3:ENSEIGNANT
nom = ‘Duval’
M3:MATIERE
libellé = ‘Système’
M1:MATIERE
libellé = ‘Génie logiciel’
M2:MATIERE
libellé = ‘Réseau’
64
65
66
U.M.L.Unified Modeling Language
(2ème partie)
Françoise Schlienger
4ème année 2004-2005
Département Informatique
67
Plan de la deuxième partie
• Les diagrammes de cas d’utilisation (Use-Case) 69
• Les diagrammes d’interactions 82
• Les diagrammes de séquences 84
• Les diagrammes de collaboration 102
• Les diagrammes d’états 105
• Les diagrammes d’activités 134
• Les diagrammes de composants 143
• Les diagrammes de déploiement 147
68
Booch
Unified MethodUnified Method0.8
etc...
OOSE(Jacobson et al.)
UML 0.9UML 0.9
1996
etc.ROOMCatalysis
OMGOMG
UML 1.1UML 1.1
Nov. 1997Nov. 1997
UML 1.3UML 1.3
UML 1.4UML 1.4
UML 2.0UML 2.0
Juin 1999Juin 1999
FinFin 200 20011
……
HOOD
OMT (Rumbaugh et al.)
1995
RationalRational
ROOM
Classe-Relation
Fusion
OOSE
Booch
OMT
Fin 1990
69
Les cas d ’utilisation (1)
Un cas d'utilisation indique une fonctionnalité du système déclenchée par un acteur externe au système.
L'acteur représente un rôle joué par une personne (ou un autre système) qui interagit avec le système en cours de modélisation.
• La même personne physique peut jouer le rôle de plusieurs acteurs (enseignant, responsable)
• Plusieurs personnes peuvent également jouer le même rôle, et donc agir comme le même acteur (tous les clients)
ActeurCas d'utilisation
70
Les cas d'utilisations permettent d'exprimer les désirs des utilisateurs du logiciel en cours de modélisation.
Les cas d ’utilisation décrivent le comportement du système, du point de vue d'un utilisateur, sous la forme d'une séquence d'actions et de réactions.
On peut préciser le comportement d’un cas d’utilisation en décrivant les flots d ’événements à l’aide d’un texte. Puis au fur et à mesure que l’on affine sa compréhension des exigences du système, on utilise des diagrammes d’interaction pour préciser graphiquement ces flots.
Les cas d ’utilisation (2)
71
Achat sur site Internet
Les acteurs : propriétés
Une relation de généralisation/spécialisation peut être appliquée aux acteurs.
Internaute
Consulter info.
Client Acheter livre
72
Un cas d’utilisation modélise un ensemble de séquences dans lequel chaque séquence représente une variation possible d’un même type d’interaction.
Chaque séquence est un scénario.
–Scénario : cas d’utilisation spécifique(exemple : « Le client Pierre retire 100 euros avec sa carte VISA à partir du distributeur installé 5 rue du château »)
–Cas d’utilisation : modélise le cas général, donne une vision synthétique de scénarios similaires.(exemple : « un client retire de l’argent à partir d’un distributeur »)
flot d’événements principal
On peut avoir d’autres scénarios : carte VISA périmée flot d’événements exceptionnel
Cas d ’utilisation et scénarios
73
Le système voiture
Garagiste Conducteur
Se déplacer
Écouter de la musique
Faire la vidange
Réparer
Exemple de cas d ’utilisation
74
Relation d’inclusion « include »
Le système voiture
Garagiste
Faire la vidange
Réparer
<<include>>
Activer pont élévateur
<<include>>
Permet d’incorporer le comportement d’un autre cas d’utilisation. Le cas d’utilisation inclus
n’est jamais exécuté seul, mais seulement en tant que partie d’un cas de base plus vaste.
75
Relation d’extension « extend »
Le système voiture
Garagiste
Faire la vidange
Réparer
Commander pièce
<<extend>>
Permet de modéliser la partie d’un cas d’utilisation considérée comme conditionnelle dans le comportement du système.
76
Spécialisation
Le système voiture
Garagiste
Réparer
Réparer Diesel
Les cas d’utilisation peuvent être hiérarchisés par généralisation/spécialisation. Les cas d’utilisation descendants héritent de la sémantique de leurs parents. Ils peuvent comprendre des interactions spécifiques supplémentaires ou modifier des interactions héritées.
Réparer essence
77
Le cas d’une coopérative de libraires
Pour chacun des cas d'utilisation, on fournira une spécification sous forme de texte ou d'un diagramme d'interaction (séquence ou collaboration)
Créer Nouveau Client
Vérifier solvabilité client
EmployéPasser une commande
urgente
Enregistrer une commande
<<extend>>
<<include>>
Ce cas peut être considéré comme exceptionnel.
On peut factoriser des comportements
<<extend>>
78
Spécification sous forme textuelle (rédigée avec l’aide de l ’utilisateur)
Système : coopérativeActeur primaire : l’employé de la coopérativeObjectif : enregistrer une commande « normale » de livresPrécondition : le libraire existeScénarios :
1 - vérification de sa solvabilité (à partir de son numéro)
Pour chaque livre :2 - vérification de l’existence du livre (à partir de l ’ISBN)
3 - précision de la quantité
Exception :1a - le libraire n’est pas solvable
(l ’employé est informé)2a - le livre n’existe pas
(l ’employé est informé)
79
Diagramme de classe (version de base)
CATALOGUELIVRE
LIGNE-COMMANDE
COMMANDE-LIBLIBRAIRE
REGISTRE-LIBRAIRE -SesDemandes
-SesLignes
*1
-SesCommandes-SonDemandeur
-SonCatalogue-SesLivres
*1-SonLivre
1
-SesLibraires
1
*
-SonRegistre
-SaCommande
*
1
*
EDITEUR
-SesLivres
-SonEditeur
*
1
80
Spécification sous forme textuelle (proposition technique)
Système : coopérativeActeur primaire : l ’employé de la coopérativeObjectif : enregistrer une commande de livresPrécondition : le libraire existeScénarios :
1 - vérification de la solvabilité du libraire (à partir de son numéro)
* une instance de commande est créée Pour chaque livre :
2 - vérification de l ’existence du livre* une instance de ligne de commande est créée
* l ’instance est reliée à la commande3 - précision de la quantité
* la quantité est ajoutée
Exceptions :1a - le libraire n ’est pas solvable * un message est renvoyé2a - le livre n ’existe pas * un message est renvoyé
81
Diagramme de classe (version 2)
CATALOGUE
LIVRE
LIGNE-COMMANDE
COMMANDE-LIB
LIBRAIRE
REGISTRE-LIBRAIRE
-NumISBN : integer-Titre : string
-DateEdition : Date
-SesCommandes
+TrouverLibraire(In Numéro:integer):LIBRAIRE
+TrouverLivre(In numéro:integer):LIVRE
-SonRegistre1
-SonCatalogue -SesLivres
1 *
+Solvable?():boolean
-SonDemandeur
1-NumLib : integer-NomLib : string-AdresLib : string-Etat : string
-SesLibraires*
+Créer(In Lib:LIBRAIRE,In NumCom:integer, In DateCom:Date)
*
-NumCom : integer-DateCom : Date
-SaCommande1
+SetQuantité(In Nb:integer)
-Quantité : integer
-SesDemandes
-SonLivre
*
1
+Créer(In Liv:LIVRE ,In Com:COMMANDE-LIB ,In Quantité:integer)
*-SesLignes
EDITEUR
-Nom : string-Adresse : string
-SesLivres
-SonEditeur
*
1
82
Diagrammes d’interaction
83
Diagramme d’interaction
Les diagrammes d’interaction représentent les objets les uns par rapport aux autres et montrent comment ces objets communiquent au cours d’une interaction.
Il existe deux sortes de diagrammes d’interaction :
• les diagrammes de séquence qui sont une représentation temporelle des interactions entre les objets.
• les diagrammes de collaboration qui sont une représentation spatiale des objets et de leurs interactions.
84
Diagramme de séquence
Un diagramme de séquence permet de décrire une simulation du fonctionnement d ’un cas d ’utilisation. Il met en jeu :
• un acteur
• un ensemble d ’objets
• la chronologie des échanges entre les objets (messages avec leurs paramètres et leur valeur de retour)
• les contraintes de temps.
85
Diagrammes de séquence : principes généraux
nom2:Classe1
objet du diagramme de classes
ligne de vie (durée de l’interaction)activation
nom3:Classe2
message
nom (…)
retour
nom1:Acteur
nom(…)
acteur
86
Diagramme de séquence : notation
Inst.1:Acteur
CallAction()
Inst.3:Class-BCréer()
CallAction()
Inst.4:CLASSE-C
Détruire()
CallAction()
Inst.2:CLASSE-A
87
Diagramme de séquence « système »
Il permet de décrire le fonctionnement du système. C ’est une reformulation du texte du cas d ’utilisation.
Il met en jeu :
• un acteur
• l ’objet de la classe SYSTEME
• la chronologie des échanges entre les objets
• les contraintes de temps
88
Diagramme de séquence « système » : exemple
Le système est traité comme une boîte noire.
Pour chaque livre commandéSolvableLibraire (num)
TrouverLivre (ISBN)
SetQuantité (n)
: Système
Livre
réponse
Ou réponse négative
89
Diagramme de séquence : message avec retour
Monsieut TRUC:LeResponsable
Unlivre:LIVRE
GetTitre()
Titre
90
Diagramme de séquence : création et message sans retour
UnLivre:LIVRECréer(NumISBN, Titre, DateEdition)
LeCatalogue:CATALOGUE
AjouterLivre(self)
Monsieut TRUC:LeResponsable
self ou this
91
Ajouter un nouveau livre : autre manière
Monsieut TRUC:LeResponsable
L:LIVRECréer(Numéro, Titre, AnnéeEdition)
L
LeCatalogue:CATALOGUE
AjouterLivre(L)
92
Ajouter un nouveau livre : solution préférable
LeCatalogue:CATALOGUE
NouveauLivre(NumISBN, Titre, DateEdition)
Monsieut TRUC:LeResponsable
UnLivre:LIVRECréer(NumISBN, Titre, DateEdition)
UnLivre
AjouterLivre (UnLivre)
93
Ajouter un nouveau livre en lui attribuant un numéro
L:LIVRE
Monsieut TRUC:LeResponsable
LeCatalogue:CATALOGUE
NouveauLivre(Titre, AnnéeEdition)
Créer(Numéro, Titre, AnnéeEdition)L
AjouterLivre(L)
CalculerNuméro()
Numéro
Cela suppose que l’on conserve le dernier
numéro attribué
94
Diagramme de séquence : branchement conditionnel(2 objets différents)
Instance:CLASSE1 Instance1:CLASSE2 Instance2:CLASSE3
[X] CallAction1()
[non X] CallAction2()
95
Diagramme de séquence : branchement conditionnel(même objet)
Instance:CLASS1 Instance1:CLASSE
[X] CallAction1()
[non X] CallAction2()
96
Diagramme de séquence (exemple)
Monsieut TRUC:Responsable
LeRegistre:REG-LIBRAIRE UnLibraire:LIBRAIRE
SolvableLibraire?
b
Solvable?()
b
TrouverLibraire
UnLibraire
Vérification de la solvabilité d’un libraire identifié par un numéro.
(numéro)
(numéro)
97
Diagramme de séquence en escalier (décentralisé)
On parle aussi de délégation ou propagation des messages .
Instance:A Instance1:B Instance2:C Instance3:D Instance4:E
CallAction()
CallAction()
CallAction()
CallAction()
98
Diagramme de séquence en fourche (centralisé)
On parle aussi de supervision (un objet envoie tous les messages)
Instance:A Instance1:B Instance2:EInstance3:C Instance4:D
CallAction()
CallAction()
CallAction()
CallAction()
CallAction()
99
Monsieut TRUC:Responsable
UnLibraire:LIBRAIRE C :COMMANDE-LIB L:LIGNE-COMMANDE SonLivre:LIVRE
GetDétailCommandes()
{Date +{Titre,Quantité}}
GetDétailCommande()
Date +{Titre,Quantité}
GetInfoLigne()
Titre,Quantité
GetTitre()
Titre
GetDate()
Date
GetLivre()
SonLivre
GetSesLignes()
SesLignes
GetQuantité()
GetSesCommandes()
Spécification sous forme de diagramme de séquence
Pour chaque commande C prise dans SesCommandes
Pour chaque ligne L prise dans SesLignes
SesCommandes
100
Monsieut TRUC:Responsable
UnLibraire:LIBRAIRE C :COMMANDE-LIB L:LIGNE-COMMANDE SonLivre:LIVRE
GetDétailCommandes()
GetDétailCommande()
GetInfoLigne()
Titre,Quantité
GetTitre()
Titre
Spécification sous forme de diagramme de séquence
Pour chaque commande C prise dans SesCommandes
Pour chaque ligne L prise dans SesLignes
Date +{Titre,Quantité}
{Date +{Titre,Quantité}}
101
Spécification sous forme de diagramme de séquence(trop centralisé)
Monsieut TRUC:LeResponsable
C :COMMANDE-LIB L :LIGNE-COMMANDE unLivre:LIVREUnLibraire:LIBRAIRE
GetSesLignes()
GetQuantité()
Quantité
GetLivre()
unLivre
GetTitre()
Titre
GetDateCom()
Date
GetDétailCommandes()
GetSesCommandes()
SesCommandes
Pour chaque commande C prise dans SesCommandes
Pour chaque ligne prise dans SesLignes
SesLignes
{Date +{Titre,Quantité}}
102
Diagramme de collaboration
Un diagramme de collaboration est une extension du diagramme d ’objets.
Il permet de décrire :
* un aspect structurel : un ensemble d ’objets, les liens entre ces objets, les rôles de ces objets dans la collaboration
* un aspect de communication : les messages et les numéros de séquence des échanges entre les objets de cette collaboration.
103
Spécification sous forme de diagramme de collaboration
MonsieurTRUC: Responsable
UnLibraire: Libraire
C: CommandeLib
L: LigneCommande
SonLivre : Livre
2: GetSesCommandes ( )
4: GetDate ( )5: GetSesLignes ( )
7: GetLivre ( )9: GetQuantité ( )
1: GetDétailCommandes ( )
3: GetDétailCommande ( )
6: GetInfoLigne ( )
8: GetTitre ( )
104
Diagramme de classe
CATALOGUE
LIVRE
LIGNE-COMMANDE
COMMANDE-LIB
LIBRAIRE
REGISTRE-LIBRAIRE
+Solvable?():boolean
-NumLib : integer-NomLib : string-AdresLib : string-Etat : string
+GetSesCommandes()+GetDétailCommandes()
-SesLivres
*
-NumCom : integer-SesCommandes
+SolvableLibraire?(In Numéro:integer):boolean
+GetSesLibraires()
SonCatalogue
1+TrouverLivre(In numéro:integer):LIVRE+AjouterLivre(In L:LIVRE)
+TrouverLibraire(In Numéro:integer):LIBRAIRE
*
SonRegistre
-SesLibraires
1
-SonDemandeur
1
-NumISBN : integer-Titre : string
-DateEdition : Date
+GetTitre():string
+Créer(In Numéro:integer ,In Titre:string ,In DateEdit:Date)+GetNumISBN():integer
-Quantité : integer
+MajQtté(In Nb:integer)+GetQuantité():integer
+GetInfoLigne()+GetSonLivre():LIVRE
-DateCom : Date
1
*
-SaCommande
-SesLignes
1
*
-SonLivre
-SesDemandes
+Créer(In Liv:LIVRE ,In Com:COMMANDE-LIB ,In Qtt:integer)
*
+Créer()
+GetDateCom():Date+GetDétailCommande()
+GetSesLignes(): Set (n)LIGNE-COMMANDE
+AjouterLigne(In L:LIGNE-COMMANDE)
EDITEUR
-Nom : string-Adresse : string
SesLivres
SonEditeur
*
1
105
Diagrammes d’états
106
Le diagramme d’états
Un diagramme d’état modélise l’existence (cycle de vie) d’un objet, que ce soit une instance de classe ou un système pris dans son ensemble.
Il repose sur différents concepts :
• les états
• les transitions
• les événements.
107
Les états
Un état correspond à la manière d’être d’un objet pendant un intervalle de temps plus ou moins long.
Un état se compose de plusieurs parties :
• le nom
• les actions d’entrée/sortie : ce sont des actions effectuées au moment de l ’entrée ou de la sortie de l’état
• les activités
• les actions liées aux transitions internes ( ces transitions n’occasionnent aucun changement d’état).
108
Transitions et Evénements
Une transition indique le passage d’un état (état source) dans un autre (état cible).
Elle est représentée par une flèche.
Un événement représente quelque chose qui arrive à un moment précis.
Il peut déclencher un changement d ’état.
Exemple : une télévision.
EtatTransition
Arrêtée En veilleMise sous tension
Evénement
109
Activités - Actions
Une activité représente une opération qui nécessite un certain temps d ’exécution.Une activité peut être interrompue à chaque instant par un événement générant une
transition.Une activité est associée à un état. Un état peut ne pas avoir d ’activité.
Une action représente une opération instantanée ; sa durée est insignifiante. Une action est toujours intégralement réalisée.Une action est associée à un événement.Si aucune action ne résulte d’un événement qui se produit alors on peut mentionner
l’action : « defer ». Cela permet d’insister sur le fait que l’événement peut arriver mais qu’il est sans effet dans l’état où l ’objet se trouve. L’événement sera traité par le même objet, dans un autre état, sans avoir besoin de se reproduire.
110
Forme générale d’un état
NOM D ’ETAT
entry / action-entréedo : activitéon Evénement-1/action-1…on Evénement-n / action-nexit / action-sortie
Début
Fin
111
Forme générale d ’une transition
Etat1
entry/action-entrée1do : activité1on Event-11/action-11…on Event-1n /action-1nexit/action-sortie1
Etat2
entry / action-entrée2do : activité2on Event-21/action-21…on Event-2m/action2mexit/action-sortie2
Événement [garde] / action
Actions et activités sont exprimées avec des verbes.
Remarque : suivant les cas, événement, garde (condition), action peuvent être omis.
112
Diagramme d’états : système d’alarme
EN-VEILLE
do : garder détecteur sous tension
EN-ALERTE
entry / mettre sonnerieDétection-Pb / envoyer message
poste de surveillance
Événement
Activité
Action
113
Dans une bibliothèque on enregistre tous les nouveaux livres avant de les mettre à disposition des lecteurs.
Cas 1 : les livres enregistrés sont mis à disposition à 15h.
Dès qu’un livre est enregistré il est mis à disposition
Diagramme d’états
ENREGISTREMENT
do / enregistrer
A DISPOSITION
entry / placerWhen 15 heures
ENREGISTREMENT
do / enregistrer
A DISPOSITION
entry / placer
114
États composés / Sous-états
Un sous-état est un état emboîté dans un autre état (état composé).
Forme générale :
Etat1 Etat2
Etat3 Etat4
Event-1
Event-5 Event- 3Event-2
Event-4
115
Exemple d’états composés
Un magnétoscope peut être * en fonctionnement
* hors fonctionnement.
* en veille
En fonction, il peut être * en enregistrement
* en diffusion.
HORS FONCTION EN-ENREGISTREMENT
EN-DIFFUSIONEN VEILLE
Event-1
Event-5 Event- 3Event-2
Event-4
EN FONCTION
Event-6
Event-7
116
États composés / Sous-états
Etat1 Etat2
Etat3 Etat4
Event-1
Event-5
Event- 3Event-2Event-4
Autre forme de modélisation équivalentePoint d ’entrée de l’état composé.
117
États à historique
Un état à historique permet à un état composé qui contient des sous-états de se souvenir du dernier sous-état actif avant la transition réalisée depuis l’état
composé.
Etat1 Etat2
Etat3 Etat4
Event-1
Event-5
Event- 3Event-2
Event-4
H
Point d’entrée pour la première fois.
118
États à historique (exemple)
Exemple : une machine à laver peut être arrêtée dans un état (lavage, rinçage, essorage). Elle redémarrera du même état.
Arrêtée
En lavage
En rinçage
En essorage
Mise en fonctionnement
H
Fin du cycle
Arrêt
119
Diagramme d’états : exemple de la montre
Une montre digitale simple possède un cadran et 2 boutons que l’on nomme A et B, pour la mettre à l’heure. La montre a deux modes d’opération : affichage de l’heure et mise à l’heure.
Le mode de mise à l’heure a deux sous-modes, heures et minutes.
Le bouton A s’utilise pour les modes. A chaque fois que l’on appuie dessus le mode change suivant la séquence : affichage, configurer heures, configurer minutes, affichage, etc.
Dans un des 2 sous-modes ‘ configurer heures ’, ‘ configurer minutes ’, le bouton B s’emploie pour avancer les heures ou les minutes à chaque fois que l’on appuie dessus. Les boutons doivent être relâchés avant de pouvoir produire un autre événement.
120
Diagramme d’états
EnAffichageHeureAppuyerA
AppuyerA
EnModificationH
on AppuyerB/IncrémenterH()
EnModificationM
on AppuyerB/IncrémenterM()
AppuyerA
EnModification
121
La montre : diagramme de classes
MONTRE
-Heures : integer-Minutes : integer+AppuyerA()+AppuyerB()-IncrémenterH()-IncrémenterM()
122
La montre : diagramme de classes
ModifierHeures
+ EtatSuivant()+avance()
Montre
-heures : Type-heure-minutes : Type-minute
+AppuyerA()+AppuyerB()+IncH()+IncM()
AffichageHeure
+ EtatSuivant()
ModifierMinutes
+ EtatSuivant()+avance()
EtatMontre
+EtatSuivant()
+avance()état
*1
AffichageHeure: EtatMontreModifierHeure: EtatMontreAffichageMinutes : EtatMontre
123
Les événements « appel »
• Un événement « appel » est un événement interne (il survient entre les objets du système).
• Il représente le déclenchement d ’une opération.
• Un événement « appel » implique au moins 2 objets :
– celui qui invoque l’opération
– celui vers lequel l’événement est dirigé. Ce dernier devra contenir une opération de même nom que l’événement.
• Notation :
^objet-destinataire.événement-appel
124
Les événements « appel » : exemple
• Autoradio :
• Voyant lumineux
EN FONCTIONEntry : ^Voyant.Allumerdo : DiffuserSon
HORS FONCTION
Entry : ^Voyant.Eteindre
MettreBouton (‘off ’)
MettreBouton (‘on’)
ALLUME
Entry : SetLumière(‘vrai’)
ETEINT
Entry : SetLumière(‘faux’)
Eteindre
Allumer
125
Opérations publiques - Opérations privées
• Les opérations correspondant aux événements externes et aux événements appel correspondent à des opérations publiques (opérations déclenchées par un autre objet).
• Les opérations effectuées à l’intérieur d ’un état correspondent à des opérations privées (opérations d ’un objet sur lui-même).
126
Opérations publiques - Opérations privées : exemple
• L’utilisateur peut activer MettreBouton(‘off ’), MettreBouton(‘on’) mais c’est l’autoradio qui active l’opération DiffuserSon() suivant l’état dans lequel il est.
• L’autoradio envoie un message Allumer(), Eteindre() au voyant mais c’est le voyant qui active l’opération setLumière en fonction de son état.
SonVoyant
SonAutoradio
VOYANT
-Lumière : booléen
+Allumer()
+Eteindre()
- SetLumière(b:bool)
AUTORADIO
+MettreBouton(e: string)
- DiffuserSon()
127
Les événements temporels
• Les événements temporels sont causés par l’expiration d ’une temporisation. Ils peuvent être :
• absolus ( spécification d’une date ou d’une heure) et sont traduits par le mot clef when.
ex : when date = 1/01/02, pour indiquer le passage de l ’état où la monnaie était en francs à l ’état où la monnaie est en euros.
Monnaie en francs Monnaie en euroswhen date = 1/01/02
128
Les événements temporels
• relatifs (spécification d’une durée par rapport à un état) et sont traduits par le mot clef after
ex : after 10 jours, pour indiquer le passage de l’état consommé à un état périmé dans le cas de produits qui se détériorent rapidement.
Médicament consommé Médicament périmé
Médicament consommable
Ouverture flacon
after 10 jours
when date du jour >= date limite
129
Les événements « appel » : exemple
• Autoradio :
• Voyant lumineux
EN FONCTIONEntry : ^Voyant.Allumerdo : DiffuserSon
HORS FONCTION
Entry : ^Voyant.Eteindre
MettreBouton (‘off ’)
MettreBouton (‘on’)
ALLUME
Entry : SetLumière(‘vrai’)
ETEINT
Entry : SetLumière(‘faux’)
Eteindre
Allumer
130
Opérations publiques - Opérations privées
• Les opérations correspondant aux événements externes et aux événements appel correspondent à des opérations publiques (opérations déclenchées par un autre objet).
• Les opérations effectuées à l’intérieur d ’un état correspondent à des opérations privées (opérations d ’un objet sur lui-même).
131
Opérations publiques - Opérations privées : exemple
• L’utilisateur peut activer MettreBouton(‘off ’), MettreBouton(‘on’) mais c’est l’autoradio qui active l’opération DiffuserSon() suivant l’état dans lequel il est.
• L’autoradio envoie un message Allumer(), Eteindre() au voyant mais c’est le voyant qui active l’opération setLumière en fonction de son état.
SonVoyant
SonAutoradio
VOYANT
-Lumière : booléen
+Allumer()
+Eteindre()
- SetLumière(b:bool)
AUTORADIO
+MettreBouton(e: string)
- DiffuserSon()
132
Petit rappel sur les relations
Il existe 4 types de relations dans UML :• la dépendance représentée par une ligne en pointillés, fléchée.
• L’association représentée par une ligne continue qui peut être fléchée (navigation).
L’agrégation est une association particulière.
• La généralisation représentée par une ligne continue fléchée avec une pointe creuse.
• La réalisation représentée par une ligne en pointillés fléchée avec une pointe creuse.
133
Les diagrammes d ’activités
Un diagramme d’activités est essentiellement un organigramme qui représente l ’activité au cours du temps.
Il peut s’utiliser :
• pour préciser un cas d ’utilisation en indiquant les flux, les synchronisations, les conditions d’exécution des activités.
(on peut représenter éventuellement qui est responsable d’une activité)
• pour spécifier un algorithme associé à une opération.
134
Les diagrammes d ’activités (formalisme)
– Activité (traitement)
– Transition
– Synchronisation
– Flots de données
– Flots de données dans un état particulier
– Production et consommation de flot de données
– Branchement conditionnel [garde]
Faire ...
objet:Classe
objet: [état]
[cond.1]
[cond.2]
135
Commander produit
Traiter commande
Sortir article
Expédier commande
Recevoir commande
Facturer commande
Recevoir facture
Expédier facture
Payer facture
Clôturer commande
Recevoir paiement
136
Les travées
Une travée permet de diviser les activités en groupes, chaque groupe représentant le département responsable de ces activités. (niveau organisationnel de Merise)
Dans un diagramme d’activité divisé en travées, chaque activité appartient à une seule travée, même si les transitions peuvent passer d’une travée à l’autre.
Les travées sont délimitées par des barres verticales. Chaque travée a un nom.
137
Commander produit
Traiter commande
Sortir article
Expédier commande
Recevoir commande
Facturer commande
Recevoir facture
Expédier facture
Payer facture
Clôturer commande
Client Service ventes Entrepôt
Recevoir paiement
138
Commander produit
Traiter commande
Sortir article
Expédier commande
Recevoir commande
Facturer commande
Recevoir facture
Expédier facture
Payer facture
Clôturer commande
Client Service ventes Entrepôt
f: facture[due]
f: facture[payée]Recevoir paiement
139
Les composants (1)
Un composant est une partie physique remplaçable d’un système qui fournit la réalisation d’un ensemble d’interfaces. Un composant existe rarement indépendamment des autres. Un composant donné collabore avec d’autres composants.
Un composant est représenté par un rectangle avec des onglets :
Composant1
140
Un composant représente en général le regroupement physique d’éléments habituellement logiques tels que les classes et leurs interfaces en tenant compte de leurs collaborations.
On peut préciser les classes qu’implémente un composant par une liaison :
Les composants (2)
Composant1
Class1 Class2
Composant1
Class1
Class2
141
Les composants (3)
De la même manière que pour les classes on peut représenter les composants qui réalisent des interfaces, et les autres composants qui ont accès aux services à travers les interfaces.
Composant1Class
Composant
Lien de dépendance(accès au service)
Réalisation
Composant1<<interface>>
Class Composant
142
Composants standards
UML définit 5 stéréotypes standard qui s’appliquent aux composants :
• « file » précise un composant qui représente un document contenant du code source ou des données
• « executable » précise un composant qui peut être exécuté
• « table » précise un composant qui représente une table de base de données
• « library » précise une bibliothèque objet statique ou dynamique
• « document » correspond à un document quelconque (fichier de données, d’installation, document d’aide …)
143
Les diagrammes de composants
Ils montrent l’organisation et les dépendances au sein d’un groupe de composants.
En règle générale les diagrammes de composants contiennent
• des composants
• de interfaces
• des relations
– de dépendances
– de généralisation
– d’association
– de réalisation
144
Les diagrammes de composants (exemple de fichiers)
signal.h {version = 3.5}
signal.h {version = 4.1}
signal.h {version = 4.0}
« parent » « parent »
irq.h
interp.cpp
device.cpp
signal.cpp {version = 4.1}
145
Les nœuds
Un nœud est un élément physique qui intervient lors d’une phase d’exécution ; il représente une ressource de calcul et dispose généralement au moins d’un peu de mémoire et souvent d’une capacité de traitement.
Un nœud est en général représenté par un cube.
« mémoire »Disque
« processeur »PC
« dispositif »Modem
146
Les nœuds
Les nœuds sont probablement les briques de base les plus stéréotypés en UML.
Des icônes sont souvent associées aux stéréotypes, pour fournir des repères visuels explicites pour le public auquel ils sont destinés.
147
Les diagrammes de déploiement
Ils permettent de représenter l’architecture physique d’un système en visualisant les classes de nœuds (ou des instances de nœuds) et les relations de dépendances et d’associations entre ceux-ci.
Ils peuvent également comporter les composants qui doivent résider sur un nœud.
Remarque :
si on développe un logiciel sur une seule machine avec en interfaces des périphériques standards, on peut se passer de diagrammes de déploiement.
Nœud
Composant
Nœud
Composant
148
Les diagrammes de déploiementavec des icônes
149
Diagramme de déploiement : diagramme de spécification
Modélisation de la répartition des composants
kiosque
console
tour de disques RAID10-T Ethernet
RS-232
<<executable>>user
<<executable>>admin
<<executable>>config
10
20
1serveur
<<executable>>dbadmin
<<executable>>tktmstr
vitesseProcesseurmémoire
150
Diagramme de déploiement : diagramme d’instances
s:Serveurk1:kiosque
k2:kiosque
c1:console
t:tour de disques RAID
vitesseProcesseur = 2Ghzmémoire=256Mo
151
152
153
De l’analyse … à la conception
L’analyse des besoins est l’activité essentielle au début du processusde développement d’un logiciel.
Le futur utilisateur exprime ses besoins sous une forme textuelle informelle, parfois accompagnée de modèles d’IHM permettant de mieux préciser des souhaits.
Analyse des besoins
154
Le cas bibliothèque.
La bibliothèque d’une école d’ingénieurs met à disposition des élèves et des enseignants des livres techniques qui peuvent être empruntés. Chaque emprunteur dispose d'un badge, comportant un numéro, son nom et son prénom, qu'il doit présenter pour accéder à la bibliothèque. Il peut emprunter autant de livres qu'il le désire.
La durée de l'emprunt n'est pas limitée.
Chaque livre est repéré par un numéro, un titre, le nom de l'auteur principal, l'année d'édition.
155
Le cas bibliothèque.
On ne cherche pas à faire d'historique des emprunts. On veut seulement savoir quelle personne détient un livre de manière à pouvoir la contacter si une autre souhaite consulter l'ouvrage. Pour cela, on dispose pour chaque personne de son “ e- mail ”.
Il est nécessaire de pouvoir enregistrer un nouveau livre, un nouvelemprunteur. On voudrait pouvoir éditer des statistiques.
156
Le cas bibliothèque : IHM - retour anonyme
Retour anonyme :
Entrer le numéro du livre : 1 2 3 4 5 (RC) Le génie logiciel orienté Objet
157
Le cas bibliothèque : IHM - retour d’un étudiant
Retour d’un étudiant :
Retour d’ étudiantEntrer le numéro de l’emprunteur : 456 (RC)
Jean Dupuy
Livres empruntés : Le génie logiciel orienté Objet OCL pour les nuls
158
Spécification globale
Le but de cette activité est d'établir une première description du futur système.
L’expression préliminaire des besoins donne lieu à une modélisation par des
Cas d’utilisation
et à une maquette d’IHM.Il faudra donc :
• identifier les acteurs• identifier les cas d’utilisation• ajouter si besoin des relations entre cas d’utilisation.
Il sera utile d’établir une priorité entre les cas d’utilisation de manièreà aider le chef de projet à planifier ses itérations (modèle de la spirale).
159
Le cas bibliothèque : cas d’utilisation
Enregistrer Retour
Enregistrer EmpruntBibliothécaire
Enregistrer Nouveau Livre
Priorité 2
Enregistrer Nouvel Emprunteur
Éditer Statistiques
160
EnregistrerRetourAnonyme
Enregistrer Retour
Bibliothécaire
Le cas bibliothèque : cas d’utilisation
EnregistrerRetourEtudiant
161
Spécification globale (2)
Il s’agit ensuite de créer une représentation visuelle des objets du monde réel dans un domaine donné.Ils seront représentées dans un
Diagramme de classes d’analyse
ne mettant en évidence que peu d’opérations.
Par contre les attributs évoqués (caractéristiques d’un livre, d’un emprunteur, etc.) dans les cas d’utilisation ainsi quetoutes les associations suggérées (emprunt caractérisé comme une association entre LIVRE et PERSONNE) devront y figurer.
162
Le cas bibliothèque : diagramme de classes d’analyse
1
*
SaBiblio
BIBLIOTHEQUE
SesLivresSaBiblio
*1
SesEmprunteurs
PERSONNE
LIVRE
SesEmprunts
NumeroNomPrénomE-mail
SonEmprunteur
0..1
*
Professeur
Numéro Titre AuteurAnnéeEdition
Dans la phase d’analyseil n’est pas indispensable de faire apparaître la classe du domaine.
163
Spécification détaillée des exigences
Une fiche de description textuelle de chaque cas d’utilisation doit être fournie.Il est nécessaire de fournir :• le scénario qui permet de satisfaire les objectifs des acteurs par le chemin le plus direct de succès.• les extensions qui comprennent tous les scénarios de succès ou d’échec.Il faut également préciser :• les pré conditions qui définissent ce qui doit être vrai en amont ducas d’utilisation pour que celui-ci puisse démarrer.• Les post conditions qui définissent ce qui doit être vrai lorsque lecas d’utilisation se termine.
164
Le cas bibliothèque : scénario
Système : la Bibliothèque
Acteur Primaire : un bibliothécaire
Objectif : enregistrer les retours de livres d'un étudiant qui présente sa carte.
Scénario :1 - Rechercher à partir d'un numéro de carte, le nom de l’étudiant et la liste des titres des livres qu’il a empruntés.2 - Pour chaque livre sélectionné, enregistrer le retour.
Exception :1a -le numéro saisi est inconnu --> demander de recommencer.
Pré condition : le livre retourné figure dans la liste des livres empruntés.
165
Spécifications OCL
context EnregistrerEmprunt( NumL, NumP : integer) {signals echec}pre :Valide : boolean =
Il existe une instance de Livre avec numéro Numl.Cette instance n’est pas déjà empruntée.Il existe une instance de Personne avec numéro NumP.
post :not Valide implies echec.sent()Valide implies
L’instance de Livre avec numéro NumL a comme emprunteur la Personne avec numéro NumP.L’instance de Livre avec numéro NumL figure dans les emprunts de la Personne avec numéro NumP.
166
Spécifications OCL
context EnregistrerEmprunt( NumL, NumP : integer) {signals echec}pre :Valide : boolean =
Livre.allInstances exists ( L | L.Numéro =NumL)Personne.allInstances exists ( P | P.Numéro =NumP)let L1 : Livre | L1.Numéro = NumL inL1.sonEmprunteur isEmpty()
post :not Valide implies echec.sent()Valide implies
let L1 : Livre | L1.Numéro = NumLP1 : Personne | P1.Numéro = NumP inL1.SonEmprunteur = P1P1.SesEmprunts = P1.SesEmprunts@pre including (L1)
167
Spécifications OCL
context EnregistrerRetour( NumL : integer) {signals echec}pre :Valide : boolean =
Il existe une instance de Livre avec numéro Numl.Cette instance est empruntée par une Personne.
post :not Valide implies echec.sent()Valide implies
L’instance de Livre avec numéro NumL n’a pas d’emprunteurL’instance de Livre avec numéro NumL ne figure pas dans les emprunts de la Personne qui l’avait avant l’enregistrement de retour.
168
Spécifications OCL
context EnregistrerRetour( NumL : integer) {signals echec}pre :Valide : boolean =
Livre.allInstances exists ( L | L.Numéro =NumL)let L1 : Livre | L1.Numéro = NumL inL1.sonEmprunteur notEmpty()
post :not Valide implies echec.sent()Valide implies
let L1 : Livre | L1.Numéro = NumLP1 : Personne | P1= L1.SonEmprunteur@pre inL1.SonEmprunteur isEmptyP1.SesEmprunts = P1.SesEmprunts@pre excluding (L1)
169
Spécification détaillée des exigences
Les cas d’utilisation décrivent les interactions des acteurs avec lesystème.On peut représenter ces échanges à l’aide de
Diagrammes de séquence système.
Le comportement du système est décrit vu de l’extérieur, sanspréjuger de comment il sera réalisé.
170
Le cas bibliothèque : diag de séquence système - retour étudiant
:LeSystème:Bibliothécaire
TrouverLivres(NumEtu)
NomEtu +{titre}
EnregistrerRetour(titre)
171
Spécification détaillée (suite)
Il est nécessaire de contrôler la validité du texte des cas d’utilisationpar rapport aux informations définies dans le diagramme de classesconceptuelles.
Afin de pouvoir relier les diagrammes de cas d’utilisation audiagramme de classes conceptuelles, il est nécessaire d’identifierles principales classes d’IHM ainsi que les opérations qui vontmontrer la logique de l’application.
On va définir un diagramme supplémentaire appelé
Diagramme de classes de conception
172
Typologie des classes de conception
• Les classes qui modélisent les interactions entre le système et les utilisateurs, appelées classes « dialogue ».
• Les classes qui représentent les processus, les ressources etl’organisation d’une entreprise, appelées classes « métier ».Elles sont souvent permanentes.
• Les classes qui contiennent la cinématique de l’application, appelées classes « contrôle ». Elles font la transition entre les classes dialogues et les classes métiers et contiennent les règles métiers.
173
Les classes « métier »
Ce sont les classes étudiées jusqu’à présent. Celles-ci représentent en général des informations persistantes de l’application.
Métier MM
donnée1donnée2donnée3
opér1()opér2()
174
Les classes « dialogue »
Elles possèdent des attributs et des opérations. Les attributs vont représenter des champs de saisie ou des résultats. Les résultats sont distingués en utilisant la notation de l’attribut dérivé.Les opérations représentent des actions de l’utilisateur sur l’ IHM, oudes actions de la classe de contrôle.
Dialogue DD
champ1champ2/résultat
action1()action2() saisir ou afficher
175
Les classes « contrôle »
Elles possèdent uniquement des opérations.Elles montrent :
• la logique de l’application, • les règles métier, • les comportements du système informatique.
Contrôle CC
opération1()opération2()
176
Règles de composition des diagrammes de classes de conception
• Les « dialogues » ne peuvent être reliés qu’aux « contrôles ».• Les « métiers » ne peuvent être reliées qu’aux « contrôles » ou autres « métiers ».• Les « contrôles » ont accès à tout type de classes, y comprisd’autres contrôles.
Contrôle CC
opération1()opération2()
Dialogue DD
champ1champ2/résultataction1()action2()
Métier MM
donnée1donnée2donnée3opér1()opér2()
177
Un exemple simple
Écran de saisieNouveau Livre
CréerNouveau Livre
Livre
CtrCréation
créerLivre(titre, auteur)
Saisie Livre
titreauteur
saisir(titre, auteur)
Livre
numérotitreAuteur+Livre(titre, auteur)
- nouveauNuméro()
178
RetourAnonyme
NumLivre
/titre+AfficherTitre()+ EnregRetour()
CtrRetourAnonyme
+EnregRetour (NumLivre)-AfficherTitre(NumLivre)-TrouverLivre (NumLivre)
Livre
-numéro-titre-auteur
+RetirerEmprunteur(P:Personne)
Le cas bibliothèque : diag de classes d’analyse - retour anonyme
Personne
-numéro-nom-prénom
+RetirerLivre(L:Livre)
SonEmprunteur
0..1
*
SesEmprunts
179
RetourEtudiant
NumEtud/nom
+AfficherNom(N:string)+AffTitreLivre()
CtrRetourEtudiant
+AffTitreLivre(NumEtud)-AfficherNom(NumEtud)-AfficherTitre(T:sting)+EnregRetour (L:Livre)
Livre
-numéro-titre-auteur
Livre-Dialogue
/titre
+Créer()+sélectionner()
Le cas bibliothèque : diag de classes d’analyse - retour étudiant
Etudiant
-numéro-nom-prénom
SonEmprunteur
0..1
*
SesEmprunts
180
La conception
Elle vise principalement à préciser le modèle d’analyse de telle sorte qu’il puisse être implémenté avec les éléments d’architecture dont ondispose.• Les classes deviennent plus précises, avec des attributs typés.• Au niveau des « ensembles », il est nécessaire de préciser s’ils serontimplémentés sous forme de listes, de tableaux …• Les opérations sont complètement qualifiées ; on précise leur visibilité.• La navigation doit être mentionnée.
Pour ces 2 derniers points, il est nécessaire de répartir les responsabilités entre les différents objets. On a recours aux diagrammes de séquence.
181
Diagrammes de séquence.
:LeSystème
:Acteur
Action1()
retour
:Acteur
Action1()
retour
:Dialogue :Contrôle :Métier
Opération1()
GetDonnées()
182
Le cas bibliothèque : diag de séquence - retour Anonyme
:Bibliothécaire
EnregistrerRetour(Num))
RetourAnonyme CtrRetourAnonyme L: Livre SonEmp:Personne
EnregistrerRetour(Num)
Afficher(Titre)
TrouverLivres(Num)
SupprimerEmprunt()
getTitre()
Titre
RetirerLivre(self)
RetirerEmprunteur()
L
183
Le cas bibliothèque : diag de séquence - retour Étudiant
:Bibliothécaire
AffTitreLivre(num)
RetourEtudiant CtrRetourEtudiant P : Personne L:Livre
AffTitreLivre(Num)
TrouverEtud(num)
getNom()
getTitre()
Livre-dial
Titre
Nom
{Titre}
Afficher(Nom)
AffTitreLivre()
Créer(Titre)
Pour chaque livre L...
Pour chaque livre de la liste établie.
P
184
Le cas bibliothèque : diag de séquence - retour Étudiant
:Bibliothécaire
Sélectionner(L:Livre)
CtrRetourEtudiant L: Livre SonEmp:Personne
Sélectionner()
Livre-dial
RetirerLivre(self)
RetirerEmprunteur()
SupprimerEmprunt()
185
Quelques règles générales de présentation des diagrammes
• Disposer les éléments de façon à éviter que les lignes se croisent.
• Organiser les éléments de façon à ce que les éléments proches du point de vue sémantique soient également proches du point de vue physique.
• Ne JAMAIS présenter un diagramme et les commentaires s’y rapportant en recto-verso.
• Ne JAMAIS présenter des diagrammes se rapportant au même problème sur des pages recto-verso.
186
Quelques règles de définition du diagramme de classes
• Nommer les attributs avec des noms courts ou des petites expressions nominales qui représentent une des propriétés de la classe.
• Nommer les opérations avec des verbes courts ou de petites expressions verbales qui représentent certains comportements de leur classe englobante.
• Les noms de classes sont notés en majuscules : PERSONNE.
• Les noms d’attributs, d’opérations, de rôles commencent par une majuscule et les noms composés sont accolés, chacun commençant par une majuscule : DateDeNaissance.
• En règle générale les attributs sont privés et les opérations publiques.
187
Règles de définition du diagramme de classes (suite)
• Les opérations seront notées sous la forme :NomOpération(liste de paramètres) : type résultat
Ex : RechercherProduit(Code : integer) : PRODUITSauf consigne particulière on précisera paramètres et type de retour.
• On ne met JAMAIS en paramètre l’objet qui contient l’opération.
• Les opérations qui permettent d ’accéder aux attributs sont de la forme GetAttribut(). Ex : GetNom() : string (… mais CalcPrixTTC() : real )
• Les opérations qui permettent de modifier un attribut sont de la forme SetAttribut(paramètre). Ex : SetAdresse (A : string)
188
Règles de définition du diagramme de classes (suite)
• Les noms des rôles avec cardinalité 0..1 ou 1 commencent par Son ou Sa (Ex : SonPropriétaire, SaForme).
• Les noms des rôles avec cardinalité 0..* ou 1..* commencent par Ses (Ex : SesPropriétés).
• La navigabilité sera explicitée (flèche dans un ou deux sens).
189
Règles de définition des diagrammes de séquence
• Les opérations mises en évidence sur les diagrammes de séquence doivent figurer sur le diagramme de classes. On vérifiera que les paramètres sont cohérents entre les deux diagrammes.
• Les opérations seront précisées avec les paramètres (noms de variable plutôt que types de variables).
• Les messages de retour seront précisés dans la mesure du possible.
Notation : la répétition d ’information sera indiquée avec des accolades
{date + { titre + quantité }}
190
Règles de définition des diagrammes de séquence (suite)
• Lorsqu’un message est adressé à plusieurs instances I d’une même classe, on le mentionne dans une note associée au message.
Cette note est de la forme :
‘ Pour chaque instance I prise dans l’ensemble des instances ’
et le message est adressé à une instance nommée I.
• On privilégie les diagrammes de séquence de type décentralisé ou en escalier.
• On évite les conditions ; si besoin on fait 2 diagrammes de séquence.
191
Règles de définition des diagrammes d’états
• Les noms des événements de transition et les noms des événements internes (derrière le mot clef on ) sont des noms d’opérations publiques de l’objet pour lequel est fait le diagramme d’état.
• Les opérations effectuées en entrée ou en sortie d’un état, et les opérations effectuées au sein d’une activité sont des opérations privées de l’objet pour lequel est fait le diagramme d’état.
• Toutes ces opérations doivent figurer sur le diagramme de classes avec visibilité (public/privé) et paramètres cohérents entre les deux diagrammes.
192
Attributs et opérations implicites (4)
ETUDIANT
Nom : string
ETUDIANT
Nom : stringSesVoeuxDOptions : liste(OPTION)
<modificateur>AjouterOption(OPTION):boolEnleverOption(OPTION):boolGetSesOptions() : liste(OPTION)
OPTION
Libellé : string
SesVoeuxDOptions
0..*{ordonné}
L’introduction de la contrainte{ordonné}
permet de traiter SesVoeuxDOptioncomme une liste
193
Diagramme de déploiement : exemple des portes (diagramme de spécification)
Serveur
SGBD
PC
Pilote
Portes
TX
RNIS
1
*
TCP/IP
Console
3 1
Maître
1
1..10
Imprimante
1
1
194
Diagramme de déploiement : exemple des portes (diagramme d’instances)
PC4 : PC
P2 :PorteP3 : Porte
P1 : Porte
Remarque : les instances sont soulignées.
195
La CBM (Computer Books by Mail) est une sociétéde distribution d'ouvrages d'informatique qui agitcomme intermédiaire entre les librairies et leséditeurs. Elle prend des commandes en provenancedes libraires, s'approvisionne (à prix réduit) auprèsdes éditeurs concernés et livre ses clients à réceptiondes ouvrages. Il n'y a donc pas de stockage. Seulesles commandes des clients solvables sont prises encompte.
Exemple de base
196
Le design pattern : State
ConcreteStateB
+Handle()
Context
+request(…)
ConcreteStateA
+Handle()
état
*
State
+Handle()1
197
198
199
200
U.M.L.
Unified Modeling Language
(3ème partie)
Françoise Schlienger
FIIFO4 2003-2004
201
Plan de la troisième partie
• Les diagrammes d’activités 139
• Les diagrammes de composants 149
• Les diagrammes de déploiement 153
• De l’analyse … à la conception 159
202
Booch
Unified MethodUnified Method0.8
etc...
OOSE(Jacobson et al.)
UML 0.9UML 0.9
1996
etc.ROOMCatalysis
OMGOMG
UML 1.1UML 1.1
Nov. 1997Nov. 1997
UML 1.3UML 1.3
UML 1.4UML 1.4
UML 2.0UML 2.0
Juin 1999Juin 1999
FinFin 200 20011
……
HOOD
OMT (Rumbaugh et al.)
1995
RationalRational
ROOM
Classe-Relation
Fusion
OOSE
Booch
OMT
Fin 1990