Conception Orientee Objet UML - Semestre 7

Annee Universitaire : 2023-2024
Semestre : 7
Credits : 2.5 ECTS
Specialite : Genie Logiciel et Methodologie

---

PART A - Presentation Generale du Module

Vue d'ensemble

Ce cours enseigne la conception orientee objet et le langage UML (Unified Modeling Language) pour analyser, concevoir et documenter des systemes logiciels complexes. Il fournit une methodologie structuree pour passer de l'analyse des besoins a une architecture logicielle robuste avant l'implementation.

Objectifs pedagogiques :

• Maitriser les diagrammes UML structurels et comportementaux
• Appliquer les principes de conception objet (SOLID)
• Utiliser les design patterns classiques (GoF)
• Concevoir des architectures logicielles maintenables
• Documenter efficacement un projet logiciel

Position dans le cursus

Ce module complete :

• Programmation Orientee Objets C++ (S7) : concepts POO en pratique
• Programmation Orientee Objets Java (S7) : implementation des designs
• Langage C (S5) : transition vers la POO

Il prepare a :

• Projets de genie logiciel : architectures complexes
• Travail en equipe : communication via UML
• Ingenierie logicielle industrielle : documentation standardisee
• Maintenance et evolution : code structure et extensible

---

PART B - Experience Personnelle et Contexte d'Apprentissage

Organisation et ressources

Le module etait structure en plusieurs volets :

Cours magistraux (12h) :

• Introduction a UML et a la conception objet
• Diagrammes structurels (classes, objets, composants, deploiement)
• Diagrammes comportementaux (sequence, activite, etats)
• Principes SOLID et bonnes pratiques
• Design patterns du Gang of Four

Travaux diriges (12h) :

• Exercices de modelisation sur cas d'etude
• Correction et discussion des TD
• Ressource disponible : Correction_TD.txt avec lien Notion detaille
• Analyse de problemes reels (bibliotheque, e-commerce, systeme embarque)

Projet de conception (16h) :

Realisation complete d'un systeme avec :

