DISEÑO

5.1. Diseño de la capa de presentación

En este proyecto, la capa de presentación se limitará a la navegación entre los diferentes apartados de la aplicación mediante un menú y a recoger o mostrar datos prácticamente de la misma manera que se introducirán o solicitarán de la capa de datos.

Todas las interfaces que la componen, a excepción de la página de identificación de usuario tendrán la siguiente distribución:

En el bloque 1 de la interfaz tendremos la cabecera, que incluirá el menú de navegación para desplazarnos por todas las funciones de la aplicación. Encima de este menú encontraremos la fecha y hora actual y un enlace con nuestro nombre de usuario que nos indica el fin de sesión en caso de así quererlo.

El bloque 2 o cuerpo, estará ocupado por formularios de introducción o modificación de datos o listados de objetos para ser gestionados.

La interfaz de identificación de usuario sólo dispondrá de un formulario donde introducir los credenciales de acceso.

figura 1: Interfaz de la aplicación

5.2. Diseño de la capa de negocio

5.2.1. Caso de uso: Identificar Usuario

Escogemos el patrón controlador para gestionar el evento externo IdentificarUsuario. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorUsuarios. Además, esta clase artificial tiene acceso directo a todos los usuarios. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método IdentificarUsuario de GestorUsuarios accede a la tabla y consulta que el Usuario de nombre y clave introducidos esté en ella.

Por el patrón experto, el método EsSuperAdministrador de GestorUsuarios accede a la tabla y consulta si el usuario introducido es Super Administrador del Sistema.

Los datos devueltos se almacenen como variables de sesión.

qIdentificarUsuario(usuario,clave) = SELECT U.idUsuario,U.nivel FROM usuario AS U WHERE U.usuario = usuario AND U.clave = clave LIMIT 1;

qEsSuperAdministrador(idUsuario) = SELECT E.master FROM empleado AS E WHERE E.idUsuario = idUsuario LIMIT 1;

5.2.2. Caso de uso: Modificar Usuario

En el caso de uso Modificar Usuario, distinguimos el proceso en dos fases:

Obtener datos de Usuario

Escogemos el patrón controlador para gestionar el evento externo ObtenerDatosUsuario. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorUsuarios. Además, esta clase artificial tiene acceso directo a todos los usuarios. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerDatosUsuario de GestorUsuarios accede a la tabla y obtiene los datos personales asociados al Usuario. Dependiendo del nivel de acceso de dicho usuario, el Sistema accederá a la tabla de clientes o de empleados, también contenidos en la clase artificial GestorUsuarios.

Finalmente, se devuelven los datos obtenidos a la interfaz de usuario.

qObtenerDatosCliente(idUsuario) = SELECT C.dni, C.nombre, C.apellidos, C.telefono, C.direccion, C.email, C.empresa, U.dniComercial FROM cliente AS C NATURAL JOIN usuario AS U WHERE C.idUsuario = idUsusario;

qObtenerDatosEmpleado(idUsuario) = SELECT E.dni, E.nombre, E.apellidos, E.telefono, E.direccion, E.email, E.master, U.usuario FROM empleado AS E NATURAL JOIN usuario AS U WHERE E.idUsuario = idUsuario;

Editar Datos Usuario

Escogemos el patrón controlador para gestionar el evento externo EditarDatosUsuario. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorUsuarios. Además, esta clase artificial tiene acceso directo a todos los usuarios. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método EditarDatosUsuario de GestorUsuarios accede a la tabla y guarda los datos personales asociados al Usuario, modificando los que ya existieran. Dependiendo del nivel de acceso de dicho usuario, el Sistema accederá a la tabla de clientes o de empleados, también contenidos en la clase artificial GestorUsuarios, para modificar los datos relacionados.

qUsuarioDatosEditar(datosUsuario) = UPDATE usuario AS U SET U.clave = clave WHERE U.idUsuario = idUsuario;

qUsuarioDatosEditarCliente(datosUsuario) = UPDATE cliente AS C SET C,nombre = nombre, C.apellidos = apellidos, C.telefono = tlf, C.email = email, C.empresa = empresa, C.direccion = dirección WHERE dni = dni;

qUsuarioDatosEditarEmpleado(datosUsuario) = UPDATE empleado AS E SET E.nombre = nombre, E.apellidos = apellidos, E.telefono = tlf, E.email = email, E.direccion = direccion WHERE E.dni = dniE;

5.2.3. Caso de uso: Gestionar Pedidos

