~Presentación Proyecto Final

*Proyecto Final

~Ligas de Entradas de Puntos Extra

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3 


*Ligas Puntos Extra


- Casos de Sistema Fallidos
- Metodologías de análisis y Diseño de Software
- Patrones de Diseño
- Casos de Uso
- Diagramas UML
- Diagrama de clases Umbrello
- Conceptos
- Interfaz Gráfica de Usuario
- Diagramas de Secuencia
- Diseño de Pruebas Unitarias
- Anti patrones
- Sistemas Distribuidos
- Eventos, Errores y Excepciones

~Eventos, Errores y Excepciones - PUNTOS EXTRA

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3

~Sistemas Distribuidos - PUNTOS EXTRA

Materia: Programación Orientada a Objetos 


Hora: Jueves m1 - m3 




*Sistemas Distribuidos


Se puede decir que un sistema distribuido es una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida; cada máquina tiene componentes de hardware y software que el usuario percibe como un solo sistema. El usuario accede a los recursos remotos (RPC) de la misma manera en que accede a recursos locales, o un grupo de computadores que usan un software para conseguir un objetivo en común.

Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones. Para que la compartición de recursos sea efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente.

Los sistemas distribuidos cumplen las siguientes características:

* Los interfaces software clave del sistema están claramente especificados y se ponen a disposición de los desarrolladores. 

* Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo uniforme de comunicación entre procesos e interfaces publicados para acceder a recursos compartidos.

* Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogéneo, posiblemente proveniente de vendedores diferentes. 

En un sistema distribuido que está basado en el modelo de compartición de recursos, la posibilidad de ejecución paralela ocurre por dos razones:

1.- Muchos usuarios interactúan simultáneamente con programas de aplicación. 

2.- Muchos procesos servidores se ejecutan concurrentemente, cada uno respondiendo a diferentes peticiones de los procesos clientes.

Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La escala más pequeña consiste en dos estaciones de trabajo y un servidor de ficheros, mientras que un sistema distribuido construido alrededor de una red de área local simple podría contener varios cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresión y otros servidores de propósito específico.

Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios.

La transparencia se define como la ocultación al usuario y al programador de aplicaciones de la separación de los componentes de un sistema distribuido, de manera que el sistema se percibe como un todo, en vez de una colección de componentes independientes.

* Ventajas

- Procesadores más poderosos y a menos costos
- Avances en la Tecnología de Comunicaciones. 

- Compartición de Recursos. 

- Eficiencia y Flexibilidad.
- Disponibilidad y Confiabilidad.
- Crecimiento Modular.

*Desventajas

- Requerimientos de mayores controles de procesamiento.
- Velocidad de propagación de información (es lenta a veces).
- Servicios de replicación de datos y servicios con posibilidades de fallas.
- Mayores controles de acceso y proceso (Commit).
- Administración más compleja.
- Costos.

* Bibliografia: 

- http://sistemas.itlp.edu.mx/tutoriales/sistsdist1/u1parte2.htm

- http://sistemas-distribuidos-unerg.blogspot.com/2008/10/caractersticas-principales-de-los.html

~Antipatrones - PUNTOS EXTRA

Materia: Programación Orientada a Objetos

Hora: Jueves m1 - m3


*Anti patrones

En desarrollo de software un antipatrón es una mala práctica, que aunque puede solucionar un problema en nuestra aplicación, también puede generar problemas de mantenimiento, diseño o comportamiento en el software.

Se puede decir que un antipatrón es, como su nombre lo indica, lo opuesto a un patrón de diseño, sin embargo el saber identificar esosbad smells en nuestros proyectos se considera una buena práctica, ya que así podremos implementar una mejor solución y hacer más eficientes nuestras aplicaciones.

Algunos ejemplos de anti patrones son:

*God - Objetc: es también conocido como The Blob, Winnebago o monster object. El Objeto todo poderoso es un objeto que hace mucho más de lo que debería osea no cumple con el principio de única responsabilidad, crece de manera descontrolada (como the blob) y se encarga de tantas cosas diferentes que todo el sistema termina dependiendo de él.

Este tipo de anti patrón es malo porque:

- Lo primero es que una clase tan grande seguramente será muy difícil de testear y de mantener debido a su complejidad.

- Una clase con tantas responsabilidades no será reusable en ningún otro proyecto.

- Clases muy grandes pueden cargar mucha información innecesaria en memoria degradando el rendimiento de nuestra aplicación.

Un god object no permite usar de buena manera los principios de orientación a objetos, por tanto no es fácil realizar cambios en la implementación de las clases sin afectar la funcionalidad de la aplicación.

