Introducción

El estudio de microorganismos representa una actividad que deben desarrollar los médicos y tecnólogos de la salud. En el proceso de formación se transita por la asignatura de Microbiología y Parasitología médica durante la cual se identifican diferentes microorganismos ¹. Materializar las actividades prácticas constituye una acción que representa riesgos biológicos para los estudiantes en formación. Para evitar el riesgo, en las prácticas programadas se estudian microorganismos que no representan peligros para las personas, lo que imposibilita la interacción con diferentes fuentes de infecciones que también son de interés ².

Una solución a este tipo de problema puede ser abordada actualmente desde diferentes perspectivas. Los Sistemas de Laboratorios Remoto (SLR) constituyen una alternativa a la problemática descrita en la que es posible el estudio de diferentes microorganismos de forma remota ^{_{3), (4), (5)}} , disminuyendo así el riesgo biológico.

Un SLR representa un lugar o entorno cuya función es realizar un control sobre un sistema físico a distancia, con el objetivo de tele operar un sistema real, realizar experimentos y acceder a los datos a través de la red ^{_{6), (7)}} . Los experimentos en los SLR son eficientes producto de que se encuentran disponibles sin limitaciones temporales y disminuyen el consumo de materiales ya que no precisan de equipamiento técnico en cada una de las infraestructuras docentes ^{_{8), (9)}} . Una estación de trabajo disponible en el SLR puede ser utilizada centralmente mediante Internet o intranet institucional. Los SLR representan una tecnología ideal para su aplicación en las Ciencias Médicas ¹⁰ .

A partir de la problemática anteriormente descrita se define como objetivo de la presente investigación: desarrollar un Sistema de Laboratorios Remoto para la práctica de Microbiología y Parasitología Médica.

Método

La presente sección describe el diseño del Sistema de Laboratorios propuesto. La solución se encuentra dividida en dos aplicaciones, una aplicación de escritorio que conformará la estación de trabajo y una aplicación Web para el SLR. La aplicación de escritorio estará en la estación de trabajo que posee el microscopio electrónico y contará entre sus funcionalidades con la transmisión de un flujo de video. La aplicación Web se encargará de visualizar el flujo de video transmitido a partir de la tele operación. A continuación se describe detalladamente cada una de ellas:

1. Aplicación de escritorio (estación de trabajo): La aplicación de escritorio se encuentra desplegada en la estación de trabajo. Es la encargada de listar los dispositivos de tipo cámara que se encuentren conectados y permitir la visualización de uno de ellos. El dispositivo seleccionado debe encontrarse acoplado a un microscopio, lo que permite la observación de la muestra que se encuentre colocada en este. Otra de sus funcionalidades es la transmisión por la red del flujo de video que se encuentra emitiendo el dispositivo seleccionado. Además permite la grabación y captura de fotografías de las muestras colocadas en el microscopio seleccionado.
2. Aplicación Web (SLR): La aplicación Web permite integrar una estación de trabajo al SLR. Esta se encarga de visualizar los flujos de video que se encuentran siendo transmitidos por la aplicación de escritorio desde las estaciones de trabajo. Además de permitir capturar y guardar fotografías del flujo de video que se encuentra visualizando.

La solución propuesta, permite a los educandos de universidades y otros centros educativos del país potenciar la adquisición de conocimientos en la rama de la microbiología, al poder observar el progreso de muestras reales en tiempo real, además de realizar capturas de fotos de la mismas, todo esto haciendo únicamente uso de un navegador Web.

Los principales conceptos que conforman el entorno que se modela son representados en un modelo conceptual ¹¹. La figura 1 muestra un esquema que ilustra la interacción de las diferentes entidades del negocio.

Para un mejor entendimiento del modelo conceptual se realiza una descripción de las clases existentes:

Especialista: Especialista que maneja la estación de trabajo y las muestras.

Estación de trabajo: Computadora con acceso a la red a la que se encuentra conectada la cámara que esta acoplada al microscopio.

Cámara: Dispositivo que se encarga de la emisión de un flujo de video.

