�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
�capacitación y guía para el desarrollo de software�
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
Relación y formas de manifestación .......................................................................20
Proceso de detección...............................................................................................21
Métricas de Software aplicadas al código 2
�capacitación y guía para el desarrollo de software�
Soluciones.................................................................................................................21
Orservaciones...........................................................................................................21
ARMONÍA DE CLASIFICACIÓN.......................................................................................................23
Reglas.......................................................................................................................23
Relación y formas de manifestación .......................................................................24
Proceso de detección...............................................................................................24
Soluciones.................................................................................................................24
Orservaciones...........................................................................................................26
REVISIÓN DE CÓDIGO CON AYUDA DE MÉTRICAS...............................................................................26
REFERENCIAS.......................................................................................................................27
Métricas de Software aplicadas al código 3
�capacitación y guía para el desarrollo de software�
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]
Métricas de Software aplicadas al código 4
�capacitación y guía para el desarrollo de software�
Valores de referencia
Métricas de Software aplicadas al código 5
�capacitación y guía para el desarrollo de software�
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
�capacitación y guía para el desarrollo de software�
CALLS / NOM: cantidad de llamadas entrantes dividida la cantidad de metodos
Métricas de Software aplicadas al código 7
�capacitación y guía para el desarrollo de software�
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
Métricas de Software aplicadas al código 8
�capacitación y guía para el desarrollo de software�
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.
Métricas de Software aplicadas al código 9
�capacitación y guía para el desarrollo de software�
Ejemplo del proyecto EAMaven antes de las mejoras
Métricas de Software aplicadas al código 10
�capacitación y guía para el desarrollo de software�
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.
Métricas de Software aplicadas al código 11
�capacitación y guía para el desarrollo de software�
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
Métricas de Software aplicadas al código 12
�capacitación y guía para el desarrollo de software�
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.
Métricas de Software aplicadas al código 13
�capacitación y guía para el desarrollo de software�
Ejemplo: clase Proyecto del proyecto EAMaven
Métricas de Software aplicadas al código 14
�capacitación y guía para el desarrollo de software�
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
Métricas de Software aplicadas al código 15
�capacitación y guía para el desarrollo de software�
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.
Métricas de Software aplicadas al código 16
�capacitación y guía para el desarrollo de software�
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
Métricas de Software aplicadas al código 17
�capacitación y guía para el desarrollo de software�
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
Métricas de Software aplicadas al código 18
�capacitación y guía para el desarrollo de software�
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
Métricas de Software aplicadas al código 19
�capacitación y guía para el desarrollo de software�
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
Relación y formas de manifestación
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
Métricas de Software aplicadas al código 20
�capacitación y guía para el desarrollo de software�
Proceso de detección
· 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.
Métricas de Software aplicadas al código 21
�capacitación y guía para el desarrollo de software�
Métricas de Software aplicadas al código 22
�capacitación y guía para el desarrollo de software�
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
Métricas de Software aplicadas al código 23
�capacitación y guía para el desarrollo de software�
Relación y formas de manifestación
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
Proceso de detección
· 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.
Métricas de Software aplicadas al código 24
�capacitación y guía para el desarrollo de software�
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.
Métricas de Software aplicadas al código 25
�capacitación y guía para el desarrollo de software�
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.
Métricas de Software aplicadas al código 26
�capacitación y guía para el desarrollo de software�
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.
Métricas de Software aplicadas al código 27
Top Related