1. UNIVERSIDAD CATÓLICA
“NUESTRA SEÑORA DE LA ASUNCIÓN”
Facultad de Ciencias y Tecnologías
Campus Itapuá - Sub Campus San Ignacio Guazú
Trabajo Práctico Grupal de:
Multimedia
Tema: Metodología RMM (Relationship Management Methodology).
Profesor: Ing. Hugo Santacruz.
Integrantes del Grupo:
 Natalia Ortiz
 Ángel Morinigo
 Rafael Echeverría
Carrera: Ingeniería Informática.
Curso: Quinto.
Año: 2014

2. Metodología RMM
Relationship Management Methodology
Historia
La Metodología de Gestión de Relaciones para el diseño hipermedia fue introducida por
primera vez en 1995, y desde entonces ha evolucionado en muchos aspectos para dar
respuesta al rápido incremento de la demanda de aplicaciones en el amplio mundo de la Web.
Diseño de sistemas de información basados en internet
La RMM proporciona una metodología de diseño estructurado para el desarrollo de muchos
tipos de aplicaciones hipermedia, facilitando su diseño, desarrollo y mantenimiento.
¿Qué es?
La RMM se define como un proceso de análisis, diseño y desarrollo de
aplicaciones hipermedia. Los elementos principales de este método son el modelo Entidad-
Relación y el modelo de gestión de datos. La metodología fue creada por Isakowitz, Stohr y
Balasubramanian. Esta metodología es apropiada para dominios con estructuras regulares (es
decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por
ejemplo, catálogos o "frentes" de bases de datos tradicionales. Según sus autores, está
orientada a problemas con datos dinámicos que cambian con mucha frecuencia, más que a
entornos estáticos
Los tres niveles de modelado de sistemas de información web
FIGURA 1: Los tres niveles de modelado de sistemas de información web.

3. 1. Nivel de presentación: se ocupa de cómo se presenta la información. En este nivel se
elige que información se agrupa
2. Nivel lógico: asocia la información almacenada en las bases de datos y los servidores
web como las páginas que el usuario ve en este momento.
3. Nivel de almacenamiento: describe cómo se organiza la información físicamente, en
términos de que aplicación es.
FIGURA 2: Contribución en términos de las tres capas de modelado WIS
Limitaciones de la RMM Original
La RMM original no daba respuestas a cuestiones más allá de la estructura básica de
navegación de una aplicación hipermedia. Quizá la más seria limitación fue la
incapacidad de RMM para modelizar los contenidos de páginas web complejas. Por
ejemplo, no era posible combinar información de entidades diferentes en una misma
pantalla. Otra importante limitación de RMM residía en que obligaba a un proceso de
desarrollo de software descendente. Esto no sólo supone una restricción al desarrollo
de software, sino que también desanima a reutilizar los diseños de bajo nivel.
• Contenidos pobres en las Rodajas(Limitación 1)
Cada página está compuesta de (a) una estructura de acceso (p.e., una agrupación,
índice o visita guiada), o (b) una página conteniendo elementos de información de
una única entidad. La imposibilidad de añadir, por ejemplo, el título del artículo y
los nombres de los autores en el índice "Artículos por Palabra Clave" ("Articles by
Keyword" ), (Figura 5-a), da como resultado una navegación incómoda.
• Pérdida del contexto durante la navegación(Limitación 2)
Como consecuencia del pobre contenido de las pantallas, llegamos a perder el
contexto de la navegación. Por ejemplo, el camino navegacional que un usuario se
ve obligado a seguir para alcanzar la una pantalla cualquiera, el cual en este punto
se ve desprovisto de contexto y por lo tanto confuso; el usuario seguramente habrá
olvidado por qué buscaba esta información.
• Diseño únicamente descendente(Limitación 3)

4. La tercera limitación de RMM que corregimos en este documente está relacionada
con su incapacidad de soportar el diseño ascendente. La RMM original no tenía
primitivas de modelización que nos permitieran construir una aplicación a partir de
sus componentes básicos. Por ejemplo, no podíamos decidir qué información
incluir en una página de referencias bibliográficas sin haber diseñado el diagrama
RMM por completo. La dificultad reside en la falta de primitivas de modelización
para diseñar pequeños elementos sin tener completado todo el diseño.
• Pérdida de la visión de conjunto(Limitación 4)
La cuarta limitación que hemos evitado está en relación con un defecto de la
extensión correspondiente a las Rodajas-M (M-Slices). Debido a la adopción de un
análisis ascendente, se pierde la capacidad de modelizar la aplicación WIS completa
en un único diagrama. Resulta ser una pérdida significativa, ya que nos arrastra de
nuevo hacia el diseño orientado a la página web. Una solución a este problema,
presentada por vez primera en [Isakowitz et al. 1997b], lleva aparejado un
algoritmo que recupera la visión global (de diseño descendente), a partir de la
aproximación ascendente. En el presente artículo refinamos esta contribución y la
integramos con el resto de extensiones a RMM.
Implementación
Una aplicación diseñada con RMM puede ser realizada con cualquier herramienta de
gestión de bases de datos o plataforma web. La naturaleza de la metodología hace que
sea independiente de las especificaciones de realización. Además, la aplicación
definitiva puede ser generada de dos formas: estáticamente o dinámicamente.
Estáticamente, las páginas HTML que abarcan la aplicación se pueden generar durante
un sencillo proceso encolado. Esto resulta más apropiado para sitios web cuyo
contenido apenas cambia. Dado que el sitio web JMIS sólo cambia sus contenidos cuatro
veces al año (con cada nueva publicación cuatrimestral), lo hemos generado de esta
manera, con un proceso semiautomático.
La actualización del sitio web es una tarea rápida y automática, con la única restricción
de la velocidad de procesamiento del ordenador utilizado para generar los informes
desde la base de datos.
Y mucho más importante, cualquier modificación o puesta al día de la estructura del
sitio se lleva a cabo fácilmente por medio del diseño RMM. Los añadidos o cambios del
sitio no son "parches", sino modificaciones estructuradas y eficientes.
El segundo camino para generar las páginas HTML de una aplicación diseñada con RMM
es de forma dinámica. Esto puede hacerse con un enlace dinámico entre la base de
datos y el servidor web, de manera que las páginas entregadas por el servidor sean
creadas en tiempo real de acuerdo con la petición especificada por el cliente.
Este mecanismo dinámico se puede emplear también para actualizar el contenido de la
base de datos, por medio del sitio web, utilizando para ello formularios HTML. Este tipo
de configuración resulta más adecuada para sitios web cuyo contenido cambie con
frecuencia y requiere un gestor de base de datos que soporte solicitaciones dinámicas
vía web.

5. Conclusión y Mejoras Futuras
En este trabajo, hemos proporcionado una amplia extensión a la metodología RMM
original concentrándonos en sus limitaciones más importantes. Una pregunta obvia en
este punto es ¿Representa esto el RMM definitivo? La respuesta es "probablemente no",
pues seguimos recibiendo comentarios y haciendo mejoras. Concretamente, RMM tal
como fue presentado aquí no controla la interacción del usuario, ni procesos
secundarios (p.e. búsqueda), ni contempla múltiples usuarios, ni aspectos de seguridad.
Semejantes transformaciones resultan primordiales para el soporte asistido por
computador del proceso de diseño RMM, y nos transportarán hacia el último área de
innovación: el desarrollo de una herramienta RM-CASE mejorada que contemple todas
las prestaciones descritas anteriormente.