Resumen

Fuentes de confusin
A lo largo del presente TFC se han consultado mltiples fuentes sobre el patrn Modelo-VistaControlador: [Ree home] [Mic 1] [Kon 04] [Sun 02] [Bur 92] [Pan 03] [Sund 96] [Sund 98] [Wikipedia] [Moo 05] [Oktaba]. Estas fuentes estn en un rango de fechas muy amplio, teniendo en cuenta la juventud de la informtica, y van desde los primeros ejemplos de sistemas interactivos de Trygve Reenskaug en el ao 1973, hasta una presentacin del mismo autor en abril de 2006, pasando por diversos autores que incluso crean sus propias versiones del patrn. El Modelo-Vista-Controlador se cre para Smalltalk a finales de los setenta. A partir de entonces su uso se ha ido extendiendo cada da ms para la construccin de sistemas software con interfaz grfica. Su enorme uso ha provocado que haya tambin multitud de referencias al patrn Modelo-Vista-Controlador, que en muchas ocasiones son fuentes de confusin porque se utilizan distintos contextos de aplicacin para el patrn, se tratan de conseguir objetivos distintos, los nombres de los componentes del patrn son los mismos pero con diferentes responsabilidades, los diagramas de clases y de secuencia son tambin diferentes. Adems, hay referencias donde se dan ejemplos de implementacin del patrn con sus particularidades, ya que la mayora de los entornos de desarrollo de aplicaciones, sobre todo de aplicaciones web, dan facilidades para implementar el patrn Modelo-Vista-Controlador. A veces esto no es del todo bueno, ya que realmente no implementan de forma correcta la esencia del patrn y confunden an ms al lector, que utiliza estas implementaciones como ejemplo para aprender a usar el patrn Modelo-Vista-Controlador. A continuacin se citan distintas fuentes que son contradictorias o que muestran diferentes interpretaciones del patrn Modelo-Vista-Controlador porque: Se mueven en diferentes contextos. Persiguen objetivos distintos. Dan los mismos nombres a los componentes pero les conceden distintas responsabilidades. Muestran diferentes diagramas de clase. Muchas se centran en la implementacin concreta con un entorno de desarrollo particular.

Intentan explicar la solucin en un universo conceptualmente limitado.

Fuente 1 Cre el patrn Modelo-Vista-Controlador como una solucin obvia al problema general de dar al usuario el control sobre su informacin, vista desde diferentes perspectivas [] []Un aspecto importante del MVC original es que su Controlador era responsable de crear y coordinar sus vistas. Tambin, en mis implementaciones posteriores del MVC, una vista acepta y maneja las entradas del usuario que se refieren a ella. El Controlador acepta y maneja las entradas referentes al conjunto Controlador/Vista, llamado ahora Herramienta [...]El propsito esencial del MVC es reducir la distancia entre el modelo mental del usuario y el modelo computacional que existe en el ordenador. La solucin ideal del MVC le proporciona al usuario la ilusin de que est viendo y manipulando la informacin del dominio directamente. La estructura es til si el usuario necesita ver el mismo elemento del modelo simultneamente en diferentes contextos y/o desde diferentes puntos de vista. La figura 10.1 ilustra esta idea'' [MVCweb]

Figura 10.1: Reducir la distancia entre el modelo mental y el computacional. Fuente 1

Trygve Reenskaug es el creador del Modelo-Vista-Controlador. Su objetivo era mostrarle al usuario lo que hay dentro de su aplicacin de una forma ms agradable e intuitiva, para que pudiera manejar la informacin que necesita en su trabajo. Esta referencia se ha estudiado en profundidad en la parte El patrn ModeloVista-Controlador de Reenskaug en la pgina 9 por ser la referencia original del Modelo-Vista-Controlador.

Fuente 2 ``Cuando se construyen aplicaciones interactivas, como con otros programas, la modularidad de componentes tiene enormes beneficios. Aislar las unidades funcionales unas de otras tanto como sea posible hace ms fcil para el diseador de la aplicacin entender y modificar cada unidad particular, sin tener que saber todo sobre las otras unidades. [...] [...]La metfora Modelo-Vista-Controlador es una forma de disear e implementar aplicaciones software interactivas que aprovecha la ventaja de la modularidad, para ayudar al desarrollo conceptual de las aplicaciones, y para permitir que las piezas ya desarrolladas para una aplicacin sean reutilizadas en una nueva aplicacin. La metfora impone una separacin de comportamientos entre el modelo real del dominio de la aplicacin, las vistas usadas para mostrar el estado del modelo y la edicin o control del modelo y las vistas.'' [KrPo88]] Esta referencia es tambin importante, porque ha sido la referencia ms antigua al Modelo-Vista-Controlador durante mucho tiempo, hasta que Trygve Reenskaug public sus artculos de finales de los setenta. En la mayora de los trabajos sobre el ModeloVista-Controlador aparece esta referencia. El punto de vista que se muestra aqu se centra en la reutilizacin de los componentes y en la facilidad para conectar nuevos componentes de interfaz sin afectar al modelo. Esta es la idea que ms predomina hoy en da en cuanto al uso del patrn Modelo-VistaControlador. Pero sin embargo tambin tiene en cuenta la idea inicial de Reenskaug, ya que habla del desarrollo conceptual de las aplicaciones. La figura 10.2 es la que se presenta en esta fuente para mostrar los componentes del Modelo-Vista-Controlador y sus relaciones. Esta es la nica fuente que muestra una simetra en el comportamiento del modelo con respecto a las vistas y el controlador. Ante un cambio en su estado, el modelo avisa de este cambio tanto a la vista como al modelo. En el resto de fuentes que se han consultado, el modelo simplemente avisa a la vista y no al controlador. Esto hace que el modelo sea algo ms mecnico, sistemtico, no hace distinciones entre el modelo y la vista, cuando cambia avisa a todos y al que le afecte el cambio ser el que tenga que buscar los datos accediendo al modelo.

Figura 10.2: Envo de mensajes del Modelo-Vista-Controlador. Fuente 2

Fuente 3 ``El propsito de muchos sistemas informticos es recabar informacin de un almacn de datos y mostrarlos al usuario. Despus de que el usuario cambie los datos, el sistema guarda las actualizaciones en el almacn de datos. Como el principal flujo de informacin es entre el almacn de datos y la interfaz de usuario, alguien se puede ver tentado a juntar ambas partes para reducir la cantidad de cdigo y mejorar el rendimiento de la aplicacin. Sin embargo, este enfoque, aparentemente natural, tiene algunos problemas significativos. Un problema es que la interfaz de usuario suele cambiar ms frecuentemente que el sistema de almacenamiento de datos. Otro problema con el acoplamiento de las partes de datos y de la interfaz de usuario es que las aplicaciones corporativas suelen incorporar lgica de negocio que va ms all de la transmisin de datos. Cmo se puede modularizar la funcionalidad de la interfaz de usuario de una aplicacin web para que se puedan modificar de forma sencilla las partes? El patrn de diseo Modelo-Vista-Controlador es fundamental para la separacin de la lgica de la interfaz de usuario de la lgica de negocio. Desafortunadamente, la popularidad del patrn ha dado como resultado bastantes descripciones errneas. En particular, el trmino ``controlador'' ha sido usado para referirse a diferentes cosas en diferentes contextos. Afortunadamente, la llegada de las aplicaciones web ha ayudado a resolver parte de esta ambigedad, ya que la separacin entre la vista y el controlador es ms evidente.'' [MVC] Microsoft contina en la misma lnea que Krasner y Pope en su trabajo [KrPo88] donde vieron el potencial que poda ofrecer la metfora Modelo-Vista-Controlador propuesta

