Synchdrive

Integrantes

• Julian Benitez
• Luis Pizza
• Juan Ospina

Indice

• Resumen
• Arquitectura Backend - Synchdrive
  • Diagrama de Clases - Modelo
  • Diagrama de Entidad-Relación
  • Diagrama de Componentes
• Arquitectura Backend - Uber
  • Diagrama de Clases - Modelo - Uber
  • Diagrama de Entidad-Relación - Uber
  • Diagrama de Componentes - Uber
• Arquitectura Backend - Beat
  • Diagrama de Componentes - Beat
• Arquitectura Backend - Didi
  • Diagrama de Componentes - Didi
• Arquitectura Frontend
• Arquitectura Despliegue
• Diagrama de Casos de uso
• Atributos No Funcionales
  • Usabilidad
  • Escalabilidad
  • Seguridad
  • Disponibilidad
  • Rendimiento (Performance)
• Continuidad de desarrollo - Github
• Despliegue - Heroku
• Manual de Uso
• Enlace a las Historias de Usuario
• Estado del Backend de Synchdrive

Resumen

Actualmente se ofrece una gran variedad de aplicaciones que proporcionan el servicio de transporte contactando a los pasajeros con los vehículos registrados en sus plataformas. Esto resulta beneficioso tanto para el conductor generando utilidades con su automóvil, como para el pasajero que pueden viajar a gusto. El problema radica en que la mayoría de los conductores y usuarios manejan dos o más de las aplicaciones móviles disponibles, les resulta tedioso tener que abrir y cerrar las aplicaciones, en el caso de los usuarios para comparar precios, servicios y solicitar diversos servicios, como para los conductores a la hora de buscar y aceptar los servicios. Tomando en cuenta esta problemática surgió Synchdrive una aplicación web en donde los diferentes usuarios podrán interactuar con las diferentes aplicaciones de transporte en las que estén registrados para poder así tomar la mejor decisión en cuanto al servicio que se requiera según el caso.

Arquitectura Backend - Synchdrive

El backend se está desarrollando en el siguiente repositorio

Diagrama de Clases - Modelo

Diagrama de Entidad-Relación

Diagrama de Componentes

Arquitectura Backend - Uber

El backend se está desarrollando en el siguiente repositorio

Diagrama de Clases - Modelo - Uber

Diagrama de Entidad-Relación - uber

Diagrama de Componentes - Uber

Arquitectura Backend - Beat

Diagrama de Componentes - Beat

Arquitectura Backed - Didi

Diagrama de Componentes - Didi

Arquitectura Frontend

Arquitectura Despliegue

Diagrama de casos de uso

Atributos No Funcionales

Usabilidad

Escenarios

Escenarios de pedir/aceptar servicios.

1. Source: Usuario final (Conductor/Usuario del aplicativo).
2. Stimulus: Usar el sistema eficientemente.
3. Artifact: Servidores Frontend, servidor backend, servidores de bases de datos, servidores de aplicativos externos.
4. Enviroment: Aplicación ejecutandose en condiciones normales.
5. Response: Es sencillo, tanto para pedir como aceptar servicios, a cada tipo de usuario.
6. Response Measure: El conductor realiza 1 click para aceptar un servicio. El usuario, después de configurar sus preferencias y destino, realiza 1 click para solicitar el servicio.

Escenario

Escenarios de visualización de historial de servicios.

1. Source: Usuario final (Conductor/Usuario del aplicativo).
2. Stimulus: Verificar que el sistema haya registrado correctamente la toma de un servicio.
3. Artifact: Servidores Frontend, servidor backend, servidores de bases de datos.
4. Enviroment: Aplicación ejecutandose en condiciones normales.
5. Response: Facilidad para identificar los servicios que se han aceptado/pedido.
6. Response Measure: Tanto el usuario como el conductor ingresan con un click a sus historiales.

Escenario Conductor

Escenario Usuario

Escalabilidad

Escenarios

