La desaparición de Peoplesoft

Finalmente, esta última semana de diciembre, Oracle tomo control formalmente de Peoplesoft. Luego de varios meses de presión sobre los accionistas, Peoplesoft sucumbió tras haber provocado previamente la desaparición de JDEdwards. Así, en un solo año vimos la extinción de dos grandes competidores del mercado de aplicaciones corporativas (ERP), y estuvimos cerca de que ver la compra de SAP por parte de Microsoft.
Luego del estallido de la "burbuja tecnológica" posterior al año 2000, la tendencia es a la consolidación y simplificación del mercado a un nivel sin precedentes, y pareciera que continuará este camino durante el 2005. Podría pasarme un largo rato contando los que estaban y ya no están, pero simplemente enumeraría aquellas empresas con las que tuve o tengo algo que ver: sin hablar de Plex, que tuvo a bien quedar en manos de uno de los grandes competidores (aunque Computer Associates atraviesa también "tormentas huracanadas"), mencionaría a Brío, que irónicamente fue comprada por Hyperion, el dueño de la base de datos que utilizara como "companion" de sus productos OLAP, invirtiendo la relación de fuerzas entre ambos productos. O Netviz, que pasara de ser un interesantísimo concepto de visualización de redes, a ser un apéndice de una compañia dedicada al monitoreo de performace (Concord Communications), estrechando su alcance al interés que el nuevo dueño pueda dedicarle. Techrepublic dedica un breve artículo que toma palabras de Joe Tucci, CEO de EMC, destacando la importancia y el impacto de esta característica dominante. Allí se encomillan las palabras de Dan Farber,
". . .if you don't get big fast, you will be left behind. If you are swift, small and innovative, you'll likely get scooped up by a big fish. Companies in the middle will have the hardest time surviving in the current consolidation phase." El artículo de Techrepublic da una pequeña lista de las adquisiciones del año, que son muchas más, siempre eliminando a un pequeño competidor con alguna virtud brillante, a manos de otro actor con una buena chequera.
No veo esta consolidación como un factor positivo. Más bien parece un corolario de la primera oleada de desapariciones, cuando la innovación y burbujeo producido por el surgimiento de jóvenes empresas se fue acotando a un reducido número de participantes, que tendieron a "enfriar" las nuevas ideas. Desde este punto de vista, vamos hacia las glaciaciones.
Qué conclusiones se pudieran sacar?

• La concentración de los participantes no traerá mejores condiciones de negociación, ni mejores precios o servicios para los compradores de software. No es esa la regla de los monopolios
• La innovación queda en pocas manos. No es un marco para el estímulo de la audacia de pensamiento: If you are swift, small and innovative, you'll likely get scooped up by a big fish.
• Tanto la fuerza creativa de los ahora empleados de alguna corporación gigantesca, que no conoce ni siquiera la cartera de productos que vende, como la confianza de los usuarios de cualquiera de los productos afectados, marchan hacia un estado de desconfianza en el compromiso con su producto. ¿Quién puede creer en la continuidad y soporte de un software, si éste fue tratado como un commodity, y pasó por tres ventas (Por ejemplo, un usuario de JDEdwards)?
• Quisiera mencionar a los perdedores: La caída de Peoplesoft, por caso, no sólo afectará a sus actuales 12.000 empleados, que deben estar buscando trabajo, sino también a sus distribuidores, a las empresas consultoras que invirtieron en costosas certificaciones de capacitación, a las empresas que pagaron centenares de miles de dólares, o millones, por implantar un producto que ahora será descartado, o desalentado.

Sin embargo, Gran Corporación fue muchas veces sinónimo de dinosaurio: éstos son grandes, les cuesta moverse, les afectan los cambios climáticos, y subsisten a condición de comer grandes cantidades de alimentos. Muy probablemente, una nueva generación de pequeños y voraces competidores les presente batalla por la comida.

Otras vías menos estructuradas de manejar los datos

