You are on page 1of 35

1- Introduction à la modélisation UML

Pr. Abdelhay HAQIQ (ahaqiq@esi.ac.ma)


Plan
❑ Historique de la modélisation

❑ Diagrammes UML

❑ Diagrammes UML par rapport aux 4+1 Vues

❑ Besoins des utilisateurs

❑ Aspects fonctionnels

❑ Architecture

Pr. Abdelhay HAQIQ UML 2


Plan
❑ Historique de la modélisation

❑ Diagrammes UML

❑ Diagrammes UML par rapport aux 4+1 Vues

❑ Besoins des utilisateurs

❑ Aspects fonctionnels

❑ Architecture

Pr. Abdelhay HAQIQ UML 3


Pourquoi modéliser ?
o Un modèle est une simplification de la réalité qui permet de mieux comprendre le système à
développer.
o Il permet de:
– Simplifier la problématique posée par le client
– 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.

o Cela permet de :
– Minimiser au maximum les erreurs lors de la phase de programmation, car durant cette phase, les
erreurs sont beaucoup plus coûteuses en temps, donc en argent.
– Assurer la cohérence et éviter la redondance des données
– Assurer la conformité du logiciel aux exigences du client

Pr. Abdelhay HAQIQ UML 4


Historique
Il existe deux approches de modélisation et de programmation :
o Approche fonctionnelle
– 1960 – fin 1970
– L'important c'est les traitements
– Séparation nette des données et traitements
▪ MERISE
o Approche objet
– 1980 – début 1990 : premières génération
– L'important c'est l'objet
– Objet = données + traitements

Pr. Abdelhay HAQIQ UML 5


MERISE
o MERISE est une méthode française née dans les années 70, développée initialement
par Hubert Tardieu. Elle fut ensuite mise en avant dans les années 80, à la demande du
Ministère de l'Industrie qui souhaitait une méthode de conception des SI.
o Signification de MERISE :
– MERISE = Methode pour Rassembler les Idées Sans Effort
– MERISE = Méthode Eprouvée pour Retarder Indéfiniment la Sortie des Etudes
– MERISE = Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise

o Elle possède un certain nombre de modèles qui sont répartis sur 4 niveaux :
– niveau conceptuel : MCC, MCT, MCD
– niveau organisationnel : MOT, MOD, MOC
– niveau logique : MLD, MLT, MLC
– niveau physique : MPD, MPT, MPC

Pr. Abdelhay HAQIQ UML 6


Historique
Début des années 1990 :
o Plusieurs équipes proposent alors des méthodes qui, pour la plupart, modélisent les mêmes
concepts fondamentaux dans différents langages, avec une terminologie, des notations et
des définitions différentes:
– méthode OOD de Grady Booch (1991)
– méthode OMT de James Rumbaugh (1991)
– méthode OOSE de Ivar Jacobson (1991)
– méthode OOA/OOD de Coad and Yourdon (1992)
– méthode de Schlaer and Mellor (1992)
– Etc.

o Les différents protagonistes conviennent rapidement du besoin d’unifier ces langages en un


standard unique;
– D’où la naissance de UML (Unified Modeling Language)

Pr. Abdelhay HAQIQ UML 7


Historique
o Fin 1994
– OMT + OOD
– Unified Method (oct 1995)

o Fin 1995
– Unified Method + OOSE
– UML 0.9 (juin 1996)

o Début 1997
– UML 1.0 (jan 1997)

o Fin 1997
– OMG (Object Management Group) retient UML 1.1 comme norme de modélisation

❖ OMG (Object Management Group) : association américaine à but non lucratif créée en 1989 dont
l’objectif est de standardiser et promouvoir le modèle objet sous toutes ses formes

Pr. Abdelhay HAQIQ UML 8


Historique
Les versions se succèdent :
o Début 1998
– UML 1.2
o En 1998
– UML 1.3
o En 2001
– UML 1.4
o En 2003
– UML 1.5
o En 2005
– UML 2.0
o En 2008
– UML 2.2
o La dernière version diffusée par l'OMG est UML 2.5.1 depuis Décembre 2017

Pr. Abdelhay HAQIQ UML 9


Plan
❑ Historique de la modélisation

❑ Diagrammes UML

❑ Diagrammes UML par rapport aux 4+1 Vues

❑ Besoins des utilisateurs

❑ Aspects fonctionnels

❑ Architecture

