DIAGRAMAS DE SECUENCIA: UN PASO A LA VEZ

A pesar de que a partir de los diagramas de casos de uso y de los diagramas 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. sto se debe que hasta que vemos interactuando a los ob!etos de nuestras clases con los actores y con otros ob!etos de manera din"mica, hasta ese momento tenemos suficiente informaci#n como para poder empezar a especificar los mtodos de nuestras respectivas clases. l diagrama de secuencias es el n$cleo de nuestro modelo din"mico, y muestra todos los cursos alternos que pueden tomar todos nuestros casos de uso. %os diagramas de secuencias se componen de & elementos que son' el curso de acci#n, los ob!etos, los mensa!es y los mtodos (operaciones). stos & elementos son los que ya han sido analizados en clase con anterioridad dentro de la primera unidad.

Los 4 pasos a seguir:

A continuaci#n se dar" una muy breve descripci#n de los & pasos que se deben de seguir para dibu!ar correctamente diagramas de secuencia de *+,-*.' /Paso 1: +opia el te0to de la especificaci#n de tu caso de uso y pgalo en la parte superior de tu diagrama de secuencia. +on esto siempre se tendr" en cuenta que es lo que debe de hacer el diagrama de secuencia. /Paso 2: +ada uno de los ob!etos entidad de tu diagrama de robustez es una instancia de la clase que debe de ser agregada a tu diagrama de secuencias ya que representa tu modelo est"tico. 1ay que ser muy meticuloso con este paso, ya que representa el ultimo de tu modelo est"tico antes de codificar. /Paso 3: Agrega las interfaces del diagrama de robustez. +on esto ya tenemos el diagrama de secuencias construido. Ahora, el cuarto paso es para decidir cuales mtodos ir2an en cuales clases, lo cual es la esencia del modelo de iteraciones. /Paso 4: 3on los mtodos en las clases, lo cual significa convertir los controles uno por uno de tu diagrama de robustez en mtodos y mensa!es. 4erifica que para cada control dibu!ado le pertenecen los mensa!es correctos dentro del diagrama de secuencias.

Top Ten de errores de os diagra!as de se"uen"ia:

A continuaci#n se presentan los 50 errores mas com$nmente cometidos por los estudiantes al intentar hacer sus diagramas de secuencia. 10.- No hacen un diagrama de secuencia para cada caso de uso: 1acer esto es muy importante, ya que solo as2 se puede saber cual es el rol y las responsabilidades de cada ob!eto.

9.- No ponen el texto del caso de uso en el diagrama de secuencia: l poner de vuelta este te0to al margen del diagrama de secuencia provee de la visi#n necesaria para poder hacer diagramas de secuencia correctos de acuerdo al caso de uso que se esta modelando. 8.- No identifican todos los o !etos necesarios desde el diagrama de ro uste": 6i tienes problemas al realizar los diagramas de secuencia es por que tienes mal modelados tus casos de uso o tus diagramas de robustez est"n incompletos.

.6. Diagramas de Actividad

El Diagrama de Actividad es un diagrama de flujo del proceso multi-propsito que se 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 processing". Esto es importante cuando se usan diagramas de actividad para modelar procesos #$ussiness# algunos de los cuales pueden actuar en paralelo, % para modelar varios &ilos en los programas concurrentes.

4.6.1. Usando Diagramas de Actividad para modelar Casos de Uso

Los Diagramas de Actividad ofrecen una &erramienta gr'fica para modelar el proceso de un Caso de Uso. (e pueden usar como un a)adido a una descripcin te*tual del caso de uso, o para listar los pasos del caso de uso. Una descripcin te*tual, cdigo, u otros diagramas de actividad pueden detallar m's 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 U+L se suel usar normalmente para modelar situaciones donde ocurren eventos asincrnicos. El diagrama de actividad se usa conado todos o la ma%or,a de los elementos representan el desarrollo de los pasos dados por las acciones generadas internamente. De$er,as asignar actividades a las clases antes de terminar con el diagrama de actividad. Los mensajes se muestran como flechas entre lneas de vida. Un diagrama de secuencia puede mostrar un escenario, es decir, una historia individual de transaccin. Un 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, la horizontal representa los objetos que participan en la interaccin. n general, el tiempo avanza hacia abajo dentro de la pgina !se pueden invertir los ejes si se desea". #on frecuencia slo son importantes las secuencias de mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una m$trica. La ordenacin horizontal de los objetos no tiene ning%n significado.

Figura 12: Diagrama de Actividad

Diagrama de Secuencia

Ejemplo de Diagrama de Secuencia

&iagrama que muestra las interacciones entre los objetos organizadas en una secuencia temporal. n particular muestra los objetos participantes en la interaccin ' la secuencia de mensajes intercambiados. (epresenta una interaccin, un conjunto de comunicaciones entre objetos organizadas visualmente por orden temporal. ) diferencia de los diagramas de colaboracin, los diagramas de secuencia inclu'en secuencias temporales pero no inclu'en las relaciones entre objetos. *ueden e+istir de forma de descriptor !describiendo todos los posibles escenarios" ' en forma de instancia !describiendo un escenario real". &entro del conjunto de mensajes representados dispuestos en una secuencia temporal, 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 secuencia puede mostrar un escenario, es decir, una historia individual de transaccin. Un 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, la horizontal representa los objetos que participan en la interaccin. n general, el tiempo avanza hacia abajo dentro de la pgina !se pueden invertir los ejes si se desea". #on frecuencia slo son importantes las secuencias de mensajes pero en

