Diagramas

UML

1. Diagramas de casos de uso
Con la ayuda de un diagrama de casos de uso, puede analizar y comunicar:
Los escenarios en los que el sistema o aplicacin interacta con personas, organizaciones o sistemas externos.
Los objetivos que el sistema o aplicacin contribuye a lograr.
El mbito del sistema.

Caractersticas:

En un diagrama de casos de uso no se muestran los casos de uso en detalle; solamente se resumen algunas de las
relaciones entre los casos de uso, los actores y los sistemas. En concreto, en el diagrama no se muestra el orden en que
se llevan a cabo los pasos para lograr los objetivos de cada caso de uso. Esos detalles pueden describirse en otros
diagramas(por ejemplo en los diagramas de secuencia y actividades) y documentos, que pueden vincularse a cada
caso de uso.
En las descripciones que se proporcionen de los casos de uso se usarn diversos trminos relacionados con el dominio
en el que trabaja el sistema, como Ventas, Men, Cliente, etc. Es importante definir de manera clara estos trminos y
sus relaciones y, para ello, puede resultar til un diagrama de clases de UML.
Los casos de uso solamente se usan para los requisitos funcionales de un sistema. Otros requisitos, como las reglas de
negocio, los requisitos de calidad del servicio y las restricciones de implementacin, deben representarse por
separado. La arquitectura y los detalles internos tambin deben describirse por separado. Los ejemplos que se usan
en este tema estn relacionados con un sitio web en el que los clientes pueden hacer pedidos de comida de
restaurantes locales.

Componentes bsicos de un caso de uso:

















Un actor (1) es una clase de persona, organizacin, dispositivo o componente de software externo que interacta con
el sistema. Los actores del ejemplo son cliente, restaurante, sensor de temperatura y titular de tarjeta de crdito.
Un caso de uso (2) representa las acciones que uno o varios de los actores realizan a fin de conseguir un objetivo
determinado. Los casos de uso del ejemplo son Pedir men, Actualizar men y Procesar pago.
En un diagrama de casos de uso, casos de uso estn asociados (3) a los actores que los realizan.
El sistema (4) es aquello que se est desarrollando. Puede ser un pequeo componente de software cuyos actores
simplemente son otros componentes de software; puede ser una aplicacin completa; o puede ser un gran conjunto de
aplicaciones distribuidas que se implementan en muchos equipos y dispositivos. Los subsistemas del ejemplo son
Sitio web de pedidos de men.
En un diagrama de casos de uso pueden mostrarse los casos de uso que el sistema o sus subsistemas admiten.

Nota: Se ha dejado fuera del sistema la entrega del men ya que es la entrega fsica platillos al comensal y no se prosesa a
travs de la herramienta.


Estructurar casos de uso


Es conveniente que intente describir el comportamiento del sistema con solo unos pocos casos de uso principales. En cada
caso de uso grande se define un objetivo principal que un actor logra, como comprar un producto o, desde el punto de vista del
proveedor, ofrecer productos para su venta.
Una vez que haya presentado estos objetivos con claridad, puede proporcionar ms detalles sobre cmo se consigue cada
objetivo y sobre las variaciones de los objetivos bsicos. Puede usar un diagrama de casos de uso para resumir las relaciones
entre los casos de uso principales y los casos de uso ms detallados.

Relacin de inclusin

Use la relacin Incluir para mostrar que en un caso de uso se describen algunos detalles de otro. En la ilustracin, Pedir un
men incluye Pagar, Elegir men y Elegir elemento del men. Cada uno de los casos de uso incluidos y ms detallados
constituye un paso que probablemente el actor o actores tendrn que llevar a cabo para conseguir el objetivo global del caso
de uso incluyente. La flecha debe apuntar al caso de uso incluido ms detallado.

Los casos de uso incluidos se pueden compartir. En el ejemplo, los casos de uso Pedir un men y Suscribirse a revistas
incluyen Pagar.

