Está en la página 1de 12

Lic.

González Crivelli Maximiliano - Maestría en Sistemas de Información 2017

Módulo VII: Técnicas avanzadas de diseño de software

Profesor: Dr. Emanuel Irrazábal

Alumno: Lic. González Crivelli Maximiliano Patricio Alberto

Trabajo Práctico 02

1 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017

 Cyvis: Análisis de Código Fuente


Este programa permite, de forma gráfica, encontrar algunos Code Smells, pero no todos.

Nos permite setear la complejidad ciclomática y nos muestra la cantidad de clases, la cantidad de métodos y
cantidad de instrucciones.

Las métricas que podemos analizar nos dan una idea de la mantenibilidad del código analizado.

Determinación de los umbrales:

Para la determinación del umbral de los indicadores se pueden utilizar los siguientes parámetros:

 Experiencia propia en este tipo de productos.


 Variabilidad de los indicadores en las diferentes versiones.
 Valores estándar de la herramienta de evaluación (Cyvis) ajustando los valores.
 Valores de productos similares existentes.
 Valores previstos por otros profesionales.

Analizando globalmente no se detectan grandes variabilidades en los indicadores entre la diferentes versiones,
no tenemos valores de algún producto similar, y no tenemos experiencia propia en este tipo de productos.

entonces procedemos a utilizar los valores estándar de la herramienta Cyvis para la complejidad ciclomática.

y valores estándar de publicaciones de otros profesionales. [1][2].

Complejidad Ciclomática: (Umbral CC Cyvis >= 7)


La complejidad ciclomática es una métrica de código que puede ser usado por cualquier lenguaje de
programación. Esta métrica nos indica que tan complejo es nuestro código y la cantidad de pruebas unitarias
que necesitamos para abarcar al 100% esta funcionalidad.

En general, una alta complejidad ciclomática, indica que el código es muy difícil y costoso de mantener.

Paquetes con clases con alta complejidad ciclomática:

 junit.framework
 org.junit.internal.runners
 org.junit
 org.hamcrest.core
 org.junit.runners
 org.junit.internal
 org.hamcrest
 junit.runner
 org.junit.internal.runners.statements

2 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017
 junit.textui
 org.junit.experimental.theories.internal
 org.junit.experimental.max

Ejemplos gráficos: En el Cyvis los vemos en rojo, para el valor seteado >= 7

Recomendación: Las clases de estos paquetes que tengan alta complejidad ciclomática se debe realizar
inspección o analizarlas con alguna herramienta más completa para reducir su complejidad.

3 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017
Posibles Code Smells que se puede analizar con Cyvis:

Lazy Class: (Umbral NOM <= 3 y CC Cyvis <= 4) [3]

Clases que no están haciendo mucho por sí mismas y que podrían ser eliminadas. [1]

Se establece el criterio de bajo número de métodos y baja complejidad ciclomática, que son las métrica que
nos proporciona esta herramienta.

Paquete Clase NOM


org.junit.internal.runners SuiteMethod 2
org.junit.experimental.theories PotentialParameterValue 3
ParameterSupplier 2
org.junit.rules Timeout 2
TestName 3
Verifier 3
org.junit.internal RealSystem 3
org.hamcrest BaseMatcher 3
org.junit.runners.model Statement 2
org.junit.internal.matches Each 2
org.hamcrest.internal SelfDescribingValue 2
org.junit.internal.runners.model ReflectiveCallable 3
org.junit.matches Each 2
org.junit.experimental.theories.suppliers (*) TestedOnSupplier 2
org.junit.experimental.catagories (*) Categories (**) 3
org.junit.experimental.runners (*) Enclosed 1

(*) Paquetes con una sola clase.

(**) Esta clase paso de una complejidad ciclomática media a baja complejidad y pocos métodos, o fue
refactorizada, o se convirtió en una lazy class.

Nota: Cambiando el umbral de NOM a <= 4, se incrementa el número de posibles Lazy Class, esto indica que
depende del proyecto en cuestión. Para determinar si el umbral es el correcto hay que hacer inspección de las
clases indicadas.

Nota: hay clases con 3 métodos pero son clases que son "assert...", "failed...","exception..." que no está mal
que tengan pocos métodos.

Existen clases que tienen pocos métodos pero alta complejidad ciclomática, estas no se consideran lazy class,
pero hay que analizarlas porque puede dividirse en mas métodos el método complejo.

Ejemplo de clase con pocos métodos pero alta complejidad ciclomática:

4 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017
paquete: org.junit.internal

 Clase: InexactComparisonCriteria: tiene solo 2 métodos, pero 1 con alta complejidad ciclomática.

Recomendación: Se debe realizar inspección para estas clases y con esto añadir otros indicadores,
como Profundidad del árbol de herencia, Número de atributos, Número de hijos, para determinar si
verdaderamente son "Lazy Class".

