analisis crc rpd v01

Programación Avanzada FI-UNER versión 01

Diseño y Análisis Orientados a Objetos a través de Juegos de Rol de Escenarios

Traducción de

Object-Oriented Analysis and Design Through Scenario Role-Play

de

Jürgen Börstler

Departamento de Ciencia de la Computación, Universidad de Umeå, Umeå, Suecia

1 Introducción

El uso de un lenguaje orientado a objetos no garantiza por sí mismo que el software desarrollado será de hecho orientado a objetos. Sin embargo, estos lenguajes proveen conceptos que hacen más sencillo el desarrollo de sistemas siguiendo esta metodología.

“La construcción de software orientado a objetos es el método de desarrollo de software que basa la arquitectura de cualquier sistema en módulos deducidos a partir de los tipos de objetos que manipula (en vez de a partir de la función o funciones que se quiere que el sistema realice).”

(Meyer, 1997, p 116)

En un lenguaje orientado a objetos, los tipos de objetos son descriptos a través de clases. Éstas deben ser desarrolladas de una forma tal que sean simples de entender, mantener y reutilizar. Se han propuesto muchas metodologías o procesos de desarrollo para asegurar esas propiedades (Zamir, 1999). Sin embargo, ninguno de ellos puede garantizar el éxito para todo tipo de problemas. Es siempre responsabilidad del desarrollador: (a) seleccionar un proceso apropiado y (b) tomar todo el tiempo que sea necesario para estudiar el problema y sus implicaciones en detalle.

En esta presentación, nos enfocaremos en el análisis y el diseño. Es importante notar que cualquier tipo de desarrollo de software requiere de actividades adicionales importantes como son, por ejemplo, el testeo y la documentación. Sin embargo, este tipo de actividades están fuera del alcance de esta presentación. Asimismo, no estudiaremos todos los temas relacionados con el diseño de interfaces de usuario.

• El objetivo del Análisis Orientado a Objetos (OOA, Object-Oriented Analysis) es lograr entender completamente el problema y sus implicaciones para sus usuarios potenciales. Mediante él queremos buscar e identificar todas las cosas y conceptos, es decir, objetos, en el dominio de la aplicación que son relevantes para la resolución de este problema en particular. Mediante el uso de estos objetos, sus propiedades e interrelaciones, podemos construir un modelo orientado a objetos del dominio del problema. Este modelo abstracto y simplificado nos ayudará a comprender mejor el problema y a encontrar una solución apropiada.El análisis es independiente del lenguaje de programación y las interfaces de usuario1. Esta independencia tiene numerosas ventajas. No es necesario conocer un lenguaje de

1 Siempre y cuando la interfaz de usuario no sea una parte principal del problema que se quiere resolver.

1


programación y/o software de interfaz de usuario específicos para hacer el análisis. Esto es particularmente importante, ya que el análisis debe ser realizado en estrecha colaboración con los clientes/usuarios. Los clientes/usuarios son expertos en el dominio del problema y no se puede esperar que también tengan un gran conocimiento de ciencia de la computación. Las decisiones sobre los detalles de implementación deben ser pospuestas el mayor tiempo que sea posible. En la fase de análisis, no deberíamos preocuparnos por ellos, ya que esto podría “bloquear nuestras mentes” e impedirnos encontrar una solución elegante , original y creativa.Podemos considerar al modelo de análisis como general e idealizado, y no corrompido por cuestiones de implementación. ¿Cómo podemos identificar los objetos relevantes en el problema? ¿Cuáles son sus propiedades y comportamiento en ese contexto particular? ¿Cómo interactúan entre ellos para llevar a cabo las tareas necesarias? Lo que queremos es encontrar qué es lo que cada objeto conoce y hace, y cómo colaboran los objetos entre ellos.

• El Diseño Orientado a Objetos (OOD, Object-Oriented Design) se basa en los resultados obtenidos en la etapa de análisis. Aquí debemos considerar ciertas cuestiones de implementación (aunque no todas ellas) y describir una solución al problema. Esto incluye decisiones sobre las clases “reales” y sus propiedades. Debemos determinar sus atributos para describir qué es lo que conocen los objetos de una clase. Asimismo, debemos definir métodos para describir el comportamiento de nuestros objetos adecuadamente.En esta etapa no podemos ser completamente independientes de los lenguajes de programación. Puede darse el caso de que necesitemos considerar asuntos como los tipos de datos del lenguaje o la disponibilidad de bibliotecas. Sin embargo, es aconsejable mantener en un nivel mínimo las dependencias a un lenguaje en particular para lograr que el diseño sea lo más general posible.

• El objetivo de la Programación Orientada a Objetos (OOP, Object-Oriented Programming) es la implementación final de una solución en un lenguaje de programación determinado.

Es importante notar que el desarrollo de software es un proceso iterativo. Mientras mayor es el tiempo que uno trabaja con un problema determinado, mejor lo conoce. Por lo tanto, puede ser necesaria la revisión de los modelos de análisis y diseño para reflejar el conocimiento adquirido.

2

Figura 1: desarrollo de software iterativo.


En esta presentación se describe un método sistemático de desarrollo orientado a objetos basado en el Diseño Guiado por Responsabilidades (RDD, Resposability Driven Design) (Wirfs-Brock et al., 1990) y tarjetas CRC (Bellin y Simone, 1997). Las tarjetas CRC son una herramienta simple y sin embargo poderosa para el desarrollo y evaluación colaborativa de modelos orientados a objetos. Estas tarjetas constituyen versiones abstractas de clases potenciales en un sistema de software. Forman un modelo de alto nivel del software que debe ser desarrollado. Este modelo es verificado mediante juegos de rol en diferentes escenarios. Un escenario describe un uso concreto del sistema, es decir, es una especie de caso de prueba. El juego de rol consiste en la ejecución de estos casos de prueba. Durante el juego de rol, los miembros del equipo de desarrollo representan los roles de objetos y actúan los escenarios interactivamente.

Un problema habitual que surge al aplicar esta metodología es que las tarjetas CRC son utilizadas para representar tanto las clases (en las actividades de modelado) como los objetos (en las actividades de juego de rol). Esto suele causar confusión en los novatos. Para evitar este problema fueron desarrollados los diagramas de juegos de rol. Mediante ellos podemos hacer una distinción clara entre las clases (usadas en las actividades de modelado) y los objetos (usados en las actividades de juego de rol). Además, son una herramienta excelente para controlar y documentar las actividades de juego de rol.

2 El poder de los juegos de rol de escenarios

Los juegos de rol de escenarios son usados habitualmente para evaluar el comportamiento humano ante situaciones hipotéticas específicas. Se asignan roles a los participantes, y éstos los actúan en un escenario predefinido, de la misma manera en que los actores siguen un guión cuando interpretan sus personajes en una obra. Durante el juego de rol, los participantes aprenden sobre sí mismos, los otros participantes, y los roles que fueron actuados. El poder de los juegos de rol radica en su interactividad, que fomenta la creatividad y la posibilidad de compartir conocimiento. Además, son una forma efectiva de estimular o explorar situaciones hipotéticas, dado que los personajes y guiones (escenarios) pueden ser modificados en forma sencilla.

En el desarrollo orientado a objetos, los personajes son los objetos en nuestro sistema y los escenarios son situaciones de uso del sistema. Los juegos de rol son usados en las etapas más tempranas del desarrollo, antes de que se haya escrito (o incluso diseñado) ningún fragmento de código. Los “personajes” de la “obra”, por lo tanto, no son más que bosquejos vagamente definidos de clases potenciales que podrían llegar a ser parte del sistema. Los juegos de rol permiten explorar muchas alternativas para modelar el sistema; es decir, brindan una forma de probar el software antes de construirlo.

3 El rol del modelado

El modelado es una actividad humana importante que se realiza en forma cotidiana. Los modelos nos ayudan a comprender una realidad compleja al permitirnos enfocarnos en aquellas propiedades de la “realidad” en las que estamos interesados en un momento en particular. Se ignoran los detalles irrelevantes. A pesar de esto, los modelos que construimos deben reflejar la realidad en la forma más parecida como sea posible. Por ejemplo, un mapa de ruta es un modelo sumamente simplificado de una cierta región de la Tierra, enfocado en lugares interesantes y en las rutas que pueden ser recorridas en auto. Ciertos detalles relevantes para los viajes son incluidos con detalle, como los tipos y longitudes de las rutas y las localizaciones de ciudades, aeropuertos y estaciones de servicio, entre otras cosas. La información relacionada con la topología, geología y vegetación,

3


por ejemplo, es excluida o incluida con un mínimo nivel de detalle. Esto es correcto si lo que nos interesa es viajar desde el lugar A hasta el B, pero inútil para un botánico que busca un tipo particular de flor.

El objetivo del modelado es desarrollar un modelo lo más simple posible de la realidad que sin embargo todavía pueda reflejar todos los aspectos interesantes e importantes en los que estamos interesados. Usando modelos, podemos concentrarnos en los aspectos y fenómenos esenciales de un problema. Los modelos son más simples y fáciles de entender que la realidad, y nos ahorran la pérdida de tiempo de concentrarnos en detalles o aspectos irrelevantes.

En el desarrollo de software, construimos modelos de los sistemas que estamos desarrollando para entenderlos mejor. En el modelado orientado a objetos, nos concentramos en los tipos de objetos manipulados por los sistemas de software. Existen numerosos enfoques para este cometido, pero en esta presentación haremos uso de aquel en el que los objetos son considerados en forma antropomórfica, es decir, los objetos son vistos como entidades vivientes que pueden actuar independientemente y con voluntad propia.

Los objetos que modelamos en el software frecuentemente tienen su contraparte en el mundo real (es decir, en el dominio del problema). Esto puede hacer que el modelado sea una actividad directa, pero también puede causar una cierta confusión. Siempre hay que recordar que lo que modelamos son objetos de software y no sus contrapartes en el mundo real. A menudo ambos compartirán ciertas propiedades, pero en ciertas situaciones unos también tendrán propiedades que los otros no pueden tener. Por ejemplo, si se tiene un objeto que modela a un Libro en una biblioteca, se le puede pedir que se dé de alta a sí mismo, cosa que claramente no pueden hacer los libros reales. Por lo tanto, es muy importante no confundir los objetos del modelo con las “cosas reales”.

Hay que notar que hay varios niveles de modelado. Algunos aspectos, propiedades o detalles que son irrelevantes durante el análisis pueden cobrar importancia durante la implementación. También hay que considerar que no hay un único modelo correcto. Los aspectos del mundo real pueden ser modelados de formas muy diferentes, dependiendo del problema en cuestión. Por ejemplo, las personas serán modeladas en forma distinta en un sistema de registro de inscripciones de una universidad y en un sistema de gestión hospitalario.

4 Tarjetas CRC

Las tarjetas CRC son herramientas simples pero poderosas para el modelado orientado a objetos colaborativo. Fueron usadas para desarrollar, discutir y evaluar modelos orientados a objetos en una manera informal. Originalmente fueron desarrolladas para enseñar a los programadores una forma de pensar “orientada a objetos” (Beck and Cunningham, 1989), pero desde entonces han encontrado un amplio uso fuera de ese contexto (Bellin y Simone, 1997).

CRC es la sigla de Clases, Responsabilidades y Colaboraciones. Una tarjeta CRC es una tarjeta de papel estándar dividida en regiones, como muestra la Figura 2.

4


Clase: Libro

Responsabilidades Colaboradores

sabe si está en préstamo

conoce su fecha de devolución

conoce su título

sabe si está vencido el préstamo Fecha

retirar libro

Figura 2: parte frontal de una tarjeta CRC para la clase Libro.

• Clase: una tarjeta CRC corresponde a una clase, es decir, a una colección de objetos del mismo tipo. Los objetos son cosas de interés en el dominio del problema. Un objeto puede ser una persona, lugar, cosa, evento o concepto. El nombre de la clase es escrito en la parte superior de la tarjeta. Una clase debe tener un propósito único y bien definido que pueda ser descripto en forma breve y clara. El nombre de la clase debería ser un sustantivo, frase nominal o adjetivo que describa en forma adecuada la abstracción. En la parte posterior de la tarjeta se escribe una breve descripción del propósito de la clase.

• Responsabilidades: una responsabilidad es una acción de la que una clase se encarga; un servicio que los objetos de una clase brindan a otros objetos. Puede consistir tanto en conocer algo como en hacer algo. Por ejemplo, un libro en una biblioteca debería conocer, entre otras cosas, su título y si está en préstamo o no. Para hacer algo la clase habitualmente usa el conocimiento que tiene. Si este conocimiento no es suficiente para realizar la labor, la clase puede pedir ayuda a sus colaboradores (ver más abajo). Las responsabilidades de una clase se escriben en el lado izquierdo de la tarjeta.

• Colaboradores: un colaborador es una clase que “ayuda” a llevar a cabo una responsabilidad específica. Por ejemplo, el colaborador puede brindar información adicional, o encargarse de ciertas partes de la responsabilidad (mediante las responsabilidades propias del colaborador). Por ejemplo, un libro puede saber si su préstamo está vencido sólo si conoce la fecha actual; esto puede ser obtenido pidiéndoselo al colaborador Fecha. Los colaboradores se escriben en el lado derecho de la tarjeta, en la misma fila que la responsabilidad correspondiente.

• La parte posterior de la tarjeta puede ser utilizada para la descripción de la clase, comentarios y detalles varios.

Las tarjetas CRC son particularmente adecuadas para un análisis colaborativo. Un grupo de 4 a 6 personas parece ser lo más adecuado. Por lo general los grupos más pequeños sufren la falta de diferentes trasfondos entre los integrantes. En la medida de lo posible, el grupo de análisis CRC debería contar tanto con analistas/desarrolladores como expertos del dominio. Si los grupos son de mayor tamaño, se torna difícil lograr el consenso entre los integrantes. Es de suma importancia NO estancarse en discusiones sobre aspectos de implementación. El objetivo es desarrollar, discutir, evaluar y probar distintos modelos orientados a objetos.

5


En la metodología CRC, consideramos a los objetos como entidades vivientes que pueden actuar con voluntad propia. Cada objeto actúa basándose únicamente en el conocimiento y el comportamiento que figura en su correspondiente tarjeta CRC.

5 Diagramas de juego de rol

Las metodologías comunes basadas en juegos de rol utilizan las tarjetas CRC como si fueran los “personajes” en el juego de rol (Bellin & Simone, 1997). Sin embargo, esto puede resultar confuso para los novatos ya que los conceptos de clase y objetos no pueden ser distinguidos en forma clara. Por esta razón se desarrollaron los diagramas de juego de rol (RPDs, Role-Play Diagrams) para reforzar esta distinción. Además, los RPDs proveen una documentación excelente del juego de rol. También pueden ser utilizados para hacer un seguimiento del juego de rol a medida que éste se desarrolla; esto también permite volver atrás al último estado consistente del juego.

Los RPDs son utilizados para documentar la interacción entre los objetos, que son instancias de las clases modeladas por las tarjetas CRC. Estos diagramas son similares en algunos sentidos a los diagramas UML, pero son más simples e informales y permiten documentar los escenarios en paralelo con las actividades de juego de rol.

Los objetos en los RPDs se denotan mediante tarjetas de objetos. Una tarjeta de objeto es una instancia de una tarjeta CRC que muestra el nombre de la instancia, el nombre de la clase y su conocimiento actual, como se muestra en la Figura 3. Toda la información presentada en la tarjeta de objeto debe coincidir con las responsabilidades de la tarjeta CRC correspondiente; sin embargo, por lo general sólo se indican aquellas propiedades que son relevantes para el juego de rol que se está desarrollando. Por ejemplo, en un sistema de biblioteca podríamos tener la tarjeta de objeto correspondiente al libro 1984 que se muestra en la Figura 3.

Los objetos que “se conocen” entre sí mismos se conectan mediante una línea. Durante el juego de rol, la comunicación entre los objetos sólo es posible si sus tarjetas están conectadas. Una tarjeta de objeto sólo puede estar conectada a los colaboradores indicados en la tarjeta CRC correspondiente. Se pueden crear nuevos objetos, siempre y cuando la correspondiente tarjeta CRC esté listada como colaborador del creador.

Las comunicaciones se describen con leyendas en la forma número : pedido sobre las líneas de conexión, como se puede ver en la Figura 4. Número se refiere al orden de los pedidos, y pedido corresponde al servicio que se solicitó. También se utiliza una flecha en la línea de conexión para

6

Figura 3: tarjeta de objeto para una instancia de la clase Libro.


indicar la dirección del pedido.

