AsociacinparalaDifusinyelAvancedelSoftwareLibreenAndaluca(ADALA) LinuxMalaga(LiMA)

Ponenciasdelas IIJornadasAndaluzasdeSoftwareLibre Mlaga,viernes18ysbado19deoctubrede2002 Elcomitorganizadorestcompuestopor: AntonioBuizaCalero(buizaatadala.org) ElenaGonzlezJurado(leniatadala.org) JavierLinaresSnchez(javieratjavierlinares.com),ResponsableTecnologasdela Informacin TefiloRuizSurez(teoatadala.org),SecretarioTcnico JuanIsidoroSerranoGarca(juanatadala.org) JosAlbertoSurezLpez(bassatadala.org),Portavozdelcomit FernandoUseroFuentes(fuseroatwanadoo.es) Comitdeprograma: AntonioLuqueEstepa(aluqueatesi.us.es),UniversidaddeSevilla DanielCarrinReinoso(danielatyacoi.com),YacoS.L. AlfonsoCepedaCaballos(cepedaatcartuja.us.es),UniversidaddeSevilla LuisMaraCruz(luismcatlinuxmalaga.org),AsociacindeusuariosdeLinuxdeMlaga JuanJ.Merelo(jmereloatgeneura.ugr.es),UniversidaddeGranada Responsablesesionesespeciales: JavierViualesGutirrez(viguatyacoi.com),YacoS.L. ndicedecontenidos: DesarrollomultiplataformaconwxWindows IntroduccinaherramientasdediseoenLinux Gestinlibre.Unaoportunidadparatodos Elsoftwarelibrecomoimpulsordelainnovacintecnolgica UsodellenguajeXMLparaeldesarrollodelsoftwarelibre ElproyectodeclusterSSIOpenMosix Desarrollorpidodevideojuegos Herramientasbsicasdedesarrollo JAMES:unaalternativalibreparalacoordinacindegruposdetrabajo Ingenieradelsoftwarelibre.Unavisinalternativadelaingenieradelsoftwaretradicional
Obtenidodehttp://web.archive.org/web/20070706212001/http://cicodegcubo.ugr.es/adala/encuentros/jasl2/ponencias.html Elcopyrigthdecadaponenciaperteneceasusautores.

DESARROLLO MULTIPLATAFORMA CON WXWINDOWS Israel Herraiz Tabernero israel.herraiz@hispalinux.es

RESUMEN wxWindows es una biblioteca de clases para C++ y Python, que permite el desarrollo de aplicaciones con interfaces gr a cas de usuario de una manera r pida y sencilla. Su princia pal caracterstica es que es multiplataforma. Desde su con cepci n se procur que fuera completamente independiente o o del sistema operativo y del compilador. En la actualidad, las versiones para Windows y para Linux son completamente estables, y la versi n para MacOS 8/9 y MacOS X est en o a una fase muy avanzada de desarrollo. Todas estas versiones se pueden conseguir en www.wxwindows.org. En este artculo crearemos un ejemplo Hola mundo! con la bi blioteca para C++, y lo compilaremos en Windows y Linux. 1. INTRODUCCION Julian Smart comenz a desarrollar wxWindows en 1992 o en el Articial Intelligence Applications Institute, de la Universidad de Edimburgo. wxWindows se distribuye bajo licencia wxWindows Library License, que es similar a la GNU Library General Public License pero que adem s permite a usar la biblioteca para desarrollos comerciales (ya sean aplicaciones o modicaciones de la propia biblioteca), siempre y cuando estos desarrollo comerciales no usen ning n c diu o go distribuido bajo alguna licencia GNU. Una caracterstica importante de wxWindows es que in tenta usar los controles nativos en cada plataforma. Si no existen controles de alg n tipo en alguna plataforma, los u emula (por ejemplo, el control wxSpinCtrl en Linux + GTK+). De este modo, se logra un aspecto homog neo en cada plae taforma (al contrario, por ejemplo, de lo que ocurre con las aplicaciones desarrolladas con GTK en Windows). En la actualidad, est soportadas las siguientes plataformas: a Windows 3.1, Windows 95/98/NT/2000/XP La mayora de las variantes de UNIX que usen Motif La mayora de las variantes de UNIX que usen GTK+ Mac Adem s de las clases para el desarrollo de GUIs, wxa Windows consta de una parte denominada wxBase que incluye clases como wxString, clases para el manejo de archivos y directorios de manera independiente del sistema

operativo, tipos de datos independientes de la arquitectura (32 o 16 bits), etc. A la hora de compilar wxWindows podemos elegir que se enlace de manera est tica con las aplicaciones, o crear a una biblioteca de enlace din mico. Adem s, podemos coma a pilar en modo FINAL, o en modo DEBUG. En cualquiera de los casos, los ejecutables obtenidos tienen un tama o relatin vamente peque o (que podemos disminuir hasta en un 70 % n si usamos un compresor de ejecutables como UPX, disponible en upx.sourceforge.net). 2. WXHTML. UN MOTOR HTML PARA WXWINDOWS Otra caracterstica destacable de wxWindows es que in cluye clases para visualizar archivos HTML. Por el momento, no implementa el est ndar completo de HTML, pero en a cualquier caso tiene una funcionalidad suciente como para poder mostrar archivos sencillos, usarlo como editor de textos con coloreado de sintaxis, visor de archivos de ayuda (existen clases especcas para ello), etc. Las clases wxHTML permiten adem s extender el cona junto de tags mediante etiquetas personalizadas, que el motor se encarga de interpretar y visualizar. Esta caracterstica va m s all de simplemente mostrar texto o im genes de a a a una manera personalizada, sino que nos permite interactuar con el archivo HTML que se est mostrando. En denitia va, podemos implementar una aplicaci n cuya interfaz con o el usuario sea un archivo HTML. wxHTML se encargan de generar los eventos necesarios para interacci n del usuario o con el archivo mostrado. 3. CREACION Y VISUALIZACION DE IMAGENES La clase wxImage puede cargar y crear varios formatos de imagen diferentes. Incluso, se puede extender la funcionalidad de esta clase si creamos el handler para un formato nuevo. En este momento, existen handlers para los formatos: TIFF, usando libTIFF JPEG, usando la biblioteca del Independent JPEG Group

BMP GIF (s lo para visualizar, no para crear) o PNG PCX PNM Adem s tambi n se pueden cargar iconos en formato ICO a e o en formato XPM. Es importante se alar que todos los n formatos de imagen y todos los de iconos se pueden usar en cualquier sistema operativo. Por ejemplo, perfectamente puedes usar iconos en XPM para la barra de herramientas de una aplicaci n Windows. o 4. CONTEXTUALIZACION (LOCALIZACION) wxWindows incluye macros que permiten la traducci n o autom tica de una aplicaci n a diferentes idiomas. Los cat loa o a gos de traducci n necesarios se crean con GNU GetText a o partir del c digo fuente de la aplicaci n. Para que una cao o dena sea traducida, debe crearse con la macro (cadena). Por ejemplo:
wxMessageBox( _("Este texto se podr traducir"), a "Este no");

5. BIBLIOTECA ESTANDAR DE C++ wxWindows no emplea ninguna clase de la biblioteca est ndar de plantillas, ni namespaces ni plantillas. La raz n a o es que si emplearan se reducira dr sticamente el n mero de a u compiladores que se podran usar con wxWindows, ya que no todos los compiladores soportan perfectamente estas caractersticas (e incluso, no todos tienen el mismo API para la biblioteca est ndar de plantillas). a 6. DOCUMENTACION 6.1. Nuevos usuarios El principal inconveniente de la documentaci n de wxo Windows es que no incluye ning n tutorial para principianu tes. Se ha concebido m s como una documentaci n de rea o ferencia (eso s, muy util para el trabajo diario con wxWin dows) que como una introducci n a la biblioteca. o Si se han tenido contactos con otras bibliotecas de cla ses como Qt o MFC, es f cil adaptarse a wxWindows, pea ro si no se tiene ninguna experiencia con alguna biblioteca similar, puede ser algo sufrido comenzar a programar con wxWindows. Por el momento, la mejor alternativa es plantearse una aplicaci n, e intentar desarrollarla con wxWino dows. Cuando no sepamos c mo implementar exactamente o una caracterstica, podemos recurrir a la extensa colecci n o de ejemplos, o incluso al propio c digo fuente de la biblioo teca. Est previsto el desarrollo de un libro de wxWindows a por parte de los autores de la biblioteca. Por ahora, el libro est algo avanzado, pero todava quedan bastantes puntos a por escribir. 6.2. Usuarios experimentados Una vez que ya tengamos experiencia con wxWindows, la documentaci n ser una valiosa ayuda para el desarrollo o a de nuestras aplicaciones. La referencia alfab tica incluye la documentaci n de toe o dos los m todos de cada clase, de los eventos que genera (y e de c mo capturarlos), una breve descripci n de cada clase y o o enlaces a otros puntos de inter s dentro de la misma biblioe teca (artculos u otras clases relacionadas). Adem s, se incluyen una serie de artculos que ilustran a sobre determinadas caractersticas de la biblioteca. Estos artculos incluyen explicaciones detalladas, c digo de ejem o plo y enlaces a otros artculos relacionados y a la documen taci n de las clases implicadas. o Toda la documentaci n est disponible en formato HTML, o a A WinHelp, MS HTML Help, PDF, PS y c digo fuente LTEX. o El unico inconveniente es que la documentaci n s lo est diso o a ponible en ingl s. e

Para generar el cat logo, hay que usar la siguiente instruca ci n: o

xgettext -C -k_ *.h *.cpp -o mi_catlogo.po a

Para poder usar el cat logo de traducci n, primero hay a o que compilarlo (generar el binario mo), con la instrucci n o (por supuesto, despu s de haber realizado las traducciones): e
msgfmt mi_catlogo.po -o salida.mo a

Despu s, en el c digo de nuestra aplicaci n, creamos un e o o objeto wxLocale antes de crear la ventana principal:
wxLocale m_traductor; m_traductor.Init("Espaol","es","C"); n m_traductor.AddCatalog("mi_catlogo"); a

El primer par metro del m todo Init() es una mera etia e queta que se usar en los mensajes de wxWindows que lo a requieran (por ejemplo, los mensajes de error si no encuentra el cat logo). El segundo par metro es la identicaci n a a o del idioma que vamos a usar. Es muy importante, ya que el cat logo debe encontrarse en un subdirectorio que se llame a como esta identicaci n. La tercera cadena indica las caraco tersticas culturales que se deben aplicar en la localizaci n o (es igual que el par metro de la funci n setlocale() de a o la biblioteca est ndar de C[1]). a Nuestra aplicaci n buscar el archivo mi catlogo.mo o a a dentro del subdirectorio es (en relaci n al directorio donde o est el ejecutable). Tambi n buscar el directorio es en otros a e a directorios predeterminados (los contenidos en la variable de entorno PATH, Mis documentos en Windows y nuestro directorio home en UNIX). Adem s de nuestro cat logo, a a tambi n buscar uno llamado wxstd.mo, que contiene las e a traducciones de todos los mensajes que emite la biblioteca.

7. HOLA MUNDO! Despu s de un breve recorrido por algunas de las carace tersticas de wxWindows, vamos a crear un peque o ejemplo n para mostrar c mo se crea una aplicaci n, c mo se contexo o o tualiza (localiza) y c mo se manejan los eventos. o Compilaremos la aplicaci n en Windows y Linux usano do el compilador gcc (en Windows usaremos el compilador Mingw, disponible en www.mingw.org). En primer lugar, crearemos el archivo con las interfaces de las diferentes clases (hola mundo.h). Lo iremos comentando a la vez que mostramos el c digo: o
// Archivo hola_mundo.h #ifndef _HOLA_MUNDO_H_ #define _HOLA_MUNDO_H_ #ifndef TRUE #define TRUE 1 #endif #ifndef FALSE #define FALSE 0 #endif

En este archivo se dene la clase wxLocale, que usaremos para traducir la aplicaci n a diferentes idiomas. o
// Clase derivada de wxApp class MiAplicacion : public wxApp

Toda aplicaci n tiene que crear una clase derivada de o wxApp. Esta clase es especial, ya que no crearemos ninguna instancia de ella (de ello se encarga el framework).
{ public: // El mtodo OnInit() actuar de funcin main() e a o virtual bool OnInit(); protected: // Instancia de wxLocale para traducir // la aplicacin o wxLocale m_traductor; };

Denimos una constante para que no se incluya el archivo m s de una vez (que es m s que suciente). Tambi n a a e denimos las macros TRUE y FALSE para usar con las variables de tipo bool.
// Para los compiladores que soporten // archivos h precompilados #include <wx/wxprec.h> // Para todos los dems a #ifndef WX_PRECOMP #include <wx/wx.h> #endif

Aqu simplemente incluimos los archivos de wxWindows necesarios. Si el compilador soporta archivos de cabecera precompilados, podemos usarlos para disminuir el tiempo de compilaci n (por ahora, s lo funciona con Borland C++ o o 5 y Visual C++ 6). Si no es as (es decir, no est denida la a macro WX PRECOMP, usamos un archivo de encabezado de texto plano.
// Para que funcione con // el compilador de Borland #ifdef __BORLANDC__ #pragma hdrstop #endif

En la interfaz de la clase MiAplicacion denimos el m toe do OnInit(). Este m todo actuar como si fuera la funci n e a o main() del programa, ya que como veremos despu s, las e aplicaciones desarrolladas con wxWindows no tienen funci n main(). El atributo m traductor se encargar de encono a trar el cat logo de traducci n (seg n nosotros le indiquea o u mos), y de forma totalmente transparente para nosotros, traducir todas las cadenas de texto que hayamos creado con a la macro (cadena). Adem s, si junto a nuestro cat logo a a encuentra el de wxWindows (wxstd.mo), traducir todos a los mensajes de la biblioteca (que originalmente est n en a ingl s). e Hay que se alar que hemos obviado el constructor, ya n que no crearemos directamente ninguna instancia de esta clase. Todo el c digo de inicializaci n de la aplicaci n debe o o o estar contenido en el m todo OnInit(). e
// Ventana principal class MiVentana : public wxFrame { public: // Constructor MiVentana( const wxString& titulo, const wxPoint& posicion, const wxSize& tam);

Este es un extra o requerimiento del compilador Born land C++. Es un pragma (es decir, una opci n especca del o compilador), sin el cual no se puede compilar wxWindows ni ninguna aplicaci n que use esta biblioteca. o
// Otros archivos requeridos // Para la contextualizacin o #include <wx/intl.h>

La ventana principal tiene que ser una instancia de una clase que derive de wxFrame (o de alguna clase derivada de wxFrame, como wxDocMDIParentFrame). El constructor que hemos denido acepta tres par metros, que pasaa remos al constructor de wxFrame. Los par metros se han a denido como constantes para cumplir con el principio de menor privilegio (si el constructor no necesita modicar estos par metros, no debe tener la potestad de hacerlo), y se a pasan por referencia para que no se haga una copia de los mismos cuando creemos una instancia de esta clase (de este

modo, se ahorra algo de memoria). Como se han denido como constantes, no existe peligro de que se modiquen las variable originales que se pasan al constructor.
private: // Maneja el evento de la opcin Salir o void OnQuit(wxCommandEvent& event); // Maneja el evento de la opcin Acerca de o void OnAbout(wxCommandEvent& event); // Esta es una funcin virtual que hemos o // sobreescrito (para mostrar un mensaje // antes de cerrar la ventana) void OnCloseWindow(wxCommandEvent& event);

// ID_QUIT // }; // Primer requerimiento: IMPLEMENT_APP(MiAplicacion)

Esta macro hace que el m todo OnInit() de MiAplicae cion se comporte como si fuera la funci n main() del proo grama. Dentro de este m todo deberemos crear y mostrar e la ventana principal, e iniciar la instancia de wxLocale para que se traduzca la aplicaci n. o
// Inicializamos la aplicacin o bool MiAplicacion::OnInit() { m_traductor.Init("Espaol","es","C"); n m_traductor.AddCatalog("messages"); MiVentana *ventana = new MiVentana( _("Hello world!"), wxDefaultPosition, wxDefaultSize); ventana->Show(TRUE); return TRUE; }

Estos tres m todos se encargan de recibir los eventos e que se alemos en la tabla de eventos. Los dos primeros n simplemente responden a dos opciones del men que creau remos. El tercer m todo, lo llamaremos cuando se vaya a e cerrar a la ventana, con el n de mostrar un mensaje de despedida. El m todo OnCloseWindow() es un m todo virtual e e de wxWindow, de la que deriva wxFrame. wxFrame ya tiene denido un m todo OnCloseWindow() con un comportae miento predeterminado (cierra la ventana ;-). Nosotros sobrescribiremos este comportamiento, a adiendo un mensaje n de despedida.
// Tabla de eventos // (no se incluye el punto y coma al // final porque es una macro) DECLARE_EVENT_TABLE() };

La manera m s c moda de conectar eventos con m toa o e dos es mediante tablas de eventos. Si queremos usar una tabla de eventos, hay que llamar a esta macro dentro del cuerpo de la interfaz de la clase que quiera manejar los eventos. Posteriormente veremos c mo se implementa la tabla de o eventos. Hay que se alar que no hay que incluir un punto y n coma despu s de esta macro, ya que la macro no es m s que e a un trozo de c digo que ya incluye su propio punto y coma. o
#endif // end of _HOLA_MUNDO_H_

Ya hemos dicho que este m todo juega el mismo pae pel que la funci n main() en otros programas. Lo primero o que tenemos que hacer es iniciar la instancia de wxLocale (por supuesto, si no queremos usar traducciones, no hay que crear ninguna instancia, ni inicializarla). Despu s le pae samos el nombre del cat logo de las traducciones. En este a caso, buscar el archivo messages.mo dentro del subdia rectorio es. Tambi n intentar buscar el archivo wxstd.mo e a para traducir los mensajes de la biblioteca. Despu s, creamos la ventana principal, instancia de Mie Ventana. Le pasamos el ttulo de la ventana (est en ingl s, a e y lo traduciremos al espa ol), y la posici n y el tama o de n o n la misma (en este caso, tama o y posici n por defecto). Por n o ultimo mostramos la ventana y devolvemos TRUE para indicar que todo ha ido bien.
// Implementacin de la tabla de eventos o BEGIN_EVENT_TABLE(MiVentana,wxFrame) EVT_MENU(ID_ABOUT,MiVentana::OnAbout) EVT_MENU(ID_QUIT,MiVentana::OnQuit) EVT_CLOSE(MiVentana::OnCloseWindow) END_EVENT_TABLE()

Y por n terminamos el archivo de encabezado de nuestra peque a aplicaci n. n o Ahora comenzaremos la implementaci n de las clases o denidas:
// Archivo hola_mundo.cpp #include "hola_mundo.h" // IDs para las opciones // del men u #define ID_ABOUT 100 #define ID_QUIT 101 // // // // o tambin (cuestin de gustos) e o enum { ID_ABOUT = 100,

Esta es la tabla de eventos. La comenzamos con la macro BEGIN EVENT TABLE, que acepta dos par metros. El a primero es el nombre de la clase que quiere manejar los eventos. El segundo par metro es el nombre de la clase de a la que nuestra clase hereda el comportamiento. En este caso, MiVentana hereda de wxFrame. En la tabla de eventos hemos denido dos handlers para eventos de men . Cuando se elija la opci n del men etiu o u quetada con el valor ID ABOUT, se llamar al handler OnAa bout, que pertenece a la clase MiVentana. El otro evento de men es id ntico. u e

La macro EVT CLOSE se usa para capturar el evento que se produce cuando se va a cerrar la ventana (por ejemplo, cuando el usuario hace clic sobre el bot n de cerrar la o ventana, o cuando pulsa la combinaci n ALT+F4, o cuano do llamamos al m todo Close() de wxFrame). Como s lo e o hay un posible emisor del evento (la ventana que maneja los eventos) no hay que pasar la identicaci n del control emio sor. El evento ser manipulado por OnCloseWindow de la a clase MiVentana.
// Constructor de MiVentana MiVentana::MiVentana(const wxString& titulo, const wxPoint &posicion, const wxSize &tam) : wxFrame(NULL,-1,titulo,posicion,tam)

men , que tambi n podremos hacerla otante (de nuevo, u e s lo vale en wxGTK). o A adimos dos opciones al men , con su identicaci n, n u o su ttulo, y el mensaje que aparecer en la barra de status a (que despu s creamos, con dos campos). Tambi n a adimos e e n el men a la barra de men . u u
// Maneja el evento de la opcin Salir o void MiVentana::OnQuit(wxCommandEvent& event) { this->Close(TRUE); }

El primer par metro del constructor de wxFrame es la a ventana padre. Debe pasarse un puntero a un objeto del tipo wxWindow. Como en este caso es la ventana principal, no tiene ventana padre, le pasamos la macro NULL (un puntero a nada). No es necesario hacer un casting a wxWindow*, ya que la biblioteca incorpora ya todos los castings necesarios para que el puntero NULL sea del tipo wxWindow*. El segundo par metro es la identicaci n de la ventaa o na. Debe ser un objeto del tipo wxWindowID, que a todos los efectos lo podemos tomar igual que un entero. Como en este caso no tenemos necesidad de asignarle ninguna identicaci n a la ventana, le pasamos -1, y la biblioteca le asigo nar una identicaci n por defecto. a o El resto de par metros son el ttulo que aparecer en la a a barra de ttulo de la ventana, la posici n y el tama o. o n
{ wxMenu *mi_menu = new wxMenu(_("Todays menu"), wxMENU_TEAROFF); wxMenuBar *mi_barra_de_menu = new wxMenuBar(wxMB_DOCKABLE); mi_menu->Append(ID_ABOUT, _("About SuperApp"), _("Show about SuperApp dialog")); mi_menu->Append(ID_QUIT, _("Close SuperApp"), _("Close this amazing application")); mi_barra_de_menu->Append(mi_menu, _("Todays menu")); this->SetMenuBar(mi_barra_de_menu); this->CreateStatusBar(2); this->SetStatusText(_("Welcome to wxWindows!")); }

Cuando elegimos salir en el men , se llama a este m tou e do que cierra la ventana. El m todo Close() no cierra la e ventana, sino que genera un evento wxCloseEvent, que de manera predeterminada cierra la ventana. Pero como hemos sobreimplementado la funci n virtual OnCloseWindow(), si o no cerramos nosotros explcitamente la ventana, nunca se cerrar . Eso es lo que vamos a hacer a continuaci n: a o
// Esta es una funcin virtual que hemos o // sobreescrito (para mostrar un mensaje // antes de cerrar la ventana) void MiVentana::OnCloseWindow(wxCommandEvent& event) { wxMessageBox(_("Goodbye world!"), _("Bye bye!"), wxOK|wxICON_INFORMATION, this); this->Destroy(); }

En este m todo, mostramos un di logo con un mensae a je de despedida. La primera cadena es el texto del di logo, a la segunda el ttulo del di logo. El tercer par metro es el a a estilo del di logo. En este caso, tendr un bot n Aceptar y a a o un icono de informaci n. El ultimo par metro es la ventao a na padre (un puntero a wxWindow). En este caso, la ventana padre es la ventana principal (this). Despu s de mostrar el e mensaje, cerramos la ventana. El m todo Destroy(), a difee rencia de Close(), no genera ning n evento, sino que cierra u denitivamente la ventana. Una caracterstica importante es que al cerrar una ven tana (o en general al destruir cualquier instancia de una clase de wxWindow, o de alguna derivada) el comportamiento predeterminado es cerrar todos los objetos hijos que existen en esa instancia. Esta es la raz n por la que no hemos o implementado un destructor para nuestra clase, ya que wxWindows se encarga de realizar el trabajo sucio, y ordenadamente destruir todos los objetos. Si no existiera esta caracterstica, y cerr ramos el objeto padre sin haber destruido a antes los hijos (con un destructor), obtendramos probable mente un error de violaci n de segmento. o
// Muestra el mensaje Hello world! void MiVentana::OnAbout(wxCommandEvent& event) { wxMessageBox(_("Hello world!"), _("Welcome to wxWindows!"),

Dentro del constructor, creamos un men con su ttulo, y u el estilo que indica que podremos desvincular el men de la u ventana, para crear un men otante (este estilo s lo es v liu o a do en wxGTK, que es la versi n para Linux de wxWindows o usando la biblioteca GTK). Despu s creamos una barra de e

wxOK|wxICON_INFORMATION, this); }

7.4. Ejecuci n y pantallazos o Si no creamos los cat logos de traducci n, se generar un a o a aviso de que no se han encontrado, y los textos aparecer n a tal y como est n en el c digo fuente. Aqu van algunos pana o tallazos (todos obtenidos con la versi n GTK): o

Este m todo muestra el mensaje Hello world!. e 7.1. Compilaci n en Windows o La mejor manera de compilarlo en Windows es mediante un makele:
WXDIR = $(WXWIN) TARGET=hola_mundo OBJECTS = $(TARGET).o include $(WXDIR)/src/makeprog.g95

Tiene que estar denida la variable de entorno WXWIN, que contiene el directorio donde est instalada la biblioteca. Para a compilar, es tan simple como:
make -f mi_makefile

Fig. 1. Mensaje de error (en este caso, wxGTK se compil en o espa ol porque la variable LANG estaba denida como es, y n por tanto este es su idioma por defecto)

Por supuesto, hemos supuesto que tenemos congurado bien el compilador (que se encuentra en la variable PATH, que hemos denido las variables de entorno C INCLUDE PATH, CPP INCLUDE PATH y LIBRARY PATH) y que hemos compilado ya la biblioteca. Es importante, en cualquier caso, leer la documentaci n de wxWindows, ya que al compilao dor Mingw le faltan algunos archivos para poder compilar wxWindows. Se pueden encontrar en un archivo llamado extra.zip, en la p gina de wxWindows. Adem s, hay a a que crear un archivo de recursos (hola mundo.rc) que contenga la lnea
#include "wx/msw/wx.rc"

Fig. 2. Opci n ID ABOUT (traducida) o

7.2. Compilaci n en Linux o Para compilar en Linux, es tan sencillo como escribir (cuidado, las tildes son hacia la derecha):
gcc -c wx-config --cflags hola_mundo.cpp gcc wx-config --libs -o hola_mundo hola_mundo.o

Fig. 3. Mensaje mostrado antes de salir (traducido) 7.3. Generaci n del cat logo de traducci n o a o Si tenemos instalado GetText, escribimos en el directorio de las fuentes:
xgettext -C -k_ *.h *.cpp

8. BIBLIOGRAFIA [1] Gerardo Aburruzaga Garca, Inmaculada Medina Bu lo, y Francisco Palomo Lozano, La biblioteca est ndar a de C. Servicio de Publicaciones de la Universidad de C diz, 1998. a

Una vez traducidas las cadenas de texto, lo compilamos con:

msgfmt messages.po -o messages.mo

Copiamos el archivo generado al subdirectorio es dentro de nuestro directorio home, y ejecutamos el programa. Todas las cadenas que hayamos traducido en el cat logo, estar n a a traducidas en la aplicaci n. Opcionalmente tambi n podeo e mos compilar el cat logo es.po del subdirectorio locale a de wxWindows y copiarlo junto a nuestro cat logo. a

INTRODUCCIN AL DISEO EN GNU/LINUX Jos Alberto Surez Lpez <bass@adala.org> www.adala.org