De todos modos Ciertos sistemas son particulares y puede que las conclusiones generales extraídas no sean
correctas. [2]

5 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017

Long Method: (Umbral: IC Cyvis >= 400)

Métodos con mucha cantidad de instrucciones.

Algunas de estas clases coinciden con lo expuesto anteriormente, es un indicador más que la clase o alguno de
sus métodos pueden ser muy complejos.

Paquete Clase Instruction Count


junit.framework TestSuite entre 609 - 646
Assert entre 513 - 544
TestCase entre 510 - 510
org.junit Assert entre 526 - 819
org.junit.runners BlockJUnit4ClassRunner entre 437 - 621
ParentRunner entre 401 - 435
org.junit.runners.model TesClass entre 344-433
junit.runners BaseTestRunner entre 685 - 728
TestCaseClassLoader entre 607 - 607
junit.swingui TestRunner entre 2023 - 2023
TestSelector entre 555 - 555
junit.awtui TestRunner entre 1539 - 1539

Recomendación: Algunas clases en las diferentes versiones fueron aumentando su cantidad de


instrucciones o las han refactorizado.

Existen algunas clases que están muy alejadas del umbral propuesto, parecen ser de la interfaz gráfica,

estas clases se deben examinar para saber si es necesario refactorizar o pueden quedar así.

6 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017

Large Class: (Umbral NOM >= 20 y CC Cyvis >= 7) [3]

Nota: Según [3] un umbral válido podría ser NOM >= 10. pero con este umbral hay que analizar el 80% de los
paquetes. Por consiguiente, se modificó el umbral para una primera aproximación a 20.

Paquete Clase NOM


junit.framework TestSuite 51
TestCase 51
Assert 39
org.junit Assert 62
org.junit.runner Description 28
org.junit.runners BlockJUnit4ClassRunner 34
ParentRunner 30
junit.runner BaseTestRunner 34

Nota: Algunas clases fueron incluidas ya que, a pesar, que no tienen una CC >= 7, tiene una gran cantidad de
métodos.

Ejemplo: org.junit - Assert

Recomendación: Se debe realizar inspección para estas clases y con esto añadir otros indicadores,
como Número de atributos, para determinar si verdaderamente son "Large Class".

De todos modos Ciertos sistemas son particulares y puede que las conclusiones generales extraídas no sean
correctas. [2]

Cambiar el Umbral de NOM a NOM >= 10, y volver a inspeccionar las clases que cumplan con este umbral.

7 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017

 Test Página web: Análisis de página web


Página que realiza el análisis general: gtmetrix.com

Página para realizar análisis de imágenes: webspeedtest.cloudinary.com

Página a analizar: southforge.azurewebsites.net

Página para convertir las imágenes: https://convertio.co/es/jpg-webp/

(Página de la empresa South Forge en servidor de pruebas en nube de Microsoft Azure)

8 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017
Resultado General del primer test: gtmetrix.com

Explicación:

 El indicador “Page Speed” se encuentra en el 56%, siendo el promedio recomendado 71%.


 El indicador “YSlow” se encuentra en el 65%, siendo el promedio recomendado 69%.

9 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017

Recomendaciones:
 Cambiar las escalas de las imágenes.
 Utilizar el filtro “inline Javascrip” para reducir las peticiones de la página.
 Combinar Imágenes usando CSS Sprites.
 Optimizar Imágenes.

De las recomendaciones tomamos una como ejemplo:

Optimización de imágenes: (Umbral >= 30 % de mejora, tamaño imagen >=


30KB)
Se seleccionaron las imágenes que según el test produjeran un rendimiento igual o superior al 30% y que el
tamaño de la imagen fuera significativo, igual o superior que 30Kb. Las imágenes a mejorar son:

10 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017
Con un convertidor de imágenes conseguimos reducir el tamaño de las imágenes con el nuevo formato.

Nota: No se pudo utilizar el nuevo formato, ya que el control “slide” utilizado no lo soporta.

Recomendación: Buscar otro control “Slide” que acepte el formato webp. Y reemplazar las imágenes
seleccionadas.

11 Técnicas avanzadas de diseño de software


Lic. González Crivelli Maximiliano - Maestría en Sistemas de Información 2017

 Referencias:
[1] Martin Fowler. Refactoring. Improving the Design of Existing Code. Number 0-201-48567-2. Addison-
Wesley, 2000.

[2 ]Mika Mäntylä, Jari Vanhanen, and Casper Lassenius. Bad smells - humans as code critics. In 20th IEEE

International Conference on Software Maintenance, 2004.

[3] Raúl Marticorena, Carlos López, Yania Crespo, Esperanza Manso. Umbrales relativos. Caso de estudio para
incorporar métricas en la detección de Bad Smells. RPM 6 (1) 2 (2010) ISSN 1698-2029, 2014

12 Técnicas avanzadas de diseño de software