• 20 hours
  • Easy

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 10/15/19

UML, c’est quoi ?

Log in or subscribe for free to enjoy all this course has to offer!

Comme n’importe quel type de projet, un projet informatique nécessite une phase d’analyse, suivi d’une étape de conception.

Dans la phase d’analyse, on cherche d’abord à bien comprendre et à décrire de façon précise les besoins des utilisateurs ou des clients. Que souhaitent-ils faire avec le logiciel ? Quelles fonctionnalités veulent-ils ? Pour quel usage ? Comment l’action devrait-elle fonctionner ? C’est ce qu’on appelle « l’analyse des besoins ». Après validation de notre compréhension du besoin, nous imaginons la solution. C’est la partie analyse de la solution.

Dans la phase de conception, on apporte plus de détails à la solution et on cherche à clarifier des aspects techniques, tels que l’installation des différentes parties logicielles à installer sur du matériel.

Positionnement du cours dans la démarche de projet

Pour réaliser ces deux phases dans un projet informatique, nous utilisons des méthodes, des conventions et des notations. UML fait partie des notations les plus utilisées aujourd’hui.

Nous allons dans ce chapitre définir le langage UML et ses outils : les diagrammes. Nous verrons comment ce langage peut contribuer à la phase d’analyse des besoins et du domaine d’un projet informatique.

Définition

Fotolia_Crédit Raywoo
Fotolia_Crédit Raywoo

UML, c’est l’acronyme anglais pour « Unified Modeling Language ». On le traduit par « Langage de modélisation unifié ». La notation UML est un langage visuel constitué d’un ensemble de schémas, appelés des diagrammes, qui donnent chacun une vision différente du projet à traiter. UML nous fournit donc des diagrammes pour représenter le logiciel à développer : son fonctionnement, sa mise en route, les actions susceptibles d’être effectuées par le logiciel, etc.

Réaliser ces diagrammes revient donc à modéliser les besoins du logiciel à développer.

Et ces diagrammes, on les réalise comment ?

Vous avez le choix ! Vous pouvez soit reprendre les normes de ces diagrammes que nous verrons au fur et à mesure de ce cours et les dessiner à la main, soit utiliser des logiciels gratuits ou payants pour les réaliser. Dans ce cours, j’utiliserai par exemple StarUml, mais vous pouvez aussi utiliser ArgoUml, BoUml, PowerDesigner, etc.

Le langage UML ne préconise aucune démarche, ce n’est donc pas une méthode. Chacun est libre d’utiliser les types de diagramme qu’il souhaite, dans l’ordre qu’il veut. Il suffit que les diagrammes réalisés soient cohérents entre eux, avant de passer à la réalisation du logiciel.

Oui, je vous l’accorde, n’ayant aucune directive quant à la démarche à adopter, on se sent plutôt perdu. C’est pourquoi je vais vous donner une démarche possible (parmi tant d’autres) pour que vous puissiez commencer à utiliser la notation UML dans vos projets de réalisation de logiciels.

Pourquoi modéliser ?

Modéliser, c’est décrire de manière visuelle et graphique les besoins et, les solutions fonctionnelles et techniques de votre projet logiciel. Mais modéliser pour quoi faire ?

Avez-vous déjà eu à constituer un meuble en kit ou à brancher un nouvel équipement électronique? Vous serez d’accord que c’est plus facile à partir de schéma plutôt qu’une page de texte, non ?

Cet exemple nous démontre que l’utilisation de schémas et d’illustrations rend quelque chose de complexe plus compréhensible.

Intéressant. Mais quel est le lien avec UML alors ?

C’est exactement ce à quoi UML sert dans des projets de réalisation de logiciels !

Un document de texte décrivant de façon précise ce qui doit être réalisé contiendrait plusieurs dizaines de pages. En général, peu de personnes ont envie de lire ce genre de document. De plus, un long texte de plusieurs pages est source d’interprétations et d’incompréhension. UML nous aide à faire cette description de façon graphique et devient alors un excellent moyen pour « visualiser » le(s) futur(s) logiciel(s).

Je suis toujours étonnée de voir le nombre d’informaticiens qui commencent à programmer sans avoir étudié le besoin des utilisateurs, du client, etc. et sans avoir fait une conception du logiciel en bonne et due forme.

Quand j’en fais la remarque, je reçois généralement des réponses du type :

  • On n’est pas vraiment obligé de modéliser un logiciel que l’on doit réaliser, non ?

  • À quoi bon modéliser le logiciel, puisque je sais exactement ce qu’il faut ?

  • C’est une perte de temps. La réalisation de ce logiciel est urgente.

  • Etc.

