APaiva Tesis Final

Universidad de Concepcin
Direccin de Postgrado
Facultad de Ingeniera -Programa de Magster en Ciencias de la Computacin
Generacin de Cdigo a partir de modelos Parametrizados

(Code Generation from parameterized models)
ANDRS EDUARDO PAIVA MAULN

CONCEPCIN-CHILE
2011
Profesor Gua: Ricardo Contreras Arriagada

Dpto. de Ingeniera Informtica y Ciencias de la Computacin, Facultad de Ingeniera
Universidad de Concepcin
INDICE
1. INTRODUCCION.........................................................................................................................................2
2. MOTIVACION...............................................................................................................................................5
3. ESTADO DEL ARTE...................................................................................................................................8
4. PROPUESTA...............................................................................................................................................11
ANTECEDENTES................................................................................................................................................11
METALENGUAJE DE ESPECIFICACIN...............................................................................................................18
RESUMEN PROPUESTA.....................................................................................................................................19
HIPTESIS.........................................................................................................................................................21
OBJETIVOS.........................................................................................................................................................21
5. ESPECIFICACIN DE REQUISITOS DEL PROTOTIPO...........................................................23
INTRODUCCIN.................................................................................................................................................23
REQUISITOS FUNCIONALES..............................................................................................................................23
REQUISITOS NO FUNCIONALES........................................................................................................................24
6. DISEO DEL PROTOTIPO...................................................................................................................25
INTRODUCCIN.................................................................................................................................................25
MECNICA DE TRABAJO...................................................................................................................................25
DESCRIPCIN DEL DISEO..............................................................................................................................26
ESQUEMA FUNCIONAL......................................................................................................................................27
7. PRUEBA Y RESULTADOS.....................................................................................................................29
ANTECEDENTES................................................................................................................................................29
DETALLE DE LAS PRUEBAS..............................................................................................................................30
COMPARATIVO DE TIEMPOS.............................................................................................................................32
DISTRIBUCIN DE TIEMPOS EN ETAPAS..........................................................................................................33
8. CONCLUSIONES.......................................................................................................................................35
ANTECEDENTES................................................................................................................................................35
RESULTADOS Y CONCLUSIONES.......................................................................................................................35
9. REFERENCIAS...........................................................................................................................................38
ANEXO 1: ESPECIFICACIN METALENGUAJE...............................................................................40

INTRODUCCIN.................................................................................................................................................40
PALABRAS CLAVE.............................................................................................................................................41
VARIABLES ESPECIALES...................................................................................................................................41
USO DE VARIABLES DENTRO DE LOS MODELOS.............................................................................................41
USO DE SENTENCIAS DENTRO DE LOS MODELOS..........................................................................................42
ANEXO 2: ESPECIFICACIN DETALLADA DE REQUISITOS....................................................46
MODELO DE DATOS.........................................................................................................................................46
REQUERIMIENTOS FUNCIONALES.....................................................................................................................47
GENERACIN.....................................................................................................................................................52
1. INTRODUCCION
En la actualidad la produccin de software debe ser realizada considerando tanto

la calidad como la reduccin de costos. La calidad est marcada por los
estndares con que se cuenten y el nivel de cumplimiento de los mismos. La
reduccin de costos dice relacin con la mejor utilizacin de los recursos, tanto
humanos como tcnicos, relacionados con la produccin de la pieza de software
en cuestin.
En este sentido, todos los esfuerzos que se inviertan en automatizar partes del
proceso de produccin se tornarn significantes para la reduccin de los costos.
A la vez, si se invierte en estandarizacin, se puede pensar en una verdadera
Fbrica de Software que produzca, ensamble e integre partes y piezas de
software. Siendo esto posible, basta con encontrar la forma en que se
estandaricen algunos componentes, usables y re-usables en mltiples proyectos
de desarrollo.
A la vez, estos componentes deben cumplir con un requisito de generalizacin,
de forma que puedan ser utilizados en distintos proyectos, adaptando aquellos
aspectos configurables para la instancia precisa en la que se estarn utilizando.
Esquemticamente:
Figura 1: Fabrica de Software por Componentes
Componentes
Programa1
Componentes
Ensamble
Programa2
Componentes
La produccin automatizada de programas (generacin) es un trabajo hace ya

algn tiempo incorporado en la ingeniera de software, existiendo an la
aparicin de cambios y mejoras importantes con el inters de aumentar la
calidad, velocidad y disminuir costos en el proceso.
El enfoque de producir software a partir de experiencias anteriores, el reuso de
partes y piezas de software, son temas que se han incorporado incluso dentro de
los ambientes de programacin, por ejemplo en el caso de la incorporacin de
clases en los lenguajes de programacin. Muchas empresas desarrolladoras
confeccionan bibliotecas de software que, en futuros proyectos, las utilizan
ensamblando partes y produciendo rpidamente un nuevo software, muy similar
al original, pero con las particularidades de la nueva instancia.
El asunto es que las empresas desarrolladoras no necesariamente han
automatizado este proceso, sino ms bien aprovechan las ventajas que ofrece,
pero realizando rplicas manuales, lo que es eficaz pero no eficienta el
mecanismo, pues la cantidad de cdigo a revisar para asociarlo a la nueva
instancia no es un tema menor [Arauco2009].
El trabajo que se presenta a continuacin busca descubrir la existencia de partes
y piezas de software que efectivamente estn presentes en muchos sistemas de
informacin administrativos. Luego, presenta una propuesta que convierte estas
partes en assets materias primas para la fbrica de software, la que convertir
segn sea la instancia, estos assets en programas ejecutables, con idntica
estructura y funcionalidad pero con la particularidad que le aporte la
especificacin que se realice para la ocasin. Se revisaron propuestas para
trabajo con assets modelos, seleccionndose una de las existentes, con la que
se automatiz el proceso de produccin con un prototipo que efecta la
generacin.
El documento se organiza de la siguiente forma:
En el captulo 2 Motivacin se muestra la situacin que ocurre hoy da en las
empresas desarrolladoras, de manera de comprender la problemtica y
comenzar a visualizar alguna solucin.
En el captulo 3 Estado del Arte se observar un anlisis de los trabajos

similares efectuados hasta el momento y la presentacin de las iniciativas
existentes para abordar este tipo de problemas.
A continuacin en el captulo 4 Propuesta se explica la seleccin de la tcnica,
se muestra la forma en que se resolver la automatizacin del proceso, se
describe la solucin y se plantean tanto la hiptesis de trabajo como los
objetivos del mismo.
El capitulo 5 Especificacin de Requisitos contiene los requerimientos que
debe cumplir el prototipo que se construir para apoyar la verificacin de la
hiptesis, considerando requisitos funcionales y no funcionales.
Avanzando en el documento, el captulo 6 Diseo del Prototipo muestra la
forma en que se dise la solucin y la aplicacin generadora. Este captulo est
ntimamente relacionado con el anexo 1, por los contenidos y detalles del
mismo.
El captulo 7 Pruebas y Resultados nos muestra el escenario de pruebas con
que se trabaj con el prototipo, a la vez que muestra los resultados, realizando
un comparativo entre el desarrollo tradicional sin generador y el mismo
utilizando el generador. Las conclusiones son muy interesantes, pues aportan en
la configuracin de los porcentajes de dedicacin en distintas etapas del
desarrollo.
Finalmente el captulo 8 Conclusiones, basado en el captulo anterior (7),
concluye una favorable comprobacin de la hiptesis y el cumplimiento de los
objetivos.
Se
agrega
el
anexo
que
contiene
la
Especificacin
detallada
del
metalenguaje y que corresponde a la especificacin de un lenguaje que se

superpone al lenguaje en el que se est generando y que constituyen mensajes
para el generador.
Finalmente, el anexo 2 contiene la especificacin detallada de requisitos,
incluyendo
layouts
de
pantalla,
funcionalidad
funcionamiento.
detallada
ejemplos
de
2. MOTIVACION
Estudios realizados en 2004 relativos a proyectos de software indican que ms

del 70% de los proyectos fallan en entregar el producto originalmente ofrecido,
sea por aumentos de costo, incumplimiento de plazos en prdidas de calidad
[Borland2004]. Esta realidad ya se haba medido en 1994, resultando en esa
ocasin ms de un 80% la cifra de proyectos en esta categora [Standish1994].
La ingeniera de software es una disciplina que est viviendo un auge impensado
hace 50 aos, toda vez que la industria del hardware se ha masificado y
popularizado y hoy resulta inconcebible prescindir de ella, as como esta
industria tampoco puede prescindir de la del software, las que van de la mano
para crear soluciones para la humanidad. En este sentido, no se puede permitir
los niveles de fallas que se siguen presentando en la construccin de soluciones.
En el siglo XXI es complejo pensar una empresa sin aplicaciones de software que
registren los datos y produzcan informacin para los negocios. La velocidad de
stos y la precisin que la logstica exige hoy, hacen pensar que se est viviendo
en pleno la sociedad de la informacin, nueva era luego de la revolucin
industrial. Es en esta sociedad en la que las empresas requieren desarrollos de
variada ndole y ya sea que los emprendan o que los adquieren de paquetes preconfigurados,
se
hace
necesario
contar
con
ellos,
poder
adaptarlos,
complementarlos y extender su vida til, de manera de acompaar el negocio.

Con el tiempo, las empresas pueden observar que estos desarrollos tienen
muchas partes y piezas en comn, o al menos ciertos tipos de programas se
repiten entre uno y otro sistema, lo que produce ciertas tcnicas en los equipos
de programacin [Arauco2009], esto es, buscar re-aprovechar este cdigo en un
nuevo emprendimiento. Esto se realiza en la mayora de las empresas, sea reusando cdigo o creando bibliotecas de objetos re-utilizables. En particular, en
los sistemas de informacin administrativos, se observa una media de un 38%
del cdigo que se repite entre sistemas diferentes [Arauco2009][CMPC2009].
Cambian las bases de datos, cambian las tablas y los valores, pero las
estructuras de los programas (en el porcentaje indicado) prcticamente no
cambia, lo que motiva a buscar una forma de automatizar este proceso, de
manera que el equipo de programacin se concentre en el cdigo propio del

negocio y de la aplicacin misma, ms que en estos programas que son
estructuralmente idnticos a otros ya construidos con xito.
Sea S un conjunto de sistemas de una compaa, tal que:
S = { S1, S2, , Sn}
Sea P el conjunto de programas de estos sistemas:
Pij (Si) = {Pi1, Pi2, , Pin}
Lo que estamos diciendo es que la interseccin de los diferentes conjuntos P ij es
un conjunto no vaco, tal que:
P1i P2j P3k Pnz
Este conjunto no vaco de programas, presente en casi todos los sistemas y que
representan en promedio el 38% del cdigo a programar [CMPC2009], muestra
una oportunidad e invita a elaborar un proceso automatizado de generacin del
mismo, a partir de las estructuras tipo que se repiten y que con el debido
tratamiento, se pueden generalizar, obteniendo la materia prima para generar
programas clones con gran rapidez y seguridad, toda vez que al ser copias de un
programa ya probado, tienen menos probabilidad de presentar fallas.
El aporte de este trabajo dice relacin con la descripcin, diseo de solucin e
implementacin de un prototipo que permita la reutilizacin de cdigo, reuso de
funciones, incorporacin de bibliotecas de objetos comunes y lneas de
fabricacin, a partir de modelos (assets) que se construyen una sola vez y luego
se clonan, diferenciando un clon de otro slo en aspectos de forma (lenguaje,
bases de datos, tablas, ambiente de desarrollo), pero no de fondo, pues son
construidos a partir de un modelo comn. Los trabajos similares (ver cap. 3) se
han concentrado en su mayora en la descripcin de tcnicas y metodologas,
pero no han concretado con una aplicacin que genere programas ejecutables e
incorporables a un sistema mayor usando la tcnica.
Al no contar con esta solucin, las empresas desarrolladoras continan
realizando la clonacin de manera manual, con prdidas de tiempo, de
seguridad, errores y fallas, por un continuo y no controlado copy-paste que
puede provocar comportamientos inesperados en las aplicaciones. O lo que
puede ser peor, continuarn desarrollando nuevamente todas las aplicaciones,

