Un guide pratique de l’UML avec Visual Paradigm et VPasCode

L’UML (Unified Modeling Language) est une méthode normalisée pour décrire la structure et le comportement d’un système. Elle aide les équipes à discuter des exigences, à concevoir des logiciels et à documenter les décisions. L’UML est un langage de modélisation, et non un langage de programmation : les diagrammes communiquent un modèle, mais ils ne garantissent pas automatiquement que l’implémentation lui correspond.

Ce guide utilise un système de commerce en ligne comme exemple récurrent. Il couvre les principaux types de diagrammes UML et un flux de travail utilisant Visual Paradigm pour la modélisation visuelle et VPasCode pour les diagrammes basés sur du texte.

1. Commencez par la question que votre diagramme doit répondre

Avant de dessiner, décidez ce que le lecteur doit comprendre :

• Que peuvent faire les utilisateurs ? Utilisez un diagramme de cas d’utilisation.

• Que se passe-t-il lors d’un scénario ? Utilisez un diagramme de séquence ou d’activité.

• Quels concepts et relations composent le domaine ? Utilisez un diagramme de classes.

• Comment le logiciel est-il divisé en parties déployables ou remplaçables ? Utilisez des diagrammes de composants et de déploiement.

• Comment un objet change-t-il au fil du temps ? Utilisez un diagramme d’état.

Un diagramme qui tente de répondre à toutes les questions à la fois devient généralement difficile à lire. Préférez plusieurs diagrammes ciblés à une vue d’ensemble encombrée.

2. Familles de diagrammes UML

L’UML 2.x comprend 14 types de diagrammes standard, généralement regroupés en diagrammes structurels et comportementaux. Les diagrammes d’interaction sont un sous-ensemble des diagrammes comportementaux.

Vous avez rarement besoin des 14 diagrammes pour un projet. Pour de nombreuses conceptions d’applications, un diagramme de cas d’utilisation, de classes, de séquence, d’activité, de composants et de déploiement constitue un ensemble de départ solide.

3. Les diagrammes les plus utiles, avec un exemple de commerce électronique

Diagramme de cas d’utilisation : objectifs et limites du système

Un diagramme de cas d’utilisation décrit les objectifs de l’utilisateur, pas les mises en page d’écran ou le code interne. Pour une boutique en ligne, les acteurs peuvent inclureClient, Fournisseur de paiement, etService d’entrepôt. Les cas d’utilisation peuvent inclureParcourir les produits, Passer une commande, Payer la commande, etSuivre l’expédition.

Utilisez<<inclure>>lorsqu’un cas d’utilisation invoque toujours un autre comportement requis. Utilisez<<étendre>>pour un comportement optionnel ou conditionnel qui s’ajoute à un cas d’utilisation de base. Gardez la limite du système claire afin que les lecteurs puissent distinguer le système des acteurs externes.

Diagramme d’activité : flux de travail et décisions

Les diagrammes d’activité sont utiles pour les processus comportant des branches ou un travail parallèle. Un flux de paiement pourrait être :

1. Valider le panier et l’adresse.

2. Calculer les frais de port et la taxe.

3. Créer une commande en attente.

4. Demander une autorisation de paiement.

5. Si le paiement réussit, confirmer la commande et notifier l’exécution.

6. Si le paiement échoue, afficher l’échec et laisser la commande non confirmée.

Utilisez des nœuds de décision et de fusion pour les branches, des nœuds de fourche et de jonction pour le travail parallèle, et des couloirs de nage (swimlanes) lorsque la responsabilité change entre un client, le magasin et un fournisseur externe.

Diagramme de séquence : un scénario dans le temps

Les diagrammes de séquence montrent les participants et les messages qu’ils échangent. Ils sont particulièrement utiles pour clarifier les limites des services, l’ordre des appels et les cas d’erreur. Ajoutez des chemins alternatifs pour des résultats tels qu’un rejet de paiement ou une indisponibilité du stock.

@startuml
actor Client
participant "Boutique en ligne" as UI
participant "Service de commande" as Orders
participant "Service d'inventaire" as Inventory
participant "Fournisseur de paiement" as Payment

Client -> UI: soumettre le paiement
UI -> Orders: passerCommande(panier, adresse)
Orders -> Inventory: réserver(articles)

alt articles disponibles
    Inventory --> Orders: réservation confirmée
    Orders -> Payment: autoriser(total)
    alt paiement approuvé
        Payment --> Orders: approuvé
        Orders --> UI: commande confirmée
        UI --> Client: afficher confirmation
    else paiement refusé
        Payment --> Orders: refusé
        Orders -> Inventory: libérer réservation
        Orders --> UI: paiement échoué
        UI --> Client: afficher erreur de paiement
    end
