DIAGRAMAS DE SECUENCIA: UN PASO A LA VEZ A pesar de que a partir de los diagramas de casos de uso y de los diagra mas de robustez

ya tenemos entre un 75 y 80 por ciento de atributos de nuestras clases identificados, es hasta el diagrama de secuencia donde se empiezan a ver que mtodos llevaran las clases de nuestro sistema. Esto se debe que hasta que vem os interactuando a los objetos de nuestras clases con los actores y con otros ob jetos de manera dinmica, hasta ese momento tenemos suficiente informacin como para poder empezar a especificar los mtodos de nuestras respectivas clases. El diagrama de secuencias es el ncleo de nuestro modelo dinmico, y muestra todos los cursos alternos que pueden tomar todos nuestros casos de uso. Los dia gramas de secuencias se componen de 4 elementos que son: el curso de accin, los o bjetos, los mensajes y los mtodos (operaciones). Estos 4 elementos son los que ya han sido analizados en clase con anterioridad dentro de la primera unidad. Los 4 pasos a seguir: A continuacin se dar una muy breve descripcin de los 4 pasos que se deben de seguir para dibujar correctamente diagramas de secuencia de ICONIX: -Paso 1: Copia el texto de la especificacin de tu caso de uso y pgalo en l a parte superior de tu diagrama de secuencia. Con esto siempre se tendr en cuenta que es lo que debe de hacer el diagrama de secuencia. -Paso 2: Cada uno de los objetos entidad de na instancia de la clase que debe de ser agregada a que representa tu modelo esttico. Hay que ser muy ue representa el ultimo de tu modelo esttico antes tu diagrama de robustez es u tu diagrama de secuencias ya meticuloso con este paso, ya q de codificar.

-Paso 3: Agrega las interfaces del diagrama de robustez. Con esto ya ten emos el diagrama de secuencias construido. Ahora, el cuarto paso es para decidir cuales mtodos iran en cuales clases, lo cual es la esencia del modelo de iteracio nes. -Paso 4: Pon los mtodos en las clases, lo cual significa convertir los co ntroles uno por uno de tu diagrama de robustez en mtodos y mensajes. Verifica que para cada control dibujado le pertenecen los mensajes correctos dentro del diag rama de secuencias. Top Ten de errores de los diagramas de secuencia: A continuacin se presentan los 10 errores mas comnmente cometidos por los estudiantes al intentar hacer sus diagramas de secuencia. 10.- No hacen un diagrama de secuencia para cada caso de uso: Hacer esto es muy importante, ya que solo as se puede saber cual es el rol y las responsabi lidades de cada objeto. 9.- No ponen el texto del caso de uso en el diagrama de secuencia: El po ner de vuelta este texto al margen del diagrama de secuencia provee de la visin n ecesaria para poder hacer diagramas de secuencia correctos de acuerdo al caso de uso que se esta modelando. 8.- No identifican todos los objetos necesarios desde el diagrama de rob ustez: Si tienes problemas al realizar los diagramas de secuencia es por que tie nes mal modelados tus casos de uso o tus diagramas de robustez estn incompletos. .6. Diagramas de Actividad El Diagrama de Actividad es un diagrama de flujo del proceso multi-propsito que s e usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un mtodo complicado. Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave

es que los diagramas de actividad pueden mostrar procesado paralelo (parallel p rocessing). Esto es importante cuando se usan diagramas de actividad para modela r procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para m odelar varios hilos en los programas concurrentes. 4.6.1. Usando Diagramas de Actividad para modelar Casos de Uso Los Diagramas de Actividad ofrecen una herramienta grfica para modelar el proceso de un Caso de Uso. Se pueden usar como un aadido a una descripcin textual del cas o de uso, o para listar los pasos del caso de uso. Una descripcin textual, cdigo, u otros diagramas de actividad pueden detallar ms la actividad. 4.6.2. Usando Diagramas de Actividad para modelar Clases Cuando se modela el comportamiento de una clase, un diagrama de estado de UML se suel usar normalmente para modelar situaciones donde ocurren eventos asincrnicos . El diagrama de actividad se usa conado todos o la mayora de los elementos repre sentan el desarrollo de los pasos dados por las acciones generadas internamente. Deberas asignar actividades a las clases antes de terminar con el diagrama de ac tividad. Los mensajes se muestran como flechas entre lneas de vida. Un diagrama de secuenc ia puede mostrar un escenario, es decir, una historia individual de transaccin. U n uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso. Un dilogo de secuencia posee dos dimensiones: la vertical representa el tiempo, l a horizontal representa los objetos que participan en la interaccin. En general, el tiempo avanza hacia abajo dentro de la pgina (se pueden invertir los ejes si s e desea). Con frecuencia slo son importantes las secuencias de mensajes pero en a plicaciones de tiempo real el eje temporal puede ser una mtrica. La ordenacin hori zontal de los objetos no tiene ningn significado. Figura 12: Diagrama de Actividad ________________________________________ Diagrama de Secuencia Ejemplo de Diagrama de Secuencia Diagrama que muestra las interacciones entre los objetos organizadas en una secu encia temporal. En particular muestra los objetos participantes en la interaccin y la secuencia de mensajes intercambiados. Representa una interaccin, un conjunto de comunicaciones entre objetos organizada s visualmente por orden temporal. A diferencia de los diagramas de colaboracin, l os diagramas de secuencia incluyen secuencias temporales pero no incluyen las re laciones entre objetos. Pueden existir de forma de descriptor (describiendo todo s los posibles escenarios) y en forma de instancia (describiendo un escenario re al). Dentro del conjunto de mensajes representados dispuestos en una secuencia tempor al, cada rol en la secuencia se muestra como una lnea de vida, es decir, una lnea vertical que representa el rol durante cierto plazo de tiempo, con la ibnteraccin completa Los mensajes se muestran como flechas entre lneas de vida. Un diagrama de secuenc ia puede mostrar un escenario, es decir, una historia individual de transaccin. U n uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso. Un dilogo de secuencia posee dos dimensiones: la vertical representa el tiempo, l a horizontal representa los objetos que participan en la interaccin. En general, el tiempo avanza hacia abajo dentro de la pgina (se pueden invertir los ejes si s e desea). Con frecuencia slo son importantes las secuencias de mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una mtrica. La ordenacin hor