an cuando muchas de ellas son casi idnticas a otras ya confeccionadas para
un sistema anterior [Arauco2009][CMPC2009].
Dentro de las aplicaciones que se repiten con alguna frecuencia y que
representan en promedio el 38% del cdigo programado [CMPC2009], se
encuentran:
Mantenedores Simples:
Aplicaciones de insercin, modificacin y borrado de

registros en tablas sin referencias externas y uniregistro en pantalla. Por ejemplo, tablas de Parmetros
y tablas Maestras.
Mantenedores Compuestos:
Aplicaciones de insercin, modificacin y borrado
de registros en tablas relacionadas, tipo padre-hijo,
con pantallas ms complejas, del tipo encabezado
detalle; grillas multi-registro y pantallas con mltiples
pestaas.
Consultas con filtro:
Aplicaciones de consulta a una tabla, con o sin tablas

de referencia, consulta en pantalla multi y uni-registro,
con filtros de seleccin.
Reportes:
Aplicaciones para generar reportes sobre una tabla

con sin tablas de referencia, con filtros de seleccin
y presentacin multi y/ uni-registro (tipo carta)
Mdulo de Control de Acceso: Mdulo consistente en aplicaciones estndares

para el control de acceso a los programas y datos del
sistema en construccin. Constituye un grupo de
rutinas y tablas que permiten habilitar acceso no a
los objetos que formen parte del sistema.
Mdulos de Parmetros:
Mdulo consistente de varios programas que

mantienen tablas de parmetros. Consiste de un
mdulo
estndar
para
cualquier sistema
de
informacin. Este mdulo es un objeto que se hereda
entre un sistema y otro, solo se detallan los tipos de
parmetros.
Aplicaciones Transaccionales: Aplicaciones de procesamiento masivo sobre

tablas de transacciones, que actualizan tablas
maestras y/o de status (stock por ejemplo). La
estructura de estos programas son muy similares,
independiente de las tablas involucradas. Corresponde

a recorridos masivos, clculos, copia, etc.
Carga de Registros:
Aplicaciones de lectura y carga tipo batch-input de

registros en un medio externo hacia alguna tabla
dentro del sistema.
Al no contar con una herramienta que automatice el proceso de generacin a

partir de modelos, la empresa contina absorbiendo el costo asociado a estos
desarrollos repetitivos, por lo que es importante disponer de una herramienta de
generacin automatizada, que permita concentrar a la fuerza de programacin
en las tareas innovadoras o no estndares, en general las mas complejas,
evitando distracciones en aspectos replicables de experiencias anteriores.
3. ESTADO DEL ARTE
El tema de la construccin de cdigo lleva ms de cinco dcadas, dentro de las

