Presentación e slayer final

Adrià Solé
Albert Lozano
Carlos Pardo
MASTEAM Fran Carpio
Disseny de Xarxes i Aplicacions Telemàtiques Ricardo Herrera

´
Índice

1. Descripción del proyecto
2. Análisis de la aplicación
3. Diseño del sistema
4. Tecnologías utilizadas
5. Estudios de uso
6. Planificación
7. Conclusiones

2

´
Índice
1.1. ¿Qué es eSlayer?

5. Estudios de uso
6. Planificación
7. Conclusiones

3

´
Descripción del proyecto
1.1 ¿Qué es eSlayer?

• Juego multijugador en línea en tiempo real para móviles con sistema operativo
Android.

• Objetivo principal: sobrevivir eliminando al resto de jugadores.

• Información, tutorial, visualización de estadísticas y ranking a través de la página
web.

4

´
Índice
2.1. Descripción de la aplicación móvil
2.2. Descripción de la aplicación web

5. Estudios de uso
6. Planificación
7. Conclusiones
5

Análisis de la aplicación
´
2.1. Descripción de la aplicación móvil

• Cada jugador tiene un avatar.

• Cada jugador tiene asignado un objetivo que no conoce (el avatar de otro
usuario) al que debe eliminar.

• El jugador obtiene pistas SOBRE EL AVATAR de su objetivo (para reconocerlo)
cubriendo necesidades (comiendo, yendo a clase,…).

• Publicación de eventos en Twitter/Facebook.

• Objetivo Principal:

Sobrevivir eliminando al resto de jugadores.

6

´
2.1 Descripción de la aplicación móvil

• Autenticación
1

3.2 Necesidades

1 2 3.1 3.3 Ver pistas

Autenticación Seleccionar partida Menú Jugador

3.4 Ver Jugadores

7

´

1 Autenticación:

• Mediante Facebook o Twitter.

• Autenticación: se redirige al usuario a la página de Facebook/Twitter para
aceptar los términos de privacidad, o para loguearse si no lo está.

8

´

2
• Seleccionar partida

3.2 Necesidades



3.4 Ver Jugadores

9

´

2
• Seleccionar Partida:

• Unirse a partida ya creada o Crear Partida.

• La partida empieza cuando se ha unido un
determinado número de jugadores.

• Una vez la partida ha empezado, NO se
pueden unir más jugadores.

• Posibilidad de visualizar información
sobre la partida.

• La partida acaba cuando sólo queda un
superviviente o cuando pasa un tiempo
determinado.

10

´

3.1 Menú Jugador
•

3.2 Necesidades



3.4 Ver Jugadores

11

´

3.1 Menú Jugador:
•

• Información de nuestro jugador (foto, avatar
eSlayer).

• Balas: Cada vez que se dispara a un jugador que no
sea tu objetivo, se pierde una bala. Si te quedas sin
balas, no puedes disparar durante un tiempo
determinado.

• Tiempo restante: Tiempo que queda para dar la
partida por finalizada.

12

´

3.2 Necesidades
•

3.2 Necesidades



3.4 Ver Jugadores

13

´

3.2 Necesidades:
•

• Cada X minutos, se deben saciar unas necesidades
(ir al baño, comer, …).

• Recompensa por saciar una necesidad: obtener
una pista.

• Para saciar una necesidad debes capturar un
DETERMINADO código QR con el móvil.
Ejemplo:

Si tienes que comer, debes capturar el
código QR localizado en el bar de la escuela.

14

´

3.3 Ver Pistas
•

3.2 Necesidades

1 2 3.1 3.3 Ver Pistas

Autenticación Seleccionar partida

3.4 Ver Jugadores

15

´

3.3 Ver Pistas:

• Se obtienen al cubrir necesidades.

• Las pistas dan información acerca del AVATAR de
tu objetivo o de las zonas donde ha estado tu
objetivo.

• Los avatares son asignados automáticamente por
el servidor para evitar que hayan dos avatares
completamente iguales.

16

´

3.4 Ver Jugadores
•

3.2 Necesidades



3.4 Ver Jugadores

17

´

3.4 Ver Jugadores:
•

• Permite ver información acerca de los jugadores que siguen vivos en la partida:
• Foto Red Social, avatar eSlayer, muertes totales.
• Listar ubicaciones donde ha estado a lo largo de la partida (donde ha capturado QRs).

• Permite disparar a tus rivales.

18

´

• Diagrama de Casos de Uso:

19

´

• Información importante:
• Cada jugador tiene asignada un objetivo y a la vez es el objetivo de otro
jugador.
• Herencia de objetivos: al acabar con tu víctima, tu nuevo objetivo pasará a ser
el antiguo objetivo de tu víctima.
Mari Mari

Juan Ana Juan Ana

Jose Jose

• Herencia de pistas: Al heredar el objetivo de tu víctima, también heredarás las
pistas que ésta tenía sobre su objetivo.

20

´
2.2. Descripción de la aplicación web

• Ofrece información sobre la aplicación eSlayer (descripción, cómo se juega, … ).

• Link QR para descargar la aplicación
desde el móvil.

• Ranking semanal de jugadores.

• Buscador de jugadores (visualizar
perfiles).

• Información sobre los
desarrolladores del proyecto.

21

´
2.1 Descripción de la aplicación web

• Diagrama de Casos de Uso:

• La administración del servidor des del portal web no se ha realizado debido al
limitado tiempo al que se ha estado expuesto.

22

´
Índice
3.1. Servidor web
3.2. Cliente Android

5. Estudios de uso
6. Planificación
7. Conclusiones

23

Diseño del sistema
3.1 Servidor Web

• Utiliza servicios web para la comunicación con la
Servidor BD
aplicación móvil.
Recibe petición-> solicita servicio a capa lógica -> devuelve respuesta de
capa lógica al usuario. Servidor Web

• Aloja el portal web de la aplicación (para la conexión Lógica de la aplicación
mediante PCs).
Recibe petición-> solicita servicio a capa lógica -> devuelve respuesta de
capa lógica al usuario. Servicios
Portal Web
Web
• Capa lógica: se encarga de la mecánica de las operaciones

HTTP (REST)

HTTP + JSON

HTTP
HTTP
y el acceso a la base de datos.
Recibe solicitudes de servicios web y portal web -> procesa solicitudes
accediendo a BD -> devuelve respuesta a servicios web y portal web.

24

Diseño del sistema
3.1 Servidor Web

Ejemplo: “Juan” quiere matar a “Jose”

Mato a Jose ¿Jose es la
victima de Juan?

¿Juan puede
matar Si
a jose?
¿Quién era la
victima de Jose?

Maria BD
Jose está muerto

María es el
objetivo de Juan
Has matado a Jose,
tienes un Servicios Si
Lógica de la
Juan nuevo objetivo Web aplicación

25

Diseño del sistema
3.1 Servidor Web


Mato a Jose

¿Juan puede
RESTJuego matar GestorUsuarios
a Jose?

GestorPartidas
RESTPartidas

GestorNotificaciones
GestorGeneral
Has matado a Jose, RESTUsuarios
tienes un
Juan nuevo objetivo Si
GestorJuego
RESTNecesidades

utils GestorPistas

...

gestores

26

Diseño del sistema
3.1 Servidor Web

hibernate
HibernateUtil

¿Juan puede
matar GestorUsuarios
a Jose?

BD
GestorPartidas

GestorNotificaciones
GestorGeneral

Si
GestorJuego
PartidaUsuario

GestorPistas

... Usuario
...

gestores models

27

Diseño del sistema
3.1 Servidor Web

• Seguridad en Servicios Web:
• Utilización del Estándar OAuth:
• Usuario utiliza access token para autenticarse.
• El access token lo genera la aplicación al recibir el request token.
• Sólo el usuario que ha enviado el request token puede utilizar el access
token (el access token está ligado al request token).
• Las peticiones se realizarán con el id de usuario de facebook/twitter,
único y no conocido (no consultable en los servicios web).
Usuario Servidor
Get Request token
Grant Request token

Get Access token
Grant Access token

Mata a Dani + access token

Dani ha muerto

28

Diseño del sistema
3.1 Servidor Web

• Base de datos

29

Diseño del sistema
3.2 Cliente Android

• Adapters
• Encargado de mostrar las diferentes listas que aparecen en el juego.

• Activities
• Contiene todas las actividades del juego(diferentes pantallas).

