Cours GL&UML-Ch2-Modélisation UML-DCL-DO

Université Sultan Moulay Slimane Ecole Supérieure de Technologie de Béni Mellal
Département: ITG Filière: Génie Informatique -2ème année - S3

Module: Génie Logiciel (M11-E1) Année universitaire: 2023-2024
Elément: Génie Logiciel & Modélisation UML
Support de cours
Génie Logiciel et Modélisation UML
Chapitre II: Modélisation UML 1
Pr. Siham BAKKOURI Email: [email protected]

Plan
❑ INTRODUCTION GÉNÉRALE
❑ INTRODUCTION À LA MODÉLISATION ORIENTÉE OBJET
❑ MODÉLISATION OBJET AVEC UML
❑ LES DIAGRAMMES ÉLÉMENTAIRES
▪ Diagramme des cas d’utilisation (Use Case Diagram)
▪ Diagramme de classes
▪ Diagramme d’objets
▪ Diagramme de séquences
❑ LES DIAGRAMMES AVANCÉS
▪ Diagramme d’état transition
▪ Diagramme d’activité
Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 2

Introduction
Pour faire face à la complexité croissante des systèmes d’information, de nouvelles méthodes
et outils ont été créées. La principale avancée des quinze dernières années réside dans la
programmation orientée objet (P.O.O.)
→ Face à ce nouveau mode de programmation, les méthodes de modélisation classique (telle
MERISE) ont rapidement montré certaines limites et ont dû s’adapter.De très nombreuses
méthodes ont également vu le jour comme Booch, OMT …
→ Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception «orientée
objet ».
→ Simula, premier langage de programmation à implémenter le concept de type abstrait à
l'aide de classes, date de 1967 ! En 1976 déjà, Smalltalk implémente les concepts
fondateurs de l'approche objet : encapsulation, agrégation, héritage.
Les premiers compilateurs C++ datent du début des années 80 et de nombreux langages
orientés objets "académiques" ont étayé les concepts objets (Eiffel, Objective C, Loops...). Il
y donc déjà longtemps que l'approche objet est devenue une réalité.

Introduction
Connaître C++ ou Java n'est donc pas une fin en soi, il faut aussi savoir les utiliser à bon
escient. La question est donc de savoir : comment comparer deux solutions de découpe objet
d'un système si l'on ne dispose pas d'un moyen de représentation adéquat ? Il est très simple
de décrire le résultat d'une analyse fonctionnelle, mais qu'en est-il d'une découpe objet ?«
→ Pour remédier à ces inconvénients majeurs de l'approche objet, il est nécessaire de :
1. un langage (pour s'exprimer clairement à l'aide des concepts objets) Le langage doit
permettre de représenter des concepts abstraits (graphiquement par exemple), limiter les
ambiguïtés (parler un langage commun, au vocabulaire précis, indépendant des langages
orientés objet), faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions).
2. Une démarche d’analyse et de conception objet est nécessaire afin de ne pas effectuer
une analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet
dès le départ, définir les vues qui permettent de décrire tous les aspects d'un système avec
des concepts objets.
Il faut donc disposer d'un outil qui donne une dimension méthodologique à l'approche
objet et qui permette de mieux maîtriser sa richesse.

Plan
▪ Diagramme de classe
▪ Diagramme d’objet
▪ Diagramme de séquence

Introduction à la modélisation orientée objet
→ Qu’est-ce qu’un modèle ?
Pour programmer une application ( développer un logiciel ), il ne convient pas de se lancer

tête baissée dans l’écriture du code : il faut d’abord organiser ses idées, les documenter,
puis organiser la réalisation en définissant les modules et étapes de la réalisation.
C’est cette démarche antérieure à l’écriture que l’on appelle modélisation ; son produit
est un modèle
Un modèle est une représentation abstraite de la réalité qui exclut certains détails du
monde réel.
• Il permet de réduire la complexité d'un phénomène en éliminant les détails qui
n’influencent pas son comportement de manière significative.
• Il reflète ce que le concepteur considère comme important pour la compréhension et la
prédiction du phénomène modélisé. Les limites du modèle dépendent des objectifs
visés par sa création.

→ Pourquoi modéliser ?
Un modèle est une simplification de la réalité qui permet de mieux comprendre le système à
développer. Il permet de :
• Visualiser le système comme il est ou comme il devrait l'être.
• Valider le modèle vis à vis des clients
• Spécifier les structures de données et le comportement du système.
• Fournir un guide pour la construction du système.
• Documenter le système et les décisions prises.

→ Les langages de modélisation
❑ Un langage de modélisation doit définir :

• La sémantique des concepts ;
• Une notation pour la représentation de concepts ;
• Des règles de construction et d'utilisation des concepts.
❑ Des langages à différents niveaux de formalisation.
• Langages formels (VDM…) : le plus souvent mathématiques, au grand pouvoir
d'expression et permettant des preuves formelles sur les spécifications
• Langages semi-formels (MERISE, UML...) : le plus souvent graphiques, au
pouvoir d'expression moindre mais plus faciles d'emploi.
❑ L'industrie du logiciel dispose de nombreux langages de modélisation :
• Adaptés aux systèmes procéduraux (MERISE...) ;
• Adaptés aux systèmes temps réel (ROOM, SADT...) ;
• Adaptés aux systèmes à objets (OMT, Booch, UML...).
❑ Le rôle des outils (Ateliers Génie Logiciel) est primordial pour l'utilisabilité en
pratique des langages de modélisation.

