Les approches de l’OMG

L’OMG est un consortium regroupant des industriels, des fournisseurs d’outils, et des académiques dont l’objectif principal est de développer des standards pour normaliser les différentes approches d’un domaine mais aussi pour contrôler la prolifération des technolo-gies. l’OMG définit plusieurs standards sur lesquels repose l’approche MDA. Nous pouvons citer : MOF [OMG,2011],OCL [OCL], UML[UML,a], SPEM [SPEM,2008], QVT [QVT,2011],

Figure 3.2 — La pyramide des niveaux de modélisation [Bézivin,2003]

etc. La plupart des approches de mise en œuvre, aussi bien dans le monde industriel qu’aca-démique, tentent de s’aligner sur ces standards.

La Figure3.3montre les couches de spécification du MDA. Dans le noyau se trouvent les standards de base (MOF, UML et CWM). La première couche représente les plates-formes supportées (Java, Corba, Web Service , ect.). La deuxième couche concerne les services sys-tème et enfin l’extérieur montre les domaines pour lesquels des composants métiers doivent être définis (Transport, Télécommunication, Finance, ...).

Figure 3.3 — Couches de spécifications du MDA [OMG,2013]

3.2.3.1 MOF (Meta Object Facility)

Le MOF [OMG, 2011] est le langage standard de plus haut niveau d’abstraction dans une architecture à trois niveaux. Le standard MOF apporte le support de définition des formalismes de modélisation sous la forme de méta-modèles comme UML, CWM et XMI. Il définit les éléments essentiels, la syntaxe et la structure des méta-modèles utilisés pour construire des modèles. Dans ce travail, nous nous intéressons aux deux langages de niveau

2. Ces deux langages sont conformes au MOF. Le premier langage est UML 2.x qui permet de créer des modèles, éventuellement à travers une spécialisation, ou par extension, via les profils UML. Le deuxième langage est SPEM 2, qui permet permet de définir des modèles de description de procédés.

3.2.3.2 Unified Modeling Language (UML)

UML [UML,a] est un langage de modélisation graphique et semi-formel normalisé par l’OMG. UML, ne fournit pas une méthode en soi, mais plutôt une notation graphique, qui peut être utilisée dans plusieurs contextes pour décrire des systèmes logiciels. UML permet de décrire les aspects fonctionnels, structurels et comportementaux d’un système en définis-sant treize types de diagrammes.

Dans sa version 2.0, offre la possibilité définir la structure, les concepts et les éléments du modèle ainsi que des éléments de sémantique indépendamment de la plateforme technolo-gique. Même si UML a été conçu pour pouvoir modéliser une grande variété de systèmes, il ne peut couvrir tous les domaines. C’est pour cela qu’ont été ajoutés des mécanismes d’ex-tension permettant de personnaliser et d’étendre le langage UML à un domaine ou à un besoin particulier.

Le Profil UML

La notion de pro ?l UML a été introduite dans les premières versions de la spécifica-tion UML. L’OMG définit la nospécifica-tion de profil comme suit [UML,a] : «The Pro ?les package contains mechanisms that allow metaclasses from existing metamodels to be extended to adapt them for different purposes. This includes the ability to tailor the UML metamodel for different platforms (such as J2EE or .NET) or domains (such as real-time or business process modeling). The pro ?les mechanism is consistent with the OMG Meta Object Facility (MOF) ».

Les profils UML permettent d’étendre le méta-modèle UML dans le cas où les dévelop-peurs ont du mal à exprimer des besoins spécifiques à leur domaine en se basant unique-ment sur des éléunique-ments déjà existant dans UML. La notion de profil est non seuleunique-ment un en-semble d’extensions qui permet à un utilisateur d’un domaine particulier (temps réel, BPM, etc.) d’entreprendre les activités liées à son domaine tout en utilisant UML, mai aussi, un ensemble d’extensions permettant d’adapter le méta-modèle UML à différentes plateformes techniques (J2EE, .Net, etc.).

Le profil contient des définitions de stéréotypes, des contraintes et des valeurs marquées sur les éléments du modèle. Les stéréotypes sont des annotations que l’on applique à des éléments de modélisation pour les spécialiser. Cependant, un stéréotype ne peut pas être instancié dans un modèle de l’utilisateur mais il peux être enrichie par un ensemble d’at-tributs (tagged values). Les valeurs marquées sont des paires "nom-valeur" qui ajoutent de l’information supplémentaire aux éléments stéréotypés. Ces informations sont ajoutées aux éléments lors de l’application d’un stéréotype à un élément.