Muestra: Pequeña porción de microorganismos o de tejido celular que se visualizará con el microscopio.

El proceso de observación de la muestra se inicia cuando el especialista coloca la muestra en el microscopio. La cámara se encuentra acoplada al microscopio electrónico y se encarga de visualizar la muestra colocada en este. El especialista manipula la cámara a través de la estación de trabajo, mediante la cual puede visualizar la muestra que esté colocada en el microscopio.

Como parte de las restricciones de servicios o funciones ofrecidas por el sistema, se definen los requisitos no funcionales ¹². Los requisitos no funcionales se enfocan fundamentalmente en las características del sistema y las condiciones que se deben cumplir para su correcto funcionamiento ^{_{13), (14)}} . Para la presente investigación se definen requisitos de usabilidad, software, hardware, interfaz y diseño ^{_{15), (16), (17)}} .

Se definen como requisitos de usabilidad:

1. El sistema en su totalidad está diseñado para que el usuario realice las operaciones en la menor cantidad de eventos posibles.
2. La solución posee un diseño sencillo que permite potenciar la facilidad de aprendizaje, tanto para aprender sus funcionalidades básicas, como para realizar correctamente la tarea que desea ejecutar y poder aplicarla en el futuro.

Se definen como requisitos de software para el funcionamiento del sistema:

1. PC Cliente de la aplicación de escritorio: Sistema Operativo Linux. Biblioteca LibVLC en su versión 2.2.0.
2. Servidor de aplicaciones: Sistema Operativo Ubuntu 12.04, debe contar con el servidor Web Apache Tomcat 7.0.1 con la aplicación Liferay Portal 6.0.5, JDK6, PostgreSQL 9.4, Flumotion Streaming Server en su versión 0.10.
3. PC Cliente Web: Las estaciones clientes para acceder al sistema deben utilizar como navegador Mozilla Firefox versión 36.0, Google Chrome 40.0, Opera 20.0, Safari 5.1 o cualquiera de la versiones superiores.

Para el correcto funcionamiento de sistema se definen los requisitos de hardware:

1. PC Cliente de la aplicación de escritorio: 1 Gb de RAM o superior, procesador Dual Core a 2.20 GHz o superior. Tarjeta de red con una velocidad de 100 Mbps o superior.
2. Servidor de aplicaciones: 2Gb de memoria RAM, procesador Dual Core a 2.20 GHz o superior. Tarjeta de red con una velocidad de 100 Mbps o superior.
3. PC Cliente Web: 256 Mb de RAM o superior, procesador Pentium IV o superior. Tarjeta de red con una velocidad de 100 Mbps o superior.

Se definen como requisitos de interfaz:

1. El sistema está diseñado para que se visualicen las alarmas con el color llamativo rojo.
2. Cuando se ordene una acción en cualquiera de los componentes del sistema debe mostrarse un icono que indique la acción que se encuentra ejecutándose: grabando o transmitiendo o ambas. En el caso de encontrarse transmitiendo, se muestran otros detalles significativos tales como el puerto y la URL.

Se definen como requisitos de diseño:

1. Lenguaje de programación: Se emplea en el desarrollo de la aplicación de escritorio el lenguaje C++, haciendo uso del framework QT Creator en su versión 3.0, mientras que para el lado del cliente Web se utilizará el lenguaje Java Server Page (JSP), haciendo uso del framework Spring.
2. Bibliotecas: Para el correcto funcionamiento de la aplicación de escritorio se utiliza la biblioteca LibVLC en su versión 2.2.0.

Para transformar los conceptos descritos, se realiza una agrupación de los Requisitos Funcionales. Los requisitos funcionales son declaraciones de servicios que el sistema debe proporcionar, define la manera en que éste debe reaccionar a determinadas entradas y cómo se debe comportar en situaciones particulares ¹². Cada requisito representa características que debe cumplir el SLR propuesto y expresan la capacidad de acción del mismo.

