Caja registradora en Java con base de datos Access

utilizando el IDE Netbeans

Después de prácticamente 2 meses sin publicar absolutamente nada os quiero hacer llegar
este trabajo de un curso de programación Java que he estado realizando (de ahí mi baja
frecuencia de publicación). Se basa en un programa que hace las veces de caja registradora
moderna y que permite guardar datos de información de clientes y de pedidos en una base de
datos Access. A continuación se muestra una memoria explicativa.

1. Diseño de la base de datos

El objetivo es crear una aplicación que permita de información relacionada con los pedidos que
en una compañía de comida rápida se hacen. Debe permitir la opción de registrar clientes y que
estos tengan descuentos. Para el diseño de la base de datos hay que determinar primero cuáles
serán las entidades y los atributos asociados a dichas entidades. Se han considerado como
entidades los Clientes, los Pedidos y los Productos. Cada uno de ellos debe tener unos atributos,
que representan la información sobre dichas entidades. Los atributos que se almacenan de cada
entidad son:
 Entidad Cliente: NIF, Nombre, PrimerApellido y SegundoApellido.
 Entidad Pedidos: NúmeroPedido, Fecha e Importe.
 Entidad Productos: NúmeroProducto, Precio y NombreProducto.
Decididas las entidades y atributos asociados, es necesario determinar los atributos claves,
aquellos que no se repiten y no pueden estar vacíos. Se han elegido los siguientes:
 Entidad Cliente: NIF.
 Entidad Pedidos: NúmeroPedido.
 EntidadProductos: NúmeroProducto. En este atributo clave hay que aclarar que aunque se
vayan a servir productos iguales, no se estarán sirviendo los mismos productos. Es decir, si un
cliente pide un capuccino, eso será un producto, y si justo después otro cliente pide de nuevo
capuccino, está pidiendo otro capuccino nuevo, no el mismo que se entregó al cliente anterior,
por lo que nunca habrá dos capuccinos con el mismo NúmeroProducto.
Llegados a este punto es hora de determinar las relaciones entre entidades. Se han considerado
las siguientes:
 Un Cliente realiza Pedidos, de forma que las entidades Cliente y Pedidos se relacionan y tienen
una relación uno a muchos, ya que un cliente puede realizar muchos pedidos, pero un
determinado pedido es realizado por un solo cliente.
 Un Pedido estará formado por uno o varios Productos, teniéndose así una relación uno a
muchos, ya que un Pedido puede tener varios Productos, pero cada Producto (NúmeroProducto)
pertenece a un solo pedido.
Por último queda por determinar las claves foráneas, traspasando así el atributo clave de una
entidad a otra, existiendo así elementos de unión entre entidades relacionadas. Las claves
foráneas que se han determinado son:
 Entidad Cliente: Ninguna.
 Entidad Pedidos: NIF (procedente de la entidad Cliente).
 Entidad Productos: NúmeroPedido (procedente de la entidad Pedidos).
Con toda esta información recabada, ya es posible generar el modelo E-R de forma gráfica, que
se muestra en la imagen a continuación:
 Modelo ER de la base de datos

2. Diseño de la interfaz
Para el diseño de la interfaz se ha optado por buscar la simplicidad y facilidad de uso, tratando
de crear un sistema Poka-Yoke que evite errores en la lectura-introducción de datos por parte
del usuario de la aplicación.
Toda la aplicación parte de una ventana principal sobre la que aparecen-desaparecen paneles
según se vaya indicando. Al arrancar el programa principal aparecerá esta ventana principal, que
tiene el siguiente aspecto:

Aspecto de la ventana principal

En ella se puede observar lo que podría ser el logotipo de la compañía (evidentemente se ha

escogido uno cualquiera), un título y un menú en la parte superior que permite acceder a todas
las funcionalidades del programa.
Clicando en la opción Cliente podemos acceder al alta, baja y modificación de clientes. Las
ventanas se muestran a continuación respectivamente:
Aspecto de la ventana AltaCliente

