Software Factories para construir Sistemas de Información con GeneXus

Transcripción

1 Instituto de Computación Facultad de Ingeniería Universidad de la República Software Factories para construir Sistemas de Información con GeneXus - Informe del Proyecto de Grado - 27 de agosto de 2007 Autor: Nicolás Castagnet Tutor: Jorge Triñanes

2 Software Factories para construir Sistemas de Información con GeneXus Nicolás Castagnet

3 Resumen En un estudio conducido por el grupo Standish en el 2004 se concluye que más del 70% de los proyectos de software fallan en entregar lo que originalmente se pretendía sin exceder su presupuesto, extender las fechas de entrega o sacrificar la calidad. La propuesta de Software Factories parte de una revisión de los métodos actuales de desarrollo, en la cual sus autores tratan de visualizar cuáles serán los desafíos a enfrentar en la próxima década y diseñan una metodología que combina ideas de Reuso Sistemático, Desarrollo Conducido por Modelos, Desarrollo por Ensamblado y Marcos de Procesos. El proyecto se planteó estudiar si estas ideas son aplicables para lograr mayor eficiencia y efectividad en el desarrollo de Sistemas de Información con GeneXus. Se diseñaron lenguajes gráficos que permiten su construcción a través de diagramas de navegación, se implementó una infraestructura con componentes reusables que resuelven problemas comunes (como la administración de usuarios y menús) y se formuló un proceso de desarrollo que integra estos elementos. De esta forma, se construyó una Software Factory. Como parte de la evaluación, se implementó un sistema a modo de caso de estudio. En la experiencia se observó una ganancia de productividad muy alta (con 40 horas hombres se implementó un sistema completo con 2 procesos de Worklow y 59 páginas Web). Adicionalmente, los niveles de calidad fueron predecibles y uniformes, gracias al uso de lenguajes con abstracciones específicas y a la aplicación de patrones de código para generar la implementación. Dentro de este trabajo se describen los principios de la propuesta de Software Factories, el proceso que se siguió para crear una y para diseñar lenguajes específicos de alto nivel (DSLs), la arquitectura con que se implementó el concepto de Desarrollo Conducido por Modelos, y se muestran varias métricas que se extrajeron al construir un Sistema de Información hipotético aplicando estas ideas. Palabras claves: Software Factories, Sistemas de Información, Desarrollo Conducido por Modelos, DSL, GeneXus

4 Índice Capítulo 1 - Introducción Objetivos Contenido... 3 Capítulo 2 - La Propuesta de Software Factories Motivación El Siguiente Paso Problemas Crónicos del Desarrollo de Software Construcción Monolítica Generalidad Innecesaria Desarrollo Aislado Inmadurez de los Procesos Innovaciones Críticas Reuso Sistemático Desarrollo Conducido por Modelos Desarrollo por Ensamblado Marcos de Procesos Software Factories Qué es una Software Factory? Construcción de una Software Factory Construcción de un Producto Otras Propuestas MDA UML Conclusiones Capítulo 3 - Aplicación en Sistemas de Información Por qué Sistemas de Información? Desarrollo de una Línea de Productos Análisis de la Línea de Productos Definición de la Línea de Productos Delimitación del Dominio del Problema Delimitación del Dominio de la Solución Diseño de la Línea de Productos Desarrollo de la Arquitectura Mapeo de los Requerimientos Definición y Automatización de Procesos Esquema Implementación de la Línea de Productos Creación de Activos de Implementación Creación de Activos de Procesos Conclusiones Capítulo 4 - Diseño de un Lenguaje Específico Definiciones DSL Objetivos Familia de Productos GeneXus Rocha Proceso de Análisis Caso de Estudio Consultas de Información (Salidas) Operación a Estudiar Navegando por Relaciones Un Caso Sencillo Expresiones sobre el Modelo de Datos Un Lenguaje Simple para Generar Código Ingreso de Datos (Entradas) Entradas Consideradas Operación a Estudiar Agregar, Modificar y Borrar Reglas de Negocio Página 1 de 85

5 Integridad Referencial Procesamientos Cálculos o Transformaciones Momento de Disparo Escenarios Alternativos Workflow Menús por Perfil WebPanels y Transacciones Externas DSLs Complementarios Asistencias en Editores Conclusiones Capítulo 5 - Construcción de los DSLs Capturando Intenciones Sencillez versus Completitud Diseño Progresivo Sincronización Generación Deductiva Anatomía de un Lenguaje Arquitectura de los DSLs Modelo Esquema Editores Diseñadores Coordinador Plantillas de Código Extensibilidad Conclusiones Capítulo 6 - Conclusiones Finales La Propuesta de Software Factories Proceso de Construcción Diseño de un Lenguaje Basado en Modelos Implementación del Desarrollo Conducido por Modelos Uso de la Software Factories Trabajos a Futuro Apéndice A - Métricas: Implementación de los DSLs A.1. Líneas de Código A.2. Análisis de los Datos Apéndice B - Métricas: Evaluación de la Software Factory B.1. Tamaño de la Base de Conocimiento B.2. Líneas de Código B.3. Información Ingresada en los DSLs B.3.1. Medidas de Esfuerzo B.4. Normalización a Líneas de Código B.5. Comparación Glosario Bibliografía Página 2 de 85

6 Capítulo 1 Introducción Este proyecto se plantea estudiar las ideas de la propuesta de Software Factories [GS04] impulsada por Microsoft, y explorar si es aplicable junto con GeneXus para mejorar el proceso de construcción de Sistemas de Información. La iniciativa de Software Factories parte de una revisión de los métodos actuales de desarrollo, en la cual sus autores tratan de visualizar cuáles serán los desafíos a enfrentar en la próxima década. A partir de este análisis construyen una metodología que intenta ayudar a superar las limitaciones actuales adoptando patrones de industrialización que han sido exitosos en otras industrias. Estos incluyen ensamblar productos a partir de componentes, automatizar las tareas que se hacen de memoria, formar cadenas de producción y suministros, y estandarizar procesos y arquitecturas. Estas ideas no son nuevas en el desarrollo de aplicaciones, sin embargo, el mayor aporte de esta propuesta es la definición de una metodología que las combina de una forma coherente y ordenada. A partir de esta metodología se construyen lo que se denominan Software Factories. Una Software Factory configura un entorno de desarrollo para brindarle componentes, herramientas y procesos especializados en un problema concreto. El objetivo es ofrecer métodos específicos que permitan alcanzar mejores niveles de productividad y efectividad frente a lenguajes y procesos de propósito general como se suelen utilizar tradicional. En este sentido, una Software Factories puede sustituir a lenguajes como Java o C# por otros con construcciones más especificas para el problema que se modela, y así simplificar el desarrollo. Este proyecto estudia si se pueden aplicar estos conceptos para lograr métodos más eficientes y efectivos que permitan construir Sistemas de Información utilizando GeneXus. Como parte de este trabajo se construye una Software Factory, y al culminarla se hace una prueba de concepto utilizándola en el desarrollo un sistema hipotético de forma de poder evaluar su utilidad Objetivos Los objetivos del proyecto fueron: Comprender la propuesta de Software Factories y brindar una síntesis que describa los problemas que pretende resolver y cómo aspira hacerlo Realizar una experiencia práctica de estos conceptos aplicándolos en el desarrollo de Sistemas de Información Diseñar herramientas de alto nivel que permitan construir estos sistemas a partir de modelos Construir un prototipo con el cual se estudien las dificultades que hay que superar para implementar el concepto de Desarrollo Conducido por Modelos y se ensayen posibles soluciones Evaluar lo beneficios y limitaciones de las Software Factories dentro del contexto de los Sistemas de Información 1.2. Contenido El resto del documento se organiza de la siguiente forma: Capitulo 2 La Propuesta de Software Factories: Sintetiza los contenidos de la propuesta de Software Factories. Comienza describiendo cual es su motivación e indicando las limitaciones que encuentran sus autores en los métodos actuales. Luego se exponen las soluciones que plantean para intentar superarlas y se presenta una metodología que las combina. En el capitulo también se incluye una comparación de esta propuesta con MDA y UML que tienen aspectos similares. Capitulo 3 Aplicación en Sistemas de Información: Describe cómo se aplicó la metodología anterior para definir una Línea de Productos que permita construir Sistemas de Información. En este capítulo se relatan las actividades realizadas durante este proceso, se describen las dificultades que se enfrentaron en cada una de ellas y las decisiones que se tomaron para resolverlas. Capitulo 4 Diseño de un Lenguaje Específico: Una de las ideas principales de la propuesta de Software Factories es el Desarrollo Conducido por Modelos. Se consideró que el proyecto brindaba una buena oportunidad para estudiar si es posible desarrollar modelos de alto nivel para construir Sistemas de Información. En este capítulo se describe la estructura de un lenguaje gráfico que se definió con esta finalidad, y se muestra cómo se condujo su proceso de diseño. Página 3 de 85

7 Capitulo 5 Construcción de los DSLs: Relata cómo se implementó un prototipo del lenguaje anterior, junto con otros complementarios. En la implementación se definió una arquitectura genérica para definir los modelos y traducirlos a aplicaciones ejecutables. Dentro de este capítulo se exponen los problemas que hubo que enfrentar y se describe cómo se resolvieron. Capitulo 6 - Conclusiones: Con este capítulo se culmina el proyecto haciendo una evaluación de los resultados que se obtuvieron aplicando las ideas de Software Factories en la construcción de Sistemas de Información. Para realizar la evaluación se desarrolló un sistema hipotético y se extrajeron métricas para poder juzgar objetivamente los resultados. Aquí se presentan las conclusiones extraídas de la evaluación y se muestra como el enfoque ayudó a lograr incrementos importantes en la productividad, junto con otros beneficios. Al final se incluyen dos apéndices con las mediciones realizadas para evaluar los resultados: Apéndice A - Métricas: Implementación de los DSLs: Brinda mediciones de líneas de código sobre los componentes de la arquitectura base y los DSLs. Apéndice B - Métricas: Evaluación de la Software Factory: Contiene métricas que se obtuvieron al utilizar las herramientas construidas en el desarrollo de un Sistema de Información. Página 4 de 85

8 Capítulo 2 La Propuesta de Software Factories La primera etapa de este trabajo es estudiar y entender las ideas que se proponen en el libro Software Factories [GS04]. En él, sus autores hacen un análisis de los métodos y las prácticas actuales de desarrollo de software y se plantean si es posible afrontar los desafíos de la próxima década con ellos. Durante el desarrollo del libro hacen una crítica constructiva de la contexto presente, intentando identificar cuáles son los puntos en donde aún hay que trabajar para alcanzar nuevos niveles de productividad y efectividad. A partir de este análisis identifican cuatro áreas claves para desarrollar: Reuso Sistematico, Desarrollo Conducido por Modelos, Desarrollo por Ensamblado y Marcos de Procesos. Estas cuatro ideas se combinan en la propuesta de Software Factories, la cual brinda una metodología de trabajo en la cual los autores tratan de plantear cómo podría ser el futuro del desarrollo de software dentro 5 o 10 años. La propuesta de Software Factories comprende una iniciativa de largo plazo impulsada por Microsoft para sus herramientas de desarrollo. Este capítulo brinda un resumen de sus ideas principales y los argumentos que la sustentan. Para comprenderla claramente es importante entender cuáles son los problemas que la inspiran y las observaciones que llevan a definirla. El resumen comenzará por brindar una opinión sobre la situación actual de la industria, luego se enumerarán una serie de problemas que enfrenta y finalmente se presentarán las Software Factories como un conjunto de propuestas que pueden ayudar a encontrar una solución. En los próximos capítulos se describe cómo a partir de los conceptos presentados aquí se construyeron herramientas, componentes y procesos que intentan mejorar el proceso de construcción de los Sistemas de Información Motivación En 1994 el grupo Standish realizó un estudio sobre el grado de éxito en los proyectos de desarrollo de software (The Chaos Report [Sta94]). Según este informe, en Estados Unidos se gastaba alrededor de 250 mil millones de dólares en desarrollo de software cada año en aproximadamente proyectos. Dentro de estos proyectos el estudio concluye que: Sólo el 16% fueron terminados en el plazo establecido y dentro de su presupuesto. Un 31% fueron cancelados, principalmente por problemas de calidad generando pérdidas de alrededor de 81 mil millones de dólares. El otro 53% excedieron su presupuesto en un promedio de un 189%, produciendo pérdidas de 59 mil millones de dólares anuales. Los proyectos que llegaron a completarse sólo entregaron en promedio un 42% de las funcionalidades previstas originalmente. A partir de este estudio se puede concluir objetivamente que el desarrollo de software en 1994 demandaba ya mucho trabajo, consumiendo más capital humano por dólar de lo que se podría esperar de una industria moderna. Las prácticas eran lentas, caras, propensas a errores, generalmente provocando productos con un alto número de defectos, problemas de seguridad, de eficiencia y de calidad de servicio. Cómo será la situación en la actualidad? En la siguiente tabla se muestran los resultados que se obtuvieron cuando el grupo Standish hizo este mismo estudio en el 2004 [Bor05]. Los proyectos se dividen en tres categorías. Categoría Exitosos 16% 29% Cancelados 31% 18% Con dificultades 53% 53% Tabla 1. The Chaos Report A través de estos datos se concluye que únicamente 1 de cada 3 proyectos tienen éxito. El informe también revela que aproximadamente el 70% de los proyectos fallaron en entregar lo que se pretendía originalmente Página 5 de 85

9 sin exceder su presupuesto, extender las fechas de entrega o sacrificar la calidad. Si bien se observa una mejora con respecto al informe de 1994, aún la tasa de éxitos sigue siendo demasiado baja como para sentir que los procesos de desarrollo que se usan en la actualidad son suficientemente eficaces. A pesar de estas fallas, la demanda se espera que siga creciendo a largo plazo, lo que muestra que el valor del software es lo suficientemente alto como para que sus usuarios estén dispuestos a aceptar altos riesgos y eventuales pérdidas con el fin de obtener sus beneficios. Esta situación no es muy alentadora, y en los últimos años no se han podido realizar cambios en los métodos y prácticas de desarrollo lo suficientemente significativos como para lograr revertir la situación. En la última década sólo se han obtenido ganancias modestas en la productividad, las más importantes probablemente sean debido a plataformas como Java y.net, y también al uso de patrones y métodos ágiles de desarrollo. Aunque estos cambios fueron acompañados por un aumento en la complejidad de las aplicaciones que se construyen. Como resultado, la tasa de fracasos sigue siendo demasiado alta, desperdiciando muchas horas en completar proyectos que no logran cumplir las expectativas (Standish estima que en el 2004 se perdió 55 mil millones de dólares en Estados Unidos por estos fracasos [Bor05]) Por otro lado, la demanda global de Software se espera que crezca en un grado de magnitud para la siguiente década, motivada por fuerzas de la economía global como la emergente China, el creciente rol del software en la infraestructura social y el surgimiento de nuevas tecnologías como Web Services y dispositivos móviles [Gre04a]. Sin un incremento comparable en la capacidad de desarrollo, parece inevitable que la demanda va a superar nuestra capacidad de construcción al final de la década. Esto sólo ocurriría si las fuerzas del mercado pudieran actuar libremente, sin embargo, probablemente ya hoy la poca capacidad disponible, junto con la alta tasa de errores y altos costos, estén reprimiendo el potencial que el software le puede brindar a la sociedad El Siguiente Paso La historia del desarrollo de software está marcada por un enfrentamiento continuo frente a la administración de la complejidad y la gestión de los cambios. Cada vez se espera más de un sistema (datawarehouses, acceso móvil, Web Services entre empresas, etc.), lo cual aumenta la complejidad del desarrollo y la dificultad de lograr soluciones que satisfagan todos los intereses. Por otro lado, la capacidad de cambiar es una propiedad esencial que se busca al construir aplicaciones, las mismas deben poder transformarse como respuesta a cambios en el ambiente o en sus requerimientos. Para enfrentar estos desafíos la industria ha logrado avanzar creando abstracciones más potentes en cada generación. Se progresó desde tarjetas perforadas, pasando por lenguaje ensamblador, programación estructurada, orientada a objetos, lenguajes byte coded (Java y.net) y patrones. Smith y Stotts resumen este progreso elocuentemente [SS02]: La historia de la programación es un ejercicio de abstracciones jerárquicas. En cada generación, los diseñadores de lenguajes crean construcciones a partir de las lecciones aprendidas en la generación previa, y luego los arquitectos las usan para construir abstracciones más complejas y poderosas. El incremento de la complejidad y el continuo cambio de requerimientos y tecnologías están llevando al límite el enfoque actual de desarrollo. Los que demandan sistemas informáticos están tendiendo a buscar proveedores especializados en cada uno de sus componentes para reducir los riesgos, el costo y el tiempo de los proyectos. Al mismo tiempo se mejora la calidad del producto final a través de un reuso sistemático de componentes ya probados. Sin embargo, en la actualidad básicamente se construyen sistemas utilizando lenguajes de propósito general como Java o.net; e incluso, muchas veces, resolviendo todos los módulos con desarrollo propio. No se podrían tener lenguajes y componentes con abstracciones más especificas para resolver problemas como el manejo de clientes o la contabilidad?. Una de las metas de las Software Factories es acelerar el proceso de creación de lenguajes de este tipo, que permitan encapsular el conocimiento de expertos en cada área, y facilitar su aprovechamiento por el resto de la industria. La visión de Software Factories aspira a lograr un funcionamiento más industrializado del desarrollo de software. En lugar de crear sistemas de cero, estos se construirían rápidamente ensamblando componentes Página 6 de 85

10 de múltiples proveedores (expertos en cada dominio), y utilizando herramientas especializadas para automatizar las tareas tediosas y repetitivas. La propuesta de Software Factories brinda una metodología de trabajo cuyo objetivo es lograr una mayor automatización en las tareas de construcción integrando innovaciones en el Desarrollo Conducido por Modelos (Model Driven Development, MDD), Desarrollo Basado en Componentes (Component Based Development, CBD) y métodos ágiles de desarrollo. Un ejemplo es la Software Factory HL7 [RGT05], la cual permite realizar implementaciones del estándar HL7 para colaboración entre sistemas dentro del área de la salud. Al instalar está Software Factory, se configura el entorno de desarrollo con proyectos, guías, plantillas, asistentes, herramientas de modelado y lenguajes específicos para implementar un canal de comunicación que siga el estándar HL7. La iniciativa de Software Factories consiste entonces en dos aspectos: brindar una metodología que permita construir Software Factories (como la HL7), y promover una serie de Innovaciones Críticas que faciliten la creación de este tipo de herramientas Problemas Crónicos del Desarrollo de Software Los autores del libro Software Factories [GS04] identifican cuatro problemas crónicos en los métodos y prácticas actuales que limitan su capacidad para lograr proyectos más predecibles y eficientes. Estos problemas son: Construcción Monolítica, Generalidad Innecesaria, Desarrollo Aislado e Inmadurez de los Procesos Construcción Monolítica La Industria de Software no ha sido capaz de implementar el desarrollo por ensamblado a gran escala, es decir, la construcción de aplicaciones en base a componentes prefabricados. Si bien se han logrado éxitos parciales (como por ejemplo, el uso de gestores de Base de Datos o Sistemas de Workflow), no se ha logrado extender su éxito a un nivel significativo para resolver requerimientos funcionales a través de componentes prefabricados pequeños. El uso de estas prácticas podría ayudar a reducir los tiempos de desarrollo y aprovechar la experiencia de expertos en cada área. El problema no se debe a que no se ha reconocido la oportunidad. El desarrollo por ensamblado ha sido parte de la visión de pioneros en la industria por décadas, claramente al menos desde el surgimiento de la orientación a objetos, aunque probablemente desde antes. Tampoco se debe a que no hubo inversiones en intentar resolver el problema. Ha sido el objetivo de numerosos esfuerzos académicos y comerciales en métodos de desarrollo basados en objetos y componentes. Sin embargo, el problema aún sigue presente y continúan surgiendo nuevos intentos por resolverlo, como por ejemplo la orientación a servicios. Garlan (y otros) han sugerido algunos posibles motivos [GAO95]: Protocolos de comunicación muy atados a la tecnología de implementación de los componentes (por ejemplo, COM y RMI) Tecnologías débiles de especificación y empaquetado de componentes hacen difícil predecir su comportamiento dentro de la arquitectura (por ejemplo, qué cantidad de recursos consumen, qué riesgos de seguridad introducen) Falta de tecnología de encapsulación que permita adaptar las dependencias de los componentes a entornos que difieren levemente del escenario para el cual fueron diseñados. Relaciones inmaduras entre consumidores y proveedores dentro de la Industria de Software. En algunos de estos puntos ya se han logrado avances significativos, por ejemplo el uso de WebServices basados en XML brindan protocolos de comunicación más generales Generalidad Innecesaria Los métodos y prácticas de desarrollo actuales generalmente ofrecen más grados de libertad de los que son necesarios para la mayoría de las aplicaciones. Por ejemplo, una gran parte de los Sistemas de Información se construyen a través de unos pocos patrones básicos: leer información de la Base de Datos, mostrársela al usuario, permitir que se realicen transacciones según las reglas de negocio, y almacenar los datos ingresados. Página 7 de 85

11 Por supuesto que esta es una simplificación, ya que las aplicaciones actuales generalmente incluyen una variedad de desafíos adicionales, como la interacción con sistemas legados, altos volúmenes de datos, grandes cantidades de usuarios concurrentes o rigurosos requerimientos de calidad que hacen que la implementación de estos patrones básicos no sea sencilla. Sin embargo, luego de desarrollar varias aplicaciones del mismo tipo, a pesar que suelen haber detalles específicos de cada proyecto, muchos de los problemas que se deben resolver son similares. Entonces, si se acepta que para un determinado tipo de sistema hay características comunes, es adecuado utilizar lenguajes de propósito general como C# o Java? o se podrían utilizar herramientas más especificas que resuman el conocimiento y la experiencia adquirida con el tiempo invertido en esta clase de sistemas?. Las Software Factories intentan dar una posible respuesta a estas preguntas proponiendo el uso de lenguajes con abstracciones específicas para dominios de aplicación más acotados Desarrollo Aislado El tercer problema identificado se le denomina Desarrollo Aislado. Cada producto de software se trata como si fuera único, a pesar que la mayoría tienen más similitudes que diferencias. El retorno de la inversión sería mayor si se planificaran múltiples productos de forma simultánea (por ejemplo, utilizando Líneas de Productos), de forma de poder detectar más oportunidades de reuso. Raramente se hacen inversiones comercialmente significativas para identificar, construir, empacar y distribuir componentes reusables. El reuso, en lugar de ser sistemático, ocurre por necesidades específicas. De esta forma, hay una baja probabilidad que un componente pueda ser aprovechado fuera del contexto para el cual fue diseñado y por lo tanto el reuso raramente ocurre a menos que haya sido planificado de antemano. Es así que distintos grupos de desarrollo desperdician tiempo construyendo componentes similares, en lugar de combinarse para coordinar sus esfuerzos Inmadurez de los Procesos El último problema identificado se relaciona a los procesos utilizados. No se ha encontrado la forma de desarrollar productos de software de forma consistente y predecible, en los tiempos estimados y sin exceder el presupuesto. Esto sugiere que los procesos de desarrollo de software aún no son suficientemente maduros. En general, o son muy rigurosos, optimizados para manejar la complejidad a expensas de los cambios; o son demasiado permisivos, optimizados para manejar los cambios a expensas de la complejidad. Un proceso de desarrollo maduro es un prerrequisito para la automatización, ya que las herramientas no pueden automatizar tareas que no están claramente definidas. En esta área también se enfocan las Innovaciones Críticas Innovaciones Críticas En la sección anterior se identificaron cuatro problemas que enfrenta la industria y pueden estar frenando la transición de un modelo de desarrollo artesanal a un modelo manufacturero. Los autores del libro Software Factories [GS04] proponen algunas posibles soluciones a través de una serie de Innovaciones Críticas, y afirman que su promoción podría ayudar a la industria a quedar en una mejor posición. Las Innovaciones Críticas se dividen en cuatro categorías: Reuso Sistematico, Desarrollo Conducido por Modelos (Model Driven Deveolpment, MDD), Desarrollo por Ensamblado, y Marcos de Procesos. Si bien en la actualidad hay numerosos trabajos desarrollados sobre varias de las innovaciones propuestas, aún no han podido desplegar todo su potencial en productos comerciales, y un posible motivo es que aún no existen procesos que las integren armoniosamente. En los siguientes párrafos se brindará un breve análisis sobre cada una de ellas y luego se presenta la propuesta de Software Factories como una metodología que las integra Reuso Sistemático Una de las recomendaciones más importantes es trabajar en base a familias de productos de software. Una familia define un grupo de productos que a pesar de ser distintos entre sí, contienen varias funcionalidades comunes. En este sentido lo que se propone es que buscar crear grupos especializados encargados de proveer componentes (y otros elementos) diseñados para poder ser utilizados en distintos sistemas. Las prácticas de Líneas de Productos de Software permiten explotar el concepto de familia de productos. Una Línea de Productos se encarga de identificar funcionalidades comunes y posibles variantes dentro de un Página 8 de 85