→ De l’approche fonctionnelle vers l’approche O.O
❑ Modélisation par décomposition fonctionnelle

Approche descendante : Décomposer la fonction globale jusqu'à obtenir des fonctions
simples à appréhender et donc à programmer.
C'est la fonction qui donne la forme du système
• Accent mis sur ce que fait le système (ses fonctions)
• Identification des fonctions du système puis décomposition en sous-fonctions,
récursivement, jusqu’à obtention de fonctions élémentaires, implémentables directement
• La fonction détermine la structure

❑ Modélisation orientée objets
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures
logicielles fondées sur les objets du système, plutôt que sur une décomposition
fonctionnelle.
C'est la structure du système lui donne sa forme.
On peut partir des objets du domaine (briques de base) et remonter vers le système global :
approche ascendante
• Accent mis sur ce qu’est le système (ses composants)
• Identification des composants du système : les objets
• Fonction = collaboration entre objets
• Les fonctions sont indépendantes de la structure
• Un objet intègre à la fois des données et des opérations

Concepts Orientés-Objet :
▪ Abstraction
▪ Encapsulation
▪ Héritage
▪ Polymorphisme
▪ objets, classes, événements, états
Un système informatique est vu comme un ensemble structuré d’éléments qui

collaborent

o Analyse OO :
– Trouver les objets
– Les organiser (les classer et les regrouper)
– Décrire leurs interactions (scénarios, interfaces)
– Définir leurs opérations (d’après les interfaces nécessaires)
– Définir l’intérieur des objets (informations stockées)
o Programmation OO :
– On peut avoir analyse OO et programmation non OO
– Le style de programmation peut être OO même avec un langage classique
• Test OO : le test peut être considéré lui-même comme un objet

Plan

Modélisation Objet avec UML
→ Evolution des Méthodes de Conception O.O
❑ 1993-1994: les auteurs de Booch, OOSE et OMT ( les méthodes Booch’93 et OMT-2 )
ont décidé de créer un langage de modélisation unifié avec pour objectifs:
• Modéliser un système des concepts à l'exécutable, en utilisant les techniques orientée
objet
• Réduire la complexité de la modélisation
• Utilisable par l'homme comme la machine
• Représentations graphiques mais disposant de qualités formelles suffisantes pour être
traduites automatiquement en code source
❑ En 1994, plus de 50 méthodes orientées objet, telles que Fusion, Shlaer-Mellor, ROOM,
Classe-Relation, Wirfs-Brock, Coad-Yourdon, MOSES, Syntropy, BOOM, OOSD,
OSA, BON, Catalysis, COMMA, HOOD, Ooram, DOORS... étaient utilisées.
Ces représentations ne disposent cependant pas de qualités formelles suffisantes pour

justifier d'aussi bonnes propriétés mathématiques que des langages de spécification
formelle (Z, VDM...).

→ Evolution des Méthodes de Conception O.O
❑ Naissance d’UML
• 1993-1994: Les 2 méthodes ( Booch’93 et OMT-2 ) deviennent leaders sur le
marché, elles sont de plus en plus proches
• Octobre 1994
o J. Rumbaugh (OMT) rejoint G. Booch chez Rational
o Annonce de l’unification des deux méthodes
• Octobre 1995: Méthode Unifiée v0.8
• Fin 1995: le fondateur d ’Objectory, Ivar Jacoson, rejoint à son tour Rational
• Janvier 97 : Soumission à l’OMG de la version UML 1.0
OMG: Object Management Group

• Organisme à but non lucratif fondé en 1989
• Plus de 700 entreprises y adhèrent
• Connu pour la norme CORBA
• Septembre 97 : UML 1.1

→ Historique
• Dernière version : UML v2.5.1 à Décembre 2017

• UML v2.0 date de 2005. Il s'agit d'une version majeure apportant des innovations
radicales et étendant largement le champ d'application d'UML

→ qu’est-ce qu’UML ?
UML : Unified Modeling Language

• Langage de Modélisation Unifié.
• Appliqué à l’analyse et à la conception des logiciels.
• Langage essentiellement graphique.
• Facile à lire et à comprendre.
UML: norme qui définit les diagrammes et les conventions à utiliser lors de la
construction de modèles décrivant la structure et le comportement d’un logiciel.
o Les modèles sont des diagrammes constitués d’éléments graphiques et de texte.
o UML n’est pas une méthode, mais un langage.

→ Les diagrammes UML
❑ UML propose 14 types de diagrammes
Les diagrammes UML peuvent être regroupés sous forme d’un diagramme de classes en
trois catégories principales en fonction de leur objectif et de ce qu'ils représentent dans la
modélisation d'un système logiciel:
→ Les diagrammes de structure (ou les diagrammes statiques) pour modéliser

l’aspect statique d’un système.
→ les diagrammes de comportement pour modéliser l’aspect plutôt dynamique d’un

système.
→ Diagrammes d'interaction (ou diagrammes dynamiques): sont une sous-catégorie

des diagrammes de comportement, se concentrant spécifiquement sur les interactions
entre les objets.

La hiérarchie des diagrammes UML 2.0

