Ariel Henríquez Renzo Stanley

Ing. Software Avanzada

Tres aristas importantes del desarrollo OO:

OOA: Object-oriented analysis OOD: Object-oriented design OOP: Object-oriented programming

Conceptos y constructos Clase (abstracta, concreta) Objeto Mensajes Herencia Polimorfismo Etc.

En general, la medición persigue tres objetivos fundamentales (Fenton y Pfleeger, 1997):

Entender qué ocurre durante el desarrollo y el mantenimiento

Controlar qué es lo que ocurre en nuestros proyectos

Mejorar nuestros procesos y nuestros productos

Métricas de Lorenz y reglas generales

En 1993 Lorenz, basado en su experiencia en desarrollo de software OO, propuso 11 métricas.

La mayoría están relacionadas con el diseño e implementación OO.

Métrica Reglas generales y comentarios

1. Tamaño promedio del Método (LOC) Debería ser menor a 24 LOC para C++

2. Tamaño promedio de métodos por clase Menor a 20. Promedios grandes indican mayor responsabilidad en pocas clases

3. Número promedio de instancias por clase Debería ser menor a 6, ya que muchas instancias indican que la clase está haciendo más de lo que debería.

4. Nivel de jerarquía de clases Menor a 6 empezando de clases del framework o de la clase raíz.

5. Número de subsistemas/subsistemas relacionados

Debería ser menor a 6 según la métrica.

6. Número de clases / clases relacionadas en cada

subsistema

Debería ser relativamente alto. Este ítem hace referencia a la alta cohesión de las clases en un mismo subsistema. Si las clases interactúan poco con otras dentro del mismo subsistema, será más fácil utilizarlas en otro subsistema.

7. Uso de variables de instancia Indica si la clase debería ser dividida en otras

8. Número promedio de líneas comentadas (por método)

En lo posible que sea mayor a 1.

9. Número de problemas reportados por clase Obviamente, debería ser bajo

10. Número de veces en que la clase es reusada Si una clase no está siendo reusada en otras aplicaciones (especialmente una clase abstracta), significa que debería ser rediseñada.

11. Número de clases y métodos (creados) Debe ocurrir en una tasa constante presente en la mayor parte del proceso de desarrollo. Si esto no ocurre, probablemente se esté haciendo un desarrollo incremental en vez de realizar un diseño iterativo verdadero.

• Propuestas en 1994 por Chidamber y Kemerer.

• Son métricas enfocadas al Diseño y Complejidad.

Métodos Cargados por Clase (WMC): Corresponde a la suma de la complejidad de los métodos, esto se hace midiendo la “cyclomatic complexity”.

Puede considerarse como el número de métodos definidos en cada clase

Profundidad del Árbol de Herencias(DIT): Es el largo de la máxima ruta de jerarquías desde una clase hoja a la clase raíz.

Número de Hijos de una Clase (NOC): Es el número de Subclases inmediatas de una Jerarquía de clases.

Acoplamiento entre Objetos de Clase (CBO): Un objeto se acopla a otro si invoca funciones miembro o instancia variables.

CBO es el número de clases con el que está acoplada una clase dada.

Respuesta para una Clase (RFC): Es el número de métodos que pueden ser ejecutados desde una clase en respuesta a un mensaje recibido.

RFC es el número de métodos locales más el número de métodos invocados por estos métodos.

Falta de Cohesión en Métodos (LCOM): Se define como el número de pares de métodos en una clase que no tienen por lo menos un campo en común menos el número de pares de métodos en la clase que comparten por lo menos un campo. Cuando este valor es negativo, el valor métrico se fija a 0.

Estudio en la Universidad de Maryland (1996). Las seis Métricas son Relativamente

Independientes. Falta de uso de la Herencia. (Bajos Valores

de DIT y NOC) El LCOM careció de poder para predecir

clases defectuosas. DIT, RFC, NOC, y CBO están

correlacionadas con las clases defectuosas

Estas Métricas OO son superiores a las métricas de código en la predicción de clases defectuosas.

Chidamber, Darcy y Kemerer (1998): Bajos valores en Profundidad del Árbol

de Herencias. Tres métricas: Métodos Cargados por

Clase, Respuesta para una Clase y Acoplamiento entre objetos de clase, están altamente relacionadas. (cercano a 0.85)

Criterio Porcentual para marcar Clases con Potenciales Errores.

Rosenberg, Stapko y Gallo (1999): Criterio para marcar clases con potenciales problemas. Respuesta para una Clase (RFC)> 100 Respuesta para una Clase (RFC)> 5

veces el número de métodos en la clase. Acoplamiento entre Objetos de Clase

(CBO)>5 Métodos Cargados por Clase

(WMC)>100 Número de Métodos > 40

Miden grado de producción o avance de cada individuo

Algunas métricas de este tipo son: LOC por hora #clases por PM (persona-mes) #clases por PD (persona-día) Promedio de clases por desarrollador

esfuerzo

salidadadproductivi

Salida

Calidad

Recursos Tiempo

Dimensiones del concepto de productividad

Programación Procedural: Defectos por KLOC, Defectos por Punto de Función, Tiempo medio en Fallar, etc.

Programación Orientada a Objetos: Calidad se mide en Defectos por Clase

Métricas para aplicar al proceso de Testing.

Proceso de Testing sigue una “curva S”

Defectos Encontrados a través del tiempo.

Defectos Acumulados a través del tiempo.

Número de problemas Críticos a través del tiempo.

Número de caídas de sistema como medida de estabilidad.

Paradigma del esfuerzo/resultado para interpretar métricas en el proceso y administración de calidad.

Resumen y conclusiones generales

Como todo proceso productivo, el desarrollo de software OO se rige por la curva de aprendizaje.

Debe existir educación formal.

NO enfocarse sólo en el lenguaje de programación.

Hab

ilida

des

Dom

inio

Esp

ecífi

co

Habilidades OO

III(Experto en el dominio antes

de la transición a OO)

IV(Experto con habilidades

en su dominio y OO)

I(Principiante)

II(Habilidades OO)

Tipología del dominio de conocimiento y habilidades de OO.

Habilidades de OO distribuidas sobre las fases del ciclo de desarrollo (distribución de expertos)

La robustez y la integración de las herramientas que se utilicen en el desarrollo son tan importantes como los lenguajes de programación y los métodos específicos que se usen.

Es importante el establecimiento de metas mensuales (checkpoints) que se indiquen en la calendarización del proyecto.

Las medidas deben ser decididas al principio.

Todos deben conocer las medidas.

El estado del proyecto debe divulgarse.

Hacer buenas clases reusables es un trabajo muy duro.

Tecnologías Orientadas a Objeto NO son sinónimo (en la práctica) de reusamiento de código.

Del punto de vista del desarrollo de un producto: Conflicto de intereses entre ciclo de vida de desarrollo y la construcción de clases reusables.

Principal preocupación en la Mayoría de los Proyectos OO durante el desarrollo.

Causas de los Problemas de Performance: Equipo sin experiencia que modulariza

demasiado. Asignaciones de memoria dinámica no se usan

apropiadamente. Tecnología OO no está optimizada al

Performance.

Consejo: Tomarlo seriamente y seguir de cerca las mediciones de Performance.

Desarrolladores lo dicen y los Autores Confirman:

En Desarrollo OO es más fácil encontrar y corregir los defectos.

La tasa de defectos disminuye al finalizar el proceso de testing y después de lanzado.

C++

Gracias

“Lo que no sea medible, hazlo medible”            Galileo Galilei

“No se puede predecir lo que no se puede medir”            Norman Fenton

“No se puede controlar lo que no se puede medir” Tom De Marco