El objetivo y los escenarios de un caso de uso incluido deben tener sentido por s mismos, de modo que puedan incluirse en
casos de uso que se diseen posteriormente.

La descomposicin de los casos de uso en elementos incluyentes y elementos incluidos resulta til para lograr los siguientes
objetivos:
Estructurar las descripciones del caso de uso en diferentes niveles de detalle.
Evitar repetir escenarios compartidos en distintos casos de uso.

En el diagrama de casos de uso no aparece ninguna informacin sobre el orden en que deben realizarse los pasos ms
detallados, ni sobre si son siempre todos necesarios.

Si desea especificar con claridad el orden de los pasos, puede usar un artefacto (Diagram en Visual
Paradigm) para asociar un documento independiente al caso de uso incluyente. En el ejemplo siguiente, se
muestra un diagrama de actividades asociado al caso de uso Pedir un men. Si lo desea, tambin puede usar un
documento de texto que contenga una lista de pasos o una secuencia de capturas de pantalla.


Tenga en cuenta estas convenciones de nomenclatura cuando use un diagrama de actividades:
El nombre de la actividad global es el mismo que el caso de uso incluyente.
Las acciones del diagrama de actividades tienen los mismos nombres que los casos de uso incluidos.




























Relacin de generalizacin

Use una relacin de generalizacin para mostrar que un caso de uso especializado es un mecanismo especfico de lograr los
objetivos expresados por otro caso de uso general. La punta de flecha abierta debe apuntar al caso de uso ms general.

Por ejemplo, Pagar es una generalizacin de Pagar con tarjeta de crdito y Pagar en efectivo.

Los casos de uso especializados pueden ayudarle a representar mecanismos distintos a travs de los cuales el sistema puede
conseguir el mismo objetivo. Los casos de uso especializados heredan los objetivos y los actores del caso de uso general. El
caso de uso general no tiene que tener escenarios propios; en sus especializaciones se describen diferentes mecanismos para
conseguir los objetivos. (el caso especializado no tiene un proceso, sino que se describen en las especializaciones)


Relacin de extensin

Use un vnculo de extensin para mostrar que, en determinadas circunstancias, un caso de uso puede agregar funcionalidad a
otro caso de uso. La flecha debe apuntar al caso de uso principal extendido.

Por ejemplo, el caso de uso Iniciar sesin de un sitio web normal puede incluir Registrar nuevo usuario, pero solamente
cuando el usuario todava no tiene una cuenta.

El caso de uso de extensin representa los pasos del escenario que, de otro modo, formaran parte de los escenarios del caso
de uso principal. El escenario y el objetivo de la extensin siempre se interpretarn en el contexto del caso de uso principal y,
por tanto, no es necesario que resulten tiles por separado.

Descomponer las extensiones puede resultar til para describir estas situaciones:
Hay actores adicionales que solamente estn implicados en el caso de uso de extensin. Por ejemplo, es necesario que
un administrador apruebe el registro de un cliente en el sitio web.
Un subsistema independiente se ocupar del caso de uso de extensin.
Esta extensin tan solo estar disponible en versiones especficas del sistema. Puede mostrar cada versin como un
subsistema independiente en el diagrama de casos de uso.

Lmites de subsistema

Use un lmite de subsistema para mostrar qu casos de uso estn dentro del mbito del sistema.

Casos de uso fuera del mbito del sistema

Normalmente, resulta til incluir en el diagrama casos de uso que forman parte del negocio pero que no tienen relacin con el
sistema que se est desarrollando. Esto ayuda a los desarrolladores a entender el contexto de su trabajo. Por ejemplo,
Entregar men podra presentarse como un caso de uso en el que estn implicados los actores Restaurante y Cliente,
pero podra quedar fuera de la responsabilidad del sitio web de pedidos de mens.

Varios subsistemas