❑ Définition d’un diagramme UML
Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis
du modèle.
• Chaque type de diagramme UML possède une structure (les types des éléments
de modélisation qui le composent sont prédéfinis).
• Un type de diagramme UML offre toujours la même vue d'un système (il
véhicule une sémantique précise).
• Combinés, les différents types de diagrammes UML offrent une vue complète
des aspects statiques et dynamiques d'un système.

❑ Axes de modélisation d’un système

→ Logiciels de modélisation UML
❑ Il existe de nombreux outils logiciels de modélisation UML.

❑ Aucun d'entre eux ne respecte strictement aucune des versions de UML, particulièrement
UML2
o Logiciels open-source: StarUML, ArgoUML, Papyrus UML, BOUML…
o Logiciels payants: WinDesign, PowerAMC, Rational Rose, Visual Paradigm …

Plan

Diagramme de Cas d’utilisation
→ Modélisation des besoins
Avant de développer un système, il est essentiel de déterminer précisément À QUOI il

devra servir et quels besoins il devra satisfaire.
❑ Modéliser les besoins permet de :
▪ Faire l'inventaire des fonctionnalités attendues.
▪ Organiser les besoins de manière à faire apparaître des relations (possibilités de

réutilisation, etc.).
Avec UML, on modélise les besoins au moyen de diagrammes de cas d'utilisation.

→ Modélisation des besoins
❑ Un diagramme de cas d'utilisation décrit
• le système
• les acteurs
• les cas d'utilisation
❑ Il contient: des descriptions textuelles
→ Le système
• Le système est un ensemble de cas d'utilisation

• Le système ne comprend pas les acteurs. Nom de système
Nom de système

→ Les acteurs
Un acteurs est une entité extérieure au système modélisé, et qui interagit directement avec
lui. Exemple: un client, un guichetier, un responsable maintenance, Une même personne
peut jouer plusieurs rôles.
Un acteur exécute un ou plusieurs cas d'utilisation, et est représenté par:
• un petit bonhomme (stick man) avec son nom en dessous
• par un rectangle contenant le mot-clé << actor>> avec son nom (Un acteur non-
Humain)
• Par un mélange de ces 2 représentations
« actor »
Nom de l’acteur
▪ Pour les identifier:

Quelles sont les entités externes au système qui interagissent directement avec le système ?

→ Les acteurs
❑ Identification des acteurs

• Les principaux acteurs sont les utilisateurs du système.
• Une même personne physique peut être représentée par plusieurs acteurs si elle a
plusieurs rôles.
• Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront représentées
par un seul acteur. En plus des utilisateurs, les acteurs peuvent être :
• Des périphériques manipulés par le système (imprimantes...) ;
• Des logiciels déjà disponibles à intégrer dans le projet ;
• Des systèmes informatiques externes au système mais qui interagissent avec lui, etc.
Attention
Un acteur correspond à un rôle, pas à une personne physique.

→ Les acteurs
• Description des acteurs → Pour chaque acteur :

- Choisir un identificateur représentatif de son rôle
- Donner une brève description textuelle
Exemple:
- Un guichetier est un employé de la banque. Interface entre le

système informatique et les clients.
- Il peut effectuer une série d'opérations : création d'un compte,
Guichetier dépôt et retrait d 'argent, etc.
• Utilité des acteurs : La définition d'acteurs permet;

o D'identifier les cas d'utilisation
Exemple: Que peut faire un guichetier ? un client ? le directeur ?
o De voir le système de différents points de vues
o De déterminer des droits d'accès par type d'acteur
o De fixer des ordres de priorité entre acteurs

→ Les acteurs: acteurs principaux et secondaire

❑ L'acteur est considéré comme principal pour un cas d'utilisation lorsque c'est lui qui
initie les échanges nécessaires pour réaliser ce cas d'utilisation.
❑ Les acteurs secondaires sont sollicités par le système, tandis que le plus souvent, ce
sont les acteurs principaux qui prennent l'initiative des interactions.
En général, les acteurs secondaires représentent d'autres systèmes informatiques avec
lesquels le système développé est interconnecté.

→ Les acteurs: relations entre les acteurs
❑ Une seule relation possible : la généralisation.

→ Les cas d'utilisation

Un cas d'utilisation est un service rendu à l'utilisateur, il implique des séries d'actions plus
élémentaires.
Cas d’utilisation
o Un cas d'utilisation est représenté par un ovale.
o Un cas d’utilisation se représente par une ellipse contenant le nom du cas
d’utilisation (phrase commençant par un verbe à l’infinitif)
o Il est relié par des associations « participe à » à ses acteurs
• Un cas d'utilisation (use case) décrit:

o Une fonctionnalité du système vue par un acteur (et utile à ce dernier)
o Une suite d'interactions entre un utilisateur et le système qui produit un résultat
observable et intéressant pour un acteur particulier
o Un comportement attendu du système du point de vue d'un ou de plusieurs acteurs
o Un service rendu par le système
• Pour les identifier:

par acteur, quelles sont les différentes manières d'utiliser le système ?

→ Les cas d'utilisation
❑ Recenser les cas d'utilisation

