← Retour aux Cours 2023-2024

🎨 Conception Orientée Objet UML - Semestre 7

Année Universitaire : 2023-2024
Semestre : 7
Crédits : 2.5 ECTS
Spécialité : Génie Logiciel et Méthodologie

PART A - Présentation Générale du Module

Vue d'ensemble

Ce cours enseigne la conception orientée objet et le langage UML (Unified Modeling Language) pour analyser, concevoir et documenter des systèmes logiciels complexes. Il fournit une méthodologie structurée pour passer de l’analyse des besoins à une architecture logicielle robuste avant l’implémentation.

Objectifs pédagogiques :

Position dans le cursus

Ce module complète :

Il prépare à :

PART B - Expérience Personnelle et Contexte d’Apprentissage

Organisation et ressources

Le module était structuré en plusieurs volets :

Cours magistraux (12h) :

Travaux dirigés (12h) :

Projet de conception (16h) : Réalisation complète d’un système avec :

Ressources pédagogiques :

Méthodologie d'apprentissage

Phase 1 : Analyse des besoins : Identifier les acteurs, définir les cas d’utilisation, spécifier les exigences fonctionnelles et non-fonctionnelles.

Phase 2 : Modélisation structurelle : Créer les diagrammes de classes (entités, relations, multiplicités), définir les interfaces et l’architecture en couches.

Phase 3 : Modélisation comportementale : Décrire les interactions (diagrammes de séquence), les workflows (diagrammes d’activité), les états (machines à états).

Phase 4 : Application des patterns : Identifier les problèmes récurrents et appliquer les patterns appropriés (Factory, Observer, Strategy, etc.).

Phase 5 : Implémentation : Générer le code squelette depuis les diagrammes, implémenter la logique métier, maintenir la cohérence UML/code.

Difficultés rencontrées

Niveau d’abstraction : Trouver le bon équilibre entre détail et abstraction. Trop détaillé rend les diagrammes illisibles, trop abstrait les rend inutiles.

Multiplicité des diagrammes : UML propose 14 types de diagrammes. Savoir lesquels utiliser selon le contexte n’est pas immédiat.

Maintien de la cohérence : Garder les diagrammes synchronisés avec le code lors des évolutions demande de la rigueur et du temps.

Over-engineering : Tendance à vouloir appliquer trop de patterns ou créer des architectures trop complexes pour le problème donné.

PART C - Aspects Techniques Détaillés

1. Introduction à UML

UML = Unified Modeling Language

Langage de modélisation graphique standardisé (ISO/IEC 19505) pour visualiser, spécifier, construire et documenter des systèmes logiciels.

Historique :

Les 14 diagrammes UML :

Catégorie Diagrammes
Structurels Classes, Objets, Composants, Déploiement, Packages, Structure composite, Profil
Comportementaux Cas d’utilisation, Activité, États-transitions, Séquence, Communication, Timing, Vue d’ensemble interaction

En pratique : On utilise principalement 5-6 diagrammes (classes, séquence, activité, états, cas d’utilisation, composants).

2. Diagramme de cas d'utilisation

Objectif : Décrire les fonctionnalités du système du point de vue utilisateur.

Éléments :

Exemple : Système de bibliothèque

Acteurs :

Relations :

Notation :

3. Diagramme de classes

Objectif : Décrire la structure statique du système (classes, attributs, méthodes, relations).

Classe :

Une classe contient trois compartiments :

Visibilités :

Exemple :

Livre
--------------
- isbn : String
- titre : String
- auteur : String
- disponible : Boolean
--------------
+ emprunter() : Boolean
+ retourner() : void
+ estDisponible() : Boolean

Relations entre classes :

Relation Symbole Signification Exemple  
Association ligne simple Les classes se connaissent Lecteur — Livre  
Agrégation losange vide “A des” (partie peut exister seule) Bibliothèque ◇— Livre  
Composition losange plein “Composé de” (partie liée au tout) Voiture ◆— Moteur  
Héritage flèche triangle vide “Est un” LivreNumerique — > Livre
Réalisation flèche triangle pointillée Implémente interface ClasseConcrète .. > Interface
Dépendance flèche pointillée Utilise temporairement Client …> Service  

