OPTIMALJ, CONCEPTION ET DÉVELOPPEMENT RAPIDE MDA-PATTERNS-UML EJB 2

Présentation au sujet: "OPTIMALJ, CONCEPTION ET DÉVELOPPEMENT RAPIDE MDA-PATTERNS-UML EJB 2"— Transcription de la présentation:

1 OPTIMALJ, CONCEPTION ET DÉVELOPPEMENT RAPIDE MDA-PATTERNS-UML EJB 2
OPTIMALJ, CONCEPTION ET DÉVELOPPEMENT RAPIDE MDA-PATTERNS-UML EJB 2.0-STRUTS Eric Risser-Maroix

2 Agenda Compuware L’approche Compuware OptimalJ Qui sommes nous?
Notre offre L’approche Compuware Architecture J2EE Model Driven Architecture OptimalJ Les concepts d’OptimalJ Normes de Développement et de Conception

3 3 laboratoires de développement
Acteur Global COMPUWARE Employés 1,7 milliard de dollars Services 9,500 personnes Logiciels 8 gammes de produits 130 produits 3 laboratoires de développement Présence globale 47 Pays 110 bureaux

4 Cycle de vie de l’application …
APPLICATIONS OPERATIONS Development & Integration Automated Software Quality Production Readiness Performance & Availability Management DESKTOP NETWORK SERVER TRANSACTION PROFILING PERFORMANCE TESTING WAN PROVISIONING ACCELERATING DEVELOPMENT & INTEGRATION FUNCTIONAL & REGRESSION DEBUGGING & TUNING PROJECT, DATA AND WORKFLOW MANAGEMENT Optimal QACenter DevPartner DevPartnerDB Enterprise Editions Application Expert Predictor VISUALIZATION & REPORTING BASELINE DATA END-USER MONITORING & DIAGNOSTICS SERVER, APPLICATION & DATABASE MONITORING PERFORMANCE TROUBLESHOOTING APPLICATION MONITORING Application Vantage & STROBE ClientVantage NetworkVantage ServerVantage VantageView

5 L’approche Compuware

6 L’approche Compuware:
L’architecture J2EE

7 L’architecture J2EE J2EE est la plate-forme middleware technologiquement riche, mise à profit par 50% des futures applications d’entreprise java. (Gartner) Servlet WAP EJB J2EE CSS JDBC UDDI JSP XSLT HTML WSDL XML Struts CORBA Java Comment Faire ?

8 L’approche Compuware:
Model Driven Architecture

9 Object Management Group : Support de l’industrie
OMG : 800 membres / 40 organisations Borland Son but: Résoudre les problèmes d’intégration de systèmes Augmenter la productivité Comment : Produire des spécifications, des standards. Exemples : CORBA UML MDA Codagen Technologies Compuware IBM InteractiveObjects SUN OMG has about 800 member companies, OMG continues to be the largest software standards organization of its kind. There are over 40 organizations that are committed and support the MDA. OMG’s focus has always been, and still is, to help users solve integration problems, in a productive way, by supplying open, vendor-neutral interoperability specifications, which is being achieved by the widely adopted CORBA standard . On the slide I have taken an extract of some of the companies that are fully committed to making MDA a success. So based on this I believe that in the next 2 to 3 years we will see the MDA will reach a maturity level status. Currently today, you see that MDA is been spoken about more and more and that vendors are announcing their support for MDA but there is a big difference between supporting it and actually implementing the MDA in its entirety. MDA will only deliver on its productivity promise when the transformations between the PIM and PSM and between the PSM and Code are automated. Currently one of the tools that is truly doing this is OptimalJ. Ruud will explain how our competitors are currently do this, or should I say not. It’s not only the support from vendors but as you can see on the slide there are a number of key analysts endorsing the MDA as the only way to move forward. Here we see Aberdeen’s take on MDA but analysts such as Meta, Gartner Group and Giga, to mention a few, have been quoted in saying that model driven and pattern based development is the way to go. For example Richard Buchanen VP, Meta Group was quoted in saying “If it’s easier to manage change using MDA then that’s the way to go” Together

