Reserva taxi: diseño y desarrollo de un sistema de reservas para una empresa de taxis

Escuela Técnica Superior de Ingeniería Informática POYECTO FIN DE CARERA DISEÑO Y DESARROLLO DE UN SISTEMA DE RESERVAS PARA UNA EMPRESA DE TAXIS Para optar a la titulación de Ingeniero Técnico en Informática de Gestión Presentado por Pablo Tenorio Garcia Dirigido por Sergio Saez Barona Pablo Tenorio García 1 MEMORIA FINAL RESERVATAXI: Diseño y desarrollo de un sistema de reservas para una empresa de Taxis Pablo Tenorio García 2 Índice de contenido 1.-INTRODUCCIÓN..........................................................................................................…............5 1.1.-Objetivos del sistema................................................................................................................7 1.2.-Alcance del sistema......................................................................................................…........8 2.- ESPECIFICACIÓN DE REQUISITOS.........................................................................…............9 2.1.- Introducción................................................................................................................…......10 2.1.1.- Proposito........................................................................................................................10 2.1.2.- Ámbito...........................................................................................................................10 2.1.3.-Definiciones, Acrónimos y Abreviaturas........................................................................10 2.1.2.- Referencias.....................................................................................................................11 2.2.- Descripción General....................................................................................................…......11 2.2.1.- Perspectiva del porducto................................................................................................11 2.2.2.- Funciones del producto..................................................................................................11 2.2.3.- Características del usuario.............................................................................................11 2.2.4.- Restricciones generales..................................................................................................12 2.3.- Requisitos Especificos.................................................................................................…......12 2.3.1.-Diagrama de contexto DFD............................................................................................12 2.2.-Requisitos del Sistema.................................................................................................…......13 2.3.2-Requisitos de datos del sistema web de registro..............................................................14 2.3.3.-Requisitos de datos del sistema API de reserva..............................................................15 3.-ANALISIS.......................................................................................................................…..........16 3.1.-Introducción.................................................................................................................…......17 3.2.-Planificación temporal..................................................................................................…......17 3.3.-Modelado de Procesos..................................................................................................…......24 3.4.-Diagrama de contexto...................................................................................................…......24 3.5.-Diagrama de primer nivel.............................................................................................…......25 3.5.1.-Almacenes.......................................................................................................................27 3.6.-Diagrama de segundo nivel..........................................................................................…......27 3.6.1.-Gestión de reservas.........................................................................................................28 3.7.-Detalle de los Casos de Uso del apartado web.............................................................…......30 3.8.-Casos de Uso del sistema API de reserva.....................................................................…......32 3.9.-Modelado de datos.......................................................................................................…......35 3.9.1.-Descripción de Entidades...............................................................................................36 3.9.2.-Descripción Relacionales................................................................................................37 3.9.3.-Reglas de negocio...........................................................................................................37 4.-DISEÑO..........................................................................................................................…..........38 4.1.-Introducción.................................................................................................................…......38 4.2.-Diseño de la base de datos............................................................................................…......40 4.2.1.-Diseño lógico..................................................................................................................40 4.2.1.1.-Tablas del diseño lógico..........................................................................................40 4.2.1.2.- Stored Procedure....................................................................................................40 4.2.1.2.- Descripción de atributos ........................................................................................40 4.2.2.-Diseño físico ..................................................................................................................42 4.2.2.1.-Integración de la Stored Procedure.........................................................................43 4.3.-Diseño de las interfaces de usuario..............................................................................…......45 4.3.1.- Interfaces de usuario WEB............................................................................................45 4.3.2.- Interfaces de usuario del sistema móvil.........................................................................47 Pablo Tenorio García 3 4.4.-Diseño de procesos.......................................................................................................…......51 4.4.1.-Diseño de procesos WEB...............................................................................................51 4.4.1.-Diseño de procesos API y Software Móvil.....................................................................53 5.- DETALLES DE IMPLEMENTACIÓN.........................................................................…..........54 5.1.-Tecnologías empleadas.................................................................................................…......55 5.2.-Arquitectura final del sistema......................................................................................…......56 5.5.-Presupuesto del proyecto..............................................................................................…......58 5.6.-Implementación............................................................................................................…......60 5.6.1.-Modulo WEB..................................................................................................................60 5.6.2.-Modulo API....................................................................................................................60 5.6.3.-Modulo Aplicación móvil J2ME....................................................................................61 6.-PRUEBAS, PUESTA EN MARCHA .............................................................................…..........62 6.1.- Pruebas........................................................................................................................…......63 6.1.1.-Creación de usuario, envío de sms e instalación............................................................63 6.1.2.-Reserva de taxi................................................................................................................65 6.2.- Puesta en marcha.........................................................................................................…......68 7.-CONCLUSION...............................................................................................................…..........69 7.1.- Conclusión...................................................................................................................…......70 8.-BIBLIOGRAFIA............................................................................................................................72 Pablo Tenorio García 4 1.-INTRODUCCIÓN Pablo Tenorio García 5 La propuesta técnica del proyecto constituye la base para el desarrollo del sistema informático. En dicha propuesta se describe que es lo que hará el sistema, cuál es el trabajo que se va a realizar para la elaboración del proyecto, cuándo se realizará dicho trabajo y que costes acarreará su realización. El sistema propuesto se llama “ReservaTaxi: Diseño y desarrollo de un sistema de reservas para una empresa de taxis” y va a permitir a un usuario ya existente en una compañía de taxis, reservar un taxi desde su terminal móvil (teléfono), mediante la selección de sus 5 últimas direcciones de recogida. El proyecto se ha realizado físicamente en las oficinas de Techideas, una empresa de ingeniería del software en el parque tecnológico BCNord, en Barcelona. Y se ha vendido a Interfacom, cliente asiduo de Techideas, encargado de taximetros y sistemas de localización y control de flotas en Europa, usando su marca Taxitronic. En este documento se incluyen los objetivos y el alcance del sistema que nos permitirán determinar cuáles son los principales puntos a cubrir por el sistema; los requisitos del sistema, que son la base para el desarrollo posterior del sistema; la planificación inicial del proyecto que nos permitirá especificar las actividades que se llevarán a cabo para el desarrollo del proyecto, su duración y su prioridad; la estimación de costes que nos dará una aproximación del coste económico final que tendrá el proyecto y el diagrama de contexto del sistema. En un primer paso se analizará la especificación de requisitos, donde se describirá el comportamiento del sistema, incluyendo un conjunto de casos de uso que describirán todas las interacciones que tendrán los usuarios con el software. Posteriormente, se realizará un análisis del sistema a desarrollar, donde se mostrarán los procesos y los datos que interaccionan con el sistema. El diseño será el siguiente aspecto que se trata. Aquí se conectará la visión lógica desarrollada en el análisis con la actividad propia de la programación. Posteriormente se mostrarán los detalles de la implementación seguido de las pruebas, puesta en marcha y la conclusión. Pablo Tenorio García 6 1.1.-Objetivos del sistema El objetivo del sistema informático es proporcionar la funcionalidad necesaria para que el usuario final de una compañía de taxis, sea capaz de reservar un taxi en una de las últimas direcciones desde donde lo ha hecho últimamente, o si no encontrara una solución, llamar a la operadora sin tener que recordar el número de teléfono de su radiotaxi favorito. Esta reserva se realiza a través de Internet, facilitando el proceso, evitando esperas y obteniendo un resultado instantáneo (ya sea positivo o negativo). Este mismo sistema, puede ser la base para dar un paso mas y realizar la reserva de taxis usando un mapa con geocodificación, pero en este caso, desgraciadamente, no daremos una solución tan compleja y completa. 1.2.-Alcance del sistema En cuánto al alcance organizacional, el sistema mantendrá interacción con los usuarios finales, que usarán el software en el terminal móvil y con el administrador del sistema en la empresa de taxis, que podrá comprobar estadísticas, comprobar datos de usuarios, etc… Por lo que se refiere al alcance informático, el sistema es prácticamente automático. El usuario final usará su teléfono para pedir primero la lista de las últimas direcciones de recogida y posteriormente seleccionar dicha dirección. En cuanto al alcance funcional, el sistema constará de tres partes con funciones diversas: 1. Web de aprovisionamiento, alojada en el servidor ReservaTaxi, donde el usuario se registrará y descargará el programa para el móvil. 2. Software del terminal móvil, desde donde el usuario podrá reservar taxis. 3. API (Application Programming Interface), que comunicará nuestro servidor con el servidor central de la empresa para obtener la lista de direcciones y reservar el taxi. Pablo Tenorio García 7 2.- ESPECIFICACIÓN DE REQUISITOS Pablo Tenorio García 8 2.1.- Introducción Esta especificación tiene como objetivo analizar y documentar las necesidades funcionales que deberán ser soportadas por el sistema a desarrollar. Para ello, se identificarán los requisitos que ha de satisfacer el nuevo sistema mediante entrevistas, el estudio de los problemas de las unidades afectadas y sus necesidades actuales. Además de identificar los requisitos se deberán establecer prioridades, lo cual proporciona un punto de referencia para validar el sistema final que compruebe que se ajusta a las necesidades del usuario. 2.1.1.- Proposito El propósito es definir cuales son los requerimientos que debe tener un programa que gestione la reserva de taxis, para usuarios vip de una empresa, en este caso, RT033. Con este sistema se liberan muchos puestos de operadora que estaban pendientes de ofrecer los destinos típicos de los clientes vip. 2.1.2.- Ámbito El producto que vamos a describir es un programa que facilitará la petición de taxis a los usuarios vip de esta empresa. Se llama RESERVATAXI. Este producto debe ser capaz de adaptarse a la mayoria de terminarles móviles (smartphones). El servidor debe estár permamentemente conectado al servidor central de la empresa de taxis y con conexión tambien permanente a internet para que los usuarios puedan hacer uso de sus servicios. 2.1.3.-Definiciones, Acrónimos y Abreviaturas Reserva: accion de pedir un taxi Servidor local: maquina donde se encuentra nuestro software Servidor cliente: maquina donde se encuentran todas las bases de datos de los taxis, su localización, las peticiones, etc API: interfaz de programación de aplicaciones (Application Programming Interface). En nuestro caso, es la encargada de recibir todas las peticiones desde los terinales moviles, y comunicarse con el servidor del cliente. Pablo Tenorio García 9 3.-ANALISIS Pablo Tenorio García 16 3.1.-Introducción Una vez conocida la propuesta técnica del proyecto ReservaTaxis, en éste apartado del proyecto vamos a centrarnos más en los detalles del sistema mediante un análisis exhaustivo; tanto en los procesos como en los datos que van a aparecer e interaccionar en el subsistema. Antes de mostrar los modelados, se ofrece una vista de la planificación temporal del proyecto. Para explicar el análisis del subsistema de un modo ordenado, se empezará por mostrar y comentar los distintos procesos que interactuarán tanto entre el sistema como fuera de él, los almacenes, y los flujos de datos que permiten la comunicación entre los componentes; a este apartado se le conoce como el modelado de procesos. El contenido de este apartado se mostrará de forma ordenada, de menor a mayor detalle. Una vez conocido el modelado de procesos se presentará el análisis de los datos que tendrán relevancia en el subsistema, agrupados en entidades, y las relaciones que existen entre ellos. A este apartado se le conoce como modelado de datos. Una vez conocido de antemano el contenido del análisis del proyecto se procederá a presentar el modelado de los procesos mediante diagramas y documentación relacionada. 3.2.-Planificación temporal Para disponer de un control temporal en el desarrollo del proyecto, se han detallado las tareas, recursos e hitos a conseguir en el transcurso del tiempo. La presente tabla muestra al desarrollador del proyecto en sus distintos roles, y el coste por hora que cobrará en el desarrollo. La siguiente tabla a presentar muestra cada una de las tareas a realizar en el desarrollo del proyecto, unas de las columnas con información más relevante es la de “Coste” de cada uno de los procesos, los cuales se tienen que tener en cuenta con la tabla anterior. Pablo Tenorio García 17 Nombre Grupo E-Mail Coste Pablo Tenorio Analista [email protected] 40 Pablo Tenorio Programador [email protected] 30 Una vez presentada la tabla de las tareas se presentará a continuación un diagrama de Gantt fragmentado, en el que, de forma gráfica, se puede apreciar los periodos de desarrollo asignados en un principio para el proyecto. Pablo Tenorio García 18 Pablo Tenorio García 19 Pablo Tenorio García 20 Pablo Tenorio García 21 Pablo Tenorio García 22 Pablo Tenorio García 23 3.3.-Modelado de Procesos A continuación se presentarán los distintos diagramas del modelado de procesos de menor a mayor detalle, acompañados de la documentación adecuada en cada uno de los niveles. Para ello se utilizará una de las técnicas de modelización de procesos más utilizada en las metodologías estructuradas; los diagramas de flujos de datos (DFD). Como se comentó en la propuesta técnica, antes de describir el contenido del diagrama, hay que tener en cuenta que todos los nombres de los flujos de datos (flechas) hacen referencia a transacciones de información entre el subsistema y las entidades externas con las que se comunica; aunque el nombre de cada uno de estos flujos no lo indiquen en algunos casos. Cada uno de los distintos flujos de datos están separados por comas bajo una misma flecha; en realidad cada flujo debería de estar representado por una flecha, pero para facilitar la comprensión del diagrama y no cargarlo demasiado, se han juntado aquellas que van de una misma entidad a otra en un mismo sentido. También hay que tener en cuenta que la descripción de los flujos de datos sólo se realizará cuando éstos se encuentren en procesos que no se vayan a explotar más, normalmente encontrados en los diagramas de mayor detalle. En éstos diagramas, cada flujo de datos estará representado por una única flecha. Empezaremos presentando el primero de los diagramas, el cual ya apareció en la propuesta técnica. 3.4.-Diagrama de contexto El diagrama de contexto es el primero de los diagramas del modelado de procesos, y por lo tanto el que contiene un menor nivel de detalle, con una mayor abstracción de la información. Pablo Tenorio García 24 En el diagrama de contexto nos encontramos al subsistema ReservaTaxi y la entidad externa con las que se relaciona, los clientes. En lo referente a los flujos de datos, de momento no se va a comentar ninguno, se irán comentando cada uno de ellos mediante tablas aclarativas, cuando aparezcan relacionados en procesos que no se vayan a explosionar más. Una vez conocido el diagrama de contexto se pasará a explosionar el proceso principal ReservaTaxi para conocer un diagrama de primer nivel. 3.5.-Diagrama de primer nivel En esta sección se presentará la primera explosión del diagrama de procesos, conocido también como el diagrama de primer nivel. Iniciaremos la documentación del diagrama explicando los distintos procesos que aparecen: 1. Gestión de clientes: Permite gestionar el alta de clientes. El cliente se da de alta y el sistema le facilita un link desde donde se podrá descargar la aplicación. 2. Gestión de reservas: Gestiona las descargas y las reservas del cliente y hace de puente entre el cliente y el servidor externo de la empresa de taxis. En el Pablo Tenorio García 25 RF-A03 Petición Direcciones Versión 1.0 Requisitos asociados RD-W03 (Radio Taxi ID,Radio Taxi Empresa) RD-W01 (Numero Teléfono) Descripción Devuelve una lista con las direcciones frecuentes desde donde el cliente suele pedir taxis. La API hace esta consulta en el servidor central de la empresa de taxis. Pre condición Se llama previamente a RF-A04 para comprobar si se ha hecho ya esta reserva. Secuencia Normal Paso Acción P1 Al iniciar el software, automáticamente se hace esta llamada al servidor P2 La API recoge los datos del cliente y hace la consulta en el servidor central de la empresa de Taxis P3 La API devuelve por JSON una lista con los destinos que la empresa de taxis ha determinado son los mas frecuentes del cliente. RF-A04 Comprobación de petición Versión 1.0 Requisitos asociados RD-W03 (Radio Taxi ID,Radio Taxi Empresa) RD-W01 (Numero Teléfono) RD-A01 (ID Calle) RD-A02 (Numero Calle) Descripción Realiza una consulta en el servidor de la empresa de taxis, comprobando si se ha realizado ya la reserva del taxi. Pablo Tenorio García 32 RF-A05 Crear Reserva Versión 1.0 Requisitos asociados RD-W03 (Radio Taxi ID,Radio Taxi Empresa) RD-W01 (Numero Teléfono) RD-A01 (ID Calle) RD-A02 (Numero Calle) Descripción Realiza la reserva del taxi en el servidor de la empresa de taxis y devuelve el resultado. Pre condición Se ha llamado previamente a RF-A03 para obtener la lista de destinos. Secuencia Normal Paso Acción P1 Se selecciona el destino de la lista P2 Aparece mas información de la reserva en pantalla, pudiendo aceptar o rechazar la reserva P3 Al aceptar se manda la petición a la API. Postcondición Se notifica al usuario del estado de la reserva, con un id de reserva o con un código de error dependiendo del caso. RF-A06 Info Procesador Versión 1.0 Requisitos asociados Descripción Devuelve información sobre la empresa de taxis Pablo Tenorio García 33 3.9.-Modelado de datos En el modelado de datos nos encontramos con la descripción de todos los datos que se mueven por el subsistema, y las relaciones que tienen entre ellos. A continuación se verá el diagrama de modelado de datos entidad-relación. 3.9.1.-Descripción de Entidades Entidad: Clientes Atributos Nombre Tipo Descripción Dominio Id Entero Código del cliente Único num_telefono Entero Número de teléfono del cliente fecha_ref Fecha Fecha de registro del cliente radio_taxi Cadena 10 Pablo Tenorio García 34 Entidad: Descargas Atributos Nombre Tipo Descripción Dominio usuario_id Entero Código del usuario Único lilnk Cadena (32) Link de descarga personalizado Active Cadena (1) Estado del cliente 0,1,2 fecha_descarga Fecha Fecha en la que se produce la descarga modelo_telefono Cadena (120) Modelo del telefono desde donde se solicita la descarga telefono_radiotaxi Int Teléfono del radiotaxi del cliente 3.9.2.-Descripción Relacionales La relación entre las entidades presentadas Clientes-Descargas es la siguiente: Un cliente puede realizar 0 o N descargas 3.9.3.-Reglas de negocio Cualquier usuario se podrá registrar en el sistema y se descargará el software, pero la aplicación no se activará si ese usuario no está previamente registrado como cliente de la compañía de taxis. Pablo Tenorio García 35 4.-DISEÑO Pablo Tenorio García 36 4.1.-Introducción El diseño del sistema informático es una fase fundamental del desarrollo del sistema, el objetivo del cuál es conectar la visión lógica desarrollada en el análisis con la actividad propia de la programación y otras tareas necesarias para poner el sistema en funcionamiento. De esta forma, el análisis del sistema se ha centrado en qué ha de realizar el sistema, mientras que el diseño físico se preocupa por la manera en que se han de satisfacer estos procesos. Durante la fase de diseño se identifica, analiza y determina como los datos que se han definido en la fase de análisis han de procesarse, almacenarse, y como y en que formatos ha de obtenerse la información de salida. Según los elementos que constituyen un sistema informático, el diseño se centra en estudiar el análisis y desarrollar modelos que representen el aspecto físico del sistema para cada uno de estos elementos: las interfaces de usuario, los procesos que ha de soportar el software y las bases de datos. Así, el objetivo es conseguir un diseño del sistema que sea efectivo, fiable y mantenible, es decir, que cumpla los requisitos analizados, las especificaciones y las restricciones de manera correcta. El diseño conceptual se ha incluido en la fase anterior de análisis del sistema, mediante la elaboración del modelo conceptual de datos (MCD). En esta fase, se ha elaborado, a partir de este MCD, en primer lugar el diseño lógico de la base de datos y posteriormente el diseño físico de ésta. En esta sección se añade la descripción de la “Stored Procedure” de la base de datos a la cual accede la API para realizar la reserva real del taxi. Se ha tenido que hacer una integración de ambos sistemas ya que la base de datos local está diseñada en MySql y la remota situada en el servidor de la empresa de taxis en Oracle, pero esto lo analizaremos mas adelante. Una Stored Procedure es una función programada que realiza su propia gestión en la base de datos instalada, haciendo Inserts, Deletes y Updates donde haga falta. Esta gestión es totalmente transparente para nosotros. El cliente nos ha dicho como llamarla y nos hemos la hemos integrado en la API. Pablo Tenorio García 37 4.2.-Diseño de la base de datos 4.2.1.-Diseño lógico El diseño lógico es el proceso de construir un esquema de la información, basándose en un modelo de base de datos específico, independientemente del sistema gestor de base de datos concreto que se vaya a utilizar y de cualquier otra consideración física. Además de todo esto, el esquema lógico es una fuente de información para el posterior diseño físico. También juega un papel importante durante la etapa de mantenimiento del sistema, ya que permite que los futuros cambios que se realicen sobre los programas de aplicación o sobre los datos, se representen correctamente en la base de datos. Así, se transforma el esquema conceptual desarrollado en la fase anterior, en un esquema lógico que utiliza las estructuras de datos del modelo de base de datos que se utilizará. En nuestro caso el modelo que sigue la base de datos que se va a diseñar es el modelo relacional. 4.2.1.1.-Tablas del diseño lógico Clientes (id, num_telefono, radio_taxi, fecha_reg) Descargas (usuario_id, link, active, fecha_descarga, modelo_telefono, telefono_radiotaxi) 4.2.1.2.- Stored Procedure ReservaTaxi (id_empresa, f_recogida, calle_rec, numero_rec, piso_rec, calle_des, numero_des, piso_des, id_serv) 4.2.1.2.- Descripción de atributos Tabla Clientes ID es el identificador del cliente, único, entero y autoincremental. Num_telefono lo usa la base de datos de la empresa de taxis como identificador proprio. Se usará para interaccionar con ella. Radio_taxi es una cadena que indica la compañía de taxis que usa el usuario. Este dato es rellenado por el cliente a la hora del alta, o directamente la central de taxis Pablo Tenorio García 38 envía una página de registro al cliente, la cual introducirá este dato automáticamente Fecha_reg es un dato tipo fecha, y registra el momento del alta del cliente. Tabla Descargas Usuario_id es el mismo que el de la tabla clientes. Link es una cadena generada por el sistema, que se enviará por sms al cliente para que se descargue el programa. Active es una variable que el software del teléfono usará para saber en que estado está el usuario. Dependiendo de su valor, sabrá si se lo ha descargado, si el usuario existe en la base de datos de la empresa, o por el contrario si ha habido algún tipo de error. Fecha_descarga es una variable tipo date, que nos muestra, como su nombre indica, la fecha de la descarga. Modelo_telefono. Cadena que indica el modelo del telefono que va a descargar la aplicación, lo detecta la página php de la api a la que se accede para realizar la descarga y lo guarda en esta variable. Teléfono_radiotaxi. Esta variable guarda el telefono de la empresa asignada al cliente. Stored Procedure ReservaTaxi Los atributos de la llamada que utilizamos son los siguientes: Id_empresa, id_cliente (el numero de telefono), calle_rec y numero_rec. El resto de atributos son opcionales y para la reserva desde nuestro software para terminales móviles, no los usamos. El atributo id_serv se recoge y nos indicará el localizador del servicio o en su caso, el tipo de error que ha sufrido la stored procedure. Pablo Tenorio García 39 4.2.2.-Diseño físico El diseño físico es el proceso de producir la descripción de la implementación de la base de datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un acceso eficiente a los datos. Así, en el diseño físico se especifica cómo se guarda la información. En general, el propósito del diseño físico es describir cómo se va a implementar físicamente el esquema lógico obtenido anteriormente. Para llevar a cabo esta etapa, se tiene que elegir un sistema gestor de bases de datos. Para la realización de este proyecto se ha escogido MySql. En primer lugar se presentan las sentencias para la creación de las tablas de la base de datos. Sentencias de creación de las tablas -- -- Estructura de tabla para la tabla `clientes` -- CREATE TABLE IF NOT EXISTS `clientes` ( `id` int(11) NOT NULL auto_increment, `phone_number` int(11) NOT NULL, `radio_taxi` text character set latin1 collate latin1_spanish_ci, `registration_date` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=87 ; -- -- Estructura de tabla para la tabla `descargas` -- CREATE TABLE IF NOT EXISTS `descargas` ( `user_id` int(11) NOT NULL, `link` varchar(32) NOT NULL, `active` varchar(1) NOT NULL, `download_date` datetime default NULL, `phone_model` varchar(120) default NULL, `phone_number_rt` int(10) NOT NULL, PRIMARY KEY (`user_id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; Pablo Tenorio García 40 Codigo de lanzamiento de la Stored Procedure $stid = oci_parse($conn, "begin RESERVA_VICTOR(:ID_EMPRESA,:ID_CLIENTE,:F_RECOGIDA,:CALLE_REC,:NUME RO_REC,:PISO_REC,:CALLE_DES,:NUMERO_DES,:PISO_DES,:ID_SERV,:ERRCODE) ; end;"); oci_bind_by_name($stid, ":ID_EMPRESA", $radioTaxiCompany); oci_bind_by_name($stid, ":ID_CLIENTE", $phone); oci_bind_by_name($stid, ":F_RECOGIDA", $today); oci_bind_by_name($stid, ":CALLE_REC", $streetId); oci_bind_by_name($stid, ":NUMERO_REC", $streetNumber); oci_bind_by_name($stid, ":PISO_REC", $null); oci_bind_by_name($stid, ":CALLE_DES", $null); oci_bind_by_name($stid, ":NUMERO_DES",$null); oci_bind_by_name($stid, ":PISO_DES", $null); oci_bind_by_name($stid, ":ID_SERV", $id_serv,8); oci_bind_by_name($stid, ":ERRCODE", $err_code,8); oci_execute($stid); 4.2.2.1.-Integración de la Stored Procedure Para poder llamar a la Stored Procedure ha hecho falta hacer una integración de varios sistemas, ya que en nuestro servidor disponemos de una base de datos MySql, pero hay que acceder a la base de datos basada en Oracle, del servido de la empresa cliente. Para ello se ha instalado el OCI 10.2 (Oracle Client Interface) y la extensión de php oci8. Para ello, ejecutamos el siguiente script en el servidor: # The script is tested on a virtual machine running OS Linux Ubuntu Server 8.04.1 i386 created on a Mac OS X running Leopard 10.5.3. # It will install and configure OracleClient v10.2 and the OCI8 v1.3.3. # 1. You need to be logged as root # 2. You need to be connected to internet # 3. You need to download the Oracle Client from the Oracle website # It downloads and installs of the basic components apt-get update apt-get --force-yes -y upgrade apt-get install --force-yes -y ssh unzip php5-dev php-pear build-essential libaio1 # It create the directory that will contain the 'Instant Client Package - Basic Lite' and the Pablo Tenorio García 41 Pablo Tenorio García 48 4.4.-Diseño de procesos A continuación se presentaran los procesos que se usarán en el sistema, tanto si hacen uso de las interfaces como si no para llevar a cabo todas las tareas necesarias para el cumplimiento de los requisitos del proyecto. Los procesos se dividirán en tres bloques, dependiendo de quién los ejecute o a quien les afecte más de forma directa. De este modo tenemos los procesos del alta de usuarios, de la API y de la aplicación del móvil Pablo Tenorio García 49 4.4.1.-Diseño de procesos WEB comprueba_format o_datos_alta Permite comprobar que los datos introducidos son completamente válidos Entrada de datos: Numero de telefono Salida de datos: Ninguna Interfaces utilizadas: “Alta usuario” cuando pulsa “Enviar” Tablas de la base de datos a las que accede: Ninguna Funcionamiento: Comprobar que están rellanados todos los campos y que tiene un formato correcto, que no contiene letras y el numero de dígitos sea entre 9 y 16 Si todo es correcto se pasa a procesar los datos y enviar el sms Si no, sale un mensaje de error javascript pidiendo que alta_usuario Crea el usuario en la base de datos, genera su link de descarga y enviá el sms al terminal con el link de descarga Entrada de datos: Numero de telefono, fecha del alta Salida de datos: Ninguna Tablas de la base de datos a las que accede: Clientes y Descargas Funcionamiento: Se crea el link Se añade el usuario a la base de datos Se enviá el sms Si todo es correcto se muestran los detalles de instalación del software Si no, sale un mensaje de error explicativo Pablo Tenorio García 50 4.4.1.-Diseño de procesos API y Software Móvil Puesto que el terminal se comunicará con la API constantemente, los procesos son los mismos, y se analizarán desde el punto de vista de la API. gestión_direccione s Resuelve la petición del listado de direcciones Entrada de datos: Numero de telefono Salida de datos: Lista de taxis Tablas de la base de datos a las que accede: Nombre de calle, ID de calle y Numero en la calle, consultado en la base de datos de la empresa de taxis Funcionamiento: Al arrancar el software del terminal móvil se enviá la petición con el numero de telefono como id Se recogen los datos y se hace la consulta en la base de datos de la empresa de taxis Se devuelve al telefono por json la lista crear_reserva_taxi Genera la reserva del taxi en la direccion deseada Entrada de datos: Numero de telefono, ID calle, fecha_reserva Salida de datos: Estado reserva Tablas de la base de datos a las que accede: Desconocido (el servidor de la empresa de taxis se encarga de gestionar la reserva) Funcionamiento: Se recogen los datos enviados desde el terminal Se rellena los parametros de la funcion que va a activar la reserva del servidor externo Se envia el resultado al terminal Pablo Tenorio García 51 5.- DETALLES DE IMPLEMENTACIÓN Pablo Tenorio García 52 5.1.-Tecnologías empleadas Para el desarrollo del proyecto se pretende hacer uso de software libre allí donde sea posible su uso. En la adquisición de cada una de las tecnologías se tiene en cuenta, en distintos grados de importancia, tanto su estabilidad/calidad, su costo y su curva de aprendizaje, siendo ésta lo menos acentuada posible. Como dispositivo hardware para la realización del proyecto se posee de un ordenador portátil IBM Lenovo T60. Como sistema operativo, se usará GNU/Linux Ubuntu versión 9.10, versión estable de dicha distribución. Como dispositivo para probar el apartado móvil se ha usado un smartfone con symbian, el Nokia 8500 XpressMusic. El servidor real es un rack con un procesador Intel Xeon quad core y 4 gigas de ram. Se le ha instalado un Ubuntu Server y un modem usb para el envío de sms. Para la redacción de los distintos documentos necesarios para el análisis y diseño del proyecto se usará OpenOffice 2.0. En el análisis del proyecto se utilizará un editor de diagramas conocido como Dia, en realidad este programa no tiene la versatilidad de un CASE , pero dada la envergadura del proyecto y la falta de Herramientas CASE en el mundo del software libre, el editor de diagramas Dia cumple dentro de lo que cabe los requisitos. En la fase de implementación se hará uso de Eclipse. Ésta herramienta facilitaran tanto la programación como la depuración del código necesario para llevar a cabo todas las funcionalidades requeridas por el subsistema y presentadas durante el proyecto. El apartado web de aprovisionamiento se ha realizado con HTML, Javascript y PHP, la API del servidor en PHP y el software del teléfono con J2ME. El sistema se aloja en un servidor proporcionado por la empresa re taxis, al cual se le instala un Ubuntu 9.10-desktop-i386, con las siguientes particiones: –8,3 GB EXT4 montado en / –9,2 GB EXT4 montado en /opt –56 GB EXT4 montado en /var –1 GB de SWAP En el servidor se ha instalado un Aache, Mysql Server y los módulos necesarios de PHP. Pablo Tenorio García 53 Se ha lanzado tambien el script de instalación de oracle OCI que se ha explicado en otros apartados. Para realizar el envío del sms, con el link de instalación, se ha usado un modem usb con una tarjeta SIM conectado al servidor. Para poder usar este modem, ha sido necesario instalar el paquete Gnokii, y configurarlo. Ademas, se ha programado una copia de seguridad, que se hace en una maquina externa, con sistema operativo windows. Para ello se ha instalado el Samba, se ha montado la unidad externa en nuestro sistema y se ha programado un script que será llamado por crontab en nuestro sistema, haciendo copias de la pagina web, el apache y de la base de datos mysql. 5.2.-Arquitectura final del sistema Una vez terminado el proyecto se debe obtener un subsistema integrable con los demás subsistemas de la empresa, con un robusto servicio web que permita atender las reservas de clientes, realizar estadísticas, ofrecer un servicio en tiempo real de manera que ni los clientes se queden esperando inútilmente ni los taxistas hagan carreras a direcciones erróneas La interfaz de usuario estará realizada mediante las últimas tecnologías en el desarrollo J2ME. El funcionamiento interno del subsistema del servidor estará programado en PHP, el cual accederá a una base de datos local gestionada por el sistema gestor de base de datos y a la base de datos del servidor central de taxis. Pablo Tenorio García 54 Una vez presentada la tabla de las tareas se presentará a continuación un diagrama de Gantt fragmentado, en el que, de forma gráfica, se puede apreciar los periodos de desarrollo asignados en un principio para el proyecto. 5.5.-Presupuesto del proyecto Una vez conocido el funcionamiento del proyecto, el alcance que pretende tener, su despliegue tecnológico y el desarrollo temporal, se presentará por último el coste total necesario para llevar el proyecto a buen cauce. Costes relacionados con el desarrollo del proyecto: Concepto Precio Amortización portátil 200,00 € SO Ubuntu Linux más software GNU de administración 0,00 € OpenOffice 2.0 0,00 € Editor de diagramas Dia 0,00 € Visor PDF's Acrobat Reader® 0,00 € MySql Server 0,00 € Eclipse 0,00 € J2ME Polish 0,00 € Pablo Tenorio García 55 Costes relacionados con los recursos humanos: Tarea Precio Estudio del proyecto 320 € Análisis de requisitos 1520,61 € Análisis del sistema 1280 € Diseño del sistema 1775 € Construcción y puesta en marcha 2520 € Redacción de la memoria final 680 € COSTE TOTAL 8095,61 € Por último se presentará el coste total final del proyecto estimado: Concepto Precio Costes en el desarrollo 200 € Costes en el funcionamiento 671,76 € Costes de mano de obra 8095,61 € COSTE TOTAL PROYECTO 8967,22 € 5.6.-Implementación En esta sección del desarrollo del proyecto se conocerán todos los aspectos vinculados a la implementación del proyecto. Teniendo en cuenta tanto el desarrollo de la base de datos como los módulos realizados en los distintos lenguajes de programación necesitados. 5.6.1.-Modulo WEB Contiene toda la programación necesaria para la gestión del alta de usuarios. Se divide en los siguientes ficheros con la siguiente funcionalidad. • index.php : Contiene el formulario de alta de usuario y una función javascript que se encarga de verificar el buen formato del imput. • add_user.php : inserta en la base de datos al usuario, enviá un sms al usuario usando la librería gnokii, •error.php: contiene y gestiona los errores • downloaded.php : gestiona las descargas, primero detectando que terminal solicita la descarga (usando la librería mdetect) y posteriormente enviando el paquete pertinente, alojado tambien en el mismo directorio. • config.inc.php : contiene la configuración de acceso a la base de datos y varias variables de configuración 5.6.2.-Modulo API Contiene toda la programación necesaria para la gestión de reserva de taxis desde el terminal móvil y comunica directamente con el servidor central de la empresa de taxis. • client_get_address_processor.php : recoge los datos del cliente local y enviá una petición al servidor de la empresa de taxis, obteniendo una lista de 5 direcciones que será reenviada por json al terminal. • radio_taxi_hasBook.php : comprueba si se ha realizado ya una reserva de taxi. • radio_taxi_create_dispatch_processor.php : realiza la reserva en la dirección seleccionada y enviada desde el terminal, haciendo una del proceso, y en caso de hacerse la reserva, ella la cancelaría. Efectivamente, en el primer intento no funcionó, y se tuvieron que corregir errores que se generaban al pasar las cadenas con las direcciones de un protocolo a otro, y en la llamada de la “Stock Procedure” ResevaTaxi. Una vez pulido cada detalle, se procede a la puesta en marcha. 6.2.- Puesta en marcha La puesta en marcha del sistema, una vez todo ya funciona a la perfección, trata de llevar el servidor que hemos configurado al centro de calculo de la empresa de Taxis, donde está su servidor con toda la gestión de los taxis, y la base de datos a la que accedemos para reservar un taxi. Se le ha asignado una dirección IP al servidor, dentro del rango de la empresa del cliente, y hemos apuntado a la dirección local del servidor central, ya que antes apuntábamos a la dirección publica. Hecho esto, se activa el sistema y se monitoriza con atención constante durante las primeras horas y poco a poco vamos mirando los logs del sistema para comprobar que todo funciona correcto, hasta que al final teniendo la seguridad de que todo funciona correctamente se dejan las comprobaciones por completo, ya que si hay algún error grande seriamos avisados por la compañía de taxis casi instantáneamente. 7.-CONCLUSION 7.1.- Conclusión Como primer contacto con el mundo de la demanda y la oferta, al ser un proyecto real he aprendido a trabajar bajo presión tanto de los jefes como del cliente. A pesar de las dificultades el proyecto ha salido adelante y con ayuda de los compañeros de trabajo hemos logrado sacarlo adelante, cosa que agradezco infinitamente. Es un proyecto base, que de hecho ha servido para posteriores proyectos, donde se han implementado interfaces mucho mas complejas y abastecido mas mercado (iPhone ha sido básicamente lo que faltaba). Actualmente existe una aplicación hecha en colaboración con nuestra empresa, GooTaxi , la cual permite reservar taxis haciendo click en un mapa desde el terminal. Debido a la presión y al ser un prototipo, muchas interfaces no están muy cuidadas ya que fueron casi de prueba pero el cliente decidió que se conformaba con la funcionalidad. Hubiera sido muy sencillo implantar el estilo de la web donde se ha colocado este servicio, por ejemplo. Además, a pesar de no haber sido pedido por el cliente, falta un servicio de gestión de usuarios, una interfaz que permitiera modificar, crear y borrar usuarios inválidos o ya no activos. Sabiendo como funciona el servidor del cliente, se podría haber ofrecido mas información al usuario, como por ejemplo el tiempo estimado hasta la recogida, o la dirección donde se encuentra el taxi que acepta la petición de recogida. 8.-BIBLIOGRAFIA •www.php.net •www.mysql.com •www.oracle.com •www.enough.de/products/j2me-polish/ •www.ubuntu.es •www.gnokii.org •www.efectosjavascript.com