UML : un langage de modélisation de type graphique

Le langage UML (Unified Modeling Language) est constitué de diagrammes intégrés utilisés par les développeurs informatiques pour la représentation visuelle des objets, des états et des processus dans un logiciel ou un système. Le langage de modélisation peut servir de modèle pour un projet et garantir une architecture d’information structurée ; il peut également aider les développeurs à présenter leur description d’un système d’une manière compréhensible pour les spécialistes externes. UML est principalement utilisé dans le développement de logiciels orientés objet. Les améliorations apportées à la norme dans la version 2.0 la rendent également adaptée à la représentation des processus de gestion.

Développement du langage de modélisation unifié

Avant même l’introduction d’UML dans le développement logiciel, le domaine de la programmation orientée objet (OOP) était déjà en plein essor. Ce style de programmation est basé sur le concept que tout est un objet : les éléments constitutifs d’un programme sont des objets qui interagissent les uns avec les autres. Les messages envoyés dans les deux sens sont également constitués d’objets. Chaque objet individuel est un exemple de sa classe supérieure. La classe elle-même agit également comme un objet et détermine le comportement des instances d’objet qu’elle contient. Les objets sont constitués de données et de code. L’objet organise les données en zones, également appelées attributs. Le code détermine leur procédure ou leur méthode.

De la fin des années 1980 aux années 1990, de nombreuses méthodes et langages pour la représentation de la POO ont été développés et mis en œuvre. Il en est résulté une variété de méthodes très dissemblables. Pour unifier ces langages, les trois développeurs James Rumbaugh, Grady Booch et Ivar Jacobson ont décidé de fusionner plusieurs langages existants en un langage commun et standardisé.

Les trois avaient déjà créé leurs propres méthodes de développement logiciel orienté objet :

  • La méthode Booch
  • L’object modeling technique (OMT)
  • L’object-oriented software engineering method (OOSE)

UML devrait définir la sémantique pour la représentation de ces méthodes comme langage de modélisation. Sous le nom de "UML Partners", les développeurs ont commencé à travailler sur l’achèvement d’UML dans une équipe en 1996. Ils l’ont ensuite remis au Object Management Group (OMG), qui a introduit la version 1.1 du langage de modélisation unifié comme norme en 1997.

Non satisfaits, les développeurs ont mis en place un groupe de travail pour améliorer le langage sur plusieurs versions. Les critiques existantes comprenaient une sémantique imprécise et inutilement complexe, un manque d’adaptabilité et une normalisation assez faible. Pour cette raison, une révision majeure a été effectuée. Le résultat a été UML 2.0, qui a établi la nouvelle norme en 2005. La version 2.4.1 constitue la base de la normalisation ISO 19505-1 (Infrastructure) et 19505-2 (Superstructure) de 2012. UML Version 2.5.1 est paru en décembre 2017.

UML : Termes clés

Certains appellent "langage de modélisation unifié" la lingua franca parmi les langages de modélisation, ce qui est vraiment ce qu’elle visait à devenir. Comme mentionné ci-dessus, UML visualise les états des objets et les interactions entre eux au sein d’un système. Son utilisation répandue peut être due à la grande influence des membres du groupe de gestion d’objets (OMG) (y compris IBM, Microsoft et HP). La sémantique structurée y contribue également. Les diagrammes UML montrent les composants système suivants :

  • Objets individuels (composants de base)
  • Classes (combinaison d’éléments ayant les mêmes propriétés)
  • Relations entre objets (hiérarchie et comportement / communication entre objets)
  • Activité (combinaison complexe d’actions et de composantes comportementales)
  • Interactions entre les objets et les interfaces

Métamodélisation

UML 2.0 définit des unités de langage qui fonctionnent à différents niveaux. Vous les utilisez pour exprimer la structure et le comportement d’un système. La méta-modélisation inclut tous les éléments d’UML, y compris ceux qui décrivent UML lui-même. Il utilise quatre niveaux hiérarchisés (M0 à M3).