Pr. Abdelhay HAQIQ UML 10


UML
o UML (Unified Modeling Langage) est un langage de modélisation graphique, et n’est pas une méthode

o Il est conçu pour représenter, construire et documenter des systèmes logiciels utilisant les techniques
orientées objet.

o Il permet la création de plusieurs modèles d’un même système, chacun privilégiant un aspect différent :
fonctionnel, dynamique, statique

o UML offre un standard de modélisation, pour:


– visualiser : chaque symbole graphique a une sémantique
– spécifier : de manière précise et complète, sans ambiguïté,
– construire : les classes, les relations SQL peuvent être générées automatiquement
– documenter : les différents diagrammes, notes, contraintes, exigences seront présentés dans un document.

o UML propose 13 types de diagrammes, leur utilisation est laissée à l'appréciation de chacun, même si le
diagramme de classes est généralement considéré comme l'élément central d'UML.

o Les diagrammes UML sont dépendants hiérarchiquement et se complètent, de façon à permettre la


modélisation d'un projet tout au long de son cycle de vie.

Pr. Abdelhay HAQIQ UML 11


Axes de modélisation des diagrammes

Pr. Abdelhay HAQIQ UML 12


Hiérarchie des diagrammes

Pr. Abdelhay HAQIQ UML 13


Plan
❑ Historique de la modélisation

❑ Diagrammes UML

❑ Diagrammes UML par rapport aux 4+1 Vues

❑ Besoins des utilisateurs

❑ Aspects fonctionnels

❑ Architecture

Pr. Abdelhay HAQIQ UML 14


Les 4+1 Vues
o Une façon de mettre en œuvre UML est de considérer différentes vues qui peuvent se
superposer pour collaborer à la définition du système :

Pr. Abdelhay HAQIQ UML 15


Plan
❑ Historique de la modélisation

❑ Diagrammes UML

❑ Diagrammes UML par rapport aux 4+1 Vues

❑ Besoins des utilisateurs

❑ Aspects fonctionnels

❑ Architecture

Pr. Abdelhay HAQIQ UML 16


Les 4+1 Vues : Besoins des utilisateurs
o Besoins des utilisateurs : décrit le contexte, les acteurs ou les utilisateurs du projet logiciel, les
fonctionnalités du logiciel mais aussi les interactions entre ces acteurs et ces fonctionnalités.

o On utilise dans cette vue :


– le diagramme de package
– le diagramme de cas d’utilisation

Pr. Abdelhay HAQIQ UML 17


Vue Besoins des utilisateurs
o Diagramme de packages permet de décomposer le système en catégories ou parties plus
facilement observables, appelés « packages ». Cela permet également d’indiquer les acteurs
qui interviennent dans chacun des packages.

Pr. Abdelhay HAQIQ UML 18


Vue Besoins des utilisateurs
o Diagramme de cas d’utilisation représente les fonctionnalités (ou dit cas d’utilisation)
nécessaires aux utilisateurs. On peut faire un diagramme de cas d’utilisation pour le logiciel
entier ou pour chaque package.

Pr. Abdelhay HAQIQ UML 19


Plan
❑ Historique de la modélisation

❑ Diagrammes UML

❑ Diagrammes UML par rapport aux 4+1 Vues

❑ Besoins des utilisateurs

❑ Aspects fonctionnels

❑ Architecture

Pr. Abdelhay HAQIQ UML 20


Les 4+1 Vues : Aspects fonctionnels
o Aspects fonctionnels : permet de définir qui utilisera le logiciel, pour quoi faire, et comment
les fonctionnalités vont se dérouler, etc.
– La vue logique a pour but d’identifier les éléments du domaine, les relations et interactions
entre ces éléments. Cette vue organise les éléments du domaine en « catégories ».

– La vue des processus démontre :

▪ la décomposition du système en processus et actions

▪ les interactions entre les processus

▪ la synchronisation et la communication des activités parallèles

Pr. Abdelhay HAQIQ UML 21


Vue Logique
o Deux diagrammes peuvent être utilisés pour la vue logique :
– Diagramme de classe
– Diagramme d’objets
o Diagramme de classes :
– Dans la phase d’analyse, ce diagramme représente les entités (des informations) manipulées
par les utilisateurs.
– Dans la phase de conception, il représente la structure objet d’un développement orienté
objet.
o Diagramme d’objets sert à illustrer les classes complexes en utilisant des exemples
d’instances.