aplicaciones de tiempo real el eje temporal puede ser una m$trica. La ordenacin horizontal de los objetos no tiene ning%n significado. Un dilogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa los objetos que participan en la interaccin. n general, el tiempo avanza hacia abajo dentro de la pgina !se pueden invertir los ejes si se desea". #on frecuencia slo son importantes las secuencias de mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una m$trica. La ordenacin horizontal de los objetos no tiene ning%n significado.
#ada 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 el punto vertical que denota el instante en que se crea el objeto. sta se conoce como lnea de vide del objeto. -e pone una . grande en el punto en que deja de e+istir el objeto o en el punto en que el objeto se destru'e a s mismo. *ara el periodo durante el cual est$ activo el objeto, la lnea de vida se ampla para ser una lnea doble continua. -i el objeto se llama a s mismo, entonces se superpone otra copia de la doble lnea para mostrar la doble activacin. l orden relativo de los objetos no tiene significado a%n cuando resulta %til organizarlos de modo que se minimice la distancia de las flechas. #ada 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 recibido el mensaje. -i un mensaje requiere un cierto tiempo para llegar a su destino, entonces la flecha del mensaje se dibuja diagonalmente hacia abajo. *ara un flujo de objeto asncrono entre objetos activos, los objetos se representan mediante lneas dobles continuas ' los mensajes se representan como flechas. -e pueden enviar simultneamente dos mensajes pero no se pueden recibir simultneamente porque no s+e puede garantizar una recepcin simultnea. Las bifurcaciones se muestran partiendo la lnea de vida del objeto. #ada bifurcacin puede enviar ' recibir mensajes. ventualmente las lneas de vida del objeto tienen que fusionarse de nuevo. Un diagrama de secuencia tambi$n se puede mostrar en forma de descriptor, en el cual los constitu'entes son roles en lugar de objetos. ste diagrama muestra en el caso general, no una sola ejecucin del mismo. Los diagramas del nivel de descriptores se dibujan sin subra'ados porque los smbolos denotan roles ' no objetos individuales.

Diagrama de Estado

Ejemplo de Diagrama de Estado

Un &iagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo cone+o de arcos !relaciones" ' v$rtices !otros elementos del modelo". Un diagrama no es un elemento semntico, un diagrama muestra representaciones de elementos semnticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama est contenido dentro de un paquete. La ma'ora de los diagramas de U/L ' algunos smbolos complejos son grafos que contienen formas conectadas por rutas. La infomacin est sobre todo en la topologa, no en el tama0o o la colocacin de los smbolos !ha' algunas e+cepciones como el diagrma de secuencia con un eje m$trico de tiempo". 1a' tres clases importantes de relaciones visuales: cone+in !generalmente de lneas a formas de dos dimensiones", contencin !de smbolos por formas cerradas de dos dimensiones", ' adhesin visual !un smbolo que est 2cerca2 de otro en un diagrama". stas relaciones geom$tricas se reasignan a cone+iones entre nodos en un grfico en la forma analizada de la notacin. La notacin de U/L est pensada para ser dibujada en superficies bidimensionales. )lgunas formas bidimensionales son pro'ecciones de formas tridimensionales tales como cubos, pero todava se representan como conos en una superficie bidimensional. 1a' cuatro clases de construcciones grficas que se usan en la notacin de U/L: conos, smbolos bidimensionales, rutas ' cadenas. Un cono es una figura grfica con un tama0o ' forma fijos. 3o se ampla para contener a su contenido. Los iconos pueden aparecer dentro de smbolos de rea, como terminadores en las rutas o como smbolos independientes que puedan o no conectar con las rutas. Los smbolos de dos dimensiones tienen altura ' anchura variables, ' pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros smbolos. /uchos 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 afecta a su contenido ' las rutas conectadas.

Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales. #onceptualmente una ruta es una sola entidad topolgica, aunque sus segmentos se pueden manipular grficamente. un segemento no debera e+istir separado de su ruta. Las rutas siempre van conectdas en ambos e+tremos. Las cadenas presentan varias clases de informacin en una forma 2no analizada2, U/L asume que cada uso de una cadena en la

notacin tiene una sinta+is por la cual pueda ser analizada la informacin del modelo sub'ancente. Las cadenas pueden e+istir como el contenido de un compartimiento, como elementos en las listas, como etiquetas 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

4ista sttica

&iagrama #lases

#lase, asociacin, de generalizacin, dependencia, realizacin, interfaz.

structural

#aso de Uso, )ctor, 4ista de #asos de &iagramas de asociacin, e+tensin, Uso #asos de Uso generalizacin.

4ista de &iagramas de #omponente, interfaz, 5mplementacin #omponentes dependencia, relaizacin.

4ista &espliegue

de &iagramas &espliegue

de 3odo, componente, dependencia, localizacin.

4ista de stados &iagramas de mquina stados

de stado, evento, transicin, accin.

4ista de actividad

&iagramas )ctividad

de

stado, actividad, transicin, determinacin, divisin, unin.

&inmica &iagramas -ecuencia 4ista interaccin de &iagramas #olaboracin de #olaboracin, interaccin, rol de colaboracin, mensaje. de 5nteraccin, objeto, mensaje, activacin.

)dministracin o 4ista de 6estin de &iagramas 6estin de modelo modelo #lases

de *aquete, modelo.

subsistema,

+tensin de U/L

7odas

7odos

