Patrn de diseo Modelo Vista Controlador

Jos Luis Granda

1

Resumen
Un gran nmero de problemas pueden presentarse cuando las aplicaciones mezclan el cdigo de acceso a datos,
el cdigo de la lgica de negocios y el cdigo de presentacin. Tales aplicaciones son difciles de mantener, en
razn de que las interdependencias entre todos los componentes causan efectos colaterales cada vez que un
cambio se realiza en algn lado. La mezcla de cdigo en proporciones elevadas dificulta o imposibilita la
reutilizacin por causa de la dependencia sobre muchas otras clases. Agregar nuevas vistas de datos frecuente
requiere reimplementacin o cortar y pegar cdigo de la lgica de negocios, conforme sea necesario en
diferentes lugares de la aplicacin. El cdigo de acceso a datos es susceptible a problemas similares, es
necesario cortar y pegar entre mtodos de la lgica de negocios.

El Patrn de Diseo Modelo-Vista-Controlador resuelve este problema a travs de la separacin del acceso a
datos, la lgica de negocios, la presentacin de datos y la interaccin del usuario.

Las consecuencias de la aplicacin del Patrn MVC son:
Reutilizacin de componentes del modelo.
Fcil soporte para nuevos tipos de clientes.
Incremento de la complejidad del diseo.

Por lo tanto el patrn MVC representa un mecanismo de mejora de procesos de desarrollo de software, fcil de
comprender y aplicar. Que propende al trabajo en equipo implicando la transicin de un modelo de desarrollo
basado en superhroes hacia un modelo donde se requieren diferentes conjuntos de habilidades para diferentes
responsabilidades.
Claves del documentos
MVC, Modelo, Vista, Controlador, J SP 2 Model Architecture, Separacin de roles y habilidades, LMSUTPL,
Patrn de Diseo.
Introduccin
A inicios de Marzo de 2004 se empez el desarrollo del proyecto de tesis LMSUTP: Sistema de Gestin de
Aprendizaje Compatible con SCORM. LMSUTPL es una aplicacin basada en Web con soporte en tecnologas
J ava. Citamos el desarrollo de este proyecto por que representa el cambio de paradigmas relacionados con el
desarrollar software.

Generalmente el desarrollo de la tesis supone el primer proyecto real de desarrollo para muchos, y por tanto
implica poner a prueba los conocimientos no adquiridos de diseo y arquitectura de Software. Existen dos
posibles caminos, escribir miles de lneas de cdigo y esperar que la funcionalidad vaya emergiendo como por
arte de magia o detenernos a explorar diseos y arquitecturas utilizadas en la industria para luego aplicarlas.

Una de estas arquitecturas, es la arquitectura MVC o arquitectura de tres capas que responde al patrn MVC
desarrollado en 1978.
Objetivos
Demostrar que el patrn MVC representa una buena forma de mejorar el proceso de desarrollo de Software a
travs del ocultamiento de la complejidad y la separacin de responsabilidades en el grupo de desarrollo.

1
Ingeniero en Sistemas Informticos y Computacin. Modalidad Virtual UTPL, jlgranda@utpl.edu.ec , 593 7
2570275 Ext. 2347
2
Desarrollo y Fundamentacin
Para demostrar la utilidad del patrn MVC en el proceso de desarrollo de Software abordaremos un breve marco
terico, y expondremos los puntos fuertes que hacen de este patrn considerable en futuros proyectos de
desarrollo.
Sntesis del Patrn MVC
El patrn Modelo Vista Controlador fue inventado en el contexto de Smalltak con el objetivo de separar la
interface grfica del cdigo que hace que trabaje una aplicacin. Posteriormente esta idea afectara una gran
parte del cdigo de Smalltak y sera ampliamente aplicada por otros lenguajes orientados a objetos.

En el paradigma MVC las entradas del usuario, los modelos del mundo exterior y la retroalimentacin visual son
explcitamente separados y manejados por tres tipos de objetos, cada uno especializado para un conjunto de
tareas especficas.

