Introduction

---

Aperçu

UML 2.0 organise les diagrammes en deux catégories principales:

Catégorie	Objectif
Diagrammes structuraux	Capturer l’organisation physique des éléments — la manière dont les objets sont liés entre eux
Diagrammes comportementaux	Se concentrer sur la manière dont les éléments interagissent, changent d’état et traitent le comportement au fil du temps

💡 Principe clé: Un modèle UML se compose d’un ou plusieurs diagrammes. Chaque diagramme représente un aspect particulier vue ou intérêt dans le système modélisé. Les éléments individuels apparaissent souvent sur plusieurs diagrammes.

---

🔷 Diagrammes structuraux

Les diagrammes structuraux modélisent l’architecture statique de votre système — le « quoi » plutôt que le « comment ».

1. Diagrammes de classes

Objectif: Les classes de modèle, les interfaces et leurs relations statiques.

Éléments clés:

• Classes avec attributs et opérations

• Interfaces et relations de réalisation

• Associations, agrégations, compositions et généralisations

• Modificateurs de visibilité (+, -, #, ~)

• Spécifications de multiplicité (1, 0..*, 1..5)

Exemple d’utilisation:Quand l’utiliser:

Stéréotypes et types de classe

Le diagramme utilise des stéréotypes (indiqués par du texte entre des crochets angulaires, comme <<entité>>) pour catégoriser le rôle de chaque classe :

• Classes de limite (<<limite>>): Elles gèrent l’interaction entre le système et ses acteurs (utilisateurs ou systèmes externes).

• Exemples : ConsoleWindow et BoiteDeDialogue.

• Classes de contrôle (<<contrôle>>): Elles gèrent la coordination, les transactions et le flux de logique métier de l’application.

• Exemples : ContexteDeDessin et ContrôleurDeDonnées.

• Classes d’entité (<<entité>>): Elles représentent les données fondamentales ou les informations persistantes que le système suit.

• Exemples : Cadre, Fenêtre, Événement, Forme, Cercle, Rectangle, Polygone, et Point.

• Classe abstraite : Le Forme la classe représente un concept abstrait. Elle sert de modèle de base pour des formes spécifiques et ne peut pas être instanciée directement par elle-même.

---

Anatomie d’une classe

Une boîte de classe UML standard est divisée en compartiments. En regardant la Cercle classe comme exemple :

• Nom de la classe : Situé dans le compartiment supérieur (Cercle).

• Attributs : Situé dans le compartiment central, représentant les champs de données.

• -rayon : flottant (Le signe moins - indique un attribut privé).

• -centre : entier non signé

• Opérations (méthodes) : Situé dans le compartiment inférieur, représentant les comportements ou les fonctions.

• +aire(rayon en : float) : double (Le signe plus + indique une méthode publique).

• +circonf(), +definirCentre(), et +definirRayon().

---

Relations et liens

Les lignes et les flèches reliant les classes définissent la manière dont elles interagissent et dépendent les unes des autres :

Généralisation (Héritage)

Représenté par une ligne pleine avec une flèche creuse pointant vers la classe parente. Cela indique une relation « est-un » où une classe fille hérite des attributs et des comportements d’une classe parente.

• Fenêtre hérite de Cadre.

• FenêtreConsole et BoîteDialogue héritent de Fenêtre.

• Cercle, Rectangle, et Polygone héritent de la classe abstraite Forme (par exemple, un Cercle est une Forme).

Agrégation

Représentée par une ligne pleine avec un diamant creux à l’extrémité du conteneur. Cela indique une relation « possède-un » lâche ou une relation tout-partie où l’enfant peut exister indépendamment du parent.

• Fenêtre agrège Forme (multiplicité 1 à *). Une Fenêtre peut contenir plusieurs (*) formes, mais si la fenêtre est fermée, les formes elles-mêmes peuvent encore exister conceptuellement en mémoire ou dans un autre contexte.

Composition

Représentée par une ligne pleine avec un diamant plein (noir) à l’extrémité du conteneur. Cela indique une relation « possède-un » forte avec une durée de vie coïncidente : si le conteneur est détruit, les parties sont également détruites.

• Cercle est composé de Point objets (multiplicité 1 vers *). Un cercle ne peut exister sans son centre ni ses points frontières ; détruire le cercle détruit ces références spécifiques aux points.

Dépendance

Représenté par un flèche pointillée. Cela montre qu’une classe dépend d’une autre, ce qui signifie qu’un changement dans la classe cible peut affecter la classe source.

• Fenêtre dépend de Événement (indiqué par la flèche pointillée qui pointe vers Événement). La fenêtre dépend des déclencheurs d’événements pour exécuter des opérations telles que handleEvent().

Association

Représenté par une simple ligne pleine. Cela indique une relation structurelle où les objets d’une classe sont connectés aux objets d’une autre.

• Boîte de dialogue est associé à ContrôleurDeDonnées, ce qui signifie qu’ils communiquent entre eux pour échanger des informations ou coordonner leur comportement.

---

Éléments de documentation

• Note : Le diagramme présente une boîte de note avec un coin plié relié par une ligne pointillée à la Fenêtre classe. Elle fournit un contexte lisible par l’humain :« La fenêtre principale de l’application. »

• Concevoir une architecture logicielle orientée objet

• Documenter les modèles de domaine

• Génération des squelettes de code

---

2. Diagrammes de composants

Objectif: Montrer l’organisation et les dépendances des unités d’implémentation.

Éléments clés:

• Composants (stéréotypés comme «composant»)

• Interfaces fournies/requises (notation balle-et-socket)

• Connecteurs d’assemblage et relations de dépendance

• Artifacts (sorties compilées : JAR, DLL, exécutables)

Utilisation exemplaire:Quand l’utiliser:

Composants et limites modulaires

Au cœur du diagramme se trouve le concept de composant, une unité autonome et modulaire d’un système qui encapsule ses contenus et manifeste son comportement à travers des interfaces claires. La grande frontière extérieure représente l’ensemble du Terminal composant, qui agit comme un sous-système ou un conteneur. À l’intérieur de ce conteneur se trouvent des composants internes plus petits et spécialisés — à savoir InspectionSécurité, Personnel, Défaut, et Carte. Chacune de ces unités internes représente une partie modulaire de logiciel ou de logique de gestion des données qui travaille ensemble pour remplir les responsabilités du Terminal.

Interfaces comme contrats

Les composants n’exposent pas directement leur logique interne ; ils interagissent au contraire via des interfaces bien définies qui servent de contrats architecturaux.

• Interfaces fournies : Représentées par un symbole « bonbon » ou un cercle, ces interfaces indiquent les services, données ou opérations qu’un composant implémente et met à disposition de son environnement. Par exemple, le composant Terminal externe expose des interfaces fournies externes telles que État, Détails, et Élément d’inspection, indiquant ce que les clients externes peuvent demander à ce composant.

• Interfaces requises : Représentées par un symbole « prise » ou un demi-cercle, ces interfaces spécifient les services ou données dont un composant a besoin d’une autre entité pour fonctionner correctement. Du côté droit du diagramme, le composant Terminal expose explicitement des interfaces requises pour Compte et ID d’inspection, montrant ses dépendances vis-à-vis de sous-systèmes externes.

Ports et câblage interne

Pour gérer le flux de données et de contrôle tout en préservant l’encapsulation, le système utilise des ports et des relations de délégation.

• Ports : Les petits carrés situés sur la frontière des composants représentent des ports. Ils agissent comme des points d’interaction distincts par lesquels la structure interne du composant se connecte au monde extérieur. Les ports permettent au composant d’isoler son câblage interne de l’environnement externe, ce qui signifie que les composants internes peuvent être remplacés ou modifiés sans modifier l’apparence du composant parent aux yeux de l’extérieur.

• Délégation et assemblage : À l’intérieur du Terminal, des lignes relient ces interfaces pour former l’assemblage structurel. Une interface fournie sur le port externe délègue directement les requêtes entrantes à une interface fournie du composant interne (comme cela apparaît avec les chemins État et Détails menant vers InspectionSécurité). À l’inverse, les composants internes connectent leurs interfaces de prise requises directement aux interfaces de type « bonbon » fournies des composants voisins. Par exemple, le composant InspectionSécurité dépend de l’interface Inspecteur fournie par Personnel, le Détails du défaut interface fournie par Défaut, et la Emplacement interface fournie par Carte, créant un écosystème interne étroitement coordonné mais faiblement couplé.

• Planification de l’architecture système modulaire

• Gestion des dépendances de compilation

• Documentation des bibliothèques de composants réutilisables

---

3. Diagrammes de structure composite(Ajouté dans UML 2.0)

Éléments clés:

• Parts (propriétés avec des relations tout-partie)

• Ports (points d’interaction avec des interfaces fournies/requises)

• Connecteurs (liens d’exécution entre les parties)

• Occurrences de collaboration

Exemple d’utilisation: Modélisation d’un Véhicule:

Classificateur d’encapsulation (Classe)

Le rectangle extérieur représente le classificateur conteneur, dans ce cas, le Véhicule classe. Dans un diagramme de structure composite, cette frontière agit comme un conteneur qui encapsule la configuration d’exécution interne du système. Elle définit le contexte dans lequel les instances individuelles coopèrent pour atteindre un objectif comportemental plus large, en cachant la complexité du fonctionnement interne d’un « Véhicule » aux entités externes.

Parts (Structure interne)

Les rectangles internes situés à l’intérieur de la limite de la voiture représentent Pièces. Une pièce explique un rôle joué par un ensemble d’instances pendant l’exécution du classificateur conteneur. Plutôt que de montrer une relation statique au moment de la compilation (comme un diagramme de classes standard), ces pièces désignent des instances en cours d’exécution qui remplissent des emplacements architecturaux spécifiques :

• -t : Transmission: Une instance jouant le rôle du système de transmission.

• -e : Moteur: Une instance jouant le rôle de la source d’énergie du moteur.

• -s : Système de direction: Une instance jouant le rôle du mécanisme de direction.

La notation deux-points indique que ce sont des rôles structurels typés par leurs classes respectives, définissant exactement quels composants doivent exister à l’intérieur d’une voiture opérationnelle.

Ports et limites

Les petits carrés intégrés à la fois à la limite externe du classificateur et aux limites des pièces internes représentent Ports. Les ports sont des points d’interaction distincts qui déconnectent la structure interne d’un classificateur de son environnement externe.

• Les ports externes sur la limite de la voiture—tels que : Roue, : Levier d'accélérateur, et : Volant—montrent comment la voiture interagit avec le monde extérieur ou l’environnement physique sans révéler lesquellespièces internes gèrent ces interactions.

• Les ports des pièces internes (comme les ports des blocs de transmission ou de moteur) régissent la manière dont ces sous-systèmes communiquent entre eux ou avec la limite parente.

Connecteurs et câblage interne

Les lignes pleines reliant les ports entre eux représentent Connecteurs. Les connecteurs définissent les voies de communication entre les pièces ou entre une pièce et un port externe au moment de l’exécution.

• Connecteurs de délégation : Connectent directement un port externe du conteneur à un port interne d’une pièce. Par exemple, le port externe : Roue le port est directement connecté au Boîte de vitesses, et le : Volant est directement connecté au Système de direction. Cela garantit que les stimuli externes sont correctement et sans interruption attribués au bon acteur interne.

• Connecteurs d’assemblage : Connecte les composants internes pour permettre la collaboration. Le connecteur entre le Boîte de vitesses et le Moteur montre que ces deux rôles d’exécution distincts échangent directement des signaux, des données ou une force mécanique pour permettre au véhicule de fonctionner comme un tout unifié.

Quand l’utiliser:

• Documenter les modèles de conception

• Modélisation de collaborations internes complexes

• Ponctuer la conception de classes et l’implémentation des composants

---

4. Diagrammes de déploiement

Objectif: Cartographier les artefacts logiciels aux environnements d’exécution matériels.

Éléments clés:

• Nœuds (périphériques, environnements d’exécution)

• Artéfacts (unités déployables)

• Chemins de communication entre les nœuds

• Spécifications de déploiement (détails de configuration)

Exemple d’utilisation:Quand l’utiliser:

Nœuds et infrastructure physique

Contrairement aux diagrammes de conception logique qui modélisent la disposition du code ou les structures de classes, un diagramme de déploiement se concentre sur la topographie matérielle. Les principaux éléments de construction sontNœuds, qui sont représentés visuellement sous forme de cubes tridimensionnels. Les nœuds illustrent les ressources informatiques physiques ou les environnements d’exécution où les éléments logiciels fonctionnent réellement :

• <<processeur>> Nœuds : Cubes stéréotypés avec <<processeur>> (tels que Serveur de mise en cache, Serveur principal, et des blocs génériques Serveur blocs) représentent des nœuds dotés de capacité de calcul, de mémoire et de puissance de traitement capables d’exécuter des binaires logiciels.

• <<réseau>> Nœuds : Le cube allongé étiqueté Réseau local représente un chemin de communication ou une infrastructure de routage plutôt qu’un ordinateur individuel. Il symbolise le squelette physique qui permet aux processeurs connectés d’échanger des flux de paquets de données.

• Nœuds périphériques : Des nœuds non stéréotypés tels que Internet et Banc de modems représentent des composants matériels de bordure ou des infrastructures physiques externes nécessaires pour acheminer le trafic externe vers l’environnement central du système.

Associations et voies de communication

Les lignes pleines reliant les cubes tridimensionnels représententAssociations. Dans un diagramme de déploiement, ces associations définissent les chemins de communication physique, les liens réseau ou les connexions matériels entre les nœuds.

• La ligne entre Internet et Modem Bankillustre le point d’entrée des données publiques externes dans la pile matérielle.

• L’association s’étendant depuis le Modem Bank vers le bas jusqu’au Serveur de mise en cachedéfinit le routage physique du trafic entrant jusqu’à la couche de mise en cache périphérique.

• Associations reliant les Serveurs de mise en cache et le Serveur principal cluster au Réseau localétablissent la manière dont les composants internes communiquent via une infrastructure partagée de bus local à haute vitesse ou d’interrupteur réseau.

Empilement topologique et redondance

Le disposition des nœuds dans le diagramme montre explicitement la topologie de déploiement et les choix architecturaux pour une haute disponibilité et une répartition de charge.

• Couche de mise en cache périphérique : Situés directement en dessous du matériel du modem d’entrée se trouvent deux nœuds distincts et parallèles Serveur de mise en cachenœuds. Cette configuration montre visuellement une couche périphérique redondante conçue pour répartir la charge du trafic entrant et mettre en cache les ressources avant que les requêtes n’atteignent l’infrastructure profonde.

• Ferme de serveurs interne : Situé au fond de la pile, connecté via le Réseau local, se trouve un cluster de serveurs centraux. La distinction entre le Serveur principal et le générique adjacent Serveur les nœuds représentent visuellement une architecture maître-réplica ou primaire-secondaire, garantissant que la persistance des données et les charges de calcul importantes sont coordonnées en toute sécurité dans l’environnement du centre de données interne.

Objectif: Modéliser la structure interne des classificateurs et des motifs complexes.

• Planification de l’infrastructure du système

• Documentation des architectures distribuées

• Définition des stratégies de basculement et de redondance

---

5. Diagrammes de paquetages

Objectif: Organiser et gérer les espaces de noms par regroupement logique.

Éléments clés:

• Paquetages (rectangles avec onglets)

• Relations d’importation/acces («importer», «accéder»)

• Relations de fusion («fusionner»)

• Visibilité (+ public, - privé)

Exemple d’utilisation:

Frontières des sous-systèmes et des paquetages

Le diagramme s’appuie fortement sur la notation « dossier » pour représenter des regroupements logiques d’éléments de conception.

• Sous-système : Le grand dossier externe stylisé comme <<sous-système>> Gestion des commandes représente une unité comportementale majeure et encapsulée du système physique. Il agit comme un conteneur de haut niveau qui regroupe les composants et les paquets connexes nécessaires à l’exécution de la gestion des commandes.

• Paquet : Les petits dossiers à l’intérieur et à l’extérieur du sous-système (tels que UI, Traitement des commandes, et GestionnaireGUI) sont des paquets standards. Ils servent à organiser les éléments en groupes gérables, à établir des espaces de noms et à définir les limites de visibilité au sein de l’architecture.

Dépendances et stratification

Les flèches pointillées indiquent Dépendances, établissant qu’un changement dans un paquet (la cible) peut affecter le fonctionnement du paquet d’origine (la source).

• Dépendances internes : Dans le sous-système de gestion des commandes, une stratification architecturale claire de haut en bas est visible. Le UI dépend du paquet Traitement des commandes, qui à son tour dépend du Calculateur de prix et Stockage externe. Cela représente un flux architectural où les éléments de présentation de haut niveau dépendent des couches logiques métier fondamentales et des couches d’accès aux données.

• Dépendance sur un paquet externe : Les paquets peuvent également dépendre d’éléments situés au-delà de leurs limites immédiates de sous-système. Par exemple, le UI le package dépend de l’extérieur GestionnaireGUI. De même, le Stockage aléatoire et Stockage en flux les packages en bas franchissent la frontière du sous-système pour dépendre de structures de données externes, mettant en évidence la manière dont le sous-système s’intègre dans un écosystème logiciel plus large.

Abstraction et héritage (généralisation)

Le diagramme utilise un style particulier et des flèches de relation pour démontrer des modèles de conception abstraits appliqués à une architecture modulaire.

• Packages abstraits vs. concrets : Les packages contenant des éléments abstraits ou définissant une structure similaire à une interface sont représentés par des noms en italique (tels que Stockage externe et Gestion du stockage). À l’inverse, les packages contenant des implémentations de code opérationnel, comme Référentiel et Stockage de fichiers, utilisent un texte standard pour indiquer qu’il s’agit de packages concrets.

• Généralisation : Représenté par une ligne pleine avec un triangle ouvert et creux pointant vers le package parent. Cela indique une relation d’héritage ou d’implémentation. À l’intérieur du sous-système, Stockage aléatoire et Stockage en flux spécialisent ou implémentent l’interface abstraite Stockage externe interface. À l’extérieur du sous-système, les packages concrets Référentiel et Stockage de fichiers les paquets généralisent vers l’abstrait Gestion du stockage paquet, montrant comment le comportement polymorphe et la classification structurelle peuvent être modélisés au niveau du paquet.

  

• Quand l’utiliser:

• Gestion de grands bases de code

• Définition des limites des modules

• Contrôle des dépendances de compilation

---

6. Diagrammes d’objets

Objectif: Montrer des instantanés d’instances et de leurs liens à un moment donné.

Éléments clés:

• Objets (noms soulignés : maVoiture:Voiture)

• Liens entre les instances d’objets

• Valeurs des attributs à l’exécution

Exemple d’utilisation:

Objets et instances concrètes

Contrairement aux diagrammes de classes qui montrent des configurations abstraites au niveau de plan, un diagramme d’objets capture des instances réelles vivant en mémoire. Les objets sont représentés par des rectangles, et leurs noms sont toujours soulignés pour indiquer l’instanciation.

• Objets nommés : Ils suivent la syntaxe nomInstance : NomClasse. Par exemple, c : Société représente une instance spécifique de société nommée « c », et p : Personne représente une instance spécifique d’individu nommée « p ».

• Objets anonymes : Lorsque l’identificateur spécifique de l’instance est omis ou sans importance dans le scénario, seul le nom de la classe est fourni, précédé d’un deux-points (par exemple, : InformationContact). Cela indique qu’une instance concrète d’information de contact existe et est attachée à la structure, mais qu’elle n’a pas besoin d’un nom de variable unique dans ce contexte.

État et valeurs des attributs

Le compartiment inférieur d’un rectangle d’objet contient son état spécifique, défini par des valeurs explicites attribuées à ses attributs à un moment donné. Plutôt que de simplement lister les types de données, ces entrées utilisent le format d’affectation attribut = valeur pour refléter la réalité :

• L’instance département d1 possède la valeur d’attribut nom = Ventes.

• Une autre instance distincte de département d2 possède la valeur nom = Recherche et développement.

• L’instance personne p possède un ensemble complet de données d’état, décrivant un profil spécifique : nom = Derek, IDemployé = D-12821, et titre = Responsable.

Liens et relations

Les lignes pleines reliant les objets représentent Liens. Un lien est une instance concrète d’une association définie entre des classes. Si un diagramme de classes indique que les entreprises ont des départements, le diagramme d’objets montre les connexions réelles au moment de l’exécution entre eux.

• L’instance entreprise c est actuellement lié aux instances de départements d1 (Ventes) et d2 (Recherche et développement).

• Le diagramme montre également une connexion hiérarchique d’instances, où d1 : Département (Ventes) est lié à une instance de sous-département également typée comme Département (nom = Ventes États-Unis).

• Enfin, l’instance personne p (Derek) est lié à l’instance du département Ventes États-Unis, tout en maintenant une connexion à une instance anonyme : Informations de contact contenant son adresse physique.

Quand l’utiliser:

• Valider les conceptions de diagrammes de classes

• Déboguer des relations d’objets complexes

• Montrer des états d’exécution d’exemple

---

🔶 Diagrammes comportementaux

Les diagrammes comportementaux modélisent les aspects dynamiques—comment le système se comporte au fil du temps.

7. Diagrammes d’activité

Objectif: Modéliser les flux de travail, les processus métiers et la logique algorithmique.

Éléments clés:

• Actions (rectangles arrondies)

• Nœuds de contrôle : initial, décision, fusion, division, jonction, final

• Nœuds d’objet et broches

• Partitions (nageoires) pour l’affectation des responsabilités

• Gestionnaires d’exceptions et régions interrompables

Exemple d’utilisation: Flux de traitement de commande

Organisation structurelle (nageoires et partitions)

Le diagramme est organisé verticalement en grandes colonnes connues indifféremment sous le nom deNageoires ou Partitions. Ces limites catégorisent les responsabilités des actions qu’elles contiennent, en associant chaque étape à un rôle ou une unité commerciale spécifique :

• Interface client vente : Gère le cycle de vie orienté client, en gérant l’initialisation du client, le routage alternatif et la présentation finale.

• Propriétaire de la proposition : Gère la planification centrale, l’analyse opérationnelle et la compilation des structures de données formelles de la proposition.

• Propriétaire du devis : Se concentre exclusivement sur l’évaluation financière et la préparation des métriques spécifiques du devis.

Flux de contrôle et états d’action

L’exécution procédurale étape par étape est dirigée par des nœuds de contrôle et des voies orientées.

• Nœud initial : Représenté par le cercle noir plein en haut, il indique le point de départ de tout le flux de travail d’activité.

• Action : Les rectangles arrondis (par exemple, Initialiser le contact, Rechercher une alternative, et Compiler des informations supplémentaires) représentent des étapes ou des tâches simples et non décomposables au sein de la séquence d’exécution.

• Flux de contrôle : Les flèches pleines reliant les éléments dictent la progression séquentielle du flux de travail, indiquant exactement quelle action doit être terminée avant que la suivante ne commence.

• Nœud final d’activité : Le symbole de cible (un cercle plein à l’intérieur d’un anneau creux) en bas marque le point de terminaison absolu de toute l’exécution du processus.

Acheminement et logique protégée (nœuds de décision)

Les symboles en losange représententnœuds de décision, qui modélisent le branchement conditionnel dans le flux de travail.

• Les chemins de contrôle entrants sont divisés en plusieurs chemins sortants mutuellement exclusifs en fonction d’entrées spécifiques.

• Les conditions qui déterminent le chemin à suivre sont encadrées par des crochets, appelées conditions de garde (telles que[accepté], [rejeté], et[rejoindre avec un autre fournisseur ou modifier les exigences]). Le processus évalue ces conditions de garde en temps réel pour acheminer l’exécution vers le chemin fonctionnel approprié.

Traitement parallèle (nœuds de séparation et de réunion)

Les barres noires pleines du diagramme agissent comme des points de synchronisation pour gérer les flux d’exécution concurrents ou parallèles.

• Nœud de séparation (marqué comme nœud de flux dans la légende du diagramme) : Un seul flux de contrôle entrant atteint la barre et se divise en plusieurs threads d’exécution indépendants et concurrents. Ici, après la création du plan de projet, le processus se sépare pour permettre au propriétaire de la proposition d’exécuter l’analyse et la planification de livraison, tandis que le propriétaire du devis gère simultanément la préparation du devis.

• Nœud de réunion : Une barre de synchronisation qui fusionne plusieurs chemins concurrents en un seul flux de contrôle. Le processus ne peut pas passer au-delà du nœud de réunion tant quetous les flux parallèles entrants n’ont pas tous atteint avec succès la barre, garantissant que la compilation du devis et la rédaction de la proposition sont entièrement finalisées avant de passer à la compilation du paquet final.

Intégration des données (nœuds d’objet)

Les rectangles standards indiquentnœuds d’objet, qui introduisent un flux de données dans le diagramme d’activité orienté vers le contrôle.

• Les nœuds d’objet représentent des instances de données spécifiques ou d’artefacts physiques produits ou consommés par des actions, en utilisant lenomInstance : ClasseName convention (par exemple, uneProposition : Proposition et unPlan : Plan de livraison du projet).

• Explicitement marqué créer les flèches indiquent exactement quand une action instancie ou met à jour une structure de données, montrant ainsi le flux des données d’une tâche à l’autre, parallèlement à l’exécution opérationnelle.

Quand l’utiliser:

• Documenter les processus métiers

• Modélisation des réalisations de cas d’utilisation

• Spécifier des algorithmes complexes

---

8. Diagrammes d’états (Statecharts)

Objectif: Modéliser le cycle de vie et le comportement dépendant de l’état des objets.

Éléments clés:

• États (rectangles arrondis avec activités d’entrée/sortie/pendant)

• Transitions (déclencheur[garde]/effet)

• Pseudostates : initial, choix, séparation, fusion, historique, terminer

• États composés et régions orthogonales

Exemple d’utilisation: configuration téléphonique

États et conditions du système

Le diagramme capture le comportement d’un système—plus précisément une configuration téléphonique—en cartographiant ses diverses situations ou conditions discrètes.

• États : Les rectangles arrondis représentent des états (par exemple, Inactif, Tonalité, Saisie, Connexion, et Connecté). Un état représente une période dans le cycle de vie d’un objet pendant laquelle il satisfait une condition, exécute une activité ou attend un événement.

• État pseudo initial : Le cercle plein noir à gauche représente le point de départ de la machine à états. Il s’agit d’un état pseudo et non d’un véritable état, servant uniquement de repère vers l’état actif par défaut au moment de l’instanciation de l’objet (Inactif).

• État final : Le symbole de cible à droite représente la terminaison de l’exécution de la machine à états, indiquant que l’objet a terminé son cycle de vie.

Transitions et routage déclenché par événement

Les lignes orientées reliant les états sont Transitions, qui représentent le passage d’un état à un autre en réponse à un déclencheur spécifique.

• Transitions standards : Déclenchées par des événements spécifiques, tels qu’une action utilisateur ou une réponse système, indiqués le long des lignes. Par exemple, passer de Inactif à Tonalité se produit lorsque l’événement onHook est déclenché, et passer de Tonalité à Saisie se produit lorsque chiffre(n) un événement est reçu.

• Transitions auto : Une flèche de transition qui part d’un état et revient directement à ce même état (comme visible sur l’Composition état avec le chiffre(n) déclencheur). Cela indique que l’événement est traité et met à jour le contexte d’état interne (par exemple, enregistrer un nouveau chiffre composé) sans faire sortir l’objet de son état opérationnel global ou le faire changer d’état.

Chemins alternatifs et gestion des erreurs

Les machines à états excellent à montrer la logique comportementale et le branchement d’erreurs en fonction des conditions variables pendant l’exécution.

• Chemin d’exécution réussi : Le pipeline horizontal central trace le chemin optimal :Inactif $rightarrow$ Tonalité de composition $rightarrow$ Composition $rightarrow$ Connexion $rightarrow$ Sonnerie $rightarrow$ Connecté $rightarrow$ Déconnecté.

• États de gestion des exceptions et des erreurs : Le système prend en compte les échecs ou les retards en effectuant un branchement vers des états dédiés à la gestion. Si un numéro est occupé pendant la connexion, le système déclenche l’numéroOccupé transition pour entrer dans le Tonalité occupée état. Si un utilisateur s’arrête trop longtemps pendant le dialing, un délai d'attente événement fait passer le système dans un Avertissement ou Délai d’attente état. Si une séquence incorrecte est détectée, un numéro invalide déclencheur fait passer le système dans un Message enregistré état, garantissant que le système gère en toute sécurité toutes les situations extrêmes du monde réel.

 

Quand l’utiliser:

• Modélisation des systèmes embarqués ou des implémentations de protocoles

• Définition de la gestion des états de l’interface utilisateur

• Documentation des règles du cycle de vie des objets

---

9. Diagrammes d’interaction

Quatre types de diagrammes mettent en évidence différents aspects de la collaboration entre objets :

a) Diagrammes de séquence (Le plus courant)

