1 / 22

Wim Bast Chief Architect OptimalJ October 18 th , 2006

Model Driven Architecture Efficiently react to Changing Architectural and Functional Requirements Stainless Steel Models for Red Rusting Technologies. Wim Bast Chief Architect OptimalJ October 18 th , 2006. Agenda. Software Production: Applying IT Patterns to Domain Requirements

cian
Download Presentation

Wim Bast Chief Architect OptimalJ October 18 th , 2006

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. Model Driven ArchitectureEfficiently react to Changing Architectural and Functional RequirementsStainless Steel Models for Red Rusting Technologies Wim Bast Chief Architect OptimalJ October 18th, 2006

  2. Agenda • Software Production: Applying IT Patterns to Domain Requirements • Model Driven Architecture: Separation of Domain and Platform Concern • Model Driven Architecture: Raising the Level of Abstraction • Conclusions

  3. Software Production:Applying IT Patterns toDomain Requirements

  4. Software = Domain * IT • When we develop software we apply IT patterns to Domain requirements • Many different technologies and IT patterns are used to build one application • Spring, Hibernate, JSP, Struts, EJB 2.0, EJB 3.0, SOA, POJO’s, data-access components, etc… • Each aspect of the domain is implemented using many technologies and many patterns

  5. What is a Pattern? • A pattern is a solution to a common problem • Capture best practices, good designs and experience • Transfer knowledge, share experience • A pattern is a matter of discovery and experience • Abstraction of a specific solution • Using, improving and extending patterns • This makes us IT experts

  6. SalesOrder Customer Stock Product Supplier Customer Stock Product Supplier SalesOrdr Stock SalesOrder Customer Product Supplier Business Delegate PatternAn Example • Problem • Remote communication between clients and business service components is too complex • Solution • Use a Business Delegate to encapsulate access to a business service * Core J2EE Patterns, Best Practices and Design Strategies Alur, Crupi, Malks; ISBN 0-13-142246-4

  7. Small window of opportunity • The number of different technologies used to develop an application is growing • The number of domain aspects to be automated is growing • The frequency of changes to both the Domain and the Technologies is growing • The window of opportunity to deliver a successful application is getting smaller

  8. Model Driven Architecture:Separation Of Domain and Platform Concern

  9. Platform Knowledge Domain Knowledge Classic Modeling and Development Domain X Technology Applications Classic Tools Designers & Developers Users

  10. Application Developers Platform Experts Technology Selection and Tuning Technology Solutions Domain Models Domain Experts MDA Goal Applications MDA Tools Users

  11. PIM Technology Patterns Technology Solution PSM Application Application MDA’s PIM, PSM and Refinement Domain Model refinement

  12. Model Driven Architecture:Raising the Level of Abstraction

  13. Coding Language Evolution • Abstraction level increased from 1GL to 4GL but fell back again to 3GL • A 4GL is productive but isn’t addressing standard technologies and lacks fine-grained control • A current 3GL is mainly a set of standard libraries and frameworks, the coding syntax is less important

  14. Abstraction Levels of Modeling • In practice UML models exist on different levels of abstraction • From analyze -via design- to implementation • Can model refinement be automated or is it a creative process?

  15. elaborational incremental refinement Abstraction Level PIM translational Percentage Automated Refinement The elaborational MDA versus translational MDA ‘battle’

  16. Productivity and Control • Black-box automated refinement and hiding the detailed specification increases productivity but decreases fine-grained control • Creative refinement and exposing the detailed specification increases fine-grained control but decreases productivity • Law of Preservation of Misery?

  17. Technology Patterns Technology Solutions Application Application Incremental Refinement Domain Model • All models are changeable • High Level Domain Model • Maintainable Technology Solutions • Customizable Application refinement

  18. Application models Applications 3 Different Abstraction Levels Domain Model Business Modelling language Technology patterns Application Modelling Languages Coding patterns Coding languages

  19. MOF UML Application models UML MOF Applications Applying OMG Modeling Standards Domain Model Business Modelling language QVT Technology rules Application Modelling Languages M2T Coding rules Coding languages

  20. Conclusions

  21. Conclusions • MDA separates Domain and Technology concerns • MDA Automates the Multiplication of the Domain and Technology aspects • MDA gives you Development Productivity without losing Control • MDA let’s you quickly react to changing domains and technologies

More Related