Après une longue période de discussions techniques et stratégiques, l’OMG a voté, en juin 2003 à Paris, l’adoption du standard UML2.0.
UML2.0 n’est pas une simple mise à jour d’UML1.4.
Il s’agit d’une réelle évolution, qui porte en elle tous les germes de MDA.
Durant les années 70 et 80, on comptait tout au plus dix langages de spécification d’applications orientées objet.
Pendant la première moitié des années 90, on en recensait une cinquantaine.
Afin d’enrayer la multiplication des langages de spécification, G. Booch et J. Rumbaugh ont décidé en 1994 d’unifier leurs méthodes respectives:
OOADA (Object-Oriented Analysis and Design with Applications) et
OMT (Object Management Technique) au sein de la société Rational Software Corporation.
La première version de ces travaux est sortie en octobre 1995 sous le nom d’UML0.8.
Booch et Rumbaugh n’ont eu de cesse depuis d’unifier sous une même bannière toutes les méthodologies existantes.
I. Jacobson a rejoint cette initiative vers la fin de l’année 1995 avec sa méthode OOSE (Object Oriented Software Engineering).
Les autres méthodes de première génération ont ensuite été unifiées avec UML.
C’est aussi à partir de ce moment que les aspects méthodologiques ont été dissociés d’UML et ont été repris dans un autre projet, nommé RUP (Rational Unified Process).
Après 1995, l’initiative de Rational Software Corporation a intéressé d’autres industriels, qui ont vite compris les avantages qu’ils pouvaient tirer de l’utilisation d’UML.
C’est ainsi qu’une RFP (Request For Proposal) a été émise à l’OMG en 1996 pour la standardisation d’UML.
Rational ainsi que de nombreuses autres entreprises, telles que HP, MCI Systemhouse, Oracle, Microsoft et IBM, ont soumis leurs réponses à cette RFP, et UML1.0 est sorti vers la fin de l’année 1996.
Jusqu’à la version 1.4 élaborée par l’OMG, l’objectif fondamental était de résoudre le problème de l’hétérogénéité des spécifications.
L’approche envisagée a consisté à proposer un langage unifiant tous les langages de spécification et à imposer ce langage sur le marché pour qu’il soit très largement utilisé.
Cela a permis de tirer parti de l’expérience de tous les langages de spécification mais aussi de convertir assez facilement leurs utilisateurs.
La version 2.0 vise à faire entrer ce langage dans une nouvelle ère en faisant en sorte que les modèles UML soient au centre de MDA.
Cela revient à rendre les modèles UML pérennes et productifs et à leur permettre de prendre en compte les plates-formes d’exécution.
UML2.0 est composé de deux standards:
UML2.0 Superstructure, qui définit la vision utilisateur.
UML2.0 Infrastructure, qui spécifie l’architecture de métamétamodélisation d’UML ainsi que son alignement avec MOF.
On se focalise sur la partie UML2.0 Superstructure.
Le métamodèle UML2.0 Superstructure
Plus complet que ne l’était le métamodèle UML1.4.
Sa sémantique est plus précise que celle d’UML1.4, même si elle demeure informelle.
La notation graphique est intégralement alignée sur le métamodèle.
Architecture
le métamodèle UML2.0 Superstructure est découpé en trois parties :
La partie Structure : définit les concepts statiques (classe, attribut, opération, instance, composant, package) nécessaires aux diagrammes statiques tels que les diagrammes de classes, de composants et de déploiement.
La partie Behaviour définit les concepts dynamiques (interaction, action, état, etc.) nécessaires aux diagrammes dynamiques, tels que les diagrammes d’activités, d’états et de séquences.
La partie Supplement définit des concepts additionnels, tels que les flots de données, les templates et les types primitifs. Cette partie définit aussi le concept de profil.
La partie Structure
Les packages Structure
Classes. Contient plusieurs sous-packages, dont le sous-package kernel. Ces sous-packages définissent tous les concepts relatifs aux diagrammes de classes. Un concept réellement nouveau et intéressant est le concept de package merge.
CompositeStructure. Contient lui aussi plusieurs sous-packages, qui définissent tous les concepts permettant de spécifier la structure interne d’une classe
Components. Dépend fortement du package CompositeStructure et ne contient que deux sous-packages. Le package Components définit tous les concepts permettant de spécifier des composants.
Deployments. Contient plusieurs sous-packages, qui définissent tous les concepts permettant de spécifier le déploiement d’une application. Certains sous-packages sont propres au déploiement des applications à base de composants.
La partie Behaviour
Les packages Behaviour
CommonBehaviour. Définit les concepts de base nécessaires aux aspects dynamiques.
Activities. Définit les concepts permettant de spécifier des occurrences de suites d’actions dans une application.
Actions. Dépend fortement du package Activities. Le package Actions précise le concept d’action.
UseCases. Définit les concepts permettant de spécifier les cas d’utilisation d’une application.
Interactions. Définit les concepts permettant de spécifier les interactions entre instances dans une application.
StateMachine. Définit les concepts permettant de spécifier les états/transitions d’une application.
La partie Supplement
AuxiliaryConstructs. constitué :
d’un sous-package définissant les types de base d’UML.
d’un package définissant ce qu’est un modèle UML.
d’un package définissant ce que sont les flots de données.
d’un package définissant ce que sont les templates.
Profiles. Définit les concepts permettant de spécifier des profils.
Elle s’établit uniquement entre deux packages, un package source et un package cible.
Le package cible de la relation est appelé package mergé et le package source package mergeant.
Une relation merge entre packages implique des transformations sur le package mergeant.
La sémantique des transformations est la suivante :
Si une classe est définie dans le package mergé, il faut définir une classe qui lui corresponde (même nom, mêmes attributs, etc.) dans le package mergeant, à moins qu’il n’existe déjà une classe correspondante, ayant même nom, mêmes attributs, etc.
Si un package est défini dans le package mergé, il faut définir un package qui lui corresponde (même nom) dans le package mergeant, à moins qu’il n’y ait déjà un package correspondant (même nom).
Après cela, une relation de merge doit être établie entre les packages correspondants.
Pour UML 2.0, un composant est une entité modulaire d’une application, qui peut être facilement remplacée par un autre composant sans que cela ait un impact sur son environnement.
La notion d’interface de composant devient dès lors très importante.
Un composant a des interfaces offertes et des interfaces requises.
C’est d’ailleurs ce qui le caractérise pour son environnement.
La structuration interne d’un composant n’est pas visible de son environnement.
Une application à base de composants est donc constituée de composants connectés entre eux.
Remplacer un composant consiste à déconnecter le composant à remplacer et à connecter son remplaçant.
UML2.0 Superstructure ne définit que trois concepts propres au support du paradigme composant:
