El modelo de
análisis tiene como objetivo generar una arquitectura de objetos que sirva como
base para el diseño posterior del sistema. Como se discutió en la introducción
del libro, dependiendo del tipo de aplicación existen diversas arquitecturas
que se pueden utilizar, siendo de nuestro interés aquellas arquitecturas
especialmente diseñadas para el manejo de los sistemas de información, las
cuales involucran ricas interfaces de usuario y accesos a base de datos como
aspectos fundamentales de la arquitectura.
En término de las
propias arquitecturas, éstas se distinguen según la organización de la
funcionalidad que ofrecen los objetos dentro de ellas o la dimensión de
los objetos. Esta dimensión corresponde a los diferentes tipos de funcionalidad
que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso de
funcionalidad para el manejo de interfaces y base de datos, si existen tipos
distintos de objetos para el manejo de cada una de estas por separado, entonces
se considera que la arquitectura es de dos dimensiones. Por el
contrario, si todos los objetos manejan de manera indistinta los dos tipos de
funcionalidades, entonces se considera que la arquitectura es de una sóla dimensión.
Si aplicamos el
concepto de dimensión a los métodos estructurados, podemos ver que estos
consisten de dos dimensiones, correspondientes a funciones y datos. Las
funciones representan un eje de comportamiento que no guarda información,
mientras que los datos se ubican en un eje de información que no contiene
comportamiento. En general, ejes de funcionalidad pueden corresponder a
distintos tipos de funcionalidades, como se ve al contrastar funciones y datos
versus manejo de interfaces y bases de datos. Sin embargo, la pregunta más
importante que uno se hace respecto al número y tipo de dimensiones es: ¿Si se
diseña un sistema con múltiples dimensiones, se obtendría un sistema más
robusto y sensible a modificaciones? Ante todo esta pregunta se relaciona con
el concepto de modularidad, siendo muy aceptado que cuanto mayor sea la
modularidad de un sistema mayor es su robustez y extensibilidad. La respuesta
particular a la pregunta tiene que ver con qué tan independiente sea un eje de
funcionalidad del otro, ya que en el caso de los métodos estructurados,
usualmente se debe modificar las funciones cada vez que se modifica la
estructura de información, lo cual no es algo deseable. Si logramos ejes de
funcionalidad ortogonales, el efecto de cambios en una dimensión no debe
afectar a las otras dimensiones. Y aunque estas dimensiones no son del todo
ortogonales, si son lo suficientemente independientes se puede limitar el
efecto de posibles cambios. En relación al número de dimensiones, esto depende
de la funcionalidad que la arquitectura debe manejar, algo que a su vez depende
del tipo de aplicación que se está desarrollando.
En el caso de
los sistemas de información, uno de las tipos de arquitecturas
mas importantes es la arquitectua MVC – Modelo, Vista, Control (Model,
View, Control) popularizada por los ambientes de desarrollo de Smalltalk.
Esta arquitectura se basa en tres dimensiones principales:Modelo
(información), Vista (presentación) y Control (comportamiento) como se
muestra en la Figura
Diagrama de tres dimensiones correspondiente a la arquitectura MVC –
Modelo, Vista, Control.
La vista o
presentación de la información corresponde a las interfaces que se le presentan
al usuario para el manejo de la información, donde por lo general pueden
existir múltiples vistas sobre un mismo modelo. Típicamente la información
representa el dominio del problema y es almacenada en una base de datos. Por
otro lado el control corresponde a la manipulación de la información a través
de sus diversas presentaciones. Y aunque existe cierta dependencia entre estas
tres dimensiones se considera que la manera de presentar la información es
independiente de la propia información y de cómo esta se controla. Sin embargo,
cada una de ellas probablemente experimente cambios a lo largo de la vida del
sistema, donde el control es el más propenso a ser modificado, seguido de la
vista y finalmente el modelo. En el modelo de análisis descrito aquí
utilizaremos como base la arquitectura MVC para capturar estos
tres aspectos de la funcionalidad, como se muestra en la Figura 7.3.
Es importante notar
la correspondencia con las tres dimensiones utilizadas durante el modelo de
requisitos. La razón de ser de las tres dimensiones del modelo de requisitos
realmente se deriva para lograr una rastreabilidad con la arquitectura que se
desarrollará en el modelo de análisis.
Diagrama de tres dimensiones
correspondiente a la arquitectura del modelo de análisis basado en el modelo de
casos de uso.
La arquitectura
para el modelo de análisis será implementada mediante tres tipos o estereotipos
de objetos como elementos básicos de desarrollo como veremos a continuación.
Clases con
Estereotipos
El tipo de funcionalidad o
“la razón de ser” de un objeto dentro de una arquitectura se le
conoce como su estereotipo. Para los sistemas de información la
arquitectura del sistema según nuestro modelo de análisis se basa en tres
estereotipos básicos de objetos:
·
El estereotipo entidad para objetos que guarden
información sobre el estado interno del sistema, a corto y largo plazo,
correspondiente al dominio del problema. Todo comportamiento naturalmente
acoplado con esta información también se incluye en los objeto entidad. Un
ejemplo de un objeto entidad es un registro de usuario con sus datos y
comportamiento asociados.
·
El estereotipo interface para objetos que
implementen la presentación o vista correspondiente a las interfaces del
sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios
humanos. Un ejemplo de un objeto interface es la funcionalidad de interface de
usuario para insertar o modificar información sobre el registro de usuario.
·
El estereotipo control para objetos que
implementen el comportamiento o control especificando cuando y como el sistema
cambia de estado, correspondiente a los casos de uso. Los objetos control
modelan funcionalidad que no se liga naturalmente con ningún otro tipo de objeto,
como el comportamiento que opera en varios objetos entidad a la vez, por
ejemplo, hacer alguna computación y luego devolver el resultado a un objeto
interface. Un ejemplo típico de objeto control es analizar el uso del sistema
por parte de algún usuario registrado y presentar tal información
posteriormente. Este comportamiento no le pertenece a ningún objeto entidad u
objeto interface específico.
Nótese que no hay ninguna
restricción a los diferentes estereotipos que puedan utilizarse, no solamente
las tres anteriores.
Diagrama de clase para los tres estereotipo.
Considerando que habrá
interacción entre los diferentes tipos de objetos, existirá cierto traslape en
la funcionalidad que los objetos ofrecen. Como se mencionó anteriormente, este
traslape deberá minimizarse para asegurar una buena extensibilidad, donde
típicamente, cada tipo de objeto captura por lo menos dos de las tres dimensiones.
Sin embargo, cada uno de ellos tiene cierta inclinación hacia una de estas dos
dimensiones, como se muestra en la Figura
Diagrama mostrando
traslape en los estereotipos de los objetos. Clases para Casos de Uso
Cuando se trabaja en el
desarrollo del modelo de análisis, normalmente se trabaja con un caso de uso a
la vez. Para cada caso de uso se identifican los objetos necesarios para su
implementación. Se identifican estos objetos según sus estereotipos para
corresponder a la funcionalidad ofrecida en cada caso de uso. Se define
explícitamente qué objeto es responsable de cual comportamiento dentro del caso
de uso. Típicamente se toma un caso de uso y se comienza identificando los
objetos interface necesarios, continuando con los objetos entidad y finalmente
los objetos control. Este proceso se continúa a los demás casos de uso. Dado
que los objetos son “ortogonales” a los casos de uso, en el sentido de que un
objeto puede participar en varios casos de uso, este proceso es iterativo. Esto
significa que cuando un conjunto de objetos ya existe, estos pueden modificarse
para ajustarse al nuevo caso de uso. La meta es formar una arquitectura lo más
estable posible, reutilizando el mayor número de objetos posible. De tal
manera, la descripción original de los casos de uso se transforma a una
descripción en base a los tres tipos de objetos, como se muestra en la Figura
La funcionalidad de cada caso de
uso es asignada a objetos distintos y de acuerdo a los estereotipos de dichos
objetos.
Se parte el caso de
uso de acuerdo a los siguientes principios:
·
La funcionalidad de los casos de uso que depende directamente de la
interacción del sistema con el mundo externo se asigna a los objetos interface.
·
La funcionalidad relacionada con el almacenamiento y manejo de
información del dominio del problema se asigna a los objetos entidad.
·
La funcionalidad específica a uno o varios casos de uso y que no se
ponen naturalmente en ningún objeto interface o entidad se asigna a los objetos
control. Típicamente se asigna a un sólo objeto control y si éste se vuelve muy
complejo se asignan objetos control adicionales.
Por ejemplo, consideremos
el caso de uso imprimir archivo, usado como ejemplo en el
capítulo 6 y que se muestra nuevamente en la Figura
Caso de uso imprimir archivo.
Para el caso de
uso imprimir archivo se pueden utilizar los objetos (descritos
según el diagrama de clases correspondiente) que se muestran en la Figura 7.9.
Se utilizan dos clases interface:Interface Archivo e Interface Impresora,
cinco clases entidad: Cola, Archivo con sus subclasesArchivo
Texto, Archivo Formateado y Archivo Gráfico y una clase control: Servidor
Impresora.
Objetos identificados para el caso de uso imprimir archivo.
La arquitectura se completa
generando asociaciones entre las distintas clases .
Objetos identificados para el caso de uso imprimir archivo mostrando
asociaciones entre si aunque omitiendo multiplicidad
El desafío para
generar esta correspondencia entre objetos o clases y los casos de uso es
precisamente decidir cuáles y cuantos objetos deben utilizarse en dicha
correspondencia.
