Diagrama Colaboracion y Secuencia

RISTORANT
Presentado por:
Nicolás Cáceres Durango
Karen Marín Ángel
Víctor Santiago Morales
Docente:
Cristian Camilo Cuellar
Bogotá, agosto 22 de 2021
FACULTAD DE TÉCNICAS DE INGENIERÍA

Programa de Desarrollo de Software
Ingeniería de Software
Asignatura: 0553 Ingeniería de Software
RISTORANT
Tabla de Contenido
1. Especificación de Requerimientos de Usuario ............................................................. 3

1.1. Nombre del Proyecto................................................................................................. 3
1.2. Descripción del Proyecto.......................................................................................... 3
1.3. Alcance del Proyecto ................................................................................................ 3
1.4. Requerimientos de Usuario ...................................................................................... 4
1.4.1. Requerimiento 1 .................................................................................................... 4
1.4.2. Requerimiento 2 .................................................................................................... 4
1.4.3. Requerimiento 3 .................................................................................................... 4
1.4.4. Requerimiento 4 .................................................................................................... 4
1.4.5. Requerimiento 5 .................................................................................................... 4
1.4.6. Requerimiento 6 .................................................................................................... 4
1.4.7. Requerimiento 7 .................................................................................................... 4
1.4.8. Requerimiento 8 .................................................................................................... 4
1.4.9. Requerimiento 9 .................................................................................................... 4
1.4.10. Requerimiento 10 .................................................................................................. 4
1.4.11. Requerimiento 11 .................................................................................................. 4
1.4.12. Requerimiento 12 .................................................................................................. 5
1.4.13. Requerimiento 13 .................................................................................................. 5
1.4.14. Requerimiento 14 .................................................................................................. 5
1.4.15. Requerimiento 15 .................................................................................................. 5
1.4.16. Requerimiento 16 .................................................................................................. 5
1.4.17. Requerimiento 17 .................................................................................................. 5
1.4.18. Requerimiento 18 .................................................................................................. 5
1.4.19. Requerimiento 19 .................................................................................................. 5
1.4.20. Requerimiento 20 .................................................................................................. 5
2. Diagrama de Casos de Uso ............................................................................................. 6
3. Especificación de Casos de Uso .................................................................................... 7

3.1. Formato Especificación Caso de Uso 1 .................................................................. 7
Página i

3.4. Formato de Especificación Caso de Uso 4 ........................................................... 10
3.5. Formato de Especificación Caso de Uso 5 ........................................................... 11
3.6. Formato de Especificación de Caso de Uso 6 ...................................................... 12
3.10. Formato de Especificación de Casos de Uso 10 .................................................. 16
3.11. Formato de Especificación de Casos de Uso 12 .................................................. 17
4. Diagrama de Clases ....................................................................................................... 25
5. Diagrama de Secuencia ................................................................................................. 26
6. Diagrama de Colaboración ............................................................................................ 27
7. Diagrama de Estados ........................................................... Error! Bookmark not defined.
8. Diagrama de Actividad......................................................... Error! Bookmark not defined.
9. Contratos de Comportamiento del Sistema ...................... Error! Bookmark not defined.

9.1. Contratos de Comportamiento Clase 1 ....................... Error! Bookmark not defined.
Página ii
1. Especificación de Requerimientos de Usuario
1.1. Nombre del Proyecto

El software se va a llamar: Ristorant.
1.2. Descripción del Proyecto

Ristorant va a ser un software funcional para restaurantes el cual podrán usar tanto
empleados como clientes, esto con el fin de que los clientes puedan crear, editar y cancelar
reservas, además de pedir domicilios por medio de este; los empleados de los restaurantes
podrán ver estas reservas y podrán agendarlas para cumplir con los que el cliente quiere,
además de esto podrán visualizar cuando alguien haya hecho un pedido a domicilio para
poder prepararlo y despacharlo.
Otra de las funcionalidades del software va a ser que tanto los empleados del restaurante
como el encargado podrán llevar las cuentas referentes a todas las ventas del mes, el
programa les calculará los gastos y los ingresos para hacer un análisis de las ventas y los
costos del mes.
Cada usuario podrá crear una cuenta ya que los clientes tendrán funcionalidades diferentes a
los empleados.
Los empelados podrán, desde ahí cuadrar permisos como vacaciones y citas médicas, y el
encargado del restaurante podrá ver y aprobar o rechazar la solicitud de estos.
1.3. Alcance del Proyecto

El software está pensado para ser adquirido por dueños y/o gerentes de restaurantes que
quieran implementar un sistema de gestión de datos de clientes, ventas y costes, además de
tener una plataforma por la cual podrán organizar temas de permisos de los empleados, y
como punto aparte, podrán dar la posibilidad a los clientes de crear cuentas para hacer
reservas en el restaurante y pedir domicilios.
Página 3
1.4. Requerimientos de Usuario
1.4.1. Requerimiento 1
El software deberá ser fácil de usar.

El programa deberá ser compatible con los diferentes sistemas operativos.

