Planteamiento14 11 08

El Juego del Mus
Proyecto de desarrollo de un mus interactivo

Grupo de PBL de 3º de Ingeniería Técnica en Informática de Sistemas
Índice
1 ABSTRACT............................................................................................................................................ 4
2 PLANTEAMIENTO ................................................................................................................................ 4
3 OBJETIVOS DEL PROYECTO .................................................................................................................. 4
3.1 MÍNIMOS ....................................................................................................................................... 4

3.2 LÍMITES .......................................................................................................................................... 5
4 ANÁLISIS .............................................................................................................................................. 5
4.1 ANÁLISIS CONCEPTUAL...................................................................................................................... 5

4.1.1 El juego del Mus ...................................................................................................................... 5
4.1.2 Mercado.................................................................................................................................. 8
4.1.3 Usuarios .................................................................................................................................. 9
4.1.4 Gestión .................................................................................................................................... 9
4.1.5 Software ................................................................................................................................. 9
4.1.6 Inteligencia artificial ............................................................................................................. 11
4.1.7 Esquema conceptual ............................................................................................................. 11
4.2 ANÁLISIS TÉCNICO .......................................................................................................................... 12
4.2.1 Base de datos........................................................................................................................ 12
4.2.2 Software ............................................................................................................................... 13
4.2.3 Agente inteligente ................................................................................................................ 17
4.2.4 Esquema general .................................................................................................................. 17
5 PLANIFICACIÓN ................................................................................................................................. 18
5.1 PLANIFICACIÓN GENERAL ................................................................................................................. 18

5.2 DIVISIÓN DEL TRABAJO .................................................................................................................... 20
6 DESARROLLO ..................................................................................................................................... 20
6.1 MODELIZACIÓN ............................................................................................................................. 20

6.1.1 Base de Datos ....................................................................................................................... 20
6.1.2 Software ............................................................................................................................... 21
6.1.3 Agente inteligente ................................................................................................................ 23
6.2 IMPLEMENTACIÓN .......................................................................................................................... 24
7 RESULTADOS ..................................................................................................................................... 24
8 LÍNEAS DE EXPANSIÓN ...................................................................................................................... 24
9 ANEXOS ............................................................................................................................................. 25
9.1 OBJETIVOS DE APRENDIZAJE ............................................................................................................. 25

9.2 COMPARACIÓN ENTRE JAVA Y C ........................................................................................................ 25
9.3 HERRAMIENTAS PARA LA IMPLEMENTACIÓN DE UN SE EN JAVA ............................................................... 27
9.4 DISEÑO DE LA BASE DE DATOS........................................................................................................... 28
9.5 DESCRIPCIÓN DE CASOS DE USO ........................................................................................................ 29
9.5.1 Jugar una partida.................................................................................................................. 29
9.5.2 Crear una partida.................................................................................................................. 30
2
El Juego del Mus
9.5.3 Ver una partida ..................................................................................................................... 31

9.5.4 Guardar una partida ............................................................................................................. 32
9.6 PROTOCOLO COMUNICACIÓN CLIENTE-SERVIDOR ................................................................................. 33
9.6.1 Paquetes Cliente->Servidor ................................................................................................... 33
9.6.2 Paquetes Servidor->Cliente ................................................................................................... 36
9.7 SOFTWARE EMPLEADO .................................................................................................................... 38
9.7.1 Eclipse ................................................................................................................................... 38
9.7.2 Assembla............................................................................................................................... 38
9.7.3 Subclipse ............................................................................................................................... 38
9.7.4 MySQL Workbench ............................................................................................................... 38
9.8 LICENCIA JESS............................................................................................................................... 38
10 BIBLIOGRAFÍA .................................................................................................................................... 39
3
El Juego del Mus
1 Abstract
2 Planteamiento
Se debe desarrollar un sistema de juego online que permita a los usuarios del sistema
jugar contra otros usuarios o agentes software con inteligencia artificial. Se han propuesto
varios juegos: mus, conecta4…
Se busca que los miembros del equipo adquieran ciertos conocimientos relacionados
con la temática del proyecto: programación concurrente, inteligencia artificial, metodologías
de desarrollo de software, diseño de software usando diagramas UML1, etc. (Anexos: Objetivos
de aprendizaje).
El equipo de proyecto ha escogido desarrollar un sistema de juego online que permita

jugar al mus. Esta elección se basa únicamente en las preferencias y motivaciones de los
miembros del equipo.
3 Objetivos del proyecto

Teniendo en cuenta el planteamiento del proyecto y los objetivos de aprendizaje que
se deben perseguir, debemos definir sus fronteras. Colocaremos diferentes ideas y elementos
tanto fuera como dentro de éstas. Aquello que consideremos indispensable para lograr los
conocimientos exigidos será ubicado dentro de los mínimos del proyecto. Todo lo demás
estará fuera de estos límites, siendo considerado un extra a desarrollar en caso de haber
logrado cumplir con todos los mínimos.
3.1 Mínimos
Distinguiremos dos tipos de usuarios a los que estará dirigido el sistema a desarrollar:
usuarios no registrados y usuarios registrados. Las funcionalidades mínimas a ofrecer y
satisfacer serán las siguientes:
Los usuarios no registrados podrán:
Registrarse en el sistema desde una interfaz web.

Descargar el software necesario desde una interfaz web.
Los usuarios registrados podrán:
Chatear con el resto de jugadores conectados al sistema de juego.

Jugar partidas de mus tanto uniéndose a partidas ya creadas como creando las
suyas propias.
Ver como espectadores partidas de mus.
1
Unified Modeling Language
4
El Juego del Mus
Los usuarios registrados que creen una partida podrán decidir si alguno o varios
jugadores son representados por agentes software con inteligencia artificial.
3.2 Límites
Basándonos en las funcionalidades mínimas previamente descritas, y en los objetivos
de aprendizaje, excluiremos las ideas y mejoras que no ayuden a lograr estos objetivos. Todos
estos extras se describen en la sección Líneas de expansión.
4 Análisis
En esta sección se definirá conceptual y técnicamente todas las características del
proyecto a desarrollar, lo cual permitirá dar el paso a la fase de desarrollo.
4.1 Análisis Conceptual

A continuación, se concretará conceptualmente el proyecto evitando entrar en
cuestiones técnicas. Se estudiarán una a una las diferentes partes de las que estará formado el
sistema, determinando por completo la forma de cada una de ellas.
4.1.1 El juego del Mus

El mus es un juego de cartas que usa una baraja española de 40 naipes, la cual excluye
los ochos y los nueves. En la modalidad de 8 reyes, la más extendida, los treses se consideran
reyes, y los doses se consideran ases. Participan cuatro jugadores agrupados por parejas, una
contra la otra. En la mesa de juego, cuadrada o circular, los miembros de cada pareja deben
colocarse uno frente a otro.
Una partida de mus se divide en vacas y estas en juegos. La pareja ganadora de la

partida es aquella que gane 3 vacas antes que la contraria, y gana una vaca aquella pareja que
consiga ganar 3 juegos antes que la contraria. En un juego, la pareja que antes logre 40 piedras
es la ganadora. El juego se compone de un número de manos indefinidas, y éstas, además, se
componen, en el siguiente orden, de las siguientes fases de juego o lances: grande, pequeña,
pares y juego (1).
4.1.1.1 Fase inicial

En la fase inicial de cada mano, hay que diferenciar si se trata de la primera mano de
un juego o no. Si fuera así, se procederá al mus corrido y sin señas.
En este caso particular, estando las señas prohibidas (concepto explicado más
adelante), un jugador cualquiera barajará y dará a cortar al jugador sentado a su izquierda. A
continuación, repartirá 4 cartas a cada jugador comenzando por el jugador sentado a su
derecha y entregando una carta cada vuelta. Dejará el taco de cartas sobrantes a su izquierda.
En este momento, el repartidor comenzará con la fase de mus o no mus. Cada jugador,
de uno en uno y teniendo en cuenta sus cartas, decidirá si corta el mus o se da mus. Si cortase
el mus, se convertiría en mano (concepto explicado más adelante) y daría comienzo la fase del
5
El Juego del Mus
juego a grande; si se diera mus, movería el taco de cartas a su derecha pasándole el turno al
siguiente jugador.
Si se llegase a completar una vuelta sin corte de mus, el repartidor movería de nuevo
el taco de cartas a su derecha, y los jugadores pasarían a descartarse de mínimo una carta.
Estas cartas pasarían momentáneamente a estar fuera del juego. Seguidamente, el jugador
sentado a la derecha del repartidor comenzaría a entregar el número de cartas necesario a
cada jugador para que cada uno tenga 4 cartas; comenzando por el jugador de su derecha y
terminando en él mismo. Este proceso se repite hasta que alguien corte el mus o no queden
cartas en el taco, momento en el que se baraja el taco de descartes para poder seguir
repartiendo cartas.
Si no estuviéramos en la primera mano de un juego, el jugador sentado a la derecha

