Licence Professionnelle Logiciels et Développement Web

2021-2022

Modélisation Objet (UML)

(UML)

BAADOU Sanae
 Plan

01 Pourquoi modéliser ?

02 Qu’est ce qu’un modèle ?

03 Les méthodes d’analyse -

L’arrivée d’UML

04 Diagrammes UML
 Objectifs du module

•Comprendre les fondements de base

de UML
•Pouvoir utiliser et appliquer UML dans
des cas réels
• Apprendre l’Outil: StarUML
 Pourquoi modéliser ?

Importance de la modélisation

Pour construire une maison:

+ plans généraux,
plans d'exécution détaillés (pièces,
électricité, plomberie, chauffage) ;
Pour développer une application, 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
 Pourquoi modéliser ?
D’où l’intérêt d’une modélisation pour Mieux comprendre le système
Objectifs :
•Nous aider à le visualiser tel qu'il est ou tel qu'il devrait être
•Spécifier la structure et le comportement d'un système
•Valider le modèle vis à vis des clients
•Avoir un "patron" pour guider la construction du système
•documenter les décisions qui ont été prises
Nous construisons des modèles de systèmes complexes parce que nous sommes incapables
d'appréhender ces systèmes dans leur entièreté.
Un modèle est une simplification de la réalité
 L’approche par modélisation facilite:

La communication (et sa précision)

•Avec donneur d’ordre
•Entre différentes phases de développement et de maintenance

La capacité de vérification
•Cohérence
•Complétude
•La continuité entre les différentes phases du cycle de vie
 Qu’est ce qu’un modèle ?
Un modèle est une abstraction de la réalité
Il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une
entité, en vue d'une utilisation précise.
L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des
caractéristiques essentielles d'une entité, retenues par un observateur.
Un modèle est une vue subjective mais pertinente de la réalité
Un modèle définit une frontière entre la réalité et la perspective de l'observateur. Ce
n'est pas "la réalité", mais une vue très subjective de la réalité.
Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des aspects
importants de la réalité, il en donne donc une vue juste et pertinente
 Caractéristiques fondamentales d’un modèle
Le caractère abstrait d'un modèle doit notamment permettre de :
• Faciliter la compréhension du système étudié un modèle réduit la complexité du
système étudié.
• Simuler le système étudié
Un modèle représente le système étudié et reproduit ses comportements.
Un modèle réduit (décompose) la réalité, dans le but de disposer d'éléments de travail
exploitables par des moyens mathématiques ou informatiques.
Un modèle est une simplification de la réalité. Il permet de mieux comprendre le
système qu'on doit développer. Les meilleurs modèles sont proches de la réalité.
 Les méthodes d’analyse
Historique

Méthodes systémiques
(Merise)

1970 1980 1990 UML

1997

Méthodes Méthodes Orientées

cartésiennes Objets
 L’arrivée d’UML

UML devient une norme de l’OMG en 1997.

L’OMG (Object Management Group) est un organisme créé en 1989 afin de
promouvoir des standards (comme CORBA par exemple) qui garantissent
l’interopérabilité entre des applications orientées objet développées sur des
réseaux hétérogènes.
Cet organisme a été créé et est soutenu par des industriels comme HP, Sun,
Unisys, American Airlines, Philips …
 Au final, qu’est-ce qu’UML ?

UML : Unified Modeling Language

• Langage de Modélisation Unifié.
• Appliqué à l’analyse et à la conception des logiciels.
• Forte coloration orientée objet.
• Langage essentiellement graphique.
• Facile à lire et à comprendre.
 Au final, qu’est-ce qu’UML ?

En clair
• 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.
• Les modèles sont des diagrammes constitués d’éléments graphiques et de
texte.
• UML n’est pas une méthode, mais un langage
 Au final, qu’est-ce qu’UML ?

En clair
• 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.
• Les modèles sont des diagrammes constitués d’éléments graphiques et de
texte.
• UML n’est pas une méthode, mais un langage
 Les différentes vues
