Sistema informático para la gestión dinámica y personalizada de ...

Instituto Superior Politécnico José Antonio EcheverríaCUJAESISTEMA INFORMÁTICOPARA LA GESTIÓN DINÁMICAY PERSONALIZADA DE ...Maikel Lázaro Pérez GortLa Habana, 2012

Tesis de Maestría

INSTITUTO SUPERIOR POLITÉCNICO “JOSÉ ANTONIO ECHEVERRÍA”FACULTAD DE INGENIERÍA INFORMÁTICACENTRO DE ESTUDIO DE INGENIERÍA DE SISTEMASSistema Informático para la GestiónDinámica y Personalizada de ReportesTESIS PRESENTADA EN OPCIÓN AL TÍTULO DE MÁSTER EN INFORMÁTICA APLICADAAutor: Ing. Maikel Lázaro Pérez GortTutores: Dr. Raúl Martínez RodríguezDr. Jyrki NummenmaaCIUDAD DE LA HABANA, CUBAENERO, 2010

“… toda ciencia empieza en la imaginación…”José Martí

Siempre a Carolina, por supuesto…

A mi familia, a mis amigos…

ResumenExisten sistemas informáticos que brindan formatos predeterminados de reportes o informesdigitales para facilitar la comprensión de la información gestionada y la toma de decisionesestratégicas en las organizaciones o entidades empresariales. Por la naturaleza de estosreportes, muchas veces se requiere, para satisfacer las necesidades de los usuarios, realizarcambios en su estructura en cuanto a su apariencia. Debido a que la misma generalmente esestática e inflexible para las transformaciones, se necesita reprogramar el diseño de losreportes que se deseen cambiar, incurriéndose en costos adicionales de mantenimiento en lasdiferentes aplicaciones.La gestión ordinaria de reportes involucra a diferentes roles de usuarios que no siempre sonconsiderados. Si se incorpora a este proceso un alto grado de dinamismo y personalización, setorna más complicada la interacción entre estas herramientas y los usuarios, por lo que esimportante definir responsabilidades y establecer fronteras en las acciones que cada usuariopuede o es capaz de realizar.Con el desarrollo de este trabajo se pretende desarrollar e implementar una herramientainformatizada que permita gestionar las plantillas de diversos tipos de reportes de formadinámica, considerando las necesidades y preferencias de los usuarios, de forma tal, que seanellos mismos los que puedan realizar las adecuaciones necesarias. La herramienta contendrá,adicionalmente, un módulo que permita gestionar roles de usuarios, con el objetivo de poderestablecer políticas de acciones acorde con los privilegios otorgados.

Índice de contenidosINTRODUCCIÓN .............................................................................................................................1CAPÍTULO I. ANTECEDENTES Y DETALLES DE LA INVESTIGACIÓN ....................................................91.1 Introducción ...................................................................................................................101.2 Antecedentes de la Gestión de Reportes .......................................................................101.3 Conceptos Claves .........................................................................................................111.3.1 Gestión de Reportes............................................................................................................. 111.3.1.1 Fuentes de Datos ........................................................................................................................ 111.3.1.2 Plantilla de Reporte ..................................................................................................................... 121.3.1.3 Carga de Datos y Representación de Información ........................................................................ 121.3.1.4 Formatos de Reportes y Exportación ........................................................................................... 131.3.1.5 Proceso de Creación ................................................................................................................... 131.3.1.6 Otros Aspectos Relevantes ......................................................................................................... 161.3.2 Temas Básicos de Seguridad Informática ............................................................................. 161.3.2.1 Los Roles de Usuarios en la Gestión de Reportes ........................................................................ 171.4 Trabajo Previo Realizado ..............................................................................................171.4.1 Breve descripción del Generador de Reportes del GREHU ................................................... 181.4.1.1 Análisis Crítico ............................................................................................................................ 201.4.1.2 Extensión de los defectos observados ......................................................................................... 201.4.2 Otros trabajos realizados ...................................................................................................... 201.5 Fundamento de los Objetivos del Trabajo ......................................................................271.6 Análisis del Estado del Arte ...........................................................................................291.6.1 Principales Mecanismos de Desarrollo ................................................................................. 291.6.1.1 Formatos de Ficheros de Plantillas .............................................................................................. 301.6.1.2 Especificaciones para la Definición de Reportes........................................................................... 311.6.1.3 Gestión de Roles de Usuarios y Seguridad de Aplicaciones Informáticas ...................................... 321.6.1.4 Extensibilidad, la Flexibilidad y la Usabilidad ................................................................................ 331.6.2 Principales Herramientas ...................................................................................................... 341.6.2.1 Herramientas de Gestión de Reportes ......................................................................................... 341.6.2.2 Herramientas de Gestión de Seguridad ........................................................................................ 391.6.2.3 Herramientas que permiten alterar archivos compilados ............................................................... 401.6.3 Herramientas de Reportes más Utilizadas en la Actualidad ................................................. 421.6.4 Validación del Sistema a Desarrollar .................................................................................... 471.7 Decisiones Esenciales para una Buena Solución ..........................................................47

1.7.1 Gestión de Fuentes de Datos ............................................................................................... 471.7.2 Proceso de Concepción y Gestión de Reportes .................................................................... 481.7.3 Estructura de la Plantilla y Especificaciones ......................................................................... 491.7.4 Gestión de Compatibilidad, Flexibilidad, Extensibilidad y Seguridad...................................... 491.7.5 Selección de Herramientas para Desarrollo de la Solución ................................................... 501.8 Conclusiones .................................................................................................................51CAPÍTULO II. DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA ............................................................532.1 Introducción ...................................................................................................................542.2 Definición de los Requerimientos de la Solución ...........................................................542.3 Definición del Dominio de la Solución ............................................................................552.3.1 Conceptos Relevantes del Dominio de la Solución ............................................................... 562.3.2 Relaciones entre Elementos del Dominio .............................................................................. 562.3.3 Reglas a Considerar ............................................................................................................. 572.4 Solución Propuesta........................................................................................................582.4.1 Actores y Casos de Uso del Sistema .................................................................................... 582.4.2 Estructura de la Herramienta ................................................................................................ 602.5 Principales Procesos a Automatizar ..............................................................................602.5.1 Gestión Trazas y Roles de Usuarios ..................................................................................... 612.5.2 Gestión de Reportes Informáticos ......................................................................................... 622.5.2.1 Definición y Administración de Fuentes de Datos ......................................................................... 622.5.2.2 Asistentes Gráficos para la Gestión de Reportes .......................................................................... 622.5.2.3 Flexibilidad y Extensibilidad del Producto de Reporte ................................................................... 632.6 Otras Alternativas para la Gestión de los Reportes........................................................662.7 Conclusiones .................................................................................................................66CAPÍTULO III. DETALLES DE IMPLEMENTACIÓN, PRUEBA Y EVALUACIÓN DE RESULTADOS ..............683.1 Introducción ...................................................................................................................693.2 Aspectos de Implementación .........................................................................................693.2.1 Arquitectura del Sistema....................................................................................................... 693.2.1.1 Módulo de Gestión de Reportes ................................................................................................... 713.2.1.2 Módulo de Gestión de Roles de Usuario ...................................................................................... 723.2.1.3 Otras Funcionalidades Incorporadas ............................................................................................ 723.2.2 Gestión de la Persistencia de la Información ........................................................................ 733.2.3 Consideraciones para la Interfaz Gráfica de Usuario ............................................................ 743.2.4 Requerimientos no Funcionales de la Solución ..................................................................... 773.3 Prueba de la Solución ....................................................................................................78

3.3.1 Planificación de Pruebas ...................................................................................................... 793.3.2 Evaluación de Resultados .................................................................................................... 793.4 Descripción del Impacto de la Herramienta ...................................................................803.5 Conclusiones .................................................................................................................81CONCLUSIONES ..........................................................................................................................82RECOMENDACIONES ...................................................................................................................83REFERENCIAS BIBLIOGRÁFICAS ..................................................................................................84BIBLIOGRAFÍA ............................................................................................................................93GLOSARIO DE SIGLAS Y TÉRMINOS ..............................................................................................98ANEXOS ........................................................................................................................................IAnexo 1. Existencia numerosa de herramientas para reportes .................................................IAnexo 2. Novedades de Reportes de Pentaho ....................................................................... IIIAnexo 3. Formato Genérico de una Plantilla de Reporte. .......................................................IVAnexo 4. Reporte Informático definido con criterios de Agrupamiento. ................................... VAnexo 5. Reporte Informático con inclusión de Gráficos. ........................................................VIAnexo 6. Variada Atención de Pentaho al Área de los Reportes ........................................... VIIAnexo 7. Planillas de Encuestas para Clientes de Sistemas de Reportes. ............................ VIIAnexo 8. Relación entre Objetos del Diseñador de Reportes del SQL Server. ........................ XAnexo 9. Relación entre Objetos en el RDL para Reportes de SQL Server .......................... XIIIAnexo 10. Comparación de Frameworks de Reportes de Código Abierto .......................... XVIII

Índice de figurasFIGURA 1. ESTRUCTURA DEL SISTEMA DE GESTIÓN DE RECURSOS HUMANOS GREHU. ..................2FIGURA 2. ESTRUCTURA GENÉRICA DEL PROCESO DE CONCEPCIÓN DE UN REPORTE ....................14FIGURA 3. DIAGRAMA DE CASOS DE USO DEL GENERADOR REPORTES DEL SISTEMA GREHU .......19FIGURA 4. PROCESO CÍCLICO DE CREACIÓN DE REPORTES EN PLATAFORMAS DE REPORTES ........21FIGURA 5. EJEMPLO DEL FORMULARIO “PERSONA” .....................................................................25FIGURA 6. DISTRIBUCIÓN DE USUARIOS ENCUESTADOS POR GRUPOS ............................................26FIGURA 7. ESTRUCTURA DE LA BIBLIOTECA “JASPERREPORTS”. .................................................45FIGURA 8. ALTERNATIVAS DE TIPOS DE CONEXIONES DE IREPORT 3.0.0. .......................................48FIGURA 9. RELACIÓN ENTRE LOS PRINCIPALES OBJETOS DEL DOMINIO. .......................................57FIGURA 10. DIAGRAMA DE CASOS DE USO DEL SISTEMA. .............................................................59FIGURA 11. ESTRUCTURA DEL SISTEMA PROPUESTO ...................................................................60FIGURA 12. FRAGMENTO DEL CUERPO DEL MÉTODO ADDFIELD.....................................................64FIGURA 13. FRAGMENTO DEL CUERPO DEL MÉTODO ADDMETHOD. ...............................................64FIGURA 14. SEGMENTO DE DEFINICIÓN DE UN FICHERO JRXML....................................................65FIGURA 15. MÉTODOS DE LA CLASE JASPEREXPORTMANAGER DE JASPERREPORT ......................65FIGURA 16. ARQUITECTURA DE CAPAS DEL SISTEMA DE GESTIÓN DE REPORTES. .........................70FIGURA 17. PRINCIPALES CLASES DEL MÓDULO DE GESTIÓN DE REPORTES. ................................71FIGURA 18. ESTRUCTURA DE LA BASE DE DATOS DE LA APLICACIÓN. ...........................................73FIGURA 19. PANTALLA DE EDICIÓN DE FUENTES DE DATOS DE IREPORT 3.0.0. .............................75FIGURA 20. VISTA DE EDICIÓN DE LA PLANTILLA DE UN REPORTE. ................................................76FIGURA 21. PANTALLA DE GESTIÓN DE PLANTILLAS COMO DOCUMENTOS XML. ...........................76

Índice de tablasTABLA 1. ROLES DE USUARIOS MÁS COMUNES EN PLATAFORMAS DE REPORTES ..........................17TABLA 2. DESCRIPCIÓN DE ACTORES DEL GENERADOR DE REPORTES DEL SISTEMA GREHU. .......19

INTRODUCCIÓNLa desenfrenada evolución de la computación y la informática han repercutido de manerasorprendente en el mundo moderno sobre el cual se han insertado de manera protagónica enmuchas áreas de diversas actividades humanas. Muchos procesos de gestión de informaciónse han optimizado disminuyendo el tiempo necesario de procesamiento y el costo deoperaciones al aprovechar las ventajas de la automatización por medio de sistemasinformáticos [9] . Las herramientas de gestión de información forman un grupo numeroso dentrode las aplicaciones informáticas. Más allá de la representación, este grupo presenta una granvariedad debido a las diferencias existentes entre los negocios en que se aplica cadaherramienta.La inmensa mayoría de estos sistemas funcionan sobre la idea estandarizada de abastecersede la información obtenida de diferentes fuentes, gestionar las operaciones de procesamiento yexponer los resultados de diversas formas. Una de las alternativas más utilizada para presentarla información, facilitando la apreciación de la misma para los diferentes propósitos que cadausuario tiene, consiste en la obtención de los reportes informáticos [29] .Los reportes informáticos permiten exponer la información con formatos más comprensibles ala apreciación de la visión humana y generalmente están destinados para obtenerlos porpantalla o por algún medio de impresión. Cada uno de ellos está basado en una plantillapredefinida o establecida que contiene la estructura y apariencia que presentará en el momentode su obtención.Algunas fuentes bibliográficas definen a los reportes como sus plantillas [92] , a diferencia deotros criterios que enfocan el concepto a una plantilla en ejecución, por lo que establecen queel “tiempo de vida” del reporte se limita a la duración de dicha obtención [71] . Con el fin derealizar el estudio del presente trabajo, desglosando lo más posible todos los términos, setratará de manera diferenciada las definiciones de plantilla y de reporte según el segundocriterio antes mencionado.La mayoría de los sistemas generadores de reportes difiere en su estructura debido a lospropósitos seguidos por estos en los negocios para los cuales hayan sido implementados ydonde se pretendan implantar. A pesar de esto, la existencia de problemas en un sistemainformático de gestión de reportes muchas veces se extiende a otras herramientas de igualnaturaleza [15][71] , por lo que una solución efectiva de carácter particular pudiera contener unvalor de impacto general en el área.1

INTRODUCCIÓNEl tema abordado en el presente trabajo enfoca el análisis a las herramientas de gestión entérminos de reportes como uno de los componentes de interfaz. Para ello se ha escogido comocaso de estudio al Sistema Informatizado de Gestión de Recursos Humanos (GREHU) en elcual se han detectado varios problemas que afectan a otras herramientas de gestión [71][92] .El GREHU fue desarrollado por del Grupo de Informática Empresarial (GRIE) del Centro deEstudios de Ingeniería de Sistemas (CEIS) hace más de diez años y en sus tiempos de mayorutilización fue la solución de más de 200 entidades empresariales, de servicios y hotelerasdistribuidas por todo el país, lo que demuestra la gran aceptación que este tuvo desde sucreación [53][54] . El sistema, de forma general permite gestionar los Recursos Humanos (RRHH)de diferentes negocios de manera integral independientemente de las diferencias existentesentre ellos. Es un sistema complejo compuesto por 17 subsistemas donde cada uno secorresponde con una de las funcionalidades de la Gestión de los Recursos Humanos (GRH)tales como: Inventario de Personal, Capacitación del Personal, Control de Dirigentes yCuadros, Selección y Contratación, Organización del Trabajo y los Salarios (OTS), entre otras[52][71] (Ver Figura 1). Muchas de las tareas automatizadas tienen que ser adaptadas a lasespecificaciones y requerimientos de cada organización, y por ello en muchas ocasiones, lainformación que se requiere es diferente [71] .Inventario dePersonalPuesto y CasesEvaluación delDesempeñoPrenóminasControl deIncidenciasPago porResultadosSelección yContrataciónDirigentes yCuadrosMódulo PrincipalPropinaColectivaEstimulación enDivisaCapacitación delPersonalSeguridad ySaludPago por TarjetaMagnéticaNóminasControl deAsistenciaCompensaciónPersonalFigura 1. Estructura del Sistema de Gestión de Recursos Humanos GREHU [54] .2

INTRODUCCIÓNEl GREHU ofrece además diversos formatos de reportes para obtener la información deseadaen cada uno de los subsistemas, los cuales son analizados en reuniones, consejos dedirecciones, auditorias y otras actividades que demanden la realización, chequeo y control delas funciones de la organización en la temática de los recursos humanos.La obtención de los diferentes reportes en el sistema GREHU ha sufrido un proceso evolutivo alo largo de sus más de diez años de explotación, debido a que estos se obtenían a partir deplantillas estáticas, lo que imposibilitaba que los usuarios pudieran cambiar o realizar suspropios diseños, acorde con sus necesidades [72][73] . Dada la naturaleza dinámica de los RRHHera necesario someter el diseño de los reportes a constantes cambios para satisfacer lascrecientes necesidades de los usuarios. Estas adecuaciones debían ser realizadas por losespecialistas del GRIE y generalmente no se realizaban en tiempo, debido a la poca cantidadde especialistas, la multitud de clientes y las diferencias entre los cambios demandados. Elequipo de desarrollo del sistema muchas veces tuvo que abandonar las labores deinvestigación y desarrollo de otras herramientas para dedicarse sólo a la reprogramación y elmantenimiento del GREHU. Aun así, muchos de los intentos para satisfacer a los usuariosfueron fallidos, continuando el desajuste en los diseños de los reportes del sistema [71] .Como respuesta a la situación anterior, la dirección del GRIE orientó la creación de un nuevosubsistema del GREHU para generar reportes, el cual debía permitirle a los diferentes usuariospor medio de información no predeterminada, realizar el diseño de nuevos reportes de la formamás personalizada posible [71] .Un tiempo después de desarrollado el nuevo subsistema Generador de Reportes del GREHU,se ha puesto de manifiesto el surgimiento de una nueva situación que aparentemente requiereuna solución más complicada. Esta vez la cuestión no se limita a temas de programación, sinoque involucra aspectos de diseño.El incorporar un generador de reportes en una herramienta de gestión esclarece la exigenciade diferentes roles de usuarios en el proceso de gestión de reportes [92] . Naturalmente, no todoslos usuarios poseen el mismo conocimiento y las mismas habilidades informáticas. Porejemplo, el usuario que condiciona la fuente de obtención de datos necesaria para obtener unreporte no tiene por qué conocer con profundidad el negocio [71] , a diferencia del que conformael reporte, que no necesariamente debe poseer un profundo conocimiento de computación [92]siempre que cuente con buenas herramientas que lo ayuden en su empeño.3

INTRODUCCIÓNA pesar de existir jerarquías de roles de usuarios propuestas para el proceso de gestión dereportes, casi nunca son consideradas al diseñarse un sistema de gestión de información o alconcebir o adicionar generadores de reportes a otras herramientas. Por otra parte, la granvariedad de soluciones para la problemática de los reportes dentro del mundo informático Anexo1 enriquece la posibilidad de diferencias entre las responsabilidades de los usuarios quedesempeñen un papel protagónico en el proceso de gestión de reportes acorde a lassoluciones utilizadas y los negocios o escenarios de acción [92] , por lo que tampoco puedeafirmarse que la jerarquía de roles ofrecida hasta el momento para este propósito sea la óptimapara todas las situaciones.Esencialmente, la complejidad del proceso de gestión de reportes en una herramienta degestión aumenta al tenerse que considerar los roles que se incorporan con la creación y elcontrol de reportes, relacionados no sólo con el negocio, sino también con las exigencias delgenerador para su funcionamiento.Aparentemente, un generador funciona sin problemas al ofrecer al usuario el reporte que estedesea, pero al restringir tareas de creación de reportes y clasificar estos para su visualizaciónde acuerdo con el tipo de usuario, se debe garantizar que la herramienta se ajuste a laestructura de la organización sobre la cual será usada. Es importante evitar la confusión entrelos usuarios de estos sistemas y definir claramente el rol de cada uno de ellos en el proceso degestión.Una vez descrita la situación apreciada en el sistema GREHU posterior a la inclusión del nuevosubsistema Generador de Reportes y después de extenderla al resto de los sistemas degestión de información, es posible definir como problema la carencia de la consideración delos posibles y diferentes roles de usuarios que intervienen en los procesos de gestión dereportes en el subsistema Generador de Reportes del sistema GREHU y la subestimación delimpacto sobre el escenario de uso de una herramienta informática al alterar aspectos de lamisma ignorando dicho tema.Como objeto de estudio de la investigación se define para el escenario cliente/usuario lasmúltiples actividades empresariales, la forma de gestionar la información en las mismas y lasdiferentes responsabilidades asignadas a cada usuario, así como las posibilidades existentesde automatización de los procesos de una organización y las ventajas que esto ofrece. Desdeel escenario del especialista informático se establecen las herramientas y aplicacionesdesarrolladas hasta el momento para facilitar el trabajo con los datos que se manipulan en lasdiferentes actividades empresariales, así como las destinadas a simular el comportamiento de4

INTRODUCCIÓNlos procesos de estas entidades para permitir una remodelación de los mismos de maneraeficiente. También se incluyen las herramientas generadoras de reportes existentes y lasjerarquías de roles de usuarios definidas con estos fines.Como campo de acción se establece desde el escenario cliente/usuario, dentro de la gestiónde la información de las actividades empresariales, la forma de representarla por medio deformatos de reportes o informes y las ventajas que los mismos reportan en cada negocio.Además, se incluyen las diferentes estructuras utilizadas para almacenar y organizar estainformación con la finalidad de presentarla lo más amigable posible y se orienta el estudio hacialos procesos referentes al desarrollo de reportes así como las principales responsabilidades deusuarios frente a los mismos. También, desde el escenario del especialista informático sedefine el campo de acción como a las normas para la representación de la información y loscriterios considerados al conformar de forma eficiente los reportes, tales como: búsqueda,ordenamiento, filtración y selección de la información. Se incluye además las facilidades que seobtienen gestionando al más bajo nivel posible los ficheros que definen plantillas de reportes, afin de lograr la obtención de reportes altamente compatibles con cualquier formato o tecnologíautilizada; y las alternativas que permiten el desarrollo de sistemas flexibles altamenteindependientes de la plataforma en la que sean utilizados y que se puedan acoplar a cualquierbase de datos, sin importar cómo estén diseñadas las mismas. Por último, se adicionan losroles existentes de acuerdo con las jerarquías de los usuarios de los negocios que utilizarán lasherramientas de gestión de información y los roles de usuarios definidos para la gestión dereportes.Como objetivo general del trabajo se establece la realización de un sistema informático paragenerar reportes, que permita gestionar los roles relacionados con los procesos de generaciónpara la distribución de responsabilidades acorde al conocimiento del usuario.Para cumplir el objetivo principal del trabajo se han establecido varios objetivos específicoslos cuales se relacionan a continuación: Seleccionar o concebir el proceso de creación de plantillas de reportes incorporando elmayor número posible de ventajas observadas de acuerdo con los estudios realizados. Elegir o definir un formato de almacenamiento, flexible a las modificaciones, que permitaprocesar plantillas de reportes altamente personalizadas con un elevado grado deindependencia de la plataforma y del ambiente de programación utilizado.5

INTRODUCCIÓN Seleccionar módulos, bibliotecas o herramientas de programación que permitan desarrollaraplicaciones que interactúen con la mayor diversidad de fuentes de datosindependientemente del diseño de estas o de su naturaleza. Seleccionar un entorno de programación de libre distribución que facilite la implementacióny permita el trabajo con potentes bibliotecas para la manipulación de los ficheros; yescoger un lenguaje de programación que permita el desarrollo de aplicaciones flexibles eindependientes de plataformas. Diseñar e implementar un módulo de gestión de roles de usuarios que permita controlar elacceso y los permisos a las diferentes opciones del sistema. Definir e implementar un módulo de gestión de reportes que garantice la extensibilidad,flexibilidad y usabilidad de la herramienta propuesta.Con el propósito de cumplir los objetivos específicos se establecen las siguientes tareas: Realizar un estudio detallado de diferentes asistentes para diseñar y generar reportes conla finalidad de adentrarse en los procesos de gestión de los mismos y en las ventajas queestos presentan. Efectuar un profundo estudio de las múltiples estructuras estandarizadas de ficheros dereportes, así como los más aceptados formatos para la representación y transmisión de lainformación. Estudiar varias herramientas destinadas al trabajo con reportes y analizar la posibilidad deseleccionar una de ellas o incluir las mejores prestaciones observadas, en la soluciónpropuesta. Estudiar módulos programados, bibliotecas y tecnologías de programación que permitan lainteracción con la mayor diversidad de bases de datos. Estudiar el tratamiento de roles de usuarios de diferentes herramientas, particularmentelos definidos para la gestión de reportes, así como herramientas dedicadas a la gestióndirecta de los mismos. Aplicar encuestas a clientes del sistema GREHU y de otros sistemas informáticos quebrinden reportes con la finalidad de conocer las principales incomodidades y ambicionesde estos, con relación a los reportes.6

INTRODUCCIÓN Estudiar mecanismos de control de acceso de funcionalidades a usuarios, así comoentornos de trabajo existentes para el manejo de la seguridad en función del controlmediante políticas de acceso y permisos. Realizar una prueba segmentada de la solución y registrar el desempeño de los usuariosante la misma.Como hipótesis se establece que si se desarrolla una aplicación informática para generarreportes de manera dinámica y personalizada, que permita gestionar los roles de usuarios paradistribuir correctamente las responsabilidades de estos en los procesos de gestión de reportes,se logrará una mejora en la automatización de tales aspectos y se aumentará el grado deaceptación relacionado con el funcionamiento de los reportes en los sistemas de gestión deinformación, por parte de los usuarios.En detalle, la aplicación informática a implementar debe permitir realizar plantillas de reportesaltamente personalizadas y acoplarse a distintas fuentes de datos ya existentesindependientemente del diseño que posean estas, su naturaleza y los gestores de bases dedatos utilizados para la creación de las mismas. La herramienta debe ser aplicable a lasdiferentes organizaciones en las que se desee utilizar, para lo cual se ha de desarrollar unmódulo de gestión de roles considerando que la jerarquía de usuarios para conformar y obtenerreportes puede cambiar en función de la organización donde se utilice la solución. EL sistemadebe crearse bajo la concepción de independencia de plataformas, software libre, y para sudesarrollo deberán utilizarse formatos y tecnologías de ficheros que hagan posible lacomunicación y transmisión de la información independientemente a los disímiles ambientes ytecnologías de programación existentes.La aplicación informática debe contar además, con una potente ayuda para facilitarles a losusuarios su utilización, así como un manual de usuario, donde se describa de forma detalladala manera de aprovechar al máximo sus funcionalidades, y un manual de programación quepermita la comprensión de contenidos claves para el mantenimiento y continuidad del trabajopor parte de profesionales informáticos.Entre los principales aportes prácticos esperados con la realización del presente trabajo seencuentran: Una herramienta que exponga una interfaz intuitiva que se ajuste a las necesidades delusuario que pretenda utilizarla para de esta forma evitar confusión en su uso.7

INTRODUCCIÓN La posibilidad de que los usuarios vean reflejada la estructura de su organización acorde asus requerimientos. El aumento del protagonismo de los usuarios respecto al papel que estos juegan frente aun sistema informático. La revelación de la existencia de problemas que están siendo obviados evitandocomprometerse con soluciones que demanden una mercada complejidad.El presente documento constituye el informe principal de la investigación realizada y laimplementación de la herramienta desarrollada. El mismo está estructurado en introducción,contenido (distribuido en tres capítulos), conclusiones, recomendaciones, referenciasbibliográficas, bibliografía, glosario de siglas y términos, y anexos. En el primer capítulo sedescribe el trabajo que antecede al presente, las deficiencias detectadas, el estudio del estadodel arte efectuado y otros detalles de la investigación. El segundo capítulo fundamentalmentese encarga de presentar aspectos de la concepción de la solución propuesta y en el tercer yúltimo capítulo se exponen temas relacionados con la implementación, las pruebas realizadas yel análisis de los resultados alcanzados.8

CAPÍTULOICAPÍTULO I. ANTECEDENTES Y DETALLES DE LA INVESTIGACIÓN

CAPÍTULO I. Antecedentes y Detalles de la Investigación1.1 IntroducciónEl presente capítulo comienza con un análisis de los antecedentes de la gestión de reportes enel campo de la informática introduciéndose de esta forma conceptos fundamentales en lainvestigación que serán utilizados en el resto del trabajo. Seguidamente se realiza un análisiscrítico al generador de reportes diseñado para el sistema GREHU y se enfatiza en losproblemas ya existentes, pero esclarecidos con la inclusión de la nueva herramienta.Una vez realizado el análisis crítico al generador de reportes del GREHU y exponer detalles dela problemática, se extiende la situación al resto de las herramientas generadoras de reportes yse expone el estudio del estado del arte realizado pretendiendo concebir la mas óptima de lassoluciones en función de cumplir con el objetivo fundamental del trabajo. Por último y demanera tentativa, se exponen las ventajas observadas en los sistemas existentes estudiados ylos posibles defectos en las soluciones brindadas hasta el momento, fundamentandocorrectamente la decisión de seleccionar una herramienta ya existente o comenzar el desarrollode una totalmente nueva haciendo uso de bondades, bibliotecas o componentes ya existentes.1.2 Antecedentes de la Gestión de ReportesLos reportes informáticos han exigido un lugar en las ciencias de la computación desde susinicios. Primeramente, como muchos otros temas de la informática, no fueron consideradosrelevantes y al transcurrir el tiempo han logrado capturar la atención de expertos, aunque seconsidera que aun en la actualidad existen problemas relacionados con ellos que son pasadospor alto [92] .Con el paso del tiempo las propuestas de soluciones para la gestión de reportes han idoaumentando su complejidad y variedad [19] (Ver Anexo 1). Actualmente existen múltiplesherramientas que son clasificadas de acuerdo con diferentes criterios. En cuanto al propósitodel trabajo del usuario final se pueden mencionar los grupos de [71] : Bibliotecas, componentes y herramientas: Destinados generalmente a la creación degeneradores de reportes, aunque permiten desarrollar reportes para sistemas informáticoscon fines específicos diferentes al de los generadores de reportes. Generadores de reportes: Permiten crear reportes para otras herramientas.10

CAPÍTULO I. Antecedentes y Detalles de la Investigación Herramientas de gestión de información: Sistemas de propósitos bien definidosencaminados a cumplir con la automatización de procesos de negocios. Presentanreportes basados en plantillas estáticas.Otro criterio que se utiliza para clasificar las herramientas de reportes viene dado por laextensión del impacto que estas tienen. Bajo este enfoque se encuentran las herramientascomunes y las plataformas de gestión de reportes [92] .La diversidad de clasificaciones de herramientas de reportes sólo es citada con el propósito deexponer la complejidad que estas han ido alcanzando con el tiempo. Para la realización delpresente trabajo no se requiere clasificación alguna, debido a que se intenta resolver uno de losproblemas que de alguna forma ha sido ignorado hasta el momento. En epígrafes posterioresse detallará al respecto haciendo mención y comparaciones de alternativas que puedan aportaren alguna medida a la solución del problema presentado.1.3 Conceptos ClavesLa gestión de reportes informáticos con el tiempo se ha complejizado, por lo que ha sidonecesario definir conceptos para formalizar las bases teóricas de dicha área. Para ello se hanestudiado aspectos relacionados a la forma de recuperar la información necesaria para crearlos reportes, así como los elementos relacionados a la manera de exponerla. Para estasdefiniciones es importante considerar que existen aspectos de otros campos de la informáticaque ofrecen bondades para el perfeccionamiento de los sistemas de gestión de reportes.1.3.1 Gestión de ReportesSeguidamente se introducen los principales conceptos tenidos en cuenta en el presente trabajopara el estudio de la gestión de los reportes. Además se expone la estructura del proceso sobreel cual se basa la concepción y exportación de estos.1.3.1.1 Fuentes de DatosLas fuentes de datos esencialmente constituyen el punto de abastecimiento de los reportes [71] .Son el primer aspecto a gestionar para la creación de los mismos, debido a que no solo brindanla información a mostrar, sino que en función de ellas son diseñadas las plantillas. En elproceso de gestión de reportes es importante conocer qué es lo que este debe contener parapoder definir cómo hacerlo.11

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónActualmente, el mayor problema relacionado con las fuentes de datos viene dado por el temade la compatibilidad debido a la gran diversidad existente. Con la popularidad alcanzada por lossistemas de gestión de datos y la gran variedad de opciones que estos presentan para elalmacenamiento y consulta de los datos, así como las contradicciones de compatibilidad entreplataformas y herramientas, la naturaleza de las fuentes de datos ha experimentado un fuertecrecimiento en cuanto a diversidad.1.3.1.2 Plantilla de ReporteEl fichero que almacena la estructura del reporte, contiene, casi en su totalidad, la plantilla delmismo. Generalmente, la plantilla constituye un fichero que además incluye en su estructura,datos sobre la fuente que brinda la información y la forma de mostrarla (formato de la página yconfiguración de impresión). Además, con frecuencia se asocian a ella detalles de la aparienciaexterna del reporte como color, formato, estilo de las fuentes, etc [71] .Es importante destacar que junto a la atención que han ido ganando con el tiempo los reportesdentro de las ciencias de la computación, también ha evolucionado la estructura de susplantillas. Si desde un inicio, la plantilla solo era analizada como un elemento más de la interfazgráfica de usuario, actualmente no solo incluye aspectos de suministro de información, sino quese ha complejizado cada aspecto de la misma llegándose a estandarizar muchos de losficheros existentes que la representan [17][49][55] . Vale la pena destacar que una plantilla dereporte en la actualidad presenta una estructura compleja que permite una elevada completitudpara facilitar el alcance de los propósitos perseguidos con los reportes.En cuanto a la parte visual de las plantillas, también se han alcanzado considerables bondadesal estandarizar sus elementos principales [58] los cuales regularmente son [33][71] [13]: Las Bandas: Definen el espacio donde se ubicará cada componente visual de la plantilla.En dependencia de la banda donde se sitúe un componente podrá extender susfuncionalidades (Ver Anexo 3). Componentes Visuales: Etiquetas, formas (líneas y demás figuras geométricas),imágenes, tablas, gráficas y campos de exposición dinámica de información.1.3.1.3 Carga de Datos y Representación de InformaciónUna vez seleccionada una fuente de datos para la creación del reporte y concluido el procesode creación (Ver Epígrafe 1.3.1.5) queda conformada y almacenada la plantilla, después sólo restaobtenerlo para visualizar la información ya sea por pantalla o por impresora.12

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónAl orientarse la ejecución de la plantilla generalmente se carga la información de la fuente ysolo después es mostrado el reporte. Existen algunas herramientas que hacen obligatoria estasecuencia, otras permiten imprimir un reporte mostrando información almacenada en la plantilladurante su última carga [33] . Esto incorpora el riesgo de exponer información obsoleta si no setiene en cuenta la frecuencia de cambios de los datos de la fuente, aunque también ofrece laventaja de permitir mayor portabilidad en los formatos de las plantillas.1.3.1.4 Formatos de Reportes y ExportaciónMuchos formatos de reportes con el tiempo han convergido sobre estructuras comunes y sehan estandarizado con el propósito de llegar a ser compatibles con múltiples entornos yherramientas [17][55] . Bajo tecnologías como la XML actualmente es posible desarrollar plantillasde reportes que sean reconocidas por diferentes sistemas, esto ha hecho a muchosdesarrolladores pensar en las plantillas como un producto que pueda distribuirse con una granindependencia del gestor o cualquier otro sistema que antes fuera considerado indispensablepara la obtención del reporte.Aunque desde sus inicios, la gestión de los reportes comenzó a incorporar disímiles formatosde ficheros y aun existen conflictos de compatibilidad por la diversidad que estos presentan, elfuturo promete dar paso a favor de la unidad en búsqueda de independencia entre plataformas,ambientes y herramientas. Una funcionalidad muy popular implementada en los gestores alrespecto ha sido permitir exportar sus reportes a formatos reconocidos por la mayoría de lastecnologías, enfocando a la extensibilidad como un requisito crítico en ellos [33][49] . Muchos deestos formatos pueden ser reconocidos por visores de texto, como el popular PDF, de usoestandarizado en diferentes ambientes de programación.1.3.1.5 Proceso de CreaciónComo fue descrito anteriormente, al concluir el proceso de creación de la plantilla, ésta quedaconformada y almacenada, conteniendo toda la estructura del reporte, restando sólo suejecución para poder obtener el reporte. La necesidad de conocer la información que semostrará de una fuente es primordial para establecer criterios de ordenamiento, agrupamiento yselección o filtrado de la misma.Este proceso generalmente está representado por asistentes que le permiten al usuario, sin lanecesidad de conocimientos profundos de computación, diseñar reportes que pueden contenerhasta gráficos. Otra forma de desarrollar la creación es mediante la gestión directa de laplantilla basándose en una vista gráfica de esta. Aunque de esta forma se necesita tener un13

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónconocimiento más profundo de la herramienta, con ella se logra alcanzar un diseño másajustado a las necesidades del usuario.De cualquier forma, con el tiempo el proceso de creación de reportes se ha estandarizado y lamayoría de las herramientas lo conciben formado por pasos, algunos de los cuales nonecesariamente se realizan siempre en un mismo orden [70][71] . En la Figura 2 se expone suestructura genérica comenzando la secuencia de los pasos de arriba hacia abajo.Definición de Fuentes de DatosSelección de la InformaciónOrdenamiento Agrupamiento FiltradoInclusión de Operaciones Lógicas y MatemáticasInclusión de Gráficos o TablasGestión Gráfica de la PlantillaEjecuciónImpresiónExportaciónFigura 2. Estructura Genérica del Proceso de Concepción de un Reporte [70][71] .Cada paso dentro del proceso tiene un propósito bien definido. Seguidamente se expone laesencia de cada uno de ellos [70] : Definición de fuentes de datos: Establecimiento de conexiones a bases de datos,fragmentos de bases de datos o ficheros que abastezcan de información al reporte.Constituye el primer paso a efectuar en la concepción de la plantilla. Selección de la información: A partir de la fuente seleccionada, se escogen de los datosque suministra la misma los que se desean mostrar en el reporte. Ordenamiento: Consiste en establecer criterios de ordenamiento acorde a los datos queserán mostrados debido a que carece de sentido utilizar como criterio de ordenamientoalguna información que no se mostrará en el reporte. Al igual que el resto de los pasos que14

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónsiguen hasta la concepción final de la plantilla, no tiene un orden fijo dentro del procesodebido a que puede variar en dependencia de la herramienta que lo implemente. Agrupamiento: No es más que la creación de grupos lógicos para establecer unaapariencia eficiente en el reporte facilitando la localización de la información expuesta.Este paso permite la incorporación de operaciones matemáticas que aportan informaciónparcial sobre cada grupo facilitando la toma de decisiones (Ver Anexo 4Anexo 1). Algunasherramientas limitan el número posible de grupos a crear. Filtrado: Consiste en seleccionar la información de acuerdo con criterios que en ocasionespueden tornarse complejos, por lo que muchas herramientas pueden incluir editores deexpresiones lógicas para realizar el mismo. El filtrado no necesariamente tiene querealizarse por datos que serán mostrados en el reporte, puede exponerse informaciónfiltrada por criterios que actúan sobre datos no expuestos. Un ejemplo lo constituye ellistado de las obreras de una fábrica, donde se muestran los nombres de las trabajadoraspero no su sexo. Inclusión de operaciones lógicas y matemáticas: Consiste en incorporar a la plantillaoperaciones de sumatorias, cálculos de promedios, etc. Este paso puede requerir de uneditor de expresiones matemáticas para definir criterios complejos y puede realizarseconjuntamente con el paso de agrupamiento antes descrito. Un ejemplo lo constituye lacuenta de trabajadores por departamentos, este proceso suele ser nombrado “cálculo delsubtotal” o “sub-acumulados”. Inclusión de gráficos o tablas: Mediante datos seleccionados de la fuente se generangráficos de diferentes clases o se forman tablas que serán expuestas en el reporte. Puedeutilizarse información generada a partir de operaciones lógicas y matemáticas incluidas(Ver Anexo 5). Edición de la plantilla: Una vez realizado todo el proceso se genera la plantilla o el formatodel reporte. En ocasiones, algunas herramientas permiten la edición de la misma parapersonalizar hasta el más mínimo detalle, ya sea el color de formas, la incorporación defiguras o la distribución exacta de los componentes en las diferentes bandas.Generalmente, al concluir la definición de la plantilla se realiza su almacenamiento físico. Ejecución del reporte: Una vez concluido el proceso de creación del reporte puederealizarse la ejecución de este para su impresión. Muchas herramientas obligan a ejecutaruna vista previa para solo después ofrecer las opciones relacionadas a la impresión enformato duro o permitir exportar a otros formatos de fichero acorde al propósito del15

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónusuario. Este proceso puede resultar tedioso en ocasiones, sobre todo si se estáconsultando constantemente el reporte para su impresión, aunque el mismo aumenta laposibilidad de detectar y corregir errores antes de la entrega del reporte a su destino final.1.3.1.6 Otros Aspectos RelevantesOtros conceptos relacionados con los reportes y sus plantillas son los que inciden directamenteen la forma de visualizar el diseño, ya sea orientación, paginado o configuración de impresión.No todos estos aspectos pueden ser gestionados de modo personalizado en cada herramienta,algunas simplemente definen un criterio por defecto y lo usan siempre igual como un detalleoculto al usuario. Seguidamente se resume la esencia de cada uno de estos elementos [71] : Orientación: Define la forma en que se expondrá el contenido en la plantilla: horizontal (porcolumnas) o vertical (por filas). Paginado: Permite establecer el tipo de hoja que será utilizada para la impresión. Configuración de Impresión: Almacena información sobre impresoras (virtuales operiféricos de hardware) a utilizar.1.3.2 Temas Básicos de Seguridad InformáticaLa seguridad es otro de los aspectos a tratar en el desarrollo de la herramienta que se proponeen este trabajo. En tal sentido, la investigación esencialmente se enfoca a la definición de rolesde usuarios, el establecimiento de políticas de seguridad, el control de acciones y registro detrazas, así como la implementación de algoritmos que ofrezcan un tratamiento personalizado ala misma.Es importante comprender los roles de usuarios como clasificaciones en grupos de usuarios,considerando la presencia de restricciones y privilegios que sobre estos se establecen. Laesencia de los roles es el enfoque conceptual del comportamiento del usuario ante laherramienta. Cuando un usuario interactúa con un sistema de manera diferente puede estarrepresentando un rol distinto, por lo que es el papel que este desempeña frente al sistema loque determina el rol a desempeñar.Es entonces una tarea delicada tratar la gestión de roles de usuarios y modificar los mismos, yaque al alterarlos, en vez de modificarlos pudieran estar simplemente dejando de existir dandolugar a otros nuevos.16

CAPÍTULO I. Antecedentes y Detalles de la Investigación1.3.2.1 Los Roles de Usuarios en la Gestión de ReportesEl tratamiento de los roles de usuarios en la gestión de reportes se ha descuidadocondenándolo muchas veces al tratamiento estático, abandono u olvido. De manera generalalgunas herramientas, sobre todos las plataformas de reportes, definen estructuras como ladetallada en la Tabla 1, pero el dinamismo de los negocios demanda un tratamientopersonalizado en tal sentido [92] .Tabla 1. Roles de Usuarios más Comunes en Plataformas de Reportes [92] .RolConsumidores deReportesDescripciónUsan la información de los reportes y son conocedores del funcionamiento delnegocio, aunque no necesariamente conocen de la plataforma.Usuarios Expertos Poseen conocimiento del funcionamiento del negocio y suficiente conocimientoacerca de la plataforma de reporte que les facilita algún grado de autoservicio.Autores deReportesAdministrador deReportesPoseen un conocimiento limitado del negocio y una elevada experiencia en lasplataformas de reportes, así como grandes habilidades para el diseño de estos.Conocen muy limitadamente el negocio. Tienen experiencia técnica sobre lasplataformas de reportes, así como conocimiento profundo de las fuentes de datosque abastecen a los mismos.Los roles expuestos en la tabla anterior sólo representan un ejemplo de algunas propuestashechas por algunas plataformas. Si bien es cierto que dentro de las numerosas soluciones queignoran el tema se destacan las que en alguna medida proponen sus jerarquías de usuarios,hay que insistir que el dinamismo de tal área dentro de la gestión de la información demandade roles variables que deben ser estudiados durante más tiempo de manera precisa en losescenarios variables de los negocios [92] .La ineficiencia de los roles antes expuestos puede validarse al no ajustarse tal jerarquía comosolución a la situación problemática que se describiera al inicio de este documento. Taljerarquía limita su efectividad sobre plataformas en escenarios condicionados que garantizansu correcto funcionamiento.1.4 Trabajo Previo RealizadoLa problemática definida en esta investigación tiene como antecedentes un trabajo realizadodesde hace algún tiempo en la temática de los reportes con el desarrollo del subsistemaGenerador de Reportes del Sistema GREHU antes mencionado. El sistema GREHU posee tresactores de sistema principales: el especialista en recursos humanos, el especialista en17

CAPÍTULO I. Antecedentes y Detalles de la Investigacióncontabilidad y el especialista informático. No obstante, esta definición de roles fue alterada porla inclusión de la nueva herramienta.1.4.1 Breve descripción del Generador de Reportes del GREHUEl Generador de Reportes del sistema GREHU posibilita efectuar cualquier actividadrelacionada con los reportes dentro del sistema. En él se permiten realizar operaciones como lapreparación y organización de fuentes de datos destinadas a abastecer de información a losreportes. Estas fuentes de datos se forman por grupos creados para contener los diferentesficheros de información que elija el usuario, los cuales pueden relacionarse según se estimeconveniente siempre que exista un sentido semántico. Otras de las funciones que brinda elsubsistema es permitir diseñar reportes, almacenando su plantilla para realizar sobre estacualquier modificación deseada posteriormente, o para reutilizar un determinado diseño con lafinalidad de ahorrarse la creación completa de un nuevo reporte de apariencia similar a algunoya existente [71] .Los principales requisitos que rigen el funcionamiento del Generador de Reportes del GREHUson [73] : Diseñar nuevos reportes con opciones de restricciones y agrupación incluidas. Clasificar los reportes disponibles para ser ejecutados. Ejecutar reportes del repositorio. Asignar, modificar o retirar diferentes permisos sobre un conjunto de reportes a roles deusuarios predeterminados. Eliminar reportes del repositorio. Renombrar o modificar el diseño de los reportes del repertorio. Distribuir los reportes creados por los diferentes menús del sistema GREHU.En gestión de las fuentes de datos, así como las demás tareas, son asignadas a roles segúnlos privilegios otorgados a estos acorde al conocimiento requerido. Por último, la funcionalidadde distribuir los reportes por los diferentes subsistemas que conforman el sistema garantiza unacceso rápido a la ejecución de los reportes por parte de los usuarios, los cuales conocerán laubicación indicada por ellos mismos [73] .Con la inclusión del generador de reportes se adicionan al sistema GREHU nuevos roles comopropuesta para el uso de esta herramienta (Ver Tabla 2).18

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónTabla 2. Descripción de actores del Generador de Reportes del Sistema GREHU [71] .ActorConsultor deInformes.Diseñador deReportes.Experto en elsistema.DescripciónEncargado exclusivamente de ejecutar los reportes para obtener con ellos lainformación deseada.Encargado de crear nuevos diseños de reportes y actualizarlos teniendo en cuentala coherencia de los datos del reporte a mostrar.Posee los privilegios que le permiten configurar las Fuentes de Datos que sirvencomo base al trabajo con los diseños.A estos actores se les asignan determinadas responsabilidades acorde con los procesosdefinidos en el generador. (Ver Figura 3) Entre ellos se establece una jerarquía que se ajustasupuestamente al uso de la herramienta cumpliendo los requerimientos planteados, sinembargo no se tiene en cuenta que un proceso de gestión de reportes puede necesitar unajerarquía de de roles de usuarios más complicada.Gestionar Grupo de DatosGestionar FicheroGestionar RelaciónExperto en elsistemaConsultor deInformesEjecutar ReporteDiseñador deReportesAlmacenar Plantilla de ReporteGestionar Plantilla de ReporteFigura 3. Diagrama de Casos de Uso del Generador Reportes del Sistema GREHU [71] .19

CAPÍTULO I. Antecedentes y Detalles de la Investigación1.4.1.1 Análisis CríticoLas funcionalidades básicas de la gestión de reportes demandan claramente de roles deusuarios que desempeñen tales actividades [71] . Aunque aparentemente la jerarquía propuestapor el generador de reportes puede satisfacer tal necesidad, funcionalidades como lasdiferentes acciones sobre el repositorio y sobre todo, la distribución de los reportes por losdiferentes subsistemas del sistema GREHU, pueden demandar clasificaciones más cuidadosasentre los diferentes usuarios, es por ello que se considera que tampoco esta jerarquía esóptima u ofrece una solución al problema definido.Es importante destacar que los requisitos funcionales de la herramienta se han implementadoenfocados a la jerarquía de roles de usuarios definida para la misma. El subsistema Generadorde Reportes del GREHU no permite adicionar nuevos roles, únicamente garantiza modificar lospermisos de los ya existentes para controlar las posibles acciones que pudieran realizar sinalterar el sentido del papel que estos desempeñan dentro del sistema.1.4.1.2 Extensión de los defectos observadosEl problema existente, pero oculto, referente a la naturaleza variable de las jerarquías de rolesde usuarios en los procesos de gestión de reporte acorde al negocio que modele el sistema,emerge claramente con la inclusión del Generador de Reporte en el sistema GREHU. Lo quese pretendía utilizar como una herramienta que pudiera utilizarse como ejemplo para extendersus funcionalidades a otros sistemas similares resultó ser un catalizador de una situaciónencubierta que se expande a cada herramienta de gestión de información que gestione susreportes de manera independiente [71] . Hasta este momento se han descrito dos variantes dedefiniciones de roles para el proceso de gestión de reportes y ninguna de ellas parece tener laclave de la solución buscada (Ver Tablas 1 y 2).1.4.2 Otros trabajos realizadosLa jerarquía de roles propuesta en el Generador de Reportes del GREHU no puede utilizarsede manera absoluta en toda situación que involucre reportes, algo que de manera similarocurre con el resto de las jerarquías definidas estudiadas hasta el momento, las cuales parecenesquivar la relevancia del asunto [92] . En otros análisis realizados en trabajos de estudio deplataformas de reportes y demás herramientas se ha concluido que estas deben responder consoluciones ante los elevados tiempos necesitados para la concepción y mantenimiento dereportes, estos aspectos deben ser cuestionados y analizados, buscando el posible problemaque los desate en vez de ignorarlo [92] .20

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónUn ejemplo claro del estancamiento en los servicios de mantenimiento sobre plataformas dereportes se aprecia en la interacción de los roles más comunes en esta área, descritos en laTabla 1, y sus desempeños en el proceso cíclico de creación de reportes más comúnmenteusado (Ver Figura 4).1. Necesidad de un usuariodel negocio de tomardecisiones, careciendo dealguna información.2. El usuario del negociosolicita al usuario experto laproducción de un reporte.6. El usuario del negociosolicita al usuario expertoel cambio en el reporte.3. El usuario expertodiseña el reporte.5. El usuario del negocioexamina el reporte yrealiza observacionessobre nueva informaciónrequerida a adicionar.4. Se efectúala ejecucióndel reporte.Figura 4. Proceso Cíclico de Creación de Reportes en Plataformas de Reportes [92] .El punto crítico en la creación de reportes se presenta cuando surgen requerimientos decambios para el usuario final. Para satisfacer los mismos puede necesitarse de un tiempoprolongado de implementación. Para cada enlace de la cadena “Usuario Experto – Autor deReportes – Administrador de Reportes” en el tercer paso, cuando se requiere de cambios en elreporte, el retraso del proceso puede incrementarse, llegando a ser un factor significativo. Enesencia, lo que impide el flujo de producción dado un cambio en los requerimientos del diseñodel reporte es el número de iteraciones del ciclo de diseño [92] .Considerando las necesidades, la atención y los gastos de tiempo de los usuarios, se puedeasegurar que la temática de los reportes es una de las más significativas dentro de lasorganizaciones de medio y gran tamaño. Generalmente, estas presentan o requieren al menosuna plataforma de reportes, por lo que los problemas antes descritos pueden afectarlas atodas. No obstante, la mayor parte de los investigadores académicos relacionados con el temaparece ignorar estos aspectos, concentrándose en áreas con fines más comerciales o dediferentes propósitos [92] .21

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónAspectos que claramente permiten asegurar la falta de atención a la relevancia de los reportesconstituyen los siguientes [92] : Los académicos no han reconocido ningún aspecto conceptual clave que sea heredado opermita su reutilización y evolución en futuras investigaciones, garantizando unacontinuidad de estas y la obtención de productos paralelos a la rápida evolución de lacomputación. Existe resistencia por parte de los académicos de competir con los equipos deinvestigación y desarrollo, proveedores de plataformas de reportes desde la toma deconciencia, por estos equipos, de los inminentes cambios y la apropiación de la mayorparte de dicha área en el mercado del software internacional. Los académicos aprecian la gran variedad de tecnología de plataformas de reportes comopropietaria y por consiguiente, más allá de su control, percepción o incumbencia.Fundamentalmente, las principales consecuencias provocadas por esta desatención son [92] : El área de los reportes, particularmente las plataformas de reportes, contiene temasconceptuales turbios o no completamente resueltos, así como otros aspectos ensurgimiento, como los relacionados con el crecimiento y la antigüedad de los reportes. Existen aspectos claves en el área de reportes ignorados por los proveedores (y laposibilidad lamentable de que continúen siendo ignorados). Esto en parte puede deberseal nivel de dificultad de estas cuestiones y de la necesidad de bases teóricas solidas paralas posibles soluciones. El aumento de la necesidad de integración de reportes con otras aplicaciones ha forzado alos propietarios y proveedores a publicar y distribuir gran parte de la tecnología comodominio público.Aunque los aspectos antes mencionados ponen en evidencia la existencia de otros problemas,además del tratado en el presente trabajo, es evidente que la temática de los reportes requiereuna mayor atención por los especialistas dada su importancia y las debilidades antesmencionadas. Particularmente, el último punto, donde se expone claramente que el problematratado en este trabajo ha sido detectado y extendido a externos.Una vez estudiada la temática de los reportes enfocados a las plataformas, y al detectar laexistencia de problemas similares en el generador de reportes incluido en el GREHU, sedecidió comenzar a realizar un estudio intenso sobre los requerimientos, necesidades y22

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónopiniones de usuarios potenciales de reportes de diversos negocios en diferentesnacionalidades por medio de cuestionarios (Ver Anexo 7).Afortunadamente, a la par que se realizaban estas entrevistas se detectó, por medio deinvestigaciones y consultas con especialistas, que un tema crítico para la búsqueda de lasolución es la captura de requisitos en la formación de un sistema. La mayoría de lassoluciones informáticas actuales son desechadas por un mal trabajo en este campo [15] ,terminando por representar erróneamente las necesidades de los usuarios, evidenciado ya seacon un procesamiento erróneo de las operaciones o por un mal diseño de la interfaz,clasificación que naturalmente incluye los reportes como elementos gráficos de interacción conlos usuarios. No solo el trabajo sobre los requerimientos, sino la orientación del diseño desistemas en función de los objetivos de la labor que realiza cada usuario, son indispensablespara la obtención de herramientas que se ajusten a los propósitos deseados [15] .Por lo anteriormente mencionado, se detuvo el proceso de realización de encuestas y seencaminó el trabajo en función de los requisitos y los objetivos que rigen la labor de los futurosusuarios. Se comenzaron a investigar criterios de desarrollo de sistemas como la Ingeniería deRequisitos guiada por Objetivos [95] y Metodologías “Persona-Escenario-Objetivo” o PSG (segúnsus siglas en inglés) [1][2] .Tanto los roles como los requerimientos de los sistemas de gestión de reportes pueden variardebido a la gran diversidad de usuarios, la variedad de clientes y los diferentes objetivos queestos pueden demandar con la solución. Muchos usuarios a veces no se tienen en cuenta enlos procesos de análisis y diseño de un sistema. También las diferencias culturales de cadadesarrollador provocan que a una misma problemática se le puedan ofrecer distintas solucionesbajo diferentes percepciones [60] . Por estas razones, para desarrollar óptimamente los procesosde Ingeniería de Requisitos con el fin de obtener los requerimientos de usuarios que pudierandesconocerse, es que se define el Método de Hanako, basado en el uso de personas yescenarios [1] .Persona se define como un elemento ficticio que representa un grupo de usuarios. Lascaracterísticas ficticias son elegidas de manera tal que una persona surge como unarepresentación real de un grupo de usuarios. Cada persona encapsula un conjunto diferente depatrones de comportamientos en relación al uso de un producto particular. Es por ello que elformulario utilizado para registrar la información de una persona exhibe un conjunto de camposque registra atributos humanos como género, edad, raza, datos familiares, cuestionessocioeconómicas, laborales y de ambiente hogareño [74] .23

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónEl Método de Hanako por medio de personas realiza una modelación más concreta y menoselástica que la obtenida con los roles, donde se ajusta forzadamente un producto a ciertosrequerimientos. El uso de personas en los procesos de diseño es una nueva práctica quecategoriza a los usuarios como primarios, secundarios, auxiliares, abastecidos y negativos [15] .Las necesidades de las primarias, secundarias y auxiliares están directamente relacionadascon las características que debe presentar la solución. Una persona abastecida o servida se vedirectamente afectada por el producto y su uso. Una persona negativa es un ejemplo de paraquién no ha sido diseñado el sistema.Las personas siempre tienen sus propias necesidades y expectativas registradas en unconjunto de actividades o eventos dentro de un contexto determinado nombrado “Escenario”.Los escenarios comúnmente se utilizan para describir métodos de diseño de soluciones aproblemas de manera concreta [10] utilizando las situaciones que dieron surgimiento a losproblemas. El Método de Hanako conecta grupos heterogéneos de usuarios acorde a lasasociaciones de los escenarios de los mismos, y posibilita a los desarrolladores analizar ydiseñar aplicaciones que respondan a grupos masivos de usuarios [60] .Por otra parte, el uso del “Método de Ayoama” [2] incorpora el análisis de los objetivos al Métodode Hanako. Los objetivos se definen como propósitos que se intentan cumplir [95] , estos existenen cada actividad que realiza la persona y están estrechamente relacionados con susnecesidades y expectativas como individuo. Los objetivos sirven como filtros a las tareas ycomo guías para estructurar la representación de la información y el control de los procesosinteractivos en la construcción de Escenarios [15] . Los productos con grupos grandes deusuarios tienden a ser por naturaleza abstractos y por ello es más difícil obtener de manerabien definida sus requerimientos. La mayoría de ellos son construidos basados en criteriosingenieriles y responden vagamente a las necesidades de los usuarios. Los desarrolladoresgeneralmente orientan el trabajo a las características, la tecnología y la metodología, ignorandoen muchas ocasiones lo que realmente desea el usuario, sus necesidades y las reglas de losnegocios [15] . El resultado de esto desafortunadamente son sistemas que fallan en conocer orepresentar las necesidades de los usuarios [35][47][98] . Los objetivos que persiguen los usuariosen su desempeño laboral, y no los rasgos de los sistemas informáticos, son la clave del éxitopara la obtención de una buena herramienta [15] . Por ello la integración de los objetivos en elMétodo de Hanako por parte de Ayoama, para evaluar requerimientos y analizar los posiblesconflictos entre estos [2] .24

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónDespués de un estudio de las teorías antes analizadas, se realizaron algunas entrevistas a losusuarios en cuanto a los objetivos de sus labores, sus necesidades y requerimientos en elfuncionamiento de la organización. Apreciando los múltiples clientes del sistema GREHU, ladiversidad de los negocios que lo utilizan y la variedad en el nivel y las habilidades quepresentan sus usuarios, se comenzó a interactuar con estos en secciones individuales paraobtener información llenando el formulario de Persona (Ver Figura 5).FotoNombre: Mabel Mesa Silva Sexo: Femenino Edad: 28Departamento: Recursos HumanosRol: Especialista en Gestión de Recursos HumanosObjetivos: Mantener la información actualizada utilizando el sistemaGREHU. Generar reportes que respondan a la solicitud de directivos y ala actividad diaria.Habilidades: Conocer la interfaz de los subsistemas de pago. Conocer sobre la Gestión de Recursos Humanos y otros temasrelacionados. Presentar un conocimiento básico de computación, así comoáreas relacionadas a la GRH.Tareas: Imprimir reportes mensuales de pago y otros solicitados. Registrar y actualizar constantemente los datos de losempleados.Deseos: Obtener un mayor conocimiento del sistema GREHU pararealizar el trabajo de manera más sencilla.Otros Detalles: (personales y profesionales)Figura 5. Ejemplo del formulario “Persona” con datos obtenidos en una entrevista [60] .De cualquier manera, el uso de estas metodologías para la recolección de información falló, almenos con los clientes del sistema GREHU. Los motivos se discutieron entre dos posibilidades:la falta de cultura de los especialistas y usuarios en el uso de tales alternativas y la incapacidadde ubicarse en el escenario y comprender y expresar sus necesidades.Aplicar las entrevistas requiere de tiempo y orientación por parte de los especialistas a losentrevistados, por tal motivo, si no se posee un buen entrenamiento y cultura al respecto,desde un inicio, se parte erradamente y naturalmente, a los usuarios les cuesta trabajoenfocarse en lo que se les pide.Un ejemplo claro lo constituyen once personas entrevistadas en tres entidades. El conjunto detrabajadores seleccionado fue aleatorio, incluyendo personas que responden a diferentes25

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónresponsabilidades como especialistas informáticos, técnicos de RRHH, personal administrativoy directivo. Cada trabajador demostró dominio de su puesto de trabajo, pero en función de lasrespuestas recolectadas en las entrevistas ocurrió de manera diferente.Según las respuestas apreciadas se definieron tres grupos de usuarios (Ver Figura 6) listados acontinuación: Grupo 1: Personas que manifestaron el deseo de conocer mejor el sistema GREHU.Usuarios incorporados recientemente a su puesto que no poseen experiencia en el uso delsistema. Grupo 2: Personas experimentadas en el uso del sistema pero poseen limitadoconocimiento de computación. Se manifiestan conformes con el sistema GREHU y no soncapaces de enfocar sus incomodidades o de atreverse a exponer nuevas ideas. Grupo 3: Personas que conocen el sistema y presentan ideas interesantes respecto acambios que proponen.27 %9 % Desean conocer mejor el sistema GREHU.64 %Conocen el sistema y se conforman con él.Sugieren mejoras al sistema.Figura 6. Distribución de usuarios encuestados por grupos [60] .La distribución de los usuarios en función de los datos obtenidos en las entrevistas realizadasdemuestra que efectivamente, los resultados no se enfocan a la investigación pretendida, sinoque se expande a otros temas. Respuestas como “estamos agradecidos con el colectivo deprofesores que desarrolla el sistema” o “deseamos que sigan impartiendo seminarios decapacitación” validan que debe orientarse a los entrevistados de manera precisa sobre qué seles pide que respondan sin darle la idea de lo que se les pretende ofrecer o el problema comolo entienden los informáticos que realizan el trabajo. Para lograr esto es necesaria lacapacitación para el uso del diseño guiado por objetivos y las metodologías enfocadas enrequerimiento y en Persona-Escenario-Objetivo por parte de los especialistas que realizarán lasentrevistas. Ha sido necesario entonces dedicar un tiempo a tal actividad, por lo que también eltrabajo en este enfoque ha llegado a un punto de espera [60] .26

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónLos deseos e intereses de usuarios pueden entrar en conflicto, por lo que es importantemantener el control de sus sugerencias y los cambios que demanden mediante la validación deestos por profesionales o expertos en el tema.1.5 Fundamento de los Objetivos del TrabajoEl desarrollo de un sistema generador de reportes que permita la gestión de los roles deusuarios relacionados con los procesos de creación y mantenimiento de reportes digitalespermite distribuir responsabilidades acorde a las necesidades de cada persona de formadinámica durante todo el tiempo de vida de la herramienta. La inclusión de un módulo de estaclase en un sistema informático hace posible analizar la labor de estos en sus escenarios,independientemente de las variaciones que presenten, durante un tiempo tan prolongado comose desee. Observando la evolución de la solución en las diferentes entidades donde se instalese pueden concebir estrategias decisivas para el estudio y propuesta de opciones que aportenen algún grado soluciones a los problemas que presenta la gestión de roles en el entorno delos reportes. Los resultados del sistema que se pretende desarrollar no se consideran enabsoluto una vía única a seguir, sino que pueden orientar el camino correcto del trabajo.Mientras más variables sean los diferentes escenarios en los que se explote la herramienta,más comprometedoras podrán ser las percepciones por parte de los especialistas.La selección o concepción de un proceso de creación de plantillas de reportes que contenga lamayor cantidad de ventajas apreciadas en los sistemas analizados con el fin de permitir que elmódulo de gestión de reportes se diseñe de manera completa, sin problemas y respaldado porun proceso flexible, dinámico y complejo, ha de garantizar que se les ofrezca a los usuariosrespuesta a cualquiera de sus necesidades o demandas de manera óptima siempre que lasmismas contengan sentido lógico.Elegir o definir, en caso de que las propuestas estudiadas no se ajusten, un formato de ficheroque permita almacenar y modificar las plantillas de reportes es un aspecto también clave parael desarrollo del sistema propuesto. Tal estructura debe permitir la carga de la plantilla con elpropósito de incorporarle cambios constantes de manera dinámica y flexible ante los usuarios.El fichero debe ser gestionado independientemente del entorno o la plataforma deprogramación. En dependencia de qué tan ágil y dinámica sea la gestión de la plantilla pormedio de la programación, será la manipulación de la misma desde la interfaz gráfica delusuario. Es importante recordar que el módulo de reportes debe ser lo más flexible y dinámico27

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónposible, por lo que no deben existir deficiencias por compromisos con plataformas otecnologías informáticas.La selección de módulos implementados, bibliotecas o herramientas de programación para eldesarrollo de un mecanismo de gestión de fuente de datos altamente flexible es otro de losaspectos que incorporan flexibilidad al módulo de reportes. Las fuentes no debencomprometerse con formatos, diseños o tecnología alguna, eliminándose de esta forma elproblema respecto a la compatibilidad entre las numerosas opciones de fuentes existentes.También debe escogerse, para la implementación de la herramienta, un entorno deprogramación libre de pago de licencias que cumpla con la estrategia por la soberaníatecnológica trazada por el Ministerio de Informática y las Comunicaciones del país. Esimportante que tal propuesta posea gran aceptación en las comunidades de programacióninternacionales con el fin de aumentar la probabilidad de adquirir bibliotecas que aportenfuncionalidades relacionadas con la investigación y garanticen la implementación flexible de losmódulos y mecanismos de la solución. Tal tecnología debe garantizar la portabilidad y permitirel desarrollo de un producto extensible a escenarios variados con el fin de aumentar ladiversidad de los negocios a estudiar.Diseñar e implementar un módulo para gestionar los roles de los usuarios de manerapersonalizada acorde con los requerimientos de los mismos hace de la herramienta un entornomás flexible que aumenta la diversidad de criterios, así como la posibilidad de conflictos entreestos. Esto desata un ambiente que propicia al usuario pensar y comprender la utilidad ynecesidad de diferencias en cuanto a su papel frente a un sistema informático. Es posible quecada usuario intente plasmar su pensamiento acorde a sus incomodidades, por lo que esnecesario implementar un mecanismo responsable del control que ofrezca estructurasjerárquicas o criterios potenciales para la consideración de estas entre los roles en el procesode gestión de reportes.Cada uno de los objetivos específicos antes fundamentados permite el desarrollo de unaherramienta que incluya un módulo de reportes que garantice la gestión de manera flexible,extendiendo el uso de los reportes como producto, y garantizando que el sistema se ajuste alos gustos y las necesidades de los usuarios, permitiendo así el surgimiento de posibles roles yenriqueciendo el proceso de registro y captura de regularidades entre estos.28

CAPÍTULO I. Antecedentes y Detalles de la Investigación1.6 Análisis del Estado del ArtePara responder a la situación problemática antes definida es imprescindible evaluar el estadodel arte relacionado con el tema tratado. De tal forma puede garantizarse si es válida lapropuesta y puede continuarse el desarrollo de la misma tomando aspectos que exponen suimportancia, o si existe alguna otra solución que pueda ajustarse a lo deseado, aspecto queahorraría tiempo para la obtención de la solución deseada.Investigar las herramientas y tecnologías existentes, los procesos definidos y el impacto deestos, nacional e internacionalmente, es la esencia de este epígrafe. El cumplimiento demuchos de los objetivos depende de esta tarea investigativa, puesto que la selección ocreación de procesos, mecanismos y herramientas depende de los resultados que aporte lainvestigación del comportamiento informático en la temática acordada.1.6.1 Principales Mecanismos de DesarrolloLa mayoría de los procesos estudiados se encuentran relacionados a la forma en que esgestionada la información por herramientas informáticas en la actualidad, particularmente elmodo de representarla utilizando reportes como componentes visuales de la interfaz gráfica deusuario de los sistemas de gestión de información.Los procesos de gestión de información son parte esencial de las organizaciones y susnegocios. El funcionamiento correcto de estos es la esencia del éxito de las mismas, por lo quela existencia de incongruencias en ellos puede llevar al fracaso a cualquier estructuraempresarial. Generalmente, al realizar la automatización se incorporan defectos que provocanerrores, es por ello que el tema del desarrollo de sistemas de gestión y el uso de metodologíaspara tales fines, resulta polémico y sin lugar a dudas, importante.La modelación correcta de los negocios, el establecimiento y captación de reglas de losmismos, que serán la esencia del cumplimiento de estos en la automatización, son cuestionescríticas que en la actualidad siguen muchas vertientes. Existen metodologías que proponen eldesarrollo de sistemas basándose estrictamente en las reglas de los negocios [96] , otras que seenfocan fundamentalmente en la constante interacción con clientes y usuarios [39] . Algunasconsideran la incorporación de los Agentes Inteligentes en la modelación y desarrollo desoluciones definiendo extensiones de UML [62] , y las llamadas metodologías ágiles, las cualespersiguen entre sus objetivos eliminar la burocracia imperante en las metodologíastradicionales y hacer al proceso de desarrollo más rápido, pretendiendo obtener resultadospalpables a corto plazo [4] .29

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónÚltimamente han surgido otras metodologías que consideran los escenarios, las personas y losobjetivos que estas han de cumplir en la organización a la que pertenecen [1][2] . Algunas de ellasfueron descritas anteriormente y todas en conjunto demuestran la diferencia de pensamientopor parte de los profesionales en función de la modelación de situaciones y concepciones desistemas informáticos.Existen problemas relacionados con la modelación y el desarrollo de sistemas, los cualesmuchas veces presentan desajustes y errores que en el peor de los casos los condenan aldesuso y al olvido [15] . Ya sea por el mal empleo de metodologías de desarrollo, por undesajuste en la interfaz ofrecida, o por el dinamismo que caracteriza a algunas esferas de laactividad humana, muchas reglas programadas no se ajustan un tiempo indeterminado a lasmodelaciones realizadas para la creación de una herramienta informática y muchos sistemasculminan su vida útil en el fracaso [15] .Dentro de los procesos automatizados, los relacionados con la gestión de reportes no quedanexentos a la situación antes mencionada. Aunque existan infinitas herramientas, sucede similar,de manera que estos pueden entrar en desajuste debido a contradicciones con loverdaderamente requerido en cualquier negocio. Los populares generadores de reportesesencialmente permiten el desarrollo de plantillas que han de ser utilizadas por otrasherramientas [17][49] . Existen plataformas como Pentaho que incorporan un mayor dinamismopara la gestión de estos una vez presente en los sistemas [69] , pero el dinamismo de losescenarios siempre afecta el ajuste de tales soluciones [92] .Por ello se piensa que se haya liberado el código de muchas de estas herramientas [92] , decualquier manera es importante detallar la situación de cada uno de los componentesrelevantes que conforman el proceso de gestión de reportes a fin de fundamentar tal desajustey exponer ideas que pudieran aportar en su solución.1.6.1.1 Formatos de Ficheros de PlantillasLa esencia de la gestión de los reportes se orienta en el desarrollo de estos y sualmacenamiento físico para posteriormente ser impresos o exportados según se requiera. Lasoperaciones que se realizan para materializar un reporte y la apariencia con que se expondrá lainformación son criterios almacenados en ficheros que representan las plantillas.Existen múltiples formatos de los ficheros de plantillas de reportes, cada uno asociado ageneradores de reportes determinados que han logrado ganar popularidad y estandarizar sustecnologías empleadas extendiendo las estructuras que suelen utilizar. Un ejemplo claro de tal30

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónestandarización lo constituyen los ficheros FRX de los reportes creados con las diferentesversiones de FoxPro de Microsoft. Tales ficheros se basan en estructuras de tablas similares alas de los ficheros DBF con campos estandarizados cuyos valores son interpretadosexclusivamente por las herramientas con las que fueron diseñados [5] .La estructura de los ficheros FRX se ha desechado con el tiempo debido a la limitante antesmencionada. Muchos productos con el tiempo han implementado sus reportes y los serviciosque gestionan los mismos, utilizando el estándar XML, entre los cuales se encuentran: CrystalReports [84] , Pentaho [3] , JasperReports [91] y Microsoft SQL Server 2005 [76] . Tal adopción hagarantizado la extensión del reconocimiento del diseño de sus reportes a otras herramientas yplataformas, ya que actualmente XML es muy difundido y ofrece múltiples bondadesbasándose en esquemas de reportes acorde con diferentes tipos de negocios.Es conveniente considerar que una gestión flexible de tales esquemas podría permitir alusuario incorporar la administración de las plantillas de forma altamente personalizada,alterando la estructura de las mismas e imponiendo restricciones que podrían en determinadomomento y bajo ciertos privilegios, ser alteradas.Uno de los ficheros que definen plantillas de reportes que se encuentran bajo la estructura XMLson los de extensión JRXML pertenecientes a los productos de Jasper Corporation. Estosficheros se encuentran sujetos a esquemas que responden a una gestión personalizada yaltamente flexible, y su estructura ha sido concebida de esta forma teniendo en cuenta que sonla base de herramientas de gestión de reportes profesionales que persiguen el desarrollo deproductos extensibles y altamente flexibles [17] .1.6.1.2 Especificaciones para la Definición de ReportesExisten especificaciones para la definición de reportes y la representación de estructuras clavesde los mismos, que generalmente se orientan al establecimiento de modelos semánticos yplantillas. Entre las tecnologías propietarias más conocidas en el mundo se encuentran SMDL yRDL, ambas definidas y utilizadas por los servicios de reportes del SQL Server 2005 (SSRSsegún sus siglas en inglés).SMDL es una especificación XML encargada de definir los elementos válidos a considerar en elmodelo de un reporte almacenado en un fichero de extensión “smdl” [76] . Mediante ella sedefinen las relaciones entre objetos semánticos y de vistas de fuentes de datos del modelo delreporte [56] (Ver Anexo 8).31

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónRDL, por otra parte, es una representación XML de la definición de los reportes que realizaSSRS que contiene información relacionada con la recuperación de datos y la apariencia de laplantilla del reporte [57] . Su principal objetivo consiste en promover la interoperabilidad dereportes comerciales por medio del establecimiento de un esquema común que permita elintercambio de definiciones de reportes [58] .RDL permite definir la estructura de plantillas de reportes de propósito generalindependientemente del negocio. La estructura que define presenta similitudes a lasmencionadas en el epígrafe 1.3.1.2 al analizar el modelo abstracto de una plantilla de reporte(Ver Anexo 9).Otra de las especificaciones que responde a un modelo genérico que se ajusta abiertamente adiferentes situaciones para la representación de la información por medio de reportes lo es elDTD al que se ajustan los ficheros JRXML antes mencionados [17] . La capacidad de ajustarse adiferentes negocios es uno de los rasgos que ha hecho a los productos de Jasper Corporationubicarse a la vanguardia entre las opciones para la gestión de reportes en el mundo delsoftware libre [33] . Esta característica, como muchas otras, parte de la estructura definida paralas plantillas de sus reportes.1.6.1.3 Gestión de Roles de Usuarios y Seguridad de Aplicaciones InformáticasOtro aspecto que ha evolucionado con el tiempo en las ciencias informáticas es el tratamientode la seguridad de la información, muchas veces gestionada por medio del establecimiento depolíticas de restricciones y control de acceso de los usuarios a las aplicaciones. Existen áreasespecializadas dentro de esta ciencia y actualmente se enfocan en el uso de jerarquías deusuarios para tratar la confidencialidad e integridad de los datos.Con el tiempo han surgido nuevas alternativas para responder ante los diversos problemas deseguridad. Se han adoptado diferentes medidas, desde la más simple como la incorporación decontraseñas a las aplicaciones, hasta otras más complejas como la defensa proactiva, lagestión de monitoreo constante en los sistemas y la gestión de políticas se seguridad [27] .Muchas aplicaciones definen grupos donde incluyen a sus usuarios [12][49] , otras adicionan en laimplementación la consideración de procesos el cifrado y descifrado de los datos, y establecenroles y políticas de seguridad a través de frameworks destinados a estos fines [38][90] . Incluso laforma de visualizar las opciones de interés y ocular aquellas que no se relacionan con lasfunciones que realice el usuario, es una política muy seguida y recomendada actualmente32

CAPÍTULO I. Antecedentes y Detalles de la Investigación[15][52]. Algo que se desconoce tiene menor probabilidad de ser atacado, a diferencia de algo quese expone, aunque sea de manera deshabilitada.Es importante recordar que la seguridad no debe ser un aspecto a confiar completamente enlas herramientas de desarrollo que se utilicen, tal problema es una guerra constante que lidiar,cada acción de corrección de errores o vulnerabilidades viene precedida por nuevos ataques odescubrimiento de fragilidades. La solución más recomendada es por ello el buen diseño de lasherramientas desde los primeros momentos. Es conveniente establecer prioridades en laslabores de desarrollo, puntos de referencia, ordenar las tareas de implementación y realizarpruebas parciales a los productos en creación [78] .La definición de roles de usuarios a partir de los negocios a modelar, la modelación dejerarquías entre usuarios y el establecimiento de relaciones entre estos, así como la asignaciónde recursos del sistema y definición de acciones que estos podrán realizar, es también unaspecto imprescindible para el funcionamiento confiable de un sistema.1.6.1.4 Extensibilidad, la Flexibilidad y la UsabilidadLa extensibilidad, la flexibilidad y la usabilidad son requerimientos no funcionales que puedencomprometer seriamente la aceptación de un producto por los clientes, por lo que deben sertratados de manera cuidadosa. El desglose de actividades, en dependencia del usuario, puedegarantizar un elevado grado de usabilidad y flexibilidad en la herramienta. Es por ello que elestablecimiento y la gestión de roles constituyen una importante tarea a implementar.También, si un sistema trata correctamente el flujo de sus funcionalidades y es respaldado poruna interfaz gráfica de usuario que se adecue a las necesidades de los mismos, puedegarantizarse que se realiza un manejo positivo de la usabilidad. Por otra parte, el hecho deadoptar una clase de esquema en común para la definición de plantillas de reportes tributapositivamente a la extensibilidad del reporte como producto.Otra manera de tratar estos requerimientos puede ser mediante bibliotecas que permitentransformar la estructura de un sistema en tiempo de ejecución. Si estas herramientas seencaminan a gestionar opciones de interfaz para la inclusión de nuevas funcionalidades, puedeobtenerse un producto capaz de ajustarse a los cambios del negocio en que se utilice y lasnecesidades de sus usuarios. Esta clase de operación incide directamente en la extensibilidad,flexibilidad y usabilidad de un sistema.33

CAPÍTULO I. Antecedentes y Detalles de la Investigación1.6.2 Principales HerramientasLa mayoría de las herramientas orientadas a satisfacer las necesidades de los usuarios entemas de reportes, no incluyen el tratamiento de la gestión de roles. Las pocas que lo tienen encuenta, solo proponen jerarquías estáticas que ajustan los procesos acorde a ciertas clases deusuarios, lo que exige a las personas que utilizarán la solución adaptarse a lo modelado en laherramienta, en vez de diseñar el sistema en función de la estructura del negocio.Lamentablemente esta situación suele repetirse en muchas de las herramientas.Para analizar las principales funcionalidades que pudieran incorporarse en la solución adesarrollar y estudiar la forma en que estas tratan los temas de interés para el presente trabajo,es que se efectúa un estudio de las propuestas actuales en el mercado del softwareinternacional y nacional.1.6.2.1 Herramientas de Gestión de ReportesTeniendo en cuenta los tipos de herramientas informáticas relacionadas con los reportesmencionadas en el epígrafe 1.2, se exponen detalles del trabajo investigativo realizado parajustificar el desarrollo de la solución propuesta. Algunas de las bibliotecas, componentes, paquetes y herramientas analizadas,destinadas a la creación de generadores de reportes o la inclusion de estos en otrasherramientas informaticas, fueron:QReport: Biblioteca desarrollada por la compañía QSOFT que contiene componentesvisuales especializados en la impresión de reportes y que, integrada a entornos dedesarrollo de aplicaciones de la empresa Borland, como Delphi y C++ Builder, permiteconstruir y manipular reportes [75] .Rpv Reports: Herramienta gratis destinada a preparar reportes. La misma puede sergestionada con cualquier lenguaje de programación obteniendo resultadosprofesionales al posibilitar la inclusión de gráficos, imágenes y código de barras, entreotros componentes visuales [80] . JasperReports: Biblioteca de código abierto de gran aceptación en la comunidadinternacional de desarrolladores de sistemas en Java. La misma está destinada altrabajo con reportes desarrollados bajo formato XML [14] .JFreeReport: Otra biblioteca de clases de Java para la generación de reportes. Ofreceplantillas basadas en XML que proveen flexibilidad a los reportes y permiten laimpresión de la información utilizando datos desde múltiples fuentes y soportes de34

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónsalida a dispositivos de pantallas o impresoras, en diferentes formatos tales comoPDF, Excel, HTML, XHTML, Texto plano, XML y ficheros CSV [45] . Incorpora lamayoría de las ventajas antes descritas y actualmente es una de las herramientasoficiales del Proyecto Pentaho al cual se incorporó en enero del 2006 [46] . Reportlab: Paquete de reportes escrito en Python con salidas directas comodocumentos PDF. Este paquete posibilita el tratamiento de gráficos e imágenes enmúltiples formatos [77] . Su principal desventaja en comparación con las herramientasdescritas anteriormente es la restricción del formato de salida.Existen muchas otras bibliotecas gratuitas para el manejo de reportes como text, FOP yPOI [14] . Todas ellas bindan funcionalidades para el desarrollo de gestores de reportes endependencia de sus particularidades. La correcta selección de una de estas herramientaspudiera permitir el desarrollo de un generador de reporte que grantice un trabajopersonalizado por parte de los usuarios. El grupo de sistemas profesionales generadores de reportes es más numeroso que elantes descrito. En él, cada aplicación presenta un conjunto de herramientas integradasque posibilitan la manipulación de reportes de forma óptima y detallada, entre las que seencuentran:Las herramientas Access y Excel del paquete de Microsoft Office: Estos sistemas noestán creados específicamente para el desarrollo de reportes, pero presentanfuncionalidades que permiten la gestión de reportes muy bien concebidos, en el casode Access, destinados a cargar datos de sus respectivas bases de datos, no siendoasí para Excel, donde son creados con una naturaleza menos dinámicamoReport: Generador de reportes basado en bibliotecas GTK que soporta bases dedatos PostgreSQL y uso estándar de XML como formato de entrada y salidasPostScript [59] .iReport: Herramienta Java que permite la gestión de reportes mediante una interfazgráfica amigable.Los SGBD como FoxPro, Visual FoxPro y SQL Server: Desarrollados principalmentepara la gestión de bases de datos, pero que incluyen potentes herramientas para lageneración de reportes.35

CAPÍTULO I. Antecedentes y Detalles de la Investigación Crystal Reports: Programa profesional creado exclusivamente para el trabajo conreportes. También permite la publicación de estos en sistemas Web, y posibilitaexportarlos a múltiples formatos de ficheros.Otros sistemas existentes destinados a la gestión de reportes con fines profesionales sonRpv Printing System y Rpv Business Reports. Rpv Printing System permite generarreportes utilizando cualquier lenguaje de programación e imprimirlos bajo Windowsgenerados desde un servidor que puede correr sobre una amplia variedad de sistemasoperativos [28] .El producto desarrollado por SQL Software utilizando herramientas Oracle, nombradoQueryx*Report, destinado principalmente a gestionar reportes del área operativa yadministrativa de diferentes organizaciones [87] , la herramienta ContourCube destinada acrear y manipular reportes, y el paquete de herramientas KOffice que incluye el generadorde reportes Kugar, tradicionalmente complicado de utilizar [34] , pero que al usarfuncionalidades de otras herramientas del paquete, como KChart y KWord, permiteobtener reportes de alta calidad [16] , son otros sistemas existentes.También Pentaho, uno de los líderes de las herramientas de Inteligencia de Negocio decódigo abierto basada en estándares de Java, facilita y guía el papel de losdesarrolladores en sus proyectos. Es considerado una plataforma de reportes según lasegunda clasificación mencionada en el epígrafe 1.2. Entre sus múltiples ventajas sedestaca la posibilidad de administrar y distribuir reportes, establecer análisis, realizarplanificaciones y facilitar la integración con fuentes de datos [64][65] .Los reportes son de gran importancia en los sistemas de Inteligencia de Negocio yPentaho particularmente, garantiza un fácil acceso de estos, sencillos formatos y ladistribución eficiente de la información. Además, facilita el despliegue flexible de reportesdesde aplicaciones de escritorio para la Web, utilizando código libre y abierto. El proyectoPentaho dedica con gran cuidado una atención especial al área de reportes y a losproductos informáticos relacionados con ellos, aspecto que lo sitúa como una de lasprincipales herramientas de su clase (Ver Anexo 6).Incluido en Pentaho se encuentra Pentaho Reporting, que consiste en una colección deproyectos de código abierto enfocados a la gestión de plantillas [68] y que permite obtenerrobustos reportes de diseños de gran acabado (Ver Anexo 4). Los proyectos incluidos enPentaho Reporting brindan asistentes de diseños de reportes para una rápida y sencilla36

CAPÍTULO I. Antecedentes y Detalles de la Investigacióncreación y permiten flexibilidad en la salida de estos, incluyendo diferentes formatos comoPDF, HTML, XLS, RTF, y texto plano [66] . Además, poseen el resto de las ventajas comoson los agrupamientos y consideran la compatibilidad con versiones anteriores [69] .Si bien Pentaho contiene herramientas robustas para el tratamiento de reportes, esimportante comprender que estos son una parte más considerada en su proyecto.Aunque logre una gestión flexible y personalizada de los mismos, el centro del proyectoPentaho se enfoca en la Inteligencia de Negocios y está compuesto por herramientas quepersiguen un fin diferente al enfoque exclusivo de la gestión automatizada de reportes.Para apreciar las variedades tratadas en Pentaho se exponen las herramientas queintegran su proyecto y el área que trata cada una, estas son: “Mondrian”, que consiste enun servidor OLAP, “JFreeReport”, para la gestión de reportes, “Kettle”, destinado a laintegración de datos (ETL por sus siglas en inglés), “Pentaho”, contenedor de Inteligenciade Negocios, y “Weka” destinado a la minería de datos. Todas estas herramientas son decódigo abierto [67] .Otra herramienta también muy conocida de este grupo lo constituye el proyecto EclipseBIRT, respaldado por una biblioteca de igual nombre ofrece un sistema de reportes decódigo abierto en Java con una interfaz gráfica de usuario basada en Eclipse. Posee unmodelo de objetos de reporte (ROM según sus siglas en ingles) que constituye la basepara el formato del diseño de estos. El mismo está representado por un formato de diseñoXML, que describe todos los aspectos de los reportes [21] . Su version 2.1.1 permite salidaen HTML, PRF, XLS, RTF, SVG, y otros formatos de imágenes. También ofrece unconjunto de interfaces que garantiza adicionar conversores para gestionar nuevasestructuras de ficheros al exportar los reportes o incluir los desarrollados en otrasaplicaciones [43] .Existen muchas otras soluciones en este grupo, aunque las abordadas son las másprometedoras considerando su popularidad, funcionalidad, y la cantidad de ventajas queofrecen. Muchas de ellas garantizan la gestión personalizada de reportes, como iReport.Lamentablemente, la mayoria no implementa la gestión de roles de usaurios ya que no essu tarea esencial. No obstante, algunas (generalmente los SGBD) permiten realizar laadministracion de usuarios y definir politicas de acceso o restricciones sobre estos,aunque el proposito perseguido es diferente. Las herramientas de gestión de información diseñadas para ser explotadas en empresasy organizaciones, que pueden incluir generadores de reportes u opciones de obtención de37

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónreportes destinados a la impresión de la información y facilitar los procesos de toma dedecisiones y control de medios, forman el grupo más variado de los tres según el criteriode clasificación empleado hasta el momento. Algunos sistemas representativos del mismoson: MEBUS (Medios Básicos para Unidades de Salud): Sistema cubano destinado a lagestión del control de los medios básicos en las unidades presupuestadas de SaludPública [36] . RepCob: Herramienta que presenta un generador de reportes para empresas deestructura distribuida [31] . Delta: Herramienta desarrollada para la gestión de la información en empresas [18] .ContaPyme: Sistema de gestión administrativa y contable del mercado, especialmentedesarrollado para pequeñas y medianas empresas. Ofrece reportes contables comobalance, estado de resultados, entre otros [37] .De manera general, cada una de los sistemas del último grupo ofrece reportes destinados altratamiento de la información bajo los términos particulares que requiere cada organización a laque están encomendados. Las herramientas que permiten el trabajo con reportes en ellos sonla representación de la concepción de sistemas para el tratamiento de reportes personalizadoso que presentan opciones de reportes de diseño estático para exponer la información, adiferencia de los dos primeros grupos, destinados al tratamiento de reportes de manerageneral. Las bibliotecas, componentes y herramientas, permiten manipular no sólo los reportesal menor nivel posible, sino que se encargan de la creación de herramientas que los gestionende manera personalizada como el grupo anterior, o con un propósito general, como lossistemas profesionales como Crystal Reports.Las bibliotecas y los paquetes de componentes persiguen objetivos diferentes. Las bibliotecasbrindan un conjunto de clases y métodos para la manipulación de reportes mediante el código.Los paquetes compuestos por componentes que pueden resultar diferentes funcionalmente, seenfocan en el trabajo encaminado a desarrollar aplicaciones generalmente restringiendolibertades que ofrecen las bibliotecas a los reportes [71] .El grupo de los sistemas profesionales tiene también sus diferencias entre cada herramienta.Estas vienen dadas esencialmente por las funcionalidades que brindan cada una de ellas. Lasviejas versiones de sistemas como FoxPro y Crystal Reports nunca van a permitir la obtenciónde reportes tan completos como sus últimas versiones. Por otra parte, los SGBD naturalmente38

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónno van a garantizar la obtención de un trabajo tan refinado sobre los reportes como lassoluciones destinadas exclusivamente a esta tarea.Éstas son algunas de las herramientas relacionadas con la gestión de los reportes de maneraautomática en el mundo de la informática. Es necesario tener en cuenta que la cantidad y lavariedad de las mismas son realmente inmensas. Constantemente se están incluyendo en lasaplicaciones destinadas a fines específicos, generadores de reportes para facilitar el trabajoque representa la obtención de información en formatos visuales, fáciles de organizar ycomprender. En menor grado se aprecia el incremento de productos profesionales destinadosal tratamiento de reportes de manera general. El hecho es que, como parte del mundo de lainformática, el de los reportes está también caracterizado por un gran dinamismo.1.6.2.2 Herramientas de Gestión de SeguridadEl nivel más básico de la implementación de la seguridad puede apreciarse en aplicacionescomunes que definen la visualización de opciones en función del tipo de usuario que utilice elsistema. Esta estrategia se hace más completa y efectiva si se ofrece la posibilidad degestionar usuarios y grupos para estos, similar a la forma en que lo hacen los SGBD como lasdiferentes versiones de Microsoft SQL Server que permiten asignar privilegios y delimitar lasacciones de los usuarios sobre las bases de datos [12] . Otras herramientas de desarrollo, comoel Framework .NET de Microsoft, definen la seguridad como aspecto clave de su arquitecturacontrolando por módulos sus aplicaciones y recursos. Además, le brindan a los especialistasherramientas para implementar la autenticación, autorización y el cifrado, entre otros aspectosclaves [26] .Particularmente .NET, a pesar de todas las facilidades que incorpora para implementar laseguridad en aplicaciones informáticas, no está exento a vulnerabilidades que lo hacen frágil aataques que comprometen la integridad y confiabilidad de las herramientas que en él puedanimplementarse. La seguridad no debe basarse únicamente en el entorno y las herramientas dedesarrollo, sino en el diseño realizado al sistema desde los inicios de la concepción [25] .También en el escenario del software libre existen tecnologías orientadas al tratamiento de laseguridad desde diferentes enfoques. Java, encabezando la lista de las más populares de estaárea, presenta un conjunto de APIs e implementaciones de algoritmos, mecanismos yprotocolos que conforman su tecnología de seguridad. Sus APIs abarcan diferentes aspectoscomo: criptografía, comunicación segura, autenticación y control de acceso. Gracias a ello es39

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónposible desarrollar aplicaciones utilizando frameworks integrales y herramientas que garantizana los usuarios y administradores la gestión de la seguridad [89] .Particularmente, para la autenticación y el control de acceso, Java contiene APIs que ofrecenun amplio conjunto de mecanismos a través de una arquitectura flexible y abierta, que brindanla posibilidad de implementar autenticación múltiple o simple y gestionar el control de recursosde forma fragmentada basándose en la identidad de cada usuario [89] .Como parte de la tecnología para el tratamiento de la seguridad en Java se encuentra suServicio de Autenticación y Autorización (JAAS por sus siglas en inglés). Introducido como unpaquete opcional en el JDK 1.3 e integrado completamente en el JDK 1.4, permite determinarqué usuario está ejecutando determinado código y garantiza que tenga acceso a los recursosque le correspondan. Actualmente gestiona los servicios de autenticación de maneraindependiente a la tecnología empleada para estos fines [88] . Indudablemente, la incorporacióndel JAAS en el JDK constituye un paso importante para la implementación de mecanismos deseguridad en las aplicaciones desarrolladas sobre esta plataforma.Basados en JAAS se han desarrollado un conjunto de frameworks y APIs para laimplementación de la seguridad en aplicaciones en Java. Para el entorno empresarial se tienea la API OWASP, orientada fundamentalmente al trabajo con aplicaciones y servicios Web [63] .Para el control de acceso (autenticación y autorización) se tiene a Acegi y jGuard y para elcifrado de datos a Bouncycastle y Jasypt [44] .Existe también el framework XWS-Security destinado para gestionar la seguridad en lasllamadas remotas de procedimientos JAX en aplicaciones SAAJ stand-alone y para asegurarmensajes SOAP a través de firmas y cifrado de algunas de sus partes, o del envió deinformación de autenticación [90] .Por otra parte, Acegi Security, actualmente nombrado Spring Security, es el proyecto oficial deseguridad de Spring Portfolio. Entre las características principales de su última versión se tieneuna simplificación de la sintaxis de configuración. Además incorpora el soporte para grupos,roles jerárquicos y una API de gestión de usuarios, los cuales son combinados para reducir eltiempo de desarrollo y optimizar la administración de los sistemas. Acegi presenta una ampliaaceptación internacional y está respaldado por una completa documentación [38] .1.6.2.3 Herramientas que permiten alterar archivos compiladosExisten herramientas profesionales destinadas a alterar la estructura gráfica de aplicacionespara incorporar nuevas opciones por medio de la inyección de código. En cierta forma esto40

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónpuede comprenderse como una intromisión, aunque siempre que sean utilizadas correctamentepueden reportar sorprendentes resultados aumentando el dinamismo y la flexibilidad de lossistemas. La mayoría de ellas se enfoca sobre los menús en donde adhieren los puntos deacceso a las nuevas funcionalidades o herramientas.Tales sistemas tienen un impacto muy limitado en las herramientas creadas con entornospropietarios. Por su naturaleza se les impide actuar libremente en tal escenario debido a lacomplejidad que representa conocer la estructura gráfica de estas aplicaciones e invadirla parainsertar nuevas opciones. Es importante recordar que, más que las aplicaciones desarrolladasen entornos libres, las soluciones desarrolladas en entornos propietarios están sujetas acódigos legales que muchas veces impiden y penalizan esta clase de actividad.Por otra parte, existe el estándar PLIB que responde a la norma ISO 13584, creado para definirun formato neutral para la representación de relaciones entre componentes independientesdefinidos con anterioridad. El mismo garantiza el intercambio entre bibliotecas de sistemasheterogéneos y su arquitectura involucra mecanismos para dar respuesta a dificultades en lamodelación y el intercambio entre partes de las bibliotecas [83] . Respondiendo a este estándarse han desarrollado algunos productos como el API PLIB que permite la escritura de programasen Java para la administración de entidades PLIB [50] y el editor PLIB, aplicación Java paragestionar y controlar la interacción de bibliotecas y sus partes [51] .Naturalmente, la diversidad de los sistemas para inyectar código, agregar nuevas opciones yalterar la estructura de sistemas desarrollados con tecnología libre y mejor aun, de códigoabierto, es mayor. Entre las más conocidas se encuentran: La Biblioteca de Ingeniería Byte Code (BCEL según sus siglas en ingles): Proyecto deApache – Jakarta que se enfoca en ofrecer a los usuarios la posibilidad de analizar, creary manipular los archivos .class de Java. En ella las clases son representadas por objetosque contienen información simbólica de estas como sus métodos, atributos einstrucciones bytecode. BCEL permite además la inyección de código en tiempo deejecución [30][42] . ProGuard: Herramienta libre destinada a ajustar ficheros .class de Java. Se considera unofuscador e incluye funciones de preverificación. Permite eliminar clases, métodos yatributos que no se utilicen y renombrar los que perduren utilizando nombres sugerentes yde poca longitud. Optimiza el bytecode y remueve instrucciones en desuso. ProGuardpermite compactar código, aumentar la velocidad de las transferencias por las redes y41

CAPÍTULO I. Antecedentes y Detalles de la Investigacióngarantiza una carga más veloz de los ficheros. Se considera de utilidad para desarrollarprogramas y bibliotecas destinadas al trabajo con la Ingenieria Inversa [48] . jclasslib: Visor de bytecode desarrollado por ej-technologies que expone todos losaspectos de un fichero .class de Java. Presenta una biblioteca que permite a losdesarrolladores leer y alterar tales archivos [22] . Se considera una herramienta de granutilidad para navegar por la estructura del fichero .class y comprender el funcionamientode la JVM [23] . Javassist: Asistente para la programación en Java que permite reflejar parámetros,variables y estructuras de ficheros en tiempo de carga. Es una biblioteca para editarbytecode que posibilita a los desarrolladores definir nuevas clases en tiempo de ejecucióny modificar ficheros .class antes que la JVM los cargue. Su principal diferencia con elresto de los sistemas de fines similares es que permite modificar los ficheros sin lanecesidad de conocer detalladamente el bytecode de estos. No requiere la escritura oinsercción de grandes secuencias de bytecode, ya que puede compilar fragmentos decódigo, lo que la hace fácil de utilizar. Permite la programacion orientada a aspectos porofrecer la posibilidad de introducir nuevos métodos en las clases [11] . En términos generales, en el estudio realizado se apreció que la biblioteca BCEL es unade las más documentadas y potentes para la gestión del bytecode de los ficheros .classde Java. jclasslib también se clasifica como herramienta popular y está basada en BCELpara exponer información que gestiona por medio de interfaces de programación. Ambasherramientas son utilizadas por JBE, editor de bytecode que permite la modificación yvisión de los ficheros .class. JBE utiliza jclasslib para visualizar el bytecode y BCEL parachequear y exportar los archivos .class [82] .1.6.3 Herramientas de Reportes más Utilizadas en la ActualidadLa mayoría de las herramientas antes mencionadas se encuentra respaldada actualmente poruna gran aceptación popular. A pesar de ello, conviene detallar las opciones que gozan demayor preferencia por programadores, aspecto que puede constar por las dimensiones de suscomunidades, los diferentes trabajos realizados con ellas y los rasgos más bondadosos quepresentan. El siguiente análisis excluye a los SGBD y a las soluciones para la gestión deinformación que utilizan reportes como medio para cumplir sus requerimientos, enfocándose enlas herramientas destinadas al trabajo con reportes de manera primaria.42

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónSegún el estudio realizado acorde a los criterios antes mencionados, se identificó entre lasherramientas de mayor impacto en la actualidad a los frameworks de reportes Jasper, BIRT yPentaho, todos de código abierto para Java. Por otra parte, el lado de los sistemas propietariosse encuentra representado fundamentalmente por Crystal Reports de Business Objects.Crystal Reports en sus últimas versiones ha incorporado funcionalidades de gran utilidad, loque evidencia la evolución que ha experimentado garantizando su protagonismo como soluciónrepresentativa en la esfera de sistemas de reportes informáticos propietarios [6] . Entre susrasgos más notables se encuentran [7][8] : Una potente gestión de reportes: Incorpora la ubicación dinámica de gráficos y mejora elagrupamiento en modo jerárquico. El uso mejorado auxiliándose de vistas previas en formato HTML, un explorador derepositorio actualizado y la introducción del diseño inteligente permitiendo el diseño degráficos de manera más rápida y fácil. La creación y publicación de reportes de manera compartida y la optimización de lainteracción con el usuario por medio de avisos dinámicos que pueden desencadenarcadenas de procesos [94] . La posibilidad de personalizar funciones, refinar vistas de negocio y crear reportesbasados en Microsoft Exchange Server, Microsoft Outlook, o ficheros de registro de trazasde servidores Web [94] . La transformación de datos de manera desconectada y la posibilidad de incluir en el diseñode los reportes animaciones desarrolladas en Adobe Flash [93] . La posibilidad de centralizar elementos de diseño y garantizar que los reportes seactualicen automáticamente por medio del repositorio [93] . La inclusión de reportes en aplicaciones Web o de escritorio desarrolladas en Java, .NET uotras herramientas [85] .Por otra parte, los productos de Jasper se han tornado protagonistas de la gestión de reportesen muchos sistemas desarrollados con Java. Cada uno de ellos se enfoca en áreas claves dela misma ofreciendo bondades claves. Seguidamente se expone la esencia de acción de cadauno de ellos [40] : JasperReports: Potente biblioteca destinada a desarrollar reportes que consiste en la basede implementación de la mayoría de los productos de Jasper. La misma está destinada43

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónfundamentalmente a desarrolladores y usuarios expertos dentro de la jerarquía de rolesvinculados al proceso cíclico de concepción de reportes (Ver Tabla 1). JasperServer: Servidor de reportes interactivo diseñado para usuarios de negocios ydesarrolladores. Esta herramienta posibilita la entrega de información en tiempo real y larealización de planificaciones básicas por medio de reportes, entre otras funcionalidades. JasperAnalysis: Permite el procesamiento de datos de manera online (OLAP) y estádestinada fundamentalmente a usuarios de negocio. Puede ser utilizada para detectartendencias, patrones, correlaciones y anomalías en los datos. JasperETL: Permite la integración de datos y puede ser utilizado para mesclar datos dediferentes fuentes en una única de manera consistente para el análisis y la gestión dereportes.De todos los productos de Jasper, conviene centrar la atención en JasperReports por constituirla base de muchos de ellos y permitir el trabajo variado a partir de sus funcionalidades.JasperReports es una de las bibliotecas de código abierto más conocidas para el trabajo conreportes que permite la salida interactiva de información de manera simple y flexible. Ademásposibilita obtener reportes bien organizados en cuanto a contenido a mostrar, ya sea porpantalla o por impresora. También incorpora la salida en un gran número de formatos deficheros. Utiliza estándares no propietarios como el XML para la definición de reportespersistentes y el HTML y el PDF para salida gráfica. Además se pueden obtener reportesbasados en vistas de Swing y Eclipse, y en otros formatos como XLS, CSV, RTF y TXT (VerFigura 7). Es una biblioteca perteneciente completamente a Java y puede ser incorporada en eldesarrollo de aplicaciones para la generación dinámica de reportes [24][32] .Otras de las ventajas de JasperReports es que puede utilizarse independientemente de lasfuentes de datos y ofrece flexibles bondades para realizar cálculos. Hace posible lamanipulación gráfica de los reportes y la incorporación de gráficos a los mismos. Brinda unconjunto de formatos internacionales de texto como el conocido “unicode” y además soportamultilenguaje para los reportes desarrollados [17] .44

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónJasperCompileManagerJasperPrintManagerJRXmlLoaderJRCompilerJasperFillManageimprimirXMLanalizarJasperDesigncompilarJasperReportllenarJasperPrintAPIGUI ToolHTMLexportarJasperExportManagerCSVFigura 7. Estructura de la Biblioteca “JasperReports” [13] .XMLUna herramienta que gestiona gráficamente el trabajo con JasperReports es iReports [41] ,generador visual de reportes para JasperReports desarrollado también en Java. Aunque es unaherramienta muy potente, se distribuye gratis y es de código abierto, no incorpora gestión deroles de usuarios, por lo que no se acopla completamente a las necesidades planteadas asolucionar en la propuesta del presente trabajo. Sin embargo la posibilidad de que utiliceJasperReports y que se distribuya a código abierto significa una oportunidad muy convenientea aprovechar al ser posible estudiar a fondo su estructura. También esta herramienta utilizaJFreeChart, una de las bibliotecas gráficas a código abierto más difundidas para Java quesoporta diferentes tipos de salidas, garantizando compatibilidad con componentes Swing,ficheros de imágenes como PNG y JPEG, y formatos de gráficos vectoriales de ficheros entrelos que se destacan PDF, EPS y SVG [61] .Anteriormente fueron descritos en detalle BIRT y Pentaho, por lo que en el presente epígrafeserán comparados con el paquete de herramientas de Jasper sin requerir de anunciaciónalguna. El propósito perseguido al encarar cada una de estas opciones es captar susprincipales diferencias y semejanzas. Crystal Reports será excluido de esta comparación portratarse de un sistema propietario que no brinda libremente su código, lo que anula laspretensiones primarias de obtener y estudiar un proyecto existente con el propósito de ofreceruna solución eficiente y rápida a la situación mencionada en la introducción del documento apartir de la modificación mínima de este.Después de estudiar detalladamente todos estos frameworks y obtener documentación quepermite la comparación de múltiples aspectos básicos para formar criterios sobre los mismos,45

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónse llegó a la conclusión de que todos presentan en alguna medida deficiencias. Cada uno deellos limita el acceso de un número elevado de diferentes usuarios a un mismo reporte. A modode semejanza se observó que todos presentan las opciones típicas para la gestión del diseñográfico de reportes, como construcción de expresiones, tablas y gráficos [43] .Desglosando los problemas apreciados, en el caso de BIRT, este no garantiza unasincronización entre el explorador de bibliotecas y el de datos. Lamentablemente, el primero nomuestra el contenido actualizado, siendo necesario recargar el Eclipse para observar la másreciente información. Otros defectos de BIRT consisten en que no funcione la paginación HTMLy presente un bajo rendimiento que afecte el despliegue en servidores [43] .JasperReports, en cambio, no permite exponer de manera previa en su asistente gráficoiReport el resultado de las consultas que constituirán la base de la información a exponer en losreportes. Otros de los defectos detectados en JasperReports es que no almacena detalles deconexión con las fuentes de datos en los ficheros JRXML [43] .Pentaho, por otro lado, no incluye la gestión de hipervínculos en su herramienta de diseño dereportes ni tampoco hace posible la creación de subreportes. Otra de las desventajas dePentaho es la ausencia de un editor de código script [43] .Otras herramientas muy utilizadas para la gestión de reportes son: ContourCube.NET 3.0, que adiciona como novedad la propiedad de interlineadoautomático para las cadenas largas de caracteres y la posibilidad de cambiar áreas decampos al modo multilínea para que el usuario pueda tener tantos campos de edicióncomo desee [86] . La versión 5.2 de Rpv Business Reports con las ventajas de permitir la gestión deimpresiones remotas, la selección de las áreas de impresión y visualización para eltrabajo con formularios preimpresos sin trabajar doblemente, y la posibilidad de generarmúltiples reportes con un mismo fichero de datos y con un solo proceso [79] .Esencialmente, los principales pasos dados en la actualidad en el trabajo con los reportespuede considerarse que son: el aumento de formatos en que son exportados por lasherramientas más utilizadas, para de esta forma establecer una mayor compatibilidad convisores y editores existentes, el enfoque sobre una estructura común (formato XML) paragarantizar la extensibilidad de los productos de reportes, y la orientación de los reportes alambiente Web.46

CAPÍTULO I. Antecedentes y Detalles de la Investigación1.6.4 Validación del Sistema a DesarrollarTeniendo en cuenta que existe una amplia gama de soluciones informáticas pertenecientes alcampo de los reportes y considerando que ninguna de ellas posee un módulo de gestión deroles de usuarios según el estudio realizado, entonces se justifica la creación del sistemapropuesto en el presente trabajo. Cada herramienta de gestión de reportes apreciada se basaen jerarquías de usuarios establecidas con anterioridad. Ninguna de ellas ha sido diseñadapara funcionar con roles que manifiesten y asimilen evolución en su definición.La creación de un generador de reportes que permita gestionar roles de forma personalizada yasignar permisos de manera dinámica, así como distribuir opciones por los diferentes menús,definitivamente abre las puertas a la posibilidad de estudiar detalladamente el comportamientode los roles de usuarios que intervienen en los diferentes procesos de gestión de reportes.1.7 Decisiones Esenciales para una Buena SoluciónEn las herramientas estudiadas destinadas a la confección y generación de reportes, sedetectó un conjunto de ventajas que resulta de gran valor para la obtención de estos de formapersonalizada. Entre ellas se encuentra el agrupamiento de los datos a exponer, la introducciónde operaciones matemáticas y lógicas, el establecimiento de condiciones y criterios deordenamiento para los datos a mostrar y la inclusión de gráficos, imágenes y figurasgeométricas.Todas estas características constituyen ventajas para obtener reportes flexibles que se ajustena las necesidades de los usuarios. Muchas de ellas se han estandarizado llegando a seraspectos tenidos en cuenta de cada una de las herramientas existentes. Un estudio detalladode cómo implementarlas constituye un tema clave para la solución del problema antes definido.Después de realizar el estudio del estado del arte y justificar el desarrollo de la herramientaplanteada como objetivo, es necesario seleccionar la tecnología de desarrollo y demásaspectos que permitan la óptima creación de la misma. El proceso de definición de decisionesesenciales para la implementación de la solución se basará en la selección de procesos,herramientas, módulos y el desarrollo de manera exclusiva de otros rasgos que constituyenventajas observadas en los demás sistemas antes descritos.1.7.1 Gestión de Fuentes de DatosPara garantizar una forma de gestionar las fuentes de datos de manera independiente a lasdiferentes tecnologías, concepciones y SGBD, es que se decide seleccionar el módulo de47

CAPÍTULO I. Antecedentes y Detalles de la Investigacióngestión de conexiones y fuentes de datos implementado para el asistente gráfico de gestión dereportes iReport de Jasper Corporation. Esta herramienta creada en Java, incorpora laportabilidad de dicho lenguaje y otros de sus rasgos que garantizan flexibilidad eindependencia, y además permite la gestión de fuentes JDBC, XML, CSV, EJBQL, Hibernate,entre otras (Ver Figura 8).La potente biblioteca en la que se basa iReport (JasperReports), y el amplio grupo de opcionesde tipos de fuentes de datos que soporta, garantiza que sea una opción de amplio alcance paradefinir puntos múltiples que abastezcan los reportes que posteriormente se puedan crear. Sucompletitud se ajusta en gran medida a los propósitos perseguidos en función de garantizar elabastecimiento de datos para los reportes, y el hecho de ser de código abierto aumenta sufavoritismo para el trabajo que se desea realizar al brindar completamente todos sus archivosfuentes.Figura 8. Alternativas de tipos de conexiones de iReport 3.0.0.1.7.2 Proceso de Concepción y Gestión de ReportesLa estructura que se adoptará para el proceso de gestión de reportes estará formada por lospasos explicados en el epígrafe 1.3.1.5 y se presentarán en un orden igual al descrito. Laselección de este proceso ha de permitir el uso de asistentes que respalden cada uno de suspasos y garanticen una elevada flexibilidad en la herramienta.48

CAPÍTULO I. Antecedentes y Detalles de la Investigación1.7.3 Estructura de la Plantilla y EspecificacionesLa estructura del fichero base que almacenará la definición del reporte y la informaciónrelacionada a la apariencia visual de su plantilla será la XML. Anteriormente se expuso unconjunto de herramientas que vienen adoptando tal tecnología como respaldo a la definición desus reportes, lo que garantiza la extensibilidad de los mismos y su uso en diferentesplataformas.También los esquemas a los que puede responder un fichero XML aumenta el ajuste de losreportes frente a diferentes escenarios siempre presentando la flexibilidad que ofrece latecnología XML al poder cambiar el esquema asignado. Los ficheros JRXML, como antes semencionara, se ajustan de manera abstracta a situaciones diferentes mediante una sólidadefinición de su plantilla. Bajo los términos de esta tecnología conviene entonces considerartambién la forma en que almacena los reportes JasperReports.Es útil considerar el uso de RDL para cubrir aspectos que pudieran ser pasados por alto en ladefinición del DTD de las plantillas de JasperReports, así como el repaso de la especificaciónSMDL para fortalecer la riqueza semántica y su enlace con las fuentes de datos para el modelodel reporte a conformar. La combinación de RDL, SMDL y JRXML junto a la gestión deesquemas y DTDs para XML ciertamente puede garantizar una modelación e implementaciónflexible, sólida y completa de plantillas y componentes de reportes para cualquier situación quepudiera exigir una representación compleja de la información.La apariencia visual de la plantilla se debe establecer de manera flexible esencialmenteincorporando la mayor cantidad de tipos de bandas útiles para permitirle al usuario desarrollarreportes altamente personalizados acorde a sus necesidades e iniciativas, aspecto que incitaráexpresar las diferencias de concepciones y criterios con el fin de ampliar el espectro de estudiode las posibles clases de usuarios. La forma de establecer las bandas responderá a laconcepción genérica referida en el epígrafe 1.3.1.2.1.7.4 Gestión de Compatibilidad, Flexibilidad, Extensibilidad y SeguridadUtilizar tecnología XML garantiza que los esquemas de los reportes puedan gestionarse demanera independiente, por lo que podrán ser exportados y reconocidos de maneraindependiente siempre que las herramientas cumplan las reglas definidas en sus esquemas.También recibiendo como fuente ficheros de formato XML se garantiza exportar a formatosreconocidos como el PDF, HTML, RTF, entre otras representaciones [81][97] .49

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónEs importante recordar que la tecnología XML consiste en un estándar por excelencia para elintercambio de información estructurada entre diferentes plataformas, por lo que su uso ha degarantizar compatibilidad, portabilidad y extensibilidad en los productos de reportes a crear.iReport presenta también opciones para exportar a diferentes formatos de ficheros quegarantizan la aceptación de los reportes por muchas herramientas, tecnologías y plataformas.La codificación de tales funcionalidades se encuentra disponible al pertenecer a unaherramienta de código abierto, por lo que por esta parte existente también bondades que sepudieran aprovechar para el desarrollo del trabajo.El tratamiento exclusivo dado a la flexibilidad se realizará a través del uso de las bibliotecasBCEL y jclasslib, utilizándolas en combinación de manera similar a como JBE lo hace. Talesopciones se han escogido debido a la buena documentación que presentan, así como lapotencia con que logran cumplir sus objetivos. Se pretende regir las acciones de flexibilidad einyección de código para la inserción de nuevas opciones siguiendo el estándar PLIB definidopara efectuar un trabajo de calidad y cumpliendo con aspectos sólidos previamente definidos.También se utilizará el servicio JAAS de Java para implementar de manera personalizadamecanismos de seguridad que permitan la gestión de roles de usuarios. Se pretende ofrecerfuncionalidades vinculadas a la distribución de opciones de menú de manera dinámica acorde ala clase de usuario que utilice el sistema y los derechos del mismo. Fundamentalmente temasde autenticación y autorización.1.7.5 Selección de Herramientas para Desarrollo de la SoluciónPara cumplir los objetivos trazados en el trabajo y lograr un desarrollo eficiente de un productode software que represente una óptima solución a la situación antes descrita debenseleccionarse las herramientas estudiadas que permitan incorporar la mayor cantidad deventajas al sistema durante todo su ciclo de vida.Como lenguaje de programación se ha seleccionado Java por permitir el desarrollo deaplicaciones portables y garantizar una alta flexibilidad. Además presenta una amplia ypoderosa comunidad de desarrolladores extendida por todo el mundo y presenta herramientasmuy poderosas de desarrollo, bibliotecas de código abierto y libre uso enfocadas a diferentespropósitos donde se encuentran los productos de JasperSoft Corporation.A diferencia de muchas otras opciones estudiadas, iReport ha sido implementado sobre Java yse distribuye con disponibilidad a sus fuentes de codificación. Por las ventajas que incorpora y50

CAPÍTULO I. Antecedentes y Detalles de la Investigaciónsu enfoque general al tratamiento de reportes constituye uno de los asistentes gráficos másbondadosos para estos fines.iReport ha sido implementado utilizando la biblioteca JasperReport para la gestión de reportesy JFreeChart para el manejo de gráficos. Incluye otras herramientas muy poderosas queadicionan funcionalidades extras a los procesos d gestión de reportes y que permiten untratamiento personalizado a la extensibilidad permitiendo al producto ser reconocido por otrasherramientas.Los productos de Jasper crean reportes sobre plantillas JRXML y al disponerse de su códigopuede adicionarse un mecanismo que permita personalizar el acceso de los usuarios a cadaopción disponible de menú. Java posee todas las bondades necesarias para implementar unmódulo de gestión de reportes con vistas a un trabajo futuro sobre el área de la gestión de rolesde usuarios en procesos de gestión de reportes. Es por ello que se ha decidido para larealización del presente trabajo seleccionar al proyecto iReport con sus fuentes junto al restode las bibliotecas y tecnologías que involucra.1.8 ConclusionesEl presente capítulo se concluye habiendo realizado el análisis de los antecedentes de lagestión de los reportes a modo de introducción. En el mismo se abordó el trabajo que antecedeal presente y se describieron los principales propósitos perseguidos con la investigación.Además, fueron introducidos conceptos básicos que serán citados en el resto del documento yque conforman la esencia teórica del tema tratado.También se realizó una descripción y el análisis crítico al generador de reportes creado para elsistema GREHU, el cual pudiera considerarse como la génesis de un conjunto de trabajosrelacionados en el tema. Se justificó la idea de extender los problemas analizados al resto delas herramientas de gestión de reportes por medio de razonamientos expuestos y con la ayudade conclusiones obtenidas en otras investigaciones relacionadas a otros trabajos efectuados enel área.Uno de los aspectos esenciales tratados en este capítulo fue el análisis del estado del arte parajustificar el desarrollo de la solución y seleccionar las herramientas y tecnologías óptimas parasu diseño e implementación. Tal actividad permitió llegar a la conclusión de que lasherramientas existentes exponen el tratamiento a la gestión de reportes sin una consideracióndetallada de la interacción de esta área con la gestión de roles.51

CAPÍTULO I. Antecedentes y Detalles de la InvestigaciónPara el desarrollo de la solución propuesta en el presente trabajo se seleccionó un conjunto deherramientas de libre distribución y uso que permiten el desarrollo y la comercialización deproductos sin necesidad de realizar pagos adicionales por licencias. Tales herramientasrelacionan las tecnologías de Java y XML. Entre ellas se incluyen algunas de código abierto ylibre modificación como la biblioteca de reportes JasperReport y la herramienta gráfica dediseño de reportes iReport.Para la gestión personalizada de opciones de menús desarrollados en Java y la gestión deroles de usuarios y el control de la seguridad, se seleccionaron: las bibliotecas BCEL y jclasslib,y la herramienta JBE, para el diseño, la inyección de código y la gestión de opciones de menúsde manera dinámica, y el servicio JAAS de Java para el control de la seguridad.Todas estas herramientas y tecnologías serán utilizadas en la concepción de la herramientadeseada incorporando las principales ventajas y funcionalidades más prometedoras que fueronapreciadas en el resto de los productos estudiados relacionados con la temática de losreportes.52

CAPÍTULO IICAPÍTULO II. DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA

CAPÍTULO II. Descripción de la Solución Propuesta2.1 IntroducciónDespués de definir los aspectos teóricos de mayor relevancia, citar y analizar la convergenciadel presente trabajo con otras investigaciones realizadas, y posterior a un análisis detallado delestado del arte relacionado, concluyendo con la justificación del desarrollo de una nuevaherramienta según los propósitos seguidos, se prosigue con la concepción, el análisis y eldiseño de la misma.“Descripción de la Solución Propuesta” es un capítulo que involucra temas de concepción sinllegar a plasmar aspectos de implementación. El mismo se inicia detallando la captura decriterios que resultan esenciales para la construcción de la herramienta y la satisfacción de losusuarios. En él también se exponen y fundamentan los requerimientos y reglas a considerar,entre otras cuestiones que constituirán la esencia de la gestión de la información.Teniendo en cuenta que la herramienta puede alterar su estructura, algunos requerimientos delos usuarios sobre la misma podrían cambiar con el tiempo. Este aspecto podría ser asimiladoeficientemente por la solución si se logra desarrollar con la flexibilidad deseada e incorporar eldinamismo requerido en sus procesos. Todas las tareas relacionadas a este tema debenconsiderarse críticas en cada fase del ciclo de vida del sistema a concebir.Como actividad final y de mayor volumen en el capítulo, se definen los procesos y mecanismosque posteriormente serán implementados. Estableciendo criterios bien fragmentados, se tratade dividir cada actividad concibiendo módulos y oficializando términos según la metodología dedesarrollo del software RUP.2.2 Definición de los Requerimientos de la SoluciónLos requerimientos funcionales del sistema fundamentalmente fueron obtenidos a través deentrevistas y consultas a clientes y usuarios potenciales, reutilizando los formularios referidosen el capítulo anterior (Ver Anexo 7) enfocados en las necesidades existentes y la detección deregularidades para la modelación abstracta y el posterior diseño del producto. También, demanera menos profunda, se utilizaron elementos básicos de metodologías de diseño guiadaspor objetivos, para la captura de consideraciones críticas para el desarrollo del módulo degestión de roles de usuarios.Considerando el impacto de la solución en el área de gestión de reportes y su interacción conla gestión de roles de usuarios, fueron definidos los siguientes requisitos:54

CAPÍTULO II. Descripción de la Solución Propuesta La presencia de asistentes simples en la aplicación que permitan la definición de reportescompletos y personalizados sin requerirse de conocimientos avanzados de computación. La existencia de editores avanzados para la definición de expresiones lógicas complejaspara la selección o filtrado de la solución, así como el establecimiento de operacionesestadísticas y matemáticas que permitan obtener e incorporar información relevante en losreportes. La disponibilidad de un editor de plantillas de reportes que garantice la obtención dereportes altamente personalizados gráficamente considerando temas como: estilo, color ytipos de fuentes, tablas, gráficos, figuras, etc. La existencia de un mecanismo de gestión dinámica de usuarios en el sistema quegarantice el manejo de los privilegios mediante el establecimiento de políticas deseguridad. El ofrecimiento de una interfaz intuitiva que se ajuste a las necesidades de cada usuario,permitiéndoles utilizar el sistema de manera sencilla y cómoda. La disponibilidad de mecanismos que garanticen exportar los reportes a diferentesformatos estándares con el fin de permitir que sean utilizados en otras herramientas dediferentes tecnologías. La posibilidad de gestionar la obtención de la información a mostrar en los reportes desdela mayor cantidad de fuentes de datos posible independientemente del diseño, tecnologíay estructura de estas. El funcionamiento de la herramienta como un todo independientemente del ambiente o laplataforma de explotación.2.3 Definición del Dominio de la SoluciónUna vez definidos los requerimientos funcionales, es importante capturar la estructura deldominio que va a regir el sistema y las reglas que deberá cumplir. Estas tareas puedenconsiderarse como las primeras a efectuar para la modelación de la herramienta. A pesar deldinamismo que se pretende incorporar en el sistema, es importante tener en cuenta laestructura de la aplicación debe basarse en criterios que, de ser modelados incorrectamentedesde un inicio, pueden comprometer el éxito de la investigación.55

CAPÍTULO II. Descripción de la Solución Propuesta2.3.1 Conceptos Relevantes del Dominio de la SoluciónLos conceptos fundamentales que conforman el dominio del sistema y constituirán la base desu modelación son: Acceso: Registro de fecha, hora y tiempo de trabajo de un usuario en el sistema. Acción: Registro de un evento significativo que altere la información, provocado por unusuario. Fuente: Fuente de datos que abastece a una plantilla de reporte. Grupo: Conjunto de elementos básicos que conforman una fuente de datos. Opción: Punto de acceso a una funcionalidad del sistema. Permiso: Restricciones o concesiones otorgadas a un rol de usuario sobre una opción. Plantilla: Conjunto de reglas y aspectos claves que rigen la estructura visual de un reporte,el procesamiento de los datos a mostrar y la forma de imprimirlo. Reporte: Elemento obtenido a partir de una plantilla, dada una solicitud de un usuario enun momento determinado. Repositorio: Almacén de las plantillas de reportes diseñadas. Rol: Papel que rige el comportamiento de un usuario frente al sistema. Traza: Registro persistente del acceso y la acción de un usuario. Usuario: Persona que utiliza las funcionalidades del sistema y responde ante un roldeterminado.2.3.2 Relaciones entre Elementos del DominioCada elemento del dominio se vincula a la gestión de roles de usuarios o a la gestión dereportes. Tales grupos de entidades se relacionan a través del ente ‘Usuario’, encargado deiniciar y controlar el funcionamiento de los diferentes procesos.En la figura 9 se expone la relación de las entidades definidas en el epígrafe anterior, donde serelacionan componentes de la gestión de reportes, los elementos que interactúan con lasplantillas y otras entidades necesarias para la gestión de los roles de usuarios.56

CAPÍTULO II. Descripción de la Solución PropuestaFigura 9. Relación entre los Principales Objetos del Dominio.2.3.3 Reglas a ConsiderarTodo sistema informático debe cumplir con ciertas reglas relacionadas con el entorno en que sevaya a utilizar, de modo que se garantice su correcta adecuación al mismo. Las principalesreglas tenidas en cuenta en el presente trabajo fueron: Las acciones que comprometan la estructura del sistema deberán ser validadas por elExperto del Negocio y sólo después podrán ser ejecutadas. Siempre que se desee realizar un reporte se debe gestionar primeramente la fuente de losdatos que abastecerá de información al mismo. Una fuente de datos puede ser utilizada para la creación de múltiples diseños de reportes,los cuales también pueden ser utilizados como base para la creación de otros diseños. El proceso de creación de reportes se regirá exclusivamente por la fuente de informaciónseleccionada, por lo que los pasos relacionados a la selección, ordenamiento,agrupamiento y filtrado de información, así como la incorporación de operaciones lógicas ymatemáticas, actuaran únicamente sobre datos ofrecidos por la fuente. Cada plantilla de reporte creada, dependiendo de su naturaleza, deberá asociarse a unaopción de menú de la aplicación donde pueda utilizarse para la obtención del reporte. Un reporte podrá exportarse únicamente al haberse concluido la creación de su plantilla ydespués de revisar una vista previa de su impresión.57

CAPÍTULO II. Descripción de la Solución Propuesta2.4 Solución PropuestaEs importante definir la jerarquía de roles de usuarios que inicialmente presentará el sistemapara poder delimitar, de los procesos a modelar, los que cada uno realizará. De esta forma seráposible asegurar el punto de partida de la herramienta para que los usuarios que tenganpermiso, propongan nuevos roles y definan la responsabilidad de estos en dependencia delnegocio donde comience a utilizarse la aplicación. Para asegurar tales tareas en el presenteepígrafe se realiza la modelación del sistema mediante los actores y los casos de uso, y deexpone la estructura concebida para el mismo.2.4.1 Actores y Casos de Uso del SistemaPara la herramienta propuesta se ha establecido un conjunto de actores, algunos de los cualescoincide con los del generador de reportes del sistema GREHU, mencionados en el epígrafe1.4.1 (Ver Tabla 2).El primero de ellos es el Consultor de Reportes, encargado de visualizar los reportes, realizarimpresiones o exportarlos a otros formatos. El Diseñador, por su parte, será el responsable degestionar el repositorio y administrar la creación, modificación y eliminación de plantillas, similaral rol definido anteriormente en el generador de reportes del GREHU.El rol de Experto del Sistema, que consistía en garantizar la disponibilidad de fuentes de datosacorde a los reportes que se deseasen elaborar, en el nuevo sistema será desempeñando porel Informático de la entidad donde se utilice la solución. Este cambio surge como generalizacióndel generador de reportes a otros entornos de acción diferentes a los del sistema GREHU.Además, el rol del Informático deberá responder a los intereses del negocio por medio de lagestión de roles de usuarios, de acuerdo a las nuevas funcionalidades a incorporar en laherramienta.A diferencia de la jerarquía establecida para el generador de reportes del GREHU, se definiócomo nuevo rol el Experto del Negocio, que es el encargado de orientar la obtención de fuentesde información acorde con las necesidades de los reportes, validar su diseño y ordenar lacreación de reportes ad-hoc. El Experto del Negocio, al igual que el Informático, tambiéndesempeñará la gestión de roles de usuarios (Ver Figura 10).Es importante recordar que el módulo de gestión de roles de usuarios de la herramientapudiera incorporar nuevos roles que interactúen con el sistema de manera diferente a losmencionados anteriormente, los que conforman la propuesta de la jerarquía inicial acorde a los58

CAPÍTULO II. Descripción de la Solución Propuestaestudios realizados. Debido a esto es que se vincula el Experto del Negocio al caso de uso“Gestionar Roles de Usuarios”, procurando mantener con su experiencia, junto al Informático, laconservación de la estructura del sistema.Figura 10. Diagrama de Casos de Uso del Sistema.El caso de uso “Gestionar Roles de Usuarios”, además de contener los procesos de adición,supresión o modificación de roles, incorpora actividades de asignación de roles a usuarios ymantenimiento de la jerarquía de roles sobre la que funcione el sistema en la entidad. Estaúltima tarea se desarrollará auxiliándose del estudio de las trazas de los usuarios.59

CAPÍTULO II. Descripción de la Solución Propuesta2.4.2 Estructura de la HerramientaLas funcionalidades de la herramienta a desarrollar se relacionan con la gestión de roles deusuarios, de trazas y de reportes, por lo que la estructura del sistema ha sido formadafundamentalmente por tres módulos donde se incluirán los procesos automatizadosrelacionados con tales aspectos (Ver Figura 11).Sistema de Gestión Dinámica y Personalizada de ReportesMódulo de Gestión de ReportesPresentación de Reporte(control de la distribución, gestión de impresión y exportación)Gestión de Reporte(selección de fuente y de datos, ordenamiento, agrupamiento,filtrado, incorporación de operaciones)Módulo de Gestión de Roles(creación y edición de roles)Control de la Jerarquía(redefinición y perfeccionamiento de lajerarquía de roles)Asistentes GráficosCreación de ReporteOperacionesMatemáticasGestión dePlantillaOperacionesLógicasMódulo de Gestión de Trazas(control de trazas)Gestión de Fuentes de Datos(descriptores, tipos de datos, diseños de fuentes de datos)Figura 11. Estructura del Sistema Propuesto.2.5 Principales Procesos a AutomatizarLa definición y el estudio de los procesos a automatizar es una tarea de crítica importancia parael correcto funcionamiento del sistema. Es importante que se conozca cada actividad y semodele de forma apropiada, de modo que se garantice el ajuste de la herramienta al entorno enel que se pretende utilizar. En el presente epígrafe se describen los procesos más críticos,oficializándolos y justificando la selección de tecnologías o herramientas informáticas para suposterior implementación.60

CAPÍTULO II. Descripción de la Solución Propuesta2.5.1 Gestión Trazas y Roles de UsuariosEl proceso de gestión de roles de usuarios está constituido fundamentalmente por dossubprocesos o partes: la creación, modificación o supresión de roles y la optimización de lajerarquía de roles del sistema acorde al negocio donde se utilice la herramienta.El propósito fundamental de crear o modificar roles de usuarios consiste en indicar las opcionesa las que tendrá acceso cada usuario acorde a su función en la organización, estableciendo deesta forma políticas de seguridad y niveles de acceso a las funcionalidades del sistema.Aunque inicialmente el sistema contará con los roles de Informático, Visor de Reportes,Especialista de Negocio y Diseñador de Reportes; estos pueden ser alterados por un usuarioque posea permiso para tales operaciones. También será posible añadir nuevos roles oeliminar los que se consideren inadecuados siempre que se apruebe tal acción.Por otra parte, el módulo para el control de las trazas, que es el más sencillo de la aplicación,construirá una herramienta que podrán consultar los usuarios responsables de la optimizaciónde la jerarquía de roles de la aplicación. El mismo permitirá conocer el estado de las consultasa las opciones del sistema por parte de cada usuario. Gracias a esto será posible apreciar siexisten opciones asignadas a un rol determinado y ningún usuario de dicho rol la estáutilizando, o si las actividades que desarrolla un determinado usuario con la herramienta hanexperimentado variaciones sugiriendo la consideración de un cambio de rol.Únicamente los usuarios que posean el rol de Expertos serán los responsables de validar lajerarquía de roles con la que cuente el sistema, optimizándola por medio de la creación,modificación o supresión de roles antes descrita.Para la implementación de las políticas de seguridad en el módulo de gestión de roles deusuarios se ha seleccionado el servicio de autenticación y autorización de Java (JAAS), dondelas actividades de autenticación y autorización pueden implementarse con una clara diferenciay respondiendo a la arquitectura de la seguridad definida por Java.Utilizando JAAS se controla primero la autenticación de cada usuario, creando un contextopropio para estos, utilizando un fichero de configuración para el acceso, lo que garantiza unaindependencia de las tecnologías de autenticación. Solamente después que un usuario se haautenticado se procede a la gestión de la autorización para chequear los recursos de laaplicación a los que el mismo tiene derecho a acceder.61

CAPÍTULO II. Descripción de la Solución Propuesta2.5.2 Gestión de Reportes InformáticosLa esencia del sistema que se pretende desarrollar consiste en garantizar la gestión dinámica ypersonalizada de reportes, por lo que cada actividad de este proceso debe presentar una altaflexibilidad y dinamismo. Seguidamente se describe cada subproceso que conforma la gestiónde reportes según la definición realizada para la implementación de la solución.2.5.2.1 Definición y Administración de Fuentes de DatosLas fuentes de datos estarán compuestas por grupos relacionados entre sí que contendránfragmentos de bases de datos o ficheros. El proceso de creación de una fuente de datos seiniciará ante la solicitud del Experto del Negocio dada la necesidad de un nuevo reporte, el cualno pueda crearse ni abastecerse con las fuentes existentes. En dependencia de los datos quedeberá poseer el reporte, se diseñará la fuente de datos en términos genéricos, concluyendo suelaboración el Informático responsable de la atención del sistema.Una fuente de datos puede ser creada completamente o utilizando otras fuentes como plantillaspara reutilizar su estructura en caso conveniente, ahorrando tiempo y trabajo en la creación.Sobre una fuente de datos podrán construirse y abastecerse múltiples reportes, yexclusivamente, cuando no existan reportes que utilicen una fuente de datos, esta podrá sereliminada. La creación de la fuente de datos concluirá cuando se disponga de una conexiónque garantice la obtención de reportes sobre la misma.Para la implementación apropiada del proceso de gestión de fuentes de datos se garantiza conel uso de JasperReport e iReport. La ventaja de considerar estas herramientas viene dada porel módulo que ellas contienen para la gestión de fuentes de datos, en el que consideranmúltiples tecnologías de gestión de persistencia y sistemas de gestión de bases de datos.2.5.2.2 Asistentes Gráficos para la Gestión de ReportesPara la gestión de reportes en la herramienta se utilizarán múltiples asistentes gráficos quegaranticen el proceso de concepción de la plantilla, así como la inclusión de operacioneslógicas, matemática y la gestión gráfica de la plantilla una vez creada. En dependencia de laexperiencia del usuario y acorde al rol que este desempeñe, el sistema expondrá una interfazgráfica que le permita realizar, de forma cómoda, tales actividades.El uso de asistentes para cada operación, facilita la edición de expresiones lógicas ymatemáticas complejas, así como el trabajo gráfico detallado particularizando tipos de fuentes,colores, y demás temas de apariencia que garanticen la obtención de un producto refinado.62

CAPÍTULO II. Descripción de la Solución Propuesta2.5.2.3 Flexibilidad y Extensibilidad del Producto de ReportePara aumentar el grado de flexibilidad a la herramienta, una vez creada la plantilla, será posiblela asignación de esta a una opción de menú donde pueda accederse para obtener el reporte.Además, cada plantilla creada podrá localizarse en el repositorio para realizársele trabajos demantenimiento en caso que sea necesario.El repositorio, como almacén de las plantillas, ha de permitir la redistribución de los reportes, sumodificación o eliminación. El trabajo con el repositorio constituye también la clave para lareusabilidad de los esquemas de reportes. Al disponerse de las plantillas realizadas, es posibleexportar los reportes a otros formatos que permitan ser utilizados por otras herramientas, lo quetributa directamente a la extensibilidad del reporte como producto independiente de laaplicación.Para la creación de opciones que menú a las que se asignen los reportes creados para suejecución, se han seleccionado las bibliotecas jclasslib y BCEL. Ellas permiten modificarficheros de java compilados (.class), por lo que si se orienta la gestión hacia del bytecode quedefine la interfaz gráfica, es posible alterarla añadiendo entradas que incorporen nuevasfuncionalidades, en este caso destinadas a la ejecución de reportes.La clase principal para la gestión del bytecode en los ficheros compilados de Java esJavaClass, perteneciente al paquete org.apache.bcel.classfile de la biblioteca BCEL. La mismapermite cargar un fichero .class y gestionar su estructura. Con el uso de la clase ConstantPoolse podrán obtener los elementos que componen el .class para, por medio de la claseConstantPoolGen proponer una estructura genérica que finalmente se entregará a JavaClass,la cual suplantará el viejo fichero por el nuevo.La clase que gestiona los campos genéricos del fichero .class se nombra FieldGen. La mismapuede utilizarse para adicionar nuevos campos al fichero. Otra clase que permitirá gestionarnuevos métodos que se deseen adicionar al .class es MethodGen, la cual, en principio,funciona similar a FieldGen.En la figura 12 se muestra un segmento de la definición del método addField, encargado deadicionar un nuevo campo, el cual se mostrará en la interfaz por medio de un descriptor.También, en un fichero .class se pueden incorporar métodos que implementen determinadasfuncionalidades utilizando la clase MethodGen antes mencionada (Ver Figura 13).63

CAPÍTULO II. Descripción de la Solución Propuestaorg.apache.bcel.classfile.JavaClassRepresenta un fichero .class de Javaorg.apache.bcel.classfile.ConstantPoolAlmacena la definición del fichero originalorg.apache.bcel.generic. ConstantPoolGenCrea una definición de un fichero .classFigura 12. Fragmento del cuerpo del Método addField.Figura 13. Fragmento del cuerpo del Método addMethod.64

CAPÍTULO II. Descripción de la Solución PropuestaPor otra parte, la extensibilidad de los reportes se garantiza con la selección del formato defichero JRXML para la estructura de las plantillas. Estos ficheros tendrán esquemas asignadosque permiten estandarizar los elementos que los componen (Ver Figura 14). Como documentosXML, también podrán ser representados gráficamente en diferentes formatos, aspecto que sedesarrolla con gran facilidad utilizando la clase JasperExportManager de la bibliotecaJasperReport (Ver Figura 15).Figura 14. Segmento de Definición de un fichero JRXML.Figura 15. Métodos de la clase JasperExportManager de JasperReport.65

CAPÍTULO II. Descripción de la Solución PropuestaPara el desarrollo de las plantillas de los reportes, además de tomar las ventajas de los ficherosJRXML se ha estudiado su representación utilizando SMDL y RDL. Aunque estasespecificaciones presentan muchos aspectos en común con el formato JRXML, SMDLestablece un mayor énfasis en la diferenciación de los elementos semánticos del reporte y loselementos físicos del mismo. Tal consideración ha permitido gestionar la plantilla de losreportes de manera abstracta, orientando primeramente la esencia semántica y posteriormente,su estructura física. Dicha consideración ha ofrecido mayor flexibilidad a los procesos degestión de reportes de la herramienta.2.6 Otras Alternativas para la Gestión de los ReportesEl proceso de gestión de reportes también podrá realizarse de manera similar a la forma en quelo hace la herramienta iReport en dependencia del rol que desempeñe el usuario que utilice elsistema. En la aplicación existirán puntos de accesos a tal herramienta y además se ofreceránpaquetes que puedan ser utilizados, que estén acorde al negocio donde se trabaje con lasolución. Tales paquetes contendrán propuestas de roles de usuarios a utilizar en un comienzo,además de las descritas anteriormente, así como esquemas para fuentes de datos y plantillasde reportes.El sistema también permitirá la edición de las plantillas de los reportes como documentos XMLmediante un editor de código, funcionalidad con la que los usuarios conocedores podránrealizar un trabajo flexible de acuerdo con las restricciones que impongan los esquemasasociados.2.7 ConclusionesEn este capítulo fueron descritos aspectos relacionados con la concepción de una herramientadestinada a gestionar de manera dinámica y personalizada reportes informáticos, y administrarla estructura jerárquica de roles de usuarios relacionados con reportes en una entidadempresarial. En él también, por medio del análisis y el diseño, sin llegar a comprometer elcontenido expuesto con detalles de implementación, fue definida la estructura general de laaplicación.Además, se realizó la captura e introducción de requerimientos, los cuales se consideranesenciales para el funcionamiento de la herramienta. La solución fue definida formalmentepartiendo de la representación de su dominio y las reglas que esta deberá cumplir. Se66

CAPÍTULO II. Descripción de la Solución Propuestaoficializaron ideas sobre los procesos y mecanismos fundamentales, así como el dinamismo yla flexibilidad de la aplicación, y la manera de garantizar la persistencia de su estructuramediante el control de las acciones de los usuarios.67

CAPÍTULO IIICAPÍTULO III. DETALLES DE IMPLEMENTACIÓN, PRUEBA YEVALUACIÓN DE RESULTADOS

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de Resultados3.1 IntroducciónEn el presente capítulo se presenta la arquitectura del sistema y se describen detalles de laimplementación de cada uno de los módulos, mecanismos y procesos definidos. Además, semuestra el diseño de la base de datos como aspecto principal para el control de la persistenciade la información, y se detallan consideraciones relacionadas a la interfaz gráfica de usuario yotros requisitos no funcionales.Posterior a los aspectos de implementación, se describe el tratamiento de las pruebasrealizadas a la herramienta y la evaluación de su impacto. Para ello, primeramente se exponenlos planes de prueba definidos y los criterios a tener en cuenta en la ejecución de estos.Seguidamente se analizan los resultados obtenidos y se hace una valoración crítica de losmismos, concluyendo con detalles relacionados al impacto del sistema en su área de acción.3.2 Aspectos de ImplementaciónEn el presente epígrafe se abordan temas relacionados con la implementación de sistemapropuesto. Partiendo de la arquitectura definida, se tratan aspectos vinculados a la realizaciónde los diferentes módulos de la herramienta, la gestión de los datos y los principales criteriostenidos en cuenta para el desarrollo de la interfaz gráfica de usuario. En él también se incluyenalgunas consideraciones para los requisitos no funcionales que garanticen el óptimofuncionamiento de la solución.3.2.1 Arquitectura del SistemaLa arquitectura del sistema a desarrollar se compondrá esencialmente por los tres módulos: elmódulo de gestión de roles de usuarios, el módulo de control de las trazas y el módulo degestión de los reportes. La misma se define basada en la concepción de capas donde seasciende de la capa inferior, responsable del almacenamiento de las fuentes de datos, a lacapa superior, relacionada con la presentación, donde se localizan los componentes de lainterfaz gráfica de usuario agrupados según sus funcionalidades.Además se cuenta con la capa de acceso a datos donde se realiza la gestión de las fuentes dedatos para los reportes, y la capa de lógica de negocio, previa a la de presentación, donde seencuentras los módulos antes mencionados acompañados por paquetes que incluyenherramientas externas al sistema (Ver Figura 16).69

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de ResultadosEn la capa de lógica de negocio aparece, además de los módulos principales, paquetes queagrupan algunas herramientas que garantizan el tratamiento eficiente de los procesos aautomatizar. El paquete JAAS incluye el servicio de autenticación y autorización de Javareferido en los capítulos anteriores, y el paquete JAXP incluye el API de Java para elprocesamiento de documentos XML, para la gestión detallada de las plantillas de reportes deficho formato.Figura 16. Arquitectura de Capas del Sistema de Gestión de Reportes.Otros paquetes de la capa de Lógica de Negocio son: el paquete Plantilla, encargado delalmacenamiento físico de las plantillas de los reportes que se realicen y sobre la cual actuará70

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de Resultadosdirectamente el repositorio; y el paquete iReport, que contendrá módulos de tal herramienta, loscuales brindarán algunas de sus funcionalidades.3.2.1.1 Módulo de Gestión de ReportesEl módulo de gestión de reportes constituye la esencia del sistema en desarrollo. La ideaprincipal seguida en su implementación fue utilizar una clase que representa la plantilla de losreportes en desarrollo y por medio de la cual se realiza la gestión de los ficheros jrxml. Unaclase similar se utiliza en el momento de obtener los datos de la plantilla desde el repositoriopara la impresión de un reporte. Tales clases se relacionan directamente con la responsabledel control de la gestión de los reportes en el modulo de gestión de reportes del sistema.En la figura 17 se muestran las clases, atributos y métodos más relevantes según lasfuncionalidades del modulo de gestión de reportes. En ella se puede observar la clase querepresenta la plantilla de un reporte, asociada a múltiples clases que indican el conjunto derestricciones o criterios a aplicar en el diseño de la plantilla y la confección de su fuente dedatos.Figura 17. Relación entre las Principales Clases del Módulo de Gestión de Reportes.71

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de ResultadosOtra relación que surge con la clase que controla la gestión de los reportes es la establecidacon la encargada de la administración de las operaciones de exportación, la cual manejaprocesos que permiten utilizar diferentes formatos de ficheros para exportar los reportes (VerFigura 17).3.2.1.2 Módulo de Gestión de Roles de UsuarioEl módulo de gestión de roles de usuarios constituye un módulo de respaldo a la gestión dereportes, desarrollado para incorporar mayor flexibilidad y ajuste organizacional al primero,independientemente del entorno donde se utilice el mismo.La idea principal para su implementación fue el seguimiento del proceso de control de opcionessobre roles de usuarios por medio de una matriz donde las columnas son las opciones y lasfilas los roles registrados. Cada intercepción fila-columna contiene un valor que describe laforma en que está asociado un rol a una opción del sistema. De esta forma es posiblediferenciar el despliegue de cada funcionalidad por medio de la interfaz gráfica de usuario endependencia del rol al que pertenezca este.3.2.1.3 Otras Funcionalidades IncorporadasEn la capa de lógica de negocio, para el tratamiento de los procesos automatizados, seincluyeron paquetes que inciden directamente en el desarrollo eficiente de las funcionalidadesde la herramienta. El paquete JAAS contiene el servicio de autenticación y autorización de javaque permite el control estricto de las opciones de la herramienta y el establecimiento depolíticas se seguridad para los usuarios. También el paquete JAXP garantiza que se gestioneeficientemente las plantillas enfocadas bajo la concepción de documentos XML.El paquete iReport, por su parte, contiene el proyecto iReport de Jasper Corporation, medianteel cual se ofrecen algunas de sus funcionalidades, como son: la gestión de fuentes de datos apartir de una amplia variedad de tecnologías, y la administración de la impresión y exportaciónde los reportes a múltiples formatos reconocidos.Muchas de las funciones del sistema ofrecen sus resultados para ser reutilizados para ladefinición de elementos similares por medio de esquemas ya creados, en búsqueda de ladisminución del tiempo de concepción de elementos como las plantillas de reportes, las fuentesde datos y los roles de usuarios. De esta forma la herramienta garantiza la disponibilidad decada esquema creado con anterioridad, en caso que el usuario desee utilizarlo como punto departida de un proceso de creación. Gracias a esto, una plantilla de reporte, por ejemplo, puedeconstituir la base para la creación de un nuevo reporte con estructura similar.72

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de Resultados3.2.2 Gestión de la Persistencia de la InformaciónEl esquema de la base de datos creada para el almacenamiento y la gestión de los datos conlos que trabajará la herramienta responde a la información administrada por los módulosprincipales de la aplicación (Ver Figura 18). La mayor cantidad de tablas de la base de datos secorresponde al módulo de gestión de roles de usuarios, con el fin de mantener un registrodetallado de cada acción de los usuarios, garantizando la persistencia de la información quepermita ser utilizada en un futuro para un estudio posterior o la toma de decisiones claves parala continuidad del trabajo.Figura 18. Estructura de la Base de Datos de la Aplicación.El registro de las acciones de los usuarios, además de utilizarse para validar la optimización dela jerarquía de roles, puede formar, consolidar y respaldar las decisiones de los expertos quetrabajen con el sistema.Por otra parte, el módulo de gestión de reportes se enlaza con el módulo de gestión deusuarios por medio de la entidad que almacena los datos de las plantillas creadas. Lasplantillas, al desarrollarse y publicarse para su utilización, serán asociadas a una dirección queindicará el lugar donde obtener los reportes en la herramienta por medio de su diseño.73

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de ResultadosLa relación establecida entre la misma entidad “plantilla” indica la posibilidad de utilizar elesquema de una plantilla como punto de partida para el diseño de otras, ahorrando tiempo enla creación de reportes que expongan información similar o de forma semejante. El camporeusa, consiste en la llave de la plantilla utilizada como esquema de reuso de ser el caso.3.2.3 Consideraciones para la Interfaz Gráfica de UsuarioLa interfaz del sistema ha sido diseñada garantizando que responda al usuario en dependenciade sus roles. Teniendo en cuenta que la responsabilidad de cada usuario debe correspondersecon las tareas a cumplir por este en el negocio, su experiencia y principales habilidades, notoda persona debe tener acceso a las mismas funcionalidades, y las que si lo tengan, nonecesariamente deberá ser de la misma forma. Este asunto no sólo se limita al hecho dehabilitar u ocultar opciones, cada ventana debe ser capaz de ajustarse hasta el más mínimodetalle.Reutilizando muchas de las pantallas de iReport, se ha logrado obtener la mayor parte de loscomponentes de la capa de presentación del sistema. iReport, como proyecto de códigoabierto, ofrece las fuentes de implementación de sus procesos y su interfaz gráfica de usuario,únicamente se requiere realizársele adecuaciones para que se ajuste a las demandas delsistema desarrollado en el presente trabajo, evitando copiar idénticamente las pantallas.iReport no ha sido implementado para ser utilizado por usuarios de diferentes roles,únicamente viene dirigido a especialistas que diseñen reportes. Es por ello que el uso de suspantallas debe realizarse desglosando la forma de acceder a las funcionalidades endependencia de la clase de usuario que acceda al sistema. Un ejemplo claro lo constituye lapantalla para crear fuentes de datos a partir de consultas sobre bases de datos utilizando elacceso por medio del API JDBC (Ver Figura 19).La idea seguida para el desglose de las opciones relacionadas a la creación de fuentes dedatos se basa en permitir que los usuarios con conocimiento mínimo que requirieran crearfuentes de datos, utilicen el asistente. Solamente los usuarios con mayor dominio de lacomputación y la programación, tendrán acceso al editor de consultas. La idea en esenciaconsiste en aislar el contenido de las dos pestañas de la pantalla original (Ver Figura 19) comoopciones diferentes, las cuales se mostrarán en dependencia del rol con que acceda el usuarioa la herramienta.74

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de ResultadosEditor de ConsultasAsistente GráficoFigura 19. Pantalla de Edición de Fuentes de Datos de iReport 3.0.0.Otra pantalla ofrecida a usuarios relacionados con el trabajo gráfico de la plantilla es lamostrada en la Figura 20. Por medio de ella se garantiza que usuarios que posean habilidadespara el trabajo gráfico en la computadora, puedan obtener diseños altamente personalizados,redistribuyendo por las diferentes bandas los componentes propuestos por los asistentes derespaldo al proceso de creación de los reportes. Además, con esta ventana es posibleincorporar figuras, gráficos, y asignar colores y tipos de fuentes de texto.75

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de ResultadosFigura 20. Vista de Edición de la Plantilla de un Reporte.Otra pantalla a la que tendrán acceso usuarios con profundo dominio de computación yprogramación, es la que expone la vista de la plantilla del reporte como un documento XML,permitiendo su gestión por medio de codificación (Ver Figura 21). Las validaciones de lasoperaciones realizadas con esta pantalla serán respaldadas por los esquemas y losdocumentos de definición que actuarán sobre la estructura del documento.Figura 21. Pantalla de Gestión de Plantillas de Reportes como Documentos XML.76

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de ResultadosLos rasgos referidos, relacionados a la capacidad de ajuste y respuesta de la interfaz deusuario, además de la clara elocuencia de los nombres de las opciones, y la sencillez que secorresponda con el conocimiento del usuario y garantice el flujo pasivo y estricto de losprocesos de gestión, han sido las principales consideraciones del diseño de la interfaz de laherramienta.3.2.4 Requerimientos no Funcionales de la SoluciónEs importante que el sistema se adapte a cualquier estructura de negocio y se ajuste a lasdiferentes necesidades de los usuarios a fin de recolectar la mayor cantidad de jerarquías deusuarios que intervienen en los procesos de gestión de reportes de cada entidad empresarialen que se instale. Los requerimientos no funcionales más críticos para el funcionamiento de laaplicación, como se ha indicado anteriormente, han sido: la usabilidad, la extensibilidad y laflexibilidad. El tratamiento apropiado de los mismos permitió incorporarle a la herramienta losrasgos necesarios para garantizar su ajuste organizacional, obtener la satisfacción de losusuarios y la motivación de ideas para la gestión de reportes. Seguidamente se expone la basedel manejo realizado a cada uno de los requerimientos.La usabilidad se basa fundamentalmente en el diseño de una interfaz intuitiva que se ajuste alrol del usuario que utilice el sistema, facilitándole la realización de su trabajo. Algunas pantallasexigen del conocimiento de computación como lenguajes de consultas sobre bases de datos,empleando recuperaciones como fuentes para la creación de los reportes, otras sencillamenteguían a un usuario mediante asistentes simples y amigables sin necesidad del dominio deconocimientos de programación. En general, la interfaz empleada intenta ofrecer el acceso a lamayor cantidad de funcionalidades de manera simple, dependiendo del rol del usuario.La implementación de la extensibilidad se realizó ampliando el número de opciones deformatos de ficheros para exportar los reportes. Para esto se utilizó la tecnología XML quepermite elaborar reportes reconocidos por múltiples plataformas y herramientas [55] . Un mismodocumento XML puede mostrarse con diferentes formatos (HTML, PDF, RTC, etc.) [81][97] , lo quegarantiza un alto nivel de uso de los reportes mas allá de la aplicación que los crea. El uso delformato JRXML como extensión de los documentos XML [33][91] permitió la incorporación de lasfuncionalidades de la biblioteca JasperReport, la cual presenta módulos para exportar reportesa diferentes formatos [33] . También el proyecto de código abierto, iReport, realizado sobre talbiblioteca, fue utilizado para la representación gráfica de las opciones vinculadas a laextensibilidad.77

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de ResultadosLa flexibilidad, en cambio, se implementó por medio del registro dinámico de las opciones demenú, garantizando el almacenamiento de la estructura del mismo para insertar nuevasopciones en tiempo de ejecución en las que se encuentren los puntos de acceso a los nuevosreportes creados con la aplicación. A pesar de poder sufrir cambios con frecuencia, laestructura del menú se irá actualizando, permitiendo mantener su cuerpo real para la gestiónde sus opciones. Existirán opciones que no podrán ser modificadas, debido a que son las quepermiten la esencia del funcionamiento de los procesos de gestión de la solución. Esta partedel menú es considerara como el “cuerpo fijo de su estructura”. La capacidad de la herramientade alterar su estructura y los reportes que contenga, según las necesidades de los usuarios,permite que esta evolucione de manera diferente a sus otras instalaciones en negociosdistintos.El módulo de gestión de roles de usuarios tributará directamente al funcionamiento eficiente delos requerimientos antes mencionados. La diferenciación de los privilegios de los usuarios paraexponer las pantallas y las opciones de menú a las que tenga acceso es esencial para laimplementación realizada de la usabilidad y la flexibilidad. El módulo de trazas, por otra parte,constituye una herramienta que ofrece evidencias para las tareas de alteración y optimizaciónde la jerarquía de usuarios de la herramienta. Gracias a este es posible observar qué usuariostienen opciones asignadas que realmente no utilizan, así como la evolución de sus actividadesen función de los cambios en las tareas que realizan con el sistema en el tiempo.Otros requerimientos importantes lo constituyen la portabilidad y la adaptabilidad de laaplicación. Es conveniente garantizar la compatibilidad de la herramienta con la mayor variedadde sistemas operativos posible, aumentando su probabilidad de uso en escenarios diversos. Laportabilidad se incorporó al implementar la solución en el lenguaje de programación Java,donde la misma constituye uno de sus rasgos principales [20] . La adaptabilidad, en cambio, sepersiguió por medio del minucioso tratamiento de la flexibilidad. Con esta se pretendegarantizar el ajuste del sistema a las diferentes estructuras organizacionales. Solo un sólidoacoplamiento de la solución ha de garantizar el éxito para el trabajo de captura y estudio deroles de usuarios relacionados a los procesos de gestión de reportes.3.3 Prueba de la SoluciónEl sistema desarrollado fue implantado a modo de prueba en los departamentos de economía yrecursos humanos de empresas de sectores del turismo, el polo científico y del petróleo.Fundamentalmente, el mayor número de instalaciones se efectuó en unidades hoteleras de la78

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de Resultadoscadena Islazul del occidente de Cuba. Las pruebas realizadas fueron, en su mayoría, unitarias,de aceptación y regresión, durante el desarrollo del producto, enfocadas a funcionalidadesespecíficas. Finalmente, posterior a la integración de los módulos de la herramienta y paraconcluir con la primera fase de la investigación, se realizaron pruebas de integración por partede los especialistas, y de aceptación en las diferentes entidades antes mencionadas.3.3.1 Planificación de PruebasLas pruebas de regresión se vincularon con las unitarias, permitiendo corregir refinar lamodelación e implementación de procesos como la creación de fuentes de datos, la gestión deimpresión y exportación de reportes, etc. Para la realización de las pruebas finales del sistema,se utilizaron registros de entradas y posibles salidas previamente analizados para diferentessituaciones extremas. En dependencia del escenario se planificaron métodos de caja negra oblanca, y se previeron las respuestas de los módulos de la aplicación de maneraindependiente, así como el estudio de su interacción.3.3.2 Evaluación de ResultadosLa herramienta registró un funcionamiento exitoso acorde a los propósitos perseguidos en eltrabajo. Muchas de las pruebas efectuadas permitieron la corrección y el refinamiento de lasfuncionalidades para la conclusión de un producto de software acorde a los objetivos definidos.Los principales aportes que, de manera general evidencian el éxito del sistema, son: La disponibilidad de un proceso de gestión de reportes automatizado y altamentepersonalizado que garantizó la consideración de las diferentes formas en que un usuariopuede interactuar con tal área acorde a la organización en la que trabaja y los objetivosde su puesto laboral. La presencia de un mecanismo de validación que permitió mantener el sentido lógico dela estructura del sistema y los objetivos perseguidos con el mismo, controlando suflexibilidad sin tornarlo rígido acorde a las necesidades de los usuarios. La sugerencia de jerarquías de roles de usuarios variables en función de los diferentesnegocios, para el estudio de la interacción de los usuarios con los procesos de reportes. El tratamiento positivo de la flexibilidad y la usabilidad, a pesar de las posibles ytradicionales contradicciones entre estos requerimientos, en función del estudio de ladisminución del tiempo de desarrollo de herramientas informáticas, su mayor aceptación yel aumento de la satisfacción y el protagonismo de los usuarios ante las aplicaciones.79

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de Resultados La capacidad lograda de ofrecer diferentes respuestas en cuestión de la apariencia delsistema acorde a las necesidades de cada usuario.De manera concreta, los aportes antes listados se consideran respaldados por los siguientessucesos: En las instalaciones realizadas, el 100% de los usuarios se mostró satisfecho con lasfuncionalidades de la herramienta. Muchos usuarios se sintieron motivados a debatir sobre la investigación y aportaronconsideraciones razonables y críticas certeras al sistema que permitieron la optimizaciónde algunas de sus funcionalidades. Entre las principales recomendaciones efectuadas seencontraron:Mayormente por parte de los especialistas informáticos, la restricción de la diversidadde los formatos de ficheros para exportar los reportes en dependencia del rol delusuario que efectuara tal operación.Por parte de la mayoría de los directivos, la inclusión de opciones de representaciónde la estructura del negocio empresarial que sirvan de referencia para la gestión deroles de usuarios en la herramienta. Se registró que las pruebas parciales del producto permitieron el perfeccionamiento del30% de las funcionalidades de la herramienta. De las diez empresas donde se realizara un trabajo más exhaustivo en la prueba de laherramienta, nueve sugirieron el uso del sistema más allá de los departamentos deeconomía y recursos humanos.3.4 Descripción del Impacto de la HerramientaSe considera que el sistema ha incidido positivamente por garantizar los cambios en laestructura de los reportes y distribuir a los mismos por las diferentes opciones de menús parasu ejecución. El establecimiento de diferencias en los niveles de usuarios, las acciones queestos desarrollan y la inclusión de funcionalidades que ofrecen resultados que posibilitanestudiar las operaciones que han efectuado con la aplicación, han permitido que usuarios dediferentes roles se encuentren satisfechos con la solución y ha motivado el pensamiento demuchos llegando a facilitar la captación de opiniones e ideas interesantes para futurasinvestigaciones en el área.80

CAPÍTULO III. Detalles de Implementación, Prueba y Evaluación de ResultadosAlgunos eventos que evidencian la aceptación del producto más allá de los usuarios queutilizaron el sistema, son: El resto de los clientes más activos del sistema GREHU pertenecientes a los sectores delas empresas donde se probara la herramienta, solicitaron también la consideración desus empresas para la instalación. Muchos trabajadores que no utilizan sistemas de gestión de información se manifestarondeseosos de participar en el proyecto de prueba.Seguidamente se exponen las consideraciones realizadas por los usuarios que se consideranmás relevantes para la continuidad de la investigación: La conveniencia de ofrecer gráficos que muestren la evolución de la jerarquía de roles enla organización a usuarios que posean privilegios para alterarla. La inyección de los reportes realizados en las herramientas de gestión que se esténutilizando en la entidad empresarial.3.5 ConclusionesEn este capítulo se expusieron detalles de la realización del sistema. A partir de su estructurase presentaron, de manera detallada, algunos aspectos relacionados a la implementación desus principales módulos, y mediante el uso de diagramas y demás artefactos, se representó elproceso de materialización de la solución.Aspectos de importancia crítica como las consideraciones de interfaz, la definición derequerimientos no funcionales y el diseño y argumentación del mecanismo de acceso a datosempleado, fueron expuestos con el apoyo de ilustraciones. También se describió la forma enque se realizaron las pruebas planificadas, bajo qué condiciones se efectuaron y los criterios yvaloraciones sobre los resultados obtenidos. Para concluir se efectuó un análisis crítico delimpacto del sistema haciendo énfasis en las dudas surgidas y la incentivación del pensamientoprofesional para la continuidad de la investigación.81

CONCLUSIONESEn el presente trabajo se desarrolló una herramienta destinada a la gestión de reportes demanera dinámica y personalizada, incluyendo la gestión de los roles de usuarios queinteractúen con los procesos vinculados y la distribución de los accesos a los reportesdesarrollados, por diferentes sitios dentro del sistema. La aplicación implementada incluyefuncionalidades calificadas como críticas, capturadas en el estudio del estado del arte de lossistemas relacionados al campo de acción. También, el proceso de concepción de reportes sediseñó e implementó de manera flexible, logrando que responda a una estructura capaz devariar en dependencia de la clase de usuario que utilice la herramienta.Como tecnología y lenguaje de programación, se seleccionó Java, por sus bondades y lasoberanía de muchas de sus herramientas. El uso de este lenguaje permitió la obtención deuna aplicación flexible y portable, habilitando la incorporación de bibliotecas que facilitaron, enmuchas ocasiones, la implementación de múltiples funcionalidades. Algunas de lasherramientas utilizadas pertenecientes al conjunto JDK fueron: para el control de la seguridad yla gestión de usuarios, el JAAS, y para la manipulación minuciosa de documentos XML, JAXP.El formato seleccionado para las plantillas de los reportes fue XML, el cual responde alesquema establecido por JasperReports en sus ficheros “.jrxml”. Esta selección garantiza laextensibilidad de las plantillas de reportes concebidas y el trabajo de manera flexibleincorporando las ventajas que reporta el uso de los productos de JasperCorporation,particularmente su potente biblioteca de reportes JasperReports y su asistente gráfico jReport,ambos desarrollados sobre el lenguaje de programación Java.Otras de las ventajas obtenidas con el estudio y desarrollo de la solución, fue una interfaz deusuario intuitiva y flexible, capaz de ajustarse para un uso eficiente de la herramienta por partede los usuarios, en dependencia de sus necesidades. De manera general, en las pruebasrealizadas, se apreció un aumento del protagonismo por parte de los usuarios frente al sistema,al permitírseles a estos incidir razonablemente ante la estructura de la aplicación.82

RECOMENDACIONESPara un mayor aprovechamiento del sistema implementado en la investigación en curso, serecomienda analizar detalladamente las diferentes jerarquías de roles de usuarios relacionadosa los procesos de gestión de reportes obtenidas en las diferentes organizaciones donde seutilizó la herramienta. Es importante estudiar la estructuras de estas jerarquías, validarlas ycriticarlas en correspondencia a los negocios donde se presentaron, con el fin de oficializaraspectos sobre la gestión de roles de usuarios en sistemas donde la gestión personalizada decomponentes de interfaz, como los reportes, juegan un papel protagónico.También se recomienda utilizar la herramienta implementada durante períodos de tiempo másprolongados y en una mayor variedad de escenarios, incorporando situaciones extremas, conel fin de recolectar resultados como evidencia, que brinden mayor peso a las decisionestomadas al definir u oficializar aspectos, metodologías, u otras clases de acciones que sepretendan realizar entre los pasos finales de la investigación.83

REFERENCIAS BIBLIOGRÁFICAS[1]. Aoyama, Mikio. “Persona-and-Scenario Based Requirements Engineering for SoftwareEmbedded in Digital Consumer Products”. 13th IEEE International Conference onRequirements Engineering, 2005.[2]. Aoyama, Mikio. “Persona-Scenario-Goal Methodology for User-Centered RequirementsEngineering”. 15th IEEE International Requirements Engineering Conference, 2007.[3]. Barkdull, Steven. Pentaho Reporting XML Definition formats. Pentaho ReportingDocumentation – Latest. 22 de Octubre del 2007.[4]. Beck, Kent. “Extreme Programming Explained: Embrace Change”. Addison-Wesley 1999,ISBN: 0-201-61641-6.[5]. Bisbé York, Ana María. “La tabla FRX”. Kansas, Agosto del 2004. [En línea]. [Consultado: 22/12/05][6]. Business Objects. “Crystal Reports XI. Feature Comparison by Version and Edition”. Enerodel 2008. [En línea].[Consultado: 19/12/08][7]. Business Objects. “Novedades en Crystal Reports XI”. [En línea]. [Consultado: 28/09/05][8]. “Business Objects refuerza su oferta destinada a la mediana empresa”. [En línea]. Madrid,18 de Marzo del 2005. [En línea]. [Consultado:27/05/05][9]. Caballero, Ismael; Blanco, Miguel A; Piattini, Mario. “Optimización del Proceso de Gestiónde Información para la Mejora de la Calidad de la Información”. Escuela Superior deInformática UCLM, Ciudad Real, España. [En línea]. [Consultado:08/01/10]84

REFERENCIAS BIBLIOGRÁFICAS[10]. Carroll, J. M. “Scenario-based design: envisioning work and technology in systemdevelopment”. John Wiley & Sons, New York, 1995.[11]. Chiba, Shigeru. “Javassist”. 12 de Marzo del 2004. [En línea]. [Consultado: 30/11/07][12]. Chigrik, Alexander. “Microsoft SQL Server Roles”. [En línea]. [Consultado: 08/01/10][13]. Clairmont, Charly. “Intégration PHP/JasperReports”. 1 de Junio del 2007. [En línea]. [Consultado:30/11/07][14]. “Combinando Reportes en Java. JasperReports”. [En línea]. [Consultado:03/06/05][15]. Cooper, Alan; Reimann, Robert. M. “About Face 2.0: The Essentials of Interaction Design”.Wiley Publishing, 2003.[16]. Dalheimer, Kalle y Weis, Torben. “KChart. La versión 1.4.1” [En línea]. [Consultado: 30/05/05][17]. Danciu, Teodor; Chirita, Lucian. “The Definitive Guide to JasperReports”. 2007. Apress.ISBN: 978-1-59059-927-3.[18]. “Delta 6.0”. [En línea]. [Consultado:01/06/05][19]. Dev Direct. “Report Writers and Reporting Tools & Components”. [En línea]. [Consultado: 10/12/07][20]. Eckel, Bruce. “Thinking in Java”, Prentice Hall PTR. 2003. ISBN: 0-13-100287-2.[21]. Eclipse Foundation. “BIRT Report Object Model – Overview. Functional Specification”. 22de Mayo del 2005. [En línea]. [Consultado: 16/09/09][22]. ej-technologies. “jclasslib”. [En línea]. [Consultado: 08/01/10]85

REFERENCIAS BIBLIOGRÁFICAS[23]. ej-technologies GmbH, Ingo Kegel. “jclasslib bytecode viewer help”. 20 de Agosto del2003. [En línea]. [Consultado: 08/01/10][24]. Ferguson Smart, John. “Open Source Java Reporting with JasperReports and iReport”.Septiembre del 2005. [En línea]. [Consultado: 26/11/07][25]. Forno, Richard. “MS ‘Security Framework’ is another .NET vulnerability”. 14 de Noviembredel 2001. [En línea].[Consultado: 08/01/10][26]. Foundstone, Inc; CORE Security Technologies. “Security in the Microsoft .NETFramework”. [En línea]. [Consultado: 08/01/10][27]. Frazier, Robert. “Security Frameworks. An Enterprise Approach to Security”. [En línea].[Consultado: 08/01/10][28]. “Generar reportes con Rpv Printing System”. [En línea]. [Consultado: 08/09/05][29]. Gordon, B. Davis; Margrethe, H. Olson. “Management Information Systems. Conceptualfoundations, structure, and development”. McGraw-Hill, Segunda Edicion, 1985. ISBN: 0-07-015828-2.[30]. Goyal, Vikram. “Analyze your classes”. 22 de Octubre del 2003. [En línea]. [Consultado: 08/01/10][31]. Guzmán Arenas, Dr. Adolfo. “Herramientas de software para la organización distribuida”.1996. [En línea]. [Consultado: 25/05/05][32]. Heffelfinger, David R. “Getting Started With JasperReports”. Septiembre del 2005. [Enlínea]. [Consultado:05/12/07][33]. Heffelfinger, David R. “JasperReports for Java Developers”. Packt Publishing, 2006. ISBN:1-904811-90-6.86

REFERENCIAS BIBLIOGRÁFICAS[34]. Hilzinger, Marcel. “Una ayuda la oficina”. [En línea]. [Consultado: 27/05/05][35]. Hofmann, H.F; Lehner, F. “Requirements engineering as a success factor in softwareprojects”. IEEE Software. Agosto del 2001.[36]. Infante G, Lic. Sonia. “Propuesta de una nueva versión del sistema automatizado deactivos fijos tangibles para el sector de salud cubano”. [En línea]. [Consultado: 16/01/06][37]. InSoft Ltda. “Software especializado en contabilidad de costos y gestión para Pymes”. [Enlínea]. [Consultado: 30/05/05][38]. Interface21, Inc. “Spring Security 2.0.0 Released”. 15 de Abril del 2008. [En línea]. [Consultado: 10/01/10][39]. Jacobson, Ivar; Booch, Grady; Rumbaugh, James. “El Proceso Unificado de Desarrollo deSoftware”. 2000. Addison Wesley. ISBN: 81-7829-031x2.[40]. Jaspersoft Corporation. “Jaspersoft Business Intelligence Suite”. 2008. [En línea].[Consultado: 12/06/08][41]. Jaspersoft Corporation. “JasperStudio, powered by iReport”. [En línea]. [Consultado: 29/11/07][42]. Java-Source.net. “BCEL”. [En línea]. [Consultado: 08/10/09][43]. “Java Open Source reporting frameworks. Evaluation results”. 24 de Enero del 2007. [Enlínea]. [Consultado: 08/01/10][44]. “Java Security Frameworks”. [En línea]. [Consultado: 08/01/10][45]. “JFreeReport”. [En línea]. [Consultado: 25/11/07][46]. “JFreeReport joined Pentaho”. [En línea]. [Consultado: 27/11/07]87

REFERENCIAS BIBLIOGRÁFICAS[47]. Jorgensen, M; Molokken, K. “How large are software cost overruns?”. Critical Commentson the Standish Group’s CHAOS Reports. Information and Software Technology. 2006.[48]. Lafortune, Eric. “ProGuard”. [En línea]. [Consultado:28/06/09][49]. Landrum, Rodney; McGehee, Shawn; Voytek III, Walter J. “Pro SQL Server 2008Reporting Services”. Apress. 2008. ISBN: 978-1-4302-0652-1.[50]. LISI/ENSMA. “PLIB API. User Manual”. [En línea]. [Consultado: 10/01/10][51]. LISI/ENSMA. “PLIBEditor Manual”. Futuroscope, Francia. 2001. [En línea]. [Consultado: 10/01/10][52]. Martínez Rodríguez, Dr. Raúl; Achang García Ing. Julio. “Aspectos Generales delGREHU”. Cuidad de la Habana. Cuba. 2003.[53]. Martínez Rodríguez, Dr. Raúl; Pérez Gort, Ing. Maikel Lázaro. “Sistema para Gestionar deforma Integral el Capital Humano de Entidades Laborales”. Fórum de Ciencia y TécnicaProvincial, Ciudad de la Habana, Cuba, Octubre del 2008.[54]. Martínez Rodríguez, Raúl; Pérez Gort, Maikel Lázaro; Alcaide Rodríguez, Iliana. “SistemaInformativo para Gestionar de forma Integral el Capital Humano de Entidades Laborales”.III Taller de Informática Aplicada, Simposio de Ingeniería Industrial Informática y Afines,XIV Convención Científica de Ingeniería y Arquitectura, CUJAE, Ciudad de la Habana,Cuba, Diciembre de 2008. ISBN: 978-959-261-281-5.[55]. Mathematical Systems, Inc. “XML REPORTING”. [En línea]. [Consultado: 11/01/10][56]. Microsoft Corporation. “Model Designer Object Relationship Diagram”. SQL Server 2008Books Online. Agosto del 2009. [En línea]. [Consultado: 10/01/10][57]. Microsoft Corporation. “Report Definition Language Reference”. SQL Server 2008 BooksOnline. Noviembre del 2009. [En línea]. [Consultado: 10/01/10][58]. Microsoft Corporation. “Report Definition Language Specification”. Segunda Versión.Noviembre del 2005.88

REFERENCIAS BIBLIOGRÁFICAS[59]. Moreno, Carlos Miguel. “¿Que es moReport?”. [En línea] [Consultado: 01/06/05][60]. Nummenmaa, Jyrki; Zhang, Zheying; Thanisch, Peter; Pérez Gort, Maikel L. “A PersonaMethod Adaptation for Requirements Engineering in Business Intelligence Reporting”.Information Technologies 2009 (IT 2009), 15 th International Conference on Informationand Software Technologies, Abril del 2009, Kaunas, Lithuania.[61]. Object Refinery Limited. “Welcome To JFreeChart!”. [En línea]. [Consultado: 24/11/07][62]. Odell, J; Van Dyke Parunak, H; Bauer, B. “Extending UML for Agents”, Proceedings of theAgent-Oriented Information System Workshop at the 17 th National Conference on ArtificialIntelligence. Austin, USA, Julio del 2000. [En línea]. [Consultado: 10/01/10][63]. OWASP Foundation. “OWASP Enterprise Security API”. [En línea]. [Consultado: 10/01/10][64]. Pentaho Corporation. “About Pentaho Corporation. The commercial open sourcealternative for business intelligence (BI)”. [En línea]. [Consultado: 20/11/07][65]. Pentaho Corporation. “JDKTM 6 Documentation”. [En línea]. [Consultado: 25/10/07][66]. Pentaho Corporation. “Pentaho BI Platform”. [En línea]. [Consultado: 05/10/07][67]. Pentaho Corporation. “Pentaho Projects”. [En línea]. [Consultado: 21/11/07][68]. Pentaho Corporation. “Pentaho Reporting”. [En línea]. [Consultado: 21/11/07][69]. Pentaho Corporation. “Pentaho Reporting”. [En línea]. [Consultado: 15/12/07][70]. Pérez Gort, Maikel L. “Automatización de la Gestión Personalizada de ReportesInformáticos”. Ciudad de la Habana, Cuba. Instituto Superior Politécnico José AntonioEcheverría, Facultad de Ingeniería Informática, Enero del 2008. Tesina de Diplomado(Informática Aplicada).89

REFERENCIAS BIBLIOGRÁFICAS[71]. Pérez Gort, Maikel L. “Subsistema Generador de Reportes”. Ciudad de la Habana, Cuba.Instituto Superior Politécnico José Antonio Echeverría, Facultad de Ingeniería Industrial,Junio del 2006. Tesis de Diploma (Ingeniería Informática).[72]. Pérez Gort, Maikel L. “Subsistema Generador de Reportes del Sistema GREHU”. XIIConvención Científica de Ingeniería y Arquitectura, CUJAE. Ciudad de la Habana, Cuba.2006. ISBN: 959-261-248-X.[73]. Pérez Gort, Maikel Lázaro; Martínez Rodríguez, Raúl. “Subsistema Generador deReportes para el sistema GREHU”. Fórum de Ciencia y Técnica Municipal, Marianao,Ciudad de la Habana, Cuba. Septiembre del 2008.[74]. Pruitt, J; Grudin, J. “Personas: Practice and Theory”. Proceedings of DUX03: Designing forUser Experiences. 2003.[75]. “QReport Borland Delphi”. [En línea]. [Consultado: 12/05/05][76]. Rambla, Jordi. “Microsoft SQL Server 2005. Creating, Editing, and Managing Reportmodels for Reporting Services”. Enero del 2006. [En línea]. [Consultado: 10/01/10][77]. Robinson, Andy. “ReportLab – a Python reports library for direct PDF output”. [En línea].[Consultado: 15/09/07][78]. Rothman, Mike . “Frameworks, just a part of security plan”. 27 de Agosto del 2007. [Enlínea]. [Consultado: 10/01/10][79]. Rpv Software. “Rpv Business Reports 5.2”. [En línea]. [Consultado: 08/09/05][80]. Rpv Software. “Rpv Reports. La solución universal a sus problemas de impresión”. [Enlínea]. [Consultado: 08/09/05][81]. Rusty Harold, Elliotte. “XML 1.1 Bible”. 3rd Edition. Wiley Publishing, Inc. 2004. ISBN: 0-7645-4986-3.90

REFERENCIAS BIBLIOGRÁFICAS[82]. Saabas, Ando. “JBE - Java Bytecode Editor". Institute of Cybernetics. Akadeemia tee 21.12618 Tallinn. Estonia. 2006. [En línea]. [Consultado:08/01/10][83]. Sardet, Eric; Pierra, Guy; Ait-Ameur, Yamine. “Formal Specification, Modelling andExchange of Classes of Components according to PLib. A case study”. To appear in theProceedings of the Internat. Symp. on Global Engineering Networking GEN’97, SpecialSession on Intelligent Electronic Catalogues. Antwerp, Bélgica, Abril de 1997. [En línea]. [Consultado: 10/01/10][84]. Sayed, Asif. “Reporting XML data using Crystal Reports and Windows Forms”. 28 de Juniodel 2007. [En línea]. [Consultado: 10/01/10][85]. SmartSoftwareReview. “Crystal Reports Review”. [En línea]. [Consultado: 08/01/10][86]. Softpedia. “OLAP - ContourCube 3.0 está disponible”. [En línea]. [Consultado: 04/10/05][87]. SQL Software. “Queryx*Report”. [En línea]. [Consultado: 02/06/05][88]. Sun Microsystems. “Java Authentication and Authorization Service (JAAS)”. ReferenceGuide for the Java SE Development Kit 6. [En línea].[Consultado: 08/01/10][89]. Sun Microsystems. “Java SE Security”. [En línea]. [Consultado: 08/01/10][90]. Sun Microsystems. “What is the XWS-Security Framework?”. [En línea].[Consultado: 10/01/10][91]. Swenson, Erik. “Reports made easy with JasperReports”. The open source JasperReportsuses XML templates for your reporting needs”. 20 de Septiembre del 2002. [En línea].91

