Why aren’t we all doing model driven development yet?
Páginas: 11 (2659 palabras)
Publicado: 14 de marzo de 2012
27/04/2011
Why aren’t we all doing Model Driven D…
« Code Generation 2011 | Home |
Why aren’t we all doing Model Driven Development yet?
16 April 2011 Johan den Haan About a month ago Kees Dijk asked a question on the programmers StackExchange titled "Why aren't we all doing model driven development yet?". He reiterates his question also as "What do you see as the biggest problems thatmake you not even consider model driven development?". It shouldn't be a surprise that I'm interested in these kind of questions. The answers, in this and other discussions about this subject, are interesting food for thought. Why? Because if you only read these 15 reasons why you should start doing MDD you would become curious why we aren't doing it all by now... Let's look at some of the mainconcerns which prevent people to use MDD, as mentioned in this StackExchange thread.
No Silver Bullet
The most upvoted answer on the programmers StackExchange refers to the essay of Fred Brooks "No Silver Bullet Essence and Accident in Software Engineering". Written in 1986 and still a valuable read! Brooks follows Aristotle in dividing difficulties in essential and accidental ones. Essentialtasks in software engineering are about the fashioning of the complex conceptual structures that compose the abstract software entity. Sounds abstract, but it means that constructing data sets, relationships among data items, algorithms, and invocations of functions is complex, inherent from their representation. Accidental tasks in software engineering are about the representation of these abstractelements in programming languages and the mapping of these onto machine languages within space and speed constraints. High-level languages are solving some of the accidental difficulties and are therefore valuable, but the essence of the problem remains the same. The specification, design, and testing of conceptual constructs need to be done by people, no tool will help you with that.
Dangersof MDD
Some followers of this blog may think I'm such a hardcore fan of MDD that I will now start defending MDD against Brooks. However, let's first try to get a balanced view on MDD. Please take notice of my previous articles 8 reasons why MDD is dangerous and 8 reasons why Model-Driven approaches (will) fail.
theenterprisearchitect.eu/…/why-arenat… 1/7
27/04/2011
Why aren’t we all doingModel Driven D…
In the first article I point at the following dangers: MDD actually introduces a lot of rigidity. Models are only flexible where flexibility has been designed. The roles of project members are quite different. The modeling environment doesn't always support version control. The modeling tool / approach is "almost" finished at project start. The requirements team needs tounderstand what is allowed and what not. MDD is sold to the customer, but the team has no experience. Innovation distracts. In the second article I mention the following eight reasons for possible MDE / MDD failure: Not targeting all goals of Model-Driven Engineering. Only using one modeling dimension: the dichotomy between PIM and PSM. Focusing on generating new artifacts. Using general purposelanguages. Using custom defined domain specific languages. Using model transformations which are not fully executable. Not testing the model. Insufficient tooling. I'm mentioning these items for two reasons. First, not every approach called MDD is the same. Hence, your experience with MDD cannot be extrapolated to MDD in general. Second, MDD is indeed no silver bullet. You still need to think about thecomplexity of your domain and the approach you want to use. There is a lot of difference among MDD approaches and you still need to select the right approach for your situation.
Tool support and popularity
An interesting answer on the question comes from "mko": "Microsoft / Apple / Google isn't pushing it". He adds "What kind of development gets popularized has much to do with tools, backer...
Why aren’t we all doing Model Driven D…
« Code Generation 2011 | Home |
Why aren’t we all doing Model Driven Development yet?
16 April 2011 Johan den Haan About a month ago Kees Dijk asked a question on the programmers StackExchange titled "Why aren't we all doing model driven development yet?". He reiterates his question also as "What do you see as the biggest problems thatmake you not even consider model driven development?". It shouldn't be a surprise that I'm interested in these kind of questions. The answers, in this and other discussions about this subject, are interesting food for thought. Why? Because if you only read these 15 reasons why you should start doing MDD you would become curious why we aren't doing it all by now... Let's look at some of the mainconcerns which prevent people to use MDD, as mentioned in this StackExchange thread.
No Silver Bullet
The most upvoted answer on the programmers StackExchange refers to the essay of Fred Brooks "No Silver Bullet Essence and Accident in Software Engineering". Written in 1986 and still a valuable read! Brooks follows Aristotle in dividing difficulties in essential and accidental ones. Essentialtasks in software engineering are about the fashioning of the complex conceptual structures that compose the abstract software entity. Sounds abstract, but it means that constructing data sets, relationships among data items, algorithms, and invocations of functions is complex, inherent from their representation. Accidental tasks in software engineering are about the representation of these abstractelements in programming languages and the mapping of these onto machine languages within space and speed constraints. High-level languages are solving some of the accidental difficulties and are therefore valuable, but the essence of the problem remains the same. The specification, design, and testing of conceptual constructs need to be done by people, no tool will help you with that.
Dangersof MDD
Some followers of this blog may think I'm such a hardcore fan of MDD that I will now start defending MDD against Brooks. However, let's first try to get a balanced view on MDD. Please take notice of my previous articles 8 reasons why MDD is dangerous and 8 reasons why Model-Driven approaches (will) fail.
theenterprisearchitect.eu/…/why-arenat… 1/7
27/04/2011
Why aren’t we all doingModel Driven D…
In the first article I point at the following dangers: MDD actually introduces a lot of rigidity. Models are only flexible where flexibility has been designed. The roles of project members are quite different. The modeling environment doesn't always support version control. The modeling tool / approach is "almost" finished at project start. The requirements team needs tounderstand what is allowed and what not. MDD is sold to the customer, but the team has no experience. Innovation distracts. In the second article I mention the following eight reasons for possible MDE / MDD failure: Not targeting all goals of Model-Driven Engineering. Only using one modeling dimension: the dichotomy between PIM and PSM. Focusing on generating new artifacts. Using general purposelanguages. Using custom defined domain specific languages. Using model transformations which are not fully executable. Not testing the model. Insufficient tooling. I'm mentioning these items for two reasons. First, not every approach called MDD is the same. Hence, your experience with MDD cannot be extrapolated to MDD in general. Second, MDD is indeed no silver bullet. You still need to think about thecomplexity of your domain and the approach you want to use. There is a lot of difference among MDD approaches and you still need to select the right approach for your situation.
Tool support and popularity
An interesting answer on the question comes from "mko": "Microsoft / Apple / Google isn't pushing it". He adds "What kind of development gets popularized has much to do with tools, backer...
Leer documento completo
Regístrate para leer el documento completo.