Luego de más de dos décadas de dominio del modelo relacional, y luego de un interregno de bases de datos orientadas a objetos, otras posibilidades se están prefigurando. El modelo relacional, y su complemento, el SQL, cumplieron, y seguirán cumpliendo un papel básico, como columna vertebral de la alimentación de datos de un dominio determinado. Un caso donde esto se puede ver, es en la relación entre el almacén de datos (Datawharehouse) y el repositorio del que se extrae la información. Pero está claro que la realidad es heraclitana, no parmeneidana, por decirlo en los términos de la filosofía natural antigua. La vida económica, social, o cual fuere, se mueve y fluctúa muy rápidamente considerada frente a su representación informática. Contínuamente las representaciónes de los datos en filas y columnas se revelan insuficientes para explicar situaciones más complejas de atributos variables, extendibles o achicables, con excepciones contínuas y fluctuantes. Tratar de abarcar estas hace correr detrás de los cambios, reduciendo las posibilidades a un reflejo empobrecido y esquemático. Una representación útil para los datos troncales, y aún así, insuficientes. El flujo de información en Internet es quizá el mayor ejemplo de esta limitación, y también el mayor motor para buscar mejores modelos.

Así, en este contexto, un gran estímulo a estudiar nuevas aproximaciones, lo constituye el XML, ya en uso en muchos casos en que se debe intercambiar una visión variable de los datos. El intercambio entre etapas de un modelo que se produce en el estándar en progreso de MDA, es un caso. Un breve comentario en este sentido lo hace Techfarmer en su weblog de ItToolbox. (Forget fixed format files, use XML!).
Pero el caso más elaborado que conozco, es el llamado Modelo Asociativo de Datos, del que William Simon es uno de sus exponentes. Simon, después de idear Obsydian, (que hoy es Plex, con el que yo trabajo todos los días, y que está orientado a generar aplicaciones a partir de un modelo abstracto), puso foco no ya en las aplicaciones, sino en los datos, e ideó un modelo muy estimulante, que todavía no tuvo quizá la discusión que se merece.
Como Simon dice:

The biggest driver of cost and complexity in database applications is the Relational Model of data, the standard database architecture underlying almost all modern applications.
Relational databases store each different type of data in a separate table. Each table is unique, and the programs are hard-coded to fit the tables. This is labour-intensive and wasteful, for two reasons: new applications always need new programs which have to be written from scratch, and any change to the structure of the data means that the programs must be changed too.

Su visión:

Instead of using a separate, unique table for every different type of data, Lazysoft's Associative Model of Data uses a single, generic structure to contain all types of data. Information about the logical structure of the data and the rules that govern it are stored alongside the data in the database. This sets the scene for a new style of programming, whereby the data structures and the rules that govern them are no longer hard-coded into the programs, but are obtained by the programs from the database itself. Thus, for the first time, such programs are truly reusable, and no longer need to be amended when the data structures change. This dramatically reduces the cost of application development and maintenance.

The quest for greater productivity in application development has focused on using more abstraction in programming languages, which have evolved from binary machine code through second generation symbolic languages and third generation high-level languages.However, 4GLs have failed to win widespread acceptance, and today's object-oriented programming languages are in truth no more abstract with respect to the real world than their third-generation predecessors.Moreover, the commercial failure of object-oriented databases means that most modern commercial applications are designed and developed using object oriented techniques, but implemented over relational databases, an impedance mis-match that imposes further overheads on the development process.Ted Codd acknowledged the connection between data architecture and programming productivity when in 1970 he introduced the relational model to the world with the words "Future users of large data banks must be protected from having to know how the data is organized in the machine". The next major breakthrough in software development productivity will come not from advances in programming languages, but from a new database architecture.

Tendrá el Modelo Asociativo un futuro? Como la evolución, puede ser una rama principal, el tronco, o un intento abandonado. Pero no hay duda de que es un intento de saltar hacia adelante.

Una visita a Buenos Aires