1. Vertical: Escenario de escalamiento vertical para la base de datos de la aplicación principal.
   1. Source: Usuarios finales.
   2. Stimulus: Al momento de solicitar servicios.
   3. Artifact: Servidor Backend, Servidores Frontend, servidor de base de datos.
   4. Enviroment: En condiciones de ejecución normales.
   5. Response: Se guardan los servicios generados en la base de datos.
   6. Response Measure: La respuesta del servidor es, en promedio, 10ms más rápida con el escalamiento vertical.

Link al video

1. Horizontal: Escenario de escalamiento horizontal para servidor externo “Uber”.
   1. Source: Usuarios finales.
   2. Stimulus: Interactuar con cualquier funcionalidad de la aplicación.
   3. Artifact: Servidor externo Uber.
   4. Enviroment: En condiciones de ejecucíon normales.
   5. Response: El balanceador de carga, dependiendo del estado de la máquina, realiza la petición a dicha máquina.
   6. Response Measure: La respuesta es aproximadamente 200ms más rápida que tener un solo servidor.

Link al video 1

Link al video 2

Seguridad

Escenarios

1. Source: Usuario no autorizado
2. Stimulus: Acceder a un recurso de la API
3. Artifact: Servidor Backend
4. Enviroment: En condiciones normales
5. Response: El servidor deniega la petición
6. Response Measure: Se muestra un código de error HTTP 401 indicando que el usuario no está autenticado.

Disponibilidad

Escenarios

Escenario de escalamiento horizontal para servidor externo “Uber”.

1. Source: Usuarios finales.
2. Stimulus: Pedir un servicio.
3. Artifact: Servidor externo Uber.
4. Enviroment: En condiciones de falla de un servidor externo.
5. Response: El balanceador de carga detecta que una máquina quedó inactiva.
6. Response Measure: Ninguna petición realizada al servidor externo “Uber” es denegada.

Link al video

1. Source: Usuarios finales
2. Stimulus: Actualizar datos del usuario
3. Artifact: Servidor Frontend y Servidor backend
4. Enviroment: En condiciones de falla en la base de datos.
5. Response: El cache del servidor backend funciona sin necesidad de guardar hasta que la base datos se recupere.
6. Response Measure: El usuario no detecta ninguna anomalía al momento de actualizar su perfil mientras que la base de datos no tome más de 5 minutos para recuperarse.

Link al video

Rendimiento (Performance)

Escenarios

Escenario de aceptar servicio

1. Source: Usuario final (Conductor)
2. Stimulus: El tiempo que toma entre aceptar un servicio un conductor y se le notifique a todos los conductores.
3. Artifact: Servidores Frontend, servidor backend, servidores de bases de datos.
4. Enviroment: Aplicación ejecutandose en condiciones normales.
5. Response: El servicio tomado se desaparece del resto de conductores.
6. Response Measure: Cuando un conductor acepta un servicio se demora menos de 1 segundo notificar al resto.

Link al video

Escenario notificación que se ha aceptado un servicio

1. Source: Usuario final (Usuario del aplicativo)
2. Stimulus: El tiempo que toma un usuario en ver que un conductor ha tomado el servicio.
3. Artifact: Servidores Frontend, servidor backend, servidores de bases de datos.
4. Enviroment:Aplicación ejecutandose en condiciones normales.
5. Response: El usuario cambia de pestaña al momneto de que un conductor acepete el servicio.
6. Response Measure: Cuando un conductor acepta un servicio, el usuario cambia de pestaña en menos de 1 segundo.

Link al video

Continuidad de desarrollo - Github

El proyecto se está desarrollando en la organización arsw-starsoft

Despliegue - Heroku

El despliegue se realizó en Heroku

Manual de Uso

En el siguiente enlace podemos encontrar la página inicial de la aplicación, aquí se puede elegir el registro ya sea de conductor o usuario y los respectivos login.

Pagina de incio

User

• Cuando le damos la opción de Sign Up User encontraremos 3 casillas las cuales nos permitirán tener la información básica de la aplicación como lo es el username, el correo y la contraseña. Cuando se le da la opción de Sign Up este nos avisara por medio de una notificación si ha sido exitosa o no. Si es exitosa nos redirigía hacia otro enlace que el cual contiene el respectivo login.

