J2EE .NET Application Generator

Transcription

J2EE .NET Application Generator
Ingénierie des modèles :
panorama et tendances
F. Barbier
1
Plan
Introduction à la 1ère
journée
Ingénierie des modèles :
panorama et tendances
2
Ingénierie des modèles, la 1ère journée

Processus
[ L’arrivée à maturité des langages de transformation et leur intégration rationnelle et
« réfléchie » dans les processus de développement logiciel
[ L’adaptation de processus propriétaire aux principes IDM en général
[ La codification de processus IDM sur-mesure

Cohérence
[ L’IDM est-elle un vecteur de correction de nos incohérences en développement logiciel ?

Traçabilité
[ Des exigences
[ Des décisions de conception
[ Des impacts techniques, financiers, humains… sur le déroulement d’un processus et le
pilotage d’un projet
[ Des retours arrière faisables et plausibles

Composants de confiance
[ Le multi-modèles est soit le multi-vues (e.g., Class Diagrams, Sequence Diagrams), le multicouches d’abstraction (PIM, PSM…) mais plus rarement le découpage modulaire d’une
application en entités réutilisables et surtout composables : MDE + CBSE ?
[ QoS, e.g., les modèles sont-ils les meilleurs moyens de prédiction de performance par
exemple ?
[ Tissage d’aspects dans les modèles pour insérer les propriétés de QoS requises (sécurité,
tolérance aux fautes, satisfaction de contraintes temps-réel…)
3
Choc des environnements IDM

Environnement « conceptuel » : Meta Object Facility (MOF)
[ Nouveaux langages : BPMN, SysML…
[ Domain profiles : santé, télécoms, espace…
[ Profils technologiques : SOA (SML), Executability (Activity Diagrams)…
[ Neutralité, crédibilité, partenariat (ISO)…

Eclipse Modeling Framework (EMF)
[ Standard d’usage et de renom
[ Richesse de l’offre en termes de plugins
[ Interopérabilité de fait mais MOF 1.3 uniquement (Ecore)
[ Impact à terme hors du monde Eclipse ?

DSL Tools Suite de Microsoft
[ Multi-langages : C#, J#, C++ CLI, VB.NET…
[ Culture modèle ? "The model is the application"
[ Conviction ou pur brouillage des pistes ?

NetBeans UML
[ Open Modeling API
[ Modeling Framework
[ Java Metadata Interface (JMI) 2 ? -> MOF 2
[ Simple stratégie de copie d’EMF ?
4
Freins à l’IDM
Offre
[ Instabilité quant au ciblage des plates-formes technologiques, e.g.,
(Hibernate/NHibernate) versus Java Persistence API (JPA)
[ Nécessité absolue de la métaphore Compilation/Exécution/Test avec parfois un
fort masquage des phases de transformation de modèles (code, assembleur,
hexa., Etc.)
[ Lisibilité de la technologie en tant que telle
[ Démonstrateurs à grande échelle (e.g., appli. Web avec plus de 1000 écrans)
[ Bilans, retours d’expérience succès versus échecs
[ Rapports d’étude prospective jusqu’à présent prudents (versus enthousiastes)
Demande
[ Barrières culturelles et psychologiques
[ Abstraction
[ Accroissement du rôle des systèmes d’information comme outils de gouvernance
et de création de valeur ajoutée
[ Coût d’entrée, ROI
[ Technology-independence !
5
Componentization des applications
Production d’applications plutôt monolithiques, référencement d’une DLL,
d’un EJB module… ?
Composants métier, e.g., composant de supply chain management
branché sur un bus de services pour une application de CPFR
(Collaborative Planning, Forecasting, Replenishment) ou comment
remplacer Coca Cola par Pepsi Cola et Carrefour par Auchan
Service-oriented computing
Bornage de modèles, versionnement, points d’ancrage, propriétés de
compatibilité, composabilité…
6
Sémantique
Sémantique formelle, i.e., sémantique mathématiquement assise
L’exécutabilité est à l’IDM ce que le test est à la programmation ou les maths
appli. aux maths pures, une approche par approximation…
Sémantique ?
Dans UML, le méta-élément Classifier hérite du méta-élément Type. Ainsi,
une instance de Class qui porte le stéréotype «type» est donc une classe
qui est un Classifier qui est un type : c’est rassurant. En revanche, une
instance de Class qui ne porte pas le stéréotype «type» n’est pas un type
mais une classe qui est un Classifier qui est un type : c’est déroutant
mais surtout contradictoire !
Quelles sont les conditions de
fabrication des méta-modèles ?
7
Convergence langages - modèles

Packages natifs javax.lang.model.* dans Java 6 (≠ JMI externe)
[ Ex. 1 : javax.lang.model.type.NullType versus VoidType d’OCL ?
[ Ex. 2 : javax.lang.model.type.PrimitiveType versus PrimitiveType de MOF ?

EMF : couche de réflexion évoluée. Pourquoi ne pas la substituer à la couche de
réflexion actuelle ?

Quand est-il des noyaux réflexifs des langages de programmation expérimentaux des
années 80 ?

Java a inventé l’eau chaude :
[ Principe de méta-modélisation, si tout « objet » est toujours l’instance d’un autre, il y a un
problème de régression infinie, d’où :
System.out.println("Absence de régression infinie du graphe d'instanciation Java : " +
Class.class.getName());
[ Résultat à l’écran :
Absence de régression infinie du graphe d'instanciation Java : java.lang.Class

L’IDM va-t-elle continuer à exister de façon « externe » aux langages de
programmation ?
8
La nature a horreur du vide…
Model-Driven SOA emerges : “I don't see where if you want to address SOA in
a scaleable way, you can go down that path without support for modeling.”
(http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1283790,00
.html)
“Rather than having models being imported and exported and generating code,
the model is the application and that breaks down the silos.”
(http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1280299,00
.html?bucket=NEWS&topic=300610)
Ex. de MDSOA (© Ed Seidweitz - Model-Driven Solutions - OMG, March 2008)
9
Conclusions, opinions
Le fossé existant entre les outilleurs et les utilisateurs finaux (applications
métier) doit être comblé
Les influences marquantes et significatives de l’IDM doivent être sans
cesse rappelées (POO, Méta. + POO, MOO, Méta. + MOO, Méta.-Méta.,
Objet, Composant, Service, Modèle modulaire
tissable/composable/transformable/versionnable/configurable…)
La phase actuelle de diversification des environnements IDM va
probablement libérer (rassurer) la demande
Le rapprochement modèle - langage est aujourd’hui une réalité observée
et sous-tend une complexification des langages de programmation.
Alternativement, l’argument en faveur de langages épurés accessibles à
tous reprend du poids : D, Ruby…
Que ces deux journées et en particulier celle d’aujourd’hui soient fructueuses
pour ceux d’entre vous acteurs de, ou utilisateurs bien engagés ou
s’engageant dans l’IDM !
10