J2EE, programación de servidores de aplicaciones

¿Qué? ¿cómo andamos?

Se que dije que el siguiente post sería de XMLSchema pero voy a dejarlo pa más tarde y me dedicaré hoy a hablar un poquillo por encima de la tecnología J2EE (Java 2, Enterprise Edition). Haré una introducción teórica en este primer post de una serie de 4 post en los que trataré lo que os quiero presentar de la siguiente forma:

1. Introducción teórica a vista de pájaro de Java 2, Enterprise Edition (J2EE) y sus Enterprise Java Beans (EJB).
2. Creación de un EJB (I): Session Bean.
3. Creación de un EJB (II): Entity Bean.
4. Creación de un EJB (III): Message-Driven Bean.
   

J2EE

Si tuviéramos que, como en el colegio, hacer teoría de conjuntos y ver qué conjuntos es menor que cuál o está contenido en o chorrás desas, tendríamos que decir que:

J2ME < J2SE < J2EE

Y es que si bien J2ME no es exactamente un subconjunto de J2SE o J2EE puesto que puede tener elementos que no aparecen en éstos, sí que cuanto menos es una edición mucho más reducida del entorno de desarrollo.

Los objetivos básicos con los que surge J2EE son:

• Abstraer las tareas críticas y repetitivas mediante servicios con una interfaz uniforme.
• Preparar una infraestructura uniforme y de una arquitectura software basada en ella para aplicaciones empresariales.

La tecnología de J2EE utiliza la filosofía de la programación basada en componentes, más que la orientada a objetos. En este tipo de programación, un componente es algo más amplio que un mero objeto, y más asociado a la aplicación.

Además, una aplicación compleja basada en componentes a su vez se subdivide en niveles lógicos, de forma que cada nivel cubra un área de tareas y que pueden componer una o varias partes. Así obtenemos "Thin Clients", frente a los "Fat Clients" de la arquitectura Cliente/Servidor, ya que en los niveles intermedios se delega parte de la responsabilidad del servidor. Cada nivel se comunica sólo con los niveles contiguos mediante interfaces bien definidas.


EJB's

Pero pasemos de to este movidón teórico y metámonos en más teoría pero por lo menos un poco más próxima a la práctica. Veamos el concepto de beans. Los beans son nuestros colegas, nuestras "habichuelas", las entidades mínimas de nuestro diseño de aplicaciones...y de servidores de aplicaciones. En esencia son clases java con unas ciertas propiedades que permitirán darnos algunas prestaciones en función de nuestras necesidades, o más técnicamente son componentes que pueden ser usados para construcción de aplicaciones distribuídas y que encapsulan una parte de la lógica de negocio de una aplicación. Un EJB accede a otros gestores de recursos como bases de datos u otros EJB's y puede ser accedido por otros EJB's, aplicaciones, servlets y aplicaciones cliente. el EJB reside en un contenedor que le provee de servicios de seguridad, transacciones, gestión del ciclo de vida, gestión de concurrencia y despliegue.

Un EJB (salvo en el especial caso de los Message-Driven Beans) tiene varias partes:

• La interfaz cliente. Permite el uso síncrono por parte de los clientes de los procesos de negocio que modela el EJB. Consta de dos clases de tipo interface. La Home Interface que debe extender la clase EJBHome y controla los métodos del ciclo de vida y la Remote Interface que debe extender la clase EJBObject y controla el acceso a los métodos de negocio remotamente.
  
• La clase Enterprise Bean. Implementa el Bean en sí, su funcionamiento interno, las llamadas a las BBDD necesarias, los métodos de negocio, ciclo de vida, etc.
• El descriptor de despliegue. Proporciona al contenedor toda la información que éste necesita sobre el EJB (nombre, nombre de sus interfaces, tipo de EJB, servicios que se esperan del contenedor, etc). Se trata de un fichero XML, y debido a su complejidad y su extensión se suelen utilizar herramientas de despliegue que lo creen a partir de la selección de opciones en un interfaz gráfico por parte del desplegador.
  

Lo que nuestros coleguitas beans pretenden ayudarnos a modelar son lo que llamamos "entidades de negocio" y "procesos de negocio", que viene a ser una forma empresarial de llamar a información de nuestra aplicación y métodos de acceso y modificación de esa información. Para que nos entendamos, las entidades de negocio son las bases de datos donde los procesos de negocio son los métodos/funciones/procedimientos que acceden a esas bases de datos y leen o modifican lo que en ellas hay.

Y para eso, ¿en qué nos ayudan los beans? Pues bien, tenemos beans para cada una de nuestras necesidades en una apliación...beans a la carta. En esencia tenemos:

Beans de Sesión (Session Beans):
Se encargan de la parte del lado servidor de la lógica de negocio de una aplicación.
Se crean instancias de un Session Bean cuando se produce una petición de un cliente y su tiempo de vida es el de el proceso abierto. Podemos tenerlos de dos tipos:

• Beans de sesión sin estado (Stateless Session Beans)
  No guardan información del cliente. Todos los Stateless Session Beans instanciados tienen la misma identidad.


• Beans de sesión con estado (Statefull Session Beans)
  Presentan diferentes estados en función del cliente, estado que se pierde cuando se deja de usar el Session Bean. Como consecuencia, cada objeto Session Bean tiene distinta identidad.

Algunas propiedades

• Su estado se mantiene en memoria principal durante una transacción pero pasa a almacenamiento secundario tras desactivarse. Además su estado es inaccesible para otros programas, aunque pueda ser sincronizado para las transacciones.
  
• Sólo puede usarse por un mismo cliente, no puede ser compartida su referencia.
• Frente a fallos no se garantiza que una referencia a un objeto Session Bean siga valiendo.
  

Los Session Beans son especialmente adecuados para encargarse...
...de la lógica de sesión de una aplicación web...


...o también para encargarse de la lógica de sesión de una aplicación de tres capas.



Beans de Entidad (Entity Beans):
Este tipo de beans son los que nos modelan aquéllos conceptos u objetos de negocio cuyos datos deben ser persistentes, para lo que se suele usar una base de datos. Se pueden usar por varios clientes de forma conjunta y simultánea. Su identidad es tan simple como la clave primaria de la base de datos usada. Son tan persistentes que incluso llegan a sobrevivir a caídas de la máquina o de la máquina virtual de Java. En función de quién controle esta persistencia, se clasifican en dos tipos distintos:

• Persistencia manejada por el bean (Bean Managed Persistence)
  El programador del bean debe programar los métodos que aseguran la persistencia, que vienen a ser los métodos que guardan los datos en la base de datos, así como crear la base de datos y mapear variables con columnas de la base de datos.
  


• Persistencia manejada por el contenedor (Container Managed Persistence)
  El programador queda liberado de la tarea de programar la persistencia teniendo únicamente que indicar al contenedor qué variables van a asociadas a qué columnas de la base de datos para que éste controle la persistencia. Todo este mapeo se reflejará en el fichero xml descriptor del bean.
  

Algunas propiedades:

• El estado de un Entity Bean es mantenido en una BBDD, con caché en memoria durante una transacción. Por consiguiente, cualquier programa externo puede acceder a él mediante queries SQL. Además su estado se cambia con transacciones y se puede recuperar en cualquier momento.
  
• Un objeto Entity Bean puede ser compartido por múltiples clientes pasándose la referencia sin problemas.
• Frente a fallos, caídas del contenedor o de la máquina, las referencias a los objetos siguen siendo válidas.
  

Beans controlados por mensajes (Message-driven Beans):
Este tipo de beans permiten a las aplicaciones J2EE procesar mensajes asíncronos, lo que los diferencia de los anteriores cuya llamada era síncrona. En última instancia no son más que escuchadores de mensajes JMS. Su estructura de hecho es similar a la de los escuchadores de eventos de java, sólo que éstos lo que escuchan son mensajes.
La principal diferencia a nivel de uso de éste tipo de bean con los anteriores es que el acceso a ellos no se realiza mediante interfaces, sino por:

• Mensajes enviados por algún componente J2EE (una aplicación cliente, otro EJB o un componente web).
• Mensajes enviados por una aplicación o sistema JMS que no use la tecnología J2EE.
  

También a diferencia de los demás beans, los MDB sólo se componen de una clase java, ya que no tienen interfaces.
describamos entonces algunas de las propiedades de este tipo de EJB's:

• Una instancia a un MDB no almacena datos o estado conversacional de ningún cliente.
• Todas las instancias de MDB tienen la misma identidad, por lo que la asignación de una instancia a un cliente es indiferente de qué instancia sea.
• Un único MDB puede procesar mensajes procedentes de múltiples clientes.

Cuando un mensaje llega, el contenedor de nuestro EJB llama a su método onMessage(), que típicamente lo primero que debe tener programado es la clasificación de este mensaje según pertenezca a cada uno de los 5 tipos de mensajes JMS, para luego procesarlo según la lógica de negocio de nuestra aplicación.

Y bueno, yo creo que como introducción a J2EE y EJB's ya se ha hecho demasiao larga, pero weno, espero haberos ayudao en familiarizaros en esta tecnología. El siguiente post irá dedicao a programar y desplegar un Session Bean pa que le echéis un ojo a su código y veáis que hacerlo es más o menos sencillico aunque un poco coñazo. Además usaremos alguna herramienta de despliegue de EJBs que provee Sun. ya os contaré.

+info:
http://java.sun.com/javaee/5/docs/tutorial/doc/
http://java.sun.com/javaee/5/docs/firstcup/doc/toc.html
http://java.sun.com/javaee/index.jsp

¿Qué es eso del AJAX?

Algunos pensarán que el AJAX es un equipo de fútbol holandés, otros pensarán que les da igual qué es lo que es, otros pensarán que tiene algo que ver con internet (nos vamos acercando al tema). En este post voy a intentar dar una primera idea que, si puedo iré extendiendo en sucesivos posts, de qué es realmente AJAX y qué podemos hacer con él.

La definición es:

AJAX: Asynchronous Javascript and XML

muy bien, y esto ¿qué significa?

Empezaré contando mi pequeña historia con AJAX, mi experiencia con AJAX comenzó cuando un conocido me comentó que estaban haciendo un sistema web con ATLAS. Yo pensé "¿para qué meter un atlas en un sistema web?", luego me enteré que ATLAS es una implementación de ASP.NET para AJAX. A estas alturas aún no sabía qué era AJAX. Con el tiempo empecé a investigar por mi cuenta y a jugar con diferentes lenguajes de programación y frameworks javascript: programé con PHP, utilicé el GWT (Google Web Toolkit) para Java, enredé con el framework Dojo y Rico, programé con ASP.NET, etc. En fin que me mareé viendo herramientas y programando con ellas, pero, realmente ¿QUÉ ES AJAX?

Mi último proyecto, con el que estoy ahora mismo (aprovecho para comentarlo) es un portal libre para compartir cursos de formación (http://learning.nidea-soluciones.com) es donde más he trabajado con AJAX y todas las técnicas relacionadas, así que, vamos al lío de verdad.


¿Qué es AJAX?

AJAX no es ni más ni menos que un mecanismo que nos permite realizar llamadas asíncronas al servidor desde un página web. Así suena muy poca cosa, pero en realidad abre todo un mundo de posibilidades (y problemas...).

¿Cómo eran las cosas antes de AJAX? Antes de AJAX, una página web se componía de etiquetas HTML y de etiquetas de servidor (utilizadas por el lenguaje de programación). Cada vez que un usuario realizaba cualquier acción en una página web que requiriese de la actualización de su contenido, se ponía la pantalla en blanco (mientras se realizaba la comunicación con el servidor) y luego volvía a aparecer con la actualización puesta. ¿Por qué pasaba esto? porque lo que los navegadores entienden es el HTML, y las etiquetas de servidor las debe sustituir el servidor por HTML con los datos correctos. Veamos el siguiente ejemplo:

Tenemos una página simple programada en ASP.NET (es lo que tengo más manío):











Lo único que hace esta página es pedir un nombre y al pulsar sobre el botón, pone el nombre que se ha escrito en una etiqueta. Sin embargo, éste lenguaje no es entendido por el navegador, por lo que el servidor web, lo que hace es sustituir las etiquetas por lo que corresponda en HTML. La primera vez que se ve la página, el código enviado es:














Todas las etiquetas han sido sustituidas por sus correspondientes etiquetas HTML. Si el usuario introduce un nombre y pulsa sobre el botón "btnBoton" que pone Púlsame, la página se tendrá que recargar para que aparezca el nombre en la etiqueta "lblNombre". El servidor (porque se le indica así en el fichero de código que acompaña a esta página) devolverá la siguiente página:














La página devuelta tiene en la caja de texto el nombre "Manolo" y en el span también. Al pulsar el botón, hemos tenido que ir al servidor para que recompusiese el HTML y lo enviase de vuelta al navegador. El tiempo que tarde en llegar la petición al servidor, en que éste evalúe las acciones, obtenga los resultados, rehaga el HTML y llegue de vuelta al navegador, será el tiempo que esté nuestro explorador en blanco. Esto es así porque las operaciones son SÍNCRONAS (lo remarco porque este es el quid de la cuestión).

Lo que nos permite AJAX es lanzar una llamada asíncrona al servidor para que nos envíe la información que requiramos de vuelta, sin que el usuario pierda el control de la interfaz de usuario. Como me gustan mucho los dibujos, veámoslo en uno de ellos:




















En el primer caso, se realiza una llamada a http://www.nidea-soluciones.com (os la marco por si queréis visitarla). El servidor web devuelve el HTML de la página, el explorador lo lee y lo pinta en la pantalla. Si el usuario pulsa algún botón o realiza alguna acción que requiera una respuesta del servidor (actualización de una parte de la página), se enviará una petición de actualización al servidor y perderemos el control en el explorador, la página se quedará en blanco esperando que el servidor recomponga todo el HTML y se lo envíe de vuelta. Este tiempo variará dependiendo del servidor, de las líneas de comunicación y de lo que queramos actualizar. En ocasiones puede llegar a ser muy frustrante puesto que no sabemos si se ha colgado el sistema, si la línea se ha caído, por dónde va el proceso, etc. y actualizamos la página para volver a darle o nos salimos del sitio.

En el segundo caso utilizamos AJAX en nuestra página web y el proceso varía ligeramente. La primera llamada al servidor nos devuelve la página web, igual que el ejemplo anterior. Sin embargo, a partir de ese momento, todas las peticiones de actualización de partes de la página se realizan con llamadas asíncronas a servidor. Esto lo que hace es lanzar una hebra de ejecución diferente de la que tiene el control de la página y, esta hebra, contacta con el servidor y le pide la información. En Javascript, habremos implementado un manejador para el evento de recepción de la respuesta. Cuando llegue la respuesta se ejecutará el código de ese manejador, donde le diremos qué tiene que hacer con los datos que nos envía el servidor. Durante el tiempo de ida y venida al servidor, la hebra principal mantiene el control de la página, posibilitando que el usuario siga haciendo cosas con ella. Podría realizar más peticiones a servidor y se lanzarían nuevas hebras.

Hasta aquí muy bien pero, ¿y eso cómo leñe se hace?

La primera alternativa para trabajar con AJAX es la que denomino, AJAX PARA CAMPEONES. La pongo en mayúsculas y coloreado porque esta opción es la de trabajar a pelo con Javascript y con el objeto XmlHttpRequest (que veremos ahora). Esta alternativa es un poco sádica pero creo que es necesario que sepáis realmente cómo funciona. Una vez superado este nivel podremos trabajar con la opción AJAX COMODO, en la que utilizaremos algún framework de los existentes.

Vamos a ver un ejemplo práctico (aquí iba a poner un ejemplo pero Blogger me bloquea las llamadas asíncronas), por lo que podéis ver el ejemplo en:
http://www.nidea-soluciones.com/PruebasAJAX/PruebaAJAX1.html.

En este ejemplo, al pinchar en el enlace lo que se hace es inicializar el objeto xmlHttpRequest (encargado de realizar la llamada asíncrona) y hacer un GET asíncrono a http://www.nidea-soluciones.com/PruebasAJAX/prueba.txt El texto de respuesta lo coloca en una etiqueta que está justo debajo del enlace. Veamos el código:






















Si nos fijamos en la parte BODY, tenemos un hipervínculo que al pulsarlo lanza la función CargaTexto(), hecha en Javascript, y tenemos un SPAN llamado textoAjax. Vamos a ver las tres funciones Javascript que hemos definido:

Función ObjetoAjax(): función encargada de inicializar el objeto XMLHttpRequest para poder realizar llamadas asíncronas a servidor. Esta función comprueba el tipo de explorador porque Firefox e Internet Explorer utilizan diferentes inicializaciones para este objeto (como siempre...).

Función CargaTexto(): esta es la función que se invoca cuando el usuario hace clic sobre el enlace. Esta función realiza tres cosas distintas:

1. Utiliza el objeto Ajax para abrir una conexión GET con la URL http://www.nidea-soluciones.com/PruebasAJAX/prueba.txt.
2. Declara cuál va a ser la función que se ejecute cuando llegue la respuesta a la llamada al servidor. En este caso, dicha función va a ser capturaPeticion.
3. Lanza la llamada.

Función CapturaPeticion(): cuando se recibe la respuesta se lanza esta función que lo que hace es poner el texto de la respuesta en la etiqueta SPAN definida.

Este ejemplo es muy básico pero ilustra bastante bien el ciclo de llamada y respuesta de AJAX. Siempre tendremos estas tres funciones: una que inicializa el objeto, una que realiza la llamada y otra que recibe la respuesta. En sucesivos posts iremos viendo cómo podemos mejorar este ejemplo (ya está siendo muy largo este), como por ejemplo:

• Etiquetas de espera para que el usuario sepa que algo se está haciendo.
• Control de la concurrencia en servidor.
• Deshabilitar controles a la hora de ir a servidor.
• Informe del estado de la operación
• ...

Estas son cosas importantes que hay que tener en cuenta a la hora de programar con AJAX, porque al introducir el elemento asíncrono, se incrementa la complejidad en nuestros desarrollos.


Finalmente, ¿qué NO es AJAX?
También es importante saber qué no es AJAX. AJAX es, simplemente, la posibilidad de realizar llamadas asíncronas a servidor. De ésto se pueden derivar muchas herramientas y controles, los llamados rich-controls, que utilizan AJAX. Podremos implementar grids que carguen los datos dinámicamente utilizando el objeto XMLHttpRequest y funciones Javascript, ventanas modales que carguen información, etc. Todos estos controles utilizan AJAX y CSS para ayudarnos en nuestros desarrollos, pero AJAX sólamente es el objeto XMLHttpRequest.

¿Otro post no? XML for Mayor!

Como veo que la cosa está más muerta que un cordero la noche después del fin del Ramadán digo...¿voy a escribir no? ... pero ... ¿qué coño escribo?

Pues como últimamente he estao aprendiendo cosillas sobre XML, RDF, RDFa, JDOM, DOM, SAX, XML-RPC, SOAP, XSLT, SNMP, J2EE, J2ME, BGP, IPv6, y demás parafernalias (cómo mola escribir siglas, no importa que no tengas puta idea, quedas como un señor poniéndolas ;) ), pos me he decidío a contaros un poquillo de estas tecnologías en diferentes post por entregas. Si os aburro no tenéis más que decirlo.

