Tecnología y salud

Estaba en la ducha esta mañana cuando me he preguntado ¿Qué hace la tecnología por nosotros, por nuestros cuerpos?. La respuesta ha resultado tan amplia y a la vez tan evidente que no merece la pena mencionar ni uno solo de sus puntos. El caso es que la pregunta siguiente es, sin duda, ¿Qué puede hacer la tecnología por nuestra salud, que no hace ya?. Aquí la respuesta también resulta muy amplia.

Por ejemplo, un conocido mío está trabajando en un proyecto llamado Quirófano Software Libre -espero poder contar algo de él más adelante- y lo que pretende es, si no lo he entendido mal del todo, unificar o interconectar todos los dispositivos y elementos tecnológicos presentes en un quirófano y usar para ello software libre. De esto naturalmente yo se bien poco, porque no soy médico ni cirujano. Sin embargo imagino que en un quirófano hay una gran cantidad de equipos electrónicos de precisión que disponen de interfaces de comunicación y pueden, en definitiva, controlarse o monitorizarse mediante un ordenador. Y es que parece que la cirujía ya no es lo que era... ahora se oye hablar mucho de eso de la "cirujía mínimamente invasiva", MIS en inglés, y parece que para trabajar de ese modo se necesita un gran soporte tecnológico.

Dejando de lado el ejemplo anterior, convivimos día a día con mecanismos y sistemas que aún no están todo lo perfeccionados que deberían estar. Así por ejemplo el programa de Tele-Asistencia del SAS, del que mi abuela es beneficiaria, instala un dispositivo de emergencias en la casa, conectado al teléfono, que permite la comunicación inmediata con los operadores del servicio de Tele-Asistencia presionando solo una tecla. Además, y esto es lo interesante de la idea, se dota al "tele-asistido" de un mando a distancia para emergencias, un pequeño pulsador que deben llevar colgado en todo momento y que, al ser pulsado, avisa a estos operadores. A parte de eso, en lo que a tecnología se refiere hay poco más: los operadores parecen tener a su disposición, de modo inmediato al inicio de la comunicación, el historial de la persona con la que hablan.

Sin embargo el ingenio de todo está en la parte menos tecnológica: Se entrega copia de la llave de la casa a varios vecinos, conocidos que deben vivir cerca del domicilio. En caso de emergencia, los operadores contactan con ellos y les envían a la casa a comprobar el estado del "tele-asistido", de modo que la respuesta inicial es casi inmediata.

Lo que quiero decir es que parece que la tecnología en sí no es demasiado avanzada. Si con tan poco podemos lograr tanto... ¿cuanto no podemos hacer con toda la tecnología de la que disponemos?

Otro ejemplo de esto son los sistemas de ayuda a discapacitados. En el caso de las discapacidades motrices, la mayoría de estos sistemas no pasan de ser una silla de ruedas con batería y un motor. Parece que todos los esfuerzos en este sentido están destinados a posibilitar la vida digna a estas personas, pero nos limitamos al mínimo esfuerzo. En efecto es importante que los minusválidos puedan acceder a todos los servicios a los que accedemos nosotros, que con su silla de ruedas puedan desplazarse por toda la ciudad y entrar a los edificios usando rampas... y por desgracia aún queda mucho para lograr solo eso. Pero ¿nos hemos planteado la dificultad que para ellos supone?

Cuando camino con mi abuela, que está "muy mal de los huesos", me resulta muy molesto tener que dar un rodeo para subir por la rampa y evitar los escalones. Y yo ando a una velocidad normal, ¿cuanto más molesto no será para el discapacitado que usa su silla de ruedas, mucho más lento y con más esfuerzo que nosotros?. Cuando desde el sofá me doy cuenta de que la luz de la cocina se ha quedado encendida, me supone un esfuerzo considerable levantarme a apagarla. Este esfuerzo debe multiplicarse si necesitas un andador. La domótica tiene mucho que decir en este sentido, y no se está explotando para nada.

El caso es que, como vengo defendiendo en los últimos posts, la tecnología de la que disponemos está infrautilizada. Podríamos hacer auténticas maravillas para mejorar la vida de las personas (la nuestra misma) con una pequeña inversión. Podríamos ahorrar a los discapacitados tener que levantarse a encender la luz, o podríamos crear caminos virtuales en las ciudades por los que los ciegos pudiesen caminar tranquilamente guiados por un dispositivo electrónico (y no limitarnos únicamente a los semáforos). En medicina seguramente se podrán hacer también auténticas maravillas (me gustaría saber más de este tema).