else articles indisponibles
    Inventory --> Orders: réservation échouée
    Orders --> UI: article indisponible
    UI --> Client: afficher erreur de disponibilité
end
@enduml

Cet exemple utilise la syntaxe PlantUML. Il s’agit d’un croquis comportemental, et non d’une spécification de chaque délai d’attente, tentative de reprise ou règle de sécurité. Ajoutez ces détails lorsqu’ils sont pertinents pour la conception.

Diagramme de classes : structure du domaine

Les diagrammes de classes décrivent les types et leurs relations. Un petit modèle de commande pourrait contenir :

• Client

• Commande

• Ligne de commande

• Produit

• Paiement

Affichez les attributs et les opérations lorsqu’ils aident à expliquer les responsabilités. Utilisez les multiplicités pour rendre explicites les règles de quantité : par exemple, un Commande contient une ou plusieurs Ligne de commande objets, tandis que chaque Ligne de commande fait référence à un Produit.

Types de relations courants :

• Association : un lien structurel général.

• Héritage/généralisation : une classe est une variante spécialisée d’une autre.

• Agrégation : une relation tout–partie où les parties peuvent exister indépendamment ; à utiliser avec parcimonie.

• Composition : une relation forte tout–partie où le cycle de vie d’une partie est lié à celui du tout.

• Dépendance : un élément utilise ou dépend d’un autre.

Pour un modèle de commerce, unLigne de commande est souvent modélisé comme appartenant à unCommande, tandis qu’unProduit existe indépendamment de toute commande particulière. Choisissez la relation qui reflète le cycle de vie et les règles réels du domaine.

Diagramme de machine d’états : règles de cycle de vie

Utilisez une machine d’états lorsque les transitions autorisées d’un objet sont importantes. Une commande peut passer par :

En attente → En attente de paiement → Confirmé → Exécuté

Elle peut également passer àAnnulé ouÉchec du paiement. Étiquetez les transitions avec des événements déclencheurs ou des gardes, tels quepaiementApprouvé ou[stockAvailable]. Ce diagramme peut révéler des transitions invalides — par exemple, si une commande remplie peut être annulée.

Diagrammes de composants et de déploiement : logiciels et exécution

Un diagramme de composantsmontre les responsabilités et les dépendances logicielles, telles qu’une boutique en ligne, un service de commandes, un service d’inventaire et un adaptateur de paiement. Il est utile pour discuter de la modularité et des limites d’intégration.

Un diagramme de déploiementmontre où le logiciel s’exécute : par exemple, navigateur, environnement d’exécution de l’application, base de données et fournisseur de paiement externe. Utilisez-le pour discuter de la topologie d’exécution, et non de la configuration réseau détaillée.

4. Modéliser correctement : conventions pratiques

• Donnez à chaque diagramme un titre clair et un objectif unique.

• Utilisez le langage du domaine de manière cohérente ; évitez d’inventer différents noms pour le même concept.

• Gardez les diagrammes suffisamment petits pour être lus à leur taille prévue.

• Incluez uniquement les détails qui répondent à la question du diagramme.

• Étiquetez les associations importantes et les flux de messages.

• Ajoutez des multiplicités aux associations lorsque les règles de quantité sont importantes.

• Utilisez des notes pour les hypothèses, les contraintes et les décisions non résolues.

• Gardez les noms et les responsabilités cohérents entre les diagrammes.

• Distinguez ce qui est confirmé de ce qui est proposé ou encore inconnu.

• Mettez à jour les diagrammes lorsque des décisions de conception importantes ou des changements de comportement surviennent.

Considérez UML comme un outil de communication. Un diagramme peut être syntaxiquement valide et néanmoins trompeur si ses étiquettes, ses hypothèses ou sa portée sont floues.

5. Utilisation de Visual Paradigm

Visual Paradigm est adapté à la modélisation graphique : créez et organisez des éléments UML sur une toile, organisez les diagrammes connexes et affinez un modèle grâce à l’édition visuelle. Ses documents produits décrivent la modélisation UML parmi ses capacités de modélisation visuelle.

Un flux de travail pratique :

1. Créez un projetpour le système ou la zone délimitée que vous modélisez.

2. Commencez par les exigences et la portée.Identifiez les utilisateurs, les systèmes externes et les objectifs clés.

3. Créez un diagramme de cas d’utilisationpour établir la frontière et les interactions majeures.

4. Ajouter des diagrammes de comportement pour les scénarios qui présentent le plus de risques ou d’ambiguïtés.

