Introduction à la

modélisation objet avec UML

Mme CHALOUAH Anissa
I.S.E.T Bizerte
Département Technologies de l’informatique

13/02/2015 Mme CHALOUAH Anissa 1

Chapitre 1 :
Introduction à la modélisation objet avec UML

BESOIN DE MODÉLISATION

13/02/2015 Mme CHALOUAH Anissa 2

Construction d’applications
 En simplifiant à l’extrême, nous pourrions dire que la
construction d’une application informatique se résume à
réaliser du code pour répondre au besoin d’un utilisateur.

Besoins
Analogie :
Construction d’application vs Construction Bâtiment
Se faire construire une Informatiser son système
maison d’information

Client Chef d’entreprise

Client Maçon

Résultat
Attente du
client
S’adresser directement au maçon n’est pas une très bonne idée
Analogie :
Développement Logiciel vs Construction Bâtiment
Chef d’entreprise Développeur Code

Logiciel non conforme

La réalisation d’une application ne se résume sûrement pas à l’écriture de milliers
de lignes codes
 Plans

Client
Architecte

Résultat ==Attente du client Maçon

Pourquoi modéliser

« Un dessin vaut mieux qu'un beau discours »

Qu’est ce qu’un modèle
 Un modèle est avant tout une représentation abstraite
du monde réel.
 Un modèle offre donc une vision schématique d'un
certain nombre d'éléments que l'on veut décrire ;
un dessin quoi !
 Réaliser un modèle, c'est avant tout dessiner ce que l'on
a compris d'un problème dans une syntaxe précise.
 L’intérêt du modèle en programmation, c’est de permettre
de réaliser une maquette simplifiée du programme à
réaliser.
Qu'est-ce qu'un modèle ?
 un modèle est prévu pour arriver à anticiper les
résultats du codage.
 Un modèle est une abstraction, une simplification de
la réalité.

13/02/2015 Mme CHALOUAH Anissa 11

Modèle & équipe
 Un modèle représente un outil majeur de
communication entre les différents intervenants au
sein d’un projet.
 Chaque membre de l’équipe, depuis l’utilisateur
jusqu’au développeur, utilise et enrichit le modèle
différemment.
 En outre, les systèmes devenant de plus en plus
complexes, leur compréhension et leur maîtrise
globale dépassent les capacités d’un seul individu.
13/02/2015 Mme CHALOUAH Anissa 12
Modèle & équipe
 Un modèle va donc nous servir à
communiquer et échanger des points de vue afin
d'avoir une compréhension commune et précise
d'un même problème.
Modèle & traçabilité
 Le modèle présente notamment l’atout de faciliter la
traçabilité du système, à savoir la possibilité de partir
d’un de ses éléments et de suivre ses interactions et
liens avec d’autres parties du modèle.

13/02/2015 Mme CHALOUAH Anissa 14

Qualité d’un bon modèle
 Un bon modèle doit :
◦ faciliter la compréhension du programme étudié, en
réduisant la complexité.
◦ permettre de simuler le comportement du programme
 Un bon modèle doit donc être construit:
◦ au bon niveau de détail,
◦ selon le bon point de vue.

13/02/2015 Mme CHALOUAH Anissa 15

Rôles du modèle
 Il permet de :
oVisualiser le système comme il est ou comme il devrait être.
oValider le modèle vis-à-vis des clients.
oSpécifier les structures de données et le comportement du
système.
oFournir un guide pour la construction du système.
oDocumenter le système et les décisions prises.

13/02/2015 Mme CHALOUAH Anissa 16

Chapitre 1 :
Introduction à la modélisation objet avec UML

LE PARADIGME ORIENTÉE OBJET

13/02/2015 Mme CHALOUAH Anissa 17

Paradigme objet
Programmation Objet :
◦ Un programme = une société d'entités
◦ Son exécution : les entités collaborent pour résoudre le problème final
en s'envoyant des messages.
◦ une entité = un objet qui prend en compte sa propre gestion (objet
responsable)
◦ Liaison inévitable entre données et procédures opérant sur ces
données.
Avantages
 Faciliter le développement en mode «boite noire»
 Maximiser la localité des changements
 Permettre la réutilisation de code

13/02/2015 Mme CHALOUAH Anissa 18

Concepts Objet
 Les concepts objets se traduisent par les notions
suivantes :
◦ Objet
◦ Classe
◦ Encapsulation
◦ Abstraction
◦ Héritage
◦ Polymorphisme

13/02/2015 Mme CHALOUAH Anissa 19

L’objet
 Toute entité identifiable, concrète ou abstraite, peut
