Page 4 sur 8. Passer des règles générales à des instantanés concrets et vérifier les cardinalités.
1. Une photographie du système à un instant donné
Le diagramme de classes décrit ce qui peut exister. Le diagramme d’objets montre une configuration particulière : tel client, telle demande et telles versions de devis, à un instant choisi. Il est utile pour expliquer une multiplicité, discuter un cas limite ou construire des données de test.
L’en-tête d’un objet est souligné et suit la forme nomObjet : Classe. L’écriture : Client représente une instance anonyme de Client ; clientA : Client donne aussi un nom local à cette instance. Le nom local du dessin n’est pas nécessairement son identifiant dans l’application.
Les compartiments contiennent des valeurs de propriétés, appelées slots. On écrit par exemple reference = "D-018", et non une nouvelle déclaration reference : String. Un lien entre objets illustre une association entre leurs classes.
2. Lire l’exemple NKILItech
Le client Atelier Sawa possède la demande DEM-042, dont l’objet est la maintenance d’un portail. Deux devis sont liés à cette demande : D-018-V1 est refusé ; D-018-V2 est envoyé. Le dessin respecte R1 puisqu’un seul client est lié à la demande, et R2 puisqu’aucun devis n’est encore accepté.
Après acceptation de V2, le même objet peut présenter le statut accepté. Il n’est pas nécessaire de créer un nouveau devis pour chaque changement de statut. En revanche, créer une nouvelle version commerciale peut justifier un nouvel objet Devis avec sa propre référence et son historique.
La figure est volontairement partielle : elle ne présente pas les lignes de devis. Un diagramme d’objets peut masquer certaines propriétés pour faciliter la lecture. Cette omission visuelle n’annule pas l’obligation métier d’avoir des lignes dans les objets réellement enregistrés.
3. Calculer sur des instances
Considérons le devis V2 avec deux lignes : audit, quantité 2 à 75 000 FCFA ; correction, quantité 3 à 100 000 FCFA. En supposant dans cet exercice des montants hors taxes et sans remise, les sous-totaux valent 150 000 et 300 000 FCFA. Le total calculé est donc de 450 000 FCFA.
Cette configuration vérifie plusieurs décisions : le devis contient au moins une ligne, chaque ligne appartient à un seul devis, les quantités sont positives et le total découle des lignes. La devise doit rester identique pour les montants additionnés, ou une règle de conversion doit être explicitée.
Le modèle de classes ne fixe pas combien de lignes possède chaque devis particulier ; il fixe l’ensemble des quantités autorisées. Une instance à deux lignes est un exemple valide de 1..*, mais elle ne prouve pas que tous les objets futurs seront valides.
4. Configurations valides et contre-exemples
| Configuration | Verdict | Justification |
|---|---|---|
| Un client sans demande | Valide | 0..* autorise zéro demande. |
| Une demande sans devis | Valide | Le besoin peut être encore à qualifier. |
| Une demande sans client | Invalide | R1 impose un propriétaire. |
| Deux devis acceptés pour DEM-042 | Invalide | R2 limite l’acceptation à une version. |
| Une ligne partagée entre deux devis | Invalide dans ce modèle | La composition impose un propriétaire composite unique. |
Un contre-exemple aide à découvrir une contrainte absente. Si les seules multiplicités permettent deux devis acceptés, il faut compléter le modèle par R2 et imposer cette règle dans les opérations concernées. Changer 0..* en 0..1 supprimerait à tort l’historique des versions.
5. De l’instantané au scénario
Un diagramme d’objets ne montre pas l’ordre des messages. Pour comprendre comment V2 passe d’envoyé à accepté, il faut un diagramme de séquence. Pour savoir si cette transition est autorisée, il faut examiner son cycle de vie. Ces vues utilisent les mêmes objets mais répondent à des questions différentes.
- Choisir un instant avant l’opération.
- Donner aux objets les valeurs nécessaires au scénario.
- Exécuter mentalement les vérifications et le changement.
- Dessiner l’instant après l’opération.
- Comparer les deux instantanés aux invariants du modèle.
Pour une deuxième confirmation identique, l’état final doit rester accepté et le nombre d’acceptations ne doit pas augmenter. Cette propriété d’idempotence constitue une cible de test précise, indépendante de la disposition des écrans.
Scénarios illustrés : comparer les situations
Comparer les valeurs avant et après le succès
Le devis change de statut sans changer d’identité. La date d’accord apparaît après validation. Un second appel identique doit retrouver ce résultat ; il ne doit pas créer une deuxième instance pour représenter le même accord.
Exercices corrigés
Exercice 1 - Calculer le total
Construire les valeurs d’un devis avec 4 heures à 25 000 FCFA et un forfait à 80 000 FCFA, hors taxes et sans remise.
Voir le corrigé détaillé
Créer un objet Devis et deux objets LigneDevis reliés par composition. Les sous-totaux sont 100 000 et 80 000 FCFA ; le total dérivé est 180 000 FCFA. Chaque ligne a un seul propriétaire.
Exercice 2 - Repérer une instance interdite
Une demande possède V1 accepté et V2 accepté ; toutes les multiplicités simples sont respectées. Le modèle est-il valide ?
Voir le corrigé détaillé
Non : R2 interdit deux versions acceptées. Une configuration doit satisfaire les contraintes en plus des multiplicités. Ce cas révèle pourquoi un diagramme de classes demande parfois des notes métier complémentaires.
Cours et schémas originaux, étude pédagogique NKILItech. Référence de lecture : Benoît Charroux, Aomar Osmani et Yann Thierry-Mieg, UML 2 : pratique de la modélisation, 2e édition, Pearson, 2009. Les explications, exemples et figures ont été rédigés pour ce parcours. Référence de notation : spécification UML de l’OMG.