Puede crear diversos lmites de subsistema para representar el modo en que los distintos componentes del sistema se ocupan
de los diferentes casos de uso. Por ejemplo, Agregar valoracin del restaurante puede realizarse en un sitio web de foros
independiente. Recuerde que un diagrama de casos de uso debe ocuparse de aquello que es visible para el usuario.Si desea
describir la divisin interna del trabajo en el sistema, considere la posibilidad de usar un diagrama de componentes.

Versiones del sistema

Puede usar diferentes lmites de subsistema para mostrar distintas versiones del sistema. Por ejemplo, el caso de uso Pagar
podra estar incluido en la versin 2 del sitio web, pero no en la versin 1. Esto significa que el sistema ayuda a los clientes a
realizar sus pedidos. Sin embargo, los clientes tienen que pagar al restaurante directamente.
Use las relaciones de Dependencia para vincular subsistemas que representan variantes o versiones diferentes.

2.- Diagramas de Actividades

El diagrama de actividades es usado para describir un proceso de negocio o un algoritmo de software como un flujo de trabajo
a travs de una serie de acciones. Las personas, los componentes de software o los dispositivos pueden realizar estas acciones.

En un diagrama de actividades, puede mostrar el flujo de datos que se pasan entre las acciones. Sin embargo, un diagrama de
actividades no describe la estructura de los datos. Para ello, puede dibujar un diagrama de clases UML.

Flujo de control

Un diagrama de actividades describe un proceso de negocio o un algoritmo de software como una serie de acciones. Las
flechas de conector muestran cmo el control pasa secuencialmente de una accin a la siguiente. Normalmente, una accin
solo puede iniciar una vez completada la accin anterior.
La ilustracin siguiente es un ejemplo de cmo se puede mostrar una secuencia de acciones mediante acciones, conectores,
bifurcaciones y bucles. Cada elemento se explica con ms detalle en las secciones siguientes.
























Los diagramas de actividades usan las Acciones y los Conectores para describir el sistema o la aplicacin como una serie de
acciones de modo que el control fluya de manera secuencial de una accin a la siguiente.
Cree una Accin (1) para cada tarea importante realizada por un usuario, el sistema o ambos en colaboracin.
Asegrese de que el ttulo de cada accin indica claramente lo que suele hacer.
Vincule las acciones en secuencia con Conectores (2).
Cada accin finaliza antes de que comience la accin siguiente del flujo de control. Si desea describir acciones que se
superponen, use un Nodo de bifurcacin.
Use un Nodo de decisin (3) para indicar un punto donde el resultado de una decisin dicta el paso siguiente. Puede
dibujar tantas rutas de acceso de salida como desee.
Si usa el diagrama de actividades para definir parte de una aplicacin, debe definir las restricciones (4) para que
quede claro cundo se debe tomar cada ruta de acceso.
No siempre es necesario definir las restricciones. Por ejemplo, si usa el diagrama de actividades para describir un
proceso de negocio o un protocolo de interaccin, una bifurcacin define el intervalo de opciones disponibles para el
usuario o para los componentes que interactan.
Use un Nodo de combinacin (5) para unir dos o ms flujos alternativos que se bifurcan en un Nodo de decisin.
Use las bifurcaciones para describir bucles, tal como se muestra en el ejemplo.


Iniciar la actividad

Existen dos maneras de indicar los puntos de entrada en una actividad:
Initial Node
Cree un Nodo inicial (6) para indicar la primera accin de la actividad.
Este mtodo es muy til cuando se describe una actividad secundaria o cuando no es necesario indicar explcitamente
qu inicia la actividad. Por ejemplo, Pedir un men se inicia cuando un cliente tiene hambre.
Nodo de aceptacin de evento
Cree Nodos de aceptacin de evento, para indicar el inicio de un subproceso que responde a un evento determinado,
como una intervencin del usuario. No proporcione un flujo de entrada al nodo. Al omitir el flujo de entrada, se indica
que se iniciar un subproceso cada vez que se produzca el evento.
Este mtodo es muy til cuando se describe una respuesta a un evento externo concreto.

