CapicuaGen, Generador automático de Código Empresarial

Hace aproximadamente un año presente la tesis de mi máster en investigación en ingeniera de software, la cual base en la creación de un sistema generador automático de código llamado CapicuaGen. Durante todo este año decide tomarme un descanso del proyecto, al haberle delicado, en su momento, mucho tiempo y esfuerzo. Sin embargo he decido que ya es hora de continuarlo, para establecerlo como una buena herramienta de generación de código empresarial.

Mi tesis puede encontrarse en el siguiente enlace:

https://drive.google.com/open?id=0B9lWgpHFJMEiZWJEaU9BS0xsaE0

Con una pequeña presentación:

https://drive.google.com/open?id=0B9lWgpHFJMEiSE5rdEI2NGkxbFU

También puede encontrarse más información sobre los fuentes y compilados del proyecto en:

http://desdelashorasextras.blogspot.mx/2016/08/capicuagen-desarrollo-de-software-en-la.html

Contexto

CapicuaGen se ubica dentro de los tipos de herramientas conocidas como "Generadores de código", siendo su especialidad la generación de código con enfoques empresariales.

Los "Generadores de código" son sistemas (o partes de sistemas) cuya funcionalidad, como dice su mismo nombre, es crear el código fuente de un sistema destino a través de una configuración o especificación de una necesidad establecida previamente.

El cómo se especifica dicha necesidad puede variar entre distintos enfoques para cada generador en particular, pudiendo ser mediante un diseño en UML, un lenguaje específico del domino (DSL) o cualquier otro mecanismo, pero teniendo todos ellos en común que son más afines a características y elementos de negocio que a temas de índole técnicos en concreto. Esto es porque intentan llevar la abstracción de la construcción de sistema a un nivel más elevado que la programación directa en un lenguaje en particular.

Ilustración 1. Ejemplo de generador de código.

CapicuaGen nace dentro de un contexto empresarial basándose en dos principios, por los que se considera que es beneficioso el uso de generadores de código.

• El software va a cambiar: Los cambios son necesarios para el negocio , además se dan de forma cada vez más frecuente, lo cual tiene un alto impacto en las empresas. Debemos poder responder a la necesidad de dicho cambio para que nuestra empresa siga vigente en el mercado de la forma adecuada. Los generadores de código nos pueden ayudar a gestionar dichos cambios de una manera más sencilla y rápida.
• El software se parece entre sí: Casi todo el software empresarial se parece entre sí. La mayoría de las compañías gestionan recursos de algún tipo (humano, económico, etc.) y generan un producto (dinero, servicios, o bienes de alguna naturaleza). Técnicamente hablando, casi todos los sistemas tienen características como acceso a datos, seguridad, interacción con el usuario o trazabilidad. Los generadores de código nos ayudarán a crear apropiadamente todos estos elementos comunes, disminuyendo el tiempo y los recursos dedicados a tal efecto.
  
  

Acerca de CapicuaGen

CapicuaGen es un proyecto de código abierto, bajo licencia LGPL, que puede ser usado tanto para crear software comercial, como software libre.

Es un proyecto modular, basado en un generador central, que delega en elementos más pequeños conocidos como "Generadores de características", cuya misión es generar un aspecto en particular de un software destino, como puede ser la interfaz gráfica, la capa de acceso a datos, o la exposición de servicios y funcionalidades a través de una red corporativa o pública.

Los generadores de características son intercambiables e independientes, pudiendo elegir los que sean más convenientes para un escenario en particular, y cambiándolos cuando sea necesario. Igualmente pueden organizarse en repositorios públicos o privados (empresariales) y ser de fácil acceso para su uso, implementación y ampliación.

El uso del generador y la contracción de los repositorios se sustentan sobre lenguajes y tecnologías ampliamente adoptados por la industria, como Git, Ruby o repositorios públicos como GitHub, o RubyGems, con lo que su curva de aprendizaje es corta y sus capacidades de distribución y ampliación son altas.

El funcionamiento general de CapicuaGen es representado por el siguiente diagrama:

Ilustración 2. Diagrama de funcionamiento de CapicuaGen.

CapicuaGen es, a la fecha, un proyecto personal construido durante un periodo de seis meses, que contiene una serie de generadores de características sencillas expuestas a nivel didáctico, pero plenamente funcionales. Debido a su naturaleza de índole abierta, y su escalabilidad, es de desear que pronto pueda ampliarse con nuevas e interesantes características, aumentando cada vez más su potencia y utilidad.

Las capacidades generadoras que posee en la actualidad son las siguientes:

•  Generación de proyectos para Visual Studio 2015.
•  Creación de proyectos de escritorio.
•  Creación de proyectos para exposición de servicios Web.
• Generación de proyectos para Android Studio 2.0.

No hay ninguna restricción en cuanto a la tecnología o lenguajes para los que es posible generar código fuente, siempre que exista un generador adecuado para tal efecto. En los ejemplos anteriores generamos elementos para Windows, Web, Android, y en C#, Java o XML.

Igualmente y tal como se verá en la descripción específica de la solución desarrollada, CapicuaGen está pensado para ser parte del ciclo de trabajo del desarrollo de un sistema, permitiendo ampliar su funcionalidad y reciclándola para nuevos proyectos según se muestra en el siguiente diagrama:

Ilustración 3. Diagrama de flujo de trabajo de CapicuaGen.

Objetivos de CapicuaGen

Los objetivos a conseguir son los siguientes:

• Agilizar la construcción de un sistema a partir del uso de generadores de código que creen de manera adecuada las características comunes ensamblándolas apropiadamente.
• Reducir la programación manual de un sistema a los elementos particulares que así lo requieran, esto es, a aquellas partes que son exclusivas de dicho sistema y por lo tanto no están incluidas en otros.

Con el cumplimiento de estos dos objetivos se espera satisfacer las siguientes necesidades:

• Aumento de la calidad del software al generarse en parte de forma automática. Los fallos detectados se podrían corregir en los elementos generadores y aplicar, por ende, al código de los sistemas.
• Los codificadores no perderían tiempo realizando tareas repetitivas y se concentrarían en las que realmente dan valor al sistema y no en aquellas que se duplican desarrollo tras desarrollo.
• Reducción de tiempo de desarrollo , con base en la generación de código automático.

Arquitectura de un sistema empresarial prototipo

En las entradas anteriores establecimos que la gran mayoría del software empresarial se parece entre sí, y entre otros ámbitos de negocio semejantes. Lo que es diferente es la variabilidad de las características que se implementan, cuales son y de qué forma son implementadas.

Vamos a hacer un pequeño acercamiento a la arquitectura de un sistema empresarial prototipo básico. Se muestra un diagrama de bloques de dicho prototipo:

Nota: Debido a que este artículo se creó originalmente como parte del desarrollo de generador “CapicuaGen”, existe varias partes que hacen referencia a dicho generador llamadas “Posibles uso del generador en este contexto”, las cuales se encuentran en cursiva. Si no se está creando un generador de código, o si no es de interés, la parte relativa a “CapicuaGen”, se puede omitir.

Interfaz de usuario

En esta capa se define la apariencia y la interacción con nuestros usuarios y clientes, debe ser lo suficientemente sencilla para que la usen con facilidad, y lo suficientemente completa para que se sea útil. Posibles interfaces son:

Interfaces tradicionales para monitor (computadora)

• Interfaz de escritorio: Puede ser para un sistema de escritorio para Windows, Linux, Mac u otros.
• Interfaz web: Un sitio web tradicional. Aunque HTML y CSS nos garantiza homogeneidad entre los distintos navegadores, ocasionalmente hay pequeñas diferencias de visualizado, que tenemos que tener en cuenta al momento de desarrollar.

Interfaces móviles

• Aplicaciones: Son las aplicaciones nativas desarrolladas para cada dispositivo móvil. En este escenario tenemos que consideran distintas resoluciones de pantalla y tipos de dispositivo como tablet, o smart phones. Podemos desarrollar aplicaciones para Android, iOS y Windows entre otros.
• Interfaz móvil web: Es una interfaz Web diseñada explícitamente para dispositivos móviles (considerando el tamaño de su pantalla).

Posibles uso del generador en este contexto

La interfaz representa lo que puede "hacer" y puede "ver" nuestro usuario, y esto debería ser común para todas las plataformas, el generador debiera ser capaz de crear dicha funcionalidad, y una vez que cambie el negocio, rehacer el código automáticamente para que se adapten todas las interfaces a dichos cambios. Sería necesario contar con una característica generadora para cada plataforma deseada.

