UNIVERSIDAD AUSTRAL DE CHILE SEDE PUERTO MONTT …
162
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
Transcript of UNIVERSIDAD AUSTRAL DE CHILE SEDE PUERTO MONTT …
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
2.1. Objetivo general ..............................................................................3
2.2. Objetivos específicos ......................................................................3
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
5.1. Hardware ...................................................................................... 14
5.2. Software ....................................................................................... 14
6. 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. Procesos para la realización de una llamada. .............................. 30
7. 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.4.1. Diagrama de clases ......................................................... 43
7.4.2. Diseño de la base de datos .............................................. 51
7.5. 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 (RS-
232C) ............................................................................................................... 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
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
2
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.
3
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.
4
- 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.
5
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
6
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
7
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.
8
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.
9
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.
10
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.
11
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.
12
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.
13
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.
14
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.
15
− 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.
16
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.
17
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
18
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
19
Central
Telefónica
Nº Extensión [10]
Usuario 1
Nº Extensión [11]
Usuario 2
Nº Extensión [12]
Usuario 3
Nº Extensión [13]
Usuario 4Nº Extensión [14]
Usuario 5
Nº Extensión [15]
Usuario 6
Línea
Externa 1
Línea
Externa 2
Figura 2: Esquema Central telefónica privada
20
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:
21
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
22
Figura 4: Teléfono Multi-Línea modelo 6TD76TXD/12TD/12TXD
23
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:
24
Indicación del Visor Datos a Ingresar Inicial
C O N F I G . S M D R
# 0 5 7 - I T - X
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: 0 Item2: 1 Item3: 0 Item4: 0 Item5: 1 Item6: 1 Item7: 1 Item8: 0 Item9: 0
Tabla1: Programa 57 Nitsuko Serie TX-Z
25
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.
26
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:
27
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:
28
Figura 9: Asigna los parámetros de comunicación para la Interfaz Serial (RS-
232C)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 Extraído del manual de Instalación Panasonic KX_TA 308/616 8 Extraído del manual de Instalación Panasonic KX_TA 308/616
29
� 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. 10 Enlace de 30 canales de voz.
30
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.
31
• 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
32
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
33
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 para la aplicación a desarrollar, se
realizaron 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
34
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
35
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
36
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.
37
7.3. Especificación funcional
El siguiente diagrama refleja el diseño completo de la aplicación:
Equipo Servidor
Aplicación
Ubuntu 12.04
Módulo de
Captura Serial
siempre a la escucha de
información
Módulo de
traspaso de la captura
hacia base de datos
siempre a la escucha de
información
Escritura de información
en base de datos
Módulo de
Generación de reportes
Central
telefónica
privada
Reporte por
números
frecuentes
de la
empresaReporte
estadístico de
la duración de
las llamadas.
Reporte por
Línea Externa
Reporte por
Extensión
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:
38
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.
39
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.
40
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.
41
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 PHP: PHP Hypertext Pre-Processor 14Web: World Wide Web
42
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.
43
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:
44
Figura 21: Diagrama de clases, parte 1
45
Figura 22: Diagrama de clases, parte 2
46
Figura 23: Diagrama de clases, parte 3
47
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
48
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.
49
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.
50
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.
51
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
52
La siguiente tabla muestra las Entidades, sus relaciones y cardinalidad:
Nombre Entidad 1 Entidad 2 E-1 -> E-2
Card.
E2 -> E-1
Card.
Tiene PBX_Business
Number
PBX_Client
Number
1,n 1,1
Esta PBX_Client
Number
PBX_Data
Table
1,n 0,1
Tabla 2: Entidad y cardinalidad
53
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
54
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
55
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:
56
Definición de tablas de datos para los parámetros del puerto serial:
Nombre Descripción
SerialParameters_BAUD
Tabla que almacena los valores de
las velocidades en baudios del
módulo del puerto serial
SerialParameters_DATABIT
Tabla que almacena los valores de
los bits de datos del módulo del
puerto serial
SerialParameters_STOPBIT
Tabla que almacena los valores de
los Bits de parada del módulo del
puerto serial
SerialParameters_PARITY
Tabla que almacena los valores de
las paridades del módulo del puerto
serial
Tabla 4: Tabla de Configuración modelo central telefónica.
57
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
58
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.
59
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.
60
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
Tabla 9: Asignación de pines cable serial RS-232
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 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
61
En la siguiente tabla se definen las señales y los tipos de circuitos:
Nº
Nombre
Señal
Función
Tipo de circuito
EIA CCITT
2 RD (RXD) Recibir datos BB 104
3 SD (TXD) Transmitir datos BA 103
4 ER (DTR) Terminal de datos preparado
CD 108.2
5 SG Masa de la señal AB 102
6 DR (DSR) Conjunto de datos preparado
CC 107
7 RS (RTS) Petición de envío CA 105
8 CS (CTS) Cancelar envío CB 106
Tabla 10: Asignación de pines.
62
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
63
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
64
▪ 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
65
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 http://ggc.sourceforge.net/
Vna/J Control program for
miniRadioSolutions
miniVNA vector-
network-analyzer.
http://vnaj.dl2sba.com
66
DriverWire A drive block and
networking server
for the TRS-80
Color Computer
family
http://drivewireserver.sourceforge.net/
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/
67
� 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.
68
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)
69
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.
70
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
71
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:
72
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.
73
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 MYSQL: Motor de Base de datos GNU GPL. 18 Oracle corporartion es una de las mayores compañías de software del mundo.
74
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-connector-
java-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 Serial_Testing, de
campo único, la cual se presenta a continuación:
19 JDBC: Java Database Connectivity.
75
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
76
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:
77
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
78
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:
79
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
80
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:
81
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:
82
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.
83
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
84
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.
85
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.
86
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. 21 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.
87
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:
88
Figura 41: Esquema visual reporte sin gráficos
89
Figura 42: Esquema visual de reporte con gráficos página 1
90
Figura 43: Esquema visual de reporte con gráficos página 2
91
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:
92
Figura 45: Aplicación de prueba generación archivo PDF
Figura 46: Resultados de la generación de archivo PDF
93
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.
94
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.
95
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.
96
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
97
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.
98
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
realizada
Resultado
obtenido
Correcto
(S/N)
Corrección
Reportes
Llamadas a
Números de
Empresa
Mostrar
gráfico de
llamadas
generadas por
todas las
extensiones
Se muestra en
pantalla el
gráfico
solicitado
S No hay
correcciones
Ingreso de Número
de llamado
frecuente empresa
Ingreso de
nuevo número
frecuente
Número
ingresado
correctamente a
la base de datos
S No hay
correcciones
Reporte de Líneas
Generar
reportes
omitiendo los
rangos de
fecha
Mensaje de
alerta indicando
que se han
omitido estos
campos
S No hay
correcciones
Reporte de
duración de las
llamadas
Generar
reporte
estadístico de
duración de
las llamadas
Generación de
reporte PDF. S
No hay
correcciones
99
Reporte de
Extensiones
Generar
reportes en
módulo de
extensión
desde la
extensión 102
entre el 19 de
noviembre y el
23 de
noviembre
Las fechas del
reporte se
generan en
formato
Año/Mes/Día
N
Se define
nuevo formato
para fecha
Día/Mes/Año
Módulo de captura
Desconexión
de cable serial
entre equipo
servidor y
central
telefónica por
un día. El
cable se
vuelve a
reconectar al
día siguiente
Las llamadas
realizadas desde
la desconexión
son recuperadas
por el módulo de
captura. Esto
demuestra que
la central
telefónica posee
un buffer de
almacenamiento
para las
llamadas.
S
A continuación, se presentan algunas pruebas de reportes realizadas:
100
101
102
103
104
105
106
107
108
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
109
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.
110
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.
111
[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/T-
ESPEL-0456.pdf, Diciembre 2007
112
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 KX-
TA 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
113
de llamadas fuera de contexto, tomar las medidas para establecer el buen uso
del recurso telefónico.
114
2. Contenido
• Descripción de componentes de la aplicación
• Iniciar la aplicación
• Generar Reportes
115
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
116
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
Salir Sale de la aplicación
Reportes Reportes por Extensión Formulario para generar
los reportes de las llamadas generadas por número de extensión.
Reportes por Línea Formulario para generar los reportes de las llamadas generadas por número de línea.
Reportes por Duración de las llamadas Generar los reportes de las llamadas por su duración.
Reportes Llamadas a Números de Empresa Formulario para generar los reportes de las llamadas generadas haia número de la empresa.
Captura Iniciar Captura Formulario para la captura
de datos a través del puerto serial.
Configuración Configurar Modelo PBX Formulario para configurar
el modelo de la PBX para la cual se hará el análisis de tráfico.
117
• 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.
118
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.
119
• 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.
120
• 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.
121
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.
122
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.
123
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.
124
Este reporte se generará en formato PDF con el nombre y ubicación los
cuáles son especificados por uno mismo.
125
� 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.
126
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.
127
Este reporte se generará en formato PDF con el nombre y ubicación los
cuáles son especificados por uno mismo.
128
� 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.
129
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:
130
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.
131
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.
132
Este reporte se generará en formato PDF con el nombre y ubicación los
cuáles son especificados por uno mismo.
133
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
134
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);
}
}
}
135
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");
}
136
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.");
}
}
137
}
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
138
{
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();
}
}
139
}
public static void main ( String[] args )
{
try
{
(new TwoWaySerialComm()).connect("/dev/ttyUSB0");
}
catch ( Exception e )
{
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
140
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
141
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).
142
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;
143
-- -------------------------------------------------------- -- -- 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` --
144
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;
145
-- -- 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`)
146
) 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 */;