por Reenskaug para facilitar la reutilizacin de componentes y mejorar la modificabilidad de los sistemas. La figura 10.3 es uno de los diagramas de clases con los que Microsoft ilustra la estructura del Modelo-Vista-Controlador. A diferencia de los dos trabajos anteriores, en este trabajo no aparece nada relacionado con el modelo mental del usuario, se centra nicamente en la mejora de la modificabilidad de la interfaz de una aplicacin.

Figura 10.3: Estructura de las clases del MVC. Fuente 3

Fuente 4 ``El patrn MVC resuelve el problema de actualizacin de las vistas de una aplicacin (ventanas de la interfaz de usuario) cuando cambian sus datos. [...] [...]La vista contiene la interfaz grfica de usuario, que es la parte de la aplicacin que puede ver el usuario. Cuando el usuario modifica los datos en la pantalla se inicia una accin, esa accin va al controlador. El controlador determina qu tipo de accin ha sido solicitada y llama a las interfaces apropiadas del modelo. El modelo puede estar compuesto de varios componentes, clases o paquetes, dependiendo de la tecnologa que implemente la lgica de negocio de la aplicacin.'' [Kontio-04] Este trabajo centra su inters en el uso del patrn Modelo-Vista-Controlador como una forma de mantener la coherencia en una interfaz de usuario que est compuesta por varias vistas. La figura 10.4 muestra los elementos del patrn Modelo-VistaControlador. En este caso, el controlador acta como elemento de entrada y la vista como salida. Adems el modelo slo notifica sus cambios a la vista, que se ha registrado como observador del modelo, pero no se indica cmo la vista conoce la informacin del estado que debe actualizar ante el cambio en el modelo.

Figura 10.4: Elementos del patrn de diseo Modelo-Vista-Controlador. Fuente 4

Este trabajo est en sintona con la idea de Reenskaug, se trata de facilitar al usuario el trabajar con mucha informacin y desde distintos puntos de vista, haciendo que ante un cambio todo sea coherente. Pero en ningn momento habla sobre los modelos mentales, se centra en el problema concreto de la actualizacin de todas las vistas ante un cambio en el mismo modelo. Fuente 5 ``MVC es particularmente apropiada para aplicaciones web interactivas, aplicaciones donde un usuario web interacciona con un sitio web, con mltiples interacciones de las pantallas que muestra y mltiples peticiones de muestreo de datos.'' [Sun-02] Este trabajo se centra en las facilidades que aporta el patrn MVC a la construccin de aplicaciones web. En la figura 10.5 se puede observar que, al contrario que en la fuente anterior, es la vista la que recibe las entradas del usuario, y las pasa al controlador que provoca un cambio de estado en el modelo en funcin de la entrada del usuario que le pasa la vista. Cuando el modelo cambia se lo notifica slo a la vista, que en este caso s que accede al modelo para pedir la informacin del estado que debe actualizar. El controlador elije la vista que se debe mostrar para cada operacin que realiza el usuario.

Figura 10.5: Arquitectura del Modelo-Vista-Controlador. Fuente 5

Es interesante observar la forma en la que el modelo avisa a la vista de que ha cambiado. En ningn momento el modelo pasa informacin a la vista sobre su estado, es la vista la que accede al modelo para conseguir esa informacin, tras el mensaje que el modelo envi de que haba cambiado. Esto es un ejemplo claro de relacin ambigua, el modelo podr admitir distintas vistas porque le son indiferentes. Como se ha visto en la fuente 2, la metfora Modelo-Vista-Controlador impone una separacin de comportamientos. En este caso, la vista rompe esta imposicin porque contiene tanto la entrada como la salida, con lo que mezcla esos comportamientos. Debido a la globalidad dentro de una clase, ante un cambio en la entrada o la salida, la otra parte se puede ver afectada, porque al estar todo en la misma clase, no puede existir independencia. Fuente 6 ``El concepto central del interfaz de usuario de Smalltalk-80 es el paradigma Modelo-VistaControlador (MVC). Es elegante y simple, pero bastante diferente al enfoque de las aplicaciones tradicionales. Debido a su novedad, requiere de alguna explicacin, explicacin que no est fcilmente disponible en las referencias de Smalltalk-80.'' [Burbeck] En este trabajo de 1992 se habla sobre lo difcil que es encontrar referencias del paradigma Modelo-Vista-Controlador (los patrones no se conocan como tal an) de Smalltalk-80. Se ha podido comprobar, a lo largo de este trabajo, que en muchos artculos o pginas web dedicadas al patrn Modelo-Vista-Controlador no hay referencias a los artculos originales de Reenskaug. Parece ser, que dichos artculos tardaron en salir a la luz, y de ah que hasta hace no mucho tiempo las referencias ms antiguas sobre el patrn Modelo-Vista-Controlador databan del ao 1988. Esto ha sido tambin una de las fuentes de confusin, porque los autores no podan consultar los documentos que contenan las ideas originales, y utilizaron las implementaciones de Samlltalk para sacar sus propias conclusiones. Fuente 7 ``El Modelo Vista Controlador es un enfoque de diseo que separa el modelo de objetos de la aplicacin de la interfaz grfica de usuario, inventando sobre los ochenta. Despus se ha convertido en un patrn de diseo comnmente aceptado. El principal objetivo detrs de este patrn es desacoplar la vista de los datos (capa de presentacin) del verdadero procesamiento de los datos, as el modelo puede usarse para varias vistas. Esto se consigue usando tres tipos diferentes de objetos que interactan entre ellos de forma poco acoplada con sus discretos conjuntos de tareas.'' [Panchal-03]

En este trabajo se habla del acoplamiento entre la capa de presentacin y la de datos y se quiere reducir este acoplamiento. Pero, qu es acoplamiento? a cul de todas sus acepciones se refiere el trabajo? Si no se dice a cul de sus significados se hace referencia no se puede utilizar de forma precisa, ya que cada lector puede suponer un significado distinto. Para reducir el acoplamiento por dependencia hay que aumentar el acoplamiento por nmero de llamadas. Por ejemplo, cuando el modelo avisa a la vista de que ha cambiado, podra enviarle los datos que ha de mostrar. Sin embargo, para no crear una relacin unvoca y que la dependencia sea grande, slo enva un mensaje de que cambi. Y la vista al recibir ese mensaje y mediante una relacin unvoca accede a la informacin del estado del modelo. Esta relacin unvoca se podra eliminar si la relacin del modelo hacia la vista fuera unvoca en vez de ambigua. Por lo tanto, para reducir el acoplamiento por dependencia del modelo hacia la vista, se ha aumentado el acoplamiento por nmero de llamadas entre modelo y vista. La figura 10.6 muestra la forma que tiene el autor de implementar el Modelo-Vista-Controlador.

Figura 10.6: Diagrama del Modelo-Vista-Controlador. Fuente 7

Este trabajo tambin est en la lnea de pensamiento del autor original, ya que se centra en la presentacin de los datos en mltiples vistas. Tambin hace hincapi en la necesidad de mantener estas vistas sincronizadas, que es algo a lo que Reenskaug no hace referencia en sus primeros artculos.

Fuente 8 ``La arquitectura Modelo/Vista/Controlador fue diseada para reducir el esfuerzo de programacin que se requiere para construir sistemas que hagan uso de mltiples y sincronizadas presentaciones de los mismos datos. Sus caractersticas principales son que el modelo, los controladores y las vistas se tratan como entidades separadas y que los cambios que se hacen sobre el modelo deberan reflejarse automticamente en cada una de las vistas.'' [Sundsted-96] Se hace pensar al lector que por el hecho de separar en tres objetos diferentes la aplicacin el esfuerzo de crear la aplicacin es menor. Cuando lo que en realidad se consigue con el patrn Modelo-Vista-Controlador es facilitar los cambios de una aplicacin ya construida, y no por el hecho de que est separada en los tres componentes del patrn, sino porque esos componentes estn relacionados de forma que facilitan los cambios en la interfaz. El autor con entidades separadas quiere hacer entender que son entidades independientes? Como se ha venido explicando a lo largo de este trabajo, la separacin no produce independencia. En la figura 10.7 se muestran una serie de controladores y vistas que pertenecen al mismo modelo, pero no aporta ninguna informacin ms, no se sabe la relacin entre cada uno de ellos y si las dependencias estn sin flechas, en UML, significa que las relaciones son en ambos sentidos, lo que no facilitara los cambios en la aplicacin. Este diagrama ofrece muy poca informacin del modelo, y slo la ofrece a nivel de organizacin y no de comportamiento. No se puede ver en la figura quin recibe la entrada y cmo se comunican los componentes de la arquitectura en el flujo de una accin concreta.

Figura 10.7: La arquitectura del Modelo-Vista-Controlador. Fuente 8

Fuente 9 ``Mientras que el patrn de diseo MVC se usa tpicamente para la construccin de interfaces de usuario completas [...]

[...]El patrn de diseo MVC separa un componente software en tres piezas distintas: un modelo, una vista y un controlador.'' [Sundsted-98] Este trabajo utiliza el Modelo-Vista-Controlador como herramienta para crear interfaces, pero sin darse cuenta lo que adems le proporciona, la facilidad de cambio en esas interfaces. Sin embargo, para el autor ese no es el objetivo, el objetivo es construir las interfaces. La figura 10.8 muestra la separacin de los tres componentes y que entre ellos existen relaciones. Pero estas relaciones no se especifican, y con este diagrama no se puede intuir un posible funcionamiento de los componentes del patrn. Partir una aplicacin en trozos sin ms no implica mejorar la calidad del software, el ``divide y vencers'' no es siempre funciona.

Figura 10.8: Patrn de diseo Modelo-Vista-Controlador. Fuente 9

Fuente 10 ``Modelo Vista Controlador (MVC) es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de control en tres componentes distintos. El patrn MVC se ve frecuentemente en aplicaciones web, donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la pgina. Modelo: Esta es la representacin especfica del dominio de la informacin sobre la cual funciona la aplicacin. El modelo es otra forma de llamar a la capa de dominio. La lgica de dominio aade significado a los datos; por ejemplo, calculando si hoy es el cumpleaos del usuario o los totales, impuestos o portes en un carrito de la compra. Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario.

Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista.

Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como puede ser una base de datos) para almacenar los datos. MVC no menciona especficamente esta capa de acceso a datos.

Es comn pensar que una aplicacin tiene tres capas principales: presentacin (IU), dominio, y acceso a datos. En MVC, la capa de presentacin est partida en controlador y vista. La principal separacin es entre presentacin y dominio; la separacin entre V/C es menos clara. Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: 1. El usuario interacta con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botn, enlace) 2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificacin de la accin solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a travs de un gestor de eventos (handler) o callback. 3. El controlador accede al modelo, actualizndolo, posiblemente modificndolo de forma adecuada a la accin solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos estn a menudo estructurados usando un patrn de comando que encapsula las acciones y simplifica su extensin. 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el patrn de observador puede ser utilizado para proveer cierta indireccin entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun as el modelo en s mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene

acceso directo al modelo, dejando que el controlador enve los datos del modelo a la vista. 5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.'' [Wikipedia] Como en casi todas las referencias, lo primero que se menciona es la separacin en tres componentes. Esta afirmacin no aporta nada, ya se ha demostrado que separar no implica mejorar el software. Se trata sobre la capa de acceso a datos, diciendo que el Modelo-Vista-Controlador no trata este tema. Que no lo trate hace que sea ambiguo, que puede adoptar distintas soluciones para esa capa de acceso a datos, porque eso no es lo esencial del Modelo-Vista-Controlador, es una peculiaridad que no aporta nada al significado de la metfora. Se reconoce la diversidad de implementaciones del patrn Modelo-Vista-Controlador, y como en algunos casos los componentes tienen distintas formas de relacionarse o distintas responsabilidades que llevar a cabo, y se da una variante en la que no queda muy claro si la vista recibe las peticiones y se las pasa al controlador o las recibe el controlador, parece que el controlador es la entrada, pero el ltimo punto donde dice que la interfaz espera nuevas interacciones puede crear dudas en el lector. Se utiliza una frase que se ha visto tambin a lo largo de este Trabajo Fin de Carrera como es ``proveer cierta indireccin entre el modelo y la vista''. Se utiliza esta frase para explicar el uso del patrn observador, como complemento del Modelo-Vista-Controlador, que se utiliza para implementar el mtodo de aviso del modelo a las vistas. Qu significa indireccin entre el modelo y la vista? No se querr decir que crea relaciones ambiguas? Al fin y al cabo se busca una forma de que el modelo avise a las vistas sin que se relacione con ellas de forma unvoca, porque el objetivo es que el modelo sea independiente de las vistas, o como mnimo, que las vistas le sean indiferentes. As se lograr que los cambios de la interfaz no se propaguen al ncleo del sistema, lo que facilitar los cambios en la interfaz porque habr que modificar menos clases. Las relaciones ambiguas son un concepto que se puede definir en un universo con incertidumbre, sin embargo, cmo se define indireccin entre dos componentes? Fuente 11