Interfaz de servicios

Representa la puerta de acceso a la funcionalidad del negocio. Es una fachada que expone la funcionalidad de forma que la pueda consumir apropiadamente la interfaz gráfica. De esta manera aislamos el negocio, de la forma en la que este es expuesto.

Por ejemplo puede exponerse el negocio de las siguientes formas (entre otras):

• Componentes
• Web Services
• Socket
• RPC
• HTTP

Posibles uso del generador en este contexto

Debido que es un mismo negocio el que se debe exponer y que solo cambia la forma de exponerse, el generador puede crear automáticamente cada fachada necesaria en base a dicho negocio.

Negocio

En esta capa está el problema que queremos resolver en nuestro sistema, representa, en forma de software, la solución a una necesidad a cumplir por la empresa con respecto al mercado.

En esta capa puede haber diversos elementos y diferentes enfoques de resolución, podríamos distinguir los siguientes elementos:

• Entidades de negocio: Son elementos que representan al modelo del negocio, la representación debe ser tanto de información (datos), como de comportamiento, aislar los datos del comportamiento, nos llevaría a un modelo de dominio anémico. [1]
• Flujos de operación: Son elementos que representan que entidades de negocio están vigentes y la forma en la que se convierten en otras. Pueden representar flujos de trabajo que no tengan una correspondencia en una entidad de negocio.
• Acceso a otros componentes: Representan el punto de entrada a componentes ajenos a nuestro software, pueden ser componentes empresariales o componentes externos a nuestra empresa, en cualquier caso esta funcionalidad está aislada, de forma que otros componentes de negocio u otra capa, ignoran el acceso a componentes externos.

Posibles uso del generador en este contexto

Esta parte es muy dependiente de como diseñemos el modelo del dominio de nuestra aplicación, en base a esto podemos crear elementos como:

• Entidades de negocio en base a otros elementos como un UML, o una base de datos.
• Agregar funcionalidad en base a diversas configuraciones.
• Agregar funcionalidad y comportamiento común de la empresa.

Persistencia

Esta capa se encarga gestionar el acceso a diversas fuentes de persistencia, desde donde obtener y guardar la información de nuestro sistema.

Interfaz de persistencia

Expone las funcionalidades de persistencia abstrayendo al negocio de conocer los detalles sobre la tecnología encargada de esta.

Posibles uso del generador en este contexto

Es posible crear las interfaces de los servicios de persistencia, siguiendo algún patrón de software o algo política empresarial sobre cómo deben persistirse los elementos de negocio.

Proveedores de Información

Son los mecanismos concretos por los que se persiste la información. Gracias a la interfaz de persistencia dichos mecanismo podrían ser cambiados por otros, sin afectar al negocio. Algunos de estos mecanismos son:

• ORM.
• Stored Procedures.
• Sentencias SQL.
• XML.
• Archivos de texto.
• Servicios RESTFul.

Posibles uso del generador en este contexto

La persistencia es una de las grandes oportunidades para los generadores de código [2]. Dependiendo de nuestro diseño puede convertir los modelos, en tablas y crear los puntos de acceso para dichas tablas, ya sea por SQL, Stored, o tecnologías ORM. Por otro lado si nuestro diseño comienza por la creación las tablas y procedimientos almacenados (cosa que en principio no es recomendable), se puede crear el acceso a la base de datos, y el modelo a través de ella.

Abstracción del acceso a datos

Mientras la capa anterior trabaja sobre la tecnología de persistencia, esta capa proporciona acceso a dicha tecnología, sin preocuparse donde esté ubicada “físicamente” dicha tecnología. Por ejemplo si el destino es un documento XML, dicho documento puede guardarse en un archivo, en una base de datos, o en cualquier otro tipo de repositorio. Si el destino fuera una base de datos, esta podría ser SQL Server, Informix, MySQL, SQLite, o cualquier otro. Esta capa sabría cómo comunicarse con cada uno de estos proveedores, con independencia de la capa anterior. Igualmente esta capa se encargaría de cualquier tipo de la configuración sobre conexiones y localización de archivos, acorde a las políticas de la empresa acerca del almacén y la seguridad de esta información.

Posibles uso del generador en este contexto

El generador puede ayudarnos a crear el código necesario para el acceso a los repositorios de información, y además puede generar distintos accesos, para simular diversos esquemas de persistencia en un ambiente de pruebas o de desarrollo.

