miércoles, 11 de junio de 2008

Ejemplo de Modelado con UML

Hola, veremos a continuación un sencillo ejemplo para implementar el modelado de requerimientos con UML, para esto tenemos los siguientes pasos:

• Descripción del problema
• Identificación de requisitos.
• Casos de uso.
• Conclusiones.


Comencemos,


Descripción del problema
  • Sokoban es un juego de varios niveles.
  • Cada nivel está compuesto por un jugador, cajas, repisas y muros.
  • El objetivo del jugador es empujar todas las cajas sobre las repisas.
  • Cuando esto sucede el jugador pasa al siguiente nivel.
  • Para mover una caja, el jugador debe colocarse al lado y empujarla. Si la casilla hacia la que está empujando la caja está libre la caja se moverá.
  • Si el jugador se queda bloqueado, es decir, no puede terminar el nivel, puede reiniciar el nivel perdiendo una vida.
  • Cuando el jugador pierde todas sus vidas la partida termina.


Identificación de requisitos

Una mini entrevista
¿Qué debe hacer el sistema (o tiene que tener) para implementar la descripción?

Requisitos:
• El sistema debe permitir comenzar una nueva partida y terminarla.
• El sistema debe permitir mover al jugador, a las cajas y reiniciar el nivel cuando
el usuario lo solicite.
• El sistema deberá almacenar varios niveles y cambiar de nivel cuando el usuario
complete el nivel actual.


Casos de uso

Los casos de uso son una respuesta,

¿Cómo puede un usuario jugar una partida de sokoban?

La primera pregunta que vamos a resolver:


¿cuántos actores tiene el sistema?

Un único actor:

  • ­ Persona humana que controla al jugador
  • ­ Su meta es jugar una partida de Sokoban

La segunda pregunta que vamos a resolver:

¿qué casos de uso necesitamos?



A continuación debemos completar la documentación de estos Casos de Uso, para esto existen las fichas de Casos de Uso, las que cumplen con el estandar de documentación de Casos de Uso:








Conclusiones

¿Cambiar de nivel es un caso de uso?
• No, porque sólo participa el sistema, no participa ningún actor externo.
• La única manera que un actor externo tiene de cambiar de nivel es mediante los movimientos (caso de uso 2)

¿Cargar un nivel es un caso de uso?
• No, porque sólo interviene el sistema.
• Además, cuando detallamos como cargar un nivel estamos detallando el sistema (queda fuera de la fase de requisitos).

¿Terminar la partida es un caso de uso?
• Como está redactado en el enunciado la respuesta es no.

¿Faltan casos de uso o están incompletos?
1. El sistema debe permitir comenzar una nueva partida y terminarla.

2. El sistema debe permitir mover al jugador y a las cajas y reiniciar el nivel cuando el usuario lo solicite.

3. El sistema deberá almacenar varios niveles y cambiar de nivel cuando el usuario complete el nivel actual

Los tres requisitos anteriores son los que definimos al principio, en la siguiente ficha vemos que los casos de uso cumplen con lo requerido.


Esta es una forma de comprobar que con los casos de uso definidos tenemos satisfechos los requerimientos.

Saludos y suerte !!

1 comentario:

Antonio De Jesus Vargas Rios dijo...

Muchas gracias me ha sido de mucha utilidad, ojala puedas explicarnos los otros tipos de diagramas