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 7.2.
Figura
7.2 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.
Figura
7.3 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. La notación de
UML para un estereotipo se muestra en la Figura 7.4.
|
<<
estereotipo >>
Nombre
de la Clase
|
|
|
Figura
7.4 Diagrama de clase con estereotipo.
Los
tres estereotipos correspondientes a las tres dimensiones para la
arquitectura del modelo de análisis se muestra en la Figura 7.5.
Figura
7.5 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 7.6.
Figura
7.6 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 7.7.
Figura
7.7 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 7.8.
Figura
7.8 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 subclases Archivo Texto, Archivo
Formateado y Archivo Gráfico y una clase control: Servidor
Impresora.
Figura
7.9 Objetos identificados para el caso de uso imprimir archivo.
La
arquitectura se completa generando asociaciones entre las distintas
clases como se muestra en la Figura 7.10.
Figura
7.10 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 cuales y cuantos objetos
deben utilizarse en dicha correspondencia.