Finalizar la actividad

Use un Nodo de final de actividad (7) para indicar el fin de una actividad.
Cuando un subproceso de control alcanza un Nodo de final de actividad, finalizan todas las acciones simultneas de
la actividad y las actividades secundarias.
Puede usar ms de un nodo de final de actividad para reducir la cantidad de conectores adicionales.

Interrumpir la actividad

Para describir cmo se puede interrumpir el flujo normal de una actividad, por ejemplo, si el usuario decide cancelar el
proceso, puede crear un nodo de aceptacin de evento que escuche ese evento. Cree un flujo de control desde ese nodo hasta
un nodo de final de actividad (7).

Calles

A veces resulta til organizar las acciones de una actividad en reas que se corresponden con distintos objetos o roles de
negocio que realizan las acciones. Estas reas se organizan de manera convencional en columnas y se denominan calles.

Describir el flujo de datos

Describir el flujo de datos con nodos de objeto

La mayora de los flujos de control transportan datos. Por ejemplo, el flujo de salida de la accin "El cliente proporciona
detalles" lleva una referencia a la direccin de envo. Si desea describir esos datos en el diagrama, puede reemplazar un
conector con un nodo de objeto y dos conectores, tal como se muestra en la ilustracin siguiente.

Observe que los rectngulos redondeados, como Despachar mercanca, representan acciones en las que tiene lugar el
procesamiento. Los rectngulos cuadrados, como Direccin de envo, representan un flujo de objetos de una accin a otra.


Almacenar en bfer los datos de los nodos de objeto

Un nodo de objeto puede actuar como bfer de varios objetos. En la ilustracin siguiente, el flujo de control muestra que el
usuario puede recorrer el bucle [elegir ms] (1) muchas veces, mientras el nodo de objeto Elementos del men seleccionados
(2) acumula las selecciones del usuario. Por ltimo, cuando el usuario finaliza su seleccin, el control pasa a la accin
Confirmar pedido (3), que acepta la lista completa de selecciones del bfer Elementos de men seleccionados.

Describir el flujo de datos con terminales de entrada y salida

Use un Terminal de salida y un Terminal de entrada para describir por separado las salidas de una accin y las entradas en
otra.

Un conector entre dos terminales representa un flujo de objetos, al igual que los flujos de entrada y salida de un nodo de
objeto. Los objetos que fluyen entre los terminales conectados deben ser compatibles de alguna manera. La razn es que los
objetos generados por el terminal de salida pertenecen a un tipo derivado del tipo del terminal de entrada.

Describir actividades secundarias con acciones de llamada a comportamiento

Puede describir el comportamiento detallado de una accin usando un diagrama de actividades independiente. Un
comportamiento llamado es un diagrama de actividades que se representa en el diagrama de actividades principal mediante
una accin de llamada a comportamiento. Tambin puede usar la accin de llamada a comportamiento para describir el
comportamiento que se comparte entre las diferentes actividades, de modo que no tenga que dibujar varias veces la actividad
secundaria.

En la ilustracin siguiente, el diagrama 1 muestra una actividad que tiene una accin de llamada a comportamiento, mientras
que el diagrama 2 muestra el diagrama de actividad secundaria donde puede verse el comportamiento llamado.

Flujos simultneos

Puede usar el Nodo de bifurcacin y el Nodo de unin para describir dos o ms subprocesos de actividades que se pueden
ejecutar al mismo tiempo.

El efecto del Nodo de bifurcacin (1) consiste en dividir el subproceso de control en dos o ms subprocesos. Cuando finaliza
la accin anterior, pueden iniciarse todas las acciones del lado de salida de la bifurcacin.
Un Nodo de unin (2) rene los subprocesos simultneos. La accin que viene despus del Nodo de unin podra no iniciarse
hasta que se completen todas las acciones que dan lugar al Nodo de unin.