Multiplicités :

Exemple complet :

Bibliothèque (1) ◆— (0..*) Livre Lecteur (1) — (0..5) Emprunt Emprunt (*) — (1) Livre

Un lecteur peut avoir au maximum 5 emprunts simultanés.

4. Diagramme d'objets

Objectif : Montrer des instances concrètes à un instant donné (snapshot).

Différence avec diagramme de classes :

Exemple :

livre1 : Livre

lecteur1 : Lecteur

emprunt1 : Emprunt

Utilité : Valider le diagramme de classes avec des exemples concrets, illustrer des configurations complexes.

5. Diagramme de séquence

Objectif : Montrer les interactions entre objets dans le temps (ordre chronologique des messages).

Éléments :

Types de messages :

Exemple : Emprunter un livre

Lecteur → Bibliotheque : emprunterLivre(isbn)
Bibliotheque → Catalogue : rechercherLivre(isbn)
Catalogue → Bibliotheque : livre
alt livre disponible
    Bibliotheque → Emprunt : creerEmprunt(lecteur, livre)
    Emprunt → Livre : marquerEmprunte()
    Bibliotheque → Lecteur : confirmationEmprunt
else livre indisponible
    Bibliotheque → Lecteur : messageErreur
end

Fragments utiles :

6. Diagramme d'activité

Objectif : Modéliser les workflows, processus métier, algorithmes (similaire à un organigramme amélioré).

Éléments :

Exemple : Processus d’emprunt

[Début]
↓
Lecteur présente carte
↓
<Carte valide?>
  Non → Refuser emprunt → [Fin]
  Oui ↓
Scanner code-barres livre
↓
<Livre disponible?>
  Non → Proposer réservation → [Fin]
  Oui ↓
Enregistrer emprunt
|
Imprimer ticket
↓
[Fin]

Parallélisme avec fork/join :

Fork (barre horizontale) : → Activité A → Activité B (en parallèle)

Join : synchronisation (attendre que A et B soient terminées)

7. Diagramme d'états-transitions

Objectif : Modéliser le cycle de vie d’un objet (états possibles et transitions).

Éléments :

Exemple : États d’un livre

[Initial]
↓
Disponible
  entry/ afficherDisponible()
  
Disponible --[emprunter]--> Emprunté
  entry/ enregistrerEmprunt()
  do/ decrementersDisponibilites()
  
Emprunté --[retourner]--> Disponible
  exit/ libererExemplaire()
  
Emprunté --[depasser delai]--> EnRetard
  entry/ calculerAmende()
  
EnRetard --[retourner + payer amende]--> Disponible

Disponible --[retirer du catalogue]--> [Final]

États composites : Un état peut contenir des sous-états (hiérarchie).

États concurrents : Plusieurs états actifs simultanément (séparés par ligne pointillée).

8. Diagrammes de composants et déploiement

Diagramme de composants :

Montre l’organisation logicielle en modules/bibliothèques avec leurs dépendances.

Composants typiques :

Relations :

Diagramme de déploiement :

Montre l’architecture physique (serveurs, réseaux, artefacts déployés).

Éléments :

Exemple :

Serveur Web
  - Apache Tomcat
  - Application.war
  
Base de données
  - MySQL Server
  - Schema bibliotheque
  
Poste client
  - Navigateur Web
  - Interface HTML/CSS/JS

9. Principes de conception SOLID

Ensemble de 5 principes pour créer du code maintenable et extensible.

S - Single Responsibility Principle (SRP) :

Une classe doit avoir une seule raison de changer (une seule responsabilité).

Mauvais :

class Livre
  + sauvegarderDansBaseDeDonnees()  // responsabilité persistance
  + envoyerEmailNotification()       // responsabilité notification

