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étricaReglas 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 instanciaIndica 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 Número de problemas reportados por claseObviamente, 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”. “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.DIT

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

 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.LCOM  DIT, RFC, NOC, y CBO están correlacionadas con las clases defectuosas DITRFCNOCCBO  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

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.

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