patrones de diseño-tapia rodriguez jose de jesus

19
Patrones de diseño 2011 INTRODUCCIÓN El diseño OO es difícil y el diseño de software orientado a objetos reutilizable lo es aún más. Los diseñadores expertos no resuelven los problemas desde sus principios; reutilizan soluciones que han funcionado en el pasado. Se encuentran patrones de clases y objetos de comunicación recurrentes en muchos sistemas orientados a objetos. Estos patrones resuelven problemas de diseño específicos y hacen el diseño flexible y reusable. DEFINICIÓN DE UN PATRÓN Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y describe también el núcleo de la solución al problema, de forma que puede utilizarse un millón de veces sin tener que hacer dos veces lo mismo. Alexander (arquitecto/urbanista) Disponemos de las técnicas básicas de la Orientación a objetos, sin embargo. Encontrar las clases es difícil. Estructurar bien las clases es más difícil. Hacerlo de forma reutilizable es más difícil aún Necesitamos técnicas y estrategias que nos guíen en la construcción de buenos sistemas orientados a objetos. Ayudando a construir clases Ayudando a estructurar sistemas Un patrón de diseño es una descripción de clases y objetos comunicándose entre sí, adaptada para resolver un problema general de diseño en un contexto particular. Un patrón de diseño es una solución a un problema en un contexto. QUÉ NO SON LOS PATRONES DE DISEÑO Patrones de diseño no es lo mismo que: Bibliotecas de clases. Frameworks. Assets de grano grueso. Técnicas y/o herramientas de refactorización. Programación Extrema. También hay patrones de Análisis, de Arquitectura, de Interfaz de usuario, de diseño Web, incluso hay Anti-patrones. VENTAJAS DE LOS PATRONES DE DISEÑO Facilitan la localización de los objetos que formarán el sistema. Facilitan la determinación de la granularidad adecuada. Especifican interfaces para las clases. 1 Tapia Rodríguez José de Jesús Instituto Tecnológico de Morelia

Upload: salvador-joanathan-villagomez-cardenas

Post on 26-Nov-2015

23 views

Category:

Documents


0 download

TRANSCRIPT

Patrones de diseo

Patrones de diseo2011

INTRODUCCINEl 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.DEFINICIN DE UN PATRNCada 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 anNecesitamos tcnicas y estrategias que nos guen en la construccin de buenos sistemas orientados a objetos. Ayudando a construir clases Ayudando a estructurar sistemas 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 son los patrones de diseoPatrones de diseo no es lo mismo que: Bibliotecas de clases. Frameworks. Assets de grano grueso. Tcnicas y/o herramientas de refactorizacin. Programacin Extrema.Tambin hay patrones de Anlisis, de Arquitectura, de Interfaz de usuario, de diseo Web, incluso hay Anti-patrones.Ventajas de los patrones de diseoFacilitan la localizacin de los objetos que formarn el sistema.Facilitan la determinacin de la granularidad adecuada.Especifican interfaces para las clases.Especifican implementaciones (al menos parciales).Facilitan el aprendizaje y la comunicacin entre programadores.ClasificacinRespecto 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 objetosRespecto a su mbito: Clases Relaciones estticas entre clases. Objetos Relaciones dinmicas entre objetos.

Los patrones del GoF.

Plantilla general de descripcin de un patrn

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.

Participantes: 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: 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).Algunos de estos elementos son simples, mientras que otros estn formados por varios elementos ms simples.El comportamiento y/o la informacin que proporciona un elemento complejo est determinada por los elementos que lo componen.

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.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.Consecuencias: Permite el tratamiento uniforme de objetos simples y complejos. Simplifica el cdigo de los clientes, que usan una sola interfaz. Permite aadir componentes nuevas sin afectar a los clientes. Es difcil restringir los tipos de los hijos. Definir las operaciones de gestin de los hijos en COMPONENTE crea problemas de consistencia con los hijos.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 necesarioMotivacin: Parametrizacin de las acciones a realizar por los objetos GUI de un framework (como hace eGTK).

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: El cliente crea un comando concreto indicndole cul es su receptor. El emisor almacena uno o varios comandos concretos. El emisor solicita al comando que se ejecute. El comando pide al receptor que realice las operaciones necesarias.

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).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 forma que se puedan tener varias vistas sincronizadas de los mismos datosObservador (Observer) (GoF p.269)

