Uml PDF

Outils de modélisation des
systèmes d’information
(Unified Modeling Language – UML - )
université d’Alger 1 -
Benyoucef Benkhedda
UML
L’OMG (Object Management Group) définit UML
« Le langage UML (Unified Modeling Language) est un langage

graphique permettant de visualiser, de spécifier, de construire et de
documenter les artefacts d'un système à forte composante logicielle.
L'UML offre un moyen standard d'écrire les plans d'un système, y
compris les concepts tels que les processus métier et les fonctions
système, ainsi que des éléments concrets tels que les instructions de
langage de programmation, les schémas de base de données et les
composants logiciels réutilisables. »
2
Introduction:
Un langage proposé en 1997.
Destiné aux applications orientée objet
L’approche orientée objet repose souvent sur les concepts de classe et objet:
o Un objet est une entité connue par une identité, un ensemble d’états et un
comportement
o Une classe est un concept d’abstraction regroupant plusieurs objets
partageant les même attributs. Il permet la réutilisation des composantes
logiciels
3
3
Introduction:
UML offre une modélisation à un niveau d’abstraction élevé, non ambiguë et

compréhensible même pour les non spécialistes.
Cela l’a rendu un langage universel.
UML ne propose pas un processus de développement. Par contre, il consiste

d’une norme de représentation.
4
4
Historique
OMT-2 Booch’93
James Rumbargh Grady Booch
OOSE
UML 0.8
Ivar Jacobson
Partenaires divers UML 0.9 (1996)
Task force UML 1.0 (1997)
UML 1.1 (fin 1997) Standard OMG
UML 1.2 UML 1.3 UML 1.4 UML 1.5 UML 2.0 … UML 2.5
5
Diagrammes UML 2
Diagrammes comportementaux Diagrammes structurels

Diagramme de cas d’utilisation Diagramme de classe
Diagramme d’état-transition Diagramme d’objet
Diagramme d’activité Diagramme de déploiement
Diagramme de séquence Diagramme de package
Diagramme de communication Diagramme de structure composite
Diagramme global d’interaction Diagramme de composant
Diagramme de temps
6
Diagrammes UML 2
Diagrammes comportementaux Diagrammes structurels

Diagramme de cas d’utilisation Diagramme de classe
Diagramme d’état-transition Diagramme d’objet
Diagramme d’activité Diagramme de déploiement
Diagramme de séquence Diagramme de package
Diagramme de communication Diagramme de structure composite
Diagramme global d’interaction Diagramme de composant
Diagramme de temps
OMSI ACOO
7
Diagramme de cas d’utilisation
8
➢
Ont été définis initialement par Ivar Jacobson en 1992 dans sa méthode OOSE
➢
Constituent un moyen de recueillir et de décrire les besoins des acteurs du
système
➢
Peuvent être utilisés comme moyen d’organisation du développement du
logiciel (pour la structuration + tests)
➢
Permet de décrire l’interaction entre les acteurs (utilisateur du cas) et le
système (point de vue utilisateur)
➢
La représentation d’un cas d’utilisation met en jeu 3 concepts: l’acteur, le cas
d’utilisation et l’interaction entre eux 9
Acteur
Un acteur représente un rôle joué par une entité externe (utilisateur
humain, dispositif matériel ou autre système) qui interagit
directement avec le système étudié.
Un acteur peut consulter et/ou modifier directement l’état du

système, en émettant et/ou en recevant des messages susceptibles
d’être porteurs de données.
10
Acteur
Les utilisateurs humains directs: client, administrateur, technicien, …
Les autres système connexes qui interagissent aussi directement avec

le système étudié: Système d’information
11
Acteur
12
Cas d’utilisation
Un cas d’utilisation (« use case ») représente un ensemble de

séquences d’actions qui sont réalisées par le système et qui
produisent un résultat observable intéressant pour un acteur
particulier
Il permet de décrire ce que le futur système devra faire, sans spécifier
comment il le fera
13
Cas d’utilisation
L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences

fonctionnelles du système
Chaque cas d’utilisation correspond donc à une fonction métier du système,

selon le point du vue d’un de ses acteurs.
Les cas d’utilisation doivent être nommés par un verbe à l’infinitif suivi d’un
complément (de point de vue acteur)
14
Cas d’utilisation
Limite du système
Acteur
Lien
d’interaction
15
Exemple
16
Relation entre acteur
UML permet une relation de