12 dominio específico, para luego formar una línea de producción que permita construir a los miembros de la familia de forma más rápida, más barata y menos riesgosa. En lugar de esperar que el reuso ocurra de forma espontánea y natural, la creación de Líneas de Productos brinda un enfoque más sistemático. Los productos desarrollados como una familia pueden reusar requerimientos, arquitecturas, librerías, componentes, pruebas y otros elementos. Para aplicar estos conceptos se deben tener varios grupos de desarrollo independientes. Por un lado se tiene el equipo de desarrollo de la Línea de Producto, el cual define la clase de productos que se van a construir, y provee componentes reusables, herramientas, procesos y otros elementos comunes para implementarlos. Por otro lado, están los equipos de desarrollo de los productos que se encargan de desarrollar productos específicos en base a los elementos comunes. Estos dos tipos de roles podrían estar incluso en empresas distintas. Se podrían tener por un lado proveedores de componentes (por ejemplo, componentes de facturación, de auditoría, de seguridad), y por otro lado empresas que los utilizaran para construir aplicaciones más grandes (por ejemplo, al construir el sistema central de una empresa de servicios). Estas ideas están siendo aplicadas con éxito por ejemplo en la industria de semiconductores, sin embargo, aún están en estado inmaduro dentro de la Industria de Software. La creación de Líneas de Productos es el primer paso para lograr un proceso más industrializado de desarrollo de software, pero por qué no se ven demasiadas Líneas de Productos hoy día?. La razón más significativa probablemente sea el alto costo que implica construir una. Por lo tanto, para promover la creación de Líneas de Productos se debe lograr antes que sean más baratas de montar y operar. En esta última área aún es necesario trabajar Desarrollo Conducido por Modelos La segunda categoría de Innovaciones Críticas que se deben promover están vinculadas al Desarrollo Conducido por Modelos. Desde hace mucho tiempo se han logrando avances en el desarrollo de software aumentando los niveles de abstracción. Contar con niveles de abstracción más altos conlleva varios beneficios, incluyendo un incremento en la productividad, menor probabilidad de defectos, mayor facilidad de mantenimiento y una mejor calidad del producto final. Aumentar los niveles de abstracción es el objetivo del Desarrollo Conducido por Modelos (Model Driven Development, MDD). La aplicación de MDD consiste en capturar el diseño del sistema en modelos de alto nivel, a partir de los cuales se puede generar la implementación, por ejemplo, utilizando generadores de código. La especificación de alto nivel se traduce en programas ejecutables, de esta forma el desarrollo se hace en base a modelos específicos y no a código escrito en un lenguaje de programación (como Java o C#). Se buscan modelos que puedan ser compilados y ejecutados de la misma forma que se hace actualmente con el código fuente. Para lograrlo, los modelos se deben expresar con una rigurosidad mayor a la que se utiliza generalmente al documentar. Éstos deben estar escritos de forma muy precisa y sin ambigüedad. Adicionalmente, para brindar un nivel de abstracción más alto, el lenguaje de modelado debe tener abstracciones muy específicas al dominio del problema que se está modelando, y por lo tanto debe apuntar a un dominio de aplicación más pequeño que un lenguaje de propósito general. A un lenguaje con las características anteriores se le denomina Lenguaje Especifico de Dominio (Domain Specific Language, DSL). Un DSL se define para resolver una clase de problemas concreto, a diferencia de un lenguaje de programación de propósito general. En la Figura 1 se muestra un DSL incluido en Microsoft Visual Studio 2005 Team System. A la izquierda se describen componentes, como por ejemplo Web Services; y a la derecha posibles servidores lógicos donde pueden ser instalados. Este DSL se utiliza para definir cómo se configuran los Web Services dentro de un centro de cómputos. Su ubicación se define arrastrándolos al servidor lógico que les corresponde. Si la configuración definida por el servidor no permite publicar el Web Service en él, se despliegan mensajes de error como se muestra en la Figura 1. Un DSL es una potente herramienta de programación, permiten implementar un sistema completo, o partes de él, en menor tiempo desde un nivel de abstracción mayor. Adicionalmente, los modelos construidos con DSLs permiten capturar documentación que frecuentemente es perdida en artefactos de bajo nivel como código fuente, y que luego es difícil de encontrar y mantener. Los DSLs se deben encargar de actualizar automáticamente los modelos relacionados ante cambios, y luego generar código ejecutable a partir de éstos aplicando patrones predefinidos. Página 9 de 85

13 Hoy día implementar esta clase de lenguajes de modelado suele ser costoso, por lo tanto, para promover su utilización es necesario abaratar el proceso. Microsoft reconoce esta situación, y por este motivo junto a la iniciativa de Software Factories ha anunciado varios proyectos que viabilicen la construcción de Software Factories en Visual Studio. Actualmente existen dos herramientas disponibles: DSL Tools [Mica]: Permite crear un diseñador con notación de diagrama para un dominio especifico. Dentro del diseñador se pueden asociar plantillas de código que se aplican sobre los modelos creados para generar código fuente y otros archivos. Guidance Automation Toolkit [Micb]: Es una extensión de Visual Studio que le permite a los arquitectos definir patrones de código, asistentes y componentes que ayuden a los desarrolladores a construir aplicaciones de forma consistente con los lineamentos de la arquitectura Desarrollo por Ensamblado Figura 1. Domain Specific Language (DSL) En una visión más industrializada del desarrollo de software, los programadores construirán pequeñas partes de cada aplicación, típicamente menos de un tercio. El resto vendrá de componentes ya existentes. Dentro de este contexto el desarrollo consistirá primariamente en la personalización de componentes, adaptaciones, extensiones y ensamblado. En lugar de escribir grandes cantidades de código, se obtendrán la mayoría de la funcionalidad a partir de componentes prefabricados ofrecidos por distintos proveedores. Los desarrolladores de componentes utilizarán también otros proveedores para construir sus componentes. Este es el objetivo del Desarrollo por Ensamblado. Para soportarlo es necesario avanzar en áreas cómo: Protocolos Independientes de la Plataforma, Autodescripción, Encapsulación Variable, Ensamblado por Orquestación y Desarrollo Conducido por la Arquitectura: Protocolos Independientes de la Plataforma: Las tecnologías de Web Services (WDSL, SOAP, y XML, por ejemplo) tuvieron éxito en donde tecnologías anteriores de ensamblado de componentes habían fallado. El motivo del éxito probablemente sea que separaron la tecnología usada para Página 10 de 85

14 especificar y ensamblar componentes, de la tecnología para implementarlos. La simplicidad de los protocolos basados en XML disminuye las barreras de su implementación, y asegura una gran universalidad. Al construir su especificación en base a estándares aceptados por distintos representantes de la industria, se ha logrado una plataforma de interoperabilidad desde sus cimientos. Autodescripción: Al empaquetar un componente debe quedar claro qué asunciones tiene, qué dependencias, cuál es su comportamiento, qué recursos consume y su eficiencia. De esta forma los desarrolladores pueden razonar con más claridad sobre la interacción entre componentes. Encapsulación Variable: La encapsulación estática tiende a aumentar la probabilidad de que un componente al ser ensamblado no responda bien a requerimientos no funcionales o del contexto en que se aplica. La encapsulación variable consiste en publicar componentes parcialmente encapsulados que pueden ser adaptados a nuevos contextos a través de aspectos. Este modelo comparte ideas con AOP (Aspect Oriented Programing), en el cual las adaptaciones válidas se identifican por adelantado (los aspectos) y se especifican usando interfaces u otros medios similares, luego durante la integración del componente o la implantación se puede definir cómo se implementan estos aspectos. Ensamblado por Orquestación: Generando contratos formales de funcionamiento se pueden definir servicios capaces de ser ensamblados por un motor de orquestación (como Microsoft BizTalk Server). Un motor de orquestación básicamente realiza una mediación entre servicios, definiendo cómo interactúan entre sí, cómo intercambian datos, y cómo es el flujo de operaciones que guía la interacción. Un motor de orquestación también puede validar que se respeten las secuencias de invocaciones definidas en los contratos y brindar servicios adicionales como controles de seguridad, generación de registros de auditoría y también actuar como puente entre tecnologías distintas. Desarrollo Conducido por la Arquitectura: Es mejor evitar el ensamblado de componentes inapropiados que hacer malos ensamblados, pero cómo se pueden prevenir las consecuencias de una decisión de diseño en el uso de un componente? Este es el propósito de la arquitectura. La misma brinda una descripción de alto nivel del software, exponiendo su estructura y escondiendo sus detalles. A partir ella se puede razonar acerca de las consecuencias de una decisión de diseño. La arquitectura también brinda un marco de referencia general, y los requerimientos globales que se imponen sobre el sistema. Esta reduce el riesgo de un ensamblado inapropiado al restringir las decisiones de diseño posibles. El Desarrollo por Ensamblado no podrá ser realizado en una escala industrial sin un progreso significativo en las prácticas arquitectónicas que den mayor confianza de la elección de una arquitectura particular Marcos de Procesos El último grupo de Innovaciones Críticas se relaciona con los procesos de desarrollo. Un proceso de desarrollo maduro debería ser capaz de preservar la agilidad mientras se escala en complejidad al enfrentar proyectos grandes, distribución geográfica, o ciclos de vida extensos. El uso de procesos formales ha ayudado a administrar la complejidad imponiendo una estructura que define las tareas a realizar, el orden en que se realizan y las responsabilidades de cada una de las personas que intervienen. Sin embargo, una de las mayores críticas que se le hacen a los procesos formales es que suelen ser muy abstractos. Las guías que ofrecen suelen ser obvias para un desarrollador experimentado, y muy poco concretas para que puedan ser aplicadas por un novato. Para poder agregar valor deben ser especializadas para un proyecto concreto. Debido a que cada proyecto es único en varias formas, es imposible publicar un proceso que satisfaga las necesidades de todo proyecto. Una forma de enfrentar este problema es buscar acotarlo. En lugar de intentar hacer un proceso universal que sirva para cualquier clase de proyecto, se puede especializar y adaptar un proceso formal para una familia específica de proyectos. Probablemente el UP (Unified Process) no hubiera tenido éxito si no hubiera consultores capaces de adaptarlo a clientes y a las necesidades de proyectos concretos. Como otras formas de reuso, esta clase de personalizaciones sólo tienen sentido si se pueden utilizar más de una vez, esto sugiere nuevamente el enfoque de familia de productos (pero enfocado en procesos) y para lograrla se introduce un nuevo concepto, los Marcos de Procesos. Un Marco de Procesos es una estructura que combina varios microprocesos, cada uno diseñado para construir elementos parciales que luego se utilizan para elaborar a los miembros de la familia de productos. Por ejemplo, un Marco de Procesos para construir una aplicación en tres capas podría contener un microproceso para construir la interfaz de usuario, uno para la capa con la lógica del negocio y otro para la Página 11 de 85

15 capa de datos. Este modelo permite disponer de procesos altamente personalizados que brinden una guía con indicaciones claras durante la construcción de los productos de software. Se proponen dos innovaciones más, relacionadas con los Marcos de Procesos, para lograr potenciar sus beneficios: Planificación Basada en Restricciones y Guías Activas Planificación Basada en Restricciones La planificación basada en restricciones es un método para organizar el desarrollo que balancea las necesidades de agilidad con las necesidades de imponer algo de estructura. En lugar de prescribir el proceso, la planificación basada en restricciones proporciona guías e impone restricciones sobre los artefactos de desarrollo que deben ser producidos. Este enfoque fomenta la agilidad dejando que el flujo de trabajo se presente de la forma más adecuada y oportuna para el proyecto mientras se respeten las restricciones impuestas sobre los artefactos resultantes. Un Marco de Procesos describe los requerimientos de cada artefacto que es producido en cada microproceso. La descripción puede enumerar las decisiones claves que hay que tomar, las relaciones de compromiso asociadas a cada decisión, las actividades requeridas y opcionales, los recursos requeridos y el resultado que se debe producir por cada actividad. Las restricciones imponen precondiciones que se deben cumplir antes que se produzca un artefacto, las postcondiciones indican condiciones para luego que se produzca, y las invariantes definen condiciones que se deben sostener luego que el artefacto está estabilizado. Por ejemplo, se puede requerir que el alcance y los requerimientos estén definidos antes que empiece una iteración y que todo el código este verificado antes de terminarla. Se recuerda que un Marco de Procesos está compuesto por varios microprocesos. Por lo tanto, si cada microproceso está definido basado en restricciones, no es necesario aplicar los microprocesos en un orden predefinido, sino que se pueden ordenar de forma dinámica utilizando el flujo que refleje mejor las necesidades de un proyecto concreto. Siempre y cuando se satisfagan las restricciones de cada microproceso Guías Activas Guías Activas (Active Guidance) es un término que se utiliza para describir un enfoque que consiste en utilizar agentes de software para asistir a los desarrolladores. Estos agentes monitorean sus actividades en tiempo real y verifican que se cumplan las restricciones impuestas por el Marco de Procesos. Jacobson describe estas ideas en el articulo A Resounding Yes to Agil Process-but also to More [Jac04]. Por ejemplo, cuando un desarrollador está intentando publicar su código en el sistema de control de versiones un agente de software podría prevenir que no se publique un archivo de código si no se puede compilar o no incluye pruebas unitarias. Una de las claves para lograr que las guías activas sean efectivas es asegurarse que el agente nunca interfiera insistiendo con tareas no importantes que consumen tiempo. Una forma de lograr esto es diferenciar reglas de mayor y de menor importancia, y permitir a los desarrolladores que invaliden una regla registrando un motivo para que pueda ser consultado luego. Un uso común de las guías activas es para entrenar desarrolladores, ya que pueden ser más efectivas que la ayuda pasiva. Para desarrolladores experimentados, las guías activas pueden servir para capturar errores que el desarrollador pasó por alto, de la misma forma que lo hace un compilador. Un ejemplo de un producto que provee guías activas es Jaczone WayPointer. Este producto monitorea en tiempo real modelos UML mientras son diseñados evaluando su completitud, consistencia y correctitud. Al detectar un problema proporciona ayudas y sugerencias de acuerdo a los objetivos que se hayan definido Software Factories En las secciones anteriores en primer lugar se intentó identificar posibles problemas que pueden estar frenando la transición del desarrollo artesanal a un desarrollo industrial, en el cual las aplicaciones se construyan aprovechando sus similitudes para lograr menores tiempos y una calidad más predecible. Luego se presentaron una serie de ideas y conceptos, agrupadas como Innovecaiones Criticas, que pueden ayudar a lograr transición. Sin embargo, probablemente ninguna de ellas sea lo suficientemente fuerte para Página 12 de 85

16 lograrla por si sola. Para alcanzar un modelo de desarrollo más industrializado, deben integrarse en una metodología coherente que combine su potencial. Este es el objetivo de la propuesta de Software Factories Qué es una Software Factory? Los autores del libro Software Factories [GS04] la definen como: Una Software Factory es una Línea de Productos de software que configura herramientas extensibles, procesos, y contenidos utilizando una plantilla de Software Factory, basada en un esquema de Software Factory, para automatizar el desarrollo y el mantenimiento de variantes de un producto arquetípico adaptando, ensamblando, y configurando componentes basados en frameworks. Una Software Factory es una Línea de Productos que configura una herramienta de desarrollo con paquetes y guías cuidadosamente diseñadas para construir un tipo específico de aplicaciones. Una Software Factory contiene tres ideas claves: un esquema, una plantilla y un entorno de desarrollo extensible: El esquema de la Software Factory actúa como una receta. Lista sus ingredientes: proyectos, directorios de código fuente, archivos SQL y archivos de configuración entre otros. Además de listar los ingredientes, también explica cómo deben combinarse para crear el producto. Identifica los DSLs que deben ser usados y describe cómo los modelos basados en estos DSLs pueden ser transformados en código y otros artefactos, o en otros modelos. Describe la arquitectura de la Línea de Productos y las relaciones claves entre los componentes y frameworks que comprende. La plantilla de la Software Factory es como una bolsa de supermercado que contiene los ingredientes listados en la receta. Provee los patrones, guías, plantillas de código, frameworks, ejemplos, herramientas personalizadas como editores visuales de DSLs, XSDs, hojas de estilo, y otros ingredientes utilizados para construir el proyecto. Finalmente, la herramienta de desarrollo extensible es como el horno donde se cocina la comida. Cuando se configura con la plantilla de la Software Factory, la herramienta de desarrollo se convierte en una Software Factory para una familia de productos. Es decir, en una herramienta de desarrollo con componentes, herramientas y procesos específicos para crear un tipo específico de productos Construcción de una Software Factory Aquí se resumirán las actividades que involucra la creación de una Software Factory. En el siguiente capítulo se describen de forma más detallada al relatar cómo se aplicaron para construir una Software Factory especializada en Sistemas de Información. La construcción consiste primero en definir el esquema, y luego en implementar la plantilla de la Software Factory para que brinde los activos definidos en el esquema Esquema El proceso de construcción del esquema consiste básicamente en dos actividades: Análisis de la Línea de Producto: En esta actividad se define el alcance de la Software Factory, el mismo determina los productos que se van a producir y mantener. El alcance se define describiendo el dominio del problema al que se enfoca. Dentro de esta actividad también se definen los requerimientos de los productos que se crean con la Software Factory. Diseño de la Línea de Producto: Aquí se define cómo se van a construir los productos que estén dentro del alcance de la Software Factory. La tarea central es definir la arquitectura para la familia de producto. Se debe presentar una arquitectura base diseñada para soportar variaciones dentro de la familia de productos. En esta actividad también se debe definir cómo se resuelven los requerimientos, el proceso de desarrollo para los productos, y un plan para el uso de herramientas que automaticen parte del proceso de desarrollo. En esta actividad se define el esquema de la Software Factory. El mismo se organiza en vistas, los activos definidos para resolver cada requerimiento se agrupan dentro de las vistas, y el proceso de desarrollo del producto se expresa como microprocesos asociados a cada vista. Como se mencionó previamente el esquema se puede ver como una lista de ingredientes. En la Figura 2 se muestra el esquema de la Software Factory HL7 [RGT05], allí se pueden ver sus vistas, el contenido de cada vista (herramientas, activos y artefactos producidos) y las relaciones entre ellas. Página 13 de 85

17 Plantilla Figura 2. Esquema de la Software Factory HL7 Luego de definir el esquema, la arquitectura base y el proceso: se deben crear los activos que van a asistir el proceso de construcción de cada producto de la Software Factory. La plantilla es la implementación del esquema. La plantilla de la Software Factory debe incluir activos, por ejemplo para: Requerimientos: Lenguajes de especificación. Implementación: Patrones, librerías y componentes. Verificación: Pruebas unitarias y pruebas de integración. Implantación: Configuraciones de servidores donde serán implantados los miembros de la familia. Al construir la plantilla se implementan componentes y librerías, se escribe documentación, y también se crean herramientas específicas para sustentar el proceso de desarrollo como DSLs, asistentes y otros que se consideren necesarios. La plantilla de la Software Factory debe verificar que no haya grandes discontinuidades entre artefactos que forman parte de distintas vistas del esquema, que todo artefacto visible pueda ser modificado durante el proceso y que no haya pasos irreversibles dentro del proceso de desarrollo del producto Construcción de un Producto El objetivo de una Software Factory es desarrollar rápidamente miembros de una familia de productos. Construir un producto usando una Software Factory incluye las siguientes actividades: Análisis del Problema: Se determina si el producto está dentro del alcance de la Software Factory. Dependiendo de cómo se ajusta se debe decidir si se construye algo o todo fuera de la Software Factory. En algunos casos incluso se podría decidir ajustar el esquema y la plantilla de la Software Factory para que se acomode mejor al producto analizado y a futuros productos. Especificación del Producto: Se definen los requerimientos indicando las diferencias con la arquitectura base de la Software Factory. Se pueden utilizar distintos mecanismos de especificación Página 14 de 85

18 como hojas de propiedades, asistentes, modelos de funcionalidades, modelos visuales o definiciones escritas. Diseño del Producto: Consiste en adaptar la arquitectura de la Software Factory y personalizar el proceso de desarrollo de software en base a los requerimientos del producto. Implementación del Producto: Comprende actividades usuales, como desarrollo de componentes, pruebas unitarias y ensamblado de componentes. Se pueden utilizar distintos mecanismos para asistir la implementación como hojas de propiedades, asistentes, modelos de funcionalidades que configuran los componentes o modelos visuales que los ensamblan y generan tanto nuevos artefactos como otros modelos, archivos de configuración y código fuente. Implantación del Producto: Consiste en crear o reutilizar archivos de configuración para implantar el producto en servidores y configurar los componentes que se van utilizar. Verificación del Producto: Consiste en crear o reutilizar programas de prueba para verificar distintos aspectos como la correctitud, la eficiencia y la robustez Otras Propuestas Una forma de entender mejor una definición es analizarla en contraposición con otras propuestas. En esta sección se va a comparar brevemente la propuesta de Software Factories con Model-Driven Arquitectura (MDA) y a analizar el uso de UML en el Desarrollo Conducido por Modelos MDA La propuesta de Software Factories ha recibido mucha atención dentro del Object Managment Group (OMG), organismo promotor de MDA. Ambos modelos parecen promover ideas similares, como crear aplicaciones en base a modelos específicos de más alto nivel, sin embargo, también hay diferencias muy marcadas. El siguiente texto es un extracto de las preguntas frecuentes de MDA [MDA FAQ] en donde se define esta propuesta: El MDA es una nueva forma de desarrollar aplicaciones y escribir especificaciones, basada en un modelo independiente de la plataforma (Platform-Independen Model, PIM) o especificación de las funcionalidades y comportamientos del negocio. Una especificación MDA completa consiste de un modelo UML base definitivo independiente de la plataforma, más uno o más modelos específicos de plataforma (Platform-Specific Models, PSM) y un conjunto de definición de interfaces que describen cómo el modelo base es implementado en un middleware de plataforma diferente. Una aplicación MDA completa consiste de una PIM definitivo, más uno o más PSMs e implementaciones completas, una sobre cada plataforma que los desarrolladores de la aplicación deciden soportar. MDA propone que las aplicaciones sean diseñadas a partir de modelos. Estos modelos deberían estar definidos en UML y estar diseñados de forma tal que su especificación sea independiente de la plataforma (creando PIMs). Luego se deben definir mecanismos para trasformar los PIMs en modelos específicos para cada una de las plataformas que se quiera soportar (los PSM). MDA se focaliza en definir las aplicaciones desde el punto de vista de su funcionalidad y su comportamiento sin incluir detalles de la tecnología subyacente. La intención es que de esta forma no haya que volver a definir la aplicación si surge una nueva tecnología. La funcionalidad se especifica una única vez, y ante nuevas tecnologías se define un nuevo PSM y cómo se realiza la transformación. De la definición la primera conclusión que se puede extraer es que MDA se centra en definir modelos independientes de la plataforma, por otro lado la propuesta de Software Factories se centra en un enfoque metodológico dándole menos importancia a la independencia de la tecnología. Los autores de Software Factories argumentan que el fin de construir una aplicación es lograr una implementación que satisfaga correctamente los requerimientos. Estos requerimientos podrían incluir exigencias de eficiencia, seguridad, interacción con código legado, restricciones de presupuesto, etc. En algunos casos la solución que se escoja dependerá fuertemente de la tecnología que se tenga debajo, por lo tanto cuestionan que en la práctica sea posible aplicar siempre modelos independientes de la tecnología subyacente. También señalan que, si bien la independencia de la tecnología es importante para muchos clientes, otros tal vez prefieran otros atributos como mayor productividad y aplicaciones más predecibles. Otra diferencia que se puede encontrar es que MDA propone únicamente el uso de modelos para construir aplicaciones. Sin embargo, Software Factories tiene una propuesta más modesta, sólo propone los DSLs como una herramienta para resolver algunos problemas, pero tampoco los autores creen que todos los Página 15 de 85

19 problemas se puedan resolver de esta forma, en algunos casos puede ser más conveniente simplemente escribir código. A favor de MDA se puede decir que brinda una propuesta más concreta y detallada de cómo utilizar modelos para construir aplicaciones (detalla el concepto de PIM y PSM, sugiere UML como lenguaje de modelado, MOF cómo lenguaje para describir la estructura de los modelos, QVT para realizar las transformaciones, entre otros). En cambio, Software Factories brinda guías pero no detalla con profundidad soluciones concretas, lo cual puede ser un inconveniente cuando se buscan aplicar estas ideas. Otra de las diferencias fundamentales es que la propuesta de Software Factories tiene un alcance más amplio. MDA se centra en el problema de construir aplicaciones utilizando modelos, y lo hace con más detalle. Por otro lado, las Software Factories integran diversos conceptos de ingeniería de software y brindan propuestas más concretas para lograr un reuso sistemático, aplicar patrones de diseño, desarrollar por ensamblado o lograr procesos de desarrollo ágiles. Como conclusión final se cree que MDA es una referencia que debe ser tenida en cuenta si se desean crear modelos independientes de la plataforma. Por otro lado, la propuesta de Software Factories brinda una base metodológica más amplia y propone argumentos con un alcance de aplicación mayor, pero sus guías son menos específicas, y por lo tanto requieren de mayor capacidad de personalización al contexto de aplicación para poder sacar buenos resultados con ellas UML Otro tema que frecuentemente motiva discusiones en blogs es si el lenguaje UML es apropiado para utilizar en el Desarrollo Conducido por Modelos (MDD). Los promotores de Software Factories no lo creen adecuado, se va a explicar primero su posición y luego contrastarla con la de Grady Booch [Boo04] (uno de los creadores de UML). Los autores de Software Factories reconocen que el UML ha aportado mucho valor al desarrollo de aplicaciones durante la última década. Ha logrado unificar con mucho éxito distintas notaciones existentes previamente. En la actualidad, UML contiene notaciones y conceptos que son fácilmente reconocidas por prácticamente todo desarrollador. Por lo cual resulta muy adecuado para documentar distintos aspectos del software y comunicarlos entre grupos de desarrolladores. Sin embargo, el debate se centra es determinar si UML es el medio adecuado para crear modelos con el suficiente rigor como para poder generar sistemas ejecutables a partir de ellos, y si pueden ser útiles para automatizar actividades del ciclo de desarrollo de software. Probablemente uno de los argumentos más fuertes es que el alcance de la especificación de UML es excesivamente amplia y flexible, pero no tiene suficiente rigor como para generar código ejecutable efectivamente, por lo tanto puede parecer mejor idea crear un lenguaje de modelado con representaciones gráficas y conceptos más específicos para un problema concreto. Los promotores de UML se defienden alegando que brinda mecanismos para lograr especializaciones, como estereotipos, tagged values, MOF (Meta-Object Facility, un metalenguaje utilizado para describir la estructura de otros lenguajes), y que las restricciones visuales son limitaciones de las herramientas de modelado pero no del UML en sí. Los autores de Software Factories critican los limitados mecanismos de representación visual, por ejemplo, para algunos problemas puede ser más apropiado utilizar estructuras de árboles o escribir formulas matemáticas, y esto no parece ser compatible con UML. Grady Booch responde a sus críticas diciendo que la especificación de UML sólo brinda sugerencias pero no restringe las representaciones de ninguna forma. De todas maneras, la conclusión de que construir algo más especifico puede ser más apropiado sigue siendo válida. Otra crítica que se le hace a UML es que los mecanismos de extensión, como estereotipos y tagged values, son limitados. Se critica que no brindan el suficiente poder para expresar restricciones semánticas, o para definir nuevas clases de elementos. Grady Booch responde señalando que muchas restricciones semánticas pueden ser expresadas con OCL (Object Constraint Language, un lenguaje para escribir restricciones), o incluso definiendo nuevos lenguajes con MOF. Las discusiones son extensas, pero lo que en el fondo se termina cuestionando es la capacidad de UML para ser utilizado como lenguaje de modelado para problemas específicos, y no como lenguaje de propósito general. La propuesta de Microsoft consiste en un complemento de Visual Studio llamado DSL Tools, que Página 16 de 85

20 permite especificar la definición de un lenguaje (sus entidades, las relaciones, etc.) y genera un editor visual para el mismo. Junto con esta herramienta también incluye mecanismos de generación de código. Al proponer esta herramienta independiente de UML, Microsoft se ha otorgado la libertad de brindar los elementos que crea más convenientes y no tener la necesidad de cumplir con un estándar, que en su opinión no fue pensado para construir modelos ejecutables. Esto le permite darle mucha potencia al definir lenguajes de modelado, por ejemplo, es posible incluso escribir código para validar reglas semánticas o para definir cómo será la interacción entre el usuario y el editor. En síntesis, UML brinda una base conceptual importante y ampliamente reconocida para documentar modelos, sin embargo, la visión del Desarrollo Conducido por Modelos implica tener modelos que estén definidos con mucho rigor para poder traducirlos a código ejecutable. La capacidad de UML para definir restricciones complejas, o para definir comportamiento entre el usuario y los editores son limitadas, por lo que parece necesario construir nuevos mecanismos para resolver estas restricciones. Microsoft está intentando solucionar este problema con una nueva herramienta para definir lenguajes de modelado (DSL Tools). Los lenguajes creados serán los que van a utilizar los desarrolladores para escribir modelos que luego serán transformados en código ejecutable. Aún su tecnología está en desarrollo y no hay suficiente experiencia empírica para evaluar su utilidad, sin embargo, parece un camino adecuado que hacer sentir más cercana la visión del Desarrollo Conducido por Modelos Conclusiones Las Software Factories surgen como una propuesta para intentar disminuir la alta tasa de fracasos en proyectos de desarrollo de software [Bor05] y lograr alcanzar mejores niveles de productividad. Con este objetivo en mente sus autores hacen un análisis de las prácticas actuales e identifican cuatro problemas fundamentales: Construcción Monolítica, Generalidad Innecesaria, Desarrollo Aislado e Inmadurez de los Procesos. Luego, en busca de soluciones que permitan superarlos brindan un conjunto de lineamientos, denominados Innovaciones Criticas. A través de ellos se plantean sustituir el desarrollo artesanal, en el cual cada sistema se hace manualmente utilizando herramientas genéricas, y buscan aplicar un enfoque más industrial, en donde las aplicaciones se construyen ensamblando componentes prefabricados y empleando herramientas muy específicas para resolver cada requerimiento. Las Innovaciones Criticas describen cuatro áreas que se deben desarrollar para lograr dicha transición, estas son: Reuso Sistemático, Desarrollo Conducido por Modelos, Desarrollo por Ensamblado y Marcos de Procesos. La propuesta de Software Factories está basada en la convergencia de ideas. Si bien muchas de estas ideas no son nuevas, lo nuevo es su síntesis en un enfoque integrado. Su propuesta brinda una metodología que guía a expertos en un dominio a aplicar las ideas anteriores para crear lenguajes, patrones, frameworks y herramientas específicas que encapsulen su conocimiento y simplifiquen el desarrollo en ese dominio. El mayor aporte de la propuesta de Software Factories es la creación de una metodología coherente y ordenada que combina las ideas contenidas en las Innovaciones Criticas: Reuso Sistematico: La metodología obliga a pensar en el reuso cuando se está diseñando la Software Factory. Desarrollo Conducido por Modelos: Promueve la creación de lenguajes específicos de dominios (DSLs) para aumentar la productividad y facilitar el desarrollo. Desarrollo por Ensamblado: Busca crear componentes reusables por diseño, y definir relaciones formales entre consumidores y proveedores de componentes. Marcos de Procesos: Se desarrollan procesos específicos para cada tipo de aplicación y para cada vista de la arquitectura. Los procesos aplican conceptos como la planificación basa en restricciones y las guías activas. Para que la visión de Software Factories logre cumplirse los desarrolladores deben empezar a pensar distinto sobre cómo enfrentar sus problemas al emprender nuevos proyectos. Deben surgir proveedores de Software Factories, y los desarrolladores se deben aprovechar de ellas para resolver los requerimientos que tienen que satisfacer. Microsoft, como empresa formadora de opinión, está aprovechando su potencial para motivar a sus socios a trabajar en este esquema, y por otro lado está brindando herramientas que lo faciliten y estimulen. Sus autores estiman que se necesitarán entre 4 y 8 años para que su visión se materialice en la industria. Sin embargo, muchas de las ideas claves de Software Factories se pueden aplicar hoy. Para citar algunos ejemplos, ya hay disponibles herramientas de desarrollo que puedan albergar una Software Factory como Microsoft Visual Studio e IBM WebSphere Studio. También hay herramientas disponibles para construir DSLs como por ejemplo Microsoft DSL Tools y JetBrains MPS. Página 17 de 85

21 La visión de Software Factories luce prometedora, y puede marcar la forma en que se estarán construyendo aplicaciones en la próxima década. Sin embrago, probablemente su aporte más importante hoy día es crear un ámbito en donde la industria pueda discutir sus problemas desde una perspectiva teórica y buscar soluciones conjuntamente. No es posible saber si la visión de Software Factory podrá algún día aplicarse en su totalidad, pero al menos se cree que va a tener una influencia importante en la industria cuando los desarrolladores busquen soluciones para enfrentar los desafíos de la próxima década. Página 18 de 85

22 Capítulo 3 Aplicación en Sistemas de Información En el capitulo anterior se introdujo la metodología de Software Factories y las Innovaciones Críticas que promueven. Las Software Factories se basan en el reconocimiento de que difícilmente puedan encontrarse métodos generales, capaces de resolver todos los problemas de desarrollo de forma precisa. Por lo tanto, para lograr dar un siguiente paso evolutivo sobre las prácticas actuales proponen pensar en dominios más acotados. Al tener un dominio de aplicación más pequeño se pueden crear herramientas, componentes y procesos especializados, que enfrenten de mejor forma sus problemas particulares, y permitan alcanzar mejores niveles de productividad y efectividad que con métodos y lenguajes de propósito general, como RUP, UML, C# o Java. Las Software Factories surgen como una propuesta que busca ayudar a reducir la alta tasa de fracasos que hay en la Industria de Software [Bor05] y para mejorar su eficiencia. Con este objetivo sus autores concluyen que para superar las limitaciones de los métodos actuales hay que trabajar en las cuatro áreas que constituyen las Innovaciones Criticas: Reuso Sistematico, Desarrollo Conducido por Modelos, Desarrollo por Ensamblado y Marcos de Proceso. Combinando estas ideas definen una metodología, la cual indica las actividades para construir una Software Factory. A través de esta metodología integran las ideas de las cuatro Innovaciones Criticas, y este probablemente sea el aporte más importante de su propuesta. En este capítulo se describe cómo se aplicó la metodología para construir una Software Factory especializada en la construcción de Sistemas de Información. La misma plantea tres grandes grupos de actividades: Análisis, Diseño e Implementación de una Línea de Productos que sustente a la Software Factory. Dentro de este capítulo se describe cómo se realizaron las actividades de cada uno de estos grupos para definir un conjunto de herramientas, componentes y procesos específicos que simplifiquen la construcción de Sistemas de Información Por qué Sistemas de Información? En las últimas décadas el protagonismo de esta clase de sistemas ha aumentado dentro de las organizaciones. Resulta difícil hoy día encontrar una empresa que no utilice alguna clase de sistema de este tipo al desempeñar sus funciones, por ejemplo, para administrar la facturación, hacer el control de stock, registrar la contabilidad, entre muchas otras aplicaciones. En un mundo globalizado, con alto dinamismo, los Sistemas de Información se han transformado en una potente herramienta que han utilizado las empresas para aumentar su eficiencia y calidad de servicio. También ayudan a los directivos a contar con fuentes de información confiables y oportunas que les permitan tomar mejores decisiones sobre el rumbo de sus empresas. Un alto porcentaje de las aplicaciones que se desarrollan en la actualidad son Sistemas de Información, por lo tanto, se considera que vale la pena explorar si las ideas de Software Factories pueden ayudar a crear mejores formas de construirlos. Si bien a priori el alcance de la familia de productos a la que se apunta podría parecer amplio, al mismo tiempo los beneficios obtenidos tendrían un gran impacto. Esta fue la razón que motivó a escogerlos como caso de estudio para este proyecto Desarrollo de una Línea de Productos Construir una Software Factory implica definir la clase de sistema en donde se quiere aplicar y luego construir una Línea de Productos especializada que permita producirlos. La Línea de Productos busca plasmar el conocimiento que se tiene sobre el problema para identificar requerimientos comunes y definir componentes reusables, patrones de diseño, procesos de desarrollo y herramientas especializadas en él. A partir de estos elementos luego se construyen los nuevos sistemas, y si bien cada uno de ellos tendrá sus requerimientos particulares se partirá con una base que resume la experiencia previa en el tema. Las actividades principales del desarrollo de una Línea de Productos se ilustran en la Figura 3. Se utilizó el proceso definido en el Capítulo 11 del libro Software Factories [GS04]. Aquí se describen los objetivos de sus actividades, se relata cómo se realizaron y se exponen los resultados que se obtuvieron al aplicarlas en la construcción de Sistemas de Información. Página 19 de 85

23 Desarrollo de la Línea de Productos Análisis de la Línea de Productos Definición de la Línea de Productos Delimitación del Dominio del Problema Delimitación del Dominio de la Solución Diseño de la Línea de Productos Desarrollo de la Arquitectura Mapeo de los Requerimientos Definición y Automatización de Procesos Implementación de la Línea de Productos Creación de Activos de Implementación Creación de Activos de Procesos Figura 3. Actividades para construir una Línea de Productos 3.3. Análisis de la Línea de Productos El análisis de la Línea de Productos es el primer grupo de actividades que se deben realizar para construir una Software Factory. El propósito de esta fase es definir qué clase de productos se van producir, describir los aspectos comunes y las variantes que caracterizan a la familia de productos. Las actividades de esta fase son: Definición de la Línea de Productos, Delimitación del Dominio del Problema y Delimitación del Dominio de la Solución Definición de la Línea de Productos La primera actividad es identificar qué clase de problemas enfrentan los potenciales usuarios de la Software Factory para buscar ayudarlos a resolverlos. Los usuarios serán empresas de desarrollo de software, centro de cómputos o desarrolladores que construyen Sistemas de Información. Estos sistemas se utilizan para capturar información, realizar transacciones y brindar medios de consultas para obtener los datos almacenados. Generalmente se construyen para apoyar las actividades de una empresa. Se identificó la siguiente lista de problemas que implica construir un sistema de esta naturaleza: Definir un modelo de datos para registrar la información Construir interfaces que permitan ingresar datos y realizar transacciones Implementar los procesos de negocio de la empresa Diseñar consultas y reportes que brinden la información capturada y ayuden a tomar decisiones Implementar cálculos y transformaciones sobre los datos Construir un componente que permite administrar los usuarios del sistema Definir menús de acceso para cada usuario dependiendo de su proceso Interactuar con otros sistemas para enviarles información, realizar consultas o realizar operaciones sobre ellos Dado un sistema concreto seguramente aparezcan necesidades adicionales, como por ejemplo, interfaces orientadas a dispositivos móviles o generación de registros de auditoría. Se definió esta lista identificando un conjunto de problemas básicos, priorizando los más comunes de forma que la Software Factory tenga un alcance de aplicación más amplio, y se dejaron de lado aquellos que se consideraron menos frecuentes Delimitación del Dominio del Problema La Software Factory no puede resolver todos los problemas del dominio, debido fundamentalmente a limitaciones de tiempo y recursos en el proyecto. Además, no todas las soluciones son generalizables para una familia de productos, algunas deberían estudiarse para un producto concreto. Por lo tanto, para definir el alcance de la Software Factory se deben identificar funcionalidades comunes para la familia en las cuales se puedan implementar componentes reutilizables. Luego, para aquellas que varían de producto en producto se podrán definir herramientas y procesos que ayuden a construirlos. En esta actividad se identificaron problemas comunes y opcionales para la familia de productos, y se definieron cuáles eran los problemas que se iba a intentar resolver. Para esta definición se tuvo en cuenta los Página 20 de 85

24 recursos y tiempos asignados al proyecto, y se priorizaron las funcionalidades más generalizables con mejor relación costo/beneficio. Los problemas que intenta resolver la Software Factory son: Definición de interfaces de ingreso de datos y consultas Integración con Sistemas de Workflow para definir los procesos de negocio de la empresa Invocación de programas de cálculos y transformaciones desde la interfaz de usuario Administración de usuarios en el sistema Creación de menús de acceso por perfil de usuario Un aspecto importante de los Sistemas de Información es su Modelo de Datos, sin embargo como se observa no se incluyó en el alcance de la Software Factory. Cabe recordar que uno de los requerimientos del proyecto es extender GeneXus, que es una herramienta especializada para definir aplicaciones orientadas a datos. Se consideró que ésta ya brinda buenas soluciones para definir el Modelo de Datos, y que no había demasiado para ganar aquí, por lo tanto, este problema no se incluyó dentro del alcance y se prefirió dar prioridad a otros, como la interacción entre los usuarios y los datos. En base a la experiencia que se tiene en la construcción de Sistemas de Información se concluyó que se invierte gran parte del tiempo diseñando interfaces de usuario para mostrar datos, o para hacer altas, bajas y modificaciones. Por lo tanto se consideró que estos son los problemas principales a los que debía apuntar la Software Factory. Luego, se buscó brindar lenguajes y herramientas más especializadas que permitan resolver estos requerimientos (en el Capítulo 4 se hace un análisis detallado de los DSLs que se construyeron para este fin). A continuación se enumeran brevemente otras decisiones tomadas para definir el alcance: Si bien se identificó que uno de los problemas de construir Sistemas de Información era representar los procesos de negocio de una empresa, ya existen productos especializados para resolver estos requerimientos: los Sistemas de Workflow. Por lo tanto, la Software Factory no necesita implementar uno nuevo, pero sí debe facilitar la integración con uno ya existente, para promover el Desarrollo por Ensamblado. La administración de usuarios y menús, es un requerimiento muy común y que presenta muchas similitudes entre los distintos sistemas, por lo tanto se incluyó dentro del alcance. Debido a las limitaciones de recursos y tiempo en el proyecto hubo que reducir el alcance en los otros puntos. Dentro de los problemas iníciales aparecían tanto consultas como reportes, se incluyeron únicamente las consultas ya que ambos sirven para obtener información del sistema. Finalmente, con respecto a la interacción con otros sistemas (típicamente a través de Web Services) se categorizó como requerimiento opcional, ya que no aparece en todos los Sistemas de Información. Además GeneXus ya brinda componentes y herramientas especializadas para resolverlos, así que también se excluyó del alcance Delimitación del Dominio de la Solución En la actividad anterior se definió qué problemas se iba a intentar resolver, en esta actividad se define qué brindará la Software Factory para hacerlo. Aquí se determinan los requerimientos de la Línea de Productos, y se definen las funcionalidades comunes y variables entre los productos que se espera producir. Las actividades anteriores se enfocaron en definir el propósito de la Software Factory, preocupándose de resolver problemas del mundo real. Esta actividad en cambio se enfoca en los productos ejecutables que se deben crear, imponiendo requerimientos funcionales y no funcionales sobre ellos para resolver los problemas identificados. Utilizando esta definición luego se diseña la Línea de Productos para permitir construirlos. Requerimientos comunes para los productos producidos: Brindar un diálogo de inicio de sesión que permita ingresar al sistema Presentar un menú de opciones que se cargue según el perfil del usuario Incluir una barra de navegación que muestre la secuencia de páginas visitadas para llegar a la actual, y permita volver a una de las anteriores Validar que haya un usuario con una sesión válida antes de mostrar cada página Definir una estética uniforme y consistente para la interfaz de la aplicación Brindar un modelo de ejecución robusto y escalable, que permita actualizar y mantener las aplicaciones sin tener que instalar actualizaciones manualmente en todas las terminales que lo usen Página 21 de 85

25 Requerimientos opcionales: Brindar una bandeja de tareas que permita iniciar nuevos procesos de negocio y administrar las tareas de un usuario (Workflow) Adicionalmente, cada producto debe definir sus ingresos de datos, consultas y procesos de cálculo. Si bien la Software Factory es responsable de ayudar a implementar estas funcionalidades, los requerimientos de este tipo son particulares para cada producto y no pueden incluirse aquí. Por lo tanto, si bien no aparecen en la lista de requerimientos para la Línea de Productos, más adelante se diseñan procesos y herramientas que ayuden a resolverlos Diseño de la Línea de Productos Ahora que ya está definido el propósito y los requerimientos para la Línea de Productos, se puede comenzar a diseñarla. El propósito del diseño de la Línea de Productos es definir cómo la Software Factory va a producir los productos definidos. Las actividades de esta fase son: Desarrollo de la Arquitectura, Mapeo de los Requerimientos y Definición y Automatización de Procesos Desarrollo de la Arquitectura En esta actividad se define la arquitectura de la Línea de Productos, en la cual se describen las características comunes del diseño de alto nivel para los productos que se construyan con ella. Esta definición incluye una partición entre componentes, la asignación de responsabilidades y definición de contratos en los componentes, las relaciones e interacciones entre los componentes, y la tecnología que se utiliza para implementar cada uno de ellos. La arquitectura de la Línea de Productos es similar a la arquitectura de un producto individual, sin embargo, debe contemplar variaciones entre los distintos miembros de la familia de productos que se construyen. Es decir, debe distinguir entre aspectos comunes y variables del diseño. <<aplicación>> Servidor Web Entorno Usuario Framework <<aplicación>> Navegador HttpProtocol <<externo>> Componentes Particulares SqlLanguage <<aplicación>> Base de Datos <<opcional>> Consola de Workflow <<opcional>> Motor de Workflow Figura 4. Arquitectura de la Línea de Productos En la Figura 4 se representa (en UML 2.0 [Fow04]) la arquitectura para la Línea de Productos definida. Se utiliza una arquitectura Web tradicional, en ella se definen los siguientes componentes: Entorno Usuario: Tiene la responsabilidad de brindar una página de inicio de sesión, un menú y una barra de navegación. Brinda el entorno que complementa las páginas de la aplicación para facilitar la interacción de los usuarios con ellas. Página 22 de 85

26 Framework: Dentro de este componente se administran los usuarios, se arma el menú según el perfil, se controla la seguridad en las páginas y se administra el flujo de navegación. Este componente brinda programas de soporte que implementan el sistema de usuario y encapsulan código de infraestructura que se repite en las distintas páginas de la aplicación. Componentes Particulares: Este no es un componente en sí mismo, sino que representa los componentes que defina un producto particular de la familia de productos. Se incluyó en la representación de la arquitectura para resaltar que estos componentes utilizan el componente Framework, por ejemplo, para validar que haya una sesión activa antes de mostrar cada página o para registrar los datos de la página en la barra de navegación. Consola de Workflow: Permite administrar las tareas asignadas a un usuario e iniciar nuevos procesos en el Sistema de Workflow. Este componente no es requerido para todos los miembros de la familia de producto, sólo estará en aquellos que necesiten automatizar procesos de negocio. Motor de Workflow: Se encarga de administrar las tareas de los procesos activos. Por ejemplo, cuando un usuario finaliza una tarea este componente se encarga de determinar cuál es la siguiente tarea a ejecutar y qué usuarios están habilitados para realizarla. Servidor Web: Los productos de la familia se ejecutaran dentro de un servidor Web. Se escogió este modelo de ejecución debido a su escalabilidad, robustez, ubicuidad y capacidad de realizar actualizaciones en la aplicación únicamente actualizando los programas en el servidor. Adicionalmente, GeneXus Rocha (el entorno para el cual se desarrolló la Software Factory) no soporta aplicaciones con interfaz de ventana en la versión utilizada durante este proyecto. Navegador: Representa un navegador para acceder a las páginas Web (por ejemplo, Internet Explorer o Firefox) Base de Datos: Representa a un servidor de Base de Datos. Para los componentes Consola y Motor de Workflow se utiliza GXFlow, un producto distribuido por los mismos fabricantes de GeneXus. Se escogió este producto debido a su fácil integración con la herramienta de desarrollo. El resto de los componentes son particulares para cada Sistema de Información o son aplicaciones, por lo tanto, dentro de la Línea de Productos únicamente será necesario implementar los componentes Entorno Usuario y Framework. Finalmente, para completar la definición de la arquitectura se identificó cómo los componentes de la arquitectura se corresponden con la tecnología disponible. Debido al uso de GeneXus como lenguaje de desarrollo, los productos producidos por la Software Factory no quedan asociados a una tecnología en particular, sino que es posible ejecutarlos en todas las tecnologías para las cuales GeneXus es capaz de generar código. Sin embargo, para simplificar la verificación se impusieron una serie de tecnologías concretas sobre las que se realizaron las pruebas. Si bien otras tecnologías podrían ser soportadas con poco esfuerzo, sería necesario volver a probar todos los componentes para garantizar su correcto funcionamiento, y se prefirió concentrar el tiempo de este proyecto en otras actividades, como el desarrollo de DSLs. Las tecnologías utilizadas son: Base de Datos: Microsoft SQL Server Servidor Web: Internet Information Server 6.0, utilizando.net 2.0. La comunicación con la base de datos se realiza utilizando ADO.NET. Navegador: Firefox. Motor de Workflow: GXFlow Mapeo de los Requerimientos El objetivo de esta actividad es determinar cómo se corresponden las variabilidades en los requerimientos de la Línea de Producto con las variabilidades dentro de la arquitectura. Esta correspondencia muestra cómo debe ser implementada cada funcionalidad variable si es seleccionada para una instancia particular de la familia de productos. Adicionalmente, en esta actividad se debe validar que todos los requerimientos sean contemplados dentro de la arquitectura. El único requerimiento opcional que se impuso sobre la Línea de Productos fue la capacidad de iniciar procesos y administrar las tareas de un usuario a través de un Sistema de Workflow. Si se desea aplicar este requerimiento simplemente se deben agregar los componentes de GXFlow. Estos componentes se integran naturalmente dentro de GeneXus y permiten asociar objetos creados con esta herramienta para ejecutar en Página 23 de 85

27 las tareas de los procesos. Adicionalmente, dentro de la Software Factory se incorporaron herramientas de desarrollo que facilitan esta integración (ver sección Workflow), aunque éstas apuntan a asistir el proceso de desarrollo y no se representan con componentes específicos de la arquitectura. Otro aspecto que también está ligado al proceso de desarrollo es la construcción de la interfaz de usuario. Esto puede ser visto como otra variabilidad, ya que las interfaces dependerán del producto concreto que se construya. Dentro del componente Framework se definieron rutinas que deben ser invocadas desde las interfaces para poder lograr un comportamiento consistente entre ellas. Esta integración se realiza a través de DSLs que asisten la construcción de interfaces durante la creación de un Sistema de Información concreto, como se verá a continuación Definición y Automatización de Procesos En esta actividad se busca definir procesos específicos para construir los miembros de la familia de forma de aprovechar los activos de la Software Factory y que estén optimizados para el tipo de producto que se construye. Al comenzar a definir la Softwate Factory se definió una lista de problemas que ésta debía apuntar a resolver. Algunos de ellos se pudieron trasladar directamente a la arquitectura, como la administración de usuarios y menús, sin embargo, también se identificaron otros que están vinculados al proceso de desarrollo, como la construcción de interfaces de ingreso de datos y consultas. Para afrontar estos requerimientos se definieron procesos específicos de la Línea de Productos, y en donde fue posible se incluyeron herramientas y automatismos que simplifiquen las tareas. En la sección Marcos de Procesos se introdujo este concepto. Allí se definió un Marco de Proceso como un conjunto de microprocesos, cada uno diseñado específicamente para construir elementos parciales (artefactos) que se utilizan para elaborar los miembros de la familia. Con los miroprocesos se busca diseñar procesos altamente especializados que permitan construir cada uno de los elementos intermedios necesarios para elaborar el producto. Junto a este concepto se introdujo el de Planificación Basada en Restricciones, que propone lo siguiente. En lugar de definir un proceso con una secuencia de actividades fija, se identifican los artefactos que se deben producir durante el proceso de desarrollo, se definen microprocesos para producir cada uno de éstos, y se indican las restricciones de cada microproceso (como por ejemplo, los artefactos que se necesitan como entrada). Con este modelo se busca definir un proceso flexible, que se pueda adaptar de forma dinámica utilizando el flujo que refleje mejor las necesidades del proyecto, siempre y cuando se satisfagan las restricciones. Se construyó la Software Factory tomando como referencia la lista de problemas que busca resolver. Al analizar estos problemas para definir los procesos se concluyó que éstos estaban principalmente vinculados a las fases de diseño e implementación. Si bien un proceso de desarrollo completo también incluye otras fases como análisis y verificación, se concluyó que en el diseño y la implementación era donde había más para aportar. Por lo tanto, se concentraron los esfuerzos en definir microprocesos para los artefactos que se construyen allí. Se identificaron los siguientes artefactos: Modelo de Datos: Define las tablas, atributos y relaciones de los datos que se van a almacenar dentro del Sistema de Información. Procedimientos: Representan a los objetos GeneXus en donde se implementan transformaciones sobre los datos y se realizan cálculos. Navegaciones: Definen las páginas que componen la aplicación, los datos que se muestran o se modifican en cada una de ella, y las rutas que indican cómo se puede llegar de una a otra. Dentro de las navegaciones también se pueden asociar operaciones invocables desde las páginas. Especificaciones de Formularios: Brindan una especificación de los datos que definen al formulario de cada página, es decir, la lista de atributos que se muestran, los controles que se utilizan, las etiquetas que se asocian a cada campo o columna en caso de que se presente una grilla, etc. WebPanels y Transacciones: Representan los objetos GeneXus utilizados para definir páginas Web, y a partir de los cuales se generan los ejecutables. Se pueden generar a partir de una especificación con el formulario que definen. Menús: Define la lista de elementos que se muestran en los menús, indicando el perfil al que está asociada cada opción (si el usuario no tiene dicho perfil no se le mostrará la opción). Los menús se Página 24 de 85

28 construyen a partir de las navegaciones, ya que el menú es el punto de entrada que permite ir a la primera página de una navegación. Ejecutable: Define los archivos que pueden ser ejecutados dentro de un servidor Web para utilizar el Sistema de Información construido. Procesos: En caso de incluir Workflow, este artefacto representa los procesos de la organización que utilizará el sistema. Un proceso se define como una secuencia de tareas y rutas que indican cuál es el siguiente paso luego que se completa una tarea. Dentro de la definición también se pueden utilizar otros elementos soportados por GXFlow como condicionales y bifurcaciones. Dentro de una tarea hay que asociar un objeto a ejecutar, dicho objeto generalmente será la página inicial de una navegación. En la Figura 5 se muestra un grafo dirigido con los artefactos y las entradas requeridas para cada uno de ellos. Por ejemplo, para realizar las navegaciones se necesita el Modelo de Datos del cual se obtienen las tablas con que se trabaja en cada página. Adicionalmente, se podrían requerir los procedimientos si se quiere permitir invocar alguna operación desde una página. Cabe destacar que el proceso no es estrictamente secuencial, sino que debe ser realizado de forma iterativa e incremental. Por ejemplo, para comenzar a realizar las navegaciones no es necesario tener el Modelo de Datos completo, sino que sólo se requieren las tablas que se van a utilizar. De la misma forma una navegación sólo necesita que los procedimientos estén definidos si se quiere referenciar alguno de ellos, pero no tienen que estar todos implementados para comenzar a hacer las navegaciones. Mientras se están diseñando las navegaciones se pueden definir únicamente los parámetros del procedimiento para poder referenciarlos, y posteriormente escribir la implementación completa cuando se necesite obtener el ejecutable. Procesos Modelo de Datos Menús Navegaciones Especificaciones de Formularios WebPanels y Transacciones Ejecutable Procedimientos Figura 5. Artefactos con sus entradas Al diseñar el proceso de desarrollo para los productos producidos con la Software Factory, se buscó identificar aspectos donde se pudieran definir herramientas y automatismos que simplificaran las tareas. Aquí se intentó aplicar el concepto de Desarrollo Conducido por Modelos para diseñar lenguajes específicos que permitan construir algunos de los artefactos identificados: Modelo de Datos: Previamente se mencionó la utilización de GeneXus para este punto, y que la definición del Modelo de Datos no se incluyó en el alcance por considerar que había más para aportar en los otros problemas. GeneXus ya brinda abstracciones específicas para definir el Modelo de Datos: las transacciones. Navegaciones: Las navegaciones son generalmente mejor comprendidas a través de diagramas, por eso pareció natural aquí crear un lenguaje gráfico que permita definirlas. Se diseñó entonces un lenguaje basado en diagramas para tal fin. En el Capitulo 4 se brinda una descripción detallada de cómo se diseñó este lenguaje, el cual constituye una de las piezas más importantes de la Software Factory, ya que prácticamente a partir de las navegaciones y el Modelo de Datos es posible generar el resto de los artefactos y construir una aplicación ejecutable. Página 25 de 85

29 Especificaciones de Formularios: Aquí se definió un lenguaje formal para realizar las especificaciones, de forma que se pueda construir un generador que lea esta especificación y la transforme en un WebPanel o Transacción. WebPanels y Transacciones: Si bien aquí no se brinda un lenguaje especificó, se detectó que hay muchos segmentos de código que se repiten en los WebPanels y Transacciones que se definen para representar la interfaz de usuario. Por este motivo, se proporcionan plantillas con patrones de código que encapsulan estos segmentos repetitivos y permiten generarlos completamente. Menús: Para simplificar la definición de menús, aquí también se brinda un lenguaje especifico en donde se enumeran las opciones disponibles. Luego, a partir de esta especificación, se genera el código para cargar el menú. Procesos: Los procesos se especifican utilizando GXFlow. Esta herramienta permite utilizar diagramas de actividad UML para este fin, por lo tanto, no se consideró necesario definir un nuevo lenguaje. En definitiva para la Software Factory se construyeron DSLs para definir la navegación, la especificación de los formularios y los menús. Adicionalmente, se implementaron plantillas de código y librerías para generar código ejecutable para los WebPanels, las Transacciones y el menú. A partir de los DSLs mencionados se busca que todos los artefactos queden definidos dentro de GeneXus. Al utilizar lenguajes formales para especificar los artefactos, éstos pueden ser interpretados por generadores que construyan los artefactos que dependen de ellos de forma parcial o total. Si se utilizaran documentos externos para definir los artefactos habría que invertir tiempo en traducir el contenido de éstos a un lenguaje capaz de ser traducido a código ejecutable. Adicionalmente, ante cambios en la implementación habría que actualizar los documentos. Con el enfoque planteado, al tener todos los artefactos dentro de la herramienta de desarrollo, se pueden construir mecanismos que los mantengan sincronizados automáticamente. Dentro de la propuesta de Software Factories de Microsoft [GS04], el Desarrollo Conducido por Modelos es una pieza fundamental, por lo tanto se dedicó gran porcentaje del tiempo a diseñar DSLs que permitan construir Sistemas de Información, y también a estudiar cómo implementarlos (en los Capítulos 4 y 5 se describen detalladamente estos puntos) Luego de haber definido e implementado estos componentes se completó el trabajo documentando un proceso para construir Sistemas de Información aprovechando la Software Factory (ver el documento Manual de Proceso [Cas07] que se entrega junto con este informe) Esquema Uno de los objetivos del grupo de actividades de Diseño la Línea de Productos es definir el esquema de la Software Factory. Recordar que el esquema es similar a una receta en donde se enumeran sus activos (ver sección Esquema). Aquí se indican los elementos que hay que implementar para construir la Línea de Productos. Se resume a continuación el esquema indicando los activos identificados en las actividades anteriores, agrupándolos en vistas: Vista de Procesos: Proceso de Construcción Vista de Diseño: DSL para Navegaciones DSL para Especificación de Formularios DSL para Menús Vista de Implementación: Plantillas para generar implementaciones Ejecución: Entorno Usuario Framework 3.5. Implementación de la Línea de Productos Luego de terminar el Diseño de la Línea de Productos se pasa a la Implementación. Aquí se realiza un grupo de actividades cuyo objetivo es proveer los activos de implementación requeridos por la arquitectura de la Línea de Productos y los activos de procesos requerido por la definición y automatización de procesos. Es decir, se implementa el esquema de la Software Factory y así se construye la plantilla de la Software Factory. Página 26 de 85

30 Recordar nuevamente, que si el esquema es como una receta, la plantilla sería la bolsa del supermercado que contiene los ingredientes de la lista (ver sección Plantilla). Las actividades de esta fase son: Creación de Activos de Implementación y Creación de Activos de Procesos Creación de Activos de Implementación El propósito de esta actividad es implementar los componentes requeridos en la arquitectura para construir miembros de la familia de productos. Al definir la arquitectura se identificaron dos componentes para implementar: Entorno Usuario y Framework. También se incluyeron dos componentes opcionales: Consola de Workflow y Motor de Workflow. Sin embargo, para proveerlos se utilizó un producto externo (GXFlow) por lo tanto no fue necesario implementarlos. La implementación se realizó utilizando código GeneXus, para que pueda ser generado en cualquiera de las plataformas y bases de datos que soporta. De esta forma, el mismo código puede ser transformado a Java con MySql y también a C# utilizando Microsoft SQL Server. En la implementación se utilizó GeneXus Rocha (el nombre código de versión que sucederá a la 9.0). Se utilizaron versiones denominadas CTP (Community Technology Review), que son versiones previas a las betas, funcionalmente incompletas, y que tienen el objetivo de mostrar a los usuarios cómo será la próxima versión antes que esté terminada. Se utilizó la versión Rocha ya que esta incluye nuevos mecanismos de extensión necesarios para implementar los DSLs. A partir de esta versión se permite definir nuevos tipos de objetos, diseñadores y otras herramientas que se integran dentro del entorno de desarrollo. El uso de versiones CTP provocó retrasos importantes durante la implementación, ya que hasta la CTP4 (liberada el 17 de abril del 2007) no se logró tener una versión estable capaz de generar una aplicación funcional completa. De cualquier forma, se pudo comenzar la implementación con la CTP3, terminando la misma con la CTP4. Luego de haber culminado el desarrollo se liberó la CTP5 con cambios que hicieron a la Software Factory incompatible con ella. Se trabajó entonces en actualizar el código para ofrecer una implementación que fuera potencialmente compatible con la versión final de GeneXus Rocha. Al realizar la migración se encontraron errores en GeneXus que fueron corregidos en Night Builds posteriores. Los Night Builds son versiones intermedias a los CTP que se liberan todas las noches y contienen los cambios realizados hasta la fecha. En el Night Build 7097 (correspondiente al 19 de agosto del 2007) se solucionaron todos los problemas encontrados, y fue con la última versión que se probó la Software Factory. Cabe destacar que se tuvo un aporte muy valioso de parte del equipo de desarrollo de GeneXus, que brindó soporte y corrigió rápidamente los errores que se fueron reportando Creación de Activos de Procesos La actividad anterior se enfocó en la creación de los activos que forman parte de la arquitectura de la Línea de Productos. Esta actividad en cambio, se encarga de definir los procesos e implementar las herramientas que ayudan a construir los productos de la línea, como por ejemplo, los DSLs. En esta actividad se invirtió la mayor parte del tiempo del proyecto. Como se mencionó previamente, uno de los puntos claves de la propuesta de Software Factories es el Desarrollo Conducido por Modelos. Por lo tanto, se consideró una buena oportunidad en este proyecto para experimentar con este concepto y observar sus beneficios con una implementación concreta. En el Capitulo 4 se describe de forma detallada cómo se diseñó el DSL para representar las navegaciones. Luego, en el Capitulo 5, se presenta la arquitectura que se utilizó para implementar los DSLs de la Software Factory, describiendo los problemas que hubo que enfrentar y las decisiones que se tomaron para resolverlos. La construcción de DSLs fue la tarea principal que se realizó en esta actividad. Luego de completarla se dedicó tiempo a documentar un proceso que indique cómo utilizar los DSLs para construir un Sistema de Información (ver Manual de Proceso [Cas07]). Con la creación de este documento se completó la implementación de la Software Factory. Página 27 de 85

31 3.6. Conclusiones En el capitulo anterior se presentó la propuesta de Software Factories [GS04] y se brindó un resumen de cuáles son los problemas que pretende resolver y cómo aspira a hacerlo. En este capítulo se aplicaron estos conceptos con un caso concreto, la construcción de Sistemas de Información. Para crear la Software Factory se aplicó el proceso que sugieren sus autores, y en este capítulo se describió cómo se realizaron cada una de sus actividades. Este proceso se compone de tres grupos de actividades: Análisis, Diseño e Implementación de la Línea de Productos; que permite construir los miembros de la familia. Durante el análisis, se identificaron los problemas que aspira resolver la Software Factory. Allí se indicó que se consideraba que GeneXus brinda buenas herramientas para definir el Modelo de Datos, y por lo tanto que era más interesante estudiar el problema de la interacción entre los usuarios y los datos. En la etapa de diseño se definió la Arquitectura de la Línea de Productos, la cual identifica los componentes comunes y opcionales para los productos que se construirán. Dentro de los componentes comunes se incluyó el entorno de trabajo y la administración de usuarios y menús. Como componentes variables se agregó la posibilidad de incluir tecnología de Workflow, habiendo decidido utilizar GXFlow debido a su natural integración con GeneXus. Al diseñar la Línea de Productos también se identificaron una serie de DSLs que se definen para simplificar el proceso de construcción. Los modelos creados con estos DSLs quedan dentro de las Bases de Conocimiento GeneXus. De esta forma, se pueden construir generadores que a partir de ellos elaboren otros artefactos de forma parcial o total. En particular, se mencionó que durante la implementación se buscó que a través del Modelo de Datos y los Diagramas de Navegación se pueda generar una aplicación ejecutable sin necesidad de escribir código. Finalmente, en la etapa de implementación se construyeron los componentes de la arquitectura, los DSLs y un proceso para guiar a los desarrolladores en el uso de la Software Factory. Durante la implementación se consideró que el proyecto brindaba una oportunidad interesante para experimentar con el concepto de Desarrollo Conducido por Modelo. Por lo que se dedicó una gran parte del mismo a diseñar e implementar los DSLs, de forma de obtener un caso práctico que permita explorar sus beneficios, conocer las dificultades de implementar este concepto y proponer algunas posibles soluciones. Como conclusión, se considera que la metodología propuesta en el libro de Software Factories [GS04] brindó una guía ordenada que permitió crear una Software Factory para Sistemas de Información. Los autores de este libro plantean una visión de una Industria de Software en donde haya empresas proveedores de componentes y herramientas especializadas para que otras se aprovechen de estas. Para lograr esta visión mencionan que se debe innovar en cuatro áreas críticas: Reuso Sistematico, Desarrollo Conducido por Modelos, Desarrollo por Ensamblado y Marcos de Procesos. A través de la metodología propuesta se brinda un conjunto de actividades que permitieron combinar estas cuatro ideas de forma consistente para construir herramientas, componentes y procesos altamente especializados para un problema específico. Este enfoque, en la práctica, ayudó a brindar un método de desarrollo más sencillo y elegante para construir Sistemas de Información (aunque con limitaciones), como se verá en el siguiente capítulo. Página 28 de 85

32 Capítulo 4 Diseño de un Lenguaje Específico Se comenzó este trabajo estudiando las ideas que promueve la iniciativa de Software Factories. A diferencia de las herramientas de desarrollo de propósito general, una Software Factory se define para implementar una clase particular de productos con un alcance más acotado. Brindan herramientas, procesos y contenidos que están altamente optimizados para la clase de productos en que se especializa, aprovechando sus particularidades y resumiendo el conocimiento de expertos en su dominio. En el capitulo anterior se describieron las actividades y tareas realizadas para construir una Software Factory para Sistemas de Información. El proceso comenzó definiendo los problemas que se intentaban resolver. Allí se indicó que GeneXus ya brinda buenas herramientas para definir el Modelo de Datos, y se consideró que había más para ganar en la interacción entre los usuarios y los datos. Luego de completar el análisis se pasó al diseño. Dentro de este grupo de actividades la primera tarea fue definir la arquitectura base para los Sistemas de Información a construir; otra tarea importante fue definir procesos y herramientas que ayuden a crear estos sistemas. Este capítulo se enfoca en el diseño de dichas herramientas. Aquí se describe cómo se diseñó un lenguaje gráfico para representar requerimientos típicos de un Sistema de Información desde el punto de vista de la interacción de los usuarios con los datos Definiciones Para encontrar aspectos comunes y características específicas de los Sistemas de Información se comenzó buscando definiciones que permitan describirlos con precisión. Algunas definiciones posibles: Daniel Cohen y Enrique Asín definen a un Sistema de Información como un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio [CA00]. Por otro lado, Kenneth Laudon y Jane Laudon los definen como un grupo de componentes interrelacionados que capturan, almacenan, procesan y distribuyen la información para apoyar la toma de decisiones, el control, análisis y visión en una institución [LL96]. En la WikiPedia se encuentra una definición más amplia que combina a las anteriores, allí se define como un conjunto de funciones o componentes interrelacionados que forman un todo, es decir, obtiene, procesa, almacena y distribuye información (datos manipulados) para apoyar la toma de decisiones y el control en una organización. Igualmente apoya la coordinación, análisis de problemas, visualización de aspectos complejos, entre otros aspectos [Wik]. La primera definición ayuda a comprender el motivo por el cual se construyen estos sistemas. Sin embargo, a partir de las otras se puede obtener una enumeración más precisa de sus funciones, que permita identificar abstracciones específicas. De ellas se puede extraer que los Sistemas de Información realizan cuatro operaciones básicas: captura (o entrada), almacenamiento, procesamiento y distribución (o salida) de información. La entrada de información es el proceso en el cual se ingresan los datos que se quieren almacenar o procesar al sistema. La entrada puede ser manual o automática. Las entradas manuales son aquellas en que una persona ingresa directamente los datos, por ejemplo, a través de interfaces de usuario o dispositivos específicos para tal fin (como escáneres). En las automáticas los datos son tomados de otros sistemas o dispositivos a través de interfaces de comunicación (por ejemplo, utilizando Web Services) o leyendo archivos de intercambio de datos (por ejemplo, el Sistema de Facturación puede generar un archivo XML con las facturas del mes para que puedan ser leídas por el Sistema de Clientes). Luego que se ingresan los datos se deben almacenar en medios durables, capaces de retener la información para que luego pueda ser procesada o consultada. Esta es la segunda operación básica de un Sistema de Información, el almacenamiento. Para este propósito generalmente se utilizan Bases de Datos, ya que brindan buenas soluciones para afrontar esta necesidad. Los Sistemas Gerenciadores de Bases de Datos (SGBD, o DBMS en ingles) ayudan a garantizar la consistencia de los datos a través de transacciones y brindan lenguajes de consulta para accederlos (SQL y XQuery). También pueden ser acompañados de componentes adicionales de hardware (por ejemplo cintas) para respaldar la información y evitar pérdidas ante fallas de hardware o de software. Página 29 de 85

33 La tercera operación básica identificada es el procesamiento de los datos. La misma define la capacidad de un sistema para realizar transformaciones y cálculos sobre los datos ingresados. A través de operaciones de procesamiento los Sistemas de Información pueden ser capaces de generar información de mucha utilidad para la toma de decisiones (por ejemplo, estadísticas de los productos más vendidos o proyecciones del uso de las materias primas). Finalmente se tienen las operaciones de salida. Las operaciones de este tipo son las que permiten consultar los datos registrados en el sistema. Aquí se pueden incluir consultas capaces de ser invocadas por los usuarios, generación de reportes y también interfaces de comunicación que permiten trasmitir daros a otros sistemas. Las salidas podrían ser aplicadas tanto a datos resultantes de procesamientos y transformaciones (como estadísticas), o a datos en la misma forma que fueron ingresados (como el nombre, apellido y dirección de los clientes registrados). En resumen, se identificaron cuatro clases de operaciones típicas para un Sistema de Información: entradas, almacenamiento, procesamientos y salidas de datos. Esta categorización por un lado define características comunes, y por otro brinda un marco de referencia para comenzar a buscar abstracciones de alto nivel sobre ellas y diseñar un lenguaje para representarlas DSL Un DSL (Domain Specific Lanaguage) es un lenguaje que se diseña para resolver un conjunto específico de tareas. Se focaliza en problemas dentro de un dominio particular sin pretender brindar soluciones para los problemas que están afuera de éste. En contraste, un lenguaje de propósito general (como Java, C# o UML) aspira a ser útil para resolver problemas un muchos dominios. A través de los DSL la Software Factory debía entonces proponer modelos que contengan abstracciones específicas para las operaciones identificadas, y así simplificar su desarrollo. Antes de buscar estas abstracciones, se definieron los objetivos buscados y el alcance, indicando qué operaciones se iban a estudiar y con qué grado de detalle. Luego se realizó un análisis más profundo de cada operación seleccionada para poder detectar patrones en ellas, y finalmente se definió un lenguaje gráfico (un DSL) para poder aplicar estos patrones Objetivos Los objetivos de diseño del DSL fueron: Brindar abstracciones especificas para construir Sistemas de Información simples Facilitar la traducción de los requerimientos a componentes ejecutables Promover el uso de patrones para resolver las operaciones típicas Generar un porcentaje grande de la aplicación a partir de modelos de alto nivel Al construir un Sistema de Información generalmente se comienza por hacer una especificación de sus requerimientos y luego se traducen esos requerimientos a componentes ejecutables que resuelvan las necesidades de sus usuarios. Este DSL está destinado a la segunda etapa, es decir, a facilitar la traducción de los requerimientos a programas ejecutables. Se planteó como objetivo del DSL proporcionar patrones y componentes prefabricados que ayuden a resolver los requerimientos típicos de un Sistema de Información. De esta forma, la implementación de un gran porcentaje de las funcionalidades se podrá obtener aplicando patrones y configurando componentes, y sólo será necesario escribir código para unos pocos casos particulares. Esta es la visión del DSL que se buscó diseñar. Cabe destacar que el DSL aspira a construir Sistemas de Información simples, eso significa que no se intentó resolver toda la complejidad que puede implicar un sistema comercial. Esto requeriría un equipo más grande y más tiempo del que tenía asignado este proyecto. Por este motivo el DSL se enfocó en ayudar a resolver las funcionalidades más comunes y brindar puntos de extensión para que los requerimientos complejos se puedan implementar manualmente sin el DSL. Al reducir el alcance, se le pudo dar más énfasis al carácter de investigación del proyecto. En lugar de invertir demasiado tiempo para contemplar funcionalidades complejas, se pudo también dedicar tiempo a probar soluciones para los problemas que implica implementar un DSL, las cuales se resumen en el siguiente capítulo. Página 30 de 85

34 Familia de Productos Luego de definir los objetivos del DSL, se definió su dominio de aplicación delimitando la familia de productos que permite generar. La misma está comprendida por Sistemas de Información que tengan las siguientes características: Registran y leen información de una base de datos relacional y se ejecutan sobre plataforma Web. Sus principales funciones son: Ingresos de datos: Que se pueden definir como altas, bajas y modificaciones sobre una o más tablas, y sus reglas de negocio son expresables en Transacciones GeneXus. Consultas: Que se pueden definir como navegaciones sobre el Modelo de Datos y condiciones que filtren el resultado Transformaciones y otras operaciones: Que se puedan escribir en procedimientos GeneXus. El DSL brinda abstracciones de alto nivel para construir rápidamente instancias de la familia de productos que se caracterizó. Sin embargo, para no ser demasiado restrictivos, se exponen puntos de extensión que permitan utilizar GeneXus de forma tradicional para implementar las funcionalidades que no son definibles en el DSL (por ejemplo, interfaces de usuario complejas, o procesos de cálculo). En definitiva, el DSL busca facilitar la construcción de instancias de una familia de productos en particular, pero también proporciona flexibilidad para no restringir su uso sólo a sistemas que se pueden escribir completamente con él. Típicamente, el DSL permite construir gran parte de la aplicación a través de modelos de muy alto nivel, y se puede utilizar GeneXus para implementar las funcionalidades en las que no se especializa GeneXus Rocha Como se definió en el capitulo anterior, una Software Factory configura una herramienta de desarrollo con componentes específicos para una clase de problemas (ver sección Qué es una Software Factory?). Para poder hacerlo se necesita de una herramienta extensible, que permita incorporar componentes externos más allá de los que vienen incluidos originalmente en el producto. GeneXus, en la versión de nombre código Rocha, ha atravesado una reingeniería completa de su entorno de desarrollo, y una de sus características más destacable es la potencia de sus nuevos mecanismos de extensión, los cuales la hacen muy adecuada para construir una Software Factory sobre ella. El proyecto brindó una experiencia en el desarrollo de una extensión, y también permitió probar esta nueva versión. Cabe destacar que se utilizaron versiones denominadas CTP (Community Technology Preview). Estas son versiones previas a las Betas, que están incompletas y en las cuales los desarrolladores aún siguen trabajando fuertemente. Por lo tanto, también se intentó brindarles a los creadores de GeneXus retroalimentación de su uso antes que liberaran la versión completa Proceso de Análisis Previamente se presentó una descomposición de los Sistemas de Información en cuatro tipos de operaciones básicas: entradas, salidas, procesamientos y almacenamientos. Al diseñar un lenguaje específico para estos sistemas se buscó brindar elementos que ayuden a implementar estas operaciones, construyendo abstracciones específicas que permitan resolver los casos más comunes con poco esfuerzo, y brindando mecanismos de extensión para los más complejos. Para identificar dichas abstracciones se definió un Caso de Estudio, de forma de poder estudiar cada operación con ejemplos concretos y así explorar cuál es la información mínima que se necesita para poder generar con ella la solución. A partir de ejemplos concretos se buscó extraer abstracciones de alto nivel, buscando que estén lo más cerca posible a la forma en que se especifican los requerimientos, aunque teniendo la precaución de no utilizar conceptos demasiado específicos que no puedan ser generalizables a otros casos. Luego de definir esas abstracciones, los ejemplos también sirvieron para validar que la solución es completa, verificando que la misma permite implementar el requerimiento de forma completa y por lo tanto no se hicieron omisiones. En la siguiente sección se presenta el Caso de Estudio que se utilizó para el análisis, y en el resto del capítulo se describen las decisiones que se tomaron para representar los tipos de operaciones elegidos. Página 31 de 85

35 4.4. Caso de Estudio Como Caso de Estudio se definió un sistema de Gestión de Proyectos. Dentro de sus requerimientos se incluye: la definición de proyectos, asignación de personas, generación de estadísticas, ingreso de requerimientos y reportes de errores, y el seguimiento de estos últimos (utilizando tecnología de Workflow). Se seleccionó este sistema debido a que es una clase de sistema con conceptos conocidos para un desarrollador y por lo tanto es más sencillo acercarse a lo que serían sus requerimientos reales. A continuación se enumeraran sintéticamente sus operaciones básicas: Entradas: Personas y roles disponibles para proyectos Proyectos: Requerimientos y documentos asociados Reportes de error asociados a requerimientos Personas asignadas Evolución: Requerimientos terminados y errores corregidos Verificaciones rechazadas Salidas: Consulta de los componentes de cada proyecto (requerimientos, documentos y reportes de error) Consulta de requerimientos y reportes error en función de su estado Consulta de historia de requerimientos y reportes de errores Consulta de recursos asignados Consulta de estadísticas por semana (cantidad de requerimientos ingresados, requerimientos completados, verificaciones rechazadas, errores ingresados, errores resueltos) Procesamientos: Generación de estadísticas para cada proyecto Generación de registros históricos al producirse un cambio en un requerimiento o reporte de error Almacenamiento: Personas y roles Proyectos y sus componentes Para el sistema también se deben implementar dos procesos (utilizando Workflow): Ingreso de Requerimiento Reporte de Error Para estudiar de forma ordenada cómo se puede representar este sistema con un DSL, se comenzó considerando únicamente las operaciones de salida, luego se agregaron las entradas, y por último los procesamientos, como se muestra en las secciones subsiguientes Consultas de Información (Salidas) En esta sección se define un lenguaje de alto nivel que permita expresar las consultas. Como método de trabajo se toma una operación de salida del Caso de Estudio que se considere representativa, y se definen las abstracciones necesarias para poder expresarla. Al diseñar el lenguaje es importante destacar que la representación escogida debe ser lo suficientemente completa como para generar código ejecutable a partir de ella, y muy flexible para poder expresar un alto número de consultas con las construcciones que ofrezca Operación a Estudiar Se toma como referencia la operación de salida Consulta de los componentes de cada proyecto. El objetivo de esta operación es brindar a los usuarios la posibilidad de consultar los requerimientos, documentos y reportes de errores asociados a cada proyecto. Adicionalmente, se debe dar la posibilidad de listar las personas que estén actualmente asignadas a cada proyecto Navegando por Relaciones Para analizar mejor el problema se va a construir un diagrama del Modelo de Datos en donde se presenta una posible organización de las tablas que define la aplicación y las relaciones que hay entre ellas. Este modelo Página 32 de 85

36 es utilizado posteriormente para estudiar cómo se podrían expresar las consultas en un lenguaje especializado para escribir esta clase de requerimientos. En la Figura 6 se muestra en UML la parte del Modelo de Datos que se va a considerar durante el análisis. La Software Factory no incluye el modelado de la Base de Datos (ver sección Delimitación del Dominio del Problema), por lo tanto, se asume que ya fue definida utilizando GeneXus y se crearon las tablas de la figura. * «table» Errores «table» Proyectos 1 1 * «table» Requerimientos 1 1 * «table» Documentos * «table» 1 Asignaciones * * 1 «table» Roles 1 «table» Personas Sólo se incluyen las tablas y relaciones del Caso de Estudio relevantes para el análisis Figura 6. Vista parcial del Modelo de Datos En el diagrama sólo se muestra una vista parcial de lo que sería el Modelo de Datos de toda la aplicación. Se incluyen únicamente las tablas y relaciones que intervienen en el Caso de Estudio, y se ocultaron los detalles que no resultan relevantes para el análisis del problema. En la definición de la operación a estudiar se expresa que se debe permitir consultar los componentes de cada proyecto (requerimientos, documentos y reportes de error). En el diagrama se puede observar que a partir de un proyecto se pueden obtener cada uno de estos elementos a través de las relaciones definidas en el Modelo de Datos. En este caso particular, a partir de un Modelo de Datos que refleja las relaciones entre las entidades del problema se puede indicar cómo se resuelve la consulta describiendo cómo se navega en las relaciones. Tomando esta observación como hipótesis de estudio se intentó definir un lenguaje que permitiera escribir los requerimientos de consultas a través de las relaciones del Modelo de Datos. Como desafío adicional, este lenguaje no sólo debe considerar la resolución de las consultas sobre el Modelo de Datos, sino que también debe definir cómo interactúa el usuario con la aplicación. Analizando el caso de estudio el usuario debería poder seleccionar un proyecto para ver sus requerimientos y luego poder escoger un requerimiento en particular para ver una descripción detallada del mismo. Esta interacción también se debe expresar con el lenguaje Un Caso Sencillo En la Figura 7 se presenta el lenguaje gráfico que se definió y se muestra cómo se representaría con él la consulta de proyectos y sus componentes. En el diagrama se indican las navegaciones entre las páginas de la Interfaz de Usuario y para cada una de ellas se define una expresión que determina los datos que se muestran allí (una tabla o registro). En el diagrama se parte de una página que muestra todos los proyectos cargados en la Base de Datos. Luego para cada proyecto se pueden obtener sus requerimientos, y para cada uno de ellos sus documentos Página 33 de 85

37 asociados y reportes de error. Dentro del diagrama también se incluyen páginas que permiten ver los datos detallados de cada uno de estos elementos. Proyectos Proyecto Requerimientos p:proyectos p r:requerimientos[p] (continúa abajo) Documentos Documento Requerimiento <TAB> d:documentos[r] d (continuación) r Errores Error <TAB> e:errores[r] e Figura 7. Lenguaje específico para representar consultas Cada recuadro representa una página Web. El texto en la parte superior de cada página indica su titulo y las flechas definen las rutas de navegación, si hay una flecha entre dos páginas significa se puede ir de una a la otra. En la parte interna se definen los datos que muestra, por ejemplo, la expresión r:requerimientos[p] indica que se deben mostrar todos los registros de la tabla Requerimientos que estén asociados con el proyecto p (que fue seleccionado en la página con titulo Proyectos), y a la selección se le denomina r. En la próxima sección se define con más detalle la gramática de estas expresiones. Para representar la opción que permite ir desde, por ejemplo, la página de Requerimiento a Documentos, se utiliza el titulo de esta última. También se permite escribir un texto en la flecha para utilizar otro texto. En algunos sistemas se suele utilizar un sistema de pestañas en la parte superior cuando se muestra información relacionada con la misma entidad (ver Figura 8). Por ejemplo, si se está mostrando la información de un requerimiento, una pestaña podría permitir ver sus documentos y otra sus errores. En cambio, no se utiliza este sistema cuando se navega a otra entidad. Para permitir definir que una navegación se hace a través de una pestaña se permite escribir <TAB> en el texto de la ruta. Figura 8. Pestañas A través de este lenguaje se busca un medio que pueda ser leído e interpretado por un generador de código. Leer los requerimientos en lenguaje natural sería una tarea demasiado compleja, pero si están escritos en un lenguaje formal, que exprese los datos que se muestran y las navegaciones, es factible crear aplicaciones ejecutables a partir de su definición. De esta forma se simplifica la tarea de desarrollo, para resolver un requerimiento en lugar de tener que escribir varios cientos de líneas en HTML + Javascript + Java o.net, sólo se necesitan unas pocas en un lenguaje más específico. Aún quedan preguntas pendientes, por ejemplo, cómo determinar qué atributos mostrar de un registro? o qué colores va a utilizar?, se dejarán pendientes las respuestas a estas preguntas hasta más adelante. Antes Página 34 de 85

38 de contestarlas, en la próxima sección se describe el formato que se utiliza para las expresiones y otros elementos que permiten agregar más información al modelo Expresiones sobre el Modelo de Datos Como se vio previamente, en cada recuadro se debe indicar una expresión que determina los datos que se muestran allí. En el ejemplo se indicaron consultas sencillas, aquí también se consideran consultas más complejas y se define cómo expresarlas. Las expresiones se definen de la siguiente forma (se utiliza formato BNF): <expresión> ::= [<instancia> : ] <fuente> La expresión cuenta por un lado con una instancia (que es opcional) y una fuente. A continuación se describen estos componentes. Cada expresión también puede tener una condición, un orden o filtros. Estos últimos elementos se definen a través de un diálogo de propiedades luego de seleccionar una página, y no se incluyen en la gramática de la expresión. De esta forma se buscó mantener una representación compacta para las expresiones que se muestran en el diagrama. Adicionalmente, dentro del mismo cuadro es posible incluir más de una expresión separándolas con ; (punto y coma) Fuente La parte principal de la expresión es la fuente, aquí se indica de dónde se extraen los datos a mostrar. La fuente puede determinar: Un único registro: En este caso se muestran sus atributos (por ejemplo los de un requerimiento) Un conjunto de registros: Aquí en cambio se muestra una grilla con los registros (por ejemplo los requerimientos de un proyecto). Se soportan las siguientes formas para definir la fuente: tabla: Consiste únicamente en un identificador con el nombre de una tabla. Por ejemplo, si se escribe Proyecto como fuente, se muestran todos los registros de esa tabla. instancia: Consiste en un identificador con el nombre de una instancia. Se utiliza para referenciar un registro que seleccionó el usuario generalmente en una página anterior. Dentro del ejemplo, en la página Requerimientos se despliegan los requerimientos de un proyecto para que se seleccione uno y en la página siguiente se muestran los datos del requerimiento seleccionado. En este caso, el requerimiento seleccionado sería r, y se escribe este nombre de instancia para mostrar sus datos. Tabla[instancias]: Al indicar una tabla junto con una o más instancias (separadas por coma), se seleccionan los registros de la tabla que están asociados a todas las instancias indicadas. Por ejemplo, al escribir Requerimiento[p] (donde p es una instancia de la tabla Proyecto) se muestran sólo los requerimientos del proyecto p. Dependiendo de la cardinalidad de la relación este tipo de expresión puede determinar un único registro o un conjunto de registros. Si la relación es 1-1 (o N-1) en la página generada se muestran los datos del registro, si la relación es 1-N o N-M es necesario mostrar una grilla con los registros que determina la relación Instancia Dentro de la expresión también se puede indicar un nombre de instancia. Por ejemplo, la expresión p:proyecto declara la instancia p. Allí se indica que el usuario debe seleccionar un proyecto y que al proyecto seleccionado se lo llamará p. Luego, la instancia p se puede referenciar en otras páginas, por ejemplo, para obtener los requerimientos del proyecto seleccionado, o para pasarlos por parámetro al invocar una operación (ver sección 4.7 Procesamientos) Condición Para cada expresión se puede asociar una condición que filtre los datos de la fuente. Por ejemplo, para indicar que se desplieguen únicamente los requerimientos que no están implementados. Las condiciones se expresan en lenguaje GeneXus. Página 35 de 85

39 Orden También se puede definir el orden en que se muestra un conjunto de registros. El orden se define indicando una lista de atributos separados por coma. Por defecto el orden es ascendente, para fijar un orden descendente en un atributo se puede escribir su nombre entre paréntesis. Si se desea mostrar los requerimientos de un proyecto ordenados por identificador (en orden descendente) la expresión sería Requerimiento[p] y el orden: (ReqId). En donde ReqId es el atributo que indica el identificador en la tabla Requerimiento Filtros Al mostrar un conjunto grande de registros puede ser deseable incluir mecanismos de búsqueda que faciliten la localización de un registro particular. Si se muestra una lista de personas, seguramente sea útil permitir búsquedas por nombre, en lugar de obligar al usuario a recorrer una lista potencialmente grande de registros. Los filtros pretenden cubrir este tipo de funcionalidades. Personas Se transforma en Personas Filtro: PerNom Orden: PerNom Figura 9. Filtro por nombre (definido con el atributo PerNom en la tabla Personas) Los filtros se definen a partir de una lista de atributos separados por coma. Cada filtro se genera como un campo que se muestra sobre la grilla en donde el usuario puede escribir un valor para filtrar los elementos. Por ejemplo, si se define un filtro por nombre, sólo se mostrarán las personas que comiencen con los caracteres escritos en el filtro (ver Figura 9). Si se define un filtro por un campo numérico sólo se mostrarán los registros mayores o iguales al valor ingresado Un Lenguaje Simple para Generar Código En este capítulo se busca definir un lenguaje diseñado con abstracciones específicas para resolver los requerimientos de un Sistema de Información. En primer lugar se categorizaron las operaciones típicas de esta clase de sistemas en cuatro categorías, y para acotar el problema, en esta primera etapa el análisis se enfocó en una en particular, las salidas. Para estudiar las operaciones de salida se definió un requerimiento como Caso de Estudio, y a partir de él se definieron abstracciones que permitan representarlo. Luego, se fue agregando complejidad, lo que obligó a agregar nuevos elementos, y así progresivamente se construyó un lenguaje específico para representar las operaciones de salida. Como se observa, el método de trabajo que se siguió se basó en el análisis de casos particulares. Al detectar requerimientos que no se podían representar, se analizaron posibles adaptaciones al lenguaje, y en forma iterativa, por aproximaciones sucesivas, se llegó a la versión final del DSL que se presentó en este capítulo. Aquí sólo se incluyeron los ejemplos que resultaron más representativos en la propuesta del lenguaje, aunque durante el diseño se consideraron varios más. De cualquier forma, sólo la evidencia empírica permitirá evaluar qué porcentaje de consultas pueden ser representadas con el DSL, en forma completa o parcial, y qué tan efectivo será para implementar sistemas reales. Cabe recordar que tampoco se pretende poder representar todas las consultas con él, sino sólo un porcentaje alto de consultas simples. En la sección Objetivos, se definieron los objetivos generales del DSL. Sin embargo, durante el proceso de diseño del lenguaje se consideró conveniente definir otros objetivos secundarios, para tener una base de referencia más sólida que permita escoger la opción más adecuada cuando hubo varias alternativas posibles. Los objetivos secundarios fueron: Lograr un lenguaje sencillo y fácil de utilizar Página 36 de 85

40 Ofrecer abstracciones muy especificas para los casos típicos, y brindar niveles de flexibilidad para casos menos comunes Capturar las definiciones claves de forma de poder generar un porcentaje alto del código a partir de estos modelos Uno de los mayores desafíos de la tarea de diseño fue conciliar distintas exigencias sobre el lenguaje, enfrentando incluso necesidades opuestas. Se buscó un lenguaje sencillo, pero al mismo tiempo lo suficiente completo como para generar todos los objetos ejecutables necesarios. Para escribir un generador de código es necesario partir de una entrada muy precisa que permita a un autómata determinar la implementación correcta para cada situación. Algunas de las preguntas que debe poder contestar son: cómo se debe diseñar la interfaz de usuario?, cómo se accede a la información?, qué atributos se van a mostrar?, qué colores y tipos de letra se deben utilizar?. Sin embargo, al mismo tiempo se buscó un lenguaje simple, que sea fácil de entender y permita a simple vista obtener una visión global del sistema. Aquí se presentan dos necesidades que pueden parecer opuestas: simplicidad y completitud. Se solucionó este conflicto utilizando dos fases de definición para poder capturar en cada una de ellas distintos niveles de detalle. La primera fase se realiza en el DSL presentado, en donde se indica una definición de muy alto nivel de los requerimientos. Con el DSL se definen las características generales, omitiendo detalles particulares. Por ejemplo, se indican las tablas que se leen pero no se enumeran los atributos que se muestran. La segunda fase de definición apunta a recolectar estos detalles. Un generador transforma los modelos representados en este DSL a otros de más bajo nivel, en donde se releva la información faltante (segunda fase). Luego, a partir de este último modelo, otro generador se encarga de escribir el código GeneXus que implementa el requerimiento. La intención es capturar en el primer nivel las decisiones esenciales y tratar de deducir las del segundo nivel. Para hacerlo el generador intenta determinar el caso más probable según el contexto (a este concepto se lo llamó Generación Deductiva). Al basarse en información parcial podría equivocarse, por este motivo se brinda un segundo nivel que le da la posibilidad al usuario de modificar los datos que infirió el generador. El proceso a seguir sería entonces así: primero se construye con el DSL una vista de alto nivel a partir de un requerimiento y luego progresivamente se refinan los detalles de más bajo nivel en cada componente que conforma la solución (a este otro concepto se lo llamó Diseño Progresivo). Por ejemplo, en el nivel más alto se indica la tabla de la Base de Datos que se quiere mostrar pero sin indicar qué atributos. A partir de este modelo se tratará de inferir una lista razonable de atributos a mostrar, en caso que la lista de atributos no sea la adecuada se podrá modificar en el segundo nivel antes de que se genere el código final de la solución. El DSL de este capítulo es la herramienta con que se define el primer nivel, para el segundo nivel se utilizó otro DSL que se presenta brevemente en el siguiente capítulo (en el Manual de Proceso [Cas07] se puede encontrar una especificación detallada de sus elementos). Se reserva para el siguiente capítulo una explicación más profunda de cómo se implementan los conceptos de Generación Deductiva y Diseño Progresivo. Mientras tanto, aquí se continúa con el análisis del siguiente tipo de requerimientos, las entradas Ingreso de Datos (Entradas) Al comenzar a estudiar los Sistemas de Información se identificaron cuatro tipos de operaciones básicas: entradas, salidas, procesamientos y almacenamientos. En esta sección se estudian las operaciones de entrada. Se toma como punto de partida el lenguaje definido para las salidas, y se crean extensiones que permitan resolver con él también las operaciones de entrada. De esta forma, con el mismo lenguaje se pueden resolver los dos tipos de operación. Otra alternativa posible sería definir un nuevo lenguaje exclusivo para representar las entradas. Sin embargo, generalmente las salidas se mezclan con las entradas en las mismas interfaces, por lo tanto, resulta más conveniente brindar un mecanismo unificado que permita definir ambos tipos de operaciones Al analizar las salidas se concluyó que era posible representarlas con expresiones que determinen el subconjunto del Modelo de Datos a mostrar. Al estudiar las entradas se encontró un escenario similar, aunque en lugar de determinar el subconjunto que se lee se debe indicar la porción de éste que se escribe. Por ejemplo, un requerimiento de salida es permitir consultar los requerimientos de un proyecto, en cambio un requerimiento de entrada podría ser permitir agregar, modificar o borrar los requerimientos. En el primer caso se leen los datos, y en el segundo además se escriben. Tanto en las salidas como en las entradas se debe expresar sobre qué sección del Modelo de Datos se va a trabajar, por lo tanto, se intentó reutilizar las expresiones de las salidas para definir los registros que se escriben. Página 37 de 85

41 De cualquier forma hay diferencias entre las entradas y las salidas. La diferencia principal es que para las entradas se debe indicar la operación que se va realizar con los datos. En las salidas hay una única operación básica que es ver el/los datos, sin embargo, en las entradas se tienen varias operaciones posibles, como agregar un nuevo registro, modificar uno ya existente o borrarlo. En el resto de la sección se analiza cómo representar estas operaciones en distintos escenarios. Para realizar el análisis, en primer lugar se da una definición más precisa de qué se entiende como entrada, luego se describe un requerimiento concreto que sirva como caso de estudio, y finalmente se presentan las extensiones necesarias para representar el requerimiento dentro del DSL Entradas Consideradas Las entradas son las que permiten ingresar los datos que se quieren almacenar o procesar en el sistema. Hay tanto entradas manuales (utilizadas por usuarios) como automáticas (utilizadas por otros sistemas, por ejemplo a través Web Services). Se planteó enfocar la Software Factory en la interacción entre el usuario y el sistema (ver sección Delimitación del Dominio del Problema), por lo tanto se consideraron únicamente las entradas manuales. Para delimitar más precisamente qué se considera como operación de entrada, se definen como operaciones de este tipo únicamente las que incluyen una o más de las siguientes funciones: agregar, modificar o borrar un registro sobre una tabla. Las operaciones que realicen otro tipo de transformación sobre los datos se consideran como operaciones de procesamiento Operación a Estudiar Al analizar las salidas se utilizó el siguiente requerimiento: Consulta de los componentes de cada proyecto. Tomándolo como referencia se expresó en el DSL una consulta que muestra los proyectos definidos y permite obtener sus requerimientos, y luego para cada requerimiento sus documentos y errores asociados. Para analizar cómo representar las entradas se tomó la operación de ingreso de requerimientos. Se buscó extender la interfaz definida para la consulta con el fin de permitir agregar, modificar y borrar requerimientos asociados a proyectos. El objetivo es por un lado estudiar cómo representar las operaciones de entrada, y por otro analizar cómo se pueden integrar las operaciones de entrada y salida dentro del mismo lenguaje Agregar, Modificar y Borrar Como se vio previamente, la diferencia fundamental que se encontró entre las entradas y las salidas es que en estas últimas hay una operación implícita que es ver el/los datos, en cambio en las entradas se identificaron tres nuevas operaciones posibles: agregar, modificar y/o borrar. Por lo tanto, la primera tarea para poder representar las entradas es crear los elementos necesarios para indicar que se va a realizar un ingreso de datos, y definir cuáles de las operaciones identificadas se van a permitir. En la Figura 10 se muestra una primera propuesta de cómo marcar las operaciones de entrada. Allí se define una interfaz que permite agregar, modificar, borrar y ver los requerimientos de un proyecto. Las operaciones se definieron sobre una flecha de navegación, ya que la mayoría vinculan a dos páginas, por ejemplo, al agregar un requerimiento se mostraría una nueva página en donde se piden sus datos. Proyecto Requerimientos Agregar / Modificar / Borrar / Ver Requerimiento p r:requerimiento[p] r Figura 10. Propuesta para Agregar, Modificar, Borrar y Ver requerimientos de un proyecto Al implementar un sistema de Gestión de Proyectos, como el que se está utilizando como Caso de Estudio, se pueden encontrar varios requerimientos que implican estas mismas operaciones. Como agregar, modificar y borrar proyectos; agregar, modificar y borrar personas; agregar, modificar y borrar documentos asociados; etc. Este tipo de requerimientos son muy comunes dentro de los Sistemas de Información, e incluso existen acrónimos populares para referirse a ellos, como ABM en español (Altas, Bajas y Modificaciones) o CRUD en ingles (Create, Read, Update y Delete), en este último se agrega también una operación de consulta. Página 38 de 85

42 Uno de los objetivos del DSL es brindar abstracciones específicas que facilitan la implementación de requerimientos típicos como estos, así que se buscó una alternativa más sencilla para definir estas cuatro operaciones: Agregar, Modificar, Borrar y Ver. La Figura 11 brinda una representación más compacta, que es equivalente a la Figura 10 y es la forma oficial de expresarlas en el DSL. En esta nueva representación también se cambió el color con que se representan las páginas con operaciones de entrada (a tonos de verde) para facilitar su identificación en los diagramas. Proyecto Requerimientos Requerimiento <IUD> p r:requerimiento[p] r Figura 11. Agregar, Modificar, Borrar y Ver requerimientos (simplificado) El patrón IUD (escrito entre símbolos de menor y mayor) resume las operaciones de la Figura 10. Este acrónimo combina las operaciones Insert (Agregar), Update (Modificar) y Delete (Borrar). Se utilizan estos términos en lengua inglesa ya que son los mismos que emplea GeneXus para referirse a las operaciones mencionadas, por lo que el usuario GeneXus estará más familiarizado con ellos. También se escogió utilizar la lengua inglesa en el DSL ya que la interfaz de GeneXus está definida en este mismo idioma, así que se mantuvo el mismo lineamiento. Se permite la utilización parcial de este patrón, por ejemplo, se pueden indicar únicamente las operaciones Alta y Baja, sin la de Modificación. Para esto, se escriben únicamente las letras asociadas a las operaciones que se quieren permitir, en el ejemplo mencionado sería <ID>. Al utilizar el patrón se define de forma implícita la operación Ver, ya que se considera que enriquece a las operaciones anteriores por lo tanto se incluye automáticamente en todos los ingresos Reglas de Negocio Las reglas de negocio son otro aspecto importante que forma parte de los requerimientos de ingreso de datos. Las mismas definen restricciones o políticas que el sistema debe controlar antes de aceptar una operación de ingreso. Un ejemplo de restricción sería: No se puede ingresar una persona con el nombre vacío o Una persona no puede estar asignada a más de dos proyectos simultáneamente. GeneXus brinda un lenguaje declarativo para definir reglas de negocio dentro de los objetos de tipo Transacción. Las Transacciones se utilizan para crear los atributos de la Base de Datos, pero también permiten definir una interfaz gráfica para interactuar con los datos y un conjunto de reglas que se validan al utilizar dicha interfaz. Dentro de estas reglas se pueden incluir condiciones que deben cumplir los datos, o también llamar a procedimientos con código para hacer validaciones más complejas (u otras operaciones, como por ejemplo, agregar un registro en una tabla histórica cada vez que se produce una modificación en los datos que administra la Transacción). Se consideró que las Transacciones brindan un medio adecuado para definir las reglas de negocio en la clase de sistemas a los que apunta la Software Factory. Por lo tanto, se establece el siguiente método de trabajo para construir un Sistema de Información con ella. Primero, se define la Base de Datos con GeneXus y se incluyen las reglas de negocio dentro de las Transacciones, cada regla se agrega en la Transacción que define la tabla en la cual se aplica. Sin embargo, no se diseña su interfaz gráfica, sólo se utilizan para definir la Base de Datos y las reglas de negocio. La interfaz gráfica se define a través del DSL presentado en este capítulo, con él se indica cómo interactúa el usuario con la Base de Datos. Luego, al generar la aplicación, la Software Factory se encarga de reconocer la tabla con que se interactúa en cada página, y si se hacen operaciones de entrada sobre la tabla que identifica la Transacción en la cual se encapsulan sus reglas y las agrega en la interfaz que genera. De esta forma, las reglas de negocio se definen una única vez por cada tabla, y la Software Factory se encarga de trasladarlas a todas las interfaces que interactúen con la tabla y también de mantenerlas sincronizadas (en el siguiente capítulo, dentro de la sección Plantillas de Código se describe cómo se implementó este mecanismo). Las reglas definidas en una transacción sólo son validas dentro de ella, así que para poder utilizarlas la Software Factory generan las interfaces de entrada dentro de Transacciones. Al seguir este enfoque también Página 39 de 85

43 se aprovecha la capacidad de GeneXus para generar la implementación de las operaciones de entrada (ingreso, modificación y borrado). Sin embargo, el único inconveniente es que potencialmente podría haber más de una interfaz que interactúe sobre la misma tabla. Por lo tanto, en lugar de modificar la misma transacción con que se genera la Base de Datos, cada vez que se necesita crear una interfaz sobre ella se crea una copia y se define la interfaz en la copia. De esta forma se pueden generar tantas interfaces de ingreso sobre la misma tabla como se quiera. Si se modifican las reglas de negocio en la Transacciones que define la tabla, la Software Factory se encarga de trasladar los cambios a todas las interfaces como se mencionó previamente. Adicionalmente, GeneXus se encarga de mantener sincronizada la definición de los atributos de las transacciones. Adicionalmente, para reglas sencillas (como por ejemplo, controlar que un nombre no esté vacío) GeneXus genera código Javascript para validarla directamente en el navegador y reportarlas rápidamente evitando que lleguen datos inválidos al servidor. Por mayor seguridad, GeneXus también genera código C# (o en otra plataforma) para validarlas nuevamente en el Servidor (por ejemplo, por si no se ejecutó el código Javascript en el navegador porque no soporta esta característica). Por lo tanto, incluso a pesar que las mismas reglas se deban validar en distintas páginas y capas de la aplicación, utilizando la Software Factory se definen una única vez y se trasladan a los lugares en donde se deban aplicar Entrada de Datos No Interactiva El enfoque utilizado se centra en la interfaz gráfica pero no abarca a los procesos batch. Si se escriben procedimientos que hacen modificaciones sobre la Base de Datos podrían no considerarse las reglas de negocio. Por ejemplo, si se define que el nombre de las personas no puede estar vacío, y se escribe un procedimiento que ingresa varias registros en la tabla Personas no se valida que no ingresen registros con el nombre vacío. La Software Factory se enfoca en la interfaz, por lo tanto este tipo de requerimientos están fuera de su alcance. Sin embargo, GeneXus brinda mecanismos para resolverlos que no son incompatibles con la forma de trabajo propuesta por la Software Factory. A través de una propiedad se puede definir que una Transacción actúe como Business Component. Al hacerlo, se puede utilizar la Transacción de forma nointeractiva, es decir, se puede instanciar a la Transacción desde el código de un procedimiento, cargar sus datos y ejecutar una operación con ellos (como por ejemplo, agregar, modificar o borrar). Al utilizar las Transacciones de esta forma, se validan sus reglas de negocio también dentro de procesos batch. Un Business Component se puede también exponer como Web Service, así que con esta funcionalidad también se pueden validar las reglas en ingresos o modificaciones realizadas a través de sistemas externos. Sin embargo, GeneXus no obliga a que todas las operaciones de entrada sobre una tabla se hagan a través de los Business Component, ya que brinda primitivas para agregar, hacer modificaciones o borrar registros sin pasar por ellos. Por lo tanto no garantiza que se apliquen siempre las reglas de negocio allí definidas, esto depende de una buena disciplina de programación Limitaciones del Uso de Transacciones Las interfaces construidas a través de Transacciones brindan un medio para interactuar con la Base de Datos. Sin embargo, exigen que todos los campos editables que se incluyan en ellas estén asociados a un atributo de la Base de Datos, por lo tanto hay un alto acoplamiento con esta. No es posible pedir datos en variables para que luego otros programan hagan modificaciones en función de ellos. Otra limitante del uso de Transacciones es que no permiten definir transacciones lógicas que abarquen más de una página. Luego que se ingresan datos en una Transacción para no perderlos hay que grabarlos en la Base de Datos. Por ejemplo, si al ingresar una persona en el sistema se quieren pedir varios datos en páginas distintas (por ejemplo, datos personales, direcciones, empleos anteriores, estudios) lo ideal sería que sólo se grabaran estos datos en la Base de Datos de forma atómica luego que se confirman, es decir, o todos o ninguno. Sin embargo, las Transacciones obligan a grabar la información parcial que se ingrese en cada página. Por lo tanto, tampoco se puede ingresar una regla que valide que no se ingresen personas sin direcciones, porque para ingresar las direcciones hay que grabar los datos personales antes, y en este momento habría una persona sin direcciones. Una alternativa para implementar la funcionalidad anterior con Transacciones es crear nuevas tablas que actúen como un repositorio temporal, y luego escribir un proceso que pase los datos a las tablas definitivas. Dentro de este proceso también se podrían validar reglas adicionales que se aplican a las relaciones (como que no puede haber personas sin direcciones). Adicionalmente, convendría escribir procesos que corran periódicamente para eliminar registros antiguos de las tablas donde se guarda la información temporal. Todos Página 40 de 85

44 estos procesos no son implementados automáticamente por la herramienta. Como trabajo a futuro se puede estudiar cómo incluir mecanismos en la Software Factory que ayuden a implementar este tipo de funcionalidades Integridad Referencial Al trabajar con una Base de Datos, una propiedad deseable es la de Integridad Referencial. Mantener esta propiedad en los datos implica que en todo momento si un registro de una tabla hace referencia a un registro de otra éste último debe existir. GeneXus permite declarar las reglas de integridad referencial como restricciones en la Base de Datos (esto es opcional y por defecto no está activado). También permite validarlas al utilizar transacciones y ésta es la opción sugerida. La Software Factory se apoya en el uso de Transacciones, por lo tanto, la validación de la integridad referencial es realizada automáticamente. Al definir las operaciones de ingreso, modificación y borrado a través de transacciones, GeneXus se encarga de agregar código para implementar las reglas de integridad. En caso que se haga alguna de estas operaciones en procedimientos implementados fuera de la Software Factory, las reglas se deben validar manualmente o definirlas como restricciones en la Base de Datos para que el gestor se encargue de controlarlas Procesamientos En las secciones anteriores se analizaron las operaciones de entrada y las de salida. Para las operaciones de almacenamiento se concluyó que están bien resueltas por los motores de Base de Datos y GeneXus, y se consideró más adecuado poner énfasis en el resto. Así que únicamente restan por analizar las operaciones de procesamiento. Estas operaciones definen la capacidad de un sistema para realizar transformaciones y cálculos sobre los datos ingresados. A través del procesamiento los Sistemas de Información facilitan a sus usuarios tomar decisiones, por ejemplo, generando estadísticas con los productos más vendidos, o proyecciones del uso de las materias primas. Los procesamientos también comprenden automatismos internos que se realiza a través de cálculos o transformaciones sobre los datos (como por ejemplo, emitir una orden de compra cuando un producto llega a un nivel de stock mínimo). Para diseñar el DSL se especificó un escenario concreto, de forma de poder realizar un análisis sobre una base más tangible. El escenario escogido fue la construcción de un sistema de Gestión de Proyectos, en el cual se definieron las siguientes operaciones de procesamiento: Generación de estadísticas para cada proyecto Generación de registros históricos al producirse un cambio en un requerimiento o reporte de error En esta sección se analiza cómo se pueden definir este tipo de operaciones dentro de un Sistema de Información creado con el DSL. Esta tarea se realizó identificando primero distintas clases de operaciones de procesamiento, y luego definiendo una estrategia para implementar cada una de ellas Cálculos o Transformaciones Dentro de las operaciones de procesamiento se definen dos clases: las que realizan cálculos y las que transforman datos. Las operaciones de cálculo serán aquellas que aplican formulas aritméticas y procesos lógicos sobre los datos almacenados para presentárselos al usuario (por ejemplo, para mostrar estadísticas). Las operaciones de transformación serán en cambio las que aplican cálculos pero para generar nuevos datos en la base de datos o modificar datos existentes. La diferencia fundamental entre estas dos clases, según la definición tomada, es que las operaciones de cálculo presentan información al usuario y no modifican los datos en la base de datos, en cambio, en las operaciones de transformación el objetivo principal es producir cambios en la base de datos. Se definieron estrategias distintas para resolver estas dos clases de operaciones de procesamiento. Las operaciones de cálculo actúan como un intermediario entre los datos que se encuentran la base de datos y los que se presentan al usuario. Es decir, definen nuevos datos calculados a partir de los datos almacenados. La estrategia para resolver este tipo de operaciones debe brindar la posibilidad de definir fórmulas calculadas sobre los datos originales, o programas que permitan procesarlos y producir nuevos datos para mostrar al usuario. Página 41 de 85

45 Según la complejidad de la operación de cálculo se tendrán varias alternativas. La primera es utilizar atributos calculados en GeneXus. Esta funcionalidad permite definir atributos que se expresan como formulas sobre otros atributos de la Base de Datos. Como el DSL es capaz de referenciar las tablas que contengan estos atributos, se pueden mostrar cálculos dentro de las interfaces. En caso que se requiera hacer un cálculo más complejo, que no se pueda expresar en un atributo calculado, es necesario escribir un procedimiento que lo realice. El DSL debe considerar esta situación para permitir mostrar el resultado del cálculo al usuario. Como se mencionó en la sección Un Lenguaje Simple para Generar Código, hay dos niveles de definición: un primer nivel que define la navegación entre un grupo de páginas (el cual se representa con el DSL diseñado en este capítulo) y un segundo nivel que permite definir con más detalle cada página (a través de otros DSLs de más bajo nivel). En este segundo nivel es donde se brinda un mecanismo para soportar cálculos complejos, el cual consiste en dar la posibilidad de asociar uno o más procedimientos que se llamen al cargar la página y permitir incluir las variables con el resultado dentro de los campos que se muestran. De esta forma se brindan dos alternativas para definir las operaciones de procesamientos que realizan cálculos según su grado de complejidad. La otra clase de procesamientos identificados son las transformaciones, las cuales no están destinadas a mostrar información al usuario, sino principalmente a realizar modificaciones en la base de datos. Por lo tanto, se tiene que utilizar una estrategia distinta, que no esté necesariamente asociada a la interfaz de usuario. La característica fundamental que determinó cómo se implementaron fue el momento en que se invocan: de forma manual por el usuario o como respuesta a un evento ocurrido en el sistema. Se analizan estas dos situaciones a continuación Momento de Disparo Como se vio previamente, el resultado de una operación de transformación es una modificación en la base de datos (ya sea ingresos, modificaciones o borrados). Típicamente, las transformaciones leen un grupo de registros, aplican cálculos sobre ellos y graban el resultado en la base de datos. Una de las operaciones de este tipo que se presentó en el Caso de Estudio fue: Generación de estadísticas para cada proyecto. Para implementar este requerimiento se podría definir una nueva tabla que contenga las estadísticas, y crear un procedimiento que se encargue de calcularlas en base al estado actual de un proyecto. En este caso, la operación de transformación toma como entrada exclusivamente valores de la Base de Datos, por lo que hay dos momentos posibles de disparo: automático cuando se detecta un cambio en el proyecto, o de forma manual cuando el usuario quiera actualizarlo. Las funcionalidades que permite modificar el progreso de proyecto son operaciones de entrada, que pueden representarse en el DSL con los mecanismos ya definidos para este tipo de operaciones. Las operaciones de entrada se basan en Transacciones, las cuales centralizan la escritura sobre la Base de Datos. En ellas se pueden definir reglas que se disparen ante una situación particular, por ejemplo, al realizar una modificación. Por lo tanto, es posible implementar las transformaciones automáticas como reglas, y esta es la estrategia propuesta para resolverlas. Con este mecanismo se implementa el requerimiento: Generación de registros históricos al producirse un cambio en un requerimiento o reporte de error. Tanto en la Transacción que define los requerimientos, como en la que define los reportes de error, se puede agregar una regla para ejecutar un procedimiento cada vez que se confirma una operación en ella (como por ejemplo, una modificación) y dentro de dicho procedimiento copiar los valores actuales de la tabla a otra que mantenga la historia. Al implementar el disparo del procedimiento con reglas en Transacciones, la Software Factory se encarga de trasladarlas a todas las interfaces que interactúen sobre estas tablas. Las transformaciones que se disparan de forma manual se resolvieron de forma distinta. Se agregó la posibilidad de asociarle un conjunto de acciones a una página, las cuales permiten ejecutar procedimientos. Estas se representan como botones o hipervínculos en las páginas Web generadas. Dentro del DSL se definen en las propiedades de la página, para cada acción se indica el nombre del procedimiento que invoca y un conjunto de parámetros. Por ejemplo, si se quiere definir una acción que se aplica sobre un proyecto, y en la página se presenta una lista de proyectos, se puede definir el proyecto seleccionado como parámetro. El requerimiento de generación de estadísticas se puede implementar escribiendo un procedimiento para generarlas y asociando este procedimiento a una acción dentro en una página. Página 42 de 85

46 Previamente se mencionó que para definir un Sistema de Información habrá que definir en primer lugar su Modelo de Datos y luego sus navegaciones. Se agregó un nueva categoría de objetos, que se denominó Catálogo de Operaciones. Aquí se indican los procedimientos que realizan transformaciones u otra operación compleja, para que puedan ser asociados fácilmente a la interfaz de usuario como acciones. Para definir las acciones de una página se muestran las operaciones definidas en el catálogo y se permite seleccionar una de ellas. El Catálogo de Operaciones se conforma simplemente por los objetos que están dentro de una carpeta especial en la Base de Conocimiento. Esta convención permite crear una interfaz más sencilla para definir las acciones, y también ayuda a ordenar los objetos que componen al sistema Escenarios Alternativos En las secciones anteriores se estudiaron los distintos tipos de operaciones y se definieron los mecanismos necesarios en el DSL para representarlas. En esta sección se analiza si es posible utilizar los mismos elementos definidos en el DSL para realizar estas operaciones dentro de un Sistema de Workflow. También se analiza cómo definir un menú de usuario, e incluir interfaces implementadas fuera del DSL Workflow Un Sistema de Workflow permite definir una secuencia de tareas que se deben ejecutar en un orden preestablecido y deben ser realizadas por usuarios con roles específicos. Por ejemplo, se puede definir un proceso de Ingreso de Requerimientos el cual comience por una tarea de relevamiento en donde un usuario con el rol Analista da de alta el requerimiento, luego un Implementador realiza la tarea de desarrollo, otro la verificación, etc. El Sistema de Wofkflow se encarga de asignar las tareas a los usuarios según sus roles, y una vez que se termina una tarea automáticamente crea la siguiente en el proceso y la envía a los usuarios que corresponda. Los Sistemas de Información generalmente incluyen requerimientos que intentan simular la operativa de la empresa que los utilizará. Esto implica definir procesos que involucran varios grupos de usuarios, pasando datos de uno a otro, y fijando una secuencia de pasos que se debe respetar para completarlos. GXFlow es un producto diseñado para representar Workflows y se integra a GeneXus para implementar las tareas que requieren programación. GXFlow brinda un lenguaje de alto nivel para definir los procesos de negocio (basado en UML), el cual podría considerarse como un lenguaje de dominio específico para definir Workflows. Como este lenguaje ya brinda una solución adecuada para este fin, no se definieron nuevos elementos en el DSL para crear diagramas de procesos, pero sí se buscó facilitar la integración entre las funcionalidades creadas con el DSL y los procesos definidos en GXFlow. a) b) Figura 12. a) GeneXus Process Modeler, b) Bandeja de Tareas Página 43 de 85

