Sistema de control y gestión de tráfico y ubicación
para la empresa de transportes “La Paz Bus”
Christian Luis Ferrufino Velasco Guido Esteban Hernani Belaunde
Universidad Católica Boliviana Universidad Católica Boliviana
“San Pablo” “San Pablo”
La Paz, Bolivia La Paz, Bolivia
cferrufinovelasco@gmail.com guimega.gh@gmail.com
Camila Lemuz Mujica
Universidad Católica Boliviana
Resumen — Éste documento presenta las fases incepción y
elaboración del Sistema de gestión y control de tráfico y ubicación,
desarrollado para la meteria de Sistemas de Información II de la
Universidad Católica Boliviana “San Pablo”. En él se desarrollan
todos los presentables de éstas fases, siguiendo el Proceso
Unificado de desarrollo de software.
Keywords—Anfitrión, Concurrencia, Geolocalización, Ruta.
I. INTRODUCCIÓN
El propósito de este documento es demostrar las etapas de
inserción y elaboración del sistema multiplataforma de gestión
y control de tráfico y ubicación para empresa de transportes "La
Paz Bus". Donde se desarrollará cada punto de estas.
II. ENTORNO INICIAL
A. Equipo de proyecto
El grupo está conformado por 4 estudiantes de Ingeniería de
Sistemas de la Universidad Católica Boliviana “San Pablo”,
cada uno de éstos cuenta con una laptop y los entornos de
desarrollo adecuados. Al tratarse de un proceso iterativo, se
determinó una reunión semanal en un espacio adecuado para la
comunicación del grupo y que permita el desarrollo del proyecto
sin inconvenientes como la disponibilidad de batería o la
conexión a internet.
B. Glosario
A continuación se exhibirán términos que se manejarán a lo
largo de todo el documento, diferenciando entre términos
temáticos del proyecto y términos técnicos.
1) Glosario temático: Las palabras que se describen a
continuación son términos términos relacionados con la
temática del proyecto, siendo éstas definiciones únicas en todo
el documento.
a) Concurrencia. Conjunto de personas que están
presentes en un lugar, ya sea en un bus o en una parada.
b) Descenso. Acción de bajar de un bus en una
determinada parada, puede referirse a situaciones donde una o
muchas personas bajan.
“San Pablo” La Paz, Bolivia
La Paz, Bolivia cferrufinovelasco@gmail.com
lemuzmujiquita@gmail.com
Danny Walter Zambrana
Sanabria
Universidad Católica Boliviana
“San Pablo”
c) Parada. Cada uno de los puntos de una ruta donde los
vehículos se detienen a esperar o dejar a los pasajeros.
d) Ruta. Camino y dirección designados para un
propósito.
2) Glosario técnico: Éste glosario contiene términos
técnicos que se manejan a lo largo del proyecto, los cuales
pueden no ser muy comúnes para personal no especializado
a) Multiplataforma. Dicho de un producto informático
que puede ser utilizado en distindos sistemas o entornos.
b) Chatbot. Programa o agente de conversación que
interactúa con los usuarios usando el lenguaje natural.
3) Terminología clave. Además de tener palabras
enteramente relacionadas con la temática del proyecto, se tiene
también algunos términos que se manejan en un contexto
especial, especialmente al identificar los roles en el sistema.
a) Administrador. Se refiere al personal designado para
comunicar sobre nuevas rutas y desvíos de emergencia de
manera general para todo el público, actualmente éste personal
realiza ésta tarea a través de Facebook, sin lograr un alcance
muy grande por su cuenta y valiéndose de la difusión por
terceros.
b) Anfitrión. Encargado de comunicar paradas, y avisos
de emergencia entre otras cosas, dentro de un bus designado,
éste cuenta con una pantalla en la que puede visualizar todo el
bus desde su estación de trabajo, su tarea más importante
actualmente es la de controlar el acceso al bus y cobrar el pasaje
correspondiente, ya sea por tarjeta a través de su sistema, o en
efectivo. Cualquiera sea el caso, la entrada de cada persona es
registrada por el anfitrión en el sistema al momento de pagar.
c) Cliente. Es cualquier persona, sin importar su edad,
sexo o condición, que use el servicio de transporte ofrecido por
La Paz Bus, ya sea ocasionalmente o de manera frecuente. Se
considera como posibles futuros clientes a todas las personas
que transiten cerca a las paradas de las nuevas rutas planificadas
o en planificación. Al tratarse de un servicio de transporte,
también se puede referir a los clientes como pasajeros o
usuarios del servicio.
 III. MODELO DE NEGOCIO IV. PROTOTIPO INICIAL
Se realizó un prototipo interactivo en la plataforma “Adobe
XD”, a continuación se mostrarán las interfaces básicas del
proyecto.
A. Aplicación Cliente
1) Conversación inicial

Figura 1. Modelo de negocios o Canvas.

El Modelo Canvas, también conocido como lienzo del modelo
de negocio, es un concepto que permite visualizar en un sólo
documento la idea y la visión global de un modelo de negocio
según 9 campos preestablecidos, mostrando las interconexiones
entre sus diferentes elementos que intervienen en el mismo. Los
puntos son: aliado clave, segmento de clientes, propuestas de
valor, canales, modelo de relación cliente-negocio, fuente de
ingresos, recursos a su disposición, actividades a realizar, y
estructura de costes.
Como aliado clave se tiene a la alcaldía de la ciudad de La
Paz, debido a que la empresa La Paz Bus es un derivado de ésta
institución, por lo que la opinión de ésta influye bastante sobre
las decisiones que llegue a tomar el Stakeholder, y por lo tanto,
en el proyecto.
Las actividades clave identificadas se basan en la fase de
elaboración, construcción y transición, éstas incluyen todo el
proceso de desarrollo, despliegue del sistema y mantenimiento.
Así mismo, se identificó el recurso humano como un recurso
clave para el proyecto, además de todas las herramientas de
software libre que se lleguen a utilizar.
Además de ofrecer una manera accesible y amigable de
consultar datos sobre la empresa, el valor agregado más
importante que se ofrece con el proyecto, es la posibilidad de
eliminar la incertidumbre del cliente a la hora de esperar un bus,
lo que ayuda de forma indirecta a que más personas utilicen el Figura 2. Ejemplo de conversación inicial.
servicio de transporte, ya que la incertidumbre e impaciencia son
dos factores muy importantes en ésta industria. La figura 2 está compuesta por una conversación la cual se hace
muy larga y capturas muestran una conversación con el chatbot, en ésta
Todos los potenciales usuarios del chatbot, son los usuarios se puede ver un mensaje de bienvenida luego de instalarlo, acompañado
del servicio. Se tiene como una gran facilidad que los buses de algunas de las consultas que puede realizar el usuario. Luego de esto
cuentan con monitores donde se puede hacer difusión del viene la que será la conversación más frecuente e importante del
chatbot, el cliente pregunta por un bus y el sistema detecta la parada en
producto, además, se puede agregar la difusión a través de los
la que se encuentra. Debido a que por esa parada pasan 2 rutas, se le
medios de comunicación y redes sociales si la alcaldía o la pide que seleccione cuál está esperando. Después de esto se busca el
empresa La Paz Bus lo deseara. Se lograría obtener ganancias bus más cercano y se informa de la última parada por la cual éste pasó,
no sólo al aumentar la afluencia de clientes del servicio, sino acompañado de un tiempo aproximado de espera. Cuando se avisa al
también por parte de las aplicaciones, ya que se pueden colocar sistema que el bus se está llenando, éste avisa al cliente por medio del
anuncios no invasivos y de los chatbot, sin embargo, al detectar que en la parada del cliente habrá
descensos, también se le hace saber.
 2) Estado del Bus 3) Avisos de desvíos

Figura 4. Avisos de desvíos

La figura 4 es una captura donde se puede observar un aviso de
desvío el cual es cargado por el administrador y luego es interpretado
por el chatbot para mostrarlo como un mensaje en la conversación,
avisando al cliente sobre el desvío y sobre las paradas alternativas
habilitadas que éste puede tomar. Éstas paradas se determinan
automáticamente, mostrando una parada antes y una parada después de
la(s) parada(s) inhabilitadas.
4) Información de la ruta

Figura 3. Estado del Bus

