diagrama de casos de uso

11
1 UML – Diagrama de casos de uso Daniel Santiago Diagrama de casos de uso Introducción 2 Casos de uso 2 Actor 2 Escenario 2 Relación de comunicación 3 Diagrama de casos de uso 3 Relaciones entre los casos de uso: relación de inclusión 4 Relaciones entre los casos de uso: relación de extensión 4 Especialización y generalización de los casos de uso 5 Representación textual de los casos de uso 5

Upload: daniel-santiago-martinez

Post on 13-Jun-2015

5.661 views

Category:

Education


7 download

DESCRIPTION

Diagrama de casos de uso UML

TRANSCRIPT

Page 1: Diagrama de casos de uso

1

UML – Diagrama de casos de usoDaniel Santiago

Diagrama de casos de uso

Introducción 2

Casos de uso 2

Actor 2

Escenario 2

Relación de comunicación 3

Diagrama de casos de uso 3

Relaciones entre los casos de uso: relación de inclusión 4

Relaciones entre los casos de uso: relación de extensión 4

Especialización y generalización de los casos de uso 5

Representación textual de los casos de uso 5

Page 2: Diagrama de casos de uso

2

UML – Diagrama de casos de usoDaniel Santiago

Introducción

Los casos de uso se usan para describir los requisitos funcionales del sistema que se desea diseñar.

En los diagramas de casos de uso se muestran los requisitos funcionales deseados, los actores (usuarios del sistema) y las relaciones que unen a actores y funcionalidades.

Casos de uso

Los casos de uso describen en forma de acciones y reacciones el comportamiento del sistema, estudiado desde el punto de vista del usuario. Definen los límites del sistema y sus relaciones con el entorno.

Los casos de uso explicitan los requisitos funcionales del sistema relativos a uno de los objetivos del usuario. Éstos se denominan también, de manera más precisa, casos de uso con objetivo usuario.

Por ejemplo, en un sistema que gestione las mercancías de una tienda, la compra de un producto constituye un caso de uso.

Actor

Un usuario externo al sistema puede desempeñar diferentes funciones en relación con el sistema. Una pareja (usuario, función) constituye un actor específico designado en UML únicamente por el nombre de la función.

La definición se extiende a los demás sistemas que interactúan con el sistema. Éstos forman tantos actores como funciones desempeñadas.

Se diferencian dos categorías de actores:

Los actores primarios son los que inician el caso de uso. Los actores secundarios son los que participan en el caso de uso.

Por ejemplo, en el ejemplo de una tienda informática, el actor primario es el comprador, y un actor secundario podría ser un sistema que reconoce la validez de la tarjeta de crédito del comprador.

Escenario

Un escenario es una instancia de un caso de uso en la cual se fijan todas las condiciones relativas a los diferentes eventos.

A un caso de uso determinado corresponden varios escenarios.

Ejemplos de diferentes escenarios para el caso de uso “Llevarse libro” de una biblioteca serían:

Escenario 1: Pedro se lleva el ejemplar “Los pilares de la tierra”. Escenario 2: María intenta llevarse el ejemplar “Drácula” pero no puede ya que ha

superado el límite de 3 préstamos simultáneos.

Page 3: Diagrama de casos de uso

3

UML – Diagrama de casos de usoDaniel Santiago

Relación de comunicación

La relación que vincula a un actor con un caso de uso se denomina relación de comunicación. Esta relación da soporte a diferentes modelos de comunicación, por ejemplo:

Los servicios que el sistema debe suministrar a cada uno de los actores del caso de uso.

Las informaciones del sistema que un actor puede introducir, consultar o modificar. Los cambios que intervienen en el entorno, de los cuales un actor informa al sistema. Los cambios que intervienen dentro del sistema, de los cuales el sistema informa a un

actor.

Diagrama de casos de uso

El diagrama de casos de uso muestra los casos de uso representados en forma de elipses y a los actores en forma de personajes. También indica las relaciones de comunicación que los vincula.

El sistema que responde al caso de uso puede representarse mediante un rectángulo en cuyo interior aparece el caso.

Ejemplo:

Los actores secundarios se representan del mismo modo que los actores primarios. Muchas veces el sentido de la relación de comunicación entre los actores secundarios y el sistema se invierte con respecto al sentido de la relación entre los actores primarios y el sistema. En efecto, es el sistema y no el actor quien inicia la comunicación.

Page 4: Diagrama de casos de uso

4

UML – Diagrama de casos de usoDaniel Santiago

Relaciones entre los casos de uso: relación de inclusión

La relación de inclusión sirve para enriquecer un caso de uso con otro. El caso de uso incluido existe únicamente con ese propósito, ya que no responde a un objetivo de un actor primario. Estos casos de uso son subfunciones.

La inclusión sirve para compartir una funcionalidad común entre varios casos de uso. También puede emplearse para estructurar un caso de uso describiendo sus subfunciones.

En el diagrama de casos de uso estas relaciones se representan mediante una flecha discontinua acompañada del estereotipo <<include>>.

Varios casos de uso pueden tener una relación de inclusión con un caso de uso en común, ya que varios casos de uso pueden tener una misma subfunción.

Relaciones entre los casos de uso: relación de extensión

Al igual que la relación de inclusión, la relación de extensión enriquece un caso de uso mediante un caso de uso subfunción. El enriquecimiento es análogo al de la relación de inclusión, no obstante, es opcional.

Page 5: Diagrama de casos de uso

5

UML – Diagrama de casos de usoDaniel Santiago

Como ocurre con la inclusión, la extensión sirve para estructurar un caso de uso o para compartir un caso de uso de subfunción.

En el diagrama de casos de uso, esta relación se representa mediante una flecha discontinua acompañada del estereotipo <<extend>>.

Especialización y generalización de los casos de uso