Además, no es que no se investigue. Es decir, si tenemos toda esta tecnología es porque alguien ha trabajado en ella. Por ejemplo en el departamento de Arquitectura y Tecnología de los Computadores de la UGR tienen un proyecto llamado CORTIVIS que pretende crear una retina artificial y dotar a los invidentes de ciertas capacidades de visión mediante un implante cerebral. Se logra la tecnología, se inventan multitud de cosas que pueden parecer increíbles, y luego se quedan guardadas en un cajón sin uso alguno.

Pero, volvemos a lo mismo. Si la tecnología está ¿que es lo que falta? ¿Iniciativa? ¿Inversión? ¿Demanda?. Puede que falte un poco de cada cosa... y en esto las autoridades tienen mucho que hacer (España está -sigue- a la cola en gasto en I+D+I y encima se está planteando el terminar con la Ingeniería Informática tal y como la conocemos). Y lo que sobra, también, es la especulación... cuando alguien invierte quiere maximizar sus beneficios; se pone un precio alto y se va bajando conforme se agota el mercado dispuesto a pagar ese precio.

Una de las metas que me mueven a trabajar en el proyecto intelligenia es cambiar, aunque solo sea mínimamente, la situación actual, comenzar a utilizar la tecnología de la que disponemos y a acercarla lo más posible al común de los mortales (me comentaban el otro día que las paredes de la casa de Bill Gates cambian de color según su estado de ánimo).

ajaxslt de google y dojo

Para los que no conozcan ni ajaxslt ni dojo, les dedico estos primeros parrafos, para despues comentar como integrarlos y poder usarlos de forma conjunta utilizando las virtudes de cada uno.

Si hacemos webs 2.0 , deben tener un comportamiento dinámico y atractivo para el usuario, debería usar servicios web y AJAX en definitiva. Si nos conectamos a servicios web que devuelven XML como es normal, obtenemos en javascript un string que contiene el xml, ¿y ahora que hacemos con él? Hay dos opciones. La primera es cargar ese XML en un DOM y mediante xpath ir obteniendo los datos y representarlos en nuestro HTML. La segunda opción es aplicar un XSL a ese XML para obtener el HTML que incrustaremos en nuestra página. Para hacer esa aplicación de HTML = XSL(XML), necesitamos un parser y un transformador que lo haga, Google nos ofrece unas librerías en javascript que se encargan de ello, lo llaman proyecto ajaxslt y es totalmente gratuito.

Por otra parte, ya que tenemos que darle tanta importancia al javascript del cliente para que parezca una aplicacion de escritorio, estaría bien implementar en javascript como si de un lenguaje de alto nivel se tratase. De forma nativa javascript no tiene herencia, ni polimorfismo, ni eventos, ni objetos (existe una chapucilla para conseguir objetos). Así que intentar programar una arquitectura software interesante y escalable con este lenguaje básico puede ser tedioso. Para solucionarlo nace dojo, como otras plataformas, que nos permite utilizar javascript, pero nos facilita el tener herencia, polimorfismo, efectos, eventos, paquetes tipo java,... Es decir, que con esto si podemos montar una buena arquitectura.

Llegado este punto nos puede surgir el caso en el que nos hemos decidido por utilizar dojo como plataforma en el cliente y que queremos utilizar ajaxstl como transformador de XML y XSL. Esto puede convivir sin problemas si se trata por separado, pero ¿y si queremos que ajaxslt sea un paquete dentro de nuestros paquetes de dojo? esto sería muy interesante ya que todo lo que utilizamos tiene un mismo estilo, todo son paquetes, y no hay cosas de una forma y cosas de otra. Para conseguir integrar ajaxslt en dojo, pueden surgir problemas de compatibilidad entre navegadores, así que os digo como solucionarlo sin ningún problema.

En javascript podemos definir funciones de dos formas diferentes:

function mifuncion (miarqumento){
//codigo
}

o de la siguiente forma

mifuncion = function(miargumento){
//codigo
}

Pues bien, si integramos directamente ajaxslt en dojo tenemos que las funciones y variables se definen de la primera forma, esto ocasiona un problema y es que con dojo y esa primera forma en Internet Explorer funciona correctamente, pero en FireFox no funciona nada. Esto se debe a que FF entiende que si defines la funcion de la primera forma, es una funcion local, por lo tanto cuando dojo se trae ese paquete, pues esas funciones quedan locales al paquete y no se pueden usar desde fuera, por eso no funciona nada, en cambio IE las toma como globales y todo funciona.