47 GXFlow se compone de una herramienta de modelado para definir procesos y un motor de Workflow para administrar las tareas de los usuarios y controlar que se respeten los procesos definidos. La definición de los procesos consiste en indicar sus tareas, las relaciones que hay entre ellas y los roles asociados. Luego, el motor se encarga de administrar las tareas entre los usuarios según sus roles. GXFlow ayuda a definir los procesos y se encarga de gestionarlos, pero no brinda herramientas específicas para construir los programas que se ejecutan en las tareas. Estos programas deben ser implementados con GeneXus y asociados a cada tarea con la herramienta de definición de procesos. El DSL brinda un mecanismo alternativo para definir estos programas. Debido a que GXFlow simplemente requiere objetos GeneXus, y el DSL genera objetos GeneXus, éstos pueden incluirse en un proceso sin muchas modificaciones. De cualquier forma, se definen nuevos elementos para darle más potencia al DSL al representar tareas de procesos y facilitar su integración. Los programas asociados a un proceso no se ejecutan de forma independiente, sino que se ejecutan dentro del contexto de una instancia de un proceso. Esto significa que una tarea de un proceso podría pedir un dato, y que otra tarea luego podría necesitar mostrar o leer este mismo valor. GXFlow brinda un concepto llamado Relevant Data que permite almacenar valores a nivel de una instancia de ejecución de un proceso, y luego leerlos en otras tareas del mismo proceso. Para poder aprovechar esta funcionalidad se definió un nuevo elemento en el DSL que permitiera interactuar con los datos de la instancia de proceso (ver Figura 13) <Workflow> Requerimiento a) r:requerimientos r <Workflow> Requerimiento Documentos Documento b) r:requerimientos r d:documentos[r] <IUD> d Figura 13. a) Tarea para dar de alta o modificar el requerimiento asociado al proceso, b) Tarea que permite ver lo datos del requerimiento que se procesa e ingresar sus documentos Dentro del DSL se incorpora un nuevo símbolo para indicar que las páginas se invocan dentro del contexto de un Workflow. Este elemento se representa con un recuadro gris y el texto <Workflow> en su parte superior. En su interior se indican los elementos que se leen y escriben de la Relevant Data, el formato es nombre:tipo (Tipo es el nombre de una tabla) En la Figura 13.a se define una página que permite ingresar un nuevo requerimiento o modificar un requerimiento ya almacenado en la Relevant Data (para indicar que la página es de ingreso se debe definir en sus propiedades que se genere como Transacción). Al ejecutar la página como transacción, y ser el punto de inicio del proceso, ésta intentará leer de la Relevant Data el requerimiento asociado a la instancia de proceso en que se ejecuta. Si no encuentra un requerimiento asume que se quiere ingresar uno nuevo, en caso de encontrarlo carga sus datos y permite modificarlos. Debido a que en la navegación no se define el proyecto al que pertenece el requerimiento, al ingresar los datos del requerimiento también se pedirá al usuario que identifique al proyecto. Luego, al confirmar la operación se grabará el requerimiento en la Base de Datos, y adicionalmente almacenará una referencia a él en la Relevant Data (grabando su clave) para que pueda ser leído en otras tareas. En la Figura 13.b se muestra una navegación que podría estar en una tarea posterior (a la tarea que está asociado el proceso anterior), allí se despliega el requerimiento que está cargado en la Relevant Data y adicionalmente se permite definir sus documentos. A su vez, el generador de código al conocer que una página se ejecuta dentro de un Sistema de Workflow puede generar código más apropiado. En el código generado se le notifica automáticamente al motor de Workflow que terminó la tarea cuando se cierra la página inicial y también se genera una interfaz más compacta, ya que los programas asociados a las tareas se ejecutan en una ventana emergente (un popup) más pequeña. En resumen, este mecanismo facilita el uso de Workflow y brinda un medio sencillo para interactuar con datos almacenados a nivel de los procesos. Además, permite definir las tareas de un proceso aprovechando los elementos de alto nivel ya definidos en el DSL. Página 44 de 85