izontal de los objetos no tiene ningn significado. Un dilogo de secuencia posee dos dimensiones: la vertical representa el tiempo, l a horizontal representa los objetos que participan en la interaccin. En general, el tiempo avanza hacia abajo dentro de la pgina (se pueden invertir los ejes si s e desea). Con frecuencia slo son importantes las secuencias de mensajes pero en a plicaciones de tiempo real el eje temporal puede ser una mtrica. La ordenacin hori zontal de los objetos no tiene ningn significado. Cada objeto representa una columna distinta, se pone un smbolo de objeto al final de la flecha que representa el mensaje que ha creado el objeto; est situada en e l punto vertical que denota el instante en que se crea el objeto. Esta se conoce como lnea de vide del objeto. Se pone una X grande en el punto en que deja de ex istir el objeto o en el punto en que el objeto se destruye a s mismo. Para el per iodo durante el cual est activo el objeto, la lnea de vida se ampla para ser una lne a doble continua. Si el objeto se llama a s mismo, entonces se superpone otra cop ia de la doble lnea para mostrar la doble activacin. El orden relativo de los obje tos no tiene significado an cuando resulta til organizarlos de modo que se minimic e la distancia de las flechas. Cada mensaje se representa mediente una flecha horizontal que va desde la lnea de vida del objeto que envi el mensaje hasta la lnea de vida del objeto que ha recib ido el mensaje. Si un mensaje requiere un cierto tiempo para llegar a su destino , entonces la flecha del mensaje se dibuja diagonalmente hacia abajo. Para un flujo de objeto asncrono entre objetos activos, los objetos se representa n mediante lneas dobles continuas y los mensajes se representan como flechas. Se pueden enviar simultneamente dos mensajes pero no se pueden recibir simultneamente porque no sxe puede garantizar una recepcin simultnea. Las bifurcaciones se muestran partiendo la lnea de vida del objeto. Cada bifurcac in puede enviar y recibir mensajes. Eventualmente las lneas de vida del objeto tie nen que fusionarse de nuevo. Un diagrama de secuencia tambin se puede mostrar en forma de descriptor, en el cu al los constituyentes son roles en lugar de objetos. Este diagrama muestra en el caso general, no una sola ejecucin del mismo. Los diagramas del nivel de descrip tores se dibujan sin subrayados porque los smbolos denotan roles y no objetos ind ividuales. Diagrama de Estado Ejemplo de Diagrama de Estado

Un Diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vrtices (otros elem entos del modelo). Un diagrama no es un elemento semntico, un diagrama muestra re presentaciones de elementos semnticos del modelo, pero su significado no se ve af ectado por la forma en que son representados. Un diagrama est contenido dentro de un paquete. La mayora de los diagramas de UML y algunos smbolos complejos son grafos que conti enen formas conectadas por rutas. La infomacin est sobre todo en la topologa, no en el tamao o la colocacin de los smbolos (hay algunas excepciones como el diagrma de secuencia con un eje mtrico de tiempo). Hay tres clases importantes de relacione s visuales: conexin (generalmente de lneas a formas de dos dimensiones), contencin (de smbolos por formas cerradas de dos dimensiones), y adhesin visual (un smbolo qu e est "cerca" de otro en un diagrama). Estas relaciones geomtricas se reasignan a conexiones entre nodos en un grfico en la forma analizada de la notacin. La notacin de UML est pensada para ser dibujada en superficies bidimensionales. Al gunas formas bidimensionales son proyecciones de formas tridimensionales tales c omo cubos, pero todava se representan como conos en una superficie bidimensional. Hay cuatro clases de construcciones grficas que se usan en la notacin de UML: conos , smbolos bidimensionales, rutas y cadenas.

Un cono es una figura grfica con un tamao y forma fijos. No se ampla para contener a su contenido. Los iconos pueden aparecer dentro de smbolos de rea, como terminado res en las rutas o como smbolos independientes que puedan o no conectar con las r utas. Los smbolos de dos dimensiones tienen altura y anchura variables, y pueden amplia rse para permitir otras cosas tales como listas de cadenas o de otros smbolos. Mu chos de ellos estn divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los smbolos, el arrastrar o suprimir uno de ellos afect a a su contenido y las rutas conectadas. Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus p untos finales. Conceptualmente una ruta es una sola entidad topolgica, aunque sus segmentos se pueden manipular grficamente. un segemento no debera existir separad o de su ruta. Las rutas siempre van conectdas en ambos extremos.