Le niveau méta-meta M3 spécifie les métadonnées du langage de modélisation et ses relations à l’aide de la fonction métaobjet (MOF). Il définit le méta-modèle et permet également le transfert des métadonnées. Le format XMI défini par les membres du groupe de gestion d’objets est un outil pratique pour partager des données orientées objet au niveau méta-meta entre les outils de développement. Le langage de contrainte d’objet (OCL), un langage de programmation déclaratif, complète UML et régule les conditions limites de la modélisation. En tant que langage texte, cependant, il n’est qu’un support et ne peut pas être utilisé pour la modélisation.

L’image montre que la métamodélisation d’UML 2.0, niveau M0 est le niveau de base. Il représente des objets concrets, réels et des enregistrements de données individuels - par ex. un objet ou un composant. Le niveau M1 comprend tous les modèles qui décrivent et structurent les données du niveau M0. Ce sont des diagrammes UML tels que le diagramme d’activité ou le diagramme de package (expliqué ci-dessous). Pour définir la structure de ces modèles, les méta-modèles M2 définissent les spécifications et la sémantique des éléments du modèle.

Si vous voulez créer un diagramme UML compréhensible, vous devez connaître le méta-modèle UML et ses règles. Le niveau le plus élevé, M3, est un méta-modèle du méta-modèle. La facilité de méta-objet mentionnée fonctionne à un niveau abstrait qui définit les méta-modèles. Ce niveau se définit lui-même, car autrement, des méta-niveaux supérieurs seraient créés.

Unités linguistiques

UML (couche M2) définit les règles de sa propre sémantique. Les unités de langage sont des termes définis dans la superstructure UML 2.0. Cela signifie qu’une représentation formelle que toutes les personnes concernées peuvent comprendre est possible. Les unités de langage abstraient des objets et des processus structurés et fonctionnant de la même manière et leur donnent une forme visuellement représentative. Selon le niveau hiérarchique du modèle, les éléments assument des tâches plus spécialisées ou définissent d’autres éléments plus étroitement.

Classe : En tant qu’unité de langage, les classes sont un aspect central d’UML. Vous définissez ce qu’est une classe et comment les classes interagissent entre elles. Cette unité linguistique comporte quatre niveaux, allant d’éléments simples à des relations plus complexes :

  • Core (describes elements from the UML 2.0 infrastructure such as package, namespace, attribute, etc.)
  • Association classes
  • Interfaces
  • Powertypes (classes whose instances are subclasses within this class)

Composants : Les composants sont des modules logiciels qui séparent leur contenu du système externe. Il n’y a qu’une connexion vers l’extérieur par l’intermédiaire d’interfaces ou d’un port. Un connecteur de composition établit une connexion avec un autre composant via l’interface. Le connecteur de délégation relie les éléments internes à une interface à la frontière extérieure. Les composants sont modulaires et interchangeables.

Structure composite : La structure composite des unités de langage décrit les éléments qui sont protégés vers l’intérieur et vers l’extérieur, comme les composants. Seuls les ports connectent le contenu au système externe. Les classificateurs dits encapsulés sont composés d’éléments appelés parties. Les pièces communiquent par l’intermédiaire de connecteurs.

Profil : Un profil configure UML 2.0 pour des besoins spécifiques. Des termes abstraits tels que activité ou objet doivent être spécifiés pour certains projets afin d’améliorer la compréhension. Vous pouvez utiliser un profil pour ajuster la sémantique et les notations qui sont définies de manière approximative.

Modèle : Le modèle comprend tous les éléments nécessaires pour représenter une vue spécifique de la structure ou du comportement d’un système. Cela inclut également les influences externes telles que les acteurs.

