Guide complet sur les diagrammes de classes UML (Diagramme en tant que code)

💡 Note: Tous les diagrammes sont fournis en format PlantUML format. Vous pouvez les rendre instantanément en utilisant Visual Paradigm Diagramme en tant que code.

🔹 Introduction à UML

Qu’est-ce que UML ?

« Le langage de modélisation unifié (UML) est un langage de modélisation visuelle généraliste utilisé pour spécifier, visualiser, construire et documenter les artefacts d’un système logiciel. » — Rumbaugh et al., 1999

Caractéristiques principales :

• 🎨 Notation visuelle: Syntaxe graphique pour modéliser les systèmes

• 📐 Standardisé: Standard adopté par l’OMG depuis 1997

• 🔧 Langage, pas une méthode: Définit la notation, pas le processus

• 🌐 Large portée: Modélise les processus métiers, les fonctions système, les structures de code et les schémas de base de données

Ce que UML N’EST PAS

🔹 Histoire et normalisation

Chronologie de l’évolution

1965-1970 : Simula-67 (premier langage orienté objet)
     ↓
Années 1970-1980 : Smalltalk au Xerox PARC
     ↓
1984 : C++ introduit par Bjarne Stroustrup
     ↓
1988-1992 : Prolifération des méthodes orientées objet (Booch, OMT, OOSE, etc.)
     ↓
1994 : Rumbaugh rejoint Booch chez Rational → Début de l'unification
     ↓
1995 : Version préliminaire UML 0.8 publiée
     ↓
1996 : OMG publie un appel d'offres pour un langage de modélisation standard
     ↓
1997 : UML 1.1 adopté par l'OMG (14 novembre)
     ↓
2000 : UML 1.3 publié officiellement
     ↓
2003 : UML 1.5 publié ; structure supérieure UML 2.0 acceptée

Pourquoi UML a remporté la « guerre des méthodes »

• A consolidé plus de 50 méthodes orientées objet concurrentes en une seule norme

• Appuyé par les principaux acteurs de l’industrie (IBM, Microsoft, Oracle, HP)

• A fourni des mécanismes d’extension pour la personnalisation

• Est devenu la norme de facto pour la modélisation orientée objet

⚠️ Point de vue critique: Certains affirment que UML est « un langage monstrueux conçu par un comité » avec des sémantiques imprécises dans ses premières versions.

🔹 Classes et attributs

Structure de la classe

Une classe UML est représentée par un rectangle comportant jusqu’à trois compartiments.

@startuml
class Student {
  firstName: String
  lastName: String
  email[0..1]: String
  encryptedPW: String
  + totalPoints(): Integer
  + setPassword(pw: String)
  + checkPW(pw: String): Boolean
}
@enduml

Syntaxe de déclaration d’attribut

[visibilité] nom[multiplicité]: Type [= valeurParDéfaut] {propriétés}

Exemples PlantUML :

@startuml
class Student {
  + ProgramOfStudy[0..2]: String = "MIS"
  - encryptedPW: String {frozen}
  # internalID: Integer
  ~ packagePrivateData: String
}
@enduml

Portée des attributs

• Portée d’instance (par défaut) : Chaque objet a sa propre valeur

• Portée de classe (statique) : Valeur unique partagée par toutes les instances

@startuml
class Student {
  name: String
  {static} count: Integer
}
@enduml

Clés en UML ⚠️

Limite importante: UML n’a pas de notion intégrée de clés. Utilisez des stéréotypes ou des valeurs étiquetées comme contournements.

@startuml
class Student {
  {pk} id: Integer
  {ak1} email: String
  - name: String
}
@enduml

🔹 Associations et relations

Association de base et multiplicité

@startuml
class Exercise
class Chapter
Exercise "0..*" -- "1..1" Chapter : Appartient à
@enduml

Interprétation: Chaque exercice appartient à un seul chapitre ; un chapitre peut contenir zéro ou plusieurs exercices.

Noms de rôle

