|
| |
| TUTORIEL ALGO/METHODES |
 |
|
|
| Le cheminement théorique de MDA |
| Ce standard du développement place le modèle au cœur de l'architecture logicielle, en prévoyant la génération directe du code source, et donc de l'application compilée, à partir de diagrammes Objet détaillés.
(02/12/2005) |
  |
Tel que nous l'avons déjà présenté
(lire notre
article du 06/07/04), le processus MDA semble être l'idéal
du développement : pouvoir générer, à partir d'un modèle
indépendant, le code source d'une application, et par extension
l'application elle-même, compilée pour une plate-forme parmi
d'autres. En poussant plus loin, il serait possible
de générer une application fonctionnelle directement depuis
des diagrammes UML.
Ce qui peut sembler de la science-fiction tient néanmoins du
futur proche pour l'OMG, et commence à apparaître comme une
réalité chez certains éditeurs d'outils.
La plupart des outils
actuels n'ont qu'une approche "code" du développement d'application
: le développeur accède directement au code source (ou aux composants
graphiques de l'éditeur, comme Delphi ou Visual Basic), le modifie
aussi profondément qu'il en est besoin, et le compile pour une
plate-forme précise. La seule modélisation accessible consiste
en la création de bibliothèques spécialisées. La conception
elle-même est extérieure à l'outil.
La nouvelle
génération d'outils place code et modèle au même niveau
Certains
outils autorisent le développeur à afficher le diagramme UML
du code qu'il écrit, ainsi qu'à modifier le diagramme UML et ainsi
voir le code modifié en conséquence. Code et modèle sont donc
étroitement couplés, et leur synchronisation laisse la conception
graphique influer directement l'application résultante. C'est
donc un pas de plus, assez conséquent, vers l'objectif MDA.
Seulement, le modèle seul ne peut encore guère générer plus
que des coquilles de classes, à charge pour le développeur de
les compléter.
L'objectif est d'élever encore la discussion à un niveau plus
abstrait, et de se baser avant tout sur les modèles.
Ceux-ci doivent alors être considérablement plus détaillés,
et inclure une représentation de toutes les couches de l'application.
La logique métier sera ainsi représentée en UML. Si on lui associe
correctement les caractéristiques MDA, le passage du code compilé
d'une plate-forme à une autre consistera simplement à reprendre
cette logique métier spécifiée en MDA, et à lancer la génération
de code vers une cible différente.
En définitive, le passage d'un PIM (Platform Independant Model
: UML) à un PSM (Platform Spécific Model : Java, .NET, XML Schema...)
est au coeur de l'architecture MDA. Le modèle se charge de décrire
les détails Objet de l'application, et les langages utilisés
par MDA (MOF, XMI...) détiennent de leur côté les règles de
génération de code et de transformation du modèle à l'application.
Pour MDA, la logique métier doit ainsi être spécialisée au
sein de technologies intermédiaire (middleware) : Corba,
les protocoles Web, et Java/.NET. L'OMG a ensuite établi les
infrastructures Objet distribuées : nommage avec UDDI ou LDAP,
transaction, persistance, sécurité, évènements... Par ce biais,
MDA cherche à créer une architecture conceptuelle de transformation
de modèle à code, pour en définitive revoir amplement les méthodes
de développements.
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
En mettant le modèle au cœur de celui-ci, MDA non seulement
favorise l'interaction modèle-code, quasiment à la volée, mais
ouvre la conception logicielle à l'ensemble de l'équipe responsable
du logiciel, non plus seulement les développeurs. |
|
|
|