Bon :

class Livre
  // seulement logique métier livre

class LivreRepository
  + sauvegarder(livre)

class NotificationService
  + envoyerEmail(destinataire, message)

O - Open/Closed Principle (OCP) :

Les classes doivent être ouvertes à l’extension, fermées à la modification.

Utiliser l’héritage, la composition, ou les interfaces pour étendre sans modifier le code existant.

L - Liskov Substitution Principle (LSP) :

Les objets d’une classe dérivée doivent pouvoir remplacer les objets de la classe de base sans altérer le comportement.

I - Interface Segregation Principle (ISP) :

Mieux vaut plusieurs interfaces spécifiques qu’une interface générale.

Mauvais :

interface DocumentActions
  + imprimer()
  + scanner()
  + faxer()

Une imprimante simple doit implémenter scanner() et faxer() même si elle ne les supporte pas.

Bon :

interface Imprimable
  + imprimer()

interface Scannable
  + scanner()

class ImprimanteSimple implements Imprimable
class ImprimanteMultifonction implements Imprimable, Scannable

D - Dependency Inversion Principle (DIP) :

Dépendre des abstractions (interfaces), pas des implémentations concrètes.

Mauvais :

class Bibliotheque
  private MySQLDatabase db  // dépendance concrète

Bon :

interface Database
  + sauvegarder(data)
  + charger(id)

class Bibliotheque
  private Database db  // dépendance abstraite

class MySQLDatabase implements Database
class MongoDBDatabase implements Database

Permet de changer facilement de base de données sans modifier Bibliotheque.

10. Design Patterns (Patrons de conception)

Solutions éprouvées à des problèmes récurrents de conception.

Patterns créationnels : gestion de la création d’objets

Singleton : Garantir une seule instance d’une classe.

class ConfigurationManager
  private static instance : ConfigurationManager
  
  private ConfigurationManager()  // constructeur privé
  
  public static getInstance() : ConfigurationManager
    if instance == null
      instance = new ConfigurationManager()
    return instance

Utilisation : gestionnaires uniques (configuration, logging, pool de connexions).

Factory Method : Déléguer la création d’objets aux sous-classes.

abstract class DocumentFactory
  abstract creerDocument() : Document
  
class PDFFactory extends DocumentFactory
  creerDocument() : Document
    return new PDFDocument()
    
class WordFactory extends DocumentFactory
  creerDocument() : Document
    return new WordDocument()

Abstract Factory : Créer des familles d’objets liés sans spécifier leurs classes concrètes.

Patterns structurels : organisation des classes et objets

Adapter : Convertir l’interface d’une classe en une autre interface attendue.

interface LecteurMultimedia
  + lire(fichier)

class LecteurMP3
  + jouerMP3(fichier)

class AdapterMP3 implements LecteurMultimedia
  private lecteurMP3 : LecteurMP3
  
  lire(fichier)
    lecteurMP3.jouerMP3(fichier)

Decorator : Ajouter dynamiquement des responsabilités à un objet.

interface Cafe
  + cout() : double

class CafeSimple implements Cafe
  cout() : double
    return 2.0

class AvecLait implements Cafe
  private cafe : Cafe
  
  cout() : double
    return cafe.cout() + 0.5

class AvecSucre implements Cafe
  private cafe : Cafe
  
  cout() : double
    return cafe.cout() + 0.2

Usage :

Cafe monCafe = new AvecLait(new AvecSucre(new CafeSimple()))
// cout = 2.0 + 0.2 + 0.5 = 2.7

Composite : Composer des objets en structures arborescentes (traiter uniformément objets individuels et compositions).

Patterns comportementaux : interactions entre objets

Observer : Notifier automatiquement des objets lors d’un changement d’état.

interface Observer
  + update(sujet)

class Sujet
  private observateurs : List<Observer>
  
  + attacher(observateur)
    observateurs.add(observateur)
  
  + notifier()
    for each observateur in observateurs
      observateur.update(this)

