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.
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.
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.
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