Y pa empezar, vamos a introducirnos levemente en el maravilloso mundillo del XML.

Actualización(23/06/07):
Como los feeds (orígenes, RSS, como los queráis llamar) se envían mediante XML, paradojas de la vida, quien lea este post recibiéndolo desde un agregador probablemente no lo lea bien porque interpretará el código XML y el resultado será que no se le mostrarán las etiquetas, sólo su contenido. Por ello, por el momento y a estas alturas de la noche no se me ocurre más que entrar vía web para leerlo sin problemas. Mil perdones. ¿A alguien se le ocurre una solución?

XML

Mi descubrimiento de XML como metalenguaje para "casi todo" ha sido como encontrarse con un hermano perdido. Uno se pregunta...¿cómo coño no lo vi antes? ¿he estao tirando to este tiempo a la basura?

¿De ande ha salío ésto?

XML surge más o menos como una simplificación de SGML, que viene a ser un lenguaje un tanto más ambíguo pero mucho más extenso y rico. SGML se lo inventaron por allá por los "unites estates" cuando un grupo de editoriales decidieron que los autores tenían que definir el contenido de forma lógica mientras los editores se dedicaran a la presentación física que es pa lo que al fin y al cabo les pagan :). Así después de unos cuantos quebraderos de cabeza se llega a un estándar ISO con una especificación muuuuy compleja. Pero claro, esto pa los libros y un grupo reducido de gente dispuesta a andarse con rodeos está mu bien, pero pa Internet digamos que la cosa estaba chunga. Así surge una simplificación que aprovechaba la experiencia previa de SGML para orientarlo a Internet y que permitía fácilmente la definición de nuevos lenguajes (de ahí el eXtensible de "eXtensible Markup Language"). Sobre todo, lo que se buscaba era un lenguaje que fuese fácil de procesar, y a la vista está que lo consiguieron. Podíamos decir que con XML se consiguió un 80% de la funcionalidad de SGML con sólo un 20% de su complejidad. Todo un logro, ¿verdad?

Pa no confundirnos, y como a alguno ésto le puede sonar a HTML aclaremos que
XML == SGML--
pero...
XML != HTML++

Aunque la sintaxis XML pueda recordarnos a HTML (de hecho las versiones actuales de HTML son ya XML, más concretamente se le llama XHTML), XML presenta algunas diferencias con el tradicional HTML de to la vida. Algunos ejemplos son:

• En HTML podíamos alegremente cerrar y abrir las etiquetas donde nos diese la gana, e incluso algunas ni cerrarlas, por lo que se suponía </p> por defecto. En XML ni de coña. Cada etiqueta que se abra debe ser cerrada adecuadamente, e importando y mucho el orden. Así mientras en HTML podíamos escribir <p><i>jeje</i></p>, en XML no se puede en aras de un procesamiento más simple y de más claridad.
• Mientras en HTML los valores de los atributos podían o no ir entre "", en XML es estrictamente obligatorio que lo hagamos.
• En HTML podíamos dejar un atributo vacío sin cerrar, pero en XML todo elemento se cierra. Por ejemplo:
  (HTML) <img src="http://www.blogger.com/...">
  (XML) <img src="http://www.blogger.com/..." /> (nótese que pa ahorrarse el curro de volver a poner la etiqueta con "/" delante, si el elemento es vacío se puede poner el símbolo "/" antes de cerrarlo).

Dicho ésto vamos a ver un ejemplo sencillico XML y sobre él ya vamos trabajando.

Veamos qué pinta tiene

<?xml version="1.0" encoding="UTF-8">
<!DOCTYPE empresa SYSTEM "empresa.dtd">

