0% encontró este documento útil (0 votos)
137 vistas249 páginas

Ejemplo

Este documento presenta una tesis para optar el título de Ingeniero en Sistemas Informáticos. Propone desarrollar una aplicación web mediante la integración de Java Server Faces y Enterprise Java Beans para gestionar un hospital. Incluye los capítulos de marco referencial, JSF y EJB, integración de JSF y EJB, metodología propuesta y aplicación de la metodología para un sistema de gestión industrial.

Cargado por

kamisaky
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
137 vistas249 páginas

Ejemplo

Este documento presenta una tesis para optar el título de Ingeniero en Sistemas Informáticos. Propone desarrollar una aplicación web mediante la integración de Java Server Faces y Enterprise Java Beans para gestionar un hospital. Incluye los capítulos de marco referencial, JSF y EJB, integración de JSF y EJB, metodología propuesta y aplicación de la metodología para un sistema de gestión industrial.

Cargado por

kamisaky
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 249

-1-

ESCUELA SUPERIOR POLITCNICA DE CHIMBORAZO


FACULTAD DE INFORMTICA Y ELECTRNICA
ESCUELA DE INGENIERA EN SISTEMAS

DESARROLLO DE UNA METODOLOGA PARA LA CONSTRUCCIN DE


UNA APLICACIN WEB MEDIANTE LA INTEGRACIN DE JSF Y EJB.
CASO PRCTICO: HOSPITAL PROVINCIAL GENERAL DOCENTE
RIOBAMBA

TESIS DE GRADO
Previa a la obtencin del ttulo de
INGENIERO EN SISTEMAS INFORMTICOS

Presentado por:
VICENTE ANBAL CARRILLO TIXE
ALEX IGNACIO ERAZO VIVERO

RIOBAMBA ECUADOR
2012

-2-

INDICE GENERAL.
INDICE GENERAL
INDICE DE TABLAS
INDICE DE FIGURAS
AGRADECIMIENTO
DEDICATORIA
FIRMAS RESPONSABLES Y NOTAS
NDICE DE ABREVIATURAS
CAPTULO I.
1.

MARCO REFERENCIAL. ______________________________________________ 25


1.1.

ANTECEDENTES. _______________________________________________ 25

1.2.

JUSTIFICACIN. ________________________________________________ 27

1.2.1.

JUSTIFICACIN TERICA. _________________________________________________ 27

1.2.2.

JUSTIFICACIN APLICATIVA. _______________________________________________ 28

1.3.

OBJETIVOS. ___________________________________________________ 30

1.3.1.

GENERAL. ______________________________________________________________ 30

1.3.2.

ESPECFICOS. ___________________________________________________________ 30

1.4.

HIPTESIS. ___________________________________________________ 30

CAPTULO II.
2.

JAVA SERVER FACES Y ENTERPRISE JAVA BEAN. _________________________ 31


2.1.

JAVA SERVER FACES. ___________________________________________ 31

2.1.1.

INTRODUCCIN A JSF. ____________________________________________________ 31

2.1.2.

APLICACIONES JAVA SERVER FACES. ________________________________________ 32

2.1.2.1.

CARACTERSTICAS. ____________________________________________________ 34

2.1.2.2.

BENEFICIOS DE JSF. ____________________________________________________ 35

2.1.2.3.

ETIQUETAS JSF. _______________________________________________________ 37

2.1.2.4.

BACKBEANS. _________________________________________________________ 38

2.1.2.4.1.

ESTRUCTURA DE LAS PGINAS. _______________________________________ 38

-3-

2.1.2.5.

JSF Y AJAX. ___________________________________________________________ 39

2.1.2.6.

EL FUTURO DE JSF. ____________________________________________________ 39

2.1.3.

MODELO VISTA CONTROLADOR EN JSF. ______________________________________ 40

2.1.3.1.

INTRODUCCIN. ______________________________________________________ 40

2.1.3.2.

MODELO. ____________________________________________________________ 40

2.1.3.3.

VISTA. ______________________________________________________________ 41

2.1.3.4.

CONTROLADOR. ______________________________________________________ 41

2.1.4.
2.1.4.1.

MANAGED BEANS Y NAVEGACIN EN JSF.____________________________________ 41


MANAGED BEANS. ____________________________________________________ 41

ATRIBUTOS. ________________________________________________________________ 42
EXPRESIONES PARA VALORES INMEDIATOS Y DIRECTOS. ____________________________ 43
MBITO DE LOS BEANS. _______________________________________________________ 43
2.1.4.2.

NAVEGACIN. ________________________________________________________ 44

NAVEGACIN ESTTICA. ______________________________________________________ 45


NAVEGACIN DINMICA. _____________________________________________________ 45

2.2.

ENTERPRISE JAVA BEAN. ________________________________________ 46

2.2.1.

INTRODUCCION. ________________________________________________________ 46

2.2.2.

DEFININ DE EJB. _______________________________________________________ 48

2.2.3.

VENTAJAS DE EJB. _______________________________________________________ 48

2.2.3.1.

SERVICIOS MIDDLEWARE. ______________________________________________ 48

2.2.3.2.

DIVISIN DE TRABAJO. _________________________________________________ 49

2.2.3.3.

DIVERSOS VENDEDORES. _______________________________________________ 49

2.2.3.4.

PROCEDIMIENTOS REMOTOS RMI. _______________________________________ 50

2.2.3.5.

DIVERSOS CLIENTES. ___________________________________________________ 50

2.2.4.

COMPONENTES DE LA ARQUITECTURA. ______________________________________ 50

2.2.4.1.

OBJETO EJB. __________________________________________________________ 50

2.2.4.2.

SERVIDOR DE EJB (EJB SERVER). __________________________________________ 53

2.2.4.3.

EJB CONTAINER. ______________________________________________________ 53

2.2.5.

FUNCIONAMIENTO DE LOS EJB. ____________________________________________ 53

2.2.5.1.

INTERFAZ REMOTA. ___________________________________________________ 54

2.2.5.2.

INTERFAZ EJB HOME. __________________________________________________ 54

2.2.5.3.

MANEJO DE ESTADOS. _________________________________________________ 55

2.2.5.4.

SEGURIDAD. _________________________________________________________ 55

2.2.5.5.

TRANSACCIONES. _____________________________________________________ 55

2.2.5.6.

PERSISTENCIA. ________________________________________________________ 56

2.2.6.

TIPOS DE EJB. ___________________________________________________________ 56

-4-

2.2.6.1.

EJB DE ENTIDAD. ______________________________________________________ 56

2.2.6.2.

EJB DE SESIN. _______________________________________________________ 56

2.2.6.3.

EJB DIRIGIDOS POR MENSAJE. ___________________________________________ 57

2.2.7.

ARCHIVO EJB-JAR. _______________________________________________________ 57

CAPTULO III.
3.

INTEGRACIN DE JSF Y EJB. __________________________________________ 59


3.1.

INTRODUCCIN. _______________________________________________ 59

3.2.

ANTECEDENTES JSF Y EJB. _______________________________________ 61

3.3.

APLICACIN CON JSF Y EJB. ______________________________________ 61

3.3.1.

REQUISITOS PARA CONSTRUIR LA APLICACIN. _______________________________ 62

3.3.2.

CREANDO EL PROYECTO. _________________________________________________ 63

3.3.3.

CREANDO LAS CLASES ENTIDADES A PARTIR DE LA BASE DE DATOS. _______________ 66

3.3.3.1.
3.3.4.

CREACIN DE LOS EJB (SESSION Y MESSAGE DRIVEN) ________________________ 70


USANDO JSF Y PRIMEFACES. _______________________________________________ 77

3.3.4.1.

CREANDO EL CLIENTE BEAN GESTIONADO. _________________________________ 82

3.3.4.2.

CREACIN DE LA PGINA WEB CLIENTE. ___________________________________ 85

CAPTULO IV.
4.

DESARROLLO DE METODOLOGA ERCA WEB ____________________________ 92


4.1.

QU ES UNA METODOLOGA? ___________________________________ 92

4.2.

METODOLOGAS DE DESARROLLO DE SOFTWARE. ____________________ 92

4.2.1.
4.2.1.1.
4.2.2.

4.3.

METODOLOGAS TRADICIONALES O PESADAS. ________________________________ 93


METODOLOGA MICROSOFT SOLUTION FRAMEWORK (MSF). __________________ 94
METODOLOGAS GILES. _________________________________________________ 95

METODOLOGA PROPUESTA ERCA WEB.____________________________ 96

4.3.1.

FASES DE LA METODOLOGA ERCA WEB. _____________________________________ 96

4.3.1.1.

Fase 1: Planificacin. ___________________________________________________ 97

4.3.1.2.

Fase 2: Desarrollo de Base de Datos. ______________________________________ 97

4.3.1.3.

Fase 3: Desarrollo de Mdulo EJB. ________________________________________ 98

4.3.1.4.

Fase 4: Integracin de Frameworks. ______________________________________ 98

4.3.1.5.

Fase 5: Construccin Final de la Aplicacin. ________________________________ 98

4.3.1.6.

Fase 6: Implementacin e Implantacin. ___________________________________ 98

-5-

4.3.2.

FASE 1: PLANIFICACIN. __________________________________________________ 98

4.3.2.1.

ANLISIS DE REQUERIMIENTOS. _________________________________________ 98

4.3.2.2.

BOSQUEJO DE BASE DE DATOS. _________________________________________ 101

4.3.2.3.

APRENDIZAJE DE FRAMEWORK JSF. ______________________________________ 101

4.3.3.

FASE 2: DESARROLLO DE BASE DE DATOS. ___________________________________ 101

4.3.3.1.

DISEO DE BASE DE DATOS. ____________________________________________ 102

4.3.3.2.

CONSTRUCCIN DE PROTOTIPO EN JSF. __________________________________ 102

4.3.3.3.

PRESENTACIN DE PROTOTIPO. ________________________________________ 102

4.3.3.4.

DISEO FINAL DE BASE DE DATOS. ______________________________________ 103

4.3.4.

FASE 3: DESARROLLO DE MDULO EJB. _____________________________________ 103

4.3.4.1.

APRENDIZAJE DE FRAMEWORK EJB. _____________________________________ 103

4.3.4.2.

CREACIN DEL MDULO EJB. __________________________________________ 103

4.3.4.3.

GENERACIN DE LA CAPA DE ACCESO A DATOS Y LGICA DE NEGOCIO INICIAL. __ 104

4.3.5.

FASE 4: INTEGRACIN DE FRAMEWORKS. ___________________________________ 106

4.3.5.1.

CREACIN DE MDULO JSF. ____________________________________________ 106

4.3.5.2.

INTEGRACIN DE JSF Y EJB. ____________________________________________ 107

4.3.5.3.

DESARROLLO FINAL DE CAPA DE LGICA DE NEGOCIO. _____________________ 108

4.3.6.

FASE 5: CONSTRUCCIN FINAL DE LA APLICACIN. ___________________________ 108

4.3.6.1.

PREPARACIN DE TEMPLATES. _________________________________________ 108

4.3.6.2.

DESARROLLO FINAL DE INTERFACES. _____________________________________ 109

4.3.6.3.

PRESENTACIN FINAL. ________________________________________________ 109

4.3.6.4.

SUGERENCIAS Y MEJORAMIENTO. _______________________________________ 109

4.3.7.

FASE 6: IMPLEMENTACIN E IMPLANTACIN. _______________________________ 110

4.3.7.1.

INSTALACIN DE SERVIDORES. _________________________________________ 110

4.3.7.2.

ALOJAMIENTO DE LA APLICACIN EN EL SERVIDOR. ________________________ 112

4.3.7.3.

PRUEBAS Y FUNCIONAMIENTO. _________________________________________ 115

CAPTULO V.
5.

APLICACIN DE METODOLOGA ERCA WEB PARA EL DESARROLLO DEL

SOFTWARE DE GESTIN INDUSTRIAL. ____________________________________ 117


5.1.

PLANIFICACIN. ______________________________________________ 117

5.1.1.
5.1.1.1.

ANLISIS DE REQUERIMIENTOS. ___________________________________________ 117


OBJETIVOS DEL SRS. __________________________________________________ 118

5.1.1.1.1.

mbito. _________________________________________________________ 118

5.1.1.1.2.

Referencias. _____________________________________________________ 118

5.1.1.1.3.

Visin general. ___________________________________________________ 119

-6-

5.1.1.2.

DESCRIPCIN GENERAL _______________________________________________ 119

5.1.1.2.1.

Perspectiva del producto. __________________________________________ 119

5.1.1.2.2.

Funciones del producto.____________________________________________ 119

5.1.1.2.2.

Caractersticas del usuario. _________________________________________ 120

5.1.1.2.3.

Limitaciones generales. ____________________________________________ 120

5.1.1.2.4.

Supuestos y dependencias. _________________________________________ 121

5.1.1.3.

REQUERIMIENTOS ESPECIFICOS _________________________________________ 121

5.1.1.3.1.

Requerimientos Funcionales. ________________________________________ 121

1.

Requerimiento 1. _______________________________________________________ 123

2.

Requerimiento 2. _______________________________________________________ 124

3.

Requerimiento 3. _______________________________________________________ 126

4.

Requerimiento 4. _______________________________________________________ 128

5.

Requerimiento 5. _______________________________________________________ 129

6.

Requerimiento 6. _______________________________________________________ 131

7.

Requerimiento 7. _______________________________________________________ 133

8.

Requerimiento 8 _______________________________________________________ 134

9.

Requerimiento 9. _______________________________________________________ 135

10.

Requerimiento 10. ___________________________________________________ 137

11.

Requerimiento 11. ___________________________________________________ 138

5.1.1.3.2.

Requerimientos de Interfaces Externas _______________________________ 140

5.1.1.3.3.

Requerimientos de Rendimiento. ____________________________________ 140

5.1.1.3.4.

Limitaciones de Diseo. ____________________________________________ 141

5.1.1.3.5.

Otros requerimientos ______________________________________________ 142

5.1.2.

BOSQUEJO DE BASE DE DATOS. ___________________________________________ 142

5.1.3.

APRENDIZAJE DE FRAMEWORK JSF. ________________________________________ 143

5.2.

DESARROLLO DE BASE DE DATOS. ________________________________ 144

5.2.1.

DISEO DE BASE DE DATOS. ______________________________________________ 144

5.2.2.

CONSTRUCCIN DE PROTOTIPO EN JSF. ____________________________________ 144

5.2.3.

PRESENTACIN DE PROTOTIPO. ___________________________________________ 144

5.2.4.

DISEO FINAL DE BASE DE DATOS. _________________________________________ 145

5.3.

5.2.4.1.

DIAGRAMA DE BASE DE DATOS._________________________________________ 145

5.2.4.2.

PROCEDIMIENTOS ALMACENADOS.______________________________________ 145

DESARROLLO DE MDULO EJB. __________________________________ 146

5.3.1.

APRENDIZAJE DE FRAMEWORK EJB. ________________________________________ 146

5.3.2.

CREACIN DEL MDULO EJB. _____________________________________________ 146

-7-

5.3.3.

5.4.

GENERACIN DE LA CAPA DE ACCESO A DATOS Y LGICA DE NEGOCIO INICIAL. ____ 147

5.3.3.1.

ACCESO A DATOS. ____________________________________________________ 147

5.3.3.2.

LGICA DE NEGOCIO. _________________________________________________ 149

INTEGRACIN DE FRAMEWORKS. ________________________________ 150

5.4.1.

CREACIN DE MDULO JSF. ______________________________________________ 151

5.4.2.

INTEGRACIN DE JSF Y EJB. ______________________________________________ 151

5.4.3.

DESARROLLO FINAL DE LA LGICA DE NEGOCIO. _____________________________ 152

5.5.

CONSTRUCCIN FINAL DE LA APLICACIN. _________________________ 152

5.5.1.

PREPARACIN DE TEMPLATES. ____________________________________________ 152

5.5.2. DESARROLLO FINAL DE INTERFACES. ___________________________________________ 153


5.5.2.

PRESENTACIN FINAL. __________________________________________________ 153

5.5.3.

SUGERENCIAS Y MEJORAMIENTO. _________________________________________ 153

5.6.

IMPLEMENTACIN E IMPLANTACIN. ____________________________ 153

5.6.1.

INSTALACIN DE SERVIDORES. ____________________________________________ 153

5.6.2.

ALOJAMIENTO DE SITIO WEB. ____________________________________________ 160

5.6.3.

PRUEBAS Y FUNCIONAMIENTO. ___________________________________________ 160

CAPITULO VI.
6.

RESULTADOS Y DISCUSIN. _________________________________________ 161


6.1.

HIPTESIS. __________________________________________________ 161

6.1.1.

INTRODUCCIN. _______________________________________________________ 161

6.1.2.

DEFINICIN DE LOS PARMETROS DE COMPARACIN. ________________________ 162

6.1.3.

DEFINICIN DE LOS INDICADORES QUE MIDEN EL TIEMPO EN LA CONSTRUCCIN Y

MANTENIMIENTO DE APLICACIONES WEB. ___________________________________________ 164


6.1.4.

CRITERIOS DE EVALUACIN. ______________________________________________ 167

6.1.5.

ANALISIS DE LOS PARMETROS DE COMPARACIN PARA LAS METODOLOGAS. ____ 168

6.1.5.1.

REUSABILIDAD. ______________________________________________________ 168

6.1.5.1.1.

PORTABILIDAD. ___________________________________________________ 168

6.1.5.1.2.

INDEPENDENCIA DE COMPONENTES. _________________________________ 169

6.1.5.1.3.

FACILIDAD DE INTEGRACIN. _______________________________________ 171

6.1.5.1.4.

INTERPRETACIN. ________________________________________________ 174

6.1.5.2.

GENERACIN DE CDIGO. _____________________________________________ 175

6.1.5.2.1.

CREACIN DE CAPA DE ACCESO A DATOS. _____________________________ 175

6.1.5.2.2.

GENERACIN DE CAPA DE LGICA DE NEGOCIO. ________________________ 177

-8-

6.1.5.2.3.

LINEAS DE CDIGO. _______________________________________________ 178

6.1.5.2.4.

CODIGO NO UTILIZABLE. ___________________________________________ 182

6.1.5.2.5.

COMPLEJIDAD. ___________________________________________________ 185

6.1.5.2.6.

INTERPRETACIN. ________________________________________________ 189

6.1.5.3.

MODULARIDAD. _____________________________________________________ 189

6.1.5.3.1.

MODELO VISTA CONTROLADOR _____________________________________ 189

6.1.5.3.2.

DISEO ESTRUCTURADO ___________________________________________ 190

6.1.5.3.3.

CAPACIDAD DE DESCOMPOSICIN ___________________________________ 191

6.1.5.3.4.

COMPRENSIN. __________________________________________________ 193

6.1.5.3.5.

INTERPRETACIN. ________________________________________________ 197

6.1.5.4.

MANTENIBILIDAD. ___________________________________________________ 197

6.1.5.4.1.

ESCALABILIDAD. __________________________________________________ 197

6.1.5.4.2.

DISPONIBILIDAD DE DOCUMENTACIN. _______________________________ 198

6.1.5.4.3.

CDIGO ENTENDIBLE. _____________________________________________ 200

6.1.5.4.4.

ADAPTABILIDAD DE NUEVOS REQUERIMIENTOS. ________________________ 202

6.1.5.4.5.

INTERPRETACIN. ________________________________________________ 205

6.1.5.5.

PRESENTACIN. _____________________________________________________ 205

6.1.5.5.1.

TEMPLATES PERSONALIZADOS. ______________________________________ 205

6.1.5.5.2.

COMPONENTES AJAX. _____________________________________________ 208

6.1.5.5.3.

VALIDACIONES. ___________________________________________________ 212

6.1.5.5.4.

MENOR USO DE JAVA SCRIPT. _______________________________________ 214

6.1.5.5.5.

INTERPRETACIN. ________________________________________________ 219

6.1.6.
6.1.6.1.

ANLISIS GENERAL DE COMPROBACIN. ___________________________________ 219


HIPTESIS. __________________________________________________________ 219

6.1.6.1.1.

DETERMINACIN DE VARIABLES. ____________________________________ 219

6.1.6.1.2.

OPERACIONALIZACIN DE LAS VARIABLES. ____________________________ 219

6.1.6.2.

COMPARACIN DE LOS RESULTADOS OBTENIDOS. _________________________ 221

6.1.6.2.1.

APLICACIN DE CHI CUADRADO. _____________________________________ 223

6.1.6.2.2.

CLCULOS OBTENIDOS CON SOFTWARE ESTADSTICO SPSS _______________ 227

CONCLUSIONES.
RECOMENDACIONES.
RESUMEN.
ABSTRACT.
ANEXOS.

-9-

INTERFACES DE APLICACIN SGM PRO.


ENCUESTA REALIZADA A EXPERTOS.
GLOSARIO.
BIBLIOGRAFA.

- 10 -

INDICE DE TABLAS.
Tabla IV.I: Mtricas de Requerimientos no Funcionales. _____________________________________ 100
Tabla V.II: Caractersticas de los Usuarios. ________________________________________________ 120
Tabla V.III: Entradas Requerimiento 1. ___________________________________________________ 123
Tabla V.IV: Procesos Requerimiento 1. ___________________________________________________ 123
Tabla V.V: Salidas Requerimiento 1. _____________________________________________________ 123
Tabla V.VI: Entradas Requerimiento 2. ___________________________________________________ 124
Tabla V.VII: Procesos Requerimiento 2. ___________________________________________________ 125
Tabla V.VIII: Salidas Requerimiento 2. ____________________________________________________ 125
Tabla V.IX: Entradas Requerimiento 3. ___________________________________________________ 126
Tabla V.X: Procesos Requerimiento 3. ____________________________________________________ 126
Tabla V.XI: Salidas Requerimiento 3. _____________________________________________________ 126
Tabla V.XII: Entradas Requerimiento 4. ___________________________________________________ 128
Tabla V.XIII: Procesos Requerimiento 4. __________________________________________________ 128
Tabla V.XIV: Salidas Requerimiento 4. ____________________________________________________ 129
Tabla V.XV: Entradas Requerimiento 5. __________________________________________________ 130
Tabla V.XVI: Procesos Requerimiento 5. __________________________________________________ 130
Tabla V.XVII: Salidas Requerimiento 5. ___________________________________________________ 130
Tabla V.XVIII: Entradas Requerimiento 6. _________________________________________________ 131
Tabla V.XIX: Procesos Requerimiento 6. __________________________________________________ 132
Tabla V.XX: Salidas Requerimiento 6. ____________________________________________________ 132
Tabla V.XXI: Entradas Requerimiento 7. __________________________________________________ 133
Tabla V.XXII: Procesos Requerimiento 7. __________________________________________________ 133
Tabla V.XXIII: Salidas Requerimiento 7. ___________________________________________________ 133
Tabla V.XXIV: Entradas Requerimiento 8. _________________________________________________ 134
Tabla V.XXV: Procesos Requerimiento 8. __________________________________________________ 135
Tabla V.XXVI: Salidas Requerimiento 8. __________________________________________________ 135
Tabla V.XXVII: Entradas Requerimiento 9. ________________________________________________ 136
Tabla V.XXVIII: Procesos Requerimiento 9. ________________________________________________ 136
Tabla V.XXIX. Salidas Requerimiento 9. ___________________________________________________ 136
Tabla V.XXX: Entradas Requerimiento 10._________________________________________________ 137
Tabla V.XXXI: Procesos Requerimiento 10. ________________________________________________ 137
Tabla V.XXXII: Salidas Requerimiento 10. _________________________________________________ 138
Tabla V.XXXIII: Entradas Requerimiento 11. _______________________________________________ 139
Tabla V.XXXIV: Procesos Requerimiento 11. _______________________________________________ 139
Tabla V.XXXV: Salidas Requerimiento 11. _________________________________________________ 139

- 11 -

Tabla VI.XXXVI: Lista de Parmetros. ____________________________________________________ 162


Tabla VI.XXXVII: Lista de Parmetros que determinan el Tiempo. ______________________________ 164
Tabla VI.XXXVIII: Parmetro 1 Reusabilidad. _____________________________________________ 165
Tabla VI.XXXIX: Parmetro 2 Generacin de Cdigo._______________________________________ 165
Tabla VI.XL: Parmetro 3 Modularidad. _________________________________________________ 166
Tabla VI.XLI: Parmetro 4 Mantenibilidad. ______________________________________________ 166
Tabla VI.XLII: Parmetro 5 Presentacin. ________________________________________________ 167
Tabla VI.XLIII: Criterios de Evaluacin General. ____________________________________________ 167
Tabla VI.XLIV: Evaluacin del ndice de Portabilidad. ________________________________________ 169
Tabla VI.XLV: Evaluacin del ndice de Independencia de Componentes. ________________________ 170
Tabla VI.XLVI: Evaluacin del ndice Facilidad de Integracin. _________________________________ 172
Tabla VI.XLVII: Tabla General del Parmetro de Reusabilidad. ________________________________ 173
Tabla VI.XLVIII: Evaluacin del ndice de Creacin de Capa de Acceso a Datos. ___________________ 176
Tabla VI.XLIX: Evaluacin del ndice de Creacin de Capa de Lgica de Negocio. __________________ 178
Tabla VI.L: Criterio de Evaluacin para medir las Lneas de Cdigo. ____________________________ 179
Tabla VI.LI: Evaluacin del ndice de Lneas de Cdigo. ______________________________________ 181
Tabla VI.LII: Criterio de Evaluacin para medir las Lneas de Cdigo no utilizable. _________________ 182
Tabla VI.LIII: Evaluacin del ndice de Cdigo no utilizable. ___________________________________ 184
Tabla VI.LIV: Criterio de Evaluacin para medir la Complejidad. _______________________________ 185
Tabla VI.LV: Evaluacin del ndice de Complejidad. _________________________________________ 186
Tabla VI.LVI: Valores de cada ndice del Parmetro de Generacin de Cdigo. ___________________ 187
Tabla VI.LVII: Evaluacin del ndice de Modelo Vista Controlador. _____________________________ 189
Tabla VI.LVIII: Evaluacin del ndice de Diseo Estructurado. _________________________________ 191
Tabla VI.LIX: Evaluacin del ndice de Capacidad de Descomposicin. __________________________ 193
Tabla VI.LX: Evaluacin del ndice de Comprensin del Cdigo. ________________________________ 195
Tabla VI.LXI: ndices - Parmetro Modularidad.____________________________________________ 195
Tabla VI.LXII: Evaluacin del ndice de Escalabilidad. ________________________________________ 198
Tabla VI.LXIII: Evaluacin del ndice de Disponibilidad de Documentacin. ______________________ 199
Tabla VI.LXIV: Evaluacin del ndice de Cdigo Entendible. ___________________________________ 201
Tabla VI.LXV: Evaluacin del ndice de Adaptabilidad de Nuevos Requerimientos. ________________ 202
Tabla VI.LXVI: Tabla general de ndices - parmetro Mantenibilidad. __________________________ 203
Tabla VI.LXVII: Evaluacin del ndice de Templates Personalizados. ____________________________ 207
Tabla VI.LXVIII: Evaluacin del ndice de Componentes AJAX. _________________________________ 211
Tabla VI.LXIX: Evaluacin del ndice de Validaciones. ________________________________________ 213
Tabla VI.LXX: Evaluacin del ndice de Menor Uso de JavaScript. ______________________________ 216
Tabla VI.LXXI: Tabla general de ndices - parmetro Presentacin _____________________________ 217
Tabla VI.LXXII: Operacionalizacin Conceptual. ____________________________________________ 219

- 12 -

Tabla VI.LXXIII: Operacionalizacin Metodolgica. _________________________________________ 220


Tabla VI.LXXIV: Paramaros de Optimizacin de tiempo y cuantificacin _________________________ 221
Tabla VI.LXXV: Valores Observados y Totales. _____________________________________________ 223
Tabla VI.LXXVI: Valores Esperados y Totales. ______________________________________________ 224
Tabla VI.LXXVII: Resumen Valores Observados y valores Esperados. ____________________________ 225

- 13 -

INDICE DE FIGURAS.
Figura II.1: Diagrama de una aplicacin JSF. ________________________________________________ 35
Figura II.2: Arquitectura MVC. ___________________________________________________________ 40
Figura II.3: Funcin de los objetos EJB. ____________________________________________________ 52
Figura II.5: Archivo EJB-jar. _____________________________________________________________ 58
Figura III.6: Distribucin por capas de la Aplicacin. _________________________________________ 62
Figura III.7: Base de Datos de muestra en NetBeans. _________________________________________ 63
Figura III.8: Creando el Proyecto => Seleccionar Proyecto. _____________________________________ 64
Figura III.9: Creando el Proyecto => Nombre y Ubicacin del Proyecto. __________________________ 64
Figura III.10: Creando el Proyecto => Servidor y Configuraciones. _______________________________ 65
Figura III.11: Creando el Proyecto => Proyectos creados por el IDE NetBeans. _____________________ 66
Figura III.12: Creando las clases entidades => Seleccionar Otro. ________________________________ 67
Figura III.13: Creando las clases entidades => Seleccionar Clase Entidad a partir de Base de Datos. __ 67
Figura III.14: Creando las clases entidades => Seleccionar Tablas de la Base de Datos. ______________ 68
Figura III.15: Creando las clases entidades => Seleccionando Tablas. ____________________________ 69
Figura III.16: Creando las clases entidades => Clases Entidad. __________________________________ 69
Figura III.17: Creando las clases entidades => Opciones de Mapeo. _____________________________ 70
Figura III.18: Creando las clases entidades => Clases entidades creadas. _________________________ 70
Figura III.19: Creacin de los MDB => Nuevo Session Bean. ____________________________________ 71
Figura III.20: Creacin de los MDB => Nombre y Localizacin. __________________________________ 72
Figura III.21: Creacin de los MDB => Nuevo Message Drive Bean. ______________________________ 72
Figura III.22: Creacin de los MDB => Nombre y Localizacin de los MDB. ________________________ 73
Figura III.23: Creacin de los MDB => Paquetes y sus respectivas clases. _________________________ 73
Figura III.24: Creacin de los MDB => Sessions Beans creados. _________________________________ 74
Figura III.25: Creacin de los MDB => Creando la Persistencia. _________________________________ 74
Figura III.26: Creacin de los MDB => Cdigo insertado de Persistencia. _________________________ 75
Figura III.27: Creacin de los MDB => Men para agregar nuevos mtodos. ______________________ 75
Figura III.28: Creacin de los MDB => Creacin de Nuevos Mtodos. ____________________________ 76
Figura III.29: Creacin de los MDB => Cdigo de los nuevos mtodos. ___________________________ 76
Figura III.30: Creacin de los MDB => Cdigo para mtodos update y retrive. _____________________ 77
Figura III.31: Usando JSF y PrimeFaces => Seleccionando Framework JavaServer Faces. _____________ 78
Figura III.32: Usando JSF y PrimeFaces => Agregando Biblioteca Global. _________________________ 78
Figura III.33: Usando JSF y PrimeFaces => Agregando archivo .jar a la biblioteca. __________________ 79
Figura III.34: Usando JSF y PrimeFaces => Agregando la Biblioteca al proyecto. ___________________ 80
Figura III.35: Usando JSF y PrimeFaces => Administrador de Plantillas. __________________________ 81
Figura III.36: Usando JSF y PrimeFaces => Crear Nuevo JSF Managed Bean. ______________________ 83

- 14 -

Figura III.37: Usando JSF y PrimeFaces => Call Enterprise Bean. ________________________________ 84
Figura III.38: Usando JSF y PrimeFaces => Nuevo Archivo XHTML. ______________________________ 86
Figura III.39: Usando JSF y PrimeFaces => Tabla JSF desde la Entidad. ___________________________ 87
Figura III.40: Usando JSF y PrimeFaces => Aplicaciones del IDE NetBeans. ________________________ 87
Figura III.41: Usando JSF y PrimeFaces => Pantalla Cruda de la Lista de Clientes. __________________ 88
Figura III.42: Usando JSF y PrimeFaces => Pantalla de Lista de Clientes usando JSF. ________________ 89
Figura III.43: Usando JSF y PrimeFaces => JSF Table From Entity. _______________________________ 89
Figura III.44: Usando JSF y PrimeFaces => Archivo faces-config.xml con PageFlow. _________________ 90
Figura III.45: Usando JSF y PrimeFaces => Formulario de Ingreso de Clientes. _____________________ 91
Figura IV.46: Fases de la Metodologa ERCA Web. ___________________________________________ 97
Figura IV.47: Creacin Mdulo EJB Creando Nuevo Proyecto ________________________________ 104
Figura IV.48: Acceso a Datos => Crear Clases Entidad a partir de base de datos. __________________ 105
Figura IV.49: Lgica de Negocio => Session Beans para Clases Entidad. _________________________ 106
Figura IV.50: Seleccionando Framework JSF. ______________________________________________ 107
Figura IV.51: Integracin de EJB a JSF. ___________________________________________________ 108
Figura IV.52: Logo XAMPP _____________________________________________________________ 110
Figura IV.53: Servidor de Base de Datos MySQL. ___________________________________________ 111
Figura IV.54: Ubicacin del Servidor GlassFish en el Men Inicio. ______________________________ 112
Figura IV.55: Consola GlassFish. ________________________________________________________ 113
Figura IV.56: Configuracin para subir Aplicaciones. ________________________________________ 113
Figura IV.57: Lista de Aplicaciones subidas al servidor. ______________________________________ 114
Figura IV.58: Pantalla Inicial de Sofware de Gestin SGM Pro _________________________________ 114
Figura IV.59: Funcionamiento de Aplicacin. ______________________________________________ 115
Figura V.60: Funciones de SGM Pro ______________________________________________________ 119
Figura V.61: Lista de Estrategias. _______________________________________________________ 124
Figura V.62: Aplicacin SGM Pro. _______________________________________________________ 125
Figura V.63: Insertar Estrategias ________________________________________________________ 127
Figura V.64: Editar Estrategias _________________________________________________________ 127
Figura V.65: Confirmacin Eliminar Estrategia. ____________________________________________ 128
Figura V.66: Asignar Actividades ________________________________________________________ 129
Figura V.67: Historial Plan de Mantenimiento. _____________________________________________ 131
Figura V.68: Plan de Mantenimiento. ____________________________________________________ 131
Figura V.69: Notificar Actividad. ________________________________________________________ 132
Figura V.70: Ingresar Fallas. ___________________________________________________________ 134
Figura V.71: Asignar Estrategias a Equipos. _______________________________________________ 135
Figura V.72: Buscar Estrategia Asignada a Tecnico _________________________________________ 137
Figura V.73: Lista de Tecnicos en la Industria. _____________________________________________ 138

- 15 -

Figura V.74: Actividades de Tecnico determinado. __________________________________________ 138