Tanto clientes como empleados deben poder crear cuentas con usuario y clave para proteger
su información.
Los clientes deberás poder hacer reservas, editarlas y cancelarlas.

El software deberá poder mostrar a los clientes las fechas disponibles para las reservas.
El software debe agendar la fecha y hora de una reserva para un cliente si ésta está
disponible.
El programa permitirá a los clientes ver el menú.

El Cliente podrá hacer pedidos a domicilios en base al menú del restaurante.

El programa debe asegurar que no se filtrarán los datos de un restaurante a otro para evitar
la competencia desleal entre estos.
El software garantizará la seguridad de la información de cliente y empleados.

Por medio del programa los empleados del restaurante que tengas los permisos dados por
quien adquirió la licencia, podrán realizar análisis de costos e ingresos para sacar reportes
con respecto a las ventas y los gastos del mes y así poder gestionar mejor su negocio.
Página 4
El software servirá para adecuar y asignar los horarios de los empleados, y que estos les
sean visibles a ellos y a los gerentes o encargados del restaurante.
Por medio del software los empleados podrán solicitar permisos de vacaciones, días no
remunerados, y horas de ausencia justificada.
El programa le permitirá al encargado del restaurante o a quien tenga los permisos

pertinentes en sus cuentas, aprobar, modificar o rechazar permisos de los empleados.
Por medio del software los empleados podrán enviar los pedidos de los clientes que van al
restaurante a la cocina, para que así los cocineros puedan recibir las órdenes y mantener un
orden.
El programa llevará una base de datos con todas las ventas del restaurante, todos los
domicilios que se pidan y las reservas que se hagan.
El diseño de la plataforma debe ser moderno y minimalista para que sea del agrado de todos.
Toda la información que aparezca en el programa deber ser clara y concisa para evitar
errores o confusiones.
La plataforma deberá contar con un espacio para los clientes con cuentas en donde podrán
poner quejas, reclamos o sugerencias.
El software deberá contar con un espacio en cual los clientes se puedan comunicar con el
restaurante para cualquier tema de servicio al cliente.
El gerente o encargado del restaurante por medio del programa podrá eliminar cuentas de
usuario tanto de empleados como de clientes si así lo requiere.
Página 5
2. Diagrama de Casos de Uso
Crear reserva
Editar Reserva
Cancelar reserva
Pedir domicilio
Ver menú restaurante CLIENTE
Ver historial reservas
Ver historial pedidos
Crear queja, reclamo o sugerencia
Contacto (Ayuda)
Crear orden (Pedido)

MESERO/ Ver orden (Pedido)
CAJERO
Cancelar orden (Pedido)
Crear solicitud permiso

Editar solicitud permiso
Aprobar Solicitud permiso
Cancelar Solicitud permiso
COCINERO
Ver reservas (Historial)
Ver ventas (Historial)
Generar reportes
Crear cuenta
Iniciar sesión
Cerrar sesión
GERENTE
Ver quejas, reclamos o
sugerencias
Ver solicitudes de ayuda
Cancelar Usuario
Página 6
3. Especificación de Casos de Uso
3.1. Formato Especificación Caso de Uso 1

Proyecto Ristorant Fecha 22/08/2021
Código Caso de Uso 001 Nombre Caso de Uso Crear cuenta
Propósito:
Que el usuario pueda crear una cuenta y especificar el rol con el cual va a utilizarla.
Alcance:
Este uso esta pensado para todas aquellas personas que necesiten o quieran una cuenta.
ACTORES SIMPLE MEDIO COMPLEJO
Clientes X
Empleados X
Gerente/Admin X
COMPLEJIDAD DEL CASO DE USO BAJA X MEDIA ALTA
CASOS DE USO ASOCIADOS
Incluye a: Llenar datos personales, Especificar rol del usuario, Editar usuario
Extiende de:
Extendido por:
Precondiciones:
Postcondiciones:
Al finalizar el proceso, el sistema muestra el perfil del usuario con toda la información, si la información queda mal, que el
usuario pueda editarla de forma fácil
DATOS DE ENTRADA
NOMBRE TIPO VALIDACIONES
Datos personales Datos (String, Int, Boolen, Inserción de datos personales del usurario (nombres,
usuario varchar) apellidos, identificación, edad, dirección de entrega (Clientes))
Inserción del rol del usuario (cliente, cocinero, mesera, cajero,
Tipo de rol Rol (Boolean)
gerente/admin)
DATOS DE SALIDA
Datos (String, Int, Boolean,
Perfil usuario La pantalla muestra un perfil creado con toda la información
varchar)
FLUJO DE TRABAJO NORMAL
PASO USUARIO SISTEMA
1 Oprime “No tengo cuenta” Abre formulario para que el usuario llene los datos.
Le permite llenar los datos al usuario y le indica que campos
2 El usuario llena los datos
son obligatorios.
Al momento en que el usuario oprime “Crear cuenta” está
3 El usuario oprime “Crear cuenta” validando el envío de la información. Y el sistema luego abre
el perfil del usuario.
FLUJO DE TRABAJO ALTERNATIVO 1
Requerimientos Especiales:
El usuario debe ingresar la información del formulario de todos los campos que sean obligatorios.
Riesgos:
Que el sistema colapse, que el sistema no cree el usuario, que la información ingresada ya exista
Criterios de Aceptación:
Pantalla Propuesta:
FIRMAS
<Nombre> <Nombre> <Nombre>

