Partes: 1, 2

 

Se han desarrollado a lo largo de los años, desde la presentación de este patrón a la comunidad científica 3 variantes fundamentales, que se presentan brevemente a continuación.

Variante I: (Figura 1)

Variante en la cual no existe ninguna comunicación entre el Modelo y la Vista y esta última recibe los datos a mostrar a través del Controlador.

Variante II: (Figura 2)

Variante en la cual se desarrolla una comunicación entre el Modelo y la Vista, donde esta última al mostrar los datos los busca directamente en el Modelo, dada una indicación del Controlador, disminuyendo el conjunto de responsabilidades de este último.

Variante III: (Figura 3)

Variante en la cual se diversifica las funcionalidades del Modelo teniendo en cuanta las características de las aplicaciones multimedia, donde tienen un gran peso las medias utilizadas en estas.

Figura 1: Variante inicial del Patrón MVC.

Figura 2: Variante Intermedia del Patrón MVC.

Figura 3: Variante modificada para Aplicaciones Multimedia del MVC, conocida como MVCMM. (Tomado de [STE04])

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente:

2. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace)
3. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.
4. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario. Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
5. 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 (si se utiliza la variante 2 descrita anteriormente, de lo contrario lo obtiene a través del Controlador). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de observador puede ser utilizado para proveer cierta indirección 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 envíe los datos del modelo a la vista, según lo descrito en la segunda variante.
6. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

Se presenta a continuación un resumen del Patrón MVC utilizando la plantilla estándar para la descripción de patrones:

Contexto/Problema:

Conviene desacoplar los objetos dominio (Modelo), las ventanas (Vista) y los manejadores (Controlador), a fin de brindar soporte a un mayor reuso de los objetos dominio y reducir al mínimo el impacto que los cambios de la interfaz y los manejadores tienen en ellos. ¿Qué hacer?

Solución:

Definir las clases dominio (Modelo) para que no tengan acoplamiento ni visibilidad directa respecto a las clases ventana (Vista) y para que los datos de la aplicación y de la funcionalidad se conserven en las clases de dominio, no en las de ventana. Definir las clases manejadores (Controlador) para que procesen los eventos (peticiones) al sistema y redireccionen a las clases dominio y ventana tanto el procesamiento como la visualización de resultados respectivamente.

Algunos de sus principales beneficios son:

• Menor acoplamiento.

1. Desacopla las vistas de los modelos.
2. Desacopla los modelos de la forma en que se muestran e ingresan los datos.

• Mayor cohesión.
• 1. Cada elemento del patrón esta altamente especializado en su tarea (la vista en mostrar datos al usuario, el controlador en las entradas y el modelo en su objetivo de negocio).
• Las vistas proveen mayor flexibilidad y agilidad.
• 1. Se puede crear múltiples vistas de un modelo.
  3. Las vistas pueden anidarse.
  4. Se puede cambiar el modo en que una vista responde al usuario sin cambiar su representación visual.
  5. Se puede sincronizar las vistas.
  6. Las vistas pueden concentrarse en diferentes aspectos del modelo.
• Mayor facilidad para el desarrollo de clientes ricos en múltiples dispositivos y canales
• 1. Una vista para cada dispositivo que puede variar según sus capacidades.
  2. Una vista para la Web y otra para aplicaciones de escritorio.
• Más claridad de diseño.
• Facilita el mantenimiento.
• Mayor escalabilidad.

EPÍGRAFE II: Una variación que acerca el patrón MVC a los software educativos cubanos.

Para poder comprender lo que es el Software (y consecuentemente la ingeniería del Software), es importante examinar las características del Software que lo diferencian de otras cosas que los hombres pueden construir.

El Software es un elemento del sistema que es lógico, en lugar de físico. Por tanto el software tiene unas características considerablemente distintas a la del hardware.[PRE01]

El software educativo cubano, tiene diferentes características marcadas en comparación con los desarrollados en otros países del mundo. Todo esto producido por el avance y la experiencia acumulada en el área de la pedagogía en nuestro país que lo ubica en uno de los primeros lugares en el planeta en este sentido.

Las aplicaciones educativas cubanas explotan grandemente los conceptos del entorno hipermedia, así como incorporan de forma profunda las técnicas y conocimientos de bases de datos relacionales y la Programación Orientada a Objetos más avanzada que se utiliza hoy día; como consecuencia de la necesidad de implementar diversos y complejos métodos pedagógicos desarrollados por nuestros educadores en las distintas ramas de la enseñanza cubana.