10 La vision MDA Une nouvelle manière de spécifier et de construire des systèmes Basée sur la modélisation UML Modéliser au lieu de programmer Finance E-Commerce Santé Plus …... Transport Espace Fabrication Télécommunication MDA’s vision is define a new way of specifying and building systems which is based on modeling with the UML. The MDA captures the use of UML for more than just pretty pictures. For example in the past and even still today. You have designers modeling a system system. All these pretty pictures that are collected and bound into a document and sent over to the developers. What do you think the developers do with them? Most of time its put to one side and forgotten and developers carry an as normal. Or else its used at inception but over time the application is miantained but the model is never kept in never kept in sync. MDA’s vision is merge these two worlds and I’ll explain later how this will take place. MDA is not the next big thing. Let me explain. The problem is that every year we see a new infrastructure being introduced. If we look in the last 10 years. C C++, Java, J2EE, Web Services, .NET and who knows what’s coming out next year. But the nice thing about MDA is that it transcends the implementation infrastructure. Its simply a way of using UML to develop application architectures that be hosted on many different implementation infrastructures in the next years which will last 20 years. So in the meantime people aren’t worried about what the architecture of the application is and how I can ensure the architecture of my application outlasts the infrastructure that implements because that what weve got to do.

11 Les spécifications en MDA
PIM Le Modèle Indépendant de la Plate-forme (PIM) représente les fonctionnalité du business et sa conduite sans rentrer dans les détails techniques. PSM Applique une correspondance standard pour créer ou générer un Modèle Spécifique à la Plate forme (PSM). Ceci à partir du PIM. Code Model Créer ou générer le code pour le PSM Platform Independent Model Platform Specific Model Intégration Lets now look at how applications are developed using the MDA. Step 1. All MDA development projects start with the creation of a Platform Independent Model(PIM), which is expressed in UML. The PIM expresses only business functionality and behavior. Built by business and modeling experts working together, this model expresses business rules and functionality undistorted, as much as possible, by technology. The clarity of this modeling environment allows business experts to ascertain, much better than they could if working with a technological model or application, that the business functionality embodied in the PIM is complete and correct. Another benefit: Because of its technological independence, the PIM retains its full value over the years, requiring change only when business conditions mandate. Step 2. Once the first iteration of the PIM is complete, it is stored in a MOF based Repository and input to the mapping step which will produce a Platform-Specific Model (PSM). To produce your PSM, you will have to select a target platform or platforms for the modules of your application. Such as J2EE, .NET etc. Step 3. Once the PSM has been created/generated, the 3rd and final step is to generate the code/implementation model. This will create/generate all of the files the platform requires. When I talk about platforms, I’m referring to the application server(s) your application will run on and programming languages, such as Java, C++ or C# your application will be generated into. This will result in a first cut working application, which can be further enhanced through the MDA process or by hand-coding. Take note that the mapping standard between PIM, PSM and the Code Model has been defined by OMG but the implementation not. MDA compliant tool vendors have implemented portions of the MDA, but OptimalJ is one of the few tools that has implemented the MDA completely to automatically generate a complete application from a PIM to PSM and finally to the Code Model, which I will explain in my next slide. Code Model

12 OptimalJ

13 OptimalJ implémente MDA
Définition, Import Transformation Patterns Functional OptimalJ Platform Independent Model Code Model Platform Specific Model Driven Architecture 2/3 ;3/3;EJB1ou 2 (ré)Génération Technology Patterns Domain Model Domain Patterns Développement de vos Patterns Application Models Application Patterns Implementation Patterns Code Model Code Patterns Paramétrage d’implémentation : Local / Remote interface, CMR / BMR, State-full / State-Less, Transaction, TagLib, Struts, HTML / WML…

14 MDA Domain Model Platform Independent Model Platform Specific Model
Code Model Now lets take a look at how OptimalJ has implemented MDA in its architecture? In line with MDA, there is a clear distinction between the models and the implementation of application components in OptimalJ. The models in OptimalJ have various abstraction levels, which include: The OptimalJ Domain Model, which maps to the MDA Platform Independent Model (PIM). The Domain Model defines the business domains without any specific application detail. It is defined by modeling the business application’s functionality and behavior, domain-specific information based on the Meta Object Facility (MOF) and Common Warehouse Model (CWM) in UML. The Domain Model is transformed automatically into an OptimalJ Application Model, which maps to the MDA Platform Specific Model (PSM). The Application Model defines the application, based on a chosen technology, which in the case of OptimalJ is J2EE. It describes what is to be generated in order to implement the application, by providing a logical overview of the components contained within each tier that makes up the application. The transformation from the OptimalJ Domain model to the application model takes place automatically via our Technology patterns. Finally, the Application Model is transformed automatically into an OptimalJ Code Model, which maps to the MDA Code Model. The Code Model defines the generated application code. In the case of OptimalJ, once the Web tier, EJB and DBMS tiers have been defined in the application model, the code implementations of defined components can be generated i.e. the Java classes, SQL scripts and other technical items that are needed for the components in the models. The transformation from the OptimalJ Application model to the Code model takes place automatically via our Implementation patterns. Both the Technology and Implementation pattern form part of Technology patterns, which will discussed in further detail in the “Patterns used in software development” webinar presented by Ton Blankers. MDA