ANALISTA CLIENTE REVISOR
Página 7

Código Caso de Uso 002 Nombre Caso de Uso Iniciar sesión
Propósito:
Que el usuario pueda ingresar al programa
Alcance:
Este uso está pensado para todas aquellas personas que necesiten o quieran una ingresas al programa.
Clientes X
Empleados X
Gerente/Admin X
Incluye a:
Extiende de: Crear usuario
Extendido por:
Precondiciones:
Para iniciar sesión, el sistema debe reconocer que ya haya sido creado un usuario, si no, el usuario deberá crear uno
primero
Postcondiciones:
Al iniciar sesión, el usuario podrá ver todas las opciones de uso que tiene el programa de acuerdo a su rol.
DATOS DE ENTRADA
Datos de inicio de El usuario deberá ingresar los datos de inicio de sesión
Datos (Varchar)
sesión (Correo o usuario y clave)
DATOS DE SALIDA
Inició sesión de forma Si el usuario inicio sesión de forma correcta o incorrecta, el
String
correcta/incorrecta software se lo hace saber
1 Oprime “Login” Abre formulario para el ingreso del usuario y de la clave
Le permite llenar los datos al usuario y le indica que campos
2 El usuario llena los datos de ingreso
son obligatorios.
Si el usuario llenó bien los datos, el sistema le permite el
3 ingreso, si no, el usuario deberá llenar la información de
nuevo.
Si el usuario no tiene cuenta deberá crear una,
1 El sistema crea el usuario.
siguiendo los pasos del CU 001 “Crear Cuenta”
El usuario debe ingresar la información para validar su cuenta.
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que la información creada sea incorrecta.
Pantalla Propuesta:
FIRMAS

Página 8

Código Caso de Uso 003 Nombre Caso de Uso Cerrar sesión
Propósito:
Que el usuario pueda cerrar su sesión
Alcance:
Este uso está pensado para los usuarios tipo clientes, Meser@/cajer@ o gerente que necesiten crear una reserva.
Clientes X
Empleados X
Gerente/Admin X
Incluye a:
Extiende de: Iniciar sesión
Extendido por:
Precondiciones:
Para iniciar sesión, el sistema debe reconocer que ya haya sido creado un usuario, si no, el usuario deberá crear uno
primero
Postcondiciones:
Al iniciar sesión, el usuario podrá ver todas las opciones de uso que tiene el programa de acuerdo a su rol.
DATOS DE ENTRADA
DATOS DE SALIDA
Cerro sesión de Si el usuario cerro sesión de forma exitosa, el software se lo
String
forma exitosa hace saber
1 Abre menú principal El sistema abre el menú desplegable del lado izquierdo
El sistema cierra sesión y muestra la pantalla principal para
2 Oprime “Cerrar sesión”
iniciar sesión o crear cuenta.
El usuario debe iniciar sesión validando sus
2 El sistema inicia sesión.
datos siguiendo el CU 002 “Iniciar sesión”
Que el usuario haya ingresado a su cuenta previamente.
Riesgos:
Que el sistema colapse, que el sistema no permita al usuario cerrar sesión.
Pantalla Propuesta:
FIRMAS

Página 9
3.4. Formato de Especificación Caso de Uso 4

Código Caso de Uso 004 Nombre Caso de Uso Crear reserva
Propósito:
Que el usuario pueda crear una reserva
Alcance:
Este uso está pensado para todas aquellas personas que necesiten o quieran una ingresas al programa.
Clientes X
Meser@/Cajer@ X
Gerente/Admin X
COMPLEJIDAD DEL CASO DE USO BAJA MEDIA X ALTA
Incluye a: Llenar datos reserva
Extendido por:
Precondiciones:
Para crear una reserva el usuario debe haber iniciado sesión y no puede ser un usuario tipo cocinero.
Postcondiciones:
Al terminar el proceso el sistema vuelve al inicio.
DATOS DE ENTRADA
Inserción de datos para la creación de la reserva (Fecha y
Datos (String, int, boolean,
Datos reserva hora, cantidad de personas, tipo de reserva, decoración,
varchar)
solicitudes especiales)
DATOS DE SALIDA
Creó reserva de Si el usuario creó reserva de forma correcta o incorrecta, el
String
forma correcta software se lo hace saber
1 Abre menú lateral El sistema despliega el menú principal oculto
El sistema despliega un menú de opciones para escoger
2 Oprime “Reservas”
(Crear, Editar, cancelar)
El software abre un formulario con datos para poder crear la
3 Elije “Crear”
reserva
El sistema crea la reserva, le deja saber al cliente que la creó
4 Oprime “Confirmar” y envía una confirmación automática al usuario por correo y
mensaje de texto.
El usuario debe haber ingresado a su cuenta que no debe ser de rol cocinero.
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema haya confirmado la creación de la reserva
pero no quede registrada, que no le llegue confirmación automática al cliente, que el sistema muestre disponibilidad en las
fechas din que la haya.
Pantalla Propuesta:
FIRMAS

