Diseño AgileDiseño Agile

Martín SalíasUniversal Thread MagazineEditor in ChiefEditor in Chief

22

Martín SalíasMartín Salías

Arquitecto de SoftwareArquitecto de Software Latinoamérica, USA, Canadá, Latinoamérica, USA, Canadá,

Australia y EscandinaviaAustralia y Escandinavia

Microsoft Consulting ServicesMicrosoft Consulting Services MSDN Cono SurMSDN Cono Sur Level Extreme .NET MagazineLevel Extreme .NET Magazine

¿Quién es este tipo?¿Quién es este tipo?

33

AgendaAgenda

DefinicionesDefiniciones La decadencia del softwareLa decadencia del software Enfoque AgileEnfoque Agile Principios de Diseño Orientado a Principios de Diseño Orientado a

ObjetosObjetos Breve Introducción a Agile ModelingBreve Introducción a Agile Modeling

44

DefinicionesDefiniciones

AgilidadAgilidad Análisis y DiseñoAnálisis y Diseño

AbstraccionesAbstracciones Interfaces purasInterfaces puras ColaboraciónColaboración

55

La decadencia del softwareLa decadencia del software

RigidezRigidez FragilidadFragilidad InmovilidadInmovilidad ViscosidadViscosidad Complejidad Complejidad

innecesariainnecesaria Repetición innecesariaRepetición innecesaria OpacidadOpacidad

66

Enfoque AgileEnfoque Agile

Qué asumimos:Qué asumimos:– La única constante en el software es el La única constante en el software es el cambio en cambio en

los requerimientoslos requerimientos

Qué hacemos:Qué hacemos:– Detectar el problema siguiendo las metodologías Detectar el problema siguiendo las metodologías

ágileságiles– Diagnosticar aplicando principios de diseño (OOD)Diagnosticar aplicando principios de diseño (OOD)– Resolver mejorando el diseño, usando Resolver mejorando el diseño, usando

frecuentemente patrones como referenciafrecuentemente patrones como referencia

77

Principios de Diseño OOPrincipios de Diseño OO

Responsabilidad únicaResponsabilidad única Abierto-CerradoAbierto-Cerrado Substitución de LiskovSubstitución de Liskov Inversión de Inversión de

dependenciadependencia Segregación de InterfazSegregación de Interfaz

88

Responsabilidad únicaResponsabilidad única

Una clase debe tener una Una clase debe tener una única razón para ser cambiada.única razón para ser cambiada.

Responsabilidad = Eje de cambiosResponsabilidad = Eje de cambios

(SI el cambio sucede)(SI el cambio sucede)

Recibir el primer golpeRecibir el primer golpe

99

Dos responsabilidadesDos responsabilidades

AplicaciónAplicación

GeométricaGeométrica + Draw()+ Draw()

+ Area() : double+ Area() : double

MyRectangleMyRectangle

AplicaciónAplicación

GráficaGráfica

GUIGUI

1010

Deslindando responsabilidadesDeslindando responsabilidades

AplicaciónAplicación

GeométricaGeométrica

+ Draw()+ Draw()

GraphRectangleGraphRectangle

AplicaciónAplicación

GráficaGráfica

GUIGUI

+ Area() : double+ Area() : double

GeoRectangleGeoRectangle

AplicaciónAplicación

GeométricaGeométricaAplicaciónAplicación

GeométricaGeométrica

AplicaciónAplicación

GráficaGráficaAplicaciónAplicación

GeométricaGeométrica

1111

Abierto-CerradoAbierto-Cerrado

Las entidades de software (clases, Las entidades de software (clases, módulos, funciones, etc) deben estar módulos, funciones, etc) deben estar abiertas a extensión, pero cerradas a abiertas a extensión, pero cerradas a

modificación.modificación.

Acercarse a un idealAcercarse a un ideal

Los cambios deben generar código Los cambios deben generar código nuevonuevo,,no modificar el código no modificar el código viejoviejo..

1212

Cerrando a modificacionesCerrando a modificaciones

ServidorServidorClienteClienteEl cliente está abierto El cliente está abierto

a modificaciones.a modificaciones.

<<Interfaz>><<Interfaz>>

IClienteIClienteClienteCliente

