UML est un langage de modélisation graphique qui simplifie la création et la représentation de logiciels objets. Il vous permet de comprendre et de raisonner sur le logiciel que vous souhaitez créer et il permet de préparer son architecture avant d’en débuter la programmation.

UML est apparu dans les années 90 et résultait de la convergence de trois langages permettant d’organiser les codes objet :

• OMT (représentation graphique)

• OOD (concept de packages)

• OOSE (cas d’utilisation)

UML a été adopté en 1997 par l”Object Management Group (OMG) comme langage de modélisation des systèmes d’information à objets. UML2 a été adopté en 2005 par l’OMG. Ce dernier est organisé autour des 14 diagrammes. L’idée consiste à n’utiliser que les diagrammes dont on a besoin pour notre application, et on peut les créer dans n’importe quel ordre (l’idéal est d’ailleurs d’en créer plusieurs en parallèle et de les modifier en passant de l’un à l’autre). UML est donc un langage assez souple.

Nous allons maintenant introduire ces diagrammes à l’aide d’un exemple de développement d’application.

Quand on développe une application, on débute par l’analyse des besoins, c’est-à-dire que l’on souhaite trouver les acteurs de l’application (qui va s’en servir) et leurs buts (pour quoi faire). Ici, on s’attache aux « grandes fonctionnalités », pas aux détails. De plus, on ne s’intéresse pas à la manière de s’y prendre pour réaliser ces buts (le « comment faire ») : cette partie viendra plus tard. L’analyse des besoins passe en général par des entretiens avec les acteurs (souvent les clients qui ont commandé le logiciel).

Pour mener à bien cette phase, UML propose un diagramme de cas d’utilisation et un diagramme de séquences qui sont particulièrement utiles.

Ce type de diagramme montre les activités d’un acteur et son interaction avec le système (votre logiciel).

Considérons une application de jeu de rôles. On a un joueur qui doit affronter des monstres (Orc, Gobelins, Elfs) dans un monde virtuel. Disséminés dans ce dernier, il existe des coffres permettant de remonter les points de vie ou les munitions du joueur. L’objectif de ce dernier est, problématique Kafkaïenne, d’atteindre le château.

Le diagramme ci-dessous est un diagramme de cas d’usage d’une telle application. Les explications sont indiquées en dessous de ce dernier.

Tout d’abord, on spécifie l’acteur qui va utiliser l’application (ici, le joueur), qui est représenté sous la forme d’un petit bonhomme. Les ellipses représentent les actions possibles de l’acteur (on dit aussi les cas d’usage ou les cas d’utilisation). Pour symboliser que l’acteur réalise ces actions, on trace des arêtes entre l’acteur et toutes les actions possibles. On note que l’on évite au maximum les détails. Par exemple, l’action « se déplacer » peut être utilisée par le joueur pour se mouvoir dans le jeu afin d’atteindre le château mais également pour fuir un ennemi. Les ellipses représentent les « grandes » actions possibles.

Certaines actions ne peuvent avoir lieu qu’après en avoir nécessairement réalisé d’autres. C’est ce qu’indiquent les flèches en pointillés labellisées <<include>>. Par exemple, la flèche entre l’action « se connecter » et l’action « jouer » indique que, pour pouvoir jouer au jeu, il faut d’abord s’être connecté. Les flèches en pointillés labellisées <<extend>> représentent des actions qui peuvent être exécutées éventuellement avant d’autres mais qui ne sont pas nécessairement exécutées : par exemple, la flèche entre « jouer » et « paramétrer personnage » indique que le joueur peut, s’il le souhaite, paramétrer son personnage avant de jouer, mais qu’il peut jouer même s’il n’a pas paramétré son personnage. La flèche « extend » entre la connexion et la création du personnage s’interprète de la manière suivante : quand le joueur exécute l’application, il peut demander à se connecter. S’il a déjà créé son personnage, on ne lui demandera pas d’en créer un nouveau. En revanche, s’il n’en a pas encore créé, on va lui demander d’en créer un pour pouvoir se connecter. Lors d’une exécution de l’application, la création du personnage n’est donc pas nécessairement réalisée. Mais si elle l’est, elle le sera avant la connexion. Enfin, les flèches en traits pleins avec les triangles blancs indiquent des sous-cas, de la spécialisation (en quelque sorte, c’est une forme d’héritage) : ici, on dit que les actions que l’on peut mener quand on joue sont « se déplacer », « attaquer » et « prendre coffre ».

Pour résumer ce que traduit le diagramme ci-dessus, on peut dire qu’un joueur doit commencer par se connecter au jeu, après avoir, éventuellement, créé un personnage. Une fois ces actions réalisées, il peut jouer, après avoir, éventuellement, paramétré son personnage. Enfin, une fois le jeu lancé, il consiste, pour le joueur, à se déplacer sur l’espace de jeu, à prendre le contenu des coffres à côté desquels il passe et à attaquer des ennemis.

Notez qu’il existe d’autres symboles dans les diagrammes de cas d’usage, mais ceux indiqués ci-dessus sont les principaux.