• En el enlace de login podremos colocar el respectivo correo electrónico con el cual nos registramos y la contraseña, cuando seleccionamos el botón de login podremos acceder a la aplicación siendo usuario de las aplicaciones de transporte.

• En el perfil del usuario podremos acceder a toda la información que se tiene dentro de la aplicación desde ahí podremos actualizar los datos suministrados.

• Si se desea realizar cualquier modificación de la información se debe acceder a los espacios asignados dependiendo de lo que se quiera modificar ya sea desde información básica como nombre hasta las cuentas asociadas que se pueden tener y luego accionar el botón de update user, Luego nos aparecerá un mensaje el cual nos dirá el estado de la petición, si es exitosa podremos ver que la información ha sido cambiada y cada vez que se intente acceder al perfil esta información se mantiene.

• Se podrá acceder a los servicios prestados por la aplicación donde el usuario podrá elegir los diferentes tipos de servicios que desea dependiendo de las aplicaciones seleccionadas los filtros necesarios y numero que desee pedir. y además podrá ver el mapa la ubicación donde se encuentra el usuario al momento de pedir un servicio.

• Luego, de que el usuario seleccione el destino, los filtros que desee y el número de servicio, se pasará a seleccionar el botón de buscar servicio, al momento que se oprima el botón aparecer una imagen de carga y un botón de cancelar el servicio, el cual nos permitirá en dado caso que no se requerirá mas este viaje, poder realizar la cancelación de los servicios que hayamos creado.

• Cuando se hayan aceptado cada uno de los servicios que se requirió, se pasará a otra pestaña la cual contenderá la información del conductor que acepto el último servicio.

Driver

• Cuando le damos la opción de Sign Up Driver encontraremos 4 casillas las cuales nos permitirán tener la información básica de la aplicación como lo es el username, el correo, la contraseña y el numero de celular.

Cuando se le da la opción de Sign Up este nos avisara por medio de una notificación si ha sido exitosa o no. Si es exitosa nos redirigía hacia otro enlace que el cual contiene el respectivo login.

• En el enlace de login podremos colocar el respectivo correo electrónico con el cual nos registramos y la contraseña, cuando seleccionamos el botón de login podremos acceder a la aplicación siendo usuario de las aplicaciones de transporte.

• En el perfil del driver podremos acceder a toda la información que se tiene dentro de la aplicación desde ahí podremos actualizar los datos suministrados.

• Si se desea realizar cualquier modificación de la información se debe acceder a los espacios asignados dependiendo de lo que se quiera modificar ya sea desde información básica como nombre hasta las cuentas asociadas que se pueden tener y luego accionar el botón de update user, Luego nos aparecerá un mensaje el cual nos dirá el estado de la petición, si es exitosa podremos ver que la información ha sido cambiada y cada vez que se intente acceder al perfil esta información se mantiene.

• Se podrá acceder a los servicios prestados por la aplicación para el conductor, donde el podrá elegir los diferentes tipos de servicios que desea ofrecer en las aplicaciones que seleccione y también el tipo de servicios que desea ver con prioridad dependiendo de los filtros escogidos. Además podrá ver la posición exacta del conductor en el mapa que se ve en la imagen.

• Cuando, el usuario publique el servicio y el driver tenga activo para aceptar el servicio, en la columna de la izquierda abajo de las aplicaciones seleccionadas por el driver, aparecerá los servicios que se encuentran disponibles para que cada driver los pueda aceptar.

• Cuando el driver seleccione el servicio que desea aceptar, aparecerá una nueva pestaña, en la cual confirmara que ha sido aceptado el servicio con la información principal, que es el destino, precio y customer.

• Una vez tanto como a un usuario como un conductor, se le ha aceptado o ha aceptado un servicio, en su historial se ven reflejados, realizando click en “My History” se pueden ver el ID del servicio, la aplicación a la que pertenece, el conductor/usuario del servicio, el destino y el precio.

Enlace a las Historias de Usuario

Estado del Backend de Synchdrive