aplicación web para la prevención y soporte en la ... · aplicación web para la administración,...

Aplicación web para la administración, prevención y soporte del SGP. U.C.E.

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA

CARRERA INGENIERÍA INFORMÁTICA

DISEÑO, DESARROLLO E IMPLEMENTACIÓN DE UNA APLICACIÓN

WEB PARA LA ADMINISTRACIÓN, PREVENCIÓN Y SOPORTE DEL

SISTEMA NACIONAL DE GESTIÓN DE PREVENCIÓN DE RIESGOS

LABORALES (SGP).

TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO

DE INGENIERO EN INFORMÁTICA.

AUTOR:

CHOCHOS ORTEGA DIANA ELIZABETH

TUTOR:

ING. MORALES MEJÍA CESAR AUGUSTO, MSC.

QUITO – ECUADOR

2015


ii

DEDICATORIA

Doy las gracias en primer lugar a mi amado padre Dios, que guió mis pasos

en todo momento y quien me ayudó a alcanzar una de mis metas tan

anheladas que es la culminación de mis estudios universitarios y también se

que él me acompañará siempre y en todo momento de mi vida.

En segundo lugar estoy y estaré eternamente agradecida con mis padres,

porque me apoyaron y estuvieron a mi lado siempre, brindándome amor,

seguridad y ánimos para salir adelante, que dios les bendiga y espero

también ayudarles más en lo que ellos necesiten.

Gracias a mi novio querido, quien siempre estuvo conmigo dándome ánimos

para terminar con mi proyecto de tesis y quien fue un apoyo total todo el

tiempo y estuvo pendiente de que mi meta sea alcanzada, te quiero mucho

mi amor Jhon Mena.


iii

AGRADECIMIENTO

Quedo muy agradecida con mi tutor Ing. Cesar Morales, quien supo guiarme

en el desarrollo de mi tesis con mucha paciencia y profesionalismo, también

agradezco a mis revisores por ayudarme a que sea posible mi graduación y

de esta manera lograr una meta más en mi vida.

También quiero agradecer a mi sponsor QESCONSULTORES S.A, quienes

me ayudaron a concretar finalmente mi proyecto y que sin su colaboración,

mi objetivo no hubiera sido posible.


iii

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL

Yo, DIANA ELIZABETH CHOCHOS ORTEGA en calidad de autor del trabajo

de investigación o tesis DISEÑO, DESARROLLO E IMPLEMENTACIÓN DE

UNA APLICACIÓN WEB PARA LA ADMINISTRACIÓN, PREVENCIÓN Y

SOPORTE DEL SISTEMA NACIONAL DE GESTIÓN DE PREVENCIÓN DE

RIESGOS LABORALES (SGP), por la presente autorizo a la UNIVERSIDAD

CENTRAL DEL ECUADOR, hacer uso de los contenidos que me pertenecen

o de parte de los que contiene esta obra, con fines estrictamente

académicos o de investigación.

Los derechos que como autor me corresponden, con excepción de la

presente autorización, seguirán vigentes a mi favor, de conformidad con lo

establecido en los artículos 5, 6, 8,19 y demás pertinentes de la Ley de

Propiedad Intelectual y su Reglamento.

Quito, 13 de Marzo del 2015

………………………………….

CHOCHOS ORTEGA DIANA ELIZABETH

CI. 1719258939


iv

CERTIFICACIÓN TUTORIAL


v

INFORME SOBRE LA CONCLUSIÓN


vi

NOTAS


vii

CONTENIDO

DEDICATORIA ............................................................................................... ii

AGRADECIMIENTO ...................................................................................... iii

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL ...................................... iii

CERTIFICACIÓN TUTORIAL ........................................................................ iv

INFORME SOBRE LA CONCLUSIÓN............................................................v

NOTAS ..........................................................................................................vi

CONTENIDO ................................................................................................ vii

LISTA DE TABLAS ....................................................................................... xii

LISTA DE FIGURAS .................................................................................... xiii

RESUMEN....................................................................................................xv

ABSTRACT.................................................................................................. xvi

CERTIFICADO TRADUCCIÓN DEL RESUMEN........................................ xvii

CERTIFICACIÓN DE CONOCIMIENTO EN EL IDIOMA INGLÉS............. xviii

INTRODUCCIÓN........................................................................................... 1

CAPÍTULO I ................................................................................................... 3

1 Presentación del problema .................................................................. 3

1.1 Planteamiento del problema.......................................................... 3

1.2 Formulación del problema ............................................................. 3

1.3 Interrogantes de la Investigación................................................... 4

1.4 Objetivos de la Investigación ......................................................... 4

1.4.1 Objetivo General ........................................................................ 4

1.4.2 Objetivos Específicos ................................................................. 4

1.5 Justificación ................................................................................... 5

CAPÍTULO II .................................................................................................. 7

2 Revisión Bibliográfica........................................................................... 7

2.1 Antecedentes................................................................................. 7

2.2 Fundamentación Teórica ............................................................... 8

2.2.1 Definición de empresa consultora .............................................. 8

2.2.2 Definición de riesgos y peligros laborales .................................. 8

2.2.2.1 Definición de peligro laboral.................................................... 8


viii

2.2.2.2 Definición de riesgo laboral..................................................... 8

2.2.3 Definición de ingeniería de software .......................................... 9

2.2.4 Definición de programación orientada a objetos ........................ 9

2.2.4.1 Definición de encapsulamiento ............................................... 9

2.2.4.2 Definición de herencia .......................................................... 10

2.2.4.3 Definición de polimorfismo.................................................... 10

2.2.4.3.1 Definición de sobrecarga de métodos................................... 11

2.2.4.4 Definición de abstracción ...................................................... 12

2.2.5 Definición de java ..................................................................... 12

2.2.5.1 Definición de compilación ..................................................... 13

2.2.6 Definición de JVM .................................................................... 13

2.2.7 Definición de JDK.................................................................... 13

2.2.8 Definición de JRE..................................................................... 13

2.2.9 Definición de Lenguaje Unificado de modelado (UML) ............ 14

2.2.9.1 Definición de diagrama de casos de uso .............................. 15

2.2.9.2 Definición de diagramas de actividades................................ 16

2.2.9.3 Definición de diagramas de secuencia ................................. 16

2.2.9.4 Definición de diagrama de componentes .............................. 17

2.2.9.5 Definición de diagrama de paquetes..................................... 18

2.2.9.6 Definición de diagramas de despliegue ................................ 18

2.2.9.7 Definición de diagrama de clases ......................................... 19

2.2.10 Definición de java empresarial JEE (Java Enterprise Edition).. 19

2.2.11 Definición de Arquitectura de software..................................... 19

2.2.11.1 Arquitectura de software en tres capas................................. 20

2.2.12 Definición de clase abstracta ................................................... 21

2.2.13 Definición de interface.............................................................. 22

2.2.14 Definición de Modelo Vista Controlador (MVC) ........................ 22

2.2.15 Definición de Framework.......................................................... 23

2.2.15.1 Ventajas de un framework .................................................... 23

2.2.16 Definición de java server fases (JSF)....................................... 23

2.2.16.1 Ciclo de vida JSF .................................................................. 24

2.2.17 Definición de Prime Faces y Rich Faces.................................. 25

2.2.18 Spring framework ..................................................................... 25


ix

2.2.18.1 Definición de spring .............................................................. 25

2.2.18.2 Arquitectura de spring........................................................... 25

2.2.18.3 Principales ventajas de spring .............................................. 27

2.2.19 Definición de Servidor de aplicaciones..................................... 28

2.2.20 Definición de Jboss .................................................................. 28

2.2.21 Definición de Mapeo Objeto Relacional (ORM)........................ 28

2.2.21.1 ¿Por qué usar un ORM?....................................................... 28

2.2.22 Definición de Hibernate ............................................................ 29

2.2.23 Definición de HQL .................................................................... 29

2.2.24 Definición de JPA (Java Persistence API)................................ 29

2.2.25 Definición de JavaScript........................................................... 29

2.2.26 Definición de Ajax..................................................................... 30

2.2.27 Definición de IDE Eclipse ......................................................... 30

2.2.28 Definición de PostgresSQL ...................................................... 30

2.2.29 Definición de JDBC .................................................................. 31

2.2.30 Definición de power designer ................................................... 32

2.2.31 Definición de Aplicación web.................................................... 32

2.2.31.1 Tipos de aplicaciones web .................................................... 33

2.2.31.2 Ventajas de una aplicación web............................................ 34

2.2.31.3 Definición de Wireframe (Diseño web).................................. 35

2.2.32 Definición de Proceso Unificado de Rational (RUP)................. 35

2.2.32.1 Principios de desarrollo RUP ................................................ 35

2.2.32.2 Faces de la metodología RUP. ............................................. 36

2.2.32.3 Iteraciones en las fases de RUP........................................... 37

2.3 Identificación de variables ........................................................... 38

2.3.1 Variables Independientes......................................................... 38

2.3.2 Variable Dependiente............................................................... 38

2.4 Hipótesis...................................................................................... 38

2.5 Alcance........................................................................................ 38

CAPÍTULO III ............................................................................................... 40

3 Marco Metodológico........................................................................... 40

3.1 Análisis y Diseño de la Investigación........................................... 40

3.1.1 Especificación de requisitos funcionales y no funcionales ....... 40


x

3.1.1.1 Casos de uso para la autenticación de usuarios................... 41

3.1.1.2 Casos de uso para la administración de grupos de normasjurídicas del SGP................................................................................... 41

3.1.1.3 Casos de uso para el soporte y seguimiento de casos. ........ 44

3.1.1.4 Lista de requisitos no funcionales para el desarrollo delsistema 47

3.1.2 Diseño del wireframe para el proyecto ..................................... 47

3.1.3 Comportamiento de la aplicación web...................................... 48

3.1.3.1 Diseño del diagrama de casos de uso .................................. 48

3.1.3.2 Diseño del diagrama de actividades ..................................... 53

3.1.3.3 Diseño de diagramas de secuencia ...................................... 54

3.1.4 Estructura de la aplicación web................................................ 61

3.1.4.1 Diseño del diagrama de componentes.................................. 61

3.1.4.2 Diseño del diagrama de paquetes ........................................ 62

3.1.4.3 Diseño del diagrama de despliegue...................................... 65

3.1.4.4 Diseño de diagrama de clases.............................................. 66

3.1.5 Diseño de arquitectura de capas lógicas.................................. 67

3.1.5.1 Análisis de la implementación de capa de presentación....... 67

3.1.5.2 Análisis de la implementación de la capa de negocios ......... 67

3.1.5.3 Análisis de la implementación de la capa de datos............... 68

3.1.6 ¿Por qué usar la Metodología RUP para el desarrollo de laaplicación web?..................................................................................... 68

CAPÍTULO IV............................................................................................... 69

4 Construcción del sistema ................................................................... 69

4.1 Estándares de java ......................................................................... 69

4.2 Implementación de las capas a nivel de software........................... 71

4.2.1 Implementación de la capa de modelo ........................................ 71

4.2.1.1 Implementación del bean factory en el proyecto ...................... 71

4.2.1.2 Implementación de Entity’s ...................................................... 72

4.2.1.3 Implementación de los id’s de entity’s ...................................... 75

4.2.1.4 Definición de servicios.............................................................. 75

4.2.2 Implementación de la capa lógica ............................................... 76

4.2.2.1 Implementación de los servicios .............................................. 76

4.2.2.2 Definición de los gestores ........................................................ 76


xi

4.2.2.3 Implementación de los gestores............................................... 77

4.2.2.4 Definición de beans en spring .................................................. 78

4.2.2.5 Mapeo de servicios .................................................................. 78

4.2.2.6 Mapeo de gestores................................................................... 79

4.2.2.7 Transacciones con spring ........................................................ 79

4.2.2.8 Configuración del DataSource en spring.................................. 80

4.2.2.9 Configuración del sessionFactory con spring........................... 80

4.2.2.10 Implementación del orm del proyecto....................................... 81

4.2.3 Implementación de la capa web .................................................. 81

4.2.3.1 Implementación de las paginas .xhtml ..................................... 81

4.2.3.2 Implementación de controladores ............................................ 82

CAPÍTULO V................................................................................................ 84

5 Conclusiones y recomendaciones...................................................... 84

5.1 Conclusiones .................................................................................. 84

5.2 Recomendaciones .......................................................................... 85

Marco Administrativo ................................................................................... 86

Presupuesto ............................................................................................. 86

Cronograma.............................................................................................. 87

Bibliografía................................................................................................ 90

Anexos......................................................................................................... 92

Anexo 1. Implementación del proyecto en QESCONSULTORES S.A ..... 93

Anexo 1.1 Plan de pruebas ................................................................... 93

Anexo 1.2 Acta de aceptación del proyecto .......................................... 94

Anexo 1.3 Certificación de implementación de proyecto ....................... 95

Anexo 2. Diccionario de datos .................................................................. 96


xii

LISTA DE TABLAS

Tabla 1. Posibles riesgos laborales. .............................................................. 8Tabla 2. Diferencias entre polimorfismo y sobrecarga de métodos ............. 12Tabla 3. Algunos ejemplos de componentes ............................................... 17Tabla 4. Requisitos funcionales de la empresa QESCONSULTORES S.A. 40Tabla 5. Caso de uso autenticación de usuarios ......................................... 41Tabla 6. Caso de uso consultar grupo de normas jurídicas del SGP........... 41Tabla 7. Caso de uso para la creación de grupos de normas jurídicas delSGP ............................................................................................................. 42Tabla 8. Caso de uso para borrar grupos de normas jurídicas del SGP. ..... 42Tabla 9. Caso de uso editar contenido documental de grupo de normasjurídicas del SGP. ........................................................................................ 42Tabla 10. Caso de uso nuevos documentos. ............................................... 43Tabla 11. Caso de uso descargar documentos............................................ 43Tabla 12. Caso de uso para crear un formulario.......................................... 44Tabla 13. Caso de uso ver formularios revisados. ....................................... 44Tabla 14. Caso de uso consultar casos (formularios) .................................. 45Tabla 15. Caso de uso revisar caso (formulario) ......................................... 45Tabla 16. Caso de uso corregir caso (formulario) ........................................ 46Tabla 17. Caso de uso validar caso (formulario).......................................... 46Tabla 18. Requisitos no funcionales ............................................................ 47Tabla 19. Estándares java. .......................................................................... 69


xiii

LISTA DE FIGURAS

Figura 1. Ejemplo de clase ............................................................................ 9Figura 2. Ejemplo de herencia ..................................................................... 10Figura 3. Definición de polimorfismo............................................................ 10Figura 4. Ejemplo de polimorfismo............................................................... 11Figura 5. Tipos de abstracción y su respectivo contravalor ......................... 12Figura 6. Ejemplo casos de uso................................................................... 15Figura 7. Diagrama de actividades. ............................................................. 16Figura 8. Diagrama de secuencia ................................................................ 16Figura 9. Ejemplo de diagrama de componentes......................................... 17Figura 10. Estructura conceptual del paquete ............................................. 18Figura 11. Diagrama de despliegue ............................................................. 18Figura 12. Diagrama de clases .................................................................... 19Figura 13. Arquitectura de software 3 capas ............................................... 20Figura 14. Ejemplo clase abstracta.............................................................. 21Figura 15. Subclases de clase abstracta ..................................................... 22Figura 16. Ciclo de vida JSF........................................................................ 24Figura 17. Arquitectura de Spring Framework ............................................. 25Figura 18. Objetos de distintos frameworks ................................................. 27Figura 19. Integración de Frameworks ........................................................ 27Figura 20. Ejemplo de consultas a diferentes SGBD................................... 28Figura 21. Power designer ........................................................................... 32Figura 22. Fases de RUP ............................................................................ 36Figura 23. Diagrama de caso de uso para la autentificación de usuarios .... 48Figura 24. Diagrama de casos de uso para el administrador del sistema.... 49Figura 25. Diagrama de caso de uso para la opción de administracióndocumental .................................................................................................. 50Figura 26. Diagrama de caso de uso para el soporte y seguimiento de casos..................................................................................................................... 51Figura 27. Diagrama de actividades general del sistema. ........................... 53Figura 28. Diagrama de secuencia para la autentificación de usuarios ....... 54Figura 29. Diagrama de secuencia para la administración de usuarios....... 55Figura 30. Diagrama de secuencia para la administración de empresas..... 56Figura 31. Diagrama de secuencia para la creación de grupos de normasjurídicas del SGP ......................................................................................... 57Figura 32. Diagrama de secuencia para la descarga de documentos. ........ 58Figura 33. Diagrama de secuencia para el registro de casos (formularios) . 59Figura 34. Diagrama de secuencia para la revisión de casos (formularios). 60Figura 35. Diagrama de componentes del proyecto .................................... 61Figura 36. Estructura y relación entre capas de presentación, negocios eintegración. .................................................................................................. 62Figura 37. Diagrama de paquetes para el proyecto. .................................... 63


xiv

Figura 38. Diagrama de despliegue del proyecto......................................... 65Figura 39. Diagrama de clases del proyecto................................................ 66Figura 40. Arquitectura de capas lógicas..................................................... 67Figura 41. Diagrama de secuencia para la autenticación de usuarios,detallando capas de servicios, gestor y persistencia. .................................. 78Figura 42. Mapeo de servicios ..................................................................... 78Figura 43. Mapeo de gestores ..................................................................... 79Figura 44. Transacciones con spring ........................................................... 79Figura 45. Configuración del DataSource en spring .................................... 80Figura 46. SessionFactory con spring.......................................................... 80Figura 47. Implementación del orm de la aplicación .................................... 81Figura 48. Implementación del controlador para la capa de presentación. . 82Figura 49. Implementación del dataManager para la capa de presentación.83