Si en otros países las multimedia llamadas educativas se circunscriben a meros software que presentan y evalúan alguna determinada materia, en Cuba por el contrario se desarrollan productos que realizan análisis exhaustivos de la navegación del usuario, mantienen actualizado el historial de trabajo de los usuarios y permiten preparar el software para diferentes entornos de trabajo a dichos usuarios teniendo en cuenta determinadas características. Esto hace que nuestras aplicaciones se vean grandemente recargadas en el almacenamiento, procesamiento y actualización de una gran cantidad de información constantemente.

Durante las dos pasadas décadas, se han desarrollado un gran número de métodos de modelado. Los investigadores han identificado los problemas del análisis y sus causas y han desarrollado varias notaciones de modelado y sus correspondientes conjuntos de heurísticas para solucionarlos (…) Se emplean modelos para poder comunicar de forma compacta las características de la función y su comportamiento. Se aplica la partición para reducir la complejidad. Son necesarias las visiones esenciales y de implementación del software para acomodar las restricciones lógicas impuestas por los requisitos del procesamiento y las restricciones físicas impuestas por otros elementos del sistema. [PRE01]

Precisamente por las características del software educativo cubano, los diseñadores han buscado y aplicado soluciones ya trabajadas internacionalmente y con un gran número de aplicaciones prácticas en este sentido, dentro de las que se encuentra la utilización del Patrón MVC. No obstante este patrón tal y como está descrito actualmente, aún con su variante más actual no responde completamente a las características mencionadas.

El diseño del software, al igual que los enfoques de diseño de ingeniería en otras disciplinas, va cambiando continuamente a medida que se desarrollan métodos nuevos, análisis mejores y se amplía el conocimiento. [PRE01]

El Software se construye para procesar los datos, para transformar datos de una forma u otra, es decir, para aceptar una entrada de información, manipularla de alguna manera y producir una salida de información (…) es importante recalcar, sin embargo, que el software también procesa sucesos. Un suceso representa algún aspecto de control del sistema y no es más que un dato binario (es encendido o apagado, verdadero o falso, está allí o no). [PRE01]

Como ya ha sido descrito en el epígrafe anterior el MVC divide la arquitectura de una aplicación en 3 tipos de clases fundamentales, con las responsabilidades siguientes:

Clase Vista <<View>>:

• Recepcionar peticiones.
• Mostrar respuestas del sistema.

Clase Modelo <<Model>>:

• Procesar peticiones del sistema.
• Generar datos de respuesta del sistema.
• Gestionar y almacenar la información.

Clase Controlador <<Controller>>:

• Gestionar procesamiento de peticiones.
• Gestionar muestra de respuestas del sistema.

De igual forma si analizamos el Lenguaje Unificado de Modelado (UML) [Unified Modeling Language], este propone para el desarrollo del Modelo de Análisis de las aplicaciones, tres tipos de clases fundamentales, con las cuales podemos expresar todas las funciones de cualquier software, con sus respectivas responsabilidades:

Clase Interfaz <<Interface>>:

• Recepcionar peticiones al sistema.
• Mostrar respuestas del sistema.

Clase Entidad <<Entity>>:

• Gestionar datos (información) necesaria para el sistema.
• Almacenar datos (información) persistentes del sistema.

Clase Controlador <<Controller>>:

• Procesar Información del sistema.
• Gestionar visualización de respuesta del sistema.

Las responsabilidades se relacionan con las obligaciones de un objeto respecto a su comportamiento. Esas responsabilidades pertenecen, esencialmente, a las dos categorías siguientes:

1. Conocer

   Entre las responsabilidades de un objeto relacionadas con hacer se encuentran:

   • Hacer algo en uno mismo
   • Iniciar una acción en otros objetos
   • Controlar y coordinar actividades en otros objetos

   Entre las responsabilidades de un objeto relacionadas con conocer se encuentran:

   • Estar enterado de los datos privados encapsulados
   • Estar enterado de la existencia de objetos conexos
   • Estar enterado de cosas que se puede derivar o calcular

   "La calidad de diseño de la interacción de los objetos y la asignación de responsabilidades presentan gran variación. Las decisiones poco acertadas dan origen a sistemas y componentes frágiles y difíciles de mantener y entender, reutilizar o extender. Una implementación hábil se funda en los principios cardinales que rigen un buen diseño orientado a objetos." [LAR99]

   Precisamente en lo expresado por Craig Larman referente a la asignación de responsabilidades a las clases, basamos nuestro análisis del diseño de aplicaciones educativas en Cuba, las cuales refuerzan o sobrecargan a determinadas clases al ser responsables de soportar la mayoría de las acciones en este tipo de software.

   Se presentan a continuación un conjunto de consideraciones al respecto:

   1. Según lo planteado en UML, la clase Controlador queda sobrecargada en sus responsabilidades al asumir el procesamiento de toda la información necesaria en el sistema.
   2. La clase Entidad, utilizando los conceptos de UML, separa eficientemente de la clase Controladora la responsabilidad referente al almacenamiento y gestión de la información persistente en la aplicación, lo que es sumamente beneficioso, no solo desde el punto de vista del diseño, sino para la implementación y mantenimiento del sistema.
   3. La clase Modelo, según el Patrón MVC, asume todas las responsabilidades que UML deposita en la clases Entidad, sobrecargando (dadas las características del software educativo cubano y su gran trabajo con las Bases de Datos) dicha clase por completo.

   Por estas consideraciones realizadas, se propone las siguientes modificaciones, las cuales se muestran gráficamente en los Anexos 1 y 2:

   2. Mantener la clase Vista (Interfaz según UML) del patrón original con sus responsabilidades establecidas.
   3. Mantener la separación que MVC establece entre las clases Modelo y Controlador (dividiendo las responsabilidades que UML asigna a la clase Controlador), quitándole a la Clase Modelo la responsabilidad asociada con la gestión y almacenamiento de los datos persistentes en la aplicación.
   4. Definir una nueva clase denominada Modelo – Entidad, que asuma la responsabilidad de la gestión y el almacenamiento de toda la información persistente de la aplicación, así como la comunicación con la Base de datos del sistema en cuestión.

   VALORACIÓN ECONÓMICA Y APORTE SOCIAL

   El trabajo que se presenta en esta ponencia, representa ahorros en los siguientes renglones:

   • Tiempo de desarrollo de las aplicaciones multimedia educativas.
   • Esfuerzo de desarrollo de los analistas y diseñadores de las aplicaciones, así como del resto de los miembros de los equipos de trabajo.
   • Análisis y planificación de los mantenimientos de las aplicaciones.
   • Desarrollo de los mantenimientos a los sistemas.

   El contenido de esta ponencia explica el aumento de la productividad y la eficiencia en el desarrollo de los software educativos multimedia y reporta beneficios de carácter social al lograr una disminución del tiempo del proceso productivo de dichas aplicaciones y su más rápida explotación por los usuarios finales.

   CONCLUSIONES:

   En el trabajo presentado se ofreció una visión bastante abarcadora del estado actual de los patrones de arquitectura, así como específicamente de uno de los más utilizados, el Patrón Modelo – Vista – Controlador (MVC). Se analizaron de forma exhaustiva las características de este patrón, su desarrollo y sus actuales variantes de presentación en el diseño de software.

   Se presentaron las características del software educativo cubano que producen su diferenciación con respecto al resto de los desarrollados bajo la misma clasificación en el resto del mundo y que trae como consecuencia un reanálisis de la arquitectura de las aplicaciones de este corte en Cuba y la investigación de mejores soluciones para el diseño de estas, posibilitando un mejor trabajo en la implementación, reutilización de los componentes desarrollados, así como en el mantenimiento.

   Se mostró al final del mismo una variante de modificación al Patrón MVC original, denominada Modelo – Vista – Controlador – Entidad (MVC - E) como propuesta de diseño arquitectónico, a las aplicaciones educativas cubanas.

   RECOMENDACIONES:

   1. Profundizar en el resto de los patrones de diseño y asignación de responsabilidades asociados con el patrón MVC.
   2. Aplicar lo planteado en esta ponencia en el análisis, diseño e implementación de aplicaciones desarrolladas en nuestra universidad para probar su veracidad y efectividad. (Esta modalidad fue analizada, diseñada e implementada en dos trabajos de diplomas de corte educativo en este propio año 2006, una de ellas proyecto productivo de nuestra universidad).
   3. Comparar estadística los resultados de las pruebas y los criterios de los desarrolladores de equipos que utilicen el patrón MVC estándar y la modificación propuesta en este trabajo.

   ANEXOS:

   Anexo 1: Correspondencia entre UML – MVC y MVC – E.

   

   Anexo 2: Esquema del MVC – E.

   

   REFERENCIAS BIBLIOGRÁFICAS:

   • [LAR99] Larman, Craig. "UML y Patrones. Introducción al análisis y diseño orientado a objetos" 2da Edición (traducción de la edición original en ingles "Appling UML and patterns. An introduction to the object oriented analysis and design"), Editorial Prentice Hall Hispanoamericana, S.A. México, 1999.
   • [PRE01] Pressman, Roger S. "Ingeniería de Software. Un enfoque práctico." 5ta Edición (traducción de la edición original en Inglés "Software Engineering. A practical approach"), Editorial Mac Graw Hill, Madrid, España, 2001.
   • [SHA96] Shaw, M. y Garlan, D. "Software Architecture". Editorial Prentic-Hall, New York, E.U.A. 1996.
   • [STE04] Stefan, Sauer; Engels, Gregor. "Extending UML for Modeling of Multimedia Applications". , 6 de abril de 2004.

   BIBLIOGRAFÍA:

   • Altadill Izura, Pello Xavier. "Struts. Implementación del patrón MVC en aplicaciones Web", 15 de mayo de 2006.
   • Anastacio Velásquez, Miguel M. "Model View Controller (MVC)" http://www.informatizate.net/articulos/model_view_controller_mvc_20040324.html, 18 de febrero de 2006.
   • Engels, Gregor. UML-based Behavior. Specification of Interactive Multimedia Applications. http://wwwcs.upb.de/cs/ag-engels/Papers/2001/SauerHCC01.pdf , 8 de abril de 2004.
   • Engels, Gregor. Integrating Software Engineering and User-centred Design for Multimedia Software Developments. http://wwwcs.upb.de/cs/ag-engels/Papers/2003/EngelsSauerNeu-HCC03.pdf , 23 de mayo de 2004.
   • Hennicker, Rolf; Koch, Nora. "Systematic Dessing of Web Applications with UML". http://www.itec.uni-klu.ac.at/~harald/proseminar02/sauer1.pdf, 6 de abril de 2004.
   • Hennicker, Rolf. A UML – based methodology for Hypermedia Desing. http://www.pst.informatik.uni-muenchen.de/personen/kochn/Uml2000.pdf , 8 de abril de 2004.
   • Larman, Craig. "UML y Patrones. Introducción al análisis y diseño orientado a objetos" 2da Edición (traducción de la edición original en ingles "Appling UML and patterns. An introduction to the object oriented analysis and design"), Editorial Prentice Hall Hispanoamericana, S.A. México, 1999.
   • Pressman, Roger S. "Ingeniería de Software. Un enfoque práctico." 5ta Edición (traducción de la edición original en Inglés "Software Engineering. A practical approach"), Editorial Mac Graw Hill, Madrid, España, 2001.
   • Shaw, M. y Garlan, D. "Software Architecture". Editorial Prentic-Hall, New York, E.U.A. 1996.
   • Sitio Wikipedia. "Modelo Vista Controlador (Tutorial)" http://es.wikipedia.org/wiki/Modelo_Vista_Controlador, 23 de marzo de 2006.
   • Stefan, Sauer; Engels, Gregor. "Extending UML for Modeling of Multimedia Applications". http://wwwcs.upb.de/cs/ag-engels/Papers/2003/EngelsSauerNeu-HCC03.pdf, 6 de abril de 2004.
   • Welicki, León. "Patrones y Antipatrones: una introducción – Parte II". http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/MTJ_3317.asp, 11 de abril de 2006.

    

    

    

   Autor:

   Ing. Febe Ángel Ciudad Ricardo

   Ciudad de La Habana, Abril de 2006

   "Año de la Revolución Energética en Cuba"

   DATOS DEL AUTOR:

   AUTOR PRINCIPAL: Ing. Febe Ángel Ciudad Ricardo

   Profesor Instructor de Ingeniería y Gestión de Software – UCI

   Jefe del Departamento de la Especialidad – Facultad 9

2. Hacer