Action : Lorsqu’il s’agit de décrire un comportement, les actions sont centrales. Ils représentent une seule étape dans une activité - une activité, à son tour, est un comportement qui se compose d’un ensemble d’actions. Voici quelques exemples d’actions :

  • Ordre de remplissage
  • Afficher la page d’erreur
  • Ordre de process

Comportement : L’unité de langage "comportement" ou "description du comportement" désigne la modélisation des aspects dynamiques d’un système. Il contient trois spécifications :

  • Activité : Les actions interagissent à travers les flux de données et de contrôle. Il en résulte un système complexe de comportements - les activités.
  • Interaction : Ce méta-modèle décrit comment les flux de messages sont échangés entre les objets, quand un message est envoyé et à quel objet, et quels autres éléments sont affectés par celui-ci.
  • Des machines à états : Dans un diagramme d’états, ce méta-modèle montre les états (situations aux propriétés immuables) et les pseudo-états (états sans affectation de valeurs) ainsi que leurs transitions. Les objets d’un état peuvent être affectés à des actions ou à des activités.

Distribution : Un réseau est constitué d’objets qui sont reliés les uns aux autres par des mailles. Un cas particulier d’application existe si ces éléments représentent des logiciels exécutables ou des artefacts. Ces artefacts s’exécutent sur des environnements d’exécution ou des périphériques que UML 2.0 classe comme nœuds. L’artefact dépend donc du nœud. La distribution représente cette relation de dépendance qui survient pendant l’installation.

Cas d’application : Le cas d’application (en tant qu’unité linguistique) représente la configuration système requise. L’acteur (une personne ou un système) est un élément qui détermine qui ou quoi doit effectuer une activité particulière à travers le système. Le système peut également être une classe ou un composant et est donc décrit comme un sujet. Le cas d’utilisation (en tant qu’élément de modèle) informe seulement qu’un comportement nommé est attendu qui est visible par le monde extérieur. Il ne montre généralement pas les actions exactes. Dans une description comportementale, la modélisation assigne les exigences détaillées au cas d’application.

Flux d’information : Cette unité de langage UML décrit l’unité d’information sur les éléments et le flux d’information. Ces éléments de modèle définissent des techniques de description du comportement qui peuvent être très détaillées, comme les activités ou les interactions. Cette représentation simplifiée permet l’utilisation universelle de ces éléments de modélisation dans tous les types de diagrammes UML.

Les diagrammes UML : leur utilisation et une brève introduction générale

Le langage de modélisation définit 14 types de diagrammes, qui sont divisés en deux catégories. Les catégories principales "structure" et "comportement" représentent les concepts de base représentés par les diagrammes UML. Dans le groupe des diagrammes de comportement, UML spécifie la sous-catégorie "diagrammes d’interaction". Une quatrième sous-spécification existe depuis l’élaboration d’UML 2.0 et définit la conception des diagrammes du modèle.

Diagrammes de structure

Les diagrammes de structure représentent les éléments individuels d’un système. Ils sont donc particulièrement adaptés à la représentation de l’architecture logicielle. La représentation statique ne représente pas un changement, mais plutôt des états et des dépendances à un moment donné. Les éléments individuels, ou objets, sont reliés les uns aux autres. Par exemple, un objet appartient à une classe. D’autres composants sont des nœuds d’ordinateur ou des artefacts - un artefact représente un résultat, par exemple un fichier script fini.