RESUMEN Diseo en GNU/Linux o Introduccin a herramientas de diseo en Linux. Introduccin y uso bsico de distintas herramientas para el diseador grco en Linux. Haremos un repaso por las herramientas indispensables para cualquier artista y sus nombres en Linux. Tales como: Raster (The Gimp), Vectorial (SodiPodi), Maquetacin (Scribus), Raster a Vector (autotrace) y Web (gnif). Incluso se podra mencionar el diseo 3D (blender) Tambin se hablar de su posible uso profesional. Hoy en da a Linux an le quedan muchas metas que alcanzar, y estas estn ligadas al escritorio. No basta que tengamos Gnome/KDE, pur muy fcil y bonitos que sean no debemos olvidar que Ms-Windows sigue siendo mucho ms rpido y ligero cara al usuario nal, sin olvidarnos de MacOs X. Uno de los mayores vacios en Linux son los referentes a grcos, en especial creacin y edicin profesional. En todo taller de Pre-Impresin serio no faltan herramientas de: Raster (PhotoShop), Vectorial (Illustrator), Maquetacin (QuarkXpress) y un convertidor de raster a vectorial. Y adems no podemos olvidar las nuevas tecnologas y las herramientas que no faltan en el ordenador de un diseador, como son: DreamWeaver (diseo Web) y el ya consagrado Flash (ambos de Macromedia). No hay ni que decir que un estudio serio no usa windows, si no MacOs ya que adems de poseer estabilidad, seguridad, y rpidez es muy afable cara al usuario nal (no olvidemos que hablamos del Unix ms vendido). Todos estos productos son de una gran calidad y abilidad, por no hablar del soporte tan apreciado por las empresas. 1. CULES SON LAS PEGAS? El problema de todo esta gran paquete de software, de indudable calidad, son los elevados precios de sus licencias, por no hablar de lo caro que resulta mantener actualizado un equipo PPC (ordenador Apple). Esto en realidad no es ningn problema para empresas grandes del sector (que las hay y son bastantes). El problema viene cuando las estadsticas nos dicen que en espaa la mayora de las empresas son PYMES de poco ms de dos empleados, las cuales ni por asomo se pueden permitir un PPC actualizado y mucho menos del orden de cinco licencias con precios muy altos, los cuales oscilan entre los 1300 Euros, y los 5000 Euros. 2. LLEGA EL SOFTWARE LIBRE La solucin a este problema pasa por usar Software Libre, ya que disminuira sensiblemente el coste tanto del mantenimiento de Hardware como de Software. La cuestin es: tenemos alternativas de calidad para los productos necesarios? La respuesta es sin duda: S, pero no. Ya que cada producto tiene sus ventajas, sus inconvenientes, y sobre todo sus faltas. En este momento casi ningn producto (por no decir ningno) dentro del software libre es comparable con el comercial, que por otra parte estan altamente integrados en las empresas. 3. LAS ALTERNATIVAS Hemos hablado de los distintos tipos de aplicaciones necesarias en un estudio de diseo o taller de pre-impresin (la diferencia entre ambos es que el taller de pre-impresin se centra casi exclusivamente en trabajos de diseo para su uso en papel, el cual diere mucho de su uso digital). Vamos a indagar un poco ms en los distintos tipos. 3.1. Diseo Raster Raster bsicamente signica que se trabaja en una imgen 2D formada por pixels (puntos), y son reconozibles fcilmente ya que por ejemplo un raster es un jpg, un png, etc. Sin duda la estrella en este tipo de herramientas es PhotoShop de Adobe, el cual es realmente muy bueno, y prcticamente un standard. En el mundo del software libre la gran estrella es The Gimp (el programa de manipulacin de imgenes GNU) [1]. Gimp fue creado por Peter Mattis y Spencer Kimball, que a su vez crearon las libreras GTK ya que ninguna de las existentes en aquel momento les gustaba. Ahora tanto GTK, como Gimp son buques insignia del software libre, gracias a su gran calidad. Gimp nos permite tanto editar fotografas o imgenes, como crear las nuestras propias. Es muy modular y tiene una gran cantidad de herramientas para la edicin

2D. Dicho de otra forma lo mismo puedes quitar los ojos rojos de una foto que crear un logotipo. Gimp [2] es una gran y real alternativa a PhotoShop en especial a lo referido en diseo digital. Sus motores son de una calidad comparables. Ciertamente es apto para un uso profesional, aunque desafortunadamente carezca de algunas facilidades que se encuentran en el afamado PhotoShop. El gran problema es el diseo para papel (pre-impresin), ya que Gimp (en su versin actual y al parecer en la prxima tampoco) no tiene soporte para CYMK, que es el sistema de color usado en imprentas, ya que solo una pequea parte de los colores RGB (digital, monitor) son reproducibles en una imprenta. El otro gran problema es la falta de la paleta Pantone. Pantone es un sistema de color usado en las imprentas que se basa en el uso de inmensas paletas con grandes gamas de colores ya predenidos, los cuales te aseguran que en la imprenta sern reproducibles. Realmente que Gimp use Pantone se antoja complicado, ya que pantone es un sistema registrado y todos los programas que lo implementen deben pagar su respectivo canon. -Como se puede salvar esto?- Siempre esta la opcion de usar RGB en el Gimp y una vez en la propia imprenta dedicarse a sealar con el dedo de que color es cada zona. Conclusin: Gimp es comparable en calidad a PhotoShop, y su uso profesional es viable en el mundo digital, pero a la hora de la impresin en papel puede causar ms de un quebradero de cabeza.

3.3. Raster a Vector Como su nombre indica son aplicaciones que transforman una imgen raster (png) a una imgen vectorial. Profesionalmente de esto se ancarga el propio programa de diseo vectorial, ya sea FreeHand, Illustrator, o cualquier otro. Pero en el software Libre tenemos que irnos a autotrace. Autotrace [5] comenz siendo un plugin para The Gimp, pero ahora es un programa independiente el cual realmente da bastante calidad, aunque cuesta trabajo hacerse a su modo de trabajo. Le falta an mejorar en algunos aspectos, y se hecha de menos en falta su integracin con algn otro programa q le proporcione una interface grca, como sodipodi. ACTUALIZACIN: Sodipodi en sus ltimas versiones es capaz de implementar Autotrace por lo que facilita bastante el uso de este. Creo que puede ser usado profesionalmente, pero con bastante cuidado. 3.4. Maquetacin Maqutar es dar forma, es ordenar una publicacin y prepararla para su impresin. Los programas de maquetacin usan tanto elementos vectoriales como raster, adems de los suyos propios. Al maquetar tenemos total control sobre lo escrito o la imgenes, y por supuesto el resultado nal. Profesionalmente el rey es QuarkXpress seguido de Adobe PageMaker ya casi sustituido por Indesign de Adobe. En el mundo de software libre hay realmente pocas alternativas. La ms conocida y desarrollada, aunque an le falta mucho, es Scribus, basado en las libreras Qt. Aunque hace poco ha comenzado el desarrollo en Gnome-es de GnoPress [7]. Scribus [6] es una aplicacin realmente bastante parecida en su concepcin a QuarkXpress, pero an bastante inestable, adems le faltan bastantes herramientas y utilidades de los programas profesionales. Conlusin, puede ser usado para la publicacin de trabajos no demasiados complejos, pero an le falta bastante trabajo para ser considerado profesional, sobre todo en lo relacionado a la interface. 3.5. Diseo Web Disear una web no quiere decir necesariamente programarla, ya que el diseador no tiene porque conocer html (por muy fcil que sea). Normalmente para disear una web se plasma con un programa de diseo raster como El Gimp y ms tarde se usa otro programa para hacer un html. Profesionalmente lo ms usado es PhotoShop + DreamWeaver. Dreamweaver casi hace que deje de ser necesario el uso de photoshop, exepto para las imgenes, ya que te permite ir dibujando la web sin necesidad de conocimientos de programacin y de una manera muy sencilla y exible a la par

3.2. Diseo Vectorial Bsicamente se basa en el uso de vectores, osea puntos denidos por coordenadas 2D, que pueden unirse para formar lneas o guras geomtricas. La gran ventaja es que dichos puntos pueden ser modicados y editados una y otra vez sin perdida de calidad. Profesionalmente lo ms usado es Adobe Illustrator o Macromedia FreeHand programas ambos de una gran calidad. En lo referido a SL este es uno de los puntos ms ojos. Los programas ms usados son sketch y sodipodi. Los dos en especial sodipodi estan an en fase de desarrollo. Sodipodi [3] tiene una gran futuro, una interfaz realmente cmoda pero tiene muy poca estabilidad, y an le faltan una gran cantidad de utilidades por implementar. Pero realmente est obteniendo un gran apoyo y avance. En cuanto a sketch [4] tiene grandes deciencias, sobre todo en su interfaces y sus herramientas, aunque caba destacar el que es capaz de usar el formato de Illustrator, aunqe no 100 % bien. Lamentablemente estas aplicaciones no estn an preparadas para su uso profesional, aunque siempre pueden sacar del paso.

que potente. En el SL no tenemos nada comparable, aunque contamos con herramientas de programacin web muy buenas como Quanta [8] o BlueFish [9]. Pero necesitan que el cdigo sea escrito para mostrar un resultado. En otra parte tenemos el Mozilla-Composer [10] el cual permite ir haciendo al web sin siquiera ver el cdigo, pero no con la potencia y exibilidad de dreamweaver, adems de ser realmente pesado y lento. La otra opcin, bastante mejor, es GINF [11] (Ginf is not FrontPage) el cual no deja de ser un composer basado en gnome y gtkhtml, pero con cosas bastante interesantes, pero an es demasiado inestable y le falta mucho camino para llegar a la calidad y exibilidad de Dreamweaver. Yo apuesto por la integracin del editor y herramientas de bluesh y GINF. El uso profesional es bastante dicil, aunque siempre dependera de la web a realizar, ya que se pueden obtener resultados muy curiosos y elaborados. La otra gran estrella del diseo web es la tecnologa Flash, la cuel permite, literlamente, dibujar e incluso animar y hacer interactiva una web con bastante facilidad, adems esta basado en diseo vectorial. Pero desgraciadamente en Linux no hay ninguna herramienta que permita hacer webs en ash. Aunque hay algunos scripts que te permiten generar algunas cosas en ash, e incluso se puede crear ash a traves del PHP. 3.6. Diseo 3D Las herramientas profesionales ms afamadas son sin duda SofImage y Maya, sin olvidar 3DStudio, aunqe este ltimo es un jugete comparado con los otros dos. Tanto SoftImage como Maya como otras aplicaciones profesionales de gran calidad tienen versiones para *NIX, ya que profesionalmente se usa Linux para la creacin de animaciones y diseos 3D. En el mundo del SL contamos con Blender [12], el cual aunque an no tenga la calidad de sus competidores es un serio aspirante y puede ser usado profesionalmente en ciertas circustancias. 4. BIBLIOGRAFA 1. http://www.gimp.org 2. http://gimp.es.gnome.org 3. http://sodipodi.sf.net 4. http://sketch.sf.net 5. http://autotrace.sf.net 6. http://web2.altmuehlnet.de/fschmid/ 7. http://gnopress.es.gnome.org/es/ 8. http://quanta.sf.net 9. http://bluesh.openofce.nl/ 10. http://www.mozilla.org

11. http://www.symonds.net/~deep/stuff/vtu/ginf/index.html 12. http://www.blender.nl

 PROYECTO GESTION LIBRE DE HISPALINUX; UNA OPORTUNIDAD PARA TODOS Fernando A. Acero Martn Coordinador del proyecto Gesti n Libre o
RESUMEN El proyecto Gesti n Libre de HispaLinux intenta hacer o atractivo para la comunidad de programadores de software libre, el desarrollo de aplicaciones de gesti n para la Admio nistraci n y las empresas. Para lograrlo, HispaLinux propoo ne crear una base de datos de conocimiento, basada en an lia sis funcionales, con todo lo que pueda necesitar la comunidad de software libre al desarrollar aplicaciones de gesti n o para la Administraci n y las empresas. o 1. INTRODUCCION Ante sus evidentes ventajas, el software libre est coa menzando a despertar el inter s de la Administraci n y las e o empresas. Desgraciadamente, a pesar de los enormes benecios que puede reportar el software libre la sociedad en general, se est haciendo muy difcil su implantaci n por la a o escasez de aplicaciones de gesti n. Si consideramos que las o ventajas del software libre deben tener su eco en la sociedad y no quedar restringidas a la comunidad que lo ha hecho posible, es b sico que esta comunidad ayude a crear el softwaa re de gesti n que necesitan la Administraci n y las empreo o sas. Para lograr este objetivo tan interesante, puede ser de gran ayuda que la Administraci n y las empresas expresen o sus necesidades de gesti n usando un lenguaje formal que o pueda ser entendido por los programadores de la comunidad de software libre. Partiendo de esta idea tan simple, se puede buscar un punto de encuentro y un lenguaje com n, u en los an lisis funcionales. a Debemos tener en cuenta, que aunque los an lisis funa cionales implican un modelo de desarrollo m s formal, no a suponen un cambio radical en los m todos y costumbres de e la comunidad de c digo abierto. Solamente representan una o matizaci n en la forma de desarrollar el software de gesti n. o o De hecho, es algo que ya se est implantando en algunos a proyectos de software libre de gran envergadura, pero de forma restringida al equipo de trabajo que los lleva a cabo. Este modelo implica la necesidad de capacitar a los programadores en el uso de los an lisis funcionales, algo que a tambi n habr que atender en el proyecto. Sin embargo, con e a este peque o coste educativo, logramos potenciar y optimin zar las caractersticas positivas de la comunidad de software libre en un momento en el que puede ser interesante responder a las necesidades de la Administraci n y las empresas. o Estos an lisis funcionales seguir n un proceso similar al que a a se usa actualmente con el c digo fuente, ser n depurados y o a despu s de la liberaci n de una versi n estable, ser n utilie o o a zados para el desarrollo de las aplicaciones de gesti n. o 2. ANALISIS INICIAL En la actualidad, hay dos nichos de mercado que son muy interesantes de informatizar con software libre, las pymes y los ayuntamientos de menos de 50.000 habitantes. En estos dos ambitos, por falta de recursos econ micos, es freo cuente que no se recurra a soluciones basadas en la programaci n a medida y se utilicen aplicaciones llave en mano, o mucho m s econ micas y r pidas de implementar. A la vista a o a de ello, podra ser interesante cubrir estas necesidades con software libre de unas caractersticas similares, pero perso nalizable y con un buen soporte. Si se logra este objetivo inicial, incluso se podra conseguir un mejor sostenimien to de la comunidad de software libre, lo que tambi n puede e contribuir a mejorar el PIB nacional o europeo. Aqu nos encontramos ante unas economas de escala, en las que un peque o esfuerzo de prograramaci n, abre un mercado de n o grandes dimensiones. Para hacernos una idea de este mercado en Espa a, podemos decir que las pymes representan n el 80 por ciento de las empresas espa olas, mueven el 90 n por ciento del PIB y reciben una gran cantidad de ayudas ociales. A pesar de las ventajas que tiene el mercado del que hemos hablado antes, los programadores de software libre encuentran algunos problemas para desarrollar programas de gesti n. Por ejemplo, es frecuente que el programador de o software libre tenga que controlar y ejecutar por el mismo todos los pasos y procesos de la implementaci n del softo ware. Este hecho complica enormemente el desarrollo de aplicaciones no relacionadas directamente con la comunidad de software libre. Con el sistema de desarrollo actual, tienen que concurrir una gran cantidad de factores para que aparezca una aplicaci n de gesti n v lida. o o a Es evidente que no todo el mundo tiene el tiempo, los conocimientos o el acceso necesario a la Administraci n o o a las empresas, para poder realizar un buen an lisis funa cional. Adem s, si el proyecto resulta se muy complejo y a

no se dispone de an lisis funcionales, es posible que no se a pueda llevar a cabo y acabe siendo abandonado, impidiendo adem s, que otros programadores lo puedan retomar por las a carencias en la documentaci n. Hay que destacar que alguo nos intentos de desarrollo de aplicaciones de gesti n libres, o por no contar con unos buenos an lisis funcionales, est n a a muy limitadas y no responden a las necesidades reales del mercado. Esta dicultad para acceder a los an lisis de las aplicaa ciones de gesti n, provoca que muchos programadores de o c digo abierto se dediquen a trabajar en proyectos relacioo nados directamente con el sistema operativo y sus utilidades. Programadores que podran dedicarse a proyectos re lacionados con las empresas o la Administraci n, que puo dieran ser m s interesantes profesional o econ micamente. a o Quiz s sea el momento de pensar en el sistema operativo a como una va para el desarrollo de aplicaciones, en lugar de considerarlo como la nalidad ultima de la comunidad de software libre. No quiero decir que se abandone el desarrollo y la mejora del sistema operativo, pero puede ser interesante dar algo de prioridad a ciertas tareas estrat gicas, e que pueden expandir las posibilidades del software libre y abrir otros caminos interesantes para la sociedad y para la comunidad de software libre. Por todo lo que hemos dicho, el proyecto Gesti n Lio bre se maniesta muy interesante para muchos colectivos y en especial, el de los estudiantes. Este colectivo es posible que sea el que tenga m s dicultades para realizar an lisis a a funcionales o aplicaciones de gesti n realistas y utilizables. o En la mayora de los casos, los trabajos de los estudiantes de inform tica, adem s de no estar orientados al software a a libre, tampoco est n orientados a casos reales, por lo que a tienen un limitado valor pedag gico y no facilitan su inteo graci n laboral. Si proporcionamos a los estudiantes el mao terial de Gesti n Libre, podran basar sus pr cticas en el o a desarrollo de estas aplicaciones, lo que puede implicar unos enormes benecios para ellos y para la sociedad en general. Por si fuera poco, los programas que elaboren en sus pr ctia cas tendr n el exito asegurado por responder a necesidades a reales del mercado. hay una mejor forma de inserci n lao boral, de auto-promoci n profesional o de realizar pr cticas o a realistas? Adem s, si consideramos que el software softwaa re libre no es lo mismo que software gratis, usando estos trabajos, se podran crear empresas de base tecnol gica en o la universidad, que podran nanciar estudios y desarrollos posteriores. En nuestro an lisis no debe faltar la posible inuencia a que tiene la ausencia de este tipo de aplicaciones en las empresas dedicadas a la comercializaci n de software libre. o Muchos indicadores muestran que el mercado del software libre, considerado atpico por unos y condenado al fraca so por otros, est n acusando una carencia de aplicaciones a especcas para la Administraci n y empresas, en las que o

basar negocios de soporte y mantenimiento. Estas empresas est n acusando la dicultades de vivir solamente de las a oportunidades de negocio que les brinda el sistema operativo y sus herramientas y en especial, del mercado de los servidores. Sin un software de gesti n de uso general, en o muchos nichos del mercado empresarial y de la Administraci n, solamente se implantar n soluciones parciales o mixo a tas. Esto signica que por cada servidor que funcione con software libre, aparecer n un gran n mero de estaciones de a u trabajo funcionando con software propietario. Como referencia adiconal, tenemos el resultado de algunas estadsti cas realizadas sobre el mercado del software libre. En ellas se indica que aunque muchas empresas tienen la certeza de que el software libre es mejor y m s estable, pero uno de a los principales problemas para su adopci n se centra en la o ausencia de software de gesti n de bajo coste y r pida imo a plantaci n. o 2.1. Las licencias para los an lisis funcionales a Antes hemos dicho que los an lisis funcionales pueden a tener una licencia libre, pero tenemos que considerar que no hay ninguna licencia de la FSF (Free Software Foundation) que se encuentre especialmente dise ada para los n an lisis funcionales. Lo ideal sera conseguir una f rmula a o legal, v lida en Europa, para que todo los trabajos derivados a del uso de an lisis funcionales libres tambi n sean libres, de a e forma similar a lo que ocurre con el c digo fuente. o Por lo general y a la espera de poder disponer de una licencia adecuada en el ambito nacional o europeo, los tipos de licencia que se pueden aplicar a los an lisis funcionaa les depender n de su formato, contenido y alcance. De este a modo, si los an lisis se encuentran contenidos en documena tos de texto y contemplan conceptos generales de la creaci n del software, se les puede aplicar una licencia GDFL o de acuerdo con la Ley de la Propiedad Intelectual. Sin embargo, si los an lisis se creen con herramientas de modelado a basadas en UML (Unied Modelling Languaje), M trica 3 e o similares, que se encuentran cercanos al c digo fuente, o podran liberarse con licencia GPL. El uso de estas licencias con su efecto vrico, pueden su poner una ventaja estrat gica y una garanta adicional, cuane do se aplican a los an lisis funcionales como paso previo a a la codicaci n de los programas. o 2.2. El caso particular de la Administraci n o Las necesidades de gesti n de la Administraci n son o o mucho m s difciles de analizar y conocer por la comunidad a de software libre. Para solucionar este problema, es posible que la unica soluci n est en que la Administraci n proporo e o cione sus necesidades, en la forma de an lisis funcionales, a a la comunidad de software libre.

Tambi n debemos considerar que algunas iniciativas gue bernamentales basadas en las nuevas tecnologas y dotadas de interesantes asignaciones econ micas, se podran mateo rializar con software libre si se tuvieran proyectos viables. Gesti n Libre, con sus caractersticas unicas, puede ser una o perfecta incubadora para proyectos en los campos de las tecnologas de la informaci n, desarrollo econ mico, apoyo o o a las pymes, apoyo a las corporaciones locales, e-learning, etc. 2.3. Las ventajas del uso del software libre Entre las ventajas de utilizar software libre encontramos las siguientes: * Permite la libertad de elecci n del software, hardware, o soporte, formaci n y servicios. o * Protege la inversi n en software, hardware, soporte, o formaci n y servicios. o * Mejora la relaci n calidad/precio del software, hardo ware, formaci n y servicios. o * Garantiza la comunicaci n e interoperabilidad de aplio caciones. * Mejora la seguridad. * Favorece la privacidad. * Permite el enriquecimiento tecnol gico y econ mico o o del pas. * Permite la escalabilidad y adaptabilidad de las aplicaciones. * Permite invertir en lo que realmente interesa, es decir, en la gesti n, evitando los gastos en licencias. o * Aumenta la productividad a la hora de crear software. * Permite el desarrollo de las ideas propias para la administraci n o el negocio. o * Minimiza el impacto de los c digos maliciosos. o Si reexionamos sobre la lista anterior, veremos que algunas de estas ventajas, podran ser argumento suciente para impulsar y promocionar el uso del software libre en la Administraci n y en las empresas. En HispaLinux estamos o convencidos de que el software libre es la unica alternativa para conseguir muchos de los objetivos de una Administraci n moderna y una mayor competitividad de las empresas. o 3. ANALISIS DE LAS LIBERTADES Y DEL MODELO DE DESARROLLO Hemos analizado algunas cuestiones relativas a la creaci n de software de gesti n libre para la Administraci n y o o o las empresas. Entre otras cosas, hemos justicado la necesidad de usar an lisis funcionales, hemos hablado de las bona dades del software libre y hemos comentado la dicultad que tienen la realizaci n de algunos an lisis. Pero al maro a gen de las dicultades que tiene la comunidad de software

libre para saber lo que necesitan la Administraci n y las emo presas, puede haber otros problemas intrnsecos a la comu nidad, que diculten o impidan la creaci n de estas aplicao ciones de gesti n. Comenzaremos analizando las libertades o que denen al software libre y su posible inuencia a la hora de crear aplicaciones de gesti n. o 3.1. Las caractersticas del software libre El software libre tiene una serie de caractersticas unicas y que lo diferencian del software propietario, que se materializan en cuatro libertades b sicas: a 1) Libertad para ejecutar el programa con cualquier prop sio to. 2) Libertad para estudiar el programa y adaptarlo a sus necesidades. 3) Libertad para distribuir copias. 4) Libertad para mejorar el programa y liberar las mejoras, con lo que se benecia toda la comunidad. Para ello, es necesario disponer del c digo fuente. o 3.2. Necesitamos los an lisis para avanzar a son sucientes las libertades de la licencia GPL para el desarrollo y evoluci n del software libre? Desde el punto o de vista pr ctico, si consideramos que las aplicaciones moa dernas est n formadas por una gran cantidad de lneas de a c digo, que son el fruto de a os de evoluci n y de la coo n o laboraci n de mucha gente, podemos pensar que el c digo o o fuente puede no ser demasiado util como para conocer el funcionamiento de un programa. Para entender y facilitar la colaboraci n en grandes proyectos de software, es indiso pensable disponer de una buena documentaci n que debera o incluir los an lisis funcionales y las especicaciones de rea quisitos. En la mayora de los proyectos actuales no estamos tra bajando con una simple utilidad de consola formada unos cientos o miles de lneas de programa, trabajamos con pro gramas mucho m s complejos y hablamos de cientos de mia les o de millones de lneas de c digo. En muchas ocasiones o es necesario contar una gran cantidad de programadores, pero sin una documentaci n adecuada, es difcil fragmentar o las tareas y avanzar con rapidez. Adem s, la exigencia de disponer del c digo fuente puea o de que no proporcione toda la libertad que creemos tener. Por ejemplo, que se nos proporcione del c digo fuente de o un programa, en un lenguaje de programaci n que no conoo cemos, tampoco nos servira de mucho. De nuevo, disponer de an lisis funcionales podra paliar este problema, permia tiendo que un programador pueda usar el lenguaje que mejor se adapte a sus gustos o conocimientos. Plataformas de desarrollo avanzadas, como MONO, en las que un ejecutable puede estar formado por c digo en varios lenguajes, o ayudar n a evidenciar esta necesidad. a

Por los motivos anteriores, podemos considerar que para poder desarrollar ciertos tipos de aplicaciones, entre las que se encuentran las de gesti n, adem s del c digo fuente, neo a o cesitamos los an lisis funcionales para poder hablar de una a aut ntica libertad. Es posible que las libertades del software e libre acaben teniendo en cuenta los an lisis funcionales, pea ro hasta ese momento, podemos intentar aplicarlos cuando lo consideremos conveniente. 3.3. El modelo de desarrollo del software libre Al margen de las posibles limitaciones que encontramos en las libertades del software libre, tambi n podemos analie zar las posibles consecuencias del modelo de desarrollo del software libre. El modelo de desarrollo tradicional del soft ware libre tiene una serie de caractersticas unicas que han permitido la creaci n de un sistema operativo s lido y muy o o completo. Desgraciadamente, algunas de estas caractersti cas, que en su momento fueron positivas, puede que no favorezcan la aparici n de ciertos tipos de aplicaciones, entre o las que se encuentran las de gesti n. Sin embargo, algunos o de estos problemas se pueden eliminar o minimizar usando an lisis funcionales en el desarrollo. Veamos algunas de a las caractersticas del modelo de desarrollo tradicional y sus posibles problemas. * El sistema de desarrollo est basado en modelos evolua tivos y en conocimientos nebulares. Es posible que algunas habilidades y conocimientos necesarios para la elaboraci n o de determindos programas no se encuentren en el seno de la comunidad. Los an lisis funcionales pueden paliar este a problema, abriendo una va de introducci n de estos cono o cimientos. * El software se crea mediante la colaboraci n y la ceo si n de conocimientos, pero en grandes aplicaciones. Sin o una documentaci n adecuada, se hace difcil esta colaboo raci n y cesi n de conocimientos. De nuevo, los an lisis o o a funcionales pueden ser la soluci n. o * Las herramientas de desarrollo son econ micas y tieo nen una calidad t cnica adecuada. e * Hay un gran n mero de programadores y muy comu petentes, pero sin una estructura vertebrada. La utilizaci n o de an lisis funcionales puede ayudar a organizar mejor el a trabajo y facilitar su repartici n entre los participantes. o * Hay demasiada entropa y caos al decidir lo que se de sarrolla y sobre la forma de hacerlo. La existencia de an lia sis funcionales podra hacer atractiva para los programado res, la creaci n de determinadas aplicaciones que se consio deran necesarias. * Los programadores suelen trabajar a tiempo parcial y puede que no reciban una remuneraci n por su trabajo. La o utilizaci n de an lisis funcionales ayudara a unir la oferta o a con la demanda, facilitando la apertura de canales de remuneraci n para los programadores. o

