SPLC 2011

Con programa preliminar a partir de este domingo, el lunes y martes próximo se desarrollará en Munich la 15ª conferencia de Lineas de Producto Software (SPL, Software Product Lines). Un concepto fundamental en la construcción de software, una fuente de ideas para quienes lo construyen, tanto sea en grandes unidades económicas, donde sus conceptos deberían ser  irremplazables, como para unidades menores, donde deberían motivar líneas de investigación y trabajo más racionales.
Aunque hemos conversado más de una vez sobre su significado, la descripción de uno de sus tutoriales explica razonablemente su meta:

Product Line Engineering is a common approach to address a business with a family of related software products. Instead of having separated development projects for each product in the family, products are built using a shared set of core assets, such as reference architectures and common infrastructure and domain-specific components. Key drivers for PLE are the potential cost savings due to shared core assets, as well as new business opportunities by, for instance, supporting tight integration and improved interworking among members of the product family. 

 Estoy persuadido de que SPL y MDD recorren caminos convergentes y retroalimentados. Uno de los tutoriales que se desarrollarán, toca esta característica: "Leveraging Model Driven Engineering in Software Product Lines", desarrollado por  Bruce Trask and Angel Roman:

Model Driven Engineering (MDE) is a promising recent innovation in the software industry that has proven to work synergistically with Software Product Line Architectures (SPLA). It can provide the tools necessary to fully harness the power of Software Product Lines. The major players in the software industry including commercial companies such as IBM, Microsoft, standards bodies including the Object Management Group and leading Universities such as the ISIS group at Vanderbilt University are embracing this MDE/SPLA combination fully. IBM is spearheading the Eclipse Foundation including its MDE tools like the Eclipse Modeling Framework (EMF) and the Graphical Modeling Framework. Microsoft has also launched their Software Factories and DSL Toolkit into the MDE space. Top software groups such as the ISIS group at Vanderbilt are using these MDE techniques in combination with SPLAs for very complex systems. The Object Management Group is working on standardizing the various facets of MDE. All of these groups are capitalizing on the perfect storm of critical innovations today that allow such an approach to finally be viable. To further emphasize the timeliness of this technology is the complexity ceiling the software industry find itself facing wherein the platform technologies have increased far in advance of the language tools necessary to deal with them. This complexity ceiling is evident in today’s Software Product Lines.

 Invito a seguir sus sesiones, a solicitar sus presentaciones, y a tomar contacto con sus participantes. Estas conferencias anuales acercan el mejor material sobre el tema.

Información y seguimiento en el sitio de la conferencia.

The Model Driven Software Network, cada día más interesante

El foro de The Model Driven... se ha convertido en otro enlace en el lado derecho de este blog. En estos días probablemente le estoy dedicando más interés que a ninguna otra actividad en Internet. La red a alcanzado una masa suficiente de adherentes como para que las discusiones sean más que atractivas. Conversaciones variadas, girando sobre MDA, Eclipse Modeling Framework, Software Product Lines, DSL, y otros temas asociados. Se han referido papeles valiosos sobre estos temas, y han participado referentes de primera línea, compartiendo y defendiendo su criterio con respeto por cada forista.
Recomiendo visitarlo, recorrerlo, y si lo desea, asociarse y participar.
Algunos asuntos en discusión:
Textual v Graphical models
Model-Driven Development is dying - discuss
Should DSL be just an UML extension ?
How MDA/MDD maps to Software Product Lines?
Could Java/Jee Architects-modelers use MDD and why is it important ?

Un proyecto interesante

Mark Dalgarno está comenzando un proyecto que podría ser muy interesante, tan pronto como sea acompañado por aquellos desarrolladores o teóricos interesados en el desarrollo guiado por modelos. Se trata de The Model Driven Software Network, que potencialmente puede convertirse en un foro abierto de discusión sobre el tema, con material y preocupaciones abiertos. Mark suma antecedentes de importancia para darle impulso: Es desde hace tiempo uno de los impulsores de Code Generation, así como de sus conferencias, y un especialista en Lineas de Producto Software. Una excelente combinación.

Code Generation 2008 finalizada

A finales de junio se efectuaron las sesiones de Code Generation 2008, anunciada aquí dos o tres veces. Centrada en las distintas variantes de desarrollo basado en modelos, ha continuado progresando en extender su uso, y en debatir el peso y alcance de las distintas vías de construcción de software. Las sesiones predominantemente ocuparon las dos tendencias corrientes en modelado: las distintas variantes del estándar de OMG, Model Driven Architecture, y las distintas ofertas de Domain Specific Languages; dos temas relacionados de particular interés, también tratados, son las relaciones con Lineas de Producto Software, y la aplicación a arquitecturas orientadas a servicios (SOA). Comentarios de algunos de sus participantes, en los blogs de Mark Dalgarno y Pedro Molina. Las presentaciones están disponibles en el sitio de la conferencia. El programa, mencionado en alguna nota anterior, da una idea del alcance de la conferencia.
Steve Cook y Bran Selic estuvieron a cargo de las keynotes. Y un excelente grupo de investigadores tomó a su cargo cada tema.

Leyendo a Matsumoto

Un aspecto relevante de la conferencia sobre Software Product Lines de 2007 fue el aporte de Yoshihiro Matsumoto. Decía la nota introductoria de SPLC 2007:

Yoshihiro Matsumoto is Adviser of ASTEM Research Institute of Kyoto. He started his career in Toshiba Corporation in 1954, where he took initiative in the applications of software to real time control systems and in building Toshiba Software Factory for those domains. After he spent 35 years in Toshiba, he switched to academic field and served a professor at Kyoto University, Osaka Institute of Technology, and Musashi Institute of Technology. He received Dr. Eng. degree from the University of Tokyo, and Fellow in 1982/Life Fellow in 2004 both from the IEEE.

Es notable el desconocimiento común sobre la actividad y logros de investigadores y profesionales japoneses en software, si nos atenemos a los medios usuales de difusión de noticias tecnológicas, aunque esto vale también en menor medida para la actividad de investigadores europeos. Lo más usual en las publicaciones de noticias tecnológicas es la atención hacia papeles de trabajo con orientación comercial, donde suele haber mucha hojarasca...Más profundamente, es probable que este desconocimiento provenga del distinto modelo de actividad en Estados Unidos y Europa, frente al japonés. En el caso de éstos últimos, el patrón de desarrollo es el de grandes empresas con investigadores empleados o academicos e institutos asociados. En el caso de Occidente, es mucho mayor el número de emprendimientos individuales o de pequeñas empresas, aunque también pese la acción de grandes conglomerados empresarios y estatales.
Como una confirmación de esta situación, Matsumoto ha logrado mención en el último tiempo gracias a su colaboración con Microsoft en la aplicación de ideas de Greenfield en Microsoft Japón (1 y 2). Pero su trabajo de investigación y de implementación sobre Factorías de Software y el sustrato que implica, tiene más de treinta años (cerca de cuarenta en realidad), siempre en Toshiba , y luego en la Universidad de Kyoto. En estos días, sigo su keynote en SPLC 2007, y su presentación sobre la Factoría de Software de Thosiba. Matsumoto trabajaba por una, y la denominaba como tal, tan temprano como 1977; y si me atengo a sus afirmaciones de 2007, basados en preparativos iniciados a finales de los sesenta. Volveremos sobre ésto.

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.

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.

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.