Les diagrammes UML de cette catégorie représentent un système entier ou une sous-structure. Cette dernière aide, par exemple, à clarifier la structure en détail. La langue de la catégorie "structure" attribue sept types de diagrammes UML dans UML 2.0 :

  • Diagramme de classes : Si les objets ont un comportement commun ou la même structure, vous pouvez les classifier ou les affecter à une classe. La classe est donc un élément de simplification et de synthèse (abstraction) pour la représentation visuelle. Les classes et les objets sont reliés entre eux à l’aide d’interfaces. Tous ces composants et leurs relations entre eux peuvent être représentés dans un diagramme de classes. Une classe représente ses diagrammes à l’aide d’un rectangle. Le nom de la classe est en caractères gras, comme indiqué ci-dessous.
  • Diagramme d’objet : Un diagramme d’objets a une structure similaire à celle d’un diagramme de classes. Au lieu du nom tel qu’il apparaît dans le diagramme de classes (voir "personne" ci-dessus), le diagramme d’objets met le nom avec le nom du classificateur/catégorie. Selon la spécification, ceci est souligné (ex. : Helga:Person)
     
  • Diagramme des composants : Un composant est un module isolé du système externe et interagit avec d’autres composants via des interfaces définies. C’est un sous-type de la classe. Par conséquent, les caractéristiques structurelles telles que les opérations et les attributs définissent plus clairement le composant. Il existe deux options d’affichage pour la modélisation, selon les besoins : la vue boîte noire (le contenu est masqué) et la vue boîte blanche (le contenu est visible).
  • diagramme de structure composite : Les objets appartiennent à des classes qui, à leur tour, peuvent également être classifiées. Ces soi-disant méta-classes sont appelées classificateurs en UML. Le diagramme de structure composite représente les différents éléments et connecteurs d’un classificateur. Les pièces font toujours partie de l’ensemble, même si elles ne sont pas nécessairement nécessaires pour compléter le classificateur. Les connecteurs sont les liens entre les pièces. Les fonctions ou les services qui nécessitent des composants en dehors du classificateur envoient des pièces via une interface.
     
  • diagramme d’ensemble : Un package combine des éléments tels que des interfaces ou des classes dans un espace de noms (voir note ci-dessous). Les paquets peuvent également fusionner avec d’autres paquets (fusion de paquets), les importer (importation de paquets), ou contenir d’autres paquets (sous-paquets). Les diagrammes de structure de paquet lient les contenus hiérarchiquement, comme dans un diagramme en arbre. Le diagramme de package est utilisé, par exemple, dans le méta-modèle d’UML 2, et est modulaire dans les systèmes logiciels. Strictement spécifié, un paquet se compose d’une tête et d’une zone de contenu.
Note

Un espace de nommage est un élément du méta-modèle UML-2. Les composants doivent avoir un nom et l’un des attributs de visibilité suivants : package, privé, protégé ou public. Le paquet est un cas particulier de l’espace de nommage.

  • diagramme de déploiement : Un diagramme de déploiement modélise la distribution physique des artefacts sur les nœuds. Les nœuds sont soit du matériel (nœuds de périphérique) qui peuvent fournir de la mémoire, soit du logiciel (nœuds d’environnement d’exécution) qui fournit un environnement pour exécuter des processus. Ils sont représentés sous forme de cuboïdes tridimensionnels. Ceux-ci contiennent le nom du fichier. Pour les distinguer d’une classe, les cuboïdes ont des stéréotypes tels que <<artéfact>>>. Le diagramme convient à l’affichage des dépendances entre les nœuds et les artefacts, appelées relations de distribution.
     
  • Diagramme de profil : Les diagrammes de profil sont utilisés au niveau du méta-modèle. Ils sont utilisés pour assigner un stéréotype à des classes, ou un profil à des packages. Au niveau méta, il est possible d’adapter le modèle à une autre plate-forme ou domaine. Par exemple, si vous limitez la sémantique UML dans un profil, elle transmet les spécifications aux classes subordonnées.

Diagrammes de comportement

Les diagrammes de comportement couvrent les autres spécifications sous UML. Contrairement aux diagrammes de structure, ils ne sont pas statiques, mais représentent des processus. Les diagrammes de comportement comprennent également des diagrammes d’interaction (voir ci-dessous).

  • Diagramme de cas d’utilisation : Les diagrammes de cas d’utilisation montrent le comportement attendu d’un système ultérieurement. Cette modélisation convient non seulement pour les systèmes logiciels, mais aussi pour prédire les procédures dans l’entreprise, par exemple. Le cas d’utilisation implique un acteur (humain ou système) avec un but. Le diagramme porte généralement le nom de la cible. Les différents cas d’utilisation au sein du système répondent à l’objectif de l’acteur.

