Videojuegos: Una alternativa para el aprendizaje de la

ciencias en educacin bsica. Caso: funcionamiento sistema

inmunolgico
Videogames: An alternative to learning in basic sciences. Case: functioning
immune system
Gabriela Veracierta 1 Nielkys Guzmn y Mercedes Ortiz
Recibido: 12-04-2012 - Aprobado: 14-08-2012

Contenido

Planteamiento del Problema

Metodologa utilizada
Desarrollo
Anlisis
Requisitos
Diseo
Implementacin
Pruebas
Conclusiones
Referencias bibliogrficas
Gracias a sus donaciones esta pgina seguir siendo gratis para nuestros lectores.
Graas a suas doaes neste site permanecer gratuito para os nossos leitores.
Thanks to your donations this site will remain free to our readers.

RESUMEN:
Los nios en edad escolar aprenden ms rpido
jugando, en funcin de esto se desarroll un
videojuego para la comprensin del
funcionamiento del sistema inmunolgico (SI)
del cuerpo humano de una manera interesante y
atractiva, la Metodologa empleada fue el
proceso Unificado de Rational (RUP) y
Lenguaje unificado de modelado (UML), el
RUP consta de cuatro fases de trabajo que
permite realizar el anlisis, diseo y desarrollo

ABSTRACT:
The school children learn faster playing,
according to a video game that was developed
for understanding how the immune system (IS)
of the human bodyin an interestingand
attractive, themethodologyused was the
Rational Unified Process (RUP) andunified
Modeling Language (UML), RUP has four
phasesof work that allows dthe analysis,
designand product development optimally,
while the UML provides diagrams to represent

del producto ptimamente; mientras el UML

ofrece diagramas para representar los artefactos
que conformarn el sistema, en las fases del
RUP. El resultado obtenido: Un videojuego
atractivo didctico sobre el funcionamiento del
SI.
Palabras clave: videojuegos, aprendizaje,
Proceso Unificado Racional (RUP) /Lenguage
Unificado de Modelado (UML)

the artifacts that make up the system, the

phases of the RUP. The result: A nattractive
educationa lgame on the operation of SI.
Keywords: videogames, Learning, Rational
Unified Process(RUP) / Unified Model
Language (UML)

Planteamiento del Problema

Actualmente muchas escuelas estn introduciendo videojuegos educativos como soporte para ayudar a
interiorizar conceptos trabajados en clase y adems ayudan a los nios desde bien pequeos a obtener
agilidad y practicar con el ordenador.
En vista de que los videojuegos llegaron a formar parte de la vida cotidiana de una gran poblacin
donde los nios son mayora, los desarrolladores de software se ven en la necesidad de crear videos
juegos, donde combinen el gnero educativo con los otros tipos de gneros que pueden abarcar los
videojuegos como ya se mencion (luchas, disparos, estrategia y aventuras), teniendo como objetivo
lograr llamar la atencin y poder aportarle algn tipo de conocimiento mientras se distraen de forma
gil y divertida.
Se desarrollar un videojuego educativo dirigido a los nios basndose en el funcionamiento del
sistema inmunolgico del ser humano, con el objetivo de lograr que el nio mientras se distrae este
adquiriendo conocimientos sobre el funcionamiento de su sistema inmunolgico. El desarrollo del
videojuego se basa en demostrar que a travs de los videojuegos tambin se puede adquirir
conocimientos educativos y proponer una alternativa para el aprendizaje.
El videojuego estar conformado por niveles, cada nivel ser representado por un tipo de enfermedad,
demostrar como acta el sistema inmunolgico ante el virus rhinovirus, que ocasiona el refriado
comn y el virus rubivirus que es el responsable de la rubeola, estos virus seatacan el cuerpo humano.

Metodologa utilizada
Para el diseo del juego se us la Metodologa RUP, El Proceso Unificado de Rational es unproceso de
ingeniera del software. Proporciona un acercamiento disciplinado a la asignacin de tareas y
responsabilidades en una organizacin de desarrollo. Su propsito es asegurar laproduccin de software
de alta calidad que se ajuste a las necesidades de sus usuarios finales con unos costos y calendario
predecibles.(Kruchten, 2001).
Este proceso consta de cuatro (4) fases: Fase de inicio, Fase de elaboracin, Fase de Construccin y
Fase de transicin. Usando el lenguaje UML.

Recoleccin de Informacin
Entrevistas y consultas:Las entrevistas fueron de carcter no estructuradas. Permitiendo obtener la
informacin necesaria para la elaboracin del proyecto; estas se realizaron a Mdicos y estudiantes
avanzados de medicina en la Universidad de Oriente; tambin se consultaron bibliografas de
inmunologa humana.

Desarrollo

Fase de Inicio
Durante la fase de inicio se identifican los requerimientos, tanto funcionales como, no funcionales del
videojuego, analizando el contexto del sistema;se realiza el anlisis de la viabilidad del proyecto,
estableciendo y priorizando los riesgos. De acuerdo con estos requisitos se realizan los diagramas de los
casos de uso ms importantes.
Modelo de dominio
El Modelo de Dominio captura los tipos ms importantes de objetos en el contexto del sistema.
Para el modelo de dominio, se tiene las clases conceptuales del sistema por medio de las cuales se tiene
una visin del proceso actualmente;se puede apreciar en la Figura 1, eldiagrama de dominio, donde el
jugador inicia el juego y puede utilizar las opciones que posee, entre ellas est la opcin de modificar si
no desea sonido, pausar el juego, pedir ayuda sobre el juego y cerrar sesin, el juego posee un escenario
donde el jugador interacta con el sistema, el escenario est conformado por una serie depersonajes.
Durante el desarrollo del juego el jugador debe realizar los retos propuesto por el sistema para obtener
una determinadarecompensa.
Figura 1. Diagrama del Dominio

Glosario de trminos para el modelo de dominio

El glosario del modelo de dominio de la Figura 1 incluye y define todos los trminos que son de vital
importancia para la comprensin del anlisis que se realizar en las fases de desarrollo, los cuales se
mencionan a continuacin:

Jugador: Representa al usuario o a la persona que interacta con el sistema.

Juego: Representa el sistema con el cual el jugador interactuar.
Opciones: Representa las opciones que le brindar el sistema, entre ellas el uso de audio, cerrar
sesin, pausar el juego y una opcin de ayuda.
Escenario: Representa el ambiente donde se desenvolver el juego.
Retos: Representa los objetivos que deben lograr para obtener recompensas.
Recompensas: Representa el premio por lograr un determinado reto.
Personajes: Representa a los protagonistas del juego.

Requisitos funcionales
Se propone desarrollar un videojuego sencillo donde los nios puedan aprender sobre el sistema
inmunolgico del cuerpo humano, mientras se entretienen, el nombre del juego es SIRPONYG. Se
considerarn como referencia los videojuegos actuales, tomando como gua sus caractersticas
principales y los objetivos a lograr, se determin las siguientes funcionalidades bsicas:

Jugar. (Interactuar con el ambiente y los personajes del juego).

Mostrar la historia del videojuego.
Mostrar y gestionar opciones del videojuego.

Representacin de los requisitos como Casos de Uso

El Modelo de casos de Uso se compone por varios objetos que intervienen en los procesos que un
sistema es capaz de ejecutar, los cuales se describen mediante la identificacin de casos de uso,
identificacin de actores y descripcin de los casos de uso.En la Figura 2, se representa los requisitos
funcionales del videojuego mediante el diagrama de casos de uso.
Figura 2. Diagrama de casos de uso general

Identificacin del actor

Jugador: Est representado por los nios que interacta con el videojuego permitindoles
acceder a las funciones que el sistema les ofrece.

Requisitos no funcionales
Los requisitos no funcionales se capturan a travs de una lista de requisitos, y se utilizan durante el
anlisis y el diseo junto al modelo de casos de uso. En este caso se consideran los siguientes requisitos
adicionales:

Entorno:El entorno se debe representar de forma atractiva para el jugador, usando diferentes
herramientas, como texto, sonido e imgenes.
Implementacin: El formato de visualizacin debe ser robusto y consistente para todas las
funciones que se implementen, se debe realizar un diseo del sistema fcil de administrar y
mantener.

