portaljuegos.wdfiles.comportaljuegos.wdfiles.com/local--files/entregas/DocEnero.… · Web viewEl...

IStationDocumentación de Enero

Cristian Barrio YáñezEzequiel DenegriJonás Fernández ReviejoGuillermo Frontera SánchezConrado Javier García MontielDaniel Garijo VerdejoPatricia Hernández LlodraEduardo HombradosJesús Ismael López Pérez

Beatriz Martín GuadañoGerardo Martín MorenoDaniel Merchán GarcíaSantiago Novoa BenditoIsaac Pérez EstradaLara Quijano SánchezRubén Jesús Ruiz CuadradoPablo Sagardía HidalgoVíctor Senovilla Marcos

1

Índice _______________________________________

Tema pág.

1 Historias.................................................................................................5Historia de un desarrollador.........................................................................................5

Historia de un administrador........................................................................................5

Historia de un nuevo jugador.......................................................................................6

Historia de un forero....................................................................................................7

Historia de un juego.....................................................................................................7

2 Interfaces................................................................................................9

Portada.........................................................................................................................9

Estadísticas globales..................................................................................................10

Unirse a una partida...................................................................................................10

Crear una partida: las 7 y Media................................................................................11

Interfaz de juego: La Oka...........................................................................................11

Interfaz de juego: Las 7 y Media................................................................................11

3 Tecnologías...........................................................................................13

El entorno de desarrollo de juegos.............................................................................13

Perfil de administrador...............................................................................................13

Visión del usuario.......................................................................................................13

Sección de juegos.......................................................................................................13

Sección de foros.........................................................................................................13

Sección de estadísticas y logros.................................................................................13

Sección de amigos y buscador de jugadores.............................................................13

2

Tecnología de la interfaz y del servidor de juego.......................................................14

Software instalado en los laboratorios.......................................................................14

4 Casos de uso.........................................................................................16

Registrar usuario........................................................................................................16

Identificar usuario......................................................................................................16

Elegir o crear una partida a un juego para jugar........................................................17

Crear una partida.......................................................................................................17

Unirse a una partida...................................................................................................18

Consultar estadísticas................................................................................................18

Añadir amigos............................................................................................................19

Aceptar un amigo.......................................................................................................19

Participar en los foros.................................................................................................19

Añadir/gestionar noticias............................................................................................20

Gestionar foros...........................................................................................................21.................................................................................................................................

Gestionar usuarios (moderador).................................................................................21

Obtener Framework...................................................................................................22

Enviar juegos..............................................................................................................22

Instalar sistema..........................................................................................................23

Instalar juegos............................................................................................................23

Gestionar usuarios (administradores)........................................................................24

Salir de un juego........................................................................................................24

Jugar a las 7 y Media..................................................................................................25

Crear una partida para las 7 y Media.........................................................................25

3

Actualizar estadísticas................................................................................................26

Hablar con los demás usuarios de una partida..........................................................26

Configurar una partida...............................................................................................26

Evaluar los juegos enviados por los desarrolladores..................................................27

Enviar mensaje dntro del chat...................................................................................28

Enviar susurro dentro del chat...................................................................................28

Personalizar el chat....................................................................................................29

5 Riesgos.................................................................................................30

El protocolo es inadecuado para los juegos que hagamos.........................................31

El proyecto no funciona en los puestos de laboratorio...............................................31

No se dispone de un servidor para ejecutar la aplicación..........................................32

Bajas permanentes del personal (por bajas médicas, abandono de la asignatura, etc.)......................................................................................................................32

El personal no es capaz de adquirir los conocimientos..............................................33

Mala estimación en el tiempo necesario para completar las características fundamentales del proyecto.................................................................................33

Falta de tiempo para realizar características secundarias.........................................33

Incompatibilidad de horarios entre los miembros del grupo......................................34

La aplicación es demasiado lenta como para ser usable...........................................34

Discrepancias en el grupo..........................................................................................34

Falta de iniciativas entre los miembros del grupo......................................................35

La aplicación es excesivamente grande.....................................................................35

El portal no tiene aceptación por parte de los usuarios.............................................35

La tecnología de cliente usada presenta limitaciones................................................36

Los grupos de trabajo no se coordinan y/o no son capaces de comprender su tarea36

4

6 Control de calidad..................................................................................37

7 Glosario.................................................................................................39

8 Secciones del portal...............................................................................41

9 Plan de fase...........................................................................................42

10 Plan de Iteración Enero..........................................................................44

11 Protocolos.............................................................................................51

Comunicaciones.........................................................................................................51

12 Diseño de componentes.........................................................................53

Módulo cargador.........................................................................................................53

Módulo de comunicaciones........................................................................................54

Módulo de chat (servidor)..........................................................................................62

Módulo de base de datos...........................................................................................63

Módulo de log.............................................................................................................67

Módulo de chat (cliente).............................................................................................68

Módulo de juegos.......................................................................................................71

13 Implementar juegos...............................................................................72

Framework cliente......................................................................................................72

5

Historias ____________________________________ Las historias son descripciones de posibles situaciones que se encuentran los usuarios al utilizar la aplicación.

Historia de un DesarrolladorGrifin estaba aburrido en casa. Cansado de la Web, decide acabar con su tedio: “¡Quiero mi propio juego, estoy harto de la maldita Oka! Me gustaría un Warcraft™ con gráficos de God Of War™". Para ello, raudo y veloz, se pone en contacto con un administrador y descubre que hacer esto no es posible, pero quizás sí sea posible cumplir su sueño, jugar al parchís online. Cordialmente recibe de parte del administrador el frame-work sobre el cual trabajar (Cu13) . En pocos días y tras muchas noches sin dormir, un divorcio, y unos intentos de suicidio, el juego está acabado. Ha nacido el PowerParchis v3 con soporte online. Grifin se lo manda al administrador deseoso de que este acepte su juego!pues cumple todos los requisitos que se le habian pedido! y está super orgulloso e su trabajo!!!Y…hay SUERTE!el administrador lo valida! y sin que sea necesario recompilar el código, coloca el juego en la Web como un módulo independiente (Cu14) . Al rato… ¡ya es un éxito! Lo ha conseguido, ¡Grifin es famoso! Lástima que con el esfuerzo desmesurado de las noches sin dormir para tener a punto el juego, y gracias a la comida basura, el estrés, ayudado por el colesterol, cierra para siempre sus ojos, su vida se apaga, y muere… Pero siempre nos quedará su legado…

Historia de un AdministradorÉrase una vez, en un reino de fantasía donde en todos los PC's funcionaban todos los juegos, en lo más alto de la más alta torre, donde el WiFi se extendía por todos sus dominios, vivía un administrador (o admin). Éste poseía un buen ordenador. Quizás con no mucho espacio en disco, pero sí el suficiente para albergar unos cuantos juegos del portal, así como la base de datos. Tenía por madre a una mujer tan buena, que nunca le hacía apagar el PC, por lo que siempre podía estar dando servicio. Incluso ella estaba registrada y participaba en los foros de vez en cuando, con sus seudónimos PRubio o PilarR, pues tenía varios para no ser reconocida. Pero hablemos del admin en sí.Este chico empezó sólo con la base de datos, pero al poco recibió el primer juego: como ya tenía instalado el soporte de los juegos en su pc desde hacía unos días (Cu15), instaló la Oka, uno de los grandes juegos de esta web. Estaba aún recién hecho, podríamos decir que fue una beta. Él lo instaló fácilmente en su servidor, ya que solo era un zip, y con las herramientas proporcionadas por la web todo resultaba genuinamente sencillo (Cu16). Más adelante, a medida que surgían actualizaciones para el juego, fue borrándolo e instalando versiones más avanzadas que solucionaban fallos, y también fue instalando muchos otros. Además de vez en cuando recibía los datos de un nuevo usuario y se encargaba de revisarlos en la base de datos. En ocasiones los usuarios querían cambiar sus datos, incluso algunos "listillos" querían ser moderadores ya que sus mujeres les tenían reprimidos y querían algo de libertad de decisión. No había problema, él era el dueño y señor de la Web, y lo podía hacer (Cu17). Y como él, muchos más administradores por todo el mundo se encargaban de que la web estuviera siempre funcionando y de solucionar los problemas de los usuarios.

Gracias a ellos, tenemos un portal funcionando día tras día, y por muchos años seremos felices y comeremos perdices.

6

http://portaljuegos.wikidot.com/casos-de-uso#cu17





Historia de un Nuevo JugadorUn día estaba encerrado en mi casa como de costumbre, esperando la cordial llamada de alguno de los pocos conocidos que tengo, cuando a mitad de mi suculento sandwich de Nocilla se me encendió la bombilla y dije “¡¡Qué maravilla!!” cuando, de repente, saltó un banner en el chat en el que estaba:

NUEVO PORTAL ON-LINE DE JUEGOS!!!!DIVERSIÓN A RAUDALES ASEGURADA

GERVÁS WANTS YOU!!

“¡Dios santo!” exclamé, “me busca a mí, lo estaba esperando toda mi vida”. Entré y se abrió un nuevo mundo de posibilidades para mí. Lo primero que hice fue fliparlo en colores con su interfaz gráfica: qué exquisita combinación de colores, imágenes y fuentes de texto, y sus ingeniosas ilustraciones para atraer al personal. En seguida vi que era necesario el registro y cuál fue mi sorpresa cuando no podía hacer log-in (pensé que ya estaría registrado desde mi nacimiento: era mi destino encontrar esta página). Antes de unirme a esta increíble comunidad de ocio on-line, decidí darme una vuelta por el foro, a ver si la gente era cool (chatis guays, personas “normales” como yo o incluso amigos nuevos). A los pocos segundos vi que no éramos todos tan diferentes, todo el mundo come Nocilla, y me decidí: “¡¡Sí, me registraré!!” Volví al inicio y entré al formulario, esperando algo muy complicado. Cuál fue mi sorpresa al ver que en pocos minutos acabé. ¡Muy sencillo todo! (Cu1) "Por fin alguien piensa en mí". Sólo necesité una dirección de correo, mi nick y mi clave. Acto seguido me logueé, impaciente por comenzar (Cu2). Entonces lo descubrí: “¡La Oka, mi juego favorito de la infancia!” Con lágrimas en los ojos entré a jugar (Cu3). Rápidamente cargó el gestor de juegos. Tenía varias opciones: crear una partida o unirme a otras ya creadas. Intenté entrar en una partida (Cu5), dirigida por una tal chica-sexy, pero no pude, no tenía nivel suficiente. En el chat de la antesala — porque hay un chat, estos chicos han pensado en todo — pregunté, y me contestaron que para subir de nivel sólo necesitaba jugar y mucho. Preparé un termo de café: esta noche no debía dormir, había que jugar lo máximo posible. Rápidamente, creé una nueva partida (Cu4) y me salieron amigos por todas partes (¡como con los donetes!). Aquí comenzó mi leyenda dentro de la página.Tras una semanas de juego continuo, subí de nivel, tanto que la mayoría de los que estaban en mi partida, les entraban unas ganas intensas de practicar el acto de expulsar orín y abandonaban la partida (Cu18). Para comprobar mis puntos exactos, me metí en la zona de estadísticas. Había diversas opciones: podía consultar mis propias estadísticas, pero también los récords de cada juego en concreto (Cu6). Ya estaba más cerca del objetivo: entrar en la partida de chica-sexy, pero, ¡lástima!, al meterme a su partida tampoco me dejó (Cu5), ¡mierda!, yo me había viciado a las 7 y Media y se ve que esta web es de lo mejorcito, porque tiene estadísticas individuales de cada juego. Yo era muy malo jugando a la Oka, por lo que intenté acceder a chica-sexy de otra manera: añadiéndola como amiga para así poder acosarla con mensajes románticos (Cu7). Pero qué pena, ella no me quiso aceptar (Cu8), así que agregué a un tal Megacoleg@, el cual con mucho gusto me aceptó (Cu8) y chateamos y chateamos a todas horas… ¡Al fin tengo un amigo!

7












Historia de un ForeroA MegaColeg@ no le gustaban los juegos, de ningún tipo, lo que en principio hizo que rechazara la web. Pero antes de abandonarla para siempre, vio en la barra de opciones algo que le llamó la atención: "FORO". Sin mucha ilusión fue a mirarlo, ya que no le hizo falta registrase para hacerlo (Cu9) — vamos, a darle una oportunidad — y descubrió que la gente de aquel foro no sólo hablaba de juegos, como de costumbre, sino que había temas interesantes (al menos a su parecer) "¿Y por qué no? ¡Voy a postear!" pensó. Se registró para que la gente lo conociera (también podría haber posteado como anónimo) (Cu1). Se logueó (Cu2) y enseguida empezó posteando en un tema abierto sobre Symbian (recientemente había comprado un N82 y no tenía mucha idea) y allí poco a poco aprendió a usarlo.

Pasados unos meses, no había día en que Megacoleg@ no escribiera al menos 5 posts cada jornada (Cu9). Para él era algo muy importante. Todo lo que sabía lo había aprendido allí y ahora quería ayudar a los demás. Pero algo aún no le convencía: estaba cansado de la gente que fastidiaba las conversaciones con tonterías y chorradas y sólo buscaba bronca. Gracias a la sección de contacto, pudo comunicarse con los administradores y fundadores de la web, el equipo que un día comenzó todo esto como una práctica de IS, y tras muchas deducciones por su parte y pasar un exhaustivo examen, decidieron que Megacoleg@ fuera moderador. ¡Es justo lo que él quería! Aquí comenzó su cruzada, el nuevo caballero lucharía por la seguridad en los foros. Tendría a partir de ahora permisos para eliminar posts para nada gratos, como aquella chica que cada día escribía 15 posts para saludar a sus gatos (Cu11).

No creáis que ser moderador es fácil, debes actualizar las noticias cada día si quieres triunfar,para que la gente se entere de cosas fundamentales como el famoso: "¿¡Por qué no te callas!?" (Cu10), debe de reprimir tus propios impulsos, pues no puedes censurar un post de alguien sólo porque te caiga mal. Todo lo que hagas tiene que estar justificado. Pero Megacoleg@ no tuvo problemas con esto, fue un moderador modelo, incluso tenía en cuenta quién ponía continuamente posts salidos de contexto y, cuando pasaba a menudo, se ponía en contacto con los administradores. En algun caso, nuestro amado héroe llegó a echar de la base de datos al usuario en cuestión (Cu12), y así, Megacoleg@ demostró que Internet no sirve sólo para jugar y ver porno, sino que también se pueden aprender cosas y convivir sin violencia.

¡¡Gracias Megacoleg@!!

Historia de un JuegoA Godrik le daba envidia que Darkcamper llevara 8 años en la 1ª posición de las ¡¡¡7 y Media!!! y ver su cara todos los días en las noticias del portal. Por ello, aburrido de jugar siempre a la Oka y ver que no ganaba ni sobornando a sus oponentes, decide que ¡las 7 y Media puede ser su fuerte y por fin tener la hegemonía y el reconocimiento en alguno de los juegos!

Pero claro, primero debía conocer las reglas de dicho juego. Gracias al fácil manejo del interfaz y de sus opciones, encuentra las reglas tan bien explicadas que cree ya ser un experto capaz de derrotar al temido Darkcamper (Cu19).

Fascinado por la facilidad del interfaz del juego decide que es hora de empezar a jugar millones de partidas con el fin de cumplir su sueño: ¡Ser el Dios de las 7 y Media! (Cu20) y que su nombre sea portada del portal (lo cual le hará famoso en él).

8










Durante las partidas, Godrik se encuentra con unos controles de juego sencillos (los cuales hasta puede modificar), unas cartas más bonitas que las que le regaló su tía Cipriana y en todo momento sabe de quién es el turno de la partida. Pero claro, Godrik no puede esperar eternamente que Herminia piense su jugada por lo que observa un bonito contador que limita el tiempo de pensar la jugada a cada jugador. A raíz de esto, Godrik nervioso, sabe que no puede irse a comer un helado mientras está en medio de una partida, por lo que se encuentra muy atento para decidir si levantará carta o se plantará. Por otro lado Godrik está asustado de qué pasará si sus oponentes se van de la partida antes de que acabe, "¿No ganaré puntos para el ranking?" Pero, Godrik está de suerte. Será informado en cada finalización de partida de los puntos que obtiene o pierde tras jugar la partida (Cu21) y nuestro intrépido usuario se dará cuenta que aquellos que abandonen serán ¡penalizados! y reirá viendo cómo ha obtenido puntos de forma muy fácil (no tantos como si hubiera sido una partida completa).Tras 4 meses de dura lucha, ¡Godrik consigue superar a Darkcamper! Feliz con el acontecimiento, cree que el trabajo ya está hecho. Será noticia, alabado y famoso (Cu10). Sin embargo, si no juega con frecuencia a las 7 y Media perderá puntos gradualmente, por lo que deberá arriesgar su hegemonía cada cierto tiempo.

Godrik era muy feliz. Pero Darkcamper, recuperado de su gripe aviar, vuelve al juego. Darkcamper da un repaso a Godrik en todas las partidas, y relega a nuestro joven amigo al 2º puesto. En la última partida con su eterno rival, Godrik cansado de perder decide abandonar la partida ya que sus mensajes privados a Darkcamper de "¡QUÉ SUERTE TIENES!" empiezan a ser repetitivos. Para ello dispone de un bonito botón en el menú que le permite rendirse y así quedar humillado ante el eterno campeón (Cu18,Cu22).Finalmente Godrik decidió probar de nuevo con otro juego, alejado de Darkcamper.

9





Interfaces ___________________________________ Las interfaces deben mostrar toda la información mencionada en las historias y casos de uso. La disposición y funcionalidades particulares de cada una pueden estar todavía indefinidas hasta que termine la discusión sobre el asunto.

PortadaLa siguiente imagen muestra el aspecto de la página que aparece al entrar en el portal. Este diseño trata de seguir todas las decisiones acordadas por el grupo, aunque hay muchos detalles que pueden variar.

Comentarios: En la pantalla principal tendremos la opción de logearnos, o de registrarnos por primera vez. Algo necesario para poder ver y acceer al resto de las aplicaciones el servidor. Lo que si podemos hacer sin logearnos es ver las cosas que en esta pagina se muestran, la portada ( con distintas informaciones, estadisticas..etc), acceder a información sobre los creadores de la página y contactar con ellos.En todas las pantallas que veremos siempre hay una opción buscar que te permite encontrar a un jugador o juego.

10

Estadísticas Globales

Comentarios: En esta imagen se supone un usuario ya registrado e identificado en la página. En la parte superior izquierda te permite hacer logaout o ver tus atos d usuario. En cuanto a las estadisticas, en portada se verán las de los juegos en tablas, con sus top10. También lo podemos dar a la opción estadisticas de cada jugador, y te aparecera una tabla por cada jugador registrado y su top10. Finalmente se podrá acceder a las estadisticas particulares del jugador logeado. En todas las pantallas que veremos siempre hay una opción buscar que te permite encontrar a un jugador o juego.

Unirse a una partida

11

Crear una partida: Las 7 y media

Interfaz de juego: La Oka

Interfaz de juego: Las 7 y mediaVersion 1

12

Version 2

13

Tecnologías _________________________________ El entorno de desarrollo de juegosEl desarrollador necesita acceder a la página tanto para descargar el frame-work como para enviar el juego desarrollado.Para desarrollar juegos sólo será necesario disponer de un compilador para el lenguaje para el que se cree el frame-work (JAVA).Casos de uso: Cu13, Cu14.

Perfil de administradorDurante la instalación se utiliza la base de datos para crear las tablas necesarias para que funcione la web. Se usará tecnología web para la administración del portal (PHP).El administrador podrá añadir los juegos desarrollados al portal, gracias a una aplicación web (PHP). Además, podrá gestionar las noticias del portal.Casos de uso: Cu15, Cu16, Cu10.

Visión del usuarioEl acceso al portal de un usuario implica una validación del registro en la base de datos (SQL). Tanto la validación como el registro inicial, se hacen a través de dicha base de datos.Casos de uso: Cu1, Cu2.

Sección de juegosLa búsqueda de juegos en el portal será por web (PHP). Por otro lado, al iniciar un juego será un applet de Java lo que se mostrará al usuario.Casos de uso: Cu3, Cu18.

Sección de forosPara la realización del foro se utilizará tecnología web, en este caso PHP.Casos de uso: Cu11, Cu9.

Sección de estadísticas y logrosLas estadísticas estarán recogidas en la base de datos, la cual se consultará y modificará al terminar cada partida o cuando quiera el usuario ver sus propias estadísticas o las de cada juego (SQL).Casos de uso: Cu6.

Sección de amigos y buscador de jugadoresPara mostrar la lista de amigos del usuario y para añadir nuevos amigos se hará uso de la base de datos a través de la web. Para conocer los usuarios amigos conectados, se hará mediante la base de datos también (SQL).Casos de uso: Cu7, Cu8.

14















Tecnología de la interfaz y del servidor del juegoCuando se inicia el juego, las tecnologías usadas son applets JAVA como interfaz del cliente, tecnologías de comunicación TCP/IP para la comunicación con el servidor de juegos.

ClienteAPPLETS JAVA. Actúa en todas las interacciones del usuario con la interfazTCP. En cada acción que pida comunicación con el servidor, creación de partida, chat de texto y durante el juego para cada acción.LIBRERIAS GRÁFICAS. Para mostrar interfaces en los casos mas complejosTECNOLOGÍAS ESPECÍFICAS. Para el chat por voz, transmisión web-cam, etc.Casos de uso: Cu1, Cu2.

ServidorAPLICACIÓN JAVA. Gestiona todo lo relacionado con el juego desde la fase de creación hasta la finalización del mismo.TCP. Para comunicar con el cliente datos relacionados con el desarrollo del juego, y el Chat de texto por cualquier necesidad que se tenga puntualmente.ACCESO BASE DE DATOS. Necesario para la búsqueda de posibles adversarios, cargr las configuraciones del juego, guardar estadísticas al finalizar el juego, obtención de estadísticas antes de jugar para garantizar las restricciones configuradas por el creador de la partida, y actualizar la lista de partidas en curso que usa el portal. La tecnología para este caso será SQLCasos de uso: Cu3,Cu4,Cu5.

Software Instalado en los Laboratorios:Software instalado en los laboratorios que puede ser utilizado para nuestro proyecto:

Apache + tomcat +Mysql Apache2 + tomcat5 Apache2 + tomcat6 ArgoUML boUML eclipse 3 eclipse 3.1 Eclipse 3.2.2 Eclipse plugin UML Studio JCreator LE 2.50 JDK 1.4.1 JDK 1.4.2 JDK 1.5 JDK 1.6 MySQL 5 NETBEANS 5 NETBEANS 5.5 Oracle Client + Developer 9i Oracle Client 10g

15






PHP

16

Casos De Uso _______________________________ Registrar usuario (Cu1)

Objetivo Obtener los datos del usuario y validarlos para que pueda definir una cuenta.

Prerrequisitos Tener una cuenta de correo electrónico.

Actores Usuario.

Acciones 1. Introducción de los datos que identifican al usuario.2. Notificación al usuario de la creación de la cuenta.

Extensiones 2a. Error en los datos introducidos.2b. El usuario ya está registrado.

Comentarios Los errores 2a y 2b son recuperables mediante la reinserción de los datos.

RNF1. Terceras personas no tendrán acceso a los datos privados de los usuarios.2. El servidor tiene capacidad "virtualmente" ilimitada para alojar usuarios.

Identificar usuario (Cu2)Objetivo Entrar en el sistema.

Prerrequisitos Estar registrado

Actores Usuario, moderador.

Acciones 1. Introducción del identificador y contraseña.2. Entrada en el sistema como usuario registrado.

Extensiones1a. Identificador no existe en la BD.1b. Contraseña incorrecta.2a. Error en la BD

Comentarios

Error 1a: te permite el registro de ese usuario o la reinserción de datos.Error 1b: permite el reingreso del password o la posibilidad de recordar la contraseña.Error 2a: responsabilidad del administrador.

17

RNF1. El servidor tiene capacidad "virtualmente" ilimitada para dar un tiempo de respuesta decente para cualquier número de usuarios en línea.

Elegir o crear una partida a un juego para jugar (Cu3)

Objetivo Seleccionar a un juego para jugar creando una partida o uniéndose a una ya creada.

Prerrequisitos Estar identificado como usuario.

Actores Usuarios

Acciones

1. Seleccionar el juego de la lista de juegos disponibles.2. Una vez seleccionado el juego se abre una nueva ventana en la que podremos:2.1.Crear una partida (Cu4)2.2.Unirse a una partida (Cu5)3. Esperar hasta el inicio del juego4. Jugar

Extensiones3a.Los usuarios pueden abandonar la partida mientras están esperando al inicio.4a. Si un usuario se sale del juego será penalizado por ello,(obteniendo puntuación negativa).

Comentarios

RNF 1. El juego tardará un tiempo razonable en cargar.

Crear una partida (Cu4)Objetivo El usuario crea una partida del juego seleccionado.

Prerrequisitos Seleccionar un juego

Actores Usuarios

Acciones1. Seleccionar crear partida1.1. Configurar las opciones de la partida (Cu23)2. Esperar a jugadores.3. Iniciar partida

18

Extensiones

Comentarios

RNF 1. El servidor tendrá capacidad para un número elevado de partidas.

Unirse a una partida (Cu5)Objetivo Unirse a una partida ya creada

Prerrequisitos Seleccionar un juego

Actores Usuarios

Acciones1. Seleccionar la partida a la que nos queremos unir de la lista de partidas.2. Esperar a que el creador la inicie.

Extensiones 1a. La partida está llena

Comentarios Error 1a. Se informa al usuario de que no se admiten más jugadores y se le devuelve a la pantalla de selección de partida.

RNF

Consultar estadísticas (Cu6)Objetivo Consultar las estadísticas propias y/o de otros usuarios.

Prerrequisitos Estar identificado como usuario

Actores Usuarios

Acciones1. Seleccionar la opción de estadísticas.2. Seleccionar el juego del que queremos seleccionar la estadística.3. Visualización de las estadísticas.

Extensiones1a. Si la opción no está disponible, no se mostrarán las estadísticas. Se mostrará un mensaje informativo.1b. Si no está el juego con la opción de estadísticas activada podrá salir de las estadísticas o elegir la estadística de otro juego.

Comentarios

19

RNF 1. La base de datos tendrá un tiempo de respuesta decente.

Añadir amigos (Cu7)Objetivo

Cada usuario registrado podrá tener una lista de usuarios a los que conozca, con el fin de saber cuáles de ellos están conectados y poder enviarles mensajes privados.

Prerrequisitos Ser un usuario registrado e identificado.

Actores Usuarios

Acciones1. Entrar en la pestaña amigos.2. Hacer clic en añadir un amigo.3. Introducir el nombre de usuario que queremos añadir como amigo.

Extensiones3a. Si el nombre es correcto, el usuario en cuestión recibirá un mensaje privado.3b. No existe el nombre del usuario al que el usuario quiere añadir como amigo.

Comentarios Error 3b. Se informa al usuario de que el usuario que se quiere añadir no está registrado.

RNF 1. Un jugador tendrá la posibilidad de añadir cuantos amigos quiera.

Aceptar un amigo (Cu8)Objetivo Aceptar la invitación de amistad de otro usuario.

Prerrequisitos

Ser un usuario registrado e identificado y haber recibido un mensaje de invitación de otro usuario.

Actores Usuarios

Acciones1. Dentro de la página de inicio, entrar en los mensajes privados recibidos.2. En el mensaje de invitación, aceptar o rechazar la amistad.

Extensiones

Comentarios

RNF

20

Participar en los foros (Cu9)

Objetivo

El objetivo es que el usuario pueda tener acceso a los foros, accediendo desde la página principal de una forma sencilla e intuitiva, y pueda participar tanto pasiva (leyendo los posts de otros usuarios) como activamente (escribiendo ya en temas existentes o creando nuevos temas)

Prerrequisitos

Para la consulta de determinados foros no será necesario ningún requisito previo (salvo la conexión a internet claramente). En caso de querer añadir nuevos posts o consultar temas de secciones privadas el usuario deberá haberse registrado previamente y estar autentificado.

Actores Usuarios

Acciones

1. Acceder al portal web.2. Si no está registrado en el portal proceder al registro (Cu1) en caso de querer.3. Identificarse en el portal (Cu2)4. Acceder a la sección de foro5. Seleccionar una opción como “empezar nuevo tema”, o elegir un tema ya abierto donde participar6. Si empieza nuevo tema se introducirán datos como el título y contenido.7. Al entrar en un tema se visualiza su contenido y se da una opción de añadir una respuesta a dicho tema

Extensiones4a..7a. Un acceso en estas condiciones sin estar identificado (en caso de estar intentando participar en partes que requieran autentificación) provocará que se le soliciten al usuario sus datos de identificación (Cu2).

Comentarios

RNF 1. El servidor tendrá capacidad para alojar un número "ilimitado" de mensajes.

Añadir / gestionar noticias (Cu10)

Objetivo El moderador subirá periódicamente a la página noticias, pudiendo editar las que ya existan.

Prerrequisitos El usuario deberá estar identificado como moderador.

Actores Moderador

21

Acciones

1.Seleccionar en la página de noticias la opción de añadir noticias o editar las noticias ya existentes.2. Una vez que ha elegido una de las dos opciones, aparecerá una nueva página en la que se podrá realizar el cometido.3. El moderador enviará la nueva noticia o la noticia editada

Extensiones 2.b. Si el contenido de la noticia es incorrecto(p.e. en blanco), se avisa al usuario y volvemos al paso 2.

Comentarios

RNF

Gestionar foros (Cu11)Objetivo Cerrar hilos de conversación y borrar mensajes.


Actores Moderador

Acciones1. Seleccionar la opcion de cerrar el tema y eliminar mensajes en el menú de moderador.2. Elegir el tema a borrar o cerrar en los foros.3.El tema seleccionado se borrará o cerrará según lo elegido.

Extensiones

Comentarios

RNF

Gestionar usuarios (moderador)(Cu12)

Objetivo Banear del sistema a los usuarios registrados.


Actores Moderador

Acciones 1. Seleccionar en el menú de moderador la opción para ver la lista de usuarios.

22

2. Seleccionar los usuarios a banear de la lista que aparece.3.Confirmar la selección por seguridad.

Extensiones 2.b. Si el usuario a banear es moderador, no se podrá realizar y no habrá cambios en el sistema. Se alertará de ello.

Comentarios

RNF

Obtener Framework (Cu13)Objetivo Permitir a los desarrolladores obtener los archivos necesarios para

fabricar sus propios juegos para ser ejecutados como parte del portal

Prerrequisitos

Un desarrollador debe estar registrado y autentificado antes de poder descargar el software

Actores Desarrolladores

Acciones 1. Seleccionar en el interfaz la opción de “Desarrollo”2. Seleccionar un framework disponible y pulsar en “Descargar”

Extensiones

1a. Cualquier error se tratará como en el caso de uso de Identificaciones2a-3a. Un error inesperado en esta parte provocará un mensaje de error sin posibilidad de continuar el proceso así como un mensaje automatizado al administrador del sitio.

Comentarios

RNF

Enviar juegos (Cu14)Objetivo

Proporcionar a los desarrolladores un método para poder mandar juegos nuevos a un administrador para evaluarlos antes de ser colgados definitivamente en el portal

Prerrequisitos

El desarrollador deberá estar registrado e identificado como usuario del portal

Actores Desarrollador

Acciones 1. Seleccionar la opción de “Desarrollo”2. Seleccionar la opción “Enviar Juego”

23

3. Rellenar el formulario con los datos solicitados incluyendo como adjunto el archivo conteniendo el juego4. Aceptar el envío.

Extensiones 3a Si falta alguno de los datos solicitados, se le volverá a mostrar el formulario al usuario para que lo complete correctamente.

Comentarios

RNF

Instalar sistema (Cu15)Objetivo Preparar desde cero el software necesario para la correcta ejecución

del portal/servidor de juegos

Prerrequisitos

Es necesario tener acceso a equipos con hardware suficiente para ejecutar las aplicaciones y que cuente con algún tipo de conectividad.

Actores Administrador

Acciones

1. Hacer login si es necesario en el equipo(s) que vayan a contener las aplicaciones.2. Cargar los archivos necesarios para el portal y el servidor de juegos en la máquina servidor con la ayuda del instalador facilitado.3. Instalar los juegos deseados con ayuda del interfaz suministrado (Cu16)

Extensiones

1a-2a: Los errores en este punto como fallos de login, o falta de permisos no se pueden solventar a nivel de aplicación y se informará al Administrador para que contacte con la persona apropiada.3a. Si algún archivo de juego está corrupto se procederá a no instalarlo continuando con el resto del proceso si el Administrador así lo elige

Comentarios

RNF

Instalar juegos (Cu16)Objetivo Permitir añadir nuevos juegos al portal

Prerrequisitos Estar identificado como Administrador del portal

24


Acciones

1. Elegir la opción de “Administración”.2. Seleccionar en el interfaz la localización del archivo de juego a instalar.3. Revisar los datos que proporcione la aplicación y si son satisfactorios pulsar en “Aceptar” para proceder a la instalación

Extensiones 3a Si el fichero está corrupto se notifica por pantalla al Administrador y no se le deja aceptar la instalación.

Comentarios

RNF

Gestionar usuarios (administrador)(Cu17)

Objetivo Gestionar la lista de usuarios así como sus permisos(en caso de que fueran moderadores).

Prerrequisitos Estar identificado como Administrador


Acciones

1. Seleccionar la opción “Administración”.2. Seleccionar la opción "Gestionar usuarios".3. Realizar los cambios en la lista de usuarios mediante las opciones del interfaz.4. Revisar los cambios y confirmarlos (o rechazarlos)

Extensiones 3a y 4a Si falla de modo irrecuperable se notificará al Administrador y se volverá a la página principal

Comentarios

RNF

Salir de un juego (Cu18)Objetivo Abandonar una partida durante el transcurso de la misma

Prerrequisitos Estar jugando a un juego

25

Actores Usuario

Acciones1. Seleccionar el botón de Salir de la partida.2. Seleccionar "Sí" en una ventana por si se pulsó de manera errónea.3. Seleccionar OK, en la ventana de Fin de partida.

Extensiones1a Puede pulsar erróneamente el botón de Salir de partida, si da a "No" en la ventana que emerge volverá a la partida.3a Una vez fuera, se redirige al usuario a la sala de selección de partida.

Comentarios

RNF

Jugar a las 7 y media(Cu19)Objetivo Proporcionar una interfaz para que el usuario pueda jugar a este

juego.

Prerrequisitos

Estar metido en esa partida.Que la partida haya comenzado (esta acción la realiza el creador de la partida).

Actores Usuario

Acciones

1. El jugador pide una carta: tiene dos botones a elegir1.1 “Pedir carta boca arriba” 1.2 “Pedir carta boca abajo”.1.1 Le aparece la carta por pantalla y al resto de los integrantes de la partida también.1.2 Le aparece la carta por pantalla pero al resto de los integrantes le aparecesólo una carta del revés.2. Espera a que el resto de los jugadores, realizan la misma acción.3. Analiza su situación, y decide:3.1 Se planta y no quiere mas cartas. 3.2 Pide otra carta. 3.3 Tiene siete y media.3.1 Espera a que el resto de jugadores se planten.3.2 Repite 1 y 2.3.3 ¡Ha ganado! Le aparece el mensaje de triunfo por pantalla. Se le sumanlos puntos correspondientes por su victoria. La ronda se acaba.4. Si no ha ganado, espera a que el resto de jugadores acabe, es decir, se planteno saquen 7 y media. Cuando todos estén plantados, automáticamente semuestran por pantalla todas las cartas de todos los jugadores. Y …4.1 si sus cartas son las que más se aproximan a 7 y media el jugador gana,le aparece el mensaje de triunfo por pantalla y se le suman los puntos correspondientes por su victoria. La ronda se acaba.4.2 Gana otro jugador y se acaba la ronda.

26

Extensiones3.2a: Si tenía las cartas boca arriba puede darle al botón de “Pedir carta boca arriba” “Pedir carta boca abajo”. Si las tiene boca abajo aparece disponible el botón de pedir cartas boca arriba.

Comentarios Las figuras valen media y el resto de las cartas su valor.

RNF

Crear partida para las 7 y media (Cu20)

Objetivos El usuario crea una partida del juego de las siete y media.

Prerrequisitos Entrar en la sala del juego las siete y media.

Actores Usuarios

Acciones

1. Seleccionar crear partida(Cu4)2. Configurar las opciones de la partidaNúmero máximo de jugadores (con 40 cartas recomendado 8 jugadores máximo)Número de rondasAsignación de un rango de nivel para que el jugador pueda participarCantidad inicial de fichas del usuarioPermitir espectadores3.Esperar a jugadoresEl creador de la partida espera a que se unan más de 1 jugadores para poder comenzar4.Iniciar partidaPulsar el botón Empezar

Extensiones

Comentarios

RNF

Actualizar estadísticas (Cu21)Objetivos Actualizar los rankings de manera correcta.

Prerrequisitos Estar jugando una partida.

Actores Administrador, usuario

27

Acciones 1. Finalizar o salir de una partida en curso.

Extensiones Puede abandonar una partida por caída de conexión. Se considerará como si hubiese salido de la partida

Comentarios

RNF

Hablar con los demas usuarios de una partida(Cu22)

Objetivo Poder comunicarse con los demás jugadores de un juego.

Prerrequisitos Estar jugando una partida.

Actores Usuarios

Acciones Escribir el mensaje que se quiere enviar a los demás usuarios y enviarlo.

Extensiones Puede comunicarse en privado con cualquier usuario que se encuentre en la sala del juego.

Comentarios

RNF

Configurar una partida(Cu23)Objetivo Elegir las opciones con las que comenzará una partida.

Prerrequisitos Haber creado una partida.

Actores Usuarios.

Acciones1.Rellenar los campos del menú de configuración.1.1.Elegir la opción de cargar configuración por defecto.2.Confirmar la selección.

Extensiones 1.a: Si no se rellenan correctamente los campos obligatorios de configuración, se le volverá a mostrar la pantalla de configuración al

28

usuario pidiendo que los rellene.

Comentarios

RNF

Evaluar los juegos enviados por los desarrolladores(Cu24)

Objetivo Aceptar o rechazar los juegos que envian los desarrolladores

Prerrequisitos

Un desarrollador debe haber enviado a un juego. El evaluador debe estar autenficado como moderador.

Actores Moderador

Acciones

1: Chequear que el juego funcione correctamente y que va a suponer una cierta innovación con los que ya hay para que los usuarios lo prueben.2: Enviar el juego al administrador, que será el encargado de instalarlo(Cu16)

Extensiones1.a: Si el juego no compila o ejecuta correctamente, o se considera que es demasiado parecido(o igual) a alguno de los que ya existen, se notificará mediante un mensaje al usuario que lo envió para su evaluación.

Comentarios

RNF

Enviar mensaje dentro del chat(Cu25)

Objetivo Enviar el mensaje a todos los usuarios del canal.

Prerrequisitos

Estar en el mismo canal que el resto de usuarios a los que quieras mandar el mensaje.

Actores Usuario

Acciones 1: Situar el cursor en el cuadro de entrada de texto.2: Escribir el mensaje, precedido o no de "/dice", en el caso de no estar precedido por "/dice" el mensaje no puede empezar por "/".

29

3: Pulsar la tecla "ENTER" o hacer click con el ratón en el botón enviar.

Extensiones 3 Si el mensaje empieza por "/" se muestra por pantalla una lista de los comandos que puede usar con "/".

Comentarios

RNF

Enviar susurro dentro del chat(Cu26)

Objetivo Enviar un mensaje a un usuario en concreto del canal.

Prerrequisitos

Estar en el mismo canal que el usuario al que quieras mandar el mensaje.

Actores Usuario

Acciones

1: Situar el cursor en el cuadro de entrada de texto.2: Escribir el mensaje, precedido de "/susurro nombre_usuario_destino" o hacer click sobre el nombre del usuario en el panel de usuarios del canal actual3: Pulsar la tecla "ENTER" o hacer click con el ratón en el boton enviar.

Extensiones 2 El usuario introducido no se encuentra en el canal, se mostrará un mensaje de error.

Comentarios

RNF

Personalizar el chat (Cu27)Objetivo Elegir los ajustes de personalización del chat.

Prerrequisitos

Actores Usuario

Acciones 1: Situar el cursor en el cuadro de entrada de texto.2: Escribir en el cuadro "/opciones"

30

3: Pulsar la tecla "ENTER" o hacer click en enviar.4: Seleccionar las opciones deseadas en la ventana de opciones surgida.5: Hacer click en aceptar, o en cancelar si no queremos modificar nada.

Extensiones

Comentarios

RNF

31

Riesgos _____________________________________ La siguiente tabla muestra un resumen de los riesgos considerados:

Riesgo Probabilidad Impacto

Falta de iniciativas entre los miembros del grupo Muy alta Catastrófico

Incompatibilidad de horarios entre los miembros del grupo Muy alta Tolerable

Discrepancias en el grupo Muy alta Tolerable

El protocolo es inadecuado para los juegos que hagamos Alta Serio /

Catastrófico

Mala estimación en el tiempo necesario para completar las características fundamentales del proyecto

Alta Serio

Falta de tiempo para realizar características secundarias Alta Tolerable

El proyecto no funciona en los puestos de laboratorio Moderada Catastrófico

No se dispone de un servidor para ejecutar la aplicación Moderada Catastrófico

El personal no es capaz de adquirir los conocimientos Moderada Serio

La aplicación es demasiado lenta como para ser usable Moderada Serio

La aplicación es excesivamente grande Moderada Serio

El portal no tiene aceptación por parte de los usuarios Moderada Serio

Bajas permanentes del personal (por bajas médicas, abandono de la asignatura, etc.) Baja Serio

La tecnologia del cliente usada presenta limitaciones Alta Serio

32

Los grupos de trabajo no se cordinan y/o no son capaces de comprender su tarea Alta Serio

El protocolo es inadecuado para los juegos que hagamosProbabilidad Alta

Impacto Serio / Catastrófico

DescripciónEl protocolo de comunicaciones diseñado para que interactúen las aplicaciones cliente de los juegos con el servidor presenta problemas o se queda corto para representar todas las funcionalidades necesarias en los juegos.

Consecuencias

Los juegos no pueden tener todas las funcionalidades esperadas o incluso determinados juegos no pueden funcionar con nuestro servidor.

Cómo evitarlo

Al ser el protocolo de comunicaciones una parte fundamental del proyecto y con altas posibilidades de presentar algún fallo se debe emplear el tiempo necesario para diseñar el protocolo correctamente, así como probar la mayor cantidad de situaciones posibles contra él para asegurarnos de que una buena cantidad de los posibles usos del mismo están cubiertos.

Cómo tratarlo

La solución pasaría por analizar los casos en los que el protocolo no soporta las funcionalidades necesarias e intentar añadir las extensiones al protocolo necesarias. Esto podría requerir una buena cantidad de tiempo en análisis y cambios en el servidor (Serio) así como la modificación de una gran mayoría de los programas clientes ya hechos (Catastrófico).

EliminadoIteracion Diciembre.En el prototipo, el protocolo, se ha probado en varias ocasiones entre ellas con un juego, y se ha visto que era adecuado.

El proyecto no funciona en los puestos de laboratorioProbabilidad Moderada

Impacto Catastrófico

Cómo evitarlo Encargar a un grupo la investigación de las versiones del software instalado en los puestos de laboratorio y limitar el desarrollo del proyecto a las versiones instaladas. Además hay que investigar y

33

tener en cuenta el espacio de disco disponible, así como la memoria y el ancho de banda.

Cómo tratarloEn caso de incompatibilidad con el software necesitado nos pondremos en contacto con los técnicos de los laboratorios, si no funciona este recurso se intentarán modificar las partes del proyecto problemáticas.

Eliminado Parcialmente

Iteracion Diciembre.El prototipo se ha podido hacer funcionar en los puestos de laboratorio

No se dispone de un servidor para ejecutar la aplicaciónProbabilidad Moderada


Cómo evitarlo

Tratar de conseguir un servidor en el que colocar tanto el portal como el servidor de juegos a la mayor brevedad posible. Conseguir también un servidor secundario para el caso en que el primero falle. Diseñar el proyecto de forma que un ordenador de los laboratorios pueda actuar de servidor.

Cómo tratarloSi en el momento de la entrega el servidor no funciona, puede utilizarse uno de los puestos del laboratorio para actuar como tal. Si no se ha diseñado de forma que aquello funcione, las consecuencias son catastróficas.

Eliminado Parcialmente

Iteracion Diciembre.Se ha usado como tal un puesto de laboratorio, apoyandonos en servidores portables

Bajas permanentes del personal (por bajas médicas, abandono de la asignatura, etc.)Probabilidad Baja

Impacto Serio

Cómo evitarlo

Concienciarles de que todos somos un grupo y debemos trabajar como tal. Organizar los trabajos de forma que una baja afecte lo mínimo posible. Como medida de prevención se evitará que sólo sea una

34

persona la que esté encargada de investigar y utilizar una tecnología especifica.

Cómo tratarlo Reorganizar el trabajo distribuyéndolo entre los miembros del grupo.

El personal no es capaz de adquirir los conocimientosProbabilidad Moderada

Impacto Serio

Consecuencias

El sujeto no puede progresar. El sujeto no es útil actualmente y además no desempeña trabajo. Otros grupos que dependen del sujeto no pueden avanzar. El proyecto se detiene en su parte asignada y, en el peor caso, totalmente.

Cómo evitarlo Reparto adecuado de los grupos de trabajo, teniendo cuenta los conocimientos previos de los miembros.

Cómo tratarloAsignarle otra tarea en que pueda ser útil. Puede suponer reorganizar grupos para cubrir su parte. Construir con él un grupo más amplio con miembros de grupos más avanzados o más capacitados para facilitar el aprendizaje.

Mala estimación en el tiempo necesario para completar las características fundamentales del proyectoProbabilidad Alta

Impacto Serio

Cómo evitarlo

Tener los pies en la tierra y no a añadir características excesivamente complejas al programa sin ningún criterio.

Cómo tratarlo

Planificar con sumo cuidado cada paso a dar en la división de trabajo antes de empezar a programar. También podría paliar el problema tener a un grupo con la tarea adicional de investigar posibles alternativas a los métodos elegidos paralelamente al desarrollo del trabajo en sí.

35

Falta de tiempo para realizar características secundariasProbabilidad Alta

Impacto Tolerable

Cómo evitarlo

Una buena planificación del proyecto, estableciendo unas fechas para la finalización de cada parte (y cumpliéndolas). Teniendo claro cuales son las partes prioritarias y secundarias del proyecto.

Cómo tratarlo

Acordar entre todo el grupo las fechas de entrega de cada parte importante dejando un margen de tiempo de sobra para realizar las características secundarias y reajustes necesarios.

Incompatibilidad de horarios entre los miembros del grupoProbabilidad Muy alta

Impacto Tolerable

Cómo evitarlo

Repartir el trabajo de tal manera que se puedan establecer grupos de trabajo más pequeños para posteriormente unificarlos.

Cómo tratarlo

Intentar establecer los horarios de tal forma que el mayor número de miembros pueda asistir.También basta con la presencia de un miembro de cada subgrupo creado para las distintas tareas del proyecto.Es importante recurrir a soluciones tecnológicas tales como una lista de distribución, un foro, un wiki y el uso de un CVS, que permitan a todos los miembros del grupo realizar cambios y ver los realizados por el resto del equipo.

La aplicación es demasiado lenta como para ser usableProbabilidad Moderada

Impacto Serio

Cómo evitarlo Utilizar tecnologías que no impliquen un alto coste de rendimiento.

36

Cómo tratarlo

Dar prioridad a la jugabilidad y el manejo de la aplicación frente a opciones gráficas que puedan acusar un rendimiento excesivo (herramientas más eficientes, programación más fácil, etc.)

Discrepancias en el grupoProbabilidad Muy alta

Impacto Tolerable

Cómo evitarlo

A lo largo del desarrollo del software dar libertad de decisión a todos y cada uno de los miembros del grupo de aportar ideas hacia la práctica, de forma que nadie vea sus ideas vetadas; siempre y cuando no haya inconvenientes serios a la hora de aceptar dichas ideas.

Cómo tratarlo

Intentar en la medida de lo posible llegar a una solución que toque todas las ideas del grupo.

Falta de iniciativas entre los miembros del grupoProbabilidad Muy alta


Cómo evitarlo

Concienciar a la gente de que o cada uno aporta su granito de arena y todos colaboramos o el proyecto se va a pique. La nota que saquemos es de y para todos. No vale quejarse de una mala gestión del grupo si no se aportan soluciones para que dicha mala gestión no tenga lugar.

Cómo tratarlo

En primer lugar dar un toque de atención a la/s persona/s que no hagan nada para que esto salga adelante. En segundo lugar, actuar dividiendo el trabajo en grupos lo más reducidos posible, de manera que el aporte individual sea crucial.

La aplicación es excesivamente grandeProbabilidad Moderada

Impacto Serio

Cómo evitarlo Optimizar al máximo los recursos utilizados (sobre todo multimedia).

37

Cómo tratarlo

Pedir más espacio, utilizar memorias externas o usar otras herramientas más eficientes en espacio.

El portal no tiene aceptación por parte de los usuariosProbabilidad Moderada

Impacto Serio

Cómo evitarlo

Consultar con posibles usuarios de manera periódica si la aplicación les causa interés. Para ello, buscaremos un grupo de personas (externas al grupo de desarrollo) dispuestas a probar el portal. Realizar encuestas con una muestra considerable de usuarios que dediquen un tiempo a utilizar nuestro portal.

Cómo tratarlo Remodelación de la aplicación cara al gusto del usuario

La tecnologia de cliente usada presenta limitacionesProbabilidad Alta

Impacto Serio

Cómo evitarlo

Cómo tratarlo Implementar ciertas funcionalidades a mano

EliminadoIteracion Diciembre.En el prototipo se han eliminado esta limitaciones como anteriormente se ha descrito.

Los grupos de trabajo no se coordinan y/o no son capaces de comprender su tareaProbabilidad Alta

38

Impacto Serio

Cómo evitarlo

Mejorando la comunicación entre los miembros del proyecto y preguntando cuando algo no se comprenda

Cómo tratarlo

Mejorando la documentacion y la comunicacion entre los miembros del grupo

39

Control de Calidad ___________________________ Convenciones a la hora de escribir códigoSabemos que todos tenemos nuestro estilo de programar, pero para el que revise y pruebe el código, va a ser más fácil si todos escribimos de una forma homogénea.

1. Habrá una y sólo una sentencia por línea. Es decir cosas como:i++; juan = pepe + pacho; j--;

estarán prohibidas. Lo correcto sería: i++; juan = pepe + pacho; j--;

2. Los nombres de las clases en Java empezarán con letra mayúscula.

3. Los nombres de los métodos de cada clase empezarán con minúscula.

4. Los nombres de los atributos de cada clase empezarán con guión bajo. Ejemplo:private String _nombre;public Integer _numero;

Los parámetros de las funciones y las variables locales a los métodos empezarán SIN guión bajo, así se pueden diferenciar mejor el contexto de las variables.

5. Los métodos y atributos estáticos de las clase cumplirán con las reglas anteriores anteponiendo "st" al nombre elegido. Ejemplo:private static String _stNombre;public static Integer _stNumero;

6. Las constantes llevarán su nombre completo en mayúscula y si hay que separar palabras se hará con guiones bajos. Por ejemplo:private static java.awt.Color COLOR_FONDO;public static String NOMBRE;

Las constantes siempre serán variables estáticas, con lo cual no pondremos el prefijo 'st' en sus nombres.

7. Para los nombres de métodos, variables y clases, para separar palabras se introducirán mayúsculas. Por ejemplo:private String _primerApellido;private String _segundoApellido;

8. Trataremos de usar nombres de variables representativos. Nada de expresiones tipo "a = b * c", porque nos va a costar identificar qué es cada cosa.Vamos a tardar más en escribir, pero después será mucho mejor a la hora de modificar y corregir el código.Todos tenemos que entender el código de todos.

9. El código deberá estar correctamente tabulado.

40

Código en Java Se tratará de documentar TODO con JavaDoc. Todo quiere decir, métodos (con

sus parámetros y lo que devuelven) y variables (lo que representan y su propósito).

Los atributos de las clases se ubicarán al PRINCIPIO de las mismas. Los métodos estarán ubicados en el siguiente orden:

1. Constructoras 2. Métodos de uso general 3. Accesoras 4. Seteadoras

Las variables de los elementos gráficos tendrán que tenér nombres representativos, como se dijo en la regla 8. No sirve que algo se llame jButton1.

Controles al código entregado

Condiciones de envío1) Que al menos compile. 2) Que cumpla con todo lo detallado en el punto anterior. 3) Haber hecho algún testeo previo para ver que funciona con casos generales. 4) Que no repita código de otros lados, hay que tratar de utilizar el código que

ya esté implementado. Por ejemplo como métodos de ordenación y cosas por el estilo.

Metodología de control

Habrá algún miembro del grupo designado para coordinar el control e integración de todos los módulos del proyecto.

Igualmente, para que no sea siempre la misma persona a lo largo de todo el curso el puesto de revisor irá rotando. Además alguien tendrá que revisar el código que produce el revisor.

41

Glosario _____________________________________ Administrador: puede acceder a los servicios de la aplicacion igual que un usuario jugador, pero además puede modificar determinadas opciones, así como gestionar la base de datos de usuarios.

Chat: aplicación para poder conversar con otros usuarios jugadores.

Desarrollador: programador de juegos para la página. Una vez desarrollada una aplicación para la misma, se la deberá enviar al administrador y solamente éste será el que le dé visto bueno y la incorpore.

Foro: aplicación web que permite a los usuarios intervenir o crear discusiones en línea.

Identificarse: introducir el nombre y contraseña para acceder a las distintas posibilidades ofrecidas dentro de la aplicación.

Juego: aplicación a la que pueden acceder los jugadores registrados en la página. (Para jugar, vamos).

Logro: cada juego tiene una serie de "desafíos". Por cada desafío superado, se concederá al jugador el logro correspondiente.

Loguearse: equivale a identificarse.

Moderador: tipo de usuario que puede acceder a las mismas opciones que un usuario normal y además gestionar el contenido del foro y las noticias.

Página: cada una de las formas de la interfaz en un determinado momento.

Portal: se refiere a la aplicación web de manera global.

Post: cada mensaje escrito en un tema del foro por un usuario.

Postear: añadir un nuevo mensaje en un tema del foro.

Ranking: tabla de clasificación en donde los jugadores aparecen ordenados por puntuación de mayor a menor.

Registrarse: abrir una nueva cuenta en el portal, aportando como dato una dirección de correo electrónico y eligiendo un nombre de usuario y contraseña para acceder al mismo.

Servidor: aplicación que da al administrador las herramientas necesarias para gestionar el portal.

42

Tema: cada nueva discusión añadida al foro, cosa que puede hacer todo usuario registrado e identificado en la sesión actual.

Usuario: aquél que accede únicamente a los servicios que ofrece la aplicación sin posibilidad de modificar las opciones principales.

43

Secciones Del Portal Menú principal

Principal Portada (Cu1,Cu2) Contacto Desarrolladores (Cu13,Cu14)

Juegos (Cu3,Cu4,Cu5,Cu18) Todos Cartas Tablero Otros

Comunidad Portada Foros (Cu9,Cu11) Amigos (Cu7,Cu8)

Estadísticas Visión Global Estadísticas por jugadores(Cu6) Estadísticas particulares(Cu6)

Ayuda FAQ

Búsqueda Jugadores Juegos

Gestión (Moderador: 1 - Administrador: 2) Noticias1,2 (Cu10) Usuarios1,2 (Cu12) Instalar juegos2 (Cu16) Gestionar moderadores2 (Cu17)

44

http://portaljuegos.wikidot.com/casos-de-uso#Cu17


















Plan De Fase ________________________________ Fecha de los hitos importantes

Objetivo del ciclo (fase de inicio) : 21 Noviembre 2007 Arquitectura del ciclo (final de la fase de elaboración, arquitectura completa):

mediados de enero Capacidad operativa inicial (final de la fase de construcción): finales de marzo o

principios de abril Fase de transición: mediados de mayo. Entrega del producto: finales de mayo.

Recursos humanos 18 personas (integrantes del grupo) Testeadores (voluntarios externos al grupo de desarrollo)

Fechas de los hitos secundarios Finales de cada mes: entrega Primera entrega: 20 diciembre

Iteraciones previstasPrimera iteración (Iteración de Noviembre)

Objetivos: Requisitos, riesgos, especificación, casos de uso, glosario. Periodo: 20 octubre - 20 noviembre Estado: terminada Evaluación: completado. Se entiende qué va a hacer nuestra aplicación.

Segunda iteración (Iteración de Diciembre) Objetivos: Investigación de tecnologías, creación del primer prototipo. Periodo: 21 noviembre - 20 diciembre Estado: terminada Evaluación: se ha conseguido un prototipo funcional y se han actualizado los

riesgos

Tercera iteración (Iteración de Enero) Objetivos: Fijar el modelo definitivo de arquitectura y adaptar/corregir la

documentación del proyecto. Periodo: 21 diciembre - 18 enero

Cuarta iteración (Iteración de Febrero) Periodo: 19 enero - 24 febrero Objetivo: preparar la fase de construcción.

o Revisión de errores y problemas de diseño

45

o Planificar la construcción en detalle

Quinta iteración (Iteración de Marzo) Periodo: 24 febrero - 15 marzo Objetivo: comenzar la fase de construcción.

Sexta iteración (Iteración de Abril) Periodo: 16 marzo - 15 abril Objetivo: Finalizar la fase de construcción.

Séptima iteración (Iteración de Mayo) Periodo: 16 abril - fecha de entrega (finales de mayo) Objetivo: Realizar la fase de transición.

o Probar el proyecto y corregir erroreso Ampliar el número de juegos disponibles

46

Plan de Iteración de Enero __________________ ObjetivoEl objetivo de esta iteración es fijar un diseño definitivo que nos permita trabajar de aquí a que terminemos el proyecto sin parones producidos porque hay partes que están sin diseñar. Todos los componentes, estén o no desarrollados, tienen que tener un comportamiento y unas dependencias bien definidas. Para ello, va a ser necesario crear una documentación de diseño. Concretando algo más, en esta iteración vamos a realizar las siguientes tareas:

PlanificaciónLa segunda iteración de el proyecto comienza tan pronto como terminó la anterior (21 de diciembre), y debería estar completa antes de la entrega del mes de enero. Como hay algunas tareas dependientes de otras, vamos a establecer 2 fechas para evitar que unos tengan que esperar a que esté el trabajo de otros. Estas fechas pueden ser el viernes 11 de enero y el siguiente viernes, 18 de enero. De esta forma aquellas personas que no puedan trabajar en navidad tendrán tiempo de hacer las cosas a la vuelta.

Tareas1. Documentación

1.1. Completar y corregir las interfaces a) Conviene ampliar la sección de las interfaces de forma que se indique cómo

pasamos de una interfaz a otra, relacionando las interfaces con los casos de uso y añadiendo, si es necesario, nuevos casos de uso que describan el comportamiento de las interfaces.

b) Las interfaces deberían ser más auto-explicativas. Por ejemplo, la página principal debería tener un texto introductorio a los objetivos del sitio web, y cada una de las secciones debería describir su objetivo y funcionamiento. También se pueden incluir comentarios fuera de la propia interfaz para aclarar cosas que dentro de la aplicación están claras, pero en las imágenes no (por ejemplo, movimiento o animaciones).

c) Las interfaces de los juegos concretos necesitarán concretarse más, y ampliarse de forma que expliquen, si es necesario, los diferentes estados de juego dentro de la misma partida (esperando la unión de los demás jugadores, esperando el turno, realizando acciones, etc.).

1.2. Completar y corregir casos de uso a) Realizar los cambios propuestos por el profesor, que según tengo anotados,

son: o Incluir en los casos de uso solamente las acciones del usuario,

eliminando o sustituyendo las acciones realizadas por el sistema.o En los casos de uso que incluyan la posibilidad de que se produzca un

error, indicar la información que se le mostraría al usuario y las opciones para subsanarlo que éste tiene disponibles.

47

o El Cu3 hace referencia a otros casos de uso pero no indica a cuáles. En este caso de uso, el nombre coincide con la primera acción y eso no está bien porque entonces el resto de acciones sobrarían. Quizás habría que renombrarlo.

o En el Cu4 quizás convendría incluir una opción de crear una partida rápida en la que no haya que introducir valores y estos vengan dados por defecto.

o Algunos casos de uso no indican cuándo o desde dónde son accesibles (principalmente los que se refieren a funcionalidades de la web).

o Podríamos indicar también desde qué lugares es posible añadir amigos en el portal.

o Hay que especificar si los juegos aparecen en una ventana aparte, de forma que podamos seguir consultando estadísticas, amigos, etc., o si por el contrario mientras jugamos no podemos hacer nada más sin abortar la partida.

o Para los casos de uso que amplían otros casos de uso (por ejemplo Cu20), hacer referencia al caso de uso que amplían (algo parecido a herencia).

b) Crear nuevos casos de uso que faltan: enviar un mensaje de chat, unirse a un canal de chat (para estos dos quizás baste con especificar más claramente el Cu22, aunque también podemos chatear mientras buscamos partidas creadas), etc.

c) También hay que incluir un caso de uso (y puede que también un nuevo tipo de usuario) para la evaluación de los juegos enviados por desarrolladores.

1.3. Riesgos a) Actualizar los riesgos añadiendo, si es necesario, aquellos riesgos deducidos

de problemas que hayamos tenido hasta ahora (por ejemplo, para combinar distintos apartados del proyecto, o provocados por retrasos en algunos miembros del grupo consecuencia de catástrofes técnicas o de otro tipo).

1.4. Plan de trabajo a) Completar el plan de la iteración de diciembre (si es que falta algo relevante)

y, opcionalmente, añadir algún tipo de conclusión detallando lo que se ha conseguido con esa iteración, y las cosas que no se han logrado hacer.

b) Completar este plan de trabajo. c) Realizar el plan de trabajo de la siguiente iteración. Para hacer esto contará

con los documentos de diseño de cada uno de los componentes. Estos documentos indicarán fechas clave en la construcción de cada componente para que el diseño esté terminado a tiempo.

2. Diseño

2.1. Planteamiento de arquitectura a) Para cada uno de los componentes de la arquitectura, definir su objetivo y sus

dependencias. Esto es, crear un diagrama UML de clases en el que aparezcan los métodos que tendrá y además indicar para cada clase y, en particular, para cada método, su función, las clases externas que se van a utilizar (y qué métodos / atributos de estas clases) y las tablas de la base de datos que se van a leer o

48

escribir. Recomiendo publicar esta información en la Wiki e ir añadiendo las cosas según vayan estando, para que los demás puedan consultar esta información y trabajar a partir de ella.

b) Cada grupo debe revisar que su parte no interfiere con las partes de los demás: que dos componentes no realicen la misma función, evitar que dos componentes puedan escribir simultáneamente en la base de datos (especialmente importante al tener por separado el servidor web del servidor de juegos) y otros problemas que ahora mismo no se me ocurren.

c) También hay que asegurarse de que los demás componentes hacen lo que esperamos que hagan, es decir, si decimos que utilizamos una clase para obtener el número de jugadores en una partida, que dicha clase pueda proporcionar ese dato.

d) Comprobar todos los componentes para asegurarse de que los dos problemas mencionados atrás no ocurren.

2.2. Documentación de la arquitectura Elaborar un documento de diseño más detallado que incluya el diagrama UML

de clases y diagramas de secuencia si son importantes (estos últimos relacionados con los casos de uso). El documento debe tener también información detallada explicando las responsabilidades de cada clase, las clases que utiliza (atributos) y, para cada método, su objetivo (responsabilidades) y los métodos que utiliza (ya sean propios o de otras clases, indicando cuáles).

El documento de diseño también debe detallar, si es necesario, qué clases deben construirse en proyectos separados y, para cada proyecto, qué otros proyectos debe importar.

Por último, debe incluir una indicación del estado de desarrollo de cada componente (cada clase o proyecto), y un plan que especifique qué clases o qué funcionalidades deben estar completadas en cada una de las iteraciones para que de tiempo a concluirlas.

2.3. Diseño de la base de datos Hay que modificar la base de datos de forma que añada aquellas restricciones y

aquellas columnas que sean necesarias para el correcto funcionamiento de todo el sistema.

3. Construcción

3.1. Prototipo Concluir el desarrollo del prototipo, de forma que su funcionamiento sea el que

se esperaba en un inicio.

3.2. Nueva arquitectura Cada grupo debe crear las clases que ha diseñado, con un mínimo de

documentación en javadoc que explique lo que hace cada clase y método. Las clases no tienen que estar completamente implementadas, basta con que tengan los atributos y métodos que se mencionan en el UML. La documentación en javadoc no tiene por qué se la definitiva, pues ésta se irá completando durante la fase de construcción. Solamente se pide que las clases estén en los proyectos adecuados y que los proyectos compilen.

49

Para los elementos que ya estuviesen implementados en el prototipo, las clases de la arquitectura diseñada durante esta iteración deben tener implementadas en el nuevo diseño al menos aquellas funcionalidades que estaban implementadas en el prototipo.

AsignaciónComo he dicho antes, podemos dividir la iteración en 2 etapas, de forma que las tareas las hemos asignado a una u otra etapa, en función de las dependencias. Algunas dependencias siguen sin estar del todo resueltas, por lo que igualmente va a haber algunas esperas (espero que sean mínimas).

Daniel y Daniel

Primera etapa:Plantear la arquitectura (2.1) del cargador de módulos. Casos de uso: 1.2a.

Segunda etapa:Hacer las modificaciones necesarias para que el cargador de módulos funcione según lo especificado en el diseño realizado (3.2).Elaborar el documento de diseño del cargador de módulos (2.2).Casos de uso: 1.2c.

Rubén y Beatriz

Primera etapa:Corregir los problemas encontrados al tratar de hacer funcionar el prototipo en el laboratorio (3.1), solicitando a quienes desarrollaron cada elemento del prototipo que realicen cambios si es necesario.Plantear la arquitectura definitiva del módulo de comunicaciones y el de bases de datos (2.1).Actualizar y completar los riesgos, en función de los que hayamos descartado y los que hayamos descubierto a partir de los problemas con el prototipo (1.3). Los que descartemos, no eliminarlos, pero comentar que, a partir de la fecha que sea, están tratados.

Segunda etapa:

Módulos de comunicaciones y de bases de datos: tareas 2.2 y 3.2.

Santi y Victor

Primera etapa:

Colaborar en el correcto funcionamiento del prototipo, haciendo los cambios necesarios

en el módulo de chat (3.1).

50

Plantear arquitectura definitiva del módulo de chat (2.1).

Casos de uso: pensar en nuevos casos de uso para 1.2b.

Segunda etapa:

Módulo de chat: tareas 2.2 y 3.2

Ezequiel y Guillermo

Primera etapa:

Plantear una arquitectura definitiva del módulo de juegos, añadiendo la carga dinámica

de juegos y facilitando todo lo posible la tarea de desarrollar los juegos concretos (2.1).

Prestar especial atención a que todos los diseños encajen correctamente (2.1d)

Plan de fase: 1.4a

Segunda etapa:

Módulo de juegos: tareas 2.2 y 3.2.

Plan de fase: 1.4b y 1.4c.

Patri y Conrado

Primera etapa:

Colaborar en el diseño del cliente y el módulo de juegos, consultando los diseños que se

vayan creando y añadiendo críticas y sugerencias con el objetivo de que estos diseños

(que van a ser la interfaz visible para el desarrollador de juegos, es decir, el frame-work)

faciliten lo máximo posible el desarrollo de juegos.

Ir planteando un prototipo de la arquitectura de un juego concreto, por ejemplo, las 7 y

media.

Desarrollar las interfaces del juego de las 7 y media con más detalle (1.1c).

Segunda etapa:

Plantear el diseño definitivo del juego de las 7 y media (2.1) y elaborar el documento de

diseño (2.2).

Si hay suficiente tiempo, realizar tarea 3.2.

51

Jonás, Lara, Jesús e Isaac

Este trabajo es para 4 personas pero es fácilmente divisible en 2 tareas, de manera que

unos se encarguen de elaborar el diseño del cliente (obtener parámetros, comunicarse

con el servidor, identificar el usuario, enviar solicitudes de partidas con unos parámetros

dados, enviar solicitudes para unirse a una partida, etc.), y otros se encarguen de diseñar

el frame-work (facilitar funcionalidades al desarrollador de juegos, como lanzar eventos

cuando se pasa un turno, proporcionar información sobre los usuarios de la partida y

todo aquello que se considere útil).

Primera etapa:

Plantear el diseño definitivo del cliente (2.1). Utilizar la experiencia adquirida en el

desarrollo del prototipo para crear un diseño mejorado. Podéis basar el diseño en el

patrón modelo-vista-controlador.

Acordar cuáles son los parámetros que se recibirán a través del código HTML.

Diseñar el frame-work del cliente, es decir: la funcionalidad proporcionada al

desarrollador de juegos. El frame-work se puede plantear como una clase de juego

abstracto que extenderán los desarrolladores para elaborar el cliente del juego concreto

(2.1). Cuanta más funcionalidad proporcione el frame-work, menos trabajo habrá que

hacer después para crear los juegos concretos.

Segunda etapa:

Crear el documento de diseño del frame-work y del cliente (2.2), y también la tarea 3.2.

Cuando toda la documentación nueva esté en la wiki, crear un documento Word que

reuna todo para enviársela al profesor.

Cristian y Pablo

Primera etapa:

Corregir lo que sea necesario para que el prototipo funcione con el chat (3.1).

Diseñar la arquitectura definitiva del cliente de chat (2.1), teniendo en cuenta que la

interfaz con el cliente puede cambiar radicalmente. Colaborar con el diseño del cliente,

haciendo críticas y sugerencias orientadas a facilitar la integración del chat.

Casos de uso: pensar en nuevos casos de uso para 1.2b.

52

Segunda etapa:

Cliente de chat: tareas 2.2 y 3.2.

Gerardo y Eduardo

Primera etapa:

Modificar el prototipo para que funcione, colaborando en la integración del applet y

solucionando los problemas existentes (3.1).

Mejorar y añadir interfaces, sobre todo en lo relacionado con el diseño de la web (1.1a y

1.1b).

Plantear un diseño definitivo de las secciones de la web, de la forma de pasar de una

sección a otra y de las tablas de las bases de datos que se leen o escriben en cada acción

(2.1).

También acordar los parámetros que se pasarán al applet en cada situación (2.1).

Segunda etapa:

Creo que Gerardo tiene un documento sobre las tecnologías disponibles en los

laboratorios que falta por copiar a la Wiki. Otra tarea es pasar ese documento a la Wiki,

manteniendo solamente la información que siga siendo relevante.

Elaborar un documento de diseño que describa lo diseñado en la etapa anterior (2.2),

sobre todo en lo referente a las bases de datos.

Actualizar y corregir el diseño de la base de datos (2.3).

Si hay tiempo, implementar más funciones y revisar el código ya creado para aumentar

la seguridad (por ejemplo, que los archivos "php" que no han sido diseñados para ser

visualizados directamente, no sean accesibles al teclear la url).

53

Protocolos ___________________________________

Modulo De Comunicaciones - Protocolo Introducción

Este documento define el formato con el que intercambia datos el módulo de comunicaciones del servidor con el exterior, así como otros detalles relacionados.

Formato de un mensaje

Un mensaje es la unidad mínima de información intercambiable entre el módulo de

comunicaciones y cualquier aplicación externa (applets de juegos, páginas web del

portal que necesiten comunicarse con éste…). Como una primera aproximación se

puede considerar la siguiente estructura.

Nombre Descripcion

Longitud Entero con signo de 4 bytes que contiene la longitud del mensaje (incluidos los 4 bytes de este mismo campo)

Metadatos

Serialización XML de una clase que exponga los metadatos de un paquete (longitud variable)

Cuerpo Serialización XML de una clase que contiene lo que realmente se quería transmitir

Descripción de los campos Longitud : A pesar de que el serializador xml no necesita conocer la longitud de

lo que enviamos previamente (lo infiere de la clase que serializa) necesitamos conocer este dato puesto que nada nos garantiza que un mensaje nos llegue de una sola vez al servidor. El protocolo TCP garantiza que llegará todo y en orden pero no que llegará sin fraccionarse. Utilizando este valor podemos determinar si la información ha llegado completa y por tanto podemos procesarla o bien si nos ha llegado un fragmento y aun debemos esperar al resto.

Metadatos : Como su nombre indica son datos sobre los datos. Entre otras cosas aquí podríamos encontrar un identificador del protocolo sobre el que se define el mensaje, un contador para numeros de mensaje , flags para indicar la prioridad… En principio solo hace falta el identificador del protocolo pero es algo abierto y facilmente modificable (antes de hacer el resto de cosas claro)

Cuerpo : Es la "chicha" del mensaje. Contiene los datos reales que quería enviar el emisor sin adornos. Esta parte del mensaje le será pasada al módulo

54

correspondiente de una manera aun por determinar (probablemente en una cola de mensajes pero eso queda más en la Estructura del Módulo Servidor)

Comentarios Como serializador xml propongo usar XStream (del cual hay enlaces en la página

de Tutoriales de Tecnologías ya que nos ofrece una cierta independencia respecto a los cambios en las clases serializadas que los métodos de serialización propios de Java no ofrecen.

55

http://portaljuegos.wikidot.com/tutoriales-de-tecnologias

Diseño de componentes _____________________

Módulo cargadorOBSOLETO. MIRAR NUEVO DIAGRAMA UML, COMENTARIOS SERÁN SUBIDOS A SU TIEMPO.¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡MIRAR EL ARCHIVO ADJUNTO DE DOCUMENTACIÓN!!!!!!!!!!!!!!!!!!!!!!!!!!!!La parte encargada de la carga dinámica de los módulos del proyecto consta de 3 partes:1.Main. Se encarga de crear las nuevas instancias de los módulos, resolviendo toda dependencia que pudiera existir entre los mismos. Para ello primero inicia aquellas clases sin dependencias para posteriormente iniciar iterativamente los demás módulos (según se vayan resolviendo).2.Instancia. Es la clase donde almacenamos la instancia del módulo e información acerca del mismo, como son sus dependencias o si ya ha sido iniciado, además de la clase que Inicia el módulo y la dirección del cargador de la clase.3.FiltroJar. Esta clase (auxiliar) es necesaria para poder filtrar los archivos .jar a la hora de buscar los módulos a cargar en sus respectivas carpetas del proyecto.Las relaciones que hay entre las mismas son las siguientes:La clase cargador (Main) posee una estructura HashMap<String,Instancia> en la que almacenaremos, como clave, el nombre del módulo y como valor la Instancia de dicho módulo. La relación entre Main e Instancia es de agregación, ya que Main contiene instancias. 0 o más se relacionan con una clase Main mientras que cada una de las Instancias necesita un Main.La clase FiltroJar, es una clase auxiliar necesaria para poder crear un filtro de archivos .jar, ya que debe implementar un interfaz para poder realizarlo.La clase Main, implementa la interfaz IGestorMódulos, el cual proporciona una operación para que los demás módulos puedan obtener la instancia de otros módulos del proyecto.

56

Módulo de Comunicaciones

DescripciónEl módulo de comunicaciones se encarga de facilitar el envio y recepción de mensajes

entre el programa servidor (y sus módulos) y los clientes. Además expone

funcionalidades para la identificación de usuarios asi como para la

obtención/modificación de los datos de estos.

DependenciasMódulo de Base de Datos

Usado para tareas de identificación y consultas de usuarios

Módulo de Log

Usado para notificar errores graves del sistema

QuickServer

Base de comunicaciones del servidor

XStream

Utilidad de serialización(necesario tambien para el cliente)

Empaquetado

57

http://portaljuegos.wikidot.com/local--files/diseno-del-modulo-de-comunicaciones/ComunicacionesComunUML.png

La implementación del módulo está en el fichero ModuloComunicaciones.jar mientras

que los interfaces y clases usables por otros modulos o aplicaciones se encuentran en

ModuloComunicacionesComun.jar.

Uso del móduloUso del módulo desde otros módulos

Lo primero es obtener una instancia de IModuloComunicaciones mediante una

llamada a IGestorModulos.obtenerInstanciaModulo("Comunicaciones"). A partir de

aqui se pueden usar los métodos definidos en la interfaz que pasamos a detallar:

IModuloComunicaciones public void registrarProtocolo(int

idProtocolo,IReceptorEventosComunicaciones receptor)

Incluye en la lista de observadores para el protocolo idProtocolo el

IReceptorEventosComunicaciones receptor, para que este pueda recibir los eventos

generales del módulo comunicaciones asi como los especificos de ese protocolo.

public void desregistrarProtocolo(int idProtocolo,IReceptorEventosComunicaciones receptor)

Elimina un IReceptorEventosComunicaciones de la lista de receptores del protocolo

especificado

public void enviarMensaje(int idProtocolo,int idCliente,String comando,Object datos)

Envia un mensaje al cliente indicado

public void enviarMensaje(int idCliente,Mensaje msg)

Envia un mensaje al cliente indicado

public Usuario getUsuario(int idCliente)

Permite ontener un Usuario conectado dado un identificador de cliente

public Usuario getUsuario(String apodo)

Permite ontener un Usuario conectado dado un apodo de cliente

58

Los eventos del módulo de comunicaciones los procesan observadores, que son

instancias de IReceptorEventosComunicaciones, los métodos que debe implementar

un posible observador son:

IReceptorEventosComunicaciones public void mensajeRecibido(int idCliente,Mensaje msg)

Metodo que es llamado por el modulo de comunicaciones cuando a éste le llega un

mensaje destinado a un protocolo para el cual se ha registrado previamente la instancia

actual de IReceptorEventosComunicaciones. Es importante que este método termine

lo antes posible y que bajo ningun concepto provoque envio de datos de forma directa o

indirecta (hay peligro de reentrada en el thread que podría provocar el cuelgue del

módulo de comunicaciones), por ello se recomienda guardar el mensaje en alguna

estructura apropiada (p.e. una cola) que sea procesada desde un hilo aparte.

public void usuarioDesconectado(int idCliente)

Metodo que es llamado por el módulo de comunicaciones cuando un usuario se

desconecta del sistema. Conviene tener en cuenta que una vez se ha disparado este

evento no se puede obtener una instancia de Usuario a partir de idCliente, por lo que si

es necesario acceder a datos del usuario despues de su desconexión habrá que crear una

instancia por su apodo o tenerla almacenada previamente.

Para la gestión de usuarios los módulos que usen el de comunicaciones pueden obtener

instancias de la clase Usuario que proveen de todo lo necesario para la

consulta/modificacion de los datos de los jugadores.

Usuario

Responsabilidad

La clase es responsable de transformar las peticiones o modificaciones de datos de un

usuario en llamadas a la base de datos. También comprueba la validez de los

credenciales proporcionados por un cliente.

Dependencias IModuloBaseDatos: Para acceso a los datos.

59

IModuloLog: Para la notificación de problemas. Sentencia: Como empaquetamiento de consultas SQL.

Métodos public Usuario(String identificador,IModuloBaseDatos bd) throws Exception

Crea una instancia de la clase Usuario a partir de una cadena de texto que representa su

nombre de usuario y contraseña e intenta identificarlo contra la base de datos, lanzando

una excepcion si no se puede

public Usuario(String nombre)

Crea un usuario para facilitar la consulta de datos sobre el mismo

public static void stIniciaLog(IModuloLog ml)

Asigna el modulo de log que va a ser usado por las instancias de Usuario

public static Usuario stGetUsuario(String nombre)

Obtiene la instancia de un Usuario conectado al sistema con el nombre indicado

public static boolean stNuevoUsuario(Usuario u)

Permite añadir un Usuario a la coleccion de usuarios conectados(No debe ser usado

desde fuera del módulo comunicaciones).

public int getPuntos(String nombreJuego, IModuloBaseDatos bd)

Permite acceder a los puntos del Usuario para un juego dado

public boolean setPuntos(String nombreJuego, IModuloBaseDatos bd, int puntos)

Permite actualizar los puntos del Usuario para un juego dado

public boolean anadePuntos(String nombreJuego, IModuloBaseDatos bd, int puntos)

Incrementa los puntos del Usuario para un juego dado ya sea positivamente o

negativamente

public String getNombre()

Devuelve el nombre del Usuario

60

public int[] dameLogros (String nombreJuego, IModuloBaseDatos bd)

Permite acceder a los logros del Usuario para un juego dado

public boolean anadeLogro (String nombreJuego, IModuloBaseDatos bd, int logro)

Permite añadir nuevos logros para el Usuario y el juego indicado

public boolean quitaLogro (String nombreJuego, IModuloBaseDatos bd, int logro)

Permite quitarle a un Usuario algun logro del juego indicado

public String[] dameListaAmigos(IModuloBaseDatos bd)

Permite obtener una lista de amigos para el Usuario

public boolean anadeAmigo (String amigo, IModuloBaseDatos bd)

Añade un amigo a la lista de amigos del Usuario

public boolean quitaAmigo (String amigo, IModuloBaseDatos md)

Quita un amigo de la lista de amigos de Usuario

La unidad minima de informacion que transmite el módulo de comunicaciones es el

mensaje, que pasamos a detallar:

Mensaje

Responsabilidad

Actua como clase contenedora para los datos y metadatos que se envian en cualquiera

de las dos direciones entre cliente y servidor. Por tanto esta clase la deben usar tanto los

modulos de servidor como los del cliente

Dependencias XStream: Para serializar el contenido del mensaje a una cadena de bytes

Métodos public Mensaje(MetaDatos metadatos,Object datos)

61

Crea un nuevo mensaje dados unos datos y unos metadatos

public MetaDatos getMetadatos()

Permite obtener los metadatos del mensaje

public Object getDatos()

Permite obtener los datos del mensaje

public byte[] serializa(XStream xs)

Convierte el mensaje en una cadena de bytes para poderlo enviar

Metadatos

Responsabilidad

Es la clase responsable de contener informacion sobre los datos y el mensaje. Se puede

heredar de esta clase si se desea añadir mas funcionalidad

Dependencias

Metodos public MetaDatos(int idProtocolo,String comando)

Dado un protocolo y un comando crea un Metadato

public int getIdProtocolo()

Permite obtener el número identificador del protocolo

public String getComando()

Permite obtener el comando que contiene Metadatos

ReconstructorMensajes

Responsabilidades

Reconstruir instancia de mensajes que le llegan como una secuencia de bytes. Se usa

internamente en el módulo comunicaciones y la pueden usar los clientes que deseen

62

comunicarse con este.

Dependencias XStream: Para la deserializacion de los mensajes

Metodos public boolean nuevoFragmento(byte[] fragmento)

Añade al bufer de fragmentos un conjunto de bytes recibidos generando con ellos si es

posible un nuevo Mensaje

public boolean hayMensajes()

Determina si hay Mensajes en la cola de mensajes

public Mensaje damePrimerMensaje()

Devuelve el primer Mensaje de la cola de mensajes

public void eliminaPrimerMensaje()

Elimina el primer Mensaje de la cola de mensajes

Uso desde la aplicación

Las aplicaciones que desen comunicarse con el servidor han de incluir una referencia al

fichero ModuloComunicacionesComun.jar para poder usar las clase Mensaje,

Metadatos y ReconstructorMensaje. Este fichero no incluye implementacion alguna

de un sistema de sockets por lo que, corre a cargo del implementador de la aplicacion,

preparar todo lo necesario para establecer la conexion

Secuencia de una comunicación

63

http://portaljuegos.wikidot.com/local--files/diseno-del-modulo-de-comunicaciones/ComunicacionesSencuenciaUML.png

64

http://portaljuegos.wikidot.com/local--files/diseno-del-modulo-de-comunicaciones/ComunicacionesSencuenciaUML.png

Módulo de Chat (Servidor)Este el modelo del servidor de Chat.Su función básica es recibir los mensajes del módulo de comunicaciones y tratarlo como sea consecuente a través de una serie de comandos:/susurro : envia un mensaje privado./dice: envia un mensaje a todos los usuarios de un canal.…

A través de las Interfaces se da acceso a este módulo desde otros.Para enviar/recibir mensajes mirar la clase ChatDatos que son las que normalmente se adjuntarán.

65

http://portaljuegos.wikidot.com/local--files/disenochatservidor/chatserver.png

Módulo de Base de Datos

DescripcionEl Modulo de Base de Datos actua de intermediario estre los modulos de servidor y la

base de datos del sistema, proporcionando metodos para lanzar consultas contra esta.

DependenciasModulo de Log

Usado para notificar errores graves del sistema

Empaquetado

66

http://portaljuegos.wikidot.com/local--files/diseno-del-modulo-de-base-de-datos/BaseDeDatosComunUML.png

La implementación del módulo está en el fichero ModuloBaseDeDatos.jar mientras que

los interfaces y clases usables por otros modulos se encuentran en

ModuloBAseDeDatosComun.jar

Uso del móduloUso del módulo desde otros módulos

Lo primero es obtener una instancia de IModuloBaseDeDatos mediante una llamada a

IGestorModulos.obtenerInstanciaModulo("BaseDeDatos"). A partir de aqui se pueden

usar los métodos definidos en la interfaz que pasamos a detallar:

IModuloBaseDatos Sentencia ejecutarBloqueando(String sql)

Ejecuta una consulta sql bloqueando el thread actual hasta que los resultados están

disponibles

void ejecutarAsincrono(String sql,IReceptorBD recep)

Ejecuta una consulta sql asíncronamente

Sentencia ejecutarBloqueando(String sql,int idTransaccion)

Ejecuta una consulta sql bloqueando el thread actual hasta que los resultados están

disponibles. La consulta se ejecutará en el contexto de la transacción indicada por el

parámetro idTransacción

void ejecutarAsincrono(String sql,IReceptorBD recep,int idTransaccion)

Ejecuta una consulta sql asíncronamente. La consulta se ejecutará en el contexto de la

transacción indicada por el parámetro idTransacción

int iniciarTransaccion()

Inicia una transacción en la base de datos que garantiza que las siguientes consultas

realizadas contra ella usando el identificador de transacción devuelto se ejecutan de

forma atómica

void confirmarTransaccion(int idTransaccion)

67

Confirma todas las operaciones realizadas para la transacción indicada en el parámetro

idTransaccion (escribiendo en la base de datos) y la termina.

void cancelarTransaccion(int idTransaccion)

Cancela todas las operaciones realizadas para la transacción indicada en el parámetro

idTransaccion y la termina.

Si se desea usar el modelo de acceso a datos asincrono es necesario implementar un

observador de eventos del modulo de base datos que ha de cumplir con la siguiente

especificacion:

IReceptorBD public void datosRecibidos(Sentencia res)

Método llamado por el módulo de bases de datos cuando una consulta asíncrona ha

terminado su ejecución

Los resultados de las consultas se encapsulan en una clase llamada Sentencia:

Sentencia

Responsabilidad

Encapsular consultas hacia la base de datos, asi como los resultados de las mismas y los

posibles errores que hayan sucedido

Dependencias

Métodos public Sentencia(String sql,Semaphore sem) public Sentencia(String sql,IReceptorBD recep)

Constructoras. Para uso interno del módulo

public void completar(ResultSet res, Exception ex,EEstadoResultado estado) public void completar(int numAfectados, Exception ex,EEstadoResultado

estado)

Usado para introducir los resultados de una consulta en la sentencia. Para uso interno

68

public boolean esAsincrono()

Indica si una sentencia se ejecuta de forma asincrona

public String getSql()

Devuelve la consulta SQL a ejecutar

public Semaphore getSemaforo()

Obtiene el semaforo usado para sincronizacion en caso de *Sentencia* sincrona

(bloqueante)

public IReceptorBD getReceptor()

Facilita la instancia de la clase observadora, que obtendrá los resultados de esta consulta

public ResultSet getResultado()

Devuelve los resultados de ejecutar la consulta SQL

public Exception getEx()

Devuelve la excepcion ocurrida, en caso de que haya habido

public EEstadoResultado getEstadoEjecucion()

Devuelve el estado con el que terminó la ejecucion

public int getNumAfectados()

Nos indica el numero de filas afectadas en la ultima operacion

69

Módulo de LogDescripciónRepresenta la forma de guardar errores y excepciones ocurridos en un archivo

DependenciasEmpaquetadoLa implementación del módulo está en el fichero ModuloLog.jar mientras que la

interface usable por otros modulo se encuentra en ModuloLogComun.jar.

Uso del MóduloUso del módulo desde otros módulos

Lo primero es obtener una instancia de IModuloLog mediante una llamada a

IGestorModulos.obtenerInstanciaModulo("Log"). A partir de aqui se pueden usar los

métodos definidos en la interfaz que pasamos a detallar:

IModuloLog public void escribirInformacion(Object llamador,String mensaje)

Se encarga de escribir una linea de informacion en el log diario

public void escribirError (Object llamador, String mensaje)

Escribe una linea de error en el log diario

public void escribirExcepcion (Object llamador, Exception ex, String mensaje)

Escribe una linea de excepcion en el log diario

70

Módulo de Chat (Cliente)DescripciónEl módulo chat se encarga de comunicar mediante mensajería instantánea a los distintos

usuarios.

DependenciasMódulo de comunicaciones

Usado para el envío y la recepción de los mensajes.

Uso del móduloLo primero es crear una instancia del chat ya sea mediante la utilización de la constructora con canal o sin canal. Después de la creación se realiza una llamada a unirseAlCanal aportándole el entero identificador del canal. En este módulo se implementan los métodos aceptarMensaje y getPanel del IComponenteCliente para que el Cliente pueda incorporarlo.

71

Módulo de JuegosEste módulo se encuentra en el paquete IStation.Modulos.Juegos.Servidor. Para

implementar el módulo de juegos se han creado las dos clases necesarias para definir

cualquier módulo:

ModuloJuegosLa clase ModuloJuegos es la encargada de administrar todas las partidas que se juegan a

cada uno de los juegos del sistema. La funcionalidad de cada juego concreto se

encuentra en módulos externos, que la clase ModuloJuegos se encarga de cargar al

inicio para tenerlas disponibles cuando las utilice. Esta clase también es la que va a

facilitar a las partidas de los juegos el acceso a la base de datos (para realizar algunas

acciones concretas) y la comunicación con los clientes situados en ordenadores remotos.

La clase ModuloJuegos utiliza otros módulos como el módulo de comunicaciones, el de

bases de datos y el módulo de chat. En concreto, utiliza las entidades

IModuloComunicaciones, Mensaje, Metadatos y ModuloChat.

Al tratarse de una clase que administra las partidas, un objeto de ModuloJuegos

contiene un conjunto de referencias a objetos de la clase Partida.

Para las funciones de carga dinámica de los distintos juegos, utilizará también la clase

ClassLoader y otras clases pertenecientes al JDK.

Descripción de los métodos:

java.lang.String consultarNombreJugador(int idCliente)

Devuelve el nombre con el que se registró el cliente con identificador idCliente.

Para obtener este dato consulta con el módulo de comunicaciones.

int consultarPuntosJugador(int idCliente)

Devuelve la cantidad de puntos que tiene el cliente con identificador idCliente.

Para obtener este dato consulta con el módulo de comunicaciones.

void eliminaPartida(int idPartida)

72

Este método se utiliza para notificar el fin de una partida. El de juegos procederá

entonces a elmiminar todas las referencias a esa partida, de forma que dejará de

enviarles mensajes.

void enviarMensaje(int idCliente, java.lang.Object msg)

Permite a las partidas enviar mensajes al cliente que se encuentra en un ordenador

remoto. El objeto que se envía al cliente debe ser de un tipo que éste pueda reconocer.

Este método utiliza las constructoras de las clases Mensaje y MetaDatos.

void mensajeRecibido(int idCliente, IStation.Modulos.Comunicaciones.Mensaje msg)

Acepta mensajes del módulo de comunicaciones y los trata adecuadamente, tratándolos

o remitiéndolos a la partida correspondiente.

Este método utiliza los métodos aceptarDatos y anadeCliente de la clase Partida.

void partidaIniciada(int idPartida)

Método para que la partida avise al modulo juegos que ya está iniciada.

Este método utiliza la entidad IModuloBaseDeDatos.

java.lang.Object salvarEstado()

Devuelve un objeto que contiene todos los datos necesarios para guardar el estado

actual del módulo.

void sumarPuntosJugador(int ptos, int idCliente)

Suma a los puntos de un usuario (jugador) una cantidad positiva o negativa. Si el

resultado de sumar los puntos a un usuario es negativo, entonces el usuario se queda con

0 puntos.

Este método utiliza el módulo de comunicaciones para llevar a cabo la acción.

void terminarModulo()

Realiza las acciones necesarias para finalizar el módulo.

void usuarioDesconectado(int idCliente)

73

Permite al módulo de juegos recibir notificaciones de que un cliente ha perdido la

conexión con el servidor. Esta desconexión ha podido ser voluntaria o involuntaria.

Utiliza el método aceptarDatos de la clase Partida.

InicioModuloJuegosEsta clase actúa como un creador de instancias de la clase ModuloJuegos, ocultando así

las constructoras y permitiendo que el Servidor haga una carga dinámica de los distintos

módulos.

Descripción de los métodos:

IStation.Modulos.IModulo iniciarModulo(IStation.Modulos.IGestorModulos gestor)

Este método obtiene una instancia de la clase ModuloJuegos.

Utiliza la entidad IGestorModulos para obtener instancias de las entidades que necesita

el módulo de juegos: el módulo de comunicaciones, el de base de datos y el de chat.

IStation.Modulos.IModulo iniciarModulo(java.lang.Object estado,

IStation.Modulos.IGestorModulos gestor)

Este método obtiene una instancia de la clase ModuloJuegos.

Utiliza la entidad IGestorModulos para obtener instancias de las entidades que necesita

el módulo de juegos: el módulo de comunicaciones, el de base de datos y el de chat.

Este método permite restablecer el estado previamente guardado a través del argumento

estado.

74

Implementar juegos _________________________

Framework Cliente

El framework consistirá en una clase con ciertas funciones comunes a todos los juegos implementadas de forma que el creador de juegos la extienda y pueda utilizar estas funciones, teniendo únicamente que preocuparse de sus atributos y del desarrollo de su juego. Estas funciones serán las encargadas de comunicarse con el servidor y mostrar información de la partida al usuario, para ello deberá contener funciones básicas como enviar y recibir mensajes, o pasar turno.

Atributos del framework:El Framework no deja de ser una clase, y como tal, puede tener atributos, y hay algunos atributos que serán comunes a todos los juegos, todos ellos con sus métodos mutadores y accesotes, estos serán:

private String _idJuego //identifica el juego que esprivate int _idPartida //identifica la partidaprivate String _idUsuario //identificación del usuarioprivate String _turnoDeQuien //de qué id de usuario es el turnoprivate String[] _jugadores //jugadores de la partidaprivate int _numJugadores //número de jugadoresprivate ModuloComunicaciones _mc //para comunicarse con el servidorprivate BlockingQueue _cola //cola de mensajes

Funciones sobre la partida:Será necesario tener funciones para iniciar la partida, abandonar la partida, unirse a la partida y finalmente cerrar la partida

public abstract void unirsePartida ():El cliente envía al servidor la solicitud de unirse a la partida definida por el idPartida con su identificación de usuario

protected abstract void iniciarPartida ():Da la orden de iniciar la partida, seria bueno enviar la ID de usuario para que el servidor pueda decidir cuando comienza, cuando todos los usuarios conectados inicien.

75

http://portaljuegos.wikidot.com/local--files/disenoframeworkcliente/General.png

Funciones para el desarrollo de la partida:Aquí tendremos funciones comunes a todos los juegos para el transcurso de la partida; Ya que todos los juegos serán por turnos, necesitaremos funciones para pasar turno.

Turno:Envía el mensaje al servidor de pasar turno, aquí podemos contemplar varios casos para la implementación final, podríamos tomar la alternativa, de que el cliente seaquien dice al servidor de quien es el turno siguiente, o de que sea el servidor quien lo decide, en ambos casos, necesitamos un método que nos diga que es nuestro turno

protected boolean meToca ()Comprobara si su propio idUsuario coindice con el usuario que tiene el turno

public void pasarTurno()Donde idUsuario dice quién es el usuario que para el turno, el servidor decidirá y asignará el próximo turno al usuario correspondiente

public abstract void clienteAbandona(int idJugador):Recibe qué jugador ha abandonado la partida

Jugar:El desarrollo del juego viene dirigido por eventos tales como que se ha recibido un mensaje o que se ha pulsado un botón. No hay bucle.

public void run():Procesa los mensajes recibidos que se encuentran en la cola y realiza las acciones oportunas. Llama a procesarMensaje() en el caso de que sea un mensaje particular de cada juego

Otras:public void aceptarMensaje(Object mensaje, String comando):Mete los mensajes recibidos en una cola.

public abstract void procesarMensaje(String mensaje):Dependiendo de cada juego, hará las acciones pertinentes con la información del mensaje

public int getNumJugadores():Devuelve el número de jugadores de la partida

76

portaljuegos.wdfiles.comportaljuegos.wdfiles.com/local--files/entregas/DocEnero.… · Web viewEl...

Documents

Transcript of portaljuegos.wdfiles.comportaljuegos.wdfiles.com/local--files/entregas/DocEnero.… · Web viewEl...