UML à l'examen : E6 et E7 SLAM, méthode et pièges

Au BTS SIO SLAM, UML intervient à deux épreuves : à l'E6 (conception et développement d'applications, bloc 2), où tes diagrammes figurent dans le dossier de tes réalisations et où tu dois modéliser l'évolution que la commission te demande ; et à l'E7 (cybersécurité des services informatiques, écrit de 4 heures), où le dossier documentaire fournit des diagrammes, le plus souvent un diagramme de classes, à lire pour écrire ou corriger du code. Ce chapitre décrit les types de questions, la méthode pour lire un diagramme fourni, les règles pour en dessiner un à la main et les erreurs qui coûtent des points.

Où UML intervient

À l'E6, le référentiel évalue notamment la compétence « Modéliser une solution applicative » : la commission attend une modélisation conforme au besoin et cohérente avec ton code. Le détail des compétences est dans le cours Épreuve E6 SLAM.

À l'E7, les sujets donnent régulièrement un diagramme des classes métier de l'application étudiée, accompagné d'un extrait de leur code : le sujet de la session 2025, par exemple, fournissait un extrait du diagramme des classes métier d'une application Java et le code de ces classes. Le diagramme n'est pas une fin en soi : c'est la carte qui te permet d'écrire du code juste. Les annales classées par thème sont dans le cours Épreuve E7 SLAM.

Les types de questions

Quand le sujet te laisse choisir le formalisme, tu peux répondre en UML ou en Merise, ou par un schéma relationnel textuel pour une base de données. Choisis celui que tu maîtrises le mieux et respecte-le jusqu'au bout.

Lire un diagramme de classes fourni

Avant toute question de code, prends cinq minutes pour lire le diagramme. Elles te feront gagner bien plus.

1. Repère les classes centrales : celles qui ont le plus d'associations. C'est le cœur du métier (dans AppliFrais, FicheFrais).
2. Lis chaque association en deux phrases, une dans chaque sens, avec les multiplicités : « une fiche a un visiteur ; un visiteur a zéro ou plusieurs fiches ».
3. Repère les héritages et les classes abstraites : une méthode écrite dans la mère s'applique aux filles ; une méthode abstraite est redéfinie dans chaque fille.
4. Note la façon dont les associations sont implémentées dans le code fourni : getLesFiches() renvoie une liste, getVisiteur() un objet. C'est ce que tu utiliseras dans ton code, avec exactement ces noms.
5. Annote le diagramme sur le sujet : entoure les classes et les méthodes dont tu auras besoin pour chaque question.

Dessiner à la main

À l'écrit de l'E7 comme sur ton brouillon pendant la préparation de la phase 1 de l'E6, tu dessines souvent sans outil de modélisation.

• Fais propre et grand. Une règle, un crayon, puis le stylo. Laisse de la place entre les classes pour les multiplicités et les noms d'associations.
• Écris ce que l'italique ne montre pas : {abstract} à côté d'une classe ou d'une opération abstraite, «interface» au-dessus du nom d'une interface.
• Mets les multiplicités aux deux bouts de chaque association. Une multiplicité oubliée est une information perdue, et le correcteur ne la devinera pas.
• Soigne les symboles qui changent le sens : triangle creux (héritage), losange plein ou creux (du côté du tout), pointillé (réalisation, dépendance, «include», «extend»). Un losange placé du mauvais côté inverse la relation.
• Ne recopie pas tout quand on te demande de compléter : redessine les classes concernées par l'évolution, et indique « (classes existantes inchangées) ».
• Ajoute une phrase d'explication sous un diagramme d'évolution : « Une classe Remboursement est ajoutée car une fiche peut être remboursée en plusieurs fois ; elle porte la date et le montant de chaque versement. » Elle montre ton raisonnement et rattrape une notation maladroite.

Les erreurs qui coûtent des points

À l'E6 : ta conception dans le dossier et pendant l'épreuve

Pour chacune de tes réalisations, ton dossier gagne à contenir :

• un diagramme de cas d'utilisation, qui montre en une image ce que fait ton application et pour qui ;
• un diagramme de classes (métier, pas forcément exhaustif), cohérent avec ton code et, si tu as une base de données, avec ton schéma relationnel ;
• si l'application a un scénario délicat (une authentification, un appel d'API, un traitement en plusieurs étapes), un diagramme de séquence de ce scénario ;
• éventuellement un diagramme de déploiement, pour montrer où tourne chaque partie.

La commission ne te demande pas les 14 diagrammes. Pendant les deux entretiens, elle te demande de justifier tes choix : « pourquoi une composition ici ? », « que se passe-t-il si la fiche est déjà validée ? ». Un diagramme que tu ne sais pas expliquer fait plus de mal que de bien.

En phase 1, l'expression des besoins porte sur l'une de tes réalisations. Repère d'abord, sur ton propre diagramme de classes, les classes que l'évolution touche, puis esquisse ce qui change : une classe, un attribut, une association avec ses multiplicités, un cas d'utilisation. Cette esquisse est une spécification technique que tu présentes et justifies pendant l'entretien (analyser l'expression des besoins). En phase 2, pendant la réalisation de l'évolution, si elle ajoute une classe ou une association, mets le diagramme à jour : c'est une preuve de méthode, que tu peux montrer à la recette (épreuve E6 SLAM : les évolutions types).

La checklist finale

Avant de rendre un diagramme, vérifie :

• Classes : noms au singulier ; attributs typés et privés ; opérations avec paramètres et type de retour ; multiplicités aux deux bouts de chaque association ; pas de clé étrangère ; {abstract} et «interface» visibles ; losanges du côté du tout.
• Cas d'utilisation : acteurs hors du cadre ; cas nommés « verbe + complément » ; flèches «include» et «extend» dans le bon sens ; pas d'ordre d'étapes.
• Séquence : chaque message correspond à une opération ; fragments avec leurs gardes ; l'acteur ne parle qu'à l'interface.
• Activité : un nœud initial, au moins un nœud final ; gardes exclusives et complètes ; fusion après une décision, jonction après une bifurcation.
• États-transitions : état initial ; chaque transition porte son événement ; les transitions interdites n'existent pas ; cohérence avec les opérations de la classe.

Exercices

public int nbLocationsEnCours() {
    int nb = 0;
    for (Vehicule v : this.getLesVehicules()) {
        for (Location l : v.getLesLocations()) {
            if (l.estEnCours()) {
                nb++;
            }
        }
    }
    return nb;
}