5. Construire le modèle de classes autour des concepts du domaine et de leurs règles.

6. Ajouter des vues de composants et de déploiement si l’architecture ou le déploiement à l’exécution nécessite une discussion.

7. Examiner avec les parties prenantes. Vérifier les noms, la portée, les flux alternatifs et les cardinalités.

8. Exporter ou partager les diagrammes dans des formats appropriés pour les revues et la documentation.

9. Maintenir le modèle à jour. Attribuer un responsable et mettre à jour les diagrammes lorsque les décisions changent.

Les noms exacts des menus et les fonctionnalités disponibles peuvent varier selon l’édition et la version de Visual Paradigm ; utilisez donc la documentation d’interface actuelle du produit pour les étapes spécifiques à chaque édition.

6. Utilisation de VPasCode

VPasCode est un éditeur de diagrammes en tant que code basé sur le navigateur, proposé par Visual Paradigm. Ses informations produit décrivent la prise en charge de formats de diagrammes basés sur du texte, notamment PlantUML et Mermaid, avec un rendu en direct ; elles décrivent également des exports tels que SVG et PNG.

Un flux de travail simple :

1. Ouvrez VPasCode et choisissez le langage de diagramme, comme PlantUML.

2. Écrivez ou collez un script de diagramme.

3. Vérifiez l’aperçu rendu pendant que vous modifiez.

4. Affinez les noms, les relations, la mise en page et les chemins d’erreur.

5. Exportez une image pour un document ou une revue.

6. Conservez le script source avec le projet si vous souhaitez un enregistrement basé sur du texte qui peut être examiné et versionné.

VPasCode convient bien pour des ébauches rapides, des diagrammes de documentation et des équipes qui préfèrent l’édition basée sur du texte. Le modèle graphique de Visual Paradigm est utile lorsque vous souhaitez manipuler visuellement les éléments du modèle et organiser les diagrammes dans le cadre d’un projet de modélisation plus vaste. Les deux approches peuvent se compléter, mais ne supposez pas que chaque diagramme ou modèle se transfère entre eux avec une fidélité parfaite aller-retour ; validez toute conversion dans votre flux de travail.

7. Un flux de travail utile de bout en bout

Pour une fonctionnalité de paiement, une séquence de modélisation légère pourrait être :

1. Cas d’utilisation : Définir qui peut passer une commande et quels systèmes externes participent.

2. Activité : Cartographier le flux de paiement et ses décisions.

3. Séquence : détaillez les interactions pour les chemins de succès, d’échec du paiement et de stock indisponible.

4. Classe : définissez les concepts de commande, d’article de commande, de produit et de paiement ainsi que leurs règles.

5. Machine à états : spécifiez le cycle de vie valide de la commande.

6. Composant : montrez quels services assument ces responsabilités.

7. Déploiement : documentez le déploiement à l’exécution si les décisions d’infrastructure sont pertinentes.

Utilisez Visual Paradigm lorsque l’équipe bénéficie d’une modélisation basée sur une toile et d’un modèle visuel géré. Utilisez VPasCode lorsque l’équipe souhaite écrire et afficher rapidement le texte des diagrammes. Une approche courante consiste à rédiger un scénario dans VPasCode, à le revoir et à l’affiner avec l’équipe, puis à maintenir les diagrammes dans le format qui convient le mieux à la documentation du projet et à son processus de changement.

8. Pièges courants

• Tenter de diagrammer l’ensemble du système d’un coup : divisez par préoccupation ou par scénario.

• Confondre les activités avec les séquences : les activités mettent l’accent sur le flux de travail ; les séquences mettent l’accent sur les messages dans le temps.

• Surcharger les diagrammes de classes : concentrez-vous sur les concepts pertinents du domaine, pas sur chaque détail d’implémentation.

• Utiliserinclure etétendre comme décoration : ils expriment des relations spécifiques entre les cas d’utilisation.

• Omettre les chemins alternatifs : les échecs et les annulations révèlent souvent des exigences importantes.

• Considérer le diagramme comme la spécification : documentez explicitement les règles métier importantes, les hypothèses et les contraintes.

• Laisser les diagrammes devenir obsolètes : un diagramme obsolète peut être pire qu’aucun diagramme, car les lecteurs peuvent lui faire confiance.

Un ensemble UML solide n’est pas le plus grand ensemble. C’est le plus petit ensemble de diagrammes permettant aux lecteurs visés de comprendre le système, de discuter des décisions et de repérer les lacunes avant qu’elles ne deviennent coûteuses.

Cette publication est également disponible en Deutsch, English, Español, فارسی, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 : liste des langues séparées par une virgule, 繁體中文 : dernière langue.