Schéma UML

Contenu

 [cacher] 

• 1 Histoire
• 1.1 Avant UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Conception
• 2.1 Méthodes de développement des logiciels
• 2.2 Modélisation
• 3 Diagrammes
• 3.1 Diagrammes de structure
• 3.2 Diagrammes de comportement
• 3.2.1 Diagrammes d'interaction
• 4 Méta-modélisation
• 5 Adoption
• 6 Critiques
• 6.1 Critique de l'UML 1.x

Histoire [modifier la source | modifier]

Histoire des méthodes et de la notation orientées objet

L'UML évolue depuis la seconde moitié des années 1990 et trouve ses racines dans les méthodes orientées objet développées à la fin des années 1980 et au début des années 1990. La chronologie (voir image) montre les points forts de l'histoire des méthodes de modélisation et de la notation orientées objet.

Il est basé à l'origine sur les notations de la méthode Booch, de la technique de modélisation par l'objet (OMT) et du génie logiciel orienté objet (OOSE), qu'il a intégrées dans un seul langage. ^[5]

Avant UML 1.x [modifier la source | modifier]

Rational Software Corporation a engagé James Rumbaugh de General Electric en 1994 et, par la suite, la société est devenue la source de deux des approches de modélisation orientée objet les plus populaires de l'époque :^[6] la technique de modélisation objet de Rumbaugh (OMT) et la méthode de Grady Booch. Ils ont rapidement été aidés dans leurs efforts par Ivar Jacobson, le créateur de la méthode de génie logiciel orienté objet (OOSE), qui les a rejoints chez Rational en 1995^[1].

Sous la direction technique de ces trois personnes (Rumbaugh, Jacobson et Booch), un consortium appelé "UML Partnerswas" s'est organisé en 1996 pour achever la spécification du langage de modélisation unifié (UML) et la proposer au groupe de gestion des objets (OMG) en vue de sa normalisation. Le partenariat comprenait également d'autres parties intéressées (par exemple HP, DEC, IBM et Microsoft). Le projet UML 1.0 des partenaires UML a été proposé à l'OMG en janvier 1997 par le consortium. Au cours du même mois, les partenaires UML ont formé un groupe, destiné à définir la signification exacte des constructions du langage, présidé par Cris Kobryn et administré par Ed Eykholt, pour finaliser la spécification et l'intégrer à d'autres efforts de normalisation. Le résultat de ce travail, UML 1.1, a été soumis à l'OMG en août 1997 et adopté par l'OMG en novembre 1997^[1][7].

UML 1.x [edit source | edit]

Après la première version, un groupe de travail a été formé ^[1] pour améliorer la langue, qui a publié plusieurs révisions mineures, 1.3, 1.4, et 1.5 ^[8].

Les normes qu'elle a produites (ainsi que la norme originale) ont été notées comme étant ambiguës et incohérentes. ^[9][10]

UML 2.x [edit source | edit]

La révision majeure de l'UML 2.0 a remplacé la version 1.5 en 2005, qui a été développée avec un consortium élargi pour améliorer encore le langage afin de refléter les nouvelles expériences d'utilisation de ses fonctionnalités. ^[11]

Bien que l'UML 2.1 n'ait jamais été publié en tant que spécification officielle, les versions 2.1.1 et 2.1.2 sont apparues en 2007, suivies par l'UML 2.2 en février 2009. UML 2.3 a été officiellement publié en mai 2010^{[12], UML 2.}4.1 en août 2011[^{12], UML 2.}5 en octobre 2012 en tant que version "In process" et officiellement publié en juin 2015[12^].

La spécification UML 2.x comporte quatre parties :

1. La superstructure qui définit la notation et la sémantique des diagrammes et de leurs éléments de modèle
2. L'infrastructure qui définit le métamodèle de base sur lequel la superstructure est basée
3. Le langage de contraintes objet (OCL) pour définir les règles des éléments de modèle
4. L'échange de diagrammes UML qui définit la manière dont les schémas UML 2 sont échangés

Les versions actuelles de ces normes suivent : UML Superstructure version 2.4.1, UML Infrastructure version 2.4.1, OCL version 2.3.1 et UML Diagram Interchange version 1.0^[13]. Il continue d'être mis à jour et amélioré par le groupe de travail de révision, qui résout tous les problèmes liés au langage. ^[14]