Como vimos en el diagrama de clases, también es posible especializar un caso de uso en otro. Obtenemos así un subcaso de uso.

Al igual que ocurría con las clases, el subcaso hereda el comportamiento y las relaciones de comunicación, inclusión y extensión del supercaso de uso.

Muchas veces el supercaso de uso es abstracto, es decir, corresponde a un comportamiento parcial completado en el subcaso de uso.

En el diagrama de casos de uso la relación de especialización se representa mediante una flecha de especialización idéntica a la que une las subclases con las superclases. El nombre de los casos de uso abstractos se escribe en cursiva, o se acompaña del estereotipo <<abstract>>.

Los subcasos de uso tienen el mismo nivel que sus supercasos. Si el supercaso es una subfunción, el subcaso también lo será.

Page 6: Diagrama de casos de uso

6

UML – Diagrama de casos de usoDaniel Santiago

También puede existir especialización en los actores del sistema.

Representación textual de los casos de uso

La representación textual de los casos de uso no se especifica en UML, no obstante se utiliza habitualmente. Es una especificación en la que se usa el lenguaje natural del autor. Hay dos tipos de especificaciones: la de alto nivel y la expandida.

Page 7: Diagrama de casos de uso

7

UML – Diagrama de casos de usoDaniel Santiago

Representación de alto nivel

Se trata de realizar una descripción breve de las acciones del caso de uso. Esta representación tiene las siguientes partes:

Caso de uso: nombre del caso de uso. Actores: lista de actores, iniciador. Propósito: objetivo del caso de uso. Resumen: Descripción breve de las actividades que se deben llevar a cabo. Tipo: 1 – Primario, secundario, opcional

2 – Real o esencial.

Los tipos de caso de uso son los siguientes:

Primario: estos casos de uso representan los procesos comunes más importantes. Secundario: representan procesos menores o raros. Opcionales: representan procesos que pueden no abordarse. Real: describe concretamente el proceso a partir de su diseño concreto actual, sujeto a

las tecnologías específicas de entrada, salida, etc. Esencial: son casos expandidos que se expresan en forma teórica y que contiene poca

tecnología y pocos detalles de implementación. Las decisiones de diseño se posponen y se abstraen de la realidad. Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y abstracción.

Representación expandida

Se trata de realizar una descripción detallada de las acciones y los requisitos. Añade a la especificación de alto nivel las siguientes partes:

Referencias cruzadas: requisitos a los que hace referencia. Curso típico de acontecimientos: descripción detallada de la interacción (conversación)

entre los actores y el sistema. Descripción de los acontecimientos paso a paso. Cursos alternativos: describe excepciones al curso típico.

Ejemplo representación caso de uso

En este ejemplo vamos a especificar el software de un terminal de punto de venta (TPV). Es un sistema usado para registrar las ventas y gestionar pagos en supermercados y grandes almacenes.

Las funciones básicas del TPV serán las siguientes:

REF # FunciónR1.1 Registrar la venta actual – los productos comprados.R1.2 Calcular el total de la venta actual, incluyendo impuestos y cálculo de “puntos de

cliente”R1.3 Capturar la información de los productos comprados de un código de barras, usando

un scanner o bien a partir de la entrada manual del código de barras.R1.4 Descontar las cantidades vendidas del stock, cuando la venta de confirme.

Page 8: Diagrama de casos de uso

8

UML – Diagrama de casos de usoDaniel Santiago

R1.5 Guardar información sobre las ventas realizadas.R1.6 El cajero debe identificarse al iniciar una sesión con un identificador y una clave de

acceso.R1.7 Mostrar la descripción y el precio de cada producto comprado.R2.1 Tratar los pagos de efectivo capturando la cantidad entregada por el cliente y

calculando el cambio.R2.2 Tratar los pagos con tarjeta de crédito capturando el número de la tarjeta desde un

lector de tarjetas o manualmente, pedir confirmación del pago al servicio de autorización de crédito (externo) con una conexión vía módem.

R2.3 Registrar los pagos con tarjeta para que puedan ser facturados.

Vamos a especificar el caso de uso “Comprar productos”:

Caso de uso: Comprar productos

Actores: Cliente (iniciador), Cajero

Propósito: Capturar una venta y su pago en efectivo.

El cajero registra los productos y gestiona el pago en efectivo.

Al terminar, el cliente se va con los productos.

Tipo: primario y esencial.

Referencias cruzadas: R1.1, R1.2, R1.3, R1.7, R2.1

Curso típico de acontecimientos:

Acciones de los actores Respuesta del sistema

Page 9: Diagrama de casos de uso

9

UML – Diagrama de casos de usoDaniel Santiago

1. El caso de uso empieza cuando el cliente llega a la caja con sus productos para comprar.2. El cajero indica el inicio de una nueva venta.

3. Registro del inicio de una nueva venta del TPV.

4. El cajero registra el identificador de cada producto. Si hay más de una unidad del producto el cajero puede introducir la cantidad.

5. Determina el precio del producto y añade su información a la cuenta.

6. Al terminar la entrada de productos el cajero lo indica.

7. Calcula y muestra el total de la cuenta.

8. El cajero le dice el total al cliente.9. El cajero entrega una cantidad de dinero posiblemente más grande que el total de la cuenta.10. El cajero indica el dinero que ha recibido. 11. Calcula y muestra el cambio al cliente.

Imprime un recibo.13. El cajero deposita el dinero recibido en la caja y extrae el cambio. El cajero da el cambio y el recibo al cliente.

12. Registra la venta que se acaba de hacer.

14. El cliente se va con los productos comprados.

Cursos alternativos:

Línea 4: se introduce un identificador de producto inexistente. Indicar error. Línea 9: el cliente no tiene suficiente dinero. Cancelar la venta.