• Facebook/Twitter
• SDK Facebook 3.0 encargado de cargar la interfaz de Facebook en el login.
• Clase necesaria para la redirección a Twitter para el login.
• Métodos para post en twitter/facebook.

• Utils
• Notificaciones (Polling cada 30 segundos al servidor)
• Comunicación con el servidor
• Shared Preferences (guardar preferencias en memoria del teléfono)
• JSON Parser, cronometro …

30

Diseño del sistema
3.2 Cliente Android

31

´
Índice
4.1. Aplicación móvil
4.2. Portal web
4.3. Servicio web
4.4. Base de datos
4.5. Herramientas de desarrollo
5. Estudios de uso
6. Planificación
7. Conclusiones

32

Tecnologias utilizadas
´
4.1 Aplicación móvil

• Desarrollada para el SO Android de Google: plataforma abierta con mayor
número de usuarios.
• Autenticación y autorización a través de Twitter/Facebook.
• Uso de la operación polling para la sincronía con el servicio web.

4.2 Portal web

• Java: lenguaje de programación de alto nivel orientado a objetos.
• HTML: lenguaje de marcado para la elaboración de las páginas web.
• CSS: lenguaje usado para definir la presentación de un documento
estructurado escrito en HTML o XML.
• Ajax:
- Conjunto de técnicas para el desarrollo de aplicaciones web
asíncronas.
- Se ejecuta en el cliente y mantiene una comunicación con el servidor
asíncrona en segundo plano.
33

´
4.3 Servicio web

• REST:
- Técnica de arquitectura software para sistemas distribuidos como WWW.
- Permite hacer llamadas a un webservice mediante peticiones HTTP sin la
necesidad de implementar un cliente específico.
- Más ligero que SOAP.
• JSON:
- Estándar basado en texto diseñado para el intercambio de datos de fácil
lectura.
- Deriva de Javascript y se trata de un formato más ligero que XML.
• Java Servlet:
- Tecnología Java utilizada que amplia las capacidades del servidor.
- Corren dentro de un contenedor de servlets (pe. Tomcat).
- Puede comunicarse sobre cualquier protocolo cliente-servidor.
- Fácil integración con otras partes del proyecto ya hechas en Java.

34

´
4.4 Base de datos
RDBMS:
- Sistema de gestión de una base de datos relacional.
- SQL es el lenguaje diseñado para la gestión de datos dentro de RDBMS.
- Usaremos MySQL como servidor SQL (Open-Source).

4.5 Herramientas de desarrollo
Apache Wicket:
- Framework para el diseño de aplicaciones web: HTML (diseño) y JAVA
(comportamiento). Uso transparente de AJAX. Fácil desarrollo.

Apache Maven:
- Herramienta de software para la gestión y construcción de proyectos Java.
- Se basa en el concepto de Project Object Model (POM) para describir el
proyecto de software a construir, sus dependencias a otros módulos y
componentes externos .
- Incluye automáticamente las dependencias necesarias para arrancar un
proyecto.
35

´
4.5 Herramientas de desarrollo
• Android SDK: API para el desarrollo de aplicaciones para Android.
• SVN: Sistema de control de versiones.
- Ofrece la posibilidad de que varias personas puedan modificar y administrar
el mismo conjunto de datos desde sus respectivas ubicaciones.
- Privacidad en los proyectos (a diferencia de GitHub).
• Jersey: API en Java para la implementación de servicios web RESTful.
• JPA: Entorno de desarrollo que gestiona datos relacionales en aplicaciones Java.
Evita tener que diseñar bases de datos y clases Java por separado. Pensado para
RDBMS.
• Hibernate:
- Implementa la API de JPA.
- La relación se realiza mediante archivos XML o anotaciones.
• Log4j: biblioteca “open source” desarrollada en Java que permite a los
desarrolladores de software elegir la salida y el nivel de granularidad de los
mensajes o “logs” (trace, debug, error, etc.).

36

´ Índice
5. Estudios de uso
5.1. Estudio de demanda
5.2. Estudio de uso

6. Planificación
7. Conclusiones
37

Estudios de uso
5.1. Estudio de demanda

• Titulaciones en la EETAC:
• Grados: Sistemas de Telecomunicación, Telemática, Aeronavegación,
Aeropuertos.
• 25 alumnos/grado · 4 grados/cuatrimestre · 2 cuatrimestres/año · 4 años
= 800 alumnos
• Másteres oficiales: MASTEAM, MAST, GEONA
• 20 alumnos/Máster · 3 Másteres/cuatrimestre · 2 cuatrimestres/año · 4
años = 480 alumnos
• Personal docente de la EETAC: alrededor de 150 profesores.
• Posibles usuarios de la aplicación: 1430 usuarios.

38

Estudios de uso
5.2. Estudio de uso

• Estadísticas del juego: a partir de los datos almacenados en la BBDD SQL.
• Relacionaremos esta información con la que ofrece el software de gestión
sacando conclusiones sobre el uso de la aplicación.
• Estudio de la aplicación móvil: se analizarán requisitos y consumo.
• Diferentes tipos de móviles Android.
• Diferentes tipos de conexión: GPRS, 3G o WiFi.
• Los estudios se realizarán de forma regular para disponer de una muestra más
grande:
• Se sacarán mejores conclusiones para optimizar la aplicación.

39

Estudios de uso
5.2. Estudio de uso

• Se ha estimado:
• La duración de las partidas.
• El tiempo que se tarda en completar una necesidad.

• Condiciones inciales:
• Número jugadores: entre 3 y 5.
• Tiempo de recarga de bala: 1 min.
• Tiempo de generación de necesidad: 1 min.
• QR’s cercanos.

40

Estudios de uso
5.2. Estudio de uso

• Duración de las partidas:
• N=31
• α=0,9 [129,84s<m<233,58s]
• α=0,95 [121,75s<m<241,67s]
• α=0,99 [103,09s<m<260,33s]

• Tiempo para completar una necesidad :
• N=81
• α=0,9 [35,13s<m<76,15s]
• α=0,95 [31,13s<m<80,15s]
• α=0,99 [23,5s<m<87,78s]

41

´
Índice

5. Estudios de uso
6. Planificación
6.1. Metodología Scrum

7. Conclusiones
42

Planificacion
´

• El proyecto se ha desarrollado de forma incremental (sprints) realizando, de forma
regular, entregas parciales (incrementos) del producto final.

• Dentro del marco de trabajo definido por Scrum existen diferentes roles:

• Propietario del producto: Toni Oller y Eduard Garcia (representa al cliente).
• Scrum manager: Ricardo (gestiona y facilita la ejecución del proceso).
• Equipos de desarrollo:
• Portal web: Ricardo y Adrià (Wicket).
• Lógica: Ricardo, Carlos y Adrià (Java).
• Cliente móvil: Fran, Daniel, Albert(Android).
• Base de datos: Ricardo y Carlos (Hibernate).
• Interesados: profesores DXAT (asesoran y observan).

43

Planificacion
´

• El product backlog (esta presentación) es el punto de partida. Explica, a alto nivel,
el trabajo a realizar.

• El proyecto se ha completado en 5 sprints de 2 semanas. Las tareas completadas a
en cada sprint fueron:

• 1er sprint: implementación básica Web y cliente Android.
• 2º sprint: diseño BBDD y servicios web ofrecidos.
• 3er sprint: implementación BBDD y primeros servicios Web.
• 4º sprint: implementación temporizadores y continuación de servicios Web.
• 5º sprint: debug de la primera versión funcional y recolección de estadísticas.

44

Planificacion
´

45

´
Índice

5. Estudios de uso
6. Planificación
7. Conclusiones

46

Conclusiones
• Subversion nos ayuda a trabajar de forma coordinada.
• Maven facilita el uso de diferentes librerías añadiéndolas automáticamente en el
proyecto.
• Existen muchas APIs que nos permiten trabajar con diferentes tecnologías sin tener
que implementar métodos propios.
- Por ejemplo Jersey ya ofrece soporte para OAUTH.
• Los servicios web RESTful son útiles para la interacción con clientes escritos en
lenguajes distintos.
- Inconveniente: seguridad.
• Scrum nos ofrece un método de organización que se ha adaptado muy bien a las
características de este proyecto.
- Nos permitió desarrollar de manera incremental a la vez que nos
familiarizamos con las distintas tecnologías.
• A pesar de no ser expertos en tecnologías concretas, hemos adquirido autonomía
suficiente para afrontar con seguridad futuros retos en lo que a desarrollo de
aplicaciones se refiere.

47

Presentación e slayer final

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Presentación e slayer final