Su respuesta es: la habilidad para asignar responsabilidades a los objetos de software. O sea, hay muchas habilidades valiosas, como por ejemplo diseñar eficientes bases de datos relacionales, escribir casos de uso completos y claros, o dibujar impecables diagramas de secuencia, entre muchas otras; pero la asignación de responsabilidades a objetos es la más importante de todas.
La razón (explica Larson) por la que dicha habilidad es tan importante es que debe llevarse a cabo en todo momento del proceso de desarrollo -ya sea mientras se dibuja un diagrama UML o mientras se está escribiendo código- y que influye fuertemente en la robustez, facilidad de mantenimiento y posibilidad de reutilización de los componentes de software.
Larson observa también que la asignación de responsabilidades tiende a ser una actividad desafiante para dominar, y su importancia es vital. "En un proyecto real, un desarrollador puede no tener la oportunidad para llevar a cabo ninguna otra actividad de modelado, por el frecuente 'apuro por programar'. Pero incluso en tal situación, la asignación de responsabilidades es inevitable".
Ahora, la pregunta es: ¿se puede cultivar esa habilidad, o se nace con ella?
Una forma de intentar responder a esa pregunta es jugar al DT (esto no es sugerencia de Larson, es pura cosecha propia). Jugar al DT significa imaginar que los objetos de un sistema son el plantel de un equipo de fútbol, y uno, como analista, es quien debe diseñar la estrategia de juego, acordando con cada jugador (u objeto) lo que debe hacer.
Un pequeño ejemplo: nos toca diseñar una herramienta para hacer el picking de pedidos en un depósito de mercaderías. Como directores técnicos, primero armamos el "plantel" imaginario con los objetos que van a formar nuestro equipo: un depósito, muchos artículos, muchas ubicaciones, un pedido que debe armarse. Hay un actor principal que es el preparador del pedido.
Comenzamos a armar nuestra estrategia de juego. Reunimos imaginariamente a nuestros objetos frente a un pizarrón (en el que imaginamos que está dibujado el bosquejo del modelo de dominio) y les decimos, señalando el dibujo: "el preparador llega con una hoja impresa en la que figura el detalle de artículos que debe reunir para armar el pedido. El preparador tiene una necesidad clara: armar el pedido lo más rápido posible, ya sea para poder seguir armando otros pedidos o para poder irse a su casa temprano. El preparador se fija en el primer artículo del pedido, y necesita averiguar rápido en qué parte del depósito encontrarlo".
Entonces miramos a nuestros jugadores y les preguntamos:
-¿Quién se encarga de decirle en dónde encontrar el artículo que busca?
-¡Yo! -contesta el objeto Depósito con firmeza.
-¡Bien! -gritamos entusiasmados. Ya tenemos asignada una importante responsabilidad a un objeto igualmente importante. Pero no es suficiente. Nos dirigimos a Depósito y le preguntamos:
-¿Qué información le das al preparador para ayudarlo a encontrar ese artículo?
-¡Le muestro todas las ubicaciones en donde hay almacenadas unidades del artículo que busca! -contesta Depósito enérgicamente-. ¡Ordenadas por cercanía, para que tenga que recorrer el menor camino posible!
-¡Perfecto! -replicamos palmeando a Depósito en el hombro. Volvemos a señalar el pizarrón y continuamos el relato estratégico-. Entonces el preparador se dirige rápidamente a la ubicación más cercana de las que le mostraste y allí encuentra el artículo. Toma las unidades que necesita y las coloca en el carro. Ahora necesitamos que el sistema se entere de que esas unidades fueron retiradas de su ubicación. ¿Quién se encarga de esto?
-¡Yo! -contestan a coro los objetos Artículo.
-¿Y cómo lo hacen?
-¡Le mostramos al preparador nuestros códigos de barra, para que los lea con su escáner, y el sistema sepa que ya no estamos en la estantería, y ahora formamos parte del pedido!
-¡Excelente!
Y así sigue nuestra imaginaria charla motivadora con nuestro plantel de objetos hasta que cada uno de ellos tiene perfectamente claro lo que tiene que hacer para llegar a cumplir con lo que necesita el actor (en este caso, el preparador).
Una curiosidad lingüística que ayuda en la metáfora del equipo de fútbol: en la terminología del UP (Proceso Unificado), se habla de los "goals" (metas u objetivos) de los actores para identificar requerimientos. Nuestro equipo imaginario, en lugar de tratar de convertir goles, busca materializar goals.
No me atrevería a proponer en recintos académicos la costumbre de dar vida, actitud y personalidad a los objetos como una forma de diseñar software; pero de seguro sirve como ayuda para ver a los sistemas como conjuntos de entidades con comportamiento, que colaboran en pos de un objetivo común.
Al fin y al cabo, si a los escritores de novelas les pasa que sus personajes parecen cobrar vida y decidir por sí mismos cuáles serán sus destinos, ¿por qué los objetos de software no pueden hacer lo mismo y decidir por sí mismos cuáles serán sus responsabilidades?