Para saber si tienes clases con God- Objetc tienes que checar los siguientes puntos:

- Cuando encuentren una clase con muchos atributos o muchas operaciones o ambas. Una clase con más de 60 atributos y operaciones habitualmente es un god object.

- Atributos y operaciones diversas y sin conexión lógica entre ellas contenidas en una misma clase, una falta de cohesión de los atributos y operaciones es otro síntoma del God-Object.

- Una ausencia de un diseño orientado a objetos, una única clase que se encarga de controlar y encapsular toda la funcionalidad de la aplicación es más un diseñoprocedimental que orientado a objetos.
* Lava Flow o Dead Code aparece principalmente en aquellos sistemas que comenzaron como investigación o pruebas de concepto y luego llegaron a producción. La principal característica de este anti patrón es la presencia de distintos flujos o corrientes de previos desarrollos que quedaron diseminados, y se hicieron inservibles. Estos desarrollos anteriores (a modo de investigación) a menudo probaban distintos enfoques para resolver distintos problemas, usualmente apresurados para entregar a término para una demostración, omitiendo documentación.

* Poltergeists, o Gipsy, o Proliferation of Classes, o Big DoIt Controller Class. Las clases poltergeists (fantasmas) se caracterizan por tener pocas responsabilidades dentro del sistema y un ciclo de vida bastante breve, ya que “aparecen” solamente para iniciar algún método en alguna clase, a menudo en un determinado orden. Son de relativa facilidad de encuentro ya que sus nombres suelen llevar el sufijo “controller” o “manager”. Estas clases desordenan el diseño ya que agregan abstracciones innecesarias, son excesivamente complejas, difíciles de mantener y comprender.

~Sistemas Distribuidos

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3

*La manera en la que tengo pensado distribuir mi juego es la siguiente: 


Quiero que mi juego sea en línea. Por lo pronto lo manejare solamente que sea jugador contra la computadora, ya que todavía no estoy pensando en poner la opción de que se pueda jugar entre usuarios, otra de las cosas que pensé para mi juego es que solamente se podrá utilizar en una computadora normal, una laptop o una iPad y esto lo pensé así porque para poder jugarlo se necesita que el juego aparezca un poco grande porque si no, no se podrán distinguir las palabras ni nada entonces por eso opte por que no se pueda jugar en celulares ya que tienen una pantalla muy pequeña y eso dificultará mucho la vista del juego. Tampoco se puede poner mi juego en consolas o algo por el estilo ya que como lo mencione para jugar fastwords se necesita un teclado y estas consolas no tienen los controles adecuados para llevar a cabo el juego entonces esa es otra opción descartada. 


Pero básicamente esta es la manera de distribuir mi juego. 

      

                      

~Diseño de Pruebas Unitarias - PUNTOS EXTRA

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3




*Prueba para Juego de Corazones

~Diseño de Pruebas Unitarias

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3




*Estas son algunas Pruebas sobre mi proyecto:

~Patrones de Diseño

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3 






*Los patrones de diseño que yo pienso que pudieran quedar con mi proyecto son: 


- Decorador: yo pienso que puedo utilizar este patrón de diseño en mi proyecto ya que necesito que los objetos de mis interfaces realicen sus funciones asignadas.


- Observador: este es otro patrón de diseño que pienso que podría utilizar en mi proyecto ya que varios de los objetos de mis interfaces necesitan que algunos objetos terminen sus funciones para que los otros realicen las que les corresponden. 

~Eventos, Errores y Excepciones

Materia: Programación Orientada a Objetos


Hora: Jueves m1- m3 


*Estos son los eventos, errores y excepciones de mi proyecto.

~Interfaces del Proyecto

Materia: Programación Orientada a Objeto


Hora: Jueves m1 - m3 




*Estas son las interfaces de mi Proyecto del juego del Basta.

~Diagramas de Secuencia

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3 


*Estos son los diagramas de secuencia de mi proyecto: 

     

~Diagramas de Secuencia - PUNTOS EXTRA

Materia: Programación Orientada a Objetos 


Hora: Jueves m1 - m3 




- Estos son los Diagramas de Secuencia que mi equipo y yo realizamos durante la clase.

~ Interfaz gráfica de usuario - PUNTOS EXTRA

Materia: Programación Orientada a Objetos 


Hora: Jueves m1 - m3




- Estas son las interfaces que mi equipo y yo realizamos durante la clase.

      

~Diagrama de clases en Umbrello

Materia: Programación Orientada a Objetos

