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.

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.

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

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.

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.

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.

• 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.

• 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).

• 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.

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.