ResuméUML2

Université Sidi Mohamed Ben Abdallah
Faculté des Sciences Dhar El Mahraz Fès

Département d’Informatique
Document sur la formation

Du langage UML
Réalisé par : WARME Moumouni
Etudiant en Master I
Filière : Master Qualité Logiciel
Année Universitaire 2010-2011

Le Langage UML W.Moumouni
Table des matières
Introduction............................................................................................................................................. 4
Chapitre 1 : Le diagramme de cas d’utilisation ....................................................................................... 5
1. Définition : ................................................................................................................................... 5
2. Les objectifs : ............................................................................................................................... 5
3. Les éléments du diagramme de cas d’utilisation ........................................................................ 6
a. Acteur ...................................................................................................................................... 6
b. Cas d’utilisation ....................................................................................................................... 6
c. Représentation d’un diagramme de cas d’utilisation ............................................................. 7
4. Relations dans les diagrammes de cas d’utilisation .................................................................... 7
a. Relations entre acteurs et cas d’utilisation ............................................................................. 7
b. Relations entre cas d’utilisations............................................................................................. 8
c. Relations entre acteurs ......................................................................................................... 10
5. Exemple d’application ............................................................................................................... 11
Chapitre 2 : Le diagramme de séquence ............................................................................................... 13
1. Définition : ................................................................................................................................. 13
2. Les objectifs : ............................................................................................................................. 13
3. Les éléments du diagramme de séquences .............................................................................. 13
a. Représentation des lignes de vie........................................................................................... 13
b. Représentation des messages ............................................................................................... 13
c. Fragments d’interaction combinés ....................................................................................... 16
d. Utilisation d’interaction (interaction use) ............................................................................. 18
Chapitre 3: Le diagramme d’état-transition.......................................................................................... 22
1. Définition : ................................................................................................................................. 22
2. Les objectifs : ............................................................................................................................. 22
3. Les éléments du diagramme de séquences .............................................................................. 22
2
1. Définitions : ........................................................................................................................... 22
2. Représentation: ..................................................................................................................... 22
Chapitre 4: Le diagramme de classes .................................................................................................... 24
1. Définition ................................................................................................................................... 24
2. Les objectifs : ............................................................................................................................. 24
3. Les éléments du diagramme de classe ...................................................................................... 24
a. Les Classes ............................................................................................................................. 24
b. Les Relations .......................................................................................................................... 25
Conclusion ............................................................................................................................................. 27
3
Introduction
Le langage UML est un langage de modélisation utilisé dans plusieurs domaines y compris
l’informatique précisément dans la POO (Programmation Orientée Objet). En tant que
étudiant informaticien développeur il est primordial de maitriser ce langage pour mieux
effectuer une approche concrète et claire des applications à développer. C’est dans cette
logique que cette formation sur UML a été effectuée. La version étudiée dans ce document
est UML 2.0.
Ainsi la réalisation de ce document a pour but de consolider, d’approfondir les différentes

notions acquises lors de la formation. Pour mieux aborder la suite nous allons d’abord définir
un certain nombre de concepts.
Définitions :
 POO (Programmation Orientée Objet) : La programmation orienté objet c’est pensé

en terme d'ensemble d’objets reliés abstraits inter-opérant entre eux, pour en faire une
application. Cette programmation a pour objectif de rendre utilisable les objets ou entités
réutilisables, sans oublié la séparation des données et du traitement sur ces données. L
 UML (Unified Modeling Language) : C’est un langage de modélisation graphique qui

permet de représenter et de communiquer les divers aspects d’un système
d’information.
Aux graphiques sont bien sûr associés des textes qui expliquent leur contenu.
Donc c’est un métalangage car il fournit les éléments permettant de construire le modèle
qui, lui, sera le langage de l’application.
Ce langage est dans sa version UML 2.0 qui comporte 13 diagrammes par rapport à la version
UML 1.0 qui ne compte que 9 diagrammes.
Les treize diagrammes d’UML 2.0 sont :
 Diagramme d’activité
 Diagramme de classes
 Diagramme de cas d’utilisation
 Diagramme de communication
 Diagramme de composants
 Diagramme de déploiement
 Diagramme d’états-transitions
 Diagramme global d’interaction