être considérée comme un objet.

 Un objet réagit à certains messages qu’on lui envoie de

l’extérieur ; la façon dont il réagit détermine le
comportement de l’objet.

 Il ne réagit pas toujours de la même façon à un même

message ; sa réaction dépend de l’état dans lequel il
est.
13/02/2015 Mme CHALOUAH Anissa 20
L’objet
Caractérisé par :
 son comportement : que peut-on faire avec cet objet?
Méthodes
 Son état : comment réagit l’objet quand on applique ces
méthodes?
 Attributs (Champs)
 son identité : comment distinguer les objets qui ont le même
état et le même comportement?  Identifiant
 A les mêmes réactions et la même modularité que le monde réel.
 L’objet informatique est une projection de l’objet du monde réel.

13/02/2015 Mme CHALOUAH Anissa 21

La classe
 Une classe est la description des caractéristiques
communes à tous les objets.
 Une classe est un modèle de définition pour des
objets
◦ ayant même structure (même ensemble d'attributs),
◦ ayant même comportement (mêmes opérations, méthodes),
◦ ayant une sémantique commune.
 Classe = schéma/moule/modèle d’objets, elle décrit :
◦ partie privée
 structure de données interne (attributs)
 corps des méthodes (algorithmes)
◦ partie publique (interface)
 noms et paramètres des méthodes
13/02/2015 Mme CHALOUAH Anissa 22
La classe
 Les objets (instances) sont créés (instanciés) à partir de
"moules" : les classes.
 Classe = générateur d’objets par instanciation, on peut
fabriquer des objets obéissant à ce schéma/moule/modèle.

13/02/2015 Mme CHALOUAH Anissa 23

Exemple : classe et objet

13/02/2015 Mme CHALOUAH Anissa 24

Abstraction
 Une abstraction est un résumé, un condensé
 Mise en avant des caractéristiques essentielles
 Dissimulation des détails
 Une abstraction se définit par rapport à un point de
vue
 Exemple d’abstraction : carte routière

13/02/2015 Mme CHALOUAH Anissa 25

Encapsulation
 Mécanisme consistant à rassembler, au sein d’une même
structure, les données et les traitements
◦ Définition des attributs et méthodes au niveau de la classe
 L’implémentation de la classe est cachée pour l’utilisateur
◦ Définition d’une interface : vue externe de l’objet
 Possibilité de modifier l’implémentation sans modifier
l’interface
◦ Facilité de l’évolution de l’objet
 Préservation de l’intégrité des données
◦ L’accès direct aux attributs est interdit
◦ L’interaction entre les objets se fait uniquement grâce aux
méthodes.
13/02/2015 Mme CHALOUAH Anissa 26
Héritage
 Un objet spécialisé bénéficie ou hérite des caractéristiques de
l’objet le plus général, auquel il rajoute ses éléments propres
◦ Création de nouvelles classes basées sur des classes existantes.
◦ Transmission des propriétés (attributs et méthodes) de la classe mère
vers la classe fille.
 Traduit la relation « est un … »
 Deux orientations possibles
◦ Spécialisation : Ajout / adaptation des caractéristiques
◦ Généralisation : Regroupement des caractéristiques communes
 Avantages
◦ Éviter la duplication du code
◦ Encourager la réutilisation du code

13/02/2015 Mme CHALOUAH Anissa 27

Héritage : Exemple

13/02/2015 Mme CHALOUAH Anissa 28

Polymorphisme
 Définition :
◦ Poly : plusieurs
◦ Morphisme : Forme
 Faculté d’une méthode à pouvoir s’appliquer à des objets
de classes différentes.
 Capacité d’une classe à redéfinir une méthode héritée à
partir d’une classe mère
◦ Surcharge
 Avantages
◦ Lisibilité du code
◦ Généricité du code

13/02/2015 Mme CHALOUAH Anissa 29

Polymorphisme : exemple

float surface(float longueur, float largeur) float surface(float rayon) {

{ return (3,14*rayon*rayon);
return (longueu*largeur); }
}

13/02/2015 Mme CHALOUAH Anissa 30

Chapitre 1 :
Introduction à la modélisation objet avec UML

UML :
UNIFIED MODELING
LANGUAGE

13/02/2015 Mme CHALOUAH Anissa 31

Historique
 Années 80
◦ Méthodes pour organiser la programmation fonctionnelle (Merise)
◦ Séparation des données et des traitements
 Début des années 90
◦ Apparition de la programmation objet: nécessite d’une méthodologie
adaptée
◦ Apparition de plus de 50 méthodes entre 1990 et 1995 1994
 Consensus sur 3 méthodes
◦ OMT de James Rumbaugh : représentation graphique des aspects statiques,
dynamiques et fonctionnels d’un système
◦ OOD de Grady Booch: concept de package
◦ OOSE de Ivar Jacobson : description des besoins de l’utilisateur.

13/02/2015 Mme CHALOUAH Anissa 32

Genèse de UML
(Unified Modeling Langage)

13/02/2015 Mme CHALOUAH Anissa 33

UML
(Unified Modeling Langage)
 UML est un langage universel de modélisation
orientée objet.
 UML est une notation, un outil de communication
visuelle (diagrammes)
 UML est une norme maintenue par l’OMG (Object
Management Group)
 UML est dans le domaine public, c’est un standard.

13/02/2015 Mme CHALOUAH Anissa 34

UML
 UML est un langage pour :
◦ Visualiser
 Chaque symbole graphique possède une sémantique.
◦ Spécifier
 De manière précise et complète, sans ambiguïté.
◦ Construire
 Une partie du code des classes peut être généré automatiquement.
◦ Documenter
 Les différents diagrammes, notes, contraintes, exigences sont
conservés dans un document.

13/02/2015 Mme CHALOUAH Anissa 35

UML
(Unified Modeling Langage)

 UML n’est pas une méthode.

 UML n’est pas un processus de développement.

 UML n’est pas un langage de programmation.

13/02/2015 Mme CHALOUAH Anissa 36

Objectifs d’UML

 Fournir un langage visuel et expressif.

 Fournir des mécanismes d’extension.
 Etre indépendant des technologies et langages
d’implémentation
 Fournir une base formelle pour la modélisation.

13/02/2015 Mme CHALOUAH Anissa 37

Les diagrammes UML

13/02/2015 Mme CHALOUAH Anissa 38

Les diagrammes UML
 Diagrammes de cas d’utilisation : décrivent les
services rendus par le système du point de vue de
l’utilisateur.
 Diagrammes de classes : décrivent les classes d’une
application et leurs relations statiques.
 Diagrammes d’objets : montrent l’état d’une
application à un instant donné. (Instances des classes)

13/02/2015 Mme CHALOUAH Anissa 39

Les diagrammes UML
 Diagrammes de séquence : Scénario d’un cas
d’utilisation : chronologie des opérations.
 Diagrammes de collaboration : sont une
représentation spatiale des interactions entre objets.
 Diagrammes d’´etats-transitions : représentent le
comportement d’un objet sous la forme d’un automate
à états

13/02/2015 Mme CHALOUAH Anissa 40

Les diagrammes UML
 Diagrammes de composants : Représentation des
composants logiciels d’un système.
 Diagrammes de déploiement : Description de
l’architecture technique du système .
 Diagrammes d’activités : Vue des enchaînements des
activités d’un cas d’utilisation ou d’une opération

13/02/2015 Mme CHALOUAH Anissa 41

Les 3 axes de modélisation d’un système
Axe fonctionnel
(ce que le système FAIT)

Diagramme de cas d’utilisations

Diagramme de classes
Diagramme d’états-transitions
Diagramme d’objets
Diagramme de séquence
Diagramme de composants
Diagramme d’activité

Axe dynamique
Axe statique (comment le système
(ce que le système EST) évolue)
13/02/2015 Mme CHALOUAH Anissa 42
Les Vues en UML
 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.
 Ce sont des formulations du problème selon un
certain point de vue.
 Elles peuvent se chevaucher pour compléter une
description.
 Leur somme représente le modèle en entier : 4 vues
plus 1.
13/02/2015 Mme CHALOUAH Anissa 43
Les Vues en UML

Le modèle « 4+1 » vues de Kruchten

13/02/2015 Mme CHALOUAH Anissa 44

Les Vues en UML
 Vue des cas d’utilisation :
◦ c'est la description du modèle vu par les acteurs du système.
◦ Elle correspond aux besoins attendus par chaque acteur
◦ (c'est le QUOI et le QUI).
 Vue logique :
◦ c'est la définition du système vu de l'intérieur.
◦ Elle explique comment peuvent être satisfaits les besoins des acteurs
◦ (c'est le COMMENT).
 Vue d'implémentation :
◦ cette vue définit les dépendances entre les modules.

13/02/2015 Mme CHALOUAH Anissa 45

Les Vues en UML
 Vue des processus :
◦ c'est la vue temporelle et technique
◦ Elle met en œuvre les notions de tâches concurrentes, contrôle,
synchronisation…

 Vue de déploiement :
◦ cette vue décrit la position géographique et l'architecture physique de
chaque élément du système (c'est le OÙ).

13/02/2015 Mme CHALOUAH Anissa 46