Génie Logiciel - Unified modeling language

Unified Modeling
Language
12018 - schneider.julien@gmail.com UNIFIED MODELING LANGUAGE

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES
2018 - schneider.julien@gmail.com UNIFIED MODELING LANGUAGE 2

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES

Les concepts
Paradigme objet
Le paradigme objet propose dedécrirele monde sous forme
d’objets.
Un objet :
◦ possède à la fois des données et des comportements,
◦ est une boîte noire : seuls les services rendus par l'objet sont importants au
niveau de son utilisateur.
4
Objet
Caractéristiques
Comportements
Contient
Appelle
Spécialise
Généralise

Les concepts
Paradigme objet
Exemple :
Toute voiture possède une marque, un nom…
Partie Donnée
Toute voiture sait avancer, reculer, tourner...
Partie Comportement

Les concepts
Approche orientée objet
Approchelogicielorientée objet (OO) « pure » :
◦ Tout est objet
◦ Un programme est une collection d’objets communicants par
envoi de messages (utilisent les comportements d’autres
objets)
◦ Chaque objet a un type (typage fort)
◦ Tous les objets d’un même type peuvent recevoir les mêmes
messages

Les concepts
Identité
Deux objets peuvent avoir exactement les mêmes valeurs
dans leur partie donnée et le même comportement, ils ne
se confondent pas l'un avec l'autre.
Réciproquement, les données d'un objet peuvent changer,
l'objet lui-même ne change pas d'identité .
Un langage de programme objet fournit un moyen de
désigner un objet en tant qu'élément unique,
indépendamment de ses valeurs (référence, pointeur,
identificateur...).
UNIFIED MODELING LANGUAGE 72018 - schneider.julien@gmail.com

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES

Historique
UML = « Unified Modeling Language »
UML n’est pas une méthode : son utilisation est laissée à
l'appréciation de chacun.

Historique
Ce qu’apporte UML :
◦ Des diagrammes qui :
◦ décrivent le système informatique à produire d’un certain point de vue,
◦ peuvent montrer tout ou partie des caractéristiques des éléments de modélisation, selon le
niveau de détail utile dans le contexte d’un diagramme donné.
◦ Des éléments de langage qui sont :
◦ les briques des diagrammes UML,
◦ utilisés dans plusieurs types de diagrammes,
Exemple d'éléments : cas d'utilisation, classe, association, etc…
UML 2.3 propose 13 types de diagrammes (9 en UML 1.3), dont les principaux sont:
◦ Le diagramme de classes : central si on se concentre sur la tâche de développement.
◦ Le diagramme de cas d’utilisation: central si on se concentre sur la vision utilisateur dans
les méthodes « Unified Process » ou Agiles.

Historique
Constats partagés par l’ensemble des entreprises :
◦ croissance de la complexité des applications / systèmes informatiques,
◦ besoin de gagner en productivité.
Qualités attendues des systèmes informatiques :
◦ modularité / résistance aux modifications,
◦ réutilisabilité,
◦ lisibilité et compréhensibilité,
◦ encapsulation des données,
◦ ...
Solution : le paradigme objet.

Historique
Historique
En 1994, on dénombre plus de 50 méthodes orientées objet:
◦ Fusion, Shlaer-Mellor, ROOM, Classe-Relation, Wirfs-Brock, Coad-Yourdon, MOSES, Syntropy,
BOOM, OOSD, OSA, BON, Catalysis, COMMA, HOOD, Ooram, DOORS...
◦ Leurs notations graphiques sont toutes différentes.
L’approche orientée objet avait besoin d’un langage standard pour :
◦ Encourager le développement de l’approche orientée objet,
◦ Supporter des spécifications indépendantes d’un langage de programmation ou d’une méthode,
◦ Supporter les concepts de haut niveau tels que les composants, les collaborations, les
frameworks et les patterns,
◦ Représenter des systèmes entiers.
Ce langage commun devait être visuel et expressif, pour être utilisé dans le cadre de
développement et d’échange de spécifications.
 Ce sont les exigences portées par la standardisation d’UML.