xv

RESUMEN

“DISEÑO, DESARROLLO E IMPLEMENTACIÓN DE UNA APLICACIÓN

WEB PARA LA ADMINISTRACIÓN, PREVENCIÓN Y SOPORTE DEL

SISTEMA NACIONAL DE GESTIÓN DE PREVENCIÓN DE RIESGOS

LABORALES (SGP)”

QESCONSULTORES S.A es una empresa que brinda servicios de

consultoría, asesoría y capacitación al sector empresarial en general, en

aspectos como: la gestión de seguridad y salud en el trabajo, gestión de

procesos y calidad, gestión ambiental y gestión del talento humano.

El objetivo del presente proyecto es brindar a las empresas que son clientes

de QESCONSULTORES S.A. un óptimo servicio de asesoría y consultoría

para el cumplimiento de los requisitos legales vigentes en Seguridad y Salud

en el trabajo, mediante el diseño, desarrollo e implementación de una

aplicación web que automatice los procesos de consultoría.

El correcto cumplimiento de los requisitos legales en Seguridad y Salud en el

trabajo, evitará sanciones administrativas previstas en la ley, por parte del

Ministerio de Relaciones Laborales y la Dirección de riesgos del Trabajo del

IESS.

DESCRIPTORES:

PROCESOS DE CONSULTORIA / QESCONSULTORES S.A / EMPRESAS

CLIENTES ECUATORIANAS / MARCOS DE TRABAJO / UML / BASE DE

DATOS.


xvi

ABSTRACT

“DESIGN, DEVELOPMENT AND IMPLEMENTATION OF A WEB

APPLICATION FOR THE ADMINISTRATION, PREVENTION AND

SUPPORT OF NATIONAL SYSTEM OF RISKS LABOR”

QESCONSULTORES SA is a company that provides consultancy services,

advising and training to the business sector in general, in areas such as:

security management and health in the place of work, quality and process

management, environmental and talent management.

The objective of this Project is to provide an optimum service of advising and

consultancy to the companies that are clients of QESCONSULTORES S.A.

for the compliance of security regulations and health in the place of work that

are valid in the SGP, through the design, development and implementation of

a web application that automates the processes of consultancy.

The correct compliance of the regulations of security and health in work will

avoid administrative sanctions that are forecasted in law by the Ministry of

Labor Relations and the Direction IESS Labor risks.

DESCRIPTORS:

PROCESS OF CONSULTANCY / QESCONSULTORES S.A. /

ECUATORIANAS BUSINESS CLIENTS / FRAMEWORKS / UML /

DATABASE.


xvii

CERTIFICADO TRADUCCIÓN DEL RESUMEN


xviii

CERTIFICACIÓN DE CONOCIMIENTO EN EL IDIOMA INGLÉS


1

INTRODUCCIÓN

QESCONSULTORES S.A es una empresa dedicada a la consultoría,

asesoría y capacitación al sector empresarial en general, en aspectos como:

la Gestión de Seguridad y salud en el Trabajo, Gestión de Procesos y

Calidad, Gestión Ambiental y Gestión del Talento Humano.

Ésta presente investigación y cuyo resultado es el diseño, desarrollo e

implementación de una aplicación web para la administración, prevención y

soporte del Sistema Nacional de Gestión de Prevención de Riesgos

laborales (SGP), ayudará a QESCONSULTORES S.A a brindar sus servicios

de consultoría y asesoría a empresas nacionales de la mejor manera, de

modo que estas puedan implementar el SGP en forma correcta y obtener un

alto nivel de eficacia.

Acerca del SGP

Todo empleador, de los sectores público y privado, para efecto de la gestión

de la prevención, identificación, medición, evaluación y control de los riesgos

del trabajo, implementará de forma obligatoria el Sistema Nacional de

Gestión de Prevención de Riesgos Laborales (SGP), de propiedad del

Instituto Ecuatoriano de Seguridad Social, que será auditado por el Ministerio

de Relaciones Laborales y la Dirección de riesgos del Trabajo del IESS.

Objetivo del SGP

La implementación del Sistema de Gestión de Seguridad y Salud en el

Trabajo mejorará la calidad de vida de los empleados, mediante la

generación de ambientes de trabajo; seguros y prácticas saludables; provee

y minimiza los riesgos del trabajo, incrementando niveles de producción en

las empresas y contribuye a la excelencia empresarial.

Control del SGP

El Ministerio de Relaciones Laborales, de acuerdo a las muestras de

auditoría establecidas conjuntamente con la Dirección del Seguro General


2

de Riesgos del Trabajo, auditará el cumplimiento, por parte de los

empleadores, de la implementación del Sistema Nacional de Gestión de

Prevención de Riesgos Laborales (SGP), dentro de los plazos establecidos

en el propio Sistema.

Sanciones SGP

El incumplimiento del presente instructivo dará lugar a las sanciones

administrativas previstas en la ley, por parte del Ministerio de Relaciones

Laborales; así como al correspondiente incremento de la prima de recargo

del Seguro General de Riesgos del Trabajo a ser establecido por el Instituto

Ecuatoriano de Seguridad Social.


3

CAPÍTULO I

1 Presentación del problema1.1 Planteamiento del problema

Las empresas ecuatorianas necesitan cumplir con normas, estándares y

políticas de seguridad para minimizar los riesgos en un espacio físico de

trabajo, brindando seguridad y tranquilidad a sus empleados. Para dar

constancia de este cumplimiento las empresas deben obligatoriamente

implementar el SGP con la finalidad de obtener un nivel de cumplimiento

técnico-legal o índice de eficacia.

QESCONSULTORES S.A. ayuda a mejorar estos resultados asesorando,

guiando y explicando punto por punto cada uno de los procesos y elementos

que componen el SGP.

Este proceso de consultoría, soporte y comunicación entre consultor y

cliente se lo ha venido realizando vía mails, documentos planos (Word,

Excel, Pdf’s), vía telefónica es decir de una forma manual, por lo que se

dificulta llevar una administración del soporte técnico y consultoría, al no

contar con un sistema electrónico que facilite esta interacción.

Cuando las empresas no cuentan con un sistema informático de

administración de documentos formal, el contenido suele crearse y

guardarse de manera no administrada y descentralizada lo que puede

provocar la pérdida de información y confusión en el asesoramiento.

Según el Gerente General de la empresa consultora QESCONSULTORES

S.A. en la actualidad en el Ecuador no existe un sistema informático que

facilite el proceso de consultoría y soporte entre empresas nacionales y

empresas consultoras en apoyo al cumplimiento con el SGP.

1.2 Formulación del problema

¿De qué manera el diseño, desarrollo e implementación de una aplicación

web mejora el soporte, consultoría, coordinación y comunicación entre

QESCONSULTORES S.A y sus empresas clientes, para el cumplimiento del

SGP?


4

1.3 Interrogantes de la Investigación

¿Cómo conocer el proceso de negocio de QESCONSULTORES S.A?

¿Cómo QESCONSULTORES S.A podría mejorar el proceso de negocio

de consultoría?

¿Cuáles son las ventajas del uso de un sistema informático de asesoría

y consultoría?

¿Qué factores están asociados a la satisfacción del cliente en una

empresa de servicios de consultoría?

¿Cómo ayudará RUP en el diseño, desarrollo e implementación de una

aplicación web para la administración, prevención y soporte del SGP?

¿Se podrá adaptar a la aplicación web más funcionalidades a nivel de

software en un futuro?

1.4 Objetivos de la Investigación

1.4.1 Objetivo General

Brindar a las empresas clientes de QESCONSULTORES S.A. un óptimo

servicio de asesoría y consultoría para el cumplimiento de las normas y

requisitos legales vigentes establecidos en el SGP, mediante el diseño,

desarrollo e implementación de una aplicación web que automatice los

procesos de consultoría.

1.4.2 Objetivos Específicos

Aplicar la investigación de campo para conocer acerca del proceso de

negocio y las necesidades que provienen de QESCONSULTORES S.A.

Obtener especificaciones puntuales sobre el sistema de software e

identificar requisitos funcionales y no funcionales mediante reuniones con

QESCONSULTORES S.A.


5

Usar la metodología RUP para asegurar la producción del software de

alta calidad que resuelva las necesidades de QESCONSULTORES S.A.

dentro de un presupuesto y tiempo establecido.

Determinar una arquitectura de software, en base a los requisitos

obtenidos en QESCONSULTORES S.A.

Creación de un sistema de base de datos.

Administrar de manera óptima los documentos de registro con la

ayuda de la aplicación web.

Evidenciar objetivamente el cumplimiento de los requisitos legales

vigentes del SGP en caso de auditoría.

Almacenar, organizar y localizar documentos.

Garantizar la coherencia de los documentos.

Ayudar a proteger documentos contra el acceso o uso no autorizados.

Ayudar a implementar formularios que solicita el SGP, a las empresas

clientes de QESCONSULTORES S.A.

1.5 Justificación

Con el diseño, desarrollo e implementación de una aplicación web para la

administración, prevención y soporte del Sistema Nacional de Gestión de

Prevención de Riesgos laborales (SGP), se logrará una plataforma de

contenido documental empresarial donde QESCONSULTORES S.A. podrá

almacenar y compartir documentación con información relevante y

actualizada de las normas y estándares del SGP, luego sus empresas

clientes podrán conocer esta información y tomar en cuenta si dichas

normas han sido cambiadas o actualizadas por el SGP y de esta forma tener

claro su régimen para poder implementarlo correctamente.


6

Por otra parte las empresas clientes ecuatorianas podrán subir al sistema

formularios implementados con información que el SGP solicita, de esta

forma se realiza la respectiva revisión y corrección de los mismos por parte

de QESCONSULTORES S.A., de modo que se podrá trabajar sobre un

mismo formulario de información sin dar lugar a confusiones ni quedar

atrapados en múltiples versiones o modificaciones.

La aplicación web centralizará la información de modo que se eliminará la

duplicación de esfuerzos y reducirá los costos operacionales de la

descentralización. Por otra parte si se maneja adecuadamente la

documentación e información de asesoría y consultoría se obtendrá

beneficios como: disminuir tiempos en los procedimientos manuales que se

realizan en la administración, optimizar recursos y un eficiente y eficaz

control en la administración documental, además se podrá realizar en un

futuro modificaciones o mejoras en el la aplicación web para que se adapte

mejor a las necesidades de la empresa.

En el ámbito de seguridad informática se restringirá el acceso a la aplicación

web mediante un módulo de autenticación de usuarios.


7

CAPÍTULO II

2 Revisión Bibliográfica2.1 Antecedentes

El presente trabajo de investigación se apoyará en fuentes de información

como Internet, libros y tesis realizadas.

Según el gerente general de QESCONSULTORES S.A., en la actualidad no

existe una aplicación web que incluya la automatización de procesos de

consultoría y soporte, en apoyo al cumplimiento del SGP.

Para solucionar los problemas en la administración del soporte técnico y de

consultoría se han tomado en cuenta las siguientes conclusiones:

Dentro de la gestión de procesos de negocios, la automatización de

procesos o BPA por sus siglas en inglés (Business Process Automation) es

uno de los pilares para el control y la maximización de la eficiencia en

empresas que deseen mejorar la calidad de sus servicios. En consecuencia

el BPA permitirá dividir un flujo de trabajo en tareas y adjudicar al personal

roles y responsabilidades.

Se considera a la gestión de contenidos empresariales o ECM por sus siglas

en inglés (Enterprise Content Management) como una manera formal de

organización y almacenamiento de documentos empresariales, y otros

contenidos que se relacionan con los procesos de la empresa.


8

2.2 Fundamentación Teórica2.2.1 Definición de empresa consultora

Las empresas consultoras, son empresas de servicios profesionales con

experiencia o conocimiento específico en un área, que asesoran a otras

empresas. La consultoría de empresas es un servicio que ayuda a mejorar y

resolver problemas en la gestión y prácticas empresariales, de este modo su

misión es potenciar un crecimiento empresarial en forma sinérgica.

En el presente proyecto la empresa QESCONSULTORES S.A. brindará sus

servicios de consultoría a sus clientes (empresas) en la prevención y soporte

de la implementación del SGP.

2.2.2 Definición de riesgos y peligros laborales2.2.2.1 Definición de peligro laboral

Por peligro se entiende a toda situación que puede afectar la vida individual

o colectiva de las personas. El peligro hace probable un incidente1.

2.2.2.2 Definición de riesgo laboral

Por riesgo es la probabilidad de que se materialice de forma efectiva cierto

peligro. El riego es la consecuencia o resultado de un incidente.

Tabla 1. Posibles riesgos laborales.

Lesiones Enfermedades

Cortes Sordera

Golpes Hernias

Quemaduras Ceguera

Raspones Insuficiencia respiratoria.

1 Incidente: Cosa que se interpone en el transcurso normal de algo.


9

2.2.3 Definición de ingeniería de software

Es la aplicación práctica del conocimiento científico al diseño, desarrollo e

implementación del software, este conocimiento engloba métodos,

herramientas y técnicas que se utilizan en la realización de programas

informáticos.

2.2.4 Definición de programación orientada a objetos

Figura 1. Ejemplo de clase

Fuente: Izquierdo , L.R. (2011) Programación orientada a objetos. Obtenido dehttp://luis.izqui.org/resources/ProgOrientadaObjetos.pdf

La programación orientada a objetos (POO por sus siglas en inglés, Object-

oriented programming), es un paradigma de programación para el desarrollo

de programas informáticos en base a objetos, está basado en 4 pilares

fundamentales que son: encapsulamiento, herencia, polimorfismo y

abstracción.

Una clase es una plantilla de la cual se crean objetos, en la POO se dice que

un objeto es una instancia de una clase, que se forma de atributos, los

cuales representan sus características o propiedades y con métodos que

emulan su comportamiento.

2.2.4.1 Definición de encapsulamiento

El encapsulamiento es una ventaja que proporciona la programación

orientada a objetos, que consiste en ocultar el estado de los datos miembro

de un objeto, manteniéndolos aislados del exterior, es decir los datos

miembro solo podrían ser accedidos mediante métodos, de esta manera los

detalles de su implementación estarían ocultos y se evitarían modificaciones

y accesos indebidos a la clase.


10

Asimismo un usuario no debe preocuparse de cómo están implementados

los métodos y propiedades de una clase, sino de cómo debe usarlos.

2.2.4.2 Definición de herencia

Figura 2. Ejemplo de herencia


La herencia consiste en la reutilización de código, es decir la idea

fundamental es permitir crear nuevas clases a partir de otras existentes, de

tal forma que se podría compartir automáticamente métodos y datos entre

clases.

2.2.4.3 Definición de polimorfismo

Figura 3. Definición de polimorfismo

En la figura 3 se muestra un mapa conceptual referente al polimorfismo y

explica que existe la posibilidad de crear varias clases con diferentes

funcionalidades, pero con métodos o propiedades denominados de forma


11

idéntica, que pueden utilizarse con diferentes implementaciones

dependiendo del caso; por ejemplo:

Figura 4. Ejemplo de polimorfismo

Fuente: Robertho, R.E.; Albaro, P.R. y Encarna, S.S. (2007) Programación orientada a objetos.Obtenido de http://es.scribd.com/doc/242753840/Programacion-Orientada-Objetos-2012-pdf#scribd

En la figura 4, se aprecia un ejemplo de polimorfismo, en el que todos los

instrumentos tienen la función de tocar, pero cada uno tocará en forma

diferente.

2.2.4.3.1 Definición de sobrecarga de métodos

En POO la sobrecarga de métodos permite la creación de funciones con el

mismo nombre pero con diferente funcionalidad y diferente firma.

Al momento de usar un método sobrecargado, el compilador sabrá a quien

llamar dependiendo de la firma2 que cada método posee. Lo mismo

sucederá al momento de usar un constructor, es decir también puede existir

sobrecarga de constructores.

Al momento la definición de polimorfismo y sobrecarga de métodos es

parecido; a continuación se explicaran las diferencias.

2 Definición de firma de un método: La firma de un método se refiere al número de paramentos, elorden y el tipo de dato de los mismos, de tal forma que los métodos se diferencien.


12

Tabla 2. Diferencias entre polimorfismo y sobrecarga de métodos

N° Polimorfismo Sobrecarga de métodos

1 El polimorfismo tiene que ver con que un

método se ejecuta diferente, dependiendo

de la clase que lo llame.

La sobrecarga de métodos funciona dentro de

una misma clase.

2 El Polimorfismo hace referencia a un

conjunto de métodos con el mismo Nombre

e igual número de Parámetros y Tipos, pero

que se encuentran definidos en diferentes

Clases.

En una sola clase pueden existir varios

métodos con el mismo nombre pero con

distinta firma, de tal forma que un método se

ejecutará dependiendo de los parámetros que

se le pase.

3 El objetivo del polimorfismo es realizar

diferentes funcionalidades.

Cuando se sobrecarga un método, el objetivo

es que todos hagan la misma funcionalidad

2.2.4.4 Definición de abstracción

La abstracción consiste en separar lo más importante o relevante de un

objeto, de modo que se los objetos se diferencien unos de otros.

Existen tipos de abstracción, los cuales se explican en la siguiente figura:

Figura 5. Tipos de abstracción y su respectivo contravalor

2.2.5 Definición de java

Es un lenguaje de programación orientado a objetos basado en clases que