4
 Diagramme d’objets
 Diagramme des packages
 Diagramme de temps
 Diagramme de structure composite
 Diagramme de séquence
Tous ces diagrammes ne sont pas utilisé en même temps lors d’une modélisation puisque chaque
diagramme à un rôle bien spécifique et selon le besoin.
D’ailleurs nous allons étudier que trois parmi ces quatre diagrammes, qui sont :
 Diagramme de cas d’utilisation
 Diagramme de séquence
 Diagramme d’état-transition
 Diagramme de classes
Ces diagrammes seront détaillés dans les chapitres qui suivent.
Chapitre 1 : Le diagramme de cas d’utilisation

1. Définition :
Le diagramme de cas d’utilisation comme sont nom l’indique présente les

différents cas d’utilisation, c’à dire les fonctionnalités de l’application ou du
système nécessaires aux utilisateurs.
C’est le premier diagramme du modèle UML, celui où s’assure la relation entre

l’utilisateur et les objets que le système ou l’application met en œuvre.
L’élaboration de celui-ci nécessite des entretiens avec les utilisateurs.
2. Les objectifs :
Les objectifs de ce diagramme sont tout à fait évidents :
 Présenter de manière claire et simple le cahier de charge d’un système
 Recueillir, analyser et organiser les besoins d’un système
 Répertorier les comportements d’un système
 Découper de manière simple les fonctionnalités d’un système.

5
3. Les éléments du diagramme de cas d’utilisation

Ce diagramme comporte plusieurs éléments qui sont :
a. Acteur
Un acteur est l’idéalisation d’un rôle joué par une personne, un système externe ou un dispositif
matériel qui interagit avec le système. Ainsi nous avons des acteurs principaux qui sont les principaux
utilisateurs, et des acteurs secondaires ce qui par exemple ferons marcher le système exemple
l’administrateur etc. Le statu d’un acteur va dépendre des fonctionnalités du système utilisés par
celui-ci.
Il se représente par un petit bonhomme (figure 1) avec son nom (exemple son rôle) inscrit en
dessous.
Cl i ent
Figure 1 : Exemple de représentation d’un acteur
Il est également possible de représenter un acteur sous la forme d’un classeur (figure 2) stéréotypé.
<<acteur>>
Client
Figure 2 : Exemple de représentation d’un acteur sous forme de classeur
Le stéréotype : Un stéréotype est une annotation s’appliquant sur un élément de modèle, exemple le
stéréotype <<acteur>> au niveau du classeur .Précisons que le stéréotype n’est pas propre au
diagramme de cas d’utilisation mais est une annotation générale utilisable dans tous les diagrammes
UML.
b. Cas d’utilisation
Un cas d’utilisation est une unité représentant une fonctionnalité visible de l’extérieur, réalisant un
service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l’acteur qui l’initie.
Un cas d’utilisation modélise donc un service rendu par le système, sans imposer le mode de
réalisation de ce service. Il est représenté par une ellipse (figure 3) contenant le nom du cas (un
verbe à l’infinitif), et optionnellement, au-dessus du nom, un stéréotype.
<<Stéréotype>>
Nom du cas
Figure 3 : Exemple de représentation d’un cas d’utilisation
6
c. Représentation d’un diagramme de cas d’utilisation
Figure 4: Diagramme de cas d’utilisation modélisant une borne d’accès à une banque.
Comme le montre la figure 4, la frontière du système est représentée par un cadre.

Le nom du système figure à l’intérieur du cadre, en haut. Les acteurs sont à l’extérieur et les cas
d’utilisation à l’intérieur.
4. Relations dans les diagrammes de cas d’utilisation
a. Relations entre acteurs et cas d’utilisation
Relation d’association : c’est un chemin de communication entre un acteur et un cas

