Finnish large-value payment system, POPS

Es necesario determinar el grado de avance obtenido con la implementación de los escenarios de esta iteración del proceso de refactorización. Esta medición de resultados se hace combinando distintos indicadores para validar las refactorizaciones llevadas a cabo hasta el momento.

En esta segunda iteración del proceso, se han definido e implementado ocho escenarios de modificabilidad a través de los cuales se ha atacado la Anomalía 3: “Diseño ligado a correos electrónicos”. Por lo tanto, habrá que verificar si el diseño de la aplicación es ahora, un poco menos ligado a correos electrónicos, es decir, un poco más abstracto y más modificable.

5.6.5.1. Análisis basado en métricas y documentación

• Cantidad de horas de desarrollo dedicadas. En total para el análisis, especificación e implementación de los escenarios de esta iteración se empleó un estimado de 57 horas de desarrollo.

• Code smells por tipos. En la tabla 5.19 se aprecian las mejoras realizadas en esta iteración en cuanto a los code smells de todo el sistema. Se observa un descenso notable de la cantidad total de smells (29,55%) y mejoras significativas en los principales tipos de smells vinculados a acoplamiento y cohesión. El tipo de smells con mayor mejora (75%) son las God Class, que se asocia a clases con alta complejidad, alto acoplamiento y baja cohesión.

Grupo Cantidad por Tipo Antes Después Mejora

Total de Code Smells 132 93 29,55%

Identidad Feature Envy 61 47 22,95%

Colaboración Dispersed Coupling 45 32 28,89% Colaboración Shotgun Surgery 13 6 53,85% Colaboración Intensive Coupling 3 1 66,67%

Identidad Brain Method 3 2 33,33%

Identidad God Class 4 1 75,00%

• Code smells por componentes afectados. La tabla 5.20 muestra las mejoras antes y después de las refactorizaciones en cada uno de los principales componentes del sistema. Se destaca el mejor resultado relativo en Importer donde, luego del escenario 3.3, se logra bajar de 43 a 17 smells. Luego los componentes Graph (reducción de 14 de 25 smells) y Model (reducción de 4 de 15 smells) siguen en nivel de mejora. Como se vió en la etapa 1 de esta iteración, estos tres componentes, que concentran la mayoría de los smells, son los responsables de la construcción del grafo, el modelado y la importación de datos. Estas áreas de código tienen relación directa con el desarrollo de los requerimientos funcionales planificados para SocialGraph. Por lo tanto, es fundamental lograr allí estas mejoras de modificabilidad.

Se observa también que algunos smells no fueron eliminados, sino desplazados a otras áreas del sistema. En particular los 5 “nuevos” smells que figuran en la fila Otros se ubican en áreas de menor importancia: tres de ellos en los casos de test y dos el paquete utils.

También se ve que la interfaz gráfica se mantiene sin cambios. Este resultado es de esperar dado que se decidió no abordar la Anomalía 2 que representa el acoplamiento entre las capas de la arquitectura.

Antes Después Mejora

Importer 43 17 60,47% GUI 36 36 0,00% Graph 25 11 56,00% Model 15 11 26,67% Otros 13 18 -38,46% Total 132 93 29,55%

Tabla 5.20. Variación de code smells en cada paquete antes y después de iteración 2.

5.6.5.2. Análisis subjetivo y valoración del grupo de desarrollo

En el conjunto de escenarios que componen esta iteración se hicieron algunos cambios en el diseño y el modelo de la aplicación que mejoran considerablemente su flexibilidad y nivel de abstracción. Se destaca la aplicación del patrón Strategy en la construcción del grafo en el escenario 3.1.1. El grafo es la estructura principal de SocialGraph y al estar ligado a los correos electrónicos (clase Mail) era dificil pensar en nuevas fuentes de datos que alimenten la información representada en el grafo. Luego de esta refactorización, para agregar una nueva

fuente, bastará con crear una nueva estrategia de construcción del grafo, que puede combinarse con la(s) existente(s).

Esta mejora de diseño se complementa con la abstracción del modelo en los escenarios 3.1.2 a 3.1.5. Alli, se reemplazó en cada uno de los componentes del grafo, la clase Mail por la interfaz CommunicationLine, que puede ser implementada por diversas fuentes de información. A su vez, este cambio se propagó a la interfaz gráfica en el escenario 3.2. De modo que se elevó el nivel de abstracción en todas las secciones de código vinculadas a la construcción del grafo.

5.6.5.3. Validación de escenarios

Realizadas estas mediciones, se observa una mejora en la modificabilidad y flexibilidad del sistema, tanto desde el punto de vista del diseño como de la implementación. El resultado de las refactorizaciones implementadas es positivo y por lo tanto se valida el conjunto de cambios especificados en los escenarios de esta segunda iteración del proceso.

5.6.6. Etapa 6: Evaluación

En esta iteración se abordó la Anomalía 3, que es probablemente, la más importante para los objetivos de desarrollo del proyecto de SocialGraph. La evaluación de esta iteración es altamente positiva. A partir de tener un mejor conocimiento del sistema y de realizar tanto un análisis objetivo como subjetivo del proceso, se aprecia una mejora en la modificabilidad.

Si se suma el total de horas de desarrollo dedicadas sólo a la implementación de los escenarios, se ve que se han invertido 81 horas hombre de trabajo, lo que representa aproximadamente el trabajo de un desarrollador durante dos semanas a tiempo completo.

Se ha aplicado una segunda iteración del proceso definido sobre el caso de estudio. Esto permitió conocer en profundidad las principales defectos de diseño e implementación del sistema para aplicar refactorizaciones y obtener mejoras en la modificabilidad del sistema.

Dado el esfuerzo dedicado y el impacto positivo que se obtuvo, se resuelve no realizar una tercera iteración del proceso y dar por terminada la actual instanciación del mismo.

6. Conclusiones

La refactorización es el proceso de modificar un programa para mejorar la calidad estructural de su código fuente sin alterar su funcionalidad. Esos cambios se pueden dar de manera aleatoria, no planificada o bien se pueden direccionar los esfuerzos para que la mejora de calidad sea más valiosa. En este trabajo final se buscó organizar un conjunto de buenas prácticas para brindar a los desarrolladores un proceso guiado por la modificabilidad del sistema. Para ello, se combinaron distintas herramientas y metodologías en un proceso paso a paso que facilita el seguimiento y la evaluación del proceso de refactorización.

A partir de las experiencias de distintos expertos en la materia, se llegó a la definición de un proceso de refactorización basado en escenarios de modificabilidad y code smells. Para ello, se documentó sistemáticamente un conjunto de iteraciones, etapas y actividades con la intención de aplicarlas en el desarrollo de sistemas de software para mejorar su modificabilidad.

6.1. Evaluación de la solución

Para validar la definición del proceso, este fue instanciado en SocialGraph, un proyecto de desarrollo real utilizado como caso de estudio. Esta experiencia deja algunas conclusiones interesantes que pueden servir como aporte para otros proyectos de refactorización.

La implementación de refactorizaciones aleatorias sobre un sistema produce mejoras aisladas, pero el uso de un proceso “racional” permite orientar los esfuerzos para que el impacto se de sobre los aspectos de interés del proyecto. En el caso de estudio, el objetivo principal fue elevar la calidad del sistema a partir de su modificabilidad y esto se logró enmarcando el desarrollo en el proceso definido en este trabajo. Las sucesivas etapas de ese proceso permitieron estudiar el sistema, detectar problemas, ponderarlos, proponer soluciones e implementarlas de manera efectiva y planificada.

La etapa de análisis permitió detectar los principales problemas del sistema para luego idear las refactorizaciones que se debían implementar. Por eso fue fundamental tener un buen conocimiento del sistema, contar con documentación actualizada, valerse de métricas y otras herramientas de análisis. En el caso de estudio, los requerimientos funcionales estuvieron claros, además se contaba con cierto conocimiento de la arquitectura del sistema, aunque este se debió profundizar y documentar a través de diagramas UML para comprender las estructuras y el flujo de datos. El uso de code smells, sugerido por el proceso, fue esencial para detectar síntomas de problemas en componentes clave de la arquitectura. Así se detectó el grave acoplamiento entre artefactos que desde el punto de vista del diseño, quizás no debieran estar tan vinculados. Este tipo de métricas son útiles cuando el sistema es relativamente grande y no se tiene conocimiento de sus detalles de implementación.

El uso de escenarios de calidad para la definición de las refactorizaciones permitió describir, en un lenguaje conocido por los desarrolladores, qué se debe hacer, qué artefactos se ven afectados y cómo se valida el trabajo a realizar. Es una forma sencilla de definir el trabajo que debe realizar un programador. En el caso de estudio se vió que la escala de los escenarios