Hora: Jueves m1 - m3



*Este es mi Diagrama de Clases referente a mi proyecto.

~Herencia

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3


Como ya vimos la característica de la herencia en POO es uno de los mecanismos por medio del cual una clase se deriva de otra, llamada entonces clase padre de manera que extiende su funcionalidad. Y aplicando la herencia a mi proyecto en mi opinión obtuve unas clases hijas que son: 


* Clase Jugador 
- Clase Jugador Principiante (incluye 3 categorías)
- Clase Jugador Intermedio  (incluye 5 categorías)
- Clase Jugador Experto      (incluye 7 categorías)

~Documentación Técnica

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3 




* Importancia de la Documentación Técnica


Un aspecto muy importante en el desarrollo de los programas es su documentación, pero muchos programadores no hacen eta parte del desarrollo y con esto no se da cuenta que pierde la posibilidad de la re utilización de parte del programa en otras aplicaciones.


La documentación de un programa comienza al momento de estarlo desarrollando y finaliza antes de la entrega del programa ya que todo lo que vayas desarrollando del programa tienes que mencionarlo en tu documentación. 


La documentación que se entrega al cliente tendrá que coincidir con la versión final de los programas que componen la aplicación y una vez finalizado el programa los documentos que se deben entregar son : una guía técnica, una guía de uso y de instalación.


* Guía Técnica: en ella se encuentran el diseño del proyecto, la codificación de la aplicación y las pruebas realizadas para su correcto funcionamiento, su principal objetivo es facilitar el desarrollo, corrección y futuro mantenimiento del programa de una forma rápida y fácil.


* Guía de Uso: es llamado el manual de usuario y contiene la información necesaria para que los usuarios utilicen correctamente la aplicación, se expresa de forma que sea entendible para el usuario.


* Guía de Instalación: contiene la información necesaria para implementar el programa, dentro de este documento se encuentran las instrucciones para hacer funcionar el programa y las normas de utilización del mismo. En las normas de utilización se incluyen las normas de seguridad, tanto físicas como las referentes al acceso a la información.


Existen diferentes tipos de documentación que se le entrega al cliente y se divide en : 


* Documentación Interna: es la que se crea en el mismo código y puede ser en forma de comentarios o de archivos de información dentro de la aplicación.


* Documentación Externa: es la que se escribe en cuadernos o libros, es totalmente ajena a la aplicación en si, la ayuda electrónica forma parte de éste tipo de documentación. 






~Referencias:
* http://www.desarrolloweb.com/articulos/importancia-documentacion.html

~Conceptos - PUNTOS EXTRA

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3




* Significado de los siguientes conceptos:


- UML: Unified Modeling Language,es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.


- OMG: El Object Management Group, es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA. Es una organización sin ánimo de lucro que promueve el uso de tecnología orientada a objetos mediante guías y especificaciones para las mismas. El grupo está formado por diversas compañias y organizaciones con distintos privilegios dentro de la misma.


- OOSAD: Object-Oriented Systems Analysis and Design, que los modelos de enfoque de un sistema como un grupo de interacción de objetos . Cada objeto representa una entidad de interés en el sistema que se modela y se caracteriza por su clase, su estado (elementos de datos), y su comportamiento. Varios modelos se pueden crear para mostrar la estructura estática, comportamiento dinámico y en tiempo de ejecución el despliegue de estos objetos de colaboración. Hay una serie de notaciones diferentes para la representación de estos modelos, como el Lenguaje de Modelado Unificado (UML).



- OOSE: Object-Oriented Software Engineering ,es una técnica de diseño de software que se utiliza en el diseño de software de programación orientada a objetos. OOSE es la primera metodología orientada a objetos de diseño que emplea a los casos de uso en el diseño de software. OOSE es uno de los precursores del Lenguaje de Modelado Unificado (UML).


- OOP: Object Oriented Programming, es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y proo Programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.





~Referencias:
* http://es.wikipedia.org/wiki/Object_Management_Group
* http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
* http://cs-exhibitions.uni-klu.ac.at/index.php?id=448
* http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos
*http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design

*Retroalimentación

Materia: Programación Orientada a Objetos


Hora: Jueves m1 - m3



En la actividad de retroalimentación que realizamos en el salón, yo hable de mi proyecto con mi compañero Jorge Montano y el me comentó que realizará de proyecto un juego parecido al Brick Breaker el cual consiste en que el jugador debe romper ladrillos utilizando una pelota que rebota en una pequeña plataforma.

