1. JUGLAR, UNA HERRAMIENTA GNU DE AUTORÍA
José Enrique Alvarez Estrada
Director de Nuevas Tecnologías
Fundación Arturo Rosenblueth
email: jalvarez@mail.rosenblueth.mx
ICQ: 31463788
RESUMEN
Ante la escasez de herramientas de autoría dcsarrolladas bajo Licencia Pública General GNU
(GPL), este trabajo aborda la creación de Juglar, un software de integración de multimedios que
trabaja en plataformas Windows y Linux, totalmente compatible con el Storyboard de IBM.
Juglar ha sido desarrollado completamente bajo el paradigma orientado a objetos, a través de una
metodología híbrida, que toma de Coad/Yourdon el enfoque de división del problema en
componentes (interacción humana, dominio del problema, administración de datos y
administración de tareas) y de OMT la etapa de análisis basada en los modelos del objeto,
dinámico y funcional. El desarrollo se aborda a través de un ciclo de vida incremental o de
entrega por etapas, donde cada etapa agrega funcionalidad a lo hecho en la etapa anterior. La
construcción del producto se lleva a cabo usando Object Pascal (Delphi y FPK) como lenguaje.
Durante la primera etapa se determina la funcionalidad operativa de los diferentes módulos de
Storyboard, eliminando aquellos que no deben desarrollarse bajo GUI. Después se decodifica el
formato de los principales archivos de la herramienta por medio de ingeniería inversa.
Posteriormente, se desarrolla el proyecto de software como tal. Para el desarrollo de la interfaz
bajo ambiente Linux se crea la Juglar Component Library (JCL), un encapsulamiento en clases
Object Pascal de la funcionalidad de los widgets de GTK+.
PALABRAS CLAVE
GNU is Not Unix (GNU), Licencia Pública General GNU (GPL), Autoría (Authoring),
Multimedia, MicroSEP, Graphical User Interface (GUI), Ingeniería Inversa, StoryBoard, Linux,
XWindow, Ciclo de Vida, Metodología, Entrega por Etapas, Coad/Yourdon, OMT, Rumbaugh,
Object Pascal, Delphi, Free Pascal (FPK), Formato PIC, Formato SH, Formato GRA, Formato
SPR, Compresión de Archivos, Run-Length Encoding (RLE), Visual Component Library (VCL),
Gimp Took Kit (GTK+), Widgets.
reconocimiento de la propiedad intelectual de
INTRODUCCIÓN la obra. La licencia GNU ha sido
La Free Software Foundation (FSF) ha extremadamente exitosa, y ya existen miles
creado un esquema de licenciamiento de programas que cumplen con ella, y que se
llamado GNU (GNU is Not Unix) [FSF00], ejecutan en innumerables plataformas y
que compromete a los programadores a sistemas operativos diferentes.
entregar el código fuente de su producto en Pero a pesar de la enorme cantidad de
cualquier distribución que hagan de él, o bien desarrolladores comprometidos con este
publicarlo en un site de Internet accesible a concepto de licenciamiento, aún existen
los usuarios. GNU es una licencia recursiva, campos en los cuales resulta difícil –si no
bajo la cuál todos los derechos que tiene el imposible– encontrar aplicaciones, tal como
distribuidor del software se transfieren los llamados softwares de autoría
recursivamente a los usuarios; el autor (authoring), dedicados a la creación de
conserva para sí únicamente el multimedia: presentaciones que combinan

2. diferentes medios, tales como audio embargo, se pretende dotar a Juglar de
digitalizado, música MIDI, gráficos y características más avanzadas que las
animaciones, con un elemento clave, que es soportadas por el producto original: entre
la capacidad de interacción o interactividad éstas destacan la capacidad de presentar
con el usuario [Burger92]. archivos vectorizados –además de bitmaps–,
La compañía IBM creó, hace ya más de 10 ampliar sus comandos para incluir
años, un producto de autoría denominado despliegues HTML y VRML, dotarlo de un
Storyboard, que se ejecutaba en sistemas intérprete interconstruido basado en objetos
DOS, y que sufrió durante su vida (llamado Mester) que pueda manejar eventos,
progresivas modificaciones y mejoras. En la dar soporte a mayor cantidad de formatos de
actualidad parece haber entrado en su ciclo de audio, etc. Por tanto, la funcionalidad de
muerte, porque IBM no lo ha portado a Storyboard será un subconjunto de la
ningún otro sistema operativo, incluyendo su funcionalidad de Juglar.
propio OS/2. Storyboard presentaba una
relación muy bien equilibrada de costo, PLAFINICACIÓN
prestaciones, características y necesidades de DEL PROYECTO
hardware, que lo hizo muy popular en la Como todo proyecto de ingeniería de
comunidad de usuarios de PC en todo el software, Juglar requirió de una cuidadosa
mundo. En México, su uso estaba muy planificación para su desarrollo. Se tomaron
difundido, y aun quedan muchas aplicaciones en cuenta tres elementos: el ciclo de vida a
multimedia creadas con él. Baste señalar, a utilizar, la metodología y el lenguaje.
modo de ejemplo, que la Secretaría de Después de un cuidadoso estudio y
Educación Pública desarrolló presentaciones evaluación de los ciclos de vida existentes
Storyboard como apoyo a su programa [McCon97] y [Press98], se optó por el
MicroSEP. modelo incremental o de entrega por etapas,
El objetivo central de este trabajo, es que se muestra en la Ilustración 1: una
presentar la creación de un software GNU de primera etapa fue la construcción de un
autoría, totalmente operable bajo GUI producto esencial o núcleo de funcionalidad
(Microsoft Windows y X-Window). El nuevo mínima (prototipo delimitado en
producto, denominado Juglar, utiliza como funcionalidad), que demostrara la factibilidad
prototipo al programa Storyboard de IBM: la técnica de crear un producto de desarrollo
idea es que Juglar sea compatible a nivel de multimedia totalmente compatible con
archivos con éste, de modo que se pueda Storyboard. En una segunda etapa, se están
aprovechar la multimedia ya desarrollada. Sin añadiendo algunas características que por
Ilustración 1.- Modelo de ciclo de vida de Entrega por Etapas.

3. cuestiones de tiempo no se pudieron modelo funcional) resultó idónea para el
desarrollar durante la primera, pero que ya proyecto [Rum96].
han quedado firmemente planteadas; es decir, Una vez determinados el ciclo de vida y la
se terminará la elaboración de las metodología a seguirse, sólo restaba elegir el
características básicas del producto que se lenguaje de programación con el que se
desea obtener. Y en una tercera etapa, instrumentaría el software. Dado que la
probablemente mucho más larga y con potencia de todos los lenguajes actuales es
participación de otros desarrolladores prácticamente igual –no hay cosas que se
(posterior al primer release), se añadirán puedan hacer en uno, y en otros no–, la
nuevas características de valor agregado que decisión acerca de cuál usar fue más de
el producto original de IBM no posee, y que índole personal que técnica, y se basó en la
permitirán a Juglar desempeñarse a niveles predilección del autor por el lenguaje Pascal;
profesionales de desarrollo de multimedios. de hecho, uno de los objetivos que perseguía
Por otra parte, se eligió el paradigma la investigación era comprobar su eficacia
orientado a objetos para la creación de como lenguaje de desarrollo en proyectos de
Juglar, dada la facilidad con la que se puede gran envergadura. Se eligió FPK (Free
mapear el dominio del problema al dominio Pascal) como el compilador para su
del software, así como sus conocidas ventajas desarrollo en ambiente Linux [Cann00], y
de encapsulamiento, reutilización de código Borland Delphi para ambiente Windows
por medio de la herencia, comunicación entre [Borl95].
las partes del sistema por medio de despacho Cabe señalar que Free Pascal es altamente
de mensajes y soporte polimórfico. compatible con el modelo de programación
La metodología empleada fue un híbrido de orientada a objetos de Delphi, lo cual hace
Coad/Yourdon y OMT. Para proyectos de que el código de todas las componentes –con
software que incluyen mucha interfaz con el excepción de la componente de interacción
usuario y mucho acceso a información en humana– resulte altamente portable entre
disco –como es el caso de Juglar– ambos.
Coad/Yourdon es una buena opción, ya que
ataca el problema desde cuatro áreas RECOLECCIÓN DE
principales: REQUERIMIENTOS
Diseño de la Componente de Dominio del Para lograr compatibilidad funcional de
Problema. Juglar con Storyboard, fue necesario estudiar
Diseño de la Componente de Interacción las principales características operativas de
Humana. éste, con el objeto de recabar información
Diseño de la Componente de que pudiera servir posteriormente para el
Administración de Tareas. análisis y el diseño de Juglar, puesto que se
Diseño de la Componente de utilizó el producto de IBM como un prototipo
Administración de Datos. operativo [Press88].
Pero a pesar de que Coad/Yourdon es La mecánica seguida fue sencilla: se
arquitectónicamente elegante, es pobre en la recorrieron una por una todas las ventanas
forma de abordar el diseño de las que integran la interfaz de Storyboard,
componentes de dominio del problema y de documentando cuidadosamente las opciones
administración de datos. Por ello, se optó por que cada una presenta, tales como menúes,
utilizar OMT (Object Modeling Technique) cuadros de diálogo, etc.
para atacar esas partes. Su propuesta de Así, se analizaron los diferentes módulos que
dividir la etapa de análisis en tres modelos integran Storyboard: menú inicial (sbmenu),
(modelo del objeto, modelo dinámico y Electronic Presentation, Picture Maker
(incluyendo su Editor de Gráficas, su Librería

4. archivos .PIC, pero no hace lo mismo con
0
0D
0
TIME Y WAIT
COMENTARIO
DEL COMANDO los archivos .SH (la historia), .SPR (los
>0
... >0
... sprites) y .GRA (los gráficos). Así que fue
Ruta de Acceso
(STRING)
NOMBRE.EXT Nota: Vale 0Ch si lo construye
necesaria la aplicación de técnicas de
(STRING) Presentation Manager, y 0Dh si lo
Longitud del PATH Longitud del Nombre
construye Story Editor.
Story Editor añade un signo '-' detrás
ingeniería inversa (reverse engineering), que
del nombre del archivo.
(en bytes) de archivo (en bytes)
no son otra cosa que el proceso mediante el
cual una entidad es desarmada y sus
Xo Yo Xf Yf Xo Yo
componentes estudiados para averiguar su
FROM PICTURE TO SCREEN
funcionamiento.
El método que se siguió para realizarla fue
DIR
01.- IN-H / RIGHT LINE COLOR relativamente sencillo: se creó un archivo
02.- OUT-H / LEFT 63.- No Line
03.- IN-V / UP
04.- OUT-V / DOWN
usando el módulo de Storyboard
METHOD
00.- None 07.- Stripes
AREA
01.- Full
02.- Part
correspondiente, se almacenó dicho archivo
01.- Crush
02.- Explode
03.- Fade
08.- Weave
09.- Checker
0A.- Diagonal
03.- Transparent Full
04.- Transparent Part en disco y después, utilizando un
04.- Push
05.- Replace
0B.- Blend
0C.- Instant
desensamblador (el debug de DOS), se
06.- Split
abrió y se tomó nota del estado en que se
encontraban sus bytes. A partir de este punto,
Ilustración 3.- Diagrama de sintaxis de los
se realizaron cambios en los comandos y
comandos Show y Display en un archivo .SH. opciones que el programa presentaba,
de Dibujos y su Editor de Fuentes), Picture guardando nuevamente el archivo y
Taker, Story Editor (incluyendo sus opciones desensamblándolo para observar los cambios
Record Audio, Sprite Editor y Video Editor), sufridos, deduciendo así qué byte o
Story Teller y la configuración (Setup). Para combinación de bytes se corresponden con
cada uno, se realizó un análisis concienzudo, cada función o parámetro en el programa.
a la luz de las siguientes premisas: Una vez lograda la decodificación de la
¡
No todos debían ser recreados en Juglar, estructura de los archivos, fue necesario
dado que algunos fueron desarrollados documentarlos, para facilitar la programación
inicialmente por IBM para suplir posterior de los filtros de importación y
deficiencias del sistema operativo DOS exportación. Con este fin, se recurrió a los
(tal es el caso del Editor de Fuentes y de diagramas de sintaxis, una técnica muy
Setup). popular en la definición de lenguajes de
¡
Algunos de sus módulos fácilmente programación y que, con pequeños cambios,
pueden ser reemplazados por resultó idónea para representar la estructura
herramientas ya existentes en los nuevos de los archivos, tal como se aprecia en la
sistemas operativos (tal es el caso de Ilustración 3, que representa la sintaxis de los
Record Audio, de Video Editor y de comandos Show y Display de Storyboard, tal
Picture Taker). como aparecen en los archivos .SH.
¡
Muchas de las opciones de interfaz de Con el objeto de abundar más en el
Storyboard no cumplen con los principios
básicos de desarrollo de GUIs señalados RENGLÓN DE PIXELES
por el CUA (Common User Access) de Checksum
IBM y por The Graphical User Interface Se repite tantas veces
como renglones indique
el encabezado del sprite
Guide de Microsoft [Chamo97]. Cada frame se rellena con tantos bytes
como sea necesario, hasta el múltiplo de
Para lograr una compatibilidad total con 16 más próximo. Para calcular el
número de bytes faltantes, se toman en
cuenta tanto los bytes de checksum
Storyboard, fue necesario que Juglar pudiera como los que forman los renglones.
leer y escribir archivos en los mismos
formatos que aquél lo hace. IBM documenta Ilustración 2.- Estructura de los frames de un
en su manual [IBM89] el formato de los archivo .SPR.

5. ser la de dificultar el proceso de ingeniería en
reversa –no es probable que se haya
ENCABEZADO ... FRAME
reservado con algún fin, puesto que el tamaño
RELLENO en sí mismo es variable.
La información gráfica de cada frame se
Ilustración 4.- Estructura general de un almacena, para todas las resoluciones,
archivo .SPR. renglón por renglón, tal como puede
apreciarse en la Ilustración 2. Cada renglón
procedimiento de ingeniería inversa, se contiene los valores de los pixeles de
presenta a continuación el resultado obtenido izquierda a derecha. Al inicio de cada frame
para los sprites, una de las características más está un valor tipo word, en formato little-
destacadas de Storyboard, ya que permite endian, que parece ser un checksum calculado
insertar animaciones móviles en las en base a la información del propio frame; sin
presentaciones, almacenadas en archivos embargo, no se ha podido determinar todavía
.SPR. El formato interno de estos archivos la función matemática que lo genera.
está totalmente indocumentado, ya que IBM IBM rellena cada frame con tantos bytes
no lo ha dado a conocer, ni parece que como sea necesario, hasta alcanzar el
terceros hayan publicado información al múltiplo de 16 superior más próximo –es
respecto en Internet o en fuente bibliográfica decir, que los frames siempre son módulo 16.
alguna. El valor de relleno no es importante, y de
Con la experiencia obtenida durante la hecho parece elegirse al azar. En el cálculo de
ingeniería inversa de los formatos anteriores, los bytes faltantes se toman en cuenta tanto
y basándose en el conocimiento del formato los bytes que almacenan la suma de
.PIC, se infirió que el archivo debía poseer verificación, como todos los bytes que
un encabezado que almacenara la integran los renglones de pixeles.
información genérica para todo el sprite, y un Probablemente esto tenga que ver con
cuerpo con la información gráfica para cada cuestiones de optimización en los accesos a
uno de sus cuadros o frames, tal como lo disco para lectura y escritura, donde se leen
muestra la Ilustración 4. bloques de 16 bytes en una sola operación.
Un problema interesante que surgió en este Cada renglón de pixeles comienza con un
punto, fue la ubicación cambiante entre byte que actúa como centinela, tal como se
archivos del primer byte de información del muestra en la Ilustración 5: si su valor es
primer frame de cada sprite. Este cambio de cero, significa que esa línea comienza con
posición se debe a un relleno de tamaño pixeles que tienen un color diferente del
variable, que no contiene información útil, transparente, y simplemente se ignora. Pero si
sino valores aparentemente calculados de es superior a cero (e inferior a FAh, el valor
forma aleatoria, y cuya única utilidad parece máximo permitido) significa que el centinela
Nùmero de bytes de
representa el número de pixeles transparentes
color que siguen
FF
al inicio de dicha línea, comprimidos
N
mediante RLE (Run-Length Encoding).
M
N veces
Nùmero de pixeles
Cuando se presenta esta compresión, hay que
transparentes (se debe
multiplicar por dos para
tomar en cuenta que el valor del centinela
Centinela:
Su valor máximo puede ser FAh (250d)
los modos $85 y $87
representa sólo la mitad del número de
Si Centinela = 0, entonces se ignora
Si Centinela > 0, indica el nùmero de pixeles
Byte de color
Nibble alto : Número de pixeles de
pixeles transparentes en los modos 85h
transparentes al inicio de cada renglón (se
debe multiplicar por dos para los modos $85 y
$87)
color consecutivos menos uno (se debe
multiplicar por dos para los modos $85
(640x350x16) y 86h (640x480x16), mientras
y $87
Nibble bajo: Valor de color que en el modo 87h (640x200x16) indica el
número total de pixeles transparentes.
Ilustración 5.- Formato de los renglones de los
El siguiente byte puede valer FFh (la marca
frames en los archivos SPR.
de fin de renglón), en cuyo caso significa que

6. todos los bytes de ese renglón son facilitó grandemente la construcción de la
transparentes, o un valor N (diferente de componente de interacción humana.
FFh), en cuyo caso indica el número N de Sin embargo, no existe VCL para Linux
bytes consecutivos que almacenan valores de (aunque Borland ya trabaja actualmente en
color. Si se presenta este último caso, el una, que acompañará a su herramienta
nibble más alto de cada uno de los bytes Kylix), por lo cuál fue necesario elegir una
representa el número de pixeles consecutivos base de componentes visuales diferente.
(menos uno, porque se empieza a contar Se decidió usar Gimp Tool Kit (GTK+) como
desde cero) del color determinado por el la librería de widgets para el proyecto. GTK+
nibble más bajo. Al igual que pasa con el fue originalmente desarrollada como una caja
centinela, si se está trabajando en los modos de herramientas para GIMP (General Image
85h y 86h el valor del nibble alto es sólo la Manipulation Program), y fue construido
mitad del número real de pixeles, mientras sobre GDK (GIMP Drawing Kit), que es
que en el modo 87h es el número total de básicamente una envoltura de las funciones
pixeles codificados. de Xlib. Esencialmente GTK+ es una API
De nuevo, si el siguiente byte vale FFh, esto pseudo orientada a objetos, que a pesar de
significa que aquí acaba el renglón, pero si su haber sido escrita completamente en lenguaje
valor es distinto, indica el número de pixeles C, se diseñó usando la idea de clases y
transparentes que siguen (multiplicándose por callback functions (apuntadores a funciones).
dos para los modos 85h y 86h y tomándose Existe, además de GTK+ y GDK, un tercer
tal cual para el modo 87h). Si la lectura del componente, llamado glib, que contiene
siguiente byte resulta diferente de FFh, indica varios reemplazos de algunas llamadas
que todavía no ha terminado el renglón, y se estándar, así como algunas funciones
está de nuevo leyendo el valor N y adicionales para manejar listas ligadas, etc.
repitiéndose todo el proceso. Las funciones de reemplazo se usan para
Un detalle que hay que explicar es lo que incrementar la portabilidad de GTK+, y
sucede con los renglones en el modo 87h algunas de ellas no son estándar en otras
(640x350x16). Storyboard Live! 1.0 guarda unidades, tal como g_sterror(). Otras
todos los sprites en el modo 86h contienen mejoras a las versiones de libc,
(640x480x16), independientemente de que se como por ejemplo g_malloc(), que tiene
esté trabajando en los modos 85h u 86h, lo utilerías de debugging mejoradas. No hay
cual significa que si se abren archivos del suficiente espacio aquí para detallar todas sus
modo 85h, finalmente son almacenados como características de programación, pero véase
86h. Esto es importante, porque en el modo [Main98] para más detalles.
85h el sprite contiene sólo la mitad de Empero, GTK+ sólo es pseudo-orientada a
renglones, y Sprite Editor realiza un proceso objetos, y se plantearon tres enfoques sobre
de duplicación de cada renglón. Por tanto, al cómo integrar su uso a un proyecto
momento de abrir este tipo de archivos en totalmente orientado a objetos: el primero de
Juglar, es necesario realizar la misma ellos optaba por un modelo de programación
duplicación que Storyboard hace para híbrida, caracterizado por el uso de
compensar la diferencia entre ambos. programación estructurada en la componente
de interacción humana, y de programación
DESARROLLO DE LA orientada a objetos en la componente de
COMPONENTE DE dominio del problema. Así, las funciones y
INTERACCIÓN HUMANA procedimientos GTK+ presentes en la
Para la versión Windows de Juglar, se utilizó primera, invocan la ejecución de métodos en
la Visual Component Library (VCL) que la segunda. Esto resulta a todas luces fácil de
acompaña al Delphi de Borland, lo cual aplicar, porque ya existen unidades en Free
Pascal que traducen las funciones de GTK+,

7. escritas en lenguaje C, y por tanto la cantidad El menú raíz, creado
con gtk_menu_item_new() La barra de menú, creada
con gtk_menu_bar_new()
de trabajo de migración que debe realizarse Se agrega a la barra de menú mediante
gtk_menu_bar_append()
es mínima. Sin embargo, no es –desde el Archivo
punto de vista del autor– una solución Un menú, creado
Nuevo
Varios elementos de menú, creados
recomendable, porque esta forma de con gtk_menu_new()
Se liga con el menú raíz
Abrir con gtk_menu_item_new()
Se agregan al menú mediante
mediante una llamada a
programación suele aglutinar las desventajas gtk_menu_item_set_submenu() Salir gtk_menu_append()
de ambas filosofías, en vez de sus virtudes, al
TMenuBar TMenuItem TMenu
permitir el uso desordenado de programación
estructurada y orientada a objetos en distintas
partes de un sistema, afectando la visibilidad
del mismo, y por ende su posterior
modificación o crecimiento. Por tanto, se Ilustración 6.- Ejemplo de encapsulamiento de
decidió no aplicar este enfoque en el los menúes de GTK+ en JCL.
desarrollo de Juglar.
El segundo enfoque, más radical, consistía en procedimientos y sus estructuras de datos
la creación a partir de cero de una nueva quedasen ocultas al programador, quien sólo
librería de clases que encapsulara el interactuaría con las clases envoltorio. El
comportamiento de Xlib, y proporcionara al encapsulamiento debió realizarse con sumo
programador toda la funcionalidad de GTK+; cuidado, de manera que si durante el
en otras palabras, crear el equivalente en desarrollo de la aplicación fuera necesario
XWindow de la Visual Component Library extender mediante herencia y/o agregación la
(VCL) de Borland para Windows. La ventaja funcionalidad de dichas clases, no se tuvieran
aquí era que, bajo un buen análisis y diseño, que manipular las estructuras originales de
resultaba posible crear una jerarquía de clases GTK+.
que respondiera perfectamente al paradigma Afortunadamente, ya existía un antecedente
orientado a objetos, y cuya conexión con la histórico de este enfoque: Tero Pulkkinen,
componente de dominio del problema, Guillaume Laurent y Karl Nelson –junto con
también orientada a objetos, se basara un equipo de al menos nueve colaboradores
únicamente en el despacho de mensajes. El más– mantienen una librería escrita en C++
principal inconveniente de este enfoque que encapsula a GTK+, llamada GTK--.
provenía de que crear una de estas librerías Según los propios autores, las principales
de clases no era un asunto trivial en absoluto, ventajas de esta librería radican en que se
y se pudiera convertir, por mérito propio, en trata de un marco de trabajo para el manejo
un tema de investigación aparte. Por tanto, y seguro de los tipos de las señales, construido
debido a que significaba desviarse con templates y objetos función, además de
radicalmente de los fines que perseguía esta que el método principal de creación de
investigación, tampoco se utilizó (aunque no nuevos widgets y aplicaciones se basa en la
se descarta como un trabajo a futuro). extensión de la jerarquía de widgets existente
El tercer enfoque –que fue el elegido mediante herencia. Este equipo de
finalmente– trataba de obtener los mejor de desarrolladores pone a disposición del
los dos anteriores, y a la vez dejar de lado sus público en su página de Internet ejemplos de
principales desventajas: se pretendía código que muestran la forma efectiva de
minimizar la cantidad de programación emplear la librería, como puede verse en
necesaria para el desarrollo de la librería de [Pulk99].
clases, y lograr al mismo tiempo que ésta Empero, GTK-- no pudo ser utilizada en
cumpliera totalmente con el paradigma forma directa en Juglar, debido a la
orientado a objetos. Para ello, fue necesario incompatibilidad del modelo de objetos de
encapsular los widgets de GTK+ en clases de C++ y de Object Pascal. Así que se decidió
Object Pascal, de forma que sus funciones y crear una serie de clases que encapsularan por

8. completo tanto a GDK como a GTK+,
subproyecto que recibió el nombre de Juglar
Component Library (JCL). La Ilustración 6
muestra esquemáticamente cómo se
encapsularon los widgets de GTK+,
correspondientes al manejo de menúes,
dentro de JCL.
Una vez que JCL hubo encapsulado por
completo la funcionalidad de GTK+, se
estuvo en condiciones de abordar el problema
de desarrollar la componente de interacción
humana –interfaz– de Juglar. Se contaba con
una herramienta de programación visual
asociada a GTK, llamada Glade (misma que
se observa en la Ilustración 8), y pareció Ilustración 8.- Glade durante la creación de la
adecuado tratar de aprovecharla en el interfaz de Juglar.
proyecto. Glade se distribuye bajo Licencia
Pública General GNU, y por tanto se XML, permitiendo así la persistencia de los
encontraba disponible su código fuente, y widgets creados entre diferentes sesiones.
abierta la posibilidad de hacerle Los archivos XML generados por Glade son
modificaciones. Puede almacenar y recuperar equivalentes a los archivos de recursos con
el proyecto de desarrollo en que se está extensión .RES de Windows, pero no pueden
trabajando, por medio de archivos en formato ser compilados y agregados al código objeto
FormaJuglar como sucede con éstos. La herramienta no
(TWindow)
tiene la verdadera funcionalidad de un IDE
CajaVentanaJuglar
(Integrated Development Environment) de
(TVBox)
desarrollo visual al estilo de Delphi, donde se
puede construir una aplicación mediante
BarraMenuPrincipal
(TMenuBar)
BarraHerramientas
(TToolBar)
ContenedorVentajasHija
(TNotebook)
BarraEstado
(TStatusBar) arrastrar y soltar (drag and drop) los
Archivo componentes visuales en la forma, codificar
(TMenuItem)
CajaVentanaEditorHistorias
MenuArchivo
(TMenu)
(TVBox) la componente de dominio del problema,
Edicion
(TMenuItem) Nuevo CajaVentanaEditorAnimaciones
(TVBox)
compilar todo, depurarlo y guardar el
(TMenuItem)
MenuEdicion
(TMenu) Abrir CajaVentanaEditorGraficos
proyecto de manera interactiva. El código
Modos
(TMenuItem)
Deshacer
(TMenuItem) (THBox)
generado por Glade incluye únicamente las
(TMenuItem)
Herramientas
(TMenuItem)
Cerrar
(TMenuItem) estructuras de datos y funciones de la
Rehacer
Ventana
(TMenuItem) Separador1
(TMenuItem)
componente de interacción humana, que a lo
(TMenuItem) Separador4
(TMenuItem) Guardar
sumo pueden incluir referencias a las
MenuVentana
Cortar
(TMenuItem)
callbacks para atención a las señales en la
(TMenuItem) GuardarComo
(TMenu)
Copiar
(TMenuItem) componente de dominio del problema, pero
NombreVentanaX
(TMenuItem) Separador2
(TMenuItem)
sin la posibilidad de desarrollar éstas de
(TMenuItem) Pegar
(TMenuItem) Imprimir forma interactiva. Además, debido a que
Ayuda (TMenuItem)
(TMenuItem) Separador5
(TMenuItem)
Glade se diseñó para GTK+, sus capacidades
Separador3
InsertarLinea
(TMenuItem)
de generación de código se restringen sólo al
MenuAyuda
(TMenu)
(TMenuItem) Salir
(TMenuItem) lenguaje C, es decir, no genera código en
BorrarLinea
(TMenuItem) Pascal estructurado, y mucho menos en
AcercaDe
(TMenuItem)
Object Pascal para dar soporte a Juglar
Component Library.
Ilustración 7.- Diagrama de objetos de la
Ante semejante limitación, se optó por la
interfaz de Juglar.
creación de la interfaz en Glade, para luego

9. revisar de forma manual el contenido del TApplication
archivo XML resultante, en busca de la
declaración de cada uno de los widgets que la
integraban, los valores que presentaban sus
atributos y las relaciones de agregación que TAplicacionJuglar
los unían. A partir de todo ello, se tradujeron Clases de la componente
de interacción humana
manualmente los widgets a objetos JCL
equivalentes y se asignaron los valores
correspondientes a sus propiedades. La
solución no es demasiado elegante, puesto TEditorHistorias TEditorAnimaciones TEditorGráficas TPresentación TIlustrador
Electrónica
que si se modifica nuevamente la interfaz en
Glade, hay que darle seguimiento en forma
manual a los cambios y reflejarlos en el
código objeto correspondiente, pero resulta a
todas luces rápida y fácil de instrumentar, Ilustración 9.- Asociación preliminar entre las
máxime cuando el objetivo de la clases de la componente de dominio del
investigación no es crear una herramienta problema de Juglar.
visual. y métodos. Tras una depuración preliminar,
Como resultado, se llegó al diagrama de donde se eliminaron todas aquellas clases
objetos de la componente de interacción redundantes, vagas, irrelevantes, etc. se creó
humana que se muestra en la Ilustración 7, un diccionario de clases detallado, a partir
donde se aprecia la presencia de un del cuál fue posible identificar asociaciones
contenedor de ventajas hija, cada una de las preliminares entre clases, tal como lo muestra
cuales forma la interfaz de uno de los la Ilustración 9. La clase
módulos de Juglar: el Editor de Historias, el TAplicacionJuglar, descendiente de la
Editor de Animaciones y el Editor de clase TApplication desarrollada como
Gráficas.
parte de la Juglar Component Library, está
compuesta, además de las clases ya
DESARROLLO DE LA explicadas en la componente de dominio del
COMPONENTE DE DOMINIO problema, por cinco clases más:
DEL PROBLEMA ¢
TEditorHistorias
Partiendo de la información obtenida en la ¢
TEditorAnimaciones
recolección de requerimientos realizada al ¢
TEditorGraficas
inicio de la investigación, así como de la
interfaz que se explicó en el inciso anterior y
¢
TPresentacionElectronica
del conocimiento del dominio del problema
¢
TIlustrador
que ya se poseía, se estaba en condiciones de de las cuáles sólo los tres primeras forman
redactar una descripción inicial del parte de la primera etapa de esta
problema. Se trataba de describir los investigación.
elementos del sistema que ya se conocían, A partir de este primer diagrama, se inició
tales como sus objetivos centrales, las realmente el análisis separado de las
funciones que el sistema debía desarrollar, los asociaciones que forman cada módulo. Con el
datos con los cuales operaría, etc., así como fin de no extenderse demasiado en la
inferir la existencia de algunos otros que explicación, se ejemplificará sólo el análisis
pudieran no ser tan obvios. Esta descripción, para la clase TEditorHistorias, del
redactada en un lenguaje coloquial pero en módulo homónimo, tal como lo muestra la
una forma exhaustiva, dio pie a la Ilustración 10. El Editor de Animaciones y el
identificación preliminar de clases, atributos

10. Editor de Gráficos siguen lógicas muy TComando
similares. ejecutar; virtual;
abrir; virtual;
La clase más importante aquí, guardar; virtual;
TLineaFlujo, es una estructura de tipo
FIFO (First In, First Out), que contiene por TShowDisplay TClearColor TCommentMidiOff TSprite
ejecutar;
agregación objetos del tipo abrir;
guardar;
abrir;
guardar;
abrir;
guardar;
abrir;
guardar;
TElementoLinea. Esta clase forma,
TShow TClear TComment
mediante agregación recursiva, la línea de
flujo como tal, al representar cada uno de los ejecutar; ejecutar; ejecutar;
renglones que forman la historia como parte TDisplay TColor TMidiOff
de su antecesor. Cada elemento de línea ejecutar; ejecutar; ejecutar;
posee un comando, representado por la
agregación de la clase abstracta TComando, TAudioMidiOn TExec TIfIfNot TTellCall
ejecutar;
ancestro directo de todas las clases que abrir;
guardar;
abrir;
guardar;
abrir;
guardar;
abrir;
guardar;
instrumentan los distintos comandos que TAudio TIf TTell
Juglar puede ejecutar, y que establece por
tanto un mecanismo polimórfico para los ejecutar; TMidiOn ejecutar; ejecutar;
principales métodos de los comandos, tales TMidi ejecutar;
TIfNot TCall
como su construcción, su apertura desde un ejecutar;
ejecutar; ejecutar;
archivo y su ejecución.
Como todos los comandos tienen dos partes TPrint TLock TOverlay TButton
comunes, el tiempo de ejecución y de espera, ejecutar; ejecutar; ejecutar; ejecutar;
así como un comentario, se han generado dos TBifurcacion
TInput TInt
clases TTimeWait y TComentario que se ejecutar; ejecutar;
abrir abrir; abrir
agregan a la clase TComando para guardar; guardar; guardar;
representar esta relación. TGoto TGosub TReturn TEnd
Dado que TComando es una clase abstracta
ejecutar; ejecutar; ejecutar; ejecutar;
que representa los elementos comunes a
todos los comandos de Juglar, se necesita
crear un conjunto de clases concretas, Ilustración 11.- Clases descendientes de
descendientes de ella, que instrumenten los TComando.
métodos virtuales que ésta ha dejado
ejemplo, TComment y TMidiOff, las
pendientes. La Ilustración 11 muestra dicha
clases para dos comandos que aparentemente
jerarquía de clases.
no tienen nada en común, ambas descienden
Puede observarse que algunas clases que
de una clase abstracta TCommentMidiOff.
representan comandos, son descendientes de
nuevas clases abstractas intermedias. Por Esto pudiera parecer en una primera instancia
desconcertante o hasta equivocado. Pero la
TLineaFlujo TElementoLinea TTimeWait creación de esta clase abstracta intermedia,
Avanzar;
Retroceder;
respondió a las similitudes encontradas en los
TEditorHistorias Ejecutar;
Insertar;
Borrar;
Anterior;
Siguiente;
Ejecutar;
formatos internos de estos comandos en el
archivo .SH. Así, los métodos que se
TComentario
TPortapapeles
TComando
encargan de construir y abrir los objetos de
ambas clases, pueden estar declarados en esta
Copiar
Pegar
Cortar Ejecutar; virtual; clase ancestro común y así no se requiere
escribirlo dos veces, mientras que el método
de ejecución de cada uno es diferente. Esto
Ilustración 10.- Relaciones de asociación del
facilita el manejo polimórfico y la
módulo Editor de Historias.
extensibilidad del sistema cuando se requiera

11. TImagen TPaleta EntradaColor Nuevamente, mostrar aquí todos los
escenarios y diagramas de seguimiento de
abrir; virtual; agregar; cambiar;
TShow
guardar; virtual;
desplegar; virtual;
borrar;
cambiar;
anterior;
siguiente;
sucesos empleados en esta investigación
requeriría de un enorme espacio y de seguro
ejecutar;
TImagenPIC TImagenPCX TImagenGIF
abrumaría al lector, motivo por el cuál se va a
TDisplay
presentar únicamente uno de ellos, con la
abrir;
guardar;
abrir;
guardar;
abrir;
guardar;
idea de ejemplificar.
desplegar; desplegar;
ejecutar;
desplegar;
La Ilustración 14 muestra un posible
escenario de ejecución, en el cuál la ventana
Ilustración 13.- Asociación uno a cero o uno principal de Juglar ya está abierta, y el
entre los comandos TShow y TDisplay y la usuario decide crear una historia nueva.
clase TImagen. - El usuario selecciona Archivo |
Nuevo en el menú principal de
crear nuevos comandos con una sintaxis en Juglar.
archivo idéntica a los ya existentes. - Aparece una ventana de diálogo
Todas aquellas clases que representan "Seleccionar Tipo de Archivo".
comandos para el despliegue o reproducción - El usuario selecciona el tipo de
archivo que desea: una nueva
de algún tipo de archivo durante la historia.
presentación, tienen una asociación uno a - Se despliega una ventana del
cero o uno con la clase que encapsula el Editor de Historias conteniendo
archivo. Así, la Ilustración 13 muestra la una historia nueva.
asociación entre los comandos SHOW y Ilustración 14.- Escenario "El usuario crea
DISPLAY, y las imágenes en formato .PIC. una nueva historia".
Puede observarse que la clase TImagenPIC
desciende de la clase abstracta TImagen, la Partiendo del hecho de que la ventana del
cual declara pero no instrumenta los métodos Editor de Historias ya se encuentra creada,
relativos a la apertura y despliegue de las pero está oculta, y que todavía no existe el
imágenes, mismos que se codifican en sus objeto que representa a la línea de flujo, el
clases descendientes. Hasta el momento, sólo diagrama de seguimiento de sucesos
se ha instrumentado la clase descendiente resultante es el que se muestra en la
TImagenPIC, pero se espera agregar Ilustración 12. Puede observarse que este
prontamente soporte para otros formatos diagrama presenta sólo las opciones para un
gráficos (TIF, PCX, TGA, etc.). suceso en especial, que es la creación de una
Todos los descendientes de TImagen nueva historia, pero el usuario bien pudiera
heredan una relación de asociación con un elegir crear una nueva animación o una nueva
objeto de la clase TPaleta, que representa gráfica, lo cuál daría pie a dos escenarios y
la paleta de colores del archivo. Esta paleta
puede contener un número variable de Item de Menú
Diálogo
"Seleccionar Linea de Flujo Ventana
Archivo | Nuevo tipo de Archivo" Editor de Historias
elementos de la clase TEntradaColor, seleccionar Archivo
|Nuevo
que definirán los valores RGB de cada color desplegar
seleccionar el tipo de archivo deseado
de la imagen. El número de entradas de color
regresar el tipo elegido
define la profundidad de la imagen. crear
Una vez que se determinó la estructura cargar
estática de Juglar, el siguiente aspecto tratado ocultar
fue su comportamiento en el dominio del desplegar
tiempo. El modelo dinámico se encargó de Ilustración 12.- El Diagrama de seguimiento
detallar estos aspectos. de sucesos para el escenario "El usuario
crea una nueva historia".

12. diagramas de seguimiento de sucesos de esta investigación, tales como el objeto
diferentes, donde participen otros objetos visualizador de gráficas del Editor de
distintos. Gráficas y la opción de visualizar imágenes
Una vez conocidas las clases que participan del Editor de Historias, aún están sin
en el dominio del problema, sus diversas instrumentarse. Es necesario dedicarles algún
relaciones de agregación, asociación y tiempo, pues sin ellos la herramienta no está
herencia, así como su comportamiento tan completa como debiera.
individual y colaborativo en el tiempo, se Ya se ha iniciado la creación del lenguaje de
detalló algorítmicamente la forma en que se programación de scripts propio de Juglar,
instrumentaría dicho comportamiento. En llamado Mester, con una sintaxis tipo Pascal
esto consistió el modelo funcional. Algunos pero con una funcionalidad similar a la de
autores, entre ellos Rumbaugh, proponen la JavaScript (incluyendo la posibilidad de ser
representación del modelado funcional a orientado a eventos y basado en objetos).
través de diagramas de flujo de datos (DFD)
y narrativas de procesamiento descritas en
pseudocódigo. Sin embargo, existe otra BIBLIOGRAFIA
corriente, encabezada por Bertrand Meyer [FSF00] The Free Software Foundation, Home Page,
[Meyer99], que propone la descripción 1 de enero del 2000, <www.fsf.org>
[Burger92] Burger, Jeff. La Biblia del Multimedia.
algorítmica de los métodos de cada clase a Primera Edición. USA: Ed. Addison-Wesley
través del propio lenguaje de Iberoamericana, 1992, 644 p.
instrumentación. En esta investigación se [McCon97] McConnell, Steve. Desarrollo y Gestión
siguió esta óptica, desarrollando el modelo de Proyectos Informáticos. Primera Edición. España:
funcional completamente en código de Object Ed. McGraw-Hill Microsoft Press, 1997, 691 p.
[Press98] Pressman, Roger S.. Ingeniería del
Pascal.
Software, un Enfoque Práctico. Cuarta Edición.
España: Ed. McGraw-Hill, 1998, 581 p.
CONCLUSIONES [Rum96] Rumbaugh, James et al. Modelado y Diseño
Esta investigación ha demostrado que es Orientado a Objetos, Metodología OMT. Primera
posible crear una aplicación de integración de Edición. España: Ed. Prentice Hall, 1996, 643 p.
[Cann00] Canneyt, Michaël Van. The Free Pascal
multimedios, Juglar, que permita a los Home Page. 1 de enero de 2000.
usuarios de software libre disfrutar de las <www.freepascal.org>.
mismas capacidades que exhiben las [Borl95] Borland International. Delphi User's Guide.
aplicaciones profesionales no libres. Si bien Primera Edición. USA: Ed. Borland International,
la herramienta todavía no está concluida, ya 1995, 452 p.
[Press88] Pressman, Roger S. Software Engineering,
es capaz de crear sus propias presentaciones, A Beginner’s Guide. Primera Edición. USA: Ed.
y ejecutar aquellas creadas por Storyboard en McGraw-Hill, 1988, 294 p.
DOS. Con un esfuerzo mayor, y la [Chamo97] Chamorro, Félix et al. Programación y
colaboración de un equipo de programadores, Diseño en Entornos Gráficos. Primera Edición.
será posible concluir en los meses España: Ed. McGraw-Hill, 1997, 375 p.
[IBM89] International Business Machines. IBM
subsecuentes un primer release del software, Storyboard Plus Version 2.0. Primera Edición. USA:
ya con posibilidades de resultar atractivo para Ed. International Business Machines, 1989, 450 p.
el gran público. A mediano plazo, la [Main98] Main, Ian y Tony Gale. GTK Tutorial.
inserción de nuevas características lo harán Primera Edición. USA: Sin Editorial, 500 p.
todavía más competitivo, hasta llegar a ser, [Pulk99]
http://www.iki.fik/terop/gtk/gtk--
como se pretende, la herramienta predilecta .html, diciembre de 1999.
para los profesionales de la autoría. [Meyer99] Meyer, Bertrand. Construcción de
Software Orientado a Objetos. Segunda Edición.
TRABAJOS A FUTURO España: Ed. Prentice Hall, 1999, 1198 p. Incluye CD-
Algunos componentes del sistema que se ROM.
planeaba tener listos durante la primera etapa