Refactorizacion basada en búsquedas para mantenimiento de software SCM

1. Analisis

1.1. Documentos publicados en el tiempo

1.2. tipos de lecturas

1.3. autores

1.3.1. Mel Ó Cinnéide

1.3.2. Marouane KessentiniMarouane KessentiniMarouane

1.3.3. Ali Ouni

1.3.4. Iman Hemati Moghadam

1.3.5. Laurence Tratt

1.4. tipos de estudio

1.5. enfoques

1.6. tecnica de busquedas

1.7. Herramientas

1.7.1. A-CMA

1.7.2. CODe-Imp

1.7.3. DPT

1.7.4. Evolution Doctor

1.7.5. FermaT

1.7.6. Truerefactor

1.8. Metricas

1.9. Brechas y oportunidades de investigacion

2. Refacturacion por busquedas

2.1. Mejorar la calidad del software

2.1.1. Cinnéide y Nixon(1999a)

2.1.1.1. Refactorizar programas de software para aplicar patrones de diseño al código heredado

2.1.2. La herramienta DPT (Design Pattern Tool

2.1.2.1. Convirtió las transformaciones de patrón en un conjunto de minipatrónes

2.1.3. Analisis por patones

2.1.3.1. (Gamma et al., 1994)

2.1.3.2. (O'Keeffe & Cinnéide, 2004)

2.1.3.2.1. Se introdujo un método para elegir las métricas adecuadas para usar en el conjunto de métricas de la herramienta

2.1.3.3. (Bansiya & Davis, 2002).

2.1.3.3.1. Basaron el conjunto de métricas utilizadas en la herramienta en el modelo QMOOD de calidad de software

2.1.3.4. O'Keeffe & Cinnéide, 2008a

2.1.3.4.1. para incluir una cuarta técnica de búsqueda (HC de reinicio múltiple) y estudios de caso más grandes. La funcionalidad de la herramienta CODe-Imp también se amplió para incluir seis refactorizaciones adicionales

2.1.3.5. O'Keeffe & Cinnéide, 2007a

2.1.3.5.1. utilizaron la plataforma CODe-Imp para llevar a cabo una comparación empírica de tres métodos de búsqueda metaheurística en la refactorización basada en búsqueda; múltiple-ascenso

2.1.3.6. Moghadam y Cinnéide(2011)

2.1.3.6.1. Reescribió la plataforma CODe-Imp para admitir la entrada Java 6 y proporcionar una plataforma más flexible

2.1.3.7. Seng, Stammel y Burkhart (Seng et al., 2006

2.1.3.7.1. Introdujeron un asesor experto para aplicar posibles refactorizaciones a un fenotipo de programa (un modelo de código abstracto)

2.2. Capacidad de prueba

2.2.1. Harman (Harman, 2011)

2.2.1.1. Una nueva categoría de transformación de la capacidad de prueba (utilizada para producir una versión de un programa más susceptible de probar la generación de datos) llamada refactorización de la capacidad de prueba

2.2.2. Morales y otros (2016)

2.2.2.1. investigaron el uso de un enfoque multi-objetivo que tenga en cuenta el esfuerzo de prueba en un sistema

2.2.3. Cinnéide, Boyle y Moghadam(2011)

2.2.3.1. utilizaron la métrica LSCC (Low-level Similarity-based Class Cohesion) con la plataforma CODe-Imp para comprobar si la refactorización automatizada con la ayuda de métricas de cohesión puede utilizarse para mejorar la capacidad de prueba de un programa

2.3. Eficacia métrica con la refactorización

2.3.1. Ghaith y Cinnéide(2012)

2.3.1.1. investigaron un conjunto de métricas de seguridad para determinar el éxito que podrían tener para mejorar una aplicación sensible a la seguridad mediante la refactorización automatizada

2.3.2. Veerappa y Harrison (2013)

2.3.2.1. ampliaron este trabajo utilizando CODe-Imp para inspeccionar las diferencias entre las métricas de acoplamiento

2.3.3. Simons, Singer y White (2015)

2.3.3.1. Compararon los valores de las métricas con las opiniones profesionales para deducir si las métricas por sí solas son suficientes para refactorizar un programa de manera útil

2.3.4. Vivanco y Pizzi (2004)

2.3.4.1. Utilizaron técnicas basadas en búsquedas para seleccionar las métricas de mantenimiento más adecuadas de un grupo

2.3.5. Harman, Clark y Cinnéide(2013)

2.3.5.1. Escribieron sobre la necesidad de métricas sustitutas que se aproximan a la calidad de un sistema para acelerar la búsqueda

2.4. Corregir defectos de software

2.4.1. con programación genética (GP

2.4.1.1. Detección de defectos de diseño como ejemplo de mal diseño

2.4.2. (Kessentini et al., 2011)

2.4.2.1. El enfoque se comparó con un enfoque diferente basado en reglas para la detección de defectos con cuatro programas Java de código abierto y se encontró que era más preciso con los defectos de diseño encontrados. Luego se investigó el trabajo con este enfoque de la corrección del olor al diseño (defecto)

2.4.3. (Ouni et al., 2013)

2.4.3.1. Reemplazó la GA utilizada en el enfoque de corrección del olfato de código por un GA multiobjetivo (NSGA-II)

2.4.4. (Kessentini et al., 2012)

2.4.4.1. Ampliaron el enfoque original mediante el uso de ejemplos de buen diseño de código para ayudar a proponer secuencias de refactorización para mejorar la estructura del código

2.4.5. Ouni, Kessentini y Sahraoui (2013)

2.4.5.1. exploraron entonces el potencial de utilizar la historia de refactorización del desarrollo para ayudar a refactorizar la versión actual de un proyecto de software. Utilizaron un enfoque multi-objetivo con NSGA-II para combinar tres objetivos separados al proponer secuencias de refactorización para mejorar el producto

2.5. Herramientas de refactorización

2.5.1. Fatiregun, Harman y Hierons (2004)

2.5.1.1. ga

2.5.1.2. ha

2.5.2. DiPenta (2005)

2.5.3. Wahl e Izurieta (2011

2.5.3.1. truerefactor

3. tecnicas de software

3.1. escalada en la colina

3.1.1. tecnica HC

3.1.2. SBSE

3.2. Recorrido Simulado

3.2.1. variacion HC

3.3. Algortimo Geneticos

3.3.1. clase de algoritmo evolutivo

3.4. Algortimo evolutivo multiobjetivo

3.4.1. eas

3.4.2. moea

4. esquema de la encuesta

4.1. RQ1: ¿Cuántos artículos se publicaron al año?

4.1.1. De 1999 a 2016, hay un promedio de tres artículos publicados por año, con un notable aumento en la cantidad que se publicó después de una sequía en 2009 y 2010. Los documentos que implican el uso de EAs también aumentaron notablemente después de 2010, junto con estudios de técnicas de búsqueda más oscuras (ABC, CRO, VNS). La mayor cantidad de artículos publicados en un año es de ocho artículos, en 2012

4.2. RQ2: ¿Cuáles son los métodos más comunes de publicación para los periódicos?

4.2.1. " La mayoría de los trabajos fueron publicados en conferencias con la conferencia de computación evolutiva GECCO publicando la mayoría de los artículos a las siete. Sólo se publicó un artículo como sección de libros y 13 se publicaron en revistas en comparación con los 36 artículos (72% de los analizados) que se publicaron en conferencias

4.3. RQ3: ¿Quiénes son los autores más prolíficos que investigan la refactorización basada en búsquedas en el mantenimiento de software?

4.3.1. El 76% de los autores de los trabajos analizados sólo habían participado en uno de los artículos publicados, pero 17 eran autores en al menos dos. Once autores publicaron más de dos artículos cada uno. De estos autores, Mel Cinnéide y Marouane Kessentini fueron los autores de 33 de los artículos entre ellos, y trabajaron juntos en cuatro de ellos

4.4. RQ4: ¿Qué tipos de estudios se utilizaron en los periódicos?

4.4.1. La mayoría de los estudios investigaron enfoques de refactorización, pero tres de los estudios cuantitativos examinaron otros aspectos, como la configuración del propio proceso de búsqueda o las métricas utilizadas para el mantenimiento

4.5. RQ5: ¿Qué enfoques de refactorización se utilizaron en la literatura?

4.5.1. El enfoque menos común utilizado en un solo estudio (Moghadam & Cinnéide, 2012)refactorizado software hacia un diseño de software ideal generado previamente utilizando modelos UML

4.6. RQ6: ¿Qué técnicas de búsqueda se utilizaron en los estudios de refactorización?

4.6.1. La mayoría de los estudios involucraron EAs de algún tipo (principalmente GAs). HC y SA también fueron populares, siendo utilizados en 14 estudios y 11 estudios respectivamente. Otras técnicas de búsqueda se utilizaron con menos frecuencia. La PSO se utilizó en tres estudios, mientras que ABC fue experimentado en un estudio. Los estudios también experimentaron con CRO y VNS en 2015 y 2016

4.7. RQ7: ¿Qué tipos de programas se utilizaron para evaluar los enfoques de refactorización?

4.7.1. Cinco de los estudios utilizaron programas de código abierto junto con un programa interno o el programa industrial JDI-Ford. Los tamaños del programa eran generalmente alrededor de decenas de miles de líneas de código

4.8. RQ8: ¿Qué herramientas se utilizaron para la refactorización?

4.8.1. Hubo siete herramientas de refactorización diferentes propuestas y utilizadas entre los estudios. La mayoría de ellos funcionaban con código Java. La mitad de las herramientas

4.9. RQ9: ¿Qué tipos de métricas se utilizaron en los estudios?

4.9.1. Varios de los estudios utilizaron métricas de la suite métrica QMOOD (Mohan et al., 2016; O'Keeffe & Cinnéide, 2007b) o losatributos de calidad construidos por (Bansiya & Davis, 2002)utilizando su suite QMOOD (O'Keeffe & Cinnéide, 2006)

4.10. RQ10: ¿Cuáles son las brechas en la literatura y las oportunidades de investigación disponibles en el área?

4.10.1. Se ha demostrado que la refactorización basada en búsquedas para automatizar el mantenimiento de software funciona para ejemplos experimentales y se han desarrollado diversas herramientas para abordar el problema del mantenimiento mediante medios automatizados, pero es necesario seguir trabajando para medir ejemplos empíricos