Aspectos fundamentales del videojuego

En esta etapa es necesario definir los aspectos fundamentales que conformarn el videojuego, entre los
que se encuentran:

Gnero: El gnero del videojuego es educativo, ya que se dar a conocer al usuario

conocimientos sobre el sistema inmunolgico del cuerpo humano.

Forma de Juego: El juego se basar en identificar y buscar rganos, clulas o huesos que
intervienen en el proceso del sistema inmunolgico del cuerpo humano.
Descripcin del ambiente y personajes: El ambiente ser realizado tomando como referencia
el cuerpo humano interno (Huesos y rganos), el sonido principal del ambiente ser el sonido
de los latidos del corazn y los personajes sern realizados tomando como referencia las clulas
que conforman el sistema inmunolgico.
Poblacin: El juego va dirigido a los nios que sepan leer, la edad promedio de esta poblacin
son nios a partir de ocho aos.

Ya finalizado el primer flujo de trabajo (captura de requisitos) en esta fase de inicio, con el uso de la
identificacin del contexto del sistema y los requisitos funcionales esenciales, se procede a trabajar en
el segundo flujo de trabajo de esta fase, el de anlisis, en el cual se profundizar en lo referente a las
funciones del sistema antes mencionadas.

Anlisis
En esta etapa se analizan, refinan y estructuran los requisitos encontrados en el flujo de trabajo
precedente. La idea es conseguir una comprensin ms precisa de los requisitos y una descripcin de
los mismos que sea fcil de mantener y que ayude a estructurar el sistema entero incluyendo su
arquitectura. El propsito fundamental del anlisis es resolver los casos de uso analizando los requisitos
con mayor profundidad.

Diagramas de clases de Anlisis

Los diagramas de clases de anlisis siempre estn asociados a una clase, a una operacin o a un caso de
uso en particular, en este caso estn asociados a los casos de uso explicados con anterioridad.
Diagrama de clases de anlisis del caso de uso Iniciar Juego
En la Tabla 1, se muestran las clases que se utilizan en el diagrama de clases de anlisis del caso de uso
Iniciar Juego, con sus respectivas descripciones.
Como se muestra en la Figura 3, el jugador inicialmente se encuentra con una clase de interfaz llamada
IU Usuario donde debe ingresar un login o en caso de no tenerlo debe crearlo para poder iniciar
juego, sta restriccin es con la finalidad de poder guardar el nivel para cada usuario, sta clase de
interfaz es controlada por la clase de control llamada Gestor Usuario, donde solicita o enva data a la
clase entidad llamada Usuario, luego de tener su login e ingresar al juego se encuentra con una clase
de interfaz llamada IU Juego en sta interfaz es donde el jugador interactuar con los personajes y el
escenario que conforman el videojuego, sta interfaz es controlada por la clase de control llamada
Gestor Juego que se encargar de controlar el desarrollo del videojuego y para ello necesita el acceso
a la clase de control llamada Gestor Nivel. El Gestor Juego solicita la data para cargar los
personajes a la clase entidad llamada Personaje y solicita la data para cargar el ambiente a la clase
entidad llamada Escenario una vez cargado el escenario y los personajes enva la data a la clase de
control llamada Gestor Nivel que se encargar de solicitar los retos dependiendo del nivel en que se

encuentre el jugador a la clase entidad llamada Reto.

Tabla 1. Especificacin de las clases del diagrama de clases de anlisis del caso de uso Iniciar
Juego.
Nombre de la
Clase

Tipo de Clase

IU Principal

Clase de
Interfaz

Interfaz principal, permite al jugador ingresar al juego.

IU Juego

Clase de
Interfaz

Interfaz secundaria, se cargan todos los componentes grficos

y es donde se desarrolla el juego.

Gestor Juego

Clase de
Control

Es la clase que controla todos los componentes grficos de la

clase interfaz IU Juego.

Gestor Usuario

Clase de
Control

Es la clase que controla todos los componentes grficos de la

clase interfaz IU Principal y la data del usuario.

Gestor Nivel

Clase de
Control

Es la clase que controla los niveles del juego.

Usuario

Clase de
Entidad

Contiene la informacin del usuario el login y el nivel en el

que se encuentra.

Personaje

Clase de
Entidad

Contiene los personajes del juego

Reto

Clase de
Entidad

Contiene los retos que se presentarn durante desarrollo del

juego

Escenario

Clase de
Entidad

Contiene el ambiente donde se desarrolla el juego.

Descripcin

Diagrama de clases de anlisis del caso de uso Gestionar Opciones

En la Tabla 2 se muestran las clases que se utilizan en el diagrama de clases de anlisis del caso de uso
Gestionar Opciones, con sus respectivas descripciones.
Figura 3. Diagrama de clase de anlisis del caso de uso Iniciar Juego

----Tabla 2: Especificacin de las clases del diagrama de clases

de anlisis del caso de uso Gestionar Opciones.
Nombre de Tipo de
la Clase
Clase
IU Opciones Clase de
Interfaz

Descripcin

Gestor
Opciones

Clase que permite procesar y realizar la

opcin que el jugador ha seleccionado.

Clase de
Control

Interfaz principal, permite al jugador

seleccionar las opciones que el juego
posee.

En la Figura 4 se muestra como el jugador tendr una interfaz de las opciones que le ofrece el sistema,
entre ellas est activar o desactivar sonido, solicitar ayuda, detener el juego y cerrar sesin, todas estas
opciones mostradas sern manejadas y procesadas por la clase de control Gestor Opciones.
Figura 4. Diagrama de clases de anlisis del caso de uso Gestionar Opciones

Diagrama de colaboracin para el caso de uso Iniciar Juego

En la Figura 5, se muestra el diagrama de colaboracin para la realizacin del caso de uso Iniciar
Juego; donde se puede observar la solicitud del jugador para iniciar juego, se le enva la data a la clase
de control llamada Gestor Usuario donde esta clase solicita la informacin a la clase entidad llamada
Usuario para luego enviar la data a la clase interfaz llamada IU Juego que ser controlada por una
clase de control llamada Gestor Juego donde sta solicitar la data de los personajes y escenario para
cargarlos en la clase interfaz, para luego enviar la data a la clase de control llamada Gestor Nivel
donde sta solicitar los retos que el jugador deber cumplir segn el nivel en el que se encuentra a la
clase entidad llamada Reto.
Diagrama de colaboracin para el caso de uso Gestionar Opciones
En la Figura 6, se muestra el diagrama de colaboracin para la realizacin del caso de uso Gestionar
Opciones; donde se puede observar al jugador solicitando ejecutar las opciones que el juego le ofrece,
la data es enviada a la clase de control llamada Gestor Opciones, sta clase es la que se encargar de
llevar a cabo dicha solicitud.

Leyenda
1: Solicitud iniciar juego.
2: Envo de data para iniciar juego a la clase de control Gestor Usuario.
3: Solicitud de data a la clase entidad Usuario.
4: Activa la clase interfaz IU Juego.
5: Envo de data a la clase de control Gestor Juego. Para cargar el segn el usuario
6: Solicitud de data a la clase entidad Escenario.
7: Solicitud de data la clase entidad Personaje.
8: Envo de data a la clase de control Gestor Nivel.
9: Solicitud de data a la clase entidad Reto.
10: Interactuar con el juego.
Figura 5. Diagrama de colaboracin para el caso de uso Iniciar Juego

Diagrama de Paquete de Anlisis

Los paquetes estn normalmente organizados para maximizar la coherencia interna dentro de cada
paquete y minimizar el acoplamiento externo entre los paquetes; dicho esto se puede deducir que los
paquetes son buenos elementos de gestin. Cada paquete puede asignarse a un individuo o a un equipo,
y las dependencias entre ellos pueden indicar el orden del desarrollo requerido.

Leyenda
1: Solicitud para procesar opciones seleccionadas.
2: Envo de data a la clase de control Gestor
Opciones.
Figura 6. Diagrama de colaboracin para el caso de uso Iniciar Juego
En la Figura 7se puede observar los paquetes de anlisis identificados a partir de los casos de
uso del videojuego.El paquete Gestin del juego incluye todas las actividades relacionada a la
interaccin del videojuego y el usuario, es decir, incluye todas las actividades que le darn vida al
sistema.El paquete Gestin de Opciones incluye todas las actividades adicionales que el usuario
podr ejecutar en el videojuego.
Figura 7. Diagrama de paquete de anlisis

