Analisis Preliminar

Metodologia

Analisis Preliminar

Durante el análisis vamos a definir más claramente qué es lo que va a hacer nuestro programa. Debemos hacer varias cosas principalmente:
Identificar actores. En lenguaje UML, actores son los usuarios y cualesquiera otros sistemas con los que se pueda comunicar nuestro programa. En nuestro programa de ajedrez, un actor sería el usuario que va a jugar al ajedrez. Le llamaremos “jugador”. También se indicaba como requisito que pueda aprender aperturas. La persona que le va a enseñar aperturas a nuestro programa podría ser otro actor, al que podemos llamar “maestro”. Una misma persona puede ser varios actores. Por ejemplo si alguien compra nuestro programa de ajedrez, a veces puede jugar y otras veces puede enseñarle aperturas. Es la misma persona, pero el papel que desempeña en cada caso es distinto.
Identificar casos de uso. Un caso de uso es algo que un actor quiera hacer con nuestro sistema. Por ejemplo, un caso de uso para un “jugador” es “jugar una partida”. Está claro que el jugador quiere nuestro programa para jugar una partida de ajedrez. Otro posible caso de uso es “análisis de un tablero”. El “jugador” pone las piezas en determinada posición y quiere que el ordenador le dé una lista de posibles movimientos, etc, etc. En resumen, debemos obtener una lista de cosas que los actores van a querer hacer con nuestro sistema. Deben ser cosas grandes y no meternos en los detalles. “Mover una pieza” no sería un caso de uso, sino una parte de “jugar una partida”. De aquí saldría un diagrama UML de casos de uso.
Detallar casos de uso. En un texto vamos poniendo varios puntos. En cada punto ponemos sentencias del estilo “el usuario hace tal cosa y el programa hace tal otra”. Es decir, explicamos por escrito, desde el punto de vista del usuario, qué es lo que tiene que hacer y qué es lo que va a hacer el ordenador. Por ejemplo, para “jugar una partida”
El usuario indica que quiere jugar una partida. El programa le pregunta el color de las piezas con las que quiere jugar
El usuario elige el color. El programa le dibuja el tablero con las piezas colocadas en la posición inicial. Las piezas del usuario en la parte inferior de la pantalla. Si el programa tiene blancas, piensa y realiza el primer movimiento.
El usuario mueve su pieza. El programa comprueba que el movimiento es correcto, piensa y realiza su propio movimiento.
Se repite el paso anterior hasta llegar a jaque mate o tablas.
En el caso de uso se detalla una situación normal, sin fallos ni situaciones raras. Al final debería ponerse una pequeña lista con los posibles fallos o situaciones anómales.
Si el movimiento del ordenador pone en jaque al usuario, el ordenador avisa del jaque
Si el usuario intenta un movimiento incorrecto, el ordenador avisa y deja al usuario que vuelva a intentarlo
Advertir que en ningún caso nos hemos metido a detallar cómo va a hacer algo nuestro programa, sólamente qué es lo que va a hacer.
Siguiendo los esquemas UML, podemos incluso hacer por cada caso de uso un diagrama de secuencia en el que los objetos implicados son el actor (el “jugador”) y nuestro programa, sin meternos dentro de él.
También en este paso podemos ir empezando a pensar en cómo van a ser las pantallas de la interface de usuario, de nuestro programa.
Diagrama de clases del negocio. Es un diagrama de clases de objetos que tienen sentido para el usuario. En el caso del ajedrez los objetos serían del estilo “tablero”, “pieza blanca”, “torre blanca”, “jugador”, “cronómetro”, “partida”, “torneo” etc. Nunca “lista de piezas”, “array de casillas”, etc. También se presentan las relaciones entre ellos, como “las piezas están en el tablero”, “la torre blanca es una pieza blanca”, etc.
Este diagrama a este nivel tiene dos utilidades:
Asegurar que los que saben del tema y los que hacen el programa están hablando de lo mismo.
Servir de base para el diseño detallado orientado a objetos.
Cuando el tema es más complejo o menos conocido que una partida de ajedrez, es posible que el informático que programa no tenga muy claros muchos de los conceptos que tiene que manejar. No sabe qué es un asiento contable, un balance, si hay relación entre ellos, etc. Es por eso importante hacer un diagrama de este tipo, en conjunto con un experto o con el cliente, para asegurar que no hay malentendidos.

Cualquier inquietud estamos a su disposición en : info@newsoftwarefactory.com