d’utilisation qui est représenté par un trait continu (figure 5).
Figure 5: Exemple de relation entre cas d’utilisation et les acteurs.
7
Acteurs principaux et secondaires :
Un acteur est qualifié de principal pour un cas d’utilisation lorsque ce cas rend service à
cet acteur.
Les autres acteurs sont alors qualifiés de secondaires. Un cas d’utilisation a au plus un
acteur principal. Un acteur principal obtient un résultat observable du système tandis
qu’un acteur secondaire est sollicité pour des informations complémentaires.
En général, l’acteur principal initie le cas d’utilisation par ses sollicitations.
Le stéréotype << primary >> vient orner l’association reliant un cas d’utilisation à son
acteur principal, le stéréotype << secondary >> est utilisé pour les acteurs secondaires.
Cas d’utilisation interne :
Lorsqu’un cas d’utilisation n’est relié à aucun acteur, c’est cas d’utilisation interne.
b. Relations entre cas d’utilisations
Types et représentations
Figure 6 : Exemple de diagramme avec des relations entre les cas d’utilisations
8
Il existe principalement deux types de relations :
 les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus
utilisés sont l’inclusion et l’extension),
 et la généralisation/spécialisation.
Une dépendance se représente par une flèche avec un trait pointillé (figure 6). Si le cas A
inclut ou étend le cas B, la flèche est dirigée de A vers B.
Le symbole utilisé pour la généralisation est une flèche avec un trait plein dont la pointe
est un triangle fermé désignant le cas le plus général (figure 6).
Relation d’inclusion
Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement

du cas B : le cas A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme
une partie de A. Cette dépendance est symbolisée par le stéréotype << include >>
(figure 6). Par exemple, l’accès aux informations d’un compte bancaire inclut
nécessairement une phase d’authentification avec un identifiant et un mot de passe
(figure 6).
Les inclusions permettent essentiellement de factoriser une partie de la description d’un

cas d’utilisation qui serait commune à d’autres cas d’utilisation (voir le cas S’authentifier
de la figure 6).
Relation d’extension
La relation d’extension est probablement la plus utile car elle a une sémantique qui a un
sens du point de vue métier au contraire des deux autres qui sont plus des artifices
d’informaticiens.
On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A
peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut
éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est
optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> (figure 6).
L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point
d’extension. Il porte un nom, qui figure dans un compartiment du cas étendu sous la
rubrique point d’extension, et est éventuellement associé à une contrainte indiquant le
moment où l’extension intervient. Une extension est souvent soumise à condition.
Graphiquement, la condition est exprimée sous la forme d’une note. La figure 6 présente
l’exemple d’une banque où la vérification du solde du compte n’intervient que si la
demande de retrait dépasse 20 euros.
9
Relation de généralisation
Un cas A est une généralisation d’un cas B si B est un cas particulier de A.

Dans la figure 6, la consultation d’un compte via Internet est un cas particulier de la
consultation. Cette relation de généralisation/spécialisation est présente dans la plupart
des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés
objet.
c. Relations entre acteurs
La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d’un acteur B (spécialisation) si l’acteur A peut être substitué par l’acteur
B. Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse
n’est pas vrai. Ceci ressemble au concept d’héritage en POO.
Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein
dont la pointe est un triangle fermé désignant l’acteur le plus général (on a déjà vu ça
avec les relations entre cas d’utilisation).
Par exemple, la figure 7 montre que le directeur des ventes est un préposé aux
commandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une
commande, il peut gérer le stock. Par contre, le préposé aux commandes ne peut pas
gérer le stock.
Figure 7 : Exemple de relation de généralisation entre les acteurs
10
5. Exemple d’application
Nous allons mettre en pratique les différentes notions acquises concernant les
diagrammes de cas d’utilisation, dans l’étude de cas suivant :
Etude de cas 1 : Un site e-commerce

Le commerce électronique dans cette étude de cas, concerne le processus d’achat/vente
de livres sur Internet. La société BookStore est spécialisée dans la vente de livres de tout
type (science, littérature, Art, etc…) et sur tout support (livre papier, numérique, DVD,
etc..). BookStore reçoit ses commandes par fax et les chèques par courrier puis envoie le
bon de commande au client. Une fois le chèque encaissé par la banque partenaire
BookBank, elle utilise la société de transport BookEx pour acheminer les livres vers
leurs clients. La société BookStore possède un système « Gestion des stocks » qui met à
jour les données concernant le prix et l’état du stock des livres du catalogue. Ce système
est automatiquement chargé dans la base de données de façon périodique.
Actuellement, La société BookStore souhaite réaliser un site e-commerce pour gérer
seulement la vente de ses livres en ligne, gérer son catalogue de livre et sa base de
données de clients. L’objectif fondamental du futur site BookStore est de permettre aux
internautes de rechercher des ouvrages par thème, auteur, mot-clé, etc., de se constituer
un panier virtuel, puis de pouvoir les commander et les payer directement sur le Web.
Après l’analyse effectuée nous avons tiré le diagramme de cas d’utilisation.

