Posted inAI AI Chatbot UML

Un guide complet pour créer un diagramme de déploiement UML pour le système simple de commande de nourriture en ligne

1. Objectif d’un diagramme de déploiement UML

Un diagramme de déploiement montre l’architecture physique/à l’exécution d’un système :

  • Nœuds matériels (serveurs, périphériques, instances cloud)
  • Artifacts logiciels déployés sur ces nœuds
  • Environnements d’exécution (conteneurs, runtimes)
  • Chemins de communication entre les nœuds (protocoles, connexions)

Pour un système simple de commande de nourriture en ligne, il visualise comment :

  • Les interfaces web des clients et des restaurants sont servies
  • La logique métier s’exécute
  • Les données sont stockées
  • Les services externes (paiement, notifications) sont intégrés

Il aide les développeurs, les équipes DevOps et les parties prenantes à comprendretopologie de déploiement, les points d’évolutivité, les frontières de sécurité et les dépendances.

2. Éléments UML clés dans les diagrammes de déploiement

Élément Notation UML (PlantUML) Signification / Quand l’utiliser Exemples de stéréotypes
Nœud node « Nom » Ressource computationnelle (physique ou virtuelle) pouvant héberger des artefacts <<device>>, <<cloud>>
Périphérique nœud « Nom » <<périphérique>> Matériel physique ou virtuel (serveur, mobile, routeur) <<périphérique>>, <<serveur>>
Environnement d’exécution nœud « Nom » <<environnement d’exécution>> Environnement d’exécution logiciel/container (Tomcat, Node.js, Docker, JVM) <<environnement d’exécution>>, <<conteneur>>
Artéfact artefact « filename.war » Unité déployable (exécutable, .jar, bundle .js, schéma de base de données, fichier de configuration) <<exécutable>>, <<fichier>>, <<base de données>>
Composant composant « Nom » Unité logicielle (facultatif dans les diagrammes de déploiement ; souvent réalisée par des artefacts) <<web>>, <<service>>
Chemin de communication –, –>, ..> Connexion réseau entre nœuds (peut avoir une étiquette de protocole) HTTP/HTTPS, WebSocket, RMI
Dépendance / Appel ..>, –> Utilisation/dépendance (par exemple, frontend appelle backend) <<appelle>>, <<accède>>
Manifestation / Réalisation ..> avec <<réalise>> ou ..> Artéfact réalise / est déployé en tant que composant <<réalise>>, <<manifeste>>
Système externe nœud « Nom » <<externe>> Service tierce partie en dehors de votre contrôle <<externe>>, <<SaaS>>

3. Meilleures pratiques pour les diagrammes de déploiement (en particulier pour les systèmes web)

  • Gardez-le simple et lisible — évitez le surpeuplement ; un diagramme par environnement majeur (dev/staging/prod facultatif)
  • Utilisez des groupements significatifs groupement de nœuds (imbriquez des nœuds à l’intérieur de nœuds) pour montrer les clusters/régions cloud
  • Préférez notations concises — affichez les noms de fichiers/configurations uniquement lorsqu’ils sont pertinents ; ignorez les stéréotypes redondants
  • Montrez clairement frontières — cloud interne vs services externes
  • Étiquetez protocoles sur les chemins (HTTP/HTTPS, WebSocket, TCP, etc.)
  • Utilisez direction de gauche à droite pour les systèmes web (le flux client → serveur → base de données semble naturel)
  • Différenciez appareil (matériel) vs environnement d’exécution (runtime)
  • Montrez réalisation uniquement lorsqu’elle apporte de la valeur (artefact → composant)
  • Utilisez skinparam dans PlantUML pour de meilleures couleurs/lisibilité
  • Pour les systèmes petits/moyens : 4 à 8 nœuds maximum

4. Structure recommandée pour un système simple de commande de nourriture en ligne

Un agencement propre et moderne pour ce système :

  • Côté client → Navigateur (implicite) communique avec Serveur web/CDN
  • Serveur web/CDN héberge les artefacts statiques + SPA pour le site client et le panneau restaurant
  • Serveur API (environnement d’exécution) exécute la logique du backend
  • Serveur de base de données héberge PostgreSQL
  • Externe Services de paiement et de notification

Nœuds typiques :

  1. Serveur web / CDN <<device>>
  2. Serveur API <<environment d’exécution>>
  3. Serveur de base de données <<environment d’exécution>>
  4. Passerelle de paiement <<externe>>
  5. Service de notification <<externe>>

5. Diagramme généré par le chatbot AI de Visual Paradigm

Code PlantUML amélioré et nettoyé (avec explications)