<!-- Definición de una empresa emprendedora, "así tó wapa" podíamos definirla-->
<empresa clase="wenaquetecagas" contacto="nidea@nidea-soluciones.com">
<nombre>N-IDEA. Nuevas Ideas</nombre>
<url tipo="web">http://www.nidea-soluciones.com</url>
<url tipo="blog">http://nidea-soluciones.blogspot.com</url>
<direccionpostal>C/ Tejuela, 25. Alcalá la Real (Jaén). CP: 23680</direccionpostal>
</empresa>

Como véis, es bastante intuitivo. Yo defino lo que quiero y con la lógica que yo quiero imprimiéndole semántica a lo que escribo. De hecho sin saber programar una persona que leyera el código de arriba muy probablemente comprendería el mensaje. Ésa es la idea.

Pero vamos a lo que nos ocupa. Bueno, aquí tenemos varias cosas. Primero tenemos
<?xml version="1.0" encoding="UTF-8">
Ésta es lo que se llama una "processing instruction", pero además es una especial. Es la que debe contener todo documento XML al principio. Ántes de ella no se puede escribir nada, ni siquiera comentarios, para que el documento sea válido. Las processing instruction sirven para pasarle información a la aplicación que usa el documento XML. Normalmente su sintaxis es:
<?Programa Instrucciones?>
Como por ej: <?JAVA_OBJECT JAR_FILE="/nidea/mijar.jar"?>
Por supuesto, para no confundir al bicho, está prohibido empezar la processing instruction con "xml" ya que este nombre está reservado para el principio del documento como habéis visto.
Lo que sigue a "xml" son dos atributos de nombre version y encoding, y de valores 1.0 y UTF-8 respectivamente. Aunque os lo podéis imaginar, son la versión y la codificación del documento. La version es obligatoria que sea 1.0 (creo), y que aparezca siempre, pero la codificación puede no aparecer o puede ser distinta. Por ejemplo, un tipo de codificación muy típica es la ISO-8859-1 que viene a ser la que define los caracteres españoles específicamente. La UTF-8 es también llamada Unicode-8 y es la que he usao en este caso.

Siguiente cosa rara que vemos es...
<!DOCTYPE empresa SYSTEM "empresa.dtd">

Es una etiqueta especial ya que como se puede observar no sigue la sintaxis de xml para las etiquetas. No va cerrada, el nombre de la etiqueta comienza por ! en lugar de por letra o "_" y tiene espacios. Entonces...¿qué #!*+ es? Pues se trata de la definición del tipo de documento. Como ésto es sólo una breve introducción no entraré en detalles, pero es necesario saber que debe apuntar al elemento raiz del documento xml (lo que sigue a !DOCTYPE, en nuestro caso empresa) y al DTD del documento, que viene a ser un fichero que especifica la estructura de nuestro documento xml, qué elementos pueden ir dentro de otros, qué tipo de datos se acepta en cada elemento, cuántas veces puede aparecer un elemento, etc. Pero eso ya lo veremos luego. En nuestro caso, el DTD está en la misma carpeta del documento xml y se llama "empresa.dtd".

Después vemos un comentario. Es eso de...
<!-- Definición de una empresa emprendedora, "así tó wapa" podíamos definirla-->
Pos eso, se trata de un comentario. Algo que el/la programador/a escribe para que no sea interpretado por los programas que hagan uso del documento, pero que puede servir para hacer más legible el mismo o para explicar algunos detalles específicos a otros/as programadores/as que puedan leer nuestro xml. En ocasiones también se usa para ocultar elementos a los programas. En fin, usarlos mola, pero no usarlos no hace tu documento no válido.

Y luego viene el documento en sí, con sus etiquetas, sus atributos y demás. De eso creo que poco hay que explicar. La cosa está en imaginar de forma lógica la información que queremos representar y luego escribirla con coherencia. Si queremos representar en un documento una empresa que puede ser de varias clases y que tendrá un único e-mail de contacto, una forma de representarlo sería con la que escogí arriba:
<empresa clase="wenaquetecagas" contacto="nidea@nidea-soluciones.com"></empresa>
pero ahí ya está vuestra imaginación y el tipo de datos que queráis representar. Si además sabemos que una empresa tiene un nombre, nos podemos inventar un nuevo elemento que esté dentro de "empresa" y cuya etiqueta sea "nombre". Si sabemos que la empresa tendrá urls de varios tipos y múltiples, una fórmula puede ser crear otros tantos elementos también dentro de "empresa" de etiqueta "url" y con un atributo "tipo" que defina el tipo de url que es (página web, blog, wiki...). Si por último sabemos que las empresas representadas por este tipo de documento pueden tener una dirección postal que queramos representar, nos podemos imaginar un último elemento "direccionPostal" que almacene esta información. Pero lo que os dije antes, todo es imaginar e inventar. Ahí los creadores sois vosotros/as.

Bueno, visto un ejemplo práctico sobre el que habremos visto la dinámica de XML, vamos a ver algunas cuestiones específicas de los elementos y los atributos.

Elementos y Atributos

Los elementos deben comenzar su nombre por letra o underscore (_) seguido de alguna combinación de letra, underscore, números, puntos, dos puntos o guiones. No puede contener espacios en blanco y no puede comenzar por "xml" en ninguna de sus variantes (xml, xmL, xMl, xML, Xml, XmL, XMl o XML). En principio no existe longitud máxima para el nombre aunque hay que tener cuidado con algunos parsers de nivel superior que puedan tenerlo.

Los atributos se definen en la etiqueta de comienzo de un elemento. Definen pares nombre="valor". No pueden estar duplicados dentro de la misma etiqueta, usan para su nombre las mismas reglas que los elementos y son obligatorias las comillas para determinar el valor. Como es lógico, el símbolo de las comillas (") no puede aparecer en el valor del atributo, para lo cual se utilizará la entidad predefinida & quot; (sin el espacio entre & y quot;. No lo junto porque entonces vuestro navegador os lo mostraría como " y entonces habríamos hecho un pan con unas hostias).


DTD

Veamos lo último que nos falta para poder definirnos nuestro lenguaje XML a nuestro gusto. Pongamos que vamos a definir un nuevo lenguaje que llamaremos NideaML.
Como hemos visto antes, NideaML es un lenguaje sencillico y que sirve para definir una empresa dado su nombre, clase, correo-e de contacto, urls de varios tipos y dirección postal. Si dejáramos nuestro documento anterior tal cual eliminando la sentencia de !DOCTYPE, ya no sería NideaML, sería XML normalico y corriente porque no existirían restricciones que impidieran a nadie meter otros atributos en el documento o inventarse nuevos elementos, o no colocarlos en su debido orden. Si no hay DTD, se asume que cualquier cosa puede ir dentro de cualquier cosa y se admite cualquier tipo de elemento. ¿Pero cómo podemos añadir estas restricciones? Como ya os dije antes, para eso está aquí nuestro amigo el DTD.

Como antes, no hay mejor forma de aprender algo en cualquier tipo de programación que viendo algo programado, así que os mostraré cómo quedaría el DTD llamado empresa.dtd, que quedaría como sigue...

<!ELEMENT empresa (nombre, url*, direccionPostal?)>
<!ATTLIST empresa
clase CDATA #REQUIRED
contacto CDATA #REQUIRED>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ATTLIST url
tipo (web | blog | wiki | proyecto) "web">
<!ELEMENT direccionPostal (#PCDATA)>

¿Qué? ¿Cómo lo veis? ¿Bonito no? :).
Se puede intuir más o menos la sitaxis, pero vayamos poco a poco. De lo primero que ya os habréis percatao es que no se trata de XML, se parece más a nuestro querido !DOCTYPE que al resto de lo que hemos visto.

