Title Page Headline Style Applied Here

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 ProductionApplying 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, POJOs, 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
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 ArchitectureSeparation Of Domain
and Platform Concern
9
Classic Modeling and Development
Domain X Technology
Applications
Classic Tools
Designers Developers
Users
10
MDA Goal
Applications
MDA Tools
Users
11
MDAs PIM, PSM and Refinement
Domain Model
refinement
12
Model Driven ArchitectureRaising 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 isnt 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
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
Incremental Refinement

• All models are changeable
• High Level Domain Model
• Maintainable Technology Solutions
• Customizable Application

Domain Model
refinement
18
3 Different Abstraction Levels
Domain Model
Business Modelling language
Technology patterns
Application Modelling Languages
Coding patterns
Coding languages
19
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 lets you quickly react to changing domains
  and technologies

22
(No Transcript)