La solución es modificar todas las cabeceras de las funciones para ponerlas de la segunda forma, además todas las variables que queramos que sean globales, no deben llevar el "var " delante, ya que entonces estamos en el mismo problema, que se piensa que es una variable local.

Costó mucho encontrar ese problema, porque en principio no parecía lógico que en uno funcionase y en el otro no, así que tras muchas horas se detectó y tras eso, en cuestión de 20 minutos ya estaba todo integrado y funcionando.

Jose Carlos Calvo Tudela

Tags vs Categorías

La tendencia actual a la hora de clasificar contenido esta evolucionando de forma que se está sustituyendo la típica clasificación en categorías por etiquetas (o tags como es más conocido). Pero, ¿realmente suponen una ventaja? ¿Qué ganamos y qué perdemos al usar tags?

Bien, en mi opinión, la principal ventaja que tienen los tags sobre las categorías es que no son excluyentes, es decir, un artículo por ejemplo puede tener varios tags en vez de pertenecer a una única categoría, por lo tanto es mucho más fácil de clasificar al no tener la necesidad de ceñirse a un solo concepto. Pero... realmente sabemos clasificar la información usando tags, ¿Para quién usamos los tags, para un buscador o para un ser humano?

Otro punto a favor de los tags, es que no es el administrador del sistema el que decide los tags, sino los propios usuarios. Esto es útil principalmente en sistemas a los que acceden muchos usuarios e intercambian información. No obstante esto presenta un arma de doble filo ya que aunque el significado semántico de dos tags pueda ser el mismo, los ordenadores trabajan con sintaxis, con cadenas de caracteres y por tanto les sería difícil relacionar tag con etiqueta o ordenador con computadora.

Una característica que perdemos con los tags, es la jerarquización, por ejemplo, si clasificamos a algo como un perro, con un sistema de categorías sabríamos también que es un animal, cosa que no ocurre con los tags.

A la hora de buscar información, esta claro que si sabemos lo que buscamos, los tags pueden ser más útiles, pero ¿Y si no lo sabemos? ¿Y si solo queremos navegar por la información? En este caso los tags son como una nube de información que puede llegar a ser demasiado amplia y dificultarnos la tarea, mientras que las categorías, nos permiten ir especializando la búsqueda progresivamente.

¿Entonces, donde está la revolución de los tags? ¿Quien se beneficia del uso de tags? La respuesta es: Google(o cualquier otro buscador), y por extensión los usuarios del buscador.

Entonces, ¿Cuando usar tags? En mi opinión, los tags son útiles cuando se necesita clasificar grandes cantidades de información altamente heterogénea, en cambio, cuando se trata de información relacionada, creo que las categorías son mucho más útiles.

Domótica from scratch

Es un poco atrevido titular a este post domótica from scratch (que sería algo así como domótica desde cero) y lo es más aún si tenemos en cuenta que de domótica se lo poco que veo en la TV y lo que he cotilleado por ahí de opciones existentes en el mercado. Todo un atrevimiento que espero que quede justificado.

Lo evidente es que la domótica no está teniendo el auge que se podía esperar. La tecnología que vemos ahora existe en su mayoría desde hace décadas... varias además. Ahora contamos con tecnología con la que se podrían hacer maravillas por poco dinero (poco al menos si lo comparamos con lo que cuesta una casa, lo que cuestan las cortinas, las ventanas o cosas similares, y si tenemos en cuenta la importante función que puede llegar a desempeñar un buen sistema de domotización).

La clásica imagen de casa inteligente que todos tenemos en mente, compuesta probablemente de fragmentos de distintas películas, y si eliminamos los elementos utópicos más irreales o, cuanto menos, lejanos, sería algo así:

Cuando llegamos a casa no tenemos que sacar la llave del bolsillo, es suficiente con girar el pomo o empujar la puerta. Las luces se encenderán a nuestro paso, y si vivimos solos empezaremos a oír la música que habíamos programado para hoy, un resumen de las noticias del día o información sobre las llamadas que hemos recibido.

Las persianas estarán convenientemente subidas o bajadas según la hora del día, el nivel de luz y nuestras costumbres y deseos, pero si aún así nos apetece cambiar su estado no tendremos más que tocar sobre una pantalla táctil de las que hay en la entrada de cada habitación, desde donde además podremos bajar la intensidad de la luz y encender la televisión. En ese momento la música se detendrá para que empecemos a escuchar la TV.

Emiten "Quiere ser millonario", y Carlos Sobera hace una curiosa pregunta sobre el inventor del disco duro. Como no tenemos paciencia, desde nuestro mando a distancia activamos el acceso a Internet en el televisor, y buscamos en menos que canta un gallo la respuesta.

Estamos tranquilos en nuestro sofá. Si, por ejemplo, hubiese un escape de gas, el sistema nos informaría. Si no estuviésemos en casa nos mandaría un mensaje al móvil y llamaría a los bomberos...

Naturalmente la historia puede hacerse mucho más larga, pero carece de sentido. Lo importante, lo que me interesa, es que todo lo relatado anteriormente es algo que ya está al alcance de nosotros, y que no sería demasiado caro (al menos no si se prodce el hardware a mediana escala y si se desarrolla el software con previsiones de una buena comercialización). Sin embargo nos parece aún muy distante, al menos su implantación en el común de los hogares. La pregunta que cabe hacerse en este punto es ¿por qué?.

Por un lado las constructoras no tienen problemas de demanda, y por ello no tienen que añadir valor a su producto. Por ese motivo la domótica se ha planteado hasta ahora como un "constrúyalo usted mismo". Son los aficionados a la informática, la electrónica o simplemente el bricolaje los que montan estos sistemas. Y por eso los sistemas comerciales están orientados a ser autoinstalables (sin instalación prácticamente) y sencillos de configurar. El problema de esto es que se trata de sistemas muy limitados. En general no pasan de un enorme mando a distancia desde el que puedes controlar todos los aparatos que tienen mando a distancia y además las luces, quizás unas persianas y poco más. ¿Donde queda la automatización? A lo sumo puedes programar el encendido o apagado de luces según la hora, pero no dejan de ser sistemas limitados y, además, caros. Se trata de sistemas descentralizados y eso supone más limitaciones.

En este punto es donde se puede replantear la domótica desde cero. Sabiendo con qué contamos, solo tenemos que preguntarnos qué queremos hacer, desligarnos si es necesario de lo que hasta ahora se ha hecho y, más adelante, preguntarnos como podemos integrar lo que queremos hacer en los estándares existentes.

Un primer paso para el sistema seria construir una interfaz de entrada/salida tanto analógica como digital que se conectase por un puerto estándar (probablemente USB). De este modo contaríamos con un lugar al que conectar todos los dispositivos (sensores y actuadores) que necesitásemos en un entorno pequeño (por ejemplo una habitación de la casa). A esta interfaz conectaríamos directamente dispositivos como motores, sensores de temperatura, detectores de gas, relés, potenciómetros, etc. También conectaríamos aquí las interfaces de control de aparatos como el aire acondicionado o la calefacción.

Esta interfaz se conectaría por USB a otro dispositivo controlador, que sería el que se encargaría de manejar todas las entradas y salidas. La capacidad y características del controlador son variables según las necesidades: desde un pequeño chipset con firmware y interfaz rj45 que facilite un mecanismo para acceder, sobre una red TCP/IP, a los sensores y actuadores, hasta un PC completo, pasando por un pequeño dispositivo con un S.O. embebido, con red inalámbrica y con un pequeño monitor LCD.

Lo más cómodo, desde el punto de vista del desarrollo, sería contar con dos tipos de dispositivos: con o sin interfaz para el usuario. El primero sería un pequeño cliente con linux embebido y que contase con USB-host, que contaría con un pequeño monitor LCD y unos cuantos botones (o incluso un LCD táctil). Una PDA o un dispositivo similar también podrían ser válidos en algunos casos. El segundo sería un pequeño controlador, también con linux embebido pero con mucha menos capacidad (no sería necesaria ni siquiera contar con capacidades gráficas o interfaz VGA) que dotaría de cierta autonomía a la habitación en caso de fallo del sistema central (por ejemplo las luces seguirían encendiéndose y apagándose a demanda), pero que no contaría con una interfaz de usuario.

Sobre toda la red anterior existiría un servidor central que controlaría todo el sistema y que interconectaría todas las habitaciones. Este servidor sería el que permitiría por ejemplo apagar una luz que nos hemos dejado encendida en la planta de arriba, desde el salón de la planta de abajo sin necesidad de subir. También seria el que se encargaría de la programación de tareas, aunque podría trasmitir ciertas órdenes programadas a los controladores, para dotarlos de mayor autonomía. Este servidor también podría actuar como servidor web, de modo que podamos monitorizar y actuar sobre la casa desde fuera.

La televisión se transformaría en un centro multimedia, con DVD, disco duro y acceso a Internet, desde el que por supuesto también podríamos controlar toda la casa. Del mismo modo todos los PCs de la casa estarían conectados a la red y tendrían también acceso al sistema. Esta red permitiría por ejemplo reproducir en el hilo musical una canción que tenemos en nuestro dormitorio, en el salón ver un documento de texto que tenemos almacenado en nuestro ordenador personal o ver en nuestra habitación el final de una película que grabamos en la televisión porque nos tuvimos que ir.

En definitiva, el hogar aparece como un único ente a nuestro servicio. Cada dispositivo del hogar puede ser parte del conjunto, y el contar con controladores que disponen directamente de entradas y salidas digitales y analógicas dota al sistema de flexibilidad y nuevas posibilidades. El contar, por encima de todo, con una red TCP/IP, permite incorporar al sistema también elementos TCP/IP (cámaras IP, PDAs con wifi, etc) y el contar con controladores con un sistema operativo embebido permite conectar interfaces para acceder a otros sistemas o protocolos existentes (por ejemplo manejar dispositivos X10).

Arquitecturas Web 2.0 1ª Parte

En esta primera parte de Arquitecturas Web 2.0, voy a defender el porqué de estas arquitecturas y en que se diferencian de las arquitecturas de aplicaciones de escritorio. En las siguientes entregas comentaré una a una las arquitecturas que creo que son mas interesantes.

Crear Web 2.0 no es cuestión de tecnologías ni de interfaz de usuario unicamente como ya se discute en otras entradas de este blog, la diferencia la marca una arquitectura de la aplicación Web que nada tiene que envidiar a otras arquitecturas de aplicaciones de escritorio.

Hace un tiempo, los ingenieros se dedicaban a trabajar en empresas en las que podían participar en proyectos de aplicaciones de escritorio para poder ejercer de ingeniero y diseñar arquitecturas potentes. Las páginas Web, conste que no he dicho aplicaciones Web, se dejaba que lo hiciese cualquier persona a la que le gustara y se le diera bien el diseño gráfico, ya que servían para eso, es decir, para publicidad.

Desde que las nuevas tecnologías tanto para banda ancha como lenguajes de programación y servidores Web permiten hacer y pensar en cosas que antes no se planteaban, empezaron a surgir aplicaciones Web, ya el fin no es la publicidad, sino la funcionalidad. Desde ese momento el mundo de las aplicaciones Web capta más y más ingenieros, debajo de cada aplicacion Web hay una arquitectura software y hardware en algunoscasos que no difiere mucho de una aplicación de escritorio.

Ahora con el boom del Web 2.0 las arquitecturas de las aplicaciones se disparan en potencia mucho más arriba de las arquitecturas de una aplicacion de escritorio, para ver esto pongamos un ejemplo,

Tenemos que hacer una aplicación para almacenar información de los CDs que tenemos en una estantería, una cosa muy simple y que no merecería la pena perder mucho tiempo en crear grandes arquitecturas, pero como es un ejemplo, lo vamos a hacer. Si lo hacemos con una aplicación de escritorio pues haciendo una buena arquitectura podríamos hacer un modelo MVC o un modelo de capas, y en cuanto a conexiones, pues con tener conexión con la BD ya estaría todo. Esta aplicación de escritorio parece apetecible para un ingeniero ya que hay cosas interesantes que hacer.

Supongamos ahora que lo hacemos en aplicacion Web, entonces igualmente en nuestro servidor Web podríamos montar una arquitectura MVC o de capas con conexión a BD, esto sería lo que hace una aplicacion Web que no sea Web 2.0 ya que en base a unos parametros de entrada, ejecuta todo su modelo interno y genera un XHTML de salida. Entonces hasta este punto no hay mucha diferencia con una aplicación de escritorio, pero si introducimos el concepto Web 2.0 las cosas cambian, nuestra arquitectura de servidor que ya hemos pensado nos puede seguir valiendo ya que es bastante potente, lo único que hay que cambiar es la vista para que genere por ejemplo XML (este cambio es en cuanto a la arquitectura, queda claro que cambiarían
todos los servicios que ofrece el servidor, pero como estamos en fas ede diseño, pues no lo tengo en cuenta). Además de este servidor ahora tenemos que diseñar el cliente Web, este cliente puede tener una arquitectura MVC o de capas al igual que el servidor, javascript permite hacer esto con orientación a objetos, herencia, polimorfismo, etc. si utilizamos plataformas como dojo, prototype, etc. Entonces podemos decir que tenemos una arquitectura potente en servidor, una arquitectura potente en cliente y además tenemos conexión entre el cliente y el servidor, esto significa un protocolo de comunicación, y en el mundo de las arquitecturas esto significa un modelo cliente-servidor.

Todo sabemos que una aplicación Web es cliente-servidor, pero si implementamos aplicaciones Web tradicionales, ese mecanismo queda transparente al desarrollador y programador. Con aplicaciones Web 2.0 podemos conseguir diseñar un gran cliente-servidor y a la vez tener una arquitectura potente en cliente y otra en servidor. Parece mucho más interesante de desarrollar, y lo es.

Una ventaja que no suele comentarse de estas aplicaciones Web 2.0, es que si por ejemplo como hemos visto el servidor genera XML, entonces no solo es una aplicacion Web, sino que es un servidor orientado a los servicios, esto significa que construimos el servidor, despues el cliente que utiliza los servicios que ofrece el servidor, pero la utilidad del servidor no queda ahí, cualquier otra aplicación posterior o cualquier otra empresa que necesite utilizar nuestros servicios, refiriendome a los datos, es decir, el XML, para integrarlo en sus aplicaciones, lo harán sin tener que modificar nuestra aplicación lo más mínimo. Esta ventaja sería imposible de conseguir con una aplicación de escritorio y es una ventaja muy interesante en este mundo en el que se evoluciona hacia la globalización de la información, ¿no creeis?

Jose Carlos Calvo Tudela

Desarrollo orientado a interfaces

Los que, como yo, estudiamos Ingeniería del Software con temarios anticuados, no llegamos mucho más allá de los modelos clásicos de desarrollo y, por supuesto, nunca oímos hablar de metodologías ágiles.

En el desarrollo de software hay, a mi juicio, dos parámetros relacionados entre sí y que son de vital importancia: El tamaño del proyecto y lo exhaustivo del proceso de ingeniería a desarrollar. La relación entre ambos debe ser una constante, y el valor óptimo de la misma depende de una multitud de factores, tales como el equipo de ingenieros que trabajen en el proyecto, la ventana temporal para el mismo, etc. En cualquier caso siempre se puede establecer un rango para esta relación: No tendría por ejemplo sentido realizar un intenso proceso de ingeniería para construir un "Hello World", del mismo modo que para afrontar la informatización de una entidad bancaria sin que el proyecto se hunda, sería necesario aplicar la Ingeniería del Software de forma estricta.

Se deduce de lo anterior que hay un punto en el tamaño del proyecto en que la Ingeniería del Software parece no ser útil o, al menos, supone un coste mayor que el beneficio que aporta. Sin embargo incluso en pequeños proyectos en los que la aplicación de un proceso de Ingeniería parece tener más costes que beneficios, son necesarios como mínimo una serie de aspectos de la misma, como por ejemplo los relacionados con el trato con el cliente.

En este punto es en el que me he encontrado en varias ocasiones sin saber muy bien como atajar el problema. Finalmente he alcanzado una solución de un modo más o menos intuitivo, es decir, trabajando con el cliente y aprendiendo en cierto modo por prueba y error. Con el tiempo, y sin saber si estas técnicas han sido descritas o usadas anteriormente por otra persona, he optado por llamarlo "desarrollo orientado a interfaces". Este texto no pretende ser una descripción detallada de un modelo de desarrollo, ya que en ningún momento he trabajado para crear dicho modelo. Simplemente pretendo enunciar una idea y dar unas ligeras pinceladas para explicar esta metodología de trabajo.

El desarrollo orientado a interfaces (DOI) no es en realidad más que un conjunto de reglas básicas, un proceso de ingeniería abreviado, con un bajo coste y con una clara intención de extraer el máximo partido de cada fase del proceso. La idea es bien sencilla: empezar la casa por el tejado. En efecto puede parecer un absurdo este modo de proceder, pero si lo miramos desde el punto de vista del software, no se trata más que de desarrollar software empezando por la interfaz de usuario.