Le diagramme de cas d’utilisation représente UML à l’aide d’un rectangle intitulé "cas d’utilisation". L’expéditeur est l’acteur (il est représenté sous la forme d’un bâton, même s’il s’agit d’un système - voir ci-dessous). L’acteur est connecté au cas d’application (ellipse avec étiquette) dans un système (rectangle avec étiquette <<system>>, et nom du système).

  • Diagramme d’activité : Les activités consistent en un réseau d’actions reliées par des flux de données et de contrôle. Alors que le diagramme de cas d’utilisation montre la configuration système requise, le diagramme d’activité montre comment ces cas d’utilisation s’exécutent. Dans ce type de diagramme, les jetons jouent un rôle. Dans les processus parallèles, ils sont un marqueur pour lequel les processus sont priorisés et reçoivent des ressources (par exemple, la mémoire de travail).
     
  • Diagramme d’état-transition : Une machine à états, aussi appelée automate fini, représente un ensemble fini d’états dans un système. Si une condition fixe est remplie dans le système (c’est-à-dire qu’un déclencheur se déclenche), une réaction correspondante se produit. Il peut s’agir d’activités ou d’interactions. Sous UML 2.0, un état représente cette situation. Les états sont considérés comme des sommets et sont affichés sous forme de rectangles aux coins arrondis. En outre, le diagramme machine d’états modélise les transitions d’un état (nœud source) à l’autre (nœud cible).

Diagrammes d’interaction

Les diagrammes d’interaction sont un sous-type des diagrammes de comportement. Ils décrivent également les processus. Ils sont particulièrement adaptés à la modélisation des comportements dans lesquels les éléments échangent des informations. Les diagrammes définissent le rôle des objets impliqués. Ils nomment et classent par ordre de priorité les messages qui sont envoyés d’un objet à l’autre. Les diagrammes d’interaction montrent également comment ces messages affectent les éléments comportementaux, tels que le démarrage ou l’arrêt des activités :

  • Diagrammes de séquence : En tant que diagramme d’interaction, le diagramme de séquence représente l’échange de messages entre objets. Le type de diagramme UML modélise ces objets comme une ligne de vie. En ce sens, il est similaire à d’autres diagrammes comportementaux tels que le diagramme d’activité. Contrairement à ces derniers, cependant, un diagramme de séquence n’est pas utilisé pour obtenir une vue d’ensemble du comportement d’un système, mais pour présenter en détail un comportement possible parmi tant d’autres. Il prescrit une chronologie, et une ligne pointillée représente le cours du temps. UML 2.0 affiche des messages synchrones (une flèche à tête remplie) et asynchrones (une flèche à tête ouverte). Les messages synchrones sont des messages qui bloquent un canal jusqu’à ce qu’ils reçoivent une réponse de l’objet cible. Ils déterminent les caractéristiques comportementales sous forme d’opérations synchrones. Les messages asynchrones contrôlent l’objet source appelant. Il s’agit aussi bien d’opérations asynchrones que de signaux (paquets de données envoyés entre les actions).
     
  • Diagramme de communication : Semblable à un diagramme de séquence, les diagrammes de communication modélisent un transfert de message à l’aide de lignes de vie. Cependant, ce diagramme UML n’utilise pas de lignes pointillées pour les séquences de temps, mais numérote les séquences avec des chiffres et des lettres. Ces termes de séquence sont situés au-dessus d’une flèche dont l’extrémité pointe dans la direction du récepteur. Les chiffres représentent l’ordre dans lequel les messages sont envoyés, les lettres pour le niveau hiérarchique (comme indiqué dans la figure ci-dessous).
  • Diagramme de temps : Un diagramme de temps permet de montrer en détail le comportement des systèmes sous l’aspect du séquençage temporel. Les systèmes en temps réel, par exemple, doivent achever certains processus dans un certain laps de temps. Pour mieux représenter un plan de temps, UML 2.0 modélise les diagrammes de temps en diagrammes bidimensionnels, avec un axe des x et un axe des y. Dans cette sous-catégorie du diagramme de séquence, les états des objets se trouvent sur l’axe des y, et les séquences temporelles qui leur sont affectées se déroulent sur l’axe des y.
  • diagramme d’aperçu des interactions : Le diagramme de vue d’ensemble des interactions récemment ajouté dans UML 2.0 permet d’afficher un système très complexe dans un schéma approximatif quand un diagramme d’interaction normal serait trop confus. Un diagramme de séquence convient pour un affichage détaillé. Le diagramme UML est similaire au diagramme d’activités avec noeuds. Il représente les flux de contrôle entre les interactions. Ceci est différent d’un diagramme d’activités, car un diagramme d’interaction entier peut être imbriqué dans des nœuds qui représentent des activités. Ces imbrications peuvent être affichées directement dans le diagramme (en ligne) ou se référer au modèle (mot clé : réf) qui est montré en détail ailleurs.