• Analyse des besoins (cas d'utilisation)
• Modelisation structurelle (diagrammes de classes)
• Modelisation comportementale (sequence, etats)
• Prototypage en Java ou C++
• Documentation UML complete

Ressources pedagogiques :

• Cours_ConceptionArchitectures.pdf (support de cours)
• Notes partagees Notion (correction des TD)
• Outils : Enterprise Architect, StarUML, PlantUML
• Livres de reference : "Design Patterns" (GoF), "UML 2" (Pascal Roques)

Methodologie d'apprentissage

Phase 1 : Analyse des besoins :

Identifier les acteurs, definir les cas d'utilisation, specifier les exigences fonctionnelles et non-fonctionnelles.

Phase 2 : Modelisation structurelle :

Creer les diagrammes de classes (entites, relations, multiplicites), definir les interfaces et l'architecture en couches.

Phase 3 : Modelisation comportementale :

Decrire les interactions (diagrammes de sequence), les workflows (diagrammes d'activite), les etats (machines a etats).

Phase 4 : Application des patterns :

Identifier les problemes recurrents et appliquer les patterns appropries (Factory, Observer, Strategy, etc.).

Phase 5 : Implementation :

Generer le code squelette depuis les diagrammes, implementer la logique metier, maintenir la coherence UML/code.

Difficultes rencontrees

Niveau d'abstraction :

Trouver le bon equilibre entre detail et abstraction. Trop detaille rend les diagrammes illisibles, trop abstrait les rend inutiles.

Multiplicite des diagrammes :

UML propose 14 types de diagrammes. Savoir lesquels utiliser selon le contexte n'est pas immediat.

Maintien de la coherence :

Garder les diagrammes synchronises avec le code lors des evolutions demande de la rigueur et du temps.

Over-engineering :

Tendance a vouloir appliquer trop de patterns ou creer des architectures trop complexes pour le probleme donne.

---

PART C - Aspects Techniques Detailles

1. Introduction a UML

UML = Unified Modeling Language

Langage de modelisation graphique standardise (ISO/IEC 19505) pour visualiser, specifier, construire et documenter des systemes logiciels.

Historique :

• Annees 1990 : fusion des methodes Booch, OMT, OOSE
• Version 1.0 en 1997
• Version 2.5 actuelle (2015)

Les 14 diagrammes UML :

Categorie	Diagrammes
Structurels	Classes, Objets, Composants, Deploiement, Packages, Structure composite, Profil
Comportementaux	Cas d'utilisation, Activite, Etats-transitions, Sequence, Communication, Timing, Vue d'ensemble interaction

En pratique : On utilise principalement 5-6 diagrammes (classes, sequence, activite, etats, cas d'utilisation, composants).

2. Diagramme de cas d'utilisation

Objectif : Decrire les fonctionnalites du systeme du point de vue utilisateur.

Elements :

• Acteur : Utilisateur ou systeme externe
• Cas d'utilisation : Fonctionnalite offerte
• Relations : include (inclusion obligatoire), extend (extension conditionnelle), generalisation

Exemple : Systeme de bibliotheque

Acteurs :

• Lecteur (emprunter livre, consulter catalogue)
• Bibliothecaire (enregistrer retour, gerer amendes)
• Administrateur (ajouter livre, gerer utilisateurs)

Relations :

• "Emprunter livre" include "Verifier disponibilite"
• "Rechercher livre" extend "Filtrer par auteur"

Notation :

• Acteur : bonhomme stylise
• Cas d'utilisation : ellipse avec nom
• Relations : fleches avec stereotypes

3. Diagramme de classes

Objectif : Decrire la structure statique du systeme (classes, attributs, methodes, relations).

Classe :

Une classe contient trois compartiments :

• Nom de la classe
• Attributs (visibilite nom : type)
• Methodes (visibilite nom(parametres) : type_retour)

Visibilites :

• + public (accessible partout)
• - private (accessible seulement dans la classe)
• # protected (accessible dans la classe et ses sous-classes)
• ~ package (accessible dans le package)

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
Agregation	losange vide	"A des" (partie peut exister seule)	Bibliotheque --- Livre
Composition	losange plein	"Compose de" (partie liee au tout)	Voiture --- Moteur
Heritage	fleche triangle vide	"Est un"	LivreNumerique ---|> Livre
Realisation	fleche triangle pointillee	Implemente interface	ClasseConcrete ..|> Interface
Dependance	fleche pointillee	Utilise temporairement	Client ...> Service

Multiplicites :

• 1 : exactement un
• 0..1 : zero ou un
• * : zero ou plusieurs
• 1..* : un ou plusieurs
• 2..5 : entre 2 et 5

Exemple complet :

Bibliotheque (1) --- (0..*) Livre
Lecteur (1) --- (0..5) Emprunt
Emprunt (*) --- (1) Livre

Un lecteur peut avoir au maximum 5 emprunts simultanes.

4. Diagramme d'objets

Objectif : Montrer des instances concretes a un instant donne (snapshot).

Difference avec diagramme de classes :

• Classes : structure generale
• Objets : instances particulieres avec valeurs

Exemple :

livre1 : Livre
- isbn = "978-2-1234"
- titre = "Design Patterns"
- disponible = false

lecteur1 : Lecteur
- nom = "Dupont"
- numeroCarte = "12345"

emprunt1 : Emprunt
- dateEmprunt = "2024-11-15"
- dateRetourPrevue = "2024-12-15"

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

5. Diagramme de sequence

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

Elements :

• Lignes de vie : lignes verticales representant les objets
• Messages : fleches horizontales entre lignes de vie
• Activation : rectangle sur ligne de vie (objet actif)
• Fragments : alt (alternative), loop (boucle), opt (optionnel), par (parallele)

Types de messages :

• Synchrone : fleche pleine (appelant attend la reponse)
• Asynchrone : fleche ouverte (appelant continue sans attendre)
• Retour : fleche pointillee

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 :

• alt : if/else (branches alternatives)
• loop : boucle (condition et iteration)
• opt : optionnel (execute si condition vraie)
• par : parallele (execution simultanee)
• ref : reference a un autre diagramme

6. Diagramme d'activite

Objectif : Modeliser les workflows, processus metier, algorithmes (similaire a un organigramme ameliore).

Elements :

• Noeud initial : cercle noir plein
• Noeud final : cercle noir avec cercle autour
• Activite : rectangle arrondi
• Decision : losange (condition)
• Fork/Join : barre horizontale (parallelisme)
• Swimlanes : partitions par acteur/systeme

Exemple : Processus d'emprunt

[Debut]
|
Lecteur presente carte
|
<Carte valide?>
  Non -> Refuser emprunt -> [Fin]
  Oui |
Scanner code-barres livre
|
<Livre disponible?>
  Non -> Proposer reservation -> [Fin]
  Oui |
Enregistrer emprunt
|
Imprimer ticket
|
[Fin]

Parallelisme avec fork/join :

Fork (barre horizontale) :
-> Activite A
-> Activite B (en parallele)

Join : synchronisation (attendre que A et B soient terminees)

7. Diagramme d'etats-transitions

Objectif : Modeliser le cycle de vie d'un objet (etats possibles et transitions).

Elements :

• Etat : rectangle arrondi
• Transition : fleche avec evenement declencheur
• Etat initial : cercle noir
• Etat final : cercle noir avec cercle
• Actions : entry/ (a l'entree), do/ (pendant), exit/ (a la sortie)

Exemple : Etats d'un livre

[Initial]
|
Disponible
  entry/ afficherDisponible()

Disponible --[emprunter]--> Emprunte
  entry/ enregistrerEmprunt()
  do/ decrementerDisponibilites()

Emprunte --[retourner]--> Disponible
  exit/ libererExemplaire()

Emprunte --[depasser delai]--> EnRetard
  entry/ calculerAmende()

EnRetard --[retourner + payer amende]--> Disponible

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

Etats composites :

Un etat peut contenir des sous-etats (hierarchie).

Etats concurrents :

Plusieurs etats actifs simultanement (separes par ligne pointillee).

8. Diagrammes de composants et deploiement

Diagramme de composants :

Montre l'organisation logicielle en modules/bibliotheques avec leurs dependances.

Composants typiques :

• Interface Utilisateur (UI)
• Logique metier (Business Logic)
• Acces aux donnees (DAO)
• Bibliotheques externes

Relations :

• Dependances entre composants
• Interfaces fournies (cercle) et requises (demi-cercle)

Diagramme de deploiement :

Montre l'architecture physique (serveurs, reseaux, artefacts deployes).

Elements :

• Noeuds : materiel (serveur, PC, mobile)
• Artefacts : fichiers deployes (JAR, EXE, WAR)
• Communications : protocoles (HTTP, TCP, etc.)

Exemple :

Serveur Web
  - Apache Tomcat
  - Application.war

Base de donnees
  - MySQL Server
  - Schema bibliotheque

Poste client
  - Navigateur Web
  - Interface HTML/CSS/JS

9. Principes de conception SOLID

Ensemble de 5 principes pour creer du code maintenable et extensible.

S - Single Responsibility Principle (SRP) :

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

Mauvais :

class Livre
  + sauvegarderDansBaseDeDonnees()  // responsabilite persistance
  + envoyerEmailNotification()       // responsabilite notification

Bon :

class Livre
  // seulement logique metier livre

class LivreRepository
  + sauvegarder(livre)

class NotificationService
  + envoyerEmail(destinataire, message)

O - Open/Closed Principle (OCP) :

Les classes doivent etre ouvertes a l'extension, fermees a la modification.

Utiliser l'heritage, la composition, ou les interfaces pour etendre sans modifier le code existant.

L - Liskov Substitution Principle (LSP) :

Les objets d'une classe derivee doivent pouvoir remplacer les objets de la classe de base sans alterer le comportement.

I - Interface Segregation Principle (ISP) :

Mieux vaut plusieurs interfaces specifiques qu'une interface generale.

Mauvais :

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

Une imprimante simple doit implementer scanner() et faxer() meme 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) :

Dependre des abstractions (interfaces), pas des implementations concretes.

Mauvais :

class Bibliotheque
  private MySQLDatabase db  // dependance concrete

Bon :

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

class Bibliotheque
  private Database db  // dependance abstraite

class MySQLDatabase implements Database
class MongoDBDatabase implements Database

Permet de changer facilement de base de donnees sans modifier Bibliotheque.

10. Design Patterns (Patrons de conception)

Solutions eprouvees a des problemes recurrents de conception.

Patterns creationnels : gestion de la creation d'objets

Singleton :

Garantir une seule instance d'une classe.

class ConfigurationManager
  private static instance : ConfigurationManager

  private ConfigurationManager()  // constructeur prive

  public static getInstance() : ConfigurationManager
    if instance == null
      instance = new ConfigurationManager()
    return instance

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

Factory Method :

Deleguer la creation 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 :

Creer des familles d'objets lies sans specifier leurs classes concretes.

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 responsabilites a 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 uniformement objets individuels et compositions).

Patterns comportementaux : interactions entre objets

Observer :

Notifier automatiquement des objets lors d'un changement d'etat.

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), systemes evenementiels.

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 requete comme un objet.

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

State :

Modifier le comportement d'un objet selon son etat interne.

Template Method :

Definir le squelette d'un algorithme, les sous-classes redefinissent certaines etapes.

11. De UML au code

Forward Engineering : generer du code depuis les diagrammes UML.

Outils :

• Enterprise Architect (generation Java, C++, C#, Python)
• StarUML (generation code basique)
• PlantUML + scripts custom

Exemple : diagramme de classes -> classes Java avec attributs et signatures de methodes (squelettes).

Reverse Engineering : generer des diagrammes UML depuis le code existant.

Utile pour :

• Documenter du legacy code
• Analyser une base de code inconnue
• Maintenir coherence code/documentation

Round-trip Engineering : synchronisation bidirectionnelle code / UML.

Modifications du code refletees dans les diagrammes et vice-versa.

En pratique : difficile a maintenir, necessite discipline et outillage adapte.

12. Outils de modelisation

Outil	Type	Avantages	Inconvenients
Enterprise Architect	Commercial	Complet, generation code, collaboration	Couteux, interface complexe
StarUML	Open-source/Commercial	Interface intuitive, legerete	Fonctionnalites limitees version gratuite
PlantUML	Open-source	Textuel, integration CI/CD, versioning	Courbe apprentissage syntaxe
Lucidchart	Web	Collaboratif, facile	Limite version gratuite
draw.io	Web/Open	Gratuit, simple	Pas specialise UML
Visual Paradigm	Commercial	Puissant, formation incluse	Couteux

Recommandation personnelle :

• Projets personnels : PlantUML (versionnable avec Git)
• Entreprise : Enterprise Architect ou Visual Paradigm
• Collaboration rapide : Lucidchart ou Miro

---

PART D - Analyse Reflexive et Perspectives

Competences acquises

Modelisation et abstraction :

Capacite a analyser un probleme complexe et a le decomposer en entites, relations et comportements modelisables.

Communication technique :

UML fournit un langage universel pour communiquer des architectures entre developpeurs, chefs de projet, et clients.

Anticipation et planification :

Concevoir avant d'implementer permet d'identifier les problemes d'architecture tot, reduisant les couts de refactoring.

Qualite logicielle :

Application des principes SOLID et patterns produit du code plus maintenable, testable et extensible.

Projet realise : Systeme de gestion de bibliotheque

Contexte :

Conception complete d'un systeme de bibliotheque multimedia (livres, DVDs, periodiques) avec gestion des emprunts, reservations, amendes, et utilisateurs.

Livrables :

• Diagramme de cas d'utilisation (12 cas, 4 acteurs)
• Diagramme de classes complet (35+ classes)
• Diagrammes de sequence (emprunter, retourner, reserver, payer amende)
• Diagrammes d'etats (cycle de vie livre, emprunt)
• Diagramme d'activite (processus d'emprunt complet)
• Prototype Java avec patterns appliques

Patterns utilises :

• Singleton : BibliothequeManager (instance unique)
• Factory : DocumentFactory pour creer Livre, DVD, Periodique
• Observer : notification disponibilite pour reservations
• Strategy : calcul amendes selon type utilisateur (standard, etudiant, enseignant)
• State : gestion etats emprunt (en cours, en retard, termine)

Resultats :

Architecture claire et extensible. Ajout de nouveaux types de documents ou nouvelles regles d'amende facile grace aux patterns. Code bien structure avec separation des responsabilites.

Points cles a retenir

1. UML = outil, pas objectif :

L'objectif est une bonne conception, pas de beaux diagrammes. Utiliser UML de maniere pragmatique.

2. Tous les diagrammes ne sont pas necessaires :

Identifier ceux qui apportent de la valeur selon le contexte (classes et sequence souvent suffisants).

3. SOLID avant patterns :

Comprendre et appliquer SOLID est plus important que connaitre tous les patterns.

4. Patterns = solutions, pas recettes magiques :

Ne pas forcer l'utilisation d'un pattern. L'appliquer seulement si le probleme correspond.

5. Documentation vivante :

La documentation doit evoluer avec le code, sinon elle devient obsolete et trompeuse.

Retour d'experience

Courbe d'apprentissage :

UML semblait complexe initialement (14 diagrammes, notations specifiques). Avec la pratique, on identifie rapidement les 5-6 diagrammes essentiels.

Lien avec la POO :

Ce cours a renforce ma comprehension de la POO au-dela de la syntaxe. Concepts comme l'encapsulation, l'abstraction, le polymorphisme deviennent concrets.

Application en projets :

Utiliser UML sur des projets reels (meme simplifies) a prouve son utilite. Gain de temps et moins de bugs grace a la reflexion en amont.

Collaboration facilitee :

Travailler en equipe avec UML comme langage commun a grandement ameliore la communication et reduit les malentendus.

Applications pratiques

Developpement logiciel :

• Applications d'entreprise (ERP, CRM)
• Systemes embarques (modelisation etats et sequences critiques)
• Applications web (architecture MVC/MVVM)

Refactoring :

Reverse engineering de code legacy, identification des problemes (couplage fort, responsabilites mixtes), puis refactoring guide par SOLID.

Documentation :

Generer automatiquement documentation technique a partir des diagrammes UML. Integration dans wikis d'entreprise.

Communication client :

Diagrammes de cas d'utilisation et d'activite comprehensibles par non-developpeurs pour valider les besoins.

Limites et critiques

UML lourd et verbeux :

Creer et maintenir tous les diagrammes prend du temps. Approche agile prefere "UML leger" (quelques diagrammes cles).

Decalage documentation/code :

Sans discipline ou outils de synchronisation, les diagrammes deviennent rapidement obsoletes.

Over-engineering :

Risque de creer des architectures trop complexes, avec trop de patterns, pour des problemes simples.

Alternatives modernes :

• C4 Model : documentation architecturale pragmatique (Context, Containers, Components, Code)
• Architecture Decision Records (ADR) : documenter les decisions plutot que les diagrammes
• Living Documentation : tests et code comme documentation

Evolutions et perspectives

Domain-Driven Design (DDD) :

Approche centree sur le domaine metier. Utilise UML mais ajoute concepts (Entities, Value Objects, Aggregates, Repositories).

SysML :

Extension UML pour ingenierie systeme (pas seulement logiciel). Utilise en aeronautique, automobile, defense.

Outils modernes :

• Generation automatique de diagrammes depuis le code (Doxygen, Javadoc UML)
• Documentation as Code (PlantUML en Markdown, versioning Git)
• Collaboration temps reel (Miro, Lucidchart, Figma pour UML)

Intelligence Artificielle :

IA generatrice de diagrammes UML depuis descriptions textuelles, detection automatique de violations SOLID, suggestions de patterns.

Conseils pour reussir

1. Pratiquer sur projets concrets :

Modeliser des systemes reels (e-commerce, reseau social, jeu) plutot que des exercices abstraits.

2. Commencer simple :

Debuter avec diagrammes de classes et sequence. Ajouter d'autres types selon les besoins.

3. Valider avec du code :

Implementer les designs pour verifier leur coherence et faisabilite.

4. Etudier du code open-source :

Analyser l'architecture de projets populaires (Spring Framework, Apache Commons) pour voir SOLID et patterns en pratique.

5. Iterer :

La conception n'est jamais parfaite du premier coup. Reviser et ameliorer au fur et a mesure.

Conclusion

Ce module fournit une methodologie essentielle pour concevoir des systemes logiciels robustes et maintenables. Au-dela de la syntaxe UML, ce sont les principes de conception objet (SOLID) et les patterns qui constituent l'apport majeur.

Competences transferables :

• Pensee architecturale et abstraite
• Conception avant implementation
• Communication technique efficace
• Code de qualite professionnelle

Pertinence professionnelle :

En entreprise, la conception et documentation sont attendues, surtout pour projets critiques ou reglementes. Savoir modeliser et justifier ses choix d'architecture est un atout majeur.

Message principal :

UML est un outil parmi d'autres. L'essentiel est de developper une demarche de conception structuree, applicable quel que soit le formalisme. Les principes SOLID et patterns sont universels et transcendent les langages et outils.

Recommandations :

• Utiliser UML de maniere pragmatique (eviter dogmatisme)
• Privilegier les diagrammes qui apportent de la valeur
• Maintenir documentation a jour (automatisation si possible)
• Continuer a apprendre patterns avances et architectures (microservices, event-driven)
• Explorer DDD pour approfondir modelisation metier

Liens avec les autres cours :

• Programmation Orientee Objets C++ - S7 : implementation des concepts
• Programmation Orientee Objets Java - S7 : application pratique
• Graphes et Programmation Lineaire - S8 : modelisation problemes

---

Documents de CoursCourse Documents

---

Cours suivi en 2023-2024 a l'INSA Toulouse, Departement Genie Electrique et Informatique.Course taken in 2023-2024 at INSA Toulouse, Department of Electrical Engineering and Computer Science.

Book
--------------
- isbn : String
- title : String
- author : String
- available : Boolean
--------------
+ borrow() : Boolean
+ return() : void
+ isAvailable() : Boolean

book1 : Book
- isbn = "978-2-1234"
- title = "Design Patterns"
- available = false

reader1 : Reader
- name = "Dupont"
- cardNumber = "12345"

loan1 : Loan
- loanDate = "2024-11-15"
- expectedReturnDate = "2024-12-15"

Reader -> Library : borrowBook(isbn)
Library -> Catalog : searchBook(isbn)
Catalog -> Library : book
alt book available
    Library -> Loan : createLoan(reader, book)
    Loan -> Book : markBorrowed()
    Library -> Reader : borrowConfirmation
else book unavailable
    Library -> Reader : errorMessage
end

[Start]
|
Reader presents card
|
<Card valid?>
  No -> Refuse loan -> [End]
  Yes |
Scan book barcode
|
<Book available?>
  No -> Offer reservation -> [End]
  Yes |
Register loan
|
Print receipt
|
[End]

[Initial]
|
Available
  entry/ displayAvailable()

Available --[borrow]--> Borrowed
  entry/ registerLoan()
  do/ decrementAvailability()

Borrowed --[return]--> Available
  exit/ releaseItem()

Borrowed --[exceed deadline]--> Overdue
  entry/ calculateFine()

Overdue --[return + pay fine]--> Available

Available --[remove from catalog]--> [Final]

Web Server
  - Apache Tomcat
  - Application.war

Database
  - MySQL Server
  - Library schema

Client Workstation
  - Web Browser
  - HTML/CSS/JS Interface

class Book
  + saveToDatabase()          // persistence responsibility
  + sendEmailNotification()   // notification responsibility

class Book
  // only book business logic

class BookRepository
  + save(book)

class NotificationService
  + sendEmail(recipient, message)

interface DocumentActions
  + print()
  + scan()
  + fax()

interface Printable
  + print()

interface Scannable
  + scan()

class SimplePrinter implements Printable
class MultifunctionPrinter implements Printable, Scannable

class Library
  private MySQLDatabase db  // concrete dependency

interface Database
  + save(data)
  + load(id)

class Library
  private Database db  // abstract dependency

class MySQLDatabase implements Database
class MongoDBDatabase implements Database

class ConfigurationManager
  private static instance : ConfigurationManager

  private ConfigurationManager()  // private constructor

  public static getInstance() : ConfigurationManager
    if instance == null
      instance = new ConfigurationManager()
    return instance

abstract class DocumentFactory
  abstract createDocument() : Document

class PDFFactory extends DocumentFactory
  createDocument() : Document
    return new PDFDocument()

class WordFactory extends DocumentFactory
  createDocument() : Document
    return new WordDocument()

interface MultimediaPlayer
  + play(file)

class MP3Player
  + playMP3(file)

class MP3Adapter implements MultimediaPlayer
  private mp3Player : MP3Player

  play(file)
    mp3Player.playMP3(file)

interface Coffee
  + cost() : double

class SimpleCoffee implements Coffee
  cost() : double
    return 2.0

class WithMilk implements Coffee
  private coffee : Coffee

  cost() : double
    return coffee.cost() + 0.5

class WithSugar implements Coffee
  private coffee : Coffee

  cost() : double
    return coffee.cost() + 0.2

Coffee myCoffee = new WithMilk(new WithSugar(new SimpleCoffee()))
// cost = 2.0 + 0.2 + 0.5 = 2.7

interface Observer
  + update(subject)

class Subject
  private observers : List<Observer>

  + attach(observer)
    observers.add(observer)

  + notify()
    for each observer in observers
      observer.update(this)

class TemperatureDisplay implements Observer
  update(subject)
    temperature = subject.getTemperature()
    display(temperature)

interface FineCalculationStrategy
  + calculate(daysOverdue) : double

class StandardFine implements FineCalculationStrategy
  calculate(daysOverdue) : double
    return daysOverdue * 0.5

class StudentFine implements FineCalculationStrategy
  calculate(daysOverdue) : double
    return daysOverdue * 0.2

class LoanManager
  private strategy : FineCalculationStrategy

  setStrategy(strategy)
    this.strategy = strategy

  calculateFine(daysOverdue)
    return strategy.calculate(daysOverdue)