Página 10
3.5. Formato de Especificación Caso de Uso 5

Código Caso de Uso 005 Nombre Caso de Uso Editar reserva
Propósito:
Que el usuario pueda editar una reserva que haya creado.
Alcance:
Este uso está pensado para todas aquellas personas que necesiten o quieran editar una reserva.
Clientes X
Meser@/Cajer@ X
Gerente/Admin X
Incluye a: Modificar datos reserva
Extiende de: Crear reserva
Extendido por:
Precondiciones:
Para que un usuario tipo cliente pueda editar una reserva, debe haber creado una previamente
Postcondiciones:
DATOS DE ENTRADA
Inserción de datos a modificar de la reserva (Fecha y hora,
Datos (String, int, boolean,
Datos reserva cantidad de personas, tipo de reserva, decoración, solicitudes
varchar)
especiales)
DATOS DE SALIDA
Edito la reserva de Si el usuario fue exitoso en cambiar la información de la
String
forma correcta reserva, el sistema se lo hace saber.
El sistema despliega un menú con las reservas que el usuario
3 Elije “Editar”
tenga activas
4 Elije la reserva a editar El sistema abre la reserva con toda la información
El sistema edita la información de la reserva, le deja saber al
El usuario edita la información que necesita y
5 cliente que la editó de forma correcta y envía una confirmación
luego oprime “Confirmar”
automática al usuario por correo y mensaje de texto.
Si el cliente no tiene reserva deberá seguir el
2
CU 4 “Crear reserva”
Si el usuario es tipo cliente, solo podrá editar la reserva si creó una anteriormente y si ésta está activa.
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no reconozca al reserva a editar, que el
usuario no reciba confirmación automática.
Pantalla Propuesta:
FIRMAS
Página 11

3.6. Formato de Especificación de Caso de Uso 6

Código Caso de Uso 006 Nombre Caso de Uso Cancelar reserva
Propósito:
Que el usuario pueda cancelar una reserva que haya creado.
Alcance:
Este uso está pensado para todas aquellas personas que necesiten o quieran cancelar una reserva.
Clientes X
Meser@/Cajer@ X
Gerente/Admin X
Incluye a:
Extendido por:
Precondiciones:
Para que un usuario tipo cliente pueda cancelar una reserva, debe haber creado una previamente
Postcondiciones:
DATOS DE ENTRADA
DATOS DE SALIDA
Confirmación El sistema le pregunta al cliente si está seguro que quiere
String
cancelación cancelar la reserva
canceló la reserva de Si el usuario fue exitoso en cancelar la reserva, el sistema se
String
forma exitosa lo hace saber.
El sistema despliega un menú con las reservas que el usuario
3 Elije “Cancelar”
tenga activas
4 Elije la reserva a cancelar El sistema le pregunta al cliente si quiere cancelar la reserva
El cancela la reserva, le confirma la cancelación al cliente y le
5 Oprime “Si”
envía una notificación automática al correo y al celular.
Si el cliente no tiene reserva deberá seguir el
2
CU 4 “Crear reserva”
Si el usuario es tipo cliente, solo podrá cancelar la reserva si creó una anteriormente y si ésta está activa.
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no reconozca a la reserva a editar, que el
usuario no reciba confirmación automática.
Página 12
Pantalla Propuesta:
FIRMAS


Código Caso de Uso 007 Nombre Caso de Uso Pedir domicilio
Propósito:
Que el usuario tipo cliente pueda pedir un domicilio.
Alcance:
Este uso está pensado para todas aquellos clientes que necesiten o quieran editar una reserva.
Clientes X
COMPLEJIDAD DEL CASO DE USO BAJA MEDIA ALTA X
Incluye a: ver menú, elegir comida, rastrear domicilio.
Extiende de: Iniciar Sesión
Extendido por:
Precondiciones:
Para que un usuario pueda pedir un domicilio, debe haber ingresado a su cuenta tipo cliente.
Postcondiciones:
Al terminar el proceso el sistema muestra un tracker del estado del domicilio.
DATOS DE ENTRADA
DATOS DE SALIDA
Confirmación Si el usuario creó pedido a domicilio de forma correcta el
Srting
creación domicilio sistema se lo hace saber
2 Oprime “Domiclios” El sistema despliega la carta del restaurante
El sistema va añadiendo al carrito las cosas que el cliente
3 Elije elemento de la carta
vaya seleccionando de la carta
4 Oprime el carrito El sistema muestra todo lo que el cliente seleccionó de la carta
El sistema muestra un resumen con los productos y el precio
5 Oprime “Ir a pagar”
final
El sistema muestra las opciones de pago (tarjeta, efectivo) y el
6 Elegir opción de pago
usuario las elije
El sistema procesa el pago en caso de que el método de pago
sea tarjeta y luego muestra una pantalla con el tracker del
7 Oprime “Pagar”
domicilio, que muestra en que estado está el pedido del
cliente.
Solamente podrá pedir domicilios el usuario tipo cliente.
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no despliegue la carta del restaurante, que
Página 13
no funcione el tracker.
Pantalla Propuesta:
FIRMAS