El objetivo principal del patrn MVC fue dar soporte a los modelos mentales de los usuarios acerca del espacio
de informacin relevante y permitir a este inspeccionar y editar esta informacin.

[Norman-90] afirma que la nica manera de construir artefactos manejables es ayudar al usuario a construir
modelos del sistema. Pero esto es imposible si el modelo mental no ha sido diseado dentro del artefacto desde
el principio. Intentar adicionar los modelos mentales del usuario cuando ya se ha avanzado en el desarrollo
puede ser imposible.
Mental models are the conceptions of a system that develop in the mind of the user. Mental models possess
representations of objects or events in systems and the structural relationships between those objects and events.
Mental models evolve inductively as the user interacts with the system, often resulting in analogical, incomplete,
or even fragmentary representations of how the system works (Farooq & Dominick, 1988). Unlike cognitive and
conceptual models that describe how users should represent a domain or system, mental models describe how
users or learners actually conceive of the system or domain. Moran (1981) expresses the belief of many
designers that the design of the system controls the mental model that is developed by the user, so an ideal user's
mental model would be congruent with the conceptual model of the interface as developed by the designers.
However, Moray (1987) makes the argument that mental models evolve instead as homomorphs of the system's
structure rather than isomorphs. Users' mental models usually vary, often significantly, from the cognitive or
conceptual model promoted by the designers because of varying prior knowledge, individual abilities, and
different beliefs about the purpose and functions of the system2.
La razn de mencionar los modelos mentales del usuario aqu, tienes dos objetivos agregar un nuevo paradigma
en la etapa de recoleccin de requerimientos y explicar la motivacin del patrn MVC.

Los modelos mentales arrojan a la luz las ideas de cmo los usuarios quieren que sea el sistema de informacin
(definen en cierta forma el comportamiento del sistema). Al usuario no le interesa lo que esta dentro de la caja
negra que representa el sistema. Al usuario le interesa la funcionalidad y conseguir sus objetivos. El usuario
interacta con el sistema a travs de la interface que este le presenta, en el contexto del patrn la interface
representa la Vista que maneja las salidas graficas o de texto permitidas para el usuario por la aplicacin, la
identificacin de las salidas para un usuario se identifican en la etapa de anlisis de requerimientos, los modelos
mentales de los usuario son de mucha ayuda para lograr identificarlas.

Una vez que se presentan salidas graficas o de texto al usuario, este conforme sus modelos mentales, querr
ejecutar acciones sobre esas salidas, aqu entra el Controlador que interpreta las entradas del usuario por medio
del teclado o el ratn, y ordena el apropiado cambio de estado del modelo o a las vistas. Finalmente, para dar
cumplimiento a las rdenes del usuario, el Modelo maneja el comportamiento y datos del dominio de la
aplicacin, responde a las peticiones de informacin acerca de su estado (usualmente desde las vistas) y responde
a las instrucciones de cambio de estado (usualmente desde el controlador).

