Este documento presenta diferentes métricas para evaluar sistemas orientados a objetos y componentes de software convencional. Describe métricas basadas en clases como profundidad de herencia, número de descendientes y acoplamiento entre clases. También presenta métricas propuestas por Lorenz y Kidd como tamaño de clase, número de operaciones redefinidas y añadidas. Finalmente, cubre métricas a nivel de componentes como cohesión, acoplamiento y complejidad.

1. METRICAS ORIENTADAS A CLASES.
Las métricasCK.Uno de los conjuntosde métricasOO más ampliamente referenciados,ha
sidoel propuestoporChidamberyKemerer.Normalmenteconocidascomolaserie de métricasCK,
los autores han propuesto seis métricas basadas en clases para sistemas OO.
Árbol de profundidadde herencia(APH). Esta métricase define como“lamáximalongitud
del nodoa laraíz del árbol”.ConreferenciaalaFigura1, el valordel APHpara la jerarquíade clases
mostradaesde 4. A medidaque el APHcrece,esposible que clasesde másbajosnivelesheredarán
muchos métodos.
Estoconllevadificultadespotenciales,cuandoseintentapredecirelcomportamientodeuna
clase. Una jerarquía de clases profunda (el APH es largo) también conduce a una complejidad de
diseño mayor. Por el lado positivo,los valores APH grandes implican un gran número de métodos
que se reutilizarán.
Númerode descendientes(NDD). Lassubclasesinmediatamente subordinadasauna clase
en la jerarquía de clases se denominan sus descendientes. Con referencia a la Figura 1, la clase C2
tiene tres descendientes (subclases C21, C22 y C23) . A medida que el número de descendientes
crece,lareutilizaciónse incrementa,peroademásesciertoque cuandoelNDDcrece,laabstracción
representada por la clase predecesora puede diluirse. Esto significa que existe una posibilidad de
que algunos descendientes no sean miembros, realmente apropiados, de la clase predecesora. A
medida que el NDD crece, la cantidad de pruebas (requeridas para ejercitar cada descendiente en
su contexto operativo) se incrementará también.
Acoplamientoentre clasesobjeto (ACO). En esencia,ACOes el númerode colaboraciones
listadasparaunaclase,enlatarjetaíndice CRC(Clase ResponsabilidadColaboración).A medidaque
ACO se incrementa, es más probable que el grado de reutilización de una clase decrezca. Valores

2. altos de ACO además complican las modificaciones y las pruebas, que se producen cuando se
realizanmodificaciones.Engeneral, losvaloresde ACOparacadaclase debenmantenersetanbajos
como sea razonable.Esto esconsistente conla regla general para reducirel acoplamiento,parael
software convencional.
Respuesta para una clase (RPC). El conjunto de respuesta de una clase es “una serie de
métodos que pueden potencialmente ser ejecutados, en respuesta a un mensaje recibido por un
objeto, en la clase”. RPC se define como el número de métodos en el conjunto de respuesta. A
medida que la RPC aumenta, el esfuerzorequeridopara la comprobación tambiénse incrementa,
ya que la secuencia de comprobación se incrementa también. Así mismo, se dice que, así como la
RPC aumenta, la complejidad del diseño global de la clase se incrementa.
Carencia de cohesiónen los métodos (CCM). Cada métododentrode una clase,C, accede
a unoo más atributos(tambiénllamadosvariablesde instancia)CCMesel númerode métodosque
accede a uno o más de los mismos atributos. Si no existenmétodos que accedan a los mismos
atributos, entonces CCM= 0.
Para ilustrarel caso enel que CCMes diferentede 0,considéreseunaclase con6 métodos.
Cuatro de los métodos tienen uno o más atributos en común (es decir, acceden a atributos
comunes).De estamanera,CCM=4. Si CCMesalto,losmétodosdebenacoplarseaotro,pormedio
de los atributos. Esto incrementa la complejidad del diseñode clases.En general,los valores altos
paraCCMimplicanque laclase debediseñarse mejordescomponiendoendosomásclasesdistintas.
Aunque existan casos en los que un valor alto para CCM es justificable, es deseable mantener la
cohesión alta, es decir, mantener CCMbajo.
MÉTRICAS OO (LORENZ Y KIDD).
Métricas propuestas por Lorenz y Kidd. En su libro sobre métricas OO, Lorenz y Kidd
separan las métricas basadas en clases en cuatro amplias categorías: tamaño, herencia, valores
internos y valores externos. Las métricas orientadas al tamaño para las clases OO se centran en el
recuento de atributos y operaciones para cada clase individual, y los valores promedio para el
sistema OO como un todo. Las métricas basadas en la herencia se centran en la forma en que las
operaciones se reutilizan en la jerarquía de clases. Las métricas para valores internos de clase
examinanlacohesiónylosaspectosorientadosal código;lasmétricasorientadasavaloresexternos,
examinan el acoplamiento y la reutilización. A continuación, una muestra de métricas propuestas
por Lorenz y Kidd.
Primera. Tamaño de clase (TC). El tamaño general de una clase puede medirse
determinando las siguientes medidas:
 El total de operaciones (operaciones tanto heredadas como privadas de la
instancia), que se encapsulan dentro de la clase.
 El númerode atributos(atributostanto heredadoscomoprivadosde la instancia),