``El Modelo Vista Controlador es un mtodo testeado de separacin de la interfaz de usuario de una aplicacin de su lgica de dominio. El objetivo principal del MVC es aislar los cambios de la interfaz grfica de usuario y evitar que estos cambios impliquen cambiar la lgica de dominio de la aplicacin. La primera razn para esta divisin es que la interfaz de usuario y la lgica de dominio tienen diferentes motivos de cambio y diferente frecuencia de cambio. Al hacer esta separacin, puedes conseguir cambiar la interfaz de usuario sin tocar la lgica de dominio y viceversa. El MVC a veces se confunde con otros patrones que tienen el mismo objetivo de separar la interfaz de usuario de la lgica de dominio como el ``Presentation Abstraction Control''.'' [Moore] La lnea de pensamiento de este trabajo est muy relacionada con la de Microsoft. El objetivo es aislar los cambios de la interfaz de usuario sin tocar el ncleo de la aplicacin. Pero el autor se enreda porque habla de lgica de dominio, qu es la lgica de dominio? Se quiere separar de la interfaz? La lgica del domino no es el modelo mental? Y Reenskaug no quera acercar el modelo mental y el software a travs de la interfaz? Adems dice que es un mtodo testeado, pero no da referencias para comprobar que eso sea cierto, es decir hay estudios tericos sobre el beneficio obtenido por el uso del Modelo-Vista-Controlador? Si existen, dnde estn publicados? Quines son los autores? ... Otra cosa es que el autor se marca como objetivo que los cambios en la interfaz no afecten al resto de la aplicacin y viceversa. Esto no es posible, ya se ha visto que facilitar los cambios en la interfaz y que as no afecten estos cambios al modelo, implica que los cambios en el modelo se dificultan. Debido a que la interfaz depende del modelo en la solucin Modelo-Vista-Controlador, de forma que ante un cambio en la lgica del modelo la interfaz se ver afectada. Hay que recordar al lector, que esto permite que la modificabilidad general del sistema aumente, ya que el nmero de de cambios que requiere la lgica del modelo es mucho menor que los necesarios en la interfaz de usuario, que es una parte ms voluble. Pero el lector debe tener muy presente que facilitar los cambios en la interfaz no es gratuito. Fuente 12

``Es muy frecuente que se solicite cambio a interfaz. Los cambios a interfaz deberan ser fciles y efectuados en tiempo de ejecucin. El cambio de interfaz no debera de tener consecuencias para el ncleo del cdigo de la aplicacin. Solucin: el sistema se divide en tres partes: procesamiento, entradas y salidas. Modelo: encapsula los datos y la funcionalidad de la aplicacin.

Vista: despliega la informacin contenida en el modelo (pueden existir varias vistas).

Controlador: est asociado a cada vista, recibe entradas que traduce en invocaciones de mtodos del Modelo o de Vista. El usuario interacta con el sistema solamente va controladores.'' [Oktaba]

Este trabajo busca aislar el modelo de los cambios en la interfaz del usuario, de esta forma se facilitaran los cambios de la interfaz, que cambia frecuentemente. Es la misma lnea de pensamiento que mantiene Microsoft. Pero al lector, se le da una solucin, que no est justificada, y que debe creerse sin tener ninguna base terica por detrs que la respalde. El lector puede llegar a pensar que el ``divide y vencers'' soluciona el problema, y esto no es cierto como se ha venido demostrando a lo largo de este trabajo.

Resumiendo
Ante este amplio abanico de referencias, donde se muestran los diferentes puntos de vista de los autores que han estudiado el Modelo-Vista-Controlador, convendra hacer un resumen, ya que, en realidad hay puntos comunes. Las ideas fundamentales en las que se basa el Modelo-VistaControlador podran simplificarse en dos: reducir la distancia humano-mquina y facilitar los cambios de la interfaz de usuario. En la lnea de la primera idea, estaran los autores que utilizan el Modelo-Vista-Controlador para dar soporte a un modelo con mltiples vistas, los que tienen como objetivo mantener la coherencia entre las distintas vistas de un mismo modelo, o los que pretenden sintonizar el modelo mental del usuario con el software.

En sintona con la segunda idea, estaran los autores que buscan facilitar la modificacin de los sistemas, los que tratan de mejorar la reutilizacin de componentes, o los que buscan la programacin concurrente de componentes. Ambas ideas estn relacionadas, porque para poder reducir la distancia humano-mquina, habr que realizar mltiples pruebas de forma que el usuario y el programador sintonicen sus ideas. De esta forma, la aplicacin ser ms cercana al modelo mental del usuario. Pero para realizar estas pruebas, se necesita que los cambios en la interfaz de usuario sean rpidos y cmodos. Ah est la relacin entre las dos ideas, y por eso el Modelo-Vista-Controlador resuelve ambos problemas.

El Modelo-Vista-Controlador de Reenskaug
Trygve Reenskaug es el creador del patrn Modelo-Vista-Controlador. Durante su estancia en Xerox Parc entre 1978 y 1979 desarroll las ideas en las que se basa el patrn conocido hoy en da, y sus ideas se usaron para implementar el Modelo-Vista-Controlador en Smalltalk-80. El objetivo fundamental que persegua Reenskaug era reducir la distancia entre el modelo mental del usuario y el modelo computacional. La figura 10.9 muestra esta idea. Quiere hacer creer al usuario que ve y manipula la informacin del dominio directamente. La estructura que crea es til, desde su punto de vista, cuando los usuarios necesitan ver el mismo elemento del modelo de forma simultnea desde diferentes puntos de vista o contextos.

Figura 10.9: Reducir la distancia entre el modelo mental y el computacional

Para lograr este objetivo de acercar lo que se implementa en el software al modelo mental que tiene el usuario de lo que est utilizando en una aplicacin, Reenskaug propone la divisin en varios componentes de la aplicacin.

Cosa-Modelo-Vista-Editor
En una primera versin, en Mayo de 1979, Reenskaug define tres elementos: modelo, vista y editor. Reconoce al modelo como una implementacin de una abstraccin que es de inters para el usuario. Es decir, el modelo representa en el computador, el modelo mental del usuario, y lo consigue mediante una coleccin de datos que estn junto con los mtodos necesarios para procesar esos datos. Esta forma de implementar el modelo, vista en la actualidad recuerda a los objetos, donde los datos y los mtodos que trabajan con esos datos forman un objeto. A finales de los setenta estaba comenzando el estudio de los objetos y esta idea parece estar presente en el documento de Reenskaug, aunque quiz referida a los tipos abstractos de datos, que fueron un paso intermedio entre el modelo estructurado y el orientado a objetos. Adems, Reenskaug reconoce la imposibilidad de crear modelos totalmente consistentes, y aboga por modelos ``menos exactos'' y ms factibles de lograr. Esta idea puede interpretarse como un alejamiento del pensamiento estructurado de la poca donde se crea que aplicando un mtodo se poda alcanzar la perfeccin en el software. Reenskaug subraya la importancia de que el modelo debe ser una representacin limpia de la abstraccin utilizada, sin tener ningn tipo de informacin sobre la presentacin en la pantalla de la informacin. La vista es el componente capaz de mostrar una o ms representaciones grficas del modelo y puede tambin, ejecutar operaciones sobre el modelo. Cada vista estar asociada a un modelo, que podr, a su vez, tener ms vistas asociadas. Esto es lgico, ya que Reenskaug quera conseguir representar el mismo dato desde diferentes puntos de vista, para que el usuario tuviera un mayor control de su informacin. El editor es una interfaz entre el usuario y una o ms vistas. Sirve para proporcionar al usuario las operaciones que puede realizar sobre el modelo, por ejemplo con mens dinmicos que se adaptan al contexto. Para Reenskaug, una tarea se realiza mejor con varias vistas en la pantalla al mismo tiempo, y el usuario querr trabajar con ellas a la vez. El editor debe crear un conjunto de vistas, colocarlas en la pantalla, coordinarlas y proporcionar al usuario una interfaz apropiada.

