3.1 ARQUITECTURA DE CLASES

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.