Graphical User Interfaces Reverse Engineering for Requirements

Graphical User Interfaces Reverse Engineering for Requirements

(2016). RACCIS 6(1), pp. 39-45.
Revista Antioqueña de las
Ciencias Computacionales y la Ingeniería de Software
ISSN: 2248-7441
www.fundacioniai.org/raccis
raccis(AT)fundacioniai.org
Graphical User Interfaces Reverse Engineering for Requirements Elicitation - Literature
Review
Ingeniería Inversa de Interfaces Gráficas de Usuario para la captura de Requisitos de Software
- Revisión de la Literatura
Carol Jaimes, Fernando Rojas
Universidad Industrial de Santander. Bucaramanga, Colombia. carol.jaimes(AT)correo.uis.edu.co; frojas(AT)uis.edu.co
INFORMACIÓN DEL ARTÍCULO
Artículo de Revisión
Recibido: 02-03-2016
Correcciones: 06-18-2016
Aceptado: 20-06-2016
Keywords
Requirements elicitation; graphical
user interface; reverse engineering;
Requirements Engineering; Software
Engineering.
Palabras clave
Captura de requisitos; ingeniería
inversa; interfaz gráfica de usuario;
Ingeniería de Requisitos; Ingeniería
del Software.
ABSTRACT
This paper exhibits a synthesis of the use of legacy systems GUI reverse engineering as a tool to
software requirements elicitation. It presents a literature review describing the approaches
related to the topic. This work primary goal is to determine the major investigations in this area,
and if there are techniques focused exclusively on the observation of the legacy applications GUI
to obtain software requirements in a standard format, without the use of source code, data
structures, documentation or sophisticated algorithms for the application analysis.
RESUMEN
Este artículo muestra una síntesis sobre el uso de la ingeniería inversa en aplicaciones
heredadas como herramienta para la obtención de requisitos de software; presenta un
análisis de la literatura describiendo los enfoques más utilizados en este campo. El objetivo
principal de este trabajo es determinar cuáles son las principales investigaciones que se han
llevado a cabo en esta área, además, averiguar si existen técnicas que se enfoquen
exclusivamente en la observación e interacción con la GUI de aplicaciones heredadas para la
obtención de requisitos de software en un formato estándar, sin tener que recurrir al código
fuente, estructuras de datos, documentación o algoritmos complejos para el análisis de
aplicaciones.
1. Introducción
Uno de los pilares de la Ingeniería del Software moderna
es la reutilización, lo que quiere decir que cualquier
sistema software tiene que usar los recursos existentes de
la manera más efectiva que le sea posible [1]. Este principio
fundamental ha movido el desarrollo de técnicas,
tecnologías y metodologías que permiten usar elementos
preconcebidos y pre-construidos en el desarrollo de
múltiples sistemas software.
Es por esto que actualmente la comprensión de los
sistemas ya construidos, y su pleno entendimiento, son
procesos de alta complejidad y de reconocida importancia
para apoyar la reutilización y el mantenimiento del
software, apoyados en técnicas como la ingeniería inversa
y la reingeniería [1, 2]. Sin embargo, la reutilización de
componentes de software ejecutables es un proceso
costoso, porque se construyen de manera específica para
una situación. Una forma alternativa de reutilización que
disminuye estos costos, es la reutilización del concepto,
que busca reutilizar una idea y que se representa de
manera abstracta para crear componentes ejecutables de
reutilización [2].
El interés de la investigación en esta área y la identificación
de las alternativas para encontrar elementos software que
se puedan reutilizar conceptualmente para nuevos
© 2016 IAI. All rights reserved.
proyectos, es la principal motivación de esta revisión de la
literatura. El aspecto principal en el que se enfoca la
investigación es la búsqueda de técnicas que apliquen la
ingeniería inversa a interfaces gráficas de usuario, con el
fin de capturar requisitos de software. Lo cual está
relacionado fuertemente a la comprensión de las
aplicaciones, recuperación y reutilización del concepto.
Este documento abarca alrededor de veinte años de
trabajos de investigación en este tema. Con el fin de
determinar los principales enfoques relacionados, así
como el cambio que ha tenido el uso de la ingeniería
inversa de interfaces gráficas de usuario a través de este
periodo de tiempo, se presenta una síntesis organizada
cronológicamente de los estudios hallados y su relevancia
y cercanía con la temática de interés para la investigación.
A continuación, se presentan los resultados obtenidos en
la revisión, organizados en etapas de tiempo que dejan
entrever las tendencias y enfoques en cada uno. La primera
sección comprende la década de 1990, la segunda en la del
2000 y la tercera cubre el intervalo de tiempo entre 2010
y 2015.
2. Metodología
La metodología usada para estructurar la revisión se
propuso específicamente para esta investigación. Se basa
inicialmente en las tres primeras etapas de Methontology
39
[3], que determinan el alcance y dan estructura a la
revisión, de manera similar a como se inicia y determina el
alcance de una ontología. En este caso, las etapas permiten
delimitar la revisión, realizar las preguntas de
competencia y formular la lista de términos. Esta lista es de
carácter iterativo y va acompañada de la continua
búsqueda de la literatura (Ver Figura 1). Después de estas
tres etapas se procede al registro escrito, las correcciones
y la divulgación.
Figura 1. Diagrama Metodológico Revisión de la Literatura
2.1 Revisión de la literatura
La etapa preliminar al desarrollo de la metodología
consiste de una búsqueda exhaustiva en la literatura sobre
las técnicas existentes para la recolección de requisitos de
software, mediante la ingeniería inversa de interfaces
gráficas de usuario. En las primeras búsquedas en las bases
de datos IEEE y ACM se involucraron todos los términos de
la temática, pero no arrojaron resultados significativos.
Esto sirvió inicialmente para corroborar la hipótesis de
que es un área poco explorada y sustenta la idea de realizar
un trabajo de investigación de esta índole.
A continuación, se procedió a segmentar la búsqueda en las
áreas principales que conforman la temática general, tal
como se observa en la Figura 2.
Figura 2. Segmentación de la temática
Las búsquedas realizadas utilizando los términos de estas
áreas permitieron recolectar artículos relacionados desde
1990 hasta la actualidad. Entonces se decide involucrar
este amplio rango de tiempo en el análisis de la
documentación, porque los temas de la subdivisión a la
temática se extienden a lo largo de esos veinticinco años.
Además, se detectó una aparición esporádica de las
temáticas de interés en espacios de tiempo más distantes.
2.2 Etapas de Methontology
Las etapas adaptadas de Methontology para estructurar
esta investigación son las presentes en la concepción de la
ontología: 1) determinar el dominio y alcance de la
ontología, 2) realizar las preguntas de competencia, y 3)
enumerar los términos importantes para la revisión.
En la primera parte se deben resolver cuatro interrogantes
que ayudan a determinar el alcance en este caso de la
revisión sistemática de la literatura, los cuales se observan
en la Tabla 1. La segunda etapa consiste en bosquejar una
lista de preguntas que la revisión debe ayudar a responder
y que se describen en la Tabla 2.
Tabla 1. Interrogantes para determinar el alcance de la revisión
¿Cuál es el dominio que la cubrirá ontología?
El dominio definido para esta ontología es la adquisición de requisitos
de software haciendo ingeniería inversa a las interfaces gráficas de
usuario de aplicaciones heredadas.
¿Para qué se usará la ontología?
La presente ontología tiene diversos propósitos, pero el más
importante es determinar el estado del arte del dominio establecido
para demostrar la existencia de un nicho investigativo. Generando una
base de conocimiento en este dominio que pueda ser asequible a otros
investigadores interesados en el área.
¿Para qué tipos de preguntas deberá proveer respuestas la información
en la ontología?
 ¿Qué métodos o técnicas existen?
 ¿Cuáles herramientas existen?
 ¿Cuáles son los estudios más sobresalientes?
 ¿Cuándo se desarrollaron?
 ¿En qué consisten?
 ¿Cómo usan la ingeniería inversa?
 ¿Qué obtienen como resultado?
