Modelo vista controlador

El modelovistacontrolador (MVC) es un patrn de arquitectura de software que separa los

datos y la lgica de negocio de una aplicacin de la interfaz de usuario y el mdulo encargado
de gestionar los eventos y las comunicaciones. Para ello MVC propone la construccin de tres
componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define
componentes para la representacin de la informacin, y por otro lado para la interaccin del
usuario

Modelo

Contiene el ncleo de la funcionalidad (dominio) de la aplicacin.

Encapsula el estado de la aplicacin.
No sabe nada / independiente del Controlador y la Vista.

Vista

Es la presentacin del Modelo.

Puede acceder al Modelo pero nunca cambiar su estado.
Puede ser notificada cuando hay un cambio de estado en el Modelo.

Controlador

Reacciona a la peticin del Cliente, ejecutando la accin adecuada y creando el modelo

pertinente
Para entender cmo funciona nuestro patrn Modelo vista controlador, se debe entender la
divisin a travs del conjunto de estos tres elementos y como estos componentes se comunican
unos con los otros y con otras vistas y controladores externos a el modelo principal. Para ello, es
importante saber que el controlador interpreta las entradas del usuario (tanto teclado como el
ratn), enviado el mensaje de accin al modelo y a la vista para que se proceda con los cambios
que se consideren adecuados
Comunicacin
El modelo, la vista y el controlador deben comunicarse de una manera estable los unos con los
otros, de manera que sea coherente con las iteraciones que el usuario realizara. Como es lgico
la comunicacin entre la vista y el controlador es bastante bsica pues estn diseados para
operar juntos, pero los modelos se comunican de una manera diferente, un poco ms sutil
Modelo pasivo
No es necesario para el modelo hacer ninguna tener alguna disposicin a l, simplemente basta
con tener en cuenta su existencia. El modelo no tiene ninguna responsabilidad para comunicar
los cambios a la vista porque ocurren solo por orden del usuario, por lo que esta funcin la
llevara a cabo el controlador porque ser el que interprete las ordenes de este usuario debido a

que solo debe comunicar que algo ha cambiado. Por esto, el modelo es se encuentra en modo
inconsciente y su participacin en este caso es irrisoria.
Unin del modelo con la vista y el controlador
Como no todos los modelos pueden ser pasivos, necesitamos algo que comunique al controlador
y a la vista, por lo que en este caso, si que necesitamos el modelo, ya que solo este puede llevar
a cabo los cambios necesarios al estado actual en el que estos se encuentran.
Al contrario que el modelo, que puede ser asociado a mltiples asociaciones con otras
vistas y controladores, cada vista solo puede ser asociada a un nico controlador, por lo
que han de tener una variable de tipo controler que notificara a la vista cual es su controlador o
modelo asignado. De igual manera, el controlador tiene una variable llamada View que apunta a
la vista. De esta manera, pueden enviarse mensajes directos el uno al otro y al mismo tiempo, a
su modelo.
Al final, la vista es quien lleva la responsabilidad de establecer la comunicacin entre los
elementos de nuestro patrn MVC. Cuando la vista recibe un mensaje que concierne al
modelo o al controlador, lo deja registrado como el modelo con el cual se comunicara y apunta
con la variable controller al controlador asignado, envindole al mismo su identificacin para
que el controlador establezca en su variable view el identificador de la vista y as puedan operar
conjuntamente. El responsable de deshacer estas conexiones, seguir siendo la vista, quitndose
a s misma como dependiente del modelo y liberando al controlador.

Las 4+1 Vistas

Es un modelo que sirve para describir la arquitectura de sistemas de
software, basndose en el uso de mltiples vistas concurrentes. Este uso de
mltiples vistas permite abordar los intereses de los distintos stakeholders
de la arquitectura por separado: usuarios finales, desarrolladores, ingenieros
de sistemas, administradores de proyecto, etc., y manejar los requisitos
funcionales y no funcionales separadamente. Se describe cada una de las
cinco vistas descritas, conjuntamente con la notacin para captarla. Las
vistas se disean mediante un proceso centrado en la arquitectura,
motivado por escenarios y desarrollado iterativamente.
Un enfoque en la presentacin de un sistema en UML es conocida como 4+1
vistas. Esta forma de documentar nuestros modelos divide lo que sabemos
de l en cinco reas:

Vista de Casos de Uso: que contiene requisitos desarrollados en las restantes vistas.
Vista Lgica: Muestra la estructura esttica del sistema.
Vista Fsica: Muestra el despliegue de la aplicacin en la red de computadoras.
Vista de Procesos: Muestra los hilos y procesos de ejecucin as como la comunicacin entre estos.
Vista de Desarrollo: Muestra la estructura en modelos del cdigo del sistema.

Estas vistas se presenta tradicionalmente en una figura de cuatro cajas con

un ovalo central que representa al modelo de casos de uso. Dicho grfico no
es UML pero al ser tan conocido no puedo menos que incluirlo en el post. La
siguiente figura corresponde a esta imagen de la que hablo:

La vista lgica describe el modelo de objetos del diseo cuando se

usa un mtodo de diseo orientado a objetos. Para disear una
aplicacin muy orientada a los datos, se puede usar un enfoque
alternativo para desarrollar algn otro tipo de vista lgica, tal como
diagramas de entidad-relacin.

La vista de procesos describe los aspectos de concurrencia y

sincronizacin del diseo.
La vista fsica describe el mapeo del software en el hardware y refleja
los aspectos de distribucin.
La vista de desarrollo describe la organizacin esttica del software
en su ambiente de desarrollo.

Los diseadores de software pueden organizar la descripcin de sus

decisiones de arquitectura en estas cuatro vistas, y luego ilustrarlas con un
conjunto reducido de casos de uso o escenarios, los cuales constituyen la
quinta vista. La arquitectura evoluciona parcialmente a partir de estos
escenarios.