48 Menús por Perfil Al diseñar un Sistema de Información generalmente se debe prever que al mismo accederán múltiples usuario con diversos perfiles, y que cada uno debe realizar únicamente las operaciones que le correspondan según su perfil. Para resolver este control de seguridad se utilizó un enfoque basado en menús de acceso. Un usuario tiene permiso para ejecutar exclusivamente las operaciones a las que puede llegar desde su menú, y cada usuario tiene un menú personalizado según el perfil que tenga asociado. De forma complementaria, se brinda un componente prefabricado para definir usuarios y perfiles, y asociarlos (ver sección Desarrollo de la Arquitectura). Adicionalmente, a partir de la información que se ingrese en el DSL se define automáticamente el menú que le corresponda a cada usuario. El objetivo es que utilizando el DSL se pueda lograr un sistema completo, si está compuesto únicamente de entradas y salidas simples. En la Figura 14 se muestra cómo se definiría la entrada de menú Proyectos asociada al perfil Líder de Proyecto y Administrador. Al ejecutar la aplicación la opción aparece solamente en los usuarios que tengan asociado uno de los perfiles mencionados. <Menu> Proyectos Proyecto Proyectos Líder de Proyecto, Administrador p:proyecto <IUD> p Figura 14. Menú por perfil WebPanels y Transacciones Externas Al comenzar a diseñar el DSL se manifestó que se buscaba ofrecer mecanismos de alto nivel para implementar rápidamente requerimientos típicos. Sin embargo, de esta definición se puede extraer que no todos los requerimientos podrán ser implementados con el DSL, por lo tanto, es importante también proveer buenos mecanismos que permitan integrar implementaciones hechas fuera del DSL. En busca de este objetivo se permite incluir referencias directas a WebPanels o Transacciones escribiendo # (numeral) y luego su nombre como se muestra en la Figura 15. El texto con que se identifica la llamada en la página Proyectos se define en la flecha que une a las páginas, y los parámetros se definen en las propiedades del recuadro amarillo dentro de un editor de propiedades. Proyectos p:proyecto Consulta Avanzada #PrjAdvQry 4.9. DSLs Complementarios Figura 15. Referencia al WebPanel con nombre PrjAdvQry Dentro de este capítulo se presentó un lenguaje de alto nivel para ayudar a implementar algunas operaciones típicas en los Sistemas de Información. A través de este lenguaje se buscó brindar una representación en donde se indican las páginas que componen la aplicación, la forma en que se navega, los datos que se muestran o escriben en cada página y las acciones que se realizan. Al definir estas abstracciones se buscó lograr un lenguaje simple, y por este motivo se aspiró a capturar la información más relevante y reducir el nivel de detalle que se captura en él. Esta decisión de diseño introdujo la necesidad de crear un nuevo DSL que permita definir lo que se denominó: formularios. A partir de las navegaciones la Software Factory genera las especificaciones de las páginas en los formularios. Estas especificaciones son editables, por lo tanto, si el formulario que se infirió no resulta adecuado se puede modificar antes de generar la aplicación final. Dentro del formulario de una página se indican los campos que se definen, junto con su etiqueta y el atributo que muestran, también se definen las grillas que se utilizan con sus columnas, entre otros aspectos de más bajo nivel (se brinda una especificación detallada de este lenguaje en el Apéndice B del Manual de Proceso [Cas07], que se entrega junto con este informe). Página 45 de 85