généralisation/spécialisation entre acteur.
17
Relation entre cas d’utilisation
Afin d’optimiser la formalisation des besoins en ayant recours notamment à la

réutilisation de cas d’utilisation, trois relations peuvent être décrites entre cas
d’utilisation : une relation d’inclusion (« include »), une relation d’extension («
extend ») et une relation de généralisation.
18
Relation d’inclusion
Une relation d’inclusion d’un cas d’utilisation A par rapport à un cas d’utilisation B
signifie qu’une instance de A contient le comportement décrit dans B.
19
Relation d’inclusion
20
Relation d’extension
Une relation d’extension d’un cas d’utilisation A par un cas d’utilisation
B signifie qu’une instance de A peut être étendue par le comportement
décrit dans B.
Deux caractéristiques sont à noter :
• le caractère optionnel de l’extension dans le déroulement du cas
d’utilisation standard (A) ;
• la mention explicite du point d’extension dans le cas d’utilisation
standard.
21
Relation
d’extension
22
Relation de généralisation
23
Exemple
24
Acteur principal & acteur secondaire
Nous appelons acteur principal celui pour qui le cas d’utilisation produit
un résultat observable.
Par opposition, nous qualifions d’acteurs secondaires les autres

participants du cas d’utilisation
25
26
Description textuelle d’un cas d’utilisation
À chaque cas d’utilisation doit être associée une description textuelle

des interactions entre l’acteur et le système et les actions que le
système doit réaliser en vue de produire les résultats attendus par les
acteurs.
UML ne propose pas de présentation type de cette description
textuelle.
27

La description textuelle d’un cas d’utilisation est articulée en six points :
• Objectif – Décrire succinctement le contexte et les résultats attendus
du cas d’utilisation.
• Acteurs concernés – Le ou les acteurs concernés par le cas doivent
être identifiés en précisant globalement leur rôle.
• Pré conditions – Si certaines conditions particulières sont requises
avant l’exécution du cas, elles sont à exprimer à ce niveau.
28

• Post conditions – Par symétrie, si certaines conditions particulières
doivent être réunies après l’exécution du cas, elles sont à exprimer à ce
niveau.
• Scénario nominal – Il s’agit là du scénario principal qui doit se dérouler
sans incident et qui permet d’aboutir au résultat souhaité.
• Scénarios alternatifs – Les autres scénarios, secondaires ou
correspondant à la résolution d’anomalies, sont à décrire à ce niveau.
Le lien avec le scénario principal se fait à l’aide d’une numérotation
hiérarchisée (1.1a, 1.1b…) rappelant le numéro de l’action concernée.
29

Sommaire d’identification
Titre: Retirer de l’argent
Résumé: ce cas d’utilisation permet à un Porteur de carte, qui n’est pas client
de la banque, de retirer de l’argent, si son crédit hebdomadaire le permet.
Acteur: Porteur de carte (principal), système d’autorisation (secondaire)
Date de création: DD/MM/YY date de mise à jour: DD/MM/YY
Version: 1.4 Responsable: uuuuuuuuuuu
30
Description des scénarios

Préconditions
• La caisse du GAB est alimentée (il reste au moins un billet !)
• Aucune carte ne se trouve déjà coincée dans le lecteur.
• La connexion avec le système d’autorisation est opérationnelle.
31

Description des scénarios (suite)
Scénario nominal
1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du
GAB
2. Le GAB vérifie que la carte introduite est bien une carte bancaire
3. Le GAB demande au Porteur de carte de saisir son code
d’identification
4. Le Porteur de carte saisit son code d’identification
32

Scénario nominal
5. Le GAB compare le code d’identification avec celui qui est codé sur la puce
de la carte
6. Le GAB demande une autorisation au Système d’autorisation
7. Le Système d’autorisation donne son accord et indique le crédit
hebdomadaire
8. Le GAB demande au Porteur de carte de saisir le montant désiré du retrait
33

Scénario nominal
9. Le Porteur de carte saisit le montant désiré du retrait.
10. Le GAB contrôle le montant demandé par rapport au crédit hebdomadaire.
11. Le GAB demande au Porteur de carte s’il veut un ticket.
12. Le porteur de carte demande un ticket
13. Le GAB rend sa carte au Porteur de carte
34

