metricas de software -...

�capacitación y guía para el desarrollo de software�

METRICAS DE SOFTWARE aplicadas al código

Métricas de Software aplicadas al código 1


Tabla de contenidoDEFINICION DE MEDIDAS.............................................................................................................4

Estadísticas.................................................................................................................4

Valores de referencia.................................................................................................5

OVERVIEW PYRAMID................................................................................................................6

Tamaño y Complejidad...............................................................................................6

Proporciones calculadas.........................................................................................6

Acoplamiento..............................................................................................................6

Herencia......................................................................................................................8

Ejemplo...................................................................................................................8

Interpretación.............................................................................................................9

Sumamos colores ...................................................................................................9

Ejemplo del proyecto EAMaven antes de las mejoras.........................................10

..................................................................................................................................10

MÉTRICAS Y VISUALIZACIÓN......................................................................................................11

Visualización Pomimétrica (estática).......................................................................11

Problemas en la presentación de las medidas.........................................................11

Conclusión................................................................................................................12

CLASS BLUEPRINT................................................................................................................13

Notación gráfica de las estrategias de detección....................................................13

DISARMONÍAS......................................................................................................................15

Identity Harmony......................................................................................................15

Collaboration Harmony ............................................................................................15

Classification Harmony ............................................................................................15

Métodos de detección de Disarmonías....................................................................15

Estrategia de detección............................................................................................16

Filtering.................................................................................................................16

Composición..........................................................................................................16

Relación entre disarmonías......................................................................................17

ARMONÍA DE ENTIDADES...........................................................................................................18

Reglas.......................................................................................................................18

Relación y formas de manifestación .......................................................................18

Proceso de detección...............................................................................................19

Soluciones.................................................................................................................19

Observaciones..........................................................................................................20

ARMONÍA DE COLABORACIÓN......................................................................................................20

Reglas.......................................................................................................................20





Soluciones.................................................................................................................21

Orservaciones...........................................................................................................21

ARMONÍA DE CLASIFICACIÓN.......................................................................................................23

Reglas.......................................................................................................................23



Soluciones.................................................................................................................24

Orservaciones...........................................................................................................26

REVISIÓN DE CÓDIGO CON AYUDA DE MÉTRICAS...............................................................................26

REFERENCIAS.......................................................................................................................27



DEFINICION DE MEDIDAS

Mecanismo que permite

Þ Caracterizar el diseño de sistemas utilizando programación orientada a objetos

Þ Evaluar y mejorar el diseño de sistemas

Þ Guiar y conducir revisiones de diseño y código como mecanismo de garantía decalidad

· NOP: nro de paquetes o namespaces en el sistema

· NOC: nro de clases en el sistema

· NOM: nro de métodos x clase

· LOC: nro de líneas de código x método

· CYCLO: nro de decisiones x líneas de código (Complejidad Ciclomática)

· WMC: CYCLO / Metodos x LOC / Metodo x NOM / clase

· AMW: CYCLO / Metodo (average method weight)

Estadísticas

· Distribución Normal

· Valor esperado, promedio E

· Desviación estándar Sigma , 68% de las observaciones en E +- Sigma

· Outlier [E +- Sigma] * 1.5 -> 50% > [E +- Sigma]



Valores de referencia



OVERVIEW PYRAMID

Tamaño y Complejidad

Proporciones calculadas

Permiten comparaiones independientes del tamaño de los proyectos. Se calculan comla razón entre medidas adyacentes como se muestra en el figura.

Acoplamiento

· CALLS: nro de invocaciones a cualquier método de una clase desde diferentesmetodos de otras

· FANOUT: nro de clases dependientes (uso, invocaciones)

Las razones calculadas tienen el siguiente significado:

FANOUT / CALLS: cantidad de invocaciones salientes dividida la cantidad de llamadasentrantesMétricas de Software aplicadas al código 6


CALLS / NOM: cantidad de llamadas entrantes dividida la cantidad de metodos



Herencia

· ANDC: Average Number of Derived Classes. Solo se contabilizan clases (nointerfaces) propias (no de librerías).

ANDC = sumatoria (nro clases x nro herencias por clase) / NOC

· AHH: Average Hierarchy Height

AHH = sumatoria(nro clases root x nro niveles de herencia) / NOC

Ejemplo

Nro de clases total = 19, sin contar Q que es de una librería y T que es una interfaz.

ANDC = (11 clases· 0 herencia + 4 clases · 1 herencia + 3 · 2 + 1 · 4) / 1 9 = 0.73Nro. total de root clases 5 (A, N, R, S, U)AHH = (4 niveles de herencia (A) + 1 (N) + 0 (R) + 0 (S) + 0 (U)) / 5 = 1