del taco de cartas, es decir, la mano, sería el que repartiera las cartas; con la diferencia de que
al terminar de repartir deja el taco a su derecha, de que al darse mus el taco no se mueve y de
que es él de nuevo el encargado de repartir si se completase una vuelta.
4.1.1.2 Apuestas
En cada lance de una mano, cada jugador comenzando por la mano y de derecha a
izquierda tiene la oportunidad de apostar o pasar. Puede apostar tantas piedras como desee,
con un mínimo de 2 piedras, la cual se llama envido, mientras que órdago significa apostar
todo el juego.
Si un jugador apostase, la otra pareja tiene la opción de pasar, querer o subir la

apuesta. Si pasara, la pareja contraria se llevaría en ese mismo instante un tanto de porque no;
si subiera la apuesta, la otra pareja podría a su vez pasar, querer o subir, con la diferencia de
que si pasara, la pareja contraria se llevaría instantáneamente tantos puntos de porque no
como la suma del valor de las apuestas precedentes.
Por ejemplo, si la mano al comienzo del lance a grande envidara, se llevaría dos puntos
al final del juego siempre y cuando la pareja contraria viera la apuesta y su jugada o la de su
compañero fuera mejor (a grande) que cualquier jugada de la pareja contraria. Si la pareja
contraria pasase, se llevarían una piedra instantáneamente de porque no. En cambio, si la
pareja contraria subiera la apuesta 5 más, se cambiarían las tornas, con la diferencia de que si
no se quiere la apuesta, los puntos de porque no serían los del total de apuestas acumuladas
sin contar la última (en este caso 2).
Si todos los jugadores pasaran en algún lance sin haber apuestas, es decir, si se dejase
un lance en paso, al final de la mano se verificará cuál es la pareja que gana en cada lance.
Cada pareja ganadora de cada lance se adjudicará seguidamente un punto si se trata de grande
o pequeña y los puntos que correspondan si se trata de pares o juego. Este recuento se explica
con claridad en la sección que describe la fase de tanteo.
6
El Juego del Mus
4.1.1.3 Puntuación de las cartas

Hay que tener en cuenta que los reyes, caballos y las sotas puntúan 10 puntos,
mientras que el resto de cartas puntúan su valor escrito (los cincos 5 puntos etc.).
Recordemos que los treses se consideran reyes, y los doses ases, por lo que suman 10 y 1
punto respectivamente. Este sistema de puntuación se usa en algunos lances tal y como se
describirá a continuación.
4.1.1.4 Grande
En el lance a grande, la combinación de las 4 cartas de cada jugador es mejor cuanto
mayor sea su valor y mayor número de reyes tenga, siendo mejor combinación, por ejemplo,
dos reyes y dos cuatros que dos caballos y dos sotas.
4.1.1.5 Pequeña
En este lance, la combinación de las 4 cartas de cada jugador es mejor cuanto menor
sea su valor y mayor número de ases tenga; siguiendo la misma lógica que el lance a grande.
4.1.1.6 Pares
En esta fase de la mano, cada jugador, en el orden habitual, debe primero decir si
posee pares (dos o más cartas iguales). Si las dos parejas tuvieran al menos un jugador con
pares, se procedería al lance. Se pasaría a apostar como en mayor y pequeña.
Hay que diferenciar tres tipos de combinaciones diferentes: pareja, con dos cartas
iguales; medias, con tres cartas iguales y dúplex, con dos parejas diferentes o iguales de cartas.
Ganan primero los dúplex, después las medias y por últimos las parejas. Al igual que en mayor,
se le da mayor importancia a las cartas de más valor, siendo los reyes las cartas de mayor
importancia.
Es por todo esto que, por ejemplo, unos dúplex de reyes ganan a unos dúplex de dos
reyes y dos caballos. También, por ejemplo, unas medias de ases ganan a una pareja de reyes.
4.1.1.7 Juego
El lance a juego comienza de la misma manera que el de pares: cada jugador, en orden,
debe decir si posee juego o no. Posteriormente comienza el lance o fase de apuestas.
Se considera juego una combinación de cartas que sume 31 o más puntos. Hay que
tener en cuenta que la combinación que gana primero es la que suma 31 puntos, después 32 y
seguidamente 40, 39, 38, 37, 36, 35, 34 y 33.
Por ejemplo, un jugador que posea una combinación que sume 35 puntos no gana a
aquél que posea otra que sume 32 o 31, pero sí a aquellos que posean combinaciones que
sumen 33 o 34 puntos.
Si ningún jugador tuviera juego (combinación de cartas que sume 31 o más puntos), se
pasaría a jugar al punto. En esta parte, la combinación ganadora es aquella cuya suma se
acerque más a 30.
7
El Juego del Mus
4.1.1.8 Tanteo
Al final de una mano, cada jugador muestra sus cartas y se pasan a contabilizar los
puntos de las apuestas y de tanteo. En el orden de los lances (grande, pequeña, par y juego),
cada pareja se adjudicará los puntos de tanteo y los que le correspondan por cada apuesta que
haya ganado.
Existen puntos de tanteo en los pares y el juego. En el lance de pares, la pareja

ganadora a pares se adjudicará 3 puntos por cada dúplex que posea, 2 puntos por cada media
y un punto por cada pareja de cartas. De la misma manera que en el lance a pares, la pareja
ganadora del lance a juego se sumará 2 puntos por juego que posean, siendo 3 puntos si la
combinación de cartas sumara 31 puntos. Por ejemplo: si de la pareja ganadora del lance a
juego uno de los jugadores poseyera una combinación de cartas que sumaran 31 puntos entre
sí y el otro una combinación que sumara 40 puntos, se adjudicarían 5 puntos al final de la
mano. La pareja que haya ganado el lance del punto, se adjudicará un punto extra al final de la
mano.
Si alguna pareja llegase a 40 piedras al contabilizar estos puntos, gana el juego. Si

ambas llegaran a 40 puntos en esta fase, se observará el lance en el que han llegado a esta
cifra: digamos grande en el caso de la pareja A y juego en el de la pareja B. En este supuesto la
pareja A sería la vencedora, ya que el lance de grande se juega antes que el de juego.
4.1.1.9 Mano
El jugador que se sienta a la derecha del taco de cartas es también llamado mano. Este
concepto es importante, ya que en la fase de tanteo, si en un lance se produjera un empate
técnico (misma combinación ganadora poseída por al menos un jugador de cada pareja), el ser
mano o la cercanía a ésta (siendo el jugador más cercano el que se sienta a su derecha y el más
lejano el sentado a su izquierda) es el factor que decide quién gana.
Pongamos dos ejemplos. Si en el lance a juego la mano suma 31 puntos y el jugador de

la pareja contraria sentado enfrente también, ganaría el jugador mano. Si en el lance a pares el
jugador sentado enfrente de la mano y el situado a la izquierda de ésta poseen par de reyes,
por la cercanía a la mano ganaría el lance el jugador sentando enfrente de ésta.
4.1.2 Mercado
Los juegos tradicionales en versión online son muy comunes en distintos portales de
Internet. Los portales, suelen estar compuestos por distintas salas, cada uno con su propio
nivel de dificultad.
En cada sala, suele haber un chat general, para hablar con los compañeros de la sala y
así crear partidas. También, suele haber un alto número de juegos, muchos de ellos
tradicionales, como el mus, domino y ajedrez. Una vez que se ha creado la partida, y los
distintos jugadores se han unido a ella, suelen ofrecer otro chat de la partida, para
comunicarse entre ellos, mientras se juega. Un buen ejemplo de este tipo de programas podría
8
El Juego del Mus
ser Garena, plataforma multifunción que permite a los jugadores chatear y jugar a multitud de
juegos contra otros usuarios (2).
Es muy interesante, que un cierto de número de jugadores, puedan estar controlados