Historique
1989 : Création de l’OMG
1993-1994 : Booch’93, OMT-2
1994 : Octobre 1994 :
◦ J. Rumbaugh rejoint G. Booch chez Rational
◦ Annonce de l’unification des deux méthodes
◦ JAVA 1.0
Octobre 1995 :
◦ Méthode Unifiée v0.8
◦ I. Jacobson rejoint à son tour Rational
Janvier 1997 : Soumission à l’OMG de la version UML 1.0
Septembre 1997 : UML 1.1
OMG :
◦ L'Object Management Group est une association américaine à but non lucratif dont l’objectif est de standardiser et promouvoir le modèle objet sous toutes ses formes.
◦ L’OMG est notamment à la base des standards UML (Unified Modeling Language), MOF (Meta-Object Facility), CORBA (Common Object Request Broker Architecture) et IDL (Interface Definition Language).
◦ L’OMG est aussi à l’origine de la recommandation MDA (Model Driven Architecture) ou ingénierie dirigée par les modèles, avec en particulier le langage standardisé de transformation de modèles QVT
(Query/View/Transformation).
◦ Plus de 700 entreprises y adhèrent.

Historique
UML est une notation, pas une méthode
UML est un langage de modélisation objet
UML convient pour toutes les langages objet
UML est dans le domaine public
UML est soutenu par le marché
◦ Microsoft, HP, Oracle, IBM...

Historique
Pionnier de l ’Orienté-Objet
◦ Article en 1981 : ‘Object Oriented Development’
◦ Au début, méthode pour le développement
d’applications en Ada pour le ‘Department of Défense’
◦ Etendue au C++
Distingue 2 niveaux :
◦ Logique
◦ Diagramme de classes
◦ Diagramme d’instance
◦ Diagramme états/transitions
◦ Physique
◦ Diagramme de modules (principe des packages)
◦ Diagramme de processus
15
Grady Booch

Historique
Object Modeling Technique
◦ Livre de James Rumbaugh (1991)
3 axes
◦ Statique
◦ Dynamique
◦ Fonctionnel
16
James Rumbaugh

Historique
Object Oriented Software Engineering
◦ Souvent appelée Objectory
5 modèles:
◦ Besoins
◦ Analyse
◦ Conception
◦ Implantation
◦ Test
3 typesd’objets (MVC en Design Paterns)
◦ entités
◦ contrôles
◦ interfaces
Notion de Cas d’Utilisation (Use Case)
17
Ivar Jacobson

Historique

Historique
Généralisation de l’approchelogicielorientée objet (OO) :
◦ La conception et développement des systèmes avec un langage orienté objet
est maintenant la norme.
◦ Mais le paradigme objet n’est souvent pas respecté : en informatique de
gestion, la décomposition « méthode métier » et « données » ne répond pas
au paradigme objet même si le développement utilise un langage OO.
Le paradigme objet est aussi à l’origine de l’évolution « récente » de
l’architecture des systèmes informatiques :
◦ Les applications et leurs composants sont des objets dont on veut isoler les :
◦ Données : qui est référent de la donnée ?
◦ Comportements : qui est référent de la manipulation de la donnée ?
◦ Ces objets du SI sont structurants pour l’entreprise et leur non-gouvernance
implique des coûts et des délais supplémentaires ainsi que de la non-qualité.
◦ Service Oriented Architecture (SOA)

Historique
Quelle est l’importance d’UML dans le cycle de vie d’une
application ?
Avant le Génie Logiciel & Spécification
◦ UML est un outil puissant de spécification des exigences de
l’utilisateur.
◦ Quelque soit le cycle de vie de l’application, certains diagrammes
doivent être produits pour garantir la cohérence de l’application
produite : diagramme de classe, diagramme de cas d’utilisation.
Développement
◦ le doux rêve du MDD (Model Driven Development) est passé, ou en
tout cas pas d’actualité en entreprise.
◦ Echanger sur des déroulés applicatifs en mode « brownpaper » :
diagramme de séquence et diagramme de collaboration.

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES

Les diagrammes
La mise en œuvre d’UML amène à considérerque différents points de
vuevont se superposer pour collaborer à la définition du système :
◦ Les diagrammes comportementaux
◦ Les diagrammes structurels ou statiques
◦ Les diagrammes d'interaction ou dynamiques

Légende
Les diagrammes
UML
Diagrammes Structurels ou
statiques
Diagramme de classes
Diagramme de composants
Diagramme de structure
composite
Diagramme de déploiement
Diagramme de paquetage
Diagrammes
comportementaux
Diagramme d’activité
Diagramme de cas
d’utilisation
Diagramme d’états
Diagrammes d’interaction
Diagramme de séquence
Diagramme de collaboration
Diagramme global
d’interaction
Diagramme de temps
Catégorie de diagramme
Type de diagramme
Type de diagramme peu
utilisé

Les diagrammes
Les diagrammes comportementaux :
◦ Diagramme des cas d'utilisation (Use Case Diagram) : Permet
d'identifier les possibilités d'interaction entre le système et les
acteurs.
◦ Diagramme états-transitions (State Machine Diagram) : Permet de
décrire sous forme de machine à états finis l’évolution des états
d’une partie du système.
◦ Diagramme d'activité (Activity Diagram) : Permet de décrire le
comportement d’une partie du système sous forme de flux ou
d'enchaînement d'actions.

Les diagrammes
Les diagrammes structurels ou statiques :
◦ Diagramme de classes (Class diagram) : représente
les classes intervenantes dans le système.
◦ Diagramme de composants (Component diagram) : permet de montrer les
composants du système d'un point de vue physique.
◦ Diagramme de déploiement (Deployment diagram) : sert à représenter les
éléments matériels, la manière dont les composants du système sont
répartis sur ceux-ci et interagissent entre eux.
◦ Non présentés :
◦ Diagramme des paquetages (Package diagram) : sert à représenter les dépendances entre paquetages.
◦ Diagramme d'objets (Object diagram) : sert à représenter les instances de classes (objets) utilisées dans le
système.
◦ Diagramme de structure composite (Composite Structure Diagram) : depuis UML 2.x, permet de décrire sous
forme de boîte blanche les relations entre composants d'une classe.
◦ Diagramme de profils (Profile Diagram) : depuis UML 2.2, permet de spécialiser, de personnaliser pour un
domaine particulier un meta-modèle de référence d'UML.

Les diagrammes
Les diagrammes d'interaction (ou dynamiques) :
◦ Diagramme de séquence (Sequence Diagram) : Représentation
séquentielle du déroulement des traitements et des interactions
entre les éléments du système et/ou de ses acteurs.
◦ Diagramme de collaboration (Communication Diagram) :
Représentent les interactions entre objets. Ils insistent sur la
structure statique et non dynamique (diagramme de séquence).
◦ Non présentés :
◦ Diagramme global d'interaction (Interaction Overview Diagram) : Depuis UML 2.x, permet
de décrire les enchaînements possibles entre les scénarios préalablement identifiés sous
forme de diagrammes de séquences.
◦ Diagramme de temps (Timing Diagram) : Depuis UML 2.3, permet de décrire les variations
d'une donnée au cours du temps.

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES
Diagramme de cas d’utilisation
Diagramme d’état

Le diagramme de cas
d’utilisation
Objectifs :
◦ Définir le système du point de vue des utilisateurs (les fonctions offertes par le
système),
◦ Notation compréhensible par tous, y compris les utilisateurs ou leurs représentants.
Permet de structurer :
◦ Les exigences,
◦ Les spécifications,
◦ Les conceptions,
◦ Les développements,
◦ Les tests.
29
Faire quelque chose
Un acteur
Un autre acteur
Faire autre chose
Faire ceci aussi
<<include>>
<<extend>>