3.4. Otros problemas que se han detectado En la historia reciente del software libre se han producido intentos para la creaci n de aplicaciones de gesti n, o o principalmente para empresas, que no han acabado materializ ndose en programas. Por ello, hemos considerado interea sante analizar las posibles causas que han motivado algunos de estos fracasos y las conclusiones son las siguientes: * El programador se debe encargar del ciclo completo del desarrollo. * El software aparece como resultado de una serie de casualidades, por lo que no siempre se desarrolla lo que hace falta. * Hay problemas de comunicaci n y mantenimiento en o los proyectos grandes. * Cuando hay problemas de continuidad o se trabaja a tiempo parcial y no existe una documentaci n adecuada, el o proyecto puede desaparecer. * Los programadores tienen pocos alicientes econ mio cos. * Cuando los an lisis no son buenos o no existen, las a aplicaciones puede tener problemas de compatibilidad o de ecacia, que limitan sus posibilidades. Estos problemas de compatibilidad est n agravados por el amplio abanico de a posibilidades disponibles que existe en el software libre. * El modelo evolutivo es poco util cuando se requieren resultados optimos desde el principio, como suele pasar con las aplicaciones de gesti n. o * Faltan herramientas y libreras especialmente dise adas n para la creaci n de aplicaciones de gesti n y para la migrao o ci n de datos. o 4. EL EFECTO DE LA PRESION QUE SE ESTA EJERCIENDO Vistas las ventajas enumeradas anteriormente, no cabe duda de que el software libre es algo muy conveniente para las empresas y la Administraci n, lo que nos mueve a ino tentar universalizar su uso. Un caso cercano lo tenemos en HispaLinux, que a trav s de las campa as de sus socios, ine n tenta implantar este software en la Administraci n y en las o empresas. Por una parte, tenemos una carencia de aplicaciones de gesti n de general para la Administraci n y las empresas o o y por otra, se est ejerciendo una gran presi n para lograr a o la implantaci n del software libre en estos ambitos y eso ta combinaci n, como veremos nos puede producir algunos o problemas. Como se dispone de argumentos s lidos, buenos y como partidos, esta presi n est teniendo un respuesta muy posio a tiva en la Administraci n y las empresas. Tanto e as, que o la Administraci n est comenzando a establecer iniciativas, o a basadas en software libre, con fechas lmite relativamente cercanas. Por las ventajas que ello supone, sera deseable

que todas o la mayora de estas iniciativas, se materializasen usando software libre y en las fechas previstas. Desgraciadamente, salvo algunas excepciones, es tradicional que la comunidad de software libre desarrolle las aplicaciones que necesita internamente, las que mejor conoce o las que m s a apetecen a sus autores. Por ello, podemos intentar buscar una f rmula para favorecer el desarrollo de aquellas aplicao ciones que realmente se necesitan. 4.1. Los logros reales y los efectos no deseados Por la presi n y sus notables caractersticas, el software o libre se est implantando con fuerza en el mercado de los a servidores, mercado en el que es casi un lder absoluto. Del mismo modo, m s lentamente y gracias en las mejoras en a los escritorios gr cos, en las herramientas de conguraci n a o y en las suites om ticas, tambi n est teniendo cierto exito a e a en las estaciones de trabajo om ticas. El problema aparece a cuando la presi n no encuentra aplicaciones gesti n que sao o tisfagan las espectativas. En ese caso se producen siguientes efectos no deseados: * Se est n generalizando las soluciones parciales o mixa tas, con servidores basados en software libre y clientes propietarios. * Se est n demostrando carencias que pueden llevar a a pensar que el software libre no es una soluci n tan buena o como se pretende. * Se est n cerrando nichos de mercado que luego ser muy a a difcil recuperar para el software libre. * La falta de credibilidad que se genera por la ausencia de aplicaciones, no favorece la aparici n de soluciones o integrales hardware+software+servicios. * Ante la ausencia de soluciones de software libre, algunas empresas se est n creando soluciones propietarias que a funcionan sobre plataformas de software libre, cerrando nichos de mercado al software libre. * Se favorecen las soluciones basadas en software a medida, en detrimento de las soluciones llave en mano. Por todo lo anterior y antes de que la situaci n se agrave o m s, se considera necesario tomar algunas medidas que faa vorezcan la aparici n de las aplicaciones de gesti n que se o o necesitan. 5. EL PROYECTO GESTION LIBRE Durante el estudio hemos visto que los an lisis funcioa nales pueden solucionar o paliar algunos de los problemas que se producen cuando queremos desarrollar aplicaciones de gesti n para la Administraci n y las empresas. Dada la o o importancia que tienen en el proyecto, es conveniente que hagamos un peque o resumen de las ventajas del uso de los n an lisis, en relaci n con el software libre. La utilizaci n de a o o an lisis funcionales nos permite: a

* La fragmentaci n de grandes proyectos. o * Independencia del lenguaje y una mejor comprensi n o del c digo fuente. o * La migraci n de las aplicaciones actuales a software o libre. * Mayor continuidad en el desarrollo y la recuperaci n o de proyectos. * Unir la demanda de aplicaciones con la programaci n o de las mismas, facilitando la remuneraci n de los trabajos. o * Una mayor estandarizaci n y la garanta de comunio caci n entre m dulos y aplicaciones. o o Una imagen m s creble y una metodologa de trabajo a m s rigurosa. a 5.1. Materializaci n del proyecto Gesti n Libre o o La materializaci n del proyecto Gesti n Libre es algo o o m s complejo que recomendar a los desarrolladores el uso a de los an lisis. De hecho, estos an lisis deberan ser propora a cionados por la Administraci n y las empresas interesadas o en la creaci n de estos programas. Lo que se intenta con o el proyecto, es que se convierta en un punto de encuentro de la Administraci n y las empresas con la comunidad de o software libre. Tambi n se intenta que el proyecto contenga e todo aquello que pueda necesitar el programador a la hora de desarrollar aplicaciones de gesti n, incluida su formao ci n integral. El proyecto, que se basa en el uso de an lisis o a funcionales, se materializa en una base de datos de conocimiento con los contenidos siguientes: * Herramientas de desarrollo adecuadas. * Informaci n util para los programadores, junto con la o normativa y la legislaci n aplicable. o * Documentaci n sobre temas de calidad, an lisis, deo a sarrollo, etc.. * Contenidos de formaci n especcos (e-learning). o * Criterios de desarrollo, especicaciones de requisitos y an lisis funcionales libres de aplicaciones de gesti n. a o 5.2. El proyecto Gesti n Libre es innovador o Es posible que el proyecto Gesti n Libre represente una o revoluci n dentro de la comunidad de software libre y entre o los motivos que avalan esta armaci n se encuentran los o siguientes: * Permite la participaci n de otros actores, como la Ado ministraci n y las empresas, para que colaboren en el desao rrollo del software libre que necesitan. * Tiene como objetivo la creaci n de software de calio dad, que se pueda homologar en base a la norma ISO 9000 u otras normas de calidad que se consideren interesantes. * Pretende crear aplicaciones de software, basadas en la arquitectura cliente/servidor, que sean escalables y personalizables. El cliente no se adaptar a la gesti n y en su lugar, a o

la gesti n se adaptar al cliente, algo casi imposible con el o a software propietario. * Se basa en que los an lisis funcionales sigan un procea so de desarrollo similar al del c digo fuente. Para lograrlo, o se usar n herramientas de modelado avanzado que generen a c digo UML o compatible con M trica 3, que es el est ndar o e a de la Administraci n. o * Explora las metodologas y las herramientas de desa rrollo de aplicaciones m s novedosas y potentes. a * Coloca en segundo plano el desarrollo nebular y darvinista tradicional del software libre, para centrarse en un modelo m s formal y eciente. a 5.3. Lo que permite el proyecto Gesti n Libre o El proyecto Gesti n Libre, al basarse en los an lisis funo a cionales, hereda todas las ventajas y posibilidades de estos, pero adem s, nos permite otras muchas m s cosas interea a santes, como por ejemplo: * Hace atractivo, para la comunidad de software libre, el desarrollo de las aplicaciones que necesitan la Administraci n y las empresas. Ayudando a comunicar a los proo gramadores aquello que demandan la Administraci n y las o empresas. * Favorece el desarrollo de software llave en mano, competitivo y econ mico. o * Permite denir herramientas y los criterios de desarrollo comunes. * Facilita el trabajo, reduciendo los tiempos y los costes. * Activa la economa en torno al software libre. * Favorece a programadores, estudiantes, Administraci n y empresas. o * Armoniza la presi n para la implantaci n del software o o libre con la oferta real de aplicaciones. 5.4. Lneas de actuaci n abiertas en la actualidad o El proyecto Gesti n Libre es muy ambicioso y exteno so, por lo que necesita mantener varias lneas de trabajo si mult neas. Para conseguir los objetivos en cada una de estas a lneas de trabajo, es imprescindible delegar en coordinado res de area, que dependiendo del coordinador general, se encarguen de los distintos aspectos del proyecto. Las lneas de trabajo que hay abiertas en la actualidad son: * Denici n y mantenimiento de los fundamentos y obo jetivos del proyecto. El proyecto se desarrolla como un sistema vivo y en constante evoluci n mediante la colaborao ci n en la lista de correo y en la web inversa de HispaLinux o (Wiki). * Creaci n y mantenimiento de fondos documentales: o A) ISO 9000. Se est n deniendo los procesos y se est a a

estudiando su compatibilidad con el modelo de desarrollo y las herramientas propuestas. La implantaci n de la ISO o 9000 se debe a la necesidad de crear aplicaciones de gesti n o de calidad. El proyecto no certica las aplicaciones, solamente entregar la documentaci n necesaria para permitir, a o si se desea, una certicaci n posterior. o B) An lisis funcionales y herramientas asociadas (UML, a dia, dia2code, umlmodeller, M trica 3, etc.). En este moe mento se est elaborando un libro de estilo de UML que a permitir acercar a n m s el c digo UML al c digo fuente, a u a o o introduciendo reglas m s estrictas. a C) Programaci n extrema. Aqu se est n evaluando y o a documentando algunas pr cticas que pueden ser compatia bles con el modelo de desarrollo propuesto. D) Herramientas de programaci n (PostgreSQL, libgda, o XML, etc.). E) Normativa y legislaci n aplicable a la gesti n de la o o Administraci n y las empresas. o * Plan de actividades en curso dentro del proyecto. En este plan de actividades destaca la colaboraci n de Hispao Linux, a trav s de Gesti n Libre y la Universidad de Le n, e o o en el Observatorio de Voto Electr nico (OVE). El objetivo o del OVE es explorar y fomentar la creaci n de un sistema o de voto electr nico basado en software libre. o * Repositorio de an lisis funcionales y de especicacioa nes de requisitos para la Administraci n y las Empresas. o * Sistema de e-learning (ense anza distribuida) orientan do a la formaci n de analistas y programadores de gesti n. o o La idea es la de lograr la capacitaci n plena de los prograo madores. Una de las metas propuestas, es la creaci n de un o master universitario orientado al desarrollo de aplicaciones de gesti n con software libre. El motivo de crear este gruo po de trabajo se deriva de la necesidad de formaci n de los o programadores, lo que entendemos que es fundamental para el proyecto. Para ello intentamos crear unos contenidos educativos especcos y muy pragm ticos, orientados a las a herramientas propuestas en el proyecto. 5.5. Relaci n entre los an lisis funcionales y los prograo a madores Aunque algunos de los an lisis se podran elaborar, en a el seno de la comunidad de software libre, la intenci n es o que estos an lisis sean aportados por la Administraci n y las a o empresas, usando repositorios organizados para ello. Como HispaLinux es una asociaci n sin animo de lucro, los equio pos de desarrollo, que pueden ser particulares o empresas de software libre, no est n contemplados en el proyecto. Rea cordemos que la idea de Gesti n Libre, no es la de realizar o aplicaciones de gesti n, es la de facilitar y hacer que sea o atractivo su desarrollo a la comunidad de software libre.

EL SOTWARE LIBRE COMO IMPULSOR DE LA INNOVACIN TECNOLGICA

Jos Mara Olmo Presidente de ndago

La Administracin es el mayor comprador de software en los pases occidentales. Este hecho repercute en que sta puede ejercer como cliente preferente, exigiendo determinados requisitos ante los proveedores en beneficio del Estado y de los ciudadanos. El software libre se convierte en el impulsor de la innovacin tecnolgica, ya que cuenta con un conjunto de ventajas que redundan en el inters, desarrollo y beneficio del conjunto de la sociedad, como son la disponibilidad de cdigo, la personalizacin, la adaptacin, al ahorro de costes, la independencia y la seguridad en la proteccin de datos.

puesto a disposicin de sus promotores una cantidad de dinero que supera los 24 millones de dlares para poner en marcha este centro en la ciudad norteamericana de Prtland. El objetivo de este laboratorio es el de facilitar los medios necesarios para que los diferentes desarrolladores de software libre, que se encuentran dispersos por todo el planeta, puedan poner en marcha sus ideas. Estas multinacionales del sector tecnolgico estn realizando una gran apuesta por el software libre. Han visto en GNU/Linux el modelo de desarrollo ms competente de creacin de tecnologa, incluso adaptando sus modelos de negocio y estrategias.

1. EL USO DEL SOFTWARE LIBRE El modelo de desarrollo de software libre, o el modelo cercano del Open Source, consiste fundamentalmente en la liberacin del cdigo fuente del software desarrollado, ofreciendo la libertad de modificar, ejecutar y usarlo sin tener que pagar licencias por ello. Este modelo fue propuesto por Richard Stallman en 1984 cuando inici el proyecto GNU y FSF. En la actualidad, determinados paquetes de software dis tribuidos en software libre se han convertido en los lderes indiscutibles de las infraestructuras de Internet: Servidor WWW Apache: 63 % de la cuota de servidores Web de Internet. Servidor de correo Sendmail: 35 % de la cuota de servidores de Correo de Internet. Servidores de Internet GNU/Linux: Existen millones de servidores en ISPs, universidades, empresas y organizaciones con software libre. 1.1. El apoyo de las grandes compaas Cada vez se percibe con ms claridad el prometedor futuro que tiene el software libre dentro de los entornos profesionales. Una prueba patente es la reciente creacin del primer laboratorio independiente de desarrollo de software libre. El OSDC (Open Source Development Laboratory) es una iniciativa sin nimo de lucro financiada por algunas de las empresas tecnolgicas ms importantes del mundo tales como Intel, IBM, Nec o HP que ha

2. VENTAJAS DEL OPEN SOURCE PARA EL SECTOR PBLICO La buena gestin de la informacin y la disponibilidad de sta son piezas clave para que las administraciones pblicas desempeen con xito las labores asociadas a la funcin de gobernar cualquier comunidad, ayuntamiento o corporacin. Analizaremos punto por punto cules son las ventajas que aporta el uso del software libre para la Administracin Pblica. 2.1. Optimizacin de la inversin En el software propietario una mayor parte de la inversin econmica recae sobre el coste de la licencia del producto, incrementando notablemente los costes y las partidas presupuestarias. Una gestin adecuada y el uso de GNU/Linux reducir notablemente este coste, ya que en el mundo del software libre no existen costes por licencia, teniendo adems el derecho para copiarlo las veces que sea necesario. 2.2. Independencia Al disponer del cdigo fuente del programa, cualquier empresa, proveedor o profesional puede ofrecer desarrollos o servicios para la aplicacin concreta. Con soluciones propietarias slo quien desarroll la aplicacin puede realizar estos servicios. La plataforma GNU/Linux fomenta la independencia del proveedor, ya que el propio

movimiento es el resultado de la colaboracin de miles de desarrolladores en todo el mundo. Con el software libre no se est supeditado a las condiciones del proveedor, ya que disponiendo el cdigo fuente el usuario puede continuar introduciendo mejoras del programa y ofrecer un programa de continuidad. El software libre puede ser utilizado perfectamente aunque la empresa que lo desarroll desapareciese, ya que cualquier profesional puede seguir mejorndolo y adaptndolo a las nuevas necesidades. 2.3. Seguridad nacional y privacidad de los datos La seguridad de los datos informticos se ha convertido en uno de los objetivos prioritarios de los estados. La Administracin debe proteger la confidencialidad y la proteccin de la informacin para garantizar los derechos y libertades fundamentales de los ciudadanos. Una deficiente seguridad informtica repercutir en la credibilidad de un estado, por lo que el software destinado a ser utilizado en las administraciones pblicas debe contar con un nivel de seguridad mximo. Los sistemas de almacenamiento y de recuperacin de la informacin son transparentes, ya que estos datos se almacenan en un determinado formato y no quedan ligados a sistemas cerrados tan habituales en el software de licencia propietaria. As se garantiza la perdurabilidad de la informacin. Adems, con el software libre existen menos posibilidades de introducir cdigo malicioso, espa o de control remoto. 2.4. Fiabilidad, escalabilidad y estabilidad La escalabilidad y estabilidad de GNU/ Linux son de sobra conocidas por cualquier profesional del sector de la informtica y Tecnologas de la Informacin. La plataforma GNU/Linux es una de las ms escalables del mercado. El sistema es capaz de adaptarse a cualquier tipo de solucin, abarcando desde aplicaciones sencillas que pueden ser instaladas en un PC de baja gama, hasta supercomputadores dedicados a la seguridad nacional, pasando por mltiples tipos de servidores, cluster, etc... 2.5. Fomento de la innovacin tecnolgica La posibilidad de modificar o adaptar el software libre permite la innovacin tecnolgica en un pas. Al disponer del cdigo fuente de la aplicacin, cualquier tcnico o empresa del pas puede realizar el desarrollo de las mejoras, no hay que encargarlas a empresas de otros pases. De esta manera, se contribuye a la formacin de profesionales de las nuevas tecnologas y al desarrollo local bajo propios planes estratgicos. Dado que las mejoras realizadas no tienen a su vez, restricciones, cualquier otra empresa, institucin o organismo pueden beneficiarse de las mejoras introducidas.

Por otra parte, actualmente, las lenguas minoritarias como el cataln, gallego o vasco, tienen pocas posibilidades de desarrollo en el mundo del software de licencia propietaria. En cambio, el software libre fomenta el desarrollo de la lengua autctona. Cualquier persona o institucin puede traducir o adaptar un software libre a la lengua propia , a diferencia del software propietario en el cual slo la empresa tiene los derechos para realizar la traduccin. La personalizacin llega hasta editar el software en el propio idioma con la posibilidad de correctores ortogrficos, diccionarios, programas personalizados...

Licencias

Adaptacin Implantacin Soporte y actualizacin Coste implantacin TI con software propietario

Adaptacin Implantacin Soporte y actualizacin Coste implantacin TI con software libre

Pongamos un ejemplo concreto: Supongamos un proyecto de informatizacin de 10.000 puestos de usuario. - Coste de un puesto de ofimtica con software propietario sin personalizacin: Sistema Operativo Paquete ofimtica Coste: 1.250.000 - 2.710.000 - Coste de un puesto de ofimtica con software libre sin personalizacin: Sistema Operativo Linux Paquete ofimtico: OpenOffice Escritorio: Gnome, KDE Coste: cero euros Segn fuentes del Consejo Superior de Informtica del MAP en la Administracin Pblica Espaola hay 310.000 ordenadores personales.

3. INICIATIVAS DE SOFTWARE LIBRE EN ALGUNOS GOBIERNOS DEL MUNDO Uno de las grandes contradicciones del Viejo Continente, es que pese a que Europa es especialista en el desarrollos de proyectos a medida, no compite con los grandes

lderes de software empaquetado americano. El uso del software libre en la Administracin puede convertirse en el elemento diferenciador que permitir a las empresas europeas, y particularmente a las espaolas, competir y relanzar la economa del pas. El software propietario, por lo general, no propicia un avance rpido de la tecnologa si no es por grandes empresas, que pueden frenar la innovacin por intereses econmicos. Por el contrario, el software libre potencia la incorporacin de nuevas tecnologas por parte de empresas pequeas, mientras que en el caso de la Administracin, puede promover la creacin de un sustrato de empresas tecnolgicas nacionales que se conviertan en motor del sector de las Tecnologas de la Informacin. Conscientes de la importancia de recortar distancias y reducir la brecha digital, los gobiernos de los pases menos favorecidos econmicamente han visto en el software libre una opcin para avanzar en materia tecnolgica. Casos como los de numerosos pases sudamericanos revelan la importancia y la consideracin de la que goza GNU/Linux, como un sistema barato, seguro, estable y escalable, ideal para dar soluciones a sus necesidades tecnolgicas ms elementales y afrontar la competitividad. Tal es el caso de Brasil, con el Proyecto de Ley 2269/99 recomendando que todos los niveles de gobierno, estatales, empresas pblicas y de economa mixta, utilizasen preferentemente programas abiertos, o el Proyecto Software Libre RS que aglutina a gobiernos, universidades, a la comunidad informtica y entidades sin nimo de lucro. El continente asitico tambin tiene en cuenta el uso del software libre. El ejecutivo coreano hizo pblica en fechas recientes la compra de 120.000 copias de una suite ofimtica en Linux, con el fin de reducir los costes de licencias y mantenimiento en un 80%. Con este gesto, el Gobierno de Sel pretende una reaccin en cadena que devenga en una utilizacin masiva del software libre en el continente asitico. Uno de los pases que apostar en un futuro prximo por Linux es China, que ha anunciado su deseo expreso de utilizar software libre como sistema operativo en el proceso de introduccin de tecnologa en el pas ms poblado de la Tierra, argumentando precio, seguridad y adaptabilidad, como los motivos que le han llevado a optar por el software libre.

4. MODELOS DE NEGOCIO CON SOFTWARE LIBRE Muchas empresas y organizaciones se plantean la siguiente pregunta: Si el software es libre cmo ganan las empresas que se apoyan en este modelo? Argumentaremos primero, que libre no significa gratis. Los beneficios de las compaas y consultoras cuyo modelo de negocio es el software libre, proceden principalmente de las adaptaciones de dicho software a las necesidades especficas del cliente y del soporte profesional que ofrecen a sus sistemas. 4.1. La evolucin de las empresas en tecnologa

4.2. Costes en proyectos bajo software libre El coste de desarrollo de un proyecto de Internet tiene tres ejes fundamentales: Los proyectos basados en licencias deben implicar un menor coste en desarrollo. Trabajar sin licencias permite acoger proyectos a medida a un coste asequible. La combinacin de licencias y adaptaciones costosas hace difcil la viabilidad de un proyecto. El proveedor de servicios debe encontrar para sus clientes la mejor combinacin para hacer su negocio viable. 4.3. Ejemplos de modelos de negocio Empresas de creacin de distribuciones de software. Empresas de soporte y consultora en software libre. Empresas de certificacin de sistemas. Empresas de adaptacin de SW Libre en empresas. 4.4. Valor aadido del software libre El modelo de software libre permite la colaboracin entre empresas. Repartiendo costes de desarrollo. Repartindose actividades del proceso: desarrollo, integracin, pruebas, documentacin, soporte, etc. Permite el desarrollo de pequeas empresas flexibles e innovadoras, debido a la menor inversin necesaria para montar equipos.

5. EL CASO PRCTICO DE LINEX Como en muchos gobiernos del mundo, la Administracin Pblica espaola est tratando de impulsar de manera activa el uso de las Tecnologas de la Informacin, tanto en lo que se refiere a la gestin de sus procesos internos como en lo relativo a la interaccin de los ciudadanos. El software libre, usado hasta ahora en los crculos de desarrolladores y usuarios ms expertos, se presenta como una alternativa eficaz y econmica para su implantacin en la Administracin. Pero aunque las iniciativas de software libre vayan calando muy lentamente en el sector pblico, la Administracin Pblica espaola est realizando apuestas muy firmes para la implantacin de GNU/Linux . Es el caso del Proyecto LinEx, uno de los proyectos pioneros de software libre en la administracin espaola y europea.

Este objetivo forma parte de otro mucho ms ambicioso: una completa alfabetizacin tecnolgica global que evite la brecha digital para que la ciudadana tenga libre acceso a las nuevas tecnologas, de forma sencilla. Ni el precio, ni la dificultad de uso podrn ser ya obstculos para que la mayora de los ciudadanos tengan acceso a las tecnologas, contribuyendo a la mejora de su calidad de vida. Esta alfabetizacin tecnolgica se est desarrollando en treinta y dos Centros de Conocimiento y escuelas extremeas ubicados en diferentes puntos de la comunidad autnoma tanto en el medio rural como en el urbano. Los usuarios de estos centros podrn manejar en sus domicilios, el mismo software que utilizan en estos centros, ya que podrn copiar el software de forma ilimitada. 5.2. Motivos para la eleccin del software libre El reto planteado por la Junta fue el de desarrollar una distribucin accesible a todos los ciudadanos, sin conocimientos especficos ms all de la informtica domstica. Para la elaboracin de esta distribucin ndago se traz como meta la simplificacin del programa de instalacin hasta el mnimo. El proceso se reduce a responder a una sencilla pregunta que aparece en la pantalla una vez que se ha insertado el CD: Desea instalar LinEX? S / NO. En caso afirmativo el sistema operativo se instala en el espacio disponible en el ordenador, manteniendo el sistema operativo existente y coexistiendo con l. 5.3. Cmo se hizo? Para la elaboracin de LinEx, ndago ha partido de desarrollos ya existentes con cdigo abierto. La disponibilidad del cdigo ha permitido la personalizacin de la solucin y el empaquetamiento de las aplicaciones en una sencilla distribucin. Como sistema operativo base se ha utilizado Debian, la distribucin de software ms completa del mundo con cerca de 9.000 paquetes de software y ms de 100 millones de lneas de cdigo. Sobre esta distribucin ndago ha desarrollado un programa de instalacin (hoy accesible bajo licencia GPL) y un entorno de escritorio con aplicaciones. La utilizacin de software existente ha posibilitado la creacin de un producto completo en un intervalo de tiempo reducido y a muy bajo coste. LinEx es una adaptacin del popular GNOME que es la aplicacin de escritorio de GNU/ Linux ms popular, de forma intuitiva y sencilla. La personalizacin ha llegado hasta crear un entorno adaptado a la comunidad extremea basado en su cultura y lugares representativos. La administracin extremea se ha decantado por el software libre debido a la inviabilidad de llevar a cabo un proyecto de semejantes caractersticas con sistemas

