UML

UML est un langage graphique qui permet de représenter un système avant ou pendant sa conception — comme un architecte dessine le plan d'une maison.

Pour construire une maison, on ne pose pas les briques au hasard : on dessine d'abord les plans. Pour construire un logiciel, c'est pareil : on dessine d'abord avec UML. Plusieurs développeurs peuvent ainsi se mettre d'accord avant d'écrire une seule ligne de code.

UML vs langage de programmation

Une classe est un MODÈLE qui décrit un type d'objet. Elle regroupe des données (les attributs) et des actions (les méthodes).

Dans notre université, un Étudiant a un nom, un email et un âge (attributs). Il peut s'inscrire à un cours et consulter ses notes (méthodes). La classe Étudiant décrit TOUT ce que peuvent avoir les étudiants — c'est le modèle général.

Classe vs Objet

Un objet est une INSTANCE concrète d'une classe, à un instant donné. Le nom d'un objet est souligné et s'écrit : nomObjet : Classe.

La classe Étudiant dit 'un étudiant a un nom'. Les objets concrets sont : baba:Étudiant (nom = 'Baba Niang', email = 'baba@univ.edu') et awa:Étudiant (nom = 'Awa Diop', email = 'awa@univ.edu'). On peut créer autant d'objets qu'on veut à partir d'une seule classe.

Classe vs Objet (rappel visuel)

Une ASSOCIATION est un lien simple entre deux classes. On peut y ajouter un RÔLE (le rôle joué par chaque côté) et une MULTIPLICITÉ (combien d'objets sont liés).

Dans l'université : un Étudiant 'suit' des Cours (rôle = 'suit'), et un Cours est 'suivi par' des Étudiants. La multiplicité '1..*' côté Cours signifie qu'un étudiant suit AU MOINS 1 cours. La multiplicité '*' côté Étudiant signifie qu'un cours peut avoir 0 ou plusieurs étudiants.

Les 4 multiplicités à connaître

Au-delà de l'association simple, il existe 3 relations importantes : la GÉNÉRALISATION (héritage), l'AGRÉGATION (contient, faible) et la COMPOSITION (possède, fort).

Dans l'université : (1) GÉNÉRALISATION — Étudiant et Professeur sont des Personne (héritage). (2) AGRÉGATION — l'Université regroupe des Départements (un département peut exister sans l'université). (3) COMPOSITION — l'Université possède ses Bâtiments (pas de bâtiment sans université).

Agrégation ◇ vs Composition ◆

Le diagramme de cas d'utilisation montre les FONCTIONNALITÉS offertes par le système, vues par les ACTEURS (personnes ou systèmes externes).

Dans l'université : l'Étudiant (acteur) peut 'S'inscrire à un cours' et 'Consulter ses notes' (cas d'utilisation). Le Professeur (acteur) peut 'Saisir des notes' et 'Consulter sa classe'. Ces cas d'utilisation sont dans la frontière du système 'Gestion Universitaire'.

include <<include>> vs extend <<extend>>

Le diagramme de SÉQUENCE montre QUI envoie QUEL message à QUI, et dans quel ORDRE (le temps va de haut en bas). Le diagramme de COMMUNICATION montre la même chose mais en mettant l'accent sur la STRUCTURE des objets.

Quand l'étudiant se connecte à l'application universitaire : (1) l'Étudiant envoie 'login(email, mdp)' à l'Application, (2) l'Application envoie 'vérifier(mdp)' à la Base de données, (3) la Base répond 'OK', (4) l'Application affiche 'Bienvenue'. Le temps s'écoule de haut en bas.

Séquence vs Communication

Le diagramme d'ÉTATS montre le CYCLE DE VIE d'un objet (comment il change dans le temps). Le diagramme d'ACTIVITÉS montre un PROCESSUS / workflow (les étapes, dans quel ordre, avec quelles décisions).

Dans l'université : (1) ÉTATS — une Inscription passe de 'En attente' à 'Validée' (si le professeur valide) puis à 'Confirmée' (après paiement), ou à 'Annulée'. (2) ACTIVITÉS — le processus d'inscription : Saisir le formulaire → Vérifier les prérequis → [décision : OK ?] → Payer les frais → Confirmer.

État vs Activité

Les diagrammes d'ARCHITECTURE montrent comment le système est ORGANISÉ : COMPOSANTS (modules logiciels), DÉPLOIEMENT (machines physiques) et PAQUETAGES (regroupements logiques).

Dans l'université : (1) COMPOSANTS — Interface Web, Service Inscription, Base de données, chacun avec un rôle précis. (2) DÉPLOIEMENT — Poste Client (navigateur de l'étudiant) → Serveur Web (Application) → Serveur BD (PostgreSQL). (3) PAQUETAGES — les classes sont regroupées : 'ihm', 'métier', 'accès-données'.

Composant vs Nœud de déploiement

UML a 4 diagrammes plus avancés : la STRUCTURE COMPOSITE (intérieur d'une classe), les PROFILS (extensions UML), la VUE D'ENSEMBLE (combinaison d'interactions) et le TEMPS (chronologie avec contraintes temporelles).

Dans l'université : (1) STRUCTURE COMPOSITE — la classe Université contient 1 Direction, plusieurs Départements, plusieurs Salles. (2) PROFILS — on peut stéréotyper une classe '«service»' pour marquer que c'est une API REST. (3) VUE D'ENSEMBLE — combine plusieurs séquences en une vue globale. (4) TEMPS — montre précisément à quel moment un étudiant reçoit sa confirmation (ex: à t=200ms).

Les 4 diagrammes avancés