Le diagramme de cas
d’utilisation
Acteur :
◦ Représente un rôle joué par un objet (personne ou chose) qui
interagit avec le système.
◦ Souvent égal à une notion de profil utilisateur dans le système.
◦ Peut représenter un système.
Héritage (cf exemple à droite) :
◦ On dit « Un autre acteur » hérite de « Un acteur »
◦ « Un autre acteur » possède toutes les capacités de « Un acteur ».
◦ Tous les cas d’utilisation auxquels « Un acteur » est associé, « Un
autre acteur » l’est aussi.
30
Un acteur
Un acteur
Un autre acteur

Le diagramme de cas
d’utilisation
Cas d’utilisation :
◦ Permet à un acteur d’atteindre un but (c’est une manière d’utiliser le système),
◦ Est piloté par l’acteur, sans interruption,
◦ Est une suite d’interactions entre l’acteur et le système, qui correspondent aux
messages qu’ils échangent.
Modélisation des cas d'utilisation :
◦ Peu standardisé par UML,
◦ Différents styles,
◦ Différentes interprétations.
Modèles construits par raffinements successifs et consensus grandissant.
Doit permettre une compréhension de l’ensemble des personnes gravitant
autour de l’application.
31
Faire quelque chose
Un cas d’utilisation

Le diagramme de cas
d’utilisation
Relation entre acteurs et cas d’utilisation :
◦ association : l’acteur participe au cas d’utilisation.
◦ Il est possible de préciser cette association :
◦ Déclencheur, bénéficiaire.
◦ Principal, secondaire
◦ …
◦ Attention à l’association unidirectionnelle qui précise le sens
(unique) des messages échangés.
32
Faire quelque chose
Un acteur
Cas d'utilisation A
Un acteur

Le diagramme de cas
d’utilisation
Relations entre cas d’utilisation :
◦ Inclusion (« include ») : un cas d’utilisation inclut un autre cas d’utilisation.
◦ Extension (« extend ») : un cas d’utilisation étend un autre cas d’utilisation.
◦ Le diagramme ci-dessous se lit :
◦ « Faire quelque chose » inclut « Faire ceci aussi ».
◦ « Faire ceci aussi » étend « Faire autre chose ».
◦ Signification concrète :
◦ « Faire ceci aussi » est obligatoirement exécuté pendant le déroulé du cas « Faire quelque chose ».
◦ « Faire ceci aussi » peut être exécuté pendant le déroulé du cas « Faire autre chose ».
33
Faire quelque chose
Un acteur
Un autre acteur
Faire autre chose
Faire ceci aussi
<<include>>
<<extend>>

Le diagramme de cas
d’utilisation
Relations entre cas d’utilisation :
◦ Héritage : Le cas d'utilisation A est une généralisation de B :
◦ B est un cas particulier de A
◦ A peut être substitué par B pour un cas précis.
 Utilisation dangereuse et non préconisée : ne le faire que si ça peut
apporter de la lisibilité à la spécification.
34
Cas d'utilisation A
Cas d'utilisation B

Le diagramme de cas
d’utilisation
Autres éléments de langage parfois utiles :
◦ Paquetage
◦ Permet de regrouper des cas d’utilisation.
◦ Pratique si de nombreux cas sont identifiés.
◦ System
◦ Permet de préciser les limites du système.
◦ A éviter car identifier des cas d’utilisation en dehors du
système est éviter : peu prêter à confusion.
35
Paquetage
Cas d'utilisation A
Cas d'utilisation B
System
Faire quelque chose
Un acteur
Un autre acteur
Faire autre chose
Faire ceci aussi
<<include>>
<<extend>>

Le diagramme de cas
d’utilisation
Spécification des cas d’utilisation :
Les diagrammes de cas d’utilisation sont insuffisant pour commencer les
développements.
N’est pas précisé dans UML.
Nécessaire car c’est l’entrant de la phase de test fonctionnel.
Plusieurs méthodes :
◦ Description des scénarios sous forme de diagramme d’activité.
◦ Définition de user stories (scénario par scénario)