5.1. LinEx para todos En el mes de abril sali a la luz el Proyecto LinEx (Linux para Extremadura) en el que ndago ha estado presente desde sus orgenes en la concepcin, desarrollo y expansin. Esta iniciativa de la Junta de Extremadura se ha convertido en la primera realizada por una administracin europea, hacia el total de una ciudadana y crear una estela que servir de ejemplo para otros ejecutivos. A travs de esta iniciativa sin precedentes, la Junta de Extremadura ha presentado pblicamente una distribucin GNU/Linux, basada en Debian y GNOME, con una interfaz sencilla, para todo tipo de usuarios. Con el llamativo slogan S legal...copia LinEx, esta distribucin de software libre se ha colado en el disco duro de 80.000 ordenadores extremeos, pero puede expandirse libremente a muchos ms debido a que uno de los elementos consustanciales a LinEx es el derecho a copia y a la difusin de cualquiera de sus versiones. Un sistema de alfabetizacin tecnolgica para diferentes colectivos LinEx surge como una iniciativa impulsada por la Consejera de Educacin, Ciencia y Tecnologa de la Junta de Extremadura, cuyo principal objetivo radica en la prxima utilizacin de esta distribucin en la Red Tecnolgica Educativa y la Intranet extremea, que dotar a todas las escuelas con un ordenador por cada dos alumnos e interconectar todos los centros de carcter administrativo, educativo y sanitario de la comunidad autnoma con un ancho de banda de 2 Mbps.

propietarios. El ahorro asciende a ms de 54 millones de euros para los prximos tres aos. Pero adems del ahorro de costes, este ejecutivo autonmico se decant por la plataforma GNU/Linux ya que aporta alternativas tecnolgicas en terminales de usuarios, servidores de datos o en diferentes niveles de aplicaciones de Tecnologa de la Informacin. El proyecto LinEx se ha convertido en la alternativa tecnolgica para la educacin, el tejido empresarial y el entorno residencial. Se ha configurado como una completa suite tecnolgica destinada a cubrir las necesidades en el sector de la Tecnologa de Informacin. 5.4. Un estmulo para el desarrollo En el periodo que LinEx lleva en la calle, son muchas las reacciones de diferentes organismos y caudalosos los ros de tinta que han corrido entre la comunidad linuxera y prosoftware libre de nuestro pas. Pero no slo esta iniciativa es valorada aqu, sino que ha trascendido allende de nuestras fronteras, en los weblogs especializados, en los portales de linux e incluso en el Foro Internacional de Software Libre que se ha celebrado recientemente en Brasil. Este foro que aborda el estado de todos los sistemas de cdigo abierto, se ha convertido en el punto de encuentro de los investigadores ms punteros de software libre en el mundo, y la Junta de Extremadura ha sido un ejemplo de innovacin para todas las administraciones del planeta. Es uno de los pocos ejecutivos que pretende fomentar la innovacin tecnolgica mediante la participacin y la implicacin de toda su ciudadana. El modelo clsico de innovacin tecnolgica ha sido invertido por la Junta de Extremadura: se ha tratado primero de acercar a los ciudadanos una tecnologa sencilla, gratuita e intuitiva para elevar el nivel tecnolgico de una regin. Y esto comienza desde las bases, ya que el colectivo de la educacin (escuelas, centros de formacin, centros educativos) ser el ms implicado usando LinEx.

Adems de mostrar a los alumnos de los centros de enseanza y a los usuarios de los Nuevos Centros del Conocimiento, la existencia de otros sistemas operativos distintos al habitual, este proyecto trabajar por introducir el software libre en las empresas del sector, fomentando el enriquecimiento del tejido empresarial. Se abren as, nuevas vas de crecimiento a empresas de mbito local que potenciarn la expansin de emprendedores que elevarn la riqueza autctona de la comunidad autnoma. Elevar la demanda de este tipo aplicaciones entre el sector privado estimular el impulso de un subsector tecnolgico centrado en la creacin de aplicaciones informticas. El uso de soluciones basadas en software libre no es gratis, pero potencia el software legal y exige menos costes de produccin, permitiendo al tejido empresarial compuesto en un 95% de Pymes, beneficiarse de la instalacin de LinEx con un importante ahorro de costes. Adems, el uso de software libre entre las empresas extremeas potenciar un emergente ncleo de empresas que trabajan con GNU/Linux y ofertarn servicios basados en esta plataforma, por lo que un proyecto de estas caractersticas redundar en un impulso al empleo autctono. 5.5. Un modelo fcilmente exportable a otras comunidades autnomas La iniciativa de este modelo de insercin de la plataforma GNU/Linux en la comunidad extremea es extrapolable a otras comunidades autnomas, incluso a la administracin central, que repercutir en un ptimo uso de los fondos pblicos. Segn el informe REINA de este ao, las Administraciones Pblicas del Estado cuentan con un parque informativo de 310.000 ordenadores y 14.000 servidores que abastecen todo el sistema de red. Este grfico muestra el ahorro en euros que supondra para la Administracin la adopcin del modelo de Open Source.

N. Ordenadores 325.000

N. Servidores 14.000

Costes licencias 199 euros por equipo

Costes software propietario 900 euros por equipo

Costes modelo Open Source Coste bsico del equipo y adaptacin

USO DEL LENGUAJE XML PARA EL DESARROLLO DE SOFTWARE LIBRE Juan Isidoro Serrano Garca Ingeniero Superior de Telecomunicaci n o juan@adala.org
RESUMEN El presente artculo pretende introducir el lenguaje XML como una poderosa herramienta para el desarrollo del software libre. Para ello, se abordar la sintaxis de dicho lena guaje, y sus usos principales, destacando como lenguaje de intercambio de datos estructurados, usado sobre todo para manejo con bases de datos, as como lenguaje de almace namiento de interfaces gr cas, opciones de conguraci n, a o etc. De esta forma, el lenguaje XML se nos presenta como un util aliado para el desarrollo de aplicaciones con necesi dad de manejar datos estructuradamente. 1. INTRODUCCION XML signica lenguaje de marcas generalizado (Extensible Markup Language). Es un lenguaje usado para estructurar informaci n en un documento o en general en cualo quier chero que contenga texto, como por ejemplo cheros de conguraci n de un programa o una tabla de datos. Ha o ganado muchsima popularidad en los ultimos a os debido n a ser un est ndar abierto y libre, creado por el Consorcio a World Wide Web, W3C (los creadores de la www), en colaboraci n con un panel que incluye representantes de las o principales compa as productoras de software. n El XML fue propuesto en 1996, y la primera especicaci n apareci en 1998. Desde entonces su uso ha tenido un o o crecimiento acelerado, que se espera que contin e durante u los pr ximos a os. o n 1.1. Ventajas del XML Antes de ser lanzado el XML, ya existan otros lengua jes de marcas, como por ejemplo el HTML, basados en el lenguaje generalizado de marcas (SGML). El problema con el SGML es que por ser muy exible y muy general, se torna difcil el an lisis sint ctico de un documento y la especica a a ci n de la estructura. XML es m s exigente que SGML en o a la sintaxis, lo que hace m s f cil la construcci n de libreras a a o para procesarlo. Comparado con otros sistemas usados para crear documentos, el XML tiene la ventaja de poder ser m s exigente a en cuanto a la organizaci n del documento, lo cual resulta o A en documentos mejor estructurados. Por ejemplo, en L TEX, existen tambi n marcas que permiten estructurar un doe cumento, identicando el nombre del autor y el ttulo del documento (como, por ejemplo, los comandos author y title). Sin embargo no existe forma de obligar a los autores de documentos a que usen estas marcas, y algunos de ellos pueden introducir el ttulo de forma que apa rezca visualmente igual a lo que se obtiene cuando se usa author y maketitle, sin usar esos comandos; esto conlleva a problemas cuando queremos extraer de forma autom tica el ttulo de varios documentos. a Otra ventaja que posee XML, ademas de ser la particularidad m s importante del lenguaje, es que no posee marcas a prejadas con anterioridad, ya que es el propio dise ador n el que las crea a su antojo, dependiendo del contenido del documento. Adem s, XML es m s un sistema complejo de a a tratamiento de informaci n que un simple lenguaje de deso cripci n. XML es m s una familia de lenguajes, y al igual o a que podemos decir que HTML es un lenguaje, para ser exactos, hay que denir al XML como un metalenguaje, o sea, un lenguaje capaz de denir otros lenguajes. Por otra parte, el lenguaje XML es un estandar ampliamente reconocido [1] de libre utilizaci n. Ademas, es facilo mente procesable, separa radicalmente la informaci n o el o contenido de su presentaci n o formato y permite poderosas o t cnicas de extracci n de informaci n. e o o 2. CONCEPTOS BASICOS DEL LENGUAJE XML Los cheros XML son cheros de texto (normalmente con extensi n .xml), identicados inequvocamente por la o primera lnea de texto del chero, que indica que dicho chero es un chero XML. Estos cheros en principio se codican mediante c digo Unicode, pero se pueden usar otros o alfabetos, como el latin-1. ?xml version=1.0 encoding=iso-8859-1 Fig. 1. Identicaci n de chero XML o Existen cinco caracteres especiales en XML: los smbo

los menor que ( ), mayor que ( ), las comillas dobles (), el ap strofo () y el caracter . Para representar eso tos caraceteres especiales y evitar que sean interpretados de forma especial se usan las siguientes entidades:

cual aparecen otros elementos artheader , sect1 e index , y estos a su vez se componen de otros elementos.

Fig. 4. Ejemplo de estructura de un DTD Fig. 2. Entidades predeterminadas Los smbolos mayor que y menor que se usan para deli mitar las marcas que dan la estructura al documento. Cada marca tiene un nombre, que debe ser distinto al de otra marca, y puede tener una serie de atributos. Por ejemplo, la mara ca gura puede tener uno o m s atributos: gura chero=gura.jpg tipo=jpeg tiene dos atributos, chero y tipo . Los atributos toman valores que tienen que estar entre comillas o entre ap strofos. o 2.1. Denici n del tipo de documento (DTD) o Las posibles marcas que pueden aparecer en un documento XML y los atributos que estas pueden tener, son de nidos en un chero llamado Denici n del Tipo de Docuo mento (en ingl s Document Type Denition ) o simplee mente DTD. Cada documento XML debe indicar al comienzo el DTD usado por medio de una marca !DOCTYPE . El DTD puede ser dise ado de forma a hacer obligaton rio el uso de algunos sub-elementos y limitar el n mero de u veces que un elemento puede aparecer y el orden de los elementos. De esta forma el DTD puede ser bastante exible o tan exigente como se desee, para forzar a los autores a ce irn se a un determinado estilo. Adem s, puede ser denido en a el propio chero XML o en un chero externo. 3. HOJAS DE ESTILO XSL Una hoja de estilo XSL es un documento XML que nos permite denir una presentaci n o un formato para otro doo cumento XML. Un mismo documento XML puede tener varias hojas de estilo XSL que lo muestren en diferentes formatos y con diferentes estilos (XML, PDF, HTML, PostSA cript, LTEX, sonido, etc) [2]. B sicamente, una hoja de estilo XSL dene una transa formaci n entre un documento XML de entrada y otro de o salida, representa el conjunto de reglas que determinan esa transformaci n. Cada regla posee un patr n (pattern) y una o o acci n o plantilla (template). o

Fig. 3. Denici n de un DTD de ejemplo o Como se puede observar en la gura, el DTD concreto posee una serie de par metros, como son el car cter del a a mismo (p blico o privado), el DTD usado (en este caso el u DTD de OASIS) y la localizaci n del mismo (en este ejemo plo aparece una direcci n local, aunque tambi n puede ser o e una direcci n global de la World Wide Web). o Un chero DTD dene siempre una o m s estructuras a jer rquicas, con una marca principal, o raiz, compuesta por a otras marcas, o hijos, describiendo los tipos de atributos y entidades permitidas, as como limitaciones para combinar los. La gura siguiente muestra la estructura de un DTD simple, con un elemento principal article , dentro del

Fig. 5. Ejemplo de chero XSL

4. BASES DE DATOS CON XML Una base de datos XML no es diferente de cualquier documento XML, ya que XML permite denir cualquier tipo de informaci n. La diferencia entre documentos XML que o tratan diversos tipos de contenidos, no es m s que la distina ta organizaci n de sus elementos, gestionados a trav s de la o e colecci n de etiquetas adecuadas a cada caso. o Las bases de datos m s sencillas son las que presentan a los datos en forma tabulada, conocidas como bases de datos tabulares.

transferencia. Este ultimo caso es m s able, al realizar las a tranferencias siempre de la misma forma, aunque es tambi n m s lento y el software debe ser especco para cada e a base de datos concreta. Por eso, el software libre aboga por el desarrollo de aplicaciones software que mapeen la estructura del documento XML con la estructura concreta de cada base de datos. Normalmente, los productos desarrollados utilizan transacciones basadas en el lenguaje SQL [3]. 4.1. Tipos de mapeo de datos entre documentos XML y bases de datos Existen diversos tipos de mapeo de datos entre documentos XML y bases de datos. En primer lugar existen los mapeos basados en tablas, usados, sobre todo, para la transferencia de datos entre documentos XML y bases de datos relacionales. Modelan los documentos XML como una tabla o un conjunto de ellas, en las que su contenido posee la misma estructura que la base de datos relacional. As, un mapeo basado en tablas producir cheros XML con la siguiente estrutura: a base-de-datos tabla la columna1 ... /columna1 columna2 ... /columna2 ... /la la ... /la ... /tabla tabla ... /tabla ... /base-de-datos Fig. 7. Estructura de chero XML con mapeo mediante tabla Dependiendo del software, es posible especicar qu coe lumna de datos es almacenada como atributos o elementos, as como el nombre que se usar para cada elemento o atri a buto. Adem s, algunos productos permiten incluir una taa bla de datos como una tabla independiente en el documento XML o como atributos de un nodo determinado existente en el documento, es decir, permiten anidamiento (hay que hacer notar que aqu tratamos el t rmino tablaen su menor e signicado, pudiendo ser una tabla completa o una parte de una consulta).

Fig. 6. Ejemplo de base de datos tabular Sin embargo, este no suele ser el caso m s usual. a Un documento XML es una base de datos s lo en su o m s estricto sentido. Esto es, un documento XML es una a colecci n de datos. o El uso de XML como base de datos posee una serie de ventajas. Por ejemplo, es autodescriptivo (las marcas denen la estructura y los nombres de los tipos de datos, aunque no su sem ntica), portable, y puede describir los datos a en forma de arbol. tambi n posee algunas desventajas, co e mo la lentitud a la hora de vericar los datos y convertirlos en otro formato. Una cuesti n mucho m s util es el uso de XML como un o a sistema de gesti n de datos (DataBase Management Syso tem, o DBMS). En este sentido, XML provee muchas de las ventajas de este tipo de sistemas: almacenamiento (documentos XML), esquemas (DTDs, Lenguajes de esquema XML), lenguajes de colas (XQuery, XPath, XQL, XMLQL, QUILT, etc), interfaces de programaci n (SAX, DOM, o JDOM), y mucho m s. Por supuesto, tambi n posee algua e nas limitaciones, como son un almacenamiento no eciente, falta de ndices, transacciones seguras e integridad de datos, falta de acceso multiusuario, etc. Un uso muy extendido de XML es el de documentos centrados en datos, esto es, documentos que usan el lenguaje XML como intercambio de datos entre aplicaciones, tablas, consultas y/o registros de una o varias bases de datos. Para transferir datos entre uno o varios documentos XML y una base de datos, es necesario mapearel esquema del documento XML (DTD, XML Schema, etc) con el esquema de la base de datos. El software de transferencia de datos se compila entonces sobre esta correspondencia. Otras veces se usa software de transferencia que no mapea ambos esquemas, por lo que es necesario una transformaci n o del documento XML (mediante XSLT por ejemplo) a la estructura de la base de datos concreta, para realizar luego la

En segundo lugar, existen los mapeos basados en relaciones de objetos. Modelan los datos de los documentos XML como un arbol de objetos, que son especcos de los datos conteni dos en el documento. En este modelo, los tipos de elementos con atributos, el contenido de los elementos o los contenidos mixtos (tipos de elementos complejos) son normalmente modelados como clases. Elementos simples o atributos son normalmente modelados como propiedades escalares. Este modelo mapea los datos con las bases de datos relacionales usando la tradicional t cnica de mapeo de objetos e relacionales o las vistas de objetos de SQL. Esto es, las clases son mapeadas con tablas y propiedades escalares son mapeadas con columnas. 4.2. Generaci n de DTDs desde esquemas relacionales o y viceversa Una cuesti n muy com n al transferir datos entre doo u cumentos XML y bases de datos es c mo generar DTDs o para los documentos XML a partir del esquema de la base de datos y viceversa. Hay que hacer notar que esta cuesti n o pertence al tiempo de dise o, dado que, aunque normalmenn te las aplicaciones de transferencia no necesitan generar un DTD a partir de un esquema relacional en tiempo de ejecuci n, su funcionamiento s se basa en un DTD concreto, y o los procedimientos para la generaci n de esquemas distan o mucho de ser perfectos. Sin embargo, existe una forma f cil de generar esquea mas a partir de DTDs pertenecientes a documentos XML y viceversa, sin m s que seguir una serie de pasos b sicos. a a Para generar un esquema relacional a partir de un DTD se deben realizar los siguientes pasos: 1 Para cada tipo de elemento complejo, crear una tabla y una columna clave primaria (primary key column). 2 Para cada atributo de un s lo valor de ese tio po de elemento, y por cada ocurrencia simple, crear una columna en dicha tabla. Si el atributo es opcional, hacer la columna eliminable. 3 Para cada atributo multievaluado (con varios valores posibles), crear una tabla independiente para almacenar los valores.

2 Para cada dato columna de la tabla (excepto la columna clave), as como para la columna clave primaria, a adir un atributo al tipo de elemento n anterior. 3 Para cada tabla para la cual la clave primaria sea exportada, a adir un elemento hijo al mon delo de contenido y procesar la tabla recursivamente.

Aunque este sistema normalmente da buenos resultados, a veces provoca duplicaci n de tablas. Por ejemplo, en un o documento XML como el siguiente: cliente nombre Adala /nombre direcci n o calle Descubrimientos 14 /calle ciudad Sevilla /ciudad c d-postal 41014 /c d-postal o o pais Espana /pais /direcci n o /cliente Fig. 8. Fichero XML con problemas de duplicaci n de tabla o El procedimiento general anteriormente mencionado generara dos tablas independientes, una para clientes y otra para direcciones, cuando, en este caso concreto, sera m s a correcto almancenar los datos de direcciones como subtablas dentro de la tabla clientes. Por tanto, vemos que el procedimiento general anterior para generar DTDs o esquemas relacionales puede ser adaptado a la mayora de los casos, necesitando elaborar s lo pe o que as variaciones en determiandos casos concretos como n el del ejemplo anterior. 5. USO DE XML PARA CREACION Y GESTION DE FICHEROS DE CONFIGURACION XML es una muy buena opci n para escribir cheros de o conguraci n de aplicaciones. La existencia de libreras opo timizadas para extraer informaci n y modicar documentos o XML facilita la tarea del programador [4]. Un ejemplo tpico son los cheros de conguraci n usa o dos en Glade. Glade es un programa para construir interfaces gr cas de usuario (GUI) que usen las libreras gr cas a a GTK+. Glade tiene una interfaz gr ca f cil de usar, dona a de se pueden denir las ventanas que usar la aplicaci n a o que se va a construir y se le pueden ir colocando diferentes widgets (botones, cuadros de di logo, ventanas, etc.). El a resultado despu s de denir el GUI del programa se resume e

Para generar un DTD a partir de un esquema relacional se deben realizar los siguientes pasos: 1 Para cada tabla, generar un tipo de elemento.

en un chero XML con el nombre del programa y con extensi n .glade. Si mas tarde se quiere modicar la interfaz o gr ca del programa, glade leer ese chero y analiz ndolo a a a recuperar toda la informaci n que necesita para volver a a o representar la interfaz gr ca del programa. De esta forma, a se aceleran mucho las posibles modicaciones que haya que realizar a la aplicaci n. Por ejemplo, si quisi ramos traducir o e nuestra aplicaci n a otro idioma, s lo tendramos que editar o o el chero XML que dene el GUI y modicar los valores de los elementos que denen los nombres de las etiquetas y botones, los di logos de los cuadros de di logo, etc., de a a una forma mucho m s sencilla que la que implicara volver a a editar la interfaz gr ca para editarla. a Como ejemplo podemos usar un editor de textos que Glade posee para introducir al programador en el uso del programa. Las primeras lneas del chero XML que denen la interfaz gr ca del editor de textos son las siguientes: a

en aplicaciones. Una gran ventaja de esta librera es que, a pesar de haber sido desarrollada en el seno del proyecto GNOME, no tiene ninguna dependencia con este entorno, por lo que puede ser usada perfectamente en aplicaciones totalmente ajenas a GNOME. Libxml incluye todo lo que cabra esperar de una librera de estas caractersticas. Es decir, con libxml se puede leer, validar y modicar documentos XML, todo ello de una forma bastante clara y sencilla. Para manejar documentos XML con libxml, se utilizan dos tipos de datos b sicos: xmlDocPtr, usado para reprea sentar un documento XML, y xmlNodePtr, que se usa para representar cada uno de los nodos contenidos en los documentos XML procesados en los programas. Estos dos tipos de datos son simplemente punteros a dos estructuras que estan denidas en los cheros de cabecera de libxml, y m s concretamente en el chero tree.h. Estas estructuras a son xmlDoc y xmlNode, cuyo contenido debe ser conocido, pues a la hora de trabajar con libxml, se usa continuamente para acceder a las propiedades de los objetos XML (documentos, nodos, etc) asociados.

6.1. Carga de documentos XML Un documento XML es, a n de cuentas, una larga cadena de caracteres. Es decir, que un documento XML no tiene porqu estar asociado a un chero en el disco, aunque, e por supuesto, puede estarlo. As, libxml ofrece dos funcio nes para permitir la carga de documentos XML, tanto leidos del disco, como desde una posici n de memoria previameno te inicializada. Estas dos funciones son: xmlDocPtr xmlParseMemory (char *buffer, int size); xmlDocPtr xmlParseFile (const char *lename); La diferencia entre ellas, como ya se ha comentado anteriormente, es que la primera carga el documento desde una posici n de memoria especca (buffer), mientras que o la otra lo hace desde el chero especicado como par mea tro.

Fig. 9. Inicio del chero de conguraci n del editor de texo tos de Glade Como vemos, podramos modicar las propiedades de la interfaz gr ca del editor de textos sin m s que editar el a a correspondiente elemento del chero XML que lo dene. Otra ventaja del uso de XML para construir cheros de conguraci n es que en estos casos no es necesaria la vao lidaci n del documento XML, ni la generaci n de un DTD o o apropiado para dicho documento, ya que cuando el chero XML es creado y modicado por un programa, normalmente no es necesario validarlo contra un DTD, pues si el programa que genera los cheros de conguraci n en leno guaje XML ya ha sido depurado, dichos cheros producidos tendr n siempre la estructura esperada. a 6. PROGRAMACION MEDIANTE XML La tendencia actual en el dise o de aplicaciones es la de n integrar el lenguaje XML para el almacenamiento estructurado de datos. En esta secci n nos centraremos en el uso de la librera o libxml (o GNOME-XML) [5], perteneciente al proyecto GNOME, que es una librera que implementa un analizador sint ctico XML que permite f cilmente hacer uso de XML a a

6.2. Creaci n de cheros XML o Libxml incluye tambien funciones para crear o modicar el contenido de documentos XML. Lo primero que necesitamos hacer para crear de cero un documento XML es crear la estructura xmlDoc asociada, que posteriormente usaremos para acceder al contenido del documento. Tras esto, tendremos un documento que estar vaco. Para a adirle contenido, se deben crear nuevos a n nodos y a adirlos a otros nodos, tras haber creado el nodo n raiz de nuestro documento.

