Desintegración del dominio. (aka descomposición del dominio)

Desintegración del dominio. (aka descomposición del dominio)

Cuando hablamos de desintegración tenemos que olvidar un poco el concepto de pistola de rayos de la ciencia ficción en donde desintegrar implica hacer desaparecer algo y fundirlo en la nada.

Desintegrar es el proceso contrario a integrar, esto es, separar la integridad o totalidad de algo en sus partes.

Tendemos a pensar que en el dominio de un sistema las partes son sus clases, en especial porque todos, básicamente, somos programadores y tendemos a pensar en forma de algoritmos, no importa cuanto lo intentemos, estamos entrenados para eso.

Sin embargo no debemos pensar así por varias razones, la primera es obvia, si solo vemos las clases nos olvidamos de las relaciones entre ellas e incluso nos podemos perder los mensajes que requieren para operar.

Hemos mencionado entonces tres elementos del dominio … clases, relaciones y mensajes, ¿ es casual ?, pues no, ¿ hemos olvidado “la base de datos” ?, tampoco.

También tendemos a pensar que el dominio es la base de datos, al fin y al cabo están las clases, las relaciones … sin embargo es un error, el dominio es el dominio y no una representación que es capaz de persistir el dominio en un instante dado. Así que, en lugar de estar pensando como vamos a persistir algo para luego mostrarlo en la pantalla y sacar algunos informes, vamos a pensar en como las cosas funcionan y sobre todo, “como logran funcionar”.

Desintegrar entonces busca algo llamado granularidad, esta bien claro que cuanto más granular sea el diseño más cohesión tendrán las clases y por supuesto menor acoplamiento. Piensen esto, yo puedo cocinar con la misma harina desde pan a tortas dulces pasando por galletas,  sin embargo, me es más difícil hacer una torta o pan usando galletas aunque tengan harina, se puede obviamente, pero las galletas son clases acopladas de harina con huevo quien sabe que más. La granularidad a la que nos referimos son los granos de harina, podemos juntarlos en diferente forma.

La calidad y cobertura de un diseño esta en relación directa a la granularidad del mismo, siempre que no terminemos modelando claro, los átomos del hierro con el cual se hacen los motores de los camiones.

Modelos de desintegración del dominio.

Vamos a explorar algunos métodos para desintegrar nuestro dominio, a esta serie de métodos se le llaman modelos y cuando se elige uno no se cambian ni se mezclan, si deseamos cambiar el modelo tenemos que empezar de nuevo.

Modelo iterativo : Es el más usado y por eso lo ponemos primero, no es que sea el mejor, pero estamos tan acostumbrados a pensar iterativamente que es muy difícil no usarlo.

Hay un concepto muy importante llamado POV (Point of View) o punto de vista, el nombre es bueno, pero, a veces encontraremos que nos falta el término altura o zoom.

Por zoom me refiero a que tan lejos estamos viendo nuestro problema, por ejemplo, miramos la luna en el cielo, la vemos redonda, blanca y brillante, podemos entonces entender cosas de la luna, todo lo que la distancia nos permita, es decir, grandes cosas, cuanto brilla, sus ciclos, cuando aparece y desaparece etc etc;

Luego nos acercamos, es decir la vemos de más cerca mediante un telescopio y entendemos que tiene cráteres, que no tiene atmósfera, que hay montañas etc.

Luego vamos hasta allí y vemos que tiene polvo de roca, poca gravedad etc;

Finalmente, mediante un microscopio vemos que el polvo lunar es cortante y sus rocas son asteroides y meteoritos que han impactado contra su superficie.

Eso define el punto de vista y su altura, sobre todo muestra como y porque se cambia al altura de visión.

Por comodidad definimos cuatro niveles de completitud de una clase : 

1. Incompleta, se está analizando.
2. Se ha analizado toda la funcionalidad que tiene que ver con la herencia.
3. Se ha analizado toda la funcionalidad que tiene que ver con composición y asociaciones
4. Se ha analizado toda la funcionalidad que tiene que ver con sus relaciones y mensajes.

Definición de la iteración :

Paso 1 : relevar.

Elegimos nuestro punto de vista, el primero se elige de forma que enfoquemos los límites del dominio, en el caso del juego que vimos es la pantalla del juego de la tarea y tal vez jugar un poco al mismo.

Junto con el primero paso creamos una MACROLISTA llamada ML en donde pondremos cosas que descubriremos al final de cada iteración.

Creamos un punto de salto o bookmark para poder volver a el al final de la iteración, este punto de salto es marcado como no terminado.

Extraemos las clases involucradas que vemos desde el POV actual sin profundizar, es decir, en el juego vemos (por ejemplo) :

Clases : 

1. naves armadas
2. Existen varios tipos de naves con diferentes tipos de peligrosidad.
3. defensas humanas
4. un cañon humano
5. una nave nodriza invasora.
6. Puntaje que aumenta según destruimos naves extraterrestres.

Relaciones : 

1. Las naves armadas disparan a las defensas y al cañon.
2. El cañon dispara a las naves. (ups !, nos olvidamos de algo ! pero seguimos)
3. El cañon dispara a la nave nodriza. (idem, seguimos, por algo pasó)
4. Las naves no se chocan entre si pero se mueven (por lo que debe haber alguna relación entre ellas).
5. La nave nodriza no dispara.

Comportamientos :

1. Las naves se mueven en Grupo
2. El Grupo aumenta su velocidad a medida que su número se reduce, pero las naves no cambian de posición, es decir, el grupo no se reacomoda según el número.
3. El cañon dispara  hacia arriba y las naves hacia abajo.
4. No hay un límite de munición.
5. Hay veces que nuestro cañon destruye los disparos aliens y hay veces que aunque nuestro disparo se destruye el disparo alien continúa cayendo.

Paso 2 : comprensión.

Luego veremos el modelo FURPS+ de comprensión de requerimientos, esta parte es la menos científica de todas ya que depende bastante de la experiencia e inteligencia de quien analiza, pero, el método no varía y es repetible, su producto es la plantilla que exponemos a continuación : 

...