Laissez-moi vous répondre par une analogie.

Est-ce que ça vous viendrait à l’idée de laisser un maître d’œuvre commencer la construction d’une maison sans avoir préalablement fait réaliser des plans par un architecte ? La réponse est bien sûr que non, à moins que l’on veuille bien accepter une maison qui ne réponde pas à nos besoins, qui soit bancale ou qui le deviendrait dans peu de temps, et dans laquelle il serait difficile de faire des travaux faute de plans.

Un logiciel qui a été réalisé sans analyse et sans conception (étapes où l’on modélise le futur logiciel) risque lui aussi de ne pas répondre aux besoins, de comporter des anomalies et d’être très difficile à maintenir.

Tout comme la construction d’une maison nécessite des plans à différents niveaux (vision extérieure, plan des différents étages, plans techniques…), la réalisation d’un logiciel ou d’un ensemble de logiciels a besoin d’un certain nombre de diagrammes.

Le temps que prend la modélisation ne devrait pas être un frein. Cette étape nous permet de ne pas perdre davantage de temps ultérieurement :

  • pour « faire coller » un logiciel déjà développé aux besoins (qu’on n’avait pas étudié, ni compris) ;

  • pour comprendre comment un logiciel a été créé avant d’y apporter des modifications. 

L’approche objet

Dans la gestion de projet, nous pouvons citer deux approches permettant de définir les besoins :

  • La décomposition fonctionnelle (ou l’approche procédurale) 

  • L’approche objet (sur laquelle est basée UML)

La décomposition fonctionnelle

Avant l’apparition de l’approche objet dans les années 80, une autre démarche était largement utilisée.

Pendant longtemps, de nombreux logiciels étaient conçus par l’approche fonctionnelle descendante, appelée également la décomposition fonctionnelle. Je sais, ce terme parait barbare, mais vous allez vite comprendre.

L’approche par décomposition fonctionnelle considère que le logiciel est composé d'une hiérarchie de fonctions et de données. Les fonctions fournissent les services désirés et les données représentent les informations manipulées. La démarche est logique, cohérente et intuitive (voir la figure suivante).

Exemple de décomposition fonctionnelle pour le logiciel Word
Exemple de décomposition fonctionnelle pour le logiciel Word

Pour réaliser une fonction du logiciel, on peut utiliser un ensemble d'autres fonctions, déjà disponibles, à condition qu'on rende ces dernières suffisamment génériques.

Comme vous pouvez le voir dans l’exemple précédent, le progiciel Word contient la fonction « Enregistrer sous », qui utilise très probablement la fonction « Enregistrer ». Cette fonction se sert de l’emplacement du nom du fichier connu à l’ouverture.

Pour la fonction « Enregistrer sous », l’utilisateur doit préciser un endroit où enregistrer tout en donnant éventuellement un autre nom au fichier. L’enregistrement se fait alors exactement de la même manière que dans la fonction « Enregistrer ».

Ce découpage n’a pas que des avantages. Les fonctions sont alors interdépendantes : une simple mise à jour du logiciel à un point donné, peut impacter en cascade d'autres fonctions. On peut éviter cela en faisant attention à créer des fonctions très génériques. Mais respecter cette contrainte rend l'écriture du logiciel et sa maintenance plus complexe.

Par exemple, si les développeurs de la société Microsoft décident de modifier le déroulement de la fonction « Enregistrer », cela impactera forcément la fonction « Enregistrer sous ». On peut aisément imaginer qu’une modification dans une fonction qui est utilisée par un grand nombre d’autres fonctions sème un peu la pagaille.

Ayant constaté les problèmes inhérents à la décomposition fonctionnelle, de nombreux experts se sont penchés sur une approche différente. De cette réflexion est née l’approche objet, dont UML s’inspire largement.

L’approche objet

L’approche objet est une démarche qui s’organise autour de 4 principes fondamentaux. C’est une démarche :

  • itérative et incrémentale ;

  • guidée par les besoins du client et des utilisateurs ;

  • centrée sur l’architecture du logiciel ;

  • qui décrit les actions et les informations dans une seule entité.

Allez, voyons cela dans le détail !

=> L’approche objet utilise une démarche itérative et incrémentale.

Aie ! Qu’est-ce que ça veut dire ?

