Utilización del Patrón Modelo ? Vista ? Controlador (MVC) en el diseño de software educativos

1. Resumen
3. El patrón de diseño de software Modelo – Vista – Controlador (MVC)
4. Una variación que acerca el patrón MVC a los software educativos cubanos
5. Valoración Económica y aporte Social
6. Conclusiones
7. Recomendaciones
8. Anexos
9. Referencias Bibliográficas

RESUMEN

Hoy día en cualquier lugar del mundo los que construyen aplicaciones informáticas centran su atención en dos aspectos fundamentales: (1) ¿cómo lograr construir mejores aplicaciones en menos tiempo? y (2) ¿cómo utilizar mayor cantidad de estándares en el diseño de las aplicaciones que soporte la primera interrogante planteada y permita mayor reutilización del código y mejores mantenimientos de los sistemas desarrollados? Los software educativos no están ajenos a esta problemática, incluso por su concepción, complejidad y variabilidad en el tiempo, se pudiera decir que son el tipo de aplicaciones informáticas que mayor necesidad tienen de darle respuesta a ambas preguntas planteadas.

"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]

Teniendo en cuenta el creciente uso de la P.O.O. en la concepción e implementación de este tipo de software y la gran actualidad que tiene el uso de patrones internacionalmente aceptados para estas funciones, proponemos en nuestro trabajo un análisis del patrón Modelo-Vista-Controlador (MVC) y su posible utilización en el diseño de software educativos en lo relacionado al trabajo con la información en este tipo de aplicaciones.

La administración o gestión de datos engloba dos áreas distintas de interés: (1) la administración (gestión) de datos críticos para la propia aplicación, y (2) la creación de infraestructura para el almacenamiento y recuperación de los objetos. En general, la administración de datos se diseña en forma de capas o en paquetes o subsistemas. La idea es aislar de forma lógica desde el análisis y luego en el diseño, los requisitos de bajo nivel que manipulan las estructuras de datos, de los requisitos de alto nivel para manejar los atributos del sistema en desarrollo.[PRE01]

Por las razones expuestas, dedicaremos este trabajo al planteamiento de un conjunto de modificaciones sobre la base de dicho patrón y lo estandarizado para el análisis y el diseño por el Lenguaje Unificado de Modelado (UML) que permita acercar al patrón MVC a las necesidades para este tipo de sistemas informáticos. Estas mismas concepciones y modificaciones presentadas, ya han sido utilizadas en el diseño e implementación de un producto de este tipo, así como de una plataforma para la construcción de aplicaciones multimedia educativas en la UCI.

INTRODUCCIÓN

El mercado del software de computadoras personales ha germinado en las pasadas dos décadas. El procesamiento de texto, la hoja de cálculo, los gráficos por computadoras, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones existentes en la actualidad.

En el mismo período de tiempo mencionado, han aparecido un conjunto de variantes de solución al diseño y a la arquitectura de las aplicaciones de todo tipo. No obstante la aplicación de dichas variantes a los software educativos se vuelve un poco compleja y en ocasiones no compatibles con las características de este tipo de aplicaciones.

En consecuencia es preocupante al mismo tiempo la estructura que adoptarán estos tipos de software. La estructura de información representa la organización interna de los elementos de datos o de control. ¿Hay que organizar los elementos de datos o de control como una tabla de dimensión n o como una estructura jerárquica en árbol? Dentro del contexto de la estructura ¿Qué información está relacionada con otra información? ¿Está contenida toda la información en una sola estructura o se van a utilizar varias? ¿Cómo se relaciona la información de una estructura con la de otra? Estas y otras preguntas se responden mediante una valoración de la estructura de la información.

Al mismo tiempo es menester el análisis de las características del diseño de las aplicaciones multimedia educativas desde el punto de vista de sus clases y la arquitectura "¿Qué tipo de visibilidad deberían tener otros paquetes respecto a la capa de presentación? ¿Cómo deberían comunicarse con las ventanas las clases no relacionadas con ellas? Por lo regular conviene que no haya un acoplamiento directo de otros componentes con los objetos ventana porque estás se encuentran relacionadas con una aplicación en particular, mientras que (en teoría) podemos reutilizar en nuevas aplicaciones los componentes sin acceso a ellas o unirlos a una nueva interfaz. El principio que se aplica en este caso es el patrón Separación Modelo- Vista." [PRE01]

Será razón de esta ponencia realizar un análisis de estos aspectos y la presentación de una variación a uno de los patrones de arquitectura más utilizados actualmente; sobre la base de las características del software educativo cubano.

EPÍGRAFE I: El patrón de diseño de software Modelo – Vista – Controlador (MVC).

La arquitectura del software alude a "la estructura global del software y a las formas en que la estructura proporciona la integridad conceptual de un sistema". En su forma más simple, la arquitectura es la estructura jerárquica de los componentes del programa (módulos), la manera en que los componentes interactúan y la estructura de datos que van a utilizar los componentes. Sin embargo, en un sentido más amplio, los "componentes" se pueden generalizar para presentar los elementos principales del sistema y sus interacciones. [PRE01]

"El diseño arquitectónico define la relación entre los elementos estructurales principales del software, los patrones de diseño que se pueden utilizar para lograr los requisitos que se han definido para el sistema, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de diseño arquitectónicos" [SHA96].

Los patrones expresan el esquema fundamental de organización para sistemas de software. Proveen un conjunto de subsistemas predefinidos; especifican sus responsabilidades e incluyen reglas y guías para organizar las relaciones entre ellos; así como ayudan a especificar la estructura fundamental de una aplicación.

El Model-View-Controller (Modelo-Vista-Controlador, en adelante MVC) fue introducido inicialmente en la comunidad de desarrolladores de Smalltalk-80. Según uno de los Sistemas de Patrones de Arquitectura más extendido en el mundo: Pattern Oriented Software Architecture, publicado por Buschmann en 1996, el patrón que se analiza en este trabajo (MVC), se sitúa en la tercera de las cuatro categorías en las cuales clasifica a los patrones: Del barro a la estructura (From mud to Structure), Sistemas Distribuidos (Distributed Systems), Sistemas Interactivos (Interactive Systems) y Sistemas Adaptables (Adaptable Systems). De igual forma si utilizamos otro de los sistemas más difundidos: Pattern of Enterprise Application Architecture, descrito recientemente por Fowler en el pasado 2003, lo ubica en la tercera de las siete categorías que se mencionan a continuación: Patrones de lógica del dominio (Domain Logia Patterns), Patrones de Mapeo a Bases de Datos Relacionales (Mapping to Relational Database Patterns), Patrones de Presentación Web (Web Presentation Patterns), Patrones de Distribución (Distribution Patterns), Patrones de Concurrencia Offline (Offline Concurrency Patterns), Patrones de Estado de Sesión (Session State Patterns) y Patrones Base (Base Patterns).

MVC divide una aplicación interactiva en 3 áreas: procesamiento, salida y entrada. Para esto, utiliza las siguientes abstracciones:

• Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada.
• Vista (View): Muestra la información al usuario. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador.
• Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio ("service requests") para el modelo o la vista.