UML : un langage de mo­dé­li­sa­tion de type graphique

Le langage UML (Unified Modeling Language) est constitué de dia­grammes intégrés utilisés par les dé­ve­lop­peurs in­for­ma­tiques pour la re­pré­sen­ta­tion visuelle des objets, des états et des processus dans un logiciel ou un système. Le langage de mo­dé­li­sa­tion peut servir de modèle pour un projet et garantir une ar­chi­tec­ture d’in­for­ma­tion struc­tu­rée ; il peut également aider les dé­ve­lop­peurs à présenter leur des­crip­tion d’un système d’une manière com­pré­hen­sible pour les spé­cia­listes externes. UML est prin­ci­pa­le­ment utilisé dans le dé­ve­lop­pe­ment de logiciels orientés objet. Les amé­lio­ra­tions apportées à la norme dans la version 2.0 la rendent également adaptée à la re­pré­sen­ta­tion des processus de gestion.

Avant même l’in­tro­duc­tion d’UML dans le dé­ve­lop­pe­ment logiciel, le domaine de la pro­gram­ma­tion orientée objet (OOP) était déjà en plein essor. Ce style de pro­gram­ma­tion est basé sur le concept que tout est un objet : les éléments cons­ti­tu­tifs d’un programme sont des objets qui in­te­ra­gis­sent les uns avec les autres. Les messages envoyés dans les deux sens sont également cons­ti­tués d’objets. Chaque objet in­di­vi­duel est un exemple de sa classe su­pé­rieure. La classe elle-même agit également comme un objet et détermine le com­por­te­ment des instances d’objet qu’elle contient. Les objets sont cons­ti­tué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 nom­breuses méthodes et langages pour la re­pré­sen­ta­tion de la POO ont été dé­ve­lop­pés et mis en œuvre. Il en est résulté une variété de méthodes très dis­sem­blables. Pour unifier ces langages, les trois dé­ve­lop­peurs James Rumbaugh, Grady Booch et Ivar Jacobson ont décidé de fusionner plusieurs langages existants en un langage commun et stan­dar­disé.

Les trois avaient déjà créé leurs propres méthodes de dé­ve­lop­pe­ment logiciel orienté objet :

• La méthode Booch
• L’object modeling technique (OMT)
• L’object-oriented software en­gi­nee­ring method (OOSE)

UML devrait définir la sé­man­tique pour la re­pré­sen­ta­tion de ces méthodes comme langage de mo­dé­li­sa­tion. Sous le nom de "UML Partners", les dé­ve­lop­peurs ont commencé à tra­vail­ler sur l’achè­ve­ment d’UML dans une équipe en 1996. Ils l’ont ensuite remis au Object Ma­na­ge­ment Group (OMG), qui a introduit la version 1.1 du langage de mo­dé­li­sa­tion unifié comme norme en 1997.

Non sa­tis­faits, les dé­ve­lop­peurs ont mis en place un groupe de travail pour améliorer le langage sur plusieurs versions. Les critiques exis­tantes com­pre­naient une sé­man­tique imprécise et inu­ti­le­ment complexe, un manque d’adap­ta­bi­lité et une nor­ma­li­sa­tion 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 nor­ma­li­sa­tion ISO 19505-1 (In­fras­truc­ture) et 19505-2 (Su­pers­truc­ture) de 2012. UML Version 2.5.1 est paru en décembre 2017.

Certains appellent "langage de mo­dé­li­sa­tion unifié" la lingua franca parmi les langages de mo­dé­li­sa­tion, ce qui est vraiment ce qu’elle visait à devenir. Comme mentionné ci-dessus, UML visualise les états des objets et les in­te­rac­tions entre eux au sein d’un système. Son uti­li­sa­tion 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é­man­tique struc­tu­rée y contribue également. Les dia­grammes UML montrent les com­po­sants système suivants :

• Objets in­di­vi­duels (com­po­sants de base)
• Classes (com­bi­nai­son d’éléments ayant les mêmes pro­prié­tés)
• Relations entre objets (hié­rar­chie et com­por­te­ment / com­mu­ni­ca­tion entre objets)
• Activité (com­bi­nai­son complexe d’actions et de com­po­santes com­por­te­men­tales)
• In­te­rac­tions entre les objets et les in­ter­faces

L’image montre que la mé­ta­mo­dé­li­sa­tion d’UML 2.0, niveau M0 est le niveau de base. Il re­pré­sente des objets concrets, réels et des en­re­gis­tre­ments de données in­di­vi­duels - par ex. un objet ou un composant. Le niveau M1 comprend tous les modèles qui décrivent et struc­tu­rent les données du niveau M0. Ce sont des dia­grammes 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é­fi­nis­sent les spé­ci­fi­ca­tions et la sé­man­tique des éléments du modèle.