El primer paso es, naturalmente, la entrevista con el cliente. Una vez tenemos idea de los requerimientos funcionales del software a desarrollar, podemos comenzar a trabajar sobre la interfaz. En un primer momento no será necesario más que un esbozo en papel de las interfaces de usuario de nuestra aplicación. Este esbozo debe desarrollarse de cara al cliente, esto es, de modo que él lo entienda. En este sentido el resultado se asemejaría bastante a un manual de instrucciones del programa en el que las capturas de pantalla son sustituidas por dibujos. Del tamaño del proyecto y de la relevancia de este primer documento depende el nivel de detalle que se quiera reflejar en el mismo. Así, si el proyecto es pequeño, no se compite con otras empresas o ingenieros para adjudicarse el trabajo, y no es necesario recurrir a este documento como contrato, podemos simplemente dibujar las interfaces explicando al cliente como trabajaría la aplicación y realizando sobre la marcha las modificaciones oportunas.

Con este primer paso logramos una multitud de objetivos, y según lo importante de los mismos dedicaremos más o menos esfuerzo a esta primera fase, en particular en lo que a la elaboración de un documento se refiere. En concreto lograremos, si lo necesitamos, los siguientes objetivos:

• Obtener una lista de requerimientos funcionales, cada uno de ellos especificados detalladamente.
  
• Obtener un documento que puede servir como contrato con el cliente.
• Minimizar el riesgo de una mala interpretación de algún requerimiento funcional, ya que la comunicación con el cliente es más clara y concreta mediante ejemplos gráficos.
• Adelantar trabajo en el diseño de la interfaz de usuario.
  
• Adelantar trabajo sobre el manual de usuario de nuestra aplicación.

Una vez se han esbozado las interfaces, y nuevamente dependiendo del tamaño del proyecto y de sus características concretas, podemos valorar la opción de desarrollar en primer lugar todas las interfaces de usuario (es decir, formularios e informes) sin dotarlas de funcionalidad y completándolas, a lo sumo, con datos ficticios y estáticos de ejemplo. En este caso podremos presentar al cliente en un tiempo excepcional un primer prototipo no funcional de la aplicación, que puede servirnos para detectar posibles errores en el análisis de requerimientos.

Podemos en cualquier caso prescindir de este primer prototipo y abordar directamente el desarrollo de la aplicación. Durante las siguientes fases podremos modelar los datos y sus relaciones. Para ello nos apoyaremos en el diseño de la interfaz con el que contamos, pues la mayoría de los datos deben aparecer en la propia interfaz a modo de campo de entrada o salida y, de no hacerlo, deben quedar reflejados de algún modo en la descripción del funcionamiento de la aplicación. A partir de aquí, y en general, el proceso de desarrollo continuaría de un modo más o menos tradicional, sin existir diferencias fundamentales que merezca la pena detallar, pero manteniendo siempre la idea de realizar solo aquello que aporte un verdadero beneficio e intentar cubrir con cada tarea el máximo número de objetivos posibles.

En conclusión la idea es simple: Aprovechar el diseño de las interfaces como mecanismo de comunicación con el cliente, obtención de requerimientos funcionales, elaboración de un contrato y obtención rápida de un prototipo.

Cabe ahora preguntarse ¿en que casos es conveniente aplicar esta idea?. Naturalmente hay una serie de factores que aumentan las ventajas de la aplicación del DOI:

• La aplicación descansa fundamentalmente sobre las interfaces de usuario y las bases de datos.
• Toda o la mayor parte de la actividad de la aplicación es disparada por el usuario al trabajar con la interfaz.
• El cliente tiene conocimientos de informática a nivel usuario.
• El cliente ha usado aplicaciones similares para las que necesita un reemplazo o una mejora.

En mi experiencia el DOI ha demostrado ser especialmente útil en las aplicaciones web. Esto está motivado probablemente por el hecho de que en este tipo de aplicaciones la ejecución de código en el servidor está normalmente condicionada al disparo de un evento por el usuario.

Metodologías ágiles en el desarrollo web

Cada vez están más de moda en ingeniería del software los procesos de desarrollo llamados "ágiles", como la programación extrema (XP) frente a otros modelos más pesados como RUP. Estos están cobrando especial importancia en el desarrollo Web ya que las aplicaciones suelen ser fácilmente divisibles en pequeñas partes sencillas.

Los puntos más interesantes de la XP son:

• Desarrollo iterativo e incremental
• Pruebas unitarias continuas, frecuentemente repetidas y automáticas
• Programación por parejas
• Frecuente interacción del equipo de programación con el cliente o usuario.
• Corrección de todos los errores antes de añadir nueva funcionalidad.
• Hacer entregas frecuentes.
• Refactorización del código
• Propiedad del código compartida: promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto.
• Simplicidad en el código

