jueves, 28 de junio de 2012

Métricas del diseño.

 
1.   Cantidad de clases desarrolladas.
•    Aspecto a medir: Tamaño.
•   Objetivo: definir una medida que permita dimensionar el producto.
•   Comentario: se usa como marco de referencia de otras métricas. Por ejemplo valorar la cantidad de jerarquías de herencia con respecto al total de clases.
•   Clases a considerar: Toda clase desarrollada, extendida, usada, que es instanciada en el sistema, clases no instanciadas pero definidas en el sistema.
•  Clases a no considerar: Clases cuyos padres son externos al sistema, usada para definir una nueva clase, por extensión. Tipos primitivos de datos, como ser Integer, Carácter, etc.

2.   Cantidad de clases externas especializadas.

•    Aspecto a medir: Reutilización.
•  Objetivo: Determinar la cantidad de clases externas al sistema que son reutilizadas por medio del mecanismo de herencia.
•  Comentario: se identifican las clases externas que el propio sistema está especializando, reutilizando. Es significativo mostrar la cantidad de clases reutilizadas por librería de clases.
•   Forma de cálculo: se cuentan las clases externas que tienen una clase hija que pertenece al alcance de medición.
•   Clases a considerar: Toda clase externa al alcance de medición que es extendida en el producto.
•    Clases a no considerar: Tipos primitivos de datos, como ser Integer, Carácter, etc. Clases que pertenecen al alcance de medición y tienen subclases que pertenecen al alcance de medición. Clases que pertenecen al alcance de medición y son padres de clases externas.

3.    Promedio de statements por método de una clase.

•    Aspecto a medir: Granularidad de métodos.
•   Objetivo: Determinar si existe una cantidad excesiva de statements en los métodos que componen una clase.
•    Comentario: Se considera que una cantidad excesiva de statements en un método pueden ser la consecuencia de una inadecuada factorización de los métodos.
•  Forma de cálculo: Sumatoria de la cantidad de statements en todos los métodos de la clase, divido el número total de métodos.
• Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
•   Clases a no considerar: Clases externas al sistema a medir, es decir clases importadas o extendidas.

4.   Cantidad de métodos de interface por clase
.
•    Aspecto a medir: Responsabilidad pública.
•    Objetivo: Medir los contratos asumidos por una clase.
•  Comentario: Esta métrica permite detectar clases que posean un exceso de responsabilidad pública o carencia de la misma. Una visualización rápida por medio de la cantidad de métodos públicos nos permite apreciar la distribución de responsabilidades del sistema y focalizar la atención en la clase que presenta valores llamativos.
•   Forma de cálculo: Se cuentan los métodos de interface que tiene la clase.
•  Métodos a considerar: Se cuentan los métodos de interface propios de la clase y métodos de interface heredados de la clase padre.
•  Métodos a no considerar: Los métodos que no pertenecen a la interface de la clase.
•   Clases a considerar: Toda clase declarada dentro del alcance de medición.
•   Clases a no considerar: Clases externas al sistema a medir, clases importadas o extendidas.

5.    Cantidad de colaboradores por clase.

•    Aspecto a medir: Colaboración - Agregación.
•   Objetivo: Medir el uso de agregación en el diseño del sistema.
•    Comentarios: La agregación de una clase se determina por el número de colaboradores habituales que la clase utiliza. La presencia de dichos colaboradores define una “parsing tool” asociación de agregación o conocimiento entre la clase dueña y las clases referenciadas.
•    Forma de cálculo: se cuentan los objetos colaboradores declarados estáticamente en la definición de la clase y que pertenecen a tipos de datos distintos a la clase considerada.
•  Objetos a considerar: Objetos definidos en la clase a través de una variable de instancia a la cual se le solicita colaboración, por medio del envío de un mensaje en algún método de la clase. Asimismo, se deben contabilizar los objetos declarados en la superclase, si la hubiera, e invocados en la clase corriente. Los objetos cuyas clases están declaradas dentro del alcance de medición (internos) y los objetos externos.
•  Objetos a no considerar: Estos objetos pueden variar dependiendo del lenguaje de programación implementado. Sin embargo, a continuación se detallan algunos objetos que no deberían ser considerados colaboradores, porque están implícitos en la mayoría de las implementaciones. Tipos de datos primitivos, objetos que representan a tipos primitivos de datos y objetos comunes.
• Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
• Clases a no considerar: Clases externas al sistema a medir, es decir clases importadas o extendidas.