por el computador, ya que así, aun no teniendo un número suficiente de jugadores físicos, se
pueda llevar adelante un juego como el mus, que requiere cuatro jugadores. Es casi obligatorio
un chat citado anteriormente para mejorar la comunicación entre jugadores.
4.1.3 Usuarios
En nuestro sistema se definirán dos tipos distintos de usuarios: el usuario no registrado,
y el usuario registrado. El usuario no registrado deberá poder realizar dos únicas cosas,
descargar el juego y registrarse en el sistema. Como es obvio, cualquier jugador registrado
también podrá descargarse el juego. Estas dos opciones serán ofrecidas en una página web.
Una vez registrado, y habiéndose identificado previamente, pasará a poder realizar

todas las demás opciones que ofrecerá nuestro sistema, tales como chatear en un salón, jugar
una partida, ver una partida, chatear en una partida, etc.
4.1.4 Gestión
Para que el sistema pueda gestionar los usuarios y partidas del mismo, son necesarias
unas base de datos y una página web. La página web se utilizará para poder descargar la
aplicación, y también ofrecerá la posibilidad de registrarse como usuario.
Los datos de los usuarios deberán ser almacenados de forma persistente para
posteriormente autentificar e identificar a cada usuario en el entorno del sistema. Para esto,
se utilizará una base de datos. Se almacenarán datos como el nombre, id, contraseña,
privilegios…
También es interesante utilizar la base de datos para guardar estadísticas, o diferentes

datos de partida; así como para guardar los datos de las partidas, cuando los usuarios utilizan
la opción de guardar, y permitirles reanudarla en cualquier otro momento.
Esta base de datos debería estar alojada en el servidor, ya que es esta figura la que
aglutina todos los procesos de juego y gestión de usuarios.
4.1.5 Software
Se describirán a continuación, sin entrar en cuestiones técnicas, las diferentes partes
de software necesarias para construir el sistema.
4.1.5.1 Programa cliente

Primeramente el cliente deberá identificarse con el sistema, introduciendo su nombre
de usuario y su contraseña. Tras esto, y si la autentificación es correcta, deberá visualizar una
lista de salones, con el número de participantes en cada uno. Los salones permitirán
diferenciar los juegos entre sí, siendo un salón lugar para jugar a un juego concreto. También
9
El Juego del Mus
podrían existir muchos otros planteamientos para estos salones, como niveles de dificultad,
idioma, etc.
Cuando el usuario entra en un salón, podrá usar un chat dirigido a los usuarios del
salón, una lista de usuarios conectados y sendas listas de partidas creándose y jugándose.
Estos dos tipos de partidas se deberán diferenciar de alguna forma visual. Podrá entrar en
cualquiera de los dos tipos de partidas: si estuviera creada y jugándose, entrará como
espectador y podrá usar un chat común de la partida, pero no verá ninguna carta; si estuviera
creada pero no iniciada, entrará dentro de la configuración de la partida.
La configuración de la partida debe ser una interfaz que ayudase a los creadores de
partidas a configurar la partida deseada. En el caso del mus, mostrará un chat y cuatro huecos
para los jugadores, donde uno de ellos será el propio creador. Los usuarios que entren a la
partida aparecerán en orden dentro de esta interfaz: si sólo estuviera el creador dentro, siendo
éste el jugador número 1, el siguiente usuario en entrar pasará a ser por defecto el jugador
número 2. Cada usuario, incluyendo al creador, podrá decidir su rol: jugador 1, 2, 3, 4 o
espectador; ya que las partidas tendrán un máximo de huecos o slots para espectadores que
sólo deseen observar, y 4 para los jugadores. Estos slots son configurables por el creador,
pudiendo cerrarlos, abrirlos o establecer manualmente una máquina como jugador, eligiendo
entre dificultades fácil, media o difícil. En todos los casos, si en el slot en cuestión se ubicase
otro usuario, este sería expulsado.
Si un usuario está viendo una partida como espectador, tendrá la opción de volver al
salón en cualquier momento deseado. Si, en cambio, está jugando una partida y no es el
creador, tendrá la opción de salir al final de cada partida de mus. Si fuese el creador, además
de esto, tendrá la opción de guardar la partida y pausarla, además de poder finalizarla al final
de cada partida.
Al salir de una partida, el usuario debe volver a visualizar la ventana del salón en el que
se encontraba antes de entrar en dicha partida.
4.1.5.2 Programa servidor

Debe existir un sistema que permita autentificar a los usuarios que deseen acceder al
juego, usando la información que éstos previamente introduzcan al realizar su registro.
Además, estos usuarios deben poder establecer una comunicación entre ellos para poder
chatear y jugar partidas: cuando un usuario envía un mensaje al chat, todos los que estuvieran
en ese momento visualizándolo deberían ver el nuevo mensaje en sus pantallas; de la misma
forma, si en una partida un jugador envidase, todos los demás tendrían que ser informados, al
igual que con el resto de acciones del juego. Estas tareas son básicamente servicios prestados
a los usuarios, donde el ente que los presta es conocido como servidor.
Las funciones de este servidor serán las siguientes:
Autentificar a los usuarios y darles permiso para acceder al sistema.
10
El Juego del Mus
Registrar todos los datos referentes a los usuarios y al sistema: salones, partidas
guardadas, etc.
Prestar los servicios de chat y de juego a los usuarios.
Además, gracias a esta centralización, el servidor poseerá una visión global del sistema
la cual le capacitará para ejercer un control completo sobre él.
4.1.5.3 Protocolo comunicación cliente-servidor

Es necesario definir un idioma común para el cliente y el servidor el cual permita una
buena y eficiente comunicación entre ambos. Este idioma debe ser comprendido e
interpretado tanto por los clientes como por el servidor. Esta comunicación es vital para el
buen funcionamiento del sistema, ya que en ella se basa la gran parte de él. Hablaremos sobre
este protocolo en 4.2.2.3 Protocolo comunicación Cliente-Servidor.
4.1.6 Inteligencia artificial

Para hacer posible que el programa juegue al mus de una forma autónoma e
inteligente de modo que se asemeje lo más posible a un jugador de carne y hueso, se usara la
inteligencia artificial.
La inteligencia artificial es un agente que se ocupara de percibir las entradas de su

entorno, procesar esa información y actuar consecuentemente mediante esa información.
En este caso la inteligencia artificial deberá recibir las entradas de la partida de mus,
tales como las cartas, el tanteo... procesar esa información y proporcionar la mejor jugada
según sus criterios.
4.1.7 Esquema conceptual

Como podemos observar en la imagen, nuestra aplicación se divide en salones, los
cuales serán de diferente dificultad. Cada salón tendrá un servidor en el que estarán los datos
de todos los usuarios y nuestras maquinas con nuestra IA.
Los usuarios podrán conectarse a estos servidores y podrán utilizar la aplicación para
chatear en el salón, jugar una partida contra la maquina o jugar y chatear en una partida con
otros jugadores
11
El Juego del Mus
Ilustración 1, esquema conceptual que refleja las funcionalidades principales del sistema de juego.
4.2 Análisis Técnico

Pasaremos a describir las herramientas y tecnologías que harán posible el desarrollo
de cada componente del sistema.
4.2.1 Base de datos

Es necesario escoger un producto DBMS2 para la implementación de la base de datos.
Existen varias opciones para, tanto gratuitas como de pago. Algunas de estas opciones son
Oracle, PostgreSQL, MySQL, SQLite, Sybase, y un largo etcétera. Hemos realizado una concisa
comparación entre dos de estos sistemas DBMS gratuitos: MySQL y PostgreSQL (3).
2
Data Base Management System, sistema de gestión de bases de datos.
12
El Juego del Mus
Característica MySQL PostgreSQL
Pobre
Portabilidad Completa
Windows 9x no soportado
Más lenta
Velocidad Muy rápida
Fork por conexión
Estabilidad Muy estable Menos estable
Media
Seguridad Media
Sensible a ataques DoS3
Otros Apropiada para DBs sencillas Perfecta para DBs complejas

Tabla 1, tabla comparativa entre MySQL y PostgreSQL.
Basándonos en la Tabla 1, nos hemos decantado por la utilización de MySQL. Esto se