Interpretación

Sumamos colores

Interpretación de la Complejidad

CYCLO / LOC = 0.15 evidencia que la complejidad es baja en relación al umbral.

LOC / NOM = 9.72 evidencia que el tamaño de los métodos es normal en relación alumbral.

NOM / NOC = 9.42 evidencia que el tamaño de las clases es execivo en relación alumbral.

Interpretación del Acoplamiento

CALLS / NOM : 4.18 evidencia gran acoplamiento

FANOUT / CALL = 0.56 evidencia que el acoplamiento está concentrado a unas pocasclases.

Interpretación de la Herencia

ANDC = 0.31 muestra uso bajo de herencia

AHH = 0.12 indica que las jerarquías no son profundas sino horizontales.



Ejemplo del proyecto EAMaven antes de las mejoras



MÉTRICAS Y VISUALIZACIÓN

Visualización Pomimétrica (estática)

Problemas en la presentación de las medidas

� Caracterizaciones des balanceadas

� Métricas mal utilizadas

� Métricas no relacionadas

� Pérdida de referencias

POLYMETRIC VIEWSTamaños y colores indican los valores de las métricas.



Ejemplo: Proyecto EAMaven

Rojo: al menos un problema de diseño de clase

Amarillo: al menos un problema de diseño de método

Verde: ningún problema de diseño detectado

Conclusión

Overview Pyramid: brinda un resumen construido en base a métricas simples y sirvepara caracterizar un sistema en términos de tamaño, complejidad, acoplamiento yherencia.

Polymetric Views: brinda un medio simple y poderoso de visualización



CLASS BLUEPRINT

Notación gráfica de las estrategias de detección

Las capas en que se descompone una clase en un blueprint se muestran en la figuraanterior y son:

Inicialización: incluye constructores y métodos de inicialización

Interfaz externa: incluye los métodos publicos de conducción del negocio

Implementación interna: métodos privados

Accesors: métodos de acceso a atributos

Atributos: atributos

También se indica la invocación de los diferentes métodos mostradas como lineasque conectan dichos métodos.

En la figura que sigue se muestra el código de colores y un ejemplo de uso.



Ejemplo: clase Proyecto del proyecto EAMaven



DISARMONÍAS

Identity Harmony

Armonía entre la clase que modela un concepto y los datos y métodos que operansobre esos datos.

Collaboration Harmony

Armonía en la forma en que colabora cada clase con el resto a efectos de lograr lafuncionalidad pedida.

Classification Harmony

Cómo cada clase hace uso de los métodos heredados y los propios. Cuál es elcomportamiento de cada clase en la jerarquía de herencia a la cual pertenece.

Si se logra cumplir con los criterios (reglas) de diseño, cada componente dentro delsistema estará en armonía con el esto.

Métodos de detección de Disarmonías

1. Estrategia de detección: expresión lógica armada con medidas defragmentos de código



2. Class BluePrint: visualización con semántica de la estructura interna de laclase y de su jerarquía

Estrategia de detección

Una métrica no puede responder a todas las preguntas acerca del sistema, por lo tantodeben ser combinadas para obtener a partir de estas combinaciones la informaciónnecesaria.

¿Cómo combinamos las métricas?

El uso de las métricas está basada en filtrado y composición.

Filtering

· Filtros estadísticos

· Filtros basados en umbrales

Composición

Están basadas en operaciones lógicas que componen diferentes métricas y lascomparan contra los umbrales de las estadísticas.

En la figura puede verse la estrategia de detección de la dis armonía God Class

Las siglas de las métrica significan:

ATFD: atributos no propios (foreign) usados por la clase.

WMC: Suma de la complejidad de los métodos de la clase.

TCC: nro relativo de métodos que acceden a atributos de la clase medida.



Relación entre disarmonías

cd Relaciones

BrainClass

BrainMethod

DataClassFeatureEnvy

GodClass SignificantDuplication

RefusedParentBequest TraditionBreaker

ShortgunSurgeryIntensiveCoupling

DispersiveCoupling

has

useshas (parcial)

has has

is

hasis

uses has

is

is

has

has



ARMONÍA DE ENTIDADES

Reglas

1. Métodos y clases deben tener tamaños no excesivos. Cuál es la referencia ¿?Ver métricas simples de la triada.

2. Cada clase posee una interfaz que define su comportamiento al mundo exteriora través del conjunto de servicios que brinda. EQUIVALENTE AL CRITERIO deSegregación de interfaces

