No sabemos si debemos introducir alguna funcionalidad más. Esto se debe a que como pusimos hace poco, podríamos traducir el juego y añadir un temporizador. Ahora hemos quedado para hablarlo. Cuando terminemos subiremos lo que vamos a hacer.
Un saludo a todos.
viernes, 16 de enero de 2009
jueves, 15 de enero de 2009
Puntos de variación de nuestro diagrama
Hemos estado haciendo el diagrama de paquetes, y ahora toca hacer los puntos de variación que hemos contemplado, la cohesión y el acoplamiento.
El paquete GUI está conectado con un paquete de la lógica de aplicación, como es lógico, en concreto con JUEGO. Tiene una alta cohesión ya que solo tiene como función presentar las interfaces de usuario.
El paquete CLUEDO tiene también una alta cohesión y un bajo acoplamiento, ya que está conectado con 3 paquetes; JUEGO, CARD y BOARD.
El paquete JUEGO tiene una cohesión muy alta y está conectado con el paquete PLAYER.
El paquete BOARD también tiene mucha cohesión, se dedica a la disposición de las casillas en el tablero donde se desarrolla la partida. Está acoplado con Database, para poder utilizar nuevos tableros, por ejemplo, cambiar los nombres de habitaciones. Esto último es un punto de variación que se ha considerado, ya que en un futuro tendremos la posibilidad de añadir nuevas habitaciones.
El paquete CARD tiene también alta cohesión. Y al igual que el paquete BOARD, está acoplado solamente con Database, lo que consideramos como punto de variación, ya que en un futuro también se podrá cambiar el nombre de los personajes, las armas y las habitaciones, como hemos dicho anteriormente.
El paquete Database, tiene también una alta cohesión y un bajo acoplamiento, y se encarga de hacer la conexión con la base de datos, Independientemente de cuál sea esta. Por ello presenta una alta cohesión.
El paquete JDBC es el encargado de la conexión con la base de datos, y tiene mucha conexión y un bajo acoplamiento porque solo se conecta con la base de datos.
El paquete GUI está conectado con un paquete de la lógica de aplicación, como es lógico, en concreto con JUEGO. Tiene una alta cohesión ya que solo tiene como función presentar las interfaces de usuario.
El paquete CLUEDO tiene también una alta cohesión y un bajo acoplamiento, ya que está conectado con 3 paquetes; JUEGO, CARD y BOARD.
El paquete JUEGO tiene una cohesión muy alta y está conectado con el paquete PLAYER.
El paquete BOARD también tiene mucha cohesión, se dedica a la disposición de las casillas en el tablero donde se desarrolla la partida. Está acoplado con Database, para poder utilizar nuevos tableros, por ejemplo, cambiar los nombres de habitaciones. Esto último es un punto de variación que se ha considerado, ya que en un futuro tendremos la posibilidad de añadir nuevas habitaciones.
El paquete CARD tiene también alta cohesión. Y al igual que el paquete BOARD, está acoplado solamente con Database, lo que consideramos como punto de variación, ya que en un futuro también se podrá cambiar el nombre de los personajes, las armas y las habitaciones, como hemos dicho anteriormente.
El paquete Database, tiene también una alta cohesión y un bajo acoplamiento, y se encarga de hacer la conexión con la base de datos, Independientemente de cuál sea esta. Por ello presenta una alta cohesión.
El paquete JDBC es el encargado de la conexión con la base de datos, y tiene mucha conexión y un bajo acoplamiento porque solo se conecta con la base de datos.
miércoles, 14 de enero de 2009
Utilización de un patrón Fachada
Después de llevar un tiempo haciendo el trabajo, y si nos merece la pena incluir lo de poder modficar los nombres de las habitaciones y los nombres de las cartas mediante la conexión a una base de datos, hemos decidido dejarlo con esta Base de datos, para que en un futuro podamos añadir lo ya expuesto.
Por tanto, necesitamos un patrón Fachada para poder proteger al sistema de la inclusión de una base de datos.
Un saludo a todos.
Por tanto, necesitamos un patrón Fachada para poder proteger al sistema de la inclusión de una base de datos.
Un saludo a todos.
Sopesando ideas nuevas
Estamos sopesando introducir algunas variaciones, ya que hemos pensado introducir la traducción del texto de la aplicación y la inclusión de un temporizador para controlar el tiempo de la partida, y si llega a cierto tiempo pues que la partida acabe. Esa es una idea que todavía está en desarrollo y que no es seguro que se realize.
martes, 13 de enero de 2009
Diagrama de clases
Hemos eliminado algunas redundancias en los métodos de las diferentes clases, y además hemos suprimido algunos métodos.
Os enseño el nuevo diagrama de clases
lunes, 12 de enero de 2009
Avanzando mas.
Ya podemos mostraros los diagramas de clases de cada paquete.
Paquete BOARD, JUEGO, CARD, MAZO.
sábado, 10 de enero de 2009
nos queda hacer el modelo dinámico
bueno, una de las cosas que nos quedan por hacer es el modelo dinámico.
Suscribirse a:
Entradas (Atom)