Si vous voulez créer un diagramme UML com­pré­hen­sible, 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 men­tion­née fonc­tionne à 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 su­pé­rieurs seraient créés.

UML (couche M2) définit les règles de sa propre sé­man­tique. Les unités de langage sont des termes définis dans la su­pers­truc­ture UML 2.0. Cela signifie qu’une re­pré­sen­ta­tion formelle que toutes les personnes con­cer­nées peuvent com­prendre est possible. Les unités de langage abs­traient des objets et des processus struc­tu­rés et fonc­tion­nant de la même manière et leur donnent une forme vi­suel­le­ment re­pré­sen­ta­tive. Selon le niveau hié­rar­chique du modèle, les éléments assument des tâches plus spé­cia­li­sées ou dé­fi­nis­sent d’autres éléments plus étroi­te­ment.

Classe : En tant qu’unité de langage, les classes sont un aspect central d’UML. Vous dé­fi­nis­sez ce qu’est une classe et comment les classes in­te­ra­gis­sent entre elles. Cette unité lin­guis­tique comporte quatre niveaux, allant d’éléments simples à des relations plus complexes :

• Core (describes elements from the UML 2.0 in­fras­truc­ture such as package, namespace, attribute, etc.)
• As­so­cia­tion classes
• In­ter­faces
• Po­wer­types (classes whose instances are sub­classes within this class)

Com­po­sants : Les com­po­sants 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’in­ter­mé­diaire d’in­ter­faces ou d’un port. Un con­nec­teur de com­po­si­tion établit une connexion avec un autre composant via l’interface. Le con­nec­teur de dé­lé­ga­tion relie les éléments internes à une interface à la frontière ex­té­rieure. Les com­po­sants sont mo­du­laires et in­ter­chan­geables.

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 com­po­sants. Seuls les ports con­nec­tent le contenu au système externe. Les clas­si­fi­ca­teurs dits en­cap­su­lés sont composés d’éléments appelés parties. Les pièces com­mu­ni­quent par l’in­ter­mé­diaire de con­nec­teurs.

Profil : Un profil configure UML 2.0 pour des besoins spé­ci­fiques. Des termes abstraits tels que activité ou objet doivent être spécifiés pour certains projets afin d’améliorer la com­pré­hen­sion. Vous pouvez utiliser un profil pour ajuster la sé­man­tique et les notations qui sont définies de manière ap­proxi­ma­tive.

Modèle : Le modèle comprend tous les éléments né­ces­saires pour re­pré­sen­ter une vue spé­ci­fique de la structure ou du com­por­te­ment d’un système. Cela inclut également les in­fluences externes telles que les acteurs.

Action : Lorsqu’il s’agit de décrire un com­por­te­ment, les actions sont centrales. Ils re­pré­sen­tent une seule étape dans une activité - une activité, à son tour, est un com­por­te­ment qui se compose d’un ensemble d’actions. Voici quelques exemples d’actions :

• Ordre de rem­plis­sage
• Afficher la page d’erreur
• Ordre de process

Com­por­te­ment : L’unité de langage "com­por­te­ment" ou "des­crip­tion du com­por­te­ment" désigne la mo­dé­li­sa­tion des aspects dy­na­miques d’un système. Il contient trois spé­ci­fi­ca­tions :

• Activité : Les actions in­te­ra­gis­sent à travers les flux de données et de contrôle. Il en résulte un système complexe de com­por­te­ments - les activités.
• In­te­rac­tion : 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 (si­tua­tions aux pro­prié­tés immuables) et les pseudo-états (états sans af­fec­ta­tion de valeurs) ainsi que leurs tran­si­tions. Les objets d’un état peuvent être affectés à des actions ou à des activités.

Dis­tri­bu­tion : Un réseau est constitué d’objets qui sont reliés les uns aux autres par des mailles. Un cas par­ti­cu­lier d’ap­pli­ca­tion existe si ces éléments re­pré­sen­tent des logiciels exé­cu­tables ou des artefacts. Ces artefacts s’exécutent sur des en­vi­ron­ne­ments d’exécution ou des pé­ri­phé­riques que UML 2.0 classe comme nœuds. L’artefact dépend donc du nœud. La dis­tri­bu­tion re­pré­sente cette relation de dé­pen­dance qui survient pendant l’ins­tal­la­tion.

Cas d’ap­pli­ca­tion : Le cas d’ap­pli­ca­tion (en tant qu’unité lin­guis­tique) re­pré­sente la con­fi­gu­ra­tion 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é par­ti­cu­liè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’uti­li­sa­tion (en tant qu’élément de modèle) informe seulement qu’un com­por­te­ment nommé est attendu qui est visible par le monde extérieur. Il ne montre gé­né­ra­le­ment pas les actions exactes. Dans une des­crip­tion com­por­te­men­tale, la mo­dé­li­sa­tion assigne les exigences dé­tail­lées au cas d’ap­pli­ca­tion.

