Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 1 - Ingénierie des Modèles Logiciels Cours #3 De OMA vers MDA, Des objets vers les modèles Jean.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 1 - Ingénierie des Modèles Logiciels Cours #3 De OMA vers MDA, Des objets vers les modèles Jean Bézivin Jean.Bezivin@irin.univ-nantes.fr Jean.Bezivin@irin.univ-nantes.fr Equipe ATLAS (INRIA & IRIN), Nantes

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 4 - La nouvelle crise du logiciel Première crise : 1965 Solutions? (NATO Summer School 1967): "Software engineering" "Structured programming" "Top-down approaches" Seconde crise : 2000 Solutions? (OMG november 2000): La PPO ou la PPC ne constituent que des réponses très partielles à la montée en complexité. Seules elles sont aujourd'hui insuffisantes. "MDA : Decouple neutral business models from variable platforms" "Transformations as assets"

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 5 - Les systèmes deviennent plus complexes Volume croissant Des données Du code Évolutivité croissante De la partie métier (mondialisation, concentrations, restructurations, …) De la partie plate-forme d'exécution Hétérogénéité croissante Des langages et des paradigmes Des supports de données et des protocoles d'accès Des systèmes et des plates-formes Des technologies Le rythme d'arrivée des nouvelles technos s'accélère Ce rythme ne se ralentira pas Les vielles technos ne meurent pas, elles se cachent

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 6 - Exemple typique Un jeune ingénieur en sortie de Bac+5 et ayant des connaissances de base en Java, XML et UML se voit invité, lors de son arrivée en entreprise et avant de commencer son travail, à lire le lundi le rapport public J2EE v1.4 de 228 pages Dans les six premières pages de ce rapport il est fait référence à : EJB, JSP, JMS, JMX, JCA, JAAS, JAXP, JDBC, JNDI. Cette nouvelle version de J2EE est la version Web services et on suppose donc connus les concepts SOAP, SAAJ, JAX-RPC et JAXR Chacun des acronymes cités correspond à une spécification La spécification de EJB 2.1 correspond à un document pdf de 640 pages qui sera lue le mardi Le mercredi sera consacré à la lecture du document Servlet 2.4 PFD specification de 307 pages Le jeudi il s'attaque à la lecture du document JSP 2.0 PFD specification de 374 pages Et ainsi de suite … Au bout d'un mois de lectures, notre ingénieur est enfin prêt à commencer le travail productif … D'après "Is complexity hurting Java?" de Jason Weiss, dans Java Developer's Journal, Vol. 7, Issue 10, Octobre 2002.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 8 - Que faire ? (… sachant que de ne rien faire est une option de plus en plus coûteuse et dangereuse) (… sachant que la complexité a atteint un tel niveau qu'il est hors de portée d'un seul individu d'avoir une vision globale sur un système en évolution) Accélérer encore la course aux nouvelles technologies dans l'espoir qu'une nouvelle solution magique se présente ? Fuite en avant ? Les technologies doivent être évaluées essentiellement pour leur capacité d'intégration de maîtrise de la complexité

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 10 - Des objets aux modèles Les maladies infantiles de l'objet Les limites du tout-objet Le sans-couture, pas sans danger Les patrons et le savoir-faire architectural Les cas d’utilisation Le syndrome du wrapper fou La portabilité perdue Le rendez-vous manqué de l'extensibilité Le "cross-cutting" et les aspects Une crise majeure ? L'impossible salut par les composants Services, le retour Prise en compte des aspects non-fonctionnels Vers une gestion cohérente des aspects multiples

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 11 - On a menti sur les objets "En raison des formidables capacités unificatrices du paradigme objet, le passage de la technologie procédurale à la technologie des objets apportera une énorme simplification conceptuelle pour l’ingénieur logiciel. Comme tout sera considéré comme objet (principe du tout-objet), on assistera à une formidable réduction du nombre de concepts nécessaires." Tous ensemble, circa 1980 La technologie des objets n'a pas tenu ses promesses de simplification. Les limites du tout-objet

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 12 - Des organisations de complexités croissantes Technologie procédurale Technologie des composants Technologie des objets Objets, Classes, Méthodes Procédures Beans, Components, Containers, Packages, Interfaces, Use cases, Scenarii,Services, Frameworks, Applications, Patterns, Aspects, etc. 19801995

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 13 - Seamlessness considered harmful objet «abstrait» objet «concret» analyse conception codage x x' x'' Hypothèse (naïve) : Il y a correspondance exacte entre les objets métier et les objets programme. Conséquence (fausse) : il est possible de "raffiner" les objets comme on raffinait autrefois les procédures.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 14 - Correspondance exacte ? Etudiant Filière Diplôme Examen Enseignant Cours Modèle d'analyse Etudiant Filière Diplôme Examen Enseignant Cours Modèle de conception Etudiant Filière Diplôme Examen Enseignant Cours Modèle de codage NB: M. Jackson qui est à l'origine de cette conjecture de correspondance n'avait jamais préconisé la correspondance exacte. NB: Quid de la persistance, des objets systèmes, de la gestion d'IHM, etc.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 15 - Une organisation plus réaliste Modèle de service Modèle de métier Modèle de ressources Modèle de conception Modèle de code fusion La plate-forme (CORBA, EJB, DotNet, … ); Le contexte; Le modèle neutre et stable de l'entreprise; Les objets métier, les règles métier, les processus métier; Les use cases; Les racines applicatives fonctionnelles; Les fonctions selon JSD; Le code exécutable;

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 16 - Les services sont-ils des objets ? f bac gedhi lkjmn qpors Configuration sous-jacente le problème Architecture non stable. À suivre Les services sont-ils des objets ? Racines fonctionnelles

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 17 - La guerre des services L'objet a toujours méprisé les services, cf. : public static void main (String argv [ ]) Les pères fondateurs (Jackson, Meyer, …) ont initialement argumenté de la faible résistance aux changements des architectures basées sur les services Aujourd'hui les services reviennent en force avec de nouvelles propriétés (dynamisme, composabilité, réutilisabilité, introspection, …) Ils réalisent des promesses que l'objet n'a pas pu réaliser (simplicité, interopérabilité, …) Le MDA est une façon de contrôler les mouvements du balancier objetsservices Le balancier oscille de l'ignorance totale des services (débuts de l'objet) vers une réhabilitation totale et un passage au premier plan (WS).

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 18 - Réutilisabilité : l'erreur de calcul historique Le Discours des années 80 : Il existe un gisement extraordinaire d'économies L'industrie du logiciel peut représenter jusqu'à 5% du PIB des pays industrialisés 85% du code produit par les informaticiens est du tout venant (gestion de tables, tris, etc.) et pourrait donc être réutilisé si l'on disposait de mécanismes adéquats comme l'héritage des langages à objets. 5% x 85 % = 4,25% 5% x 50% x 10% = 0,25% Chiffres courants: Analyse et conception : 50% Codage : 10% Mise au point : 40% 2002 : le compte n'y est pas !

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 19 - Les patrons sont-ils des objets ? Template method Factory method Abstract Factory Strategy Decorator Adapter Composite Flyweight Visitor Memento Proxy Bridge Iterator implements with often uses sharing strategies sharing composites enumerating children defining traversals saving state of iteration GoF : pas de relation d'héritage entre les patrons.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 20 - Le rendez-vous manqué de l'extensibilité En 1980 : la technologie des objets va apporter des propriétés d'extensibilité aux logiciels d'application En 2002 : Quel est le mécanisme de terrain permettant de réaliser l'extensibilité d'application au quotidien : c'est indubitablement le mécanisme du plug-in Qu'est ce qu'un plug-in (version Netscape)? Plug-ins are software programs that extend the capabilities of the Netscape Browser in a specific way - giving you, for example, the ability to play audio samples or view video movies from within your browser. Exemples : Apple Quick Time, Adobe Acrobat Reader, Macromedia FlashPlayer et ShockWave, RealNetworks RealPlayer, Net2Phone, etc. Est-il possible de faire des plug-ins de plug-ins? Comment gérer les incompatibilités de plug-ins ? Comment sont modélisés les concepts d'application et de plug-in d'application (extension) ?

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 23 - Les plug-ins Eclipse en XML <!ATTLIST plugin name CDATA #REQUIRED id CDATA #REQUIRED version CDATA #REQUIRED vendor-name CDATA #IMPLIED > <!ATTLIST import pluginCDATA#REQUIRED versionCDATA#IMPLIED match(exact | compatible) "compatible« > <!ATTLIST library nameCDATA #REQUIRED > <!ATTLIST export nameCDATA #REQUIRED > <!ATTLIST extension-point nameCDATA #REQUIRED idCDATA #REQUIRED schemaCDATA #IMPLIED > <!ATTLIST extension pointCDATA #REQUIRED idCDATA #IMPLIED nameCDATA #IMPLIED >

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 24 - AOP : un problème bien identifié … We have found many programming problems for which neither procedural nor object-oriented programming techniques are sufficient to clearly capture some of the important design decisions the program must implement. This forces the implementation of those design decisions to be scattered through-out the code, resulting in "tangled" code that is excessively difficult to develop and maintain. We present an analysis of why certain design decisions have been so difficult to clearly capture in actual code. We call the properties these decisions address aspects, and show that the reason they have been hard to capture is that they cross- cut the system's basic functionality. We present the basis for a new programming technique, called aspect-oriented programming, that makes it possible to clearly express programs involving such aspects, including appropriate isolation, composition and re-use of the aspect code. from Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier, John Irwin. In proceedings of the European Conference on Object-Oriented Programming (ECOOP), Finland. Springer-Verlag LNCS 1241. June 1997. … mais des solutions contestables … AOP  AOSD

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 25 - Les aspects sont-ils des objets ? Debugging directives Optimisation directives Synchronization Exceptions Code exécutable Algorithmique Code d'organization (#include, etc.) preconditions postconditions AOP: le code comme référentiel unique.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 26 - Le syndrome du wrapper fou Avantages et inconvénients de l’utilisation des emballeurs d’objets (wrappers) pour applications existantes. Dégats écologiques importants à moyen et surtout à long terme de la "Tchernobilization du logiciel" qui consiste à recouvrir l'existant de chapes technologiques successives. Tchernobyl Un sarcophage de béton recouvre désormais le réacteur #4 de la centrale de Tchernobyl.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 27 - La loi de Moore Formulée pour la première fois par Gordon E. Moore en 1965, elle postule le doublement annuel des performances des circuits intégrés (mémoires et processeurs). Moore a revu son estimation en 1975 : le doublement aurait lieu tous les 18 mois et non tous les ans. Cette "loi", fondée sur un constat empirique, a été vérifiée par la suite. Moore estime qu'elle se poursuivra jusqu'en 2017, date à laquelle elle devrait rencontrer des contraintes physiques. Cette annonce a incité les ingénieurs à concevoir des systèmes très en avance sur les possibilités du jour de leur conception. Plus la capacité mémoire croit, plus la taille des programmes augmente pour l’occuper... Understand, maintain, migrate, etc. Execute, etc.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 28 - Objets vs. Modèles : ce n'est qu'un volet du débat Transformational approaches Interpretative approaches 1950197520002025 compiler compiler's OS Dist. OS + Middleware MDA La proportion de code automatiquement généré par rapport au code directement produit à la main tend à croître très rapidement. À certains égards Java tient déjà la place du langage d'assemblage et UML du langage de haut niveau.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 29 - MDA : une pause dans les approches interprétatives ? Intel Motorola Sun Unix Intel Motorola Sun Windows CORBA Intel Motorola Sun Unix Intel Motorola Sun Windows Java Super-plateforme ?

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 31 - La cote des paradigmes objets composants processus règles services événements, transactions, etc. Par exemple : Un modèle de services est mieux adapté à la techno Web actuelle (WebServices, SOAP, WSDL, WSFL, etc.) Un modèle de services s'accommode beaucoup mieux qu'un modèle d'objets ou de composants aux extensions non- fonctionnelles Un modèle de services s'interface beaucoup plus facilement avec un modèle de workflow qu'un modèle d'objets La technologie des modèles permet de subsumer la plupart de ces paradigmes et bien d'autres.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 32 - Objects have failed (Richard Gabriel, OOPSLA 2002) The object-oriented approach does not adequately address the computing requirements of the future. Object-oriented languages have lost the simplicity —some would say purity— that made them special and which were the source of their expressive and development power. Powerful concepts like encapsulation were supposed to save people from themselves while developing software, but encapsulation fails for global properties or when software evolution and wholesale changes are needed. … Objects promised reuse, and we have not seen much success. … The over-optimism spawned by objects in the late 1990s led businesses to expect miracles that might have been possible with objects unpolluted by static thinking… Objects require programming by creating communicating entities, which means that programming is accomplished by building structures rather than by linguistic expression and description through form, and this often leads to a mismatch of language to problem domain. Object design is like creating a story in which objects talk and interact with each other, leading people to expect that learning object-oriented programming is easy, when in fact it is as hard as ever. Again, business was misled. People enthused by objects hogged the road, would not get out of the way, would not allow alternatives to be explored —not through malice but through exuberance— and now resources that could be used to move ahead are drying up. But sometimes this exuberance was out-and-out lying to push others out of the way. http://www.dreamsongs.com/ObjectsHaveFailedNarrative.html

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 33 - Les limites des objets et des composants Les patrons de conception ne sont pas des objets Les aspects ne sont pas des objets Les applications ne sont pas des objets Les services ne sont pas des objets Les objets ont échoué dans prise en compte de la concurrence Les objets ont échoué dans la recherche de simplicité Les objets ont échoué dans la recherche de l'extensibilité Les objets ont échoué dans la recherche de l'intégration Les objets ont échoué dans leur tentative d'intégration des SGBD Les objets ont raté le rendez-vous du Web (URI, etc) La technologie des composants n'est qu'une fuite en avant et apporte peu d'espoir pour une sortie de crise. Elle accentue la complexité des solutions. Les logiciels à composants seront le «legacy» de demain.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 34 - Conclusion La TdO (Technologie des Objets) a eu à répondre à de nombreux défis depuis sa diffusion industrielle dans les années 1980 De façon générale, elle n'a pas réussi à trouver en son sein, les moyens de répondre à ces défis En conséquence les solutions trouvées sont souvent baroques, informelles, non généralisables difficilement combinables. Technologie des Objets Use cases Aspects Patterns etc.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 35 - Conclusion L'IdM (Ingénierie des Modèles) semble être en mesure de répondre à certains de ces défis pour lesquels la TdO n'a pas su trouver des réponses internes. Parmi ceux-ci on pourrait citer : Gestion séparée des aspects Prise en compte homogène des éléments fonctionnels et non- fonctionnels Intégration homogène de points de vue différents (règles, services, processus, architecture, etc.) etc. L'IdM semble pouvoir subsumer la TdO et offrir une voie d'évolution progressive aux solutions actuelles à base d'objets et de composants. TdO Use cases Aspects Patterns etc. IdM QoS Règles Processus Applications Services

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 37 - Les deux crises du logiciel Octobre 1968 Rapport de l'école NATO Science Committee qui invente le terme "génie logiciel" Octobre 2000 Rapport de Richard Soley "de l'OMA vers le MDA"

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 38 - MDA: La nouvelle vision de l'OMG "OMG is in the ideal position to provide the model-based standards that are necessary to extend integration beyond the middleware approach… Now is the time to put this plan into effect. Now is the time for the Model Driven Architecture." Richard Soley and the OMG staff, MDA Whitepaper Draft 3.2 November 27, 2000 (appel à contribution)

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 39 - New orientation for OMG activities New step beyond the Object Management Architecture (OMA) Models are centric! Target middleware is not important! Focus on Platform Independent Models (PIM) Without middleware details Abstract Platform Specific Models (PSM) Including all middleware details Define PIM to PSM transformations Preserving PIM when new middleware appears! Model Driven Architecture

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 42 - Déclaration (d'intention) We can generate a lot of the code and reduce the need for hand programming by an order of magnitude, and in some restricted cases we will be able to generate all of the code. David Frankel, Chief Scientist, IONA/Genesis and OMG Architecture Board Member Modeling as much of the application semantics as precisely as possible enables a greater degree of code generation. Sridhar Iyengar, Fellow, Unisys Corporation and OMG Architecture Board Member

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 43 - La séquence n'a pas de fin It's difficult -- in fact, next to impossible -- for a large enterprise to standardize on a single middleware platform. Some enterprises found themselves with more than one because their different departments have different requirements, others because mergers or acquisitions created a mix. Even the lucky enterprise with a single middleware choice still has to use other technologies to interoperate with other enterprises and B2B markets. The middleware environments that are most visible today are CORBA, Enterprise JavaBeans, messageoriented middleware, XML/SOAP, COM+ and.NET. However, over the past decade or so, the middleware landscape has continually shifted. For years we've assumed that a clear winner will emerge and stabilize this state of flux, but it's time to admit what we've all suspected: The sequence has no end! And, in spite of the advantages (sometimes real, sometimes imagined) of the latest middleware platform, migration is expensive and disruptive. (We know an industry standards group that, having migrated their standard infrastructure twice already, is now moving from their latest platform du jour to XML.) from Richard Soley and the OMG staff, MDA Whitepaper Draft 3.2, November 27, 2000

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 44 - MDA: le plan de bataille The next step is to generate application code itself. For component environments, the system will have to produce many types of code and configuration files including interface files, component definition files, program code files, component configuration files, and assembly configuration files. The more completely the platformspecific UML dialect reflects the actual platform environment, the more completely the application semantics and runtime behavior can be included in the platformspecific application model and the more complete the generated code can be. In a mature MDA environment, code generation will be substantial or, perhaps in some cases, even complete. Early versions are unlikely to provide a high degree of automatic generation, but even initial implementations will simplify development projects and represent a significant gain, on balance, for early adopters, because they will be using a consistent architecture for managing the platformindependent and platformspecific aspects of their applications.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 45 - Mappings Because the MDA is platformindependent at its core, adding new middleware platforms to the interoperability environment is straightforward: After identifying the way a new platform represents and implements common middleware concepts and functions, OMG members will incorporate this information into the MDA as a mapping. Various messageoriented middleware tools, XML/SOAP and.NET will be integrated in this way Going one step further, by rationalizing the conflicting XML DTDs that are being proposed in some industries, the MDA can even help you interoperate across them.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 46 - Standardizing Domain Models Since January 1996, a sizeable percentage of OMG members have been meeting in Domain Task Forces, communities focused on standardizing services and facilities in specific vertical markets. Until now these specifications have consisted of interfaces written in OMG IDL with accompanying semantic description in English text. Standardizing components at a platform level, in terms of standards such as CORBA, is certainly a viable contribution to solving the integration and interoperability problem, but we can do something additional.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 47 - CORBA ? CORBA is a foundation of this new architecture. As the only vendor and languageindependent middleware, it is a vital and necessary part of the MDA superstructure; software bridges would be hard to build without it. Extending this superstructure, the MDA is expressed completely in terms of modeling concepts, moving the reuse equation up one level.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 48 - Extension du rôle de l'OMG We are continuing our quest to support integration and interoperability across heterogeneity at all levels. Our first mission, to enable integration through the introduction of the distributed object model, is complete: objects are the way systems are built today, at the core of every vendor's enabling architecture and also at the core of all ebusinesses. But the integration task is not yet done. To focus on this, OMG will extend our focus from a middlewarecentric to a modeling centric organization.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 49 - Declaration Over the past decade or more, companies have endured a succession of middleware platforms. Jon Siegel, OMG Director of Technology Transfer CORBA was a powerful first step, but we have more steps to take. Fred Waskiewicz, OMG Director of Standards Companies that adopt the MDA gain the ultimate in flexibility: the ability to derive code from a stable model as the underlying infrastructure shifts over time. ROI flows from the reuse of application and domain models across the software lifespan. Dr. Richard Soley, OMG Chairman and CEO

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 51 - Les patrons en colère Nous ne voulons plus payer le prix fort uniquement pour porter notre système informatique vers une nouvelle plate-forme de middleware (COM, CORBA, Java, HTML, XML, DotNet, Cluster, Grid, etc.) alors que notre modèle métier reste stable. D'autant plus que nous avons déjà donné pour ce type de migration sans aucun retour sur investissement ($$$!!!). Tout ce que nous pouvons accepter c'est de payer une dernière fois pour la construction de modèles abstraits de notre métier et des services associés, modèles qui nous garantiront contre l'obsolescence technologique des plate- formes. À partir de ce moment, tout nouveau fournisseur de plate- forme, s'il désire nous voir acheter sa solution, sera prié de nous livrer en même temps que sa plate-forme les outils de transformation permettant de générer vers cette plate-forme à partir des modèles neutres de métier et de service.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 52 - Tir sur cible mobile Business Model 1BM 2BM 3 Product line or application development Platform 1Pf 2Pf 3Pf 4Pf 5Pf 6Pf 7 Pf 8 SpecificationImplementation and Tests Usage and maintenance Pascal; C; ADA; Linux; Smalltalk; C++; Com/DCOM; Apple OS; PowerBuilder; CORBA; Java; EJB; DotNet; C#; XML; SOAP; Web services; etc. Évolutions mineures Évolutions majeures Pf 9 Le changement de plate-forme était jusqu'à présent un événement exceptionnel; Il devient de plus en plus une opération de routine. Cette opération doit être prise en compte de façon explicite dans le cycle de développement du logiciel.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 53 - La guerre des intergiciels est finie COM+ DCOM CORBA IIOP Microsoft C# & DotNet XML SOAP Java EJB de Sun HTTP HTM L  Il n'y a ni vainqueur ni perdant  Le prochain champ de bataille sera celui de la transformation de modèles  L'initiative MDA de l'OMG vise à promouvoir l'idée de la mise en œuvre de systèmes distribués dirigée par les méta- modèles + la prochaine merveilleuse plateforme de Middleware (~2005) Réaction de Sun's à C# & DotNet ?

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 54 - Correspondance vers des plate-formes multiples et évolutives COM+ DCOM CORBA C# DotNet XML SOAP Java EJB HTTP HTM L  MOF et UML constituent le cœur de la technologie MDA.  Hypothèse : Des modèles technologiquement neutres peuvent être mis en œuvre sur sur une grande variété de technologies de plate- formes. Modèles neutres basés sur UML et MOF

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 55 - UML (+OCL) vs. IDL interface Compte { attribute short numéro; attribute float solde; }; IDL: sémantiquement léger par définition UML: CORBA sémantiquement enrichi

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 59 - Les éléments des différents modèles sont dépendants Modèle métier UML Vehicle Truck Modèle de code Java Vehicle Truck comesFrom specializes extends Problème : Comment prendre en compte de façon précise les relations inter-modèles comme les relation intra-modèles ? Constat : Les problèmes de traçabilité, de transformation, de tissage d'aspects sont des cas particuliers de la mise en correspondance de modèles. Ils doivent se traiter au niveau des méta-modèles.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 60 - Méta-modèle de correspondance Méta-modèle de tissage Méta-modèle de transformation Méta-modèle de traçabilité Méta-modèle d'alignement etc.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 65 - Exemple d'un méta-modèle Java élémentaire Le nom du constructeur est celui de la classe qui le définit : Constructor self.name = self.ClassOrInterface.name

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 66 - Fragment d'un méta-modèle UML Un constructeur ne renvoie pas de résultat (pas de valeur retournée) : Context Constructor self.methodSignature.result.size() = 0

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 67 - Exemple d'un méta-modèle Java élémentaire Une méthode ne peut prendre deux paramètres de même nom : Method self.methodSignature.parameter->forAll(P1,P2) P1.name <> P2.name

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 69 - Au cœur du MDA: les PIMs et les PSMs Modèles MDA PIM: Platform Independent Model Spécification neutre d'un système (modèle de métier et de service) qui ignore tous les détails de mise en oeuvre Exemple: système de facturation exprimé en UML PSM: Platform Specific Model Modèle de métier et de service lié à un modèle de plate- forme Exemple : Système de facturation exprimé en "UML profile for CORBA" Modèles de plate-forme (PDM?) p. ex. modèles de composants à différents niveaux d'abstraction : CCM, C#, EJB, EDOC,

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 70 - Write once, run everywhere Model once, Generate everywhere CORBA Java/EJB C#/DotNet Web/XML/SOAP PIM etc. Platform-Independent Model Multi-target code generation + SVG, GML, Delphi, ASP, MySQL, PHP, etc. data grid computing pervasive computing cluster computing SMIL/Flash

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 71 - Espaces concrets et abstraits UML/MOF XML/SOAP XMI/XSLT projection CORBA IDL Java/EJB JSR #40 Java User Community (Sun) C#/DotNet Abstract Modeling Space Concrete Execution Spaces

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 72 - Le besoin d'indépendance Objets et composants PIMs Platform Independent Models Les technos du passé Web services Les technos du présent Grid computing, Cluster computing, etc. Les technos du futur

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 73 - Au cœur du MDA: les PIMs et les PSMs Modèles MDA PIM: Platform Independent Model Spécification neutre d'un système (modèle de métier et de service) qui ignore tous les détails de mise en oeuvre Exemple: système de facturation exprimé en UML Modèles de plate-forme (PDM?) P.ex. modèles de composants à différents niveaux d'abstraction : CCM, C#, EJB, EDOC, … PSM: Platform Specific Model Modèle de métier et de service lié à un modèle de plate-forme Exemple: Système de facturation exprimé en "UML profile for CORBA"

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 77 - Revisiter le cycle en Y : tissage des PIMs & PDMs pour produire les PSMs. Utopie ou Réalité ? PIM (Platform Independent Model) PSM (Platform Specific Model) M Merging/binding phase PDM (Platform Description Model) ? tissage Code DDM (Design Decision Model) CIM

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 78 - Empowering the MDA MOF UTL UPM UML UML 2.0SPEM MOF 2.0 QVT RFP UML : description des artefacts logiciels à objets UPM : comment les utiliser et les produire UTL : comment générer des modèles à partir d'autres modèles MDA model UPM UTL UML Meta-model

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 79 - Conditions nécessaires pour le succès du MDA 1. Langage précis (MOF, UML, OCL) 2. Convergence sur un UTL (Unified Transformation Language) MOF 2.0 QVT RFP 3. Stabilisation industrielle du standard de sérialisation de modèles XMI 4. Définitions précises pour les PIMs, CIMs, PDMs and PSMs 0% 100% 2005 Manual/Automatic code generation

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 81 - Transformation de PIM à PSM (projections) UML Model (PIM) Red 4 2 XMI Document (PSM) XMI <!Element Auto (Color*, Door*, Engine*)> XMI DTD, Schema (PSM) XMIXMI MOFMOF interface Auto { }; IDL, Java… (PSM) Class Auto {public String color; public int Door; public int Engine; } JMI

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 86 - Réponse globale: J3 The Machine (resources) The World (domain) Jackson + Jacobson + Johnson = J3 The requirement model (usage model) Patterns and composition objects. Jacobson Johnson & Co The horizontal axis The design model The verttical axis Jackson e.g. Use cases

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 88 - L'approche classique en MDA AnalyseConception Programmation UML UMLforCORBA CORBA sem Profil au sens UML, çàd l'expression d'un dialecte? sem MOF Modèle Méta-Modèle Méta-Méta-Modèle

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 90 - Les raisons d'une transition rapide La technologie des objets a montré la possibilité de description homogène du contexte (organisation, entreprise) et de la plate- forme d'exécution (CORBA, Java) Chacune peut être prise en compte par un méta- modèle séparé (EDOC, CCM, EJB) À partir de ce moment, il est tout à fait raisonnable d'envisager d'appuyer le système à construire sur un méta-modèle MM2, déduit des méta-modèles d'entreprise (MM1) et de plate-forme (MM3). Entreprise Système à construire Plate-forme MM1MM2 MM3 sem

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 91 - Models Everywhere Business model Business processes Business rules Workflow model Test model User model Cost model Development process model Design model Class model Object model Dynamic model UseCase model Interaction model Resource model Agent model etc. Performance model Business objects

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 92 - Le cycle de développement du logiciel est peuplé de modèles. Les modèles sont d'importance inégales L'espace des modèles est structuré. Les modèles sont liés les uns aux autre dans un réseau organisationnel complexe Le contenu de chaque modèle est défini (contraint) par un méta- modèle (une ontologie). L'espace des modèles est en expansion constante, à partir des modèles de base (Domaine, Service, Ressources) Les modèles peuvent se spécialiser (simple ou multiple) Les bibliothèques de modèles et de méta-modèles sont accessibles via des navigateurs. Requirement model Requirement model Business Object model Business Object model Workflow model Workflow model Business rules model Business rules model Business process model Business process model Design model Design model Deployment model Deployment model Test model Test model Performance model Performance model QoS model QoS model Execution model Execution model etc. 1 aspect = 1 modèle

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 93 - L'espace global des modèles Le cycle de développement du logiciel est peuplé de modèles. Les modèles sont d'importance inégales L'espace des modèles est structuré. Les modèles sont liés les uns aux autre dans un réseau organisationnel complexe Le contenu de chaque modèle est défini (contraint) par un méta-modèle (une ontologie). L'espace des modèles est en expansion constante, à partir des modèles de base (Domaine, Service, Ressources) Les modèles peuvent se spécialiser (simple ou multiple) Les bibliothèques de modèles et de méta-modèles sont accessibles via des navigateurs.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 94 - Conclusions Modern model engineering techniques are ready for prime time in software engineering. They are based on: A four level architecture (3+1) A unique meta-meta-model (MOF), with transfer and exchange mechanisms with transformation mechanisms with operationalization mechanisms (e.g. round-trip engineering) A grawing collection of specialized meta-models (évolutive) Object meta-models (Java, CLR, etc.) Legacy meta-models (Relational, CWM) Enterprize meta-models : business objects, process & rules Product an process meta-models (e.g. workflow, RUP) An extension mechanism (profile). Efficient representation engines. Middleware integration schemes (DotNet, CORBA, Java).

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 95 - Les technos se suivent et se complètent Chaque technologie a un apport historique qui persiste. Les principes de la programmation structurée, issus de la technologie procédurale (TdP :Dijkstra, Hoare, Wirth, etc.), n'ont pas été perdus ni oubliés lors du passage à la technologie des objets dans les années 1980. Les contributions des différentes technologies (procédures, objets, composants, services, modèles, etc.) ne sont jamais perdues mais laissent des traces positives même longtemps après leur période d'impact maximum. Il ne faut pas jeter le bébé avec l'eau du bain : la contribution de la technologie des objets entre 1980 et 2000 aura été essentielle à l'évolution de l'informatique.

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 96 - Évolution des techniques de génie logiciel Procedural refinement (1950-1980) Top-down programming Architecture based on procedural refinement are very sensible to modifications (Jackson, Meyer) Object composition (1980-2000) The complexity of object architectures lies not inside the indivual objects, but in the complex relations between them Patterns, Components, etc. Model transformation (2000-?) Any artifact belongs to a specific model Models are first class entities in the software development Models are derived from other models by transformation operations

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 97 - De l'OMA vers le MDA Technologie procédurale Technologie des composants Technologie des objets Objets, Classes, Smalltalk, C++,... Procédures, Pascal, C,... Paquetages, Frameworks, Patrons, … 19801995 2000 Raffinement procédural Technologie Des modèles Modèles, Méta-Modèles, UML, MOF, XML, XMI, XSLT, … Composition d'objets Transformation de modèles

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 1 - Ingénierie des Modèles Logiciels Cours #3 De OMA vers MDA, Des objets vers les modèles Jean.

Présentations similaires

Présentation au sujet: "Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 1 - Ingénierie des Modèles Logiciels Cours #3 De OMA vers MDA, Des objets vers les modèles Jean."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 1 - Ingénierie des Modèles Logiciels Cours #3 De OMA vers MDA, Des objets vers les modèles Jean.

Présentations similaires

Présentation au sujet: "Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 1 - Ingénierie des Modèles Logiciels Cours #3 De OMA vers MDA, Des objets vers les modèles Jean."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back