• Il n'y a pas une manière mécanique et totalement objective de repérer les cas
d'utilisation.
• Il faut se placer du point de vue de chaque acteur et déterminer comment il se sert
du système, dans quels cas il l'utilise, et à quelles fonctionnalités il doit avoir
accès.
• Il faut éviter les redondances et limiter le nombre de cas en se situant au bon
niveau d'abstraction (par exemple, ne pas réduire un cas à une seule action).
• Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut rester au
niveau des grandes fonctions du système.
• Trouver le bon niveau de détail pour les cas d'utilisation est un problème difficile
qui nécessite de l'expérience.

Exemple:

→ Relations entre cas d'utilisation et acteurs

• Les acteurs impliqués dans un cas d'utilisation lui sont liés par une association.
• Un acteur peut utiliser plusieurs fois le même cas d'utilisation.
→ Relations entre les cas d'utilisation
❑ Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A)
❑ Extension : le cas B étend le cas A (A est une partie optionnelle de B)
❑ Généralisation : le cas A est une généralisation du cas B (B est une sorte de A).

→ Dépendances d'inclusion et d'extension

❑ Les inclusions et les extensions sont représentées par des dépendances.
▪ Lorsqu'un cas B inclut un cas A, B dépend de A.
▪ Lorsqu'un cas B étend un cas A, B dépend aussi de A.
▪ On note toujours la dépendance par une flèche pointillée B - -> A qui se lit: B
dépend de A .
❑ Lorsqu'un élément A dépend d'un élément B, toute modification de B sera susceptible
d'avoir un impact sur A.
❑ Les include et les extend sont des stéréotypes (entre guillemets) des relations de
dépendance.
Attention
Le sens des flèches indique le dépendance, pas le sens de
la relation d'inclusion.


❑ Réutilisabilité avec les inclusions et les extensions
Exemple: Les relations entre cas permettent la réutilisabilité du cas « s'authentifier » : il
sera inutile de développer plusieurs fois un module d'authentification


