Ejercicio Propuesto

Descripción del problema: "El tacón de oro".

La zapatería Tacón de oro ha decidido crear un espacio web para ampliar su línea de negocio, así sus usuarios podrán adquirir los artículos: zapatos, bolsos y complementos que se venden en la tienda.

Los usuarios del sistema navegarán por la web para ver los artículos, zapatos, bolsos y complementos que se venden en la tienda. De los artículos nos interesa su nombre, descripción, material, color, precio y stock. De los zapatos nos interesa su número y el tipo. De los bolsos nos interesa su tipo (bandolera, mochila, fiesta). De los complementos (cinturones y guantes) su talla.

Los artículos se organizan por campañas para cada temporada (primavera/verano y otoño/invierno) de cada año.

Los artículos son de fabricación propia, pero, opcionalmente, pueden venderse artículos de otras firmas. De las firmas nos interesa saber su nombre, CIF y domicilio fiscal. La venta de artículos de firma se realiza a través de proveedores, de forma que un proveedor puede llevar varios artículos de diferentes firmas, y una firma puede ser suministrada por más de un proveedor. Los artículos pertenecen a una firma solamente. De los proveedores debemos conocer su nombre, CIF, y domicilio fiscal.

Los usuarios pueden registrarse en el sitio web para hacerse socios. Cuando un usuario se hace socio debe proporcionar los siguiente datos: nombre completo, correo electrónico y dirección.

Los socios pueden hacer pedidos de los artículos. Los usuarios pueden consultar todos los productos que tienen a su disposición, pero para realizar compras han de registrarse como socios.

Para comprar productos, se generan pedidos. Un pedido está formado por un conjunto de detalles de pedido que son parejas formadas por artículo y la cantidad. De los pedidos interesa saber la fecha en la que se realizó y cuanto debe pagar el socio en total. El pago se hace a través tarjeta bancaria, cuando se va a pagar una entidad bancaria comprueba la validez de la tarjeta. De la tarjeta interesa conocer el número.

Las campañas son gestionadas por el administrativo de la tienda que se encargará de dar de baja la campaña anterior y dar de alta la nueva siempre que no haya ningún pedido pendiente de cumplimentar.

Existe un empleado de almacén que revisa los pedidos a diario y los cumplimenta. Esto consiste en recopilar los artículos que aparecen en el pedido y empaquetarlos. Cuando el paquete está listo se pasa al almacén a la espera de ser repartido. Del reparto se encarga una empresa de transportes que tiene varias rutas preestablecidas. Según el destino del paquete (la dirección del socio) se asigna a una u otra ruta. De la empresa de transportes se debe conocer su nombre, CIF y domicilio fiscal. Las rutas tienen un área de influencia que determina los destinos, y unos días de reparto asignados. Se debe conocer la fecha en la que se reparte el pedido. Si se produce alguna incidencia durante el reparto de algún pedido se almacena la fecha en la que se ha producido y una descripción.

Los socios pueden visualizar sus pedidos y una vez comprobados, puede cancelarlos (siempre y cuando no hayan sido cumplimentados por el empleado de almacén) o confirmar la compra. Las compras deberán ser abonadas a través de una entidad bancaria. Así mismo los socios puede modificar sus datos personales.

Se pide:

Diagrama de casos de uso. Identifica los actores y casos de uso, incluye relaciones de asociación, identifica generalizaciones (de actores y de casos de uso). Si consideras alguna relación tipo include o extend, justifica su uso.
Del diagrama que hayas obtenido en el apartado anterior, agrupa todos los casos de uso que hayas considerado en el proceso de gestión de pedidos en uno sólo. Para este apartado, se entiende que el pedido ya ha sido dado de alta y que el proceso normal de un pedido es que termine siendo comprado. Desarrolla su notación escrita (tabla del caso de uso).

Retroalimentación

Los diagramas de casos de uso quedan encuadrados en la fase de análisis de los proyectos, se entienden como una puesta en común entre el cliente y el analista sobre como entender requisitos funcionales.

Al utilizarse UML, se entiende que ambos interlocutores conocen la notación propia de estos diagramas y las reglas sobre como combinar los diferentes símbolos, de forma que no hay ambigüedades que sí podrían darse mediante una descripción escrita.

Completar un diagrama de casos de uso supone versionar el diagrama tantas veces como sean necesarias hasta que la vista del proyecto que se presenta al cliente garantiza que el requisito funcional ha sido entendido.

En nuestros ejercicios, sólo hay una descripción que no permite ir refinando el diagrama mediante sucesivas consultas con el cliente, por lo tanto, las soluciones propuestas podrán ser diversas, todas ellas válidas siempre que reflejen razonablemente lo propuesto en el enunciado.