definidos no fue homogénea, ya que en algunos casos se trató de refactorizaciones concretas a nivel de código pero en otros se requirió profundizar el análisis del diseño incluso durante la etapa de implementación. En general, esto varía según la complejidad del escenario y la experiencia de los desarrolladores que lo implementan. En algunos casos se optó por dividir el escenario en sub-escenarios de manera tal de minimizar el riesgo de sufrir un efecto dominó y resolver el problema a través de la combinación de varias soluciones.

Una vez definidas las refactorizaciones, en la etapa de implementación se realizaron los cambios en el sistema. La introducción de cambios no debe poner en riesgo la funcionalidad del sistema, por eso en esta etapa se pudo determinar la importancia de contar con un testeo robusto. En el caso de estudio, la presencia de casos de test era prácticamente nula por lo que, siguiendo el proceso definido, antes de implementar cada escenario se debió garantizar una cierta cobertura de tests de las áreas afectadas.

Finalmente, la medición de resultados permitió evaluar los avances de calidad obtenidos luego de la implementación de uno o más escenarios. De esta manera, se validan las etapas anteriores del proceso y se puede optar por seguir implementando escenarios e iteraciones del proceso, por revisar algunos cambios realizados o bien por finalizar el proceso.

En conclusión, la instanciación de este proceso de refactorización guiado por escenarios de calidad y code smells podría realizarse en cualquier otro sistema de software. Sin embargo, los resultados podrán variar de acuerdo a las características de la arquitectura del sistema. En los casos de sistemas cuyo proyecto de desarrollo cuente con documentación actualizada, requerimientos funcionales claros, atributos de calidad definidos, buena cobertura de tests y desarrolladores con conocimiento de la arquitectura; el proceso será más eficiente, ya que estos artefactos facilitan el análisis, la detección de problemas y la implementación de soluciones efectivas. En sistemas con menor grado de formalidad en su metodología de desarrollo o arquitectura o escasa cantidad de artefactos, el proceso de refactorización será más lento ya que habrá que conocer la arquitectura, documentar el proyecto para estudiar sus debilidades, elicitar requerimientos y objetivos del refactoring, implementar casos de tests, etc. De todas maneras, en esos casos el proceso también es aplicable y como resultado se logrará, además de una mejora en la calidad del sistema, una mejora en la calidad del proceso de desarrollo.

6.2. Aportes y beneficios

Con este trabajo se logró enmarcar un conjunto de buenas prácticas de desarrollo de software en un proceso de refactorización orientado a mejorar la modificabilidad a partir de la implementación de escenarios de calidad. Es un aporte a aquellos diseñadores y arquitectos que deseen mejorar sus procesos de desarrollo a partir de la refactorización de áreas de código de interés. La aplicación del proceso definido permite refactorizar un sistema para incorporar nuevas funcionalidades de manera segura, planificada e integrada.

Si bien las refactorizaciones son pequeñas mejoras sobre el código de un sistema de software, un conjunto de refactorizaciones guiadas por un proceso como el definido en este trabajo conduce a una mejora notable de la calidad, en este caso de la modificabilidad. Los

beneficios de enmarcar los esfuerzos de desarrollo en este proceso permiten identificar mejor las áreas prioritarias para aplicar las refactorizaciones y, como consecuencia de ese análisis, sugerir soluciones acertadas a implementar.

Los resultados obtenidos a partir del caso de estudio son alentadores para seguir aplicando este proceso para mejorar la calidad de otros sistemas y también del proceso en general. En su definición, se especificó una serie de etapas y actividades, brindando un marco flexible para que los analistas incorporen sus propias herramientas para el análisis y medición de resultados.

6.3. Limitaciones

A partir de la aplicación del proceso definido en el caso de estudio, se detectan algunas limitaciones que es bueno tener en cuenta en otros casos de aplicación:

• Los escenarios de modificabilidad a veces no son lo suficientemente específicos como para que un desarrollador sin conocimiento profundo del sistema pueda realizar las tareas de manera directa. Si el desarrollador que implementa el escenario no es el mismo que realizó el análisis, los tiempos estimados como medida de respuesta se pueden extender. Esto se evidencia, por ejemplo, en el escenario 3.1: “Abstraer el modelo para la construcción del grafo”, el cual fue necesario dividirlo en seis subescenarios.