Seguridad

Es una capa que afecta a todas las demás independientemente de lo profundas o externas que sean [3]. Los servicios que ofrecen la capa de seguridad son (entre otros):

• Autentificación: Garantiza que la persona que está usando el software es quien realmente está identificada ante el sistema.
• Autorización: Asegura que la persona autenticada, solo pueda realizar las tareas sobre las que tenga autorización.

Posibles uso del generador en este contexto

El generador puede crear distintos tipos de seguridad y agregarla en los puntos requeridos ya sea por programación orientada a aspectos, o cualquier otro mecanismo.

Políticas empresariales

Implica cualquier aspecto empresarial, que se pueda aplicar de forma vertical en cualquier punto de nuestro sistema. Pueden ser, entre otro:

• Reglas empresariales que deben cumplir todos los sistemas.
• Mecanismos de Cache
• Mecanismos y política de bitácoras y trazabilidad
• Inyección de código
• Gestión de dependencias
• Validación de datos
• Control de excepciones

Posibles uso del generador en este contexto

Dependiendo de qué tipo sea la política empresarial, el generador de código, puede ayudarnos a introducirlas en los lugares adecuados de nuestro software, y encargase de “replicarlas” en el caso que estas cambien.

Acerca de las arquitecturas empresariales

Si bien lo mostrado anteriormente es un ejemplo de una arquitectura empresarial prototipo, hay que tener en cuenta que debemos usar la arquitectura adecuada para resolver cada problema en concreto. No existe una arquitectura que sea indicada para resolver todas los necesidades de software a los que se enfrenta un empresa.

Para considerar una arquitectura software adecuada, esta debe cumplir lo siguiente:

• Que resuelva la necesidad de negocio de forma adecuada.
• Que sea sencilla de entender y de explicar.
• Que sea mantenible.

---

[1] El modelo de dominio anémico, es un antipatrón de diseño, en que se usa un modelo del dominio, sin lógica de negocio, lo cual rompe el paradigma de la orientación a objetos donde dichos elementos (información y comportamiento) van juntos en una misma entidad.

[2] Jack Herrington, expresa en su libro “Code Generation in Action”, que el principal motivo por el cual comenzara a usar generación automática de código, son las experiencias y dificultades que tuvo trabajando con capas de acceso a datos, como menciona el capítulo 6: “Teaching engineers how to use code generation for database work is my primary reason for writing this book. This motivation comes from some personal experiences with database work.”

[3] Principio “Defense in Deep”

Diseño de una fábrica de software

Analicemos los elementos necesarios que necesitamos para crear nuestra línea de producción de software , basado en un esquema de “Fabrica de software”, que se puede implementar dentro de nuestra empresa, ya sea que esta tenga un departamento de desarrollo de sistemas o que el giro de la empresa sea el desarrollo de sistemas en sí.

Estándares de programación: Es una colección de reglas de programación que define como debe crearse el software de nuestra empresa , es importante que todos los programadores los conozcan y respecten. De esta forma cualquier codificador del equipo podría asumir cualquier tarea de programación o mantenimiento con una curva mínima de aprendizaje. Deben de existir herramientas que validen de forma automática que los estándares se cumplan.

Metodologías adecuadas: Debemos trabajar de la forma correcta y que dicha forma sea conocida y cumplida por todos los integrantes del equipo. Debido a las características de nuestra línea de producción, en que muchos elementos serán generados automáticamente, puede utilizarse un enfoque ágil (como XP, o Scrum), en el que se presenten cada poco tiempo un prototipo que a la vez sirva para definir y acércanos más a la necesidad final del cliente (En las metodologías agiles se asume que el software va a cambiar y eso se valora como algo positivo).

Patrones de software : Es necesario que el equipo de desarrollo conozca los patrones de software y los sepa aplicar de forma adecuada, igualmente nuestro generador puede implementar automáticamente los patrones de software, para garantizar que se usen correctamente.

