Aplicaciones

	Aplicaciones

Introducción

Como se ha visto anteriormente podemos distinguir en un ordenador tres partes: hardware, sistema operativo y aplicaciones. El hardware, es la parte física del ordenador: el microprocesador, la memoria, el disco duro y resto de dispositivos y periféricos (ratón, impresora, teclado, etc.). El sistema operativo es el software encargado de comunicarse con el hardware, permitiendo que los dispositivos del ordenador estén disponibles para ser utilizados. Las aplicaciones son el software que va a dar una funcionalidad específica y que es lo que le interesa realmente al usuario. Permite hacer cosas útiles con el ordenador que serían más difíciles o pesadas de hacer a mano. Por ejemplo un procesador de textos, un programa de dibujo o una hoja de cálculos. También hay aplicaciones de ocio como los juegos, de aprendizaje como los cursos de idiomas y a veces permiten hacer cosas que sería imposible hacer a mano, como por ejemplo, alinear automáticamente miles de secuencias.

Un programa recibe y presenta información al usuario (a través de un interfaz de usuario) lee y guarda información en el disco duro (como archivos) y realiza acciones pedidas por el usuario a través del interfaz sobre los datos cargados. El interfaz de usuario puede ser de texto, como en los antiguos programas de MS-DOS o gráfico (GUI) como en el caso de la mayoría de los programas que actualmente se usan. Sin prejuicio de ello, el uso de la linea de comandos sigue siendo el método más potente de trabajar con un ordenador.

Modelo de Aplicación

Ejemplo: Programa que almacena información sobre los clones que posee un laboratorio: código del clon, secuencia, organismo, caja en la que está guardado, primers empleados para amplificar por PCR, etc. El usuario a través del interfaz administra los registros: añade clones, elimina alguno en caso necesario y modifica información de los existentes, acciones siempre a petición del usuario. La información se almacena en un fichero de base de datos de Access y el programa además puede presentar informes de que clones tenemos, ordenados siguiendo algún criterio determinado: por cajas, por organismo, etc.

En el ejemplo anteriormente expuesto, la misma aplicación se encarga de hacer todo, genera el interfaz para interaccionar con el usuario, gestiona los datos usados almacenándolos en un fichero y cargándolos al iniciar, realiza sobre los datos todas las acciones pedidas por el usuario, etc. Este es un modelo monolítico de aplicación que como veremos tiene muchos inconvenientes. Por ejemplo si la aplicación la he creado en Visual Basic, que es un lenguaje de programación de Microsoft, esta solo va a funcionar en SO Windows y con ordenadores PC (microprocesadores Intel y semejantes). Además, el guardar los datos en un fichero me impide que el programa lo tengan instalado distintos usuarios en distintos PC's debido a que si alguien modifica algo con su copia habría que actualizarlo en los demás ficheros. En algunos casos, este modelo es suficiente y no presentaría ningún problema estos aspectos. En un entorno de varios usuarios potenciales de la aplicación que además comparten los datos los datos y que pueden necesitar usarla desde ordenadores distintos, este modelo no es muy conveniente.

Modelo de tres capas.

Lo ideal para empezar es que cada usuario no tuviese una copia local del fichero de la base de datos. Lo suyo sería que dicho fichero estuviese centralizado en algún lado y todos los posibles usuarios pudiesen acceder a él, ya sea desde el ordenador en el que está o desde otro. Esto se soluciona empleando un sistema gestor de bases de datos como MySQL, PostgreSQL y Oracle. Ese ordenador se convierte en un servidor de la base de datos y nuestra aplicación en un cliente de esta. La aplicación le pide los datos al servidor y este se los da. Entonces la aplicación ya puede hacer con los datos lo que el usuario quiera. Si hay alguna modificación de estos la aplicación le envía la información al servidor y este se encarga de actualizar, eliminar o añadir. Hemos separado de esta manera la gestión de los datos del resto de la aplicación.

