Almudena Moya Muñoz

Julio 2006

Una vuelta de tuercaa los principios de

diseño ágiles

Estructura

• Introducción

• Objetivos

• Análisis de los principios

• Conclusiones

Introducción

• El problema de los cambios en el software

• Gran diversidad de soluciones

• Se necesita un instrumento teórico de ayuda al diseño de software

• El instrumento podría ser la ambigüedad

Objetivos

• Comprobar la validez de la ambigüedad como instrumento teórico para el análisis de los principios de diseño ágiles

• Explicar y predecir el efecto de los principios

• Ofrecer una visión unificada de los principios y un criterio para clasificarlos

• Resolver varios aspectos confusos

Principios de diseño ágiles

• Principio de responsabilidad única• Principio de separación de la interfaz• Principio abierto/cerrado• Principio de sustitución de Liskov• Principio de inversión de dependencias

“Agile Software Development: Principles,

Patterns, and Practices” Robert C. Martin

Principio de responsabilidad única

Una clase sólo puede tener una razón para cambiarRobert C. Martin

Diseño con una sola clase

Cliente P

Cliente Q

Clase X

Elementos asociados a la responsabilidad A

Elementos asociados a la responsabilidad B

• Finalidad– Evitar que el cambio de una

responsabilidad en una clase pueda provocar fallos en las demás responsabilidades de la clase

– Evitar que los clientes de una clase carguen con elementos que no utilizan

Diseño con una sola clase Diseño con dos clases

Cliente P

Cliente Q

Clase X

Elementos asociados a la responsabilidad A

Elementos asociados a la responsabilidad B

Cliente P

Cliente Q

Clase XA

Elementos asociados a la responsabilidad A

Clase XB

Elementos asociados a la responsabilidad B

Principio de responsabilidad única

Principio de responsabilidad única

Justificación del principio según R. Martin

Principio de cohesión (DeMarco y Pages-Jones)Cohesión: Relación funcional de los elementos de un modulo

Cohesión = responsabilidad única (Martin)

Principio de responsabilidad única (Martin)Responsabilidad: razón de cambio

Cohesión: Fuerzas que provocan cambios en una clase o módulo

Principio de responsabilidad única¿ cohesión = razón de cambio ?

• Creencia– Alta cohesión y bajo acoplamiento conlleva facilidad

de modificación

• Problema (incluye lo que estaba escrito antes)– Infinitud de definiciones de cohesión y acoplamiento

• Consecuencia– No hay justificación para asociar cohesión con

fuerzas de cambio

Diseño con una clase

• Realidad del principio:– División salomónica puntual

• Ambigüedad:– Aumenta entre los elementos de

responsabilidades separadas– Aumenta entre la clase cliente hacia

las clases separadas que no utilizan– Disminuye entre la clase cliente

hacia las clases separadas que utilizan

• Ventajas e inconvenientes

Cliente P

Cliente Q

Clase X

Responsabilidad A

Responsabilidad B

Diseño con dos clases

Cliente P

Cliente Q

Clase XA

Responsabilidad A

Clase XB

Responsabilidad B

Principio de responsabilidad única

Análisis

Principio de separación de la interfaz

Los clientes no deben ser forzados a depender de

interfaces que no utilizanRobert C. Martin

Diseño con una sola interfaz

• Finalidad– Reducir las dependencias entre clientes

que utilizan métodos diferentes de la misma interfaz

– Evitar que los clientes de una clase carguen con elementos que no utilizan

Cliente C

Cliente D

Interfaz Z

Métodos que utiliza el cliente C

Métodos que utiliza el cliente D

Diseño con una interfaz Diseño con dos interfaces

Cliente C

Cliente D

Interfaz Z

Métodos que utiliza el cliente C

Métodos que utiliza el cliente D

Cliente C

Cliente D

interfaz ZC

Métodos que utiliza el cliente C

Interfaz ZD

Métodos que utiliza el cliente D

Principio de separación de la interfaz

Diseño con una interfaz

• Extensión del principio de responsabilidad única

• Ambigüedad– Aumenta entre los métodos de

interfaces separadas– Aumenta entre la clase cliente hacia

los métodos de las interfaces no utilizan

• Ventajas e inconvenientes

Cliente C

Cliente D

Interfaz Z

Métodos cliente C

Métodos cliente D

Diseño con dos interfaces

Cliente C

Cliente D

Interfaz ZC

Métodos cliente C

Interfaz ZD

Métodos cliente D

Principio de separación de la interfaz

Análisis

Principio abierto/cerrado

Las entidades software deben estar abiertas para su

extensión, pero cerradas para su modificaciónBertran Meyer

Diseño cerrado/cerrado

• Finalidad– Sistema funcionando (cerrado), pero

ampliable (abierto)– Conseguir cambios añadiendo

nuevo código sin afectar al resto de elementos del diseño

Clase A Clase B

• Ambigüedad– La dependencia “uno a uno” se

transforma en una dependencia de “uno a muchos”

• Ventajas

Diseño abierto/cerrado

Principio abierto/cerrado

Análisis

Diseño cerrado/cerrado

Clase A Clase B

Clase A Clase Abstracta B

Clase B1 Clase B2

Principio de sustitución de Liskov

Los subtipos deben ser sustituibles por sus supertiposRobert C. Martin

S es subtipo de T (Barbara Liskov)

o2 es un objeto de T

o1 es un objeto de S

Para todo programa P ( T )

comportamiento P(o1) = comportamiento P(o2)

cuando o1 es sustituido por o2

T

S

• Finalidad– Facilitar la modificación del

diseño y la reutilización del código a través del uso adecuado de la herencia

Te cambié el orden de o1 y o2, pero no estoy seguro

Rectángulo Cuadrado

Propiedades alto

ancho

lado

Operaciones establecerAlto(x)

establecerAncho(y)

obtenerAlto()

obtenerAncho()

establecerLado(z)

obtenerLado()

Rectángulo Cuadrado

establecerAlto(x) Modifica el atributo alto con el valor x

Mantiene el atributo ancho

Modifica el atributo alto con el valor x

Modifica el atributo ancho con el valor x

establecerAncho(y) Mantiene el atributo alto

Modifica el atributo ancho con el valor y

Modifica el atributo alto con el valor y

Modifica el atributo ancho con el valor y

Rectángulo

Cuadrado

ES – UN ?

Principio de sustitución de Liskov

¿ Rectángulo ES-UN Cuadrado ?

Poscondiciones de los métodos establecerAlto y establecerAncho

Propiedades y métodos

• Ambigüedad:– Los programas no saben si

trabajan con objetos de supertipos o de subtipos

• Ventajas• El enunciado de Martin es

confuso:– “Los subtipos deben ser

sustituibles por los supertipos”, pero la definición de subtipo se basa en la sustitución

S es subtipo de T

o1 es un objeto de S

o2 es un objeto de T

Para todo programa P ( T )

comportamiento P(o1) = comportamiento P(o2)

cuando o1 es sustituido por o2

T

S

Principio de sustitución de Liskov

Análisis

Principio de inversión de dependencias

Los módulos de alto nivel no deben depender de los

módulos de bajo nivel. Ambos deben depender de las

abstracciones

Las abstracciones no deben depender de los detalles.

Los detalles deben depender de las abstracciones.Robert C. Martin

Principio de inversión de dependencias

• Finalidad:– Conseguir que los

cambios en los módulos de bajo nivel no afecten a los módulos de alto nivel

– Facilitar la reutilización de los módulos de alto nivel

Diseño tradicional

Nivel Política

Nivel Mecanismo

Nivel Utilidad

Diseño tradicional

Nivel Política

Nivel Mecanismo

Nivel Utilidad

Principio de inversión de dependencias

Diseño con inversión de dependencias

Nivel Política

Nivel Mecanismo

Nivel Utilidad

InterfazPolítica

InterfazMecanismo

Política

Mecanismo

Utilidad

• Ambigüedad:

– Aumenta entre los módulos de alto nivel y los de bajo nivel

• Ventajas• Caso particular de la

programación estructurada de Dijkstra

Principio de inversión de dependenciasAnálisis

Diseño con inversión de dependencias

Nivel Política

Nivel Mecanismo

Nivel Utilidad

InterfazPolítica

InterfazMecanismo

Política

Mecanismo

Utilidad

Conclusiones (I)

La ambigüedad ha sido un instrumento

teórico válido para analizar los principios de

diseño ágiles porque ha permitido:– Explicar y predecir los efectos de la aplicación

de estos principios– Disponer de una visión uniforme de los

principios

Conclusiones (II)

Los principios:– abierto/cerrado– de sustitución– de inversión de dependencias

aumentan la ambigüedad del diseño:– Reemplazo de las relaciones unívocas por ambiguas– Reducción la complejidad descriptiva– Reducción la complejidad por incertidumbre

Son criterios de diseño para utilizarlos de forma regular

Conclusiones (III)

Los principios:– de responsabilidad única– de separación de la interfaz

diminuyen la ambigüedad del diseño:– Aumento de la complejidad descriptiva– Aumento de la complejidad por incertidumbre

Son criterios de diseño para utilizarlos de forma

excepcional

Conclusiones (y IV)

Objeciones al trabajo de Martin:– No existe un análisis teórico de los principios – No hay relación entre el principio de cohesión y el

principio de responsabilidad única– Enunciado tautológico del principio de sustitución– Principio de inversión de dependencias es un caso

particular de la programación estructurada original (Dijkstra)