¿Quién usará y mantendrá la ontología?
Inicialmente es para determinar un nicho investigativo para un
próximo trabajo de los autores, sin embargo, queda como un producto
disponible para todos los investigadores interesados en el área.
Tabla 2. Preguntas que la revisión debe ayudar a responder
¿Qué es ingeniería inversa?
¿Qué es adquisición de requerimientos?
¿A qué tipo de software se pueden aplicar las técnicas encontradas?
¿Alguna técnica utiliza un análisis que involucre únicamente la parte
visible de la GUI y de la forma en que esta interactúa con el usuario?
¿Cuándo se mencionó por primera vez la posibilidad de utilizar la
ingeniería inversa de GUI para capturar requisitos de software?
¿Cuáles técnicas se puede reconocer, que utilicen el análisis de
aplicaciones heredadas para recuperar requisitos o consideraciones
de diseño?
La tercera etapa es enumerar los términos importantes en
la ontología, y se enfoca en encontrar los términos sobre
los cuales se quiere hablar en la revisión, lo mismo que sus
propiedades. En la Tabla 3 se muestra un extracto de esta
lista de términos, clasificado cronológicamente y por
documento consultado.
Nombre Documento
Reverse Engineering and
Design: A Taxonomy
Chikofsky, Elliot
Cross, James
Año
1990
Términos en inglés
Forward Engineering
Reverse Engineering of user
interfaces
Merlo, E
1993
Reverse engineering
Design Recovery
Restructuring
Reengineering
Redocumentation
Specification language
Method
Girard, J F
Kontogiannisl, I
Panangaden, P
Mori, R De
Structural
Representation
Behavioural
Representation
Lifespan
Reengineering UI
AUIDL*
User Actions
System Responses
Mapping out the
behaviour
Process-Algebraic
Class Hierarchy based on
Motif
List of Equations
40
2.3 Registro de la información
Finalmente, y usando como guía el producto anterior, se
procede al registro cronológico y descriptivo de los
hallazgos más significativos relacionados con el uso de la
ingeniería inversa, en aplicaciones heredadas como
herramienta para la obtención de requisitos de software.
3. Resultados
3.1 Primera Etapa: años 90
En los primeros años de esta década, Chicofsky y Cross [4]
dedicaron su publicación a establecer claramente los
principios taxonómicos de la ingeniería inversa. Para esa
época no se podía aplicar exitosamente debido a la
confusión que existía acerca de la terminología usada en
campos técnicos y comerciales. En su documento precisan
cinco términos involucrados en la comprensión y
entendimiento de la ingeniería inversa: ingeniería directa,
re-documentación, reestructuración, reingeniería y
recuperación del diseño. Definen a la ingeniería inversa el
proceso de analizar un sistema con el fin de identificar sus
componentes y las interrelaciones entre ellos, y de crear
una representación del sistema en otra forma o en un nivel
más alto de abstracción [4]. Debido a esto, su trabajo se
convirtió en la base para la mayoría de estudios citados en
el presente análisis. Además, como el punto de partida para
los estudios referentes a la ingeniería inversa o a la
comprensión y entendimiento de un sistema heredado.
En años posteriores a esta publicación se encuentran
interesantes enfoques relacionados con la ingeniería
inversa de aplicaciones. Durante ese periodo se presenta
una transición de aplicaciones con interfaces de usuario,
orientadas a caracteres, hacia aplicaciones con interfaces
gráficas de usuario. Los investigadores se centran en la
búsqueda de alternativas que permitan modernizar los
grandes sistemas heredados, para alargar el tiempo del
sistema y mejorar la experiencia del usuario. Aunque se
visualiza el potencial de analizar interfaces gráficas de
usuario para generar especificaciones, es evidente que
para entonces no se consideraba viable aplicar ingeniería
inversa a una interfaz gráfica de usuario. Sin embargo, cabe
resaltar que ya se considera seriamente el análisis de
interfaces para que la transición fuera más fácil de abordar,
así como para el mantenimiento de las aplicaciones en uso.
Entre los primeros enfoques de la década de los noventa se
presenta un método para aplicar ingeniería inversa a las
interfaces de usuario, donde se obtiene una representación
de la interfaz, estructural y comportamental, con el fin de
aplicarle reingeniería y prolongar el tiempo de vida del
sistema [5, 6]. La idea era describir los aspectos dinámicos
de la interfaz mediante una representación del
comportamiento de la misma (interacción entre sus
componentes), a través de un proceso algebraico. Todo se
automatizaba mediante la implementación del lenguaje
AUIDL (Abstract User Description Language). Este enfoque
concluye que, a partir del análisis de interfaces de usuario
heredadas y orientadas a caracteres, es posible generar
especificaciones para interfaces gráficas de usuario
simples, y que trabajos futuros pueden lograr aplicar este
método a interfaces gráficas de usuario. Posteriormente,
creció el interés por reversar las antiguas interfaces de
usuario, con el fin de migrar o realizar mantenimiento de
aplicaciones de una manera más sencilla. En [7] se aborda
la idea de construir un modelo de la funcionalidad de la
interfaz, a partir del análisis estático y dinámico del código
fuente, y de desarrollar una técnica que permita
automatizar este proceso.
Durante esta época también tienen protagonismo los
enfoques centrados en el análisis de los datos para
recuperar distintos elementos de diseño, tales como el
modelo relacional [8]; también para transformar el modelo
relacional en un esquema relacional binario [9] e incluso
para obtener requisitos para construir herramientas CASE,
que permitan realizar la ingeniería inversa de aplicaciones
centradas en los datos [10]. Otros enfoques proponen
recuperar especificaciones a través del uso de técnicas de
aprendizaje automatizado sobre las bases de datos que
hacen parte de grandes sistemas heredados [11].
Apoyando estas iniciativas se desarrollaron trabajos
relacionados con la implementación de aplicaciones que
automatizan el proceso de ingeniería inversa de bases de
datos, basados en la premisa de que hacer ingeniería
inversa de la parte procedimental es más simple cuando ya
se tienen los datos [12].
Para finales de la década, se proponen técnicas para la
recuperación de elementos de diseño desde el análisis de
sistemas heredados. Optando por el rescate de
información, junto con técnicas de minería del
conocimiento, como opción para aplicar ingeniería inversa
a sistemas heredados. La diferencia fundamental es la
visión basada en repositorios, que le permite al
programador entender el modelo que está recuperando y
encontrar una descripción de cómo han sido creados estos
modelos [13]. Otros enfoques basados en el conocimiento
detallado de la aplicación heredada, buscan facilitar la
tarea de mantenimiento de estos sistemas. Ese
conocimiento se extrae del código fuente y se relaciona con
el vocabulario corporativo, los programas y los elementos
de datos relevantes [14].
Otra temática importante es la transformación de las
antiguas aplicaciones procedimentales a sistemas
diseñados y construidos bajo el paradigma de los objetos,
lo que se manifiesta con la existencia de trabajos de
ingeniería inversa preocupados por identificar modelos
(objetos y relaciones entre objetos) y de reconocer los
objetos ocultos en las aplicaciones heredadas de carácter
procedimental [15, 66].
Sin embargo, para este tiempo ya se empiezan a buscar
soluciones de ingeniería inversa para aplicaciones
construidas bajo el paradigma de los objetos. También se
encuentran enfoques dedicados a la recuperación de la
documentación arquitectónica a partir del código fuente.
Para lograrlo se aplica análisis estático y dinámico del
código [17]. Gracias al avance en el análisis dinámico, el
trabajo dirigido a la recuperación de requisitos de sistemas
heredados se direcciona al análisis y el modelando del
comportamiento. Así mismo se fundamenta en la captura
del comportamiento, el modelado del comportamiento
dinámico, el mapeo de la interfaz y el modelamiento de la
tarea del dominio [18, 19].
En esta primera etapa, el poco desarrollo de las interfaces
gráficas no permite encontrar enfoques que se centren
41
únicamente en el uso de la interfaz gráfica de usuario para
realizar un análisis de aplicaciones heredadas, porque la
orientación de las técnicas es hacia el análisis del código
fuente y los datos. Estos enfoques no buscan encontrar
requisitos de los sistemas analizados, sino que pretenden
determinar modelos del comportamiento de la interfaz,
especificaciones de la interfaz y modelos de datos para
inferir cierto conocimiento del dominio de la aplicación.
Además, el uso de estas técnicas siempre requiere el acceso
al código fuente o a los datos de la aplicación.
3.2 Segunda Etapa: 2000 – 2009
En este segundo periodo se presentan cambios
importantes en las aplicaciones: el uso de la ingeniería
inversa se diversifica hacia el análisis de aplicaciones que
han sido concebidas únicamente para la web y requieren
de nuevos métodos de ingeniería inversa; el uso del
análisis dinámico tiene un fuerte auge; las técnicas buscan
automatizar al máximo las tareas requeridas por la
ingeniería inversa; y debido a la popularización de las
aplicaciones construidas con una interfaz gráfica de
usuario, se encuentran más trabajos encaminados a
extraer información a partir del comportamiento y
propiedades de la interfaz.
Los primeros enfoques se basan en el uso de herramientas
software que realizan el trabajo de analizar el sistema
heredado de manera automatizada, que realizan el mapeo
de la interfaz basándose en el registro de las trazas de la
interacción del usuario con el sistema [20] y evolucionan
hacia un análisis más complejo, que busca entender el
comportamiento de sistema heredado y sus procesos y
usos [21]. De esta manera se tiene como propósito
recuperar las aplicaciones que los usuarios hacen del
sistema, no se intenta recuperar los requisitos
considerados en la etapa de diseño del sistema heredado y
se resalta la dificultad de entender el código de
aplicaciones heredadas. Es por esto que el proceso se basa
en descubrir y modelar las tareas que logran
frecuentemente los usuarios que usan el sistema [22].
Aunque algunos enfoques tratan específicamente de
encontrar requisitos, en general buscan obtener modelos
que representen distintos aspectos de la aplicación, con el
fin de utilizarlos para pruebas automáticas, conocer la
intención del sistema, realizar mantenimiento, migrar a
otras tecnologías o recuperar el diseño de la misma. Los
modelos recuperados muestran a través de arreglos la
estructura que forman las ventanas de la aplicación y la
relación jerárquica que hay entre ellas; la refactorización
del código heredado se utiliza para extraer modelos de las
metas del software; y el registro de las características
interactivas y gráficas de la aplicación permite identificar
acciones claves desarrolladas por los usuarios [23-25].
Hacia la segunda mitad de la década, las direcciones que
toman los enfoques se diversifican ampliamente y algunos
trabajos reconsideran la importancia y fortaleza del
análisis del código fuente para obtener modelos. Los
métodos propuestos tratan de adaptarse a las nuevas
tecnologías, migrando las viejas interfaces orientadas a
caracteres con el fin de extender el uso de los sistemas
heredados hacia la web [26]. Sin embargo, ya existen
aplicaciones heredadas desarrolladas con tecnologías
orientadas completamente hacia los ambientes web. Este
tipo de aplicaciones requiere nuevas técnicas a la hora de
ser usadas en procesos de ingeniería inversa. Algunas
obtienen modelos de presentación de una página web,
analizando el código HTML, y explotan el conocimiento del
negocio embebido en las interfaces de aplicaciones web
dedicadas al comercio electrónico [27, 28]. A su vez, se
trabaja en la recuperación del comportamiento del lado del
cliente de Rich Internet Applications RIAs, usando análisis
dinámico para obtener una Finite State Machine FSM que
represente el modelo de comportamiento de la GUI. La idea
es aprovechar al máximo las interfaces de usuario
enriquecidas de estos sistemas, que se construyen con
base en la interacción de los usuarios con la aplicación [2931].
Hay que mencionar que los enfoques de ingeniería inversa
no se orientan únicamente hacia el tipo de aplicación como
tal (en este caso web), sino que también se preocupan por
extraer mayor información, teniendo en cuenta la
tecnología con la cual está construida la aplicación
heredada. En este caso las técnicas, dependientes o
independientes del código fuente, se centran en analizar
aplicaciones construidas bajo determinados paradigmas y
lenguajes de programación. Entre ellas se encuentra el
análisis de código de aplicaciones web desarrolladas en
ASP.NET, C y C++. El enfoque que usa ASP.NET busca
extraer un modelo conceptual de la aplicación, realizando
el análisis estático del código contenido de los archivos
.aspx y .cs, que contienen la lógica del sistema. Con el
análisis de C y C++ se extraen las ventanas del programa,
su estructura, atributos, los valores de estos atributos, los
eventos y los manejadores de eventos asociados [32-33].
Lenguajes como Java, y su paquete gráfico Java-Swing, se
estudian desde una orientación independiente del código
fuente, para recuperar características comportamentales y
estructurales con el fin de portar fácilmente las
aplicaciones de escritorio a web [34, 35].
A partir de tecnologías como la Programación Orientada
por Objetos, pero alejados de la interfaz gráfica, con el UML
y la descripción de documentos mediante los esquemas
XML, también se obtienen ventajas a la hora de la
ingeniería inversa. UML, por ejemplo, es un lenguaje que
permite representar múltiples aspectos de un sistema en
un nivel más alto de abstracción, soportando modelos
estructurales (análisis estático) y comportamentales
(análisis dinámico). Desde esta perspectiva se propone
recuperar diagramas de clases y reconstruir diagramas de
secuencia [36, 37]. En cuanto a XML, la descripción de la
estructura y las restricciones de los contenidos entregan
un estándar para la presentación de datos, a partir de los
cuales se busca recuperar diagramas conceptuales [38].
En esta segunda etapa, la diversificación de la tecnología y
el amplio desarrollo de aplicaciones web muestran que es
posible aplicar análisis inverso de diversas formas. En los
primeros enfoques encontrados el interés de conocer el
uso del sistema heredado se hizo evidente, sin embargo, a
medida que se avanza en este periodo la diversificación en
sí termina por llevar el interés hacia la tecnología en la que
están construidas las aplicaciones, y no hacia el principio
de reutilización del concepto, el conocimiento del dominio
o los requisitos.
42
3.3 Tercera Etapa: 2010 – 2015
El avance tecnológico de las dos últimas décadas también
influenció el desarrollo de técnicas para el análisis de
interfaces gráficas de usuario; los enfoques de ingeniería
inversa se han diversificado ampliamente y se presentan
novedosos estudios que abordan el problema de ingeniería
inversa de interfaces gráficas de usuario desde sus
elementos estructurales más simples: los pixeles [39, 40].
Enfoques más complejos proponen no sólo usar una simple
imagen de la interfaz, sino que dan un paso adelante y se
basan en el análisis de un video de la interfaz gráfica,
usando la diferenciación de fotogramas de video para
identificar las ocurrencias de los comportamientos o
movimientos de los componentes de la interfaz [41].
Durante este periodo, para los enfoques de ingeniería
inversa de GUIs el tipo de modelos obtenidos cambia
debido a múltiples razones: la tecnología de la aplicación
sobre la cual se aplica la ingeniería inversa, el tipo de
modelo que se desea obtener y las técnicas que se usan
para abordar el problema. Por esto se encuentra un amplio
espectro de técnicas con diversos fines. Algunos de los
modelos encontrados son de tipo estructural, tanto de la
aplicación (diagramas de clase) como de la GUI (máquinas
de estado finitas); también se encuentran modelos de
estado o comportamiento de la GUI y modelos con
información descriptiva de los datos manejados por los
controles de la GUI [42-45].
Sin embargo, es notoria la importancia dada a los modelos
para la realización de pruebas, en especial de GUI, que se
consideran como un proceso complejo y en algunos casos
poco eficiente. Por lo tanto, los investigadores se centran
en el uso de la ingeniería inversa de la GUI con el fin de
encontrar modelos que hagan viable automatizar la
generación de casos de prueba. En distintas técnicas se
resalta la presencia de enfoques, dinámicos y estáticos, de
la ingeniería inversa, así como el uso de inteligencia
artificial [46] y la identificación de patrones de interfaz de
usuario [47].
Los avances en la ingeniería inversa de GUI también se
extienden hacia las aplicaciones heredadas, que en años
anteriores fueron revolucionarias, como las creadas
usando ambientes RAD, lenguajes de cuarta generación y
sistemas de información web, y hacia la automatización de
modelos de pruebas de aplicaciones móviles [48, 49]. Más
recientemente el interés de la ingeniería inversa de
interfaces gráficas de usuario se centra en el objetivo de la
migración de aplicaciones hacia y entre plataformas
móviles, debido a que el acceso a los sistemas web se
realiza en gran medida a través de este tipo de dispositivos.
Los investigadores proponen enfoques basados tanto en
análisis dinámico como en análisis estático del código
fuente. En [50] se propone un enfoque orientado a
examinar una representación de la interfaz en tiempo de
ejecución, usando Aspect Oriented Programming AOP, que
obtiene un modelo genérico e independiente del lenguaje.
También se encuentran enfoques basados en el análisis
estático del código fuente, sin embargo, no se limitan al
código de la interfaz en estudio, sino que integran la
información obtenida a un repositorio existente, que
contiene toda la información de los diferentes artefactos
reversados (código fuente, bases de datos, interfaces de
usuario etc.), y después transforma el modelo de la
interfaz, representado en el repositorio, en un modelo de
interfaz para Android [51].
En esta última etapa se presentan avances en el análisis de
la interfaz gráfica, que son independientes del código
fuente y que se preocupan por recuperar información
estructural de la aplicación. A su vez, crece el interés por
recuperar modelos para generar pruebas automáticas, la
necesidad de migrar aplicaciones hacia nuevas tecnologías
móviles y sigue vigente el análisis estático y dinámico del
código fuente. Cabe resaltar que las capacidades
tecnológicas, aumentadas por el desarrollo de hardware,
permiten mayor automatización, sin embargo, la presencia
de recuperación conceptual se disuelve en la cantidad de
información encontrada y que termina siendo útil
únicamente para ser interpretada de forma automatizada.
4. Conclusiones
Debido a la baja incidencia de enfoques que se centren en
realizar ingeniería inversa de GUIs para recuperar
requisitos de software, los autores deciden presentar una
síntesis sobre cuáles son los resultados que se obtienen en
la variedad de técnicas desarrolladas y las tendencias que
generan más interés en la ingeniería inversa de GUIs. En
general, y de acuerdo a lo encontrado en la revisión de la
literatura, se nota que el interés de reversar GUIs se
concentra en la obtención de modelos que permitan la
realización de migración y pruebas. A su vez, las técnicas
evolucionan junto con la tecnología y la naturaleza de las
aplicaciones que se proponen reversar.
Inicialmente, el código fuente de las interfaces era la fuente
más común para la aplicación de estas técnicas, pero
actualmente la tecnología permite separar completamente
el concepto de ingeniería inversa del código fuente y de los
datos. Los enfoques propuestos, sin embargo, no invierten
mucho esfuerzo en abordar la recuperación de conceptos,
y la excesiva automatización convierte la ingeniería
inversa más en un proceso de algoritmos y máquinas que
en uno de comprensión más clara de un software existente
o de un dominio determinado por los desarrolladores.
Porque la mayoría de los modelos obtenidos son de difícil
comprensión y, para lograr dar un uso adecuado, se
necesitan especialistas para interpretar la información
generada por dichas herramientas.
En cuanto al interés de aplicar ingeniería inversa a las
interfaces gráficas de usuario para encontrar requisitos de
software, se encuentra la iniciativa presentada en [52], que
pretende insertar la ingeniería inversa de aplicaciones
heredadas en el ciclo de vida del software, integrando los
requisitos clásicos con requisitos obtenidos por ingeniería
inversa. También presenta la posibilidad de obtener
requisitos a partir de los modelos gráficos proporcionados
por procesos de ingeniería inversa. Sin embargo, y de
acuerdo al análisis hecho en la presente revisión, esta
iniciativa no tuvo incidencia en trabajos posteriores, pero
es un amplio campo investigativo disponible para nuevas
ideas y enfoques del uso de la ingeniería inversa de GUIs.
Por otro lado, una de las tareas esenciales en la Ingeniería
de Requisitos es el conocimiento del dominio de la
aplicación, por lo que para los proyectos de ingeniería
directa existen técnicas, métodos y herramientas
43
ampliamente conocidas. Sin embargo, para el caso de los
proyectos de reingeniería de aplicaciones, los métodos
encontrados en esta investigación se centran en el
conocimiento del dominio a partir de esquemas de bases
de datos, dejando un vacío en cuanto a las características
del software. Esto motivó la búsqueda de técnicas de
ingeniería inversa para la obtención de requisitos a partir
de interfaces de usuario, porque son elementos de trabajo
más cercanos a los desarrolladores. Los hallazgos
permiten vislumbrar una oportunidad para convertir una
práctica de facto en el desarrollo de software, el análisis de
aplicaciones heredadas, en una técnica que permita
derivar conocimiento del dominio de la aplicación desde
las interfaces de software heredado. De esta manera se,
disminuye la curva de aprendizaje que se requiere del
dominio de aplicación por parte de los desarrolladores,
potenciando la eficiencia de la Ingeniería de Requisitos,
antes de realizar las entrevistas con clientes y usuarios
finales de la aplicación, además, se optimiza la práctica de
reutilización en el proceso de elicitación de requisitos.
Referencias
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
Sommerville, I. (2011). Ingeniería del Software. México:
Pearson Education.
Bourque, P. & Dupuis, R. (2004). Guide to the Software
Engineering Body of Knowledge SWEBOK. Online [May
2015].
Corcho, O., Fernández, M. & Gómez, A. (2005). Building
Legal Ontologies with Methontology and WebODE. Lecture
Notes in Computer Science 3369, pp. 142-157.
Chikofsky, E. & Cross, J. (1990). Reverse Engineering and
Design: A Taxonomy. IEEE Software 7(1 ), pp. 13–17.
Merlo, E. et al. (1993). Reverse engineering of user
interfaces. Proceedings IEEE Working Conference on
Reverse Engineering (pp. 171–179). Baltimore, USA.
Merlo, E. (1995). Reengineering User Interfaces. IEEE
Software 12(1), pp. 64–73.
Moore, M. (1996). Rule - Based Detection for Reverse
Engineering User Interfaces. Proceedings Third Working
Conference on Reverse Engineering (pp. 42-48). Monterey,
USA.
Chiang, R., Barron, T. & Storey, V. (1994). Reverse
engineering of relational databases: Extraction of an EER
model from a relational database. Data & Knowledge
Enginnering 12(2), pp. 107–142.
Shoval, P. & Shreiber, N. (1993). Database reverse
engineering: From the relational to the binary relationship
model. Data & Knowledge Enginnering 10(3), pp. 293–315.
Hainaut, J. et al. (1996). Database reverse engineering:
From requirements to CARE tools. Automated Software
Enginnering 3(1), pp. 9–45.
Cohen, W. (1994). Recovering software specifications with
inductive logic programming. Proceedings Twelfth National
Conference on Artificial Intelligence (pp. 142-148). Seattle,
USA.
Hainaut, J. & Englebert, V. (1995). Requirements for
information system reverse engineering support.
Proceedings 2nd Working Conference on Reverse
Engineering (pp. 136–145). Toronto, Canada.
Dayani, H. & Jurisica, I. (1998). Reverse engineering by
mining dynamic repositories. Proceedings 5th Working
Conference on Reverse Engineering (pp. 174–182).
Honolulu, USA.
Lee, B., Lee, J. & Kim, W. (1997). A knowledge-based
maintenance of legacy systems: METASOFT. Expert
Systems with Applications Expert 12(4), pp. 483–496.
[15] Babiker, E. et al. (1997). A model for reengineering legacy
expert systems to object-oriented architecture. Expert
Systems with Applications 12(3), pp. 363–371.
[16] Cimitile, A. et al. (1999). Identifying objects in legacy
systems using design metrics. Journal of Systems and
Software 44(3), pp. 199–211.
[17] Richner, T. & Ducasse, S. (1999). Recovering high-level
views of object-oriented applications from static and
dynamic information. Proceedings IEEE International
Conference on Software Maintenance (pp. 13-22). Oxford,
UK.
[18] Liu, K. et al. (1999). Requirements Recovery from Legacy
Systems by Analysing and Modelling Behaviour
Environment Observation of Human - Machine Interactions.
Proceedings IEEE International Conference on Software
Maintenance (pp. 3-12). Oxford, UK.
[19] Stroulia, E. et al. (1999). Reverse Engineering Legacy
Interfaces : an Interaction-Driven Approach. Proceedings.
Sixth Working Conference on Reverse Engineering (pp.
292-302). Atlanta, USA.
[20] El-Ramly, M. et al. (2001). Modeling the system-user dialog
using interaction traces. Proceedings Eighth Working
Conference on Reverse Engineering (pp. 208–217).
Stuttgart, Germany.
[21] Stroulia, E. & Systä, T. (2002). Dynamic analysis for reverse
engineering and program understanding. ACM SIGAPP
Applied Computing Review 10(1), pp. 8–17.
[22] El-ramly, M. et al. (2002). Recovering Software
Requirements from System-user Interaction Traces.
Proceedings 14th international conference on Software
Engineering and Knowledge Engineering (pp. 447–454).
Ischia Island, Italy.
[23] Memon, A., Banerjee, I. & Nagarajan, A. (2003). GUI ripping:
Reverse engineering of graphical user interfaces for testing.
Proceedings 10th Working Conference on Reverse
Engineering (pp. 260–269). Victoria, Canada.
[24] Yu, Y., Wang, Y. & Mylopoulos, J. (2005). Reverse
engineering goal models from legacy code. Proceedings
13th International Conference on Requirements
Engineering (pp. 363–372). La Sorbonne, France.
[25] Chan K, Michail a. (2003) Design recovery of interactive
graphical applications. ICSE '03 Proceedings of the 25th
International Conf. on Software Engineering, pp. 114–124.
[26] Moore, M. & Moshkina, L. (2000). Migrating legacy user
interfaces to the internet: Shifting dialogue initiative.
Proceedings seventh Working Conference on Reverse
Engineering (pp. 52–58). Brisbane, Australia.
[27] Vanderdonckt, J., Bouillon, L. & Souchon, N (2001). Flexible
reverse engineering of web pages with VAQUISTA.
Proceedings eighth Working Conference on Reverse
Engineering (pp. 241–248). Stuttgart, Germany.
[28] Zhang, Q., Chen, R. & Zou, Y. (2006). Reengineering User
Interfaces of E-Commerce Applications Using Business
Processes. Proceedings 22nd International Conference on
Software Maintenance (pp. 428–437). Philadelphia, USA.
[29] Amalfitano, D., Fasolino, A. & Tramontana, P. (2008).
Reverse Engineering Finite State Machines from Rich
Internet Applications. Proceedings 15th Working
Conference on Reverse Engineering (pp. 69–73). Antwerp,
Belgium.
[30] Amalfitano, D. (2009). Experimenting a reverse engineering
technique for modelling the behaviour of rich internet
applications. Proceedings 2009 International Conference
on Software Maintenance (pp. 571–574). Edmonton, USA.
[31] Amalfitano, D., Fasolino, A. & Tramontana, P. (2010). An
iterative approach for the reverse engineering of rich
internet application user interfaces. Proceedings Fifth
International Conference on Internet and Web Applications
and Services (pp. 401–410). Barcelona, Spain.
44
[32] Katsimpa, T. et al. (2006). Application modeling using
reverse engineering techniques. Proceedings 2006 ACM
symposium on Applied computing (pp. 1250-1255). Dijon,
France.
[33] Staiger, S. (2007). Reverse Engineering of Graphical User
Interfaces Using Static Analyses. Proceedings 14th Working
Conference on Reverse Engineering (pp. 189–198).
Vancouver, Canada.
[34] Samir, H. & Kamel, A. (2007). Automated reverse
engineering of Java graphical user interfaces for web
migration. Proceedings 5th International Conference on
Information and Communications Technology (pp. 157–
162). El Cairo, Egypt.
[35] Samir, H., Stroulia, E. & Kamel, A. (2007). Swing2Script:
Migration of Java-Swing Applications to Ajax Web
Applications. Proceedings 14th Working Conference on
Reverse Engineering (pp. 179–188). Vancouver, Canada.
[36] Jain, A. & Tayal, D. (2008). On reverse engineering an objectoriented code into UML class diagrams incorporating
extensible mechanisms. ACM SIGSOFT Software
Enginnering Notes 33(5), Article 9.
[37] Merdes, M., Heidelberg, D. & Dorsch, D. (2006). Experiences
with the Development of a Reverse Engineering Tool for
UML Sequence Diagrams : A Case Study in Modern Java
Development. Proceedings 4th international symposium on
Principles and practice of programming in Java (pp. 125–
134). Mannheim, Germany.
[38] Necasky, M. (2009). Reverse Engineering of XML Schemas
to Conceptual Diagrams. Proceedings Sixth Asia-Pacific
Conference on Conceptual Modeling (pp. 117-128).
Wellington, New Zealand.
[39] Dixon, M. & Fogarty, J. (2010). Prefab: implementing
advanced behaviors using pixel-based reverse engineering
of interface structure. Proceedings 28th international
conference on Human factors in computing systems (pp.
1525-1534). Atlanta, USA.
[40] Dixon, M. (2013). Pixel-based reverse engineering of
graphical interfaces. Proceedings 26th annual ACM
symposium on User interface software and technology (pp.
29–32). St Andrews, UK.
[41] Banovic, N. et al. (2012). Waken: Reverse engineering usage
information and interface structure from software videos.
Proceedings 25th Annual ACM Symposium on User
Interface Software and Technology (pp. 83–92). Cambridge,
USA.
[42] Muhairat, M., Al-Qutaish, R. & Athamena, B. (2011). From
graphical user interface to domain class diagram: A reverse
engineering approach. Journal of Theoretical & Applied
Information Technology 24(1), pp. 28–40.
[43] Marchetto, A., Tonella, P. & Ricca, F. (2012). ReAjax: A
reverse engineering tool for Ajax Web applications. IET
Software 6(1), pp. 33-49.
[44] Becce, G. et al. (2012). Extracting Widget Descriptions from
GUIs. Lectures Notes in Computers Sciences 7212, pp. 347–
361.
[45] Morgado, I. et al. (2012). GUI reverse engineering with
machine learning. Proceedings First International
Workshop on Realizing AI Synergies in Software
Engineering (pp. 27–31). Zurich, Switzerland.
[46] Lu, L, & Huang, Y. (2012). Automated GUI Test Case
Generation. Proceedings 2012 International Conference on
Computer Science and Service System (pp. 582–585).
Nanjing, China.
[47] Sacramento, C. (2014). Web Application Model Generation
through Reverse Engineering and UI Pattern Inferring.
Proceedings 9th International Conference on the Quality of
Information and Communications Technology (pp. 105–
115). Guimaraes, Portugal.
[48] Sánchez, R., Sánchez, J. & García, J. (2010). Model-driven
reverse engineering of legacy graphical user interfaces.
Proceedings IEEE/ACM International Conference on
Automated Software Engineering (pp. 147-150). Antwerp,
Belgium.
[49] Yang, W., Prasad, M. & Xie, T. (2013). A grey-box approach
for automated GUI-model generation of mobile
applications. Lecture Notes on Computer Science 7793, pp.
250–265.
[50] Shah, E. & Tilevich, E. (2011). Reverse-engineering user
interfaces to facilitateporting to and across mobile devices
and platforms. Proceedings of the compilation of the colocated workshops on DSM (pp.255–259). Portland, USA.
[51] Pérez, R. et al. (2011). An empirical comparison of static and
dynamic business process mining. Proceedings 2011 ACM
Symposium on Applied Computing (pp. 272-279).
Taichung, Taiwan.
[52] Fahmi, S. & Choi, H. (2007). Software Reverse Engineering
to Requirements. Proceedings International Conference on
Convergence Information Technology (pp. 2199–2204).
Gyeongju, China.
45