Describir seales y eventos

Puede mostrar un paso en un proceso que enva una seal como una accin de envo de seal de una actividad.
Por ejemplo, puede mostrar un paso que enva un pedido y, a continuacin, otro paso que debe recibir el pedido antes de
procesarlo.

Enviar una seal
Use una accin de envo de seal (3) para indicar que se enva una seal o un mensaje de algn tipo a otras actividades o
procesos. Use el nombre de la accin para indicar qu tipo de mensaje se enva.
El control pasa inmediatamente a la accin siguiente del flujo de control, si la hay.
No puede usar una accin de envo de seal para describir cmo responde el proceso a una informacin devuelta.Para
ello, use una accin de aceptacin de evento independiente.
Puede mostrar el flujo de datos entrante en una accin de envo de seal para indicar qu datos pueden enviarse con
el mensaje saliente.

Esperar una seal o evento
Use una accin de aceptacin de evento (4) para indicar que esta actividad espera algn evento externo o mensaje entrante.
Use el nombre de la accin para indicar el tipo de evento que espera.
Para mostrar que la actividad espera un mensaje o evento externo en un punto concreto de su flujo, dibuje una accin
de aceptacin de evento con un flujo de entrada (rectngulo bufer) en el lugar adecuado de la actividad.

Describir varios flujos de datos

Puede dibujar ms de un flujo de control o flujo de objeto saliendo de una accin para indicar que varios subprocesos emergen
cuando finaliza la accin. El efecto es similar al de una bifurcacin, salvo que se puede usar una combinacin de flujos de
control y objeto.
El ejemplo siguiente muestra varios flujos que entran y salen de acciones.

Cuando se completa la accin "El cliente proporciona detalles", se generan dos objetos: "Direccin de envo" y "Detalles de la
tarjeta de crdito". Los dos objetos avanzan en el procesamiento mediante acciones diferentes.
Dado que una accin requiere que todas sus entradas estn disponibles antes de iniciarse, la ltima accin no se inicia hasta
que se completen todas las acciones anteriores.

Secuencias

Puede usar un diagrama de actividades para describir una canalizacin o una serie de acciones que se ejecutan al mismo
tiempo y pasan datos continuamente de una accin a otra. La finalidad del ejemplo siguiente es que cada accin genere objetos
y siga funcionando. Dado que no hay flujos de control, cada accin se puede iniciar en cuanto recibe sus primero objetos.

Observe que los conectores de este ejemplo son flujos de objeto, ya que todos tienen al menos un extremo en un nodo de
parmetros de actividad, un nodo de objeto o un terminal de entrada o salida.

1. El ejemplo tiene tres nodos de parmetros de actividad, que representan sus entradas y salidas.
2. Los nodos de objeto, los terminales de entrada y los terminales de salida pueden representar bferes.
3. Puede usar los nodos de decisin para mostrar que una secuencia se divide y enva objetos diferentes por
bifurcaciones diferentes. Puede usar los comentarios o los ttulos de los nodos para explicar cul es el criterio de
divisin.
4. Puede usar los nodos de bifurcacin para mostrar que se realizan dos o ms copias de los objetos, que se envan para
el procesamiento simultneo.
5. Puede usar los nodos de unin para mostrar que dos secuencias de procesamiento se combinan en una sola.

Ejemplos:

Student
Register to Course

Student

System

Billing System
Select Course s

Billing System

Check Availability

Inform Not
Available
Confirm
Registration

Cancel
Registration

Mail Professor

Calculate
Bill
Bill Student

Calculate
total cost

[cost < $50]

[cost >= $50]

Get
authorization

Change customer's
account

Customer

Re que st se rvi ce

Sales

Stockroom

Order
[placed]

Take order

Order
[entered]

Play
Fill order

Order
[deliver ed]

Deliver order

Order
[filled]

Collect order