Pasos a seguir en el diseo de un diagrama de secuencias.

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. Esto se
debe que hasta que vemos interactuando a los objetos de nuestras clases con
los actores y con otros objetos 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 diagramas de secuencias se componen de 4 elementos que son: el
curso de accin, los objetos, 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

la 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 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 esttico. Hay que ser muy meticuloso con este
paso, ya que representa el ultimo de tu modelo esttico antes de codificar.

-Paso 3: Agrega las interfaces del diagrama de robustez. Con esto ya

tenemos 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 iteraciones.

-Paso 4: Pon los mtodos en las clases, lo cual significa convertir los
controles 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 diagrama 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
responsabilidades de cada objeto.
 9.- No ponen el texto del caso de uso en el diagrama de secuencia: El
poner de vuelta este texto al margen del diagrama de secuencia provee de la
visin necesaria 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

robustez: Si tienes problemas al realizar los diagramas de secuencia es por que
tienes 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 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
'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar 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 caso
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 representan el
desarrollo de los pasos dados por las acciones generadas internamente. Deberas 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. En general, el tiempo avanza hacia abajo
dentro de la pgina (se pueden invertir los ejes si se 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 horizontal 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
secuencia 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 organizadas

visualmente por orden temporal. A diferencia de los diagramas de colaboracin, los
diagramas de secuencia incluyen secuencias temporales pero no incluyen las
relaciones entre objetos. Pueden existir de forma de descriptor (describiendo todos los
posibles escenarios) y en forma de instancia (describiendo un escenario real).

Dentro 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. En general, el tiempo avanza hacia abajo
dentro de la pgina (se pueden invertir los ejes si se 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 horizontal de los objetos no tiene ningn significado.
Un dilogo de secuencia posee dos dimensiones: la vertical
representa el tiempo, la 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 se 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 horizontal 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 el 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 existir el objeto o en
el punto en que el objeto se destruye a s mismo. Para el periodo durante el cual est
activo el objeto, la lnea de vida se ampla para ser una lnea doble continua. Si el
objeto se llama a s mismo, entonces se superpone otra copia de la doble lnea para
mostrar la doble activacin. El orden relativo de los objetos no tiene significado an
cuando resulta til organizarlos de modo que se minimice 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 recibido
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 representan
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 bifurcacin
puede enviar y recibir mensajes. Eventualmente las lneas de vida del objeto tienen
que fusionarse de nuevo.

Un diagrama de secuencia tambin se puede mostrar en forma de descriptor, en el

cual 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
descriptores se dibujan sin subrayados porque los smbolos denotan roles y no objetos
individuales.

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 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 mayora de los diagramas de UML y algunos smbolos
complejos son grafos que contienen 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 relaciones visuales: conexin (generalmente
de lneas a formas de dos dimensiones), contencin (de smbolos
por formas cerradas de dos dimensiones), y adhesin visual (un
smbolo que 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. Algunas formas bidimensionales son
proyecciones de formas tridimensionales tales como 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 terminadores en las rutas o
como smbolos independientes que puedan o no conectar con las
rutas.
Los smbolos de dos dimensiones tienen altura y anchura
variables, y pueden ampliarse para permitir otras cosas tales como
listas de cadenas o de otros smbolos. Muchos 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 y las rutas conectadas.

Una ruta es una secuencia de segmentos de recta o de

curva que se unen en sus puntos finales. Conceptualmente una
ruta es una sola entidad topolgica, aunque sus segmentos se
pueden manipular grficamente. un segemento no debera existir
separado de su ruta. Las rutas siempre van conectdas en ambos
 extremos.

Las cadenas presentan varias clases de informacin en una forma

"no analizada", UML asume que cada uso de una cadena en la
notacin tiene una sintaxis por la cual pueda ser analizada la
informacin del modelo subyancente. Las cadenas pueden existir
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

Clase, asociacin,
Diagrama de generalizacin,
Vista Esttica
Clases dependencia,
realizacin, interfaz.

Caso de Uso, Actor,

Vista de Casos de Diagramas de
asociacin, extensin,
Uso Casos de Uso
generalizacin.
Estructural

Componente, interfaz,
Vista de Diagramas de
dependencia,
Implementacin Componentes
relaizacin.

Nodo, componente,
Vista de Diagramas de
dependencia,
Despliegue Despliegue
localizacin.

Vista de Estados Diagramas de Estado, evento,

de mquina Estados transicin, accin.

Dinmica
Estado, actividad,
Diagramas de transicin,
Vista de actividad
Actividad determinacin, divisin,
unin.
 Diagramas de Interaccin, objeto,
Secuencia mensaje, activacin.

Vista de
interaccin
Colaboracin,
Diagramas de
interaccin, rol de
Colaboracin
colaboracin, mensaje.

Administracin o Vista de Gestin Diagramas de Paquete, subsistema,

Gestin de modelo de modelo Clases modelo.

Restriccin, estereotipo,
Extensin de UML Todas Todos
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 como 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
caracterizar 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
mediante una denominacin exclusiva que permite accederle. El Modelado de Objetos
permite 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 smbolo

geomtrico que el descriptor. En la instancia se muestran los posibles valores pero las
propiedades compartidas slo se pone de manifiesto en el descriptor. La notacin
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 ltimo 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 siguientes
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 independencia 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 el objeto deje de existir.

No se tiene ningn control sobre los oids y su manipulacin resulta transparente. Sin
embargo, es preciso contar con algn medio para hacer referencia a un objeto utilizando
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
reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estmulo
externo representado como mensaje enviado desde otro objeto.

Persistencia:

La persistencia de los objetos designa la capacidad de un objeto trascender en el

espacio/tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria
secundaria para utilizarlo en la ejecucin (materializacin del objeto). Los lenguajes OO
no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un
objeto existe desde su creacin hasta que se destruya.
Comunicacin:

Un sistema informtico puede verse como un conjunto de objetos autnomos y

concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico.
El comportamiento global se basa pues en la comunicacin entre los objetos que la
componen.

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 con 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
previamente 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 especificacin 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
diagrama de clases presenta las clases del sistema con sus relaciones
estructurales y de herencia. La definicin de clase incluye definiciones para
atributos y operaciones. El modelo de casos de uso aporta informacin para
establecer las clases, objetos, 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

define 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 que son:
 (-) Privado : es el ms fuerte. Esta parte es totalmente invisible (excepto
para clases 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 trata de atributos se est transgrediendo el principio de
encapsulacin)

Relaciones entre clases:

Los enlaces entre objetos pueden representarse entre las respectivas clases y sus 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 enlaces
entre los objetos. Puede determinarse por la especificacin de multiplicidad
(mnima...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
agregado?
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 complementarias
del modelo. Un Diagrama de Clases muestra la abstraccin de una parte del dominio.
Un Diagrama de Objetos representa una situacin concreta del dominio. Las clases
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.
La Generalizacin consiste en factorizar las propiedades comunes de un conjunto de
clases en una clase ms general. Los nombres usados: clase padre - clase hija. Otros
nombres: superclase - subclase, clase base - clase derivada. Las subclases heredan
propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) 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 simtricas 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
conjunto relativo a las instancias que posee o bien relativo a las propiedades de la clase.
Generalizacin y especializacin expresan relaciones de inclusin entre conjuntos

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 trabaja, o de cmo se desea que trabaje. No
pertenece estrictamente al enfoque orientado a objeto, es una tcnica
para captura de requisitos.

Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones 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 entorno.
Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de
la implementacin.
Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado.
Los Casos de Uso cubren la carencia existente en mtodos previos (OMT, Booch) en
cuanto 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 mbito
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, el nombre del actor describe el papel desempeado.
Los Casos de Uso se determinan observando y 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. 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
descrito por el Caso de Uso destino. include reemplaz al denominado uses
Extensin : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino.
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 pocos 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 caso 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 secuenciales y
concurrentes de actividades. Los grafos de actividades se muestran en diagramas de
actividades. Las actividades se enlazan por transiciones automticas. Cuando 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
usando 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 normal, 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 cuando se completa la
actividad precedente. Los estados de actividad no tienen transiciones
con eventos explcitos, peor pueden ser abortados por transiciones en
estados 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 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, 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
transiciones o como diamantes con mltiples flechas de salida
etiquetadas. Una divisin 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 mostrar como un disparador en una transicin, o
como un smbolo especial que denota la espera de una seal.
A menudo es til organizar las actividades en un modelo segn su
responsabilidad. Esta clase de asignacin puede mostrarse
organizando las actividades en regiones distintas separads por lneas
en el diagrama. Debido a su aspecto, esto es conocido como Calles.
Un diagrma de actividades puede mostrar el flujo de objetos como
valores. Para un valor de salida, se dibuja una flecha con lnea
discontinua desde la actividad al objeto. Para 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
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 comportamiento significativo. Cada objeto est en
un estado en cierto instante. El estado est caracterizado
parcialmente por los valores algunos de los atributos del objeto. El
estado en el que se encuentra un objeto determina su
comportamiento. Cada objeto sigue el comportamiento descrito en el
Diagrama de Estados asociado a su clase. Los Diagramas de Estados
y escenarios son complementarios, los Diagramas de 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 est esperando alguna operacin, tiene cierto estado
caracterstico o puede recibir cierto tipo de estmulos. Se 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 y otro para las
acciones que se realizan al entrar, salir o estar en un estado (entry,
exit o do, respectivamente

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 fecha
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 mensaje.

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-condition son las condiciones adicionales al evento
necesarias para que la transicin ocurra, 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
adicionales que se ejecutan con el cambio de estado, por ejemplo, el
envo de eventos a otros paquetes o clases.

Transicin interna
Es una transicin que permanece en el mismo estado, en vez de
involucrar dos estados 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 entrar, 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
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.

Subestados
Un estado puede descomponerse en subestados, con transiciones
entre ellos y conexiones al nivel superior. Las conexiones se ven al
nivel inferior como estados de inicio o fin, los cuales se suponen
conectados a las entradas y salidas del nivel inmediatamente
superior.

Transaccin Compleja
Una transicin compleja relaciona tres o ms estados en una
transicin de mltiples fuentes y/o mltiples destinos. Representa la
subdivisin en threads del control del objeto o una sincronizacin. Se
representa como una lnea vertical de la cual salen o entran varias
lneas de transicin de estado.

Transicin 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).

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 mismo lo puede hacer en nuestro
foro

Diagramas de Interaccin:
Diagramas de Diagramas de
Secuencia 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 simplemente "un rol", es la descripcin
de un objeto, que desempea un determinado papel dentro de una
interaccin, distinto de los otros objetos de la misma clase. Esta
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 exhibe en dos diagramas centrados en
distintos aspectos pero complementarios: centrados en los objetos
individuales y centrados en objetos cooperantes.

Los objetos interactan para realizar colectivamente los servicios

ofrecidos por las aplicaciones. Los diagramas de interaccin muestran
cmo se comunican los objetos en una interaccin. Existen dos tipos
de diagramas de interaccin: el Diagrama de Colaboracin 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 Colaboracin ofrece
una mejor visin espacial mostrando los enlaces de comunicacin
entre objetos, muestra las relaciones entre objetos y son mejores
para comprender todos los efectos que tiene un objeto y para el
diseo de procedimientos. El diagrama de Colaboracin puede
obtenerse automticamente a partir del correspondiente diagrama de
Secuencia (o viceversa).

Diagramas de Secuencia:
1. Muestra la secuencia de mensajes entre objetos durante un escenario
concreto
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 una lnea oblicua

Diagramas de Colaboracin:
1. Muestra la secuencia de mensajes entre objetos durante un escenario
concreto
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 una 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
adecuadamente 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
cierto comportamiento dentro de un contexto. Describe una sociedad de objetos
cooperantes unidos para realizar un cierto propsito. Una colaboracin contiene ranuras
que 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 dentro
de la colaboracin.
Un rol clasificador representa una descripcin de los objetos que pueden participar en
una ejecucin de la colaboracin, un rol de asociacin representa una descripcin de los
enlaces que pueden participar en una ejecucin de colaboracin. Un rol de clasificador
es una asociacin que est limitada por tomar parte en la colaboracin. Las relaciones
entre roles de clasificador y asociacin dentro de una colaboracin slo tienen 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
aspecto 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 de los

roles de asociacin. Un mensaje es una comunicain unidireccional entre dos objetos,
un flujo de objeto con la informacin de un remitente a un receptor. Un mensaje puede
tener parmetros que transporten valores entre objetos. Un mensaje puede ser una seal
(comunicacin explcita entre objetos, con nombre y asncrona) o una llamada (la
invocacin sncrona de una operacin con un mecanismo para el control, que retorna
posteriormente al remitente). Un patrn de intercambios de mensajes que se realizan
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
utilizarlo. 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 cada 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 que componen un sistema y 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:

Dispositivos
Procesadores
Memoria

Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez

estereotiparse. Esta vista permite determinar las consecuencias de la distribucin y la
asignacin de recursos. Las instancias de los nodos pueden contener instancias de
ejecucin, como instancias de componentes y objetos. El modelo puede mostrar
dependencias entre las instancias y sus interfaces, y tambin modelar la migracin de
entidades entre nodos u otros contenedores.
Esta vista tiene una forma de descriptor y 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 y
qu tipo de nodos se pueden conectar, de forma similar a una diagrama de 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 relaciones. Muestran las opciones de realizacin
incluyendo cdigo fuente, binario y ejecutable. 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 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 software, incluyendo componentes de cdigo fuente,
componentes del cdigo binario, y componentes ejecutables. Un
mdulo de software se puede representar como componente. Algunos
componentes existen en tiempo de compilacin, algunos en tiempo
de enlace y 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. Para 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, y las relaciones entre
ellas. Los clasificadores de componentes tambin se pueden anidar
dentro de otros clasificadores de componentes para mostrar
relaciones de definicin.
Un diagrama que contiene clasificadores de componentes y 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 y se pueden
representar como estereotipos de las dependencias.
El diagrama tambin puede usarse para mostrar interfaces y las
dependencias de llamada entre componentes, usando flechas con
lneas discontinuas desde los componentes a las interfaces de otros
componentes.

El 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 y su
despliegue en nodos de ejecucin. Esta vista proporciona la
oportunidad de establecer correspondecias entre las clases y los
componentes de implementacin y nodos. La vista de implementacin
se representa con los diagramas de componentes.

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 incluyen objetos en tiempo de ejecucin, documentos,
bases de datos, etc. Los componentes existentes 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: Empaquetan el cdigo
que implementa la funcionalidad de un sistema, y algunas de sus
propias instancias de objetos que contituyen 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 de implementacin. Al gunos
lenguajes de programacin distinguen archivos de declaracin de los
archivos de mtodo, pero todos son componentes. Un componente de
cdigo binario 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 realizan algunas clases e interfaces lgicas. La
relacin de realizacin asocia un componente con las clases y las
interfaces lgicas que implementan sus clases de implementacin.
Las interfaces de un componente describen la funcionalidad que
aporta. Cada 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.
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 objetos 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
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. Para proporcionar manejadores para sus
elementos contenidos, puede tener atributos y asociaciones salientes,
que deben ser implementadas por sus elementos de implementacin.
Este componente se representa con un rectngulo con dos
rectngulos ms pequeos que sobresalen en su lado izquierdo.
Las operaciones e interfaces disponibles para los objetos exteriores se
pueden representar directamente en el smbolo de clase. Estos 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. S un
componente es la realizacin de una interfaz, se representa con 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
personas puedan trabajar con una cantidad de informacin limitada, a la vez y de
modo 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 racional,
tal como funcionalidad comn, implementacin relacionada y punto de vista comn.
UML 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. Cada
paquete corresponde a un submodelo (subsistema) del modelo
(sistema). Los paquetes son unidades de organizacin jerrquica de
uso general de los modelos de UML. Pueden ser utilizados para el
almacenamiento, el control de acceso, la gestin de la configuracin y
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 y sus relaciones, mquinas de estado, diagramas de
casos de uso, interacciones y colaboraciones; atributos, operaciones,
estados, lneas de vida y mensajes estn contenidos 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 sistema de cualquier tamao, 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 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
elementos 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 dependencias entre elementos
contienen estereotipos, ste puede ser omitido en la dependencia del
paquete, para dar una sola dependencia de alto nivel.