Modelo UML diagrama de clases del Juego de cartas UNO

Buenas noches comunidad

En la entrada de hoy mi compañero Manuel Cepeda y yo Andrés Murcia, vamos a empezar con un nuevo proyecto propuesto para la materia .NET + SQL, en esta oportunidad vamos a mostrarles como se haría un juego de cartas llamado UNO; antes de empezar a modelar necesitamos saber las reglas del juego, debemos saber que este juego se compone de 108 cartas, pero vamos a trabajar con 104 no vamos a tener en cuenta los 4 comodines de cambio de color + roba 4, la baraja se compone de 19 cartas con numeros del 0 al 9 azules, igualmente amarillas, verdes y rojas, hay también 8 cartas especiales roba+2, dos de cada color, 8 cartas especiales cambia de sentido dos de cada color, 8 cartas especiales pierde el turno dos de cada color, 4 cartas especiales comidín cambio de color, y 4 cartas especiales comodín cambio de color + roba 4 "estas ultimas no las vamos a tener en cuenta"; Bastaría con leerse un breve manual de instrucciones para saber las reglas del juego pero mas adelante nosotros las modelaremos para ustedes y validaremos en programación que el juego cumpla estas reglas; Inicialmente y para esta entrada vamos a mostrarles como hariamos el modelo UML, para ello vamos a usar starUML, este software es facil de encontrar en la web, le damos descargar y al abrirlo comprobamos que quedo instalado correctamente…

Desde aca le especificamos el nombre y la ruta en la que queremos guardar nuestro proyecto de diagrama de clases, le damos defualt aproach for UML aceptamos y en el siguiente entorno empezamos a trabajar.

Aca vemos que tenemos una barra de herramientas en la parte izquierda la cual tiene todos los elementos que necesitaremos para trabajar  nuestro diagrama de clases, vamos a esta barra de herramientas y agregamos las respectivas clases, vamos a crear una clase jugador que  tiene el siguientes atributo o característica, a nuestra forma de verlo, un alias de tipo string y que la denotamos con un (-) que quiere decir que va ser una caracteristica privada solamente del jugador, en esta misma clase en sus acciones que las vamos a definir por fuera de la clase exactamente en la flecha de asociación directa de clases la definimos como acciones concretas con un (-) debido a su privacidad de clase a clase, tenemos las cartas del jugador en una lista dinamica, debido a que el jugador puede elegir cualquiera de las cartas que tiene en su posesión para jugarla en su turno y va a ir relacionada con la clase abstracta principal a nuestra forma de verlo llamada carta veamos esta relación en la siguiente imagen de lo que les describimos arriba.

En esta imagen podemos ver un asterístico este representa que las cartas del jugador pueden variar de 0 a muchas cartas, entonces como esta cantidad pueden variar dependiendo de las penalizaciones entonces se simboliza con un (*). La clase que a continuación definimos es Carta que ya la había mencionado antes esta es abstracta como se ve en la anterior figura, sus atributos los hereda de otras clases por lo que no tiene definido atributos propios dentro de la clase. Veamos a continuación otra clase llamada Mazo, este debe tener 104 cartas y es una lista ordenada inicialmente pero ramdomica despues de ser barajada, esta se comporta como pila (LIFO) quiere decir que las ultimas que entran son las primeras en salir, ya que uno va tomando la carta de arriba del mazo la ultima en entrar. Veamos la siguiente imagen de la clase Mazo y como va relacionada con la clase pote. Que es una relación de dependencia el pote depende del mazo por esto va en lineas punteadas.

 Tenemos otra clase llamada pote que se ve en la figura, esta tiene como atributo o característica validar_secuencia(); ya que sobre este se va a desarrollar el juego entonces necesita validar que lo que se este jugando coincida por así decirlo con las reglas del UNO. y tenemos entre sus acciones de clase a clase la de cartas pote que es una lista tipo LIFO también ya que la última carta que quedo boca arriba es la primera para seguir la secuencia. Veamos ahora que el patrón solitario o singleton entran en acción desde una clase llamada Partida hasta la clase Pote y hasta la clase Mazo, la clase Partida se va a encargar de almacenar los turnos quien gano la parida "Alguno de los Alias" se encarga de recoger los datos y almacenarlos. los datos que se consideren necesarios.

Tenemos aca otras dos clases llamadas respectivamente CartaNumero y CartaComodín para CartaNumero vamos a definirle un atributo que va ser el numero de tipo entero "int" del 0 al 9 y privado para dicha clase (-) para CartaComodín no le vamos a definir atributos internamente pera esta va a ir asociada a otra clase llamada ComodinUNO por el momento vemas la imagen de las respectivas clases y como van asociadas por medio de una generalización hacia la clase Carta.

La siguiente clase la vamos a llamar ComodinUNO y va ser de tipo <<enum>> esta clase tiene como atributos las cartas comodín del UNO sea que tiene el mas 2, el Cambio de Sentido, el Salto de Turno y el Cambio de Color este va a ir relacionado con la clase CartaComidin por medio de una asociacion desde CartaComodín "#tipoComodin" hasta ComodinUNO veamos la figura para hacernos a la idea.

Listos ya estan todos nuestras clases definidas e implementadas en el diagrama de clases, despues de haberlas descritas todas y una por una, vamos a mostrar nuestro módelo de diagrama de clase con todas las relaciones que existen entra cada clase veamos el modelo completo

En nuestro diagrama de clase UML encontramos notas que son las que estan como en una especie de rectanguno o cuadrado con una pestaña doblada, en la parte superior derecha, estas nostas no son clases, pero nos ayudan a entender mejor nuestro modelo y tienen un NoteLink que siempre va desde la clase hasta la nota, estas notas nos dan información adicional de las acciones que deben cumplir dichas clases, tambien nos dicen que esta pendiente por implementar como en el caso de la clase CartaComodín que sabemos que necesitamos implementar el conrtrolador en esta instancia pero esto va ser programado en C# y por lo tanto va ser demostrado hasta entonces, tambien tenemos notas de tipo informativas como la que esta en la esquina superior derecha, nos habla de la multiplexación de las relaciones que existen entre clases de muchas cartas del jugador a muchas cartas del juego, o de una carta del jugador a muchas cartas del juego etc. Este es nuestro modelo UML de diagrama de clases corregido y analizado clase por clase para asegurarnos que se cumplan con las reglas del negocio o reglas del juego, espero este modelo les sea útil y con base en este vamos a seguir con las siguientes etapas de programación  implementación web e implementación de base de datos. 

"Solo triunfa en el mundo quien se levanta y busba a las circunstancias, creándolas si no las encuentra".
George Bernard Shaw