Au lieu (ou en complément) des noms d’association, utilisez des noms de rôle aux extrémités des associations :

@startuml
class Person
class Company
Person "0..*" --> "0..1" Company : Employé/Employeur
@enduml

Implémentation: Le Personne table aurait une clé étrangère employeur référençant Société.

Navigabilité

Spécifiez la direction du parcours avec des flèches :

@startuml
class Exercice
class Chapitre
Exercice "0..*" --> "1" Chapitre
@enduml

• La flèche indique la direction de parcours efficace

• Dans les OODBs : implémenté comme pointeur dans une seule direction

• Dans les RDBMS : les jointures fonctionnent dans les deux sens indépendamment

Types de collection avec {ordonné}


@startuml
class Chapitre
class Exercice
Chapitre "1" -- "0..*" Exercice : {ordonné}
@enduml

• {ordonné}: Maintenir l’ordre (utiliser une liste, pas un ensemble)

• Implémentation dans les RDBMS : ajouter un attribut de numéro de séquence

EXERCICES (
    id PRIMARY KEY,
    chapter_id REFERENCES CHAPITRES,
    sort_no INTEGER,
    UNIQUE (chapter_id, sort_no)
)

Qualificateurs

Les qualificateurs partitionnent les objets liés à l’aide d’un mécanisme similaire à une clé :

@startuml
class Chapitre
class Exercice
Chapitre "1" --> "0..1" Exercice : <<qualificateur>> no: Entier
@enduml

Signification: Étant donné un chapitre et un numéro d’exercice, au plus un Exercice est retourné.

Classes d’association

Lorsqu’une association possède des attributs ou des opérations :

@startuml
class Étudiant
class Exercice
class Solution {
  date: Date
  points: Entier
}
Étudiant "0..*" -- "0..*" Exercice : a résolu
Solution .. Étudiant
Solution .. Exercice
@enduml

• Un Solution objet par paire (Étudiant, Exercice)

• Imposé : un même étudiant ne peut pas soumettre deux solutions pour le même exercice

Composition vs. Agrégation

@startuml
class Chapitre
class Exercice
Chapitre *-- "0..*" Exercice : Composition
Chapitre o-- "0..*" Exercice : Agrégation
@enduml

🔹 Opérations et méthodes

Syntaxe de déclaration d’opération

@startuml
class Calculatrice {
  + getTotal(idEtudiant: Integer, inclExtra: Boolean = true): Float {isQuery=true}
  + {static} getInstance(): Calculatrice
  + {constructeur} Calculatrice(valeurInitiale: Float)
  - recalculate(): void
}
@enduml

Spécification des paramètres:

[direction] nom: Type [= valeurParDéfaut]

• Directions : en (par défaut), sortie, en sortie

• Les valeurs par défaut permettent des paramètres facultatifs

Stéréotypes d’opération spéciaux

Opérations dans le contexte de la base de données

Le conflit culturel: OO met l’accent sur l’encapsulation ; le modèle relationnel met l’accent sur l’accès direct aux données.

Stratégies d’implémentation:

🔹 Généralisation et héritage

Généralisation basique

@startuml
class Personne
class Etudiant
class Professeur
Personne <|-- Etudiant
Personne <|-- Professeur
@enduml

Classes abstraites et opérations

@startuml
classe abstraite Compte {
  - solde : Flottant
  + depot(montant : Flottant) : void
  + {abstrait} retirer(montant : Flottant) : void
}
@enduml

Contraintes de généralisation

@startuml
class Personne
class Etudiant
class Professeur
class AutrePersonne
Personne <|-- Etudiant : <<{disjoint, complete}>>
Personne <|-- Professeur : <<{disjoint, complete}>>
Personne <|-- AutrePersonne : <<{disjoint, complete}>>
@enduml

Classification multiple / Discriminateurs

