Almudena Moya Muñoz Julio 2006 Una vuelta de tuerca a 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 cambiar Robert 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 claseDiseñ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

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 utilizan Robert 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 interfazDiseñ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ón Bertran 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 AClase 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 AClase B Clase A Clase Abstracta B Clase B1Clase B2

Principio de sustitución de Liskov Los subtipos deben ser sustituibles por sus supertipos Robert 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ánguloCuadrado Propiedadesalto ancho lado OperacionesestablecerAlto(x) establecerAncho(y) obtenerAlto() obtenerAncho() establecerLado(z) obtenerLado() RectánguloCuadrado 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 Interfaz Política Interfaz Mecanismo 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 dependencias Análisis Diseño con inversión de dependencias Nivel Política Nivel Mecanismo Nivel Utilidad Interfaz Política Interfaz Mecanismo 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)