(estriccin, estereotipo, valores, etiquetados.

Diagramas de O !etos
-$jeto es una entidad discreta con l,mites $ien definidos % con identidad, es una unidad atmica que encapsula estado % comportamiento. La encapsulacin en un o$jeto permite una alta co&esin % un $ajo acoplamiento. el -$jeto es reconocido tam$in como una instancia de la clase a la cual pertenece. La encapsulacin presenta tres ventajas $'sicas. 1. Se protegen los datos de accesos indebidos 2. El acoplamiento entre las clases se disminuye 3. Favorece la modularidad y el mantenimiento Un o$jeto se puede ver desde dos perspectivas relacionadas. como una entidad de un determinado instante de tiempo que posee un valor espec,fico !Un o$jeto puede caracteri/ar una entidad f,sica -coc&e-" % como un poseedor de identidad que tiene distintos valores a lo largo del tiempo !a$stracta -ecuacin matem'tica-". Cada o$jeto posee su propia identidad e*clusiva % se puede &acer referencia a l mediante una denominacin e*clusiva que permite accederle. El +odelado de -$jetos permite representar el ciclo de vida de los o$jetos a travs de sus interacciones. En U+L, un o$jeto se representa por un rect'ngulo con un nom$re su$ra%ado.

Objeto = Identidad + Estado + omportamiento El estado est! representado por los valores de los atributos. "n atributo toma un valor en un dominio concreto.

La regla general para la notacin de instancias consiste en utili/ar el mismo s,m$olo geomtrico que el descriptor. En la instancia se muestran los posi$les valores pero las propiedades compartidas slo se pone de manifiesto en el descriptor. La notacin cannica es un rect'ngulo con tres compartimientos. En el primero va el nom$re del o$jeto, en el segundo sus atri$utos % en el tercero sus operaciones. Este 0ltimo puede ser omitido si as, se prefiere.

Oid #O$%e"& Iden&i'ier(

Cada o$jeto posee un oid. El oid esta$lece la identidad del o$jeto % tiene las siguientes caracter,sticas.

onstituye un identi#icador $nico y global para cada objeto dentro del sistema. Es determinado en el momento de la creaci%n del objeto. Es independiente de la locali&aci%n #'sica del objeto( es decir( provee completa independencia de locali&aci%n. Es independiente de las propiedades del objeto( lo cual implica independencia de valor y de estructura. )o cambia durante toda la vida del objeto. *dem!s( un oid no se reutili&a aun+ue el objeto deje de e,istir.

1o se tiene ning0n control so$re los oids % su manipulacin resulta transparente. (in em$argo, es preciso contar con alg0n medio para &acer referencia a un o$jeto utili/ando referencias del dominio !valores de atri$utos".

Caracter"sticas alrededor de un o !eto:

Es&ado:
El estado evoluciona con el tiempo. Algunos atri$utos pueden ser constantes, el comportamiento agrupa las competencias de un o$jeto % descri$e las acciones % reacciones de ese o$jeto. Las operaciones de un o$jeto son consecuencia de un est,mulo e*terno representado como mensaje enviado desde otro o$jeto.

Persis&en"ia:
La persistencia de los o$jetos designa la capacidad de un o$jeto trascender en el espacio2tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria secundaria para utili/arlo en la ejecucin !materiali/acin del o$jeto". Los lenguajes -no proponen soporte adecuado para la persistencia, la cual de$er,a ser transparente, un o$jeto e*iste desde su creacin &asta que se destru%a.

Co!uni"a"i)n:

Un sistema inform'tico puede verse como un conjunto de o$jetos autnomos % concurrentes que tra$ajan de manera coordinada en la consecucin de un fin espec,fico. El comportamiento glo$al se $asa pues en la comunicacin entre los o$jetos que la componen.

Ca&egor*as de o$%e&os:

*ctivos o -asivos liente .. Servidores( *gentes

1. Objeto *ctivo/ posee un 0ilo de ejecuci%n 1t0read2 propio y puede iniciar una actividad. 2. Objeto -asivo/ no puede iniciar una actividad pero puede enviar est'mulos una ve& +ue se le solicita un servicio. 3. liente es el objeto +ue solicita un servicio. 3. Servidor es el objeto +ue provee el servicio solicitado. 4. 5os agentes re$nen las caracter'sticas de clientes y servidores. Son la base del mecanismo de delegaci%n. Introducen indirecci%n/ un cliente puede comunicarse con un servidor +ue no conoce directamente.

Mensa%es:
La unidad de comunicacin entre o$jetos se llama mensaje. El mensaje es el soporte de una comunicacin que vincula din'micamente los o$jetos que fueron separados previamente en el proceso de descomposicin. Adquiere toda su fuer/a cuando se asocia al polimorfismo % al enlace din'mico. Un est,mulo causar' la invocacin de una operacin, la creacin o destruccin de un o$jeto o la aparicin de una se)al. Un mensaje es la especificacin de un est,mulo.

Tipos de ' u%o de "on&ro :

1. 2. 3. 3. 4. 8. 5lamada a procedimiento o #lujo de control anidado Flujo de control plano 6etorno de una llamada a procedimiento Otras variaciones Esperado 1bal7ing2 ronometrado 1time.out2

Diagrama de Objetos

Diagramas de Clases
El 9iagrama de lases es el diagrama principal para el an!lisis y dise:o. "n diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de 0erencia. 5a de#inici%n de clase incluye de#iniciones para atributos y operaciones. El modelo de casos de uso aporta in#ormaci%n para establecer las clases( objetos( atributos y operaciones. El mundo real puede ser visto desde abstracciones di#erentes 1subjetividad2

Mecanismos de a stracci#n:
1. lasi#icaci%n ; Instanciaci%n 2. omposici%n ; 9escomposici%n 3. *grupaci%n ; Individuali&aci%n 3. Especiali&aci%n ; <enerali&aci%n La clasificacin es uno de los mecanismos de a$straccin m's utili/ados. La clase define el 'm$ito de definicin de un conjunto de o$jetos, % cada o$jeto pertenece a una clase, Los o$jetos se crean por instanciacin de las clases. ada clase se representa en un rect!ngulo con tres compartimientos/ nombre de la clase atributos de la clase operaciones de la clase Los atri$utos de una clase no de$er,an ser manipula$les directamente por el resto de o$jetos. 3or esta ra/n se crearon niveles de visi$ilidad para los elementos que son.

1.2 -rivado / es el m!s #uerte. Esta parte es totalmente invisible 1e,cepto para clases #riends en terminolog'a ++2 1=2 5os atributos;operaciones protegidos est!n visibles para las clases #riends y para las clases derivadas de la original. 1+2 5os atributos;operaciones p$blicos son visibles a otras clases 1cuando se trata de atributos se est! transgrediendo el principio de encapsulaci%n2

$elaciones entre clases:

Los enlaces entre o$jetos pueden representarse entre las respectivas clases % sus formas de relacin son.

*sociaci%n y *gregaci%n 1vista como un caso particular de asociaci%n2 <enerali&aci%n;Especiali&aci%n.

Las relaciones de Agregacin % 4enerali/acin forman jerarqu,as de clases. *sociaci%n/ 5a asociaci%n e,presa una cone,i%n bidireccional entre o$jetos. Una asociacin es una a$straccin de la relacin e*istente en los enlaces entre los o$jetos. 3uede determinarse por la especificacin de multiplicidad !m,nima...m'*ima"

Uno % slo uno 5..6 Cero o uno +..1 Desde + &asta 1 !enteros naturales" 7 Cero o muc&os 5..7 Cero o muc&os 6..7 Uno o muc&os !al menos uno"

Agregaci#n:
La agregacin representa una relacin parte8de entre o$jetos. En U+L se proporciona una escasa caracteri/acin de la agregacin. Esta relacin puede ser caracteri/ada con precisin determinando las relaciones de comportamiento % estructura que e*isten entre el o$jeto agregado % cada uno de sus o$jetos componentes. Una agregacin se podr,a caracteri/ar seg0n. 3uede el o$jeto parte comunicarse directamente con o$jetos e*ternos al o$jeto agregado9 1o :; inclusiva (i :; no inclusiva 3uede cam$iar La composicin del o$jeto agregado9 (i :; din'mica 1o :; est'tica

Diagrama de Clases % Diagramas de -$jetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la a$straccin de una parte del dominio. Un Diagrama de -$jetos representa una situacin concreta del dominio. Las clases a$stractas no son instanciadas.

%enerali&aci#n:
3ermite gestionar la complejidad mediante un ordenamiento ta*onmico de clases, se o$tiene usando los mecanismos de a$straccin de 4enerali/acin %2o Especiali/acin. La 4enerali/acin consiste en factori/ar las propiedades comunes de un conjunto de clases en una clase m's general. Los nom$res usados. clase padre - clase &ija. -tros nom$res. superclase - su$clase, clase $ase - clase derivada. Las su$clases &eredan propiedades de sus clases padre, es decir, atri$utos % operaciones !% asociaciones" de la clase padre est'n disponi$les en sus clases &ijas. La 4enerali/acin % Especiali/acin son equivalentes en cuanto al resultado. la jerarqu,a % &erencia esta$lecidas. 4enerali/acin % Especiali/acin no son operaciones refle*ivas ni simtricas pero s, transitivas. La especiali/acin es una tcnica mu% efica/ para la e*tensin % reutili/acin. La nocin de clase est' pr*ima a la de conjunto. Dada una clase, podemos ver el conjunto relativo a las instancias que posee o $ien relativo a las propiedades de la clase. 4enerali/acin % especiali/acin e*presan relaciones de inclusin entre conjuntos

Diagrama de Clases

Ejemplo de Diagrama de Clases

Diagramas de Caso de Uso

#asos de Uso es una t$cnica para capturar informacin de cmo un sistema o negocio trabaja, o de cmo se desea que trabaje. 3o pertenece estrictamente al enfoque orientado a objeto, es una t$cnica para captura de requisitos.

Los #asos de Uso !5var 8acobson" describen bajo la forma de acciones ' reacciones el comportamiento de un sistema desde el p.d.v. del usuario. *ermiten definir los lmites del sistema ' las relaciones entre el sistema ' el entorno. Los #asos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacin. #omparacin con respecto a los &iagramas de 9lujo de &atos del nfoque structurado. Los #asos de Uso cubren la carencia e+istente en m$todos previos !:/7, ;ooch" en cuanto a la determinacin de requisitos. Los #asos de Uso particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismo. stn basados en el lenguaje natural, es decir, es accesible por los usuarios.

Actores

*rincipales: personas que usan el sistema. -ecundarios: personas que mantienen o administran el sistema. /aterial e+terno: dispositivos materiales imprescindibles que forman parte del mbito de la aplicacin ' deben ser utilizados. :tros sistemas: sistemas con los que el sistema interact%a.

La misma persona fsica puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempe0ado. Los #asos de Uso se determinan observando ' precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario. Los casos de uso intervienen durante todo el ciclo de vida. l proceso de desarrollo estar dirigido por los casos de uso. Un escenario es una instancia de un caso de uso.

UML de'ine "ua&ro &ipos de re a"i)n en os Diagra!as de Casos de Uso:

#omunicacin 5nclusin : una instancia del #aso de Uso origen inclu'e tambi$n el comportamiento descrito por el #aso de Uso destino. <include= reemplaz al denominado <uses= +tensin : el #aso de Uso origen e+tiende el comportamiento del #aso de Uso destino. <e+tend= 1erencia : el #aso de Uso origen hereda la especificacin del #aso de Uso destino ' posiblemente la modifica '>o ampla.

Para!e&ros para a "ons&ru""ion de un "aso de uso:

Un caso de uso debe ser simple, inteligible, claro ' conciso. 6eneralmente ha' pocos actores asociados a cada #aso de Uso. *reguntas clave:
?. A. B. C. cules son las tareas del actor@ qu$ informacin crea, guarda, modifica, destru'e o lee el actor@ debe el actor notificar al sistema los cambios e+ternos@ debe el sistema informar al actor de los cambios internos@

La des"rip"i)n de Caso de Uso "o!prende:

?. A. B. C. E. F. G. uso@ el inicio: cundo ' qu$ actor lo produce@ el fin: cundo se produce ' qu$ valor devuelve@ la interaccin actorDcaso de uso: qu$ mensajes intercambian ambos@ objetivo del caso de uso: qu$ lleva a cabo o intenta@ cronologa ' origen de las interacciones repeticiones de comportamiento: qu$ operaciones son iteradas@ situaciones opcionales: qu$ ejecuciones alternativas se presentan en el caso de

Diagrama de Caso de Uso

Diagrama de Actividades
l &iagrama de )ctividad es una especializacin del &iagrama de stado, organizado respecto de las acciones ' usado para especificar:

Un m$todo 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 secuenciales ' concurrentes de actividades. Los grafos de actividades se muestran en diagramas de actividades. Las actividades se enlazan por transiciones automticas. #uando 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 ' salida de una accin se pueden mostrar usando las relaciones de flujo que conectan la accin ' un estado de flujo de objeto.

Un proceso de negocio !HorIfloJ"

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. n vez de esperar un evento, como en un estado de espera normal, un estado de actividad espera la terminacin de su cmputo. #uando 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 cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos e+plcitos, peor pueden ser abortados por transiciones en estados que los inclu'en. Un grafo de actividades puede contener tambi$n estados de accin, que son similares a los de actividad pero son atmicos ' no permiten transiciones mientras estn activos. Los estados de accin se deben utilizar para las operaciones cortas de mantenimiento. Un diagrama de actividades puede contener bifurcaciones, as como divisiones de control en hilos concurrentes. los hilos concurrentes representan actividades que se pueden realizar concurrentemente por los diversos objetos o personas. La concurrencia 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, e+cepto que permite el control de concurrencia adems del control secuencial.

'otaci#n

'otaci#n

Un estado de actividad se representa como una caja con los e+tremos 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 transiciones o como diamantes con m%ltiples flechas de salida etiquetadas. Una divisin o una unin de control se representa con m%ltiples flechas que entran o salen de la barra gruesa de sincronizacin. #uando es necesario incluir eventos e+ternos, la recepcin de un evento se puede mostrar como un disparador en una transicin, o como un smbolo especial que denota la espera de una se0al. ) menudo es %til organizar las actividades en un modelo seg%n su responsabilidad. sta clase de asignacin puede mostrarse organizando las actividades en regiones distintas separads por lneas en el diagrama. &ebido a su aspecto, esto es conocido como Calles. Un diagrma de actividades puede mostrar el flujo de objetos como valores. *ara un valor de salida, se dibuja una flecha con lnea discontinua desde la actividad al objeto. *ara un valor de entrada, se dibuja una flecha con lnea discontinua desde el objeto a una actividad.

Diagrama de Actividades

Ejemplo de Diagrama de Actividades

Diagramas de Estado
/uestra 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 &iagramas de stado representan autmatas de estados finitos, desde el p.d.v. de los estados ' las transiciones. -on %tiles slo para los objetos con un comportamiento significativo. #ada objeto est en un estado en cierto instante. l estado est caracterizado parcialmente por los valores algunos de los atributos del objeto. l estado en el que se encuentra un objeto determina su comportamiento. #ada objeto sigue el comportamiento descrito en el &iagrama de stados asociado a su clase. Los &iagramas de stados ' escenarios son complementarios, los &iagramas de stados son autmatas jerrquicos que permiten e+presar concurrencia, sincronizacin ' jerarquas de objetos, son grafos dirigidos ' deterministas. La transicin entre estados es instantnea ' se debe a la ocurrencia de un evento.

(stado
5dentifica un periodo de tiempo del objeto !no instantneo" en el cual el objeto est esperando alguna operacin, tiene cierto estado caracterstico o puede recibir cierto tipo de estmulos. -e representa mediante un rectngulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor caracterstico de los atributos del objeto en ese estado ' otro para las acciones que se realizan al entrar, salir o estar en un estado !entr', e+it o do, respectivamente

(ventos
s una ocurrencia que puede causar la transicin de un estado a otro de un objeto. sta ocurrencia puede ser una de varias cosas:

#ondicin que toma el valor de verdadero o falso (ecepcin de una se0al de otro objeto en el modelo (ecepcin de un mensaje *aso de cierto perodo de tiempo, despu$s de entrar al estado o de cierta hora ' fecha particular

l nombre de un evento tiene alcance dentro del paquete en el cual est definido, no es local a la clase que lo nombre.

(nv"o de mensa!es
)dems de mostrar ' transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros objetos. sto se realiza mediante una lnea punteada dirigida al diagrama de estados del objeto receptor del mensaje.

)ransici#n simple
Una transicin simple es una relacin entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado ' ejecutar ciertas operaciones, cuando un evento ocurre ' si ciertas condiciones son satisfechas. -e representa como una lnea slida entre dos estados, que puede venir acompa0ada de un te+to con el siguiente formato:
event-signature " " guard-condition! """ action-e#pression "$"send-clause

event-signature es la descripcin del evento que da lugar la transicin, guardDcondition son las condiciones adicionales al evento necesarias para que la transicin ocurra, action-e#pression es un

mensaje al objeto o a otro objeto que se ejecuta como resultado de la transicin ' el cambio de estado ' sendDclause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envo de eventos a otros paquetes o clases.

)ransici#n interna
s una transicin que permanece en el mismo estado, en vez de involucrar dos estados distintos. (epresenta un evento que no causa cambio de estado. -e denota como una cadena adicional en el compartimiento de acciones del estado.

Acciones:
*odemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transicin. -e puede especificar el ejecutar una accin como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento <enerali&aci%n de Estados/

*odemos reducir la complejidad de estos diagramas usando la generalizacin de estados. &istinguimos as entre superestado ' subestados. Un estado puede contener varios subestados disjuntos. Los subestados heredan las variables de estado ' las transiciones e+ternas. La agregacin de estados es la composicin de un estado a partir de varios estados independientes.

La composicin es concurrente por lo que el objeto estar en alguno de los estados de 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 llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto.

*u estados
Un estado puede descomponerse en subestados, con transiciones entre ellos ' cone+iones al nivel superior. Las cone+iones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas ' salidas del nivel inmediatamente superior.

)ransacci#n Comple!a
Una transicin compleja relaciona tres o ms estados en una transicin de m%ltiples fuentes '>o m%ltiples destinos. (epresenta la

subdivisin en threads del control del objeto o una sincronizacin. -e representa como una lnea vertical de la cual salen o entran varias lneas de transicin de estado.

)ransici#n a estados anidados

Una transicin de hacia un estado complejo !descrito mediante estados anidados" significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera !a cualquier nivel de profundidad".

)ransiciones tempori&adas

Las esperas son actividades que tienen asociada cierta duracin. La actividad de espera se interrumpe cuando el evento esperado tiene lugar. ste evento desencadena una transicin que permite salir del estado que alberga la actividad de espera. l flujo de control se transmite entonces a otro estado.

Diagrama de Estado

Ejemplo de Diagrama de Estado

-i desea colocar sus cometarios acerca del tema o desea hacer preguntas del mismo lo puede hacer en nuestro foro

Diagramas de %nteracci&n'
Diagramas de Diagramas de *ecuencia Cola oraci#n
La vista de interaccin describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente 2un rol2, es la descripcin de un objeto, que desempe0a un determinado papel dentro de una interaccin, distinto de los otros objetos de la misma clase. sta visin proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de control a trav$s de muchos objetos. La vista de interaccin se e+hibe en dos diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos individuales ' centrados en objetos cooperantes. Los objetos interact%an para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccin. +isten dos tipos de diagramas de interaccin: el &iagrama de #olaboracin ' el

&iagrama de -ecuencia. l &iagrama de -ecuencia es ms adecuado para observar la perspectiva cronolgica de las interacciones, muestra la secuencia e+plcita de mensajes ' son mejores para especificaciones de tiempo real ' para escenarios complejos. l &iagrama de #olaboracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetos, muestra las relaciones entre objetos ' son mejores para comprender todos los efectos que tiene un objeto ' para el dise0o de procedimientos. l diagrama de #olaboracin puede obtenerse automticamente a partir del correspondiente diagrama de -ecuencia !o viceversa".

Diagramas de *ecuencia:
1. >uestra la secuencia de mensajes entre objetos durante un escenario concreto 2. ada objeto viene dado por una barra vertical 3. El tiempo transcurre de arriba abajo 3. uando e,iste demora entre el env'o y la atenci%n se puede indicar usando una l'nea oblicua

Diagramas de Cola oraci#n:

1. >uestra la secuencia de mensajes entre objetos durante un escenario concreto 2. ada objeto viene dado por una barra vertical 3. El tiempo transcurre de arriba abajo 3. uando e,iste demora entre el env'o y la atenci%n se puede indicar usando una l'nea oblicua

Diagramas de Cola oraci#n:

1. Son $tiles en la #ase e,ploratoria para identi#icar objetos. 2. 5a distribuci%n de los objetos en el diagrama permite observar adecuadamente la interacci%n de un objeto con respecto de los dem!s 3. 5a estructura est!tica viene dada por los enlaces? la din!mica por el env'o de mensajes por los enlaces

+u, es una Cola oraci#nEs una descripcin de una coleccin de o$jetos que interact0an para implementar un cierto comportamiento dentro de un conte*to. Descri$e una sociedad de o$jetos cooperantes unidos para reali/ar un cierto propsito. Una cola$oracin contiene ranuras que son rellenadas por los o$jetos % enlaces en tiempo de ejecucin. Una ranura de cola$oracin se llama <ol porque descri$e el propsito de un o$jeto o un enlace dentro de la cola$oracin.

Un rol clasificador representa una descripcin de los o$jetos que pueden participar en una ejecucin de la cola$oracin, un rol de asociacin representa una descripcin de los enlaces que pueden participar en una ejecucin de cola$oracin. Un rol de clasificador es una asociacin que est' limitada por tomar parte en la cola$oracin. Las relaciones entre roles de clasificador % asociacin dentro de una cola$oracin slo tienen sentido en ese conte*to. En general fuera de ese conte*to no se aplican las mismas relaciones. Una Cola$oracin tiene un aspecto estructural % un aspecto de comportamiento. El aspecto estrucutral es similar a una vista est'tica. contiene un conjunto de roles % relaciones que definen el conte*to para su comprtamiento. El comportamiento es el conjunto de mensajes intercam$iados por los o$jetos ligados a los roles. =al conjunto de mensajes en una cola$oracin se llama >nteraccin. Una cola$oracin puede incluir una o m's interacciones.

+u, es una .nteracci#n-

Es el conjunto de mensajes intercam$iados por los roles de clasificador a travs de los roles de asociacin. Un mensaje es una comunicain unidireccional entre dos o$jetos, un flujo de o$jeto con la informacin de un remitente a un receptor. Un mensaje puede tener par'metros que transporten valores entre o$jetos. Un mensaje puede ser una se)al !comunicacin e*pl,cita entre o$jetos, con nom$re % as,ncrona" o una llamada !la invocacin s,ncrona de una operacin con un mecanismo para el control, que retorna posteriormente al remitente". Un patrn de intercam$ios de mensajes que se reali/an para lograr un propsito espec,fico es lo que se denomina una interaccin.

+u, es /atr#nUn patrn es una cola$oracin parametri/ada, junto con las pautas so$re cu'ndo utili/arlo. Un par'metro se puede sustituir por diversos valores, para producir distintas cola$oraciones. Los par'metros se)alan generalmente las ranuras para las clases. El uso de un patrn se representa como una elipse de l,nea discontinua conectada con cada una de las clases por una l,nea discontinua, que se etiqueta con el nom$re del rol.

Diagramas de Despliegue

Los &iagramas de &espliegue muestran la disposicin fsica de los distintos nodos que componen un sistema ' el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposicin de las instancias de componentes de ejecucin en instacias de nodos conectados por enlaces de comunicacin. Un nodo es un recurso de ejecucin tal como un computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del equipo:

&ispositivos *rocesadores /emoria Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. sta vista permite determinar las consecuencias de la distribucin ' la asignacin de recursos. Las instancias de los nodos pueden contener instancias de ejecucin, como instancias de componentes ' objetos. l modelo puede mostrar dependencias entre las instancias ' sus interfaces, ' tambi$n modelar la migracin de entidades entre nodos u otros contenedores. sta vista tiene una forma de descriptor ' otra de instancia. La forma de instancia muestra la localizacin de las instancias de los componentes especficos en instancias especficas del nodo como parte de una configuracin del sistema. La forma de descriptor muestra qu$ tipo de componentes pueden subsistir en qu$ tipos de nodos ' qu$ tipo de nodos se pueden conectar, de forma similar a una diagrama de clases, esta forma es menos com%n que la primera.

Diagrama de Componentes Diagramas de Componentes

Los diagramas de componentes describen los elementos fsicos del sistema ' sus relaciones. /uestran las opciones de realizacin

inclu'endo cdigo fuente, binario ' ejecutable. Los componentes representan todos los tipos de elementos softJare que entran en la fabricacin de aplicaciones informticas. *ueden ser simples archivos, paquetes de )da, bibliotecas cargadas dinmicamente, etc. Las relaciones de dependencia 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 softJare, inclu'endo componentes de cdigo fuente, componentes del cdigo binario, ' componentes ejecutables. Un mdulo de softJare se puede representar como componente. )lgunos componentes e+isten en tiempo de compilacin, algunos en tiempo de enlace ' algunos en tiempo de ejecucin, otros en varias de $stas. Un componente de slo compilacin es aquel que es significativo %nicamente en tiempo de compilacin. Un componente ejecutable es un programa ejecutable. Un diagrama de componentes tiene slo una versin con descriptores, no tiene versin con instancias. *ara mostrar las instancias de los componentes se debe usar un diagrama de despliegue. Un diagrama de componentes muestra clasificadores de componentes, las clases definidas en ellos, ' las relaciones entre ellas. Los clasificadores de componentes tambi$n se pueden anidar dentro de otros clasificadores de componentes para mostrar relaciones de definicin. Un diagrama que contiene clasificadores de componentes ' de nodo se puede utilizar para mostrar las dependencias del compilador, que se representa como flechas con lneas discontinuas !dependencias" de un componente cliente a un componente proveedor del que depende. Los tipos de dependencias son especficos del lenguaje ' se pueden representar como estereotipos de las dependencias. l diagrama tambi$n puede usarse para mostrar interfaces ' las dependencias de llamada entre componentes, usando flechas con lneas discontinuas desde los componentes a las interfaces de otros componentes. l diagrama de componente hace parte de la vista fsica de un sistema, la cual modela la estructura de implementacin de la aplicacin por s misma, su organizacin en componentes ' su despliegue en nodos de ejecucin. sta vista proporciona la oportunidad de establecer correspondecias entre las clases ' los componentes de implementacin ' nodos. La vista de implementacin se representa con los diagramas de componentes.

Diagrama de Componentes

+u, es Componentes una parte fsica reemplazable de un sistema que empaqueta su implementacin ' es conforme a un conjunto de interfaces a las que proporciona su realizacin. )lgunos componentes tienen identidad ' pueden poseer entidades fsicas, que inclu'en objetos en tiempo de ejecucin, documentos, bases de datos, etc. Los componentes e+istentes en el dominio de la implementacin son unidades fsicas en los computadores que se pueden conectar con otros componentes, sustituir, trasladar, archivar, etc. Los componentes tienen dos caractersticas: mpaquetan el cdigo que implementa la funcionalidad de un sistema, ' algunas de sus propias instancias de objetos que contitu'en el estado del sistema. Los llamados %ltimos componentes de la identidad, porque sus instancias poseen identidad ' estado. C&digo' Un componente contiene el cdigo para las clases de implementacin ' otros elementos. Un componente de cdigo fuente es un paquete para el cdigo fuente de las clases de implementacin. )l gunos lenguajes de programacin distinguen archivos de declaracin de los archivos de m$todo, pero todos son componentes. Un componente de

cdigo binario es un paquete para el cdigo compliado. Una biblioteca del cdigo binario es un componente. #ada tipo de componente contiene el cdigo para las clases de implementacin que realizan algunas clases e interfaces lgicas. La relacin de realizacin asocia un componente con las clases ' las interfaces lgicas que implementan sus clases de implementacin. Las interfaces de un componente describen la funcionalidad que aporta. #ada operacin de la interfaz debe hacer referencia eventualmente a un elemento de la implementacin disponible en el componente. La estrucutra esttica, ejecutable de una implementacin de un sistema se puede representar como un conjunto interconectado de componentes. Las dependencias entre componentes significan que los elementos de la implementacin en un componente requieren los serivios de los elementos de implemntacin en otros componentes. 7al uso requiere que dichos elementos sean de visibilidad p%blica.

%dentidad' Un componente de identidad tiene identidad ' estado. *osee los objetos fsicos que estn situados en $l. *uede tener atributos, relaciones de composicin con los objetos posedos, ' asociaciones con otros componentes. &esde este punto de vista es una clase. -in embargo la totalidad de su estado debe hacer referencia a las instancias que contiene. Estructura' Un componente ofrece un conjunto de elementos de implementacin, esto significa que el componente proporciona el cdigo para los elementos. Un componente puede tener operaciones e interfaces. Un componente de identidad es un contenedor fsico para las entidades fsicas como bases de datos. *ara proporcionar manejadores para sus elementos contenidos, puede tener atributos ' asociaciones salientes, que deben ser implementadas por sus elementos de implementacin. ste componente se representa con un rectngulo con dos rectngulos ms peque0os que sobresalen en su lado izquierdo. Las operaciones e interfaces disponibles para los objetos e+teriores se pueden representar directamente en el smbolo de clase. stos son su comportamiento como clase. Los contenidos del subsistema se representan en un diagrama separado. Las dependencias de un componente con otros componentes o elementos del modelo se representan usando lneas discontinuas con

la punta de flecha hacia los elementos del proveedor. - un componente es la realizacin de una interfaz, se representa con un crculo unido al smbolo del componente por un segmento de lnea.

Pa(uetes
#ualquier sistema grande se debe dividir en unidades ms peque0as, de modo que las personas puedan trabajar con una cantidad de informacin limitada, a la vez ' de modo que los equipos de trabajo no interfieran con el trabajo de los otros. Un paquete es una parte de un modelo. #ada parte del modelo debe pertenecer a un paquete. *ero para ser funcional, la asignacin debe seguir un cierto principio racional, tal como funcionalidad com%n, implementacin relacionada ' punto de vista com%n. U/L no impone una regla para componer los paquetes.

Los paquetes ofrecen un mecanismo general para la organizacin de los modelos>subsistemas agrupando elementos de modelado. #ada paquete corresponde a un submodelo !subsistema" del modelo !sistema". Los paquetes son unidades de organizacin jerrquica de uso general de los modelos de U/L. *ueden ser utilizados para el almacenamiento, el control de acceso, la gestin de la configuracin ' la construccin de bibliotecas que contengan fragmentos reutilizables del modelo.

Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elemento pertenece a !est definido en" slo un paquete. Los paquetes contienen elementos del modelo al ms alto nivel, tales como clases ' sus relaciones, mquinas de estado, diagramas de casos de uso, interacciones ' colaboraciones, atributos, operaciones, estados, lneas de vida ' mensajes estn contenidos en otros elementos ' no aparecen como contenido directo de los paquetes.

Dependen"ias en os pa+ue&es
Las dependencias que se presentan entre elementos individuales, pero en un sistema de cualquier tama0o, deben ser vistas en un nivel ms alto. las dependencias entre paquetes resumen dependencias entre los elementos internos a ellos, es decir, las dependencias del paquete son derivables a partir de las dependencias entre los elementos individuales. La presencia de una dependencia entre paquetes implica que e+iste en un enfoque ascendente !una declaracin de e+istencia", o que se permite que e+ista 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 elementos individuales dentro de los paquetes correspondientes. Las dependencias m%ltiples del mismo tipo entre elementos individuales se agregan a una sola dependencia entre los paquetes que contienen los elementos. -i las dependencias entre elementos contienen estereotipos, $ste puede ser omitido en la dependencia del paquete, para dar una sola dependencia de alto nivel.