6.   Cantidad de colaboradores externos por clase
.
•    Aspecto a medir: Reutilización – Agregación.
•   Objetivo: determinar el uso de colaboradores externos en el sistema. Esta métrica completa el planteo de la medición de reutilización.
•  Comentarios: la agregación realizada con clases externas al sistema es otra forma posible de reutilizar clases.
•    Forma de cálculo: se cuentan los objetos colaboradores externos declarados estáticamente en la definición de la clase y que pertenecen a tipos de datos distintos a la clase considerada. “Design Patterns” pag.22-23, Erich Gamma. Una colaborador definido en forma estática en una clase, significa que existe una variable de instancia del tipo del colaborador.
•   Objetos a considerar: Los objetos cuyas clases no están declaradas dentro del alcance de medición (externos). Objetos definidos en la clase a través de una variable de instancia a la cual se le solicita colaboración, por medio del envío de un mensaje en algún método de la clase. Asimismo, se deben contabilizar los objetos declarados en la superclase, si la hubiera, e invocados en la clase corriente.
•  Objetos a no considerar: Objetos internos. Estos objetos pueden variar dependiendo del lenguaje de programación implementado. Sin embargo, a  continuación se detallan algunos objetos que no deberían ser considerados colaboradores, porque están implícitos en la mayoría de las implementaciones. Tipos de datos primitivos, objetos que representan a tipos primitivos de datos y objetos comunes. Ej. Integer, String, Byte, Char, int, char, short, flota, etc.
• Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
•  Clases a no considerar: Clases externas al sistema a medir, es decir clases importadas o extendidas.

7.   Cantidad de Mensajes Polimórficos.

•    Aspecto a medir: Polimorfismo.
•    Objetivo: medir el uso de polimorfismo en la invocación de los métodos.
•  Comentarios: Se considera mensajes enviados a tipos internos y externos al alcance de medición.
•   Forma de Cálculo: Se cuentan los mensajes polimórficos enviados a tipos internos y externos al alcance de medición.

8.    Cantidad de jerarquías de clases desarrolladas.

•    Aspecto a medir: Herencia.
•    Objetivo: medir el uso de herencia.
•  Comentarios: se define esta métrica como valor de referencia, útil para la valoración de los resultados obtenidos en otras métricas. Por ejemplo, valores obtenidos en la medición de cantidad de mensajes polimórficos.
•    Forma de Cálculo: se cuentan las jerarquías de clases propias implementadas en el sistema.
•  Jerarquías a considerar: jerarquías donde la raíz pertenece al alcance de medición.
•    Jerarquías a no considerar: jerarquías donde la raíz no pertenece al alcance de medición
•    Clases a considerar: Toda clase, que pertenezca a una jerarquía de clases declarada dentro del alcance de medición.
•   Clases a no considerar: Clases internas al alcance de medición, que heredan de una “superclase”, que esté fuera del alcance de medición.

9.  Cantidad de jerarquías extendidas de clases externas.

•    Aspecto a medir: Herencia.
•    Objetivo: Medir el uso de herencia.
• Comentarios: Puede suceder que algunas de las jerarquías que sean principales a la aplicación tengan una raíz externa.
•    Forma de Cálculo: se cuentan las jerarquías de clases, que tengan una clase padre externa, y que al menos tenga una clase hija que pertenezca al alcance de medición, que a su vez sea padre de una clase que pertenezca al alcance de medición.
•  Jerarquías a considerar: jerarquías donde la raíz no pertenece al alcance de medición.
•  Jerarquías a no considerar: jerarquías donde la raíz pertenece al alcance de medición. Jerarquía donde la raíz no pertenece al alcance de medición y tiene un padre externo, que tiene una hija perteneciente al alcance de medición que no es padre de una clase que pertenece al alcance de medición.

