Université Abdelmalek Essaadi

Ecole Nationale des Sciences Appliquées

d'Al-Hoceima

UML
Introduction
Pourquoi modéliser ?
 Modéliser, c’est décrire de manière visuelle et graphique les besoins et, les
solutions fonctionnelles et techniques du projet logiciel. Mais modéliser
pour quoi faire ?
 Avez-vous déjà eu à constituer un meuble en kit ? Cette tâche sera très
difficile constituons page de texte.
Pourquoi modéliser ?
 Toutefois, vous serez d’accord que c’est plus facile à partir de schéma
plutôt qu’une page de texte.

 Cet exemple nous démontre que l’utilisation de schémas et d’illustrations

rend quelque chose de complexe plus compréhensible.
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 devrait être ;
 De valider le modèle vis à vis des clients ;
 De spécifier les structures de données et le comportement du système ;
 De fournir un guide pour la construction du système ;
 De documenter le système et les décisions prises.
Pourquoi modéliser ?

 Un logiciel qui a été réalisé sans analyse et sans conception risque de ne

pas répondre aux besoins, de comporter des anomalies et d’être très
difficile à maintenir.
 Tout comme la construction d’une maison nécessite des plans à différents
niveaux (vision extérieure, plan des différents étages, plans techniques…),
la réalisation d’un logiciel ou d’un ensemble de logiciels a besoin d’un
certain nombre de diagrammes.
Méthodes de conception
On parle principalement de trois types de méthodes de conception :
Méthodes fonctionnelles
(années 70)

 Les méthodes fonctionnelles (également qualifiées de méthodes structurées)

trouvent leur origine dans les langages procéduraux.
 Elles mettent en évidence les fonctions à assurer et proposent une approche
hiérarchique descendante et modulaire.
 Les méthodes fonctionnelles consistent à décomposer hiérarchiquement une
application en un ensemble de sous applications.
 Les fonctions de chacune de ces dernières sont affinées successivement en
sous fonctions simples à coder dans un langage de programmation donné.
Méthodes fonctionnelles
(années 70)

Représentation graphique d'une approche fonctionnelle

Méthodes fonctionnelles
(années 70)

Les points forts des méthodes fonctionnelles sont les suivants :

 Simplicité du processus de conception préconisé,
 Capacité à répondre rapidement aux besoins ponctuels de leurs
utilisateurs.
Les points faibles des méthodes fonctionnelles sont les suivants :
 Le code devient très rapidement volumineux et perd en clarté.
 Optimisations et extensions plus difficiles
Méthodes systémiques
(années 80)

 Les méthodes systémiques proposent une double démarche de modélisation :

la modélisation des données et celle des traitements. Elle est influencée par
les systèmes de gestion de bases de données.
 MERISE est un exemple d’une méthode systémique. Elle permet de faire
l'analyse et la conception des systèmes d'information basée sur le principe de
la séparation des données et des traitements.
 Elle possède plusieurs modèles qui sont répartis sur 3 niveaux : Le niveau
conceptuel, le niveau logique ou organisationnel, le niveau physique.
Méthodes systémiques
(années 80)

 Les points forts des méthodes systémiques sont les suivants :

- Approche globale qui prend en compte la modélisation des données et des
traitements.
- Introduction des niveaux d'abstraction dans le processus de conception
(niveau conceptuel, niveau logique et niveau physique),
 Les points faibles des méthodes systémiques sont les suivants :
- Double démarche de conception : les données et les traitements.
- Pas de fusion possible des deux aspects (données et traitements).
Méthodes orientées objets
 La fonctionnalité du logiciel émerge alors de l’identification et l'interaction
entre les différents objets qui le constituent
 L'objet est le coeur de cette approche. Tout objet donné possède deux
caractéristiques :
 Son état courant (attributs)

 Son comportement (méthodes)

 L'une des particularités de cette approche est qu'elle rapproche les données
et leurs traitements associés au sein d'un unique objet.
Méthodes orientées objets
En quoi les méthodes OO sont difficile ?

 La difficulté de cette modélisation consiste à créer une représentation

abstraite, sous forme d'objets, d'entités ayant une existence matérielle ou
virtuelle (chien, voiture, ampoule, personne…)
 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 la
fonction qu'il est censé réaliser.

En résumé, l'architecture du système est dictée par la structure du problème.