49 Al diseñar las navegaciones también se detectó la oportunidad para definir en ellas las opciones del menú de la aplicación. Desde cada navegación se indica el nombre de la opción que permite invocarlas (cuando no se utilizan dentro de un Sistema de Workflow). Debido a que cada navegación define una opción, para combinar todas las opciones se definió un nuevo DSL. Al indicar el nombre de una opción de menú automáticamente se carga en este DSL, el cual agrupa todas las opciones y permite editarlas, por ejemplo, para cambiar el orden en que se muestran (se brinda una especificación detallada de este lenguaje en el Apéndice C del Manual de Proceso [Cas07]). En resumen, se construyeron tres DSLs para representar distintos objetos con que se construyen los Sistemas de Información: Navegaciones: Brindan una visión global de la aplicación. Definen las páginas que la componen, las rutas que hay entre ellas, los datos que se manejan en cada una y las acciones que se pueden realizar. Formularios: Cada formulario brinda una especificación detallada de una página, contiene toda la información necesaria para poder generar el código que la implementa. Menús: Agrupa las opciones de menú. A partir de este DSL se genera el código que arma los menús de cada usuario. La forma en que interactúan estos lenguajes se describe con más detalle en el siguiente capítulo. Dentro de este capítulo se describieron las opciones de diseño que guiaron la construcción del lenguaje principal (el de navegaciones) y los motivos que dieron origen al resto. También se presentaron sus abstracciones más relevantes de las navegaciones, aunque no se describen de forma exhaustiva todos sus elementos. Para obtener una especificación detallada de este lenguaje junto con el resto se puede consultar el Manual de Proceso [Cas07] Asistencias en Editores El objetivo principal con que se definieron estos lenguajes fue simplificar el proceso de construcción de los Sistemas de Información. Para lograr este objetivo no alcanza con brindar lenguajes compactos, sino que también es necesario complementarlos con editores que permitan utilizarlos eficientemente. En este sentido, se definieron varios editores gráficos con automatismos que asisten a los desarrolladores autocompletando parte de los modelos en base a la información ingresada. De esta forma se reduce la información necesaria que hay ingresar en los modelos. En caso que la información autocompletada sea incorrecta se puede cambiar, lo cual tampoco produce una pérdida de tiempo porque de cualquier forma hubiera sido necesario ingresarla. Se observaron muy buenos resultados infiriendo los formularios a partir de las navegaciones, pero también se implementaron otras ayudas que resultaron beneficiosas. El siguiente esquema documenta las asistencias más importantes implementadas: Asignación del título de la página al escribir una expresión: Si por ejemplo se escribe Clientes para mostrar los registros de la tabla Clientes se asigna el titulo Clientes (el mismo nombre que la tabla). Por otro lado, si se escribe c como expresión (donde c es un registro de la tabla Clientes) se asigna como titulo Cliente (el nombre de la tabla en singular) Pasaje automático de parámetros: Al asignar una expresión que referencia a un registro que el usuario debe seleccionar en una página anterior, se agrega el símbolo en la lista de parámetros de todas las páginas que forman la ruta que las une. De esta forma, el pasaje de parámetros es automático y no es necesario definir la lista de parámetros de cada página. Generación de los nombres de objetos: Luego de definir una página en una navegación se genera de forma automática los nombres de los objetos que lo implementan en base a su titulo. Definición de pestañas según la información presentada: Cuando se muestra en una página información de un registro (por ejemplo, de un requerimiento) y en las páginas siguientes se muestra información relacionada con el registro (por ejemplo, los documentos o reportes de errores asociados al requerimiento) se definen automáticamente pestañas para presentar los datos (ver sección Un Caso Sencillo) Generación de formularios: Luego de definir una página se infiere un formulario completo para implementarla. Cuando se muestra un conjunto de registros se genera una grilla, cargando cada atributo en una columna y asignando los títulos de las columnas en base a las descripciones de los atributos. Si se muestra un registro se define un conjunto de campos, uno por cada atributo según su tipo de dato, y mostrando a la izquierda su descripción. De esta forma se genera un formulario base para cada página, que luego puede ser ajustado. El tiempo necesario para modificar un formulario base es menor que el tiempo que implica crear uno completamente. En una prueba que se realizó Página 46 de 85

