Cours GL&UML-Ch2-Modélisation UML - DCU

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: s.bakkouri@usms.ma

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 classe
▪ Diagramme d’objet
▪ Diagramme de séquence
❑ 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

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
▪ Diagramme de cas d’utilisation (Use Case Diagram)

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.

Cours GL&UML-Ch2-Modélisation UML - DCU

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours GL&UML-Ch2-Modélisation UML - DCU

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: s.bakkouri@usms.ma

❑ 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

❑ Définition d’un diagramme UML

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

→ Les diagrammes UML