• Es difícil garantizar en un 100% la cobertura de tests para poder evitar posibles efectos dominó al realizar una refactorización. Por ejemplo, en el escenario 3.1.6: “Refactorizar

God Class en GraphPersistenceHelper” se ejecutaron los tests correctamente pero días

más tarde, por casualidad, se detectó un error en el sistema que fue introducido durante esta refactorización. Esta situación requirió dedicar tiempo a rastrear el origen del error, corregirlo y además, volver revisar la forma en que se testea el sistema.

• El éxito de la instanciación de este proceso está ligado a las características del sistema de software al que se aplica: la escala del sistema, la calidad de arquitectura y los conocimientos del mismo por parte de los desarrolladores responsables del refactoring. Estos factores son claves para el éxito en las etapas de análisis y especificación de escenarios y pueden determinar la viabilidad de todo el proceso.

• La experiencia del caso de estudio demuestra que los code smells ayudan a detectar síntomas de malas prácticas de implementación, sin embargo también se detectan muchos falsos positivos que obligan a los desarrolladores a revisar cada uno de los smells detectados. Para el diagnóstico de la arquitectura y el diseño no alcanza con el análisis objetivo que puede hacerse sobre las métricas. También es imprescindible el análisis subjetivo obtenido a partir de la experiencia de los desarrolladores en la evaluación y toma de decisiones. Es necesario contar con uno o más desarrolladores involucrados con la arquitectura del sistema y los objetivos del proyecto.

• Naturalmente, la realización de este proceso no soluciona todos los problemas de un sistema en desarrollo, más bien ayuda a dedicar los recursos a mejoras estratégicas para la evolución del sistema. Queda evidenciado que el refactoring debe ser un proceso continuo en el tiempo, donde se mejore la calidad del software de manera constante.

6.4. Trabajos futuros

Algunas ideas para desarrollar en posibles trabajos futuros:

• Seguramente el proceso puede ser mejorado en cada una de sus etapas y actividades. Las técnicas, métodos, indicadores y herramientas utilizados pueden ser refinadas o bien se pueden incorporar nuevas opciones que aporten a un proceso de mayor calidad.

• En este trabajo final, el proceso definido se ha aplicado apenas sobre un caso de estudio y, como se ha visto, los resultados pueden variar de acuerdo al ambiente en que se aplique el proceso. Por eso, sería bueno aplicar el proceso a otros casos de estudio y profundizar el análisis de resultados obtenidos en este trabajo.

• Dado que el objetivo es mejorar la modificabilidad de un sistema, se podrían comprobar los resultados a partir de experiencias en casos de estudio donde se midan la mejoras de este atributo de calidad luego del desarrollo de nuevas funcionalidades, verificando empíricamente la mejora de modificabilidad obtenida.

• Parte del análisis realizado en el proceso definido es denominado subjetivo, con lo cual es difícil de medir y podría arrojar resultados dispares dependendiendo de quién o quiénes lo lleven a cabo. A futuro sería bueno reforzar las herramientas que asisten a los desarrolladores en la toma de decisiones para el análisis y la validación del proceso. Cada experiencia de refactorización tiene sus particularidades, por lo que es deseable contar con un proceso que pueda adaptarse a la mayor variedad de sistemas y metodologías de desarrollo a fin de proveer un proceso consistente que garantice una mejora de calidad tanto a nivel de código, como de diseño y de arquitectura.

7. Referencias

[Alshayeb2009] Alshayeb, M. (2009). Empirical investigation of refactoring effect on software quality. Information and software technology, 51(9), 1319-1326.

[Bass2003] Bass, L., Clements, P., & Kazman, R. (2003). Software Architecture in Practice. [Bavota2015] Bavota, G., De Lucia, A., Di Penta, M., Oliveto, R., & Palomba, F. (2015). An Experimental Investigation on the Innate Relationship between Quality and Refactoring. Journal of Systems and Software.

[Beck2000] Beck, K. (2000). Extreme programming explained: embrace change. Addison- Wesley Professional.

[Bengtsson2000] Bengtsson, P., Lassing, N., Bosch, J., & van Vliet, H. (2000). Analyzing software architectures for modifiability.