Objectif: Montrer les échanges de messages ordonnés dans le temps entre les lignes de vie.

Éléments clés:

• Lignes de vie (lignes pointillées verticales)

• Messages (flèches pleines ou pointillées avec étiquettes)

• Occurrences d’exécution (barres d’activation)

• Fragments combinés : alt, opt, boucle, par, interrompre

Exemple d’utilisation:

Lignes de vie et contextes d’exécution

Le diagramme se lit de gauche à droite pour établir les participants, et de haut en bas pour indiquer le passage du temps.

• Lignes de vie : Les boîtes situées en haut, attachées à des lignes verticales pointillées, représentent les lignes de vie. Elles modélisent les participants individuels dans l’interaction, selon la convention nomInstance : NomClasse (par exemple, fenêtre : UI, aChaîne : ChaîneHôtelière, et aHôtel : Hôtel). La ligne pointillée suit l’existence de ce participant tout au long de la séquence.

• Barres d’activation : Les minces rectangles verticaux colorés posés au-dessus des lignes de vie indiquent une activation (ou occurrence d’exécution). Ces barres montrent précisément quand un objet est en cours d’exécution d’une opération ou en attente de la fin d’un appel imbriqué.

• Arrêté : Le grand symbole « X » situé en bas de la fenêtre : UI La ligne de vie indique une destruction ou une terminaison, montrant que le cycle de vie de ce participant spécifique est terminé et que ses ressources sont libérées.