UML propose 5 vues qui se superposent en partie afin de
présenter les systèmes sous différents aspects.

vue de La vue des cas d'utilisation décrit le système tel que

déploiement le perçoivent les acteurs (leurs besoins).
Vue des cas
La vue logique décrit l’intérieur du système pour
d’utilisation
expliquer comment peuvent être satisfaits les
besoins.
vue des La vue d'implémentation définit les
vue d‘ dépendances entre les modules.
implémentation processus
La vue des processus est la vue temporelle et
technique, qui met en œuvre les notions de
tâches concurrentes, stimuli, contrôle,
synchronisation, etc.
vue logique
La vue de déploiement décrit la position
géographique et l'architecture physique de
chaque élément du système.
 Buts d’UML

 Modélisation du système complet (pas seulement le logiciel)

 Relier les objets conceptuels au système "exécutable"

 Contrôler la complexité (échelle)

 Lisible par des humains et des machines

 Langage ouvert (mécanisme d'extensibilité)

 Langage de spécification : signification claire et non ambiguë

 Comment modéliser avec UML ?
 UML est un langage qui permet de représenter des modèles, mais il ne
définit pas le processus d'élaboration des modèles !

 Cependant, dans le cadre de la modélisation d'une application informatique,

les auteurs d'UML préconisent d'utiliser une démarche :

 itérative et incrémentale,

 guidée par les besoins des utilisateurs du système,

 centrée sur l'architecture logicielle.

 D'après les auteurs d'UML, un processus de développement qui possède

ces qualités devrait favoriser la réussite d'un projet.
 Comment "rédiger" un modèle avec UML ?

 UML permet de définir et de visualiser un modèle, à l'aide de diagrammes.

 Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle ; c'est
une perspective du modèle, pas "le 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 véhicule une sémantique précise (un type de diagramme offre toujours la
même vue d'un système).

 Combinés, les différents types de diagrammes UML offrent une vue complète des aspects statiques et
dynamiques d'un système.

 Par extension et abus de langage, un diagramme UML est aussi un modèle (un diagramme modélise un
aspect du modèle global).
 Les différents diagrammes

 Vues statiques du système :

 diagrammes de cas d'utilisation
 diagrammes d'objets
 diagrammes de classes
 diagrammes de composants
 diagrammes de déploiement
 Vues dynamiques du système :
 diagrammes de collaboration
 diagrammes de séquence
 diagrammes d'états-transitions
 diagrammes d'activités
 Logiciels de modélisation UML

Il existe de nombreux outils logiciels de modélisation UML.

Logiciels open-source: ArgoUML, Papyrus UML, StarUML, BOUML…
Logiciels payants: Rational Rose ,EDGE Diagrammer, Visual Paradigm …
 Les éléments de la modélisation UML

Les paquetages
Un paquetage est un regroupement logique de
différents éléments de la modélisation, il peut
contenir d’autres sous paquetages
Chaque paquetage doit avoir un nom
 Les éléments de la modélisation UML

Les notes
Commentaire attaché à un ou plusieurs éléments de
modélisation
 Les éléments de la modélisation UML

Les stéréotypes
Les stéréotypes permettent d’étendre la sémantique des
éléments de modélisation UML
Représentation: <<NomStéréotype>>
UML propose de nombreux stéréotypes standards:
<<includ>> <<extend>> <<utility>>…
LES CAS D'UTILISATION
 Cas d'utilisation (use cases)

 Il s'agit de la solution UML pour représenter le modèle conceptuel.

 Les use cases permettent de structurer les besoins des utilisateurs et

les objectifs correspondants d'un système.

 Ils centrent l'expression des exigences du système sur ses

utilisateurs : ils partent du principe que les objectifs du système sont
tous motivés.
 Cas d'utilisation (use cases)

 Ils se limitent aux préoccupations "réelles" des utilisateurs ; ils ne

présentent pas de solutions d'implémentation et ne forment pas
un inventaire fonctionnel du système.
 Ils identifient les utilisateurs du système (acteurs) et leur
interaction avec le système.
 Ils permettent de classer les acteurs et structurer les objectifs du
système.
 Ils servent de base à la traçabilité des exigences d'un système
dans un processus de développement intégrant UML.
 Intérêt des cas d'utilisation

 Un cas d'utilisation "use-case" est une manière particulière d'utiliser le système.

 Les cas d'utilisation permettent d'exprimer rapidement et simplement les besoins

fondamentaux d'un point de vue complètement externe au système.

 On définit une relation entre l’acteur et chacun de ses use-cases.

 L’acteur communique avec le use-case, il participe au cas d’utilisation.

 Un use-case peut être relié à plusieurs acteurs.

28
 Éléments de base des cas d'utilisation

 Acteur : entité externe qui agit sur le système (opérateur, autre

système...).
 L'acteur peut consulter ou modifier l'état du système.
 En réponse à l'action d'un acteur, le système fournit un service qui correspond
à son besoin.
 Les acteurs peuvent être classés (hiérarchisés).
 Use case : ensemble d'actions réalisées par le système, en réponse à une
action d'un acteur.
 Les use cases peuvent être structurés.
 Les use cases peuvent être organisés en paquetages (packages).
 L'ensemble des use cases décrit les objectifs (le but) du système.
 Éléments de base des cas d'utilisation

La relation entre cas d’utilisation

Il existe 3 types de relations entre cas d’utilisation :

• La relation de généralisation
• La relation d’extension
• La relation d’inclusion
 Éléments de base des cas d'utilisation

La relation de généralisation:
Le cas d’utilisation source hérite le comportement du cas d’utilisation
destination
 Éléments de base des cas d'utilisation
La relation d’ extension :
Le cas d’utilisation source étend cad ajoute son comportement (optionnellement) au
comportement du cas d’utilisation destination
 Éléments de base des cas d'utilisation

La relation d’ extension :

Le point où se passe l’extension peut être précisé L’extension

peut être soumise à une condition
 Éléments de base des cas d'utilisation
La relation d’inclusion :
Le cas d’utilisation source inclue cad contient obligatoirement le
comportement du cas d’utilisation destination
 Éléments de base des cas d'utilisation

La relation entre acteur et use case

La relation entre acteurs

La seule relation possible entre deux acteurs est

la généralisation
 Les diagrammes de cas d’utilisation

Démarche

•Identifier et décrire les acteurs.

• Identifier et décrire les cas d’utilisation.

• Structurer les cas d’utilisation en package

 Recettes pour établir les cas d’utilisation

 Étape 1: Identifier les "rôles" du système:

Ce sont les acteurs avec le stéréotype "acteur". Lorsqu’un système est
subdivisé en sous-systèmes plus élémentaires, un sous-système peut devenir
un acteur pour un autre sous système. Si l'acteur n'est pas humain, utiliser
une forme rectangulaire.

 Étape 2: Différencier les acteurs si possible si la nature du problème l’exige.

Chercher les propriétés communes de ces acteurs. Factorisez éventuellement
un rôle commun et dériver (si possible) les autres acteurs à partir de cet
acteur commun (usage de l'héritage)
 Recettes pour établir les cas d’utilisation

 Étape 3: Pour chaque acteur, chercher ce que cet acteur peut faire avec
le système et identifier les use cases de base.

 Étapes 4: Étudier chaque use case de base. S'il a l'air complexe et ne

permet pas d'estimer l'ampleur du projet, décomposer le et identifier les
use cases sous-jacents.

 Étape 5: Décrire en détail chaque use case, aussi bien des use case de
base que les use cases sous-jacents. C'est une étape importante car elle
permet de clarifier ce qu'on veut confier comme tâches à un système.
 Recettes pour établir les cas d’utilisation

 Étape 6 : Supprimer les uses cases qui n'ont pas leur raison d'être. Généralement,
un use case est "réalisé" possiblement avec un mini diagramme de séquence ou de
collaboration, aussi petit soit-il, si l'on poursuivait l'étude. Si ce n'est pas le cas,
peut être le use case n'a pas sa raison d'être.

 Étape 7: Trouver les traitements communs dans les descriptions et cherchez les
possibilités de factorisation. Dégagez si possible les use cases « factorisés »

 Étape 8: Établir les liens stéréotypés pour préciser la sémantique du système. Ce

sera la partie la plus technique de la spécification.
 Recettes pour établir les cas d’utilisation

 Étape 9: Recommencer les étapes 4 à 8 pour tous les use cases de base.

 Étape 10: Identifier les acteurs secondaires (par exemple, les acteurs de
maintenance et recommencez les étapes de 2 à 9 pour les acteurs
secondaires)
Exemple: diagramme de cas d’utilisation
Exercice
 Modélisation d’un GAB (Guichet Automatique de Banque). Les principales
fonctions sont les suivantes :
 distribution d’argent à tout porteur d’une carte de la banque (autorisation d’un certain
montant par le Système d’Information de la banque) ou d’une carte VISA (autorisation à
distance par le Système d’Autorisation VISA),

 consultation du solde, dépôt en numéraire et de chèques pour les possesseurs d’une carte
de la banque.

 Toutes les transactions sont sécurisées (code personnel vérifié avec le code enregistré sur
la puce de la carte ; la carte est avalée après trois échecs).Il faut parfois recharger le GAB
et retirer des choses ...

 Identifier les acteurs et les cas. Structurer les cas.

Correction
LES DIAGRAMMES DE SÉQUENCES
 Les diagrammes de séquences

Les diagrammes de séquences permettent de représenter des interactions entre objets (=

décrire COMMENT les éléments du système interagissent entre eux).

Les diagrammes de séquences sont utilisés pour :

•Illustrer les use cases dans le modèle dynamique.
 Les éléments de bases des diagrammes de séquences

Les participants :
Les objets : les acteurs + le système ( instances de classes)
La ligne de vie

La zone d’activation = période d’activation

 Les diagrammes de séquence

: :
 La période d'activation

•La réception des messages provoque une période d'activation ( rectangle vertical sur la
ligne de vie) marquant le traitement du message

•Période durant laquelle un objet effectue une action -> état actif

•Un objet peut être actif plusieurs fois

Exemple de diagramme de séquence
 Les types de messages

1. Message synchrone

synchrone: l’émetteur reste bloqué le temps que le récepteur traite le message envoyé ;

Il se représente par une flèche en traits pleins et à l’extrémité pleine

 Les types de messages

2- message asynchrone:

Dans un message asynchrone : l’émetteur n’est pas bloqué lorsque le récepteur traite le
message envoyé.
Un message asynchrone se représente par une flèche en traits pleins et à l’extrémité
ouverte
 Les types de messages

3. Message récursif

Un message récursif est un message qu’un objet s’envoie à lui-même.

Message création/destruction d’un objet
Bref
 Structures de contrôle

Le diagramme de séquences peut inclure un certain nombre de

structures

• Les tests

• Répétitions (itérations, boucles)

Références (réf): faire référence à un autre diagramme de séquence.

 Fragment optionnel

Opt: fragment parcouru si une condition est vérifié

 Fragment Alt

Alt: équivalant à la structure de contrôle « si …… alors sinon …… »

 Fragment Loop

Loop : répétition du fragment tant que la condition est vérifiée

Exercice
Etude d'une caisse de supermarché
le déroulement normal d’utilisation d’une caisse de supermarché est le suivant :
• un client arrive à la caisse avec ses articles à payer
• le caissier enregistre le numéro d’identification de chaque article
• la caisse affiche le prix de chaque article et son libellé
le caissier enregistre la quantité
• lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente
• la caisse affiche le total des achats
• le caissier annonce au client le montant total à payer
• le client choisit son mode de paiement: on suppose que le client va payer en espèce
o liquide : le caissier encaisse l’argent

1- développez le diagramme de séquence correspondant?