Factoría de Software no es solo outsourcing

Este comentario está motivado por las reflexiones de Mancarf, que conocí a propósito de un comentario suyo en otra entrada anterior, no del todo relacionada con lo que vamos a conversar. Tratando de conocer a quien efectuara un comentario a una entrada mía sobre factorías de software, entré a sus propias ideas sobre este tema. Manuel pone el acento, hasta donde leí (me falta completar la lectura), en la relación entre las factorías y el outsourcing. Más de una vez me pareció que era necesario aclarar este punto, que creo que está confuso. Aunque mejor es decir que se trata de una ambiguedad; Que el outsourcing se base en general en la idea de factorías, es una consecuencia. Estoy seguro que Manuel comparte este punto de vista también...

La idea básica que está detrás de la factoría, es la de construír el software de una manera análoga a como se construye un producto en la industria. Las empresas de manufacturas tiene una larga y madura experiencia en cómo producir, partiendo de patrones comunes, elaborando kits de componentes, reutilizando partes, estandarizándolas para que un proveedor pueda entregarlas, definiendo mediciones de tiempos, entre muchas técnicas; y ésto tanto en la fase de diseño y planificación de una nueva línea, como en la producción en masa del producto definido. Y lo mismo sucede con los proyectos de ingeniería que aplican procedimientos y componentes bien definidos, para generar un producto cuasi único, tal como un puente, un edificio, un barco.
Así, cuando los precursores hablaron de fábricas de software, pensaban en estas similitudes: en la mejora de cada aspecto de la construcción de software, para lograr procesos repetibles, medibles, usando componentes o patrones reutilizables, de tal forma que el proceso sea confiable, y económico. En su primera época, el interés estaba enfocado en el desarrollo propio, en grandes empresas o instituciones. Sólo ha evolucionado hacia una cercanía con el outsourcing en años más o menos recientes, en la medida que India, Irlanda, Brasil, Europa del Este y otros, pudieron convertir el diferencial de costo en un negocio conveniente.

¿Cómo veo a las factorías de software?: En efecto, como un requisito para ofrecer outsourcing; esto puede ser un buen negocio para algunos países, o dentro de un país, aprovechando nichos de mercado. Y aquí coincido con Manuel en cuanto a los límites que este esquema puede tener.
Pero el software como construcción industrial, como factoría, es una idea más general, y es en ese terreno en el que realmente me interesa. A condición de que un emprendimiento sea del porte adecuado, tanto por tamaño, como por su perdurabilidad, probablemente la generalidad de los proyectos podrían y deberían afrontarse utilizando prácticas y recursos típicos de una factoría.
Considero que en estos casos, las investigaciones sobre Lineas de Producto Software (SPL), así como las investigaciones sobre desarrollo basado en modelos (MDD), deberían ser una fuente de recursos a ser revisada y adoptada. Dados los auxiliares metodológicos, recursos y herramientas que hoy existen desarrollados, no es viable desconocerlos y omitirlos.

Nota: He mencionado la excelente y breve descripción que hace el ESI sobre MDD, que, siendo parte de su página de presentación, tiene el riesgo de estar disponible para leer ahora, pero no dentro de un año o dos. En previsión, un pequeño resúmen existe en estas páginas.
Sobre SPL, MDD, DSM y DSL, mucho se ha apuntado aquí. Solo es cuestión de buscar.

ESI va a Argentina

Enterado por medio de Enrique Avogadro, y publicado por CanalAr y el CFI: El ESI (European Software Institute) , filial del SEI soportada por el gobierno vasco con el apoyo de la Comunidad Europea, instalará una sede en La Plata, provincia de Buenos Aires, en el polo tecnológico de la ciudad. La noticia:

En marzo de 2008, el European Software Institute (ESI), uno de los principales laboratorios informáticos mundiales en materia de calidad de programas, abrirá en el polo tecnológico de La Plata el ESI Center Cono Sur. Desde allí, la fundación internacional sin fines de lucro se encargará de gestionar junto a universidades, empresas y organismos gubernamentales, la generación de proyectos de I+D+i, y la prestación de servicios ligados a la calidad en los procesos de desarrollo de software.

La ESI es uno de los principales partners en certificaciones CMMI, un equivalente a las normas ISO aplicadas a la programación informática. Formarán parte del centro el Grupo Tekne, la Facultad de Informática de la Universidad Nacional de La Plata (UNLP), y la Universidad Nacional de San Martín (UNSAM), entidades que impulsaron la creación de la unidad.

Canal AR se comunicó con Gerardo Renzetti, director del Grupo Tekne, recientemente nombrado por ESI como representante para el Cono Sur en el Consejo Directivo en Europa: "La apertura del centro es un trabajo que venimos gestionando hace 14 meses. Ya tenemos a muchas universidades y empresas adentro. Estamos esperando, por un lado, a que el Estado confirme a través de qué organismo se va a definir, y por el otro, aguardamos el ingreso de las cámaras interesadas".

Renzetti aseguró que ya iniciaron conversaciones con representantes del Ministerio de Ciencia, Tecnología e Innovación Productiva, así como también se reunieron con Miguel Calello, presidente de la CESSI, para presentar la propuesta e intercambiar opiniones.

En declaraciones al medio platense El Día, Armando De Giusti, decano de la facultad de Informática de la Plata, dijo: "La Argentina registra cierto atraso en materia de aplicación de las normas de control de calidad del software producido en el país. Los fabricantes tienen que recurrir a Europa para obtener la certificación de sus productos, lo que termina encareciendo enormemente los costos de las compañías". Con el establecimiento de un ESI Center en el país, los costos de certificación tenderían a reducirse.

"Abrir un centro de control de calidad en argentina se traduce en una enorme ventaja competitiva para las empresas de la región, ya que les permitirá fabricar y exportar software a todo el mundo achicando la inversión en certificación. Además, obtener el certificado de producción de software bajo la norma CMM en el país representará sin dudas un incentivo para el crecimiento las compañías del cono sur", finalizó el decano.

La importancia del trabajo del ESI es muy grande, no sólo en el área de calidad, al que se apunta en primera instancia, sino en cómo se llega a ella, especialmente desde el punto de vista de las fábricas de software, algo particularmente perseguido en casos como Argentina hoy. Sus investigaciones son de primera línea en otras dos áreas aquí comentadas: líneas de producto software, y desarrollo guiado por modelos. Volveremos sobre esto.
Por otra parte, se repite aquí un patrón muy positivo para Argentina: la confluencia de instituciones académicas y de investigación, universidades, y empresas locales. Esta es la vía de crecimiento sobre la que los países emergentes pueden tener salida.

Software Factories, una visión más objetiva que podríamos poner en Wikipedia