De las caracteristicas generales que tendrá su proyecto son que: El jugador tentra 3 vidas o bolas totales, por cada ladrillo que el jugador destruya recibirá 50 puntos, y el juego en total son 10 niveles, por cada nivel que el jugador avance recibirá una vida o bola extra.

A lo que platique con el su proyecto se escucha interesante, aunque sea un juego ya existente se que el hara que su proyecto sea original porque trae muchas ideas para cambiarlo y hacerlo diferente al clásico Brick Breaker que ya conocemos.

~Diagrama de clases en Umbrello - PUNTOS EXTRA

Materia: Programación Orientada a Objetos

Hora: Jueves m1 - m3


*Ejercicio

~Diagramas UML - PUNTOS EXTRA

Materia: Programación Orientada a Objetos 


Hora: Jueves m1 - m3

Se dice que UML es un lenguaje visual orientado al modelado de sistemas, facilita un vocabulario controlado con regla y símbolos para que todos los agentes de un proyecto eviten dispersión conceptual.

Las ventajas que tiene el utilizar Los Diagramas UML son:

1.Mejora nuestro nivel de comunicación formal.
2. Abordamos la complejidad con una documentación minimalista.
3. Desarrollamos procesos y productos con una mayor fiabilidad y calidad.
4. El impacto de nuestras decisiones sobre un proceso y producto es más visible.
5.Podemos definir, organizar y compartir el conocimiento más fácil.
6.Nuestro esfuerzo de especificación es más eficiente.
* Los Diagramas UML contienen lo siguiente:

• Tiene una gran variedad de unidades como clases, acciones, objetos, estados y casos de uso
• Tiene una gramática que define las reglas de combinación para formar otras unidades más complejas como diagramas y modelos.
• Tiene una determinada escala de abstracción y granularidad.

*  Los Diagramas UML nos sirven para:
-  Representar visualmente las reglas de creación, estructura y comportamiento de un grupo relacionado de objetos y procesos.
- Para visualizar de manera eficiente la complejidad de un sistema o una organización en un reducido número de diagramas.
- Para mantener mucho más ágilmente las especificaciones ante los cambios y nuevos enfoques de arquitectura.

Normalmente se utilizan los diagramas UML para:
1.Definir un problema que afecta a una organización.(Análisis)
2. Plantear una solución de diseño.(Abstracción).
3.Modelar procesos de negocio.(Optimización de flujos de trabajo).
4.Construir un producto de software.(Concreción de una abstracción).
5.Certificar la coherencia, completitud y usabilidad del producto.(Calidad).
6.Evaluar la arquitectura de una organización.(Conocimiento).

* Unidades básicas de UML
-Estructura: en ella se definen básicamente tipos de objetos (clases) con sus atributos que conocen sus responsabilidades y su nivel de visibilidad.
-Función: es donde se expresan acciones y procesos como resultado de la interacción de los objetos en un escenario acotado, y modelan la sucesión de estados que transcurren a lo largo del cliclo de vida de un objeto.
- Conectores: son los que definen las categorías de relación entre clases, objetos , acciones, procesos y estados entre todas las funciones de estructura y función.
Un diagrama UML tiene múltiples perspectivas y algunas de ellas son:
- Compartir conocimiento
- Definir reglas y responsabilidades
- Visualizar la complejidad
- Tomar decisiones
- Organizar la experiencia
- Arquitectura basada en modelos
- Vocabulario controlado

*Bibliografía: 

*https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIqjrIePc6flbb15zN2RC_ExTjkNn3WWF4uPOTePm4U7wWj55FBvq3KsOm_hmt8qF4rSLEuZWA7h0RFNqNHkjlB8MfKiOpkjpK5vBQuuo3uo23cH17Qqu4qBdULzNf1BM3miT3al6Ccig/s400/uml+2.jpg

*http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

*http://elvex.ugr.es/decsai/java/pdf/3E-UML.pdf

*http://www.monografias.com/trabajos67/diagramas-uml/diagramas-uml.shtml

~Casos de Uso

Materia: Programación Orienta a Objetos

Hora: Jueves m1 - m3

*El diagrama de Casos de Uso que diseñe para mi proyecto del Juego del Basta es :



~Clases, Atributos y Métodos

Materia: Programación Orientada  a Objetos


Hora: Jueves m1 - m3

-Definiciones :

* Clase: es una construcción que se utiliza como un modelo (o plantilla) para crear objetos. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Representa un sustantivo, como una persona, lugar o cosa.

* Atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

