DIAGRAMAS EN UML

CONALEP 173 CUAUTLA

URIEL RODRIGUEZ BARRERA

Carrera: PTB en Informtica.
Grupo: 4105
DIAGRAMA DE CLASES
Introduccin

Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Elementos

Clase

Es la unidad bsica que encapsula toda la informacin de un Objeto (un

objeto es una instancia de una clase). A travs de ella podemos modelar el
entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectngulo que posee tres

divisiones:

En donde:

o Superior: Contiene el nombre de la Clase

o Intermedio: Contiene los atributos (o variables de instancia) que

caracterizan a la Clase (pueden ser private, protected o public).

o Inferior: Contiene los mtodos u operaciones, los cuales son la

forma como interacta el objeto con su entorno (dependiendo de la
visibilidad: private, protected o public).

Ejemplo:
Una Cuenta Corriente que posee como caracterstica:

o Balance

Puede realizar las operaciones de:

o Depositar

o Girar

o y Balance

El diseo asociado es:

Atributos y Mtodos:

o Atributos:

Los atributos o caractersticas de una Clase pueden ser de tres tipos,

los que definen el grado de comunicacin y visibilidad de ellos con
el entorno, estos son:

public (+, ): Indica que el atributo ser visible tanto

dentro como fuera de la clase, es decir, es accsesible desde
todos lados.

private (-, ): Indica que el atributo slo ser accesible

desde dentro de la clase (slo sus mtodos lo pueden
accesar).

protected (#, ): Indica que el atributo no ser accesible

desde fuera de la clase, pero si podr ser accesado por
 mtodos de la clase adems de las subclases que se deriven
(ver herencia).

o Mtodos:

Los mtodos u operaciones de una clase son la forma en como sta

interacta con su entorno, stos pueden tener las caractersticas:

public (+, ): Indica que el mtodo ser visible tanto dentro

como fuera de la clase, es decir, es accsesible desde todos
lados.

private (-, ): Indica que el mtodo slo ser accesible

desde dentro de la clase (slo otros mtodos de la clase lo
pueden accesar).

protected (#, ): Indica que el mtodo no ser accesible

desde fuera de la clase, pero si podr ser accesado por
mtodos de la clase adems de mtodos de las subclases que
se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se

pueden interrelacionar dos o ms clases (cada uno con caractersticas y
objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En

UML, la cardinalidad de las relaciones indica el grado y nivel de
dependencia, se anotan en cada extremo de la relacin y stas pueden ser:

o uno o muchos: 1..* (1..n)

o 0 o muchos: 0..* (0..n)

o nmero fijo: m (m denota el nmero).

o Herencia (Especializacin/Generalizacin):
 Indica que una subclase hereda los mtodos y atributos
especificados por una Super Clase, por ende la Subclase adems de
poseer sus propios mtodos y atributos, poseer las caractersticas y
atributos visibles de la Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camin heredan de Vehculo,

es decir, Auto posee las Caractersticas de Vehculo (Precio,
VelMax, etc) adems posee algo particular que es Descapotable, en
cambio Camin tambin hereda las caractersticas de Vehiculo
(Precio, VelMax, etc) pero posee como particularidad propia
Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo nico "visible" es el

mtodo Caracteristicas aplicable a instancias de Vehculo, Auto y
Camin, pues tiene definicin publica, en cambio atributos como
Descapotable no son visibles por ser privados.

o Agregacin:

Para modelar objetos complejos, n bastan los tipos de datos bsicos

que proveen los lenguajes: enteros, reales y secuencias de
caracteres. Cuando se requiere componer objetos que son instancias
de clases definidas por el desarrollador de la aplicacin, tenemos
dos posibilidades:

Por Valor: Es un tipo de relacin esttica, en donde el

tiempo de vida del objeto incluido esta condicionado por el
tiempo de vida del que lo incluye. Este tipo de relacin es
comunmente llamada Composicin (el Objeto base se
contruye a partir del objeto incluido, es decir, es
"parte/todo").

Por Referencia: Es un tipo de relacin dinmica, en donde el

tiempo de vida del objeto incluido es independiente del que
lo incluye. Este tipo de relacin es comunmente
llamada Agregacin (el objeto base utiliza al incluido para su
funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacen posee Clientes y Cuentas (los rombos van en el

objeto que posee las referencias).

Cuando se destruye el Objeto Almacen tambin son

destruidos los objetos Cuenta asociados, en cambio no son
afectados los objetos Cliente asociados.

La composicin (por Valor) se destaca por un rombo relleno.

La agregacin (por Referencia) se destaca por un rombo

transparente.
 La flecha en este tipo de relacin indica la navegabilidad del objeto
refereniado. Cuando no existe este tipo de particularidad la flecha se
elimina.

o Asociacin:

La relacin entre clases conocida como Asociacin, permite asociar

objetos que colaboran entre si. Cabe destacar que no es una relacin
fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en

cambio una orden de compra solo puede tener asociado un cliente.

o Dependencia o Instanciacin (uso):

Representa un tipo de relacin muy particular, en la que una clase es

instanciada (su instanciacin es dependiente de otro objeto/clase).
Se denota por una flecha punteada.

El uso ms particular de este tipo de relacin es para denotar la

dependencia que tiene una clase de otra, como por ejemplo una
aplicacin grafica que instancia una ventana (la creacin del Objeto
Ventana esta condicionado a la instanciacin proveniente desde el
objeto Aplicacion):

Cabe destacar que el objeto creado (en este caso la Ventana grfica)
no se almacena dentro del objeto que lo crea (en este caso la
Aplicacin).

ii. Casos Particulares:

 o Clase Abstracta:

Una clase abstracta se denota con el nombre de la clase y de los

mtodos con letra "itlica". Esto indica que la clase definida no
puede ser instanciada pues posee mtodos abstractos (an no han
sido definidos, es decir, sin implementacin). La nica forma de
utilizarla es definiendo subclases, que implementan los mtodos
abstractos definidos.

o Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo

superior de la clase, en donde se especifican los parmetros que
deben ser pasados a la clase para que esta pueda ser instanciada. El
ejemplo ms tpico es el caso de un Diccionario en donde una llave
o palabra tiene asociado un significado, pero en este caso las llaves
y elementos pueden ser genricos. La genericidad puede venir dada
de un Template (como en el caso de C++) o bien de alguna
estructura predefinida (especializacin a travs de clases).

En el ejemplo no se especificaron los atributos del Diccionario,

pues ellos dependern exclusivamente de la implementacin que se
le quiera dar.

Ejemplo:
Supongamos que tenemos tenemos un el caso del Diccionario implementado
mediante un rbol binario, en donde cada nodo posee:

key: Variable por la cual se realiza la bsqueda, puede ser generica.

item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo

tambin puede ser genrico.

Para este caso particular hemos definido un Diccionario para almacenar String y
Personas, las cuales pueden funcionar como llaves o como item, solo se
mostrarn las relaciones para la implementacin del Diccionario:

DUAGRAMA DE OBJETOS

Los diagramas de objetos representan las instancias de su proyecto de

desarrollo
Los diagramas de objetos de UModel 2017 representan un nico ejemplo de
una clase y se utilizan para ilustrar un punto de datos en su aplicacin. Cuando
cree un objeto nuevo, llamado especificacin de instancia, UModel le permite
asignar una clase ya existente representada por la instancia. UModel ofrece
automticamente al objeto instancias de las propiedades pertinentes desde la
clase y el usuario puede insertar valores de muestras para el objeto.

Los diagramas de objetos UML utilizan una notacin similar a los diagramas de
clases y se utilizan para ilustrar una instancia de una clase en un momento
dado. Imagine que desea dibujar un diagrama de objetos para ilustrar un
ejemplo real de una clase y de sus relaciones.

Los diagramas de objetos pueden ayudar a explicar las clases y su herencia. A

veces se dibujan durante el proceso de planificacin de clases o para ayudar a
partes interesadas para quienes los diagramas de clases sean demasiado
abstractos.

Puesto que los diagramas de objetos utilizan notaciones muy similares a los
diagramas de clases, la barra de herramientas de diagramas de objetos usan
algunos de los iconos de la barra de herramientas de diagramas de clases. Para
editar los atributos y valores de un objeto puede utilizar la barra de
herramientas, el dilogo de propiedades o editarlos directamente en el
diagrama.

DIAGRAMAS DE CASO DE USO

Introduccin

El diagrama de casos de uso representa la forma en como un Cliente (Actor)

opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los
elementos interactuan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Actor.

Casos de Uso.

Relaciones de Uso, Herencia y Comunicacin.

Elementos

Actor:

Una definicin previa, es que un Actor es un rol que un usuario juega con
respecto al sistema. Es importante destacar el uso de la palabra rol, pues
con esto se especifica que un Actor no necesariamente representa a una
persona en particular, sino ms bien la labor que realiza frente al sistema.

Como ejemplo a la definicin anterior, tenemos el caso de un sistema de

ventas en que el rol de Vendedor con respecto al sistema puede ser
realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:
 Es una operacin/tarea especfica que se realiza tras una orden de algn
agente externo, sea desde una peticin de un actor o bien desde la
invocacin desde otro caso de uso.

Relaciones:

o Asociacin

Es el tipo de relacin ms bsica que indica la invocacin desde un

actor o caso de uso a otra operacin (caso de uso). Dicha relacin se
denota con una flecha simple.

o Dependencia o Instanciacin

Es una forma muy particular de relacin entre clases, en la cual una

clase depende de otra, es decir, se instancia (se crea). Dicha relacin
se denota con una flecha punteada.

o Generalizacin

Este tipo de relacin es uno de los ms utilizados, cumple una doble

funcin dependiendo de su estereotipo, que puede ser
de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relacin esta orientado exclusivamente para casos de

uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a

otro (caractersticas).

uses: Se recomienda utilizar cuando se tiene un conjunto de

caractersticas que son similares en ms de un caso de uso y no se
desea mantener copiada la descripcin de la caracterstica.

De lo anterior cabe mencionar que tiene el mismo paradigma en

diseo y modelamiento de clases, en donde esta la duda clsica
de usar o heredar.
Ejemplo:

Como ejemplo esta el caso de una Mquina Recicladora:

Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El

sistema debe controlar y/o aceptar:

Registrar el nmero de temes ingresados.

Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositado

b. El valor de cada item

c. Total

El usuario/cliente presiona el botn de comienzo

Existe un operador que desea saber lo siguiente:

a. Cuantos temes han sido retornados en el da.

b. Al final de cada da el operador solicita un resumen de todo lo

depositado en el da.

El operador debe adems poder cambiar:

a. Informacin asociada a temes.

b. Dar una alarma en el caso de que:

i. Item se atora.

ii. No hay ms papel.

Como una primera aproximacin identificamos a los actores que interactuan con
el sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede
cambiar la informacin de un Item o bien puede Imprimir un informe:

Adems podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresin de comprobantes, que puede ser realizada despus

de depositar algn item por un cliente o bien puede ser realizada a peticin de un
operador.
Entonces, el diseo completo del diagrama Use Case es:

DIAGRAMAS DE ESTADO
Diagrama de estados
 De Wikipedia, la enciclopedia libre
Saltar a navegacin, bsqueda
En UML, un diagrama de estados es un diagrama utilizado para identificar cada una de las
rutas o caminos que puede tomar un flujo de informacin luego de ejecutarse cada proceso.
Permite identificar bajo qu argumentos se ejecuta cada uno de los procesos y en qu
momento podran tener una variacin.
El diagrama de estados permite visualizar de una forma secuencial la ejecucin de cada uno
de los procesos.

externos
Diagramas de estado en UML

Los diagramas de estado describen grficamente los eventos y los estados de los objetos.
Los diagramas de estado son tiles, entre otras cosas, para indicar los eventos del sistema
en los casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es
la condicin de un objeto en un momento determinado: el tiempo que transcurre entre
eventos. Una transicin es una relacin entre dos estados, e indica que, cuando ocurre un
evento, el objeto pasa del estado anterior al siguiente.

Diagramas de estado
Los diagramas de estado describen grficamente los eventos y los estados de los objetos. Los
diagramas de estado son tiles, entre otras cosas, para indicar los eventos del sistema en los
casos de uso.
Unevento es un acontecimiento importante a tomar en cuenta para el sistema. Unes tado es
la condicin de un objeto en un momento determinado: el tiempo que transcurre entre
eventos. Unatr ans icin es una relacin entre dos estados, e indica que, cuando ocurre un
evento, el objeto pasa del estado anterior al siguiente.
En UML, los estados se representan mediante valos. Las transiciones se representan
mediante flechas con el nombre del evento respectivo. Se acostumbra poner un estado inicial
(crculo negro). Por ejemplo:

Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le ocurren,
sus transiciones, y los estados que median entre estos eventos.
En particular, es til hacer diagramas de estado para describir la secuencia permitida de
eventos en los casos de uso. Por ejemplo, en el caso de usocom pr ar Pr oductos no est
permitido efectuarpagoT ar jeta mientras no haya ocurrido el eventoter m inar Venta.
Un diagrama de estado que describe los eventos globales del sistema y su secuencia en un
caso de uso es un diagrama de estado para casos de uso. Por ejemplo, una versin
simplificada del diagrama de estados para el caso de usocom pr ar Pr oductos es el siguiente:

Una versin ms completa del diagrama anterior se muestra en la siguiente figura:

El diagrama anterior aun no est completo, pues falta considerar algunos casos
excepcionales, como por ejemplo, si al rechazar una tarjeta de crdito o un cheque, el cliente
decide pagar usando otro mtodo, por ejemplo pagando en efectivo.
DIAGRAMA DE SECUENCIA

Diagrama de Secuencia
Un diagrama de secuencia es una forma de diagrama de interaccin que muestra los objetos como
lneas de vida a lo largo de la pgina y con sus interacciones en el tiempo representadas como
mensajes dibujados como flechas desde la lnea de vida origen hasta la lnea de vida destino. Los
diagramas de secuencia son buenos para mostrar qu objetos se comunican con qu otros objetos y
qu mensajes disparan esas comunicaciones. Los diagramas de secuencia no estn pensados para
mostrar lgicas de procedimientos complejos.

Lnea de Vida
Una lnea de vida representa un participante individual en un diagrama de secuencia. Una lnea de
vida usualmente tiene un rectngulo que contiene el nombre del objeto. Si el nombre es self entonces
eso indica que la lnea de vida representa el clasificador que posee el diagrama de secuencia.

Algunas veces un diagrama de secuencia tendr una lnea de vida con un smbolo del elemento actor
en la parte superior. Este usualmente sera el caso si un diagrama de secuencia es contenido por un
caso de uso. Los elementos entidad, control y lmite de los diagramas de robustez tambin pueden
contener lneas de vida.
Mensajes
Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o
encontrados; sncronos o asncronos: llamadas o seales. En el siguiente diagrama, el primer mensaje
es un mensaje sncrono (denotado por una punta de flecha oscura), completo con un mensaje de
retorno implcito; el segundo mensaje es asncrono (denotado por una punta de flecha en lnea) y el
tercero es un mensaje de retorno asncrono (denotado por una lnea punteada).

Ocurrencia de ejecucin
Un rectngulo fino a lo largo de la lnea de vida denota la ocurrencia de ejecucin o activacin de un
foco de control. En el diagrama anterior hay tres ocurrencias de ejecucin. El primero es el objeto
origen que enva dos mensajes y recibe dos respuestas, el segundo es el objeto destino que recibe un
mensaje asncrono y retorna una respuesta, y el tercero es el objeto destino que recibe un mensaje
asncrono y retorna una respuesta.

Mensaje Self
Un mensaje self puede representar una llamada recursiva de una operacin, o un mtodo llamando a
otro mtodo perteneciente al mismo objeto. Este se muestra como cuando crea un foco de control
anidado en la ocurrencia de ejecucin de la lnea de vida.
Mensajes perdidos y encontrados
Los mensajes perdidos son aquellos que han sido enviados pero que no han llegado al destino
esperado, o que han llegado a un destino que no se muestra en el diagrama actual. Los mensajes
encontrados son aquellos que llegan de un remitente no conocido, o de un remitente no conocido en el
diagrama actual. Ellos se denotan yendo o llegando desde un elemento de punto final.

Inicio y final de lnea de vida

Una lnea de vida se puede crear o destruir durante la escala de tiempo representada por un diagrama
de secuencia. En el ltimo caso, la lnea de vida se termina por un smbolo de detencin, representado
como una cruz. En el primer caso, el smbolo al inicio de la lnea de vida se muestra en un nivel ms
bajo de la pgina que el smbolo del objeto que caus la creacin. El siguiente diagrama muestra un
objeto que fue creado y destruido.
Restricciones de tiempo y duracin
En forma predeterminada, un mensaje se muestra como una lnea horizontal. Ya que la lnea de vida
representa el pasaje de tiempo hacia abajo, cuando se modela un sistema en tiempo real, o incluso un
proceso de negocios en tiempo lmite, puede ser importante considerar el tiempo que toma realizar las
acciones. Al configurar una restriccin de duracin para un mensaje, el mensaje se mostrar como
una lnea inclinada.

Fragmentos combinados

Se estableci anteriormente que no se espera que los diagramas de secuencia muestren lgicas de
procedimientos complejos. Siendo este el caso, hay un nmero de mecanismos que permiten agregar
un grado de lgicas de procedimientos a los diagramas y que a la vez vienen bajo el encabezado de
fragmentos combinados. Un fragmento combinado es una o ms secuencias de procesos incluidas en
un marco y ejecutadas bajo circunstancias nombradas especficas. Los fragmentos disponibles son:
 El fragmento Alternative (denotedo alt) modela estructuras ifthenelse.

El fragmento Option (denotado opt) modela estructuras switch.

El fragmento Break modela una secuencia alternativa de eventos que se procesa en lugar de
todo del resto del diagrama.

El fragmento Parallel (denotado par) modela procesos concurrentes.

El fragmento de secuenciado Weak (denotado seq) incluye un nmero de secuencias para

las cuales todos los mensajes se deben procesar en un segmento anterior, antes de que el
siguiente segmento pueda comenzar, pero que no impone ningn secuenciado en los
mensajes que no comparten una lnea de vida.

El fragmento de secuenciado Strict (denotado strict) incluye una serie de mensajes que se
deben procesar en el orden proporcionado.

El fragmento Negative (denotado neg) incluye una serie de mensajes invlidos.

El fragmento Critical incluye una seccin crtica.

El fragmento Ignore declara un mensaje o mensajes que no son de ningn inters si este
aparece en el contexto actual.

El fragmento Consider es el opuesto del fragmento Ignore: cualquier mensaje que no se

incluya en el fragmento Consider se debera ignorar.

El fragmento Assertion (denotado assert) designa que cualquier secuencia que no se

muestra como un operando de la asercin es invlida.

El fragmento Loop incluye una serie de mensajes que estn repetidos.

El siguiente diagrama muestra un fragmento loop.

Tambin hay una ocurrencia de interaccin, que es similar a un fragmento combinado. Una ocurrencia
de interaccin es una referencia a otro diagrama que tiene la palabra ref en la esquina izquierda
arriba del marco, y tiene el nombre del diagrama referenciado que se muestra en el medio del marco

Puerta
Una puerta es un punto de conexin para conectar un mensaje dentro de un fragmento con un
mensaje fuera del fragmento. EA muestra una puerta como un cuadro pequeo en un marco del
fragmento.

Descomposicin en parte
Un objeto puede tener ms de una lnea de vida que viene de sta. Esto permite mensajes de entre e
intra objetos para que se muestren en el mismo diagrama.
DIAGRAMA DE ACTIVIDADES

Diagrama de Actividades
En UML un diagrama de actividades se usa para mostrar la secuencia de actividades. Los diagramas de
actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final detallando
muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad.
Estos tambin pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en la
ejecucin de algunas actividades. Los Diagramas de Actividades son tiles para el Modelado de
Negocios donde se usan para detallar el proceso involucrado en las actividades de negocio.

Un ejemplo de un diagrama de actividades se muestra a continuacin

Las siguientes secciones describen los elementos que constituyen un diagrama de actividades.

Actividades
Una actividad es la especificacin de una secuencia parametrizada de comportamiento. Una actividad
muestra un rectngulo con las puntas redondeadas adjuntando todas las acciones, flujos de control y
otros elementos que constituyen la actividad.

Acciones
Una accin representa un solo paso dentro de una actividad. Las acciones se denotan por rectngulos
con las puntas redondeadas.

Restricciones de Accin
Las restricciones se pueden adjuntar a una accin. El siguiente diagrama muestra una accin con pre y
post condiciones locales.
Flujo de Control
Un flujo de control muestra el flujo de control de una accin a otra. Su notacin es una lnea con una
punta de flecha.

Nodo Inicial
Un nodo inicial o de comienzo se describe por un gran punto negro, como se muestra a continuacin.

Nodo Final
Hay dos tipos de nodos finales: nodos finales de actividad y de flujo. El nodo final de actividad se
describe como un crculo con un punto dentro del mismo.

El nodo final de flujo se describe como un crculo con una cruz dentro del mismo.
La diferencia entre los dos tipos de nodos es que el nodo final del flujo denota el final de un solo flujo
de control, y el nodo final de actividad denota el final de todos los flujos finales dentro de la actividad.

Flujos de Objetos y Objeto

Un flujo de objeto es la ruta a lo largo de la cual pueden pasar objetos o datos. Un objeto se muestra
cmo un rectngulo.

Un flujo de objeto se muestra como un conector con una punta de flecha denotando la direccin a la
cual se est pasando el objeto.

Un flujo de objeto debe tener un objeto en por lo menos uno de sus extremos. Una notacin de acceso
rpido para el diagrama de arriba sera usar los pins de salidas y entradas.

Un almacn de clave se muestra como un objeto con las clave datastore.

Nodos de Decisin y Combinacin

Los nodos de decisin y combinacin tienen la misma notacin: una forma de diamante. Los dos se
pueden nombrar. Los flujos de control que provienen de un nodo de decisin tendrn condiciones de
guarda que permitirn el control para fluir si la condicin de guarda se realiza. El siguiente diagrama
muestra el uso de un nodo de decisin y un nodo de combinacin.
Nodos de Bifurcacin y Unin
Las bifurcaciones y uniones tienen la misma notacin: tanto una barra horizontal como vertical (la
orientacin depende de si el flujo de control va de derecha a izquierda o hacia abajo y arriba. Estos
indican el comienzo y final de hilos actuales de control. El siguiente diagrama muestra un ejemplo de
su uso.

Una unin es diferente de una combinacin ya que la unin sincroniza dos flujos de entrada y produce
un solo flujo de salida. El flujo de salida desde una unin no se puede ejecutar hasta que todos los
flujos se hayan recibido. Una combinacin pasa cualquier flujo de control directamente a travs de
esta. Si dos o ms flujos de entrada se reciben por un smbolo de combinacin, la accin a la que el
flujo de salida apunta se ejecuta dos o ms veces.

Regin de Expansin
Una regin de expansin es una regin de actividad estructurada que se ejecuta muchas veces. Los
nodos de expansin de salida y entrada se dibujan como un grupo de tres casillas representando una
seleccin mltiple de tems. La clave reiterativa, paralelo, o flujo se muestra en la esquina izquierda
arriba de la regin.
Gestores de Excepcin
Los gestores de Excepcin se pueden modelar en diagramas de actividad como en siguiente ejemplo.

Regin de Actividad Interrumpible

Una regin de actividad interrumpible rodea un grupo de acciones que se pueden interrumpir. En un
ejemplo simple como el siguiente, la accin Procesar Orden se ejecutar hasta su cumplimiento
cuando pase control a la accin Cerrar Orden, a menos que una interrupcin Cancelar Pedido se
reciba, la cual pasar el control a la accin Cancelar Orden.

Particin
Una particin de una actividad se muestra como calles horizontales o verticales. En el siguiente
diagrama, las particiones se usan para separar acciones dentro de una actividad en aquellas realizadas
por el departamento de contabilidad y aquellas realizadas por el cliente.
DIAGRAMA DE COLABORACION

Un diagrama de colaboracin sirve para describir un determinado escenario de

un caso de uso al mostrar la interaccin entre el conjunto de objetos que
cooperan en la realizacin de dicho escenario.

Suele ser conveniente especificar en la parte izquierda del diagrama, el caso

de uso que se est representando para que resulte ms sencilla su validacin.

Los diagramas de colaboracin conforman, junto con los diagramas de

secuencia, los diagramas de interaccin para modelar el comportamiento
dinmico de un sistema haciendo nfasis en la secuencia de los mensajes
intercambiados por un conjunto de objetos para un caso de uso en particular.

Tanto los diagramas de colaboracin como los diagramas de secuencia

muestran la misma informacin pero destacando un aspecto particular. Los
diagramas de secuencia muestran de forma explcita la secuencia de los
mensajes intercambiados por los objetos, mientras que los diagramas de
colaboracin muestran de forma ms clara cmo colaboran los objetos, es
decir, con qu otros objetos tiene vnculos o intercambia mensajes un
determinado objeto.

Un diagrama de colaboracin es una descripcin de una coleccin de objetos

que interactan para implementar un cierto comportamiento dentro de un
contexto. Sirve para describir 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 estructural es similar a una vista esttica: contiene
un conjunto de roles y relaciones que definen el contexto para su
comportamiento. El aspecto de comportamiento es el conjunto de mensajes
intercambiados por los objetos ligados a los roles. Al conjunto de mensajes
intercambiados pro los objetos en una colaboracin se llaman 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 comunicacin 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 sincrona 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.

Un diagrama de colaboracin es una forma de representar interaccin entre

objetos, alterna al diagrama de secuencia. A diferencia de los diagramas de
secuencia, pueden mostrar el contexto de la operacin (cules objetos son
atributos, cules temporales) y ciclos en la ejecucin. En general, un diagrama
de colaboracin se centra en estudiar todos los efectos de un objeto dado para
un caso de uso hoja.

Los diagramas de secuencia proporcionan una forma de ver el escenario en un

orden temporal - qu pasa primero, qu pasa despus. Los usuarios entienden
fcilmente este tipo de diagramas, por lo que resultan tiles en las primeras
fases de anlisis. Contrariamente, los diagramas de colaboracin proporcionan
la representacin principal de un caso de uso hoja, ya que las colaboraciones
se organizan entorno a los enlaces de unos objetos con otros. Este tipo de
diagramas se utilizan ms frecuentemente en la fase de diseo, es decir,
cuando estamos diseando la implementacin de las relaciones. Se toma como
ejemplo el caso de uso PedirProducto.

A diferencia de otras notaciones que muestran tanto el estado y el

comportamiento de la clase en el diagrama de clases, UML separa el
comportamiento de las clases en los diagramas de colaboracin. Los diagramas
de clase de UML no incluyen flujo de mensajes entre clases, es por esto que los
diagramas de colaboracin se deben crear en paralelo con los diagramas de
clases. Aunque se puede indicar el orden del flujo de mensajes en un diagrama
de colaboracin numerando los mensajes, no se suele hacer, ya que para este
propsito son mejores los diagramas de secuencia.

Los objetos se conectan por medio de enlaces, cada enlace representa una
instancia de una asociacin entre las clases implicadas. El enlace muestra los
mensajes enviados entre los objetos, el tipo de mensaje (sincrnico,
asincrnico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con
respecto a los otros.

Los elementos que conforman un diagrama de colaboracin son:

Instancias

Las instancias representan un objeto o instancia cualquiera de una clase

determinada (no a una instancia real).

Una instancia u objeto se ilustra con un rectngulo, que contiene el nombre y

la clase del objeto en un formato nombreObjeto: nombreClase.

Enlaces

Los enlaces representan una conexin entre instancias que indican

navegabilidad y visibilidad entre ellas. Establece una relacin cliente-servidor
entre las instancias.

Mensajes

Los mensajes se representan mediante una flecha etiquetada. Un mensaje

esta asociado a un enlace y para el caso de los diagramas de colaboracin
tienen asociados un nmero que indican el orden de ocurrencia.
En general, la sintaxis para mostrar los mensajes son:

[retorno :=] mensaje([parmetro [:tipoDatos]] [:tipoRetorno]

Donde,
retorno: indica el resultado de la operacin (opcional)
mensaje: indica el mensaje enviada u operacin invocada
parmetro: indica los argumentos usados para el mensaje
tipoDatos: indica el tipo de datos de cada parmetro (opcional)
tipoRetorno: indica el tipo de retorno de la operacin (opcional)

Un mensaje se ilustra mediante una flecha y existen los siguientes tipos:

Llamada a procedimiento u otra forma de llamada con

anidamiento de control. La secuencia anidada termina antes
de que siga la operacin que invoc. Puede usarse para
procesos concurrentes cuando el mensaje es sncrono.

Comunicacin asncrona, sin anidamiento de control. El

objeto que enva no se detiene a esperar respuesta.

Retorno de una llamada a procedimiento. Esta flecha puede

omitirse si queda claro por el fin de la activacin.

Parmetros

Los parmetros se muestran entre parntesis a la derecha del nombre del

mensaje. Opcionalmente se puede mostrar adems su tipo de datos.

Tipo de retorno

El valor de retorno es opcional y puede ser mostrado a la izquierda del mensaje

separndolo con un dos punto seguido de un igual (:=).

Iteraccin

Las iteracciones se indican mediante un asterisco (*) a continuacin del

nmero de secuencia del mensaje indicando que el mensaje es enviado en
forma repetida (en forma de ciclo) al receptor.
 Creacin de instancias

La creacin de una instancia se ilustra mediante el envio de un mensaje

create que puede incluir o no parmetros. Lo usual es especificar un nombre
para la instancia con el fn de usarla luego.

Destruccin de instancias

La destruccin de instancias se ilustra mediante el envio de un mensaje

delete que puede incluir o no parmetros.

Nmeros de secuencia

Los nmeros de secuencia determinan el orden de ocurrencia de los mensajes.

El mensaje que inicia la interaccin generalmente no es numerado.

Mensajes condicionales

Un mensaje es enviado nicamente si el mensaje se cumple. La guarda se

muestra en parntesis rectos ([ ]) a la izquierda del mensaje.

DIAGRAMA DE COMPONENTES

En Visual Studio, un diagrama de componentes muestra los elementos de un

diseo de un sistema de software. Un diagrama de componentes permite
visualizar la estructura de alto nivel del sistema y el comportamiento del
servicio que estos componentes proporcionan y usan a travs de interfaces.
Para crear un diagrama de componentes UML, en el men Arquitectura, haga
clic en Nuevo diagrama UML o de capas.
Para ver qu versiones de Visual Studio admiten esta caracterstica, vea
Compatibilidad de versiones con las herramientas de arquitectura y modelado.
Puede usar un diagrama de componentes para describir un diseo que est
implementado en cualquier idioma o estilo. Solo es necesario identificar los
elementos del diseo que interactan con las otros elementos del diseo a
travs de un conjunto restringido de entradas y salidas. Los componentes
pueden ser de cualquier escala y pueden estar interconectados de cualquier
manera.
Para obtener ms informacin acerca de cmo se usan los diagramas de
componentes en el proceso de diseo, vea Modelar la arquitectura de la
aplicacin.
Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado
de Modelado.
Un diagrama de componentes representa cmo un sistema de software es
dividido en componentes y muestra las dependencias entre estos
componentes. Los componentes fsicos incluyen archivos,
cabeceras, bibliotecas compartidas, mdulos, ejecutables, o paquetes. Los
diagramas de Componentes prevalecen en el campo de la arquitectura de
software pero pueden ser usados para modelar y documentar cualquier
arquitectura de sistema.
Debido a que los diagramas de componentes son ms parecidos a los
diagramas de casos de usos, stos son utilizados para modelar la vista esttica
y dinmica de un sistema. Muestra la organizacin y las dependencias entre un
conjunto de componentes. No es necesario que un diagrama incluya todos los
componentes del sistema, normalmente se realizan por partes. Cada diagrama
describe un apartado del sistema.
En l se situarn libreras, tablas, archivos, ejecutables y documentos que
formen parte del sistema.
Uno de los usos principales es que puede servir para ver qu componentes
pueden compartirse entre sistemas o entre diferentes partes de un sistema.