Repositorio Institucional de Documentos

AUTORA: LAURA LACARRA ARCOS DIRECTOR: ROBERTO CASAS MILLÁN PONENTE: JESÚS ALASTRUEY BENEDÉ Departamento Informática e Ingeniería de Sistemas Zaragoza, Julio 2010 UNIVERSIDAD DE ZARAGOZA Centro Politécnico Superior Ingeniería Informática Proyecto Fin de Carrera DESARROLLO DE UNA APLICACIÓN PARA LOS OPERADORES DE TELEASISTENCIA INTEGRADA EN TELEFONÍA IP A mi familia, amigos y compañeros de trabajo RESUMEN La teleasistencia domiciliaria es un servicio de ayuda a personas mayores y/o discapacitadas. Las personas o clientes que contratan el servicio disponen de una instalación específica compuesta por un terminal (similar a un teléfono con un botón de emergencia) y varios dispositivos (sensores) que permiten ponerse en contacto con un centro de asistencia, por voluntad de la persona o activación propia de los dispositivos. El centro de asistencia está formado por operadores, cuya misión es atender las alarmas que generen las personas y proporcionar una ayuda eficaz y personalizada ya sea movilizando familiares, conocidos u organismos de la comunidad. Actualmente cada centro de teleasistencia está configurado a través de la red de teléfono convencional. Las llamadas llegan a una centralita de teleasistencia cuya funcionalidad es transformar los datos en digitales, gestionar los teléfonos de los operadores y traducir los protocolos de los equipos que están instalados en cada hogar. Una instalación con estas características es poco escalable y costosa. El proyecto consiste en el desarrollo de un sistema para una empresa de teleasistencia en el cual los operadores puedan gestionar las alarmas recibidas en el centro y la información de las personas que contratan el servicio. El sistema estará integrado en una plataforma IP en el cual la gestión telefónica pasará de ser analógica a ser por VozIP y la gestión de los distintos protocolos, pasará de ser por hardware a software. Los objetivos que se persiguen son dos: facilitar la tarea de los operadores en la atención de alarmas y ahorrar grandes costes a las empresas reduciendo el gasto de la infraestructura inicial y de la instalación de equipamiento de la empresa. Gracias a la VozIP, es posible una centralita de teleasistencia configurada en base a las necesidades de los clientes y operadores, de forma que sea susceptible a cambios de crecimiento sin ocasionar los costes que supondría un aumento de hardware, y ante todo, la asistencia será rápida y exitosa en beneficio de las personas. -9- TABLA DE CONTENIDOS 1. INTRODUCCIÓN .............................................................................................................. 13 1.1 Introducción ................................................................................................................ 13 1.2 Contexto ...................................................................................................................... 13 1.3 Motivación .................................................................................................................. 13 1.4 Definición y alcance del sistema ................................................................................. 14 1.5 Definición y alcance de la integración ........................................................................ 14 1.6 Fases del trabajo .......................................................................................................... 15 1.7 Herramientas utilizadas ............................................................................................... 15 1.8 Contenido de la documentación .................................................................................. 16 2. PLANIFICACION DEL SISTEMA ................................................................................... 17 2.1 Metodología ................................................................................................................ 17 2.2 Planificación ................................................................................................................ 17 3. ESTUDIO DEL ENTORNO ............................................................................................... 19 3.1 Contexto de Teleasistencia .......................................................................................... 19 3.2 Investigación de la arquitectura actual ........................................................................ 20 3.3 Contexto de la voz IP .................................................................................................. 21 3.4 ¿Por qué voz IP? .......................................................................................................... 21 3.5 Arquitectura IP de AsisT ............................................................................................. 22 4. ANÁLISIS DE LA INFORMACIÓN ................................................................................ 24 4.1 Actividades realizadas en el análisis ........................................................................... 24 4.2 Resumen de los requisitos de AsisT ............................................................................ 24 4.3 Definición de actores y roles ....................................................................................... 25 4.4 Los subsistemas ........................................................................................................... 25 5. DISEÑO DE LA INFORMACIÓN .................................................................................... 27 5.1 Resumen de la actividad del diseño ............................................................................ 27 5.2 Patrones de diseño ....................................................................................................... 27 5.2.1 Interfaz - gestión .................................................................................................. 27 5.3 Elección del tipo de aplicación .................................................................................... 28 5.4 Elección del lenguaje de programación de AsisT ....................................................... 29 5.5 Elección del lenguaje de programación que integra la centralita IP con AsisT .......... 29 6. SISTEMA ASIST ............................................................................................................... 31 6.1 Subsistema de bases de datos ...................................................................................... 31 Introducción -16- 1.8 Contenido de la documentación Este apartado pretende encaminar la lectura de la documentación aportada. La siguiente sección, presenta la metodología empleada, así como los estándares que se han utilizado. Posteriormente, se presenta un estudio del contexto de la teleasistencia y la arquitectura actual, detectando las ventajas y desventajas que tiene, frente a una plataforma IP. Se muestra además, la plataforma desarrollada para AsisT en la sección 3.5 y se presentan posibles soluciones en el ANEXO A. El desarrollo del sistema prosigue explicando las conclusiones destacadas en el análisis y desarrollo del sistema AsisT, secciones 4 y 5 de este documento. En el ANEXO B y el ANEXO C respectivamente, se detallan en profundidad. En la sección 6 se describe el sistema completo, describiendo las soluciones y elecciones tomadas y destacando la funcionalidad implementada. Por otro lado, en el ANEXO D se detallan aspectos técnicos implementados y en el ANEXO E se presenta la completa aplicación con el “Manual de usuario”. Finalmente, en la sección 7 se presentan las conclusiones alcanzadas una vez realizado el proyecto. Planificación del Sistema -17- 2. PLANIFICACION DEL SISTEMA 2.1 Metodología En la actualidad existen varios estándares de metodología de desarrollo el software: La metodología utilizada para el desarrollo del sistema ha sido Métrica 3 [30]. Los motivos han sido: - Conocimiento previo de Métrica 2.1. - Familiarización y recomendación de la empresa con dicha metodología. - Es completa y detallada. - Es propiedad intelectual del ministerio de administraciones públicas de España. - Disponible de la documentación en Internet, en la página oficial [30]. Métrica 3 se divide en grandes bloques y cada bloque tiene distintas actividades que se subdividen en tareas. La forma de abordar el problema ha sido seleccionar los bloques beneficiosos, realizar las actividades más significativas y relevantes de forma que cada actividad aportara nueva información a los siguientes pasos y completar de esta forma y progresivamente el desarrollo del producto. Los bloques que se han seguido más exhaustivamente son: - Planificación del sistema de información: o Tareas a realizar, el estudio inicial del contexto, la situación actual, los sistemas de información, definir el plan de trabajo, etc. - Análisis del sistema de información: o Actividades para el análisis del sistema. Disponible en el ANEXO B. - Diseño del sistema de información: o Actividades para el diseño del sistema. Disponible en el ANEXO C. - Construcción del sistema de información: o Implementación y pruebas del sistema. Disponible en el ANEXO D. o Manual de usuario. Disponible en el ANEXO E. Métrica ha servido de guía para realizar el desarrollo del producto. Esto significa que, en ocasiones, se ha seguido otro orden al efectuar las actividades que se han considerado prioritarias. También se han omitido algunas que resultaban redundantes o se han fusionado varias, para mejorar la legibilidad. El ciclo de vida del desarrollo ha sido en cascada mejorado, es decir, tras cada etapa se han revisado las anteriores actividades. El desarrollo de la implementación se ha realizado por módulos. Una vez implementado un módulo, se han realizado las pruebas del mismo, se han integrado con el resto de módulos y se han realizado las pruebas de integración, siguiendo la línea de cascada por módulos. 2.2 Planificación En el inicio del proyecto, una vez evaluada la metodología a utilizar y las tareas a realizar, se hizo una planificación inicial, siguiendo los pasos de la “Actividad de Planificación” de Métrica 3. La estimación era de 7 meses distribuidos desde Octubre a Abril. La planificación sufrió riesgos, detalles que se explican en las conclusiones de los ANEXOS B, D y C. Planificación del Sistema -18- La última planificación desarrollada y realizada es la que se muestra en la Figura 2-1. Figura 2-1 Planificación Estudio del entorno -19- 3. ESTUDIO DEL ENTORNO 3.1 Contexto de Teleasistencia Una empresa de teleasistencia dispone de uno o varios centros en los que ofrece servicio. Entre otros trabajadores, el centro cuenta con un equipo de operadores y un equipo preparado para desplazarse al domicilio del cliente según la incidencia: técnico, emergencia, etc. Una entidad local (un ayuntamiento, una comarca, un barrio, etc) puede solicitar contratar el servicio de teleasistencia en su jurisdicción. La solicitud pasa a concurso y se le asigna una empresa privada para la prestación del servicio a la entidad. El centro de teleasistencia puede subdividirse en grupos de operadores para que gestionen un área, distrito o entidad. De esta forma las alarmas, según el origen sean atendidas por el grupo específico. Un cliente solicita a la entidad local o a una empresa, el servicio de teleasistencia. Si cumple los requisitos, se instalará en su hogar un terminal y una unidad de control remoto, UCR. El cliente puede disponer además de varios dispositivos o equipos tal y como aparece en la Figura 3-1 Instalación de teleasistencia. La instalación pertenece a un hogar y tiene un código de identificación de usuario (CIU). Si el cliente se muda de vivienda, la instalación también. Figura 3-1 Instalación de teleasistencia Una alarma es originada por un equipo. Si el equipo es el terminal o la UCR, se inicia una alarma por la pulsación del botón, y se produce una llamada al centro de teleasistencia. Por el contrario, si la alarma es producida por otro dispositivo, no se inicia llamada. En este caso es una incidencia técnica que también tendrá que asistir el centro. Estudio del entorno -20- Todos los dispositivos están conectados al terminal que sabe el equipo que la ha originado y manda la señal al centro de teleasistencia. Para más detalle, véase las definiciones de teleasistencia en el GLOSARIO , página 58. 3.2 Investigación de la arquitectura actual Actualmente el sistema de teleasistencia está basado en la red de telefónica básica, RTB. Esto significa que cada vez que una instalación que posee un cliente origina una alarma, la alarma es una llamada por la red de teléfono convencional. En la siguiente Figura 3-2, se observa la arquitectura actual. La llamada llega a través de la RTB al centro de teleasistencia. El centro dispone de una centralita específica que da servicio a un determinado número de líneas de teléfono. Cada teléfono está conectado directamente a la centralita. Los operadores disponen de una aplicación para la atención de los clientes de teleasistencia. La centralita está configurada a medida por medio de un servidor que convierte los datos a CTI (conocido como integración de telefonía y datos), para que los operadores puedan gestionarlos. Figura 3-2 Arquitectura actual Estudio del entorno -21- Cada fabricante de equipos tiene sus propios protocolos, implementados mediante secuencias de marcación por tonos, DTMF. Para decodificar la información de las alarmas procedentes de los equipos, las empresas cuentan con un hardware capaz de traducir los distintos protocolos. Cada protocolo es soportado por una tarjeta que traduce un número limitado de terminales simultáneamente. El dispositivo hardware está limitado por el número de ranuras en las que insertar las tarjetas. Las instalaciones actuales tienen una serie de inconvenientes: - Alto coste de la centralita: tanto la inversión inicial como el mantenimiento de las mismas elevan los costes de la empresa. - Alto coste de la solución hardware multiprotocolo: la solución por hardware supone un elevado coste económico. - Limitación de equipos de clientes de un mismo fabricante: la arquitectura del hardware de traducción de protocolos dificulta la escalabilidad. - La centralita tiene limitado el número de operadores: si no se dispone de más conexiones para los teléfonos, la centralita, queda obsoleta. La empresa Verklizan ofrece la solución más completa y cara del momento. Su plataforma UMO soluciona el multiprotocolo mediante hardware e incorpora una centralita analógica para los puestos de los operadores [45]. Por otro lado, la empresa Sabia [46] presenta: - La central de alarmas B2000: la centralita analógica encargada de la gestión de alarmas y llamadas. - Puesto del operador B2301: dispositivo externo a la computadora del operador que permite comunicarse con la persona que ha efectuado la alarma. - Software CSTAtención: muestra las alarmas y expedientes de un cliente. 3.3 Contexto de la voz IP La voz IP se define como un conjunto de recursos que permiten que la señal de voz viaje a través de Internet por medio de los protocolos de Internet [21]. Una instalación IP necesita la tecnología necesaria para transformar la red de teléfono convencional en protocolo IP. Esta instalación puede estar en el centro, o se puede obtener contratando el servicio a una empresa especializada en ello. Una vez insertada la información de voz en un paquete IP y señalizada, se gestiona en una centralita IP para que finalmente se comunique con el resto de dispositivos conectados en la red. El teléfono IP destino puede ser un dispositivo hardware conectado a la red local o integrado en una aplicación, lo que se conoce como softphone. 3.4 ¿Por qué voz IP? Si comparamos una empresa con infraestructura voz IP con otra analógica, la gran diferencia es económica. Estudio del entorno -22- Para empezar, la inversión inicial es mayor en la analógica debido al coste de sus componentes. Para continuar, si se desea aumentar la instalación, dependiendo de la plataforma: - Analógica: Un teléfono convencional está conectado directamente a una centralita analógica. El número de conexiones que la centralita soporta está limitado por el número de conexiones analógicas que posea. - Voz IP: Un teléfono IP está conectado a la red local. La centralita IP no necesitará modificarse a no ser que se sobrepase ampliamente, el número de usuarios respecto a lo previsto inicialmente. Por ejemplo: se haya instalado un servidor configurado para 300-400 operadores y crezca por encima de 500. La solución actual supone la duplicación de hardware, y por consiguiente, de precio. La solución IP es más escalable, incluso muy cómoda en caso de ser subcontratada: - Si se subcontrata el servicio de telefonía: sólo es necesario solicitar nuevos canales concurrentes a la empresa que ofrece el servicio. - Si no se subcontrata el servicio: se necesita contratar nuevas líneas de telefonía y adquirir una pasarela para alimentar las líneas. Esta solución es mucho más rentable que la analógica. Además, una centralita IP puede estar configurada a medida de forma que pueda interpretar los distintos protocolos de terminales. De esta forma, evita el coste adicional que supone adquirir el hardware multiprotocolo y hace el sistema escalable en cuanto al número de terminales soportados por centro. Es decir, si en un área todos los clientes de teleasistencia utilizan los terminales de un mismo fabricante, se garantice dar el servicio a todos. 3.5 Arquitectura IP de AsisT La plataforma en la que se sustenta AsisT es la que se muestra en la Figura 3-3. Figura 3-3 Arquitectura IP de AsisT Estudio del entorno -23- En el centro de teleasistencia se instala un servidor que contiene: - Centralita IP. - Servidor de cola de mensajería. - Gestor de base de datos. En la red local de la empresa está el servidor y los puestos de los operadores. Esta arquitectura permite que no haya problemas en caso de caída de Internet y que en caso de realizar una llamada de emergencia (112), la centralita gestione la llamada en el área local conveniente (problema si la centralita está en un servidor externo). En el ANEXO A, se detallan e ilustran las distintas soluciones tomadas por la empresa Diaple Networking. Análisis de la información -24- 4. ANÁLISIS DE LA INFORMACIÓN 4.1 Actividades realizadas en el análisis Para el desarrollo de AsisT se ha realizado un completo análisis de la información siguiendo la metodología de Métrica 3 [30]. La documentación con todas las conclusiones y gráficos está disponible en el ANEXO B. En esta fase se ha realizado las siguientes tareas: - Análisis de la información del convenio-marco [5]. - Análisis de los requisitos para un usuario de teleasistencia: o Confección de un catálogo de requisitos funcionales y técnicos. o Analizar los subsistemas en los que está compuesto. o Confección de “casos de uso” de un usuario que accede al sistema AsisT. - Análisis de la información: o Confección del diagrama entidad – relación. o Confección del modelo entidad – relación. - Análisis de las clases: o Confección de un diagrama de clases. - Análisis de los patrones de las ventanas: o Confección de los prototipos de las ventanas. 4.2 Resumen de los requisitos de AsisT Se necesita un sistema capaz de estar instalado en varios puestos de trabajo de una misma red local. Los usuarios, desde su puesto de trabajo deben recibir en tiempo real y de forma simultánea un aviso de alarma. Sólo uno de ellos podrá capturarla y atenderla. Mientras esté atendiéndola, no recibirá más alarmas. Una vez que ha recibido la alarma podrá observar la información personal de la persona que la ha originado. Para la atención de las incidencias, ya sea con llamada o sin llamada, el operador deberá cumplimentar el tipo de alarma y realizar tantas actuaciones como sea necesario para atender satisfactoriamente al cliente. El sistema se encargará de establecer la llamada para cada actuación seleccionada. La llamada debe realizarse sin marcar el número y será el operador el que libere cuando finalice la conversación. Todas las alarmas que se generen deben estar almacenadas, así como la información de la gestión que realicen los usuarios. También es necesario tener la información de los clientes en lo referente a datos personales, vivienda, instalación, personas a recurrir en caso de emergencia, asistencia sanitaria, situación del servicio y últimas llamadas atendidas y recibidas. Dicha información debe poder ser creada, modificada o eliminada por un usuario. El usuario debe poder observar las alarmas que ha atendido y sus detalles, así como las llamadas que ha realizado o aceptado. La aplicación debe soportar distintos perfiles de usuarios. Se debe implementar la gestión del alta de nuevos usuarios para la aplicación y nuevos clientes. Análisis de la información -25- La aplicación deber ser rápida, segura y cumplir la ley de protección de datos [12]. También debe ser escalable, de forma que pueda expandirse en funcionalidad e información. Debe poder ejecutarse en distintos sistemas operativos. 4.3 Definición de actores y roles La aplicación AsisT está analizada para adaptarse a los distintos roles que pueda tener una empresa de teleasistencia, de forma que se gestione los permisos de acceso de funcionalidad apropiados. En esta versión se han identificado tres actores. Se llama indistintamente con el término usuario a cualquier persona que utilice la aplicación sin importar el rol, por el contrario, para especificar el usuario según el rol se atiende a la siguiente terminología: - Súper - administrador: acceso a toda la operativa de la aplicación. Tiene privilegios: o Gestión de los usuarios de la aplicación: alta / baja / modificación. o Gestión de los clientes del servicio: alta / baja / modificación del expediente. o Funcionalidad de los operadores. - Administrador: o Gestión de los usuarios de la aplicación: alta / baja / modificación. o Gestión de los clientes del servicio: alta / baja / modificación del expediente. - Operador: o Ver información y modificación del expediente de los clientes. o Gestión de alarmas: atención de alarmas entrantes y ver alarmas atendidas y activas. o Ver información de las llamadas entrantes y salientes. 4.4 Los subsistemas AsisT es el sistema a desarrollar. Los subsistemas son las partes dentro de AsisT que se han diferenciado según la funcionalidad. - Subsistema de base de datos: consiste en la realización y mantenimiento de la base de datos necesaria para almacenar toda la información que necesita AsisT en un gestor de base de datos adecuado. - Subsistema de información: tiene toda la interfaz e interacción con la base de datos. Se han distinguido distintos módulos en función de la información a gestionar: o Módulo de autentificación: gestiona el acceso a la aplicación. o Módulo Expediente-Cliente: información vivienda, instalación, conocidos, etc. o Módulo Clientes: dar de alta un nuevo cliente, listados de clientes, etc. o Módulo Usuarios: dar de alta un nuevo usuario a la aplicación AsisT, listado de usuarios, permisos, etc. o Módulo Alarmas: ver información de alarmas realizadas y gestionar las activas por un operador. o Módulo Llamadas: ver información de las llamadas recibidas y realizadas por un operador. - Subsistema softphone: hace el vínculo entre el subsistema de información y la centralita IP. Se encarga de utilizar el protocolo adecuado para recibir y enviar las llamadas que realice el usuario. - Subsistema Aviso alarmas: vínculo entre la centralita IP y los usuarios para la gestión de alarmas. Sistema AsisT -32- Todos los dispositivos de una casa están conectados al terminal y siempre será éste el que emita la señal de alarma. Para interpretar el multiprotocolo, la base de datos tiene una tabla con todos los protocolos de fabricantes y otra tabla que conecta el protocolo con el tipo de alarma que corresponde. Se ha implementado un script en PHP [32] que introduce la alarma en la base de datos. Este programa ha sido realizado con la herramienta Aptana [14]. Este script parte como entrada del código de identificación del usuario (CIU), y del tipo de alarma: - Crea la alarma con los datos de fechas, estado y cliente. - Inserta en la base de datos utilizando el API de MySQL disponible para PHP. El script es ejecutado por la centralita IP, por medio del interfaz AGI [54]. Ésta dispone de las librerías y mecanismos para ejecutarlo dentro del servidor. No es necesario por tanto, un servidor web para su ejecución como se acostumbra a relacionar PHP. 6.2 Subsistema de atención de alarmas En primer lugar se explica cómo AsisT soluciona e integra el problema de las alarmas. Los operadores están conectados a la red local del centro de teleasistencia. Todos los operadores están conectados a un servidor local formado por: - Centralita IP - Base de datos Los operadores necesitan ser avisados de dos tipos de eventos: - Llegada de una alarma nueva al centro de teleasistencia: se informa por pantalla a todos los operadores. - Quitar el aviso de la alarma ya que un operador la ha capturado: todos los operadores deben dejar de recibir el aviso. 6.2.1 Solución al aviso de alarmas La solución para el aviso de alarmas es la utilización de una cola de mensajes (Message Broker) de forma que los usuarios que estén conectados a la red local y que hayan inicializado la aplicación AsisT, puedan dar parte de la llegada de un evento y actuar en consecuencia. El modelo empleado es publicador/suscriptor y los eventos son de tipo síncronos. Cuando se quiera notificar un evento al resto de suscriptores, se instancia la clase publicador, para que escriba un mensaje en un tema de la cola de mensajería. La cola de mensajería es un servidor que se ha instalado localmente junto con la base de datos y la centralita IP. El objetivo: conectar la centralita IP – alarmas – operadores. AsisT puede ser publicador o suscriptor según el tipo de evento que desea notificar. Como puede observarse en la Figura 6-1. Al iniciar la aplicación, se convierten en suscriptores del tema „asist‟, y a partir de este momento leen los mensajes publicados. Por el contrario, la centralita IP sólo notifica eventos. En la sección 6.2.3 se detallan los eventos y actuaciones ante los avisos. Sistema AsisT -33- Figura 6-1 Mensajería modelo publicador / suscriptor 6.2.2 Elección del servidor de mensajería Para elegir un servidor de mensajería acorde con las características de la aplicación se destacan las siguientes necesidades del sistema: - Compatible con java (Java message service, JMS [18]): de forma que AsisT interaccione con el servidor. - Compatible con PHP [32]: script PHP que ejecuta la centralita IP para publicar un mensaje. - Software libre. De los numerosos servidores de colas de mensajes disponibles, se destacaron los siguientes por popularidad y reciente actividad: ActiveMQ [24], OpenJMS [25] y RabbitMQ [26]. OpenJMS ha sido descartado debido a la incompatibilidad con PHP. ActiveMQ y RabbitMQ son muy similares: ofrecen la posibilidad de ser multiplataforma y varios servicios para facilitar la gestión como un gestor web para publicar mensajes. Finalmente se eligió ActiveMQ debido al soporte por parte de la comunidad Apache. La comunidad Apache ofrece confianza en mantenimiento y seguridad. 6.2.3 Integración mensajería con AsisT La centralita ejecuta un script en PHP [32] en el que: - Introduce la alarma en la base de datos. - Se conecta a la cola de mensajería ActiveMQ [24] y publica un mensaje anunciando el evento: “alarma”. El mensaje tiene la siguiente estructura: Sistema AsisT -34- Para integrar la mensajería con Java se ha hecho uso del API JMS [18]. Al iniciar la aplicación, se suscribe a un tema: „asist‟ en el proveedor de mensajería ActiveMQ. Desde este momento, el sistema está a la escucha de los mensajes publicados en tema. Cuando la aplicación detecta que se ha publicado un mensaje, según el tipo de evento, se interpreta para actuar en consecuencia: mostrar o quitar aviso de alarma. Llegada de alarma Figura 6-2 ilustra cómo el sistema AsisT es notificado ante el evento de una alarma nueva. El mensaje escrito por la centralita es de tipo alarma, los suscriptores leen el mensaje y muestran el aviso de la alarma. Figura 6-2 Aviso de alarma AsisT inicia una ventana emergente, véase Figura 6-3 , en la esquina inferior derecha en todas las aplicaciones de los usuarios que están inicializadas. Dicha ventana tiene información de la alarma del cliente al que pertenece, el tipo de alarma, la fecha y la hora. Figura 6-3 Ventana aviso de alarma message_type=ALARMA message_source=ASTERISK message_created=(FECHA_HORA_ACTUAL) alarma_id=1201 Sistema AsisT -35- A medida que se reciban nuevas alarmas, estarán listas para ser capturadas por el usuario. En esta primera versión, cuando un usuario esté atendiendo una alarma, no recibirá nuevos avisos. Capturar la alarma La Figura 6-4 ilustra cómo AsisT captura una alarma. En la ventana emergente de “aviso de alarma”, los operadores pueden seleccionar “capturar alarma” e iniciar la gestión de la misma. El proceso de que un operador obtenga la alarma, comienza en comprobar si no ha sido ya capturada por otro operador. Para ello, se hace una lectura en la base de datos y se comprueba el estado. La Figura 6-4, muestra la interacción entre los componentes. El operador ganador es el que ha leído la alarma que está desactivada. Una vez cambiado el estado a activada, los operadores no podrán capturarla. Figura 6-4 Caputura de alarma Una alarma sólo puede ser atendida por una persona, dos usuarios nunca pueden atender una alarma simultáneamente. Esto provocaría que los datos almacenados no sean los correctos. La Figura 6-5 ilustra la situación de error. Los dos usuarios hacen la consulta en la base de datos. El primero en llegar, ha modificado la alarma indicando que ya no está activa. En un periodo pequeño de tiempo, los cambios no se han guardado de forma permanente en la base de datos (no ha realizado commit). El problema surge cuando el segundo operador, lee que está libre, accediendo a la misma información y gestionándola a la vez. Sistema AsisT -36- Figura 6-5 Error en captura La base de datos está implementada en el gestor de almacenamiento InnoDB [27] que permite transacciones. El modelo de transacciones permite lecturas en modo de bloqueo. La función “select… for update” bloquea la captura de la alarma, de esta manera, cuando la aplicación realiza la consulta, sólo un usuario accede en exclusividad [48]. Aunque se pulse casi simultáneamente para capturar la alarma, sólo uno la obtiene y el perdedor, es notificado por pantalla. Cancelar alarma para el resto de suscriptores Un usuario ha aceptado la alarma, por lo tanto debe desaparecer la ventana emergente de aviso de alarma para todos los usuarios que están conectados a la aplicación. En este momento, AsisT se comporta como publicador y publica un mensaje en ActiveMQ con la siguiente información: Donde “usuario_id” es el operador que la ha capturado y “alarma_id” es el identificador de la alarma. Todos los usuarios leen dicho mensaje en el Tema “asist” del Active MQ, incluido el usuario que la ha capturado. La aplicación actúa eliminando el aviso de alarma por pantalla. La Figura 6-6 ilustra que el “suscriptor 1” captura la alarma e informa al resto de aplicaciones activas por medio de ActiveMQ para quitar el aviso. message_type=ALARMA_CAPTURADA message_source=usuario_id message_created=(FECHA_HORA_ACTUAL) alarma_id=1201 User 1 User 2 Sistema AsisT -37- Figura 6-6 Alarma capturada 6.3 Subsistema teléfono El softphone es el teléfono integrado en la aplicación. En otras palabras, es la implementación de las funcionalidades típicas de un teléfono y de la gestión de los canales de voz y datos con la centralita IP. Para que una llamada desde la aplicación pueda salir a la red convencional o una llamada desde el exterior pueda entrar a la red local, se necesita una centralita IP configurada a medida. Un teléfono IP puede ser un dispositivo externo cuya diferencia con un teléfono convencional es que está conectado a la red local por la que recibe los datos de voz IP. La primera versión de AsisT está configurada de modo que el teléfono está integrado en la aplicación. Para ello, el puesto de los operadores necesita una tarjeta de sonido integrada para la entrada de altavoces y micrófono. Para que un teléfono sea operativo en la aplicación necesita: - Conectarse satisfactoriamente con la centralita IP. - Realizar llamadas y aceptarlas a partir de la aplicación AsisT. - Señalizar con la centralita la información siguiendo el protocolo de la misma. 6.3.1 Centralita IP La centralita IP está instalada y configurada en un servidor por medio del software libre Asterisk [22]. Los detalles programados en Asterisk quedan fuera del alcance del proyecto. El protocolo IP utilizado por la centralita para comunicarse en la red, es SIP (Session Initiation Protocol) [2]. Una vez que llega la red de telefonía básica (RTB) al centro de teleasistencia, la pasarela (gateway), la conecta con SIP para poder comunicarse con la centralita y el resto de dispositivos conectados en red. Entre otros dispositivos, están todos los puestos de los operadores con la aplicación AsisT operativa. En la Figura 6-7 se observa la plataforma IP donde los elementos conectados en la red local son el puesto de trabajo, teléfono IP, servidor, y la pasarela. El servidor contiene la centralitaIP, la base de datos y la cola de mensajería. Sistema AsisT -38- Figura 6-7 Plataforma IP 6.3.2 Solución adoptada Para implementar la conexión y comunicación con la centralita se ha hecho uso de la librería Jain [1], que es un API disponible para Java [6] que ofrece las funciones para construir mensajes SIP en bajo nivel. El subsistema está formado por tres capas de forma que abstrae la funcionalidad de la capa inferior: - 1er Nivel: funciones que utiliza el subsistema de información de AsisT para establecer conexión, realizar una llamada y terminarla. - 2º Nivel: funciones para construir paquetes de SIP acordes con la funcionalidad y configuración deseada. - 3º Nivel: librería Jain: aporta funciones para la construcción de la pila de SIP. Se ha creado una nueva tabla en la base de datos, que almacena la configuración del teléfono de la aplicación. Cuando AsisT inicia la aplicación, establece la conexión con Asterisk. Si la configuración es la correcta, el sistema queda a la escucha de recibir eventos. El protocolo SIP se basa en el envío de mensajes. La aplicación envía mensajes: peticiones y respuestas. Una petición es cualquier mensaje con un tipo en concreto: invite, request, ok, ack, bye, etc. Una respuesta es una petición con un tipo, a consecuencia de recibir una petición por parte de la centralita. [2] Para más detalle de las funciones implementadas, véase la sección D.8, en el ANEXO D. 6.3.3 Conexión con la centralita La Figura 6-8 detalla la secuencia implementada para establecer la conexión con Asterisk [22]. El sistema se conecta a Asterisk por identificación por “paso de testigo” (token passing). El primer mensaje de AsisT siempre es sin éxito y el servidor responde con un mensaje con un identificador propio para asegurar la conexión. AsisT responde reenviando el mensaje con los datos de autenticación del puesto de trabajo. Si son correctos, la conexión se ha realizado con éxito. Sistema AsisT -39- Figura 6-8 Conexión con la centralita 6.3.4 Establecer una llamada Una llamada se inicia con una petición de tipo invite. La Figura 6-9 muestra la secuencia de mensajes SIP. AsisT realiza: - Cuando pulse el botón de inicio de llamada, se manda la información del teléfono configurado en ese puesto. - Se realiza el paso de mensajes SIP entre los dos dispositivos de forma que confirmen ambos la conexión. - Se abre el canal de audio. - Finaliza la llamada (bye). Figura 6-9 Realizar una llamada Todas llamadas salientes permitidas por la aplicación son a consecuencia de una alarma. Cuando se indica la actuación más acorde con la incidencia, aparece un listado de números de teléfono que cuando confirme, establece directamente la llamada. El operador, no introduce por su cuenta ningún otro número de teléfono para realizar una actuación, para evitar el mal uso de la aplicación. 6.3.5 Aceptar una llamada entrante Una llamada entrante llega a la centralita a consecuencia de una alarma: - Asterisk identifica que la alarma que ha recibido es de tipo llamada. - Asterisk mantiene la llamada en espera hasta que un operador la capture. - Cuando es capturada, AsisT responde con una llamada a Asterisk. - Se realiza el paso de mensajes SIP hasta finalmente se abre el canal de voz. Véase la Figura 6-9 de la sección anterior. Sistema AsisT -40- - El operador habla con el cliente hasta que él finaliza la llamada (siguiendo las especificaciones del convenio-marco [5]). 6.3.6 Interfaz del teléfono El estado del teléfono está siempre visible en la esquina superior derecha. Los mensajes de estado son: - “Esperando llamadas”: una vez que el teléfono se ha registrado correctamente y se ha terminado una llamada. - “Registrando teléfono”: ha lanzado la petición para conectarse y espera confirmación. - “Recibiendo llamadas”: el softphone tiene una llamada entrante. - “Marcando <número_al_que_marca>”: ha iniciado la llamada pero el teléfono del destinatario, aún no está sonando. - “Teléfono no registrado”: cuando los datos de configuración del usuario no son correctos. - “Hablando…”: el canal de audio ha sido abierto. - “Estableciendo conexión”: cuando esté conectado con la centralita IP. - “Llamada <número de teléfono>”: en el caso que esté realizando una llamada o recibiendo. Aparece la información del número de teléfono y del tiempo actualizado de la llamada. - “Sonando”: cuando tiene una llamada entrante. - “Denegado”: cuando la centralita deniega establecer una llamada con dicho número. - “Prohibido”: cuando no está permitido llamar a dicho número. En la Figura 3-2, se observa el softphone en diferentes estados. Cuando no hay una llamada activa, el softphone tiene el botón “llamar”. Por el contrario, cuando está hablando, el botón “colgar”. Figura 6-10 Softphone sonando - hablando – en espera 6.3.7 Integración con la base de datos Cuando se realiza o recibe una llamada, la centralita o Asterisk se encarga de introducir la información. Se ha realizado un programa en PHP, similar a introducir una alarma que introduce y modifica los datos de la llamada en la base de datos, de forma que puedan ser visualizados en el expediente del cliente y el los historiales del operador. 6.3.8 Chequeo de un equipo Chequear un terminal consiste en conocer en tiempo real desde la aplicación AsisT, el estado del dispositivo: “activado” o “desconectado”. Desde el expediente del cliente, en la pestaña instalación, se gestionan los equipos que dispone el cliente en su hogar. Cuando se añade un nuevo equipo su estado es “pendiente”. El botón “chequear” comprueba el estado del dispositivo. Un chequeo se reduce a realizar una llamada hacia el dispositivo, en la que no abre el canal de audio. Si responde correctamente, el estado es “activado”. Sistema AsisT -41- 6.4 Subsistema información Este subsistema se caracteriza por contener toda la interfaz y procesamiento de información de la aplicación. Se ha construido siguiendo el patrón para el acceso a base de datos VO-DAO y para la interfaz como View – Action. El orden en el que se explican no es el de implementación. Se trata de explicar lo que se ha implementado en cada uno y la funcionalidad que aporta al sistema. 6.4.1 Contexto del funcionamiento AsisT es una aplicación de escritorio. Para entrar en la aplicación hace falta autentificarse con nombre y contraseña. Según el perfil y permisos de usuario la aplicación tiene vistas distintas. Los administradores, observarán el “módulo de administración”, mientras que los operadores el “módulo de tele-asistencia”. En los ejemplos descritos durante la memoria, se considerara el perfil de “super-administrador” sin restricción de acceso. Una vez que los datos son correctos, se accede a la pantalla principal. Está formada por un menú a la izquierda, que siempre está visible y el resto es el centro de operaciones para la gestión de la información. Cuando arranca la aplicación se suscribe a la cola de mensajes, se inicializa el softphone y se establece conexión con la base de datos. La Figura 6-11 muestra el inicio de la aplicación AsisT: barra de estado superior, menú y centro de operaciones. En el centro de operaciones siempre está visible el “Inicio” o cuadro de mandos, cuyos detalles se explican en el apartado 6.4.2. Figura 6-11 Inicio aplicación AsisT Cuando se pulsa un botón del menú, se abre una pestaña en el panel central con dicha información. Se pueden abrir tantas pestañas como el usuario necesite, de la misma forma que se pueden cerrar. La aplicación no duplica una pestaña si ya está abierta. Sistema AsisT -48- De esta forma, una empresa puede gestionar los perfiles y permisos que tienen los empleados, para que sean configurados en la gestión de usuarios. 6.5.5 Control de errores Se ha implementado la gestión de errores por pantalla de forma que avise a un usuario de la introducción de datos erróneos o acciones que no puede llevar a cabo, como por ejemplo, obtener una alarma que ha capturado otro operador. Este gestor permite guardar la información con el fin de que en un futuro y por petición del usuario, un error sea enviado a un servidor web, fichero de un servidor o un correo electrónico, para ser resuelto por un equipo de mantenimiento del software. Conclusiones -49- 7. CONCLUSIONES En este apartado, se detallan las conclusiones llegadas tras la realización de este proyecto. Se analizan tres aspectos: - Cumplimiento de los objetivos - Futuro de AsisT - Valoración personal 7.1 Cumplimiento de los objetivos iniciales Volviendo la vista atrás, los objetivos que inicialmente se establecieron se han cumplido: - Se ha desarrollado un sistema de gestión de alarmas en tiempo real, capaz de recibir alarmas desde una centralita IP. - Se ha construido un sistema de información capaz de gestionar la información de los clientes de teleasistencia. - Se ha desarrollado un sistema softphone capaz de establecer llamada con el exterior a través de una centralita IP. - Se ha construido la lógica de gestión para que una empresa de alta a los usuarios de la aplicación y los clientes. - El sistema es robusto, escalable, multiusuario y cumple la ley de protección de datos. Además, dos aspectos importantes se han tenido en cuenta: - En el desarrollo del sistema se ha utilizado la metodología del software de Métrica 3: aspecto que aporta consistencia al desarrollo. - Todas las herramientas utilizadas han sido software libre, lo que permite superar las limitaciones del software privado. Aunque los objetivos hayan sido alcanzados, se puede afirmar que el sistema no está completo. Un sistema de información de clientes de teleasistencia puede crecer exponencialmente en funcionalidad. Además se han descubierto nuevas líneas que podrían ser incorporadas. Este aspecto se detalla a continuación. 7.2 Futuro de AsisT AsisT es un sistema innovador en el mercado. Actualmente, no existe ningún software de gestión de un centro de teleasistencia, que integre un softphone en la aplicación y/o que interactúe con una centralita IP. La telefonía IP está ganando nuevos adeptos en las empresas, dejando obsoletas las centralitas analógicas por ser poco escalables y costosas. La teleasistencia basada en una plataforma IP es el siguiente paso al que se enfrentan las empresas de teleasistencia. Este proyecto da solución a este problema. A partir de aquí, la programación puede aporta nueva funcionalidad para mejorar la gestión de la aplicación y la gestión de la teleasistencia. En cuanto a la gestión de la aplicación: - Gestión asistencia sanitaria, hospitales y médicos: crear / modificar /eliminar dichos datos (actualmente en desarrollo). Conclusiones -50- - Gestión de empresas de servicios del hogar: crear/modificar/eliminar empresas de servicios (actualmente en desarrollo). - Gestión de grupos de operadores en un centro de teleasistencia (actualmente en desarrollo). En cuanto a la gestión de teleasistencia: - Gestión de informes: sistema completo de informes para la empresa (actualmente en desarrollo). o De las sesiones de un operador en un periodo de tiempo. o En formato “.pdf” y correo electrónico. o Sesiones directamente a la impresora. - Teléfono integrado en la aplicación: o Llamada en espera: dejar en espera al cliente mientras se realizan las actuaciones. o Grabación de llamadas entrantes y salientes. o Videoconferencias. o “Conversación a 3”. o Control de volumen desde la aplicación. - Configuración para la personalización de AsisT: o Fijar filtros según criterios de aviso: solo reciban avisos de alarma si no están atendiendo, atender una o varias alarmas, etc. o Detalles de aviso configurables con sonido. o Modificación datos del cliente durante la sesión. - Alarmas: o Integrar aviso de alarmas con mensajería móvil. - Tele-programación de los equipos desde la aplicación: ejemplo, modificar la fecha y hora, modificar el volumen, etc. - Agenda: gestionar las tareas para un operador a beneficio de los clientes: o Planificación de citas o recordatorios de los clientes. - Teleasistencia móvil: o Integrar alarmas desde un dispositivo móvil provenientes de GPS [55]. Es mucha la funcionalidad que podrían incorporarse: la programación y las herramientas existentes en la actualidad, lo hacen posible. Lo importante, es que lo más peliagudo: los conocimientos, la plataforma, la primera versión de gestión, está realizada y que dadas las características con las que se ha realizado el sistema, puede ser escalable en funcionalidad e información. Se espera que AsisT pueda tener una larga vida y un gran futuro, en el que espero seguir trabajando en ello. 7.3 Valoración Personal Mi valoración del proyecto es muy positiva. La motivación inicial que me llevó aceptar el proyecto ha impulsado mi gran interés y confianza en un proyecto innovador, basado en nuevas tecnologías y con un futuro prometedor. El proyecto ha indagado en los campos de softphone, cola de mensajes, programación en java, programación en PHP, servidores, redes, tecnología IP, etc. Gracias a ello, he conseguido adquirir nuevos conocimientos acerca de nuevas herramientas que desconocía y disfrutar de los logros alcanzados. Conclusiones -51- El hecho de realizar el proyecto en una empresa ha sido una experiencia muy gratificante. Tener el apoyo de la empresa, obtener los conocimientos de los compañeros y cometer errores y aprender de ellos, me ha ayudado para formarme en conocimientos, profesionalmente y como persona. -53- Acrónimos -55- ACRÓNIMOS API Application Programming Interface BD Base de Datos CIU Código de Identificación de Usuario CPD Centro de Proceso de Datos CTI Computer Telephony Integration DAO Data Access Object DFD Diagrama de Flujo de Datos DTMF Dual-Tone Multi-Frecuency FEMP Federación Española de Municipios y Provincias IMSERSO Instituto de Mayores y Servicios Sociales GPS Global Position System IP Internet Protocol JDBC Java Database Connectivity JMS Java Messaging Service PBX Private Branch Exchange PDF Portable Document Format RTB Red de Telefonía Básica SAAS Sotfware As A Service SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol UDP User Data Protocol UCR Unidad de Control Remoto URI Uniform Resource Identifier VO Value Object XML Extensible Markup Language Bibliografía -56- BIBLIOGRAFÍA Referencia Título [1] JAIN http://java.sun.com/products/jain/ [2] SIP: RFC 3261 http://www.ietf.org/rfc/rfc3261.txt [3] IMSERSO http://www.imserso.es/imserso_01/index.htm [4] FEMP http://www.femp.es/ [5] Normativa de teleasistencia aportada por IMSERSO y FEMP: http://www.imsersomayores.csic.es/documentos/documentos/imserso-programateleasistencia- 01.pdf [6] Java : http://www.java.com/en/ [7] Comunidad Open Source: http://www.opensource.org/ [8] Sistema opertaivo Linux Ubuntu: http://www.ubuntu-es.org/ [9] MySQL: http://www.mysql.com/ [10] Postgree SQL http://www.postgresql.org/ [11] Oracle: Gestor de bases de datos http://www.oracle.com/global/es/index.html [12] Ley juridical de protección de datos: http://noticias.juridicas.com/base_datos/Admin/lo15-1999.html [13] NetBeans: Herramienta de programación http://netbeans.org/ [14] Aptana: Herramienta de programación utilizada para PHP http://www.aptana.org/ [15] JDBC Driver para MySQL http://dev.mysql.com/downloads/connector/j/3.0.html [16] Substance: https://substance.dev.java.net/ [17] Herramienta de debuging para java: http://logging.apache.org/log4j/1.2/download.html [18] Librería JMS para paso de mensajes: http://java.sun.com/products/jms/docs.html Java message service / Richard Monson-Haefel, David A. Chappell [19] Librería JUnit pruebas del sistema: www.junit.org/ [20] Design Patterns: Elements of Reusable Object-Oriented Software Escrito por Gamma [21] Fundamentos de voz sobre IP / Jonathan Davidson, James Peters [22] AsterisK: Software de gestión de la centralita IP http://www.asterisk.org/ [23] Properties claas: http://java.sun.com/j2se/1.5.0/docs/api/ [24] Cola de mensajería Active MQ: http://activemq.apache.org/ [25] Cola de mensajería OpenJMS http://openjms.sourceforge.net/ [26] Cola de mensajería Rabbit MQ http://www.rabbitmq.com/ [27] Gestor de almacenamiento InnoDB http://dev.mysql.com/doc/refman/5.0/en/innodb.html [28] Análisis y diseño orientado a objetos de sistemas usando UML / Simon Bennet, Steve McRobb, Ray Farmer [29] Object-oriented analysis / Peter Coad and Edward Yourdon [30] Métrica 3:Metodología de Software http://www.csi.map.es/csi/metrica3/index.html [31] Pencil v1.0: herramienta de modelado http://www.evolus.vn/pencil/Downloads.html [32] PHP http://php.net/index.php Bibliografía -57- Referencia Título [33] DIA : Herramienta de diagramas http://live.gnome.org/Dia [34] GIMP: Herramienta de edición de imágenes http://www.gimp.org/ [35] Umbrello: Herramienta de modelado UML http://uml.sf.net, [36] OpenOffice: Procesador de texto y diagramas http://es.openoffice.org/ [37] Subversion http://subversion.tigris.org/ [38] Label: Clase Label de Java http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Label.html [39] Clase JOptionPane http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JOptionPane.html [40] Event Listener http://java.sun.com/docs/books/tutorial/uiswing/events/index.html [41] Timer Task http://java.sun.com/j2se/1.4.2/docs/api/java/util/TimerTask.html [42] Mozilla Firefox: navegador web http://www.mozilla.com/en-US/ [43] ActiveMQ Web console http://activemq.apache.org/web-console.html [44] MySQL Query Browser http://dev.mysql.com/doc/query-browser/en/index.html [45] Empresa Verklizan: Servidor UMO http://www.verklizan.org/exec/verklizanweb.exe?lang=SP&page=Pagina/UMO52.html [46] Empresa Sabia: http://bioingenieria.es/Teleasistencia/Teleasistencia.htm [47] .Net http://www.microsoft.com/net/ [48] Select for update http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html [49] XML http://www.w3.org/XML/ [50] Swing http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/package-summary.html [51] Aplicación Flash http://www.adobe.com/es/ [52] Applet Java http://java.sun.com/applets/ [53] Active X http://msdn.microsoft.com/en-us/library/ms537508.aspx [54] AGI http://www.voip-info.org/wiki/view/Asterisk+AGI [55] GPS http://www.gps.gov/ [56] API JCalendar https://jcalendar.dev.java.net/ [57] Wikipedia http://www.wikipedia.org