Your SlideShare is downloading. ×
  • Like
  • Save
10 Things You Should Know About MDD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

10 Things You Should Know About MDD

  • 3,639 views
Published

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

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

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • See http://www.theenterprisearchitect.eu/archive/2009/11/09/10-things-you-should-know-about-model-driven-development for some background explanation.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
3,639
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
3
Comments
1
Likes
7

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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