class AffichageTemperature implements Observer
  update(sujet)
    temperature = sujet.getTemperature()
    afficher(temperature)

Utilisation : interfaces graphiques (MVC), systèmes événementiels.

Strategy : Encapsuler des algorithmes interchangeables.

interface StrategieCalculAmende
  + calculer(joursRetard) : double

class AmendeStandard implements StrategieCalculAmende
  calculer(joursRetard) : double
    return joursRetard * 0.5

class AmendeEtudiant implements StrategieCalculAmende
  calculer(joursRetard) : double
    return joursRetard * 0.2

class GestionnaireEmprunt
  private strategie : StrategieCalculAmende
  
  definirStrategie(strategie)
    this.strategie = strategie
  
  calculerAmende(joursRetard)
    return strategie.calculer(joursRetard)

Command : Encapsuler une requête comme un objet.

Permet : annulation (undo), file d’attente de commandes, journalisation.

State : Modifier le comportement d’un objet selon son état interne.

Template Method : Définir le squelette d’un algorithme, les sous-classes redéfinissent certaines étapes.

11. De UML au code

Forward Engineering : générer du code depuis les diagrammes UML.

Outils :

Exemple : diagramme de classes → classes Java avec attributs et signatures de méthodes (squelettes).

Reverse Engineering : générer des diagrammes UML depuis le code existant.

Utile pour :

Round-trip Engineering : synchronisation bidirectionnelle code ↔ UML.

Modifications du code reflétées dans les diagrammes et vice-versa.

En pratique : difficile à maintenir, nécessite discipline et outillage adapté.

12. Outils de modélisation

Outil Type Avantages Inconvénients
Enterprise Architect Commercial Complet, génération code, collaboration Coûteux, interface complexe
StarUML Open-source/Commercial Interface intuitive, légèreté Fonctionnalités limitées version gratuite
PlantUML Open-source Textuel, intégration CI/CD, versioning Courbe apprentissage syntaxe
Lucidchart Web Collaboratif, facile Limité version gratuite
draw.io Web/Open Gratuit, simple Pas spécialisé UML
Visual Paradigm Commercial Puissant, formation incluse Coûteux

Recommandation personnelle :

PART D - Analyse Réflexive et Perspectives

Compétences acquises

Modélisation et abstraction : Capacité à analyser un problème complexe et à le décomposer en entités, relations et comportements modélisables.

Communication technique : UML fournit un langage universel pour communiquer des architectures entre développeurs, chefs de projet, et clients.

Anticipation et planification : Concevoir avant d’implémenter permet d’identifier les problèmes d’architecture tôt, réduisant les coûts de refactoring.

Qualité logicielle : Application des principes SOLID et patterns produit du code plus maintenable, testable et extensible.

Projet réalisé : Système de gestion de bibliothèque

Contexte : Conception complète d’un système de bibliothèque multimédia (livres, DVDs, périodiques) avec gestion des emprunts, réservations, amendes, et utilisateurs.

Livrables :

Patterns utilisés :

Résultats : Architecture claire et extensible. Ajout de nouveaux types de documents ou nouvelles règles d’amende facile grâce aux patterns. Code bien structuré avec séparation des responsabilités.

Points clés à retenir

1. UML = outil, pas objectif : L’objectif est une bonne conception, pas de beaux diagrammes. Utiliser UML de manière pragmatique.

2. Tous les diagrammes ne sont pas nécessaires : Identifier ceux qui apportent de la valeur selon le contexte (classes et séquence souvent suffisants).

3. SOLID avant patterns : Comprendre et appliquer SOLID est plus important que connaître tous les patterns.

4. Patterns = solutions, pas recettes magiques : Ne pas forcer l’utilisation d’un pattern. L’appliquer seulement si le problème correspond.

5. Documentation vivante : La documentation doit évoluer avec le code, sinon elle devient obsolète et trompeuse.