Modelos-Vistas-Controladores
En diciembre de 1979, Reenskaug introduce el trmino controlador y da una nueva definicin para los trminos modelo, vista y editor, que sigue estando presente. Sobre el modelo dice que representa conocimiento y que no es muy interesante que sea un nico objeto, por lo tanto, el modelo puede ser una estructura de objetos. Adems, Reenskaug propone que debera existir una correspondencia entre el modelo y el mundo que se percibe. Esta idea, es muy tpica en el modelo orientado a objetos, ya que se tiende a creer, que copiar la realidad facilita conseguir un software de mayor calidad. [Incertidumbre] trata la problemtica de copiar la realidad en el software, donde se explica porque no siempre esta poltica es la ms beneficiosa. La vista est asociada a un modelo y es su representacin visual. Para conseguir los datos que debe mostrar, la vista debe obtenerlos preguntndole al modelo. Adems, la vista tambin puede actualizar el modelo. La vista por lo tanto depender del modelo, porque tiene que mandarle mensajes para comunicarse con l. El nuevo componente, el controlador, es el enlace entre un usuario y el sistema. Es el encargado de proporcionar al usuario una forma para que ejecute sus operaciones. Una vez que el controlador recibe las instrucciones del usuario se lo notifica a las vistas. Reenskaug deja bien claro que el nico componente que puede recibir instrucciones del usuario es el controlador. Tambin se especifica que un controlador puede manejar ms de una vista. Un editor es, para Reenskaug, un controlador especial que proporcionan algunas de las vistas. Permite al usuario modificar la informacin que se presenta en las vistas, acta como una extensin del controlador. Se podra ver al editor como la parte del controlador que modifica las vistas, mientras que el controlador slo recibe peticiones del usuario que redirige a las vistas. Hay ciertos aspectos que Reenskaug no deja del todo claros, y que por lo tanto, pueden ser interpretados desde diferentes puntos de vista. En ningn momento dice que el controlador o el editor ordena cambios en el modelo, slo habla de que la vista puede hacer modificaciones en el modelo. Habr lectores que sobreentiendan que el controlador es el que modifica el modelo, pero Reenskaug, slo dice que el controlador avisa a las vistas de las entradas del usuario. Sin embargo en la figura 10.9 se muestra la situacin opuesta a lo que describe en sus artculos. El usuario parece que interacciona directamente con la vista, y es el controlador el que modifica el modelo.

El Modelo-Vista-Controlador. Su pasado y presente

Ms de veinte aos despus de la creacin del Modelo-Vista-Controlador, Reenskaug public un documento que pretende ser un lenguaje de patrones sobre el Modelo-Vista-Controlador. Reenskaug quiere que este documento sirva como punto de partida para que la comunidad que trabaja con patrones investigue y estudie los distintos puntos de vista desde los que se puede observar el patrn Modelo-Vista-Controlador. Hoy en da los patrones son algo muy comn en la informtica, estn de moda, y las empresas buscan programador que sepan crear aplicaciones web siguiendo el patrn Modelo-Vista-Controlador. En los aos en los que se cre este patrn, los patrones como se entienden hoy en el mundo de la informtica no existan, pero a lo largo de estos aos, y debido a su gran aplicacin en el mundo de las aplicaciones web sobre todo, se ha convertido en uno de los patrones ms conocidos. En este documento Reenskaug se centra en la relacin hombre mquina, que sigue siendo su objetivo. Quiere reducir la distancia que separa al hombre de la mquina, facilitando la construccin de sistemas de informacin habitables. Para ello cree que es imprescindible implicar al usuario en la creacin de esos sistemas de informacin. Plantea la creacin de un lenguaje de modelado que sea comn al usuario y a los diseadores, de forma que el modelo mental del usuario est lo ms cerca posible del modelo computacional. Para ello, propone tambin que este lenguaje de modelado comn sea tambin un lenguaje de programacin, de forma que los usuarios puedan crear las primeras capas de sus propios sistemas de informacin. En cuanto a las revisiones que hace de las ideas originales del patrn Modelo-VistaControlador, Reenskaug comienza explicando la divisin de un objeto de negocio en dos partes, el modelo y el editor. El modelo maneja la informacin y el comportamiento del modelo de objetos del usuario, reflejando as su modelo mental. El editor es el responsable de la presentacin y de las operaciones del usuario. Este editor lo divide a su vez, en controlador y vista, que son responsables de la entrada del usuario y la presentacin respectivamente. Al final, propone una estructura donde estara el modelo, la herramienta, que coordina un grupo de editores, que pueden estar a su vez divididos en controlador y vista. Por lo tanto, Reenskug confunde an ms al lector, ya que esta versin que propone dice que es el Modelo-VistaControlador original de 1979. En el documento original no existe el trmino controlador, y adems, aqu se dice que el editor puede dividirse en un par vista-controlador, hecho que tampoco se contemplaba en el documento original. Al final del documento se tratan varias polticas posibles para gestionar la actualizacin de un grupo de vistas cuando cambia el estado del modelo.

Dos arquitecturas de sistema: MVC y DCA

Recientemente, y con motivo de una conferencia, Reenskaug realiz una presentacin donde trataba el patrn Modelo-Vista-Controlador. Reducir la distancia entre el modelo mental y el modelo computacional sigue siendo el objetivo. Hay un modelo y varias herramientas, que son un conjunto de controlador y vistas. El modelo almacena la informacin de dominio, las vistas presentan y editan esa informacin, el controlador construye y gestiona las vistas y la herramienta da al usuario acceso directo a la informacin. Reenskaug habla de la separacin de la informacin de dominio y la presentacin que aporta el patrn Modelo-Vista-Controlador. Tambin trata el tema de la reduccin del acoplamiento, reduccin que propone conseguir encapsulando los componentes.

El Modelo-Vista-Controlador de Microsoft
Microsoft trata el patrn Modelo-Vista-Controlador en un artculo que pertenece a una coleccin donde se tratan los patrones de diseo de aplicaciones web. El problema que se plantea resolver Microsoft en su artculo es cmo modularizar la funcionalidad de la interfaz de usuario de una aplicacin web de forma que se puedan modificar de forma sencilla las partes individuales. Microsoft se plantea un contexto donde la interfaz de usuario cambia de una forma ms habitual que la lgica de negocio de la aplicacin. Por eso se quiere lograr facilitar los cambios en la interfaz de usuario, porque facilitando este tipo de cambios se conseguir facilitar la modificabilidad del sistema en general, ya que estos cambios son los ms frecuentes. Se consideran una serie de motivaciones que aconsejan utilizar el patrn Modelo-VistaControlador como solucin al problema planteado en el contexto que se presenta. La interfaz cambia ms a menudo que la lgica de negocio, si se tiene en un mismo objeto a las dos partes, ser ms difcil aislar a la lgica de negocio de posibles equivocaciones en el cdigo cuando no era necesario modificar su cdigo. Cuando se cambian los datos de una vista, el resto de vistas debe actualizarse automticamente. Se necesitan perfiles de programadores distintos para la parte de la interfaz y de la lgica de negocio. La interfaz tiene las responsabilidades de mostrar la informacin al usuario y de enviar a la lgica de negocio las peticiones de actualizacin que realiza el usuario. Hay que facilitar la migracin de la interfaz a otras tecnologas y reducir el