Patrón Strategy: Patrón Strategy:

El cliente está abiertoEl cliente está abierto

y cerrado.y cerrado.

ServidorServidor

1313

Cerrando a modificacionesCerrando a modificaciones

+ ReglaPolitica()+ ReglaPolitica()

- Servicio()- Servicio()

PolíticaPolítica

- Servicio()- Servicio()

ImplementaciónImplementación

Patrón Template Method:Patrón Template Method:

La clase base está cerradaLa clase base está cerradaa modificaciones.a modificaciones.

La implementación delLa implementación delmétodo lo abre a cuantasmétodo lo abre a cuantasextensiones se necesiten.extensiones se necesiten.

1414

Substitución de LiskovSubstitución de Liskov

Los subtipos deben ser substituiblesLos subtipos deben ser substituiblespor sus tipos base.por sus tipos base.

Si para cada objeto Si para cada objeto oo11 de tipo de tipo SS hay un objeto hay un objeto oo22 de tipo de tipo TT tal que tal que para todo programa para todo programa PP definido en términos de definido en términos de TT, el comportamiento , el comportamiento de de PP no varía cuando no varía cuando oo11 es sustitido por es sustitido por oo22, entonces , entonces SS es un subtipo es un subtipo de de TT..

Es la base de poder del polimorfismo.Es la base de poder del polimorfismo.

Cuidarse de GetType() y otros datos de tipo en runtime.Cuidarse de GetType() y otros datos de tipo en runtime.

1515

Implicancias del LSPImplicancias del LSP

La validez depende del contextoLa validez depende del contexto

No podemos validar un modelo No podemos validar un modelo aisladamenteaisladamente

Diseñar basándose en Diseñar basándose en comportamientoscomportamientos

Presunciones Presunciones razonablesrazonables (¿cómo (¿cómo acotarlas?)acotarlas?)

1616

Diseño por contratoDiseño por contrato

Preservar las invariantesPreservar las invariantes

Pre y pos-condicionesPre y pos-condiciones

– La redeclaración de una rutina (en una derivación) debe La redeclaración de una rutina (en una derivación) debe solamente reemplazar la precondición original con una solamente reemplazar la precondición original con una igual o más débil, y la poscondición original con una igual o igual o más débil, y la poscondición original con una igual o más fuerte.más fuerte.

Eiffel soporta nativamente DBCEiffel soporta nativamente DBC En .NET ó Java usamos Unit TestsEn .NET ó Java usamos Unit Tests

1717

Un ejemplo más complejo (1)Un ejemplo más complejo (1)

ListaLista

ListaListailimitadailimitada

ListaListalimitadalimitada

ListaListailimitadailimitada

ListaListalimitadalimitada

LibreríaLibrería

1818

Un ejemplo más complejo (2)Un ejemplo más complejo (2)

ListaLista

ListaListapersistentepersistente

ListaListapersistentepersistente

LibreríaLibrería

ListaListapersistentepersistente

1919

Un ejemplo más complejo (3)Un ejemplo más complejo (3)

ContenedorContenedor

ListaListapersistentepersistente

LibreríaLibrería

ListaListapersistentepersistente

Quitar(T)Quitar(T)

Existe(T)Existe(T)

ListaLista

Agregar(T)Agregar(T)

ListaListaPersistentePersistenteAgregar(T)Agregar(T)

2020

Inversión de dependenciaInversión de dependencia

a)a) Los módulos de alto nivel no deben Los módulos de alto nivel no deben depender de los módulos de bajo nivel. depender de los módulos de bajo nivel. Ambos deben depender de abstracciones.Ambos deben depender de abstracciones.

b)b) Las abstracciones no deben depender de Las abstracciones no deben depender de detalles. Los detalles deben depender de detalles. Los detalles deben depender de las abstracciones.las abstracciones.

Es el principio general detrás del concepto Es el principio general detrás del concepto de Layers o Capas.de Layers o Capas.

2121

Capas acopladasCapas acopladas

CapaCapaPolíticaPolítica

CapaCapaMecanismoMecanismo

CapaCapaUtilidadUtilidad

2222

Política

Política

Meca

nism

oM

eca

nism

oU

tilidad

Utilid

ad

Capas desacopladasCapas desacopladas

