INTRODUCCIN El diseo OO es difcil y el diseo de software orientado a objetos reutilizable lo es an ms. Los diseadores expertos no resuelven los problemas desde sus principios; reutilizan soluciones que han funcionado en el pasado. Se encuentran patrones de clases y objetos de comunicacin recurrentes en muchos sistemas orientados a objetos. Estos patrones resuelven problemas de diseo especficos y hacen el diseo flexible y reusable. Bibliotecas de clases. Frameworks. Assets de grano grueso. Tcnicas y/o herramientas refactorizacin. Programacin Extrema.
de
Tambin hay patrones de Anlisis, de Arquitectura, de Interfaz de usuario, de diseo Web, incluso hay Anti-patrones. VENTAJAS DISEO DE LOS PATRONES DE
Facilitan la localizacin de los objetos que formarn el sistema. Facilitan la determinacin de la granularidad adecuada. Especifican interfaces para las clases. Especifican parciales). implementaciones (al menos
DEFINICIN DE UN PATRN Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno y describe tambin el ncleo de la solucin al problema, de forma que puede utilizarse un milln de veces sin tener que hacer dos veces lo mismo. Alexander (arquitecto/urbanista) Disponemos de las tcnicas bsicas de la Orientacin a objetos, sin embargo. Encontrar las clases es difcil. Estructurar bien las clases es ms difcil. Hacerlo de forma reutilizable es ms difcil an
Facilitan el aprendizaje y la comunicacin entre programadores. CLASIFICACIN Respecto a su propsito: Creacionales: Resuelven problemas relativos a la creacin de objetos. Estructurales: Resuelven problemas relativos a la composicin de objetos. De Comportamiento: Resuelven problemas relativos a la interaccin entre objetos
Necesitamos tcnicas y estrategias que nos guen en la construccin de buenos sistemas orientados a objetos. Ayudando a construir clases Ayudando a estructurar sistemas
Respecto a su mbito: Clases Relaciones estticas entre clases. Objetos Relaciones dinmicas entre objetos.
Un patrn de diseo es una descripcin de clases y objetos comunicndose entre s, adaptada para resolver un problema general de diseo en un contexto particular. Un patrn de diseo es una solucin a un problema en un contexto. QU NO DISEO SON LOS PATRONES DE
Participantes: PLANTILLA GENERAL DE DESCRIPCIN DE UN PATRN OBJETIVO: Define la interfaz que espera el cliente. ADAPTABLE: Implementa la interfaz incompatible que necesitamos adaptar. ADAPTADOR: Implementa la interfaz de OBJETIVO mediante llamadas al objeto adaptado.
Colaboraciones: ADAPTADOR (ADAPTER) (GOF P.131) Intencin: Convierte la interfaz de una clase en otra interfaz esperada por los clientes. Permite la cooperacin de clases que de otro modo seran incompatibles. Motivacin: Necesitamos reutilizar clases ajenas para nuestro sistema, pero, aunque la funcionalidad de estas clases es la que deseamos, la interfaz no es compatible. Si no podemos o no queremos modificar las clases a reutilizar, necesitamos hacerlas compatibles con nuestro sistema. Observacin: Este patrn tiene dos versiones, una con mbito en clases y otra con mbito en objetos, pero nosotros nos centraremos en la segunda versin. Los clientes utilizan la interfaz OBJETIVO. Sus peticiones son recogidas por un adaptador que las redirige al objeto adaptado.
Consecuencias: Un adaptador puede funcionar con varios adaptables de forma simultnea, coordinando sus tareas. Si se necesita redefinir el comportamiento de ADAPTABLE basta construir un heredero y hacer que el adaptador lo adapte. Introduce un nivel de indireccin extra para satisfacer las peticiones del cliente.
COMPUESTO (COMPOSITE) (GOF P.151) Intencin: Componer objetos en jerarquas todo-parte y permitir a los clientes tratar objetos simples y compuestos de manera uniforme. Motivacin: Necesitamos representar un conjunto de elementos de una interfaz grfica de usuario (GUI).
COMANDO (COMMAND) (GOF P.215) Intencin: Encapsula una peticin en un objeto. Permite con ello parametrizar a los clientes con diferentes peticiones y almacenar peticiones para deshacerlas en caso necesario Motivacin: Parametrizacin de las acciones a realizar por los objetos GUI de un framework (como hace eGTK).
Participantes: COMPONENTE: Declara la interfaz comn para todos los objetos de la composicin e implementa acciones por defecto cuando sea apropiado. Tambin puede proporcionar la interfaz de acceso a hijos y padres. SIMPLE: Representa los objetos simples e implementa su comportamiento comn. COMPUESTO: Representa los objetos con hijos, almacenando a stos e implementando las operaciones de acceso y mantenimiento relacionadas con ellos.
Participantes: COMANDO: Declara la interfaz para ejecutar una operacin. COMANDO_CONCRETO: Define una relacin entre un receptor y una accin, redefiniendo la operacin ejecutar para que se enve una peticin adecuada al receptor. CLIENTE: Crea un comando concreto indicndole cul es su receptor. EMISOR: Pide al comando que lleve a cabo una peticin. RECEPTOR: Sabe cmo realizar la operacin relacionada con una peticin-
Colaboraciones: Los clientes utilizan la interfaz de COMPONENTE. Los objetos simples contestan directamente, mientras que los compuestos pueden reenviar la operacin a sus componentes. Los objetos que construyen la estructura deben ser clientes tanto de SIMPLE como de COMPUESTO.
Participantes: Consecuencias: La intermediacin de comando desacopla emisor y receptor. Permite manipular comandos tratados como objetos. Permite aadir nuevos comandos sin alterar las otras clases. Aplicando el patrn compuesto podemos obtener comandos complejos (macros). Los comandos pueden ser ms o menos inteligentes (solicitar un trabajo al receptor, o realizar tareas ms complejas). Se puede adaptar la infraestructura para la opcin deshacer comando, ya sea de un nivel o de varios niveles (posiblemente eso requiera almacenar el estado previo del receptor). SUJETO: Mantiene una lista de observadores y proporciona una interfaz para su gestin. OBSERVADOR: Define una interfaz para actualizar los objetos que deben reflejar los cambios en el sujeto. SUJETO_CONCRETO: Enva una notificacin a sus observadores cuando cambia su estado. OBSERVADOR_CONCRETO: Mantiene una referencia a una sujeto concreto, almacenando parte de su estado e implementado la interfaz de OBSERVADOR
Colaboraciones: El SUJETO_CONCRETO notifica a sus observadores de los cambios que sufre. Los observadores concretos solicitan a su sujeto los datos necesarios para mantener la consistencia con su nuevo estado.
Intencin: Definir una dependencia entre un objeto y un conjunto de ellos, de modo que los cambios en el primero se vean reflejados en los otros. Motivacin: En un toolkit de GUI necesitamos separar los objetos de presentacin de los objetos que modelan los datos interesantes para la aplicacin, de
Participantes: Consecuencias: Permite reutilizar sujetos y observadores por separado. Permite aadir nuevos observadores sin modificar al sujeto o a otros observadores. Que el sujeto no informe a sus observadores de qu cambio ha sufrido permite mantener el acoplamiento en un nivel bajo, puesto que el observador slo pide los datos del estado del sujeto que le interesan. Aunque el observador no est interesado en ciertos cambios del sujeto ser notificado de ellos. Se pueden realizar implementaciones con observadores que coordinan informacin sobre varios sujetos. ITERADOR: Define la interfaz comn para recorrer todos los agregados y acceder a ellos. AGREGADO: Define la interfaz de creacin del iterador. ITERADOR_CONCRETO: Implementa la interfaz de ITERADOR y mantiene la posicin actual del iterador. AGREGADO_CONCRETO: Implementa la interfaz de creacin de los iteradores.
Colaboraciones: El iterador concreto mantiene la informacin actualizada sobre el recorrido que se est realizando sobre el agregado.
Consecuencias: Podemos variar la forma de recorrer el agregado sin ms que cambiar el iterador. Varias formas diferentes de recorrido pueden ser encapsuladas en una jerarqua de iteradores. La interfaz del agregado resulta ms simple al implementar menos operaciones de recorrido. Permite el recorrido simultneo con varios iteradores, utilizando varios algoritmos para el mismo. Hay muchas alternativas de implementacin: Iterador interno o externo, cursor, iterador robusto. La interfaz del iterador puede tener elementos adicionales (anterior, busca)
ITERADOR (ITERATOR) (GOF P.237) Intencin: Permite acceder secuencialmente a los elementos de un agregado sin exponer su estructura interna. Motivacin: Necesitamos implementar una estructura de datos compleja. Deseamos proteger a los clientes de la estructura frente a los detalles de implementacin de la misma. Permitiendo incluso que el cambio de su implementacin no afecte a los clientes.
MODELO DE CASOS DE USO Los casos de uso se utilizan para mejorar la comprensin de los requerimientos. CASO DE USO. Es una secuencia de acciones que dan un resultado observable para un actor particular. Describen un proceso de principio a fin, suele abarcar muchos pasos o transacciones; normalmente no es un paso ni una actividad individual del proceso.
Caractersticas de un Modelo de Caso de uso Describen la funcionalidad del sistema desde la perspectiva del usuario. Muestran una interaccin tpica entre un usuario y un sistema de cmputo. Especifican sistema. el contexto de un
Desplegar los lmites de un sistema sus principales funciones mediante casos de uso. Representar la estructura esttica de un sistema usando diagramas de clases. Modelar los lmites de un objeto con diagramas de estados. Mostrar la arquitectura de la implementacin fsica con diagramas de componentes y de emplazamiento o despliegue.
Capturan los requerimientos de mi sistema. Validan la arquitectura del sistema. Manejan el desarrollo y genera casos de prueba. Desarrollados por analistas y expertos del dominio del problema ACTOR. Es un rol que un usuario puede tener dentro del sistema al interactuar con este. Un usuario puede ser una persona o un sistema externo.
Ventajas de UML Ser un estndar abierto. Soporta la totalidad del ciclo de vida de desarrollo de software. Soporta diversas reas de aplicacin.
Los actores llevan a cabo casos de uso. Un mismo actor puede realizar muchos casos de uso, y un caso de uso puede tener a varios actores.
Casos de uso esenciales. Permiten captar la esencia del proceso y sus motivos fundamentales, sin verse abrumado con detalles de diseo. Los casos de alto nivel siempre son de carcter esencial. Casos de uso reales. Describen el proceso a partir de su diseo concreto actual, sujeto a las tecnologas especficas de entrada y salida.
RELACIONES ENTRE CASOS DE USO Aparte de los vnculos entre los actores y los casos de uso, UML define tres tipos de vnculos include (incluir). Una relacin include ocurre cuando se tiene una porcin de comportamiento que es similar en ms de un caso de uso y no se quiere copiar la descripcin de tal conducta. Para include, es frecuente que no haya un actor asociado con el caso de uso comn. Y si lo llega a tener, no se considera que est llevando a cabo los dems casos de uso. extend (extiende). Una relacin extend se ocupan cuando se tiene un caso de uso que es similar a otro, pero que hace un poco ms. Es usada para incluir comportamiento adicional bajo situaciones particulares. En
Los casos de uso reales se crean normalmente durante la fase de diseo en un ciclo de desarrollo. EJEMPLO DE UN DIAGRAMA DE CASOS DE USO
muestra las clases (descripciones de objetos que comparten caractersticas comunes) que componen el sistema y como se relacionan entre s. Nombre del Objeto Cada objeto es representado como un rectngulo, el cual contiene el nombre del objeto y su clase subrayada y separada por dos puntos. Atributos del objeto Notacin de UML para representar una nota: Notacin de UML para representar una clase:
Puedes listar todos los atributos del objeto en un compartimiento separado. Los atributos de los objetos deben tener valores asignados.
Enlazado a si mismo Objetos que desempean mas de un rol pueden ser enlazados a si mismos. Por ejemplo, Ejemplos
Por lo tanto los diagramas de clases son la espina dorsal de casi todos los mtodos orientados a objetos ya que describen la estructura esttica del sistema GENERALIZACIN La actividad de identificar los aspectos comunes de las clases y en definir las relaciones entre la superclase y la subclase. La generalizacin es otro nombre para la herencia o es una relacin. Refirindose a una relacin entre dos clases, donde una clase es una versin especializada de otro. En ejemplos verdaderos de la codificacin de la vida, la diferencia entre la herencia y la agregacin pueden ser confusas. Si usted tiene una relacin de la agregacin, el agregado (el conjunto) puede tener acceso solamente a las funciones
DIAGRAMA DE CLASES El diagrama de clase describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones estticas que existen entre ellos. En otras palabras
Restricciones de generalizacin. o o Complete: La generalizacin ya no permite ms hijos. Incomplete: Podemos incorporar ms hijos a la generalizacin. Disjoint: solo puede tener un tipo en tiempo de ejecucin, una instancia del padre solo podr ser de un tipo de hijo. Overlapping: puede cambiar de tipo durante su vida, una instancia del padre puede ir cambiando de tipo entre los de sus hijos.
Estereotipos de relacin Clase-objeto. Bind. La clase utilizada es una plantilla, y necesita de parmetros para ser utilizada, con Bind se indica que la clase se instancia con los parmetros pasndole datos reales para sus parmetros. Derive. Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un atributo depende directamente del valor de otro. Es decir el atributo edad depende directamente del atributo Fecha nacimiento. Friend. Especifica una visibilidad especial sobre la clase relacionada. Es decir podr ver las interioridades de la clase destino. InstanceOF. Indica que el objeto origen es una instancia del destino. Instantiate. Indica que el origen crea instancias del destino. Powertype. Indica que el destino es un contenedor de objetos del origen, o de sus hijos.
Esta relacin es representada entre los elementos por medio de una flecha con la punta de flecha grande y hueca que seala el elemento ms general partiendo del ms especializado.
ASOCIACIN Especifica que los objetos de una clase estn relacionados con los elementos de otra clase. Se representa mediante una lnea continua, que une las dos clases. Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregacin.
Lnea de vida. Representa la vida del objeto durante la interaccin que es la lnea vertical mediante lneas discontinuas verticales. Destruir Objetos. Los objetos se pueden terminar temprano usando una flecha etiquetada <<Destroy>>, o sealado con una X. Mtodos recursivos. Es un rectngulo adyacente a la activacin principal y con lneas de llamada de mensajes, que indican la entrada y salida de la recursin. DIAGRAMAS DE COLABORACIN
DIAGRAMA DE SECUENCIA Los diagramas de secuencia muestran la interaccin de un conjunto de objetos a travs del tiempo. Esta descripcin es importante porque nos proporciona la interaccin entre los objetos que se sucede en el tiempo, para un escenario especfico durante la ejecucin del sistema. Los diagramas de secuencia incluyen secuencias temporales pero no incluyen las relaciones entre objetos. Pueden existir de forma de descriptor (describiendo todos los posibles escenarios) y en forma de instancia (describiendo el escenario real). Los principales componentes de este diagrama se representa con y son: Clases de roles Describen la manera en que un objeto se comportara en contexto, este es el diagrama utilizado por UML. Activacin. Las cajas de activacin representan el tiempo que un objeto necesita terminar una tarea. Mensajes. Son las flechas que representan la comunicacin entre los objetos. Teniendo tambin los mensajes asncronos que se enviando un objeto que no espere una respuesta del receptor antes de continuar sus tareas.
En estos diagramas los objetos se muestran como iconos, describiendo las interacciones entre los objetos de un formato de grafo o red. Permitindonos apreciar otros aspectos de la vinculacin de los objetos, ayudando a determinar agrupaciones de los mismos Componentes Colaboracin de un Sistema de
10
Enlaces. Se representa como una lnea continua que une a dos objetos. En los diagramas de colaboracin hay dos caractersticas que los distinguen de los diagramas de secuencia: Path. El path indica qu tipo de objeto recibe el mensaje. Nmero de secuencia. Indica el orden de un mensaje dentro de la interaccin.
Mensajes. Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un nmero de secuencia, una lista opcional de mensajes precedentes, una condicin opcional de guarda, un nombre y una lista de argumentos y un nombre de valor de retorno opcional. Flujo de mensajes. El flujo de mensajes, tambin llamado flujo de control, expresa el envo de los mensajes.
11
ESTADO INICIAL. Este estado es representado con un crculo relleno seguido de una flecha ESTADO FINAL. Es representado por con una lnea que apunta a un circulo relleno el cual esta dentro de otro circulo. La sintaxis completa de una etiqueta de transicin tiene tres partes: Evento. Condicin. Accin. Elementos estado: de un
Transicin interna. Es una transicin que permanece en el mismo estado. Se denota como una cadena adicional en el compartimiento de acciones del estado. Transaccin compleja. Una transicin compleja relaciona tres o ms estados en una transicin de mltiples fuentes. Representa la subdivisin en hilos del control del objeto. Transicin a estados anidados. Es la transicin hacia el estado inicial del
Evento de entrada. Se ejecuta siempre que se entre al estado a travs de una transicin. Evento de salida. Siempre que se sale del estado por medio de una transicin.
12
subestado. Las transiciones que salen del estado compuesto son las transiciones desde cada uno de los subestados hacia fuera. DIAGRAMAS DE ACTIVIDADES Son ocupados esencialmente para descripciones de comportamiento de los sistemas que contienen procesos potencialmente paralelos. Los diagramas de actividades pueden manejar procesos paralelos, determinando el orden en que se harn las actividades. En los procesos concurrentes es necesario especificar las sincronizaciones; para lograr esto, el diagrama de actividades proporciona la barra de sincronizacin, que indica que el disparo de salida ocurre slo cuando se ha llevado a cabo todos los disparos de entrada. Carriles
Un diagrama de despliegue trata de capturar la topologa de un sistema de hardware. Trata de ubicar la distribucin de los componentes y ayuda a identificar los cuellos de botella. La combinacin de los diagramas de componentes y de despliegue muestra las relaciones fsicas entre los componentes de software y de hardware del sistema. DIAGRAMA DE COMPONENTES
Los carriles son una forma de disminuir esta deficiencia de los diagramas de actividades. La idea de los carriles es acomodar los diagramas de actividades en zonas verticales separadas por lneas punteadas. Cada zona representa responsabilidad de una clase en particular. El objetivo de estos es combinar la representacin lgica de los diagramas de actividades con la representacin lgica de los diagramas con la representacin de las responsabilidades de los diagramas de interaccin. DIAGRAMAS DE COMPONENTES Y DE DESPLIEGUE Representa la estructura fsica de la implementacin. Forma parte de la
Se utilizan para modelar la vista esttica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. COMPONENTE. Un componente es un bloque de una estructura fsica del sistema.
13
http://hillside.net/patterns/. (s.f.). Patterns Home Page. Recuperado el 25 de Agosto de 2011, de http://hillside.net/patterns/ Jean-Marc Jzquel, M. T. (1999). Design Patterns and contracts. Addison Wesley. Prieto, F. (s.f.). Universidad de Valladolid. Recuperado el 24 de Agosto de 2011, de Universidad de Valladolid
DEPENDENCIA. Dibuja dependencias entre los componentes usando flechas punteadas. DIAGRAMA DE DESPLIEGUE En el diagrama de despliegue se indica la situacin fsica de los componentes lgicos desarrollados. Es decir se sita el software en el hardware que lo contiene. Cada Hardware se representa como un nodo. NODO. Un nodo de un recurso fsico que ejecuta cdigo de componentes.
BIBLIOGRAFA:
14