Código Caso de Uso 008 Nombre Caso de Uso Ayuda
Propósito:
Que el usuario tipo cliente pueda poner quejas, sugerencias, reclamos o pueda ponerse en contacto directamente con el
restaurante
Alcance:
Este uso está pensado para todos los usuarios tipo cliente que necesiten algún tipo de ayuda o que quieran contactarse con
el restaurante.
Clientes X
Incluye a: crear queja, reclamo, sugerencia, contacto
Extendido por:
Precondiciones:
Para que un usuario tipo cliente pueda cancelar una reserva, debe haber creado una previamente
Postcondiciones:
DATOS DE ENTRADA
El usuario podrá ingresar detalladamente en que necesita
Ayuda String
ayuda
DATOS DE SALIDA
Confirmación de
String El sistema le confirmará al cliente que un caso se creó
creación de caso
2 Oprime “Ayuda”
(Quejas, sugerencias, reclamos, seguimiento, contacto)
Si el cliente elige queja, sugerencia o reclamo, el sistema abre
un cuadro de texto donde el cliente podrá especificar en que
3 Elije la opción que desea
necesita ayuda. Si el cliente elige contacto, el sistema
desplegara los medios de contacto con el restaurante.
El sistema crea un caso y automáticamente le envía un correo
4 Oprime confirmar
y un mensaje de texto al cliente con los detalles
El usuario debe ser tipo cliente para utilizar la opción ayuda.
Página 14
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el cuadro de texto no funcione, que el caso se haya
creado pero no le llegue al buzón del gerente.
Pantalla Propuesta:
FIRMAS


Código Caso de Uso 009 Nombre Caso de Uso Crear orden
Propósito:
Que el usuario tipo meser@/cajer@, gerente/admin pueda crear una orden de preparación para los cocineros.
Alcance:
Este uso está pensado para ser usado por los empleados que no sean cocineros, para que puedan crear una orden que
llega a la cocina para facilitar el flujo de pedidos y preparación de la comida.
Meser@/Cajer@ X
Gerente/Admin X
Incluye a: Ingresar opciones de comida
Extendido por:
Precondiciones:
El usuario que va a crear una orden debe tener un rol de Meser@/cajer@ o gerente/admin.
Postcondiciones:
DATOS DE ENTRADA
Nombre pedido String Nombre de la persona que hace el pedido
Nombre meser@ String Nombre de la persona que tomó el pedido
Mesa Int Numero de mesa
Orden String Platos que eligió el usuario a la carta
DATOS DE SALIDA
El sistema arroja a los cocineros y a la meser@ los detalles
Confirma pedido String, int
de la orden y el número de pedido
2 Oprime “Ordenes”
(Crear, ver, cancelar)
El sistema despliega la carta para que el meser@ pueda
3 Elije “Crear” poner lo que el cliente pidió, más la información de la mesa y
del cliente
El sistema crea el pedido y lo envía a los cocineros de turno,
4 Oprime “confirmar” además despliega la información del pedido con el número de
orden.
Página 15

Solo podrán usar esta opción los usuarios que sean empleados pero no de tipo cocinero
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no despliegue la carta, que sistema confirme
la creación de la orden pero que esta no sea enviada a los cocineros de turno.
Pantalla Propuesta:
FIRMAS

3.10. Formato de Especificación de Casos de Uso 10

Código Caso de Uso 010 Nombre Caso de Uso Ver y editar orden
Propósito:
Que el usuario tipo empleado puedan ver y editar la orden
Alcance:
Este uso está pensado para los usuarios que sean empleados del restaurante para que puedan observar y editar la orden si
así se requiere.
Meser@/Cajer@ X
Gerente/Admin X
Cocinero X
Incluye a: ver y editar orden
Extiende de: Crear orden
Extendido por:
Precondiciones:
Para que un usuario tipo empleado pueda ver o editar una orden, esta orden ya debió ser creada anteriormente
Postcondiciones:
DATOS DE ENTRADA
Nombre pedido String Nombre de la persona que hace el pedido
Nombre meser@ String Nombre de la persona que tomó el pedido
Mesa Int Numero de mesa
Orden String Platos que eligió el usuario a la carta
DATOS DE SALIDA
Detalles de la orden String El sistema muestra los detalles de la orden
(Crear, Ver, Cancelar)
El sistema despliega los detalles de la orden que pueden ser
3 Elije “Ver”
modificado y guardados si así se requiere
Página 16

Si ls orden tiene que ser modificada, el usuario
2 deberá seguir pasos similares al CU 009 “Crear El sistema modifica los detalles de la orden
orden”
Solo usuarios de tipo empleado podrán ver o editar la orden.
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no reconozca la orden a editar, que los
detalles de la orden sean incorrecto o se crucen con los de otra orden.
Pantalla Propuesta:
FIRMAS


Código Caso de Uso 011 Nombre Caso de Uso Cancelar Orden
Propósito:
Que el usuario tipo empleado pueda cancelar una orden.
Alcance:
Este uso está pensado para todas aquellas personas con usuario de tipo empleado que necesiten cancelar una orden.
Cocinero X
Meser@/Cajer@ X
Gerente/Admin X
Incluye a:
Extiende de: Crear orden
Extendido por:
Precondiciones:
Para que un usuario tipo empleado pueda cancelar una orden, ésta debe existir primero en el sistema.
Postcondiciones:
DATOS DE ENTRADA
DATOS DE SALIDA
Confirmación El sistema le pregunta al usuario si está seguro que quiere
String
cancelación cancelar la orden
canceló la orden de Si el usuario fue exitoso en cancelar la orden, el sistema se lo
String
forma exitosa hace saber.
(Crear, ver, cancelar)
3 Elije “Cancelar” El sistema despliega todas las ordenes activas
4 Elije la orden a cancelar El sistema le pregunta al usurario si quiere cancelar la orden
Página 17
5 Oprime “Si” El sistema cancela la orden

Si el cliente la orden no existe, el usuario deberá
2
seguir el CU 9 “Crear orden”
Solo los usuarios tipo empleado podrán cancelar la orden
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no reconozca a la orden a cancelar, que el
sistema no pueda cancelar la orden.
Pantalla Propuesta:
FIRMAS


Código Caso de Uso 012 Nombre Caso de Uso Crear solicitud de permiso
Propósito:
Que los usuarios tipo empleado puedan solicitar permisos de vacaciones o ausencias justificadas.
Alcance:
Este uso está pensado para todos los empleados del restaurando incluyendo al gerente para que puedan pedir permisos de
ausencia y acomodar sus horarios.
Cocinero X
Meser@/Cajer@ X
Gerente/Admin X
Incluye a:
Extendido por:
Precondiciones:
Postcondiciones:
DATOS DE ENTRADA
Se agenda la fecha de la solicitud dependiendo de la
Fecha del permiso Date
disponibilidad de horario
Justificación String Espacio para que el usuario pueda justificar la solicitud
DATOS DE SALIDA
Confirmación
String El sistema le confirma al usuario que la solicitud fue creada
creación de solicitud
2 Oprime “Solicitudes” El sistema despliega un menú de opciones para escoger
Página 18
(Crear, Editar, cancelar (y para gerentes o admin tienen la

opción de aprobar))
El sistema despliega un calendario que muestra la
3 Elije “Crear” disponibilidad de días en los que el usuario puede solicitar el
permiso
El sistema despliega un cuadro de texto para que el usuario
4 Elije la fecha y hora
pueda justificar la solicitud
El sistema crea la solicitud y le envía una confirmación al
5 Oprime “Confirmar”
usuario al correo o por mensaje de texto
Solo los usuarios tipo empleado pueden tener acceso a este uso en el programa
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no despliegue las fechas, que el sistema no
tenga la información de disponibilidad actualizada.
Pantalla Propuesta:
FIRMAS


Código Caso de Uso 013 Nombre Caso de Uso Editar solicitud permiso
Propósito:
Que el usuario tipo empleado pueda editar la información de la solicitud de su permiso.
Alcance:
Este uso es para ser usado por empleados que necesitan editar la información de la solicitud de su permiso si éste no ha
sido aprobado o rechazado aun.
Cocinero X
Meser@/Cajer@ X
Gerente/Admin X
Incluye a:
Extiende de: Crear solicitud
Extendido por:
Precondiciones:
Para que un usuario tipo empleado pueda editar una solicitud, éste debe haber creado una previamente
Postcondiciones:
DATOS DE ENTRADA
Si el usuario quiere editar la fecha de solicitud puede hacer
Fecha Date
con el calendario
Justificación String Cuadro de texto donde justifica la solicitud
DATOS DE SALIDA
Página 19
Confirmación Si el usuario fue exitoso en modificar los datos de la solicitud,

String
modificación solicitud el sistema se lo hace saber
2 Oprime “Solicitudes” (Crear, Editar, cancelar (para gerente o admin tiene además la
a opción aprobar))
3 Elije “Editar” El sistema el calendario y el cuadro de texto para editar
El sistema le pregunta al usuario si esta seguro que quiere
4 Edita los datos
realizar los cambios
El sistema confirma la modificación de la solicitud y envía
5 Oprime “Si” automáticamente otra confirmación al correo o por mensaje de
texto al usuario
Si el usuario no ha creado una solicitud de
2 permiso, debe crear una siguiendo el caso de El sistema crea la solicitud
uso 12 “Crear solicitud de permiso”
Si el usuario es de tipo empleado debe haber creado una solicitud previamente para poder editarla
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no reconozca la solicitud, que el sistema no
despliegue la info para editar, que el sistema no procese los cambios.
Pantalla Propuesta:
FIRMAS


Código Caso de Uso 014 Nombre Caso de Uso Cancelar Solicitud
Propósito:
Que el usuario tipo empleado pueda cancelar una solicitud de permiso que hay creado anteriormente.
Alcance:
Este uso está pensado para todos lo empleados que desean cancelar una solicitud que creada por previamente sin que esta
haya sido aprobada o rechazada.
Cocinero X
Meser@/Cajer@ X
Gerente/Admin X
Incluye a:
Extendido por:
Precondiciones:
Para que un usuario tipo empleado pueda cancelar la reserva debe haber creado uno anteriormente
Postcondiciones:
Página 20

DATOS DE ENTRADA
DATOS DE SALIDA
String
cancelación cancelar la solicitud
canceló la reserva de Si el usuario fue exitoso en cancelar la solicitud, el sistema se
String
forma exitosa lo hace saber.
2 Oprime “Solicitudes”
El sistema despliega un menú con las solicitudes que el
3 Elije “Cancelar”
usuario tenga activas
4 Elije la solicitud a cancelar El sistema le pregunta al cliente si quiere cancelar la solicitud
El sistema cancela la solicitud, le confirma la cancelación al
5 Oprime “Si” cliente y le envía una notificación automática al correo y al
celular.
Si el cliente no tiene una solicitud deberá seguir
2 El sistema crea la solicitud
el CU 12 “Crear solicitud”
El empleado solo podrá cancelar una solicitud que haya creado anteriormente
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no reconozca al usuario como empleado,
que el sistema no encuentre la solicitud, que el sistema no quiera cancelar la solicitud
Pantalla Propuesta:
FIRMAS


Código Caso de Uso 015 Nombre Caso de Uso Aprobar solicitud
Propósito:
Que el usuario tipo gerente/admin puedan aprobar o rechazar las solicitudes de permiso de los empleados
Alcance:
Este uso está pensado para todos los empleados que tengas usuarios gerente/admin y que puedan aprobar las solicitudes
de permiso de lo sempleados
Gerente/Admin X
Incluye a:
Extiende de: Crear Solicitud
Página 21
Extendido por:
Precondiciones:
Para que un usuario gerente o admin puedan aprobar o rechazar una solicitud, ésta ya debe haber sido creada por un
empleado previamente
Postcondiciones:
DATOS DE ENTRADA
DATOS DE SALIDA
Confirmación El sistema le pregunta al cliente si está seguro aprobar o
String
Aprobación rechazar la solicitud
Aprobó o rechazó la
Si el usuario fue exitoso en aprobar o rechazar la solicitud, el
solicitud de forma String
sistema se lo hace saber.
exitosa
2 Oprime “Solicitud”
(Crear, Editar, cancelar, aprobar)
El sistema despliega un menú con las Solicitudes activas en el
3 Elije “Aprobar”
sistema
4 Elije la solicitud El sistema le pregunta al cliente si quiere aprobar o rechazar
5 Oprime la opción que prefiera El sistema confirma la aprobación o el rechazo de la solicitud
Solo los usuarios tipo admin y los usuarios tipo gerente pueden aprobar o rechazar estas solicitudes
Riesgos:
Que el sistema colapse, que el sistema no reconozca el rol del usuario, que el sistema no reconozca a la solicitud, que el
sistema no despliegue la solicitud.
Pantalla Propuesta:
FIRMAS

3.16. Formato de Especificación de Casos de uso 16

Código Caso de Uso 016 Nombre Caso de Uso Ver solicitudes de ayuda
Propósito:
Que el usuario tipo gerente o admin puedan ver la solicitudes de ayuda de los clientes además de las quejas sugerencias o
reclamos
Alcance:
Este uso está pensado para todos los usuarios que tengan los permisos puedan ver y responder a las dudas y reclamos que
tengan los usuarios tipo clientes.
Gerente/Admin X
Página 22

Incluye a:
Extiende de: Ayuda
Extendido por:
Precondiciones:
Para que un usuario pueda responder a una solicitud de ayuda, esta debe haber sido creada por un cliente anteriormente
Postcondiciones:
DATOS DE ENTRADA
El sistema le da un cuadro de texto al usuario para responder
Respuesta a solicitud String
a los clientes
DATOS DE SALIDA
El sistema despliega una bandeja de entrada con todas las
2 Oprime “Solicitudes de Ayuda”
solicitudes de ayuda, quejas, reclamos o sugerencias
El sistema abre la solicitud con todos los detalles con un
3 Elije la solicitud cuadro de texto en donde el usuario puede responderle al
cliente
Responde en el cuadro de texto y oprime El sistema envía la respuesta al correo del cliente o por
4
“confirmar” mensaje de texto
Solo los usuarios con rol gerente o admin pueden responder a las solicitudes de ayuda de los clientes
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no muestre las solicitudes, que el sistema no
envié la respuesta al cliente.
Pantalla Propuesta:
FIRMAS

Página 23

