• Mover representa el movimiento seleccionado por un jugador; por lo tanto, mantiene el contador siendo jugado y la ubicación para colocar el contador. • El mostrador tiene una etiqueta que indica X u O. Ahora podemos actualizar el diagrama de clases con datos y enlaces entre las clases: En este punto, parece que HumanPlayer y ComputerPlayer las clases son innecesarias ya que no contienen ningún dato propio. Sin embargo, en este caso de que el comportamiento de HumanPlayer y ComputerPlayer sea bastante diferente. La clase HumanPlayer le pedirá al usuario humano que seleccione el próximo movimiento. En contraste, la clase ComputerPlayer debe implementar un algoritmo que permitir que se genere el siguiente movimiento dentro del programa. Otros aspectos conductuales de las clases son: • Juego esto debe contener la lógica general del juego. También debe poder seleccionar qué jugador irá primero. También permitiremos que el jugador humano seleccione qué ficha con la que jugarán (X u O). Esta lógica también se ubicará dentro de la Clase de juego. • Tablero La clase Tablero debe permitir realizar un movimiento, pero también debe poder para verificar que un movimiento es legal (ya que la celda está vacía) y si un juego ha sido ganado o si hay un empate. Esta última lógica podría ubicarse dentro de la juego en su lugar; sin embargo, la Junta tiene los datos necesarios para determinar una victoria o un empate y así vamos ubicando la lógica con los datos. Ahora podemos agregar los aspectos de comportamiento de las clases al diagrama. Tenga en cuenta que han seguido la convención aquí para separar los datos y el comportamiento en diferentes diferentes áreas dentro de un cuadro de clase: 37.2 Clases en el juego 425