50 luego de implementar los editores más del 90% de la información sugerida resultó adecuada y sólo hubo que cambiar un 10% (en el Capitulo 6 se describe esta experiencia) Conclusiones En este capítulo se exploró el concepto de Desarrollo Conducido por Modelos (una de las Innovaciones Criticas de la propuesta de Software Factories) y se diseñó un lenguaje que lo aplica sobre Sistemas de Información. Este lenguaje busca capturar las características del diseño, y luego utilizar generadores de código para inferir la implementación en base a patrones de código predefinidos. De esta forma, los desarrolladores se concentran en definir el diseño, es decir, lo que diferencia a cada sistema de la familia de producto, y los generadores se encargan de escribir código repetitivo para resolver los problemas comunes. En busca de abstracciones más específicas para los Sistemas de Información se analizaron tres definiciones que describen esta clase de sistema. A partir de este análisis se extrajo que se componen de cuatro tipos de operaciones básicas: entradas, salidas, procesamientos y almacenamientos. Se consideró que las operaciones de almacenamiento ya son resueltas de buena forma por los motores de Base de Datos y GeneXus, por lo tanto para diseñar el lenguaje se estudiaron las tres primeras. El proceso de diseño se realizó a través de un Caso de Estudio, el cual proporcionó ejemplos concretos para analizar cómo representar las operaciones anteriores con abstracciones más específicas. El propósito de esta forma de trabajo fue crear un lenguaje práctico lo más cercano posible a las necesidades de un sistema real. Adicionalmente, ayudó a ordenar el diseño y a evaluar el grado de completitud del lenguaje para resolver requerimientos. Sin embargo, con este enfoque se corrió el riesgo de crear algo demasiado específico para el Caso de Estudio y que no se pueda utilizar en otros sistemas. Por lo tanto, para mitigar este riesgo se apoyó la tarea de diseño con la experiencia que se tenía en otros sistemas del mismo tipo. Luego de reconocer una nueva abstracción se exploró mentalmente cómo se podrían representar otros requerimientos con ella. Por lo tanto, si bien esta metodología basada en un Caso de Estudia resultó efectiva, es necesario complementarla con experiencia en el dominio. Se buscó un lenguaje compacto y sencillo, para lograrlo se definieron dos niveles de abstracciones. Uno que permite definir el sistema con abstracciones de muy alto nivel que buscan capturar la información más relevante (a través de navegaciones), y un segundo nivel en donde se obtiene información complementaria necesaria para generar una aplicación ejecutable a partir de estos modelos. Adicionalmente, se observó que el segundo nivel, en el cual se define la especificación detallada de cada página, podría deducirse a partir del primer nivel. Sin embargo, debido a que se parte de información parcial se permiten editar los modelos de este segundo nivel por si los datos inferidos son incorrectos. Sin embargo, si las deducciones son lo suficiente buenas se simplifica aún más el desarrollo, porque es necesario ingresar menos información a los modelos. De esta forma, se diseñó un lenguaje que busca resolver los casos más comunes de forma sencilla. Sin embargo el lenguaje es limitado, no aspira a construir sistemas complejos, ni tampoco resuelve todos sus aspectos. Se centra en definir la interacción entre el usuario y la aplicación, y sólo implementa algunas operaciones básicas sobre la Base de Datos. Para no limitar el uso del lenguaje únicamente a sistemas que puedan construirse completamente con él fue necesario explorar cómo lograr una buena integración con objetos GeneXus escritos de forma tradicional. En este sentido, se permite asociar procedimientos con código GeneXus a la interfaz, se brinda la posibilidad de incluir WebPanels y Transacciones creadas fuera de la Software Factory, se incluyeron mecanismos de integración con Workflow y también se implementó un esquema que permite definir las reglas de negocio con Transacciones y replicarlas a todos los lugares donde sea necesario aplicarlas. Dentro de este capítulo se presentó un enfoque posible para implementar el concepto de Desarrollo Conducido por Modelos sobre Sistemas de Información. En el siguiente capítulo se describen los distintos mecanismos que se estudiaron para implementarlo y dar la posibilidad de generar aplicaciones ejecutables a partir de los modelos. Página 47 de 85

