Upload
eva-maria-torres-ferreyra
View
213
Download
0
Embed Size (px)
Citation preview
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)