15 MDA Application Model Platform Independent Model Platform Specific
Technology Patterns Platform Specific Model Code Model Now lets take a look at how OptimalJ has implemented MDA in its architecture? In line with MDA, there is a clear distinction between the models and the implementation of application components in OptimalJ. The models in OptimalJ have various abstraction levels, which include: The OptimalJ Domain Model, which maps to the MDA Platform Independent Model (PIM). The Domain Model defines the business domains without any specific application detail. It is defined by modeling the business application’s functionality and behavior, domain-specific information based on the Meta Object Facility (MOF) and Common Warehouse Model (CWM) in UML. The Domain Model is transformed automatically into an OptimalJ Application Model, which maps to the MDA Platform Specific Model (PSM). The Application Model defines the application, based on a chosen technology, which in the case of OptimalJ is J2EE. It describes what is to be generated in order to implement the application, by providing a logical overview of the components contained within each tier that makes up the application. The transformation from the OptimalJ Domain model to the application model takes place automatically via our Technology patterns. Finally, the Application Model is transformed automatically into an OptimalJ Code Model, which maps to the MDA Code Model. The Code Model defines the generated application code. In the case of OptimalJ, once the Web tier, EJB and DBMS tiers have been defined in the application model, the code implementations of defined components can be generated i.e. the Java classes, SQL scripts and other technical items that are needed for the components in the models. The transformation from the OptimalJ Application model to the Code model takes place automatically via our Implementation patterns. Both the Technology and Implementation pattern form part of Technology patterns, which will discussed in further detail in the “Patterns used in software development” webinar presented by Ton Blankers. MDA

16 MDA Code Model Generate Platform Independent Model Platform Specific
Implementation Patterns Code Model Now lets take a look at how OptimalJ has implemented MDA in its architecture? In line with MDA, there is a clear distinction between the models and the implementation of application components in OptimalJ. The models in OptimalJ have various abstraction levels, which include: The OptimalJ Domain Model, which maps to the MDA Platform Independent Model (PIM). The Domain Model defines the business domains without any specific application detail. It is defined by modeling the business application’s functionality and behavior, domain-specific information based on the Meta Object Facility (MOF) and Common Warehouse Model (CWM) in UML. The Domain Model is transformed automatically into an OptimalJ Application Model, which maps to the MDA Platform Specific Model (PSM). The Application Model defines the application, based on a chosen technology, which in the case of OptimalJ is J2EE. It describes what is to be generated in order to implement the application, by providing a logical overview of the components contained within each tier that makes up the application. The transformation from the OptimalJ Domain model to the application model takes place automatically via our Technology patterns. Finally, the Application Model is transformed automatically into an OptimalJ Code Model, which maps to the MDA Code Model. The Code Model defines the generated application code. In the case of OptimalJ, once the Web tier, EJB and DBMS tiers have been defined in the application model, the code implementations of defined components can be generated i.e. the Java classes, SQL scripts and other technical items that are needed for the components in the models. The transformation from the OptimalJ Application model to the Code model takes place automatically via our Implementation patterns. Both the Technology and Implementation pattern form part of Technology patterns, which will discussed in further detail in the “Patterns used in software development” webinar presented by Ton Blankers. MDA

17 IBM WebSphere, BEA WebLogic, Sun ONE, Oracle 9iAS, JBoss
Déploiement Test Production Tomcat JOnAS JBoss Solid IBM WebSphere, BEA WebLogic, Sun ONE, Oracle 9iAS, JBoss JSP EJB SQL .WAR .JAR .DAR .EAR Deployment Descriptors 1) Test 2) Production

18 Génération (Patterns)
OptimalJ Modélisation UML Génération d’application Java en architecture J2EE Weblogic Déploiement Modélisation WebLogic Génération (Patterns) Génération d ’EJB … Génération de JSP… Génération de SQL… Génération d’EAR… Intégration

19 En Résumé …

20 IBM WebSphere, BEA WebLogic, Sun ONE, Oracle 9iAS, JBoss
Optimal J : la démarche Génération IHM Déploiement Génération Java (Codage) IDE Test Production Tomcat JOnAS JBoss Solid IBM WebSphere, BEA WebLogic, Sun ONE, Oracle 9iAS, JBoss JSP EJB SQL .WAR .JAR .DAR .EAR Deployment Descriptors NetBeans Jbuilder WSAD Découpage J2EE (PSM) Web Services Java Legacy CICS / IMS CORBA Modélisation (PIM)