debe a que en nuestro sistema, manejaremos una base de datos sencilla que no precisa de
todas las funcionalidades que daría PostgreSQL; DBMS más orientada a bases de datos
complejas (4). Además, MySQL es más rápido, más seguro y más estable que PostgreSQL.
4.2.2 Software
En esta sección, razonaremos la tecnología a usar para la creación de los programas
cliente y servidor, basándonos en la descripción conceptual previa de nuestro sistema. Además,
explicaremos el funcionamiento de cada uno de los programas.
4.2.2.1 Cliente
Definiremos la tecnología a emplear para la implementación del cliente, además de de
definir de una forma más técnica su funcionamiento general.
4.2.2.1.1 Tecnología
Nos hemos planteado la utilización tanto de Java o de C para la implementación del
programa cliente. En base a un análisis comparativo entre estos dos lenguajes, nos hemos
decantado por Java (Anexos: Comparación entre Java y C).
Las razones de esta decisión son claras. Mientras que C ofrece una mejora en la
velocidad inapreciable para el usuario al cual está dirigido este programa, Java disminuiría el
tiempo de desarrollo, y por lo tanto, los costes del proyecto en un ámbito comercial. Además,
programando en java, conseguimos un código que es portable, ya que este código se va a
ejecutar a través de la maquina virtual que ofrece este lenguaje y así no depende del Sistema
Operativo que tenga la ordenador del cliente.
3
Denial of Service, ataque que se basa en inhabilitar uno o varios servicios de una máquina. En
PostgreSQL, si un usuario puede conectarse a la base de datos, este puede ejecutar CREATE TABLE
debido a una vulnerabilidad del sistema, permitiendo perpetrar ataques DoS.
13
El Juego del Mus
El único punto negativo de Java respecto a C o C++, es la velocidad. En el cliente este

atributo carece de importancia, ya que muchas veces la aplicación tendrá que esperar al
usuario, como por ejemplo para hacer una jugada.
Otro punto positivo de Java respecto a C, es la facilidad para crear un entorno grafico,
muy interesante para la aplicación cliente.
4.2.2.1.2 Funcionamiento general

Describiremos el funcionamiento de este programa desde un punto de vista técnico,
centrándonos en la identificación de la concurrencia.
El cliente, al inicializarse, creará dos sockets4 para comunicarse con el servidor, uno
para un hilo asistente que escuchar al usuario y otro para un hilo refrescador que actualiza la
información de la pantalla. Es decir, el primero enviará las peticiones del usuario al servidor y
escuchará las respuestas que le envíe este servidor y el último se encargará de refrescar la
pantalla con la información que pida y posteriormente reciba desde el servidor. Esto permite
que el programa no deba esperar peticiones del usuario para mostrar información de
importancia enviada por el servidor.
Como se explicó en la sección 4.1.5.1 Programa cliente, primeramente, se le

preguntará al usuario su nombre y contraseña. Cuando el usuario haya sido autentificado, se
pasará a la fase de selección de salón. Una vez el usuario haya entrado en un salón, el usuario
puede unirse a una partida ya creada o crear una nueva partida. Si se eligiera la primera opción,
este usuario pasaría a convertirse en espectador de la partida. Si se escogiera la segunda, se
pasará a la fase de configuración de la partida, para después iniciar el proceso de juego del
mus.
En todos los casos, los chats serán totalmente independientes, es decir, ellos mismos
crearán dos hilos (receptor y emisor) que se encargarán de enviar los mensajes del usuario y
recibir los mensajes de otros usuarios. Estos chats se basarán en IP multicast5 y sockets UDP6.
Realizamos esta separación para aprovechar la tecnología IP multicast, la cual se identifica y
simplifica el funcionamiento del chat. Usamos UDP por su velocidad y ligereza frente a TCP, ya
que en el caso del chat el orden de los paquetes no es relevante.
El hilo asistente y el hilo refrescador del cliente, en cambio, modificarán su rol en el

sistema según sea necesario. Esto es, el hilo asesor en un primer momento cumplirá las
funciones de portero; después será mayordomo al servicio del usuario que atenderá al mismo,
para pasar a ser un representante del jugador en la partida. Por otra parte, el hilo refrescador
4
Un socket es un punto de entrada y salida de datos desde un proceso hacia otro proceso. En el caso de
los sockets de red, esta comunicación se realiza vía Internet.
5
Método de direccionamiento de red para el envío de información a todo un grupo de usuarios de
forma simultánea.
6
User Datagram Protocol, protocolo para la comunicación en Internet rápido y ligero. Éste no asegura
que los datos lleguen a su destino, ni tampoco que lleguen en el mismo orden de envío.
14
El Juego del Mus
informará a este sobre los cambios en los datos. En este último caso, el hilo refrescador deberá
actualizar con cierta regularidad la información sobre los salones, las partidas disponibles, la
información de configuración de las partidas o los espectadores de una partida en juego.
4.2.2.2 Servidor
En este apartado, al igual que en la sección dedicada al cliente, estudiaremos la
tecnología a emplear para la implementación del servidor y definiremos de una forma más
técnica el funcionamiento general de este programa.
4.2.2.2.1 Tecnología
Analizaremos los lenguajes de programación Java y C para poder llevar a cabo la
elección del lenguaje de programación a emplear para la implementación del servidor (Anexos:
Comparación entre Java y C).
Basándonos en estos datos, podemos decir que C es un gran lenguaje a tener en

cuenta si lo que queremos es velocidad y precisión en cálculos lógicos y matemáticos; ya que,
en este aspecto, es sustancialmente más rápido que Java. Pero en servidores que tengan que
comunicarse y relacionarse con diferentes componentes, aun obteniendo un mejor resultado
que Java, la diferencia sería tan mínima que el usuario no sería capaz de apreciarla. Esto hace
sopesar esta pequeña mejora de rendimiento con todas las ventajas que da Java a la hora del
diseño, la programación y el mantenimiento de los programas, las cuales implican una
reducción de costes y tiempo de desarrollo sustancial respecto a C.
Por esta razón se ha elegido emplear Java para el desarrollo del servidor. Ofrece
mejores resultados que C salvo en la velocidad. Hay que señalar que esto no sería un problema
para la aplicación proyectada, ya que no es necesaria una gran velocidad: no es importante ser
veloz, sino no ser lento.
4.2.2.2.2 Funcionamiento general

Al iniciar el programa, el servidor creará una lista de salones utilizando información de
la base de datos. Como se explicó anteriormente, cada salón contendrá un chat, una lista de
usuarios conectados y una lista de partidas en creación y en juego.
El proceso principal del servidor se encargará de aceptar a los usuarios que deseen
conectarse. Al aceptar a cada usuario, el servidor creará un objeto que le represente, el cual
lanzará dos hilos: asistente y refrescador. El primero se encargará de escuchar y atender las
peticiones del usuario en cuestión y el segundo enviará información de refresco a petición del
mismo. Para esto son necesarios dos sockets por cada cliente.
En el lado del servidor, no hace falta ningún tipo de conexión ni concurrencia para los
chats; lo único que hay que hacer es especificar la dirección IP Multicast y el puerto de cada
chat para enviar estos datos a los usuarios que deseen conectarse a ellos.
15
El Juego del Mus
4.2.2.3 Protocolo comunicación Cliente-Servidor

Iniciando el protocolo el cliente mandara un paquete de identificación. El asistente
comprobará los datos en la BD, y devolverá un paquete de respuesta. Después de esto el
mayordomo le mandará la lista de salones en un paquete llamado listaSalones.
El mayordomo se convertirá en el servidor personal de cada cliente, subdividiéndose