Méthodes orientées objets
Méthodes orientées objets
Méthodes orientées objets

 L'approche orientée objet est potentiellement de type ascendant : un effort

de regroupement basé sur l'abstraction des données est entretenu tout au
long du processus de conception.
 En effet, on commence par l'identification des objets. Ces objets sont
regroupés dans des classes selon leurs propriétés. Ensuite ces classes sont à
nouveau regroupées en classes plus abstraites appelées modules ou sous-
systèmes jusqu'à la modélisation du problème posé.
Méthodes orientées objets
Les concepts de base

 Objets : unités de base organisées en classes et partageant des traits communs

(attributs ou procédures). Peuvent être des entités du monde réel, des concepts de
l’application ou du domaine traité.
 Encapsulation :
- Les structures de données et les détails de l’implémentation sont cachés aux autres
objets du système.
- La seule façon d’accéder à l’état d’un objet est de lui envoyer un message qui
déclenche l’exécution de l’une de ses méthodes.
- Les types d’objets peuvent être assimilés aux types de données abstraites en
programmation.
Méthodes orientées objets
Les concepts de base

 Héritage : chaque instance d’une classe d’objet hérite des caractéristiques (attributs et
méthodes) de sa classe mais aussi d’une éventuelle super-classe. L’héritage est un des
moyens d’organiser le monde c.-à-d. de décrire les liens qui unissent les différents
objets
 Polymorphisme : possibilité de recourir à la même expression pour dénoter différentes
opérations. L’héritage est une forme particulière du polymorphisme caractéristique
des systèmes orientés objet
Méthodes orientées objets
Les points forts des méthodes orientées objets sont les suivants :
 Intégrer dans l'objet des données et des traitements
 Permet de de mieux organiser son code & facilite le travail coopératif et la
maintenance à long terme.
 Favoriser la conception et la réutilisation des composants : concevoir dans un
but de réutilisation et non pas pour répondre à un besoin ponctuel.
 Améliorer la productivité et la rentabilité en utilisant des bibliothèques de
composants réutilisables
 Simplifier le passage conceptuel/physique.
Projet informatique
Un projet informatique nécessite une phase d’analyse, suivi d’une étape de
conception
La phase d’analyse
 Dans cette phase, on cherche d’abord à bien comprendre et à décrire de façon
précise les besoins des utilisateurs ou des clients.
- Que souhaitent-ils faire avec le logiciel ?
- Quelles fonctionnalités veulent-ils ?
- Pour quel usage ?
- Comment l’action devrait-elle fonctionner ?
 C’est ce qu’on appelle « l’analyse des besoins ». Après validation de notre
compréhension du besoin, nous imaginons la solution. C’est la partie analyse
de la solution
La phase de conception
 Dans cette phase, on apporte plus de détails à la solution et on cherche à
clarifier des aspects techniques, tels que l’installation des différentes parties
logicielles à installer sur du matériel.
 Pour réaliser ces deux phases dans un projet informatique, nous utilisons des
méthodes, des conventions et des notations. UML fait partie des notations les
plus utilisées aujourd’hui.
Langage UML

UML permet de modéliser toutes les

étapes du développement d’une
application de l’analyse au
déploiement (en utilisant plusieurs
diagrammes).
L'émergence des méthodes objet
(années 1990-1995)

 Méthodes fonctionnelles (années 70)

 Méthodes systémiques (années 80)
 Prise de conscience de l'importance d'une méthode spécifiquement objet :
