Almudena moya mu oz
This presentation is the property of its rightful owner.
Sponsored Links
1 / 26

Almudena Moya Muñoz PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on
  • Presentation posted in: General

Una vuelta de tuerca a los principios de diseño ágiles. Almudena Moya Muñoz. Julio 2006. Estructura. Introducción Objetivos Análisis de los principios Conclusiones. Introducción. El problema de los cambios en el software Gran diversidad de soluciones

Download Presentation

Almudena Moya Muñoz

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Almudena moya mu oz

Una vuelta de tuercaa los principios de diseño ágiles

Almudena Moya Muñoz

Julio 2006


Almudena moya mu oz

Estructura

  • Introducción

  • Objetivos

  • Análisis de los principios

  • Conclusiones


Almudena moya mu oz

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


Almudena moya mu oz

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


Almudena moya mu oz

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


Almudena moya mu oz

Principio de responsabilidad única

Una clase sólo puede tener una razón para cambiar

Robert C. Martin

  • 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

Clase X

Cliente P

Elementos asociados

a la responsabilidad A

Cliente Q

Elementos asociados

a la responsabilidad B


Almudena moya mu oz

Principio de responsabilidad única

Diseño con una sola clase

Diseño con dos clases

Clase XA

Clase X

Cliente P

Elementos asociados

a la responsabilidad A

Cliente P

Elementos asociados

a la responsabilidad A

Clase XB

Cliente Q

Elementos asociados

a la responsabilidad B

Cliente Q

Elementos asociados

a la responsabilidad B


Almudena moya mu oz

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


Almudena moya mu oz

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


Almudena moya mu oz

Principio de responsabilidad única

Análisis

  • 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

Diseño con una clase

Clase X

Cliente P

Responsabilidad A

Cliente Q

Responsabilidad B

Diseño con dos clases

Clase XA

Cliente P

Responsabilidad A

Clase XB

Cliente Q

Responsabilidad B


Almudena moya mu oz

Principio de separación de la interfaz

Los clientes no deben ser forzados a depender de

interfaces que no utilizan

Robert C. Martin

  • 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

Diseño con una sola interfaz

Interfaz Z

Cliente C

Métodos que utiliza

el cliente C

Cliente D

Métodos que utiliza

el cliente D


Almudena moya mu oz

Principio de separación de la interfaz

Diseño con una interfaz

Diseño con dos interfaces

interfaz ZC

Interfaz Z

Cliente C

Métodos que utiliza

el cliente C

Cliente C

Métodos que utiliza

el cliente C

Interfaz ZD

Cliente D

Métodos que utiliza

el cliente D

Cliente D

Métodos que utiliza

el cliente D


Almudena moya mu oz

Principio de separación de la interfaz

Análisis

  • 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

Diseño con una interfaz

Interfaz Z

Cliente C

Métodos cliente C

Cliente D

Métodos cliente D

Diseño con dos interfaces

Interfaz ZC

Cliente C

Métodos cliente C

Interfaz ZD

Cliente D

Métodos cliente D


Almudena moya mu oz

Principio abierto/cerrado

Las entidades software deben estar abiertas para su

extensión, pero cerradas para su modificación

Bertran Meyer

  • Finalidad

    • Sistema funcionando (cerrado), pero ampliable (abierto)

    • Conseguir cambios añadiendo nuevo código sin afectar al resto de elementos del diseño

Diseño cerrado/cerrado

Clase A

Clase B


Almudena moya mu oz

Principio abierto/cerrado

Análisis

  • Ambigüedad

    • La dependencia “uno a uno” se transforma en una dependencia de “uno a muchos”

  • Ventajas

Diseño cerrado/cerrado

Clase A

Clase B

Diseño abierto/cerrado

Clase A

Clase Abstracta B

Clase B1

Clase B2


Almudena moya mu oz

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

  • 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

T

S


Almudena moya mu oz

Principio de sustitución de Liskov

¿ Rectángulo ES-UN Cuadrado ?

Rectángulo

ES – UN ?

Cuadrado

Propiedades y métodos

Poscondiciones de los métodos establecerAlto y establecerAncho


Almudena moya mu oz

Principio de sustitución de Liskov

Análisis

  • 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


Almudena moya mu oz

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


Almudena moya mu oz

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

Principio de inversión de dependencias

Diseño tradicional

Nivel Política

Nivel Mecanismo

Nivel Utilidad


Almudena moya mu oz

Principio de inversión de dependencias

Diseño tradicional

Diseño con inversión de dependencias

Política

Nivel

Política

Interfaz

Política

Nivel Política

Mecanismo

Nivel Mecanismo

Nivel

Mecanismo

Interfaz

Mecanismo

Nivel Utilidad

Utilidad

Nivel

Utilidad


Almudena moya mu oz

Principio de inversión de dependencias

Análisis

  • 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

Diseño con inversión de dependencias

Política

Nivel

Política

Interfaz

Política

Mecanismo

Nivel

Mecanismo

Interfaz

Mecanismo

Utilidad

Nivel

Utilidad


Almudena moya mu oz

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


Almudena moya mu oz

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


Almudena moya mu oz

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


Almudena moya mu oz

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)


  • Login