Cours UML 2020

Hela LAJMI
Conception des SI Assistant Professor

LSIM2
Héla Lajmi
Plan
Chapitre 1: Introduction
1. Système d’information
2. Cycle de vie d’un logiciel
3. Conception des SI
4. Concepts importants de l’approche objet
Chapitre 2: Conception des SI

1. Introduction
2. Historique UML
3. Diagrammes UML
4. Types de visualisations
Types de visualisation dans UML
Visualisation « Use Cases » Visualisation Logique
Vue fonctionnelle Vue Dynamique Vue Statique
D. des cas d’utilisation D. activité D. Classe

D. Collaboration
D. Objet
D. Séquence
D. composant
D. Etat
D. déploiement
Système d’information
• On peut décomposer le terme Système d’information en :
Système : Ensemble de composantes travaillant en collaboration pour
accomplir une tache particulière portant des données initiales.
Information :elle doit être collectée, vérifiée, validée, représentée,

codée, stockée et bien manipulée.
l'informatique est au cœur de toutes les grandes entreprises. Le système
d'information d'une entreprise est composé de matériels et de logiciels.
Les logiciels
• Le cycle de vie d'un logiciel désigne toutes les étapes du
développement d'un logiciel, de sa spécification et conception à sa
disparition.
• L'objectif d'un tel découpage est de permettre de définir des jalons
intermédiaires permettant la conformité du logiciel avec les besoins
exprimés, et la vérification du processus de développement
(l'adéquation des méthodes mises en œuvre)
Cycle de vie d’un Logiciel (en cascade)
Cycle de vie d’un Logiciel (en V)
Conception des SI
Le système d’information (SI) englobe donc deux aspects :
*Les méthodes d’analyse et de conception (Modèle E/A…) et,
*Les environnements de programmation (modèle relationnel…)
Pourquoi modéliser et qui doit modéliser??

Pourquoi Modéliser?
Modéliser un système avant sa réalisation permet de:
• mieux comprendre le fonctionnement du système.
• maîtriser sa complexité
• assurer sa cohérence
• assurer la bonne communication entre les membres de l’équipes et par conséquent,
aboutir à une compréhension commune aux différentes parties prenantes d'un problème
donné.
Pourquoi Modéliser? (suite)
• mieux répartir les tâches et automatiser certaines d'entre elles
• Réduire les coûts et les délais
• générer automatiquement le code et effectuer des allers-‐retours entre le code et le
modèle sans perte d'information
• assurer un bon niveau de qualité et une maintenance efficace
Méthodologies d’analyse et de conception
• Approche Fonctionnelle:
Exemple SADT, Modélisation que du traitement (les données non) pour les applications peu
complexe.
• Approche Systémique:
Exemple Merise, Modélisation des données et des traitements séparément pour des applications de
complexité moyenne.
• Approche Orientée Objet:

Exemple OMT, Modélisation des objets (encapsulation des données et des traitements) pour tout
type d’application.
Les approches structurés (fonctionnelle ou systémique) ne sont pas adaptés à la
conception et au développement des applications qui évoluent souvent dont la
complexité croit continuellement.
è Ces applications nécessitent une maintenabilité accrue, manquent de

traçabilité, de modularité, d’extensibilité et de réutilisabilité.
L’approche Orientée objet: consiste à modéliser informatiquement un ensemble

d’éléments d’une portée du monde réel en un ensemble d’entités informatiques
appelés OBJETS.
L’approche Orientée objet
Quel que soit la complexité et l’évolution des applications, on peut réussir à les
modéliser et développer par l‘approche OO.
Avantage de l’OO:
ØLa modularité: la programmation modulaire permet la réutilisation du code, via
l’écriture de librairie
ØLa réutilisabilité: réutilisabilité des composantes logiciels (encapsulation,

généralisation, polymorphisme)
L’approche Orientée objet
ØL’extensibilité (pour une meilleure productivité des développeurs et une plus
grande qualité des applications)
ØLa traçabilité: ce qu’on fait en conception, on trouve son image en
programmation.
ØLa maintenabilité: l'application peut être facilement maintenue, probablement

par une autre équipe et, qui plus est, pas nécessairement de la même société que
celle ayant créé l'application.
Concepts importants de l’approche objet
l'approche objet rapproche les données et leurs traitements. Mais
cette approche ne fait pas que ça, d'autres concepts importants sont
spécifiques à cette approche et participent à la qualité du logiciel.
Qu’est ce qu’un objet?
• Un objet est une entité qui possède une identité (un titre écrit en
Majuscule ).
• Un ensemble d'attributs caractérise l'état de l'objet (les données)
• Un ensemble d'opérations (méthodes) en définissent le

comportement (le traitement).
• Un objet est une instance de classe (une occurrence d'un type abstrait).
• Une classe est un type de données abstrait, caractérisé par des propriétés
(attributs et méthodes) communes à des objets et permettant de créer
des objets possédant ces propriétés.
Encapsulation
• L'encapsulation consiste à masquer les détails d'implémentation d'un
objet, en définissant une interface. L'interface est la vue externe d'un
objet, elle définit les services accessibles (offerts) aux utilisateurs de
l'objet.
• L'encapsulation garantit l'intégrité des données, car elle permet

d'interdire, ou de restreindre, l'accès direct aux attributs des objets
Encapsulation
centraliser les données d'un type et les traitements associés, dans une
même unité physique, permet de limiter les points de maintenance
dans le code et facilite l'accès à l'information en cas d'évolution du
logiciel :
Héritage
L'héritage est un mécanisme de transmission des caractéristiques d'une
classe (ses attributs et méthodes) vers une sous-‐classe.
Plusieurs classes peuvent être généralisées en une classe qui les

factorise, afin de regrouper les caractéristiques communes d'un
ensemble de classes.
Héritage simple ou multiple
L'héritage peut être simple ou multiple. L'héritage évite la duplication

et encourage la réutilisation.
Polymorphisme
Le polymorphisme représente la faculté d'une méthode à pouvoir

s'appliquer à des objets de classes différentes. Le polymorphisme
augmente la généricité, et donc la qualité, du code.
Agrégation
Il s'agit d'une relation entre deux classes, spécifiant que les objets
d'une classe sont des composants de l'autre classe. L'agrégation
permet donc d'assembler des objets de base, afin de construire des
objets plus complexes.
Exemple:
Notion de classe
Une classe est un type de données abstrait qui précise des
caractéristiques (attributs et méthodes) communes à toute une famille
d'objets et qui permet de créer (instancier) des objets possédant ces
caractéristiques.
Plan
Chapitre 2
•Introduction
• Historique
• Diagrammes UML
• Types de visualisations
Pourquoi un langage de modélisation Unifié?
• Difficultés de l’échange de modèles entre équipes de concepteurs et entre
concepteurs et clients.
• Synergie de compétence: différents modèles pour une même application

développée par différentes équipes de concepteurs avec différentes méthodes.
UML: Unified Modelling Language
Ø Est le standard pour la Conception orientée Objet des Systèmes d’Information.
Ø Est un langage formel qui couvre le cycle de développement des logiciels de la
spécification des besoins à l’implantation.
Ø Est un support de communication :

• conséquence de la standardisation
• On peut faire travailler des équipes différentes avec des méthodes
différentes sur les parties d’une même application.
UML: Unified Modelling Language
Ø La structure des diagrammes UML et la notation graphique des

éléments de modélisation sont normalisées
ØUML n’est pas un processus de développement

ØUML n’est pas un langage de programmation
Plan
Chapitre 2
• Introduction
•Historique
• Diagrammes UML
Historique
• 1993-‐1994 1995 1996 01 - 1997 11 - 1997

Soumission à Adoption par
l’OMG l’OMG
Booch’93
jan.
Autres Unified Method 0.8 UML 0.9 UML 1.0 UML 1.1
OMT - 2 Partenaires Normalisation
OOSE
en 1999
Autres tentatives d’unification de
méthodes : UML 1.3
Fusion et Eurométhode
UML 2.0
Plan
Chapitre 2
• Introduction
• Historique
•Diagrammes UML
Diagrammes UML
• Neuf diagrammes représentant chacun un aspect particulier du SI à modéliser :
• de cas d’utilisation : décrivent les vues utilisateurs du système,
• de classes : décrivent les classes et les liens qui les relient,
• d’objets : représentent des instances de diagrammes de classes,
• de composants: décrivent les dépendances de compilation ou d’exécution entre les

différents modules constituant un logiciel,
• les diagrammes de déploiement: décrivent les unités de programmes et leurs processus
d’affectation.
Diagrammes UML
• d’états-‐transitions : décrivent les cycles de vie des objets,
• de collaboration : décrivent les interactions entre les objets,

• de séquence : représentent des diagrammes de collaboration ordonnés dans le
temps,
• d’activités : décrivent la sémantique des méthodes en termes d’actions,

Bibliographie
• Muller, P. A., & Gaertner, N. ( 2000). Modélisation objet avec UML (Vol. 514). Paris: Eyrolles.
• Piechocki, L. ( 2007). UML, le langage de modélisation objet unifié. Laurent piechnocki. développez. com.
• Laurent, G. ( 2007) Modélisation orientée objets avec UML.
• Faiez. G ( 2015). Cours Modélisation orientée objets UML.

Plan
Chapitre 2
• Introduction
• Historique
• Diagrammes UML
•Types de visualisations
• Vue Fonctionnelle
• Vue statique
• Vue dynamique
Vue Fonctionnelle Vue Dynamique Vue Statique

D. Collaboration
D. Objet
==> Les différents types de
D. Séquence
diagrammes UML combinés offrent une D. composant
vue complète des aspects statiques et D. Etat
D. déploiement
dynamiques d'un système.
Vue fonctionnelle Vue Dynamique Vue Statique

D. Collaboration
D. Objet
D. Séquence
D. composant
D. Etat
D. déploiement
Plan
Chapitre 2
• Introduction
• Historique
• Diagrammes UML
•Vue Fonctionnelle
• Vue statique
• Vue dynamique
Vue Fonctionnelle: Diagramme des cas
d’utilisation «Use cases»
• Un cas d’utilisation décrit un ensemble d’actions réalisées par le système
qui produit un résultat observable pour un acteur
• Son objectif est de structurer les besoins des utilisateurs et les objectifs
(fonctionnalités) correspondants d'un système.
• Un bon Use Case représente une fonctionnalité du système qui est complète du
début jusqu’à la fin.
«Use cases»
Position des UC dans un processus de modélisation
Spécifications
Use Cases
Analyse Tests
Commencer par établir le diagramme des cas permet de :

Ø mener un développement orienté utilisateur et
Ø de découper le système global en grandes tâches qui pourront être
réparties entre les équipes de développement.
«Use cases» acteurs
• Les acteurs sont déterminés en examinant les utilisateurs directs du système et
leurs responsabilités. Ils sont représentés sous forme de petits personnages ou
sous forme de rectangle avec le mot clé <<acteur>>
«Use cases» acteurs
• Les acteurs :
• Doivent être décrits d’une manière simple et précise avec des phrases en langage naturel
• Peuvent être reliés par des liens de généralisation/spécialisation
Exemples de types d’acteurs :

• Humains : les utilisateurs du logiciel à travers son interface graphique
• Logiciels : déjà disponibles qui communiquent avec le système grâce à une interface logicielle
• Matériels : robots et automates qui exploitent les données du système ou qui sont pilotés par
le système
«Use cases»: relation simple
«Use cases»: relation d’inclusion « include »
• Relation d’inclusion entre cas d'utilisation
• L’instance du CU source contient aussi le comportement décrit par le CU destination.
• La relation d’inclusion a un caractère obligatoire: La source doit indiquer à quel endroit le CU
cible doit être inclus
• Permet de décomposer les comportements et définir des comportements partageables entre
plusieurs CU.
«Use cases»: relation d’extension « extend »
• Relation d’inclusion entre cas d'utilisation
• L’instance du CU source ajoute son comportement au CU destination (si la
condition est réalisée).
• Le CU destination étend son comportement par l’ajout de celui du CU source,
si la condition est vérifiée.
«Use cases»: relations de spécification
« Use cases »
• Un cas d’utilisation :
• Regroupe une famille de scénarios d’utilisation
• Est une abstraction du dialogue système/utilisateurs
• Quand un acteur interagit avec le système:

• Le cas d’utilisation instancie un scénario
• L'ensemble des cas d’utilisation décrit les objectifs du système

• Utilité des cas d’utilisation pour :
• les utilisateurs : exprimer les besoins
• Les analystes : comprendre
• Les programmeurs : réaliser
• Les testeurs : vérifier
Description des cas d’utilisation
Sommaire d’identification
Titre : ……………….. Type : …………………
Résumé :………………………………………………………………………………
Acteurs :
Date de création : Date de mise à jour :…………………………………
Version : Auteur(s) :
Description des Enchaînements :

Pré conditions :
Scénario nominal :
1.
2.
…
Enchaînements alternatifs :
A1…
A2…
Contraintes
….
Description des cas d’utilisation
◦ Quelques conseils :
◦ Un cas d’utilisation doit être :
◦ Simple
◦ Décrit de manière claire et concise
◦ Le nombre d’acteurs interagissant avec le CU doit être limité
◦ Lors de la construction d’un CU, il faut se demander :
◦ Quelles sont les tâches de l’acteur ?
◦ Quelles informations l’acteur doit-‐il créer, sauvegarder, modifier, détruire ou simplement lire ?
◦ L’acteur devra-‐t-‐il informer le système des changements externes ?
◦ Le système devra-‐t-‐il informer l’acteur des conditions internes ?
Modélisation objet avec UML

P.A. Muller, N. Gaertner
Exercice: Caisse enregistreuse
(extrait de UML par la pratique, Pascal Roques, Eyrolles)
Le déroulement normal d’utilisation de la caisse est le suivant :

Ø Un client arrive à la caisse avec des articles à payer
Ø Le caissier enregistre le numéro d’identification de chaque article, ainsi que la quantité si elle
est supérieure à 1
Ø La caisse affiche le prix de chaque article et son libellé
Ø Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente la caisse affiche le
total des achats
Exercice: Caisse enregistreuse
Ø Le client choisit son mode de paiement : liquide (le caissier encaisse l’argent reçu, la caisse indique la
monnaie à rendre au client), chèque , carte de crédit (la caisse transmet une demande d’autorisation
à un centre d’autorisation)
Ø La caisse enregistre la vente et imprime un ticket.
Ø Le caissier donne le ticket de caisse au client.
Lorsque un paiement est terminé, la caisse transmet les informations sur le nombre d’articles vendus au
système de gestion de stocks.
Tous les matins, le responsable du magasin initialise la caisse pour la journée.
Travail demandé: Modéliser le diagramme des cas d’utilisation de la caisse

enregistreuse
Correction: Caisse enregistreuse
Exemple de Cas d’utilisation
Sommaire d’identification
Titre : Traiter le passage en caisse

Résumé : un client arrive à une caisse avec des articles à acheter. Le caissier enregistre les achats et
récupère le paiement. A la fin de l’opération, le client part avec les articles.
Acteurs : Caissier (P), Client (S), Gestion des stock (S)
Date de création : Date de mise à jour :…………………………………
Version : 1 Auteur(s) : FG
Description des Enchaînements :
Pré conditions : La caisse est en service : un caissier y est connecté

Scénario nominal :
Représente le déroulement normal d’un cas d’utilisation : les différentes interactions utilisateur /
système permettant l’exécution réussie du traitement
(voir suite)
1. Ce CU commence quand un client arrive à la caisse
avec des articles qu’il veut acheter.
2. Le caissier enregistre chaque article. S’il y a plus d’un 3. La caisse détermine le prix de l’article et ajoute des
exemplaire par article, le caissier indique également la informations sur l’article à la vente en cours.
quantité.
La caisse affiche la description et le prix de l’article en
question.
4. Après avoir enregistré tous les articles, le caissier 5. La caisse calcule et affiche le montant total de la vente.
indique que la vente est terminée.
6. Le caissier annonce le montant total au client.
7. Le client choisit le type de paiement :

a. En cas de paiement …
b. En cas de …
c. En cas …
8. La caisse enregistre la vente et imprime …
9. Le caissier donne le ticket de caisse au client.

• Enchaînement alternatif :
• Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler
comme prévu :
• Le cas d’utilisation converge tout de même.
• Exemple:
• Numéro d’identification d’un article est inconnu
l’enchaînement démarre au point 2 du scénario nominal.

3. La caisse indique que le numéro d’identification de l’article est inconnu. L’article ne
peut alors pas être pris en compte dans la vente encours.
Le scénario reprend au point 2.

• Enchaînement d’erreur :
• Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler :
• Le cas d’utilisation se termine par un échec.
• Exemple:
• Client ne pouvant payer (ou le centre d’autorisation refuse le payement)
l’enchaînement démarre au point 6 du scénario nominal.
7. Le client ne peut pas payer le total avec aucun des moyens autorisés.
8. Le caissier annule l’ensemble de la vente et le cas d’utilisation se termine en échec :
à la vente ne peut pas avoir lieu
Conclusion
• Les cas d’utilisation :
• Sont de bons moyens pour modéliser les besoins des utilisateurs par les utilisateurs.
• Les avantages :
• Un formalisme simple :
• Les concepts proposés sont faciles à comprendre et à utiliser.
• Les modélisations résultats (UC):

• Faciles à comprendre, à lire et à interpréter.
• Un bon moyen de communication : client/concepteur et concepteur/concepteur

Conclusion
• Les limitations :
• Subjectifs, dépendant de l’utilisateur :
• Peuvent être peu précis, ne reflétant pas les besoins majeurs de l’utilisateur ou
interprétés différemment.
• Pas formels : pas de vérification automatique possible ni de génération des autres
diagrammes, …
Plan
Chapitre 2
• Introduction
• Historique
• Diagrammes UML
• Vue statique
• Vue dynamique

D. Collaboration
D. Objet
D. Séquence
D. composant
D. Etat
D. déploiement
Vue Statique
Diagramme de classe
Le diagramme de classe permet de donner une vue statique du
système en terme de :
• Classes d’objets
• Relations entre classes,
• Associations
• Composition/agrégation
• héritage
Vue Statique
Diagramme de classe: Attributs
Les attributs et les opérations sont décrits dans le deuxième et troisième
compartiments .
Le type des attributs peut être :

• Un type primitif : Entier, chaîne, …
• Une classe (type utilisateur) : Etudiant, Rectangle, …
• Expression complexe non supportée par UML
• Remarques :
• Opération = méthode
• Attribut = propriété.
Vue Statique
Diagramme de classe: Attributs
• La syntaxe de description des attributs est :
Visibilité NomAttribut [[Multiplicité] :

Type [ValeurInitiale] [{Propriété}]]
• Visibilité = type d'accessibilité :

+ : public: visible et modifiable par tout objet du même paquetage
-‐: private: seulement visible et modifiable par les opérations de l'objet auquel il
appartient.
# : protected: seulement accessible et modifiable par les opérations des classes
descendantes
Vue Statique
Diagramme de classe: Opération
• La syntaxe de description des opérations est :
Visibilité NomOpération [[Arguments] :
TypeRetourné [{Propriété}]]
• Visibilité : +, -‐, #
• Arguments :
Direction NomArgument : TypeArgument [= ValeurDefaut]
Classe
+Attributpublic
#Attributprotégé Attribut de classe
-Attributprivé
AttributDeClasse Visibilité globale: l’attribut est
considéré comme un objet partagé
De méme pour par les instances d’une classe
les opérations
Vue Statique
Diagramme de classe: Relations et associations
• Les relations entre classes :
• Association
ADHERENT
• Agrégation Nom
emprunter EXEMPLAIRE
• Composition Prénom
Adrsse
• Héritage
• Les associations :
• Une association exprime une connexion sémantique bidirectionnelle entre deux
classes.
• Une association est instanciable dans un diagramme d'objets ou de collaboration
sous forme de liens entre objets issus des classes associées.
Vue Statique
• Constatations :
Association
Diagramme de classes C1 C2
Lien
:C1 :C2 :C1 :C2
Diagramme d’objets Diagramme de collaboration

Vue Statique
Diagramme de classe: Cardinalités des associations
• Les associations :
• représentent des liens statiques/conceptuels entre objets et à longue
durée de vie (n’est pas un lien instantané ni passager).
• Relient une ou plusieurs classes : arité 1 ou plus Card: Min .. Max
• Par rapport au modèle Entité / Association :
Entité 1 Entité 2
Card1 Card2
Diag. Entité / P11, P21,
Ass
Association P12 P22
… …
Diag. De classes CEntité1 Card2 Card1 CEntité2

Vue Statique
Diagramme de classe: Cardinalités des associations
précisent le nombre d'instances qui participent à une relation.
• Combien d’objets de la classe considérée peuvent être liés à un objet de l’autre classe?
1 Un et un seul
0 .. 1 Zéro ou un
N N (entier naturel)
M .. N De M à N (entiers naturels)
* De 0 à plusieurs
0 .. * De 0 à plusieurs
1 .. * De 1 à plusieurs
Vue Statique
Diagramme de classe: Contraintes des associations
• Les associations : Contraintes
• des expressions qui précisent le rôle ou la portée d'un élément de modélisation
• permettent d'étendre ou de préciser la sémantique
• permettent de restreindre le nombre d'instances visées
• peuvent s'exprimer en :
• Langage Naturel ou
• graphiquement avec un {texte} ou
• En OCL (Object Constraint Language)
• Les types de contraintes exprimables sur les associations :
• Ordonné;
• Sous-ensemble;
• Ou-exclusif, …
Vue Statique
• Les associations : Contraintes
• Ordonné : Personne
1 0..*
Compte
{ordonné}
• La collection des comptes d’une personne est triée
• Sous-ensemble :
Service 1 affecter 1..* Employé

Numéro_S Numéro
{sous-ensemble} Nom
Nom_S
... ....
0..1 1
diriger
Vue Statique
• Ou-exclusif :Indique que pour un objet donné, une seule association
est valide
BATTERIE
PORTABLE
{Ou-exclusif}
Alimenter SECTEUR
Cette contrainte permet d’éviter l’introduction de classes artificielles
Alimenter ENERGIE
PORTABLE
SECTEUR BATTERIE
Vue Statique
Diagramme de classe: Classe d’association
• Classe d'association :
• est une classe qui réalise la navigation entre les instances d'autres classes.
• représente les associations porteuses de données.
Passe >
ETUDIANT EXAMEN
NOTE
Remarque : classe d’association (Cde, Client, Facture)& attribut de lien (Cde, produit, QteCdée)
Vue Statique
• Les associations : Notion de rôle
• Rôle des associations (utilisé pour les associations ambiguës) :
• spécifie la fonction d'une classe pour une association donnée
Client Parents
HÔTEL PERSONNE PERSONNE
Directeur Enfants
Vue Statique
Diagramme de classe: Agrégation et composition
• La composition est une agrégation forte.

• si le composé est détruit (ou copié), ses composants le sont aussi.
• une instance de composant ne peut être liée qu'à un seul composé.
• Les "objets composites" sont des instances de classes
composées.
COUVERTURE LIVRE CHAPITRE
Agrégation Composition
Remarque : toutes les conventions relatives aux cardinalités restent valables

pour les Agrégations et les compositions
Vue Statique
Diagramme de classe: Généralisation
• La généralisation :
• L’héritage, avec UML, est désigné par GENERALISATION
• La généralisation peut être
• Simple ou
GENARALISATION
Est Un
SPECIALISATION
• Multiple :
• La spécialisation a plus qu’une généralisation
Vue Statique
Diagramme de classe: Généralisation
Remarque : une classe généralisée peut être spécialisée selon ≠ critères

Vue Statique
Diagramme de classe: Les packages
• regroupent des éléments de modélisation (EM) : classes, associations et packages.
• encapsulent des EM correspondant à une fonctionnalité particulière.
• servent de "briques" de base dans la construction d'une architecture logicielle
• représentent le bon niveau de granularité pour la réutilisation.
CLIENT Vision Micro. Vision Macro.
Client
Commande CLIENT FACTURATION
*
concerner 1
1 acheter
Facturation:: * Relation
Facture Produit d’utilisation
COMPTABILITE
Utiliser la classe Facture du package Facturation
Relation entre diagramme de classe et
diagramme d’objet
Est une instance de
1,N 0,N
Lien Objet Relation Classe
1, N 1, N
Est une instance de

diagramme d’objet
diagramme d’objet
• Représentation des objets :
• Un groupe d’objets :
:Personne
• Le rectangle représentant un objet peut comporter une partie contenant les
valeurs des attributs de l’objet :
Ahmed : ADHERENT : V OITURE

Nom = Mohamed Couleur = rouge
Prénom = Ahmed Puissance = 4
Adresse = Sfax Marque = Peugeot
Vue Statique
Diagramme d’objets
• Un diagramme d'objets UML représente une instance spécifique d'un
diagramme de classes à un moment précis. Dans sa représentation visuelle, il
est très similaire à un diagramme de classes.
Les diagrammes d’objets montrent :

• des objets (instances de classes dans un état particulier) et
• des liens (relations sémantiques) entre ces objets.
Vue Statique
Diagramme d’objets
Un développeur trouvera les diagrammes d’objets utiles pour:
• Étudier une itération spécifique d'un système général
• Obtenir une vue d'ensemble du système à développer
• Tester un diagramme de classes en utilisant des diagrammes d'objets
pour des cas d'utilisation spécifiques
Vue Statique
Diagramme des composants
• Decrivant les dépendances physique et statique d’une application en

terme de composants : fichiers sources (.java, .cpp, .h, .cs...) librairies
(dll, jar...), executables...
• Utilisé pour éviter de parler de classes, ou de packages
Vue Statique
Diagramme des composants
• Exemple (ref: UML2: De l'apprentissage à la pratique)
La relation de dépendance est utilisée dans les diagrammes de composants pour indiquer qu'un
élément de l'implémentation d'un composant fait appel aux services offerts par les éléments
d'implémentation d'un autre composant.
Vue Statique
Diagramme des deploiement
Décrivant l’architecture physique ainsi que les relations entre les

composants logiciels et matériels d’une application en expliquant le
déploiement de l’application en terme de réseau et de communication
Vue Statique
Diagramme des déploiement
• Exemple (ref: UML2: De l'apprentissage à la pratique)
Dans un diagramme de déploiement, les associations entre nœuds sont des chemins de
communication qui permettent l'échange d'informations
Plan
Chapitre 2
• Introduction
• Historique
• Diagrammes UML
• Vue statique
• Vue dynamique

D. Collaboration
D. Objet
D. Séquence
D. composant
D. Etat
D. déploiement
Vue Dynamique
Diagramme de collaboration
Ø Représente le contexte d'une interaction en y précisant les états des
objets en collaboration (interaction).
Ø présente des rôles joués par des objets dans un contexte particulier et les
liens entre ces objets.
Ø montre :
• des interactions entre objets (instances de classes et acteurs).
• les interactions entre ces objets par des envois de messages
Vue Dynamique
Ø permet:
• une représentation (structure) spatiale des objets, des liens et des interactions
(graphe dont les nœuds = intervenants et les arcs = les interactions).
• Une dimension temporelle (ordre de déclenchement) par l’ajout de numéros de
séquence des messages échangés (on ne représente pas le t de déclenchement
ni la durée).
àL’objectif est de construire un modèle expliquant la coopération entre les objets

utilisés pour la réalisation d’une fonctionnalité.
Vue Dynamique
• Relation entre D. cas d’utilisation et D. collaboration :
• Les acteurs du diagramme de cas d’utilisation sont aussi présents au niveau
du diagramme de collaboration
• Les cas d’utilisation se transforment en un ou plusieurs messages échangés
entre les intervenants du diagramme de collaboration
• Il y a plus d’intervenants et de liens au niveau du diagramme de collaboration
qu’au niveau du diagramme de cas d’utilisation
Vue Dynamique
• Dans un diagramme de collaboration :
• les interactions sont représentées par les échanges de messages.
• l’ordre des messages peut être indiqué par leur énumération.
• Plusieurs types de messages existent : simples, synchrones, asynchrones et
minutés.
• Conventions graphiques :
• les objets sont représentés par un rectangle dont le nom et la classe sont
soulignés.
Nom Objet Nom Objet : Classe :Classe

Vue Dynamique
• Représentation Générale :
3: opération (paramètre)
2 : opération
1 : événement
Objet1 : nom classe Objet 2
4 : opération
5 : opération (paramètres)
Objet 3 :nom de la classe

Nom acteur :
Nom de la classe
Flux de données
Vue Dynamique
• Une collaboration :
• Est la réalisation d’une opération ou d’un cas d’utilisation dans un contexte particulier.
• Possède deux types de descriptions :
• Une description générale au niveau spécification, donnant:
• Les rôles joués par les intervenants et les rôles des associations
• Une interaction : une séquence de messages partiellement ordonnés échangés
entre les rôles des intervenants
• Une description spécifique au niveau instance, représentant :

• Une instance particulière d’une interaction avec les objets et les liens respectant
les rôles définis au niveau spécification, et les stimulus (instances des messages)
échangés entre ces objets.
PA Muller, N. Gaertner
Vue Dynamique
Exemple:
1:total:=valeurStock()
:Entreprise
1.1.1 : Créer(0,0) :SRéel
:C lient 2:afficher(total)
1.1.2.i : ajout(p)
1.1 : calculValeur()
:Stock :Produit
:Afficheur
1.1.2 * [i:=1..n]:p:=ValeurP()
Vue Dynamique
Considérons le diagramme de cas d’utilisation suivant:
Vue Dynamique
Le diagramme de collaboration correspondant est :
2.1 : Rédiger
2.2 : Envoi de papier
Auteur Comité
1 : Appel à communication
d'organisation
3 : Adresser le papier
Comité
5 : Papier enregistré
programme
6 : Affecter Lecteur
7.1 : Evaluer
4 : Enregistrer
Lecteur RAPPORT
7.2 : Note
PAPIER

Langue

Cours UML 2020

Transféré par

Informations du document

Titre original

Copyright

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 :

Cours UML 2020

Transféré par

Droits d'auteur :

Hela LAJMI

Conception des SI Assistant Professor

Chapitre 2: Conception des SI

Vue fonctionnelle Vue Dynamique Vue Statique

D. des cas d’utilisation D. activité D. Classe

Information :elle doit être collectée, vérifiée, validée, représentée,

Le système d’information (SI) englobe donc deux aspects :

*Les méthodes d’analyse et de conception (Modèle E/A…) et,

*Les environnements de programmation (modèle relationnel…)

Pourquoi modéliser et qui doit modéliser??

• mieux comprendre le fonctionnement du système.

• maîtriser sa complexité

• assurer sa cohérence

• Réduire les coûts et les délais

modèle sans perte d'information

• Approche Orientée Objet:

è Ces applications nécessitent une maintenabilité accrue, manquent de

L’approche Orientée objet: consiste à modéliser informatiquement un ensemble

Avantage de l’OO:

ØLa réutilisabilité: réutilisabilité des composantes logiciels (encapsulation,

ØLa maintenabilité: l'application peut être facilement maintenue, probablement

• Un ensemble d'attributs caractérise l'état de l'objet (les données)

• Un ensemble d'opérations (méthodes) en définissent le

• L'encapsulation garantit l'intégrité des données, car elle permet

Plusieurs classes peuvent être généralisées en une classe qui les

L'héritage peut être simple ou multiple. L'héritage évite la duplication

Le polymorphisme représente la faculté d'une méthode à pouvoir

• Synergie de compétence: différents modèles pour une même application

Ø Est un support de communication :

Ø La structure des diagrammes UML et la notation graphique des

ØUML n’est pas un processus de développement

• 1993-­‐1994 1995 1996 01 - 1997 11 - 1997

• de classes : décrivent les classes et les liens qui les relient,

• d’objets : représentent des instances de diagrammes de classes,

• de composants: décrivent les dépendances de compilation ou d’exécution entre les

• de collaboration : décrivent les interactions entre les objets,

• d’activités : décrivent la sémantique des méthodes en termes d’actions,

• Laurent, G. ( 2007) Modélisation orientée objets avec UML.

• Faiez. G ( 2015). Cours Modélisation orientée objets UML.

Vue Fonctionnelle Vue Dynamique Vue Statique

D. des cas d’utilisation D. activité D. Classe

Vue fonctionnelle Vue Dynamique Vue Statique

D. des cas d’utilisation D. activité D. Classe

Commencer par établir le diagramme des cas permet de :

Exemples de types d’acteurs :

• Quand un acteur interagit avec le système:

• L'ensemble des cas d’utilisation décrit les objectifs du système

Description des Enchaînements :

Modélisation objet avec UML

Le déroulement normal d’utilisation de la caisse est le suivant :

Ø La caisse affiche le prix de chaque article et son libellé

Tous les matins, le responsable du magasin initialise la caisse pour la journée.

Travail demandé: Modéliser le diagramme des cas d’utilisation de la caisse

Titre : Traiter le passage en caisse

Description des Enchaînements :

Pré conditions : La caisse est en service : un caissier y est connecté

6. Le caissier annonce le montant total au client.

7. Le client choisit le type de paiement :

9. Le caissier donne le ticket de caisse au client.

l’enchaînement démarre au point 2 du scénario nominal.

Le scénario reprend au point 2.

• Les modélisations résultats (UC):

• Un bon moyen de communication : client/concepteur et concepteur/concepteur

Vue Fonctionnelle Vue Dynamique Vue Statique

D. des cas d’utilisation D. activité D. Classe

• 1993-‐1994 1995 1996 01 - 1997 11 - 1997