La semana pasada viajé con mi familia a Buenos Aires, después de un año conectado sólo por los comentarios y noticias de los amigos, los diarios, Internet y la televisión. Una semana de turista, pasada la hora de atención al público de las oficinas en donde debía hacer trámites. Encontré a la ciudad bastante desprolija, (dónde está la acción municipal?), pero con turistas extranjeros como nunca había visto, hoteles saturados, y mucha animación. Encontré en los amigos sentimientos ambivalentes, de expectativa y desconfianza, y una mejor perspectiva económica en casi todos ellos. Pareciera una nueva primavera, de la que todos desconfían que sea como el florecimiento del desierto: crecimiento rápido, flores, césped, aves, agua, hasta que vuelve el desierto. Evidentemente, existen nuevas condiciones de crecimiento económico basadas en la caída brutal de la moneda, lo que puede desaparecer tan pronto como el intercambio alcance un punto de equilibrio, y nuevamente sea más conveniente importar que exportar. Sin embargo, no todo es explicable simplemente por la caída de la moneda: en otras circunstancias, una caída así podría haber significado sólamente recesión, y sin embargo ahora se observan múltiples emprendimientos. Indudablemente el campo está trabajando a pleno, como se puede ver recorriendo los mil kilómetros de llanura de la ruta 7: nunca antes había visto tanta superficie sembrada, ni tantas instalaciones de silos de almacenamiento. Pero no hay que engañarse: sólo hacia fines de año, creciendo a un siete u ocho por ciento del PBI, se está alcanzando el nivel económico de 1998, el último año de crecimiento del período anterior. Hemos conversado con amigos que vuelven a trabajar en proyectos de reingeniería, pero en empresas que reinician desde un nivel de actividad muy bajo, y con metas de optimización muy básicas.
Sin embargo conocí en extensión algo que ya había visto el año pasado: la asociación de múltiples empresas con un objetivo común de expansión: crecer exportando, y mejorar los procesos, y certificar una normativa de calidad, para poder competir por mercados nuevos en el exterior. Así fue el cluster Córdoba, el Polo Tecnológico Rosario, y el Polo Tandil. Ahora pude conocer un poco más de ésto: más de dos mil cuatrocientas pequeñas empresas incorporadas a la exportación, en toda clase de rubros, desde muy primarios, con poco futuro quizá, hasta muy innovadores y de alto valor agregado.
Lo notable de casi todos estos casos es que es un crecimiento de abajo hacia arriba (no es una perogrullada), y marginal, naciendo de la iniciativa colectiva y la colaboración de empresarios, instituciones gubernamentales y ONGs, universidades y profesionales. A la tradicional colaboración del INTA y el INTI, se le suman particularmente Universidades tratando de aportar conocimiento y soporte para que pequeños emprendedores puedan obtener recursos económicos, técnicos y conocimientos para entrar al mundo de la competencia por los mercados internacionales. Un caso que me llamó la atención es el de la asociación de estos participantes en las ciudades de Pergamino y 9 de Julio, en la provincia de Buenos Aires. En el primer caso, colaboración para armar un polo textil, con la ayuda del know how de una institución italiana (el Programa Integrado de Cooperación Técnica italiano), y la participación de más de seiscientas PYMES. En el segundo caso, la misma especialización, pero para la fabricación de maquinaria agrícola. Un elemento común de estas iniciativas es la creación colaborativa de centros de servicos, capacitación, o calificación (el caso de Pergamino, Tandil, Córdoba, Rosario). Los más notables a mi juicio son los centros destinados a la certificación o evaluación ISO o CMM (Córdoba, Rosario).
Otro elemento común y característico, que ya hemos visto en nuestra historia, es la sustitución de actores. En otras épocas (Segunda Guerra mundial) fue sustitución de importaciones. Ahora debiera hablarse de sustitución de grandes operadores internacionales, por operadores locales. El mercado argentino sigue existiendo, pero los términos de intercambio, y la inseguridad jurídica, lo hicieron poco atrayente para un agente internacional. En cambio, los argentinos seguiremos estando, (y quizá un día con un país maduro), y así muchos servicios han sido tomados por nuevos actores locales en el espacio abandonado. Hoy no es fácil recurrir a un servicio del primer mundo, y así alguien ocupa ese territorio.
El lado negativo: una recorrida a los precios de la tecnología informática, me dice que el parque argentino devendrá obsoleto. La banda ancha en Internet recién comienza, aunque se están ofreciendo buenos productos (Fibertel a 1 MB), y la telefonía celular comienza a estar en todos lados.
Como alguna vez dijo Yrigoyen (no soy radical) "una forja parece un mundo que se derrumba"