Scénario nominal
14. Le Porteur de carte reprend sa carte
15. Le GAB délivre les billets et un ticket.
16. Le Porteur de carte prend les billets et le ticket
35

Scénarios alternatifs
A1: code d’identification provisoirement erroné
L’enchaînement A1 démarre au point 5 du scénario nominal.
6. Le GAB indique au Porteur de carte que le code est erroné, pour la
première ou deuxième fois.
7. Le GAB enregistre l’échec sur la carte
Le scénario nominal reprend au point 3.
36

A2: montant demandé supérieur au crédit hebdomadaire
11. Le GAB indique au Porteur de carte que le montant demandé est
supérieur au crédit hebdomadaire.
Le scénario nominal reprend au point 8.
37

A3: ticket refusé
12. Le Porteur de carte refuse le ticket.
13. Le GAB rend sa carte au Porteur de carte.
14. Le Porteur de carte reprend sa carte.
15. Le GAB délivre les billets.
16. Le Porteur de carte prend les billets
38

Scénarios d’erreurs
E1: carte non-valide
L’enchaînement E1 démarre au point 2 du scénario nominal.
3. Le GAB indique au Porteur que la carte n’est pas valide, confisque la
carte ; le cas d’utilisation se termine en échec.
39

E2: code d’identification définitivement erroné
L’enchaînement E2 démarre au point 5 du scénario nominal
6. Le GAB indique au Porteur de carte que le code est erroné, pour la troisième
fois.
7. Le GAB confisque la carte
8. Le Système d’autorisation est informé; le cas d’utilisation se termine en échec
40

E3: retrait non autorisé
7. Le Système d’autorisation interdit tout retrait.
8. Le GAB éjecte la carte; le cas d’utilisation se termine en échec
41

E4: carte non reprise
14. Au bout de 10 secondes, le GAB confisque la carte.
15. Le système d’autorisation est informé; le cas d’utilisation se termine
en échec.
42

E5: billets non pris
16. Au bout de 10 secondes, le GAB reprend les billets.
17. Le cas d’utilisation se termine en échec.
43

E6: annulation de la transaction
L’enchaînement E6 peut démarrer entre les points 4 et 12 du scénario
nominal.
4 à 12. le Porteur de carte demande l’annulation de la transaction en
cours. Le GAB éjecte la carte; le cas d’utilisation se termine en échec.
44

Post conditions
• La caisse du GAB contient moins de billets qu’au début du cas d’utilisation
(le nombre de billets manquants est fonction du montant de retrait).
• Une transaction de retrait a été enregistrée par le GAB avec toutes les
informations pertinentes (montant, numéro de carte, date, etc.)
• Les détails de la transaction doivent être enregistrés aussi bien en cas de
succès que d’échec.
45
Recommandation
Commencer par l’identification des acteurs

Organiser les acteurs par généralisation
Pour chaque acteurs, rechercher les cas d’utilisation
46

Uml PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml PDF

Transféré par

Droits d'auteur :

Formats disponibles

Outils de modélisation des

L’OMG (Object Management Group) définit UML

« Le langage UML (Unified Modeling Language) est un langage

Un langage proposé en 1997.

Destiné aux applications orientée objet

UML offre une modélisation à un niveau d’abstraction élevé, non ambiguë et

Cela l’a rendu un langage universel.

UML ne propose pas un processus de développement. Par contre, il consiste

Partenaires divers UML 0.9 (1996)

Task force UML 1.0 (1997)

UML 1.1 (fin 1997) Standard OMG

Diagrammes comportementaux Diagrammes structurels

Diagrammes comportementaux Diagrammes structurels

Un acteur peut consulter et/ou modifier directement l’état du

Les utilisateurs humains directs: client, administrateur, technicien, …

Les autres système connexes qui interagissent aussi directement avec

Un cas d’utilisation (« use case ») représente un ensemble de

L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences

Chaque cas d’utilisation correspond donc à une fonction métier du système,

UML permet une relation de

Afin d’optimiser la formalisation des besoins en ayant recours notamment à la

Acteur principal & acteur secondaire

Par opposition, nous qualifions d’acteurs secondaires les autres

Description textuelle d’un cas d’utilisation

À chaque cas d’utilisation doit être associée une description textuelle

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description des scénarios

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Description textuelle d’un cas d’utilisation

Commencer par l’identification des acteurs

Vous aimerez peut-être aussi