🎯 UML Résumé Ultime — Conception des SI

Cours 1

🌍 C'est quoi UML ?

Avant de dessiner des diagrammes, comprends pourquoi on en a besoin.

🤔 Imagine que tu construis une maison...

Tu ne commences pas directement à poser des briques, non ? D'abord, tu fais un plan (l'architecte dessine). UML, c'est exactement pareil mais pour les logiciels.

UML = Unified Modeling Language (Langage de Modélisation Unifié)
C'est un langage graphique, pas un langage de programmation !
Il permet de dessiner des plans pour comprendre un système avant de le coder
Normalisé par l'OMG (Object Management Group)

📊 Diagrammes Statiques

Montrent la structure du système (c'est quoi les pièces de la maison ?)

Diagramme de Classes ⭐
Diagramme d'Objets
Diagramme de Paquetages
Diagramme de Composants

🎬 Diagrammes Dynamiques

Montrent le comportement (comment les choses bougent ?)

Diagramme de Cas d'Utilisation ⭐
Diagramme de Séquence ⭐
Diagramme de Communication
Diagramme d'États-Transitions
Diagramme d'Activités

🏗️ Le Système d'Information (SI)

Définition simple : Le SI d'une entreprise = toutes les données + tous les traitements nécessaires à son fonctionnement.

Donnée vs Information

Concept	C'est quoi ?	Exemple
Donnée	Signe + code (brut)	71540325
Information	Donnée + interprétation	"C'est un numéro de téléphone"
Connaissance	Information interprétée	"C'est un abonné de Tunis"

📜 Les 3 générations de méthodes de conception

Génération	Approche	Points Forts ✅	Points Faibles ❌
1ère	Cartésienne	Simple, bon sens, capture des besoins	Focus fonctions, pas de réutilisation
2ème	Systémique	Cohérence données, 3 niveaux d'abstraction	Manque de cohérence données↔traitements
3ème	Objet (UML)	Modélise objets complexes, intègre données + traitements, encapsulation	"Tout objet" difficile à apprendre

Cours 7

🧭 La Démarche de Modélisation avec UML

UML te donne les dessins. La démarche te dit dans quel ordre les faire pour passer des besoins au code.

🚨 Idée fausse à corriger : UML n'est PAS une méthode

UML, c'est comme une boîte de crayons avec des règles de dessin. Une méthode, c'est la recette qui te dit : "dessine d'abord ça, vérifie ça, puis passe à l'étape suivante".

✅ UML = le langage

Il fournit les symboles : acteur, classe, transition, composant, nœud, message...

🧭 Méthode = le chemin

Elle organise le travail : besoins → analyse → conception → implémentation.

⚠️ Ce qu'il ne faut pas faire Ne commence pas par un diagramme de classes juste parce que tu aimes les classes. Si les besoins sont flous, ton diagramme sera joli mais probablement faux.

🏛️ Les 3 principes d'une méthode basée sur UML

1. Pilotée par les cas d'utilisation On part de ce qui est utile aux utilisateurs. Comme demander "à quoi sert le jouet ?" avant de fabriquer les pièces.

2. Centrée sur l'architecture On pense au squelette du système : gros composants, contraintes techniques, évolutions futures.

3. Itérative et incrémentale On construit petit morceau par petit morceau. Chaque tour améliore les modèles précédents.

Version enfant : tu ne construis pas tout le château LEGO d'un coup. Tu fais une tour, tu testes si elle tient, tu ajoutes un pont, tu corriges, puis tu continues.

🧱 La Méthode Archi-Minimale (le minimum vital)

Le cours propose une démarche plus simple que RUP, adaptée aux projets modestes. Elle garde seulement ce qui aide vraiment.

Recueillir les besoins
Détermine les limites du système, identifie les acteurs et recense les cas d'utilisation. Si le système est gros, range les cas en paquetages.
Classer les cas d'utilisation
Donne à chaque cas un degré d'importance et un risque. On attaque d'abord ce qui apporte beaucoup de valeur ou ce qui peut casser le projet.
Décrire les scénarios
Écris le scénario nominal et les scénarios alternatifs. Dessine un diagramme de séquence système pour montrer les échanges acteur ↔ système.
Faire une maquette IHM
Ce n'est pas UML, mais ça aide l'utilisateur à dire clairement ce qu'il veut. Sans maquette, il imagine une chose et toi une autre.
Construire le modèle du domaine
Fais un premier diagramme de classes avec les concepts métier : Client, Commande, Produit... À ce stade, mets surtout les attributs et associations, pas encore les opérations techniques.
Ajouter les classes participantes
Relie les cas d'utilisation au modèle objet avec trois familles : dialogues, contrôles, entités.
Modéliser la navigation et les activités
Si le scénario contient beaucoup de chemins ou d'écrans, utilise un diagramme d'activités pour clarifier le parcours.
Passer à la conception
Transforme les séquences système en interactions internes entre objets. Puis produis le diagramme de classes de conception qui servira au code.

🧑‍🍳 Les 3 Types de Classes d'Analyse

Quand tu passes des besoins au logiciel, tu ne mets pas tout dans une seule classe géante. Tu sépares les responsabilités.

Type	Rôle	Image simple 🧒	Exemple
Dialogue	Gère l'interaction avec l'utilisateur ou l'IHM	Le guichet où l'utilisateur parle	FenetreConnexion, PagePanier
Contrôle	Organise le scénario et applique les règles applicatives	Le chef d'orchestre	ControleurCommande
Entité	Représente les données persistantes du métier	Les fiches qu'on garde dans un classeur	Client, Facture, Produit

🧠 Règle de séparation L'IHM parle au contrôle. Le contrôle parle aux entités. Si une page web contient toute la logique métier, ton modèle est en train de devenir fragile.

🔄 Ce que chaque diagramme produit dans la démarche

Étape	Diagramme utile	Ce qu'il prouve
Besoins	Cas d'utilisation	On sait qui utilise le système et pour quoi faire.
Spécification	Séquence système	On sait quels messages passent entre acteur et système.
Analyse métier	Classes du domaine	On sait quels concepts métier existent et comment ils sont liés.
Scénarios complexes	Activités	On voit les décisions, branches, boucles et responsabilités.
Conception logicielle	Séquence / Communication	On sait quels objets collaborent à l'intérieur du système.
Architecture	Composants / Déploiement	On sait comment le logiciel est découpé et où il s'exécute.

✅ Conclusion pratique Les diagrammes ne sont pas indépendants : chaque diagramme doit corriger, préciser ou valider les autres. Si ton diagramme de séquence appelle une méthode absente du diagramme de classes, il y a une incohérence à réparer.

Cours 2 + TD1

👤 Diagramme de Cas d'Utilisation

Le premier diagramme qu'on fait — il répond à la question : "Qui fait quoi avec le système ?"

📖 C'est quoi ?

Imagine un restaurant 🍽️. Le diagramme de cas d'utilisation, c'est comme lister :

Qui vient au restaurant ? → Les Acteurs (client, serveur, cuisinier...)
Que font-ils ? → Les Cas d'Utilisation (commander, payer, cuisiner...)
Quels liens entre ces actions ? → Les Relations

💡 Objectif Principal C'est un outil de communication avec le client. Il montre les fonctionnalités du système du point de vue de l'utilisateur. C'est le cahier des charges visuel.

🧩 Les 4 Composants

1. Le Système (le rectangle)

Un grand rectangle qui représente les limites du système. Tout ce qui est dedans = ce que le système fait. Tout ce qui est dehors = l'environnement.

2. Les Acteurs (les bonhommes)

Type	Description	Position
Principal	Celui qui initie le cas d'utilisation et en tire un bénéfice	🔵 À gauche
Secondaire	Sollicité pour des infos complémentaires (ne démarre rien)	🟡 À droite

⚠️ Attention ! Un acteur peut être une personne (client, admin) ou un système externe (banque, API, serveur...). Ce n'est PAS forcément un humain !

3. Les Cas d'Utilisation (les ellipses)

Chaque ellipse = une fonctionnalité que le système offre. Le nom est toujours un verbe à l'infinitif.

4. Les Relations

Relation	Symbole	Signification	Exemple Simple 🧒
Association	Trait simple ——	L'acteur participe au cas	Le client utilise "Commander"
«include»	Flèche pointillée →	Le cas A inclut TOUJOURS le cas B	"Retirer argent" inclut toujours "S'authentifier"
«extend»	Flèche pointillée →	Le cas B est optionnel/exceptionnel pour le cas A	"Payer" peut être étendu par "Payer en CB"
Généralisation	Flèche avec triangle △	Relation parent → enfant (héritage)	"Client VIP" hérite de "Client"

🎯 Include vs Extend — La Confusion #1

C'est la question piège favorite des profs. Voici comment ne JAMAIS se tromper :

✅ «include» (toujours)

Le cas principal a BESOIN du cas inclus. Sans lui, ça ne marche pas.

Retirer argent ----«include»---→ S'authentifier (Tu DOIS t'authentifier pour retirer)