Figura V.75: Actividades de Tecnico. _____________________________________________________ 140
Figura V.76: Bosquejo de Base de Datos. _________________________________________________ 143
Figura V.77: Diseo de Base de Datos. ___________________________________________________ 144
Figura V.78: Prototipo en JSF de Lista de Estrategias. _______________________________________ 144
Figura V.79: Modelo Final de Base de Datos. ______________________________________________ 145
Figura V.80: Creando Aplicacin Empresarial. _____________________________________________ 146
Figura V.81: Aplicacin Empresarial. _____________________________________________________ 147
Figura V.82: Clases entidad a partir de base de Datos. ______________________________________ 147
Figura V.83: Seleccin de Tablas para el acceso a datos. _____________________________________ 148
Figura V.84: Capa de Acceso a Datos. ____________________________________________________ 148
Figura V.85: Cdigo Generado por la capa de Acceso a Datos. ________________________________ 149
Figura V.86: Creando los Session Bean ___________________________________________________ 149
Figura V.87: Seleccionando Clases Entidad ________________________________________________ 150
Figura V.88: Lgica de Negocio _________________________________________________________ 150
Figura V.89: Creacin de mdulo JSF. ____________________________________________________ 151
Figura V.90: EJB Integrado a JSF. ________________________________________________________ 152
Figura V.91: Templates Utilizados. ______________________________________________________ 152
Figura V.92: Interfaz Final. _____________________________________________________________ 153
Figura V.93: Panel de Control de XAMPP. _________________________________________________ 154
Figura V.94: Consola de Administracin de GlassFish. _______________________________________ 155
Figura V.95: Conexin a MySQL en GlassFish. ______________________________________________ 155
Figura V.96: Configuracin de Conexin a MySQL. __________________________________________ 156
Figura V.97: Parmetros de Conexin a MySQL. ____________________________________________ 156
Figura V.98: Lista de Conexiones. _______________________________________________________ 157
Figura V.99: Lista de Recursos JDBC _____________________________________________________ 157
Figura V.100: Nuevo Recurso JDBC. ______________________________________________________ 158
Figura V.101: Lista de Recursos JDBC. ____________________________________________________ 158
Figura V.102: Consola de GlassFish. _____________________________________________________ 159
Figura V.103: Servidor Web GlassFish. ___________________________________________________ 159
Figura V.104: Alojamiento de Sitio Web. __________________________________________________ 160
Figura VI.105: ndice de comparacin Portabilidad. _________________________________________ 169
Figura VI.106: Independencia de Componentes. ____________________________________________ 171
Figura VI.107: ndice Facilidad de Integracin. _____________________________________________ 172
Figura VI.108: Parmetro de Reusabilidad de acuerdo a cada ndice. ___________________________ 173
Figura VI.109: Reusabilidad en las dos metodologas. _______________________________________ 174
Figura VI.110: ndice Creacin de Capa de Acceso a Datos. ___________________________________ 176

- 16 -

Figura VI.111: CRUD de Entidad Ubicacin Tcnica. ________________________________________ 177


Figura VI.112: Grfica del ndice Generacin de Capa de Lgica de Negocios. ____________________ 178
Figura VI.113: Lneas de Cdigo Mtodo Insercin Tcnicos Prototipo 1. ________________________ 179
Figura VI.114: Lneas de Cdigo Mtodo Eliminacin Tcnicos Prototipo 1. ______________________ 180
Figura VI.115: Lneas de Cdigo Mtodo Insercin Tcnicos Prototipo 2. ________________________ 180
Figura VI.116: Lneas de Cdigo Mtodo Eliminacin Tcnicos Prototipo 2. ______________________ 181
Figura VI.117: Grfica del ndice Lneas de Cdigo. _________________________________________ 182
Figura VI.118: Cdigo no utilizable en la Metodologa Propuesto en la Capa de Acceso a Datos. _____ 183
Figura VI.119: Cdigo no utilizable en la Metodologa Propuesto en la Capa de Lgica de Negocios. __ 183
Figura VI.120: Grfica del ndice Cdigo no Utilizable. _______________________________________ 184
Figura VI.121: Grfica del ndice Complejidad. _____________________________________________ 186
Figura VI.122: Grfica de Valores del Parmetro Generacin de Cdigo. ________________________ 188
Figura VI.123: Grfica Porcentual del Parmetro Generacin de Cdigo. ________________________ 188
Figura VI.124: ndice de comparacin Modelo Vista Controlador. ______________________________ 190
Figura VI.125: ndice de comparacin Diseo Estructurado. __________________________________ 191
Figura VI.126: Pgina HTML prototipo 1. _________________________________________________ 192
Figura VI.127: Pgina XHTML y Backbean. ________________________________________________ 192
Figura VI.128: ndice de comparacin Capacidad de Descomposicin. __________________________ 193
Figura VI.129: Comprensin de cdigo prototipo 1. _________________________________________ 194
Figura VI.130: Comprensin de cdigo prototipo 2. _________________________________________ 194
Figura VI.131: ndice de comparacin Comprensin del Cdigo. _____________________________ 195
Figura VI.132: ndices de comparacin Modularidad. ______________________________________ 196
Figura VI.133: Porcentajes totales - Modularidad. __________________________________________ 196
Figura VI.134: ndice de comparacin Templetes Personalizados. ______________________________ 198
Figura VI.135: ndice de comparacin Disponibilidad de Documentacin. _______________________ 199
Figura VI.136: Cdigo de Mtodo Insertar Prototipo 1. ______________________________________ 200
Figura VI.137: Cdigo Generado por Framework.___________________________________________ 201
Figura VI.138: ndice de comparacin Cdigo Entendible. ____________________________________ 201
Figura VI.139: ndice de comparacin Adaptabilidad de Nuevos Requerimientos. _________________ 203
Figura VI.140: ndices de comparacin - Mantenibilidad _____________________________________ 204
Figura VI.141: Porcentajes totales Mantenibilidad. ________________________________________ 204
Figura VI.142: Hojas de Estilo prototipo 1. ________________________________________________ 206
Figura VI.143: Referencias - Hojas de Estilo prototipo 1. _____________________________________ 206
Figura VI.144: Templates prototipo 2. ____________________________________________________ 207
Figura VI.145: Referencias - Templates prototipo 2._________________________________________ 207
Figura VI.146: ndice de comparacin Templates Personalizados. ______________________________ 208
Figura VI.147: Ajax en JSP. _____________________________________________________________ 209

- 17 -

Figura VI.148: Funcin AJAX. ___________________________________________________________ 209


Figura VI.149: AJAX HTML. ____________________________________________________________ 210
Figura VI.150: AJAX XHTML prototipo 2. __________________________________________________ 210
Figura VI.151: AJAX PRIMEFACES. _______________________________________________________ 211
Figura VI.152: ndice de comparacin Componentes AJAX. ___________________________________ 211
Figura VI.153: Validaciones prototipo 1. __________________________________________________ 212
Figura VI.154: Validaciones prototipo 2. __________________________________________________ 213
Figura VI.155: ndice de comparacin Validaciones. ________________________________________ 214
Figura VI.156: JavaScript prototipo 1. ____________________________________________________ 215
Figura VI.157: JavaScript prototipo 2. ____________________________________________________ 216
Figura VI.158: ndice de comparacin Menor Uso de Javascript. _______________________________ 217
Figura VI.159: ndices de comparacin -Presentacin. _______________________________________ 218
Figura VI.160: Porcentajes Totales - Presentacin. __________________________________________ 218
Figura VI.161: Tabla General de Valores. _________________________________________________ 222
Figura VI.162: Porcentaje General. ______________________________________________________ 223
Figura VI.163: Tabla de Chi-Cuadrado. ___________________________________________________ 226
Figura VI.164: Ingreso de datos al Spss. __________________________________________________ 227
Figura VI.165: Optimizacin del tiempo Metodologas. ____________________________________ 227
Figura VI.166: Resultado Chi cuadrado SPSS. ______________________________________________ 228

- 18 -

AGRADECIMIENTO
Agradezco primero a Dios por su misericordia, amor y por
permitirme cumplir uno de mis sueos ms anhelados dndome las
fuerzas necesarias para avanzar en el camino hacia mi superacin,
convirtindose en el pilar ms importante en mi vida. A mis padres
y hermanos por su apoyo incondicional en todo momento, siendo
as las columnas fundamentales en mi vida, por sus consejos,
enseanzas y principios, los cuales han contribuido en todo
momento para convertirme en la persona que soy hoy en da. A la
Escuela Superior Politcnica de Chimborazo por acogerme en sus
aulas e impartirme todos los conocimientos que hoy hacen de mi
un hombre de bien para la sociedad
Alex Erazo

Doy gracias al ser ms importante DIOS Que gua cada momento


de mi vida. A la Escuela Superior Politcnica de Chimborazo que
me permiti estudiar e investigar para el bien propio y de la
sociedad. Un especial agradecimiento a los Ingenieros Danny
Velasco y Ral Rosero Miembros del Tribual por la ayuda y
colaboracin para la realizacin de esta tesis. Al Hospital General
Docente de Riobamba por permitirnos trabajar conjuntamente en
el rea de Mantenimiento.
Vicente Carrillo

- 19 -

DEDICATORIA
Dedico este trabajo investigativo y toda mi carrera
politcnica, primero a Dios, ya que por medio de l he
alcanzado este logro tan anhelado, renovando mis fuerzas
en todo momento y estando conmigo siempre.
Dedico tambin el presente trabajo a mis padres, hermanos
y amigos, quienes nunca dudaron de mis capacidades, ms
bien, fueron un puntal de motivacin en mi vida,
demostrando en toda ocasin su confianza depositada en mi
Alex Erazo

A DIOS, a mis padres, hermanos, abuelitos y de manera


exclusiva a mis sobrinos Pablito y Sebastin que con el
andar cotidiano, me fueron aprovisionando de
herramientas especiales, para que el diario construir de
mi vida me sea ms interesante, a la experiencia de la vida
misma, a todas y cada una de mis amistades y a los que me
han ofrecido sus experiencias para construir las mas, a
todo ser humano que cree en s mismo y en sus propsitos.
Vicente Carrillo

- 20 -

FIRMAS RESPONSABLES Y NOTAS.


NOMBRES

FIRMAS

Ing. Ivn Menes


DECANO DE LA FACULTAD
DE INFORMTICA Y ELECTRNICA

Ing. Ral Rosero Miranda


DIRECTOR DE LA ESCUELA
DE INGENIERA EN SISTEMAS

Ing. Danny Velasco


DIRECTOR DE TESIS

Ing. Ral Rosero


MIEMBRO DE TESIS

Tec. Carlos Rodriguez


DIR. DPTO DOCUMENTACION

Nota:

FECHA

- 21 -

NDICE DE ABREVIATURAS.
ADF

Application Development Framework

API

Application Programming Interface.

ASP

Active Server Page

AWT

Abstract Window Toolkit

CGI

Common Gateway Interface

CRUD

Create Read Update and Delete

DI

Dependence Injection

EJB

Enterprise Java Beans.

ERP

Planificacin de Recursos Empresariales

ESPOCH

Escuela Superior Politcnica de Chimborazo.

HQL

Hibernate Query Language

HTML

Hipertext Markup Language

HTTP

Hipertext Transfer Protocol

IBM

International Business Machines

IDE

Integrated Development Environment

IoC

Inversion of Control

ISO

Organizacin Internacional de Normalizacin

J2EE

Java Enterprise Edition

J2SE

Java Standard Edition

JAAS

Java Authorization and Authentication Service

jBPM

JBoss Business Process Manager

- 22 -

JDBC

Java Database Connectivity

JDK

Java Development Kit

JDO

Java Data Objects

JMS

Java Message Service

JPA

Java Persistence API

JPOX

Java Persistant Objects

JSF

Java Server Faces

JSP

Java Server Pages

LDAP

Lightweight Directory Access Protocol

MDB

Message Driven Bean

MSF

Microsoft Solution Framework

MVC

Modelo Vista Controlador

ODBC

Open Database Connectivity

OJB

Object Relational Bridge

ORM

Object-Relational Mapping

PHP

Personal Home Page

POA

Programacin Orientada a Aspectos

POJO

Plain Object Java Old

RMI

Remote Method Invocation

RUP

Rational Unified Process

SQL

Estructured Query Language

UI

Interfaz de Usuario

- 23 -

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

XML

Extensible Markup Language

XUL

XML-based User-Interface Language

XP

Extreme Programming

- 24 -

Nosotros, Vicente Anbal Carrillo Tixe, Alex Ignacio Erazo Vivero, somos los
responsables del contenido, ideas y resultados planteados en el presente proyecto de
tesis, y el patrimonio intelectual del mismo pertenecen a la Escuela Superior Politcnica
de Chimborazo.

Vicente Anibal Carrillo Tixe

Alex Ignacio Erazo Vivero

- 25 -

CAPTULO I.

1. MARCO REFERENCIAL.
1.1.ANTECEDENTES.
El Internet y la Web han influido enormemente tanto en el mundo de la informtica
como en la sociedad en general. La web, en menos de 10 aos ha transformado los
sistemas informticos: ha roto las barreras fsicas (debido a la distancia), econmicas y
lgicas (debido al empleo de distintos sistemas operativos, protocolos, etc.), y ha abierto
todo un abanico de nuevas posibilidades. Una de las reas que ms expansin est
teniendo en la Web en los ltimos aos son las aplicaciones web.
Las aplicaciones web permiten la generacin automtica de contenido, la creacin de
pginas personalizadas segn el perfil del usuario o el desarrollo del comercio
electrnico. Adems permite interactuar con los sistemas informticos de gestin de una
empresa, como puede ser de gestin de clientes, contabilidad o inventario a travs de
una pgina web.
Estas aplicaciones se encuadran dentro de las arquitecturas cliente / servidor, donde un
ordenador solicita servicios (el cliente) y otro est a la espera de recibir solicitudes y las
responde (el servidor).
Existen multitud de tecnologas que se pueden emplear para programar las aplicaciones
web.

- 26 -

A travs de la historia se ha tenido varias tecnologas para realizar las diferentes


aplicaciones web; as por ejemplo desde el inicio nicamente exista informacin
esttica utilizando HTML bsico y obteniendo como resultado aplicaciones pobres.
Posteriormente ha evolucionado la tecnologa web teniendo mejoras como son: las
presentaciones adecuadas por lado del cliente, introduciendo HTML dinmico y
JAVASCRIPT.
Estos cambios fueron el inicio de una gran evolucin dentro del mbito de aplicaciones
web; as aparecieron nuevas tecnologas como son: CGIs, Java Server Pages, Serverlets,
etc. las cuales implementaron codificacin por lado del servidor.
El CGIs (Common Gateway Interface) es la primera tecnologa de programacin de
aplicaciones web, un Script CGI se ejecutaba en el servidor, y tena la capacidad de
retornar informacin.
Posteriormente aparecieron otras tecnologas para solucionar los puntos dbiles de los
CGIs, as surgieron alternativas como: JSP, Servelets, ASP, PHP. Mediante estas
tecnologas se dota a los servidores un intrprete de algn lenguaje de programacin que
permita incluir el cdigo en las pginas de forma que lo ejecute el servidor, reduciendo
el intervalo de respuesta; En consecuencia tambin surge la aparicin de nuevas
arquitecturas, la ms utilizadas eran las que permiten mezclar los 2 sistemas: un
lenguaje integrado que permita al servidor interpretar comandos "incrustados" en las
pginas HTML y, adems, un sistema de ejecucin de programas mejor enlazado con el
servidor, que no implique los problemas de rendimiento propios de los CGIs.
En la actualidad han surgido tecnologas que permiten realizar las aplicaciones web de
una forma rpida y sencilla permitiendo el ahorro de recursos y tiempo, as como la
tecnologa Java Server Faces. Esta tecnologa trabaja conjuntamente con otras
tecnologas como Java Server Page permitiendo simplificar de forma significativa la
construccin y el mantenimiento de una aplicacin web.
As como tambin tecnologas como Enterprise Java Beans que se encargan de manejar
mdulos concretos de una aplicacin web como son: la Seguridad, Sesiones,
Persistencia Transacciones, etc.

- 27 -

1.2.JUSTIFICACIN.
1.2.1. JUSTIFICACIN TERICA.
La constante, casi frentica, evolucin que est sufriendo el desarrollo de Internet y el
aumento del nmero de usuarios que lo utiliza, est causando un gran auge en el
desarrollo de aplicaciones Web. Este tipo de software permite que un determinado
usuario pueda acceder a informacin almacenada en servidores Web a travs de Internet
o de una intranet. El factor clave radica en la posibilidad de poder acceder a una
determinada aplicacin, de forma transparente al usuario y desde cualquier lugar. Este
valor aadido hace que muchas empresas opten, por ejemplo, realizar intranets
corporativas, permitiendo el despliegue de aplicaciones Web para compartir y gestionar
informacin.
Desde el punto de vista de los profesionales que se dedican al mundo de la informtica
y en particular, al desarrollo de aplicaciones Web, la creciente evolucin del sector
conlleva la mejora e innovacin de los lenguajes y herramientas disponibles para
desarrollar este tipo de software. Adems, muchos de los problemas que se presentan en
el desarrollo de aplicaciones Web no existen en las aplicaciones de escritorio y se debe,
fundamentalmente, a que el protocolo HTTP, en el cual se basa la comunicacin clienteservidor, es un protocolo sin estado. Con lo que cada vez ms, aparecen nuevas
herramientas que hacen que la construccin y diseo de un entorno Web sea ms fcil y
rpida.
Una de los lenguajes de programacin que proporcionan las caractersticas establecidas
anteriormente es Java, ya que es un lenguaje altamente extendido, independiente de la
plataforma hardware/software, orientado a objetos, con gran cantidad de herramientas
que dan soporte a su programacin y adems es relativamente sencillo de utilizar y
mantener.
Uno de los aspectos ms interesantes de Java es el ritmo al que evolucionan tanto sus
tecnologas como las arquitecturas diseadas para soportarlas. Cada poco tiempo
aparecen nuevas libreras, herramientas, frameworks, patrones, etc., y se hace muy
difcil elegir entre ellos y, sobre todo, combinarlos de una manera eficiente que
aproveche toda su flexibilidad y potencia.

- 28 -

Es importante el estudio y seleccin de un conjunto de frameworks J2EE de cdigo


libre. La arquitectura final de aplicacin Web depende de la separacin en capas y
partes que se decida, as como de los patrones de diseo utilizados por las diferentes
(una o varias) herramientas que se unen para el desarrollo del producto final.
Este trabajo investigativo pretende establecer una metodologa para el desarrollo de una
aplicacin web, de modo que la construccin de sta, sea de una manera ms rpida,
ordenada, mantenible y reutilizable, utilizando nuevas tecnologas para el desarrollo de
aplicaciones web, que proporcionen estas funcionalidades como son Java Server Faces
y Enterprise Java Bean
Con el desarrollo de esta metodologa se proporcionar una gua para el desarrollo de
aplicaciones web de forma ptima y gil a los nuevos desarrolladores.
Adems se presentar un caso prctico en el cual se utilizar la metodologa plasmada
de modo que logre alcanzar los beneficios propuestos.
1.2.2. JUSTIFICACIN APLICATIVA.
En la actualidad, las grandes industrias, en su laborar diario, utilizan un sin nmero de
mquinas para la produccin de los productos que se desarrollan, as como de tcnicos
experimentados en la produccin, sin embargo muchas de estas industrias no toman en
cuenta el mantenimiento que se debe llevar diariamente en los elementos que
intervienen en esta produccin o incluso algunas industrias las llevan manualmente. Por
esto la necesidad de desarrollar un software que permita automatizar estos procesos de
mantenimiento, permitiendo una optimizacin de los recursos de la institucin,
aumentando la productividad y rentabilidad de la misma.
La implementacin del Sistema Web De Gestin de Mantenimiento, en el HOSPITAL
PROVINCIAL GENERAL DOCENTE RIOBAMBA, permitir solucionar los
problemas de control y Gestin Preventivo del Mantenimiento Industrial.
Adems que en la actualidad se requiere que en empresas de este tipo se lleve el Control
y la Gestin del Mantenimiento Industrial de manera Informtica para que dicha
empresa se pueda certificar con las Normas ISO 9000 que son normas de Calidad.
Lugar de la aplicacin:

- 29 -

HOSPITAL PROVINCIAL GENERAL DOCENTE RIOBAMBA


Alcance:
Este tema de tesis se fundamenta en el desarrollo de una metodologa para la
construccin de una aplicacin web mediante la Integracin del Framework JSF y EJB,
con lo cual se desarrollar el Sistema Web de Gestin de Mantenimiento.
Limitacin:
Para la parte aplicativa se limitar en los siguientes mdulos:
Mdulo de Cuentas de Usuario.

Registro de Usuarios.

Mdulo De Gestin. En este mdulo se tienen varios sub-mdulos como son:

Tcnicos.

Equipos.

Componentes.

Fallas Equipos.

Estrategias.

Ubicaciones Tcnicas.

Todos estos mdulos constaran de Ingresar, Modificar, Eliminar, Seleccionar.


Mdulo de Planificacin y Control de Mantenimiento Industrial

Asignacin de Estrategias a Equipos.

Asignacin de Tcnicos a Actividades.

Asignacin de Componentes a equipos.

Reportes.

Reporte Plan de Mantenimiento.

Reporte de Tareas Asignadas

- 30 -

1.3.OBJETIVOS.
1.3.1. GENERAL.
Desarrollar una metodologa para construir una aplicacin web mediante la
integracin de Java Server Face y Enterprise Java Beans, y aplicar en el
desarrollo de un sistema web para el Hospital Provincial General Docente
Riobamba.
1.3.2. ESPECFICOS.
Analizar el framework Java Server Faces y el API Enterprise Java Bean.
Estudiar y desarrollar la integracin de Java Server Faces con Enterprise
Java Bean.
Desarrollar la metodologa para la construccin de una aplicacin web
mediante la integracin de Java Server Face y Enterprise Java Bean.
Desarrollar el mdulo de Plan de Mantenimiento en un software de gestin
de mantenimiento, utilizando la tecnologa de Java Server Faces integrado
con Enterprise Java Bean.
1.4.HIPTESIS.
Mediante el desarrollo de una metodologa para la construccin de una aplicacin web a
travs de la integracin de las tecnologas JSF y EJB se minimizar el tiempo en la
construccin y mantenimiento de aplicaciones web.

- 31 -

CAPTULO II.

2. JAVA SERVER FACES Y ENTERPRISE JAVA BEAN.


2.1.JAVA SERVER FACES.
2.1.1. INTRODUCCIN A JSF.
Tradicionalmente, las aplicaciones web se han codificado mediante pginas JSP1 que
reciben peticiones a travs de formularios y construyen como respuesta pginas HTML2
mediante ejecucin directa o indirecta, a travs de bibliotecas de etiquetas de cdigo
JAVA, lo que permite acceder a bases de datos para obtener los resultados a mostrar,
con el fin de realizar operaciones marginales como insertar o modificar registros en
tablas relacionales.
Java Server Faces (JSF) pretende facilitar la construccin de estas aplicaciones
proporcionando un entorno de trabajo (framework) va web que gestione las acciones
producidas por el usuario en su pgina HTML y las traduce a eventos que son enviados
al servidor con el objetivo de regenerar la pgina original y reflejar los cambios
pertinentes provocados por dichas acciones.
Cualquier evento realizado sobre una pgina JSF incurre en una carga sobre la red, ya
que el evento debe enviarse a travs de sta al servidor, y la respuesta de ste debe
devolverse al cliente; por ello, el diseo de aplicaciones JSF debe hacerse con cuidado
1
2

JSP: Tecnologa Java que permite generar contenido dinmico para web.
HTML: Lenguaje de Marcado predominante para la elaboracin de pginas web

- 32 -

cuando se pretenda poner las aplicaciones a disposicin del mundo entero a travs del
internet. Aquellas aplicaciones que vayan a ser utilizadas en una intranet podrn
aprovecharse de un mayor ancho de banda y producirn una respuesta mucho ms
rpida.
2.1.2. APLICACIONES JAVA SERVER FACES.
En su mayora, las aplicaciones JSF son como cualquier otra aplicacin web Java. Se
ejecutan en un contenedor de servlets3 de Java y, tpicamente, contienen:
Componentes JavaBeans (llamados objetos del modelo en tecnologa JSF)
conteniendo datos y funcionalidades especficas de la aplicacin.1
Oyentes de Eventos.
Pginas, (principalmente pginas JSP).
Clases de utilidad del lado del servidor, como beans4 para acceder a las bases de
datos.
Adems posee:
Una librera de etiquetas personalizadas para dibujar componentes UI en una
pgina.
Una librera de etiquetas personalizadas para representar manejadores de
eventos, validadores y otras acciones.
Componentes UI representados como objetos con estado en el servidor.
Toda aplicacin JSF debe incluir una librera de etiquetas personalizadas que define las
etiquetas que representan componentes UI, as como una librera de etiquetas para
controlar otras acciones importantes, como validadores y manejadores de eventos. La
implementacin de JSF de Sun proporciona estas dos libreras. La librera de etiquetas
de componentes elimina la necesidad de codificar componentes UI en HTML u otro
lenguaje de marcas, lo que se traduce en el empleo de componentes completamente
reutilizables. Y la librera principal (core) hace fcil registrar eventos, validadores y
otras acciones de los componentes.

Servlets: Permiten generar todas las pginas web de forma dinmica a partir de los parmetros de la
peticin que enve el navegador web.
4
Beans: Componente hecho en software que se puede reutilizar.

- 33 -

Como librera de etiquetas de componentes puede usarse la librera html_basic incluida


con la implementacin de referencia de la tecnologa JSF, aunque tambin es posible
definir una librera de etiquetas personalizadas que dibuje componentes propios o que
proporcione una salida distinta a HTML.
Otra ventaja importante de las aplicaciones JSF es que los componentes UI de la pgina
estn representados en el servidor como objetos con estado. Esto permite a la aplicacin
manipular el estado del componente y conectar los eventos generados por el cliente a
cdigo en el lado del servidor.
Finalmente, la tecnologa JSF permite convertir y validar datos sobre componentes
individuales e informar de cualquier error antes de que se actualicen los datos en el lado
del servidor.
Debido a la divisin de labores que permite el diseo de la tecnologa JSF, el desarrollo
y mantenimiento de una aplicacin JSF se puede realizar muy rpida y fcilmente.
Aunque en muchos equipos, los desarrolladores individuales pueden interpretar ms de
uno de esos roles, resulta muy til considerar la tecnologa JSF desde varias
perspectivas basadas en la responsabilidad principal que tiene cada participante:
Autores de pginas, que utilizan un lenguaje de marcas, como HTML, para
construir pginas para aplicaciones web. Cuando se utiliza la tecnologa JSF, los
autores de pginas casi siempre usarn exclusivamente la librera de etiquetas.
Desarrolladores de aplicaciones, que programan los objetos del modelo,
los manejadores de eventos, los validadores, y la navegacin de pginas. Los
desarrolladores de aplicaciones tambin pueden proporcionar las clases de
utilidad necesarias.
Escritores de componentes, que tienen experiencia en programar interfaces de
usuario y prefieren crear componentes personalizados utilizando un lenguaje de
programacin. Esta gente puede crear sus propios componentes desde cero, o
puede extender los componentes estndares proporcionados por JSF.

- 34 -

Vendedores de herramientas, que proporcionan herramientas que mejoran la


tecnologa JSF para hacer incluso ms sencilla la construccin de interfaces de
usuario en el lado servidor.
Para las aplicaciones web pueden ser muy convenientes frameworks como JSF, Struts,
Spring, etc., pero stos no servirn (a no ser a costa de un gran esfuerzo) para hacer
portales. Para este segundo caso sera ms adecuado usar gestores de contenidos como
Lenya, OpenCMS, etc.
2.1.2.1.CARACTERSTICAS.
La tecnologa JSF constituye un marco de trabajo de interfaces de usuario del lado del
servidor para aplicaciones web basadas en tecnologa Java y en el patrn MVC (Modelo
Vista Controlador).
Los principales componentes de la tecnologa JSF son:
Una API y una implementacin de referencia para:
o Representar componentes de interfaz de usuario y manejar su estado.
o Manejar eventos, validar en el lado del servidor y convertir datos.
o Definir la navegacin entre pginas.
o Soportar internacionalizacin y accesibilidad.
o Proporcionar extensibilidad para todas estas caractersticas.
Una librera de etiquetas Java Server Pages personalizadas para dibujar
componentes de interfaces de usuario dentro de una pgina JSP.
Este modelo de programacin bien definido y la librera de etiquetas para componentes
de interfaz de usuario facilita de forma significativa la tarea de la construccin y
mantenimiento de aplicaciones web con interfaces de usuario en el lado del servidor.
Con un mnimo esfuerzo es posible:
Conectar eventos generados en el cliente a cdigo de la aplicacin en el lado
servidor.
Mapear componentes de interfaz de usuario a una pgina de datos en el lado
servidor.
Construir una interfaz de usuario con componentes reutilizables y extensibles.

- 35 -

La interfaz de usuario que se crea con la tecnologa JSF se ejecuta en el servidor y se


renderiza en el cliente. Ver figura II.1.

Figura II.1: Diagrama de una aplicacin JSF.

La pgina JSP miform.jsp, especifica los componentes de la interfaz de usuario


mediante etiquetas personalizadas definidas por la tecnologa JSF. La interfaz de
usuario de la aplicacin web (representada por miUI en la figura) maneja los objetos
referenciados por la pgina JSP, que pueden ser de los siguientes tipos:
Objetos componentes que mapean las etiquetas sobre la pgina JSP.
Oyentes de eventos, validadores y conversores registrados y asociados a los
componentes.
Objetos del modelo que encapsulan los datos y las funcionalidades de los
componentes especficos de la aplicacin (lgica del negocio).
2.1.2.2.BENEFICIOS DE JSF.
Una de las ventajas de que JSF sea una especificacin estndar es que pueden
encontrarse implementaciones de distintos fabricantes. Esto permite no vincularse
exclusivamente con un proveedor concreto, y poder seleccionar el que ms interese en
cada caso segn el nmero de componentes que suministra, el rendimiento de stos,
soporte proporcionado, precio, poltica de evolucin, etc.
JSF trata la vista (la interfaz de usuario) de una forma algo diferente a lo que se est
acostumbrado en aplicaciones web, ya que este tratamiento es mucho ms cercano al
estilo de Java Swing, Visual Basic o Delphi, donde la programacin de la interfaz se

- 36 -

hacer a travs de componentes y est basada en eventos (pulsacin de un botn, cambio


en el valor de un campo, etc.).
JSF es muy flexible. Por ejemplo, permite crear nuestros propios componentes, y/o
crear nuestros propios renderizadores para pintar los componentes en la forma que ms
convenga.
Una de las grandes ventajas de la tecnologa JSF es que ofrece una clara separacin
entre el comportamiento y la presentacin. Las aplicaciones web construidas con
tecnologa JSP conseguan parcialmente esta separacin. Sin embargo, una aplicacin
JSP no puede mapear peticiones HTTP5 al manejo de eventos especficos de los
componentes o manejar elementos UI como objetos con estado en el servidor. La
tecnologa JSF permite construir aplicaciones web que introducen realmente una
separacin entre el comportamiento y la presentacin, separacin slo ofrecida
tradicionalmente por arquitecturas UI del lado del cliente.
Separar la lgica de negocio de la presentacin tambin permite que cada miembro del
equipo de desarrollo de la aplicacin web se centre en su parte asignada del proceso de
diseo, y proporciona un modelo sencillo de programacin para enlazar todas las piezas.
Por ejemplo, personas sin experiencia en programacin pueden construir pginas JSF
usando las etiquetas de componentes UI que sta tecnologa ofrece, y luego enlazarlas
con cdigo de la aplicacin sin escribir ningn script ni algo parecido.
Otro objetivo importante de la tecnologa JSF es mejorar los conceptos familiares de
componente-UI y capa-web sin limitarnos a una tecnologa de script particular o un
lenguaje de marcas. Aunque la tecnologa JSF incluye una librera de etiquetas JSP
personalizadas para representar componentes en una pgina JSP, las APIs6 de JSF se
han creado directamente sobre el API Java Servlet. Esto permite, tericamente, hacer
algunas cosas avanzadas: usar otra tecnologa de presentacin junto a JSP, crear
nuestros propios componentes personalizados directamente desde las clases de
componentes, y generar salida para diferentes dispositivos cliente, entre otras.

HTTP: Mtodo ms comn de intercambio de informacin en la www, el mtodo mediante el cual se


transfieren las pginas web a un ordenador.
6
API: Conjunto de funciones y procedimientos para ser utilizado por otro software como una capa de
abstraccin.

- 37 -

En otras palabras, la tecnologa JSF proporciona una rica arquitectura para manejar el
estado de los componentes, procesar los datos, validar la entrada del usuario, y manejar
eventos.
2.1.2.3.ETIQUETAS JSF.
JSF dispone de un conjunto bsico de etiquetas que permiten crear fcilmente
componentes dinmicos en las pginas web. Estas etiquetas son:
h:commandButton. Un botn al que se puede asociar una accin.
h:commandLink. Un enlace hipertexto al que se puede asociar una accin.
h:dataTable. Crea una tabla de datos dinmica con los elementos de una
propiedad de tipo Array o Map del bean.
h:form. Define el formulario JSF en la pgina JSP.
h:graphicImage. Muestra una imagen jpg o similar.
h:inputHidden. Incluye un campo oculto del formulario.
h:inputSecret. Incluye un campo editable de tipo contrasea (no muestra lo que
se escribe).
h:inputText. Incluye un campo de texto normal.
h:inputTextarea. Incluye un campo de texto multilnea.
h:message. Imprime un mensaje de error en la pgina (si se ha producido
alguno).
h:messages. Imprime varios mensajes de error en la pgina, si se han producido.
h:outputFormat.

Muestra

texto

parametrizado.

Utiliza

la

clase

java.text.MessageFormat de formateo.
h:outputLabel. Muestra un texto fijo.
h:outputLink. Crea un enlace hipertexto.
h:outputText. Crea una casilla de texto.
h:panelGrid. Crea una tabla con los componentes incluidos en el panelGrid.
h:panelGroup. Agrupa varios componentes para que cierto componente los
trate como un nico componente (por ejemplo para meter varios componentes en
una celda de un panelGrid).
h:selectBooleanCheckbox. Crea una casilla con dos estados: activado y
desactivado.

- 38 -

h:selectManyCheckbox. Crea un conjunto de casillas activables.