51 Página 48 de 85

52 Capítulo 5 Construcción de los DSLs Con este proyecto se planteó como meta estudiar si los conceptos de las Software Factories [GS04] pueden ayudar a facilitar la construcción de Sistemas de Información (con GeneXus). Se comenzó analizando y comprendiendo en qué consiste la propuesta de Software Factories. De allí se extrajo que se basa en construir herramientas, procesos y componentes enfocados en un dominio concreto. Mayoritariamente, hoy día se utilizan lenguajes y procesos de desarrollo de propósito general para construir aplicaciones (como por ejemplo, Java,.Net, UML, RUP); la propuesta de Software Factories busca subir un nivel, y especializarse en problemas con un alcance más reducido. Esto permite crear abstracciones más específicas y procesos más optimizados, lo cual promueve una mayor productividad y efectividad. Si bien crear estas herramientas y procesos tiene un costo extra, se pueden justificar por las ganancias que permiten obtener. La propuesta de Software Factories está basada en la unificación de ideas claves en Reuso Sistemático, Desarrollo Conducido por Modelos, Desarrollo por Ensamblado y Marcos de Procesos. El capitulo anterior se centró en aplicar los conceptos de Desarrollo Conducido por Modelos sobre Sistemas de Información, el resultado fue un lenguaje gráfico (un DSL) que permite definir consultas e ingresos de datos de forma simple y compacta. También se aplicaron, aunque en menor medida, conceptos de Reuso Sistemático (al brindar una forma espontánea de aplicar soluciones predefinidas en la forma de patrones) y también conceptos de Desarrollo por Ensamblados (al proporcionar mecanismos para integrarse con un motor de Workflow y con un sistema de administración de usuarios). Los conceptos de Marcos de Procesos se aplicaron al diseñar el proceso que se presentó en el Capitulo 3 y que se describe de forma más detallada en el Manual de Proceso [Cas07]. Como se mencionó previamente, una de las dificultades del Desarrollo Conducido por Modelos es el tiempo que lleva implementar las herramientas. En lo que sigue se muestra una infraestructura genérica construida para implementar los DSLs y cómo con ella se pudo reducir el tiempo necesario para implementar cada uno de estos lenguajes. La finalidad de este capítulo es describir los problemas que hubo que enfrentar al implementar los DSLs de la Software Factory. Se comienza estudiando características deseables de una implementación de un DSL, y luego se presenta la arquitectura con que se lograron resolver estos desafíos. Adicionalmente, se brinda una base teórica más formal que pueda ayudar a guiar otras implementaciones Capturando Intenciones De acuerdo con Charles Simonyi [Sim95] las intenciones describen lo que se busca cuando se escribe código. Al implementar una solución, se suelen construir imágenes mentales con el diseño que se aspira implementar, estas imágenes reflejan las intenciones. Por ejemplo, para implementar una consulta dentro de un Sistema de Información es una práctica común imaginar qué información se le mostrará al usuario y cómo será su interacción para obtenerla. Dichas imágenes mentales representan las intenciones que se quiere reflejar en el código. Sin embargo, esta tarea requiere traducir los conceptos de alto nivel en construcciones de programación de bajo nivel. El código es la traducción de la intención expresada en elementos ejecutables. Jacobson estima que típicamente el 80% del trabajo hecho para lograr esta traducción es de memoria, mientras que sólo el 20% es creativo [Jac04]. El uso de herramientas que automaticen el trabajo de memoria, realizando la traducción de modelos de alto nivel a código, permite a los desarrolladores concentrarse en las tareas creativas. Además: Reducen el costo y el tiempo de desarrollo al automatizar las tareas tediosas de programación. Aumentan la calidad de las soluciones utilizando prácticas probadas realizadas por programadores expertos. Permiten lograr soluciones que serían inviables si hubiera que programarlas manualmente. La evolución y migración del software puede ser realizada de forma más fácil y eficiente. Sin embargo, para lograr todos estos beneficios hay que implementar patrones y algoritmos que automaticen la toma decisiones, y fundamentalmente hay que poder extraer toda la información necesaria para tomar estas decisiones. En este objetivo se centran los DSLs, en buscar asistir el diseño para capturar las intenciones de los desarrolladores y generar a partir de ellas el código que las implemente. Página 49 de 85

53 Sencillez versus Completitud En el capítulo anterior se mencionó que al diseñar el DSL uno de los mayores desafíos fue conciliar sencillez con completitud. Por un lado se buscaba un lenguaje sencillo, pero al mismo tiempo lo suficientemente completo como para generar objetos ejecutables a partir de él. Para solucionar este conflicto de intereses se propuso utilizar varios modelos que apuntan a capturar distintos niveles de detalle. En los modelos de los niveles más altos se pretende obtener un diseño global de la solución, la clase de diseño que se hace en las fases más tempranas de los proyectos. Luego, utilizando modelos de más bajo nivel se capturaran detalles adicionales que se omitieron en los de más alto nivel. Por ejemplo, en los diagramas de navegación se capturan las entidades que se muestran en cada página y de esta forma se da una visión global de la interacción con el usuario. Sin embargo, se omiten detalles como los atributos que se muestran para evitar abrumar los diagramas. Estas definiciones se trasladan a modelos separados de más bajo nivel, uno por cada página, llamados formularios. Allí se indica la lista de atributos a mostrar, las etiquetas de los campos, etc. Luego, se toman estos últimos modelos para escribir código HTML y GeneXus, y finalmente los generadores de GeneXus traducen este código a programas ejecutables. En la Figura 16 se presenta un esquema con las transformaciones entre los distintos modelos. Diagramas de Navegación Proyecto Requerimientos Requerimiento p:proyecto r:requerimiento[p] r Proyectos Requerimientos Requerimiento Formularios Objetos GeneXus Web Panels Web Panels Web Panels Programas Ejecutables.dll.dll.dll Figura 16. Transformaciones entre distintos modelos Dentro de la figura se muestra un diagrama de navegación en el cual se muestra un proyecto, luego los requerimientos del proyecto y finalmente los datos de un requerimiento. Para cada página del diagrama de navegación se define un formulario. En el formulario se indica que, por ejemplo, para los requerimientos se va a utilizar una grilla con dos columnas, una con sus identificadores y otra con su nombre. Es decir, el formulario es la especificación de la página en la cual se muestran los datos. A partir de esta especificación se genera un objeto GeneXus con el código HTML que define la representación visual, y también código que implementa las opciones disponibles. Finalmente, este código se traduce en programas ejecutables. Al construir la Software Factory se estudió esta forma de trabajo en los DSLs. Al diseñarla se hicieron varias observaciones que demostraron ser útiles luego, así que como aporte de este trabajo se definieron dos conceptos que las reflejan, estos son: Diseño Progresivo y Generación Deductiva. En el capitulo anterior se introdujeron brevemente estos conceptos, en las siguientes secciones se da una descripción más amplia de ellos. Luego se presenta la arquitectura que se definió para implementarlos. Página 50 de 85

54 5.2. Diseño Progresivo Desde que comienza un proyecto de construcción de un sistema, se atraviesan distintas fases en las cuales poco a poco se va conociendo más de la aplicación que se debe construir. Al final, si el proyecto fue exitoso, se culmina con un sistema que refleja un punto de acuerdo entre las expectativas de los usuarios y las limitaciones impuestas para el proyecto, como los recursos asignados, el tiempo fijado y el alcance definido. El proceso de creación generalmente es progresivo. Se comienza con una separación del sistema en módulos y componentes, y se define la arquitectura general. Luego que se define la arquitectura se pasa a diseñar más detalladamente cada uno de estos módulos, hasta llegar a un nivel que puede ser traducido a un lenguaje de programación o una herramienta de desarrollo de alto nivel. Finalmente, se utilizan estas herramientas y se escribe código para implementar cada funcionalidad hasta lograr tener archivos que sean ejecutables dentro de un computador. Es decir, se parte de modelos de alto nivel, y a medida que se llegan a acuerdos en ellos, se pasa a modelos de más bajo nivel para definir información complementaria hasta llegar a la aplicación ejecutable. Este proceso de diseño progresivo es el que se buscó reflejar en el modelo de programación de los DSLs. Primero se parte de un diagrama de navegación, que describe qué páginas van a constituir la aplicación Web, y con qué entidad se va a trabajar en cada una de ellas. Luego que se llega a un acuerdo en las navegaciones, se pasa a la definición del formulario para cada página, en la cual se define más precisamente con qué atributos se va a trabajar, qué titulo se va a mostrar para cada columna, etc. A esta forma de trabajo se le denominó Diseño Progresivo. Se utilizó este concepto ya que se considera que refleja de mejor forma la realidad de un proyecto de software. El conocimiento necesario para resolver las necesidades de sus usuarios se obtiene de forma progresiva. Primero se llega a un acuerdo sobre modelos de alto nivel, y luego se pasan a definir detalles adicionalmente en modelos de más bajo nivel Sincronización Esta forma de trabajo presenta algunas dificultades a la hora de implementarla. Hay información duplicada en los modelos. Por ejemplo, para una página de consulta que compone la aplicación su definición deberá estar reflejada tanto en el diagrama de navegación, en el formulario, en el WebPanel (GeneXus) y en el código que implementa el WebPanel. Si bien cada modelo captura aspectos distintos de la página, si se quisiera hacer un cambio en la página debería quedar reflejado en los cuatro modelos. Existen varias estrategias posibles para resolver este problema. Una podría ser desechar los modelos de más alto nivel luego que se tienen los de más bajo nivel. Este esquema es el aplicado al utilizar un proceso en el que se parta de diseños en UML para traducirlos a un lenguaje de programación y luego que la aplicación está implementada si se detecta un cambio se hace en el código pero no en los modelos de alto nivel. Si bien hoy día hay herramientas que permiten hacer ingeniería inversa para actualizar los diseños, no siempre son aplicables, y de cualquier forma hay que invertir horas de trabajo adicional para que todos los modelos estén sincronizados y sean un reflejo real del sistema. Por este motivo, como primera premisa se buscó que los modelos se sincronicen automáticamente ante cambios, para que en todo momento sean una vista confiable del sistema. Una forma de lograr este objetivo podría ser permitir editar sólo el nivel más alto, y dejar que generadores actualizaran automáticamente el resto. Por ejemplo, en GeneXus se define una página Web con un WebPanel, a partir del WebPanel se genera código C#, y luego a partir de éste una dll (con código MSIL, el cual es similar al assembler pero orientado a objetos). Si se quiere modificar la página, se debe hacer la modificación en el WebPanel y luego generar nuevamente el código C# y la dll; si se hiciera la modificación en el código C#, se perdería al volver a generar el WebPanel. Esta estrategia es válida sólo si en los modelos de más alto nivel (los WebPanels en el ejemplo) se tiene toda la información necesaria para generar completamente los modelos de más bajo nivel (el código C# y la dll en el ejemplo). En el caso del DSL utilizar la misma estrategia implicaría permitir editar únicamente los diagramas de navegación y generar completamente el resto a partir de estos. Sin embargo, esto no es posible, ya que la premisa de este esquema es que en los formularios se complementen las navegaciones con información que no hay en ellas (por ejemplo, los atributos que se muestran y las etiquetas asociadas a cada uno de ellos). Por lo tanto, se debe buscar otra estrategia para sincronizar las navegaciones con los formularios. Página 51 de 85