3.2.3.3 Software System Process Engineering Metamodel ( SPEM 2.0)

Une définition de ce standard, qui correspond à nos besoins est présentée dans [SPEM, 2008] : The Software and Systems Process Engineering Meta-Model (SPEM) is a process enginee-ring metamodel as well as conceptual framework, which can provide the necessary concepts for mo-deling, documenting, presenting, managing, interchanging, and enacting development methods and processes.

SPEM permet de décrire les processus de développement logiciel. Le but de SPEM est aussi de permettre la réutilisation des processus et de la documentation.

Le but du standard SPEM [SPEM, 2008] est de proposer des concepts partagés par la communauté du génie logiciel pour décrire les processus de développement logiciel. Le développement du méta-modèle SPEM a été motivé par :

– L’abondance de différents concepts de modélisation des processus décrits dans des formats différents, en utilisant différentes notations

– La violonté d’assurer la cohérence entre ces différentes approches.

Ainsi le besoin de standardisation s’est posé et la norme SPEM a vu le jour.

La première version de la norme SPEM a été introduite par l’OMG en 2002. Cette première version était basé sur le standard UML 1.4. Des changements majeurs ont conduit à la version SPEM 2.0 [SPEM, 2008], qui est compatible avec UML 2. En raison de la conformité avec le standard UML, les diagrammes UML tels que les diagrammes d’activités ou diagrammes états peuvent être util pour visualiser des modèles du processus SPEM. SPEM 2.0 est décrit à la fois comme un mèta-modèle conforme à MOF et un profil UML. Comme profil UML, il bénéficie de l’outillage d’UML existant ainsi que des principaux diagrammes d’UML.

3.2.3.4 Architecture dirigée par les modèles (MDA)

L’architecture dirigée par les modèles ou MDA (Model Driven Architecture) [Soley, 2000] est une approche orientée modèle définie par l’Object Management Group (OMG) et rendue publique fin 2000. Cette approche spécifie trois niveaux d’abstraction ( niveau métier, niveau indépendant de la plateforme et niveau dépendant de plateforme)pour la descrip-tion d’une architecture d’un système et propose un processus de développement fondé sur ces trois niveaux et dirigé par les modèles.

L’idée de base du MDA est de séparer les spécifications fonctionnelles d’un système des spécifications de son implémentation sur une plate-forme cible donnée. Dans un processus de développement orienté MDA, tout est considéré comme modèle. Ainsi, MDA identifie quatre types de modèles : CIM, PIM, PDM et PSM.

- Le CIM (Computation Independent Model), appelé aussi modèle de domaine ou mo-dèle métier, modélise les exigences du système. Son but est d’aider à la compréhension du problème mais aussi de fixer un vocabulaire commun pour un domaine particulier. MDA ne fait aucune préconisation quant au langage à utiliser pour décrire les CIM. Par exemple, dans UML les modèles des exigences sont décrit en utilisant les digrammes de cas d’utilisa-tion ou encore avec l’utilisad’utilisa-tion de profils UML tels que SysML [SysML,2012].

- Le PIM (Platform Independent Model) ou modèle d’analyse et de conception abstraite de l’application. Ce modèle décrit le système sans montrer les détails de son utilisation sur une plate-forme particulière. Dans MDA, il est possible d’élaborer plusieurs modèles PIM indépendants de la plate-forme cible. Les modèles PIM ne contiennent aucune information sur les plates-formes d’exécution. Un PIM doit être raffiné avec les détails d’une ou plusieurs architecture(s) particulière(s) pour produire un PSM.

- Le PDM (Platform Description Model) décrit la plate-forme sur laquelle le système va être exécuté (par exemple des modèles de composants à différents niveaux d’abstraction comme CCM ou EJB).

- Le PSM (Platform Specific Model) ou modèle spécifique des plates-formes d’exécu-tion. PSM est le modèle produit par la transformation d’un PIM pour prendre en compte les informations techniques relatives à la plate-forme choisie. Le PSM peut être raffiné par transformations successives jusqu’à l’obtention d’un système exécutable.

La figure3.4donne une vue générale d’un processus MDA appelé couramment cycle de développement en Y en faisant apparaître les différents niveaux d’abstraction associés aux modèles.

Figure 3.4 — Principes du processus MDA [Combemale,2008]