Flux d’in­for­ma­tion : Cette unité de langage UML décrit l’unité d’in­for­ma­tion sur les éléments et le flux d’in­for­ma­tion. Ces éléments de modèle dé­fi­nis­sent des tech­niques de des­crip­tion du com­por­te­ment qui peuvent être très dé­tail­lées, comme les activités ou les in­te­rac­tions. Cette re­pré­sen­ta­tion sim­pli­fiée permet l’uti­li­sa­tion uni­ver­selle de ces éléments de mo­dé­li­sa­tion dans tous les types de dia­grammes UML.

Le langage de mo­dé­li­sa­tion définit 14 types de dia­grammes, qui sont divisés en deux ca­té­go­ries. Les ca­té­go­ries prin­ci­pales "structure" et "com­por­te­ment" re­pré­sen­tent les concepts de base re­pré­sen­tés par les dia­grammes UML. Dans le groupe des dia­grammes de com­por­te­ment, UML spécifie la sous-catégorie "dia­grammes d’in­te­rac­tion". Une quatrième sous-spé­ci­fi­ca­tion existe depuis l’éla­bo­ra­tion d’UML 2.0 et définit la con­cep­tion des dia­grammes du modèle.

• diagramme de dé­ploie­ment : Un diagramme de dé­ploie­ment modélise la dis­tri­bu­tion physique des artefacts sur les nœuds. Les nœuds sont soit du matériel (nœuds de pé­ri­phé­rique) qui peuvent fournir de la mémoire, soit du logiciel (nœuds d’en­vi­ron­ne­ment d’exécution) qui fournit un en­vi­ron­ne­ment pour exécuter des processus. Ils sont re­pré­sen­tés sous forme de cuboïdes tri­di­men­sion­nels. Ceux-ci con­tien­nent le nom du fichier. Pour les dis­tin­guer d’une classe, les cuboïdes ont des sté­réo­types tels que <<artéfact>>>. Le diagramme convient à l’affichage des dé­pen­dances entre les nœuds et les artefacts, appelées relations de dis­tri­bu­tion.
   
• Diagramme de profil : Les dia­grammes de profil sont utilisés au niveau du méta-modèle. Ils sont utilisés pour assigner un sté­réo­type à 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é­man­tique UML dans un profil, elle transmet les spé­ci­fi­ca­tions aux classes su­bor­don­nées.

• Diagramme d’activité : Les activités con­sis­tent 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’uti­li­sa­tion montre la con­fi­gu­ra­tion système requise, le diagramme d’activité montre comment ces cas d’uti­li­sa­tion s’exécutent. Dans ce type de diagramme, les jetons jouent un rôle. Dans les processus pa­ral­lèles, ils sont un marqueur pour lequel les processus sont priorisés et reçoivent des res­sources (par exemple, la mémoire de travail).
   
• Diagramme d’état-tran­si­tion : Une machine à états, aussi appelée automate fini, re­pré­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é­clen­cheur se déclenche), une réaction cor­res­pon­dante se produit. Il peut s’agir d’activités ou d’in­te­rac­tions. Sous UML 2.0, un état re­pré­sente cette situation. Les états sont con­si­dé­rés comme des sommets et sont affichés sous forme de rec­tangles aux coins arrondis. En outre, le diagramme machine d’états modélise les tran­si­tions d’un état (nœud source) à l’autre (nœud cible).

• diagramme d’aperçu des in­te­rac­tions : Le diagramme de vue d’ensemble des in­te­rac­tions récemment ajouté dans UML 2.0 permet d’afficher un système très complexe dans un schéma ap­proxi­ma­tif quand un diagramme d’in­te­rac­tion 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 re­pré­sente les flux de contrôle entre les in­te­rac­tions. Ceci est différent d’un diagramme d’activités, car un diagramme d’in­te­rac­tion entier peut être imbriqué dans des nœuds qui re­pré­sen­tent des activités. Ces im­bri­ca­tions peuvent être affichées di­rec­te­ment 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 ca­té­go­ries et les ap­pli­ca­tions possibles des dif­fé­rents types de dia­grammes UML sous forme abrégée. Si vous souhaitez re­pré­sen­ter vi­suel­le­ment un système logiciel orienté modèle, vous devez d’abord sé­lec­tion­ner l’un des types de diagramme UML con­for­mé­ment aux re­com­man­da­tions 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é­ces­si­tent souvent une certaine méthode. Vous pouvez ensuite créer un diagramme UML.