* Método: consiste generalmente de una serie de sentencias para llevar a cabo una acción, un juego de parámetros de entrada que regularán dicha acción y, posiblemente, un valor de salida (o valor de retorno) de algún tipo.

Ya con esto puedo sacar las clases, los atributos y los métodos de mi proyecto. Y lo que hice fue lo siguiente: 

* Proyecto : Basta 

- Clase (pública): Tablero.
* Esta clase se encarga de modificar todo lo referente al tablero.
- Atributos (privados): color, tamaño.

- Métodos (públicos): escribir,pausar juego.

-Clase (pública): Dado.
*Esta clase le proporciona al usuario la letra con la que realizará su juego.

-Atributos (privados):  forma, color, letra para jugar. 

-Métodos (públicos):  girar, detener.

-Clase (pública): Reloj.
*Esta clase se encarga de marcar el tiempo transcurrido del jugador.

-Atributos (privados):  color, forma, tamaño, formato de tiempo.

-Métodos (públicos):  iniciar, pausar, parar.

 

-Clase (pública): Jugador.
*Esta clase se encarga de que el usuario juegue  o salga del juego.

-Atributos (privados):  activo, desactivo,tipo(principiante, intermedio, experto).

-Métodos (públicos):  jugar, finalizar.

-Clase (pública) : Puntuación
*Esta clase se encarga de llevar un registro de los puntos hechos por el jugador.
-Atributos(privados): color, tamaño, forma, contenido, posición.
-Métodos(públicos): registrar, reiniciar, eliminar.





-Clase (pública) : Menú
*Esta clase se encarga de mostrarle al jugador algunas opciones del juego.
-Atributos(privados): color, tamaño, forma, contenido, posición.
-Métodos(públicos): ayudar, salir, iniciar juego.





-Clase (pública) : Perfil
*Esta clase se encarga de crear el perfil del jugador.
-Atributos(privados): color, tamaño, forma.
-Métodos(públicos): ingresar nombre, guardar puntuación.





-Clase (pública) : Dificultad 
*Esta clase se encarga de decirle al jugador que tipo de dificultad posee.
-Atributos(privados): tipo de dificultad, tamaño, forma. 
-Métodos(públicos): mostrar dificultad (depende del tipo de jugador).





-Clase (pública) : Categorías
*Esta clase se encarga de mostrarle al jugador las diferentes categorías que tendrá su juego.
-Atributos(privados): tipo de categoría, tamaño, forma, color, posición.
-Métodos(públicos): ver categorías (depende del tipo de jugador).










 * Bibliografía: 


* http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos


*http://es.wikipedia.org/wiki/Clase_(inform%C3%A1tica)


*http://es.wikipedia.org/wiki/M%C3%A9todo_(inform%C3%A1tica)

~Descripción del proyecto

Materia: Programación Orientada a Objetos

Hora: Jueves m1 - m3

Para mi proyecto final de la clase de Programación Orientada a Objetos lo que voy a hacer es un Basta electrónico, como ya todos sabemos el juego del basta consta en que alguien esta diciendo una letra, comienza diciendo A hasta que el jugador diga basta el que esta diciendo la letra le dice cual corresponde y el jugador empieza a anotar sus respuestas en las diferentes categorías que hay. Ya cuando termine de llenar todas sus categorías el jugador dice la palabra Basta indicando con esto que termino y los demás jugadores ya no pueden escribir mas respuestas.

Para dar la puntuación al momento de comparar las respuestas se checa que si la respuesta es igual se divide la puntuación en 50 y 50 ya que lo máximo es 100, si la respuesta es completamente diferente se dan 100 puntos a los 2 y si uno de los jugadores no contesto nada no se le dan puntos.

En mi Basta electrónico la dinámica va a ser un poco diferente ya que la letra se va a seleccionar dándole click a un dado y al momento que el dado de una letra el jugador le pica a tiempo para comenzar el juego, se empiezan a llenar las diferentes categorías y al momento que se termine el tiempo se muestran las respuestas de la computadora y se comparan con las del jugador. Hasta ahorita esta es la idea que tengo estoy viendo como poder hacerle para que diferentes usuarios jueguen unos contra otros en línea pero esto básicamente seria la idea de mi proyecto principal.

Aquí esta el link de un demo que encontré de un juego parecido al Basta que fue de donde saque la idea del dado y del tiempo y con esto esta un poquito mas clara la idea que tengo.

* Scattergories

~Casos de Uso - PUNTOS EXTRA

Materia : Programación Orientada a Objetos 

Hora: Jueves m1 - m3

* Diagramas de Casos de Uso :

* Buscaminas

* iTunes

* SIASE