h:selectManyListbox. Crea una lista que permite seleccionar mltiples
elementos.
h:selectManyMenu. Crea una lista desplegable de seleccin mltiple.
h:selectOneListbox. Crea una lista en la que se puede seleccionar un nico
elemento.
h:selectOneMenu. Crea na lista desplegable de seleccin.
h:selectOneRadio. Crea una lista de botones, redondos normalmente,
excluyentes.
2.1.2.4.BACKBEANS.
A las clases java que se asocian a los formularios JSF se les denomina backend beans ya
que son los beans (clases java) que estn detrs del formulario. Estos beans se
referencian en el fichero de configuracin de JSF en el apartado de managed beans, ya
que son beans gestionados por el controlador JSF. ste se encarga de su construccin y
destruccin automticas cuando es necesario.
2.1.2.4.1. ESTRUCTURA DE LAS PGINAS.
En su versin ms sencilla, cada pgina JSF est formada por una pgina JSP que
contiene un formulario (HTML FORM) y un backbean.
El controlador JSF registra en el servidor de aplicaciones un tipo especial de peticin,
tipicamente *.jsf, que estar asociado a estas pginas.
El primer caso comienza cuando el usuario realiza en su navegador una peticin de
navegacin a una URL de tipo *.jsf. Cuando al servidor web llega una peticin del tipo
pgina JSF, el controlador JSF entra en funcionamiento.
Primero comprueba si es la primera vez que se accede a dicha pgina. Si es as, carga la
pgina JSP asociada pagina.jsp y la procesa construyendo en memoria la representacin
de los controles de la pgina. Tras esta etapa JSF sabe cmo construir el cdigo HTML
de salida y la lista de controles de usuario que la cumplen, es decir, sabe lo que contiene
y cmo pintarla.

- 39 -

El siguiente paso es asociarle los backbeans. Para ello, del procesamiento de la pgina
JSP, el controlador ha obtenido la lista de backbeans asociados, por lo que procede a
buscarlos en sus correspondientes mbitos de la aplicacin como la request y la session.
Los beans que no existan se crean llamando a los constructores de sus clases, definidos
en la seccin de managed beans del fichero de configuracin de JSF.
El tercer paso es dar valores a las propiedades de los elementos JSF de la pgina. Aqu
juega un papel fundamental el lenguaje de expresiones de JSF, que es parecido al
lenguaje de expresiones que se permite en las pginas JSP normales. En su versin ms
sencilla una expresin JSF sera del tipo #{mibackbean.propiedad}.
Finalmente el servidor devuelve al usuario una pgina creada a partir de una pgina JSP
que incluye normalmente etiquetas JSF, cuyos valores se extraern del backbean
asociado, ahora ya actualizados.
2.1.2.5.JSF Y AJAX.
JSF es un framework que lanza muchas peticiones al servidor. Para optimizar dicho
dilogo estn empezando a aparecer implementaciones de JSF que incorporan AJAX en
sus etiquetas. Esto permite actualizar los componentes en el navegador del usuario de
manera selectiva, sin necesidad de recargar la pgina completa. La combinacin JSF y
AJAX dota a las pginas de gran dinamismo sin complicar el desarrollo, evitando el uso
de javascripts codificado a mano asegurando un mayor soporte a los navegadores web.
2.1.2.6.EL FUTURO DE JSF.
El framework JSF forma parte importante del estndar java J2EE7. De hecho se est
preparando una nueva versin que traer numerosas novedades, sobre todo en lo que se
refiere a su integracin con AJAX. Tambin se est comenzando a utilizar en
numerosas aplicaciones empresariales, ya que permite crear pantallas de usuario
bastante complejas con una cierta facilidad, aunque desde luego no es sencillo la
primera vez que te enfrentas a este framework. En la nueva versin se espera una
mejora sobre el control de las fases del ciclo de vida de la peticin que faciliten la
creacin de componentes JSF complejos que se usan de manera simple.

J2EE: Plataforma de programacin para desarrollar y ejecutar software de aplicaciones en el lenguaje de


programacin Java.

- 40 -

2.1.3. MODELO VISTA CONTROLADOR EN JSF.


2.1.3.1.INTRODUCCIN.
El patrn MVC (Modelo Vista Controlador), ver Figura II.2, permite separar la lgica
de control (qu cosas hay que hacer pero no cmo), la lgica de negocio (cmo se hacen
las cosas) y la lgica de presentacin (cmo interaccionar con el usuario).
Utilizando este tipo de patrn es posible conseguir ms calidad, un mantenimiento ms
fcil, perder el miedo al folio en blanco (existe un patrn de partida por el que empezar
un proyecto), etc. al margen de todo esto, una de las cosas ms importantes que permite
el uso de este patrn consiste en normalizar y estandarizar el desarrollo de Software.

Figura II.2: Arquitectura MVC.

Adems, este modelo de arquitectura presenta otras importantes ventajas:


Hay una clara separacin entre los componentes de un programa; lo cual permite
implementarlos por separado.
Hay una API muy bien definida; cualquiera que use la API, podr remplazar el
modelo, la vista o el controlador, sin demasiada dificultad.
La conexin entre el modelo y sus vistas (ya que puede haber varias) es
dinmica: se produce en tiempo de ejecucin, no en tiempo de compilacin.
2.1.3.2.MODELO.
Todas las aplicaciones software dejan a los usuarios manipular ciertos datos que
proceden de una realidad sobre la que se pretende actuar, como supermercados,

- 41 -

itinerarios de viaje, o cualquier dato requerido en un dominio problemtico particular. A


estos datos en estado puro, que representan el estado de la realidad se les llama modelo:
modelan la parte de la realidad sobre la que se desea actuar.
El modelo, pues, es el objeto que representa y trabaja directamente con los datos del
programa: gestiona los datos y controla todas sus transformaciones. El modelo no tiene
conocimiento especfico de los diferentes controladores y/o vistas, ni siquiera contiene
referencias a ellos. Es el propio sistema el que tiene encomendada la responsabilidad de
mantener enlaces entre el modelo y sus vistas, y notificar a las vistas cundo deben
reflejar un cambio en el modelo.
2.1.3.3.VISTA.
La vista es el objeto que maneja la presentacin visual de los datos gestionados por el
Modelo. Genera una representacin visual del modelo y muestra los datos al usuario.
Interacciona con el modelo a travs de una referencia al propio modelo.
2.1.3.4.CONTROLADOR.
El controlador es el objeto que proporciona significado a las rdenes del usuario,
actuando sobre los datos representados por el modelo. Entra en accin cuando se realiza
alguna operacin, ya sea un cambio en la informacin del modelo o una interaccin
sobre la Vista. Se comunica con el modelo y la vista a travs de una referencia al propio
modelo.
Adems, JSF opera como un gestor que reacciona ante los eventos provocados por el
usuario, procesa sus acciones y los valores de estos eventos, y ejecuta cdigo para
actualizar el modelo o la vista.
2.1.4. MANAGED BEANS Y NAVEGACIN EN JSF.
2.1.4.1.MANAGED BEANS.
Un apartado importante en el diseo de aplicaciones web es la separacin de la
presentacin y la lgica de negocio. JSF usa beans para lograr esta separacin. Las
pginas JSF se refieren a las propiedades del bean, y la lgica de programa est
contenida en el cdigo de implementacin del bean. Los beans son fundamentales para
programar JSF.

- 42 -

Segn la especificacin de los JavaBeans, un Java bean es un componente reutilizable


del software, que puede ser manipulado8. Esta es una definicin bastante imprecisa y,
ciertamente, los beans sirven para una gran variedad de propsitos.
A primera vista, un bean parece ser similar a cualquier otro objeto. Sin embargo, los
beans se manejan de una forma ms concreta. Cualquier objeto se crea y se manipula
dentro de un programa Java llamando a los constructores e invocando a los mtodos.
Sin embargo, los beans pueden ser configurados y manipulados sin programar, a travs
de entornos de trabajo (frameworks) o entornos de desarrollo integrados (IDEIntegrated Development Environment), que los utilizan mediante tcnicas de
introspeccin. En el contexto de JSF, los beans no se utilizan para nada relacionado con
la interfaz de usuario: los beans se utilizan cuando se necesita conectar las clases Java
con pginas web o archivos de configuracin.
Una vez que un bean ha sido definido, puede ser accedido a travs de etiquetas JSF. Por
ejemplo, la siguiente etiqueta lee y actualiza el atributo password del bean usuario:
<h:inputSecret value="#{usuario.password}"/>
ATRIBUTOS.
Las caractersticas ms importantes de un bean son los atributos que posee, tambin
llamados propiedades. Cada uno de stos tiene:
Un nombre.
Un tipo.
Mtodos para obtener y establecer los valores de atributo.
La especificacin de los JavaBeans impone una sola exigencia en una clase bean: debe
tener un constructor predeterminado, sin parmetros. Adems, para que los entornos de
trabajo o de desarrollo puedan acceder a sus atributos mediante introspeccin, una clase
bean debe declarar mtodos get y/o set para cada uno de ellos, o debe definir
descriptores utilizando la clave java.beans.BeanDescriptor.

http://www.sc.ehu.es/sbweb/fisica/cursoJava/applets/javaBeans/fundamento.htm

- 43 -

Un mtodo get() no posee parmetros mientras que un mtodo set() posee un parmetro
y no devuelve ningn valor. Por supuesto, una clase bean puede tener otros mtodos
adems de los get() y set().
EXPRESIONES PARA VALORES INMEDIATOS Y DIRECTOS.
Muchos componentes de interfaz de usuario JSF tienen un valor de atributo que permite
especificar, ya sea un valor inmediato o un valor directo obtenido del atributo de un
bean. Por ejemplo, se puede especificar un valor inmediato de la forma: <h:outputText
value="Hola mundo!"/> o se puede especificar un valor directo: <h:inputText
value="#{usuario.nombre}"/>
MBITO DE LOS BEANS.
Para comodidad del programador de aplicaciones web, un contenedor de servlets
suministra diferentes mbitos: de peticin, de sesin y de aplicacin. Estos mbitos
normalmente mantienen beans y otros objetos que necesitan estar disponibles en
diferentes componentes de una aplicacin web.
mbito de Tipo Peticin.
Es el de vida ms corta. Empieza cuando una peticin HTTP, comienza a tramitarse y
acaba cuando la respuesta se enva al cliente. Por ejemplo, en la siguiente lnea de
cdigo:

<f:loadBundle

basename="mensajes"

var="msjs"/>

la

etiqueta

f:loadBundle hace que la variable BUNDLE solo exista mientras dura la peticin. Un
objeto debe tener un mbito de este tipo slo si lo que se quiere es renviarlo a otra fase
de procesado.
mbito de tipo Sesin.
El navegador enva una peticin al servidor, el servidor devuelve una respuesta, y
entonces ni el navegador ni el servidor tiene cualquier obligacin para conservar
cualquier memoria de la transaccin. Este acomodamiento simple marcha bien para
recuperar informacin bsica, pero es poco satisfactorio para aplicaciones del lado del
servidor. Por ejemplo, en una aplicacin de un carrito compras, necesita al servidor para
recordar los contenidos del carrito de compras.

- 44 -

Por esa razn, los contenedores servlet amplan el protocolo de HTTP para seguir la
pista a una sesin, esto se consigue repitiendo conexiones para el mismo cliente. Hay
diversos mtodos para el rastreo de sesin. El mtodo ms simple es usar cookies: La
pareja nombre/valor la enva el servidor a un cliente, esperando que regresen en
subsiguientes peticiones.
Mientras el cliente no desactive las cookies, el servidor recibe un identificador de sesin
por cada peticin siguiente. Los servidores de aplicacin usan estrategias de retirada,
algo semejante como al URL rewriting, para tratar con esos clientes que no devuelven
cookies. El URL rewriting aade un identificador de sesin a la URL, con lo cual se
parece algo a esto: http://ejemploBasico/index.jsp;jsessionid=64C28D1FC...D28
El rastreo con cookies es completamente transparente al desarrollador

web, y las

etiquetas estndar JSF automticamente rescriben URL si un cliente no usa cookies. El


mbito de sesin permanece desde que la sesin es establecida hasta que sta termina.
Una sesin termina si la aplicacin web invoca el mtodo invalidate en el objeto
HttpSession o si su tiempo expira.
Las aplicaciones Web tpicamente colocan la mayor parte de sus bean dentro de un
mbito de sesin. Por ejemplo, un bean UsuarioBean puede contener informacin
acerca de usuarios que son accesibles a lo largo de la sesin entera. Un bean
CarritoCompraBean puede irse llenando gradualmente durante las demandas que
levantan una sesin.
mbito de Tipo Aplicacin.
Persiste durante toda la aplicacin web. Este mbito es compartido entre todas las
peticiones y sesiones.
2.1.4.2.NAVEGACIN.
Las aplicaciones JSF usan las reglas de navegacin para controlar la navegacin entre
pginas. Cada regla de navegacin especifica cmo ir de una pgina a las dems dentro
de la aplicacin. En la arquitectura MVC, la navegacin de la pgina es una de las
responsabilidades del controlador. Las reglas de navegacin de las aplicaciones JSF
estn contenidas en el archivo faces-config.xml bajo el directorio WEB-INF.

- 45 -

Existen dos tipos diferenciados de navegacin: navegacin esttica y dinmica.


NAVEGACIN ESTTICA.
Considere el caso en el que un usuario rellena un formulario de una pgina web. El
usuario puede escribir en campos del texto, puede hacer clic sobre enlaces, pulsar
botones o seleccionar elementos de una lista, entre otras muchas cosas.
Todas estas acciones ocurren dentro del navegador del cliente. Cuando, por ejemplo, el
usuario pulsa un botn, enva los datos del formulario y stos son gestionados por el
servidor. Al mismo tiempo, el servidor JSF analiza la entrada del usuario y debe decidir
a qu pgina ir para dar la respuesta.
En una aplicacin web simple, la navegacin es esttica. Es decir, pulsar sobre un botn
suele redirigir al navegador a una misma pgina para dar la respuesta. En este caso,
simplemente, a cada botn se le da un valor para su atributo de accin (action), por
ejemplo: <h:commandButton label="Aceptar" action="login"/> Esta accin
desencadenante, debe concordar con la etiqueta outcome del fichero faces-config.xml,
dentro de sus reglas de navegacin.
En esta simple regla de navegacin, se indica que tras la accin login, se navegar a la
pgina hola.jsp, si esta accin ocurre dentro de la pgina index.jsp.
NAVEGACIN DINMICA.
En la mayora de aplicaciones web, la navegacin no es esttica. El flujo de la pgina no
depende de qu botn se pulsa, sino que tambin depende de los datos que el cliente
introduce en un formulario. Por ejemplo, una pgina de entrada al sistema puede tener
dos resultados: El xito o el fracaso.
El resultado depende de una computacin, sea cual sea el nombre y si la contrasea es
legtima. Para implementar una navegacin dinmica, el botn de aceptar debe tener un
mtodo referencia, por ejemplo: <h:commandButton label="Aceptar" action=
"#{loginControlador.verificarUsuario}"/>
En este caso, loginControlador, referencia un bean, y ste debe tener un mtodo
denominado verificarUsuario.

- 46 -

Un mtodo de referencia, en un atributo de accin, no tiene parmetros de entrada y


devuelve una cadena de caracteres, que ser usada para activar una regla de navegacin.
2.2.ENTERPRISE JAVA BEAN.
2.2.1. INTRODUCCION.
Hoy en da,

los desarrolladores pueden construir aplicaciones distribuidas,

transaccionales, seguras y confiables basadas en la tecnologa de servidores de


aplicacin.
Cada vez, las aplicaciones deben ser diseadas, construidas y producidas por menos
dinero, a ms velocidad y utilizando menor cantidad de recursos.
Para reducir costos y acelerar el proceso de desarrollo, Java Plataform Enterprise
Edition (J2EE) provee un enfoque basado en componentes para el diseo, ensamblaje e
instalacin de aplicaciones. La plataforma J2EE provee un modelo de aplicacin
multicapa, componentes reutilizables, un modelo de seguridad unificado, control
flexible de transacciones, soporte de Web Services9 a travs de intercambio de datos
integrados por estndares y protocolos abiertos XML.
Las soluciones basadas en componentes de la plataforma J2EE son desarrolladas en
forma independiente de la implementacin, por lo tanto no se encuentran asociadas a los
productos particulares y a las APIs de los proveedores; llegando en algunos casos a
perder el soporte debido a la falta de actualizacin de la versin del producto.
El servidor de aplicacin (aplication server) nace para resolver estos problemas. Provee
servicios comunes de middleware10 como persistencia, transacciones, distribucin de
objetos, administracin de conexiones, etc. Los proveedores implementan estas
interfaces estndares para integrar y proveer los servicios a sus productos mediante el
servidor de aplicaciones. Por lo tanto los desarrolladores ahora pueden centrarse en la
problemtica central de negocio, o los requerimientos funcionales, que debe resolver la
aplicacin utilizando APIs estndares y para invocar al middleware y decidiendo luego

Web Services: Tecnologa que utiliza un conjunto de protocolos y estndares que sirven para
intercambiar datos entre aplicaciones
10
Middleware: Software de conectividad que ofrece un conjunto de servicios que hacen posible el
funcionamiento de aplicaciones distribuidas sobre plataformas heterogneas.

- 47 -

qu implementaciones especficas utilizar para resolver mejor los requerimientos de tipo


no funcionales.
Los Enterprise JavaBeans (tambin conocidos por sus siglas EJB) son una de las API
que forman parte del estndar de construccin de aplicaciones empresariales J2EE de
Oracle Corporation.
EJB corresponde a una tecnologa Java que permite definir un modelo para el desarrollo
y despliegue de componentes servidor reusables. EJB soporta el desarrollo de
aplicaciones basadas en una arquitectura de objetos distribuidos, en mltiples capas y en
donde la mayor parte de la lgica de la aplicacin se mueve desde el cliente hasta el
servidor. EJB extiende el modelo de componentes que definieron los JavaBeans.
Un "JavaBean" es un componente utilizado en Java que permite agrupar
funcionalidades para formar parte de una aplicacin. Un "EJB" tambin agrupa
funcionalidades para una aplicacin, sin embargo, implica que existe un ambiente de
ejecucin ("deployable component"), "EJB Container. Un "JavaBean" requiere ser
integrado con otros componentes para que ste sea funcional, mientras un "Enterprise
Java Bean" a travs de un "EJB Container" puede ser activado ("deployed").
EJB es una arquitectura de componentes de servidor que simplifica el proceso de
construccin de aplicaciones de componentes empresariales distribuidos en Java.
Con su utilizacin es posible escribir aplicaciones escalables, fiables y seguras sin
escribir cdigo de infraestructura. La existencia de infraestructura permite un desarrollo
ms rpido de la parte servidora.
Dado que son componentes, permiten desarrollar aplicaciones portables entre distintas
plataformas (son Java) y servidores de aplicaciones (especificacin estndar).
Su especificacin detalla cmo los servidores de aplicaciones proveen objetos desde el
lado del servidor que son, precisamente, los EJB:
Comunicacin remota utilizando CORBA11.
Transacciones.
11

CORBA: Standard que permite que diversos componentes de software escritos en mltiples lenguajes
de programacin y que corren en diferentes computadoras puedan trabajar juntos.

- 48 -