encapsulados por la clase.
La métricaMPCpropuestaporChidamberyKemererestambiénunamétricaponderadadel
tamañode clase.Comose indicóconanterioridad,valoresgrandesparaTCindicanquelaclase debe

3. tener bastante responsabilidad. Esto reducirá la reutilización de la clase y complicará la
implementaciónylaspruebas.En general,operacionesyatributosheredadosopúblicosdebenser
ponderados con mayor importancia, cuando se determina el tamaño de clase. Operaciones y
atributos privados, permiten la especialización y son más propios del diseño.
También se pueden calcular los promedios para el número de atributos y operaciones de
clase.Cuanto menorsea el valor promediopara el tamaño, será más posible que lasclasesdentro
del sistema puedan reutilizarse.
Segunda. Número de operaciones redefinidas para una subclase (NOR). Existen casos en
que unasubclase reemplazaunaoperaciónheredadadesusuperclase porunaversiónespecializada
para su propiouso. A estose le llamaredefinición.Losvaloresgrandesparael NOR, generalmente
indican un problema de diseño. Tal como indican Lorenz y Kidd:
“Dado que una subclase debe serla especializaciónde sussuperclases,deben,sobre todo,
extender los servicios (operaciones) de las superclases. Esto debe resultar en nuevos nombresde
métodos únicos”.
Si el NOR esgrande,el diseñadorhavioladolaabstracción representadaporlasuperclase.
Esto provoca una débil jerarquía de clases y un software OO, que puede ser difícil de probar y
modificar.
Tercera. Número de operaciones añadidas por una subclase (NOA). Las subclases se
especializan añadiendo operaciones y atributos privados. A medida que el valor NOA se
incrementa, la subclase se aleja de la abstracción representada por la superclase. En
general, a medida que la profundidad de la jerarquía de clases incrementa (APH se vuelve
grande), el valor para NOA a niveles más bajos en la jerarquía debería disminuir.
Cuarta. Índice de especialización (IES). El índice de especialización proporciona una
indicación aproximada del grado de especialización, para cada una de las subclases en un
sistema OO. La especialización se puede alcanzar añadiendo o eliminando operaciones,
pero también redefiniendo.
IE = [ NOR * nivel ] / Mtotal
Donde: nivel corresponde al nivel en la jerarquía de clases en que reside la clase, y
Mtotal es el número total de métodos de la clase. Cuanto más elevado sea el valor de IE,
más probable será que la jerarquía de clases tenga clases que no se ajusten a la abstracción
de la superclase.
MÉTRICAS DE DISEÑO A NIVEL DE COMPONENTES DE SOFTWARE CONVENCIONAL
Las métricasde diseñoanivelde componentesse concentranenlascaracterísticasinternas
de los componentes del software e incluyen medidas de las «3Cs» la cohesión, acoplamiento y
complejidaddelmódulo.Estastresmedidaspuedenayudaral desarrolladorde software ajuzgarla
calidad de un diseño a nivel de los componentes.