Fase de Elaboracin
La fase de elaboracin tiene por objeto construir el ncleo central de la arquitectura, resolver los
elementos de alto riesgo, definir los requerimientos y estimar los recursos necesarios.
Se identifican los procesos, capas de software, paquetes, subsistemas, estableciendo sus
responsabilidades y se efecta la clarificacin de las interfaces internas (entre componentes) y externas
(con los actores), refinndolas e incluyendo parmetros y valores de retorno.

Requisitos
En este flujo de trabajo no se identificaron nuevos actores, casos de uso, ni requisitos que se pudiesen

adicionar a los antes establecidos, ya que hubo un total entendimiento del contexto en la fase de inicio,
que permiti establecer directamente los lineamientos que se van a utilizar durante el desarrollo del
proyectos.

Diseo
En la fase de elaboracin el diseo tiene como objetivo la obtencin de la vista de la arquitectura del
modelo de diseo y la realizacin fsica de los casos de uso. Se modelar el sistema para que soporte
todos los requisitos, incluyendo los requisitos no funcionales y otras restricciones, que se le suponen.

Diagrama de Capas
La Figura 8 muestra la arquitectura del sistema SIRPONYG utilizando un diagrama de capas.En la
capa especfica de la aplicacin se identifica los subsistemas Gestin del Juego y Gestin de Opciones,
mientras que para la capa general de la aplicacin se distingue el subsistema SIRPONYG que ser el
nombre de la aplicacin.Luego se identifican los subsistemas de las capas intermedias y de software del
sistema, que constituyen los cimientos de un sistema, ya que, toda la funcionalidad descansa sobre
software como sistemas operativos, sistemas de gestin de base de datos, software de comunicaciones,
entre otros. A la capa intermedia corresponden los subsistemas: PHP, AS3 y Flash CS3. Para la capa de
software se identifica el manejador de base de datos MySQL y el sistema operativo Microsoft
Windows.
Figura 8. Diagrama de capas

Diagrama de Clase de Diseo

El diagrama de clase de diseo muestra una estructura esttica del sistema, representando cada una de
las clases que intervienen en cada proceso, proporcionando la funcionalidad del sistema.
La Figura 9 representa de manera general el diagrama de clase del sistema SIRPONYG. Este sistema
posee una clase IU Principal, donde inicia la aplicacin esta clase le solicita al usuario ingresar un
login que ser enviado a la clase Gestor Usuario, clase encargada de controlar ese login usando
informacin que se encuentra en la base de datos. Una vez gestionado el login la clase Gestor Usuario
activa la clase IU Juego clase que ser controlada por la clase Gestor Juego.
La clase Gestor Juego solicita cargar los personajes y el escenario de la aplicacin y activa la clase
Gestor Opciones que es la clase encargada de las opciones que ofrece el juego, segn el nivel en el
que se encuentre el jugador tambin activar la clase Gestor Nivel1 o la clase Gestor Nivel2 o la
clase Gestor Nivel3, estos gestores tendrn acceso a la base de datos para solicitar los retos y
animaciones propuestos para cada nivel.La clase Gestor Juego tambin tendr acceso a la base de
datos para modificar el nivel del usuario.

Diseo de la Base de Datos

La base de datos del sistema es utilizada para guardar la informacin del jugador en este caso se
necesita un login para cada jugador con el fin de relacionar el nivel en el que se encuentran cada uno de
ellos, tambin se guardan los retos que el jugador debe cumplir en el juego y todos los nombres de los
distintos objetos 3d que se utilizan durante la ejecucin del sistema.
Para su representacin se utiliza el modelo Entidad-Relacin, que permite modelar conceptualmente los
datos del sistema a travs del establecimiento y representacin de las entidades, facilitando la creacin
de la Base de Datos.Este modelo consta de entidades y sus atributos, relaciones, roles y claves que
permitirn la representacin grfica de la base datos. En la Figura 10 se observa la representacin de
las entidades de la base de datos. Estas entidades representan las tablas del sistema y son denominadas
Usuario, Animacin, Reto y Nivel cada una muestra sus respectivos atributos.
Para la identificacin de la clave principal de cada tabla se subraya el atributo correspondiente a la
misma.
Las relaciones de las entidades se describen de la siguiente forma:

Tabla Nivel con la Tabla Usuario:Un usuario solo puede estar en un nivel.
Tabla Nivel con la Tabla Animacin:Una animacin tiene un nivel.
Tabla Nivel con la Tabla Reto:Un reto posee un nivel.
Figura 9. Diagrama de clases de diseo

Figura 10. Diagrama de las tablas de la base de datos del sistema SIRPONYG.

Diseo de la Interfaz
La interfaz de usuario permite el flujo de informacin entre un usuario y la aplicacin. Para el
diseo de las Interfaces del sistema SIRPONYG se debe tomar en consideracin que es un juego
sobre el sistema inmunolgico del cuerpo humano y que el objetivo a lograr es que la poblacin que son
los nios adquiera conocimientos sobre el sistema inmunolgico, ya que es un juego educativo.La
Figura 11 es referente a la interfaz inicial del juego, donde el jugador debe ingresar un login para iniciar
el juego. Esta interfaz consta de un campo de texto donde el usuario debe ingresar su login e ingresar al
juego, en caso de no tener un login la interfaz posee una opcin de Nuevo Usuario para que el
jugador pueda crear su login y entrar al juego. Esta interfaz es necesaria ya, que se necesita un login
para llevar el control del nivel en el que se encuentre cada jugador.
La Figura 12 es la interfaz de carga que vern los jugadores despus que ingresan el login. Proporciona
un tiempo adicional de carga para establecer la configuracin principal del sistema y garantizar que se
carguen de forma correcta todos los componentes.
Figura 11 Interfaz Inicial del sistema SIRPONYG

En la Figura 13 y la Figura 14 muestra la pantalla que revela el juego cargado, se puede apreciar el
ambiente o escenario del juego y tambin se puede apreciar como el juego se comunicar con el
jugador. El escenario del juego fue realizado basndose en el funcionamiento real del sistema
inmunolgico del cuerpo humano, se tom los rganos principales que intervienen en el proceso. En
estas figuras tambin se puede apreciar la barra de opciones que el juego les ofrece a los jugadores.
Figura 12 Interfaz de carga antes de iniciar el juego del sistema

Figura 13 Interfaz del juego SIRPONYG cargado y comunicndose con el Jugador.

Figura 14 Interfaz del juego SIRPONYG cargado

Detalles de los elementos del videojuego

Historia: El videojuego le mostrar al usuario determinados retos, que tendrn informacin real
sobre el funcionamiento del sistema inmunolgico. Se pretende guiar al jugador a travs de los
retos para que realice las respuestas del sistema inmunolgico ante un virus de una forma
simplificada.
Mecnica de Juego: Consistir en la bsqueda y seleccin de rganos, huesos, y en eliminar
virus;ste estar conformado por nivelesque el jugador pasarmientras vaya superando los retos.
Diseo de Programacin: El juego ser ejecutado en una computadora y el lenguaje a utilizar
es ActionScript 3.0.

Implementacin
En la implementacin se comenzar con el uso de los resultados del diseo y se implementar el
sistema en trminos de componentes. El propsito principal de este flujo de trabajo es desarrollar la
arquitectura y el sistema como un todo. Aqu se realizar el diagrama de componentes parcial de la
aplicacin.

Diagrama de Componentes
Para la fase de elaboracin se ha construido un adelanto de los componentes que conforman el sistema
de forma general. En la Figura 14 se observan los componentes principales requeridos para la
implementacin del caso de uso Iniciar Juego. Se indica el tipo de archivo correspondiente y su
extensin (flash, php, flare3D). Proporciona la relacin entre cada componente que establece el vnculo
entre los componentes que han sido desarrollado hasta ahora. Especficamente se expone la iteracin
del inicio del juego en determinado nivel.