Aspecto de la ventana BajaCliente

 Aspecto de la ventana ModificarCliente

Todas ellas están formadas por etiquetas, cajas de texto sobre las que introducir la información
y botones que captarán eventos para ejecutar acciones.
Desde el menú Pedidos se puede acceder a las opciones Nuevo pedido, Fecha pedidos,
Pedidos de clientes, cuyos nombres resultan autoexplicativos. Los aspectos de dichas
ventanas son:

Apecto de la ventana AltaPedido

Esta es la parte de la interfaz más recargada. En la parte superior izquierda aparecen las
etiquetas y cajas de texto que permiten introducir la fecha actual (en un programa real debiera
captarlo automáticamente) e introducir el NIF de un cliente si está registrado, o bien realizar el
pedido como un cliente no registrado. Debajo de estas opciones se encuentran los diferentes
productos que componen el menú, cada uno de ellos con un botón que permite añadir al
pedido el producto. En la parte derecha se muestra una tabla sobre la que irán apareciendo los
productos que un cliente solicita, una opción de eliminar algún tipo de producto en caso de
 introducción por error y por último una caja de texto que muestra el importe total y el botón para
imprimir o realizar el pago del pedido.

Aspecto de la ventana FechaPedidos

Esta es una ventana simple sobre la que introducir la fecha sobre la cuál queremos ver los
pedidos realizados.

Aspecto de la ventana PedidosCliente

Muy similar a la anterior, esta ventana permite introducir el NIF del cliente sobre el que
queremos ver los pedidos que ha solicitado.

3. Diseño de la arquitectura de programación

Para la realización del programa se han generado los siguientes paquetes:
 fastfoodcompany.principal: Contiene Aplicación y FastFoodCompany. Aplicación simplemente
se encarga de cargar y visualizar la ventana principal, que está diseñada en
FastFoodCompany.
 fastfoodcompany.principal.acciones: Contiene la clase AccionesFastFoodCompany que se
encarga de atender a los eventos que ocurran en la ventana FastFoodCompany y realizar las
acciones necesarias.
 fastfood.clientes: Contiene AltaCliente, BajaCliente y ModificarCliente que son las clases con
los JPanel (paneles) vistos en las figuras 3, 4 y 5.
 fastfood.clientes.acciones: Contiene las clases AccionesAltaCliente, AccionesBajaCliente y
AccionesModificarCliente que, al igual que hace AccionesFastFoodCompany, se encarga de
atender a los eventos que ocurran en las ventanas (que serán originados por el usuario) y
ejecutar las respuestas.
 fastfood.pedidos:Contiene AltaPedido, FechaPedidos y PedidosCliente.
 fastfood.pedidos.acciones: Con AccionesAltaPedido, AccionesFechaPedidos y
AccionesPedidosCliente.
 fastfood.gestionBD: Contiene ServiceCliente, GestionSQLClientes, ServicePedidos y
GestionSQLPedidos. Las clases GestionSQLXXX se encargan de gestionar la conexión con la
base de datos, mientras que las clases ServiceXXX se encarga de generar las consultas SQL
correspondientes que luego serán solicitadas desde GestionSQLXXX. Las clases XXXCliente
se encargan de todo lo relacionado con el alta, baja y modificación de clientes, mientras que
XXXPedidos gestionan lo relacionado con los pedidos.
Se ha desarrollado por tanto una arquitectura Model-View-Controller, donde:
 View: FastFoodCompany, AltaCliente, BajaCliente, ModificarCliente, AltaPedido,
FechaPedidos y PedidosCliente.
 Model: AccionesFastFoodCompany, AccionesAltaCliente, AccionesBajaCliente,
AccionesModificarCliente, AccionesAltaPedido, AccionesFechaPedidos,
AccionesPedidosCliente, ServiceClientes y ServicePedidos.
 Controller: GestionSQLClientes, GestionSQLPedidos.

4. Manual de usuario interactivo

Véase:
Manual usuario interactivo
5. Código fuente de la aplicación
Lo podéis descargar aquí

http://geekenformacion.blogspot.com.es/