21 Comment intégrer vos Normes de Développement et de Conception ?

22 Génération “Pattern-driven”
Accès au référentiel “Meta Object Facility” Transformation PIM PSM Implementation PSM  Code Model Platform Independent Model Code Specific MDA Langage de patterns Langage simple compilé en code Java PATTERN IMPORT FILE TEMPLATETYPE TEMPLATE GUARD FREE IF DO LET FOR JOINPOINT

23 Exemple de Transformation Pattern
Transformation PIM PSM

24 Génération “Pattern-driven”
Implementation PSM  Code Model

25 Pattern Join Points Génération du code xxxxxxxxxxxxxxx Join Point
yyyyy

26 Les avantages d’OptimalJ
Complex business process Models Réduction de la complexité du business Modélisation Développement Focus métier Business – IT gap Test Patterns Réduction de la complexité technologique Déploiement Complex technology platform (J2EE)

27 Les Acteurs de MDA

28 Generated Application
Les Rôles et Activités Architectes Recherche technologique Définition d’ architecture Définition des  ’best practices’ via les patterns Développer les standards & guides Transfert de connaissances Architecte Designer Developer Personnalisation de l’appli générée Intégration d’Application Test et debug Maintenance de l’application Déploiement Best Practices & Standards Modélisation du Business Exigence du Management Analyses et Design Définition des règles de gestion Génération de l’Application Pré test de l’application Développeurs Fonctionnels Generated Application

29 OptimalJ: Le code généré

30 OptimalJ : le code généré !
DevPartner For Java Vérification des normes de codage Monitoring du Garbage Collector Performance Analysis CPU Affichage Graphe d’appel Couverture de Code

31 Intégration dans OptimalJ

32 Conclusion

33 La technologie évolue surtout dans le monde J2EE
Application Framework JDK 1.3 JSP 1.0 Servlet 2.2 EJB 1.1 JDBC 2.0 JSP 2.0 Servlet 2.3 EJB 2.0 JCA 1.0 JSP 3.x Servlet 2.4 JDK1.4 Lets have a look at another challenge and that is to keep up with changes in technology. Although everything is standardized in the Java world that doesn’t mean you don’t have to cope with technology change. As standards evolve and new functionality will be added you have to make a decision which new version of technology you are going to implement and when. The costs of technology change are hidden in many cases because what you see in a lot of projects is that adding new functionality and upgrading to new versions of technology are done in one and the same project. <Ask your audience if they do the same and ask them if they have ever made separate calculations for technology upgrades and functionality upgrades for a project> Lets have a look at what typically happens in an application over time, when new versions of technology need to be implemented in subsequent versions of the application. Of course with version 1 of the application everything is still under control. In the application a fixed set of standards are implemented. Lets have a look at version 2.3 of the application. JNDI 1.2.1 JTS 1.0 JMS 1.1 JSF 1.0 Framework ??? Application ???

34 OptimalJ Solution complète, structurée et industrielle pour :
Développer rapidement Maintenir simplement Sans connaissance pointue de java des applications en architecture J2EE

35 Portail Développeur OptimalJ http://javacentral.compuware.com
OptimalJ Community Home News White papers Documentation FAQ Forums Support Center Java links More than 1000 users If we look at IBM, Sun, Borland, TogetherSoft they all have Developer community websites where developer can browse for information, whitepapers, examples etc, partake in forums etc. Compuware and OptimalJ is no different. We also have a website, which can be found on javacentral.compuware.com, which currently has over 1000 users. When talking to customers/prospects please communicate this. Its only way we can foster a OptimalJ Java community….

36 Démonstration

37 Démonstration Le sujet :
Créer une application web en architecture 3 tiers J2EE. Un contact d’une société de voyage propose des promotions pour des séjours dans des pays.

38 Relation inter package

39 Les Fournisseurs package Fournisseur
On rajoutera par la suite une classe Agence liée à Société