Sin buscar mucho, éste artículo sobre factorías de software, podría reemplazar con todos los honores al actual existente en Wikipedia. Me gustaría saber si el ajuste pudiera ser cuestionado o borrado (en la historia del artículo parece haber algunos forcejeos). Se ve aquí lo importante que Software Factories no toma en cuenta en Wikipedia en inglés:

A lo largo de la historia de la Ingeniería del Software ha aparecido repetidamente el concepto de fábrica con diferentes matices que se han ido adoptando de acuerdo a la propia evolución de la tecnología y los procesos software. En la actualidad el término ha vuelto a tomar relevancia en el sector de la industria del software, debido a las especiales condiciones socio económicas, tecnológicas y de madurez de la ingeniería del software; no obstante no debemos olvidar que, como se muestra en la Tabla 1, el concepto de fábrica software goza de una gran madurez y antigüedad.

1968	Aparece por primera vez el término “fábrica de software”
1969	Primera fábrica de software: Hitachi Software Works
1975	Fábrica software de la Systems Development Corporation
1976	Fábrica software de NEC
1977	Fábrica software de Toshiba
1979	Fábrica software de Fujitsu
1985	Fábrica software de Hitachi y de NTT
1987	Fábrica software de Mitsubishi

Tabla1. Primeros hitos en la historia de las fábricas de software

En este artículo haremos un recorrido por las principales etapas y conceptos que han ido marcando el término fábrica software, así como las principales empresas en implementar dichas estrategias, de lo cual puede obtenerse una importante visión y comprensión a la hora de constituir y evolucionar tanto fábricas como departamentos dedesarrollo en la época actual.

1. Años 70 y 80: origen de las fábricas de software

El término se acuñó en el año 1968, a la vez que otros tan famosos como el término reutilización (propuesto por McIlroy de AT&T en la famosa conferencia de ese año de la OTAN sobre Ingeniería de Software). En efecto, la primera vez que se cita “fábrica de software” es en un position paper presentado en el congreso IFIP (International Federation of Information Processing) del año 1968 por Bemer, quien afirmaba que los gestores de software no disponían de entornos adecuados: Bemer señalaba también que es imposible que los programadores hagan buen software simplemente bajo supervisión humana, mientras que “una fábrica, sin embargo, tiene más que supervisión humana. Mide y controla la productividad y calidad. Se mantienen registros financieros para coste y planificación”.

Fue Hitachi la primera empresa que utilizó el término “fábrica” en 1969 cuando fundó Hitachi Software Works.

Por otra parte en EEUU, la Systems Development Corporation (que formaba parte de Rand Corporation) estableció la segunda fábrica de software entre 1975-1976, llegando a registrar esta denominación.

Durante los años setenta y ochenta en Japón se siguieron instalando fábricas de software: NEC en 1976, Toshiba en 1977, Fujitsu en 1979 y 1983, Hitachi en 1985, NTT en 1985 y Mitsubishi en 1987.

2. Años 90: CASE, reutilización y procesos

Durante los noventa surgen diferentes aproximaciones a las fábricas de software

2.1. Fábricas basadas en Entornos de Desarrollo Integrados

A finales de los ochenta y principios de los noventa se implantó la primera generación de herramientas CASE (M Piattini & Daryanani, 1995), y los denominados Entornos Integrados de Desarrollo de Software (conocidos por sus siglas inglesas ISDE, Integrated Software Development Environments), y los Entornos de Ingeniería del Software orientados al Proceso (PSEE, Process-centered Software Engineering Environment)

En este caso, el contexto lo constituyen grandes empresas europeas, fabricantes de ordenadores, desarrolladoras de software y universidades.

El objetivo que se persigue es producir una arquitectura y un marco de trabajo para los ISDE. La estrategia utilizada es la de adaptar el entorno de soporte, creando una instancia de la fábrica en la organización de desarrollo. El modelado de procesos se pretenden estandarizar y soportar mediante herramientas automáticas.

2.2. Fábrica de componentes basadas en experiencia

Esta es la experiencia desarrollada en el SEL (Software Engineering Laboratory) de la NASA por Basili (V. R.Basili, 1989, , 1993; V. R. Basili, Caldiera, & Cantone, 1992), con el fin de experimentar con nuevas tecnologías en entornos de producción. Nace con el triple objetivo de mejorar la eficacia del proceso, reducir la cantidad de re-proceso y reutilizar los productos de ciclo de vida.

Ejemplos reales de factorías de experiencia son el SEL (Software Engineering Laboratory) del Goddard Space Flight Center de la NASA, el SEC (Software Experience Center) de DaimlerChrysler, o el EPIK (Engineering Process Improvementand Knowledge Sharing) de ICL.

2.3. Fábrica de software basada en la madurez de procesos

El contexto de esta aproximación lo constituye el modelo CMM, patrocinado por el Departamento de Defensa de EEUU con el fin de evaluar a los subcontratistas. El objetivo es crear un marco para la mejora de procesos software que permitan conseguir un proceso predecible, fiable y auto-mejorable que produzca software de alta calidad.

2.4. Fábrica de software basada en la reutilización

(Griss, 1993) señala que una reutilización efectiva requería más que tecnología para bibliotecas y código, y que utilizar sólo la metáfora de la biblioteca limitaba los resultados de la reutilización, la solución pasaba por familias de soluciones relacionadas. Este experto propone combinar la noción de fábrica de software de los años anteriores con la idea de los sistemas de fabricación flexible para dar lugar a la “fábrica de software flexible” en las que se construyen las partes para trabajar juntas y además se optimiza la producción de componentes y el ensamblado de productos con el fin de decrementar el reproceso de ingeniería. Enfatiza en prestar atención a los estándares de construcción, certificación y pruebas, haciendo trabajar de manera conjunta las guías de diseño y los procesos cuidadosamente afinados.

2.5. Fábricas de renovación de software

