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:

Calculate total cost

Get authorization

Change customer's account

[cost < $50]

[cost >= $50]

Select Courses Check Availability

Inform NotAvailable

Mail Professor

Confirm Registration

Calculate Bill

Bill Student

Student System Billing System

CancelRegistration

Register to Course

Student

Billing System

StudentStudent

Billing SystemBilling System

Request se rvice

Play

Collect order

Order[placed]

Order[delivered]

Take order

Deliver order

Fill order

Order[entered]

Order[filled]

StockroomSalesCustomer