Types de messages et communication

La communication entre les participants est modélisée à l’aide de flèches horizontales représentant des messages, ordonnées séquentiellement à l’aide d’un système de numérotation hiérarchique (par exemple, 1, 1.1, 1.1.1).

• Messages synchrones : Des lignes pleines avec des flèches pleines (comme 1 : makeReservation et 1.1 : makeReservation) indiquent des appels synchrones. L’expéditeur bloque l’exécution et attend que l’objet récepteur termine son traitement.

• Messages self : Une boucle de message qui commence et se termine sur la même barre d’activation (par exemple, 1.1.1 : available(roomId, date) : isRoom exécuté par aHotel) représente un message self. Cela indique une exécution de méthode interne où un objet appelle l’une de ses propres opérations.

• Messages de création : Une ligne pointillée avec une flèche ouverte pointant directement vers une boîte d’objet (par exemple, le message 1.1.2: pointant vers aReservation : Reservation) représente la création d’un objet. Cela montre que l’instance aHotel instancie dynamiquement l’objet aReservation à cet instant précis dans la séquence d’exécution.

Fragments combinés et flux de contrôle

De grandes boîtes rectangulaires entourant des sections de la séquence sont des fragments combinés, qui utilisent des opérateurs d’interaction pour gérer la logique complexe, les branches et les itérations.