Bien, queremos definir qué elementos se permiten, cuáles están dentro de cuáles, qué atributos tienen, si son o no obligatorios y de qué tipo son.

Empecemos por los elementos. Los elementos se declaran con !ELEMENT seguido de su nombre y entre paréntesis el tipo de datos que van a contener indicando cuántas veces van a ocurrir. El nombre del elemento sigue las reglas que ya citamos antes, y el tipo de datos que van a contener pueden ser otros elementos (se pone el nombre de éstos), texto normal (#PCDATA), una combinación con expresiones regulares de las anteriores (ej: nombre | #PCDATA | (otroNombre, otroMas) ), cualquier cosa (ANY) o nada (EMPTY).
El número de ocurrencias de cada cosa que puede entrar en nuestro elemento lo definen unos caracteres que se añaden al final del nombre del elemento/expresión regular. Veamos nuestros símbolos para las expresiones regulares:
si no ponemos nada implica que ocurre sólo una vez
+ indica una o más veces
* indica cero o más veces
? indica cero o una vez
() indica agrupamiento
| indica disyunción
, indica secuencia ordenada
Vamos pues a echarle un vistazo a nuestro ejemplo para ver eso qué implica.

<!ELEMENT empresa (nombre, url*, direccionPostal?)>
Según lo dicho antes, esta declaración define un elemento de nombre "empresa" que puede contener a su vez otros elementos, y sólo otros elementos, no puede tener texto plano; y además estos elementos tienen que ser de tipo "nombre","url" y "direccionPostal"; y además tienen que aparecer en este orden; y además ocurrirá que,
"nombre" aparecerá sólo una vez,
"url" puede aparecer cuantas veces quiera o no aparecer,
"direccionPostal" puede aparecer una vez o no aparecer

¿Fácil no? Ahora vamos con los atributos
Los atributos se declaran con !ATTLIST seguido del nombre del elemento al que pertenecen y seguido de la lista de atributos que puede contener este elemento.
La lista de atributos se escribe siguiendo triplas del siguiente modo
nombre_atributo tipo_atributo valor_por_defecto
Ocasionalmente puede ir entre el tipo de atributo y su valor por defecto la obligatoriedad o no de que aparezca el atributo, de modo que
#REQUIRED significa que el atributo es obligatorio
#IMPLIED significa que el atributo no es obligatorio
#FIXED significa que el atributo está fijo al valor que ponemos por defecto y el programador del documento xml no puede modificarlo. Si lo hiciera esta valor es ignorado prevaleciendo el del DTD.
El valor por defecto sólo tiene sentido cuando el atributo es #FIXED o #IMPLIED. En el caso concreto de #FIXED además es obligatorio. La cosa es que si ponemos a un atributo #REQUIRED se supone que es obligatorio, luego el programador pondrá un valor sí o sí, ¿para qué íbamos a darle un valor por defecto si siempre sería machacado por el del programador XML?
Los tipos de datos pueden ser:
CDATA -> Similar al #PCDATA de los elementos.
Enumerated -> Tienen su sintaxis especial, es el que hemos usado en el ejemplo para el atributo "tipo" del elemento "url". Consiste en una expresión de posibles valores separados por (|) donde el programador/a elegirá uno de ellos.
ID -> Asocia al elemento un identificador único.
IDREF -> Referencia a un ID.
IDREFS -> Lista de IDREF separados por espacio.
NMTOKEN -> Especifican identificadores.
NMTOKENS -> Especifican listas de identificadores.

Si todo esto lo aplicamos a nuestro ejemplo particular...
<!ATTLIST empresa
clase CDATA #REQUIRED
contacto CDATA #REQUIRED>
...implica que estamos tratando con la lista de atributos del elemento "empresa"; que además puede tener atributos tipo clase o tipo contacto; que además clase son datos normales y corrientes y es obligatoria su aparición; y que además contacto también tendrá como valores datos normales y será obligatoria su especificación en el documento XML.

<!ATTLIST url
tipo (web | blog | wiki | proyecto) "web">
...implica que estamos tratando con la lista de atributos del elemento "url"; que además sólo tendrá el atributo "tipo"; que éste podrá ser igual a "web" o "blog" o "wiki" o "proyecto" y que en caso de no encontrarse el valor por defecto será de "web".

Y bien, yo creo que como introducción a lo que puede ser XML y su definición mediante DTDs, ésto ya está. Ya podéis haceros vuestro lenguaje MiracomomoloML para definir todo lo que se os ocurra. ¿Y para qué? Pues por ejemplo una utilidad muy buena es la de pasarle al documento una hoja de estilo XSLT y transformarlo directamente en una página web con un formato determinado, que puede servirnos para crear páginas web dinámicamente en una máquina a partir de una aplicación que recoja unos datos de un formulario web, o para utilizar sistemas como DOM o JDOM para recorrer la información recogida en el formulario web y convertida a XML y usarla para hacer otra cosa, o para crear apliciones...¡yo qué se! yo ya os he contao como funciona, ahora ¡a buscarle utilidades propias, coño! :).

Espero que os sea de utilidad. Si así es, prometo volver para contaros un poco de XMLSchema, que vienen a ser los sucesores de los DTD y que permiten más versatilidad y especificidad en las definiciones.

+info:
http://www.w3.org
http://www.xml.com
http://www.xmlinfo.com

Subversion: Colaboración en el Software

En este artículo vamos a ver el funcionamiento de Subversion, una herramienta libre que sirve como repositorio de código en los proyectos de desarollo software. La utilización de un repositorio de código, un sitio central donde se vayan juntando todas las partes desarrolladas por las diferentes personas involucradas, es obligado. Sin embargo, Subversion nos ofrece una serie de funcionalidades que la convierten en una de las herramientas colaborativas más utilizadas.

¿Qué es un repositorio?
Un repositorio de código es, en esencia, un programa que sirve para juntar las partes de código que los desarrolladores programan por separado. Las funcionalidades básicas (aunque no todos las cumplen) son las siguientes:

• Mantener revisiones de código, es decir, si yo cambio algo en el repositorio, el gestor de código debe mantener puntos de restauración, de forma que cualquiera pueda descargarse el código con mis modificaciones o sin ellas.
• Seguimiento de Cambios, debo poder realizar comentarios cuando actualice algo, indicando qué es lo que he cambiado, qué es lo que he arreglado, etc. de forma que el resto de desarrolladores puedan consultar mi comentario y saber qué es lo que he hecho antes de descargarselo.
• Copias de seguridad de los códigos y las revisiones.
• Etiquetas de versiones y revisiones, para poder localizar rápidamente la versión a descargar o la revisión específica.

¿Por qué utilizar un repositorio de código?
Cuando nos encontramos involucrados dentro de proyectos de desarrollo donde trabajan diversas personas cada una de ellas conocerá una parte del desarrollo y se centrará en ella. Sin embargo, aunque cada uno lleve su parte, necesita la de los demás para que funcione correctamente. Sin un repositorio, tendríamos que enviarnos constantemente todas las partes unos a otros con el consiguiente caos, o que una persona se dedicase a recibir todas las modificaciones y mandarlas al resto de desarrolladores. En el siguiente diagrama se muestra un poco esta situación:











En el caso que tengamos un repositorio de código, la situación sería diferente. Cada desarrollador estaría conectado con el repositorio y enviaría sus modificaciones al mismo. Este se encargaría de conjugar las diferentes partes y mostrar a los desarrolladores la versión completa.

Operaciones con los repositorios:
Existen dos operaciones básicas que se realizan en todos los respositorios y luego algunas funcionalidades avanzadas de algunos mejor preparados, caso de Subversion.

• Confirmar: subir los cambios que hemos realizado al repositorio. Únicamente se enviarán los cambios realizados con respecto a la versión existente en el repositorio.
• Actualizar: recibir la versión existente en el repositorio con los cambios que hayan realizado el resto de desarrolladores.

Las operaciones especiales que tenemos en los repositorios y que le dan un valor añadido son:

• Creación de etiquetas y versiones: nos permite marcar con una etiqueta una confirmación de cambios o crear una versión, de forma que se pueden localizar rápidamente las revisiones o versiones.
• Creación de ramas de desarrollo: esta opción permite crear líneas independiente de desarrollo. Esto se utiliza para el desarrollo de partes de las aplicaciones que no queremos que interfieran en la rama principal hasta que estén acabadas. Una vez terminadas, se fusiona la rama de desarrollo con la principal.
• Bloqueo de ficheros: habrá veces que estemos modificando un fichero y no queramos que nadie lo toque mientras lo tengamos nosotros. En ese caso, bloquearemos el fichero y el repositorio no dejará que nadie lo utilice.
• Fusión de ficheros: esta es una de las herramientas más potentes de Subversion ya que permite que varias personas trabajen simultáneamente sobre el mismo fichero, encargándose él de fusionar los cambios. En caso de surgir un conflicto porque varias personas han modificado la misma parte del fichero, tendrá que ser el usuario el que diga cual es la modificación que prevalece.

Utilización del repositorio:
Como en todas las fases de un proyecto, es necesario plantearse una estrategia para la utilización del repositorio. Subversion se basa en carpetas dentro de las cuales se organiza la información. Para acceder al repositorio se puede hacer vía un servidor Apache (utilizando http) o mediante el servidor subversion (protocolo svn). Dentro del servidor accederemos a una carpeta o subcarpeta para actualizar nuestra información. Se aconseja siempre que los ficheros que se mantengan controlados por el repositorio sean los de código fuente, excluyendo ficheros binarios, compilados, librerías, etc. La estructura de carpetas aconsejable es la siguiente:

• Carpeta TRUNK: rama principal de desarrollo, aquí irá el desarrollo principal y se irán fusionando las diferentes ramas.
• Carpeta TAGS: carpeta donde se almacenarán las diferentes versiones y revisiones con nombre del desarrollo. Cuando queramos descargarnos una versión la buscaremos en esta carpeta
• Carpeta BRANCHES: carpeta donde se almacenan las ramas de desarrollo de nuestro sistema.

Manteniendo esta simple jerarquía de carpetas será mucho más fácil gestionar nuestro repositorio de código y realizar las copias de seguridad.

Conclusión:
La utilización de un repositorio de código es obligado en proyectos que cuenten con más de dos o tres personas trabajando. No solo nos sirven como controlador de los cambios, sino también como copia de respaldo del código. Es muy aconsejable utilizarlos y sacarles el máximo de provecho.

Gestión de Proyectos de Cooperación al Desarrollo

1.Presentación

El objetivo de esta entrada es introducir una ya conocida herramienta en la gestión de proyectos de cooperación al desarrollo llamada "Enfoque del Marco Lógico" (EML).

2.Proyectos de desarrollo

¿Qué entendemos por desarrollo?

Un problema serio que nos encontramos a la hora de elaborar un proyecto de cooperación al desarrollo es que nos lanzamos a desarrollarlo sin habernos parado a pensar seriamente qué entendemos nosotros por desarrollo. ¿Qué es desarrollo? ¿desarrollo económico? ¿desarrollo humano? ¿mejora de las capacidades individuales? ¿mejora de las capacidades colectivas? ¿mejoras puntuales de las condiciones de vida? ¿mejora de las herramientas que generan las condiciones de vida? Es necesario que esto quede claro.
El desarrollo, entendido desde el punto de vista de un proyecto de cooperación al desarrollo siempre ha de ser el de la mejora de las condiciones de vida colectivas, que devendrá en la mejora de las condiciones individuales, desde la óptica del desarrollo humano siempre y salvaguardando los derechos humanos, la justicia social y los derechos colectivos de grupos étnicos y nacionalidades.

¿Qué es un proyecto de desarrollo?

Los proyectos de desarrollo tienen el objetivo de solucionar unos problemas o necesidades y mejorar la situación de los beneficiarios aplicando diversas técnicas y garantizando siempre la independencia de la población beneficiaria así como la dirección activa del proyecto por parte de éstos.
Una de las tareas principales del proyecto debe ser capacitar a sus beneficiarios para que sean más independientes de la ayuda y el apoyo exterior.. que sean capaces de resolver nuevos problemas por sí mismos.

Estructura de un proyecto de desarrollo
Un proyecto se estructura en 4 fases principales:

• Identificación

En esta fase lo que hacemos es determinar los problemas que han de resolverse.. ¿qué sucede?, ¿por qué sucede?, ¿a quiénes y cómo afecta?... ¿cómo se puede solucionar?.

• Diseño

En la etapa de diseño organizaremos la información obtenida en la fase anterior. Aquí hay que establecer las estrategias a seguir, los plazos, los costes, los recursos necesarios.. ¿qué queremos hacer?, y ¿cómo pretendemos realizarlo? ¿a quién se dirige la acción?, ¿por qué y para qué actuar?, ¿con quién, dónde, cuándo y con qué recursos?
En esta etapa construiremos el esqueleto del proyecto: la llamada Matriz de Planificación del Proyecto, que será nuestra guía a seguir para poder llevar a cabo la fase de Ejecución.

• Ejecución

Éste es el punto es donde comenzamos a ejecutar el proyecto según lo planificado. Aquí es importante ser flexible y no seguir con rigidez el plan previsto, además de contemplar la identificación de nuevos problemas que pudieran no haberse captado durante las etapas previas.

• Evaluación

Una vez ejecutado el proyecto, no vale simplemente con recoger los bártulos e irse a otra parte.. Es muy importante realizar un seguimiento posterior, ver si realmente se consiguen los objetivos iniciales de mejorar las condiciones de vida de los beneficiarios. Y aprender de los errores cometidos para mejorar en los próximos proyectos..

Pese a que se plantean como 4 fases diferenciadas, el formato de seguimiento de éstas no es estrictamente lineal sino que sería más bien circular teniendo en cuenta que cuando se detecta un nuevo problema en alguna fase podemos tener que repensar todas las fases anteriores.

3.Centrándonos

En ésta entrada nos vamos a centrar en la fase de Identificación y de Diseño, que son muy importantes pues serán la base de nuestro Proyecto. Si fallamos aquí… es bastante probable que nuestro proyecto se vaya al garete. Desgraciadamente el 30% de los proyectos de cooperación fracasan y el motivo suele ser que fallan en estas fases.

¿Qué es el Enfoque del Marco Lógico?

Para diseñar nuestro proyecto vamos a utilizar la principal herramienta de gestión de proyectos de Desarrollo: El Enfoque del Marco Lógico, convertido ya en método universal de la mayor parte de las agencias de cooperación internacional y que demuestra especial utilidad en las tareas de identificación y gestión de proyectos. De hecho, pese a que ha quedado ya institucionalizada como procedimiento indispensable para solicitar financiación de proyectos de cooperación al desarrollo a agencias y organismos donantes, la herramienta pudiera servir para la identificación y gestión de proyectos de cualquier tipo, no sólo de cooperación al desarrollo.

Características del EML

• Nos permite tomar decisiones mejores y más razonadas.
• Es un método participativo.. que no se puede llevar a cabo sin tener en cuenta a los beneficiarios. Hay que insistir en que los proyectos no se preparan en un despacho ni de manera individual. Los proyectos se identifican y diseñan en equipo y en el seno de esos equipos deben estar representados los beneficiarios, siempre que eso sea posible. Si olvidamos esa perspectiva, la mayoría de los pasos que vamos a comentar habrán perdido su sentido.
  

Un problema que presenta el EML es que luego no se lleve a la práctica, uno puede hacer un análisis teórico perfecto e impecable… pero luego en la práctica dejar de hacer muchas de las cosas planificadas y ésto es como un puente al que no se le puede andar quitando pilares así como así, pues se te viene abajo.

Por ejemplo, imaginad un proyecto en el que se mueven todos los medios para instalar unos equipos de radio que saquen de su aislamiento a unas comunidades. En ocasiones, por falta de tiempo los cooperantes instalan los equipos y luego apenas enseñan a los pobladores a utilizarlos. Si el EML se hace correctamente, esa capacitación forma parte del proyecto, es más, quizás la parte más vital para el funcionamiento correcto del mismo y para su perdurabilidad en el tiempo. Ya sabéis, si no cumples con una determinada etapa, sea cual sea, la estás cagando.

Estructura del EML

El EML consta de 5 pasos:

Análisis de la participación: Averiguar todos los actores, las relaciones entre ellos y determinar a quién va destinado el proyecto.

Análisis de los problemas: ¿qué problemas tienen los actores?

Análisis de los objetivos: ¿como se podrían solucionar cada uno de esos problemas?

Análisis de las alternativas: entre las soluciones anteriores, aquí elegiremos la que llevaremos a cabo.

Matriz de planificación del proyecto: tabla esquemática que resume la identificación del proyecto y facilita enormemente la gestión del mismo.

4. Participación.

Antes de nada, es necesario conocer la realidad social de la zona donde pretendemos actuar. Y para ello no hace falta ser sociólogo, basta con hablar con la gente y sobre todo.. escucharla. Así podremos descubrir qué inquietudes y problemas tienen y qué grupos están afectados por ellos.
Con el análisis de la participación se pretenden básicamente dos cosas. En primer lugar, se trata de tener una visión, lo más precisa posible, de la realidad social sobre la que el futuro proyecto pretende incidir. Muchas intervenciones de desarrollo fracasan, precisamente, por haber efectuado un diagnóstico excesivamente superficial del contexto en el que deben insertarse.
Un proyecto comienza siempre determinando quienes son los colectivos cuya situación se quiere mejorar.
Es preciso mostrar qué problemas afectan a qué personas, cuáles son las relaciones entre los diferentes grupos que conforman una realidad, entre esos grupos y los problemas identificados y entre los propios problemas que se han detectado, para finalmente alcanzar los criterios que establecen las prioridades para elegir la alternativa considerada más deseable.

5. Identificación de los actores y árbol de problemas

Una vez recogidos todos los datos del terreno llega la hora de poner un poco de orden y de analizar la situación que nos hemos encontrado en clave de problemas. Al fin y al cabo el análisis del proyecto depende de varios factores clave:

La calidad de la información disponible.

La capacidad del equipo del proyecto.

El nivel de participación de la población beneficiaria y contrapartes locales en el análisis del problema.

La experiencia previa del equipo.

Salvo la experiencia previa, el resto de factores dependen de la etapa que acabamos de desarrollar y de cuánto impliquemos a las partes locales en el análisis y procesado de la información que hagamos ahora.

Comencemos con la identificación de los actores, que van a poder ser de los siguientes tipos:

Gobierno (regional, local, nacional, extranjero, etc).

Población local (familias, poblaciones, comités, etc).

Sector privado (cooperativas, PYMEs, grandes empresas, etc).

Organizaciones no gubernamentales (asociaciones, colectivos, del lugar, del norte, etc).

Ecosistemas (fauna, flora, lugares protegidos, entornos de vital importancia para supervivencia de poblaciones, etc).

Si se han identificado correctamente los actores y extraído adecuadamente la información necesaria debiéramos ser capaces de construir la "tabla de análisis de actores", que debiera tener al menos la siguiente profundidad:

Actores	Características	Problema	Interés	Potencial	Inter-relación
Actor 1
Actor 2
Actor 3
Actor 4
...

Una vez tenemos ya una buena tabla con todos los actores implicados en nuestro proyecto, sus relaciones, problemas y demás vicisitudes, llegó la hora de construir nuestro árbol de problemas que nos demuestre de forma causal cuáles son los más importantes que han de atajarse para producir un efecto dominó sobre sus derivados. El resultado ha de ser algo parecido a ésto:

Hemos de tratar de ser claros a la hora de definir los problemas, no situarlos por orden de importancia, sino de causalidad y consecuencia, y tratar de situar problemas actuales, no futuros.

Por último identificamos el que será el problema principal, que trataremos de atajar con el proyecto que estamos desarrollando.

6.Árbol de soluciones (o árbol de objetivos)

Bien. Analicemos nuestra situación actual. Ya tenemos los problemas analizados junto con los actores que intervienen y además clasificados según unos sean causas o efectos de otros e identificado el problema principal, foco de todos nuestros odios y rabias. Ha llegado la hora pues de transformar lo negativo en positivo, los problemas en soluciones, o más bien, en objetivos a cumplir. Le damos la vuelta a cada problema y lo convertimos en su objetivo/solución. Ejemplos:

Problema -> La población tiene un problema serio de desnutrición.
Objetivo/Solución -> La población está correctamente nutrida.

Problema -> Existe una sequía que está devastando la agricultura.
Objetivo/Solución -> No existe sequía alguna.

Como vemos al hacer la transformación nos surgirán algunas soluciones válidas como la primera, que puede ser alcanzable por medios a nuestra disposición, pero otras irreales, o cuanto menos, que se quedan en buenos deseos, como el caso del segundo problema donde nosotros de ninguna manera podemos intervenir para una solución inmediata (si, ya sé que podemos influir en el calentamiento global y sus efectos, pero ya me entendéis lo que quiero decir).

Además, cuando el objetivo/solución sea suficientemente genérico podremos concretarlo dividiéndolo en objetivo principal y objetivo específico, siendo el principal el objetivo último que mueve el proyecto y el específico lo que objetivamente vamos a conseguir si realizamos el proyecto. Un ejemplo:

Problema -> La población tiene un problema serio de desnutrición.
Objetivo/solución -> La población está correctamente nutrida.
Objetivo principal -> La red de cultivos y distribución de alimentos está en buen estado.
Objetivo específico -> La producción agrícola es dedicada al consumo interno.
Objetivo específico -> La distribución de alimentos en mercados locales es proporcional a la población total a quien distribuye y su nivel de necesidad.
Objetivo específico -> Las variedades de alimentos cultivadas/criadas son suficientes para una correcta nutrición.

Una vez transformados los problemas en soluciones/objetivos, toca transformar el árbol de problemas en un árbol de soluciones/objetivos. Si el primero mostraba causa/efecto de los problemas, el segundo muestra medios/fines de las soluciones/objetivos. Un resultado pudiera ser éste algo como...

Lo siguiente será hacer limpieza eliminando las soluciones no válidas que nos hubieran surgido, volviendo a formular las que no quedasen bien expresadas y añadiendo los objetivos específicos que hubiésemos visto necesarios.

Ya tenemos los objetivos principales y específicos seleccionados y en nuestro árbol de objetivos ha quedado de tal manera que algunos objetivos quedan al mismo nivel determinando estrategias a seguir diferentes posibles. ¿Qué hacemos? seleccionar cuál será la nuestra en función de su viabilidad contando para ello con todas las variables que nos sean necesarias. Descartaremos el resto.

Para esta selección nos podemos apoyar en una tabla como la que sigue:

Alternativas\Criterios	Coste	Posibilidad de éxito	Beneficio/coste	Horizonte temporal	Dependencia	Riesgo social
Alternativa 1
Alternativa 2
Alternativa 3
...

