Tarjeta CRCTengo que ser sincero. Cuando la empresa me comunicó que tenía que asistir a un seminario sobre la orientación a objetos, tenía de todo menos ganas. No es que me disguste la formación. Todo lo contrario. Me gusta y además tengo más que asumido que es necesaria, sino imprescindible para el gremio.

Lo que no me hizo tanta gracia era estar fuera de casa unos días, al tener que ir a otra ciudad. Eso era. Tener que dejar la familia aquí para irme allí. Al final me conciencié y se acabó. De todas formas, el seminario era imprescindible para el departamento de informática de la empresa.

Después de aquel seminario, cambié de opinión. Vi la utilidad de algo tan sencillo y potente a la vez. Tanto Víctor, el formador, como los compañeros del seminario, hicieron esta experiencia muy interesante. Este artículo pretende presentar aquellos momentos que encontré más interesantes.

Espero que os sirva de ayuda…

- Bien. Ahora vamos a considerar el juego del parchís como un sistema a desarrollar. Imaginemos por un momento que tenemos que crear un software para jugar al parchís con nuestro ordenador. ¿Cómo lo haríamos?.
Todos nosotros callamos. Así era. Un grupo de analistas, algunos más experimentados que otros, callaban ante una pregunta de cómo abordar un sistema.

- Me refiero a qué hacer para conocer más este sistema de cara al diseño de sus programas. ¿Alguien puede decirme cómo?.

- Yo creo – Marcelo fue el primer valiente – que, en el fondo, no tenemos una manera común. Es decir, existen por supuesto las metodologías, pero su aplicación es tan flexible que no creo que podamos hablar de una manera única de hacer este proceso.

- Lo mismo creo yo – Dijo Antonia – Al final, cada uno de nosotros aplica su versión de la metodología que sea.

- A veces, ni siquiera hay metodología en algunos proyectos.- Mario fue tajante, y el único que se atrevió a poner sobre la mesa el problema de las metodologías a la hora de llevar a cabo un proyecto de software.

Aquello fue el detonante de una serie de comentarios, ya de todos nosotros, sobre lo mal que iban algunos proyectos y algunos desastres varios. La situación era en aquel momento caótica, pero Víctor dejó pasar unos minutos antes de volver a conducir el seminario.



- Espero que os hayáis desahogado bien, porque es lo que yo quisiera. Estoy de acuerdo con vosotros sobre los problemas que habéis tenido con proyectos de software, porque yo también lo he experimentado, además de ver muchos otros casos desde que soy formador y, a veces, consultor.


Dejó pasar unos segundos, en los que nosotros esperábamos que Víctor nos empezase a dar la receta milagrosa de la solución a este problema.

- ¿Sabéis cuál es la solución?. - No hay solución fácil. Cada proyecto de software es muy particular respecto a los otros. Es cierto que existen patrones comunes a todos los proyectos, pero al final, no tenemos más remedio que aprender de los proyectos en los que hemos sido miembros para tener más experiencias de cara a los siguientes. Las metodologías ayudan, pero somos nosotros quienes debemos aplicarlas de la manera que nuestro proyecto demande.

- O sea, que no sirven para nada. – sonó como si Julián quisiese tener un debate con Víctor.

 - Nada más equivocado. Las metodologías han sido y serán una ayuda inestimable. El problema está en cómo se utilizan.

 - ¿Y cómo deberían utilizarse?. - Pues como una gran caja de herramientas. Supongo que todos habéis hecho alguna vez arreglos en casa. Pues de eso se trata.

- ¿De qué?.

- Pensemos, o mejor dicho imaginemos, que se nos ha roto una ventana. Vamos a ella y nos damos cuenta que tiene una bisagra rota y la queremos cambiar. Para ello, necesitaremos una o más herramientas, las que se adapten mejor a la tarea. Ahora imaginemos que tenemos que fijar un azulejo del baño que se ha despegado. Para esta tarea utilizaremos otras herramientas. Es posible que algunas herramientas sirvan para las dos tareas, pero seguro que habrán otras que sirvan para una u otra cosa, pero no para ambas. Víctor pensó unos segundos antes de continuar.