Le diagramme de cas
d’utilisation
« Traiter les coupons de réduction » se fait éventuellement pendant « Réaliser une vente ».
« Traiter le paiement » est obligatoire lors du déroulé de « Réaliser une vente ».
« Traiter le paiement CB » est une sorte de « Traiter le paiement ».
On voit ici l’intérêt de l’héritage, qui permet de préciser plusieurs types de paiement. Chaque type de paiement s’inscrit au
même moment et de la même façon dans un même cas : « réaliser une vente ».
37
Caissier
Manager
Mettre à jour le
catalogue
Editer des
rapports
Réaliser une
vente
Traiter les coupons
de réduction
Traiter le
paiement
Traiter le paiement
cash Traiter le
paiement CB
Traiter le
paiement chèque
<<extend>>
<<include>>
Exemple : Système d’encaissement2018 - schneider.julien@gmail.com UNIFIED MODELING LANGUAGE

38
Le diagramme de cas d’utilisation
Exemple : le DAB Oney

39
Exemple : le DAB Oney - Inventaire des acteurs
Inventaire des acteurs du système
Acteurs externesClients
Client
Transporteur de billets
Technicien
Client Oney

40
Exemple : le DAB Oney - Diagramme de cas d’utilisation
Client
Client Oney
Transporteur de billets
Technicien
Retirer de
l'argent au
comptant
Retirer de
l'argent à crédit Réaliser la
maintenance
Ajouter des
billets
Retirer les
cartes
avalées
Saisir le code PIN
de la carte
<<include>>
<<include>>

41
Nouveau
Externe
Non modifié
Légende
DDV-CAS-01
Rechercher un
produit
<<extend>> DDV-CAS-02
Consulter la fiche
d'un produit
<<extend>>
<<extend>>
DDV-CAS-03
Ajouter un produit
au panier
DDV-CAS-04 Editer le
contenu du panier
<<extend>>
DDV-CAS-05
Confirmer la
commande
Client
DDV-CAS-00 Accéder à
Doudou Ville
<<extend>>
Régler la
commande en
ligne
<<include>>
Préparateur de commande
DDV-CAS-07 Préparer
une expédition
DDV-CAS-08 Réaliser une
expédition
Responsable préparateur
DDV-CAS-09 Valider une
expédition importante
DDV-CAS-10 Lister les
commandes à
préparer
<<extend>>
DDV-CAS-11 Lister les
expédition à expédier
<<extend>>
Administrateur
DDV-CAS-06 Annuler
tout ou partie d'une
commande
Mettre à jour le
catalogue
Exemple de diagramme de cas d’utilisation - site web « Doudou Ville »

Le diagramme de cas
d’utilisation
Exercices

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES
Diagramme d’état

Le diagramme d’activité
Objectif : Représenter le déroulé
d’un «processus» sous forme
d’enchainement d’étapes, appelées
« actions ».
Une bonne pratique est de
représenter le déroulé de haut en
bas, puis de gauche à droite.

Une action :
◦ Représente une action permettant de faire avancer le processus.
◦ Doit être rédigée sous cette forme : « verbe d’action à l’infinitif »
+ « description de l’action ».
Les transitions :
◦ Relient les activités.
◦ Sont automatiques. Lorsqu’une activité se termine, la transition
est déclenchée et l’activité suivante démarre.
◦ Peuvent indiquer des informations qui transitent.
◦ Peuvent-être conditionnées (voir slide suivant).
Couloirs (swimlane)
◦ Permet d’identifier quel objet réalise l’activité
45
Une activité
Une activité Une autre activité
Swimlane

Etat initial :
◦ Un seul par diagramme
◦ Peut être annoté pour préciser l’état au début du
processus
Etat final :
◦ Indique une fin dans le processus.
◦ Souvent plusieurs
◦ Peut être annoté pour préciser l’état à le fin du processus