A la hora de valorar el ejercicio, lo que no es interpretable, es que el uso de la notación sea el correcto y que se muestre una variedad de los símbolos que conocemos para estos diagramas.

Con estas consideraciones, se propone la siguiente solución:

Actores que participan en el problema.

Zapatería (web), usuario (que podrá ser socio o no socio), productos/artículos (que podrán ser zapatos o complementos), y pedidos.

Generalizaciones.

Se observan dos posibles generalizaciones, que en el desarrollo del diagrama podrán ser expresadas en relación a actores o en relación a los casos de uso en los que participan. En la solución propuesta se ha decidido hacer una generalización de actores -- usuario socio o no socio -- y de casos de uso -- comprar zapatos o complementos (que podría haber sido una generalización de productos) --.

Relaciones extends.

De la ejecución del caso de uso visualizar pedido se pueden derivar los casos de uso cancelar pedido y comprar artículo. Se trata de casos de uso que no tienen porque siempre llevarse a cabo.

Relaciones includes/use.

Cuando se realiza la compra de un artículo, siempre habrá que pagarlo.

Notas:

Puesto que todos los usuarios pueden consultar la web de la zapatería, la relación consultar web la hace el actor usuario (padre de la relación de generalización), en cambio, generar pedido sólo puede llevarse a cabo por los socios, así que es éste el que participa en este caso de uso.
También podría haberse considerado el actor entidad bancaria, partícipe del caso de uso pagar.

Quedando el siguiente diagrama.

Actor de nombre Web Zapatería en forma de monigote, conectado con el caso de uso Consultar con forma de óvalo a través de una línea recta. Este a su vez está conectado al actor Usuario a través de una línea recta. A la derecha aparece otro actor llamado Usuario No Socio unido a Usuario por una flecha terminada en un triángulo blanco en Usuario. Debajo aparece otro actor llamado Socio unido a Usuario por una flecha terminada en un triángulo blanco en Usuario, que está asociado con los casos de uso Generar pedido y Visualizar pedido. Generar pedido está unido a los actores Productos y Pedidos con líneas rectas y a su vez, Visualizar pedido está unido con Pedido con una línea recta. Por otro lado, Visualizar Pedido está unido a través de flechas discontinuas sobre las que pone Extends con sentido hacia los casos de uso Cancelar Pedido y Comprar Artículo. Por último, Comprar Artículo está unido con una flecha discontinua sobre la que pone Includes con sentido al caso de uso Pagar y debajo de Comprar Artículo aparece dos casos de uso llamados Comprar Zapato y Comprar Complemento unidos a Comprar Artículo por una flecha terminada

Como se indicaba en los contenidos del apartado 2.2, lo más importante en la elaboración de un diagrama de casos de uso, no es el diagrama en sí, sino la documentación de los casos de uso que es lo que permitirá desarrollar otros diagramas que ayuden en la codificación del sistema, y la elaboración de los casos de prueba de caja negra.

A modo de ejemplo vamos a desarrollar la documentación del caso de uso Generar Pedido, ya que, por su complejidad abarca todos los apartados que hemos visto. El ejemplo se hará con la herramienta Visual Paradigm for UML, aunque tu puedes usar la herramienta que consideres más oportuna

Los datos que debemos incluir para elaborar la documentación del caso de uso eran:

Nombre: nombre del caso de uso.
Actores: aquellos que interactúan con el sistema a través del caso de uso.
Propósito: breve descripción de lo que se espera que haga.
Precondiciones: aquellas que deben cumplirse para que pueda llevarse a cabo el caso de uso.
Flujo normal: flujo normal de eventos que deben cumplirse para ejecutar el caso de uso exitosamente.
Flujo alternativo: flujo de eventos que se llevan a cabo cuando se producen casos inesperados o poco frecuentes. No se deben incluir aquí errores como escribir un tipo de dato incorrecto o la omisión de un parámetro necesario.
Postcondiciones: las que se cumplen una vez que se ha realizado el caso de uso.

Para incluir el nombre, actores, propósito, precondiciones y postcondiciones abrimos la especificación del caso de uso. Esto da lugar a la aparición de una ventana con un conjunto de pestañas que podemos rellenar:

En la pestaña "General" rellenamos el nombre "Hacer pedido", y tenemos un espacio para escribir una breve descripción del caso de uso, por ejemplo:
"El cliente visualiza los productos que están a la venta, que se pueden seleccionar para añadirlos al pedido. Puede añadir tantos artículos como desee, cada artículo añadido modifica el total a pagar según su precio y la cantidad seleccionada.

