architecture - ¿Qué es Abstractness vs. Inestabilidad gráfica?
code-metrics ooad (2)
Recientemente usé NDepend y produjo un buen informe sobre mis ensamblajes .net y pdbs relacionados.
Lo más interesante que encontré en el informe fue la abstracción contra el gráfico de inestabilidad. Quería entender esto en detalle, leí sus documentos y las metrices en línea, pero solo podía ayudar en cierta medida.
Principalmente deseo entender cómo evaluar la gráfica correctamente y las técnicas para controlar la abstracción con estabilidad.
Aquí hay un muy buen artículo que habla sobre esto, pero ¿qué más, además de esto, necesito es ''cómo controlo esto? [controlando la abstracción con estabilidad] ''
La abstracción es una medida de la rigidez de un sistema de software. A mayor abstracción, menor rigidez (o mayor flexibilidad) y viceversa. Si los componentes del sistema dependen de clases abstractas o interfaces, tal sistema es más fácil de ampliar y cambiar que si dependiera directamente de clases concretas.
La estabilidad es una medida de la tolerancia al cambio, ya que el sistema de software permite realizar cambios sin romperlo. Esto se determina analizando las interdependencias de los componentes del sistema.
El article Robert C. Martin sobre métricas de OO describe estos conceptos en términos más cuantitativos.
Extracto del artículo:
La responsabilidad, la independencia y la estabilidad de una categoría pueden medirse contando las dependencias que interactúan con esa categoría. Se han identificado tres métricas:
Ca: Acoplamientos aferentes: el número de clases fuera de esta categoría que dependen de las clases dentro de esta categoría.
Ce: Acoplamientos eferentes: el número de clases dentro de esta categoría que dependen de clases fuera de estas categorías.
I: Inestabilidad: (Ce ÷ (Ca + Ce)): esta métrica tiene el rango [0,1]. I = 0 indica una categoría máxima estable. I = 1 indica una categoría de máxima inestabilidad.
A: Resumen: (# clases abstractas en la categoría ÷ # total de clases en la categoría). Este rango métrico es [0,1]. 0 significa concreto y 1 significa completamente abstracto.
En cualquier sistema de software particularmente grande, el equilibrio es crítico. En este caso, un sistema debe equilibrar la abstracción con la estabilidad para ser "bueno". La posición en el gráfico AI muestra esto. Por favor, lea el artículo para la explicación.
Tanto la abstracción como la inestabilidad pueden usarse solas para evaluar su código. Usted sabe de antemano qué tan abstracto o estable debería ser un módulo. Por ejemplo, desea que la capa de presentación sea moderadamente abstracta y altamente estable, porque los módulos inferiores dependen de ella. Por otro lado, desea que la capa de infraestructura sea muy concreta (baja abstracción) y altamente inestable, ya que debería implementar lo que las capas superiores son exigentes.
Una vez que esté claro, puede combinar la abstracción y la inestabilidad en un gráfico, y ese es el gráfico de inestabilidad-abstracción. Desea que su código muestre tanta abstracción como estable, a fin de equilibrar las necesidades para soportar futuros cambios en los requisitos.
Pero de todos modos, debe tener una sólida comprensión de las métricas de inestabilidad y abstracción solo antes de tratar de entenderlos trabajando juntos. Puede encontrar algunos ejemplos de lo que significa inestabilidad en este artículo: Cómo usar el acoplamiento de módulos y las métricas de inestabilidad para guiar la refactorización
Hay un artículo relacionado que deriva una consulta de CQLinq que mide la inestabilidad de todos los módulos en la aplicación: Cómo medir el acoplamiento e inestabilidad del módulo usando NDepend