Truc : La flèche part du cas principal VERS le cas inclus

🔶 «extend» (parfois)

Le cas étendu peut ou ne peut pas se produire. C'est optionnel.

Payer ←---«extend»---- Payer par CB (Payer par CB est UNE OPTION de payer)

Truc : La flèche part du cas optionnel VERS le cas principal

🧠 Moyen mnémotechnique ULTIME «include» = "J'ai INCLUS mon déjeuner dans mon sac, je l'emporte TOUJOURS"
«extend» = "J'ÉTENDS ma serviette à la plage SI il fait beau (optionnel)"

Direction des flèches :
• include : Cas principal → → → Cas inclus (je vais CHERCHER ce dont j'ai besoin)
• extend : Cas optionnel → → → Cas principal (le cas optionnel VIENT se greffer)

📝 Comment Construire un Diagramme de Cas d'Utilisation (Pas à Pas)

Identifie le SYSTÈME
Lis l'énoncé et trouve ce qu'on construit. Dessine le rectangle avec le nom du système.
Trouve les ACTEURS
Cherche les noms de personnes/rôles/systèmes externes dans le texte. Pose la question : "Qui utilise le système ?" et "Qui est sollicité par le système ?"
Trouve les CAS D'UTILISATION
Cherche les verbes d'action dans le texte : "le client peut consulter", "le serveur enregistre"... Chaque verbe = un cas potentiel.
Relie les acteurs aux cas
Chaque acteur est relié par un trait simple aux cas auxquels il participe.
Ajoute les relations entre cas
Y a-t-il des actions obligatoires (include) ? Des alternatives optionnelles (extend) ? Des spécialisations (généralisation) ?
Vérifie la cohérence
Chaque acteur est lié à au moins un cas. Chaque cas est lié à au moins un acteur. Pas de cas "orphelin".

🔍 Comment Analyser un Énoncé (Exemple TD1)

Prenons l'exercice de l'agence de voyages :

📋 Texte : "Une agence de voyages organise des voyages où l'hébergement se fait en hôtel. Le client doit disposer d'un taxi quand il arrive à la gare. Certains clients demandent à l'agent de voyages d'établir une facture détaillée. Le voyage se fait soit par avion, soit par train."

🔎 Analyse mot par mot :

Acteurs : Client (celui qui demande) — acteur principal
Système : Agence de voyages
Cas principaux : "Organiser voyage", "Réserver hébergement", "Réserver transport"
"soit par avion, soit par train" → C'est un «extend» ou une généralisation de "Réserver transport"
"certains clients demandent une facture détaillée" → C'est optionnel → «extend»
"doit disposer d'un taxi" → C'est obligatoire → «include»

🔑 Mots-clés magiques dans les énoncés :

"doit", "toujours", "obligatoire" → «include»
"peut", "certains", "optionnel", "soit...soit" → «extend»
"est un type de", "est aussi" → généralisation

⚖️ Règles de Cohérence (Erreurs à ne PAS faire)

❌ ERREUR : Acteur dans le système Un acteur est TOUJOURS à l'EXTÉRIEUR du rectangle système. Jamais dedans !

❌ ERREUR : Cas sans acteur Chaque cas d'utilisation doit être relié à au moins un acteur (directement ou indirectement via include/extend).

❌ ERREUR : Trait entre 2 acteurs Les acteurs ne communiquent pas entre eux ! Seule relation possible : la généralisation (héritage).

❌ ERREUR : Trop de détails Un cas d'utilisation n'est PAS un "bouton" ou une "page web". C'est un SERVICE complet rendu à l'acteur.

📄 Description Textuelle d'un Cas d'Utilisation

Chaque cas d'utilisation peut (et souvent doit) être décrit textuellement :

Champ	Description
Nom	Le nom du cas (verbe à l'infinitif)
Acteur principal	Qui lance ce cas
Préconditions	Ce qui doit être vrai AVANT
Scénario nominal	Les étapes du cas normal (1, 2, 3...)
Scénarios alternatifs	Les variantes (extend)
Postconditions	Ce qui est vrai APRÈS

Cours 3 + TD2

🧱 Diagramme de Classes

Le diagramme STAR ⭐ d'UML — il montre la structure de ton système : les objets et leurs liens.

📖 C'est quoi ?

Le diagramme de cas d'utilisation dit à QUOI sert le système. Le diagramme de classes dit DE QUOI il est fait.

Imagine un jeu LEGO 🧱. Le diagramme de classes, c'est la notice qui liste toutes les pièces et comment elles s'emboîtent.

📦 Comment dessiner une Classe

Une classe a 3 compartiments :

Visibilité des attributs/opérations

Symbole	Visibilité	Signification 🧒
-	private	Personne ne peut y toucher sauf moi
+	public	Tout le monde peut y accéder
#	protected	Moi et mes enfants seulement
~	package	Ceux de mon groupe/paquet

🔗 Les Associations (les liens entre classes)

Association Simple

Un trait entre deux classes = elles sont liées. On peut ajouter :

Nom de l'association (un verbe : "emploie", "possède"...)
Rôles (à chaque extrémité : "employeur", "employé")
Sens de lecture (petite flèche ▶)

⭐ Les Multiplicités (SUPER IMPORTANT)

Notation	Signification	Exemple 🧒
1	Exactement 1 (obligatoire)	1 personne a exactement 1 cerveau
0..1	0 ou 1 (optionnel)	1 personne a 0 ou 1 voiture
* ou 0..*	0 ou plusieurs	1 personne peut avoir 0 ou plein d'amis
1..*	Au moins 1	1 équipe a au minimum 1 joueur
n..m	Entre n et m	1 main a entre 0 et 5 doigts

🧠 Comment lire les multiplicités ? Lis toujours depuis UNE instance d'un côté vers l'autre côté :

Personne 1..* ————— 0..1 Entreprise

→ "1 Entreprise emploie 1 ou plusieurs (1..*) Personnes"
→ "1 Personne travaille dans 0 ou 1 (0..1) Entreprise"

⚠️ La multiplicité est TOUJOURS du côté OPPOSÉ à la classe qu'on lit !

💎 Agrégation vs Composition

C'est la question piège #2 des profs !

◇ Agrégation (losange VIDE)

Relation "contient" mais les parties peuvent exister seules.

Exemple : Une Équipe ◇—— Joueur

Si l'équipe est dissoute, les joueurs existent encore ! Ils peuvent rejoindre une autre équipe.

◆ Composition (losange PLEIN)

Relation "composé de" et les parties meurent avec le tout.

Exemple : Une Maison ◆—— Pièce

Si la maison est détruite, les pièces n'existent plus !

🧠 Test magique en 2 questions :

Si je détruis le tout, les parties sont-elles détruites aussi ? OUI → Composition ◆
Une partie peut-elle appartenir à plusieurs "touts" en même temps ? NON → Composition ◆

Si tu réponds OUI à Q1 ET NON à Q2 → Composition ◆
Sinon → Agrégation ◇

🧬 Héritage (Généralisation / Spécialisation)

C'est comme une famille 👨‍👩‍👧 : l'enfant hérite des caractéristiques du parent mais peut avoir les siennes en plus.

La classe enfant hérite tous les attributs et opérations du parent
L'enfant peut redéfinir (override) les méthodes du parent
Toutes les associations du parent s'appliquent aux enfants
Principe de substitution : partout où on attend un Animal, on peut mettre un Chat 🐱

🎓 Concepts Avancés

📎 Classe d'Association

Quand une association elle-même a des attributs ou des opérations, on crée une classe d'association.

Exemple : Personne — travaille — Société. Le "contrat de travail" a un salaire et une date → classe d'association "Contrat"

Elle est reliée à l'association par un trait en pointillé.

🔒 Classe Abstraite & Interface

Classe abstraite : Une classe qu'on ne peut pas instancier directement. Son nom est en italique. Elle contient au moins une méthode abstraite (sans corps).

Interface : Un "contrat" qui dit quelles opérations une classe doit implémenter. Notation : «interface» au-dessus du nom.

Relation d'implémentation = flèche pointillée avec triangle vide △

🧭 Navigabilité

Une flèche à une extrémité indique dans quel sens on peut traverser l'association.

A ——→ B signifie : A connaît B, mais B ne connaît pas A.

Par défaut (pas de flèche) : la navigabilité est dans les deux sens.

📊 Diagramme d'Objets (compagnon du diag. de classes)

Le diagramme d'objets montre des instances concrètes à un moment donné.

Le nom est souligné : jean:Personne
On montre les valeurs des attributs (pas les types)
Pas de multiplicités dans un diagramme d'objets !

Diagramme de classes = les RÈGLES / Diagramme d'objets = les FAITS

🔨 Comment Construire un Diagramme de Classes (Pas à Pas)

Trouver les CLASSES
Cherche les noms / substantifs importants dans le texte. "Client", "Commande", "Produit" → ce sont des classes.
Trouver les ASSOCIATIONS
Cherche les verbes qui relient deux classes. "Le client passe une commande" → association entre Client et Commande.
Trouver les MULTIPLICITÉS
Pour chaque association, pose la question : "1 Client peut passer combien de commandes ?" et "1 Commande est passée par combien de clients ?"
Trouver les ATTRIBUTS
Cherche les détails (nom, prix, date...) = ce sont des attributs. Ils sont plus "petits" que des classes.
Organiser avec l'HÉRITAGE
Y a-t-il des "types de" ? "Un vélo est un type de produit" → héritage.
Vérifier agrégation/composition
Y a-t-il des relations "fait partie de" ? Utilise le test des 2 questions.
Raffiner et itérer
Vérifie les chemins d'accès. Simplifie. Ajoute les opérations si demandé.

🔑 Truc pour différencier Classe vs Attribut :
Si un concept a ses propres attributs ou relations → c'est une classe.
Si c'est juste une valeur simple (nom, âge, prix) → c'est un attribut.

Exemple : "adresse" → Si c'est juste "12 rue X" → attribut. Si elle a (rue, ville, codePostal) → classe !

Cours 4 + TD3

🔄 Diagramme de Séquence

Il montre comment les objets discutent entre eux dans le temps — comme un script de film 🎬

📖 C'est quoi ?

Imagine un groupe WhatsApp 📱 : chaque personne envoie des messages, et tu vois l'ordre dans lequel ils arrivent (qui a parlé en premier, en deuxième...). Le diagramme de séquence, c'est exactement ça !

Dimension horizontale → Les objets/acteurs (les "participants")
Dimension verticale ↓ Le temps (de haut en bas)
Les flèches = les messages échangés

🧩 Les Composants

Les Participants

Ligne de vie = ligne verticale pointillée sous chaque participant = son "existence" dans le temps
Zone d'activation = petit rectangle sur la ligne de vie = le moment où l'objet est actif (il fait quelque chose)

✉️ Les Types de Messages

Type	Flèche	Description	Exemple 🧒
Synchrone	—▶ (pleine)	L'envoyeur attend la réponse avant de continuer	Tu appelles quelqu'un au tel et tu attends qu'il décroche
Asynchrone	—> (ouverte)	L'envoyeur continue sans attendre	Tu envoies un SMS et tu continues ta vie
Retour	- - - > (pointillé)	La réponse à un message synchrone	La personne te rappelle avec la réponse
Création	- -«create»- ->	Crée un nouvel objet	Tu crées un nouveau groupe WhatsApp
Destruction	❌ sur la ligne de vie	Détruit un objet	Tu supprimes le groupe
Récursif	Flèche qui revient sur soi	L'objet s'envoie un message à lui-même	Tu te parles tout seul 🤷

🏗️ Les Fragments Combinés (Structures de contrôle)

Ce sont des boîtes rectangulaires qui entourent des messages pour montrer des conditions, boucles, etc.

🔀 alt (si...sinon)

Comme un if/else. Divisé en 2 zones par une ligne pointillée. Chaque zone a sa condition entre [crochets].

┌─ alt ─────────────┐ │ [montant > 0] │ │ payer() │ │- - - - - - - - - -│ │ [else] │ │ erreur() │ └───────────────────┘

🔁 loop (boucle)

Comme un while. Répète les messages tant que la condition est vraie.

┌─ loop ────────────┐ │ [pour chaque │ │ article] │ │ scanner(article) │ │ afficherPrix() │ └────────────────────┘

❓ opt (optionnel)

Comme un if sans else. Le fragment est exécuté seulement SI la condition est vraie.

┌─ opt ─────────────┐ │ [clientFidèle] │ │ appliquerRemise()│ └───────────────────┘

📌 ref (référence)

Fait référence à un autre diagramme de séquence. Utile pour ne pas surcharger le schéma.

┌─ ref ─────────────┐ │ │ │ Processus de │ │ paiement │ │ │ └───────────────────┘

🔨 Comment Construire un Diagramme de Séquence (Pas à Pas)

Identifie le SCÉNARIO
Un diag. de séquence illustre UN scénario (souvent le scénario nominal d'un cas d'utilisation). Lis l'énoncé et identifie les étapes.
Identifie les PARTICIPANTS
Les acteurs + les objets impliqués. Regarde le diagramme de classes pour trouver les bonnes classes.
Place-les horizontalement
L'acteur à gauche, puis les objets dans l'ordre où ils interviennent.
Trace les MESSAGES de haut en bas
Suis l'ordre chronologique du scénario. Chaque étape = un message (ou plusieurs).
Ajoute les RETOURS
Chaque message synchrone doit avoir un message de retour (pointillé).
Ajoute les FRAGMENTS si nécessaire
S'il y a des conditions → alt/opt. Des boucles → loop. Des sous-scénarios → ref.

🧠 Cohérence avec le diagramme de classes !

Les participants doivent être des instances de classes qui existent dans le diag. de classes
Les messages doivent correspondre à des opérations définies dans la classe du destinataire
Les arguments des messages doivent être cohérents avec les paramètres des opérations

🔍 Analyse d'Exercice (TD3 — ChampionnatEchecs)

Voici comment aborder ce type d'exercice pas à pas :

Question 1 : Comment modéliser admin et participants ?

Ce sont des acteurs (bonhommes allumettes). Ils sont extérieurs au système.

L'administrateur crée le championnat et génère les parties.

Les participants s'inscrivent et jouent.

Question 2 : Création championnat + inscription 2 joueurs

Participants : Admin, :ChampionnatDEchecs, :Joueur1, :Joueur2

Admin → «create» → :ChampionnatDEchecs(MAX=...)
Participant1 → :ChampionnatDEchecs : inscriptionJoueur("nom1","prénom1")
:ChampionnatDEchecs → «create» → :Joueur (numéro=1)
Retour ← numéro=1
Participant2 → :ChampionnatDEchecs : inscriptionJoueur("nom2","prénom2")
:ChampionnatDEchecs → «create» → :Joueur (numéro=2)
Retour ← numéro=2

⚠️ Cohérence : L'opération inscriptionJoueur retourne un integer (le numéro) — exactement comme dans le diag. de classes !

Question 4 : Déroulement d'une partie en 4 coups

Astuce : Utilise un fragment loop pour les coups !

Joueur1 → :Partie : jouerCoup("e2-e4")
:Partie → :Partie : vérifierMat() → retour false
Joueur2 → :Partie : jouerCoup("e7-e5")
:Partie → :Partie : vérifierMat() → retour false
... (répéter)
Au dernier coup : vérifierMat() → retour true
:Partie → :Partie : finirPartie()

Le message vérifierMat() est un message récursif (l'objet :Partie s'appelle lui-même).

Cours 4

🔗 Diagramme de Communication

C'est le jumeau du diagramme de séquence — même info, présentation différente.

📖 C'est quoi ?

Imagine que au lieu de lire les messages d'un groupe WhatsApp de haut en bas (séquence), tu vois tous les participants reliés en réseau avec des numéros sur les messages. C'est le diagramme de communication !

Les objets sont des rectangles reliés par des traits (liens)
Les messages sont numérotés pour montrer l'ordre
C'est un graphe, pas une timeline

✍️ Syntaxe des Messages

Format	Signification	Exemple
`4 : méthode()`	Message simple numéro 4	4 : Afficher(x,y)
`3.3.1 : méthode()`	Message imbriqué (3→3.3→3.3.1)	3.3.1 : Afficher(x,y)
`4.2 : ret := méthode()`	Avec valeur de retour	4.2 : âge := Calculer(date)
`[condition] 6 : méthode()`	Message conditionnel	[age>=18] 6.2 : Voter()
`1 * : méthode()`	Message itéré (boucle)	1 * : Laver()

⚔️ Séquence vs Communication — Quand utiliser quoi ?

📊 Diagramme de Séquence

Quand l'ordre temporel est important
Quand on part d'un cas d'utilisation
Pour des scénarios détaillés et longs
Plus facile à lire pour les débutants

🔗 Diagramme de Communication

Quand on veut voir l'architecture
Pour valider le diag. de classes
Quand les relations entre objets comptent plus
Reflète mieux la structure du système

💡 Ils sont équivalents ! Tout diagramme de séquence peut être converti en diagramme de communication et vice versa. C'est juste un point de vue différent sur la même interaction.

Cours 5

🚦 Diagramme d'États-Transitions

Il décrit la vie interne d'un objet : dans quel état il est, quel événement arrive, et dans quel état il part.

📖 C'est quoi ?

Imagine un feu tricolore. Il peut être vert, puis orange, puis rouge. Il ne change pas au hasard : un événement comme after(25s) déclenche le passage à l'état suivant.

Un état = une situation stable pendant un moment
Une transition = le passage d'un état à un autre
Un événement = ce qui déclenche la transition
Le diagramme est un graphe : états = nœuds, transitions = flèches

💡 À quoi ça sert ? À modéliser un objet qui a un cycle de vie clair : Commande (créée → validée → payée → livrée), Compte (actif → bloqué), Partie (en attente → en cours → terminée).

🧩 Les Éléments de Base

Élément	Notation	Explication simple
État	Rectangle arrondi	L'objet reste ici jusqu'à ce qu'un événement arrive.
État initial	Point noir ●	Le point de départ de la vie de l'objet.
État final	Cible ◉	La fin du cycle de vie.
Transition externe	Flèche état A → état B	Elle change l'état actif.
Événement	`evenement()`	Le bouton qui déclenche le changement.
Garde	`[condition]`	La porte ne s'ouvre que si la condition est vraie.
Action	`/ action()`	Ce qu'on fait pendant la transition.

⚡ Les Événements Déclencheurs

Type	Syntaxe	Quand l'utiliser ?	Exemple
call	`nomEvenement(params)`	Quand une méthode est appelée	`payer(montant)`
signal	`signal(params)`	Quand un signal externe arrive	`alarmeDeclenchee()`
change	`when(condition)`	Quand une condition devient vraie	`when(stock == 0)`
after	`after(duree)`	Quand un délai est écoulé depuis l'entrée dans l'état	`after(10s)`

🧠 Syntaxe complète d'une transition événement(paramètres) [garde] / action
Exemple : valider() [panierNonVide] / créerFacture()

🏠 Transitions Internes : entry, do, exit

Parfois l'objet fait quelque chose dans l'état sans forcément changer d'état.

Mot-clé	Moment	Image simple
`entry`	Juste à l'entrée de l'état	Tu entres dans une pièce et tu allumes la lumière.
`do`	Pendant que l'objet reste dans l'état	Tu restes dans la pièce et tu travailles.
`exit`	Juste avant de quitter l'état	Tu sors et tu éteins la lumière.
`include`	Appel d'une sous-machine d'états	Tu délègues un mini-cycle de vie à un autre schéma.

Transition externe

Elle quitte l'état source et active un autre état. C'est le cas le plus courant.

Transition interne

Elle exécute une action sans changer l'état actif. Pratique pour éviter des faux états.

🧠 États Avancés

🔀 Point de choix vs point de jonction

Point de choix = losange. Il choisit une branche selon les gardes [condition].

Point de jonction = petit cercle. Il sert surtout à partager des morceaux de transition pour rendre le dessin plus compact.

📦 État composite

Un état composite contient des sous-états. Exemple : Commande en traitement peut contenir Préparation, Contrôle, Emballage.

On l'utilise quand un état est trop gros pour être expliqué par une seule boîte.

↩️ État historique

L'état historique mémorise le dernier sous-état actif. C'est comme reprendre un jeu exactement là où on l'a laissé.

🔨 Comment Construire un Diagramme d'États (Pas à Pas)

Choisis UN objet
Un diagramme d'états décrit un objet précis, pas tout le système.
Liste les états stables
Cherche les adjectifs ou situations : brouillon, validé, payé, bloqué, terminé...
Ajoute l'état initial et l'état final
Le cycle doit avoir un début clair et, si possible, une fin claire.
Trouve les événements
Cherche ce qui déclenche les changements : valider(), annuler(), after(30j), when(solde<0)...
Ajoute les gardes et actions
Une garde bloque la transition si elle est fausse. Une action décrit ce qu'on fait pendant le passage.
Simplifie
Si le dessin devient illisible, utilise points de choix, états composites ou sous-machines.

Cours 5

🛤️ Diagramme d'Activités

Il montre le déroulement d'un travail : actions, décisions, boucles, parallélisme et responsabilités.

📖 C'est quoi ?

Le diagramme d'activités est une variante du diagramme d'états, mais il met l'accent sur les actions. Quand une action se termine, le flot passe automatiquement à la suivante.

Très utile pour détailler une méthode ou un cas d'utilisation
Plus lisible qu'un diagramme de séquence quand il y a beaucoup de conditions
Permet de montrer qui fait quoi avec des couloirs d'activités

💡 Version enfant C'est une recette avec des flèches : "prendre commande" → "vérifier paiement" → si OK "préparer", sinon "refuser".

🧩 Les Nœuds d'Activité

Nœud	Notation	Rôle
Action	Rectangle arrondi	Une étape exécutable : calculer, vérifier, envoyer...
Objet	Rectangle	Un objet produit ou consommé par une action.
Décision	Losange	Choisit une branche selon une condition.
Fusion	Losange	Rassemble plusieurs branches alternatives.
Bifurcation	Barre épaisse	Lance plusieurs flots en parallèle.
Union	Barre épaisse	Attend que les flots parallèles se rejoignent.
Initial	Point noir ●	Début de l'activité.
Final d'activité	Cible ◉	Termine toute l'activité.
Final de flot	Cercle avec X	Termine seulement un flot, pas les autres.

🏊 Couloirs d'Activités (Swimlanes)

Un couloir indique qui est responsable de chaque action : client, système, banque, service livraison...

✅ Quand les utiliser ? Utilise les swimlanes si plusieurs acteurs/objets se partagent le travail. Tu évites ainsi de dessiner un processus où on ne sait pas qui fait quoi.

⚠️ Limite Si les flèches traversent trop de couloirs dans tous les sens, le diagramme devient illisible. Dans ce cas, sépare en plusieurs diagrammes plus petits.

🔀 Décision, Fusion, Fork, Join

Décision / Fusion Un losange coupe le flot en alternatives ou réunit des alternatives. Chaque sortie de décision doit avoir une garde : [oui], [non], [stock>0].

Bifurcation / Union Une barre épaisse lance des actions en parallèle ou les synchronise. Exemple : préparer facture et préparer colis en même temps, puis attendre les deux.

🧠 Final d'activité vs final de flot Le final d'activité arrête tout le processus. Le final de flot arrête seulement une branche. Si tu as des actions parallèles, cette différence peut changer le sens du diagramme.

🔨 Comment Construire un Diagramme d'Activités (Pas à Pas)

Choisis le processus
Prends un cas d'utilisation ou une méthode : "traiter commande", "inscrire étudiant", "payer facture".
Écris les actions dans l'ordre
Chaque action doit être courte et verbale : vérifier, calculer, envoyer, enregistrer...
Ajoute les décisions
Quand le texte dit "si", "sinon", "selon", "peut", ajoute un losange avec des gardes.
Ajoute les objets si utiles
Montre les documents ou données qui circulent : Facture, Demande, Reçu...
Ajoute les swimlanes
Si plusieurs responsables interviennent, sépare-les en couloirs.
Vérifie le début et la fin
Un début clair, une fin claire, pas de branche qui part dans le vide.

⚔️ Activité vs Séquence vs États

Tu veux montrer...	Choisis	Pourquoi
Les étapes d'un processus avec conditions	Activité	Le flot de travail est le plus important.
Les messages entre objets dans le temps	Séquence	L'ordre chronologique des appels est le plus important.
La vie interne d'un objet	États	Les états stables et les événements sont le plus important.

Cours 6

🧩 Diagrammes de Composants & Déploiement

Ces vues montrent l'architecture : comment le logiciel est découpé et où il est installé.

📦 Diagramme de Composants — C'est quoi ?

Un composant est une brique logicielle autonome qui fournit un service précis. Il cache ses classes internes et montre seulement ses interfaces.

Il encapsule des fonctionnalités cohérentes
Il doit être réutilisable autant que possible
Il peut avoir des interfaces offertes et des interfaces requises
Son comportement interne peut être réalisé par des classes, d'autres composants ou des artefacts

💡 Version enfant C'est comme une prise électrique : tu n'as pas besoin de voir les fils dans le mur. Tu connais juste l'interface : brancher ici, recevoir de l'énergie.

🔌 Interfaces, Ports et Dépendances

Élément	Signification	À retenir
Interface offerte	Service fourni par le composant	Notation "lollipop" : petit cercle.
Interface requise	Service dont le composant a besoin	Notation "socket" : demi-cercle.
Port	Point de connexion sur le bord du composant	Permet de changer l'intérieur sans casser les clients externes.
Connecteur «delegate»	Relie un port externe à un élément interne	Il délègue le travail vers l'intérieur du composant.
Dépendance	Un composant utilise un autre composant	Flèche pointillée orientée vers ce dont on dépend.

🖥️ Diagramme de Déploiement — C'est quoi ?

Le diagramme de déploiement montre la réalité physique : serveurs, postes clients, appareils, connexions réseau, et artefacts installés dessus.

Un nœud = ressource matérielle ou environnement d'exécution
Un artefact = fichier déployable : exécutable, script, document, table, archive...
Un composant doit normalement être manifesté par un artefact avant d'être déployé

🔗 Relations Importantes en Déploiement

Relation	Syntaxe	Explication
Déploiement direct	Artefact dans le nœud	On dessine le fichier à l'intérieur du serveur ou poste.
«support»	Composant → nœud	Montre qu'un nœud supporte un composant.
«manifest»	Artefact → élément modèle	Montre qu'un fichier implémente un composant ou une classe.
Connexion	Ligne entre nœuds	Montre une communication physique ou réseau.

⚠️ Rigueur UML En théorie, on déploie des artefacts sur des nœuds, pas directement des composants. Le composant est manifesté par un artefact, puis l'artefact est déployé.

🔨 Comment Construire ces Diagrammes (Pas à Pas)

Diagramme de composants

Liste les gros blocs logiciels réutilisables.
Donne à chaque composant un service clair.
Ajoute les interfaces offertes et requises.
Relie les dépendances.
Cache les classes internes sauf si elles aident à comprendre.

Diagramme de déploiement

Liste les machines, serveurs et environnements.
Ajoute les artefacts installés dessus.
Relie les nœuds par leurs connexions.
Ajoute «manifest» si tu montres quel artefact implémente quel composant.
Vérifie que l'architecture physique correspond aux contraintes du système.

⚔️ Composant vs Classe vs Artefact vs Nœud

Concept	C'est quoi ?	Exemple
Classe	Plan d'un objet dans le code	Commande, Client, Facture
Composant	Bloc logiciel qui fournit des services	GestionCommande, Paiement
Artefact	Fichier concret produit ou utilisé	app.jar, schema.sql, facture.pdf
Nœud	Machine ou environnement d'exécution	Serveur web, PC client, JVM, conteneur

Astuces Exam

🧠 Astuces pour Réussir TOUT Exercice

Les stratégies qui font la différence entre 10/20 et 18/20 💪

📋 Comment Lire un Énoncé (Méthode du Surlignage)

1ère lecture : COMPRENDS le contexte
Lis tout sans rien marquer. Comprends de quoi on parle (une banque ? un hôpital ? un jeu ?).
2ème lecture : SURLIGNE avec des couleurs mentales
🟢 VERT = Acteurs (noms de personnes/rôles/systèmes externes)
🔵 BLEU = Classes/Entités (noms/concepts importants)
🟡 JAUNE = Actions/Cas (verbes d'action)
🟣 ROSE = Conditions ("si", "peut", "doit", "certains"...)
3ème lecture : VÉRIFIE ce qu'on te demande
Quel diagramme ? Quel scénario ? Quelles contraintes ?

💀 Top 14 des Erreurs qui Font Perdre des Points

1. ❌ Sens des flèches include/extend Include : Cas principal → Cas inclus
Extend : Cas optionnel → Cas principal

2. ❌ Multiplicités inversées La multiplicité se lit depuis l'autre côté ! "1..*" à droite = "un objet à gauche est lié à 1 ou plusieurs à droite"

3. ❌ Agrégation au lieu de Composition Pose les 2 questions magiques ! Destruction + Appartenance exclusive = Composition ◆

4. ❌ Messages vers le mauvais objet En séquence : vérifie que le message correspond à une opération de la classe du DESTINATAIRE

5. ❌ Oublier les messages de retour Chaque message synchrone ▶ doit avoir un retour ← (flèche pointillée)

6. ❌ Acteur à l'intérieur du rectangle système Les acteurs sont TOUJOURS dehors !

7. ❌ Cas d'utilisation trop détaillés "Cliquer sur bouton" n'est PAS un cas d'utilisation ! "S'authentifier" OUI.

8. ❌ Oublier les attributs/opérations En classe : mets les attributs (privés -) et les opérations (publiques +)

9. ❌ Numérotation désordonnée (communication) Les numéros doivent refléter l'ordre chronologique ET l'imbrication

10. ❌ Pas de cohérence entre diagrammes Si tu as un diag. de classes ET de séquence, les classes/opérations doivent être les mêmes !

11. ❌ Confondre activité et état Activité = flot de travail. État = cycle de vie d'un objet. Ce n'est pas interchangeable.

12. ❌ Oublier les gardes Après un losange, chaque branche doit dire quand elle est prise : [oui], [non], [stock>0]...

13. ❌ Déployer un composant comme un fichier En déploiement, le fichier concret est l'artefact. Le composant est manifesté par cet artefact.

14. ❌ Croire qu'UML est une méthode complète UML donne les notations. La démarche organise les étapes et les itérations.

🌳 Arbre de Décision : Quel Diagramme Utiliser ?

La question demande...	→ Diagramme	Indice dans l'énoncé
"Qui fait quoi ?"	Cas d'Utilisation	"les acteurs", "les fonctionnalités", "les besoins"
"De quoi est composé le système ?"	Classes	"les entités", "la structure", "les données"
"Dans quel ordre ça se passe ?"	Séquence	"le scénario", "le déroulement", "les échanges"
"Comment les objets coopèrent ?"	Communication	"la coopération", "les liens entre objets"
"Quels états traverse un objet ?"	États-Transitions	"état", "cycle de vie", "événement", "après X secondes"
"Quelles étapes suit un processus ?"	Activités	"workflow", "si/sinon", "parallèle", "responsable"
"Quels modules logiciels composent l'application ?"	Composants	"interface offerte/requise", "service", "dépendance"
"Sur quelles machines tourne le système ?"	Déploiement	"serveur", "poste client", "artefact", "réseau"
"Comment passer des besoins au code ?"	Démarche UML	"besoins", "analyse", "conception", "itération"

📜 Cheat Sheet Express par Diagramme

👤 Cas d'Utilisation — Checklist rapide

☐ Rectangle système avec nom
☐ Acteurs principaux à gauche
☐ Acteurs secondaires à droite
☐ Cas = ellipse + verbe infinitif
☐ Traits acteur ↔ cas
☐ «include» = toujours obligatoire (flèche vers le cas inclus)
☐ «extend» = optionnel (flèche vers le cas étendu)
☐ Généralisation = triangle vide
☐ Chaque cas lié à au moins 1 acteur

🧱 Classes — Checklist rapide

☐ Chaque classe : Nom + Attributs + Opérations
☐ Visibilité : - private, + public, # protected
☐ Associations avec nom et/ou rôles
☐ Multiplicités aux DEUX extrémités
☐ Agrégation ◇ / Composition ◆ si nécessaire
☐ Héritage avec triangle △ vide
☐ Classe d'association si l'association a des attributs
☐ Attribut type = String, int, boolean, Date...
☐ Navigabilité si précisée

🔄 Séquence — Checklist rapide

☐ Participants en haut : nomObjet:Classe
☐ Lignes de vie verticales en pointillé
☐ Zones d'activation (rectangles)
☐ Messages synchrones = flèche pleine ▶
☐ Messages de retour = flèche pointillée
☐ Messages = opérations de la classe destinataire
☐ Fragments alt/loop/opt/ref si conditions
☐ «create» pour créer un objet
☐ Cohérence avec le diagramme de classes

🔗 Communication — Checklist rapide

☐ Objets = rectangles
☐ Liens = traits entre objets
☐ Messages numérotés : 1, 2, 3...
☐ Messages imbriqués : 1.1, 1.2, 2.1...
☐ Conditions entre [crochets]
☐ * pour itération
☐ Flèche sur le lien pour la direction du message

🚦 États-Transitions — Checklist rapide

☐ Un seul objet ou système à cycle de vie clair
☐ État initial ● et état final ◉ si le cycle se termine
☐ États stables nommés proprement
☐ Transitions avec événement déclencheur
☐ Gardes entre [crochets] quand il y a condition
☐ Actions après / si nécessaire
☐ entry / do / exit seulement pour les actions internes à l'état

🛤️ Activités — Checklist rapide

☐ Actions courtes avec verbes d'action
☐ Début ● et fin claire
☐ Décisions avec gardes sur toutes les sorties
☐ Fork/join si actions parallèles
☐ Swimlanes si plusieurs responsables
☐ Final de flot utilisé seulement pour arrêter une branche

🧩 Composants — Checklist rapide

☐ Composants = blocs logiciels réutilisables
☐ Chaque composant fournit un service précis
☐ Interfaces offertes = services fournis
☐ Interfaces requises = services nécessaires
☐ Ports si on veut montrer les points de connexion
☐ Dépendances orientées vers ce dont on dépend

🖥️ Déploiement — Checklist rapide

☐ Nœuds = machines ou environnements d'exécution
☐ Artefacts = fichiers concrets déployables
☐ Connexions réseau entre nœuds
☐ «manifest» pour relier artefact et composant
☐ «support» si un nœud supporte un composant
☐ Ne pas confondre composant logique et fichier physique

🧭 Démarche UML — Checklist rapide

☐ UML = langage de modélisation, pas méthode complète
☐ Démarche pilotée par les cas d'utilisation
☐ Architecture pensée tôt, pas à la fin
☐ Travail itératif et incrémental
☐ Besoins → analyse du domaine → classes participantes → conception
☐ Chaque diagramme doit rester cohérent avec les autres

🎯 Stratégie d'Examen

✅ Avant de commencer :

Lis TOUT l'énoncé 2 fois
Identifie le type de diagramme demandé
Surligne les acteurs, classes, actions
Dessine d'abord un brouillon

✅ Pendant le dessin :

Commence par le plus évident (acteurs ou classes principales)
Ajoute les détails progressivement
Vérifie la cohérence à chaque étape
Relis l'énoncé pour ne rien oublier

✅ Après avoir fini :

Vérifie que chaque élément du texte est dans ton diagramme
Vérifie les multiplicités
Vérifie les sens des flèches
Vérifie la notation (include vs extend, ◇ vs ◆)

✅ Si tu bloques :

Commence par ce que tu sais
Mets des post-it mentaux "à vérifier"
Ne perds pas 20min sur une multiplicité, avance !
Un diagramme partiel > pas de diagramme

Résumé Final

✅ Checklist Globale — Tout en un Coup d'Œil

La dernière page à relire avant l'exam 🔥

📊 Résumé des 4 Diagrammes Fondamentaux

	👤 Cas d'Utilisation	🧱 Classes	🔄 Séquence	🔗 Communication
Type	Dynamique (fonctionnel)	Statique (structurel)	Dynamique (temporel)	Dynamique (spatial)
Question	Qui fait quoi ?	De quoi c'est fait ?	Dans quel ordre ?	Qui parle à qui ?
Éléments clés	Acteurs, Cas (ellipses), Relations	Classes, Attributs, Associations	Objets, Messages, Temps	Objets, Liens, Messages numérotés
Piège #1	Include vs Extend	Agrégation vs Composition	Oublier les retours	Numérotation incorrecte
Source TD	TD1	TD2	TD3	Cours 4

📊 Résumé des Diagrammes d'Architecture et de Comportement

	🚦 États	🛤️ Activités	🧩 Composants	🖥️ Déploiement	🧭 Démarche
Type	Dynamique interne	Dynamique procédural	Statique architectural	Physique	Processus de modélisation
Question	Quels états ?	Quelles étapes ?	Quels modules ?	Où ça tourne ?	Dans quel ordre travailler ?
Éléments clés	États, transitions, événements, gardes	Actions, décisions, fork/join, swimlanes	Composants, interfaces, ports, dépendances	Nœuds, artefacts, connexions, manifest	Besoins, analyse, conception, itérations
Piège #1	Mettre un processus entier au lieu d'un objet	Oublier les gardes sur les branches	Confondre interface offerte et requise	Confondre composant et artefact	Traiter UML comme une méthode complète
Source	Cours 5	Cours 5	Cours 6	Cours 6	Cours 7

🗝️ Les Mots Magiques (Résumé)

→ Include "doit", "toujours", "nécessite", "obligatoire", "il faut"

→ Extend "peut", "optionnel", "certains", "parfois", "soit...soit"

→ Héritage "est un type de", "est un", "spécialise", "hérite"

→ Composition ◆ "composé de", "contient" (et meurt avec), "fait partie intégrante"

→ Agrégation ◇ "contient", "regroupe" (mais indépendant), "a des"

→ Association simple "utilise", "réserve", "emploie", tout autre verbe

→ États "état", "devient", "passe à", "après", "quand", "si condition"

→ Activités "workflow", "étape", "processus", "parallèle", "responsable"

→ Composants "module", "service", "interface", "dépend de", "réutilisable"

→ Déploiement "serveur", "poste", "artefact", "installé sur", "connexion réseau"

→ Démarche "besoins", "analyse", "conception", "itératif", "cas d'utilisation"

💎 Formule de Succès

🏆 La Méthode R.A.C.E.

RRead — Lis l'énoncé 2 fois minimum
AAnalyse — Surligne acteurs/classes/verbes/conditions
CConstruis — Dessine étape par étape (brouillon d'abord!)
EExamine — Vérifie cohérence, multiplicités, flèches

Le Guide Ultimedes Diagrammes UML

Démarche UML

Cas d'Utilisation

Diagramme de Classes

Diagramme de Séquence

Diag. de Communication

États-Transitions

Diagramme d'Activités

Composants & Déploiement

🌍 C'est quoi UML ?

🤔 Imagine que tu construis une maison...

📊 Diagrammes Statiques

🎬 Diagrammes Dynamiques

🏗️ Le Système d'Information (SI)

Donnée vs Information

📜 Les 3 générations de méthodes de conception

🧭 La Démarche de Modélisation avec UML

🚨 Idée fausse à corriger : UML n'est PAS une méthode

✅ UML = le langage

🧭 Méthode = le chemin

🏛️ Les 3 principes d'une méthode basée sur UML

🧱 La Méthode Archi-Minimale (le minimum vital)

🧑‍🍳 Les 3 Types de Classes d'Analyse

🔄 Ce que chaque diagramme produit dans la démarche

👤 Diagramme de Cas d'Utilisation

📖 C'est quoi ?

🧩 Les 4 Composants

1. Le Système (le rectangle)

2. Les Acteurs (les bonhommes)

3. Les Cas d'Utilisation (les ellipses)

4. Les Relations

🎯 Include vs Extend — La Confusion #1

✅ «include» (toujours)

🔶 «extend» (parfois)

📝 Comment Construire un Diagramme de Cas d'Utilisation (Pas à Pas)

🔍 Comment Analyser un Énoncé (Exemple TD1)

🔎 Analyse mot par mot :

⚖️ Règles de Cohérence (Erreurs à ne PAS faire)

📄 Description Textuelle d'un Cas d'Utilisation

🧱 Diagramme de Classes

📖 C'est quoi ?

📦 Comment dessiner une Classe

Visibilité des attributs/opérations

🔗 Les Associations (les liens entre classes)

Association Simple

⭐ Les Multiplicités (SUPER IMPORTANT)

💎 Agrégation vs Composition

◇ Agrégation (losange VIDE)

◆ Composition (losange PLEIN)

🧬 Héritage (Généralisation / Spécialisation)

🎓 Concepts Avancés

🔨 Comment Construire un Diagramme de Classes (Pas à Pas)

🔄 Diagramme de Séquence

📖 C'est quoi ?

🧩 Les Composants

Les Participants

✉️ Les Types de Messages

🏗️ Les Fragments Combinés (Structures de contrôle)

🔀 alt (si...sinon)

🔁 loop (boucle)

❓ opt (optionnel)

📌 ref (référence)

🔨 Comment Construire un Diagramme de Séquence (Pas à Pas)

🔍 Analyse d'Exercice (TD3 — ChampionnatEchecs)

🔗 Diagramme de Communication

📖 C'est quoi ?

✍️ Syntaxe des Messages

⚔️ Séquence vs Communication — Quand utiliser quoi ?

📊 Diagramme de Séquence

🔗 Diagramme de Communication

🚦 Diagramme d'États-Transitions

📖 C'est quoi ?

🧩 Les Éléments de Base

⚡ Les Événements Déclencheurs

🏠 Transitions Internes : entry, do, exit

Transition externe

Transition interne

🧠 États Avancés

🔨 Comment Construire un Diagramme d'États (Pas à Pas)

🛤️ Diagramme d'Activités

Le Guide Ultime
des Diagrammes UML