Caso para Resolver: Sistema de Punto de Venta

1. Caso para Resolver: Sistema de Punto de Venta Una Terminal de punto de venta (TPV) es un sistema computarizado usado para registrar las ventas y manejar los pagos. Es típicamente usado en las tiendas e incluye componentes hardware tales como un computador, un scanner de código de barras y software para correr el sistema. Asuma que se solicita crear el software para correr una TPV. Usando una estrategia de desarrollo incremental iterativo procederemos a enunciar requerimientos y a realizar el análisis, diseño e implementación O.O. DSOO - María Eugenia Valencia

2. Arquitectura de Diseño por Capas - X Venta Pago Prod. Cod Cantidad Agente de B.D. Administrador de seguridad Total Entregado Balance Entrar Item Fin Venta Pagar Menor énfasis; se discute cómo conectarse a otras capas Presentación Aplicación Lógica Principal énfasis del estudio del caso Objetos del dominio del problema Énfasis secundario del estudio del caso Objetos de servicio Almacenamiento Base de Datos Capas en un SIOO Típico DSOO - María Eugenia Valencia

3. Etapa de Requerimientos Los artefactos que aquí se presentan son solo documentos comunes de la fase de requerimientos y NO artefactos específicos de UML: • Definición del objetivo general • Clientes • Metas • Funciones del sistema - Atributos del sistema DSOO - María Eugenia Valencia

4. Funciones del Sistema Es lo que se supone hará el sistema, tal como autorizar pagos a crédito. Estas funciones deben identificarse y listarse en grupos cohesivos lógicos. Si x es una función del sistema, la siguiente oración debe tener sentido: El sistema debería hacer <x>. Ejemplo: El sistema debería hacer autorización de pagos a crédito. DSOO - María Eugenia Valencia

5. Categorías de Funciones Las que deben ejecutarse y el usuario debe ser consciente que se ejecutarán. Evidentes: (E) Oculta: (O) Se deben ejecutar, pero no son visibles a los usuarios. Esto se aplica a muchos servicios técnicos tales como “almacenar información en un medio de almacenamiento persistente”. Este tipo de funciones a veces se olvidan al especificar requerimientos. No Esenciales: (NE) Opcionales. Añadirlas no afectan significativamente ni costos ni otras funciones. DSOO - María Eugenia Valencia

6. Ref # Función. Categ. R 1.1 Registrar la venta actual – ítems ordenados. E R1.2 Calcular total venta actual, incluyendo impuesto y cálculo por cupones de descuento. E R1.3 Capturar información del ítem ordenado mediante el scanner del código de barras o entrando manualmente el código del producto. E R1.4 Reducir la cantidad del inventario cuando se realiza la venta. O R1.5 Hacer un registro histórico (Log) de ventas completadas. O R1.6 El cajero debe entrar su código de usuario y clave para usar el sistema. E R1.7 Proveer un mecanismo o medio de almacenamiento persistente. O R1.8 Proveer mecanismos de comunicación entre procesos y entre sistemas. O R1.9 Desplegar descripción y precio del ítem registrado E Requerimientos (Funciones Básicas) DSOO - María Eugenia Valencia

7. Ref # Función Categ. R2.1 Manejar pagos en efectivo, capturando cantidad entregada y calculando el balance a favor. E R2.2 Manejar pagos a crédito, capturando información desde una lectora de tarjeta o por entrada manual, y autorizando pago a través de una conexión vía moden con el servicio de autorizaciones de crédito de la tienda (externo). E R2.3 Manejar pagos con cheque, capturando los datos de la persona por entrada manual y autorizando pago a través de una conexión vía moden con el servicio de autorizaciones de crédito de la tienda (externo). E R2.4 Añadir (Log) los pagos a crédito al sistema de recaudo de las cuentas cuando el servicio de autorización de créditos le adeude a la tienda la cantidad del pago. E Requerimientos (Funciones de Pago) DSOO - María Eugenia Valencia

8. Atributos del Sistema: Son cualidades no funcionales del sistema, tales como, facilidad de uso, tolerancia a las fallas, tiempo de respuesta, costo unitario. A menudo se confunden con las funciones pero al aplicarlos a la oración anterior ella carecerá de sentido. Ejemplo: para facilidad de uso: x el sistema debería hacer facilidad de uso. DSOO - María Eugenia Valencia

9. Atributos del Sistema: (continuación) Estos hacen parte de un documento diferente al de Especificaciones Funcionales del Sistema, que puede denominarse Documento de Especificación de Atributos del Sistema. Los atributos del sistema pueden atravesar todas las funciones (ejemplo, una plataforma de sistema operativo) o ser específicos a una función particular o a un grupo de funciones. DSOO - María Eugenia Valencia

10. Atributos del Sistema: (continuación) Los atributos del sistema tienen un posible conjunto de detalles de atributo, los cuales tienden a ser discretos, imprecisos. Valores simbólicos de los atributos pueden ser: Tiempo de respuesta = (sicológicamente apropiado) Ejemplo: Tiempo de respuesta = (máximo 5 segundos) Metáfora de interfaz = (gráfica, a color, basada en formas). Algunos atributos del sistema pueden tener restricciones de frontera del atributo DSOO - María Eugenia Valencia

11. Otros Artefactos o Instrumentos de la Fase de Requerimientos. • Equipos de Requerimientosy de interrelación. Lista de los grupos que deberían involucrarse en la especificación de funciones y atributos del sistema, y realizar versiones, pruebas, negociaciones, etc. • Grupos Afectados. Los afectados por el desarrollo • y/o la instalación del sistema. • Supuestos. Las cosas que se asumen como verdaderas. DSOO - María Eugenia Valencia

12. Otros Artefactos o Instrumentos de la Fase de Requerimientos. • Riesgos. Las cosas que pueden llevar a fallas o retrasos. • Dependencias. Otras personas, sistemas y productos • de los cuales este proyecto depende para su culminación. • Glosario. Definición de términos relevantes. • Casos de Uso. • Borrador de Modelo Conceptual. DSOO - María Eugenia Valencia