Las cadenas presentan varias clases de informacin en una forma "no analizada", UM L asume que cada uso de una cadena en la notacin tiene una sintaxis por la cual p ueda ser analizada la informacin del modelo subyancente. Las cadenas pueden exist ir como el contenido de un compartimiento, como elementos en las listas, como et iquetas unidas a los smbolos o a las rutas, o como elementos independientes en un diagrama. UML est compuesto por los siguientes diagramas: rea Vista Diagramas Conceptos Principales Estructural Vista Esttica Diagrama de Clases Clase, asociacin, general izacin, dependencia, realizacin, interfaz. Vista de Casos de Uso Diagramas de Casos de Uso Caso de Uso, Act or, asociacin, extensin, generalizacin. Vista de Implementacin Diagramas de Componentes Componente, inte rfaz, dependencia, relaizacin. Vista de Despliegue Diagramas de Despliegue Nodo, componente, depend encia, localizacin. Dinmica Vista de Estados de mquina Diagramas de Estados Estado, evento, transicin, accin. Vista de actividad Diagramas de Actividad Estado, actividad, trans icin, determinacin, divisin, unin. Vista de interaccin Diagramas de Secuencia Interaccin, objeto, mensa je, activacin. Diagramas de Colaboracin Colaboracin, interaccin, rol de colaboraci , mensaje. Administracin o Gestin de modelo Vista de Gestin de modelo Diagramas de Cla ses Paquete, subsistema, modelo. Extensin de UML Todas Todos Restriccin, estereotipo, valores, etiquetados. Diagramas de Objetos Objeto es una entidad discreta con lmites bien definidos y con identidad, es una unidad atmica que encapsula estado y comportamiento. La encapsulacin en un objeto permite una alta cohesin y un bajo acoplamiento. el Objeto es reconocido tambin co mo una instancia de la clase a la cual pertenece. La encapsulacin presenta tres ventajas bsicas: 1. Se protegen los datos de accesos indebidos 2. El acoplamiento entre las clases se disminuye 3. Favorece la modularidad y el mantenimiento Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de un determinado instante de tiempo que posee un valor especfico (Un objeto puede c aracterizar una entidad fsica -coche-) y como un poseedor de identidad que tiene distintos valores a lo largo del tiempo (abstracta -ecuacin matemtica-). Cada objeto posee su propia identidad exclusiva y se puede hacer referencia a l m ediante una denominacin exclusiva que permite accederle. El Modelado de Objetos p ermite representar el ciclo de vida de los objetos a travs de sus interacciones. En UML, un objeto se representa por un rectngulo con un nombre subrayado.

Objeto = Identidad + Estado + Comportamiento El estado est representado por los valores de los atributos. Un atributo toma un valor en un dominio concreto. La regla general para la notacin de instancias consiste en utilizar el mismo smbol o geomtrico que el descriptor. En la instancia se muestran los posibles valores p ero las propiedades compartidas slo se pone de manifiesto en el descriptor. La no tacin cannica es un rectngulo con tres compartimientos. En el primero va el nombre del objeto, en el segundo sus atributos y en el tercero sus operaciones. Este lti mo puede ser omitido si as se prefiere. Oid (Object Identifier) Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las s iguientes caractersticas: Constituye un identificador nico y global para cada objeto dentro del sistema. Es determinado en el momento de la creacin del objeto. Es independiente de la localizacin fsica del objeto, es decir, provee completa ind ependencia de localizacin. Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura. No cambia durante toda la vida del objeto. Adems, un oid no se reutiliza aunque e l objeto deje de existir. No se tiene ningn control sobre los oids y su manipulacin resulta transparente. Si n embargo, es preciso contar con algn medio para hacer referencia a un objeto uti lizando referencias del dominio (valores de atributos). Caractersticas alrededor de un objeto: Estado: El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento agrupa las competencias de un objeto y describe las acciones y re acciones de ese objeto. Las operaciones de un objeto son consecuencia de un estmu lo externo representado como mensaje enviado desde otro objeto. Persistencia: La persistencia de los objetos designa la capacidad de un objeto trascender en e l espacio/tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria sec undaria para utilizarlo en la ejecucin (materializacin del objeto). Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transpar ente, un objeto existe desde su creacin hasta que se destruya. Comunicacin: Un sistema informtico puede verse como un conjunto de objetos autnomos y concurren tes que trabajan de manera coordinada en la consecucin de un fin especfico. El com portamiento global se basa pues en la comunicacin entre los objetos que la compon en. Categoras de objetos: Activos o Pasivos Cliente -- Servidores, Agentes 1. Objeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividad. 2. Objeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio. 3. Cliente es el objeto que solicita un servicio. 4. Servidor es el objeto que provee el servicio solicitado. 5. Los agentes renen las caractersticas de clientes y servidores. Son la base del mecanismo de delegacin. Introducen indireccin: un cliente puede comunicarse c on un servidor que no conoce directamente. Mensajes: La unidad de comunicacin entre objetos se llama mensaje. El mensaje es el soporte de una comunicacin que vincula dinmicamente los objetos que fueron separados prev iamente en el proceso de descomposicin. Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinmico. Un estmulo causar la invocacin de una operacin, la creacin o destruccin de un objeto o la aparicin de una seal. Un mensaje es la esp

