Hi,

I'm examining various model driven approaches and their applicability
to organizations that have a commitment to existing open-source OO
frameworks they own.

Let me bounce off some observations I have regarding developer
behavior in practice and why I believe developers, sometimes
justifiably?, believe using models "in their head" and "on paper"
along with conventional IDE tools provides an advantage over MDD.

For example, experienced developer behavior can often overcome the
proposed advantages of MDD. Here's a list of some MDD advantages and
conventional developer behavior:
- model execution <==> source level debuggers
- code generation <==> initial development
- design exploration <==> collaborative whiteboard

Model execution is useful for understanding domain element
interactions abstractly, e.g. how file formats, decoders, cameras and
audio/video renderers typically interact in multi-media systems.
After developers learn the domain, they map the implementation to it
mentally while stepping through code. If more formalization is
needed, UML diagrams are formalized and their system constraints are
tracked. The process relies on developer experience and
communication. Albeit, turnover of developers experienced with the
code base and non-conformance to system constraints and architecture
can cause problems. On the whole, however, process checks exist to
keep rapidly changing constraints and general maintenance violations
in check. - It seems like domain knowledge isn't so much the
advantage of automation, as is the mapping knowledge from domain
concepts to how they are commonly implemented and maintained. It
would be nice if the models "teach us" the mapping as well as the
domain, but marks seems to hide the former. Is this a valid concern
and how is it addressed?

Code generation that takes 5 minutes versus 3 days of manual coding
is an advantage of only fixed cost. The real cost is in program
maintenance. - How does the MDA address maintenance concernces, I
mean, other than re-generation? Are there techniques for exposing
design actions that map to program manipulation?

Finally, exploring design alternatives with models instead of code is
a seemingly decided advantage with MDD. However, design exploration
is often a collaborative process involving mutiple experts and
stakeholders, e.g. product manager, project managers, architects,
designers and testers. The input from various levels should be staged
according to adopted process, e.g. agile. This could provide one
explanation of the use of whiteboarding and conference calls over the
adoption of MDD tools at the system architecture level. - Do MDA
tools directly address collaboration?

How do existing approaches address these issues?

Thanks very much for the input!

-Arnel