• Fragment de boucle : La boîte externe étiquetée boucle avec la condition de garde [chaque jour] représente une itération. Toutes les interactions contenues dans cette boîte se répéteront continuellement pour chaque jour spécifié dans la demande de réservation.

• Fragment combiné alternatif (Alt) : Intégré à l’intérieur de la boucle se trouve un alt fragment (annoté comme « Si » dans la flèche du diagramme), qui gère le branchement conditionnel. Il évalue la condition de garde [isRoom = true]. Si la condition est remplie, la séquence exécute le chemin spécifique à l’intérieur de ce bloc — créant l’instance aReservation et déclenchant ultérieurement le message 2: pour instancier aNotice : Confirmation. Si la condition était fausse, un chemin alternatif (ou aucune action) serait suivi.

  

b) Diagrammes de communication

Objectif: Mettre l’accent sur les relations entre objets plutôt que sur le moment des messages.

Éléments clés:

• Objets comme nœuds

• Liens avec des messages numérotés et orientés

• Focus sur « qui parle à qui »

c) Diagrammes d’aperçu d’interaction

Objectif: Flux de contrôle de haut niveau utilisant la notation des diagrammes d’activité.

Éléments clés:

• Occurrences d’interaction comme nœuds d’activité

• Décision/fusion pour le branchement

