A buscar M!nas: MSAccess - Requerimientos

Buenas!

Empezamos ya con la primera mejora para nuestro juego de M!nas. Esta mejora servirá como base para las próximas mejoras.

Tal como indiqué en la entrada anterior (en el índice), en esta entrada redactaré de forma textual los requerimientos de nuestra aplicación.

Para ello describiré la "aplicación ideal". Posteriormente extraeremos la información útil y la adaptaremos a un modelo E-R adaptado a un modelo local..

Empecemos, pues:

La idea es tener una aplicación con un sistema de base de datos.

La aplicación (el juego de las M!nas) enviará información diversa para registrarla.

Así, una ejecución normal del juego consistiría en:

• Se abre el ejecutable
• Un pop-up pide un modo de autenticación:
• Usuario y password
• Anónimo
• Crear cuenta
• Una vez entrado el modo de autenticación, se pide la dificultad y la opción.
• Se carga el juego
• Al finalizar el juego se envían estadísticas. Esto es
• Si ha ganado o perdido
• Tiempo transcurrido
• Dificultad
• Opción
• Usuario jugado
• Modo de autenticación
• Minas marcadas
• Número de clicks

Cada usuario será único. En caso de que el usuario sea anónimo, significa que no está registrado, y por tanto puede ser cualquiera (es decir, dos personas diferentes pueden usar los mismos datos).

De este modo, un usuario registrado tendrá un registro único de estadísticas, mientras que un usuario anónimo puede tener varios registros, estando en el mismo registro físico.

Para registrar un usuario hace falta un nick, un nombre, apellidos, correo electrónico y un password. Para un usuario anónimo se pedirá un nick.

Esta es la especificación de requerimientos, en un modo textual. De este texto se puede extraer toda la información necesaria para crear la base de datos. Toda la información ha sido destacada de la siguiente manera:

Los nombres de tablas están en azul y negrita
Los nombres de campos están en verde y negrita

Se puede apreciar a simple vista que el futuro modelo Entidad - Relación será pequeño. Pero esto no quiere decir que se pueda hacer a la ligera.

Tenemos que proceder siempre con cautela y cuidado, para intentar cometer siempre el mínimo número de errores.

Estas medidas pueden parecer inútiles y contraproducentes, pero es todo lo contrario; es preferible estar seis u ocho horas analizando un problema y luego dos horas programando que empezar a programar y luego parchear todo a base de debug. Además, el analizar las cosas nos proporciona una vista más amplia del problema y nos permite subdividirlo de manera que las funciones y clases que hagamos serán realmente útiles.

Después de esta pequeña reflexión, voy a preparar la siguiente entrada. De momento lo dejamos aquí.

¡Hasta la próxima!