Para definir las funcionalidades que pueden ejecutar los usuarios, se definen los actores del sistema. Para el Sistema de Laboratorios propuesto se determina su nivel de interacción con cada caso de uso. La tabla 1 realiza una descripción de los actores del sistema y sus descripciones.

Un Diagrama de Casos de Uso de Sistema (DCUS) muestra la relación entre los actores y los casos de uso del sistema, de esta forma se representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa ¹⁸. La figura 1 muestra el DCUS.

A continuación se relacionan los Requisitos Funcionales y los Casos de Uso del Sistema teniendo en cuenta la aplicación en la cual se encuentran.

Agrupación de Casos de Usos del Sistema de la aplicación de escritorio (estación de trabajo)

Caso de Uso 1. Mostrar la muestra:

1. Requisito Funcional 1: Listar cámaras disponibles para su uso.
2. Requisito Funcional 2: Seleccionar una cámara de la lista de disponibles
3. Requisito Funcional 3: Visualizar la muestra con la cámara seleccionada.

Caso de Uso 2. Realizar capturas de la evolución de la muestra:

1. Requisito Funcional 4: Capturar fotografía de la muestra con la cámara seleccionada.
2. Requisito Funcional 5: Guardar la fotografía capturada.
3. Requisito Funcional 6: Iniciar grabación de la evolución de la muestra con la cámara seleccionada.
4. Requisito Funcional 7: Detener grabación de la cámara.
5. Requisito Funcional 8: Guardar video grabado de la evolución de la muestra.

Caso de Uso 3. Administrar la transmisión del flujo de video:

1. Requisito Funcional 9: Configurar los parámetros del video para la transmisión.
2. Requisito Funcional 10: Iniciar la transmisión del flujo de video emitido por la cámara seleccionada.
3. Requisito Funcional 11: Detener la transmisión del flujo de video.

Caso de Uso 4. Configurar opciones de guardado de las capturas:

1. Requisito Funcional 12: Configurar las opciones de guardado de las capturas.
2. Definición de Casos de Usos del Sistema de la aplicación Web (SLR)

Caso de Uso 5. Mostrar flujo de video transmitido:

1. Requisito Funcional 13: Listar las estaciones transmisoras disponibles.
2. Requisito Funcional 14: Seleccionar una estación transmisora de la lista de disponibles.
3. Requisito Funcional 15: Visualizar flujo de video de la estación transmisora seleccionada.

Caso de Uso 6. Capturar fotograma del flujo de video:

1. Requisito Funcional 16: Capturar fotograma del flujo de video de la estación seleccionada.
2. Requisito Funcional 17: Guardar fotograma tomado del flujo de video de la estación seleccionada.

Caso de Uso 7. Gestionar estaciones transmisoras del flujo de video:

1. Requisito Funcional 18: Insertar una estación transmisora de un flujo de video.
2. Requisito Funcional 19: Actualizar los datos de una estación transmisora de un flujo de video.
3. Requisito Funcional 20: Eliminar una estación transmisora de un flujo de video.

Resultados

Los diagramas de clases del diseño permiten modelar la vista de diseño estática de un sistema, estos describen gráficamente las especificaciones de las clases además de visualizar las relaciones entre estas. A continuación se muestran los diagramas de clases del diseño para los CU: “Administrar la transmisión del flujo de video” y “Mostrar flujo de video transmitido”.

Caso de Uso “Administrar la transmisión del flujo de video”

En el diagrama de clases del diseño referente al CU “Administrar la transmisión del flujo de video” (Fig. 3), se identifican dos paquetes: Presentación y Negocio, los que corresponden al patrón de diseño N-Capas, en su versión dos capas.

La clase CI_Principal es la clase a través de la cual el rol especialista puede acceder a todas las funcionalidades. Posee un objeto de tipo CC_Principal que es la clase controladora. La clase CC_Principal es la encargada de recibir las peticiones que le son enviados desde la clase interfaz, esta redirecciona a la clase controladora relacionada con la petición realizada, en este caso la clase CC_Transmisión, la cual realiza la transmisión del video a través del protocolo RTSP, haciendo uso de un objeto de tipo VlcElemento.