Branchements conditionnels :
◦ Une condition sur une transition est
identifiée par la « guard condition » et
se représente entre crochet dans le
diagramme.
◦ Pour plus de clarté, il est préférable
d’utiliser explicitement d’une décision
(losange).
47
Calculer le coût total
Obtenir l'authorisation Prélever le compte du client
[ coût> 550€ ]
[ sinon ]
Mesurer la température
Chauffer Refroidir
[ T < 20 °C ]
[ T > 23 °C ]
Ventiler
[ T > 22 °C ]

Parallélismes / synchronisation :
◦ On représente les synchronisations au
moyen des barres de synchronisation.
◦ Les barres de synchronisation
permettent d’ouvrir et de fermer des
branches parallèles en sortie.
◦ Une barre de synchronisation ne peut
être franchie que lorsque toutes les
transitions en entrée ont été
déclenchées.
48
Chauffer
Arrêter le chauffage Aérer
Mesurer la température

Plus loin… BPMN
BPMN :
◦ « Business Process Model and Notation »
◦ n’est pas une méthode : son utilisation est laissée à l'appréciation de chacun.
◦ offre un éventail très large de concepts et son utilisation s’en retrouve donc complexe.
Un diagramme BPMN est un « diagramme d’activité d’UML » ++.
Ce qu’apporte BPMN :
◦ Un diagramme de collaboration (faux amis du diagramme du même nom en UML) qui est une extension
du diagramme d’activité d’UML.
◦ Des éléments de langage précis et nombreux :
◦ Surcharges de UML : actions, événements, branchements, pistes, données
◦ Nouveautés : conversations, chorégraphies.
BPMN doit être utilisé lorsqu’il faut décrire un processus informatique entrant dans un outil
d’exécution automatique (webmethod par exemple) de BPM (Business Process Management)
 Le diagramme d’activité UML est souvent suffisant.

Plus loin… BPMN
50
[BPMN_Poster]2018 - schneider.julien@gmail.com UNIFIED MODELING LANGUAGE

Client Préparateur de commande Société de transportResponsable préparateur
DDV-ACT-001
Construire son panier
DDV-ACT-002 Créer une
commande à partir du panier
DDV-ACT-004 Payer
la commande
DDV-ACT-005 Préparer
une expédition associée
à la commande
DDV-ACT-006 Expédier
l'expédition
Prendre en charge les colis
Livrer les colis
Recevoir le colis
DDV-ACT-007 Choisir
les adresses de
livraison et de
facturation
[ expédition partielle ]
DDV-ACT-008 Valider
l'expédition
[ montant > x € ]
[ montant < x € ]
Vérification ?
[ KO ]
[ OK ]
Exemple de diagramme d’activité –
Réaliser un achat sur le site web
Doudou ville

Exercices

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES
Diagramme d’état

Le diagramme de classes
Objectifs : Définir les concepts manipulés par l’application.
N’est pas une modélisation de la structure physique de données.
N’est pas utile que pour concevoir du code informatique en langage objet.
Eléments de langage : Class
La classe (Class) :
◦ La classe est une description abstraite d’un ensemble d’objets,
◦ La classe peut être vue comme la factorisation des éléments communs à un ensemble d’objets,
◦ Les objets ayant la même structure de données (attributs) et les mêmes comportements (méthodes)
sont regroupés en une classe,
◦ Chaque objet est dit instance de la classe, il possède ses propres valeurs pour chaque attribut mais
partage les noms d'attributs avec les autres instances de la classe.
54
MaClasse
+monAttribut
+Operation1()

55
55
Classe
Personne
Date de naissance
Nom
Prénom
Sexe
acheter ()
conduire ()
dormir ()
manger ()
Attribut
Méthode

Caractéristiques particulières
Pour une classe :
◦ Abstraite : Oui / Non
Pour un attribut :
◦ Visibilité
◦ Public « + »
◦ Protected « # »
◦ Private « - »
◦ Valeur initiale
Pour une méthode :
◦ Visibilité
◦ Public « + »
◦ Protected « # »
◦ Private « - »
◦ Paramètre
◦ Type (type primaire ou classe)
◦ Valeur par défaut
56
MaClasse
+monAttribut = valeur initiale
+Operation1(paramètre: Integer = valeur par défaut)
Utilisés pour la conception

