Analisis de clases

ANÁLISIS DE CLASES: LAS RELACIONES

Como se mencionó anteriormente, el modelo de análisis resultado del análisis orientado a objetos unificado, incluye las actividades: arquitectura del modelo de análisis que organiza los casos de uso de los requerimientos formando paquetes, análisis de casos de uso que muestra la interacción entre objetos usando diagramas de colaboración, análisis de clases yanálisis de paquetes.
En este capítulo trataremos en detalle el análisis de clases en lo correspondiente a las relaciones.
Los objetos del análisis interactúan vía los enlaces que aparecen en los diagramas de colaboración. Dichos enlaces con frecuencia son instancias de asociaciones entre sus correspondientes clases. Del estudio de los diagramas de colaboración se puede determinar quéasociaciones y agregaciones son necesarias.
Hay que tratar de minimizar el número de relaciones entre las clases. No hay que perder de vista que pueden haber relaciones entre entidades del mundo real que no son relevantes al sistema en desarrollo. Las relaciones necesarias son aquellas que se requieren para cumplir con el funcionamiento de los casos de uso. Tampoco se trata de optimizar las rutas entreasociaciones o agregaciones. Esto se tratará de lograr en los flujos de diseño e implementación.

En esta actividad se debe establecer:

• La multiplicidad o cardinalidad:
• Los roles:
• Ordenamiento de roles:
• Asociaciones recursivas;
• Asociaciones como clases; calificación de roles;
• y asociaciones en que participan más de dos clases.

1. LA MULTIPLICIDAD OCARDINALlDAD:

La multiplicidad o cardinalidad representa la cantidad de objetos de la otra clase, con los que puede estar asociado un objeto de una clase cuando se establece una relación de asociación o agregación entre las clases mencionadas. La figura 1.1 muestra distintos ejemplos de uso de multiplicidad usando la notación UML.

[pic]

Fig. 1.1 La cardinalidad o multiplicidad usando UMLLa multiplicidad explícitamente mostrada expone supuestos escondidos del sistema. Por supuesto que dicha multiplicidad depende del dominio o contexto de la aplicación, pues escoger una multiplicidad restrictiva puede limitar el crecimiento y extensibilidad del sistema; sin embargo, la elección de una multiplicidad muy expansiva introducirá complejidad e ineficiencia.

Generalmente cuando se dejala multiplicidad sin definir el valor por omisión es uno a uno. Una asociación es opcional a menos que exista por lo menos, enlace por cada objeto de una clase, pues la introducción de una ocurrencia en una clase origina una ocurrencia en la asociación si la participación de dicha clase es mandatoria.
Se debe tener en cuenta el esquema de tiempo al preparar un modelo. ¿Debe la relaciónconsiderar un minuto, un día, una semana, un año, permanente? La especificación del tiempo considerado para preparar el modelo, debe ser especificada en la documentación del sistema. Un enfoque recomendado es que la multiplicidad represente, en particular, un punto del reloj en el tiempo de vida del dominio o de la aplicación que está siendo modelada. Si un esquema de tiempo más largo es necesario,entonces se requieren asociaciones separadas para capturar la historia correspondiente.

2. LOS ROLES

El rol es el papel que desempeña un objeto cuando se establece un enlace de una relación. Así por ejemplo, en la figura 1.2, cuando un alumno ha aprobado un curso, el alumno ha realizado el rol de aprendiz, mientras que el curso ejecuta el rol del conocimiento aprendido. Nótese que los nombres delos roles pueden resultar arbitrarios al lector, sin embargo, estos nombres son propios del área de estudio.
[pic]

Fig. 1.2 Los roles

Normalmente, el nombre del rol se ubica al final de la asociación para clarificar el papel que desempeña una ocurrencia de la clase junto a la que está; sin embargo cuando hay una sola asociación que enlaza dos clases, casi siempre los nombres de las clases...