3.4. TARJETAS CRC 3.4.1 Introducción A fines de la década de 1980, uno de los centros mas grandes de tecnología de objetos era el laboratorio de investigación de Tektronix en Pórtland, 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 ahí. Dos de sus programadores mas renombrados de Smalltalk fueron Ward Cunningham y Kent Beck. Tanto Cunningham como Beck estaban y siguen preocupados de como enseñar los profundos conocimientos de Smalltalk que habían logrado. De esta pregunta sobre como 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 metodologos, Cunningham y Beck representaron las clases en tarjetas de 4x6 pulgadas, y en lugar de indicar atributos y métodos en las tarjetas, escribieron responsabilidades. Esta metodología lleva acabo la utilización de contratos en donde se especifican los requerimientos del cliente-servidor. Es aquí en donde se pretende encontrar las responsabilidades que se deben cumplir, utilizando de manera clara los requerimientos que desea el cliente que el servidor cumpla, como prácticamente en base a estas responsabilidades se conocen los requerimientos. Por lo tanto, dichas responsabilidades se utilizan para llenar las tarjetas CRC. Qué es un sistema basado en contrato? Es un sistema basado en la dualidad cliente servidor en donde se cuenta con la descripción de que hace tanto el cliente como el servidor.! Cliente: es el agente que envía un mensaje y solicita un servicio.! Servidor: es el agente que recibe el mensaje y proporciona un servicio! Contrato: lista de requerimientos que posteriormente se convierten en responsabilidades. Esto es lo que define a un sistema de contrato. 3.4.2 El Juego del Pacman. Se dará a conocer el planteamiento de un problema para poder explicar mejor el proceso de las tarjetas CRC. Planteamiento del problema. Se simulara el juego del Pacman en el que intervienen los siguientes elementos: Un Laberinto que contiene: Pacman. Fantasma. _N.. Fruta. Borde. 76
El juego inicia cuando se mueve el Pacman, a su paso puede encontrar _N,, Fantasma o Fruta. Cuando el Pacman come _N incrementa su puntuación y al ser comida la _N desaparece del Laberinto. Pero si el Pacman come una el Pacman incrementa el número de vidas y su velocidad, el Fantasma cambia su color indicando que el Pacman puede comérselo. Cuando el Pacman se come una Fruta, se incrementa su número de vidas y su puntuación. El Fantasma tiene la función de perseguir al Pacman para comérselo y así decrementar su número de vidas. Cuando el Pacman pierde una vida, si es la última termina el juego, si no vuelve a comenzar. Una vez que el Pacman se ha comido el conjunto de s_n, incluyendo las s_m antes de que sea comido por un Fantasma, se incrementa el número de vidas del Pacman y comienza nuevamente el juego. 3.4.3 Proceso de Desarrollo 3.4.3.1 Clases La clase representa una colección de objetos similares. Aquí es donde se encuentran todas las clases involucradas en el sistema. Para localizar estas clases se recomienda lo siguiente: 1. Listar todas las clases: Listar las clases que se encuentren en la especificación de requerimientos. 2. Modelar los objetos físicos: Las instancias de aquellas clases que son físicas que se pueden tocar, tienen que ser modeladas. 3. Modelar las entidades conceptuales. 4. Seleccionar de varios conceptos iguales el que más represente o describa al objeto 5. Tener cuidado con los adjetivos. 6. Tener cuidado con oraciones que tengan sujetos engañosos. 7. Modelar categorías; reconocer superclases, subclases y clases abstractas. 8. Modelar interfaces del sistema. 9. Modelar valores de atributos, no los atributos mismos. 10. Localizar la parte interactiva con el sistema o parte del sistema 11. Usar una o dos palabras que describan la clase. Registro de clases Después de haber identificado las clases, mediante el análisis de las especificaciones de requerimientos, es necesario llenar una tarjeta, la cual contiene tres partes: NOMBRE DE LA CLASE: Figura # 66! En la parte superior se coloca el nombre de la clase, al reverso de la tarjeta se recomienda escribir una breve descripción del propósito de la clase.! Se escribe una tarjeta para cada clase encontrada en los requisitos. 77
! Cuando una clase tiene una superclase o subclase puede ser representada de la siguiente forma: NOMBRE CLASE: SUPERCLASE(S): SUBCLASE (S): Figura # 67 De acuerdo con el ejemplo del Pacman, se identificaron las siguientes clases:! Pacman!! _N! Borde!! Laberinto! Fruta! Fantasma Se presentará en forma de tarjeta CRC la clase Pacman: Pacman: Figura # 68 3.4.3.2 Responsabilidades Una responsabilidad es algo que una clase conoce o hace. Son todos los servicios que un objeto puede realizar y que mantiene en un contrato que tiene con otros objetos. Cabe recordar que el contrato entre 2 clases representa una lista de servicios. Un servicio puede realizar una acción o regresar alguna información. Las responsabilidades representan la parte pública de los objetos, debido a que un contrato cliente-servidor no se necesita conocer como se hacen las cosas, sino que cosas se hacen. Identificación de las responsabilidades Para llevar acabo la identificación de las responsabilidades se usan dos fuentes, la especificación de requerimientos y las clases que ya han sido identificadas. 78
La Especificación de requerimientos: volver a leer el documento e identificar los verbos que representan acciones que un objeto puede tomar y hacer dentro del sistema. Las Clases: una vez que se ha analizado y realizado esta etapa se puede usar la información con la que se cuenta y así poder usar la descripción de la clase para poder identificar sus responsabilidades las cuales deberá cumplir el objetivo de la creación de dicha clase. Recomendaciones para identificar responsabilidades 1. Preguntar que clases se conocen. 2. Preguntar que clases se hacen. 3. Si ya se tiene identificada la responsabilidad preguntar que clase seguirá. 4. Clases que colaboraran para el llenado de muchas de sus responsabilidades. 5. Establecer responsabilidades generales. 6. No permitir información duplicada de objetos. Identificar clases mediante sus relaciones con otras clases Otra forma que existe para identificar las responsabilidades es mediante las relaciones que hay entre las clases. Se encuentran tres tipos de relaciones:! Es un tipo de! Es igual que! Es parte de! Es un tipo de: Esta relación es un tipo que representa una relación de subclase que hereda una super-clase.! Es igual que: Cuando dos clases son análogas quiere decir que pueden tener una super-clase común, lo cual indica también que pueden tener las mismas responsabilidades.! Es parte de: Cuando una clase, esta compuesta de otras clases pero no de su comportamiento Registro de responsabilidades Por cada tarjeta CRC que se tiene, en la parte inferior izquierda colocar todas las responsabilidades para dicha clase. CLASES: RESPONSABILIDADES Figura # 69 79
Si la clase tiene muchas responsabilidades, las cuales no pueden ser mostradas en una sola tarjeta esto es signo de que no hay dominio del problema. Tomando del Pacman la lista de responsabilidades encontradas en el ejemplo.! Pacman empieza a caminar sobre el laberinto y come píldoras! Pacman es perseguido por el Fantasma.! Pacman puede comer Frutas! Pacman pierde una vida cuando un Fantasma lo atrapa Se representan de la siguiente manera: Pacman Pacman puede comer Frutas Pacman camina sobre Laberinto Pacman pierde una vida cuando el Fantasma lo atrapa Figura # 70 3.4.3.3 Colaboraciones Las colaboraciones representan peticiones de un cliente a un servidor para cumplir la responsabilidad del cliente. Las colaboraciones representan los contratos que hay entre la clase cliente y la(s) clase(s) servidor(es). Para cumplir una responsabilidad no necesariamente debe existir una colaboración con otros objetos ya que una misma clase puede cumplirla, debido a que conoce toda la información para realizarla. Las colaboraciones son importantes porque demuestran el flujo de control e información durante la ejecución del sistema, además que determinan en un contrato los roles de cada clase. Identificar colaboraciones Para identificar las colaboraciones es necesario analizar como interactúa cada clase. Examinar las responsabilidades de cada clase para saber si la clase posee todo el conocimiento para cumplir con su responsabilidad por si misma o requiere de alguna otra instancia de clase que contenga información que puede ayudar a cumplir con el trabajo. Para identificar colaboraciones, es necesario responder a las siguientes preguntas para cada responsabilidad de cada clase. 1. Es la clase capaz de cumplir la responsabilidad por si misma? 2. Sino, que es necesario hacer? 3. De cuál otra clase puede tomar lo que necesita? Registro de colaboraciones Como cada colaboración cumple una responsabilidad, se obtiene la tarjeta CRC para una clase que toma el rol de cliente y en ella se escribe al lado derecho de la responsabilidad el nombre de la clase servidor. Si la responsabilidad requiere para ser cumplida de varias colaboraciones, se escribe el nombre de cada clase. 80
CLASE (CLIENTE) RESPONSABILIDADES COLABORACIONES (CLASE SERVIDOR) Figura # 71 De la siguiente manera quedan especificadas las colaboraciones para las responsabilidades mencionadas de la clase Pacman: Pacman Pacman puede comer Frutas Pacman camina sobre Laberinto Pacman pierde una vida cuando Fantasma lo atrapa Fruta Laberinto Fantasma Figura # 72 De esta forma se da la explicación de la construcción de tarjetas CRC y la utilidad que estas proporcionan. 3.4.3.4 Jerarquías Un diagrama de jerarquías representa las relaciones de herencia que hay entre las clases existentes en el sistema. En el diagrama de jerarquías las clases son representadas mediante un rectángulo etiquetado con el nombre propio de la clase, las relaciones son representadas mediante líneas que parten de la superclase a la subclase, que es la de la parte inferior. Figura # 73 El diagrama de jerarquías ayuda a distinguir las clases abstractas (que son superclases) de las clases concretas. Clases abstractas: son aquellas clases que no pueden ser instanciadas. Clases concretas: son aquellas clases que pueden ser instanciadas. 81
En el diagrama de jerarquías una clase abstracta es representada mediante un triangulo relleno colocado en la esquina superior izquierda del rectángulo de la clase. Diagramas de Venn: Clase Abstracta Figura # 74 Al igual que el diagrama de jerarquías, los diagramas de Venn ayudan a tener un mejor conocimiento de las relaciones de herencia que existen en el sistema. En este tipo de diagramas, las clases se ven como un conjunto de responsabilidades. Figura # 75 Siguiendo el ejemplo del sistema del Pacman, la subclase contiene además las responsabilidades definidas por su superclase, lo cual produciría el siguiente diagrama. Figura # 76 Cuando se dan este tipo de relaciones, es mejor crear una clase abstracta que contenga las responsabilidades que hay en común entre la subclase y la superclase. 82
_N P i l d o r a _N Figura # 77 3.4.3.5 Contratos: Los contratos ayudan a entender el diseño, debido a que las responsabilidades son agrupadas dentro de ellos. Un contrato define un conjunto de peticiones que una clase cliente puede hacer a una clase servidor. Una clase puede tener uno o más contratos. Un contrato define un conjunto cohesivo de responsabilidades del que un cliente puede depender, mientras que las responsabilidades son algo que un objeto hace para otros objetos mediante alguna acción. Los contratos se representan mediante la modificación de las tarjetas, en lugar de las colaboraciones se especifican cuales son los contratos a los que se esta accediendo. 3.4.3.6 Subsistemas Los subsistemas son grupos de clases o de otros subsistemas que colaboran en grupo para soportar un conjunto de contratos. Para encontrar los subsistemas es necesario apoyarse con el diagrama de colaboraciones, debido a que este representa las relaciones entre las superclases y subclases, por lo cual en el diagrama una superclase representa los contratos soportados por todas sus subclases. En el diagrama de subsistemas la superclase se representa mediante un rectángulo y sus subclases por rectángulos dentro de ellas. Los contratos de una clase se representan mediante semicírculos al lado de la clase y al lado del número de contrato. Las colaboraciones son representadas por una flecha que une al cliente con el contrato que tiene el servidor. Para establecer los subsistemas se buscan clases fuertemente acopladas, el acoplamiento entre dos clases es una medida de cómo unas dependen de otras. Para registrar los subsistemas es necesario modificar las tarjetas, especificando en lugar de los contratos, los subsistemas a los cuales accesan las clases. 3.4.9 Protocolos Un protocolo es un conjunto de datos que corresponden a una clase. Cuando ya se haya revisado todo el diseño y también se hayan especificado los métodos que se van a utilizar y cual es su 83
propósito, se deben de llenar para cada clase sus protocolos con todos sus datos: Nombre, superclases, subclases, diagrama de jerarquías, diagrama de colaboraciones, descripción, contratos que accesa y los métodos que implementará para cumplir con sus responsabilidades. Esta fase es la final en el proceso de diseño, esta etapa ayuda a asegurar que las responsabilidades sean refinadas y los mensajes sean nombrados, generando protocolos que preserven la utilidad de las clases que se han diseñado. En esta etapa se llevan a cabo los siguientes procesos:! Construir protocolos para cada clase (especificar los métodos que cada clase implementará).! Escribir una especificación de diseño para cada clase y subsistema.! Escribir una especificación de diseño para cada contrato. 84