Los amantes del código bien temperado

Hace poco, buscando otros asuntos, me dí con una discusión acerca del uso de "Obsydian", en la que alguien quería conocer experiencias de su uso, y alguien (no me interesa mencionar otros datos, porque no es el caso la persona) envió la siguiente contestación:

Personalmente no he trabajado con obsydian. Fui contratado para desarrollar y mejorar unas aplicaciones. Estas estaban desarrolladas con Obsydian. Realmente las hice de nuevo ya que la cantidad de códigos que mete la herramienta, es imposible hacer mantenimiento si no utilizas la herramienta. Como cualquier herramienta para programar (la que utilice genera código rpg) debe tener la mayor cantidad de posibilidades o rutinas para que estas sean efectivas, lastimosamente al desarrollar o crear el programa introduce todas estas rutinas aunque no se utilicen en programa desarrollado. Los programadores de otra instalación que desarrollan con obsydian me dijeron que era fácil de utilizar y rápido para crear programas. Me di cuenta que no eran programadores con experiencia en RPG y los rete a que ellos utilizando obsydian y yo programando en la manera tradicional quien terminaban primero, no aceptaron el reto. En una tercera instalación fui contratado (soy programador independiente) para desarrollar unos programas para mantenimiento de unas bases de datos, las cuales habían sido desarrollados con Obsydian, la verdad no se por que no utilizaron la herramienta para los programas de mantenimento. En el desarrollo de los programas se necesito cambiar las bases de datos. Yo propuse cambiar las bases de la manera tradicional, directamente en las DDS en el PDM, por alguna razón el analista no quiso y utilizo la herramienta para el cambio de las bases de datos, la verdad es que fue muy bonito la cantidad de pantalla y pantallitas de windows que se abrieron para cambiar y introducir un campo nuevo en la base de datos, y creo que mi hijo que no sabe programar para el As400 con esta herramienta la habría hecho, yo le dije que yo habría hecho el cambio en menos tiempo, mucho menos, pero bueno el era que el mandaba.
Conclusión si eres buen programador y tratas de crear un estándar en la programación, lo documentas bien, puedes reciclar estos códigos una y otra vez no necesitas una herramienta. Las personas que han corregido en alguna ocasión mis programas me han dicho lo fácil que resulta dar mantenimientos a estos, ya que cuando has visto uno se puede decir que ya los vistes todos. Las herramientas son buenas si quieres contratar gente sin experiencia y que vienen del mundo de ventanas.

