Gagne de la cryptomonnaie GRATUITE en 5 clics et aide institut numérique à propager la connaissance universitaire >> CLIQUEZ ICI <<

7.1.3.1 Les principaux modèles du MDA

Non classé

Les principaux modèles du MDA sont :

· Le modèle des exigences (Computational Independent Model, CIM)

Il s’agit d’un modèle de haut niveau qui représente l’application et qui permet de définir les
services qu’elle va offrir et les relations qu’elle aura avec les autres entités. Ces modèles ont
pour objectif d’être pérennes et de refléter la relation entre les exigences du client et
l’application. Dans les CIM, aucune information sur le fonctionnement de l’application ne
doit être incluse. En UML, on peut représenter un modèle d’exigences avec un diagramme
de cas d’utilisation. Il offre la faculté de définir l’ensemble des acteurs et des cas
d’utilisation sans en détailler le fonctionnement.

· Le modèle d’analyse ou de conception abstraite (Platform Independent Model, PIM).

Il a pour objectif de structurer l’application en modules et sous-modules. Ces modèles font
le lien entre le modèle des exigences et le code de l’application et se doivent d’être pérennes.
Pour ce faire, ils ne doivent pas contenir d’informations sur les plates-formes ou langages
qui seront utilisés.

· Le modèle des plates-formes (Platform Dependent Model, PDM)

Ce modèle sert à décrire une architecture technique qui sera appliquée au PIM pour obtenir
le PSM.

· Le modèle de code (Platform Specific Model, PSM).

Contrairement au modèle d’analyse ou de conception, le modèle de code est lié à une plateforme
d’exécution. Il sert principalement à faciliter la génération de code. Les PSM peuvent
être obtenus par application de profils UML, c’est-à-dire l’adaptation d’UML à un domaine
particulier, ou par l’utilisation de modèles de plates-formes (PDM) lors de la transformation
du PIM. Etant liés à une plate-forme d’exécution, les modèles de code n’ont pas pour
vocation d’être pérennes.

Figure 36 Stratégie de test au sein du processus d’évolution d’architecture de SodifranceFigure 36 : diagramme de classes du MOF1.4

(Blanc 2005, p.39)(Object Management Group 2002a)

Figure 37 Stratégie de test au sein du processus d’évolution d’architecture de SodifranceFigure 37 : les quatre niveaux de l’architecture du MDA (Blanc 2005, p.40)

Page suivante : 7.1.3.2 L’architecture du MDA

Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance