UNIVERSIDAD AUSTRAL DE CHILE SEDE PUERTO MONTT ESCUELA DE INGENIERIA EN COMPUTACION Analizador de Tráfico Telefónico GNU Linux Seminario de Titulación para optar al título de Ingeniero en Computación PROFESOR PATROCINANTE: Sra. Viviana Alvarado Espinoza Nixia Alejandra Quero Tangol PUERTO MONTT - CHILE 2012 Dedicado a mi abuela, mi familia y mi hija. AGRADECIMIENTOS En estas breves líneas deseo agradecer en primer lugar a mis padres, ya que gracias a su ejemplo y esfuerzo me han permitido convertirme en Madre y profesional. A mi Abuela, por su apoyo incondicional en todo momento, su insistencia y su fortaleza para continuar con nosotros al momento de terminar este largo camino. A mi pareja y mi hija, los que me dieron la fuerza y la motivación para convertirme en una profesional. Al profesor Moisés Coronado por aceptar este tema de tesis y a la profesora Viviana Alvarado por aceptar la continuidad del proyecto y su dedicación para las revisiones y correcciones. INDICE Síntesis. Abstract. 1. Introducción...............................................................................................1 2. Objetivos ....................................................................................................3 3. 2.1. Objetivo general..............................................................................3 2.2. Objetivos específicos ......................................................................3 Planteamiento del Problema ....................................................................5 3.1. Antecedentes ..................................................................................5 3.1.1. Definición del problema......................................................5 3.1.2. Esfuerzos anteriores ..........................................................6 3.1.3. Solución propuesta ............................................................6 3.2. Justificación ....................................................................................8 3.3. Delimitación ..................................................................................10 4. Metodología .............................................................................................11 5. Recursos ..................................................................................................14 6. 5.1. Hardware ......................................................................................14 5.2. Software .......................................................................................14 Introducción a la telefonía. .....................................................................16 6.1. Centrales Telefónicas. ..................................................................16 6.1.1. Central telefónica pública. ................................................16 6.1.2. Central telefónica privada. ...............................................18 6.1.3. Descripción de centrales telefónicas privadas utilizadas en el proyecto. ..............................................................................20 6.2. 7. Procesos para la realización de una llamada. ..............................30 Desarrollo de la aplicación. ....................................................................32 7.1. Plan Operativo ..............................................................................32 7.2. Especificación de los requisitos ....................................................33 7.3. Especificación funcional ...............................................................37 7.4. Diseño. .........................................................................................43 7.5. 7.4.1. Diagrama de clases .........................................................43 7.4.2. Diseño de la base de datos..............................................51 Implementación. ...........................................................................59 7.5.1. Etapa 1: Captura a través de puerto serial.......................59 7.5.1.1. Plan Operativo. ........................................................59 7.5.1.2. Especificación de los requisitos. ..............................60 7.5.1.3. Especificación funcional. .........................................63 7.5.1.4. Implementación. ......................................................68 7.5.1.5. Validación y verificación. .........................................70 7.5.2. Etapa 2: Traspaso captura a base de datos ...................72 7.5.2.1. Plan operativo. .........................................................72 7.5.2.2. Especificación de requisitos y funcional. .................73 7.5.2.3. Implementación. ......................................................74 7.5.2.4. Integración. ..............................................................79 7.5.2.5. Validación y verificación. .........................................81 7.5.3. Etapa 3: Generación de reportes .....................................84 7.5.3.1. Plan operativo. .........................................................84 7.5.3.2. Especificación de requisitos y funcional. .................84 7.5.3.3. Diseño. ....................................................................87 7.5.3.4. Implementación. ......................................................91 7.5.3.5. Integración. ..............................................................93 7.5.3.6. Validación y verificación. .........................................94 7.6. Integración Final. ..........................................................................96 7.7. Validación y verificación final. .......................................................98 8. Conclusiones y/o recomendaciones. ..................................................108 9. Bibliografía.............................................................................................110 10. Anexos. ..................................................................................................112 Anexo A: Manual de usuario LPBX Analizador de tráfico telefónico ....112 Anexo B. Código de pruebas detección de puertos seriales utilizando librería JavaCom ...................................................................................133 Anexo C. Código de pruebas de lectura puerto serial utilizando librería RXTX ……………………………………………………………………… 135 Anexo D: Glosario .................................................................................140 Anexo E: Script de la base de datos .....................................................142 Figuras Figura 1: Trama de distribución de una central metropolitana .........................17 Figura 2: Esquema Central telefónica privada .................................................19 Figura 3: Arquitectura Nitsuko TXZ Series.......................................................21 Figura 4: Teléfono Multi-Línea modelo 6TD76TXD/12TD/12TXD....................22 Figura 5: Teléfono Multi-Línea modelo 6BTD/6BTXD/12BTD/12BTXD ...........23 Figura 6: Esquema de funcionamiento DISA. .................................................25 Figura 7: Arquitectura Panasonic KX-TA 308 ..................................................26 Figura 8: Cartilla de controles para la programación Panasonic KX-TA 308 ...27 Figura 9: Asigna los parámetros de comunicación para la Interfaz Serial (RS232C) ...............................................................................................................28 Figura 10:Asigna los parámetros ancho de página ..........................................28 Figura 11: Asignación de impresión de las llamadas .......................................29 Figura 12: Central TDA100 ..............................................................................30 Figura 13: Comunicación entre extensiones ....................................................31 Figura 14: Software Tarificador Wintariff..........................................................34 Figura 15: Overcall Small.................................................................................35 Figura 16: Diagrama de la aplicación ..............................................................37 Figura 17: Esquema módulo captura serial .....................................................38 Figura 18: Esquema módulo traspaso de la captura serial a la base de datos. .........................................................................................................................38 Figura 19: Esquema módulo de generación de reportes .................................39 Figura 20: Diagrama de clases esquema completo .........................................43 Figura 21: Diagrama de clases, parte 1 ...........................................................44 Figura 22: Diagrama de clases, parte 2 ...........................................................45 Figura 23: Diagrama de clases, parte 3 ...........................................................46 Figura 24: Diagrama conceptual de la base de datos ......................................51 Figura 25: Diseño lógico de la base de datos ..................................................53 Figura 26: Diseño físico de la base de datos ...................................................54 Figura 27: Cable serial RS232 Hembra ...........................................................62 Figura 28: Cable USB-Serial............................................................................62 Figura 29: Esquema de Interfaz Captura Serial ...............................................70 Figura 30: Secuencia de captura datos router Cisco 800. ...............................71 Figura 31: Secuencia de captura Panasonic y Nitsuko ....................................72 Figura 32: Módulo de pruebas de escritura en base de datos MySQL ............75 Figura 33: Escritura en base de datos MySQL ................................................76 Figura 34: Módulo de pruebas versión 2 de escritura en base de datos MySQL .........................................................................................................................77 Figura 35: Versión 2 de escritura en base de datos MySQL ............................78 Figura 36: Formulario Ingreso Números telefónicos de la empresa ................79 Figura 37: Esquema de almacenamiento captura puerto serial .......................81 Figura 38: Esquema de conexión Central Panasonic y Nitsuko ......................82 Figura 39: Integración entre módulo de captura serial y base de datos ..........82 Figura 40: Integración final entre Módulo de captura y traspaso hacia la base de datos ...........................................................................................................83 Figura 41: Esquema visual reporte sin gráficos ...............................................88 Figura 42: Esquema visual de reporte con gráficos página 1 ..........................89 Figura 43: Esquema visual de reporte con gráficos página 2 .........................90 Figura 44: Prueba de generación de gráficos. .................................................91 Figura 45: Aplicación de prueba generación archivo PDF ...............................92 Figura 46: Resultados de la generación de archivo PDF ................................92 Figura 47: Generación de gráfico estadístico en un período determinado.......94 Figura 48: Generación de gráfico estadístico de todas las extensiones en un período determinado. .......................................................................................95 Tablas Tabla1: Programa 57 Nitsuko Serie TX-Z ........................................................24 Tabla 2: Entidad y cardinalidad ........................................................................52 Tabla 3: Tablas de almacenamiento de información PBX. ..............................55 Tabla 4: Tabla de Configuración modelo central telefónica. ............................56 Tabla 5: Tabla contenido SerialParameters_BAUD .........................................57 Tabla 6: Tabla contenido SerialParameters_DATABIT ....................................57 Tabla 7: Tabla contenido SerialParameters_STOPBIT ...................................58 Tabla 8: Tabla contenido SerialParameters_PARITY ......................................58 Tabla 9: Asignación de pines cable serial RS-232 ...........................................60 Tabla 10: Asignación de pines. ........................................................................61 Tabla 11: Aplicaciones que utilizan la librería RXTX. ......................................66 Tabla 12: Tabla SerialTesting módulo traspaso datos ....................................75 Tabla 13: Segunda tabla SerialTesting módulo traspaso datos .....................77 Síntesis Este trabajo de tesis se desarrolló con la finalidad de generar una solución que permitiese medir de forma clara el consumo telefónico generado a través de una central telefónica privada, entre las distintas extensiones que componen una pequeña y mediana empresa utilizando herramientas de código abierto para su desarrollo, con la finalidad de que pueda ser descargada e instalada sin necesidad de adquirir costosas licencias, las cuales son difíciles de obtener para este segmento empresarial. Para desarrollar el proyecto, e impulsar el uso de software libre, se utilizó la distribución Ubuntu Linux en su versión 12.04 como sistema operativo para desarrollo y funcionamiento del sistema. Como lenguaje de desarrollo se utilizó el lenguaje de programación Java, ya que posee la característica de ser independiente de la arquitectura de hardware, es un lenguaje multiplataforma, robusto, ligero y de código libre, por lo que es un lenguaje idóneo para el desarrollo en sistemas Linux. Los resultados obtenidos desde la implantación de la aplicación durante el período de pruebas entregaron datos concretos respecto al uso de los recursos telefónicos de la empresa en la que se testeó la aplicación, siendo de gran utilidad para el monitoreo y seguimiento de las llamadas realizadas. Abstract This thesis is developed in order to generate a solution that would allow a clear measure of consumption generated telephone through a PBX between the various extensions that make up a small and medium enterprise using open source tools for development, with order that can be downloaded and installed without purchasing expensive licenses, which are difficult to obtain for this business segment. To develop the project, and promote the use of free software, the Ubuntu Linux distribution in Release 12.04 operating system was used for development and operation of the system. As development language used the Java programming language, since it has the property of being independent of the hardware architecture, is a cross-platform language, sturdy, lightweight, open source, making it an ideal language for development Linux systems. The results obtained from the implementation of the application during the test period gave specific data regarding the use of resources of the phone company you are testing the application, being very useful for monitoring and follow-up calls. 1. Introducción En el ámbito de las comunicaciones, la telefonía tiene un rol importante para las personas, las pequeñas y grandes empresas. Para estos dos últimos segmentos, es común encontrar equipamiento destinado a gestionar, administrar los recursos telefónicos y distribuirlos de forma eficiente a través de la empresa, él cual es llamado de forma común Central Telefónica Privada o PBX (Private Branch Exchange). Debido al alto tráfico de llamadas que pueden generarse a través de una central telefónica, nace la necesidad de tener un control del recurso de las comunicaciones para asegurar una buena utilización. Para este fin, existen varias aplicaciones comerciales que permiten generar informes que entregan a la gerencia los datos necesarios para tomar medidas respecto al uso de este recurso, las cuales tienen costos elevados de licencia y puesta en marcha, los cuales no pueden ser costeados por las pequeñas empresas, las cuales ante el tamaño de la inversión prefieren prescindir de este tipo de aplicaciones. Este proyecto propone desarrollar una aplicación que permita efectuar análisis del tráfico telefónico de licencia gratuita, utilizando herramientas de código abierto y que tengan las funcionalidades necesarias para entregar 1 estadísticas de consumo, entregando al segmento de las pequeñas empresas, una herramienta que les permita tomar decisiones sobre el uso de sus recursos de comunicaciones. Debido a como se estructurará este proyecto, se utilizará la metodología de desarrollo de software por etapas, debido a que cada objetivo específico es una etapa o módulo del sistema que debe ser desarrollado, probado e integrado al siguiente módulo una vez que se demuestra que funciona correctamente. Las pruebas se realizan sucesivamente hasta tener el resultado final. En este documento se comenzará por describir la problemática que generó la necesidad de implementar esta solución informática, esfuerzos realizados con anterioridad y una visión del problema sin mejoras junto con su respectiva propuesta de mejoramiento. Se dedicará un capítulo a modo de introducción a las telecomunicaciones con el fin de entregar la información necesaria para comprender el desarrollo y los distintos módulos del proyecto. Se describirá la metodología a utilizar a través del desarrollo del proyecto, así como también se expondrá las tecnologías de Hardware y Software para su desarrollo. 2 2. Objetivos 2.1. Objetivo general Desarrollar una aplicación que permita analizar el tráfico telefónico generado por una Central telefónica, que tenga las características de código abierto, por tanto gratuita y de libre distribución. 2.2. Objetivos específicos • Diseñar una interfaz que permita obtener la información del tráfico telefónico desde la central telefónica hacia el computador. • Crear un módulo que permita grabar los datos obtenidos desde la central telefónica hacia una base de datos en tiempo real. • Generar reportes estadísticos en base a la recolección de datos del analizador, de acuerdo a los siguientes criterios: - El número de extensión desde el cual se realiza una llamada. - Rango de fecha en el que se realizan las llamadas. - Informe mensual de todas las llamadas realizadas. 3 - Informe semanal de todas las llamadas realizadas. - Informe de llamadas realizadas comparándolas con una base de datos de números de llamado frecuente en la empresa. 4 3. Planteamiento del Problema 3.1. Antecedentes 3.1.1. Definición del problema El consumo telefónico que una empresa promedio genera en un período determinado se vuelve difícil de cuantificar debido a la alta demanda que tienen los sistemas de telefonía; esta demanda significa, por ejemplo, la alta utilización del teléfono para la gestión comunicacional de las empresas (del total de costos administrativos el consumo telefónico corresponde a cerca del 35%). Sin embargo, algunas de las llamadas realizadas son de carácter personal de quién las realiza y por lo tanto, no son parte de la gestión empresarial. Si bien, las llamadas del tipo personal son necesarias para el bienestar de los empleados, el uso racional de este recurso no siempre es efectivo (llamadas fuera de horario, de muy larga duración, a números de autoayuda, etc). El estudio del consumo telefónico está orientado, entre otras cosas, a disminuir el mal uso del recurso y para ello bien se puede utilizar alguna de las herramientas informáticas disponibles. Ahora bien, como son de tipo comercial 5 y de costos que empresas promedio o Pymes no estan en condiciones de pagar las marginan de la posibilidad de determinar si existe uso fraudulento o simplemente negligente del servicio de comunicación. 3.1.2. Esfuerzos anteriores Al realizar un estudio respecto al tema del análisis del tráfico telefónico gratuito, Timofómetro1 es una aplicación de código abierto que permite llevar la cuenta de las llamadas de una línea específica de forma directa sin pasar por una central telefónica. 3.1.3. Solución propuesta Se propone realizar un analizador de tráfico telefónico capaz de realizar análisis estadísticos del consumo telefónico efectuado. Para efectuar el análisis del consumo, debe ser factible capturar los datos desde la central telefónica hacia un dispositivo que tenga la capacidad de interpretarlos. En este caso la central debe tener la facilidad de entregar estos datos a través de 1 Disponible en: http://timofometro.softbull.com 6 una tarjeta adicional instalada que entrega esta información hacia un equipo a través de su puerto serial. El proyecto pretende almacenar esta información en una base de datos con el fin de poder realizar el manejo estadístico para llevar un control de tráfico y elaborando informes de acuerdo a criterios específicos como: - Llamadas por Extensión. - Llamadas por Línea. - Estadística de duración de llamadas. - Comparación de consumo entre períodos determinados por el usuario. - Comparación de las llamadas realizadas y una base de datos de llamados frecuentes de la empresa. Para el desarrollo del proyecto, se aplicarán los conocimientos adquiridos al trabajar en el rubro de las telecomunicaciones en conjunto con la electrónica simple para la construcción de los medios de comunicación entre hardware y computador. 7 3.2. Justificación Este proyecto surge de la necesidad por parte de pequeñas empresas de conocer la forma en la que se utilizan los recursos de comunicaciones, en este caso orientado al recurso telefónico, en las pequeñas empresas. Esta necesidad actualmente está cubierta por aplicaciones comerciales las cuales tienen costos elevados y son difíciles de financiar para las pequeñas empresas, por otro lado, en la actualidad no existe una aplicación de este tipo en la categoría del software libre, debido a esto, es interesante sentar las bases para el desarrollo de una aplicación con estas características. Actualmente, existen 2 estrategias para llevar un control del consumo telefónico: - Mediante software comercial que realiza la tarea de capturar las llamadas desde la central hacia el computador mediante protocolo serial. - Solicitar a las empresas telefónicas un resumen de las llamadas realizadas mensualmente, pero en este caso no se puede determinar qué extensiones fueron las que realizaron las llamadas. Ambas alternativas son comerciales y suponen un gasto adicional asociado a los costos de administración de una empresa. 8 El desarrollo de este proyecto podría beneficiar a aquellas empresas que no estén en condiciones de adquirir un software comercial, el cual tiene un costo de 22,86 UF, equivalentes a $483.328 (referencia OVERCall Empresas, hasta 120 anexos), en caso de que el sistema sea instalado en la ciudad de Puerto Montt tiene un costo de 45,86 UF, equivalentes a $969.617. El sistema desarrollado en este proyecto aportará datos concretos para hacer estudios de consumo, reducción de costo en llamadas innecesarias, así como también evaluar si los recursos disponibles, vale decir troncales o líneas contratadas, número de extensión, son suficientes o exceden las necesidades de la empresa o cliente final. 9 3.3. Delimitación El proyecto estará limitado a analizar el tráfico de centrales mediante el protocolo serial, limitándose a algunos modelos de centrales telefónicas. Otra limitación son las centrales IP o de nueva generación como son las centrales Alcatel modelos OXO, OXE y derivados debido a que esta marca está trabajando en su propio sistema de tarificación interno. 10 4. Metodología La metodología de Desarrollo que se utilizará para desarrollar la aplicación es la Metodología de desarrollo por etapas, como se menciona anteriormente debido a que cada módulo de la aplicación es una etapa que debe desarrollarse y realizar pruebas de funcionamiento aislado hasta que tenga un funcionamiento óptimo antes de pasar a la siguiente etapa, con la cual se integra cuando la última ha pasado por su propio período de pruebas. Además, cada etapa del desarrollo se define por las siguientes etapas definidas a continuación: Plan operativo Etapa en la cual se define el problema a resolver, las metas del proyecto y se identifica cualquier restricción aplicable al proyecto de desarrollo. Especificación de requerimientos Etapa en la que se puede dar una visión sobre el alcance del proyecto, exponiendo el problema desde el punto de vista Cliente-Desarrollador. Aquí puede considerarse la posibilidad de una planificación de los recursos sobre una escala de tiempos. 11 Especificación funcional Etapa en la cual se define la información que el software a desarrollar trabajará. Diseño Etapa en la que se describe cómo el sistema a desarrollar va a satisfacer los requerimientos planteados. Los niveles más altos de detalle generalmente describen los componentes o módulos que formarán el software a ser producido. Los niveles más bajos, describen, con mucho detalle, cada módulo que contendrá el sistema. Implementación Etapa en la cual el software empieza a codificarse. En esta etapa se desarrolla cada módulo y se prueban de forma independiente constatando su buen funcionamiento Integración Etapa en la cual los módulos desarrollados independientemente son probados en conjunto Este proceso se repite hasta que se han agregado todos los módulos y el sistema se prueba como un todo. 12 Validación y verificación Esta etapa comienza cuando todos los módulos del sistema ya han sido integrados. Por otro lado, la verificación consiste en una serie de actividades que aseguran que el software implementa correctamente una función específica. Al finalizar esta etapa, el sistema ya puede ser instalado en ambiente de explotación. Mantención Esta etapa sólo es necesaria en caso de que se detectase algún problema dentro de un sistema existente, los cuales no fueron detectados en la fase de pruebas. También pueden ser actualizaciones y mejoras para el sistema ya existente o cambios que respondan a nuevos requerimientos. Las mantenciones se pueden clasificar en: correctiva, adaptativa, perfectiva y preventivas. 13 5. Recursos 5.1. Hardware Laboratorio de pruebas equipado con 3 centrales: NitsukoTX-Z 308, Panasonic TDA-100, Panasonic KX-TA 308. o Cable serial RS232. o Central Telefónica o Tarjeta de expansión que permiten la captura de datos desde la central hacia el equipo. o Adaptador Prolific UsbSerial. 5.2. Software o Notebook Acer Aspire 4817Z − Procesador: Geniune Intel® CPU U2700 1.30GHZ. − Memoria RAM: 2048 MB. − Disco duro: 500 GB SATA, 7200 PRM. − Adaptador de RED: LAN 100Mbps; WLAN 802.5 b/g. 14 − Adaptador de video: Mobile Intel(R) 965 Express Chipset Family. o Distribución Linux Ubuntu 12.04 o Lenguaje de programación Java. o Motor de base de datos MySQL. o MySQL Workbench para el modelamiento de la base de datos. o Visio 2007 para realizar esquemas y figuras. o Java Development KIT (JDK) versión 6 para el desarrollo de la aplicación java. o NetBeans 7.2 como entorno de desarrollo. 15 6. Introducción a la telefonía. 6.1. Centrales Telefónicas. Se define como central telefónica al punto central donde se reúnen todos los aparatos telefónicos de una determinada área, que se denomina “área local” o “área central”. Las centrales telefónicas se dividen en 2 tipos: 6.1.1. Central telefónica pública. Cumple la función de establecer comunicación entre nodos distantes. Este tipo de centrales son de gran tamaño, llegan a ocupar edificios completos y son utilizadas para enlazar las comunicaciones de ciudades, regiones y países a través de enlaces de fibra óptica entre ellas. De forma general, este tipo de centrales se puede clasificar en: • Centrales de conmutación local: Este tipo de centrales atiende a abonados2 finales, y posee conexión con la red de acceso fija. La conexión entre dos abonados conectados a la misma central se realiza en forma local. 2 Cualquier persona física o jurídica que contrate con un proveedor de servicios de comunicaciones. 16 La conexión entre un abonado de una central local y otro abonado de otra central local se realiza por medio de la red de transmisión y transporte. • Centrales de tránsito: Son centrales telefónicas que interconectan otras centrales locales, o internacionales, pero que no tienen abonados finales directamente conectados. • Centrales Internacionales: Son las centrales de tránsito que conectan enlaces internacionales. • Centrales celulares: Son las que prestan servicios de conmutación a abonados celulares. En la siguiente imagen se muestra una central metropolitana: Figura 1: Trama de distribución de una central metropolitana3 3 Imagen copiada desde http://es.wikitel.info/w/images/7/7a/2056984143_62550e8be4.jpg 17 6.1.2. Central telefónica privada. Cumple la función de establecer comunicación dentro de una empresa, gestionar sus recursos telefónicos, permitiendo comunicación directa entre los departamentos a través de numeración interna y ahorrando los costos que pudiesen implicar contratar una gran cantidad de líneas externas4 para mantener a cada uno de los departamentos y usuarios comunicados con el exterior, debido a que puede derivar llamadas entrantes y salientes entre los distintos departamentos y la utilización de una o más líneas externas, las cuales al igual que la numeración interna, pueden ser derivadas a los distintos departamentos o usuarios de la empresa. En la siguiente figura, se muestra un ejemplo de como una central telefónica privada distribuye los recursos telefónicos en una empresa: 4 Se define como la numeración pública, que puede ser contratada a cualquier compañía telefónica 18 Nº Extensión [11] Usuario 2 Nº Extensión [10] Usuario 1 Línea Línea Externa 1 Externa 2 Nº Extensión [15] Usuario 6 Nº Extensión [12] Usuario 3 Central Telefónica Nº Extensión [13] Usuario 4 Nº Extensión [14] Usuario 5 Figura 2: Esquema Central telefónica privada 19 6.1.3. Descripción de centrales telefónicas privadas utilizadas en el proyecto. a) Descripción Central Telefónica Nitsuko- TX-Z La central Nitsuko TX-Z es una central telefónica que data de los años 90. Este tipo de centrales se pueden encontrar en pequeñas empresas, debido a que es una central económica y entrega un servicio básico de comunicación interna y externa. En su versión básica, cuenta con la capacidad de conectar 8 extensiones y 3 líneas externas, lo que hace que esta central sea una opción apetecida por pequeñas empresas que están iniciando actividades, desean tener sus oficinas y unidades comunicadas internamente como hacia el exterior. A continuación, se muestra un esquema de la arquitectura de una central Nitsuko TX-Z Serie: 20 Figura 3: Arquitectura Nitsuko TXZ Series Esta central cuenta con una puerta DB-95, la cual debe ser configurada para que imprima la información de las llamadas. Para realizar esta programación, es preciso contar con un teléfono multi-línea modelo 6TD/6TXD/12TD/12TXD ó 6BTD/6BTXD/12BTD/12BTXD, el cual presentan en las siguientes figuras: 5 Conector de 9 pines 21 Figura 4: Teléfono Multi-Línea modelo 6TD76TXD/12TD/12TXD 22 Figura 5: Teléfono Multi-Línea modelo 6BTD/6BTXD/12BTD/12BTXD Esta debe ser activada de la siguiente forma: 1. (En condición colgado) Presione OPAC 2. Digite # * # * 3. Digite la Clave de Acceso (Máx. 8 dígitos) 3. Presione HOLD. 4. Ingresar al programa 057 A continuación, se presenta una tabla con las opciones para configurar la salida SMDR: 23 Indicación del Visor CONFIG.SMDR #057-IT-X Datos a Ingresar Inicial IT. N_ de Item (1 - 9) Item1 Cantidad Mínima de Dígitos Marcados 0: Deshabilitado *Todas las llamadas salientes se imprimen. 1: Habilitado *Las llamadas salientes se imprimen si el número marcado tiene más dígitos que la cantidad asignada en el Programa #059. Item2 Llamadas Transferidas (Entrantes/Salientes) 0: Imprime 1: No imprime Item3 Llamadas No Contestadas 0: Imprime 1: No imprime Item4 Llamadas Entrantes 0: Imprime 1: Imprime sólo si ingresa código de cuenta Item5 Intento de Llamada Restringida 0: Imprime 1: No imprime Item6 Código de Cuenta para Tel. Convencional 0: Habilitado 1: Deshabilitado Item7 Número Marcado 0: Imprime 1: No imprime Item8 Datos de Caller-ID 0: No imprime 1: Imprime n° telefónico 2: Imprime nombre 3: Imprime nombre o n° telefónico (el nombre tiene prioridad sobre el n°) Item9 Cantidad de Dígitos Enmascarados 0: Deshabilitado 1-9: Cantidad Item1: Item2: Item3: Item4: Item5: 0 1 0 0 1 Item6: Item7: Item8: Item9: 1 1 0 0 Tabla1: Programa 57 Nitsuko Serie TX-Z 24 b) Descripción Central Telefónica Panasonic KX-TA 308 La central telefónica Panasonic KX-TA 308 es una central de similares características que la Nitsuko TX-Z Serie: cuenta con la capacidad para conectar 8 extensiones y 3 líneas, pero puede ser ampliada mediante tarjetas de expansión hasta 24 extensiones y 6 líneas. Además, tiene facilidades de operadora automática (DISA6) los cuales pueden ser activados a través de una tarjeta de expansión para dar mayor flexibilidad al momento de establecer contacto con la empresa. En el siguiente diagrama se muestra como funciona el sistema DISA o contestadora automática: Figura 6: Esquema de funcionamiento DISA. 6 DISA: Acceso Directo al Sistema. 25 A continuación, se presenta un esquema de la arquitectura de la central Panasonic KX-TA 308: Figura 7: Arquitectura Panasonic KX-TA 308 Esta central cuenta con una puerta DB-9, la cual debe ser configurada para que imprima la información de las llamadas. Para realizar esta programación, es preciso contar con un teléfono multi-línea modelo KX-T7330 en la posición Jack1. La siguiente imagen es la plantilla de controles para la programación de la central: 26 Figura 8: Cartilla de controles para la programación Panasonic KX-TA 308 Pulsar botón “Program”. Pulsar secuencia * #. Introducir contraseña del sistema. Ingresar al programa 800 y seguir la siguiente secuencia: 27 Figura 9: Asigna los parámetros de comunicación para la Interfaz Serial (RS232C)7 Código NL: Selecciona el código para su impresora o computadora personal. Si su impresora o computadora personal avanza líneas automáticamente con un retorno del carro, seleccione “CR”. Si no, seleccione “CR+LF”. * Selección: Mark (Marca)/Space (Espacio)/Even (Par)/Odd (Impar)/None (Ninguno) Establecer ancho de página en programa 801: Figura 10:Asigna los parámetros ancho de página8 7 8 Extraído del manual de Instalación Panasonic KX_TA 308/616 Extraído del manual de Instalación Panasonic KX_TA 308/616 28 Establecer impresión de llamadas en programa 802. Figura 11: Asignación de impresión de las llamadas9 c) Descripción Central Telefónica Panasonic TDA100/200 La central Panasonic TDA100/200 es una central de última tecnología orientado a empresas medianas y grandes. Cuenta con capacidad hasta 64 extensiones y 64 líneas externas. Esta capacidad puede ser ampliada debido a que se utilizan tarjetas de expansión para aumentar las capacidades de la central. Cuenta además, con las facilidades para utilizar telefonía IP y E110. Esta central trae parámetros predefinidos para imprimir el detalle de las llamadas los cuáles son: Baudios: 19200 Longitud de palabra: 8 bits. Paridad: Ninguna Bit de parada: 1 bit. Esta configuración puede ser cambiada en el programa 800 a través de un teléfono multi-línea KX-T7330 siguiendo el mismo procedimiento de una Panasonic KX-TA 308. 9 Extraído del manual de Instalación Panasonic KX-TA 308/616. Enlace de 30 canales de voz. 10 29 A continuación se muestra la imagen de como se ve una central Panasonic TDA100: Figura 12: Central TDA100 6.2. Procesos para la realización de una llamada. Cuando un usuario realiza una llamada desde su número de extensión “A” hacia una extensión “B” se realiza la siguiente secuencia para cursarla: • La llamada realizada por la extensión A y la transmisión de la información, es dada por el tono de marcado. • Con la información recibida se realiza la elaboración de la señal y se la almacena en la central. • Conexión de enlace de la extensión central • Señalización enviada a una o varias centrales. • La supervisión del enlace establecido. 30 • Desconexión del enlace luego de culminar la comunicación. Las centrales telefónicas se encuentran divididas en dos unidades: Unidad de control y Unidad de Conmutación, tal como se indican en la figura 13. Figura 13: Comunicación entre extensiones 31 7. Desarrollo de la aplicación. En esta etapa se han de seguir las actividades incluidas en la metodología elegida, por tanto, de acuerdo a la Metodología de desarrollo por etapas se desarrollará la aplicación en el siguiente orden: • Plan operativo. • Especificación de requisitos. • Especificación funcional. • Diseño. • Implementación. • Integración. • Validación y verificación. • Mantenimiento. 7.1. Plan Operativo En la actualidad, no existe en el campo del software de código abierto una aplicación que permita realizar un seguimiento o análisis del tráfico generado por una central telefónica privada. Por el contrario, las aplicaciones 32 de este tipo son comerciales, de licencias costosas y por lo tanto, difíciles de adquirir por segmentos empresariales pequeños. La meta fue desarrollar una aplicación de código abierto que permita realizar, en primera instancia, un análisis básico del tráfico telefónico generado, limitando el campo de las centrales privadas a 3 modelos de centrales telefónicas privadas: Nitsuko TX-Z 308, Panasonic TDA-100, Panasonic KX-TA 308. Estas centrales se encuentran en el laboratorio de pruebas del alumno y cuentan con el hardware de expansión necesarios para entregar reportes en modo texto de las llamadas realizadas. Además, estas centrales telefónicas privadas cuentan con un puerto RS-232 desde el cual se obtiene la información de las llamadas realizadas, y por lo tanto, al segmento de centrales telefónicas privadas al que se orientó esta aplicación. 7.2. Especificación de los requisitos Para obtener los requisitos realizaron para la aplicación a desarrollar, se pruebas de campo utilizando dos aplicaciones tarificadores comerciales: Wintariff y Overcall Small, ambos en su versión de prueba limitando el número de capturas que se pueden obtener de una central 33 telefónica privada. A continuación, se presenta una captura de pantalla de la aplicación Wintariff: Figura 14: Software Tarificador Wintariff11. 11 Aplicación desarrollada por PBX Software 34 La siguiente imagen es una captura de la aplicación Overcall Small: Figura 15: Overcall Small A partir de estas dos aplicaciones se realizaron diversas capturas y filtros para determinar como funciona la aplicación y cuál es la información relevante que un usuario final pudiese necesitar obtener del tráfico generado por su central telefónica. Debido a que ambas aplicaciones no tienen la funcionalidad de entregar reportes pre-establecidos, sino que entrega al usuario las herramientas para generar sus propios reportes según sus necesidades, resulta complicado para un usuario inexperto obtener un reporte con la información necesaria. Por esta razón, se realizó un listado con los 35 reportes que deberá generar la aplicación para entregar esta información, los cuales se listan a continuación: - El número de extensión desde el cual se realiza una llamada. - Rango de fecha en el que se realizan las llamadas. - Informe mensual de todas las llamadas realizadas. - Informe semanal de todas las llamadas realizadas. - Informe de llamadas realizadas comparándolas con una base de datos de números de llamado frecuente en la empresa. 36 7.3. Especificación funcional El siguiente diagrama refleja el diseño completo de la aplicación: Central telefónica privada Reporte por Extensión Módulo de Generación de reportes Reporte por Línea Externa Equipo Servidor Aplicación Ubuntu 12.04 Escritura de información en base de datos Módulo de Captura Serial siempre a la escucha de información Reporte estadístico de la duración de las llamadas. Módulo de traspaso de la captura hacia base de datos siempre a la escucha de información Reporte por números frecuentes de la empresa Reporte por período de tiempo (Diario, mensual) Figura 16: Diagrama de la aplicación El desarrollo de la aplicación se planificó en 3 etapas. Cada una de estas etapas es un módulo del sistema, las cuales se definen a continuación: 37 El siguiente esquema representa el diseño de la primera etapa de la aplicación, la cual corresponde al módulo de captura de datos: Figura 17: Esquema módulo captura serial El siguiente es el esquema de la segunda etapa de la aplicación, el módulo traspaso de la captura hacia la base de datos: Figura 18: Esquema módulo traspaso de la captura serial a la base de datos. 38 El siguiente es el esquema de la tercera etapa de la aplicación, el módulo de generación de reportes. Figura 19: Esquema módulo de generación de reportes En el capítulo del desarrollo, estas etapas serán explicadas de forma detallada. 39 Para el desarrollo de la aplicación, se realizó un estudio para determinar el lenguaje apropiado. Al tratarse de una aplicación de código abierto se propusieron 3 lenguajes como opciones para el desarrollo: • Lenguaje de programación C. • Lenguaje de programación PHP. • Lenguaje de programación Java. Como primera opción, el lenguaje de programación C, es el lenguaje utilizado por excelencia para el desarrollo de aplicaciones de código abierto, es un lenguaje fuertemente tipificado de medio nivel pero con muchas características de bajo nivel, y es el lenguaje en el que está programado el sistema operativo GNU12 Linux. A pesar de que en este leguaje existen librerías que hacen posible la lectura del puerto serial, la programación y puesta en marcha es de larga duración. Además, el lenguaje propiamente tal no soporta la programación orientada a objetos, y se debe recurrir a la extensión del lenguaje, C++, para este fin. Sin embargo, al cambiar el lenguaje se pierde el sentido de la aplicación, que es desarrollarla con herramientas de código libre y se descarta este lenguaje para desarrollar la aplicación. 12 GNU: General Public License. 40 La segunda opción, el lenguaje PHP13, un lenguaje de programación orientado al lado del servidor, es uno de los primeros lenguajes de programación orientado a la web14 que permite interacción entre su contenido almacenado en una base de datos. Si bien, se consideraba interesante realizar una aplicación basado en web, la programación orientada a objetos se estaba explorando de forma reciente en el lenguaje y además, las librerías de interacción entre PHP y el puerto serial, php-serial, no estaban disponible en una versión estable al momento del desarrollo de la aplicación por lo que se descartó la idea de utilizar este lenguaje. Como última opción, el lenguaje Java, es un lenguaje de alto nivel orientado a objetos, robusto y de código abierto. Además, posee librerías de interacción base de datos y con el puerto serial estable, las cuales han sido utilizadas en diversas aplicaciones, demostrando la estabilidad de éstas. Un ejemplo de aplicación que utiliza estas librerías es una aplicación de lectura Biométrica implementada por Banco de Chile, la cual a través de una pistola lectora de código de barra con puerto serial, lee el código de barra de la cédula de identidad y entrega los datos asociados a la persona en pantalla. Teniendo estos antecedentes, se tomó la decisión de adoptar el lenguaje de programación Java para el desarrollo de la aplicación. 13 14 PHP: PHP Hypertext Pre-Processor Web: World Wide Web 41 Como entorno de desarrollo se comenzó a trabajar con el entorno de desarrollo Eclipse en su versión Helios SR1, pero fue descartado después de las pruebas de interfaz no gráfica de la captura serial, debido a que no fue posible utilizar herramientas para realizar la interfaz gráfica. Se realizó el cambio de entorno a NetBeans versión 7.2 que ofrecía las herramientas necesarias para llevar a cabo el proyecto. Finalmente, se utilizará Java Development Kit versión 6 como herramienta de desarrollo para la aplicación. 42 7.4. Diseño. 7.4.1. Diagrama de clases A continuación, se expone el diagrama de clases de la aplicación Figura 20: Diagrama de clases esquema completo En las siguientes figuras se muestran con detalles cada una de las clases del diagrama: 43 Figura 21: Diagrama de clases, parte 1 44 Figura 22: Diagrama de clases, parte 2 45 Figura 23: Diagrama de clases, parte 3 46 Definición de las clases y sus métodos principales El proyecto se dividió en dos package para separar los métodos de la captura del puerto serial con la interfaz de usuario. Los package son lpbxcapture y lpbxMainForm. A continuación, se explican las clases del package lpbxcapture: CaptureC: Clase que realiza la escucha del puerto serial. Esta clase configura la lectura del puerto una vez que recibe los parámetros desde la clase SerialC: Puerto serial, Baudios, Bits de Datos, Bits de Parada y Paridad. Se establece la conexión una vez se haya comprobado que el puerto seleccionado este libre y abre el buffer de lectura de datos. A continuación, se describen sus métodos principales: OpenSerialCapture() throws SerialConnectionException : es el método encargado de abrir el buffer de lectura para el puerto serial y mostrar los datos en pantalla a través del cuadro de texto. CloseSerialCapture(): método encargado de cerrar el buffer de lectura del puerto serial 47 SerialC: Clase de la interfaz gráfica para el manejo de la lectura de datos desde el puerto serial hacia el computador. Es la clase encargada de enviar los parámetros: Puerto serial, Baudios, Bits de Datos, Bits de Parada y Paridad para abrir el puerto serial. Estos datos son obtenidos desde la base de datos y se pueblan en los combobox del módulo. A continuación se describen sus métodos principales: Btn_InitCapture(java.awt.event.ActionEvent evt): En este metodo se envian los datos de configuración del puerto serial y el área de texto en donde serán visibles los datos de la captura. SetParams(): Este método asigna los parámetros para iniciar la captura del puerto serial. SerialConectionException: Clase que realiza el manejo de excepciones del puerto serial es una extensión de la clase Exception. Como se mencionó en la referencia de la librería RXTX, al ser una librería que se basa en el mismo JDK, reutiliza herramientas de esta para sus propios manejos de excepciones. PortRequestDialog: Clase que maneja los diálogos para el requerimiento del puerto serial. La interfaz gráfica se basa en el modelo de ejemplo de captura serial del ejemplo contenido en la librería comm3.0 SerialDemo y se toman dos clases de este ejemplo para el proyecto: SerialConectionException y PortRequestDialog. 48 A continuación, se explican las clases del package lpbxMainForm. En la siguiente tabla se listan las clases que componen los formularios de la aplicación, los cuales son la interfaz visual de la aplicación: Formulario Descripción BusinessNumberForm Formulario de ingreso de los números frecuentes de la empresa BusinessReportForm Formulario para generar reportes de las llamadas a números frecuentes de la empresa ExtensionReportForm Formulario para generar reportes de las llamadas que realizan las extensiones. LineReportForm Formulario para generar reportes de las llamadas que realizan las líneas. MainForm Formulario principal de la aplicación TablaForm Formulario que contiene la tabla con los datos capturados desde la central telefónica. DurationCallReport Formulario para generar reportes de la duración de las llamadas. PBX_ConfigForm Formulario para realizar la configuración del modelo de la central telefónica. 49 Además, se explican los métodos principales para la obtención de datos para generar los reportes: ReportDataAcces: Clase que contiene los métodos encargados de las consultas a la base de datos para generar los reportes de la aplicación. ModeloTablaPBX: clase que contiene el modelo de datos para la tabla que muestra los datos de la captura. DataPBXClass: clase que maneja los datos que son ingresados en la Tabla de datos que contiene la información de las llamadas realizadas desde la central telefónica. ControlTabla: clase que maneja los métodos para insertar y eliminar registros de la tabla contiene la información de las llamadas realizadas desde la central telefónica. Aunque el método borrarFila() no está implementado, se declara para alguna futura implementación. 50 7.4.2. Diseño de la base de datos a) Diseño conceptual de la base de datos El siguiente diagrama corresponde al modelo conceptual de la base de datos, reflejado en el modelo entidad relación: Figura 24: Diagrama conceptual de la base de datos 51 La siguiente tabla muestra las Entidades, sus relaciones y cardinalidad: Nombre Tiene Esta Entidad 1 Entidad 2 PBX_Business PBX_Client Number Number PBX_Client PBX_Data Number Table Tabla 2: Entidad y cardinalidad 52 E-1 -> E-2 E2 -> E-1 Card. Card. 1,n 1,1 1,n 0,1 b) Diseño lógico de la base de datos La figura a continuación, corresponde al diseño lógico de la base de datos: Figura 25: Diseño lógico de la base de datos 53 c) Diseño físico de la base de datos La figura a continuación, corresponde al diseño físico de la base de datos: Figura 26: Diseño físico de la base de datos 54 Se definen a continuación las 3 tablas definidas para almacenar datos referentes a la central telefónica: Nombre Descripción PBX_DateTable Tabla que almacena los datos enviados desde la central telefónica. PBX_BusinessNumber Tabla que almacena la información de los clientes que posee la empresa. PBX_ClientPhone Tabla que almacena los números telefónicos de uso frecuente en la empresa. Tabla 3: Tablas de almacenamiento de información PBX. Además, se definieron 5 tablas para almacenar datos estáticos, por lo cual no tienen relación entre si, para la configuración de la aplicación. Estas tablas se definen a continuación: 55 Definición de tablas de datos para los parámetros del puerto serial: Nombre Descripción Tabla que almacena los valores de las SerialParameters_BAUD velocidades en baudios del módulo del puerto serial Tabla que almacena los valores de los bits de datos del módulo del SerialParameters_DATABIT puerto serial Tabla que almacena los valores de los Bits de parada SerialParameters_STOPBIT del módulo del puerto serial Tabla que almacena los valores de las paridades del módulo del puerto SerialParameters_PARITY serial Tabla 4: Tabla de Configuración modelo central telefónica. 56 A continuación, se define la información que contienen las tablas para la configuración del puerto serial: SerialParameters_BAUD (INT) 300 2400 9600 14400 19200 38400 57600 152000 Tabla 5: Tabla contenido SerialParameters_BAUD SerialParameters_DATABIT (INT) 5 6 7 8 Tabla 6: Tabla contenido SerialParameters_DATABIT 57 SerialParameters_STOPBIT(INT) 1 2 Tabla 7: Tabla contenido SerialParameters_STOPBIT SerialParameters_PARITY(INT) None Odd Even Mark Space Tabla 8: Tabla contenido SerialParameters_PARITY El script para generar la base de datos se puede encontrar en el Anexo E del documento. 58 7.5. Implementación. Debido a que el diseño global fue descrito en el capítulo anterior, no se describirán en las etapas del desarrollo. 7.5.1. Etapa 1: Captura a través de puerto serial Para esta etapa del desarrollo, no es necesario describir la fase de integración de este módulo debido a que es el primero en desarrollarse y por lo tanto, no existe un módulo al cual integrarse. 7.5.1.1. Plan Operativo. Para que la aplicación pueda obtener la información necesaria para poder realizar los análisis se requirió el desarrollo de un módulo capaz de leer los datos desde el puerto serial de la central telefónica hacia el computador servidor. 59 7.5.1.2. Especificación de los requisitos. Los requisitos necesarios en esta etapa fueron los siguientes: - Central telefónica con puerto serial y la capacidad de imprimir las llamadas realizadas a través de él. - Cable de transmisión serial. - Computador con puerto serial. - Librería para la lectura del puerto serial. El cable serial fue construido siguiendo el siguiente mapa de asignación de pines: Sistema Impresora/PC Tipo de Circuito (EIA) Tipo de señal Número de contacto BB RXD 2 BA TXD 3 CD DTR 4 AB SG 5 CC DSR 6 CA RTS 7 CB CTS 8 Tipo de señal contacto BB RXD 2 BA TXD 3 CD DTR 4 AB SG 5 CC DSR 6 CA RTS 7 CB CTS 8 Tabla 9: Asignación de pines cable serial RS-232 60 Número de Tipo de Circuito (EIA) En la siguiente tabla se definen las señales y los tipos de circuitos: Nº Nombre Tipo circuito Función de Señal EIA CCITT 2 RD (RXD) Recibir datos BB 104 3 SD (TXD) Transmitir datos BA 103 4 ER (DTR) Terminal de datos CD preparado 108.2 5 SG AB 102 6 DR (DSR) Conjunto de datos CC preparado 107 7 RS (RTS) Petición de envío CA 105 8 CS (CTS) Cancelar envío CB 106 Masa de la señal Tabla 10: Asignación de pines. 61 El cable serial queda de la siguiente forma: Figura 27: Cable serial RS232 Hembra Debido a que los computadores actuales no cuentan con puertos seriales integrados a ellos, se utilizará un cable adaptador Prolific USB- Serial. Figura 28: Cable USB-Serial 62 7.5.1.3. Especificación funcional. En esta etapa se estudiaron dos librerías que cumplían la función de realizar operaciones a través de puerto serial en Java. a) Javacomm. Java Communications 3.0 API es una librería desarrollada y mantenida por Oracle. Entrega facilidades para trabajar con los puertos RS232 bajo plataformas Solaris SPARC, Solaris x86 y Linux x86. Como se enumera en el sitio Oracle15, las funcionalidades de esta librería son: • Enumeración de los puertos seriales disponibles en el equipo (Los puertos pueden ser asignados de forma fija en el programa o asignados por el usuario). • Configuración del puerto (velocidad de transmisión, velocidad, bits de parada, paridad). • Acceso a DTR EIA232 estándar, CD, CTS, RTS y señales DSR. • Transferencia de datos a través de puertos RS-232. • Opciones de configurar Hardware y control de flujo. • Recibe señales del buffer de control threshold. • Opción de eventos asíncronos para la notificación de: 15 www.oracle.com 63 ▪ Disponibilidad de un puerto RS-232. ▪ Cambios de línea a nivel de hardware de los puertos. ▪ Propiedad de cambiar los puertos dentro de una JVM. Instalación de la librería. Se inició el proyecto utilizando esta librería la cual comenzó operando con algunas dificultades como el hecho de tener que definir el controlador del puerto serial para el sistema operativo en el cual se estuviese desarrollando, en este caso Linux, para lo cual se realiza la copia de los archivos: libLinuxSerialParallel.so al directorio /usr/lib comm.jar al directorio jre/lib/ext/ Después de realizar estas modificaciones, se procedió a realizar pruebas de detección de puertos seriales, encontrándose con problemas de compilación acusando la falta del siguiente archivo: javax.comm.properties en el directorio jre/lib/ Este último archivo no se encontraba en la primera versión descargada, por lo cual fue creado manualmente y se realizaron las modificaciones para indicar el Sistema operativo desde el cual se estaba trabajando, en este caso Linux Ubuntu 12.04, editando el archivo y dejando el siguiente cambio: driver=com.sun.comm.LinuxDriver 64 Luego de realizada la inclusión del archivo faltante se procedió a compilar un ejemplo básico de detección de puertos seriales presentes en el equipo. El código fuente utilizado para realizar estas pruebas se encuentra en el anexo A. Después de realizar diversas pruebas con este código y esta librería, se detectó inestabilidad de ésta a la hora de reconocimiento de puertos presentes en los equipos, por lo tanto se procede a buscar otra librería de manejo de puerto serial en java para remplazar esta librería. b) Librería RXTX La librería RXTX es una librería de código abierto para Java desarrollada a partir de Java Development Kit (JDK) desarrollada por Keane Jarvi en el año 1998. Entre los proyectos que han utilizado esta librería para desarrollar soluciones utilizando el puerto serial / paralelo de java se encuentran: GGC Gnu Gluco Control Vna/J Control program for http://vnaj.dl2sba.com http://ggc.sourceforge.net/ miniRadioSolutions miniVNA vector- network-analyzer. 65 DriverWire A drive block and http://drivewireserver.source forge.net/ networking server for the Color TRS-80 Computer family Tabla 11: Aplicaciones que utilizan la librería RXTX. Además, de estos proyectos existe una lista amplia en el sitio de la librería. Como la librería RXTX hereda las funcionalidades de la librería de JDK, soló se requiere instalar y modificar las librerías en el proyecto para tener las funcionalidades operativas. Instalación de la librería RXTX Según la documentación publicada en sitio de la librería RXTX16, para la instalación de la librería son necesarias las siguientes dependencias: JDK 1.4 o superior Autoconf Automake Libtool gnu make 16 http://rxtx.qbang.org/wiki/ 66 gcc. Después de descargar la librería se descomprime y se copia el archivo RXTXcomm.jar en el directorio donde se encuentra la JDK: cp RXTXcomm.jar /usr/local/jdk1.6.0_22/jre/lib/ext Y luego se copia la librería serial librxtxSerial.so para linux en el directorio de las librerías del JDK: cp librxtxSerial.so /usr/local/jdk1.6.0_22/jre/lib/i386 Después de la instalación de la librería se procedió a realizar pruebas de captura de datos a través del puerto serial, utilizando el mismo ejemplo básico de detección de puertos seriales, el cual se encuentra en el anexo A, estableciendo la compatibilidad y estabilidad de la librería con las funciones del código anterior. El código fuente utilizado para realizar estas pruebas se encuentra en el anexo B. Finalmente, se adoptó la librería RXTX para realizar la captura de información después de pasar un período de pruebas sin presentar fallas de ningún tipo. 67 7.5.1.4. Implementación. El módulo de captura serial utilizará la librería RXTX para la lectura a través del puerto serial. A continuación, se describen las funciones de esta librería que se utilizaron para establecer la captura: • import gnu.io.CommPort es la librería encargada de detectar los puertos com seriales. • import gnu.io.CommPortIdentifier asigna un identificador a cada puerto serial. • import gnu.io.SerialPort entrega facilidades para abrir y trabajar puerto serial. • CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); Se encarga de detectar e identificar los puertos seriales presentes en el equipo, los cuales se almacenan en una variable de tipo CommPortIdentifier, para luego comparar los puertos encontrados con el puerto que se desea utilizar. • CommPort commPort portIdentifier.open(this.getClass().getName(),2000) 68 = Se abre el puerto serial que realiza la lectura. • SerialPort serialPort = (SerialPort) commPort; Se define la variable serialport que manejará la lectura / escritura del puerto serial y se asocia al commPort asignado. • serialPort.setSerialPortParams(9600,SerialPort.DATABITS_8,Serial Port.STOPBITS_1,SerialPort.PARITY_NONE) Se definen los valores de los baudios, bits de datos, bit de parada y paridad de lectura del puerto serial. Esta función recibe valores de tipo entero, los cuales están definidos en la librería como variables estáticas. 69 7.5.1.5. Validación y verificación. Al finalizar el módulo de la captura serial se obtiene el siguiente resultado de interfaz Figura 29: Esquema de Interfaz Captura Serial Las pruebas de captura que fueron realizadas con el módulo serial se hicieron utilizando como primer dispositivo un router Cisco Serie 800 en su 70 modelo 828, debido a la simplicidad de los datos entregados, los cuales se muestran a continuación: Figura 30: Secuencia de captura datos router Cisco 800. Cuando se determinó que la captura de datos de estos dispositivos cumplía la etapa de estabilidad de captura en los datos y no presentaba errores en los bits de lectura, se continuó realizando pruebas de captura utilizando las centrales telefónicas privadas de laboratorio. Los resultados fueron los siguientes: 71 Figura 31: Secuencia de captura Panasonic y Nitsuko 7.5.2. Etapa 2: Traspaso captura a base de datos En esta etapa se unirán las etapas de especificación de requisitos y la especificación funcional debido a que la primera etapa es de corta planificación. 7.5.2.1. Plan operativo. Para que la aplicación pueda almacenar la captura de la información obtenida desde el módulo de captura serial fue necesario definir la forma en la que se almacenarán la información hacia la base de datos del computador servidor. 72 7.5.2.2. Especificación de requisitos y funcional. Los requisitos necesarios en esta etapa son los siguientes: - Establecer motor de base de datos. - Integración entre motor de base de datos y lenguaje de programación. - Comprobación del correcto almacenamiento de la información ingresada. Para el lenguaje de programación Java, se determinó trabajar con el motor de base de datos MYSQL17 debido a que es un proyecto de código abierto, multihilo y multiusiario que se adapta a las necesidades de la aplicación. Otra ventaja de trabajar con este motor de base de datos es el soporte que le brinda Oracle Corporation18 quién además, brinda el mismo soporte de mantención al lenguaje de programación Java, por lo que la integración entre ambos componentes, motor base de datos y lenguaje de programación, es óptimo. Finalmente, la experiencia adquirida trabajando en proyectos utilizando este motor de base de datos determinó la decisión de adoptarlo para el desarrollo de la aplicación. 17 18 MYSQL: Motor de Base de datos GNU GPL. Oracle corporartion es una de las mayores compañías de software del mundo. 73 Para que una aplicación en Java se comunique con una base de datos usando la API JDBC19, se requirió de un conector que fuese capaz de comunicar a la aplicación con la base de datos. Ese conector es específico para el manejador de base de datos y debió incluirse en el archivo JAR de despliegue de la aplicación. Para el desarrollo de la aplicación se utilizó la versión mysql-connectorjava-5.0.8. 7.5.2.3. Implementación. Para el módulo de traspaso hacia la base datos se realizó una pequeña aplicación para realizar las pruebas de escritura en la base de datos. Como primera prueba se creó una tabla, la cual fue llamada campo único, la cual se presenta a continuación: 19 JDBC: Java Database Connectivity. 74 Serial_Testing, de Serial_Testing SerialParam (VARCHAR 60) Tabla 12: Tabla SerialTesting módulo traspaso datos Las pruebas fueron hechas después de incluir el conector mysql- connector-java-5.0.8 a la aplicación de pruebas en la cual se ingresaron datos hasta que se determinó que las operaciones de lectura – escritura en la base de datos se realizaban de forma correcta. A continuación, se presentan capturas de pantalla con los resultados obtenidos: Figura 32: Módulo de pruebas de escritura en base de datos MySQL 75 Figura 33: Escritura en base de datos MySQL Luego de esta primera prueba, se realizaron modificaciones a la tabla para probar la escritura de múltiples campos en la base de datos para terminar el campo de pruebas de interacción entre el lenguaje de programación y la base de datos, la tabla definida se presenta a continuación: 76 Serial_Testing Fecha (VARCHAR 60) Hora (VARCHAR 60) Extension (VARCHAR 60) Linea (VARCHAR 60) Numero Discado (VARCHAR 60) Duracion Llamada (VARCHAR 60) Tabla 13: Segunda tabla SerialTesting módulo traspaso datos Se crea un formulario para las pruebas: Figura 34: Módulo de pruebas versión 2 de escritura en base de datos MySQL 77 Y se verifican los resultados en la base de datos: Figura 35: Versión 2 de escritura en base de datos MySQL Una vez que se probó el correcto funcionamiento del conector MySQL y Java esta tabla fue eliminada para poder continuar con la etapa de integración del módulo de captura serial y el traspaso de la información a la base de datos. Posteriormente, se diseñó e implementó un formulario simple para almacenar la información de los clientes y números de discado frecuente el cual será utilizado al momento de generar los reportes finales. Este permitió además, reutilizar código de las pruebas que se realizaron anteriormente y depurarlo para la implementación de la escritura final en la base de datos. El formulario se muestra en la siguiente figura: 78 Figura 36: Formulario Ingreso Números telefónicos de la empresa 7.5.2.4. Integración. Cuando se inició el desarrollo de la aplicación, se definió realizar una captura intermedia desde el puerto serial hacia un archivo de texto plano antes de realizar el traspaso definitivo hacia la base de datos. Al momento de desarrollar la aplicación y realizar las pruebas de escritura en el motor de base de datos MySQL y esquematizando el traspaso de la información desde la captura del puerto serial se estableció que era factible realizar el traspaso de la información a la base de datos en forma concurrente con la captura de datos a través del puerto serial. Esto es posible debido a las características del 79 envío de datos a través del puerto serial, las cuales como fue mencionado con anterioridad se realizan bit a bit. Cuando se realizaron las pruebas de captura serial en las centrales privadas en laboratorio, se constató que a pesar de que la información entregada por ambos modelos era la misma; no coincidía el orden en la que era entregada por pantalla Orden de la información Mostrada por Central Panasonic: [Date] [Time] [Ext] [CO] [Dial Number] [Duration] Orden de la información Mostrada por Central Nitsuko: [CLS] [Date] [Time] [Line] [Duration] [ST] [Dialed] Debido a esto, se realizó una función de control simple para que, cuando el usuario seleccione una central Nitsuko, separe los campos mostrados en pantalla y los ordene respecto a un orden estándar, tomando como base el orden entregado por la central Panasonic, antes de almacenarlos en la base de datos. A continuación, se esquematiza el proceso de traspaso de datos desde el módulo de la captura serial hacia la base de datos MySQL: 80 Figura 37: Esquema de almacenamiento captura puerto serial 7.5.2.5. Validación y verificación. En la primera etapa de las pruebas de funcionamiento integrado del módulo de la captura y el módulo de traspaso hacia la base de datos se realizaron interconectando dos centrales entre si para simular llamadas hacia el exterior, esto con el fin de obtener datos de captura en un ambiente controlado de llamadas sin utilizar recursos telefónicos reales, los cuales implicasen gastos adicionales asociados. En el siguiente esquema se gráfica el ambiente de pruebas: 81 Figura 38: Esquema de conexión Central Panasonic y Nitsuko Figura 39: Integración entre módulo de captura serial y base de datos La última etapa de pruebas consistió en realizar las pruebas de funcionamiento en una central telefónica en operación. Esta pertenece a la empresa JMOAustral, en la cual se realizó la captura de datos durante un período de 15 días. 82 A continuación, se muestra una captura de pantalla con una captura de datos y los resultados de escritura en la base de datos: Figura 40: Integración final entre Módulo de captura y traspaso hacia la base de datos 83 7.5.3. Etapa 3: Generación de reportes En esta etapa se unirán las etapas de especificación de requisitos y la especificación funcional debido a que la primera etapa es de corta planificación. 7.5.3.1. Plan operativo. Para que la aplicación pueda obtener la información para generar los reportes fue necesario definir la información requerida por cada uno de ellos y definir la forma en como se almacenarán y presentarán al usuario final. 7.5.3.2. Especificación de requisitos y funcional. Los requisitos necesarios en esta etapa son los siguientes: - Definir los reportes que serán generados por la aplicación - Definir la forma en la que los reportes serán mostrados y almacenados al usuario final. 84 Para la generación de informes, se establecieron los siguientes criterios: a) Reportes por número de extensión Elabora reportes del tráfico generado por una o todas las extensiones existentes en un período de tiempo determinado por el usuario. b) Reportes por línea externa Elabora reportes del tráfico generado por una o todas las líneas desde una extensión en un período de tiempo determinado por el usuario. Elabora reportes del tráfico generado por una o todas las líneas en un período de tiempo determinado por el usuario. c) Reportes por duración de las llamadas Elabora un reporte estadístico con las 10 llamadas de más larga duración realizada por cada una de las extensiones y el promedio de tiempo de las llamadas desde cada una de las extensiones. d) Reportes por números frecuente de la empresa Elabora un reporte comparativo del tráfico generado por una o todas las extensiones entre las llamadas a los números frecuentes de la empresa y las llamadas que no lo son, en un período de tiempo determinado por el usuario. 85 Para los reportes, fue necesario estudiar que tipo de componentes existían en el lenguaje Java para realizar esta tarea y poder seleccionar el más adecuado para su generación. Al momento en que se realizaron los reportes, se determinó que los informes se generarían en formato PDF20. Esta decisión se tomó debido a que es un formato de almacenamiento de documentos digitales independiente de plataformas de software o hardware. En el lenguaje Java, existen múltiples librerías para el trabajo y la generación de archivos PDF, sin embargo, se optó por utilizar la librería iText21 para este propósito, debido a que es de código abierto por lo que se ajusta a las características del proyecto. Además de la generación de reportes, se determinó necesario generar modelos de gráficos que para representar de forma visual los resultados obtenidos por la generación de reportes. Para generar los gráficos, se utilizó la librería JFreeChart22 en conjunto con la librería JCommon23 como dependencia para operar, debido a que es una librería de código abierto y permite generar gráficos simples. Las versiones de las librerías utilizadas en el proyecto fueron las siguientes: iText-5.3.4, JFreeChart-1.0.14 y JComon-1.0.4. 20 PDF: Portable Document Format. iText: Librería Opensource para crear y manipular archivos PDF. 22 JFreeChart: Librería Opensource para crear gráficos. 23 JCommon: Librería Opensource complementaria para JFreeChart. 21 86 7.5.3.3. Diseño. En esta etapa, se definió la estructura que tendrían los reportes generados. La información se dividirá en dos tipos: Un reporte simple sin gráficos y otro con una gráfica representativa según el reporte generado, y se estructurará de la siguiente forma: - Titulo del reporte - Período del reporte - Gráfico en el caso de generar reporte con gráficos - Total de llamadas realizadas - Tiempo total de las llamadas - Tabla que muestra todas las llamadas realizadas ordenadas según el tipo de reporte realizado. A continuación, se realizó un esquema general del aspecto visual de los reportes: 87 Figura 41: Esquema visual reporte sin gráficos 88 Figura 42: Esquema visual de reporte con gráficos página 1 89 Figura 43: Esquema visual de reporte con gráficos página 2 90 7.5.3.4. Implementación. Para el módulo de generación de reportes, se inició la implementación realizando una pequeña aplicación para realizar las pruebas de la generación de gráficos utilizando la librería JFreeChart. Figura 44: Prueba de generación de gráficos. Posteriormente, se realizó una pequeña aplicación para probar el funcionamiento de la librería iText, para la generación de archivos PDF y se integraron ambas pruebas para generar archivos PDF con imágenes de los gráficos generados con la librería JFreeChart. Se realizaron capturas de las pruebas realizadas las cuales se muestran a continuación: 91 Figura 45: Aplicación de prueba generación archivo PDF Figura 46: Resultados de la generación de archivo PDF 92 7.5.3.5. Integración. La integración de este módulo se describirá a fondo en el capítulo de integración final, debido a que es la última etapa del desarrollo de la aplicación y al integrarla con los módulos anteriores todas las funcionalidades quedan operativas. 93 7.5.3.6. Validación y verificación. A continuación, se presentan a modo de ejemplo, los resultados obtenidos de la generación de reportes por extensión. Gráfico de reportes generados por la extensión 101 entre el 19 de noviembre y el 24 de noviembre del 2012. Figura 47: Generación de gráfico estadístico en un período determinado. 94 Gráfico de reportes generados por todas las extensiones entre el 1 de noviembre y el 30 de noviembre del 2012 Figura 48: Generación de gráfico estadístico de todas las extensiones en un período determinado. Al finalizar estas pruebas, se modificó la orientación de las leyendas del eje X de los gráficos, rotándolas en 45 grados, para una lectura más cómoda. 95 7.6. Integración Final. En la etapa de integración final se incorpora el módulo de generación de reportes, el cual tiene por finalidad elaborar informes de los consumos generados por las extensiones y líneas de la central PBX. A continuación, se explicará como opera el módulo de generación de reportes y luego como se incorpora en conjunto con los demás módulos de la aplicación: El módulo de generación de reportes obtiene la información en su mayoría desde la tabla PBX_DataTable a excepción del reporte de llamadas a números frecuentes. La tabla PBX_DataTable contiene toda la información respecto a las llamadas realizadas, por lo tanto, es utilizada para elaborar los reportes referentes a la cantidad de llamadas realizadas desde una extensión o línea especifica, duración de las llamadas, llamadas realizadas desde una extensión o línea específica, entre otras consultas siempre referentes a las llamadas generadas. Para los reportes de llamadas de número frecuente se generan reportes a través de dos tablas: PBX_DataTable y PBX_BusinessNumber debido a que de esta forma, se obtuvieron las llamadas que pertenecen y las 96 que no pertenecen al registro de llamadas que se realizan hacia números conocidos de la empresa. De esta forma, los módulos de captura de datos a través del puerto y el traspaso de la captura hacia la base de datos entregan la información al módulo de generación de reportes completando las funcionalidades de la aplicación en los tres módulos definidos al inicio del proyecto. 97 7.7. Validación y verificación final. En esta etapa, se realizan pruebas de funcionamiento de la aplicación. Para probar la correcta integración de todos los módulos y probar la funcionalidad de la aplicación completa, se realizaron las siguientes pruebas: Formulario/Módulo Prueba Resultado Correcto realizada obtenido (S/N) Corrección Mostrar Reportes gráfico de Se muestra en Llamadas a llamadas pantalla el Números de generadas por gráfico Empresa todas las solicitado S No hay correcciones extensiones Ingreso de Número Ingreso de de llamado nuevo número frecuente empresa frecuente Reporte de Líneas Número ingresado correctamente a S Mensaje de reportes alerta indicando omitiendo los que se han rangos de omitido estos fecha campos S Generar reporte duración de las estadístico de llamadas duración de hay correcciones la base de datos Generar Reporte de No No correcciones No Generación de reporte PDF. las llamadas 98 hay hay correcciones S Generar reportes en módulo de extensión Reporte de desde la Extensiones extensión 102 entre el 19 de noviembre y el Las fechas del Se define reporte se generan en N formato nuevo formato para fecha Día/Mes/Año Año/Mes/Día 23 de noviembre Las llamadas Módulo de captura Desconexión realizadas desde de cable serial la desconexión entre equipo son recuperadas servidor y por el módulo de central captura. Esto telefónica por demuestra que un día. El la central cable se telefónica posee vuelve a un buffer de reconectar al almacenamiento día siguiente para las S llamadas. A continuación, se presentan algunas pruebas de reportes realizadas: 99 100 101 102 103 104 105 106 107 8. Conclusiones y/o recomendaciones. El uso de la metodología de desarrollo por etapas, permitió organizar la estructura del proyecto de tal forma que a medida de que fueron desarrollando cada uno de los módulos que componen la aplicación, se depuraron y probaron hasta obtener los resultados esperados para luego proceder a la integración con el siguiente módulo. Esto fue beneficioso para el proyecto, sobre todo en el módulo de captura serial, donde los niveles de depuración y desarrollo fueron más largos. En relación al desarrollo de la aplicación, trabajar con el lenguaje de programación Java resultó una experiencia nueva e interesante, debido a que a medida de que se avanzó en la codificación, cada necesidad de la aplicación tenia su propia solución adaptada al lenguaje, lo cual demuestra la versatilidad que este lenguaje ha obtenido a través del tiempo y demuestra las razones de que se haya transformado en un lenguaje de programación cada vez más integrado a las aplicaciones cotidianas. Después de realizar el período de pruebas de la aplicación, se puede concluir que se cumplió el objetivo de la conexión entre central telefónica y el computador a través del puerto serial cuando la aplicación fue capaz de conectarse mediante puerto serial a la central telefónica TDA 100 y comenzar 108 a recibir la información de las llamadas realizadas guardadas en el buffer del puerto rs-232 de la central telefónica. Además, la aplicación desarrollada cumplió con los objetivos definidos al inicio del proyecto respecto a la generación de reportes, ya que entregó información concreta de como se estaban utilizando los recursos telefónicos en la empresa respecto a las extensiones, duración de las llamadas y líneas contratadas. Finalmente, cabe mencionar, que en el caso de existir una futura iniciativa de desarrollo en el presente proyecto, es factible en primer lugar realizar un módulo de consultas de las llamadas realizadas a un número telefónico específico, para establecer si la llamada fue concretada. En segundo lugar es posible considerar ampliar la funcionalidad a un tarificador de tráfico telefónico, agregando centro de costos para las llamadas realizadas, realizar filtros específicos para las llamadas realizadas como por ejemplo: filtrar las llamadas larga distancia y asignarles un valor por minuto. Estos filtros no fueron considerados en el desarrollo del proyecto actual, ya que, lo que se propuso lograr es un analizador de tráfico, para tener una visión general del uso de los recursos telefónicos y dejar abierta la generación de estos componentes. 109 9. Bibliografía. [Pressman, 2005] Pressman, Roger. Ingenieria del software: Un enfoque Práctico. 6ª Edición. 2005. [Ferra, 2009] Ferra, Enrique. El análisis del tráfico telefónico: Una herramienta estratégica de la empresa. Disponible en: http://www.academiadelanzarote.es/Discursos/Discurso% 2032.pdf Discurso%2032.pdf, Julio del 2009. [Joskowicz, 2011] Joskowicz , José Conceptos básicos de telefonía. Disponible en http://iie.fing.edu.uy/ense/asign/ccu/material/docs/Concep tos%20Basicos%20de%20Telefonia.pdf Junio 2011. 110 [Reinoso 2007] Reinoso, Marlon Diseño e implementación del sistema de generación de reportes para la tarifación automática de la central telefónica NITSUKO TX SERIES de la ESPE Sede Latacunga. Disponible en http://repositorio.espe.edu.ec/bitstream/21000/3465/1/TESPEL-0456.pdf, Diciembre 2007 111 10. Anexos. Anexo A: Manual de usuario LPBX Analizador de tráfico telefónico 1. Descripción de la aplicación LPBX Analizador de tráfico telefónico, es una aplicación orientada a analizar los datos desde tres modelos de centrales telefónicas: Panasonic KXTA 308, Panasonic TDA100 y Nitsuko TXZ-Serie. Esta aplicación es capaz de generar reportes estadísticos básicos para: • Establecer cuanto duran las llamadas realizadas por cada extensión • Establecer el consumo de cada extensión y línea existentes en la central. Además, cuenta con la funcionalidad de crear una libreta de contactos propios de la empresa, con el fin de poder filtrar las llamadas que se generan a estos números y las que no están dentro de este listado con el fin de poder determinar la cantidad de llamadas que se escapan de las necesidades de contacto propios de la empresa y, en caso de que se estén generando exceso 112 de llamadas fuera de contexto, tomar las medidas para establecer el buen uso del recurso telefónico. 113 2. Contenido • Descripción de componentes de la aplicación • Iniciar la aplicación • Generar Reportes 114 Descripción de componentes de la aplicación A continuación, se describen los componentes de la aplicación: • Pantalla inicio de la aplicación Al iniciar la aplicación se pueden apreciar dos componentes de la aplicación: Tabla de todos los datos capturados a través del tiempo y actualizará su contenido a medida de que los datos capturados son almacenados en la base de datos 115 Barra de menú de la aplicación cuenta con los siguientes elementos: Archivo Administrar números Frecuentes Formulario para guardar los números de llamado frecuente de la empresa Sale de la aplicación Salir Reportes Reportes por Extensión Reportes por Línea Reportes por Duración de las llamadas Reportes Llamadas a Números de Empresa Captura Iniciar Captura Configuración Configurar Modelo PBX Formulario para generar los reportes de las llamadas generadas por número de extensión. Formulario para generar los reportes de las llamadas generadas por número de línea. Generar los reportes de las llamadas por su duración. Formulario para generar los reportes de las llamadas generadas haia número de la empresa. Formulario para la captura de datos a través del puerto serial. Formulario para configurar el modelo de la PBX para la cual se hará el análisis de tráfico. 116 • Configuración modelo PBX Para configurar el modelo de la central telefónica a la cual se realizará el análisis de tráfico, ir al menú Configuración Seleccionar opción Configurar Modelo PBX. Seleccionar Modelo central PBX a analizar, el cual está dividido por marca de central, formato de hora y formato de fecha por defecto la configuración está asignada para trabajar con centrales de la marca Panasonic, formato 12 horas y formato fecha en Mes/Día/Año. 117 Agregar números frecuentes de la empresa Para configurar el modelo de la central telefónica a la cual se realizará el análisis de tráfico, ir al menú Archivo. o Seleccionar opción Administrar números Frecuentes o Ingresar los datos solicitados Empresa Contacto Ciudad Teléfono Presionar el botón Guardar Para ver todos los contactos almacenados presionar el botón Mostrar Todo. 118 • Iniciar Captura Datos Para iniciar la captura de datos ir al menú Captura. o Seleccionar opción Iniciar Captura. o Seleccionar Puerto Serial, Baudios, Bit de Parada, Bit de Datos y Paridad según configuración asignada en el puerto seria de la PBX (generalmente es Baudios: 9600, bit de parada: 1, bit de datos: 8 y paridad: none). o Presionar botón Iniciar Captura y esperar a que los datos capturados se muestren por pantalla. o Minimizar Módulo de captura en caso de ser necesario. 119 • Reportes Para generar reportes ir al menú Reportes o Seleccionar el reporte que se desea generar. o Generar reporte deseado. La generación de reportes se detalla en el capítulo Generar reportes Iniciar aplicación Después de iniciar la aplicación, primero se debe configurar el modelo de la central PBX en el menú Configuración y Seleccionar opción Configurar Modelo PBX. Seleccionar Modelo, formato de hora y formato de fecha correspondiente. Luego de completar esta operación es necesario iniciar la captura de datos para comenzar a almacenar los datos respecto al tráfico generado, para ello debe ir al menú Captura y seleccionar la opción Iniciar Captura. 120 Seleccionar la configuración del puerto serial correspondiente y presionar botón Iniciar Captura. Luego de esto, minimizar esta ventana. Puede volver a restaurarla cuando estime necesario. 121 Generar Reportes A continuación, se detalla como generar cada uno de los reportes de la aplicación: Reportes por extensión. Para generar reportes por extensión ir al menú Reportes y seleccionar la opción Reportes por extensión, aparecerá la siguiente pantalla: Seleccione el Número de extensión: Puede ser una extensión específica o Todas las extensiones. Seleccione rango del período para el reporte: Seleccionar fecha de inicio y fecha de fin. Seleccione filtro: de para establecer el orden de la información del reporte Presionar el botón Filtrar para ver los resultados en pantalla. 122 Para generar un gráfico representativo del reporte, presionar botón Ver Gráfico Para generar un reporte simple, presionar botón Reporte sin Gráfico. Este reporte se generará en formato PDF con el nombre y ubicación los cuales son especificados por uno mismo. Para generar un reporte incorporando un gráfico representativo del reporte, presionar botón Reporte con Gráfico. 123 Este reporte se generará en formato PDF con el nombre y ubicación los cuáles son especificados por uno mismo. 124 Reportes por línea Para generar reportes por extensión ir al menú Reportes y seleccionar la opción Reportes por línea, aparecerá la siguiente pantalla: Seleccione el número de Línea: Puede ser una línea específica o Todas las líneas. Seleccione el Número de extensión: Puede ser una extensión específica o Todas las extensiones. Seleccione rango del período para el reporte: Seleccionar fecha de inicio y fecha de fin. Seleccione filtro: de para establecer el orden de la información del reporte Presionar el botón Filtrar para ver los resultados en pantalla. 125 Para generar un gráfico representativo del reporte, presionar botón Ver Gráfico Para generar un reporte simple, presionar botón Reporte sin Gráfico. Este reporte se generará en formato PDF con el nombre y ubicación los cuáles son especificados por uno mismo. Para generar un reporte incorporando un gráfico representativo del reporte y presionar botón Reporte con Gráfico. 126 Este reporte se generará en formato PDF con el nombre y ubicación los cuáles son especificados por uno mismo. 127 Reportes por Duración de las llamadas Para generar reportes por extensión ir al menú Reportes y seleccionar la opción Reportes por duración de las llamadas, aparecerá la siguiente pantalla: Seleccione rango del período para el reporte: Seleccionar fecha de inicio y fecha de fin. Presionar el botón Generar Reporte. 128 Este reporte se generará en formato PDF con el nombre y ubicación especificados por uno mismo. El contenido de este reporte es una lista con las 10 llamadas de más larga duración realizada por cada una de las extensiones y el promedio de tiempo de las llamadas desde cada una de las extensiones. Reportes Llamadas a Números de Empresa Para generar reportes por extensión ir al menú Reportes y seleccionar la opción Reportes Llamadas a Número de Empresa, aparecerá la siguiente pantalla: 129 Seleccione el Número de extensión: Puede ser una extensión específica o Todas las extensiones. Seleccione rango del período para el reporte: Seleccionar fecha de inicio y fecha de fin. Seleccione filtro: de para establecer el orden de la información del reporte Presionar el botón Filtrar para ver los resultados en pantalla. Para generar un gráfico representativo del reporte, presionar botón Ver Gráfico Para generar un reporte simple, presionar botón Reporte sin Gráfico. 130 Este reporte se generará en formato PDF con el nombre y ubicación los cuáles son especificados por uno mismo. Para generar un reporte incorporando un gráfico representativo del reporte, presionar botón Reporte con Gráfico. 131 Este reporte se generará en formato PDF con el nombre y ubicación los cuáles son especificados por uno mismo. 132 Anexo B. Código de pruebas detección de puertos seriales utilizando librería JavaCom import javax.comm.*; import java.util.Enumeration; public class Main { public static void main(String args[]) { Enumeration ports = CommPortIdentifier.getPortIdentifiers(); while (ports.hasMoreElements()) { CommPortIdentifier port (CommPortIdentifier)ports.nextElement(); String type; switch (port.getPortType()) { case CommPortIdentifier.PORT_PARALLEL: type = "Paralelo"; //Se ejecuta si el puerto es paralelo break; case CommPortIdentifier.PORT_SERIAL: type = "Serial"; //Se ejecuta si el puerto es serial 133 = break; default: type = "Desconocido/Error"; //No deberia de suceder o el puerto esta dañado break; } System.out.println("Nombre del puerto: "+port.getName() + " - " + type); } } } 134 Anexo C. Código de pruebas de lectura puerto serial utilizando librería RXTX Asegurándose de que la librería está correctamente instalada se realiza prueba con código desarrollado con esta librería para leer el puerto serial: import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.FileDescriptor; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } 135 = else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(9600,SerialPort.DATABITS_8,SerialPort.STOP BITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialReader(in))).start(); (new Thread(new SerialWriter(out))).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } 136 } public static class SerialReader implements Runnable { InputStream in; public SerialReader ( InputStream in ) { this.in = in; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try{ while ( ( len = this.in.read(buffer)) > -1 ){ System.out.print(new String(buffer,0,len)); } } catch ( IOException e ){ e.printStackTrace(); } } } public static class SerialWriter implements Runnable 137 { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); } } 138 } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("/dev/ttyUSB0"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } 139 Anexo D: Glosario Bit de Parada (Stop Bit): El código de bit de parada indica el final de una serie de bits que compone un carácter. Seleccione un valor dependiendo de los requerimientos de su impresora o computadora personal. Baudios: El código de velocidad en baudios indica la velocidad de transmisión de datos desde el sistema a la impresora o computadora personal. Longitud de Palabra (Data Bit): El código de longitud de palabra indica cuántos bits componen un carácter. Paridad (Parity): El código de paridad indica qué tipo de paridad se utiliza para detectar un error en la serie de bits que componen un carácter. Haga su elección dependiendo de los requerimientos de su impresora o computadora personal. Puerto Serial: El puerto serial es un puerto de comunicaciones. La información se transmite bit a bit y es por esto que recibe su nombre. El puerto se rige por RS 232 140 RS-232: Se define como un estándar para la conexión serial de señales de datos binarias entre un DTE (Equipo terminal de datos) y un DCE (Equipo de terminación del circuito de datos). 141 Anexo E: Script de la base de datos -- phpMyAdmin SQL Dump -- version 3.4.10.1deb1 -- http://www.phpmyadmin.net --- Servidor: localhost -- Tiempo de generación: 30-11-2012 a las 16:08:07 -- Versión del servidor: 5.5.28 -- Versión de PHP: 5.3.10-1ubuntu3.4 SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; SET time_zone = "+00:00"; /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; --- Base de datos: `LPBXDB` --- ---------------------------------------------------------- Estructura de tabla para la tabla `PBX_BusinessNumber` -CREATE TABLE IF NOT EXISTS `PBX_BusinessNumber` ( `CodCli` int(11) NOT NULL, `ClientName` varchar(45) COLLATE utf8_spanish_ci DEFAULT NULL, `ClientContact` varchar(45) COLLATE utf8_spanish_ci DEFAULT NULL, `ClientCity` varchar(45) COLLATE utf8_spanish_ci DEFAULT NULL, PRIMARY KEY (`CodCli`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci; 142 -- ---------------------------------------------------------- Estructura de tabla para la tabla `PBX_ClientNumber` -CREATE TABLE IF NOT EXISTS `PBX_ClientNumber` ( `ClientNumber` varchar(45) COLLATE utf8_spanish_ci NOT NULL, `PBX_BusinessNumber_CodCli` int(11) NOT NULL, PRIMARY KEY (`ClientNumber`), KEY `fk_PBX_ClientNumber_PBX_BusinessNumber1` (`PBX_BusinessNumber_CodCli`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci; -- ---------------------------------------------------------- Estructura de tabla para la tabla `PBX_DataTable` -CREATE TABLE IF NOT EXISTS `PBX_DataTable` ( `PBX_ID` int(11) NOT NULL AUTO_INCREMENT, `PBX_Date` date DEFAULT NULL, `PBX_Time` time DEFAULT NULL, `PBX_Extension` varchar(10) COLLATE utf8_spanish_ci DEFAULT NULL, `PBX_Line` varchar(10) COLLATE utf8_spanish_ci DEFAULT NULL, `PBX_DialNumber` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL, `PBX_Duration` time DEFAULT NULL, `PBX_ClientNumber_ClientNumber` varchar(45) COLLATE utf8_spanish_ci NOT NULL, PRIMARY KEY (`PBX_ID`), KEY `fk_PBX_DataTable_PBX_ClientNumber1` (`PBX_ClientNumber_ClientNumber`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=1 ; -- ---------------------------------------------------------- Estructura de tabla para la tabla `PBX_SaveConfig` -- 143 CREATE TABLE IF NOT EXISTS `PBX_SaveConfig` ( `PBX_Model` varchar(45) COLLATE utf8_spanish_ci NOT NULL, `PBX_HourFormat` varchar(45) COLLATE utf8_spanish_ci NOT NULL, `PBX_DateFormat` varchar(45) COLLATE utf8_spanish_ci NOT NULL, PRIMARY KEY (`PBX_Model`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci; -- ---------------------------------------------------------- Estructura de tabla para la tabla `SerialParameters_BAUD` -CREATE TABLE IF NOT EXISTS `SerialParameters_BAUD` ( `SerialBAUD` int(11) NOT NULL, PRIMARY KEY (`SerialBAUD`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; --- Volcado de datos para la tabla `SerialParameters_BAUD` -INSERT INTO `SerialParameters_BAUD` (`SerialBAUD`) VALUES (300), (2400), (9600), (14400), (19200), (38400), (57600), (152000); -- ---------------------------------------------------------- Estructura de tabla para la tabla `SerialParameters_DATABIT` -CREATE TABLE IF NOT EXISTS `SerialParameters_DATABIT` ( `SerialDATABIT` int(11) NOT NULL, PRIMARY KEY (`SerialDATABIT`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci; 144 --- Volcado de datos para la tabla `SerialParameters_DATABIT` -INSERT INTO `SerialParameters_DATABIT` (`SerialDATABIT`) VALUES (5), (6), (7), (8); -- ---------------------------------------------------------- Estructura de tabla para la tabla `SerialParameters_PARITY` -CREATE TABLE IF NOT EXISTS `SerialParameters_PARITY` ( `SerialPARITY` varchar(11) COLLATE utf8_spanish_ci NOT NULL, PRIMARY KEY (`SerialPARITY`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci; --- Volcado de datos para la tabla `SerialParameters_PARITY` -INSERT INTO `SerialParameters_PARITY` (`SerialPARITY`) VALUES ('Even'), ('Mark'), ('None'), ('ODD'), ('Space'); -- ---------------------------------------------------------- Estructura de tabla para la tabla `SerialParameters_STOPBIT` -CREATE TABLE IF NOT EXISTS `SerialParameters_STOPBIT` ( `SerialSTOPBIT` int(11) NOT NULL, PRIMARY KEY (`SerialSTOPBIT`) 145 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci; --- Volcado de datos para la tabla `SerialParameters_STOPBIT` -INSERT INTO `SerialParameters_STOPBIT` (`SerialSTOPBIT`) VALUES (1), (2); --- Restricciones para tablas volcadas ---- Filtros para la tabla `PBX_ClientNumber` -ALTER TABLE `PBX_ClientNumber` ADD CONSTRAINT `fk_PBX_ClientNumber_PBX_BusinessNumber1` FOREIGN KEY (`PBX_BusinessNumber_CodCli`) REFERENCES `PBX_BusinessNumber` (`CodCli`) ON DELETE NO ACTION ON UPDATE NO ACTION; --- Filtros para la tabla `PBX_DataTable` -ALTER TABLE `PBX_DataTable` ADD CONSTRAINT `fk_PBX_DataTable_PBX_ClientNumber1` FOREIGN KEY (`PBX_ClientNumber_ClientNumber`) REFERENCES `PBX_ClientNumber` (`ClientNumber`) ON DELETE NO ACTION ON UPDATE NO ACTION; /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */; 146