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 ello, se deben
identificar primero las clases borde, luego las clases entidad y, finalmente,
las de control. En general, se desea asignar la funcionalidad general del caso
de uso. Por otro lado, los objetos entidad y borde deben contener funcionalidad
local, limitando su efecto en los demás objetos. El trabajo del analista
consiste en distribuir de la mejor manera posible el comportamiento específico en
el modelo de requisitos entre los diferentes tipos de objetos de la
arquitectura de análisis.
La asignación de funcionalidad es bastante difícil en la práctica, y afecta
en gran medida de la calidad y mantenimiento del sistema. Los buenos analistas
consideran desde un principio los posibles cambios futuros del sistema.
En general, los cambios más comunes a un sistema son los de funcionalidad y
bordes. Los cambios de las interfaces deben afectar solo a los objetos borde.
Los cambios a la funcionalidad son más difíciles de administrar, ya que esta
puede abarcar todos los tipos de objetos.
A continuación se describen se describirán con mayor detalle el proceso de
identificación de los tres tipos de objetos, identificando las clases para cada
caso de uso según sus estereotipos. El desafío principal en dicho proceso, es
decidir cuantas y cuales clases deben asignarse por cada caso de uso.
Borde
Toda la funcionalidad especificada en las descripciones de los caso de uso
que depende directamente de los aspectos externos del sistema, se ubica en los
objetos borde, pues a través de ellos se comunican los actores con el sistema.
La tarea de una clase borde es traducir los eventos generados por un actor en
eventos del sistema en una presentación comprensible por el actor. Las clases
borde, en otras palabras, describen la comunicación bidireccional entre el
sistema y los actores.
Las clases borde son bastante fáciles de identificar, donde se cuenta con
al menos tres estrategias:
Se puede identificar con base a los actores.
Se pueden identificar con base en las descripciones de las interfaces del
sistema que acompañan al modelo de requisitos.
Se pueden identificar con base en las descripciones de los
casos de uso y extraer la funcionalidad específica a los objetos bordes.
Comenzaremos utilizando la primera 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 no son totalmente independientes de cada uno, ya que,
en ciertos casos deben saber de la existencia de los demás. Por ejemplo, el
usuario debe interactuar con las clases borde de la interface de usuario que a
su vez se comunican con las clases borde de las pantallas. Debe estar muy bien
definida la interacción de estos dos grupos de clase borde, las pantallas e
interface de usuario.
Existen dos tipos de clase borde a modelar, dependiendo del tipo de actor:
borde a otros sistemas y bordes a usuarios humanos.
En el caso de objetos borde que se comunican con otros sistemas, es
muy común que la comunicación se describa mediante protocolos de comunicación.
Los objetos bordes pueden traducir las señales del sistema a un protocolo de
comunicación estandarizada, o simplemente enviar eventos producidos
internamente sin conversiones complejas. Una ventaja de esto, es que si se
cambia el protocolo, estos cambios serán locales al objeto borde. Un mayor
problema ocurre cuando existen señales continuas del mundo externo, como en los
sistemas de medición o control. Entonces los objetos borde deben “muestrear” la
señal de entrada, ya que internamente el sistema se procesa en términos de
eventos.
En el caso de los objetos borde que se comunican con usuarios humanos se
utilizan diversas técnicas para el modelado de la interacción. Es fundamental
que las interfaces con el usuario sean lógicas y coherentes. En general, en las
aplicaciones interactivas es común que las interfaces de usuario sean un
aspecto fundamental y de mayos complejidad dentro de la aplicación completa.
Aunque cada tipo de objeto tiene un propósito distinto, es evidente que los
objetos borde tienen como propósito principal el manejo de las presentaciones.
Sin embargo, también pueden administrar información y tener comportamiento.
Debe decidirse de manera individual la cantidad de información y tener
comportamiento de un objeto borde. En un extremo, el objeto borde solo debe
enviar el evento que recibe del actor a otros objetos en el sistema, sin
participar activamente en el curso de los eventos. En el otro extremo, el
comportamiento del objeto borde puede ser muy complejo, de manera que la
información se procede dentro del objeto borde, haciendo todo el procesamiento
de eventos de manera local.
Para identificar que parte del flujo de un caso debe asignarse a los
objetos borde, se deben analizar las interacciones entre los actores
y los casos de uso. Esto significa buscar aspectos como, información que deba
presentarse al actor y funcionalidad que dependa del comportamiento del actor.
Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe
manejar a corto y largo plazos. 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 casos de uso, por lo que es necesario guardarla en alguna base
de datos o archivo.
Los objetos entidad se identifican principalmente a partir del dominio del
problema del modelo de requisitos. Dado que es posible identificar un gran
número de entidades, se deben considerar únicamente aquellos necesarios para la
aplicación. Los casos de uso deben usarse como guías para identificación, y
solamente aquellos objetos entidad que puedan justificarse de la descripción
del caso de uso deben incluirse.
Adicionalmente, no es fácil decidir cuándo cierta información debe ser
modelada como objeto entidad o atributo. Esto depende de cómo se usara la
información. Si esta cuenta con cierta estructura más allá de un simple valor
numérico, entonces debe modelarse como un objeto entidad. Por otro lado,
información que pueda describirse mediante un simple valor, debe modelarse como
un atributo de un objeto entidad. Esta decisión es algo arbitraria, ya que
cierta información puede modelarse como objeto entidad en un sistema, mientras
que en otro puede representarse mediante un atributo.
También es difícil identificar que operaciones y cuales atributos serán
incluidos dentro de estos objetos.
Dado que la única forma para manipular un objeto entidad es por medio de
sus operaciones, se deben identificar suficientes operaciones para manipular
completamente al objeto entidad. La descripción detallada de los casos de uso
es de nuevo un medio extremadamente valioso para identificar estas operaciones.
Las operaciones pueden ser sencillas, sirviendo de acceso a los valores de
los atributos, o complejas, como en el caso de ciertos cálculos matemáticos
basados en los valores de los atributos del objeto. Sea cual sea la
complejidad, estas operaciones deben depender y afectar solamente a la
información local.
Durante la identificación de objetos entidad, se encontrara que objetos
similares aparecen en varios casos de uso.
Control
Hasta ahora se han identificado objetos borde y entidad a partir de cada
caso de uso. En algunas situaciones, todo un caso de uso pudiera
implementarse exclusivamente mediante estos dos tipos de objetos. Así no se
necesitaría ningún objeto control para el respectivo caso de uso. Sin embargo,
en la mayoría de los casos de uso, existe un comportamiento que no puede
asignar de forma natural a ninguno de los otros dos tipos de objetos. 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. Por lo tanto, para evitar estos
problemas, tal comportamiento se asigna a objetos control.
En general, 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 la administración de los demás tipos de
objetos, dependiendo de la existencia del propio caso de uso. Por lo tanto, los
objetos control se especifica directamente de los casos de uso. Como primera
aproximación, se especifica un objeto control para cada caso de uso. Dado que
se asigna inicialmente el comportamiento a los objetos borde y entidad, el
comportamiento restante se agrega a los objetos control. Una manera de asignar
el comportamiento es modelar inicialmente el caso de uso sin ningún objeto
control, en otras palabras, solo utilizando objetos borde y objetos entidad.
Cuando tal modelo se ha desarrollado, se verá que hay ciertos comportamientos
que no se asignan de forma natural, a los diversos objetos, o incluso, se
distribuye a varios objetos. Estos comportamientos deberían asignarse
a los objetos control. Otra situación es que los comportamientos, después de
distribuirse entre objetos borde y entidad, sea demasiado complicado. En tal
caso, los comportamientos pueden ser distribuidos en varios objetos control.
En la mayoría de los sistemas, se promueve la distribución del manejo de un
caso de uso en un solo objeto control. Sin embargo, la estrategia de asignación
de control se debe decidir de acuerdo a cada aplicación.
Bibliografia:
