|
A fines de la década de 1980, uno de los centros más grandes de tecnología de objetos era el laboratorio de investigación de Tektronix, en Portland, Oregon, Estados Unidos. Este laboratorio tenía algunos de los principales usuarios de Smalltalk y muchas de las ideas clave de la tecnología de objetos se desarrollaron allí. Dos de sus programadores renombrados de Smalltalk eran Ward Cunningham y Kent Beck.
Tanto Cunningham como Beck estaban y siguen preocupados por cómo enseñar los profundos conocimientos de Smalltalk que habían logrado. De esta pregunta sobre cómo enseñar objetos surgió la sencilla técnica de las tarjetas de Clase-Responsabilidad-Colaboración (CRC).
En lugar de utilizar diagramas para desarrollar modelos, como lo hacían la mayoría de los metodólogos, Cunningham y Beck representaron las clases en tarjetas 4 x 6 [pulgadas]. Y en lugar de indicar atributos y métodos en las tarjetas, escribieron responsabilidades.
Ahora bien, ¿qué es una responsabilidad? En realidad es una descripción de alto nivel del propósito de una clase. La idea es tratar de eliminar la descripción de pedazos de datos y procesos y, en cambio, captar el propósito de la clase en unas cuantas frases. El que se haya seleccionado una tarjeta es deliberado. No se permite escribir más de lo que cabe en una tarjeta (véase la figura 4-4).
|
Nombre de la Clase : Pedido |
|
|
Responsabilidad |
Colaboración |
|
Revisa si hay elementos en existencia |
Línea de pedido |
|
Determina precio |
Línea de pedido |
|
Revisa si el pago es válido |
Cliente |
|
Despacha a la dirección de entrega |
|
Figura 4-4 Tarjeta de Clase-Responsabilidad-Colaboración (CRC)
La segunda C se refiere a los colaboradores. Con cada responsabilidad se indica cuáles son las otras clases con las que se tiene que trabajar para cumplida. Esto da cierta idea sobre los vínculos entre las clases, siempre a alto nivel.
Uno de los principales beneficios de las tarjetas de CRC es que alientan la disertación animada entre los desarrolladores. Son especialmente eficaces cuando se está en medio de un caso de uso para ver cómo lo van a implementar las clases. Los desarrolladores escogen tarjetas a medida que cada clase colabora en el caso de uso. Conforme se van formando ideas sobre las responsabilidades, se pueden escribir en las tarjetas. Es importante pensar en las responsabilidades, ya que evita pensar en las clases como simples depositarias de datos, y ayuda a que el equipo se centre en comprender el comportamiento de alto nivel de cada clase.
Un error común que veo que comete la gente es generar largas listas de responsabilidades de bajo nivel. Este procedimiento es completamente fallido. Las responsabilidades deben caber sin dificultad en una tarjeta. Yo cuestionaría cualquier tarjeta que tenga más de tres responsabilidades. Plantéese la pregunta de si se deberá dividir la clase y si las responsabilidades se podrían indicar mejor integrándolas en enunciados de un mayor nivel.
Algunos consideran maravillosas las tarjetas de CRC; en cambio, a otros, esta técnica los deja indiferentes.
Yo considero definitivamente que se deberían probar, a fin de saber si al equipo de trabajo le gusta trabajar con ellas. Se deben usar, en particular, si el equipo se ha empantanado en demasiados detalles o si parecen identificar clases apelmazadas y carentes de definiciones claras.
Se pueden emplear diagramas de clase y diagramas de interacciones y para captar y formalizar los resultados del modelado CRC en un diseño con notación de UML. Asegúrese de que cada clase en su diagrama de clase tiene un enunciado de sus responsabilidades.
Desafortunadamente, Cunningham y Beck no han escrito un libro sobre las CRC, pero usted puede encontrar su artículo original (Beck y Cunningham 1989) en la Web http://c2.com/doc/oopsla89/paper.html. En general, el libro que mejor describe esta técnica y, de hecho, todo el concepto del uso de responsabilidades es el de Rebeca Wirfs-Brock (1990). Es un libro relativamente viejo según las normas de la OO, pero se ha añejado bien.
Fowler, Martín
UML, gota a gota
Addison Wesley Longman de México,SA de CV
México 1.999
ISBN: 968-44-364-1
Formato 17x23
Paginas 224
| © 2.003 - La Güeb de Joaquín - Apuntes Tácticos - UML |
| [Arriba] [Home] [Apuntes] [UML] [Correo] |
|
La documentación es como el sexo: cuando es bueno, es muy, muy bueno; y cuando es malo, es mejor que nada. Fecha de la última actualización.: 18 / Septiembre / 2003 
|