Plantuml


Modifier Plantuml dans VPasCode
Plantuml Edit Plantuml in VPasCode 
@startuml

title Système simple de commande de nourriture en ligne - Diagramme de déploiement

direction de gauche à droite

skinparam {
CouleurFleche #424242
CouleurPoliceFleche #424242
TaillePoliceParDefaut 14
ombrage false
CouleurFondStéréotypeC #ADD1B2
CouleurFondStéréotypeI #ADD1B2
}

' ── Nœuds ────────────────────────────────────────────────

nœud "Serveur web / CDN" <<device>> comme WebServer {
[Site client HTML/JS/CSS] #..# (SPA client)
[Panels administrateur restaurant HTML/JS/CSS] #..# (SPA restaurant)
}

nœud "Cloud Backend" <<device>> comme Cloud {
nœud "Serveur API" <<environment d'exécution>> comme APIServer {
artefact "backend-api.jar / main.exe" comme BackendArtifact
}

nœud "Serveur PostgreSQL" <<environment d'exécution>> comme DBServer {
database "Base de données PostgreSQL" comme Postgres <<base de données>>
}
}

nœud "Passerelle de paiement" <<externe>> comme Payment {
[API de paiement] comme PaymentAPI
}

nœud "Service de notification" <<externe>> comme Notification {
[WebSocket / API Push] comme NotifyAPI
}

' ── Relations ─────────────────────────────────────────

WebServer --> Cloud : HTTPS (appels API)

Cloud --> Payment : HTTPS (paiement)

Cloud --> Notification : WebSocket / HTTPS (mises à jour d'état)

' Artefact → réalisation du composant (facultatif mais clair)
(SPA client) ..> BackendArtifact : <<appelle>>
(SPA restaurant) ..> BackendArtifact : <<appelle>>

BackendArtifact --> Postgres : <<JDBC / SQL>>

BackendArtifact --> PaymentAPI : <<appels HTTPS>>

BackendArtifact --> NotifyAPI : <<WebSocket / HTTPS>>

' Optionnel : afficher le protocole sur la base de données si souhaité
' BackendArtifact -droite-> Postgres : <<JDBC>>

note à droite de Cloud
Configuration typique pour petit/moyen système :
• Machine virtuelle unique ou petit cluster
• API + base de données peuvent être sur la même machine (pour simplifier)
ou séparés pour une meilleure évolutivité
fin note

@enduml
Edit Plantuml in VPasCode



Modifier Plantuml dans VPasCode

6. Étapes par étapes : Comment créer votre propre diagramme de déploiement

  1. Lister tous les cibles d’exécution(serveurs, conteneurs, services externes)
  2. Liste des artefacts déployables (ce qui s’exécute réellement : paquet .js, .jar, base de données)
  3. Regrouper en nœuds (imbriquer quand logique — par exemple : API + base de données dans un même nœud cloud)
  4. Déterminer la direction (de gauche à droite fonctionne bien pour web → API → base de données)
  5. Ajouter les chemins de communication avec des étiquettes de protocole
  6. Ajouter les dépendances clés (<<appelle>>, <<accède>>)
  7. Appliquer skinparam pour les couleurs/lisibilité
  8. Ajouter des notes pour les décisions importantes (instance unique vs multiple, notes d’évolutivité)
  9. Valider: Un ingénieur DevOps peut-il comprendre où déployer chaque composant ?

Résumé – Référence rapide pour le déploiement simple de commande de nourriture

Partie Type de nœud typique Exemple d’artefact Se connecte via
Interface client Serveur web / CDN <<device>> Paquet SPA (HTML/JS) HTTPS → API
Tableau de bord du restaurant Serveur web / CDN <<device>> Paquet SPA administrateur HTTPS → API
Logique métier Serveur API <<executionEnv>> backend-api.jar / exécutable JDBC → BD, HTTPS → externe
Stockage des données PostgreSQL <<executionEnv>> Fichiers de données PostgreSQL + schéma —
Paiements Externe <<SaaS>> Point de terminaison de l’API de paiement HTTPS
Mises à jour en temps réel Externe <<SaaS>> WebSocket / FCM / APNs WebSocket / HTTPS

Cette structure est réaliste pour les déploiements MVP ou à petite à moyenne échelle (1 à 3 serveurs + base de données cloud + Stripe/PayPal + Firebase/Pusher).

N’hésitez pas à ajuster le niveau d’imbrication, les protocoles ou à ajouter des notes d’évolutivité (par exemple, équilibreur de charge, réplicas) lorsque le système grandit.

🔗 Liste de références