Encuentro en esta contestación dos motivos fundamentales. Uno, la inconsistencia en la adopción de una herramienta por parte de la empresa usuaria. Otro, el punto de vista del programador. Sin embargo, quizá ambos confluyan a una idea compartida: Una herramienta "generadora de código" no es confiable, y un programador lo puede hacer mejor. En definitiva, ¿cómo es posible que una empresa que usa una herramienta de cuarta generación, la reemplace por un trabajo manual, o por decirlo de la misma forma, de tercera generación? Aunque sin duda se pueden alegar defectos del producto, creo que es la escasa adhesion al concepto, lo que produce la actitud del propietario de la herramienta.
Este es un punto de vista recurrente con el que tropecé en muchas ocasiones, que trabó antes y ahora muchos intentos de racionalizar la construcción de software, y no sólo en este terreno, sino también en otros: herramientas para la administración de cambios y uso del diseño visual (uso de diagramas). En resumen, la idea básica es que en la construcción de software lo más importante es el trabajo personal, y que programar es un arte que no debe ser cedido a procedimientos automatizados.
En el pasado, he trabajado con colegas que desconfiaban del producto generado, y revisaban el código resultante, y lógicamente, lo criticaban tal como lo hace quien escribe arriba. Lo que aquí se pierde es el bosque, por destacar al árbol.
Lo que el programador que escribe no observa, es la diferencia en productividad y consistencia:
No advierte que no se trata de comparar un programa, sino el conjunto entero de aplicaciones que compondrían el patrimonio de la empresa en que estaba: Su proposición implica que cada programador escribirá su programa, siguiendo estándares tan durables como lo fue la adhesion a la herramienta 4GL de la que habla: un año después de que el programador freelance desarrollara sus programas con el estándar A, llegará el freelance siguiente, que impondrá el estándar B, y criticará al 4GL, y al A. Como bien se vió durante la crisis del año 2000, al cabo de 5 años de desarrollos, un gran número de programas ya no son reconocibles, llegando al extremo de que algunos objetos se ejecutan sin código fuente.
Como bien dice, "es imposible hacer mantenimiento si no utilizas la herramienta". De eso se trata justamente.
El programador desafía al equipo que usa el 4GL a una competencia. Seguramente les ganará en un programa y un DDS (definición de una estructura de datos RPG), porque en el 4GL, Obsydian en este caso, se definirán elementos "superfluos", y ello mediante el uso del IDE del producto. (Ah, qué tiempos aquellos en que escribíamos en la línea de comandos de la consola!). Lo que debiera el equipo desafiado, es proponerle competir en un proceso completo, durante un año. Allí veríamos la diferencia que existe entre un programador que modifica directamente un DDS, y otro que construye un repositorio integrado. La diferencia la veremos cuando haya que producir una modificación que impacte sobre 50 programas y 30 DDSs, o cuando deba agregar un nuevo proceso, y cambiar cinco tipos de datos.
El programador se burla del analista que se niega a cambiar directamente el DDS, y de las "pantallitas" que se usaron para cambiar un tipo de datos, como lo hace del equipo que utiliza un 4GL. Lo lamentable es que proliferen (y no sólo en el RPG, sino en cualquier ambiente), los desarrolladores que piensan de esta forma, y desacreditan a quienes se esfuerzan por construír con "esas tonterías" donde no se puede hacer un algoritmo elegante.
Pero aún más lamentable, es que una empresa que adquiere un producto de esta clase, no mantenga el estándar, y deje a medio camino la inversión volviendo atrás, al recurrir a programadores que interfieren el código desde fuera, como lo indica el caso comentado. O cuyos usuarios no están convencidos del valor de lo que están haciendo.
Existe un promedio de desarrolladores convencidos de que lo fundamental es escribir código, y ven a los 4GL con hostilidad, y su peso, sumado a las partes no interesadas en el predominio de herramientas CASE, hacen que el uso de estas herramientas sea mucho menor que lo que se pudiera recomendar.

Food for Thought

Gracias a Quasimodo, usuario de un sitio argentino dedicado al C++ conocí la página "Food for Thought" de la Universidad de Sussex, en el Reino Unido. Si a alguien le interesa estudiar materiales básicos de programación en C++ y Java, Arquitecturas de Procesadores, Sistemas Operativos, Redes, Seguridad, Criptografía, Matemáticas, y otras disciplinas de base más, debe hacer una visita a la página. Y, con un poco de curiosidad, puede seguir visitando, por ejemplo, los nombres y antecedentes de sus profesores, los proyectos en desarrollo, las actividades de la Universidad, y, por qué no, el estilo de presentación de sus materiales, y su disponibilidad.
Luego, puede detenerse unos minutos, y pensar cuánta es la distancia entre esta Universidad, y lo que en nuestros países disponemos o planeamos.

Ajustando la nota anterior...