Fase de construccin

Herramientas de Desarrollo
Para el desarrollo de SIRPONYG se utilizan las siguientes herramientas:

El lenguaje de programacin PHP, que es el lenguaje que permitir las consultas a la base de
datos, a travs de la interfaz de software Dreamweaver.
Figura 15. Diagrama de Componente del caso de uso Iniciar Juego.

Para el desarrollo general del juego se utiliza el lenguaje de programacin de la Plataforma

Adobe Flash ActionScript 3.0. La programacin con ActionScript permite mucha ms eficiencia
en las aplicaciones de la plataforma Flash para construir animaciones de todo tipo, ricas en datos
e interfaces interactivas.
Para el diseo del escenario y los personajes del sistema se utiliza la herramienta Autodesk 3ds
Max, es un programa de creacin de grficos y animacin 3D, con su arquitectura basada
en plugins, es uno de los programas de animacin 3D ms utilizado en la creacin de video
juegos, anuncios de televisin, en arquitectura o en pelculas.
Para la creacin de las imgenes se utiliza la herramienta Adobe Photoshop, es una aplicacin
informtica en forma de taller de pintura y fotografa que trabaja sobre un "lienzo" y que est
destinado para la edicin, retoque fotogrfico y pintura a base de imgenes de mapa de bits.
Se utiliza el motor Flare3D que permite incluir y manipular objetos 3D dentro de Flash.
Flare3D permite exportar desde 3ds Max el modelo que se desee importar a Flash usando el
plugin nativo de Flare3D, tambin permite levantar el archivo F3d desde Flash. Y agregar la

lgica deseada mediante ActionScript 3.0

Para la construccin de la base de datos del SIRPONYG se escoge el manejador MySQL,
debido a que proporciona facilidades de conexin con el lenguaje PHP, garantiza la integridad y
seguridad de los datos. La interfaz del WAMP es la que permite la creacin de la base de datos
del SIRPONYG.

Implementacin
La implementacin trata al sistema en trminos de desarrollo de componentes y codificacin del
software, integracin de mdulos y la explicacin acerca de las funcionalidades del sistema y su
correcto uso, delatando as toda la estructura en forma de cdigo abierto e identificacin de las
actividades que ste puede realizar.

Construccin de la Base de Datos

La estructura bsica de la base de datos de SIRPONYG, ya fue realizada con anterioridad, y se
mostr el diagrama de entidad-relacin.Debido a que no se registran cambios en la estructura de la base
de datos, se implementa, a travs del WAMP.

Diagrama de Componentes
En esta fase se desarrolla el diagrama de componentes con la totalidad de los componentes del sistema,
indicando las clases que necesitan cada uno. En la Figura 16, se puede observar los paquetes ya
definidos en la fase de inicio que son el paquete de Gestin de Opciones y el paquete de Gestin del
Juego.
En el paquete Gestin del Juego se puede observar que fue dividido en paquetes segn su funcin. El
paquete Principal es el que se encarga de gestionar todo lo referente al usuario y permitirle al jugador
iniciar el juego.El paquete Iniciar Juego es el que se encarga de llevar a cabo todo el desarrollo del
video juego.El paquete Conexin contiene todas las consultas que se le realizan a la base de datos y
el paquete Objeto 3d contiene el ambiente, los personajes y las animaciones del videojuego.
Figura 16. Diagrama de Componentes.

Pruebas
Las pruebas son los procesos que determinan si el software satisface los requisitos y funciona de la
manera establecida,se verifica la interaccin entre los objetos, al igual que la integracin apropiada de
componentes, identificar los defectos y corregirlos antes de la instalacin.

Pruebas por Unidad

Las pruebas por unidad se aplicaron mediante la aplicacin de la prueba de la caja negra sobre los
diversos componentes del sistema. Para realizar este tipo de pruebas, se identifican un conjunto de
valores que pueden ser introducidos por un actor, y se expresan como clases de equivalencia para poder
abarcar la totalidad de las ocurrencias de un evento de insercin de datos. En el sistema SIRPONYG,
solo se tiene un actor que es el jugador, y este jugador solo ingresar al sistema un login cuando desee
iniciar juego. La siguiente Tabla 7 representa la equivalencia del caso de uso iniciar juego.
Tabla 7. Clases de equivalencia para el caso de uso Iniciar Juego

Dato

Clase Equivalencia

Valido

No
Valido

Login

Caracteres Numricos

Login

Caracteres Alfabticos

Login

Caracteres Alfanumricos

Login

Longitud de caracteres>10

Login

Longitud de caracteres<10

Login

Dato nulo

Login

Dato repetido

x
x

Prueba de Integracin
El objetivo general de las pruebas de integracin es, detectar las fallas de interaccin entre las distintas
clases que componen al sistema. Debido a que cada clase probada por separado se inserta de manera
progresiva dentro de la estructura, las pruebas de integracin son realmente un mecanismo para
comprobar el correcto ensamblaje del sistema completo.
Al efectuar la integracin de los mdulos, se concentra el esfuerzo en la bsqueda de fallas que puedan
provocar excepciones arrojadas por los mtodos; el empleo de operaciones equivocada, e invocacin
inadecuada de los mtodos. Luego de verificar la calidad de los componentes, se procede a comprobar
la eficiencia de un conjunto de componentes integrados por fase, stas se pueden observar resaltadas en
la Figura 17 donde se despliega el diagrama de componentes por fase de integracin del sistema. La
primera fase fue el desarrollo de la IU principal, la segunda fase fue el desarrollo del juego, donde se
fue realizando los modelados 3d de los personajes y escenario y la gestin de los niveles, en estas dos
fases se fue realizando los archivos de PHP necesarios para realizar la conexin con la base de dato. Por
ltimo se realiz la IU de las opciones y su gestin.

Figura 17. Diagrama de Componentes por Fases de Integracin

Conclusiones
Los retos propuestos en el videojuego estn basados en informacin real sobre el sistema inmunolgico
del cuerpo humano. Cada nivel del juego tiene diferentes retos y cada reto representa una informacin
sobre el sistema inmunolgico, guiando al jugador a realizar las respuestas que adquiere el sistema
inmunolgico ante la presencia de un virus. A travs de los retos se aprovecha nutrir al jugador con la
informacin bsica del funcionamiento del sistema inmunolgico.
El uso de la herramienta Autodesk 3ds Max, para la creacin de los personajes, hizo un poco
pesado el juego al iniciar,
debido al tamao de las imgenes y la cantidad de ellas, esta situacin
se mejor debido al uso de imgenes estticas y que se guard el escenario para cargarlo completo y no
por partes; de esta forma se aument la velocidad de respuesta por parte del sistema, sin pixelar las
imgenes y evitando las pausas.
El juego consta de tres (3) niveles, en cada uno de ellos se tiene acceso a una ayuda personalizada,
donde se le explica al jugador la tarea que debe realizar para avanzar al prximo nivel; Tambin el
puntero tiene la funcin de mostrar el nombre del rgano, hueso o componente del sistema, cuando se
posiciona sobre alguno de ellos.