Caso de Uso “Mostrar flujo de video transmitido”

En el diagrama de clases del diseño referente al CU “Mostrar flujo de video transmitido” (Fig. 4), se identifican tres paquetes: Vista, Controlador y Modelo, los que corresponden a las capas del patrón de diseño MVC.

El usuario accede a la interfaz principal, “CP_Principal”, a través de la clase “CP_Index”, esta genera una solicitud que es enviada a la clase “SP_ControladoFrontal”, la cual la redirecciona a la clase “SP_Principal” que es la encargada de la lógica del negocio relacionada con la “CP_Principal”. La clase “CI_Principal” se construye con una lista de las estaciones que se encuentren disponibles, además contiene todas las funcionalidades necesarias para la visualización de los flujos de video.

En el diagrama de clases del diseño del CU “Mostrar flujo de video transmitido” se encuentra el paquete “Acceso a datos” (Fig. 5), el cual define la clase “DAO”. Esta contiene todos los métodos necesarios para el acceso y gestión de las tablas de la base datos, utilizando para ello las clases “Acceso_Estación” y “Estación”. Esta clase implementa el patrón de diseño DAO, ya que se encarga de la gestión de los datos entre las clases que contienen la lógica del negocio y las entidades.

Un diagrama de componentes permite visualizar con más facilidad la estructura general del sistema y el comportamiento del servicio que estos componentes proporcionan y utilizan a través de las interfaces. Representa como cada subsistema es dividido en componentes y muestra las dependencias entre ellos. A continuación se muestra el diagrama de componentes para los CU: “Administrar la transmisión del flujo de video” (Fig. 6) y “Mostrar flujo de video transmitido” (Fig. 7).

La figura 8 muestra el diagrama de despliegue para el Sistema de Laboratorios Remoto propuesto. Representa el grafo de nodos unidos por conexiones de comunicación que muestra las relaciones físicas entre los componentes hardware y software ¹⁹.

A continuación se describe cada uno de los nodos que conforman el diagrama de despliegue:

1. Cámara: Dispositivo físico encargado de emitir flujos de video.
2. Estación de trabajo: Terminal con acceso a la red en la cual se encuentra desplegada la aplicación de escritorio desarrollada. Por otro lado la estación de trabajo debe contar con la librería LibVLC en su versión 2.2.0 instalada, la cual es utilizada por la aplicación de escritorio para la transmisión del flujo de video de la cámara haciendo uso del protocolo RTSP.
3. Servidor de aplicaciones: Terminal con acceso a la red donde se halla alojado el servidor Web Apache Tomcat en su versión 7.0.1, el cual cuenta con el contenedor de portlet Liferay Portal, versión 6.1,en este se encuentra desplegado el portlet para la microbiología. Además cuenta con un servidor de medias, el cual se encarga de todo lo relacionado con la recepción y posterior transmisión del flujo de video, disminuyendo la carga del servidor Web.
4. Servidor de bases de datos: Terminal con acceso a la red donde se encuentra el servidor de bases de datos PostgreSQL en su versión 9.4, al cual se accede a través del puerto 5432, haciendo uso del protocolo TCP/IP.
5. PC cliente del SLR: Terminal conectada a la red, mediante la cual el cliente accede al portlet de microbiología en el SLR a través de un navegador Web.

El dispositivo de tipo cámara que se encuentra conectado a la Estación de trabajo emite un flujo de video, el cual es decodificado y transmitido por la aplicación de escritorio desarrollada haciendo uso del protocolo RTSP. Este flujo de video es recibido en el servidor de aplicaciones por el servidor de medias y colocado bajo demanda. El cliente accede a través de una computadora al portlet alojado en el SLR, a través del protocolo HTTPS, el cual le permite visualizar los flujos de video que se encuentran disponibles y han sido previamente colocados en la bases de datos, a la cual se accede a través del protocolo TCP/IP.

