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-Vista-Controlador,
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-Vista-Controlador 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.