en 2 hilos, uno para escuchar peticiones y otro para mandar la información de refresco (cada x
segundos mandará la nueva lista de usuarios… etc). El mayordomo esperará a que el cliente
seleccione un salón, cuando llegue el momento el cliente mandará un paquete entrarEnSalon.
El servidor devolverá un paquete de respuesta, y si esta fuera positiva también devolverá un
paquete infoSalón. El mayordomo pasara a instanciarse en el salón correspondiente y se
añadirá a la lista de usuarios.
El mayordomo esperará a que el cliente le diga en que partida quiere entrar o si quiere
crear una partida. En el primer caso, el mayordomo enviará un paquete entrarAPartida, en el
segundo, un paquete crearPartida. En ambos casos el servidor devolverá un paquete de
Repuesta (positiva o negativa). Si hubiera pedido entrar en una partida, el servidor enviará
después En el constructor de partida, se creará un chat, se añadirá al creador como tal y se le
mandará al salón la partida. Los dos hilos de mayordomo pasarán de refrescar e interactuar
con el salón a hacerlo con la partida de tal modo, que el mayordomo escuchara y mandará
todos los datos de la partida al cliente y el hilo de refresco refrescará la partida. Si la partida
estuviese ya creará (y en modo configuración) el mayordomo llamaría al salón y le pediría
permiso para entrar en la partida, y este a su vez al mayordomo creador correspondiente.
Si el cliente quisiese entrar como espectador, lo podría hacer en cualquier momento,

tanto en el de configuración como en la partida en si.
Para añadir una maquina en la partida el cliente deberá mandar el nombre de la

maquina en forma de string a su mayordomo (esto solo lo podrá hacer el creador de la partida),
el mayordomo responderá “0” o “-1”.
El creador podrá empezar la partida cuando haya mínimo entre maquinas y clientes 4
jugadores. Al empezar la partida el hilo de refresco también cambiará para poder refrescar la
partida.
Durante la partida, se seguirá un orden, contrario a las agujas del reloj, en el que la
maquina irá preguntando uno por uno a cada jugador su jugada dependiendo de la ronda. El
asistente se encargará de preguntar al cliente la jugada correspondiente, y escuchar su
respuesta para luego mandar la información a partida.
El creador de la partida podrá guardar, guardando en la BD los datos de la partida, o

salir dando la partida por terminada. Los clientes podrán salirse en cualquier momento de la
partida volviendo al salón y dando la partida por terminada. Desde el salón se podrá salir al
16
El Juego del Mus
menú de salones, o salón principal. Desde cualquier punto de la aplicación se podrá salir,
destruyendo los hilos del mayordomo.
4.2.3 Agente inteligente

La lógica de un agente inteligente que sea capaz de jugar al mus se identifica con el
concepto de sistemas expertos. La razón principal es que el mus es un juego muy variable, sin
jugadas que necesariamente lleven a ganar una partida ni jugadas que lleven a perderlo. Por
esta razón, no hay cabida para ninguna función heurística que defina las jugadas a llevar a cabo
en el juego.
4.2.3.1 Sistemas expertos

Un sistema experto se compone habitualmente de una base de conocimiento, donde
se encontrará la información y reglas del sistema, y una Shell. Esta última se compone de un
motor de inferencia, el cual ejecuta y dispara las reglas necesarias para generar respuestas, y
de una interfaz de usuario para la interacción del sistema con los usuarios. Esta última parte no
es necesaria en nuestro sistema, ya que no queremos que los usuarios puedan interferir en el
razonamiento del agente.
4.2.3.2 Lógica difusa y directa

Para recrear la forma de pensar de un experto jugador de mus, la lógica difusa podría
ser de gran ayuda. Esta lógica ayudaría a dar una especie de aleatoriedad al agente, una visión
más difusa para una forma de jugar que no tiene que por qué ser guiada por una lógica directa.
A decir verdad, ningún jugador de mus hace uso de lógica directa para deducir sus jugadas. Por
ejemplo, no se puede llegar a decir que siempre que la pareja contraria envide a grande y la
máquina tenga dos reyes, esta deba de ver la apuesta. Es por esta razón que la lógica difusa, al
establecer continuidad entre lo falso y lo verdadero, serviría para implementar un agente
inteligente más realista. A pesar de esto, se ha decido emplear la lógica directa debido a los
objetivos mínimos y plazo del proyecto (5) (6).
4.2.3.3 Tecnología para la implementación

Se ha realizado un análisis comparativo entre varias herramientas que facilitan la
implementación de un sistema experto en Java. Este análisis se encuentra en (Anexos:
Herramientas para la implementación de un SE en Java)
Por la mayor identificación con el sistema a desarrollar, elegimos JESS como recurso
principal para el desarrollo del agente. Con JESS tan sólo debemos implementar la base de
conocimiento que contenga las reglas y hechos relacionados con el juego del mus. Para
conseguir JESS, fue necesario realizar una petición de licencia académica gratuita, la cual
implica el cumplimiento de las normas en ella descritas (Anexos: Licencia JESS).
4.2.4 Esquema general

El servidor estará conectado a nuestros clientes en una red local, gracias a la cual los
clientes compartirán información con el mismo (Ilustración 2). Será el servidor el que alojará la
17
El Juego del Mus
base de datos del sistema, la cual contendrá información como los registros de los usuarios y
partidas guardadas.
Ilustración 2, arquitectura cliente-servidor del sistema.
5 Planificación
En esta sección se presentan una planificación general de las diferentes tareas a realizar
para llegar a la culminación del proyecto, una descripción más concreta de la fase de
implementación, la forma de dividir el trabajo entre los miembros del equipo y las diferentes
herramientas que nos permitirán trabajar más dinámicamente.
5.1 Planificación general

En el siguiente diagrama de Gantt pueden apreciarse las diferentes tareas en las que se
ha dividido el desarrollo del proyecto. Teniendo como referencia este diagrama, es posible
prever una eventual falta de tiempo para llevar a cabo alguna de las fases.
18
El Juego del Mus
Ilustración 3, diagrama de Gantt donde se muestras las diferentes tareas e hitos del proyecto.
Es importante que la planificación diseñada permita verificar de forma continuada el

buen funcionamiento de cada parte desarrollada. Es por ello que se han diferenciado estas
partes en módulos que puedan ser testados por separado de la forma más sencilla posible.
Gracias a esto, en la fase de ensamblaje de componentes para formar el sistema en su
totalidad, se acotan las ubicaciones y razones de los errores que puedan aparecer.
Como se puede ver en la Ilustración 2, se distinguen diferentes partes a implementar:

base de datos, sockets, chat, cliente, servidor y agente IA. Se desarrollarán primero los
19
El Juego del Mus
módulos que permiten funcionar al resto, es decir, la base de datos y los sockets. Estos
módulos se ubican dentro de una capa de datos, en el centro del sistema. Comienza en ese
momento el desarrollo de un chat, componente muy usado en el programa, para seguir con la
implementación del cliente y del servidor en paralelo. Por último, se desarrollará el agente
inteligente.
Como se puede apreciar en el diagrama, se deben acometer primero las tareas de

aprendizaje sobre la librería JESS y sockets en Java. Son componentes imprescindibles en el
sistema, ya que JESS será el motor de la inteligencia artificial y los sockets la herramienta para
establecer comunicación entre nuestro servidor y los clientes.
5.2 División del trabajo

Es importante planificar una buena división del trabajo, la cual permita cumplir con los
plazos del proyecto y, lo más importante, que cada miembro del equipo alcance los objetivos
de aprendizaje establecidos.
Por esta razón, todos y cada uno de los miembros participarán en cada fase del
proyecto. En la fase de implementación, gracias a la orientación a objeto, Assembla y
Subclipse, se podrá trabajar de forma conjunta y de la manera más eficiente posible (Anexos:
Assembla, Subclipse).
6 Desarrollo
Se explicará el proceso de desarrollo que llevó al resultado final del proyecto. Desde la
modelización hasta los resultados finales, pasando por la implementación.
6.1 Modelización
Pasaremos a presentar los modelos creados para el diseño de las diferentes partes del
sistema: base de datos, programa cliente y programa servidor. Estos modelos han sido
realizados mediante el uso de diferentes programas y siguiendo normas como, por ejemplo,
UML.
6.1.1 Base de Datos

Usando diagramas relacionales, diseñamos en primer lugar la base de datos del
sistema. Las tablas creadas permiten mantener un registro de usuarios del sistema, además de
guardar partidas jugadas por los usuarios. También guarda un registro de salones y del juego al
que puede jugarse en cada uno. El diagrama relacional puede encontrarse en (Anexos: Diseño
de la base de datos).
Para la creación del diagrama se usó MySQL Workbench (Anexos: MySQL Workbench).
20
El Juego del Mus
6.1.2 Software
6.1.2.1 Recogida de requisitos