En el primer nivel del juego se trabaj con el virus rhinovirus, para que el usuario se familiarice con los
huesos que trabajan con el sistema inmunolgico, as como los rganos ms importantes, glbulos
blancos y macrfagos; as pueda identificarlos en los prximos niveles; En este nivel se muestra la
respuesta innata del sistema inmunolgico.
En el segundo nivel se interacta con el virus rubivirus, como el jugador ya ha superado el primer nivel,
entonces en este segundo nivel el jugador tiene un tiempo en contra para poder defender el cuerpo del
virus; Los rganos que intervienen son el fmur, el timo y el bazo, globulos blancos y linfocitos T; en
caso de que se termine el tiempo y el jugador no controlo el virus debe comenzar a jugar este nivel.
En el tercero y ltimo nivel, se prueba el conocimiento adquirido en los dos primeros niveles del juego;
se tiene un tiempo en contra, y tres vidas que son restadas si falla o si se disminuye el tiempo; tambin
se colocan obstculos para dificultar el acceso al virus a destruir; en este nivel intervienen todos los
componentes del sistema inmunolgico presentados en los niveles anteriores.
Se desarroll un escenario con caractersticas atractivas para promover el inters de los nios y facilitar
el aprendizaje. En el videojuego se encuentran las clulas que conforman el sistema inmunolgico entre
ellos est el macrfago, los fagocitos, las clulas T y la clulas B. Estas clulas se comportan en el
videojuego de forma parecida a como lo hacen en el sistema inmunolgico y se realiz el modelado y
texturizado de estas clulas tomando como referencia clulas reales. Tambin se realiz el modelado y
texturizado de los rganos principales que intervienen en el proceso.
Se desarrollaron algoritmos eficientes para la gestin del videojuego, de manera que ya que se estaba
trabajando con objetos 3d, se debi ser muy cuidadoso a la hora de manejar cargar y manipular los
objetos. Los algoritmos permitieron percibir las colisiones del jugador y los otros personajes en los
distintos niveles de forma correcta. El algoritmo general del juego se centra en una constante bsqueda
y ejecucin del desarrollo de los retos en los distintos niveles.
La fase de elaboracin permiti eliminar la mayor cantidad de riesgos posibles empezando por los ms
altos o de ms relevancia. Tambin se definieron los flujos de trabajo en diseo y organizacin del
sistema, representados por los diagramas correspondientes. Se definieron los elementos que detallan al
videojuego como su historia, que hace referencia a la forma en que el jugador se desenvolver en el
videojuego y la mecnica, que hace referencia a la diversin o la distraccin que el jugador tendr en el
videojuego.
La integracin de cada uno de los mdulos se realiz sin ningn inconveniente y permiti obtener una
aplicacin robusta, confiable y segura.Mediante la realizacin de pruebas de unidad e integracin se
encontraron y corrigieron fallos menores del sistema, que garantizan la obtencin de un producto de
buena calidad.
El videojuego SIRPONYG ofrece una alternativa para facilitar en los nios el proceso de enseanza y
aprendizaje sobre el sistema inmunolgico del cuerpo humano. Mediante este proyecto se plantea una
herramienta til para influir en el conocimiento, principalmente de los nios,todas aquellas personas
que jueguen podrn adquirir un conocimiento bsico del funcionamiento de su sistema inmunolgico.

Referencias bibliogrficas
Aguilar Joyanes, L. (1996). Programacin Orientada a Objetos. Madrid: McGraw-Hill.
Delves P., Martin S., Burton D., Roitt I., (2006). Inmunologa. Fundamentos. Madrid- Espaa.
Fainboim L., Geffner J., (2008). Introduccin a la inmunologa humana. Buenos Aires: Mdica
Panamericana.
Fireman P., (2007). Atlas de Alergia e inmunologa clnica. Madrid-Espaa. Elsevier Espaa.
Gil A., Mombiela T., (2007). Los videojuegos. Barcelona. Espaa. Pujol & Amado S L L
Jacobson, I., Booch, G., &Rumbaugh, J., (2000). El lenguaje unificado de modelado (1era Edicin).
Madrid: Pearson Educacin.
Jacobson, I., Booch, G., &Rumbaugh, J., (2000). El proceso unificado de desarrollo de software
(1era Edicin).Madrid: Pearson Educacin.
Microsoft, C., (2010). Centro de desarrollo de .NET Framework. Recuperado el Mayo de 2010, de
Centro de desarrollo de .NET Framework:http://msdn.microsoft.com/es-ve/netframework/default.aspx
Philippe Kruchten, (2001).The Rational Unified Process An Introduction, USA. Addison Wesley.
Roja O., (2006). Inmunologa (de memoria). Mxico. Ed. Panamericana
Rojas W., (2004). Inmunologa. Medelln, Colombia. Corporacin para Investigaciones Biolgicas.
Silverschatz, A., Korth, H., &Sudarshan, S. (2006). Fundamentos de bases de datos (5ta
Edicin).Madrid: McGraw-Hill.
The Web ModelingLanguage. (7 de Febrero de 2010). Recuperado el Abril de 2010, de The Web
ModelingLanguage: http://www.webml.org/.
Universidad Autnoma De Baja California. (Junio de 2006).Proceso Unificado. Recuperado el 30 de
abril de 2010, de Manuales en lnea: http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm.

1 Universidad de Oriente. UDO. Venezuela. Email: gabrielaveraciertat@hotmail.com

2 Universidad de Oriente. UDO. Venezuela
Vol. 34 (1) 2013

Temario/Un ejemplo de la creacin de un videojuego/Anlisis

Tabla de contenidos
[esconder]

1 Anlisis
o 1.1 Modelo de Casos de Uso
1.1.1 Casos de uso
1.1.2 Diagramas de casos de uso
1.1.3 Descripcin de los casos de uso
o 1.2 Modelo conceptual de datos en UML
1.2.1 Conceptos bsicos
1.2.2 Descripcin diagramas de clases conceptuales
o 1.3 Diagrama de clases
o 1.4 Modelo de comportamiento del sistema
1.4.1 Diagramas de secuencia del sistema y los Contratos de operaciones
1.4.2 Diagramas de secuencia del sistema y Contratos de las operaciones
del sistema

[editar] Anlisis
En el anlisis del sistema se realizan los modelos que nos ayudan a analizar y especificar el
comportamiento del sistema. Existen varios tipos de modelado nosotros vamos a utilizar un
efoque orientado a objetos usando la notacin UML.
En este apartado vamos a realizar un anlisis del problema a resolver con el objetivo de
describir qu debe de hacer el sistema software y no, todava, cmo lo hace. Es un paso ms
entre el problema y su resolucin final. Es fundamental a la hora de desarrollar un
videojuego hacer un anlisis detallado de lo que queremos que haga nuestro videojuego. Es
importante que creemos un sistema potente pero que, si es uno de nuestros primeros
proyectos, no se nos escape de las manos.

El anlisis ser el primer paso que nos guiar en la construccin de nuestro videojuego.
Para este paso vamos a utilizar el modelado UML. UML es el lenguaje de modelado ms
utilizado en la actualidad. Es un lenguaje grfico para visualizar, especificar, construir y
documentar sistemas software. Nos permite especificar el sistema, que no describir
mtodos o procesos, y se define sobre una serie de diagramas que estudiaremos a
continuacin.

[editar] Modelo de Casos de Uso

El modelo de casos de uso de UML especifica qu comportamiento debe de tener el sistema
software. Representa los requisitos funcionales del sistema centrndose en qu hace y no en
cmo lo hace. Este modelo no es orientado a objetos por lo que podemos utilizarlo en
proyectos que no lo sean.

[editar] Casos de uso

El caso de uso est compuesto de:

Conjunto de secuencia de acciones Cada una de estas secuencias representa un posible

comportamiento del sistema.
Actores Roles o funciones que pueden adquirir cada usuario, dispositivo u otro sistema al
interaccionar con nuestro sistema. El tempo puede ser considerado un sistema por lo que
puede ser un actor. Los actores no son parte del sistema en s. Hay dos tipos de actores

o
o

Principales Demanda al sistema el cumplimiento de un objetivo.

Secundarios Se necesita de ellos para cumplir con un objetivo.

Variantes Casos especiales de comportamiento.

Escenarios Es una secuencia de interacciones entre actores y el sistema. Est compuesto
de un flujo principal y flujos alternativos o excepcionales. Es una instancia de un caso de
uso.

Los casos de uso son iniciados por un actor con un objetivo concreto y es completado con
xito cuando el sistema cumple con dicho objetivo. Existen secuencias alternativas que nos
pueden llevar al xito o al fracaso en el cumplimiento del objetivo. El conjunto completo de
los casos de uso especifica todas las posibles formas de usar el sistema que no es ms que el
comportamiento requerido de dicho sistema.
Los casos de uso ofrecen un medio eficiente para capturar requisitos funcionales
centrndose en las necesidades del usuario. Dirigen el proceso al desarrollo a que las
actividades que conlleva este desarrollo se realizan a partir de los casos de uso.

Existen tres tipos de relaciones en los casos de uso:

Generalizacin Un caso de uso hereda el comportamiento y significado de otro.

Inclusin Un caso de uso incorpora explcitamente el comportamiento de otro en algn
lugar de su secuencia.
Extensin Un caso de uso ampla la funcionalidad de otro incluyendo implcitamente el
comportamiento de otro caso de uso.

