MÓDULO 1: ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CONTENIDO
MÓDULO 1: ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 2

Pensamiento Orientado a Objetos 2

El Diseño en el proceso de software 4

Requerimientos 5

Diseño 5

Compromiso en requisitos y diseño 8

Diseño para atributos de calidad 9

Compensaciones (Trade-offs) 9

Contexto y Consecuencias 9

Cualidades satisfactorias 10

Compromiso 11

Clase-Responsabilidad-Colaboración (CRC) (Class Responsibility

Collaborator) 12

Tarjetas CRC (CRC Cards) 13

Prototipado y Simulación 13
MÓDULO 1: ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
Al finalizar este módulo, podrá:
(a) Explique el pensamiento orientado a objetos.
(b) Comprender el papel del diseño y la comunicación en el proceso del
software, así como el vínculo entre estos conceptos y el uso de diagramas.
(c) Diseño para atributos de calidad.
(d) Modelo de tarjetas Class Responsibility Collaborator (CRC).

Pensamiento Orientado a Objetos

El modelado orientado a objetos es un tema importante en esta

especialización. Antes de que podamos discutir este tema en profundidad, es
importante aprender a pensar en los problemas y conceptos como orientados
a objetos.

Probablemente asocie el término "orientado a objetos" con la codificación y

el desarrollo de software. Si bien eso es cierto, la noción de estar orientado a
objetos puede aplicarse fuera del rol de desarrollador. El pensamiento
orientado a objetos implica examinar los problemas o conceptos en cuestión,
dividirlos en partes y pensar en ellos como objetos. Por ejemplo, un tweet en
Twitter o un producto en un sitio web de compras en línea podrían
considerarse objetos.

Cuando se traduce al modelado orientado a objetos, el pensamiento

orientado a objetos implica representar conceptos clave a través de objetos
en su software. Tenga en cuenta que los conceptos son de naturaleza amplia.
Incluso las instancias de personas, lugares o cosas pueden ser objetos
distintos en el software.

Los objetos pueden tener detalles específicos asociados con ellos, que son
relevantes para los usuarios. Por ejemplo, un objeto de persona puede tener
detalles como nombre, edad, sexo y ocupación. Un objeto de lugar puede
tener un tamaño o un nombre. Un objeto inanimado puede tener
dimensiones o un color.

Los objetos también pueden tener comportamientos o responsabilidades

asociados con ellos. Por ejemplo, una persona puede tener comportamientos
asociados como sentarse o escribir. Un dispositivo electrónico puede ser
responsable de encender o apagar, o de mostrar una imagen.
Al usar objetos para representar cosas en su código, el código se mantiene
organizado, flexible y reutilizable.

• Los objetos mantienen el código organizado colocando detalles

relacionados y funciones específicas en lugares distintos y fáciles de
encontrar. En los ejemplos anteriores, los detalles de los objetos
permanecen asociados con los propios objetos.
• Los objetos mantienen el código flexible, por lo que los detalles se
pueden cambiar fácilmente de forma modular dentro del objeto, sin
afectar el resto del código. En el ejemplo anterior de un objeto de
persona, los detalles de una persona, como la ocupación, pueden
cambiar y no afectar el resto del código.
• Los objetos permiten reutilizar el código, ya que reducen la cantidad de
código que debe crearse y mantienen los programas simples.

Los objetos son conscientes de sí mismos en la producción de software,

incluso si son objetos inanimados. Por ejemplo, un teléfono móvil “conoce”
sus especificaciones. De manera similar, en el modelado orientado a objetos,
un objeto como una silla conocería sus dimensiones y ubicación.

En el pensamiento orientado a objetos, a menudo todo se considera un

objeto, incluso si está animado o vivo. Y todos los objetos son conscientes de
sí mismos, incluso si son inanimados.

Es una buena práctica prepararse para el diseño orientado a objetos

acostumbrándose a pensar en el mundo que lo rodea en términos de objetos
y los atributos que esos objetos podrían tener.

¿SABÍAS?
Un buen ejercicio para ayudarlo a comenzar el pensamiento orientado a
objetos es mirar la habitación que lo rodea e identificar qué podrían ser
objetos. Por ejemplo, puede ver una computadora, una persona o algún
tipo de mueble. Todos estos tienen sus propios detalles específicos y
pueden tener comportamientos o responsabilidades que serían relevantes
para un usuario de ese objeto. Para un sistema informático, los detalles
pueden incluir el software operativo o la resolución de pantalla. Las
responsabilidades pueden incluir encender y apagar, o mostrar una
pantalla.
¡Incluso la habitación en sí es un objeto! Puede tener una capacidad de
asientos, un número de sala o un propósito que brinde detalles y
responsabilidades específicas a la sala como objeto. ¿Qué objetos hay a tu
alrededor? ¿Qué tipo de detalles y comportamientos podrían tener?

El Diseño en el proceso de software

Cuando se desarrolla software, generalmente pasa por un proceso. En

términos simples, un proceso toma un problema y crea una solución que
involucra software. Un proceso es generalmente iterativo. Estas iteraciones
consisten en tomar un conjunto de requisitos en función de los problemas
identificados y usarlos para crear maquetas de diseño conceptual y diagramas
de diseño técnico, que luego se pueden usar para crear una implementación
de software que funcione, que también debe pasar la prueba. Este proceso
se repite para cada conjunto de requisitos, creando finalmente una solución
completa para el proyecto.
Muchos proyectos fallan cuando se salta este proceso, especialmente cuando
el trabajo comienza inmediatamente con la codificación y hay una falta de
comprensión de los requisitos y el diseño.
Es importante dedicar tiempo a formar los requisitos y el diseño, aunque no
estén perfectamente establecidos. El trabajo de codificación se basa en
ciertas suposiciones, y puede ser difícil cambiar esas suposiciones una vez que
se ha iniciado la codificación. Los requisitos y las actividades de diseño lo
ayudan a comprender qué suposiciones necesita para crear el producto
correcto.
¿SABÍAS?

En una encuesta de The Standish Group, el 13 % de los encuestados señaló

que los requisitos incompletos perjudicaron sus proyectos. Lanzarse
directamente al trabajo de implementación es una de las principales causas
del fracaso del proyecto.

Examinemos brevemente los pasos de los requisitos y las actividades de

diseño en el proceso del software. Estos pasos requerirán que piense como
un arquitecto, por lo que deberá considerar la estructura y el
comportamiento de su software. Al final de esta lección, comprenderá que el
trabajo de diseño implica esbozar una solución y puede incluir la evaluación
de diferentes alternativas.
Requerimientos

Los requisitos son condiciones o capacidades que deben implementarse en

un producto, según la solicitud del cliente o usuario. Son el punto de partida
de un proyecto: debe comprender lo que quiere su cliente.
Sin embargo, para obtener requisitos, es importante pedir más que
simplemente la visión del cliente. En cambio, obtener requisitos implica
sondear activamente la visión del cliente, aclarar lo que no se haya dicho y
hacer preguntas sobre problemas que el cliente ni siquiera haya considerado.
Esto le permite comprender el alcance completo de lo que debe construir y
lo que su cliente quiere en un producto antes de comenzar a codificar.
Además de establecer las necesidades específicas del proyecto, también es
importante establecer las compensaciones potenciales que el cliente puede
necesitar hacer en la solución. Por ejemplo, un cliente puede decidir sacrificar
una función para garantizar que un programa se ejecute más rápido, si la
velocidad es una necesidad importante.
Una vez que se establecen los requisitos y las compensaciones, pueden servir
como base para el diseño.
Para comprender mejor los requisitos, imagina que eres un arquitecto que
construye una casa. Los requisitos le permiten comprender lo que un
propietario quiere en una casa antes de comenzar a construir. El propietario
puede decirle qué habitaciones quiere, pero es posible que deba hacerle
preguntas de seguimiento sobre qué habitaciones pueden faltar en su lista,
qué tamaño podrían tener la casa y las habitaciones, cualquier restricción en
la casa basada en restricciones, cómo los clientes desean que se coloquen las
habitaciones, o en qué dirección debe mirar la casa. Estos le ayudan a
comprender mejor lo que va a construir.
Diseño

Cuando se ha creado el conjunto inicial de requisitos, el siguiente paso en el

proceso es producir un diseño conceptual y un diseño técnico. Esto da como
resultado la creación de dos tipos diferentes de artefactos: maquetas (mock-
ups) conceptuales y diagramas técnicos.

Diseño Conceptual

Los diseños conceptuales se crean con un conjunto inicial de requisitos como

base. El diseño conceptual reconoce los componentes, conexiones y
responsabilidades apropiados del producto de software. Sin embargo, los
detalles técnicos más específicos se posponen hasta el diseño técnico. Los
diseños conceptuales describen los conceptos de más alto nivel de su
producto de software final.

Los diseños conceptuales se expresan o comunican a través de maquetas

conceptuales. Estas son anotaciones visuales que brindan ideas iniciales
sobre cómo se cumplirán los requisitos. Las maquetas de software que
involucran interfaces de usuario a menudo se presentan como estructuras
alámbricas, que son una especie de modelo o representación visual básica del
producto. Vea el siguiente ejemplo de una maqueta de estructura alámbrica
para una página web. Ya sea para las interfaces de usuario o para el producto
de software en sí, las maquetas conceptuales pueden ser bocetos hechos a
mano o dibujos hechos con herramientas informáticas. Las maquetas
conceptuales ayudan a clarificar las decisiones de diseño con los clientes y
usuarios al proporcionar una forma sencilla de ilustrar y discutir cómo
funcionará un producto.

Las maquetas ilustran los principales componentes y conexiones, o las

relaciones entre los componentes. Una vez que comience a crear una
maqueta, podrá ver más fácilmente qué componentes faltan o no funcionan.
Estas fallas requerirían una mayor aclaración con su cliente o implicarían un
trabajo de diseño conceptual adicional. Cada componente también tiene una
tarea que debe realizar. Esto se conoce como su responsabilidad. Las
maquetas no describen detalles técnicos, porque eso queda fuera del alcance
del diseño conceptual.
Por ejemplo, volvamos a la metáfora de construir una casa. Los componentes
para el ejemplo arquitectónico de construir una casa podrían ser: el lote en el
que se construirá la casa, la casa y las habitaciones dentro de la casa. Las
conexiones pueden ser cómo las habitaciones son accesibles entre sí. La casa
tiene la responsabilidad de proporcionar suficiente energía, agua y apoyo
para todos los componentes dentro de ella. Las habitaciones de la casa, como
la cocina, también pueden tener responsabilidades, como proporcionar
espacio para almacenar utensilios de cocina, electrodomésticos, suministros
de alimentos, además de energía y agua para la preparación de comidas. Sin
embargo, los detalles sobre el cableado y la plomería no se mencionan en el
diseño conceptual. Estos detalles técnicos no pueden abordarse por completo
hasta que las maquetas conceptuales se entiendan por completo. Por
ejemplo, el tamaño del panel de distribución eléctrica de la casa requerirá
sumar los requisitos de energía de cada una de las habitaciones.
La mejor práctica es formar el diseño conceptual antes de pasar al diseño
técnico. Cuanto más claro sea el diseño conceptual, mejor será el diseño
técnico y más probable será que su software se construya correctamente.
Diseño Técnico

Los diseños técnicos se basan en diseños y requisitos conceptuales para

definir los detalles técnicos de la solución. En el diseño conceptual, se
describen los principales componentes y conexiones, así como sus
responsabilidades asociadas del software que se está desarrollando. El diseño
técnico lleva esta información a la siguiente etapa: su objetivo es describir
cómo se cumplen estas responsabilidades. El diseño técnico no está
terminado hasta que cada componente se haya refinado para que sea lo
suficientemente específico como para diseñarse en detalle.

Para lograr esto, los diseños técnicos comienzan por dividir los componentes
en componentes cada vez más pequeños que son lo suficientemente
específicos para diseñarse en detalle. Al desglosar los componentes cada vez
más en más componentes, cada uno con responsabilidades específicas, llega
a un nivel en el que puede hacer un diseño detallado de un componente en
particular. El resultado final es que cada componente tendrá sus detalles
técnicos especificados.

Para comunicar el diseño técnico, se utilizan diagramas técnicos. Los

diagramas técnicos visualizan cómo abordar problemas específicos para cada
componente, ya que las maquetas conceptuales generalmente no son lo
suficientemente específicas para capturar esta información. Hay muchos
diagramas técnicos diferentes que se pueden usar para describir la estructura
y el comportamiento de los componentes, que se abordarán más adelante en
esta especialización. Por lo tanto, los diagramas técnicos ayudan a coordinar
el trabajo de desarrollo.

Para continuar con el ejemplo arquitectónico utilizado a lo largo de esta

lección, imagine tener que diseñar una cocina. Una cocina es un componente
de una casa en sí misma, pero requerirá otros componentes más pequeños,
como el suelo. El diseño técnico puede indicar que el piso deberá estar hecho
de un material que sea fácil de limpiar, especialmente si el cliente planea
cocinar mucho: ¡cocinar puede ser un asunto complicado!

Compromiso en requisitos y diseño

Cuando se encuentra en la fase de diseño, es posible que deba haber

compromisos para crear una solución aceptable. La comunicación y la
retroalimentación constantes son clave para crear la solución correcta que
satisfaga las necesidades del cliente y funcione dentro de las restricciones que
puedan existir.

Basándose en el ejemplo arquitectónico utilizado a lo largo de esta lección,

imagine que al cliente le gustaría una cocina abierta en su casa que no tenga
obstrucciones entre ella y el comedor. Pero, ¿y si se necesita un poste y una
viga en esa área para sostener el segundo piso de la casa? El propietario y el
proyecto deberán llegar a un compromiso en esa situación.

Será necesario volver a trabajar en los diseños si los componentes, las

conexiones y las responsabilidades del diseño conceptual resultan imposibles
de lograr en el diseño técnico, o si no cumplen con los requisitos. Es
importante verificar continuamente con los clientes que las maquetas
conceptuales capturen lo que quieren. Es más fácil rediseñar en las etapas de
planificación que una vez que se ha iniciado la codificación.

Los sistemas más grandes generalmente requieren más tiempo de diseño.

Hay más componentes, conexiones y responsabilidades para realizar un
seguimiento en sistemas más grandes. Y como estos componentes en sí
mismos son grandes, es posible que deban refinarse hasta componentes más
pequeños antes de poder detallar su diseño.

Una vez que se ha acordado un diseño factible, los diagramas técnicos se

convierten en la base para construir la solución prevista. Los componentes en
esta etapa pueden refinarse lo suficiente como para convertirse en
colecciones de funciones, clases u otros componentes. Estas piezas se
convierten en un problema más manejable que los desarrolladores pueden
implementar individualmente.

Existen muchas técnicas de diseño que se pueden utilizar para aprovechar al

máximo el proceso de diseño. El resto de esta especialización examinará esas
técnicas.
Diseño para atributos de calidad
Al desarrollar software, es importante tener una visión amplia sobre cómo
lograr los requisitos deseados. Esta lección examina cómo deben tenerse en
cuenta y equilibrarse en el diseño de software los ideales, roles y perspectivas
que compiten entre sí, las compensaciones potenciales y las realidades del
proyecto.
Compensaciones (Trade-offs)

Este curso ha revisado la importancia de los requisitos y el diseño en la

creación de software. A veces, existen restricciones en el diseño que
requieren compromiso. Además de los requisitos de software basados en la
funcionalidad deseada, también hay atributos de calidad para definir qué tan
bien debe funcionar esta funcionalidad. Pero sus decisiones también pueden
implicar compensaciones en diferentes atributos de calidad, como el
rendimiento, la conveniencia y la seguridad, y estos atributos deben
equilibrarse.

Por ejemplo, es importante considerar cómo los atributos de calidad pueden

competir en una solución propuesta en diferentes situaciones. Luego,
teniendo esto en cuenta y comparándolo con los requisitos del producto, se
puede determinar un compromiso adecuado. Este acto de equilibrio es una
constante en curso para la arquitectura de software. Los arquitectos de
software deben encontrar el mejor equilibrio entre los atributos de calidad, a
menudo evaluando cuál es más importante. Los plazos también pueden influir
en lo que es factible hacer dentro de un marco de tiempo determinado.

Consideremos, por ejemplo, diseñar una puerta de entrada a una casa. La

seguridad es un atributo de calidad que puede ser importante, pero si agrega
demasiadas cerraduras a la puerta, puede ser difícil abrirla con facilidad y será
un inconveniente de usar. Un buen diseño debe equilibrar la seguridad con la
comodidad y el rendimiento.

Contexto y Consecuencias
El contexto proporciona información importante al decidir sobre el equilibrio
de cualidades en el diseño. Por ejemplo, el software que almacena
información personal, a la que el público puede acceder, puede tener
diferentes requisitos de seguridad que el software que solo usan los
empleados corporativos. Para establecer el contexto, es importante hablar
con las partes interesadas.

El diseño de software también debe considerar las consecuencias. A veces, las

elecciones realizadas en el diseño de software tienen consecuencias no
deseadas. Por ejemplo, una idea que parece funcionar bien para una pequeña
cantidad de datos puede no ser práctica para grandes cantidades de datos.

Una buena práctica es buscar otras perspectivas sobre los diseños técnicos
para una implementación más completa. Esto se puede hacer preguntando a
otros desarrolladores por su opinión, o teniendo una sesión de revisión de
diseño. También es una buena práctica probar un sistema cuidadosamente
antes de implementarlo por completo. Durante el proceso de diseño, puede
considerar crear prototipos de ideas alternativas y realizar pruebas para ver
qué funciona mejor. Las pruebas pueden ayudar a detectar consecuencias no
deseadas. Por ejemplo, probar con cantidades de datos pequeñas y grandes
en el ejemplo anterior podría revelar las limitaciones del sistema.

Cualidades satisfactorias

Las cualidades se logran mediante la satisfacción de requisitos funcionales y

no funcionales, que a su vez son la base del proceso de diseño.

Los requisitos funcionales describen lo que se espera que haga el sistema o la

aplicación. Una cualidad clave a lograr al satisfacer un requisito funcional es
la corrección. Por ejemplo, si está diseñando una aplicación de música, la
aplicación debe poder descargar y reproducir una canción. El diseño debe ser
capaz de esbozar una solución que cumpla correctamente con este requisito.

Los requisitos no funcionales especifican qué tan bien el sistema o la

aplicación hace lo que hace. Los requisitos no funcionales a satisfacer pueden
incluir rendimiento, uso de recursos y eficiencia; estos requisitos se pueden
medir desde el software en ejecución. Por ejemplo, la aplicación de música
puede tener requisitos no funcionales para descargar música solo hasta cierto
límite de memoria. Otras cualidades que el software a menudo satisface en
requisitos no funcionales incluyen la reutilización, la flexibilidad y la
capacidad de mantenimiento. Esto ayuda a informar qué tan bien puede
evolucionar el código del software y permitir cambios futuros.

Los requisitos suelen estar incompletos al principio, pero se resuelven con

más interacciones con los clientes y usuarios finales.

Es importante satisfacer los requisitos funcionales y no funcionales, pero

puede haber restricciones y limitaciones importantes que conducirán a
compromisos. Por esta razón, es importante comunicar y determinar qué es
aceptable para las partes interesadas. Considere este ejemplo: todos los
automóviles cumplen con el requisito funcional de proporcionar transporte;
sin embargo, los requisitos no funcionales y el énfasis en ciertas cualidades
pueden cambiar enormemente el producto final: diferentes aceleraciones,
manejo, peso y economía de combustible pueden marcar la diferencia entre
una minivan y un automóvil deportivo.

También se deben utilizar revisiones y pruebas para verificar que se cumplen

las cualidades requeridas en el diseño y la implementación del software.
Algunas cualidades también pueden validarse con comentarios de los
usuarios finales.

Compromiso

Además de equilibrar las cualidades y cumplir con los requisitos funcionales

al diseñar software, es importante considerar múltiples perspectivas. El
software debe satisfacer cualidades que son importantes tanto para los
usuarios como para los desarrolladores. En otras palabras, la forma en que se
organiza la estructura del software puede afectar la calidad del rendimiento,
tal como la entienden los usuarios, y las cualidades de reutilización y
mantenibilidad, tal como la entienden los desarrolladores.

A continuación, se presentan algunas compensaciones comunes en las

cualidades para el diseño de software:
• Rendimiento y facilidad de mantenimiento: el código de alto
rendimiento puede ser menos claro y menos modular, lo que dificulta su
mantenimiento. Alternativamente, el código adicional para la
compatibilidad con versiones anteriores puede afectar tanto el
rendimiento como la capacidad de mantenimiento.
• Rendimiento y seguridad: la sobrecarga adicional para alta seguridad
puede disminuir el rendimiento.
El equilibrio entre las cualidades debe entenderse y tenerse en cuenta
durante el diseño. Es importante priorizar y entender qué cualidades se
necesitan. Una buena pregunta para ayudarlo a determinar qué compromisos
se pueden hacer es: ¿Hay alguna manera de reducir una cierta cualidad para
equilibrar otra?

¿SABÍAS?

Algunas cualidades comunes a tener en cuenta en el diseño de software

incluyen: rendimiento, facilidad de mantenimiento, seguridad y
compatibilidad con versiones anteriores.

También es importante considerar las limitaciones de las realidades del

proyecto en su proyecto. Para desarrollar el producto, las cualidades deben
equilibrarse con los recursos disponibles, como el costo, el tiempo y la mano
de obra.

Clase-Responsabilidad-Colaboración (CRC) (Class

Responsibility Collaborator)
Hasta ahora, este módulo ha revisado el proceso de obtención de requisitos
y el uso del diseño conceptual para recopilar pensamientos iniciales sobre
cómo satisfacer esos requisitos en el desarrollo de software. Durante esta
etapa se establecen componentes, conexiones y responsabilidades para
algunos requisitos.

Este módulo también ha examinado cómo se refinan los componentes y las

conexiones a través del proceso de diseño técnico y teniendo en cuenta los
atributos de calidad para establecer los detalles técnicos. Esto permite que
los componentes y las conexiones se implementen más fácilmente.

La próxima lección presenta una técnica importante para ayudar a

representar los componentes, responsabilidades y conexiones a un alto nivel
al formar el diseño conceptual. Esta técnica es el uso de tarjetas de Clase,
Responsabilidad, Colaborador (CRC). Las tarjetas CRC ayudan a registrar y
organizar los componentes en clases, identificar las responsabilidades de los
componentes y determinar cómo colaboran entre sí. Por lo tanto, también
ayudan a refinar los componentes de su diseño de software.
Tarjetas CRC (CRC Cards)

Durante el proceso de diseño conceptual, es útil no solo identificar

componentes, responsabilidades y conexiones, sino también representarlos.
Una técnica es usar tarjetas de Clase, Responsabilidad, Colaborador (CRC).

Las tarjetas CRC se utilizan para registrar, organizar y refinar los componentes
del diseño del sistema. Se pueden comparar con tarjetas de notas, que se
utilizan para organizar puntos de conversación. Las tarjetas CRC están
diseñadas con tres secciones: el nombre de la clase en la parte superior de la
tarjeta, las responsabilidades de la clase en el lado izquierdo de la tarjeta y
los colaboradores en el lado derecho de la tarjeta. Vea la imagen a
continuación para ver un ejemplo de cómo se vería una tarjeta CRC,
aproximadamente del tamaño de una tarjeta de índice física.

Nombre de la clase

Responsabilidades Colaboradores

Para realizar un seguimiento de cada componente candidato y sus

responsabilidades utilizando una tarjeta CRC, coloque el nombre de un
componente en la sección de nombre de clase y las responsabilidades en la
sección de responsabilidades. Las conexiones se capturan en la sección de
colaboradores. Las conexiones o colaboradores indican otras clases con las
que interactúa la clase en la parte superior de la tarjeta para cumplir con sus
responsabilidades. Estos pasos se repiten iterativamente y se crean nuevas
tarjetas hasta que se identifican todas las clases, responsabilidades y
colaboradores para un sistema.

En el diseño de sistemas, las tarjetas CRC tienen un propósito: obligan a los

diseñadores a seguir dividiendo los componentes en componentes y clases
más pequeños que se pueden describir individualmente en una tarjeta.

Prototipado y Simulación
El uso de las tarjetas CRC es un sistema sencillo que tiene muchas ventajas.
Son baratos, editables y ampliamente disponibles. Ayudan a clasificar la
información en piezas manejables.

Una ventaja clave de usar tarjetas CRC es que le permiten reorganizar

físicamente su diseño. Como cada uno de los componentes está representado
por una tarjeta, puede juntar tarjetas relacionadas o colocar tarjetas para
sugerir relaciones. Esto le permite explorar teóricamente cómo funcionará su
sistema e identificar cualquier deficiencia en el diseño.

También puedes experimentar moviendo estas cartas en nuevos órdenes y

analizando las consecuencias resultantes, permitiéndote jugar con diseños
alternativos. Esto significa que las tarjetas CRC se pueden usar para crear
prototipos y simular un sistema para el diseño conceptual.

Cuando desarrolla diseños, a veces se los denomina modelos CRC. Las tarjetas
CRC deben organizarse colocando juntos los componentes que colaboran
estrechamente. Esto facilita la comprensión de las relaciones o conexiones
entre clases o componentes.

Las tarjetas CRC son excelentes herramientas para llevar a las reuniones del
equipo de desarrollo de software. Todas las tarjetas se pueden colocar sobre
la mesa y facilitar una discusión o una simulación con el equipo de cómo estas
clases trabajan junto con otras clases para lograr sus responsabilidades. Esto
le permite explicar visualmente su sistema y obtener información potencial
de otras partes.

Las tarjetas CRC son herramientas útiles, pero son más poderosas cuando se
utilizan para la creación de prototipos y la simulación para el diseño
conceptual. Se han desarrollado muchas otras técnicas para ayudarlo a
diseñar de manera más efectiva. El resto de esta especialización se centrará
en algunas de estas diversas técnicas de diseño.