❑ Décomposition grâce aux inclusions et aux extensions
Quand un cas est trop complexe (faisant intervenir un trop grand nombre d'actions), on
peut procéder à sa décomposition en cas plus simples.

→ Généralisation
Exemple:
• Un virement est un cas particulier de paiement.
• Un virement est une sorte de paiement.
• La flèche pointe vers l'élément général.
→ 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?

→ Description des cas d'utilisation
• Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de
vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas
d'utilisation.
• Un simple nom est tout à fait insuffisant pour décrire un cas d'utilisation.
• Chaque cas d'utilisation doit être documenté pour qu'il n'y ait aucune ambiguïté
concernant son déroulement et ce qu'il recouvre précisément.
❑ Description textuelle
Une description textuelle d’un cas d’utilisation se compose de trois parties : identification,
description des scénarios et exigence non fonctionnelle

→ Description des cas d'utilisation

Exemple 1 : Description textuelle de cas d’utilisation : ‘Ajouter une commande’

Exemple 2 : Description textuelle de cas d’utilisation : ‘S’authentifier’

Exemple 2 : Description textuelle de C.U : Payer CB - Enchaînements alternatifs

o Identification : 1. En (2) : si le numéro est incorrect, le client est
- Nom du cas : Payer CB averti de l'erreur, et invité à recommencer
- Objectif : Détailler les étapes permettant à client 2. En (3) : si les informations sont erronées, elles
de payer par carte bancaire sont re-demandées au client
- Acteurs : Client, Banque (secondaire) - Post-conditions
- Date : 18/09 ‥ La commande est validée
- Responsables : Toto ‥ Le compte de l'entreprise est crédité
- Version : 1.0
o Séquencements :
- Le cas d'utilisation commence lorsqu'un client o Rubriques optionnelles
demande le paiement par carte bancaire - Contraintes non fonctionnelles :
- Pré-conditions ‥ Fiabilité : les accès doivent être sécurisés
‥ Le client a validé sa commande ‥ Confidentialité
- Enchaînement nominal - Contraintes liées à l'interface homme-
1. Le client saisit les informations de sa CB
machine :
2. Le système vérifie que le numéro de CB est correct
3. Le système vérifie la carte auprès du Sys.Ban
‥ Toujours demander la validation des
4. Le système demande au système bancaire de opérations bancaires
débiter le client
5. Le système notifie le client du bon déroulement de
la transaction

Exemple
Nous disposons des cas d'utilisation suivants :
1. Passer une commande
2. Passer une commande urgente
3. Suivre une commande
4. Valider l'utilisateur
5. Expédier commande totale ou partielle
• Le suivi de la commande englobe l'ensemble du processus, depuis la commande initiale
jusqu'à l'expédition.
• Cependant, il peut arriver que certaines commandes passées ne soient pas expédiées.
• Il convient de noter que passer une commande urgente est un cas particulier de passer
une commande.
• Pour passer une commande, il est impératif de valider l'utilisateur.
Présentez les cas d'utilisation et identifiez leurs relations de dépendance.

Exemple

Exercice 1
Un comptable est chargé du traitement des factures d'une entreprise.

Chaque fois qu'il traite une facture, il doit effectuer un calcul de remise, même si la
remise est de 0%. De plus, les factures étrangères nécessitent un traitement spécial.
Donner un diagramme de cas d'utilisation UML qui représente cette situation en

identifiant les acteurs et les cas d'utilisation principaux, ainsi que leurs interactions

Exercice 2
Un système de gestion de magasin doit permettre aux clients :

• D'entrer dans le magasin,
• De parcourir les rayons,
• De poser des questions au besoin,
• D'essayer des produits,
• D'acheter des articles (sous réserve de disponibilité en stock),
• De se rendre à la caisse pour effectuer le paiement en utilisant divers modes de
paiement acceptés,
• De bénéficier de réductions.
Identifiez les acteurs et les cas d'utilisation principaux de ce système, puis
représentez leurs interactions dans un diagramme de cas d'utilisation UML.

Plan

Diagramme de Classes
• Les diagrammes de cas d'utilisation modélisent à QUOI sert le système : le système est
composé d'objets qui interagissent entre eux et avec les acteurs pour réaliser ces cas
d'utilisation.
• Le diagramme de classes exprime la structure statique du système en termes de classes

et de relations entre ces classes
• L’intérêt du diagramme de classe est de modéliser les entités du système d’information
• Le diagramme de classes est sans doute le

diagramme le plus important à représenter pour les
méthodes d’analyse orientées objet ➔ C’est le point
central de tout développement orienté objet.

→ Définitions et principes de base
• Un diagramme de classes est une collection d'éléments de modélisation statique qui

montre la structure d'un modèle.
• Un diagramme de classes fait abstraction des aspects dynamiques et temporels du

Système
• Concepts et instances
o Une instance est la concrétisation d'un concept abstrait.
Exemple:
- Concept : Stylo
- Instance : le stylo que vous utilisez à ce moment précis est une instance du concept
stylo: il a sa propre forme, sa propre couleur, son propre niveau d'usure, etc.

→ Définitions et principes de base
• Un objet est une instance d'une classe
• Une classe est une description abstraite d’un ensemble d’objets du domaine de
l’application : elle définit leur structure, leur comportement et leurs relations
• Une classe représente la description d’un ensemble d’objets possédant les mêmes
caractéristiques : elle spécifie la manière dont tous les objets de même type seront
décrits (désignation, label, auteur, etc).
• Un lien est une instance d'association. Il représente la relation entre deux ou plusieurs
entités.

→ Représentation
Le diagramme de classes met en œuvre des classes, contenant des attributs et des
opérations, et reliées par des associations ou des généralisations.

→ Représentation d’une classe
❑ Classe
Une classe est représentée par un rectangle séparé en trois parties:
▪ La première partie représente le nom de la classe

▪ La deuxième partie représente les attributs de la classe
▪ La troisième partie représente les opérations de la classe
Formalisme Exemple
Nom de classe
- Attribut 1: int=val-init
- Attribut 2: float
…..
+ Opération1(): int
+ Opération2(): void
…….


❑ Les attributs
- Un attribut représente la modélisation d’une information élémentaire représentée par
son nom et son format.
- UML définit 4 niveaux de visibilité pour les attributs :
• public (+) : l’élément est visible par tous les membres de la classe
• protégé (#) : L'élément est visible dans la classe où il est déclaré et dans ses sous-
classes.
• privé (-) : l’élément n’est visible que par les objets de la classe dans laquelle il est
déclaré
• package (~) : propriété ou classe visible uniquement dans le paquetage où la classe
est définie.
- Syntaxe de la déclaration d'un attribut :
visibilité nomAtt: type [ multiplicité ]= valeurInit


❑ Les attributs
- L’identifiant est un attribut particulier, qui permet de repérer de façon unique chaque objet,
instance de la classe.
❑ Les attributs dérivés
• Les attributs dérivés peuvent être calculés à partir d'autres attributs et des formules de
calcul.
• Les attributs dérivés sont symbolisés par

l'ajout d'un / devant leur nom.
• Attribut dérivé : attribut dépendant d’autres

attributs.
• Lors de la conception, un attribut dérivé peut

être utilisé comme marqueur jusqu'à ce que vous Souvent destiné à devenir une méthode
puissiez déterminer les règles à lui appliquer.


❑ Les opérations
• Une opération représente un élément de comportement des objets, défini de manière
globale dans la classe.
• Une opération est une fonctionnalité assurée par une classe. La description des opérations
peut préciser les paramètres d’entrée et de sortie ainsi que les actions élémentaires à
exécuter.
• Comme pour les attributs, on retrouve 4 niveaux de visibilité pour les opérations
(Publique, Privée, protégée et package)
• La syntaxe de la déclaration d'une opération est la suivante :

visibilité nom_méthode ([paramètre_1, ..., param_N]) : type_renvoyé
• La syntaxe de la liste des paramètres est la suivante :
[NomClasse]<nom_paramètre>:type =valeur_par_défaut


❑ Méthodes et Opération
• Une opération est la spécification d'une méthode (sa signature) indépendamment de son
implémentation.
• UML 2 autorise également la définition des opérations dans n'importe quel langage
donné.
Exemples de méthodes pour l'opération fact(n:int):int :

❑ Attributs de classe
• Par défaut, les valeurs des attributs définis dans une classe diffèrent d'un objet à un
autre. Parfois, il est nécessaire de définir un attribut de classe qui garde une valeur
unique et partagée par toutes les instances.
• Graphiquement, un attribut de classe (static) est souligné
❑ Opérations de classe
• Similaires aux attributs de classe
• Les opérations de classe sont des propriétés de la classe, et non de ses instances.
• Contrairement aux objets de la classe, elles n'ont pas accès aux attributs des
instances de la classe.
• Les opérations de classe représentent généralement les comportements ou les
actions que les objets de la classe peuvent effectuer.

❑ Notation complète

→ Les relations entre classes
Il existe plusieurs types de relations entre classes :
• Une association représente une relation sémantique entre les objets d'une classe.
• Une relation d'agrégation décrit une relation de contenance ou de composition.
• Une relation d'héritage est une relation de généralisation/spécialisation permettant
l'abstraction.

1. Association
• Une association est une relation entre deux classes qui décrit les connexions structurelles
entre leurs instances.
• Une association indique donc qu’il peut y avoir des liens entre des instances des classes
associées.
• Elle est représentée par un trait entre classes.
Exemple:

1. Association
Les propriétés d'une association entre deux classes comprennent plusieurs éléments
paramétrables :
• Nom de l’association : Une association peut être nommée. Le nom est situé près de la
terminaison de l'association. Cependant, ce nom est facultatif.
• Nom de rôle: indication sur la participation de la classe à l’association
• Multiplicité: définit le nombre d’instances de l’association pour une instance de la classe
• Navigabilité: La navigabilité précise la direction dans laquelle la navigation est possible,

indiquant si un objet peut naviguer de l'un à l'autre ou dans les deux sens.
Ces propriétés sont essentielles pour définir correctement l'association entre les classes dans
un modèle UML.

1. Association
a) Multiplicités des associations
• La notion de multiplicité permet le contrôle du nombre d'objets intervenant dans chaque

instance d'une association.
Exemple : un article n'appartient qu'à une seule catégorie (1) ; une catégorie concerne plus de
0 articles, sans maximum (*).
• La syntaxe est :
MultMin .. MultMax
• * à la place de MultMax signie plusieurs sans préciser de nombre
• n..n se note aussi n , et 0..* se note *

1. Association
a) Multiplicités des associations