Consumo de framework de terceros: Es necesario identificar los componentes existentes en el mercado que nos pueden ayudar en nuestro desarrollo . Muchos de estos componentes resuelven problemas que a nosotros nos pueden resultar complejos o los más probable que estén fuera del ámbito del problema de negocio que queremos resolver (por ejemplo cuando creamos un portal web , no queremos crear un Framework MVC, por que ese no es nuestro objetivo real, por eso usamos alguno previamente existe como ASP.NET MVC o Apache Struts). Es importante encapsular los framework elegidos apropiadamente para no generar dependencias externas excesivas, para ello, nos será muy útil nuestro generador de código que puede crear las interfaces adecuadas hacia dichos frameworks (y cambiarlas si es necesario).

Desarrollo de framework empresariales propios: Se encapsularan los componentes y funcionalidades comunes que se hayan sido desarrollados dentro la empresa . Cualquier funcionalidad que pueda ser global, se convierte en una herramienta que podrá ser usada en cualquier futuro desarrollo . Nuestro generador puede administrar dichos componentes.

Control de versiones: En toda fábrica es necesario tener controlado el software generado, permitir "viajar" sobre distintas revisiones y sobre distintas ramas de un mismo producto , para ello podemos usar herramientas como SVN o GIT.

Generador de código: Es el encargado de generar la gran parte de nuestro sistema . Todo característica repetible, que se propague en dirección vertical u horizontal en nuestra aplicación, se convertirá en una parte de este generador , una característica a incluir en un catálogo común.

Un característica común repetible, no es un fragmento de código, ni una librería que se usa en varios lugares, sino una parte del desarrollo , que puede ser reusada en otros desarrollos, esto incluye la parte del análisis y del diseño, no solo del código. El código se generara automáticamente adaptándose a la circunstancia indicada para el sistema que se quiera hacer.

Por ejemplo si empresarialmente definimos que nuestros sistemas deben tener cierta arquitectura, existirá una característica (o conjunto de ella), que se encarga de generar el código que respecte dicha característica. El código por sistema será diferente pero se habrá generado automáticamente, en base a un análisis y diseño que se realizaron previamente. El código de la misma forma, podrá cambiar de arquitectura, si cambiamos la característica generadora, o podrá crearse simultáneamente para varias arquitectura, por ejemplo podríamos desear que se genere nuestro software para escritorio y para teléfono móvil (Android o iOS ). De esta manera para una misma lógica de negocio , se crearan diferentes arquitecturas de forma automática.

Hay que considerar que para resolver el desarrollo de un sistema no se puede usar cada uno de los elementos previamente mencionados como única solución (de hacerlo caeremos en el problema del martillo de oro ). Es necesario combinar adecuadamente todos los elementos, para conseguir un software estable y con escalable a futuro:

Los estándares y las metodologías por sí solo, nos dan las reglas y las buenas prácticas sobre cómo crear nuestro software , por otro lado los patrones de software deben usarse de la forma y en los lugares correctos.

El abuso de los frameworks externos nos genera una dependencia, tanto al nivel de arquitectura, como técnicamente. Cuando estamos muy atados a un framework, y este no resuelve un problema en concreto, la solución puede volverse tremendamente complicada y enrevesada, entorpeciendo el mantenimiento del producto .

Intentar resolver todos los problemas con framework propios tampoco es una solución idónea, puesto que caeremos en dos escenarios posibles para abarcar todas las circunstancias propias de nuestro negocio , o crearemos un framework muy abstracto, que no resuelva nada, o creamos un framework muy concreto, amplio y difícil de manejar y mantener.

Si solo usáramos nuestro generador de código de forma exclusiva, este crearía muchos elementos repetidos, y código innecesariamente largo, haciéndolo difícil de comprender su funcionamiento, y por lo tanto condenado a ir perdiendo su utilidad con el tiempo (por posibles mantenimiento y diagnósticos).

Por todo eso debemos combinar en nuestra línea de producción de software todos los elementos según las necesidades particulares de los sistemas a desarrollar, eso hará que sean sistemas con alta calidad , funcionales y escalables.

El manifiesto ágil indica que se debe valorar más la colaboración con el cliente sobre negociación contractual y respuesta ante el cambio sobre seguir un plan.

La expresión "Martillo de oro", hace referencia el refrán "Al que tiene un martillo, todo le parece un clavo". Se quiere evidenciar que es fácil creer que nuestra herramienta o tecnología, por buena que sea, puede resolver cualquier problema, aunque no sea apropiada para la tarea.

Primera versión de CapicuaGen publicada