Un día después de escribir la nota anterior (Plex y MDA), Lucio Gayosso me alcanzó la presentación hecha el 1 de noviembre en Praga por Bill Hunt, que contesta mi nota con creces, estableciendo al soporte de los estándares MDA y UML como Candidate Release del producto. El horizonte de desarrollo para los próximos tres años establece una línea de profundización en el soporte de Java, particularmente J2EE y EJB, el soporte de .Net, y el soporte de servicios Web. Como era de esperar, la inclusión de Plex en el grupo Allfusion lo coloca en la corriente principal de herramientas de desarrollo de Computer Associates, creando la posibilidad de planear su uso como parte del manejo del ciclo de vida completo de un producto software. La perspectiva es la de integrar mejor (ya es posible) Plex con ERwin como modelador visual, con Harvest como administrador de código fuente producto, con Unicenter WSDM como administrador de servicios web, como aspectos explícitamente mencionados.
Y en particular, la inclusión del soporte de UML y MDA como Release Candidato, implica darle un poder y flexibilidad único a Plex, ya que se potenciará su capacidad integradora, tanto dialogando con otras herramientas (al poder intercambiar modelos con XML), como en su virtud de abordar arquitecturas complejas de aplicaciones de empresa.
Justamente, un elemento importante de la presentación de Bill, es destacar lo que ya hoy es un hecho, que a mí también me ha llamado la atención, que es la cantidad de recursos que hoy mismo dispone Plex como herramienta de integración utilizable en soluciones EAI, lo que indudablemente se extendería aplicando un esquema MDA más explícito.
Tan pronto disponga una URL donde localizar el documento, la incluiré aquí.

UML y otras vías de construír software basadas en un modelo

Uno de los argumentos de los opositores a la generación de código a partir de un modelo del problema, es que no es posible representar mediante diagramas visuales todos sus aspectos, como lo dicen Scott Ambler o Martin Fowler. En el estado actual, y en base a la variedad de artefactos disponibles con UML, es posible que ese argumento sea bastante débil, ya que cualquiera de ellos pudiera mapearse a código ejecutable, más tarde o más temprano, con la ventaja adicicional de que remodelar produciría un efecto inmediato de doble vía entre la representación visual y el código.
Sin embargo, puede irse aún más allá. Basándome en Allfusion Plex (o Plex a secas, considerando su historia de cambios de nombre), se puede decir que no sólo es posible tener un diseño conceptual, abstracto, basado en UML, sino que el modelo puede ser representado por otros medios. Plex basa su descripción del problema en "triples", verbos que describen atributos de objetos, que forman un repositorio único que explica el modelo en todas sus partes, y en este repositorio, el modelo gráfico es una parte.
Plex y MDA crecieron conociéndose, y con cierto grado de intercambio. En el pasado, Synon primero, y Sterling después, participaron en la OMG de los esfuerzos destinados a la construcción de conceptos más sólidos en la elaboración de Software. Quizá hubiera que hacer en algún momento una breve historia de esta evolución. Pero baste recordar que Synon fue participante del proyecto San Francisco (dónde quedó?), y que Synon y Sterling fueron parte de los esfuerzos por elaborar estándares en el manejo de un repositorio, el UML, CORBA y los componentes en general, y aún se encontraron en alguna ocasión con Fowler en esfuerzos comunes en la definición de tecnología para construír patrones de diseño. Debiera revisar materiales de congresos de la década del 90 (especialmente el de 1999) para encontrar estas coincidencias pasadas.
Si lo viéramos desde el enfoque de Plex, el modelo es expresado en forma visual, pero no es dependiente de los diagramas de ningún tipo, sino de una descripción casi narrativa, conservada en un repositorio que puede ser exportada como XML. Podríamos decir que las visiones PIM (Platform Independent Model) y PSM (Platform Specific Model) son representados en Plex a través del modelo en su versión Base, y sus variantes. Las transformaciones entre una visión y otra no requieren otra actividad que la configuración del modelo en una variante, y esto es una acción simple, a condición de haber construído el modelo con una política de configuración premeditada. Se podría decir aún más, ya que la arquitectura que construye al modelo basado en una visión de cuatro dimensiones (Versión, Variante, Nivel, y Lenguaje), permite solucionar en el interior del modelo algunos problemas que todavía no ví bien expresados en MDA: el manejo de la versión como un complejo evolutivo histórico. Qué significa esto: que en el momento en que Plex finalmente integre una herramienta de diagramación, un diagrama determinado (de clases, de actividad), se crearía en una dimensión dada de la configuración (aunque fuera en la base), y aún podría explotar las ventajas de la configuración en una variante o una versión.
En lo que a mí respecta, quisiera tener la libertad de usar un diagramador para representar lo que hiciera falta. Sin embargo, los diagramas UML pueden usarse solo limitadamente hasta ahora importándolos a la IDE de Plex, y básicamente para ERD. En algún momento, con Sterling, existió planificado integrar varias herramientas de tal forma que hubieramos sido "MDA compliant". Sterling planeaba vincular Spex, Biz, Plex, Joe, como un solo conjunto capaz de iniciar un modelo desde el proceso de negocios, hasta el código ejecutable (Biz => Spex => Joe => Plex). El paso a Computer Associates implicó la reubicación de herramientas, y sólo ahora, uno o dos años después, es posible ver una vinculación entre Erwin => Joe => Plex.
Sin embargo, es UML la única vía de pasar de un modelo conceptual a código ejecutable?. Plex a vivido perfectamente usando un repositorio basado en otra forma de describir el modelo, sin perder la opción de usar UML u otro lenguaje de representacion visual como parte del conjunto de recursos, y agregando a partir de la versión 5.1 la posibilidad de exportar o importar un modelo a XML. Es razonable propugnar un estándar común, y UML tiene un camino recorrido como tal, pero quizá sea XML el verdadero medio de intercambio.
Es necesario agregar que UML encuentra resistencias también desde un punto de vista comercial, especialmente desde el momento en que Rational devino en una dependencia de IBM, y creo que Microsoft es uno de ellos.
En fin, esta nota requiere volver sobre ella una y otra vez, en la medida en que algunas tendencias de definan algo más. Digamos que la idea yacente en MDA es fundamentalmente aceptable, y que puede ser alcanzada por más de un camino, entre ellos, el que Plex adopta.

