Modelo Vista Controlador, modelo 4 vistas + 1

Modelo vista controlador  El modelo–vista–controlador (MVC) es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. ara ello MVC propone la construcción de tres componentes distintos que son el modelo! la vista y el controlador! es decir! por un lado define componentes para la representación de la información! y por otro lado para la interacción del usuario

•

Modelo

Contiene el n"cleo de la funcionalidad (dominio) de la aplicación. Encapsula el estado de la aplicación.  #o sa$e nada % independiente del Controlador Controlador y la Vista. Vista. •

Vista

Es la presentación del Modelo. uede acceder al Modelo pero nunca cam$iar su estado. uede ser notificada cuando &ay un cam$io de estado en el Modelo. •

Controlador

'eacci 'eacciona ona a la petició petición n del Client Cliente! e! eecut eecutand ando o la acción acción adecua adecuada da y creand creando o el modelo modelo  pertinente ara entender cómo funciona nuestro patrón Modelo vista controlador! se de$e entender la división a travs del conunto de estos tres elementos y como estos componentes se comunican unos con los otros y con otras vistas y controladores e*ternos a el modelo principal. ara ello! es importante sa$er que el controlador interpreta las entradas del usuario (tanto teclado como el ratón)! enviado el mensae de acción al modelo y a la vista para que se proceda con los cam$ios que se consideren adecuados Comunicación El modelo! la vista y el controlador de$en comunicarse de una manera esta$le los unos con los otros! de manera que sea co&erente con las iteraciones que el usuario realizara. Como es lógico la comunicación entre la vista y el controlador es $astante $+sica pues est+n dise,ados para operar untos! pero los modelos se comunican de una manera diferente! un poco m+s sutil Modelo pasivo  #o es necesario para el modelo &acer ninguna tener alguna disposición a l! simplemente $asta con tener en cuenta su e*istencia. El modelo no tiene ninguna responsa$ilidad para comunicar  los cam$ios a la vista porque ocurren solo por orden del usuario! por lo que esta función la llevara a ca$o el controlador porque ser+ el que interprete las ordenes de este usuario de$ido a

que solo de$e comunicar que algo &a cam$iado. or esto! el modelo es se encuentra en modo inconsciente y su participación en este caso es irrisoria. Unión 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 ca$o los cam$ios necesarios al estado actual en el que estos se encuentran. Al contrario que el modelo, que puede ser asociado a múltiples asociaciones con otras vistas y controladores, cada vista solo puede ser asociada a un único controlador! por lo que &an de tener una varia$le de tipo controler  que notificara a la vista cual es su controlador o modelo asignado. -e igual manera! el controlador tiene una varia$le llamada View que apunta a la vista. -e esta manera! pueden enviarse mensaes directos el uno al otro y al mismo tiempo! a su modelo. l final! la vista es quien lleva la responsabilidad de establecer la comunicación entre los elementos de nuestro patrón MVC. Cuando la vista reci$e un mensae que concierne al modelo o al controlador! lo dea registrado como el modelo con el cual se comunicara y apunta con la varia$le controller  al controlador asignado! envi+ndole al mismo su identificación para que el controlador esta$lezca en su varia$le view el identificador de la vista y as/ puedan operar  conuntamente. El responsa$le de des&acer estas cone*iones! seguir+ siendo la vista! quit+ndose a s/ misma como dependiente del modelo y li$erando al controlador.

0as 123 Vistas Es un modelo que sirve para describir la arquitectura de sistemas de software, basándose en el uso de múltiples vistas concurrentes. Este uso de múltiples vistas permite abordar los intereses de los distintos “stakeholders” de la arquitectura por separado: usuarios nales, desarrolladores, inenieros de sistemas, administradores de pro!ecto, etc., ! mane"ar los requisitos funcionales ! no funcionales separadamente. #e describe cada una de las cinco vistas descritas, con"untamente con la notaci$n para captarla. %as vistas se dise&an mediante un proceso centrado en la arquitectura, motivado por escenarios ! desarrollado iterativamente. 'n enfoque en la presentaci$n de un sistema en '(% es conocida como )*+ vistas. Esta forma de documentar nuestros modelos divide lo que sabemos de l en cinco áreas: •

Vista de Casos de Uso 4 que contiene requisitos desarrollados en las restantes vistas.

•

Vista Lógica4 Muestra la estructura est+tica del sistema.

•

Vista Física4 Muestra el despliegue de la aplicación en la red de computadoras.

•

Vista de rocesos 4 Muestra los &ilos y procesos de eecución as/ como la comunicación entre estos.

•

Vista de !esarrollo 4 Muestra la estructura en modelos del código del sistema.

Estas vistas se presenta tradicionalmente en una ura de cuatro ca"as con un ovalo central que representa al modelo de casos de uso. -icho ráco no es '(% pero al ser tan conocido no puedo menos que incluirlo en el post. %a siuiente ura corresponde a esta imaen de la que hablo:

•

•

•

•

%a vista l$ica describe el modelo de ob"etos del dise&o cuando se usa un mtodo de dise&o orientado a ob"etos. ara dise&ar una aplicaci$n mu! orientada a los datos, se puede usar un enfoque alternativo para desarrollar alún otro tipo de vista l$ica, tal como diaramas de entidad/relaci$n.

%a vista de procesos describe los aspectos de concurrencia ! sincroni0aci$n del dise&o. %a vista f1sica describe el mapeo del software en el hardware ! re2e"a los aspectos de distribuci$n. %a vista de desarrollo describe la orani0aci$n estática del software en su ambiente de desarrollo.

%os dise&adores de software pueden orani0ar la descripci$n de sus decisiones de arquitectura en estas cuatro vistas, ! lueo ilustrarlas con un con"unto reducido de casos de uso o escenarios, los cuales constitu!en la quinta vista. %a arquitectura evoluciona parcialmente a partir de estos escenarios.