Acabo de publicar mi primera versión de CapicuaGen, el proyecto de mi máster en "Investigación en "Ingeniera de Software", la cual me ha tenido varios meses sin la posibilidad de publicar nada, y posiblemente me tenga algunos meses más debido a que estoy completando la memoria.

Pero no quería dejar pasar la oportunidad de anunciar la publicación del código fuente del proyecto, y de sus gemas.

CapicuaGen es un proyecto modular de generación de código, construido en Ruby, y de código libre, se puede obtener más información de la propuesta en:

http://desdelashorasextras.blogspot.mx/2015/12/capicuagen-proyecto-de-generador-de.html

Igualmente se puede obtener el código en:

• CapicuaGen: Núcleo del generador de código.

https://rubygems.org/gems/CapicuaGen
https://github.com/jbautistamartin/CapicuaGen

• CapicuaGenMelchior: Características comunes del generador.

https://rubygems.org/gems/CapicuaGenMelchior
https://github.com/jbautistamartin/CapicuaGenMelchior

• CapicuaGenGaspar: Características para C#.

https://rubygems.org/gems/CapicuaGenGaspar
https://github.com/jbautistamartin/CapicuaGenGaspar

• CapicuaGenBalthazar: Características para Android.

https://rubygems.org/gems/CapicuaGenBalthazar
https://github.com/jbautistamartin/CapicuaGenBalthazar

• CapicuaGenEssential: Gema base que referencia a las anteriores para facilitar la instalación de un entorno funcional

https://rubygems.org/gems/CapicuaGenEssential
https://github.com/jbautistamartin/CapicuaGenEssential

La descripción publicada en GitHub, Sobre el generador es la siguiente:

CapicuaGen

CapicuaGen es un software que ayuda a la creación automática de sistemas empresariales a través de la definición y ensamblado de diversos generadores de características.CapicuaGenEssential agrega referencia a los generadores de características Melchior, Gaspar, Balthazar, con lo que es posible generar un ejemplo funcional completo.

El proyecto fue iniciado por José Luis Bautista Martin, el 6 de enero del 2016.

Puede modificar y distribuir este software, según le plazca, y usarlo para cualquier fin ya sea comercial, personal, educativo, o de cualquier índole, siempre y cuando incluya este mensaje, y se permita acceso el código fuente.

Este software es código libre, y se licencia bajo LGPL.

Para más información consultarhttp://www.gnu.org/licenses/lgpl.html

Instalación

Agregue la siguiente línea al archivo GemFile de tu aplicación

gem 'CapicuaGenEssential'

y ejecute:

$ bundle

O instálela manualmente con el siguiente comando

$ gem install CapicuaGenEssential

Uso

CapicuaGen permite comenzar a trabajar con él desde el mismo momento en que es instalado. Para obtener un ejemplo funcional simplemente ejecutamos el comando CapicuaGen con el parámetro example:

$ capicuagen example

Se crearan los siguientes archivos:

• generator.rb: Ejemplo de un generador de codigo
• GemFile: Archivo de configuración de depencias para bundler .
• instnwnd.sql: Ejemplo de base de datos NorthWind, para Microsoft SQL Server

Revise el archivo generator.rb para tener una introducción a CapicuaGen.

Contribuir

Reporte de fallos y solicitudes de pull son bien recibidas en https://github.com/jbautistamartin/CapicuaGen

CapicuaGen: Proyecto de generador de codigo

Me encuentro estos días por comenzar mi proyecto de fin de master en "Investigación en ingeniera de software". Después de mucho debatir el tema decidí hacer un producto orientado a la generación automática de código, y a la construcción de software desde un enfoque generativo. ¿Que quiere decir esto? Bueno básicamente que construiremos un software, cuya misión es construir otro software, o mas exactamente el código de dicho software. El generador de código que voy a hacer se llamara CapicuaGen, nombre que elegí de forma aleatoria entre varias opciones, y espero, quizás, publicarlo como GPL (o otra licencia afín). En los siguientes meses iré publicando los avances que vaya haciendo en este tema y según sea posible el código fuente, quizás en GitHub.

Para comenzar, publico la propuesta del proyecto, sobre la que voy a comenzar a construir.

Situación actual

Durante la creación de sistemas empresariales, es común que se den las siguientes circunstancias:

• Software muy parecido a desarrollos anteriores, pero lo suficientemente diferente para impedir que se reúse software y librerías de una forma clara y consistente.
• Cortos tiempo de desarrollo.
• Numero de recursos limitados (tanto económicos como humanos).
• Equipos que atacan varios frentes que no tiene que ver con el sistema a desarrollar en cuestión (los recursos desarrollando o soportando varios sistemas a la vez).

El resultado de toda esta combinación de factores causa los siguientes problemas en el desarrollo de un sistema:

• Lentitud en el desarrollo.
• Retrasó en los tiempos de entrega.
• Elevación de costos.
• Multitud de horas extras realizadas por el equipo, lo que a su vez en la motivación de este.
• Sacrificios en la calidad del sistema, lo que a su vez lleva a fallos en el sistema.

Como conclusión impactamos aspectos relativos al producto en si, como la calidad y el tiempo de entrega, y por otro lado impactamos en el equipo de personas que trabaja en el sistema.

Objetivos

Los objetivos a conseguir son los siguientes:

• Agilizar la construcción de un sistema a partir del uso de generadores de código, que creen de manera adecuada las características comunes de cada sistema, ensamblándola apropiadamente.
• Reducir la programación manual de un sistema a los elementos particulares que así lo requieran, esto es, aquellos elementos que son exclusivos del sistema y por lo tanto no están incluidos en otros sistemas.

Con el cumplimiento de estos dos objetivos se espera satisfacer las siguientes necesarias:

• Aumento de la calidad del software al generarse en parte de forma automática. Los fallos detectados se podrían corregir en los elementos generadores y aplicar automáticamente al código de los sistemas.
• Los codificadores no perderían tiempo realizando tareas repetitivas y se concentraría en las tareas que realmente da valor al sistema, y no en aquellas que se duplican sistema tras sistema.
• Reducción de tiempo de desarrollo, en base a la generación de código automático, lo cual a su vez reduce el número de hora extras a desarrollar por un sistema.

Propuesta

Se realiza la siguiente propuesta de solución:

• Es necesario detectar las características (features) comunes a un sistema, y las posibles variaciones de dichas características.
• El análisis de dichas características detectadas y sus posibles variaciones, serán incorporados dentro de un generador de código, llamado Generador de características.
• Los generadores de características serán los encargados de crear el código fuente que implementan las mencionadas características en base a una configuración sobre su variabilidad.
• Los generadores de características deben ser independientes unos de otros, aunque pueden tener una serie de interfaces con las que exponer servicios a otras características, con el menor acoplamiento posible (debe ser lo más independientes posible).
• La configuración de la variabilidad debe ser lo más versátil posible, si en una primera versión se uso XML, se intentara usar Ruby como lenguaje de configuración, parecido a la configuración de los archivos RakeFile o a un archivo podFile de CocoaPods.
• Igualmente la generación de un sistema se llevara a cabo mediante la agrupación de varios generadores de características, que interactúan entre sí, para crear el código de dicho sistema.
• La configuración, tanto del sistema, como de la variabilidad del sistema deben hacerse a través de una interfaz grafica que facilite dicha tarea.
• Cuando se genera el código de un sistema, es necesario considerar que el sistema no puede generarse en un 100% de forma automática, por lo que habrá una parte del sistema que será creada automáticamente, y otra parte que lo creara el programador. Es importante que el generador reconozca la parte creada manualmente por el codificador y no sea reemplazado su código en ninguna circunstancia.
• La creación de generadores de características en sí, es construida de forma manual, y se crean en parte a base de plantillas de código y analizadores de código, realizados en Ruby
• Estos generadores de características una vez creados, podrán ser usados por varios programadores, con lo que se creara un repositorio centralizado en los que los programadores puedan subir sus generadores de características, o bajar los generadores de característica creados por otros programadores, algo parecido a las gemas de Ruby.
• Hay que considerar que el generador de características, genera código, esa es su funcionalidad, es decir en ningún caso son librerías o framework a usar en nuestro código, sin embargo el código generador si puede usar librerías o framework externos.
• Unos de los objetivos de generar el código, es aumentar la calidad del sistema, haciendo que el código generador implemente patrones de software, así como estándares y mejores prácticas de programación.
• Hay que considerar que si tenemos un sistema generado con una versión de un generador de características y descargamos una nueva versión de las características podemos volver a generar el código y aprovechar las nuevas mejoras y cambios de esta versión.