Sistema distribuido para administración de restaurantes

Texto completo

(1)Sistema Distribuido para Administración de Restaurantes. Juan Felipe Caro. Trabajo de grado para optar el título de Ingeniero de Sistemas y Computación. Asesor Juan Pablo Quiroga Magister en Ingeniería de Sistemas y Computación Profesor Instructor. Universidad de los Andes Ingeniería de Sistemas y Computación. 2001.

(2) Sistema Distribuido para Administración de Restaurantes Índice general CAPÍTULO 1. INTRODUCCIÓN ...................................................................1 1.1. OBJETIVOS........................................................................................................................ 1 1.2. CONTENIDO ...................................................................................................................... 2 CAPÍTULO 2. REVISIÓN BREVE DEL FUNCIONAMIENTO DE UN RESTAURANTE...........................................................................................3 2.1. INTRODUCCIÓN.................................................................................................................. 3 2.2. ESTADO ACTUAL DE COMPOSTELA BAR LTDA. .................................................................... 3 2.3. EL PROCESO DE LAS ÓRDENES .......................................................................................... 3 2.4. OTROS PROCESOS Y NECESIDADES ................................................................................... 4 CAPÍTULO 3. PROPUESTA DE SOLUCIÓN INFORMÁTICA ...........................6 3.1. INTRODUCCIÓN.................................................................................................................. 6 3.2. ALCANCE .......................................................................................................................... 6 3.3. NOTACIÓN DE CASOS DE USO ............................................................................................ 6 3.4. FUNCIÓN DE ADMINISTRACIÓN............................................................................................ 7 3.5. FUNCIÓN DE INVENTARIO ................................................................................................. 13 3.6. FUNCIÓN DE ADMINISTRACIÓN DE BARRA .......................................................................... 30 3.7. FUNCIÓN ATENCIÓN MÓVIL EN MESAS ............................................................................... 40 CAPÍTULO 4. EL PROBLEMA DEL DESARROLLO DE APLICACIONES COMPLETAS.............................................................................................54 4.1. INTRODUCCIÓN................................................................................................................ 54 4.2. REQUERIMIENTOS TÍPICOS DE UNA APLICACIÓN ................................................................ 54 4.3. ¿QUÉ ES UN FRAMEWORK? ............................................................................................. 55 4.4. CUÁNDO USAR UN FRAMEWORK ....................................................................................... 55 CAPÍTULO 5. EXPRESSO FRAMEWORK COMO CASO DE ESTUDIO.............57 5.1. INTRODUCCIÓN................................................................................................................ 57 5.2. CARACTERÍSTICAS DE EXPRESSO .................................................................................... 57 5.3. DIFICULTADES Y CARENCIAS DE EXPRESSO ...................................................................... 57 5.4. IMPLEMENTACIÓN DE LA PERSISTENCIA EN EXPRESSO ...................................................... 57 5.5. IMPLEMENTACIÓN DE LA LÓGICA DEL NEGOCIO EN EXPRESSO ........................................... 66 CAPÍTULO 6. SUPERWABA COMO FRAMEWORK PARA APLICACIONES MÓVILES .................................................................................................74 CAPÍTULO 7. DESARROLLO DE UNA APLICACIÓN DISTRIBUIDA CON EL USO DE EXPRESSO Y SUPERWABA ..........................................................76 7.1. INTRODUCCIÓN................................................................................................................ 76 7.2. DESCRIPCIÓN GENERAL DE LA SOLUCIÓN ......................................................................... 76 CAPÍTULO 8. CONCLUSIONES..................................................................87 8.1. FUNCIONALES ................................................................................................................. 87 8.2. TÉCNICAS ....................................................................................................................... 87 CAPÍTULO 9. APÉNDICES ........................................................................89 9.1. APÉNDICE 4.1 ARCHIVO PRODUCTO.JAVA ....................................................................... 89 9.2. APÉNDICE 4.2 ARCHIVO DETALLEDEORDEN.JAVA ............................................................ 93 CAPÍTULO 10. BIBLIOGRAFÍA .................................................................98 CAPÍTULO 11. REFERENCIAS...................................................................99. ISC-2003-2-8. ii.

(3) Capítulo 1. Introducción Por medio de una solución informática a las necesidades de un tipo particular de restaurante, este documento muestra cómo en el proceso de construcción de software puede ser limitado a dar solución a los problemas propios del negocio, y en contraposición, delegando las responsabilidades paralelas a herramientas informáticas elaboradas por terceros. Se da inicio al recorrido de este documento con el planteamiento de un problema real en el sector de los restaurantes y los bares. Sigue la propuesta de su solución. Y con ella se hacen evidentes una serie de problemas al margen de lo puramente relacionado con el problema planteado en la primera parte. Es entonces cuando se introducen las herramientas tecnológicas escogidas para proveer las soluciones necesarias. El siguiente paso corresponde a las fases de diseño y desarrollo de un proyecto de construcción de software. Es aquí en donde este documento encuentra sus objetivos. Se muestra una manera alternativa a la tradicional para implementar un diseño que, a su vez, es novedoso. Por último se hace un recuento de los resultados al usar este paradigma alterno de desarrollo.. 1.1. Objetivos El presente trabajo se enmarca en el campo de la ingeniería y construcción de software. Estos se ocupan de los procesos que resultan en un sistema computacional como propuesta de solución a un problema real. Dentro de ese marco, los objetivos más importantes planteados aquí son los siguientes: Diseño y desarrollo de una solución informática para el control de órdenes y personal de servicio en restaurantes y bares. El sistema debe disminuir los tiempos de atención al cliente. Se espera que el sistema reduzca el tiempo que deben esperar los clientes para recibir su pedido, dado que los meseros disminuirán sus recorridos a la barra en un 30% El sistema debe dar apoyo al personal de meseros. En el restaurante que se tomó como caso de estudio, los meseros tiene una alta responsabilidad en cuanto a las cuentas, y sin embargo no cuentan con un sistema que los apoye en su labor. Se espera que el sistema facilite la labor de los meseros proporcionándoles información actualizada de inventario. Reducir los errores e inconsistencias entre las cuentas de los meseros y el personal encargado de la barra, es un objetivo muy importante a solucionar. El sistema debe mejorar el control de inventarios. Se espera que el sistema provea un sistema de control de inventarios fácilmente escalable. Incursión en el campo de tecnologías alternativas en computación móvil. Se espera que este documento explore opciones alternativas a las tradicionales y comerciales en el campo de la computación móvil.. ISC-2003-2-8. 1.

(4) Estudio y evaluación de un marco de trabajo (Framework) como herramienta útil para eliminar tareas al margen de la principal del negocio, enriquecer aplicaciones y disminuir el tiempo de desarrollo de aplicaciones. Se espera mostrar los casos en los cuales el uso de un framework es una efectiva herramienta para la construcción de software.. 1.2. Contenido El recorrido hecho en este documento es de la siguiente manera: El Capítulo 1, la introducción, hace un recorrido por los motivos que inspiraron la creación de este documento, y con ellos los objetivos que se buscan alcanzar para mejorar el problema planteado. El segundo capítulo introduce al lector en la problemática que gira entrono al restaurantebar que se tomó como modelo para desarrollar este trabajo. Se hace en el tercer capítulo una propuesta de lo que podría ser la solución informática para la problemática planteada en el capítulo anterior. Se hasta el capítulo cuarto en donde se plantea la cuestión fundamental a ser resulta en este documento. Se revisan los obstáculos por los que debe pasar un grupo de desarrollo de software al crear una aplicación de complejidad promedio y que un framework ofrece solucionar. Del capítulo quinto en adelante se muestra cómo Expresso y SuperWaba, los framework que se escogieron como caso de estudio para aplicaciones Web y aplicaciones móviles respectivamente, proponen sean solucionados los problemas que se plantean en los capítulos anteriores.. ISC-2003-2-8. 2.

