Una guía completa sobre el modelado CRC (Clase Responsabilidad Colaborador)
Basado en los principios fundamentales del análisis orientado a objetos (OO), esta guía describe el proceso de modelado CRC. El modelado CRC es una metodología altamente efectiva y de bajo costo diseñada para cerrar la brecha de comunicación entre desarrolladores y usuarios, asegurando que los requisitos del negocio se identifiquen y comprendan con precisión antes de escribir código.
1. Conceptos clave: La anatomía de una tarjeta CRC
El modelado CRC se basa en tarjetas de índice estándar divididas en tres secciones distintas. Cada sección representa un concepto fundamental en el diseño orientado a objetos.
A. Clase (Parte superior de la tarjeta)
Una clase representa una colección de objetos similares. Un objeto puede ser una persona, lugar, cosa, evento, concepto, pantalla o informe relevante para el sistema.
-
Regla de nombrado: Utilice una o dos palabras en singular (por ejemplo, Cliente, no Clientes).
-
Ejemplo: En un sistema de envíos/inventario, las clases incluyen Artículo de inventario, Pedido, Artículo de pedido, Cliente, y Dirección superficial.
B. Responsabilidad (Columna izquierda)
Una responsabilidad es cualquier cosa que una clase sabe o hace.
-
Lo que sabe (Datos/Propiedades): Ejemplo: Un Cliente la clase sabe su nombre, número de cliente y número de teléfono.
-
Lo que hace (Comportamientos/Métodos): Ejemplo: Un Cliente la clase puede ordenar productos, cancelar pedidos y realizar pagos.
C. Colaborador (Columna derecha)
La colaboración ocurre cuando una clase necesita información o ayuda de otra clase para cumplir con una responsabilidad.
-
Ejemplo: Un Pedido el objeto tiene la responsabilidad de «calcular el total». Sin embargo, no conoce el precio de los artículos ni la cantidad pedida. Por lo tanto, debe colaborar con Artículo de Pedido (que conoce la cantidad) y Artículo de Inventario (que conoce el precio) para calcular el total final.
2. El equipo de modelado CRC
Una sesión de CRC exitosa requiere roles específicos para garantizar que el proceso transcurra sin problemas y capture con precisión la lógica del negocio.
-
Expertos en el Dominio del Negocio (EDN): Los usuarios reales del sistema (típicamente 4 a 5 empleados de primera línea). Poseen el conocimiento cotidiano del negocio. Nota: Los ejecutivos generalmente no son ideales para CRC; son más adecuados para casos de uso de alto nivel.
-
Facilitador: Dirige la sesión, explica la técnica, formula preguntas pertinentes, asegura que las tarjetas se llenen correctamente y lidera la prueba de escenarios.
-
Apuntador(es):1 o 2 personas que se sientan en la parte de atrás/lados. No participan activamente en el modelado, sino que registran la lógica y las reglas empresariales detalladas que no caben en las pequeñas tarjetas.
-
Observadores:Aprendices o partes interesadas que se sientan en la parte de atrás y observen sin participar.
3. El proceso de modelado CRC de 6 pasos
Paso 1: Reunir al equipo
Reúna de 4 a 5 BDE de primera línea, un facilitador y 1 o 2 escribanos. Asegúrese del apoyo de la gerencia para que los participantes puedan dedicar el tiempo necesario.
Paso 2: Organizar la sala
-
Superficies escribibles:Pizarras o pizarras blancas para la generación de ideas y prototipado.
-
Mesa de modelado:Una mesa grande y central para que los BDE coloquen y muevan las tarjetas.
-
Puestos de escribanos:Mesas colocadas fuera del camino pero con una vista clara.
-
Suministros:Tarjetas de índice, marcadores y unapelota suave y esponjosa(utilizada más adelante para la prueba de escenarios).
Paso 3: Generar ideas
Genere ideas sin evaluarlas. El facilitador formula preguntas abiertas para comprender las necesidades empresariales.
-
Preguntas de ejemplo:¿Para quién es este sistema?, ¿Qué necesidades empresariales satisface?, ¿Cómo podemos hacer esto más rápido/más barato/mejor?, ¿Hay tareas triviales que podamos automatizar?
Paso 4: Explicar la técnica
El facilitador dedica de 10 a 15 minutos a explicar los conceptos CRC, mostrando prominentemente las definiciones en la pared y guiando al equipo para crear unas cuantas tarjetas de ejemplo.
Paso 5: Modelado CRC iterativo
Los BDE se paran o se sientan alrededor de la mesa y construyen el modelo de forma iterativa:
-
Buscar clases:Siga el dinero, busque informes/pantallas y identifique de inmediato las 3 a 5 clases principales.
-
Buscar responsabilidades:Pregunte qué sabe y hace la clase.
-
Definir colaboradores:Identifique quién posee la información faltante necesaria para cumplir con una responsabilidad.
-
Organice las cartas: Paso crucial.Las cartas que colaboran con frecuencia se colocan cerca unas de otras sobre la mesa. Las cartas «ocupadas» van en el centro. Mover las cartas físicamente ayuda al equipo a visualizar relaciones y asociaciones.
Paso 6: Prueba de escenarios de casos de uso (Ejercicio del «lanzamiento de la pelota»)
Esta es una prueba de validación en la que el equipo «interpreta» los flujos de trabajo del sistema para asegurarse de que el modelo sea preciso.
-
Llame un escenario:El facilitador describe un caso de uso (por ejemplo, «El cliente realiza un pedido») y lanza la pelota blanda al BDE que sostiene la carta responsable inicial (por ejemplo, Pedido).
-
Determine la responsabilidad:El grupo confirma que la carta maneja la tarea. Si no es así, actualizan o crean una nueva carta.
-
Describa la lógica:El BDE que sostiene la pelota describe paso a paso la lógica del negocio (código pseudocódigo) al redactor.
-
Colabore:Si el BDE necesita información de otra clase (por ejemplo, Artículo de inventario), lanza la pelota al BDE que sostiene esa carta. Ese BDE luego describe su parte de la lógica.
-
Pase la pelota de vuelta:Una vez que una tarea se completa, la pelota se lanza de vuelta a la persona anterior, regresando finalmente al facilitador para iniciar el siguiente escenario.
4. Cómo encaja CRC en el ciclo de vida del desarrollo de software
La modelización CRC no existe en el vacío; forma parte de un proceso más amplio de modelización orientada a objetos que es serial en gran escala (pasando de los requisitos al diseño al código) y iterativo en pequeña escala (que salta entre modelos).
-
Nivel de detalle:CRC se encuentra en medio. Comienza de forma sencilla con Casos de uso y Prototipos de interfaz de usuario, pase al detalle medio de Modelos CRC, y termine con el detalle alto de Diagramas de clases.
-
Los entregables impulsan los entregables:Los diagramas de casos de uso se documentan mediante casos de uso, que se documentan mediante diagramas de secuencia, que finalmente generan código fuente. Los modelos CRC alimentan directamente el diagramado de clases.
5. Mejores prácticas y consejos para el éxito
-
Envíe un orden del día:Distribuya un orden del día unos días antes para que los BDE puedan prepararse.
-
Muestre las definiciones:Pegue una disposición grande de tarjetas CRC y sus definiciones en la parte delantera de la sala.
-
Use terminología del dominio:Evite el jergón técnico; use exactamente las palabras que los BDE usan en sus trabajos diarios.
-
Manténgalo de bajo nivel tecnológico:Las herramientas para CRC son opcionales. Las tarjetas de índice son económicas, portátiles y muy efectivas.
-
Espere prototipar:Dibujar pantallas y informes en pizarras durante la sesión ayuda a los usuarios a visualizar el sistema.
-
Planee varios días:Los sistemas grandes requieren varias sesiones. Esto es normal y necesario.
-
Obtenga el apoyo de la gerencia:Asegúrese de que la dirección entienda el valor de modelar antes de codificar.
-
Diríjase al personal de primera línea:CRC es altamente detallado y funciona mejor con usuarios diarios, no con ejecutivos de alto nivel.
6. Ventajas y desventajas
Las ventajas
-
Los expertos realizan el análisis:Las personas que realmente hacen el trabajo construyen el modelo.
-
Alto compromiso del usuario:La participación activa aumenta la satisfacción del usuario y su sentido de propiedad.
-
Rompe las barreras:Los usuarios y los desarrolladores trabajan lado a lado.
-
Simple y no amenazante:Son solo tarjetas de índice. Los usuarios no se sienten intimidados por herramientas de software complejas, y no sienten que sus trabajos están siendo automatizados por una “máquina”.
-
Económico y portátil:Cuesta unos cuantos dólares y cabe en una maleta.
-
Transición sin problemas:Se combina perfectamente con la prototipación y conduce directamente a diagramas de clases formales.
Las desventajas
-
Amenazante para algunos desarrolladores:Algunos desarrolladores creen erróneamente que su conocimiento técnico supera el conocimiento empresarial de los usuarios.
-
La programación es difícil:Reunir a 4 o 5 usuarios clave en una misma sala al mismo tiempo requiere planificación anticipada.
-
Las tarjetas tienen limitaciones:Una pila de tarjetas de índice no es un entregable formal aceptable para la mayoría de las organizaciones. CRC debe complementarse con casos de uso formales, prototipos y diagramas de clases.
Conclusión
El objetivo final del desarrollo de aplicaciones esresolver problemas empresariales, no para satisfacer la curiosidad intelectual de un desarrollador con nuevas tecnologías. La modelización CRC obliga a los desarrolladores a trabajarconcon los usuarios en lugar de en contra de ellos. Al utilizar un entorno de baja tecnología altamente colaborativo, los equipos pueden capturar, validar y refinar con precisión los requisitos empresariales antes de escribir una sola línea de código.