Si nuestra aplicación tiene que hacer cosas más complicadas que añadir, modificar y eliminar registros de una base de datos puede ser que no nos valga cualquier ordenador de los que los usuarios van a usar. Por otro lado puede ser que los usuarios accedan desde ordenadores muy distintos con SO muy distintos. Otro paso que podemos realizar ahora es separar la parte operacional del programa del interfaz de usuario. La primera parte podría estar en un ordenador potente mientras que el interfaz puede estar en cualquier ordenador más limitado, idealmente, se debería poder emplear el interfaz desde cualquier ordenador con cualquier SO. Esto se puede hacer por ejemplo poniendo el programa con la parte operacional en un ordenador que además esté ejecutando un servidor web. Entonces los usuarios pueden acceder al programa mediante un navegador web y un sistema llamado CGI. Otra forma sería diseñar el propio programa como un servidor y que la parte del interfaz de usuario fuese un cliente de este servidor. Nosotros preferimos el primer sistema en el que el interfaz de usuario es cliente de un servidor web y este se comunica con el programa a través de los CGI.

Hemos pasado de esta manera de un modelo monolítico de aplicación a un Modelo de Tres Capas o niveles, el nivel de datos, el nivel de aplicación (u operacional) y el nivel de presentación(o interfaz de usuario). Este modelo permite aumentar el rendimiento y hacer la aplicación accesible para un numero casi ilimitado de plataformas de ordenadores, independientemente del microprocesador que usen o el SO que tengan instalado.

NIVEL DE APLICACIÓN

NIVEL DE PRESENTACIÓN

Arquitectura Cliente/Servidor.

Para que el modelo de tres capas sea útil tiene que basarse en una arquitectura cliente/servidor. Esto permite la comunicación entre los distintos niveles comportándose cada uno de ellos como cliente y/o servidor. Un servidor es un programa que sirve cosas, ya sean datos, utilidades, etc. Un cliente es el programa que pide los datos a ese servidor. El servidor solo esta a la espera de que algún cliente le pida algo y cuando le llega una petición, la realiza.

Ejemplo 1: Navegar por Internet y ver páginas web.
Ejemplo 2: Recibir un e-mail en nuestro programa de correo.

Siguiendo con el ejemplo de la base de datos de clones, podemos almacenar en una base de datos la información de los clones. La base de datos estará funcionando en un ordenador que será el servidor de base de datos. En el mismo ordenador u en otro está corriendo un servidor web, y en nuestro ordenador solo tendremos que abrir un navegador. En el navegador escribimos la dirección web de la pagina de la aplicación y la pagina, mediante CGI ejecuta la aplicación en función de las opciones elegidas por nosotros en la pagina web. Al ejecutarse la aplicación esta leerá datos de la base de datos, los modificará, los eliminara o añadirá otros nuevos si se lo pedimos.

Software de Base.

Con estos conceptos, se llega a la definición de un tipo de aplicaciones que en realidad se encuentran entre el SO y las aplicaciones de los usuarios. Es el llamado software de base o middleware y que proporcionan una funcionalidad específica pero que el usuario normalmente no interacciona demasiado con ellos. Serían por ejemplo los sistemas gestores de bases de datos o servidor de bases de datos (MySQL), el servidor web (Apache), el servidor de correo (Sendmail), el servidor de archivos (Samba), etc. Como vemos, algunos de ellos están implicados en el nivel de datos de nuestra aplicación según el modelo de tres capas mientras que otros están implicados en el nivel se presentación. Nuestra aplicación los emplea pero el usuario no tiene porque saber nada de ellos.

¿Qué es un programa?

Por un lado tenemos el software de base y Por otro están el resto de las aplicaciones, como el Word, el Excel, el OpenOffice, etc. Estas son las que van a interaccionar directamente con el usuario, el usuario las emplea conscientemente para realizar una tarea que no puede realizar sin la aplicación o que le resulta mucho más efectiva realizarla con ella. Estás son las aplicaciones que pueden ser interesantes desarrollar desde el punto de vista de la biología y son en las que se trabaja en bioinformática. Son aplicaciones con un grado más o menos alto de interacción con el usuario y que le permiten manejar los datos de origen biológico, obtener más información de ellos, presentarlos de una manera que mejore su comprensión, almacenar las grandes cantidades de información, etc.