Los RPDs siempre deben ser consistentes con las tarjetas CRC. El conocimiento que posee un objeto y los pedidos que éste soporta deben coincidir con las responsabilidades indicadas en la tarjeta CRC. En nuestro ejemplo del sistema de librería, la clase Libro debe tener responsabilidades para ocuparse de los pedidos ¿está en prestamo? y retirar libro, como indica la Figura 5.

Al final de un escenario de juego de rol, el RPD provee una documentación exacta de lo que ocurrió, incluyendo los cambios de estado.

6 Análisis orientado a objetos

El método CRC es especialmente adecuado cuando el problema no está bien definido. Durante el análisis orientado a objetos, se analizan los dominios del problema y de la aplicación para entender el problema en cuestión e identificar las cosas que debería de hecho llevar a cabo el sistema que está siendo desarrollado, y cuáles deberían ser dejadas de lado. Para esto, se llevan a cabo los siguientes pasos:

• encontrar las clases candidatas mediante una lluvia de ideas (brainstorming);

• filtrar la lista de candidatos;

7

Figura 4: un pedido entre tarjetas de objetos conectadas.

Figura 5: Figura 4 después de que el segundo pedido fue ejecutado.


• confeccionar las tarjetas CRC de los candidatos restantes;

• asignar las responsabilidades a las tarjetas CRC/clases;

• definir los escenarios para probar y evaluar nuestro modelo;

• preparar la sesión grupal;

• realizar los juegos de rol de cada escenario usando las tarjetas CRC;

• documentar los escenarios; y

• actualizar las tarjetas CRC y los escenarios para reflejar los descubrimientos hechos.

Hay que notar que estos pasos no siempre se desarrollan en una secuencia estricta. Por ejemplo, suele ocurrir que para filtrar la lista de clases candidatas debemos considerar las posibles responsabilidades de cada una para hacer decisiones adecuadas. Además, los últimos tres pasos siempre se llevan a cabo en paralelo. En las siguientes secciones, desarrollaremos cada uno de estos pasos.

6.1 Encontrar las clases candidatas

El objetivo de este primer paso es generar una lista de clases que pueda ser de interés en el problema considerado. Los objetos de estas clases usualmente deberían tener propiedades y comportamiento. Por ejemplo, un objeto libro en un sistema de biblioteca puede tener las propiedades está en préstamo y el comportamiento calcular la fecha de devolución, entre otros. Si los objetos difieren sólo en los valores de sus propiedades, todos son del mismo tipo y los consideramos como objetos de la misma clase. De esta manera, por ejemplo, todos los libros en una biblioteca podrían ser considerados como objetos de la clase Libro (ver Figura 2).

Si las únicas diferencias entre los objetos Alien y Star Trek son el título y la fecha de registro, los deberíamos considerar como el mismo tipo de objeto. En un sistema de biblioteca simple ambos serían objetos de la clase Material prestable. Sin embargo, si uno de ellos es un video cassete y el otro un disco compacto, podríamos asociarles comportamientos distintos. En este caso, al diseñar un sistema de gestión de video club, Alien y Star Trek serían objetos de las clases Video cassete y Disco compacto, respectivamente.

Los nombres de las clases deberían ser sustantivos, frases nominales o adjetivos, y siempre en singular. Probablemente, cualquier cosa que no pueda ser nombrada cumpliendo estas restricciones no sea un candidato adecuado para una clase (de hecho, tal vez se trate de una responsabilidad, como se verá en la sección siguiente).

La lista de candidatos se debería obtener en una sesión de lluvia de ideas (brainstorming). Para comenzar con ella, se pueden usar las siguientes herramientas que brindan una lista inicial de candidatos:

• Lista: recorra una lista de fuentes típicas de objetos, como pueden ser los siguientes: gente, lugares, cosas tangibles, roles, organizaciones, cosas abstractas, eventos, interacciones, sistema, etc.

• Extracción de sustantivos: subraye todos los sustantivos y frases nominales en la especificación del problema o en cualquier otra documentación disponible. Este método funciona bien, siempre y cuando la documentación no sea demasiado extensa. También hay que tener en cuenta que este método genera mucho “ruido” debido al texto que no es

8


relevante para el problema real.

Hay que recordar que la lluvia de ideas es una técnica para generar ideas, no para evaluarlas. Durante la sesión de lluvia de ideas, no debería haber discusión alguna sobre la adecuación de las clases propuestas. Todos los candidatos deberían ser considerados. Las discusiones deberían ser pospuestas hasta el paso siguiente (filtrado de la lista de candidatos). Es recomendable recorrer a todos los miembros del equipo en turnos (para dar a cada voz una oportunidad de expresarse) y anotar las clases candidatas en un lugar visible para su evaluación posterior (por ejemplo, en un pizarrón). La lluvia de ideas termina cuando el grupo se queda sin ideas, o bien cuando se alcanza un límite de tiempo especificado de antemano (por ejemplo, 30 minutos).

6.2 Filtrar la lista de candidatas

En el segundo paso, evaluamos la lista de clases candidatas. El objetivo es disminuir el número de candidatos a un número manejable, descartando todas las candidatas irrelevantes para el problema.

De acuerdo con Wirf-Brock y Kean (2003), “los candidatos generalmente representan trabajo que su software lleva a cabo, cosas a las que su software afecta, información, control y toma de decisiones, formas de estructurar y organizar grupos de objetos, y representaciones de cosas del mundo real de las que su software debe conocer algo”.

Algunas recomendaciones para filtrar las candidatas son:

• Unir los sinónimos con la clase candidata con el nombre más adecuado.

• Descartar las candidatas que no pueden ser nombradas adecuadamente mediante un sustantivo, frase nominal o adjetivo. Hay que prestar especial atención a los sustantivos que en realidad esconden verbos y/o describen servicios. Estas candidatas son, por lo general, responsabilidades disfrazadas y, por lo tanto, deberían ser documentadas como tales en la tarjeta de una clase candidata adecuada. Por ejemplo, en un sistema de biblioteca podríamos tener las candidatas búsqueda, préstamo y libro derivadas de la oración “... búsqueda y préstamo de libros ...” En este caso, tanto búsqueda como préstamo deberían ser descartadas como candidatas y convertidas en responsabilidades de alguna clase.

• Descartar las candidatas que parezcan insignificantes o vagas, especialmente si no es posible describir su propósito con facilidad.

• Descartar las candidatas que describan detalles de la implementación. El propósito del análisis es modelar el problema, no la solución. Considerar los detalles de implementación demasiado temprano sólo logra restringir el espacio de soluciones.

• Descartar las clases que modelen propiedades (simples) de otras candidatas. Estas se tratan, por lo general, de responsabilidades del tipo conocer de otras candidatas. Por ejemplo, en un sistema de biblioteca los códigos de registro deberían ser modelados como una responsabilidad de la clase Libro, conocer su código de registro, y no como una clase en sí misma.

• Descartar las clases candidatas que no tengan responsabilidad alguna.

• Descartar las candidatas que modelen las interfaces de usuario. Éstas deben ser consideradas como detalles de la implementación. Habitualmente estos detalles no son importes para entender el problema2.

2 Sin embargo, con el fin de hacer que los escenarios de juego de rol sean más intuitivos, supondremos un objeto IU

9


• Descartar las candidatas que estén fuera de la aplicación, como los usuarios y los sistemas externos. Sólo deben ser mantenidos en el diseño si el comportamiento del sistema depende de sus propiedades (es decir, éste necesita mantener datos sobre ellos).

• Descartar las candidatas que estén fuera del dominio del problema. Las clases deberían estar basadas en requerimientos reales o altamente probables. En todo momento hay que tener presente lo que debe hacer el software que estamos desarrollando. Siempre se debería tratar de prever los cambios, extensiones y nuevos requerimientos; aunque de todas formas se debería resolver el problema real. No hay que tratar de resolver el problema equivocado. No hay que hacer al modelo más complicado de lo necesario. En un sistema de biblioteca, por ejemplo, podría ser posible proponer la compra de elementos que no estén disponibles. Sin embargo, hay que evaluar cuidadosamente si esto es requerido en el sistema real.

• Descartar las candidatas que son “nombres” del sistema en sí mismo, como “el sistema” o “la aplicación”. Nuestro objetivo es encontrar un conjunto de clases que entre ellas formen un modelo de nuestro sistema.

• Mezclar las candidatas que representen objetos de la misma clase. Una tarjeta CRC modela una clase, es decir, una colección de objetos del mismo tipo. Es importante poder abstraer los objetos concretos y modelar sólo clases.

• Descartar las candidatas que representen objetos, es decir, instancias. Las tarjetas CRC modelan clases, no objetos. Necesitaremos modelar una clase incluso si hay un único objeto de este tipo en particular3.

• Mezclar las candidatas con responsabilidades que se entrecrucen en gran medida. En estos casos hay que tratar de encontrar una abstracción que cubra todas las candidatas (si es posible). En un sistema de biblioteca, por ejemplo, podrían haber diferentes tipos de elementos que pueden ser prestados, como libros y películas. Si éstos son manipulados en exactamente la misma forma por el sistema, tal vez sea conveniente unirlos en una nueva candidata como, por ejemplo, Material prestable, y tratarlas como si fueran del mismo tipo.

El objetivo de este primer paso es encontrar un conjunto de candidatas útiles. No es necesario encontrar todas las clases definitivas en un primer momento. Seguramente, se irán revelando más clases durante los pasos siguientes.

6.3 Confeccionar las tarjetas CRC

En esta etapa confeccionaremos las tarjetas CRC para las clases candidatas que nos hayan quedado, en la forma que fue descripta anteriormente. Una buena clase captura una abstracción única y bien definida que puede ser identificada adecuadamente por un sustantivo, frase nominal o adjetivo. Asimismo, las responsabilidades de una buena clase pueden ser descriptas clara y brevemente.

Los nombres de las clases deberían ser escogidos con cuidado. Un buen nombre es específico y descriptivo, y puede ser asociado con las responsabilidades que se espera que tenga la clase. En un sistema de biblioteca, Lector sería un mejor nombre que Persona o Cliente para describir a la clase que modela a las personas que toman libros prestados.

(interfaz de usuario) central.

3 Esto, de hecho, es muy común. Las clases con una única instancia también son conocidas como clases Singleton.

10


La parte trasera de la tarjeta debería ser usada para describir breve y claramente el propósito de la clase, para asegurar que el nombre de la clase es interpretado en forma correcta. Si no es posible hacer esto usando sólo unas pocas oraciones, probablemente la clase tenga demasiados propósitos y responsabilidades y deba ser dividida en dos. Hay que asegurarse de que todos los miembros del equipo CRC están de acuerdo con el nombre y propósito de la clase, y de que todos interpretan la descripción en la misma forma.

A pesar de que indicamos que el diseño de la interfaz de usuario está fuera del alcance del método, sugerimos preparar dos tarjetas adicionales: una para la interfaz de usuario y otra para las interfaces con sistemas externos. Sin embargo, éstas no son tarjetas CRC reales. Sólo serán utilizadas para tomar notas sobre aspectos de la interfaz que se deberán tener en cuenta en etapas posteriores.

6.4 Asignar las responsabilidades

Las responsabilidades pertenecen a las clases proveedoras de servicios y, por lo tanto, se documentan en sus tarjetas CRC. Las responsabilidades y la “inteligencia del sistema” deberían estar distribuidas y ser compartidas entre las clases. Ninguna clase debería ser responsable de todo el conocimiento o de todo el comportamiento. Asimismo, todas las clases deberían tener algún conocimiento o comportamiento. Uno puede pensar en los objetos como en entidades vivientes que actúan según su propia voluntad. Cada objeto opera según el conocimiento y el comportamiento que están plasmados en sus tarjetas CRC.

En primer lugar, agregamos las responsabilidades que resultan obvias a partir de la descripción del problema o del dominio de la aplicación. Por ejemplo, en un sistema de biblioteca necesitaremos prestar libros; por lo tanto, parece lógico agregar una responsabilidad retirar a la tarjeta de la clase Libro, dado que los libros tienen el conocimiento necesario para cumplir con esta responsabilidad (ver Figura 2). Para identificar responsabilidades adicionales podemos hacer sesiones adicionales de lluvia de ideas, o identificar los verbos y frases verbales en la descripción del problema, en forma similar a lo que hicimos con los sustantivos en el primer paso. Sin embargo, no es estrictamente necesario encontrar absolutamente todas las responsabilidades en esta etapa. Es suficiente con encontrar un conjunto de responsabilidades clave que provean un punto de partida para los juegos de rol de escenarios.

“Las responsabilidades denotan tanto deberes como poder... un objeto debería cumplir con sus obligaciones, y debería tener la habilidad para llevarlas a cabo” (Biddle et al, 2002). Para cada responsabilidad, debemos determinar si el objeto necesita de colaboradores para realizarla. En caso de que éstos sean necesarios, debemos asegurarnos de que estén equipados con las responsabilidades necesarias. A menudo ocurre que se identifican responsabilidades similares o incluso idénticas para clases diferentes. Esto es evidencia de que debe existir colaboración entre las clases. Sin embargo, hay que notar que dos clases no deberían tener demasiadas responsabilidades en común. Si esto ocurriese, ambas clases se deberían unir ( ver la sección Filtrar la lista de candidatas). Por otro lado, también debería evitarse tener una única clase responsable de todas las cosas importantes en el modelo. Esta clase dominaría todo el modelo y degradaría a las otras al nivel de clases ayudantes “tontas”.

Nuevamente, es importante asegurar que no se discutan detalles de la implementación. Esto no es de interés en esta etapa y, de hecho, es contraproducente, dado que evita la identificación de distribuciones alternativas de responsabilidades.

11


6.5 Definir los escenarios

Los escenarios son los casos de prueba de nuestro modelo CRC. Cada escenario es un ejemplo específico de uso del sistema. Es una especie de guión en una obra de teatro, actuado por los objetos definidos por las tarjetas CRC. Cuando “actuamos” un escenario seguimos las responsabilidades y colaboraciones definidas para probar si nuestro modelo puede manejar las eventualidades que ocurran. Los escenarios describen situaciones concretas del tipo “que pasaría si...”.

Los escenarios deben ser concretos y estar definidos claramente. De otra forma, podemos perdernos fácilmente en los detalles a la hora de ejecutarlos. Un escenario es similar a un caso de prueba tradicional y consta de (1) una función del sistema que debe ser evaluada, (2) datos de prueba (suposiciones), y (3) resultados esperados. A modo de ejemplo, un escenario para un sistema de biblioteca podría ser el siguiente:

Juan Pérez tomará en préstamo el libro 1984; Juan Pérez es un lector registrado y nunca tomó un elemento prestado antes; el libro 1984 está disponible. Después del préstamo, Juan Perez será registrado como lector de 1984, y 1984 tendrá una fecha de devolución válida.

Para validar el modelo serán necesarios muchos escenarios. Por ejemplo, también se debería evaluar lo que ocurriría si Juan Perez no es un lector registrado, si tiene multas pendientes, o libros sin devolver, lo que ocurriría si 1984 está prestado, etc. Es importante definir un número limitado de escenarios que, sin embargo, cubran todas las situaciones de mayor interés.

No es necesario que los escenarios cubran una función del usuario completa, como ocurre en el ejemplo presentado. Es adecuado dividir los escenarios largos y complejos en partes más pequeñas que puedan ser manejadas por separado. Por ejemplo:

El libro disponible 1984 es prestado al lector registrado Juan Pérez.

De esta forma, cuando se ejecutan escenarios complejos podemos saltear los detalles que ya fueron evaluados.

6.6 Preparar la sesión grupal

Un equipo CRC debería consistir en al menos 4-6 personas con experiencias diferentes. Si es posible, debería haber (al menos) analistas/desarrolladores y expertos en el dominio del problema. Antes de que el juego de rol comience, los miembros deberían asegurarse de que están de acuerdo con las descripciones de las clases que figuran en las tarjetas CRC.

Un miembro del equipo debería actuar como secretario. Su misión es documentar el juego de rol a medida que éste se desarrolla y ayudar a que el equipo lo siga. Las tarjetas CRC se deben repartir entre los otros miembros del equipo, de manera que cada uno sea responsable de las tarjetas que le fueron asignadas. Esto quiere decir que cada persona es responsable de todos los objetos correspondientes a sus tarjetas. La actuación se realiza expresando en voz alta lo que un determinado objeto hará al recibir un pedido. Esto debe ser realizado de acuerdo con las responsabilidades indicadas en las tarjetas CRC; no se debe suponer nada que no esté expresado en ellas. Además, un objeto sólo puede actuar cuando es su “turno”. El secretario puede actuar cuando es necesaria la interacción con el usuario o los dispositivos externos.

Durante los primeros juegos de rol, iremos descubriendo muchos detalles nuevos. Serán necesarios muchos escenarios para que el modelo se estabilice. Es recomendable empezar con escenarios simples que correspondan a “casos normales”. De otra forma, hay una alta probabilidad de perderse en discusiones sobre un número elevado de detalles faltantes.

12


6.7 Realizar los juegos de rol de cada escenario

Mediante los escenarios simulamos la forma en que el sistema funcionará dejando de lado, por ahora, los detalles de implementación y cuestiones relacionadas con la interfaz de usuario y las interfaces con otros sistemas.

El método CRC tiene una visión antropomórfica de los objetos, es decir, los interpreta como entidades vivas que actúan según voluntad propia. Además, cada uno tiene una visión centrada en sí mismo. Por ejemplo, un objeto libro en un sistema de biblioteca tendría la siguiente visión: “Hola, soy el libro XYZ, ¿que puedo hacer por usted?” No debería ser necesario preguntar a otros objetos sobre cosas específicas que los libros deberían saber por sí mismos (por ejemplo, si están prestados o no).

Antes de empezar el juego de rol, repasaremos las suposiciones hechas en el escenario seleccionado. En el ejemplo “Juan Perez tomará prestado el libro 1984”, presentado en secciones anteriores, tenemos las siguientes suposiciones: (1) explícitamente mencionamos que Juan Pérez es un lector registrado que nunca antes tomó un préstamo, por lo que no tiene multas; (2) el libro está disponible (es decir, no está prestado). En este momento debemos preparar un diagrama de juego de rol (RPD) que modele una situación inicial adecuada. Para simplificar el juego de rol, suponemos que hay un objeto que centraliza la interfaz con el usuario y con sistemas externos (en caso de que tales interacciones existan).

Una situación inicial posible para un sistema de biblioteca simple podría ser la que se muestra en la Figura 6. En este RPD hemos supuesto que hay dos libros y dos lectores4. Hemos supuesto la existencia de un objeto Bibliotecario que conoce a todos los libros y lectores registrados. Además, suponemos que el objeto laInterfaz sólo conoce al objeto Bibliotecario.

4 Para el juego de rol, dos libros y dos lectores son suficientes. Agregar más objetos de cualquiera de las dos clases haría que el escenario sea más realista, pero no agregaría nada a su complejidad inherente.

13


¿Qué significa el escenario Juan Pérez tomará prestado el libro 1984 para nuestro sistema? ¿Cómo traducimos este requerimiento a una responsabilidad de un objeto?

• ¿Qué objeto comenzará a realizar el trabajo que debe hacerse? Hay que marcar la tarjeta correspondiente en el RPD como “activa” y darle el “control” al miembro del equipo que tiene esa tarjeta.

• ¿Qué es lo que el objeto activo necesita para realizar el trabajo solicitado? ¿Tiene todas las responsabilidades necesarias para cumplir con el pedido? El objeto activo debe decir en voz alta todas las acciones que realizará. Por ejemplo, ante el pedido en préstamo, el objeto unLibro de la figura 4 podría responder de esta forma:“Tengo la responsabilidad de conocer si estoy prestado o no (consultar la tarjeta CRC correspondiente en la Figura 2). Actualmente no estoy prestado (consultar la tarjeta de objeto unLibro en la Figura 4). La respuesta es no.”5

Una vez que un pedido fue ejecutado exitosamente, el control vuelve al objeto que lo efectuó.Si se descubre que faltan responsabilidades en una tarjeta CRC, se deben agregar y actualizar las tarjetas de objeto en concordancia. Si faltan demasiadas responsabilidades

5 El objeto unLibro es una instancia de la clase Libro. Por lo tanto, el miembro del equipo que sea responsable de la clase Libro debe “actuar” estar parte del escenario.

14

Figura 6: posible situación inicial para el escenario Juan Pérez tomará prestado el libro 1984 con laInterfaz marcada como activa.


como para poder continuar con el juego de rol, hay que detenerlo y revisar el modelo CRC antes de continuar.

• ¿Hay otros objetos con los que su objeto debe colaborar? ¿Están sus tarjetas de objeto presentes en el diagrama RPD? ¿Están sus tarjetas de objeto conectadas con la del objeto actual? Hay que recordar que la comunicación sólo es posible entre tarjetas de objeto conectadas. Un objeto puede colaborar con otro objeto sólo si conoce exactamente quien es su colaborador.6

A medida que hagan falta, hay que agregar al RPD las tarjetas de objeto necesarias, y hay que conectarlas a los objetos que saben sobre ellas. Hay que considerar cuidadosamente la forma en que un objeto “nuevo” es creado y cuál es el objeto responsable de su creación. También hay que tener en cuenta la forma en que los objetos “se conocen” entre ellos. Un objeto siempre conoce los objetos que él creó. Cualquier otro objeto debe ser “anunciado” de alguna forma. Esto puede hacerse, por ejemplo, a través de un pedido que lleve esta información (como en el pedido 3: tomar prestado el libro1 de la Figura 7). Los colaboradores también pueden ser obtenidos como resultado de este pedido. Un pedido de búsqueda de un libro en particular puede devolver un objeto libro específico.

• Hay que tener cuidado de no saltear detalles que parecen ser obvios (“el demonio suele ocultarse en los detalles”). Es importante recorrer el escenario cuidadosamente y paso a paso. Sin embargo, a veces será necesario saltear algunos detalles para poder terminar con el escenario. En estos casos hay que asegurarse de que estos detalles serán considerados más tarde, tal vez en la forma de un escenario adicional.

6.8 Documentar los escenarios

El secretario documenta los escenarios a media que estos son ejecutados en el juego de rol. Para esto, registra todas las actividades y actualiza los RPD. Esta documentación es útil en muchos sentidos.

• Durante el juego de rol, el equipo CRC puede ver fácilmente el conocimiento actual de los objetos involucrados, o si dos objetos pueden comunicarse. Esto permite que el juego de rol continúe y minimiza la cantidad de detalles que el equipo tiene que memorizar.

• Los escenarios completados pueden ser “jugados” de nuevo para verificar que todavía funcionan.

• Los diagramas pueden ser utilizados para explicar a terceros la forma en que el sistema funciona.

• Si uno se pierde durante un escenario, es fácil retroceder unos pasos para encauzar el juego de rol.

• Sirven a modo de guía para la implementación del sistema.

• Pueden ser utilizados como una documentación del sistema.

En la Figura 7 se muestra el RPD al que se llega al finalizar el escenario Juan Pérez tomará prestado el libro 1984. Luego de completar un escenario, el “control” vuelve al objeto inicial (es decir, laInterfaz, consultar Figura 6). Es importante notar que la línea que conecta a libro1 con 6 El modelo CRC es estático, es decir, en las tarjetas CRC sólo se documenta la clase de un colaborador. El objeto

real necesitado para la colaboración será determinado, por lo general, dinámicamente durante el juego de rol, es decir, la ejecución.

15


lector1 no está disponible al comienzo del escenario. Fue dibujada luego del pedido 3, es decir, cuando el objeto bibliotecario identificó a los objetos en cuestión y le dice al lector1 a qué libro debe conectarse.

6.9 Actualizar las tarjetas CRC y los escenarios

Durante el juego de rol, probablemente nos daremos cuenta de que el modelo inicial estaba incompleto, era inconsistente o, incluso, estaba parcialmente equivocado. El juego de rol revela muchos de los problemas que deben ser arreglados. Cuando estos problemas son detectados, deben ser discutidos y resueltos en forma apropiada. Todos los cambios que se hagan al modelo deben ser hechos en forma consistente. Siempre que se cambie una tarjeta CRC, hay que asegurarse de que los escenarios y RPD se actualizan en concordancia. Si los cambios son extensos, puede ser necesaria la inclusión de nuevos escenarios para probar las partes nuevas o modificadas.

Las responsabilidades o colaboradores faltantes se pueden agregar a las tarjetas CRC durante el juego de rol. Hay que tener cuidado de distribuir las responsabilidades de acuerdo con los

16

Figura 7: RPD de la Figura 6 después de completar el escenario Juan Pérez tomará prestado el libro 1984.


lineamientos presentados en la sección Asignar las responsabilidades. Si una tarjeta CRC no tiene espacio para nuevas responsabilidades, se debería considerar dividirla en dos clases.

6.10 Ventajas del método CRC/RPD

Las tarjetas CRC son una herramienta simple pero poderosa para el modelado orientado a objetos colaborativo. Ayudan a explorar el espacio del problema y a comprenderlo mejor. Mediante el uso de juegos de rol de escenarios, muchos modelos orientados a objetos pueden ser utilizados en una etapa temprana del desarrollo del software. El método descripto aquí brinda un buen entendimiento de los objetos, las responsabilidades y las interacciones involucradas en la solución al problema.

Las principales ventajas pueden ser resumidas en los siguientes puntos:

• El método es sencillo e independiente de los lenguajes de programación. Esto lo hace adecuado para el modelado colaborativo en equipos compuestos por miembros con trasfondos diferentes (analistas, desarrolladores, usuarios, etc).

• Las tarjetas CRC y los RPDs forman una documentación excelente de la fase de análisis y del diseño inicial del sistema. Mediante los RPD se puede ver fácilmente cómo se supone que funcionan las clases.

• Mediante los juegos de rol de escenarios, se pueden probar fácilmente modelos alternativos usando tarjetas CRC distintas. Esto permite hacer muchas pruebas mucho antes de que sea necesario escribir código.

7 Referencias

Beck, K., Cunningham, W. (1989). A Laboratory for Teaching Object-Oriented Thinking. Proceedings OOPSLA’89. 1-6.

Bellin D., Suchman Simeone, S. (1997). The CRC Card Book. Reading, MA: Addison-Wesley.

Biddle, R., Noble, J., Tempero, E. (2002). Reflections on CRC Cards and OO Design. Proceedings TOOLS Pacific 2002.

Booch, G. (1994). Object-Oriented Analysis and Design with Applications, 2nd Edition. Redwood City, CA, USA: Benjamin/Cummings.

Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1994). Design Patterns. Reading, MA: Addison-Wesley.

Lieberherr, K.J., Holland, I.M. (1989). Assuring Good Style for Object-Oriented Programs. IEEE Software 6 (5), 38-48.

Meyer, B. (1997). Object-Oriented Software Construction. Englewood Cliffs, NJ: Prentice Hall.

Wilkinson, N. (1995). Using CRC Cards, An Informal Approach to Object-Oriented Development. New York, NY: SIGS Publication.

Wirfs-Brock, R., Wilkerson, B., Wiener, L. (1990). Designing Object-Oriented Software. Upper Saddle River, NJ: Prentice Hall.

Wirfs-Brock, R., McKean, A. (2003). Object Design--Roles, Responsibilities, and Collaborations. Boston, MA: Addison-Wesley.

Zamir, S. (editor) (1999). Handbook of Object Technology. Boca Raton, FL: CRC Press.

17

analisis crc rpd v01

Documents