[editar] Diagramas de casos de uso

Una vez estudiada esta pequea introduccin a los casos de uso vamos a realizar el
diagrama que representa la funcionalidad de nuestro videojuego de ejemplo. Es importante
que dediques un tiempo importante a este proceso antes de empezar a implementar el
videojuego porque entre la documentacin generada y la vista general del proyecto que te
proporciona este diagrama te ahorrarn muchos quebraderos de cabeza.
Para obtener los casos de uso seguiremos el siguiente procedimiento:
1.
2.
3.
4.

Identificaremos a los usuarios del sistema y los roles que juegan en dicho sistema.
Para cada rol identificaremos todas las maneras de interactuar con el sistema.
Creamos un caso de uso para cada objetivo que queramos cumplir.
Estructuraremos los casos de uso.

El diagrama de casos de uso es una ayuda visual pero lo realmente importante se encuentra
en la descripcin de los casos de uso. Vamos a seguir el esquema anterior para crear
nuestro diagrama de casos de uso.
El usuario de nuestro sistema es nico. El mismo ser el que edite los niveles as como
juegue a sus creaciones. No hay diferenciacin de roles ya que siempre realizar la funcin
de usuario del sistema software.
Ahora vamos a identificar las maneras que tiene el usuario de interactuar con el sistema.
Son tres. La primera se produce cuando el jugador decide jugar a los niveles creados. La
segunda es cuando el usuario decide editar los niveles del videojuego para modificar algn
detalle del mismo o crear niveles nuevos. La tercera est relacionada con la peticin de salir
de la propia aplicacin. Para cada uno de estos objetivos crearemos un caso de uso que
mostraremos en el diagrama de la figura.

Diagrama de casos de uso: Videojuego de ejemplo

[editar] Descripcin de los casos de uso

La descripcin de un caso de uso es un texto que puede ser expresado de varias formas.
Nosotros vamos a utilizar una notacin formal usando plantillas. Este texto debe ser legible
y comprensible por un usuario que no sea experto. Para describir los casos de uso vamos a
utilizar una plantilla en formato completo que nos permita dejar fuera de toda duda
razonable los casos de uso requeridos en nuestro videojuego.
Vamos a proceder a describir los casos de uso de nuestro videojuego:
DESCRIPCIN CASO DE USO: Cargar Niveles

Caso de uso: Cargar Niveles

Descripcin: Carga el fichero de niveles de juego en la aplicacin desde un fichero de
datos.
Actores: Usuario

Precondiciones: Para realizar dicha accin deben de existir niveles guardados en el fichero
de niveles.
Postcondiciones: Los datos del primer nivel almacenado sern mostrados en pantalla para
poder interaccionar con dicho nivel.
Escenario principal: Describimos el escenario principal:

1.
2.
3.
4.
5.
6.

El usuario demanda la carga de los niveles.

El sistema carga los niveles.
El sistema comprueba que el fichero existe.
El sistema comprueba que al menos el primer nivel existe.
El sistema carga el nivel en la aplicacin.
El sistema muestra el primer nivel al usuario.

Extensiones (Flujo alternativo): Describimos el flujo alternativo:

o
o
o
o

1a Carga de nivel automtica por secuencialidad del juego.

1b Carga de nivel a demanda del usuario mediante un interfaz.
3a El fichero no existe en el sistema.
El sistema muestra el error y cierra el sistema.
4a El nivel no existe en el fichero.
El sistema muestra el error y cierra el sistema.

DESCRIPCIN CASO DE USO: Siguiente Nivel

Caso de uso: Siguiente Nivel

Descripcin: Muestra el nivel siguiente al cargado actualmente.
Actores: Usuario
Precondiciones: Deben de existir niveles cargados en el sistema.
Postcondiciones: El siguiente nivel ser mostrado en pantalla.
Escenario principal: Describimos el escenario principal:

1. El usuario demanda la carga del siguiente nivel.

2. El sistema comprueba que existe un siguiente nivel.
3. El sistema muestra el nivel al usuario.

Extensiones (Flujo alternativo): Describimos el flujo alternativo:

o 1a Carga de nivel automtica por secuencialidad del juego.
o 1b Carga de nivel a demanda del usuario mediante un interfaz.
o 2a El nivel no existe en el sistema.
El sistema muestra el error y no se avanza de nivel.
No funcional: El interfaz del usuario proporcinar dos botones de navegacin por los
niveles del fichero fcilmente identificables.

DESCRIPCIN CASO DE USO: Nivel Anterior

Caso de uso: Nivel Anterior

Descripcin: Muestra el nivel anterior al cargado actualmente.
Actores: Usuario
Precondiciones: Deben de existir niveles cargados en el sistema.
Postcondiciones: El nivel anterior ser mostrado en pantalla.
Escenario principal: Describimos el escenario principal:

1. El usuario demanda la carga del nivel anterior.

2. El sistema comprueba que existe un nivel anterior.
3. El sistema muestra el nivel al usuario.

Extensiones (Flujo alternativo): Describimos el flujo alternativo:

o 1a El nivel no existe en el sistema.
El sistema muestra el error y no se retrasa de nivel.

DESCRIPCIN CASO DE USO: Nuevo Nivel

Caso de uso: Nuevo Nivel

Descripcin: Crea un nivel nivel para ser editado.
Actores: Usuario
Precondiciones: Debe estar cargado el fichero de niveles.
Postcondiciones: Muestra un nivel vaco a editar por el usuario.
Escenario principal:Describimos el escenario principal:

1. El usuario demanda un nuevo nivel.

2. El sistema crea dicho nivel.
3. El sistema muestra el nivel al usuario.

Extensiones (Flujo alternativo):Describimos el flujo alternativo:

2a El nivel no se puede crear en el sistema.

El sistema muestra el error y no se contina.

DESCRIPCIN CASO DE USO: Editar Nivel

Caso de uso: Editar Nivel

Descripcin: Editamos un nivel de los disponibles en el sistema.
Actores: Usuario
Precondiciones: El nivel a editar debe estar cargado en el sistema.

Postcondiciones: Modificamos un determinado nivel.

Escenario principal: Describimos el escenario principal:

1. El usuario demanda editar un nivel.

2. El sistema prepara dicho nivel.
3. El usuario edita el nivel.

Extensiones (Flujo alternativo): Describimos el flujo alternativo:

o 2a El nivel no est disponible en el sistema.
El sistema muestra el error y se reinicia la aplicacin.
Cuestiones pendientes: Se debe guardar la modificacin del nivel para que est disponible
en otros escenarios.

DESCRIPCIN CASO DE USO: Guardar Nivel

Caso de uso: Guardar Nivel

Descripcin: Guarda el nivel que muestra el sistema en el fichero de niveles.
Actores: Usuario
Precondiciones: Debe de existir un nivel cargado que guardar.
Postcondiciones: Guarda el nivel en el fichero de niveles.
Escenario principal: Describimos el escenario principal:

1. El usuario demanda guardar un nivel.

2. El sistema guarda el nivel.
3. El sistema muestra el resultado de la operacin.

Extensiones (Flujo alternativo): Describimos el flujo alternativo:

o 3a El nivel no puede ser guardado.
o El sistema muestra el error.
o 3b El nivel es guardado.

1. El sistema muestra OK.

DESCRIPCIN CASO DE USO: Jugar

Caso de uso: Jugar

Descripcin: Nos permite interactuar con los niveles creados en el sistema.
Actores: Usuario
Precondiciones: Deben existir niveles en el sistema.
Postcondiciones: Se muestran los niveles y se nos permite interactuar con ellos
secuencialmente.
Escenario principal: Describimos el escenario principal:

1. El usuario demanda interactuar con el sistema.

2. El sistema carga un nivel.

3. El usuario interaca con el sistema.

Extensiones (Flujo alternativo): Describimos el flujo alternativo:

o 2a El nivel no puede ser cargado.

1. El sistema muestra el error y reinicia la aplicacin.

3a El usuario completa un nivel.

1. Se vuelve al paso 3 y se carga otro nivel.

*a El usuario decide teminar.