se ejecuta en la máquina virtual Java (JVM).

Las clases de Java son archivos con extensión ".java" que contienen el

código fuente y suelen encontrarse en carpetas de nombre src (source) y


13

que al compilarlos (con javac) generan archivos ".class" que contienen el

bytecode (código que la máquina virtual Java entiende) y que se encuentran

en carpetas de nombre bin (binary).

2.2.5.1 Definición de compilación

Es el proceso de traducción de código fuente de un lenguaje de

programación de alto nivel (en este caso java) a lenguaje de máquina.

El código fuente pasa por varias etapas, entre ellas está el análisis sintáctico

y análisis semántico, para finalmente traducirlo a un lenguaje de máquina,

ceros y unos (conocido como bytecode).

2.2.6 Definición de JVM

La máquina virtual de java (JVM, por sus siglas en inglés, Java Virtual

Machine) es uno de los segmentos esenciales de la plataforma java, ya que

se encarga de ejecutar e interpretar el código binario y que en última

instancia convierte el código bytecode a código nativo del dispositivo final.

2.2.7 Definición de JDK

Java development kit o (JDK), es el software que suministra herramientas de

desarrollo para la creación de programas en java. En el sistema operativo

windows se configuran variables de entorno y son:

-JAVAPATH: Es un path completo del directorio donde está instalado el JDK.

-CLASSPATH: Son las librerías o clases de usuario.

-PATH: Es la variable donde se adiciona la ubicación de JDK.

2.2.8 Definición de JRE

El entorno de ejecución java (JRE, por sus siglas en ingles Java Runtime

Environment ), es un conjunto de utilidades que permite la ejecución de

programas Java y actúa como un "intermediario" entre el sistema y Java.

Un usuario sólo necesita el JRE para ejecutar las aplicaciones desarrolladas

en lenguaje Java.


14

2.2.9 Definición de Lenguaje Unificado de modelado (UML)

El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified

Modeling Language) es un lenguaje gráfico, que permite construir, visualizar,

documentar y describir un modelo de un sistema de software.

Se usa este lenguaje ya que permite entender de mejor manera las

funcionalidades de un sistema a desarrollar, tratando de verlo desde

distintas perspectivas, por lo que en el presente proyecto se desarrollará los

siguientes diagramas:

Diagramas de comportamiento

-Diagrama de casos de uso.

-Diagrama de actividades.

-Diagramas de secuencia.

Diagramas de estructura

-Diagrama de componentes.

-Diagrama de paquetes.

-Diagrama de despliegue.

-Diagrama de clases.


15

2.2.9.1 Definición de diagrama de casos de uso

Figura 6. Ejemplo casos de uso


Para el desarrollo del presente proyecto se usará los diagramas de casos de

uso para representar los pasos, acciones o actividades que se deberán

realizar para el proceso de consultoría.

En un diagrama de casos de uso intervienen actores, casos de uso y sus

relaciones.

Definiciones básicas de elementos de casos de uso:

Actores: Pueden ser usuarios, sistemas incluso entidades abstractas

como el tiempo, que cumplan un rol dentro del sistema.

Casos de uso: Describen acciones y reacciones que equivalen a las

funcionalidades del sistema (requisitos funcionales).

Tipos de relaciones entre casos de uso:

-Extends <<extends>>:Indica que el caso de uso no es indispensable que

ocurra, se lo lee “va a poder hacer”.

-Include <<include>>: Se usa cuando un primer caso de uso necesite incluir

otro caso de uso para su correcto funcionamiento.


16

-Uses <<uses>>: Se usa cuando se tiene un conjunto de características que

son similares en más de un caso de uso y no se quiere mantener copiada la

descripción de la característica.

2.2.9.2 Definición de diagramas de actividades

Figura 7. Diagrama de actividades.

Fuente: Antonia, Z. (2008). Diagrama de actividades. Obtenido de http://ocw.unizar.es/ciencias-experimentales/modelos-matematicos-en-bases-de-datos/uml/02UML_DiagramaActividades.pdf

Los diagramas de actividades representan algoritmos de un proceso de

negocio y se construyen mediante símbolos con significados definidos que

constituyen pasos, además el flujo de ejecución se la hace mediante flechas

que conectan los puntos de inicio y de fin.

2.2.9.3 Definición de diagramas de secuencia

Figura 8. Diagrama de secuencia

Fuente: Robertho, R.E.; Albaro, P.R. y Encarna, S.S. (2012) Programación orientada a objetos.Obtenido de http://es.scribd.com/doc/242753840/Programacion-Orientada-Objetos-2012-pdf#scribd

Un diagrama de secuencia es un diagrama que ayuda a entender la

interacción entre los objetos a través del tiempo además se modela una

secuencia para cada caso de uso definido. Para la construcción de este

diagrama se tomará en cuenta el diagrama de casos de uso definido para el

proyecto.


17

Se extraerá los objetos que intervienen en el escenario y se los representará

con líneas discontinuas verticales y los mensajes pasados entre dichos

objetos se simbolizarán con flechas horizontales.

2.2.9.4 Definición de diagrama de componentes

Figura 9. Ejemplo de diagrama de componentes

Fuente: Sergio, C. (2010). Diagrama de componentes. Obtenido enhttp://professor.unisinos.br/wp/crespo/files/2011/07/aula5.pdf

Es un diagrama que muestra los elementos de software del sistema y sus

dependencias. Entre los componentes físicos podemos mencionar a los

archivos, paquetes, librerías, motor de base de datos, ejecutables, etc.

Tabla 3. Algunos ejemplos de componentes

Componentes Definición de componente

Representa un archivo de texto, por ejemplo los documentos

que se generaron en el trabajo de campo, la recolección de

datos que se hicieron, también se usa para representar código

fuente.

Se usa para representar librerías estáticas o dinámicas, por

ejemplo librerías para comunicarse con una base de datos,

librerías para representar la interfaz gráfica de usuario.

Simboliza una tabla en la base de datos.

Simboliza como tal los programas ejecutables, es decir cuando

un código fuente se pasa por un compilador o por un intérprete

este genera un código ejecutable. Por ejemplo en java

tendríamos un código fuente .java y sus ejecutables .class

Componente para páginas web, es decir representa archivos

xhtml en este proyecto.

Nota: En la tabla, se definen algunos componentes con su respectiva explicación.


18

2.2.9.5 Definición de diagrama de paquetes

Un diagrama de paquetes agrupa lógicamente los componentes de software

mostrando sus respectivas dependencias.

Figura 10. Estructura conceptual del paquete

Nota: En la figura se muestra la estructura de los paquetes que se usará en el proyecto y se trata de laanidación de paquetes unos dentro de otros y sus dependencias.

Los diagramas de paquetes ayudan a plantear la arquitectura del sistema a

nivel macro.

2.2.9.6 Definición de diagramas de despliegue

Figura 11. Diagrama de despliegue

Fuente: Xavier, F.G; María, I.S. Desarrollo orientado a objetos con UML. Obtenido dehttp://www.uv.mx/personal/maymendez/files/2011/05/umlTotal.pdf. UPM.

Los diagramas de despliegue modelan la arquitectura de un sistema, se

componen de nodos y muestran las relaciones entre sus componentes.


19

2.2.9.7 Definición de diagrama de clases

Figura 12. Diagrama de clases

Fuente: Xavier, F.G; María, I.S. Desarrollo orientado a objetos. UPM. Obtenido dehttp://www.uv.mx/personal/maymendez/files/2011/05/umlTotal.pdf.

Un diagrama de clases describe la estructura de un sistema, mediante la

definición de clases y sus relaciones orientado a objetos.

2.2.10 Definición de java empresarial JEE (Java Enterprise Edition)

Es una plataforma de programación que permite el desarrollo y ejecución de

software en el lenguaje de programación java, maneja arquitecturas de N

capas distribuidas, también se apoya enteramente en componentes de

software modulares y se despliega sobre un servidor de aplicaciones.

2.2.11 Definición de Arquitectura de software

Es el diseño de alto nivel de la estructura de un sistema informático y que se

crea en base a requerimientos y restricciones3

Como una analogía se puede mencionar los planos de un edificio, con

dichos planos se puede visualizar su estructura, es decir el cómo será

armado y construido y como quedará al finalizar el proyecto. A semejanza de

estos planos la arquitectura indicará la estructura, funcionamiento e

interacción entre las partes del software.

3 Restricciones: Son aquellas limitaciones derivadas de las tecnologías disponibles para implementarsistemas de información


20

2.2.11.1 Arquitectura de software en tres capas

Figura 13. Arquitectura de software 3 capas

Fuente: Ian, S. (2005). Ingeniería del software. Obtenido dehttps://books.google.com.ec/books?id=gQWd49zSut4C&printsec=frontcover&hl=es&source=gbs_ge

_summary_r&cad=0#v=onepage&q&f=false

La figura 13 representa una separación de capas, que se explica a

continuación:

En la capa 1 de presentación o también llamada vista, se establece una

interfaz gráfica, en la que un usuario puede realizar una o más acciones

mediante su navegador web y que a su vez estas llegan al servidor de la

capa 2 mediante una petición HTTP.

En la capa 2 de negocio o también llamada capa de modelo se establece

toda la lógica de negocio que quedaría centralizada en un servidor, es la

encargada de recibir solicitudes y entregar resultados a la capa 1.

Finalmente la capa 3 es donde residen los datos y es la encargada de

acceder a los mismos.


21

2.2.12 Definición de clase abstracta

Figura 14. Ejemplo clase abstracta

Fuente: Clases abstractas e interfaces. UPM. Obtenido dehttp://www2.caminos.upm.es/Departamentos/matematicas/Fdistancia/PIE/java/temasj/tjava10.pdf

En la figura 14 se puede observar una clase abstracta, la que se toma como

ejemplo para entender su estructura.

Si una clase tiene un método abstracto, la clase debe declararse

como abstracta.

Una clase puede declararse como abstracta aunque no tenga ningún

método abstracto.

Los métodos abstractos no se implementan en la clase abstracta, solo

se declaran.

Una clase abstracta puede incluir variables y métodos no abstractos.

No se puede definir constructores abstractos o métodos estáticos

abstractos.

Una clase abstracta no puede instanciarse, es decir no se pueden

crear objetos de esta clase.


22

Figura 15. Subclases de clase abstracta

Fuente: Clases abstractas e interfaces. UPM. Obtenido dehttp://www2.caminos.upm.es/Departamentos/matematicas/Fdistancia/PIE/java/temasj/tjava10.pdf

Las subclases de la clase abstracta deben sobrescribir

necesariamente todos los métodos de la clase padre o superclase y agregar

funcionalidad a los métodos abstractos, o bien pueden ser declaradas como

clases abstractas, como se observa en la figura 15.

Con lo expuesto anteriormente se puede decir que una clase abstracta está

presente cuando existe una jerarquía de clases en la que algún

comportamiento es común y se materializa de forma distinta para cada una.

2.2.13 Definición de interface

Se puede decir que una interface es una clase abstracta pura, es decir, en

una interface ningún método puede ser implementado, los métodos solo

pueden ser definidos. Los datos miembro de una interface pueden ser de

tipo static y final.

2.2.14 Definición de Modelo Vista Controlador (MVC)Es un patrón de arquitectura de software que se encarga de separar al

modelo, a la vista y al controlador con el fin de reutilizar código y separar

conceptos, de este modo busca facilitar el desarrollo de aplicaciones y su

posterior mantenimiento.

El Modelo que contiene una representación de los datos que maneja el

sistema, su lógica de negocio, y sus mecanismos de persistencia.


23

La Vista, que es la interfaz de usuario.

El Controlador, que actúa como intermediario entre el Modelo y la Vista,

gestionando el flujo de información entre ellos y las transformaciones

para adaptar los datos a las necesidades de cada uno.

2.2.15 Definición de Framework

Un framework es un marco de trabajo o conjunto de bibliotecas orientadas a

la reutilización de código a nivel de componentes de software y su uso

acelera el desarrollo de aplicaciones.

2.2.15.1 Ventajas de un framework

Entre las ventajas principales que brinda un framework podemos anotar las

siguientes:

Disminuir el tiempo de desarrollo de un sistema informático.

Usar componentes que ya existen, y adaptarlos a un nuevo sistema

parametrizándolos a conveniencia.

Los componentes siguen una política de diseño uniforme, por lo tanto

al usar un framework se garantiza una estructura de software óptima y

organizada.

Un framework orientado a objetos está formado por clases, lo cual

implica la existencia de bibliotecas más fáciles de aprender a usar.

La portabilidad de aplicaciones de una arquitectura a otra.

Un framework es un trabajo usado por la comunidad de

programadores y por lo que es menos propenso a sufrir errores.

2.2.16 Definición de java server fases (JSF)

Es un Framework que facilita la creación de interfaces gráficas de usuario en

aplicaciones JEE basados en el patrón modelo vista controlador (MVC).

Para el presente proyecto se usará la versión JSF 2.1 con la extensión Prime

Faces versión 3.5 ya que tiene novedades como la incorporación de nuevos


24

componentes y el poder encontrarlos fácilmente además proporciona un

nuevo conjunto de palabras clave para la búsqueda de expresiones y cuenta

con documentación actualizada.

2.2.16.1 Ciclo de vida JSF

Figura 16. Ciclo de vida JSF

Fuente: Ciclo de vida JSF (2013). Obtenido de

http://project-longinus.es/jsf-introduccion-y-ciclo-de-vida/

A continuación se explica cada una de las etapas JSF

1. Restaurar los componentes de la vista (restore view): En esta etapa el

controlador construye en memoria la estructura de componentes de la

página.

2. Aplicar los valores de la petición (apply request values): En esta etapa

se recuperan los valores de la request y se asignan a los beans de la página.

3. Procesamiento de las validaciones (process validations): Se verifican

los parámetros de entrada según un conjunto de reglas definidas en un

fichero de configuración.

4. Actualizar los valores del modelo (update model values): Los valores

leídos y validados son cargados en los beans.

5. Invocación a la aplicación (invoke application): Se ejecutan las

acciones y eventos solicitados para la página. Si es necesario se realiza la

navegación.


25

6. Generación de la página (render response): En esta fase se genera la

página que será enviada al usuario con todos sus elementos y valores

actualizados.4

2.2.17 Definición de Prime Faces y Rich FacesSon librerías de componentes que facilita la creación de páginas web en

JSF, son de código abierto, cuentan con una completa documentación y son

de fácil uso.

2.2.18 Spring framework2.2.18.1 Definición de spring

Spring es un framework que proporciona varios módulos, los cuales ayudan

a construir aplicaciones empresariales y son independientes, es decir la

separación en módulos permitirá usar solo las partes que se necesite sin

tener que cargarlos todos.

2.2.18.2 Arquitectura de spring

Figura 17. Arquitectura de Spring Framework

Fuente: Balani, (2005). Spring framework.

Spring Core: Este módulo es el más importante ya que este provee la

funcionalidad principal del framework, está compuesta por el BeanFactory

que utiliza el patrón de inversión de control (Inversion of control) y configura

los objetos a través de inyección de dependencia (Dependency Injection).

4 Fuente: http://project-longinus.es/jsf-introduccion-y-ciclo-de-vida/


26

El núcleo de spring es el paquete org.springframework.beans el cual está

diseñado para trabajar con java beans.

El contenedor ApplicationContext se basa en BeanFactory y extiende su

funcionalidad con soporte para i18n, eventos de ciclo de vida, validación y

mejor integración con AOP.

Spring AOP: Provee la implementación de AOP, permite desarrollar

interceptores de método y puntos de corte para desacoplar el código de las

funcionalidades transversales.

Spring DAO: Provee una capa de abstracción sobre JDBC, abstrae el

código de acceso a datos de una manera simple y limpia. Tiene una capa de

expresiones sobre los mensajes de error provistos por cada servidor

específico de base de datos. Además cuenta con manejo de transacciones a

través de AOP.

Spring ORM: Provee la integración para las distintas APIs de mapeo objeto-

relacional incluyendo JPA, JDO, Hibernate e iBatis.

Spring JEE: Provee integración con aplicaciones Java Enterprise Edition así

como servicios JMX, JMS, EJB, etc.

Spring Web: Módulo que aporta clases especiales orientadas al desarrollo

web e integración con tecnologías como Struts y JSF. Cuenta con el paquete

Spring MVC, una implementación del conocido patrón de diseño aplicando

los principios de Spring.5

Spring ayuda a inicializar objetos de distintos frameworks que se podrían

necesitar en una aplicación, basándose en ficheros xml o anotaciones.

5 Fuente: http://picandocodigo.net/2010/introduccion-a-spring-framework-java/


27

Figura 18. Objetos de distintos frameworks

En la figura del ejemplo se observa que una aplicación usa tres frameworks,

en la situación 2 se genera un problema al querer inicializar los objetos ya

que cada framework es totalmente independiente y gestiona su propio ciclo

de vida de los objetos, de manera que spring ayuda a inicializar los objetos

de los distintos frameworks.

Figura 19. Integración de Frameworks

Spring además ayuda a integrar los frameworks de manera correcta, como lo

describe la figura 19

2.2.18.3 Principales ventajas de spring

Spring se acopla a la aplicación sin obligar modificaciones de código

para utilizar sus funcionalidades y beneficios.

Spring permite que el código Java sea más limpio, elegante y

reutilizable, ya que spring guía una programación orientada a interfaces, de


28

modo que toda la aplicación sea altamente modular y posea bajo

acoplamiento.

Los objetos reciben sus dependencias en tiempo de creación, de

manera que ellos no son los responsables de la inicialización e instanciación