Retour d'expérience

Courbe d’apprentissage : UML semblait complexe initialement (14 diagrammes, notations spécifiques). Avec la pratique, on identifie rapidement les 5-6 diagrammes essentiels.

Lien avec la POO : Ce cours a renforcé ma compréhension de la POO au-delà de la syntaxe. Concepts comme l’encapsulation, l’abstraction, le polymorphisme deviennent concrets.

Application en projets : Utiliser UML sur des projets réels (même simplifiés) a prouvé son utilité. Gain de temps et moins de bugs grâce à la réflexion en amont.

Collaboration facilitée : Travailler en équipe avec UML comme langage commun a grandement amélioré la communication et réduit les malentendus.

Applications pratiques

Développement logiciel :

Refactoring : Reverse engineering de code legacy, identification des problèmes (couplage fort, responsabilités mixtes), puis refactoring guidé par SOLID.

Documentation : Générer automatiquement documentation technique à partir des diagrammes UML. Intégration dans wikis d’entreprise.

Communication client : Diagrammes de cas d’utilisation et d’activité compréhensibles par non-développeurs pour valider les besoins.

Limites et critiques

UML lourd et verbeux : Créer et maintenir tous les diagrammes prend du temps. Approche agile préfère “UML léger” (quelques diagrammes clés).

Décalage documentation/code : Sans discipline ou outils de synchronisation, les diagrammes deviennent rapidement obsolètes.

Over-engineering : Risque de créer des architectures trop complexes, avec trop de patterns, pour des problèmes simples.

Alternatives modernes :

Évolutions et perspectives

Domain-Driven Design (DDD) : Approche centrée sur le domaine métier. Utilise UML mais ajoute concepts (Entities, Value Objects, Aggregates, Repositories).

SysML : Extension UML pour ingénierie système (pas seulement logiciel). Utilisé en aéronautique, automobile, défense.

Outils modernes :

Intelligence Artificielle : IA génératrice de diagrammes UML depuis descriptions textuelles, détection automatique de violations SOLID, suggestions de patterns.

Conseils pour réussir

1. Pratiquer sur projets concrets : Modéliser des systèmes réels (e-commerce, réseau social, jeu) plutôt que des exercices abstraits.

2. Commencer simple : Débuter avec diagrammes de classes et séquence. Ajouter d’autres types selon les besoins.

3. Valider avec du code : Implémenter les designs pour vérifier leur cohérence et faisabilité.

4. Étudier du code open-source : Analyser l’architecture de projets populaires (Spring Framework, Apache Commons) pour voir SOLID et patterns en pratique.

5. Itérer : La conception n’est jamais parfaite du premier coup. Réviser et améliorer au fur et à mesure.

Conclusion

Ce module fournit une méthodologie essentielle pour concevoir des systèmes logiciels robustes et maintenables. Au-delà de la syntaxe UML, ce sont les principes de conception objet (SOLID) et les patterns qui constituent l’apport majeur.

Compétences transférables :

Pertinence professionnelle : En entreprise, la conception et documentation sont attendues, surtout pour projets critiques ou réglementés. Savoir modéliser et justifier ses choix d’architecture est un atout majeur.

Message principal : UML est un outil parmi d’autres. L’essentiel est de développer une démarche de conception structurée, applicable quel que soit le formalisme. Les principes SOLID et patterns sont universels et transcendent les langages et outils.

Recommandations :

Liens avec les autres cours :

📚 Documents de Cours

📖 Cours Conception et Architectures

Cours complet UML : diagrammes de classes, séquences, cas d'utilisation, patterns de conception et principes SOLID.

📥 Télécharger

📖 Sujet TD

Travaux dirigés sur la conception orientée objet : modélisation de systèmes embarqués et architectures logicielles.

📥 Télécharger

Cours suivi en 2023-2024 à l’INSA Toulouse, Département Génie Électrique et Informatique.

← Retour aux Cours 2023-2024