Conception [modifier la source | modifier]

Le langage de modélisation unifié (UML) offre un moyen de visualiser les plans architecturaux d'un système dans un diagramme (voir image), comprenant des éléments tels que :^[5]

• Toutes les activités (emplois)
• Les différentes composantes du système
• Et comment ils peuvent interagir avec d'autres composants logiciels.
• Comment le système fonctionnera
• Comment les entités interagissent avec les autres (composants et interfaces)
• Interface utilisateur externe

Bien qu'initialement destiné uniquement à la documentation de conception orientée objet, le langage UML (Unified Modeling Language) a été étendu pour couvrir un ensemble plus large de documentation de conception (comme indiqué ci-dessus)^[15], et a été jugé utile dans de nombreux contextes. [^16]

Méthodes de développement de logiciels [modifier la source | modifier]

UML n'est pas une méthode de développement en soi ^[17] ; cependant, elle a été conçue pour être compatible avec les principales méthodes de développement logiciel orienté objet de son temps (par exempleOMT, méthode Booch, Objectory) et surtout avec RUP qu'elle devait à l'origine être utilisée lorsque les travaux ont commencé chez Rational Software Inc.

Modélisation [modifier la source | modifier]

Il est important de faire la distinction entre le modèle UML et l'ensemble des diagrammes d'un système. Un diagramme est une représentation graphique partielle du modèle d'un système. Il n'est pas nécessaire que l'ensemble des diagrammes couvre complètement le modèle et la suppression d'un diagramme ne modifie pas le modèle. Le modèle peut également contenir de la documentation qui pilote les éléments du modèle et les diagrammes (comme des cas d'utilisation écrits).

Les diagrammes UML représentent deux vues différentes d'un modèle de système : ^[18]

• Vue statique (ou structurelle) : met l'accent sur la structure statique du système en utilisant des objets, des attributs, des opérations et des relations. La vue structurelle comprend des diagrammes de classe et des diagrammes de structure composite.
• Vue dynamique (ou comportementale) : met l'accent sur le comportement dynamique du système en montrant les collaborations entre les objets et les modifications des états internes des objets. Cette vue comprend des diagrammes de séquences, des diagrammes d'activités et des diagrammes de machines d'état.

Les modèles UML peuvent être échangés entre les outils UML en utilisant le format d'échange XMI (XML Metadata Interchange).

Diagrammes [éditer la source | éditer]

L'UML 2 comporte de nombreux types de diagrammes qui se divisent en deux catégories. Certains types représentent des informations structurelles, et les autres représentent des types généraux de comportement, dont quelques-uns représentent différents aspects des interactions. Ces diagrammes peuvent être classés hiérarchiquement comme le montre le diagramme de classes suivant :^[5]

Ces diagrammes peuvent tous contenir des commentaires ou des notes expliquant l'usage, la contrainte ou l'intention.

Diagrammes de structure [modifier la source | modifier]

Les diagrammes de structure mettent l'accent sur les éléments qui doivent être présents dans le système modélisé. Comme les diagrammes de structure représentent la structure, ils sont largement utilisés pour documenter l'architecture logicielle des systèmes logiciels. Par exemple, le diagramme de composants qui décrit comment un système logiciel est divisé en composants et montre les dépendances entre ces composants.

• Schéma des composants
• Diagramme de classe

Diagrammes de comportement [modifier la source | modifier]

Les diagrammes de comportement mettent l'accent sur ce qui doit se passer dans le système modélisé. Comme les diagrammes de comportement illustrent le comportement d'un système, ils sont largement utilisés pour décrire la fonctionnalité des systèmes logiciels. À titre d'exemple, le diagramme d'activité décrit les activités commerciales et opérationnelles, étape par étape, des composants d'un système.

• Diagramme d'activité
• Diagramme de cas d'utilisation

Diagrammes d'interaction [modifier la source | modifier]

Les diagrammes d'interaction, un sous-ensemble de diagrammes de comportement, mettent l'accent sur le flux de contrôle et de données parmi les éléments du système modélisé. Par exemple, le diagramme de séquence, qui montre comment les objets communiquent entre eux en termes de séquence de messages.

• Diagramme de séquence
• Schéma de communication

Méta-modélisation [modifier la source | modifier]

Article principal : Facilité Méta-Objet

Illustration de la facilité Méta-Objet

L'Object Management Group (OMG) a développé une architecture de métamodélisation pour définir le langage de modélisation unifié (UML), appelé Meta-Object Facility (MOF). Le Meta-Object Facility est conçu comme une architecture à quatre couches, comme le montre l'image de droite. Elle fournit un méta-modèle à la couche supérieure, appelée couche M3. Ce modèle M3 est le langage utilisé par le Meta-Object Facility pour construire des métamodèles, appelés M2-modèles.

L'exemple le plus marquant d'un modèle d'installation de méta-objets de couche 2 est le métamodèle UML, le modèle qui décrit l'UML lui-même. Ces modèles M2 décrivent des éléments de la couche M1, et donc des modèles M1. Il s'agit, par exemple, de modèles écrits en UML. La dernière couche est la couche M0- ou couche de données. Elle est utilisée pour décrire les instances d'exécution du système. ^[20]

Le méta-modèle peut être étendu en utilisant un mécanisme appelé stéréotypage. Ce mécanisme a été critiqué comme étant insuffisant/inaccessible par Brian Henderson-Sellers et Cesar Gonzalez-Perez dans "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

Adoption [éditer la source | éditer]

L'UML a été jugé utile dans de nombreux contextes de conception^{[16], à} tel point qu'il est devenu pratiquement omniprésent dans la communauté informatique. ^[22]

Il a été traité, parfois, comme une balle d'argent en matière de design, ce qui a entraîné des problèmes dans son utilisation. L'utilisation abusive de ce logiciel comprend l'usage excessif (concevoir chaque petite partie du système avec ce logiciel, ce qui est inutile) et l'hypothèse que n'importe qui peut concevoir n'importe quoi avec ce logiciel (même ceux qui n'ont pas programmé). ^[23]

Il est considéré comme une grande langue, avec de nombreuses constructions. Certains (dont Jacobson) estiment qu'il y en a trop et que cela entrave son apprentissage (et donc son utilisation). ^[24]

Critiques [éditer la source | éditer]

Les critiques les plus fréquentes de l'industrie à l'égard de l'UML sont les suivantes :^[4]

• pas utile : "[ne leur] offre pas d'avantages par rapport à leurs pratiques et représentations actuelles et évoluées"
• trop complexe, notamment pour la communication avec les clients : inutilement complexe" et "La meilleure raison de ne pas utiliser l'UML est qu'il n'est pas "lisible" pour toutes les parties prenantes. Combien vaut l'UML si un utilisateur professionnel (le client) ne peut pas comprendre le résultat de votre effort de modélisation".
• nécessité de maintenir la synchronisation entre l'UML et le code, comme pour la documentation en général

Critique d'UML 1.x [modifier la source | modifier]

Notation de la cardinalité

Comme pour les diagrammes de Chen, Bachman et ISO ER, les modèles de classe sont spécifiés pour utiliser des cardinalités "look-across", même si plusieurs auteurs (Merise, ^[25] Elmasri & Navathe [26] entre autres [27]⁾ préfèrent le même côté ou "look-here" pour les rôles et les cardinalités minimum et maximum. Des chercheurs récents (Feinerer, ^[28] Dullea et. entre autres ^[29]) ont montré que la technique du "look-across" utilisée par les diagrammes UML et ER est moins efficace et moins cohérente lorsqu'elle est appliquée à des relations n-aire d'ordre >2.

Selon M. Feinerer, "des problèmes surgissent si nous fonctionnons avec la sémantique "look-across" telle qu'elle est utilisée pour les associations UML. Hartmann ^[30] étudie cette situation et montre comment et pourquoi différentes transformations échouent". (Bien que la "réduction" mentionnée soit fallacieuse car les deux diagrammes 3.4 et 3.5 sont en fait les mêmes) et aussi "Comme nous le verrons dans les pages suivantes, l'interprétation croisée introduit plusieurs difficultés qui empêchent l'extension des mécanismes simples des associations binaires à n-aire".