El problema está en que hasta hace relativamente poco tiempo, no se disponían de herramientas para aplicar estas metodologías al desarrollo web. Afortunadamente con la aparición de frameworks como Ruby on Rails (RoR) o django, que promueven la arquitectura MVC, estas metodologías se vuelven extremadamente útiles y fáciles de aplicar.

Ambos, RoR y django, disponen de herramientas que facilitan el desarrollo rápido de prototipos de forma que el cliente puede ver resultados pronto, sugerir modificaciones y participar en lo que en XP se conoce como "El juego de la planificación", un proceso en el cual se ponen sobre la mesa el conjunto de tareas (o historias en terminología XP) y el cliente y los desarrolladores se ponen de acuerdo para decidir cual interesa obtener primero de forma que aporten el máximo valor posible al negocio.

Web 2.0, ¿futuro o pasado?

Mucho se habla últimamente de la Web 2.0, aunque nadie la define, cuando vemos una aplicación web, sabemos si es o no Web 2.0

Ahora se estan haciendo aplicaciones Web que en muchas ocasiones son capaces de reemplazar a las aplicaciones tradicionales de escritorio, por ejemplo gmail es un cliente de correo que nada tiene que envidiar a Outlook.

También se suben al carro muchas empresas, para reemplazar sus antiguas aplicaciones de escritorio y su engorrosa instalación en cada máquina en la que hay que acceder a la aplicación, por aplicaciones Web 2.0 que permiten acceso a la aplicación desde cualquier navegador y desde cualquier sitio. Las empresas ya no quieren aplicaciones de escritorio, han visto las posibilidades de la Web 2.0 y no lo dudan.

Pero mi pregunta es si esto de la Web 2.0 es futuro o pasado, y ¿por qué digo esto? cuando uno quiere empezar a experimentar con Web 2.0 piensa que va a aprender una tecnología diferente que permite hacer estas aplicaciones tan útiles y versátiles, pero tras empezar te empiezas a dar cuenta que lo que haces es lo mismo de siempre, lo único que cambias es la arquitectura de tus aplicaciones, pero no necesitas ni una sola tecnología nueva que no conocías antes de empezar. Entonces podemos pensar que porque ahora se utiliza tanto la Web 2.0 si eso ya podía usarse hace mucho tiempo. Aunque seguramente haya muchas respuestas, yo me decanto por el ancho de banda, lo cual es una contradicción, porque Web 2.0 consigue disminuir notablemente el ancho de banda en una aplicación Web, pero el problema es que con un ancho de banda pequeño no se pensaba en construir aplicaciones web, demasiada carga, nos conformabamos con una web pequeña y casi sin utilidad de interacción.

Lo mejor de la Web 2.0 es que no tenga ninguna tecnología nueva, porque eso permite que cada uno la haga como mejor le venga. Se podría conseguir Web 2.0 de decenas e incluso cientos de formas diferentes de mezclar la tecnología.

En siguientes post daré una pincelada al tema de XML y XSL, ¿por qué esto y no otra cosa?, El xml se ha convertido en el lenguaje de intercambio de información entre sistemas automáticos y empresariales, gracias a esto tenemos motores de generación e interpretación de xml muy potentes, así que parece un buen método de comunicacion para nuestras aplicaciones Web 2.0, ya que supone un menor cambio en las arquitecturas que tienen montadas las empresas. Y si vamos a utilizar XML, parece una buena opción, utilizar XSL para renderizar el XML y hacer que la información sea cómoda al usuario.

Jose Carlos Calvo Tudela

En el aire

intelliGenia ha surgido dentro de la ETSIIT de Granada para dar cabida a las inquietudes y aspiraciones de un grupo de ingenieros informáticos (algunos aún en proyecto de serlo) experimentados en programación web y diseño de arquitecturas en interfaces web avanzadas, así como en las nuevas tecnologías de programación.

Al mismo tiempo desde intelliGenia pretendemos cubrir un amplio hueco en el mercado de las nuevas tecnologías en Andalucía Oriental y de este modo evitar la fuga de capital y recursos humanos con amplio potencial a otras áreas geográficas más desarrolladas.

Este blog nace con la intención de convertirse en un punto de contacto entre los miembros de intelliGenia y la comunidad. Por ello tenemos intención de presentar aquí todas las novedades que desarrollemos, las ideas que surjan en nuestro trabajo y en general aquél conocimiento que consideremos de utilidad para una comunidad, una sociedad en auge, con la que nos sentimos en deuda.

Bienvenidos a intelliGenia.