Escogemos el patrón controlador para gestionar el evento externo ObtenerPedidos. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorPedidos. Además, esta clase artificial tiene acceso directo a todos los pedidos. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerPedidos de GestorPedidos accede a la tabla selecciona los pedidos asociados al Usuario.

Finalmente, se ordena la lista de pedidos descendientemente por fecha de realización.

qObtenerPedidos(idUsuario) = SELECT P.IdPedido, P.fecha, P.importe, P.estado FROM pedido AS P WHERE P.idUsuario = idUsusario

5.1.4. Caso de uso: Crear Pedido

Escogemos el patrón controlador para gestionar el evento externo CrearPedido. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorPedidos. Además, esta clase artificial tiene acceso directo a todos los pedidos y su relación de productos. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método CrearPedido de GestorPedidos accede a la tabla de pedidos y registra los datos del pedido.

Por el patrón experto, el método CrearPedido de GestorPedidos accede a la tabla de relación pedido-productos y guarda los productos asociados al pedido.

qCrearPedido(idPedido,idUsuario,idEmpleado) = INSERT INTO pedido AS P ( P,idUsuario, P.idEmpleado) VALUES (idUsuario,idEmpleado)

qCrearProductosPedido(idPedido,idProducto,num,importe) = INSERT INTO pedido-productos AS PP (PP.num,PP.importe) VALUES (num,importe)

5.1.5. Caso de uso: Modificar Pedido

En el caso de uso Modificar Pedido, distinguimos el proceso en dos fases:

Obtener datos del Pedido

Escogemos el patrón controlador para gestionar el evento externo ObtenerDatosPedido. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorPedidos. Además, esta clase artificial tiene acceso directo a todos los pedidos, así como su relación de productos asociados. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerDatosPedido de GestorPedidos accede a la tabla de pedidos y obtiene los datos del pedido.

Por el patrón experto, el método ObtenerDatosPedido de GestorPedidos accede a la tabla de relación pedido-productos y obtiene los productos asociados al pedido.

Finalmente, se devuelven los datos obtenidos a la interfaz de usuario.

qObtenerDatosPedido(idPedido) = SELECT P.idUsuario, P.idEmpleado FROM pedido AS P WHERE P.idPedido = idPedido;

qObtenerDatosProductosPedido(idPedido) = SELECT PP.idProducto, PP.num, PP.importe FROM pedido-productos AS PP WHERE PP.idPedido = idPedido

Modificar datos del Pedido

Escogemos el patrón controlador para gestionar el evento externo EditarPedido. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorPedidos. Además, esta clase artificial tiene acceso directo a todos los pedidos y su relación de productos. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método EditarPedido de GestorPedidos accede a la tabla de pedidos y modifica los datos del pedido.

Por el patrón experto, el método EditarPedido de GestorPedidos accede a la tabla de relación pedido-productos y modifica los productos asociados al pedido.

qEditarPedido(idPedido,idUsuario,idEmpleado) = UPDATE pedido AS P SET P,idUsuario = idUsuario, P.idEmpleado = idEmpleado WHERE P.idPedido = idPedido

qEditarProductosPedido(idPedido,idProducto,num,importe) = UPDATE pedido-productos AS PP SET PP,num = num, PP.importe = importe WHERE PP.idPedido = idPedido AND PP.idProducto = idProducto

5.1.6. Caso de uso: Gestionar Clientes

Escogemos el patrón controlador para gestionar el evento externo ObtenerClientes. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorClientes. Además, esta clase artificial tiene acceso directo a todos los clientes. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerClientes de GestorClientes accede a la tabla selecciona todos los clientes.

Finalmente, se ordena la lista de clientes descendientemente por orden de apellidos.

qObtenerClientes() = SELECT C.dni, C.idUsuario, C.nombre, C.apellidos, C.email FROM cliente AS C

5.1.7. Caso de uso: Crear Cliente

Escogemos el patrón controlador para gestionar el evento externo CrearCliente. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorCliente. Además, esta clase artificial tiene acceso directo a todos los clientes y sus datos de usuario relacionados. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método CrearCliente de GestorCliente accede a la tabla de usuarios y registra los datos del usuario.

Por el patrón experto, el método CrearCliente de GestorCliente accede a la tabla de clientes y guarda los datos del cliente.

qCrearUsuario(idUsuario,usuario,clave,idEmpleado) = INSERT INTO usuario AS U (U.idUsuario, U.usuario, U.clave, U.idEmpleado) VALUES (idUsuario, usuario, clave, idEmpleado)