En la figura 3 se muestran 2 casos importantes. El primero es la
difusión de noticias de La Paz Bus y de la alcaldía en general, esto a
través del administrador, el cual publica noticias y avisos importantes,
el chatbot lo traduce para expresarlo como un mensaje en una
conversación. Lo que se puede observar luego es la interacción con el
usuario cuando éste pregunta por un bus sin estar en la parada, la
aplicación detecta la parada más cercana y luego de preguntar la ruta
que el pasajero quiere tomar, calcula el tiempo que tardará el bus hasta
llegar a la parada y el tiempo que le tomaría al pasajero caminar hacia
la misma parada. Se hace una diferencia y se determina si el cliente
tiene tiempo para llegar a la parada y alcanzar su bus. Posteriormente
se le informa al cliente amigablemente sobre el tiempo que tiene para
llegar a la parada.

Figura 5. Informacion de la ruta

En ésta conversación se puede observar cómo un cliente pide

información sobre una de las rutas del bus. Acto seguido, el chatbot
interpreta la solicitud y realiza una confirmación.
 Al recibir la confirmación, el chatbot accesa a la base de datos de
la empresa “La Paz Bus”, la cual contiene PDF’s de todas las rutas
disponibles, éste se carga y se envía como un archivo adjunto para que
el usuario pueda visualizar la ruta completa con cada parada.
B. Aplicación Anfitrion
1) Log in.
Figura 6. Log In
Como se puede ver en la imagen, el acceso a la aplicación para los
anfitriones estará restringida por un registro interno en un sistema
externo de la empresa, el mismo también asigna el bus que el anfitrión
atenderá ese turno, por lo cual todo el proceso de selección del bus en
el que éste va a trabajar se realiza de forma automática, redirigiendo
directamente a la pantalla principal que se describirá a continuación.
2) Pantalla principal
Figura 7. Pantalla principal
En la captura se muestra la pantalla principal y única de la aplicación
para el anfitrión. Al poseer una asignación automática, la aplicación
del anfitrión selecciona cual bus debe ser asignado desde el momento
del Log In, el cual, por éste mismo motivo, debe ser reintentado cada
vez que se cambie de turno. En la pantalla se puede ver un cuadro de
texto muy notable, indicando la parada registrada en la base de datos
como “última”, haciendo referencia a la última parada de la cual se
tiene registro que el bus pasó. Sigue un botón que cambia el TextBox
anteriormente mencionado, modificando la base de datos y cambiando
la parada por la siguiente en la lista, en caso de cometerse errores,
siempre se puede cambiar la última parada manualmente presionando
el botón “Desvío”, cuyo funcionamiento detallado se explica
posteriormente. Por último, los botones de “Descenso” y “Desvío”
muestran ventanas emergentes que permiten realizar sus respectivas
acciones en la misma vista de la aplicación.
3) Cambio de parada
Figura 8. Cambio de parada
Ésta captura muestra cómo el cuadro de texto superior cambia al
presionarse el botón verde, sin necesidad de preguntar cuál es la
siguiente parada o pedir una confirmación, esto debido a que la acción
debe realizarse lo más rápido posible. El cuadro de texto muestra la
información de la base de datos en tiempo real, por lo que, al cambiar,
se sabe que la base de datos se actualizó y se informó a los clientes que
solicitaron la información, recibiendo éstos las alertas explicadas en la
figura 2.
 4) Desvío
Figura 9. Desvio
La figura muestra todo el proceso al presionar el botón “Desvío”, ésta
función permite cambiar la última parada de manera manual, esto en
caso de existir desvíos de emergencia o haber cometido un error como
presionar el botón verde accidentalmente. Cuando el botón se presiona,
se muestra una lista en forma de ventana emergente para que el
anfitrión pueda seleccionar la última parada. Al ser seleccionada, se
muestra un mensaje de confirmación y se cambia el valor de la base de
datos.
5) Descenso
Figura 10. Descenso
Ésta captura muestra la ventana emergente generada cuando se
presiona el botón “Descenso”, ésta muestra una lista con tres opciones,
la opción seleccionada depende del número aproximado de personas
que desciendan en la siguiente parada, el cual es determinado por el
anfitrión a través de las cámaras del bus y de su percepción
C. Web App para Administrador
1) Log in
Figura 11. Log In
En esta captura se puede observar el banner de La Paz bus y el logo
de la alcaldía, también se observan dos formularios uno de usuario
donde se ingresa el nombre o id de usuario, el siguiente de password y
final un button de envió (ingresar) de formulario el cual envía la
información para su posterior búsqueda en la base de datos.
 2) Noticias y Avisos