(5) Capítulo 2. Revisión breve del funcionamiento de un restaurante 2.1. Introducción Hay una amplia gama de opciones de modelos de dirección que un administrador de restaurantes puede escoger para el suyo. Para alcanzar los objetivos planteados anteriormente, se ha escogido el modelo adoptado por Compostela Bar Ltda., un restaurante y bar de amplia trayectoria en la ciudad de Bogotá. Este modelo, si bien no es el más común entre los que se pueden escoger para este tipo de negocios, si presenta los retos y requerimientos necesarios para lograr los objetivos planteados.. 2.2. Estado actual de Compostela Bar Ltda. Con más de 15 meseros, dos cajas, cientos de clientes diarios, y millones en ventas, Compostela bar necesita administrar eficientemente sus recursos físicos y humanos. En la actualidad el establecimiento cuenta con una infraestructura de Hardware subutilizada compuesta por 4 computadores con sendos procesadores de 800Mhz. De los cuales dos cuentan monitores de “contacto”. Por otro lado, luego fracasar en repetidas ocasiones, el establecimiento carece de un sistema de información que facilite su administración. Juan Camilo Saldarriaga (comunicación personal, mayo 2003), principal accionista de Compostela, atribuye el fracaso de los sistemas de información que se han instalado a que ninguno de ellos esta diseñado de acuerdo a la manera como el restaurante es administrado, dice además, que no dan lugar a correcciones o a ajustes. En general estos sistemas se enfocan en un estricto control de inventarios, facturación, y contabilidad en general. Cuenta Saldarriaga que si bien el control de inventarios y la facturación son de vital importancia para el negocio, poco contribuyen a mejorar la eficiencia en la atención al cliente. La queja más común por parte de la clientela hace referencia al tiempo que los meseros tardan en traer los productos que han sido pedidos. Explica Saldarriaga que esta demora se debe a varios factores: Los meseros deben hacer constantes y largos recorridos entre las mesas que atienden y las barras, que son el lugar en donde los productos son entregados. Constantemente hay problemas de comunicación entre los meseros y los encargados de la barra a causa del alto volumen de la música y el ruido propio del establecimiento en horas pico. Estos problemas obligan al mesero a repetir la orden, cancelar la anterior, y en muchas ocasiones son causantes de vanos viajes a las mesas atendidas.. 2.3. El proceso de las órdenes Saldarriaga anota un segundo problema constante al que los sistemas anteriores no han dado una solución satisfactoria. Compostela tiene una manera muy particular de interactuar con sus meseros. Estos, a diferencia de la labor de transporte de mercancía y. ISC-2003-2-8. 3.

(6) mensajes entre los clientes y la cocina, como tradicionalmente actúan en otros establecimientos, tienen responsabilidades directas en la facturación. “Ante la caja” anota Saldarriaga, “los meseros son vistos como un cliente mas”. Ante la llegada de un cliente, el mesero se acerca y toma la orden; hecho esto, puede ir a una segunda mesa y repetir la acción antes de dirigirse a la barra. Una vez el mesero tiene las órdenes, se acerca a la barra y pide la totalidad de productos, sin informar a qué mesas va a llevarlos. La persona encargada de la barra entrega los productos y lleva registro de lo pedido por cada uno de los meseros. Cuando un cliente está listo para pagar su cuenta y salir del establecimiento, es responsabilidad del mesero cobrar lo que corresponde. De manera similar, al cierre, el encargado de la barra hace una relación de lo entregado a cada mesero, ellos a su vez, deben pagar lo correspondiente a sus ventas del día. Este sistema ha probado ser eficiente en Compostela, sin embargo, deja una gran responsabilidad a los meseros.. 2.4. Otros procesos y necesidades Cuando de administrar un restaurante del talante de Compostela se trata, son múltiples las tareas para las cuales se pueden diseñar soluciones informáticas. En general las áreas principales son: Administración y comunicación con proveedores. Se hace necesario tener un directorio de proveedores con el registro de los productos que ofrece cada proveedor y el precio al que los vende. Una vez se tienen estos datos, es importante contar con un medio de comunicación que permita informar a los proveedores los pedidos que se les solicitan y con un sistema de control de recibo. Administración de inventarios. Se espera que el sistema de administración de inventarios no solo provea una manera de saber la cantidad en existencias de un producto, sino que además calcule la utilidad de cada uno y el costo en inventario. Publicación actualizada de inventario a meseros. Los meseros deben tener a la mano las existencias de cada producto para evitar ofrecer un producto que no hay en inventario. Contabilidad. Como en cualquier empresa, es necesario que el sistema de información provea informes de contabilidad y contaduría, como el Balance General, Estado de resultados, Libro Mayor y Menor, etc. Historial mejor mesero. Es importante saber el desempeño de los meseros. El sistema debe proveer información estadística de los meseros. Procesos de CRM (Customer Relationship Management). Para fortalecer la fuerza de ventas, es importante tener registro de los clientes y sus preferencias. Y así, diseñar campañas publicitarias efectivas, ofertas eficientes, etc. Es deseable la posibilidad de enviar comunicados electrónicos a los clientes en fechas importantes como cumpleaños, tener un registro de clientes frecuentes, y en general diseñar estrategias para crear en el cliente un sentimiento de recordación. Control de entrada, salida y facturación. El sistema ofrecería apoyo al control de entrada y salida del establecimiento. Un cliente no podrá abandonar el restaurante sin antes pagar la cuenta, por ejemplo.. ISC-2003-2-8. 4.

(7) Proyecciones: Inventario óptimo. Dado que el sistema cuenta con información estadística de ventas detalladas por producto, es posible predecir el consumo de un periodo de tiempo en el futuro. De esta forma se podrá diseñar un plan de compras que obedezca al las ventas y a el precio según la oferta.. ISC-2003-2-8. 5.

(8) Capítulo 3. Propuesta de solución informática 3.1. Introducción Como se ha mostrado anteriormente, existe un amplio campo en el cual una solución informática tendría buena cabida. Para cubrir en su totalidad las demandas de un negocio de este tipo se hace necesario crear un sistema que sobrepasa el alcance de este documento. Sin embargo, para cumplir los objetivos anotados basta con restringir el alcance de este a unas pocas funcionalidades básicas.. 3.2. Alcance El propósito principal del sistema propuesto es el apoyo a meseros en su labor frente a los clientes. Esto es, el mesero contará con las herramientas necesarias para crear órdenes, ofrecer solo los productos que tienen existencias en inventario, comunicar estas órdenes a la persona encargada en la barra o la cocina para que los prepare, recibir notificación a cerca de las órdenes que están listas para ser entregadas a los clientes y, finalmente, hacer el resumen laboral para hacer la correspondiente liquidación. Por otra parte, y para dar soporte a lo anterior, el sistema estará en la capacidad de llevar un control de inventario. Dado que el sistema es multiusuario, se hace necesario administrar los usuarios. Se tendrá en cuenta aspectos de movilidad, seguridad, eficiencia, etc. Por otro lado, el sistema no estará en la capacidad de administrar proveedores, llevar la contabilidad, ni generar sus informes. Tampoco se llevará registro de las preferencias de consumo y por consiguiente no será posible hacer proyecciones de consumo, o de inventario óptimo.. 3.3. Notación de casos de uso En la descripción que sigue de cada caso de uso debe tenerse en cuenta la siguiente notación. Actor. Es la persona o rol que interactúa con el sistema y que obtiene de él un resultado específico que colabora en la realización sus objetivos. Todo caso de uso corresponde a la interacción de un actor, ya sea persona o aplicación, y provee para el mismo un resultado tangible. Nivel. El caso de uso puede tener tres niveles, gerencial, operativo, y computacional. Cuando un caso de uso tiene nivel gerencial, la descripción de la interacción tiene el nivel de la descripción de procesos, y normalmente se describe en función de interacción general entre un usuario externo a la institución y la organización misma. Por ejemplo, la interacción de un cliente jugador con la lotería puede tener este nivel, y describir que un cliente compra lotería, consulta resultados, y cobra los premios.. ISC-2003-2-8. 6.

(9) Cuando un caso de uso tiene nivel operativo el nivel de trabajo es detallado, indicando las acciones de cada actor y las posibles respuestas del sistema en ese diálogo. Ese es el nivel en que se escriben la mayoría de los casos de uso pues es un nivel adecuado para programación. Finalmente, un caso de uso con nivel computacional describe la interacción entre dos programas y rara vez tiene interés para el usuario final. Su interés está en describir un algoritmo para implantación de alguna funcionalidad, normalmente repetitiva. Por ejemplo, el cifrado de la palabra clave puede describirse como un caso de uso computacional. En la descripción que sigue se utiliza con preferencia la descripción de los casos de uso a nivel operativo. Versión. Es un número secuencial que indica la versión de discusión del caso de uso. El número 1 indica la primera versión, 2 la segunda, etc. Estado. Se consideran dos estados, “Para revisión”, y “Aprobado”. Un caso de uso para revisión está normalmente en sus primeras versiones, pero no ha tenido una aprobación formal. En contraste, un caso de uso aprobado ha sido revisado y aprobado, y puede utilizarse para programar. Contexto. Describe la razón de ser del caso de uso en forma de la operación que debe realizar. Precondición. Describe un estado de cosas que debe existir para que pueda ejecutarse el caso de uso. La descripción se describe en forma de un predicado lógico que debe evaluar a “verdadero”. De otra forma el caso de uso no puede ser ejecutado. Garantía de éxito. Describe el estado del sistema al terminar la ejecución del caso de uso cuando ésta es exitosa. Garantía mínima. Describe el estado del sistema cuando la ejecución de un caso de uso fracasa. Stakeholders. Identifica los dolientes cuyos intereses deben ser protegidos por el caso de uso.. 3.4. Función de administración La función de administración es una función general del sistema que permite registrar la información básica para poder operar. El administrador del sistema podrá registrar un nuevo usuario especificando el cargo que tendrá. Solo existen en el sistema tres posibles cargos: Administrador, cajero y mesero. El administrador podrá, además, actualizar la información de un usuario. La información de cada usuario está compuesta por su nombre, login, contraseña y perfil de usuario. Por último podrá consultar usuarios y suprimir usuarios registrados en el sistema.. ISC-2003-2-8. 7.

(10) Ilustración 1 Casos de uso de administración. Caso de uso:. 101 Ingresar al sistema (Login). Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito:. Todos Operativo 1 Para revisión Ingresa al sistema y puede ejecutar sus casos de uso Ninguna El usuario ha ingresado al sistema y puede afectar la información de una empresa de acuerdo con los permisos que le conceda el perfil al que pertenece. El sistema no se modifica; el usuario no puede ingresar al sistema ni puede ejecutar ninguno de sus casos de uso. Dueños, administrador.. Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4.. Usuario ingresa al sistema de loterías. Sistema presenta la pantalla inicial. Usuario provee código de usuario y palabra clave Sistema valida que a. El usuario esté registrado b. La palabra clave corresponda con la registrada en el sistema c. El usuario tenga autoridad para ingresar a la empresa seleccionada. Escenarios alternativos 3a. Información no valida, ya sea porque el usuario no existe, su palabra clave no corresponde, o el usuario no tiene autoridad para trabajar en la empresa seleccionada. Sistema informa del fracaso de la operación y regresa al paso 3 Vista del caso de uso 101 Ingresar al sistema (Login) Código usuario: Palabra clave: Botón de aprobación para ingresar al sistema. ISC-2003-2-8. 8.

(11) Caso de uso:. 102 Registrar nuevo usuario. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito:. Administrador Operativo 1 Para revisión Crea un nuevo registro de usuario y le asigna un rol El usuario no existe previamente Un nuevo usuario ha sido ingresado al sistema con el perfil especificado. El sistema no se modifica; no se crea el nuevo registro de usuario. Dueños, administrador, nuevo usuario.. Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4.. Administrador solicita registrar un nuevo usuario del sistema Sistema presenta una plantilla para registrar la información del usuario Administrador provee la información del usuario (Apellidos, nombre, cédula, teléfono, dirección, perfil obtenido de una lista de perfiles) y provee aprobación para guardarlo 5. Sistema valida que el usuario no haya sido previamente registrado, guarda la información e informa el éxito de la operación. Escenarios alternativos 5. El usuario ha sido previamente registrado en el sistema Sistema informa de la situación e informa el fracaso de la operación. Vista del caso de uso 102 Registrar nuevo usuario Apellidos: Nombres: Cédula: Teléfono: Dirección: Perfil de seguridad: (De lista de perfiles) Botón de aprobación para guardar. ISC-2003-2-8. 9.

(12) 3.4.1. Caso de uso: 103 Actualizar información de usuario Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador Operativo 1 Para revisión Modifica la información de un usuario El usuario ha sido registrado previamente La información del usuario ha sido modificada en el sistema. El sistema no se modifica; no se modifica el registro del usuario. Administrador, usuario.. Escenario principal 1. 2. 3. 4. 5.. Administrador solicita actualizar usuario Sistema presenta un listado de los usuarios registrados Administrador selecciona el usuario cuya información se va a actualizar Sistema presenta una plantilla para registrar la información del usuario Administrador modifica la información del usuario (Apellidos, nombre, teléfono, dirección, perfil obtenido de una lista de perfiles) y provee aprobación para guardarlo.. Escenarios alternativos No tiene. Vista del caso de uso 103 Actualizar información de usuario Apellidos: Nombres: Teléfono: Dirección: Perfil de seguridad: (De lista de perfiles) Botón de aprobación para guardar. ISC-2003-2-8. 10.

(13) Caso de uso:. 104 Suprimir usuario. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador Operativo 1 Para revisión Elimina un usuario del sistema El usuario ha sido registrado previamente No hay registro del usuario en el sistema. El sistema no se modifica; no se elimina ningún registro de usuario. Dueños, administrador, usuario.. Escenario principal 1. Administrador solicita suprimir usuario. 2. Sistema presenta un listado de los usuarios registrados. 3. Administrador selecciona el usuario a suprimir y provee aprobación para suprimirlo. Escenarios alternativos 3. El usuario seleccionado es el único administrador del sistema. 4. El sistema informa que la operación no es posible porque debe existir al menos un administrador. Vista del caso de uso 104 Suprimir usuario Usuario: Botón de aprobación para suprimir. ISC-2003-2-8. 11.

(14) Caso de uso:. 105 Consultar usuarios. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito:. Administrador Operativo 1 Para revisión Listar los usuarios registrados en el sistema. Ninguna El sistema no se modifica. Se listan los usuarios registrados en el sistema con su respectiva información. El sistema no se modifica. Administrador.. Garantía mínima: Stakeholders: Escenario principal. 1. Administrador solicita listar usuarios del sistema. 2. Sistema presenta un listado de los usuarios registrados. Escenarios alternativos No tiene Vista del caso de uso 105 Consultar usuarios Apellidos | Nombres | Cédula | Teléfono | Dirección | Cargo (perfil) Botón de aprobación para suprimir. ISC-2003-2-8. 12.

(15) 3.5. Función de inventario La función de inventario apoya administración de los productos y su existencia en bodega. Todos los productos son clasificados en un sistema de categorías de dos niveles, categorías y subcategorías. Por consiguiente, antes te crear un producto es necesario crear una categoría y crear una subcategoría especificando su respectivo nombre. Las categorías, subcategorías y productos creados podrán ser actualizados, consultados y suprimidos. Una vez estén creados los productos será posible aumentar su existencia al ingresar productos a inventario. De la misma manera es posible Suprimir un producto de inventario en caso de pérdida, deterioro, etc. En cualquier momento es posible consultar el inventario tanto de forma general, como filtrado según categorías y subcategorías. Al ingresar un producto al inventario, el sistema requiere se le especifique el costo al que fue adquirido, de la misma manera permite asignar y actualizar un precio de venta para cada producto. Con esta información el sistema es capaz generar un informe de movimiento de producto en inventario al consultar el historial de un producto en el que se presenta la utilidad que un producto ha generado.. Ilustración 2 Casos de uso de Inventario. Caso de uso:. 201 Crear una categoría. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, Cajero Operativo 1 Para revisión Crea una categoría de productos. La categoría no ha sido creada previamente La nueva categoría de productos ha sido creada. El sistema no se modifica; la categoría no fue creada. Administrador, cajero y mesero.. Escenario principal 1. Administrador solicita crear una nueva categoría de productos. 2. Sistema presenta una planilla para crear una nueva categoría.. ISC-2003-2-8. 13.

(16) 3. Administrador ingresa información de la categoría (nombre) y provee aprobación de adición. 4. El sistema verifica que no exista otra categoría con el mismo nombre y presenta un mensaje de éxito confirmando la adición de la categoría. Escenarios alternativos 4. Existe una categoría con el mismo nombre creada previamente. El sistema presenta un mensaje de error informando el fracaso en la operación. Vista del caso de uso 201 Crear una categoría Nombre categoría: Botón de aprobación para adicionar. ISC-2003-2-8. 14.

(17) Caso de uso:. 202 Actualizar categoría. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, Cajero Operativo 1 Para revisión Cambiar el nombre de una categoría de productos. La categoría ha sido creada previamente. El nombre de la categoría ha sido cambiada en el sistema. El sistema no se modifica; la categoría no fue modificada. Administrador, cajero y mesero.. Escenario principal 1. 2. 3. 4. 5.. Administrador solicita actualizar una categoría de productos. Sistema presenta un listado con las categorías creadas. Administrador elige la categoría a actualizar. Sistema presenta una planilla para actualizar la categoría. Administrador ingresa información de la categoría (nombre) y provee aprobación de actualización. 6. El sistema verifica que no exista otra categoría con el mismo nombre y presenta un mensaje de éxito confirmando la actualización de la categoría. Escenarios alternativos 5. Existe una categoría con el mismo nombre creada previamente. El sistema presenta un mensaje de error informando el fracaso en la operación. Vista del caso de uso 202 Actualizar categoría Nombre categoría: Botón de aprobación para actualizar. ISC-2003-2-8. 15.

(18) Caso de uso:. 203 Suprimir categoría. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, Cajero Operativo 1 Para revisión Suprimir una categoría de productos. La categoría ha sido creada previamente. No está la categoría registrada en el sistema. El sistema no se modifica; la categoría no fue suprimida. Administrador, cajero y mesero.. Escenario principal 1. 2. 3. 4.. Administrador solicita suprimir una categoría de productos. Sistema presenta un listado con las categorías creadas. Administrador elige la categoría a suprimir y provee aprobación de supresión. Sistema verifica que la categoría no tenga subcategorías asociadas y presenta un mensaje de éxito confirmando la supresión de la categoría.. Escenarios alternativos 4. La categoría tiene una o más subcategorías asociadas. El sistema presenta un mensaje de error informando el fracaso en la operación y sugiere suprimir o modificar todas subcategorías asociadas. Vista del caso de uso 203 Suprimir categoría Nombre categoría: Botón de aprobación de supresión. ISC-2003-2-8. 16.

(19) Caso de uso:. 204 Consultar categorías. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, Cajero, Mesero Operativo 1 Para revisión Listar las categorías de productos existentes en el sistema. Ninguna. El sistema no se modifica; se listan las categorías creadas. El sistema no se modifica; no se listan las categorías creadas. Administrador, cajero y mesero.. Escenario principal 1. Administrador solicita consultar las categorías de productos. 2. Sistema presenta un listado con las categorías creadas. Escenarios alternativos No tiene Vista del caso de uso 204 Consultar categorías | Nombre categoría |. ISC-2003-2-8. 17.

(20) 3.5.1. Caso de uso: Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. 205 Crear una subcategoría. Administrador, Cajero Operativo 1 Para revisión Crea una subcategoría de productos asociada a una categoría. La subcategoría no ha sido creada previamente La nueva subcategoría de productos ha sido creada. El sistema no se modifica; la subcategoría no fue creada. Administrador, cajero y mesero.. Escenario principal 1. 2. 3. 4. 5.. Administrador solicita crear una nueva subcategoría de productos. Sistema presenta un listado de las categorías creadas Administrador selecciona la categoría a la que estará asociada la subcategoría. Sistema presenta una planilla para crear una nueva subcategoría. Administrador ingresa información de la subcategoría (nombre) y provee aprobación de adición. 6. El sistema verifica que no exista otra categoría con el mismo nombre asociada a la misma categoría y presenta un mensaje de éxito confirmando la adición de la subcategoría. Escenarios alternativos 6. Existe una subcategoría con el mismo nombre asociada a la misma categoría creada previamente. El sistema presenta un mensaje de error informando el fracaso en la operación. Vista del caso de uso 205 Crear una subcategoría | Nombre categoría | Botón para selección Nombre subcategoría: Botón de aprobación de adición. ISC-2003-2-8. 18.

(21) Caso de uso:. 206 Actualizar subcategoría. Actor: Nivel: Versión: Estado: Contexto:. Administrador, Cajero Operativo 1 Para revisión Cambiar el nombre o categoría asociada de una subcategoría de productos. La subcategoría ha sido creada previamente. La información de la subcategoría ha sido cambiada en el sistema. El sistema no se modifica; la subcategoría no fue modificada. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4. 5.. Administrador solicita actualizar una subcategoría de productos. Sistema presenta un listado con las subcategorías creadas. Administrador elige la subcategoría a actualizar. Sistema presenta una planilla para actualizar la subcategoría. Administrador ingresa información de la categoría (nombre, categoría) y provee aprobación de actualización. 6. El sistema verifica que no exista otra categoría con el mismo nombre asociada a la nueva categoría y presenta un mensaje de éxito confirmando la actualización de la categoría. Escenarios alternativos 6. Existe una subcategoría con el mismo nombre creada previamente asociada a la misma categoría. El sistema presenta un mensaje de error informando el fracaso en la operación. Vista del caso de uso 206 Actualizar subcategoría Nombre subcategoría: Categoría asociada: Botón de aprobación para actualizar. ISC-2003-2-8. 19.

(22) Caso de uso:. 207 Suprimir subcategoría. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, Cajero Operativo 1 Para revisión Suprimir una subcategoría de productos. La subcategoría ha sido creada previamente. No está la subcategoría registrada en el sistema. El sistema no se modifica; la subcategoría no fue suprimida. Administrador, cajero y mesero.. Escenario principal 1. 2. 3. 4.. Administrador solicita suprimir una subcategoría de productos. Sistema presenta un listado con las subcategorías creadas. Administrador elige la subcategoría a suprimir y provee aprobación de supresión. Sistema verifica que la subcategoría no tenga productos asociados y presenta un mensaje de éxito confirmando la supresión de la categoría.. Escenarios alternativos 4. La categoría tiene uno o más productos asociados. El sistema presenta un mensaje de error informando el fracaso en la operación y sugiere suprimir o modificar todos los productos asociados. Vista del caso de uso 207 Suprimir subcategoría Nombre subcategoría: Botón de aprobación de supresión. ISC-2003-2-8. 20.

(23) Caso de uso:. 208 Consultar subcategorías. Actor: Nivel: Versión: Estado: Contexto:. Administrador, Cajero, Mesero Operativo 1 Para revisión Listar las subcategorías de productos existentes en el sistema según su categoría asociada. Ninguna. El sistema no se modifica; se listan las subcategorías creadas asociadas a una categorñia. El sistema no se modifica; no se listan las subcategorías creadas. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4.. Administrador solicita consultar las subcategorías de productos. Sistema presenta un listado con las categorías creadas. Administrador elige una categoría. Sistema presenta un listado con las subcategorías asociadas a la categoría elegida.. Escenarios alternativos 3. Administrador no elige categoría. Sistema presenta un listado con todas las subcategorías creadas. Vista del caso de uso 208 Consultar subcategorías | Nombre categoría | Nombre subCategoría. ISC-2003-2-8. 21.

(24) Caso de uso:. 209 Crear un producto. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador Operativo 1 Para revisión Crea un producto asociado a una subcategoría. El producto no ha sido creado previamente El nuevo producto ha sido creado. El sistema no se modifica; el producto no fue creado. Administrador, cajero y mesero.. Escenario principal 1. 2. 3. 4. 5. 6. 7. 8.. Administrador solicita crear un nuevo producto. Sistema presenta un listado de las categorías creadas. Administrador elige una categoría. Sistema presenta un listado de las subcategorías creadas asociadas a la categoría elegida. Administrador selecciona la subcategoría a la que estará asociado el producto. Sistema presenta una planilla para crear el nuevo producto. Administrador ingresa información del producto (nombre, descripción, precio de venta) y provee aprobación de adición. El sistema verifica que no exista otro producto con el mismo nombre asociado a la misma subcategoría y presenta un mensaje de éxito confirmando la adición del producto.. Escenarios alternativos 7. Existe un producto con el mismo nombre asociado a la misma subcategoría creado previamente. El sistema presenta un mensaje de error informando el fracaso en la operación. Vista del caso de uso 209 Crear un producto | Nombre categoría | Botón para selección | Nombre subcategoría | Botón para selección Nombre producto: Descripción del producto: Precio inicial de venta: Botón de aprobación de adición. ISC-2003-2-8. 22.

(25) Caso de uso:. 210 Actualizar producto. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, Cajero Operativo 1 Para revisión Cambiar el nombre o subcategoría asociada de un producto. El producto ha sido creado previamente. La información del producto ha sido cambiada en el sistema. El sistema no se modifica; el producto no fue modificado. Administrador, cajero y mesero.. Escenario principal 1. 2. 3. 4.. Administrador solicita actualizar un producto. Sistema presenta un listado de las categorías creadas. Administrador elige una categoría. Sistema presenta un listado de las subcategorías creadas asociadas a la categoría elegida. 5. Administrador selecciona la subcategoría a la que está asociado el producto. 6. Sistema presenta un listado de los productos asociados a la subcategoría asociada. 7. Administrador selecciona el producto a actualizar. 8. Sistema presenta una planilla para actualizar el producto. 9. Administrador ingresa nueva información del producto (nombre, descripción, subcategoría) y provee aprobación de actualización. 10. El sistema verifica que no exista otro producto con el mismo nombre asociado a la misma subcategoría y presenta un mensaje de éxito confirmando la adición del producto. Escenarios alternativos 10. Existe un producto con el mismo nombre creado previamente asociado a la misma subcategoría. El sistema presenta un mensaje de error informando el fracaso en la operación. Vista del caso de uso 210 Actualizar producto | Nombre categoría | Botón para selección | Nombre subcategoría | Botón para selección. Nombre producto: Descripción del producto: Subcategoría del producto: Botón de aprobación de actualización. ISC-2003-2-8. 23.

(26) Caso de uso:. 211 Suprimir producto. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, Cajero Operativo 1 Para revisión Suprimir un producto. El producto ha sido creado previamente. No está el producto registrado en el sistema. El sistema no se modifica; el producto no fue suprimido. Administrador, cajero y mesero.. Escenario principal 1. 2. 3. 4. 5. 6. 7. 8.. Administrador solicita suprimir un producto. Sistema presenta un listado de las categorías creadas. Administrador elige una categoría. Sistema presenta un listado de las subcategorías creadas asociadas a la categoría elegida. Administrador elige la subcategoría a la que está asociado el producto. Sistema presenta un listado de los productos asociados a la subcategoría elegida. Administrador elige el producto a suprimir. Sistema verifica que el producto no tenga órdenes (abiertas o cerradas) asociadas y presenta un mensaje de éxito confirmando la supresión de la categoría.. Escenarios alternativos 8. El producto tiene una o más órdenes asociadas. El sistema presenta un mensaje de error informando el fracaso en la operación. Vista del caso de uso 211 Suprimir producto | Nombre categoría | Botón para selección | Nombre subcategoría | Botón para selección | Nombre producto | Botón para selección Botón de aprobación de supresión. ISC-2003-2-8. 24.

(27) Caso de uso:. 212 Consultar productos. Actor: Nivel: Versión: Estado: Contexto:. Administrador, Cajero, Mesero Operativo 1 Para revisión Listar los productos existentes en el sistema según su categoría y subcategoría asociada. Ninguna. El sistema no se modifica; se listan los productos creados. El sistema no se modifica; no se listan los productos creados. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4.. Administrador solicita consultar los productos. Sistema presenta un listado de las categorías creadas. Administrador elige una categoría. Sistema presenta un listado de las subcategorías creadas asociadas a la categoría elegida. 5. Administrador elige la subcategoría a la que está asociado el producto. 6. Sistema presenta un listado de los productos asociados a la subcategoría elegida. Escenarios alternativos 3. 4. 5. 6.. Administrador no elige categoría. Sistema presenta un listado con todas las subcategorías creadas. Administrador elige la subcategoría a la que está asociado el producto. Sistema presenta un listado de los productos asociados a la subcategoría elegida. 5. Administrador no elige una subcategoría 6. Sistema presenta todos los productos creados de la categoría elegida o todos los productos creados si el administrador tampoco eligió categoría. Vista del caso de uso 212 Consultar productos | Nombre categoría | Botón para selección | Nombre subcategoría | Botón para selección Nombre categoría | Nombre subcategoría | Nombre producto | Descripción producto. ISC-2003-2-8. 25.

(28) Caso de uso:. 213 Ingresar producto a inventario. Actor: Nivel: Versión: Estado: Contexto:. Administrador Operativo 1 Para revisión Se registra en el sistema el recibo de mercancía aumentando el inventario. Además, re registra el costo de compra. El producto ha sido creado. El sistema adiciona a la existencia actual, la nueva mercancía recibida registrando su costo de compra. El sistema no se modifica; no se modifica el inventario. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4.. Sistema presenta un listado de los productos. Administrador elige el producto que se adicionará a inventario. Sistema presenta planilla para ingreso de mercancía nueva. Administrador ingresa información de recibo de mercancía (cantidad recibida, costo de compra). 5. Sistema analiza la información y presenta aviso de éxito en la operación. Escenarios alternativos 5. Administrador ingresa valores no válidos. 6. Sistema presenta un mensaje de error indicando las causas del fracaso de la operación. Vista del caso de uso 213 Ingresar producto a inventario. Nombre categoría | Nombre subcategoría | Nombre producto | Descripción producto Cantidad recibida: Costo: Botón para aprobación de ingreso en inventario. ISC-2003-2-8. 26.

(29) Caso de uso:. 214 Actualizar precio de venta producto. Actor: Nivel: Versión: Estado: Contexto: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador Operativo 1 Para revisión Se registra en el sistema cambio de precio de venta de un producto. El sistema registra el nuevo precio en el sistema. El sistema no se modifica; no se modifica el precio del producto. Administrador, cajero.. Escenario principal 1. 2. 3. 4.. Administrador solicita actualizar precio de venta producto. Sistema presenta un listado de las categorías creadas. Administrador elige una categoría. Sistema presenta un listado de las subcategorías creadas asociadas a la categoría elegida. 5. Administrador elige la subcategoría a la que está asociado el producto. 6. Sistema presenta un listado de los productos asociados a la subcategoría elegida. 7. Administrador elige el producto al que se le actualizará el precio. 8. Sistema presenta planilla para actualización de precio. 9. Administrador ingresa el nuevo precio. 10. Sistema analiza la información y presenta aviso de éxito en la operación. Escenarios alternativos 9. Cajero ingresa valores no válidos. 10. Sistema presenta un mensaje de error indicando las causas del fracaso de la operación. Vista del caso de uso 214 Actualizar precio de venta producto | Nombre categoría | Botón para selección | Nombre subcategoría | Botón para selección Nombre categoría | Nombre subcategoría | Nombre producto | Descripción producto Botón para selección Nombre producto | Descripción producto Nuevo precio: Botón para aprobación de actualización.. ISC-2003-2-8. 27.

(30) Caso de uso:. 215 Consultar inventario. Actor: Nivel: Versión: Estado: Contexto:. Administrador, cajero, mesero Operativo 1 Para revisión Se listan los productos indicando su existencia en inventario, costo y precio actual. Se listan los productos de inventario. El sistema no se modifica. El sistema no se modifica. Administrador, cajero, mesero.. Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4.. Administrador solicita consultar inventario. Sistema presenta un listado de las categorías creadas. Administrador elige una categoría. Sistema presenta un listado de las subcategorías creadas asociadas a la categoría elegida. 5. Administrador elige la subcategoría a la que está asociado el producto. 6. Sistema presenta un listado de los productos asociados a la subcategoría elegida indicando su descripción, costo, precio y existencia en inventario. Escenarios alternativos No tiene Vista del caso de uso 215 Consultar inventario | Nombre categoría | Botón para selección | Nombre subcategoría | Botón para selección Nombre categoría | Nombre subcategoría | Nombre producto | Descripción producto | Costo | Precio. ISC-2003-2-8. 28.

(31) Caso de uso:. 218 Consultar historial de producto. Actor: Nivel: Versión: Estado: Contexto:. Administrador Operativo 1 Para revisión Se muestra el historial de inventario de un producto. En el historial se visualizan sus entradas y salidas diarias junto con su costo o precio respectivo. Se lista el historial de inventario de un producto. El sistema no se modifica. El sistema no se modifica. Administrador, cajero.. Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4. 5. 6. 7. 8.. Administrador solicita consultar historial de producto. Sistema presenta un listado de las categorías creadas. Administrador elige una categoría. Sistema presenta un listado de las subcategorías creadas asociadas a la categoría elegida. Administrador elige la subcategoría a la que está asociado el producto. Sistema presenta un listado de los productos asociados a la subcategoría elegida. Administrador elige un producto. Sistema presenta una tabla con la fecha, cantidad comprada, cantidad vendida, costo, precio, cantidad en inventario, costo total en inventario, saldo en caja y utilidad generada por el producto.. Escenarios alternativos No tiene Vista del caso de uso 218 Consultar historial de producto | Nombre categoría | Botón para selección | Nombre subcategoría | Botón para selección | Nombre producto | Botón para selección Fecha | #compra | #venta | Costo | Precio | En inventario | Costo inventario | Caja | Utilidad. ISC-2003-2-8. 29.

(32) 3.6. Función de administración de barra La función de administración de barra da soporte al sector operacional del negocio. Permite definir la distribución del local al crear mesas y asignarlas a uno o más meseros. De la misma manera informa por medio de consultar órdenes por despachar sobre las órdenes que los meseros han hecho y complementarla al despachar las órdenes. Finalmente es posible registrar una venta directa. Una función más es la de liquidar a los meseros. Esta función se lleva a cabo al final de la jornada para establecer los honorarios del mesero. Paralelamente es posible consultar el resumen laboral de un mesero que informa sobre cada venta realizada y su estado.. Ilustración 3 Casos de uso del encargado del bar. Caso de uso:. 301 Crear una mesa. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, barra Operativo 1 Para revisión Crea una mesa para ser asignada a un mesero. La mesa no ha sido creada previamente La nueva mesa ha sido creada. El sistema no se modifica; la mesa no fue creada. Administrador, cajero y mesero.. Escenario principal 1. Administrador solicita crear una nueva mesa. 2. Sistema presenta una planilla para crear la nueva mesa. 3. Administrador ingresa información de la mesa (número, lugar) y provee aprobación de adición. 4. El sistema verifica que no exista otra mesa con el mismo número y presenta un mensaje de éxito confirmando la adición de la mesa. Escenarios alternativos. ISC-2003-2-8. 30.

(33) 4. Existe una mesa con el mismo número asociado creado previamente. El sistema presenta un mensaje de error informando el fracaso en la operación. Vista del caso de uso 301 Crear una mesa Número de mesa: Lugar: Botón de aprobación de adición. ISC-2003-2-8. 31.

(34) Caso de uso:. 302 Suprimir mesa. Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito: Garantía mínima: Stakeholders:. Administrador, barra Operativo 1 Para revisión Suprimir una mesa. La mesa ha sido creada previamente La mesa ha sido eliminada del sistema. El sistema no se modifica; la mesa no fue eliminada. Administrador, cajero y mesero.. Escenario principal 1. 2. 3. 4.. Administrador solicita suprimir una mesa. Sistema presenta un listado con las mesas. Administrador elige la mesa (número) y provee aprobación de supresión. El sistema presenta un mensaje de éxito confirmando la supresión de la mesa.. Escenarios alternativos No tiene. Vista del caso de uso 302 Suprimir mesa | Número de mesa | Botón de aprobación de supresión. ISC-2003-2-8. 32.

(35) Caso de uso: tiempo. 304 Consultar resumen laboral en un periodo de. Actor: Nivel: Versión: Estado: Contexto:. Administrador, mesero Operativo 1 Para revisión Se presentan las ventas en el establecimiento en un periodo de tiempo y el costo y precio de los productos vendidos. Ninguna. El sistema no se modifica; se presenta la información de las ventas hechas en el establecimiento. El sistema no se modifica. Administrador, cajero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4. 5. 6.. Administrador solicita consultar resumen laboral. Sistema presenta formato para selección de fecha de inicio de informe. Administrador elige fecha de inicio de informe. Sistema presenta formato para selección de fecha de fin de informe. Administrador elige fecha de fin de informe. Sistema presenta una tabla con la relación de ventas del establecimiento.. Escenarios alternativos No tiene. Vista del caso de uso 304 Consultar resumen laboral en un periodo de tiempo Fecha inicio informe: Fecha fin informe:. | Día | Mes | Año | Hora | Minutos | | Día | Mes | Año | Hora | Minutos |. Botón de selección Número de mesas atendidas: Número de órdenes: Costo de ventas: Precio de ventas: Utilidad: | Fecha | Hora inicio | Hora fin | No. Orden | Estado | Mesa | Costo |. ISC-2003-2-8. 33.

(36) Caso de uso:. 305 Liquidar mesero. Actor: Nivel: Versión: Estado: Contexto:. Administrador Operativo 1 Para revisión Se presentan las ventas hechas por un mesero en un periodo de tiempo y el costo y precio de los productos vendidos. El mesero ha sido creado previamente. El sistema no se modifica; se presenta la información de las ventas hechas por un mesero. El sistema no se modifica. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4. 5. 6. 7. 8.. Administrador solicita liquidar mesero. Sistema presenta un listado con los meseros creados. Administrador elige el mesero. Sistema presenta formato para selección de fecha de inicio de informe. Administrador elige fecha de inicio de informe. Sistema presenta formato para selección de fecha de fin de informe. Administrador elige fecha de fin de informe. Sistema presenta una tabla con la relación de ventas del mesero.. Escenarios alternativos No tiene. Vista del caso de uso 304 305 Liquidar meseros | Código del mesero | Nombre del mesero Fecha inicio informe: Fecha fin informe:. | Día | Mes | Año | Hora | Minutos | | Día | Mes | Año | Hora | Minutos |. Botón de selección Número de mesas atendidas: Número de órdenes: Costo de ventas: Precio de ventas: | Fecha | Hora inicio | Hora fin | No. Orden | Estado | Mesa | Costo |. ISC-2003-2-8. 34.

(37) Caso de uso:. 306 Consultar órdenes por despachar. Actor: Nivel: Versión: Estado: Contexto:. Cajero Operativo 1 Para revisión Se presentan las órdenes hechas por los meseros y que aun no han sido entregadas a los clientes. Ninguna. El sistema no se modifica; se presenta la información de las órdenes hechas por los meseros. El sistema no se modifica. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal. 1. Cajero solicita consultar órdenes por despachar. 2. Sistema presenta un listado con los códigos de las órdenes por despachar y su mesero. 3. Cajero elige una orden. 4. Sistema presenta formato información específica de la orden a despachar. Escenarios alternativos No tiene. Vista del caso de uso 306 Consultar órdenes por despachar | Código de la orden | Nombre del mesero Botón de selección | Código del producto | Nombre del producto | Anotaciones | Cantidad |. ISC-2003-2-8. 35.

(38) Caso de uso:. 307 Despachar orden. Actor: Nivel: Versión: Estado: Contexto:. Cajero Operativo 1 Para revisión El caso de uso inicia cuando una orden está lista en la barra para ser entregada al cliente. Se registra en el sistema que una orden pedida por un mesero está despachada, es decir, lista para ser entregada. La orden ha sido creada y no ha sido despachada. La orden cambia de estado a “despachada”. El sistema no se modifica. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal. 1. Cajero solicita despachar orden. 2. Sistema presenta un listado con los códigos de las órdenes por despachar y su mesero. 3. Cajero elige una orden y da aprobación para marcar como despachada. 4. Sistema presenta un mensaje de éxito en la operación. Escenarios alternativos No tiene. Vista del caso de uso 307 Despachar orden | Código de la orden | Nombre del mesero | Botón de selección. ISC-2003-2-8. 36.

(39) Caso de uso:. 308 Expedir factura. Actor: Nivel: Versión: Estado: Contexto:. Cajero Operativo 1 Para revisión El caso de uso inicia cuando un mesero pide se imprima la factura de una orden cerrada. La orden ha sido cerrada por parte del mesero y él ha sincronizado su sistema. La orden es mostrada a en pantalla para ser impresa. La orden queda en estado “impresa”. El sistema no se modifica. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal. 1. Cajero solicita expedir factura. 2. Sistema presenta un listado con los códigos de las órdenes cerradas y que algún mesero ha pedido imprimir. 3. Cajero elige una orden y da aprobación para impresión. 4. Sistema presenta en detalle la factura de la orden. Escenarios alternativos No tiene. Vista del caso de uso 308 Expedir factura | Código de la orden | Nombre del mesero | Botón de selección Factura No.: Fecha: | Código del producto | Nombre del producto | Cantidad | Precio | Subtotal: IVA: Total:. ISC-2003-2-8. 37.

(40) Caso de uso:. 309 Registrar venta. Actor: Nivel: Versión: Estado: Contexto:. Cajero Operativo 1 Para revisión El caso de uso inicia cuando un mesero se acerca con el dinero para pagar una factura. La factura de la orden ha sido impresa previamente. La orden está en estado “cancelada”. El sistema no se modifica. Administrador, cajero y mesero.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4. 5. 6.. Cajero solicita registrar venta. Sistema presenta un listado con los códigos de las órdenes impresas. Cajero elige una orden. Sistema presenta en detalle la factura de la orden. Cajero ingresa monto entregado por el cajero. Sistema registra la venta, muestra la boleta de salida y el cambio que debe entregar al mesero.. Escenarios alternativos 6. El mesero entrega menos dinero del necesitado para pagar la orden. 7. Sistema informa el error y regresa al paso 4. Vista del caso de uso 309 Registrar venta | Código de la orden | Nombre del mesero | Botón de selección Factura No.: Fecha: | Código del producto | Nombre del producto | Cantidad | Precio | Subtotal: IVA: Total: Abono: Botón aceptar | Cambio |. ISC-2003-2-8. 38.

(41) Caso de uso:. 310 Registrar venta directa. Actor: Nivel: Versión: Estado: Contexto:. Cajero Operativo 1 Para revisión El caso de uso inicia cuando un cliente le pide al cajero uno o más productos en la barra. Ninguna. Se ha generado una orden asignándole como mesero al cajero. El estado de la orden es “impresa” y referencia los productos pedidos. El inventario se ve reducido por los productos vendidos. El sistema no se modifica. Administrador, cajero y mesero.. Precondición: Garantía de éxito:. Garantía mínima: Stakeholders: Escenario principal 1. 2. 3. 4.. Cajero solicita registrar venta directa. Sistema planilla de venta. Cajero selecciona los productos a vender y su cantidad. Aprueba venta. Sistema presenta en detalle la factura de la orden.. Escenarios alternativos No tiene. Vista del caso de uso 310 Registrar venta directa | Categoría | Subcategoría | Producto | Cantidad | Botón de selección Factura No.: Fecha: | Código del producto | Nombre del producto | Cantidad | Precio | Subtotal: IVA: Total:. ISC-2003-2-8. 39.

(42) 3.7. Función atención móvil en mesas La función de atención móvil en mesas está diseñada para dar soporte al personal de meseros en la interacción con los clientes finales. El mesero cuenta con una herramienta móvil que lo acerca a la información de inventario mientras le ofrece la posibilidad de enviar órdenes al bar agilizando los procesos. Existe una asignación previa, por parte del administrador de la barra, de mesas al mesero de tal forma que este pueda suministrarles servicio. El mesero puede, para conseguir tal fin, abrir una orden asociada a una de las mesas que tiene asignadas. Hecho esto, es posible adicionar productos a la orden y para hacerlo, se consultan los productos con existencia en inventario por categorías y se seleccionan los que se han de adicionar. Seleccionados los productos, el mesero tiene la posibilidad de actualizar la cantidad pedida de un producto, suprimir un producto pedido y personalizar una orden editando notas de productos. Dado que el simultáneamente se trabaja con varias mesas, es posible consultar las órdenes de un mesero y a su vez, consultar los detalles de una orden entre los cuales están los productos pedidos, el precio y cantidad pedida por cada uno de ellos, el total a pagar de la cuenta, una marca en los productos que han sido entregados al cliente y otra que indica que la orden ha sido cerrada. En cualquier momento el mesero está en capacidad de consultar productos por entregar para listar los productos que están listos en la barra para ser entregados a los clientes. Una vez los entrega, marca los productos como entregados. Cuando el cliente desea retirarse y pide al mesero la cuenta, este cierra la orden para que el sistema le informe el costo total a pagar. Al sincronizar con la barra, se logra concordancia entre los meseros y la barra en cuanto a productos pedidos, productos listos para ser entregados a los clientes y cierre de órdenes. Para eso, el sistema móvil del mesero cuenta con comunicación inalámbrica vía puerto infrarrojo con la barra. En caso de error, el usuario podrá eliminar una orden siempre y cuando esta no contenga productos entregados al cliente.. ISC-2003-2-8. 40.

(43) Ilustración 4 Casos de uso de mesero. Caso de uso:. 401 Abrir una orden. Actor: Nivel: Versión: Estado: Contexto:. Mesero Operativo 1 Para revisión El caso de uso inicia cuando un mesero se acerca a un nuevo cliente. No tiene. El sistema tiene una nueva orden en estado “vacío”. El sistema no se modifica. Mesero y cliente.. Precondición: Garantía de éxito: Garantía mínima: Stakeholders: Escenario principal. 1. Mesero solicita abrir una orden oprimiendo el botón “nuevo” en la vista comanda. 2. Sistema presenta la vista de una orden vacía. 3. Mesero selecciona la mesa en la que se encuentra el cliente Escenarios alternativos No tiene. Vista del caso de uso 401 Abrir una orden Botón “Nuevo” Selección de la mesa.. ISC-2003-2-8. 41.

(44) | Producto | |Nota | |Cantidad | “vacío” Nota: Entregado:$ Total:$ Botón de regreso Botón para adicionar Botón para quitar Botón para eliminar. ISC-2003-2-8. 42.

(45) 3.7.1. Caso de uso: 402 Consultar productos con existencia en inventario por categorías Actor: Nivel: Versión: Estado: Contexto: Precondición: Garantía de éxito:. Garantía mínima: Stakeholders:. Mesero Operativo 1 Para revisión El caso de uso inicia cuando un mesero ha abierto una nueva orden. Se tiene una nueva orden abierta y seleccionada. El sistema no se modifica. El sistema muestra el listado de los productos existentes en el inventario de la categoría y subcategoría seleccionada. El sistema no se modifica. Mesero y cliente.. Escenario principal 1. El mesero solicita el listado de los productos existentes en el inventario, para esto oprime el botón adicionar en la vista de orden. 2. El sistema muestra la vista de productos con dos casillas donde el mesero puede elegir la categoría y subcategoría de los productos que desea consultar. Debajo, un listado de todos los productos existentes en el inventario. Escenarios alternativos 3. El mesero selecciona la categoría y subcategoría de los productos que va a consultar. 4. El sistema filtra la lista de los productos existentes en el inventario, a los pertenecientes a la categoría y subcategoría seleccionadas por el mesero Vista del caso de uso 402 Consultar productos con existencia en inventario por categorías Botón “adicionar” Selección de categoría Selección de subcategoría |Lista de productos existentes en el inventario | precios respectivos de cada producto | Botón para cancelar. Botón para adicionar. Cantidad:. ISC-2003-2-8. 43.

(46) Caso de uso:. 403 Adicionar producto a una orden. Actor: Nivel: Versión: Estado: Contexto:. Mesero Operativo 1 Para revisión El caso de uso inicia cuando un mesero después de consultar el inventario selecciona los productos que ha pedido el cliente. El producto que se desea adicionar tiene existencia en inventario. . El sistema muestra la orden con los productos que han sido seleccionados, la cantidad que ha sido seleccionada de cada uno y además las notas de observación de cada producto. El sistema no se modifica. Mesero y cliente.. Precondición: Garantía de éxito:. Garantía mínima: Stakeholders: Escenario principal. 1. El mesero selecciona los productos deseados del listado de los productos existentes en el inventario, el mesero escribe la cantidad deseada de cada producto, el mesero oprime el botón adicionar. 2. El sistema muestra la vista de la orden con la lista de los productos que fueron adicionados, la cantidad requerida de cada uno y un espacio frente a cada producto, para escribir las anotaciones referentes a cada producto. Escenarios alternativos 3. El mesero puede regresar al listado de los productos del inventario, para seleccionar otros productos. 4. El sistema muestra al mesero el estado de la orden después de los cambios que se han hecho. Vista del caso de uso 403 Adicionar producto a una orden Botón adicionar. Selección de categoría Selección de subcategoría |Lista de productos existentes en el inventario | precios respectivos de cada producto | Botón para cancelar. Botón para adicionar. Selección de la cantidad del producto a adicionar.. ISC-2003-2-8. 44.

(47) Caso de uso:. 404 Suprimir detalle de orden. Actor: Nivel: Versión: Estado: Contexto:. Mesero Operativo 1 Para revisión El caso de uso inicia cuando se ha adicionado un producto a la orden y se desea reversar esta operación. El producto ha sido adicionado con anterioridad. Se ha seleccionado la orden que se va a alterar en la vista de Comanda. El sistema muestra la orden con la lista de los detalles que habían sido adicionados con anterioridad, sin incluir los que han sido suprimidos. El sistema no se modifica. Mesero y cliente.. Precondición: Garantía de éxito:. Garantía mínima: Stakeholders: Escenario principal. 1. El mesero selecciona los detalles a suprimir del listado en la vista de orden, y oprime el botón quitar. 2. El sistema muestra la vista de la orden, con todos los detalles adicionados excepto los que han sido suprimidos. La cantidad requerida de cada uno y la nota no se ven alterados. Escenarios alternativos 3. El mesero puede regresar al listado de los productos del inventario, para seleccionar otros productos en reemplazo de los que han sido suprimidos. 4. El sistema muestra al mesero el estado de la orden después de los cambios que se han hecho. Vista del caso de uso 404 Suprimir detalle de orden | Producto | |Nota | |Cantidad | Nota: Entregado:$ Total:$ Botón de regreso Botón para adicionar Botón para quitar Botón para eliminar. ISC-2003-2-8. 45.

(48) Caso de uso:. 405 Actualizar cantidad pedida de producto. Actor: Nivel: Versión: Estado: Contexto:. Mesero Operativo 1 Para revisión El caso de uso inicia cuando se ha adicionado un detalle a la orden y se desea cambiar la cantidad que se había solicitado de este producto. Que el producto y la cantidad requerida de este exista en el inventario. . El sistema muestra la orden con la lista de los productos que habían sido seleccionados con anterioridad, la cantidad requeridas de cada uno con las modificaciones respectivas de cantidad y las notas de observación de cada producto. El sistema no se modifica. Mesero y cliente.. Precondición: Garantía de éxito:. Garantía mínima: Stakeholders: Escenario principal. 1. El mesero selecciona el producto en la vista de orden, rescribe el número de la cantidad que había solicitado por la nueva cantidad a solicitar. 2. El sistema muestra la vista de la orden con la lista de los productos que fueron seleccionados, la cantidad requerida de cada uno que ha sido modificada para algunos productos y un espacio frente a cada producto donde se han escrito las anotaciones referentes a cada producto. Escenarios alternativos Ninguno Vista del caso de uso 405 Actualizar cantidad pedida de producto | Producto | |Nota | |Cantidad | Nota: Entregado:$ Total:$ Botón de regreso Botón para adicionar Botón para quitar Botón para eliminar. ISC-2003-2-8. 46.

(49) Caso de uso:. 406 Editar nota de producto en una orden. Actor: Nivel: Versión: Estado: Contexto:. Mesero Operativo 1 Para revisión El caso de uso inicia cuando se ha adicionado un producto a la orden y se tiene una recomendación importante que debe ser tenida en cuenta en el momento de sacar el producto. El producto ha sido adicionado con anterioridad y figura en la orden. . El sistema muestra la orden con la lista de los productos seleccionados, la cantidad requerida de cada uno y las notas de observación de cada producto. El sistema no se modifica. Mesero y cliente.. Precondición: Garantía de éxito:. Garantía mínima: Stakeholders: Escenario principal. 1. El mesero escribe la anotación de los detalles que lo requieren en el espacio de notas designado que se encuentra en frente de cada producto. 2. El sistema muestra la vista de la orden, con la lista de los productos seleccionados, la cantidad requerida de cada uno y las anotaciones que se requieran. Escenarios alternativos Ninguno Vista del caso de uso 406 Editar nota de producto en una orden | Producto | |Nota | |Cantidad | Nota: Entregado:$ Total:$ Botón de regreso Botón para adicionar Botón para quitar Botón para eliminar. ISC-2003-2-8. 47.