Pr. Abdelhay HAQIQ UML 22


Vue Logique : Diag. de classe

Pr. Abdelhay HAQIQ UML 23


Vue Logique : Diag. d’objets
o Une instance est un exemple concret de contenu d’une classe. En illustrant une partie des
classes avec des exemples (grâce à un diagramme d’objets), on arrive à voir un peu plus
clairement les liens nécessaires

Pr. Abdelhay HAQIQ UML 24


Les 4+1 Vues
o La vue des processus démontre :
– la décomposition du système en processus et actions
– les interactions entre les processus
– la synchronisation et la communication des activités parallèles
o La vue des processus s’appuie sur plusieurs diagrammes :
▪ diagramme de séquence
▪ diagramme d’activité
▪ diagramme de communication (anciennement appelé collaboration)
▪ diagramme d’état-transition
▪ diagramme global d’interaction
▪ diagramme de temps

Pr. Abdelhay HAQIQ UML 25


Vue Processus : Diag. de séquence
o Diagramme de séquence permet de décrire les différents scénarios d’utilisation du système.

Pr. Abdelhay HAQIQ UML 26


Vue Processus : Diag. d’activité
o Diagramme d’activité représente le déroulement des actions, sans utiliser les objets. En
phase d’analyse, il est utilisé pour consolider les spécifications d’un cas d’utilisation.

Pr. Abdelhay HAQIQ UML 27


Vue Processus : Diag. de communication
o Diagramme de communication (appelé également diagramme de collaboration) permet de
mettre en évidence les échanges de messages entre objets. Cela nous aide à voir clair dans les
actions qui sont nécessaires pour produire ces échanges de messages. Et donc de compléter,
si besoin, les diagrammes de séquence et de classes.

Pr. Abdelhay HAQIQ UML 28


Vue Processus : Diag. d’état-transition
o Diagramme d’état-transition permet de décrire le cycle de vie des objets d’une classe.

Pr. Abdelhay HAQIQ UML 29


Vue Processus : Diag. global d’interaction
o Diagramme global d’interaction permet de donner une vue d’ensemble des interactions du
système. Il est réalisé avec le même graphisme que le diagramme d’activité. Chaque élément
du diagramme peut ensuite être détaillé à l’aide d’un diagramme de séquence ou d’un
diagramme d’activité

Pr. Abdelhay HAQIQ UML 30


Vue Processus : Diag. de temps
o Diagramme de temps est destiné à l’analyse et la conception des systèmes ayant des contraintes temps-réel.
Il s’agit là de décrire les interactions entre les objets avec des contraintes temporelles fortes

Un exemple de diagramme de temps avec un seul axe temporel

Un exemple de diagramme de temps avec un axe temporel par état

Pr. Abdelhay HAQIQ UML 31


Plan
❑ Historique de la modélisation

❑ Diagrammes UML

❑ Diagrammes UML par rapport aux 4+1 Vues

❑ Besoins des utilisateurs

❑ Aspects fonctionnels

❑ Architecture

Pr. Abdelhay HAQIQ UML 32


Les 4+1 Vues : Architecture
o Aspect lié à l’architecture du logiciel : permet de définir les composantes à utiliser (exécutables,
interfaces, base de données, librairies de fonctions, etc.) et les matériels sur lesquels les composants
seront déployés.
– La vue des composants (vue de réalisation) : met en évidence les différentes parties qui
composeront le futur système (fichiers sources, bibliothèques, bases de données, exécutables, etc.)

– La vue de déploiement : décrit les ressources matérielles et la répartition des parties du logiciel sur
ces éléments

Pr. Abdelhay HAQIQ UML 33


Vue des composants
o La vue des composants comprend deux diagrammes.
– Le diagramme de structure composite décrit un objet complexe lors de son exécution

– Le diagramme de composants décrit tous les composants utiles à l’exécution du système


(applications, librairies, instances de base de données, exécutables, etc.).

Pr. Abdelhay HAQIQ UML 34


Vue du déploiement
o La vue de déploiement décrit les ressources matérielles et la répartition des parties du
logiciel sur ces éléments. Il contient le diagramme de déploiement qui correspond à la
description de l’environnement d’exécution du système (matériel, réseau…) et de la façon
dont les composants y sont installés

Pr. Abdelhay HAQIQ UML 35

You might also like