10 points you should know when you start with Model Driven Development.

1. 10 things you should know about
Model-Driven Development
Johan den Haan
Blog:
http://www.theenterprisearchitect.eu
Twitter:
@JohanDenHaan
@ModelDriven

2. Model-Driven Development
 Differs from model-based development
 Is still a software development approach
 Asks for agile development
 Needs a standardized architecture
 Asks for different tools
 Leads to a change in roles
 Can lead to business-IT alignment
 Needs another business model
 Is not enough
 Leads to resistance

3. Model-Driven
Development?

4. Automation

5. Abstraction

6. Productivity
 Short term: more functionality
 Long term: less sensitive for changes in
– Personnel
– Business requirements
– Development platforms
– Deployment platforms

7. It’s still software development
 Experience with approach and tool?
 Is the tool finished on time to start project?
 Abstraction vs. Rigidity: know your
limitations
 Version control

8. The law of leaky
abstractions

9. Innovation
distracts?

10. Asks for agile development
 Iterative modeling
– Iteration planning
– Model storming
– Test-driven executable model specification
 Knowledge crunching
 Stakeholders actively participate
 Requirements evolve troughout project

11. YAGNI also holds
for modeling

12. Asks for agile development
 DDD based DSL development
– Capture domain knowledge in a metamodel
– Communicate using an ubiquitous language
– Let the metamodel drive the implementation
– Isolate the domain
– Refactor continously
– Maintain metamodel integrity
– Use a people-oriented approach

13. Needs a standardized architecture

14. Needs a standardized architecture
 Functional principles
– Guide function design
– Are reflected in the DSLs
– Condition the model validations
 Constructional principles
– Guide construction design
– Are reflected in the generator
– Condition the domain framework implementation

15. MDD really enforces
architecture

16. Asks for different tools

17. DSL tool
 Workbenches:  Tool user activities:
– DSL workbench – DSL definitions
– Transformation workbench – Transformation rules
 Input: – Architecture definition
– DSL definitions – (Domain) framework
– Transformation rules implementation
 Output:  Examples:
– Solution workbench – openArchitectureWare
– Generator – MetaEdit+
– Microsoft DSL Tools
 Tool vendor activities:
– JetBrains MPS
– Meta language definition
– Transformation language
definition
– Workbench
implementations

18. Model-Driven Software Factory
 Workbenches:  Tool user activities:
– Solution workbench – Application modeling
 Input:  Examples:
– Functional specification – Mendix
 Output: – Mod4j
– Working application
 Tool vendor activities:
– DSL definitions
– Transformation rules
– Architecture definition
– Domain framework
implementation
– Solution workbench
implementation

19. Leads to a change in roles
 Meta team
– Building the Model-Driven Software Factory
– Using DSL tools
 Project team
– Building end-user applciations
– Using a Model-Driven Software Factory

20. Meta team:
domain expert

21. Meta team:
language engineer

22. Meta team:
transformation specialist

23. Meta team:
implementation / platform expert

24. Meta team:
software factory architect

25. Project team:
business engineer

26. Project team:
application / solution architect

27. Project team:
test engineer

28. Can lead to Business-IT alignment
 Specify software with domain-specific
concepts
 Domain experts really involved in
development process
 MDD makes software development more
agile
 Explicit connection between organization
models and models of the IT system?

29. Can lead to Business-IT alignment

30. Needs another business model
 Benefits
– Faster time-to-market
– Increased quality
– Involving domain experts leads to fit-for-purpose
– Follow fast changes in business requirements and
technology
 Costs
– Learn MDD
– Develop MDD tool
– Maintain MDD tool

31. Time = money?

32. Is not enough!!

33. Is not enough
 Integrating model and code
 More focus on changing applications
 Runtime flexibility
 Configuration vs. Model-Driven Development
 Adaptive modeling

34. Leads to resistance

35. Model-Driven Development
 Differs from model-based development
 Is still a software development approach
 Asks for agile development
 Needs a standardized architecture
 Asks for different tools
 Leads to a change in roles
 Can lead to business-IT alignment
 Needs another business model
 Is not enough
 Leads to resistance

36. 10 things you should know about
Model-Driven Development
Blog:
http://www.theenterprisearchitect.eu
Twitter:
@JohanDenHaan
@ModelDriven