Code Generation 2008, faltando dos meses

Probablemente la proxima mención sea para publicar lo que esté disponible de la conferencia. Pero, estando ya consolidado el programa de actividades, y habiendo avanzado en el número de auspiciantes, vale la pena volver a recomendar su seguimiento; y para quien pueda, la participación.
Entre los temas propuestos, un buen número de trabajos sobre DSL (Domain Specific Languages) y DSM (Domain Specific Modeling), con participaciçon especial de miembros de Microsoft (Steve Cook). En general, de los trabajos , me parecen importantes estos:
Mark Dalgarno, MDSD and Software Product Lines - a marriage made in heaven? , porque encara las correlaciones entre diseño por modelo y SPL; Brooke Hamilton, Evangelizing Code Generation: A Case Study of Incremental Adoption , porque trata un caso donde la generaciçon de cçodigo se adopta progresivamente en una empresa; Bernhard Merkle, Modelling Standards: what exists, what's missing and what failed?, porque se enfoca en los problemas; y Chul Hwee Kim, Managing Complexity with Domain Specific Visual Languages, porque aplica DSL a problemas complejos.
Entre los participantes y expositores, Anneke Kleppe, Mark Dalgarno, Steven Kelly, Pedro Molina, Juha-Pekka Tolvanen, y Steve Cook.

Las redes sociales como negocio

Therese Poletti, en Market Watch, se pregunta si la compra de la red Bebo por AOL no revela un alcance más realista de este negocio, contrastándolo con la valuación teórica de Facebook (The $850 million all-cash deal was a huge payday for Bebo and its founders, but at the same time, the deal may have placed a lower valuation of Facebook, the darling of social networks, which got its hefty valuation when Microsoft made its investment of $240 million in the Palo Alto, Calif.-based company, for a 1.6% stake).
Poletti se pregunta si el crecimiento de las redes sociales no es parte de otra burbuja, con empresas sobrevaluadas. Comparando Bebo y Facebook, las distancias en utilización no reflejan sus valuaciones:

That notion of a lower valuation, said Ray Valdes, an analyst with Gartner, is based on imperfect data and a range of estimates that Facebook is anywhere from 2.5 to 7 times the size of Bebo. That data varies from monthly visitors to active users to registered users.

For example, Compete.com said Bebo had four million monthly visitors in February, versus 28 million at Facebook, a ratio of one to seven. But active users, as reported by Bebo, are 22 million and 66 million by Facebook, giving Facebook three times the number of users.

"If all things are proportional, it makes Facebook valued at $2 billion to about $6 billion, depending on what you use as a metric," Valdes said. "You could say that Bebo was undervalued or Facebook was overvalued when it was valued at $15 billion. In any case, there is a valuation gap."

Poletti destaca que parece advertirse, en el caso de Facebook, cierto estancamiento en su utilización; implicando en general un pago excesivo por parte de Microsoft por su pequeña participación en la sociedad:

At the same time, there is also a sense that Microsoft's investment in Facebook was at about the time of a peak of what some are calling a Web 2.0 bubble. With the markets now in turmoil and the economy in a decline, investment in startup companies may start to fall off.

Y, finalmente, se pregunta cuánto puede afectar el trato por Bebo-AOL, a otras redes, dedicadas a ámbitos específicos, en general profesionales, como LinkedIn:

It will be interesting to see how the AOL deal affects the value of other social networking companies, especially privately held LinkedIn, which targets business professionals, and niche players, such as ClubMom

Quizá una burbuja pudiera afectar en primer lugar a las redes sociales, y probablemente no tanto a otras dedicadas a actividades profesionales, académicas o de negocios, donde las ventajas de sus servicios son tangibles.

AS400 a pesar de todo

Publicado por Mark Fontecchio, en The ISeries Blog: la historia del ¿AS400? en un mousepad y una prenda de vestir. Mark lo toma de Cafepress.com, donde aparece una lista de prendas posibles. Con nuevo nombre activado, el AS parece que seguirá llamándose así, más allá de los cambios de marketing:

Ken Jack, a software engineer at trucking software company TMW Systems, has created the T-shirt you see to the right. He has it on his personal CafePress website called iWhatever.

Jack reflects the anguish of many System i users — er, users running i on Power Systems — who have a hard time figuring out what to call the server platform on which they run all their business applications. In a recent story on feedback of the System i/p merger, one user told me that he spent a long time trying to convince everyone in his organization that the server and platform should be called System i and i5/OS, not AS/400, iSeries, or OS/400.

Now that IBM has renamed it again to Power Systems and just “i,” expect some folks to just say forget it and start calling it AS/400 again.

That’s how Jack feels, as is apparent by this T-shirt he’s selling. He’s been selling a similar shirt for a while now, just adding on whenever IBM decides to rename the platform again.

“It’s honestly to the point where if IBM changes the name one more time, I’m going to have to put ‘continued on other side…’ on the front of the T-shirts,” Jack wrote in an email to me. “Just last month somebody bought a shirt that stopped at ‘System i.’ I bet he’s pissed.”

What are they calling it at TMW Systems? Jack said that “everybody at our shop still calls it ‘The 400.’ ‘Power System running i’ is just too much of a mouthful.”

By the way, in addition to buying the T-shirt, you can also buy other merchandise with the logo on it: mousepad, coffee mug, baseball cap, etc.

Bueno, como Plex, que parece que quedará como tal: Obsydian, Cool:Plex, Advantage Plex, Allfusion Plex, CA Plex...

Brad Appleton sobre Software Product Lines

Brad Appleton, que es una autoridad en administración de configuración y versionamiento, ha comenzado a enfocarse en Software Product Lines, con la particularidad de aportar el enfoque de la configuración, que debería ser un punto importante del problema. En el último tiempo ha dedicado al menos dos artículos en su blog:
Software Product-Line Architecture and Product-Families, dedicado a presentar brevemente el tema, pero apuntando al aspecto de la configuración.
Commonality and Variability Management, dedicado a presentar un aspecto central, el manejo de los aspectos comunes y las variaciones, con referencias a algunos papeles que discuten el problema en detalle.
Hoy simplemente quería destacar la participación de Appleton. En otro momento volveremos sobre el tema, como seguramente lo hará él mismo: Unir SPL con SCM es algo que se produce naturalmente.

Argentina: Polo tecnológico en San Luis

Publicado en La Nación, hace pocos días: la provincia de San Luis incrementa su oferta tecnológica, con la colaboración de la Universidad de La Punta. Dentro de la línea de usar la promoción para incrementar la actividad económica en la provincia, nuevas facilidades disponibles:

SAN LUIS.- La Universidad Provincial de La Punta (ULP) inauguró un polo tecnológico de desarrollo de software destinado a la radicación de empresas que explotan servicios informáticos.
Con el objetivo de absorber la mano de obra que se forma académicamente en esa casa de estudios, la propuesta consiste en el arrendamiento de espacios físicos con pago de peaje sobre fibra óptica y descuentos de hasta el 40% en los primeros cuatro años de actividad.
Con una inversión de 7 millones de pesos iniciales, la ULP ofrece a los capitales interesados los beneficios de la ley provincial de creación del Parque Tecnológico, con el reintegro del 10% de la masa salarial contratada los primeros 2 años y de un 5% por dos años más.
Los descuentos se extienden a los costos de arrendamiento de oficinas, reduciendo, en algunos casos, la locación inicial, tasada en 10 dólares por metro cuadrado, a 6 dólares mensuales como único gasto empresarial. Con una superficie de 3264,8 metros cuadrados y capacidad para albergar a 12 empresas, el Parque Tecnológico de La Punta (PILP) cuenta en la actualidad con cinco firmas radicadas que "emplean a 102 jóvenes de aproximadamente 25 años, con un sueldo promedio de 2500 pesos", afirmó la rectora y ministra del Progreso de San Luis, Alicia Bañuelos, que destacó que para fines de 2008 "la universidad planea construir más edificios para el PILP" que amplíen esa oferta.
En la actualidad operan en San Luis Mercado Libre, Indra, Telesoft, Unitech y Vit4b y poseen convenio firmado Accendra Networks, Axxon Solutions, Call Center Superville, Ciliare Sofware, Competir.com, Gevenue Technology e Intercomgi. Durante el acto de inauguración del PILP, que incluyó además el edificio del Rectorado de la ULP y los 37 departamentos de 140 plazas destinados a los alumnos de la Tecnicatura en Desarrollo de Software, los empresarios destacaron el marco jurídico, la formación universitaria y la infraestructura tecnológica de la provincia como los principales factores para decidir su radicación.
Incentivo permanente
En esa oportunidad y tras reconocer que, en un comienzo, la relación con las empresas será "deficitaria", el director del PILP, Cristian Moleker, señaló que "por la ubicación geográfica de la provincia es difícil que las industrias tradicionales se desarrollen sin una política de incentivo permanente".
El funcionario agregó que "en las empresas de software, el 80% del costo corresponde a salarios, contra el 30% de la industria tradicional. Esto se debe -explicó- a que en esta última el 70% se va en transporte y adquisición de materia prima. En cambio, en la industria informática, sólo se va en ese rubro un 20%, por lo tanto, este tipo de empresas generan una actividad de alto valor agregado que impacta directamente en sus recursos humanos, que por lo general son jóvenes".
Para Ricardo Viaggio, director general de Indra, que se propone desarrollar sistemas para exportar a Europa, "San Luis muestra una trayectoria que es lo que busca la empresa para ubicarse en un lugar en el que pueda permanecer en el tiempo". Al igual que Ramón Ortega, de Raona, Daniel Rabinovich, de Mercado Libre, destacó la seguridad jurídica como factor que los anima a invertir en tecnología.

Por Claudia San Martín

Johan den Haan sobre Model Driven Engineering

Johan den Haan es un joven especialista encargado en su empresa (Mendix) de investigación y desarrollo. No recuerdo exactamente si lo encontré a través de la referencia de algún colega, o si fue a través de LinkedIn, donde participa también. El caso es que mantiene un blog sobre arquitectura que recomiendo para todos los que quieran profundizar sobre el diseño y construcción por modelos. Acaba de publicar un artículo que avanza sobre las características de la construcción de modelos ejecutables, que puede ser clarificador para quienes quieran profundizar. En unos días más quizá lo tome en detalle, pero vaya ahora su introducción:

In a previous article about Model-Driven Engineering I've stated that the basic principle of MDE is that "everything is a model". Models and model elements are given a first-class status. The essential change is that models are no longer used only as mere documentation for programmers, but can now directly be used to drive software development. Models are used to define implementations, transformations, aspects of software artefacts, viewpoints on a system, and so on. In this article I define what a model is (taking into account the different usage scenario's for a model) and how models can be defined using metamodels.

The definition of models with metamodels can be seen as a language definition which can be done using a general purpose language or a domain specific language. In most approaches a choice is made between a general purpose or a domain specific language. I think both approaches can be combined using the best from both worlds. I'll show the power of this approach with a process modelling example using BPMN and BPEL to build a domain specific process modelling language which is almost directly executable.

Adopción de Tecnologías de la Información en América Latina

El World Economic Forum publica sus informes de evolución de distintos parámetros de análisis de la economía global. Los informes son amplios y es convenientes verlos relacionados entre sí para obtener una visión más completa; en particular, el dedicado a tecnología de la información muestra un leve retroceso para Latinoamérica. El comentario de América Economía, de donde proviene la información:

Sólo cuatro economías de América Latina y el Caribe se encuentran entre los primeros 50 puestos del Global Information Technology Report, un informe del World Economic Forum que evalúa el impacto de las tecnologías de la información y la comunicación (TIC) en 127 países de todo el mundo.
Chile (34), Barbados (38), Puerto Rico (39) y Jamaica (46) son las economías más conectadas de la región, seguidos por México y Brasil, que descendieron hasta los puestos 58 y 59 respectivamente, señala el reporte, difundido este miércoles.
La mayoría de los países de América Latina van a la cola del ranking, en el siguiente orden: Costa Rica (60), Uruguay (65), Colombia (69), República Dominicana (75), Argentina (77), Guatemala (80), Perú (84), Venezuela (86), Honduras (90), Ecuador (107), Bolivia (111), Nicaragua (116), Surinam (117) y por último Paraguay (120).
“El panorama sobre la preparación de los países para utilizar las TIC de manera eficiente para América Latina y el Caribe es menos positivo que el año anterior”, afirmó Irene Mia, economista senior de la Global Competitiveness Network en el World Economic Forum y una de las editoras del Informe.

La elaboración del índice puede no ser suficientemente rigurosa, pero de todas formas entrega un conjunto de indicadores que dan una aproximación:

Para elaborar el ranking, se construyó el índice de Networked Readiness Index (NRI), que examina el grado de preparación de los países para utilizar las TIC de manera eficiente.
En particular, se abordaron tres dimensiones: el entorno de negocios, reglamentaciones e infraestructura de las TIC en general; la preparación de los tres principales interesados (individuos, empresas y gobiernos) para utilizar y beneficiarse de las TIC, y su nivel real de utilización de la última tecnología de la información y la comunicación que se encuentra disponible.
Para construir el NRI, se utiliza una combinación de datos provenientes de fuentes públicas y los resultados de la Encuesta Ejecutiva de Opinión del World Economic Forum. El informe es generado en colaboración con la escuela internacional de negocios INSEAD.

De las posiciones relativas del ranking, son de interés las primeras, lideradas por Dinamarca, Suecia, Suiza y Estados Unidos, en ese orden. Del mundo iberoamericano, España ocupa el puesto 31, Chile el 34, México el 58, Brasil el 59. Y Argentina, 77.
El informe también ofrece una planilla comparativa entre el correspondiente a este año y el anterior. Se puede ver allí que en general los países nombrados latinoamericanos retrocedieron posiciones: Chile del 31 al 34, Mexico del 49 al 58, Brasil del 53 al 59, y Argentina del 63 al 77.
Es posible examinar en detalle cada uno de los ítems que componen el índice, país por país. En el caso de Argentina, un aspecto destacable es que varios de los aspectos más negativos de su clasificación están relacionados con la actividad gubernamental: número de trámites para comenzar un negocio, 112; efectividad para elaborar leyes, 124; carga de regulaciones gubernamentales para abrir un negocio, 113; eficiencia del marco legal, 121; independencia judicial, 119; etc, etc.
También es posible comparar dos países, lo que puede representar un interesante ejercicio de competitividad. Para aquellos que piensan que nuestros países están atrasados por razones que están fuera de nuestro control, nada más interesante que compararse contra un país pequeño e irrelevante aparentemente, que esté bien ubicado en el ranking. Yo probé Argentina contra Islandia, en aspectos como infraestructura, educación, investigación, disponibilidad para los negocios. Los resultados son una bofetada.

Oportunidad para el outousourcing en Argentina

Pablo Pizarro me hizo notar (gracias a las facilidades de del.icio.us) la existencia de esta nota de BussinesWeek, de gran interés para Argentina y otros países de América Latina. Rachael King escribe sobre un fenómeno que era esperable: en la medida en que la industria del software en India (y otros países precursores del outourcing) se hace estable, sus costos se incrementan. Sumado esto a la creciente caída del valor del dólar, de la generalización de la subida de costos de India (y otros países que están pasando a una nueva fase de su desarrollo), ya las diferencias entre presupuestar en India o hacerlo en América Latina, no son tan grandes para la industria estadounidense (o europea). Sumado a las diferencias horarias, se está creando un mundo de oportunidades.
BusinessWeek sobre los costos indios:

Companies that traditionally rely on India for offshore IT services have been looking for that something beyond India for years, citing such reasons as high employee turnover and unreliable communications. But the search has taken on added urgency recently, especially for U.S. companies, as a weakening dollar has boosted the cost of IT services priced in India's rupee. Over the past five years the dollar has declined about 16% against the rupee. High real estate costs and expectations for tax increases also have diminished India's allure.
As outsourcing to India becomes more expensive, North American companies are more inclined to "nearsource," keeping work in the Western Hemisphere, where they can operate in a closer time zone. In years past a company could save 40% to 50% by hiring Indian firms to handle IT and other services, says Atul Vashistha, chairman at neoIT, a management consulting firm. Should the U.S. dollar continue its descent, that differential would shrink to 10% to 20%, he estimates. "If you're only going to have a 20% savings, clients start to think about time zone," Vashistha says.
(...) How much longer the world's companies will have financial incentive to outsource to India is a matter of lively debate. India's "advantage as an offshore location is fast eroding—its attractiveness takes a hit with each passing day," analysts at Forrester Research (FORR) wrote in a January, 2008, report. Forrester catalogued some of the well-known challenges, such as increasing staffing costs, turnover and strained infrastructure (BusinessWeek.com, 12/11/06). Yet, there are newer challenges as well, including the falling dollar and expected tax revisions that may increase the cost of relying on outsourcing providers.

Sobre la comparación de costos con América Latina:

Contracts are written in dollars, and as much as 60% to 80% of Indian service providers' revenue is in U.S. dollars, but more than half of their costs are incurred in rupees, according to an October report from Forrester. Indian outsourcing powerhouses like Wipro are feeling the squeeze. They've strived to cut costs, and now they're raising prices to keep margins from narrowing further. "We are relentlessly driving for higher pricing for our services and have seen price increases from our customers in the range of 3% to 6%, and our new customers are coming in at around 5% higher than our average," Wipro Chairman Azim Premji said on a conference call with investors on Jan. 18.
Duke University professor Arie Lewin estimates that the benefit of doing business, from a labor-cost point of view, in such locales as Bangalore, India, will disappear for some companies in three to four years. That's due to a combination of dollar depreciation, wage inflation, and other costs. Others say it will take longer. "Costs are escalating, so the level of labor arbitrage isn't as great as it used to be, but that's not to say labor arbitrage is disappearing, nor will it disappear in the next 10 years or so," says Sid Pai, partner and managing director of TPI India, a sourcing advisory firm.
Indeed, while costs are increasing in India, the country is generally less expensive than Latin America and most other locations, especially for companies that don't require high-end software developers. The average annual salary for an IT worker in the U.S. is about $75,000, according to a late 2007 report by Alsbridge, an outsourcing consulting firm. In India it's about $7,779 and in Argentina, it's slightly higher at $9,478. In Brazil, the annual wage jumps to $13,163, and in Mexico it climbs to $17,899. "The bottom line is that there aren't great alternatives with the scale, quality, price structure, and the lack of risk of India," says Stephanie Moore, vice-president at Forrester.

Sobre Argentina:

Kimberly-Clark (KMB) had time zone in mind when it hired Cognizant Technology Solutions in Buenos Aires to handle tech support for its SAP (SAP) software applications.
Kimberly-Clark was drawn by the available talent and the fact that the company has Argentine operations but also because geographical proximity and similar time zones make collaboration easier. "We picked Buenos Aires for a number of reasons, but we really felt from supporting SAP, it was the right place to be," says Kimberly-Clark Chief Information Officer Ramon Baez. The company also outsources application development and maintenance to Cognizant in Chennai, India.

BusinessWeek enfoca a México, Argentina, Brasil (especialmente) como posibles receptores de outsourcing en estas nuevas condiciones. Y queda claro que los competidores indios son promotores de este cambio, señalando a Cognizant, Tata, Wipro, e Infosys, como empresas de ese orígen que están activando la ventaja de la diferencia horaria, costo y calidad de recursos.
King de todas formas apunta que la escala de Latinoamérica está lejos de las posibilidades de India, particularmente. La oferta de desarrolladores (u otras áreas de outsourcing) será siempre menor a la esperable en India. Pero la oportunidad existe, particularmente en la medida que se puedan ocupar nichos de especialidad y mayor valor.

