UML (informatique)

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Page d'aide sur l'homonymie Pour les articles homonymes, voir UML.
Logo d'UML

En informatique UML (de l'anglais Unified Modeling Language), ou Langage de modélisation unifié, est un langage de modélisation graphique à base de pictogrammes. Il est utilisé en développement logiciel, et en conception orientée objet. UML est couramment utilisé dans les projets logiciels.

UML est l'accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par l'Object Management Group (OMG). La dernière version diffusée par l'OMG est UML 2.5 bêta 2 depuis septembre 2013[1].

Utilité d'UML[modifier | modifier le code]

UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon développement d'un logiciel orienté objet. UML offre un standard de modélisation, pour représenter l'architecture logicielle. Les différents éléments représentables sont :

  • Activité d'un objet/logiciel
  • Acteurs
  • Processus
  • Schéma de base de données
  • Composants logiciels
  • Réutilisation de composants

Grâce aux outils de modélisation UML, il est également possible de générer automatiquement une partie de code, par exemple en langage Java, à partir des divers documents réalisés.

Histoire[modifier | modifier le code]

Historique d'UML.

Les méthodes objets ont commencé à émerger au début des années 80, ces méthodes avaient pour but de remplacer les méthodes structurée et fonctionnelles, trop liés à la machine. Plusieurs méthodes (une cinquantaine) objets ont fait leur apparition au début des années 90. Ces méthodes s’orientant sur l’abstraction des composants matériels, se basent sur des notions de classe, d’association, de partition en sous-système et autour de l’étude de l’interaction entre utilisateur et le système. Les principaux auteurs de ces méthodes sont James Rumbaugh, Grady Booch et Ivar Jacobson. Parmi ces méthodes, deux se sont principalement établies : la méthode de Booch et la méthode OMT (Object Modeling Technique). Une deuxième version des méthodes de Booch et OMT ont fait leur apparition Booch’93 et OMT-2. Ces méthodes sont fortement semblables, en effet Booch’93 se concentre plus sur la construction tandis que OMT-2 se concentre sur l’analyse et l’abstraction.

Avant UML 1.x[modifier | modifier le code]

Le nombre important de méthodes et les différences entre celles-ci se réduisant fait reculer la technologie objet au point que Jim Rumbaugh et Grady Booch s’unissent en 1994 afin d’unifier leur travaux. Ils proposent ainsi « Unified Method », un an plus tard Ivar Jacobson (créateur des use cases) les rejoindra. Les auteurs de la méthode unifiée sortent, en 1995, un document intitulé Unified Method V0.8. Un an plus une nouvelle révision du document, suite aux commentaires des utilisateurs, sort (V0.9). En 1996, la révision 0.9.1 est la version la plus aboutie de la méthode unifiée (réorientation de la portée de l’effort d’unification). La méthode change de nom et se transforme en UML (Unified Modeling Language for Object-Oriented Development). Un consortium de grandes entreprises se crée (Microsoft, IBM, Oracle, etc.) permettant de faire évoluer la méthode à la version 1.0 d’UML.

UML 1.x[modifier | modifier le code]

En janvier 1997, UML est devenu un standard OMG. Les spécifications d'UML 1.0 sont soumises à l'association OMG.

Les différents partenaires de cette association mettent en place un groupe de travail, dirigé par Cris Kobryn et administré par Ed Eykholt. Cela donne naissance à UML 1.1 : les spécifications sont proposées à l'OMG en Août 1997, et sont définitivement adoptées en Novembre 1997[2].

Différentes améliorations continuent d'être apportées au standard UML, donnant naissance à 4 révisions : UML 1.1, 1.3, 1.4, 1.5. UML 1.5 est la dernière révision avant le passage à la version UML 2.0.

Les standards UML 1.x restent largement influencés par la notation OMT. Cependant, UML 1.x est décrié comme manquant d'intégration sémantique.

UML 2.x[modifier | modifier le code]



Le formalisme d'UML[modifier | modifier le code]

UML 2.3 propose 14 types de diagrammes (9 en UML 1.3). UML n'étant pas une méthode, leur utilisation est laissée à l'appréciation de chacun, même si le diagramme de classes est généralement considéré comme l'élément central d'UML ; des méthodologies, telles que l'UnifiedProcess, axent l'analyse en tout premier lieu sur les diagrammes de cas d'utilisation (Use Case). De même, on peut se contenter de modéliser seulement partiellement un système, par exemple certaines parties critiques.

  • UML se décompose en plusieurs sous-ensembles :
    • Les vues : Les vues sont les observables du système. Elles décrivent le système d'un point de vue donné, qui peut être organisationnel, dynamique, temporel, architectural, géographique, logique, etc. En combinant toutes ces vues, il est possible de définir (ou retrouver) le système complet.
    • Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci décrivent le contenu des vues, qui sont des notions abstraites. Les diagrammes peuvent faire partie de plusieurs vues.
    • Les modèles d'élément : Les modèles d'élément sont les briques des diagrammes UML, ces modèles sont utilisés dans plusieurs types de diagrammes. Exemple d'élément : cas d'utilisation (CU ou cadut'), classe, association, etc.

Mise en œuvre d'une démarche à l'aide d'UML : les vues[modifier | modifier le code]

Vues d'UML.

Une façon de mettre en œuvre UML est de considérer différentes vues qui peuvent se superposer pour collaborer à la définition du système :

  • Vue des cas d'utilisation : c'est la description du modèle vu par les acteurs du système. Elle correspond aux besoins attendus par chaque acteur (c'est le QUOI et le QUI).
  • Vue logique : c'est la définition du système vu de l'intérieur. Elle explique comment peuvent être satisfaits les besoins des acteurs (c'est le COMMENT).
  • Vue d'implémentation : cette vue définit les dépendances entre les modules.
  • Vue des processus : c'est la vue temporelle et technique, qui met en œuvre les notions de tâches concurrentes, stimuli, contrôle, synchronisation, etc.
  • Vue de déploiement : cette vue décrit la position géographique et l'architecture physique de chaque élément du système (c'est le OÙ).

Nota : le POURQUOI, n'est pas défini dans UML.

Les diagrammes[modifier | modifier le code]

La hiérarchie des diagrammes UML 2.0 sous forme d'un diagramme de classes.

Les 14 diagrammes UML sont dépendants hiérarchiquement et se complètent, de façon à permettre la modélisation d'un projet tout au long de son cycle de vie.

Diagrammes structurels ou statiques[modifier | modifier le code]

Les diagrammes structurels ou statiques (Structure Diagram) rassemblent :

Diagrammes comportementaux[modifier | modifier le code]

Les diagrammes comportementaux (Behavior Diagram) rassemblent :

  • Diagramme des cas d'utilisation (use-cases ou Use Case Diagram) : il permet d'identifier les possibilités d'interaction entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire toutes les fonctionnalités que doit fournir le système.
  • Diagramme états-transitions (State Machine Diagram) : permet de décrire sous forme de machine à états finis le comportement du système ou de ses composants.
  • Diagramme d'activité (Activity Diagram) : permet de décrire sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants.

Diagrammes d'interaction ou dynamiques[modifier | modifier le code]

Les diagrammes d'interaction ou dynamiques (Interaction Diagram) rassemblent :

  • Diagramme de séquence (Sequence Diagram) : représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs.
  • Diagramme de communication (Communication Diagram) : depuis UML 2.x, représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets.
  • Diagramme global d'interaction (Interaction Overview Diagram) : depuis UML 2.x, permet de décrire les enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes de séquences (variante du diagramme d'activité).
  • Diagramme de temps (Timing Diagram) : depuis UML 2.3, permet de décrire les variations d'une donnée au cours du temps.

Les éléments de modélisation[modifier | modifier le code]

  • Le Stéréotype est une marque de généralisation notée par des guillemets, cela montre que l'objet est une variété d'un modèle.
  • Le classeur est une annotation qui permet de regrouper des unités ayant le même comportement ou structure. Un classeur se représente par un rectangle conteneur, en traits pleins.
  • Un paquetage regroupe des diagrammes ou des unités.
  • Chaque classe ou objet se définit précisément avec le signe « :: », ainsi l'identification d'une Classe X en dehors de son package ou de son classeur sera définie par « Package A::Classeur B::Classe X ».

Les éléments de modélisation de type commun[modifier | modifier le code]

Modèles d'éléments UML.

Symbolique des modèles d'éléments :

  • Nœud (Node)
  • Fourche (Fork)
  • État initial (Initial state)
  • État terminal (Final state)
  • Interface
    • O←-- sens du flux de l'interface
    • O)----- est un raccourci pour la superposition de →O et O←

Les éléments de modélisation de type relation[modifier | modifier le code]

Autres éléments descriptifs[modifier | modifier le code]

Standardisation et Certification UML[modifier | modifier le code]

UML n'est pas un standard de fait mais un standard « industriel » de l'OMG (novembre 1997) au même titre que CORBA par exemple. Ceci étant, vu le succès initial de ce langage, il aurait pu tout aussi bien être simplement « standard de fait ». Depuis juillet 2005, la première version 2.* de UML est validée par l'OMG.

Par ailleurs, depuis 2003, l'OMG a mis en place un programme de certification à la pratique et la connaissance d'UML : OCUP[3] (OMG Certified UML Professional), qui recouvre trois niveaux successifs de maîtrise.

Exemple de séquence de création des diagrammes[modifier | modifier le code]

Diagramme étape du cycle en V
1. Diagramme de cas d'utilisation Spécification, cahier des charges
2. Diagramme de séquence
3. Diagramme d'activité (processus métiers)
4. Diagramme d'activité (cinématique et/ou processus applicatifs)
5. Diagramme de classe Conception Architecturale
6. Diagramme d'objet
7. Diagramme de communication
8. Diagramme de déploiement
9. Diagramme de composant

Logiciels de modélisation UML[modifier | modifier le code]

Article détaillé : Comparaison des logiciels d'UML.
Umbrello, atelier UML de KDE.

Il existe de nombreux outils logiciels de modélisation UML. Malheureusement, aucun d'entre eux ne respecte strictement chacune des versions de UML, particulièrement UML2 : beaucoup de ces outils introduisent des notations particulières non conformes, très peu supportent les différents types de diagrammes définis par le standard. Beaucoup en revanche incluent des outils de génération de squelette de code, particulièrement à partir du diagramme de classes, qui est celui qui se prête le mieux à une telle automatisation.

Notes et références[modifier | modifier le code]

2.5 Bêta 2 http://www.omg.org/spec/UML/2.5/Beta2/

(en) OMG, « OMG Unified Modeling LanguageTM (OMG UML),Superstructure », OMG,‎ aout 2011 (consulté le 20 novembre 2011)

(en) OMG, « OMG Unified Modeling LanguageTM (OMG UML), Infrastructure », OMG,‎ aout 2011 (consulté le 20 novembre 2011)

Voir aussi[modifier | modifier le code]

Sur les autres projets Wikimedia :

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]