Module 1 : Introduction à UML (3h) - ESSENTIEL pour débutants
➢ Qu'est-ce que la modélisation ?
➢ Pourquoi UML ? À quoi ça sert ?
➢ Les différents diagrammes (vue d'ensemble simple)
➢ Outils de modélisation (introduction)
Module 2 : Les diagrammes fondamentaux (22h)
❖ Diagramme de cas d'utilisation (5h) - Le plus simple pour commencer
➢ Identifier les acteurs et les besoins
➢ Exercices pratiques simples
❖ Diagramme de classes (9h) - Le plus important
➢ Notions de classe, attributs, méthodes
➢ Les relations étape par étape
➢ Beaucoup d'exercices
❖ Diagramme de séquence (5h) - Pour comprendre les interactions
➢ Messages entre objets
➢ Scénarios d'utilisation
❖ Diagramme d'activités (3h) - Pour les processus
➢ Flux de travail simple
Module 3 : Mise en pratique (4h)
❖ Projet guidé complet
❖ De l'analyse au code
Module 4 : Révision et évaluation (1h)
MODULE 1 : INTRODUCTION À UML
SÉANCE 1 : LA MODÉLISATION ET SES FONDEMENTS (1h)
Introduction générale
Dans le cadre du développement de systèmes informatiques complexes, la
programmation directe sans phase préalable de conception conduit souvent à des
difficultés majeures. Ces difficultés se manifestent notamment par une mauvaise
organisation du code, des erreurs de conception coûteuses à corriger, et une
communication défaillante au sein des équipes de développement. C'est précisément pour
répondre à ces problématiques que la modélisation logicielle a été développée. Avant
d'aborder le langage UML proprement dit, il convient de bien comprendre ce qu'est la
modélisation et pourquoi elle constitue une étape incontournable dans le processus de
développement logiciel.
Rappels sur les concepts fondamentaux de la Programmation Orientée Objet
Vous avez déjà étudié la programmation orientée objet en C++ lors de votre première
année. Il est donc essentiel de rappeler brièvement les concepts fondamentaux qui
constituent la base de cette approche de programmation, car ces mêmes concepts se
retrouvent au cœur de la modélisation UML.
Le premier concept fondamental est celui de classe. Une classe représente un modèle
abstrait, un plan de construction qui définit la structure et le comportement d'un ensemble
d'objets similaires. En C++, vous avez appris à définir une classe en spécififiant ses
attributs et ses méthodes. Considérons l'exemple suivant d'une classe Etudiant :
Cette classe Etudiant constitue un modèle général qui décrit ce qu'est un étudiant dans
notre système informatique. Elle possède trois attributs privés qui caractérisent l'étudiant,
à savoir son matricule, son nom et son âge. Elle définit également deux méthodes
publiques qui représentent les actions qu'un étudiant peut effectuer : s'inscrire et passer
un examen.
Le deuxième concept clé est celui d'objet. Un objet représente une instance concrète
d'une classe, c'est-à-dire une réalisation particulière du modèle défini par la classe. Si la
classe Etudiant est le plan général, alors chaque étudiant réel dans notre système
constitue un objet distinct de cette classe. Par exemple :
Dans ce code, etud1 est un objet de type Etudiant qui possède ses propres valeurs pour
les attributs nom et age.
Enfin, les méthodes représentent les actions ou comportements que peuvent réaliser les
objets d'une classe. Elles définissent ce que l'objet peut faire ou comment il peut interagir
avec d'autres objets du système. Par exemple :
Pour mieux comprendre ces concepts, on peut utiliser une analogie architecturale. Si une
classe est comparable au plan architectural d'une maison, alors chaque maison
effectivement construite selon ce plan représente un objet, et les différentes actions
possibles dans cette maison comme ouvrir les portes ou allumer les lumières
correspondent aux méthodes.
La nécessité de la modélisation
Maintenant que nous avons rappelé les fondements de la programmation orientée objet,
posons-nous la question suivante : pourquoi ne pas directement écrire le code d'une
application ? Pourquoi consacrer du temps à créer des modèles avant de programmer ?
Imaginons que l'on vous demande de développer un système de gestion complet pour une
université comme celle d'Abomey-Calavi. Ce système devra gérer les inscriptions des
étudiants, les emplois du temps, les notes, les paiements des frais de scolarité, les salles
de cours, et bien d'autres aspects encore. Face à un projet d'une telle ampleur, commencer
directement à programmer sans avoir une vision claire de l'ensemble du système serait
comparable à vouloir construire un bâtiment sans avoir établi de plans architecturaux
préalables. Les conséquences seraient désastreuses.
En l'absence de modélisation, plusieurs problèmes surgissent inévitablement.
Premièrement, il y a un risque élevé de confusion au sein de l'équipe de développement,
car chaque développeur pourrait avoir sa propre vision du système sans qu'il y ait de
référence commune. Deuxièmement, des fonctionnalités importantes peuvent être
oubliées ou mal comprises, ce qui nécessitera des corrections coûteuses par la suite.
Troisièmement, le code produit sans conception préalable est généralement difficile à
comprendre, à maintenir et à faire évoluer. Enfin, les erreurs de conception découvertes
tardivement, après que le code ait déjà été écrit, sont extrêmement coûteuses à corriger.
À l'inverse, lorsqu'on prend le temps de modéliser le système avant de le programmer, de
nombreux avantages apparaissent. La modélisation permet d'obtenir une vision claire et
partagée du système par tous les membres de l'équipe. Elle facilite grandement la
communication entre les différents acteurs du projet : développeurs, analystes, clients et
utilisateurs finaux. De plus, elle permet de détecter et de corriger les erreurs de
conception avant même d'avoir écrit une seule ligne de code, ce qui représente une
économie considérable de temps et de ressources. Enfin, les modèles constituent une
documentation précieuse du système qui facilite sa maintenance et son évolution future.
Pour illustrer cette importance de la modélisation, reprenons l'analogie de la construction.
Avant de construire un bâtiment universitaire, les architectes réalisent des plans détaillés
qui montrent la disposition des salles, les circuits électriques, la plomberie, etc. Ces plans
permettent de visualiser le bâtiment avant qu'il soit construit, d'identifier les problèmes
potentiels, et de communiquer efficacement avec les différents corps de métier. De la
même manière, avant de développer un système logiciel, il est indispensable de créer des
"plans" sous forme de modèles. C'est précisément à cette fin que le langage UML a été
créé.
Présentation du langage UML
UML, qui signifie Unified Modeling Language ou Langage de Modélisation Unifié en
français, est un langage graphique standardisé qui permet de visualiser, de spécifier, de
construire et de documenter les artefacts d'un système logiciel. Il s'agit d'un langage de
modélisation et non d'un langage de programmation, distinction qu'il est fondamental de
bien comprendre.
Pour saisir cette différence, considérons le parallèle suivant : un langage de
programmation comme C++, Java ou Python permet d'écrire du code qui sera exécuté par
un ordinateur pour produire un résultat concret. En revanche, UML permet de dessiner
des schémas et des diagrammes qui représentent la structure et le comportement d'un
système, sans pour autant constituer du code exécutable. On peut comparer UML aux
plans et schémas qu'utilise un architecte pour concevoir un bâtiment, tandis que les
langages de programmation correspondent aux outils qu'utilise le maçon pour construire
effectivement ce bâtiment.
L'histoire d'UML mérite d'être brièvement évoquée car elle permet de comprendre
pourquoi ce langage est devenu un standard international. Avant le milieu des années
1990, il existait de nombreuses méthodes de modélisation différentes, chacune avec sa
propre notation et ses propres conventions. Cette diversité créait une grande confusion
dans le monde du développement logiciel. En 1995, trois experts reconnus de la
modélisation objet, Grady Booch, James Rumbaugh et Ivar Jacobson, ont décidé d'unifier
leurs approches respectives pour créer un langage de modélisation unique.
Cette initiative a abouti en 1997 à la première version standardisée d'UML, la
version 1.0, qui a été adoptée par l'Object Management Group (OMG) comme standard
international. Depuis lors, UML a continué à évoluer pour s'adapter aux nouvelles
pratiques du développement logiciel, et la version actuelle est UML 2.5.
Il est crucial de bien comprendre qu'UML n'est pas un langage de programmation.
Cette confusion est fréquente chez les étudiants débutants, et il est donc important de
clarifier ce point dès maintenant. UML sert à concevoir et à documenter, tandis que les
langages de programmation servent à implémenter. Autrement dit, UML vous aide à
réfléchir et à organiser vos idées avant de programmer, mais vous aurez toujours besoin
d'un langage comme C++ pour écrire le code effectif de votre application. Les deux sont
complémentaires et non interchangeables.
SÉANCE 2 : PANORAMA DES DIAGRAMMES UML (1h30)
Vue d'ensemble des types de diagrammes
Maintenant que nous avons compris ce qu'est UML et pourquoi il est utile,
intéressons-nous aux différents outils qu'offre ce langage pour modéliser un système.
UML propose quatorze types de diagrammes différents, ce qui peut sembler
impressionnant au premier abord. Cependant, il ne faut pas se laisser intimider par ce
nombre, car ces diagrammes sont organisés de manière logique et répondent à des
besoins spécifiques dans le processus de modélisation.
Ces quatorze diagrammes se répartissent en deux grandes catégories fondamentales
qui correspondent à deux perspectives complémentaires sur un système informatique.
D'une part, nous avons les diagrammes structurels qui décrivent l'architecture statique du
système, c'est-à-dire de quoi il est composé. D'autre part, nous trouvons les diagrammes
comportementaux qui illustrent le fonctionnement dynamique du système, c'est-à-dire
comment il se comporte et évolue dans le temps. Cette distinction entre structure et
comportement est fondamentale car elle reflète deux questions essentielles que tout
développeur doit se poser lors de la conception d'un système.
Les diagrammes structurels
Commençons par examiner les diagrammes structurels, qui nous permettent de répondre
à la question : "De quoi est composé notre système ?" Cette catégorie comprend sept
types de diagrammes, dont certains sont plus fréquemment utilisés que d'autres dans la
pratique quotidienne du développement logiciel.
Le diagramme de classes est incontestablement le plus important et le plus utilisé de
tous les diagrammes UML. Il représente la structure statique du système en montrant les
classes, leurs attributs, leurs méthodes, ainsi que les relations qui les lient. Voici un
exemple simple pour un système universitaire :
Ce diagramme est si central qu'il constitue le cœur de la modélisation orientée objet et
sera étudié en profondeur dans notre cours. Vous verrez qu'il existe une correspondance
directe entre un diagramme de classes UML et le code que vous écrivez en C++.
Le diagramme d'objets, quant à lui, montre des instances spécifiques des classes à un
moment donné. Alors que le diagramme de classes représente la structure générale et
abstraite, le diagramme d'objets illustre une situation concrète avec des objets particuliers
et leurs valeurs spécifiques.
Le diagramme de composants permet de visualiser l'organisation physique du
système en termes de modules ou de composants logiciels. Il montre comment le système
est décomposé en parties réutilisables et comment ces parties interagissent entre elles.
Le diagramme de déploiement représente l'architecture matérielle du système et
la distribution des composants logiciels sur les différents nœuds physiques. Par exemple,
dans un système de gestion universitaire, ce diagramme pourrait montrer comment
l'application est répartie entre les serveurs, les postes clients, et les bases de données.
Enfin, le diagramme de paquetages organise les éléments du modèle en groupes
logiques appelés paquetages, permettant ainsi de gérer la complexité des grands
systèmes.
Les diagrammes comportementaux
Passons maintenant aux diagrammes comportementaux qui répondent à la question
: "Comment fonctionne notre système ?" Cette catégorie est tout aussi importante que la
précédente car elle permet de modéliser la dynamique du système, c'est-à-dire son
comportement dans le temps et en réponse aux différentes sollicitations.
Le diagramme de cas d'utilisation est généralement le premier diagramme que
l'on crée lors de la modélisation d'un système. Il représente les fonctionnalités du système
du point de vue des utilisateurs, appelés acteurs. Ce diagramme est extrêmement utile
pour capturer les besoins fonctionnels et pour communiquer avec les clients et les
utilisateurs finaux qui ne sont pas nécessairement des informaticiens.
Le diagramme de séquence est un outil puissant pour représenter les interactions entre
les objets dans le temps. Il montre comment les différents objets d'un système
communiquent en s'échangeant des messages pour réaliser une fonctionnalité donnée.
Le diagramme d'activités modélise les processus et les workflows, c'est-à-dire
l'enchaînement des activités nécessaires pour accomplir une tâche. Il ressemble à un
organigramme et peut être utilisé pour représenter des processus métier ou des
algorithmes.
Le diagramme d'états-transitions représente les différents états qu'un objet peut
prendre au cours de sa vie et les transitions entre ces états. Ce type de diagramme est
particulièrement utile pour modéliser le cycle de vie d'objets qui ont un comportement
dépendant de leur état.
Le processus de modélisation
Maintenant que nous avons une vue d'ensemble des différents types de
diagrammes, il est essentiel de comprendre dans quel ordre et dans quel but on les utilise.
La modélisation d'un système suit généralement un processus structuré qui commence
par la compréhension des besoins et se termine par l'implémentation du code.
La première étape consiste à analyser les besoins, c'est-à-dire à comprendre précisément
ce que le système doit faire. Cette phase nécessite souvent des entretiens avec les
utilisateurs futurs et les commanditaires du système. Il faut se poser des questions telles
que : Quels sont les objectifs du système ? Quels problèmes doit-il résoudre ? Quelles
sont les contraintes à respecter ?
Une fois les besoins identifiés, la deuxième étape consiste à identifier les acteurs, c'est-à-
dire les personnes ou les systèmes externes qui interagiront avec notre système. Par
exemple, dans un système de bibliothèque universitaire, les acteurs pourraient être
l'étudiant qui emprunte des livres et le bibliothécaire qui gère les collections.
La troisième étape consiste à modéliser les cas d'utilisation, c'est-à-dire les différentes
fonctionnalités que le système doit offrir à ses acteurs. Cette modélisation se fait à l'aide
du diagramme de cas d'utilisation que nous étudierons en détail dans le module suivant.
La quatrième étape est la modélisation des classes, où l'on identifie les concepts
importants du domaine et on les représente sous forme de classes avec leurs attributs,
leurs méthodes et leurs relations. Cette étape est cruciale car elle établit la structure
fondamentale du système.
La cinquième étape consiste à modéliser les interactions entre les objets pour réaliser les
différents cas d'utilisation. On utilise pour cela principalement les diagrammes de
séquence et les diagrammes d'activités.
Enfin, la dernière étape est l'implémentation, où l'on traduit les modèles UML en code
dans un langage de programmation comme C++, Java ou Python. Il est important de
comprendre que les modèles UML guident cette implémentation mais ne la remplacent
pas.
Exemple concret : Système de bibliothèque universitaire
Pour illustrer ce processus de manière concrète, prenons l'exemple d'un système de
bibliothèque universitaire.
Étape 1 - Analyser les besoins : Le système doit gérer les livres disponibles dans la
bibliothèque, gérer les étudiants qui sont autorisés à emprunter des livres, et enregistrer
tous les emprunts et retours de livres.
Étape 2 - Identifier les acteurs : Nous identifions deux acteurs principaux : l'Etudiant
qui vient emprunter des livres, et le Bibliothécaire qui gère les collections et aide les
étudiants.
Étape 3 - Fonctionnalités principales : Le système doit permettre d'emprunter un livre,
de retourner un livre, de rechercher un livre dans le catalogue, et de consulter l'historique
des emprunts.
Étape 4 - Classes principales : Nous identifions trois classes fondamentales : la classe
Livre qui représente les ouvrages disponibles, la classe Etudiant qui représente les
emprunteurs, et la classe Emprunt qui enregistre les transactions.
Dans les modules suivants, nous verrons concrètement comment tout cela se traduit en
diagrammes UML précis et normalisés.