Il y a plusieurs façon de concevoir l’architecture d’une application : TDA (Test Driven Architecture), SOA (Service Oriented Architecture), [ … ] et une qui gagne à être connue : MDA (Model Driven Architecture).
Contrairement aux autres architectures, le lien entre la conception et le code est très fort. Une modification sur le modèle entraîne sa répercussion sur l’architecture. Evidemment, l’on peut déjà avoir ce genre de comportement avec des outils tels que Together Architect, qui permettent de lier un diagramme de classes aux classes développées et vice versa (Reverse Engineering). Mais le principe de la MDA et d’AndroMDA (prononcez Andromeda) va au délà : à partir d’un modèle UML, vous pouvez générer votre application (tout du moins, son squelette) dans n’importe quel langage, du moment que le “processus” a été défini avant.
Comment définit-on un processus ? C’est simple : en tout premier lieu, on définit ce que l’on appelle un PIM (Plateform Independant Model) généralement rédigé en UML (ou dans d’autre langages). Puis, c’est à ce niveau qu’AndroMDA intervient, à partir de ce PIM et d’une cartouche donnée, on obtient un PSM (Platform Specific Model) qui représente le code qui aurait été généré s’il avait été codé à la main.
La notion fondamentale de cartouche (cartridge) est, au sens AndroMDA, n’est plus ni moins qu’un template de génération de code. Il en existe déjà de nombreuses (Spring, Hibernate, Struts, …) qui sont toutefois très orientées J2EE, mais la création de nouvelles cartouches est ouverte !
Les avantages des cartouches sont nombreux :
-
Vous rédigez des cartouches spécifiques à vos besoins, qui vous permettent de coller au maximum à vos exigences
-
Vous pouvez réutiliser cette cartouche pour d’autres projets.
-
Vos applications deviennent faciles à migrer vers d’autres plateformes, en changeant juste la cartouche.
-
La séparation des métiers (Fonctionnelle / Technique) est facilitée
Avouez que sur le papier, c’est plutôt séduisant …
Pour plus d’information à ce sujet, => www.andromda.org
