\n
![\"Fiche](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195e127973c.png\")
<\/p>\n
Partie 1 : Les \u00e9l\u00e9ments de base (syntaxe et l\u00e9gende)<\/h2>\n
Avant de plonger dans l’\u00e9tude de cas, nous devons \u00e9tablir le vocabulaire utilis\u00e9 dans les diagrammes UML.<\/p>\n
1. Structure de classe et visibilit\u00e9<\/h3>\n
Une classe est repr\u00e9sent\u00e9e par un rectangle divis\u00e9 en trois compartiments :<\/p>\n
- \n
- \n
Haut :<\/strong> Nom de la classe (par exemple,
FlightBooking<\/code>).<\/p>\n<\/li>\n- \n
Milieu :<\/strong> Propri\u00e9t\u00e9s\/attributs (par exemple,
+ nameProperty : String<\/code>).<\/p>\n<\/li>\n- \n
Bas :<\/strong> M\u00e9thodes\/op\u00e9rations (par exemple,
+ isActive() : boolean<\/code>).<\/p>\n<\/li>\n<\/ul>\nModificateurs de visibilit\u00e9 :<\/strong><\/p>\n
- \n
- \n
+<\/code>\u00a0Public :<\/strong> Accessible par n’importe quelle autre classe.<\/p>\n<\/li>\n- \n
-<\/code>\u00a0Priv\u00e9 :<\/strong> Accessible uniquement au sein de la classe.<\/p>\n<\/li>\n- \n
#<\/code>\u00a0Prot\u00e9g\u00e9 :<\/strong>\u00a0Accessible au sein de la classe et de ses sous-classes.<\/p>\n<\/li>\n- \n
~<\/code>\u00a0Paquetage :<\/strong>\u00a0Accessible uniquement au sein du m\u00eame paquetage.<\/p>\n<\/li>\n<\/ul>\n2. Types de classes sp\u00e9ciaux<\/h3>\n
- \n
- \n
Interfaces (
<<interface>><\/code>):<\/strong>\u00a0Contrats d\u00e9finissant des m\u00e9thodes sans impl\u00e9mentation. Repr\u00e9sent\u00e9s par une bo\u00eete verte (dans cette fiche) ou une notation standard.<\/p>\n- \n
- \n
Exemple :<\/em>\u00a0
UserRepo<\/code>\u00a0avec\u00a0+ method(): void<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Classes abstraites (
<<abstract>><\/code>):<\/strong>\u00a0Classes de base qui ne peuvent pas \u00eatre instanci\u00e9es directement. Elles peuvent contenir des m\u00e9thodes abstraites.<\/p>\n- \n
- \n
Exemple :<\/em>\u00a0
Component<\/code>\u00a0avec\u00a0+ render(): void \/\/ abstract<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
\u00c9num\u00e9rations :<\/strong>\u00a0Un ensemble de constantes nomm\u00e9es.<\/p>\n
- \n
- \n
Exemple :<\/em>\u00a0
JobStatus<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nExemple de diagramme de classes du syst\u00e8me de commandes<\/h2>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195f79a1fa7.png\")
<\/p>\n\u00a0<\/p>\n
@startuml
\nskinparam classAttributeIconSize 0
\nskinparam shadowing false<\/p>\n\u2018 \u2014 INTERFACES \u2014
\ninterface PasserelleDePaiement {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 CLASSES ABSTRAITES \u2014
\nclasse abstraite Commande {
\n# orderId: String
\n# totalAmount: double
\n+ {abstract} calculateTax(): double
\n+ getSummary(): String
\n}<\/p>\n\u2018 \u2014 CLASSES \u2014
\nclass CommandePhysique {
\n\u2013 shippingWeight: double
\n+ calculateTax(): double
\n}<\/p>\nclass CommandeNum\u00e9rique {
\n\u2013 downloadLink: String
\n+ calculateTax(): double
\n}<\/p>\nclass ArticleDeCommande {
\n\u2013 productName: String
\n\u2013 price: double
\n\u2013 quantity: int
\n}<\/p>\nclass PasserellePayPal {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 RELATIONS \u2014’
\nOrder <|\u2013 CommandePhysique
\nOrder <|\u2013 CommandeNum\u00e9rique<\/p>\nOrder *\u2013 \u00ab 1..* \u00bb OrderItem : contient
\nOrder ..> PasserellePaiement : utilise<\/p>\nPasserellePaiement <|.. PasserellePayPal<\/p>\n
@enduml<\/p>\n
\nPartie 2 : Relations et Multiplicit\u00e9<\/h2>\n
Les lignes reliant les classes d\u00e9finissent la mani\u00e8re dont elles interagissent.<\/p>\n
1. Types d’association<\/h3>\n
- \n
- \n
H\u00e9ritage (G\u00e9n\u00e9ralisation) :<\/strong>Ligne pleine avec un triangle creux. Relation \u00ab est-un \u00bb.<\/p>\n
- \n
- \n
Exemple :<\/em>\u00a0
Voiture<\/code>\u00a0et\u00a0Moto<\/code>h\u00e9ritent de\u00a0V\u00e9hicule<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Impl\u00e9mentation :<\/strong>Ligne pointill\u00e9e avec un triangle creux. Une classe remplit un contrat d’interface.<\/p>\n
- \n
- \n
Exemple :<\/em>\u00a0
Voiture<\/code>impl\u00e9mente\u00a0Conductible<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Composition (Propri\u00e9t\u00e9 forte) :<\/strong>Ligne pleine avec un\u00a0losange plein<\/strong>. La \u00ab partie \u00bb ne peut pas exister sans le \u00ab tout \u00bb.<\/p>\n
- \n
- \n
Exemple :<\/em>\u00a0
Restaurant<\/code> (Tout) poss\u00e8deMenu<\/code> (Partie). Si le restaurant ferme, le menu dispara\u00eet.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Agr\u00e9gation :<\/strong> Ligne pleine avec un losange creux<\/strong>. Une relation \u00ab avoir-un \u00bb o\u00f9 les parties peuvent exister ind\u00e9pendamment.<\/p>\n
- \n
- \n
Exemple :<\/em>\u00a0
Commande<\/code> agr\u00e8geRestaurant<\/code> (Le restaurant existe m\u00eame si la commande est supprim\u00e9e).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. L\u00e9gende de la multiplicit\u00e9<\/h3>\n
Les nombres aux extr\u00e9mit\u00e9s des lignes indiquent la cardinalit\u00e9 :<\/p>\n
- \n
- \n
1<\/code>: Exactement un.<\/p>\n<\/li>\n- \n
0..1<\/code>: Z\u00e9ro ou un (Optionnel).<\/p>\n<\/li>\n- \n
1..*<\/code>: Un ou plusieurs (Liste obligatoire).<\/p>\n<\/li>\n- \n
*<\/code>: Plusieurs (Z\u00e9ro ou plus).<\/p>\n<\/li>\n<\/ul>\nLes concepts d’h\u00e9ritage, d’impl\u00e9mentation, de composition et d’agr\u00e9gation Exemple<\/h3>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a19600180d6b.png\")
<\/p>\n\n@startuml<\/div>\n\u00ab Interfaces et classes de base<\/div>\ninterface Drivable {<\/div>\n+ drive()<\/div>\n}<\/div>\nclasse abstraite Vehicle {<\/div>\n+ startEngine()<\/div>\n}<\/div>\n\u2018 Classes<\/div>\nclass Voiture {<\/div>\n}<\/div>\nclass Moto {<\/div>\n}<\/div>\nclass Restaurant {<\/div>\n\u2013 name: String<\/div>\n}<\/div>\nclass Menu {<\/div>\n}<\/div>\nclass Commande {<\/div>\n}<\/div>\n\u2018 Relations<\/div>\n\u2018 1. H\u00e9ritage (G\u00e9n\u00e9ralisation)<\/div>\nVehicle <|\u2013 Voiture<\/div>\nVehicle <|\u2013 Moto<\/div>\n\u2018 2. Impl\u00e9mentation<\/div>\nDrivable <|.. Voiture<\/div>\n\u2018 3. Composition (Propri\u00e9t\u00e9 forte)<\/div>\nRestaurant *\u2013 Menu : poss\u00e8de<\/div>\n\u2018 4. Agr\u00e9gation<\/div>\nCommande o\u2013 Restaurant : implique<\/div>\n\u2018 Exemples de multiplicit\u00e9<\/div>\n\u2018 Un Restaurant a un ou plusieurs Menus (1..*)<\/div>\n\u2018 Une Commande implique z\u00e9ro ou un Restaurant (0..1)<\/div>\nRestaurant \u201c1\u201d *\u2013 \u201c1..*\u201d Menu<\/div>\nCommande \u00ab 1 \u00bb ou \u00ab 0..1 \u00bb Restaurant<\/div>\n@enduml<\/div>\n<\/div>\n
\nPartie 3 : \u00c9tude de cas en situation r\u00e9elle : Plateforme unifi\u00e9e de livraison de repas<\/h2>\n
Cette section analyse le diagramme central de la fiche de trucs, en d\u00e9composant l’architecture d’une application de livraison de repas.<\/p>\n
1. La hi\u00e9rarchie des utilisateurs (H\u00e9ritage et composition)<\/h3>\n
Le syst\u00e8me commence par une classe g\u00e9n\u00e9rique Utilisateur<\/strong> \u00bb, marqu\u00e9e comme Abstraite<\/strong>. Cela garantit qu’aucun objet \u00ab Utilisateur \u00bb g\u00e9n\u00e9rique n’est cr\u00e9\u00e9, seuls des types sp\u00e9cifiques sont instanci\u00e9s.<\/p>\n
- \n
- \n
H\u00e9ritage :<\/strong>\u00a0
Client<\/code> etLivreur<\/code> h\u00e9ritent deUtilisateur<\/code>.<\/p>\n<\/li>\n- \n
Composition :<\/strong><\/p>\n
- \n
- \n
Client<\/code> poss\u00e8de unAdresse de livraison<\/code> (Propri\u00e9t\u00e9 forte).<\/p>\n<\/li>\n- \n
Livreur<\/code> poss\u00e8deD\u00e9tails du v\u00e9hicule<\/code> (Propri\u00e9t\u00e9 forte).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. L’\u00e9cosyst\u00e8me du restaurant et du menu<\/h3>\n
Cette section illustre une imbrication profonde et des collections.<\/p>\n
- \n
- \n
Impl\u00e9mentation d’interface :<\/strong>\u00a0
Restaurant<\/code> impl\u00e9mente<<interface>> Localisable<\/code>, garantissant que chaque restaurant dispose de donn\u00e9es de localisation.<\/p>\n<\/li>\n- \n
Cha\u00eene de composition :<\/strong><\/p>\n
- \n
- \n
Restaurant<\/code> (1) poss\u00e8de fortementMenu<\/code>\u00a0(1).<\/p>\n<\/li>\n- \n
Menu<\/code> contientCat\u00e9gorie de menu<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Cat\u00e9gorie de menu<\/code> contientArticle de menu<\/code>\u00a0(*).<\/p>\n<\/li>\n- \n
Note :<\/em> Cette structure impose qu’un article de menu ne peut exister sans cat\u00e9gorie, qui ne peut exister sans menu.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
3. Traitement des commandes et paiements<\/h3>\n
- \n
- \n
Structure de commande :<\/strong><\/p>\n
- \n
- \n
Commande<\/code> a une relation avecRestaurant<\/code> (agr\u00e9gation).<\/p>\n<\/li>\n- \n
Commande<\/code> poss\u00e8de fortementArticle de ligne de commande<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Commande<\/code> a unPaiement<\/code> (0..1), indiquant que le paiement est facultatif lors de la phase de cr\u00e9ation initiale.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Strat\u00e9gie de paiement (Polymorphisme) :<\/strong><\/p>\n
- \n
- \n
Le syst\u00e8me utilise une interface
<<interface>> PaymentProcessor<\/code>.<\/p>\n<\/li>\n- \n
Classes concr\u00e8tes
StripeProcessor<\/code> etPayPalProcessor<\/code> impl\u00e9mentent cette interface. Cela permet au syst\u00e8me de changer de passerelle de paiement sans modifier le c\u0153urCommande<\/code> logique.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n4. Classe abstraite vs. Interface (L’exemple du v\u00e9hicule)<\/h3>\n
Le coin sup\u00e9rieur droit de la feuille de triche clarifie une confusion courante :<\/p>\n
- \n
- \n
Classe abstraite (
V\u00e9hicule<\/code>):<\/strong>\u00a0Voiture<\/code> etMoto<\/code> h\u00e9ritent deV\u00e9hicule<\/code>. Cela implique qu’ils partagent des donn\u00e9es\/structures de base (par exemple,typeMoteur<\/code>,\u00a0roues<\/code>).<\/p>\n<\/li>\n- \n
Interface (
Conductible<\/code>):<\/strong>\u00a0Voiture<\/code> impl\u00e9menteConductible<\/code>. Cela impliqueVoiture<\/code> a un comportement sp\u00e9cifique (conduire()<\/code>) queMoto<\/code> pourrait ne pas avoir (ou pourrait l’impl\u00e9menter diff\u00e9remment).<\/p>\n<\/li>\n<\/ul>\n
\nPartie 4 : Visualisation avec PlantUML<\/h2>\n
Voici le code PlantUML pour g\u00e9n\u00e9rer la structure de base de la \u00ab Plateforme Unifi\u00e9e de Livraison de Nourriture \u00bb d\u00e9crite dans l’\u00e9tude de cas. Vous pouvez copier ce code dans n’importe quel \u00e9diteur PlantUML pour voir le diagramme.<\/p>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195d5d056af.png\")
<\/p>\n\n\nPlantUML<\/span> - \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n