Las técnicas de análisis orientado a objetos aplicables para la construcción de modelos conceptuales también se aplican al diseño. Por tanto, algunas modelos conceptuales podrían incluir elementos de diseño. Sin embargo, tome como guía que el análisis se centra en descubrir los conceptos que forman el vocabulario del dominio del problema, es decir la información que usan los usuarios reales que necesitan el sistema, y que se representarán como clases y objetos en los modelos de clases.
Con base en las descripciones del dominio del problema, algunas técnicas clasifican los conceptos según una serie de categorías (Booch et al., 2007). Shlaer and Mellor (1988) proponen que las clases candidatas del dominio del problema corresponden a una categoría como cosas tangibles, roles, eventos o interacciones. En el caso de cosas tangibles se pueden considerar como clases automóviles, datos de medición de fenómenos atmosféricos, sensores de movimiento, entre otras cosas del mundo real. Empleado, jefe o dentista correspondería a clases de la categoría roles. La categoría de eventos pudiera considerar clases como solicitud, accidente o incidencia, mientras que la categoría interacciones considera clases las reuniones de personas, intersecciones, préstamos, entre otros conceptos.
Usando el mismo criterio de clasificación, Coad and Yourdon (1990) presentan las siguientes categorías para identificar objetos: estructura (relaciones “es un” y “parte de”), otros sistemas, dispositivos, eventos que deben ser recordados, roles, lugares y unidades organizacionales.
Un caso de uso es una descripción de un conjunto de secuencias de acciones que ejecuta un sistema y que produce un resultado observable de interés para un actor particular (Booch et al., 2006). Los casos de uso permiten enumerar y describir los escenarios que fundamentalmente muestran los escenarios operativos del sistema. Los escenarios, en su conjunto, describen las funciones del sistema.
Conforme el analista recorre cada uno de los escenarios, debe identificar los objetos que participan en dicho escenario, las responsabilidades de cada objeto y los objetos con los cuales debe colaborar para realizar una operación. Al profundizar el conocimiento sobre el dominio del problema del sistema que se estudia, los escenarios iniciales se pueden extender para abordar condiciones excepcionales así como escenarios secundarios (Booch et al., 2007).
Las tarjetas CRC fueron propuestas por Beck and Cunningham (1989) para analizar escenarios. La técnica facilita la tormenta de ideas y mejora la comunicación entre desarrolladores. Cada tarjeta CRC corresponde a una ficha (rectángulos de cartulina de 5”x7”) en el cual el analista escribe en la parte superior el nombre de una clase (Figura 2). En la mitad izquierda, el analista escribe las responsabilidades de la clase; en la mitad derecha, las clases colaboradoras para realizar cada una de las responsabilidades.
Conforme el equipo de desarrollo recorre cada escenario, se crea una tarjeta CRC para cada clase relevante identificada. Cada clase relevante se corresponde con un nombre o sustantivo descrito en el escenario. Las responsabilidades se agregan conforme se recorre el escenario. Estas son las acciones que realiza la clase. Se corresponden con los verbos. Si estas responsabilidades requieren que otra clase realice alguna acción, entonces se agrega la clase colaboradora correspondiente en la mitad derecha de la ficha.