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.