10 Things You Should Know About MDD

4,591 views
4,384 views

Published on

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

Published in: Technology, Business
1 Comment
7 Likes
Statistics
Notes
  • See http://www.theenterprisearchitect.eu/archive/2009/11/09/10-things-you-should-know-about-model-driven-development for some background explanation.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,591
On SlideShare
0
From Embeds
0
Number of Embeds
1,632
Actions
Shares
0
Downloads
3
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide

10 Things You Should Know About MDD

  1. 1. 10 things you should know about Model-Driven Development Johan den Haan Blog: http://www.theenterprisearchitect.eu Twitter: @JohanDenHaan @ModelDriven
  2. 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. 3. Model-Driven Development?
  4. 4. Automation
  5. 5. Abstraction
  6. 6. Productivity  Short term: more functionality  Long term: less sensitive for changes in – Personnel – Business requirements – Development platforms – Deployment platforms
  7. 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. 8. The law of leaky abstractions
  9. 9. Innovation distracts?
  10. 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. 11. YAGNI also holds for modeling
  12. 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. 13. Needs a standardized architecture
  14. 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. 15. MDD really enforces architecture
  16. 16. Asks for different tools
  17. 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. 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. 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. 20. Meta team: domain expert
  21. 21. Meta team: language engineer
  22. 22. Meta team: transformation specialist
  23. 23. Meta team: implementation / platform expert
  24. 24. Meta team: software factory architect
  25. 25. Project team: business engineer
  26. 26. Project team: application / solution architect
  27. 27. Project team: test engineer
  28. 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. 29. Can lead to Business-IT alignment
  30. 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. 31. Time = money?
  32. 32. Is not enough!!
  33. 33. Is not enough  Integrating model and code  More focus on changing applications  Runtime flexibility  Configuration vs. Model-Driven Development  Adaptive modeling
  34. 34. Leads to resistance
  35. 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. 36. 10 things you should know about Model-Driven Development Blog: http://www.theenterprisearchitect.eu Twitter: @JohanDenHaan @ModelDriven

×