10.   Cantidad de niveles de especialización por jerarquía de clases
.
•    Aspecto a medir: Herencia.
•   Objetivo: Determinar la especialización alcanzada por la clase “raíz” en cada jerarquía de clases.
•   Comentario: En el capítulo anterior se citan trabajos que reportan dificultades en los niveles bajos de especialización. Se plantea esta métrica para focalizar la atención en jerarquías complejas.
•  Forma de cálculo: Primero se determina la rama de subclases con mayor profundidad. La cantidad de niveles de la jerarquía es igual a la cantidad de clases de la rama de mayor profundidad menos una clase.
•  Jerarquías a considerar: toda jerarquía donde la clase raíz pertenezca al alcance de medición.
•   Jerarquías a no considerar: familias de clases externas al sistema, ramas de familias de clases externas, clases que pertenecen a la librería del lenguaje utilizado.
.
11.  Cantidad de niveles agregados a jerarquías donde la raíz es externa.
•    Aspecto a medir: Herencia.
•   Objetivo: Determinar la especialización alcanzada de una clase externa en el alcance de medición.
•    Comentario: En el capítulo anterior se citan trabajos que reportan dificultades en los niveles bajos de especialización. Se plantea esta métrica para apuntar la atención a jerarquías complejas. Es la que tiene mayor cantidad de niveles.
•    Forma de cálculo: A partir de la clase externa al alcance de medición, que es padre de al menos una clase que pertenece al alcance de medición, determinar la rama de subclases que pertenece al alcance de medición con mayor profundidad (la cantidad de niveles se cuentan a partir del padre externo). Para esta rama, la cantidad de niveles agregados es igual a la cantidad de clases de la rama de mayor profundidad menos una clase.
•  Jerarquías a considerar: toda jerarquía donde la clase raíz es externa, donde existe un padre externo, y en el alcance de medición la clase hija es padre de una clase que pertenece al alcance de medición.
• Jerarquías a no considerar: jerarquías donde existe un padre externo, y en el alcance de medición la clase hija no tiene hijos.

12.  Cantidad de Clases Raíz no Abstractas.

•    Aspecto a medir: Herencia.
•   Objetivo: identificar las jerarquías que no tienen una clase raíz abstracta.
•    Comentario: Declarar la clase raíz como clase abstracta, implica que cada subclase debe proveer una implementación completa de los métodos definidos en la clase raíz. De esta forma se asegura el uso de polimorfismo. Gamma et al. [1995] dice que facilita “programar para una interfase, y no para una implementación”. Liskov asegura el uso de polimorfismo, si se programa para el tipo abstracto.
•   Forma de cálculo: se cuentan las clases raíz que no son abstractas.
•  Clases a considerar: Clases que pertenecen al alcance de medición, y son raíz de una jerarquía, que pertenece al alcance de medición.
• Clases que no deben considerarse: Clases que pertenezcan a la librería del lenguaje de programación. Cualquier clase externa que tenga subclases que pertenecen al alcance de medición.

13.  Porcentaje de Métodos Reemplazados en una Jerarquía.

•    Aspecto a medir: Herencia.
•  Objetivo: Determinar si la cantidad de métodos sobrescritos es excesiva.
•   Comentarios: El porcentaje de métodos heredados que son remplazados en cada subclase de una jerarquía de clases propia, da una idea del uso o abuso de la sobre-escritura. El problema principal de la redefinición de métodos (overriden) se centra en aquellos casos donde la firma se mantienen, pero la implementación es remplazada completamente. Como consecuencia, se rehace el comportamiento del método y se descarta completamente el comportamiento heredado de la clase padre. La jerarquía que tiene un porcentaje alto de métodos redefinidos detiene el mecanismo de herencia, que la clase padre aporta en la subclase.
•    Forma de cálculo: PMRJ = (CMR / CMH) * 100.
•    CMR = Cantidad de métodos remplazados.
•    CMH = Cantidad de métodos heredados.
•  Clases a considerar: subclases de una jerarquía de herencia definida en el alcance de medición.
•    Clases a no considerar: Clases externas a la jerarquía de herencia. Subclases, que pertenecen a la jerarquía de herencia y que hereden de una clase definida abstracta.

14. Porcentaje de Métodos Reemplazados en Jerarquías donde la raíz es externa.

•    Aspecto a medir: Herencia.
•  Objetivo: determinar si se esta usando bien el mecanismo de herencia cuando se esta rehusando clases.
•  Comentarios: no tiene sentido reutilizar una clase a la cual se le sobrescriben un alto porcentaje de métodos.
•    Forma de cálculo: PMRJ = (CMR / CMH) * 100.
•    CMR = Cantidad de métodos remplazados.
•    CMH = Cantidad de métodos heredados.
• Clases a considerar: subclases de una jerarquía de herencia donde la raíz es externo y tiene una clase hija en el alcance de medición que a su vez tiene una hija.
•  Clases a no considerar: subclases de una jerarquía de herencia donde la raíz es externo y tiene una clase hija en el alcance de medición que no tiene hijos. Subclases, que pertenecen a la jerarquía de herencia de raíz externo y que hereden de una clase definida abstracta.

No hay comentarios:

Publicar un comentario