de esas dependencias.

2.2.19 Definición de Servidor de aplicaciones

Un servidor de aplicaciones proporciona servicios que soportan la ejecución

y disponibilidad de las aplicaciones desplegadas, este servidor gestiona las

funciones de la lógica de negocio y acceso a los datos de una aplicación, y

es el corazón de un gran sistema distribuido.

2.2.20 Definición de Jboss

Jboss es un servidor de aplicaciones JEE de código abierto, implementado

en java, su propietario es Red Hat y funciona en cualquier sistema operativo.

2.2.21 Definición de Mapeo Objeto Relacional (ORM)

El mapeo Objeto Relacional (ORM, por sus siglas en inglés, object-relational

mapping), es una técnica de programación la cual consiste en la

transformación de tablas de una base de datos relacional en una serie de

entidades que simplifiquen el acceso a los datos.

2.2.21.1 ¿Por qué usar un ORM?

Es muy importante usar un ORM en el proceso de una aplicación, ya que

abstrae al programador de la base de datos y le centra en el desarrollo de la

aplicación en sí, a continuación se explica con un ejemplo su importancia:

Figura 20. Ejemplo de consultas a diferentes SGBD

En la figura 20 se muestra un ejemplo de una consulta para delimitar el

número de registros de una consulta en tres sistemas de gestión de base de


29

datos (SGBD) como son SqlServer, MySQL, Oracle y como se puede

observar las consultas son diferentes en sintaxis, esto para el programador

supone tener que conocer el lenguaje para cada SGBD, y más importante

aún, si en el futuro se desea migrar la aplicación se tendría que reescribir un

gran número de consultas.

Otro punto muy importante es la facilidad de trabajo, porque se podría

realizar el CRUD (Create, Read, Update y Delete) de datos a través del

lenguaje de alto nivel orientado a objetos.

2.2.22 Definición de Hibernate

Hibernate es una herramienta de código abierto para la implementación del

ORM, facilita el mapeo de atributos entre una base de datos relacional y un

modelo de objetos, mediante archivos declarativos (XML) o anotaciones en

los beans de las entidades.

2.2.23 Definición de HQL

HQL (por sus siglas en inglés, Hibernate Query Languaje) es el lenguaje de

consultas que usa Hibernate para conseguir los objetos desde la base de

datos. Su principal característica es que las consultas se ejecutan sobre los

objetos que integran el modelo de negocio, es decir, las entidades que

persisten en Hibernate.

2.2.24 Definición de JPA (Java Persistence API)

Es un framework que permite automatizar la persistencia de los objetos en la

base de datos.

2.2.25 Definición de JavaScript

JavaScript es un lenguaje interpretado,6 orientado a documentos, que se

embebe en una página web HTML y se utiliza del lado del cliente, es decir se

implementa como parte de un navegador web y permite mejoras en la

6 Un lenguaje interpretado significa que a las instrucciones las analiza y procesa el navegador en elmomento que deben ser ejecutadas.


30

interfaz de usuario, además es importante tomar en cuenta que este

lenguaje es sensible a mayúsculas y minúsculas. También existe una forma

de java script que se usa del lado del servidor

2.2.26 Definición de Ajax

Es un conjunto de tecnologías (JavaScript, HTML, DHTML, CSS, PHP,

ASP.NET, JSP, XML), y cabe recalcar que no es un lenguaje de

programación.

Una característica principal de Ajax es actualizar parte de una página web,

sin tener que refrescar la página por completo de modo que Ajax permite

realizar páginas interactivas.

2.2.27 Definición de IDE Eclipse

Es un entorno de desarrollo integrado (IDE) de código abierto y

multiplataforma, es decir es un programa de software que permite la edición,

compilación y depuración de código en un lenguaje de programación.

Eclipse permite el uso de componentes o plugins para relacionar una

aplicación con otra y aportar con funcionalidades nuevas y específicas.

En el presente proyecto se usará Eclipse Versión Luna para el desarrollo de

la aplicación web ya que se dispone de un editor de texto que resalta la

sintaxis, también permite la compilación en tiempo real, tiene pruebas

unitarias, control de versiones con CVS y refactorización (reestructurar

código fuente).

2.2.28 Definición de PostgresSQL

PostgreSQL es un sistema de gestión de base de datos

(SGBD) relacional orientado a objetos y libre, se ejecuta en los principales

sistemas operativos como Linux, Unix y Windows, fue publicado bajo

la licencia BSD con las siguientes características.


31

Es una base de datos ACID (Atomicidad, Consistencia, Aislamiento y

Durabilidad) que quiere decir que cumple con un conjunto de características

necesarias para que una serie de instrucciones puedan ser consideradas

como una transacción. A continuación las definiciones:

Atomicidad: Consiste en un proceso que sigue una serie de pasos, y

en la que todos los pasos se deben ejecutar correctamente para concluir con

éxito la operación, caso contrario no se ejecuta.

Consistencia: Se refiere a la integridad de los datos, el cual asegura

que los datos sean exactos y consistentes, dicho de otra forma que estén

intactos y sean siempre los esperados y que de ninguna manera cambien ni

se deformen.

Aislamiento: Es la propiedad que asegura que una operación no

afecte a otra, es decir que cuando se realicen transacciones sobre una

misma información, estas sean independientes y no causen errores.

Durabilidad: Se refiere a la persistencia de datos, es decir asegura

que después de realizada la operación los datos no se deshagan aunque el

sistema falle.

2.2.29 Definición de JDBC

Es una API que permite la ejecución de operaciones sobre bases de

datos desde el lenguaje de programación Java, independiente del sistema

operativo (OS, por sus siglas en inglés Operating System) donde se ejecute

y de la base de datos (DB, por sus siglas en inglés Data Base) a la cual se

accede, utilizando el dialecto SQL del modelo de base de datos que se

utilice.


32

2.2.30 Definición de power designer

Figura 21. Power designer

Es una aplicación de software muy útil para el análisis y diseño de

diagramas UML e incluye herramientas para cada uno de los bosquejos,

permitiendo de esta forma facilitar el desarrollo de proyectos que satisfagan

las necesidades de manera efectiva.

En la figura 21 se puede observar los módulos con sus correspondientes

diagramas de diseño, entre los que se puede observar los diagramas de

casos de uso, secuencia, paquetes, clases, comunicación, etc., que

pertenecen al tipo de modelo Object Oriented Model. De esta forma se logra

visualizar de mejor manera el objetivo y la lógica de negocio del proyecto.

2.2.31 Definición de Aplicación web

Las aplicaciones web son programas que se diseñan para funcionar

mediante un navegador de internet, en otras palabras son aplicaciones que

se ejecutan en forma online.


33

2.2.31.1 Tipos de aplicaciones web

Las aplicaciones web se clasifican por el público al que va dirigido y el

objetivo que proyecta, por lo que su posible clasificación es:

Páginas publicitarias: Este tipo de páginas buscan anunciar

propaganda, dando a conocer productos y/o servicios que alguien (individuo

o empresa) provee y de esta forma causar impacto ante el público.

Páginas informativas: El objetivo de este tipo de páginas es presentar

información actualizada y veraz de algún tema y con una estructura óptima,

de tal forma que un usuario pueda entender y navegar sin problemas.

Páginas de comunidad: Estas páginas son accedidas por usuarios

con intereses comunes, los cuales aportan con un valor añadido en forma

pública.

Páginas catálogo/tienda: Son lugares donde un usuario puede adquirir

artículos de su necesidad, siguiendo algunos pasos y filtros de búsqueda

para conseguirlos. Algunos de estos sitios permiten realizar el pago en línea

y de esta forma dichas aplicaciones facilitan la compra y venta de productos.

Las aplicaciones web también se pueden clasificar de acuerdo a la

interacción que esta puede tener con el usuario.

Páginas web estáticas: Son páginas que muestran información

permanente, es decir información no modificable y que no pueden soportar

gestores de base de datos y lógicas de negocio programadas.

Estas aplicaciones son usadas por empresas para dar a conocer su perfil

comercial, por ejemplo: quiénes somos, ubicación en el mapa, misión, visión,

etc.

Entre sus ventajas está el costo (económico), cuentan con textos,

imágenes y no necesitan de ningún tipo de programación.

Páginas web dinámicas: Estas aplicaciones permiten a los

interesados navegar y comunicarse dentro de una página, mediante una


34

interfaz de usuario, como por ejemplo encuestas, blogs, foros, tiendas

online, etc.

Estas páginas son desarrolladas con lenguajes de programación, bases

de datos, arquitecturas de software, entre otras tecnologías.

2.2.31.2 Ventajas de una aplicación web

Ahorra tiempo: Se pueden realizar tareas sencillas sin necesidad de

descargar ni instalar ningún programa.

No hay problemas de compatibilidad: Basta tener un navegador

actualizado para poder utilizarlas.

No ocupan espacio en nuestro disco duro.

Actualizaciones inmediatas: Como el software lo gestiona el propio

desarrollador, cuando nos conectamos estamos usando siempre la última

versión que haya lanzado.

Multiplataforma: Se pueden usar desde cualquier sistema operativo

porque sólo es necesario tener un navegador.

Portables: Es independiente del ordenador donde se utilice (un PC de

sobremesa, un portátil, etc) porque se accede a través de una página web

(sólo es necesario disponer de acceso a Internet).

La disponibilidad suele ser alta porque el servicio se ofrece desde

múltiples localizaciones para asegurar la continuidad del mismo.

Los virus no dañan los datos porque éstos están guardados en el

servidor de la aplicación.

Colaboración: Gracias a que el acceso al servicio se realiza desde

una única ubicación es sencillo el acceso y compartición de datos por parte

de varios usuarios.


35

2.2.31.3 Definición de Wireframe (Diseño web)

Un wireframe es un plano que esquematiza la estructura que tendrá una

pantalla en una página web, este esquema de página ayudará a ordenar el

contenido, a tener una mejor visión en la funcionalidad y comportamiento del

sistema.

2.2.32 Definición de Proceso Unificado de Rational (RUP)

El Proceso Unificado de Rational (Por sus siglas en inglés, Rational Unified

Process) es una metodología de desarrollo de software adaptable al

contexto y necesidad de una organización.

El ciclo de vida RUP es un desarrollo en espiral y organiza las tareas en

fases y dentro de estas se realizan las iteraciones que sean necesarias.

La metodología RUP es una de las más empleadas dentro del desarrollo de

sistemas, debido a que ofrece ventajas en cuanto al diseño y la construcción

de sistemas orientados a objetos, dividiendo el proceso de desarrollo en

cuatro fases dentro de las cuales se realizan barias iteraciones.

2.2.32.1 Principios de desarrollo RUP

Adaptar el proceso:

Se refiere a la adaptación de los procesos a los requerimientos del cliente y

el alcance que deberá tener el proyecto como tal.

Equilibrar prioridades:

Encontrar un equilibrio que satisfaga los requerimientos de todos los

usuarios que manejaran un mismo sistema.

Demostrar valor iterativamente:

Al hablar de iteraciones en RUP, se refiere a la presentación del proyecto

por etapas iteradas y en cada iteración se analiza la opinión de los

inversores respecto a la calidad del producto, de tal forma que se logre


36

corregir y refinar su dirección en un tiempo justo, de acuerdo a la fase en la

que se encuentre su desarrollo.

Colaboración entre equipos:

Se refiere a la comunicación y coordinación que deberá existir entre las

personas involucradas en el desarrollo de un sistema.

Enfocarse en la calidad:

El control de calidad debe realizarse en todos los aspectos de la producción,

por ejemplo en calidad de arquitectura, código, modelo de base de datos,

equipos, etc.

2.2.32.2 Faces de la metodología RUP.

Figura 22. Fases de RUP

Fuente: Rational Unified Process. UDG. Obtenido de http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesRUP.pdf

1 Inicio: En esta fase es donde se reúne todos los requisitos o

requerimientos del usuario.

1.1 Requisitos de software

Entiende los servicios y restricciones que tiene un sistema.

1.1.1 Requisitos funcionales

Define lo que esperamos que deba hacer un sistema, se detalla los

servicios o funciones que proveerá un sistema.

1.1.2 Requisitos no funcionales


37

Define como debe ser un sistema, describe restricciones que limitan las

elecciones para construir una solución, por ende son atributos

relacionados con la calidad como: rendimiento, escalabilidad, fiabilidad,

disponibilidad, mantenimiento, seguridad, etc., por ejemplo el lenguaje

de programación java, una interfaz gráfica que garantice la fácil

navegabilidad y alta velocidad de procesamiento de datos.

2 Elaboración: En esta fase de desarrollo, es donde se construyen los

diagramas (casos de uso, actividad, secuencia, etc.), para

posteriormente construir la base de datos.

3 Construcción: En esta fase es donde pasamos a fabricar el producto

que vamos a mostrar al usuario con todos sus requerimientos, además

de que en esta etapa se realiza la implantación y las pruebas al mismo.

4 Transición: Durante esta fase de transición busca garantizar que se

tiene un producto preparado para su entrega al usuario.

2.2.32.3 Iteraciones en las fases de RUP

En la fase de inicio y elaboración, las iteraciones se enfocan en la

comprensión del problema, delimitación del proyecto, modelado de negocio,

tecnología a usar y establecimiento de la línea base de la arquitectura.

Las iteraciones en la fase de elaboración se orientan al desarrollo de una

línea base de arquitectura, refinamiento de modelado de negocio, análisis y

diseño del proyecto.

En la fase de construcción, se lleva a cabo la construcción del producto

mediante una serie de iteraciones.

La fase de transición intenta garantizar que el producto esté preparado para

su entrega a la organización o empresa cliente.

Como se puede observar en cada fase participan todas las disciplinas, pero

dependiendo de la fase el esfuerzo dedicado a una disciplina varía.


38

2.3 Identificación de variables2.3.1 Variables Independientes

No existencia de una aplicación web para la administración, prevención y

soporte del Sistema Nacional de Gestión de Prevención de Riesgos

laborales (SGP).

2.3.2 Variable Dependiente

Implementación de forma manual e ineficiente del SGP, invirtiendo

más tiempo y recursos.

Sanciones administrativas previstas en la Ley, por parte del Ministerio

de Relaciones Laborales.

2.4 Hipótesis

El no contar con una aplicación web para la administración, prevención y

soporte del SGP implica la implementación de forma manual e ineficiente del

SGP, invirtiendo más tiempo y recursos, poniendo en riesgo a la empresa de

sanciones administrativas previstas en la ley, por parte del Ministerio de

Relaciones Laborales.

2.5 Alcance

El diseño, desarrollo e implementación de una aplicación web para la

administración, prevención y soporte del SGP, servirá como un modelo o

prototipo para que QESCONSULTORES S.A. brinde sus servicios de forma

más organizada y eficaz a las empresas clientes del ecuador.

En el desarrollo del presente proyecto pretende cubrir con los siguientes

puntos:

Análisis: Analizar todas las funcionalidades que poseerá la aplicación

web manteniendo una coherencia con los requisitos de la empresa

QESCONSULTORES S.A.


39

Diseño: Con los requisitos obtenidos y analizados se diseñará la

aplicación web usando la metodología RUP.

Arquitectura: La aplicación web se desarrollará bajo la plataforma JEE

de software libre, usando framework’s como Spring e Hibernate para la

lógica de negocio y JSF para la capa de presentación del usuario y un motor

potente de base de datos como lo es Postgresql.

Desarrollo: La aplicación web a desarrollar contiene básicamente

cuatro procesos a automatizar:

La construcción de un gestor documental (Subida y descarga de

documentos referentes al SGP).

El envío de formularios para el cumplimiento del SGP por parte de las

empresas clientes ecuatorianas.

Revisión y corrección de formularios por parte de la empresa

consultora.

Generación de reportes de consultoría.

Implementación: La aplicación web se implementará en un servidor

local de la empresa QESCONSULTORES S.A. para que los usuarios hagan

uso de la misma realizando las respectivas pruebas y den solución sus

necesidades de negocio.


40

CAPÍTULO III

3 Marco Metodológico3.1 Análisis y Diseño de la Investigación

Para el desarrollo de la aplicación web se empleará la investigación

bibliográfica7 la cual ayudará a obtener tanto conocimientos técnicos como

metodológicos, irrefutablemente ordenados.

El proyecto también manejará la investigación de campo, ya que se

recolectará los datos e información de negocio directamente en la empresa

QESCONSULTORES S.A. y se realizará un diseño basado en sus

características.

3.1.1 Especificación de requisitos funcionales y no funcionales

En este punto se toma en cuenta la fase número uno de la metodología

RUP, la cual expone que un primer paso el mismo que pretende la reunión

de todos los requisitos o requerimientos del usuario.

Se fijaron varias reuniones para la toma de requerimientos funcionales con el

gerente general de la empresa QESCONSULTORES S.A. donde se

detallaron los servicios o funciones que proveerá la aplicación web para la

administración, prevención y soporte del SGP.

Tabla 4. Requisitos funcionales de la empresa QESCONSULTORES S.A.

Actores Opciones y funcionalidades asignadas

Empresa

consultora

Administración documental de grupos de normas jurídicas del SGP (Crear, ver,

actualizar y eliminar grupos).

Administración de soporte y seguimiento de casos (ver, actualizar).

Empresa cliente Administración documental de grupos de normas jurídicas del SGP (Ver grupos).

Administración de soporte y seguimiento de casos (Crear, ver, actualizar).

En la tabla 4, se exponen las opciones y funcionalidades asignadas a un

usuario dependiendo del tipo de empresa al que pertenece.

7 Investigación bibliográfica: Es el proceso de búsqueda de información en documentos paradeterminar cuál es el conocimiento existente en un área particular.


41

3.1.1.1 Casos de uso para la autenticación de usuarios.

Tabla 5. Caso de uso autenticación de usuarios

Caso de uso Ingresar al sistema.

Actor Empresa consultora y empresa cliente.

Propósito Acceder al sistema.

Resumen Ingresar al sistema, mediante un nombre de usuario y una

contraseña registrados en la base de datos.

Acción del actor Respuesta del sistema

Ingresar su usuario y

contraseña en la caja

de texto que se muestra

en una pantalla de

autenticación.

Si el usuario y contraseña son correctos el sistema permitirá el

acceso a los diferentes módulos u opciones, dependiendo del

tipo de usuario.

3.1.1.2 Casos de uso para la administración de grupos de normasjurídicas del SGP.

Tabla 6. Caso de uso consultar grupo de normas jurídicas del SGP

Caso de uso Consultar grupos de normas jurídicas del SGP8.

Actor Empresa consultora.

Propósito Administrar un gestor documental.

Resumen Podrá consultar grupos de normas jurídicas del

SGP y realizar operaciones como: Crear, ver,

actualizar y eliminar grupos.


En la ventana de administración

documental, el usuario podrá filtrar un

grupo de normas jurídicas del SGP, ya

sea por el nombre del grupo, por la

fecha o por código de clasificación.

Se desplegaran los grupos dependiendo del filtro

seleccionado por el usuario.

8 Un grupo de normas jurídicas del SGP contiene un conjunto de archivos referentes a una norma,ley, requisito o estándar que el SGP exige.


42

Tabla 7. Caso de uso para la creación de grupos de normas jurídicas del SGP

Caso de uso Crear nuevo grupo de normas jurídicas del SGP.


Propósito Crear nuevos grupos de normas jurídicas del SGP.

Resumen La empresa consultora puede crear un nuevo grupo para poder

agregar documentos relativos al tema.


Presionar el botón de

nuevo grupo.

Permitirá visualizar al usuario una pantalla para la creación de un

nuevo grupo en el cual le solicitará el ingreso de un nombre y una

descripción del para el grupo.

Tabla 8. Caso de uso para borrar grupos de normas jurídicas del SGP.

Caso de uso Borrar grupos de normas jurídicas del SGP.


Propósito Borrar grupos de normas.

Resumen Inactivar grupos de normas jurídicas del SGP en la base de

datos.


Seleccionar un grupo

mediante su vínculo y

pulsar el botón estado

inactivo.

El sistema muestra al usuario el grupo de normas a detalle y en

forma de edición, de tal manera que el usuario pueda inactivar

dicho grupo.

Tabla 9. Caso de uso editar contenido documental de grupo de normas jurídicas del SGP.

Caso de uso Editar contenido documental de grupo de normas jurídicas del

SGP.


Propósito Actualizar grupo de normas.

Resumen Modificar contenido de grupo de normas.



mediante su vínculo y

modificar información.

El sistema muestra al usuario el grupo de normas a detalle y en

forma de edición, de tal manera que el usuario pueda modificar

su contenido.


43

Tabla 10. Caso de uso nuevos documentos.

Caso de uso Cargar nuevos documentos.


Propósito Informar a las empresas clientes a cerca de las reformas de

normas del SGP o a su vez de nuevas normas.

Resumen Agregar nuevos documentos informativos en un grupo de normas

jurídicas del SGP.



de normas y pulsar el

botón nuevo archivo,

llenar la información

requerida y luego el

botón examinar.

El sistema muestra los archivos o documentos pertenecientes al

grupo de normas y en su cabecera existe un botón nuevo que el

usuario pulsó y el que le mostrará una pantalla solicitando un

nombre y una descripción para el nuevo documento y finalmente

el usuario debe pulsar el botón examinar para poder cargar el

archivo y guardarlo.

Tabla 11. Caso de uso descargar documentos

Caso de uso Descargar documentos.

Actor Empresa cliente.

Propósito Permitir la descarga de documentos a las empresas clientes,

para que estas adquieran información actualizada a cerca de

las normas jurídicas del SGP.

Resumen Las empresas clientes podrán descargar los documentos

subidos por la empresa consultora.


Consultar el grupo de

normas jurídicas de su

interés y presionar el botón

descargar.

Muestra al usuario el grupo seleccionado en detalle, dentro

del cual se pueden observar los documentos subidos por la

empresa consultora con la opción de descarga en cada uno.


44

3.1.1.3 Casos de uso para el soporte y seguimiento de casos.

Tabla 12. Caso de uso para crear un formulario.

Caso de uso Crear nuevo formulario.


Propósito Verificar si el formulario está correctamente implementado.

Resumen Las empresas clientes ecuatorianas podrán subir al sistema

formularios implementados con información que el SGP solicita,

de esta forma se realiza la respectiva revisión y corrección de los

mismos por parte de QESCONSULTORES S.A.


Presionar el botón

nuevo formulario.

El sistema muestra una pantalla para la creación de formularios,

existe un campo en la que el usuario puede seleccionar un tipo

de formulario y de esta forma se despliega un formulario vacío

para ser implementado.

Tabla 13. Caso de uso ver formularios revisados.

Caso de uso Ver formularios revisados.


Propósito Saber si el formulario está correctamente implementado para

tomarlo en cuenta al momento de implementar el SGP.

Resumen Saber cómo implementar el SGP.


Presionar el botón ver

formulario.

El sistema muestra el mismo formulario que la empresa cliente

envió, pero en estado revisado, lo cual indica que el formulario

fue examinado por la empresa consultora.


45

Tabla 14. Caso de uso consultar casos (formularios)

Caso de uso Consultar casos9 (formularios).


Propósito Ayudar a las empresas clientes a implementar el SGP.

Resumen La empresa podrá consultar todos los casos subidos al

sistema por las empresas clientes.


Consultar el caso de interés, esto

lo puede hacer mediante algunos

filtros, como el nombre del

cliente, número de soporte o por

la fecha de registro. Finalmente

debe presionar el botón buscar.

El sistema muestra al usuario un listado de casos de

soporte que corresponderán al filtro seleccionado.

Cada caso o formulario tendrá una acción de revisión.

Tabla 15. Caso de uso revisar caso (formulario)

Caso de uso Revisar caso.


Propósito Ayudar a las empresas clientes a implementar correctamente

cada formulario que el SGP solicita.

Resumen La empresa consultora revisará los formularios enviados por las

empresas clientes y planteará las respectivas correcciones si

fuera necesario.


Presionar un vínculo

revisar caso.

El sistema muestra al usuario un formulario lleno con información

de la empresa cliente, de tal forma que se podrá ver y revisar su

contenido.

9 Casos: Son las dudas, interrogantes o desconocimiento, que las empresas clientes tienen, respectoa cómo efectuar o llenar los formularios de información que el SGP.


46

Tabla 16. Caso de uso corregir caso (formulario)

Caso de uso Corregir caso.


Propósito Ayudar a las empresas clientes a implementar el SGP

correctamente.

Resumen La empresa consultora podrá editar el formulario subido por la

empresa cliente, explicando claramente que debe corregir.


Presionar un vínculo

revisar caso.

El sistema muestra al usuario un formulario y unas cajas de texto

donde la empresa consultora podrá escribir las observaciones

necesarias para que la empresa cliente pueda corregir sus

errores.

Tabla 17. Caso de uso validar caso (formulario)

Caso de uso Validar caso.


Propósito Subir correcciones en un formulario.

Resumen La empresa consultora podrá reenviar el formulario al cliente,

indicando que debe corregir.


Pulsar un botón validar

formulario.

El sistema actualizará la información del mismo formulario

enviado por el cliente con sus respectivas observaciones.


47

3.1.1.4 Lista de requisitos no funcionales para el desarrollo del sistema

Tabla 18. Requisitos no funcionales

N° Requisito Descripción

1 Rendimiento Se debe presentar la respuesta en tiempo real, es decir al instante en

el que se solicitó una tarea.

2 Funcionalidad El usuario podrá realizar cualquier acción que el sistema le presente.

3 Escalabilidad, El sistema tendrá la capacidad de permitir en el futuro el desarrollo de

nuevas funcionalidades.

4 Seguridad El sistema tendrá la parte de autenticación de usuarios, para rechazar

accesos no autorizados.

5 Validación En el sistema se definirá la obligatoriedad de campos, manejo de tipos

de datos y validación de contraseñas.

6 Lenguaje de

programación

El lenguaje de programación que se usará es java, ya que es de

fuente abierta e independiente de plataforma.

7 Interfaz

gráfica

Interfaz amigable, para el fácil manejo y navegabilidad en la

aplicación.

En la tabla 18, se puede observar los requisitos no funcionales que se

implementarán en el proyecto de investigación.

3.1.2 Diseño del wireframe para el proyecto

El diseño del wireframe ha sido muy importante en el desarrollo del sistema,

mediante el cual se ha logrado tener claro las funcionalidades y el

comportamiento a desarrollar.

Para la realización del wireframe se tomó en cuenta los siguientes puntos:

El tipo de información que será mostrada.

La funcionalidad que tendrá cada componente en la pantalla.

Relación o comunicación entre pantallas.


48

3.1.3 Comportamiento de la aplicación web3.1.3.1 Diseño del diagrama de casos de uso

A continuación y como parte del comportamiento de la aplicación web, se

presenta el diagrama de casos de uso generado después de haber tenido

una reunión de toma de requerimientos con QESCONSULTORES S.A. y en

el cual se basará el proyecto.

Figura 23. Diagrama de caso de uso para la autentificación de usuarios

En la figura 23 se puede observar un primer requisito funcional y que

también es un mecanismo de seguridad. Se trata del ingreso a la aplicación

web, donde los usuarios tanto empresa consultora como empresas clientes

pueden acceder al sistema, mediante un nombre de usuario y una

contraseña registrados en la base de datos.


49

Figura 24. Diagrama de casos de uso para el administrador del sistema

En la figura 24, se puede denotar, que el rol de un usuario de tipo

administrador es gestionar la creación y edición de usuarios y empresas. El

usuario administrador juega un papel muy importante en la empresa ya que

el manejo de clientes es importante en la lógica de procesos de consultoría.


50

Figura 25. Diagrama de caso de uso para la opción de administración documental

La figura 25, trata de la administración documental, que es la parte

consiguiente a la autenticación de usuarios, donde dependiendo del tipo de

usuario (empresa consultora, empresa cliente) que acceda al sistema, podrá

realizar ciertas acciones:

Si se trata de la empresa consultora, esta podrá consultar grupos de normas

jurídicas del SGP10 y realizar las siguientes operaciones:

Borrar un grupo de normas jurídicas del SGP: Al borrar un grupo de

normas, solo se inactivará dicho grupo, mas no se borrará de la base de

datos del sistema ya que es un requerimiento del departamento de auditoría

de sistemas que se mantenga toda la información desde su creación, para la

realización de análisis de datos y de esta forma, también el usuario empresa

consultora tendrá la opción de volver a activar dicho grupo.

Editar su contenido documental: Al hablar de edición de grupo normas

jurídicas del SGP, se entiende que sobre este grupo se puede modificar su

contenido, es decir la empresa consultora podría sustituir un archivo por otro.

10 Un grupo de normas jurídicas del SGP contiene un conjunto de archivos referentes a una norma,ley, requisito o estándar que el SGP exige.


51

Crear un nuevo documento: Puede crear un nuevo documento

registrando su nombre y descripción y cargando el respectivo archivo.

Crear un nuevo grupo normas jurídicas del SGP: La empresa

consultora puede crear un nuevo grupo para poder agregar documentos

relativos al tema.

Ahora si se trata de una empresa cliente, esta solo podrá consultar grupos

de normas jurídicas del SGP y también podrá ver y descargar los

documentos colgados en dichos grupos.

Figura 26. Diagrama de caso de uso para el soporte y seguimiento de casos

En proyecto también contiene un módulo de soporte y seguimiento de casos,

el cual se encarga de la administración de formularios que se explica a

continuación:

Si se trata de una empresa consultora ésta podrá administrar el soporte y

seguimiento de casos11de la siguiente manera:

Consultar casos: La empresa podrá consultar todos los casos subidos

al sistema por las empresas clientes.

11 Casos: Son las dudas, interrogantes o desconocimiento que las empresas clientes tienen, respectoa cómo efectuar o llenar los formularios de información que el SGP solicita a cada empresaecuatoriana.


52

Revisar caso: QESCONSULTORES S.A. podrá visualizar el formulario

con la información de la empresa cliente de modo que la empresa consultora

pueda efectuar la respectiva revisión del formulario subido y corregir errores

si los tuviera.

Corregir caso: La corrección del caso se la hace mediante

observaciones que la empresa consultora registra en el formulario

receptado.

Validar caso: Finalmente el caso receptado por QESCONSULTORES

S.A. es actualizado con las correcciones pertinentes.

Un usuario de tipo empresa cliente, podrá realizar las siguientes

operaciones:

Consultar casos: Podrá examinar sus casos expuestos y corregidos si

fuera el caso.

Crear nuevo caso: Logrará seleccionar el tipo de formulario del cual

tenga desconocimiento de implementación y llenarlo para solicitar ayuda a

QESCONSULTORES S.A.


53

3.1.3.2 Diseño del diagrama de actividades

[Incorrecto]

[Correcto]

[Externo][Interno]

[Opción1] [Opción2][Opción1] [Opción2]

Insertar usuario y clave

validación deusuario No ingresa al sistema

Tipo de usuarioMuestra panel de

opciones para empresacliente

Muestra panel deopciones para empresa

consultora

Opción subirdocumentos Opción revisión de casos

Opción registro de casosOpción descarga dedocumentos

Descargar documentos Crear formulariosRegistrar documentos Revisar y reenviar

formularios corregidos

Enviar formularios para revisión

Muestra panel deopciones para un usuario

administrador

Opción creación yactualización de usuarios

Opción creación y actualización de empresas

Figura 27. Diagrama de actividades general del sistema.

En la figura 27 se puede observar desde cómo un usuario puede acceder al

sistema. En un inicio el sistema solicitará información para validar su registro

en base de datos y luego poder verificar el tipo de usuario asociado,

dependiendo de este paso se podrá dar acceso a las opciones

correspondientes de cada usuario.

De esta manera se manejarán dos módulos, el módulo de administración

documental y el módulo de soporte y seguimiento de casos, los cuales se

explicaron a detalle en el diseño del diagrama de casos de uso.


54

3.1.3.3 Diseño de diagramas de secuencia

Autenticación de usuarios

Usuario o clave incorrecta.

Si no encuentra alusuario.

Mostrar panel de opciones dependiendo deltipo de usuario.

Cargar opciones

Si encuentra elusuario

Consulta usuario y su tipo (Interno,

externo).

Buscar usuario

Valida datosEnviar datos (Usuario y clave)

Muestra una pantalla de login

Ingresa a la aplicación web

Usuario

:Sistema Inicio :Login Base de datos :Opciones

Usuario o clave incorrecta.

Mostrar panel de opciones dependiendo deltipo de usuario.

Cargar opciones

Consulta usuario y su tipo (Interno,

externo).

Buscar usuario

Valida datosEnviar datos (Usuario y clave)

Muestra una pantalla de login

Ingresa a la aplicación web

Figura 28. Diagrama de secuencia para la autentificación de usuarios

El diagrama de secuencia para la autenticación de usuarios, trata

precisamente del registro o existencia de los mismos en la base de datos,

de tal forma que si se lo encuentra, éste tendrá acceso al sistema y

dependiendo del tipo de usuario asociado podrá visualizar sus respectivas

opciones.


55

Administración de usuarios

Mostrar mensaje de actualización correcta

Update del usuario

validar datos

Corregir datos

Muestra los datos guardados de un usuarioCarga información del usuario

Click en el botón edición de usuario

Modificar usuario

Creación deusuarios

Mostrar mensaje de guardado exitoso

Persistir datos

Validación de datosEnviar datos

Muestra pantalla a usuarioCarga información en componentes

Click en botón nuevo usuario

Crear usuario

Usuario administrador

Opción creación de usuarios Pantalla detalle usuariosNuevo usuario Base de datos

Edisión deusuarios

Edición usuario


Update del usuario

validar datos

Corregir datos

Muestra los datos guardados de un usuarioCarga información del usuario

Click en el botón edición de usuario

Modificar usuario


Persistir datos

Validación de datosEnviar datos

Muestra pantalla a usuarioCarga información en componentes

Click en botón nuevo usuario

Crear usuario

Figura 29. Diagrama de secuencia para la administración de usuarios

En la figura 29, se puede apreciar una administración de usuarios, la cual

consiste en la creación y edición de usuarios, en este caso el único usuario

que puede realizar estas operaciones en el sistema es un usuario con perfil

de administrador y es muy importante tomar en cuenta que éste usuario

debe pertenecer a una empresa calificada como consultora o de tipo interna

para lograr esta administración.


56

Administración de empresas

Crear empresa

Click en botón nueva empresa

Carga información en componentesMuestra pantalla al usuario

Enviar datos Validación de datos

Persistir datos


Modificar empresaClick en el botón edición de empresa

Carga información de empresaMuestra los datos guardados de unaempresa

Corregir datos

validar datos

Update del empresa


Creación deempresa

Usuario administrador

Opción creación de empresa Pantalla detalle empresaNueva empresa Base de datos

Edisión deempresa

Edición empresa

Crear empresa

Click en botón nueva empresa