Una mirada sobre los principios del desarrollo de Software

Un blog que promete ser interesante: Perpetual Developer, en IT Toolbox. Enfocado en las razones que llevan a "reinventar la rueda" una y otra vez, y deseando promover la reutilización del software. En sus palabras, al inicio:

My intention in maintaining this blog is to try and identify the root causes and fundamental reasons why software developers cultivate a mindset which is geared towards redeveloping software rather than reusing existing software. I know there are numerous technical challenges to achieving real software reuse and sometimes the cost of reuse is higher than cost of development. But is that the only reason why software reuse is not as high as one would expect it to be? Or is it that developers are not trained or not prepared or not motivated to practice real software reuse?

Many times I have heard the term that software development is more of an art than engieering and science. But isn't it ironic that many software engineers who are trained in the software science and engineering methodologies also end up becoming Perpetual Developers, who develop functionally same or similar software artifacts over and over again?

Trataremos de seguirlo...

Administración de Configuración y MDA

Charles Betz (Alphas0ng), en ERP for IT, febrero de 2004, se ocupa del manejo de la configuración del software, extendiendo su significado al seguimiento de todos los ítems constituyentes de un desarrollo dado. Puntualiza así el límite de muchas herramientas de control de cambios, enfocadas sólo en el código fuente, y eventualmente (agrego) en los objetos generados, y algunos artefactos relacionados (scripts, documentos del diseño y la implementación). El control de configuración debiera aplicarse sobre todo el ciclo de vida, idealmente por medio de la misma herramienta, y sobre el conjunto de los componentes del desarrollo. Cómo identificar un ítem y sus dependencias?. Alphasong apunta a los principios de MDA para la solución de este seguimiento. En sus palabras:

The point of using the OMG’s modeling standards are that they are languages with a precise representation, not merely diagramming standards. The standard XML format for OMG models is called XML Metadata Interchange, or XMI.
(...)

We have everything here we need to feed a configuration management system: objects with names and unique IDs, and a precise representation of their interconnections. Connections between servers and switches can be represented, between components and databases, and virtually anything else imaginable in the modern IT infrastructure. A competent XSLT programmer could convert this structure into whatever format a CMDB required; far preferable would be a CMDB that accepted this industry standard directly.

El autor denomina a esta visión Model Driven Configuration Management. Luego de leer su punto de vista, encontré esta discusión en los archivos de OMG, que me llevó a conocer el proyecto europeo Combine, destinado a conducir el desarrollo de componentes por medio de herramientas MDA. Cuál será su estado actual?

OO, MDA, XP

