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.
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
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
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
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
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
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
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
Rigidez : difícil de cambiar Fragilidad : fácil de romper Inmovilidad : difícil de reutilizar Viscosidad : difícil de modificar correctamente En el diseño mismo En el ambiente (compilación, control de fuentes, herramientas que no favorecen una buena manera de hacer las cosas; o la carencia de aquellas que la facilitan). Complejidad : sobre-diseño ó sobre-arquitectura; exceso de especulación Repetición : exceso de “ copy/paste development ” Opacidad : falta total de expresividad Sample : TheCopyProgram
Cohesion (Tom DeMarco, Structured Analysis and System Specification) Sample : SingleResponsibility
Bertrand Meyer (OO Software Construction, 1988) Applicable to several levels: Source code Asemblies (jar, dll) Exes
Abstraction is the key Abstractions relates more to their clients than to their implementations. Patterns: Strategy
Pattern: Template Method Sample : OpenClosed
Barbara Liskov: Data Abstractions and Hierarchies (SIGPLAN, 1988) Samples : OpenClosed (The first version violates LSP because in DrawShapes neither Circle or Square can be substituted by Shape) Liskov
DBC : Bertrand Meyer Las convenciones como alternativa - ¿por qué no funcionan? Cumplir con el LSP se logra usualmente mediante Refactoring Síntomas: Legado despreciado Subclases tirando excepciones que la clase base no tira
Samples : InterfaceSegregation
Dos alternativas de separación: Por delegación Por herencia múltiple
Disponible en C++ y Eiffel, no en C#, J# y VB.Net, excepto con interfaces puras, lo que es una solución parcial. FINAL PARTE 1 – SIGUE AGILE MODELING