Celui-ci présente les différents éléments suivant suivant :
Les cas d’utilisation :
 S’inscrire
 S’authentifier
 Rechercher des ouvrages
 Gérer le panier
 Commander le livre
 Payer
 Gérer les clients
 Maintenance catalogue
 Maintenance du site
Les Acteurs :
Principaux acteurs sont : Visiteur, Internaute, Client.

Acteurs secondaire : Administrateur du site, Système de gestion de stock,
BookBank.
11
Figure 8 : Diagramme de cas d’utilisation
12
Chapitre 2 : Le diagramme de séquence

1. Définition :
Le diagramme de séquence représente la succession chronologique des
opérations réalisées par un acteur. Il indique les objets que l’acteur va manipuler
et les opérations qui font passer d’un objet à l’autre.
2. Les objectifs :
Elle a comme objectifs de présenter :
 les objets manipulés par les acteurs
 la durée de vie d’un objet
 ordre chronologique d’enchainement des objets d’un système
 les opérations effectuées sur les objets par les acteurs
3. Les éléments du diagramme de séquences
a. Représentation des lignes de vie
Une ligne de vie se représente par un rectangle, auquel est accrochée une ligne verticale
pointillée, contenant une étiquette dont la syntaxe est :
[<nom_du_rôle>] : [<Nom_du_type>]
Au moins un des deux noms doit être spécifié dans l’étiquette, les deux points (:) sont,
quand à eux, obligatoire.
b. Représentation des messages
Un message définit une communication particulière entre des lignes de vie. Plusieurs types de
messages existent, les plus communs sont :
 l’envoi d’un signal

 l’invocation d’une opération
 la création ou la destruction d’une instance.
13
Messages asynchrones
Figure 9: Représentation d’un message asynchrone
Graphiquement, un message asynchrone se représente par une flèche en traits pleins et

à l’extrémité ouverte partant de la ligne de vie d’un objet expéditeur et allant vers celle
de l’objet cible (figure 9).
Messages synchrones
Figure 10: Représentation d’un message synchrone
Graphiquement, un message synchrone se représente par une flèche en traits pleins et à

l’extrémité pleine partant de la ligne de vie d’un objet expéditeur et allant vers celle de
l’objet cible (figure10). Ce message peut être suivi d’une réponse qui se représente par
une flèche en pointillé (figure 10).
Messages de création et destruction d’instance
Figure 11: Représentation d’un message de création et destruction d’instance.
La création d’un objet est matérialisée par une flèche qui pointe sur le sommet d’une
ligne de vie (figure 11).
La destruction d’un objet est matérialisée par une croix qui marque la fin de la ligne de
vie de l’objet (figure 11). La destruction d’un objet n’est pas nécessairement consécutive
à la réception d’un message.
14
Événements et messages
Figure 12: Les différents évènements correspondant à un message asynchrone.
UML permet de séparer clairement l’envoi du message, sa réception, ainsi que le début
de l’exécution de la réaction et sa fin (figure 12).
Syntaxe des messages et des réponses
Figure 13: Syntaxe des messages et des réponses.
Dans la plupart des cas, la réception d’un message est suivie de l’exécution d’une
méthode d’une classe. Cette méthode peut recevoir des arguments et la syntaxe des
messages permet de transmettre ces arguments.
15
La syntaxe de réponse à un message est la suivante :
[<attribut> = ] message [ : <valeur_de_retour>] où message représente le message

