Contratos I

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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una inserción de cliente en curso, en la cual se ha comprobado que el cliente no existía ya en BD.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.

POSTCONDICIONES:

  1. Se creó un nuevo objeto cliente en el sistema.
  2. Se creó una tupla en BD con la información del cliente nuevo.
  3. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. 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.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
  3. El objeto cliente está creado en el sistema.

POSTCONDICIONES:

  1. Se mostraron los datos del cliente c por pantalla.
  2. El usuario modificó los datos oportunos del cliente c.
  3. Se actualizó en BD la tupla que contenía la información antigua del cliente c con la nueva información.
  4. Se actualizó el objeto cliente.
  5. Se actualizó el estado del cliente en BD si es distinto al anterior.
  6. Si el estado final del cliente es el correspondiente a “eliminado”, se elimina el objeto cliente del sistema.
  7. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una inserción de producto en curso, en la cual se ha comprobado que el producto no existía ya en BD.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.

POSTCONDICIONES:

  1. Se creó una tupla en BD con la información del producto nuevo.
  2. Se creó un nuevo objeto producto.
  3. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una modificación de producto en curso, en la cual se ha comprobado que el producto existía ya en BD.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
  3. El objeto producto está creado en el sistema.

POSTCONDICIONES:

  1. Se mostraron los datos del producto p por pantalla.
  2. El usuario modificó los datos del producto p.
  3. Se modificó la tupla correspondiente en BD con la información nueva del producto p.
  4. Se actualizó el objeto producto.
  5. Se actualizó el estado del producto en BD si es distinto al anterior.
  6. Si el producto existe en una venta o en una reserva pendiente, no se permite modificar el estado del mismo.
  7. 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:

  1. Hay una modificación o creación de producto en curso.
  2. Los datos económicos han sido introducidos en la aplicación.
  3. El precio de compra se ha introducido.
  4. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.

POSTCONDICIONES:

  1. Se obtiene el precio de venta aconsejado por la aplicación según los datos económicos y el precio de compra del producto.
  2. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. El tipo de búsqueda suministrado debe corresponder con una de las tablas que tenemos almacenadas en BD.
  2. El tipo de la clave primaria que se recibe debe ser compatible con el de la clave primaria de la tabla.
  3. Se realiza una búsqueda en BD.

POSTCONDICIONES:

  1. En caso de que la búsqueda tenga éxito, se devuelve la tupla completa desde BD.
  2. 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:

  1. 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.
  2. 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.
  3. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una venta en curso.
  2. El objeto venta está creado y sus datos debidamente rellenos.
  3. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, estructura de los datos, etc.
  4. Al menos existe un objeto lineaVenta asociado a la venta.
  5. 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:

  1. Se creó una tupla en BD con la información de la venta nueva.
  2. La venta insertada se almacena con el estado “alta”.
  3. Se almacenó una tupla en BD por cada uno de los objetos lineaVenta que están relacionados con v.
  4. Si la fecha no es válida, se notifica y se aborta el proceso de inserción de venta.
  5. Si la hora no es válida, se notifica y se aborta el proceso de inserción de venta.
  6. 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:

  1. 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.
  2. 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.
  3. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una modificación de venta en curso, en la cual se ha comprobado que la venta existía ya en BD.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
  3. El objeto venta está creado en el sistema.
  4. Al menos hay un objeto lineaVenta asociado a la venta creado en el sistema.

POSTCONDICIONES:

  1. Se mostraron los datos de la venta v por pantalla.
  2. El usuario modificó los datos de la venta v.
  3. Se modificó la tupla correspondiente en BD con la información nueva de la venta v.
  4. Se modificó una tupla en BD por cada uno de los objetos lineaVenta que están relacionados con v conteniendo la nueva información.
  5. Se actualizó el objeto venta.
  6. Se actualizaron los objetos lineaVenta asociados a la venta en curso.
  7. Si la fecha no es válida, se notifica y se aborta el proceso de modificación de venta.
  8. Si la hora no es válida, se notifica y se aborta el proceso de modificación de venta.
  9. 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ó.
  10. Se actualizó el estado de la venta en BD si es distinto al anterior.
  11. Si la venta está aún en curso, no se permite modificar el estado del mismo a "eliminado"
  12. Si el estado final de la venta es el correspondiente a “eliminado”, se elimina el objeto venta del sistema lógicamente.
  13. 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:

  1. 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.
  2. 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.
  3. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una reserva en curso.
  2. El objeto reserva está creado y sus datos debidamente rellenos.
  3. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, estructura de los datos, etc.
  4. Al menos existe un objeto lineaReserva asociado a la reserva.
  5. 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:

  1. Se creó una tupla en BD con la información de la reserva nueva.
  2. La reserva insertada se almacena con el estado “alta”.
  3. Se almacenó una tupla en BD por cada uno de los objetos lineaReserva que están relacionados con v.
  4. Si la fecha no es válida, se notifica y se aborta el proceso de inserción de reserva.
  5. Si la hora no es válida, se notifica y se aborta el proceso de inserción de reserva.
  6. 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ó.
  7. En caso de que no se haya abonado toda la reserva, el estado de la reserva pasará a ser "reserva".
  8. 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:

  1. 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.
  2. 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.
  3. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una modificación de reserva en curso, en la cual se ha comprobado que la reserva existía ya en BD.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
  3. El objeto reserva está creado en el sistema.
  4. Al menos hay un objeto lineaReserva asociado a la reserva creado en el sistema.

