Diseño

Metodologia

DISEÑO PRELIMINAR

Aquí ya empezamos a pensar en cómo vamos a hacer las cosas.

En el diseño preliminar tratamos de establecer la arquitectura de nuestro programa. La arquitectura es un esquema de en qué módulos/paquetes vamos a dividir nuestro programa, qué librerías. Si el programa es suficientemente grande, quizás vaya en varios ejecutables, una arquitectura cliente/servidor, etc.

Viendo los casos de usos, deberíamos ver qué cosas podemos hacer comunes o como librerias aparte, que podamos reutilizar. Por ejemplo, en nuestro caso del juego de ajedrez, podríamos hacer los siguientes paquetes:
Paquete de ajedrez. Un paquete que sea capaz de jugar al ajedrez, pero sin ningún tipo de relación con las pantallas. Si es una clase, tendría métodos del estilo “Poner_Piezas_Posición_Inicial()”, “Mover_Pieza()”, “Dame_Siguiente_Movimiento()”, etc, etc. Sólo con este paquete, seríamos capaces de jugar al ajedrez, o de instanciar dos paquetes y hacer que jueguen entre ellos, o jugar en red, etc.
Interface con el usuario. Un paquete con el dibujo del tablero, las piezas, recoger los movimientos del usuario etc.

Dentro de estos paquetes, podemos ir pensando más subpaquetes, etc.

En este punto y con los casos de uso en general, debemos tener cuidado. Según una crítica generalizada a los casos de uso, estos llevan a un diseño funcional y no a uno orientado a objetos. Debemos tratar de pensar en objetos y almacenarlos juntos en la misma librería cuando estén muy relacionados entre sí, no en funciones. Por ello es buena idea tratar de agrupar las clases del diagrama de clases del negocio en paquetes y tratar de desarrollar la arquitectura a partir de ellas.

Es importante en este paso definir las interfaces y relaciones entre paquetes. Para ello puede servir de ayuda hacer los diagramas de secuencia de los casos de uso mostrando los actores, los paquetes y los mensajes entre ellos. Según vayan creciendo los diagramas de secuencia por aquello de ir entrando en detalles, podremos ir extrayendo subcasos de uso, como “mover pieza”, “elegir color”, etc.

DISEÑO DETALLADO

En el diseño detallado ya se entra a nivel de clases y métodos. Por cada paquete que hayamos extraido en el paso anterior y siguiendo siempre los casos de uso, debemos ir detallando las clases que vamos a implementar y los métodos que van a tener. Detallamos aun más los casos de uso y las interfaces de las clases.

En este punto pueden ser de ayuda los patrones de diseño. La gente que ha ido diseñando a lo largo de la historia, se ha encontrado con problemas (¿cómo hago que la clase A se entere que la clase B ha cambiado sin necesidad de que B vea a A?, ¿En qué clase pongo el metodo que suma las clases A y B? ¿Como me aseguro que de esta clase sólo se haga una instancia?, etc, etc). Algunos de dichos problemas salen con mucha frecuencia (como los indicados de ejemplo) y se han establecido soluciones “estandard”, que funcionan bien. Dichas soluciones se llaman patrones. No está de más leer algo sobre patrones de diseño orientados a objetos para tener una lista de “soluciones” a aplicar.

Hay incluso patrones a nivel de arquitectura. Es bastante conocido, por ejemplo, el patrón separación modelo-vista. En nuestro caso “modelo” sería el conjunto de clases que juegan al ajedrez. “Vista” sería el conjunto de clases que “pintan” la partida en la pantalla. Hacer esa separación en dos módulos, hace que nuestro módulo de ajedrez sea reaprovechable, incluso si cambiamos de entorno de ventanas (de windows a ms-dos o de ms-dos a unix). Eso sí, es imprescindible que sólo la “vista” vea al “modelo” y nunca al revés. Si lo hacemos al revés y queremos llevarnos nuestro “modelo” juego de ajedrez, tendremos que llevarnos también parte de la “vista”.

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