Diseño AgileMartín SalíasUniversal Thread MagazineEditor in Chief
¿Quién es este tipo?Martín SalíasArquitecto de Software Latinoamérica, USA, Canadá,  Australia y Escandinavia   Microsof...
Agenda   Definiciones   La decadencia del software   Enfoque Agile   Principios de Diseño Orientado a Objetos   Breve...
Definiciones Agilidad Análisis y Diseño Abstracciones Interfaces puras Colaboración                      4
La decadencia del software     Rigidez     Fragilidad     Inmovilidad     Viscosidad     Complejidad innecesaria    ...
Enfoque Agile Qué asumimos:  – La única constante en el software es el cambio en los    requerimientos Qué hacemos:  – D...
Principios de Diseño OO Responsabilidad única Abierto-Cerrado Substitución de Liskov Inversión de dependencia Segrega...
Responsabilidad única  Una clase debe tener una única razón para ser cambiada.Responsabilidad = Eje de cambios     (SI el ...
Dos responsabilidades              MyRectangleAplicación                        AplicaciónGeométrica    + Draw()          ...
Deslindando responsabilidades Aplicación           Aplicación Geométrica            GráficaGeoRectangle        GraphRectan...
Abierto-CerradoLas entidades de software (clases, módulos,    funciones, etc) deben estar abiertas a  extensión, pero cerr...
Cerrando a modificaciones                         El cliente está abiertoCliente    Servidor                         a mod...
Cerrando a modificaciones Política                     Patrón Template Method: + ReglaPolitica()   La clase base está cerr...
Substitución de Liskov     Los subtipos deben ser substituibles               por sus tipos base.Si para cada objeto o1 de...
Implicancias del LSP La validez depende del contexto No podemos validar un modelo  aisladamente Diseñar basándose en co...
Diseño por contrato Preservar las invariantes Pre y pos-condiciones  – La redeclaración de una rutina (en una derivación...
Un ejemplo más complejo (1)       Lista                           Librería                  Lista       Lista             ...
Un ejemplo más complejo (2)                   Librería     Lista                     Lista                  persistente   ...
Un ejemplo más complejo (3)             Contenedor                Librería           Quitar(T)           Existe(T)        ...
Inversión de dependenciaa) Los módulos de alto nivel no deben depender   de los módulos de bajo nivel. Ambos deben   depen...
Capas acopladas CapaPolítica                 Capa               Mecanismo                              Capa               ...
Capas desacopladas                                                Política                <<interface>>                   ...
Dependencia de Interfaces Responder a interfaces desacopla La propiedad de la interfaz debe ser del cliente Principio d...
Segregación de Interfaz  Los clientes no deben ser forzados a depender de                métodos que no usan. Apunta a ev...
Una interfaz engorda                                   <<interface>>                         Timer                        ...
Separación por delegación           <<interface>>Timer          Cliente Timer         + TimeOut()                         ...
Separación por herencia múltiple              <<interface>>   Timer             Cliente Timer            + TimeOut()      ...
Agile Modeling   Modelado liviano          Principios XP más   Soporta XP, RUP, otros     – Modelar con un             ...
Prácticas de AM   Modelar con clientes   Aplicar los artefactos correctos   Considerar pruebas   Varios Modelos en par...
Espacio de trabajo   Compatible con espacio XP   Pizarrones y cámara   Paredes para colgar modelos   Mesa amplia de tr...
Agile Modeling y XP               Stand Up              Meeting at                 9:00            Pair Up -- Quick       ...
Requerimientos   Casos de Uso esenciales y Casos de cambios   Prototipos de Interfaz de Usuario   Diagramas de flujo de...
Ejemplo: Casos de Uso            Obtain Student                                Pay Fees            Input marks            ...
Ejemplo: Prototipo IU                        34
Ejemplo: Modelo CRCStudent                                              Enroll in Seminar   <<UI>>                        ...
Análisis Elabora sobre los requerimientos Avanza en artefactos (simples)  –   Diagramas UML  –   Prototipos detallados  ...
Ejemplo: Prototipo IU                        37
Ejemplo: UML               38
Diseño   Determinación genérica de distribución   Esquema de colaboración general   Diseño general de modelos de datos...
Bibliografía                            Matt Weisfeld      Bertrand MeyerJohn Hunt   David West                         Re...
Preguntas?     msalias@gmail.com     www.Salias.com.ar     Universal Thread      www.UniversalThread.com               ...
Upcoming SlideShare
Loading in …5
×

Diseño Agile

737 views

Published on

Fundamentals of Agile Object Oriented Design.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
737
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Samples : Abstractions
  • 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
  • Diseño Agile

    1. 1. Diseño AgileMartín SalíasUniversal Thread MagazineEditor in Chief
    2. 2. ¿Quién es este tipo?Martín SalíasArquitecto de Software Latinoamérica, USA, Canadá, Australia y Escandinavia Microsoft Consulting Services MSDN Cono Sur Level Extreme .NET Magazine 2
    3. 3. Agenda Definiciones La decadencia del software Enfoque Agile Principios de Diseño Orientado a Objetos Breve Introducción a Agile Modeling 3
    4. 4. Definiciones Agilidad Análisis y Diseño Abstracciones Interfaces puras Colaboración 4
    5. 5. La decadencia del software  Rigidez  Fragilidad  Inmovilidad  Viscosidad  Complejidad innecesaria  Repetición innecesaria  Opacidad 5
    6. 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. 7. Principios de Diseño OO Responsabilidad única Abierto-Cerrado Substitución de Liskov Inversión de dependencia Segregación de Interfaz 7
    8. 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. 9. Dos responsabilidades MyRectangleAplicación AplicaciónGeométrica + Draw() Gráfica + Area() : double GUI 9
    10. 10. Deslindando responsabilidades Aplicación Aplicación Geométrica GráficaGeoRectangle GraphRectangle+ Area() : double + Draw() GUI 10
    11. 11. Abierto-CerradoLas 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. 12. Cerrando a modificaciones El cliente está abiertoCliente Servidor a modificaciones. <<Interfaz>> Patrón Strategy:Cliente ICliente El cliente está abierto y cerrado. Servidor 12
    13. 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. 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 paratodo programa P definido en términos de T, el comportamiento de P novarí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. 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. 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. 17. Un ejemplo más complejo (1) Lista Librería Lista Lista ilimitada ilimitada Lista Listalimitada limitada 17
    18. 18. Un ejemplo más complejo (2) Librería Lista Lista persistente Lista Lista persistente persistente 18
    19. 19. Un ejemplo más complejo (3) Contenedor Librería Quitar(T) Existe(T) Lista persistente Lista Lista Lista Persistente persistenteAgregar(T) Agregar(T) 19
    20. 20. Inversión de dependenciaa) 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. 21. Capas acopladas CapaPolítica Capa Mecanismo Capa Utilidad 21
    22. 22. Capas desacopladas Política <<interface>> Política Capa Servicio dePolítica políticas Mecanismo Mecanismo <<interface>> Capa Servicio de Mecanismo mecanismos Utilidad Utilidad Capa Utilidad 22
    23. 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. 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. 25. Una interfaz engorda <<interface>> Timer Cliente Timer + TimeOut()Puerta+ Trabar()+ Destrabar()+ Abierta() Puerta Puerta temporizada 25
    26. 26. Separación por delegación <<interface>>Timer Cliente Timer + TimeOut() Puerta Adapter Puerta Puerta Temporizada temporizada + TimeOut() + TimeOutPuerta() <<instancia>> 26
    27. 27. Separación por herencia múltiple <<interface>> Timer Cliente Timer + TimeOut() Puerta Puerta Temporizada + TimeOut() 27
    28. 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. 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. 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. 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. 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. 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 FeesStudent 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. 34. Ejemplo: Prototipo IU 34
    35. 35. Ejemplo: Modelo CRCStudent Enroll in Seminar <<UI>> ProfessorName Enrollment **See the prototype** NameAddress Record Seminar Request identifying Student AddressPhone number info for student Phone numberEmail address Enable seminar search Seminar Email addressStudent number Display seminar list Seminar, Professor SalaryAverage mark received Display seminar fees Student Provide informationValidate identifying info Display professor info Professor Seminars instructingProvide list of seminars taken . Transcript <<UI>> Enrollment RecordStudent <<Actor>> **See the prototype** Student Mark(s) receivedProvide information Enroll in Seminar Get student info Seminar Average to date about self Transcript Get seminars student Professor Final gradeRequest to enroll in took Enrollment Record Student seminar Determine average SeminarRequest Transcript mark Output self Seminar Name Student Seminar number Professor Fees Waiting list Enrolled students Instructor Add student Drop student 35
    36. 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. 37. Ejemplo: Prototipo IU 37
    38. 38. Ejemplo: UML 38
    39. 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. 40. Bibliografía Matt Weisfeld Bertrand MeyerJohn Hunt David West Rebecca Wirfs-Brock Scott Ambler 40
    41. 41. Preguntas?  msalias@gmail.com  www.Salias.com.ar  Universal Thread www.UniversalThread.com 41

    ×