Les diagrammes UML : vue d’ensemble

La vue d’ensemble suivante montre les catégories et les applications possibles des différents types de diagrammes UML sous forme abrégée. Si vous souhaitez représenter visuellement un système logiciel orienté modèle, vous devez d’abord sélectionner l’un des types de diagramme UML conformément aux recommandations du groupe de travail UML. Ce n’est qu’alors qu’il vaut la peine de choisir l’un des nombreux outils UML tools, car ceux-ci nécessitent souvent une certaine méthode. Vous pouvez ensuite créer un diagramme UML.

Catégorie

Type de diagramme

utilité

Diagramme de structure

Diagramme de classes

Représente les classes

 

Diagramme d’objet

Affiche l’état d’un système à un moment donné

 

Diagramme des composants

Affiche les dépendances et les composants de structure

 

diagramme de structure composite

Divise les modules ou les classes en leurs composantes et clarifie leurs relations.

 

Diagramme de paquetage

Regroupe les classes en paquets, représente la hiérarchie et la structure des paquets

 

Diagramme de déploiement

Affiche la distribution des composants aux nœuds de l’ordinateur

 

Diagramme de profil

Illustre les relations d’usage au moyen de stéréotypes, de conditions aux limites, etc.

Diagrammes de comportement

Diagramme de cas d’utilisation

Représente divers usages

 

Diagramme d’activité

Décrit le comportement de différents processus (parallèles) dans un système.

 

Diagramme d’état-transition

Documente la façon dont un objet passe d’un état à un autre par le biais d’un événement.

Diagrammes de comportement - diagrammes d’interaction

Diagramme de séquence

Représente le moment des interactions entre les objets.

 

Diagramme de communication

Affiche la répartition des rôles des objets au sein d’une interaction.

 

Diagramme de temps

Démontre la limitation temporelle pour les événements qui mènent à un changement d’état.

 

Diagramme d’aperçu d’interaction

Montre comment les séquences et les activités interagissent.

Conseil

Le Groupe de modélisation d’objets émet des certificats UML. Si vous souhaitez approfondir vos connaissances, découvrez plus d’informations sur les tutoriels UML.


Nom de domaine en .alsace
Renforcez votre présence en ligne
locale avec le .alsace

9 € HT la 1ère année (10,80 € TTC), puis 60 € HT/an (72 € TTC)
.fr
1 € HT la 1ère année
puis 10 € HT/an
.alsace
9 € HT la 1ère année
puis 60 € HT/an
.com
1 € HT la 1ère année
puis 10 € HT/an
.org
1 € HT la 1ère année
puis 15 € HT/an