Uml

UML

Unified Modeling Language

Réalisé par :

mohammed.zaoui11@gmail.com
https://www.facebook.com/groups/ISP.2011/

Créé le : mercredi ‎ 1 ‎ ars ‎ 009
1 m 2

UML : Introduction

UML offre une manière élégante de représenter le système
selon différentes vues complémentaires grâce aux diagrammes.
Lorsqu'une entreprise désire un logiciel, elle le réalise parfois
en interne, mais le fait plus généralement réaliser par une
société de services. Dans un cas comme dans l'autre il est
nécessaire de définir l'ensemble des fonctionnalités que le
logiciel doit possèder. Le demandeur du logiciel n'a parfois pas
de compétences particulières en informatique et exprime donc
ses souhaits sous forme d'un CdCF (Cahier des Charges
Fonctionnelles), c'est-à-dire un document décrivant sous forme
textuelle l'ensemble des particularités que le logiciel doit
possèder, les conditions qu'il doit remplir (système(s)
d'exploitation visé(s)), les écueils à éviter, ainsi que les délais
impartis, éventuellement des clauses sur le coût, les langages à
utiliser, ...

UML : Introduction (suite)

Le CdCF est ainsi distribué à différentes sociétés de
services (dans le cas d'une sous-traitance) sous forme
d'un appel d'offre, auquel les sociétés vont répondre
par un coût, un délai, ...
Lorsqu'une société obtient le marché et qu'elle décide
(si elle a le choix) d'opter pour un langage orienté
objet, il lui faut dans un premier temps créer un
modèle (c'est là qu'intervient UML) à fin:
• de présenter au client la façon de laquelle elle
compte développer le logiciel.
• d'accorder tous les acteurs du projet.

UML : Caractéristiques

 UML (Unified Modeling Language, que l'on peut traduire par
"langage de modélisation unifié) est une notation permettant
de modéliser un problème de façon standard. Ce langage est
né de la fusion de plusieurs méthodes existant auparavant,
et est devenu désormais la référence en terme de
modélisation objet, à un tel point que sa connaissance est
souvent nécessaire pour obtenir un poste de développeur
objet.
 UML n‟est pas une méthode: UML est un langage qui permet
de représenter des modèles, mais il ne définit pas le
processus d'élaboration des modèles. Qualifier UML de
"méthode objet" n'est donc pas tout à fait approprié.

UML : Caractéristiques (suite)

 UML est un support de communication: UML est avant tout
un support de communication performant, qui facilite la
représentation et la compréhension de solutions objet.
 UML est basé sur un méta-modèle: UML est un moyen
d'exprimer des modèles objet en faisant abstraction de
leur implémentation, c'est-à-dire que le modèle fourni par
UML est valable pour n'importe quel langage de
programmation. UML est un langage qui s'appuie sur un
méta-modèle, un modèle de plus haut niveau qui définit les
éléments d'UML (les concepts utilisables) et leur
sémantique (leur signification et leur mode d'utilisation).

UML : Diagrammes (définition)

 Un diagramme UML est une représentation graphique, qui
s'intéresse à un aspect précis du modèle. C'est une
perspective du modèle, pas "le modèle".
 Chaque type de diagramme UML possède une structure (les
types des éléments de modélisation qui le composent sont
prédéfinis).
 Un type de diagramme UML véhicule une sémantique précise
(un type de diagramme offre toujours la même vue d'un
système).
 Combinés, les différents types de diagrammes UML offrent
une vue complète des aspects statiques et dynamiques d'un
système.
 Par extension et abus de langage, un diagramme UML est
aussi un modèle (un diagramme modélise un aspect du modèle
global).

UML : Diagrammes (types)

 Il existe 2 types de vues du système qui comportent chacune
leurs propres diagrammes :
- les vues statiques :
o diagrammes de cas d'utilisation
o diagrammes d'objets
o diagrammes de classes
o diagrammes de composants
o diagrammes de déploiement
- les vues dynamiques :
o diagrammes de collaboration
o diagrammes de séquence
o diagrammes d'états-transitions
o diagrammes d'activités

UML : Unified Modeling Language

Diagramme
des cas d’utilisation

Diagramme des cas d’utilisation: Définition

 Les cas d‟utilisation(use cases)permettent de structurer les
besoins des utilisateurs et les objectifs correspondants d'un
système. Ils centrent l'expression des exigences du système
sur ses utilisateurs : ils partent du principe que les objectifs
du système sont tous motivés.
 Description de l‟interaction entre l‟utilisateur et le système
 Une fois identifiés et structurés, ces besoins :
- définissent le contour du système à modéliser (ils précisent
le but à atteindre),
- permettent d'identifier les fonctionnalités principales
(critiques) du système.

Diagramme des cas d’utilisation: Acteur

 L’acteur: Un acteur représente un rôle joué par une personne
ou une chose qui interagit avec le système. (la même personne
physique peut donc être représentée par plusieurs acteurs en
fonction des rôles qu‟elle joue).
un acteur n‟est pas nécessairement une personne physique : il
peut être un service, une société, un système informatique …
 Il existe 4 catégories d‟acteurs :
- les acteurs principaux : les personnes qui utilisent les
fonctions principales du système
- les acteurs secondaires : les personnes qui effectuent des
tâches administratives ou de maintenance.
- le matériel externe : les dispositifs matériels
incontournables qui font partie du domaine de l‟application et
qui doivent être utilisés.
- les autres systèmes : les systèmes avec lesquels le système
doit interagir.

Diagramme des cas d’utilisation: Acteur (suite)

 Un acteur se représente par un petit bonhomme avec son nom
(son rôle) inscrit au dessous.
 Il est également possible de représenter un acteur sous la
forme d‟un classeur stéréotypé << actor >>

Diagramme des cas d’utilisation: Le cas d’utilisation
 Le cas d’utilisation: Le cas d‟utilisation (ou use case) correspond
à un objectif du système, motivé par un besoin d‟un ou plusieurs
acteurs. L'ensemble des use cases décrit les objectifs (le but) du
système.
Un cas d‟utilisation se représente par une ellipse contenant le
nom (un verbe à l‟infinitif) et optionnellement, au dessous du nom
un stéréotype .
Dans le cas ou l‟on désire présenter les attributs ou les
opérations du cas d‟utilisation,il est préférable de le représenter
sous la forme d‟un classeur stéréotypé <<use case>>.Nous
reviendrons sur les notions d‟attributs et d‟opérations lorsque
nous traiterons les diagrammes de classes et d‟objets.

Diagramme des cas d’utilisation: Exemples

Exemple 1 Exemple 2

Diagramme des cas d’utilisation: Exemples

Exemple 3 Exemple 4

Diagramme des cas d’utilisation: La relation

 Elle exprime l‟interaction existant entre un acteur et un cas
d‟utilisation.
 Il existe 3 types de relations entre cas d‟utilisation :
- la relation de généralisation
- la relation d‟extension
- la relation d‟inclusion
1. La relation de généralisation:
Dans une relation de généralisation entre 2 cas d‟utilisation,
le cas d‟utilisation enfant est une spécialisation du cas
d‟utilisation parent.

Diagramme des cas d’utilisation: La relation (suite)

 NB : un acteur peut également participer à des relations de
généralisation avec d‟autres acteurs. Les acteurs « enfant »
seront alors capables de communiquer avec les mêmes cas
d‟utilisation que les acteurs « parents ».


2. La relation d’inclusion:
Elle indique que le cas d‟utilisation source contient aussi le
comportement décrit dans le cas d‟utilisation destination. Cette
relation permet ainsi de décomposer des comportements et de
définir des comportements partageables entre plusieurs cas
d‟utilisation.
Cette dépendance est symbolisée par le stéréotype <<include>>

Pour réaliser l‟objectif
<<virement», on utilise
obligatoirement
«identification ».


3. La relation d’extension:
Elle indique que le cas d‟utilisation source ajoute son
comportement au cas d‟utilisation destination. L‟extension peut
être soumise à condition. Le comportement ajouté est inséré au
niveau d‟un point d‟extension défini dans le cas d‟utilisation
destination. Cette relation permet de modéliser les variantes
de comportement d‟un cas d‟utilisation (selon les interactions
des acteurs et l‟environnement du système).
Cette dépendance est symbolisée par le stéréotype <<extend>>


Exemple :

Diagramme des cas d’utilisation: Les scénarios

 Un cas d‟utilisation est une abstraction de plusieurs chemins
d‟exécution. Une instance de cas d‟utilisation est appelée : «
scénario ».
 Chaque fois qu‟une instance d‟un acteur déclenche un cas
d‟utilisation, un scénario est créé (le cas d‟utilisation est
instancié). Ce scénario suivra un chemin particulier dans le cas
d‟utilisation.
 Les scénarios peuvent être classés en :
- scénarios principaux : il correspond à l‟instance principal du
cas d‟utilisation. C‟est souvent le chemin « normal »
d‟exécution du cas d‟utilisation qui n‟implique pas d‟erreurs.
- Scénarios secondaires : il peut être un cas alternatif (un
choix), un cas exceptionnel ou une erreur.


Diagramme
de classes

Diagramme de classes : Définition

 Le diagramme de classes exprime la structure statique du
système en termes de classes et de relations entre ces
classes.
 L‟intérêt du diagramme de classe est de modéliser les
entités du système d‟information.

CLASSE OBJETS

Maison 234 Des érables
$180 000
Adresse
1986 50 Laurier
Valeur
$150 000
Date construction
1959 765 Bellevue
$210 000
1996
...

Diagramme de classes : La notion de classe

 une classe est une description abstraite (condensée) d‟un ensemble
d‟objets du domaine de l‟application : elle définit leur structure,
leur comportement et leurs relations.
 Représentée par un rectangle comprenant 3 compartiments: le
nom, les attributs et les opérations.
 Les compartiments non pertinents peuvent ne pas être affichés

Nom de classe Nom de classe Nom de classe
Attribut 1 Attribut 1
Attribut 2 Attribut 2
Opération 1
Opération 2

Diagramme de classes : Stéréotypes

 UML définit les stéréotypes de classe suivants :

- « classe implémentation » : il s’agit de l’implémentation d’une
classe dans un langage de programmation.
- « énumération » : il s’agit d’une classe qui définit un ensemble
d’identificateurs formant le domaine de la valeur.
- « métaclasse » : il s’agit de la classe d’une classe, comme en
Smalltalk.
- « powertype » : une classe est un métatype : ses instances sont
toutes des sous-types d’un type donné.
- « processus » : il s’agit d’une classe active qui représente un
flot de contrôles lourd.
- « thread » : il s’agit d’une classe active qui représente un flot
de contrôles léger.
- « type » : il s’agit d’une classe qui définit un domaine d’objets
et les opérations applicables à ces objets.
- « utilitaire » : il s’agit d’une classe réduite au concept de
module et qui ne peut être instanciée.

Diagramme de Classes : La notion d’attribut
 Une classe correspond à un concept global d‟information et se
compose d‟un ensemble d‟informations élémentaires, appelées
attributs de classe.
 Un attribut représente la modélisation d‟une information
élémentaire représentée par son nom et son format.
 Caractéristique d‟une classe d‟objets.
 Syntaxe: Visibilité Nom_attribut : Type_Attribut = Valeur_Initiale
 Visibilité: définie en trois niveaux:
+ :public, visible par toutes les classes;
# :protégé, visible par les classes amies et classes dérivées;
- :privé, visible seulement par les classes amies;
 Dérivé (/): attribut obtenu par le traitement d‟autres attributs.

Rectangle
+ longueur : /Surface = longueur * largeur

entier
+ largeur: entier

Diagramme de Classes : La notion d’opération

 L‟opération représente un élément de comportement des objets,
défini de manière globale dans la classe.
 Une opération est une fonctionnalité assurée par une classe. La
description des opérations peut préciser les paramètres d‟entrée et
de sortie ainsi que les actions élémentaires à exécuter.
 Syntaxe:
Visibilité Nom_Opération.
La classe rectangle contient les
Rectangle attributs longueur et largeur et
+ Longueur: entier l’opération surface qui
+ Largeur: entier encapsule le calcul de surface
obtenu avec la longueur et la
+ Surface largeur du rectangle.
(longeur:entier * largeur:entier)
: entier

Diagramme de Classes : Association

 Représente des relations structurelles entre classes d‟objets.
 Représentée par une forme verbale, active ou passive, en italique au milieu
de la ligne qui symbolise l‟association.
 Le sens de lecture du nom est indiqué par un petit triangle dirigé vers la
classe désignée par la forme verbale.

 Peut être représentée < habite
par des traits
est habitée par >
Maison Personne
rectilignes ou obliques. < possède
est possédée par >
 Il peut y avoir deux ou
plusieurs associations
de nature différente
entre les deux mêmes
classes.
< est mariée à
est mariée à >
 Peut être récursive,
i.e. qui affecte une Personne
seule classe.

Diagramme de Classes : Le rôle

 Le rôle est l’extrémité d’une association qui décrit comment une
classe en voit une autre à travers une association.
 Il est placé à l’extrémité d’une association sans être en italique.

< habite habitant

Maison habitation est habitée par > Personne

parent
Personne

enfant

Diagramme de Classes : Classe-association

 On ajoute une classe-association à une association lorsqu‟elle a
des attributs ou des opérations.
 Une classe de ce type est une classe comme les autres et peut
participer à d‟autres relations dans le modèle.

Diagramme de Classes : Association n-aire

•Relations entre plus de 2 classes (à éviter si possible)

Diagramme de Classes : La multiplicité des associations

 La multiplicité définit le nombre d‟instances de l‟association
pour une instance de la classe. La multiplicité est définie par
un nombre entier ou un intervalle de valeurs. La multiplicité
est notée sur le rôle (elle est notée à l‟envers de la notation
MERISE).
 Indique le nombre minimum et maximum d‟objets de la classe
qui peuvent être liés à un objet de l‟autre classe.
 Une association possède deux cardinalités.

Exemple:

 Une personne travaille pour 0 à plusieurs sociétés (*) et une
société est employeur de 1 à plusieurs personnes (1..*).
 Pour un emploi donné, un patron dirige de zéro à plusieurs
travailleurs (0 ..*) et un travailleur est dirigé par zéro à un
patron (0..1).

Société < Travaille pour 1..*
Personne
*
employeur employé
Emploi patron
Salaire 0..1

travailleur 0..* <Dirige

Diagramme de Classes : Contraintes sur les associations

 Peut affecter une relation ou un groupe de relations.
 Chaîne de caractères entre accolades { } positionnée sur
l‟association affectée ou entre les associations affectées.

Diagramme de Classes : Agrégation

 Association non symétrique dans laquelle une des extrémités joue
un rôle prédominant par rapport à l‟autre extrémité (agrégat).
Les deux classes existent indépendamment, c‟est-à-dire qu‟elles
“survivent” à la “destruction” de l‟autre classe.
 Ne concerne qu‟un seul rôle de l‟association.
 Symbolisé par un losange vide du côté de l‟agrégat.

Symbole d’agrégation

Diagramme de Classes : Composition

 La composition est un cas particulier de l‟agrégation dans
laquelle la vie des composants est liée à celle des agrégats.
 Association symétrique entre deux classes dont une classe
(partie) compose l‟autre (composite). Les deux classes sont
dépendantes, c‟est-à-dire que la partie “ne survit pas” à la
“destruction” du composite.
 Symbolisée par un losange plein du coté du composite.

Symbole de composition

Diagramme de Classes : Agrégation/Composition

Exemple 1:
< fait partie de 1,1 < compose de 0,N
Livre Page Mot
comprend de 1,N > comprend de 1,N >

Exemple 2:

Diagramme de Classes : Généralisation/Spécialisation

 Le principe de généralisation / spécialisation permet d‟identifier
parmi les objets d‟une classe (générique) des sous-ensembles d‟objets
(des classes spécialisées) ayant des définitions spécifiques. La classe
plus spécifique (appelée aussi classe fille, classe dérivée, classe
spécialisée, classe descendante …) est cohérente avec la classe plus
générale (appelée aussi classe mère, classe générale …), c‟est-à-dire
qu‟elle contient par héritage tous les attributs, les membres, les
relations de la classe générale, et peut contenir d‟autres.

 - La généralisation : il s‟agit de prendre des classes existantes déjà
mises en évidences) et de créer de nouvelles classes qui regroupent
leurs parties communes ; il faut aller du plus spécifique au plus
général.
- La spécialisation : il s‟agit de sélectionner des classes existantes
(déjà identifiées) et d‟en dériver des nouvelles classes plus
spécialisées, en spécifiant simplement les différences.

Diagramme de Classes : Généralisation multiple

 Les classes peuvent avoir plusieurs superclasses ; dans ce
cas, la généralisation est dite multiple et plusieurs flèches
partent de la sous-classe vers les différentes superclasses.
La généralisation multiple consiste à fusionner plusieurs
classes en une seule classe.

Diagramme de Classes : Contraintes de généralisation

Diagramme de Classes : Classe abstraite

 Classe sans instance immédiate
 Super-classe non instanciable directement, i.e. qui ne
donne pas naissance à des objets mais sert de concept
plus général pour les sous-classes.
 Elle s‟applique uniquement pour la généralisation et jamais
pour la spécialisation.

Diagramme de Classes : Dépendance

 Les relations de dépendance sont utilisées lorsqu‟il existe une
relation sémantique entre plusieurs éléments qui n‟est pas de
nature structurelle. Une relation de dépendance définit une
relation unidirectionnelle entre un élément source et un
élément cible.
 Une dépendance est une relation entre deux éléments de
modélisation dans laquelle toute modification effectuée sur un
élément de modélisation (l'élément influent) affecte l'autre
élément (élément dépendant).
 UML définit 4 types de relation de dépendance. Pour chaque
type de dépendance, un mot clé ou stéréotype entre guillemets
peut être ajouté à la relation de dépendance pour préciser sa
nature.

Diagramme de Classes : Dépendance (suite)

Les 4 types de relation sont :
 Abstraction :Il s‟agit d‟une relation de dépendance entre éléments qui représentent
un même concept à différents niveaux d‟abstraction ou selon des points de vue
distincts.
 Les mots-clés sont :
o « « dérive » » : représente un élément défini ou calculé à partir d‟un autre. Par
exemple, un attribut ou un rôle peut dériver d‟autres attributs ou rôles.
o « « raffine » » : représente une relation de dépendance entre des éléments
sémantiques différents (analyse et conception par exemple).
o « « réalise » » : représente une relation de dépendance entre une spécification
(cible) et l‟élément qui implémente cette spécification (source).
o « « trace » » : représente l‟historique des constructions présentes dans les
différents modèles.
 Liaison : Les paramètres formels d‟une classe ou collaboration paramétrables
doivent être liés à des valeurs.
 Le mot clé est :
o « « lie » »

Diagramme de Classes : Dépendance (suite)

 Permission: Un élément (source) a le droit d‟accéder à un espace de
nommage (cible)
o « « ami » »: Représente un élément source (paquetage, classe, opération …)
qui a accès à l‟élément destination (paquetage, classe, opération …) quelle
que soit la spécification de visibilité de ce dernier.
 Utilisation: Un élément (source) requiert la présence d‟un autre élément
(cible) pour son bon fonctionnement ou son implémentation.
o « « utilise » »
o « « appelle » »
Représente une relation de dépendance entre une opération
qui invoque une opération d‟une autre classe. Cette relation
est représentée en connectant les opérations ou les classes
qui possèdent ces opérations.
o « « crée » »: Représente le classificateur source qui crée
une instance du classificateur cible.
o « « instancie » »: Représente une relation de dépendance
entre classificateurs due à la création d‟une instance du
classificateur cible par une opération du classificateur source.

Exemple

Diagramme de Classes : L’interface
 Une interface définit le comportement visible d‟une classe. Ce
comportement est défini par une liste d‟opérations ayant une
visibilité « public ». Aucun attribut ou association n‟est défini pour
une interface.
 Une interface est en fait une classe particulière (avec le
stéréotype « « interface » »).
 UML représente les interfaces :
 - soit au moyen de petits cercles reliés par un trait à l‟élément qui
fournit les services décrits par l‟interface
 - soit au moyen de classes avec le mot clé « « interface » ». Cette
notation permet de faire figurer dans le compartiment des
opérations la liste des services de l‟interface.
L’exemple illustre la modélisation
de 2 interfaces crédit et
assurance d’une classe banque.
Une relation de réalisation
indique que la classe banque
réalise l’interface assurance.

Diagramme de Classes : Package

 Mécanisme général pour la
partition des modèles et le
regroupement des éléments de
modélisation
 Est représenté graphiquement Nom du
par un dossier package
 Correspond à un sous-ensemble
du modèle

Diagramme de Classes : Package (suite)

 Peut contenir entre autre des classes, des objets, des
relations et d‟autres paquetages, sans limite du niveau
d‟emboîtement.
 Les relations possibles entre paquetages sont les
dépendances et les généralisations.

Paquetage racine

Classe
Dépendance

Généralisation
Sous-paquetage

Diagramme de Classes : Package (suite)

 Une classe contenue par un paquetage peut également
apparaître dans un autre paquetage sous la forme d‟un
élément importé. Cela crée une relation de dépendance
indiquée par le sens de la flèche.

Limites Administratives Socio-économique
<<import>>
Ville LA::Ville

classe importée

Diagramme de classes : Étude de cas
























Soit le cas ’’Réservation de vols dans une agence de voyage’’























1° Des compagnies aériennes proposent différents vols.




















2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.


















3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.
















4° Une réservation concerne un seul vol, et un seul passager.














5° Une réservation peut être annulée ou confirmée.












6° Un‎vol‎a‎un‎aéroport‎de‎départ‎et‎un‎aéroport‎d’arrivée.










7° Un‎vol‎a‎un‎jour‎et‎une‎heure‎de‎départ‎et‎un‎jour‎et‎une‎heure‎d’arrivée.








8° Un vol peut comporter des escales dans des aéroports.






9° Une‎escale‎a‎une‎heure‎d’arrivée‎et‎une‎heure‎de‎départ.




9° Une‎escale‎a‎une‎heure‎d’arrivée‎et‎une‎heure‎de‎départ.
10° Chaque aéroport dessert une ou plusieurs villes.

 Modélisation de la phrase :


CompagnieAerienne et Vols sont 2 objets métiers : 2 classes



CompagnieAerinne Propose Vol
1..*



1..*

• Un vol est réalisé par une seule compagnie mais partagé par plusieurs affréteurs



1..*

• Un vol est réalisé par une seule compagnie mais partagé par plusieurs affréteurs

1..* 1..*
affréteur


1..* 1..*
état (ouvert, fermé)
affréteur


1..* 1..*
affréteur

 Tout objet peut avoir un état (diagramme d‟états).
 Dans un diagramme de classes tout concept dynamique est modélisé en opération.

 Il faut représenter la 2° phrase par 2 opérations : ouvrirReservation( ) et fermerReservation( )
 Dans quelle classe ? Responsabilité d‟une classe


1..* 1..*
affréteur



1..* 1..*
affréteur
ouvrirVol( )
fermerVol( )


1..* 1..*
affréteur



1..* 1..*
affréteur
ouvrirVol( )
fermerVol( )

 Les opérations sont déclarées dans l‟objet dans lequel elles doivent s‟exécuter
 Les autres pourront déclencher ces opérations par envoi de messages
 Le classe CompagnieAerienne a une association avec la classe vol.

 Modélisation des phrases :

Réservation
Client 1 a effectué 0..*
concerne Vol
Annuler( ) 0..* 1
Confirmer( )

0..*
concerne

1
Passager


 Il faut discerner un client d‟un passager

Réservation
Client 1 a effectué 0..*
concerne Vol
Annuler( ) 0..* 1
Confirmer( )

0..*
concerne

1
Passager


 La réservation et le passager sont 2 concepts métier : 2 classes d‟objets
 Un réservation concerne un seul vol et un seul passager: donc 2 associations entre „‟Vol’’ et
‟‟Réservation’’ et entre ’’Réservation’’ et „‟Passager’’.
 La 5° phrase se traduit par l‟ajout de 2 opérations annuler( ) et confirmer( ) dans ‘’Reservation’’.


 La réservation et le passager sont 2 concepts métier : 2 classes d‟objets
 Un réservation concerne un seul vol et un seul passager: donc 2 associations entre „‟Vol’’ et
‟‟Réservation’’ et entre ’’Réservation’’ et „‟Passager’’.
 La 5° phrase se traduit par l‟ajout de 2 opérations annuler( ) et confirmer( ) dans ‘’Reservation’’.

Réservation Vol
concerne dateDepart
heureDepart
Annuler( ) 1 dateArrivee
Confirmer( ) heureArrivee

ouvrirVol( )
fermerVol( )
concerne

1

Passager

6° Un vol a un aéroport de départ et un aéroport d’arrivée.


 Par quoi peut-on représenter l‟élément „‟Aéroport‟‟ ?
3 réponses sont envisageables :



1. Soit avec une classe et une association de multiplicité 2



1. Soit avec une classe et une association de multiplicité 2

Vol
dateDepart Aéroport
heureDepart 2
dateArrivee nom
{ ordered}
heureArrivee
aeroportDepart
aeroportArivvee

ouvrirVol( )
fermerVol( )

 Modélisation peu parlante.


2. Soit avec 2 classes


2. Soit avec 2 classes

Vols
dateDepart 1 AeroportDepart
heureDepart
dateArrivee Aéroport
heureArrivee
nom
aeroportDepartr 1
aeroportArivvee AeroportArrivee

ouvrirReservation( )
fermerReservation( )

 Modélisation non correcte. Tout aéroport peut être de départ et d‟arrivée.


2. Soit avec 2 associations


2. Soit avec 2 associations

Vol
dateDepart Départ
Aéroport
heureDepart
dateArrivee 1 Nom
heureArrivee …
Arrivée

1
ouvrirVol( )
fermerVol( )

 Le rôle de chaque association précise son sens.

7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.


 Les dates et les heures de départ et d‟arrivée ne représentent que des valeurs : attributs.



1..* 1..*
dateDepart
affréteur heureDepart
dateArrivee
heureArrivee

ouvrirVol( )
fermerVol( )



1..* 1..*
dateDepart
affréteur heureDepart
dateArrivee
heureArrivee

ouvrirVol( )
fermerVol( )

 Pour savoir si un élément doit être représenté en attribut ou en objet :
 S‟il n‟ y a que sa valeur qui est intéressante : c‟est plutôt un attribut.
 Si plusieurs questions peuvent concerner l‟élément, alors il faut le représenter en objet.

9° Une escale a une heure d’arrivée et une heure de départ.


 Une escale a les propriétés heure d‟arrivée et heure de départ, c‟est donc un objet.



Vol
dateDepart Depart Aéroport
heureDepart
dateArrivee 1 nom
heureArrivee
Arrivee
ouvrirVol( )
fermerVol( ) 1

Escale

heureArrivee
heureDepart
0..*



Vol
heureDepart
dateArrivee 1 nom
heureArrivee
Arrivee
ouvrirVol( )
fermerVol( ) 1

 Quelles sont alors les multiplicités entre Escale
„’Vols’’ et „’Escale’’, entre „’Escale’’ et heureArrivee
‘’Aeroport’’ et entre ‘’Aeroport’’ et ’Vols’’ ? heureDepart
0..*



Vol
heureDepart
dateArrivee 0..* 1 nom
heureArrivee
Arrivee
ouvrirVol( )
fermerVol( ) 0..* 1
1
1..*

 Quelles sont alors les multiplicités entre Escale
„’Vols’’ et „’Escale’’, entre „’Escale’’ et heureArrivee
‘’Aeroport’’ et entre ‘’Aeroport’’ et ’Vols’’ ? heureDepart
0..* 0..*







 „’Escale’’ a peu d‟informations propres. Elle n‟est qu‟une partie de ’’Vol’’ .




 On peut la représenter comme une spécialisation de ’’Aéroport’’ . Mais elle n‟est pas totalement un aéroport.



 La meilleure solution serait de la modéliser comme une classe d‟association entre et ’Vols’’ et ‘’Aéroport’’.


 La meilleure solution serait de la modéliser comme une classe d‟association entre et ’Vols’’ et ‘’Aéroport’’.

Vol Départ
dateDepart Aéroport
heureDepart 0..* 1
dateArrivee Arrivée nom
heureArrivee
0..* 1
ouvrirVol( )
fermerVol( ) Escale

0..* 0..*
{Ordered}
Escale

heureArrivee
heureDepart


 On ne peut pas savoir la multiplicité de „’Aéroport’’



Aéroport dessert Ville

1..*




0..* 1..*




0..* 1..*

 Si on considère que desservir une ville signifie l‟aéroport le plus proche, il n‟ en y a qu‟un :
la multiplicité est de 1
 Si on considère que desservir une ville signifie les aéroports dans un rayon de 35 km :
la multiplicité est de 0..*

Client
nom Prénom CompagnieAerinne
adresse
nom
téléphone
e-mail
1..*
Propose
1
a effectué
0..* 1..*
départ
Réservation Vol Aéroport
dateDepart 0..* 1
date concerne heureDepart nom
arrivée
numéro dateArrivee
0..* 1
Annuler( ) heureArrivee 0..* 1
Confirmer( )
ouvrirVol( ) escale
0..* fermerVol( )
0..* 0..*
concerne
{ordered}

1 InfosEscale
Passager heureArrivee Ville
heureDepart nom
nom Prénom

 Le diagramme des classe complet est :
Client
adresse
nom
téléphone
e-mail
1..*
Propose
1
a effectué
0..* 1..*
départ
dateDepart 0..* 1
arrivée
numéro dateArrivee
0..* 1
Annuler( ) heureArrivee 0..* 1
Confirmer( )
ouvrirVol( ) escale
0..* fermerVol( )
0..* 0..*
concerne
{ordered}

1 InfosEscale
heureDepart nom
nom Prénom

Client
adresse nom
tél
e-mail
numéro
1..*
{frozen} 1 Propose
a effectué
0..* 0..1
départ
dateDepart 0..* 1
arrivée
numéro dateArrivee
0..* 1
heureArrivee 0..* 1
Annuler( ) {frozen}
Confirmer( ) ouvrirVol( ) escale
0..* fermerVol( )
0..* 0..*
concerne
{ordered}

1 InfosEscale
heureDepart nom
nom Prénom

 Diagramme des classe complet et annoté:
Client
adresse nom
tél
e-mail
numéro
1..*
{frozen} 1 Propose
a effectué
0..* 0..1
départ
dateDepart 0..* 1
arrivée
numéro dateArrivee
0..* 1
heureArrivee 0..* 1
Annuler( ) {frozen}
Confirmer( ) ouvrirVol( ) escale
0..* fermerVol( )
0..* 0..*
concerne
{ordered}

1 InfosEscale
heureDepart nom
nom Prénom

Client
CompagnieAérienne
nom Prénom 1..*
nom
adresse Affréteur
téléphone
e-mail numéro
1
{frozen} 1 propose Propose
a effectué 0..1
0..* ‘’ métaclasse ‘’
départ
VolGenerique
Aéroport
Réservation 0..* jour 0..* 1
date concerne heureDépart arrivée nom
Vol heureArrivée
numéro
0..* 1 dateDépart /durée 0..* 1
périodevalidité
Annuler( ) {frozen} dateArrivée escale
Confirmer( ) ouvrirVol( )
ouvrirVol( ) fermerVol( )
0..* 0..*
0..* fermerVol( )
{ordered}
concerne {AddOnly} 0..* {frozen} 1
1 InfosEscale
Passager décrit heureArrivée Ville
heureDépart nom
nom Prénom

 Le diagramme des classe complet devient :
Client
CompagnieAérienne
nom Prénom 1..*
nom
adresse Affréteur
téléphone
e-mail numéro
1
a effectué 0..1
0..* ‘’ métaclasse ‘’
départ
VolGenerique
Aéroport
date concerne heureDépart arrivée nom
Vol heureArrivée
numéro
0..* 1 dateDépart /durée 0..* 1
périodevalidité
Annuler( ) {frozen} dateArrivée escale
0..* 0..*
0..* fermerVol( )
{ordered}
1 InfosEscale
Passager décrit heureArrivée Ville
heureDépart nom
nom Prénom

 Le diagramme des classes peut être réorganisé en packages:

 Le diagramme des classes peut être réorganisé en packages:
Client
1..*
nom
adresse Affréteur
tééphonel
e-mail numéro
1..*
a effectué 0..1
0..* ‘’ metaclasse „‟
départ
VolGenerique
Aéroport
date concerne heureDepart arrivée nom
Vol heureArrivee
numero
0..* 1 dateDepart /durée 0..* 1
periodevalidite
Annuler( ) {frozen} dateArrivee escale
0..* 0..*
0..* fermerVol( )
{ordered}
InfosEscale
1
décrit heureArrivee Ville
Passager heureDepart nom
nom Prénom

Réservations Vol

Réservation Vol
date dateDepart
numéro concerne dateArrivee
Annuler( )
0..* 1 ouvrirVol( )
Confirmer( )
{frozen} fermerVol( )

Réservations Vol

Réservation Vol
date dateDepart
numéro concerne dateArrivee
Annuler( )
0..* 1 ouvrirVol( )
Confirmer( )
{frozen} fermerVol( )

 Réduire la dépendance mutuelle afin d‟augmenter la modularité
et l‟évolutivité d‟une application

Réservations

Client
nom Prénom
adresse
téléphone
e-mail

{frozen} 1
a effectué
0..*

Réservation
date
numéro
Annuler( )
Confirmer( )

0..*
concerne

1
Passager
nom Prénom

Réservations Vol

Client
CompagnieAerinne
nom Prénom 1..*
nom
adresse Affréteur
téléphone
e-mail numéro
1
a effectué 0..1
0..* ‘’ metaclasse ‘’
départ
VolGenerique Aéroport
date heureDepart arrivée nom
Vol heureArrivee
numéro
dateDepart /durée 0..* 1
Annuler( ) dateArrivee periodevalidite
ouvrirVol( ) escale
Confirmer( )
ouvrirVol( ) fermerVol( ) 0..* 0..*
0..* fermerVol( ) {ordered}
InfosEscale
1
decrit heureArrivee Ville
nom Prénom

Réservations Vol

Client
CompagnieAerinne
nom Prénom 1..*
nom
adresse Affréteur
téléphone
e-mail numéro
1
a effectué 0..1
0..* ‘’ metaclasse ‘’
départ
VolGenerique Aéroport
Réservation concerne 0..* jour 0..* 1
date heureDepart arrivée nom
Vol heureArrivee
numéro 0..* 1
dateDepart /durée 0..* 1
Annuler( ) {frozen} dateArrivee periodevalidite
ouvrirVol( ) escale
Confirmer( )
ouvrirVol( ) fermerVol( ) 0..* 0..*
0..* fermerVol( ) {ordered}
InfosEscale
1
decrit heureArrivee Ville
nom Prénom

Généralisation et réutilisation


 On veut élargir ce domaine aux voyages par bus que des transporteurs assurent.
 Un voyage en bus à une ville de départ et un ville d‟arrivée avec des dates et
des heures associées.
 Un trajet peut comporter des arrêts dans des villes intermédiaires.
 Un client peut réserver un ou plusieurs voyages pour un ou plusieurs passagers


 On veut élargir ce domaine aux voyages par bus que des transporteurs assurent.
 Un voyage en bus à une ville de départ et un ville d‟arrivée avec des dates et
des heures associées.
 Un trajet peut comporter des arrêts dans des villes intermédiaires.
 Un client peut réserver un ou plusieurs voyages pour un ou plusieurs passagers

ReservationsBus
VoyagesBus

ReservationBus
VoyageEnBus
date
numéro
concerne dateDepart
dateArrivee
0..* 1
Annuler( )
Confirmer( ) {frozen} OuvrirVoyage( )
fermerVoyage( )

ReservationsBus VoyagesBus

Client
Voyagiste
nom Prénom
nom
adresse
téléphone
e-mail référence

1
{frozen} 1 Propose
a effectué 0..1
0..* VoyageEnBus départ
ReservationBus concerne dateDepart 0..* 1 Ville
date heureDepart arrivée
dateArrivee nom
numéro {frozen} heureArrivee 0..* 1
Annuler( ) /durée
ouvrirVoyage( ) arrêt
Confirmer( )
fermerVoyage( ) 0..* 0..*
0..*
{ordered}
concerne
InfosArret
1..*
heureArrivee
Passager heureDepart
nom Prénom

Fusion des 2 modèles

1. Il faut isoler les classes communes dans des packages
2. Il faut factoriser les propriétés communes







 AVION BUS

ReservationBus
ReservationVols

Vols VoyagesBus

Lieux

 Il faut isoler les classes communes dans des packages

 Il faut isoler les classes communes dans des packages
Classe
Réservations abstraite

Client Réservation concerne
nom Prénom a effectué Passager
date 0..* 1
adresse numéro
1 0..* nom Prénom
tél
Annuler( )
e-mail
{frozen} Confirmer( )

ReservationVol ReservationBus
(from ReservationsVols)
(from ReservationsBus)

concerne concerne
1 {frozen} 1 {frozen}
Vol VoyageEnBus
(from Vols) (from VoyagesBus)

Package généralisé
Réservations

Packages spécialisés

ReservationsBus ReservationsVols

Réservations



VoyagesBus Vols

Réservations



VoyagesBus Vols

Package réutilisable
Lieux


Diagramme
d’objets

Diagramme d’objets : Objectif

 Le diagramme d‟objets permet de mettre en évidence
des liens entre les objets. Les objets, instances de
classes, sont reliés par des liens, instances
d‟associations.
 A l‟exception de la multiplicité, qui est explicitement
indiquée, le diagramme d‟objets utilise les mêmes
concepts que le diagramme de classes. Ils sont
essentiellement utilisés pour comprendre ou illustrer
des parties complexes d‟un diagramme de classes.

Diagramme d’objets : Objet

 Notion‎d’Objet
Une abstraction du monde réel c.-à-d. des données
informatiques regroupant des caractéristiques du
monde réel.
Un objet est une instance d'une classe.
 Exemple
une personne, une voiture, une maison, ...

Diagramme d’objets : Objet

 Chaque objet est unique et a un identifiant qui le
distingue des autres objets.
 Les objets peuvent avoir un nom suivi de deux points et
du nom de la classe.
 Trois représentations possibles des instances :

Diagramme d’objets : Exemple


Diagramme
de composants

Diagramme de composants : Objectif

 Les diagrammes de composants décrivent les composants et
leurs dépendances dans l‟environnement de réalisation.
 En général, ils ne sont utilisés que pour des systèmes
complexes.
 Les diagrammes de composants permettent de décrire
l'architecture physique et statique d'une application en
terme de modules : fichiers sources, librairies, exécutables,
etc. Ils montrent la mise en œuvre physique des modèles de
la vue logique avec l'environnement de développement.

Diagramme de composants : Le composant

 Un composant est un élément physique qui représente une
partie implémentée d‟un système. Un composant peut être
du code (source, binaire ou exécutable), un script, un fichier
de commandes, un fichier de données, une table, etc. Il peut
réaliser un ensemble d‟interfaces qui définissent alors le
comportement offert à d‟autres composants.

Diagramme de composants : La relation

 Les relations de dépendance sont utilisées dans les
diagrammes de composants pour indiquer qu‟un élément
d‟implémentation d‟un composant fait appel aux services
offerts par les éléments d‟implémentation d‟un autre
composant.

Diagramme de composants : Stéréotypes

 UML définit 5 stéréotypes aux composants :
- «« document »» : un document quelconque
- «« exécutable »» : un programme qui peut s‟exécuter
- «« fichier »» : un document contenant un code source ou
des données
- «« bibliothèque »» : une bibliothèque statique ou
dynamique
- «« table »» : une table de base de données relationnelle

Diagramme de composants : Exemple


Diagramme
de déploiement

Diagramme de déploiement : Objectif

 Les diagrammes de déploiement montrent la disposition
physique des différents matériels (les noeuds) qui entrent
dans la composition d‟un système et la répartition des
instances de composants, processus et objets qui « vivent »
sur ces matériels.
 Le diagramme de déploiement modélise les composants
matériels utilisés pour implémenter un système et
l'association entre ces composants.
 Les diagrammes de déploiement sont donc très utiles pour
modéliser l‟architecture physique d‟un système.

Diagramme de déploiement : Le composant

 Un composant représente une entité logicielle du système.
(fichier de code source, programmes, documents, fichiers de
ressource .etc.). Sur un diagramme de déploiement, les
composants sont placés dans des noeuds pour identifier
l'endroit de leur déploiement.

Diagramme de déploiement : Le nœud

 Un noeud représente un ensemble d'éléments matériels du
système. Cette entité est représentée par un cube
tridimensionnel.

Diagramme de déploiement : L’association

 Les noeuds sont connectés entre eux, à l'aide d'un support
de communication.
 une association, représentée par une ligne pleine entre deux
noeuds, indique une ligne de communication entre les
éléments matériels.

Diagramme de déploiement : Exemple
 Le diagramme de déploiement ci-dessous montre que le
composant SiteConfig est déployé sur le serveur Web et le
composant Base DB est déployé sur le serveur APP. Nous
pouvons également déterminer que le serveur Web
communique avec le serveur APP, et le serveur APP
communique avec le serveur de base de données et une
imprimante.


Diagramme
de collaboration

Diagramme de collaboration: Objectif

 Le diagramme de collaboration permet de mettre en
évidence les interactions entre les différents objets du
système.
 Dans le cadre de l‟analyse, il sera utilisé
- pour préciser le contexte dans lequel chaque objet évolue
- pour mettre en évidence les dépendances entre les
différents objets impliqués dans l‟exécution d‟un processus
ou d‟un cas d‟utilisation.
 Un diagramme de collaboration fait apparaître les
interactions entre des objets et les messages qu‟ils
échangent.

Diagramme de collaboration: Les interactions

 Une interaction définit la communication entre les objets
sous la forme d‟un ensemble partiellement ordonné de
messages.
 L‟objet émetteur envoie un message à l‟objet récepteur. Les
objets représentés dans les diagrammes de collaboration ne
sont pas nécessairement des instances d‟entités. Certains
messages peuvent avoir pour origine des acteurs que l‟on
pourra représenter.
 l‟interaction se représente par une flèche avec un texte
décrivant le message.

Diagramme de collaboration: Les messages

 Les messages sont le seul moyen de communication entre les
objets. Ils sont décrits essentiellement par l‟objet émetteur et
l‟objet récepteur. Leur description peut être complétée par un
nom, une séquence, des arguments, un résultat attendu, une
synchronisation, une condition d‟émission.
 La séquence permet de préciser l‟ordre d‟émission des messages.

Le message 1 peut avoir
comme arguments
l‟intitulé du produit
souhaité, la quantité et
la catégorie du client.

Diagramme de collaboration: Les messages (suite)

 Certains messages peuvent solliciter un résultat. Ce cas peut
être modéliser de 2 façons :
- un message de demande et un message de réponse
- indiquer sur le premier message le résultat attendu (lorsque
le message en retour est attendu immédiatement).

ou

Ici, le message émis par le gérant implique la restitution
immédiate du résultat du calcul:la valeur du stock.

Diagramme de collaboration: Les messages (suite)

 NB : l‟émission de message peut également être soumis à une
condition, qui s‟exprime alors sur le texte du message.

 Exemple : la demande de
réapprovisionnement n‟est
envoyée au magasinier que
lorsque la quantité en stock
est inférieure au seuil de
réapprovisionnement.


Diagramme
de séquence

Diagramme de séquence: Objectif

 Le diagramme de séquence est une variante du diagramme de
collaboration.
 Les diagrammes de séquences permettent de représenter
des collaborations entre objets selon un point de vue
temporel.
 Le diagramme de séquence permet de visualiser les messages
par une lecture de haut en bas. L‟axe vertical représente le
temps, l‟axe horizontal les objets qui collaborent. Une ligne
verticale en pointillé est attachée à chaque objet et
représente sa durée de vie.

Diagramme de séquence: La ligne de vie

 La ligne de vie des objets est représentée par une ligne
verticale en traits pointillés, placée sous le symbole de
l‟objet concerné. Cette ligne de vie précise l‟existence de
l‟objet concerné durant un certain laps de temps.
 En général, une ligne de vie est représentée sur toute la
hauteur du diagramme de séquence. Par contre, elle peut
débuter et s‟interrompre à l‟intérieur du diagramme.
 La destruction est indiquée par la fin de la ligne de vie et par
une croix (X), soit à la hauteur du message qui cause la
destruction, soit après le dernier message envoyé par un
objet qui se suicide.

Diagramme de séquence: Les catégories de message
 Message simple: message dont on ne spécifie aucune
caractéristique d'envoi ou de réception particulière.
 Message minuté (timeout): bloque l'expéditeur pendant un
temps donné (qui peut être spécifié dans une contrainte), en
attendant la prise en compte du message par le récepteur.
L'expéditeur est libéré si la prise en compte n'a pas eu lieu
pendant le délai spécifié.
 Message synchrone: bloque l'expéditeur jusqu'à prise en
compte du message par le destinataire. Le flot de contrôle
passe de l'émetteur au récepteur (l'émetteur devient passif
et le récepteur actif) à la prise en compte du message.
 Message asynchrone: n'interrompt pas l'exécution de
l'expéditeur. Le message envoyé peut être pris en compte
par le récepteur à tout moment ou ignoré (jamais traité).
 Message dérobant: n'interrompt pas l'exécution de
l'expéditeur et ne déclenche une opération chez le récepteur
que s'il s'est préalablement mis en attente de ce message.

Diagramme de séquence: Les catégories de message (suite)

Exemple :

Diagramme de séquence: Le message réflexif

 Un objet peut s‟envoyer un message.
 Formalisme : Cette situation se représente par une flèche
qui revient en boucle sur la ligne de vie de l‟objet.

Diagramme de séquence: Les activations

 Les diagrammes de séquence permettent de représenter
les périodes d‟activité des objets.
 Une période d‟activité correspond au temps pendant lequel
un objet effectue une action, soit directement, soit par
l‟intermédiaire d‟un autre objet qui lui sert de sous-
traitant.
 les périodes d‟activité se représentent par des bandes
rectangulaires placées sur la ligne de vie des objets.
 Pour représenter de manière graphique une exécution
conditionnelle d'un message, on peut documenter un
diagramme de séquence avec du pseudo-code et
représenter des bandes d'activation conditionnelles.

Diagramme de séquence: Les activations

Exemple :

Ne confondez la
période d'activation
d'un objet avec sa
création ou sa
destruction. Un
objet peut être
actif plusieurs fois
au cours de son
existence

Diagramme de séquence: Les contraintes temporelles

 Une flèche qui symbolise un message peut être représentée
en oblique pour matérialiser les délais de transmission non
négligeables par rapport à la dynamique générale de
l‟application.

Diagramme de séquence: Exemple


Diagramme
d'états-transitions

Diagramme d’états-transitions: Objectif

 Ils ont pour rôle de représenter les traitements
(opérations) qui vont gérer le domaine étudié. Ils
définissent l'enchaînement des états de classe et font donc
apparaître l'ordonnancement des travaux.
 Le diagramme d'états-transition est associé à une classe
pour laquelle on gère différents états : il permet de
représenter tous les états possibles ainsi que les
événements qui provoquent les changements d'état.
 Décrit le comportement des objets d‟une classe au moyen
d‟un automate d‟états associé à la classe.

Diagramme d’états-transitions: Notion d’état

 Un état correspond à une situation durable dans laquelle se
trouvent les objets d'une classe.
 On lui associe les règles de gestion et les activités
particulières.
 un état = étape dans le cycle de vie d‟un objet durant lequel
• il satisfait à certaines conditions
• il réalise certaines actions
• ou attend certains événements
 La représentation symbolique des états d'une classe
d'objets est la suivante (rectangle aux bords arrondis) :

Diagramme d’états-transitions: Notion d’état (suite)

 Chaque diagramme d‟états-transitions comprend un état
initial.
 Pour un niveau hiérarchique donné, il y a un et un seul état
initial, mais plusieurs états finaux correspondant chacun à
une fin de vie de l‟objet différente.
 Il est possible de n‟avoir aucun état final : ex : un système
que ne s‟arrête jamais.

 L'état initial d'un objet : il
est obligatoire et unique
 L'état final : selon les
événements, il peut exister
plusieurs états finaux

Diagramme d’états-transitions: Evénements et transitions

 Un objet passe d'un état à un autre suite à un événement,
certains événements pouvant ne pas provoquer de
changement d'état.
 un événement est une information instantanée qui doit être
traitée dans l’instant où il se produit.
 Une transition est une relation entre 2 états. Elle est
orientée ce qui signifie que l'état 2 est possible si certains
événements sont vérifiés. Sa représentation symbolique est
une flèche sur laquelle est annoté l'événement qui concourt
au changement d'état.

Diagramme d’états-transitions: Evénements et transitions
 Exemple :
Une commande passera
dans l'état "En attente"
dès lors qu'elle aura été
expédiée

La transition peut être soumise à la vérification d'une expression
appelée "expression de garde".
Une garde est une condition booléenne qui permet ou non
le déclenchement d‟une transition lors de l’occurrence d‟un
Événement.

Exemple : La commande n'est expédiée que si la
commande comporte au moins 3 produits.

Diagramme d’états-transitions: actions et activités

 Les opérations de description des classes sont décrites dans le
diagramme d'étatstransitions sous forme d'actions et d'activités.
 Une action est une opération élémentaire et instantanée. Elle peut
être associée à l'événement lui-même ou à l'entrée dans l'état ou
à la sortie de l'état.
• l‟action d’entrée (entry) est exécutée de manière instantanée
et atomique.
• l‟action de sortie (exit) est exécutée à la sortie de l‟état.
 l‟action sur un événement interne (on) est exécutée lors de
l‟occurrence d‟un événement qui ne conduit pas à un autre état

Diagramme d’états-transitions: actions et activités (suite)

 Une activité est une opération qui dure et qui est donc associée à
un état. Elle peut être séquentielle ou cyclique :
• La fin d'une activité séquentielle correspond à la sortie de l'état :
une transition automatique est générée.
• Une activité cyclique ne se termine que par une transition de
sortie identifiée.
 Le mot clé do: indique une activité.
 Lorsqu‟une activité se termine, les transitions automatiques (sans
événement), mais éventuellement protégées par des gardes, sont
déclenchées.

Diagramme d’états-transitions: actions et activités (suite)

 Six manières d‟associer une
opération à une transition :
• l‟action associée à la transition
d’entrée (op1)
• l‟action d’entrée de l’état (op2)
• l’activité dans l’état (op3)
• l’action de sortie de l’état (op4)
• l‟action associée aux événements
internes (op5)
• l‟action associée à la transition de
la sortie de l’état (op6)

Diagramme d’états-transitions: hiérarchie d’états

 En cours de modélisation avec un diagramme d‟états, il peut
être judicieux de regrouper plusieurs états en un seul ou bien
de décomposer un état en plusieurs sous-états.
 Exemple:
Ici, l‟état „état4‟ est un sur-état
des états „état1‟, „état2‟, „état3‟.
Les deux transitions qui rentrent
dans l‟état „état4‟ spécifient
dans quel sous-état on arrive. La
transition sortante de l‟état
„état4‟ exprime que, quel que soit
le sous-état dans lequel l‟objet
se trouve, si l‟événement „ev3‟
arrive, alors l‟objet sort de l‟état
„état4‟.

Diagramme d’états-transitions: Exemple
Diagramme d’états-transitions du Distributeur Automatique de Boissons


Diagramme
d’activités

Diagramme d’activités : Objectif

 Les diagrammes d‟activités permettent de mettre l‟accent
sur les traitements.
 les diagrammes d'activité sont utilisés pour documenter le
déroulement des opérations dans un système.
 En regardant un diagramme d'activité, vous trouverez des
éléments des diagrammes d'état. En fait, le diagramme
d'activité est une variante du Diagramme d'état où les
„états‟ représentent des opérations, et les transitions
représentent les activités qui se produisent quand
l'opération est terminée. L'usage général des diagrammes
d'activité permet de faire apparaître les flots de
traitements induits par les processus internes par rapport
aux évènements externes.
 Ce diagramme pourra comporter des synchronisations pour
représenter les déroulements parallèles.
 La notion de couloir d'activité va décrire les responsabilités
en répartissant les activités entre les différents acteurs
opérationnels.

Diagramme d’activités : Synchronisation

 Les diagrammes d‟activités représentent les synchronisations
d‟activités au moyen de barres de synchronisation.
Formalisme: Exemple :

Diagramme d’activités : Nœuds d’activités

Un nœud d‟activité est un type d‟élément abstrait permettant
de représenter les étapes le long du flot d‟une activité. Il existe
trois familles de nœuds d‟activités :
 les nœuds d‟exécutions:
 les nœuds objets:
 et les nœuds de contrôle.

Diagramme d’activités : Nœuds d’activités (suite)

 Un nœud exécutable est un nœud d‟activité qu‟on peut exécuter. Il possède
un gestionnaire d‟exception qui peut capturer les exceptions levées parle
nœud, ou un de ses nœuds imbriqués. Il y‟a deux types de la Nœud
Exécutable:
 Nœud d’action: est un nœud d‟activité exécutable qui constitue l‟unité
fondamentale de fonctionnalité exécutable dans une activité.
 Nœud d’activité structurée: Un nœud d‟activité structurée est un nœud
d‟activité exécutable qui représente une portion structurée d‟une activité donnée
qui n‟est partagée avec aucun autre nœud structuré, à l‟exception d‟une
imbrication éventuelle.
 Un nœud de contrôle est un nœud d‟activité abstrait utilisé pour coordonner
les flots entre les nœuds d‟une activité. Il existe plusieurs types de nœuds
de contrôle :
Nœud initial, nœud final, nœud de décision et de fusion, nœud de bifurcation
et d‟union


 Nœud initial: Un nœud initial est un nœud de contrôle à partir duquel le
flot débute lorsque l‟activité enveloppante est invoquée.
 Nœud final: Un nœud final est un nœud de contrôle possédant un ou
plusieurs arcs entrants et aucun arc sortant.
 Nœud de décision: est un nœud de contrôle Qui permet de faire un
choix entre plusieurs flots sortants. Il possède un arc entrant et
plusieurs arcs sortants. Ces derniers sont généralement accompagnés de
conditions de garde pour conditionner le choix.
 Nœud de fusion: Un nœud de fusion est un nœud de contrôle qui
rassemble plusieurs flots alternatifs entrants en un seul flot sortant.
 Nœud de bifurcation: Un nœud de bifurcation, également appelé nœud
de débranchement est un nœud de contrôle qui sépare un flot en
plusieurs flots concurrents. Un tel nœud possède donc un arc entrant et
plusieurs arcs sortants.
 Nœud d’union: Un nœud d‟union, également appelé nœud de jointure est
un nœud de contrôle qui synchronise des flots multiples. Un tel Nœud
possède donc plusieurs arcs entrants et un seul arc sortant.

Diagramme d’activités : Nœuds d’activités (exemple)


 un nœud d’objet: permet de définir un flot d‟objet (un flot de données) dans
un diagramme d‟activités. Ce nœud représente l‟existence d‟un objet généré par
une action dans une activité et utilisé par d‟autres actions.
 Pin d‟entrée ou de sortie: Pour spécifier les valeurs passées en argument
à une activité et les valeurs de retour, on utilise des nœuds d‟objets
appelés pins (pin en anglais) d‟entrée ou de sortie.
Les valeurs sont passées par copie : une modification des valeurs
d‟entrée au cours du traitement de l‟action n‟est visible qu‟à l‟intérieur de
l‟activité.


 Pin de valeur: Un pin valeur est un pin d‟entrée qui fournit une valeur à
une action sans que cette valeur ne provienne d‟un arc de flot d‟objets.
Un pin valeur est toujours associé à une valeur spécifique.
Graphiquement, un pin de valeur se représente comme un pin d‟entrée
avec la valeur associée écrite à proximité.
 Flot d’objet: Un flot d‟objets permet de passer des données d‟une
activité à une autre. Un arc reliant un pin de sortie à un pin d‟entrée. Il
existe une autre représentation possible d‟un flot d‟objets, représenté
par un rectangle dans lequel est mentionné le type de l‟objet (souligné).
Le nom d‟un état, ou d‟une liste d‟états, de l‟objet peut être précisé
entre crochets après ou sous le type de l‟objet.
On peut également préciser des contraintes entre accolades, soit à
l‟intérieur, soit en dessous du rectangle du nœud d‟objet.


 Nœud tampon central: est un nœud d‟objet qui accepte les entrées de
plusieurs nœuds d‟objets ou produit des sorties vers plusieurs nœuds
d‟objets.

 Nœud de stockage des données: est un nœud tampon central
particulier qui assure la persistance des données. Lorsqu‟une information
est sélectionnée par un flux sortant, l‟information est dupliquée et ne
disparaît pas du nœud de stockage des données comme ce serait le cas
dans un nœud tampon central. Lorsqu‟un flux entrant véhicule une donnée
déjà stockée par le nœud de stockage des données, cette dernière est
écrasée par la nouvelle.

Diagramme d’activités: Les couloirs d'activités

 Le diagramme d'activités fait intervenir les acteurs de chaque
activité. Chaque activité sera placée dans une colonne (couloir) qui
correspond à l'acteur.
 permettent d‟organiser les nœuds d‟activités dans un diagramme
d‟activités en opérant des regroupements.


Modélisation dynamique en UML :
Étude de cas

Cas du publiphone :

1. Le prix minimal d’une communication interurbaine est de 1€.

Cas du publiphone :

2. Après l’introduction de la monnaie, l’utilisateur a 2 mn pour
composer son numéro (ce délai est décompté par le standard).

Cas du publiphone :

3. La ligne peut être libre ou occupée.

Cas du publiphone :

4. Le correspondant peut raccrocher le premier.

Cas du publiphone :

5. Le publiphone consomme de l’argent dès que l’appelé
décroche et à chaque unité de temps (UT) générée par le
standard.

Cas du publiphone :

standard.
6. On peut ajouter des pièces à tout moment.

Cas du publiphone :

standard.
6. On peut ajouter des pièces à tout moment.
7. Lors du raccrochage, le solde de monnaie est rendu.

 Démarche en plusieurs points :

 Identifier les acteurs et construire le diagramme des use case.
 Construire le diagramme de séquences système.
 Construire le diagramme de contexte dynamique.
 Élaborer le diagramme d’états du publiphone.

 Le diagramme des use case
 Les acteurs

 Les acteurs
0..1
«system» 0..*
Publiphone «system» 0..1
0..1 Téléphone
Appelant «actor» 0..*
0..1 Appelé
Standard

 Les acteurs
0..1
«system» 0..*
0..1 Téléphone
0..1 Appelé
Standard


 Les acteurs
0..1
«system» 0..*
0..1 Téléphone
0..1 Appelé
Standard

Publiphone
«actor»
Standard
secondaire
Appelant téléphoner

 Le diagramme de séquence sysème

 Le diagramme de séquence sysème
:publiphone :standard
:appelant
décrocherCombiné
introduirePièce(1€)
vérifierPièce
incrémenterCrédit(1€)
composerNuméro(04 78 77 23 23)
acheminerNuméro(04 78 77 23 23)

tonalité(libre) tonalité(libre)
débuterComm

taxer(1€)
introduirePièce(1€)

vérifierPièce
incrémenterCrédit(1€)
UT

taxer(1€)
raccrocherCombiné
FinComm

 Le diagramme de contexte dynamique


 Représenter les messages émis et les messages reçus par le publiphone .

:appelant

:publiphone

:standard

- Messages reçus déclenchent des transitions entre états.

décrocherCombiné ; introduirePièce(p) ; composerNuméro(n) ;
raccrocherCombiné ; voixAppelant

:appelant

:publiphone

acheminerNuméro(n)
finComm ; voixAppelant
timerNumérotation
:standard

- Messages transitions entre états.
reçus déclenchent des
- Messages émis donnent lieu à des actions sur les transitions.
décrocherCombiné ; introduirePièce(p) ; composerNuméro(n) ;
raccrocherCombiné ; voixAppelant

:appelant tonalité(type)
voixAppelé
rendrePièce

:publiphone
débuterComm acheminerNuméro(n)
UT
finComm ; voixAppelant
tonalité(type)
voixAppelé timerNumérotation
État(Ligne)
:standard
validitéNumérotation(v)
finComm
TimeroutNumérotation

 Le diagramme d’états







 Démarche itérative et incrémentale :
 Représenter les séquences d’états décrivant le comportement d’une instance avec les
transitions associées.
 Ajouter les transitions correspondant aux comportements ‘’alternatifs’’ ou d’exception.
 Compléter les actions sur les transitions et les activités dans les états.
 Structurer le diagramme en sous états et utiliser les notations ( entry, exit, …)

 Démarche itérative et incrémentale :
 Représenter les séquences d’états décrivant le comportement d’une instance avec les
transitions associées.
 Ajouter les transitions correspondant aux comportements ‘’alternatifs’’ ou d’exception.
 Compléter les actions sur les transitions et les activités dans les états.
 Structurer le diagramme en sous états et utiliser les notations ( entry, exit, …)

Événement interne
décrocherCombiné
When(crédit  1€)
raccroché attente pièce

communication attente N°
raccrocherCombiné
Réception
composerNuméro
message débuterComm

numéroValide
attente attente validité
décrochage

Événement interne
décrocherCombiné

raccrocherCombiné
Réception
composerNuméro

numéroValide
décrochage

Événement interne
décrocherCombiné
raccrocherCombiné

raccrocherCombiné

raccrocherCombiné
Réception
composerNuméro

numéroValide
raccrocherCombiné décrochage

raccrocherCombiné



décrocherCombiné

raccroché

raccrocherCombiné



décroché

décrocherCombiné

raccroché

raccrocherCombiné



décroché

décrocherCombiné

raccrocherCombiné

composerNuméro
débuterComm

numéroValide
décrochage

La solution bleue n’est pas intéressante

décroché

décrocherCombiné

raccrocherCombiné

composerNuméro
débuterComm

numéroValide
décrochage

 Modéliser l’ attente des pièces pour que le crédit devienne suffisant :

 Modéliser l’ attente des pièces pour que le crédit devienne suffisant :

introPièce(p)/incrémenterCrédit(p)

attente pièce

attente N°

Le diagramme devient :
décroché

décrocherCombiné
raccroché /crédit=0 attente pièce

Fin
UT[créditInuffisant] communication attente N°
raccrocherCombiné /taxer
/rendrePièce UT[créditInsuffisant]
/taxer
communication
composerNuméro

débuterComm /taxer

numéroValide attente validité
attente
décrochage

 Modéliser la phrase 6 : « on peut rajouter des pièces à tout moment »
 On peut rajouter une transition à chaque sous état (solution lourde, effet secondaire : à
chaque introPièce(p) le publiphone revient à son état initial (attente pièce c.a.d. raccroché)).
 On peut utiliser une transition interne introPièce(p)/incrémenterCrédit(p) à l’intérieur de
l’état « décroché »


décroché

décrocherCombiné

Fin
UT[créditInsuffisant] communication attente N°
communication /taxer
composerNuméro
débuterComm /taxer
numéroValide
décrochage


décroché

décrocherCombiné

Fin
UT[créditInsuffisant] communication attente N°
communication /taxer
composerNuméro
•Même la transition propre sur débuterComm /taxer
«communication» doit être numéroValide
transformée en transition interne. attente attente validité
décrochage
•On préfère les transitions propres,
car visuelles.


















 Les phrases 1, 5, 6, 7 dont modélisées.















 Les phrases 2, 3 et 4 sont à compléter.















 Phrase 2 : deux messages sont introduits :
 timerNumérotation envoyé par le publiphone au standard.
 timeoutNumérotation envoyé par le standard au publiphone.











 Utilisation du concept UML «send» pour envoyer un message








 Phrase 3 : Le standard renvoie un message sur l’état de la ligne.
 État(Ligne) (où état peut être libre, occupé, en dérangement).





 Phrase 3 : Le standard renvoie un message sur l’état de la ligne.
 État(Ligne) (où état peut être libre, occupé, en dérangement).

 Phrase 4 : Transition entre les états «communication» et «fin communication».

Le diagramme d’états final est alors après ajouts et compléments :


décroché


When(crédit  1€) /send standard.timerNumérotation
attente
pièce
phrase4 Fin timeoutNumérotation
raccrochage appelé communication
ou erreur
UT[créditInsuffisant] attente N°
/taxer
UT[crédit
Numéro composerNuméro
Insuffisant]
Communication /send standard.
invalide
/taxer acheminerNuméro
do /transmettrevoix

débuterComm étatLigne(occupée)
/taxer phrase3 timeoutappel

attente attente
décrochage numéroValide validité


décroché


Décrocher When(crédit  1€) /send standard.timerNumérotation
raccroché attente
Combiné pièce
/crédit=0 phrase4 Fin timeoutNumérotation
raccrochage appelé communication
ou erreur
UT[créditInsuffisant] attente N°
raccrocherCombi /taxer
né /rendrePièce UT[crédit
Numéro composerNuméro
Insuffisant]
Communication /send standard.
invalide
/taxer acheminerNuméro
do /transmettrevoix

débuterComm étatLigne(occupée)
/taxer phrase3 timeoutappel

attente attente
décrochage numéroValide validité


Conclusion :
• UML intègre l’objet et a été conçu pour et autour de l’objet.
• UML permet donc de modéliser une application selon une
vision objet.
• L’appréhension d’UML est complexe car UML est à la fois :
- une norme,
- un langage de modélisation objet,
- un support de communication,
- un cadre méthodologique.
• Il faut penser ce langage comme une boite à outils riche
et complexe; à utiliser intelligemment face à des besoins
précis.


FIN

Uml

Contenu connexe

Tendances

Similaire à Uml

Plus de Mohammed Zaoui

Uml