2. Antecedentes del Tema de Investigación Propuesto

2.1 . ANTECEDENTES DEL PROYECTO
2.1.1. Definición del problema a investigar
El código fuente en funcionamiento en ambientes reales requiere comúnmente la aplicación permanente de efectos secundarios (side effects) y/o la combinación de estos. En el enfoque formal de comprensión de programas en el que estamos interesados [1,2], basado en los formalismos de la programación funcional, inicialmente hemos dejado de lado el tratamiento de los efectos por tratarse de situaciones complejas de resolver. Sin embargo, recientemente [8], hemos incorporado el tratamiento de efectos mediante la utilización de ciertos operadores monádicos [5,6], que actúan como esquemas donde insertar las especificaciones calculadas.
En programación funcional, y en particular en el lenguaje HASKELL, los efectos secundarios son manipulados mediante estructuras algebraicas conocidas como mónadas [12]. Las mónadas permiten de algún modo ocultar la presencia de los efectos secundarios, haciendo que se conserven intáctas propiedades como la transparencia referencial y el razonamiento ecuacional, las cuales son críticas para el cálculo y refactoreo de programas.
Precisamente, es en el contexto del refactoreo de programas y el cálculo inverso, en donde pretendemos tratar casos que involucren combinaciones de efectos secundarios, el análisis de los mismos mediante la manipulación tradicional de estos en HASKELL, es decir, mónadas transformadas, así como también el estudio de los efectos secundarios mediante implementaciones alternativas como las que aplican co-producto [9]. Al mismo tiempo, los esquemas formales que aplicamos como patrones de cálculo, por ahora, están limitados a escasos operadores monádicos. Resta en consecuencia, extender el conjunto de dichos patrones de cálculo no solamente con el tratamiento de combinaciones de mónadas y sus mecanismos alternativos de composición, sino además, con esquemas de otra naturaleza como los propuestos en [10].
Por otro lado, y al inicio del proceso de refactoreo, es necesario la aplicación de transformaciones fuente a fuente del código, hasta que el mismo pueda ser manipulado por alguna propiedad del cálculo. Tales transformaciones, lejos están de ser manejadas por la herramienta de refactoreo HaRe [11] del lenguaje HASKELL. Por lo tanto, también constituye parte de nuestro interés, el análisis y diseño de mecanismos o esquemas de transformación que permitan esta clase de refactoreo.

2.1.2. Estado Actual del problema
En trabajos anteriores [1,2] hemos presentado un cálculo inverso de programas (CIP) -desarrollado por la Universidad Católica de Santiago del Estero en colaboración con la Universidad de Minho (Braga, Portugal)- como un proceso formal de ingeniería reversa, basado en técnicas de slicing. El código fuente original es fragmentado utilizando técnicas de slicing [3], con el propósito de disminuir su complejidad y de esta forma evitar el tratamiento monolítico del mismo. La semántica de cada slice se expresa en lenguajes tales como HASKELL o VDM-SL. Las expresiones obtenidas se someten luego a un proceso de transformación (conocido como refactoring), hasta que las mismas quedan prontas para ser manipuladas por leyes o propiedades asociadas a un cálculo (cálculo point-free [4], por ejemplo). A partir de aquí, comienza el proceso de cálculo propiamente dicho, que consiste en aplicar leyes y propiedades del cálculo, hasta que se alcanza una expresión lo suficientemente abstracta. La fórmula calculada constituye la especificación abstracta del código fuente original.
Los últimos avances de este enfoque han sido presentados en [8] donde las expresiones calculadas desde el código fuente se insertan en esquemas formales abstractos (patrones de cálculo) expresados en la forma de operadores monádicos. Tales esquemas, funcionan como patrones que conducen el proceso de cálculo, por lo que puede decirse, que el proceso de entendimiento de programas que estamos definiendo es dirigido por patrones (pattern-driven).
En primera instancia, se podría argumentar, que procesos de compresión de programas con la sofisticación teórica del presente, podrían ser aplicados a un conjunto muy reducido de aplicaciones, como aquellas que requieren un muy alto nivel de seguridad en su funcionamiento, y/o de las que dependen vidas humanas (aplicaciones críticas). Contrariamente, para el común de las aplicaciones, serían suficientes los enfoques tradicionales de entendimiento de programas, donde las fallas o errores no se “penalizan” con consecuencias catastróficas. Si bien coincidimos en que el estado del arte hace impracticable enfoques como el que proponemos en aplicaciones no críticas, creemos que más investigación (y desarrollo) es necesario para disminuir la distancia entre tales aplicaciones y los enfoques formales como el que proponemos. Sin embargo, el tratamiento de tales aspectos, están fuera del alcance de los objetivos del presente proyecto.

2.1.3. La importancia de resolver el problema planteado
Todos los informes desarrollados sobre la distribución de gastos durante el ciclo de vida del software, coinciden en que las actividades de mantenimiento son las que mayor recursos consumen. Precisamente, la compresión de programas o ingeniería reversa, es la actividad central en el mantenimiento, y de ahí, la importancia y la necesidad creciente de realizar investigación sobre los procesos involucrados en la misma.
Específicamente, el desarrollo de una estrategia formal de comprensión de programas resulta de una importancia decisiva, por cuanto no solo se dispondría de una estrategia para atacar problemas complejos en la fase de mantenimiento, sino además, dicha estrategia tendría una sólida base formal, una cualidad muy poco usual en los procesos de ingeniería de software actuales, y en particular, a los relacionados al mantenimiento.

2.1.4. Trabajo adelantado por los solicitantes
En [8] hemos tratado superficialmente los efectos secundarios en el contexto del CIP, utilizando operadores monádicos como esquemas o patrones en donde insertar las especificaciones calculadas. Por otro lado, hemos realizado algunas experimentaciones con combinaciones de mónadas aplicando el mecanismo tradicional de mónadas transformadas [13]. No obstante, los resultados de que disponemos son provisorios y más experimentación es necesaria para cubrir la mayor cantidad de combinaciones de mónadas posibles, especialmente de aquellas cuya aplicación es frecuente.