Introdui on al Dise~ no on Patrones Dise~ no de Sistemas Informatios AYER: Programai on estruturada pero sigue en uso... Separaion entre dise~no y odiaion Parte de la idea de que la mayora de los errores se introduen durante el dise~no. Supone que los requerimientos se onoen de antemano y permaneen inalterados durante el ilo de vida. (Horowitz 1993) Cambios o nuevos requerimientos: 30% del oste de desarrollo 70% del oste del mantenimiento Alternativa: Desarrollo en espiral El dise~ no e implementaion proede de forma inremental on gran interaion on el usuario a n de mitigar riesgos. Ejemplo: Rapid Strutured Prototyping Inonveniente: Separaion del modelo de datos del modelo del proeso. Cambios en uno pueden oasionar efetos imprevisibles en el otro. 1 HOY: Analisis, Dise~no e Implementaion OO Orientaion a Objetos: An alisis, Dise~no: UML Implementai on: Lenguaje OO (Java, C++, Delphi,...) Suposiion fundamental: los objetos del dominio son las entidades mas estables del sistema. Un dise~ no basado en estos objetos del dominio sera mas resistente al ambio. Fusiona los modelos de proeso y de datos Ventaja adiional: redue el vao entre el software y los modelos de negoio. Tres elementos fundamentales: An alisis OO, analizar el dominio del problema para onstruir un modelo del mundo real utilizando objetos Dise~ no OO, renamiento de los modelos de analisis para rear espeiaiones adiionales que enriqueen el modelo de analisis on detalles proximos a la implementaion Implementai on, odiaion del dise~no posiblemente utilizando un lenguaje OO 2 Analisis vs Dise~no OO Limites difusos entre analisis y dise~no OO An alisis: investigai on (desripion del problema y requerimientos) Dise~ no: solui on logia (forma en que se umplen los requerimientos: asignaion de responsabilidades, interaiones entre objetos, et.) Soporte An alisis de requerimientos: asos de uso An alisis: modelo oneptual no es una desripi on de omponentes software, sino que representa el dominio del problema. Dise~no: diagrama de lases, olaboraion, estado Cuestiones laves en el dise~no OO: > omo se asignan responsabilidades a las lases? > omo deben interatuar los objetos? >qu e lases deber an haer qu e? 3 Dise~no e Implementai on OO Problema: Sigue habiendo interaiones molestas debidas al uso inadeuado de la OO, por ejemplo, mal empleo de la enapsulaion. Problema: Vao existente entre analisis, dise~no e implementaion El programador debe tomar deisiones de dise~ no Sobrespeiai on Nuevo enfoque: Dise~ no on Patrones Nuevo ollar para un perro viejo: Abstrai on Idea de Christopher Alexander (arquiteto), que aplia el onepto a la onstruion urbanstia. (1977) (1979) A Pattern Language: Towns, Buildings, Constrution The Timeless Way of Building 4 Dise~no on Patrones Objetivo: Agrupar una oleion de soluiones de dise~no que son validas en distintos ontextos y que han sido apliadas on exito en el pasado. Patron de Dise~no: Soluion a un problema de dise~no no trivial que es efetiva y reusable. Es efetiva en el sentido de que ya resolvi o el problema on anterioridad satisfatoriamente. Es reusable si se puede apliar a un abanio de problemas de dise~no en distintas irunstanias. Los patrones son soluiones de sentido omun que ya deberan formar parte del onoimiento de un dise~nador experto. Failitan la omuniaion entre dise~nadores al estableer un maro de referenia: terminologa, justiaion. Failitan el aprendizaje al dise~nador inexperto Esenia: estableer parejas problema-soluion. 5 Aportaiones de los Patrones de Dise~no Identiar los Objetos Apropiados Parte ompliada de la OO: Desomponer un sistema en objetos (enapsulaion, granularidad, dependenias, exibilidad, rendimiento, evoluion, reusabilidad, ...) Determinar la Granularidad de los Objetos Espeiar las Interfaes Identian los elementos lave en las interfaes y las relaiones existentes entre distintos interfaes Failita la distinion \sublase o subtipo" Espeiar las Implementaiones Reutilizar Failita la deision \herenia o omposiion" (herenia de aja blana frente a herenia de aja negra) Gamma et al.: Favoreer omposii on sobre herenia Uso de la delegai on Relaionar Estruturas en Tiempo de Compilaion y en Tiempo de Ejeuion Dise~nar para el Cambio 6 Componentes de un Patron (Culinario) Nombre Desripion Clasiaion Ejemplo motivador Contexto/alane Componentes involurados Algoritmo de preparaion Reetas relaionadas 7 Componentes de un Patron de Dise~no (GoF) Nombre y Clasiaion Estrutural, reai on, omportamiento Proposito (Intent) Otros nombres (Also Known As) Motivaion Esenario que presenta un problema de dise~ no Solui on para el esenario utilizando el patr on Apliabilidad Estrutura (situaiones en las que se puede apliar) (diagrama de lases, olaborai on, estado) Partiipantes Clases y objetos partiipantes Responsabilidades Colaboraiones entre partiipantes Conseuenias (ventajas e inonvenientes de su apliai on) Implementaion (t enias y peligros en la implementai on) Codigo de Ejemplo Usos onoidos (ejemplos del patr on en sistemas reales) Patrones relaionados 8