La primera fase de desarrollo del software consiste en recopilar los requisitos
funcionales del sistema. Debemos saber exactamente qué debe ofrecer nuestro sistema para
poder comenzar con el desarrollo. Toda esta información está descrita en la sección 3
Objetivos del proyecto.
A continuación podemos observar dos diagramas de clases diferentes, los cuales

corresponden al diagrama de dominio del servidor (Ilustración 4) y del cliente (Ilustración 5).
Ilustración 4, diagrama de dominio del programa servidor.
21
El Juego del Mus
Ilustración 5, diagrama de dominio del programa cliente.
Estos dos diagramas ayudan a identificar el problema, adquirir una primera idea de la
forma del sistema.
Tras esto, pasamos a crear un diagrama de casos de uso, el cual ilustra de manera
sencilla las distintas funcionalidades que ofrecerá el sistema a los usuarios potenciales del
mismo.
22
El Juego del Mus
Ilustración 6, diagrama de casos de uso del sistema.
Este diagrama es de gran utilidad para la comunicación entre el equipo que desarrolla
el proyecto y el cliente.
Para ciertas funcionalidades, debido a su importancia en el sistema, es necesario

especificar algunas características: objetivo, flujo de eventos, prerrequisitos, etc. Hemos
descrito cuatro casos de uso diferentes, considerados de gran importancia en nuestro
proyecto: jugar una partida, crear una partida, ver una partida y guardar una partida. Estas
descripciones pueden encontrarse en (Anexos: Descripción de casos de uso).
6.1.2.2 Análisis
-Diagrama de clases del servidor y del cliente
-Diagramas de secuencia que expliquen el proceso de entrar a un salón, crear una

partida y jugarla.
6.1.3 Agente inteligente

-definir reglas para jugar al mus
-definir como se implementaran
23
El Juego del Mus
6.2 Implementación
7 Resultados
8 Líneas de expansión
24
El Juego del Mus
9 Anexos
9.1 Objetivos de aprendizaje
9.2 Comparación entre Java y C

Para la programación del servidor y del cliente disponemos de diferentes opciones
respecto al lenguaje de programación a emplear, como por ejemplo C y Java.
Es difícil decantarse por una de ellas, por lo cual se realizará un pequeño análisis sobre
las diferentes ventajas y desventajas que tenga cada lenguaje en diversas áreas (7).
9.2.1.1 Lenguaje
C fue creado como un lenguaje de programación muy expresivo y potencialmente muy
económico, dado a lo reducido de su sintaxis para programas pequeños y medianos. Pero a la
hora de crear programas complejos con miles de líneas de código, la labor de programar puede
tornarse muy oscura, en gran parte debido a los punteros y a su aritmética.
Por su parte, Java aporta diferentes herramientas que facilitan la labor del
programador. A continuación, citaremos algunas de las muchas que ofrece: la sobrecarga de
operadores dota al lenguaje de una gran expresividad; las excepciones permiten procesar de
un modo claro los errores; la sintaxis de clases y objetos permite manipular convenientemente
diversas estructuras de datos y operaciones, y además evita el uso de punteros sin que esto
merme su expresividad, gracias en parte al recolector de basura, la cual se encarga de liberar
de la memoria datos no referenciados.
9.2.1.2 Desarrollo
El desarrollo de programas en C puede tornarse complicado debido a su sintaxis. Es
cierto que el uso de punteros le da una gran versatilidad, pero, a la vez, ocasionan la
proliferación de errores en programas de grandes dimensiones.
En cambio, java tiene ciertas características como la encapsulación, la herencia, la

herencia múltiple por medio de interfaces, el gestor de excepciones, etc. las cuales facilitan
que el desarrollo del programa sea mucho más intuitivo, menos propenso a los errores y que
además le dan al producto una gran versatilidad a la hora de futuros cambios.
9.2.1.3 Seguridad
Como ya se ha comentado anteriormente, el uso de punteros en C le da una gran
versatilidad y potencia al lenguaje, pero muchas veces a costa de la seguridad del programa.
Por ello java elimina los punteros, sin que esto afecte a la expresividad y encima añade la
encapsulación, la cual confiere una gran robustez al código.
25
El Juego del Mus
9.2.1.4 Velocidad/Eficiencia
Es bien sabido que las CPU7 sólo comprenden el llamado lenguaje máquina. Por lo
tanto, todos los lenguajes de programación deben ser traducidos en algún momento a
lenguaje máquina para que los programas sean ejecutados. En este punto C posee estructuras
de datos muy simples que generalmente suelen tener una traducción muy sencilla al lenguaje
máquina. Esta sencillez otorga al lenguaje C una excelente eficiencia.
En cambio, Java fue creado desde un principio para ser ejecutado en cualquier clase de
dispositivo o CPU, es decir, sin que importase la arquitectura de la máquina en cuestión. Esto
lo consigue gracias a que no se compila directamente en el lenguaje máquina del CPU en uso,
sino en un pseudolenguaje máquina denominado byte code. Debido a esto, se precisa de un
programa especial que se encargue de la traducción del byte code al lenguaje máquina. Este
programa es conocido como JVM8, y es por ello que al código de Java se le conoce como
código interpretado.
Todo esto conlleva que un programa compilado en byte code debe ser además
traducido a lenguaje máquina. En general, esto resulta más lento que un programa ya
traducido al lenguaje máquina del CPU, aunque con cada versión de Java se acorta cada vez
más esta diferencia.
En diversas pruebas de cálculo puro en los que se suele plantear el argumento de la

importancia de la velocidad de ejecución del lenguaje en sí, Java suele salir perdiendo en
comparación con C. Pero también es cierto que muchas veces la lentitud de los programas no
es debida a la falta de eficiencia del código principal, sino de componentes auxiliares tales
como bases de datos, librerías de terceros, dispositivos gráficos acelerados, etc. En esta línea,
algunos defensores de Java manifiestan que es poco relevante que el código C/C++ sea 10 o
50% más veloz, si al final este tiempo no es el verdaderamente percibido por el usuario.
Asimismo, la aparentemente reducida performance de Java en comparación a C y C++ podría
ser frecuentemente superada gracias básicamente a la claridad del lenguaje, ya que esta
característica permitiría implementar mejores algoritmos y de un modo mucho más eficiente.
En definitiva, Java suele ser notoriamente más lento si la tarea principal consiste en
operaciones lógico-matemáticas, mientras que la eficiencia suele ser pareja a la de C para
aplicaciones que hacen uso de muchos componentes y librerías diferentes.
9.2.1.5 Portabilidad
C presenta importantes deficiencias en el tema de la portabilidad. Es cierto que al
tener características que dependen de la implementación permite una gran optimización del
programa en términos de eficiencia; pero esto mismo supone una gran pesadilla para
conseguir cierto grado de portabilidad.
7
Central Processing Unit
8
Java Virtual Machine
26
El Juego del Mus
Java, por otro lado, al ser diseñado como un lenguaje que no depende del entorno en
el que será ejecutado, si bien esto le resta eficiencia, basta con escribir una vez el código para
poder ejecutarlo en cualquier dispositivo o sistema operativo que tenga instalada JVM.
9.2.1.6 Tabla comparativa

Podemos ver compactados los detalles de cada lenguaje de programación antes
descritos en la siguiente tabla.
Característica C Java
Expresividad Regular Muy Buena
Tiempo de Desarrollo Deficiente Muy Buena
Eficiencia Excelente Buena
Seguridad Buena Muy Buena
Portabilidad Buena Excelente
Tabla 2, comparación entre las diferentes características de los lenguajes C y Java.
9.3 Herramientas para la implementación de un SE en Java

Para construir un sistema experto en Java, hemos analizado diferentes herramientas y
librerías que podrían facilitarnos esta labor. Describiremos cada una de ellas a continuación.
JIProlog9 es un intérprete de de Prolog el cual integra Java y Prolog de forma sencilla.