El desarrollo de software es un arte?

Rodrigo Corral ha publicado en su blog una entrada sobre la idea del software "al modo industrial" que se explica desde su nombre: "La falacia de la industrialización del desarrollo de software ".
Más de una vez aquí se ha hablado de este tema: en realidad forma parte de la temática de éste blog, y no hace mucho se ha escrito sobre ésto. Como en muchos puntos lo veo de forma muy distinta, creo que debería dedicarle algunas líneas, a modo de extensión de lo que dejé en su entrada como comentario.
En primer lugar, creo que Rodrigo escribe pensando en la industria del software, en empresas específicas, y en políticas comerciales y de recursos humanos. Es probable que en este terreno tenga razones para sus afirmaciones sobre la necesidad de reconocer el valor de cada desarrollador.
Pero no comparto que se extienda el cuestionamiento al propósito de establecer criterios que normalicen el proceso de construcción. Si aceptamos que existe una ingeniería de software, se debe aceptar también que sus intenciones son reducir el riesgo y la incertidumbre en la construcción de software, establecer procedimientos, medir y proyectar, utilizar patrones repetibles.
Por supuesto, el desarrollador tiene importancia. Pero un equipo, y un plan de construcción, no pueden depender de las individualidades: desde hace mucho, reducir la indeterminación ha sido una preocupación generalizada, ante la evidencia de que sin criterios claros de manejo del proceso, un proyecto puede convertirse en interminable, o mucho peor, terminar dramáticamente sin lograr sus objetivos. La historia de la industria está plagada de estos casos. Además, el software debe ser mantenible: no basta crear un software por única vez, sino que debe sostenerse en el tiempo: si dependieramos de las individualidades, cada vez que se produjera una baja del equipo de trabajo, la situación sería calamitosa.
A diferencia de lo que Rodrigo mencionara, como bien se puede ver aquí, creo en la positividad de todas aquellas líneas de investigación que tienden a asegurar procesos más confiables, sea en la utilización de procesos repetibles de manejo del ambiente de construcción (Administración de cambios, seguimiento de defectos, manejo de configuración), como en las herramientas mismas de modelado y generación (generadores de código).
No creo que ninguno de esos elementos vayan en perjuicio del desarrollador, del recurso humano, sino que proponen una actividad más creativa, particularmente en el caso de las nuevas generaciones de 4GL, que permiten poner el acento en el modelado, en lugar del "picado de código".
Quizá la línea de investigación de Líneas de Producto Software sea el ejemplo más generalizador y demostrativo de qué es lo importante del "sofware como industria": SPL propone el planeamiento anticipado, la utilización de patrones, el reuso de partes, la existencia de un repositorio de componentes, la utilización de herramientas de generación de código.
Finalmente, quiero hacer notar que una vía artesana de trabajo, considerando el volúmen que adquiere la intervención de la informática en la economía y la sociedad, si fuera realmente el paradigma aplicado, haría que un alto porcentaje de desarrollos corrieran totalmente por detrás de su necesidad.
En fin, repitiendo lo que le escribía a Rodrigo, "no me gusta la idea de que la construcción de software es un arte, y el programador, un artista. Reconozco que en su construcción hay lugar para la creación y para la belleza (de un algoritmo o de una solución de arquitectura), y que forma parte de la motivación, pero también a esa disposición se la puede calificar con otros nombres, más cercanos a la ingeniería. No me opongo a su existencia, y es excelente trabajar con colegas que den soluciones brillantes; pero no creo que sea conveniente basar una estructura persistente en individualidades, porque dependeremos de ellos. El software debe ser mantenible, y debe tener tiempos de construcción estimables, o al menos planeables. La metáfora de la fábrica siempre la interpreté en ese sentido, y estoy seguro que todos aquellos que han rondado esta idea, lo han hecho en la misma dirección".
Estoy seguro sin embargo, de que la diferencia con sus afirmaciones se reducen a un matíz, que sin embargo quizá sea de importancia.

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.