¡Descarga Gestión de una Peluquería con SIPEL: Casos de Uso y UML - Prof. Reyes y más Ejercicios en PDF de Análisis y Diseño del Sistema solo en Docsity!
SIPEL: GESTIóN DE UNA PELUqUERÍA 23
Ejercicio 1
SIPEL: Gestión de una peluquería
Se desea desarrollar una aplicación de gestión para una peluquería con la fina- lidad de llevar el mantenimiento de productos y clientes (SIPEL). Esta aplicación permitirá la gestión de productos, es decir, altas, bajas y modificaciones de productos, así como actualizar el stock de cada uno de ellos. Por otra parte, y respecto a los clientes, SIPEL permitirá dar de alta, baja y modificar clientes. El sistema también permite calcular el precio de los servicios que ha con- sumido el cliente en la peluquería (cortar el pelo, lavar el pelo, teñir el pelo, secar, etc.), permitiendo al peluquero/a indicar los productos consumidos (champú, crema suavizante, tinte, laca, etc.). En el momento de calcular dicho coste, el sistema modifica automáticamente la cantidad de los productos con- sumidos. Finalmente, si coincide que ese día es el cumpleaños del cliente, se le bonifica con un descuento del 20% sobre el precio total y se genera un aviso indicando esta situación. Habrá que comprobar si un producto está bajo-mínimos (es decir, si el stock del producto es inferior o igual a un stock mínimo admisible) en dos ocasiones: (a) cuando se calcula el precio del cliente, tras la modificación automática de la cantidad de cada producto consumido; (b) cuando se actua- liza el stock de los productos. Ambas comprobaciones marcarán aquellos pro- ductos que están bajo-mínimos , mostrando un aviso de que hay productos en esta situación. Otra de las funcionalidades de dicho sistema será permitir al peluquero/a obtener un listado de los productos bajo-mínimos , es decir, de aquellos pro- ductos marcados previamente como tal.
24 ESPECIFICANDO SOFTWARE MEDIANTE CASOS DE USO Y UML
Solución 1. SIPEL
En base a la información del enunciado, se puede deducir que este desarrollo será una aplicación de escritorio denominada SIPEL. a) Diagrama de casos de uso En cuanto a los actores, dado que no se especifica ni se intuye ninguna comuni- cación o conexión con otros sistemas, sólo existen actores humanos. Se asume que existe solo un actor: Peluquero/a, que es el actor iniciador. Aunque no se indica nada explícitamente en el enunciado, también podría ser razonable crear un actor Administrador, que hiciera las gestiones de productos y clientes, la actualización de stocks y la generación del listado bajo-mínim os. Se podría consultar con el cliente que nos encarga este desa- rrollo, si le interesa esta posibilidad. En principio asumimos la existencia de un solo actor y resolvemos el problema de esta manera. Los casos de uso asociados al actor Peluquero/a se van a presentar desde la perspectiva de productos y clientes. Con respecto a los productos, son los siguientes:
- Gestionar productos. Permite realizar las altas, las bajas y las modifica- ciones de los productos.
- Actualizar el stock. Permite cambiar (aumentar o disminuir) el número de unidades de los productos y generará un aviso cuando el stock del pro- ducto queda por debajo de un valor dado como mínimo ( bajo-mínimos ).
- Listar productos bajo-mínimos. Permite mostrar una lista de los produc- tos que previamente se hayan marcado bajo-mínimos. Los casos de uso con respecto a los clientes son los siguientes:
- Gestionar clientes. Permite realizar las altas, las bajas y las modifica- ciones de los clientes.
- Calcular el precio. Calcula el precio de los servicios y productos consu- midos por el cliente. Para cada producto consumido se modificará la can- tidad del mismo. Generará un aviso si el producto queda bajo-mínim os. Además, si es el día del cumpleaños del cliente, se le bonifica con un descuento del 20% sobre el precio total.
26 ESPECIFICANDO SOFTWARE MEDIANTE CASOS DE USO Y UML b) Flujo de eventos asociado al camino básico del caso de uso “Calcular el precio” Nombre del caso de uso: Calcular el precio Precondiciones : Que haya productos con stock. Descripción : Calcula el precio de los servicios y productos consumidos, modifi- cando el stock y generando un aviso si este queda bajo-mínimos. Si es el día del cumpleaños del cliente, se aplica un descuento del 20%. Camino básico ACTOR SISTEMA
- Seleccionar “Calcular el precio” 2. Mostrar la lista clientes ordenada alfabéticamente
- Seleccionar cliente 4. Mostrar la lista de servicios y productos
- Seleccionar servicios y productos consumidos 6. Modificar el stock de los productos consumidos 7. Comprobar si hay bajo-mínimos 8. Calcular el importe 9. Comprobar cumpleaños del cliente 10. Mostrar el importe total
- Aceptar y fin del caso de uso Caminos alternativos : Eventos 3 y 5. Cancelar. Evento 3. Si el cliente no existe, se puede dar de alta, siendo otro caso de uso. Evento 7. Si hay productos con stock bajo-mínimos , generar un aviso. Evento 9. Si es el cumpleaños del cliente, generar un aviso. Postcondiciones : Los stocks de los productos consumidos se habrán modificado. Debido al camino alternativo del evento 3 (dar de alta un cliente, si este no existe), se podría replantear el diagrama de casos de uso: en lugar de los casos de uso Gestionar clientes y Gestionar productos, lo que habrá serán casos de uso de Alta, Baja y Modificación de clientes y productos (ver Ilustración 2).
SIPEL: GESTIóN DE UNA PELUqUERÍA 27 Ilustración 2: Diagrama de casos de uso versión 2 de SIPEL
SIPEL: GESTIóN DE UNA PELUqUERÍA 29 d) Flujo de eventos asociado al camino alternativo del evento 9 del caso de uso “Calcular el precio” Nombre del caso de uso: Calcular el precio Precondiciones : Que haya productos con stock. Descripción : Si es el día del cumpleaños del cliente, se le bonifica con un des- cuento del 20% sobre el precio total. Camino alternativo evento 9 ACTOR SISTEMA
- Comprobar si es el cumpleaños del cliente
- Aplicar el 20% de descuento
- Mostrar aviso
- Aceptar 13. Volver al evento 10 del camino básico Caminos alternativos : No aplica. Postcondiciones: No aplica.
30 ESPECIFICANDO SOFTWARE MEDIANTE CASOS DE USO Y UML e) Diagrama de estados del caso de uso “Calcular el precio” Ilustración 3: Diagrama de estados del caso de uso “Calcular el precio” de SIPEL
32 ESPECIFICANDO SOFTWARE MEDIANTE CASOS DE USO Y UML
- En el caso de que el ticket no sea válido, el SCB devuelve el ticket, no levanta la barrera y muestra el mensaje “Pase por ventanilla. Ticket defectuoso o impagado”.
- Ningún usuario puede accionar el SCB si no dispone de ticket.
Solución 2. SCB
a) Diagrama de casos de uso El SCB es un sistema, es decir, tiene hardware y software. De hecho, según dice el propio enunciado, este sistema concreto consta de: (i) un pie con una pantalla y un lector de tarjetas de aparcamiento; (ii) una barrera para bloquear y desbloquear el paso de vehículos y (iii) un detector de salida del vehículo. Con respecto a los actores del SCB, ¿qué o quiénes van a interaccionar con el sistema? Con el pie con pantalla y lector de tarjetas va a interaccionar un Usuario del parking. Con la barrera y el detector de salida va a interaccio- nar un Vehículo. Con respecto a los casos de uso del SCB, ¿qué actores son iniciadores? Es decir, ¿qué actores inician el funcionamiento del sistema? En nuestro caso, el Usuario del parking es iniciador y el Vehículo es secundario. Para identificar los casos de uso hay que preguntarse, desde la perspectiva del actor iniciador, para qué utiliza ese actor el sistema: en nuestro caso, para Salir del parking. ¿Qué pasa con el actor secundario? El actor secundario tiene que estar asociado tam- bién al menos a un caso de uso porque sus acciones en el sistema afectan al fun- cionamiento, pero nunca lo ponen en marcha. En nuestro caso, el actor secunda- rio Vehículo está asociado también al caso de uso Salir del aparcamiento. Ilustración 4: Diagrama de casos de uso de SCB
SCB: SISTEMA DE ESTACIONAMIENTO SUBTERRáNEO 33 b) Flujo de eventos asociado al camino básico del caso de uso “Salir del aparcamiento” Aunque en la especificación no queda recogido, asumimos que en el camino básico de este caso de uso, cuando se indique “volver a la situación inicial”, significa que el sistema esté preparado y a la espera de que el usuario intro- duzca el ticket de aparcamiento. Para ello, el sistema mostrará el mensaje “Introduzca el ticket” al usuario del parking. Nombre del caso de uso: Salir del aparcamiento Precondiciones : El SCB estará inicialmente con la barrera bajada, mostrando por pantalla “Introduzca ticket”, a la espera de que el usuario introduzca el ticket. Descripción: Permite al usuario del parking salir del mismo tras introducir un tic- ket en el sistema. Cuando se detecta la salida del vehículo, el sistema bajará la barrera para volver a su situación inicial. Camino básico ACTOR: Usuario parking SISTEMA ACTOR: Vehículo
- Introducir ticket 2. Mostrar mensaje “Comprobando ticket”
- Chequear ticket
- Tragar ticket
- Levantar barrera
- Mostrar mensaje “Hasta pronto”
- Iniciar temporizador de 1 minuto
- Salir del parking
- Parar temporizador
- Bajar barrera
- Mostar mensaje “Introduzca ticket” y fin del caso de uso Caminos alternativos : Evento 8. Si el vehículo no sale del parking, se baja la barrera, el SCB devuelve el ticket y se muestra el mensaje “Recoja ticket”. Postcondiciones: No aplica.
SCB: SISTEMA DE ESTACIONAMIENTO SUBTERRáNEO 35 d) Diagrama de estados del caso de uso “Salir del aparcamiento” Ilustración 5: Diagrama de estados del caso de uso “Salir del aparcamiento” de SCB