Este intérprete permite llamadas a código Prolog desde código Java y viceversa sin tener que
tratar con código nativo ni JNI10.
Por otro lado, Prolog Café es un traductor de código de Prolog a Java y viceversa.
Transforma el código usando una WAN11, para entonces compilarlo con un compilador de Java
corriente.
Por último, encontramos JESS 12 , una librería de Java que implementa una Shell
genérica para el desarrollo de sistemas expertos. El motor de inferencia que ofrece se basa en
9
Java Internet Prolog.
10
Java Native Interface, framework de Java que permite que un programa escrito en Java interactúe con
otro escrito en un lenguaje diferente.
11
Warren Abstract Machine, máquina abstracta que ejecuta código escrito en Prolog.
12
Java Expert System Shell.
27
El Juego del Mus
una versión mejorada del algoritmo de Rete. Además, da la posibilidad de usar un lenguaje de
scripting que permite el uso de todas las API13 de Java. Dispone además de un entorno de
desarrollo basado en Eclipse.
Característica JESS JIProlog Prolog Cafe
Soporte lenguaje JESS Scripting

Prolog Prolog
lógico language
Motor de Inferencia Sí No No
Integración con
Sí No No
Eclipse
A través de
Integración con JAVA Sí Sí
traducción
Tabla 3, comparación entre herramientas para la implementación de un Sistema Experto en Java.
9.4 Diseño de la base de datos
Ilustración 7, diagrama relacional de la base de datos del sistema.
13
Application Programming Interface, conjunto de funciones y procedimientos que ofrece cierta
biblioteca para ser utilizado por otro software como una capa de abstracción.
28
El Juego del Mus
9.5 Descripción de casos de uso

9.5.1 Jugar una partida
Objetivo: El usuario podrá jugar al mus siguiendo las reglas habituales para este juego de mesa.
Prerrequisitos: El usuario tendrá que estar en un salón.
Flujo de eventos:
1. Cortar o dar mus.

2. Jugar a grande.
3. Jugar a pequeña.
4. Si se tienen pares, jugar a pares.
5. Si se tiene juego, jugar a juego.
Otros flujos de eventos:
Si no se tienen pares, no jugar pares.
Si nadie tiene juego, jugar a punto.
Pos requisitos: Tras haber jugado, tendrá la opción de salir de la partida.
Diagrama de actividades:
Ilustración 8, diagrama de actividades del caso de uso Jugar una partida.
29
El Juego del Mus
9.5.2 Crear una partida

Objetivo: Crear una partida que no exista para así poder jugar una partida.
Prerrequisitos: El usuario debe estar logeado y estar dentro de un salón concreto.
Flujo de eventos:
1. El usuario seleccionará la opción de crear una partida dentro de un salón.

2. El usuario seleccionará diferentes opciones de la partida, tales como reglas, número de
juegos, etc. Así mismo, el usuario podrá seleccionar si el resto de jugadores serán
agentes u otros clientes.
3. En caso de haber seleccionado uno o más clientes, el usuario deberá esperar a que
estos se conecten a su partida.
4. Una vez estén completos todos los jugadores, ya sean agentes o clientes, el usuario
podrá seleccionar la opción de comenzar partida.
5. Al seleccionar comenzar partida, si se han seleccionado uno o más agentes, el servidor
los creará.
Pos requisitos: El usuario puede jugar una partida configurada a lo largo del proceso de
creación.
Ilustración 9, diagrama de actividades del caso de uso Crear una partida.
30
El Juego del Mus
9.5.3 Ver una partida

Objetivo: Ver una partida ya creada.
Prerrequisitos: El usuario debe estar logeado.
Flujo de eventos:
1. El usuario elige un salón.

2. Mostrar la lista de partidas.
3. El usuario elige una partida de la lista.
4. Mostrar la partida.
Pos requisitos: El usuario puede ver el desarrollo de una partida, pudiendo además participar
en el chat de la misma, pero sin poder ver las cartas de los jugadores.
Ilustración 10, diagrama de actividades del caso de uso Ver una partida.
31
El Juego del Mus
9.5.4 Guardar una partida

Objetivo: Guardar una partida en curso.
Prerrequisitos: El usuario debe estar jugando una partida.
Flujo de eventos:
1. Esperar al final de un juego.

2. Dar la opción de salir y guardar al creador de la partida.
3. Esperar a que el creador de la partida pulse la opción de salir y guardar.
4. Recopilar la información de la partida y guardarla en la base de datos.
5. Devolver a todos los jugadores al salón que estaban anteriormente.
Pos requisitos: Debe quedar almacenada en la base de datos del sistema la información
relacionada con la partida, para que posteriormente pueda ser cargada y ejecutada en las
mismas condiciones que se guardaron.
Ilustración 11, diagrama de actividades del caso de uso Guardar una partida.
32
El Juego del Mus
9.6 Protocolo comunicación Cliente-Servidor

En esta sección describiremos con precisión la estructura de los paquetes usados para la
comunicación entre los clientes y el servidor. Este protocolo es el lenguaje que utilizarán
ambas partes para comunicarse o hablar entre sí.
9.6.1 Paquetes Cliente->Servidor

Los paquetes enviados por el cliente al servidor se diferencian en dos grupos: paquetes
enviados por el hilo asistente y paquetes enviados por el hilo refrescador.
9.6.1.1 Paquetes hilo asistente

Estos paquetes se identifican con peticiones que realiza el usuario al servidor, aunque
también pueden encontrarse paquetes relacionados con el propio juego. Serán recibidos por el
hilo asistente homólogo del servidor.
9.6.1.1.1 Fase pre-juego
Bloque Bloque fin

Bloque información
inicial
Nombre Separador Password
Nombre
$p01 #
String % String
PIdentificación
Ilustración 12, paquete de petición de identificación de usuario.
Bloque Bloque fin

Bloque información
inicial
idSalon
Nombre
$p02 #
int
PEntrarASalon
Ilustración 13, paquete de petición de entrada en un salón.
9.6.1.1.2 Fase de acceso a partida
Bloque Bloque fin

Bloque información
inicial
idPartida
Nombre
$p03 #
int
PEntrarAPartida
Ilustración 14, paquete de petición de entrada en una partida.
Bloque Bloque fin

Bloque información
inicial
NombrePartida
Nombre
$p04 #
String
PCrearPartida
Ilustración 15, paquete de petición de creación de una nueva partida.
33
El Juego del Mus
9.6.1.1.3 Fase de configuración de partida
Bloque Bloque fin

Bloque información
inicial
Posición Separador Nivel
Nombre
$p05 #
int % int
PAñadirMaquina
Ilustración 16, paquete de petición de adición de una máquina de cierto nivel a una partida.
Bloque Bloque fin

Bloque información
inicial
Slot
Nombre
$p06 #
int
PAbrirSlot
Ilustración 17, paquete de petición de apertura de slot.
Bloque Bloque fin

Bloque información
inicial
Slot
Nombre
$p07 #
int
PCerrarSlot
Ilustración 18, paquete de petición de cierre de slot.
Bloque Bloque fin

Bloque información
inicial
Slot
Nombre
$p08 #
int
PCambiarSlot
Ilustración 19, paquete de petición de cambio de slot.
Bloque Bloque fin

Bloque información
inicial
Opcion
Nombre
$p11 #
boolean
PConfEspectador
Ilustración 20, paquete de configuración de opción espectadores.
Bloque fin
Bloque inicial
Nombre
$p09 #
PIniciarPartida
Ilustración 21, paquete de petición de inicio de partida.
34
El Juego del Mus
9.6.1.1.4 Fase de juego
Bloque Bloque fin

Bloque información
inicial
Jugada Separador Apuesta
Nombre
$p10 Char #
% int
PJugada (m,c,a,o,p,q,n)
Ilustración 22, paquete de información de jugada.
9.6.1.2 Paquetes hilo refresco

Los siguientes paquetes son enviados por el hilo encargado del refresco del cliente.
Realizan peticiones de información de refresco al servidor en las diferentes fases en las que se
puede encontrar el cliente.
9.6.1.2.1 Fase de pre-juego
Bloque fin
Bloque inicial
Nombre
$pr01 #
PInfoSalones
Ilustración 23, paquete de petición de refresco de la información general de los salones.
Bloque Bloque fin

Bloque información
inicial
IdSalon
Nombre
$pr02 #
int
PInfoSalon
Ilustración 24, paquete de petición de refresco de la información de un salón concreto.
9.6.1.2.2 Fase de configuración de partida y de juego
Bloque Bloque fin

Bloque información
inicial
idPartida
Nombre
$pr03 #
int
PInfoPartida
Ilustración 25, paquete de petición de refresco de la información de una partida.
35
El Juego del Mus
9.6.2 Paquetes Servidor->Cliente
9.6.2.1 Paquetes hilo asistente
Bloque Bloque fin