Esta captura muestra la tercera opción Nueva ruta que consta de 3 box
de texto ,en el primero se provee información del nombre de la ruta ,
el label paradas que contiene los dos posteriores box de texto el
nombre y el número de parada con su respectivo button que agrega la
información a la tabla .La tabla tiene 2 opciones una que edita y otra
que elimina, también se cuenta con un box de despliegue en el cual se
selecciona la fecha y un button que guarda la información de la nueva
ruta

5) Cambiar Rutas

Figura 12. Noticias y avisos

Esta interfaz proporciona información a la base de datos por medio de

un formulario sobre las noticias y avisos que solo el administrador
tiene el permiso de proporcionar. Se cuenta con 4 opciones, la opción
Noticias/Avisos que tiene 2 radio buttons, una de notica y el otro de
aviso, se cuenta con un formulario y un button que cumple la función
de subir los datos a la BDD.

3) Desvíos
Figura 15. Cambiar rutas

Esta captura muestra la cuarta y última opción, Cambiar Ruta, que

es similar a la anterior opción, solo que esta opción modifica la ruta. Se
pueden apreciar de 3 box de texto, en el primero se provee información
del nombre de la ruta, el label paradas que contiene los dos posteriores
box de texto el nombre y el número de parada con su respectivo button
que agrega la información a la tabla..La tabla tiene 2 opciones una que
edita y otra que elimina, también se cuenta con un box de despliegue
en el cual se selecciona la fecha y un button que guarda la información
y modifica la ruta

V. REQUERIMIENTOS

Figura 13. Desvios A. REQUERIMIENTOS FUNCIONALES:

Código: RF-1
Esta captura muestra la opción de Desvíos la cual cuenta con varias Nombre: Pantalla de Inicio de Sesión
opciones de formulario 3 de despliegue y una de texto. La primera Funcionalidad: El sistema debe autentificar el
opción de despliegue muestra las rutas preestablecidas, la posterior usuario, ya sea por correo electrónico o redes sociales.
muestra opciones de paradas de la ruta ya seleccionada .En el box
texto se describe el motivo del desvió , se selecciona la fecha y un Código: RF-2
button que publica la información
Nombre: Interacción con el cliente
4) Nueva Ruta Funcionalidad: El chatbot debe poder entender el
idioma español y todos los modismos y
modificaciones que éste experimenta por la ciudadanía
paceña.

Código: RF-3
Nombre: Ubicación del bus
Funcionalidad: El sistema debe poder detectar qué
bus de la ruta necesitada está más cerca a la parada del
cliente y ofrecerle una devolución agradable, de tal
manera que el cliente no sienta que su tiempo de espera
es muy largo o molesto.

Código: RF-4
Figura 14. Nueva ruta Nombre: Concurrencia del bus
 Funcionalidad: El sistema tiene que devolver la
cantidad de espacios libres aproximados hasta la
parada del cliente, para que así éste pueda saber si el
bus que espera tiene o tendrá espacios para él y sus
acompañantes si los tuviera.

Código: RF-5
Nombre: Notificaciones de cambios en las rutas
Funcionalidad: El chatbot debe poder informar a los
clientes sobre cambios en las rutas, sean éstos de
emergencia o planificados previamente. Figura 16. Caso de uso Login

B. REQUERIMIENTOS NO FUNCIONALES 1.4 Procesos en que se Aplica

Código: RNF-1
Tipo: Requerimiento de seguridad
Nombre: Seguridad en el Log In
Funcionalidad: Los usuarios deben tener una sola
cuenta por correo
Código: RNF-2
Nombre: Aplicación multiplataforma
Funcionalidad: La aplicación se desarrollará en un
lenguaje que permita la distribución en Android e IOS.
Usuario ingresa a la app, le aparecerá la interfaz de registro. El
usuario tiene para poder registrarse de forma manual o
mediante la red social de Facebook. Usuario recibe un correo
con la confirmación de que el sistema pudo valorar los datos de
registro
2.2 Caso de uso: Cliente Preguntar Rutas
2.1 Descripción de Casos de Uso

Usuario puede interactuar con el sistema por medio de un chat,

Código: RNF-6 por el cual puede preguntar la ruta de un PumaKatari en
Tipo: Plataforma Operativa específico.
Funcionalidad: El sistema podrá accederse a través 2.2 Identificación de Actores y Casos de Uso
de cualquier dispositivo con conexión a internet.
CASO DE USO: PREGUNTAR RUTAS
ACTORES: CLIENTE
Código: RNF-4
Tipo: Versión del Hardware 2.3 Diagrama del Modelo y Casos de Uso
Funcionalidad: Las aplicaciónes móviles deben
poderse acceder a través de cualquier dispositivo
móvil que soporte aplicaciones desarrolladas en
Flutter. Así mismo, la aplicación web para el
administrador debe poder accerderse a través de
cualquier navegador web.
Figura 17. Caso de uso Preguntar rutas

VI. MODELO DE DOMINIO 2.4 Procesos en que se Aplica

A. CLASES DE USO.
El usuario ingresa al chatbot, donde podrá escribir la respectiva
Caso de uso: Cliente Login pregunta sobre la ruta del PumaKatari y esperará una resuesta,
casi inmediata dada por el chat bot.
1.1 Descripción de Casos de Uso

El usuario empieza se registra ya sea manualmente o mediante 3 Caso de uso: Cliente Estado del Bus
Facebook, el sistema al final de todo valida los daros
1.2 Identificación de Actores y Casos de Uso 3.1 Descripción de Casos de Uso

CASO DE USO: LOGIN Usuario puede interactuar con el sistema por medio de un chat,
ACTORES: CLIENTE por el cual puede preguntar sobre el estado del bus, es decir si
hay espacio, si hay asientos,etc.
1.3 Diagrama del Modelo y Casos de Uso
 3.2 Identificación de Actores y Casos de Uso
CASO DE USO: CLIENTE ESTADO DE BUS
ACTORES: CLIENTE
3.3 Diagrama del Modelo y Casos de Uso
Figura 18. Caso de uso Cliente-Estado de bus
3.4 Procesos en que se Aplica
El cliente ingresa al chatbot, realiza la pregunta sobre el estado
del bus, el sistema valida la pregunta, el chatbot responde de
forma inmediata.
4. Caso de uso: Cliente Parada Actual
4.1 Descripción de Casos de Uso
Usuario puede interactuar con el sistema por medio de un chat,
por el cual puede preguntar sobre la parada actual donde se
encuentre el bus en específico.
4.2 Identificación de Actores y Casos de Uso
CASO DE USO: CLIENTE PARADA ACTUAL
ACTORES: CLIENTE
4.3 Diagrama del Modelo y Casos de Uso
Figura 19. Caso de uso Cliente-Parada actual
4.4 Procesos en que se Aplica
El cliente ingresa al chatbot, realiza la pregunta sobre la parada
actual del bus, el sistema valida la pregunta, el chatbot responde
de forma inmediata.
5 Caso de uso: Cliente Nuevas Rutas
5.1 Descripción de Casos de Uso
Usuario puede interactuar con el sistema por medio de un chat,
por el cual puede preguntar sobre las nuevas rutas que tendrá el
PumaKatari.
5.2 Identificación de Actores y Casos de Uso
CASO DE USO: CLIENTE NUEVAS RUTAS
ACTORES: CLIENTE
5.3 Diagrama del Modelo y Casos de Uso
Figura 20. Caso de uso: Cliente-Nueva ruta
5.4 Procesos en que se Aplica
El cliente ingresa al chatbot, realiza la pregunta sobre las
nuevas rutas del PumaKatari, el sistema valida la pregunta, el
chatbot responde de forma inmediata.
6 Caso de uso: Cliente Lejos de un Parada
6.1 Descripción de Casos de Uso
El cliente entra al chatbot para preguntar sobre la parada del
puma, este responderá con la ubicación del bus y el tiempo
estimado de la parada más cercana del que se encuentra el
cliente
6.2 Identificación de Actores y Casos de Uso
CASO DE USO: CLIENTE LEJOS DE UNA PARADA
ACTORES: CLIENTE
6.3 Diagrama del Modelo y Casos de Uso
Figura 21.Caso de uso: Cliente lejos de una parada
 8.3 Diagrama del Modelo y Casos de Uso
6.4 Procesos en que se Aplica

Cliente Ingresa al chatbot, pregunta a cuánto está el bus de

dicha parada. El chatbot hace un cálculo de en cuánto tiempo
podrá llegar el bus a dicha parada

7 Caso de uso: Anfitrión Concurrencia

7.1 Descripción de Casos de Uso

El anfitrión tendrá su propia interfaz donde podrá poner la

concurrencia del bus, de esta forma actualizar la base de datos
en la nube, para cuándo el cliente necesite de esta información,
este disponible.
7.2 Identificación de Actores y Casos de Uso
CASO DE USO: ANFITRIÓN CONCURRENCIA
ACTORES: ANFITRIÓN, CLIENTE
7.3 Diagrama del Modelo y Casos de Uso
Figura 23. Caso de uso: Anfitrión parade actual
8.4 Procesos en que se Aplica
Anfitrión entra a su interfaz, actualiza parada, guarda
información; de esta forma se actualizará en la nube, y es así
como esta información estará disponible en el chatbot para el
cliente.

9. Caso de uso: Anfitrión Desvíos

9.1 Descripción de Casos de Uso

El anfitrión tendrá su propia interfaz donde podrá anunciar los

desvíos de emergencia, en caso de que exista uno, para que esta
información esté disponible en el chatbot para el cliente.
9.2 Identificación de Actores y Casos de Uso

CASO DE USO: ANFITRIÓN DESVÍOS

ACTORES: ANFITRIÓN, CLIENTE
Figura 22. Caso de uso:Anfitrión concurrencia
9.3 Diagrama del Modelo y Casos de Uso
7.4 Procesos en que se Aplica

Anfitrión entra a la interfaz de anfitrión para actualizar la

concurrencia del bus en la base de datos que se encuentra en la
nube, para que cuándo el cliente pregunte por el estado del bus,
este dato este disponible.

8 Caso de uso: Anfitrión Parada

8.1 Descripción de Casos de Uso

El anfitrión tendrá su propia interfaz donde podrá poner la
parada actual, de esta forma actualizar la base de datos en la
nube, para cuándo el cliente necesite de esta información, este
disponible
8.2 Identificación de Actores y Casos de Uso
CASO DE USO: ANFITRIÓN PARADA
ACTORES: ANFITRIÓN, CLIENTE
Figura 24. Caso de uso Anfitrión desvíos
9.4 Procesos en que se Aplica
Anfitrión entra a su interfaz, anuncia desvío de emergencia,
guarda información; de esta forma se actualizará en la nube, y
es así como esta información estará disponible en el chatbot
para el cliente.
10 Caso de uso: Administrador Noticias
 10.1 Descripción de Casos de Uso

Administrador tendrá su propia interfaz, donde podrá subir

noticias GAMLP, para que esté disponible para los clientes,
cuando estos pidan noticias al chatbot.

10.2 Identificación de Actores y Casos de Uso

CASO DE USO: ADMINISTRADOR NOTICIAS

ACTORES: ADMINISTRADOR, CLIENTE

10.3 Diagrama del Modelo y Casos de Uso

Figura 26. Caso de uso: Administrador Desvío

11.4 Procesos en que se Aplica

Administrador entra a su interfaz, sube noticias de GAMLP,

que se guardan en la nube, para que estas estén disponibles en
la plataforma de chatbot.

12 Caso de uso: Administrador Nuevas Rutas

Figura 25. Caso de uso: Administrador Noticias 12.1 Descripción de Casos de Uso

10.4 Procesos en que se Aplica
Administrador entra a su interfaz, sube noticias de GAMLP,
que se guardan en la nube, para que estas estén disponibles en
la plataforma de chatbot.
Administrador tendrá su propia interfaz, donde podrá actualizar
las nuevas rutas, para que esté disponible para los clientes,
cuando estos pidan noticias al chatbot.
12.2 Identificación de Actores y Casos de Uso

CASO DE USO: ADMINISTRADOR NUEVAS RUTAS

ACTORES: ADMINISTRADOR, CLIENTE, ANFITRIÓN
11 Caso de uso: Administrador Desvío
12.3 Diagrama del Modelo y Casos de Uso
11.1 Descripción de Casos de Uso

Administrador tendrá su propia interfaz, donde podrá anunciar

desvíos, para que esté disponible para los clientes y anfitriones.

11.2 Identificación de Actores y Casos de Uso

CASO DE USO: ADMINISTRADOR DESVÍO

ACTORES: ADMINISTRADOR, CLIENTE, ANFITRIÓN

11.3 Diagrama del Modelo y Casos de Uso

Figura 27. Caso de uso:Administrador Nuevas Rutas

 12.4 Procesos en que se Aplica
