Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
ElevenDogmas of Model-driven Development Rafael Chaves rafael@abstratt.com - Twitter: @abstratt http:...
I Enterprise Software is muchharder than it should be, lackof separation of concerns is to blame.
II Domain and architectural/implementation concerns are completelydifferent beasts and should be addressed s...
IIIWhat makes a language good for implementation makes itsuboptimal for modeling, and vice-versa.
IV Domain concerns can and should be fully addressed during modeling,implementation should be a trivial mapping.
VA model that fully addressesdomain concerns will expose gaps in requirements much earlier.
VIA model that fully addresses domain concerns allows thesolution to be validated much earlier.
VIINo modeling language is more understandable to end-usersthan a running application (or prototype).
VIII A single architecture canpotentially serve applications of completely unrelated domains.
IX A same application canpotentially be implementedaccording to many different architectures.
XImplementation decisions are based on known guidelines applied consistently throughout the application, and beg for...
XIThe target platform should notdictate the development tools, and vice-versa.
Prochain SlideShare
Chargement dans…5
×

11 Dogmas of model driven development

7 183 vues

Publié le

I prepared the following slides for a presentation on AlphaSimple but ended up not having time to cover them. The goal was to make the audience understand where we are coming from, and not try to convert them.


I truly believe in those principles, and feel frustrated when I realize how far the software industry is from abiding by them.

Publié dans : Technologie
no profile picture user

  • Identifiez-vous pour voir les commentaires

11 Dogmas of model driven development

  1. 1. ElevenDogmas of Model-driven Development Rafael Chaves rafael@abstratt.com - Twitter: @abstratt http://abstratt.com/blog/
  2. 2. I Enterprise Software is muchharder than it should be, lackof separation of concerns is to blame.
  3. 3. II Domain and architectural/implementation concerns are completelydifferent beasts and should be addressed separately and differently.
  4. 4. IIIWhat makes a language good for implementation makes itsuboptimal for modeling, and vice-versa.
  5. 5. IV Domain concerns can and should be fully addressed during modeling,implementation should be a trivial mapping.
  6. 6. VA model that fully addressesdomain concerns will expose gaps in requirements much earlier.
  7. 7. VIA model that fully addresses domain concerns allows thesolution to be validated much earlier.
  8. 8. VIINo modeling language is more understandable to end-usersthan a running application (or prototype).
  9. 9. VIII A single architecture canpotentially serve applications of completely unrelated domains.
  10. 10. IX A same application canpotentially be implementedaccording to many different architectures.
  11. 11. XImplementation decisions are based on known guidelines applied consistently throughout the application, and beg for automation.
  12. 12. XIThe target platform should notdictate the development tools, and vice-versa.

×