que se ha buscado alejarse abstraerse lo ms posible del hardware donde ste
se ejecutar. Se inici con los lenguajes como ensamblador y Fortran, cuyo
principal objetivo era alejar al programador del lenguaje de mquina. An
cuando stos aumentaron el nivel de abstraccin, todava tenan un enfoque
orientado al hardware, pues continuaban otorgando acceso a los componentes
de hardware, muy propios de una mquina particular. Esto se solucion mas
tarde con la programacin orientada a objetos y la programacin estructurada
[Musat2009].
Posteriormente, aparecieron las herramientas CASE (Computer-Aided Software
Engineering) que estaban enfocadas a permitir expresar los diseos en
representaciones grficas (mquinas de estado, diagramas de estructura,
diagramas de proceso y de flujo de datos. La idea era que los entornos grficos
disminuyeran la complejidad respecto a los lenguajes de programacin,
aumentando el nivel de abstraccin respecto al lenguaje y herramientas de
programacin a utilizar [Alonso2007]. Paralelo y complementario a los CASE,
estaba la idea de obtener la generacin automtica de cdigo fuente. Estas
herramientas no han prosperado en el tiempo, posiblemente por la falta de
precisin en la notacin utilizada, fuerte dependencia de la infraestructura de
ejecucin y la dificultad para reutilizar partes en otros proyectos, a la vez que no

facilitan la incorporacin de requerimientos no funcionales.
En la actualidad, la fuerte competencia exige marcar una diferencia, que se
traduce en proporcionar calidad a bajos costos. Como solucin a esta exigencia,
las compaas estn confeccionando guas de trabajo, llamadas modelos, que
sean el punto de partida y la carta de navegacin para los especialistas y
programadores. En esta lnea, se han descrito tanto MDA de OMG [OMG2003]
como Software Factories de Microsoft [Greenfield2003] como grandes iniciativas
de programacin a partir de modelos. Ambas postulan la generacin de cdigo
como un apoyo importante para la reduccin de costos, a partir de modelos de
alto nivel que representan la especificacin de la aplicacin a construir,
partiendo desde un modelo genrico hasta un programa fuente en un lenguaje y
plataforma especficos. El tema de la re-utilizacin (re-uso) de software est
presente en ambas, an cuando la iniciativa de Microsoft trata el tema con ms
precisin y fuerza, pues postula el uso de lneas de fabricacin para familias de
productos, tal y como lo hiciera la industria automotriz y otras similares en el
inicio de la era industrial [Greenfield2003].
10
A principios de los ochenta, la compaa HP implement el re-uso de software

para reducir los tiempos de salida de sus versiones al mercado, aumento de la
productividad y mejora en la consistencia de sus productos [Griss1994]. En los
noventa
inici
un
programa
corporativo
de
re-uso.
No
existe
mayor
documentacin de las herramientas y procedimientos que se implementaron, lo

que s ocurri es que se derribaron algunos mitos existentes a la fecha respecto
al re-uso, a saber:
- El re-uso requiere utilizar la tecnologa orientada a objetos
- Supone el uso de bibliotecas complejas y uso de sistemas de
administracin de stas.
- Las aplicaciones generadas son lentas debido a su generalizacin
- No se debe implementar a menos que se tenga un nivel 3 en CMM.
Estos mitos fueron derribados por HP, por cuanto mantienen hasta el da de hoy
el programa de re-uso de componentes de software con gran xito.
En los noventa, Motorola implement una iniciativa similar, con el fin de
incrementar la productividad y calidad. Tampoco existe documentacin de
herramienta utilizada; s se confirm que el tema, ms que dificultad tcnica,
presentaba barreras culturales debiendo pasar por una etapa fuerte de
educacin para salir de una mentalidad orientada al hardware y pasar a una
orientada al software [Joss1994].
Existen a lo menos tres interesantes propuestas recientes, ninguna de las cuales
termina con una herramienta que obtenga programas a partir de re-uso de otras
aplicaciones y/o modelos. Si bien los tres trabajos muestran el camino, no son
comparables con la aplicacin obtenida en este presente trabajo, puesto que ac
se plantea la tcnica, se desarrolla la misma y se termina con un prototipo
generador que construye aplicaciones en distintos ambientes y lenguajes, por lo
que esta propuesta es mas completa ya que concluye con la prueba emprica de
la hiptesis planteada.
El primero de estos es un trabajo que se desarroll en la PUC de Per por Carla
Basulto y Abraham Dvila [Basulto2001], quienes trabajaron en su tesis de pregrado denominada Generador de Cdigo con Plantillas XML, trabajo del que no
11
se tiene constancia de que se haya llegado a un producto de software concreto.

Ellos plantearon la idea, usando para ello plantillas de programa escritas en XML,
a lo que agregaron hojas de estilo para diferenciar los lenguajes de
programacin en los que el cdigo se generaba. De esta forma logran la
combinacin de n x m, donde n es una plantilla de programa y m el
lenguaje en el que se generar. Llegaron hasta un prototipo simple que
generaba porciones de cdigo de acuerdo al modelo seleccionado y al lenguaje
en cuestin. No avanzaron hasta programas completos.
El segundo de stos corresponde a otra tesis de grado en Uruguay, Universidad
de la Repblica, por Nicols Castagnet, que busca construir una Software Factory
asociada al generador Genexus [Castagnet2007]. Este trabajo concluy con la
definicin de un ambiente de modelamiento y la especificacin de un lenguaje
para ste, sin llegar hasta la generacin misma, que la deja a Genexus, an
cuando aplica de manera bastante completa el concepto de Microsoft
[Gally2007].
El tercero, orientado a la reutilizacin de cdigo, es un trabajo de pre-grado
denominado Gestin de reuso de software, por Falcn et al 2007 de la Facultad
de Ingeniera, Universidad Peruana de Ciencias Aplicadas. Ellos trabajan
fuertemente el tema de la reutilizacin de software planteado por la OMG en
2003, pero tomando experiencias anteriores de IBM y otras empresas. Definen el
concepto de asset, como la materia prima del re-uso. Un asset es una porcin
de software, confeccionada para algn fin, que es posible generalizar de manera
que luego pueda ser utilizada nuevamente para un fin, plataforma set de datos
distinto para el que originalmente fue originalmente concebida.
Otras iniciativas existentes son directamente generadores de cdigo, entre los
que destacan ProCG, OxyGen y GeneXus [Gonda2007], los que no siguen la
misma lnea de este trabajo, pues son aplicaciones que generan cdigo a partir
de especificaciones, lo que es positivo, pero no apunta al trabajo con modelos y
al re-uso de cdigo. Lo ms similar a la tcnica de uso de modelos es un
subproyecto de ECLIPSE denominado MOFScript, que provee una herramienta
para la transformacin de modelos en texto (M2T) a partir de templates. Se
encuentra en etapa de incubacin, an cuando est disponible desde 2009
[Eclipse2009] como un add-on para ECLIPSE.
12
En cambio, en esta tesis se plantea que es la propia empresa desarrolladora la

que identifica aquellas aplicaciones que son repetibles, que estn construidos
segn sus estndares, y procede a convertirlos en aplicaciones generalizadas
(ver el caso asset recin explicado), comenzando a generar nuevos programas
similares, a partir de estos programas. Esto adems de permitir la construccin
ms rpida de aplicaciones, habilita al
desarrollador para que incremente el
conjunto de modelos (assets) con nuevos elementos, los que pasarn a formar
parte del activo de la empresa y del generador. Esta lnea de trabajo es mas
completa y contiene elementos bsicos en la generacin de cdigo y
herramientas afines [Czarnecki1999].
13
4. PROPUESTA
Antecedentes
El propsito de este trabajo es mostrar e implementar la tcnica de generacin a
partir del supuesto que indica que dentro del desarrollo de Sistemas de
Informacin Administrativos, existe un porcentaje de aplicaciones (38%) que se
repiten entre un sistema y otro, aplicaciones que se pueden modelar para
generalizarlas, de manera que sirvan de materia prima para la construccin de
aplicaciones completas similares para otros sistemas, siguiendo el patrn
definido en el modelo.
A la vez, este hecho implica que las aplicaciones similares que se identifiquen se
podrn replicar o clonar con una herramienta de software preparada para ello,
de manera que estas aplicaciones no constituyan carga significativa para los
programadores, por cuanto su construccin se realizar a partir de generacin
automtica, permitiendo concentrar el esfuerzo de programacin en las
aplicaciones del negocio y aplicaciones particulares que no poseen modelos
posibles de generar.
La propuesta se traduce en dos grandes lneas de trabajo. Primero un anlisis de
programas dentro de sistemas de informacin administrativa y descubrimiento
de
tipos
de
programa
estndares
modelables.
En
segundo
lugar,
la
implementacin de una prototipo de aplicacin generadora que tome estos

modelos y los convierta en una instancia nueva de programa, con caractersticas
propias,
mejoras,
aportes
especficos,
etc.,
construido
sin
un
esfuerzo
significativo y slo aportando las diferencias particulares de la instancia.

La herramienta construida permitir la generacin automtica de cdigo,
reutilizando programas fuentes, objetos y funciones, basadas en estndares,
esto es, que contienen toda la experiencia de las mejores prcticas probadas en
la empresa donde se utilice, a saber, la lgica asociada a la aplicacin que se
est construyendo, la imagen corporativa, formatos, accesos a los datos, lgica
de presentacin, etc., es decir, todo aquello que es predecible, que ya fue
pensado y hecho alguna vez y que no requiere ms que reemplazar las
14
secciones variables por la tupla de valores que se est trabajando en cada caso
particular.
El hecho de utilizar modelos a partir de programas estndares acelera
enormemente la velocidad del proceso de desarrollo [Quintero2007], dejando la
creatividad de los programadores a aquellas porciones de software en los que se
deben implementar funciones especficas no estandarizables, lo que llamaremos
aportes.
Para abordar la propuesta, se analizaron distintas tcnicas y metodologas,
relacionadas con la bsqueda de una mejora en la programacin, llegando al
desarrollo conducido por modelos (MDD) [Castagnet2007], esto es, un mayor
nivel de abstraccin y generacin automatizada de cdigo fuente, a partir de
modelos genricos que a travs de un proceso se transforman en cdigo en un
lenguaje especfico. Dentro de ste tipo de iniciativa, se observan dos grandes
lneas de trabajo, una propuesta por la OMG en 2003 denominada Model Driven
Architecture (MDA) [OMG2003] que propone una arquitectura de desarrollo
basada en modelos y Software Factories de Microsoft [Greenfield2003], que
propone lneas de fabricacin y reutilizacin de cdigo para construir nuevas
instancias de solucin.
De ambas iniciativas, se seleccion Software Factories como la alternativa base
para este trabajo, tanto por tener similitud con el diseo de solucin que se
propone como por dar mas nfasis a aspectos que se utilizan en este trabajo,
como lo son la generacin en mltiples lenguajes, el reuso de lo que el propio
desarrollador va produciendo y el ensamblado automatizado, todo lo que se
utiliza con un nivel de simplicidad muy superior, observado en los resultados.
Software Factories postula la creacin de una metodologa ordenada y
coherente, que combina las siguientes ideas a modo de innovaciones crticas
[Greenfield2003]:
1. Reuso Sistemtico: la metodologa se basa en la reutilizacin de partes y
piezas de software, para la construccin de nuevas aplicaciones.
15
2. Desarrollo Conducido por Modelos (MDD): que promueve la creacin de

lenguajes especficos de dominios (DSL) para facilitar el desarrollo y
mejorar la productividad.
3. Desarrollo por Ensamblado: que busca la creacin de componentes
reusables, propiciando la aparicin de proveedores de componentes
ensamblables.
4. Marco de Procesos: se desarrollan procesos especficos para cada tipo de
aplicacin
Software Factories realiza la similitud entre una fbrica de ensamblado de
equipos a partir de partes y piezas provenientes de distintos lugares, con la
construccin de software, que sigue un tronco comn y se le incorporan partes y
piezas de software pre-hechas, posiblemente de otros proveedores, que en su
armado constituyen un producto final til para el mandante. Corresponde a una
iniciativa, un conjunto de ideas y directivas, no precisamente una herramienta
que implemente stas, por lo que no constituye una solucin en s, sino el
modelo de la misma.
Los autores de esta iniciativa indican que pretenden solucionar aportar
significativamente para resolver los casi siempre presentes problemas que
muestra el Desarrollo de Software [Castagnet2007], a saber:
1. Construccin Monoltica: no se ha logrado implementar el desarrollo por
ensamblado a gran escala, esto es, construccin de aplicaciones en base
a componentes prefabricados. Falta encapsulacin y madurar en las
relaciones entre proveedores y consumidores. El nico contraejemplo es la
aparicin y consumo de Web Services basados en XML.
2. Generalidad Innecesaria: los mtodos y prcticas de desarrollo ofrecen
muchos ms grados de libertad que los necesarios. Se puede observar
que muchos de los sistemas se construyen a partir de pocos patrones
bsicos (lectura de datos, display, transacciones con reglas del negocio,
almacenamiento de datos, procesos masivos, etc.). Siendo estos procesos
similares entre uno y otro sistema, se postula que podran utilizarse
16
lenguajes ms especficos y no generalistas como C Java. Software

Factories propone uso de lenguajes con abstracciones especficas (DSLs)
para dominios de aplicacin bien acotados.
3. Desarrollo Aislado: cada producto de software se trata como pieza nica,
an cuando existen ms similitudes que diferencias entre un programa y
otro. Las mejoras de rentabilidad se notan cuando se crean lneas de
productos (SPLs), de manera de producir ms rpido y adems de
permitir detectar nuevas oportunidades de reuso.
4. Inmadurez de los Procesos: no se ha encontrado an la forma de
desarrollar software de manera consistente y predecible, cumpliendo
plazos, sin exceder el presupuesto y cumpliendo las especificaciones. Un
paso vital antes de la automatizacin es la madurez del proceso.
La propuesta que aqu se entrega, basada en software factories pero con
caractersticas propias, considera un patrn que se repite de un sistema de
informacin (SIA) a otro y es que una cantidad importante (38%) [CMPC2009]
[Arauco2009] de los programas se aprecian casi idnticos, en funcionalidad y
estructura. En funcionalidad, pues realizan las mismas operaciones, cambiando
solo el conjunto de datos (Ej.: mantenedores, reportes, consultas, etc.) y en
estructura, pues realizando un anlisis del cdigo fuente se observa idntico
tronco comn de estas aplicaciones.
Estos programas son los candidatos a ser generalizados, pasando a constituir la
material prima asset para la fabricacin en lnea de nuevas instancias para
nuevos SIAs.
Para mejor ilustracin, un ejemplo:
Mantenedor de Ciudades
Tabla
Ciudades
Campos
cdigo, descripcin, provincia, alcalde, habitantes
Estructura del programa
17
Muestra ciudades
existentes
Evento
Nuevo
Modifica
Pide campos para Ciudad

nueva, incluyendo
Cdigo y resto campos
Permite modificar descripcion

Provincia, alcalde y habitantes
Evento
Evento
Graba Ciudad
Actualiza Ciudad
Elimina
Borra ciudad de tabla
Figura 2: Estructura de programa ejemplo
Fuente (pseudo lenguaje)

Inicio: Mostrar Pantalla inicial con ciudades existentes
Opcion: Esperar evento
Nuevo Va a Nuevo
Modifica Va a Modif
Borrar Elimina ciudad seleccionada y vuelve a Opcion
Salir Terminar aplicacin
Nuevo:
Muestra pantalla vaca y pide los campos de la nueva ciudad

Esperar evento
Graba Inserta ciudad en tabla, cierra pantalla y vuelve a Inicio
Cancela Cierra pantalla y vuelve a Inicio
Modif:
Muestra pantalla con todos los campos de la ciudad seleccionada

Permite modificar descripcin, provincia, alcalde y habitantes
Esperar evento
Graba Actualiza ciudad en tabla, cierra pantalla y vuelve a Inicio
Para construir un mantenedor de otra tabla, por ejemplo regiones, se tomar

exactamente la misma estructura y hasta el mismo cdigo fuente, modificando
aquello que diferencia la tabla regiones de la tabla original ciudades.
18
La propuesta aqu es obtener primero una generalizacin del cdigo fuente

original, de manera que nos sirva para cualquier otra tabla de caractersticas
similares.
Generalizacin del cdigo

Inicio: Mostrar Pantalla inicial con registros existentes
Opcion: Esperar evento
Nuevo Va a Nuevo
Modifica Va a Modif
Borrar Elimina registro seleccionado y vuelve a Opcion
Salir Terminar aplicacin
Nuevo:
Muestra pantalla vaca y pide los campos del nuevo registro

Esperar evento
Graba Inserta registro en tabla, cierra pantalla y vuelve a Inicio
Modif:
Muestra pantalla con todos los campos del registro seleccionado

Permite modificar campos no clave
Esperar evento
Graba Actualiza registro en tabla, cierra pantalla y vuelve a Inicio
Observando este paso, vemos que el cdigo fuente puede ser reutilizado,
manteniendo la estructura que es idntica y conservando la mayora del cdigo,
generalizando solamente aquello que difiere entre una tabla y otra, a saber, los
nombres de los campos y los campos clave y no clave.
Modificando adems la estructura, de manera de obtener una generalizacin de
sta, tenemos el siguiente diagrama que muestra ahora el mismo programa
mantenedor pero que permite ser el punto de partida para un programa
mantenedor que acte sobre otra tabla, tenga sta ms menos campos.
19
Muestra registros
existentes
Evento
Nuevo
Modifica
Pide campos para

registro nuevo
Permite modificar campos no

clave de la tabla
Evento
Evento
Graba registro
Actualiza registro
Elimina
Borra registro de tabla
Figura 3: Estructura de programa generalizado
Este principio es el que convierte un programa ya funcionando y probado en un

modelo genrico, que contiene lgica, funcionalidad, imagen corporativa (logos,
colores, estndares, etc) y que constituye un asset, activo materia prima
para ser clonado y generar nuevas instancias del mismo programa, pero
actuando sobre otro conjunto de datos.
Durante el desarrollo de este trabajo, se observa cmo es posible llevar el
cdigo fuente de un programa terminado, que est dentro de los programas
posibles de clonar (ver cap. 2), hasta convertirlo en un modelo parametrizado,
que constituye un input para el generador, que sumado a
otros insumos,
obtiene un programa fuente como salida del proceso, programa que es copia del
original, excepto en los aspectos que interesa diferenciar.
Dentro de los insumos particulares para una nueva instancia de programa, se
encuentran los que denominaremos aportes, los que se podrn incorporar en
puntos estratgicos de la aplicacin y que por tanto deben venir sealados en el
modelo parametrizado, de forma que el generador aplique estos aportes en el
20
momento y lugar adecuado, que permita enriquecer una instancia de modelo sin
alternar la estructura, incluyendo la funcionalidad requerida.
El programa generador debe ser capaz de tomar este modelo genrico e
interpretar cierta sintaxis que le permita incorporar nombre(s) de campo(s), de
tabla(s) y otros elementos, que permitan generar a partir del modelo pero para
la instancia respectiva, un programa diferente en forma pero no en estructura,
pues conserva la que tiene el modelo.
Esquemticamente:
Figura 4: Diagrama General de la Propuesta
Necesida
d
Aportes
Elegir Tipo
de
Programa
(modelo)
Generado
r
Programa
Generalizado
Objetos
Funciones
Program
a
Final
(clon)
El input del generador (en rojo) es bsicamente el programa generalizado

modelo (amarillo), esto es, un programa probado, que funciona y que ha sido
generalizado en su cdigo fuente incorporndole el metalenguaje. Adems,
observamos
un
input
de
aportes,
que
como
se
seala
anteriormente,
corresponde a cdigo fuente que aporta funcionalidad en otro archivo de entrada

y cuyo cdigo se copiar en el programa de salida (clon) en los lugares que se
especifique en el mismo cdigo fuente del aporte (ver cap. 6 seccin
sentencias).
21
En segundo lugar, el generador tiene como entrada una biblioteca de objetos y

funciones, que corresponde a cdigo re-utilizable producto de la experiencia de
la empresa desarrolladora. Los modelos programas generalizados podrn
referenciar estos objetos, con lo que su incorporacin en el clon de salida no solo
es deseable sino estrictamente necesaria.
Esta tcnica permite tener modelos parametrizados provenientes de programas
escritos en cualquier lenguaje de programacin; es ms, puede ni siquiera ser un
lenguaje de programacin el que se quiera replicar. Caso emblemtico de esto
es la documentacin de una tabla o de una aplicacin, en la que el modelo
podra ser una generalizacin de un reporte de campos, tablas y aplicaciones
que se quieren documentar.
Metalenguaje de Especificacin
A fin de interpretar adecuadamente los modelos parametrizados asset que
son la materia prima del generador, fue necesario crear un metalenguaje de
especificacin, que permitiera incorporar mensajes para el generador dentro del
modelo, de forma que lograra convertir ste en un programa fuente de salida,
clon del original, con el mbito de datos que le corresponde de acuerdo a lo que
se requiere de l y que se especifica en la necesidad (ver figura 4). Se
construy este metalenguaje ya que no se encontr uno que permitiera realizar
la funcionalidad que se describe a continuacin.
En trminos generales, la tcnica propuesta reemplaza variables del modelo por
su valor de acuerdo al contexto. En ocasiones es necesario recorrer los campos
de la tabla sobre la que se est generando especficamente una aplicacin;
tambin es necesario poder incorporar una porcin de cdigo fuente u otra, a
partir de la evaluacin de una condicin que se hace verdadera o falsa; en otras
ocasiones; tambin se requiere identificar los puntos permitidos para aportes de
cdigo; por ltimo, en algunas ocasiones, se observa la necesidad de disponer
de herramientas muy particulares, que permiten generar parte de la sintaxis del
lenguaje generado.
Las sentencias de este metalenguaje se incorpora al programa ya probado, el
que
se
generalizar
convirtindose
en
un
modelo.
Las
sentencias
de
metalenguaje constituyen mensajes para el generador y no se incluyen en el
22
cdigo de salida, sino que modifican el comportamiento del generador y le dan

seales para efectuar uno u otro comando. En el anexo 1 Especificacin
Metalenguaje se entregan detalles del mismo, su sintaxis, ejemplos, etc.
Resumen Propuesta
La informacin recogida de las empresas que ha apoyado este trabajo, indica
que a lo menos un 38% de las aplicaciones de un sistema de informacin
administrativo (SIA) son candidatas a ser generadas a partir de un modelo
clonable [CMPC2009].
En la Tabla 1 se muestran los tipos de aplicaciones de un SIA, separadas en los
mdulos tpicamente presentes. La columna C1 indica el % de ocurrencia de
cada tipo. La columna C2 indica la presencia, siendo los nmero 1 los mas
presentes y por tanto los mas repetibles y los nmero 4 los muy poco presentes
poco repetibles. El 38% se obtuvo considerando solo los tipos de programa 1 y
2, los que al ser parametrizables constituyen un asset que ser convertidos en
un programa nuevo, clon de este asset, til para todos los fines, probado, con
el sello e imagen corporativa y que podr actuar sobre otro mbito de datos o de
aspectos variables respecto al asset original.
1. Mantenedores:
a. Mantenedores Simples
b. Mantenedores Padre-Hijo y
c. Mantenedores Tabulares.
C1
C2
2%
2
5%
3%
C1
C2
10%
2. Maestros:
a. Maestros
b. Maestros
c. Maestros
d. Maestros
simples,
6%
Padre-Hijo,
4%
3
Tabulares
4%
2
de Tabla Principal, con lengetas
1%
15%
3. Registro y Carga de Datos:

C1
C2
a. Ingreso de registros
15%
3
b. Cargadores y extraccin masiva de datos 5%
3
c. Procesamiento propio de cada sistema. 20%
4
40%
4. Reportes (Todos con filtros varios):

C1
C2
a. Reportes Tabulares
15%
2
b. Reportes Matriciales simples y/o grupos 10%
4
c. Reportes de Etiquetas y
3%
4
d. Reportes Tipo Carta.
2%
4
30%
23
C1
5. Consultas:
a. Consultores Simples
b. Consultores Padre-Hijo
c. Consultores Tabulares.
1%
1
2%
2%
C2
4
2
5%
Tabla 1: Presencia de tipos de programas en los S.I.A.
Con esta informacin, se valida la necesidad de crear una aplicacin que permita
obtener este 38% de programacin con un esfuerzo menor incluso nulo, pues
en este porcentaje de sistema, el programador no aporta mayor valor, sino ms
bien constituye una carga de trabajo rutinaria pero presente en la mayora de los
sistemas de informacin.
El equipo de desarrollo, seguir el siguiente procedimiento para obtener un set
de modelos parametrizados, de forma de contar con ellos para la construccin
de los siguientes sistemas. En la medida que un nuevo sistema tenga un
programa que se constituya en candidato para ser modelo, por su generalidad,
entonces se enriquecer el set de programas asset, poblando an ms de
materia prima el generador:
1. Construir un programa de acuerdo a requerimientos
2. De los programas ya construidos y probados, funcionando, identificar
aquellos que estn en las categoras de presencia 1 y 2 de acuerdo a la
tabla 1 (los que tienen nmero 3 4 no son habitualmente programas de
gran frecuencia entre distintos sistemas [Arauco2009]).
3.
Con los programas identificados como posibles modelos, proceder a

parametrizar el cdigo fuente, logrando un texto genrico que no hace
referencia a un sistema, aplicacin, tabla, base de datos, etc. particular,
sino al que se le ha incorporado el metalenguaje ya descrito y que se
encuentra en condiciones de ser input para el generador.
4. Este programa ya generalizado, en conjunto con los que anteriormente

pasaron por este proceso, se denomina Modelo Parametrizado. Se llama
de esta forma dentro de este documento, an cuando indistintamente lo
denominamos tambin programa insumo, materia prima y asset.
24
De esta forma, se enriquece el generador, con modelos que vienen de

programas propios, que contienen la imagen corporativa y los estndares de
programacin. El cdigo fuente obtenido, esto es, ya clonado el modelo en una
instancia particular, corresponde a un programa fuente tan eficiente como el
modelo, sin agregar cdigo que no haya sido incorporado por el propio equipo de
programadores que produjeron los modelos. Con esta tcnica, las diferencias
entre un programa construido por personas y un clon construido por el
generador no son apreciables.
As como algunos equipos de desarrollo realizan esta operacin manualmente,

esto es, la clonacin de programas en otros programas de similar estructura,
tambin es prctica habitual [Arauco2009] mantener un modelo plantilla de un
programa vaco, esto es, que no efecta funcin alguna, pero que posee todas
las referencias a una biblioteca de funciones, posee la imagen corporativa y la
pantalla inicial de acuerdo a los estndares. Este tipo de plantilla permite
concentrar al programador exclusivamente el cdigo a construir. Esta idea es
posible incorporarla al generador, teniendo un modelo parametrizado vaco, con
imagen, funciones y todo disponible, donde el programador construir el 100%
del cdigo, pero en el archivo de aportes, concentrndose en la lgica y dejando
aspectos cosmticos y de forma al modelo vaco y al generador.
Hiptesis
A partir de la base (por demostrar) que indica que en muchos sistemas de
informacin existe cdigo fuente similar ( incluso idntico) entre distintos
programas, repetitivos en cada sistema, entonces se postula la hiptesis es
posible describir e implementar una tcnica que permita generar el
cdigo fuente de programas en forma automtica a partir de modelos
provenientes
de
programas
anteriormente
confeccionados
generalizados.
Como consecuencia de esta hiptesis, ser posible confeccionar cdigo fuente a
partir de modelos pre-escritos en un tiempo notoriamente inferior al que
actualmente se emplea en la confeccin del mismo cdigo sin el apoyo de
25
modelos. A la vez, se incorporarn aspectos de apoyo a la construccin, tales

como funciones comunes y objetos.
Objetivos
Los objetivos de este trabajo son:
1. Descripcin de un metalenguaje que permita generalizar los programas tipo
que sern luego los modelos para generar programas de esa familia.
2. Construir un prototipo de generador, que a partir de los modelos y
especificaciones genere un programa fuente.
3. Probar y comparar prototipo con un caso real de empresa de desarrollo.
La construccin de un prototipo apoyar la tesis respecto a que es posible
confeccionar cdigo fuente clonando programas ya hechos y que han sido
generalizados para que sirvan de modelo a otros programas de similar
estructura. La funcionalidad de una aplicacin de esta naturaleza puede exceder
todo tipo de especificacin, por lo que se construir una aplicacin que pruebe la
hiptesis, ms que pensar en la obtencin de un software completo con todas
las etapas de generacin y que est en condiciones de entrar en explotacin en
una empresa productiva.
Si bien se mostrarn aplicaciones construidas por el generador, no es cobertura
de este trabajo otorgar funcionalidad completa al prototipo, por lo que
constituir un trabajo por realizar la confeccin de dicho generador, que utilice la
misma tcnica aqu descrita y que permita generar aplicaciones, aportando
funcionalidad de apoyo a los programadores, como diseadores de pantallas,
reportes, herramientas de gestin de B. de Datos, etc.
26
5. ESPECIFICACIN DE REQUISITOS DEL PROTOTIPO
Introduccin
El prototipo es una aplicacin que genera programas a partir de modelos
parametrizados. Se establece que estos programas sern generados dentro del
contexto de un Sistema, de manera que es necesario inscribir primeramente un
Sistema, dentro del que se registrarn Aplicaciones, que se obtendrn como
clones de programas generalizados denominados Modelos. La complejidad
mayor de esta aplicacin radica en que la entrada es un archivo con un cdigo
fuente generalizado (modelo) ms variables ambientales (Sistema, Aportes,
Objetos) y la salida del mismo es otro archivo con cdigo fuente particular para
las variables ambientales especificadas, o sea, una instancia ejecutable del
modelo de entrada.
El prototipo operar sobre 3 tablas maestras, ms elementos que sern tomados
desde archivos externos, a saber, los aportes y los objetos y funciones (ver
figura 4 en cap. 4).
Las tablas son Sistemas, Modelos y Aplicaciones. El detalle de este modelo se
encuentra en el anexo 2, an cuando para efectos didcticos se indica que la
tabla SISTEMAS posee registros de los sistemas con los que se trabaja,
otorgando variables ambientales elementales, tales como Nombre, Servidor,
Directorio de Programas, entre otros. De igual forma, la tabla MODELOS poseer
un registro con los programas generalizados o modelos, con referencia al (a los)
respectivo(s) archivo(s) que contienen los modelos en s mismos. Finalmente, la
tabla APLICACIONES contiene un registro de las aplicaciones, pertenecientes a
un sistema y que utilizan un modelo para ser generadas.
Requisitos Funcionales
El prototipo debe proveer 3 programas Mantenedores, uno para cada una de
estas 3 tablas, de manera que sea posible inscribir, modificar y eliminar
sistemas, modelos y aplicaciones. Las particularidades se encuentran en el
27
anexo 2, donde se incluyendo restricciones, layout de pantallas y reglas propias

para cada mantenedor de cada tabla.
Estos mantenedores sern invocados desde un men principal de opciones.
Dentro del mantenedor de aplicaciones, se incluir una opcin para GENERAR el
cdigo para una aplicacin que ya est inscrita en la tabla aplicaciones.
La generacin se deber realizar a partir de una aplicacin inscrita dentro de un
sistema, la que tiene asociado un modelo. La generacin se efectuar tomando
el archivo con cdigo fuente generalizado correspondiente al modelo, ms la
utilizacin de los datos del sistema al que pertenece la aplicacin (servidor, base
de datos, directorio, etc.) y usando los parmetros propios que se hayan inscrito
en la aplicacin (una tabla especfica por ejemplo).
La interpretacin del archivo del modelo se regir por lo indicado en anexo 1,
puesto que este archivo de entrada posee una generalizacin de lo que fue un
programa operativo y el generador debe interpretar los comandos que all
vienen para generar el cdigo fuente de salida.
Requisitos no Funcionales
Se consideran los siguientes requisitos no funcionales:
Mantener la funcionalidad y eficacia de los modelos de entrada en los

programas de salida
Capacidad tanto para agregar modelos modificar existentes y adems

capacidad para enriquecer el metalenguaje de ser necesario
Generacin Multi-plataforma y Multi-Lenguaje
Operable en cualquier equipo PC estndar en cualquier empresa
La especificacin detallada de requisitos constituir adems coo el manual de

usuario (anexo 2)
28
29
6. DISEO DEL PROTOTIPO
Introduccin
A fin de cumplir con los objetivos indicados al final del captulo 4, se realiz un
catastro en 2 empresas productivas: Celulosa Arauco y Constitucin S.A.
[Arauco2009]
Forestal
Mininco
S.A.
[CMPC2009],
las
que
efectan
eventualmente la clonacin de programas sin una metodologa ni herramienta

alguna, pues an cuando ellos han detectado que se generan ahorros de tiempo,
no han realizado el anlisis de estos ahorros ni menos han pensado en
automatizar el proceso.
La clonacin la efectan manualmente, por iniciativa de algunos programadores,
por lo que se estudi durante meses la tcnica y se complet sta con un
procedimiento automatizado, que se describe a continuacin.
Mecnica de Trabajo
Un programa clonable, esto es, uno de los que est dentro del 38% de mayor
ocurrencia en los SIAs estudiados (ver tabla 1, cap. 4), posee la cualidad de ser
repetible para otro conjunto de datos y/o de variables ambientales. Si se
independiza de los datos originales y de las variables ambientales originales,
entonces el cdigo fuente y la estructura del mismo puede re-utilizarse en otro
sistema, para otro conjunto de datos y variables, obteniendo un clon que se
comporta de idntica forma al original, pero en su nuevo ambiente.
Este principio hace que, identificados los programas dentro de este tipo, stos
pasen por un proceso de parametrizacin, de manera que se conviertan en el
input del generador, denominados assets.
Por tanto, el generador, debe ser un programa que acepte como entrada este
cdigo fuente generalizado, ms el conjunto de datos y las variables
ambientales, procediendo luego a ejecutar la generacin (ver figura 4, captulo
4).
30
El primer desafo fue confirmar que un archivo con cdigo fuente ejecutable
poda ser input de otro programa (el generador) y luego ser output de este
programa, de manera que este output siguiera siendo un cdigo fuente
ejecutable. Se realizaron las pruebas y se confirm el hecho, con lo que se
elabor la siguiente arquitectura de solucin:
Programa
Fuente input
(ejecutable)
Generado
r
v1
Programa
Fuente output
(ejecutable)
Figura 5: Arquitectura Bsica
Pasada esta primera y gran prueba, se confirm que era posible automatizar el
proceso que hasta ahora era manual e incompleto, por cuanto se realizaba de
manera muy artesanal, no sistemtica y solo por iniciativa de algunos
programadores.
Descripcin del Diseo

Al avanzar en la tcnica, se descubri que lo que cambiaba desde un programa
original hacia un clon eran variables y campos de una tabla. Dentro de las
variables se encuentran las denominadas ambientales, a saber nombre de la
aplicacin, del sistema, servidor, directorios, etc., campos que pueden ser
31
obtenidos desde el algn repositorio donde estn registrados. En cambio, en el

caso de los campos de una tabla, se trata de conocer la tabla, obtener los
campos de sta y luego generar cdigo variable, pues cada tabla tiene campos
distintos en nombre, tipo y sobretodo cantidad, que necesariamente genera
cantidad de lneas de cdigo distintas, lneas de cdigo con ms o menos
caracteres (por cantidad de campos), etc.
Esta condicin variable y que adems implica que se puede dar variabilidad
entre un modelo parametrizado a otro, oblig a pensar en alguna forma de
indicar al generador el comportamiento que debe tener cuando lee el modelo
con el cdigo fuente como input y realiza un anlisis de este cdigo,
reemplazando variables por sus valores obtenidos y expandiendo o contrayendo
cdigo en el caso de enfrentar campos de una tabla.
La forma que se dise y que es indita para este tipo de aplicaciones, es la del
metalenguaje descrito en el anexo 1. Con este metalenguaje incorporado a los
modelos de entrada es posible generalizar un programa y luego volver a generar
una instancia particular y nueva, que se comporte como el original, pero sobre
otro mbito de datos y de variables ambientales.
El metalenguaje es universal y permite intercalarlo dentro de un cdigo fuente
de cualquier lenguaje de programacin, por lo que generar uno u otro lenguaje
como programa de salida es tan simple como obtener el modelo respectivo en el
lenguaje deseado.
La potencia de este diseo radica en que posee todos los elementos necesarios
para clonar programas, incorporando mejoras puntuales por programa, sin tocar
el modelo y sin tener que modificar o enriquecer el programa fuente generado.
Si se visualiza necesario hacer esto, se modifica el archivo de aportes, que de
acuerdo a lo indicado al final del anexo 1, es el lugar donde se deben incorporar
particularidades de la nueva instancia del modelo clonado.
Esquema Funcional
32
El prototipo toma el modelo que tiene el cdigo fuente, el que normalmente

referencia objetos y funciones propias de la organizacin. Verifica si tiene archivo
de aportes, toma las variables ambientales que aporta el sistema al que
pertenece la aplicacin a clonar y procede a generar el cdigo fuente de salida,
de acuerdo a la lgica que le aporta el metalenguaje que est inserto dentro del
modelo.
El resultado es un programa clonado, enriquecido con aportes, con toda la lgica
funcional y de imagen que tiene el modelo original, sin errores de programacin,
excepto aquellos que el programador haya cometido en el archivo de aportes.
Programa
Generalizado
(MODELO)
Aportes
Generado
r
Variables
Ambientales
(SISTEMA)
Objetos
Funciones
Program
a
Final
(clon)
Figura 6: Diseo de Solucin
33
7. PRUEBA y RESULTADOS
Antecedentes
En el captulo 4, se identifican los tipos de programas que son candidatos a ser
tratados como plantillas para generar nuevos programas similares. Estos son:
Mantenedores Simples
Mantenedores Compuestos
Consultas con filtro
Reportes
Mdulo de Control de Acceso
Mdulos de Parmetros
Aplicaciones Transaccionales
Carga de Registros
Se indica adems que stos representan el 38% del total de programas de un

sistema. Esto no significa que los ahorros de tiempo de construccin de
programas clonados a partir de stos sea tambin del 38%, sino posiblemente
menos, pues se deben considerar las diferentes etapas que tiene un programa y
que solo algunas se ven favorecidas con la tcnica ac descrita, mantenindose
los tiempos empleados en las otras etapas, comparando la programacin
tradicional sin modelos versus la que utiliza el generador. Las etapas en la
construccin de un programa son [Pressman2006]:
1. Anlisis de Requisitos
2. Diseo General
5%
10%
3. Diseo de Detalle
4. Programacin
20%
45%
5. Prueba de unidad
5%
6. Prueba de Integracin
5%
7. Implementacin
5%
8. Imagen Corporativa
5%
El porcentaje representa el esfuerzo (en relacin a las HH) que se hace en cada
etapa de programa, utilizando desarrollo tradicional.
34
Se realizaron pruebas de construccin de Mantenedores simples, Consultas

con filtro,
Reportes y Aplicaciones Transaccionales, con el apoyo de las
empresas Arauco y CMPC Mininco, sobre el siguiente escenario de pruebas.

1. mbito de Datos: se consideraron tablas con 5 y 20 campos
2. Prueba se hace para los 4 tipos de aplicaciones, en 2 lenguajes diferentes
(PHP, ASP). Los tiempos empleados son prcticamente idnticos para
ambos lenguajes, por lo que se independizar esta variable, presentando
los datos en una sola tabla.
Inicialmente se efectu la prueba con la programacin sin modelos (tradicional).
A partir de los programas obtenidos, se construyeron las plantillas (assets)
parametrizadas, los que se usaron para la prueba con generador. Este tiempo de
parametrizacin no se contabiliz, pues se ejecuta solo una vez. Se observ que
las etapas 1, 2, 6 y 7 no presentan diferencia significativa entre lo tradicional y
con generador, toda vez que corresponden a etapas no apoyadas directamente
por la aplicacin.
En cambio las etapas 3, 4, 5 y 8 muestran una diferencia importante, ya que se
trata de la generacin misma del cdigo, de diseo, pruebas especficas y de
imagen corporativa, en donde se observan ventajas significativas. En particular
la etapa 4, en el caso del generador, puede tener una componente de
programacin tradicional, si consideramos los aportes que se le hacen al
producto.
Detalle de las Pruebas

Se realiz la construccin de los 4 tipos de aplicaciones, para un escenario de 5
campos en una tabla principal y para otro escenario de 20 campos en la tabla
principal. Esta prueba se hizo con 3 tipos de sistemas diferentes, a saber,
Ventas,
Abastecimiento
Personas.
Los
resultados
que
se
incluyen
continuacin son los promedios de tiempo obtenidos, los que muestran una
desviacin mnima entre un sistema y otro, por lo que se considerarn
promedios de los 3 sistemas. Como ya
se indic en la seccin anterior, se
gener en lenguaje PHP y en ASP, pero al no observar diferencias significativas
35
entre ambos, se tabul solo una de ellas, en este caso, PHP con motor de datos
Microsoft SQLServer 2008.
Las etapas de la prueba, tanto para el caso en que no se utiliza generador
(tradicional) como en el caso en que se utiliza esta herramienta fueron:
Idntica en ambos casos
2. Diseo General
3. Diseo de Detalle
Cuando la aplicacin es de uno de los tipos de aplicaciones comunes a
otros sistemas (modelo parametrizado), este tiempo se disminuye
considerablemente con generador, pues no se realiza mayor diseo, pues
la estructura de la aplicacin ya est lista.
4. Programacin
Si la aplicacin es de uno de los tipos de aplicaciones comunes a otros
sistemas, este tiempo se limita solo a los aportes particularidades de
esta aplicacin respecto al estndar que se tiene (asset), lo que es
significativamente menor en el caso del generador.
5. Prueba de unidad
sistemas, este tiempo se limita a la prueba de los aportes, pues el resto
ya est probado.
6. Prueba de Integracin
7. Implementacin
36

sistemas, este tiempo se minimiza hasta desaparecer, pues las plantillas
se construyeron con la imagen corporativa de la empresa, por lo que no
hay nada que aportar.
Para las pruebas se hizo el anlisis de requisitos, se crearon las bases de datos
respectivas y luego se construyeron las aplicaciones, en forma tradicional y con
el generador. Para la opcin generador, se confeccion previamente la
programacin de aportes especiales que permitieran cubrir los requerimientos,
ms all de la funcionalidad estndar que ofrecen las plantillas.
Es importante destacar que una vez construidas las bases de datos, generar
cdigo en forma automtica es trivial y las pruebas mostraron que era muy
eficaz generar con el modelo estndar para luego incorporar los aportes en los
puntos donde fuere necesario, de manera de conseguir la funcionalidad que se
indica en los requisitos, la que en la mayora de los casos consisti en
restricciones y/o validaciones adicionales a los datos.
Comparativo de Tiempos
Los tiempos empleados (en horas) para el desarrollo tradicional y el que usa
generador fueron:
Mantenedor
Simple
Nmero de Campos
Consulta
con Filtro
Reporte
Aplicacin
Transaccional
20
20
20
20
5%
1,0
1,2
0,8
1,0
1,0
1,2
0,8
1,0
2. Diseo General
10%
2,0
2,4
1,6
2,0
2,0
2,4
1,6
2,0
3. Diseo de Detalle
20%
4,0
4,8
3,2
4,0
4,0
4,8
3,2
4,0
4. Programacin
45%
9,0
10,8
7,2
9,0
9,0
10,8
7,2
9,0
5. Prueba de Unidad
5%
1,0
1,2
0,8
1,0
1,0
1,2
0,8
1,0
6 .Prueba de Integracin
5%
1,0
1,2
0,8
1,0
1,0
1,2
0,8
1,0
7. Implementacin
5%
1,0
1,2
0,8
1,0
1,0
1,2
0,8
1,0
5%
1,0
1,2
0,8
1,0
1,0
1,2
0,8
1,0
20
24
16
20
20
24
16
20
Tabla 2: Tiempos con Desarrollo Tradicional sin modelos (hrs.)
Mantenedor
Simple
Nmero de Campos
Consulta
con Filtro
Reporte
Aplicacin
Transaccional
20
20
20
20
14%
1,0
1,2
0,8
1,0
1,0
1,2
0,8
1,0
2. Diseo General
29%
2,0
2,4
1,6
2,0
2,0
2,4
1,6
2,0
3. Diseo de Detalle
14%
1,0
1,2
1,0
1,2
1,0
1,2
1,6
2,0
37
4. Programacin
13%
0,9
1,1
0,7
0,9
1,8
2,2
7,2
9,0
1%
0,1
0,1
0,2
0,2
0,1
0,1
0,4
0,5
6 .Prueba de Integracin
14%
1,0
1,2
0,8
1,0
1,0
1,2
0,8
1,0
7. Implementacin
14%
1,0
1,2
0,8
1,0
1,0
1,2
0,8
1,0
0%
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
13
17
5. Prueba de Unidad
Tabla 3: Tiempos con Desarrollo con Generador (hrs.)
La tabla 2 de desarrollo tradicional sin modelos se construy a partir de los

estndares de desarrollo con los que trabaja una de las empresas apoyan esta
tesis [CMPC2009] y los valores de la tabla se calcularon a partir del estndar
(lnea final) y los % asignados a cada etapa.
En la tabla 3 de desarrollo con generador se mantuvieron los tiempos de las
etapas 1, 2, 6 y 7, que son las etapas que no se ven afectadas en aspecto
alguno con la tcnica. Para las etapas 3, 4, 5 y 8 se midieron los tiempos
empleados, luego se recalcularon los porcentajes de cada etapa, con lo que la
distribucin ahora se concentra en el diseo general ms que en la
programacin, la que no es cero debido a los aportes que se agregan en
cualquier aplicacin. Al no haber aportes, el generador se tarda un tiempo
despreciable en generar el cdigo.
Se observan ahorros de 65%, 64%, 61% y 18% en las respectivas aplicaciones,
al desarrollar con el generador versus el desarrollo tradicional. En promedio el
ahorro es de un 52%.
El 18% en la aplicacin transaccional (valor algo bajo) se explica por el alto
contenido de aportes que hace el programador, siendo prcticamente igual a la
programacin tradicional. En este caso, el generador aporta el entorno, la
conexin a la base de datos, la imagen corporativa y el ambiente de generacin
y pruebas, la codificacin es casi igual que para el caso tradicional.
Distribucin de Tiempos en Etapas

Observamos una nueva distribucin de la carga asignada a las distintas etapas
del desarrollo:
38
Grfico 1: Comparativo de pesos de las etapas del desarrollo
Podemos observar que las horas hombre se concentran ahora en un buen diseo
de la aplicacin, para luego aprovechar las plantillas existentes, utilizando
tiempo solo en los aportes y mejoras puntuales y concentrarse en las pruebas y
entrega, pues las aplicaciones construidas con esta tcnica replican su forma, su
funcionalidad e imagen, no generando errores por cuanto la materia prima
(assets) no los contiene y la tcnica asegura un clon idntico al modelo.
Considerando tres sistemas de ejemplo facilitados para estos fines por Forestal
Mininco, con 12.960 HH en total, que tienen la distribucin de HH y %
anteriormente indicadas, es posible afirmar que se podra haber ahorrado un
52% sobre el 38% de las aplicaciones, esto corresponde a 2.560 HH.
Valorizando la HH en UF 0,3 esto es aprox. US$15, podemos afirmar que este
ahorro habra hecho
invertir US$156.000 (para 10.400HH) en vez de
US$194.400 (para las 12.960HH), con un ahorro de US$38.400.

Este resultado, que corresponde a un ahorro de 19,76% en la cantidad de HH
empleadas de la totalidad de 3 sistemas, muestra que:
1. Existe un subconjunto de aplicaciones dentro de un sistema que son
repetibles entre sistemas y que pueden considerarse como materia prima
para otros sistemas.
39
2. Que es posible, identificadas estos tipos de aplicaciones, tomarlas como

plantilla modelo para construir aplicaciones similares.
3. Que automatizando este proceso, se consiguen ahorros de casi un 20% en el
total de las HH empleadas, cumpliendo todos los requerimientos indicados.
4. Que al bajar considerablemente el tiempo de codificacin, pruebas y de
forma, los analistas y programadores pueden emplear el tiempo de mejor
forma, apuntando al diseo, las pruebas y la integracin de todas las
aplicaciones, ms que seguir usando tiempo en aplicaciones que se repiten y
que constituyen una trivialidad entre distintos sistemas.
Un software generador, con el principio de las plantillas puede y debe ser
utilizado en los equipos de desarrollo. Arauco y Mininco lo estn considerando,
siendo el primero de ellos el que ms avance tiene pues ya ha realizado pruebas
en algunas aplicaciones de este tipo con el generador con dos lenguajes
(COBOL, ABAP R/3) con muy buenos resultados, an cuando no hay planes
definitivos de uso de esta tcnica.
La aplicacin es la misma, solo cambian las plantillas que se utilizan como
materia prima para la generacin. El concepto se mantiene y la productividad se
ve incrementada a travs de esta tcnica.
8. CONCLUSIONES
Antecedentes
La hiptesis planteada para este trabajo indica que es posible describir e
implementar una tcnica que permita generar el cdigo fuente de programas en
forma automtica a partir de modelos provenientes de programas anteriormente
confeccionados y generalizados. Esta hiptesis considera la tesis que indica que
en muchos sistemas de informacin administrativos existe cdigo fuente similar
( incluso idntico) entre distintos programas, repetitivos en cada sistema. A la
vez, para demostrar esta hiptesis, se consideraron los siguientes objetivos:
1. Descripcin de un metalenguaje que permita generalizar los programas tipo
que sern luego los modelos para generar programas de esa familia.
40
2. Construir un prototipo de generador, que a partir de los modelos y

especificaciones genere un programa fuente.
3. Probar y comparar prototipo con un caso real de empresa de desarrollo.
Resultados y Conclusiones
La bsqueda de programas repetitivos entre sistemas se consigui cabalmente,
logrando un ndice de 38% de los programas presentes en sistemas de
informacin administrativos (SIAs). Esto muestra que existe un importante
nmero de programas que se repiten entre SIAs diferentes. De la muestra
(12.960 HH en 3 SIAs), este porcentaje corresponde a:
Mantenedores Simples
Mantenedores Compuestos
Consultas con filtro
Reportes
Mdulo de Control de Acceso
Mdulos de Parmetros
Aplicaciones Transaccionales
Carga de Registros
Considerando los sistemas ya indicados, a los que no agregaremos 2 sistemas

ms, probados en una empresa de desarrollo en Los ngeles, con 3.520 HH, por
cuanto los tipos de programas en estos 2 sistemas se repiten casi de manera
idntica respecto a los 3 primeros, por lo que se considerarn solo los iniciales,
tenindolos por representativos para la muestra y para las conclusiones
obtenidas.
A partir de estos tipos de programa, se convirtieron 5 de stos en plantillas
parametrizadas que hemos denominado assets y se realiz la produccin de
programas con 2 escenarios de datos, considerando para ello el programa
generador que toma este asset y lo convierte en un programa idntico al
original, aplicando las particularidades que pudiera tener esa instancia de
programa, a saber, tabla(s) especficas, aportes adicionales, intervenciones
especiales u otro de acuerdo a lo que el diseo permite.
41
El programa generador permite tomar un asset en cualquier lenguaje y

convertirlo en un programa fuente compilable, completo, idntico en estructura
al original pero distinto en particularidades que se necesite segn la instancia. El
generador utiliza para ello la interpretacin de un metalenguaje que se incorpora
al programa original, el que se viene a denominar asset cuando est convertido,
generalizado y tiene incorporados los mensajes y lgica que interpreta luego el
generador.
El metalenguaje utilizado se dise para cubrir la funcionalidad necesaria. No
fue posible encontrar un lenguaje que permitiera la sustitucin, expansin,
seleccin, iteracin y decisin de incorporacin de cdigo en el producto final,
por lo que se construy un lenguaje para estos fines (ver anexo 1) y se incorpor
al
generador
la
interpretacin
de
este
metalenguaje,
obteniendo
una
herramienta que adems tiene capacidad de expansin, pudiendo incorporar

nuevas clusulas y sentencias al metalenguaje, en funcin de nuevas
necesidades que surjan en el futuro.
Las pruebas realizadas se muestran en el captulo 7. Son pruebas acotadas y
realistas, que muestran en detalle las etapas del desarrollo de software que se
ven apoyadas por la tcnica y aquellas que no se ven favorecidas, realizando las
mediciones donde corresponde. Es importante recalcar este punto, por cuanto se
puede llegar a conclusiones equivocadas y demasiado optimistas si se observa
al generador en accin, toda vez que la generacin de una aplicacin teniendo
las tablas y aportes listos- es prcticamente instantnea, lo que no corresponde
a la realidad del ahorro, sino que segn lo confirmado, se trata de un 52% de
ahorro promedio, sobre el 38% de los programas de un sistema. Esto equivale a
un ahorro de HH de 19,76%, probado en 5 sistemas.
La hiptesis planteada se confirm en la totalidad de los sistemas probados, es
ms, existen pruebas adicionales que han confirmado la factibilidad de
generacin a partir de assets de prcticamente cualquier programa fuente que
tenga tronco comn y partes variables.
Los objetivos se consiguieron a cabalidad, apuntando directamente a confirmar
la hiptesis, con lo que se est en presencia de un producto concreto y
comercializable. El software generador ya se encuentra patentado.
42
Se observ que las empresas de desarrollo poseen algn grado de generacin a

partir de plantillas, pero de manera totalmente manual, con prdidas de tiempo
y seguridad, y ms bien concentrando los ahorros en la pro-actividad de algunos
analistas y programadores. La empresa debera considerar este trabajo para
automatizar todos sus procesos de generacin de programas a partir de assets,
consiguiendo los ahorros ya indicados a lo menos, y sentando las bases para el
desarrollo de sistemas con un set de aplicaciones con el que se puede contar,
por cuanto no forman parte de un diseo acabado sino ms bien de programas
normalmente presentes en SIAs y que podran tenerlos disponibles desde el
tiempo cero.
Observamos adems mejoras en los tiempos de programacin; facilidad de
mantenimiento de aplicaciones (por la estandarizacin); capacidad de reconstruir rpidamente aplicaciones en desarrollo por prototipos; orientacin al
cliente ms que al cdigo; uniformidad de aplicaciones, por provenir todas de
plantillas estndares; aumento de la independencia del programador, ya que
utiliza una tcnica y estndares reflejados en los assets, entre otras mejoras no
dimensionadas.
Como trabajo futuro deber abordarse el enriquecimiento del metalenguaje,
para permitir la generacin de algunos fuentes ms complejos incluso mas
diversos, como la documentacin bsica de la aplicacin. Es necesario
incorporar un administrador de directorios, aportes y datos, ya que esto se ha
dejado a la administracin que el programador haga de estos tems. Se requiere
poder generar ms de un fuente de salida, ya que algunos ambientes (.NET por
ejemplo) utilizan varios archivos de salida para una misma aplicacin. No se ve
necesario incorporar diseadores de pantalla de layout de reportes, pues se
sugiere utilizar los existentes y dejar al generador solo la generacin de la
grfica inicial y estndar, para no distraer esfuerzos en algo que ya est
resuelto.
43
9. REFERENCIAS
[Alonso2007]
Automatic Ada Code Generation Using a Model-Driven

Engineering Approach
Diego Alonso,Cristina Vicente-Chicote,Pedro Snchez,Brbara lvarez
& Fernando Losilla
Divisin de Sistemas e Ingeniera Electrnica (DSIE)
Universidad Politcnica de Cartagena, Campus Murrala del Mar, E302002, Spain
[Arauco2009]
Entrevistas ARAUCO
Equipo de Desarrollo ARAUCO Aserraderos, 2009
[Basulto2001]
Generador de Cdigo con Plantillas XML

Carla Basulto, Abraham Dvila
Grupo de Investigacin y Desarrollo en Ing. de Software,
P.U.C. del Per, 2001
[Borland2004]
Borland Software Corporation

Borland Corporative Brochure, 2004
[Castagnet2007] Software Factories para construir Sistemas de Informacin con

GeneXus
Nicols Castagnet
Universidad de la Repblica, Uruguay, 2007
[CMPC2009]
Entrevistas CMPC
Equipo de Desarrollo CMPC Forestal Mininco, 2009-2010
[Czarnecki1999] Components and Generative Programming

Krzysztof Czarnecki
DaimlerChrysler AG Research and Technology, Ulm, Germany
Ulrich W. Eisenecker
University of Applied Sciences Heidelberg, Germany
[Eclipse2009]
The Eclipse MOFScript sub-project

Jon Oldevik
Eclipse Development Group, 2009
[Falcn2007]
Gestin del re-uso de Software

Abril Falcn, Jonathan Pal, Otaz Estrada, Vctor Luis
Facultad de Ingeniera, Universidad Peruana de Ciencias Aplicadas,
Per, 2009
[Gally2007]
What is MDD/MDA and where will it lead the software

development in the future?
Matthias Gally
Department of Informatics at the University of Zurich, Switzerland,
2007
44
[Gonda2007]
Desarrollo basado en el Conocimiento

Breogn Gonda, Nicols Jodal
Artech, Uruguay, 2007
45
[Greenfield2003] Software Factories, Assembling Applications with Patterns,

Models Frameworks and Tools
Jack Greenfield, Keith Short
Microsoft Corporation, 2003
[Griss1994]
Software reuse experience at Hewlett-Packard

Martin L. Griss
16th International Conference on Software Engineering, Italy, 1994
[Joss1994]
Software reuse at Motorola

R. Joss
IEEE Software, vol. 11, # 5, pp. 42-47, 1994
[Musat2009]
ESPORA: Definicin de Lenguajes de Operacin Especficos de

Dominio Siguiendo un Proceso de Desarrollo Dirigido por
Modelos
David Musat Salvador, Jennifer Prez Bened, Pedro Alarcn Cavero
Grupo de Investigacin SYST, Universidad Politcnica de Madrid,
Espaa, 2009
[OMG2003]
Object Management Group

MDA Guide Version 1.0
OMG, 2003
[Pressman2006] Ing. de Software: un enfoque prctico (5ta edicin)

Roger Pressman
McGraw Hill, 2006
[Quintero2007]
MDA y el papel de los modelos en el desarrollo de Software

Juan Bernardo Quintero, Raquel Araya
Escuela de Ingeniera de Antioqua, Medelln, Colombia, 2007
[Standish1994]
The Standish Group

The Chaos Report, 1994
46
Anexo 1: ESPECIFICACIN METALENGUAJE

Introduccin
El metalenguaje creado para este proyecto responde a la necesidad de
incorporar mensajes para el generador, puesto que para que tenga el
comportamiento esperado, esto es, clonar un modelo en una nueva instancia de
programa, se deben aportar datos (variables ambientales) de la nueva instancia,
informacin de la las tablas que se utilizarn y otros, los que se realizan
mediante el uso de este lenguaje, que se intercala en el programa fuente
original, en un proceso que denominamos generalizacin y que consiste en
llevar un programa probado con un set de datos a un programa genrico, que
puede ser tomado por el generador y luego obtener a partir de l otro programa
clon del primero, pero que trabaje sobre otro set de datos y/o variables
ambientales.
El metalenguaje consiste de variables y sentencias. Entre estas ltimas
consideraremos las de iteracin, las condicionales y los aportes. En el caso de
las variables, se utilizan encerradas entre 2 caracteres . Para las sentencias,
se antepone el carcter .
<linea input>
::=
<lenguaje final>::=
compilador respectivo.
<variable> ::=
<palabra clave>
tabla3 | server |
<especiales>
<sentencia>
<iteracin> ::=
<condicional>
<aportes> ::=
<parrafo> ::=
<lenguaje final> [variable] [variable] | <sentencia>

sentencia en lenguaje a generar respeta sintaxis del
<palabra clave>
::=
sistema | appnombre | apptitulo | tabla1 | tabla2 |
dbname | usuario | clave | campo1 | <especiales>
::=
allcampo1 | coma | i | i-1 | nlf
::=
<iteracin> | <condicional> | <aportes>
para - tabla 1 | 2 | 3
<linea input> <linea input>
para-fin
::=
si -es_clave 1 | 2 | 3
<linea input> <linea input>
[ si-no]
[ <linea input> <linea input> ]
si-fin
include <parrafo>
X1 | X2 | ZZ para todo ZZ en modelo parametrizado
47
48
Palabras Clave
Aclaracin del significado y valores que toman las palabras clave.
Palabra
Clave
Observacin
sistema
Nombre del Sistema
appnombre Nombre de la Aplicacin

apptitulo
Descripcin de la Aplicacin
tabla1
Tabla1
tabla2
Tabla2
tabla3
Tabla3
server
Servidor de Base de Datos
dbname
Nombre de la Base de Datos
usuario
usuario
clave
password
campo1
Campo de la Tabla1
Tabla 1-1: Palabras Clave
Variables Especiales
Aclaracin del significado y valores que toman las variables especiales.
Especiales Observacin
Lista separada por coma de todos los campos de la
allcampo1
tabla 1
Coma dentro de un ciclo PARA, excepto para el
coma
ltimo elemento
i
i-1
Numero de iteracin dentro de un ciclo PARA

Numero de iteracin menos 1 dentro de un ciclo
PARA
nlf
Indica al generador "No Line Feed"

Tabla 1-2: Variables Especiales
Uso de variables dentro de los modelos

Intercalado con el cdigo en el lenguaje de generacin, se incorporan estas
variables y campos especiales, los que sern reemplazados por el generador por
su respectivo valor. Ejemplos de esto:
sistema se reemplazar por el nombre del sistema bajo el que se est
generando
tabla1 se reemplazar por el nombre de la tabla1 que se seleccion
49
Se usa el smbolo (ASCII 128) por ser un smbolo no utilizado en lenguaje

alguno
Si en el modelo aparece: System=sistema, Table=tabla1
ser reemplazado por: System=Ventas, Table=Clientes
50
Una aplicacin es generada dentro de un sistema, usando un modelo

parametrizado como estructura base y especificando tabla(s) y otro(s)
elementos diferenciadores. Al especificar Sistema, se heredan sus atributos, a
saber, directorio donde quedan los programas, servidor, base de datos que
accesa, etc. los que corresponden a las otras variables ya descritas.
Uso de sentencias dentro de los modelos

Dentro de las plantillas se utilizan sentencias que son instrucciones para el
generador, de manera de normar su operacin y conseguir la expansin y
correcta generacin del cdigo. Estas sentencias comienzan en la columna 1 del
texto, vienen antecedidas por el carcter y corresponden a:
Sentencia
Observacin
parametros Inicio de parmetros requeridos por la plantilla

parametrosfin
Fin de parmetros requeridos
Inicio ciclo FOR con los campos de la tabla1 seleccionada
para-tabla1 previamente
para-fin
Fin del ciclo FOR

IF dentro de un ciclo para-tabla1. Es verdadera si el campo
si-es_clave1 vigente es clave
si-no
Condicin ELSE
si-fin
Fin de la sentencia IF anterior

Incorporacin de cdigo directo en un punto de intervencin
permitido
include XX
Tabla 1-3: Sentencias
Sentencia de Parmetros
Se utiliza en tiempo de registro de la aplicacin, antes de la generacin. Es un
aviso para el mantenedor de aplicaciones, indicndole que debe solicitar al
usuario el nombre de una tabla para esta aplicacin. Ofrece el set de tablas
disponibles en la base de datos del sistema asociado. En tiempo de generacin
esta secuencia es obviada.
parametros
tabla1
parametros-fin
Este ejemplo muestra que este modelo requiere una tabla, la que ser usada
luego para la generacin del cdigo utilizando los campos y atributos de esa
tabla.
51
Sentencia de Iteracin
Corresponde al comando de iteracin para-tabla1, el que se interpreta como
recorrido de todos los campos de la tabla1. Finaliza con para-fin. Similar
comportamiento tiene para-tabla2 con los campos de la tabla2. dem para la
tabla3.
Se usa el smbolo (ASCII 230) por ser un smbolo no utilizado en lenguaje
alguno. Se coloca en la primera columna de una lnea en el modelo
parametrizado.
Constituye un comando que el generador deber interpretar como un ciclo FOR
sobre todos los campos de la tabla1 (2 3).
Ejemplo 1:
para-tabla1
Msgbox (campo1: + campo1)
para-fin
ser reemplazado por:

Msgbox
Msgbox
Msgbox
Msgbox
Msgbox
(codigo: + codigo)
(descripcion: + descripcion)
(provincia: + provincia)
(alcalde: + alcalde)
(habitantes: + habitantes)
Ejemplo 2:
para-tabla1
<td><H5>campo1</td></H5>
para-fin
En tiempo de generacin, se recorrer la tabla1 (datos) e incluir una lnea de

cdigo final por cada campo de la tabla, quedando:
<td><H5>nombre</td></H5>
<td><H5>apellido</td></H5>
<td><H5>edad</td></H5>
52
Sentencia de Condicin
Dentro de un ciclo para, es necesario generar cierto cdigo si el campo en
cuestin cumple una condicin no, por ejemplo, si el campo es clave no.
Ejemplo 1:
para-tabla1
si-es_clave1
$consulta_sql=mssql_query("select * from tabla1 ORDER BY campo1",$conexion_sqlserver);
si-fin
para-fin
En tiempo de generacin, se recorrer la tabla1 (datos) y para cada campo de

sta, se evaluar si es clave, arrojando la sentencia SQL solo para el los
campos que cumplan esta condicin:
$consulta_sql=mssql_query("select * from datos ORDER BY nombre",$conexion_sqlserver);
Ejemplo 2:
para-tabla1
si-es_clave1
si-no
Msgbox (campo1)
si-fin
para-fin
generar:
Msgbox
Msgbox
Msgbox
Msgbox
(descripcion)
(provincia)
(alcalde)
(habitantes)
Sentencia de Aportes
Permite indicarle al generador que el programador realizar un aporte en cdigo
fuente directo. Dentro del modelo parametrizado, existirn puntos dentro del
cdigo donde se indicar:
Linea1
include X1
Linea n
Si el programa por generar se denomina P1 y existe un archivo llamado P1.APO,

escrito por el programador, donde identific un prrafo con el ttulo X1
entonces todo ese prrafo se incluir en el programa P1 que se est generando:
Linea1
Primera lnea del include X1
Segunda lnea del include X1
ltima linea del include X1
Linea n
53
Otro Ejemplo:
<form name="formulario1" action="<?=$_script; ?>" method="post">
<table width="335" align="center">
para-tabla1
<tr><td>campo1:</td>
<td><input type="text" name="campo1" maxlength="20" /></td></tr>
para-fin
<tr><td ><input type="submit" value="Grabar" name="ac" /> </td>
<td><input type="reset" value="limpiar"/></td>
</table>
include X3
</form>
y paralelamente, se ha creado el archivo Programa1.apo en el directorio del

sistema, con el texto:
X3
<td><input type="text" value="Prueba de Insercin"/></td>
<td><input type="text" value="Mas Pruebas"/></td>
entonces el generador producir el cdigo fuente anterior y le intercalar el prrafo X3, as:
<form name="formulario1" action="<?=$_script; ?>" method="post">
<table width="335" align="center">
<tr><td>nombre:</td>
<td><input type="text" name="nombre" maxlength="20" /></td></tr>
<tr><td>apellido:</td>
<td><input type="text" name="apellido" maxlength="20" /></td></tr>
<tr><td>edad:</td>
<td><input type="text" name="edad" maxlength="20" /></td></tr>
<tr><td ><input type="submit" value="Grabar" name="ac" /> </td>
<td><input type="reset" value="limpiar"/></td>
</table>
<td><input type="text" value="Prueba de Insercin"/></td>
<td><input type="text" value="Mas Pruebas"/></td>
</form>
La sentencia include se intercalar en la plantilla en todos los puntos en los

que se permita incorporar cdigo. El usuario-programador debe conocer la
estructura de las plantillas y los puntos de intervencin. A la vez, en el archivo
de aportes nombreprograma.apo se pueden incluir todos los prrafos de aportes
que se necesite, en el mismo texto, antecediendo un nuevo prrafo con el
nombre en el formato XY, donde XY es el nombre del prrafo referenciado en
la plantilla.
54
Anexo 2: ESPECIFICACIN DETALLADA DE REQUISITOS
Modelo de Datos
Una aplicacin se genera a partir de un modelo y aportes. Esta aplicacin
considera variables ambientales tomadas del sistema en el que se encuentra
definida. Un sistema puede contener n aplicaciones. Una aplicacin se
confecciona a partir de un solo modelo, pero un modelo puede ser la base de
generacin para muchas aplicaciones. Los aportes se tomarn de un archivo
externo, de acuerdo a lo indicado en anexo 1, seccin de aportes, por lo que
no se requiere una estructura de datos para estos fines. Tanto los sistemas,
como los modelos y las aplicaciones se registrarn en tablas que se describen a
continuacin.
Sistemas
1
Aportes
Aplicaciones
Modelos
Figura 2-1: Entorno para la generacin
Tabla:
SISTEMAS
Uso: Registro de los Sistemas dentro de los que se generarn aplicaciones.
Proporciona variables ambientales necesarias para el generador, pues se
incluyen estas en la mayora de las aplicaciones.
Campos:
Nombre
Descripcion
DBServer
DBNom
User
Pass
Direct
sistema
Texto
Memo
Texto
Nombre del Sistema

Texto Libre
Servidor de la Base de Datos
Texto
Nombre de la Base de Datos
Texto
Usuario con el que se conecta a la Base de Datos
Texto
Password del usuario anterior
Texto
Directorio donde quedarn los archivos del
55
Tabla:
MODELOS
Uso: Registro de los Modelos que constituyen los asset materia prima para el
proceso. Contienen referencias a los archivos plantilla que constituyen
los modelos parametrizados con los que se construyen las aplicaciones
clones.
Campos:
Nombre
Descripcion
Plantilla1
Plantilla2
Plantilla3
Texto
Memo
Texto
Texto
Texto
Nombre del Modelo

Texto Libre
Archivo con 1ra plantilla a utilizar
Archivo con 2da plantilla a utilizar (opcional)
Archivo con 3ra plantilla a utilizar (opcional)
Tabla:
APLICACIONES
Uso: Registro de las Aplicaciones que se generarn. Se inscriben asociadas a
un sistema. Referencian al modelo a partir del que se generar la
aplicacin. Se almacena tambin ac los parmetros necesarios para la
generacin.
Campos:
Sistema
Texto
Sistema al que pertenece esta aplicacin
Nombre
Texto
Nombre de la Aplicacin
Modelo
Texto
Modelo que usar esta aplicacin
Descripcion Memo
Texto Libre
Datos1
Texto
Parmetros requeridos por la plantilla 1
Datos2
Texto
Datos3
Texto
Requerimientos Funcionales
La aplicacin se inicia con un men de opciones generales:
56
Opcin Sistemas
Corresponde a un mantenedor que opera sobre la tabla del mismo nombre. Al
ingresar a la pantalla, se muestra una grilla con todos los sistemas que ya
existan en la tabla. Para efectos ilustrativos, el sistema que ya contenga
aplicaciones inscritas se mostrar en color verde.
Inmediatamente debajo de la grilla, se incluyen los botones Nuevo, Eliminar y

Salir. El botn Nuevo abre otra pantalla que muestra todos los campos en blanco
y permite ingresar un sistema nuevo.
El Botn Eliminar acta sobre el registro que est seleccionado. Si el sistema

tiene Aplicaciones (color verde) no permite eliminar.
57
Para modificar los datos de un sistema existente, presionar doble clic sobre en
NOMBRE del sistema. Se abrir la misma pantalla que en el caso de uno nuevo,
pero donde ya se muestran los datos del sistema, permitiendo modificar stos,
con excepcin del nombre del sistema.
Opcin Modelos
Corresponde a un mantenedor que opera sobre la tabla del mismo nombre. Al
ingresar a la pantalla, se muestra una grilla con todos los modelos que ya
existan en la tabla. Para efectos ilustrativos, el modelo que est en uso por
alguna aplicacin se mostrar en color verde.
Inmediatamente debajo de la grilla, se incluyen los botones Nuevo, Eliminar y

Salir. El botn Nuevo abre otra pantalla que muestra todos los campos en blanco
y permite ingresar un modelo nuevo.
58
Los campos Plantilla 01, Plantilla 02 y Plantilla 03 permiten seleccionar un

archivo de texto en el explorador de archivos. Este archivo contiene el programa
generalizado que se debe utilizar en este modelo.
El Botn Eliminar acta sobre el registro que est seleccionado. Si tiene el
modelo est en uso por alguna aplicacin (color verde) no permite eliminar.
Para modificar los datos de un modelo existente, presionar doble clic sobre en
NOMBRE del modelo. Se abrir la misma pantalla que en el caso de uno nuevo,
pero donde ya se muestran los datos del modelo, permitiendo modificar stos,
con excepcin del nombre del modelo.
Opcin Aplicaciones
Corresponde a un mantenedor que opera sobre la tabla del mismo nombre, an
cuando en este caso adems contiene la opcin de generar la aplicacin. Al
ingresar a la pantalla, se muestra en la parte superior una combo-box que
permite identificar el sistema bajo el que se inscribirn las aplicaciones. Bajo
este elemento, se muestra una grilla con todas las aplicaciones que ya existan
en la tabla, para el sistema que est indicado en la combo-box superior.
Inmediatamente debajo de la grilla, se incluyen los botones Nuevo, Eliminar,

Generar y Salir. El botn Nuevo abre otra pantalla que muestra todos los campos
59
en blanco y permite ingresar una aplicacin al sistema. El Botn Eliminar acta

sobre el registro que est seleccionado.
Para modificar los datos de una aplicacin existente, presionar doble clic sobre
en NOMBRE de la aplicacin y abre la misma pantalla que en el caso de una
nueva, pero donde ya se muestran los datos de la aplicacin, permitiendo
modificar stos, con excepcin del nombre de la aplicacin.
Tanto la pantalla para Aplicacin Nueva como la de Modificacin, que son muy
similares, tienen el campo Modelo como una combo-box, apuntado a la tabla
de Modelos. Seleccionado ste, el programa leer de la tabla Modelos la las
correspondiente(s) plantilla(s) que usa ese modelo. El programa abrir el(los)
archivo(s) asociado(s) a la(s) plantilla(s), verificando si sta(s) necesita(n)
parmetros especiales.
En el archivo de una plantilla, los parmetros vienen al principio, antecedidos
por una sentencia con un mensaje para el generador: parametros. Luego de
esta sentencia, vienen los parmetros requeridos por la plantilla. Para terminar
los parmetros, en la plantilla se agreg la sentencia parametros-fin, que
indica el fin de los requerimientos de parmetros especiales.
Ejemplo:
parametros
tabla1
parametros-fin
60
Siguiendo el ejemplo, en esta plantilla se requiere una tabla referenciada con

tabla1, entonces la aplicacin mostrar en una pantalla el parmetro requerido,
para luego mostrar del modelo de datos asociado al sistema, las tablas
existentes, permitiendo seleccionar una de ellas. Esta seleccin quedar
almacenada en el campo Datos1 de la tabla Aplicaciones. Se deber operar de
igual manera si la plantilla seleccionada trae algn dato en el campo Plantilla2
y Plantilla3.
Esta aplicacin termina con el botn Generar, que se describe a continuacin.
Generacin
Esta etapa es la principal del proceso. El programa a generar se ha inscrito
dentro de un sistema y se ha asociado a un modelo. La generacin consiste en la
clonacin de este modelo, utilizando los datos del sistema (base de datos,
directorio, etc.) y usando los parmetros del modelo (tabla1 por ejemplo) mas el
cuerpo mismo del modelo, el que es en si el programa de entrada, que posee
algunas sentencias que el generador interpreta y termina produciendo el texto
del programa final, copia de la entrada pero de acuerdo a los parmetros que se
especificaron.
Tomaremos como ejemplo un sistema denominado PERSONA.
61
El generador, para todos los efectos de generar una aplicacin dentro de este
sistema, tomar las tablas del sistema en un servidor local con la base de datos
PERSONA.
Los
programas
generados
los
dejar
en
el
directorio
\Mis
Documentos\Visual Studio 2008\PERSONA. En ese mismo directorio instalar los

objetos que sean necesarios para complementar las aplicaciones generadas.
Luego, al inscribir una aplicacin por generar y proceder a efectuar la
generacin, tenemos los siguientes eventos:
En este caso, para generar el Programa1, se utilizar el modelo Man Sim PHP
v3, que corresponde a un Mantenedor Simple en PHP, sobre la tabla datos de
la base PERSONA.
62
El generador buscar el archivo asociado al modelo indicado y comenzar la

generacin a partir de este programa fuente generalizado, interpretando las
sentencias de metalenguaje que vienen dentro del texto, modificando palabras
clave y ejecutando las instrucciones que estn indicadas dentro de la plantilla,
de acuerdo a la especificacin de funciones del metalenguaje especificado en
anexo 1, sintaxis que se debe respetar, pues no es necesario que el generador
revise la sintaxis, solo que la ejecute. Si se presenta una instruccin no incluida
en la definicin (anexo 1) el generador asumir que la sentencia no encontrada
es parte del cdigo fuente de salida y la incluir en el texto del programa que
est generando.
63

APaiva Tesis Final

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

APaiva Tesis Final

Transféré par

Droits d'auteur :

Formats disponibles

Universidad de Concepcin

Generacin de Cdigo a partir de modelos Parametrizados

ANDRS EDUARDO PAIVA MAULN

Profesor Gua: Ricardo Contreras Arriagada

ANEXO 1: ESPECIFICACIN METALENGUAJE...............................................................................40

En la actualidad la produccin de software debe ser realizada considerando tanto

La produccin automatizada de programas (generacin) es un trabajo hace ya

En el captulo 3 Estado del Arte se observar un anlisis de los trabajos

metalenguaje y que corresponde a la especificacin de un lenguaje que se

Estudios realizados en 2004 relativos a proyectos de software indican que ms

complementarlos y extender su vida til, de manera de acompaar el negocio.

manera que el equipo de programacin se concentre en el cdigo propio del

puede ser peor, continuarn desarrollando nuevamente todas las aplicaciones,

Aplicaciones de insercin, modificacin y borrado de

Aplicaciones de consulta a una tabla, con o sin tablas

Aplicaciones para generar reportes sobre una tabla

Mdulo de Control de Acceso: Mdulo consistente en aplicaciones estndares

Mdulo consistente de varios programas que

Aplicaciones Transaccionales: Aplicaciones de procesamiento masivo sobre

independiente de las tablas involucradas. Corresponde

Aplicaciones de lectura y carga tipo batch-input de

Al no contar con una herramienta que automatice el proceso de generacin a

3. ESTADO DEL ARTE

El tema de la construccin de cdigo lleva ms de cinco dcadas, dentro de las

ejecucin y la dificultad para reutilizar partes en otros proyectos, a la vez que no

A principios de los ochenta, la compaa HP implement el re-uso de software

documentacin de las herramientas y procedimientos que se implementaron, lo

se tiene constancia de que se haya llegado a un producto de software concreto.

En cambio, en esta tesis se plantea que es la propia empresa desarrolladora la

desarrollador para que incremente el

implementacin de una prototipo de aplicacin generadora que tome estos

significativo y slo aportando las diferencias particulares de la instancia.

2. Desarrollo Conducido por Modelos (MDD): que promueve la creacin de

lenguajes ms especficos y no generalistas como C Java. Software

cdigo, descripcin, provincia, alcalde, habitantes

Estructura del programa

Pide campos para Ciudad

Permite modificar descripcion

Figura 2: Estructura de programa ejemplo

Fuente (pseudo lenguaje)

Muestra pantalla vaca y pide los campos de la nueva ciudad

Muestra pantalla con todos los campos de la ciudad seleccionada

Para construir un mantenedor de otra tabla, por ejemplo regiones, se tomar

La propuesta aqu es obtener primero una generalizacin del cdigo fuente

Generalizacin del cdigo

Muestra pantalla vaca y pide los campos del nuevo registro

Muestra pantalla con todos los campos del registro seleccionado

Pide campos para

Permite modificar campos no

Figura 3: Estructura de programa generalizado

Este principio es el que convierte un programa ya funcionando y probado en un

El input del generador (en rojo) es bsicamente el programa generalizado

corresponde a cdigo fuente que aporta funcionalidad en otro archivo de entrada

En segundo lugar, el generador tiene como entrada una biblioteca de objetos y

metalenguaje constituyen mensajes para el generador y no se incluyen en el

cdigo de salida, sino que modifican el comportamiento del generador y le dan

3. Registro y Carga de Datos:

4. Reportes (Todos con filtros varios):

Con los programas identificados como posibles modelos, proceder a

4. Este programa ya generalizado, en conjunto con los que anteriormente

De esta forma, se enriquece el generador, con modelos que vienen de

As como algunos equipos de desarrollo realizan esta operacin manualmente,

modelos. A la vez, se incorporarn aspectos de apoyo a la construccin, tales

5. ESPECIFICACIN DE REQUISITOS DEL PROTOTIPO