Exemple : Dans ce diagramme, le nom de l’association est Travailler, le nom du rôle de la
classe Personne pour l’association est: Employé. Le diagramme se lit comme suit :
✓ Une personne travail pour une seule entreprise.
✓ Dans une entreprise il y a une à plusieurs personnes

1. Association
b) Navigabilité d'une association
• La navigabilité permet de spécifier dans quel(s) sens il est possible de traverser

l'association à l'exécution.
• On restreint la navigabilité d'une association à un seul sens à l'aide d'une flèche.
Exemple :Connaissant un article on connaît les commentaires, mais pas l'inverse.

- On peut aussi représenter les associations navigables dans un seul sens par des attributs.


1. Association
c) Association Binaire
• Dans une association binaire la multiplicité sur la terminaison cible contraint le nombre
d'objets de la classe cible pouvant être associés à un seul objet donné de la classe source
(la classe de l'autre terminaison de l'association).
• Une association binaire est matérialisée par un trait plein entre les classes associées.
• Elle peut être ornée d'un nom, avec éventuellement une précision du sens de lecture
(▸ou◂).
• Quand les deux extrémités de l'association pointent vers la même classe, l'association est
dite réflexive.

1. Association
i. Association unidirectionnelle de 1 vers 1
ii. Association bidirectionnelle de 1 vers 1

1. Association
iii. Association unidirectionnelle de 1 vers *
iii. Association bidirectionnelle de * vers *

1. Association
e) Association n-aire
• Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque classe
s'applique sur une instance de chacune des classes, à l'exclusion de la classe-association et
de la classe considérée.
• Une association n-aire lie plus de deux classes.
• On représente une association n-aire par un grand losange avec un chemin partant vers
chaque classe participante. Le nom de l'association, le cas échéant, apparaît à proximité du
losange.

1. Association
e) Association n-aire
Exemple
Si (A,B,C) représente un triplet d’instances de type ( Personne, Profession, Entreprise ) :

• Pour obtenir la multiplicité côté C , on fixe un couple d’instances (A,B) et on examine le nombre
d’instances Cmin et Cmax qui lui sont reliées à travers l’association .
• Même raisonnement pour trouver les multiplicités côté A ou côté B .
• Par exemple : Une personne ayant une profession ( couple (A,B ) fixé ) peut être employée
dans 0 à plusieurs entreprises selon l’association « Emploie » alors qu’elle peut posséder 0 ou 1
employeur ( entreprise ) selon l’association « Emploi actuel » .
1. Association
d) Association Réflexive
• Dans ce type d'association, les deux extrémités de l'association pointent vers la même
classe. Cela signifie qu'une classe est associée à elle-même.
• L'association la plus utilisée est l'association binaire (reliant deux classes).
• Dans les associations réflexives, les rôles des classes associées sont souvent obligatoires.
Cela signifie qu'une instance de la classe doit être associée à au moins une autre instance
de la même classe.

1. Association
d) Association Réflexive
Exemple: Association réflexive n-aire

1. Association
f) Classe- Association
• Une association peut être raffinée et avoir ses propres attributs, qui ne sont disponibles
dans aucune des classes qu'elle lie.
• Comme, dans le modèle objet, seules les classes peuvent avoir des attributs, cette
association devient alors une classe appelée classe-association
• Une classe-association possède les caractéristiques des associations et des classes : elle
se connecte à deux ou plusieurs classes et possède également des attributs et des
opérations.