¿Es viable aplicar los principios de eXtreme Programming a un desarrollo basado en Model Driven Architecure? Esta pregunta abrió una serie de comentarios sobre cómo encaminar un proyecto MDA con un método, pero también sirven para examinar XP en acción. La discusión se puede seguir en el grupo (en verdad, uno de ellos) dedicado a MDA en Yahoo.
A propósito de esta discusión, otros conceptos y relaciones en el Blog de H.S. Lahman.

En el directorio Web de Google

Desde hace unos pocos días, la página que dió orígen a este blog, aparece listada en el directorio Google, en el área de Ingeniería de Software. No sé si entusiasmarme, o lamentarme del escaso número de páginas listadas. Sé que hay mucho más, pero quizá no sea finalmente tanto como se requeriría para difundir la Ingeniería de Software en nuestro idioma. Sé, porque frecuentemente veo consultas sobre el tema, que muchos estudiantes, al menos en Latinoamérica, no dominan el inglés, y pierden el material fundamental. Los estudiantes debieran mejorar su inglés, y los autores debieran difundir más estudios en castellano.

Tuxpan en Ideas 2004, en Perú.

Confieso que no conocía (y sólo ahora lo estoy haciendo) a Tuxpan, a pesar de estar en Chile desde hace dos años, y estar en contacto desde hace varios más. Los descubrí a propósito de su aporte al congreso Ideas 2004. En este congreso describen su producto Z4-CASE, para la generación de código (Java) basado en modelos UML. El papel presentado, explica cómo construyeron la herramienta. Creo que voy a tener que conocerlos un poco más...
A propósito de Ideas 2004, no sólo éste es un documento de interés. No está de más leer la lista de papeles disponibles.

Análisis de productividad

Middleware Research ha desarrollado varios análisis de productividad y comparaciones de rendimiento de herramientas basadas en principios MDA. Estas debieran constituír una fuente de estudio para aquellos que desean mejorar la productividad y calidad en el desarrollo de sus aplicaciones. Una lectura de estos estudios debiera servir para comprender la ventaja ganada por enfoques orientados al diseño de un modelo, y las IDEs de corte "tradicional". Puede verse la batería de análisis en su página de Investigaciones.

Model Driven Architecture

Continuando con la nota anterior, una característica interesante de las universidades españolas, es la existencia de una buena difusión de la iniciativa MDA de la OMG, con varias universidades dedicándole al tema parte de sus clases, con documentación disponible de difusión y enseñanza, y varios profesores investigadores con trabajos dedicados a aspectos de su formalización, algunos enfocados en la aplicación de estos principios en desarrollo de aplicaciones para Web. Un caso son los investigadores Cristina Cachero y Jaime Gómez, en la Universidad de Alicante. Existe una lista de sus trabajos en sus páginas de la Universidad, para Cachero y Gómez.
Podría decirse que los académicos de Europa dedican más atención a MDA que los de América, y otros casos lo podrían sugerir. Una recorrida al número de congresos y Workshops mencionados en los trabajos de ambos investigadores desde el año 2000, pueden dar una idea.

La enseñanza de TI en España

En algún momento, alumnos de Ingeniería de Software que buscaban materiales de sus materias en castellano, me llevaron a tratar de localizar lo que hubiera disponible en nuestro idioma. Así fue que concluí que las universidades españolas, o están largamente más avanzadas en la enseñanza de TI, y en la investigación, o son mucho más colaborativas en la oferta de sus contenidos a la comunidad que muchas otras. Una buena parte de los comentarios que se insertarán aquí, tendrán que ver con esa oferta.
Por empezar por algún lado, sea el profesor Fernando Bellas Permuy, de la Universidad de La Coruña . Dos recursos que pone a disposición, son un tutorial de JDBC , y otro de J2EE, dentro de su clase de Integración de Sistemas.
EAI, CORBA, componentes, parecen ser fuertes en España y Europa, desde el punto de vista de Latinoamérica....

Inicio

Como continuación del material en desarrollo en la página de La Cuarta Generación, este blog servirá para acercar diariamente enlaces, comentarios, referencias rápidas a cualquier tema conexo.
Jorge Ubeda