Model-Driven Development, the end of the test profession?

4,240 views

Published on

I used this presentation in my keynote talk at the Dutch Testnet 2010 event. For an audience of 500+ professional software testers I explained the basic concepts of Model-Driven Development and gave some food-for-thought about the impact of MDD on the test profession.

Published in: Technology
1 Comment
1 Like
Statistics
Notes
  • See http://www.theenterprisearchitect.eu/archive/2010/11/03/model-driven-development-the-end-of-the-test-profession for a description of the talk.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,240
On SlideShare
0
From Embeds
0
Number of Embeds
1,302
Actions
Shares
0
Downloads
0
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Model-Driven Development, the end of the test profession?

  1. 1. Model-Driven Development, the end of the test profession? Johan den Haan Head R&D Mendix @JohanDenHaan
  2. 2. I’m not a test expert
  3. 3. Meet Marvin!
  4. 4. How Marvin discovered MDD 1. Good programmers are lazy 2. Creating a product line 3. Empowering business engineers 4. Changing the test profession
  5. 5. 1. Good programmers are lazy
  6. 6. Marvin needs to add a field to the Order entity… User Interface Application Layer Domain Layer ORM Database
  7. 7. Marvin wants 1 place to change instead of 5 User Interface Application Layer Domain Layer ORM Database
  8. 8. DRY Don’t repeat yourself
  9. 9. Good programmers are lazy  Don’t repeat yourself  Generate different parts from one program definition  One business change means one change in program definition  Program definition can be seen as a model  First step into direction of MDD
  10. 10. 2. Creating a product line
  11. 11. Marvin needs to serve a lot of customers… Customer 1 Customer 2 Customer 3
  12. 12. Software Product Line: assemble assets
  13. 13. Platform Assets Assemble Application
  14. 14. Proactive vs. Reactive Software Product Line design
  15. 15. Creating a product line  What should be part of the model?  Define a domain and specify the static and variable part  Model can be at higher abstraction level  Second step into direction of MDD
  16. 16. Summary 1. Don’t repeat yourself: one business change is one change in your program specification 2. Define a domain: separation between static (platform) and variability (model) leads to a high-level model
  17. 17. 3. Empowering business engineers
  18. 18. Marvin wants to focus on technology…
  19. 19. … so he empowers business engineers
  20. 20. Language Transf. rules Specified in Defined by Model Generator Code Uses Domain Framework
  21. 21. Domain-Specific Language
  22. 22. Code Generation vs. Model Interpretation + = + =
  23. 23. Abstraction and Automation empower business engineers
  24. 24. Empowering business engineers  High-level modeling language (abstraction)  Tool support (automation)  Empowers business engineers  Focus on business problem instead of technology  Third step into direction of MDD
  25. 25. Summary 1. Don’t repeat yourself: one business change is one change in your program specification 2. Define a domain: separation between static (platform) and variability (model) leads to a high-level model 3. Use DSLs: easily specify a high-level model which is automatically converted into a working application
  26. 26. 4. Changing the test profession
  27. 27. Marvin…!! What’s in it for me?
  28. 28. … no billable hours for Marvin
  29. 29. Marvin explains…  Higher productivity  More agile  Business-IT alignment – Communication using models – Empowering domain experts – Short feedback cycles  Improved quality – Separation of concerns – Engine contains knowledge – Less technical errors
  30. 30. Is MDD less error-prone?
  31. 31. User Acceptance requirements test System System test requirements Integration Design test Detailed Component design test Code Unit tests
  32. 32. User Acceptance requirements test System System test requirements Integration Design test Detailed Component design test No code Code Unit tests
  33. 33. User Acceptance requirements test System System test requirements Integration Design test No detailed design Detailed Component design test Code Unit tests
  34. 34. User Acceptance requirements test System System test requirements Integration Design test No technical design Detailed Component design test Code Unit tests
  35. 35. Focus on requirements, Focus on validation, functional design reviews, business fit User Acceptance requirements test System System test requirements Integration Design test Detailed Component design test Code Unit tests
  36. 36. Are we approaching the end of the test profession?
  37. 37. Why MDD doesn’t mean the end of the test profession  Validation and verification still needed  Testing of complex systems in complex environments  Testing and verification of MDD tools!  Is creating software by only defining the functional design ever feasible?
  38. 38. How Marvin discovered MDD 1. Good programmers are lazy 2. Creating a product line 3. Empowering business engineers 4. Changing the test profession
  39. 39. Model-Driven Development will change the test profession! Read more (blog): www.theenterprisearchitect.eu Connect (twitter): @JohanDenHaan

×