1. Association
f) Classe- Association
Exemple
• l'association Emploie entre une société et une personne possède comme propriétés le salaire et la date
d'embauche.
• En effet, ces deux propriétés n'appartiennent ni à la société, qui peut employer plusieurs personnes,
ni aux personnes, qui peuvent avoir plusieurs emplois.
• Il s'agit donc bien de propriétés de l'association Emploie. Les associations ne pouvant posséder de
propriété, il faut introduire un nouveau concept pour modéliser cette situation : celui de classe-
association.
1. Association
g) Association dérivée
• Une association dérivée est conditionnée ou peut être déduite à partir d'autres autres
associations. On utilise également le symbole « / ».

❑ Les Contraintes sur les associations
Il existe plusieurs types de contraintes sur les associations :
a– Contrainte de partition
• Elle indique que toutes les instances d’une classe correspondent à une et une seule
instance des classes liées.
→ Toutes les sociétés sont soit clientes, soit considérées comme des prospects

b– Contrainte d’exclusion
Elle permet de préciser qu’une instance d’association exclut une autre instance.
→ Un employé ne peut être à la fois directeur financier et directeur commercial.

c– Contrainte de totalité
• Toutes les instances d’une classe correspondent au moins à une des instances des classes
liées.
→Toute société est au moins partenaire ou client privilégiée. Et elle peut être les 2 à la
fois.
d– Contrainte d’inclusion {sous-ensemble}
• Elle permet de préciser qu’une collection est incluse dans une autre collection. (la flèche
de la relation de dépendance indique le sens de la contrainte).

2. Association de type Agrégation
• Une agrégation est une forme particulière d'association. Elle

représente la relation d'inclusion d'un élément dans un ensemble.
• On représente l'agrégation par l'ajout d'un losange vide du côté de

l'agrégat.
• Une agrégation dénote une relation d'un ensemble à ses parties.

L'ensemble est l'agrégat
et la partie l'agrégé. → Lorsque l'on souhaite modéliser une relation
tout/partie où une classe constitue un élément plus grand (tout)
composé d'éléments plus petits (partie), il faut utiliser une
agrégation.
3. Association de type Composition
• La relation de composition décrit une contenance structurelle entre instances.
• On représente la composition par un losange plein.
• La destruction et la copie de l'objet composite (l'ensemble) impliquent respectivement la

destruction ou la copie de ses composants (les parties).
• Une instance de la partie n'appartient jamais à plus d'une instance de l'élément composite

❑ Composition et agrégation
• Lorsqu'il existe une relation du tout à ses parties, nous parlons d'agrégation ou de
composition.
• La composition également appelée agrégation composite ou agrégation forte.
• Pour décider entre l'usage de la composition et de l'agrégation, il est essentiel de se poser
les questions suivantes :
1. Est-ce que la destruction de l'objet composite (le tout) entraîne nécessairement la
destruction des objets composants (les parties) ?
2. Lorsque le composite est copié, doit-on également copier les composants ou peut-
on les réutiliser ?
Si les réponses à ces deux questions sont affirmatives, alors l'utilisation de la composition
est appropriée.

❑ Composition et agrégation
Exemple

4. Relation d’héritage
• L'héritage une relation de spécialisation/généralisation.
• Les éléments spécialisés héritent de la structure et du comportement des éléments plus
généraux (attributs et opérations)
Exemple :
• La classe enfant possède toutes les propriétés de
ses classes parents (attributs et opérations)
• La classe enfant est la classe spécialisée (ici
Livre)
• La classe parent est la classe générale (ici
Article)
• Toutefois, elle n'a pas accès aux propriétés
privées.

❑ Les Interfaces
• Le rôle d'une interface est de regrouper un ensemble d'opérations assurant un service
cohérent offert par un classeur et une classe en particulier.
• Une interface est dénie comme une classe, avec les mêmes compartiments. On ajoute le
stéréotype « interface » avant le nom de l'interface.
• On utilise une relation de type réalisation entre une interface et une classe qui
implémente.
• Les classes implémentant une interface
doivent implémenter toutes les opérations
décrites dans l'interface

❑ Les Interfaces
Exemple
1er notation
2ème notation

❑ Classe paramétrée
• Pour définir une classe générique et paramétrable en fonction de valeurs et/ou de types :
Définition d'une classe paramétrée par des éléments spécifiés dans un rectangle en
pointillés
• Utilisation d'une dépendance stéréotypée «bind » pour définir des classes en fonction
de la classe paramétrée.
• Java : généricité
• C++ : templates

Exercice 3
• Une personne est caractérisée par son nom, son prénom, son sexe et son âge.
• Les objets de classe Personne doivent pouvoir calculer leurs revenus et leurs
charges.
• Les attributs de la classe sont privés, le nom, le prénom ainsi que l'âge de la
personne doivent être accessibles par des opérations publiques.
1. Donnez une représentation UML de la classe Personne, en remplissant tous les
compartiments adéquats.
• Deux types de revenus sont envisagés : d'une part le salaire et d'autre part
toutes les autres sources de revenus. Les deux revenus sont représentés par
des nombres réels (float).
• Pour calculer les charges globales, on applique un coefficient fixe de 20% sur
les salaires et un coefficient de 15% sur les autres revenus.
2. Enrichissez la représentation précédente pour prendre en compte ces nouveaux
éléments.