Reprenons notre exemple de la construction d’une maison. L’architecte réalise toujours plusieurs versions des plans avant d’avoir la version définitive (c’est-à-dire celui accepté par le client). Après un premier entretien avec son client, il réalise les plans pour la vision extérieure de la maison et les plans de surface. Ces plans sont soumis au client et donnent généralement lieu à des discussions. Cela permet à l’architecte de mieux cerner le besoin de son client. Il apporte alors les modifications qui s’imposent aux plans qu’il avait réalisés. Il s’agit là d’une première itération sur les plans de la vision extérieure et les plans de surface.

Par la suite, l’architecte réalisera les plans techniques qui seront nécessaires pour les différents corps de métier (les maçons, les électriciens, les plombiers, etc.). Il arrive parfois que ces plans mettent en évidence certaines contraintes qui obligent l’architecte à revenir sur les plans de surface (par exemple pour ajouter l’emplacement d’une colonne d’aération qui n’avait pas été prévue au départ). Il y a donc une deuxième itération sur les plans de surface.

Une démarche itérative c’est donc faire des allers-retours entre le plan initial et les modifications apportées par les acteurs du projet.

De la même façon, la modélisation d’un logiciel se fera en plusieurs fois. Les diagrammes ne seront pas réalisés de façon complètement satisfaisante dès la première fois. Il nous faudra plusieurs versions d’un même diagramme pour obtenir la version finale. Chaque version est le fruit d’une itération (un nouveau passage sur les diagrammes). Une itération permet donc d’affiner la compréhension du futur logiciel.

 La démarche est guidée par les besoins du client et des utilisateurs

Les besoins d’un client, dans un projet logiciel sont les exigences exprimées par le client au niveau des fonctionnalités, du rendu et des actions d’un logiciel. Par exemple, lors de la réalisation du progiciel Word, les clients ont probablement souhaité un logiciel qui leur permettrait d’écrire du texte, de l’effacer, d’intégrer des images, enregistrer le contenu, le supprimer, etc.

Les besoins des utilisateurs servent de fil rouge, tout au long du cycle de développement :

  • lors de la phase d'analyse pour la clarification, l’affinage et la validation des besoins des utilisateurs ;

  • lors de la phase de conception et de réalisation pour la vérification de la prise en compte des besoins des utilisateurs ;

  • lors de la phase de test afin de garantir la satisfaction des besoins. 

Je vous rappelle que dans ce cours, nous traiterons uniquement de la phase d’analyse.

=> La démarche est également centrée sur l'architecture du logiciel, pierre angulaire d'un développement.

L’architecture logicielle décrit les choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité...). On peut citer l’architecture client serveur, en couche ou en niveaux. Cela n’étant pas l’objet de ce cours, je vous épargnerai les détails. Concentrons-nous sur la modélisation des besoins !

=> L’approche objet décrit aussi bien les actions que les informations dans une même entité.

Les différents diagrammes utilisés en UML donnent tous une vision particulière du logiciel à développer. Parmi ces diagrammes, il en est un qui représente particulièrement bien ce qui est à développer si on opte pour un développement objet. Il s’agit du diagramme de classes.

Je sais, je n’ai pas encore défini les diagrammes que l’on peut utiliser. Pour l’instant, nous pouvons retenir que le diagramme de classes donnera une vision assez claire des informations qui seront utilisées par le logiciel, mais également des fonctions (ou opérations) qui devront s’appuyer sur ces informations. L’approche objet mélange donc habilement l’analyse des informations et des actions au lieu de les analyser séparément.

Le diagramme de classes ne sera pas étudié dans ce cours, mais je souhaitais simplement l’évoquer dans le cas où vous auriez envie d’aller plus loin !

En résumé

  • UML signifie « Unified Modeling Language » ou Langage de modélisation unifié en français. C’est un langage de modélisation qui permet de représenter graphiquement les besoins des utilisateurs. On utilise pour cela des diagrammes. 

  • UML est une démarche qui se base sur une approche objet. Cette approche s’appuie sur 4 principes fondamentaux.

  • L’approche objet nécessite une démarche itérative et incrémentale, c’est-à-dire que le concepteur doit faire des allers-retours entre les diagrammes initiaux et, les besoins du client et des utilisateurs perçus au fur et à mesure de la conception du logiciel afin de le modifier si nécessaire. 

  • L’approche objet est guidée par les besoins du client. 

  • L’approche objet est centrée sur le diagramme de classes qui décrit aussi bien des actions que des informations dans une même entité. Les autres diagrammes nous aident à voir clair dans les besoins et dans la solution qui est à développer. Ils permettent de compléter le diagramme de classes.

Example of certificate of achievement
Example of certificate of achievement