2.1.4 Métricas para Sistemas Oientados a Objetos

En un tratamiento detallado de las métricas de software para sistemas OO, Whitmire [Whi97] describe  nueve características distintas y mensurables de un diseño OO:

  • Tamaño. El tamaño se describe a función de cuatro visiones: población, volumen, longitud y funcionalidad.
    • La población se mide al realizar un conteo estático de entidades OO, tales como clases u operaciones.
    • Las medidas de volumen son idénticas a las medidas de población, pero se recolectan de manera dinámica en un instante de tiempo determinado.
    • La longitud es una medida de una cadena de elementos de diseño interconectados.
    • Las métricas de funcionalidad proporcionan un indicio indirecto del valor entregado al cliente por una aplicaión OO.

  • Complejidad. Como el tamaño existen muchas visiones diferentes de la complejidad del software .

  • Acoplamiento. Las conexiones físicas entre elementos del diseño OO (por ejemplo el número de colaboraciones entre clases o el de mensajes que pasan entre los objetos), representan el acoplamiento dentro de un sistema.

  • Suficiencia. Se define como el grado en el que una abstracción posee las características requeridas de él o en el que un componente de diseño posee características en su abstracción, desde el punto de vista de la aplicación actual.. Dicho de otra manera  se pregunta: ¿Qué propiedades debe poseeer esta abstracción (clase) para ser útil?. En esencia, un componente de diseño (por ejemplo, una clase) es suficiente si refleja por completo todas las propiedades del objeto de dominio de aplicaciones que se modela, es decir, si la abstracción (clase) posee sus características.

  • Completitud. La única diferencia  entre complejidad y suficiencia es el "conjunto de características contra las cuales se compara la abstracción o el componente de diseño". La suficiencia compara la abstracción desde el punto de vista de la aplicación actual. La completitud considera multiples puntos de vista, y plantea la pregunta: ¿qué propiedades se requieren para representar por completo al objeto de dominio problema?. Puesto que el criterio para completitud considera diferentes puntos de vista, tiene una implicación indirecta en el grado en el que puede reutilizarse la abstracción o el componente de diseño.

  • Cohesión. Como contraparte en software convencional, un componente OO debe diseñarse de manera que tengan todas las operaciones funcionando en conjunto para lograr un sólo propósito bien definido. La cohesividad de una clase se determina al examinar el grado en que el conjunto de propiedades que posee es parte del problema dominio de diseño.

  • Primitivismo. Una característica que es similar a la simplicidad, el primitivismo (aplicado tanto a operaciones como a clases), es el grado en el que una operación es atómica, es decir, la operación no puede construirse a partir de una secuencia de otras operaciones contenidas dentro de una clase. Una clase que muestra un alto grado de primitivismo encapsula sólo operaciones primitivas.

  • Similitud. El grado en el que dos o más clases son similares en términos de su estructura, función, comportamiento propósito de indica mediante esta medida.

  • Volatidad. Los cambios en el diseño pueden ocurrir cuando se modifican los requerimientos o cuando ocurren modificaciones es otras partes de una aplicación, lo que da como resultado la adaptación obligatoria del componente de diseño en cuestión. La volatidad de un componente de diseño OO mide la probabilidad de que ocurrirá un cambio.

Arriba