6.3. Guardar documentos XML Por ultimo, libxml tambi n posee un conjunto de fun e ciones para almacenar un documento XML creado y/o modicado tanto en disco como en memoria. En primer lugar, tenemos las funciones: void xmlDocDumpMemory (xmlDocPtr doc, xmlChar **buffer, int *size); int xmlSaveFile (const char *lename, xmlDocPtr doc); Estas funciones permiten salvar un documento XML (referenciado por una variable de tipo xmlDocPtr tanto en memoria (la primera de ellas) como en disco (la segunda). Junto a estas dos funciones, existen otras para almacenar un nodo (o un conjunto de ellos) de un documento XML en memoria, liberar el espacio ocupado en memoria por un documento, comprimir el espacio ocupado por un documento en memoria y otras combinaciones. 7. CONCLUSION Como hemos visto a lo largo de este artculo, el lenguaje XML presenta numerosas ventajas en su utilizaci n para el o desarrollo de software libre, tales como su facilidad de uso, normalizaci n y su extensi n actual. o o Adem s, el futuro del lenguaje XML es bastante espea ranzador, ya que, como hemos visto, grandes aplicaciones (al estilo de GNOME con su librera libxml o KDE con pro gramas como Kugar, programa para visualizar e imprimir documentos XML) se decantan por integrar el uso del lenguaje XML.

Por supuesto, XML es una herramienta muy util, aunque no siempre ser recomendable su uso. Depender de cada a a situaci n concreta el uso de esta u otra de las numerosas o herramientas de las que se disponen para el desarrollo de software libre. 8. BIBLIOGRAFIA [1]. The World Wide Web Consortium (W3C). Los creadores de los est ndares HTML, XML, a XSL, XHTML y muchos otros; en esta p gia na se encuentran las versiones mas recientes de los est ndares as como informaci n adicional a o y enlaces a otras fuentes de informaci n. URL: o http://www.w3.org/ [2]. xml.com. La p gina de oReilly dedicada al XML; a all se encuentra mucha informaci n sobre XML o y XSL. URL: http://www.xml.com [3]. XML data model. Una p gina dedicada al an lia a sis de relaciones entre XML y bases de datos, por Bert Bos. URL: http://www.w3.org/pub/ WWW/XML/Datamodel.html [4]. Programaci n en XML: el nuevo lenguaje o de Internet. Los apuntes de un curso bastante completo sobre XML, realizado en Granada. URL: http://geneura.ugr.es/cursos/xml/ programa.shtml [5]. The XML C library for Gnome. La p gina de a las libreras XML creadas por el proyecto Gno me; incluye el procesador de XML/XSL xslt. URL: http://www.xmlsoft.org

EL PROYECTO DE CLUSTER SSI OPENMOSIX David Santo Orcero Mantenedor de las herramientas de area de usuario del proyecto OpenMosix irbis@orcero.org, http://www.orcero.org/irbis
RESUMEN OpenMosix es el unico proyecto con licencia GPL con su ciente calidad para ser usado en entornos de producci n o capaz de implementar un cluster con un modelo SSI, frente a otros proyectos no libres MOSIX o que a n est n en u a fase alfa SSI-C existentes en el mercado. En este artculo vamos a estudiar los conceptos claves de OpenMosix, as como su historia y su funcionamiento. 1. LOS SISTEMAS SSI Denominamos sistemas SSI Single System Image [1] a aquellos sistemas de clustering en los que todo el cluster ofrece al usuario la imagen de un unico sistema, es decir, que el cluster entero se comportar para el usuario como a una unica m quina. a Desde un punto de vista menos formal, la idea de un cluster SSI es poder administrar y usar un cluster completo como si se tratara de una m quina SMP o, en el peor de los a casos, de una m quina NUMA. a Los sistemas SSI siempre han sido de inter s de la ine dustria inform tica, y actualmente son objeto de investigaa ci n intensa en el area de los sistemas operativos distribuio dos y de gran inter s en la comunidad general, con espacio e dentro de los foros de en clustering [2]. El problema que los SSI deben resolver es bastante complejo, ya que se supone que un sistema operativo SSI puro debe ser capaz de hacer transparente el paralelismo del cluster al proceso y al administrador. Esto signica que cualquier proceso debe poder migrar desde cualquier nodo del cluster a cualquier otro nodo y ejecutarse en el, independientemente de donde haya sido lanzado; y que puede hacerlo tantas veces como quiera, para as aprovechar mejor los recursos del sistema. Las aplicaciones, adem s, deben ser capaces de poder usar a esta capacidad de migrar sin necesidad de ser recompiladas ni de enlazar ninguna biblioteca especca de migraci n. o De entre los sistemas con alguna de las caractersticas de un sistema SSI que han existido y existen en el mecado, debemos destacar el VMS para VAX, de Digital, el Sysplex de IBM para su OS/390, o el sistema MOSIX [3]. Sin embargo, ninguno de estos sistemas SSI son libres. Por otro lado, tenemos el SSI de Compaq, que ha tomado muchas ideas y c digo de MOSIX como OpenMosix, o de la epoca en que MOSIX era libre; pero a n esta muy lejos u de ser lo sucientemente estable como para poder ejecutarse en un cluster en producci n. o En este artculo vamos a revisar el sistema libre SSI OpenMosix. 2. EL ORIGEN DE OPENMOSIX El proyecto OpenMosix [4] es un fork libre del proyecto MOSIX. Por ello, vamos a comenzar estudiando la historia del proyecto MOSIX. El proyecto MOSIX fue desarrollado por el profesor Amnon Barak y su equipo Oren Laadan, Ammon Shiloh y Moshe Bar, entre otros en la Universidad Hebrea de Jerusal n. Su desarrollo original fue parte de un proyecto e nanciado originalmente por el DARPA para un cluster de m quinas PDP-11/45 usado en las fuerzas a reas norteamea e ricanas. Despu s este sistema se adapt tambi n a clusters e o e PDP-11/10. El sistema operativo era el Unix 6 de Bell Labs, y fue desarrollando entre 1977 y 1979. En aquella epoca, el proyecto se llamaba UNIX with Satellite Processors. La idea de este proyecto era parchear masvamente el kernel para permitir la migraci n autom tica de procesos seg n un o a u algoritmo de equilibrado de carga del que hablaremos m s a adelante, de tal forma que el aprovechamiento de los recursos del cluster sea el mayor posible y, por lo tanto, mayor la probabilidad de que un proceso determinado de uno de los nodos con m s carga termine m s deprisa, al no tener que a a competir por procesador con tantos procesos como competira sin MOSIX. El resultado de este primer desarrollo fue excelente, y, tras un a o dedicado a otras actividades, el prof. Barak con menz a trabajar en el nuevo proyecto MOS. Este proyecto o sigui con las ideas del proyecto anterior; y supuso en la o pr ctica una reimplementaci n completa del antiguo proa o yecto UNIX with Satellite Processors -reencarnacion, tal y como el profesor Barak denominar las reimplementaa ciones de MOSIX en su bibliografa-. MOS fue desarrollado entre los a os 1981 y 1982 para las m quinas PDP-11/45 y n a PDP-11/23, parcheando masvamente el sistema operativo

Unix 7, tambi n de Bell Labs. e En una tercera fase, que se desarroll durante los a os o n 1983 y 1984, el proyecto MOS fue portado a una m quina a CADMUS/PCS MC68K, que ejecutaba el Unix 7 de Bell Labs con algunas extensiones de BSD 4.1. Despu s de su adaptaci n a CADMUS/PCS MC68K, el e o proyecto MOS, a n completamente SSI, estubo completau mente detenido durante dos a os. Pero en 1987 el profen sor Barak retom el desarrollo, ahora llamando a la nueva o reencarnaci n de MOS con el nombre NSMOS. NSMOS o fue desarrollado sobre una m quina NS32332, que ejecua taba AT&T Unix system V release 2. El proyecto NSMOS comenz a dejar el area de kernel de cada proceso en el o nodo raz, ya que ya no era posible modicar todos los pro gramas de area de usuario de Unix que eran precisos para mantener el area de kernel migrable. Este cambio, que se ha mantenido hasta nuestros dias, permite que no sea necesario modicar ninguna de las aplicaciones de Unix para que sean ejecutadas en un cluster MOSIX/OpenMosix satisfactoriamente, a cambio de que el area de kernel de los procesos se ejecute siempre en su nodo raiz. En 1998, el equipo del profesor Barak porta NSMOS a las arquitecturas VAX-780 y VAX-750, que tambi n ejecue taban el AT&T Unix system V release 2. Como en el caso anterior, no es parcheado masvamente el sistema operativo, sino apenas su kernel. El proyecto pasa a llamarse MOSIX, nombre que conservara hasta hoy en dia. A n en 1988, el sistema SSI MOSIX es portado a arquiu tecturas NS32532, tambi n con AT&T Unix system V ree lease 2. Este porting llev dos a os, seguidos por dos a os o n n en que el profesor Barak par el proyecto. o Ya entrando en los noventa, el profesor Barak comienza a trabajar con arquitecturas Intel. En 1991 comienza el porting de MOSIX a BSD/OS sobre 486, porting que llevara tres a os en completarse. Entre 1994 y 1997, volvera n otra vez el profesor Barak a parar el proyecto, ahora durante cinco a os. n En 1998, el profesor Barak vi que BSD/OS estaba desao pareciendo, y decidi portar MOSIX a un sabor de Unix o bastante popular en la epoca: Linux. Esta reencarnaci n de o MOSIX s lo funcionaba para m quinas i80486 o superioo a res, y usaba el kernel 2.2. Un a o m s tarde de la reencarn a naci n de MOSIX en Linux, por la naturaleza vrica de la o licencia GPL con la que fue desarrollado el kernel de Linux, el profesor Barak se vi legalmente forzado a liberar o el c digo de MOSIX. Este hecho fue aplaudido por alguno o de los colaboradores del profesor Barak, tales como Moshe Bar; aunque el profesor Barak no se qued muy convencido o del hecho. Las herramientas de area de usuario, imprescindibles para congurar y administrar un cluster MOSIX, no fueron liberadas hasta medio a o m s tarde; y debido a la n a presi n de la comunidad Linuxera, no a ning n plan detero u minado del profesor Barak. Estas herramientas de area de

usuario permanecieron libres hasta nal del 2001. Una vez liberadas las herramientas de area de usuario, el proyecto MOSIX se populariz r pidamente, ya que permio a tia SSI real en clusters Linux, algo que otros paquetes a n u s lo prometen. MOSIX fue incluido por defecto en la mao yor parte de las distribuciones importantes, tales como Debian o Mandrake, y una parte importante de la comunidad intent apoyar el proyecto MOSIX enviando parches y nueo vas funcionalidades, sin que ninguno despertase el inter s e del profesor Barak. En el a o 2000 comenz el porting al kernel 2.4 de Lin o nux, que termin un a o m s tarde. Este c digo tambi n o n a o e estaba liberado bajo GPL, pero el hecho de que MOSIX no avanzara durante todo el 2001 y que el profesor Barak no aceptaba cualquier tipo de ayuda externa que el no contro lase directamente, termin desencadenando el fork. o En el a o 2002, la situaci n termin estallando en las n o o manos del profesor Barak. El profesor Barak decidi camo biar la licencia de MOSIX retirando el derecho a adaptar el c digo al uso propio all donde le fue posible modicar o la licencia sin violar la GPL. Adem s, el proyecto MOSIX a llevaba un a o parado, el profesor Barak estaba rechazando n los parches que aportaban mejoras y nuevas funcionalidades a MOSIX, y estaba ocultando este hecho a sus colaboradores, entre ellos a Moshe Bar el antiguo alumno del profesor Barak m s brillante, en esta epoca ya la mano derecha del a profesor Barak y coresponsable del proyecto. Todo esto origin que grupo importante del equipo que o haba desarrollado MOSIX y de usuarios de MOSIX entre los que se encontraba Moshe Bar coadministrador del proyecto MOSIX y mano derecha del profesor Barak, y autor del MFS, y del DFSA, Mark Veltzer Windows2Linux, sgmltools-lite, contribuciones al CPAN, Muli Ben Yehuda Syscalltrack, pptp, Brian Bilbrey LinuxBook, gran cantidad de documentaci n libre para Linux, Brian Pontz o Apache log rotator, Louis Zechtzer, Michael Farnbach, Bruce Knox, y David Santo Orcero el autor de este artculo tomaron la ultima versi n de Mosix que era posible demos o trar en un tribunal que era GPL, y comenzaron a trabajar por su cuenta. Con modelo de desarrollo de bazar, bajo GPL y con CVS abierto a todos. Y, sorprendentemente, comenzaron masivamente las descargas de OpenMosix y las colaboraciones en forma de parches y localizaci n de errores. o Haba comenzado el proyecto OpenMosix. Actualmente el proyecto MOSIX tiene una licencia de c digo cerrado para una parte muy importante del c digo o o por la que no es legal modicarlo y mucho menos distribuir las mejoras, y ha estado los dos ultimos a os pr ctica n a mente sin avances. Por otro lado, el proyecto OpenMosix, completamente libre, bajo GPL y con modelo de desarrollo de bazar, ha tenido un r pido crecimiento en caractersticas a y estabilidad. Actualmente, Moshe Bar coordina el proyecto Open-

Mosix y se encarga del mantenimiento de la parte de kernel del proyecto, y David Santo Orcero se encarga del mantenimiento de la parte de area de usuario. Pero no son los unicos desarrolladores de OpenMosix. OpenMosix cuenta con m s a de una docena de excelentes desarrolladores, varios miles de clusters en producci n en el mundo, es el segundo proo yecto m s descargado de sourceforge, el septimo proyecto a en visitas en sourceforge en el mes de Agosto, y est siendo a portado a IA-64. 3. QUE ES OPENMOSIX OpenMosix es un conjunto de parches al kernel y unas utilidades y bibliotecas de area de usuario que permiten te ner un sistema SSI completo para Linux. Al estar basado en el c digo de MOSIX, comparte algunas de sus caracterstio cas y limitaciones. Sin embargo, OpenMosix lleva medio a o de actividad extrem damente activa, que MOSIX no ha n a tenido. Por ejemplo, OpenMosix hace uso del parche de Rik van Riel de mapeado inverso de memoria, que permite que el proceso que consume m s recursos de OpenMosix pase de a a una comtener una complejidad computacional de plejidad de . En la pr ctica, elimina una de las partes del a c digo de OpenMosix que pueden consumir una cantidad o apreciable de procesador. Adem s de esto, OpenMosix carece de algunas de las a condiciones de carrera de MOSIX gracias a un parche de David Santo Orcero, tiene autodetecci n de los nodos del o cluster gracias a una aplicaci n de Louis Zechtzer, y grao cias al trabajo de Moshe Bar ya funcionan correctamente las aplicaciones que usen hebras sobre OpenMosix. Gran parte de los desarrolladores de OpenMosix est n trabajando en el a porting a IA-64 y a la correcci n de errores, con lo que gloo balmente OpenMosix es m s r pido, eciente y tiene m s a a a caractersticas innovadoras que MOSIX. Se ha hecho tambi n un esfuerzo importante en docue mentar correctamente OpenMosix: parte del equipo est esa cribiendo documentaci n moderna y precisa, y el proceso o OpenMosix dispone de un FAQ, un HOWTO y una base de conocimientos Wiki propia. Haciendo un sumario de lo que hace OpenMosix, en OpenMosix los procesos migran de un nodo a otro de un cluster Linux para ejecutarse en aquellos nodos que permitir n que el aprovechamiento de los recursos del cluster sea a m ximo. Esto signica que los procesos migrar n de CPUs a a sobrecargadas a CPUs libres, y que migrar n al nodo en el a que fsicamente est n escribiendo los datos para escribirlos a a m s velocidad si escriben mucho en dicho nodo, usando a el sistema de archivos de OpenMosix oMFS. Por ultimo, los procesos que comiencen a swappear en exceso migrar n a a nodos en los que tengan memoria suciente para ejecutarse sin swap. Todo esto se evalua teniendo en cuenta el coste de

la migraci n, para evitar el ping-pong de procesos que o un proceso vaya y vuelva de un nodo constantemente. En ning n momento es necesario ni recompilar ni reprogramar u ning n proceso, por lo que tenemos un sistema SSI real, que u nos permite hacer el m ximo aprovechamiento de los recura sos de cualquier cluster Linux, sea dedicado o no, para que podamos ejecutar en el la mayor parte de las aplicaciones posibles de la forma m s r pida posible. a a El modelo de programaci n de OpenMosix es fork and o forget. Una vez que el proceso ejecuta la llamada fork llamada estandar Posix para que un proceso se transforme en dos, el hijo y el padre podr n ejecutarse en nodos distina tos si as mejora el aprovechamiento global de los recursos computacionales del cluster. La migraci n de procesos y su o ejecuci n efectiva en nodos distintos no quita que sus coo municaciones sean simples, ya que se pueden comunicar los procesos migrados entre s tal y como se comunicaban antes de que migrasen, es decir, usando los mismos mecanismos de comunicaci n locales. o El c digo de OpenMosix se compone de dos partes bien o diferenciadas: por un lado, una parte en area de kernel que consiste en un conjunto de parches al kernel para dotar al kernel de Linux de las funcionalidades de un cluster SSI. Este conjunto de parches incluye modicaciones al planicador de Linux que se activan cclicamente cuando crece la carga, algunas inclusiones en el algoritmo de gesti n del o swap que se activan cuando la carga asociada al swap es intensa, rutinas de lanzamiento remoto de llamadas al kernel que se activan cuando un proceso migrado realiza una llamada al kernel que no puede resolver en el nodo de ejecuci n, un sistema de cheros propio que permite acceder o de forma local a las particiones remotas de las m quinas del a cluster, y una rutina que permite escuchar en un puerto las llamadas al kernel lanzadas remotamente y que deben ser atendidas localmente, entre otros parches. Por otro lado, las herramientas de area de usuario se componen de un conjunto de utilidades y bibliotecas en area de usuario que tienen como objetivo facilitar la tarea de administraci n y uso del cluster, as como una biblioteca con o un API que nos permiten acceder a las funciones propias de OpenMosix. Las herramientas de area de usuario, por ejem plo, incluyen utilidades para congurar los nodos del cluster, para detectar autom ticamente los nodos OpenMosix de a la red e incluirlos en el cluster, una utilidad para lanzar procesos deniendo c mo van a migrar, una utilidad para forzar o migraciones y forzar que vuelvan procesos migrados, y utilidades de monitorizaci n del cluster, entre otras utilidades. o Debemos incidir en uno de los conceptos fundamentales a OpenMosix: aunque existan la biblioteca y las aplicaciones de area de usuario para tomar el control del cluster, no es necesario que el usuario o el pogramador usen las bibliotecas y las aplicaciones de area de usuario: un cluster OpenMosix, de por si solo, realiza la migraci n autom tio a

ca de las tareas de un nodo a otro con objeto de asegurar que la utilizaci n de los recursos computacionales del cluso ter sea siempre optima. La biblioteca de area de usuario nos permite controlar el cluster, decidiendo sobre la poltica de migraci n, dando informaci n heurstica al planicador de o o OpenMosix sobre lo que el proceso piensa hacer y forzando migraciones, pero las aplicaciones pueden migrar sin usar la biblioteca. 4. EL MECANISMO DE MIGRACION AUTOMATICA DE PROCESOS EN OPENMOSIX En OpenMosix, determinados procesos pueden ejecutarse en un nodo distinto al que se lanzaron. En este caso se dice que el proceso ha migrado, y que no se ejecuta su area de usuario en el nodo raiz. En el nodo raiz el nodo donde se gener el proceso solo se ejecutar n las llamadas al kernel o a que no puedan ser ejecutadas en el nodo de ejecuci n por o falta de informaci n o por hacer uso dicha llamada al kernel o de los recursos locales al nodo raiz. Un proceso no puede migrar y se le marca como no migrable si cumple alguna las siguientes condiciones: El proceso usa segmentos de memoria compartida System V. Desgraciadamente, este es el caso del sistema gestor de base de datos PostgreSQL. Esto supone una limitaci n de OpenMosix heredada de MOSIX que el o equipo de OpenMosix est trabajando para eliminara la. El proceso se ejecuta en modo de emulaci n VM86. o Desgraciadamente, este es el caso del VMware; pero es un problema que casi nunca se da en programas de Linux y que tiene muy mala eliminaci n por la natuo raleza del modo de emulaci n VM86 si migr semos o a un proceso en este estado, la carga de llamadas al nodo raiz sera tan alta que habra sido contraproducente haberlo migrado. El proceso ejecuta instrucciones en ensamblador propias de la m quina donde se lanza, y que no tiene la a m quina de destino. Esto es una limitaci n evidente, a o ya que por muy bueno que sea OpenMosix jam s poa dremos lanzar un programa compilado para un Pentium IV que use las instrucciones propias de Pentium IV en un Pentium. Esta condici n, en principio, no o es una condici n demasiado preocupante, ya que cao si todas las distribuciones de Linux tienen todos sus programas compilados para Pentium. Programas que usen instrucciones m s especcas en clusters hetea rog neos pueden provocar que el proceso vuelva ane tes de tiempo a su nodo raiz, o que s lo pueda migrar o a un n mero determinado de nodos. u

El proceso mapea memoria de un dispositivo en la RAM, o acceder directamente a los registros de un dispositivo. Esta limitaci n es evidente, ya que el aco ceso a los recursos hardware del nodo raiz hace que no sea rentable su migraci n a otro nodo. El caso m s o a destacado de proceso que viola esta limitaci n es el o servidor de X-Window, aunque hay algunos programas que no pueden migrar por el uso de la funci n o mmap. Actualmente el equipo est viendo como a evitar este problema. En principio, todos los procesos que est n declarados e como migrables propiedad heredada del padre del proceso, pero que puede ser modicada con las herramientas de area de usuario pueden migrar. En el momento que un proceso no migrado cumpla alguna de las condiciones anteriormente citadas, no podr migrar m s hasta que deje de violar las a a restricciones salvo en el caso de usar instrucciones de una arquitectura distinta, en cuyo caso queda marcado como no migrable permanentemente. Por otro lado, si un proceso migrado intenta cumplir alguna de las condiciones anteriores por ejemplo, porque intente reservar o usar un segmento de memoria compartida, o intente usar directamente un registro hardware de la m quina el proceso migrado genera un trap y ser suspena a dido por el kernel, para ser enviado al nodo raiz el nodo donde se origin el proceso. Una vez que el proceso o est otra vez en el nodo raiz, el proceso ser planicado e a para ejecuci n de nuevo, y volver a ejecutar la operaci n o a o prohibida en su nodo raiz, siendo marcado dicho proceso como no migrable hasta que deje de violar las restricciones. 5. EL ALGORITMO DE EQUILIBRADO AUTOMATICO DE CARGA En OpenMosix las migraciones pueden ser de dos clases: pueden ser forzadas explcitamente por el usuario pro pietario de un proceso, por el grupo propietario de un proceso, o por root; pero tambi n puede ser migraciones aue tom ticas de procesos. Vamos a hablar de la migraci n aua o tom tica de procesos. a Antes de entrar en detalle en el algoritmo de migraci n o autom tico de carga, debemos destacar un detalle importana te. El algoritmo de equilibrado autom tico de carga es coma pletamente distribuido: cada nodo decide localmente si va a migrar o no alg n proceso, y lo decide cuando el nodo que u toma la decisi n est sobrecargado, decisi n que tomar en o e o a base a datos parciales de uso del cluster recolectados por el y almacenados localmente. Esta naturaleza distribuida del algoritmo permite que los clusters OpenMosix puedan escalar hasta los miles de nodos sin problemas de hecho, actualmente hay clusters OpenMosix con miles de nodos en producci n, y adem s permite que no haya un nodo ceno a tral que sea punto unico de fallo del cluster completo, y que

en caso de caida de dicho nodo central caiga el cluster entero. En caso de que caiga un nodo en un cluster OpenMosix, esta cada solo afecta a los procesos ejecutados y genera dos en el nodo caido: esto es especialmente importante en clusters grandes, ya que en estos cada dia siempre hay alg n u nodo que falla. El algoritmo de migraci n autom tico de carga es un alo a goritmo de optimizaci n que emplea como funci n de costo o o el uso de los recursos del sitema de un cluster, incluendo el uso que se hace de la memoria y el uso que se hace del procesador de los nodos de un cluster, entre otros par metros. a El algoritmo que empleamos en OpenMosix tiene un orden de complejidad lineal respecto al n mero de nodos del u cluster del que tenemos informaci n local, lo que sin lugar o a dudas favorece la escalabilidad del cluster. El algoritmo de migraci n autom tico de carga busca o a maximizar el uso de los recursos de un cluster en base a la informaci n que tiene sobre la carga de los nodos y el o uso del procesador y del disco que hacen los procesos. Esto permite que, por regla general, los programas se ejecuten m s r pido de lo que se ejecutaran en un cluster sin equilia a brado autom tico de carga, aunque no tienen que ejecutarse a neces riamente todos los procesos m s r pido. a a a Veamos con un ejemplo la l gica de la funci n de costo. o o Supongamos que tenemos dos nodos en nuestro cluster. Un nodo ejecuta dos procesos, y el otro nodo no ejecuta ning n u proceso. El uso del procesador que hacen en el primer nodo los procesos es del 100 %; pero en el segundo nodo el uso que hacen del procesador es del 0 %. Supongamos ahora que migramos uno de los dos procesos al nodo desocupado: el uso del procesador del primer nodo caer probablemena te al 95 %, pero el uso del procesador en el segundo nodo subir al 95 %. El uso del cluster ha aumentado 100+0 a es menor que 95+95; y, como efecto secundario, estamos aprovechando mejor los recursos del cluster y los procesos se ejecutar n m s r pido. a a a Como algoritmo de optimizaci n OpenMosix usa un alo goritmo de tipo greedy. Este algoritmo es extrem damente a simple y muy eciente, por lo que conseguimos soluciones buenas a nuestro problema sobrecargando poco el sistema. El algoritmo de equilibrado de carga no se lanza constantemente, para no perjudicar el rendimiento del cluster. Este algoritmo s lo se lanza cuando el nodo que lo lanza o est demasiado cargado. Entonces toma la decisi n de que e o si lo mejor ser aguantar el exceso de carga, o que ser mea a jor para aprovechar el cluster mandar alguno de los procesos ejecutados localmente a alg n nodo remoto menos cargado. u Para realizar esta operaci n, un nodo OpenMosix no o cuenta con toda la informaci n que describe todo el estao do de todo el cluster. Esto hara prohibitiva la recolecci n o de esta informaci n, especialmente en clusters grandes. o OpenMosix toma un planteamiento alternativo para recolectar la informaci n. Cada cierto tiempo le pregunta a o

un grupo de nodos, escogidos aleat riamente de entre la liso ta de nodos, toda la informaci n que necesita para operar. o Con el tiempo, consigue tener informaci n de un n mero o u suciente de nodos como para tomar decisiones razonadas. Aunque la decisi n individual de migraci n de un proceso o o puede que no sea la optima para el mejor aprovechamiento del cluster, en su conjunto todas las decisiones distribuidas de todos los nodos si son optimas. De hecho, el profesor Barak ha demostrado matem ticamente de que el algoritmo a usado por MOSIX y por OpenMosix para un tiempo innito tiene el mismo rendimiento que un algoritmo optimo de ventana nita es decir, un algoritmo que ve el futuro, pero que no es capaz de ver el futuro m s all de una fecha en a a particular. 6. EL MEMORY USHERING Como hemos comentado anteriormente, en caso de sobrecarga el algoritmo de OpenMosix evalua donde va a mandar los procesos y qu procesos va a mandar usando para e ello gran cantidad de de datos; entre ellos, y destacando como los m s importantes, el uso de la memoria y el uso del a procesador. Sin embargo, hay una circunstancia crtica en la cual este algortmo sera inefectivo: es el caso del trashing. Denominamos trashing al fen meno por el cual el sisteo ma est siendo completamente inusable debido al alto uso a que hacemos del swap. La condici n de trashing es especialmente crtica, ya o que cuando un nodo comienza a hacer trashing, su eciencia pasa a ser p sima. Por ello, el trashing es algo que OpenMoe six intenta evitar a toda costa. Y lo evita gracias al sistema de memory ushering. El sistema de memory ushering es un sistema que usa el mismo algoritmo que el sistema de equilibrado de carga un greedy, pero que tiene como funci n de coste la memoria o fsica utilizada funci n que intentar maximizar y como o a condici n de activacion que un proceso comience a hacer o swap intensamente. Es un sistema predictivo, que evita de antemano llegar al trashing. El subsistema de memory ushering es considerado m s a crtico que el de equilibrado autom tico de carga. Por ello, a el subsistema de memory ushering siempre tiene prioridad sobre el subsistema de equilibrado autom tico de carga de a OpenMosix, es aut nomo a este, y se lanza de forma indeo pendiente. 7. EL MECANISMO DE MIGRACION DE PROCESOS La migraci n de procesos en OpenMosix es completao mente transparente: esto signica que al proceso migrado no se le avisa de que ya no se ejecuta en su nodo de origen. Es m s, este proceso migrado seguir ejecut ndose como si a a a

siguiese en el nodo de origen: si escribe o lee en el disco, lo har a trav s del nodo de origen lo que supone leer o grabar a e remotamente en el nodo de origen si el sistema de archivos donde se lee o se escribe corresponde a un sistema de archivos local al nodo de origen. Si hacemos un ps en el nodo origen de un proceso migrado, el proceso migrado aparentemente estar a n ah, aunque realmente no est ocupando a u e recursos de procesador. Si hacemos un ps en el nodo al que ha migrado un proceso, no veremos el proceso: el proceso se est ejecutando como una hebra del kernel. a Una vez que el proceso migra, no se ejecuta por completo en el nodo de destino. Algunas de las llamadas al kernel se ejecutan en el nodo raz. Por ello, una de las funciones del mecanismo de migraci n de procesos es, dado un proo ceso migrado, capturar todas las llamadas al kernel que haga el proceso migrado, seleccionar aquellas llamadas que no pueden ser resueltas en el nodo en el que se ejecuta actualmente el proceso migrado frecuentemente porque necesitan un recurso que s lo est en el nodo de origen del o a proceso migrado y mandar dichas llamadas al kernel por red al nodo raz para que se ejecuten en el. Por ello, deci mos que el area de usuario de un proceso en OpenMosix se ejecuta en el nodo migrado, y el area del sistema se ejecuta habitualmente en el nodo raz. Esto permite que los proce sos migrados mantengan todos los descriptores de cheros abiertos, y que puedan seguir operando con su entorno de la misma forma que si se ejecutasen en el nodo raz. Esta mo dicaci n se hizo en MOS para evitar tener que reescribir o el sistema operativo entero y las aplicaciones para funcionar en MOS, y ha sido heredada por MOSIX primero y por OpenMosix despu s. e Destacamos un ejemplo importante: una aplicaci n ino teractiva migrada. El usuario no percibe que la tarea ha migrado, ya que la interacci n con el usuario se realiza en area o de kernel, por lo que la petici n de datos se hace en el nodo o raz, y el procesamiento de los datos se hace en el nodo de ejecuci n. o El area de usuario corresponde al segmento de c digo, o el segmento de datos, el segmento de pila y el segmento de heap, as como las estructuras internas del kernel necesarias para mantener la integridad de estas estructuras. En la migraci n, todos estos segmentos y estructuras son enviados a o trav s de la red al nodo de destino. Una vez que el procee so ha migrado, se ejecuta en el nodo de destino como una hebra del kernel. Por otro lado, el area de kernel en OpenMosix corres ponde a la pila del kernel asociada al proceso, y todas las estructuras de datos relativas al uso de los recursos del kernel y el uso de los recursos de la m quina raz que emplea a el proceso. Observamos que no hay segmento de c digo; es o lo que es normal y correcto, ya que el c digo que se ejecuta o en area de kernel es c digo del kernel del sistema operativo. o Los segmentos y estructuras relativos al area del kernel no

migran al nodo de destino. Siempre est n en el nodo raz del a proceso, y ser n usados por el kernel cuando el proceso mia grado haga una llamada al kernel para poder atender a esta llamada correctamente. Las llamadas al kernel que pueden ser resueltas sin estas estructuras son las que no usan recursos de la m quina raz o de las estructuras de datos del a kernel de la m quina raz; y, por lo tanto, pueden ser resuela tas en el nodo al que migr el proceso. Pero esto no incluye o las llamadas que consumen m s recursos llamadas a disco a y a red, que siempre se ejecutar n en el nodo raz. a 8. LA COMUNICACION ENTRE LAS DOS AREAS Un dato importante que podemos tener inter s en ese tudiar es c mo se realiza la comunicaci n entre el area de o o usuario y el area de kernel en OpenMosix. Desgraciadamen te, no tenemos espacio en este artculo para estudiarla ente ra, ni tendremos tiempo en la presentaci n para comentaro la con detalle, por lo que recomendamos la lectura de [5], [6] y [7], donde encontramos descritos tambi n los escee narios de comunicaci n proceso migrado-nodo raiz por o una llamada al kernel, nodo raiz-proceso migrado por una se al, y la suspensi n de procesos migrados. n o 9. CONCLUSION OpenMosix es una prometedora plataforma SSI para Linux, bajo licencia GPL y de desarrollo de bazar que ya permite usar clusters SSI en entornos de producci n enteo ramente con software libre, y permitir en el futuro a los a investigadores en clustering nuevos avances en el campo de la computaci n distribuida. o 10. BIBLIOGRAFA [1] David Santo Orcero, Los clusters SSI, Todo Linux, , no. 23, pp. 5760, 2002. [2] http://www.hispacluster.org, . [3] http://www.mosix.org, . [4] http://www.openmosix.org, . [5] David Santo Orcero, El algoritmo de migraci n de o OpenMosix, Todo Linux, , no. 23, pp. en impresi n, o 2002. [6] David Santo Orcero, El equilibrado autom tico de cara ga en OpenMosix, Todo Linux, , no. 24, pp. en impresi n, 2002. o [7] David Santo Orcero, Las herramientas de area de usua rio de OpenMosix, Todo Linux, , no. 25, pp. en impresi n, 2002. o

 DESARROLLO RAPIDO DE VIDEOJUEGOS Alvaro L pez Ortega o alvaro@alobbs.com

1. INTRODUCCION Un videojuego es b sicamente un programa para el ena tretenimiento. En los ultimos a os, esta clase de pogramas n ha sufrido grandes cambios, aunque todos ellos siguen manteniendo en com n una caracteristica que no ha variado en u decenas de a os: buscan ser lo m s espectaculares posibles, n a tanto en el aspecto gr co como en el sonoro. a Se ha avanzado mucho en este aspecto. Los ordenadores sobre los que se ejecutan son radicalmente m s potentes, y a por lo tanto se han creado progresivamente videojuegos m s a y m s complejos. a Por otro lado, este aumento de capacidad en los ordenadores ha permitido un nuevo enfoque del desarrollo de videojuegos. Hace ocho a os, pr cticamente la totalidad de n a los videojuegos eran desarrollados por completo en lenguaje ensamblador. Necesidades de eciencia y acceso a bajo nivel a dispositivos tales como la tarjeta de video o la de sonido hacian que este tipo de programaci n fuese el est ndar o a para el desarrollo de videojuegos. La situaci n actual nada tiene que ver con el anterior o tipo de programaci n. Hoy en da los videojuegos normalo mente se desarrollan en lenguajes C/C++, bas ndose en APIs a existentes para este tipo de programas. Actualmente la mayora de los juegos se basan en libreras como OpenGL, Di rect X o SDL, las cuales facilitan mucho el trabajo de desarrollo, as como la estandarizaci n de los mismos. o 2. ESTADO DE LOS JUEGOS LIBRES En un principio, los sistemas libres fueron creados por y para desarrolladores. Esta es una situaci n que se est corrio a giendo progresivamente para que se extiendan a toda clase de usuarios de ordenador. Si realizasemos una encuesta sobre los programas m s a demandados en el mundo del software libre, uno de los grandes puntos destacados seran, sin lugar a duda, los videojue gos. En algunos de los sistemas libres, es posible ejecutar famosos juegos como la saga de Quake, Unreal o Civilization; ahora bien, en general no se trata de software libre. Existen una serie de razones que pueden ayudar a explicar esta peque a carencia dentro del software libre: n En primer lugar se trata de aplicaciones grandes. Un videojuego, aunque se suela presentar como una aplicaci n agradable y sencilla de utilizar, esconde una o gran cantidad de trabajo. Se trata de desarrollo multidisciplinar. Al contrario que con los dem s tipos de aplicaciones, el desarrollo a de un videojuego no s lo implica conocimientos de o programaci n. En el desarrollo de uno de estos proo gramas intervienen papeles como los de un dise ador n gr co y un m sico. Es l gico pensar que en el desaa u o rrollo de un videojuego se ver n involucradas persoa nas con perles profesionales bastante dispares. La raz n anterior causa muchas dependencias entre o los m dulos a la hora de desarrollar el programa. Es o mucho m s probable que se produzcan retrasos pora que una de las dependencias se ha retrasado. 3. DESARROLLO DE UN VIDEOJUEGO LIBRE Para desarrollar un videojuego libre es necesaro tener en cuenta todos y cada uno de los aspectos implicados en el. Por ejemlo, de nada sirve tener un motor gr co excelente a si el juego carece de un material gr co con una calidad a suciente. A continuaci n se expondr n las partes principales: o a Gr cos : El apartado gr co del videojuego es el m s visa a a toso de todos. C mo basar este apartado es una de las o decisiones crticas para el resultado nal del juego. Hoy en da existen un gran n mero de motores gr u a cos y libreras que facilitan mucho el trabajo en este punto. La elecci n de uno u otro condicionar n el reno a dimiento y la portabilidad de nuestra aplicaci n. M s o a adelante se expondr n las opciones m s importantes a a hoy en da en el mundo del software libre. Sonoro : Tambi n es un punto a tener en cuenta, aunque en e esta ocasi n no existe una posibilidad de elecci n tan o o grande como en el punto anterior. Existen una gran variedad de libreras que permiten que el videojuego pueda leer una gran variedad de formatos de sonido,

incluso de libreras que dan un paso m s y nos brin a dan la posibilidad de dotar de caracteristicas avanzadas y bastantes novedosas al videojuego; por ejemplo, sonido cuadraf nico. o L gica : El juego ha de tener un motor de l gica, m s o o o a menos complejo, que haga que el juego presente una cierta complicaci n a los ojos del jugador. Hoy en da o los motores l gicos de los juegos se basan en t cnicas o e de inteligencia articial: algoritmos de caminos mni mos, m quinas de estado para implementar el coma portamiento de los oponentes, etc. Media : Los gr cos, sonidos, modelos o texturas que se a van a utilizar en el juego tambi n son un punto a tee ner en cuenta. En este punto es probable que se vea involucrada una persona con un perl fuera del campo de la inform tica, lo que en algunas ocasiones no a es f cil encontrar en el mundo del software libre. a 4. LIBRERIAS LIBRES Como ya se ha expuesto anteriormente, existen una serie de libreras libres que facilitan mucho el desarrollo de videojuegos. En el presente apartado se van a exponer algunas de ellas: 4.1. 3D OpenGL : Se trata un API para desarrollar aplicaciones gr cas. Fue creado inicialmente por Silicon Grapa hics en 1992 y actualmente es uno de los estandares m s importantes en la programaci n de aplicaa o ciones con capacidades 3D. Silicon Graphics en un principio desarroll una librera para que las aplicao ciones de sus estaciones gr cas Iris fuesen portaa bles entre unos modelos y otros. El nombre de esta librera era Iris GL fu la predecesora de lo que ac e tualemente es OpenGL. Una de las grandes ventajas de OpenGL es que se trata de una tecnologia abier ta, y por lo tanto no esta controlada por una unica compa ia. En este caso, existe un comit de estann e darizaci n, el OpenGL ARB (OpenGL Architecture o Review Board). Los miembros de fundadores de este comit son empresas tan importantes como: SGI, e Digital Equipament Corporation, IBM, Intel y Microsoft. Actualmente 3Dfx (hoy NVidia), 3DLabs, ATI, Evans & Sutherland, Hewlett-Packard, NVidia o Sun Microsystems. Otra de las ventajas de este sistema es la gigantesca base de conocimientos que existe a su alrededor. A lo largo de sus nueve a os de vida se n han escrito cientos de artculos, libros y programas li bres con los que cualquiera puede aprender a utilizar este motor gr co. a

Crystal Space : Se trata de un motor 3D libre. Su desarrollo comenz en 1998 y actualmente es bastante conoo cido y usado en el desarrollo de juegos Open Source. Las principales caracteristicas de Crystal Space son: 1. Se trata de un motor con seis grados de libertad. Esto quiere decir que la c mara se puede mover a y rotar en cualquier direcci n en el mundo virtual que o se est renderizando para el juego. Este es un aspeca to que se da por supuesto en los dos anteriores engines, pero que no cumplen todos. Hace unos a os, n la potencia de las m quinas no era suciente como a para esta clase de render en tiempo real. Ante este problema, la soluci n que se adopto por regla geneo ral fu restringir los grados de libertad. Gracias ese ta optimizaci n, juegos tan famosos como Quake son o ejecutables en m quinas con una potencia reducidad a (desde el punto de vista de las m quinas actuales). En a Quake, por ejemplo, no es posible girar el punto del espectador de lado (giro con la misma Z y distinto X e Y). 2. Se trata de un motor muy portable: Actualmente soporta plataformas tales como: GNU/Linux, GNU/HURD, FreeBSD, NetBSD, DOS, win32 (Windows 9x/NT/ME/2000/XP), MacOS/X, MacOS/X Server 1.0, etc. Open Inventor : OpenInventor es un entorno de desarrollo creado por Sillicon Graphics. Se basa por completo en OpenGL y proporciona un entorno de trabajo para C++ sobre el que desarrollar aplicaciones 3D. Presenta un modelo de programaci n basado en el manejo o de escenas tridimensionales que simplican de una forma dr stica la programaci n de esta clase de aplia o caciones. Incluye un gran conjunto de objetos sobre los que trabajar: cubos, polgonos, texto, materiales, c maras, luces, etc. Actualmente, Open Inventor es a un producto libre, ya que SGI liber su c digo poco o o despu s de hacer lo mismo con una implementaci n e o de OpenGL. En este momento, las tres plataformas en las que tiene m s fuerza Open Inventor son: estacioa nes gr cas de SGI, GNU/Linux y Windows. a 4.2. 2D SDL : es una librera libre y multiplataforma enfocada a servir de base en el desarrollo de videojuegos. Actualmente SDL est siendo usada en varios juegos comera ciales (Civilization: Call To Power, Myth II Soulblighter, Railroad Tycoon II o Hopkins F.B.I., entre otros). Esta librera es el resultado de una empresa que se dedicaba a portar juegos a GNU/Linux. Desde el primer momento SDL ha sido libre y Loky Games, su creadores, han desarrollado juegos comerciales basados en ella. Al contrario que otras libreras, SDL

no s lo tiene en cuenta el punto de vista gr co de o a la aplicaci n, si no tambi n otros aspectos importano e tes en un videojuego, como el Sonido, el acceso al CD-ROM, la posibilidad de usar Joysticks, etc. Otro de los puntos fuertes de SDL es su simplicidad. Un programador que quiera comenzar a usar esta librera unicamente tiene que estar familiarizado con la programaci n gr ca, el API de la librera es simple e o a intuitivo, por lo que la curva de aprendizaje hasta dominar SDL ser muy suave. Desde el punto de visa ta de las aplicaciones gr cas y en concreto juegos, a la portabilidad es un aspecto que tiene cierta importancia, y que en muchas ocasiones se ha descuidado. SDL es una soluci n parcial para este problema, pero o desde cualquier punto de vista, muy interesante. Aun trat ndose de una librera de bajo nivel, proporciona a una portabilidad asombrosa. Allegro : Se trata de una librera parecida a SDL en sus objetivos, pero muy anterior en el tiempo. La primera versi n de Allegro funcionaba sobre MS-DOS, y o desde ah se ha portado y mejorando durante a os. n Al igual que SDL proporciona herramientas para trabajar con im genes, sonido y perif ricos. A lo largo a e de su extenso desarrollo se han incluido funcionalidades: trabajar con n meros en coma otante, c lculos u a para programas con gr cos tridimensionales, manea jo de la entrada/salida de cheros, compresi n, etc. o Una vez m s se trata de software libre, y hay dispoa nible un grandisimo n mero de programas que hacen u uso de esta librera, as como documentaci n y recur o sos. 4.3. Sonido OpenAL : Una librera tiene dos puntos fuertes. En primer lugar es una plataforma neutra para el trabajo con sonido. Por otro lado, se trata de la opci n m s exteno a dida a la hora de dotar a los videojuegos de sonido cuadraf nico. o SDL mixer : Quiz una de las libreras mas usadas para a dotar de sonido a videojuegos libres. Al igual que SDL es altamente portable y muy potente. Es posible utilizar, de forma transparente para el programador, libreras como libogg/libvorbis, mikmod o libsmpeg. Esto proporciona al desarrollador un amplio abanico de posibilidades sobre qu formatos de sonido utilizar e en el videojuego. 5. MAS RAPIDO TODAVIA El presente artculo es parcialmente el resultado de un proyecto en el que se tuvo que desarrollar un videojuego en

un tiempo record. En el momento de comenzar el proyecto hubo que valorar cada una de las opciones en cada uno de los puntos implicados en el videojuego para tomar una opci n sobre c mo se iba a realizar el planteamiento o con que o o herramientas se iba a desarrollar. El tipo de juego y su funcionamiento era un requisito del proyecto: Un juego de estrategia con un gran peso en la inteligencia y comportamiento global de los personajes. Algo parecido a juegos tan famosos como Civilization o StarCraft. Se realiz un estudio de sobre todos los puntos anterioro mente expuestos, y como resultado de sopesar cada uno de los puntos se tom la siguiente decisi n: o o Como libreras b sica sobre la que desarrollar los gr a a cos se opt por SDL. Esta elecci n se vi condicionada por o o o el background de la gente implicada en el proyecto, aunque desde un punto objetivo SDL es una de las dos mejores libreras libres de esta clase. Para el apartado sonoro se opt por SDL Mixer, un uso o mucho m s simple que OpenAL y que el manejo rawdel a sonido fueron las principales razones para este elecci n. o Una vez tomadas estas dos elecciones t cnicas, quedaba e aun una por tomar: el lenguaje del programaci n sobre el o que se iba a realizar el desarrollo. En princio parecia l gico o optar por C: es el lenguaje por excelencia, y para el desarrollo de un juego es el m s adecuado por razones de eciencia. a Esta ultima decisi n era una de las que m s podan cono a dicionar que el desarrollo del videojuego llegase a buen puerto. El desarrollo en C no es r pido, y la restricci n m s fuera o a te del proyecto era el tiempo de desarrollo. Llegados a este punto era necesario buscar un lenguaje de alto nivel sobre el que desarrollar el juego, de otra forma, no sera posible terminarlo en el plazo jado. La mejor opci n como lenguaje de muy alto nivel que o encontramos fue Python. Un lenguaje potente, simple y extendido con una gran base de conocimientos disponible. Python permita desarrollar la l gica del juego de una forma o agil: con primitivas y tipos abstractos de datos de alto nivel y sin preocupaciones con el manejo de memoria. Ahora bien, la opci n por Python poda hacer que el deo sarrollo fuese muy r pido, pero al ser un lenguaje interprea tado, la ejecuci n fuese realmente lenta. Este era un tema o peliagudo que haba que probar. Para ello se utiliz PyGa o me, un wrapper para Python de SDL. Los resultados fueron algo decepcionantes, realizando una simulaci n del juego o a una resoluci n considerable los resultados visuales eran o algo pobres por problemas de eciencia. 6. UNA APORTACION AL DESARROLLO DE VIDEOJUEGOS LIBRES La elecci n sobre tecnologa estaba tomada, pero existan o serios problemas de eciencia si se basaba el juego en Py-

Game. Para el proyecto SDL y Python seguan siendo las mejores opciones te ricas, aunque en la pr ctica viesemos o a que el resultado no era demasiado bueno. Este problema estara solucionado si existiese una li brera como PyGame pero con nivel de abstracci n supe o rior, en la que los tipos b sicos ya fuesen de alto nivel e a implementados nativamente. Existe una librera gr ca lla a mada Kyra que encajaba perfectamente con estas necesidades: dispone de tipos nativos de alto nivel, est bajada en a SDL y es libre. Para el desarrollo del videojuego sera perfecto poder utilizar Kyra desde Python. Y aqu es donde comienza la aportaci n. El primer paso para el desarrollo del juego fu el o e desarrollo de PyKyra, el binding de Kyra para Python. 7. PYKYRA Se trata de una librera de muy alto nivel para el desarro llo de videojuegos. Disponde de todos los tipos nativos que proporciona Kyra: Sprite, Image, Canvas, etc.. con lo que el nivel respecto a PyGame es considerablemente m s alto. a El desarrollo de PyKyra no se ha limitado a realizar un binding. PyKyra incorpora funcionadidades adicionales a las proporcionadas por Kyra: Sonido : Por defecto es posible usar s nido, de una foro ma completamente transparente. Soporta, gracias a SDL Mixer, formatos tales como MP3, OGG o WAV. Carga de imagenes : Kyra puede leer imagenes desde imagenes desde cheros de datos propios, pero no desde un chero como PNG, JPEG, GIF. PyKyra a ade esta n posibilidad con la intenci n de intentar expandir las o posibilidades del motor. Soporte de video MPEG : Con PyKyra es posible mostrar videos MPEG con una carga para la aplicaci n poco o superior a la generada para descomprimir este formato de forma nativa. Al margen de estas nuevas funcionalidades, se ha simplicado de una forma dr stica la interface de Kyra con el a objetivo de que, a la hora del desarrollo de un videojuego basado en Kyra, la parte m s importante sea la de la l gica a o y que los gr cos y el s nido sea algo que se implemente de a o una forma r pida y sin complicaciones. a

 HERRAMIENTAS BASICAS DE DESARROLLO Carlos Alberto Paramio Danta carlos.paramio@hispalinux.es

RESUMEN El lenguaje de programaci n m s usado en el desarrollo de o a aplicaciones para entornos Unix es, sin duda C, seguido de cerca por C++. El proyecto GNU elabor en su da un como pilador multiplataforma que adem s es extensible a varios a lenguajes. Tambi n se dispusieron una serie de herramiene tas adicionales que facilitan la labor del programador a la hora de afrontar cualquier proyecto. En este documento se explican algunas de las m s comunes en todo desarrollo, y a se ver n ejemplos de utilizaci n de las mismas. a o 1. INTRODUCCION Cuando iniciamos el desarrollo de un programa, adem s a del compilador para nuestro lenguaje, es imprescindible el uso de un depurador que nos permita encontrar y reparar errores de nuestro software de una manera productiva. GNU Compiler Collection es un compilador desarrollado por el proyecto GNU, capaz de generar c digo para diferentes plao taformas hardware, y desde diversos lenguajes de programaci n diferentes. Tambi n nos proporcionan un potente depuo e rador que es capaz de interpretar el c digo de cada uno de o estos lenguajes, de forma que sea sencillo hacer un seguimiento de la ejecuci n de nuestro programa. o Adem s, puede sernos de mucha utilidad que ejecutea mos nuestro software a trav s de un proler, como puede ser e gconf, ya que este nos proporcionar suciente informa a ci n para detectar cuellos de botella en nuestro programa, o que ser n susceptibles de optimizar. a En aplicaciones grandes, es bastante habitual (y aconsejable) que el c digo que conforma nuestra aplicaci n se o o halle repartido en distintos m dulos, los cuales deben ser o compilados a c digo objeto uno a uno, para despu s inteo e grarlos formando la aplicaci n nal. Las dependencias de o estos m dulos exigen adem s una compilaci n ordenada, y o a o cualquier cambio en un m dulo puede suponer la necesidad o de recompilar muchos otros. Es conveniente automatizar este proceso, de forma que se realice transparentemente, y de ello se encarga la herramienta make. No hay que olvidar que, desde que la proliferaci n de los o sistemas UNIX ha ido en aumento, han surgido diferentes implementaciones; antes de que se estableciese el est ndar a POSIX, esto dio lugar a un tremendo caos, que obligaba a

los desarrolladores interesados en hacer su software multiplataforma a usar diversos articios, que permitiesen la migraci n de su programa a otros sabores de UNIX. A n cuano u do POSIX se dio a conocer, los diversos sistemas adoptaron dicho est ndar en distintas fechas, y a n existen ligeras dia u ferencias que seran una traba para nuestro prop sito. Fue o ron necesarias, entonces, el uso de ciertas herramientas que facilitaran la adaptaci n de nuestro c digo a estas posibles o o diferencias, y adem s que dicha tarea fuese lo m s automaa a tizada posible, para que el futuro usuario pudiese compilar el paquete de software sin necesidad de realizar complicados pasos. Aunque existen muchos programas que cumplen estas especicaciones, son de destacar los elaborados desde el proyecto GNU: autoconf, automake y libtool. Debido a la limitaci n de tiempo y espacio para esta poneno cia, se tratar unicamente la primera de ellas, que en muchos a casos es suciente. Todo este conjunto de herramientas har que podamos a centrarnos en el desarrollo en s, que este sea de calidad y lo m s exento posible de errores, y que no tengamos que preoa cuparnos de detalles de portabilidad, aumentando nuestra productividad. 2. GCC O GNU COMPILER COLLECTION El compilador de GNU, si bien est formado por dia versas partes, puede funcionar como un todo, permitiendo la modicaci n de su comportamiento a trav s de diversos o e par metros. Como ya se ha comentado, dispone de varios a front-ends que generan c digo objeto desde distintos leno guajes. Si bien soporta tambi n diferentes formatos de bie narios, el m s usado es el formato ELF. a GCC, al igual que la mayora de los compiladores, di vide su proceso en varias fases. Si no le indicamos nada especial, intentar pasar a lo largo de todas las fases, para a generarnos el ejecutable nal. Es posible, no obstante, indicar que se detenga tras una fase en concreto. He aqu una peque a lista: n Preprocesado Compilaci n o Ensamblado

Enlazado Algunos par metros que controlan la compilaci n son a o los siguientes: -E -S -c -o -ansi -std=xxx S lo preprocesa o S lo compila; no ensambla o enlaza o Compila y ensambla, pero no enlaza Coloca la salida en chero indicado Usa el est ndar ANSI C89 (en C) a xxx = Est ndar a seguir (c89, c99...) a

go objeto necesario de cada m dulo o biblioteca. El proceo dimiento a seguir sera el siguiente: bash$ gcc -c foobar.c} bash$ ls foobar.c foobar.h foobar.o main.c bash$ gcc -o miprograma foobar.o \ -L/usr/lib/glib -lglib bash$ ls foobar.c foobar.h foobar.o main.c miprograma Las opciones de compilaci n de GCC son muy diversas o y variadas, y es conveniente estudiarlas en detalle. Normalmente hay un documento en lnea disponible en la mayora de las m quinas UNIX, que puede consultarse mediante el a comando info gcc. Su lectura es altamente aconsejada. 3. LA HERRAMIENTA MAKE Con make podemos denir las dependencias que existen entre nuestros m dulos, as como el proceso a seguir o para obtener las distintas partes intermedias de la compilaci n. Esto permitir que generemos el ejecutable de nueso a tro programa de un plumazo, recompilando si es necesario aquellas partes que han sufrido cambios. La sintaxis de make es sencilla. Las reglas mencionadas se describen en un chero de nombre makefile o Makefile. Se componen de un objetivo intermedio (o nal), un conjunto de prerequisitos (dependencias), y un grupo de comandos que, al ser ejecutados, generan el objetivo. El formato de escritura de estas reglas es el siguiente: objetivo : prerequisitos ... comando ... ... Hay que destacar que la indentaci n establecida para cao da uno de los comandos no es trivial. Todos los comandos deben ir precedidos de un tabulador. Es importante que no se sustituya por un grupo de espacios, ya que entonces make no interpretara correctamente nuestra regla. El tabulador es imprescindible. Veamos un ejemplo de chero makefile, para nuestra situaci n hipot tica mencionada anteriormente: o e miprograma : main.o foobar.o gcc -o miprograma main.o foobar.o \ -L/usr/lib/glib -lglib main.o : main.c foobar.h gcc -c main.c foobar.o : foobar.c foobar.h gcc -c foobar.c

El par metro -o nos permite establecer el nombre del a chero de salida. Si lo usamos sin ning n otro, obtendremos u un ejecutable con el nombre indicado tras dicho par metro. a En otro caso, el nombre por defecto es a.out. Por otro lado, para el desarrollo en lenguaje C, el compilador GCC normalmente usa ciertas extensiones al lenguaje proporcionadas por GNU. Estas extensiones a aden caracn tersticas como un nuevo tipo de datos (long long, ente ro de 64 bits), rangos para los case, y otras. No obstante, como se ha visto, pueden utilizarse algunos est ndares coa mo ANSI C89 o C99 (este ultimo est parcialmente sopor a tado), desabilitando de esta forma las extensiones. Para que el compilador emita los warnings debidos al incumplimiento de dichos est ndares, ha de usarse adem s el par mea a a tro -pedantic. Tambi n es posible usar -pedantice error, para emitir errores en lugar de warnings. Para nalizar, hay que indicar a GCC el uso de las distintas bibliotecas de funciones, de forma que este pueda en lazar correctamente nuestra aplicaci n con las mismas. Las o bibliotecas disponibles en nuestro sistema normalmente se sit an en /lib, /usr/lib o /usr/local/lib. Cuanu do usemos una de estas bibliotecas, lo se alaremos usando n el par metro -l seguido del nombre de la biblioteca, elia minando el prejo lib inicial. Por ejemplo, si nuestro programa hace uso de funciones de la biblioteca libgtk, indicaremos -lgtk. No hace falta incluir la biblioteca est ndar a de C (libc), salvo la parte correspondiente a las funciones matem ticas (libm). Si las bibliotecas estuviesen situadas a en un lugar distinto a los habituales, puede avisarse de ello a GCC con el par metro -L, seguido de la ruta a los cheros a de biblioteca. Los cheros include con las cabeceras de estas bibliotecas tambi n pueden hallarse en una ruta diferente e a la habitual. Es posible indicar rutas alternativas mediante -I seguido de la ruta. Como el mejor profesor es un buen ejemplo, veamos uno que cubra la mayor parte de lo visto hasta ahora. Imaginemos que tenemos un programa compuesto por dos m duo los: main.c (que contiene la funci n main de nuestro proo grama) y foobar.c (con funciones adicionales). Adem s, a usamos una biblioteca llamada libglib que, casualmente, est situada en una ruta no habitual: /usr/lib/glib. a Queremos generar un ejecutable miprograma, con el c dio

