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 : 

1. Numeramos las clases detectadas en forma consecutiva comenzando por uno, en general vemos las clases más “importantes” o evidentes primero, pero, si no es así NO CAMBIAMOS el orden en que las descubrimos.
2. Marcamos cada clase como no analizada y no terminada.
3. Numeramos las relaciones en el orden que las detectamos.
4. Numeramos los comportamientos en el orden en que los detectamos.
5. Preguntamos ¿ surge, mirando la lista de relaciones alguna clase que no hayamos visto ? (como las clases de disparo alien y disparo humano o al menos la clase disparo, bala o como la llamemos).

1. Si es así las agregamos a la lista.

1. Preguntamos ¿ Surge de la lista de comportamientos alguna clase que no hayamos visto ? (por ejemplo la clase escuadrón o grupo que agrupa las naves).
2. Preguntamos ¿ Es nuestro de punto de vista actual una clase en si misma que agrupa todo lo que estamos viendo ?, para que se entienda, la primera iteración siempre dirá, el sistema, en nuestro caso, el juego.
3. Preguntamos ¿ ha quedado algún elemento sin clasificar ? es decir, sin una etiqueta. En nuestro caso nos quedó sin clasificar el puntaje.

1. Si es así, por cada elemento sin clasificar :

1. Agregamos el elemento a donde corresponda.
2. Volvemos a ejecutar el paso de comprensión entero.

1. Preguntamos ¿ tomando todos los elementos detectados, podría construir el sistema ? (suponiendo que cada elemento haga lo que debe de la forma que debe hacerlo).

1. Si concluimos que no, volvemos al paso 1 relevar y luego al paso 2.
2. Si concluimos que si, terminó este paso.

Paso 3 : verificación de completitud del punto de salto.

Para cada elemento no completo de las listas :

1. Preguntamos ¿ Que ES esta clase ?, por ejemplo, un pájaro, una nave espacial.

1. En ese momento sabemos de donde deriva, si la clase no existe en el mundo real o en nuestro análisis da lo mismo, simplemente la nombramos (por ejemplo nave nodriza extraterrestre desarmada).
2. Notarán que estamos eliminando de un plumazo la herencia múltiple.
3. Anotamos esta clase en la Macrolista y la marcamos como no analizada y completa nivel 1.
4. Si esta clase ya estaba en la lista solo la marcamos sin terminar. 

1. Preguntamos ¿ Es esta clase una composición de otras ?, para responder aplicamos las siguientes reglas :

1. Con lo que la clase es, ¿ puede hacer todo lo que yo creo ?, por ejemplo, ¿ Mi nave armada puede disparar solo porque sea una nave ?

1. Si la respuesta es no, marco mi clase NaveArmada como no analizada y no terminada, se le puede agregar una nota para saber que debo especializar esa case y en que sentido.
2. Si la respuesta es si, marco esa clase como analizada y completa nivel 3 porque la funcionalidad de esa clase está garantizada por su padre.

1. ¿ Necesita mi clase la colaboración de otra para realizar lo que yo creo (que debe) ?

1. Si la respuesta es sí hacemos una lista de las colaboraciones necesarias, es decir, las otras clases requeridas y las pasamos a la Macrolista, con los mismos criterios que la anterior.
2. Si la respuesta es no tenemos a estas alturas tenemos una clase completamente analizada y completa nivel 2.

1. Si la clase esta analizada y las clases que colaboran o componen anotadas en la lista la Macrolista se puede marcar esta clase como completa nivel 3.
2. Para cada relación nos preguntamos :

1. Son capaces las clases involucradas en esta relación de responder, mediante mensajes, a la funcionalidad de estas relaciones.
   (Tener en cuenta que la clase debe ser vista en su punto más alto, es decir, ¿ mi nave espacial de ataque puede responder a los mensajes que el juego le envía para que dispare ?)

1. Si la respuesta es no, creo el mensaje o la relación.

1. ¿ He creado algún mensaje en esta iteración ?

1. Si la respuesta es no marco las clases como completas nivel 4.
2. Si la respuesta es si, marco las clases como completas nivel 1 y ejecuto el paso 3 completo.

Paso 4: modificación del punto de vista.

Debemos elegir ahora donde fijar la vista, por lo tanto :

1. Volvemos al punto de salto del que partimos. 
2. Tomamos la clase de numeración menor marcada como no analizada, en general elegimos las del punto de salto que acabamos de ver, pero no es mandatorio, se puede elegir de cualquier punto de salto no terminado.
3. Marcamos el elemento elegido como punto de salto y ejecutamos los tres pasos que acabamos de ver n veces hasta su completitud.

Paso 5: Verificación de la macrolista.

1. Tomamos la macrolista y aplicamos los pasos de 1 a 4 n veces.
2. Volvemos al punto uno hasta que todas las clases este completas nivel 4 y la macrolista este vacía.

Paso 6: Colisión

No lo veremos aquí sino en el capítulo de modelando el mundo ideal.

Cuando parar .... 

Cuando llegamos al punto que todos los puntos de salto están completos sabemos que el modelo esta terminado, ahora bien, a veces pasa que tendemos a refinar demasiado, es decir, hacemos granos demasiado pequeños y eso también es malo, para evitar eso se puede graficar el progreso del modelo O DE CUALQUIERA DE SUS COMPONENTES, es decir, puntos de salto o clases, de forma que las y corresponden a la cantidad de clases / iteraciones mientras que las x a la cantidad de iteraciones completas. Si hay demasiadas iteraciones estamos perdiendo el tiempo en tonterías y llevando las cosas al extremo. Cuando la gráfica converge es señal que debemos parar.

...