d’envoi.
La figure 13 montre un exemple d’exécution d’une méthode avec une réponse.
Message perdu et trouvé
Figure 14: Représentation d’un message perdu et d’un message trouvé.
Un message complet est tel que les événements d’envoi et de réception sont connus.
Un message perdu est tel que l’événement d’envoi est connu, mais pas l’événement de
réception. Il se représente par une flèche qui pointe sur une petite boule noire
(figure 14).
Un message trouvé est tel que l’événement de réception est connu, mais pas l’événement
d’émission. Une flèche partant d’une petite boule noire représente un message trouvé
(figure 14).
c. Fragments d’interaction combinés
Un fragment combiné représente des articulations d’interactions. Il est défini par un opérateur
et des opérandes. L’opérateur défini la signification du fragment combiné.
Il existe 12 d’opérateurs définis dans la notation UML 2.0.
Il est représenté dans un rectangle dont le coin supérieur gauche contient un pentagone. Dans
le pentagone figure le type de la combinaison, appelé opérateur d’interaction. Les opérandes
d’un opérateur d’interaction sont séparés par une ligne pointillée. Les conditions de choix des
opérandes sont données par des expressions booléennes entre crochets ([ ]).
La liste suivante regroupe les opérateurs d’interaction par fonctions :
 les opérateurs de choix et de boucle : alternative, option, break et loop ;

 les opérateurs contrôlant l’envoi en parallèle de messages : parallel et critical region ;
 les opérateurs contrôlant l’envoi de messages : ignore, consider, assertion et negative ;
 les opérateurs fixant l’ordre d’envoi des messages : weak sequencing , strict sequencing.
Nous allons présenter que celle vue lors de cette formation.
16
Opérateur alt
Figure 15: Représentation d’un choix dans un diagramme de séquence illustrant le découvrement d’une case au
jeu du démineur.
L’opérateur alternative, ou alt, est un opérateur conditionnel possédant plusieurs

opérandes (figure 15). C’est un peu l’équivalent d’une exécution à choix multiple.
Opérateurs opt
L’opérateur option, ou opt, comporte une opérande et une condition de garde associée. Le
sous-fragment s’exécute si la condition de garde est vraie et ne s’exécute pas dans le cas
contraire.
Opérateur loop
Un fragment combiné de type loop possède un sous-fragment et spécifie un compte minimum

et maximum (boucle) ainsi qu’une condition de garde.
La syntaxe de la boucle est la suivante :
loop[ '('<minInt> [ ',' <maxInt> ] ')' ]
17
La condition de garde est placée entre crochets sur la ligne de vie. La boucle est répétée
au moins minInt fois avant qu’une éventuelle condition de garde booléenne ne soit
testée. Tant que la condition est vraie, la boucle continue, au plus maxInt fois. Cette
syntaxe peut être remplacée par une indication intelligible comme sur la figure 15.
d. Utilisation d’interaction (interaction use)
Il est possible de faire référence à un autre diagramme de séquence, dans la définition

d’un autre diagramme de séquence.
Graphiquement, une utilisation apparaît dans un diagramme de séquence sous forme de
rectangle avec le tag ref (pour référence). On place dans le rectangle le nom du
diagramme référencée (figure 16).
Figure 16: Représentation de l’appel d’un diagramme de séquence dans un autre
18
Nous allons donner des exemples de diagramme de séquence, pour l’étude de cas
1 du chapitre 1.
Ainsi chaque diagramme de séquence est lié à un cas d’utilisation du diagramme
de cas d’utilisation.
Voici quelques principaux diagrammes de séquence:
Figure 17: Diagramme de sequence du cas S’inscrire
19
Figure 18: Diagramme de séquence du cas S’authentifier
Figure 19: Diagramme de séquence du cas gérer panier

20
Figure 20: Diagramme de séquence du cas rechercher ouvrage
Figure 21: Diagramme de séquence du cas payer ouvrage

21
Chapitre 3: Le diagramme d’état-transition

1. Définition :
Un diagramme d’états-transitions est un graphe qui représente un automate à
états finis, c’est-à-dire une machine dont le comportement des sorties ne dépend
pas seulement de l’état de ses entrées, mais aussi d’un historique des
sollicitations passées.
2. Les objectifs :
 Décrire les changements d'états d'un objet ou d'un composant
 Séquences d’actions et états traités par une instance
 Une vision complète et non ambiguë de l’ensemble des comportements du

système
3. Les éléments du diagramme de séquences
1. Définitions :
 Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des
valeurs des attributs d'un objet.
 Une transition représente le passage instantané d'un état vers un autre.
 Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un
événement qui conditionne la transition.
 Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas l'événement qui la
déclenche.
2. Représentation:
Etat simple :
Etat initial :
Etat final :
22
Figure 22:Exemple diagramme d’état-transition
23
Chapitre 4: Le diagramme de classes

1. Définition
Il permet de fournir une représentation abstraite des objets du système qui vont
interagir ensemble pour réaliser les cas d’utilisation.
Le diagramme de classes est considéré comme le plus important de la

modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation.
2. Les objectifs :
 Modéliser les concepts du domaine d’application
 Identifier la structure des classes du système
 Identifier les propriétés, et les méthodes de chaque
 Représenter les relations entre les classes
3. Les éléments du diagramme de classe

Les éléments de ce diagramme sont les classes et les relations entre ces classes.
a. Les Classes
Une classe est la description formelle d’un ensemble d’objets ayant une sémantique et
des caractéristiques communes.
Les classes sont les modules de base de la programmation orientée objet.
Une classe est représentée en utilisant un rectangle divisé (figure) en trois sections :
La section supérieure est le nom de la classe.
La section centrale définit les propriétés de la classe.
La section du bas énumère les méthodes de la classe.
Figure 23: Exemple de classe
24
b. Les Relations
Association :
Une association est une relation générique entre deux classes. Elle est modélisée
par une ligne (figure) reliant les deux classes. Cette ligne peut être qualifiée avec
le type de relation, et peut également comporter des règles de multiplicité (par
exemple un à un, un à plusieurs, plusieurs à plusieurs) pour la relation.
Personne Adresses
0..*
1
Figure 24: Exemple d’association
Composition
Si une classe ne peut pas exister par elle-même, mais doit être un membre d'une autre
classe, alors elle possède une relation de composition avec la classe contenant.
Une relation de composition est indiquée par une ligne avec un "losange" (figure)
rempli.
Voiture Roue
1
0..4
Figure 25: Exemple de relation de composition
Agrégation
Les agrégations indiquent une relation de contenant-contenu. Elle décrite par une
relation "possède".
Une relation d'agrégation est représentée par une ligne avec un "losange" creux.
Bibliothèque Livre
1..*
1..1
Figure 26: Exemple de relation d’agrégation
Généralisation
Une relation de généralisation est l'équivalent d'une relation d'héritage en terme
orientés objet (relation "est-un "). Une relation de généralisation est indiquée par une
flèche creuse se dirigeant vers la classe "Parent ".
25
Annimal
Chat Vache
Figure 27: Exemple de relation de généralisation (héritage)
Dépendance
Quand une classe utilise une autre classe, par exemple comme membre ou comme
paramètre d'une de ces fonctions, elle "dépend" ainsi de cette classe.
Une relation de dépendance est représentée par une flèche pointillée.
Figure 28: Exemple de relation de dépendance
Par exemple, le diagramme de la figure montre que la classe Confrontation utilise la

classe Stratégie car la classe Confrontation possède une méthode confronter dont deux
paramètre sont du type Stratégie. Si la classe Stratégie, notamment son interface,
change, alors des modifications devront également être apportées à la classe
Confrontation.
Nous allons donner le diagramme de classe, pour l’étude de cas 1 du chapitre 1.
Les différentes méthodes n’on pas été présenter dans ce diagramme pour éviter
de surcharger celui-ci.
26
Panier Ligne
- total : float - Quantite : int

0..* - montant : float
0..1
0..*
0..1 0..1
0..1
Client 0..*
0..1
- Nom : String
- Prenom : String
Ouvrage
- login : String Theme
- password : String - ISBN : int
- libelle : String
- email : String - titre : String
0..*
- prix : float
- date edition : Date 0..1 0..*
1..*
1..*
Auteur
Adresse - Nom : String
- adresse : String - Prenom : String
Editeur
- Nom : String
- Pays : String
0..*
0..*
Commande
Carte bancaire
- NumCmde : int
1..1 - dateCmde : Date 0..1
- montantCmde : double 0..*
- dateLivraison : Date
Figure 29: Diagramme de class
Conclusion
Cette étude nous a permis de se familiariser et s'initier au langage UML.
Ainsi nous avons acquis différentes notions concernant les diagrammes de cas
d’utilisation, de séquence, d’état-transition et de classe. Personnellement cette étude m’a
été bénéfique et pour une bonne maitrise des différentes notions acquises, il est
nécessaire de faire beaucoup d’étude de cas pratique. Cette étude a suscité en moi une
curiosité d’aller comprendre les autres diagrammes que nous n’avons pas abordé à
augmenté. En somme ce langage propose plusieurs types de diagramme qui ne sont pas
tous utilisé lors de la conception d’une application. Ce qui nous oblige à bien choisir le
type de diagramme qui va mieux expliquer notre application.
27

ResuméUML2

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ResuméUML2

Încărcat de

Drepturi de autor:

Formate disponibile

Université Sidi Mohamed Ben Abdallah

Faculté des Sciences Dhar El Mahraz Fès

Document sur la formation

Réalisé par : WARME Moumouni

Filière : Master Qualité Logiciel

Année Universitaire 2010-2011

Chapitre 1 : Le diagramme de cas d’utilisation ....................................................................................... 5

2. Les objectifs : ............................................................................................................................... 5

3. Les éléments du diagramme de cas d’utilisation ........................................................................ 6

b. Cas d’utilisation ....................................................................................................................... 6

c. Représentation d’un diagramme de cas d’utilisation ............................................................. 7

4. Relations dans les diagrammes de cas d’utilisation .................................................................... 7

a. Relations entre acteurs et cas d’utilisation ............................................................................. 7

b. Relations entre cas d’utilisations............................................................................................. 8

c. Relations entre acteurs ......................................................................................................... 10

5. Exemple d’application ............................................................................................................... 11

Chapitre 2 : Le diagramme de séquence ............................................................................................... 13

2. Les objectifs : ............................................................................................................................. 13

3. Les éléments du diagramme de séquences .............................................................................. 13

a. Représentation des lignes de vie........................................................................................... 13

b. Représentation des messages ............................................................................................... 13

c. Fragments d’interaction combinés ....................................................................................... 16

d. Utilisation d’interaction (interaction use) ............................................................................. 18

4. Exemple d’application ............................................................................................................... 19

Chapitre 3: Le diagramme d’état-transition.......................................................................................... 22

2. Les objectifs : ............................................................................................................................. 22

3. Les éléments du diagramme de séquences .............................................................................. 22

Chapitre 4: Le diagramme de classes .................................................................................................... 24

2. Les objectifs : ............................................................................................................................. 24

3. Les éléments du diagramme de classe ...................................................................................... 24

a. Les Classes ............................................................................................................................. 24

b. Les Relations .......................................................................................................................... 25

4. Exemple d’application ............................................................................................................... 26

Ainsi la réalisation de ce document a pour but de consolider, d’approfondir les différentes

 POO (Programmation Orientée Objet) : La programmation orienté objet c’est pensé

 UML (Unified Modeling Language) : C’est un langage de modélisation graphique qui

Les treize diagrammes d’UML 2.0 sont :

 Diagramme de cas d’utilisation

 Diagramme global d’interaction

 Diagramme des packages

 Diagramme de structure composite

 Diagramme de cas d’utilisation

Ces diagrammes seront détaillés dans les chapitres qui suivent.

Chapitre 1 : Le diagramme de cas d’utilisation

Le diagramme de cas d’utilisation comme sont nom l’indique présente les

C’est le premier diagramme du modèle UML, celui où s’assure la relation entre

L’élaboration de celui-ci nécessite des entretiens avec les utilisateurs.

 Présenter de manière claire et simple le cahier de charge d’un système

 Recueillir, analyser et organiser les besoins d’un système

 Répertorier les comportements d’un système

 Découper de manière simple les fonctionnalités d’un système.

3. Les éléments du diagramme de cas d’utilisation

Figure 1 : Exemple de représentation d’un acteur

Figure 3 : Exemple de représentation d’un cas d’utilisation

c. Représentation d’un diagramme de cas d’utilisation

Comme le montre la figure 4, la frontière du système est représentée par un cadre.

4. Relations dans les diagrammes de cas d’utilisation

a. Relations entre acteurs et cas d’utilisation

Relation d’association : c’est un chemin de communication entre un acteur et un cas

Figure 5: Exemple de relation entre cas d’utilisation et les acteurs.

Cas d’utilisation interne :

b. Relations entre cas d’utilisations

Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement

Les inclusions permettent essentiellement de factoriser une partie de la description d’un