• Fork/join pour le parallélisme

d) Diagrammes de temporisation

Objectif: Modéliser des contraintes de temporisation précises (systèmes temps réel).

Éléments clés:

• Chronogrammes d’état pour chaque ligne de vie

• Échelles de temps et contraintes

• Flèches de message avec des indicateurs de durée

Quand utiliser les interactions:

• Spécification des réalisations de cas d’utilisation

• Débogage des flux de messages complexes

• Documentation des modèles d’utilisation d’API

• Modélisation du temporisation des protocoles temps réel

---

10. Diagrammes de cas d’utilisation

Objectif: Capturer les exigences fonctionnelles du point de vue d’un acteur externe.

Éléments clés:

• Cas d’utilisation (ovales ou rectangles de classificateur)

• Acteurs (figures en bâton ou classificateurs)

• Associations (acteur ↔ cas d’utilisation)

• Relations :«include», «étendre», généralisation

• Boîte de limite du système

Exemple d’utilisation: Système de guichet automatique

Quand l’utiliser:

• Recueil des exigences avec les parties prenantes

• Définition du périmètre et des limites du système

• Planification des scénarios de test

---

🎯 Choisir le bon diagramme : guide de décision

Objectif	Diagramme(s) recommandé(s)
Concevoir la structure de classe	Classe, Objet, Package
Modéliser les interactions en cours d’exécution	Séquence, Communication
Documenter les flux métier	Activité, Cas d’utilisation
Préciser le cycle de vie de l’objet	Machine à états
Planifier le déploiement du système	Déploiement, Composant
Modéliser des schémas internes complexes	Structure composite
Capturer les contraintes en temps réel	Diagramme de timing
Définir les exigences	Cas d’utilisation, Activité

---

🔑 Principes fondamentaux de modélisation

1. Commencez simplement: Commencez par le type de diagramme qui correspond le mieux à votre objectif immédiat.

2. Itérez: Affinez les modèles au fur et à mesure que la compréhension s’approfondit — aucun diagramme n’est « final » dès le premier jet.

3. Le public compte: Ajustez le niveau de détail en fonction des lecteurs (développeurs contre parties prenantes).

4. Combinez les points de vue: Utilisez plusieurs diagrammes pour raconter une histoire complète (par exemple, Cas d’utilisation → Séquence → Classe).

5. Étendez avec soin: Utilisez les stéréotypes, les valeurs étiquetées et les profils pour des besoins spécifiques au domaine, mais documentez les conventions.

6. Gardez-le lisible: Omettez les détails non pertinents ; utilisez des notes pour un contexte complémentaire.

📌 Souvenez-vous: « UML est un langage, pas une méthodologie. » Il fournit une notation — pas de processus. Choisissez les diagrammes qui clarifient la communication, et non ceux qui servent à cocher des cases.

Conclusion