L’héritage
On dit :
◦ « Voiture » est une classe fille de « Véhicule Roulant »
◦ « Voiture » hérite de « Véhicule ».
◦ « Voiture » est une spécialisation de « Véhicule
roulant ».
◦ « Véhicule roulant » généralise « Voiture ».
◦ « Véhicule roulant » est la classe mère de « Voiture »
Une classe fille
◦ hérite de toutes les attributs et méthodes de sa classe
mère
◦ peut ajouter ses propres attributs et méthodes.
◦ peut modifier les attributs et méthodes de sa classe
mère, on parle alors de surcharge. (Règles qui dépendent
du langage de programmation)
57
Véhicule
Voiture
Véhicule roulant
Véhicule à moteur
Vélo
Véhicule volant
Avion Deltaplane
Spécialisation Généralisation

Association :
◦ Exprime une connexion sémantique bidirectionnelle entre classes,
◦ Est une abstraction des liens qui existent entre les objets, instances des classes
associées.
Chaque terminaison d’association peut avoir les attributs :
◦ Nom
◦ Multiplicité :
◦ 1 Un et un seul
◦ 0.. 1 Zéro ou un (Optionnel)
◦ M .. N De M à N
◦ * Plusieurs
◦ 0 .. * De zéro à plusieurs
◦ 1 .. * Un à plusieurs (Au moins un)
◦ Indicateur d’agrégation
◦ … Beaucoup d’autres moins utilisés.

Une agrégation :
◦ est une association qui relie un tout aux éléments qui le composent,
◦ est représentée par un losange blanc.
La composition est une agrégation :
◦ avec une multiplicité de 1 sur le rôle agrégé,
◦ qui signifie que sans les objets agrégés, l’objet agrégat n’existe plus.
◦ qui est représentée par un losange noir.
59
Equipe
Joueur
1..*
0..*
Immeuble
Etage
1..*
CompositionAgrégation

Classe d’association :
◦ Une association peut être représentée par une classe afin d’y ajouter des attributs
et/ou des opérations
◦ Une instance de A et de B est associée à une instance de C
60
Panier Article
+prix de session: Float
Ligne de panier
+qtte: Integer
+prix de session : Float
+article choisi
1..*0..*

61
Client
+email: String
Personne
+nom: String
+prenom: String
Entreprise Panier
Commande
+numero: Integer
+etat: String
Adresse de livraison
Article
Adresse
+pays: String
+codePostal: String
+Ville: String
+voie: String
+numeroDeVoie: Integer
Adresse de facturation
Ligne de commande
+qtte commandée: Integer
+qtte préparée: Integer
+qtte expédiée: Integer
+qtte annulée: Integer
1
1..*
Ligne de panier
+qtte: Integer
+prix de session : Float
0..*
1
1
1
0..1
0..*
1
0..*
+choix en cours
0..*
1 +article choisi
1..*
0..*
+article commandé
0..*
1
+a commandé
+a été passé par
0..*
1
Exemple de diagramme de classes - site web « Doudou Ville »

Exercices

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES
Diagramme d’état

Le diagramme d’états
Le comportement des objets d’une classe peut être décrit de manière
formelle, en termes d’états et d’événements, au moyen d’un automate
à états finis (statechart) :
◦ Chaque objet (ou opération) suit le comportement décrit par l’automate et
se trouve à un moment donné dans un état qui caractérise les valeurs de
l’objet,
◦ Un état représente une situation stable pendant la vie d'un objet,
◦ L’objet satisfait alors une condition, exécute une certaine action, ou attend
un certain événement,
◦ Un objet reste dans un état pendant un temps fini.
Eléments de langage : état + transition.

Les états :
◦ Initial
◦ Intermédiaire
Ils peuvent être hiérarchisés (super-état)
◦ Finaux
A la création de l’objet, l’automate démarre toujours en état
initial.
En revanche, il est possible d’avoir plusieurs états finaux.
65
Début
Etat intermédiaire A
Fin