55 De cualquier forma, la estrategia mencionada se puede utilizar a partir de los formularios para generar los WebPanels. La única información necesaria para generar los WebPanels (que no se encuentra en los formularios) es la definición del aspecto (colores, tipos de letra, etc.) y los patrones de código para resolver funcionalidades genéricas (como los filtros, o el paginado). Sin embargo, toda esta información es deseable que sea la misma para toda la aplicación, por lo tanto, se puede encapsular en los generadores de código. En definitiva, no se debe permitir editar los WebPanels, ni el código generado a partir de ellos. Pero sí se debe permitir editar los formularios y los diagramas de navegación, y por lo tanto ambos modelos deben mantenerse sincronizados. Las modificaciones hechas en el diagrama de navegación se deben reflejar en los formularios y viceversa. Sin embargo, las modificaciones hechas manualmente en los WebPanels o en el código de la plataforma (ej. C#) se perderán al volver a ejecutar los generadores. En la Figura 17 se muestra un esquema de este funcionamiento. Cabe destacar que todo lo mencionado para los WebPanels también se aplica en las Transacciones que se generan para representar la interfaz de usuario. Editable Editable No se debe editar No se debe editar Diagrama de Navegación Formulario WebPanel o Transacción Programa Ejecutable Figura 17. Direcciones de sincronización entre distintos modelos En esta sección se buscó mostrar los motivos por los cuales se necesita un esquema de sincronización bidireccional en la implementación de los DSLs. Más adelante se muestra la arquitectura que los implementa y cómo se resuelve con ella este problema Generación Deductiva En la Software Factory se definió un esquema de trabajo de varios niveles. Para construir un Sistema de Información primero se deben definir las navegaciones entre páginas, y luego los formularios de las páginas que componen cada una de estas navegaciones. En la sección anterior se vio que ambos niveles deben poder ser editados por separado, y que un cambio en uno debe replicarse en el otro si corresponde. Si bien hay dos modelos relacionados, no están al mismo nivel. Los diagramas de navegación pertenecen a un nivel de abstracción más alto, y los formularios a un nivel más bajo. Esto significa que las navegaciones contienen conceptos más generales y los formularios conceptos más específicos. En particular, todo lo que se represente en los diagramas de navegación, queda representado en los formularios pero no a la inversa. Visto de otra forma, los formularios contienen información complementaria a las navegaciones. Se estimó que entre un 30% y 40% de la información que está en los formularios también está en las navegaciones. Por lo tanto, a partir de las navegaciones al menos se podría generar ese porcentaje del formulario, para que luego se complemente con la información faltante. De todas formas, se intentó ir un paso más adelante. A partir de la información contenida en las navegaciones y la Base de Conocimiento GeneXus se intentó deducir también el porcentaje de información que falta. Previamente se mencionó que GeneXus para generar código a partir de un WepPanel debe tener toda la información que define la página, para poder determinar sin ambigüedad el código (por ejemplo, C#) que debe escribir para implementarla. Sin embargo, con las navegaciones y los formularios la situación es distinta, ya que el formulario puede ser editado. Por lo tanto, si se construye un generador para escribirlo, éste no tiene por qué construir el formulario correcto para el 100% de los casos, se pueden utilizar heurísticas que apunten a generar un buen formulario para la mayoría de los casos, ya que el programador tiene la posibilidad de editarlo si no es correcto. A este enfoque se le llamo Generación Deductiva. No se tiene suficiente información para construir el formulario completo, si se tuviera no sería necesario permitir que el formulario fuera editable. Sin embargo, al deducir el formulario a partir de información ambigua se puede ayudar a reducir los tiempos de implementación en muchos casos, si las deducciones son lo suficientemente buenas. En definitiva, no sólo se implementaron mecanismos para mantener sincronizados los diagramas de navegación y los formularios, sino que también se implementaron generadores deductivos, que a partir de Página 52 de 85

56 especificaciones ambiguas e incompletas intentan deducir la estructura completa del formulario. Para lograrlo también se aprovechó la información contenida en la Base de Conocimiento GeneXus, en particular, la definición del Modelo de Datos, de la cual se pueden obtener las tablas definidas y sus atributos. Utilizando esta información se determinan los atributos que se tienen que mostrar al referenciar una tabla en una página, y a partir de sus descripciones se determinan los textos que se escriben a la izquierda de cada campo o en los títulos de las columnas dentro de las grillas Anatomía de un Lenguaje Las tareas para implementar un DSL son similares a las necesarias para implementar un lenguaje de programación. Si bien los DSL implementados son gráficos y la mayoría de los lenguajes de programación son textuales, los DSL deben definirse con la misma rigurosidad, ya que se utilizan con un fin similar. En esta sección se estudia brevemente la anatomía de un lenguaje, para identificar los componentes necesarios para implementar los DSLs. En el libro Software Factories [GS04] se diferencian dos clases de lenguajes, los naturales (como el español) y los formales. Los lenguajes formales son aquellos que están diseñados para ser procesados por una máquina, y estos son los lenguajes que interesa estudiar para entender cómo definir un DSL. En la Figura 18 se muestra un diagrama con la anotomía asociada un lenguaje formal. Sintaxis Concreta Sintaxis Abstracta Semántica Sintaxis de Serialización Figura 18. Anatomía de un lenguaje formal Los elementos que componen la anatomía son: Semántica: Define el significado de los elementos que componen el lenguaje. Se debe tener una semántica muy bien definida para que el lenguaje pueda ser procesado por una máquina. El significado de una expresión se tiene que poder determinar con precisión sin necesidad de una interpretación humana. Sintaxis Abstracta: Indica los elementos que componen al lenguaje y las reglas que definen cómo se combinan. Sintaxis Concreta: Define cómo se muestran los elementos del lenguaje en una representación concreta, entendible por humanos (por ejemplo, figuras o palabras). Sintaxis de Serialización: Es similar a la sintaxis concreta, excepto que la representación no está destinada a ser usada por humanos, sino que está destinada a ser entendida por programas. La sintaxis de serialización es utilizada, por ejemplo, para almacenar los modelos en archivos de textos o trasmitirlos a través de la red. En los DSLs implementados, la sintaxis concreta es un diagrama (para las navegaciones) y un árbol (en el caso de los formularios y los menús). También se necesita de un formato de serialización para poder almacenarlos y trasladarlos a otra Base de Conocimiento GeneXus, aquí se utilizó XML. Debido a que se van a definir dos tipos de representaciones para los DSLs, para poder reutilizar parte de la implementación se utilizó el patrón MVC (Model View Controller [Ree79]). Por un lado se definió el modelo con una sintaxis abstracta que define los elementos válidos y la forma en que se combinan. Luego se tienen Página 53 de 85

57 las vistas que son las sintaxis concretas, y por último los controladores que vinculan ambos componentes. La semántica del lenguaje está embebida en los generadores que son quienes lo interpretan. En la siguiente sección se describe la arquitectura completa de forma más detallada Arquitectura de los DSLs A través del estudio de la anatomía de un lenguaje formal se identificaron los elementos que lo definen. A partir de estos elementos se construyó la arquitectura con que se implementa cada DSL. La misma está conformada por 6 componentes principales: Modelo: Permite representar una instancia de un DSL, por ejemplo, un diagrama de navegación para consultar los requerimientos de un proyecto. Esquema: Define los elementos que componen el modelo y la forma que se combinan. El modelo se utiliza para varios DSL por lo tanto necesita de una estructura genérica (similar a un XML). El esquema es el responsable de fijar una estructura concreta para un DSL (como lo hacen los XSD en los XML). Aquí se define la sintaxis abstracta del lenguaje (ver sección 5.5 Anatomía de un Lenguaje). Editores: Los editores expresan los modelos en un formato entendible por humanos. También brindan una interfaz para modificarlos. Se implementaron dos tipos de editores (uno para diagramas y otro para representaciones en forma de árbol). Cada uno permite definir lo que se denomina sintaxis concreta en la anotomía de un lenguaje. Diseñadores: Actúan como vínculo entre los editores y los modelos, indican cómo representar los elementos de un modelo dentro de un editor concreto. Cumplen el rol de los controladores del patrón MVC (los editores definen las vistas, y el modelo representa al componente del patrón con este mismo nombre) Coordinador: El coordinador se utiliza para sincronizar los cambios entre distintos modelos. Previamente se mencionó que los diagramas de navegación y los formularios están relacionados. Al definir una página con la lista de proyectos en una navegación, el coordinador es el encargado de actualizar el formulario asociado agregando una grilla y sugiriendo la lista de columnas a mostrar. Plantillas de código: Definen patrones de código para traducir los modelos a código GeneXus que pueda ser generado para construir una aplicación ejecutable. En la arquitectura definida, implementar un DSL implica: Declarar un nuevo tipo de objeto en GeneXus para almacenar los modelos Definir el esquema del DSL Asociar un editor y los diseñadores que indican cómo interactúa el editor con el modelo Opcionalmente, se puede asociar un coordinador para sincronizar los cambios con otro modelo, y si corresponde plantillas de código para transformar el modelo a objetos GeneXus ejecutables. En la Figura 19 se muestra un diagrama con estos componentes y las dependencias entre ellos. Editores Diseñadores Modelo+Esquema Modelo Esquema Plantillas de Código Coordinador Figura 19. Componentes para implementar los DSLs Página 54 de 85

58 En el proyecto se implementaron tres DSLs, cada uno define un nuevo tipo de objeto en GeneXus: Navigation: Permite definir los diagramas de navegación que se presentaron en el capítulo anterior. Form: Brinda un modelo declarativo para diseñar páginas Web. En este modelo se puede indicar, por ejemplo, que se va a mostrar una grilla con ciertos atributos de la Base de Datos, y luego utilizando plantillas de código se transforma a código HTML y GeneXus que despliega la grilla y carga con datos. Menu: Define el menú de la aplicación. Dentro de las navegaciones se indica la opción de menú desde donde se parte, y a través de un coordinador automáticamente se copian a un objeto de este tipo. En este objeto se agrupan todas las opciones posibles que puede tener el menú. Utilizando plantillas de código este objeto se traduce a un procedimiento GeneXus que se invoca cuando se inicia la aplicación y configura el menú del usuario actual. Los DSL se implementaron en C# utilizando Visual Studio y se definieron como extensiones de GeneXus Rocha. Se utilizaron versiones CTP (Community Technology Preview) durante el desarrollo (ver sección Creación de Activos de Implementación) En los siguientes párrafos se describe cómo se diseñaron cada uno de los componentes de la arquitectura indicando cuáles fueron los problemas que se enfrentaron y cómo se resolvieron Modelo Este componente se utiliza para representar una instancia de un DSL. Al diseñarlo se buscó crear un conjunto de clases que pueda ser reutilizado en varios DSLs, en particular, se iban a definir tres DSLs y se buscó que este mismo componente pudiera ser utilizado en ellos. Cada DSL debe tener un lenguaje preciso, con una estructura bien definida, sin embargo, para lograr reusar el modelo se debían utilizar las mismas clases para los distintos lenguajes. Para lograrlo, se diseñó un modelo genérico, al cual se le asocia un esquema que permite restringirlo para un lenguaje particular. El modelo es similar a la estructura de XML, se define a partir de un documento con elementos y atributos. El documento define un elemento raíz, luego cada elemento puede a su vez tener elementos hijos y atributos para almacenar distintos valores (por ejemplo, en las navegaciones cada página se puede representar con un elemento, y dentro de ese elemento se puede utilizar un atributo para almacenar su titulo). Figura 20. Clases y atributos principales en la implementación del Modelo En la Figura 20 se muestra un diagrama generado con Visual Studio 2005 con las clases y propiedades principales de la implementación. En el diagrama no se hace una enumeración exhaustiva de todos los elementos que componen la implementación, ya que esto afectaría la claridad del diagrama con detalles muy particulares. Sólo se incluyen los elementos más relevantes que permitan entender los lineamientos de la implementación seguida. El uso de un modelo flexible fue muy útil luego al construir los DSL, ya que permitió reutilizar varias operaciones implementadas de forma genérica allí. Todas las operaciones que se podían resolver interactuando con el modelo y leyendo el esquema, se implementaron directamente en el modelo. De esta forma, al definir un nuevo DSL se pueden aprovechar y no es necesario reimplementarlas. En particular, el último DSL que se construyó fue el que se utiliza para el Menú y se armó en unas pocas horas reutilizando el modelo y los editores ya definidos. Algunas de las funcionalidades que se encapsularon en el modelo fueron las de copiar/pegar, deshacer/rehacer y también la serialización/deserialización para poder almacenar y recuperar un modelo de texto en formato XML. La principal desventaja del uso de un modelo genérico se refleja en el código C# que hay que escribir para interactuar con él. Hay que escribir más código que si se hubieran diseñado clases específicas para representar cada DSL. En lugar de consultar directamente una propiedad, se tiene que obtener la colección Página 55 de 85

59 de atributos y pedir el atributo deseado. Sin embargo, esta pérdida no es significativa como para opacar las ventajas de reutilización que se mencionaron previamente. Si bien también hay una pérdida de eficiencia al utilizar un modelo más genérico, no se observaron consecuencias perceptibles en este sentido Esquema Para poder utilizar el modelo en un DSL particular hay que definir cuáles son los elementos y atributos válidos en él y cómo se combinan. Esto se realiza asociando un esquema. Como se mostró en la Figura 20, el documento, los elementos y los atributos del modelo tienen asociado un esquema (ver propiedad Schema). En la Figura 21 se muestran las clases principales con que se implementaron los esquemas. Figura 21. Clases y atributos principales en la implementación del Esquema El esquema de un DSL se define a través de la clase MDocumentSchema, la cual determina la estructura del documento en el modelo. El documento define el elemento raíz y opcionalmente un coordinador que se puede utilizar para sincronizar cambios entre dos modelos (no necesariamente del mismo esquema). En la sección Coordinador se describe cómo funciona. Para cada elemento del esquema se define cuáles son sus atributos e hijos válidos. También se indica si puede haber hijos repetidos y si se debe respetar el mismo orden con que se definieron en el esquema (propiedad ChildsLayout). Dentro de cada elemento también se define un diseñador (propiedad Designer) que indica cómo se representa el elemento en un editor (este tema se describe en la sección Diseñadores) Con respecto a los atributos, se debe definir un nombre, un tipo de datos para ellos y un valor por defecto. Adicionalmente se pueden asociar validadores (propiedad Validators) para limitar el dominio de valores posibles. Dentro del esquema también se soporta la definición de atributos calculados. Estos se utilizan, por ejemplo, para calcular de forma automática la lista de parámetros en las páginas de las navegaciones. Los atributos calculados se definen indicando un método que los calcula (propiedad Calculator). También se soportan atributos calculados editables, en este caso se asocia un método que se invoca cuando se asigna un valor al atributo calculado. Dentro de este método se deben realizar las modificaciones que correspondan al modelo. En el ejemplo anterior de los parámetros, se utiliza esta funcionalidad para permitirle al usuario definir parámetros adicionales a los que se infieren de la navegación. El uso de esquemas ayudó a lograr funcionalidades genéricas dentro del modelo. Al comenzar a diseñar la arquitectura para los DSL se encontró que había funcionalidades que podrían implementarse genéricamente a partir de un esquema. Luego la implementación se realizó con esta filosofía intentando implementar todo lo posible dentro del modelo a partir del esquema, de forma de poder reutilizar las implementaciones en varios DSL. La serialización de los modelos a XML está implementada leyendo la estructura del esquema, al igual que el editor de árbol. Por lo tanto, únicamente definiendo el esquema de un nuevo DSL ya se puede contar con un editor y un formato de almacenamiento sin necesidad de escribir código adicional. Página 56 de 85

60 Los esquemas se definen directamente desde código C# creando las instancias de las clases que corresponden (ver Figura 21). Se evaluó utilizar archivos de texto externos para definir la estructura de los esquemas. Sin embargo, esta opción no evita completamente la necesidad de escribir código, ya que sería necesario hacerlo para definir atributos calculados o para indicar cómo interactúa un elemento con un editor, entre otras tareas. Por lo tanto, ya que de cualquier forma iba a ser necesario escribir código, se consideró mejor opción definir todo el esquema con código para simplificar su integración y aprovechar las facilidades que brinda el editor de Visual Studio para escribirlo (como por ejemplo, Intellisense). La mayor limitante que se encontró de definir el esquema con código es que restringe la capacidad de extensión del DSL, para poder personalizarlo y agregarle atributos propios es necesario modificar el código fuente y recompilarlo. Se consideró importante dar la posibilidad de personalizarlo sin tener que recompilarlo, así que para atenuar la limitante anterior, se definió un archivo (en XML) que permite agregar atributos y elementos dentro de los DSLs (aunque sin contar con todas las funcionalidades que se obtienen definiendo el esquema desde código). En la sección 5.6 Extensibilidad se describen las capacidades de extensión de los DSL. En resumen, se definió en la arquitectura un componente especializado para definir el esquema de los modelos. Durante el proyecto se tuvo la posibilidad de experimentar con las consecuencias de esta decisión de diseño. Su mayor beneficio fue brindar una herramienta que permitió implementar funcionalidades de forma genérica y aprovecharlas en todos los DSLs, lo cual simplificó su desarrollo. Por el lado de la implementación, la mayor desventaja fue que al no contar con archivos de definición externos se limitaba la capacidad de extensión del lenguaje. Para resolver esta dificultad, se creó un formato de archivo que permite definir algunas extensiones simples sin necesidad de recompilar el código Editores Los editores brindan el medio que permite a los usuarios de los DSLs interactuar con sus modelos. A partir de los editores se puede crear y borrar elementos dentro de un modelo, y modificar los valores de sus atributos, siempre y cuando se respeten las restricciones del esquema. Los editores se implementaron siguiendo el patrón MVC. Cada editor definir una vista sobre un modelo. Se implementan de forma genérica para que un mismo editor pueda ser reutilizado con distintos lenguajes. Las particularidades de cada DSL se encapsulan en los diseñadores (clases que heredan de MElementDesigner), los cuales actúan como puente entre las vistas y los modelos. Los diseñadores cumplen el rol del controlador en el patrón MVC. a) b) Figura 22. a) Diagrama de Navegación, b) Diagrama de Árbol Se implementaron dos tipos de editores (ver Figura 22): Diagrama de Navegación: Este primer tipo de editor se diseñó para representar los diagramas de navegación. Es un editor gráfico que permite ver las páginas que componen una navegación y las Página 57 de 85

61 rutas que permiten ir de un lado al otro. Se utiliza únicamente para el DSL que representa los Diagramas de Navegación. Árbol: Brinda una vista de árbol con los elementos que componen el modelo y sus hijos. Este editor proporciona una representación genérica que puede ser adaptada fácilmente a distintos DSLs, en particular se utilizó para el DSL que define formularios y el que define menús. Ambos editores se complementan con el editor de propiedades que brinda GeneXus. Este último se utiliza para modificar los atributos de un elemento luego que se seleccionó. Se siguió este enfoque para ser consistente con los editores estándares de GeneXus, los cuales siguen la misma filosofía Diagramas de Navegación Para los diagramas de navegación se decidió implementar un editor específico, ya que en ellos se invertirá la mayor parte del tiempo al utilizar esta Software Factory. Se buscó implementar un editor altamente especializado para esta tarea, que permita visualizar los diagramas y brinde una interfaz sencilla para modificarlos. Antes de comenzar a implementar el editor, se analizaron algunos productos que podrían ayudar a implementarlo. Se analizó la herramienta DSL Tools [Mica] (de Microsoft), sin embargo, la misma está diseñada para utilizarse dentro de Visual Studio y no dentro de GeneXus, por lo tanto, tuvo que descartarse esta opción. Otros productos analizados fueron Diagram. for NET [Dal] (de Dalssoft) y Diagram [Nev] (de Nevron). Ambos componentes se enfocan principalmente en la visualización y no en la edición, por lo que las capacidades que tienen para esta última tarea son limitadas. Como el DSL se enfoca principalmente en la edición se encontró que había bastante para ganar implementando completamente el editor sin utilizar estos productos. Así que este fue el camino que se siguió. El editor se implementó utilizando las clases de la librería gráfica GDI+ incluida en.net. Se diseñó como una vista del modelo, el editor muestra la instancia actual del modelo y utilizando eventos detecta si ocurre algún cambio y actualiza la representación. Por ejemplo, si se asigna un nuevo valor a un atributo, se dispara un evento en el modelo que indica que un atributo cambió, el editor recibe este evento y si corresponde actualiza la visualización para mostrar el nuevo valor. De esta forma, el editor se actualiza tanto si se hacen modificaciones en el modelo a través del editor o por fuera de él. Esta característica fue esencial para poder implementar el componente de coordinación (ver sección Coordinador). Otra característica en la que se puso énfasis fue en logar una interfaz muy simple para crear diagramas de navegación. La Software Factory aspira a brindar un medio que permita crear Sistemas de Información más rápidamente que con los métodos tradicionales. Para definir la interfaz de usuario se utilizarán principalmente los diagramas de navegación, por lo tanto, para satisfacer el objetivo de productividad es importante que el editor sea práctico y permita definir estos diagramas en poco tiempo. Por este motivo, durante el desarrollo se dedicó tiempo a experimentar con interfaces distintas a las tradicionales, para intentar brindar un aporte también en este sentido. Generalmente los editores de diagramas (como por ejemplo, Microsoft Visio) se basan fuertemente en el uso del ratón, tanto para seleccionar elementos existentes, como para agregar nuevos (los cuales se arrastran de una paleta de figuras). En el editor de navegaciones en cambio se buscó hacer un editor más enfocado al uso del teclado como lo hacen los editores de texto, a pesar de que sigue siendo un editor gráfico que muestra figuras y no sólo texto. El uso del ratón, implica que se debe invertir tiempo mirando la pantalla y en mover con precisión el cursor del ratón para seleccionar un punto especifico. En un editor de texto, además del ratón también se puede utilizar el teclado para mover el cursor, y si la distancia es corta suele ser más rápido moverse con las teclas a una posición específica que con el ratón. En busca de agilizar el uso del editor de diagramas se intentó simular la misma experiencia que se tiene en los editores de texto implementando mecanismos de selección a través del teclado. También se incluyó la selección con el ratón para poder comparar los dos esquemas (y además porque puede ser más intuitivo para algunos usuarios). En la experiencia se observó que el uso del teclado dentro del diagrama de navegación también permite moverse de forma más rápida que con el ratón cuando los elementos son cercanos, al igual que lo observado en los editores de texto. Si se selecciona un campo de texto dentro del editor de diagramas se puede editar presionando F2 o escribiendo sobre él, también se permite borrar elementos utilizando la tecla Suprimir (al igual que en los editores tradicionales). Página 58 de 85

62 El otro aspecto que se buscó cambiar fue la forma en que se agregan nuevos elementos, tradicionalmente esta función se implementa arrastrando y soltando figuras de una paleta, aquí se buscó implementarla utilizando exclusivamente el teclado. Para hacerlo se incluyó un cursor intermitente como el que se encuentra en los editores de texto (ver Figura 23). Este cursor se puede mover con las flechas y cuando se pasa sobre un elemento se selecciona. También se definen posiciones de ingreso. Cuando el cursor está en una de estas posiciones, si se escribe un carácter alfanumérico se crea un nuevo elemento en la posición. Con este mecanismo para agregar una nueva página se debe posicionar el cursor en el lugar donde se quiere agregar y escribir el dato que muestra. Adicionalmente, al agregar nuevas páginas de esta forma el editor se encarga de alinearlas y agruparlas de forma ordenada en el diagrama. Figura 23. Cursor (a la derecha de la página Documentos) Con este enfoque, se permite definir las páginas de un diagrama de navegación y sus rutas exclusivamente con el teclado. Al comparar el tiempo que se necesita para definir un diagrama de esta forma, con el que lleva utilizando una herramienta tradicional como Microsoft Visio, se observó que el enfoque basado en teclado resulta considerablemente más práctico y productivo. Como último aspecto a destacar de la implementación del editor, es que muchas de sus funcionalidades se implementaron a nivel del modelo y no del editor. Mientras se implementaba se encontraron funcionalidades que eran comunes a los dos editores, como el cortar/copiar/pegar y el deshacer/rehacer. Por este motivo se buscó implementarlas en las clases del modelo de forma de poder reutilizarlas. En particular, la funcionalidades de deshacer y rehacer se implementaron registrando los cambios que se realizan en el modelo (como por ejemplo, agregar un nuevo elemento, asignar un valor a un atributo), luego para deshacer un cambio se deshacen las operaciones realizadas en sentido inverso, y el editor se actualiza automáticamente al capturar los eventos producidos por modificar el modelo. Aquí entonces se ve otro beneficio de utilizar un esquema de eventos para actualizar el editor ante cambios Árbol El editor de diagramas fue especializado para definir navegaciones, en cambio en el editor de árbol se buscó lograr una implementación más genérica ya que se iba a utilizar para dos DSLs: el que permite definir los formularios de las páginas y el que contiene las opciones a mostrar en el menú principal. Este editor se implementó leyendo el esquema del modelo que se edita, el árbol refleja su estructura. A partir del esquema se determinan cuáles son los hijos válidos para cada elemento y también sus atributos. Además restringe las operaciones que puede hacer el usuario sobre el editor (por ejemplo, en función del esquema se determina si se pueden agregar elementos repetidos). Al utilizar un diseño tan estrechamente vinculado con el esquema no es necesario escribir demasiado código para configurar el editor a un nuevo DSL, simplemente basta con definir el esquema del lenguaje. La única configuración adicional requerida es indicar el ícono que Página 59 de 85