@startuml
class Employé
class Personnel
class PersonnelFonctionnel
class HMO
class NonHMO
Employé <|-- Personnel : <<type>>
Employé <|-- PersonnelFonctionnel : <<type>>
Employé <|-- HMO : <<assurance>>
Employé <|-- NonHMO : <<assurance>>
@enduml

• Les discriminateurs regroupent des spécialisations mutuellement exclusives

• Les objets peuvent avoir une valeur par dimension de discriminateur

🔹 Mécanismes d’extension

UML fournit trois mécanismes d’extension :

1. Stéréotypes<< >>

Étendre les sémantiques UML en créant de nouveaux « sous-types » d’éléments de métamodèle.

@startuml
class Client <<entité>> {
  - id : Entier
  - nom : Chaîne
}
class BibliothèqueMath <<utilitaire>> {
  + sin(x : Flottant) : Flottant
  + cos(x : Flottant) : Flottant
}
@enduml

2. Valeurs étiquetées{clé=valeur}

Ajouter des propriétés personnalisées aux éléments du modèle.

@startuml
class Student {
  {auteur=sb, version=1.0, persistance=persistante}
  - id : Entier
}
@enduml

3. Contraintes {...}

Ajouter des restrictions sémantiques en utilisant du texte libre, de l’OCL ou des abréviations prédéfinies.

@startuml
class Exercise {
  - no : Entier
  - points : Entier {valeur >= 0}
  {points <= maxPoints}
}
@enduml

🔹 UML pour la conception de bases de données : points clés à considérer

Traduction de UML vers un schéma relationnel

Différences critiques : Orienté objet vs. Relationnel

Recommandations pratiques pour les concepteurs de bases de données

1. Modéliser explicitement les clés: Utilisez {clef primaire}, {clef étrangère1} stéréotypes car UML ne prend pas en charge nativement les clés

2. Marquer la persistance: Utilisez {persistant} valeur étiquetée pour distinguer les classes de base de données des classes d’application transitoires

3. Simplifier les opérations: Mappez les opérations de requête sur des vues ; les opérations complexes sur des procédures stockées

4. Gérer l’héritage avec précaution: Choisissez la stratégie de mappage en fonction des modèles de requête

5. Documenter les contraintes: Utilisez des contraintes OCL ou en texte clair pour les règles métier

6. Utilisez les classes d’association avec discernement: Uniquement lorsque la relation possède des attributs significatifs

🎯 Feuille de référence rapide

Résumé de la notation des diagrammes de classes PlantUML

@startuml
class <<stéréotype>> NomClasse {
  {étiqueté=valeur}
  [+/-/#/~] nom[mult]: Type [= val] {props}
  [+/-/#/~] nom(paramètres): Ret {props}
}
@enduml

Notation d’association

@startuml
ClasseA "multA" -- "multB" ClasseB : NomAssociation
ClasseA *-- ClasseB  ' Composition
ClasseA o-- ClasseB  ' Agrégation
ClasseA --> ClasseB  ' Navigable
@enduml

Symboles de visibilité

• + Public

• - Privé

• # Protégé

• ~ Paquet

Propriétés et contraintes communes

• {statique} / {estRequête=vrai} / {abstrait}

• {valeur >= 0} / {ou exclusif} / {ordonné} / {clef primaire}

💡 Réflexion finale: Les diagrammes de classes UML sont puissants pour la modélisation conceptuelle, mais rappelez-vous qu’ils ont été principalement conçus pour l’ingénierie logicielle. Lorsque vous utilisez UML pour la conception de bases de données, soyez prêt à étendre la notation (avec des stéréotypes, des valeurs étiquetées, des contraintes) afin de capturer des concepts relationnels tels que les clés, la normalisation et les contraintes déclaratives qui ne sont pas nativement présents dans la fondation orientée objet d’UML.

Guide compilé à partir de « Partie 6 : Diagrammes de classes UML » par Stefan Brass, Universität Halle, 2003. Tous les diagrammes sont formatés selon la syntaxe PlantUML pour assurer la compatibilité avec les outils modernes.