Begin

1
Begin
2
Model Driven DevelopmentWho Needs It?
Wim Bast Chief Architect, Compuware
Europe September 15, 2004
3
Agenda

• Multiplying Domain aspects with IT patterns
• The Essence of MDA
• Raising the Level of Abstraction
• MDD solutions that are not MDA solutions
• Conclusions

4
Multiplying Domain aspects with IT patterns
5
Software Domain IT

• When we develop software we apply IT patterns to
  Domain aspects
• Many different technologies and patterns are used
  to build one application
• Each aspect of the domain is implemented in many
  technologies and patterns in one application

6
Pattern Example Business Delegate Pattern

• Problem
• Remote communication between clients and business
  service components is too complex
• What do I want to do?
• Hide clients from the complexity of remote
  communication
• Avoid unnecessary invocation of remote services

7
Pattern Example Business Delegate Pattern

• How do I do it?
• 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
8
Small window of opportunity

• The number of different technologies used to
  develop an application is growing
• The number of automated aspects of the domains is
  growing
• Domain and IT aspects change more and more
  rapidly
• The (time) window of opportunity for a successful
  application is getting smaller

9
The Essence of MDA
10
MDA Qualities

• Portability
• Cross-platform Interoperability
• Platform Independence
• Domain Specificity
• Productivity

11
MDA Benefits

• Reduced cost
• Reduced development time
• Improved application quality
• Increased return on IT investments
• Rapid inclusion of emerging technologies

12
Classic Modeling and Development
Domain X Technology
Applications
Classic Tools
Designers Developers
Users
13
MDA Goal
Applications
MDA Tools
Users
14
MDA Essentials

• Separation between, and reusability of, domain
  and platform expertise
• Reuse and leveraging existing IT technologies
• Quick adaptability of domain and technology
  changes
• Generation of working, high-quality applications
  and integrations

15
Raising the Level of Abstraction
16

• The entire history of software engineering is
  that of the rise in levels of abstraction.

Grady Booch The Limits of Software September
2002
17
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

18
Modeling on Different Abstraction Levels

• 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?

19
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?

20
Controllable Incremental Refinement

• Hiding complexity in Abstract Specification
• Maintainable Refinement Definition
• Tuneable Detailed Specification

Abstract Specification
refinement
Detailed Specification
21
MDA Goal
Application Developers
Platform Experts
Technology Selection and Tuning
Technology Solutions
Applications
MDA Tools
Domain Models
Users
Domain Experts
22
MDAs PIM, PSM and Iterative Refinement
Domain Model
refinement
23
Different Abstraction Levels and Multiple PSMs
Domain Model
Business Modelling Language
Technology Patterns
Application Modelling Languages
Coding Patterns
Coding Languages
24
MDA Raising the Level of Abstraction

• Increased productivity and decreased complexity
  through automatic generation
• Quality improvements because intelligent patterns
  are enforced
• Separation between and reuse of domain and
  technology expertise
• No lose of fine-grained control

25
MDD solutions that are NOT MDA solutions
26
One-to-One Model to Code Transformations

• Models are not necessarily on a higher level of
  abstraction than code

Model
transformation
Code
27
Model and Code with Equal Complexity

• Model and code with equal complexity

28
Examples That Do Not Raise the Level of
Abstraction

• Diagrammatical presentation of the code structure
  (for example UML class diagram of Java classes)
• Detailed method body specifications in a modeling
  language (for example Java method bodies
  generated from UML action specs)
• Reverse engineering of legacy code (for example,
  import the class structure of a C application
  into an UML tool)
• One-to-one UML profiles for technologies (for
  example, the UML profile for EJB)

29
Full Computational Platform Independent Language
UML to C mapping rules
UML ASL
C
expressed in
expressed in
defined by
C Library
Applic C
Model A
uses
30
Full Computational Platform Independent Language
UML to Java mapping rules
UML ASL
Java
expressed in
expressed in
defined by
Java Library
Applic J
Model A
uses
31
Full Computational Platform Independent Language
UML to Java mapping rules
UML ASL
Java
expressed in
expressed in
defined by
Java Library
Applic J
Model B
uses
32
Models On the Code Level of Abstraction is Not MDA

• A model expressed in a platform-independent
  language is not necessarily a platform-independent
  model
• A model on the code level of abstraction is
  either incomplete or platform dependent
• No productivity improvement because of equal
  complexity
• No quality improvement because only simple
  patterns are derived

33
Conclusions
34
Conclusions

• Not all MDD solutions are MDA solutions
• MDA separates Domain and Technology concerns
• MDA Automates the Multiplication of the Domain
  and Technology aspects
• MDA gives you Development Productivity without
  losing Control

35
End