almudena moya mu oz
Download
Skip this Video
Download Presentation
Almudena Moya Muñoz

Loading in 2 Seconds...

play fullscreen
1 / 26

Almudena Moya Muñoz - PowerPoint PPT Presentation


  • 160 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Almudena Moya Muñoz' - hanh


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
slide2
Estructura
  • Introducción
  • Objetivos
  • Análisis de los principios
  • Conclusiones
slide3
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
slide4
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
slide5
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

slide6
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

slide7
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

slide8
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

slide9
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
slide10
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

slide11
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

slide12
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

slide13
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

slide14
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

slide15
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

slide16
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

slide17
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

slide18
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

slide19
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

slide20
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

slide21
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

slide22
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

slide23
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
slide24
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

slide25
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

slide26
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)