qCrearCliente(idUsuario,dni,nombre,apellidos,email) = INSERT INTO cliente AS C (C.idUsuario, C.dni, C.nombre, C.apellidos, C.email) VALUES (idUsuario, dni, nombre, apellidos, email)

5.2.8. Caso de uso: Modificar Cliente

En el caso de uso Modificar Cliente, distinguimos el proceso en dos fases:

Obtener datos de Cliente

Escogemos el patrón controlador para gestionar el evento externo ObtenerDatosCliente. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorClientes. Además, esta clase artificial tiene acceso directo a todos los clientes y a los datos de usuarios asociados. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerDatosCliente de GestorClientes accede a la tabla y obtiene los datos personales asociados al cliente

Finalmente, se devuelven los datos obtenidos a la interfaz de usuario.

qObtenerDatosCliente(idUsuario) = SELECT U.nombre, U.clave, U.idEmpleado, C.dni, C.nombre, C.apellidos, C.telefono, C.direccion, C.email, C.empresa FROM usuario AS U NATURAL JOIN cliente AS C WHERE U.idUsuario = idUsuario LIMIT 1;

Editar Datos Cliente

Escogemos el patrón controlador para gestionar el evento externo EditarDatosCliente. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorClientes. Además, esta clase artificial tiene acceso directo a todos los clientes así como a los datos de usuario relacionados. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método EditarDatosCliente de GestorCliente accede a la tabla de usuarios y modifica los datos del usuario.

Por el patrón experto, el método EditarDatosCliente de GestorCliente accede a la tabla de clientes y modifica los datos del cliente.

qEditarDatosUsuario(idUsuario,usuario,clave,idEmpleado) = UPDATE usuario AS U SET U.usuario = usuario, U.clave = clave, U.idEmpleado = idEmpleado WHERE U.idUsuario = idUsuario;

qEditarDatosCliente(idUsuario,dni,nombre,apellidos,email) = UPDATE cliente AS C SET C,dni = dni, C,nombre = nombre, C.apellidos = apellidos, C.email = email WHERE C.idUsuario = idUsuario;

5.1.9. Caso de uso: Gestionar Productos

Escogemos el patrón controlador para gestionar el evento externo ObtenerProductos. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorProductos. Además, esta clase artificial tiene acceso directo a todos los productos. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerProductos de GestorProductos accede a la tabla selecciona todos los productos.

Finalmente, se ordena la lista de productos descendientemente agrupados por material y familia y ordenados por nombre.

qObtenerProductos() = SELECT P.idProducto, P.nombre, P.familia, P.material, P.familia, P.precio FROM producto AS P GROUP BY P.material, P.familia ORDER BY P.nombre

5.1.10. Caso de uso: Crear Producto

Escogemos el patrón controlador para gestionar el evento externo CrearProducto. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorProductos. Además, esta clase artificial tiene acceso directo a todos los productos. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método CrearProducto de GestorProductos accede a la tabla de productos y registra los datos del nuevo producto.

qCrearProducto(nombre,material,familia,precio) = INSERT INTO producto AS P (P.nombre, P.material, P.familia, P.precio) VALUES (nombre, material, familia, precio)

5.2.11. Caso de uso: Modificar Producto

En el caso de uso Modificar Producto, distinguimos el proceso en dos fases:

Obtener datos de Producto

Escogemos el patrón controlador para gestionar el evento externo ObtenerDatosProducto. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorProductos. Además, esta clase artificial tiene acceso directo a todos los productos. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerDatosProducto de GestorProductos accede a la tabla y obtiene los datos del producto

Finalmente, se devuelven los datos obtenidos a la interfaz de usuario.

qObtenerDatosProducto(idProducto) = SELECT P.nombre,P.material, P.familia, P.precio FROM producto AS P WHERE P.idProducto = idProducto LIMIT 1;

Editar Datos Producto

Escogemos el patrón controlador para gestionar el evento externo EditarDatosProducto. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorProductos. Además, esta clase artificial tiene acceso directo a todos los productos. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método EditarDatosProducto de GestorProductos accede a la tabla de productos y modifica los datos del producto.

qEditarDatosProducto(idProducto,nombre,material,familia,precio) = UPDATE producto AS P SET P.nombre = nombre, P.material = material, P.familia = familia, P.precio = precio WHERE P. idProducto = idProducto;

5.1.12. Caso de uso: Gestionar Empleados

Escogemos el patrón controlador para gestionar el evento externo ObtenerEmpleados. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorEmpleados. Además, esta clase artificial tiene acceso directo a todos los empleados. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerEmpleados de GestorEmpleados accede a la tabla selecciona todos los empleados.

Finalmente, se ordena la lista de empleados descendientemente por orden de apellidos.

qObtenerEmpleados() = SELECT E.dni, E.idUsuario, E.nombre, E.apellidos, E.email, E.admin FROM empleados AS E

5.1.13. Caso de uso: Crear Empleado

Escogemos el patrón controlador para gestionar el evento externo CrearEmpleado. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorEmpleados. Además, esta clase artificial tiene acceso directo a todos los empleados y sus datos de usuario relacionados. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método CrearEmpleado de GestorEmpleados accede a la tabla de usuarios y registra los datos del usuario.

Por el patrón experto, el método CrearEmpleado de GestorEmpleados accede a la tabla de empleados y guarda los datos del empleado.

qCrearUsuario(idUsuario,usuario,clave) = INSERT INTO usuario AS U (U.idUsuario, U.usuario, U.clave) VALUES (idUsuario, usuario, clave)

qCrearEmpleado(idUsuario,dni,nombre,apellidos,dirección,email,admin) = INSERT INTO empleados AS E (E.idUsuario, E.dni, E.nombre, E.apellidos, E.direccion E.email, E.admin) VALUES (idUsuario, dni, nombre, apellidos, dirección, email, admin)

5.2.14. Caso de uso: Modificar Empleado

En el caso de uso Modificar Empleado, distinguimos el proceso en dos fases:

Obtener datos de Empelado

Escogemos el patrón controlador para gestionar el evento externo ObtenerDatosEmpleado. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorEmpleados. Además, esta clase artificial tiene acceso directo a todos los empleados y a los datos de usuarios asociados. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método ObtenerDatosEmpleado de GestorEmpleados accede a la tabla y obtiene los datos personales asociados al empleado

Finalmente, se devuelven los datos obtenidos a la interfaz de usuario.

q ObtenerDatosEmpleado(idUsuario) = SELECT U.usuario, U.clave, E.dni, E.nombre, E.apellidos, E.telefono, E.direccion, E.email, E.admin FROM usuario AS U NATURAL JOIN empleado AS E WHERE U.idUsuario = idUsuario LIMIT 1;

Editar Datos Empleado

Escogemos el patrón controlador para gestionar el evento externo EditarDatosEmpleado. Aunque otras opciones son posibles, a falta de más información al tratarse de modelar un caso de uso, seleccionamos el controlador de caso de uso GestorEmpleados. Además, esta clase artificial tiene acceso directo a todos los empleados así como a los datos de usuario relacionados. Con ello pretendemos un diseño global con alta cohesión y bajo acoplamiento.

Por el patrón experto, el método EditarDatosEmpleado de GestorEmpleados accede a la tabla de usuarios y modifica los datos del usuario.

Por el patrón experto, el método EditarDatosEmpleado de GestorEmpleados accede a la tabla de empleados y modifica los datos del empleado.

qEditarDatosUsuario(idUsuario,usuario,clave) = UPDATE usuario AS U SET U.usuario = usuario, U.clave = clave WHERE U.idUsuario = idUsuario;

q EditarDatosEmpleado (idUsuario,dni,nombre,apellidos,dirección,email,admin) = UPDATE empleado AS E SET E,dni = dni, E,nombre = nombre, E.apellidos = apellidos, E.direccion = dirección, E.email = email E.admin = admin WHERE E.idUsuario = idUsuario;

5.3. Diseño de la capa de datos

En este punto detallaremos una por una la estructura de las tablas que forman la base de datos. Puesto que Cofundi Subestaciones no dispone de ningún tipo de base de datos relacionada con clientes, empleados ni productos, el diseño ha sido desde cero, pudiendo elegir yo mismo los campos que creía necesarios para cada función.

5.3.1. Tabla Usuario

figura : tabla de datos Usuario

5.3.2. Tabla Cliente

figura : tabla de datos Cliente

5.3.3. Tabla Empleado

figura : tabla de datos Empleado

5.3.4. Tabla Pedido

figura : tabla de datos Pedido

5.3.5. Tabla Producto

figura : tabla de datos Producto

5.3.6. Tabla PedidoProducto

figura : tabla de datos PedidoProducto

5.3.6. Tabla UsuarioEstados

figura : tabla de datos UsuarioEstados

5.3.6. Tabla PedidoEstados

figura : tabla de datos PedidoEstados

5.3.6. Tabla ProductoEstados

figura : tabla de datos ProductoEstados