3. Los datos y las operaciones colaboran armónicamente en el interior de la clasea la cual pertenecen. PRINCIPIO DE PROGRAMACION ORIENTADA A OBJETOS.

Relación y formas de manifestación

cd Entity

God Class acceden a datos que no son propios y se valen de

otras clases que se convierten a proveedores de datos sin

ninguna funcional idad

Dis armonía asociada con el sobre

dimensionamiento (tamaño y complejidad)

de métodos y las clases que los contienen

FeatureEnvy

BrainMethodGodClass

BrainClass

DataClass

SignificantDuplication

Clases que realizan

varias tareas NO

cohesivas



Proceso de detección

cd DeteccionEntities

GodClass

BrainClass

BrainMethod SignificantDuplication

MetodosUsandoDatosExternos

ModeloDeClases

Detectar las clases con

Entity Disarmonías

Para cada clase

recorrer y analizar

· Clases que contienen una alta cantidad de desarmonías en sus métodos tienenprioridad.

· Clases que incluyen más de una desarmonía de tipo Entidad tienen prioridad.· Clases que son afectadas por otro tipo de desarmonías son tratadas primero

para encontrar también otros aspectos

Soluciones

1. Remover duplicaciones refactorizando (extraer método para intra clases yextraer super class para las inter clases).

2. Remover atributos temporales (aquellos usados en un solo método) yreemplazarlos por variables locales. Esto está orientado a reducir fuentes debaja cohesión como se manifiesta en las dis armonías BrainClass y GodClass.

3. Reducir la utilización de datos no propios, moviendo el método que los usa a laclase propietaria de los datos (FeatureEnvy); o mover los datos usados comoatributos a esta clase.

4. Extraer método hasta contar con métodos atómicos y cohesivos que eliminen alBrainMethod y por tanto a la BrainClass



Observaciones

Asemblers: caso tipico de FeatureEnvy. No se puede refactorizar ya que evita que elDTO conozca a DomainObject y así la capa de presentación.

Mappers: caso de FeatureEnvy, atributosAsString() a la clase proyecto ¿? -> SIII

DTO: caso típico de DataClass, que se puede refactorizar¿?

Por qué se usan y no se usan interfaces ¿? -> iCode NO, XRay -> SI

ARMONÍA DE COLABORACIÓN

Reglas

Son aquellas que definen buenas prácticas para lograr la funcionalidad pedida en basea la colaboración entre las instancias de determinadas clases.

· Bajo acoplamiento entre clases: a través de invocación de métodos con

o extensión (nro limitado de clases),

o intensidad (unidireccionales) y

o dispersión (mismo nivel abstracción, otro nivel, otro pakage) limitadas.Excesivo funout -> muy inestable, excesivo funin -> inmutable


custom Colaboracion

ShotgunSurgery

DispersiveCoupling

IntensiveCoupling

Alto acoplamiento con un nro

reducido de clases

Alto acoplamiento con un nro

al to de clases

Un método es invocado por

muchos métodos en muchas

clases

uses




· Para detectar Acoplamiento Intensivo se buscan clases cuyos métodos invocanun grupo de métodos de una única clase

· Para detectar Acoplamiento Dispersivo se buscan clases cuyos métodos invocanmétodos de un grupo de clases

· Para detectar ShotgunSurgery se buscan métodos llamados por muchos otrosmétodos de diferentes clases.

Soluciones

1. Definir servicios más complejos a partir de métodos cohesivos que implementenel servicio completo y que al invocarlos solo a ellos disminuyan el acoplamientointensivo.

2. Si el caso de acoplamiento dispersivo es un BrainMethod, luego ataque esa disarmonía.

3. Si es posible, mover funcionalidad invocada con el fin de reducir elacoplamiento dispersivo.

4. En los casos de acoplamiento mencionados la estrategia a usar está guiada por�Mover comportamiento lo más cerca de los datos� y �Eliminar el código denavegación� ya que es muy frecuente la mala asignación de responsabilidadesa las clases en cuestión.

5. Resolver la ShotgunSurgery tiene relación con la Law of Demeter: relacionarobjetos a partir del menor conocimiento posible de la estructura de relaciones ycomportamiento asociado a las instancias. Expresado más formalmente es:

un método M de un objeto O invocaría solamente métodos de lossiguientes tipos de objetos

� propios� de objetos parámetros� de objetos creados por él� de objetos tenidos por valor