Cada uno de los componentes definido fue implementado para obtener la solución propuesta. El proceso de desarrollo de los mismos fue guiado por los diagramas de clases y se respetaron las características de cada uno de los patrones arquitectónicos escogidos según el componente. A continuación se describe cada uno de estos componentes.

La Figura 9 muestra la descripción por áreas de las interfaces de usuario para la aplicación de Escritorio (Estación de trabajo).

1. 1. Panel de visualización: Área donde se muestra la visualización de la cámara.
2. 2. Opciones de configuración: Área que permite entrar a la interfaz de configuración.
3. 3. Opciones de transmisión: Permite al usuario acceder a las opciones correspondientes con la transmisión.
4. 4. Opciones de realizar capturas: Permite a los usuarios realizar fotografía o grabaciones con la cámara escogida.
5. 5. Lista de cámaras: Muestra la lista de cámaras disponibles para su utilización. El usuario puede escoger una de estas y visualizarla.
6. 6. Detalles y notificaciones: En esta área se muestran al usuario las notificaciones del sistema. Se muestra además información adicional sobre la transmisión (puerto y dirección IP por el que se transmite, URL utilizada), de encontrarse realizando una.

La Figura 10 muestra la descripción por áreas de las interfaces de usuario para la Aplicación Web.

1. Panel de visualización: Área donde se muestra el flujo de video que se encuentre transmitiendo la estación escogida.
2. Opciones para realizar captura: Permite al usuario realizar capturas el flujo de video que se encuentre visualizando.
3. Lista de estaciones: Muestra la lista de estaciones disponibles para su visualización.
4. Opciones de origen: Esta área solo podrá visualizarla un usuario con permisos de administración pues permite la gestión de la lista de estaciones accesibles.

Para el correcto funcionamiento del sistema propuesto se utilizan estándares de codificación. Los estándares de codificación comprenden todos los aspectos de la generación de código, este refleja un estilo armonioso estableciendo como operar con la base de código existente. Estos facilitan que el código generado en la fase de implementación se encuentre bien organizado, sea comprensible, sencillo y rápido de detectar errores. Se logra así una aplicación eficiente en términos de mantenimiento y extensión de acuerdo a las nuevas necesidades que surjan en el negocio.

En el desarrollo de la solución planteada se utilizan los siguientes estándares de codificación:

lowerCamelCase: Es una convención de nombres que forma parte de CamelCase en el que el nombre se forma de múltiples palabras que se unen como una sola donde la primera letra del nombre comienza con mayúscula. Específicamente en el caso de lowerCamelCase la primera letra del nombre comienza con minúscula. La figura 11 muestra un fragmento de código donde se muestra el estándar definido.

UpperCamelCase: Esta convención de nombres también forma parte de CamelCase, pero específica que la primera letra es con mayúscula, siendo fácil distinguirla de los nombres lowerCamelCase. Se utiliza mayormente para definir los nombres de las clases, a continuación se muestra un ejemplo. La figura 12 muestra un fragmento de código donde se implementa el estándar.

Sentencias de inclusión o importación: No existen líneas en blanco entre estas. A continuación se muestra un ejemplo en la clase “VlcElemento”. La figura 13 muestra un ejemplo del empleo del estándar.

Conclusiones

La caracterización y revisión del estado del arte actual de los Sistemas de Laboratorios Remoto y sus estaciones de trabajo permitió identificar la necesidad de implementar una solución que permita el desarrollo de prácticas de Microbiología y Parasitología Médica.

Con el desarrollo de la solución propuesta se introduce un Sistema de Laboratorios Remoto para la práctica de Microbiología y Parasitología Médica disponible para las instituciones educativas del país. Permite potenciar la adquisición de conocimientos por parte de los estudiantes al poder estos visualizar, desde cualquier terminal con acceso a la red, la evolución de las muestras en tiempo real.

A partir del proceso de diseño de la solución propuesta se obtuvieron los artefactos generados para el proceso de desarrollo que facilita continuar su implementación en el futuro y adecuarla a diferentes contextos.