REFERENCIAS BIBLIOGRÁFICAS[Consultado: 10/01/10][92]. Thanisch, Peter; Nummenmaa, Jyrki; Zhang, Zheying; Pérez Gort, Maikel L. “Temas deInvestigación en el Área de Reportes de la Inteligencia de Negocios”. III Taller deInformática Aplicada, Simposio de Ingeniería Industrial Informática y Afines, XIVConvención Científica de Ingeniería y Arquitectura, CUJAE. Ciudad de la Habana, Cuba.Diciembre del 2008. ISBN: 978-959-261-281-5.[93]. The Ablaze Group. “Crystal Reports 2008: The Complete Reference”. [En línea]. [Consultado: 08/01/10][94]. The Ablaze Group. “Crystal Reports XI: The Complete Reference”. [En línea]. [Consultado: 08/01/10][95]. van Lamsweerde, Axel. “Goal-Oriented Requirements Engineering: A Guided Tour”. 5thIEEE International Symposium on Requirements Engineering. Toronto. Agosto del 2001.[96]. von Halle, Barbara. “Business Rules Applied-Business Better Systems Using the BusinessRules Approach”. John Wiley & Sons. New York. 2001. ISBN: 978-0-471-41293-9.[97]. W3C. “Extensible Markup Language (XML)”. [En línea]. [Consultado: 07/11/07][98]. Whittaker, B. “What went wrong? Unsuccessful information technology projects”. KPMG,MCB University Press, Information Management & Computer Security. 1999.92

BIBLIOGRAFÍA1. Atwood, M; Hewett, T. “A Cognitive Approach to Interactive System Design”. Conference onHuman Factors in Computing Systems. CHI’02. ACM. Minnesota, USA, 2002.2. Baecker, R. “Frontiers of User Support: Bridging the Gap Between What Users Know andWhat They Need to Know”. Conference on Human Factors in Computing Systems. CHI’02.ACM. Minnesota, USA, 2002.3. BCEL. The Apache Jakarta Project. 3 de Junio del 2006. [En línea]. [Consultado: 08/01/10]4. Bisbé York, Ana María. “Mejoras en Agrupación de datos”. Kansas. Agosto del 2004. [Enlínea]. [Consultado: 18/05/05]5. Bisbé York, Ana María. “Múltiples bandas de detalle (Multiple-Detail Bands)”. Kansas.Agosto del 2004. [En línea]. [Consultado: 18/05/05]6. Bischof, Brian. “SQL Server Reporting Services and Crystal Reports:A Competitive Analysis”. [En línea].[Consultado: 14/09/07]7. Butler, Keith A.; Jacob, Robert J. K.; John, Bonnie E. “Human-Computer Interaction:Introduction and Overview”. Conference on Human Factors in Computing Systems, CHI’99.ACM. Pittsburgh, Pennsylvania. 1999. ISBN:1-58113-158-5.8. Chi, E.; Stuart, C. “Information Visualization and Visual Perception”. ACM SIGCHI. 2002.ISSN: 0736-6906.9. Chiba, Shigeru; Nishizawa, Muga. An Easy-to-Use Toolkit for Efficient Java BytecodeTranslators. Proc. of 2nd Int'l Conf. on Generative Programming and ComponentEngineering (GPCE '03), LNCS 2830, pp.364-376, Springer-Verlag, 2003. [En línea]. [Consultado: 08/01/10]93

BIBLIOGRAFÍA10. Chiba, Shigeru. “Load-time Structural Reflection in Java”. ECOOP 2000. Object OrientedProgramming. LNCS 1850. Springer Verlag. 2000. [En línea]. [Consultado: 08/01/10]11. Constantine, Larry. “PREPRINT. Users, Roles, and Personas”. IDSA. Constantine &Lockwood, Ltd.12. D Vint Productions. “XML Schema – Data Types Quick Reference”. D VintProductions. 2003. [En línea]. [Consultado:11/01/10]13. Dillion, A. “A Primer on Test Design and Statistics for Usability Evaluation”. ACM SIGCHI.Romania. 2002.14. Dray, S. “Understanding User’s Work in Context: Practical Observation Skills”. ACMSIGCHI. 2002. SSN: 0736-6906.15. Ducan Davidson, James; Hunter, Jason. “Java TM API for XML Processing 1.1”. [En línea]. [Consultado:15/11/07]16. Goodwin, K. “Goal-Directed Methods for Great Design”. Conference on Human Factors inComputing Systems. CHI’02. ACM. Minnesota, USA, 2002.17. Google Enterprise EMEA. “GSA Valve Security Framework – Scenarios”. Scenario Guide.[En línea]. [Consultado: 08/01/10]18. Gropp, Eric. “REST Reporting”. 16 de Febrero del 2005. [En línea]. [Consultado: 12/01/10]19. Hackos, JoAnn T.; Redish, Janice C. “User and Task Analysis for Interface Design”. JohnWiley & Sons, Inc. 1998. ISBN: 0-471-17831-4.20. Interactive Reporting. “Interactive Reporting. Overview”. White Paper. Diciembre del 2004.[En línea]. [Consultado:11/01/10]21. JASYPT. “JASYPT. Java Simplified Encryption”. [En línea]. [Consultado: 08/01/10]94

BIBLIOGRAFÍA22. Java4Less. “RReport & RReport Visual Builder 2.6: Java[TM] platform printing library andweb reports”. [En línea]. [Consultado:15/11/07]23. JavaBlackBelt. “JasperReports TechMap. JavaBlackBelt”. [En línea]. [Consultado: 08/01/10]24. Jenson, S. “The Simplicity Shift: Making Innovative Design Work”. ACM SIGCHI. Romania.2002.25. John, Bonnie E.; Bass, Len. “Avoiding We Can’t Change That!: Software Architecture &Usability”. Conference on Human Factors in Computing Systems. CHI’02. ACM. Minnesota,USA, 2002.26. Johnson, J. “GUI Bloopers: Recognizing and Avoiding Common GUI Design Mistakes”.Conference on Human Factors in Computing Systems. CHI’02. ACM. Minnesota, USA,2002.27. Mayhew, D. “Promoting, Establishing, and Institutionalizing Usability Engineering”.Conference on Human Factors in Computing Systems. CHI’02. ACM. Minnesota, USA,2002.28. Mayhew, D. “The Usability Engineering Lifecycle”. Conference on Human Factors inComputing Systems. CHI’02. ACM. Minnesota, USA, 2002.29. McLaughlin, Brett D. “All about JAXP, Part 1”. 17 de Mayo del 2005. [En línea]. [Consultado: 05/12/07]30. Microsoft Corporation. “MS-RDL: Report Definition Language File Format StructureSpecification”. [En línea]. [Consultado: 11/01/10]31. Microsoft Corporation. “Report Definition Chart Overview Diagram”. SQL Server 2008 BooksOnline. Agosto del 2009. [En línea]. [Consultado: 08/01/10]32. Microsoft Corporation. “Report Definition Custom Report Item Overview Diagram”. SQLServer 2008 Books Online. Agosto del 2009. [En línea]. [Consultado: 08/01/10]95

BIBLIOGRAFÍA33. Microsoft Corporation. “Report Definition Language XML Schema”. SQL Server 2008 BooksOnline. Agosto del 2009. [En línea]. [Consultado: 08/01/10]34. Microsoft Corporation. “Report Definition Report Data Overview Diagram”. SQL Server 2008Books Online. Agosto del 2009. [En línea]. [Consultado: 08/01/10]35. Microsoft Corporation. “Report Definition Report Layout Overview Diagram”. SQL Server2008 Books Online. Agosto del 2009. [En línea]. [Consultado: 08/01/10]36. Microsoft Corporation. “Report Definition XML Diagrams”. SQL Server 2008 Books Online.Agosto del 2009. [En línea]. [Consultado: 11/01/10]37. Microsoft Corporation. “Visual FoxPro 8.0. Checking for Differences in Forms, Reports, andOther Table Files”. [En línea]. [Consultado: 11/01/10]38. NetCat Inc. “Java Report Printing SDK Library - ReportCat 1.1”. [En línea]. [Consultado: 14/11/07]39. NetCat Inc. “ReportCat - The Java Report Print SDK Library”. [En línea]. [Consultado: 12/11/07]40. Pérez Gort, Maikel L. “Diseño e Implementación de un Generador de Reportes utilizandoficheros DBF y FoxPro 2.6 para Windows”. Reporte de Investigaciones del CEIS. Ciudad dela Habana. Cuba. 2007. ISBN: 978-959-261-2662.41. Richardson, W. Clay; Avondolio, Donald; Schrager, Scot; Mitchell, Mark W.; Scanlon, Jeff.“Professional Java, JDK 6 Edition”. Wiley Publishing, Inc. 2007. ISBN: 978-0-471-77710-6.42. Rosson, M.B.; Carroll, J. “Scenario-Based Usability Engineering”. Conference on HumanFactors in Computing Systems. CHI’02. ACM. Minnesota, USA, 2002.43. Rumbaugh, James; Jacobson, Ivar; Booch, Grady. “The Unified Modeling LanguageReference Manual”. 1999. Addison Wesley. ISBN: 0-201-30998-X.44. Sosnoski, Dennis M. Java programming dynamics, Part 4: Class transformation withJavassist. IBM developerWorks, 16 de Septiembre del 2003. [En línea]. [Consultado: 08/01/10]96

BIBLIOGRAFÍA45. Sosnoski, Dennis M. Java programming dynamics, Part 7: Bytecode engineering with BCEL.15 de Abril del 2004. [En línea]. [Consultado: 08/01/10]46. Sun Microsystems. “Java API for XML Processing”. [En línea]. [Consultado: 05/12/07]47. Tatsubori, Michiaki; Sasaki, Toshiyuki; Chiba, Shigeru; Itano, Kozo. A Bytecode Translatorfor Distributed Execution of "Legacy" Java Software. ECOOP 2001 -- Object-OrientedProgramming, LNCS 2072, Springer Verlag, pp.236-255, 2001. [En línea]. [Consultado: 08/01/10]48. TEC-IT. “INFORMer, Report Generator for Software Developers”. [En línea]. [Consultado:12/01/10]49. TEC-IT “Professional Label/Form Printing and Reporting”. [En línea]. [Consultado: 20/11/07].50. TEC- IT. “TFORMer. Barcode Label Printing and Reporting Software. Version 6.0”. WhitePaper. GmbH. Austria. 6 de Agosto del 2009. [En línea]. [Consultado: 08/01/10]51. The Ablaze Group. “The Most Definitive Resources on Crystal Reports Available!”. [Enlínea]. [Consultado: 11/01/10]52. Tiffoli, Giulio. “The Definitive Guide to iReport”. 2007. APRESS. ISBN: 978-1-59059-928-053. Vanderheiden, G.; Henry, S.L. “Flexible, Accessible Interfaces More Usable by Everyone”.Conference on Human Factors in Computing Systems. CHI’02. ACM. Minnesota, USA,2002.54. Vredenburg, K.; Isensee, S.; Righi, C. “How to Introduce, Deploy, and Optimize User-Centered Design in Your Organization”. UPA’01. Usability Professionals' Association. 2001.55. Yankelovich, Nicole; Lai, Jennifer. “Designing Speech User Interfaces”. Conference onHuman Factors in Computing Systems. CHI 98. Los Angeles, California, United States.1998. ISBN: 1-58113-028-7.97

GLOSARIO DE SIGLAS Y TÉRMINOSAPI (Application Programming Interface): Interfaz de Programación de Aplicaciones.Conjunto de métodos que ofrece una biblioteca para que otros sistemas lo utilicen como unacapa de abstracción.Bibliotecas GTK: Conjunto importante de bibliotecas o rutinas que contienen objetos yfunciones para crear interfaces gráficas de usuario.Borland (Borland Software Corporation): Anteriormente Borland International, Inc. Compañíade software ubicada en Scotts Valley, California, Estados_Unidos, conocida sobre todo por suherramienta de programación Turbo Pascal que evolucionó hasta el Delphi.BPM (Bussiness Process Management): Gestión de Procesos de Negocios. Consiste en unaestrategia sistemática para mejorar los procesos de negocios de una organización. Susactividades se orientan en función de alcanzar la efectividad, eficiencia y adaptabilidad de losprocesos de negocios. Es una infraestructura de gestión que concierne al área administrativapara el mantenimiento y la optimización de la organización.Bytecode: Código intermedio más abstracto que el código máquina.DBF (DataBase File): Fichero de Base de Datos. Estructura de fichero formada por una tablade almacenamiento de datos.DTD (Document Type Definition): Definición de Tipo de Documento que contiene loselementos, atributos, entidades y notaciones a utilizar en un documento XML, así como susposibles relaciones. Además puede incluir reglas para la estructura del documento.Framework: Conjunto de clases de diseño abstracto que ofrecen herramientas para desarrollarproductos informáticos.FRX: Extensión de los ficheros de informes de las herramientas de Microsoft FoxPro.Constituyen ficheros con estructura de tablas, que almacenan información para definir losreportes en FoxPro.Hibernate: Herramienta de Mapeo objeto-relacional para la plataforma Java.98

GLOSARIO DE SIGLAS Y TÉRMINOSInteligencia de Negocio: Proceso que consiste en recopilar, analizar y utilizar datos delnegocio para mejorar el rendimiento empresarial.JAX-WS (Java API for XML Web Services): API de Java que ofrece un conjunto detecnologías para el desarrollo de servicios web con el uso de la tecnología XML.JDK (Java SE Development Kit): Conjunto de programas y bibliotecas de libre distribuciónque permiten desarrollar, compilar y ejecutar programas en Java. Existe también una versiónreducida del JDK, denominada JRE (Java Runtime Environment) destinada únicamente aejecutar código Java.JVM (Java Virtual Machine): Máquina Virtual de Java. Es un programa nativo (ejecutable enuna plataforma específica) capaz de interpretar y ejecutar instrucciones expresadas en uncódigo binario especial (Java bytecode), el cual es generado por el compilador del lenguajeJava.KChart: Generador de gráfico integrado al paquete KOffice.KDE (K Desktop Environment): Entorno de escritorio gráfico e infraestructura de desarrollopara sistemas Unix y Linux. La ‘K’ originalmente representaba la palabra “Kool”, pero susignificado fue abandonado más tarde.KOffice: Colección de programas libres para el proyecto KDE.KWord: Editor de texto integrado al paquete KOffice.Ofuscador: Herramienta que transforma el bytecode a otra clase de bytecode más difícil dedescompilar.PDF (Portable Document Format): Formato de Documento Portátil. Es un formato dealmacenamiento de documentos desarrollado por la empresa Adobe Systems.PostScript: Lenguaje de Descripción de Página (en inglés PDL, Page Description Language),utilizado en muchas impresoras y como formato de transporte de archivos gráficos en talleresde impresión profesional.99

GLOSARIO DE SIGLAS Y TÉRMINOSPSG (Persona-Scenario-Goal): Metodología que extiende de la Metodología Persona –Escenario (PS) y está centrada en el estudio de los requerimientos de los usuarios en supuesto laborar según los objetivos a cumplir.RDL (Report Definition Language): Representación XML de la definición de los reportesutilizados en los servicios de reportes de SQL Server. Contiene información sobre la exposiciónde los datos y la estructura del reporte. Está compuesto por documentos XML que estandarizanla gramática creada para los servicios de reportes de SQL Server.RUP (Rational Unified Process): Proceso Unificado de Desarrollo. Modelo de proceso dedesarrollo de software que utiliza el lenguaje UML para preparar todos los esquemas de unsistema de software. Se distingue por promover un desarrollo dirigido por casos de uso,centrado en la arquitectura y de manera iterativa e incremental.SAAJ (SOAP with Attachments API for Java): API de SOAP con Adjuntos para Java quesuministra una manera estándar de enviar documentos XLM sobre Internet desde la plataformaJava. SAAJ permite a los desarrolladores producir y consumir mensajes uqe complan con lasespecificaciones de SOAP. Suele utilizarse también para desarrollar aplicaciones demensajería.SGBD (Sistema de Gestión de Bases de Datos): Sistema que permite a los usuariospreservar, recuperar y modificar información digital.SMDL: Especificación XML que define los elementos válidos del modelo de un reportealmacenado en un fichero de extensión ‘smdl’. Además especifica las relaciones entre objetossemánticos y de vistas de fuentes de datos pertenecientes al modelo.Stand-Alone: Independiente. Separado de un conjunto. Autónomo. Caracteriza a un terminal oun puesto de trabajo que está conectado directamente al ordenador o que tiene una solaconexión a través de una línea externa.SysML (systems Modeling Language): Lenguaje de modelado gráfico de propósito generalque consiste en un subconjunto de UML 2.0 con extensiones requeridas para modelar losrequerimientos, el comportamiento y la estructura de sistemas complejos que pueden estarformados por software, hardware, información, personal, procedimientos y medios. Es utilizadode manera integrada con otros modelos de ingeniería de análisis de sistemas.100

GLOSARIO DE SIGLAS Y TÉRMINOSUML (Unified Modeling Language): Lenguaje Unificado de Modelado para propósito generalformado por un conjunto de notaciones y diagramas estándares utilizado para el modelado deproyectos o sistemas complejos orientados a objetos.Unicode: Codificación estandarizada de caracteres de la industria de la computación quepermite a las computadoras representar y manipular texto en la mayoría de los idiomas delmundo.URL (Uniform Resource Locator): Dirección Global de Documentos. Es una secuencia decaracteres de formato estándar utilizada para localizar recursos, como documentos eimágenes, en Internet.XML (Extensible Markup Language): Lenguaje de Marcas Extensible. Es un Metalenguajeestandarizado por el W3C para formatear datos, en otras palabras, un lenguaje de metamarcado que ofrece un formato para la descripción de datos estructurados. Es una formaflexible de crear formatos de información y compartir tanto el formato como los datos enInternet y otras redes.W3C (World Wide Web Consortium): Consorcio internacional que encabeza y rige las normasy estándares definidos en pos de una mayor interoperabilidad e intercambio a través de Internety la Web en general.101

ANEXOSAnexo 1. Existencia numerosa de herramientas para reportes [19] .PropietarioHerramientas- Report Sharp-Shooter 3.6- Report Sharp-Shooter 3.7- Report Sharp-Shooter Express 3.5- IntelliVIEW Designer 3.6.2- IntelliVIEW Report Analyzer 3.6.2- IntelliVIEW suite 3.6.2- Telerik Reporting Q2 2007- Xtreme ReportControl 2007 Vol 2- SpreadsheetGear for .NET 2007 V3.1- Aspose.BarCode for Reporting Services V1.1- Aspose.Cells for .NET V4.4- Aspose.Cells for Reporting Services 1.0.0.0- Aspose.Pdf for Reporting Services V1.0- Aspose.Slides for Reporting Services 1.0.0.0- Aspose.Words for .NET V4.4.2- Aspose.Words for Reporting Services V2.0.1.0- TextDynamic V1.38- WPTools V5.35.1- WPTools V5.22- Izenda Ad Hoc V5.0- ActiveReports V2.4.1- ActiveReports for .NET 3.0 V5.2.3.068- Data Dynamics Reports 1.0.33.0I

ANEXOS- XtraPivotGrid Suite 2007.2.4- XtraReports Suite 2007.3.5- Essential Grouping 2008 Vol 1- CrossCompass Query and Reporting 3.9- DynamicPDF Generator for COM/ActiveX V4.0- DynamicPDF Generator Classic V2.6b- DynamicPDF Generator for .NET V4.0.3- DynamicPDF Generator for Java V4.0.3- DynamicPDF Merger for .NET V4.0.3- DynamicPDF Merger for Java V4.0.3- DynamicPDF ReportWriter V1.6- dbQwikReport V1.1- DBxtra 2005 SP1- Report Miner V4.0.10- eDocEngine VCL V2.5- StimulReport.Net 2007.2- Stimulsoft Reports.Net 2007.3- Visual Reports V2.2- Visual Reports for .NET 1.0- CRChart V3.1Three D Graphics, Inc.- GemBox.Spreadsheet V2.9II

ANEXOS- RReport Visual Builder (Java Edition) 2.6- Flexcel Studio for .NET V4.0.0.3- PrintForm for .NET V2.1.0.10Elixir Technology - Elixir Dashboard 7.1.2- Elixir Repertoire 7.1.2- Elixir Report 7.1.2Software Forces, LLC - .rpt Inspector Enterprise Suite V3.1- .rpt Inspector Professional Suite V3.0LogiXML- LGX Ad Hoc Report Builder V8.2.12Epsilon Logic Systems, Inc. - ELS-Script® Web Report Tool V3.0Anexo 2. Novedades de Reportes de Pentaho [68] .III

ANEXOSAnexo 3. Formato Genérico de una Plantilla de Reporte.Banda de Título del ReporteBanda de Encabezamiento de PáginaBandas de Encabezamiento de GrupoBandas de Encabezamiento de ColumnasBanda de DetalleBanda de ResumenBandas Pie de ColumnasBandas de Pie de GrupoBanda de Pie de PáginaBanda del Pie del ReporteIV

ANEXOSAnexo 4. Reporte Informático definido con criterios de Agrupamiento.V

ANEXOSAnexo 5. Reporte Informático con inclusión de Gráficos.VI

ANEXOSAnexo 6. Variada Atención de Pentaho al Área de los Reportes [68] .Anexo 7. Planillas de Encuestas para Clientes de Sistemas de Reportes.VII

ANEXOSVIII

ANEXOSIX

ANEXOSAnexo 8. Relación entre Objetos del Diseñador de Reportes del SQL Server [56] .Ficheros que componen el modelo de un reporteObjetos semánticos del modelo de un reporteX

ANEXOSObjetos semánticos y objetos de vistas de fuentes de datos (DSV)Objetos de expresión del modelo de reportesObjetos de consultas del modelo del reporteXI

ANEXOSXII

ANEXOSAnexo 9. Relación entre Objetos en el RDL para Reportes de SQL Server [57] .Definición del diseño del reporteElementos de datos de tablas del reporteXIII

ANEXOSElementos de tablas del reporteXIV

ANEXOSElementos de gráficos del reporteXV

ANEXOSOtros elementos del reporteXVI

ANEXOSElementos de datos del reporteXVII

ANEXOSAnexo 10. Comparación de Frameworks de Reportes de Código Abierto [43] .Framework BIRT Jasper PentahoVersion 2.1.0 1.2.6 1.2.RC1Report DesignerWYSIWYG editor Yes Yes YesFat clientEclipse plug-in Yes Yes (JasperAssistant) YesStandalone JavaapplicationYes Yes (iReport) YesHTML client No No NoPalette Yes Yes YesData Explorer Yes Yes YesProperty Editor Yes Yes YesChart Builder Yes Yes YesReport preview Yes Yes YesScript Editor Yes Yes NoOutline Yes Yes YesExpression Builder Yes Yes YesReusabilityReport templates Yes Yes YesReport element libraries Yes Yes YesLibrary Explorer Yes Yes YesReport Items Yes No NoData Sources Yes Yes YesStyles Yes Yes YesScripts Yes No NoSub-reports Yes Yes NoCrosstab No Yes NoCompiled report definition No Yes NoParameterized reports Yes Yes YesData SourceSupported typesJDBC Yes Yes YesXML Yes Yes YesPOJO Yes Yes YesFlat file Yes No NoScripted Yes No NoXVIII

ANEXOSEJB No Yes NoHibernate No Yes YesOLAPMDXMondrian No Yes YesConnection pool supportIn designer Yes (JNDI) No Yes (JNDI)Programmatically Yes Yes YesData SetQuery builder Yes Yes YesData preview Yes Yes YesJoined Data Set Yes No NoCustomizationComputed fields Yes No NoParameterized SQLstring (any part)built-in systemparametersUser-defined contextparametersFormattingNo Yes NoNo Yes NoYes Yes NoConditional Formatting Yes No YesConditional Visibility Yes No NoValue Mapping Yes No NoHighlighting Yes No YesProject ManagementEclipse project Yes No NoEclipse CVS support Yes No NoInteractive reportsHyperlinking (in ReportDesigner)ChartsChart Types (in ReportDesigner)Yes Yes NoPie (3D) Yes, No Yes, Yes Yes(Stacked) Bar (3D) Yes, Yes, Yes Yes, Yes, Yes YesLine (3D) Yes, Yes Yes, No YesArea (3D) Yes, Yes Yes, No YesXIX

ANEXOSScatter Yes Yes NoBubble Yes Yes NoTime Series No Yes NoMeter Yes No NoStockHigh Low OpenClose/Bar-stickYes Yes NoCandle-stick Yes Yes NoInteractive charts (inReport Designer)Hyperlinking Yes Yes NoLocalizationStrings in the reportdefinitionResource bundle Yes Yes YesLocale-aware dataformattingDeploymentReport Viewer for WebapplicationReport Viewer forStandalone Java applicationLicenseReport designerReport engineSupport and developmentCommercial support anddevelopmentOnline supportactive community ofusersDocumentationTutorialYes No NoYes Yes NoEclipse PublicLicense Version 1.0("EPL").Eclipse PublicLicense Version 1.0("EPL").GPL/CommercialLGPLMozilla PublicLicenseLGPLYes (Actuate) Yes (JasperSoft) Yes (Pentaho)Yes Yes YesYes (Very goodtutorial)Yes (outdated orcommercial)Cheat Sheets Yes No NoIntegrationYesXX

ANEXOSReport DesignerStandalone JavaapplicationYes Yes YesEclipse plug-in Yes Yes YesDesign Engine API Yes No NoReport Engine API Yes Yes YesCharting Engine API Yes Yes YesReport Viewer Yes No NoPerformance No No NoExtensibilityCustom Data Accessruntime component forgetting the datacustom design-time UIfor building a custom queryYes Yes YesYes No NoCustom Report Items Yes Yes YesCustom Chart Types Yes Yes YesScriptingEvent handlingJavaScript Yes No NoJava Yes Yes NoGroovy No Yes NoExpressionsJavaScript Yes No NoJava No Yes NoGroovy No Yes NoOutput formatsHTML Yes Yes YesPaginated HTML Yes No NoPDF Yes Yes YesXLS No Yes YesCSV Yes Yes NoCustom converter Yes No NoRTF No Yes YesTXT No Yes YesXML No Yes NoXXI