Jean Pierre Charalambos,¹ José Andrés Martínez²

¹ Ingeniero industrial M. Sc. Universidad Nacional de Colombia- Bogotá. Profesor asistente. e-mail: jpcharalambosh@unal.edu.co
² Ingeniero de sistemas. Universidad Nacional de Colombia. e-mail: jose.andres@e-rainteractive.net

RESUMEN

El presente artículo expone una metodología para el diseño de sitios y aplicaciones web que permitan, a los entes informáticos para los cuales se desarrollan, publicar la información que generen en tiempo real y como consecuencia natural de su trabajo. La metodología que a continuación se presenta integra los conceptos del Lluvia de ideas y los Mapas Mentales, definiendo un esquema para la recopilación de información absolutamente natural tanto para el ente informático que se entrevista como para el entrevistador mismo. Asimismo la metodología desarrollada alcanza de forma natural las tres primeras formas normales expuestas en la teoría de bases de datos relacionales, con lo cual se convierte en una valiosa herramienta para cualquier desarrollador de aplicaciones web.

Palabras clave: diseño de bases de datos, web, metodologías de diseño

ABSTRACT

This paper presents a novel website design methodology. The methodology is suitable for developing medium-sized websites and web applications as it is inspired by brainstorming and using mind maps. The proposed approach employs two well-defined roles: the interviewer and interviewee. The former could be identified with a web designer whilst the latter is more related to someone handling informatics. Practical experience has shown that a series of brainstorming sessions naturally leads to the system underlying the data-base structure.

Keywords: database design, web, design methodology, scripting languages.

Recibido: noviembre 13 de 2003
Aceptado: junio 27 de 2005

Introducción

El presente artículo expone una propuesta metodológica para el desarrollo de sitios web que tengan como fin presentar la información relacionada con algún tipo de ente informático. A lo largo de este artículo se denotará por ente informático cualquier individuo o grupo de individuos que genere información de forma natural y como consecuencia de su trabajo. Ejemplos de entes informáticos claramente identificables los constituyen un profesor universitario, un grupo de profesores y estudiantes agrupados bajo una misma facultad o un conjunto de facultades agrupadas bajo una universidad. Cada uno de ellos: el profesor, la facultad y la universidad, son entes informáticos que generan información de forma natural y como consecuencia de su propia existencia.

La gran mayoría de los entes informáticos cuentan en al actualidad con un sitio en internet. Dicho sitio se convierte en un canal de comunicación de una sola vía con sus clientes, visitantes, alumnos, o como sea que se denominen los consumidores de la información que dicho ente genera. Gracias a que la mayoría de diseños se centran en aspectos como la imagen corporativa, el nivel de atracción visual ofrecida al navegante y la presentación de componentes interactivos, se ha relegado a un segundo plano el aspecto más importante de todos: la naturaleza misma de la información generada por el ente informático. De este modo se tienen dos problemas fundamentales:

1. La información presentada no corresponde con la realidad temporal del ente que la genera.

2. La preparación y posterior publicación de esta información constituye una carga de trabajo adicional para el ente.

Un proceso adecuado para diseñar un sitio en internet debe estar fuertemente ligado al ente informático que se encuentra detrás del sitio web. El proceso metodológico que se describe a continuación plantea una propuesta metodológica para llevarlo a cabo.

Metodología Propuesta

Múltiples metodologías para la elaboración de aplicaciones se han desarrollado a lo largo de los últimos años, el principal objetivo que persiguen es el de lograr que los usuarios finales puedan realizar su trabajo de la mejor manera. Como ejemplos de ellas vale la pena mencionar LUCID, que representa una estrategia metodológica en el cual las interfaces de una aplicación se construyen por completo alrededor de la interacción del usuario final con la aplicación (Cognetics Corporation, 2002, on line), ó PD, que corresponde a una propuesta metodológica en la cual la participación del usuario final en el diseño es un elemento central (Cline, on-line). Asimismo, se han desarrollado diferentes metodologías para asegurar que la lógica de la aplicación funcione de la mejor manera y presente la información solicitada de forma eficiente. Sin embargo, a partir de ninguna de ellas es posible identificar, simultáneamente, tanto las entidades que de forma natural formarán parte integral del sistema generador de la información, como la información generada por ellas y que ha de integrarse de manera natural al sistema propuesto.

GAC

GAC, acrónimo de Gestión Autónoma de Contenido, es una propuesta metodológica que ha sido concebida para el desarrollo de sitios web que integren completamente a los entes generadores de información y a los procesos que ocurren entre ellos. Los sitios web desarrollados a partir de GAC presentan la información generada por los entes en el mismo instante en que ésta se produce, como consecuencia natural del trabajo del ente y no como una carga de trabajo adicional a éste.

El punto de partida para llegar a GAC lo constituye el conocido ejercicio de las sesiones de lluvias de ideas (Wikipedia, on line), mediante el cual un grupo de individuos dejan fluir libremente todas las ideas que respecto a un tema en particular se les ocurren. La diferencia entre las sesiones de Lluvia de ideas clásicas y las que se desarrollan en GAC, es que en estas últimas, las ideas expresadas tienen como fin identificar las entidades que se encargarán de la generación de información en el sistema que será implementado. De hecho, en GAC se tienen dos clases de sesiones de lluvias de ideas, una primera en la que se identifican las entidades generadoras de información y los atributos que las caracterizan; y una segunda, en la cual se determinan los procesos que ocurren al interior del sistema y que tienen como consecuencia natural la generación de información.

Mientras en las sesiones de Lluvia de ideas tradicionales uno de los participante se encarga de dirigir la sesión e ir tomando apuntes de las ideas expresadas (Wikipedia, on line), en GAC se establecen dos roles muy claros dentro de la sesión: el rol del entrevistado, que corresponderá al ente informático para el cual será desarrollado e implementado el sistema; y el rol del entrevistador, que debe ser asumido por uno de los miembros del equipo de desarrollo. Este debe contar únicamente con las capacidades adecuadas para sostener de forma fluida una sesión de este tipo (no necesariamente debe corresponder a un desarrollador de software). El entrevistador en GAC no irá tomando apuntes de la forma en que tradicionalmente se ha hecho. En vez de ello, empleará un sistema gráfico para la representación de esta información, por completo inspirado en la teoría de los Mapas Mentales y el Pensamiento Irradiante, (Buzan, 1996; Buzan, 2002, on line). Los dibujos que el entrevistador deberá realizar corresponden a los resultados de la primera clase de sesiones de Lluvia de Ideas mencionada anteriormente. La forma en que estos dibujos se realizan es la siguiente:

1. En el centro de una hoja de papel se dibuja un círculo que encierre la palabra clave que mejor sirva para describir el sistema.

2. Por cada una de las entidades generadoras de información identificadas por el entrevistado durante las sesiones de lluvias de ideas, se dibuja una rama partiendo del nodo central, que llevará en la parte superior el nombre de la entidad identificada. Es muy importante aclarar que cada entidad debe nombrarse en singular, por ejemplo “alumno” en lugar de “alumnos”. Si en algún momento una entidad no pudiese ser nombrada en singular, debe procederse a su descomposición.

Una vez identificadas todas las entidades, se da inicio a una nueva sesión de Lluvia de Ideas, en la cual se procederá a identificar cada uno de los atributos de las entidades identificadas anteriormente. Los resultados de esta sesión modifican el dibujo inicial de la siguiente forma:

1. Por cada entidad que se caracteriza debe cambiarse la rama en la que se encuentra por un nodo en cuyo centro estará escrito su nombre. Este nuevo nodo estará conectado por medio de una rama con el nodo central del sistema, esta rama no llevará ningún tipo de nombre o indicación sobre ella.

2. Cada uno de los atributos que se identifique debe dibujarse en una rama que partirá del nodo que representa la entidad que se está caracterizando. Al igual que en el paso previo, los atributos deben ser nombrados siempre en singular, si en algún momento resulta imposible para el entrevistado hacerlo, el atributo en cuestión debe descomponerse.

Aplicación práctica de GAC

GAC: aplicación al desarrollo de un sistema de encuestas real

Objetivo: Se busca desarrollar un aplicativo web que presente al navegante de un portal una ventana emergente con un listado de “n” preguntas. Sobre esta ventana el navegante ingresará las respuestas a las preguntas y cuando haya finalizado presionará un botón para enviarlo. El cuestionario diligenciado será enviado a una dirección de correo, incluyendo en la información que se envía los datos del usuario que lo diligenció con el ánimo de saber quién contesta la encuesta. La información quedará guardada en la base de datos del portal.

Funcionalidad de usuario:

1. Llenar el cuestionario

2. Enviar el cuestionario

3. Consultar las encuestas y los resultados de la misma a través del sistema de administración del portal

Funcionalidad del administrador:

1. Definir el formulario que debe aparecer en el pop up. Los formularios podrán tener entre 1 y 15 preguntas, cada pregunta tendrá entre 1 y 10 opciones de respuesta

2. Definir el tiempo de vida para el formulario creado (esto es, el rango de fechas entre el cual debe aparecer cuando un usuario registrado ingrese al portal)

3. Definir la dirección de correo a la cual debe ser enviado el formulario

4. Consultar las encuestas y los resultados de la misma a través del sistema de administración del portal.

Análisis Preliminar: En este sistema de encuestas las entidades generadora de información son los propios componentes de cada encuesta, así como el usuario que la diligencia. Lo anterior se afirma con base al hecho de que las respuestas dadas por el usuario a las preguntas presentadas en el portal, deben almacenarse en una base de datos para posteriormente presentar sus resultados tabulados. De acuerdo con esta afirmación el mapa mental preliminar de este sistema corresponde al ilustrado por la imagen de la Figura 1.

A continuación se identifican cada uno de los atributos (relevantes para el sistema) que caracterizan las entidades generadoras de información. Las ramas en las que se encontraban las entidades se remplazan por nuevos nodos y a partir de estos se dibujan las ramas sobre las cuales se ubicarán cada uno de los atributos identificados. El nuevo dibujo luce según lo mostrado en la Figura 2.

Obsérvese como de forma natural las entidades determinadas se relacionan unas con otras. Por ejemplo una pregunta debe estar asociada a un único formulario, igualmente una respuesta debe asociarse a una y sólo una pregunta.

En este punto del proceso ya se cuenta con la representación gráfica de las entidades generadoras de información del sistema. Dos aspectos deben resaltarse debido a su importancia. El primero de ellos es que esta representación corresponde de manera muy cercana al diseño de la base de datos subyacente que soportará esta aplicación. La segunda es que dicho diseño cuenta ya con las tres primeras formas normales expuestas en la teoría formal de bases de datos relacionales (Mata-Toledo, 2000), a saber:

1. Todas las ocurrencias de tipo registro deben contener el mismo número de campos. La primera forma normal excluye campos repetidos y grupos.

2. Un campo no clave no puede contener un valor de un subconjunto del campo de l clave. Es solo relevante cuando el campo clave es compuesto por varios campos.

3. Un campo no clave no puede contener un valor que se encuentra contenido en otro campo no clave.

En la Figura 3 los atributos que se encuentran en negrita corresponden a la llave primaria de la tabla y los atributos en otro color corresponden a la llave foránea de la entidad del mismo color.

Formas normales obtenidas con GAC

Como puede apreciarse en la Figura 3, ninguna de las instancias de las entidades definidas (registros de las tablas de acuerdo con la notación tradicional de bases de datos relacionales (Mata-Toledo, 2000) podría contener un número de campos diferente al de otra. Por ejemplo, no podría existir una respuesta con dos preguntas asociadas, puesto que se trata de un campo para el que solamente es posible definir un valor. Como tampoco podría existir una pregunta asociada a dos formularios diferentes. La forma en que se han caracterizado las entidades garantizará la primera forma normal.

Aunque cada una de las entidades cuenta con un campo especial, definido con el fin de ser empleado como llave primaria, las entidades “pregunta” y “respuesta” podrían manejar una llave compuesta. Por ejemplo, “pregunta” podría tener por llave la combinación: (id. Pregunta, id. Formulario). Es claro que en el campo “texto” de esta entidad no se almacenaría el valor del id. De la pregunta o del id. Del formulario, garantizando así el cumplimiento de la segunda forma normal.

En cada una de las entidades es posible verificar que ninguno de los atributos contendrá un valor correspondiente a otro atributo. Por ejemplo, el campo email_destino de la entidad formulario no podrá contener el id. Del formulario, o la fecha de inicio o finalización del mismo. No existe ningún tipo de ambigüedad a la hora de llenar los campos de un registro, cada campo ha sido determinado y etiquetado para caracterizar de forma específica la entidad en cuestión.

Identificación de los procesos generadores de información

Una vez se ha conseguido la representación gráfica de las entidades generadoras de información, una nueva serie de sesiones de Lluvia de Ideas debe comenzar. En esta nueva etapa se determinarán los procesos que ocurren de forma natural al interior del sistema y que tienen como consecuencia la generación de información.

Procesos que ocurren de forma natural dentro del sistema:

1. El administrador crea un nuevo formulario.

2. El administrador define la fecha de inicio para el formulario. Esto es, la fecha en que comenzará a aparecer en el portal.

3. El administrador define la fecha de finalización para el formulario. Esto es, la fecha en que dejará de aparecer en el portal (sin que esto implique su eliminación de la base de datos subyacente).

4. El administrador define el correo electrónico al que serán enviados automáticamente los formularios cada vez que se diligencien.

5. El administrador crea una nueva pregunta para un formulario existente.

6. El administrador define el texto de la pregunta que está creando.

7. El administrador crea una nueva respuesta para una pregunta existente.

8. El administrador define el texto de la respuesta que está creando.

9. El usuario del portal diligencia un formulario y lo envía. Entonces, automáticamente se genera un correo electrónico a la dirección que lleva adjunto el id. Del usuario (especificada por el administrador del sistema en el proceso 4 definido anteriormente). Finalmente, la información introducida mediante el formulario es almacenada en la base de datos.

10. El Usuario o el Administrador del sistema desea conocer los resultados del formulario activo o de un formulario anterior.

El proceso 10 descrito arriba, hace caer en cuenta a los participantes en la reunión de lluvia de ideas, que han olvidado un atributo importante en la entidad “respuesta”: puntaje. Incluir este atributo hará posible saber cuantas veces ha sido escogida una respuesta dada y de esta forma tabular y presentar los resultados obtenidos mediante el diligenciamiento de los formularios. El diagrama ajustado se presenta en la Figura 4.

Notas importantes:

1. En la implementación final no se creo una nueva tabla usuario, en lugar de ello se empleó la misma tabla de usuario que provee el portal.

2. Al realizar la implementación de la forma en que lo ilustra la Figura 4 (haciendo la salvedad anterior) cada formulario podrá tener n preguntas con n opciones de respuesta cada una.

Al finalizar el proceso metodológico GAC, se tendrá:

1. La base de datos que soportará la aplicación normalizada.

2. Las funciones requeridas por el administrador del sistema.

3. Las funciones requeridas por los usuarios regulares del sistema.

A partir de este punto el equipo de desarrollo puede emplear cualquiera de las metodologías de implementación existentes y realizar de forma exitosa la implementación del sistema. Lo que GAC garantiza es que en el sistema implementado la generación de la información no será una carga de trabajo adicional para el ente informático y que además la información generada corresponderá con la realidad temporal de este último.

Conclusiones

La metodología ha sido puesta en práctica con éxito en la implementación de varios sistemas. En el ámbito académico GAC se empleó para desarrollar Postgrade³. Postgrade es una herramienta para la consulta y evaluación académica que integra a docentes y estudiantes en la web. GAC ha sido también empleada en el ámbito empresarial durante más de un año para el desarrollo de varios sistemas⁴.

El principal atractivo de la metodología de diseño propuesta es la de constituirse en un proceso natural respecto de las capacidades cognitivas de los seres humanos. El concepto de las sesiones de lluvias de ideas y su visualización mediante mapas mentales aplicado al diseño de bases de datos, es por mucho un proceso más fácil de asimilar para la mente que los esquemas empleados para el mismo fin del modelo entidad relación.

La experiencia con los entes informáticos con los que se ha trabajado, ha demostrado que para cualquiera de ellos resulta natural la identificación de entidades generadoras de información, su posterior caracterización y su representación gráfica utilizando el sistema de pensamiento irradiante.

Bibliografía

Buzan, T., The mind map book., Plume, 1996.        [ Links ]

Buzan, T., The human brain and the global brain., Buzan Centers, 2000.        [ Links ]

Cline, A., JAD for Requirements Collection and Management., http://www.carolla.com/wp-jad.htm.        [ Links ]

Cognetics Corporation, The LUCID Framework. 1998 – 2003., Consultado por primera vez en junio de 2002. http://www.cognetics.com/lucid.        [ Links ]

Mata-Toledo, R. y Cushman, P.K., Fundamentals of Relational Databases., Primera Edición, McGraw Hill, 2000.        [ Links ]

Wikipedia, Brainstorming definition., http://en.wikipedia.org/wiki/Brainstorming.        [ Links ]

3 Grupo de Investigación en computación gráfica y procesamiento de imágenes, OHWAHA. Universidad Nacional de Colombia, 2003
4 José Andrés Martínez, coautor de este artículo, trabaja actualmente como gerente de investigación y desarrollo en una compañía web, la cual ha adoptado GAC como metodología estándar para el inicio de sus desarrollos.