Pero antes de entrar en lo que podemos hacer con la programación como biólogos: ¿Qué es un programa? Un programa no es más que un conjunto de números binarios que son instrucciones para el ordenador. Como se explico anteriormente estás instrucciones en realidad son abstracciones que implican un flujo de corriente eléctrica, pero eso ya no nos importa demasiado. Los valores de los 1 y 0 guardados en forma de un archivo en el disco duro, se almacenan temporalmente el la memoria RAM, donde son pasados después secuencialmente al microprocesador. Este va ejecutando las instrucciones una a una, de tal manera que en realidad, un microprocesador nunca puede hacer dos cosas al mismo tiempo.

Lenguajes de programación

Los microprocesadores solo entienden código binario por lo que este se denomina también lenguaje máquina. Sin embargo como os podeis imaginar este no resulta demasiado amigable para nosotros. Programar en lenguaje máquina es tedioso y requiere muchos conocimientos de la máquina y SO para el que estás programando. Sería mucho mejor si le pudiésemos decir al ordenador:

"Ordenador: Sumame 4 y 7 y saca el resultado por pantalla".

Esto es para lo que se crearon los lenguajes de programación. Un lenguaje de programación no es más que una forma de expresar lo que queremos decirle al ordenador que haga de manera que sea más facil de entender por los humanos. Esta formado por un léxico (palabras a usar) y una gramática (forma de usar las palabras) que usadas correctamente nos permiten decirle al ordenador como queremos que se comporte. Por ejemplo, en perl para darle la orden de antes escribiríamos:

print 4+5;

Los lenguajes de programación se pueden clasificar en función de cuanto se parezcan al lenguaje humano y cuanto al lenguaje máquina. De esta manera un lenguaje de bajo nivel es el que se parece más al lenguaje máquina, como el lenguaje ensamblador. Por otro lado, un lenguaje de alto nivel se parece más al lenguaje humano, como el Perl, el BASIC, etc. Hay lenguajes intermedios que son algo menos fáciles de usar pero que a cambio dan más rendimiento, como es el caso del lenguaje C, C++, etc. Nosotros vamos e emplear un lenguaje de alto nivel como es el Perl, que por sus características particulares ha encontrado una gran campo aplicación en bioinformática puesto que es un lenguaje idóneo para el análisis de textos y que son los genes y proteínas sino secuencias de caracteres o letras.

Compiladores e Interpretes.

Nosotros escribimos nuestro programa en el lenguaje de programación que más se adecue a nuestras necesidades o con el que más cómodo nos encontremos, pero ese fichero, con las instrucciones que le hemos escrito, el microprocesador no puede entenderlo. Es necesario por lo tanto alguien que le traduzca al microprocesador lo que pone en nuestro fichero con el programa. Este es el trabajo de los compiladores y los intérpretes.

Un compilador lee el fichero en el que está escrito el programa y traduce la información del lenguaje de programación para el que está diseñado (un compilador de C compila lenguaje C). Tras esto genera un fichero binario que es lo que podemos después ejecutar. Una vez obtenido ese fichero no es necesario que ejecutemos de nuevo el compilador. Si queremos ejecutar el código solo habrá que ejecutar el fichero generado, sin tener por lo tanto que traducir de nuevo.

Un interprete lee el fichero en el que está escrito el programa y traduce la información del lenguaje de programación para el que está diseñado. Sin embargo después no genera un fichero que podamos ejecutar, sino que directamente ejecuta el código binario obtenido tras la traducción. Si queremos ejecutar de nuevo ese código, tendremos que llamar de nuevo al interprete y este tendrá que traducir de nuevo el código.

Código Fuente.

Cuando escribimos un programa lo guardamos normalmente en un fichero. El fichero contiene texto plano y nada más, palabras con las instrucciones que queremos realice el ordenador. Este fichero es lo que le pasamos al compilador o al intérprete y va a dar origen al fichero binario por lo que se le llama fichero fuente y al código que contiene código fuente. Una vez pasado por el compilador este genera un fichero binario que contiene código binario. Este archivo es el que podemos ejecutar y que va a entender a la perfección el microprocesador... siempre que lo que hayamos escrito en el fichero fuente sea correcto claro. En el caso de los interpretes tras la traducción se ejecuta directamente el código binario por lo que no se genera un fichero binario. El lenguaje Perl es un lenguaje interpretado que es como se usa normalmente, sin embargo también hay un compilador por lo que se podrían generar ficheros binarios.