La idea es evitar invocar métodos de objetos devueltos por otros métodos, yaque esto presupone un conocimiento profundo de las relaciones ycomportamiento. El tema es que estas relaciones pueden cambiar y la esenciadel problema es evitar cambiar cuando otros cambian.

Orservaciones

Ejemplo del proyecto EAMaven: en la figura se muestra las dependencias de diferentesy múltiples clases de la clase Registry que aparece a la izquierda del gráfico.



Otra vista con diferente visualizacion

Singletons tipo Registry y UnitofWork violan esta regla ¿?

Factory ¿?

ARMONÍA DE CLASIFICACIÓN

Reglas

· Las clases deben estar organizadas en jerarquías armómicas, ni demasiadoprofundas ni demasiado anchas.

· Cada clase debe estar en armonía con las clases de las cuales deriva. Esdecir, extender las interfaces, especializar el comportamiento y decrecer laabstracción.

· Las clases deben presentar armonía en la colaboración dentro de lajerarquía a la cual pertenecen. Es decir, las dependencias deben ser bottom� up y el comportamiento debe ser especializado (redefinido) más que sumarnuevos para implementar uno ya definido en las clases bases




cd Clasificacion

TraditionBreaker RefusedParentBequest

Las clases derivadas

rechazan el comportamiento

heredado (legado)

Las clases derivadas extienden masivamente la

interfaz de la clase base con servicios que no

caracterizan al concepto modelado por la clase

Se manifiestan en general cuando se uti liza el

mecanismo de herencia como reuso de codigo en

lugar de expresar subtipos

is


· Las clases derivadas no redefinen métodos de su clase base

· Las clases además tienen cierto tamaño, medido en número de métodos ycomplejidad (Refused)

· El tamaño de la interfaz pública de la clase hija ha crecido mucho y sutamaño y complejidad son altos y la clase base tiene una ciertafuncionalidad definida (Breaker)

Soluciones

Hay tres casos de RefusedParentBequest

· Falsa herencia - > las clases no tienen una relación directa de herencia sinocon una superbase, luego extraer la clase de la jerarquía

· Legado Irrelevante: las clases derivadas no utilizan los métodos protected nilos redefinen - > hacerlos privados en la base

· Legado Discriminatorio -> la clase base tiene un gran número de clasesderivadas y ofrece un legado que tiene sentido solo para algunas y no paraotras. La figura muestra una posible solución, que de ser aplicable denotaque la clase base fue usada para modelar más de un concepto y no unoúnico.



Hay cuatro casos de TraditionalBreaker

· Tradición Irrelevante: excesivos métodos públicos, deberían ser privados oprotected.

· Tradición negada: la clase base no incluye un conjunto de servicios que sonimplementados en casi todas las hijas.

· Subclases con Doble Intencionalidad: clases hijas que implementanfuncionalidad completamente diferente a la expresada pro la interfaz de labase. Se debe extraer esta funcionalidad a otra clase fuera de la jerarquía.

· Subclases Mal Relacionadas: las interfaces de la hija y la base no tienennada que ver.

· No alcanza con analizar clases asiladas, se deben analizar jerarquías. ¿Cómose agrupan las clases afectadas y cuáles tienen prioridad?

� Tienen prioridad las jerarquías con mayor número de clases afectadas.

� Las jerarquías con más niveles de profundidad afectados es mayor.

� Las jerarquías con mayor diversidad de disarmonías tienen prioridad.

� Las jerarquías con otro tipo de disarmonías tienen prioridad.

La figura muestra la estrategia seguida a efectos de extraer estos tipos de disarmonías.



cd Clasificacion

DeteccionJ erarquiaAfectada

Existe Duplicacion

Existe Refused Parent Bequest

Existe Tradition Breaker

Duplicacion aparece en casi

todas las sibl ing clases

Resolver cada caso de

Refused Parent Bequest

Resolver cada caso de

Tradicion Breaker

Extraer aspectos

comunes a clase base

(Template Method)

Extraer aspectos

comunes a otras clases y

usar delegacion[NO]

[NO]

[NO]

[SI]

[SI]

[SI]

[SI]

[NO]

Orservaciones

Qué herramienta de visualización los muestra ¿?

REVISIÓN DE CÓDIGO CON AYUDA DE MÉTRICASUtilización de las métrica analizadas como punto de partida y guía de la revisión.



REFERENCIASObject-Oriented Metrics in Practice - Using Software Metrics to Characterize, Evaluate,and Improve the Design of Object-Oriented Systems; Michele Lanza, Radu Marinescu,Springer, 2006.


metricas de software -...

Documents