Responding to Arnel_periquet...

>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?
>
>

One problem here is that stepping through the code is employing a
representation that is an order of magnitude less compact that an OOA/D
model. In addition, the code addresses many different concerns at the
same time (e.g., both functional and nonfunctional requirements
resolution is mixed together by the time one gets to OOP). But the big
problem is the level of abstraction. The advantage of dealing with the
design in an OOA/D model is that one is not distracted by the details of
implementation like language vagaries, particular technologies (SOAP,
CORBA, etc.), and techniques (collection class libraries, refactoring to
reduce the physical coupling of 3GLs). Those details constitute most of
the order of magnitude difference in compaction.

I would also point out that an OOA/D model is supposed to be a complete,
precise, and unambiguous specification of what the software
implementation must do. So there shouldn't be a need for more
formalization and the models aren't teaching anything because they /are/
the solution. It is that rigor that allows model level simulation to
validate that the design has satisfied the functional requirements prior
to committing to code.

Bottom line: I think the point of MDD is that one doesn't have to step
through the code to figure out what it is doing or to validate its
correctness with respect to functional requirements. IOW, the big gain
is not dealing with 3GL code. [As a translationist, I doubt I have
written 10 KLOC of 3GL code in total since 1990. I also regard a 3GL
debugger like MS VC/C++ pretty much the same way a C/C++ programmer
regards an assembly debugger -- life is simply too short for that.]

>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?
>
>

I would have to argue that the main advantage of MDD code generation is
that one /can/ re-generate the code rather than mucking with it at the
3GL level. That ensures that the OOA/D models are always in synch with
the actual code and it removes the need for worrying about things like
maintainability refactoring. [I know one translation vendor who
deliberately makes the generated code difficult to read to prevent
people from making changes to it rather than the model.]

However, MDA does support round-trip development by providing a semantic
framework with meta models so that tool vendors can provide reverse
engineering of code changes back into the models. Unfortunately that is
inherently limited because design information about Why things were done
the way they were is lost by the time one gets to 3GL code. That's
because there tends to be a *:* relationship between OOA/D model
artifacts and the OOP implementation mechanisms. So working backwards
from 3GL code tends to be ambiguous. IOW, reverse engineering provides a
model of the code rather than a model of the design.

>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?
>
>

I think this is a quite different issue. It is about how one defines
requirements. Product managers, end users, and SQA people are not going
to be looking at either 3GL code or OOA/D models, so it really doesn't
matter how the developers express their solution design.

One thing to note is that UML combined with a compliant abstract action
language is a 4GL. IOW, when one is creating an MDD model one is
programming in the same sense that 3GL programmers do; it is just at a
higher level of abstraction and resolving nonfunctional requirements has
been delegated to a different trade union (the transformation engine
tool vendors). That has two important implications here. The first is
that one still needs requirements prior to programming and the shop
needs a process for defining them and managing changes to them. How
formal or informal that process is depends upon the shop's culture, not
whether one is programming in a 3GL or 4GL.

The second point is that agile techniques can be applied to 4GL
development in much the same way they are applied to OOP development.
(There is a paper on the Pathfinder web site that describes how XP's
practices map into translation-based MDD development.)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@...
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@... for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH