7.1 Arquitectura de clases

Transcripción

1 7.1 Arquitectura de clases El modelo de analisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diserio del sistema. Como se discutio en el capitulo 3, dependiendo del tipo de aplicacion existen cliversas arquitecturas que se pueden utilizar, en este libro nos centraremos en aquellas arquitecturas especialmente disenaclas para el mane jo de los sistemas de information, las cuales involucran la manipulacion de la informacion guardada en bases de datos a partir de interfaces de usuario. Las arquitecturas se distinguen segun la organizacion de los objetos de acuerdo a su funcionalidad. Esto es tambien conocido como la dimension de la arquitectura. For ejemplo, si existe un grupo de objetos para el manejo de la funcinalidad cle la aplicacion y otro para interactuar con las entidades externas de la aplicacion, como el usuario y las bases de datos, entonces se considera que la arquitectura es de dos dimensiones. For el contrario, si existe un solo grupo de objetos que maneja de manera inclistinta la funcionalidad junto con la interaccion externa, entonces se considera que la arquitectura es de una sola dimension. En general, una arquitectura puecle incluir cualquier numero de dimensiones, algo que depencle del tipo de aplicacion que se desee desarrollar. En general, el planteamiento es: si se diseria un sistema con cierto ncimero de dimensiones, ^;se obtendna un sistema mas estable y facil de extender que con un numero menor o mayor? La respuesta clepende de que tan indepencliente sean los objetos de un eje de funcionalidad con los demas. Si se cuenta con ejes de funcionalidad completamente ortogonales, algo que es dificil de lograr, el efecto de cambios en una dimension no deberia afectar a las demas dimensiones. Sin embargo, si los grupos de objetos no son lo suficientemente independientes, aun se puede limitar el efecto de los posibles cambios. En el caso de los sistemas de informacion, una cle las arquitecturas mas utilizadas es la de Modelo, Vista, Control (MVC - Model, View, Control)? popularizada por los ambientes de desarrollo para los lenguajes de programacion de Smalltalk (ver capitulo 2). Esta arquitectura se basa en tres dimensiones principales: Modelo correspondiente a la informacion, Vista correspondiente a la presentation o interaccion con el usuario y Control correspondiente al comportamiento, como se ilustra en la figura 7.2. Figura 7.2 Diagrama de tres dimensiones correspondiente a la arquitectura Modelo, Vista, Control (MVC). 254 CAP. 7 MODELO DE ANALISIS

2 La vista o presentacion de la informacion corresponde a las interfaces que se le presentan at^usuario para el manejo de la informacion, donde por lo general pueden existir multiples vistas sobre un mismo moclelo. Tipicamente la informacion representa el dominio del problema y se almacena en una base cte clatos. Por otro lado, el control corresponde a la manipulacion cle la informacion a traves de sus cliversas presentaciones. Aunque existe cierta depenclencia entre estas tres dimensiones, se considera que la manera de presentar la informacion es independiente de la propia informacion y de como se controla esta. Sin embargo, cacla una de ellas probablemente experimente cambios a lo largo del ciclo cle vida del sistema, donde el control es el mas propenso a ser modificado, seguido cie la vista y, finalmente, del moclelo. En el moclelo de analisis descrito aqui utilizaremos como base la arquitectura MVC para capturar estos tres aspectos cle la funcionaliclad, como se muestra en la figura 7.3. Figura 7.3 Diagrama de tres dimensiones correspondiente a la arquitectura del modelo de analisis, basado en el modelo de casos de uso. En correspondencia con el modelo MVC, la arquitectura para el modelo de analisis se basara en tres tipos o estereotipos de objetos corresponclientes a las tres dimensiones anteriores. Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo cle requisites (ver figura 6.2) Clases con estereotipos El tipo cle funcionalidad o "la razon cle ser" cle un objeto clentro de una arquitectura se conoce como su estereotipo. Siguienclo la metodologia de casos de uso, la arquitectura del sistema para el modelo de analisis se basara en tres estereotipos: El estereotipo entidad (entity) para los objetos que guardan informacion sobre el estado interno del sistema a corto y largo plazo. Estos objetos corresponden al clominio del problema. Un ejemplo de objeto entidad es un registro de usuario con sus clatos y comportamiento asociados. El estereotipo horde (boundary) para objetos que implementan las interfaces del sistema con el munclo externo, correspondientes a todos los actores, incluyendo a aquellos que no son humanos. Un ejemplo de objeto borde es una interface cle usuario o pantalla para insertar o modificar informacion en el registro de usuario. Otro ejemplo es un objeto que se comunica con una base cle clatos externa al sistema. ARQUITECTURA DE CLASES 255

3 El estereotipo control (control) para objetos que implementan el comportamiento o control de la logica de los casos de uso, especificando cuando y como el sistema cambia de estado. Los objetos control modelan la funcionalidad que no se asocia naturalmente con un solo objeto. Un ejemplo tipico de objeto control es validar un usuario existente o insertar uno nuevo. Este comportamiento requiere la interaccion de multiples objetos y actores. La notacion de UML para un estereotipo se muestra en la figura 7.4. Figura 7.4 Diagrama de clase con estereotipo utilizando la notacion de UML. Los tres estereotipos, Entidad, Borde y Control, correspondientes a las tres dimensiones de la arquitectura de analisis, se ilustran en la figura 7.5. Figura 7.5 Diagrama de clase para los tres estereotipos. Los tres estereotipos de la arquitectura de analisis se pueden describir a traves de diagramas de iconos en lugar de rectangulos, se muestran como iconos en la figura 7.6. Figura 7.6 Diagrama de clases mostrando los tres estereotipos como iconos: entidad, borde y control, respectivamente. Es dificil lograr una ortogonalidad completa de estereotipos en los objetos. En general, es comun que un objeto tenga cierta inclinacion hacia una de las dimensiones, como se muestra en la figura CAP. 7 MODELO DE ANALISIS

4 Figura 7.7 Diagrama que ilustra el traslape en las dimensiones de los objetos correspondientes a sus estereotipos Clases para casos de uso Cuando se desarrolla el modelo de analisis, normalmente se trabaja con un caso de uso a la vez. En cada caso de uso se identifican los objetos necesarios para su implementacion. Los objetos se identifican segun sus estereotipos de manera que correspondan con la funcionalidad ofrecida en cada uno. Se define explicitamente que objeto es responsable de cual comportamiento dentro del caso de uso. Se comienza identificando los objetos borde necesarios, continuando con los objetos entidad y, finalmente, los objetos control. Este proceso se continua a los demas casos de uso. Dado que los mismos objetos pueden participar en varios casos de uso, durante este proceso es necesario identificar aquellos objetos comunes. Esto significa que cuando un conjunto de objetos ya existe, estos pueden modificarse para ajustarlos al nuevo caso de uso. La meta es formar una arquitectura que reutilice el mayor numero de objetos posible. De tal manera, la descripcion original de los casos de uso se transforma en una descripcion con base en los tres tipos de objetos, como se muestra en la figura 7.8. Figura 7.8 La funcionalidad de cada caso de uso se asigna a objetos distintos y de acuerdo con sus estereotipos. ARQUITECTURA DE CLASES 257

5 La asignacion de objetos a cada caso de uso se hace de acuerdo con los siguientes principios: La funcionalidad de los casos de uso que depende directamente de la interaccion del sisterna con el mundo externo se asigna a los objetos borde. La funcionalidad relacionada con el almacenamiento y manejo de informacion del dominio del problema se asigna a los objetos entidad. La funcionalidad especifica a uno o varios casos de uso y que afecta a multiples objetos a la vez, o que no se relaciona naturalmente con ningun objeto borde o entidad, se asigna a los objetos control. En general, se asigna un solo objeto control por caso de uso. Si el caso de uso es muy complejo, se pueden asignar objetos control adicionales. 7.2 Identification de clases segun estereotipos Para llevar a cabo la transicion del modelo de requisites al modelo de analisis 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 discutio 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, correspondiente a la "politica" de la aplicacion, a los objetos control. Esta funcionalidad depende y afecta al resto de los objetos dentro del caso de uso. Por otro lado, los objetos entidad y borde deben contener funcionalidad local, limitando su efecto en los demas objetos. El trabajo del analista consiste en distribuir de la mejor manera posible el comportamiento especificado en el modelo de requisites entre los diferentes tipos de objetos de la arquitectura de analisis. La asignacion de funcionalidad es bastante dificil en la practica, y afecta en gran medida la calidad y mantenimiento del sistema. Los buenos analistas consideran desde un principio los posibles cambios futuros al sistema. En general, los cambios mas 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 mas dificiles de administrar, ya que esta puede abarcar todos los tipos de objetos. En las siguientes secciones se describira con mayor detalle el proceso de identificacion de los tres tipos de objetos, identificando las clases para cada caso de uso segun sus estereotipos. El desafio principal en dicho proceso, es decidir cuantas y cuales clases deben asignarse por caso de uso Borde Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a traves 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 comprendidos por el sistema, y traducir los eventos del sistema en una 258 CAP. 7 MODELO DE ANALISIS