Esta tabla se suele rellenar con valores como Baja/Media-baja/Media/Media-alta/Alta. Una fórmula para obtener la alternativa más deseable es luego dar valores numéricos a los anteriores (por ejemplo: Baja=0; Media-baja=1; Media=2; Media-alta=3; Alta=4) y luego sumar cada fila para obtener un resultado mayor en la alternativa ideal para nuestro proyecto. Es evidente que esto supondría tratar con el mismo peso cada una de las columnas, y puede que para nosotros el Coste tenga mayor o menor valor que Riesgo Social, por ejemplo, por lo que otra fórmula que se acostumbra a seguir es la de establecer unos pesos numéricos en el intervalo [0,1] para cada columna siendo el número mayor cuanto más peso tenga para nosotros dicha columna. Este peso será el coeficiente por el que multiplicaremos el valor numérico resultante de la substitución de los valores cualitativos que pusimos a cada columna.

Como ejemplo más gráfico, imaginemos que una alternativa nos ha salido con los siguientes valores:
Coste: Alto -> 0
Posibilidad de éxito: Media -> 2
Relación Beneficio/coste: Alta -> 4
Horizonte temporal que cubrirá el proyecto: Medio -> 2
Dependencia del proyecto de factores externos: Media -> 2
Nivel de Riesgos Sociales que se puedan generar a partir del proyecto: Bajo -> 4

---

TOTAL = 0.7*0 + 1*2 + 0.8*4 + 0.5*2 + 1*2 + 1*4 = 11.6
Nótese que las columnas de coste, dependencia y riesgo social se sustituirán por sus valores numéricos de forma inversa a las demás puesto que pretendemos que lo más positivo para el proyecto obtenga una mayor puntuación y lo más negativo puntuación menor.
Nótese también que los valores de los pesos que hemos establecido dan mayor importancia a los valores de "Posibilidad de éxito", "Riesgo Social" y "Dependencia" frente a "Coste", "Beneficio/Coste" y "Horizonte Temporal".

Si ahora nos topásemos con otra alternativa con mayor puntuación sería ésta la que tendríamos que escoger, de lo contrario estaríamos teóricamente frente a la mejor de las alternativas para nuestro proyecto.

7. Matriz de planificación del proyecto

La matriz de planificación del proyecto constituye, por su parte, la estructura del diseño, el armazón sobre el que se construye el documento de formulación. Si bien la matriz es la base el diseño pero no es todo el diseño. Para que éste pueda considerarse completado es preciso realizar la programación de las actividades y los recursos (calendarios, presupuestos y organización del personal adscrito a la ejecución de todas esas actividades), completar los diseños técnicos siempre que éstos sean necesarios y efectuar una valoración de las posibilidades de viabilidad de la futura intervención.
La matriz se rellena de la siguiente manera:

Esta matriz puede interpretarse usando 2 lógicas distintas, la vertical y la horizontal.

Lógica vertical o lógica de intervención

Ver la matriz desde esta óptica vertical te revela una secuencia lógica que ha de ocurrir en el proyecto:

1. Si los insumos están disponibles, las actividades se llevarán a cabo.
2. Si las actividades se llevan a cabo, se obtendrán los resultados.
3. Si se obtienen los resultados, se alcanzará el objetivo específico.
4. A largo plazo ésto contribuirá a la consecución del objetivo global.
IMPORTANTE: Sólo debe haber un objetivo específico en el proyecto.

• Lógica horizontal

Ver la matriz desde esta óptica horizontal revela también otra secuencia lógica del proyecto:

1. Si los factores externos se cumplen podremos obtener datos de las fuentes de verificación.
2. Con estos datos de las fuentes contrastaremos cada indicador.
3. Si contrastamos positivamente cada indicador diremos que se ha cumplido cada uno de los objetivos, resultados o que se han realizado las actividades en cada nivel.

Aclaración de la columna de "Factores Externos" (o hipótesis):
Los factores externos han de ser problemas que puedan preveerse y que obstaculicen de manera decisiva cada uno de los objetivos. En definitiva, hipótesis.
Se derivan del árbol de objetivos, deben enunciar en positivo, aplican a todos los elementos importantes del proyecto y se valoran y analizan de acuerdo a su importancia y probabilidad.

Aclaración de la columna de "Indicadores Objetivamente Verificables":
Los indicadores fijan el nivel de efectividad necesaria para el proyecto. Son aquéllos cuya medida da igual resultado independientemente de quien la realice. Son importantes en el apartado de evaluación del proyecto.
Un indicador debe ser:

• Específico: importante usar términos precisos.
• Independiente: no deben depender entre sí indicadores de diferentes objetivos para que reflejen objetivamente la consecución de un objetivo.
• Fáctico: no debe reflejar impresiones subjetivas sino hechos.
• Reflejo de datos obtenibles: los datos deben de estar disponibles o de forma inmediata o mediante un esfuerzo extra razonable.
• Medible.

Aclaración de la columna de "Fuentes de Verificación":
Para obtenerlas nos pueden ayudar las siguientes preguntas.
¿Cómo ha de ser la información que se requiere?: p.ej. Registros administrativos, estadísticas nacionales, grupos de trabajo, observación directa...
¿Cual es la fuente más apropiada para proveer la información?, ¿quién debe intervenir?, ¿es fiable la fuente?.
¿Quién recoge la información? (supervisores, equipos independientes...)
¿Cuándo y con qué frecuencia se debe recoger, analizar y sistematizar la información?
¿Cuáles son los formatos en los que se recoge la información?

Construcción de la matriz

Para construir la matriz de planificación del proyecto ya tenemos todas las herramientas, luego lo que tendremos que hacer será seguir un orden lógico para que no se nos escape nada. Un orden que nos puede ayudar podría ser éste:

PASO I - OBJETIVOS - rellenamos la columna de objetivos excepto las actividades

PASO II - ACTIVIDADES - rellenamos las actividades teniendo en cuenta los objetivos rellenados

PASO III - INSUMOS, PRECONDICIONES E HIPÓTESIS - nos encargamos de los insumos necesarios para que se puedan realizar las tareas, las precondiciones para poder obtener los insumos y realizar las tareas y las hipótesis o factores externos que condicionan el proyecto

PASO IV - INDICADORES Y FUENTES DE VERIFICACIÓN - rellenamos los huecos reservados para cada uno de los indicadores que nos objetivizan el éxito del proyecto y las fuentes de donde obtendremos los datos para compararlos con esos indicadores

CONCLUSIONES Y DELIRIOS:
Espero que el objetivo de esta entrada, que era dar a conocer la herramienta del EML de forma superficial a quien la lea se haya cumplido y quien encuentre ésto como recurso de información quede picado por el gusanillo del desarrollo de proyectos de cooperación, busque más información y termine participando en alguno.
Toda la información procede del curso de "Introducción a la Gestión de Proyectos de Cooperación al Desarrollo de Base Tecnológica" que imparte maravillosamente la UOC, de la asignatura "Introducción a la Cooperación al Desarrollo" que se imparte en la Universidad Carlos III de Madrid y de otras muchas fuentes de información extraídas por internet.
Además esta entrada es una adaptación de la sección teórica de una dinámica de gestión de proyectos de cooperación que desarrollamos entre mi compañero Juan José del Valle y yo durante las III y IV ediciones de las Jornadas Solidarias que las asociaciones Ingeniería Sin Fronteras y Asamblea Social Universitaria realizan en la Universidad Carlos III de Madrid, y por tanto somos coautores los dos.


+ info
http://www.isf.es/menu_publicaciones/pub_libros.php?$sesion_idioma=1&$menu=3&identifica=libros&nombrexml=113
http://bicho.uc3m.es/gta/introduccion_mas_links.htm
http://www.preval.org/documentos/00423.pdf