- comment structurer un système sans centrer l'analyse uniquement sur
les données ou uniquement sur les traitements (mais sur les deux) ?
- Plus de 50 méthodes objet sont apparues durant cette période (Booch,
Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !
- Aucun méthode ne s'est réellement imposée.
Les premiers consensus (1995)
OMT (James Rumbaugh)

 Offre des vues statiques, dynamiques et fonctionnelles d'un système :

- Issue du centre de R&D de General Electric.
- Notation graphique riche et lisible..

OOD (Grady Booch)

 Offre des vues logiques et physiques du système
 Ne couvre pas la phase d’analyse dans ses 1ères versions
Les premiers consensus (1995)

- Introduit le concept de package (élément d'organisation des modèles).

- ..

OOSE (Ivar Jacobson)

 Couvre tout le cycle de développement :

- Issue d'un centre de développement d'Ericsson, en Suède.
- La méthodologie repose sur l'analyse des besoins des utilisateurs.
L'unification et la normalisation des
méthodes (1995-1997)

 En octobre 1994, G. Booch (père fondateur de la méthode Booch) et J.

Rumbaugh (principal auteur de la méthode OMT) ont décidé de travailler
ensemble pour unifier leurs méthodes au sein de la société Rational
Software.
 Un an après, I . Jacobson (auteur de la méthode OOSE et des cas
d’utilisation) a rejoint Rational Software pour travailler sur l’unification.
Unified Modified Language (UML) est né.
 UML 2

Langage UML Soumission OMG UML 1.3 juin 1999

UML 1.2 juin 1998

Standardisation OMG Novembre 1997

Soumission OMG UML 1.1
Septembre 1997

Soumission OMG UML 1.0 Janvier 1997

OOPSLA ‘ 96 UML 0.9

Juin 1996

OOPSLA ‘ 95 Méthode Unifiée 0.8 Octobre 1995

Booch ’93 OMT-2

Autres méthodes Booch ’91 OMT-1 OOSE Partenaires : IBM, HP, Microsoft, Oracle
Langage UML
UML : Unified Modeling Language

 Un langage de modélisation unifié

 Ce n’est pas un langage de programmation
 Indépendant de tout langage de programmation (objet ou autre)
 Un langage basé sur des notations graphiques
 Constitués de plusieurs graphes (diagrammes) permettant de visualiser la
future application de plusieurs angles différents
 Une norme maintenue par l’OMG (Object Management Group :
organisation mondiale créée en 1989 pour standardiser le modèle objet)
Résumé sur l’hitorique d’UML
 UML, c’est l’acronyme anglais pour « Unified Modeling Language ». On le
traduit par « Langage de modélisation unifié ».
 UML est né de la fusion des trois méthodes qui ont influencé la modélisation
objet au milieu des années 90 : OMT, Booch et OOSE.
 Il est proposé par : Grady Booch, James Rumbaugh et Ivar Jacobson.
Langage UML

 UML est surtout utilisé lorsqu’on prévoit de développer des applications avec
une démarche objet (développement en Java, en C++, etc.).
 La notation UML est un langage visuel constitué d’un ensemble de schémas,
appelés des diagrammes, qui donnent chacun une vision différente du projet à
traiter.
 UML nous fournit donc des diagrammes pour représenter le logiciel à
développer : son fonctionnement, sa mise en route, les actions susceptibles
d’être effectuées par le logiciel, etc..
Langage UML

 Réaliser ces diagrammes revient donc à modéliser les besoins du logiciel à

développer.
 Le langage UML ne demande aucune démarche, ce n’est donc pas une
méthode.
 Chacun est libre d’utiliser les types de diagramme qu’il souhaite, dans l’ordre
qu’il veut.
 Il suffit que les diagrammes réalisés soient cohérents entre eux, avant de
passer à la réalisation du logiciel.
UML
Et un graphe ?

En mathématiques, c’est un outil composé de :

 un ensemble de sommets,

 Et un ensemble d’arêtes (arcs) reliant les sommets

Exemple de graphe :
x6 x5 Sommets
Arêtes

x1 x2 x3 x4
UML
Remarques :

 14 diagrammes depuis UML 2.3 classés en deux catégories

 7 diagrammes de structure (statiques) : permettent de d'écrire la structure
d’un système selon plusieurs points de vue différents (classes, composants,
nœuds, objets, packages...)
 7 diagrammes de comportement (dynamiques) : permettent de d'écrire le
comportement d’un système de plusieurs points de vue différents
(temporel, changement d’état...)
UML
Diagrammes de comportement (dynamiques)
UML
UML
Notations communes :
 Classeur : a une forme rectangulaire et permet de représenter les classes dans un diagramme
UML
 Package (paquetage) : est un regroupement de éléments de système ou de diagrammes
 Stéréotype : annotation entourée par <<nomAnnotation>> permettant d’ajouter une précision
sur l’ élément annote

Classeur Package Stéréotype

UML
Les flèches en UML

Association bidirectionnelle
Association unidirectionnelle
Dépendance
Héritage
Implémentation
Agrégation
Composition
UML
Quelques logiciels pour faire la modélisation UML :

 Power Designer (payant - version d’essai 30 jours)

 StarUML
 BoUML
 Visual Paradigm (payant - version d’essai 30 jours)
 Astah (payant - version d’essai 30 jours)
 ArgoUML (Open source)
 PlantUML