Discusión sobre la adopción del desarrollo guiado por modelos

En el grupo MDA-Discussion de Yahoo, existe un interesante debate sobre las posibilidades de adoptar el desarrollo orientado por modelos en la construcción de software. Como en muchas oportunidades, el tema dió motivo a un buen intercambio de ideas que abarcan también otros elementos del problema. Dos o tres puntos son destacables.
El hilo nace con una consulta de Arnel Periquet al grupo, cuestionando tres aspectos:

• Modelos ejecutables: ¿tiene sentido formalizar un modelo completo, cuando los desarrolladores pueden manejarse con bosquejos parciales, luego de comprender el modelo general "mentalmente"?
  
• Generación de código: generar código al inicio es posible, pero ¿es posible realmente manejar los problemas de mantenimiento?
  
• Exploración del diseño (o análisis del modelo): el análisis del modelo es una tarea colaborativa, donde intervienen distintas partes ¿puede MDA manejar este trabajo colaborativo?

En palabras de Arnel:

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?

La respuesta de H.S.Lahman (Pathfinder) , sobre el primer punto:

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 ofthe 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.]

Sobre el segundo punto:

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.

Sobre el tercer punto, Lahman lo considera ajeno al problema:

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.)

La discusión es más amplia, y puede consultarse libremente en el grupo, a partir de su raíz. En otro momento, otros aspectos.