Participantes: 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 OBSERVADORColaboraciones: 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.

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 (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.

Participantes: 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)

U M LUNIFIED MODELING LANGUAGEEl Lenguaje Unificado de Modelado (Unified Modeling Language, UML) es ahora el esquema de representacin grfica ms utilizado para modelar sistemas orientados a objetos. UML no es un lenguaje de programacin, sino un lenguaje de modelado visual que se utiliza para especificar, visualizar, construir y documentar los componentes de un sistema de software, ya que capta la informacin sobre la estructura esttica y el comportamiento dinmico de un sistema. UML entrega una forma de modelar los aspectos conceptuales del diseo de software como lo son procesos de negocio y funciones de sistema, adems de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software que puede ser reutilizableUML es utilizado para realizar las siguientes funciones: 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.Ventajas de UML Ser un estndar abierto. Soporta la totalidad del ciclo de vida de desarrollo de software. Soporta diversas reas de aplicacin. Est basado en la experiencia y necesidades de la comunidad de usuarios. Es soportado actualmente por diversas herramientas.MODELO DE CASOS DE USOLos 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 el contexto de un sistema. 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.Estructura de los Modelos de Casos de UsoAunque forman parte de UML no se propone un formato rgido, para que se adapte a las necesidades del equipo de desarrollo.Es comn que se hable de dos niveles de casos de uso: Casos de uso de alto nivel. Casos de uso expandidos.DIAGRAMAS DE CASOS DE USOUn diagrama de casos de uso explica grficamente un conjunto de casos de uso de un sistema, mostrando la relacin entre estos y los actores. Tiene dos componentes esenciales: actores y casos de uso.

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.RELACIONES ENTRE CASOS DE USOAparte de los vnculos entre los actores y los casos de uso, UML define tres tipos de vnculosinclude (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 esta relacin, los actores tienen que ver con los casos de uso que se estn extendiendo. Un actor entonces se encargar tanto del caso de uso base como de todas las extensiones.specialize (especializar). Una relacin specialize a un caso de uso ms general. El caso de uso especializado refina el flujo de eventos original.TIPOS DE CASOS DE USOCasos 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.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

DIAGRAMA DE OBJETOS

Nombre del ObjetoCada 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

Puedes listar todos los atributos del objeto en un compartimiento separado. Los atributos de los objetos deben tener valores asignados.

Enlazado a si mismoObjetos que desempean mas de un rol pueden ser enlazados a si mismos. Por ejemplo, Ejemplos

DIAGRAMA DE CLASESEl 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 muestra las clases (descripciones de objetos que comparten caractersticas comunes) que componen el sistema y como se relacionan entre s.Notacin de UML para representar una clase:Notacin de UML para representar una nota:

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 sistemaGENERALIZACINLa 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 PBLICAS de la clase de la pieza. Por otra parte, la herencia permite que la clase heredera tenga acceso al PBLICO y a las funciones PROTEGIDAS de los superclases.UML nos permite modificar la relacin de Generalizacin con un estereotipo y dos restricciones. Estereotipo de generalizacin. Implementation: El hijo hereda la implementacin del padre, sin publicar ni soportar sus interfaces. Restricciones de generalizacin. 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.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.ASOCIACINEspecifica 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.DEPENDENCIASEs una relacin de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua va desde la clase utilizadora a la clase utilizada. Con la dependencia mostramos que un cambio en la clase utilizada puede afectar al funcionamiento de la clase utilizadora, pero no al contrario. Aunque las dependencias se pueden crear tal cual, es decir sin ningn estereotipo (palabreja que aparece al lado de la lnea que representa la dependencia) UML permite dar ms significado a las dependencias, es decir concretar ms, mediante el uso de estereotipos. 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. Refine. Se utiliza para indicar que una clase es la misma que otra, pero mas refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.El ejemplo muestra los tres tipos de relaciones en el diagrama de clasesDIAGRAMA DE SECUENCIALos 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 rolesDescriben 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.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 , 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 COLABORACINEn 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 mismosComponentes de un Sistema de ColaboracinObjetos. Un objeto se representa mediante un rectngulo que contiene el nombre y la clase del objeto. Objeto compuesto. Es una representacin alternativa de un objeto y sus atributos. Objeto activo. Un objeto activo es el que contiene su propio flujo de control.Creacin y destruccin de un objeto. Para especificar qu objetos son creados y destruidos en un diagrama de colaboracin, se puede aadir una de las siguientes restricciones y debe estar encerrada entre llaves, cerca del rectngulo del objeto: New. Destroyed. Transient. 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.

Flujos Become. El diagrama de colaboracin contiene un smbolo para un objeto durante una operacin completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explcitos. Los diferentes smbolos de objeto que representan un objeto se pueden conectar usando flujos "become" o "conversion". Un flujo "become" es una transicin, a partir de un estado de un objeto a otro. Se dibuja como una flecha de lnea discontinua con la etiqueta "become" o "conversion" y puede tener un nmero de serie para mostrar cuando ocurre. Un flujo de conversin tambin se utiliza para mostrar la migracin de un objeto a partir de una localizacin a otra. Patrn de diseo. Un diagrama de colaboracin puede especificar un contrato entre objetos, parte esencial para la descripcin de un patrn de diseo. Contexto. Un contexto es una vista de uno o ms elementos dentro del modelo que colaboran en el desarrollo de una accin. DIAGRAMA DE ESTADOAyudan a determinar el comportamiento de los sistemas, ya muestran grficamente los eventos y estados de los objetos. Existen varios Diagramas de estados de casos de uso Diagramas de estado del sistema o subsistema Diagramas de estado de los objetosElementos del diagrama de estadosESTADO. El estado representa situaciones durante la vida de un objeto. Se ilustra con un rectngulo con las puntas redondeadas.Acciones. Una accin es una operacin atmica, que no se puede interrumpir por un evento y que se ejecuta hasta su finalizacin.Actividades. Cuando un objeto est en un estado est esperando a que suceda algn evento. En ocasiones es necesario modelar una actividad que se est ejecutando. Es decir, mientras un objeto est en un estado, dicho objeto realiza un trabajo que continuar hasta que sea interrumpido por un evento. TRANSICIN. Esta flecha nos representa la trayectoria entre diferentes estados. La etiqueta de transicin lleva el evento y la accin que resulta.

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 de un estado:

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.Actividad. Proceso que debe realizar el estadoAutotransicin. Transicin que vuelve al mismo estado.Estados compuestos o superestados. Contiene un conjunto de subestados. Los subestados heredan todas las transiciones sobre el superestado. Un superestado nos ayuda a reducir la saturacin de transiciones entre estados.Los subestados secuenciales son el tipo ms comn de mquina de estado anidada. Los subestados concurrentes permiten especificar dos o ms mquinas de estado que se ejecutan en paralelo.

Transiciones del Diagrama de EstadosTransiciones simples. 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 subestado. Las transiciones que salen del estado compuesto son las transiciones desde cada uno de los subestados hacia fuera.DIAGRAMAS DE ACTIVIDADESSon 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.CarrilesLos 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 DESPLIEGUERepresenta la estructura fsica de la implementacin. Forma parte de la arquitectura de la especificacin y ayuda a proponer: La organizacin del cdigo fuente. La construccin de versiones ejecutables finales. La especificacin de la base de datos.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 COMPONENTESSe 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.

INTERFACE. Describe un grupo de operaciones usadas o creadas por los componentes.

.DEPENDENCIA. Dibuja dependencias entre los componentes usando flechas punteadas.DIAGRAMA DE DESPLIEGUEEn 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.

ASOCIACIN. Se refiere a una conexin fsica entre nodos.

COMPONENTES Y NODOS. Posiciona los componentes dentro de un nodo y los despliega.

BIBLIOGRAFA:Erich Gamma, R. H. (1995). Dessign Patterns. Elements of Reusable. Addison Wesley.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

14Tapia Rodrguez Jos de Jess Instituto Tecnolgico de Morelia