CapaCapaPolíticaPolítica

CapaCapaMecanismoMecanismo

CapaCapaUtilidadUtilidad

<<interface>><<interface>>

Servicio deServicio depolíticaspolíticas

<<interface>><<interface>>

Servicio deServicio demecanismosmecanismos

2323

Dependencia de InterfacesDependencia de Interfaces

Responder a interfaces desacoplaResponder a interfaces desacopla La propiedad de la interfaz debe ser del clienteLa propiedad de la interfaz debe ser del cliente Principio de Hollywood: Principio de Hollywood:

“No nos llame, lo llamaremos”“No nos llame, lo llamaremos” Depender de abstracciones como ideal implica:Depender de abstracciones como ideal implica:

– Las variables no deben apuntar a clases concretasLas variables no deben apuntar a clases concretas– Las clases no deberían derivar de clases concretasLas clases no deberían derivar de clases concretas– Los métodos no deberían sobrescribir una implementación Los métodos no deberían sobrescribir una implementación

de su clase base.de su clase base.– Excepciones: Factories (excepto si son reflectivas)Excepciones: Factories (excepto si son reflectivas)

Cambiar las interfaces sólo si el cliente (su dueño) Cambiar las interfaces sólo si el cliente (su dueño) lo necesita.lo necesita.

2424

Segregación de InterfazSegregación de Interfaz

Los clientes no deben ser forzados a depender Los clientes no deben ser forzados a depender de métodos que no usan.de métodos que no usan.

Apunta a evitar las interfaces “gordas”.Apunta a evitar las interfaces “gordas”.

No importa la cantidad de métodos, sino que todos No importa la cantidad de métodos, sino que todos sus clientes las utilicen.sus clientes las utilicen.

Inadvertidamente podemos Inadvertidamente podemos acoplar clientesacoplar clientes que usan que usan ciertos métodos con ciertos métodos con otros clientes otros clientes que no los usan.que no los usan.

2525

Una interfaz engordaUna interfaz engorda

PuertaPuerta

+ Trabar()+ Trabar()

+ Destrabar()+ Destrabar()

+ Abierta()+ Abierta()

TimerTimer<<interface>><<interface>>

Cliente TimerCliente Timer

+ TimeOut()+ TimeOut()

PuertaPuerta

Puerta Puerta temporizadatemporizada

2626

Separación por delegaciónSeparación por delegación

TimerTimer<<interface>><<interface>>

Cliente TimerCliente Timer

+ TimeOut()+ TimeOut()

PuertaPuerta

Puerta Puerta temporizadatemporizada

Adapter Puerta Adapter Puerta

TemporizadaTemporizada

+ TimeOut()+ TimeOut()

<<instancia<<instancia>>>>

+ TimeOutPuerta()+ TimeOutPuerta()

2727

Separación por herencia Separación por herencia múltiplemúltiple

TimerTimer<<interface>><<interface>>

Cliente TimerCliente Timer

+ TimeOut()+ TimeOut() PuertaPuerta

Puerta Puerta

TemporizadaTemporizada

+ TimeOut()+ TimeOut()

2828

Agile ModelingAgile Modeling

Modelado livianoModelado liviano Soporta XP, RUP, Soporta XP, RUP,

otrosotros Basado en valores Basado en valores

XPXP

Principios XP másPrincipios XP más– Modelar con un Modelar con un

propósitopropósito– Múltiples modelosMúltiples modelos– Viajar livianoViajar liviano

2929

Prácticas de AMPrácticas de AM

Modelar con clientesModelar con clientes Aplicar los artefactos correctosAplicar los artefactos correctos Considerar pruebasConsiderar pruebas Varios Modelos en paraleloVarios Modelos en paralelo Modelos sencillos y públicosModelos sencillos y públicos Iterar hacia otro artefactoIterar hacia otro artefacto Modelado incrementalModelado incremental Modelar con otrosModelar con otros Comprobar con códigoComprobar con código Herramientas simples (papel y lápiz)Herramientas simples (papel y lápiz)

3030

Espacio de trabajoEspacio de trabajo