Une transition :
◦ est déclenchée par pendant le déroulé
d’un cas d’utilisation,
◦ provoque le passage d’un état à un autre,
◦ est instantanée,
◦ Peut être conditionnée avec du texte en
crochets « [ ] » : guard condition.
66
State1
State2
State3
[ condition ]

Faux amis en terme de formalisme du diagramme d’activités :
◦ Diagramme d’activité
◦ Représente un processus.
◦ Identifie des couloirs.
◦ Diagramme d’état
◦ Représente le cycle de vie des objets.
◦ Est une vision transverse aux processus.
◦ Permet, en autre, de vérifier que les cas d’utilisation sont tous identifiés.

Inactive
Refusée
Préparée
Expédiée
Annulée
Refusée
Préparée
Expédiée
Annulée
Active
A valider
A préparer
A valider
A préparer
[ Annulation de toute la commande ]
[ Tout est expédié ]
[ Paiement refusé ]
[ Paiement OK ]
[ Expédition préparée ]
[ Expédition partielle ]
[ Annulation d'une partie de la commande ]
[ Annulation d'une partie de la commande ]
Exemple de diagramme d’états - Classe Commande de « Doudou Ville »

Exercices

UML
LES CONCEPTS
HISTORIQUE
LES DIAGRAMMES
Diagramme d’état

Le diagramme de séquence
Les diagrammes de séquence :
◦ montrent des échanges de messages entre objets, selon un point de vue
temporel.
◦ Eléments de langage : objet + stimulus + frame.
Les diagrammes de collaboration :
◦ montrent les échanges de messages entre objets, selon un point de vue
spatial.
◦ Utilisés pour discuter d’échanges entre applications.
◦ Eléments de langage : objet + stimulus.
 Ne sera présenté ici que le diagramme de séquence.

Les objets :
◦ Diagramme de séquence :
◦ « nom de l’objet » : « nom de classe »
◦ Ligne de vie
◦ Diagramme de collaboration :
◦ « nom de l’objet » : « nom de classe »
72
Object1 : Class1
Object1 : Class1

Les stimulus :
◦ Synchrone :
◦ Création
◦ Destruction
◦ Appel de méthode
◦ Réponse
◦ Asynchrone :
◦ Envoi de message (signal)
73
Object1 : Class1 Object2 : Class2Object3 : Class2
1
<<create>>
2
<<destroy>>
3 : Operation1()
4 : Retour
5 : Signal1

Les frames :
◦ Boucle (loop)
◦ Scénario alternatif (alt)
◦ Faire référence à un autre diagramme de
séquence
◦ …
Peut rendre le diagramme compliqué à
comprendre.
◦  Utilisation à limiter : faire plusieurs
diagrammes si nécessaire.
74
tant queloop
Object1 : Class1 Object2 : Class2Object3 : Class2
1
<<create>>
2
<<destroy>>
3 : Operation1()
4 : Retour
5 : Signal1

75
Contrôleur - Traiter la demande de
fabrication en magasin d'un
support privatif
<<Gestion des supports>>
SM -Fabriquer la carte (Embosseuse)
SM - Générer le flux de fabrication
en magasin d'un support privatif
SM - Calculer les données
sécuritaires (Pistes)
<<Armoney>>
: Utilisateur
IHM - Lancer la fabrication
en magasin d'un support
privatif
<<X>>
1 : N° support préalablement créé
2 : N° support
3 : N° support
4 : MAJ - Flux de fabrication (Identifiant Fidélité)
5 : Flux de fabrication
6 : Flux de fabrication enrichi (Piste)
7 : Flux de fabrication
8 : CR du traitement de la demande de fabrication
9 : Affichage CR Exemple de diagramme de séquence – Projet chez Oney

Exercices

Génie Logiciel - Unified modeling language

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Génie Logiciel - Unified modeling language

Similaire à Génie Logiciel - Unified modeling language (20)

Génie Logiciel - Unified modeling language