4. Las métricaspresentadasenestasecciónsonde cajablancaen el sentidode que requieren
conocimiento del trabajo interno del módulo en cuestión. Las métricas de diseño de los
componentesse puedenaplicarunavezque se ha desarrolladoundiseñoprocedimental.También
se pueden retrasar hasta tener disponible el código fuente.
Métricas de Cohesión: Bieman y Ott definen una colección de métricas que proporcionan
unaindicaciónde lacohesióndeunmódulo.Lasmétricassedefinenconcincoconceptosymedidas:
 Porción de datos. Dicho simplemente,unaporciónde datoses una marcha atrás a
través de un módulo que busca valores de datos que afectan a la localización de
móduloenel que empezólamarchaatrás.Deberíaresaltarse quese puedendefinir
tanto porcionesde programas(que se centranen enunciadosycondiciones) como
porciones de datos.
 Muestras (tokens) de datos. Las variables definidas para un módulo pueden
definirse como muestras de datos para el módulo.
 Señales de unión. El conjunto de muestras de datos que se encuentran en una o
más porciones de datos.
 Señales de superunión. La muestras de datos comunes a todas las porciones de
datos de un módulo.
 Pegajosidad. La pegajosidad relativa de una muestra de unión es directamente
proporcional al número de porciones de datos que liga.
Métricas de acoplamiento: El acoplamiento de módulo proporciona una indicación de la
conectividad» de un módulo con otros módulos, datos globales y el entorno exterior.
Dhama ha propuesto una métrica para el acoplamiento del módulo que combina el
acoplamiento de flujo de datos y de control, acoplamiento global y acoplamiento de entorno.Las
medidas necesarias para calcular el acoplamiento de módulo se definen en términos de cada uno
de los tres tipos de acoplamiento apuntados anteriormente.
Para el acoplamiento de flujo de datos y de control:
di = número de parámetros de datos de entrada
ci = número de parámetros de control de entrada
do = número de parámetros de datos de salida
co = número de parámetros de control de salida
Para el acoplamiento global:
g, = número de variables globales usadas como datos
g, = número de variables globales usadas como control
Para el acoplamiento de entorno:

5. w = número de módulos llamados (expansión)
r = número de módulos que llaman al módulo en cuestión
Métricas de Complejidad: Se pueden calcular una variedad de métricas del software para
determinar la complejidaddel flujo de control del programa. Muchas de éstas se basan en una
representacióndenominada grafode flujo.Un grafo es una representacióncompuestade nodosy
enlaces(tambiéndenominadosaristas).Cuandose dirigenlosenlaces(aristas),el grafode flujoes
un grafo dirigido.
McCabe identifica un número importante de usos para las métricas de complejidad:
Las métricasde complejidadpuedenemplearse parapredecir lainformacióncríticasobre la
fiabilidad y mantenimiento de sistemas software de análisis automáticos de código fuente (o
información de diseño procedimental). Las métricas de complejidad también realimentan la
información durante el proyecto de software para ayudar a controlar la [actividad del diseño].
Durante las pruebas y el mantenimiento, proporcionan una detallada información sobre los
módulos software para ayudar a resaltar las áreas de inestabilidad potencial.
McCabe también defiende que la complejidad ciclomática puede emplearse para
proporcionar una indicación cuantitativa del tamaño máximo del módulo. Recogiendo datos de
varios proyectos de programación reales, ha averiguado que una complejidadciclomática de 10
parece ser el límite práctico superior para el tamaño de un módulo. Cuando la complejidad
ciclomática de los módulos excedían ese valor, resultaba extremadamente difícil probar
adecuadamente el módulo.
Referencias Bibliográficas
Métricas para Sistemas Orientados a Objetos
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo6.pdf
Métodos y herramientas Orientados a Objetos a la Calidad del Software
http://www.frre.utn.edu.ar/gics/clean/files/get/item/6425
Ingeniería de Software III
http://ing-software3.blogspot.com/2012/11/metricas-del-modelo-del-diseno.html