Carga información en componentesMuestra pantalla al usuario

Enviar datos Validación de datos

Persistir datos


Modificar empresaClick en el botón edición de empresa

Carga información de empresaMuestra los datos guardados de unaempresa

Corregir datos

validar datos

Update del empresa


Figura 30. Diagrama de secuencia para la administración de empresas

En la figura 30, se puede apreciar una administración de empresas, la cual

consiste en la creación y edición de empresas, en este caso el único usuario

que puede realizar estas operaciones en el sistema es un usuario con perfil

de administrador y es muy importante tomar en cuenta que éste usuario

debe pertenecer a una empresa calificada como consultora o de tipo interna

para lograr esta administración.


57

Diagrama de creación de nuevos grupos de normas jurídicas

Norma guardada exitosamente

Datos guardados

Guardar norma

Validar datosEnviar datos de norma y cargar documento

(PDF,IMAGEN,WORD) respectivo.

Mostrar formulario de norma

Agregar normaAgregar normas agrupo creado

Mostrar el resultado en modovisual de la operación.

El grupo de normas juridicas del SGP seha creado correctamente

Grupo guardado

Si existe algún error notermina la operacón

Guardar grupo

Validar datosEnviar datos

Mostrar formulario

crearGrupo()Nuevo grupo

Empresa consultora

Opción subir documentos :Grupo Base de datos :Modo visual de Grupo :Norma


Norma guardada exitosamente

Datos guardados

Guardar norma

Validar datosEnviar datos de norma y cargar documento

(PDF,IMAGEN,WORD) respectivo.

Mostrar formulario de norma

Agregar norma

El grupo de normas juridicas del SGP seha creado correctamente

Grupo guardadoGuardar grupo

Validar datosEnviar datos

Mostrar formulario

crearGrupo()Nuevo grupo

Figura 31. Diagrama de secuencia para la creación de grupos de normas jurídicas del SGP

Para la creación de grupos es necesario que el usuario sea de tipo interno,

ya que de la carga de archivos en el gestor documental, se encarga

QESCONSULTORES S.A.


58

Descarga de documentos

Hace la consulta

El documento no ha sido encontrado

Dowload (Descarga completa)

Descargardocumentos

Consultar grupo

Mostrar grupo

Elegir y descargar norma de interés

buscar documento

Si no encuentra eldocumento

Empresa cliente

Opción descargar documentos :Grupo Base de datos

Si encuentra eldocumento

Hace la consulta

El documento no ha sido encontrado

Dowload (Descarga completa)

Descargardocumentos

Consultar grupo

Mostrar grupo

Elegir y descargar norma de interés

buscar documento

Figura 32. Diagrama de secuencia para la descarga de documentos.

Una empresa cliente puede descargar cualquier documento subido por

QESCONSULTORES S.A. y de esta forma, informarse correctamente sobre

la implementación del SGP.


59

Registro de casos

El formulario se actualizó correctamente.

Formulario actualizado

Actualizar datos

Validar datosModifica datos

Muestra formulario en forma de edición.

Editar formulario

formulario encontrado

Desplegar formularioConsultar formulario

Buscar formulario

Nuevo formulariocrearFormulario()

Mostrar formulario del caso

Enviar información de la empresa clienteValidar datos

Guardar formularioFormulario guardado

El formulario ha sido enviadocorrrectamente.

Modificar formulario.


Empresa cliente

Opción registro de casos :Formulario Base de datos :Modo visual de Formulario



Actualizar datos

Validar datosModifica datos


Editar formulario


Desplegar formularioConsultar formulario

Buscar formulario

Nuevo formulariocrearFormulario()


Enviar información de la empresa clienteValidar datos

Guardar formularioFormulario guardado


Figura 33. Diagrama de secuencia para el registro de casos (formularios)

En la figura 33 se puede observar como una empresa cliente puede crear y

modificar un formulario, para la respectiva revisión y asesoramiento de

QESCONSULTORES S.A.


60

Revisión de casos


Formulario guardadoGuardar formulario

Validar datosRevisar formulario y corregir formulario(l lenar observaciones)


buscar formularioVer formulario

Buscar formulario

Consultar formularioDesplegar formulario


Editar formulario


Modifica datos Validar datos

Actualizar datos




Modificar formulario.

Empresa empresa

Revisión de casos :Formulario Base de datos :Modo visual de Formulario


Formulario guardadoGuardar formulario

Validar datosRevisar formulario y corregir formulario(l lenar observaciones)


buscar formularioVer formulario

Buscar formulario

Consultar formularioDesplegar formulario


Editar formulario


Modifica datos Validar datos

Actualizar datos



Figura 34. Diagrama de secuencia para la revisión de casos (formularios)

Finalmente QESCONSULTORES S.A. revisa los formularios enviados por

sus clientes y los corrige si fuera el caso.


61

3.1.4 Estructura de la aplicación web3.1.4.1 Diseño del diagrama de componentes

MODELO: Contiene una representación de los datos quemaneja el sistema, su lógica de negocio, y sus mecanismos de

persistencia.M prjGestorClientprjGestorDocWeb

src

Framework JSF Framework Spring 3.1.0

Dependencia JPA 2.0

Class Mapping

ARQUITECTURA EMPRESARIAL JEE

controlador.javadataManager.java

WEB-INF

faces-config.xml web.xml

prjGestorCore

Framework Spring 3.1.0

Interfacegestores.java

gestorImpl.java

Spring Factory

InterfaceServicio.java

ConsultoraGestorBeans.xml

ConsultoraServicioBeans.xml

ConsultoraTransactionBeans.xml

Dependencia

Dependencia

ormConsultora.xmlPOJOS (Clases)

ServicioImpl.java

DAO.java

PostgreSQL 9.3

Hibernate3.6.1

.xhtml-1.xhtml-2

.xhtml-n

Paginas .xhtml

C

VsessionFactory.xml

Figura 35. Diagrama de componentes del proyecto

En el diagrama de componentes se observa la integración de frameworks.

La capa web o de presentación se implementa con el framework JSF 2.1 que

simplificará el desarrollo de la interfaz de usuario.

La capa de negocio empleará el framework spring 3.1.0, que provee soporte

para desarrollar aplicaciones empresariales en java.

La arquitectura del proyecto, empleará el patrón de diseño modelo, vista y

controlador (MVC), que se encargará de separar los datos, interfaz de

usuario y lógica de negocio en tres componentes.

Para el diseño de la arquitectura del proyecto a nivel de software, se ha

tomado en cuenta una alta cohesión y un bajo acoplamiento entre clases,

para lograr los siguientes objetivos: Fácil creación, facilidad de

mantenimiento y adaptación de mejoras.


62

gestor core.jar

Interface.gestores.java

Impl

Impl

gestorDoc.eargestor client.jar

Interface.Servicio.java

gestorDocDAO.jar

Database server

PostgreSQL9.3

Figura 36. Estructura y relación entre capas de presentación, negocios e integración.

Se entiende por acoplamiento, al grado en que una clase conoce a otras. Si

una clase A conoce a una clase B a través de interfaces, decimos que la

clase A y la clase B tienen un bajo acoplamiento. En cambio si la clase A se

basa en partes de una clase B directamente, es decir si se conocen pero sin

el uso de interfaces, entonces existiría un alto acoplamiento, por lo tanto no

sería óptima esta situación, ya que si se realiza un cambio en una de las

clases significaría un cambio en la otra.

La cohesión indica el grado en que una clase está enfocada a un objetivo,

por lo tanto si una clase tiene un único objetivo a tratar, decimos que existe

una alta cohesión, esto implica un fácil mantenimiento a nivel de clase, por

poseer definiciones puras y enfocadas a un solo tema.

3.1.4.2 Diseño del diagrama de paquetes

El presente proyecto adoptará una arquitectura JEE de 3 capas:

presentación, negocios y datos.

A continuación se detalla cada una de la capas a nivel de paquetes.


63

prjGestor-Client

WebContent

Paginas .xhtml

ec.uce.tesis.consultora.common.factory

ec.uce.tesis.consultora.dao

ec.uce.tesis.consultora.mdl.dto ec.uce.tesis.consultora.mdl.dto.id

ec.uce.tesis.consultora.servicio

prjGestor-Core

ec.uce.tesis.consultora.gestor

ec.uce.tesis.consultora.gestor.impl

ec.uce.tesis.consultora.servicio.impl

ec.uce.tesis.consultora.gestorDocDAO

prjGestorDoc-Web

ec.com.gestor.web.base.controller ec.com.gestor.web.basedatamanager

ec.com.gestor.web.commons.uti ls

ec.com.gestor.web.controller ec.com.gestor.web.datamanager

.xhtml 1

.xhtml 2

.xhtml n

PostgreSQL 9.3

Figura 37. Diagrama de paquetes para el proyecto.


64

Capa Web

En la figura podemos observar las paginas .xhtml, las cuales representan la

interfaz gráfica del usuario, y se encargan de recibir peticiones y desplegar

resultados.

Se ha definido el paquete ec.com.gestor.web.datamanager, el cual contiene

una clase que manipulará los valores de atributos de los beans establecidos

en el proyecto.

El paquete ec.com.gestor.web.controller, que actuará como un intermediario

entre la capa de modelo y la vista encargándose de gestionar las acciones

producidas por el usuario.

Capa Client

En el paquete ec.uce.tesis.consultora.common.factory se podrá encontrar la

clase Consultorafactory que se encarga de la inyección de dependencias y

abstracción de servicios empresariales.

En esta capa también se definirán los entity beans, que se los podrá

encontrar en el paquete ec.uce.tesis.consultora.mdl.dto, que ayudará a dar

una visión y acceso orientado a objetos de la base de datos relacional.

En el paquete ec.uce.tesis.consultora.servicio se establecen las definiciones

de los servicios que serán invocados desde la capa web, para la

implementación de la lógica de negocio.

Capa Core

En esta capa se ha definido la implementación de los servicios en el paquete

ec.uce.tesis.consultora.servicio.impl. En la implementación de los servicios

se podrá incluir inyecciones de dependencia que permitirá acceder a las

interfaces de la capa del gestor definida en el paquete

ec.uce.tesis.consultora.gestor, y respectivamente a su implementación, en la

que se implementa toda la lógica de negocio del proyecto.


65

3.1.4.3 Diseño del diagrama de despliegue

Keyboard/Monitor

HTTP

JDBC

HTTP

Workstation

Web browser

Application serverjboss-eap-6.2

gestorDoc.ear

gestor-client.jar

gestor-core.jar

gestorDocDAO.jar

PostgreSQL 9.3

Figura 38. Diagrama de despliegue del proyecto.

En la figura 38 se muestra una arquitectura conformada por una estación de

trabajo, un servidor de aplicaciones y una base de datos, también se ha

ilustrado la comunicación que existe entre componentes.

El usuario puede realizar la petición mediante un browser a la aplicación

web, esta petición es posible gracias al protocolo de comunicación HTTP12

encargado de la comunicación con un servidor de aplicaciones, en el que se

procesa toda la lógica de negocio, luego este servidor realiza la petición a

una base de datos a través de otro protocolo llamado JDBC, la base de

datos devuelve un resultado usando el mismo protocolo y de esta manera el

servidor de aplicaciones podrá garantizar al usuario una respuesta a su

solicitud.

12 HTTP: Significa protocolo de transferencia de hipertexto, es el protocolo usado en cadatransacción de la World Wide Web.


66

3.1.4.4 Diseño de diagrama de clases

TABLAS PARA EL MÓDULO DE FORMULARIOS

1..*

1

1..*

1

<<tiene>>

1

1

1..*

1

11

1

1..*

1..*

1

1 1

1..*1

<<Archivos de normas juridicas del SGP>>tblarchivo

codigoarchivonombrearchivotipoarchivocodigodocumentousuarioregistrocontenidotamanioarchivo

int4varchar(50)varchar(10)int4varchar(10)oidvarchar(20)

<pk>

<fk>

tblcatalogotipocodigotiponombredescripcionestadousuarioregistro

int4varchar(100)varchar(500)varchar(3)varchar(10)

<pk>

tblcatalogovalorcodigovalornombredescripcionestadocodigotipousuarioregistro

int4varchar(100)varchar(500)varchar(3)int4varchar(10)

<pk>

<fk>

<<Grupo de normas juridicas del SGP>>tbldocumento

codigodocumentotituloautornumeropaginasintroduccionestadocodigotipocodigovalorfechausuarioregistrocodigousuarioportada

int4varchar(200)varchar(100)int4varchar(500)varchar(3)NUMERICint4datevarchar(10)int4oid

<pk>

<fk1>

<fk2>

tblempresacodigoempresanombreempresausuarioregistrodireccionempresatelefonoempresamailempresaestadotipoempresa

int4varchar(50)varchar(10)varchar(100)varchar(20)varchar(50)varchar(3)VARCHAR(3)

<pk>

tblusuariocodigousuarionombreusuarioclaveusuarioestadousuarioregistrocodigoempresasuperusuario

int4varchar(10)textvarchar(3)varchar(10)int4varchar(3)

<pk>

<fk>

tblpreguntacodigopreguntadescripcionpreguntacatalogopreguntaestadotipopreguntacodigopreguntapadreusuarioregistrotipocomponente

int4VARCHAR(100)NUMERICvarchar(3)VARCHAR(4)varchar(100)int4int4

<pk>

<fk1>

tblformulariocodigoformulariocodigousuariofechaformulariotituloformularioestadoformulariousuarioregistroobservacion

int4int4datevarchar(100)varchar(3)varchar(10)VARCHAR(500)

<pk><fk>

tblformulariodetallecodigodetallecodigoformulariocodigopreguntarespuestavalidacionrespuestaobservaciónestadousuarioregistrocalificacion

int4int4int4varchar(200)varchar(200)VARCHAR(250)varchar(3)varchar(10)DECIMAL

<pk><fk2><fk1>

TABLAS PARA EL MÓDULO DEL GESTORDOCUMENTAL

TABLAS PARA USUARIOS

tblestadisticadocumentocodigoestadisticacodigodocumentonombreipnombremaquinafechahorasistemanombreeventousuarioregistrocodigousuario

NUMERICint4VARCHAR(50)VARCHAR(100)TIMESTAMPVARCHAR(50)VARCHAR(10)<Undefined>

<pk><fk>

Figura 39. Diagrama de clases del proyecto

En la figura 39 se observa el modelo de clases orientado a objetos y sus relaciones, que ayudaran a generar las tablas y constrains en un esquemadel SGDB postgreSQL.


67

3.1.5 Diseño de arquitectura de capas lógicas

Figura 40. Arquitectura de capas lógicas

En la figura 40, se observa las capas lógicas del sistema, a continuación la

explicación de cada capa en un nivel13:

3.1.5.1 Análisis de la implementación de capa de presentación

Nivel 1: La capa de presentación consistirá en el uso de cualquier equipo o

PC mediante el cual un usuario podrá acceder al sistema a través de un

navegador y editando la URL de la aplicación web previamente definida.

3.1.5.2 Análisis de la implementación de la capa de negocios

Nivel 2: A continuación mediante el protocolo HTTP, la capa de presentación

se comunica con la capa de negocios, es decir con el servidor de

aplicaciones (jboss-eap-6.2), donde se encuentra toda la lógica del negocio

codificada. En el alcance del proyecto se especifica, que el servidor de

aplicaciones residirá en un equipo local de la empresa QESCONSULTORES

S.A.

13 El término "nivel" corresponde a la forma en que las capas lógicas se encuentran distribuidas deforma física.


68

3.1.5.3 Análisis de la implementación de la capa de datos

Nivel 3: La capa de negocios se comunica con la capa de datos mediante el

protocolo de comunicación JDBC. De igual forma el sistema de gestión de

base de datos postgresSQL, será implementado en un equipo local de la

empresa QESCONSULTORES S.A.

3.1.6 ¿Por qué usar la Metodología RUP para el desarrollo de laaplicación web?

Se optó por esta metodología debido a que genera un alto nivel de calidad

asegurando así en cada una de las fases de desarrollo del proyecto el

cumplimiento de los objetivos establecidos. A su vez, es una metodología

ágil que permite integrar conjuntos de actividades y también, refina la

dirección del proyecto en cada una de las etapas, recopilando así,

sugerencias de las partes interesadas a lo largo de todos los procesos.


69

CAPÍTULO IV

4 Construcción del sistema4.1 Estándares de java

Se usarán los estándares de java para el desarrollo del proyecto, de manera

que el código sea fácil y rápido de entender, además al usar estándares se

garantiza un mantenimiento óptimo de código.

Las reglas que se seguirán para la escritura del código fuente en java son:

Tabla 19. Estándares java.

Estándares Convenciones Ejemplos

Archivos Nombres -Los nombres de archivos deben

tener extensión .java, deben ser

claros, simples y descriptivos.

Las clases tienen extensión .class

VideoTienda.java

Cliente.class

Organización En la organización de los archivos

se debe tomar en cuenta tres

aspectos:

1.- Comentarios de inicio:

suministrar la debida información

sobre el nombre de la clase, la

versión, fecha y copyright

2.- Sentencias package e import: La

primera sentencia es package y

después pueden seguir tantas

sentencias import como sean

necesarias.

3.- Declaraciones de interfaces y

clases: Se debe establecer un

orden.

-Comentario de documentación.

-Sentencia class o interface.

-Comentario de implementación.

-Variables de clase.

-Variables de instancia.

-Constructores.

-Métodos.

/*

*Clase Cliente

*Versión1

*8 de Marzo de 2014

*Diana Chochos

*/

Package VideoTienda;

Import java.io.Serializable;

Import java.awt.*;


70

Indentación Consiste en mover un bloque de texto a la derecha,

de esta manera se mejora la legibilidad del código.

Comentarios Comentarios de bloque: Son usados al comienzo de

cada método o en el interior de estos, con el

objetivo de dar una descripción de los mismos.

Están precedidos de una línea en blanco.

Comentarios de una línea: Son comentarios cortos

endentados a nivel de la línea de código que sigue

y precedidos por una línea en blanco.

Comentarios de aclaración: Aparecen en una

misma línea de código, pero comentado y se

escriben en una misma distancia, de modo que no

se confunda con el código.

Paquetes Los nombres de paquetes se los representa en

minúsculas con dominio de alto nivel,

En el actual proyecto un paquete está definido de la

siguiente forma:

Primero el nombre del país ec = Ecuador, luego el

nombre de la universidad uce = universidad central

del Ecuador, finalmente de que se trata el proyecto

“tesis” y el contexto del sistema “consultora”.

Ejemplo de nombre de paquete:

ec.uce.tesis.consultora

Clases e

Interfaces

Los nombres de clases siempre deben iniciar con

letra mayúscula y si es más de una palabra se debe

intercalar entre minúsculas y mayúsculas, este

mecanismo se lo conoce como camelCase.

Usando la norma camelCase:

NotaDeCrédito

IconsultoraServicio

Métodos En los métodos la primera letra debe ser en

minúscula, debe ser un verbo descriptivo y de igual

forma usa la camel si tiene más de una palabra.

crearCaso();

actualizarCaso();

Constantes Las variables que son constantes deben ser

escritas en mayúsculas y si son más de dos

palabras estas deben separarse por un guion bajo.

ANCHO_MINIMO;


71

4.2 Implementación de las capas a nivel de software

Para la implementación de las capas lógicas a nivel de software se tomó en

cuenta el uso de los estándares java mencionados anteriormente y los

framewors integrados a la arquitectura del proyecto.

4.2.1 Implementación de la capa de modelo4.2.1.1 Implementación del bean factory en el proyecto

El bean factory es un contenedor que asume la inyección de dependencias.

El siguiente código se encarga de inicializar todos los beans del proyecto, en

forma ordenada y resolver la dependencia de cada uno de ellos, es decir

spring gestionará todo el ciclo de vida de la aplicación.

Se observa la implementación del ApplicationContext que se basa o

implementa del bean factory, el cual provee una interfaz para la

configuración de la aplicación que contiene y maneja el ciclo de vida de cada

bean.

A continuación se presenta la implementación del bean factory en el

proyecto:

package ec.uce.tesis.consultora.common.factory;import org.springframework.context.ApplicationContext;import org.springframework.context.support.GenericXmlApplicationContext;import org.springframework.core.env.ConfigurableEnvironment;import ec.com.sysma.simple.dao.commons.constants.DaoFactoryConstants;import ec.uce.tesis.consultora.common.util.ConsultoraLogger;import ec.uce.tesis.consultora.servicio.IConsultoraServicio;

public class ConsultoraFactory {private static final ConsultoraFactory INSTANCIA = new

ConsultoraFactory();private transient final ApplicationContext contextoAplicacion;/*** Rutas de las configuraciones de Spring*/

private transient final String[] pathsContexto = new String[]{FactoryConstantes.CONTEXT_CONSULTORA_GESTOR_BEANS,FactoryConstantes.CONTEXT_CONSULTORA_SERVICE_BEANS,FactoryConstantes.CONTEXT_CONSULTORA_SESSION_FACTORY_BEANS,FactoryConstantes.CONTEXT_CONSULTORA_TRANSACTION_BEAN,FactoryConstantes.CONTEXT_CONSULTORA_ENVIRONMENT_BEANS,DaoFactoryConstants.SERVICE_CONTEXTPATH

};

private ConsultoraFactory(){final GenericXmlApplicationContext ctx = new

GenericXmlApplicationContext();final ConfigurableEnvironment env = ctx.getEnvironment();


72

env.setActiveProfiles("CONSOLA");ConsultoraLogger.log.info("Ambiente:{}","CONSOLA");ctx.load(pathsContexto);ctx.refresh();contextoAplicacion = ctx;

}/*** @return the instancia*/

public static ConsultoraFactory getInstancia() {return INSTANCIA;

}

public static Object getBean(String bean){return INSTANCIA.contextoAplicacion.getBean(bean);

}

public IConsultoraServicio getConsultoraServicio(){return

contextoAplicacion.getBean(FactoryConstantes.ACCESO_SISTEMA,IConsultoraServicio.class);

}}

4.2.1.2 Implementación de Entity’s

Para la automatización de la persistencia de los objetos en la base de

datos, se ha partido primero de clases a nivel de POJOs, es decir de

clases base java con información de las entidades a ser persistidas.

Todas las clases deben implementar la interfaz Serializable con el

objetivo de poder enviar las instancias de las clases por un canal para su

posterior consumo.

Luego se implementó un modelo de persistencia con anotaciones JPA

como se observa en el código siguiente.

Ejemplo de persistencia con la clase Usuario:

package ec.uce.tesis.consultora.mdl.dto;

import javax.persistence.Column;import javax.persistence.Entity;import javax.persistence.FetchType;import javax.persistence.JoinColumn;import javax.persistence.JoinColumns;import javax.persistence.ManyToOne;import javax.persistence.Table;import ec.com.sysma.simple.dao.commons.annotations.ComparatorTypeField;import ec.com.sysma.simple.dao.commons.dto.AuditoriaBaseDTO;import ec.com.sysma.simple.dao.commons.enumeration.ComparatorTypeEnum;import ec.uce.tesis.consultora.mdl.dto.id.UsuarioID;


73

/*** Permite gestionar la información correspondiente a UsuarioDTO.* @author dchochos*/

@SuppressWarnings("serial")@Entity(name="ec.uce.tesis.consultora.mdl.dto.UsuarioDTO")@Table(name="tblusuario")public class UsuarioDTO extends AuditoriaBaseDTO<UsuarioID>{

/*** Especifica el nombre usuario*/

@Column(name="nombreusuario")@ComparatorTypeField(comparatorType=ComparatorTypeEnum.EQUAL_COMPARATOR)private String nombreUsuario;

/*** Especifica la clave usuario*/

@Column(name="claveusuario")@ComparatorTypeField(comparatorType=ComparatorTypeEnum.EQUAL_COMPARATOR)private String claveUsuario;

/*** Especifica el tipo usuario*/

@Column(name="tipousuario")@ComparatorTypeField(comparatorType=ComparatorTypeEnum.EQUAL_COMPARATOR)private String tipoUsuario;

/*** Especifica el estado usuario*/

@Column(name="estado")@ComparatorTypeField(comparatorType=ComparatorTypeEnum.EQUAL_COMPARATOR)private String estado;

/*** Especifica el estado usuario*/

@Column(name="empresa")@ComparatorTypeField(comparatorType=ComparatorTypeEnum.EQUAL_COMPARATOR)private String empresa;

/*** Empresa al que pertenece el usuario*/

@ManyToOne(fetch=FetchType.LAZY)@JoinColumns({@JoinColumn(name="empresa",referencedColumnName="codigoempr

esa",insertable=false,updatable=false)})private EmpresaDTO empresaDTO;

/*** @return the nombreUsuario*/

public String getNombreUsuario() {return nombreUsuario;

}

/*** @param nombreUsuario the nombreUsuario to set*/

public void setNombreUsuario(String nombreUsuario) {this.nombreUsuario = nombreUsuario;

}

/*** @return the claveUsuario*/

public String getClaveUsuario() {return claveUsuario;


74

}

/*** @param claveUsuario the claveUsuario to set*/

public void setClaveUsuario(String claveUsuario) {this.claveUsuario = claveUsuario;

}

/*** @return the tipoUsuario*/

public String getTipoUsuario() {return tipoUsuario;

}

/*** @param tipoUsuario the tipoUsuario to set*/

public void setTipoUsuario(String tipoUsuario) {this.tipoUsuario = tipoUsuario;

}

/*** @return the estado*/

public String getEstado() {return estado;

}

/*** @param estado the estado to set*/

public void setEstado(String estado) {this.estado = estado;

}

/*** @return the empresa*/

public String getEmpresa() {return empresa;

}

/*** @param empresa the empresa to set*/

public void setEmpresa(String empresa) {this.empresa = empresa;

}

/*** @return the empresaDTO*/

public EmpresaDTO getEmpresaDTO() {return empresaDTO;

}

/*** @param empresaDTO the empresaDTO to set*/

public void setEmpresaDTO(EmpresaDTO empresaDTO) {this.empresaDTO = empresaDTO;

}}


75

4.2.1.3 Implementación de los id’s de entity’s

Esta clase se encarga de encapsular las propiedades identificadoras de la

clase usuario, que se ha usado como ejemplo.

package ec.uce.tesis.consultora.mdl.dto.id;

import javax.persistence.Column;import javax.persistence.Embeddable;import ec.com.sysma.simple.dao.commons.annotations.SequenceDataBaseValue;import ec.com.sysma.simple.dao.commons.dto.id.BaseID;import ec.uce.tesis.consultora.common.util.Secuencias;

/*** Clase que encapsula a las propiedades Identificadoras de la claseUsuarioDTO* @see ec.uce.tesis.consultora.mdl.dto.UsuarioDTO** @author dchochos*/@Embeddable@SuppressWarnings("serial")public class UsuarioID extends BaseID {

/*** Especifica el codigo usuario*/@Column(name="codigousuario")@SequenceDataBaseValue(descriptorClass=Secuencias.class,name="sequsua

rio")private Integer codigoUsuario;

public Integer getCodigoUsuario() {return codigoUsuario;

}

public void setCodigoUsuario(Integer codigoUsuario) {this.codigoUsuario = codigoUsuario;

}}

4.2.1.4 Definición de servicios

Se define una interface de servicios que dará paso a la utilización de la

implementación de la lógica de negocio.

package ec.uce.tesis.consultora.servicio;import java.util.Collection;import ec.uce.tesis.consultora.exception.ConsultoraException;import ec.uce.tesis.consultora.mdl.dto.DocumentoDTO;import ec.uce.tesis.consultora.mdl.dto.UsuarioDTO;

public interface IConsultoraServicio{/*** verifica el usuario ingresado* @param usuarioDTO* @throws ConsultoraException*/

public UsuarioDTO verificarUsuario(UsuarioDTO usuarioDTO) throwsConsultoraException}


76

4.2.2 Implementación de la capa lógica4.2.2.1 Implementación de los servicios

En la implementación de los servicios se ha inyectado la capa del gestor que

es donde se encuentra toda la lógica de negocio del proyecto.

Es importante también definir los métodos setters, ya que spring permite la

inyección de dependencias a los beans mediante estos métodos.

package ec.uce.tesis.consultora.servicio.impl;import java.util.Collection;import ec.uce.tesis.consultora.exception.ConsultoraException;import ec.uce.tesis.consultora.gestor.IGestorConsultora;import ec.uce.tesis.consultora.mdl.dto.DocumentoDTO;import ec.uce.tesis.consultora.mdl.dto.UsuarioDTO;import ec.uce.tesis.consultora.servicio.IConsultoraServicio;

public class ConsultoraServicio implements IConsultoraServicio {

private IGestorConsultora gestorConsultora;

/*** verifica el usuario ingresado* @param usuarioDTO* @throws ConsultoraException*/public UsuarioDTO verificarUsuario(UsuarioDTO usuarioDTO) throws

ConsultoraException{return gestorConsultora.verificarUsuario(usuarioDTO);

}

public void setGestorConsultora(IGestorConsultora gestorConsultora) {this.gestorConsultora = gestorConsultora;

}}

4.2.2.2 Definición de los gestores

En el código siguiente se puede apreciar la interface del gestor del proyecto,

mediante la cual se podrá permitir la dirección a su implementación.

package ec.uce.tesis.consultora.gestor;

import java.util.Collection;import ec.uce.tesis.consultora.exception.ConsultoraException;import ec.uce.tesis.consultora.mdl.dto.DocumentoDTO;import ec.uce.tesis.consultora.mdl.dto.UsuarioDTO;

public interface IGestorConsultora {/*** verifica el usuario ingresado* @param usuarioDTO* @throws ConsultoraException*/public UsuarioDTO verificarUsuario(UsuarioDTO usuarioDTO) throws

ConsultoraException;}


77

4.2.2.3 Implementación de los gestores

Finalmente en esta parte se observa la lógica de negocio en sí del proyecto.

También se inyecta una dependencia (GestorDocDAO), para poder realizar

las operaciones CRUD contra la base de datos y para lograr esto se uso el

framework Hibernate.

package ec.uce.tesis.consultora.gestor.impl;

import java.util.Collection;import ec.com.sysma.simple.dao.commons.gestor.GestorDocDAO;import ec.uce.tesis.consultora.exception.ConsultoraException;import ec.uce.tesis.consultora.gestor.IGestorConsultora;import ec.uce.tesis.consultora.mdl.dto.DocumentoDTO;import ec.uce.tesis.consultora.mdl.dto.UsuarioDTO;

public class GestorConsultora implements IGestorConsultora {

private GestorDocDAO gestorDocDAO;/*** verifica el usuario ingresado* @param usuarioDTO* @throws ConsultoraException*/

public UsuarioDTO verificarUsuario(UsuarioDTO usuarioDTO) throwsConsultoraException{

UsuarioDTO usuarioFind = gestorDocDAO.encontrarUnico(usuarioDTO);return usuarioFind;

}

public void set GestorDocDAO (GestorDocDAO gestorDocDAO) {this.gestorDocDAO = gestorDocDAO;

}}

A continuación se representa con un diagrama la secuencia de las llamadas

de métodos atravesando cada una de las capas definidas en la arquitectura

del sistema.


78

Diagrama de secuencia para la autenticación de usuario

Consultarealizada

Devuelve resultado

Consultar

Llamar a laconsultarequerida

Validar tipode datos

Informar registro encontrado respuesta del

servicioRespuesta del

gestor

Llamar al gestor deverificación de

usuarios

Usar servicioverificar usuario

Enviar datos

Ingresarusuario y

contraseña

Empresa

Interfaz gráfica de usuario controller

Administración deservicios

Administración degestor

Administración deservicios de datos

Administración depersistencia

Consultarealizada

Devuelve resultado

Consultar

Llamar a laconsultarequerida

Validar tipode datos

Informar registro encontrado respuesta del

servicioRespuesta del

gestor

Llamar al gestor deverificación de

usuarios

Usar servicioverificar usuario

Enviar datos

Ingresarusuario y

contraseña

Figura 41. Diagrama de secuencia para la autenticación de usuarios, detallando capas de servicios,gestor y persistencia.

4.2.2.4 Definición de beans en spring

A diferencia de los beans convencionales que representan una clase, la

característica de los beans de Spring es que son objetos creados y

manipulados por el contenedor Spring. Este contenedor carga las

definiciones de los beans escritos en archivos XML.

4.2.2.5 Mapeo de servicios

Figura 42. Mapeo de servicios

En la figura 42 se observa el mapeo de la clase que contiene los servicios y

su respectiva inyección de dependencia.


79

4.2.2.6 Mapeo de gestores

Figura 43. Mapeo de gestores

En la figura 43 se observa el mapeo de la clase que contiene la

implementación de la lógica de negocio del sistema y su inyección de

dependencia para realizar las operaciones contra la base de datos.

4.2.2.7 Transacciones con spring

Figura 44. Transacciones con spring

La figura 44 describe como se puede controlar la vuelta atrás (rollback) de

las transacciones. Para indicar a la infraestructura de transacción de spring

que el trabajo de una transacción debe revertirse se define una excepción de

código que se ejecutará en el contexto de la transacción.

Se ha definido un fragmento que indica cómo se puede configurar una marca

de rollback-for en el archivo de configuración XML, sobre un tipo de

excepción determinada, en este caso se define una excepción

ConsultoraException para métodos que inicien con la palabra trans.


80

También se ha definido un punto de corte (pointcut de Spring AOP), para

interceptar todos los métodos de la capa de servicio.

4.2.2.8 Configuración del DataSource en spring

Figura 45. Configuración del DataSource en spring

En la figura 45 se denota la configuración de la fuente de datos

(DataSource). Se define la conexión con el SGBD mediante el driver de

postgres y el direccionamiento al esquema de datos.

4.2.2.9 Configuración del sessionFactory con spring

Figura 46. SessionFactory con spring


81

En la figura se define un bean sessionFactory, en el que se mapea las

propiedades de hibernate y la lista de entidades a ser usadas en el proyecto.

4.2.2.10 Implementación del orm del proyecto

Figura 47. Implementación del orm de la aplicación

En la figura 47 se observa el mapeo de entidades y sus respectivas claves

primarias.

4.2.3 Implementación de la capa web4.2.3.1 Implementación de las paginas .xhtml

En el siguiente código se observa la implementación de la autenticación de

usuarios usando richfaces, primefaces y html. En el ejemplo se hace

referencia al bean loginController y éste debe tener un método denominado

login, el cual se encargará de permitir o no el acceso al sistema.

<ui:composition xmlns="http://www.w3.org/1999/xhtml"xmlns:ui="http://java.sun.com/jsf/facelets"xmlns:f="http://java.sun.com/jsf/core"xmlns:h="http://java.sun.com/jsf/html"xmlns:a4j="http://richfaces.org/a4j"xmlns:rich="http://richfaces.org/rich"xmlns:p="http://primefaces.org/ui"xmlns:c="http://java.sun.com/jsp/jstl/core"xmlns:s="http://java.sun.com/jsf/composite/components"template="/templates/pageLayoutLogin.xhtml">

<ui:param name="idForm" value="frmLogin" /><ui:param name="controller" value="#{loginController}" /><ui:param name="form" value="#{loginController.form}" />

<ui:define name="contentBody"><style>

.espacio1 {width: 20% !important;

}


82

.espacio2 {width: 40% !important;

}</style>

<h:panelGrid id="pnlPrincipal" columns="3" cellpadding="0"cellspacing="0" columnClasses="espacio2, espacio1, espacio2"style="vertical-align:middle; border:none !important; width: 100% !important;height:490px !important"><h:panelGroup layout="block" /><h:panelGroup layout="block" style="float:center;">

<center><h:panelGroup layout="block"

style="float:center; height:150px !important"><center>

<h:graphicImage library="image" name="uce.png" /></center>

</h:panelGroup><p:panelGrid id="panelGridLogin" columns="2">

<f:facet name="header">Login

</f:facet><h:outputLabel value="Usuario: *" /><p:inputText id="idUsuario" value="#{loginController.nomUsuario}"

required="true"requiredMessage="El nombre de usuario es requerido" />

<h:outputText value="Clave: *" /><p:password id="idPasswd" value="#{loginController.claUsuario}"

required="true"requiredMessage="El Password del usuario es requerido" />

</p:panelGrid><h:panelGroup style="float:right;margin-top:3px; margin-right:10px">

<p:commandButton id="btnEntrar" action="#{loginController.login}"update=":frmLogin:mensajesLogin, :frmLogin:pnlPrincipal"process="@this :frmLogin:idUsuario :frmLogin:idPasswd"value="Ingresar" ajax="true" />

</h:panelGroup></center>

</h:panelGroup><h:panelGroup layout="block" />

</h:panelGrid></ui:define></ui:composition>

4.2.3.2 Implementación de controladores

Figura 48. Implementación del controlador para la capa de presentación.


83

Figura 49. Implementación del dataManager para la capa de presentación.

En la figura 48 y 49 se definen los controladores de la capa de presentación,

los que se encargaran de interpretar las acciones introducidas por el usuario

y darán paso al uso de los servicios implementados en la capa de negocio.


84

CAPÍTULO V

5 Conclusiones y recomendaciones5.1 Conclusiones

La investigación de campo fue la clave fundamental para la

recolección de información del proceso de negocio de QESCONSULTORES

S.A.

QESCONSULTORES S.A mejorará sus servicios sustancialmente,

gracias a la automatización de procesos de negocio de asesoría y

consultoría.

Las ventajas de implementar una aplicación web en

QESCONSULTORES S.A. son: La optima comunicación entre empresa

consultora y clientes; la integración, centralización y almacenamiento

ordenado de la información y claridad en los procesos.

Los factores que están asociados a la satisfacción del cliente son: El

tiempo de entrega del servicio, la calidad del producto final, información

clara, correcta y precisa y el compromiso con el cliente.

La metodología RUP ayudó a generar un alto nivel de calidad de

software, siguiendo cada una de las fases de desarrollo y cumpliendo con

los objetivos establecidos. La calidad de la aplicación web se logró con la

presentación del proyecto por etapas iteradas ya que en cada iteración se

analizó la opinión de los inversores respecto al desarrollo del producto, de tal

forma que se logró corregir y refinar el software en un tiempo justo.

En un futuro se podrá adaptar a la aplicación web más

funcionalidades o requerimientos funcionales a nivel de software, ya que

para su desarrollo se ha tomado en cuenta el uso de patrones de diseño,

frameworks, alta cohesión y bajo acoplamiento de clases y estándares de

programación, lo cual facilitará la creación de nuevos módulos sin que esto

afecte al resto de programación.


85

El modelo de datos basado en la abstracción de procesos de negocio de la

empresa y la construcción de artefactos para modelar íntegramente dicho

negocio, asegurará que el modelo también soporte cambios en un futuro.

5.2 Recomendaciones

Se recomienda siempre desarrollar e implementar un sistema

informático con una metodología de desarrollo de software, con el fin de

crear productos con calidad, optimizar tiempo y minimizar riesgos.

Es importante listar casos de uso como punto de partida para la

construcción de diagramas UML y la definición de arquitectura lógica para el

proyecto.

Construir diagramas UML, para facilitar el desarrollo del modelo de

datos y la definición de la interfaz de usuario final.

Tomar en cuenta la alta cohesión y el bajo acoplamiento en las clases

para poder reutilizar código.

Es recomendable usar el framework MVC, porque ayuda a separar la

parte gráfica o de presentación (V) de la parte de manejo de acciones (C) y

de la parte de la lógica de negocio (M). De este modo también se logrará la

reutilización de código.

Usar frameworks para simplificar el desarrollo de aplicaciones web en

java.


86

Marco Administrativo

Presupuesto

La estimación del presupuesto se detalla en la siguiente tabla:

Número DETALLE CANTIDAD VALORUNITARIO

VALORTOTAL

1

RECURSOSTECNOLÓGICOS

Disco externo usb. 1 165 165.00

CD’s 6 0.80 4,80

Servicios de internet 100 1.00 100.00

Laptop Lenovo i7 1 1000.00 1000.00

Subtotal 1269.80

2

RECURSOS PERSONALES MESESTransporte

6 60.00 360.00

Alimentación6 60.00 360.00

Imprevistos 6 30.00 180.00

Subtotal 900,00

3

RECURSOS MATERIALESResma de papel 3 5.00 15.00

Tinta para impresora 4 6.00 24.00

Copias 600 0,04 24.00

Folders, sobres de manila,

anillados, lápices, cuadernos y

otros. 100.00

MATERIAL BIBLIOGRÁFICOEmpastado de trabajo de grado 1 100.00 100.00

Subtotal 263.00

TOTAL GASTOS 2432,80

Imprevistos (5%) 121,64

TOTAL DE PRESUPUESTO 2554,44


87

Cronograma


88


89


90

Bibliografía

1. KROENKE, David m. Procesamientos de bases de datos. Octavaedicion. México. ISBN, 2003. 688.

2. CORTES MORALES, Roberto. Introducción al análisis de sistemas yla ingeniería de software. Segunda edición. España S.A, 1992.340.

3. IVAR JACOBSON, Grady Booch. El proceso unificado de desarrollode software. Madrid. CLM, 2000. 530.

4. TONDREAU CAÑAS, Carlos Francisco. Proceso de desarrollo deaplicaciones web basado en metodología RUP. PUCH, 2002.

5. DURÁN, F., GUTIERREZ, F., & PIMENTEL, E. Programación orintadaa objetos. Segunda edición. Madrid. Librotex, 2007. 302.

6. GROUSSARD, Thierry. Los fundamentos del lenguaje Java. Primeraedición. Barcelona. ENI, 2012. 387.

7. GONZLEZ RUIZ, Pedro Mateo. Prevención de riesgos laborales.Primera edición. Madrid. FC Editorial, 2010. 207.

8. GUTIERREZ, Felipe. Spring Framework. Primera edición. 2008. 252

9. ARELLANO, A. P. (s.f.). SGP. Obtenido dehttp://www.bustamanteybustamante.com.ec/articulos-de-interes/300-implementacion-del-sistema-nacional-de-gestion-de-prevencion-de-riesgos-laborales-sgp

10. CEDES. (2010). Estándar de codificación Java. Obtenido dehttp://www.aves.edu.co/ovaunicor/recursos/view/265

11. CEPRIT. (2013). Centro de preveción de riesgos en el trabajo.Obtenido de http://www.essalud.gob.pe/downloads/ceprit/BoletinCPR03_.pdf

12. MATEPSS, M. (11 de 2010). Boletín de Prevención de RiesgosLaborales. Obtenido de http://www.maz.es/prevencion/boletin-prl/Boletines%20PRL/prevencion_n4/formacion.htm

13. RIOJA, U. (s.f.). Servicio de Prevención de Riesgos Laborales.Obtenido de https://www.unirioja.es/servicios/sprl/pdf/guia_oficinas.pdf


91

Glosario de términos

Asesoría: Informa que se debe hacer.

El asesor ayuda a descubrir problemas, pero frecuentemente dirige a sus

clientes hacia quien pueda ayudar a resolverlos.

Consultoría: Resuelven el problema.

La consultoría se considera típicamente un proceso para ayudar a una

compañía a descubrir un problema en específico y llegar a una solución.

Soporte: Persona o cosa que sirve de apoyo, base o ayuda.

Técnico: Persona que posee los conocimientos específicos sobre una

ciencia, un arte o un oficio.

Gestión: Hacer los trámites o diligencias necesarios para resolver un

asunto.

Administración: Ordenar u organizar determinada cosa o situación.

Metadato: Son datos que describen otros datos.

Mutua: Sociedad de socorros mutuos.

Mutuas de Accidentes de Trabajo y Enfermedades Profesionales: Son

asociaciones empresariales sin fines de lucro que, debidamente autorizadas

por el ministerio de empleo y seguridad social y bajo su dirección y tutela,

tienen por objeto la gestión de las contingencias de accidentes de trabajo y

enfermedades profesionales de los trabajadores.

Plan mínimo de prevención de riesgos: Tiene la misma función que el

Reglamento de seguridad y salud pero es a menor escala.

Norma jurídica: Regla que regula el comportamiento de los individuos en la

sociedad y cuyo incumplimiento se encuentra sancionado.


92

Anexos


93

Anexo 1. Implementación del proyecto en QESCONSULTORES S.A

Anexo 1.1 Plan de pruebas


94

Anexo 1.2 Acta de aceptación del proyecto


95

Anexo 1.3 Certificación de implementación de proyecto


96

Anexo 2. Diccionario de datos

Nombre: tblusuarioDescripción: En esta tabla se registraran todos los usuarios

que tendrán acceso al sistema.

Constrains:

Atributos Tipo Largo Restricciones Descripción

codigousuario integer NOT NULL Identificador de la tabla usuario.

nombreusuario character 10 NOT NULL Nombre del usuario.

claveusuario text NOT NULL Clave o password del usuario.

estado character 3 NOT NULL Indica si el estado es activo (ACT) o

inactivo (INA).

usuarioregistro character 10 Registra a la persona que crea o modifica

objetos en el sistema.

codigoempresa integer NOT NULL Llave foránea de la tabla.

superusuario varchar 3 Campo que indica si una persona podrá

administrar usuarios y empresas.

Nombre: tbldocumentoDescripción: Esta tabla representa un documento de normas

jurídicas, el cual podrá tener varios archivos relacionados

adjuntos.

Constrains:


codigodocumento integer NOT NULL Identificador de la tabla documento.

titulo character 200 NOT NULL Titulo del grupo de normas jurídicas del

SGP.

autor character 100 NOT NULL Nombre del autor del grupo de normas.

numeropaginas iteger NOT NULL Número de páginas del grupo de

normas.

introduccion character 500 Indica de qué se trata el grupo de

normas.

estado character 3 El estado indica si un grupo de normas

jurídicas del SGP está activo o inactivo

(ACT) e (INA) respectivamente.


97

codigotipo Integer NOT NULL

Indica el tipo de catalogo relacionado

con el documento

codigovalor integer NOT NULL

Indica el catálogo al que pertenece el

grupo de normas jurídicas del SGP.

fecha date NOT NULL Fecha en la que se crea el grupo de

normas.

usuarioregistro character 10 Registra a la persona que crea o

modifica objetos en el sistema.

codigousuario integer NOT NULL Usuario que subió el grupo de normas

jurídicas del SGP.

portada oid Es una imagen relacionada al título del

documento.

Nombre: tblarchivoDescripción: Son los archivos de normas jurídicas del SGP que

puede tener cada documento (grupo de normas jurídicas del

SGP).

Constrains:


codigoarchivo integer NOT NULL Identificador de la tabla archivo (PK).

nombrearchivo character 50 NOT NULL Nombre del archivo.

tipoarchivo character 10 NOT NULL Indica el tipo de archivo, pueden

archivos de word y pdf’s.

codigodocumento integer NOT NULL Llave foránea desde la tabla documento

(FK). Un documento puede tener varios

archivos.



contenido oid NOT NULL Es el número de caracteres de un

archivo.

tamanioarchivo character 20 Es el tamaño en bytes de un archivo.


98

Nombre: tblcatalogotipoDescripción: Esta tabla indica el tipo de catálogo al

que se asociará varios sub-catálogos.

Constrains:


codigotipo integer NOT NULL Identificador del tipo de catalogo.

nombre character 100 NOT NULL Nombre del tipo.

descripcion text 500 NOT NULL Define de que se trata el catálogo.

estado character 3 Indica si el catalogo es activo o inactivo.



Nombre: tblcatalogovalorDescripción: En esta tabla se registraran todos los

archivos asociados a grupos de normas jurídicas del

SGP.

Constrains:


codigovalor integer NOT NULL Identificador del catalogo valor.

nombre character 100 NOT NULL Nombre del catalogo.

descripcion character 500 NOT NULL Descripción del catalogo.

estado character 3 Estado activo o inactivo del catalogo.

codigotipo integer NOT NULL Indica de que tipo es el catalogo valor.



Nombre: tblempresaDescripción: En esta tabla se registraran las empresas ya

sea la empresa consultora o las empresas clientes.

Constrains:


codigoempresa integer NOT NULL Identificador de la tabla empresa.

nombreempresa character 50 NOT NULL Nombre de la empresa.



direccionempresa character 100 Dirección de la empresa.

telefonoempresa character 20 Teléfono convencional o móvil de la

empresa.

mailempresa character 50 Correo electrónico de la empresa.

estado character 3 NOT NULL Estado de la empresa, puede ser activo

o inactivo.

tipoEmpresa character 3 La empresa puede ser interno o externa


99

Nombre: tblformularioDescripción: En esta tabla se registraran los formularios.

Constrains:


codigoformulario integer NOT NULL Identificador de la tabla formulario.

codigousuario integer NOT NULL Campo con el cual se puede asociar

un usuario con uno o más

formularios formulario.

fechaformulario date NOT NULL Indica la fecha de creación del

formulario.

tituloformulario character 100 Indica el titulo del formulario.

estadoformulario character 3 Estado del formulario, puede ser

activo o inactivo.

usuarioregistro character 10 NOT NULL Indica el responsable de la creación

del formulario.

Observacion character 500 Es la observación que el consultor

hace respecto a la implementación

del formulario.

Nombre: tblpreguntaDescripción: En esta tabla se registraran las posibles preguntas

que forman parte de un formulario.

Constrains:


codigopregunta integer NOT NULL Identificador de la tabla pregunta.

descripcionpregunta varchar 100 Describe el contexto de la

pregunta.

catalogopregunta integer Indica a que catalogo pertenece la

pregunta (incendios, productos

químicos, manejo correcto de

herramientas, etc).

estado character 3 NOT NULL Estado de la pregunta, puede ser

activo o inactivo.

tipopreguntapadre integer NOT NULL Indica si es una sub pregunta.

tipopregunta integer NOT NULL Es el tipo del catalogo al que

pertenece la pregunta.

usuarioregistro integer NOT NULL Registra a la persona que crea o

modifica una pregunta.

tipocomponente integer NOT NULL Indica el tipo de pregunta en un

formulario.


100

Nombre: tblformulariodetalleDescripción: En esta tabla se registraran los formularios

guardados con sus respuestas.

Constrains:


codigodetalle integer NOT NULL Identificador del detalle de un

formulario.

codigoformulario integer NOT NULL Indica a que formulario pertenece el

detalle.

codigopregunta integer NOT NULL Son las preguntas que pertenecen al

detalle.

respuesta character 200 NOT NULL Es la respuesta a la pregunta de un

formulario.

validacionrespuesta character 200 Es la validación que se le da a cada

respuesta de un formulario.

observacion character 250 Son las observaciones que la

empresa consultora asienta respecto

a las respuestas del formulario.

calificacion double Es la calificación del formulario.

Estado character 3 NOT NULL Indica el estado de cada pregunta.

usuarioregistro character 10 NOT NULL Usuario responsable de la creación o

modificación del detalle de un

formulario.


101

Nombre: tblestadisticadocumentoCon esta tabla se pretende realizar los reportes necesarios para

la toma de decisiones en la empresa consultora.

Esta tabla se llena dependiendo de las acciones que realice el

cliente (empresas nacionales clientes) en el gestor documental.

Constrains:


codigodocumento integer NOT NULL Al descargar o visualizar un

documento se guarda el código del

documento en el campo

codigodocumento.

nombreip character 50 NOT NULL Al descargar o visualizar un

documento se guarda la ip del equipo

desde donde se realizaron dichas

acciones.

nombremaquina character 100 NOT NULL Al descargar o visualizar un

documento se guarda el nombre del

equipo desde donde se realizaron

dichas acciones.

fechahorasistema timestamp NOT NULL Se guarda la fecha y hora del equipo

desde donde se realizaron dichas

acciones

nombreevento character 50 NOT NULL Se guarda la descripción de la acción

realizada, puede ser: visualizardoc y

descargarDoc.

codigoestadistica Integer NOT NULL Es el código de la estadística y es un

secuencial (pk).

usuarioregistro character 10 NOT NULL Usuario responsable de la creación o

modificación del detalle de un

formulario.

codigousuario Integer NOT NULL Es el código del usuario cliente quien

realizo la acción de visualizar o

descargar un documento del gestor.

aplicación web para la prevención y soporte en la ... · aplicación web para la administración,...

Documents