1. Se cierra la aplicacin.

No funcional: Se dispondr de un dispositivo de juegos para que el usuario pueda

interactuar con el sistema.

DESCRIPCIN CASO DE USO: Gestionar Niveles

Caso de uso: Gestionar Niveles

Descripcin: Gestiona el fichero de niveles del sistema.
Actores: Usuario
Precondiciones:
Postcondiciones: Realiza una operacin sobre el fichero de niveles.
Escenario principal: Describimos el escenario principal:

1. El usuario demanda una operacin con los niveles.

2. El sistema realiza la operacin.
3. El sistema muestra el resultado de la operacin.

Extensiones (Flujo alternativo): Describimos el flujo alternativo:

o 2a La operacin demandada es crear un nivel.

1. Incluir (Nuevo Nivel)

2b La operacin demandada es cargar un nivel.

1. Incluir (Cargar Nivel)

2c La operacin demandada es pasar de nivel.

1. Incluir (Siguiente Nivel)

2d La operacin demandada es volver a un nivel anterior.

1. Incluir (Nivel Anterior)

2e La operacin demandada es guardar un nivel.

1. Incluir (Guardar Nivel)

2f La operacin demandada es editar un nivel.

1. Incluir (Editar Nivel)

[editar] Modelo conceptual de datos en UML

El siguiente paso del anlisis de la aplicacin que estamos realizando es realizar el modelo
conceptual de datos. Este tipo de modelado sirve para especficiar los requisitos del sistema
y las relaciones estticas que existen entre ellos.
Para realizar este modelo se utiliza como herramienta los diagramas de clase. En estos
diagramas representamos las clases de objetos, las asociaciones entre dichas clases, los
atributos que componen las clases y las relaciones de integridad.

[editar] Conceptos bsicos

Vamos a presentar varios conceptos, que aunque ya los hemos utilizado en el tutorial, no
est dems recordarlos. El primero de ellos es el concepto de objeto. Un objeto no es ms
que una entidad que existe en el mundo real bien distinguible de las dems entidades. Un
ejemplo de objeto es un bolgrafo, una persona, una factura...
Los objetos de un mismo tipo se abstraen en clases. Estas clases describen a un conjunto de
objetos con las mismas propiedades, comportamientos comunes, con relaciones idnticas
con los otros objetos y una semntica comn.
Existen varios tipos de relaciones entre las distintas clases. Estas relaciones normalmente
tienen asociadas unas restricciones de participacin en dichas relaciones. Algunos ejemplos
de estos tipos de relaciones son las agregaciones, las composiciones, las generalizaciones...
El tema de las relaciones entre clases es un tema muy extenso e interesante en el que es
necesario que profundices para poder realizar un diseo de calidad.

[editar] Descripcin diagramas de clases conceptuales

En este punto debemos de tener claro qu clases vamos a necesitar para implementar
nuestro videojuego. Es el momento de presentarlas describiendo brevemente las
caractersticas de cada una de ellas para, posteriormente, realizar el diagrama de clases.

Imagen: Esta clase nos permite controlar todos los aspectos referentes a las imgenes
necesarias en la aplicacin.
Msica: Esta clase nos permite controlar la msica del videojuego.
Sonido: La clase sonido nos permite gestionar los sonidos del videojuego.
Fuente: Nos permite utilizar una fuente para rotular en la aplicacin.
Texto: Con esta clase creamos y controlamos los textos necesarios en la aplicacin.
Galera: La galera englobar todos los contenidos multimedia de la aplicacin. Ser la
encarga de gestionar todos los aspectos de este contenido, desde la inicializacin de los
elementos, hasta la utilizacin de stos por parte de las dems clases de la aplicacin.
Participante: Esta clase ser el interfaz de todos los participantes del juego. Nos permitir
realizar las actualizaciones lgicas y grficas de todos los elementos existentes en un nivel.
Protagonista: Subclase de Participante que nos permitir controlar los aspectos del
personaje principal del juego.
Item: Clase heredada de Participante que nos permite controlar los objetos e tems del
nivel y su comportamiento.
Enemigo: Clase hija de Participante que controla todos los aspectos de los enemigos.
Control Movimiento: Clase auxiliar que nos permite establecer un tipo de movimiento a
diferentes clases del sistema.
Control Animacin: Controla las animaciones internas de todos los elementos de la
aplicacin a partir de una rejilla de imgenes.
Control Juego: Lleva el control de la lgica y los elemetos del juego. Gestiona las colsiones
as como los elementos existentes en un determinado nivel, sus actualizaciones lgicas y
grficas.
Menu: Esta clase controla el men principal de la aplicacin y sus distintas opciones.
Juego: Esta clase controla los aspectos relevantes de la aplicacin en tiempo de juego.
Editor: Con esta clase controlaremos los aspectos relevantes de la edicin y gestin de
niveles.
Interfaz: Esta clase hace de interfaz entre las diferentes escenas de la aplicacin para la
navegacin de ellas que no son otras que Menu, Juego y Editor.
Nivel: Controla las propiedades y proporciona las capacidades para trabajar con niveles.
Ventana: Esta clase nos permitir mostrar slo una porcin adecuada de la superficie del
nivel
Universo: Es la clase principal que interrelaciona todos los aspectos del juego.
Teclado: Esta clase nos permite gestionar la entrada de teclado.
Apuntador: Con la clase Apuntador podremos utilizar el dispositivo de ratn en el editor
de niveles.

[editar] Diagrama de clases

Una vez descritas todas las clases y las relaciones entre ellas vamos a presentar los
diagramas de clases que nos van a permitir tener un mapa conceptual de la globalidad de la

aplicacin para afrontar su desarrollo. Vamos a presentar los diagramas por subconjuntos.
As podremos estudiar los detalles de cada uno de ellos. Para terminar incluiremos un
diagrama donde observar las relaciones entre todas las clases que intervendrn en la
aplicacin.
Para descomponer el diagrama hemos tomado el criterio de funcionalidad. Mostraremos
subconjuntos de clases que tengan un fin comn.
El primer subdiagrama que presentamos incluye a las clases que gestionarn los elementos
multimedia de la aplicacin. Podemos decir que la clase principal de este grupo es la clase
Galera que estar compuesta de las clases que estn asociadas a ella. El diagrama es el de
la figura.

Diagrama de clases: Componentes multimedia

En este diagrama se muestran siete clases. Como hemos comentado Galera es la clase que
gestiona a las dems.
El segundo diagrama que presentamos relaciona a las clases que nos permiten crear y
modificar niveles en la aplicacin. En este caso la clase que permite relacionar a las dems
componentes del diagrama es la clase Universo aunque la que contendr toda la lgica para
realizar esta tarea es la clase Editor.

Diagrama de clases: Editando niveles

El tercer diagrama que vamos a estudiar engloba las clases que estn asociadas
directamente con la clase Participante que recoge todos los elementos activos que
participan en los niveles del juego.

Diagrama de clases: Participantes

Ahora vamos a estudiar uno de los diagramas de clases ms importantes del anlisis. Se
trata de la clase Universo encargada de relacionar las clases del videojuego, los elementos
de control y los elementos multimedia que representa a cada una de estas partes.

Diagrama de clases: Universo

Para terminar con este apartado vamos a presentar el diagrama de clases que relaciona
todos los dems diagramas. Al ser excesivamenete grande no vamos a detallar cada uno de
sus componentes ya que esta tarea la realizamos en los anteriores diagramas.

Diagrama de clases: Diagrama Global

[editar] Modelo de comportamiento del sistema

El modelo del comportamiento especifica cmo debe de actuar un sistema. El sistema a
considerar es el que engloba a todos los objetos. Este modelo consta de dos partes. La
primera es el diagrama de secuencia de sistema que nos muestra la secuencia de eventos
entre los actores y el sistema. La segunda parte de este modelo est compuesta por los
contratos de las operaciones del sistema que efecto que deben producir las operaciones del
sistema.

[editar] Diagramas de secuencia del sistema y los Contratos de operaciones

