1 / 32

Evaluating Compuware OptimalJ as an MDA tool

Evaluating Compuware OptimalJ as an MDA tool. Shimin Li. Project Overview. Introduction Mode-Driven Architecture Overview Framework for Evaluating MDA Tools Evaluating Compuware OptimalJ Conclusion. Introduction. Motivation Objectives Approach Organization.

franklinf
Télécharger la présentation

Evaluating Compuware OptimalJ as an MDA tool

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Evaluating Compuware OptimalJ as an MDA tool Shimin Li

  2. Project Overview • Introduction • Mode-Driven Architecture Overview • Framework for Evaluating MDA Tools • Evaluating Compuware OptimalJ • Conclusion

  3. Introduction • Motivation • Objectives • Approach • Organization

  4. Model-Driven Architecture Overview • Viewpoints and Models • Computation Independent Viewpoint and CIM • Platform Independent Viewpoint and PIM • Platform Specific Viewpoint and PSM

  5. Model-Driven Architecture overview • Model transformations • Meta-model • Mapping • Model Marking • Approaches • Marking Model • Meta-model transformation • Model transformation • Pattern application • Model Merging

  6. Model-Driven Architecture overview • Proposed standards • Meta-Object Facility (MOF) • Unified Modeling Language (UML) • XML Metadata Interchange (XMI) • Common Warehouse Metamodel (CWM)

  7. Model-Driven Architecture overview • Benefits • Improved portability • By separating the specification of the operation of a system from the details of the way that the system uses the capabilities of its platform • Increased productivity • By automating mappings • Improved quality • By reuse of well designed patterns and templates in mappings • Improved maintainability and documentation • By separation of concerns, traceability and consistency between models and code

  8. Framework for Evaluating MDA Tools • MDA Feature Analysis • By a case study • Comparison with a Standard Engineering Tool • By a case study

  9. Model-Driven Architecture Features

  10. Case Study • Goal • Exercise important MDA-related activities using Compuware OptimalJ • Compare OptimalJ with Standard Engineering Tool

  11. Standard Engineering Tool • Eclipse + Lomboz J2EE plug-in

  12. Case Study • Software Practice Lab (SPL) • A number of members (students) • A number of supervisors • A number of sponsors • A list of projects, and each of them is associated with a specific sponsor • Each member, supervisor, and sponsor can access the information of SPL through a web browser by login SPL with their username and password.

  13. Case Study Software Practice Lab (SPL)

  14. Case Study

  15. Case Study

  16. Case Study

  17. Implementation - Eclipse & Lomboz J2EE plug-in Software Practice Lab J2EE Components

  18. Implementation - Eclipse & Lomboz J2EE plug-in • Design pattern: Session Façade • Member, supervisor, project, and sponsor are accessible via SPLAccess • Code written • A session EJB and its DAO (SPLAccess) • Two BMP EJBs and their DAOs (Member and Supervisor) • Two CMP EJBs (Project and Sponsor) • A Servlet • Database Schema (for five relations) • Code generated (by XDoclet) • EJB Home, Remote, DAO interfaces • Deployment descriptions

  19. Feature Analysis - Eclipse & Lomboz J2EE plug-in

  20. SPL Implementation– OptimalJ 3.1 PE • Construct the Domain Model (PIM) • High level of abstraction of the system • Class Model • Static structure of the application data • Each class must has a primary key (for creating database model) • Service Model • Operations on data (e.g. login user, show all projects in SPL)

  21. SPL Domain model explorer

  22. SPL Domain model

  23. SPL Implementation– OptimalJ 3.1 PE • Generate the Application Model (PSM) • High level of abstraction of the Platform • Use patterns to translate PIM to PSM • PSM depends upon technology used (Currently J2EE) • SPL application model consists of • Database model – SQL Schema (Solid) • EJB model – Session, entity, and message-driven beans • Web model – Web page templates from Macromedia Dreamweaver

  24. SPL Application model – Database model

  25. SPL Application model – EJB model

  26. Transformation Rules -- Classes • For each class in the PIM, there is a class of the same name in the PSM • For each public attribute of the class, the following are in the PSM • A private attribute with the same name and type • A public operation for get • A public operation for set

  27. Transformation Rules -- Associations • For each association in the PIM, the following are in the PSM • A private attribute in each class with the same name as the opposite class • Get and set operations for the attribute • If multiplicity is 0 or 1, the type is that of the opposite class • If multiplicity is many, the type is a Set (e.g. Collection in Java)

  28. SPL Implementation– OptimalJ 3.1 PE • Generate the Code Model • Java code, JSP, and XML files • Certain design patterns used (e.g. Session Façade) • Make the generated code easier to understand and modify • Divides generated files into free and guarded blocks • Free blocks • Free to change • Changes are preserved when code is updated from application model • Guarded blocks • Forbid changing • But may change by selecting the option to ignore the guarded blocks or from outside OptimalJ. The changes are not preserved.

  29. Feature Analysis - OptimalJ 3.1 PE

  30. Comparison

  31. Conclusion • Compuware OptimlJ 3.1 PE supports MDA well • Shield the engineer from implementation details • Provides a good development life-cycle • Make modification to models • The modification can be reflected almost immediately in the deployed system • Perform significantly better than the traditional engineering tool

  32. Conclusion • Suggestions for improvements • Provide the ability to model behavior of the system • Provide the simulation of models at domain level and application level

More Related