1. insertarCliente:
NOMBRE: insertarCliente (DNI: string, nombre: string, apellidos: string, direccion: string, localidad: string, provincia: string, codigoPostal: int, telefonoContacto: string)
RESPONSABILIDADES: Inserta un nuevo cliente en el sistema.
REFERENCIAS CRUZADAS: CU14-ICLI.
NOTAS: A partir del formulario de inserción de cliente nuevo, se insertan los datos en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una inserción de cliente en curso, en la cual se ha comprobado que el cliente no existía ya en BD.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
POSTCONDICIONES:
- Se creó un nuevo objeto cliente en el sistema.
- Se creó una tupla en BD con la información del cliente nuevo.
- El cliente insertado se almacena con el estado “alta”.
2. modificarDatosCliente:
NOMBRE: modificarDatosCliente (c: cliente)
RESPONSABILIDADES: Modifica los datos de un cliente ya almacenado en el sistema.
REFERENCIAS CRUZADAS: CU15-MCLI.
NOTAS: Debe existir una búsqueda previa del cliente a modificar. A partir del formulario de modificación de cliente nuevo, se actualizan los nuevos datos en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una modificación de cliente en curso, en la cual se ha obtenido los datos anteriores del cliente, y el usuario los ha modificado con los nuevos datos.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
- El objeto cliente está creado en el sistema.
POSTCONDICIONES:
- Se mostraron los datos del cliente c por pantalla.
- El usuario modificó los datos oportunos del cliente c.
- Se actualizó en BD la tupla que contenía la información antigua del cliente c con la nueva información.
- Se actualizó el objeto cliente.
- Se actualizó el estado del cliente en BD si es distinto al anterior.
- Si el estado final del cliente es el correspondiente a “eliminado”, se elimina el objeto cliente del sistema.
- Si el cliente posee una venta o una reserva pendiente, no se permite modificar el estado del mismo.
3. insertarProducto:
NOMBRE: insertarProducto (idProducto: int, nombre: string, categoria: string, proveedor: string, precioCompra: float, existencias: int, valorUmbral: float, epocaVenta: string, direccionFoto: string, observaciones: string)
RESPONSABILIDADES: Inserta un nuevo producto en el sistema.
REFERENCIAS CRUZADAS: CU03-IPRO.
NOTAS: A partir del formulario de inserción de producto nuevo, se insertan los datos en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una inserción de producto en curso, en la cual se ha comprobado que el producto no existía ya en BD.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
POSTCONDICIONES:
- Se creó una tupla en BD con la información del producto nuevo.
- Se creó un nuevo objeto producto.
- El producto insertado se almacena con el estado “alta”.
4. modificarDatosProducto
NOMBRE: modificarDatosProducto (p: producto)
RESPONSABILIDADES: Modifica los datos de un producto ya almacenado en el sistema.
REFERENCIAS CRUZADAS: CU04-MPRO.
NOTAS: Debe existir una búsqueda previa del producto a modificar. Tomamos como punto de partida el formulario en el que el usuario puede modificar los datos de dicho producto.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una modificación de producto en curso, en la cual se ha comprobado que el producto existía ya en BD.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
- El objeto producto está creado en el sistema.
POSTCONDICIONES:
- Se mostraron los datos del producto p por pantalla.
- El usuario modificó los datos del producto p.
- Se modificó la tupla correspondiente en BD con la información nueva del producto p.
- Se actualizó el objeto producto.
- Se actualizó el estado del producto en BD si es distinto al anterior.
- Si el producto existe en una venta o en una reserva pendiente, no se permite modificar el estado del mismo.
- Si el estado final del producto es el correspondiente a “eliminado”, se elimina el objeto producto del sistema.
5. obtenerPrecioVenta
NOMBRE: obtenerPrecioVenta (precioCompra: float, margenBeneficios: float, IVA: float, recargoEquivalencia: float)
RESPONSABILIDADES: Calcula, a partir del precio de compra de un producto y los datos económicos almacenados, el precio de venta aconsejado.
REFERENCIAS CRUZADAS: CU03-IPRO, CU04-MPRO.
NOTAS: Esta operación es utilizada antes de almacenar los datos en BD.
EXCEPCIONES:
SALIDA: Se muestra el resultado por pantalla y se da la opción de modificarlo antes de almacenarlo todo.
PRECONDICIONES:
- Hay una modificación o creación de producto en curso.
- Los datos económicos han sido introducidos en la aplicación.
- El precio de compra se ha introducido.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
POSTCONDICIONES:
- Se obtiene el precio de venta aconsejado por la aplicación según los datos económicos y el precio de compra del producto.
- Se actualiza el objeto producto actual con este precio de venta.
6. calcularBusqueda
NOMBRE: calcularBusqueda(tipoBusqueda: int, clavePrimaria: string)
RESPONSABILIDADES: Realiza una búsqueda en BD para comprobar si existe en la tabla correspondiente al tipo de búsqueda una tupla con la clave primaria suministrada.
REFERENCIAS CRUZADAS: CU20-BUSQ.
NOTAS: El uso de esta operación en el caso de uso CU20-BUSQ es una precondición necesaria para todos los casos de uso de “Modificar X”.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- El tipo de búsqueda suministrado debe corresponder con una de las tablas que tenemos almacenadas en BD.
- El tipo de la clave primaria que se recibe debe ser compatible con el de la clave primaria de la tabla.
- Se realiza una búsqueda en BD.
POSTCONDICIONES:
- En caso de que la búsqueda tenga éxito, se devuelve la tupla completa desde BD.
- En caso de éxito, se crea un objeto del tipo correspondiente a tipoBusqueda, asignándole los datos de la tupla encontrada.
7. insertarVenta:
NOMBRE: insertarVenta (v: venta)
RESPONSABILIDADES: Inserta una nueva venta en BD.
REFERENCIAS CRUZADAS: CU18-RVEN
NOTAS:
- Se puede almacenar una venta tras crear las distintas líneas de venta agregando los productos que componen la venta, y tras rellenar los datos necesarios para la venta.
- Como fecha de envío válida entenderemos una fecha posterior a la actual. Se aceptan como válidas todas las fechas futuras, incluyendo domingos y festivos.
- Como hora de envío válida entenderemos en un principio que esté comprendida entre las 8:00 horas y las 21:00 horas.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una venta en curso.
- El objeto venta está creado y sus datos debidamente rellenos.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, estructura de los datos, etc.
- Al menos existe un objeto lineaVenta asociado a la venta.
- Las existencias que hay en el almacén de un producto es el límite de cantidad de ese producto para las ventas que vayan a ser retiradas en el mismo día de la venta.
POSTCONDICIONES:
- Se creó una tupla en BD con la información de la venta nueva.
- La venta insertada se almacena con el estado “alta”.
- Se almacenó una tupla en BD por cada uno de los objetos lineaVenta que están relacionados con v.
- Si la fecha no es válida, se notifica y se aborta el proceso de inserción de venta.
- Si la hora no es válida, se notifica y se aborta el proceso de inserción de venta.
- Las cantidades de los productos que estaban agregados en la venta se han decrementado en BD en una cantidad igual a las veces que el producto aparece en la venta siempre y cuando la venta sea para el mismo día que se realizó.
8. modificarVenta:
NOMBRE: modificarVenta (v: venta)
RESPONSABILIDADES: Modifica una venta existente en el sistema.
REFERENCIAS CRUZADAS: CU19-MVEN
NOTAS:
- Debe existir una búsqueda previa de la venta a modificar. Tomamos como punto de partida el formulario en el que el usuario puede modificar los datos de dicha venta.
- Como fecha de envío válida entenderemos una fecha posterior a la actual. Se aceptan como válidas todas las fechas futuras, incluyendo domingos y festivos.
- Como hora de envío válida entenderemos en un principio que esté comprendida entre las 8:00 horas y las 21:00 horas.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una modificación de venta en curso, en la cual se ha comprobado que la venta existía ya en BD.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
- El objeto venta está creado en el sistema.
- Al menos hay un objeto lineaVenta asociado a la venta creado en el sistema.
POSTCONDICIONES:
- Se mostraron los datos de la venta v por pantalla.
- El usuario modificó los datos de la venta v.
- Se modificó la tupla correspondiente en BD con la información nueva de la venta v.
- Se modificó una tupla en BD por cada uno de los objetos lineaVenta que están relacionados con v conteniendo la nueva información.
- Se actualizó el objeto venta.
- Se actualizaron los objetos lineaVenta asociados a la venta en curso.
- Si la fecha no es válida, se notifica y se aborta el proceso de modificación de venta.
- Si la hora no es válida, se notifica y se aborta el proceso de modificación de venta.
- Las cantidades de los productos que han sido modificados que estaban agregados en la venta se han decrementado en BD en una cantidad igual a las veces que el producto aparece en la venta siempre y cuando la venta sea para el mismo día que se realizó.
- Se actualizó el estado de la venta en BD si es distinto al anterior.
- Si la venta está aún en curso, no se permite modificar el estado del mismo a "eliminado"
- Si el estado final de la venta es el correspondiente a “eliminado”, se elimina el objeto venta del sistema lógicamente.
- Si se han modificado los productos de una venta (añadido o eliminado) y dicha venta será retirada en el mismo día, las cantidades de los productos que han sido agregados/eliminados en la venta serán decrementados/aumentados en BD en una cantidad igual a las veces en las que el producto aparece en la venta.
9. insertarReserva:
NOMBRE: insertarReserva (v: venta)
RESPONSABILIDADES: Inserta una nueva reserva en BD.
REFERENCIAS CRUZADAS: CU16-RRES
NOTAS:
- Se puede almacenar una reserva tras crear las distintas líneas de reserva agregando los productos que componen la reserva, y tras rellenar los datos necesarios para la reserva.
- Como fecha de envío válida entenderemos una fecha posterior a la actual. Se aceptan como válidas todas las fechas futuras, incluyendo domingos y festivos.
- Como hora de envío válida entenderemos en un principio que esté comprendida entre las 8:00 horas y las 21:00 horas.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una reserva en curso.
- El objeto reserva está creado y sus datos debidamente rellenos.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, estructura de los datos, etc.
- Al menos existe un objeto lineaReserva asociado a la reserva.
- Las existencias que hay en el almacén de un producto es el límite de cantidad de ese producto para las reservas que vayan a ser retiradas en el mismo día de la reserva.
POSTCONDICIONES:
- Se creó una tupla en BD con la información de la reserva nueva.
- La reserva insertada se almacena con el estado “alta”.
- Se almacenó una tupla en BD por cada uno de los objetos lineaReserva que están relacionados con v.
- Si la fecha no es válida, se notifica y se aborta el proceso de inserción de reserva.
- Si la hora no es válida, se notifica y se aborta el proceso de inserción de reserva.
- Las cantidades de los productos que estaban agregados en la reserva se han decrementado en BD en una cantidad igual a las veces que el producto aparece en la reserva siempre y cuando la reserva sea para el mismo día que se realizó.
- En caso de que no se haya abonado toda la reserva, el estado de la reserva pasará a ser "reserva".
- En caso de que se haya abonado toda la reserva, el estado de la reserva pasará a ser “venta”.
10. modificarReserva:
NOMBRE: modificarReserva (v: venta)
RESPONSABILIDADES: Modifica una reserva existente en el sistema.
REFERENCIAS CRUZADAS: CU17-MRES
NOTAS:
- Debe existir una búsqueda previa de la reserva a modificar. Tomamos como punto de partida el formulario en el que el usuario puede modificar los datos de dicha reserva.
- Como fecha de envío válida entenderemos una fecha posterior a la actual. Se aceptan como válidas todas las fechas futuras, incluyendo domingos y festivos.
- Como hora de envío válida entenderemos en un principio que esté comprendida entre las 8:00 horas y las 21:00 horas.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una modificación de reserva en curso, en la cual se ha comprobado que la reserva existía ya en BD.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
- El objeto reserva está creado en el sistema.
- Al menos hay un objeto lineaReserva asociado a la reserva creado en el sistema.
POSTCONDICIONES:
- Se mostraron los datos de la reserva v por pantalla.
- El usuario modificó los datos de la reserva v.
- Se modificó la tupla correspondiente en BD con la información nueva de la reserva v.
- Se modificó una tupla en BD por cada uno de los objetos lineaReserva que están relacionados con v conteniendo la nueva información.
- Se actualizó el objeto reserva.
- Se actualizaron los objetos lineaReserva asociados a la reserva en curso.
- Si la fecha no es válida, se notifica y se aborta el proceso de modificación de reserva.
- Si la hora no es válida, se notifica y se aborta el proceso de modificación de reserva.
- Las cantidades de los productos que han sido modificados que estaban agregados en la reserva se han decrementado en BD en una cantidad igual a las veces que el producto aparece en la reserva siempre y cuando la reserva sea para el mismo día que se realizó.
- Se actualizó el estado de la reserva en BD si es distinto al anterior.
- Si la reserva está aún en curso, no se permite modificar el estado del mismo a "eliminado"
- Si el estado final de la reserva es el correspondiente a “eliminado”, se elimina el objeto reserva del sistema lógicamente.
- Si se han modificado los productos de una reserva (añadido o eliminado) y dicha reserva será retirada en el mismo día, las cantidades de los productos que han sido agregados/eliminados en la reserva serán decrementados/aumentados en BD en una cantidad igual a las veces en las que el producto aparece en la reserva.
- En caso de que se haya abonado toda la reserva, el estado de la reserva pasará a ser “venta”.
11. generarFactura:
NOMBRE: generarFactura (v: [venta|reserva], DNICliente: string, observaciones: string)
RESPONSABILIDADES: Almacenar los datos de una venta, los datos del cliente y alguna que otra observación como una factura.
REFERENCIAS CRUZADAS: CU21-IFAC
NOTAS: A partir del formulario de realizar venta o del formulario de realizar reserva o del formulario de modificar venta o del formulario modificar reserva, se genera una factura con los datos existentes en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Se ha generado una venta o reserva y ha sido almacenada en BD.
- Hay una venta o reserva en curso.
POSTCONDICIONES:
- Se creó una tupla en BD con la información de la factura nueva.
- Se almacenó una tupla en BD por cada uno de los objetos lineaVenta que están relacionados con v.
12. imprimirFactura:
NOMBRE: imprimirFactura (f: factura, e: empresa)
RESPONSABILIDADES: Imprime un recibo de tipo factura y los datos de la empresa.
REFERENCIAS CRUZADAS: CU21-IFAC.
NOTAS: A partir del formulario de realizar venta o del formulario de realizar reserva o del formulario de modificar venta o del formulario modificar reserva, se genera un recibo factura con los datos existentes en BD y se solicita que se imprima.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
- Si se solicita imprimir una factura sin que esta haya sido generada se devolverá un mensaje de error al usuario como que la factura no existe.
SALIDA: Un recibo con los datos de la factura.
PRECONDICIONES:
- Se ha generado una factura y ha sido almacenada en BD.
- Hay una venta o reserva en curso.
POSTCONDICIONES:
13. establecerDatosEconómicos:
NOMBRE: establecerDatosEconomicos (e: empresa)
RESPONSABILIDADES: Establecer los datos pertenecientes a la economía de la empresa como son el margen de beneficios, el IVA, el recargo de equivalencia y la mano de obra. //
REFERENCIAS CRUZADAS: //CU05-EDEC.
NOTAS: A partir del formulario de Establecer Datos Económicos de la empresa, se modifican los datos en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una modificación de los datos económicos de la empresa en curso.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
- El objeto empresa está creado en el sistema.
POSTCONDICIONES:
- Se mostraron los datos económicos de la empresa e por pantalla.
- El usuario modificó los datos económicos de la empresa e.
- Se modificó la tupla correspondiente en BD con la información nueva de la empresa e.
- Se actualizó el objeto empresa.
14. insertarDatosEmpresa:
NOMBRE: insertarDatosEmpresa (e: empresa)
RESPONSABILIDADES: Establecer los datos pertenecientes a la empresa como son el nombre de gerente, nombre de la empresa, NIF, dirección completa de donde está ubicada, teléfono y una dirección física desde donde se pueda cargar un logotipo para la empresa.
REFERENCIAS CRUZADAS: CU13-EDEM.
NOTAS: A partir del formulario de Establecer Datos de la empresa, se modifican los datos en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
- Si la dirección física introducida como lugar de ubicación del logotipo no existe o no es correcta se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una modificación de los datos de la empresa en curso.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
- El objeto empresa está creado en el sistema.
POSTCONDICIONES:
- Se mostraron los datos de la empresa e por pantalla.
- El usuario modificó los datos de la empresa e.
- Se modificó la tupla correspondiente en BD con la información nueva de la empresa e.
- Se actualizó el objeto empresa.
15. insertarGastoAdicional:
NOMBRE: insertarGastoAdicional (idGasto: int, fecha: date, cantidad: float, descripcion: string)
RESPONSABILIDADES: Almacenar un gasto adicional producido en la empresa como puede ser gasto de limpieza, artículos de papelería, etc.
REFERENCIAS CRUZADAS: CU06-IGAS.
NOTAS: A partir del formulario de insertar gasto adicional, se generan nuevos datos en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una inserción de un gasto adicional en curso, en la cual se ha comprobado que el gasto no existía ya en BD.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
POSTCONDICIONES:
- Se creó un nuevo objeto gasto y un nuevo objeto gastoAdicional.
- Se creó una tupla en BD con la información del gasto nuevo y una tupla asociada con la información del gasto adicional.
16. modificarGastoAdicional:
NOMBRE: modificarGastoAdicional (g: gasto, ga: gastoAdicional)
RESPONSABILIDADES: Modificar los datos de un gasto adicional ya almacenado en el sistema.
REFERENCIAS CRUZADAS: CUXX-MGAS.
NOTAS: Debe existir una búsqueda previa del gasto adicional a modificar. A partir del formulario de modificación de gasto adicional, se actualizan los nuevos datos en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una modificación de un gasto adicional en curso, en la cual se ha obtenido los datos anteriores del gasto adicional, y el usuario los ha modificado con los nuevos datos.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
- El objeto gasto y el objeto gasto adicional está creado en el sistema.
POSTCONDICIONES:
- Se mostraron los datos del gasto g y del gasto adicional ga por pantalla.
- El usuario modificó los datos oportunos del gasto g y del gasto adicional ga.
- Se actualizó en BD la tupla que contenía la información antigua del gasto g y la tupla que contenía la información antigua del gasto adicional ga con la nueva información.
- Se actualizó el objeto gasto y el objeto gasto adicional.
17. insertarZonaProvincia:
NOMBRE: insertarZonaProvincia (idZonaProvincia: int, codigoPostal: int, nombre: string, precio: float)
RESPONSABILIDADES: Almacenar una zona de una provincia.
REFERENCIAS CRUZADAS: CU08-IZPR.
NOTAS: A partir del formulario de Insertar Zonas de Provincia, se almacena la información que nos interesa.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una inserción de zona provincia en curso, en la cual se ha comprobado que la zona provincia no existía ya en BD.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
POSTCONDICIONES:
- Se creó un nuevo objeto zonaProvincia.
- Se creó una tupla en BD con la información de la zona provincia.
18. modificarDatosZonaProvincia:
NOMBRE: modificarDatosZonaProvincia (zp: zonaProvincia)
RESPONSABILIDADES: Actualizar o modificar una zona de una provincia existente.
REFERENCIAS CRUZADAS: CU09-MZPR.
NOTAS: A partir del formulario de modificar zonas de una provincia, se actualizan o se modifican los datos en BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una modificación de zona provincia en curso, en la cual se ha obtenido los datos anteriores de la zona provincia, y el usuario los ha modificado con los nuevos datos.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
- El objeto zonaProvincia está creado en el sistema.
POSTCONDICIONES:
- Se mostraron los datos de la zonaProvincia zp por pantalla.
- El usuario modificó los datos oportunos de la zonaProvincia zp.
- Se actualizó en BD la tupla que contenía la información antigua de la zonaProvincia zp con la nueva información.
- Se actualizó el objeto zonaProvincia.
19. eliminarZonaProvincia:
NOMBRE: eliminarZonaProvincia (zp: zonaProvincia)
RESPONSABILIDADES: Eliminar una zona provincia.
REFERENCIAS CRUZADAS: CU10-EZPR.
NOTAS: A partir del formulario de eliminar zonas de una provincia, se elimina un registro de la BD.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una eliminación de zona provincia en curso.
- El objeto zonaProvincia está creado en el sistema.
POSTCONDICIONES:
- Se eliminó en BD la tupla con la información de la zonaProvincia zp.
- Se eliminó el objeto zonaProvincia.
20. insertarZonaProvinciaDesdeFichero:
NOMBRE: insertarZonaProvinciaDesdeFichero(idZonaProvincia: int, codigoPostal: int, nombre: string, precio: float)
RESPONSABILIDADES: Almacenar una zona de una provincia desde un fichero de datos.
REFERENCIAS CRUZADAS: CU23-CDDF.
NOTAS: A partir del formulario de Insertar Zonas de Provincia desde un fichero, se almacena la información que existe en dicho fichero.
EXCEPCIONES:
- Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
- Si la dirección física introducida como lugar de ubicación del fichero de datos no existe o no es correcta se devolverá un mensaje de error al usuario.
- Si los datos leídos no corresponden a la siguiente estructura: <codigoPostal + “ “ + nombre + “ “ + precio + “\n”> se devolverá un mensaje de error al usuario indicando que la estructura del fichero no es la correcta.
- Si se llega al final del fichero se mostrará un mensaje de alerta indicando que se ha llegado al final del fichero.
SALIDA: Ninguna.
PRECONDICIONES:
- Hay una inserción por fichero de zonas de provincia en curso.
- El fichero debe de estar almacenado en algún medio físico existente en el sistema.
- El fichero debe de ser tipo texto.
- Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
POSTCONDICIONES:
- Se creó un nuevo objeto zonaProvincia.
- Se creó una tupla en BD con la información de la zona provincia.
- Se creó un nuevo objeto zonaProvincia.
- Se creó una tupla en BD con la información de la zona provincia.