Para compilar nuestro programa, nos bastara con eje cutar make miprograma desde el directorio donde est n a situadas las fuentes y el chero makefile. Por defecto, si no se indica el objetivo que se desea crear, make usar el a primero de los objetivos denidos. Por tanto, si hubi semos e usado make, a secas, en este caso, obtendramos el mismo resultado: bash$ make gcc -c main.c gcc -c foobar.c gcc -o miprograma main.o foobar.o -L/usr/lib/glib -lglib Como puede observarse, hemos declarado una regla para nuestro ejecutable miprograma as como para los c di o gos objeto intermedios de sus diferentes m dulos. Adem s, o a como prerequisitos, hemos establecido para cada m dulo o tanto su c digo fuente original como el de las cabeceras que o incluye. De esta forma, si algo cambiase en las cabeceras, o en el c digo en C, el m dulo debe recompilarse para que el o o c digo objeto reeje los cambios. Las diferentes partes de o nuestra aplicaci n son generadas ordenadamente para cumo plir con las exigencias de dependencias que necesita cada una. Es interesante conocer c mo sabe make cuando debe o recompilar un m dulo, de forma que entendamos mejor el o proceso, y podamos controlarlo a voluntad. Al intentar obtener el objetivo, primero observa sus dependencias, y trata de resolverlas, consider ndolas ahora su objetivo principal. a Una vez resueltas las dependencias, se proceder a la creaa ci n del objetivo. Cuando se decide por un objetivo detero minado, lo primero que hace es comprobar si ya existe (si ya est compilado). Si no lo est , entonces simplemente ejecua a ta los comandos indicados para ese objetivo. Si, en cambio, ya existe, entonces realiza una comprobaci n de fechas. En o caso de que el objetivo tenga una fecha y hora de modicaci n mayor que sus dependencias, entonces se presupone o que el objetivo est actualizado; en cambio, si alguna de las a dependencias posee una fecha mayor que el objetivo, este debe ser l gicamente actualizado. o Los cheros makefile pueden tambi n contener ciere tas reglas que no poseen dependencias, y que nos permiten automatizar algunas otras tareas. Por ejemplo, podramos incluir una regla clean, de tal forma que al hacer make clean se eliminen del directorio de fuentes todo aquello que forma parte del proceso de compilaci n: cheros objeo to, programas ejecutables, etc. De esta forma, el directorio contendra de nuevo s lo los fuentes de nuestra aplicaci n. o o Para denir estas reglas sin prerequisitos, lo correcto es indicar previamente que se trata de una regla de este tipo, mediante la palabra reservada .PHONY. Luego, se escribe la regla como anteriormente. As: .PHONY : clean

clean : rm -f *.o miprograma Tambi n es posible denir variables, de forma que en e alguna parte de la regla se usen estas en lugar del texto co rrespondiente. As, eliminamos alguna parte reiterativa, o bien facilitamos la edici n del chero makefile para que o pueda adaptarse a otros entornos. Por ejemplo, podramos usar una variable CC cuyo contenido sea el nombre del ejecutable del compilador de C. As, en todas las lneas donde se use el mismo, sustituiramos gcc por $(CC). La varia ble estara denida al principio de nuestro makefile, de esta forma: CC=gcc Al igual que con GCC, tenemos disponible una ayuda en lnea, que podemos consultar con info make. Tam bi n encontraremos imprescindible el manual editado en el e Proyecto GNU [1]. 4. EL DEPURADOR GDB Para poder depurar nuestro programa, previamente lo habremos compilado de forma que incluya informaci n de o depuraci n, para que sea posible el seguimiento en el leno guaje fuente, la resoluci n de nombres de funciones y de o variables, etc. Esto es tan sencillo como a adir el par metro n a -g al compilador GCC. Como es l gico, el c digo compilao o do de esta forma ocupa m s espacio que aquel que fue consa truido sin opciones de depuraci n. Por tanto, es conveniente o que el programa nal sea compilado sin esta informaci n o adicional. Comenzamos nuestra sesi n de depuraci n ejecutando o o nuestro programa a trav s de gdb, simplemente tecleando e gdb miprograma. Desde gdb, podemos por ejemplo ver el listado de nuestro programa con el comando list, y a adir puntos de pan rada (breakpoints) con el comando break. Podemos establecer dichos puntos de parada ya sea nombrando la funci n en la que queremos que se detenga, o bien el n meo u ro de lnea del c digo fuente de nuestro programa: o GDB 5.2.1, Copyright 1999 Free Soft... (gdb) list 1 #include "foobar.h" 2 3 int main(int argc, char *argv[]) { ... (gdb) break 5 Breakpoint 1 at 0x804834c: file main.c, line 5. Una vez detenido, podemos visualizar el contenido de las variables de la aplicaci n, modicarlas, visualizar la pila o

de ejecuci n (para comprobar las llamadas a funciones que o se han hecho hasta entonces), o continuar la ejecuci n, ya o sea paso a paso o como lo hara normalmente. He aqu una peque a tabla con algunos de los coman n dos m s utiles. Cuando un par metro aparece entre corchea a tes signica que es opcional: list [n] break n run [n] print exp display exp next nexti continue bt Mostrar c digo fuente [desde lnea n] o Marca punto ruptura en lnea o fun. n Comienza ejecuci n [con argumentos n] o Muestra valor de expresi n exp o Muestra cada vez que avanza un paso Avanza un paso a trav s de subrutinas e Avanza 1 instrucc., procede subrutinas Contin a la ejecuci n del programa u o Imprime contenido de pila de ejecuci n o

aquellas m s llamadas (para eliminar el retardo de resolua ci n de la llamada) y mejorando el c digo en s. o o Para compilar nuestra aplicaci n de forma que gconf o pueda posteriormente extraer toda esta informaci n, simo plemente a adimos el par metro -pg al compilador GCC. n a Una vez hecho esto, procedemos a ejecutar el programa en s, y tras salir correctamente de el (al nalizar main(), o tras un exit()), observaremos que se ha generado un nuevo chero en el directorio de trabajo llamado gmon.out. S lo nos queda pasar este archivo a trav s de gconf, con el o e siguiente formato:

gconf <opciones> <ejecutable> <gmon.out> En nuestro sempiterno ejemplo de programa, haramos gconf miprograma gmon.out. Hay una opci n que merece la pena destacar, que nos o muestra el c digo fuente de nuestro programa junto con un o conteo de ejecuciones por lnea. Esta opci n se activa con o el par metro -A. a Una vez m s, ampliaremos nuestros conocimientos acera ca de esta herramienta usando el comando info gprof, o bien con la lectura del manual de GNU [3]. 6. LA HERRAMIENTA AUTOCONF Terminamos viendo una herramienta que, con el tiempo, se ha convertido en una de las m s utiles y necesarias a a la hora de desarrollar software multiplataforma. Las diferencias entre estas obliga al programador a conocerlas con detalle. Con autoconf, podremos generar un script que nos evite la mayor parte del trabajo. Este script, llamado configure, generar unos cheros makefile modia cados para adaptarse a nuestro sistema. El modo de funcionamiento de autoconf se basa en el uso de macros m4 para resumir las operaciones de comprobaci n que deben hacerse. Estas macros comienzan too das con el prejo AC y son sustituidas por una porci n de o c digo en el lenguaje de script de una shell tipo Bourne. o Las macros se denen en un chero configure.in, y al ser procesado este chero con autoconf, se generar el correspondiente script configure. S lo dos maa o cros son imprescindibles para nuestro programa: AC_INIT(fichero_unico_fuentes)

Por ejemplo, una vez establecido el punto de ruptura anterior, podramos haber comenzado la ejecuci n, esperar a o que gdb detenga el programa, y mostrar el contenido de la variable entera argc, para nalizar observando los marcos de la pila de ejecuci n: o (gdb) run Starting program: miprograma Breakpoint 1, main ... 5 printfoobar("Hola, soy foobar"); (gdb) print argc $1 = 1 (gdb) bt #0 main (argc=1, argv=0xbffff7a4) at... #1 0x4004112d in __libc_start_main()... El depurador gdb dispone de una ayuda interna, que puede ser invocada con help. Esto mostrar una lista de a secciones en las que est n divididas los distintos comana dos que podemos usar para controlar nuestro programa. Con s lo hacer help seccin, observaremos una de esas liso o tas, y help comando nos ofrecer una breve ayuda acera ca de un comando concreto. No obstante, al igual que las herramientas anteriores, se dispone de una ayuda en lnea en formato texinfo, invocable a trav s de info gdb. Tambi n hay un manual t cnico e e e elaborado por el Proyecto GNU [2]. 5. EL PROFILER GPROF Como ya se dijo, a menudo deseamos optimizar el rendimiento de nuestro programa, pero en determinadas ocasiones resulta difcil conocer d nde est n localizados los o a cuellos de botella. Bien podra ser una funci n que consu o ma una gran cantidad de tiempo de ejecuci n, como alguna o otra que, aunque muy r pida, se ejecuta demasiadas veces. a Esto nos permitir optimizar de manera adecuada nuestra a aplicaci n, sustituyendo por macros o funciones inline o

La llamada a AC INIT comprueba que existe el chero indicado para asegurarse de que se encuentra en el directorio correcto. En nuestro ejemplo, podramos usar main.c. Se utiliza al comienzo del chero de conguraci n. o La otra llamada se sit a al nal del chero, e indica u d nde se recogeran los resultados de la ejecuci n del script. o o Normalmente, el destino es el chero makele:

