3.2 Identificación de Clases según Estereotipos

Para llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos como se discutió anteriormente. Para lograr esto se debe identificar primero las clases interface, luego las entidad y finalmente las de control. En general, se desea asignar la funcionalidad más especializada correspondiente a la “política” de la aplicación a los objetos control, la cual depende y afecta al resto de los objetos. Por otro lado, los objetos entidad e interface deben contener funcionalidad más bien local limitando su efecto en los demás objetos. El trabajo del analista consiste en distribuir lo mejor posible el comportamiento especificado en el modelo de requisitos en los diferentes tipos de objetos de la arquitectura de análisis. La asignación de funcionalidad es bastante difícil en la práctica afectando de gran manera la robustez y mantenimiento del sistema. Los buenos analistas consideran cambios potenciales al sistema a la hora de llevar a cabo este proceso.

En general, los cambios mas comunes a un sistema son los cambios en su funcionalidad e interfaces. Cambios a las interfaces deben afectar típicamente solo los objetos interface. Cambios a la funcionalidad son mas difíciles, ya que la funcionalidad puede abarcar todos los tipos de objetos. Si la funcionalidad esta ligada a la información existente, tales cambios afectan al objeto entidad representado esa información, o puede involucrar múltiples objetos incluyendo objetos control. Típicamente, esta funcionalidad se define en uno o varios casos de uso y se asigna a uno o varios objetos control. 

A continuación describimos en más detalles el proceso de identificación de los tres tipos de objetos.

1. Se pueden identificar con base a los actores.

2. Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.

3. Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.

Estrategia correspondiente a los actores

Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.

Entidad

Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.

Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.

Clases entidad

Validar Usuario: Este caso de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que se hace en la clase entidad RegistroUsuario, utiliza también por el caso de uso RegistroUsuario.

Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.

Registrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.

Registrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.

Consultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones.

Hacer Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.

Pagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases entidad, sino más bien especificar cualquier clase adicional.

Control

En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.

Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.