[Bertran2011] Bertran, I. M. (2011, May). Detecting architecturally-relevant code smells in evolving software systems. In Proceedings of the 33rd International Conference on Software Engineering (pp. 1090-1093). ACM.

[DuBois2004] Du Bois, B., Demeyer, S., & Verelst, J. (2004, November). Refactoring- improving coupling and cohesion of existing code. In Reverse Engineering, 2004. Proceedings. 11th Working Conference on (pp. 144-151). IEEE.

[Elssamadisy2002] Elssamadisy, A., & Schalliol, G. (2002, May). Recognizing and responding to bad smells in extreme programming. In Proceedings of the 24th International conference on Software Engineering (pp. 617-622). ACM.

[Fowler1999] Fowler, M. (1999). Refactoring: improving the design of existing code.

[Fowler2009] TechnicalDebtQuadrant Martin Fowler, October 2009 http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

[Frier2015] Frier, J. R., & Roggio, R. F. (2015). The Downsides of Software Refactoring. Journal of Computer Science, 3(1), 01-13.

[Gamma1995] Patrones de Diseño. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison Weasley. 1995.

[Garcia2009] Garcia, J., Popescu, D., Edwards, G., & Medvidovic, N. (2009, March). Identifying architectural bad smells. In Software Maintenance and Reengineering, 2009. CSMR'09. 13th European Conference on (pp. 255-258). IEEE.

[GATE] Biblioteca GATE. https :// gate . ac . uk /

[ISO9126] ISO/IEC 9126-1, Software engineering – product quality – Part 1: Quality Model, first ed.: 2001-06-15.

[JSpIRIT] Java Smart Identification of Refactoring opportunITies

https :// sites . google . com / site / santiagoavidal / projects / jspirit

[Kerievsky2005] Kerievsky, J. (2005). Refactoring to patterns. Pearson Deutschland GmbH. [Kim2012] Kim, M., Zimmermann, T., & Nagappan, N. (2012, November). A field study of refactoring challenges and benefits. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (p. 50). ACM.

[Lanza2007] Lanza, M., & Marinescu, R. (2007). Object-oriented metrics in practice: using software metrics to characterize, evaluate, and improve the design of object-oriented systems. Springer Science & Business Media.

[Lehman2001] Lehman, M. M., & Ramil, J. F. (2001, September). An approach to a theory of software evolution. In Proceedings of the 4th international workshop on Principles of software evolution (pp. 70-74). ACM.

[Liu2006] Liu, J., Batory, D., & Lengauer, C. (2006, May). Feature oriented refactoring of legacy applications. In Proceedings of the 28th international conference on Software engineering (pp. 112-121). ACM.

[Liu2009] Liu, H., Yang, L., Niu, Z., Ma, Z., & Shao, W. (2009, August). Facilitating software refactoring with appropriate resolution order of bad smells. In Proceedings of the the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering (pp. 265-268). ACM.

[Liu2012] Liu, H., Gao, Y., & Niu, Z. (2012, July). An initial study on refactoring tactics. In Computer Software and Applications Conference (COMPSAC), 2012 IEEE 36th Annual (pp. 213-218). IEEE.

[Mäntylä2006] Mäntylä, M. V., & Lassenius, C. (2006). Subjective evaluation of software evolvability using code smells: An empirical study. Empirical Software Engineering, 11(3), 395- 431.

[Mens2004] Mens, T., & Tourwé, T. (2004). A survey of software refactoring. Software Engineering, IEEE Transactions on, 30(2), 126-139.

[MurphyHill2008] Murphy-Hill, E., & Black, A. P. (2008). Refactoring tools: Fitness for purpose. Software, IEEE, 25(5), 38-44.

[Schulz2009] Schulz, C., Löwe, M., & König, H. (2009). Refactoring object-oriented systems. Manipulation of Graphs, Algebras and Pictures. Essays Dedicated to Hans-Jörg Kreowski on the Occasion of His 60th Birthday, Universität Bremen, 321-340.

[Shrivastava2008] Shrivastava, S. V., & Shrivastava, V. (2008, November). Impact of metrics based refactoring on the software quality: A case study. In TENCON 2008-2008 IEEE Region 10 Conference (pp. 1-6). IEEE.

[Simon2001] Simon, F., Teinbruckner, F. S., & Lewerentz, C. (2001). Metrics based refactoring. In Software Maintenance and Reengineering, 2001. Fifth European Conference on