ecificacin de un estmulo. Tipos de flujo de control: 1. Llamada a procedimiento o flujo de control anidado 2. Flujo de control plano 3. Retorno de una llamada a procedimiento 4. Otras variaciones 5. Esperado (balking) 6. Cronometrado (time-out) Diagrama de Objetos

Diagramas de Clases El Diagrama de Clases es el diagrama principal para el anlisis y diseo. Un diagram a de clases presenta las clases del sistema con sus relaciones estructurales y d e herencia. La definicin de clase incluye definiciones para atributos y operacion es. El modelo de casos de uso aporta informacin para establecer las clases, objet os, atributos y operaciones. El mundo real puede ser visto desde abstracciones diferentes (subjetividad) Mecanismos de abstraccin: 1. Clasificacin / Instanciacin 2. Composicin / Descomposicin 3. Agrupacin / Individualizacin 4. Especializacin / Generalizacin La clasificacin es uno de los mecanismos de abstraccin ms utilizados. La clase defi ne el mbito de definicin de un conjunto de objetos, y cada objeto pertenece a una clase, Los objetos se crean por instanciacin de las clases. Cada clase se representa en un rectngulo con tres compartimientos: nombre de la clase atributos de la clase operaciones de la clase Los atributos de una clase no deberan ser manipulables directamente por el resto de objetos. Por esta razn se crearon niveles de visibilidad para los elementos qu e son: (-) Privado : es el ms fuerte. Esta parte es totalmente invisible (excepto para c lases friends en terminologa C++) (#) Los atributos/operaciones protegidos estn visibles para las clases friends y para las clases derivadas de la original. (+) Los atributos/operaciones pblicos son visibles a otras clases (cuando se trat a de atributos se est transgrediendo el principio de encapsulacin) Relaciones entre clases: Los enlaces entre objetos pueden representarse entre las respectivas clases y su s formas de relacin son: Asociacin y Agregacin (vista como un caso particular de asociacin) Generalizacin/Especializacin. Las relaciones de Agregacin y Generalizacin forman jerarquas de clases. Asociacin: La asociacin expresa una conexin bidireccional entre objetos. Una asociacin es una abstraccin de la relacin existente en los enlac es entre los objetos. Puede determinarse por la especificacin de multiplicidad (mn ima...mxima) Uno y slo uno 0..1 Cero o uno M..N Desde M hasta N (enteros naturales) * Cero o muchos 0..* Cero o muchos 1..* Uno o muchos (al menos uno) Agregacin: La agregacin representa una relacin parte_de entre objetos. En UML se proporciona

una escasa caracterizacin de la agregacin. Esta relacin puede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes. Una agregacin se podra caracterizar segn: Puede el objeto parte comunicarse directamente con objetos externos al objeto ag regado? No => inclusiva Si => no inclusiva Puede cambiar La composicin del objeto agregado? Si => dinmica No => esttica Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementaria s del modelo. Un Diagrama de Clases muestra la abstraccin de una parte del domini o. Un Diagrama de Objetos representa una situacin concreta del dominio. Las clase s abstractas no son instanciadas. Generalizacin: Permite gestionar la complejidad mediante un ordenamiento taxonmico de clases, se obtiene usando los mecanismos de abstraccin de Generalizacin y/o Especializacin. L a Generalizacin consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general. Los nombres usados: clase padre - clase hija. Otr os nombres: superclase - subclase, clase base - clase derivada. Las subclases he redan propiedades de sus clases padre, es decir, atributos y operaciones (y asoc iaciones) de la clase padre estn disponibles en sus clases hijas. La Generalizacin y Especializacin son equivalentes en cuanto al resultado: la jerarqua y herencia establecidas. Generalizacin y Especializacin no son operaciones reflexivas ni simtr icas pero s transitivas. La especializacin es una tcnica muy eficaz para la extensin y reutilizacin. La nocin de clase est prxima a la de conjunto. Dada una clase, podemos ver el conju nto relativo a las instancias que posee o bien relativo a las propiedades de la clase. Generalizacin y especializacin expresan relaciones de inclusin entre conjunt os Diagrama de Clases Ejemplo de Diagrama de Clases Diagramas de Caso de Uso Casos de Uso es una tcnica para capturar informacin de cmo un sistema o negocio tra baja, o de cmo se desea que trabaje. No pertenece estrictamente al enfoque orient ado a objeto, es una tcnica para captura de requisitos. Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reaccione s el comportamiento de un sistema desde el p.d.v. del usuario. Permiten definir los lmites del sistema y las relaciones entre el sistema y el en torno. Los Casos de Uso son descripciones de la funcionalidad del sistema independiente s de la implementacin. Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurad o. Los Casos de Uso cubren la carencia existente en mtodos previos (OMT, Booch) en c uanto a la determinacin de requisitos. Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismo. Estn basados en el lenguaje natural, es decir, es accesible por los usuarios. Actores Principales: personas que usan el sistema. Secundarios: personas que mantienen o administran el sistema. Material externo: dispositivos materiales imprescindibles que forman parte del mb ito de la aplicacin y deben ser utilizados. Otros sistemas: sistemas con los que el sistema interacta. La misma persona fsica puede interpretar varios papeles como actores distintos, e

l nombre del actor describe el papel desempeado. Los Casos de Uso se determinan observando y precisando, actor por actor, las sec uencias de interaccin, los escenarios, desde el punto de vista del usuario. Los c asos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estar dirigido por los casos de uso. Un escenario es una instancia de un caso de uso. UML define cuatro tipos de relacin en los Diagramas de Casos de Uso: Comunicacin Inclusin : una instancia del Caso de Uso origen incluye tambin el comportamiento d escrito por el Caso de Uso destino. include reemplaz al denominado uses Extensin : el Caso de Uso origen extiende el comportamiento del Caso de Uso desti no. extend Herencia : el Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla. Parametros para la construccion de un caso de uso: Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay p ocos actores asociados a cada Caso de Uso. Preguntas clave: 1. cules son las tareas del actor? 2. qu informacin crea, guarda, modifica, destruye o lee el actor? 3. debe el actor notificar al sistema los cambios externos? 4. debe el sistema informar al actor de los cambios internos? La descripcin del Caso de Uso comprende: 1. el inicio: cundo y qu actor lo produce? 2. el fin: cundo se produce y qu valor devuelve? 3. la interaccin actor-caso de uso: qu mensajes intercambian ambos? 4. objetivo del caso de uso: qu lleva a cabo o intenta? 5. cronologa y origen de las interacciones 6. repeticiones de comportamiento: qu operaciones son iteradas? 7. situaciones opcionales: qu ejecuciones alternativas se presentan en el ca so de uso? Diagrama de Caso de Uso

Diagrama de Actividades El Diagrama de Actividad es una especializacin del Diagrama de Estado, organizado respecto de las acciones y usado para especificar: Un mtodo Un caso de uso Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecucin de una operacin. Un grafo de actividades describe grupos secuenciale s y concurrentes de actividades. Los grafos de actividades se muestran en diagra mas de actividades. Las actividades se enlazan por transiciones automticas. Cuand o una actividad termina se desencadena el paso a la siguiente actividad. Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecucin de un sistema, sin profundizar en los detalles internos de los mensajes. Los parmetros de entrada y salida de una accin se pueden mostrar usa ndo las relaciones de flujo que conectan la accin y un estado de flujo de objeto. Un proceso de negocio (Workflow) Un grafo de actividades contiene estados de actividad que representa la ejecucin de una secuencia en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En vez de esperar un evento, como en un estado de espera norm al, un estado de actividad espera la terminacin de su cmputo. Cuando la actividad termina, entonces la ejecucin procede al siguiente estado de actividad dentro del diagrama. una transicin de terminacin es activada en un diagrama de actividades c uando se completa la actividad precedente. Los estados de actividad no tienen tr ansiciones con eventos explcitos, peor pueden ser abortados por transiciones en e stados que los incluyen.

Un grafo de actividades puede contener tambin estados de accin, que son similares a los de actividad pero son atmicos y no permiten transiciones mientras estn activ os. Los estados de accin se deben utilizar para las operaciones cortas de manteni miento. Un diagrama de actividades puede contener bifurcaciones, as como divisiones de co ntrol en hilos concurrentes. los hilos concurrentes representan actividades que se pueden realizar concurrentemente por los diversos objetos o personas. La conc urrencia se representa a partir de la agregacin, en la cual cada objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultneamente o en cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que permite el control de concurrencia adems del control secuencial. Notacin Notacin Un estado de actividad se representa como una caja con los extremos redondeados que contiene una descripcin de actividad. Las transacciones simples de terminacin se muestran como flechas. Las ramas se muestran como condiciones de guarda en t ransiciones o como diamantes con mltiples flechas de salida etiquetadas. Una divi sin o una unin de control se representa con mltiples flechas que entran o salen de la barra gruesa de sincronizacin. Cuando es necesario incluir eventos externos, la recepcin de un evento se puede m ostrar como un disparador en una transicin, o como un smbolo especial que denota l a espera de una seal. A menudo es til organizar las actividades en un modelo segn su responsabilidad. Es ta clase de asignacin puede mostrarse organizando las actividades en regiones dis tintas separads por lneas en el diagrama. Debido a su aspecto, esto es conocido c omo Calles. Un diagrma de actividades puede mostrar el flujo de objetos como valores. Para u n valor de salida, se dibuja una flecha con lnea discontinua desde la actividad a l objeto. Para un valor de entrada, se dibuja una flecha con lnea discontinua des de el objeto a una actividad. Diagrama de Actividades

Ejemplo de Diagrama de Actividades Diagramas de Estado Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin, junto con los cambios que permiten pasar de un estado a otro. Los Diagramas de Estado representan autmatas de estados finitos, desde el p.d.v. de los estados y las transiciones. Son tiles slo para los objetos con un comportam iento significativo. Cada objeto est en un estado en cierto instante. El estado e st caracterizado parcialmente por los valores algunos de los atributos del objeto . El estado en el que se encuentra un objeto determina su comportamiento. Cada o bjeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su c lase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas d e Estados son autmatas jerrquicos que permiten expresar concurrencia, sincronizacin y jerarquas de objetos, son grafos dirigidos y deterministas. La transicin entre estados es instantnea y se debe a la ocurrencia de un evento. Estado Identifica un periodo de tiempo del objeto (no instantneo) en el cual el objeto e st esperando alguna operacin, tiene cierto estado caracterstico o puede recibir cie rto tipo de estmulos. Se representa mediante un rectngulo con los bordes redondead os, que puede tener tres compartimientos: uno para el nombre, otro para el valor caracterstico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respec tivamente

Eventos Es una ocurrencia que puede causar la transicin de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas: Condicin que toma el valor de verdadero o falso Recepcin de una seal de otro objeto en el modelo Recepcin de un mensaje Paso de cierto perodo de tiempo, despus de entrar al estado o de cierta hora y fec ha particular El nombre de un evento tiene alcance dentro del paquete en el cual est definido, no es local a la clase que lo nombre. Envo de mensajes Adems de mostrar y transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros objetos. Esto se realiza mediante una lnea punteada dirigida al diagrama de estados del objeto receptor del mensaj e. Transicin simple Una transicin simple es una relacin entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una lnea slida entre dos estados, que puede venir acompaada de un texto con el siguiente formato: event-signature "[" guard-condition] "/" action-expression "^"send-clause event-signature es la descripcin del evento que da lugar la transicin, guard-condi tion son las condiciones adicionales al evento necesarias para que la transicin o curra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transicin y el cambio de estado y send-clause son acciones a dicionales que se ejecutan con el cambio de estado, por ejemplo, el envo de event os a otros paquetes o clases. Transicin interna Es una transicin que permanece en el mismo estado, en vez de involucrar dos estad os distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado. Acciones: Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transicin. Se puede especificar el ejecutar una accin como consecuencia de e ntrar, salir, estar en un estado, o por la ocurrencia de un evento Generalizacin de Estados: Podemos reducir la complejidad de estos diagramas usando la generalizacin de estados. Distinguimos as entre superestado y subestados. Un estado puede contener varios subestados disjuntos. Los subestados heredan las variables de estado y las transiciones externas. La agregacin de estados es la composicin de un estado a partir de varios estados i ndependientes. La composicin es concurrente por lo que el objeto estar en alguno de los estados d e cada uno de los subestados concurrentes. La destruccin de un objeto es efectiva cuando el flujo de control del autmata alcanza un estado final no anidado. La ll egada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto. Subestados Un estado puede descomponerse en subestados, con transiciones entre ellos y cone xiones al nivel superior. Las conexiones se ven al nivel inferior como estados d e inicio o fin, los cuales se suponen conectados a las entradas y salidas del ni vel inmediatamente superior. Transaccin Compleja Una transicin compleja relaciona tres o ms estados en una transicin de mltiples fuen tes y/o mltiples destinos. Representa la subdivisin en threads del control del obj eto o una sincronizacin. Se representa como una lnea vertical de la cual salen o e ntran varias lneas de transicin de estado. Transicin a estados anidados