2 David H. J onassen. Operationalizing Mental Models: Strategies for Assessing Mental Models to Support Meaningful Learning and Design-
Supportive Learning Environments. (http://www.ittheory.com/jonassen2.htm)


3

Como mejora el proceso de desarrollo de Software a travs de la aplicacin del
paradigma MVC.
El uso efectivo del paradigma MVC se basa en la separacin, en tres capas, de los objetos que componen una
aplicacin. Tal separacin introduce la necesidad de crear tres categoras de objetos principales: Objetos de
vistas, Objetos de Control y Objetos de Negocios.
LMSUTPL es un ejemplo de aplicacin del patrn de diseo MVC, implementado con tecnologas J ava como
J SP, J ava Servlet y J ava Beans. La combinacin de estas tres tecnologas permite implementar el patrn de una
manera comprensible. Pero ms halla de la tecnologa, lo que pretendemos resaltar es la utilidad del patrn MVC
para el reparto de responsabilidades.
Al precisarse tres categoras generales de objetos, se precisan tres tipos de habilidades mnimas en el grupo de
desarrollo. El cuadro siguiente detalle la relacin entre los componentes del patrn, las habilidades necesarias del
desarrollador y el rol o papel en el equipo de desarrollo.

Componente MVC Papel en el equipo Habilidad requerida
VISTA Diseador de Interfaces Especializado en la tecnologa utilizada
para la creacin de vistas. Ha de conocer
la sintaxis y las estructuras del lenguaje
de programacin. Ej.: JSP, SWING, PHP,
XML, ASPX
CONTROLADOR Programador de Controladores Debe conocer en un nivel medio la
tecnologa de implementacin de control.
No requiere ser un programador
experimentado. Ej.: Conocimientos de
J ava Servlet o del modelo de Eventos de
J ava, CSharp, etc.
MODELO Programador del Modelo Programador experimentado en la
tecnologa base de implementacin. Es
quien desarrolla el corazn de la
aplicacin. Ej.: Conocimientos de J ava,
J DBC, etc.

Tal separacin de roles implica la divisin natural de responsabilidades y propende a la especializacin de los
integrantes del equipo.
Una de las ventajas de la Programacin Orientadas a Objetos y por ende del Anlisis y Diseo Orientado a
Objetos es la abstraccin, el patrn MVC podra ser la mxima expresin del ocultamiento de la complejidad. En
cada rol solo es necesario conocer las interface de acceso disponibles y nada ms.
El diseador de Vistas simplemente tendr que aprender el conjunto de mtodos accesores del tipo getters,
definidos en un conjunto de interfaces que representan los contratos de implementacin. En estos contratos
tambin de detallan el conjunto de mtodos setters que permitirn modificar el estado de los objetos del negocio
y que son lo nico que ha de conocer el programador de controladores para coordinar el flujo de la informacin
en el sistema. Los objetos de negocio o modelos implementaran los contratos definidos (definen el
comportamiento) de tal forma que los resultados esperados, por el diseador de vistas y el programador de
controladores, sean los correctos, de esto se encarga el Programador del modelo.
Otro aspecto clave de la aplicacin del patrn MVC es que mejora la comunicacin del equipo, en el sentido de
que dicha comunicacin se realiza en funcin de los contratos definidos y por ende todas hablan el mismo
idioma.
4
Al existir la separacin de vistas, controladores y modelos es ms sencillo realizar labores de mejora como:
Agregar nuevas vistas.
Agregar nuevas formas de recolectar las ordenes del usuario (interpretar sus modelos mentales).
Modificar los objetos de negocios bien sea para mejorar el performance o para migrar a otra tecnologa.
Las labores de mantenimiento tambin se simplifican y se reduce el tiempo necesario para ellas. Las
correcciones solo se deben hacer en un solo lugar y no en varios como sucedera si tuvisemos una
mezcla de presentacin e implementacin de la lgica del negocio.
Las vistas tambin son susceptibles de modificacin sin necesidad de provocar que todo el sistema se
paralice. Adicionalmente el patrn MVC propende a la especializacin de cada rol del equipo, por tanto
en cada liberacin de una nueva versin se vern los resultados.
Conclusiones
Si nos remitimos al modelo de madurez CMMI, la aplicacin del patrn MVC permitira dar el salto del nivel en
que los proyectos se dan gracias a la participacin del superhroe, hacia el segundo nivel en que los proyectos
se realizan gracias a la participacin de un equipo de desarrollo.
Referencias

David H. Jonassen. Operationalizing Mental Models: Strategies for Assessing Mental Models to Support
Meaningful Learning and Design- Supportive Learning Environments.
(http://www.ittheory.com/jonassen2.htm).

J oseph Bergin. Building Graphical User Interaces with the MVC Pattern.
(http://csis.pace.edu/~bergin/mvcgui.html)

J os Luis Granda. LMSUTPL: Sistema de Gestin del Aprendizaje compatible con SCORM. 2004