Cuando el cliente ha rellenado todos los productos que quiere comprar debe formalizar el pedido.

En caso de que el cliente no sea socio de la empresa antes de formalizar la compra se le indica que puede hacerse socio, si el cliente acepta se abre el formulario de alta, en caso contrario se cancela el pedido.

En caso de que se produzca algún problema con los datos bancarios se ofrecerá la posibilidad se volver a introducirlos.

Al finalizar un pedido se añade al sistema con el estado pendiente."
En la pestaña "Valores etiquetados" encontramos un conjunto de campos predefinidos, entre los que se encuentran el autor, precondiciones y postcondiciones, que podemos rellenar de la siguiente manera:
Autor: usuario.

Precondiciones: Existe una campaña abierta con productos de la temporada actual a la venta.

Postcondiciones: Se ha añadido un pedido con un conjunto de productos para servir con el estado "pendiente" que deberá ser revisado.

También se pueden incluir otros datos como la complejidad, el estado de realización del caso de uso la complejidad que no hemos visto en esta unidad.

Para incluir el resto de los datos en el caso de uso hacemos clic en la opción "Open Use Case Details..." del menú contextual, lo que da lugar a la aparición de una ventana con una serie de pestañas. En ellas se recupera la información de la especificación que hemos rellenado antes, además, podemos rellenar el flujo de eventos del caso de uso, en condiciones normales usaríamos la pestaña "Flow of events", sin embargo como esta opción solo está disponible en la versión profesional, utilizaremos la pestaña "Descripción", que está disponible en la versión community. Para activarla pulsamos el botón "Create/Open Description".

Podemos añadir varias descripciones de diferentes tipos, pulsando el botón "Nuevo". Para añadir filas al flujo de eventos pinchamos en el botón. En principio añadimos la descripción principal, luego añadiremos otras alternativas.

Tabla gestionar pedido.

Una vez adaptado el diagrama para obtener el caso de uso gestionar pedidos, podría quedar como sigue:

Actor de nombre Web Zapatería en forma de monigote, conectado con el caso de uso Consultar con forma de óvalo a través de una línea recta a su izquierda. Este a su vez está conectado al actor Usuario a través de una línea recta a su izquierda también. A la derecha aparece otro actor llamado Usuario No Socio unido a Usuario por una flecha terminada en un triángulo blanco en Usuario. Debajo izquierda, en el centro del diagrama, aparece otro actor llamado Socio unido a Usuario por una flecha terminada en un triángulo blanco en Usuario, que está asociado con los casos de uso Generar pedido en un óvalo azul a su izquierda y Generar pedido en un óvalo blanco abajo a la derecha. Generar pedido blanco está unido a los actores Productos y Pedido con líneas rectas. Por otro lado, Generar pedido en un óvalo azul está unido a través de líneas rectas con el actor Pedido por debajo y con el actor inicial Web Zapatería por encima.

La tabla resultante sería:

Caso de uso	Gestionar pedidos.
Actores	Principal: usuario-socio. Secundarios: pedido, zapatería.
Propósito	Gestión de los pedidos ya dados de alta en el sistema.
Pre-condiciones	El pedido ha sido generado y está en modo activo. El usuario debe ser socio.
Flujo normal	El flujo normal finaliza con la compra del pedido.	Visualizado del pedido.
		Compra del pedido.
		Pago del pedido.
		Fin de flujo.
Flujos alternativos	Cancelación del pedido.	Visualizado del pedido.
		Cancelación del pedido. El pedido desaparece de la lista de pedidos activos.
		Fin de flujo.
	Imposibilidad de efectuar el pago.	Visualizado del pedido.
		Compra del pedido.
		Error en la operación de pago. La compra del pedido no se completa.
		Fin de flujo.
Post-condiciones	Las post-condiciones son estados en los que ha de quedar el sistema siempre, sea cual sea el flujo ejecutado (normal o alternativo). Para este enunciado no se identifica ninguna post-condición en particular.
Requerimientos trazados	Los que correspondan en el documento de requisitos. Recuerda que el tipo de requisitos que se consideran en los diagramas de casos de uso son siempre de tipo funcional.
Puntos de inclusión	Ninguno. Este diagrama no dispone de otros casos de uso con los que establecer estas relaciones.
Puntos de extensión	Ninguno. Este diagrama no dispone de otros casos de uso con los que establecer estas relaciones.

Esta es la descripción principal, en ella se describe el flujo normal de eventos que se producen cuando se ejecuta el caso de uso sin ningún problema.

