Este documento presenta los conceptos y principios clave del diseño ágil y orientado a objetos. Explica cómo el cambio constante en los requerimientos de software llevó al desarrollo de enfoques ágiles. Luego resume los principios de diseño orientado a objetos como responsabilidad única, abierto-cerrado e inversión de dependencias. Finalmente, introduce brevemente la metodología de modelado ágil.

1. Diseño Agile
Martín Salías
Universal Thread Magazine
Editor in Chief

2. ¿Quién es este tipo?
Martín Salías
Arquitecto de Software
 Latinoamérica, USA, Canadá,
Australia y Escandinavia
 Microsoft Consulting Services
 MSDN Cono Sur
 Level Extreme .NET Magazine
2

3. Agenda
 Definiciones
 La decadencia del software
 Enfoque Agile
 Principios de Diseño Orientado a Objetos
 Breve Introducción a Agile Modeling
3

4. Definiciones
 Agilidad
 Análisis y Diseño
 Abstracciones
 Interfaces puras
 Colaboración
4

5. La decadencia del software
 Rigidez
 Fragilidad
 Inmovilidad
 Viscosidad
 Complejidad innecesaria
 Repetición innecesaria
 Opacidad
5

6. Enfoque Agile
 Qué asumimos:
– La única constante en el software es el cambio en los
requerimientos
 Qué hacemos:
– Detectar el problema siguiendo las metodologías ágiles
– Diagnosticar aplicando principios de diseño (OOD)
– Resolver mejorando el diseño, usando frecuentemente
patrones como referencia
6

7. Principios de Diseño OO
 Responsabilidad única
 Abierto-Cerrado
 Substitución de Liskov
 Inversión de dependencia
 Segregación de Interfaz
7

8. Responsabilidad única
Una clase debe tener una
única razón para ser cambiada.
Responsabilidad = Eje de cambios
(SI el cambio sucede)
Recibir el primer golpe
8

9. Dos responsabilidades
MyRectangle
Aplicación Aplicación
Geométrica + Draw() Gráfica
+ Area() : double
GUI
9

10. Deslindando responsabilidades
Aplicación Aplicación
Geométrica Gráfica
GeoRectangle GraphRectangle
+ Area() : double + Draw()
GUI
10

11. Abierto-Cerrado
Las entidades de software (clases, módulos,
funciones, etc) deben estar abiertas a
extensión, pero cerradas a modificación.
Acercarse a un ideal
Los cambios deben generar código nuevo,
no modificar el código viejo.
11

12. Cerrando a modificaciones
El cliente está abierto
Cliente Servidor
a modificaciones.
<<Interfaz>> Patrón Strategy:
Cliente
ICliente El cliente está abierto
y cerrado.
Servidor
12

13. Cerrando a modificaciones
Política
Patrón Template Method:
+ ReglaPolitica() La clase base está cerrada
- Servicio() a modificaciones.
Implementación La implementación del
método lo abre a cuantas
extensiones se necesiten.
- Servicio()
13

14. Substitución de Liskov
Los subtipos deben ser substituibles
por sus tipos base.
Si para cada objeto o1 de tipo S hay un objeto o2 de tipo T tal que para
todo programa P definido en términos de T, el comportamiento de P no
varía cuando o1 es sustitido por o2, entonces S es un subtipo de T.
Es la base de poder del polimorfismo.
Cuidarse de GetType() y otros datos de tipo en runtime.
14

15. Implicancias del LSP
 La validez depende del contexto
 No podemos validar un modelo
aisladamente
 Diseñar basándose en comportamientos
 Presunciones razonables (¿cómo acotarlas?)
15

16. Diseño por contrato
 Preservar las invariantes
 Pre y pos-condiciones
– La redeclaración de una rutina (en una derivación) debe
solamente reemplazar la precondición original con una igual o
más débil, y la poscondición original con una igual o más fuerte.
 Eiffel soporta nativamente DBC
 En .NET ó Java usamos Unit Tests
16

17. Un ejemplo más complejo (1)
Lista
Librería
Lista Lista
ilimitada ilimitada
Lista Lista
limitada limitada
17

18. Un ejemplo más complejo (2)
Librería
Lista
Lista
persistente
Lista Lista
persistente persistente
18

19. Un ejemplo más complejo (3)
Contenedor Librería
Quitar(T)
Existe(T)
Lista
persistente
Lista Lista Lista
Persistente persistente
Agregar(T)
Agregar(T)
19

20. Inversión de dependencia
a) Los módulos de alto nivel no deben depender
de los módulos de bajo nivel. Ambos deben
depender de abstracciones.
b) Las abstracciones no deben depender de
detalles. Los detalles deben depender de las
abstracciones.
Es el principio general detrás del concepto de
Layers o Capas.
20

21. Capas acopladas
Capa
Política
Capa
Mecanismo
Capa
Utilidad
21

22. Capas desacopladas
Política
<<interface>>
Política
Capa
Servicio de
Política
políticas
Mecanismo
Mecanismo
<<interface>>
Capa
Servicio de
Mecanismo
mecanismos
Utilidad
Utilidad
Capa
Utilidad
22

23. Dependencia de Interfaces
 Responder a interfaces desacopla
 La propiedad de la interfaz debe ser del cliente
 Principio de Hollywood:
“No nos llame, lo llamaremos”
 Depender de abstracciones como ideal implica:
– Las variables no deben apuntar a clases concretas
– Las clases no deberían derivar de clases concretas
– Los métodos no deberían sobrescribir una implementación de su
clase base.
– Excepciones: Factories (excepto si son reflectivas)
 Cambiar las interfaces sólo si el cliente (su dueño) lo
necesita.
23

24. Segregación de Interfaz
Los clientes no deben ser forzados a depender de
métodos que no usan.
 Apunta a evitar las interfaces “gordas”.
 No importa la cantidad de métodos, sino que todos sus
clientes las utilicen.
 Inadvertidamente podemos acoplar clientes que usan
ciertos métodos con otros clientes que no los usan.
24

25. Una interfaz engorda
<<interface>>
Timer
Cliente Timer
+ TimeOut()
Puerta
+ Trabar()
+ Destrabar()
+ Abierta() Puerta
Puerta
temporizada
25

26. Separación por delegación
<<interface>>
Timer
Cliente Timer
+ TimeOut()
Puerta
Adapter Puerta Puerta
Temporizada temporizada
+ TimeOut() + TimeOutPuerta()
<<instancia>>
26

27. Separación por herencia múltiple
<<interface>>
Timer
Cliente Timer
+ TimeOut() Puerta
Puerta
Temporizada
+ TimeOut()
27

28. Agile Modeling
 Modelado liviano  Principios XP más
 Soporta XP, RUP, otros – Modelar con un
propósito
 Basado en valores XP
– Múltiples modelos
– Viajar liviano
28

29. Prácticas de AM
 Modelar con clientes
 Aplicar los artefactos correctos
 Considerar pruebas
 Varios Modelos en paralelo
 Modelos sencillos y públicos
 Iterar hacia otro artefacto
 Modelado incremental
 Modelar con otros
 Comprobar con código
 Herramientas simples (papel y lápiz)
29

30. Espacio de trabajo
 Compatible con espacio XP
 Pizarrones y cámara
 Paredes para colgar modelos
 Mesa amplia de trabajo
 Libros de referencia a mano
 Libre de sillas en la Zona de Modelado
30

31. Agile Modeling y XP
Stand Up
Meeting at
9:00
Pair Up -- Quick
Design Session
Test Q&A
Code Refactor
Integrate or
Toss
Go Home at
17:00
31

32. Requerimientos
 Casos de Uso esenciales y Casos de cambios
 Prototipos de Interfaz de Usuario
 Diagramas de flujo de la IU
 Modelos CRC
 Reglas de negocios
 Limitantes – Requerimientos técnicos
 Historias de Usuario
 Características
32

33. Ejemplo: Casos de Uso
Obtain Student
Pay Fees Input marks
Grant
Grade Admistrator
Obtain Student Inform Student of
Loan Grades
Produce Teaching
Produce Fee Schedule
Schedule
Reimburse Course Instructor
Teach Seminar
Fees
Student
Enroll in seminar Apply for Grant
Researcher
Drop seminar
Drop out of
Attend seminar
School
Graduate From Notify Students of Registrar
Finish seminar
School Schedule Changes
33

34. Ejemplo: Prototipo IU
34

35. Ejemplo: Modelo CRC
Student Enroll in Seminar <<UI>> Professor
Name Enrollment
**See the prototype** Name
Address Record Seminar
Request identifying Student Address
Phone number
info for student Phone number
Email address
Enable seminar search Seminar Email address
Student number
Display seminar list Seminar, Professor Salary
Average mark received
Display seminar fees Student Provide information
Validate identifying info
Display professor info Professor Seminars instructing
Provide list of seminars taken
.
Transcript <<UI>> Enrollment Record
Student <<Actor>>
**See the prototype** Student Mark(s) received
Provide information Enroll in Seminar Get student info Seminar Average to date
about self Transcript Get seminars student Professor Final grade
Request to enroll in took Enrollment Record Student
seminar Determine average Seminar
Request Transcript mark
Output self
Seminar
Name
Student
Seminar number
Professor
Fees
Waiting list
Enrolled students
Instructor
Add student
Drop student
35

36. Análisis
 Elabora sobre los requerimientos
 Avanza en artefactos (simples)
– Diagramas UML
– Prototipos detallados
– Diagramas de flujo
– Diseño de interfaces externas
 En XP sigue sin ser una fase, sino parte del
proceso de desarrollo
36

37. Ejemplo: Prototipo IU
37

38. Ejemplo: UML
38

39. Diseño
 Determinación genérica de distribución
 Esquema de colaboración general
 Diseño general de modelos de datos
 Consideración de Patrones posibles
 ¿Hasta dónde llegar en papel?
 ¿Cuánto invertir antes del código?
 Consideración de escenarios
39

40. Bibliografía
Matt Weisfeld Bertrand Meyer
John Hunt David West
Rebecca Wirfs-Brock Scott Ambler
40

41. Preguntas
?
 msalias@gmail.com
 www.Salias.com.ar
 Universal Thread
www.UniversalThread.com
41