POSTCONDICIONES:

  1. Se mostraron los datos de la reserva v por pantalla.
  2. El usuario modificó los datos de la reserva v.
  3. Se modificó la tupla correspondiente en BD con la información nueva de la reserva v.
  4. Se modificó una tupla en BD por cada uno de los objetos lineaReserva que están relacionados con v conteniendo la nueva información.
  5. Se actualizó el objeto reserva.
  6. Se actualizaron los objetos lineaReserva asociados a la reserva en curso.
  7. Si la fecha no es válida, se notifica y se aborta el proceso de modificación de reserva.
  8. Si la hora no es válida, se notifica y se aborta el proceso de modificación de reserva.
  9. 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ó.
  10. Se actualizó el estado de la reserva en BD si es distinto al anterior.
  11. Si la reserva está aún en curso, no se permite modificar el estado del mismo a "eliminado"
  12. Si el estado final de la reserva es el correspondiente a “eliminado”, se elimina el objeto reserva del sistema lógicamente.
  13. 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.
  14. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Se ha generado una venta o reserva y ha sido almacenada en BD.
  2. Hay una venta o reserva en curso.

POSTCONDICIONES:

  1. Se creó una tupla en BD con la información de la factura nueva.
  2. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
  2. 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:

  1. Se ha generado una factura y ha sido almacenada en BD.
  2. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una modificación de los datos económicos de la empresa en curso.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
  3. El objeto empresa está creado en el sistema.

POSTCONDICIONES:

  1. Se mostraron los datos económicos de la empresa e por pantalla.
  2. El usuario modificó los datos económicos de la empresa e.
  3. Se modificó la tupla correspondiente en BD con la información nueva de la empresa e.
  4. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
  2. 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:

  1. Hay una modificación de los datos de la empresa en curso.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
  3. El objeto empresa está creado en el sistema.

POSTCONDICIONES:

  1. Se mostraron los datos de la empresa e por pantalla.
  2. El usuario modificó los datos de la empresa e.
  3. Se modificó la tupla correspondiente en BD con la información nueva de la empresa e.
  4. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. 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.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.

POSTCONDICIONES:

  1. Se creó un nuevo objeto gasto y un nuevo objeto gastoAdicional.
  2. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. 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.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
  3. El objeto gasto y el objeto gasto adicional está creado en el sistema.

POSTCONDICIONES:

  1. Se mostraron los datos del gasto g y del gasto adicional ga por pantalla.
  2. El usuario modificó los datos oportunos del gasto g y del gasto adicional ga.
  3. 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.
  4. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. 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.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.

POSTCONDICIONES:

  1. Se creó un nuevo objeto zonaProvincia.
  2. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. 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.
  2. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.
  3. El objeto zonaProvincia está creado en el sistema.

POSTCONDICIONES:

  1. Se mostraron los datos de la zonaProvincia zp por pantalla.
  2. El usuario modificó los datos oportunos de la zonaProvincia zp.
  3. Se actualizó en BD la tupla que contenía la información antigua de la zonaProvincia zp con la nueva información.
  4. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.

SALIDA: Ninguna.
PRECONDICIONES:

  1. Hay una eliminación de zona provincia en curso.
  2. El objeto zonaProvincia está creado en el sistema.

POSTCONDICIONES:

  1. Se eliminó en BD la tupla con la información de la zonaProvincia zp.
  2. 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:

  1. Si no se puede establecer la conexión con la base de datos se devolverá un mensaje de error al usuario.
  2. 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.
  3. 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.
  4. 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:

  1. Hay una inserción por fichero de zonas de provincia en curso.
  2. El fichero debe de estar almacenado en algún medio físico existente en el sistema.
  3. El fichero debe de ser tipo texto.
  4. Se ha comprobado la validez de los datos: datos nulos, tipos de datos, rango, etc.

POSTCONDICIONES:

  1. Se creó un nuevo objeto zonaProvincia.
  2. Se creó una tupla en BD con la información de la zona provincia.
  3. Se creó un nuevo objeto zonaProvincia.
  4. Se creó una tupla en BD con la información de la zona provincia.

Ir a contratos anteriores

Volver a modelado dinámico del prototipo I

contratosdinámicoprototipo1
page revision: 34, last edited: 01 Feb 2007 23:45
Edit Tags History Files Print Site tools + Options
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.