- Yo tengo las herramientas organizadas en un carro con ruedas, que tiene compartimentos. Las he organizado por función, así sé que las herramientas para el trabajo de la madera, están en el segundo cajón, y las de electricidad en el cuarto. A eso me refiero con utilizar las metodologías como una gran caja de herramientas, para cada tarea utilizaré una u otra herramienta, diagramas, documentos, o lo que sea, que me ayude a hacerla mejor. Como en el ejemplo de la ventana, no utilizaré todas las herramientas por que estén ahí, sino aquellas que convengan. Cuando me enfrento a un arreglo, voy allí con mi carro y lo hago. Llevo todas mis herramientas, y sé que cuántas más tenga, sean específicas para tareas y las sepa utilizar convenientemente, más preparado estaré. Pero eso no significa que tenga que utilizarlas todas cada vez.

- En este seminario vamos a ver una de esas herramientas. Es útil para comenzara pensar bajo una manera de diseñar programas bajo la perspectiva de la orientación a objetos: las tarjetas CRC. Lo de CRC nos sonó a chino. Y no era para menos. Además también nos sonó a algo sofisticado, con un software. ¡Qué digo!, con un montón de diferentes programas para ayuda a llevarlo a cabo. Nos quedamos esperando a que Víctor empezase a repartir manuales, tochos ladrillos enormes con CD incluido, en el que hubiese una versión de 30 días de algún producto. Me lo imaginaba algo así como CRC-Soft o GoCRC.


- Empecemos – Víctor se colocó delante de nosotros mirándonos fijamente. Se iba a desvelar el gran secreto.

- Esto es una tarjeta CRC


Alzó su mano derecha. En ella tenía una cartulina blanca, sin nada escrito en ella. No dijo nada más.

- ¿Un papel? – quien primero demostró su asombro fue Julián. Los demás nos aliviamos cuando alguien se atrevió a decir su opinión, aunque fuese de manera sutil. – No es un papel – insistió Víctor -es una tarjeta CRC. Os ayudará a la hora de empezar a diseñar y analizar el software orientado a objetos que necesitéis. – Disculpa, Víctor -el que hablaba ahora era Marcelo -, pero como no nos des ninguna indicación más, creo que no vamos a entenderte.

- Lo sé. Pero no os voy a dar ninguna indicación, sino que vamos a utilizar el ejercicio del parchís para que seáis vosotros mismo quienes veáis las indicaciones. ¿Vamos?.


No esperó respuesta alguna.

- Bien. ¿Qué es lo que tenemos? Unos requerimientos y unas tarjetas CRC. Vamos a traspasar lo uno a lo otro. Los requerimientos es lo único claro que tenemos. Sigamos. Aquí tengo la nota que hice en el bar – la enseñó a la clase como el mago que enseña aquello con lo que va a trabajar. Luego la escribió en la pizarra.



Tarjeta CRC

- Veamos “las cosas” de las que ya hablamos en el bar. Sabemos también que esas “cosas” interactúan unas con otras para que el sistema (el juego del parchís) funcione, y que además existen unas reglas. Pero lo que quiero saber, a partir de estas premisas, es qué espero que hagan cada una de esas “cosas”, o mejor dicho, cuando una de las “cosas” interactúa con otra, espera algo de ella, acorde con la interacción demandada.


- Veámoslo con un ejemplo: si yo voy al ascensor del hotel en donde estoy alojado, puedo interactuar con él de varias formas. Una de las más comunes es pulsar el botón del piso a dónde me quiero dirigir. Eso es una interacción: desde una “cosa” (en este caso: yo), le doy una orden a otra (el ascensor, o más bien el botón).


- Queda claro- Antonia impidió que el monólogo fuese demasiado largo- ¿Nos estás diciendo que debemos saber qué esperamos de las “cosas” a partir de qué acciones, órdenes, interacciones vamos a tener con ellas?.


- Eso es. Pero la pregunta es: ¿cómo llegamos a saber las interacciones y lo que esperamos?.


- A partir de los requerimientos -Mario lo dijo convencido.


- Si, pero sólo con ellos no basta. Sabemos que son una buena información, pero no suelen especificar el detalle de los pasos que deben ejecutarse para satisfacer cada requerimiento. Todos sabéis los requerimientos del parchís, pero para cada uno de ellos, debemos saber qué pasos, “cosas” e interacciones ordenados son necesarios para llevarlo a cabo. ¿A alguien se le ocurre cómo?.


- Emulando el sistema – fue Antonia quién se atrevió.


- Cierto. Lo que vamos a hacer es reproducir los pasos para ver qué ocurre con partes del sistema relacionadas con los requerimientos. A esas partes las llamaremos “escenarios”.


- ¿Cómo los del teatro? Las medio-risas fueron generales.


- No. Un escenario, tal y como lo vamos a tratar, se trata de una parte del sistema, delimitada, con un inicio y un fin, y que tiene una serie de pasos ordenados y bien definidos para ir desde su inicio a su fin.


Ahora nadie se reía. Víctor había dado el golpe perfecto para recordarnos que no era para tomárselo a broma. El problema es que aún no veía que sus palabras fuesen claras.


- Me explicaré – Víctor caminó de lado a lado del aula pellizcándose la barbilla y mirando hacia el suelo, buscando la mejor manera de explicarse. Imaginemos por un momento que estamos de nuevo en el bar de antes. Ahora pensad cada uno de vosotros en qué sería el escenario “pedir un café”.


Dejó pasar unos segundos.


- No te entiendo muy bien -dijo Julián-. La palabra escenario no deja de significar para mí una parte de un teatro.


- Pues veamos en qué se compone el escenario “pedir un café”. Imaginadme a mí entrando en el bar. Voy a definir este escenario. Como os he dicho antes, un escenario tiene un inicio y un fin delimitados. ¿Cuál es el inicio del escenario “pedir un café”?.


- Cuando entras en el bar- dijo Antonia.


- Podría ser, pero ese inicio es el que has decidido tú. Quizá alguno de vosotros había pensado en otro inicio.


- Si – esta vez quien hablaba era Marcelo. – Yo había pensado en que lo primero que pasa es que pides el café al camarero.


- Pues yo pienso que es cuando el camarero viene y te pide qué vas a tomar.


En aquel momento se generó un pequeño caos en el aula. Todos hablaban con todos mientras Víctor los miraba, con expresión de alguien que estuviese investigando el comportamiento de un grupo de personas. Estuvo así durante cinco largos minutos, hasta que las conversaciones cesaron.


- Bien. ¿Habéis llegado a una conclusión?.


- No.


- Yo diría que si.


- ¿Cuál es la conclusión?.


- Pues que la decisión de cómo abordar los escenarios es del analista. Si os dais cuenta, algunos de vosotros habéis coincidido, pero el resto no, y sin embargo a todos os ha parecido que la vuestra es la correcta, ¿no?. Pues de eso se trata. Al final, es decisión vuestra cómo definís los escenarios, cuáles son su inicio y su fin.


- Pero, alguno será mejor que otro, ¿no?.


- Cierto, pero no en todos los casos se puede saber cuál es el mejor escenario. Dependerá del cada proyecto y de las partes del mismo que sean más necesarias de analizar. Lo que os intento decir, es que necesitamos los escenarios para saber cómo funciona el sistema que desarrollamos, pero que la elección de qué escenarios y su alcance es decisión sólo vuestra. Por supuesto, no se trata de elegir porque sí, sino aplicando la lógica de qué es lo que nos conviene, teniendo en cuenta el proyecto, que define sus propias características.


- Ya hemos decidido el inicio del escenario, por ejemplo, y que nadie crea que es el mejor, yo decido que sea cuando le pido el café al camarero, porque me interesan los pasos de ahí en adelante, pero, ¿hasta cuándo? ¿hasta qué momento? Os podría pedir lo mismo de antes, pero ya sabéis que es posible que salgan varios momentos finales, así que yo yo a decidir que sea en el instante que el camarero coloca el café en la barra, ya que estoy analizando el escenario “pedir un café” con la salvedad que es “pedir un café desde la barra”.


Nosotros, lo único que hicimos en aquel momento fue escuchar.


- Ya tenemos el inicio y el fin del escenario “pedir un café en la barra”. Estaréis de acuerdo conmigo en que desde su inicio a su fin suceden varias cosas, además con un orden: le pido el café al camarero, el camarero se dirige a la cafetera, saca el casquillo, lo limpia, lo llena de café, lo coloca en la cafetera, coge una taza, la coloca debajo, le da al botón de poner en marcha, coge un platillo, cucharilla y azúcar, y cuando el café está listo, coloca la taza en el platillo y me lo trae a la barra.


Mientras iba diciendo los pasos, dibujó en la pizarra un esquema con estos pasos.


- Todo esto está muy bien – No me pude creer que fuese yo quien hablase, y de esa manera-, pero, ¿cuántos escenarios tenemos que hacer?.


- ¿Qué pensáis los demás?.


Nadie decía nada, así que Víctor no tuvo más remedio que dar su opinión.


- Yo digo que todos.


- ¿Todos?- dije.


- Si. Todos. Y me refiero a que si analizo todos los posibles escenarios de un sistema, significa que habré analizado todo el sistema, y eso es lo que debería ocurrir.


- Si, es lo que debería ocurrir. Pero todos sabemos que no es así.


Al escuchar mis palabras, todos mis compañeros asintieron. Todos eran experimentados y saben la realidad que ocurre en los proyectos de desarrollo de software. Al final, la presión hace que no se pueda analizar la totalidad de escenarios.


- Lo sé -dijo Víctor-. Yo también he sido desarrollador en proyectos similares a los vuestros.


- ¿Entonces?. ¿Qué hacemos?.


- Aplicar la lógica. Sabemos que eso ocurre, ¿qué opciones tenemos?:. Creo que la opción de eliminar la presión no entra en las posibles.


- No.


- Pues entonces tenemos que vivir con ello. Así que pensemos cómo vivir con ello.


- Yo creo que al final, no nos queda más remedio que analizar parte del sistema, ya que no tendremos más tiempo. – Mario, que no había intervenido, decidió que era el momento.


- Si, creo que eso ya lo sabemos todos. ¿Pero qué parte?- Antonia tenía ganas de ir a lo importante.


- Pues empezando por lo más importante -Mario daba señales de sentirse un poco dolido por al comentario de Antonia y se notaba en su tono.


Antes que el seminario se convirtiese en una batalla entre dos, Víctor tomó las riendas de nuevo.


- ¡Pues claro que las más importantes!. Ahora decidme cuáles son las más importantes.


En aquel instante, creo que ninguno de nosotros sabía con certeza cuáles son los escenarios más importantes. Todos teníamos una idea de cuál escenario es más importante que otro pero no sabíamos con qué patrón lo decidíamos. Al menos eso era lo que me pasaba a mi. Por la cara que ponía el resto, supuse que les pasaba más o menos lo mismo.


- De alguna manera tenemos que priorizar- insistió Víctor.- Si vamos a analizar escenarios, y queremos hacer el primero, tenemos que saber cuál es el primero.


Nada. Que nadie se atrevía. Decidí que, dado que Víctor no iba a decir nada hasta que alguien lo hiciese, diría lo que pienso, aún a riesgo de hacer el ridículo.


- Yo creo que aquellos que son más importantes, lo son para el cliente.


- Explícate.


- Pues que, si por ejemplo estoy en un proyecto para una zapatería, el escenario “vender zapatos”, es importante para el cliente, o más bien para el negocio.


Víctor se quedó mirándome primero a mí, y luego a los demás. Estaba esperando una reacción del grupo. No tardó mucho en llegar.


- El cliente tiene unas prioridades, pero a veces tenemos partes del sistema que el cliente desconoce y aún así siguen siendo importantes. – Antonia fue la valiente.


- ¿A qué partes te refieres? – se notaba que a Víctor le gustaba aquella situación.


- Pues, por ejemplo: estoy en un proyecto en el que una oficina que tenemos en Madrid, necesita vender nuestros productos cuando antes no lo hacía. Teniendo en cuenta que hasta ahora todo se hacía en nuestra central de Zaragoza, supone tomar una decisión de si, por una parte, hacemos que Madrid tenga su propia base de datos replicada de la de Zaragoza, o bien Madrid ataque la base de datos de Zaragoza directamente. Estas dos posibilidades generan escenarios diferentes, en lo que a la consistencia de la información se refiere, pero que son trasparentes para el cliente. Por tanto, el cliente no nos dirá que estos escenarios son importantes, ya que para él no lo son.


Se generaron murmullos generalizados, todos dando la razón a Antonia.


- Entonces, ¿qué hacemos?.


- Pues tener en cuenta ambos criterios para establecer los escenarios más importantes. – quien ponía la rúbrica era Julián.


- Decidido. Sabremos cuáles son los escenarios más importantes sobre todo por los siguientes motivos: que sea importante para el cliente, y por tanto para el negocio, o bien que influya de manera importante en las decisiones de la arquitectura del sistema. Las apuntó en la pizarra para que todos las tuviésemos en mente.


Después de un instante para que pudiésemos copiar lo de la pizarra, la borró y empezó a escribir de nuevo en ella.


- Podemos continuar ahora con las tarjetas CRC. Escojamos un escenario: voy a decidir que sea el siguiente.


Al apartarse, dejó ver lo que había escrito:


Datos: “mueve ficha y se come a otra de diferente color”.

Inicio: la posición de la ficha cambia.

Final: la posición de la ficha cambia sumándole 20 posiciones.


- Vamos a practicar con este sencillo escenario. Para empezar, decido que el primer paso que me interesa analizar es que un jugador a acabado de mover una de sus fichas. ¿Qué es lo que ocurre entonces?.


- Que se come la ficha. – Antonia contestó.


- No. Todavía no. Como os he comentado, el escenario comienza justo después del movimiento de una ficha, por lo que todavía no sabemos si en la nueva posición hay o no una ficha de otro color.


- Pues entonces, tenemos que comprobar si en nuestra posición hay o no una ficha.


Víctor se giró hacia la pizarra y escribió: “Lista de responsabilidades”. Justo debajo escribió: “Comprobar fichas de diferente color en misma casilla”:


- Lo que os pregunto ahora es: ¿Quién tiene la responsabilidad de comprobar si hay dos fichas de diferente color en una misma casilla?.


- ¿Responsabilidad?.


- Si. Dicho de otra manera, ¿De quién esperamos que sepa comprobar si en una misma casilla hay dos fichas de diferente color?.


- ¿De la misma ficha?. – Marcelo lo dijo pero sin estar seguro del todo.


- Podría ser, pero antes de decidirlo, pensemos que no es lo mismo ser responsable de cumplir algo a pedir a alguien o algo que haga ese algo. Para nuestro ejemplo, no es lo mismo ser el responsable de comprobar si en una casilla hay dos fichas de diferente color a ser alguien que pide a otro que cumpla su responsabilidad.


Víctor se giró de nuevo a la pizarra. Al quitarse nos dimos cuenta que había hecho un pequeño dibujo:

Tarjeta CRC

- Pensemos. En este dibujo: ¿quién es el monigote que más se ajusta a la ficha que acaba de moverse?.


Después de unos segundos, Julián se atrevió a dar su opinión.


- Creo que es el de la izquierda. El que has etiquetado como “el que pide”.


- ¿Porqué?.


- Por que no solamente esa ficha es la que necesita saber si está en una casilla donde hay otra de diferente color, sino que será necesario proveer de este servicio a todas las fichas cada vez que se muevan.


Se hizo el silencio. Víctor miró a todos con una media sonrisa.


- Hay dos cosas que quiero decir – Siguió Víctor – Lo primero es que ha salido una palabra importante, y es “servicio”. Es más importante de lo que creéis. ¿Porqué?, pues por que es una buena práctica diseñar software bajo la filosofía de que en él hay partes en las que se pide un “servicio” y partes que lo proveen.


- ¿Como pedir la hora a alguien?.


- Exacto. En vez de pensar en programas, o módulos que lo hacen todo, podemos pensar en que el sistema que estoy desarrollando tendrá servicios disponibles a quien los demande.


- Pero, ¿no se parece un poco un servicio a una responsabilidad?.


- Se parece, y a veces tenemos servicios que se corresponden a una sola responsabilidad, pero no siempre es así. A veces tenemos un servicio que, para cumplirlo, entran en juego varias responsabilidades.


Como vio que no lo teníamos claro…


- Por ejemplo. Imaginad que tenemos un servicio al que, si le damos una cuenta de correo electrónico, nos diga si, en su estructura, es correcta. Para conseguir este servicio, se me ocurren, al menos, las siguientes responsabilidades: comprobar que tiene el símbolo de arroba, que no tiene ningún carácter no permitido y que tiene, como sufijo, un dominio correcto. Todas estas responsabilidades se utilizarían para conseguir dar el servicio “comprobar estructura correcta de dirección de correo electrónico”.


- Visto esto, podemos tener el servicio, en este caso correspondiente a una responsabilidad, de saber, a partir de la petición de una ficha justo después de haberse movido, si en la nueva casilla hay otra ficha de otro color. Y ahora viene la pregunta: si no parece lógico que esta responsabilidad sea de la propia ficha, ¿de quién entonces?.


- Yo creo que es una responsabilidad que está fuera de las cosas físicas del juego. Es decir, no creo que sea ni del tablero, ni de los jugadores. Mas bien es un tema de las reglas del juego, de su funcionamiento. – se notaba que Julián estaba motivado.


- Intentas decirnos que es una de las reglas del juego, ¿no?. -Antonia, que llevaba un rato ausente, volvió al grupo.


- Si.


- ¿Podemos decir que, en principio, tenemos una responsabilidad, que es posible que no sea la única, referente a las reglas del juego?. – Víctor lo tenía claro. No era para menos.


Todos estábamos de acuerdo, aunque no se oyó a nadie.


- Pues vamos a hacer nuestras primeras tarjetas CRC: una para la ficha y otra para las reglas del juego.


- ¿Porqué dos?. ¿No hemos asignado la responsabilidad a las reglas del juego?. ¿Qué tiene que ver en esto la ficha?. – Antonia estaba despierta del todo. Al menos ahora.


- ¿Te acuerdas de los monigotes de antes?.


Por supuesto, no lo había copiado. Como estaba a mi lado, le pasé el mío. Cuando Víctor vio que lo miraba, siguió hablando.


- No os olvidéis que estamos analizando un escenario. Y como tal, consiste en pasos, siendo cada uno de ellos una comunicación entre dos partes, como cuando lo dibujé con monigotes.


Un poco de rubor subió a la cara de Antonia.


- ¿Y cómo hacemos las tarjetas?.


- Ahora mismo. Pero antes vamos a mover las mesas y las sillas.


Después de varias indicaciones, juntamos las pequeñas mesas, consiguiendo así la forma de una mesa más grande. Luego nos sentamos alrededor. El aula parecía entonces una sala de reuniones improvisada.


- Ahora que ya estamos listos, empecemos con la primera tarjeta. Julián, por favor, coge una de las tarjetas y dibuja en ella las siguientes líneas. No escribas los textos.


En la pizarra, dibujó lo siguiente:

Tarjetas CRC

Julián lo hizo. Todos nos quedamos mirándole.


- Bien. Ahora lo primero es ver qué partes hay que rellenar. Como veis, en la parte superior izquierda hay que poner el nombre de la tarjeta. ¿Qué representa una tarjeta CRC?. Pues depende.


- ¿Depende de qué?. – El mismo Julián habló mientras miraba su tarjeta.


- De si está en la mesa o si alguno de vosotros la coge.


- ¿Y qué diferencia hay?.


- Mucha. Cuando está en la mesa significa que sus responsabilidades no se utilizan en el instante en el que está en la mesa, pero si alguien la coge, significa que en el escenario que analizamos y el paso en el que estamos, esta tarjeta está involucrada y por tanto se está haciendo uso de alguna de sus responsabilidades. Como veis, no es lo mismo. Digamos que, mientras está en la mesa, no es utilizable, mientras que cuando la necesitamos, lo que simbolizamos al levantarla es que se convierte en algo utilizable.


- Por tanto, si la volvemos a dejar, ¿significa que deja de ser utilizable de nuevo?


- Eso es. Si está en la mesa, es que no es utilizable.


Después de dejar asimilar lo dicho, Víctor siguió:


- Vamos a hacer lo siguiente: Mientras avanzamos el escenario, puede ocurrir que creamos nuevas tarjetas, utilicemos las que tenemos o incluso nos demos cuenta de que nos sobra alguna o bien tengamos que fusionarla con otra. Cada vez que creamos una, tendrá a uno de vosotros como responsable de ella. Como seguramente tocará a más de una tarjeta por persona, vamos a intentar que las tarjetas que tengan responsabilidades que tengan que ver algo entre ellas, las tenga la misma persona. Como es Julián quien ha dibujado la tarjeta de la ficha, será el responsable de ella. Para las reglas del juego, será Antonia.


Ambos cogieron una tarjeta y le pusieron el nombre en la parte superior izquierda.

Tarjetas CRC

- Sigamos. Ahora sabemos que la tarjeta “reglas del juego” tiene una responsabilidad: saber si en una casilla hay una ficha de otro color a la que pide la ejecución de dicha responsabilidad. Vamos a ponerla. Antonia, por favor, coloca la responsabilidad en la parte inferior izquierda de tu tarjeta.

Tarjetas CRC

- Ahora podemos decir que ficha puede usar esta responsabilidad de “reglas de juego”, cumpliéndose así el primer paso. Nos queda una cosa más. Como veis, hay una sección de la tarjeta que no hemos rellenado, la derecha. Esa es la sección de los colaboradores. En este paso, ¿Quién es colaborador de quién?.


- ¿Colaborador?.


- Si. Dicho de otra forma: ¿Quién ayuda a quién en el paso de saber si en una casilla hay una ficha de otro color?.


- Las reglas del juego ayudan a la ficha, ya que la ficha se vale de las reglas del juego para conseguir saberlo. – La seguridad de Antonia iba en aumento.


- Correcto. Por tanto, ¿en dónde ponemos el colaborador?.


Ahora ya no estábamos tan seguros.


- Si la ficha hace uso de las reglas del juego, significa que las reglas de juego es un colaborador de la ficha. Colabora con ella para que ésta consiga saber si en la casilla hay una ficha de otro color. – Antonia estaba a tope.


- Veo que está claro, así que seguiremos. Julián, puedes anotar tu colaborador en la tarjeta.

Tarjeta CRC

 

- Podemos continuar. “Reglas de juego” ha devuelto que sí, que en la casilla consultada hay una ficha de diferente color. ¿Cuál es el siguiente paso de nuestro escenario?.


- Matar la ficha. – Antonia lo tenía claro.


- Vale, pero…¿qué es “matar la ficha”?.


- Pues que no juega y la devolvemos a la zona de las fichas que todavía no juegan, como al principio de la partida.


- Entonces, según esta afirmación, lo que hacemos es cambiar que la ficha ya no está en la casilla donde estaba sino en estado, podríamos decir, “en casa”. Bien, ahora lo que necesitamos es saber quién tiene la responsabilidad de enviar una ficha a casa.


Como veía que nadie se animaba…


- Recordad que no queremos saber quién va a utilizar esta responsabilidad, sino que quién la va a satisfacer, ponerla para que otros la utilicen.


- Pues, visto así, creo que esta responsabilidad es de la propia ficha. – No sé porqué, pero cuando dije esta frase no estaba convencido de ella.


- Yo también lo creo. – Sentí alivio cuando Julián decía esto.


- ¿Y los demás?.


Nadie dijo lo contrario.


- Pues si todos estáis de acuerdo, adelante.


- Pero, ¿no nos vas a decir si hemos decidido bien?. -Marcelo era quien hablaba.


- No.


- ¿No? – Insistió Marcelo.


- No. En el análisis y el diseño de software, tenéis que tomar decisiones, y son vuestras decisiones. Es posible que más adelante veáis que alguna decisión anterior no era la mejor posible, y la tendréis que cambiar. Lo importante es, salvo que hagáis alguna barbaridad, que toméis decisiones en base a la lógica y no porque sí.


- Yo lo veo lógico -dije- ya que si se necesita en algún momento de la partida enviar a una ficha a casa, se podrá dar la orden a la ficha correspondiente, para que luego nuestro programa sepa cuáles son las que están “en casa” y cuáles no.


- Ok.- Víctor seguía en su línea.- ¿Puedes, como responsable de la tarjeta de la ficha, incluir esta responsabilidad? -se dirigió a Julián.

Tarjeta CRC

- ¿Y quién es el colaborador en este caso?. -Antonia no esperó a que fuese Víctor quien hiciese la pregunta.


- Buena pregunta. ¿Qué pensáis?. ¿Quién tendrá como colaborador a la ficha para poder darle la orden de “enviar a casa”?.


- Pues no lo tengo muy claro -dije-. Quien primero sabe la existencia de la ficha de diferente color es “reglas de juego”, pero no sé si debe ser ella misma quien de la orden de “enviar a casa” a una ficha.


- Entonces, la duda está entre si la ficha colabora con reglas de juego o con una nueva tarjeta, ¿no?.


- Si.


- Propongo que colabore con reglas de juego. Creo que tiene lógica que dar la orden de enviar una ficha a casa puede estar junto a la responsabilidad “hay ficha de otro color”.


- Tendríamos entonces una tarjeta que hace de árbitro del juego. La hemos llamado “reglas de juego”, pero podría llamarse “árbitro”. Quizá cambiándole el nombre elimina las dudas sobre qué debe cumplir esta tarjeta.


Todos estábamos de acuerdo. Así que Víctor, dirigiéndose a Antonia como responsable de la tarjeta “reglas de juego”, le indicó que le cambiase el nombre. Antonia rehizo la tarjeta de nuevo, ya que no le gustaban los tachones.

tarjeta crc

- Ya tenemos, representados en tarjetas, los pasos de nuestro escenario desde que una ficha se ha movido, hasta que se ha detectado que ha matado a otra y se ha enviado a casa. Ahora nos falta mover la ficha veinte casillas más adelante.


- Si, y es posible que al moverse de nuevo vuelva a caer en una casilla con una ficha de otro color.


- O incluso que antes de cumplir las veinte casillas, llegue al final del recorrido, lo que supone volver hacia atrás el número de casillas que faltan hasta veinte.


- Como veis, saber dónde va a “caer” una ficha es algo importante en el juego del parchís. Tiene toda la pinta de ser una responsabilidad. ¿Qué creéis?.


A todos nos pareció lo suficiente importante como para ser una responsabilidad en sí misma. Además, tenía toda la pinta de ser una responsabilidad del árbitro. No hubo mucho debate.

tarjeta crc

- Si os fijáis, hemos cumplido el escenario ya que se han hecho todos los pasos.


- Pero, ¿qué pasa si ahora que la ficha ya está en una nueva casilla hay de nuevo una ficha de diferente color?.


- Pues el árbitro sabrá qué hacer. Lo importante es que nuestro escenario está listo. Recordad que hay muchos escenarios en un sistema, y que debemos abordar los más importantes primero y abordar los necesarios para hacer un buen diseño.


Víctor miró su reloj.


- Creo que por hoy podemos acabar. Pero antes, me gustaría que os fueseis con unos conceptos claros. Hasta ahora hemos hablado de tarjetas CRC, órdenes, escenarios, responsabilidades, comunicaciones, servicios. Ya sabéis que todo lo que hacemos aquí se basa en el paradigma de la orientación a objetos en lo que al software se refiere. Pues bien, después de haber hecho el escenario, creo que tendréis más claros los siguientes conceptos de dicho paradigma.


- ¿Se refiere a conceptos como el de clase?.


- Si. Pero, por favor, no nos adelantemos. Antes hemos dicho que una tarjeta no representa lo mismo si está en la mesa o si su responsable la coge en alto. Esto, aunque parezca una tontería, no lo es. Cuando está en la mesa, la tarjeta es una definición, pero no se utiliza. Es como los planos de una casa: la casa definida tal y como será pero no la puedo utilizar. Eso es, básicamente, el concepto de clase del paradigma de la orientación a objetos.


Dejó pasar unos segundos.


- Sin embargo, cuando el responsable de dicha tarjeta la coge en alto, está representando que crea una copia de dicha definición para su uso. Es como si se cogieran los planos de la casa y se construyera una con dichas características para poder utilizarla. Esa casa en concreto, es un objeto. En programación, yo puedo utilizar objetos para conseguir hacer los pasos de los escenarios.


Otro par de segundos.


- Al igual que a partir de los mismos planos puedo construir muchas casas, también puedo tener muchos objetos creados a partir de la misma clase. Se dice que cada objeto es una instancia de la clase a partir de la que se creó. Los objetos de una misma clase tendrán las mismas características, aunque no tienen porque tener los mismos valores en dichas características.


Ahora sí que vio caras raras.


- Me explico. Puedo tener la clase vivienda, y además tiene la característica número, siendo éste el número de la calle en donde está la vivienda. Si la clase vivienda tiene esta característica, todos los objetos (todas las viviendas) la tendrán, pero cada una de ellas tendrá su propio número, pudiendo ser diferente o no, ya que los números se repiten dependiendo de la calle en donde está. ¿Queda un poco más claro ahora?.


Dedujo que sí.


- Sigo entonces. Tenemos clase, objeto, ¿qué más?.¡Ah!, también tenemos mensajes entre objetos, que son cada una de las comunicaciones que un objeto hace a otro, o a sí mismo. Normalmente son órdenes desde un objeto a otro, que en su modo más utilizado es el de llamara a una responsabilidad.


- Por hoy ya basta. Mañana nos vemos a las nueve. Por cierto, aunque nadie me lo haya pedido, CRC viene de las palabras Class, Responsibilities, Collaborators.


Y sin esperar que le dijésemos adiós, recogió sus cosas y se fue.


Todos los personajes, lugares y escenas que aparecen en este texto son ficticios y cualquier parecido con la realidad es mera coincidencia.

Artículo original de robiol.org.


Creative Commons License
The Tarjetas CRC. Ejemplo de utilización. by Informática escuela EDIB, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.