Administrador entra a su interfaz, actualiza las nuevas rutas,
estas rutas se guardan en la nube, para que estas estén
disponibles en la plataforma de chatbot y para el anfitrión.
13 Caso de uso: Administrador Actualizar Paradas
13.1 Descripción de Casos de Uso
Administrador tendrá su propia interfaz, donde podrá actualizar
las nuevas rutas, para que esté disponible para los clientes,
cuando estos pidan noticias al chatbot.
13.2 Identificación de Actores y Casos de Uso
CASO DE USO: ADMINISTRADOR ACTUALIZAR
PARADAS
ACTORES: ADMINISTRADOR, CLIENTE, ANFITRIÓN
13.3 Diagrama del Modelo y Casos de Uso
Figura 28.Caso de uso: Administrador-Actualizar paradas
13.4 Procesos en que se Aplica
Administrador entra a su interfaz, actualiza las paradas, estas
paradas se guardan en la nube, para que estas estén disponibles
en la plataforma de chatbot y para el anfitrión.
B. DIAGRAMA DE CLASES
El diagrama de clases incluye la relación entre las
diferentes clases que fueron analizados para crear la aplicación
.
VII. ARQUITECTURA DE SOFTWARE
Para cumplir con los requerimientos a cabalidad, y
evaluando los posibles riesgos que podrían presentarse, los
cuales se explican en el documento de visión, se determinó
desarrollar un sistema compuesto por tres módulos, los cuales
serán asignados a los anfitriones de los buses, al personal
encargado de la planificación de rutas y a los clientes
respectivamente. Siendo aplicaciones móviles para clientes y
anfitriones y una aplicación web para el personal encargado de
las rutas.
Como se especifica en los requerimientos, las aplicaciones
móviles serán desarrolladas en Flutter, permitiendo así que se
pueda acceder a ellas sin importar el sistema operativo. Así
mismo, la aplicación web será desarrollada con “Angular 6.
Todos los módulos compartirán una base de datos en Firebase.
El servidor del chatbot será construido utilizando el
framework “Sping Boot” de Java, teniendo una base de datos
no relacional basada en documentos que se replique en Firebase
y apoyándose en las herramientas “DialogFlow” de Google y la
librería ElasticSearch.js para poder permitir las modificaciones
lingüísticas de la población paceña.
VIII. PLANIFICACIÓN
Para la planificación de la gestión del proyecto, se realizó un
diagrama de Gantt que se puede ver en los anexos del documento
 REFERENCES
The template will number citations consecutively within
brackets [1]. The sentence punctuation follows the bracket [2].
Refer simply to the reference number, as in [3]—do not use
“Ref. [3]” or “reference [3]” except at the beginning of a
sentence: “Reference [3] was the first ...”
Number footnotes separately in superscripts. Place the actual
footnote at the bottom of the column in which it was cited. Do
not put footnotes in the abstract or reference list. Use letters for
table footnotes.
Unless there are six authors or more give all authors’ names;
do not use “et al.”. Papers that have not been published, even if
they have been submitted for publication, should be cited as
“unpublished” [4]. Papers that have been accepted for
publication should be cited as “in press” [5]. Capitalize only the
first word in a paper title, except for proper nouns and element
symbols.
For papers published in translation journals, please give the
English citation first, followed by the original foreign-language
citation [6].
[1] G. Eason, B. Noble, and I. N. Sneddon, “On certain integrals of Lipschitz-
Hankel type involving products of Bessel functions,” Phil. Trans. Roy.
Soc. London, vol. A247, pp. 529–551, April 1955. (references)
[2] J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol.
2. Oxford: Clarendon, 1892, pp.68–73.
[3] I. S. Jacobs and C. P. Bean, “Fine particles, thin films and exchange
anisotropy,” in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New
York: Academic, 1963, pp. 271–350.
[4] K. Elissa, “Title of paper if known,” unpublished.
[5] R. Nicole, “Title of paper with only first word capitalized,” J. Name
Stand. Abbrev., in press.
[6] Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, “Electron spectroscopy
studies on magneto-optical media and plastic substrate interface,” IEEE
Transl. J. Magn. Japan, vol. 2, pp. 740–741, August 1987 [Digests 9th
Annual Conf. Magnetics Japan, p. 301, 1982].
[7] M. Young, The Technical Writer’s Handbook. Mill Valley, CA:
University Science, 1989.
IEEE conference templates contain guidance text for
composing and formatting conference papers. Please
ensure that all template text is removed from your
conference paper prior to submission to the
conference. Failure to remove template text from your
paper may result in your paper not being published.