Una transicin de hacia un estado complejo (descrito mediante estados anidados) si gnifica la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subest ados hacia afuera (a cualquier nivel de profundidad). Transiciones temporizadas Las esperas son actividades que tienen asociada cierta duracin. La actividad de espera se interrumpe cuando el evento esperado tiene lugar. Este evento desencadena una transicin que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado. Diagrama de Estado Ejemplo de Diagrama de Estado Si desea colocar sus cometarios acerca del tema o desea hacer preguntas del mis mo lo puede hacer en nuestro foro Diagramas de Interaccin: Diagramas de Secuencia Diagramas de Colaboracin La vista de interaccin describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasificador, o si mplemente "un rol", es la descripcin de un objeto, que desempea un determinado pap el dentro de una interaccin, distinto de los otros objetos de la misma clase. Est a visin proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de control a travs de muchos objetos. La vista de interaccin se e xhibe en dos diagramas centrados en distintos aspectos pero complementarios: cen trados en los objetos individuales y centrados en objetos cooperantes. Los objetos interactan para realizar colectivamente los servicios ofrecidos por l as aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccin. Existen dos tipos de diagramas de interaccin: el Diagrama de C olaboracin y el Diagrama de Secuencia. El Diagrama de Secuencia es ms adecuado para observar la perspectiva cronolgica de las interacciones, muestra la secuencia explcita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. El Diagrama de Cola boracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetos, muestra las relaciones entre objetos y son mejores para comprender todo s los efectos que tiene un objeto y para el diseo de procedimientos. El diagrama de Colaboracin puede obtenerse automticamente a partir del correspondiente diagram a de Secuencia (o viceversa). Diagramas de Secuencia: 1. Muestra la secuencia de mensajes entre objetos durante un escenario conc reto 2. Cada objeto viene dado por una barra vertical 3. El tiempo transcurre de arriba abajo 4. Cuando existe demora entre el envo y la atencin se puede indicar usando un a lnea oblicua Diagramas de Colaboracin: 1. Muestra la secuencia de mensajes entre objetos durante un escenario conc reto 2. Cada objeto viene dado por una barra vertical 3. El tiempo transcurre de arriba abajo 4. Cuando existe demora entre el envo y la atencin se puede indicar usando un a lnea oblicua Diagramas de Colaboracin: 1. Son tiles en la fase exploratoria para identificar objetos. 2. La distribucin de los objetos en el diagrama permite observar adecuadamen te la interaccin de un objeto con respecto de los dems 3. La estructura esttica viene dada por los enlaces; la dinmica por el envo de mensajes por los enlaces

Qu es una Colaboracin? Es una descripcin de una coleccin de objetos que interactan para implementar un cie rto comportamiento dentro de un contexto. Describe una sociedad de objetos coope rantes unidos para realizar un cierto propsito. Una colaboracin contiene ranuras q ue son rellenadas por los objetos y enlaces en tiempo de ejecucin. Una ranura de colaboracin se llama Rol porque describe el propsito de un objeto o un enlace dent ro de la colaboracin. Un rol clasificador representa una descripcin de los objetos que pueden participa r en una ejecucin de la colaboracin, un rol de asociacin representa una descripcin d e los enlaces que pueden participar en una ejecucin de colaboracin. Un rol de clas ificador es una asociacin que est limitada por tomar parte en la colaboracin. Las r elaciones entre roles de clasificador y asociacin dentro de una colaboracin slo tie nen sentido en ese contexto. En general fuera de ese contexto no se aplican las mismas relaciones. Una Colaboracin tiene un aspecto estructural y un aspecto de comportamiento. El a specto estrucutral es similar a una vista esttica: contiene un conjunto de roles y relaciones que definen el contexto para su comprtamiento. El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados a los roles. Tal conjunto de mensajes en una colaboracin se llama Interaccin. Una colaboracin puede incluir una o ms interacciones. Qu es una Interaccin? Es el conjunto de mensajes intercambiados por los roles de clasificador a travs d e los roles de asociacin. Un mensaje es una comunicain unidireccional entre dos ob jetos, un flujo de objeto con la informacin de un remitente a un receptor. Un men saje puede tener parmetros que transporten valores entre objetos. Un mensaje pued e ser una seal (comunicacin explcita entre objetos, con nombre y asncrona) o una lla mada (la invocacin sncrona de una operacin con un mecanismo para el control, que re torna posteriormente al remitente). Un patrn de intercambios de mensajes que se r ealizan para lograr un propsito especfico es lo que se denomina una interaccin. Qu es Patrn? Un patrn es una colaboracin parametrizada, junto con las pautas sobre cundo utiliza rlo. Un parmetro se puede sustituir por diversos valores, para producir distintas colaboraciones. Los parmetros sealan generalmente las ranuras para las clases. El uso de un patrn se representa como una elipse de lnea discontinua conectada con c ada una de las clases por una lnea discontinua, que se etiqueta con el nombre del rol.