AC_OUTPUT(fichero_salida) Una vez que nuestro script est listo, tras procesar el e chero configure.in con autoconf, este necesitar de a un chero adicional makefile.in que contenga nuestras reglas de compilaci n. S lo que en este chero, usaremos o o expresiones como CC=@CC@ que ser n sustitudas por el a script con el valor adecuado al generar el makefile nal. Tambi n podemos hacer exportar ciertas deniciones a e un chero config.h, que incluiremos en nuestros fuentes, sin m s que denir el correspondiente config.h.in a y usar la macro AC CONFIG HEADER para establecer dicho chero de cabecera. Para facilitar la tarea de escritura de la cabecera config.h.in, tenemos a nuestra disposici n una herramienta que viene con autoconf, llamao da autoheader. Una vez que nuestro configure.in est listo, la usaremos para crear la cabecera de entrada. e En configure.in podemos introducir comentarios, simplemente precedi ndolos del modicador dnd al princie pio de la lnea. Las macros que hay disponibles son muy numerosas, y como dicta la intuici n, se pueden crear macros nuevas. o Para este particular, es recomendable leer la gua en lnea del lenguaje de macros M4, con info m4. Algunas macros de ejemplo son las siguientes: AC PROG CC : Decide qu compilador de C usar, seteane do la variable CC. AC CHECK PROG (prog) : Comprueba que el programa existe en el path actual. AC CHECK LIB (lib, fun, action1, action2 : Determina si la funci n fun existe en la librera lib intentando o enlazar un programa con lib. Ejecuta action1 si el test result ser correcto, o action2 en caso contrario. o AC CHECK HEADER (head) : Determina la existencia de la cabecera head. AC C BIGENDIAN : Si los words (palabra del procesador) son guardados con los bits de mayor peso primero, entonces dene WORDS BIGENDIAN. AC C INLINE : Si el compilador no soporta las palabras clave inline, inline o inline, entonces dene inline como una cadena vaca. AC CONFIG HEADER : Fichero de cabecera donde ir n a las deniciones pertinentes para el c digo fuente de o nuestro programa. Como siempre, una de las mejores referencias de documentaci n se encuentra en el comando info autoconf. o Tambi n en este caso, se elabor un manual t cnico [4] que e o e es perfecto como material complementario.

7. BIBLIOGRAFA [1] Richard M. Stallman and Roland McGrath, GNU Make, Free Software Foundation, April 2000. [2] Richard M. Stallman and Roland H. Pesch, Debugging with GDB, Free Software Foundation, April 1998. [3] Jay Feulason and Richard M. Stallman, GNU gprof, Free Software Foundation. [4] David MacKenzie and Ben Elliston, Autoconf, Free Software Foundation, July 2001.

 JAMES: UNA ALTERNATIVA LIBRE PARA LA COORDINACION DE GRUPOS DE TRABAJO Jos Ignacio Centeno, Pablo Fern ndez, Manuel Resinas, Jos Ignacio Villar, e a e Jorge Sede o, Diego Campoy, Juan M. Pi ero, Antonio M. Guti rrez, n n e Olga Domnguez, Diana de Lara del Rey, Antonio Chaparro y Rafael Sep ulveda E.T.S. Ingeniera Inform tica, Universidad de Sevilla a james@talika.eii.us.es http://talika.eii.us.es/james/
RESUMEN JAMES es un entorno modular de ayuda a la coordinaci n de (y entre) grupos de trabajo. La idea principal del o proyecto, est abierta a m ltiples aplicaciones en entornos a u de trabajo heterog neos. Como campo de aplicaci n inicial, e o han sido desarrollados una serie de m dulos, orientados a o la gesti n del conocimiento en estructuras docentes de too do tipo. De esta forma, el sistema desarrollado, podr ser a utilizado como entorno de ayuda a la ense anza. n Con el n de proporcionar una amplia difusion al sistema, se han elegido tecnologias que pertenecen a la comunidad de software libre: PHP y MySQL. El uso de estas potentes herramientas junto con la excelente documentacion de la que goza la comunidad ha permitido un desarrollo muy productivo y de gran escalabilidad. m dulos. Mediante esta arquitectura, se pretende alcanzar o un entorno que se caracterice por su gran capacidad de escalabilidad en 360o ; que sea capaz de adaptarse de manera precisa y sencilla, a las nuevas necesidades funcionales que pudiesen aparecer en cada momento. Por su parte, el mencionado motor central, proporciona un interfaz homog neo de interacci n con la capa de dae o tos, y un entorno de ejecuci n conocido. De esta forma, el o proceso de construcci n de m dulos es un mecanismo emio o nentemente sencillo, en el que el desarrollador de m dulos, o no debe conocer en profundidad el sistema, sino que puede limitarse a estudiar los puntos de interacci n con este, que o est n claramente denidos y documentados. Esta estructura a permite que el desarrollador de m dulos pueda desprocuo parse de los detalles del entorno y centrarse en la l gica de o la aplicaci n que est construyendo. o e El sistema que se expone tiene como interfaz una aplicaci n Web ligera, en la que se ha hecho especial incapi en o e la estandarizaci n a nivel de cliente. As se consigue que no o sean necesarios excesivos requisitos y que sea multiplataforma, tanto a nivel de hardware (PCs, Puntos de informaci n o no asistidos, terminales modo texto, PDAs, etc...) como a nivel de software (SO, navegador, etc...), sin por ello perder funcionalidad alguna. Con todo esto, se pretende conseguir un entorno en el que el usuario pueda integrarse de manera uda en un sis tema colaborativo centralizado que aproveche los medios y las posibilidades que nos brindan las redes inform ticas de a comunicaci n que existen actualmente. o 1.1. Aplicaci n en un entorno concreto, la Universidad o La evoluci n de las nuevas tecnologas, trae aparejada o una evoluci n en los modelos sociales que conocemos, y o por tanto, modicaciones en los modelos de ense anza, que n habr n de explotar las nuevas posibilidades que se nos prea senten. Con la irrupci n de la Web, en las las relaciones o profesor/alumno, se puede llegar a obtener una efectividad

1. INTRODUCCCION El hombre, como animal social, vive inmerso en un universo de relaciones interpersonales, de las que se vale, para conformase como individuo en los distintos grupos humanos a los que esta vinculado. La aparici n de la nuevas teco nologas ha supuesto la creaci n de grupos interrelaciona o dos que responden a la idea de aldea global de McLuhan, quien describi la evoluci n de la sociedad como el resultao o do de la transformaci n de sus medios de comunicaci n. o o Sobre estos planteamientos y con la intenci n de dar o una respuesta optima a los problemas que de ellos devie nen, surgen las motivaciones que impulsaron el desarrollo del proyecto que hoy se presenta: JAMES, un entorno inform tico que potencie los sistemas colaborativos que las a personas forman entre si, y en el que cada persona, sea capaz de enriquecerse a trav s de su relaci n con los otros y e o con el medio. La estructura de JAMES se basa en un n cleo central de u gesti n, que se encarga de la coordinaci n entre diferentes o o

que no puede ser alcanzada por el m todo cl sico a secas. e a Se es capaz de llegar a una gran cantidad de personas minimizando el esfuerzo y haciendo m xima la cantidad de a conocimientos que quedan al alcance de cualquier alumno o profesor. Es importante resaltar que el proyecto no es un nuevo m todo de ense aza que intente suplantar al m todo cl sico, e n e a sino que trata de ser una herramienta que lo complemente y le dote de todas las potentes herramientas y funcionalidades que las nuevas tecnologas pueden brindar a la Universidad. Asentados los conceptos sobre su ambito de aplicaci n, o podemos denir al proyecto JAMES (Just Another Modular Enviroment for Students), como un entorno modular de ayuda a la coordinaci n entre todos los grupos de trabajo, o que pueda haber en un entrono tan heterog neo, como es la e Universidad. JAMES permite el acercamiento entre el alumno y el profesor, mediante herramientas compartidas, en las que se abarcan desde tareas como la integraci n de fechas, realizao ci n de practicas, horarios de ex menes, hasta la resoluci n o a o de dudas, problemas y cuestiones de manera tanto personal como global a trav s de foros, FAQs, tutoras virtuales, e etc... Tambi n se da respuesta a los problemas de gesti n e o como pueden ser la informatizaci n de las calicaciones, o pruebas de conocimiento autoevaluadas, control de asistencia a pr cticas, etc... El sistema est preparado para cuala a quier requerimiento de funcionalidad que sea necesario en cada momento, pudiendo escalar cualquiera de las herramientas existentes o en su caso, integrando nuevos desarrollos. 2. ARQUITECTURA La idea fundamental que se ha seguido a la hora de dise ar la arquitectura del sistema, ha sido el conseguir una n estructura completamente modular. Con ello se pretende alcanzar un entorno con grandes posibilidades de escalabilidad e integraci n; adaptandose de manera precisa a las nueo vas necesidades funcionales que pudiesen aparecer en cada momento. 2.1. Conceptos Se tomaran de partida, una serie de deniciones que seran ampliamente utilizadas a lo largo del texto. De esta forma se tratar de dar una sem ntica precisa sobre cada uno a a de los puntos en el contexto de JAMES. Usuario: el signicado de este elemento es an logo al que a tiene en la mayora de sistemas de informaci n. El o sistema reconoce al usuario como la estructura de datos que permite guardar informaci n sobre la persona o

que accede al sistema en una determinada sesi n, proo porcionando un mecanismo de autenticaci n adeo cuado. M dulo: un m dulo es un subsistema que porporciona una o o determinada funcionalidad a un grupo. Debe de estar preparado para ser reutilizado por m ltiples gruu pos, dando a cada uno, un aspecto personalizado, y las garantas de buen funcionamiento situaciones de concurrencia. Como ejemplo de m dulo, podramos o mencionar el M dulo de Noticias. o Grupo: es junto a los M dulos, la piedra angular de Jao mes. Por Grupo entendemos a un conjunto de Usuarios que participan en el sistema con una determinado Rol. Cada grupo tiene asociados una serie de M duo los que le dotan de funcionalidad y puede, a su vez, tener otros subgrupos anidados. De esta forma se forma una estructura jerarquizada de grupos y, en cada caso, los m dulos act an como m todos del grupo. o u e Como ejemplo de grupo, podemos tener una asignatura o un grupo de practicas. Permiso: la mayoria de los m dulos, al implementar la funo cionalidad para la que est n dise ados, deben presena n tar una serie de comportamientos distintos, en funci n del usuario que los ha invocado. De esta forma, o algunos usuarios podr n realizar algunas acciones paa ra las que est n autorizados (ej: edici n, administraa o ci n, etc...). Para diferenciar los diferentes aspectos o a los que un ususario puede acceder, se utilizan los permisos. Cada m dulo dene una serie de permisos. o Un ejemplo de conjunto de permisos para el m duo lo de Noticias puede ser: Escribir Noticia, Borrar Noticia, Editar Noticia Leer Noticia. Rol: cada usuario, forma parte de un grupo con un determinado Rol, este elemento, determinar el grupo de a permisos de que dispondr el usuario en cada uno de a los m dulos que tiene el grupo. Un claro ejemplo de o Rol es .Administrador. 2.2. Interfaz El interfaz que se ha realizado est basado en la divisi n a o en distintas partes del area de trabajo. Con esto se consigue una cierta independencia entre las dos partes fundamentales: el arbol del sistema y el marco de ejecuci n de modu o los. Las estructuras troncales del sistema son las relativas a usuarios y grupos. Se ha utilizado un arbol como esquema gr co que proporcione una r pida navegaci n por los grua a o pos a los que un usuario esta adscrito. En el arbol, un usua rio, puede contemplar de un vistazo todos los grupos a los
2

que pertenece, ordenados (y agrupados) por tipos, y pudiendo expandir o cerrar los grupos para ver (u ocultar) sus diferentes m dulos y grupos anidados. o 2.3. Eventos Uno de los puntos mas relevantes del sistema es el dise o de un sistema unicado de comunicaci n entre m dun o o los. La infraestructura de comunicaciones elegida esta fuertemente basada en el concepto de evento. Dentro de JAMES se denomina evento, a un mensaje que es dirigido a un m dulo. Estos eventos son usados coo mo mecanismo de comunicaci n tanto entre el n cleo y los o u modulos, como entre los distintos m dulos entre s. o Gracias a las capacidades de comunicaci n, cada m duo o lo puede obtener una una visi n global del sistema en todo o momento, a partir de su comunicaci n con el resto de m duo o los. Esta caracterstica es de extrema importancia en siste mas web, debido a que la capacidad de reacci n a eventos o l gicos, se limita a acciones del usuario en un determinado o ambito. Gracias a la noticaci n va eventos se permite a ca o da m dulo (sin que est necesariamente cargado) personalio e zar el tratamiento de sucesos globales, como por ejemplo el de salida del sistema. Otro mecanismo de gran importancia que permite el sistema de eventos, es permitir a un m dulo comunicarse con o otro. En este caso, existe un m dulo que invoca un evento o de otro m dulo con una serie de par metros; en la mayora o a de las ocasiones. Este proceso est destinado a una comunia caci n tipo cliente/servidor, es decir, un m dulo solicita un o o determinado servicio a otro m dulo que, a su vez act a de o u servidor. En un ejemplo de aplicaci n, de este mecanismo, o un m dulo arbitrario (actuando como cliente) podra invoo car un evento del m dulo calendario para que este (actuando o como servidor), creara una cita o dijese si el usuario esta libre en una determinada fecha. Mediante el uso de eventos, se consigue un sistema fuertemente interrelacionado que permite una amplia gama de funcionalidades al servicio usuario. Para comprender con claridad la utilidad de este aspecto, se propone el siguiente caso real: Durante un determinado curso acad mico, un profesor e consider apropiado el uso del m dulo de Foro en su asigo o natura. En el foro, los alumnos han ido preguntando, respondiendo y opinando sobre diferentes temas de la asignatura; adem s, el profesor ha ido interviniendo para la aclaraci n a o de diferentes puntos. Llegado el n de curso, el profesor puede considerar oportuno publicar ciertos mensajes del foro y alguna de sus respuestas en el m dulo FAQ. Esta acci n o o se realiza desde el m dulo foro invocando el evento de puo blicaci n del m dulo FAQ. o o Aplicando el caso del ejemplo, se conseguira, con mni mo esfuerzo, ir creando una base de conocimiento organizada en el m dulo de FAQ, en la que los alumnos a o tras o n

a o pudieran buscar respuestas de un modo eciente y con n resultados satisfactorios. Este ejemplo, pone de maniesto la utilidad de los eventos en la interconexi n de dos m dulos, a primera vista, tan o o independientes como son el de Foro y el de FAQ. Como resumen podemos decir que a trav s del sistema de eventos e un m dulo puede ofrecer una serie de servicios cara a otros o m dulos independientemente de las funcionalidades espeo cicas para las que esta dise ado, permitiendo, a posteriori, n la creaci n de nuevas caractersticas sin que halla que moo dicar el m dulo que presta servicios. o 3. MODULOS En esta secci n se describen los m dulos del sistema. o o Dado que la primera implantaci n que se ha realizado en el o ambito universitario, existen algunos m dulos que son es o peccos para este contexto. Como se explic anteriomente, o la idea es que los m dulos que est n implementados sean o e reutilizados para crear sistemas colaborativos de cualquier naturaleza, por ello se ha hecho un fuerte hincapi en dotar e de un car cter generalista a la mayora de los m dulos. a o La lista de m dulos que estan implementados en este o momento son: M dulo para la generaci n de arboles de contenidos o o M dulo para la publicaci n de tutorias e informaci n o o o sobre profesores M dulo para la publicaci n de noticias o o M dulo de calendario o M dulo de foro o M dulo de FAQ o M dulo para la publicaci n de notas o o M dulo para la generaci n de examenes o o M dulo para la generaci n de documentaci n (fronto o o end a las sgmltools) M dulo de repositorio o 4. REFERENCIAS 1. Centeno, J.I., Fern ndez, P., Resinas, M., Villar, J.I.: a JAMES: Un entorno modular de ayuda a la ense ann za, Simposio en Inform tica y Telecomunicaciones, a SIT 2002, Sevilla (Espa a), 25-27 de septiembre de n 2002. Publicado en Actas del SIT2002 - Simposio en Inform tica y Telecomunicaciones. a

 INGENIERIA DEL SOFTWARE LIBRE. UNA VISION ALTERNATIV DE LA INGENIERIA A DEL SOFTWARE TRADICIONAL Gregorio Robles

RESUMEN La ingeniera del software no ha podido madurar convenien temente debido a las pr cticas propietarias que predominan a (todava) en el mundo del software comercial. En cambio,  el software libre y los m todos de desarrollo asociados con e frecuencia a proyectos de software libre brindan una gran oportunidad para que la ingeniera del software sea real mente lo que pretende ser: una actividad ingenieril aplicada a las t cnicas de desarrollo, funcionamiento y mantene imiento del software. Partiendo de esta idea, esta ponencia pretende presentar un enfoque cuantitativo basado en la ex traccion, procesado y an lisis de informacion proveniente a del software libre. Adem s de ver las aportaciones y posia bilidades que esta nueva vision puede ofrecer a la ingeniera  del software y al software libre, se presentar el estado del a arte en este campo.

se encuentra estancada y falta de ideas es una consideracion que, por lo tanto, podemos tomar como muy v lida. a

2. LA CRISIS DE LA INGENIERIA DE SOFTWARE TRADICIONAL Uno de los grandes problemas de la ingenera del software  ha sido y es que no ha sabido adaptarse consecuentemente a su propia de nicion. Esto es algo que se puede considerar como una especie de traicion a s misma, a sus propios fun damentos. El enfoque sistem tico y cuanti cable ha tenido a siempre como barreras las propias de las formas en las que el software se ha desarrollado y distribuido. El formato binario del software, la opacidad en los modelos de negocios, los secretos y barreras comerciales se encuentran entre las principales causas que han imposibilitado estudios cuantitativos a gran escala del software cuyos resultados pudieran ser veri cados sistem ticamente por equipos de investia

1. INTRODUCCION Desde hace cuatro d cadas, la ingeniera del software se ha e  venido consolidando como una rama importante dentro de la inform tica en busca de m todos de desarrollo y t cnicas a e e que permitan producir software de gran calidad con unos recursos limitados. Segun la de nicion del IEEE, la ingeniera del software es un enfoque sistem tico y cuanti  a cable al desarrollo, operacion (funcionamiento) y manten imiento del software: es decir, la aplicacion de la ingeniera  del software. [IEEE 1993] A pesar de que la ingeniera del software ha consegui do indudablemente notables exitos, tambi n es cierto que e ha sucumbido a lo que se ha venido a llamar la crisis del software. Prueba de ello es que a da de hoy todava sigue   sin ser posible cuanti car con exactitud los plazos, costes, recursos humanos y t cnicas que lleven a un desarrollo exie toso del software, tal y como otras ramas de la ingeniera en  otros campos s han sido capaces de hacer. Es m s, incluso  a en algunos puntos de la ingeniera del software se puede ob servar una tendencia a retomar viejos caminos bajo nuevas formulas, como podemos ver con la incipiente expansion de las t cnicas de programacion evolutiva que se basan en e gran parte en principios y t cnicas conocidos y usados en la e d cada de los 70. Argumentar que la ingeniera del software e 

gacion independientes. Las verdades que han sido enunciadas son, con frecuencia, experiencias puntuales que han sido generalizadas y dadas por v lidas ante la falta de altera nativas. La propia forma de desarrollar, distribuir y comerciarlizar software ha sido la que ha llevado a la ingeniera  del software a la crisis. Y es aqu donde el software libre puede dar nuevos aires  a la ingeniera del software. Desde hace m s de una d cada,  a e el software libre ha venido experimentando un gran auge en cuanto a uso, aceptacion y, por supuesto, desarrollo. La implantacion de Internet junto con las caractersticas de las  licencias que invitan a todo el mundo a formar parte del equipo de desarrollo, han propiciado que a da de hoy no  solo podamos contar con el codigo fuente (un gran avance para su estudio en contraposicion al software propietario), sino tomar medidas de los archivos de las listas de correo donde viene plasmada la comunicacion del proyecto, los repositorios de versiones gracias a los cuales podemos ver la evolucion, etc. De todas estas fuentes se puede extraer una gran cantidad de informacion de inter s, en la mayora e  de casos incluso de manera autom tica. Vemos, por tanto, a que el software libre ofrece la oportunidad de conocer m s a a fondo el proceso de concepcion de software yendo m s a all que lo que a da de hoy conocemos como ingeniera del a   software, aport ndonos nuevas evidencias y experiencias. a

 Podemos concluir que la apertura tanto del codigo co mo de la informacion asociada al proceso de desarrollo que ofrece el software libre es clave para que pueda ser analizado, estudiado y discutido de manera totalmente contrastable y abierta. 2.1. Ingeniera del software tradicional e ingeniera del   software libre Este nuevo enfoque de ingeniera del software no es ni mu cho menos contradictorio con el tradicional que todos conocemos; es m s, se puede considerar que ambos son coma patibles, incluso complementarios. Esto viene a signi car que la nueva perspectiva puede ser utilizada para comparar dos t cnicas de programacion diferentes, ayudando a sacar e conclusiones cuantitativas. Es muy probable que estos resultados puedan ayudar a mejorar esas t cnicas, al mismo e tiempo que nuevas t cnicas pueden implicar nuevas medie das. Mediante el an lisis del software libre se ganan una sea rie de factores que difcilmente ha podido conseguir la in geniera del software tradicional y que ser n discutidos a  a continuacion. El primero de ellos es la vertiente temporal que se anade al an lisis. Y es que no se puede olvidar que el proceso de a creacion de software ha cambiado segun han cambiado los paradigmas tecnologicos, de educacion, de programacion, etc. Algo que se enuncio hace 30 anos puede ser muy v lido a en la actualidad (o no), aunque no cabe duda de que es muy probable que necesite ser adaptado e incluso mejorado. Por otro lado, de la evolucion historica se puede sacar mucha e interesante informacion. Para muchas decisiones es de gran importancia saber los lenguajes de programacion en alza, la evolucion en cuanto a colaboradores de ciertos proyectos (por ejemplo, de proyectos que se dediquen a crear aplicaciones p2p), etc. Mediante un an lisis temporal a continuo estaremos en disposicion de tener un termometro permanente de lo que est ocurriendo en el mundo del softa ware (libre). Por otro lado, el an lisis de software libre no plantea a problemas de granularidad. La ingeniera del software se ha  basado con frecuencia en el an lisis de unos pocos proyeca tos de software debido en gran parte a la facilidad de acumular experiencias en entornos corporativos propios. COCOMO, un modelo de c lculo de costes y tiempos para proyeca tos software, es un claro ejemplo de esto, ya que fue creado en un departamento de la NASA a raz de la experiencia en  poco m s de un centenar de proyectos. a Tomando como analoga las ciencias economicas, po dramos decir que estamos hablando de un microan lisis.  a Por otro lado, deberamos tener, por tanto, el macroan lisis,  a que tratara de cuanti car y estudiar el software a gran es cala. Este an lisis ha sido historicamente ignorado por la a ingeniera del software tradicional y es el software libre el 

que da la posiblidad de que se pueda ver la evolucion de mu chos par metros. De esta manera se facilitar informacion a a relevante a la hora de tomar decisiones en entornos empresariales y en proyectos de software libre. Gracias al enfoque que presenta la ingeniera del soft ware libre deber ser posible, por consiguiente, medir un a proyecto dentro de entornos cerrados (microan lisis) y globa ales (macroan lisis) de manera simult nea, lo que puede ser a a de gran ayuda para medir la salud del mismo. Por ejemplo, se podra analizar Evolution, el cliente de correo m s  a completo del entorno GNOME, dentro del propio proyecto GNOME que engloba unos 200 proyectos y mil colaboradores y dentro del resto de software (libre) en general. Esto nos dar informacion desde dos puntos de vista que, a a buen seguro, enriquecer n el enfoque. a 2.2. Software libre e ingeniera del software libre  Cabe anadir, sin embargo, que la ingeniera del software li bre no solo pretende ser bene ciosa para la ingeniera del  software; tambi n lo pretende ser, en gran medida, para e el software libre. Si a da de hoy los c lculos de plazos  a y de costes en los proyectos de software estudiados tradicionalmente (en su gran mayora de software propietario)  son difcilmente cuanti cables, dentro del mundo del soft ware libre son pr cticamente utopicos. a En cierta medida, la ingeniera del software libre pre tende desposeer de esa magia que parece que es intrnseca  a los desarrollos de software libre y cuanti car unos par metros a que nos permitan predecir con exactitud costes, plazos y recursos humanos. Como consecuencia, aunque podemos considerar que en la actualidad el software libre adolece de estos m todos en contraposicion a las formas de desarrole lo tradicionales, tambi n es cierto que, por los motivos que e se est n desarrollando en esta ponencia, no le falta precisaa mente potencial para que esta situacion cambie en el futuro.

3. HACIA UN SISTEMA DE MEDICION Y ANALISIS DE SOFTWARE LIBRE. La medicion y el an lisis de datos relacionados con el desara rollo de software libre se hace imprescindible para alcanzar los objetivos que la ingeniera del software libre persigue.  Adem s, es de capital importancia que los procesos que se a desarrollen puedan ser veri cados por terceros, por lo que las herramientas utilizadas deberan tener una licencia de  software libre. Para hacer la medicion y el an lisis lo m s vers til posia a a ble, se han diferenciado varias etapas, tal y como se puede observar en la (gran) gura al nal de este punto. Es importante denotar que todos los datos provienen directa o indirectamente de par metros y caractersticas de a  software libre. Esto se debe a que suelen ser accesibles gracias a que se tiende a seguir un modelo de desarrollo lo

m s abierto posible. Mediante el uso de varias herramiena tas independientes entre s se pretende obtener los datos de  diferentes fuentes. Es frecuente que un mismo par metro se a pueda obtener de varias formas diferentes, lo que puede ser util para la realizacion de comprobaciones. Los resultados de las diferentes herramientas se almacenar n en un formato intermedio e independiente de las a mismas. De esta forma, la segunda fase se facilita sobremanera, ya que los datos guardados en ese formato intermedio podr n analizarse convenientemente por medio de hera ramientas realizadas al efecto o, si es necesario, pueden ser f cilmente convertidos a otro tipo de formatos. a Mientras que el objetivo de la primera fase es extraer el mayor numero de par metros cuanti cables, la segunda a fase es un amplio terreno aun por explorar; veremos que es ah donde tienen cabida desde simples an lisis de los datos  a hasta la utilizacion de complejos algoritmos estadsticos que  permitan ir conociendo m s a fondo el software libre. a Antes de mostrar pormenorizadamente las herramientas existentes para las cada una de las fases, se debe mencionar que aun cuando la arquitectura completa del sistema puede parecer compleja, esto no es as. Existe una gran modulari dad e independencia y el pegamento que da sentido a todo esto es la capa donde viene especi cado que los datos se almacenar n en un formato intermedio e independiente. Esto a quiere decir que una aplicacion de extraccion de par metros a de codigo fuente es totalmente independiente de otra que toma datos debidos al desarrollo distribuido. Es m s inclua so lo es de otra que tambi n se encarga de estudiar el codigo e fuente. Lo que debe preocupar a las aplicaciones es ofrecer sus resultados en el formato intermedio, haciendo uso de ltros si es conveniente realizar conversiones a otros formatos.

an lisis nos dir n por donde seguir buscando y cu les deben a a a ser los siguientes pasos logicos dentro del estudio del software libre. 4.1. Codigo fuente El codigo fuente es, con diferencia, el mayor continente de informacion en cuanto al desarrollo de proyectos de soft ware libre se re ere. De el se pueden extraer no solo par metros a globales como el tamano, el numero de puede ser investigado con la cheros, sino que nalidad de encontrar par metros a

de participacion (numero de desarrolladores), de progra macion (lenguaje de programacion, adem s de ofrecer la a posibilidad de utilizar diferentes m tricas de programacion), e de lneas de codigo (tanto logicas como fsicas), numero de   comentarios, etc. etc. Una de las primeras aproximaciones existentes a da de  hoy es el c lculo del numero de lneas fsicas de proyectos a   de software libre y el uso del modelo COCOMO (cl sico) a para obtener resultados en cuanto al tiempo, al coste y a los recursos humanos necesarios para su desarrollo. Evidentemente, este primer an lisis se encuentra en una fase a bastante primitiva, pero la correlacion con otras fuentes permitir mejorar (y/o adaptar) los resultados en el futuro. a Existe en la actualidad una gama de herramientas que permiten realizar parcialmente estas tareas. SLOCcount re conoce el lenguaje de programacion utilizado, cuenta lneas  de codigo (fsicas) y hace una estimacion aproximada de los  costes y el tiempo que el desarrollo ha supuesto mediante el uso de COCOMO. Por su parte, CODD recorre todos los cheros con codigo fuente y asigna autora a las personas  que lo han desarrollado. A estas dos aproximaciones habra  que sumar la informacion que pueden proporcionar diferentes m tricas de software. e 4.2. Intercambio de informacion directa entre desarrolladores El intercambio m s importante de informacion no incluido a en el codigo corre a cargo de listas de correo electronico, canales IRC y documentacion. En el caso de las listas de correo-e, los mensajes son almacenados en archivos que deben ser analizados. En cuanto a la documentacion y al IRC todava no est muy claro lo que buscamos y sobre to a do, como hacerlo de forma autom tica. a Para nuestro acometido existe una herramienta llamada MailListStats que analiza estadsticamente la participacion  en las listas de correo. Existen tambi n herramientas que e analizan las bit coras de los canales IRC. a 4.3. Herramientas de desarrollo distribuido El desarrollo de software libre se basa en gran parte en unas herramientas que permiten sincronizarse con el trabajo de los diferentes desarrolladores del proyecto, de man era que la distribucion geogr ca no suponga un problema. a

4. EXTRACCION DE DATOS (PRIMERA FASE) El primer paso engloba agrupar, ordenar y analizar conve nientemente el codigo fuente y los ujos de informacion nalidad existentes en los proyectos de software libre. La

principal es conseguir que todo esto se haga lo m s aua tom ticamente posible. En realidad, se pretende recabar toa do tipo de informacion para poder ser analizada y estudiada detenidamente con posterioridad. Como se ve, se trata de un proceso iterativo, ya que los resultados de los primeros

Los sistemas de control de versiones y los gestores de erratas (tambi n usados ocasionalmente para tareas de planie cacion) se han convertido en herramientas imprescindibles para proyectos de software libre grandes, y no tan grandes. Estos sistemas suelen registrar las interacciones con los desarrolladores y, por tanto, una vez que se consiguen estos registros puede monitorizarse de manera bastante sencilla todo el proceso de desarrollo. El an lisis de las bit coras del CVS mediante la aplia a cacion cvstat2 permite obtener informacion de la interac cion de los desarrolladores con el repositorio. El an lisis a permite obtener datos por desarrollador, por proyecto y por chero y todo esto de manera temporal. cvstat2 tiene integrado un interfaz web que permitir por una parte que a muchos proyectos puedan instalarlo f cilmente y ver sus a estadsticas y por otra que exista una extraccion de datos  distribuida. La otra fuente de informacion interesante en este punto es obteniendo datos de los sistemas de control de erratas como BugZilla. Del mismo se pueden ver la evolucion de las erratas y las diferentes interacciones que existen. 4.4. Otras Herramientas Adem s de las herramientas ya presentadas, existen otro a tipo de herramientas que no entran en la clasi cacion que hemos seguido y que, por tanto, ser n mostradas a contina uacion. SFparser es una herramienta que rastrea sitios web que tengan el software de SourceForge instalado. Su acometi do es tomar toda la informacion posible que existe, como por ejemplo los desarrolladores que participan, la catego rizacion del proyecto, si tiene listas de correo y/o usa un repositorio CVS, etc. La misma idea subyace tras el guion FMparser, que realiza id nticas extracciones de Freshmeat. e Otras aplicaciones o sitios que pueden ofrecer m s datos son a apt, el LSM o rpmgraph. 4.5. Datos de otras fuentes A diferencia de los proyectos de software tradicionales, con el software libre en muchos casos se desconocen los recursos humanos. La situacion socio-laboral, economica, geogr ca y cultural de los integrantes de los proyectos de a software puede ser muy dispar y, a buen seguro, tiene reper cusion en la forma en la que un proyecto de software evoluciona. La forma tradicional para la obtencion de estos datos ha sido mediante encuestas, que han permitido obtener una imagen de las personas que est n detr s del desarrollo de a a software libre. El problema que estas conllevan es que las grandes consultas suelen preservar el anonimato de los de sarrolladores, por lo que su correlacion con las fuentes presentadas con anterioridad se di culta sobremanera. Para estudios pormenorizados, como sera en el caso de comu

nidades en torno a proyectos concretos (GNOME, KDE, Linux, Apache

...

), se podran conseguir y estudiar datos 

sobre la situacion laboral y personal de los desarrolladores. Esta informacion podra utilizarse en los microan lisis para  a ver el grado de participacion de profesionales en el desar rollo, como se dividen las funciones, etc.

5. FORMATO INTERMEDIO E INDEPENDIENTE En un principio, se intentar que todas las herramientas utia lizadas devuelvan los resultados en un formato intermedio e independiente de forma que se pueda aglutinarlos de man era sencilla aun proveniendo de diferentes herramientas. El formato elegido debe ser muy exible, ya que puede que en un futuro proximo se le anadan m s par metros. A da de a a  hoy, lo mejor sera utilizar un formato XML o SQL, ya que  cumplen todos los requisitos comentados con anterioridad y adem s permiten la compatibilidad hacia atr s. a a Tambi n hay que tener en cuenta que los conversores de e XML (SQL) a cualquier otro tipo de formato que se desee no ser n muy difciles de implementar. La conversion es a  muy importante, ya que se pretende utilizar en la medida de lo posible herramientas ya existentes en la segunda fase, por lo que una adaptacion de los datos obtenidos en la primera fase al formato que estas herramientas requieran sera muy  conveniente.

6. ANALISIS, PROCESADO Y VISUALIZACION DE LOS DATOS (SEGUNDA FASE) Hemos visto que la primera fase trata la extraccion de datos de diferentes fuentes para almacenarlos posteriormente en un formato intermedio que sea independiente de las fuentes y de las herramientas. Esta primera fase, aunque todava in completa, se encuentra mucho m s madura que la fase que a se va a presentar ahora. Parece bastante claro cu les son a las fuentes que se quieren investigar y solo falta rellenar algunos huecos en las implementaciones para que se d por e acabada. Una vez que tenemos los datos, se abre ante nosotros un mundo lleno de posibilidades. El volumen de datos del que disponemos y la carencia de an lisis hace que se puedan a vislumbrar en un futuro proximo gran cantidad de estudios en lo que se re ere al an lisis, procesado e interpretacion de a los resultados. Existen varias formas de tomar los datos y analizarlos, aunque seguro que en los proximos tiempos se crear n m s. a a La m s elemental es proporcionar un simple interfaz web a para poder visualizar los datos de manera tabular y/o gr ca. a Si los datos est n en una base de datos, adem s se pueden a a ofrecer correlaciones y datos por proyecto o desarrollador. El siguiente paso logico es la utilizacion de herramientas de an lisis estadstico que faciliten el estudio de grandes a 

 cantidades de datos, as como su correlacion. Existen suites  para la realizacion de estas tareas que pueden hacer todo esto un poco m s f cil. a a Yendo un poco m s all , cabe la posibilidad de realizar a a un an lisis de clusters, ya sea de paquetes o de desarrola ladores. En este sentido se han hecho algunos esfuerzos en los ultimos tiempos. Muestra de ello es la aplicacion coddcluster que toma datos de desarrolladores de CODD y crea agrupaciones de proyectos con desarrolladores en comun de forma que se pueda llegar a encontrar interdependencias entre diferentes proyectos. Los clusters tambi n pueden e ser utilizados para agruparlos segun lenguajes de progra macion, tamano, etc. simult neamente. a Incluso tomando varios par metros a

8. AGRADECIMIENTOS A esta ponencia le faltara algo si no expresara mi agradec imiento por las ideas y comentarios con los que me han provisto Jesus M. Gonz lez de Barahona y Luis Rodero a del Grupo de Sistemas y Comunicaciones de la Universidad Rey Juan Carlos y Joaqun Seoane, del Departamento  de Ingeniera Telem tica de la Universidad Polit cnica de  a e Madrid.

9. BIBLIOGRAFA [1] Frederick P. Brooks Jr. The Mythical Man-Month, Primera edicion ano 1975, Addison Wesley Publishing Company

7. CONCLUSIONES Empezamos esta ponencia viendo los problemas que tiene la ingeniera del software tradicional, b sicamente por su  a falta de an lisis metodicos y sistem ticos. Hemos visto que a a el software libre cuenta con cualidades innatas para introducir m todos que permitan conocer m s a fondo todos los e a par metros que in uyen en la generacion del mismo. Esta a formalizacion es muy prometedora, ya que el software libre es mucho m s difcil de cuanti car que la ingeniera del a   software tradicional. Por tanto, es probable que el conocimiento del desarrollo de software libre se pueda tambi n dar e solucion a muchas incognitas de la ingeniera del software  tradicional. En este sentido se ha hecho hincapi en que el e nuevo enfoque es totalmente complementario al tradicional. Despu s de una introduccion m s bien teorica en la que e a se ha presentado una declaracion de intenciones de la ingeniera del software, hemos visto una propuesta de metodologa   para recabar informacion de proyectos de software libre. De esta inmensa cantidad de informacion se pretende extraer experiencias con exito que puedan ser replicadas en otros desarrollos. Hemos visto que hay una serie de herramientas para la extraccion de datos de diversas fuentes, desde el propio codigo fuente hasta rastreando p ginas web de portales de a desarrollo de software. Los datos se almacenar n en un fora mato intermedio e independiente tanto de la fuente como de las herramientas, para que en una segunda fase, se puedan analizar, correlar, procesar y visualizar de diversas maneras. Esto ultimo abre un campo de consecuencias difciles de  predecir, pero sin lugar a dudas muy ilusionante y prometedor. La sensacion de que el software libre parece que est a propiciando uno de esos extranos momentos donde una industria entera cambia de paradigma, se puede tambi n exe trapolar a la ingeniera del software libre. Aun nos encon tramos en sus comienzos y hace falta un largo camino por andar.

[2] Roger Pressman Ingeniera del Software: Un enfoque  pr ctico, 1997, McGrawHill a [3] Adam Smith Investigacion sobre la naturaleza y la causa de la riqueza de las naciones, Primera edicion ano 1776 [4] Jae Yun Moon & Lee Sproull Essence of Distributed Work: The Case of the Linux Kernel, http://www. rstmonday.dk/issues/issue5 11/moon [5] Sandrep Krishnamurthy Cave or Community?,

http://www. rstmonday.dk/issues/issue7 6/krishnamurthy [6] David Lancashire Code, Culture and Cash: Fading Altruism of Open Source The

Development,

http:// rstmonday.org/issues/issue6 12/lancashire/ [7] Christopher M. Kelty Free Software/Free Science, http:// rstmonday.org/issues/issue6 12/kelty/ [8] Jesus M. Gonz lez Barahona, Jos M. Ortuno P rez a e e y otros Contando Patatas: El tamano de Debian 2.2, http://congreso.hispalinux.es/congreso2001/actividades/ponencias/gonzalez/html/t1.html [9] David A. Wheeler Why Open Source Software/Free Software (OSS/FS)? Look at the Numbers!, http://www.dwheeler.com/oss fs why.html [10] The FLOSS Survey - Encuesta auspiciada por un proyecto de investigacion de la Comision Europea realizada a m s de 2750 desarrolladores (2002), a http:// oss1.infonomics.nl/stats.php [11] Rishab A. Ghosh, Rudiger Glott, Bernhard Krieger & Gregorio Robles Survey Free/Libre Study Open Final Source report, Software: and

http:// oss1.infonomics.nl/ nalreport/ [12] The Widi Survey - Encuesta realizada a m s de 5500 a desarrolladores (2001), http://widi.berlios.de

[13] Boston millar

Consulting de

Group de

Boston

Consulting (2001),

[27] SLOCcount de codigo de c lculo a

Herramienta en y

para

contar de

lneas  y

Group/OSDN Hacker Survey - Encuesta a casi un desarrolladores Sourceforge http://www.osdn.com/bcg/ [14] Gregorio Robles Los desarrolladores de Software Libre, http://congreso.hispalinux.es/congreso2001/actividades/ponencias/robles/pdf/desarrolladores.pdf [15] Gregorio DI Robles, Who Is Niels Doing Weber It?, & otros WI-

fuente costes

diferentes tiempos

lenguajes

desarrollo,

http://www.dwheeler.com/sloccount/ [28] GNOME-stats stats.berlios.de [29] KDE-stats - Estadsticas (est ticas por ahora) del CVS  a del proyecto KDE, http://kde-stats.berlios.de [30] sloc2html - Aplicacion que presenta los resultados de SLOCcount a trav s de un interfaz web agradable, e http://halfdans.net/index.py?p=sloc2html [31] Estadsticas gr cas de GNOME con SLOCCount  a Estadsticas  (est ticas a por aho-

ra) del CVS del proyecto GNOME, http://gnome-

http://ig.cs.tu-

berlin.de/s2001/ir2/ergebnisse/OSE-study.pdf [16] Curso de doctorado Programas Libres - Departamento de Ingeniera Telem tica UPM, http://curso a sobre.berlios.de [17] Rishab dencies ment: Aiyer in Ghosh Clustering Source and and DepenDevelopAnalysis,

sloc2html,

http://gnome-stats.berlios.de/gnome-

Free/Open

Software

sloc.html [32] Free Software de Foundation Europe de Distribucion libre,

Methodology

Preliminary

http://www.idei.asso.fr/Commun/Conferences/Internet/OSS2002/Papiers/Ghosh.PDF [18] Rishab The Aiyer Orbiten Ghosh Free & Vipul Ved Prakash Survey,

geogr ca a

desarrolladores

software

http://www.fsfeurope.org/coposys/index.en.html [33] Alison tion opers, Luo Metric) TPM for (Trinity Source ParticipaDevelali-

Software

Open

http://www. rstmonday.dk/issues/issue5 7/ghosh [19] Eric S. Raymond The Cathedral and the Bazaar, http://www.tuxedo.org/ esr/writings/cathedral-bazaar/ [20] Nikolai at the Bezroukov Cathedral A and Second the Look Bazaar,

http://www.cse.ucsc.edu/

son/projects/cmpe276/index.html [34] Linux kernel Study Questionnaire (141 on Linux

developers

desarrolladores),

http://www.psychologie.uni-kiel.de/linux-study/ [35] Proyecto cion Debian de Mapa los con la distribuDebian,

http://www. rstmonday.dk/issues/issue4 12/bezroukov/ [21] Rishab kets: free Aiyer an goods and Ghosh Cooking for on the the pot marin

geogr ca a

desarrolladores

economic

model

trade

http://www.debian.org/devel/developers.loc [36] Edward Betts Debian Developer Centre of Mass, http://people.debian.org/ edward/average/ [37] rpmgraph de una herramienta a partir de que hace grafos RPM,

services

Internet,

http://www. rstmonday.dk/issues/issue3 3/ghosh/ [22] Josh ple Lerner & Jean of Tirole Open The Sim-

Economics

Source,

dependencias

paquetes

http://www.idei.asso.fr/Commun/Articles/Tirole/simpleeconomics-July-24-2001.pdf [23] Jesus ware M. libre, Gonz lez a monopolios Barahona y otras Softyerbas,

http://www.freshmeat.net/rpmgraph [38] Graphical cies (algo Display parecido a of Package DependenDebian),

rpmgraph

para

http://www.debianplanet.org/node.php?id=695

http://sinetgy.org/ jgb/articulos/soft-libre-monopolios/ [24] Proyecto Gestion Libre de Hispalinux http://gestionlibre.hispalinux.es [25] CODD - Aplicacion rastreadora de autores y de pendencias de codigo e interfaces en codigo fuente, http://codd.berlios.de [26] CODDWeb - Interfaz web para acceder a los resultados de CODD, http:// oss1.infonomics.nl/coddweb/