riesgo de introducir equivocaciones en el cdigo de la lgica de negocio. Hay que mejorar la testeabilidad del sistema para facilitar as la parte de pruebas que es tan tediosa. Estas motivaciones son las que hacen presentar como solucin el patrn Modelo-VistaControlador, que separa el modelado del dominio, la presentacin y las acciones basadas en la entrada del usuario en tres clases separadas. El modelo maneja el comportamiento y los datos del dominio de la aplicacin, responde a las peticiones de informacin sobre su estado (que normalmente le har la vista) y responde a las instrucciones para cambiar su estado (que normalmente le har el controlador). La vista maneja la presentacin de la informacin. El controlador interpreta las entradas del usuario e informa al modelo y/o a la vista para que cambien apropiadamente. La figura 10.10 permite ver cmo se relacionan los tres componentes del patrn Modelo-VistaControlador. Hay que hacer notar que en este diagrama de clases el modelo es independiente de la vista y del controlador. Esta independencia permite que el modelo pueda probarse y crearse de forma independiente al resto de los componentes. Adems, tambin se consigue que los cambios en la interfaz de usuario no se propaguen al modelo, y por lo tanto, se consigue aislar al modelo de esos cambios.

Figura 10.10: Estructura de las clases del MVC

Esto es lo que Microsoft llama la variante del modelo pasivo. En esta situacin el controlador es el que efecta los cambios de estado en el modelo y avisa a las vistas para que se actualicen. Las vistas accedern al modelo para consultar el nuevo estado que deben mostrar al usuario. La figura 10.11 muestra el diagrama de secuencia que ilustra una operacin en el modelo solicitada por el usuario y la correspondiente actualizacin de la vista.

Figura 10.11: Comportamiento del modelo pasivo

Cuando el modelo es el nico que es consciente de un cambio en su estado, el modelo debe avisar a las vistas y al controlador de su cambio para que se actualicen debidamente, dando lugar a lo que Microsoft llama modelo activo. Aparece por lo tanto una dependencia que Microsoft plantea eliminar con el uso del patrn Observador. Esa dependencia va a ser imposible eliminarla, y lo que se logra con el Observador es que la relacin del modelo hacia las vistas y el controlador sea ambigua. Esto permitir seguir manteniendo aislado al modelo de los cambios en la interfaz. La figura 10.12 muestra el diagrama de clases de su variante modelo activo donde utiliza el patrn Observador para que el modelo notifique sus cambios. Adems, la figura 10.13 ilustra el comportamiento de los componentes del patrn Modelo-VistaControlador en el modelo activo.

Figura 10.12: Uso del Observador para desacoplar el modelo de las vistas en el modelo activo

Figura 10.13: Comportamiento del modelo activo

El uso del patrn Modelo-Vista-Controlador, segn Microsoft aporta los siguientes beneficios: mejora la testeabilidad del sistema, soporta mltiples vistas de un mismo modelo y facilita los cambios, todo ello gracias a la separacin de los tres componentes. En esto se equivoca Microsoft ya que la separacin no es la que provoca los beneficios del patrn, se ver que son el tipo de relaciones entre los componentes lo que permitir que el software sea fcilmente modificable. Por otro lado, Microsoft advierte que el uso del Modelo-Vista-Controlador aumenta la complejidad de la solucin y que si la frecuencia de cambio del estado del modelo es muy alta, puede provocar distintos problemas de funcionamiento de la aplicacin.

Mitos
A lo largo de este Trabajo Fin de Carrera se ha observado, como en muchas de las referencias sobre el Modelo-Vista-Controlador que se han consultado, la explicacin que se da a las soluciones aportadas se basa en la utilizacin de mitos. Mitos muy extendidos en el mundo de la informtica que se quieren aclarar en este trabajo.

Modularidad Separacin Independencia

Modularizar es separar una aplicacin en mdulos. Existe la creencia, en el mundo de la informtica, que esa separacin produce independencia entre las partes, independencia que nos aportar unos beneficios en la aplicacin. Lo primero que se debera hacer es pensar en modularidad como sinnimo de organizacin. Cuando se dice que queremos modularizar una aplicacin en realidad lo que queremos es

organizarla, lo que producir a lo mejor alguna que otra divisin o separacin. La separacin es una condicin necesaria para lograr independencia entre dos partes, pero no es una condicin suficiente. El hecho de tener dos partes separadas no hace que automticamente sean independientes entre s. Para conseguir que dos partes sean independiente no debe haber relaciones entre ellas. Pero en una aplicacin los objetos deben colaborar para llevar a cabo tareas complejas, que por s mismos no pueden realizar. Por lo tanto, aunque se debe minimizar el nmero de dependencias entre componentes a la hora de crear aplicaciones, es inevitable y necesario que existan dependencias. Las relaciones entre componentes software son direccionales y de dos tipos, unvocas y ambiguas. Se intentarn crear, siempre que sea posible, relaciones ambiguas, que facilitan los cambios en el software. Se dice que la relacin de la clase A hacia la clase B es unvoca, si al cambiar la clase B por la clase B', la clase A debe cambiarse por A'. La figura 10.14 muestra una relacin unvoca de la clase A hacia la clase B. Este tipo de relacin dificulta los cambios en el software, ya que ante un cambio en la clase B, la clase A se ve afectada. El cambio de B se propaga hacia A y obliga a modificar tambin la clase A. El mbito del cambio es mayor, ya que hay ms clases implicadas en cada cambio, esto provoca que realizar cambios en la clase B sea ms difcil, lento y costoso, con lo que se dificulta la modificabilidad del sistema.

Figura 10.14: Relacin univoca de la clase a hacia la clase B

Se dice que la relacin de la clase A hacia la clase B es ambigua, si al cambiar la clase B por la clase B', la clase A no necesita cambiar. La figura 10.15 representa una relacin ambigua o indiferente de la clase A hacia la clase B. Este tipo de relacin facilita los cambios en la aplicacin porque al no propagarse los cambios se acota el mbito de los cambios de B a la clase B. Los cambios son ms sencillos y rpidos de realizar, lo que reduce el coste de mantenimiento. Se podra modificar, o incluso sustituir, la clase B sin que la clase A tenga que cambiar. Se facilita por lo tanto la modificabilidad de la aplicacin.

Figura 10.15: Definicin de relacin ambigua de la clase A hacia la clase B

Decir que modularizar una aplicacin es beneficioso porque facilita los cambios es falso. Modularizar es partir en mdulos, y eso no asegura independencia ni indiferencia. La indiferencia se consigue mediante el uso de relaciones ambiguas. Por lo tanto, para facilitar la modificabilidad hay que buscar independencia e indiferencia, cosas que no se consiguen con slo modularizar la aplicacin. Un ejemplo se muestra en la figura 10.16, donde los componentes son los mismos que en el Modelo-Vista-Controlador. Sin embargo, el modelo depende de la vista, as que, ante un cambio en la vista, el modelo se ver afectado y deber modificarse. Esto demuestra, que modularizar slo no basta, hay que organizar los componentes y sus relaciones de forma que se pueda conseguir independencia o indiferencia en el sentido correcto. No es lo mismo que el modelo dependa de la vista, a que la vista dependa del modelo.

Figura 10.16: El modelo depende de la vista

El todopoderoso ``divide y vencers''

Este es otro mito que est muy relacionado con la modularidad. Alguien que haya programado alguna vez es muy posible que haya odo hablar del ``divide y vencers''. En la informtica existe la premisa de que ante un problema grande la solucin es dividir el problema, resolver las partes y unirlas de nuevo. Esta es la esencia del ``divide y vencers'': partir, tratar las partes por separado y volverlas a unir. Este mtodo reduce la complejidad descriptiva, pero no consigue reducir la complejidad por incertidumbre. Hace la suposicin de que puede tratar las partes de forma independiente,

situacin que no es real, ya que los componentes estn relacionados. Ante un cambio en uno de los componentes no se facilita la modificabilidad por el hecho de dividir, luego la complejidad por incertidumbre no se est reduciendo. Se puede ver un ejemplo de divide y vencers en la figura 10.17, donde para un conjunto de 6 elementos relacionados entre s, se proponen dos modularizaciones distintas.

Figura 10.17: Conjunto de elementos y dos posibles modularizaciones

La primera opcin la divisin de la lnea vertical produce la situacin que se muestra en la figura 10.18. Existen dos partes con tres componentes cada una, pero ambas partes estn relacionadas porque los elementos 2 y 6 de la parte de la izquierda estn relacionados con los elementos 3 y 5 de la parte de la derecha respectivamente. Ante cambios en una de las partes la otra se puede ver afectada por esos cambios, luego no pueden ser tratadas de forma independiente.

Figura 10.18: Primera separacin

La segunda opcin se muestra en la figura 10.19, donde se han dividido los componentes de acuerdo a la lnea de divisin diagonal de la figura 10.17. Esta segunda opcin es an peor, porque tampoco se pueden manejar las dos partes de forma independiente, y adems ahora, el nmero de relaciones entre estas dos partes es mayor. Ahora, ante cualquier cambio en cualquier componente de una u otra parte, esos cambios afectarn a las dos partes

Figura 10.19: Segunda separacin

Se puede ver en estas figuras que la complejidad descriptiva ha disminuido, ya que ahora hay slo dos componentes frente a los 6 que haba en la situacin inicial. Sin embargo, esto no permite que puedan ser tratados de forma independiente los dos componentes. Las relaciones existentes entre ellos no facilitan los cambios, por lo que la complejidad por incertidumbre no se ha reducido. Reducir esta complejidad ser el objetivo para conseguir que los cambios en una parte no se propaguen a otras. El ``divide y vencers'' ignora las relaciones entre las partes en que divide el problema. En un universo no aditivo, la suma de las partes no es el todo, y por lo tanto el ``divide y vencers'' no funciona. El espacio de soluciones donde se contemplan las dos dimensiones de complejidad, la descriptiva y la de incertidumbre, puede ser un espacio no aditivo, y por lo tanto, no es seguro que el ``divide y vencers'' funcione.

El malo del acoplamiento

El trmino acoplamiento tiene mltiples significados, y por lo tanto es polismico. En el mundo de la informtica, mucha gente habla de ``bajo acoplamiento y alta cohesin'' como dos objetivos a la hora de construir software fcilmente modificable. Pero, qu es el acoplamiento? Es el nmero de llamadas entre dos componentes? Es la dependencia que existe de un componente hacia otro? Utilizar este trmino puede llevar a contradicciones como que para reducir el acoplamiento por dependencia se aumenta el acoplamiento por nmero de llamadas. Cuando se debilita una relacin utilizando ambigedad, puede ser necesario crear otra relacin unvoca en sentido contrario. En ese tipo de casos, para reducir un acoplamiento se aumenta otro.

El problema con este trmino es que existe la premisa en el mundo de la informtica de que para que una aplicacin sea fcilmente modificable el acoplamiento debe ser bajo, y eso no es cierto. Como se ha visto, el trmino acoplamiento tiene diferentes significados, y para reducir un acoplamiento hay que aumentar otro, por lo tanto qu acoplamiento hay que bajar para que la aplicacin sea modificable? El grado de acoplamiento no es til como herramienta para medir las propiedades del software.

Solucin
En la informtica, durante muchos aos ha predominado el pensamiento estructurado, que tiene sus orgenes en el mtodo cartesiano. Esta gran influencia en el pensamiento ha hecho extenderse la idea de que la incertidumbre en el software es erradicable. La incertidumbre est presente en el software a travs de las abstracciones, como pueden ser las variables, las funciones,... Adems, se est comprobando que los requisitos cambian a lo largo de los proyectos, lo que va en contra del pensamiento estructurado que requiere unos requisitos completos, exactos, estables, ... para as poder erradicar la incertidumbre. Adems, se puede ver como un espacio de soluciones donde slo se contempla la complejidad descriptiva no es capaz de resolver el problema del Modelo-Vista-Controlador. Los autores se enredan con la utilizacin de mitos y de frases como dependencias directas, indirectas, ... Para conseguir encontrar una solucin hay que introducir una nueva dimensin en este espacio de soluciones. Hay que considerar la complejidad por incertidumbre, a partir de esta ampliacin en el espacio de soluciones se podr dar una solucin al Modelo-Vista-Controlador. Debido a estos motivos, es necesario introducir ambigedad en la solucin. De esta forma se podr manejar la incertidumbre que existe en el software y se encontrar una solucin al Modelo-Vista-Controlador. El uso de la ambigedad disminuir la complejidad por incertidumbre, aunque eso s, no de forma gratuita. A cambio, la complejidad descriptiva puede aumentar. Pero sin el uso de la ambigedad, habr problemas que no se podrn resolver ya que buscarn solucin a su problema en un espacio terico ms limitado.

Aclarando el Modelo-Vista-Controlador
A partir de la solucin propuesta de considerar las dos dimensiones de la complejidad, la descriptiva y la de incertidumbre, el Modelo-Vista-Controlador puede inventarse a partir de qu es lo que se quiere y cmo se quiere conseguir. Lo que se quiere es facilitar los cambios en la

interfaz de usuario de una aplicacin, y para conseguirlo hay que aplicar la ambigedad como instrumento de diseo.

Una clase con entrada, salida y proceso

En la figura 10.20 se muestra la situacin inicial, donde la clase A contiene los mtodos de entrada (leer) y salida (imprimir) de sus datos. A causa de la globalidad que existe dentro de la clase A, ante un cambio en cualquiera de los mtodos, el resto de mtodos se pueden ver afectados. Los mtodos de una clase no son independientes entre s, ya que tienen como puntos de unin los atributos de la clase, que son variables globales dentro del mbito de esa clase. Para conseguir independizar los mtodos leer e imprimir de la clase A hay que sacar estos mtodos a dos clases diferentes. De esta forma los mtodos leer e imprimir son independientes, y los cambios en uno de ellos, no afectan al otro.

Figura 10.20: Clase con mtodos para la entrada y la salida

Sacando la entrada y la salida de la clase inicial

La figura 10.21 muestra como se han creado dos nuevas clases, Imprimir y Leer, que contendrn cada una de ellas el mtodo imprimir y leer respectivamente. De esta forma, ante un eventual cambio en la entrada o la salida del sistema, la otra parte no se ver afectada. Sin embargo, y debido a que la clase A depende de las dos nuevas clases, ante un cambio en cualquiera de ellas, la clase A se vera afectada, porque el cambio se propagara hasta ella. Esta nueva situacin incrementa la posibilidad de que, debido a un cambio en la interfaz del sistema (entrada o salida), se introduzcan, de forma involuntaria ciertas equivocaciones en el cdigo de la clase A. Adems, en una aplicacin, normalmente, la parte ms voluble suele ser la de entrada y salida. Por estas razones sera conveniente invertir las relaciones de dependencia, de forma que las clases Imprimir y Leer dependan de la clase A y no al revs.