Diagramas de Despliegue Los Diagramas de Despliegue muestran la disposicin fsica de los distintos nodos qu e componen un sistema y el reparto de los componentes sobre dichos nodos. La vis ta de despliegue representa la disposicin de las instancias de componentes de eje cucin en instacias de nodos conectados por enlaces de comunicacin. Un nodo es un r ecurso de ejecucin tal como un computador, un dispositivo o memoria. Los estereot ipos permiten precisar la naturaleza del equipo: Dispositivos Procesadores Memoria Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribuc in y la asignacin de recursos. Las instancias de los nodos pueden contener instancia s de ejecucin, como instancias de componentes y objetos. El modelo puede mostrar dependencias entre las instancias y sus interfaces, y tambin modelar la migracin d e entidades entre nodos u otros contenedores. Esta vista tiene una forma de descriptor y otra de instancia. La forma de instan cia muestra la localizacin de las instancias de los componentes especficos en

instancias especficas del nodo como parte de una configuracin del sistema. La form a de descriptor muestra qu tipo de componentes pueden subsistir en qu tipos de nodos y qu tipo de nodos se pueden conectar, de forma similar a una diagrama d e clases, esta forma es menos comn que la primera. Diagrama de Componentes Diagramas de Componentes Los diagramas de componentes describen los elementos fsicos del sistema y sus rel aciones. Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ej ecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinmicamente, etc. Las relaciones de depend encia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente. Un diagrama de componentes representa las dependencias entre componentes softwar e, incluyendo componentes de cdigo fuente, componentes del cdigo binario, y compon entes ejecutables. Un mdulo de software se puede representar como componente. Alg unos componentes existen en tiempo de compilacin, algunos en tiempo de enlace y a lgunos en tiempo de ejecucin, otros en varias de stas. Un componente de slo compilacin es aquel que es significativo nicamente en tiempo d e compilacin. Un componente ejecutable es un programa ejecutable. Un diagrama de componentes tiene slo una versin con descriptores, no tiene versin c on instancias. Para mostrar las instancias de los componentes se debe usar un di agrama de despliegue. Un diagrama de componentes muestra clasificadores de componentes, las clases def inidas en ellos, y las relaciones entre ellas. Los clasificadores de componentes tambin se pueden anidar dentro de otros clasificadores de componentes para mostr ar relaciones de definicin. Un diagrama que contiene clasificadores de componentes y de nodo se puede utiliz ar para mostrar las dependencias del compilador, que se representa como flechas con lneas discontinuas (dependencias) de un componente cliente a un componente pr oveedor del que depende. Los tipos de dependencias son especficos del lenguaje y se pueden representar como estereotipos de las dependencias. El diagrama tambin puede usarse para mostrar interfaces y las dependencias de lla mada entre componentes, usando flechas con lneas discontinuas desde los component es a las interfaces de otros componentes. El diagrama de componente hace parte de la vista fsica de un sistema, la cual mod ela la estructura de implementacin de la aplicacin por s misma, su organizacin en co mponentes y su despliegue en nodos de ejecucin. Esta vista proporciona la oportun idad de establecer correspondecias entre las clases y los componentes de impleme ntacin y nodos. La vista de implementacin se representa con los diagramas de compo nentes. Diagrama de Componentes Qu es Componente? Es una parte fsica reemplazable de un sistema que empaqueta su implementacin y es conforme a un conjunto de interfaces a las que proporciona su realizacin. Algunos componentes tienen identidad y pueden poseer entidades fsicas, que incluy en objetos en tiempo de ejecucin, documentos, bases de datos, etc. Los componente s existentes en el dominio de la implementacin son unidades fsicas en los computad ores que se pueden conectar con otros componentes, sustituir, trasladar, archiva r, etc. Los componentes tienen dos caractersticas: Empaquetan el cdigo que implementa la f uncionalidad de un sistema, y algunas de sus propias instancias de objetos que c ontituyen el estado del sistema. Los llamados ltimos componentes de la identidad, porque sus instancias poseen identidad y estado. Cdigo: Un componente contiene el cdigo para las clases de implementacin y otros elementos . Un componente de cdigo fuente es un paquete para el cdigo fuente de las clases d e implementacin. Al gunos lenguajes de programacin distinguen archivos de declarac

in de los archivos de mtodo, pero todos son componentes. Un componente de cdigo bin ario es un paquete para el cdigo compliado. Una biblioteca del cdigo binario es un componente. Cada tipo de componente contiene el cdigo para las clases de implementacin que rea lizan algunas clases e interfaces lgicas. La relacin de realizacin asocia un compon ente con las clases y las interfaces lgicas que implementan sus clases de impleme ntacin. Las interfaces de un componente describen la funcionalidad que aporta. Ca da operacin de la interfaz debe hacer referencia eventualmente a un elemento de l a implementacin disponible en el componente. La estrucutra esttica, ejecutable de una implementacin de un sistema se puede repr esentar como un conjunto interconectado de componentes. Las dependencias entre c omponentes significan que los elementos de la implementacin en un componente requ ieren los serivios de los elementos de implemntacin en otros componentes. Tal uso requiere que dichos elementos sean de visibilidad pblica. Identidad: Un componente de identidad tiene identidad y estado. Posee los objetos fsicos que estn situados en l. Puede tener atributos, relaciones de composicin con los objeto s posedos, y asociaciones con otros componentes. Desde este punto de vista es una clase. Sin embargo la totalidad de su estado debe hacer referencia a las instan cias que contiene. Estructura: Un componente ofrece un conjunto de elementos de implementacin, esto significa qu e el componente proporciona el cdigo para los elementos. Un componente puede tene r operaciones e interfaces. Un componente de identidad es un contenedor fsico par a las entidades fsicas como bases de datos. Para proporcionar manejadores para su s elementos contenidos, puede tener atributos y asociaciones salientes, que debe n ser implementadas por sus elementos de implementacin. Este componente se repres enta con un rectngulo con dos rectngulos ms pequeos que sobresalen en su lado izquie rdo. Las operaciones e interfaces disponibles para los objetos exteriores se pueden r epresentar directamente en el smbolo de clase. Estos son su comportamiento como c lase. Los contenidos del subsistema se representan en un diagrama separado. Las dependencias de un componente con otros componentes o elementos del modelo s e representan usando lneas discontinuas con la punta de flecha hacia los elemento s del proveedor. S un componente es la realizacin de una interfaz, se representa c on un crculo unido al smbolo del componente por un segmento de lnea. Paquetes Cualquier sistema grande se debe dividir en unidades ms pequeas, de modo que las p ersonas puedan trabajar con una cantidad de informacin limitada, a la vez y de mo do que los equipos de trabajo no interfieran con el trabajo de los otros. Un paquete es una parte de un modelo. Cada parte del modelo debe pertenecer a un paquete. Pero para ser funcional, la asignacin debe seguir un cierto principio r acional, tal como funcionalidad comn, implementacin relacionada y punto de vista c omn. UML no impone una regla para componer los paquetes. Los paquetes ofrecen un mecanismo general para la organizacin de los modelos/subs istemas agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema). Los paquetes son unidades de organizacin jerrq uica de uso general de los modelos de UML. Pueden ser utilizados para el almacen amiento, el control de acceso, la gestin de la configuracin y la construccin de bib liotecas que contengan fragmentos reutilizables del modelo. Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elem ento pertenece a (est definido en) slo un paquete. Los paquetes contienen elementos del modelo al ms alto nivel, tales como clases y sus relaciones, mquinas de estado, diagramas de casos de uso, interacciones y co laboraciones; atributos, operaciones, estados, lneas de vida y mensajes estn conte nidos en otros elementos y no aparecen como contenido directo de los paquetes. Dependencias en los paquetes

Las dependencias que se presentan entre elementos individuales, pero en un siste ma de cualquier tamao, deben ser vistas en un nivel ms alto. las dependencias entr e paquetes resumen dependencias entre los elementos internos a ellos, es decir, las dependencias del paquete son derivables a partir de las dependencias entre l os elementos individuales. La presencia de una dependencia entre paquetes implica que existe en un enfoque ascendente (una declaracin de existencia), o que se permite que exista ms adelante en un enfoque descendente (una restriccin que limita cualquier otra relacin), por lo menos un elemento de relacin con el tipo de dependencia indicado entre elemen tos individuales dentro de los paquetes correspondientes. Las dependencias mltiples del mismo tipo entre elementos individuales se agregan a una sola dependencia entre los paquetes que contienen los elementos. Si las de pendencias entre elementos contienen estereotipos, ste puede ser omitido en la de pendencia del paquete, para dar una sola dependencia de alto nivel.