Compatible con espacio XPCompatible con espacio XP Pizarrones y cámaraPizarrones y cámara Paredes para colgar modelosParedes para colgar modelos Mesa amplia de trabajoMesa amplia de trabajo Libros de referencia a manoLibros de referencia a mano Libre de sillas en la Zona de ModeladoLibre de sillas en la Zona de Modelado

3131

Agile Modeling y XPAgile Modeling y XPStand Up

Meeting at9:00

Pair Up -- QuickDesign Session

Test Q&A

Code Refactor

Integrate orToss

Go Home at17:00

3232

RequerimientosRequerimientos

Casos de Uso esenciales y Casos de Casos de Uso esenciales y Casos de cambioscambios

Prototipos de Interfaz de UsuarioPrototipos de Interfaz de Usuario Diagramas de flujo de la IUDiagramas de flujo de la IU Modelos CRCModelos CRC Reglas de negociosReglas de negocios Limitantes – Requerimientos técnicosLimitantes – Requerimientos técnicos Historias de UsuarioHistorias de Usuario CaracterísticasCaracterísticas

3333

Ejemplo: Casos de UsoEjemplo: Casos de Uso

Instructor

Grade Admistrator

Input marks

Student

Researcher

Enroll in seminar

Finish seminar

Attend seminar

Drop seminar

Registrar

Pay Fees

Inform Student ofGrades

Produce FeeSchedule

Teach Seminar

Obtain StudentGrant

Obtain StudentLoan

Reimburse CourseFees

Drop out ofSchool

Graduate FromSchool

Notify Students ofSchedule Changes

Produce TeachingSchedule

Apply for Grant

3434

Ejemplo: Prototipo IUEjemplo: Prototipo IU

3535

Ejemplo: Modelo CRCEjemplo: Modelo CRC

Student <<Actor>>

Provide information about selfRequest to enroll in seminarRequest Transcript

Enroll in SeminarTranscript

Enroll in Seminar <<UI>>

**See the prototype**Request identifying info for studentEnable seminar searchDisplay seminar listDisplay seminar feesDisplay professor info

Student

SeminarSeminar, ProfessorStudentProfessor

Transcript <<UI>>

**See the prototype**Get student infoGet seminars student tookDetermine average markOutput self

StudentSeminarProfessorEnrollment Record

Seminar

NameSeminar numberFeesWaiting listEnrolled studentsInstructorAdd studentDrop student

StudentProfessor

Enrollment Record

Mark(s) receivedAverage to dateFinal gradeStudentSeminar

.

Professor

NameAddressPhone numberEmail addressSalaryProvide informationSeminars instructing

Seminar

Student

NameAddressPhone numberEmail addressStudent numberAverage mark receivedValidate identifying infoProvide list of seminars taken

Enrollment Record

3636

AnálisisAnálisis

Elabora sobre los requerimientosElabora sobre los requerimientos Avanza en artefactos (simples)Avanza en artefactos (simples)

– Diagramas UMLDiagramas UML– Prototipos detalladosPrototipos detallados– Diagramas de flujoDiagramas de flujo– Diseño de interfaces externasDiseño de interfaces externas

En XP sigue sin ser una fase, sino En XP sigue sin ser una fase, sino parte del proceso de desarrolloparte del proceso de desarrollo

3737

Ejemplo: Prototipo IUEjemplo: Prototipo IU

3838

Ejemplo: UMLEjemplo: UML

3939

DiseñoDiseño

Determinación genérica de distribuciónDeterminación genérica de distribución Esquema de colaboración generalEsquema de colaboración general Diseño general de modelos de datosDiseño general de modelos de datos Consideración de Patrones posiblesConsideración de Patrones posibles

¿Hasta dónde llegar ¿Hasta dónde llegar en papelen papel?? ¿Cuánto invertir antes del código?¿Cuánto invertir antes del código?

Consideración de escenariosConsideración de escenarios

4040

BibliografíaBibliografía

John HuntJohn Hunt David WestDavid West

Matt Weisfeld Matt Weisfeld Bertrand MeyerBertrand Meyer

Rebecca Wirfs-Rebecca Wirfs-Brock Brock

Scott AmblerScott Ambler

4141

PreguntasPreguntas

?? msalias@gmail.commsalias@gmail.com

www.Salias.com.arwww.Salias.com.ar

Universal Thread Universal Thread www.UniversalThread.comwww.UniversalThread.com