Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
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.
Próxima SlideShare
Cargando en…5
×

11 Dogmas of model driven development

6.979 visualizaciones

Publicado el

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.

Publicado en: Tecnología
no profile picture user

  • Sé el primero en comentar

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.

×