Código Caso de Uso 017 Nombre Caso de Uso Cancelar Usuario
Propósito:
Que el usuario con rol admin o gerente puedan eliminar o cancelar a un usuario
Alcance:
Este uso es exclusivo de gerentes y admin quienes pueden eliminar un usuario de la base de datos si así lo requieren
Gerente/Admin X
Incluye a:
Extiende de: Crear usuario
Extendido por:
Precondiciones:
Para que un usuario tipo pueda eliminar o cancelar otro usuario este debe existir primero en la base de datos
Postcondiciones:
DATOS DE ENTRADA
DATOS DE SALIDA
String
cancelación cancelar o eliminar al usuario
canceló al usuario de Si el usuario fue exitoso en cancelar o eliminar a otro usuario,
String
forma exitosa el sistema se lo hace saber.
El sistema despliega una base de datos con todos los usuarios
2 Oprime “Usuarios”
registrados en el sistema
El sistema le muestra la informacion de usuario un botón que
3 Elije usuario a eliminar
dice eliminar
4 Oprime “Eliminar” El sistema le pregunta al cliente si quiere eliminar al usuario
5 Oprime “Si” El sistema borra al usuario de la base datos.
Únicamente las personas con rol de gerentes o admin pueden realizar este proceso
Riesgos:
Que el sistema colapse, que el sistema no reconozca al usuario, que el sistema no muestre la base de datos, que la base de
datos no este actualizada.
Pantalla Propuesta:
FIRMAS

Página 24
4. Diagrama de Clases
Página 25
5. Diagrama de Secuencia
Página 26
6. Diagrama de Colaboración
Página 27

Diagrama Colaboracion y Secuencia

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diagrama Colaboracion y Secuencia

Cargado por

Copyright:

Formatos disponibles

RISTORANT

Bogotá, agosto 22 de 2021

FACULTAD DE TÉCNICAS DE INGENIERÍA

1. Especificación de Requerimientos de Usuario ............................................................. 3

2. Diagrama de Casos de Uso ............................................................................................. 6

3. Especificación de Casos de Uso .................................................................................... 7

3.3. Formato Especificación Caso de Uso 3 .................................................................. 9

4. Diagrama de Clases ....................................................................................................... 25

5. Diagrama de Secuencia ................................................................................................. 26

6. Diagrama de Colaboración ............................................................................................ 27

7. Diagrama de Estados ........................................................... Error! Bookmark not defined.

8. Diagrama de Actividad......................................................... Error! Bookmark not defined.

9. Contratos de Comportamiento del Sistema ...................... Error! Bookmark not defined.

1. Especificación de Requerimientos de Usuario

1.1. Nombre del Proyecto

1.2. Descripción del Proyecto

1.3. Alcance del Proyecto

1.4. Requerimientos de Usuario

El software deberá ser fácil de usar.

El programa deberá ser compatible con los diferentes sistemas operativos.

Los clientes deberás poder hacer reservas, editarlas y cancelarlas.

El programa permitirá a los clientes ver el menú.

El Cliente podrá hacer pedidos a domicilios en base al menú del restaurante.

El software garantizará la seguridad de la información de cliente y empleados.

El programa le permitirá al encargado del restaurante o a quien tenga los permisos

2. Diagrama de Casos de Uso

Crear orden (Pedido)

Crear solicitud permiso

3. Especificación de Casos de Uso

3.1. Formato Especificación Caso de Uso 1

<Nombre> <Nombre> <Nombre>

3.2. Formato Especificación Caso de Uso 2

<Nombre> <Nombre> <Nombre>

3.3. Formato Especificación Caso de Uso 3

<Nombre> <Nombre> <Nombre>

3.4. Formato de Especificación Caso de Uso 4

<Nombre> <Nombre> <Nombre>

3.5. Formato de Especificación Caso de Uso 5

<Nombre> <Nombre> <Nombre>

3.6. Formato de Especificación de Caso de Uso 6

<Nombre> <Nombre> <Nombre>

3.7. Formato de Especificación de Caso de Uso 7

<Nombre> <Nombre> <Nombre>

3.8. Formato de Especificación de Caso de Uso 8

<Nombre> <Nombre> <Nombre>

3.9. Formato de Especificación de Caso de Uso 9

Si el usuario no tiene cuenta deberá crear una,

<Nombre> <Nombre> <Nombre>

3.10. Formato de Especificación de Casos de Uso 10

Si el usuario no tiene cuenta deberá crear una,

<Nombre> <Nombre> <Nombre>

3.11. Formato de Especificación de Casos de Uso 11

5 Oprime “Si” El sistema cancela la orden

<Nombre> <Nombre> <Nombre>

3.12. Formato de Especificación de Casos de Uso 12

(Crear, Editar, cancelar (y para gerentes o admin tienen la

<Nombre> <Nombre> <Nombre>

3.13. Formato de Especificación de Casos de Uso 13

Confirmación Si el usuario fue exitoso en modificar los datos de la solicitud,

<Nombre> <Nombre> <Nombre>

3.14. Formato de Especificación de Casos de Uso 14

Al terminar el proceso el sistema vuelve al inicio.