40 Les Promotions package Promotion OptimalJ has 4 cornerstones:
- Model-based - CBD - Pattern-based - Rule-based We see 3 groups of models: We have the domain model, that is aimed at the business level. It is where you model your business and completely technology independent The development and integration model are technology dependent (EJB), but are code independent. We could replace for example the current development model with a .Net model based on the DNA architecture. Finally we have the real source code. From the domain model, the development models are generated and from the the development models the code is generated. The 3 models are not 1-1, but have different abstraction levels. So to generate from one abstraction level to another, you need to add knowlegde and this is done in the form of patterns. It is not a one time generation, the links between all model element are saved, so we can change the models manually and regenerate to propagate all the changes to the related models, without losing the manual changes. We are also working on the integration model, consisting of connectors to the outside world (for example CICS) and transformations. we discriminated 7 layers of transformation (for example data transformation, API transformation, protocol transformation). Next step is to upgrade the domain model to a full flash business model, by adding the process and organizational model. Of course we have this functionality already in optimal flow, but we want to move to one unified architecture. At this moment we are adding this integration modules as add-ons to the OptimalJ product. the domain model is part of the Optimalj product that that will change in the future. We move to (at least) 3 products, once each of these products have enough critical mass to stand on its own. The integration part is being development by Loek Gherings group, The business Product will be developed by Ronald Verloo group and The optimalJ product will move to Herman Meeuwsen groups. The vision to reality group will focus on the architecture and foundation of these products. If you want to look at the optimalJ product in action, please visit one of the demo areas. Henk will show how to generate applications from the domain model. wim will show how the models are synchronized. Arjan will show the pattern for wireless devices and Eric van HInte will do the graphical editor demo's.

41 Les autres possibilités de modélisation

42 Le Modèle When the model is built, the business rules are added and the application is generated. Changes will be made to the application, both during development and after the first release of the production version of the application. This is where the active synchronization comes in. Active synchronization ensures that when a developer makes changes to the models, model and code are kept in sync automatically. Active synchronization is a smart process as it recognizes which pieces of the application are affected by the change and which not, only re-generating the modified components. This ensures that the impact on the application will be minimized. In addition, the active synchronization functionality distinguishes between generated code and code developed by a developer. The process will preserve the developer extensions.

43 People and software for business applications
sm

44 Conclusion : Compuware OptimalJ et MDA sont la garantie du succès de vos développements. Respect des Coûts Respect des Délais Respect de la Qualité DevPartner pour Java est l’assurance de la satisfaction de vos utilisateurs dès la mise en production.

45 Les bénéfices de MDA Intégrer les systèmes, les implémentations actuelles et futures Simplifier le changement d’infrastructures Pérenniser les applications Réduire les coûts pendant toute la durée de vie de l’application Augmenter le “ROI” « Les entreprises qui suivront la démarche de MDA, soit la séparation de l’architecture de la technologie et de la technologie de déploiement, feront un grand pas en avant et rendront leur infrastructure informatique plus souple, apte à s’adapter aux transformations de l’entreprise, et libre d’intégrer de nouvelles technologies. Cette souplesse est également la garantie pour les entreprises d’un excellent ROI en matière d’investissement informatique. » Michele Rosen, IDC The benefits of the MDA are significant-to business leaders and developers alike : It allows you to integrate what you’ve built, with what you’re building, with what you will build in the future. To quote OMG “…. MDA is always ready to deal with yesterday’s, today's and tomorrow’s ‘next big thing’” Its remains flexible in the face of constantly changing infrastructure. MDA provides a solid framework that frees system infrastructures to evolve in response to a never-ending parade of platforms, while preserving and leveraging existing technology investments. It enables system integration strategies that are better, faster and cheaper. It reduces costs throughout the application lifecycle, extending beyond design and coding stages through deployment and into maintenance and, ultimately, evolution of the application, which results in lengthening the usable lifetime of software and application systems Reduction in development time when building and implementing new applications, without sacrificing application quality but rather improving it. MDA increases the return on investment through the reuse of applications and domain models, which in turn can be adopted to ongoing business and technology changes. It allows a software environment to evolve and change while the business model (PIM) remains stable. This stable base is necessary to cope with the constantly changing environment of today’s market.

46 OptimalJ – La solution pour développer des applications Java/J2EE d’Entreprise
Réponse rapide aux évolutions métier Augmentation de la productivité des développements Garantit l’utilisation des “best practices”, des standards et “guidelines” Pérennité des applications toujours à la pointe des nouvelles technologies Reprise des investissements existants Maximise la qualité et la fiabilité des applications avec un minimum de risques Concluding we can say that OptimalJ provides an excellent solution to the 6 most important business issues related to developing enterprise class applications on the Java/J2EE platform.

47 OptimalJ: Quel IDE ?

48 Model Driven Architecture
Modélisation (PIM) Fonctionnel JSP , EJB, Data (PSM) Architecture J2EE NetBean Génération du code Développements WSAD JBuilder

49 Intégration NetBean

50 Intégration JBuilder

51 Intégration WSAD

52 DevPartner : Quel IDE ?

53 Exemple d’intégration WSAD

54 Exemple d’intégration Jbuilder 7