Flujo de eventos normal para el caso de uso Hacer Pedido.
Use Case	Hacer pedido
Author	usuario
Date	26-ago-2011 13:56:56
Brief Description	EL usuario selecciona un conjunto de artículos, junto con la cantidad de los mismos, para crear el pedido. Cuando se formaliza se comprueba que el usuario sea socio. A continuación se comprueban los datos bancarios, se realiza el cobro y se crea el pedido.
Preconditions	Existe un catálogo de productos disponibles para pedir. El usuario está registrado. Los datos bancarios son correctos.
Post-conditions	Se crea un pedido con los datos del usuario que lo realiza y los artículos solicitados.
Flow of Events		Actor Input	System Response
	1	Inicia el pedido.
	2		Se crea un pedido en estado "en construcción".
	3	Selecciona un artículo.
	4	Selecciona una cantidad.
	5		Recupera la información del artículo para obtener el precio y modifica el precio total del pedido.
	6	El proceso se repite hasta completar la lista de artículos.
	7	Se acepta el pedido.
	8		Se comprueba si el usuario es socio, si no lo es se le muestra un aviso para que se registre en el sitio.
	9		Se comprueban los datos bancarios con una entidad externa.
	10		Se genera: calcula el total, sumando los gastos de envío.
	11		Se realiza el pago a través de la entidad externa.
	12		Se almacena la información del pedido con el estado "pendiente".

Añadimos un par de descripciones alternativas para indicar que hacer cuando el usuario no es socio y cuando los datos bancarios no son correctos:

Flujo alternativo para el caso de uso Hacer Pedido cuando el usuario no está registrado.
Author	usuario
Date	26-ago-2011 17:56:35
Brief Description	Cuando el usuario hace un pedido si no está registrado se abre la opción de registro para que se dé de alta.
Preconditions	El usuario no está registrado. Existe un catálogo de artículos para hacer pedido. Los datos bancarios son correctos.
Post-conditions	El usuario queda registrado. Se crea un pedido con los datos del usuario que lo realiza y los artículos solicitados.
Flow of Events		Actor Input	System Response
	1	Inicia el pedido.
	2		Se crea un pedido en estado "en construcción".
	3	Selecciona un artículo.
	4	Selecciona la cantidad.
	5		Recupera la información del artículo para obtener su precio y modifica el precio total a pagar por el pedido.
	6		Añade la información al pedido en creación.
	7	EL proceso se repite hasta completar la lista de artículos del pedido.
	8	Acepta el pedido.
	9		Se comprueba si el usuario es socio.
	10		Se invoca el registro de usuario.
	11		Se comprueban los datos bancarios con una entidad externa.
	12		Se genera: calcula el total, sumando los gastos de envío.
	13		Se realiza el pago a través de la entidad externa.
	14		El pedido queda almacenado con el estado "pendiente".

Flujo alternativo para hacer pedido cuando los datos bancarios no son correctos.
Author	usuario
Date	26-ago-2011 18:14:35
Brief Description	Una vez que se han seleccionado los artículos y se han introducido los datos del socio, al hacer la comprobación de los datos bancarios con la entidad externa se produce algún error, se da la posibilidad al usuario de modificar los datos o de cancelar el pedido.
Preconditions	Existe un catálogo de productos disponibles para pedir. El usuario está registrado. Los datos bancarios no son correctos.
Post-conditions	Se crea un pedido con los datos del usuario que lo realiza y los artículos solicitados.
Flow of Events		Actor Input	System Response
	1	Inicia el pedido.
	2		Se crea un pedido en estado "en construcción".
	3	Selecciona un artículo.
	4	Selecciona una cantidad.
	5		Recupera la información del artículo para obtener el precio y modifica el precio total del pedido.
	6	El proceso se repite hasta completar la lista de artículos.
	7	Se acepta el pedido.
	8	Acepta el pedido.
	9		Se comprueban los datos bancarios con una entidad externa, fallando la comprobación.
	10		Se solicitan los datos de nuevo.
	11	Introduce los datos de nuevo.
	12		Se repite el proceso hasta que se acepten los datos bancarios o se cancele la operación.
	13		Se genera: calcula el total, sumando los gastos de envío.
	14		Se realiza el pago a través de la entidad externa.
	15		Se almacena la información del pedido con el estado "pendiente".

El resto de casos se uso se documentan de forma similar hasta completar la descripción formal de la funcionalidad del sistema.

Debes conocer

La elaboración de casos de uso no es un proceso inmediato, en la siguiente presentación tienes la descripción de como elaborar el diagrama de casos de uso del sistema con el que estamos trabajando.

Revísalo con cuidado para comprender los conceptos que acabamos de ver.