Control de la concurrencia.
Eventos utilizando JMS (Java messaging service).
Servicios de nombres y de directorio.
Seguridad.
Ubicacin de componentes en un servidor de aplicaciones.
La especificacin de EJB define los papeles jugados por el contenedor de EJB y,
adems de disponer los EJB en un contenedor.
2.2.2. DEFININ DE EJB.
Los EJB proporcionan un modelo de componentes distribuido estndar del lado del
servidor. El objetivo de los EJB es dotar al programador de un modelo que le permita
abstraerse de los problemas generales de una aplicacin empresarial (concurrencia,
transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lgica
de negocio en s.
El hecho de estar basado en componentes permite que stos sean flexibles y sobre todo
reutilizables.
No hay que confundir los EJB con los JavaBeans. Los JavaBeans tambin son un
modelo de componentes creado por Oracle - Sun Microsystems para la construccin de
aplicaciones, pero no pueden utilizarse en entornos de objetos distribuidos al no
soportar nativamente la invocacin remota (RMI).
2.2.3. VENTAJAS DE EJB.
Un EJB a travs de un "EJB Container" ofrece varios servicios y funcionalidades no
disponibles en un "Java Bean", algunas son las siguientes:
2.2.3.1.SERVICIOS MIDDLEWARE.
Esta posiblemente sea la mayor ventaja de un EJB. Cuando se disea un componente de
software se deben definir varios servicios para su funcionamiento, algunos pueden ser:
Si ocurre un error, qu procedimiento debe ejecutarse?
Si la base de datos especificada se encuentra desactivada, existe otra alternativa?

- 49 -

No fue posible cumplir exitosamente "x" procedimiento se deben retractar sus


acciones parciales o re-invocar la transaccin?
Estos servicios (comnmente llamados "Middleware") por lo general son requeridos
adems de la lgica contenida en los componentes principales; obviamente estos
servicios ("Middleware") an deben ser diseados, sin embargo, mediante un "EJB
Container" se ofrecen estos servicios y es a travs de un "Enterprise Java Bean" que es
posible desarrollar los componentes principales ("lgica de negocios").
2.2.3.2.DIVISIN DE TRABAJO.
La posibilidad de dividir "Servicios" (EJB Container) de "Componentes Principales"
(EJBs) permite una clara divisin de trabajo, esto es, que un diseador de
"componentes" (EJB's) puede concentrar sus esfuerzos en la "lgica de proceso" sin
preocuparse del diseo de servicios. Y de la misma manera un "diseador" de servicios
("Middleware") concentrarse en su rea.
Esta divisin de trabajo trae consigo otra pregunta: Cmo se logra la
interoperabilidad? La interoperabilidad entre "Servicios" y "Componentes" se debe a la
existencia de especificaciones para EJB's, estas especificaciones (parte primordial de
J2EE) definen los requerimientos para un "EJB Container" y los requisitos para un
"Enterprise Java Bean".
2.2.3.3.DIVERSOS VENDEDORES.
El uso de especificaciones para EJB's permite que existan diversos vendedores tanto de
"EJB Containers" los cuales son incluidos en un java application server, as como
"Enterprise Java Beans" los cuales resuelven algn tipo de lgica.
Lo anterior permite ejecutar cualquier "EJB" en cualquier "EJB Container", esto es,
puede adquirir un conjunto de EJB's producidos por Insprise o inclusive desarrollarlos
dentro de su empresa y estos podrn ser ejecutados en un "EJB Container" de IBM,
Insprise o JBoss.
En lo que se refiere a diferencias en costo y calidad, generalmente estas dependen de las
funcionalidades que van ms all de las especificaciones EJB. El "EJB Container" de
IBM ofrece un integracin ms eficiente con sus productos (Domino, DB2), mientras

- 50 -

Insprise puede desarrollar su "EJB Container" orientado hacia ambientes financieros,


Oracle haca manufactura y sus productos en "Bases de Datos", etc.
2.2.3.4.PROCEDIMIENTOS REMOTOS RMI.
Debido a la solucin que intenta ofrecer EJB ("Enterprise Java Beans") su diseo gira
alrededor de procedimientos remotos.
2.2.3.5.DIVERSOS CLIENTES.
Un EJB puede interactuar con una gran gama de clientes desde: JSP o Servlets, bases de
datos, Applets, sistemas ERP (SAP, JDEdward's).
2.2.4. COMPONENTES DE LA ARQUITECTURA.
Con respecto a la arquitectura EJB, se pueden encontrar los siguientes componentes que
la estructuran:
2.2.4.1.OBJETO EJB.
Los Enterprise Beans no son estrictamente objetos remotos. Cuando un cliente necesita
utilizar una instancia de una clase Enterprise Bean, el cliente nunca invoca el mtodo
directamente en la instancia real. La invocacin es interceptada por el contenedor EJB y
delegada a la instancia del Enterprise Bean. Interceptando las invocaciones, el
contenedor EJB puede realizar en forma automtica las invocaciones de middleware en
forma implcita. Por lo tanto el desarrollador de componentes no necesita escribir,
corregir o mantener invocaciones a las APIs de middleware. Algunos de los servicios
que se pueden obtener en forma implcita mediante la intercepcin son:
Administracin implcita de transacciones distribuidas. Las transacciones
permiten realizar operaciones en forma robusta y determinstica en ambientes
distribuidos. El contenedor EJB provee un servicio de transacciones, que consta
de una implementacin a bajo nivel de administracin de transacciones a bajo
nivel. El servicio de transacciones debe ser expuesto a travs de la API de alto
nivel JTA12. JTA es una interfaz de alto nivel que permite controlar las
transacciones.

12

JTA: Establece una serie de Interfaces java entre el manejador de transacciones y las partes
involucradas en el sistema de transacciones distribuidas.

- 51 -

Seguridad implcita. La seguridad suele ser una consideracin importante para


el desarrollo de aplicaciones multicapa distribuida. La plataforma Java Edicin
Estndar (J2SE), define un servicio de seguridad robusto que permite autorizar y
autenticar usuarios, asegurando los componentes instalados. EJB agrega a este
concepto la nocin de seguridad transparente o declarativa, que permite obtener
los beneficios de seguridad sin necesidad de escribir las invocaciones a la API
de JAAS. (Java Authorization and Authentication Service).
Administracin implcita de recursos y ciclos de vida de los componentes. El
contenedor EJB administra implcitamente los recursos utilizados por los
Enterprise Beans, como threads, sockets o conexiones a la base de datos. El
ciclo de vida de los Enterprise Beans tambin es administrado, permitiendo al
contenedor EJB reutilizar las instancias de los Enterprise Beans cuando sea
necesario.
Persistencia implcita. La persistencia de datos es un requerimiento de
cualquier aplicacin que requiere almacenamiento permanente. EJB ofrece
asistencia para almacenar los datos persistentes de los objetos en las capas
subyacentes de almacenamiento y luego obtener esa informacin.
Acceso remoto implcito. La clase Enterprise Bean no puede ser invocada a
travs de la red directamente porque es una clase sin soporte para redes. El
contenedor EJB soporta invocacin remota mediante el encapsulamiento de los
beans en objetos con soporte para red. Los objetos con soporte para red reciben
invocaciones desde el cliente y las delegan a las instancias correspondientes de
los beans. Esto ahorra al programador tener que preocuparse por temas referidos
al uso de redes.
Soporte

implcito.

Los

contenedores

EJB

automticamente

reciben

invocaciones concurrentes de los clientes. El contenedor EJB provee soporte de


threads, instanciando las mltiples copias necesarias de los componentes,
instanciando mltiples Enterprise Beans y alojando las instancias en threads. De

- 52 -

esta forma se obtiene concurrencia robusta sin necesidad de escribir cdigo


multithread.
Transparencia de ubicacin de componentes en forma implcita. Los clientes
de los componentes se encuentran desacoplados de la ubicacin especfica del
componente que se encuentra siendo utilizado.
Monitoreo implcito. El contenedor EJB puede realizar un seguimiento de los
mtodos invocados y recopilar informacin estratgica para optimizacin y
balance de carga inteligente.
El contenedor EJB acta como una capa de direccin entre el cdigo del cliente y el del
Enterprise Bean. Esta capa de indireccin se manifiesta como un objeto con soporte de
red llamado objeto EJB (EJB object) que acta como el interceptor de invocaciones.
El objeto EJB es un objeto que conoce sobre redes, transacciones, persistencia y ms.
Tiene la inteligencia para saber cmo realizar la lgica intermedia que el contenedor
EJB requiere antes de la invocacin a la instancia de la clase Enterprise Bean. El objeto
EJB replica y expone todos los mtodos de negocios expuestos por el Enterprise Bean y
delega todas las invocaciones del cliente a los Enterprise Beans. La figura II.3 muestra
la funcin de los objeto EJB.

Figura II.3: Funcin de los objetos EJB.

- 53 -

El Objeto EJB puede pensarse como una parte fsica del contenedor. Todos tienen
cdigo especfico del container dentro. Cada contenedor puede manejar internamente el
middleware en forma diferente, el proveedor del contenedor (vendor) genera las clases
para los objetos EJB en forma automtica. Existen varias estrategias para la generacin
de los EJB Object.
2.2.4.2.SERVIDOR DE EJB (EJB SERVER).
El servidor EJB proporciona el ambiente o entorno necesario para soportar la ejecucin
de aplicaciones que han sido desarrolladas utilizando la tecnologa de EJB. Este
servidor administra y coordina la ubicacin de los recursos para que sean utilizados por
las aplicaciones.
2.2.4.3.EJB CONTAINER.
Un servidor EJB debe ser capaz de proveer uno o ms contenedores EJB. El concepto
de container es anlogo al concepto de hogar, esto queda ms claro al constatar que es
el EJB container quien administra a los beans contenidos en l.
Por cada EJB, el contenedor es responsable de registrarlo, de proporcionar una interfaz
remota para l, de crear o destruir instancias del objeto, realizar chequeos de seguridad
para el objeto, manejar su estado activo y coordinar transacciones distribuidas.
Como una funcionalidad opcional, el EJB container puede incluso llegar a manejar toda
la informacin persistente dentro del objeto.
2.2.5. FUNCIONAMIENTO DE LOS EJB.
Los EJB se disponen en un contenedor EJB dentro del servidor de aplicaciones. La
especificacin describe cmo el EJB interacta con su contenedor y cmo el cdigo
cliente interacta con la combinacin del EJB y el contenedor.
Cada EJB debe facilitar una clase de implementacin Java y dos interfaces Java. El
contenedor EJB crear instancias de la clase de implementacin Java para facilitar la
implementacin EJB. Las interfaces Java son utilizadas por el cdigo cliente del EJB.
Las dos interfaces, conocidas como interfaz "home" e interfaz remota, especifican las
firmas de los mtodos remotos del EJB. Los mtodos remotos se dividen en dos grupos:

- 54 -

Mtodos que no estn ligados a una instancia especfica, por ejemplo


aquellos utilizados para crear una instancia EJB o para encontrar una entidad
EJB existente. Estos mtodos se declaran en la interfaz "home".

Mtodos ligados a una instancia especfica. Se ubican en la interfaz remota.

Dado que se trata simplemente de interfaces Java y no de clases concretas, el


contenedor EJB genera clases para esas interfaces que actuarn como un proxy en el
cliente. El cliente invoca un mtodo en los proxies generados que a su vez sita los
argumentos del mtodo en un mensaje y enva dicho mensaje al servidor EJB. Los
proxies usan RMI-IIOP13 para comunicarse con el servidor EJB.
El servidor llamar a un mtodo correspondiente a una instancia de la clase de
implementacin Java para manejar la llamada del mtodo remoto.
2.2.5.1.INTERFAZ REMOTA.
Proporciona el acceso a los mtodos dentro del bean. Un objeto EJB representa la visin
del usuario del bean. El objeto EJB revela todas las interfaces de la aplicacin
vinculadas al objeto, pero no aquellas interfaces que permiten al contenedor administrar
y controlar al objeto.
El wrapper14 de objeto EJB permite que el contenedor EJB intercepte todas las
operaciones que se hagan sobre el bean. Dicho, de otra forma, cada vez que el cliente
invoca un mtodo sobre un objeto EJB, la peticin pasa por el EJB container antes de
ser traspasada al bean.
El contenedor implementa la administracin de estados, el control de transacciones,
seguridad y servicios de persistencia en forma transparente tanto para el cliente como
para el bean.
2.2.5.2.INTERFAZ EJB HOME.
Esta interfaz proporciona el acceso a los servicios del ciclo de vida del EJB. Los
clientes pueden usar esta interfaz para crear o destruir instancias del bean en materia de

13
14

RMI-IIOP: Denota la interfaz RMI de Java sobre el sistema CORBA.


Wrapper: Clases que modelan los tipos de datos primitivos tales como enteros y flotantes

- 55 -

servicios. El modelo EJB provee soporte para un determinado nmero de servicios


implcitos (Ver Figura II.4).

Figura II.4: Interfaz EJB Home.

2.2.5.3.MANEJO DE ESTADOS.
Los EJB no requieren guardar o recuperar en forma explcita los estados del objeto entre
llamado y llamado de los mtodos, debido a que el contenedor EJB se encarga de llevar
a cabo estas tareas en beneficio del mismo bean.
2.2.5.4.SEGURIDAD.
Todas las tareas involucradas con este punto (chequeos de seguridad), como por
ejemplo, la autenticacin de usuarios o el chequeo de niveles de autorizacin, quedan en
manos del container del bean.
2.2.5.5.TRANSACCIONES.
Los Beans no necesitan explicitar individualmente el cdigo de demarcacin
transaccional para poder participar en transacciones distribuidas. Es el EJB container
quien se encarga de manejar la partida, el enroollment, el compromiso y el rollback de
transacciones.

- 56 -

2.2.5.6.PERSISTENCIA.
Un bean no necesita retirar o almacenar objetos de datos persistentes desde una base de
datos, ya que el EJB container se encarga de manejar datos persistentes.
2.2.6. TIPOS DE EJB.
Existen 3 tipos de EJB:
1. EJB de Entidad.
2. EJB de Sesin.
3. EJB dirigidos por mensaje.
2.2.6.1.EJB DE ENTIDAD.
Son objetos persistentes, que representan una vista de objeto de una determinada fuente
de datos. Esto permite que el EJB manipule informacin residente en sistemas ajenos al
"EJB Container. En otras palabras, un "Entity EJB" manipula una copia/reflejo de
informacin que reside en otro sistema. Cada instancia de un bean de identidad se
identifica a travs de una nica clave primaria. Las beans de entidad pueden crearse
bien creando un objeto (Create()) o insertando directamente datos en la fuente de datos.
Dado que el estado del bean se mantiene en la fuente de datos, este tipo de beans
pueden recuperarse ante una cada del sistema.
Un bean de entidad a diferencia de un bean de sesin trabaja en conjuncin con un
depsito de informacin (generalmente una base de datos), esto permite que el EJB
manipule la informacin residente en sistemas ajenos al EJB Container.
2.2.6.2.EJB DE SESIN.
Un Bean de Sesin permite realizar cierta lgica solicitada por un cliente ya sea un
JSP/servlet, Applet15 e inclusive otro EJB. Existen dos tipos de Beans de Sesin:
1. Beans de Sesin sin Estado (Stateless Session EJBs): Este tipo de EJB
como su nombre lo indica no mantiene estado ("Stateless") en el EJB
Container. Estos EJB's son utilizados para realizar tareas rutinarias que no
requieren identificar o rastrear al cliente. Dado que este tipo de bean no
15

Applet: Componente de una aplicacin que se ejecuta en el contexto de otro programa, por ejemplo un
navegador web.

- 57 -

mantiene estado, los beans de sesin no estn ligados a un cliente particular,


de manera que cualquier instancia de un bean de esta clase puede usarse para
dar servicio a un cliente. Algunos EJB's de este tipo son: operaciones
matemticas complejas, bsquedas generales, etc. Cualquier informacin de
estado, en caso de que fuera necesario, se mantiene por el cliente.

2. Beans de Sesin con Estado (Statefull Session EJBs): Permiten mantener


la sesin del cliente en el "EJB Container", de esta manera el cliente puede
trabajar con cierto juego de datos especfico administrado por el "EJB
Container". Dado que el estado se mantiene en este tipo de EJB, el servidor
de aplicacin maneja pares cliente-bean. Cada instancia de un cierto EJB se
crea bajo peticin de un cliente concreto, y en principio es un recurso privado
para ese cliente (aunque puede compartirse entre clientes, usando el handle
del bean). En esencia, un bean con estado acta como una extensin del
cliente, con la excusa de que cierta carga del cliente se distribuye en el
servidor de aplicaciones. Los datos de estado no sobreviven a una cada del
servidor, salvo que la implementacin particular soporte persistencia frente a
cadas del servidor. Los beans con estado pueden acceder a recursos
persistentes (como bases de datos o ficheros) pero, a diferencia de los beans
de entidad, no representan datos.
2.2.6.3.EJB DIRIGIDOS POR MENSAJE.
Son los nicos beans con funcionamiento asncrono. Usando el Java Messaging
System16 (JMS), se suscriben a un tema (topic) o a una cola (queue) y se activan al
recibir un mensaje dirigido a dicho tema o cola. No requieren de su instanciacin por
parte del cliente.
2.2.7. ARCHIVO EJB-JAR.
Una vez creadas las clases Enterprise Bean, las interfaces home, la interfaces remotas y
los descriptores, es necesario empaquetarlos en un mdulo EJB mediante un archivo
EJB-jar con extensin .jar (Ver Figura II.5).
16

Java Messaging System: Estndar de mensajera que permite a los componentes de aplicaciones
basados en la plataforma Java2 crear, enviar, recibir y leer mensajes.

- 58 -

Figura II.5: Archivo EJB-jar.

Una vez construido el archivo EJB-jar, el Enterprise Bean est completo, y es una
unidad instalable en cualquier servidor de aplicacin J2EE. Una vez instalado, las
herramientas provistas por el proveedor del contenedor EJB son las responsables de
descomprimir, leer, y extraer la informacin contenida en el archivo EJB-jar. Luego el
instalador realiza tareas especficas del proveedor, como generar los objetos EJB, los
objetos home, importar el Enterprise Bean dentro del container, y configurarlo. El
soporte para los archivos EJB-jar es un estndar y es una funcionalidad requerida por
todas las herramientas EJB.
Es importante destacar que ms de un Enterprise Bean puede estar contenido en un
mismo archivo EJB-jar, permitiendo empaquetar mdulos o aplicaciones enteras en un
solo archivo.

- 59 -

CAPTULO III.

3. INTEGRACIN DE JSF Y EJB.


3.1.INTRODUCCIN.
EJB3 es la ltima versin de EJB (Enterprise Java Beans). EJB es una especificacin de
un framework que define unos componentes software (los Enterprise Java Beans), que
debidamente diseados y configurados por el desarrollador, y alojados en un servidor de
aplicaciones J2EE, conforman la capa del modelo en el patrn MVC (a la capa del
modelo tambin se le llama lgica del negocio - bussiness logic - en el entorno de la
geston empresarial).
EJB3 provee una gran cantidad de funcionalidad al desarrollador a la hora de
implementar el modelo, funcionalidad que de una u otra forma se tendra que
implementar por s mismo. Entre otras se encuentran las siguientes caractersticas:
Proceso de Transacciones. El servidor J2EE se encarga de que las
modificaciones que se realicen al modelo y que estn encerradas dentro de una
"transaccin" se realicen todas o ninguna.
Integracin con los servicios de persistencia que ofrece Java Persistence
API (JPA). JPA integra el mapeo ORM como una forma de persistencia para
los 'beans de entidad' de EJB. Su equivalente en Ruby on Rails es el
ActiveRecord. En realidad, la parte de persistencia de EJB3 es la integracin en

- 60 -

el API de EJB de los conceptos de ORM implementados con gran xito por
Hibernate17.
Control de concurrencia.
Piscinas de recursos y clustering, que asegura la escalabilidad del producto.
Seguridad.
JSF (Java Server Faces), por otro lado, es un framework de desarrollo de aplicaciones
web en Java, tambin para ser alojado en un servidor de aplicaciones JEE, cuyo diseo
implementa el patrn MVC al completo. Es decir, un desarrollador puede implementar
una aplicacin Web completa slo usando las herramientas de JSF. El problema es que
JSF le deja al desarrollador casi todo el trabajo de implementar la capa de modelo, y la
capa de presentacin que incluye es muy pobre. Sin embargo, la capa del controlador es
excelente, y adems - y esto es lo ms importante de JSF - da muchas facilidades para
ser extendido.
JSF implementa la conexin del controlador con la capa de modelo a travs de los JSF
Managed Java Beans. El sistema es que el desarrollador asocia los inputs del usuario
con objetos y mtodos de los Managed Java Beans.
Si un desarrollador quiere realizar una aplicacin JSF + EJB3, la forma correcta es crear
el modelo en EJB3, y realizar las llamadas a ste modelo desde los JSF Managed Java
Beans de la aplicacin.
En la mayora de las aplicaciones, esto genera mucha duplicacin del trabajo.
Las longitudes de los ciclos de vida de los componentes de una aplicacin viene dada
por los mbitos de aplicacin (scopes) disponibles en el framework para dichos
componentes.
Los mbitos de aplicacin de los JSF Java Beans pueden ser:
Aplicacin.
Sesin.
Pgina.
17

Hibernate: Herramienta JAVA que facilita el mapeo de atributos entre una base de datos relacional
tradicional y el modelo de objetos de una aplicacin

- 61 -

Es decir, el controlador JSF es capaz de manejar componentes del modelo con ciclos de
vida de dichas longitudes.
Cualquier otro ciclo de vida de componentes del modelo tiene que ser implementado
por el programador.
3.2.ANTECEDENTES JSF Y EJB.
A pesar del esfuerzo realizado por el grupo de expertos encargado de definir las
especificaciones que forman parte de JEE por simplificar el desarrollo de aplicaciones
JEE, hay que tener en cuenta que JEE se trata de una plataforma compleja, alrededor de
la cual se concentran usa serie de APIs y de conceptos, y que sin un conocimiento
medio de stos ser difcil sacar el mximo partido a JEE, por lo que aunque a primera
vista parezca sencillo el desarrollo de aplicaciones se tendr que intentar conocer al
mximo todo aquello que se mueve a su alrededor si se quiere sacar rendimiento a JEE.
En este captulo se mostrar cmo desarrollar un prototipo de aplicacin en la que se
integrar dos tecnologas que forman parte de esta renovada plataforma, EJB y Java
Server Faces.
Para ello se utilizar NetBeans, cuyo equipo tambin ha realizado grandes esfuerzos por
simplificar al mximo el desarrollo de aplicaciones JEE con este IDE.
3.3.APLICACIN CON JSF Y EJB.
En este captulo se demostrar un prototipo de integracin entre las dos tecnologas Java
Server Face y Enterprise Java Beans, en el Entorno de Desarrollo Netbeans.
El prototipo ilustrado a continuacin se fundamente en demostrar la facilidad de uso de
los diversas tecnologas J2EE y ponerlas juntas para crear una aplicacin web
empresarial.
Aunque la aplicacin que se va a demostrar a continuacin no profundiza temas
complejos ni se va a desarrollar una aplicacin completa, su arquitectura representa las
mejores prcticas en el desarrollo de una aplicacin empresarial, por lo que la
modularidad, escalabilidad y reusabilidad se tienen en cuenta.
La figura III.6 muestra la arquitectura como se distribuye la aplicacin por capas:

- 62 -

Figura III.6: Distribucin por capas de la Aplicacin.

La arquitectura de la aplicacin se muestra en la figura III.6, en el que se organizan en


distintos niveles: Presentacin, lgica de negocios, acceso a datos y de datos, donde
cada uno tiene un papel importante que desempear y se separa el uno del otro.
Esta arquitectura favorece una clara separacin de responsabilidades, la reutilizacin y
escalabilidad mediante el uso de Enterprise Java Beans. Con el uso de JSF y JPA, el
desarrollo de interfaz grfica de usuario se convierte en una brisa y los desarrolladores
ya no estn empantanados por las tareas tediosas y propensas a errores de conversin de
datos relacionales orientada a objetos, lo cual es natural en Java y viceversa. As, todoen-todo, esta demostracin no slo muestra el uso de las diversas tecnologas J2EE,
tambin demuestra la arquitectura de la aplicacin mejor de su clase que puede ser
utilizada en un sistema de produccin.
3.3.1. REQUISITOS PARA CONSTRUIR LA APLICACIN.
Para construir una aplicacin web integrando las tecnologas de JSF y EJB, es necesario
tener conocimientos previos sobre:
JavaServer Faces (JSF) con Facelets18.
Enterprise Java Beans (EJB) 3/3.1
Java Persistence API (JPA)
18

Facelets: Framework ligero que permite el uso de plantillas en aplicaciones JSF.

- 63 -

Conocimientos bsicos de uso de NetBeans IDE.


Para construir esta aplicacin, es necesario tener el siguiente software instalado en el
equipo:
NetBeans IDE 6.5 o superior.
GlassFish Enterprise Server v3.
Biblioteca de Componentes PrimeFaces19.
Base de Datos de muestra instalada junto con NetBeans.

Figura III.7: Base de Datos de muestra en NetBeans.

3.3.2. CREANDO EL PROYECTO.


Crear un nuevo proyecto con el nombre de CustomerApp.
Seleccione en la barra de men la opcin Archivo => Proyecto Nuevo.En el
cuadro de dilogo, seleccione Java EE en la parte de Categoras, en virtud de
los proyectos, seleccione Enterprise Application. Haga clic en Siguiente.
19

PrimeFaces: Componente para JavaServer Faces que cuenta con un conjunto de componentes ricos que
facilitan la creacin de las aplicaciones web

- 64 -

Figura III.8: Creando el Proyecto => Seleccionar Proyecto.


Seleccione la ubicacin del proyecto y el nombre del proyecto, CustomerApp,
y haga clic en Siguiente.

Figura III.9: Creando el Proyecto => Nombre y Ubicacin del Proyecto.

- 65 -

Seleccione GlassFish v3 como el servidor, y Java EE 6 como la versin de Java


EE, y haga clic en Terminar.

Figura III.10: Creando el Proyecto => Servidor y Configuraciones.

NetBean crear 3 proyectos, a saber, CustomerApp (proyecto de aplicaciones


empresariales), CustomerApp-ejb (EJB del proyecto), y CustomerApp-war (Web del
proyecto).

- 66 -

Figura III.11: Creando el Proyecto => Proyectos creados por el IDE NetBeans.

3.3.3. CREANDO LAS CLASES ENTIDADES A PARTIR DE LA BASE DE


DATOS.
En el proyecto CustomerApp-ejb dar click derecho, seleccionar
Nuevo y seleccionar la opcin Otro..

- 67 -

Figura III.12: Creando las clases entidades => Seleccionar Otro.


En la Ventana, se selecciona en la pestaa de Persistencia seleccionar
en Clases Entidad a partir de bases de datos, y dar siguiente.

Figura III.13: Creando las clases entidades => Seleccionar Clase Entidad a
partir de Base de Datos.

- 68 -

En la siguiente ventana en la opcin Fuente de Datos, seleccionar


Jndi/sample

Figura III.14: Creando las clases entidades => Seleccionar Tablas de la Base de
Datos.
Seleccionar una tabla para agregar, se marca en Customer, y se not que se
agrega la tabla relacionada que es Discount_Code, dar en Siguiente

- 69 -

Figura III.15: Creando las clases entidades => Seleccionando Tablas.


En la siguiente venta poner en el nombre de paquete com.customerapp.entity,
dar siguiente.

Figura III.16: Creando las clases entidades => Clases Entidad.

En la ventana siguiente seleccionar en el tipo de coleccin "java.util.List", y


finalizar.

- 70 -

Figura III.17: Creando las clases entidades => Opciones de Mapeo.


Se

puede

notar

la

creacin

de

las

clases

Customer.java

DiscountCode.java

Figura III.18: Creando las clases entidades => Clases entidades creadas.

3.3.3.1.CREACIN DE LOS EJB (SESSION Y MESSAGE DRIVEN)


Ahora que se tienen las clases de entidad, la siguiente tarea es la creacin del Session
Bean (sin estado), CustomerSession para manipular y contar con las funciones RU en
los objetos del cliente. En esta demostracin, el cliente que utiliza estas funciones son
las pginas JSF. Uno de los beneficios de hacer esto (es decir, contar con las funciones
de la capa EJB) es la reutilizacin, porque las mismas funciones pueden ser utilizadas

- 71 -

por ms de mil pginas JSF, objetos EJB, otros clientes de aplicaciones empresariales y
clientes de servicios web cuando se exponen como servicios web. Otros beneficios
incluyen la capacidad de ampliacin debido a que el contenedor EJB puede ser
fcilmente afinado y ampliado cuando aumenta la carga.
Tambin se va a crear un Message-Driven Bean (MDB), NotificationBean aqu para
demostrar su uso para la mensajera asincrnica. En esta ilustracin, se quiere enviar las
notificaciones sobre la correcta actualizacin de un registro de cliente. Para simplificar,
slo se est enviando el objeto de cliente actualizado a la cola, de modo que el MDB
puede recoger y procesar en un subproceso independiente.
Para crear los MDB, se seguirn los siguientes pasos.
Seleccionar en CustomerApp-ejb click derecho, escoger Nuevo y
seleccionar Session Bean.

Figura III.19: Creacin de los MDB => Nuevo Session Bean.


En la ventana que aparece, poner los siguientes datos, Ejb Name
CustomerSession,

Package com.customerapp.ejb, en Session Type

Stateless, y terminar.

- 72 -

Figura III.20: Creacin de los MDB => Nombre y Localizacin.


Seleccionar en CustomerApp-ejb y dar clic derecho, escoger Nuevo y
seleccionar Message-Driven Bean.

Figura III.21: Creacin de los MDB => Nuevo Message Drive Bean.
En la ventana que aparece poner los siguientes datos, Ejb Name
NotificationBean,

Package com.customerapp.mdb, en Project

- 73 -

Destinations, seleccionar Add, en Destination Name NotificationQueue, y


Destination Type Queue y terminar

Figura III.22: Creacin de los MDB => Nombre y Localizacin de los MDB.
En el explorador de proyectos se observan los paquetes que se ha creado con sus
respectivas clases.

Figura III.23: Creacin de los MDB => Paquetes y sus respectivas clases.

- 74 -

Dirigirse a la Fuente de Session Beans, haciendo click sobre CustomerSession

Figura III.24: Creacin de los MDB => Sessions Beans creados.


En el editor de cdigo, hacer click derecho, seleccionar en Persistencia,
Utilizar el administrador de entidades

Figura III.25: Creacin de los MDB => Creando la Persistencia.


Se puede observar que se inserta cdigo.

- 75 -

Figura III.26: Creacin de los MDB => Cdigo insertado de Persistencia.


En el mismo editor de cdigo, dar click derecho, seleccionar en Insertar
Codigo y seleccionar en Add Bussines Method

Figura III.27: Creacin de los MDB => Men para agregar nuevos mtodos.
A continuacin proporcionar el nombre del mtodo retrive, en El tipo de
regreso digitar List <Customer>, tambin hacer lo mismo para el mtodo
update y Aceptar

- 76 -

Figura III.28: Creacin de los MDB => Creacin de Nuevos Mtodos.


Y aparece el siguiente cdigo.

Figura III.29: Creacin de los MDB => Cdigo de los nuevos mtodos.
Editar los mtodos, como se muestra a continuacin.

- 77 -

Figura III.30: Creacin de los MDB => Cdigo para mtodos update y retrive.

3.3.4. USANDO JSF Y PRIMEFACES.


Debido a que JSF es nuevo, no hay muchas opciones de framework basados en Ajax.
Sin embargo, PrimeFaces es el ms completo y adecuado para esta aplicacin, ya que
ha puesto en marcha el componente dataTable de interfaz de usuario, y parece ser el
ms fcil de integrar en el IDE NetBeans.
Antes de crear las pginas web, asegrese de que el framework JSF se agregue al
proyecto Web, CustomerApp-war.
En la ventana de Proyectos, haga clic en el proyecto Web, CustomerApp-war,
y seleccione Propiedades.
En el cuadro de dilogo de propiedades, seleccione Frameworks, y luego
presione en Add, para agregar el framework con el que se va a trabajar,
seleccione JavaServer Faces.

- 78 -

Figura III.31: Usando JSF y PrimeFaces => Seleccionando Framework


JavaServer Faces.

Antes de utilizar los componentes PrimeFaces en nuestras Facelets, es


necesario incluir la biblioteca en el IDE NetBeans y realizar un par de cosas.
o Descargar la biblioteca PrimeFaces (primefaces-2.0.0.RC.jar) de
http://www.primefaces.org/downloads.html y guardarlo en algn lugar
del disco local.
o Para permitir que los proyectos futuros usen PrimeFaces, cree una
biblioteca mundial en NetBeans para PrimeFaces.

Seleccione "Herramientas > Bibliotecas" en el men principal de


NetBeans.

En el cuadro de dilogo Administrador de Biblioteca, elegir la


opcin "Biblioteca Nueva" y proporcione un nombre para la
biblioteca, por ejemplo, "PrimeFaces3".

Figura III.32: Usando JSF y PrimeFaces => Agregando Biblioteca Global.

- 79 -

Con la nueva biblioteca "PrimeFaces2" creada, haga clic en el


botn "Add JAR / carpeta..." y seleccione el archivo .jar que se ha
descargado antes y haga clic en Aceptar para terminar.

Figura III.33: Usando JSF y PrimeFaces => Agregando archivo .jar a la


biblioteca.
o A continuacin, se tiene que aadir la biblioteca PrimeFaces3 al proyecto
Web.

Seleccione el proyecto Web, CustomerApp-war, desde la ventana


de proyecto, haga clic derecho y seleccione "Propiedades".

En la categora Bibliotecas, haga clic en "Add Library..." y


seleccione la biblioteca PrimeFaces3 y haga clic en Aceptar para
terminar.

- 80 -

Figura III.34: Usando JSF y PrimeFaces => Agregando la Biblioteca al proyecto.


o Debido a que se va a utilizar Facelets en nuestra aplicacin, se tiene que
actualizar la plantilla de XHTML en NetBeans para que todos los
archivos XHTML creados posteriormente dispongan de los espacios de
nombres y los recursos necesarios para el desarrollo.
o Seleccione "Herramientas> Plantillas" en el men de NetBeans.
o En el cuadro de dilogo Administrador de plantillas, seleccione "Web>
XHTML" y haga clic en la opcin "Abrir en el Editor de".

- 81 -

Figura III.35: Usando JSF y PrimeFaces => Administrador de Plantillas.


o Editar el contenido de este archivo con este cdigo:
<?xml version="1.0" encoding="${encoding}"?>
<#assign licenseFirst = "<!--"><#assign licensePrefix = ""><#assign
licenseLast = "-->"<# Asignar licenseLast = "->">
<#include "../Licenses/license-${project.license}.txt">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<Xmlns html = "http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core" xmlns: f =
"http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html"
xmlns: h = "http://java.sun.com/jsf/html"
xmlns:p="http://primefaces.prime.com.tr/ui" xmlns: p =
"http://primefaces.prime.com.tr/ui">
<h:head>
<meta http-equiv="Content-Type" content="text/html;
charset=${encoding}"/></span>
<title>TODO supply a title</title></span>
<p:resources />
</h:head>
<h:body>
<p>
TODO write content
</p>
</h:body>
</html>

- 82 -

o Por ltimo, se aade las siguientes declaraciones en el archivo web.xml


del proyecto Web para que PrimeFaces funcione correctamente:
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/* </url-pattern>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>Resource Servlet</servlet-name>
<servletclass>org.primefaces.resource.ResourceServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Resource Servlet</servlet-name>
<url-pattern>/primefaces_resource/*</url-pattern>
</servlet-mapping>
<context-param>
<param-name>com.sun.faces.allowTextChildren</paramname>
<param-value>true</param-value>
</context-param>
En este punto, se ha terminado la instalacin y configuracin del entorno para
PrimeFaces para trabajar en NetBeans. A continuacin se crear el listado de
clientes y puntos de vista Detalles.
3.3.4.1.CREANDO EL CLIENTE BEAN GESTIONADO.
Antes de crear las pginas JSF, primero se crea el bean gestionado que ser la
prestacin de los servicios necesarios para las pginas JSF que se crearn ms tarde.
En la ventana de Proyectos, haga clic en el proyecto Web, CustomerAppwar,

selecciona

"Nuevo>

JSF

Managed

Bean...",

especifique

CustomerMBean como nombre de clase ", com.customerapp.web" como el


nombre del paquete, el cliente como el nombre, y en Scope Session.

- 83 -

Figura III.36: Usando JSF y PrimeFaces => Crear Nuevo JSF Managed Bean.
En el editor de cdigo de la clase recin creada, CustomerMBean, haga clic
derecho y seleccionar "Insertar Cdigo...", y "Call Enterprise Bean...".
En el cuadro de dilogo "Call Enterprise Bean", expanda el proyecto
CustomerApp-ejb y seleccione el CustomerSessionBean y seleccione la
opcin de No interfaz (de todos modos las opciones locales y remotos deben
ser desactivados, porque se cre el bean de sesin sin interfaz) para la interfaz
de referencia, y haga clic en Aceptar.

- 84 -

Figura III.37: Usando JSF y PrimeFaces => Call Enterprise Bean.


Tenga

en

cuenta

la

variable

que

se

genera

automticamente,

customerSessionBean que representa una instancia del bean de sesin, a


principios de la declaracin de clase.
Aadir el resto de los mtodos (propiedades y controladores de accin) y su
implementacin en la clase como se muestra a continuacin, que sern utilizados por las
pginas JSF ms tarde:
package com.customerapp.entity;
import java.util.List;
import javax.ejb.Stateless;
import javax.ejb.LocalBean;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
/**
*
* @author user

- 85 -

*/
@Stateless
@LocalBean
public class CustomerSesion {
@PersistenceContext(unitName = "CustomerAPP-ejbPU")
private EntityManager em;
public void persist(Object object) {
em.persist(object);
}
public List<Customer> retrieve() {
return null;
}
public Customer update(Customer customer) {
return null;
}
// Add business logic below. (Right-click in editor and choose
// "Insert Code > Add Business Method")
}

3.3.4.2.CREACIN DE LA PGINA WEB CLIENTE.


Ahora, se debe crear la primera pgina web que muestra los registros de clientes en la
base de datos en forma de tabla.
En la ventana de Proyectos, haga clic en el proyecto Web, CustomerAppwar, y selecciona "Nuevo> XHTML ...", especifique CustomerList como
nombre de archivo.

- 86 -

Figura III.38: Usando JSF y PrimeFaces => Nuevo Archivo XHTML.

Nota: Si el elemento "XHTML..." no aparece en la lista del men, seleccione


"Nuevo> Otros..." en su lugar, luego en el dilogo Nuevo archivo, seleccione
Web en Categoras y aparecer el tipo de archivo XHTML a la derecha.
Por razones de conveniencia, se crear la tabla inicial de la gama de colores en
vez de codificar desde cero. En el editor de cdigo, arrastre, "JSF data table
from entity" desde la paleta y colquelo entre el <h:body> </ h: body>
etiquetas del archivo recin generado, CustomerList.xhtml.
Un cuadro de dilogo con el ttulo, "JSF Data Table from Entity" aparece,
seleccione "com.customerapp.entity.Customer" como el bean de entidad, y
"customer.customers" como la propiedad de un Bean administrado y haga clic
en Aceptar.

- 87 -

Figura III.39: Usando JSF y PrimeFaces => Tabla JSF desde la Entidad.

Nota: El resultado de esto son las lneas de los cdigos generados


automticamente para mostrar una lista predeterminada de los objetos Customer.
En este punto, se va a ver el resultado de la primera pgina web creada hasta
ahora. En la ventana de Proyectos, haga clic derecho en el proyecto
CustomerApp y seleccione limpiar y construir, y seleccione Implementar.
Para confirmar que el despliegue se realiza correctamente, vaya a la carpeta
Aplicaciones en el servidor Glassfish en la ventana de Servicios y compruebe
si la aplicacin, CustomerApp, existe.

Figura III.40: Usando JSF y PrimeFaces => Aplicaciones del IDE NetBeans.

- 88 -

Abra el navegador y vaya a la URL, http://localhost:8080/CustomerAppwar/CustomerList.jsf y usted debera ver la siguiente pantalla:

Figura III.41: Usando JSF y PrimeFaces => Pantalla Cruda de la Lista de


Clientes.
Nota: La pantalla es muy cruda y sin ningn tipo de embellecimiento porque
hasta ahora, sigue siendo una pgina JSF sencilla. As que se va a modificar la
pgina para mostrar slo las columnas de inters y utilizar PrimeFaces
dataTable.
Para utilizar PrimeFaces dataTable en la pgina CustomerList.xhtml, basta
con sustituir las etiquetas <h:dataTable> y <h:column> por <p:dataTable>
y <p:column>, respectivamente, y modificar el resto del cdigo.
El resultado de estos cambios deberan dar a la pgina este aspecto:

- 89 -

Figura III.42: Usando JSF y PrimeFaces => Pantalla de Lista de Clientes usando
JSF.
Ahora se procede a crear la pgina de detalles.
En el editor de cdigo, arrastre, "JSF data table from entity" desde la paleta y
colquelo entre el <h:body> </ h: body> etiquetas del archivo recin
generado, CustomerDetails.xhtml.
Aparece un cuadro de dilogo con el ttulo "JSF Table from Entity" ,
seleccione

"com.customerapp.entity.Customer"

como

la

Entidad,

"customer.showDetails()" como la propiedad de un Bean administrado y haga


clic en Aceptar:

Figura III.43: Usando JSF y PrimeFaces => JSF Table From Entity.

Nota: El resultado de esto son las lneas de cdigo generadas automticamente para
mostrar la etiqueta y el campo de entrada de todos los atributos del objeto de cliente en
una cuadrcula.

- 90 -

Para permitir la navegacin de la pgina cliente con la de detalles, y viceversa,


es necesario modificar el faces-config.xml con el editor de PageFlow y
conecte las 2 pginas, como se muestra en el siguiente diagrama:

Figura III.44: Usando JSF y PrimeFaces => Archivo faces-config.xml con


PageFlow.

Nota: La LISTA DE DETALLES debe coincidir con la cadena de retorno de los


mtodos List y ShowDetails en el CustomerMBean.

Para ver el resultado, guarde y despliegue la aplicacin, vaya a la pgina del


listado

de

clientes

en

la

URL,

http://localhost:8080/CustomerApp-

war/CustomerList.jsf, y haga clic en el ID de cliente en la primera fila de la


tabla:

- 91 -

Figura III.45: Usando JSF y PrimeFaces => Formulario de Ingreso de Clientes.

De este modo se ha enlazado el ID de cada registro a la tabla de detalles, creando as la


navegacin entre pginas.
De esta manera se ha podido integrar el framework EJB con JSF.

- 92 -

CAPTULO IV.

4. DESARROLLO DE METODOLOGA ERCA WEB


4.1.QU ES UNA METODOLOGA?
Una metodologa es un conjunto de etapas formalmente estructuradas, de manera que
brinden a los interesados parmetros de accin en el desarrollo de sus proyectos: plan
general y detallado, tareas y acciones, tiempos, aseguramiento de la calidad,
involucrados, etapas, revisiones de avance, responsables, recursos requeridos, entre
otros20.
La metodologa es el enlace entre el sujeto y el objeto de conocimiento. Sin ella es
prcticamente imposible lograr el camino que conduce al conduce al conocimiento
cientfico21.
La metodologa es necesaria para que un equipo de profesionales alcance un resultado
homogneo tal como si lo hiciera uno solo, por lo que resulta habitual el uso de
metodologas para el desarrollo de aplicaciones informticas.
4.2.METODOLOGAS DE DESARROLLO DE SOFTWARE.
Todo desarrollo de software es riesgoso y difcil de controlar, pero si no se lleva una
metodologa de por medio, lo que se obtiene son clientes insatisfechos con el resultado
y desarrolladores an ms insatisfechos. Sin embargo, muchas veces no se toma en
20
21

http://www.angelfire.metodologia.doc
https://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r33282.PDF

- 93 -

cuenta el utilizar una metodologa adecuada, sobre todo cuando se trata de proyectos
pequeos de dos o tres meses. Lo que se hace con este tipo de proyectos es separar
rpidamente el aplicativo en procesos, cada proceso en funciones, y por cada funcin
determinar un tiempo aproximado de desarrollo.
Cuando los proyectos que se van a desarrollar son de mayor envergadura, ah si toma
sentido el basarnos en una metodologa de desarrollo, y se busca cual sera la ms
apropiada para nuestro caso. Lo cierto es que muchas veces no se encuentra la ms
adecuada y se termina por hacer o disear nuestra propia metodologa, algo que por
supuesto no est mal, siempre y cuando cumpla con el objetivo.
Las Metodologas de Desarrollo de Software surgen ante la necesidad de utilizar una
serie de procedimientos, tcnicas, herramientas y soporte documental a la hora de
desarrollar un producto software. Dichas metodologas pretenden guiar a los
desarrolladores al crear un nuevo software, pero los requisitos de un software a otro son
tan variados y cambiantes, que ha dado lugar a que exista una gran variedad de
metodologas para la creacin del software. Se podran clasificar en dos grandes grupos:
1. Metodologas

Orientadas

al

Control

de

los

Procesos.

Establecen

rigurosamente las actividades a desarrollar, herramientas a utilizar y notaciones


que se usarn. Estas metodologas son llamadas Metodologas Tradicionales o
Pesadas.

2. Metodologas Orientadas a la Interaccin con el Cliente y el Desarrollo


Incremental del Software. Muestra versiones parcialmente del software al
cliente en intervalos cortos de tiempo, para que pueda evaluar y sugerir cambios
en el producto segn se va desarrollando. Estas son llamadas Metodologas
giles.
4.2.1. METODOLOGAS TRADICIONALES O PESADAS.
Son las ms tradicionales, se centran en la definicin detallada de los procesos y tareas a
realizar, herramientas a utilizar, y requiere una extensa documentacin, ya que pretende
prever todo de antemano. Este tipo de metodologas son mas eficaces y necesarias
cuanto mayor es el proyecto que se pretende realizar respecto a tiempo y recursos que

- 94 -

son necesarios emplear, donde una gran organizacin es requerida. Una de las
metodologas tradicionales ms conocidas y utilizadas es la Metodologa MSF
(Microsoft Solution Framework).
4.2.1.1.METODOLOGA MICROSOFT SOLUTION FRAMEWORK (MSF).
Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos
y prcticas de uso, que controlan la planificacin, el desarrollo y la gestin de proyectos
tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un
segundo plano las elecciones tecnolgicas.
MSF tiene las siguientes caractersticas:
Adaptable: es parecido a un comps, usado en cualquier parte como un mapa,
del cual su uso es limitado a un especfico lugar.
Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as
como tambin, proyectos que requieren 50 personas a ms.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones
basadas sobre cualquier tecnologa.
MSF se compone de varios modelos encargados de planificar las diferentes partes
implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,
Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de
Diseo de Proceso y finalmente el modelo de Aplicacin.
Modelo de Arquitectura del Proyecto: Diseado para acortar la planificacin
del ciclo de vida. Este modelo define las pautas para construir proyectos
empresariales a travs del lanzamiento de versiones.
Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento
del equipo de desarrollo. Proporciona una estructura flexible para organizar los
equipos de un proyecto. Puede ser escalado dependiendo del tamao del
proyecto y del equipo de personas disponibles.
Modelo de Proceso: Diseado para mejorar el control del proyecto,
minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega.
Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto,

- 95 -

describiendo las fases, las actividades, la liberacin de versiones y explicando su


relacin con el Modelo de equipo.
Modelo de Gestin del Riesgo: Diseado para ayudar al equipo a identificar las
prioridades, tomar las decisiones estratgicas correctas y controlar las
emergencias que puedan surgir. Este modelo proporciona un entorno
estructurado para la toma de decisiones y acciones valorando los riesgos que
puedan provocar.
Modelo de Diseo del Proceso: Diseado para distinguir entre los objetivos
empresariales y las necesidades del usuario. Proporciona un modelo centrado en
el usuario para obtener un diseo eficiente y flexible a travs de un enfoque
iterativo. Las fases de diseo conceptual, lgico y fsico proveen tres
perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los
desarrolladores.
Modelo de Aplicacin: Diseado para mejorar el desarrollo, el mantenimiento y
el soporte, proporciona un modelo de tres niveles para disear y desarrollar
aplicaciones software. Los servicios utilizados en este modelo son escalables, y
pueden ser usados en un solo ordenador o incluso en varios servidores.
La Metodologa MSF se adapta a proyectos de cualquier dimensin y de cualquier
tecnologa.
4.2.2. METODOLOGAS GILES.
Este tipo de metodologas nace en febrero del 2001 en una reunin celebrada en UtahEEUU.
Las principales ideas de la metodologa gil son:
Se encarga de valorar al individuo y las iteraciones del equipo ms que a las
herramientas o los procesos utilizados.
Se hace mucho ms importante crear un producto software que funcione que
escribir mucha documentacin.
El cliente est en todo momento colaborando en el proyecto.
Es ms importante la capacidad de respuesta ante un cambio realizado que el
seguimiento estricto de un plan.

- 96 -

Como una metodologa gil se tiene a la Programacin Extrema o XP (Extreme


Programming).
4.3.METODOLOGA PROPUESTA ERCA WEB.
Esta metodologa se centra nicamente en el desarrollo de aplicaciones web de tipo
empresarial utilizando tecnologas actuales para este tipo de software, tales como son
Java Server Faces (JSF) y Enterprise Java Bean (EJB).
Mediante la integracin de stas tecnologas se proporcionar un modelo para la
construccin de aplicaciones web que permitir a los interesados desarrollar
aplicaciones web empresariales sin mayor esfuerzo.
4.3.1. FASES DE LA METODOLOGA ERCA WEB.
La metodologa ERCA Web est organizada en seis fases las mismas que se describen
en el siguiente grfico junto con las principales actividades.

- 97 -

Planificacin.
Anlisis de Requerimientos.
Bosquejo de Base de Datos.
Aprendizaje de framework JSF.

Desarrollo de Base de Datos.


Diseo de Base de Datos.
Construccin de Prototipo en JSF.
Presentacin de Prototipo.
Diseo Final de Base de Datos.

Desarrollo de Mdulo EJB.


Aprendizaje de Framework EJB.
Creacin de mdulo EJB.
Generacin de Capa de Acceso a Datos y Lgica de Negocios Inicial.

Integracin de Frameworks.
Creacin de mdulo JSF.
Integracin de JSF y EJB.
Desarrollo Final de Capa de Lgica de Negocio.

Construccin Final de la Aplicacin.


Preparacin de Templates.
Desarrollo Final de Interfaces.
Presentacin Final.
Sugerencias y Mejoramiento.

Implementacin e Implantacin.
Instalacin de Servidores.
Alojamiento de Aplicacin Web.
Pruebas de funcionamiento.

Figura IV.46: Fases de la Metodologa ERCA Web.

El objetivo de cada una de las fases se describe a continuacin:


4.3.1.1.Fase 1: Planificacin.
Definir concretamente, con los interesados relevantes, un plan inicial para el desarrollo
de la aplicacin determinada, realizando el anlisis de los requerimientos del usuario.
4.3.1.2.Fase 2: Desarrollo de Base de Datos.
Analizar y disear la base de datos de acuerdo a los requerimientos establecidos
previamente por parte del cliente, con el fin de presentar a estos un prototipo inicial de
la aplicacin a desarrollar.

- 98 -

4.3.1.3.Fase 3: Desarrollo de Mdulo EJB.


En esta fase se va a utilizar el framework EJB con el fin de generar la capa de acceso a
datos y la lgica de Negocios.
4.3.1.4.Fase 4: Integracin de Frameworks.
Creacin de la capa de Presentacin mediante JSF, la integracin con el mdulo EJB y
el desarrollo complementario de la capa de lgica de negocio.
4.3.1.5.Fase 5: Construccin Final de la Aplicacin.
En esta fase se desarrollar la parte final de la aplicacin, haciendo uso de templates
para el correcto desarrollo de las interfaces. Luego de esto se deber presentar al cliente
el producto final, de modo que pueda dar nuevas sugerencias del software y adaptarlas
posteriormente.
4.3.1.6.Fase 6: Implementacin e Implantacin.
Esta etapa corresponde a la implementacin e implantacin de la aplicacin realizada,
en las mquinas de los usuarios, con el fin de verificar si se han cumplido a cabalidad
todos los requerimientos establecidos en un principio por parte de los usuarios.

4.3.2. FASE 1: PLANIFICACIN.


4.3.2.1.ANLISIS DE REQUERIMIENTOS.
Esta etapa es la primera actividad que se debe realizar en el desarrollo de un Sistema de
Informacin. Comienza despus de que un usuario ha detectado una ausencia, falla o
falta de oportunidad de la informacin o simplemente, luego que la organizacin ha
determinado un cambio en sus polticas, reglas o tecnologas a aplicar.
En esta etapa, se debe responder a una pregunta fundamental: Qu es lo que quiere el
cliente? y para ello, se debe diagnosticar la situacin actual, recopilar los requerimientos
del cliente, tanto en relacin al sistema, como generales respecto del rea informtica, es
decir la situacin ideal, para as poder definir alternativas de solucin, segn las cuales
se podr avanzar desde lo que hoy se posee, hacia el punto que se pretende llegar.

- 99 -

Como parte del trabajo, se debe sealar cul de las alternativas, es a nuestro juicio la
ms conveniente (y justificarlo) en la propuesta.
En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se le
va a presentar la solucin que se est buscando.
Los requerimientos son parte fundamental en un sistema de informacin ya que estos
representan el conjunto completo de resultados a ser obtenidos una vez que se utilice el
sistema. Los requerimientos de sistemas deben mostrar todo lo que el sistema debe
hacer ms todas las restricciones sobre la funcionalidad. Los requerimientos forman un
modelo completo, representando el sistema total a algn nivel de abstraccin.
De este modo se puede decir que un requerimiento es una condicin o capacidad a la
que el sistema (siendo construido) debe conformar. Un requerimiento de software puede
ser definido como:
Una capacidad del software necesaria por el usuario para resolver un problema o
alcanzar un objetivo.
Una capacidad del software que debe ser reunida o poseda por un sistema o
componente del sistema para satisfacer un contrato, especificacin, estndar, u
otra documentacin formal.
Los requerimientos de usuario representan el conjunto completo de resultados a ser
obtenidos utilizando el sistema22. Estos se dividen as mismos en: Funcionales y no
Funcionales.
Requerimientos no Funcionales.
Son aquellos requerimientos que no se refieren directamente a las funciones especficas
que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la
respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen
las restricciones del sistema, como la capacidad de los dispositivos de entrada/salida y
la representacin de datos que se utiliza en las interfaces del sistema. Sin embargo, estos
requerimientos no siempre se refieren al sistema de software a desarrollar.
22

Requerimientos
http://www.galeon.com/zuloaga/Doc/AnalisisRequer.pdf

- 100 -

Para poder especificar los requerimientos no funcionales, es necesario establecer


algunas mtricas:
Tabla IV.I: Mtricas de Requerimientos no Funcionales.
PROPIEDAD
Rapidez.

MEDIDA
Transacciones procesadas por segundo.
Tiempo de respuesta al usuario y a eventos.
Tiempo de actualizacin de la pantalla.

Tamao.

Kilobytes.
Tamao de RAM.

Facilidad de uso.

Tiempo de capacitacin.
Nmero de ventanas de ayuda.

Fiabilidad.

Tiempo promedio entre fallas.


Probabilidad de no disponibilidad.
Tasa de ocurrencia de las fallas.
Disponibilidad.

Robustez.

Tiempo de reinicio despus de fallas.


Porcentaje de eventos que provocan las fallas.
Probabilidad de corrupcin de los datos despus de
las fallas.

Portabilidad.10

Porcentaje de declaraciones dependientes del


objetivo.
Nmero de sistemas objetivo.

Requerimientos Funcionales.
Describen la interaccin entre el sistema y su ambiente independientemente de su
implementacin. El ambiente incluye al usuario y cualquier otro sistema externo que
interacta con el sistema.
Un requisito funcional define el comportamiento interno del software: clculos, detalles
tcnicos, manipulacin de datos y otras funcionalidades especficas que muestran cmo

- 101 -

los casos de uso sern llevados a la prctica. Son complementados por los requisitos no
funcionales, que se enfocan en cambio en el diseo o la implementacin.
4.3.2.2.BOSQUEJO DE BASE DE DATOS.
En esta actividad se toma los requerimientos y especificaciones de la etapa de anlisis y
se determina la mejor manera de satisfacerlos, segn las apreciaciones del Usuario y del
que lo desarrolla, a travs de un diseo inicial de base de datos.
La finalidad de este bosquejo es establecer, a partir del trabajo con los usuarios, las
lneas bsicas del proyecto, principalmente en lo que respecta a funcionalidad y
estructura de la base de datos.
Este bosquejo deber exponer claramente las entidades involucradas, los atributos, las
relaciones y los procedimientos almacenados.
Una vez realizado el bosquejo, el coordinador podr determinar si la idea ha sido
correcta, o si se ha presentado algn desvo con respecto a las metas fijadas, pudiendo
en este momento corregir y repensar sin ninguna dificultad el modelo a desarrollar.
4.3.2.3.APRENDIZAJE DE FRAMEWORK JSF.
Esta actividad se realiza con el fin de que los interesados se familiaricen con el
framework JSF desde la planificacin del proyecto. Los desarrolladores tienen que
realizar un estudio minucioso sobre las ventajas y desventajas del framework JSF, sobre
los componentes y las caractersticas principales de este framework.
4.3.3. FASE 2: DESARROLLO DE BASE DE DATOS.
Una vez realizada la fase de planificacin que es la parte previa al desarrollo, se
proceder a desarrollar la base de datos, que es la parte modular y fundamental de esta
metodologa.
En esta fase se debe dedicar un gran tiempo a la base de datos, ya que desde aqu se
asegurar que el proyecto sea realizado sin ningn contratiempo e inconveniente.
Las actividades que corresponden a esta fase son las siguientes:

- 102 -

4.3.3.1.DISEO DE BASE DE DATOS.


Toda gestin empresarial requiere, hoy en da, manejar grandes cantidades de datos.
Cualquier empresa que se precie debe tener almacenados todos estos datos en una base
de datos para poder realizarlos mediante una aplicacin profesional. Sin esta
funcionalidad resultara imposible tratar y manejar en su totalidad los datos que lleva a
cabo la empresa y se perdera un tiempo y un dinero muy valiosos.
Uno de los pasos cruciales en la construccin de una aplicacin que maneje una base de
datos, es sin duda, el diseo de la base de datos. Si las tablas no son definidas
apropiadamente, se tendr muchos problemas al momento de ejecutar consultas a la
base de datos para tratar de obtener algn tipo de informacin.
Por lo cual es muy importante asegurarse que la base de datos est correctamente
diseada para que tenga eficiencia y que se pueda seguir utilizando por largo tiempo.
Dependiendo de los requerimientos de la aplicacin, el diseo de la base de datos puede
ser algo complejo, pero con algunas reglas simples que se tengan ser mucho ms fcil
crear una base de datos perfecta para un determinado proyecto.
4.3.3.2.CONSTRUCCIN DE PROTOTIPO EN JSF.
Una vez diseada la base de datos, se desarrolla un prototipo utilizando el framework
JSF, el cual se estudi previamente en la fase de planificacin. El objetivo de esta
actividad es poder tener una visin clara de lo que se pretende hacer, adems de
presentar al cliente los primeros avances del proyecto, logrando as una interaccin con
el o ellos.
Cabe indicar que un prototipo no es el diseo final de la aplicacin, ms bien es una
muestra de cmo puede quedar la aplicacin. Este prototipo est sujeto a cambios y
utiliza la base de datos previamente diseada, la cual tambin puede ser cambiada o
modificada si el cliente as lo desea.
4.3.3.3.PRESENTACIN DE PROTOTIPO.
En esta actividad, como su nombre lo indica, se deber presentar el prototipo construido
anteriormente al cliente. Al presentar el prototipo, el cliente podr establecer nuevos
cambios, nuevos requerimientos, etc., de modo que se establezca una idea ms clara de

- 103 -

lo que se quiere. Con esto se logra involucrar ms al cliente hacindolo parte


fundamental del desarrollo de la aplicacin. De esta manera se garantiza que se cumpla
efectivamente con todo lo que realmente quiere el cliente.
4.3.3.4.DISEO FINAL DE BASE DE DATOS.
En esta actividad se realiza un remodelamiento de la base de datos, de acuerdo con los
cambios o sugerencias que haya establecido el cliente. Como se dijo anteriormente, la
base de datos es una parte medular en el desarrollo de una aplicacin, utilizando la
metodologa ERCA Web.
En este remodelamiento se debe disear correctamente la base de datos, construir
procedimientos almacenados, funciones, triggers, si fuere necesario.
Una vez remodelada la base de datos, no se deber modificar en las actividades
posteriores, a no ser la inclusin de un nuevo procedimiento o funcin, sin alterar el
diseo lgico de la base de datos, sus relaciones, etc.

4.3.4. FASE 3: DESARROLLO DE MDULO EJB.


4.3.4.1.APRENDIZAJE DE FRAMEWORK EJB.
En esta actividad se debe realizar un estudio completo del framework EJB, de modo que
se puede aprovechar la mayora de sus funcionalidades y ventajas. El framework EJB es
el componente que permite generar la capa de acceso a datos de la aplicacin y parte de
la lgica de negocio, por lo cual es muy importante que se conozcan sus componentes y
su correcto funcionamiento.
4.3.4.2.CREACIN DEL MDULO EJB.
El framework EJB, a su vez, est compuesto por tres componentes bsicos que son: los
EJB Entity, los EJB Sessions y los Message Drive Bean. Cada uno de estos
componentes forma lo que es el acceso a datos de nuestra aplicacin.
En esta actividad se proceder a crear el mdulo EJB, a travs del IDE NetBeans.
Primeramente crear un Nuevo Proyecto de tipo empresarial, as como se muestra en la
figura:

- 104 -

Figura IV.47: Creacin Mdulo EJB Creando Nuevo Proyecto

Al seleccionar una aplicacin empresarial, el IDE automticamente crear el mdulo


EJB como otro proyecto.
4.3.4.3.GENERACIN DE LA CAPA DE ACCESO A DATOS Y LGICA DE
NEGOCIO INICIAL.
Una vez creado el mdulo EJB, se debe generar la capa de acceso a datos y parte de la
lgica de negocio.
Por lo cual, en el mdulo creado previamente, se deber establecer los EJB Entity, los
cuales hacen incapie al acceso a datos, y los EJB Sessions que se refieren a la lgica de
negocio.
Para establecer los EJB Entity, se debe dar clic derecho en el mdulo EJB generado y
seleccionar en Nuevo -> Clase entidad a partir de Base de Datos. De este modo aparece
un cuadro dilogo donde se debe ubicar la conexin a utilizar.

- 105 -

Figura IV.48: Acceso a Datos => Crear Clases Entidad a partir de base de datos.

Luego se debe seleccionar las tablas de las cuales se van a generar las clases entidad del
mdulo EJB. De este modo se genera los EJB Entity que son nada ms que una
copia/reflejo de la informacin de establecida en la base de datos.
Luego, para generar los EJB de Sesin, de igual forma dar clic derecho en el mdulo
EJB y seleccionar Nuevo->Session Bean for Entity Classes. Se generarn las clases
donde se establecer la lgica de negocio. La creacin de los EJB de Session permite la
reutilizacin de estos mismos mtodos en otras pginas.

- 106 -

Figura IV.49: Lgica de Negocio => Session Beans para Clases Entidad.

Agregar todas la entidades deseadas para que se generen los beans de sesin, as se
obtendrn nuevas clases segn la entidad en donde se establecer la programacin
modular para la aplicacin, as como el CRUD de cada entidad.
4.3.5. FASE 4: INTEGRACIN DE FRAMEWORKS.
4.3.5.1.CREACIN DE MDULO JSF.
En esta actividad se crear el mdulo JSF, el cual se lo integrar al mdulo EJB. JSF se
centra en el desarrollo de las interfaces de usuario, simplificando su construccin.
Como anteriormente se cre una aplicacin empresarial, esta a su vez genera dos
mdulos; el primero es el mdulo EJB y el segundo es un mdulo tipo web. En este
segundo mdulo, se debe seleccionar el framework JSF para activar las caractersticas
principales del mismo. Una vez seleccionado el framework se activarn todas las
etiquetas correspondientes a ste y se est listo para implementarlo en nuestra
aplicacin.

- 107 -

Figura IV.50: Seleccionando Framework JSF.

4.3.5.2.INTEGRACIN DE JSF Y EJB.


Una vez creado los mdulos EJB y JSF, es necesario realizar la integracin de estos,
con el fin de crear una aplicacin robusta de tipo empresarial.
El framework EJB funciona como un mdulo separado el cual puede ser integrado a
otros mdulos de una manera muy sencilla, simplemente haciendo referencia al EJB
desde cualquier otro mdulo.
La arquitectura de esta integracin representa las mejores prcticas en el desarrollo de
una aplicacin empresarial, por lo que la modularidad, escalabilidad y reusabilidad se
tienen en cuenta, y adems se organiza en distintos niveles: Presentacin, lgica de
negocios, acceso a datos y de datos, donde cada uno tiene un papel importante que
desempear y se separa el uno del otro.
Si un desarrollador quiere realizar una aplicacin JSF + EJB, la forma correcta es crear
el modelo EJB, y realizar las llamadas a ste modelo desde los JSF Managed Java
Beans de la aplicacin.

- 108 -

Para integrar ambos mdulos, simplemente desde el mdulo JSF se hace referencia, en
las libreras, al mdulo EJB, as como se muestra en la figura:

Figura IV.51: Integracin de EJB a JSF.

4.3.5.3.DESARROLLO FINAL DE CAPA DE LGICA DE NEGOCIO.


Anteriormente se dijo que el mdulo EJB solo genera una parte de la lgica de negocio,
pues bien, en esta actividad se realizar totalmente la lgica de negocio, conforme a los
requerimientos establecidos por el cliente.
4.3.6. FASE 5: CONSTRUCCIN FINAL DE LA APLICACIN.
Siguiendo correctamente las actividades anteriores, la parte lgica de la aplicacin ya
estara totalmente desarrollada, sin embargo, esto para el cliente no representa nada, ya
que lo que el cliente desea es poder interactuar con el software desarrollado a travs de
las interfaces de usuarios. Por lo cual en esta fase, se dedicar totalmente al diseo de
las interfaces, de modo que la aplicacin sea presentada al cliente.
En esta fase se desarrollarn las siguientes actividades:
4.3.6.1.PREPARACIN DE TEMPLATES.
Los templates son plantillas de interfaces de usuario que una vez implementados en una
aplicacin generan interfaces de usuario amigables.

- 109 -

El uso de templates trae consigo las ventajas de tener un cdigo ordenado (sobre todo en
aplicaciones grandes), fcil de desarrollar y reusar.
Por lo general JSF hace uso de estas plantillas para un mejor diseo de interfaces. En
JSF existen un sin nmero de templates, de los cuales se deber seleccionar el que ms
conveniente. Entre los templates que usa JSF se tienen:
MyFaces.
ICEFaces.
RichFaces.
RC Faces.
PrimeFaces.
Los templates son archivos .jar que son referenciados desde las libreras del mdulo
JSF.
En esta actividad se deber seleccionar y preparar los templates necesarios para el
desarrollo de la aplicacin.
4.3.6.2.DESARROLLO FINAL DE INTERFACES.
Una vez preparado los templates, se debern referenciar desde las libreras. En esta
actividad, se realiza el diseo final de las interfaces, creando las pginas de interaccin
con el usuario, los comandos, colores, etc.
4.3.6.3.PRESENTACIN FINAL.
Al desarrollar las interfaces, se puede decir que la aplicacin est prcticamente
terminada, por lo cual, en esta actividad se realiza una presentacin final al cliente, el
cual dar nuevas sugerencias, si las hubiera, sobre cmo deberan estar organizadas las
interfaces, los colores, etc.
4.3.6.4.SUGERENCIAS Y MEJORAMIENTO.
De acuerdo a la presentacin final al cliente, este dar nuevas sugerencias sobre la
aplicacin. Estas sugerencias no debern afectar en nada a la lgica de negocio de la
aplicacin, es decir, el cliente no podr sugerir la adicin de un nuevo requerimiento o
el cambio de alguno, mas bien estas sugerencias se centran en las interfaces.

- 110 -

Una vez dada las sugerencias se proceder al mejoramiento y acoplo de estas


sugerencias en la aplicacin.
4.3.7. FASE 6: IMPLEMENTACIN E IMPLANTACIN.
Como su nombre lo indica, esta etapa corresponde a la implementacin de la aplicacin
realizada, en las mquinas de los usuarios, con el fin de verificar si se han cumplido a
cabalidad todos los requerimientos establecidos en un principio por parte de los
usuarios.
Las actividades correspondientes a esta fase son las siguientes:
4.3.7.1.INSTALACIN DE SERVIDORES.
En esta actividad se debern instalar los servidores necesarios para que la aplicacin
web funcione correctamente. Los servidores ms importantes son: El servidor de Base
de Datos y el servidor de Aplicaciones Web.
Un servidor de base de datos es, como su nombre lo indica, un programa que provee
servicios de base de datos a otros programas u otras computadoras, como es definido
por el modelo cliente/servidor. Tambin puede hacer referencia a aquellas
computadoras (servidores) dedicadas a ejecutar esos programas, prestando el servicio.
Entre los servidores ms comunes se tiene el Servidor MySQL. Este servidor es muy
rpido, seguro, y fcil de usar. Si eso es lo que se est buscando, se le debe dar una
oportunidad a MySQL.
Una de las herramientas ms sencillas para instalar el servidor MySQL es el
denominado XAMPP que es un servidor independiente de plataforma que consiste
principalmente en la Base de Datos MySQL, el servidor Apache, PHP y Perl.

Figura IV.52: Logo XAMPP

Comnmente, para crear una base de datos en MySQL es necesario establecer un


conjunto de comandos SQL. Debido a que no se conocen todos los comandos

- 111 -

necesarios, es muy difcil crear una base de datos con MySQL, sin embargo, existen
alternativas que permiten configurar una base de datos en MySQL utilizando una
interfaz grfica. Estas alternativas se denominan: MySQL Workbench, MySQL SQLFront, y otras ms.

Figura IV.53: Servidor de Base de Datos MySQL.

Un servidor web es un programa que se ejecuta continuamente en un computador,


mantenindose a la espera de peticiones de ejecucin que le har un cliente o un usuario
de Internet. El servidor web se encarga de contestar a estas peticiones de forma
adecuada, entregando como resultado una pgina web o informacin de todo tipo de
acuerdo a los comandos solicitados.
Un servidor utilizado comnmente es el denominado GlassFish que es un servidor libre
para aplicaciones Java EE de cdigo abierto. Usualmente GlassFish es uno de los
primeros Servidores de aplicaciones en soportar las ltimas novedades de Java EE.

- 112 -

4.3.7.2.ALOJAMIENTO DE LA APLICACIN EN EL SERVIDOR.


En esta actividad se deber alojar la aplicacin en el servidor web instalado, en nuestro
caso GlassFish.
Para publicar una aplicacin en servidor Glassfish se siguen los siguientes pasos:
Primero se debe dirigir a Inicio todos los programas y en la carpeta de Glassfish le
dar clic en Iniciar Servidor de Aplicaciones.

Figura IV.54: Ubicacin del Servidor GlassFish en el Men Inicio.


Una vez iniciado el servidor dirigirse al explorador y teclear http:localhost:4848, y
aparece la consola de configuracin.

- 113 -

Figura IV.55: Consola GlassFish.


Dar clic en Applications y en Deploy, para subir nuestra aplicacin web.

Figura IV.56: Configuracin para subir Aplicaciones.

- 114 -

Y escoger la aplicacin que debe estar en el formato .war


Y la aplicacin aparecer en la lista.

Figura IV.57: Lista de Aplicaciones subidas al servidor.

Dar clic en Launch y aparece la aplicacin

Figura IV.58: Pantalla Inicial de Sofware de Gestin SGM Pro

El funcionamiento de la aplicacin a travs de una red, estara representado en la


siguiente figura:

- 115 -

Figura IV.59: Funcionamiento de Aplicacin.

4.3.7.3.PRUEBAS Y FUNCIONAMIENTO.
Esta actividad, da inicio luego de que las diferentes unidades de diseo han sido
desarrolladas y probadas por separado. Durante su desarrollo, el sistema se emplea de
forma experimental para asegurar que el software no falle, es decir, que funcione de
acuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga, y de
esta forma poder detectar cualquier anomala, antes de que el sistema sea puesto en
marcha y se dependa de l. Para evaluar el desenvolvimiento del sistema, en esta fase se
llevan a cabo varios niveles de prueba:
Funcional: Prueba desde el punto de vista de los requerimientos funcionales.
De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y
de desempeo.
De Integracin: Prueba de interfaces.
De Aceptacin Tcnica: Prueba de manejo de condiciones extremas.
Si el Sistema cumple de forma satisfactoria con estos niveles mencionados
anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas del

- 116 -

nuevo sistema, para de esta forma dar inicio al proceso de aceptacin final, durante el
cual, el sistema comenzar a funcionar bajo la responsabilidad del departamento de
operaciones y del usuario, por un lapso determinado de tiempo llamado Periodo de
Aceptacin.
Finalizado el Periodo de Aceptacin, se le dar al sistema la aprobacin final, para que
pase a ser el sistema oficial.

- 117 -

CAPTULO V.

5. APLICACIN DE METODOLOGA ERCA WEB PARA EL


DESARROLLO DEL SOFTWARE DE GESTIN INDUSTRIAL.

Para el desarrollo del software de gestin de mantenimiento industrial para el Hospital


Docente General Riobamba SGM Pro, se aplic la metodologa propuesta denominada
ERCA Web, la cual consta de las siguientes fases y actividades.
5.1.PLANIFICACIN.
5.1.1. ANLISIS DE REQUERIMIENTOS.
En esta actividad se desarroll la Especificacin de Requerimientos de Software (SRS)
para determinar los requerimientos de usuario que debe cumplir el software creado.
La Especificacin de Requerimientos de Software SRS es una de las piezas ms
importantes en un proyecto de Desarrollo de Software, es necesario entonces establecer
las condiciones o necesidades del usuario para resolver un problema o alcanzar un
objetivo, de esta manera satisfacer un contrato a travs de un documento formal.
Los requerimientos que se establecen en el presente entregable son funcionales los
cuales definen las funciones que el sistema ser capaz de realizar adems describen las
transformaciones que el sistema realiza sobre las entradas para producir salidas y los no

- 118 -

funcionales que tiene que ver con caractersticas que de una u otra forma pueden limitar
el sistema.
Las caractersticas de un requerimiento son sus propiedades principales que debe
presentar tanto individualmente como en grupo. stas deben satisfacer una necesidad,
ser completo, verificable y no ser ambiguas.
5.1.1.1.OBJETIVOS DEL SRS.
Los objetivos del SRS son los siguientes:
Determinar los requerimientos funcionales y no funcionales para el
sistema SGM PRO.
Describir de la forma ms clara posible cada uno de los requerimientos
del usuario, actividades, mtodos, procesos, etc.
Realizar algoritmos de seguimiento para el buen uso y manejo del
sistema por parte de los usuarios, propuestas de interfaces, etc.
Presentar un prototipo de las interfaces de usuario que contendr el
Sistema.

5.1.1.1.1. mbito.
El Sistema SGM PRO servir de ayuda para las pequeas y medianas empresas que
realicen actividades de mantenimiento, ya que le permitir llevar un mejor control de las
actividades que se hacen por parte de sus tcnicos ya que el plan de mantenimiento se
llevaba de forma manual, Por tal razn este sistema aporta a la efectividad y rapidez de
estos controles para un mejor control de las actividades.
5.1.1.1.2. Referencias.
La siguiente documentacin de especificacin de requerimiento se lo realiz:
Software Requirements Specifications basado en el estndar 830 IEEE.
Documentos de estatutos, acuerdos, de contratacin de personal.

- 119 -

5.1.1.1.3. Visin general.


El documento de SRS describe los requerimientos del software a construir. Se incluyen
los requerimientos funcionales y no funcionales, as como tambin las el posible diseo
de las interfaces de SW. Su especificacin existe en otros documentos, a los que se hace
referencia.
5.1.1.2.DESCRIPCIN GENERAL
El proyecto constar de una aplicacin desarrollada en el lenguaje de programacin
JAVA, utilizando los frameworks JSF y EJB, con el motor de Base de Datos
denominado MySQL. Se utilizar el IDE NetBeans para el desarrollo de la propuesta,
adems del servidor web Glassfish.
5.1.1.2.1. Perspectiva del producto.
SGM PRO permitir llevar un mejor control de las actividades que se realizan por parte
de los tcnicos, adems de determinar un reporte de fallas permitiendo llevar una
planificacin anual de las actividades de acuerdo al nmero de semana.
5.1.1.2.2. Funciones del producto.

SGM PRO

MODULO
PLANIFICACIN

MODULO
REPORTE
FALLAS

MODULO DE
GESTION

Figura V.60: Funciones de SGM Pro

Mdulo de Planificacin: En ste mdulo se realizar la organizacin de las


actividades que debe realizar cada tcnico en la empresa de acuerdo al nmero

- 120 -

de semanas, definiendo as las actividades que se deben desarrollar en la semana


correspondiente y el tcnico que las debe desarrollar.
Mdulo Reporte Fallas: Este mdulo permite a los tcnicos de la empresa
reportar fallas en el desarrollo de las actividades, ya sean fallas en los equipos de
mantenimiento o problemas al desarrollar alguna actividad. Se podr establecer
el tiempo de para de los equipos determinando as costos por la falla de los
equipos.
Mdulo de Gestin. En este mdulo se realizarn todas las operaciones con
respecto a la insercin, modificacin y eliminacin de cada una de las entidades
que se manejan en el sistema.
5.1.1.2.2. Caractersticas del usuario.
Tabla V.II: Caractersticas de los Usuarios.
FUNCIN

NIVEL

EXPERIENCIA

CONOCIMIENTOS
TCNICOS

Programador

Superior

1 ao

Ing. en Sistemas

Programador

en

Sistemas

Estudiantes

Analista en Sistemas

Conocimiento en

Bachiller

programacin bsica.

Conocimientos en
aplicaciones web bsico

Conocimiento en computacin
bsica.

Gerente

Superior

Conocimiento en programacin
bsica

5.1.1.2.3. Limitaciones generales.


El sistema no podr funcionar al mximo de su capacidad en equipos que tengan
menos de 256 MB de memoria RAM.

- 121 -

El sistema no funciona en mquinas que no tengan acceso a internet.


La aplicacin va a ser desarrollada utilizando el Motor de Base de Datos de
MySQL, utilizando el lenguaje de programacin de Java, utilizando el servidor web
denominado GlassFish.
Para el correcto funcionamiento del sistema se debe implantar en una arquitectura
cliente-servidor en su totalidad.
Necesita algn tipo de sistema operativo (Windows XP, Vista, Seven, etc;).

5.1.1.2.4. Supuestos y dependencias.


Si la solucin de la aplicacin en JAVA requiere de alguna aplicacin en
VisualStudio se lo har pero producir retrasos en el desarrollo y avance.
Los cambios en los requerimientos en algn instante de la construccin del software
producirn retraso en el desarrollo e incluso puede causar una reprogramacin total
del producto de software.
El cambio de algn miembro del equipo de trabajo de desarrollo podran afectar en
gran manera el desarrollo del producto.
Si el DBMS sufre algn desperfecto este debera ser cambiado por otro de idnticas
caractersticas.

5.1.1.3.REQUERIMIENTOS ESPECIFICOS
5.1.1.3.1. Requerimientos Funcionales.

- 122 -

Req. 1. Como gerente quiero gestionar los datos a travs de una base de datos de modo
que exista un control organizado de la informacin.

Req. 2. Como gerente quiero que la informacin sea visualizada a travs de la web para
que nuestros clientes puedan acceder a nuestros servicios desde cualquier parte.

Req. 3. Como un gerente quiero que se establezca la insercin, modificacin y


eliminacin de estrategias, tcnicos y equipos para llevar un control eficaz de las
actividades que se realiza.

Req. 4. Como gerente quiero llevar el proceso automtico de asignacin de actividades


a los tcnicos.
Req. 5. Como gerente quiero que se muestre un plan de mantenimiento de todas las
actividades que se desarrollarn durante el ao de acuerdo al nmero de semana
correspondiente.
Req. 6. Como gerente quiero que se permita a los tcnicos notificar las actividades que
vaya realizando de acuerdo a la semana que toque.
Req. 7. Como gerente quiero que se permite reportar las fallas de algn equipo adems
de poder determinar el tiempo que estuvo parado ese equipo hasta su arreglo.

Req. 8. Como gerente quiero llevar el proceso automtico de asignacin de actividades


a los equipos.

Req. 9. Como gerente quiero que se permita establecer bsquedas de estrategias,


tcnicos, equipos o fallas.

Req. 10. Como gerente quiero que se presente por cada tcnico, las actividades que ste
debe desarrollar.

Req. 11. Como gerente quiero que se presente por cada equipo, las actividades que se
deben desarrollar en l.

- 123 -

1. Requerimiento 1.
Como gerente quiero gestionar los datos a travs de una base de datos de modo que
exista un control organizado de la informacin.
1.1.Introduccin.
La informacin que se maneje en la empresa ser organizada e ingresada en una
base de datos con el fin llevar un control eficiente de los datos.
1.2.Entradas.
Tabla V.III: Entradas Requerimiento 1.
Fuente:

Base de Datos SGM PRO.

Cantidad:

Relacionado

con

las

necesidades de la empresa.
Depende de los requerimientos

Frecuencia:

del usuario.
Rango de entradas vlidas:

Disponible todo el tiempo

1.3.Procesos.
Tabla V.IV: Procesos Requerimiento 1.
1.- El usuario utiliza la aplicacin.
2.- Realiza los requerimientos de gestin de acuerdo a
la necesidad.

1.4.Salidas.
Tabla V.V: Salidas Requerimiento 1.
Destino:

Pantalla

Cantidad:

Nmero de registros solicitados.

Frecuencia:

Relacionado con las necesidades


del usuario.

- 124 -

Mensajes

de

error:

1.5.Interfaces de Usuario.

Figura V.61: Lista de Estrategias.


2. Requerimiento 2.
Como gerente quiero que la informacin sea visualizada a travs de la web para que
nuestros clientes puedan acceder a nuestros servicios desde cualquier parte.
2.1.Introduccin.
Para una mejor visualizacin de la informacin de desea disear un sistema
informativo, en el cual cualquier cliente podr ver nuestra informacin pero solo
podr reservar un vuelo si se registra.
2.2.Entradas.
Tabla V.VI: Entradas Requerimiento 2.
Fuente:

Aplicacin web.

Cantidad:

Relacionado con las necesidades


del administrador.

Frecuencia:

Depende de los requerimientos


del usuario administrador.

Rango de entradas vlidas:

Disponible todo el tiempo

- 125 -

2.3.Procesos.
Tabla V.VII: Procesos Requerimiento 2.
1. El usuario utiliza la aplicacin.
2. Digita www.sgmpro.com.
3. Se presenta la pgina web.
4. El usuario podr obtener todo tipo de informacin que la
pgina dispone.

2.4.Salidas.
Tabla V.VIII: Salidas Requerimiento 2.
Destino:

Pantalla

Cantidad:

Nmero de registros solicitados.

Frecuencia:

Relacionado con las necesidades


del usuario.

Mensajes

de

error:

2.5.Interfaces de Usuario.

Figura V.62: Aplicacin SGM Pro.

- 126 -

3. Requerimiento 3.
Como un gerente quiero que se establezca la insercin, modificacin y eliminacin
de estrategias, tcnicos y equipos para llevar un control eficaz de las actividades que
se realiza.
3.1.Introduccin.
Este requerimiento tiene como finalidad permitir los mtodos de insercin,
modificacin y eliminacin de cada una de las entidades que en el sistema se
manejan.
3.2.Entradas.
Tabla V.IX: Entradas Requerimiento 3.
Fuente:

Base de Datos SGM PRO

Cantidad:

Uno por usuario.

Frecuencia:

Demanda alta.

Rango de entradas vlidas:

Disponible todo el tiempo

3.3.Procesos.
Tabla V.X: Procesos Requerimiento 3.
1.- Seleccionar la entidad a gestionar.
2.- Seleccionar lo que desea realizar en esta entidad, ya sea agregar un
nuevo registro, modificarlo o eliminarlo.
3.- Si selecciona agregar, insertar la entidad.
4.- Si selecciona modificar, editar la entidad.
5.- Si selecciona eliminar, eliminar la entidad.

3.4.Salidas.
Tabla V.XI: Salidas Requerimiento 3.
Destino:

Pantalla

Cantidad:

Nmero de usuarios

- 127 -

que

solicitan

un

servicio
Frecuencia:

Nmero de acceso a la
red.

Mensajes

de Datos mal ingresados

error:

3.5.Interfaces de Usuario.

Figura V.63: Insertar Estrategias

Figura V.64: Editar Estrategias

- 128 -

Figura V.65: Confirmacin Eliminar Estrategia.

4. Requerimiento 4.
Como gerente quiero llevar el proceso automtico de asignacin de actividades a los
tcnicos.
4.1.Introduccin.
Cada actividad que se desarrolla en la empresa debe asignarse a un tcnico para que
la complete por lo cual es lo que permite este requerimiento.
4.2.Entradas.
Tabla V.XII: Entradas Requerimiento 4.
Fuente:

Base de Datos SGM PRO.

Cantidad:

Una por usuario.

Frecuencia:

Posee una demanda alta.

Rango de entradas vlidas:

Disponible todo el tiempo

4.3.Procesos.
Tabla V.XIII: Procesos Requerimiento 4.
1.- El usuario accede a la aplicacin.
2.- Visualiza el plan de mantenimiento.
3.- Verifica las actividades a realizar en la semana.
4.- Asigna las actividades de esa semana a un tcnico determinado.

- 129 -

4.4.Salidas.
Tabla V.XIV: Salidas Requerimiento 4.
Destino:

Pantalla

Cantidad:

Uno por usuario

Frecuencia:

Nmero de acceso a
la aplicacin

Mensajes

de

error:

4.5.Interfaces de Usuario

Figura V.66: Asignar Actividades

5. Requerimiento 5.
Como gerente quiero que se muestre un plan de mantenimiento de todas las
actividades que se desarrollarn durante el ao de acuerdo al nmero de semana
correspondiente.
5.1.Introduccin.
El usuario necesita conocer las actividades que se debern desarrollar durante el
ao por lo cual debe visualizar el plan de mantenimiento anual.

- 130 -

5.2.Entradas.
Tabla V.XV: Entradas Requerimiento 5.
Fuente:

Base de Datos SGM Pro.

Cantidad:

Una a la vez.

Frecuencia:

Demanda alta.

Rango

de

entradas Disponible todo el tiempo.

vlidas:

5.3.Procesos.
Tabla V.XVI: Procesos Requerimiento 5.
1.- El usuario accede a la aplicacin.
2.- Selecciona la opcin Actividades en Reportes.
3.- Selecciona el ao en el que desea que se visualice
el plan.
4.- Visualiza el plan de mantenimiento.

5.4.Salidas.
Tabla V.XVII: Salidas Requerimiento 5.
Destino:

Pantalla

Cantidad:

Una por usuario.

Frecuencia:

Nmero de acceso a la red.

Mensajes
error:

de Usuario o password mal ingresado

- 131 -

5.5.Interfaces de Usuario.

Figura V.67: Historial Plan de Mantenimiento.

Figura V.68: Plan de Mantenimiento.

6. Requerimiento 6.
Como gerente quiero que se permita a los tcnicos notificar las actividades que vaya
realizando de acuerdo a la semana que toque.
6.1.Introduccin.
El tcnico puede notificar de algn inconveniente al momento de completar la
actividad.
6.2.Entradas.
Tabla V.XVIII: Entradas Requerimiento 6.
Fuente:

Base de Datos SGM PRO

Cantidad:

Una a la vez.

- 132 -

Frecuencia:

Demanda media.

Rango de entradas vlidas:

Todo el tiempo.

6.3.Procesos.
Tabla V.XIX: Procesos Requerimiento 6.
1.- El usuario visualiza las actividades que ya han sido asignadas.
2.- Selecciona la actividad que desea notificar.
3.- Notifica la actividad si hubo inconvenientes en la realizacin
de sta.
4.- Si Completa la actividad selecciona en Actividad Realizada.

6.4.Salidas.
Tabla V.XX: Salidas Requerimiento 6.
Destino:

Pantalla

Cantidad:

Una a la vez.

Frecuencia:

Nmero de acceso a la red.

Mensajes

de

error:

6.5.Interfaces de Usuario.

Figura V.69: Notificar Actividad.

- 133 -

7. Requerimiento 7.
Como gerente quiero que se permita reportar las fallas de algn equipo adems de
poder determinar el tiempo que estuvo parado ese equipo hasta su arreglo.
7.1.Introduccin.
Los equipos de mantenimiento en la empresa sufren diversas fallas, por lo cual es
necesario reportar esas fallas para su posterior arreglo y adems poder determinar el
tiempo de para que tuvo el equipo.
7.2.Entradas.
Tabla V.XXI: Entradas Requerimiento 7.
Fuente:

Base de Datos SGM PRO

Cantidad:

Una a la vez.

Frecuencia:

Alta demanda.

Rango de entradas vlidas:

Las entradas se realizan a


cualquier hora del da.

7.3.Procesos.
Tabla V.XXII: Procesos Requerimiento 7.
1.- El usuario accede a la aplicacin.
2.- Selecciona la opcin Reporte Fallas.
3.- Agrega un nuevo reporte de fallas.

7.4.Salidas.
Tabla V.XXIII: Salidas Requerimiento 7.
Destino:

Pantalla

Cantidad:

Una por usuario

Frecuencia:

Demanda Media Alta

Mensaje de Error:

Ninguno

- 134 -

7.5.Interfaces de Usuario.

Figura V.70: Ingresar Fallas.

8. Requerimiento 8
Como gerente quiero llevar el proceso automtico de asignacin de actividades a los
equipos.
8.1.Introduccin.
Cada actividad se debe asignar a un equipo determinado con el fin de que los
tcnicos desarrollen estas actividades.
8.2.Entradas.
Tabla V.XXIV: Entradas Requerimiento 8.
Fuente:

Base de Datos SGM PRO

Cantidad:

Una por usuario

Frecuencia:

Demanda Media.

Rango de entradas vlidas:

Todo el da

- 135 -

8.3.Proceso.
Tabla V.XXV: Procesos Requerimiento 8.
1.- El usuario selecciona el equipo.
2.-Selecciona la actividad que se va a asignar.
3.-Se asigna la actividad al equipo.

8.4.Salida.
Tabla V.XXVI: Salidas Requerimiento 8.
Destino:

Pantalla

Cantidad:

Demanda Media Alta

Frecuencia:

Media

Mensaje de Error:

8.5.Interfaces de Usuario.

Figura V.71: Asignar Estrategias a Equipos.

9. Requerimiento 9.
Como gerente quiero que se permita establecer bsquedas de estrategias, tcnicos,
equipos o fallas.
9.1.Introduccin.

- 136 -

En determinados momentos el usuario necesitar realizar bsquedas especficas de


las entidades para acceder ms rpido a registros determinados.
9.2.Entradas.
Tabla V.XXVII: Entradas Requerimiento 9.
Fuente:

Base de Datos SGM PRO

Cantidad:

Una por usuario.

Frecuencia:

Demanda Alta.

Rango de entradas vlidas:

Todo el da

9.3.Procesos.
Tabla V.XXVIII: Procesos Requerimiento 9.
1.- El usuario selecciona la entidad.
2.-Ingresa los parmetros de bsqueda.
3.- Busca el o los registros de acuerdo a los
parmetros pre-establecidos.

9.4.Salidas.
Tabla V.XXIX. Salidas Requerimiento 9.
Destino:

Pantalla

Cantidad:

Una por usuario

Frecuencia:

Demanda Alta

Mensaje de Error:

Parmetro establecido no es correcto.

- 137 -

9.5.Interfaces de Usuario.

Figura V.72: Buscar Estrategia Asignada a Tecnico

10. Requerimiento 10.


Como gerente quiero que se presente por cada tcnico, las actividades que ste debe
desarrollar.
10.1. Introduccin.
Se debe presentar a cada tcnico las actividades que ste debe desarrollar para su
posterior impresin.
10.2. Entradas.
Tabla V.XXX: Entradas Requerimiento 10.
Base de Datos SGM PRO

Fuente:
Cantidad:
Frecuencia:

Demanda Alta.

Rango de entradas vlidas:

Todo el da

10.3. Procesos.
Tabla V.XXXI: Procesos Requerimiento 10.
1.- Selecciona el tcnico.
2.- Revisa sus actividades.
3.- Verifica las actividades que ha realizado y las que se
deben desarrollar.

- 138 -

10.4. Salidas.
Tabla V.XXXII: Salidas Requerimiento 10.
Destino:

Pantalla

Cantidad:

Demanda Media

Frecuencia:

Dependiendo de la consulta

Mensaje de Error:

10.5. Interfaces de Usuario.

Figura V.73: Lista de Tecnicos en la Industria.

Figura V.74: Actividades de Tecnico determinado.

11. Requerimiento 11.


Como gerente quiero que se presente por cada equipo, las actividades que se deben
desarrollar en l.

- 139 -

11.1. Introduccin.
Se debe presentar por cada equipo las actividades que se deben desarrollar en ste.
11.2. Entradas.
Tabla V.XXXIII: Entradas Requerimiento 11.
Base de Datos SGM PRO

Fuente:
Cantidad:
Frecuencia:

Demanda Media.

Rango de entradas vlidas:

Dependiendo la consulta.

11.3. Procesos.
Tabla V.XXXIV: Procesos Requerimiento 11.
1.- Selecciona el equipo.
2.- Revisa sus actividades.
3.- Verifica las actividades que se deben realizar en la semana
correspondiente.

11.4. Salidas.
Tabla V.XXXV: Salidas Requerimiento 11.
Destino:

Pantalla

Cantidad:

Demanda Media

Frecuencia:

Dependiendo de la consulta

Mensaje de Error:

- 140 -

11.5. Interfaces de Usuario.

Figura V.75: Actividades de Tecnico.

5.1.1.3.2. Requerimientos de Interfaces Externas


5.1.1.3.2.1.Interfaces Hardware
Access Point.
Conectores RJ45.
Computadora.
Impresora.

5.1.1.3.2.2.Interfaces Software.
SO (XP, VISTA, SEVEN, etc.).
Servidor de BD MySQL.
Servidor GlassFish

5.1.1.3.2.3.Interfaces de Comunicacin
TCP/IP.

5.1.1.3.3. Requerimientos de Rendimiento.

5.1.1.3.3.1.Nmero de Usuarios simultneos:


Existen mltiples usuarios que van a manejar el sistema.

- 141 -

5.1.1.3.3.2.Estaciones de trabajo:
Existen muchas estaciones de trabajo.
5.1.1.3.3.3.Nmero de tablas y registros a manejar:
Existen 12 tablas.
Registros Rango (10-100).
5.1.1.3.4. Limitaciones de Diseo.

5.1.1.3.4.1.Obediencia a Estndares
SRS IEEE830.
ISO 9300.

5.1.1.3.4.2.Atributos.
Seguridad
El sistema proporcionar la integridad y la seguridad de toda la
informacin que se maneje debido a la manera de implementacin que se
utilizar. Siendo el sistema eficaz, confiable y muy seguro.
Mantenibilidad.
El sistema debido a su implementacin ser fcil de darle mantenimiento,
al mismo tiempo su mantenimiento ser econmico.
Escalabilidad.
El sistema es flexible ya que se pueden incrementar nuevas funciones de
acuerdo a los requerimientos que puedan presentarse.
Interfaz amigable.
El sistema cuenta con una interfaz de fcil manejo para el usuario final.
Disponibilidad.
El sistema deber estar disponible durante todo el da.

- 142 -

5.1.1.3.5. Otros requerimientos


5.1.1.3.5.1.Adaptacin al Sitio.
Se requieren adaptaciones a nivel de infraestructura fsica, espacio y cambios necesarios
para la adecuacin de la red.
5.1.2. BOSQUEJO DE BASE DE DATOS.
En esta etapa se va a definir un bosquejo de la base de datos de la aplicacin que se va a
desarrollar. Para el desarrollo del sistema SGM Pro se ha desarrollado un bosquejo de la
base de datos:
TABLAS Y ATRIBUTOS:
Estrategias.
o Id_Estrategia.
o Descripcin.
o Duracin.
o Frecuencia.
Tecnicos.
o Id_Tecnico.
o Cedula.
o Nombre.
o Apellidos.
o Direccion.
o Telefono.
Equipos.
o Id_equipo.
o Codigo.
o Descripcion.
o Marca.
o Modelo.
Ubicacin Tcnica.
o Id_ubicacion.
o Codigo.

- 143 -

o Descripcion.
Componentes.
o Id_componente.
o Descripcion.
Fallas.
o Id_Falla.
o Descripcion.
o Fecha.
Repuestos.
o Id_Repuesto.
o Descripcion.
o Stock.
o Costo.
RELACIONES:

EQUIPOS
TCNICOS
UBICACIN
TCNICA
ESTRATEGIAS

FALLAS

COMPONENTES

REPUESTOS

Figura V.76: Bosquejo de Base de Datos.

5.1.3. APRENDIZAJE DE FRAMEWORK JSF.

- 144 -

5.2. DESARROLLO DE BASE DE DATOS.


5.2.1. DISEO DE BASE DE DATOS.

Figura V.77: Diseo de Base de Datos.


5.2.2. CONSTRUCCIN DE PROTOTIPO EN JSF.

Figura V.78: Prototipo en JSF de Lista de Estrategias.

5.2.3. PRESENTACIN DE PROTOTIPO.


Durante esta presentacin se establecieron algunos cambios por parte del cliente en
cuanto a la base de datos, es decir, se hizo la inclusin de una nueva tabla denominada

- 145 -

Login, se agregaron nuevos atributos, se establecieron relaciones correctas entre las


tablas y se crearon algunos procedimientos almacenados.
5.2.4. DISEO FINAL DE BASE DE DATOS.
De acuerdo a estas observaciones se realiz el diseo final de la base de datos,
quedando totalmente estructurada.
5.2.4.1.DIAGRAMA DE BASE DE DATOS.

Figura V.79: Modelo Final de Base de Datos.

5.2.4.2.PROCEDIMIENTOS ALMACENADOS.
Los procedimientos almacenados que se realizaron para realizar la interaccin con la
base de datos son los siguientes:
Actualizar_inicio_semana.
Actualizar_stock.
Asignar_actividad_tecnico.
Cambiar_clave.

- 146 -

cambiarTecnicosPlan1.
Cerrar_actividad.
Comprar_repuesto.
GenerarPlanMantenimiento.

5.3. DESARROLLO DE MDULO EJB.


5.3.1. APRENDIZAJE DE FRAMEWORK EJB.
5.3.2. CREACIN DEL MDULO EJB.
Para crear el mdulo EJB, primeramente se cre una aplicacin de tipo empresarial en
el IDE NetBeans.

Figura V.80: Creando Aplicacin Empresarial.

- 147 -

Figura V.81: Aplicacin Empresarial.

A partir de esta se crean dos mdulo: uno tipo web y el otro, tipo EJB.

5.3.3. GENERACIN DE LA CAPA DE ACCESO A DATOS Y LGICA DE


NEGOCIO INICIAL.
El acceso a datos en EJB est definido por las clases entidades, sin embargo, la lgica
de negocio es definida por los beans de sesin.
5.3.3.1.ACCESO A DATOS.
Para realizar la capa de acceso a datos primero se cre las clases entidad a partir de la
base de datos:

Figura V.82: Clases entidad a partir de base de Datos.

- 148 -

Para esto se deber establecer la conexin a nuestra base de datos en el siguiente cuadro
de dilogo y seleccionar las tablas de las cuales se van a tomar los datos.

Figura V.83: Seleccin de Tablas para el acceso a datos.

Una vez realizado esto se genera la capa de acceso a datos con las siguientes clases:

Figura V.84: Capa de Acceso a Datos.

- 149 -

El cdigo que se genera en cada clase es parecido al siguiente:

Figura V.85: Cdigo Generado por la capa de Acceso a Datos.

5.3.3.2.LGICA DE NEGOCIO.
Aqu se genera un parte de la lgica de negocio. Para generarla se debe crear los Session
Bean a partir de las clases entidad creadas anteriormente:

Figura V.86: Creando los Session Bean

Luego se seleccionan las clases entidad creadas y se deja que el modulo EJB genere las
clases para la lgica de negocio de estas entidades.

- 150 -

Figura V.87: Seleccionando Clases Entidad

Una vez hecho esto se genera las siguientes clases:

Figura V.88: Lgica de Negocio

5.4. INTEGRACIN DE FRAMEWORKS.


Ahora en esta fase se va a integrar los frameworks JSF y EJB, siguiendo estas
actividades:

- 151 -

5.4.1. CREACIN DE MDULO JSF.


Este mdulo se crea en el momento de crear la aplicacin empresarial. En las
actividades anteriores se cre una aplicacin empresarial, esta aplicacin creo dos
mdulos a su vez, que era el mdulo EJB y el mdulo de tipo web.
Para que el mdulo de tipo web sea utilizado como un JSF simplemente se debe
seleccionar en este mdulo el framework JSF para desarrollo, haciendo clic derecho en
el mdulo web, luego en propiedades, apareciendo este cuadro de dilogo:

Figura V.89: Creacin de mdulo JSF.

En este cuadro de dilogo se selecciona el framework JavaServer Faces, creando de esta


manera el mdulo JSF.
5.4.2. INTEGRACIN DE JSF Y EJB.
Para integrar EJB a JSF, se debe agregar el mdulo EJB al mdulo JSF. Para esto, se
aade a las libreras del proyecto en JSF, el mdulo EJB, as como se muestra a
continuacin. De esta manera se integran ambos mdulos, haciendo uso de los
beneficios que otorgan ambos frameworks, desarrollando de esta manera una aplicacin
ms robusta.

- 152 -

Figura V.90: EJB Integrado a JSF.

5.4.3. DESARROLLO FINAL DE LA LGICA DE NEGOCIO.


En esta actividad se desarroll toda la lgica de negocio de la aplicacin.
5.5. CONSTRUCCIN FINAL DE LA APLICACIN.
5.5.1. PREPARACIN DE TEMPLATES.
Los templates que se utilizaron son los siguientes:

Figura V.91: Templates Utilizados.

- 153 -

5.5.2. DESARROLLO FINAL DE INTERFACES.


En esta actividad se desarrollaron 79 pginas aproximadamente, cada interfaz tiene un
aspecto similar al siguiente:

Figura V.92: Interfaz Final.

5.5.2. PRESENTACIN FINAL.

5.5.3. SUGERENCIAS Y MEJORAMIENTO.

5.6. IMPLEMENTACIN E IMPLANTACIN.


5.6.1. INSTALACIN DE SERVIDORES.
El servidor de base de datos a utilizar es MySQL, para instalarlo, se hace uso de la
herramienta XAMPP:

- 154 -

Figura V.93: Panel de Control de XAMPP.

Para instalar el servidor de aplicaciones en una mquina determinada, primero se debe


descargar el instalador desde el siguiente enlace:
http://dlc.sun.com.edgesuite.net/glassfish/3.1/release/glassfish-3.1-windows-ml.exe
Una vez instalado glassfish se procede con los siguientes pasos:
En

el

siguiente

path

C:\Program

Files\glassfish-

3.0.1\glassfish\domains\domain1\lib\ext se copia el archivo mysql-connectorjava.jar

(Lo

puede

descargar

desde

el

siguiente

link:

http://cdn.mysql.com/Downloads/Connector-J/mysql-connector-java-5.0.8.tar.gz).
Se Inicia en el explorador el administrador de Glassfish poniendo la url:
localhost:4848

- 155 -

Figura V.94: Consola de Administracin de GlassFish.


Se dirige a la opcin Resources JDBC Jdbc Connection Pools

Figura V.95: Conexin a MySQL en GlassFish.


Llenar los datos que se solicitan, de la siguiente manera:
o Pool Name: Mysql_Pool
o Resource Type: java.sql.Source
o Database Driver Vendor: MySql.

- 156 -

Figura V.96: Configuracin de Conexin a MySQL.

Configurar valores como el Nombre del Servidor, el Usuario, Password, etc.

Figura V.97: Parmetros de Conexin a MySQL.


Una vez llenado todos los valores se da clic en finalizar, y se hace una prueba de
conexin, si todo est bien se mostrar una pantalla de Ping Succeeded:

- 157 -

Figura V.98: Lista de Conexiones.


Ahora se debe configurar el Data Set para eso, dirigirse a Resources/JDBC/JDBC
Resources y dar en New.

Figura V.99: Lista de Recursos JDBC

En la pgina, llenar los siguientes datos.


o Jndi Name: dstMySql
o Pool name: MySqlPool

- 158 -

Figura V.100: Nuevo Recurso JDBC.


Dar clic en Ok y se crea el dataSet.

Figura V.101: Lista de Recursos JDBC.

De esta manera se ha configurado el servidor web para el alojamiento de la pgina y


para conectarse a la base de datos de la aplicacin.
El servidor web instalado es GlassFish 3.0

- 159 -

Figura V.102: Consola de GlassFish.

Figura V.103: Servidor Web GlassFish.

- 160 -

5.6.2. ALOJAMIENTO DE SITIO WEB.

Figura V.104: Alojamiento de Sitio Web.

5.6.3. PRUEBAS Y FUNCIONAMIENTO.

- 161 -

CAPITULO VI.

6. RESULTADOS Y DISCUSIN.
6.1.HIPTESIS.
6.1.1.

INTRODUCCIN.

La necesidad de determinar la mejor metodologa para el desarrollo de aplicaciones web


en un entorno de programacin JAVA, que permita minimizar el tiempo en la
construccin y mantenimiento de estas aplicaciones, requiere de un anlisis comparativo
en base a parmetros que faciliten la seleccin de una metodologa adecuada para este
fin.
Con el propsito de determinar que la metodologa propuesta es adecuada en la
optimizacin del tiempo en la construccin y mantenimiento de aplicaciones web, se
busca comparar dos prototipos de aplicaciones web, que utilizan metodologas distintas,
tales como son:
Metodologa Tradicional MSF para la construccin de aplicaciones web que utiliza
herramientas de desarrollo como JSP y JDBC.
La metodologa Propuesta ERCA Web; desarrollada en el presente trabajo
investigativo, que utiliza las herramientas JSF y EJB.

- 162 -

Para esto, se han determinado parmetros de comparacin los cuales permitirn


establecer el tiempo en la construccin y mantenimiento de aplicaciones web y obtener
un resultado de esta comparacin.
Para poder analizar y comparar las metodologas se desarroll dos prototipos, el
Prototipo 1 fue implementado siguiendo la metodologa Tradicional MSF, metodologa
que est diseada para proyectos de cualquier dimensin y de cualquier tecnologa; se
har nfasis en el uso de herramientas como son JSP y JDBC en el uso de esta
metodologa.
El Prototipo 2 fue implementado siguiendo la metodologa propuesta ERCA WEB, la
cual usa herramientas JSF y EJB en especfico.
6.1.2.

DEFINICIN DE LOS PARMETROS DE COMPARACIN.

Los parmetros y variables que a continuacin se definen para la comparacin de las


dos metodologas fueron seleccionados por los autores de esta tesis, en base a las
referencias de la informacin obtenida.
Los parmetros que se consideraron para comparar las dos metodologas han sido
establecidos segn lo visto en libros y tesis ubicadas en la Biblioteca General23 y Centro
de Documentacin de la ESPOCH:

Tabla VI.XXXVI: Lista de Parmetros.


N
1

PARMETRO
Lneas de cdigo

CONCEPTO
Cantidad de lneas de cdigo para la ejecucin de
una tarea especfica.

Reusabilidad

Poder usar partes o componentes de un software


determinado en otro proyecto.

23

Generacin de Cdigo

Capacidad para convertir un programa

Lawrence Pfleeger, S. Ingeniera del Software: Teora y Prctica. Traducido del ingls por Elvira
Quiroga. Primera ed. Buenos Aires, Argentina. s.e. 2002. pp. 119 124.

- 163 -

sintcticamente correcto en una serie de


instrucciones a ser interpretadas por una mquina.
4

Modularidad

Capacidad que tiene un sistema de ser estudiado,


visto o estudiado como la unin de varias partes
que interactan entre s y que trabajan para alcanzar
un objetivo comn, realizando cada una de ellas
una tarea necesaria para la consecucin de dicho
objetivo.

Compatibilidad

La aplicacin desarrollada con las herramientas de


estudio es compatible con sistemas operativos de
versiones anteriores.

Facilidad del consumo de datos

Capacidad de acceder a conexiones externas y


llamadas a servicios web.

Generacin automtica de

Capacidad de generacin automtica de

documentacin

documentacin tcnica teniendo nicamente como


base el cdigo y sus respectivos comentarios.

Escalabilidad.

Capacidad de un sistema informtico de cambiar su


tamao o configuracin para adaptarse a
circunstancias cambiantes.

Mantenibilidad.

Facilidad con la que un sistema o componente


software puede ser modificado para corregir fallos,
mejorar su funcionamiento u otros atributos o
adaptarse a cambios en el entorno

10

Presentacin.

Tiene que ver con la facilidad de realizar interfaces


amigables para el usuario.

- 164 -

6.1.3.

DEFINICIN DE LOS INDICADORES QUE MIDEN EL TIEMPO EN


LA CONSTRUCCIN Y MANTENIMIENTO DE APLICACIONES
WEB.

De los parmetros establecidos para la comparacin entre la metodologa tradicional y


la metodologa propuesta, se ha seleccionado los siguientes indicadores que permiten
medir la el tiempo en la construccin y mantenimiento de aplicaciones web.
Tabla VI.XXXVII: Lista de Parmetros que determinan el Tiempo.
N
1

PARMETRO
Reusabilidad

CONCEPTO
Poder usar partes o componentes de un software
determinado en otro proyecto.

Generacin de Cdigo

Capacidad para convertir un programa sintcticamente


correcto en una serie de instrucciones a ser interpretadas por
una mquina.

Modularidad

Capacidad que tiene un sistema de ser estudiado o visto


como la unin de varias partes que interactan entre s y que
trabajan para alcanzar un objetivo comn, realizando cada
una de ellas una tarea necesaria para la consecucin de dicho
objetivo.

Mantenibilidad.

Facilidad con la que un sistema o componente software


puede ser modificado para corregir fallos, mejorar su
funcionamiento u otros atributos o adaptarse a cambios en el
entorno

Presentacin.

Tiene que ver con la facilidad de realizar interfaces


amigables para el usuario.

- 165 -

Tabla VI.XXXVIII: Parmetro 1 Reusabilidad.


NDICE
Portabilidad.

DESCRIPCIN.
Se define como la caracterstica que posee un software para ejecutarse en
diferentes plataformas, el cdigo fuente del software es capaz de
reutilizarse en vez de crearse un nuevo cdigo cuando el software pasa de
una plataforma a otra.

Independencia de

Capacidad de funcionamiento de un mdulo independiente de la

componentes.

plataforma o de otro proyecto.

Facilidad de

Capacidad de integrar mdulos a otros proyectos fcilmente.

integracin.

Tabla VI.XXXIX: Parmetro 2 Generacin de Cdigo.


NDICE

DESCRIPCIN

Creacin de capa de

Es la creacin automtica utilizando herramientas de desarrollo de cdigo

acceso a datos.

para la generacin de clases que permiten el manejo de las bases de datos.

Creacin de capa de

Es la creacin automtica utilizando herramientas de desarrollo de cdigo

lgica de negocio.

para la generacin de clases que permiten el manejo de la lgica de datos.

Lneas de cdigo.

ndice que permite medir la cantidad de lneas de cdigo para la realizacin


de una consulta en especfico.

Cdigo no utilizable.

Cdigo generado o programado que no se utiliza.

Complejidad.

ndice que permite medir la facilidad o complejidad de entendimiento del


cdigo.

- 166 -

Tabla VI.XL: Parmetro 3 Modularidad.


NDICE

DESCRIPCIN

Modelo Vista

Patrn para establecer un modelo de abstraccin de desarrollo de software,

Controlador

que separa en componentes Modelo - Vista - Controlador.

Diseo

Indicador para establecer la estructura y organizacin de las diferentes

estructurado

objetos en la aplicacin web.

Capacidad de

Indicar que se utiliza para cuantificar el nivel de descomposicin de los

descomposicin

diferentes componentes web.

Comprensin

Patrn para medir el nivel de facilidad y manejabilidad del cdigo


utilizado en la aplicacin web.

Tabla VI.XLI: Parmetro 4 Mantenibilidad.


NDICE
Escalabilidad

DESCRIPCIN
Propiedad deseable de un sistema, una red o un
proceso, que indica su habilidad para reaccionar y
adaptarse sin perder calidad

Disponibilidad de

Cantidad de informacin disponible en la red o en otros

Documentacin

medios, sobre un tema especfico.

Cdigo Entendible.

Lneas de cdigo entendibles y lebles por un desarrollador


cualquiera.

Adaptabilidad a nuevos

Facilidad con la que se adapta o acopla a nuevos

requerimientos

requerimientos un software determinado.

- 167 -

Tabla VI.XLII: Parmetro 5 Presentacin.


NDICE
Templates personalizados

DESCRIPCIN
Se refiere al uso de plantillas de interfaz de usuario
preelaboradas, que permitan ahorrar tiempo en el desarrollo
de interfaces.

Componentes AJAX

Permite la creacin de aplicaciones web interactivas,


tambin llamadas aplicaciones RIA.

Validaciones

Proceso de comprobacin de si algo satisface un cierto


criterio.

Menor uso de java script

JavaScript es un lenguaje interpretado que se embebe en una


pgina web HTML. Un lenguaje interpretado significa que a
las instrucciones las analiza y procesa el navegador en el
momento que deben ser ejecutadas. Al utilizar javaScript
para

realizar

validaciones

para

ejecutar

mens

desplegables, datepickers, etc., esto hace que el desarrollo de


la aplicacin sea mayor en tiempo; en cuanto tiene que ver
en el mantenimiento y desarrollo de la aplicacin web.

6.1.4.

CRITERIOS DE EVALUACIN.

A continuacin se muestran los valores cualitativos y cuantitativos que se darn a los


parmetros a ser analizados en la comparacin de las metodologas, para lo cual se
utilizar valores del 0 al 4.
Tabla VI.XLIII: Criterios de Evaluacin General.
Cuantitativa

Cualitativa

Bajo

Medio

Medio

Medio

Alto

Bajo
Porcentajes

0%

25%

Alto
50%

75%

100%

- 168 -

6.1.5.

ANALISIS DE LOS PARMETROS DE COMPARACIN PARA LAS


METODOLOGAS.

El anlisis comparativo ser realizado en base a la informacin que se obtenga de la


investigacin bibliogrfica, tambin en base a encuestas realizadas a expertos en el tema
y a la observacin realizada por los autores de la tesis utilizando para esto los dos
prototipos implementados anteriormente.
6.1.5.1. REUSABILIDAD.
6.1.5.1.1.

PORTABILIDAD.

La portabilidad tiene que ver con el hecho de poder utilizar el cdigo fuente de un
software en uno totalmente independiente del anterior. Tambin la portabilidad se
refiere a que un sistema puede ser ejecutado en diferentes plataformas sin ningn
inconveniente. A mayor portabilidad menor es la dependencia del software con respecto
a la plataforma.
El prerrequisito para la portabilidad es la abstraccin generalizada entre la aplicacin
lgica y las interfaces del sistema. Cuando un software se puede compilar en diversas
plataformas (x86, IA64, amd64, etc.), se dice que es multiplataforma. Esta caracterstica
es importante para el desarrollo de reduccin costos, cuando se quiere hacer una misma
aplicacin. Por lo general, todo software JAVA es multiplataforma, sin embargo, no
todo software JAVA puede ser reutilizable.
El prototipo 1 desarrollado usando la metodologa tradicional que utiliza las tecnologas
JSP y JDBC puede ser ejecutado en diferentes plataformas, sin embargo, la reutilizacin
del cdigo fuente es compleja, ya que es necesario acoplar ste cdigo al nuevo
proyecto, debido a que este cdigo no funciona de forma independiente a las interfaces
de usuario.
Por otro lado el prototipo 2 desarrollado, el cual utiliza la metodologa propuesta,
usando las tecnologas JSF y EJB manejan este trmino de portabilidad completamente,
ya que si bien es multiplataforma, tambin el cdigo fuente puede ser reutilizado en
otros proyectos, debido a que el mdulo EJB, donde se maneja la lgica de negocios,
acta como un proyecto independiente de las interfaces de usuario correspondiente al
mdulo JSF.

- 169 -

De acuerdo con este anlisis se establecen los siguientes valores.


Tabla VI.XLIV: Evaluacin del ndice de Portabilidad.
METODOLOGAS
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE

TRADICIONAL
Prototipo 1

PROPUESTA
Prototipo 2

2
50%

4
100%

Portabilidad
4
4
3,5
3
2

2,5

Metodologa Tradicional
(Prototipo 1)

Metodologa Propuesta
(Prototipo 2)

1,5
1
0,5
0
Metodologa
Tradicional (Prototipo
1)

Metodologa
Propuesta (Prototipo
2)

Figura VI.105: ndice de comparacin Portabilidad.

En la Figura VI.105, se observa los resultados obtenidos para el ndice de Portabilidad,


en el cual el prototipo 2, que utiliza la metodologa propuesta, con el valor de 4 toma
ventaja sobre el prototipo 1, el cual utiliza la metodologa tradicional, ya que en el
prototipo 2 la portabilidad resulta ms efectiva que en el prototipo 1.
6.1.5.1.2.

INDEPENDENCIA DE COMPONENTES.

La independencia de componentes tiene que ver con el hecho de que un mdulo pueda
funcionar de manera independiente a otros mdulos, es decir, un mdulo independiente
no necesariamente debe estar acoplado a otros para poderse ejecutar.

- 170 -

Mediante el desarrollo del prototipo 1, se establecieron dos mdulos: Capa de Acceso a


Datos y Lgica de Negocio y Capa de Presentacin. Estos dos mdulos no pueden
actuar de manera independientes, es decir, la capa de acceso a datos y lgica de
negocios necesita de la capa de presentacin para poderse compilar, si hay un error en
cualquiera de estos mdulos, no se podrn compilar de forma separada.
Sin embargo, en el prototipo 2 que utiliza la metodologa propuesta, se establecieron de
igual forma dos mdulos: Capa de Acceso a Datos y Lgica de Negocios y la Capa de
Presentacin. La diferencia radica en que el primer modulo el cual es gestionado por el
componente EJB funciona como un proyecto independiente al segundo modulo
gestionado por JSF. Es decir, en un mismo proyecto se tiene dos proyectos ejecutndose
de forma conjunta pero no dependiente el uno del otro. Esto permite que el modulo EJB
pueda ser reutilizado en otros proyectos y acoplarse sin ninguna dificultad a estos, as
mismo el mdulo JSF.
Conforme al anlisis realizado se establecen los siguientes valores:
Tabla VI.XLV: Evaluacin del ndice de Independencia de Componentes.
METODOLOGAS
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE

TRADICIONAL

PROPUESTA

Prototipo 1

Prototipo 2

25%

75%

- 171 -

Independencia de Componentes
3
3
2,5
2
1,5

Metodologa Tradicional
(Prototipo 1)

Metodologa Propuesta
(Prototipo 2)

1
0,5
0
Metodologa
Tradicional (Prototipo
1)

Metodologa
Propuesta (Prototipo
2)

Figura VI.106: Independencia de Componentes.

En la figura VI.106 se establece los valores correspondientes al prototipo 1 que utiliza la


metodologa tradicional el cual posee un valor de 1 (medio bajo) frente al prototipo 2
que utiliza la metodologa propuesta con un valor de 4 (muy alto), determinando as que
el prototipo 2 est en ventaja frente al prototipo 1 con respecto a la independencia de
sus componentes.
6.1.5.1.3.

FACILIDAD DE INTEGRACIN.

Es muy importante poder realizar la integracin de componentes ya existentes a


proyectos o aplicaciones nuevas. La integracin puede resultar un trabajo complejo o a
la vez algo muy sencillo si se utilizan las herramientas tecnolgicas adecuadas.
En el desarrollo del prototipo 1 usando la metodologa tradicional se integraron algunos
componentes java, para su realizacin, la integracin no gener mayor complicacin.
De igual forma usando la metodologa propuesta, la integracin a otros proyectos no
genera ninguna dificultad, ya que, como se dijo anteriormente, cada mdulo se trata
como componentes separados que pueden ser integrados a cualquier proyecto.

- 172 -

Los valores establecidos respecto al anlisis hecho son:


Tabla VI.XLVI: Evaluacin del ndice Facilidad de Integracin.
METODOLOGAS
INDICADOR
|

TRADICIONAL

PROPUESTA

Prototipo 1

Prototipo 2

100%

100%

CRITERIO DE EVALUACIN
PORCENTAJE

Facilidad de Integracin
4

4
3,5
3
Metodologa Tradicional
(Prototipo 1)

2,5
2

Metodologa Propuesta
(Prototipo 2)

1,5
1
0,5
0
Metodologa
Tradicional (Prototipo
1)

Metodologa Propuesta
(Prototipo 2)

Figura VI.107: ndice Facilidad de Integracin.

En la figura VI.107 se establece que existe una facilidad de integracin alta utilizando la
metodologa tradicional as como la metodologa propuesta.
De acuerdo a al anlisis de cada ndice se obtienen los siguientes valores para medir la
reusabilidad que se obtiene desarrollando un proyecto siguiendo la metodologa
tradicional o siguiendo la metodologa propuesta.

- 173 -

Tabla VI.XLVII: Tabla General del Parmetro de Reusabilidad.


METODOLOGIAS TRADICIONAL
INDICADORES

PROPUESTA

PESO
MXIMO

PORTABILIDAD

INDEPENDENCIA DE
COMPONENTES

FACILIDAD DE
INTEGRACIN

TOTAL

11

12

58,33%

91.67%

100%

PORCENTAJE DE
REUSABILIDAD

Siguiendo la metodologa tradicional se obtiene una reusabilidad del 58,33%, mientras


que siguiendo la metodologa propuesta se obtiene una reusabilidad del 91,67%. De
modo que, est demostrado que la metodologa propuesta abarca muy bien el trmino de
reusabilidad para minimizar el tiempo en la construccin y mantenimiento de
aplicaciones web. En la siguiente figura se observan los resultados obtenidos de cada
uno de los ndices.
4

4
3,5

3
2,5

Portabilidad
2

2
1,5

Independencia de
Componentes

Facilidad de Integracin

1
0,5
0
Metodologa
Tradicional
(Prototipo 1)

Metodologa
Propuesta
(Prototipo 2)

Figura VI.108: Parmetro de Reusabilidad de acuerdo a cada ndice.

- 174 -

REUSABILIDAD
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

92%

58%
Metodologa Tradicional (JSP
y JDBC)
Metodologa Propuesta (JSF
y EJB)

Metodologa
Tradicional (JSP y
JDBC)

Metodologa
Propuesta (JSF y
EJB)

Figura VI.109: Reusabilidad en las dos metodologas.

6.1.5.1.4.

INTERPRETACIN.

De acuerdo con la figura VI.109, al utilizar la metodologa tradicional que hace uso de
herramientas como Java Server Pages (JSP) y JDBC se maneja muy poco el concepto
de Reusabilidad. Si se desea reutilizar componentes de una aplicacin realizada en JSP
con JDBC en otro proyecto se deber acoplar cada clase creada al nuevo proyecto, de
modo que esto permite que el tiempo en la construccin de un nuevo proyecto sea
mayor.
Sin embargo, utilizando la metodologa propuesta, es decir, haciendo uso de las
tecnologas Java Server Faces (JSF) y Enterprise Java Bean (EJB), la reusabilidad es un
concepto que se maneja adecuadamente, debido a que el mdulo EJB trabaja
independientemente y se acopla fcilmente a un nuevo proyecto.
Con todo esto, se demuestra que el prototipo desarrollado con JSP y JDBC no se acopla
debidamente a nuevos proyectos, mientras que el prototipo desarrollado con EJB y JSF
lo hace satisfactoriamente, ya que EJB es un proyecto independiente y puede ser
exportado a otros proyectos, de la misma forma que lo puede hacer JSF.

- 175 -

6.1.5.2. GENERACIN DE CDIGO.


6.1.5.2.1.

CREACIN DE CAPA DE ACCESO A DATOS.

La capa de acceso a datos sirve como puente entre la capa lgica de negocio y el
proveedor de datos. Este capa pretende encapsular las especificidades del proveedor de
datos tales como (SQL, Oracle, Sybase, archivos XML, texto, hojas electrnicas), a la
siguiente capa. Para que si cambia el proveedor de datos solo se necesitar cambiar en
una sola capa el proveedor de datos.
Generar el acceso a datos puede ser un proceso muy tedioso y complicado en algunos
casos, sin embargo, si se utilizan las herramientas necesarias, se podr generar esta capa
de forma automtica.
En los prototipos desarrollados con las diferentes metodologas, est realizada la capa
de acceso a datos. Esta capa fue creada de manera diferente en cada prototipo.
En el prototipo 1 que utiliza la metodologa tradicional la capa de acceso a datos se
realiz con cdigo programable por los desarrolladores, mas no por cdigo generado ya
que utilizando las tecnologas JSP y JDBC no permiten la generacin de cdigo de la
capa de acceso a datos. En cierta manera esto podra ser una ventaja para el
desarrollador ya que le permitir familiarizarse ms con el software que se est
desarrollando, y como es su propio cdigo conoce donde pueden haber posibles errores
de sintaxis o de lgica, sin embargo sera una desventaja en cuanto al tiempo de
desarrollo de la aplicacin, ya que crear el cdigo adecuado para esta capa es muy
tedioso, peor aun si se tiene una base de datos muy grande.
En el prototipo 2, donde se utiliza la metodologa propuesta, toda la capa de acceso a
datos se genera automticamente, sin necesidad que se programe, esto permite
minimizar el tiempo en la construccin de aplicaciones web, ya que el desarrollador
solo se centrara en algunos aspectos de la lgica de negocio y en la capa de
presentacin. El mdulo EJB en el cual est establecida la capa de acceso a datos y la
lgica de negocios, permite generar sin mayor inconveniente el acceso a datos
completamente, una vez que se haya establecido la conexin a la base de datos
pertinente.

- 176 -

De acuerdo con esta observacin se establecen los siguientes valores:


Tabla VI.XLVIII: Evaluacin del ndice de Creacin de Capa de Acceso a Datos.
METODOLOGAS
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE

TRADICIONAL

PROPUESTA

Prototipo 1

Prototipo 2

50%

100%

Creacin de Capa de Acceso a Datos


4
4
3,5
3
2,5

Metodologa Tradicional
(Prototipo 1)

Metodologa Propuesta
(Prototipo 2)

1,5
1
0,5
0
Metodologa
Tradicional (Prototipo
1)

Metodologa
Propuesta (Prototipo
2)

Figura VI.110: ndice Creacin de Capa de Acceso a Datos.

Dada la figura VI.110 se observa claramente que siguiendo la metodologa propuesta


utilizando las tecnologas JSF y EJB se tiene una ventaja con la metodologa tradicional
que utiliza JSP y JDBC, con respecto a la creacin de la capa de acceso a datos, ya que
en la metodologa propuesta, esta capa se genera completamente de forma automtica y
no hay que programarle, minimizando as el tiempo en la construccin de aplicaciones
web.

- 177 -

6.1.5.2.2.

GENERACIN DE CAPA DE LGICA DE NEGOCIO.

La capa de lgica de negocio es el corazn de la aplicacin. El objetivo de esta capa es


que toda la lgica de negocio est bien localizada y no mezclada con los otros objetos
de las otras capas, conllevando as a grandes ventajas. Es en esta capa donde se
establecen todas las reglas de negocio que deben cumplirse. Esta capa se comunica con
la capa de presentacin, para recibir las solicitudes y presentar los resultados, y con la
capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de l.
Utilizando la metodologa tradicional se debe programar la capa de negocio totalmente
conforme a los requerimientos de usuario establecidos ya que las tecnologas utilizadas
en esta metodologa no generan automticamente ningn tipo de cdigo para esta cap.
Usando la metodologa propuesta, el cdigo que genera con respecto a la lgica de
negocio es muy poco. Las tecnologas utilizadas en esta metodologa solo generan el
CRUD (Create, Retrieve, Update, Delete) de cada entidad, por lo que las dems reglas
de negocio deben ser programadas manualmente. As como se muestra a continuacin:

Figura VI.111: CRUD de Entidad Ubicacin Tcnica.

Dada esta observacin se establecern los siguientes valores con respecto a la


generacin de la capa de lgica de negocios:

- 178 -

Tabla VI.XLIX: Evaluacin del ndice de Creacin de Capa de Lgica de Negocio.


METODOLOGAS

TRADICIONAL

PROPUESTA

Prototipo 1

Prototipo 2

0%

25%

INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE

Creacin de Capa de Lgica de Negocios


4
3,5
3
2,5

Metodologa Tradicional
(Prototipo 1)

2
1

1,5
1

Metodologa Propuesta
(Prototipo 2)

0,5
0

Metodologa
Tradicional (Prototipo
1)

Metodologa
Propuesta (Prototipo
2)

Figura VI.112: Grfica del ndice Generacin de Capa de Lgica de Negocios.

En la figura VI.112 se observa que usando la metodologa propuesta se ahorra ms


tiempo al momento de crear la capa de lgica de negocios que usando la metodologa
tradicional, ya que la metodologa propuesta genera poco cdigo con respecto a la capa
de negocio, sin embargo la metodologa tradicional no genera ningn tipo de cdigo
para esta capa.
6.1.5.2.3.

LINEAS DE CDIGO.

- 179 -

Tabla VI.L: Criterio de Evaluacin para medir las Lneas de Cdigo.


Cuantitativa

Cualitativa

>40

30-40

20-29

10-19

<10

Porcentajes

0%

25%

50%

75%

100%

El nmero lneas de cdigo dentro de una aplicacin es muy importante para poder
mantener de mejor manera determinada aplicacin y tambin minimizar el tiempo en la
construccin de estas.
Para verificar el nmero de lneas de cdigo en cada prototipo, se escogieron
procedimientos o tareas puntuales y similares en cada uno de ellos. Se va a escoger dos
tareas en cada prototipo. La primera tarea ser la Insercin de una determinada Entidad
y la segunda tarea ser la Eliminacin de esta Entidad.
En el prototipo 1 utilizando la metodologa tradicional el nmero de lneas de cdigo es
el siguiente:
Tarea 1: Insercin de Tcnicos.

Figura VI.113: Lneas de Cdigo Mtodo Insercin Tcnicos Prototipo 1.

- 180 -

Nmero de Lneas de Cdigo: 25 lneas de cdigo.


Tarea 2: Eliminacin de Tcnicos.

Figura VI.114: Lneas de Cdigo Mtodo Eliminacin Tcnicos Prototipo 1.

Nmero de Lneas de Cdigo: 21 lneas de cdigo.


En el prototipo 2 utilizando la metodologa propuesta el nmero de lneas de cdigo es
el siguiente:
Tarea 1: Insercin de Tcnicos.

Figura VI.115: Lneas de Cdigo Mtodo Insercin Tcnicos Prototipo 2.

Nmero de Lneas de Cdigo: 4 lneas de cdigo.

- 181 -

Tarea 2: Eliminacin de Tcnicos.

Figura VI.116: Lneas de Cdigo Mtodo Eliminacin Tcnicos Prototipo 2.

Nmero de Lneas de Cdigo: 4 lneas de cdigo.


Dada esta observacin se obtienen los siguientes valores:
Tabla VI.LI: Evaluacin del ndice de Lneas de Cdigo.
METODOLOGAS

INDICADOR
LNEAS DE CDIGO

TRADICIONAL

PROPUESTA

Prototipo 1

Prototipo 2

Tarea 1

Tarea 2

25

21

Tarea 1 Tarea 2
4

PROMEDIO

23

CRITERIO DE EVALUACIN

50%

100%

PORCENTAJE

- 182 -

LINEAS DE CDIGO
4
4
3,5
3
2

2,5

Metodologa Tradicional
(Prototipo 1)

Metodologa Propuesta
(Prototipo 2)

1,5
1
0,5
0
Metodologa
Tradicional (Prototipo
1)

Metodologa
Propuesta (Prototipo
2)

Figura VI.117: Grfica del ndice Lneas de Cdigo.

Mediante la grfica se establece que utilizando la metodologa propuesta se ahorra


mucho tiempo en la programacin de una aplicacin web, ya que las lneas de cdigo
utilizadas para realizar tareas esenciales son muy pocas, en contraste con la metodologa
tradicional que utiliza de 5 a 6 veces ms lneas de cdigo que la anterior, para realizar
la misma tarea. Esto permite que se optimice el tiempo en la construccin y
mantenimiento de aplicaciones web usando la metodologa propuesta.
6.1.5.2.4.

CODIGO NO UTILIZABLE.

Tabla VI.LII: Criterio de Evaluacin para medir las Lneas de Cdigo no


utilizable.
0
1
2
3
4
Cuantitativa
Cualitativa
Porcentajes

Excesivo Mucho
0%

25%

Poco

Muy Poco

Nada

50%

75%

100%

Tener cdigo no utilizable en una aplicacin puede generar problemas al momento de


dar un mantenimiento a una determinada aplicacin, adems que puede volver pesada a
la aplicacin al momento de su ejecucin.

- 183 -

Usando la metodologa tradicional no se encontrar problemas de cdigo innecesario o


no utilizable ya que el cdigo aqu es propiamente programado por el desarrollador, y
este cdigo es utilizado en toda la aplicacin. Sin embargo, usando la metodologa
propuesta, como la mayora del cdigo es generado, se genera cdigo que es innecesario
y que no se utiliza en la aplicacin, por lo cual esto sera una gran desventaja al utilizar
esta metodologa.
El nmero de lneas de cdigo no utilizable que se genera usando la metodologa
propuesta es de: 6 lneas por cada Entidad.

Figura VI.118: Cdigo no utilizable en la Metodologa Propuesto en la Capa de


Acceso a Datos.

Adems genera cdigo no utilizable en la capa de negocios con un total de 15 lneas por
entidad:

Figura VI.119: Cdigo no utilizable en la Metodologa Propuesto en la Capa de


Lgica de Negocios.

Realizada esta observacin se establecen los siguientes valores:

- 184 -

Tabla VI.LIII: Evaluacin del ndice de Cdigo no utilizable.


METODOLOGAS
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE

TRADICIONAL

PROPUESTA

Prototipo 1

Prototipo 2

100%

25%

CODIGO NO UTILIZABLE
4
4
3,5
3
2,5

Metodologa Tradicional
(Prototipo 1)

2
1

1,5
1

Metodologa Propuesta
(Prototipo 2)

0,5
0
Metodologa
Tradicional (Prototipo
1)

Metodologa
Propuesta (Prototipo
2)

Figura VI.120: Grfica del ndice Cdigo no Utilizable.

De acuerdo a la figura VI.120 se establece que usando la Metodologa Tradicional, el


cdigo fuente de una aplicacin web va a ser aprovechado por completo y no dar lugar
a cdigo innecesario que implique dificultad al momento de mantener una aplicacin o
al momento de construirla. Por el contrario la metodologa propuesta genera cdigo
innecesario, no utilizable, para el desarrollo de aplicaciones web.

- 185 -

6.1.5.2.5.

COMPLEJIDAD.
Tabla VI.LIV: Criterio de Evaluacin para medir la Complejidad.
0

Cualitativa

Muy Alta

Alta

Media

Baja

Muy Baja

Porcentajes

0%

25%

50%

75%

100%

Cuantitativa

Este ndice tiene que ver con cun entendible o no es el cdigo creado o generado en
una aplicacin web. Mientras ms entendible sea el cdigo menos tiempo se necesitar
para construir o mantener una aplicacin. Para construir aplicaciones usando la
metodologa tradicional el cdigo creado es entendible por cualquier desarrollador de
software, ya que las tecnologas que utiliza se basan a la programacin orientada a
objetos y es muy fcil de entender por cualquier desarrollador. Sin embargo usando la
metodologa propuesta, si se desea entender completamente el cdigo generado o
creado se debe tener un basto conocimiento sobre la programacin en JAVA, de todos
modos, el cdigo aqu es un poco entendible para cualquier desarrollador de software ya
que de una u otra manera tambin se basa en la programacin orientada a objetos.
En el prototipo 1, para poder realizar el listado de todos los tcnicos de una base de
datos se escribe simplemente una consulta sql:

Este cdigo es entendible para cualquier desarrollador.


Sin embargo, en el prototipo 2, para realizar el listado de todos los tcnicos, se tiene el
siguiente cdigo:

Dado estos criterios se obtienen los siguientes valores:

- 186 -

Tabla VI.LV: Evaluacin del ndice de Complejidad.


METODOLOGAS
INDICADOR

TRADICIONAL

PROPUESTA

Prototipo 1

Prototipo 2

75%

25%

CRITERIO DE EVALUACIN
PORCENTAJE

COMPLEJIDAD
4
3,5

3
2,5

Metodologa Tradicional
(Prototipo 1)

2
1

1,5
1

Metodologa Propuesta
(Prototipo 2)

0,5
0
Metodologa
Tradicional (Prototipo
1)

Metodologa
Propuesta (Prototipo
2)

Figura VI.121: Grfica del ndice Complejidad.

Analizada la figura VI.121 se concluye que usando la metodologa tradicional el cdigo


que se genera es muy entendible y esto ayuda para un mejor mantenimiento a la
aplicacin minimizando as el tiempo en el mantenimiento. Por otro lado, se establece
una complejidad en el cdigo si se usa la metodologa propuesta, afectando de esta
manera a un mantenimiento ptimo y eficaz y a maximizar el tiempo en la construccin
de nuevas aplicaciones.
De acuerdo al anlisis de cada ndice se obtienen los siguientes valores para medir la
generacin de cdigo que se obtiene desarrollando un proyecto siguiendo la
metodologa tradicional o siguiendo la metodologa propuesta.

- 187 -

Tabla VI.LVI: Valores de cada ndice del Parmetro de Generacin de Cdigo.


METODOLOGIA
TRADICIONAL

PROPUESTA

PESO
MXIMO

Creacin de capa de acceso a


datos.

Creacin de capa de lgica de


negocio.

Lneas de cdigo.

Cdigo no utilizable.

Complejidad.

Total

11

11

20

55,00%

55,00%

100%

INDICADORES

Porcentaje de generacin de
cdigo

Siguiendo la metodologa tradicional se obtiene una eficacia de generacin de cdigo


del 55%, de la misma forma siguiendo la metodologa propuesta se obtiene una eficacia
de generacin de cdigo del 55%. De modo que, usando cualquiera de estas dos
metodologas el cdigo tendr el mismo grado de eficacia y el tiempo en la construccin
y mantenimiento de aplicaciones web ser constante. En la siguiente figura se observan
los resultados obtenidos de cada uno de los ndices.

- 188 -

4
3,5

Creacin de Capa de Acceso a


Datos

3
2,5

Creacin de Capa de Lgica


de Negocios

Lneas de Cdigo

1,5

1
0,5

Cdigo no utilizable
Complejidad

0
Metodologa
Tradicional (JSP y
JDBC)

Metodologa
Propuesta (JSF y EJB)

Figura VI.122: Grfica de Valores del Parmetro Generacin de Cdigo.

GENERACIN DE CDIGO
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

Metodologa Tradicional
(JSP y JDBC)
55%

Metodologa
Tradicional (JSP y
JDBC)

55%

Metodologa Propuesta (JSF


y EJB)

Metodologa
Propuesta (JSF y
EJB)

Figura VI.123: Grfica Porcentual del Parmetro Generacin de Cdigo.

- 189 -

6.1.5.2.6.

INTERPRETACIN.

En cuanto a la generacin de cdigo se puede observar en la figura VI.123 que tanto


usando una metodologa tradicional como usando la metodologa propuesta existe un
55% de utilidad del cdigo que se genera, por lo cual, usando una que otra metodologa
no se minimizar el tiempo en la construccin y/o mantenimiento de aplicaciones web.
6.1.5.3. MODULARIDAD.
6.1.5.3.1.

MODELO VISTA CONTROLADOR

Es un patrn o modelo de abstraccin de desarrollo de software que separa los datos de


una aplicacin, la interfaz de usuario, y la lgica de negocio en tres componentes
distintos. El patrn de llamada y retorno MVC (segn CMU), se ve frecuentemente en
aplicaciones web, donde la vista es la pgina HTML y el cdigo que provee de datos
dinmicos a la pgina.
El prototipo realizado por la Metodologa Propuesta es realizado de acuerdo a este
ndice, obteniendo ventajas como son:
Sencillez para crear distintas representaciones de los mismos datos.
Facilidad para la realizacin de pruebas unitarias de los componentes, as como
de aplicar desarrollo guiado por pruebas (TDD).
Reutilizacin de los componentes.
Simplicidad en el mantenimiento de los sistemas.
Facilidad para desarrollar prototipos rpidos.
Los desarrollos suelen ser ms escalables.
De acuerdo con este anlisis se establecen los siguientes valores.
Tabla VI.LVII: Evaluacin del ndice de Modelo Vista Controlador.
METODOLOGIAS TRADICIONAL
INDICADOR
Prototipo 1
CRITERIO DE EVALUACIN
1
PORCENTAJES
25%

PROPUESTA
Prototipo 2
4
100%

- 190 -

Modelo Vista Controlador


4
3,5
3
2,5

Metodologa Tradicional
(Prototipo 1)
Metodologa Propuesta
(Prototipo 2)

1,5
1

0,5
0

Metodologa
Tradicional (Prototipo
1)

Metodologa
Propuesta (Prototipo
2)

Figura VI.124: ndice de comparacin Modelo Vista Controlador.

Se puede observar en la figura VI.124 que el prototipo 2 de la Metodologa Propuesta


tiene un valor mayor al prototipo 1, esto debido al patrn Modelo Vista Controlador
que adopta la Metodologa Propuesta.
6.1.5.3.2.

DISEO ESTRUCTURADO

El hecho de que una Metodologa no adopte el Modelo Vista Controlador en su


desarrollo de software no implica que su diseo estructurado este mal.
Definicin:
Diseo estructurado es el proceso de decidir que componentes, y la interconexin entre
los mismos, para solucionar un problema bien especificado.
Frente a esto se puede encontrar los siguientes beneficios: Eficiencia, Mantenibilidad,
Modificabilidad, Flexibilidad, Generalidad, Utilidad.
En el desarrollo de los prototipos se ha encontrado que tanto la Metodologa Tradicional
como la Metodologa Propuesta siguen un diseo bien estructurado, razn por la cual
tienen el mismo porcentaje de calificacin en este ndice.

- 191 -

De acuerdo con este anlisis se establecen los siguientes valores.


Tabla VI.LVIII: Evaluacin del ndice de Diseo Estructurado.
METODOLOGAS TRADICIONAL
INDICADOR
Prototipo 1
CRITERIO DE EVALUACIN
4
PORCENTAJES
100%

PROPUESTA
Prototipo 2
4
100%

Diseo Estructurado
4
3,5
3
2,5
4

Metodologa Tradicional
Metodologa Propuesta

1,5
1
0,5
0
Metodologa
Tradicional

Metodologa
Propuesta

Figura VI.125: ndice de comparacin Diseo Estructurado.

6.1.5.3.3.

CAPACIDAD DE DESCOMPOSICIN

ndice que mide el tiempo que se ahorra cuando se hace una aplicacin web, mediante
la capacidad de descomponer el trabajo en mdulos independientes, tambin se toma en
consideracin a la hora de unificar los mdulos y obtener la aplicacin total sin
complicaciones.
La aplicacin tradicional utiliza un concepto claro de descomposicin, utilizado
mediante paquetes, clases, pginas web; sin embargo en las pginas web se mezcla la
las paginas HTML y paginas JSP, haciendo esto que sea un tanto difcil a la hora de la

- 192 -

unificacin de mdulos. Por su contraparte la Metodologa Propuesta tiene bien


marcada la separacin de los que son las paginas XHTML con la lgica de proceso de
las paginas como son los BackBeans.

Figura VI.126: Pgina HTML prototipo 1.

Figura VI.127: Pgina XHTML y Backbean.

De acuerdo con este anlisis se establecen los siguientes valores.

- 193 -

Tabla VI.LIX: Evaluacin del ndice de Capacidad de Descomposicin.


METODOLOGAS TRADICIONAL
INDICADOR
Prototipo 1
CRITERIO DE EVALUACIN
2
PORCENTAJES
50%

PROPUESTA
Prototipo 2
4
100%

Capacidad de Descomposicin
4
3,5
3
2,5
4

Metodologa Propuesta

1,5
1

Metodologa Tradicional

0,5
0
Metodologa
Tradicional

Metodologa
Propuesta

Figura VI.128: ndice de comparacin Capacidad de Descomposicin.

6.1.5.3.4.

COMPRENSIN.

Es mejorar la facilidad de comprensin del cdigo o cambiar su estructura y diseo y


eliminar cdigo muerto, para facilitar el mantenimiento en el futuro. Aadir nuevo
comportamiento a un programa puede ser difcil con la estructura dada del programa,
as que un desarrollador puede refactorizarlo primero para facilitar esta tarea y luego
aadir el nuevo comportamiento.
Este ndice sirve para medir la optimizacin del tiempo de desarrollo de una aplicacin
web especialmente a la hora de mantener la pgina.
En el desarrollo de la investigacin, se ha notado que el prototipo 1 realizado por la
Metodologa Tradicional en sus pginas de presentacin mezclan cdigo HTML con

- 194 -

cdigo java, esto hace que la comprensin del funcionamiento sea muy difcil, como se
muestra en la figura.

Figura VI.129: Comprensin de cdigo prototipo 1.

Se observa en la figura VI.129 como el cdigo java es insertado en paginas HTML, esto
hace muy difcil la comprensin de la estructuracin de la pagina HTML.
No as la Metodologa Propuesta en el cual se facilita la comprensin de cdigo, ya que
la lgica se la realiza en el backbean, como se muestra en la figura.

Figura VI.130: Comprensin de cdigo prototipo 2.

De acuerdo con este anlisis se establecen los siguientes valores.

- 195 -

Tabla VI.LX: Evaluacin del ndice de Comprensin del Cdigo.


METODOLOGAS TRADICIONAL
INDICADOR
Prototipo 1
CRITERIO DE EVALUACIN
2
PORCENTAJES
50%

PROPUESTA
Prototipo 2
4
100%

Comprensin del Codigo


4
3,5
3
2,5

Metodologia Tradicional

1,5
1

Metodologia Propuesta

0,5
0
Metodologia
Tradicional

Metodologia
Propuesta

Figura VI.131: ndice de comparacin Comprensin del Cdigo.

Como se observa en la figura VI.131 se ahorra un 50 % de tiempo ms; a la hora de


entender el cdigo y realizar el mantenimiento de las aplicaciones web con el uso de la
Metodologa Propuesta.
Tabla VI.LXI: ndices - Parmetro Modularidad.
METODOLOGAS
INIDICADORES
Modelo Vista Controlador
Diseo Estructurado
Capacidad de
Descomposicin
Comprensin del Cdigo
TOTAL
PORCENTAJE DE
PRESENTACIN

TRADICIONAL

PROPUESTA

PESOS
MXIMOS

1
4
2

4
4
4

4
4
4

2
9
56,25%

4
16
100%

4
16
100%

- 196 -

4
3,5
3

Modelo Vista Controlador

2,5

Diseo Estructurado

2
1,5

Capacidad de
Descomposicin

Comprensin de Cdigo

1
0,5
0
Metodologa
Tradicional

Metodologa
Propuesta

Figura VI.132: ndices de comparacin Modularidad.

MODULARIDAD
100
80
60
100%

40
56,25%

METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA

20
0
METODOLOGA
TRADICIONAL

METODOLOGA
PROPUESTA

Figura VI.133: Porcentajes totales - Modularidad.

- 197 -

6.1.5.3.5.

INTERPRETACIN.

Se puede observar en la figura VI.133 que el parmetro Modularidad tiene un 100% de


optimizacin de tiempo, usando la metodologa propuesta, permitiendo adaptar los
beneficios que ofrece este parmetro, no as el prototipo que utiliza la Metodologa
Tradicional que ha calificado con la mitad aproximadamente de optimizacin de tiempo
en el parmetro Modularidad.
6.1.5.4. MANTENIBILIDAD.
6.1.5.4.1.

ESCALABILIDAD.

La escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que


indica su habilidad para reaccionar y adaptarse sin perder calidad, o bien manejar el
crecimiento continuo de trabajo de manera fluida, o bien para estar preparado para
hacerse ms grande sin perder calidad en los servicios ofrecidos.
En el desarrollo de aplicaciones web es comn cambios de requerimientos como
tambin adaptacin de nuevos requerimientos, es muy importante tener en cuenta este
factor ya que si la aplicacin es escalable se va ahorrar mucho tiempo en la construccin
de los nuevos requerimientos.
Metodologa Tradicional.
La metodologa tradicional permite la escalabilidad de una manera no ptima ya que no
tiene separado claramente la lgica de negocios con la lgica de presentacin y lgica
de acceso a datos. Para lo cual en la adaptacin de nuevos requerimientos se debe
realizar una re-estructuracin de todo el cdigo.
Metodologa Propuesta.
La Metodologa propuesta simplifica las cosas como ya que tiene separada claramente
toda la lgica, de manera que es escalable fcilmente.
De acuerdo con este anlisis se establecen los siguientes valores.

- 198 -

Tabla VI.LXII: Evaluacin del ndice de Escalabilidad.


METODOLOGAS
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJES

TRADICIONAL
Prototipo 1
2
50%

PROPUESTA
Prototipo 2
4
100%

Escalabilidad
4
3,5
3
2,5
4

Metodologa Propuesta

1,5
1

Metodologa Tradicional

0,5
0
Metodologa
Tradicional

Metodologa
Propuesta

Figura VI.134: ndice de comparacin Templetes Personalizados.

En la Figura VI.134, se observa los resultados obtenidos para el ndice de Escalabilidad,


en el cual el prototipo 1, tiene un porcentaje medio de escalabilidad frente al prototipo 2
que es desarrollada por la Metodologa Propuesta.
6.1.5.4.2.

DISPONIBILIDAD DE DOCUMENTACIN.

Mediante este indicador se sabr la cantidad en porcentaje de tiempo ahorrado, a la hora


de buscar informacin ya sea en foros, libros, wikis, etc, para la construccin o
mantenibilidad de la aplicacin web.
Se puede decir que utilizando la Metodologa Tradicional se ahorra mucho tiempo a la
hora de buscar informacin para la construccin de aplicaciones web, ya que esta utiliza
tcnicas estables y conocidas, lo cual hace que haya mucha disponibilidad de

- 199 -

documentacin, no as en la Metodologa Propuesta ya que utiliza tcnicas nuevas y no


se tendr mucha documentacin.
De acuerdo con este anlisis se establecen los siguientes valores.
Tabla VI.LXIII: Evaluacin del ndice de Disponibilidad de Documentacin.
METODOLOGAS TRADICIONAL
INDICADOR
Prototipo 1
CRITERIO DE EVALUACIN
4
PORCENTAJES
100%

PROPUESTA
Prototipo 2
1
25%

Disponibilidad de Documentacin
4
3,5
3
2,5
2

Metodologa tradicional

Metodologia Propuesta

1,5
1
1

0,5
0
Metodologa
tradicional

Metodologia
Propuesta

Figura VI.135: ndice de comparacin Disponibilidad de Documentacin.

En la figura VI.135 se observa que la Metodologa Propuesta no ahorra tiempo a la hora


de buscar documentacin, a lo contrario de la Metodologa Tradicional que ahorra un
100% de tiempo a la hora de buscar documentacin para el desarrollo de aplicaciones
web.

- 200 -

6.1.5.4.3.

CDIGO ENTENDIBLE.

Es un ndice muy importante que se toma en consideracin principalmente a la hora de


la mantenibilidad de las aplicaciones web. Mide que tan entendible es el cdigo que se
ha utilizado en la construccin de las aplicaciones web.
Utilizando la Metodologa Tradicional los desarrolladores de software estn obligados a
escribir todo el cdigo razn por la cual es ms entendible a la hora de la
mantenibilidad. Como se muestra en la figura de un ejemplo para llamar un
procedimiento almacenado.

Figura VI.136: Cdigo de Mtodo Insertar Prototipo 1.

Utilizando la Metodologa Propuesta la mayor parte de cdigo es generado por


frameworks, razn por la cual existe mayor cdigo no entendible a la hora de la
construccin y manteniblidad de aplicaciones web.
Ejemplo en el Grafico se muestra cdigo generado por frameworks.

- 201 -

Figura VI.137: Cdigo Generado por Framework.

De acuerdo con este anlisis se establecen los siguientes valores.


Tabla VI.LXIV: Evaluacin del ndice de Cdigo Entendible.
METODOLOGAS

TRADICIONAL
Prototipo 1
4
100%

INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJES

PROPUESTA
Prototipo 2
3
75%

Cdigo Entendible
4
3
2

Metodologa
Tradicional

4
3

Metodologa
Propuesta

0
Metodologa
Tradicional

Metodologa
Propuesta

Figura VI.138: ndice de comparacin Cdigo Entendible.

- 202 -

En la figura VI.138 se observa que el prototipo realizado con la Metodologa


Tradicional tiene como porcentaje 100% , esto quiere decir que todo su cdigo es
entendible y favorece a la hora de re-estructurar algunos requerimientos, tambin se
observa que el prototipo que utiliza la Metodologa Propuesta tiene 75% pretendiendo
decir que hace un poco difcil la comprensin del cdigo.
6.1.5.4.4.

ADAPTABILIDAD DE NUEVOS REQUERIMIENTOS.

Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no


funcionales. Los requerimientos funcionales definen las funciones que el sistema ser
capaz de realizar. Describen las transformaciones que el sistema realiza sobre las
entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra
forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de
equipo), mantenimiento, seguridad, portabilidad, estndares, etc.
La capacidad de introducir nuevos requerimientos sin la dificultad a la hora de
programar, por ende ganar tiempo y recursos.
De acuerdo con este anlisis se establecen los siguientes valores.
Tabla VI.LXV: Evaluacin del ndice de Adaptabilidad de Nuevos
Requerimientos.
METODOLOGAS
TRADICIONAL
PROPUESTA
INDICADOR
Prototipo 1
Prototipo 2
CRITERIO DE EVALUACIN
2
4
PORCENTAJES
50%
100%

- 203 -

Adapatabilidad de Nuevos
Requerimientos
4
3,5
3
2,5

Metodologa Tradicional

Metodologia Propuesta

1,5

1
0,5
0

Metodologa
Tradicional

Figura VI.139:
Requerimientos.

ndice

Metodologia
Propuesta

de

comparacin

Adaptabilidad

de

Nuevos

Como se observa en la figura VI.139 el prototipo realizado con la Metodologa


propuesta ofrece el doble de productividad en lo que tiene que ver con el tiempo, en la
adaptablidad de Nuevos Requerimientos frente al prototipo realizado con la
Metodologa Tradicional.
Tabla VI.LXVI: Tabla general de ndices - parmetro Mantenibilidad.
METODOLOGAS
INIDICADORES
Escalabilidad
Disponibilidad de
Documentacin
Cdigo Entendible
Adaptabilidad de nuevos
requerimientos
TOTAL
PORCENTAJE DE
PRESENTACIN

TRADICIONAL

PROPUESTA

PESOS
MXIMOS

2
4

4
1

4
4

4
2

3
4

4
4

12
75%

12
75%

16
100%

- 204 -

4
3,5
3
3
Escalabilidad
2,5
2

Disponibilidad de
Documentacin

Codigo Entendible
1,5
1

Adaptabilidad de nuevos
Requerimientos

1
0,5
0
Metodologa
Tradicional

Metodologa
Propuesta

Figura VI.140: ndices de comparacin - Mantenibilidad

MANTENIBILIDAD
100
80
60
40

75%

20

75%

METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA

0
METODOLOGA
TRADICIONAL

METODOLOGA
PROPUESTA

Figura VI.141: Porcentajes totales Mantenibilidad.

- 205 -

6.1.5.4.5.

INTERPRETACIN.

En este parmetro como es el de Mantenibilidad se observa en la figura VI.141 que


tanto la Metodologa Tradicional como la Metodologa Propuesta tienen un mismo
porcentaje de ahorro de tiempo en cuanto tiene que ver con la construccin y adaptacin
de nuevos requerimientos en una aplicacin web.
Debido a los indicadores de: Documentacin Disponible y Cdigo entendible, la
Metodologa Tradicional ofrece varias ventajas frente a la Metodologa Propuesta, sin
embargo los indicadores de: Escalabilidad y Adaptacin de Nuevos Requerimientos
trae desventajas frente a la Metodologa Propuesta.
6.1.5.5. PRESENTACIN.
6.1.5.5.1.

TEMPLATES PERSONALIZADOS.

El uso de templating trae consigo las ventajas de tener un cdigo ordenado (sobre todo
en aplicaciones grandes), fcil de desarrollar y reusar. Se puede crear componentes o
templates que abarcan desde simplemente mostrar texto hasta crear componentes que
muestren un checkbox, un input o un dropdown dependiendo de la data del backing
bean.
En la metodologa tradicional se desarrollan los Templates mediante hojas de estilo, no
as en la metodologa propuesta que ofrece Templates personalizados que benefician en
el tiempo a la hora de la creacin de los Templates.
Templates en Metodologa Tradicional
La metodologa tradicional para el uso de de Templates hace uso de un sin nmero de
tcnicas tales como son jquery, javascript, frames, etc.

- 206 -

Figura VI.142: Hojas de Estilo prototipo 1.

Figura VI.143: Referencias - Hojas de Estilo prototipo 1.

Templates en Metodologa Propuesta.


La Metodologa propuesta simplifica las cosas como se muestra a continuacin.

- 207 -

Figura VI.144: Templates prototipo 2.

Figura VI.145: Referencias - Templates prototipo 2.

De acuerdo con este anlisis se establecen los siguientes valores.


Tabla VI.LXVII: Evaluacin del ndice de Templates Personalizados.
METODOLOGAS TRADICIONAL
INDICADOR
Prototipo 1
CRITERIO DE EVALUACIN
3
PORCENTAJES
75%

PROPUESTA
Prototipo 2
4
100%

- 208 -

Templates Perzonalizados
4
3,5
3
2,5
2
1,5
1
0,5
0

Metodologa
Tradicional

Metodologa Tradicional
Metodologa Propuesta

Metodologa
Propuesta

Figura VI.146: ndice de comparacin Templates Personalizados.

En la Figura VI.146, se observa los resultados obtenidos para el ndice de Templates


Personalizados, en el cual el prototipo 2, que utiliza la metodologa propuesta, con el
valor de 4 toma ventaja sobre el prototipo 1, el cual utiliza la metodologa tradicional,
esto significa que utilizando los Templates personalizados que ofrece la metodologa
propuesta se obtiene mayor ventaja en el ahorro de tiempo en la construccin de los
mismos.
6.1.5.5.2.

COMPONENTES AJAX.

Es una tcnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich
Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el
navegador de los usuarios mientras se mantiene la comunicacin asncrona con el
servidor en segundo plano. De esta forma es posible realizar cambios sobre las pginas
sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y
usabilidad en las aplicaciones.
Ajax permite cargar la pgina en segundo plano sin actualizar la pgina completa y la
presentacin. Ajax es un script simple JavaScript que trabajar con XML peticin HTTP.

Ajax en Metodologa Tradicional (JSP).

- 209 -

Para realizar componentes ajax con jsp, se debe implementar un sin nmero de clases y
mtodos, haciendo as a la aplicacin ms demorosa, como se muestra en las figuras
siguientes.
Index.jsp

Figura VI.147: Ajax en JSP.

Figura VI.148: Funcin AJAX.

- 210 -

Figura VI.149: AJAX HTML.

AJAX en Metodologa Propuesta (JSF con PrimeFaces)


Para implementar AJAX con JSF, se hace ms fcil simplemente se utiliza pocas lneas
de cdigo, como se muestra en las siguientes figuras.
Tcnico.xhtml

Figura VI.150: AJAX XHTML prototipo 2.

- 211 -

Backbean equipoEstrategia.calcular

Figura VI.151: AJAX PRIMEFACES.

De acuerdo con este anlisis se establecen los siguientes valores.


Tabla VI.LXVIII: Evaluacin del ndice de Componentes AJAX.
METODOLOGAS
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE

TRADICIONAL
Prototipo 1
1
25%

PROPUESTA
Prototipo 2
3
75%

Componentes AJAX
4
3,5
3
2,5

2
1,5
1
0,5

Metodologa Tradicional
Metodologa Propuesta

0
Metodologa
Tradicional

Metodologa
Propuesta

Figura VI.152: ndice de comparacin Componentes AJAX.

- 212 -

En la Figura VI.152, se observa los resultados obtenidos para el ndice de Componentes


AJAX, se puede concluir diciendo que ambas metodologas utilizan componentes
AJAX, sin embargo, la metodologa tradicional hace se uso de forma ms extensa y
difcil, no as la metodologa propuesta en la cual ahorra mucho tiempo para el
desarrollo de componentes AJAX.
6.1.5.5.3.

VALIDACIONES.

La validacin se define como: El proceso de comprobacin de si algo satisface un cierto


criterio. Los ejemplos incluyen la comprobacin de si una afirmacin es verdadera (la
validez), si un aparato funciona como est previsto, si un sistema es seguro, o si los
datos informticos son compatibles con un estndar abierto. La validacin implica un
documento, puede que la solucin o el proceso es correcto o es adecuado para su uso.
La validacin de HTML y CSS es un proceso que no es impuesto sobre un diseador /
desarrollador. Sin embargo, se realiza con el fin de asegurar la compatibilidad y la
estabilidad de una pgina web a travs de los distintos navegadores. El defensor nmero
de la validacin es el W3C (World Wide Web Consortium). La validacin es la mejor
manera de evitar diversas irregularidades en la prestacin de una pgina web.
Validaciones Metodologa Tradicional.
Se utiliza validaciones usando javascript, no tiene mensajes de error personalizados.

Figura VI.153: Validaciones prototipo 1.

- 213 -

Validaciones Metodologa Propuesta.


Posee validaciones personalizadas y mensajes de error personalizados.

Figura VI.154: Validaciones prototipo 2.

De acuerdo con este anlisis se establecen los siguientes valores.


Tabla VI.LXIX: Evaluacin del ndice de Validaciones.
METODOLOGAS
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE

TRADICIONAL
Prototipo 1
3
75%

PROPUESTA
Prototipo 2
4
100%

- 214 -

Validaciones
4
3,5
3
2,5

2
1,5

Metodologa Tradicional
Metodologa Propuesta

1
0,5
0
Metodologa
Tradicional

Metodologa
Propuesta

Figura VI.155: ndice de comparacin Validaciones.

En la Figura VI.155, se observa los resultados obtenidos para el ndice de Validaciones,


se puede concluir diciendo que tanto la metodologa tradicional como la metodologa
propuesta utilizan validaciones, pero aqu la metodologa propuesta supera por poco a la
metodologa tradicional, ya que trae incluidos mensajes personalizados de error.
6.1.5.5.4.

MENOR USO DE JAVA SCRIPT.

JavaScript, al igual que Flash, Visual Basic Script, es una de las mltiples maneras que
han surgido para extender las capacidades del lenguaje HTML (lenguaje para el diseo
de pginas de Internet). Al ser la ms sencilla, es por el momento la ms extendida.
JavaScript no es un lenguaje de programacin propiamente. Es un lenguaje script u
orientado a documento, como pueden ser los lenguajes de macros que tienen muchos
procesadores de texto y planillas de clculo. No se puede desarrollar un programa con
JavaScript que se ejecute fuera de un Navegador.
JavaScript es un lenguaje interpretado que se embebe en una pgina web HTML. Un
lenguaje interpretado significa que a las instrucciones las analiza y procesa el navegador
en el momento que deben ser ejecutadas.

- 215 -

Al utilizar javaScript para realizar validaciones o para ejecutar mens desplegables,


datepickers hace que el desarrollo de la aplicacin sea mayor en tiempo; en cuanto tiene
que ver en el mantenimiento y desarrollo de la aplicacin web.
Es decir al utilizar menos java script en el desarrollo de una aplicacin web, ser ms
beneficioso en tiempo de desarrollo y construccin.
Java Script en Metodologa Tradicional

Figura VI.156: JavaScript prototipo 1.

- 216 -

Java Script en Metodologa Propuesta.

Figura VI.157: JavaScript prototipo 2.

De acuerdo con este anlisis se establecen los siguientes valores.


Tabla VI.LXX: Evaluacin del ndice de Menor Uso de JavaScript.
METODOLOGAS
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE

TRADICIONAL
Prototipo 1
2
50%

PROPUESTA
Prototipo 2
4
100%

- 217 -

Menor Uso Javascript


4
3,5
3
2,5
Metodologia Tradicional

1,5
1

Metodologia Propuesta

0,5
0
Metodologia
Tradicional

Metodologia
Propuesta

Figura VI.158: ndice de comparacin Menor Uso de Javascript.

En la figura VI.158, se observa los resultados obtenidos para el ndice de Menor Java
Script, se puede notar que la Metodologa Propuesta es ms optima en cuanto tiene que
ver con este ndice ya que hace un uso casi nulo de Javascript y no as la Metodologa
tradicional que usa Javascript para realizar muchas de sus acciones.
Tabla VI.LXXI: Tabla general de ndices - parmetro Presentacin
METODOLOGAS
TRADICIONAL PROPUESTA
INDICADORES
Templates personalizados
Componentes AJAX
Validaciones
Menor Uso De Java Script
TOTAL
PORCENTAJE

3
1
3
2
9
56,25%

4
3
4
4
15
93,75%

PESOS
MXIMOS
4
4
4
4
16
100%

- 218 -

4
3,5

3
2,5

Templetes personalizados

Componentes AJAX

Validaciones

1,5

Menor uso de Javascript

1
0,5
0
Metodologa
Tradicional

Metodologa Propuesta

Figura VI.159: ndices de comparacin -Presentacin.

PRESENTACION
100
80
60
93,75%

40
56,25%

METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA

20
0
METODOLOGA
TRADICIONAL

METODOLOGA
PROPUESTA

Figura VI.160: Porcentajes Totales - Presentacin.

- 219 -

6.1.5.5.5.

INTERPRETACIN.

En consecuencia de la valoracin de los diferentes ndices para este parmetro se tiene


como resultado que el Prototipo que utiliza la Metodologa Tradicional ha alcanzado un
porcentaje de 56,25% y que el Prototipo que utiliza la Metodologa Propuesta ha
alcanzado un porcentaje del 93,75%, esto quiere decir que utilizando la Metodologa
Propuesta se optimiza tiempo en cuanto tiene que ver con el parmetro de Presentacin
para el desarrollo y tiempo de mantenibilidad de pginas web.

ANLISIS GENERAL DE COMPROBACIN.

6.1.6.

6.1.6.1. HIPTESIS.

Mediante el desarrollo de una metodologa para la construccin de una aplicacin web a


travs de la integracin de las tecnologas JSF y EJB se minimizar el tiempo en la
construccin y mantenimiento de aplicaciones web.
6.1.6.1.1.

DETERMINACIN DE VARIABLES.

Variable Independiente. Metodologa para la construccin de una aplicacin web a


travs de la integracin de las tecnologas JSF y EJB.
Variable Dependiente. Tiempo en la construccin y mantenimiento de aplicaciones
web.
6.1.6.1.2.

OPERACIONALIZACIN DE LAS VARIABLES.

Operacionalizacin Conceptual.
Tabla VI.LXXII: Operacionalizacin Conceptual.
VARIABLE
Metodologa

para

construccin

de

TIPO
la

Independiente

CONCEPTO
Conjunto

de

etapas

una

formalmente estructuradas,

aplicacin web a travs de

de manera que brinden a los

la

interesados parmetros de

integracin

de

tecnologas JSF y EJB.

las

accin en el desarrollo de
sus proyectos: plan general

- 220 -

detallado,

tareas

acciones,

tiempos,

aseguramiento de la calidad,
involucrados,
revisiones

etapas,
de

avance,

responsables,

recursos

requeridos, entre otros.


Tiempo en la construccin y
mantenimiento

Dependiente

de

Es el periodo o lapso de
tiempo utilizado desde que

aplicaciones web.

se inicia el desarrollo de la
aplicacin hasta su fin.

Operacionalizacin Metodolgica.
Tabla VI.LXXIII: Operacionalizacin Metodolgica.
VARIABLE

CATEGORA

INDICADORES

TCNICAS

FUENTES DE
VERIFICACIN

Metodologa

Investigacin

Revisin de

Metodologa

Internet.

para la

para

el Documentos

Libros.

construccin de

desarrollo

de

Manuales.

una aplicacin

software

Tutoriales.

Prototipo 1

Prototipo 2

Prototipo 1

web a travs de
la integracin
de las
tecnologas JSF
y EJB.
Tiempo en la
construccin y

Reusabilidad.

Observacin

Tiempo

mantenimiento

Generacin

de aplicaciones

Cdigo.

Observacin

Prototipo 2

web.

Modularidad.

Observacin

Prototipo 1

Prototipo 2

Prototipo 1

de

Mantenibilidad.

Observacin

- 221 -

Presentacin.

Observacin

Prototipo 2

Prototipo 1

Prototipo 2

6.1.6.2. COMPARACIN DE LOS RESULTADOS OBTENIDOS.

Para la comprobacin de hiptesis se utilizar el Mtodo Estadstico Chi cuadrado, se


trabajar con los porcentajes, valores observados:
De acuerdo a la evaluacin realizada por cada parmetro se establecieron valores que
permiten determinar la minimizacin del tiempo en la construccin y mantenimiento de
aplicaciones web. En la tabla siguiente se muestra los valores obtenidos.
Tabla VI.LXXIV: Paramaros de Optimizacin de tiempo y cuantificacin
METODOLOGAS
OPTIMIZACIN DE TIEMPO
REUSABILIDAD
GENERACIN DE CDIGO
MODULARIDAD
MANTENIBILIDAD
PRESENTACIN

TRADICIONAL PROPUESTA
58,33

91,67

55

55

56,25

100

75

75

56,25

93,75

- 222 -

100
100

93,75

91,67

90
75 75

80
70

58,33

60

55 55

56,25

56,25

50
40

Metodologa Tradicional

30

Metodologa Propuesta

20
10
0

Figura VI.161: Tabla General de Valores.

La figura VI.161 representa los valores obtenidos en cada parmetro de cada


metodologa. Mientras ms alto sea el valor del parmetro de la metodologa, se
establece que es ms ptima para minimizar el tiempo de desarrollo y construccin de
aplicaciones web.
Usando la Metodologa Propuesta se obtiene mayor Reusabilidad, Modularidad y
Presentacin de interfaces, permitiendo de esta manera minimizar el tiempo en la
construccin y mantenimiento de aplicaciones web.
Entonces, con respecto a la metodologa tradicional, la metodologa propuesta permite
minimizar el tiempo en la construccin y mantenimiento de aplicaciones web en un
21,25% ms, as como se observa en la figura:

- 223 -

Porcentaje General
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

81%

Metodologa Propuesta

60%

Metodologa
Tradicional

Metodologa Tradicional

Metodologa
Propuesta

Figura VI.162: Porcentaje General.

La figura VI.162 refleja que se optimiza el tiempo en un 21% utilizando la Metodologa


Propuesta ERCA Web que usa tecnologas como JSF y EJB, con respecto a la
Metodologa Tradicional MSF que utiliza tecnologas como JSP y JDBC.

6.1.6.2.1.

APLICACIN DE CHI CUADRADO.

Planteamiento de la hiptesis:
Ho: Las Metodologa Propuesta NO optimizara el tiempo en la construccin de
aplicaciones web mediante la Integracin JSF y EJB.
H1: Las Metodologa Propuesta optimizara el tiempo en la construccin de aplicaciones
web mediante la Integracin JSF y EJB.
Encontrar los totales por cada fila y por cada columna:
Tabla VI.LXXV: Valores Observados y Totales.
METODOLOGAS

TOTAL

- 224 -

OPTIMIZACIN

DE TRADICIONAL

PROPUESTA

FILAS

58,33

91,67

150

55

55

110

56,25

100

156,25

75

75

150

PRESENTACIN

56,25

93,75

150

TOTAL COLUMNAS

300,83

415,42

716,25

TIEMPO
REUSABILIDAD
GENERACIN

DE

CDIGO
MODULARIDAD
MANTENIBILIDAD

Valores esperados
De la tabla VI.LXXV, que son los valores observados, se encuentra los valores
esperados, con la siguiente formula

Ejemplo:

Valor Esperado (1,1) = 63,00


Obteniendo como resultado los siguientes valores esperados:
Tabla VI.LXXVI: Valores Esperados y Totales.
METODOLOGAS
OPTIMIZACIN

DE TRADICIONAL PROPUESTA

TOTAL
FILAS

TIEMPO
REUSABILIDAD

63,00

87,00

150

GENERACIN DE CDIGO

46,20

63,80

110

MODULARIDAD

65,63

90,62

156,25

- 225 -

MANTENIBILIDAD

63,00

87,00

150

PRESENTACIN

63,00

87,00

150

TOTAL COLUMNAS

300,83

415,42

716,25

Se obtiene el valor de Chi cuadrado mediante la frmula:

Tabla VI.LXXVII: Resumen Valores Observados y valores Esperados.


Valores Observados

Reusabilidad
Generacin de Cdigo
Modularidad
Mantenibilidad
Presentacin

X2calc =
+

X2calc = 0,35
X2calc = 10,99

Valores Esperados

M.

M.

M.

M.

Tradicional

Propuesta

Tradicional

Propuesta

58,33

91,67

63,00

87,00

55

55

46,20

63,80

56,25

100

65,63

90,62

75

75

63,00

87,00

56,25

93,75

63,00

87,00

- 226 -

Chi cuadrado experimental = 10,99


Grados De Libertad
Para calcular los grados de libertad se realiza con la frmula:
V = (Cantidad de filas - 1) (Cantidad de columnas - 1)
Grados de libertad = (5-1) (2-1) = 4
Nivel de confianza.
Por lo general se trabaja con un porcentaje de 95% (0,95), es decir el nivel de error es
del 5%(0,05).

Figura VI.163: Tabla de Chi-Cuadrado.

Obteniendo el valor critico con 4 grados de libertad y valor de error de 0,05 = 9,49
Conclusin:
Como el chi cuadrado experimental es mayor al valor critico, cae en la zona de rechazo
de la Hiptesis Nula (Ho), aceptando la Hiptesis Alternativa.
10,99 > 9,49

- 227 -

6.1.6.2.2.

CLCULOS OBTENIDOS CON SOFTWARE ESTADSTICO SPSS

Clculos: para la obtencin de los datos que se muestran en la tabla, se utilizo el software
SPSS el cual es un programa estadstico informtico.

Ingreso de datos al programa.

Figura VI.164: Ingreso de datos al Spss.

Resultados.
Valores esperados.

Figura VI.165: Optimizacin del tiempo Metodologas.

- 228 -

Valor del chi cuadrado

Figura VI.166: Resultado Chi cuadrado SPSS.

Valores obtenidos con SPSS


Chi cuadrado experimental = 11,245
El valor critico con 4 grados de libertad y valor de error de 0,05 = 9,49
11,245 > 9,49 se rechaza hiptesis nula.
Aceptacin de Hiptesis Alternativa
H1: Las Metodologa Propuesta optimizara el tiempo en la construccin de aplicaciones
web mediante la Integracin JSF y EJB.

- 229 -

CONCLUSIONES.
Una vez realizado los anlisis pertinentes se ha llegado a las siguientes conclusiones:
Se desarroll una Metodologa para la construccin de aplicaciones web
mediante la integracin de JSF y EJB la cual fue aplicada para la construccin
del software de gestin SGM Pro, que permiti minimizar el tiempo de
desarrollo de la aplicacin.
Java Server Faces permite realizar interfaces de usuario de una manera ms
fcil, rpida y de forma profesional, con la posibilidad de incorporar cdigo para
complementar la lgica de negocio.
Enterprise Java Bean es una herramienta que permite generar automticamente
la capa de acceso datos y parte de la lgica de negocio sin esfuerzo alguno.
La integracin de EJB y JSF permite realizar aplicaciones web de tipo
empresarial, de forma estructurada, ordenada y escalable; adems de ahorrar
tiempo en la construccin de estas.
La utilizacin de las herramientas tecnolgicas JSF y EJB permiti desarrollar el
mdulo de Plan de Mantenimiento de una manera fcil y rpida.
La Metodologa Propuesta ERCA Web que utiliza tecnologas de desarrollo
como JSF y EJB permite minimizar el tiempo en un 21% ms, con respecto a la
Metodologa Tradicional MSF que usa tecnologas como JSP y JDBC.

- 230 -

RECOMENDACIONES.
Una vez realizado el trabajo investigativo, se han establecido las siguientes
recomendaciones:
Investigar ms a fondo sobre las tecnologas utilizadas en la metodologa ERCA
Web, de modo que en un futuro se pueda mejorar esta metodologa.
Utilizar libreras compatibles con JSF para crear interfaces de usuarios de una
forma ms rpida, amigable e intuitiva; adems de no ingresar cdigo de
negocio si no es realmente necesario.
Dedicar un tiempo considerable en el diseo y construccin de la base de datos
de la aplicacin, de modo que no haya inconvenientes al momento de que se
genere la capa de acceso a datos y de lgica de negocios por parte del
framework EJB.
Estudiar y analizar profundamente las tecnologas EJB, JSF y los beneficios de
su integracin, para hacer uso de toda la potencialidad que estas tecnologas
ofrecen.
Para la construccin de aplicaciones web pequeas se recomienda usar
solamente el framework JSF, ya que este maneja internamente el concepto de
EJB.

- 231 -

RESUMEN.
La formulacin, desarrollo e implementacin de la aplicacin web de gestin de
mantenimiento industrial utilizando la metodologa ERCA Web fue implantada en el
Hospital General Provincial Docente Chimborazo en la Ciudad de Riobamba, en la
Facultad de Informtica y Electrnica en la Escuela Superior Politcnica de
Chimborazo.
Se aplic un mtodo experimental e inductivo, utilizando herramientas de software libre
para el desarrollo de la aplicacin. Se realiz dos prototipos de software; el primer
prototipo de desarroll utilizando la metodologa tradicional de desarrollo de
aplicaciones web, la cual usa herramientas como JSP y JDBC, mientras que el segundo
prototipo se desarroll utilizando la metodologa propuesta (ERCA Web) de desarrollo
de aplicaciones web, que usa tecnologas como JSF y EJB.
La metodologa que permite minimizar el tiempo en la construccin y mantenimiento de
aplicaciones web es la Metodologa ERCA Web, obteniendo una Reusabilidad del 92%,
Generacin de Cdigo del 55%, Modularidad del 100%, Mantenibilidad del 75% y
Presentacin del 93,75%; logrando as minimizar el tiempo de construccin y
mantenimiento de aplicaciones web en un 21% ms que la Metodologa Tradicional.
De esta manera se concluye que utilizando la Metodologa ERCA Web en el desarrollo
y mantenimiento de aplicaciones web se reduce el tiempo en la construccin de stas.
Se recomienda investigar ms a fondo de las tecnologas usadas en la metodologa
ERCA Web, de modo que se pueda mejorar esta metodologa en un futuro.

- 232 -

ABSTRACT.
The present thesis is the formulation, development and implementation of an industrial
maintenance management using the ERCA Web Methodology in the Hospital
Provincial General Docente Riobamba, through the Informatics and Electronics Faculty
from Higher Polytenich School of Chimborazo.
The current web applications nowadays have influenced hugely in the enterprise world
in consequence is important to investigate the usage of new tools to simplify the
construction of these ones.
The main problems that are pretended to solve are the construction time and web
application maintenance in order to use different technologies. It was made two
prototypes, each one to determine if the proposed research solves the problem.
Among the main objectives of this work are: to analyze the JSF and API Framework,
also to study and develop the JSF integration through EJB, and finally to develop the
methodology for a web application construction through integration.
It was applied an experimental and inductive method, using free software tools for the
development of the application. It was made two kinds of software, the first one it was
developed using the traditional method of web applications development, which uses
tools such as: JSP and JDBC, while the second prototype was made using the proposed
methodology (ERCA Web) of web development of applications that uses technologies
like JSF and EJB.
The methodology allows to minimize the construction time and web application
maintenance which is the ERCA Web Methodology, obtaining a Reusability if 92%;
Code Generation of 55%, Modularity of 100%, Maintenance of 75% and Presentation
of 93,75%; managing to minimize the construction time and web applications
maintenance by 21% more than the Traditional Methodology.
On this way it can conclude that using ERCA Web Methodology in the development
and the web applications, the time is reduced in their construction.
It is recommended to investigate deeper about the used technologies in the ERCA Web
Methodology, on this form this methodology could be used in the future.

- 233 -

ANEXOS.
INTERFACES DE APLICACIN SGM PRO.
Index.xhtml

Login.xhtml

ubicacionTecnica.xhtml

- 234 -

agregarUbicacion.xhtml

editarUbicacion.xhtml

listaEquipos.xhtml

agregarEquipo.xhtml

- 235 -

equiposEstrategia.xhtml

asignarEquipoEstrategia.xhtml

- 236 -

listaEstrategias.xhtml

agregarEstrategias.xhtml

editarEstrategias.xhtml

- 237 -

listaTecnicos.xhtml

listaRepuestos.xhtml

historialMantenimiento.xhtml

- 238 -

planMantenimiento.xhtml

buscarSemanaPlan.xhtml

planMantenimientoSemana.xhtml

planMantenimientoSemanaAsignar.xhtml

- 239 -

listadoFallas.xhtml

agregarFalla.xhtml

listaTecnicos1.xhtml

- 240 -

listaActividad.xhtml

- 241 -

ENCUESTA REALIZADA A EXPERTOS.

Proyecto de Tesis Escuela de Ingeniera en Sistemas


Objetivo: determinar la optimizacin de tiempo en el desarrollo de aplicaciones web
mediante la utilizacin de diferentes herramientas de programacin.
Nota: Encuesta dirigida para programadores que utilicen herramientas de programacin
como son JSP, JDBC, JSF Y EJB.
1. Seleccione el nivel de portabilidad de cada uno de las tecnologas.

2. Seleccin el nivel de que herramienta considera que tiene independencia de


componentes.

3. Seleccin el nivel de que herramienta considera que tiene facilidad de


integracin con nuevas herramientas de programacin.

4. Seleccin el nivel de que herramienta le facilita la creacin de la capa de


acceso a datos.

5. Seleccin el nivel que tiene cada herramienta considerando la facilidad de la


creacin de la capa de lgica.

- 242 -

6. Seleccione el nivel de que herramienta se la hace ms complejo utilizar.

7. Defina el nivel de la capacidad de descomposicin de las herramientas.

8. Defina el nivel de escalabilidad.

9. Mediante que herramientas se le hace ms fcil para la adaptacin de


nuevos requerimientos.

10. Con que herramienta se le hace ms fcil en la construccin de templetes


personalizados.

11. Establezca la facilidad del uso de componentes AJAX.

- 243 -

12. Establezca la facilidad del uso de validaciones en las pginas web.

13. Establezca la facilidad de uso de java script.

- 244 -

GLOSARIO.
Administrador

Persona responsable del manejo del sistema.

Aplicacin

Tipo de programa informtico diseado como herramienta para


permitir a un usuario realizar uno o diversos tipos de trabajo.

Arquitectura

Nivel de diseo que hace foco en aspectos "ms all de los


algoritmos y estructuras de datos de la computacin; el diseo y
especificacin de la estructura global del sistema es un nuevo tipo
de problema".

Atributo

Indica una o ms caractersticas de un objeto.

Bean

Componente software que tiene la particularidad de ser


reutilizable y as evitar la tediosa tarea de programar los distintos
componentes uno a uno.

Cliente

Persona que usa el sistema.

Concurrencia

Es el grado en que las fases, etapas o actividades pueden ser


superpuestas a pesar de que no tengan relacin entre s.

Cookies

Fragmento de informacin que se almacena en el disco duro del


visitante de una pgina web a travs de su navegador

Diseo

Proceso de definicin de la arquitectura, componentes, interfaces


y otras caractersticas de un sistema o componente que resulta de
este proceso

Framework

Es una estructura conceptual y tecnolgica de soporte definido,


normalmente con artefactos o mdulos de software concretos, con
base a la cual otro proyecto de software puede ser ms fcilmente
organizado y desarrollado.

Hardware

Corresponde a todas las partes fsicas y tangibles de una


computadora:

sus

componentes

electromecnicos y mecnicos.

elctricos,

electrnicos,

- 245 -

Implementacin

Realizacin de una aplicacin, o la ejecucin de un plan, idea,


modelo cientfico, diseo, especificacin, estndar, algoritmo o
poltica.

Ingeniera

Conjunto de conocimientos y tcnicas cientficas aplicadas a la


invencin, perfeccionamiento y utilizacin de la tcnica industrial
en todos sus diversos aspectos incluyendo la resolucin u
optimizacin de problemas que afectan directamente a los seres
humanos en su actividad.

Interfaz

Lo que es visible para el usuario.

Internet

Conjunto

descentralizado

de

redes

de

comunicacin

interconectadas que utilizan la familia de protocolos TCP/IP,


garantizando que las redes fsicas que la componen funcionen
como una red lgica nica, de alcance mundial.
Intranet

Es una red de ordenadores privados que utiliza tecnologa Internet


para compartir dentro de una organizacin parte de sus sistemas
de informacin y sistemas operacionales.

Java

Es un lenguaje de programacin orientado a objetos, desarrollado


por Sun Microsystems a principios de los aos 90.

Javascript

Lenguaje de scripting basado en objetos no tipeado y liviano,


utilizado para acceder a objetos en aplicaciones. Principalmente,
se utiliza integrado en un navegador web permitiendo el
desarrollo de interfaces de usuario mejoradas y pginas web
dinmicas.

Middleware

Software de conectividad que ofrece un conjunto de servicios que


hacen posible el funcionamiento de aplicaciones distribuidas
sobre plataformas heterogneas.

Persistencia

Se refiere a la propiedad de los datos para que estos sobrevivan de


alguna manera.

- 246 -

Protocolo

Conjunto de reglas usadas por computadoras para comunicarse


unas con otras a travs de una red.

Proxy

Referencia a un programa o dispositivo que realiza una accin en


representacin de otro.

Requisitos

Necesidad

documentada

sobre

el

contenido,

forma

funcionalidad de un producto o servicio.


Servidor

Computadora que, formando parte de una red, provee servicios a


otras computadoras denominadas clientes.

Servlets

Son objetos que corren dentro del contexto de un contenedor de


servlets (ej: Tomcat) y extienden su funcionalidad.

Software

Conjunto de programas, mtodos y procedimientos relacionados


con la explotacin, funcionamiento y manejo de un sistema de
proceso de datos.

Threads

Hilo de ejecucin o subproceso es una caracterstica que permite a


una aplicacin realizar varias tareas a la vez.

Web

Red informtica, especialmente para referirse a internet.

- 247 -

BIBLIOGRAFA.
1. CORONEL, E., Desarrollando soluciones con Java y MySQL., Editorial
macro., 2009., Pp. 428.

2. KEOGH, J., J2EE: Manual de Referencia., Editorial McGraw-Hill


Interamericana., 2002., Pp. 803.

3. ROZANSKI, U., Enterprise Java Bean 3.0 con Eclipse y JBoss., Barcelona,
Editorial Alfaomega, MARCOMBO S.A., 2009., Pp. 563.

4. SIERRA, M., Ajax en J2EE., Editorial Alfaomega., 2008., Pp. 264.

TESIS.
5. VALDIVIEZO, P., GUACHO, M., ANLISIS COMPARATIVO DE
TECNOLOGAS DE APLICACIONES WEB EN EL ENTORNO JSF
Y ADF. CASO PRCTICO: IESS DE RIOBAMBA: CHIMBORAZO.

BIBILOGRAFA DE INTERNET.
6. ENTERPRISE JAVA BEAN.
http://osgg.net/omarsite/resources/proceedings/EJB.pdf
2011/12/21.

- 248 -

7. ESTUDIO,

COMPARATIVA

APLICACIN

PRCTICA

DE

METODOLOGAS DE DESARROLLO DE APLICACIONES WEB EN


JAVA.
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/619/1/00804tf
c.pdf
2012/04/18

8. JAVA SERVER FACES.


http://www.sicuma.uma.es/sicuma/Formacion/documentacion/JSF.pdf
2011/12/21.

9. JAVA SERVER FACES.


http://ccia.ei.uvigo.es/docencia/SCS/1011/transparencias/Tema53.JSF.pdf
2012/03/20.

10. JAVA SERVER FACES: RICHFACES Y ICEFACES.


http://www.slideshare.net/israelalcazar/introduccin-jsf-richfaces-eicefaces-2267358
2012/03/15.

11. PRIME FACES.


http://www.primefaces.org/showcase/ui/home.jsf
2012/05/12.

12. PROGRAMACIN DE APLICACIONES WEB.


http://gplsi.dlsi.ua.es/~slujan/materiales/pi-cliente2-muestra.pdf
2012/01/02.

- 249 -

13. RECURSOS EJB.


http://www.dsc.ufcg.edu.br/~jacques/cursos/map/recursos/ejb/white_pa
per.pdf
2012/12/28.
14. TUTORIAL JSF 2.0 Y PRIMEFACES.
http://www.javahispano.org/storage/1.%20Parte%20I%20%20NetBeans.pdf
2012/06/02.

También podría gustarte