Funciones y Subrutinas

A medida que escribimos programas más largos nos damos cuenta de que hay muchas instrucciones que se parecen mucho. En realidad hay mucha parte del código fuente que se va a ir repitiendo por lo que es mucho más eficiente agrupar todas aquellas instrucciones que se ejecutan en bloque en subrutinas y funciones. Una subrutina no es más que un conjunto de instrucciones que se ejecutan cada vez que se usa el nombre de la subrutina. Una función es muy parecida pero además permite que se le pasen parámetros. El agrupar las instrucciones con subrutinas y funciones permite obtener programas más limpios y más fáciles de mantener en el futuro.

Librerías y Módulos.

A medida que hacemos programas nos daremos cuenta también de que hay una serie de funciones y subrutinas que empleamos frecuentemente en muchos programas. Los mejor sería que en lugar de tener que escribir las funciones cada vez que queramos emplearlas en un programa, las tuviésemos escritas en un fichero y desde nuestro programa pudiésemos llamar a la función. Así ahorraríamos mucho trabajo y además permitiría que otros usasen fácilmente esas funciones si queremos permitir que lo hagan. Esto es lo que permiten hacer las librerías y los módulos.

Cuando un programa emplea funciones de una librería dinámica, la librería es cargada dinamicamente cuando se ejecuta el programa, de manera que el código binario de la librería se une al de nuestro programa. Si la librería es estática el código de la librería de une al del programa al ser compilado. Nuestro programa llevará con él siempre el código de la librería.

Bioperl.

Dentro de las cosas que podemos encontrar ya hechas y que están relacionadas íntimamente con nuestro interés bioinformático es el proyecto bioperl. Bioperl es parte de un proyecto común para llevar herramientas informáticas al terreno de la biología entre los que se encuentran también biojava, biopython... Lo de "ya hechas" es simplemente una forma de hablar ya que son proyectos en continuo y activo desarrollo por lo que suelen salir nuevas versiones cada poco tiempo.

Lo que el proyecto bioperl ofrece es un marco de desarrollo, es decir una serie de módulos que permiten, por ejemplo, bajar secuencias, manipularlas, enviarlas a servidores para que se realicen tareas como alineamientos, etc.

EMBOSS.

Otra de las aplicaciones que ya lleva mucho camino recorrido es el proyecto EMBOSS del EMBL, que en realidad no es una aplicación sino un conjunto de aplicaciones orientadas a la biología molecular. Se encuentran herramientas de análisis de secuencias, de análisis filogenético, para diseñar primers, dibujar plásmidos, buscar sitios de restricción, etc. Y además cuenta con un kit de desarrollo por lo que se pueden emplear las librerías desarrolladas por ellos para construir a partir de ellas nuestro código. También está en desarrollo una librería de perl para acceder a las funciones de las librerías de C de EMBOSS.

Bioconductor.

El proyecto bioconductor está orientado al desarrollo de herramientas para el análisis de datos en biología. En principio está más dirigido a la tecnología de microarrays de cDNA y de oligonuclótidos (Affymetrix) sin embargo también hay algo para otrás tecnologías como SAGE. El proyecto se apoya en la plataforma de análisis estadístico R (r-project) que es además un lenguaje de programación y por lo tanto muy flexible e idoneo para el desarrollo de nuevos métodos estadísticos.

Open Source.

El rápido desarrollo de muchas de estas herramientas ha sido posible no solo a que mucha gente se haya puesto a trabajar en ello recientemente sino a que los proyectos iniciados por instituciones más o grandes como EMBL se han basado en un modelo de código abierto lo cual significa que el código fuente de los programas que ellos distribuyen está accesible para cualquiera que quiera verlo (y sepa claro). De está manera se puede aprender como se ha hecho una cosa e implementarlo en nuestra aplicación o incluso mejorarlo si tenemos el tiempo y la formación adecuada. Tanto bioperl, EMBOSS, bioconductor y R son herramientas muy sofisticadas de código libre por lo que se puede aprender mucho mirando en sus entrañas.

Servicio de BioInformatica
Ultima modificación: 29 de Octubre de 2003

© CSIC.