Una vez descrito un caso de uso representamos mediante un diagrama de secuencia del
sistema dicho caso de uso. Este diagrama nos servir de aproximacin visual a los casos de
uso como complemento a la descripcin anterior.
La principal utilidad y objetivo de este diagrama es permitirnos identificar las operaciones
y eventos del sistema. El punto de partida de estos diagramas son los casos de uso que nos
permiten identificar qu eventos son los que van de los actores hacia el sistema. Tendremos
que definir un diagrama de secuencia para cada escenario relevante de un caso de uso. Para
identificar estos escenarios en el sistema nos centraremos en los eventos que genera el
usuario que hace uso de dicho sistema y que espera alguna operacin como respuesta de
dicha interaccin.
La segunda parte del modelo es la realizacin de los contratos para las operaciones del
sistema. Estos contratos describen el efecto que deben producir las operaciones del sistema.
Las operaciones del sistema son operaciones internas que se ejecutan como respuestas a un
evento producido, normalmente, por un actor o usuario.
Los contratos tienen unas partes bien diferenciadas: nombre de la operacin,
responsabilidades, precondiciones, postcondiciones... que utilizaremos en forma de

plantilla. Construiremos contratos para operaciones complejas y para aquellas que no

quedan claras en el proceso de especificacin del sistema.

[editar] Diagramas de secuencia del sistema y Contratos de las operaciones

del sistema
A continuacin expondremos todos los diagramas de secuencia del sistema y los
correspondientes contratos de las operaciones del sistema.
DIAGRAMA DE SECUENCIA: Cargar Niveles

Diagrama de secuencia: Cargar Niveles

Contrato de las operaciones

Operacin: Cargar Niveles

Responsabilidades: Carga los niveles del juego en memoria principal. Primero comprueba
que existe el fichero de niveles y seguidamente que dicho fichero tenga algn nivel. De ser
as carga el primero de ellos. Si no existe el fichero o est vaco se muestra el error y se
cierra la aplicacin.
Precondiciones: Debe de existir un fichero de niveles. Se debe de solicitar la carga de los
niveles explcita o implcitamente asociado a alguna accin del usuario.
Postcondiciones:
o Carga en memoria principal el primer nivel de la coleccin almacenada en el
fichero de niveles.

Si no existe el fichero de niveles muestra un mensaje de error y termina la

aplicacin.

Operacin: Muestra Nivel

Responsabilidades: Mostrar en pantalla el nivel actual de la aplicacin. Si no existiese
dicho nivel se muestra el error y se cierra la aplicacin.
Precondiciones: El nivel a mostrar debe estar cargado en memoria principal.
Postcondiciones:
o Carga en memoria principal el primer nivel de la coleccin almacenada en el
fichero de niveles.
o Si no hay nivel que mostrar se muestra un mensaje de error y se sale de la
aplicacin.

DIAGRAMA DE SECUENCIA: Siguiente Nivel

Diagrama de secuencia: Siguiente Nivel

Contrato de las operaciones

Operacin: Carga Nivel Siguiente

Responsabilidades: Cargar el siguiente nivel al actual. En caso de no existir el siguiente
nivel no realiza accin alguna.
Precondiciones: Debe de existir un nivel cargado.
Postcondiciones:
o Prepara el siguiente nivel disponible para ser mostrado.
o En caso no existir no realiza ninguna accin.

Operacin: Muestra Nivel

Responsabilidades: Mostrar en pantalla el nivel actual de la aplicacin. Si no existiese
dicho nivel se muestra el error y se cierra la aplicacin.
Precondiciones: El nivel a mostrar debe estar cargado en memoria principal.
Postcondiciones:
o Carga en memoria principal el primer nivel de la coleccin almacenada en el
fichero de niveles.
o Si no hay nivel que mostrar se muestra un mensaje de error y se sale de la
aplicacin.

DIAGRAMA DE SECUENCIA: Nivel Anterior

Diagrama de secuencia: Nivel Anterior

Contrato de las operaciones

Operacin: Carga Nivel Anterior

Responsabilidades: Cargar el siguiente anterior al actual. En caso de no existir el siguiente
nivel no realiza accin alguna.
Precondiciones: Debe de existir un nivel cargado.
Postcondiciones:
o Prepara el nivel anterior disponible para ser mostrado.
o En caso no existir no realiza ninguna accin.
Operacin: Muestra Nivel
Responsabilidades: Mostrar en pantalla el nivel actual de la aplicacin. Si no existiese
dicho nivel se muestra el error y se cierra la aplicacin.
Precondiciones: El nivel a mostrar debe estar cargado en memoria principal.
Postcondiciones:

o
o

Carga en memoria principal el primer nivel de la coleccin almacenada en el

fichero de niveles.
Si no hay nivel que mostrar se muestra un mensaje de error y se sale de la
aplicacin.

DIAGRAMA DE SECUENCIA: Nuevo Nivel

Diagrama de secuencia: Nuevo Nivel

Contrato de las operaciones

Operacin: Crea un Nivel Nuevo

Responsabilidades: Crear un nivel nuevo al final del a lista de niveles. En caso de no poder
alojar el nivel mostrar un mensaje de error.
Precondiciones: Debe de existir el fichero de niveles.
Postcondiciones:
o Prepara un nivel vaco para ser mostrado y editado.
o Si no se puede preparar dicho nivel se muestra un mensaje de error.
Operacin: Muestra Nivel
Responsabilidades: Mostrar en pantalla el nivel actual de la aplicacin. Si no existiese
dicho nivel se muestra el error y se cierra la aplicacin.
Precondiciones: El nivel a mostrar debe estar cargado en memoria principal.
Postcondiciones:
o Carga en memoria principal el primer nivel de la coleccin almacenada en el
fichero de niveles.
o Si no hay nivel que mostrar se muestra un mensaje de error y se sale de la
aplicacin.

DIAGRAMA DE SECUENCIA: Editar Nivel

Diagrama de secuencia: Editar Nivel

Contrato de las operaciones

Operacin: Editar Nivel

Responsabilidades: Prepara un nivel para ser editado y muestra el interfaz.
Precondiciones:
Postcondiciones: En caso de no existir el fichero de niveles se crea.

DIAGRAMA DE SECUENCIA: Guardar Nivel

Diagrama de secuencia: Guardar Nivel

Contrato de las operaciones

Operacin: Guarda el Nivel

Responsabilidades: Guardar el nivel actual en el fichero de niveles. En caso de no poder
guardarlo muestra el error.
Precondiciones: Debe de existir un nivel cargado en memoria que guardar.
Postcondiciones:
o Guarda el nivel en el fichero de niveles.
o En caso de no poder realizar la accin el sistema muestra un mensaje.

DIAGRAMA DE SECUENCIA: Jugar

Diagrama de secuencia: Jugar

Contrato de las operaciones

Operacin: Jugar
Responsabilidades: Prepara el sistema, los niveles y la lgica del juego para una partida.
En caso de no poder realizar alguna de las operaciones muestra un mensaje de error y
termina la aplicacin.
Precondiciones: Deben de existir niveles en el fichero de niveles. Dicho fichero debe existir
tambin. Se debe demandar la accin de jugar.
Postcondiciones:
o Devuelve el sistema preparado para jugar.
o En caso de error muestra un mensaje y cierra la aplicacin.
Operacin: Juega
Responsabilidades: Devolver el control al usuario para que pueda interactuar con la
aplicacin.
Precondiciones: El sistema debe de haber sido preparado para que el usuario interacte
con la aplicacin.
Postcondiciones: Pasa el control de la aplicacin al usuario.

DIAGRAMA DE SECUENCIA: Gestionar Niveles

Diagrama de secuencia: Gestionar Niveles

Contrato de las operaciones

Operacin: Solicitar Nivel

Responsabilidades: Solicitar al sistema una determinada accin sobre un nivel.
Precondiciones: El nivel solicitado debe de existir.
Postcondiciones: El sistema recibe la peticin del usuario.

Operacin: Resultado de la accin.

Responsabilidades: Debe de devolver al usuario el resultado de la accin previamente
solicitada.
Precondiciones: Debe de existir una accin solicitada al sistema sobre un nivel.
Postcondiciones: Dependiendo del resultado de la accin
o Devuelve al usuario un mensaje con el resultado de la accin.
o Devuelve un nivel determinado a otro proceso de usuario.