Bloque información
inicial
Respuesta
Nombre
$rp01 #
boolean
PRespuesta
Ilustración 26, paquete de respuesta positiva o negativa enviada por el servidor al cliente.
9.6.2.2 Paquetes hilo refresco

A continuación se describen los paquetes que el hilo del servidor encargado de
refrescar a su cliente debe enviar para lograr tal fin.
9.6.2.2.1 Fase de pre-juego
Bloque
Bloque
Bloque información fin
inicial
Nombre Sep Sep

$rr01 infoSalon InfoSalon … #
RInfoSalones % %
Ilustración 27, paquete de respuesta con la información de refresco de la información general de los salones.
Bloque
Bloque
inicial
Sep
Nombre Info Sep Info Sep
$rr02 … Info … #
User Partida
RInfoSalon % / %
Ilustración 28, paquete de respuesta con la información de refresco de un salón concreto.
9.6.2.2.2 Fase de configuración de partida
Bloque
Bloque
inicial
Sep
Nombre Info Sep Start
$rr03 … Info #
Posicion
RInfoPartidaConf % / boolean
Ilustración 29, paquete de respuesta con la información de refresco de una partida en proceso de configuración.
9.6.2.2.3 Fase de juego
36
El Juego del Mus
Bloque
Bloque
inicial
Nombre Sep Sep

$rr04 infoUser InfoUser … #
RInfoPartidaJug % %
Ilustración 30, paquete de respuesta con la información de refresco de una partida en proceso de juego.
9.6.2.3 Sub-bloques de información de usuario y de partida

En ciertos paquetes enviados por el servidor a sus clientes aparece información
compuesta de varias partes. En esta sección podemos ver una descripción de esos sub-bloques
de información.
Bloque información
Nombre id Sep Nombre Sep numUser

InfoSalon int % String % int
Ilustración 31, descripción del bloque con información general de un salón.
Bloque información
Nombre id Sep Nombre Sep Localidad Sep Pais

InfoUser int % String % String % String
Ilustración 32, descripción del bloque con la información de un usuario.
Bloque información
Nombre id Sep Nombre Sep Estado Sep NumJug

InfoPartida int % String % boolean % int
Ilustración 33, descripción del bloque con la información de una partida.
Bloque información
Nombre id Sep Nombre Sep Pos

InfoPosicion int % String % int
Ilustración 34, descripción del bloque con la información de una posición de la configuración de una partida.
37
El Juego del Mus
9.7 Software empleado

9.7.1 Eclipse
9.7.2 Assembla
9.7.3 Subclipse
9.7.4 MySQL Workbench
9.8 Licencia JESS
38
El Juego del Mus
10 Bibliografía
1. Wikipedia. Mus. [En línea] 21 de Octubre de 2008. [Citado el: 26 de Octubre de 2008.]
http://es.wikipedia.org/wiki/Mus.
2. Ocean Global Holding. Garena Help & FAQ. Garena. [En línea] [Citado el: 6 de November de
2008.] http://ww.garena.com.
3. Fermilab Computing Division. PostgreSQL versus MySQL. [En línea] Fermi National
Accelerator Laboratory, 15 de Febrero de 2005. [Citado el: 11 de Noviembre de 2008.]
http://www-css.fnal.gov/dsg/external/freeware/pgsql-vs-mysql.html.
4. Hunter, Shylon Ray. TechRepublic. MySQL vs PostgreSQL. [En línea] 1 de Julio de 2002.
[Citado el: 10 de Noviembre de 2008.] http://articles.techrepublic.com.com/5100-10878_11-
1050671.html.
5. William Siler, James J. Buckley. Fuzzy Expert Systems and Fuzzy Reasoning. s.l. : Wiley, 2005.
978-0-471-38859-3.
6. School of Computer Science, Carnegie Mellon University. FAQ: Fuzzy Logic and Fuzzy Expert
Systems. [En línea] [Citado el: 28 de Octubre de 2008.]
http://www.cs.cmu.edu/Groups/AI/html/faqs/ai/fuzzy/part1/faq.html.
7. America TI. Ventajas y Desventajas: Comparación de los lenguajes C, C++ y Java. [En línea]
11 de Noviembre de 2006. [Citado el: 3 de Noviembre de 2008.]
http://www.americati.com/doc/ventajas_c/ventajas_c.html#id2488972.
39

Planteamiento14 11 08

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Planteamiento14 11 08

Cargado por

Copyright:

Formatos disponibles

El Juego del Mus

Proyecto de desarrollo de un mus interactivo

3 OBJETIVOS DEL PROYECTO .................................................................................................................. 4

3.1 MÍNIMOS ....................................................................................................................................... 4

4.1 ANÁLISIS CONCEPTUAL...................................................................................................................... 5

5.1 PLANIFICACIÓN GENERAL ................................................................................................................. 18

6.1 MODELIZACIÓN ............................................................................................................................. 20

8 LÍNEAS DE EXPANSIÓN ...................................................................................................................... 24

9.1 OBJETIVOS DE APRENDIZAJE ............................................................................................................. 25

9.5.3 Ver una partida ..................................................................................................................... 31

El equipo de proyecto ha escogido desarrollar un sistema de juego online que permita

3 Objetivos del proyecto

Los usuarios no registrados podrán:

Registrarse en el sistema desde una interfaz web.

Los usuarios registrados podrán:

Chatear con el resto de jugadores conectados al sistema de juego.

4.1 Análisis Conceptual

4.1.1 El juego del Mus

Una partida de mus se divide en vacas y estas en juegos. La pareja ganadora de la

4.1.1.1 Fase inicial

Si no estuviéramos en la primera mano de un juego, el jugador sentado a la derecha

Si un jugador apostase, la otra pareja tiene la opción de pasar, querer o subir la

4.1.1.3 Puntuación de las cartas

Existen puntos de tanteo en los pares y el juego. En el lance de pares, la pareja

Si alguna pareja llegase a 40 piedras al contabilizar estos puntos, gana el juego. Si

Pongamos dos ejemplos. Si en el lance a juego la mano suma 31 puntos y el jugador de

Es muy interesante, que un cierto de número de jugadores, puedan estar controlados

Una vez registrado, y habiéndose identificado previamente, pasará a poder realizar

También es interesante utilizar la base de datos para guardar estadísticas, o diferentes

4.1.5.1 Programa cliente

4.1.5.2 Programa servidor

Las funciones de este servidor serán las siguientes:

Autentificar a los usuarios y darles permiso para acceder al sistema.

4.1.5.3 Protocolo comunicación cliente-servidor

4.1.6 Inteligencia artificial

La inteligencia artificial es un agente que se ocupara de percibir las entradas de su

4.1.7 Esquema conceptual

4.2 Análisis Técnico

4.2.1 Base de datos

Característica MySQL PostgreSQL

Estabilidad Muy estable Menos estable

Otros Apropiada para DBs sencillas Perfecta para DBs complejas

Basándonos en la Tabla 1, nos hemos decantado por la utilización de MySQL. Esto se

El único punto negativo de Java respecto a C o C++, es la velocidad. En el cliente este

4.2.2.1.2 Funcionamiento general

Como se explicó en la sección 4.1.5.1 Programa cliente, primeramente, se le

El hilo asistente y el hilo refrescador del cliente, en cambio, modificarán su rol en el

Basándonos en estos datos, podemos decir que C es un gran lenguaje a tener en

4.2.2.2.2 Funcionamiento general

4.2.2.3 Protocolo comunicación Cliente-Servidor

El mayordomo se convertirá en el servidor personal de cada cliente, subdividiéndose

Si el cliente quisiese entrar como espectador, lo podría hacer en cualquier momento,

Para añadir una maquina en la partida el cliente deberá mandar el nombre de la

El creador de la partida podrá guardar, guardando en la BD los datos de la partida, o

4.2.3 Agente inteligente

4.2.3.1 Sistemas expertos

4.2.3.2 Lógica difusa y directa

4.2.3.3 Tecnología para la implementación

4.2.4 Esquema general

Ilustración 2, arquitectura cliente-servidor del sistema.

5.1 Planificación general

Es importante que la planificación diseñada permita verificar de forma continuada el

Como se puede ver en la Ilustración 2, se distinguen diferentes partes a implementar: