Modélisation objet et UML
Introduction
Mathilde Vernet
[Link]@[Link]
Licence Informatique
CERI, Avignon Université
Automne 2025
Plan
1 Informations pratiques
2 Introduction
Génie logiciel
Approche orientée objet
Modélisation
Informations pratiques
UE Concevoir et développer une application informatique
Modélisation objet et UML (3 ECTS)
Architectures web (2 ECTS)
AMS : Concevoir et développer une application web (3 ECTS)
Modélisation Objet et UML
Partie d’une unité d’enseignement
Une activité de mise en situation commune ponctue l’UE
Informations pratiques
Organisation
4 séances de cours d’1h30
8 séances de TD d’1h30
4 séances de TP de 3h
Objectif du cours
Comprendre l’approche orientée objet
Comprendre la démarche de modélisation
Connaître et savoir utiliser les différents types de modèles
Être capable de les mettre en œuvre pour modéliser un cas
Être capable de les interpréter et les exploiter pour compléter d’autres
modèles et produire une implémentation
Évaluation des connaissances
Examen écrit d’1h30 sur la modélisation (50%)
Examen écrit d’1h30 sur l’exploitation de modèles (50%)
Introduction Génie logiciel
Objectif principal du génie logiciel
Construire un logiciel de qualité
I Fiable : doit faire ce que l’utilisateur attend
I Efficace : sans gaspiller les ressources, dans la mesure du raisonnable
I Maintenable : résister aux changements afin d’augmenter sa durée de vie pour
un coût raisonnable
I Avec une interface utilisateur appropriée : adapté à l’usage qu’en font les
utilisateurs
Introduction Génie logiciel
Quels sont les critères de qualité d’un logiciel ?
Validité : correspondre à la spécification
Robustesse : fonctionner dans des conditions anormales
Extensibilité : adaptable aux changements de spécification
Réutilisabilité : peut être en partie ou intégralement réutilisé pour de
nouvelles applications
Compatibilité : peut être combiné à d’autres logiciels
Efficacité : utilisation optimale des ressources matérielles
Portabilité : facilité de transfert sous différents environnements matériels et
logiciels
Vérifiabilité : facilité de préparation des procédures de tests
Intégrité : protection du code et des données contre des accès non autorisés
Facilité d’emploi
Remarque
Il faut parfois faire des compromis parmi ces conditions
Introduction Génie logiciel
Démarche de création d’un logiciel
Spécification : d’après l’analyse des besoins
Conception : description du système à réaliser utilisable comme directives
d’implémentation
Implémentation : Développement par morceau et possibilité de retoucher les
modèles
Les tests : vérification des résultats de l’implémentation via
I des tests unitaires : vérification composant par composant
I des tests d’intégration : vérification de l’interaction entre composants
Le déploiement
Remarques
Cette description n’est pas détaillée
Il existe plusieurs modèles de cycles de vie d’un logiciel de la spécification à la
maintenance
Introduction Approche orientée objet
Qu’est-ce que l’approche orientée objet ?
Le système est vu comme une collection d’objets ayant des caractéristiques
Les données et leurs traitements ne sont pas dissociés
Focus sur les objets du système et non sur les fonctions qu’il doit réaliser
Facilité de réutilisation puisque les composants sont indépendants de
l’environnement
Caractéristiques d’un système orienté objet
Abstraction : Représentation des caractéristiques essentielles des objets via
des classes
Encapsulation : Masque les détails d’implémentation d’un objet
Typage : Des objets de types différents ne s’intervertissent pas
Hiérarchie : Spécialisation/généralisation des classes
Polymorphisme : Possibilité des méthodes de s’appliquer à des objets de
classes différentes
Modularité : Avoir des modules faiblement couplés pour favoriser la
réutilisation
Introduction Approche orientée objet
Un objet Une classe
Définit un ensemble d’objets ayant
Défini par :
des similitudes de :
Identité
Structure
Comportement
Comportement
État
En relation avec d’autres classes :
En relation avec d’autres objets :
Hiérarchie
Dans sa structure
Composant
Dans son utilisation
Association
Remarques
Une classe définit un type
Un objet de type T est une instance de la classe T
Introduction Modélisation
Modélisation objet
Représentation du système à réaliser (modèle) qui utilise une approche
orientée objet
Partie de l’étape de conception
Principes de conceptions orientée objet
Les principes SOLID
Single responsibility principle : Principe de responsabilité unique
I une classe ou une méthode ne doit avoir qu’une seule responsabilité
Open/closed principle : Principe ouvert/fermé
I Une entité doit être fermé à la modification directe mais ouverte à l’extension
Liskov substitution principle : Principe de substitution de Liskov
I Une instance de type T doit pouvoir être remplacée par une instance de type
G si G est une spécialisation de T
Interface segregation principle : Principe de ségrégation des interfaces
I Préférer l’utilisation de plusieurs interfaces plutôt qu’une seule interface
générale
Dependency inversion principle : Principe d’inversion des dépendances
I Dépendre des abstractions et non des implémentations
Introduction Modélisation
Méthodes de modélisation
Il existe de nombreuses méthodes pour conception orientée objet, dont :
OMT : fournit une représentation graphique des aspects statique, dynamique
et fonctionnel d’un système
OOD : introduit la notion de package
OOSE : fonde l’analyse sur la description des besoins des utilisateurs (use
cases)
UML
Unified Modeling Language
Langage permettant de rassembler les différents cas couverts par les
différentes méthodes
Utilisation de diagrammes
Les diagrammes statiques
I Pour définir la structure des éléments
Les diagrammes dynamiques
I Pour définir le comportement des éléments
Introduction Modélisation
Diagrammes statiques Diagrammes dynamiques
Diagrammes de classes diagramme de cas d’utilisation
Diagrammes d’objets diagramme d’activités
Diagramme de composants diagramme d’états-transitions
Diagramme de déploiement diagramme de séquence
Diagramme de packages diagramme de communication
Diagramme de structures diagramme global d’interaction
composites diagramme de temps
Remarques
Ils ne sont pas forcément tous utiles selon les applications
On ne les verra pas tous