Figura 10.21: Salida y entrada independientes de la clase inicial

Independizando la clase inicial de la entrada y la salida

Se han invertido las relaciones de dependencia, de forma que ahora tanto la clase Imprimir como la clase Leer dependen de la clase A. Adems, ha sido necesario crear una nueva dependencia, ya que ahora la clase A no sabe cuando debe imprimirse el dato que le llega. La clase Leer, cuando lee un carcter y se lo enva a la clase A informa a la clase Imprimir de que debe imprimir. Por lo tanto, la clase Leer depender tambin de la clase Imprimir, pero de una forma ambigua, por eso la lnea de la dependencia es ms fina. Una relacin ambigua evita que se propaguen los cambios entre las clases que une, de forma que un cambio en Imprimir no tendra porqu afectar a la clase Leer. Esta clase Imprimir, cuando recibe la orden de la clase Leer, accede al modelo para conseguir el carcter que ha de imprimir. La figura 10.22 muestra el diagrama de clases de la nueva situacin. Se puede observar que la clase A no depende de ninguna de las otras dos clases, lo que permite, que se puedan hacer cambios en la entrada y la salida sin que esos cambios se propaguen a la clase A. Al no propagarse, los cambios estn ms localizados, afectan a menos clases dentro de la aplicacin, y por lo tanto, son ms fciles de realizar y menos costosos.

Figura 10.22: Cambio de las dependencias para independizar la clase inicial de la entrada y la salida

La clase inicial debe avisar sobre sus cambios

Se plantea una nueva situacin, donde la clase A puede querer imprimir algo aunque no se haya ledo nada por la entrada. Ante esta situacin, donde la nica clase que conoce la necesidad de imprimir es la clase A, es ella la que debe avisar a la clase Imprimir para que lleve a cabo la impresin correspondiente. La figura 10.23 muestra esta nueva situacin. Cabe destacar que desaparece la dependencia de Leer hacia Imprimir, ya que ahora, el aviso de que hay que imprimir lo hace la clase A. La relacin de dependencia de A a Imprimir es una relacin ambigua, que permitir aislar los cambios de Imprimir, de forma que no se propaguen a la clase A. La forma en la que avisa A mediante esta relacin ambigua es el envo de un mensaje a Imprimir del estilo ``imprime''. Este tipo de mensaje permite que siempre que Imprimir mantenga un mtodo con ese nombre los cambios en su cdigo no afecten a la clase A.

Figura 10.23: La clase inicial avisa a la salida

De la misma manera puede ser interesante o necesario que la clase A avise a Leer. Si por ejemplo, ante un cambio en su estado, la clase A necesita que se le pida un carcter al usuario, deber avisar a la clase Leer para que ese dato puede solicitarse. Mediante una relacin ambigua tambin, A avisa a Leer con un mensaje del tipo ``lee'', como se muestra en la figura 10.24.

Figura 10.24: La clase inicial avisa a la entrada y la salida

Por ltimo, otra posibilidad, es que ante una lectura errnea o con algn tipo de incidente, la clase Leer deba avisar a Imprimir para que se imprima un cdigo de error o una advertencia al usuario que est introduciendo los datos. Est relacin no es ambigua ya que la clase Leer le deber pasar a Imprimir los datos necesarios para la impresin, ya que en esta ocasin la clase A no es consciente del dato que se ha recibido, ya que Leer acta como filtro de errores. Esta situacin se muestra en la figura 10.25.

Figura 10.25: La clase inicial avisa a la entrada y la salida y la entrada informa a la salida de un error sintctico

Se ha visto a lo largo de este ejemplo, como se manejaba la ambigedad en la solucin para llegar a una situacin donde se facilitan los cambios en la interfaz de usuario de una aplicacin. Si se fija bien, el lector podra intercambiar la clase A por el modelo, Imprimir por la vista y Leer por el controlador del patrn Modelo-Vista-Controlador. Por lo tanto, se ha podido ver paso a paso cmo se llega a la solucin del patrn Modelo-Vista-Controlador, al aplicar la ambigedad en una clase con elementos de entrada y salida. En el patrn Modelo-Vista-Controlador, se suele utilizar el patrn Observador como ayuda para gestionar los avisos a las vistas y los controladores. Si as fuera entre las clases A e Imprimir y Leer estara la interfaz ``Observer''. Esta solucin ya se ha visto en la variante del modelo activo de Microsoft.

Esencia del patrn Modelo-Vista-Controlador

A lo largo de este trabajo se ha visto como los fines que se buscan con el patrn Modelo-VistaControlador son dos principalmente. Uno es reducir la distancia entre el modelo mental y el modelo computacional y otro es facilitar los cambios de la interfaz de usuario. Ambos objetivos estn relacionados de una forma muy directa. Para que se pueda reducir la distancia entre el modelo mental y el modelo computacional, se requiere un trabajo de sintonizacin a travs de prototipos, de forma que el usuario vaya sintiendo la aplicacin como algo ms cercano a su forma de pensar. Para conseguir esta sintonizacin habr que realizar constantes cambios en la interfaz de usuario de los prototipos, y por ello, el objetivo de facilitar los cambios en esa parte de la aplicacin es muy til. En el trabajo [Xavi] se hace un estudio sobre la integracin de la usabilidad dentro del proceso de desarrollo del software, donde se trata ms en profundidad la problemtica de los modelos mentales.

El patrn Modelo-Vista-Controlador debe considerarse un conjunto de varias ideas, donde hay dos ideas principales. Reducir la distancia humano-mquina y facilitar cambios en la interfaz. Esta es la esencia del Modelo-Vista-Controlador, ms que la eleccin de una u otra arquitectura particular, que como ya se ha visto, pueden ser fuente de confusin. Lo importante es saber para qu se quiere utilizar el Modelo-Vista-Controlador y cmo se quiere utilizar. Se quieren conseguir los dos objetivos que plantea el patrn y se consiguen mediante el uso de la ambigedad como herramienta de diseo software para afrontar la incertidumbre. Adems, mediante el uso de la ambigedad y el reconocimiento de la incertidumbre inevitable en el problema, se puede justificar con un marco terico la solucin obtenida. Se puede comprobar como la solucin particular que se ha aportado en este trabajo del patrn Modelo-Vista-Controlador logra satisfacer los dos objetivos. Para llegar a la solucin se ha tenido que ampliar el espacio de soluciones que utilizaban los distintos autores para justificar las soluciones aportadas en sus estudios. Se ha aadido una dimensin ms al espacio de soluciones, de forma, que adems de considerar la complejidad descriptiva, se tiene tambin en cuenta la complejidad por incertidumbre. Para enfrentar la incertidumbre que ahora se contempla es necesario introducir ambigedad en la solucin. La ambigedad permite crear las abstracciones utilizadas, como las clases Leer e Imprimir, las relaciones ambiguas de la clase A hacia las clases Leer e Imprimir, ... Este problema, como tantos otros, casi todos en la informtica, es un ejemplo ms de que la incertidumbre es inevitable y til en el software.