2. OBJETIVOS DEL PROYECTO.
Los objetivos del proyecto realizado han sido varios. En resumidas palabras podemos decir que la idea ha sido crear un aplicativo riguroso para una empresa siguiendo los pasos principales de la Ingeniería de Software.
Todo esto conlleva a la creación de una documentación y un estudio de los requisitos del aplicativo, un análisis del aplicativo y un diseño del aplicativo.
Un segundo objetivo ha sido la creación de una interfaz de usuario robusta y clara que facilite al usuario el uso de dicho aplicativo.
Un tercer objetivo a sido ver que un aplicativo con una misma interfaz de usuario puede estar implementada de diferentes maneras y ver las principales diferencias entre ellas, en este caso el aplicativo se ha desarrollado con tecnología Java 1.4 usando la librería de Java
SWING que es la librería de componentes visuales más nueva que proporciona Java hasta el momento y la otra manera de implementarlo a sido usando JDBC.
Como parte innovadora y de investigación uno de los objetivos a sido la conexión de la interfaz de usuario del aplicativo usando JDBC que es el acrónimo de Java Database
Connectivity, un API que permite la ejecución de operaciones sobre bases de datos desde el
lenguaje de programación Java utilizando el dialecto SQL. Para la conectividad se ha usado un driver de Apache SQL.
En resumen lo que se ha intentado con este proyecto a sido abarcar una serie de conocimientos adquiridos con las diferentes asignaturas (como Programación 1 y 2, Lenguajes de Programación, Bases de Datos, Ingeniería de Software y Gestión de la Informática de la carrera de Ingeniería Informática de Gestión).
3. ESPECIFICACIÓN DEL PROYECTO.
El tema del proyecto realizado ha sido la implementación de un aplicativo Java orientado a objetos y en JDBC en el que se implementa el comportamiento de una agencia de transportes de personas.
Gracias a la nueva construcción de una Terminal de transporte con pistas de avión, comunicada por autobús y tren en las afueras de Tarragona una conocida empresa de transportes de Tarragona nos a pedido la realización de un aplicativo para la venta de billetes, esta agencia dispone de varias pistas de aterrizaje y un tren que va desde dicha Terminal a las ciudades más importantes de Tarragona (Reus, Tarragona, etc.) La agencia también dispone de un servicio de autobús para todos estos clientes ya que es más económico que el tren pero algo más lento.
La agencia de transportes la llamaremos Agencia de Transportes URV. En esta agencia se desarrolla una actividad de transporte de personas de un origen a un destino.
La agencia dispone de dos tipos de personal el encargado y el vendedor, el encargado es la persona que se hace cargo de las altas, bajas y modificaciones de transportes que ofrece la agencia a los clientes. El encargado también dispone de la posibilidad de consultar los datos de una persona en concreto mediante un identificador único de cada cliente, el resultado de esta consulta será una lista con los datos del cliente y los viajes que ha realizado con la Agencia de Transportes URV.
El vendedor es la persona que se encarga de la venta de billetes, así como de dar información a los clientes de los viajes disponibles en la agencia, y el vendedor tiene autorización para dar de alta a los clientes, modificar sus datos e incluso dar de baja de la agencia a clientes. El vendedor en todo momento puede obtener una lista de todos los clientes de la agencia.
Por último el cliente también participa en el uso del aplicativo mediante unos cajeros informatizados donde el cliente podrá comprar los billetes que a él le interese sin tener que pasar por cola todo ello de forma automatizada. Los clientes podrán darse de alta pero en ningún momento modificar sus datos ni darse de baja. Todo cliente podrá consultar los transportes disponibles de la agencia introduciendo un origen y un destino además de poder comprar un billete introduciendo su identificador y el código de transporte que desea
Los datos que interesan a la agencia de transportes son los siguientes, de cada cliente interesa saber su DNI, su nombre y apellidos su fecha de nacimiento y los kilómetros que ha realizado en la agencia. Los datos de interés de un transporte son: el código de transporte, el origen, el destino, la distancia, el precio del billete y el tipo de transporte; en este caso la agencia dispone de la venta de billetes de autobús, tren, y avión.
La agencia nos ha pedido un aplicativo que permita la persistencia de datos y el control de todo el flujo de información comentado anteriormente.
DOCUMENTACIÓN DE REQUISITOS.
4. DISEÑO.
4.1. CONTEXTO DEL APLICATIVO.
4.1.1. Concepto de documentación de requisitos.
Concepto: Decimos que los requisitos son la especificación de aquello que tiene que hacer el aplicativo final o programario, son descripciones del comportamiento, propiedades y restricciones, todo esto nos tiene que ayudar a formar una idea clara del producto final.
Hay que decir que la fuente de los datos de los requisitos son las entrevistas con los usuarios finales del aplicativo así como documentaciones ya existentes y sistemas parecidos.
La documentación de requisitos pretende servir como la base de un acuerdo entre el cliente que pide el aplicativo y los desarrolladores. En conclusión la parte de requisitos ha de ser un documento que puedan entender los clientes, ya que son ellos los que tendrán que revisar el documento.
Una pequeña dificultad añadida para los desarrolladores es que muchas veces no conocen la actividad de la empresa de la cual han de desarrollar el aplicativo, cosa que hace más difícil entender las peticiones del cliente. Para ello existen unas técnicas de recogida de información.
● Principalmente observar a los usuarios desarrollando su trabajo, escucharlos y hablar con ellos ya que de esta manera podemos estar seguros de que no se nos escapa nada importante ya que gran parte de la información que para el desarrollador es importante puede no serlo para el cliente.
● Entrevistar a los usuarios con el fin de obtener mucha más información como quien hace una tarea concreta, con que frecuencia se hace y con que dificultades se encuentran en su trabajo.
● Una técnica importante es la recogida de documentos y listados de la empresa, ya que pueden ser con datos reales o datos ficticios para respetar la privacidad de la empresa. Estos documentos son importantes ya que en ellos están representados los datos que se consideran más importantes.
● Las visitas es una parte importante dentro de los requisitos y hay que planificarlas bien y definir bien cual es el objetivo de la visita y ante todo elegir representantes que realmente usen el aplicativo final.
La planificación temporal es una de las partes más “espinosas” ya que el cliente en algunos casos le gustaría tener el producto lo antes posible y muchas veces durante el periodo de visitas y prueba se hacen falsas ideas del aplicativo ya que no es el resultado final. Muchas veces hay retrasos ya que puede ser que un programador se retire del
Por lo tanto podemos observar que el desarrollo de un aplicativo no es nada trivial, depende de muchos factores.
4.1.2. Modelo del dominio.
En principio sabemos que en el modelo del dominio se identifican las clases que corresponden a cosas del mundo real donde tiene lugar la actividad de la empresa y estas clases son: Cliente, Transporte y Viaje
4.1.3. Modelo del negocio.
4.1.3.1. Diagrama de clases del negocio.
En el modelo del negocio introduciremos las clases en las cuales se maneja información referente al negocio partiendo de una información muy superficial se identifican y se describen las principales clases que son: Cliente, Transporte, Viaje, e Histórico.
En este diagrama las clases llevan las funciones principales sin atributos, no es necesario poner los atributos ya que este diagrama no se usara para el desarrollo del aplicativo
4.1.3.2. Casos de Uso del negocio.
Los casos de uso del negocio los identificaremos como toda tarea autónoma correspondiente a un actor o lo que es lo mismo un usuario, pero hay que considerar que puede haber un caso de uso que no corresponda a ninguna tarea por el motivo de que su actor no sea un usuario y por lo tanto lo consideraremos como un requisito no funcional de proceso en lugar de una parte de la interfaz de usuario.
Los actores son los siguientes: Vendedor, Encargado y Cliente ya que todos estos interactuaran de alguna forma con el aplicativo final. Por lo contrario, el sistema que realiza varias tareas de actualización no es un usuario.
4.2. INFORMACIÓN RECOGIDA SOBRE LOS REQUISITOS DEL APLICATIVO. 4.2.1. Resumen del trabajo que han de realizar los usuarios.
Altas, bajas y modificaciones de transportes.
Una vez que el encargado recibe la lista de Orígenes y Destinos del día se encarga de introducir en la base de datos los orígenes y destinos así como la distancia en kilómetros y la hora de salida y el tipo de transporte, ya sea avión tren o autobús.
Altas, bajas y modificaciones de clientes.
El vendedor es el encargado de hacer las bajas altas y modificaciones de clientes, el vendedor pedirá el DNI, nombre y apellidos, y hará las modificaciones que el cliente le pida.
Consulta de transportes.
Los clientes y vendedores pueden acceder a la información de los desplazamientos en cualquier momento desde un Terminal introduciendo el origen y destino al que quieren llegar, si existen transportes en la agencia con esas características se mostrarán.
Consulta de histórico
Los encargados son los que pueden acceder a estos datos a partir del DNI del cliente ya que una vez al mes crean una estadística con los datos obtenidos y que mandan a la empresa de transportes. Los datos que se muestran son los datos de cliente, nombre, apellido, fecha de nacimiento, y kilómetros recorridos además de los transportes que ha utilizado en la agencia.
Comprar billete
Los clientes interesados pueden comprar su billete indicando su DNI y el código del transporte que desean.
Listado de Cliente
Se trata de poder obtener una lista de todos los clientes de la agencia.
4.2.2. Los guiones.
Una vez hechas las entrevistas con los diferentes tipos de usuarios del sistema, se tienen los siguientes guiones.
El guión del encargado:
Cada día se le pasa al encargado una lista de los viajes disponibles en ese día, de los cuales él introduce en la base de datos el código de vuelo, la distancia, el origen de partida y el destino y el tipo de transporte. Él se encarga de suprimir de la base de datos los viajes o desplazamientos obsoletos. El encargado puede consultar el histórico en cualquier momento.
El guión de vendedor
El vendedor pide la identificación al cliente en caso de no estar introducido en la base de datos, el vendedor dará de alta al cliente poniendo su DNI, nombre, apellidos y fecha de nacimiento.
Una vez introducidos los datos el cliente dirá el origen y el destino al que quiere ir y de una lista de posibles resultados elegirá el que más le convenga y así efectuará la compra de su billete.
El vendedor puede pedir una lista de todos los clientes de la agencia.
El guión del Usuario
El usuario puede comprar su billete sin necesidad de pasar por taquilla una vez esté introducido en la base de datos comprando su billete por un Terminal o Internet, los datos que se le requerirán serán su DNI, y nombre, un origen y un destino y dada una lista de resultados, él podrá elegir el que más le convenga.
4.2.3. Vocabulario del dominio y del negocio.
Es bueno tener una referencia a palabras del dominio y del negocio ya que la persona o el grupo de personas que realizan el aplicativo deben tener el máximo conocimiento del funcionamiento del negocio para una correcta funcionalidad de este mismo.
Cliente: Persona que hace uso del transporte para desplazarse de una ciudad a otra o dentro de la misma ciudad.
Vendedor: Persona que se encarga de facilitar los billetes a los clientes y darles de alta.
Encargado: Persona que se encarga de fijar los precios y los viajes disponibles de una ciudad a otra.
Viaje: Desplazamiento de una ciudad a otra o dentro de la misma.
Histórico: Lugar físico donde guardar los datos del cliente y sus viajes.
Agencia: Empresa dedicada al transporte de personas.
Transporte: Medio de locomoción en el que se desplazarán los clientes. Hay tres tipos en la agencia: avión, autobús y tren.
4.3. DOCUMENTACIÓN DE LOS REQUISITOS DE LA INTERFAZ USUARIO. 4.3.1. Requisitos funcionales de la interfaz del usuario.
4.3.1.1. Estructura de metas.
4.3.1.2. Descripción de las tareas.
Tareas del Encargado Crear viaje
Meta: Añadir un viaje en la base de datos.
El encargado da los datos del tipo de transporte (avión, tren, autobús), el código identificador, los kilómetros, el origen, el destino y el precio.
Tareas del Vendedor Crear cliente
Meta: Añadir un cliente en la base de datos.
El encargado introduce el DNI, nombre , apellidos y fecha de nacimiento del usuario. Vender viaje
Meta: Realizar la venta de un viaje.
El vendedor pide los datos del cliente, si no está en la base de datos crea el cliente luego selecciona el tipo de transporte, el origen y destino. El vendedor le ofrece de una lista de posibles transportes indicando su precio y distancia y el cliente elige la que más le convenga.
Consulta de viajes
Meta: encontrar un transporte adecuado para el cliente.
El vendedor introduce un origen y un destino y el aplicativo devuelve una lista de todos los posibles transportes indicando la distancia, y el precio.
Listado de clientes
Meta: elaborar una lista de todos los clientes de la agencia.
El vendedor puede pedir en cualquier momento una lista de clientes.
Tareas del cliente Buscar viaje
Meta: Encontrar el viaje que busca el cliente.
El cliente puede consultar los viajes disponibles ya sea en el panel informatizado de viajes o en una Terminal. Se mostrarán los viajes disponibles para cada transporte. Comprar viaje
Meta: Realizar la compra de un viaje.
El cliente introduce sus datos luego selecciona el tipo de transporte, el origen y el destino. El vendedor o el Terminal le ofrece una lista de posibles opciones y el cliente elige la que más le conviene.
Crear cliente
Meta: Añadir un cliente en la base de datos.
El cliente introduce el DNI, nombre, apellidos y fecha de nacimiento,de esta manera queda introducido en la base de datos.
4.3.1.4. Descomposición de las tareas en subtareas. Identificarse en el aplicativo.
El encargado y el vendedor tienen que identificarse en el sistema antes de poder acceder al sistema ya que son ellos los que pueden modificar la información del aplicativo.
Crear, modificar y eliminar Transportes.
Para poder crear modificar y eliminar un transporte, el encargado tiene que introducir una serie de datos como son: el código, el origen, el destino, la distancia, el precio y el tipo de transporte entre ese origen y destino, en el caso de modificar o eliminar un transporte la precondición es que ese transporte esté creado.
Introducir, modificar y eliminar un cliente.
Para poder introducir un cliente necesitamos los datos DNI y nombre, por lo tanto introducir cliente se descompondrá en esas dos acciones. Para poder modificarlo es necesario introducir el DNI y el nombre, para eliminarlo solo bastará con el DNI y la precondición que en la modificación y eliminación el cliente exista en la base de datos.
Consultar Origen y Destino tanto en el caso como de consulta de cliente o vendedor.
4.3.1.5. El Modelo de la información.
Diagramas de estados de los recursos de información Cliente, Transportes, Viaje e Histórico.
Diagramas de estados del recurso de información Cliente.
Diagramas de estados del recurso de información: Transportes.
4.4. DOCUMENTACIÓN DE LOS REQUISITOS DE PROCESO. 4.4.1. Requisitos funcionales de proceso.
4.4.1.2. Especificación textual de los casos de uso. Caso 1: Altas de Transportes
Resumen de la funcionalidad: introduce un código identificador, un origen y destino
con su distancia, el tipo de transporte y precio en la base de datos.
Actor: El encargado.
Casos de uso relacionados: Crear Viaje, Consultar Transportes, Modificar Transportes
y Eliminar Transportes.
Precondición: El código de Transporte a introducir no ha de existir en la base de
datos.
Postcondición: Los datos del viaje están introducidos en la base de datos. Proceso normal principal:
● El encargado introduce en la base de datos el código, los datos del origen, el destino, la distancia el precio y el tipo de transporte.
● El sistema guarda los datos introducidos en la base de datos.
Alternativas de proceso y excepciones:
1a. El código del viaje existe en la base de datos.
1a1. El sistema crea un mensaje de error y cancela la introducción de datos.
Caso 2: Modificar Transportes
Resumen de la funcionalidad: introduce un código identificador, un origen y destino
con su distancia, tipo de transporte y precio en la base de datos.
Actor: El encargado.
Casos de uso relacionados: Crear Viaje, Consultar transportes. Precondición: El Transportes tiene que existir en la base de datos.
Postcondición: Los datos del viaje están modificados en la base de datos. Proceso normal principal:
● El encargado introduce en la base de datos los datos modificados del origen, el destino, la distancia, el precio y el tipo de transporte.
● El sistema guarda los datos introducidos en la base de datos.
1a. El código del viaje no existe en la base de datos:
1a1. El sistema crea un mensaje de error y cancela la introducción de datos.
Caso 3: Eliminar Transportes
Resumen de la funcionalidad: introduce un código identificador y el sistema se encarga
de eliminar de la base de datos el Origen y Destino, el precio, distancia, etc de ese transporte en particular.
Actor: El encargado.
Casos de uso relacionados: Crear Viaje, Consultar transportes. Precondición: El Transportes tiene que existir en la base de datos. Postcondición: Los datos del viaje están eliminados de la base de datos. Proceso normal principal:
● El encargado introduce el código del Transporte. ● El sistema elimina los datos de ese Transporte.
Alternativas de proceso y excepciones:
1a. El código del viaje no existe en la base de datos:
1a1. El sistema crea un mensaje de error y cancela la introducción de datos.
Caso 4: Consultar Histórico
Resumen de la funcionalidad: El encargado consulta los viajes que ha hecho un cliente
en concreto.
Actor: El encargado.
Casos de uso relacionados: Crear Viaje. Precondición: Ninguna
Postcondición: Devuelve los datos de los viajes realizados. Proceso normal principal:
● El encargado introduce el DNI del cliente a consultar.
● El sistema muestra todos los datos del cliente y los kilómetros que ha hecho con la agencia.
1a. El DNI del Cliente no existe en la base de datos:
1a1. El sistema crea un mensaje de error y cancela la introducción de datos.
Caso 5: Crear Cliente
Resumen de la funcionalidad: Introducir un cliente en la base de datos. Actor: El Vendedor y el Cliente.
Casos de uso relacionados: Vender Viaje, Crear Viaje. Precondición: Cliente no introducido en la base de datos. Postcondición: El cliente esta introducido en la base de datos. Proceso normal principal:
● El vendedor o cliente introduce el DNI del cliente su nombre, apellidos y fecha de nacimiento.
● El sistema introduce los datos del cliente en la base de datos.
Alternativas de proceso y excepciones:
1a. El DNI del Cliente ya existe en la base de datos:
1a1. El sistema crea un mensaje de error y cancela la introducción de datos.
Caso 6: Modificar Cliente
Resumen de la funcionalidad: introduce un DNI identificador, y cambiar los datos de
un cliente en particular.
Actor: El vendedor.
Casos de uso relacionados: Crear Viaje, Consultar clientes. Precondición: El cliente tiene que existir en la base de datos.
Postcondición: Los datos del cliente están modificados en la base de datos. Proceso normal principal:
● El vendedor introduce en la base de datos los datos modificados del cliente, el nombre y apellido.
● El sistema guarda los datos introducidos en la base de datos.
1a1. El sistema crea un mensaje de error y cancela la introducción de datos.
Caso 7: Eliminar Cliente
Resumen de la funcionalidad: introducido un DNI identificador se elimina el cliente
con ese DNI de la base de datos.
Actor: El vendedor.
Casos de uso relacionados: Crear Viaje, Consultar clientes. Precondición: El cliente tiene que existir en la base de datos.
Postcondición: Los datos del cliente están eliminados de la base de datos. Proceso normal principal:
● El vendedor introduce en la base de datos el DNI del cliente. ● El sistema elimina a ese cliente de la base de datos.
Alternativas de proceso y excepciones:
1a. El DNI del cliente no existe en la base de datos:
1a1. El sistema crea un mensaje de error y cancela la introducción de datos.
Caso 8: Consulta de Transportes
Resumen de la funcionalidad: El encargado consulta los viajes que ha hecho un cliente
en concreto.
Actor: El Vendedor o el Cliente.
Casos de uso relacionados: Vender Viaje, Crear Viaje.
Precondición: Por lo menos un Transporte introducido en la base de datos. Postcondición: Devuelve una lista de Transportes.
Proceso normal principal:
● El vendedor o cliente hace la consulta de Transportes.
● El sistema el sistema devuelve una lista de los transportes disponibles.
Alternativas de proceso y excepciones:
1a. No hay ningún transporte en la base de datos: 1a1. El sistema crea un mensaje de error.
Caso 9: Venta Billete
Resumen de la funcionalidad: El Vendedor vende un billete. Actor: Vendedor.
Casos de uso relacionados: Actualizar Histórico.
Precondición: Transporte deseado disponible en la base de datos y el cliente que quiere
comprar el billete ha de estar introducido en la base de datos.
Postcondición: Histórico actualizado con el viaje del cliente. Proceso normal principal:
● El Vendedor introduce el origen, el destino, el código de transporte y el DNI del cliente.
● El Vendedor confirma la compra. ● El sistema actualiza el histórico.
Alternativas de proceso y excepciones:
1a. El fichero Histórico no se encuentra
1a1. El sistema devuelve un mensaje de error. 1b. El cliente no existe en la base de datos.
1b1. El sistema devuelve un mensaje de error. 1c. El Transporte deseado no existe.
1c1. El sistema devuelve un mensaje de error. Caso 10: Comprar Viaje
Resumen de la funcionalidad: El Cliente compra un billete. Actor: Cliente.
Casos de uso relacionados: Actualizar Histórico.
Precondición: Transportes deseado disponible en la base de datos y el cliente que quiere
comprar el billete ha de estar introducido en la base de datos.
Postcondición: Histórico actualizado con el viaje del cliente. Proceso normal principal:
● El Cliente introduce el origen, el destino, el código de transporte y el DNI del cliente.
● El Cliente confirma la compra. ● El sistema actualiza el histórico.
1a. El fichero Histórico no se encuentra
1a1. El sistema devuelve un mensaje de error. 1b. El cliente no existe en la base de datos.
1b1. El sistema devuelve un mensaje de error. 1c. El Transportes deseado no existe.
1c1. El sistema devuelve un mensaje de error. Caso 11: Listar Clientes
Resumen de la funcionalidad: El Vendedor puede obtener una lista de clientes de la
base de datos.
Actor: Vendedor .
Casos de uso relacionados: Crear Cliente, Modificar Cliente.
Precondición: Al menos un cliente ha de estar introducido en la base de datos. Postcondición: Ninguna.
Proceso normal principal:
● El Vendedor inicia el caso de uso. ● El sistema muestra una lista de clientes.
Alternativas de proceso y excepciones:
1a. No existe ningún cliente en la base de datos.
1a1. El sistema devuelve un mensaje de error.
4.4.2. Requisitos no funcionales de proceso.
Cada vez que un cliente compra un viaje o un vendedor vende un viaje, el sistema tiene que actualizar el histórico con los datos de dicho viaje.
4.4.3. Glosario de los requisitos.
Encargado: es la persona que se encarga de organizar los desplazamientos posibles de personas.
Vendedor: es un empleado de la empresa que ofrece un servicio de venta de billetes. Histórico: es un fichero donde se guardan los datos de los clientes que realizan vuelos con la agencia.
Código: cada desplazamiento posible está identificado por un código para ser diferenciado de los demás.
Cliente: es la persona que utiliza las instalaciones de la agencia.
Transporte: este término se refiere a los Orígenes y Destinos que están disponibles por algún tipo de transporte disponible que hay en la agencia, ya sea tren, autobús o avión.
ANÁLISIS DE LOS REQUISITOS.
4.5. ANÁLISIS DE LA INTERFAZ DE USUARIO.
4.5.1. Concepto de análisis de requisitos.
La documentación de requisitos ha estado la base de un acuerdo entre el usuario o los usuarios y el desarrollador, cosa que implica que el documento está realizado de forma sencilla y fácil de entender.
Pero el documento de requisitos no es un documento que nos sirva para comenzar a desarrollar el aplicativo ya que no están especificados los temas más importantes como clases, herencias y notaciones formales. Por lo tanto, una vez aceptados los requisitos (por las dos partes, cliente y desarrollador) se pasan estos requisitos a un nuevo modelo llamado modelo de análisis de requisitos o análisis de requisitos. Este documento, mucho más formal, ya nos sirve para empezar a realizar la base del diseño.
Los objetivos del análisis de requisitos son elaborar la metáfora, identificar las clases principales que serán la base del diseño de la implementación del programario y la especificación de los casos de uso en términos de operaciones.
4.5.2. La metáfora.
La metáfora está constituida por objetos gráficos que representan los recursos de información que tratará el aplicativo y las acciones que se harán sobre estos objetos gráficos que representan las acciones que hace el usuario con esas entidades (clases) o recursos de información.
Se van a mostrar los tipos de metáfora para el Cliente, el Transporte y el Viaje. Metáfora del cliente
Metáfora del Transporte
Metáfora de Viaje
4.6. LAS CLASES DEL ANÁLISIS. 4.6.1. Las clases de entidad.
4.6.1.1. Identificación de las clases de entidad.
Se procederá a identificar las clases del aplicativo final a partir de los casos de uso. Cada caso de uso esta relacionado con una o varias clases
Caso de uso 1: Altas de Transporte: OrigeDestino Caso de uso 2: Modificar Transporte: Transporte Caso de uso 3: Eliminar Transporte: Transporte Caso de uso 4: Consultar Histórico: Histórico Caso de uso 5: Crear Cliente: Cliente
Caso de uso 6: Modificar Cliente: Cliente Caso de uso 7: Eliminar cliente: Cliente
Caso de uso 8: Consultar Transporte: Transporte Caso de uso 9: Venta de billete: Viaje
Caso de uso 10: Compra de billete: Viaje Caso de uso 11: Listar Clientes: Cliente
4.6.1.2. Especificación de los atributos de las clases de entidad.
Cliente: D.N.I (string), Nombre (String), Apellidos (String), Distancia (Real) Viaje: D.N.I (String), Código (String)
Transporte: Código (String), Origen (String), Destino (String), Distancia (Real), Precio (Real)
4.6.1.3. Clases de entidad.
En el siguiente esquema se puede observar las clases de entidad del aplicativo a desarrollar.
4.6.1.4. Asociaciones.
Siempre que los objetos de una clase necesitan la colaboración de los objetos de otra clase para poder llevar a cabo sus funciones, decimos que entre las dos clases hay una asociación tal y como podemos observar entre Transporte, Cliente y Viaje.
4.7. DIAGRAMAS DE CLASES DE LOS CASOS DE USO.
En el funcionamiento de cada caso de uso intervienen tres tipos de clases: las clases de entidad, las clases de frontera y las clases de control.
Una manera simple de explicar la función de cada una de las clases es la siguiente: ● Las clases de entidad contienen los datos.
● Las clases de frontera representan los flujos de entrada y salida E/S. ● Las clases de control implementan la lógica de los casos de uso.
La notación de cada clase es la siguiente:
En todos los casos de uso se introduce una clase de frontera llamada menú, su función es crear un objeto de clase de control.
Caso de uso 2: Modificar Transporte
Caso de uso 3: Eliminar Transporte
Caso de uso 5: Crear Cliente
Caso de uso 6: Modificar cliente
Caso de uso 8: Consultar Transporte
Caso de uso 10: Compra de billete
4.8. ESPECIFICACIÓN FORMAL DE LOS CASOS DE USO. 4.8.1. Diagramas de robusteza de los casos de uso.
Un paso interesante antes de hacer los diagramas de secuencia es elaborar los diagramas de robusteza, que son en el fondo diagramas de colaboración de la implementación de un caso de uso en términos de las clases de frontera de control y de entidad.
La finalidad del diagrama de robusteza del caso de uso no es describir de manera formal y detallada el proceso, sino construir una base para poder hacerlo. Ese es el motivo de que una vez realizados los diagramas de secuencia estos dejen de tener utilidad. Caso de uso 1: Altas de Transporte
Caso de uso 3: Eliminar Transporte
Caso de uso 5: Crear Cliente
Caso de uso 6: Modificar cliente
Caso de uso 8: Consultar Transporte
Caso de uso 10: Compra de billete
4.9. DIAGRAMAS.
4.9.1. Diagramas de secuencia.
Un forma concisa de explicar que es un diagrama de secuencia, sería decir que es la implementación de un caso de uso con un actor primario el cual manda un mensaje a una clase de frontera que es común a todos los actores y que llamaremos (Menú) a la que se le pide la ejecución de una operación. Esta operación envía un mensaje que crea un objeto de clase de control la cual puede:
● Enviar mensajes que creen objetos de clase de frontera.
● Enviar mensajes a clases de entidad, para leer o grabar objetos.
● Enviar mensajes que creen objetos de la clase de control ,los cuales tengan dependencias de include y extend.
Caso de uso 1: Altas de Transporte
Caso de uso 3: Eliminar Transporte
Caso de uso 4: Consultar Histórico
Caso de uso 6: Modificar cliente
Caso de uso 8: Consultar Transporte
Caso de uso 9 y 10: Venta de billete y Compra de billete
El caso de uso compra de billete es igual al de venta de billete lo único que cambia es que el actor es el cliente.
Caso de uso 11: Listar Clientes
DISEÑO.
4.10. DISEÑO DE LA INTERFAZ DE USUARIO.
4.10.1. Diagramas de estado de los menús.
En este aplicativo se considera que hay diferentes tipos de menú según el tipo de usuario que dará uso al aplicativo.
4.10.2. Diagrama de estados del menú del encargado.
El menú del encargado corresponde a la representación de 4 casos de uso, alta, baja, y modificación de transporte así como la consulta de histórico, a todos estos casos de uso se llega desde el menú del encargado y el botón "Aceptar" que solo se activa una vez están todos los datos completos. La ayuda se puede consultar desde los 4 casos de uso.
4.10.3. Diagrama de estados del menú del cliente.
El menú del cliente corresponde a la representación de 3 casos de uso, alta de cliente, compra de billete y consulta de transporte, a todos estos casos de uso se llega desde el menú del cliente y el botón "Aceptar" que solo se activa una vez están todos los datos
El menú del vendedor podemos decir que es el más complejo y llegamos a él desde el menú principal, está compuesto por 6 casos de uso, alta de cliente, modificación de cliente, baja de cliente, consultar transporte, listar clientes y venta de billete. En todos estos casos de uso se puede llegar a la ayuda .
4.11. DISEÑO DETALLADO DE LA INTERFAZ DE USUARIO.
4.11.1. Pautas y estilo de la interfaz de usuario.
El diseño de la interfaz de usuario es la categoría de diseño que crea una comunicación entre el usuario y la máquina, una pauta del diseño es identificar los objetos y acciones de la interfaz de usuario y crear un formato de pantalla que será la base del prototipo de interfaz de usuario.
Una pauta muy importante a seguir es que si la interfaz es difícil de utilizar, si obliga a cometer errores al usuario o causa frustración a la hora de conseguir los objetivos, lo más probable es que no sea una interfaz de agrado para el usuario independientemente de la potencia informática que demuestre el aplicativo, y en muchos casos puede haber un rechazo total por parte del usuario, por lo tanto, como la interfaz de usuario es la forma de percepción del usuario tiene que estar muy bien diseñada.
Por lo tanto, resumidamente, las pautas que se han seguido en este aplicativo han sido la identificación de los requisitos del usuario, de las tareas y del entorno. Una vez hecho esto, se crean las tareas, se analizan los escenarios para definir el conjunto de objetos y acciones de la interfaz.
Las pautas anteriores más la colocación de iconos, la definición del texto descriptivo en pantalla, los títulos de pantalla y la especificación de elementos principales y
secundarios del menú es lo que forma la base para la creación del formato de pantalla. Para que una interfaz tenga aceptación completa por parte de uno o varios usuarios se podría definir en tres reglas muy importantes:
● Dar el control de la interfaz al usuario. ● Reducir la carga de memoria del usuario.
● Construir una interfaz consecuente con el trabajo que va a desempeñar. Como último apunte a modo introductorio, comentar las pautas del proceso de diseño de la interfaz de usuario de la Agencia de Transportes.Estas pautas tienen la propiedad de ser un proceso iterativo y se puede representar mediante un modelo en espiral.
● Análisis y modelado de usuarios, tareas, y entornos. ● Diseño de la interfaz.
● Implementación de la interfaz. ● Validación de la interfaz.
Véase un ejemplo:
4.11.2. Diseño formal de los formatos de pantalla.
Para la inserción de un cliente en la Agencia tenemos que introducir el DNI,
Nombre, Apellidos, y la Fecha de nacimiento. Hay que rellenar todos los campos ya que si no es así no podremos seguir adelante, una vez rellenados los campos,
podemos dar al botón “Aceptar” y los datos del cliente se introducirán siempre y cuando el cliente no exista previamente en la Agencia. Si decidimos no introducir el cliente podemos cancelar la operación en cualquier momento, además de poder consultar la ayuda cuando sea necesario.
La modificación de cliente implica varios pasos, previamente el botón “Aceptar” está desactivado y solo tendremos un campo activo que es el DNI. Para modificar el cliente introduciremos el DNI, buscaremos el cliente y solo si existe se mostraran los datos del cliente y los campos que antes estaban desactivados y el botón “Aceptar” pasarán a estar activos. El botón “Buscar cliente” se desactiva, de esa manera ya se pueden modificar los datos del cliente y aceptar los cambios o cancelar la operación, una vez modificado el cliente o cancelada la modificación el botón “Aceptar” de desactiva de nuevo y pasa a estar activo solo el campo DNI.
Inicialmente solo tenemos activo el campo DNI, para eliminar el cliente primero hay que buscarlo con el botón “Buscar” cliente, si el cliente existe se activará el botón “Aceptar” y se desactiva el botón “Buscar” cliente, se mostrarán sus datos pero en ningún momento se podrán modificar ya, una vez seguros de que queremos eliminar ese cliente podemos eliminarlo con el botón “Aceptar” o cancelar la eliminación, volviendo al estado inicial.
Para la inserción de un transporte en la Agencia tenemos que introducir el código, origen, destino, distancia, precio y tipo de transporte. Hay que rellenar todos los campos ya que si no es así no podremos seguir adelante. Una vez rellenados los campos,
podemos dar al botón “Aceptar” y los datos del transporte se introducirán siempre y cuando el transporte no exista previamente en la Agencia. Si decidimos no introducir el transporte podemos cancelar la operación en cualquier momento, además de poder consultar la ayuda cuando sea necesario.
Modificar un transporte implica varios pasos: previamente el botón “Aceptar” está desactivado y solo tendremos un campo activo que es el código; para modificar el transporte introduciremos el código, buscaremos el transporte y solo si existe se mostrarán los datos y los campos que antes estaban desactivados y el botón “Aceptar” pasará a estar activo y el botón “Buscar” cliente se desactiva de esa manera ya se pueden modificar los datos del transporte y aceptar los cambios o cancelar la operación. Una vez modificado el transporte o cancelada la modificación, el botón “Aceptar” se desactiva de nuevo y pasa a estar activo solo el campo Código.
Inicialmente solo tenemos activo el campo Código. Para eliminar un transporte primero hay que buscarlo con el botón “Buscar transporte”, si el transporte existe se activará el botón “Aceptar” y se desactiva el botón “Buscar transporte”, se mostrarán sus datos pero en ningún momento se podrán modificar ya, una vez seguros de que queremos eliminar ese transporte podemos eliminarlo con el botón “Aceptar” o cancelar la eliminación, volviendo al estado inicial.
La compra o venta de billete se puede hacer buscando previamente un transporte con el origen y destino deseado o directamente si ya se conoce el código del transporte.
Para realizar la compra o la venta hay que introducir un DNI que exista en la Agencia y un código de transporte que exista en la agencia, de esa manera y apretando el botón “Aceptar” se hace una compra o venta de billete de transporte.
Para la consulta de un transporte introduciremos un origen y un destino al que se quiere llegar, apretando el botón “Aceptar” se muestra una lista de resultados con los transportes que hay disponibles para el origen y destino mostrando su tipo su
precio y distancia además de su código de transporte. Siempre se puede cancelar la operación y además se puede limpiar el listado para nuevas consultas.
Inicialmente solo tenemos activo el campo DNI. Para hacer la consulta de un histórico de cliente solo tenemos que apretar el botón “Aceptar” y todos los datos del cliente se mostrarán en los campos correspondientes además de la lista de transportes que ese cliente ha utilizado. En el campo distancia se mostrarán todos los kilómetros que ha realizado el cliente con la agencia
Pantalla modal de error.
Esta es la pantalla modal de error que nos encontraremos en los momentos que se produzca un error, esta pantalla es genérica lo que quiere decir que cada vez que se produzca el error, en el espacio de texto nos saldrá una explicación del error.
4.11.3. Diseño de la persistencia.
Base de datos relacional.
Por lo tanto las tablas serán la siguientes: ● transporte
- columnas:código, origen, destino,distancia, precio, tipo - primary key :codigo
● cliente
- columnas: dni, nombre, apellidos, fecha, distancia - primary key: dni
● viaje
-columnas: dni, código - foreng key: dni, código
5. DESARROLLO.
5.1. DESARROLLO DEL APLICATIVO ORIENTADO A OBJETOS.
Antes de empezar a construir el aplicativo orientado a objetos, se definen las clases (objetos) que representan al aplicativo que se va a realizar, la formas en que las
clases interactúan entre ellas, el funcionamiento interno (las operaciones internas y sus atributos) todo esto ya visto en el análisis de requisitos.
Por lo tanto:
Identificar las clases (es decir, definir atributos y métodos) que en el caso del aplicativo de la agencia de transportes son:
La clase Cliente.
publicclass Cliente implements Serializable
private String DNI;
private String nombre;
private String apellidos;
private String fechanac; private double Kms;
public Cliente(String DNI, String nombre, String apellidos, String fechanac, double Kms) { this.DNI = DNI;
this.nombre = nombre; this.apellidos = apellidos; this.fechanac = fechanac; this.Kms = Kms;
}
public String getDNI (){ /*Devuelve el DNI*/ return DNI;
}
public String getNombre (){ /*Devuelve el Nombre*/
return nombre; }
public String getApellidos (){ /*Devuelve el Apellido*/
return apellidos; }
public String getFechanac (){ /*Devuelve la fecha de nacimiento*/
return fechanac; }
public double getKms (){ /*Devuelve los kilometros recorridos por el cliente*/ return Kms;
}
public void acumKms (double newKms){/*Suma los kilometros acumulados*/ Kms = Kms+newKms;
La Clase Transporte.
public class Transporte implements Serializable /*Campos de un Vuelo*/
private String codiID;
private String ciudadOrig;
private String ciudadDest; private double distancia; private double precio; private String Tipo;
public Transporte(String codiID, String ciudadOrig, String ciudadDest, double distancia, double precio, String Tipo) {
this.codiID = codiID;
this.ciudadOrig = ciudadOrig;
this.ciudadDest = ciudadDest; this.distancia = distancia; this.precio = precio; this.Tipo= Tipo;
}
public String getCodiID (){ /*Devuelve el código del Vuelo*/
return codiID; }
public String getCiudadOrig (){ /*Devuelve la ciudad de origen*/
return ciudadOrig; }
public String getCiudadDest (){ /*Devuelve la ciudad de destino*/
return ciudadDest; }
public boolean equalityOrig(String ciuOrig){
if (ciudadOrig==ciuOrig) { return true; }else{ return false; } }
public boolean equalityDest(String ciuDest){
if (ciudadDest==ciuDest) { return true; }else{ return false; } }
publicdouble getDistancia(){ *Devuelve la distancia*/ return distancia;
}
public double getPrecio(){ /*Devuelve el precio*/
return precio; }
public void introPrecio(double price){ precio=price;
}
public void introTipo(String tipo){ Tipo=tipo;
}
public String getTipo(){ /*Devuelve la ciudad de origen*/
return Tipo; }
La clase Viaje.
public class Viaje implements Serializable String DNI,codiID;
public Viaje(String DNI,String codiID) {
this.DNI=DNI;
this.codiID=codiID;
}
5.2. LA PERSISTENCIA DE DATOS.
La idea principal de este aplicativo es poder conservar grandes volúmenes de información, como los datos de los clientes, los datos de transportes y los viajes realizados por cada cliente, sabemos que el método más correcto sería usar bases de datos pero esto lo haremos en el aplicativo que usa JDBC. En este caso, usaremos un fichero de texto para introducir los datos.
5.3. ALMACENAMIENTO DE DATOS.
5.3.1. Almacenamiento temporal.
Durante la ejecución del aplicativo los datos se almacenan en listas, las listas son las siguientes:
ArrayList listaTransportes=new ArrayList(); ArrayList listaClientes=new ArrayList();
ArrayList listahistorico=new ArrayList(); 5.3.2. Persistencia de datos.
Para guardar lo datos se ha seguido el siguiente procedimiento: la creación de un fichero donde guardar los datos.
FileOutputStream foo = new
La creación de un objeto del tipo ObjectOutputStream
ObjectOutputStream oo = new ObjectOutputStream(foo); oo.writeObject(listaClientes);
oo.writeObject(listaTransportes); oo.writeObject(listahistorico); oo.close();
Por lo que respecta a la lectura de datos desde fichero, los pasos seguidos han sido la creación de un objeto del tipo ObjectOutputStream y la posterior inserción de los valores en las listas de clientes, transportes e histórico de clientes.
ObjectInputStream oi = new ObjectInputStream(foo); listaClientes=(ArrayList) oi.readObject();
listaTransportes=(ArrayList) oi.readObject(); listahistorico=(ArrayList) oi.readObject(); oi.close();
El aplicativo cada vez que se enciende carga los valores almacenados en el fichero de texto disponiendo de ellos para ser actualizados o modificados además de posibilitar la inserción de nuevas instancias de la clase cliente, transporte o histórico.
5.4. DASAROLLO DEL APLICATIVO USANDO JDBC. 5.4.1. Diseño de la base de datos.
Como parte más importante y que marcara el aplicativo en los siguientes pasos de su desarrollo es el correcto diseño de las tablas en las que almacenaremos los datos de los Clientes, Transportes y Desplazamientos.
Por lo tanto las tablas serán la siguientes:
create table Transporte (
codigo varchar(40), origen varchar(40), destino varchar(40), distancia int, precio int, tipo varchar(40) , primary key(codigo) )
create table Cliente (
dni varchar(40), nombre varchar(40), apellidos varchar(40), fecha varchar(40), distanc int, primary key(dni) )
create table Viaje (
dni varchar(40), codigo varchar(40) }
5.4.2. Establecer una conexión entre Java y JDBC.
Lo primero que tenemos que hacer es establecer una conexión con el controlador de base de datos que queremos utilizar. (En el caso de la Agencia de Transportes conectaremos con los driver de una Derby de Apache SQL).
En primer paso tenemos que hacer los import necesarios.
import java.sql.Connection;
Definimos es driver a cargar:
public String driver = "org.apache.derby.jdbc.EmbeddedDriver";
public String protocol = "jdbc:derby:";
Cargar el driver o drivers que queremos utilizar es muy sencillo y sólo implica una línea de código. La documentación del driver nos dará el nombre de la clase a utilizar.
Class.forName(driver).newInstance(); 5.4.3. Hacer la conexión.
El segundo paso para establecer una conexión es tener el driver apropiado conectado al controlador de base de datos.
Por lo tanto definiríamos las propiedades de la conexión que serían:
Properties props = new Properties(); props.put("user", "user1"); props.put("password", "user1");
Connection conn = null; Statement s = null;
En estas dos líneas de código siguiente es donde se realiza la conexión. conn = DriverManager.getConnection(protocol +
"AgenciaDB;create=false", props); s = conn.createStatement();
Por lo tanto, ya tenemos una conexión abierta que se puede utilizar para crear sentencias JDBC que pasen nuestras sentencias SQL al controlador de la base de datos.
5.4.4. Crear sentencias JDBC.
Para crear sentencia JDBC necesitamos un objeto Statement, es el que envía
nuestras sentencias SQL al controlador de la base de datos. Simplemente creamos un objeto Statement y lo ejecutamos, suministrando el método SQL apropiado con la sentencia SQL que queremos enviar. Para una sentencia SELECT, el método a ejecutar es executeQuery. Para sentencias que crean el método a utilizar es execute mientras que para actualizar o eliminar executeUpdate.
Seguidamente, vamos a ver como se han insertado valores desde la interfaz usuario en el aplicativo de la agencia de transportes.
5.4.4.1 Creación de las tablas Cliente, Transporte y Viaje. Statement s = null;
s.execute("create table Transporte ( codigo varchar(40), origen varchar(40), destino varchar(40), distancia int, precio int, tipo varchar(40) , primary key(codigo))");
s.execute("create table Cliente ( dni varchar(40), nombre varchar(40), apellidos varchar(40), fecha varchar(40), distanc int, primary key(dni))");
s.execute("create table Viaje ( dni varchar(40), codigo varchar(40))");
5.4.4.2. Cómo insertar valores en las tablas. Veremos el ejemplo de insertar un cliente String insertStr="";
insertStr="insert into Cliente values (" +quotate(DNI)+"," +quotate(nombre)+"," +quotate(apellidos)+"," +quotate(fechanac)+"," +(0) +")"; try { s.execute(insertStr); } catch (SQLException ex) {
new Error("Error, el cliente con D.N.I "+DNI+" ya existe").setVisible(true);
}
5.4.4.3. Cómo modificar un cliente. String insertStr="";
insertStr="update Cliente set nombre=" +quotate(nombre)+","+"apellidos=" +quotate(apellidos)+","+"fecha=" +quotate(fechanac)+","+"distanc=" +(dist)+"where dni="+quotate(DNI); try { bol = s.executeUpdate(insertStr); ... ...
5.4.4.4. Cómo eliminar un cliente. String insertStr="";
insertStr="delete from Cliente where dni="+quotate(DNI); try {
bol=s.executeUpdate(insertStr); } catch (SQLException ex) {
new Error("Error, a la hora de eliminar el cliente").setVisible(true);
}
if(bol==0){ new Error("Error, no existe ningun cliente con el D.N.I. "+DNI).setVisible(true); }
Comentar que la instrucción “executeUpdate” devuelve un booleano “true” si se ha podido ejecutar la instrucción y “false” si no ha podido.
5.4.4.5. Cómo recuperar valores de una tabla. (Instrucción Select).
JDBC devuelve los resultados en un objeto “ResultSet”, por eso necesitamos declarar un ejemplar de la clase “ResultSet” para contener los resultados.
Para acceder a los nombres y los precios, iremos a la fila y recuperaremos los
valores de acuerdo con sus tipos. El método “next” mueve el cursor a la siguiente fila y hace que esa fila (llamada fila actual) sea con la que podamos operar. Como el cursor inicialmente se posiciona justo encima de la primera fila de un objeto “ResultSet”, primero debemos llamar al método “next” para mover el cursor a la primera fila y convertirla en la fila actual.
ResultSet ressultset = null; String insertStr="";
insertStr="select * from Transporte where origen=" +quotate(ciudadOrig)+" and "+"destino=" +quotate(ciudadDest);
try {
ressultset = s.executeQuery(insertStr); } catch (SQLException ex) {
new Error("Error, no se ha podido hacer ejecutar la consulta").setVisible(true); } try { while (ressultset.next()) { try { bol=true; String cod=ressultset.getString(1); String orig=ressultset.getString(2); String dest=ressultset.getString(3); ... ...
5.4.5. Unión de los métodos del aplicativo a la interfaz de usuario.
Una vez identificados e implementados los métodos pasamos a unir los métodos a la interfaz mediante un evento actionPerformed.
5.4.5.1. Entrada de flujo de datos.
En este aplicativo hay dos maneras posibles de introducir datos el primero mediante el elemento de interfaz de usuario de la librería Swing “jTextField”. En este elemento el usuario introduce un dato, ya sea String, Integer o Double, el método es el que se encarga de recoger el valor mediante getText(), o GetInt().
String codiID=jTextField5.getText();
El segundo es mediante un jComboBox, este elemento permite desplegar mediante un scroll vertical una serie de valores ya introducidos previamente. En este
aplicativo se ha usado a la hora de elegir, un día del año o un mes, o elegir un tipo de transporte.
String Tipo = (String)jComboBox1.getSelectedItem(); 5.4.5.2. Salida de flujo de datos.
La salida de flujo de datos se muestra en este aplicativo de dos maneras.
La primera en elementos de áreas de texto “textArea”, es aquí donde mostraremos las listas de datos de clientes como de trasportes y así como los datos históricos de los clientes.
La segunda es mediante elementos “jTextField” ya que además de recoger el valorde un campo también puede devolverse un valor en él.
jTextField18.setText(ressultset.getString(1));
5.5. ACTIVACIÓN DE LOS CASOS DE USO.
Una vez que tenemos los métodos preparados para ejecutarse tenemos, que indicar a la interfaz como ejecutar el método. Para eso hemos usado un tipo de elemento de la librería Swing llamado “jButton” al que le hemos asignado que ejecute el método al ser pulsado, además, con este tipo de elemento también podemos cancelar acciones, limpiar listados, etc, todo previamente implementado en un método o función y asignado a un jButton.
6. EVALUACIÓN.
Para poder hacer una correcta evaluación de todo el aplicativo vamos a analizar el correcto funcionamiento de todos los casos de uso.
6.1. Casos de uso del Cliente. 6.1.1. Alta de cliente.
● Intentamos insertar un cliente en la agencia que no está repetido, y el aplicativo reacciona correctamente.
● Intentamos introducir un cliente en la agencia con el mismo identificador que un cliente que ya existe, el aplicativo responde generando un mensaje de error y mostrando el dato erróneo.
● Intentamos insertar un cliente sin rellenar todos sus campos y el aplicativo responde mostrando un mensaje de error por pantalla.
6.1.2. Compra de Billete.
● Intentamos comprar un billete con el identificador de un cliente no existente en la agencia, el aplicativo responde correctamente mostrando un mensaje de error diciendo que dicho cliente no existe en la agencia.
● Intentamos comprar un billete de un transporte que no existe, el sistema reacciona correctamente mostrando un mensaje de error diciéndonos de que dicho transporte no existe.
● Un cliente que no existe intenta comprar un billete de transporte de un transporte que no existe, el sistema reacciona correctamente mostrando un mensaje de error diciendo que el transporte y el cliente no existen en la agencia.
6.2. Casos de uso del Vendedor. 6.2.1. Alta de Cliente.
● Intentamos insertar un cliente en la agencia que no esta repetido, y el aplicativo reacciona correctamente.
● Intentamos introducir un cliente en la agencia con el mismo identificador que un cliente que ya existe, el aplicativo responde generando un mensaje de error y mostrando el dato erróneo.
● Intentamos insertar un cliente sin rellenar todos sus campos y el aplicativo responde mostrando un mensaje de error por pantalla.
6.2.2. Modificación de Cliente.
● Intentamos modificar un cliente que no existe y el aplicativo responde
mostrando un mensaje de error por pantalla diciendo que el cliente no existe en la agencia y por lo tanto no se puede modificar.
● Intentamos modificar un cliente de la agencia que existe y el sistema responde correctamente una vez modificado cambiando los valores anteriores.
● Al modificar un cliente dejamos los campos modificables iguales, el sistema reacciona correctamente no alterando los datos de un cliente.
● Al modificar un cliente dejamos los campos en blanco sin poner ningun valor, el sistema responde correctamente mostrando un mensaje de error diciendo que los datos no han sido rellenados.
6.2.3. Eliminación de Cliente.
● Intentamos eliminar un cliente que no existe en la agencia, el aplicativo responde correctamente mostrando un mensaje de error diciéndonos que tal usuario con ese identificador no puede ser borrado ya que no existe.
● Intentamos eliminar un cliente que existe en la agencia de transportes y el sistema actúa correctamente eliminando los datos de ese cliente de la agencia. 6.2.4. Venta de Billete.
● Intentamos vender un billete con el identificador de un cliente no existente en la agencia, el aplicativo responde correctamente mostrando un mensaje de error diciendo que dicho cliente no existe en la agencia.
● Intentamos vender un billete de un transporte que no existe, el sistema reacciona correctamente mostrando un mensaje de error diciéndonos de que dicho
transporte no existe.
● Un cliente que no existe intenta comprar un billete de transporte de un transporte que no existe, el sistema reacciona correctamente mostrando un mensaje de error diciendo que el transporte y el cliente no existen en la agencia.
6.3. Casos de uso de Encargado. 6.3.1. Alta de Transporte.
● Intentamos insertar un transporte en la agencia que no está repetido, y el aplicativo reacciona correctamente.
● Intentamos introducir un transporte en la agencia con el mismo identificador que un transporte que ya existe, el aplicativo responde generando un mensaje de error y mostrando el dato erróneo.
● Intentamos insertar un transporte sin rellenar todos sus campos y el aplicativo responde mostrando un mensaje de error por pantalla.
6.3.2. Modificación de Transporte.
● Intentamos modificar un transporte que no existe y el aplicativo responde mostrando un mensaje de error por pantalla diciendo que el transporte no existe en la agencia y por lo tanto no se puede modificar.
● Intentamos modificar un transporte de la agencia que existe y el sistema responde correctamente una vez modificado cambiando los valores anteriores. ● Al modificar un transporte dejamos los campos modificables iguales, el sistema
reacciona correctamente no alterando los datos de un transporte.
● Al modificar un transporte dejamos los campos en blanco sin poner ningún valor, el sistema responde correctamente mostrando un mensaje de error diciendo que los datos no han sido rellenados.
6.3.3. Eliminación de Transporte.
● Intentamos eliminar un transporte que no existe en la agencia, el aplicativo responde correctamente mostrando un mensaje de error diciéndonos que ese transporte con ese código no puede ser borrado ya que no existe.
● Intentamos eliminar un transporte que existe en la agencia de transportes y el sistema actúa correctamente eliminando los datos de ese transporte de la agencia.
6.3.4. Consulta de Histórico de Clientes.
● Si introducimos el D.N.I de un cliente que existe el sistema, nos muestra los datos de dicho cliente y además nos muestra la suma de kilómetros del cliente que ha realizado con la agencia además de todos los transportes que ha usado. ● Si introducimos el D.N.I de un cliente que no existe el sistema nos muestra un
mensaje de error diciéndonos que el cliente con ese D.N.I no existe en la agencia.
6.4. CASO DE USO COMÚN A LOS DEMÁS ACTORES.
6.4.1. Consulta de transporte.
● Para consultar un transporte es necesario introducir un origen y un destino de un transporte que estén en la agencia, por lo tanto, el origen y destino han de coincidir con algún transporte indiferentemente del tipo de transporte. ● Si introducimos orígenes y destinos existentes en la agencia, el aplicativo
muestra los datos del transporte.
● Si introducimos un origen y destino inexistente el aplicativo nos avisa mediante un mensaje de que no existe ningún transporte con esas características.
7. CONCLUSIONES.
Como conclusión al proyecto y al trabajo que he ido realizando en el aplicativo de la agencia he podido extraer como conclusión varias cosas:
La elaboración de un aplicativo algo complejo en muchos casos no es algo trivial ya que por el camino van surgiendo pequeños problemas que hacen que el aplicativo tenga retrasos. Esto es un problema grande ya que estos pequeños retrasos pueden afectar a la empresa que desarrolle un aplicativo, ya que puede ser que no cumpla con el plazo de entrega establecido Esto siempre genera en el usuario final o la persona que compra el aplicativo un grado de desconfianza.
También es importante elaborar una planificación temporal y seguimiento del
proyecto. Para mí esta es una de las parte más importantes del desarrollo de la agencia de transportes, esto es debido a que en este caso si el aplicativo no se entregara a tiempo se deduciría en un suspenso, pero si realmente esto fuera una empresa que desarrolla aplicativos un retraso se deduciría en perdidas económicas, desconfianza por parte del usuario, y más factores negativos.
En el caso de una empresa un aplicativo se desarrolla entre un grupo de personas que pueden ser más o menos inexpertas en el tema, en mi caso el aplicativo ha sido desarrollado con solo una persona, por lo tanto en la planificación temporal he dejado un buen margen de error para evitar esos posibles retrasos ya que esas pequeñas dificultades a la hora de elaborar el aplicativo sin duda alguna han surgido.
Una conclusión extraída por mi parte y que considero vital es un correcto juego de pruebas. En este caso, como es el desarrollo de la agencia el correcto funcionamiento de la agencia es importante ya que esto es un proyecto realizado con fin didáctico y se intenta que el funcionamiento sea correcto y corregir los errores con el fin de aprender bien a elaborar un aplicativo. Pero una empresa desarrolla un aplicativo con fines económicos y es importante que un aplicativo funcione bien ya que si no es así y no se ha elaborado un buen juego de pruebas pueden surgir problemas cuando este aplicativo esté funcionando y causar grandes perdidas económicas a la empresa o particular que esté haciendo uso del aplicativo, ya que desde mi punto de vista cada vez que usamos un aplicativo en el fondo lo estamos probando.
8. RECURSOS UTILIZADOS. Bibliografía.
S. Pressman, Roger. Ingeniería del Software. Un enfoque práctico 5ª edición .
MacGraw-Hill, 2002.
Bruce Ecke. Thinking in Java. Prentice-Hall, December 2002.
Jim Melton, Andrew Eisenberg. SQL y Java, Guía para SQL, JDBC y tecnologías
relacionadas. Editorial ra-ma, 2002.
John Lewis, Joseph Chase. Estructuras de datos con Java, Diseño de estructuras y
algoritmos. Editorial Pearson, 2004.
John Crupi, Dan Malks. J2EE Patterns, Best practices a desing satrategies. Prentice-Hall, 2001.
Stewart Birnam, Java 2 distribuido, desarrollo de bases de datos. Prentice-Hall, 2003
Páginas Web consultadas.
GUI Building
Adding Functionality to Buttons Creating a Derby Data base
Connecting a GUI to a Derby Database with NetBeans IDE Java
TM 2 Platform Standard Edition 5.0 API Specification Wikipedia
Java DataBase Connectivity
Programario utilizado. MagicDraw UML v10.5.
Programario utilizado para la construcción de los esquemas UML de los requisitos, análisis y diseño del aplicativo.
Página Web : Magic Draw UML
NetBeans 5.5
Programario gratuito para la implementación del aplicativo. Página Web : NetBeans
9. MANUAL.
9.1. INSTALACIÓN.
Hay dos maneras de ejecutar el aplicativo:
La primera es usando NetBeans 5.5 siguiendo las siguientes indicaciones: File – Open Proyect y escogemos el proyecto que deseemos. Tenemos que indicar donde está el driver .jar que queremos cargar.
La segunda manera es directamente desde el Símbolo del Sistema.(MS-2)
Antes que nada hay que instalar Java 1.4 o Java 1.5 definir y el Path de Java y el del Driver SQL
Instalar Java 1.5 o 1.4
Copiar el driver de Apache en el disco duro, en mi caso los sets quedan de la siguiente manera;
set JAVA_HOME=D:\j2sdk1.4.2_13 set PATH=%PATH%;%JAVA_HOME%\bin set DERBY_INSTALL=D:\Apache\db-derby-10.1.2.1-bin setCLASSPATH=%DERBY_INSTALL%\lib\derby.jar;% DERBY_INSTALL%\lib\derbytools.jar; Y ejecutar el programa: Java Agencia
9.2. USO DEL APLICATIVO.
Este aplicativo está enfocado a tres usuarios (actores) diferentes por lo tanto el
aplicativo está dividido en tres aplicativos diferentes y todos tienen en común el mismo almacén de datos, también existe el aplicativo que abarca todos los usuarios, esto quiere decir que desde ese aplicativo se controlan todos los casos de uso, por lo tanto tenemos:
El aplicativo del encargado, con el que se pueden hacer altas de transportes,
modificaciones de transportes, eliminaciones de transportes y consulta del histórico de los clientes.
El aplicativo del vendedor, con el que el vendedor puede hacer altas de cliente,
modificaciones de cliente, eliminación de clientes, consultas de transportes y ventas de billete.
Por último el aplicativo del cliente, en este aplicativo que está orientado a estar en Terminales en la misma agencia de transportes por los que el usuario o cliente podrá hacer sus consultas de transportes, darse de alta en el sistema y también podrá comprar billetes de transporte.
Por lo tanto este manual está enfocado a los tres usuarios del aplicativo y se trataran de forma independiente.