Exercice 4
Pour chacun des énoncés suivants, donnez un diagramme de classes :
1. Tout écrivain a écrit au moins une œuvre
2. Les personnes peuvent être associées à des universités en tant qu'étudiants aussi bien
qu’en tant que professeurs.
3. Un rectangle a deux sommets qui sont des points. On construit un rectangle à partir
des coordonnées de deux points. Il est possible de calculer sa surface et son périmètre,
ou encore de le translater.
4. Les cinémas sont composés de plusieurs salles. Les films sont projetés dans des salles.
Les projections correspondantes ont lieu à chacune à une heure déterminée.

Plan

Diagramme d’objets
→ Définitions
• Le diagramme d'objets représente les objets d'un système à un instant donné.

Il permet de :
o Illustrer le modèle de classes (en montrant un exemple qui explique le modèle)
o Préciser certains aspects du système (en mettant en évidence des détails

imperceptibles dans le diagramme de classes)
o Exprimer une exception (en modélisant des cas particuliers, des connaissances non
généralisables. . . )
Le diagramme de classes modélise des règles et le diagramme d'objets

modélise des faits

→ Représentation des objets
- Comme les classes, on utilise des cadres compartimentés.
- En revanche, les noms des objets sont soulignés et on peut rajouter son identifiant devant
le nom de sa classe.
Exemple:
- Les valeurs (a) ou l'état (f) d'un objet peuvent être spécifiées.
- Les instances peuvent être anonymes (a, c, d), nommées (b, f), orphelines (e), multiples
(d) ou stéréotypées (g).

→ Diagramme de classes et diagramme d'objets
• Le diagramme de classes contraint la structure et les liens entre les objets.
• Le diagramme d’objets cohérent avec le diagramme de classes :
D. de classes D. d’objets

→ Les liens
• Un lien est une instance d'une association.
• Un lien se représente comme une association mais s'il a un nom, il est souligné.
→ Relation de dépendance d'instanciation
• La relation de dépendance d'instanciation (stéréotypée) décrit la relation entre un

classeur et ses instances.
• Elle relie, en particulier, les associations aux liens et les classes aux objets.
Attention
On ne représente pas les
multiplicités qui n'ont aucun
sens au niveau des objets.

Plan

Cours GL&UML-Ch2-Modélisation UML-DCL-DO

Transféré par

Droits d'auteur :

Formats disponibles

Cours GL&UML-Ch2-Modélisation UML-DCL-DO

Transféré par

Informations du document

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

Cours GL&UML-Ch2-Modélisation UML-DCL-DO

Transféré par

Droits d'auteur :

Formats disponibles

Université Sultan Moulay Slimane Ecole Supérieure de Technologie de Béni Mellal

Département: ITG Filière: Génie Informatique -2ème année - S3

Chapitre II: Modélisation UML 1

Pr. Siham BAKKOURI Email: [email protected]

❑ INTRODUCTION À LA MODÉLISATION ORIENTÉE OBJET

❑ MODÉLISATION OBJET AVEC UML

❑ LES DIAGRAMMES ÉLÉMENTAIRES

▪ Diagramme des cas d’utilisation (Use Case Diagram)

❑ LES DIAGRAMMES AVANCÉS

▪ Diagramme d’état transition

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 2

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 3

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 4

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 5

→ Qu’est-ce qu’un modèle ?

Pour programmer une application ( développer un logiciel ), il ne convient pas de se lancer

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 6

• Visualiser le système comme il est ou comme il devrait l'être.

• Valider le modèle vis à vis des clients

• Spécifier les structures de données et le comportement du système.

• Fournir un guide pour la construction du système.

• Documenter le système et les décisions prises.

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 7

→ Les langages de modélisation

❑ Un langage de modélisation doit définir :

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 8

→ De l’approche fonctionnelle vers l’approche O.O

❑ Modélisation par décomposition fonctionnelle

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 9

→ De l’approche fonctionnelle vers l’approche O.O

❑ Modélisation orientée objets

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 10

→ De l’approche fonctionnelle vers l’approche O.O

❑ Modélisation orientée objets

Un système informatique est vu comme un ensemble structuré d’éléments qui

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 11

→ De l’approche fonctionnelle vers l’approche O.O

❑ Modélisation orientée objets

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 12

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 13

→ Evolution des Méthodes de Conception O.O

Ces représentations ne disposent cependant pas de qualités formelles suffisantes pour

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 14

→ Evolution des Méthodes de Conception O.O

OMG: Object Management Group

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 15

• Dernière version : UML v2.5.1 à Décembre 2017

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 16

UML : Unified Modeling Language

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 17

→ Les diagrammes UML

❑ UML propose 14 types de diagrammes

→ Les diagrammes de structure (ou les diagrammes statiques) pour modéliser

→ les diagrammes de comportement pour modéliser l’aspect plutôt dynamique d’un

→ Diagrammes d'interaction (ou diagrammes dynamiques): sont une sous-catégorie

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 18

→ Les diagrammes UML

La hiérarchie des diagrammes UML 2.0

Pr. S. BAKKOURI Génie Logiciel & Modélisation UML 19

→ Les diagrammes UML