Al acercarse el final de la década de los noventa se agudizaron aún más los clásicos problemas del mantenimiento de software (Polo, Piattini, & Ruiz, 2003), sobre todo por las conversiones de los programas existentes debido al “problema” del año 2000 y la introducción del euro. Surgen entonces otras “fábricas” denominadas “fábricas de renovación de software”, en las que entran los programas en una especie de línea de ensamblado, pasando por una secuencia de herramientas de transformación (Brunekreef (Brunekreef & Diertens, 2002).

En (van den Brand, Sellink, & Verhoef, 2000) se presenta incluso la generación de componentes para la fábrica de renovación de software: transformadores de código, re-generadores, re-estructuradores, migradores, etc.

2.6. Fábricas enfocadas a otras técnicas de gestión de la calidad

(Swanson, Kent, McComb, & Dave, 1991) destacan la aplicación de TQM (Gestión de Calidad Total) y reutilización, así como generadores de código y herramientas CASE, buscando la flexibilidad de las fábricas de software.

También en los noventa en Japón se trasladaron métodos de la fabricación de automóviles a las fábricas de software, como el proceso de desarrollo concurrente (Aoyama, 1996) que integra conceptos convencionales de proceso-producción con los sistemas de producción “esbeltos” (lean) y otras técnicas de gestión basadas en el tiempo. Estas técnicas lean persiguen la eliminación del desperdicio dentro de una organización, combinando la planificación y los sistemas de producción.

3. Años 2000: COMPONENTES, MODELOS y LÍNEAS DE PRODUCTOS

En los años 2000 se siguió perfeccionando las técnicas de las décadas anteriores, afianzándose la ingeniería basada en modelos, el desarrollo basado en componentes, las líneas de producto y los modelos de madurez de procesos.

Así en (Li, Li, & Li, 2001) se puede encontrar una propuesta más reciente de modelo de fábrica de software para organizaciones chinas, en las que (como se puede ver en la figura), se considera que una fábrica de software se expresa como (Correa, Werner & Zaverucha, 2000):

Fábrica Software = (Especificaciones de Gestión, Líneas de producto) x (Procesos, Personas, Técnicas)

Ya que se combina, desde el punto de vista directivo, la gestión de la calidad orientada a procesos, con el punto de vista técnico, de las líneas de producto basadas en tecnologías de componentes. En esta propuesta se integran ISO9000, CMM y PSP/TSP (véase (M. Piattini, Caballero, & García, 2006)).

(Greenfield, Short, Cook, Kent, & Crupi, 2004) de Microsoft vuelven a poner de moda a nivel internacional el concepto de fábrica de software como enfoque de desarrollo de aplicaciones en el que confluyen el desarrollo basado en componentes, el desarrollo dirigido por modelos y las líneas de producto software. Lenguajes Específicos de Dominio (DSL), patrones, armazones (frameworks), y herramientas (incluido código y metadatos) que permiten implementar el esquema para construir un miembro de la familia de productos.

Destaco en verde, al final, la referencia del artículo al concepto de Software Factories en la versión Greenfield/Microsoft. Como corresponde, ocupa la última parte del artículo, porque fueron los últimos en mencionarlo. Si se toma el trabajo de revisar el artículo original, se verá que la bibliografía es bastante más amplia que UN solo libro.
KybeleConsulting, la empresa que sostiene el papel, es originaria de la universidad Rey Juan Carlos, y sus autores, Javier Garzás y Mario Piattini, son conocidos estudiosos del tema.

Code Generation 2008

Me acerca Pedro Molina la recordatoria de que Code Generation 2008 abre la llamada a presentación de ponencias a la conferencia de tres días en Cambridge, UK. Esta reunión, continuidad de la muy sustanciosa de 2007, tiene la virtud de reunir a las distintas vertientes interesadas en la generación de aplicaciones por medios más abstractos y rigurosos que el heroísmo de los programadores. Desde su inicio, Code Generation tuvo un criterio abierto para reunir y clasificar a la diversidad de herramientas dedicadas a la generación de código. Sigue siendo hoy el mejor lugar para acudir en busca de fundamento teórico, estado de situación de las investigaciones, estado del mercado y evaluación de productos. La reunión de 2008 promete ser tan interesante como la de 2007, con la discusión de las líneas de acción que se abren a partir de los conceptos de arquitecturas dirigidas por modelo (MDA, Model Driven Architecture), lenguajes específicos de dominio (DSL, Domain Specific Languages), programación generativa, y líneas de producto software (SPL, Software Product Lines), siguiendo lo que están ocupando los intereses actuales, explicados en la llamada:

Call for Session Proposals
Submission Deadline - Friday January 18th 2008

We are currently seeking high-quality session proposals covering topics in model-driven software development (including Software Factories, Model-Driven Architecture (MDA), Domain-Specific Languages (DSLs), Generative Programming, Software Product Lines and related areas). Sessions could cover topics such as:

• Tool and technology adoption
• Code Generation and Model Transformation tools and approaches
• Defining and implementing modelling languages
• Domain Analysis and Domain Engineering
• Language evolution and modularization
• Meta Modelling
• Runtime virtual machines versus direct code generation
• Flexibility in code generation
• Approaches to code generation
• Approaches to combined development (partial code generation with partial handwritten code)

Real-world case studies based on any aspect of these and related approaches are particularly encouraged although more theoretical sessions are also welcome.

Una reunión que debe ser agendada, y una lista de participantes que debe ser seguida. Trataré de sistematizar los papeles relacionados con la reunión anterior en una próxima nota.
Es importante destacar al otro organizador del encuentro, Software Acumen, la empresa que ocupa a Mark Dalgarno, quien cumple una excelente labor explicando el valor de SPL.

Factorías de Software ¿Horizontales y Verticales? dos o tres apuntes más

No más sobre el artículo de Jezz, salvo dos o tres apuntes finales:

• Las líneas de Producto no pueden ignorar las variaciones de plataforma. La afirmación de Jezz acerca de este tema, constituye una importante limitación de SF, si así es (y así debe ser muy probablemente):

  Now, I don’t want to set the expectation that this mapping can or should be platform independent (such that MDA promotes) since, platform independence is a much larger challenge than technology or implementation independence. And one that practical software factories in general avoid. Platform independence requires platform independent architectures, and effective specific software factories will define successful platform specific architectures. Remember, software factories are very solution domain specific. Platform independent models are likely to be too abstract to become practically useful for product line development.

• La idea de concentrarse en "factorías horizontales" es una cuestión de mercado, legítima, pero que no representa todos las formas de entender los "core assets".
  
• La cuestión planteada sobre propiedad intelectual (tres capas de participantes) conduce a un tema que es importante, ineludible, y difícil de resolver con estas restricciones de plataforma y de marco base: la integración de "legacy assets".

En adelante, volvermos sobre estos temas, pero ya no alrededor del artículo de Jezz.

Factorías de Software ¿Horizontales y Verticales? III

Volviendo una vez más sobre la nota de Jezz Santos, quisiera tomar uno de los puntos críticos observados por él sobre el modelo Software Factories: la variabilidad, que en definitiva es el punto fundamental, en su nota, que permite construír una "factoría vertical", basada en una "horizontal". Dice Jezz sobre el tema:

In order for a horizontal software factory itself to be reusable in multiple vertical domains (which is where it is ultimately destined for) there has to be some level of customization that allows it to be specialized towards any particular vertical domain. If we don’t allow this, then we simply can’t adapt a factory to create specific enough product lines, which means we are limited to the productivity we can achieve with it as a reusable asset. That’s not to say we can’t. We can do the product lines, but the overhead of doing so is much larger than it needs to be, because some things in the particular domain will either be common, or specific across the whole product line for that domain. Remember, the power of factories is in how specific they can be.

Y qué observa sobre la variabilidad disponible (en su criterio):

Verticalizing a factory today can seem impossible given the tool-sets we have at our disposal.
For most customizations of today’s factories you need to ‘crack open’ the factory and mess about with the source code internals of the recipes, DSL’s and the like. This is not a guided experience, and requires very deep technical knowledge of the factory, and deep technical VS extensibility skills. Not an easy ramp-up for those new to factories.
Extending a factory today is a function of what external interfaces the factory may expose today (if any at all!). For example the patterns & practices Web Service Software Factory does a good job of providing a number of extensibility points and interfaces, both via a programming model and configuration. But anything beyond what it supports at the programming API level, and you'll have to crack it wide open, effectively voiding the warranty and support policy of the factory. It’s wild-west country from there onwards.

Más adelante, de nuevo sobre sus posibilidades actuales:

(...) we would need a way of formally declaring the points of variability of the product architecture of a base (horizontal) factory. These declared points of variability could then be provided with default values/views/assets by the base factory. Or the factory may declare them ‘abstract’ requiring vertical factories to be built to subclass them and extend these points through customization interfaces.
We would then need a ‘customization authoring tool’ that we use to load the base factory into, and extend these pre-defined customization points with standard tools, that creates for us a set of customized assets output into a vertical factory in some form.
In this way we would not have to crack open a software factory any alter recipes or DSL’s just to predefine say, the data contracts of a web service product. Instead we can provide a simple subclass that hooks into a predefined point of variability customization interface and either provide fixed factory configuration, or extend the architecture of the product.
However, I feel this customization capability may be too far out for us right now. Instead we need to look at practical means today to achieve the same net effect (albeit a less guided experience).

Jezz insiste sobre este estado del problema en varios puntos, mientras examina las vías de "verticalizar", pero este es el planteo, sin entrar en más detalles...Sus palabras dan una sensación de inmadurez del esquema en su totalidad, con soluciones aún no retempladas para aspectos básicos de lo que debe conseguir (un poco distinto de las tajantes afirmaciones que en algunos papeles se observan).
Para tomar un poco de distancia de esta vista del problema, es conveniente releer cómo define variabilidad el SEI:

All architectures are abstractions that admit a plurality of instances; a great source of their conceptual value is, after all, the fact that they allow us to concentrate on design while admitting a number of implementations. But a product line architecture goes beyond this simple dichotomy between design and code–it is concerned with identifying and providing mechanisms to achieve a set of explicitly allowed variations (because when exercised, these variations become products). Choosing appropriate variation mechanisms may be among the product line architect's most important tasks. The variation mechanisms chosen must support

• the variations reflected in the products. The product constraints (see Core Asset Development) and the result of a scoping exercise (see the "Scoping" practice area) provides information about envisioned variations in the products of the product line–variations that will need to be supported by the architecture. These variations often manifest as different quality attributes. For example, a product line may include both a high-performance product with enhanced security features and a low-end version of the same product.

• the production strategy and production constraints (as described in Core Asset Development). The variation mechanisms provided by the architecture should be chosen carefully, so they support the way the organization plans to build products.

• efficient integration. Integration may assume a greater role for software product lines than for one-off systems simply because of the number of times it's performed. A product line with a large number of products and upgrades requires a smooth and easy process for each product. Therefore, it pays to select variation mechanisms that allow for reliable and efficient integration when new products are turned out. This need for reliability and efficiency means some degree of automation. For example, if the variation mechanism chosen for the architecture is component selection and deselection, you will want an integration tool that carries out your wishes by selecting the right components and feeding them to the compiler or code generator. If the variation mechanism is parameterization or conditional compilation, you will want an integration tool that checks the parameter values for consistency and compatibility before it feeds those values to the compilation step. Hence, the variation mechanism chosen for the architecture will go hand in hand with the integration approach (see the "Software System Integration" practice area).

Support for variation can take many forms (and be exercised many times [Clements 2002c, p. 64]). Mechanisms to achieve variation in the architecture are discussed under "Example Practices."

Products in a software product line exist simultaneously and may vary from each other in terms of their behavior, quality attributes, platform, network, physical configuration, middleware, and scale factors and in a multitude of other ways. Each product may well have its own architecture, which is an instance of the product line architecture achieved by exercising the variation mechanisms. Hence, unlike an organization engaged in single-system development, a product line organization will have to manage many related architectures simultaneously.

There must be documentation for the product line architecture as it resides in the core asset base and for each product's architecture (to the extent that it varies from the product line architecture). For the product line architecture, the views need to show the variations that are possible and must describe the variation mechanisms chosen with the rationale for the variation. Furthermore, a description–the attached process–is required that explains how to exercise the mechanisms to create a specific product. The views of the product architectures, on the other hand, have to show how those variation mechanisms have been used to create this product's architecture. As with all core assets, the attached process becomes the part of the production plan that deals with the architecture.

Respecto a los mecanismos de variación, transcribimos su definición:

Variation mechanisms (1): Jacobson, Griss, and Jonsson discuss the mechanisms for supporting variability in components (see the following table) [Jacobson 1997a]. Each mechanism provides a different type of variability. The variation of functionality happens at different times depending on the type. Some of these variation types are included in the specification implicitly. For example, when a parameter is used, the specification includes the specific type of component mentioned in the contract or any component that is a specialization of that component. In the template instantiation example below, the parameter to the template is Container, which permits variation implicitly via the Inheritance pattern. The Container parameter can be replaced by any of its subclasses, such as Set or Bag.

One aspect of variability that is important in a product line effort is whether the variants must be identified at the time of product line architecture definition or can be discovered during the individual product's architectural phase. Inheritance allows for a variant to be created without the existing component having knowledge of the new variant. Likewise, template instantiation allows for the discovery of new parameter values after the template is designed; however, the new parameter must satisfy the assumptions of the template, which may not be stated explicitly in the interface of the formal parameter. In most cases, configuration further constrains the variation to a fixed set of attributes and a fixed set of values for each attribute.

Types of Variation [Jacobson 1997a]
Mechanism	Time of Specialization	Type of Variability
Inheritance	At class definition time	Specialization is done by modifying or adding to existing definitions. Example: LongDistanceCall inherits from PhoneCall.
Extension	At requirements time	One use of a system can be defined by adding to the definition of another use. Example: WithdrawalTransaction extends BasicTransaction.
Uses	At requirements time	One use of a system can be defined by including the functionality of another use. Example: WithdrawalTransaction uses the Authentication use.
Configuration	Previous to runtime	A separate resource, such as file, is used to specialize the component. Example: JavaBeans properties file
Parameters	At component implementation time	A functional definition is written in terms of unbound elements that are supplied when actual use is made of the definition. Example: calculatePriority(Rule)
Template instantiation	At component implementation time	A type specification is written in terms of unbound elements that are supplied when actual use is made of the specification. Example: ExceptionHandler
Generation	Before or during runtime	A tool that produces definitions from user input. Example: Configuration wizard

Variation mechanisms (2): Anastasopoulos and Gacek expound on a somewhat different set of variation options that includes [Anastasopoulos 2000a]

• aggregation/delegation: an object-oriented technique in which the functionality of an object is extended by delegating the work it cannot normally perform to an object that can. The delegating object must have a repertoire of candidates (and their methods) and assumes a role resembling that of a service broker.
• inheritance: which assigns base functionality to a superclass and extended or specialized functionality to a subclass. Complex forms include dynamic and multiple inheritance, in addition to the more standard varieties.
• parameterization: as described above
• overloading: which means reusing a named functionality to operate on different data types. Overloading promotes code reuse but at the cost of understandability and code complexity.
• properties in the Delphi language: which are attributes of an object. Variability is achieved by modifying the attribute values or the actual set of attributes.
• dynamic class loading in Java: where classes are loaded into memory when needed. A product can query its context and that of its user to decide which classes to load at runtime.
• static libraries: which contain external functions that are linked to after compilation time. By changing the libraries, you can change the implementations of functions that have known names and signatures.
• dynamic link libraries: which give the flexibility of static libraries but defer the decision until runtime based on context and execution conditions
• conditional compilation: which puts multiple implementations of a module in the same file. One is chosen at compile time according to the appropriate preprocessor directives.
• frame technology: Frames are source files equipped with preprocessor-like directives that allow parent frames to copy and adapt child frames and form hierarchies. On top of each hierarchical assembly of frames lies a corresponding specification frame that collects code from the lower frames and provides the resulting ready-to-compile module.
• the ability of a program to manipulate data that represents information about itself or its execution environment or state. Reflective programs can adjust their behavior based on their context.
• aspect-oriented programming: which is described in the "Architecture Definition" practice area
• design patterns: which are extensible, object-oriented solution templates catalogued in various handbooks (for example, the work of Gamma and colleagues [Gamma 1995a]). We mentioned the Adapter Design pattern specifically as a variation mechanism earlier in this practice area.

La variabilidad es un aspecto central del desarrollo de Líneas de Producto, que es extensamente tratada en SPL, con definiciones precisas sobre cómo sostenerla. Más exactas que las que Jezz parece manejar. No lo cuestiono: SF seguirá madurando, construirá DSLs, y las inconsistencias tomarán un rumbo estable. Lo que no cuadra, es alguna publicidad tan terminante con otras formas de encarar el problema.

Factorías de Software ¿Horizontales y Verticales? II

Siguiendo la nota anterior...
El planteo de Factorías de Software sostenido por Microsoft contiene un componente que produce confusión, al denominar su iniciativa con las mismas palabras usadas durante mucho tiempo por distintos emprendimientos de desarrollo con criterios de rigor industrial. "Software Factory" implica un concepto de mayor alcance que el dado por el conjunto de recomendaciones y productos asociados a la idea por Microsoft. Pero existe un segundo componente en la definición que también resulta controversial: el desarrollo como líneas de producto (Software Product Lines, SPL, en los conceptos del SEI (Software Engineering Institute). En este caso, el concepto es central, y explícitamente indicado como base de las Software Factories por Jack Greenfield. Sin embargo, existen diferencias en el desarrollo práctico de las factorías, si nos atenemos a Jezz, y a lo que se puede ver en el sitio de MS. Al comienzo de su nota, Jezz declara una vez más la relación existente entre SF y SPL:

In order for a horizontal software factory itself to be reusable in multiple vertical domains (which is where it is ultimately destined for) there has to be some level of customization that allows it to be specialized towards any particular vertical domain. If we don’t allow this, then we simply can’t adapt a factory to create specific enough product lines, which means we are limited to the productivity we can achieve with it as a reusable asset. That’s not to say we can’t. We can do the product lines, but the overhead of doing so is much larger than it needs to be, because some things in the particular domain will either be common, or specific across the whole product line for that domain. Remember, the power of factories is in how specific they can be.

La vinculación es central en el libro de Greenfield, fundamento de esta iniciativa:

Recognizing and planning around these assumptions leads to defining families of similar solutions, and separating their common features, which make them similar, from their variable features, which make one member of the family different from the next. The common features are used to develop a custom process for building the members of the family, and of a set of reusable assets supporting the process. The variable features are used to drive parameterization, configuration, assembly and other techniques for accommodating the differences between the family members.
This is the thinking underlying the development of the components that are truly reusable, such as RDBMSs and GUI frameworks, although it may not have been recognized at the time by all of the people involved in building those components.
Work at the Software Engineering Institute (SEI) formalized this thinking in the concept of Software Product Lines. Software Product Line practices have been well established through many books, case studies and experience reports, and are widely accepted in the software engineering community.
Software Factories is a methodology for using domain specific languages and other technologies to automate Software Product Lines. They were developed by leveraging the work of David Garlan, as described in the book, in consultation with the authors of Software Product Lines at the SEI, and with other experts in related disciplines, such as pattern languages, generative programming and feature based development.[Comentado en su blog]

Por lo tanto, es razonable ver cuánto ayuda SF en ese terreno, así como deslindar el valor de la idea de Líneas de Producto Software más allá de la encarnación en el proyecto de Microsoft. Y vale lo mismo para las Factorías de Software. Es decir, es importante discernir que ambos conceptos no son necesariamente lo que Microsoft postule, y que pueden diverger. Que el concepto es del mayor interés, y que no tiene por qué acompañar el resultado que le dé a Microsoft, así como también las ideas de la empresa pueden contribuír al perfeccionamiento de la iniciativa. Como lo puede hacer MDA (Model Driven Architecture), aunque Jezz no desee entrar en esa discusión.
Más aún, es absolutamente legítimo suponer que el libro de Greenfield, que obra como sustento de SF (uno referencia al otro, mutuamente), sea aplicable con otro conjunto de herramientas que no sea Visual Studio Team System (VSTS), ni sus extensiones. Por esto mismo el concepto es interesante, conveniente de analizar, poniendo entre paréntesis los recursos concretos con que Jezz construye. ¿Es generalizable el tipo de problemas con que Jezz se encuentra? ¿O tienen que ver con su implementación de la idea de SPL?.
Sobre esto trataremos de escribir, con los limitados recursos de tiempo que disponemos. Si fuera posible, sería bueno presentar también otros puntos de vista que hoy existen sobre cómo resolver SPL.

Factorías de Software ¿Horizontales y Verticales?

Jezz Santos abre en su blog una dimensión de las factorías de software, versión Microsoft, que posiblemente sea una de las mejores maneras de cotejar las diferencias con el estándar MDA y otras variantes de desarrollo orientado por modelos. Desgraciadamente no tengo casi tiempo, lo que limita mis posibilidades de desmenuzar en detalle sus comentarios, pero trataré de releerlo, analizarlo, y luego apuntar algunas diferencias.
Para comenzar, se presenta el problema, en palabras de Jezz:

The title of this post would not mean anything if you didn't know what 'horizontal' and 'vertical' software factories were. In that case then for simplification, ‘Factory Verticalization’ merely means ‘Factory Specialization’. Ironically enough though, most of the factories being build today are ‘Horizontal Factories’, so specialization in these cases means ‘Factory Verticalization’.
In almost all my interactions with customers about factories I am constantly reminded that ‘verticalization’ is the one key principal aspects of software factories today which is largely going unaddressed (and poorly understood). I am convinced that there is a clear and immediate requirement that we need to deal with more effectively in the present. I go so far to say that without catering for Verticalization of any factory, would seriously limit the adoption of factories in the future. It is such an important aspect to provide for if we are to realize the full vision of product lines and asset reuse.

Inmediatamente, Jezz carga un poco más la definición:

Before I get into this lengthy discussion about different aspects of verticalization, I think I need to explain what we mean by 'Horizontal' and 'Vertical' software factories in order to set the right context for the discussion.
In software factories we use these terms (vertical and horizontal) in the respect as they use them to describe markets. In software development these terms are generally well understood to differentiate broad skill-sets (or more general capabilities) typically focused at particular technologies and platforms, from the skill-sets/capabilities applied to specific industry domains (e.g. finance, manufacturing, retail, etc). The intersection of these axes in software engineering, in theory at least, applies the expert technical solution people to build instances of solutions for particular vertical domains, under the guidance and knowledge provided by the industry domain experts. The assumption is that the horizontal assets (people and artifacts) can be reused (with some specialization) across many vertical domains - it’s really a synergy of the two axes.

Existen en este planteo dos aspectos para analizar:

1. ¿Software Factories representa un "mercado horizontal" para Microsoft?
2. ¿Qué distancia existe entre este concepto de lineas de producto, y el de Software Product Lines del SEI (para mencionar el centro que probablemente más trabaja sobre este punto)

Sobre el primer punto, así parecería demostrarlo el repositorio visible en Codeplex, (Microsoft patterns and practices, Software Factories), con cuatro casos desarrollados. Asimismo, las referencias de Jezz en su nota:

From a marketing perspective, if you can call it that (which is really isn’t), one of the primary reasons Microsoft currently releases only horizontal factories is that: at present, software factories are a new concept to the industry, and Microsoft is leading the charge here. It makes perfect sense that the first factories from Microsoft must have some large significance and impact and benefit to the existing marketplace. So they chose horizontal factories to tackle first

Sobre el segundo, las definiciones del SEI dicen algo distinto:

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.
(...) How is production made more economical? Each product is formed by taking applicable components from the base of common assets, tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance, adding any new components that may be necessary, and assembling the collection according to the rules of a common, product-line-wide architecture. Building a new product (system) becomes more a matter of assembly or generation than one of creation; the predominant activity is integration rather than programming. For each software product line, there is a predefined guide or plan that specifies the exact product-building approach.
(...) The common set of assets and the plan for how they are used to build products don't just materialize without planning, and they certainly don't come free. They require organizational foresight, investment, planning, and direction. They require strategic thinking that looks beyond a single product. The disciplined use of the common assets to build products doesn't just happen either. Management must direct, track, and enforce the use of the assets. Software product lines are as much about business practices as they are about technical practices.

A partir de aquí, conversaremos. Comenzando esta semana...

Nota: Esto es muy curioso...Desapareció del sitio de Microsoft el ítem sobre SF en Arquitecturas, y ya no se encuentra el enlace a la explicación difundida durante meses sobre el tema (http://msdn.microsoft.com/architecture/overview/softwarefactories/) . Tendré que buscar más (¿?)

Software Product Lines en CM Crossroads

Durante algún tiempo se desarrolló una conversación en CM Crossroads sobre Líneas de Producto en Software (SPL, Software Product Lines). Está congelada en este momento, pero vale la pena destacarla: SPL es en general el espacio de discusión más interesante actualmente, desde el punto de vista del software como industria, y quizá desde el punto de vista de la ingeniería de software. En general, SPL requiere poner en práctica conceptos fundamentales de la disciplina, o no habrá resultados. En el caso de esta discusión, SPL es discutido desde el punto de vista del manejo de los cambios.
SPL implica trabajar con patrones, componentes, aplicar normas de manejo de proyecto y de trabajo en equipo, definir claramente líneas de desarrollo, integrar herramientas, automatizar la generación de código, y mucho más. Tengo una línea de búsqueda abierta en del.icio.us sobre SPL, pero curiosamente es muy poco el material que recolecto. Probablemente se trate de que nadie le pone una etiqueta a estos conceptos; aunque justamente SPL o SF (Factoría de Software, Software Factory) definen en su título un conjunto de actividades no sólo aplicables a una organización que "fabrique software", sino que, con ciertas limitaciones, son aplicables a cualquier organización grande que construya su propio software. (O que delegue parte de su construcción, como en algún momento veremos).
Volviendo a CM Crossroads, son particularmente útiles las intervenciones de Mark Dalgarno, de quien hay más para comentar, Thiago Henrique Burgos de Oliveira, antes que nada para volver a destacar la importante experiencia brasilera en Factorías de Software, Brad Appleton, y Frank Guerino.
Appleton destaca un artículo de John D. McGregor en JOT, extendiendo la disciplina de Administración de Cambios (CM) a SPL.

Volveremos sobre esta discusión...

Construcción de software, Fábricas de Software

Mientras continúo pasando a un lugar más accesible mis notas, van apareciendo materiales de interés olvidados. La cita recordada aquí refiere a un artículo en The Server Side de Griffin Caprio, que, en el marco de la "popularización" de las herramientas de Microsoft orientadas a software factories, ofrece una visión más imparcial y generalizadora del problema que la que otras declaran. Lo más interesante del artículo:

Moving from Craftsmanship to Industrialization
All too often, highly skilled application developers and architects have to use their time for low-level, implementation level tasks. Usually, junior developers are not able to complete such tasks because of lack of appropriate domain knowledge, requiring the senior developer to mentor the junior developer. This fosters not only knowledge transfer, but also an introduction to the complexities of the current development environment.
Since developers are always involved at some stage of development, very little time is spent in making development more efficient, especially low-level implementation details. This method of development resembles early goods based industries, where single workers create custom solutions, tailored to each individual requirement. Think early tailors or shoe cobblers.
This craftsmanship approach to software development does not scale very well. The lack of quality senior developers creates a mentoring environment, where specialized knowledge must be transferred, similar to an apprenticeship. Since there is such a hands-on approach required, each part of the project need to be created, most of the time, by hand. This often leads to higher quality, but also leads to performance and efficient issues.
Migrating from a craftsmanship-based industry to a more industrial-based industry has been the path of progression for many more mature industries. If this is the end result for so many other industries, why is software development still based on small groups of highly specialized craftsmen?
Most people within the IT industry will agree that a form of standardization and modularization is the key to enabling the kind of reuse required for efficient industrialization of software development. What they don’t agree on is the means to which this standardization and modularization is achieved. Software Factories aim to address this effort by prescribing a process by which software can be modularized into reusable assets.

Caprio se refiere a los tres componentes de las Factorías de Software (en el sentido SF de Greenfield): Modelos y Patrones, Lenguajes específicos de Dominio (DSL), y Lineas de Productos (SPL). Siendo un artículo temprano (marzo 2005), aún no insistía en lo que luego se convirtiera en una oposición de tipo comercial entre la iniciativa de la OMG (Model Driven Development, MDA) y Microsoft (Software Factories, SF, Domain Specific Languages, DSL):
Sobre el papel de los modelos, Caprio dice:

“using models to capture high level information, usually expressed informally, and to automate its implementation, either by compiling models to produce executables, or by using them to facilitate the manual development of executables”
The importance of models comes from their ability to keep a consistent representation of concepts within a project. For example, while it’s easy to draw and manipulate a person object in a model, it’s much more difficult to manipulate the same person object at a lower level, because the person object could be represented by class files, tables, and columns in a database.

Dejo de lado las palabras sobre DSLs, que para 2005 eran sólo una expresión de deseos. En cuanto a las líneas de producto de software, indica:

Software Product Lines are entire subsets of components that can be configured, assembled, and packaged to provide a fairly complete product. The resulting product should only require customization from a developer for the highly specialized aspects of the project.
Perhaps the largest component of a Software Factory, Software Product Lines not only provide the greatest value, but also require the greatest investment. Software must be carefully partitioned into distinct and reusable components and those components must readily fit together in a coherent manner. Configuration is the key to Software Product Lines, as projects must be able to pick and choose which components they want to utilize, and then generate an application off of that configuration.

Pero lo más interesante de este artículo temprano, es que se refiere no solo a las iniciativas de Microsoft, sino a las de Sun. De ellas se puede hablar un poco más, y así abrir un poco más las ideas sobre el problema. Así presenta el tema Caprio:

While all of the promises of Software Factories sound appealing, many companies have tried to provide the tools and components, only to fail under the load of inflexible tools or proprietary formats.
All of this is about to change. Big name companies like Microsoft and Sun are getting ready to release many of the components necessary for building and assembling a Software Factory within an organization. With the release of Visual Studio 2005, Microsoft will unveil several add-ins and plug-ins that enable the creation of not only Domain Specific Languages, but also the integration of those languages with the IDE itself. This will allow developers to manipulate and use the language from within the Visual Studio.NET IDE. Not to be outdone, Sun Microsystems is working on its own implementation of Software Factory technology, simply named ‘Project Ace’. Although, very little details of ‘Project Ace’ are available, developers shouldn’t expect Sun to let Microsoft provide .NET tools, without answering with a comparable set of tools for Java.

Bien, qué hay con el proyecto de Sun, ACE? En la presentación de Sun:

The Ace Project at Sun Labs has developed a way to fundamentally simplify the process of creating modern, web-enabled business applications.

• Applications are specified in the Ace language, DASL^§, which is a higher level architectural programming language. This language is the gem at the heart of Ace.

The DASL language abstracts out complexities, such as persistence and distribution. Using DASL, the application writer concentrates on domain details specific to the application's purpose, instead of worrying about the application's deployment architecture, middleware APIs, remote object invocations, and other details of the implementation "stack". The DASL language defines precise application and business logic and semantics, including application-level transactions.

• DASL is based on published specifications and therefore can be considered open.
• Ace is not a tool, it is a language which has a reference implementation that includes an ease-of-use tool.
• Although the DASL language is compiled in the reference implementation, it can also be interpreted.
• The generators which come with Ace can be customized.
• The next version of the reference implementation will have a pluggable Ace generator API.
• DASL can call Java code.
• Ace doesn't compete with Java, it works at a higher level and generates pure Java code.
• The distribution details are implemented automatically at the time the application is compiled and deployed, based on the well defined semantics of the DASL language.
• There is no Ace runtime.
• The Ace approach results in tremendous cost and time savings when creating a J2EE Application.
• As new architectures beyond J2EE evolve, new code generators can be written to support them without modifying the DASL language, and without rewriting applications written in it.

The preliminary results of this new way of building business applications have been remarkable. We have found that in typical web applications as they are written today, roughly 5 to 10% of the code has to do with domain logic, and roughly 90 to 95% has to do with distribution. Using our approach, there is a huge reduction in the number of lines of code required to specify these applications, and a corresponding huge reduction in the time it takes to write and debug the applications.

For example, the Java J2EE Pet Store application can be specified using about 1000 lines of Ace code, as compared to 14,000 lines of code in the native J2EE implementation. In fact, of those 1000 lines of Ace code, 750 of them can be created graphically via UML diagrams that are part of our GUI development tool, so the entire Pet Store is actually specified in Ace by writing only 250 lines of traditional "code".
(...)
The Ace project team believes that application programming languages must evolve to handle the distribution automatically. Just as early programmers who wrote in assembly language had to worry about register allocation, stack protocols for invoking library functions, and other details of the machine on which the applications were run, today's programmers worry about passing data and objects back and forth between various computers, services, languages, and data sources. We have defined DASL as the first of a new breed of higher level languages that abstract out the distribution details and handle them efficiently by capturing the global semantics of the application.
(...)
The benefits of our approach to application writing include:

• Huge reduction in the time it takes to write and debug applications (many fewer lines of code).
• Ability to retarget existing applications to new deployment architectures without having to change the application specification. Retargeting is crucial for several reasons:
• Applications initially written on a small scale (smaller number of simultaneous users) often must be redeployed with additional tiers if they become popular, e.g., the customer base grows.
• As hardware and technology advance, existing applications must often be rewritten for the new technology.
  
• Automatic verification of correctness of application-level transaction semantics.
• Global optimization of communication between the browser, web server, proxy server, application server, and database server tiers. While such optimization is possible today, it is so tedious and time-consuming that it is often not done.
  

Si bien el proyecto ACE no parece estar activo, de todas formas estudiar sus objetivos contribuye a tener una idea más amplia del problema a resolver.
Sobre su lenguaje DASL, en Wikipedia.

IBM y la investigación de patrones de diseño

También de mis notas antiguas, la página de IBM sobre investigaciones acerca de patrones de diseño: buenos materiales y buena bibliografía sobre un tema que ha pasado a ser un patrimonio común del desarrollo de software. El diseño de patrones ha devenido un componente básico del estándar de diseño basado en modelos, y probablemente ambos se convertirán en un pilar del desarrollo de lineas de producto de software (SPL), al modo en que el SEI lo entiende.
Entre otros materiales destacables, Automatic code generation (Vlissides y otros):

Automatic code generation adds a dimension of utility to design patterns. Users can see how domain concepts map into code that implements the pattern, and they can see how different trade-offs change the code. Once generated, the user can put the code to work immediately, if not quite noninvasively.
Much remains to be explored. The concept of design patterns is in its infancy--the tools that support the concept, even more so. Our tool is just a start. It exploits only a fraction of the intellectual leverage that design patterns provide. For example, the tool is limited to system design and implementation; it does not support domain analysis, requirements specification, documentation, or debugging. All of these areas stand to benefit from design patterns, though at this point it might not be clear exactly how. Then again, the principles underpinning our tool were not clear until we had experience using patterns for design. Application is the first and necessary step; only then can we hope to automate profitably.

Habrá que sistematizar todo el material asociado...

Code Generation Network 2007

Mark Dalgarno, en su blog, viene comentando desde hace algunos días las sesiones de Code Generation 2007, que muestra el crecimiento de las técnicas destinadas a construír software d manera más rigurosa y confiable. Como dice la página de la reunión, "Our session leaders are recognised experts in Software Factories, Domain-Specific Languages, MDA and Generative Programming", es decir, confluyen allí las distintas aproximaciones existentes hoy a la generación "industrial" de software.
Dos reportajes aproximan al contenido de sus discusiones: a Fabrizio Pugnetti, de Artisan, y a Tony Clark, de Xactium.
Sobre Dalgarno, en otro momento.