Ejemplo
Ejemplo
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.
ANTECEDENTES. _______________________________________________ 25
1.2.
JUSTIFICACIN. ________________________________________________ 27
1.2.1.
1.2.2.
1.3.
OBJETIVOS. ___________________________________________________ 30
1.3.1.
GENERAL. ______________________________________________________________ 30
1.3.2.
ESPECFICOS. ___________________________________________________________ 30
1.4.
HIPTESIS. ___________________________________________________ 30
CAPTULO II.
2.
2.1.1.
2.1.2.
2.1.2.1.
CARACTERSTICAS. ____________________________________________________ 34
2.1.2.2.
2.1.2.3.
2.1.2.4.
BACKBEANS. _________________________________________________________ 38
2.1.2.4.1.
-3-
2.1.2.5.
2.1.2.6.
2.1.3.
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.
ATRIBUTOS. ________________________________________________________________ 42
EXPRESIONES PARA VALORES INMEDIATOS Y DIRECTOS. ____________________________ 43
MBITO DE LOS BEANS. _______________________________________________________ 43
2.1.4.2.
NAVEGACIN. ________________________________________________________ 44
2.2.
2.2.1.
INTRODUCCION. ________________________________________________________ 46
2.2.2.
2.2.3.
2.2.3.1.
2.2.3.2.
2.2.3.3.
2.2.3.4.
2.2.3.5.
2.2.4.
2.2.4.1.
2.2.4.2.
2.2.4.3.
2.2.5.
2.2.5.1.
2.2.5.2.
2.2.5.3.
2.2.5.4.
SEGURIDAD. _________________________________________________________ 55
2.2.5.5.
TRANSACCIONES. _____________________________________________________ 55
2.2.5.6.
PERSISTENCIA. ________________________________________________________ 56
2.2.6.
-4-
2.2.6.1.
2.2.6.2.
2.2.6.3.
2.2.7.
CAPTULO III.
3.
INTRODUCCIN. _______________________________________________ 59
3.2.
3.3.
3.3.1.
3.3.2.
3.3.3.
3.3.3.1.
3.3.4.
3.3.4.1.
3.3.4.2.
CAPTULO IV.
4.
4.2.
4.2.1.
4.2.1.1.
4.2.2.
4.3.
4.3.1.
4.3.1.1.
4.3.1.2.
4.3.1.3.
4.3.1.4.
4.3.1.5.
4.3.1.6.
-5-
4.3.2.
4.3.2.1.
4.3.2.2.
4.3.2.3.
4.3.3.
4.3.3.1.
4.3.3.2.
4.3.3.3.
4.3.3.4.
4.3.4.
4.3.4.1.
4.3.4.2.
4.3.4.3.
4.3.5.
4.3.5.1.
4.3.5.2.
4.3.5.3.
4.3.6.
4.3.6.1.
4.3.6.2.
4.3.6.3.
4.3.6.4.
4.3.7.
4.3.7.1.
4.3.7.2.
4.3.7.3.
CAPTULO V.
5.
5.1.1.
5.1.1.1.
5.1.1.1.1.
5.1.1.1.2.
5.1.1.1.3.
-6-
5.1.1.2.
5.1.1.2.1.
5.1.1.2.2.
5.1.1.2.2.
5.1.1.2.3.
5.1.1.2.4.
5.1.1.3.
5.1.1.3.1.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
5.1.1.3.2.
5.1.1.3.3.
5.1.1.3.4.
5.1.1.3.5.
5.1.2.
5.1.3.
5.2.
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.3.
5.2.4.1.
5.2.4.2.
5.3.1.
5.3.2.
-7-
5.3.3.
5.4.
5.3.3.1.
5.3.3.2.
5.4.1.
5.4.2.
5.4.3.
5.5.
5.5.1.
5.5.3.
5.6.
5.6.1.
5.6.2.
5.6.3.
CAPITULO VI.
6.
6.1.1.
6.1.2.
6.1.3.
6.1.5.
6.1.5.1.
6.1.5.1.1.
6.1.5.1.2.
6.1.5.1.3.
6.1.5.1.4.
6.1.5.2.
6.1.5.2.1.
6.1.5.2.2.
-8-
6.1.5.2.3.
6.1.5.2.4.
6.1.5.2.5.
6.1.5.2.6.
6.1.5.3.
6.1.5.3.1.
6.1.5.3.2.
6.1.5.3.3.
6.1.5.3.4.
6.1.5.3.5.
6.1.5.4.
6.1.5.4.1.
6.1.5.4.2.
6.1.5.4.3.
6.1.5.4.4.
6.1.5.4.5.
6.1.5.5.
6.1.5.5.1.
6.1.5.5.2.
6.1.5.5.3.
6.1.5.5.4.
6.1.5.5.5.
6.1.6.
6.1.6.1.
6.1.6.1.1.
6.1.6.1.2.
6.1.6.2.
6.1.6.2.1.
6.1.6.2.2.
CONCLUSIONES.
RECOMENDACIONES.
RESUMEN.
ABSTRACT.
ANEXOS.
-9-
- 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 -
- 12 -
- 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 -
- 16 -
- 17 -
- 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
- 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
- 20 -
FIRMAS
Nota:
FECHA
- 21 -
NDICE DE ABREVIATURAS.
ADF
API
ASP
AWT
CGI
CRUD
DI
Dependence Injection
EJB
ERP
ESPOCH
HQL
HTML
HTTP
IBM
IDE
IoC
Inversion of Control
ISO
J2EE
J2SE
JAAS
jBPM
- 22 -
JDBC
JDK
JDO
JMS
JPA
JPOX
JSF
JSP
LDAP
MDB
MSF
MVC
ODBC
OJB
ORM
Object-Relational Mapping
PHP
POA
POJO
RMI
RUP
SQL
UI
Interfaz de Usuario
- 23 -
URI
URL
XML
XUL
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.
- 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 -
- 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 -
- 29 -
Registro de Usuarios.
Tcnicos.
Equipos.
Componentes.
Fallas Equipos.
Estrategias.
Ubicaciones Tcnicas.
Reportes.
- 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.
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 -
- 34 -
- 35 -
- 36 -
- 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 -
- 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.
- 40 -
- 41 -
- 42 -
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
- 45 -
- 46 -
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 -
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 -
- 50 -
12
JTA: Establece una serie de Interfaces java entre el manejador de transacciones y las partes
involucradas en el sistema de transacciones distribuidas.
- 51 -
implcito.
Los
contenedores
EJB
automticamente
reciben
- 52 -
- 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 -
13
14
- 55 -
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 -
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 -
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.
- 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 -
- 63 -
PrimeFaces: Componente para JavaServer Faces que cuenta con un conjunto de componentes ricos que
facilitan la creacin de las aplicaciones web
- 64 -
- 65 -
- 66 -
Figura III.11: Creando el Proyecto => Proyectos creados por el IDE NetBeans.
- 67 -
Figura III.13: Creando las clases entidades => Seleccionar Clase Entidad a
partir de Base de Datos.
- 68 -
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 -
- 70 -
puede
notar
la
creacin
de
las
clases
Customer.java
DiscountCode.java
Figura III.18: Creando las clases entidades => Clases entidades creadas.
- 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.
Stateless, y terminar.
- 72 -
Figura III.21: Creacin de los MDB => Nuevo Message Drive Bean.
En la ventana que aparece poner los siguientes datos, Ejb Name
NotificationBean,
- 73 -
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 -
- 75 -
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.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.
- 78 -
- 79 -
- 80 -
- 81 -
- 82 -
selecciona
"Nuevo>
JSF
Managed
Bean...",
especifique
- 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 -
en
cuenta
la
variable
que
se
genera
automticamente,
- 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")
}
- 86 -
- 87 -
Figura III.39: Usando JSF y PrimeFaces => Tabla JSF desde la Entidad.
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:
- 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,
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 -
de
clientes
en
la
URL,
http://localhost:8080/CustomerApp-
- 91 -
- 92 -
CAPTULO IV.
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
- 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 -
- 96 -
- 97 -
Planificacin.
Anlisis de Requerimientos.
Bosquejo de Base de Datos.
Aprendizaje de framework JSF.
Integracin de Frameworks.
Creacin de mdulo JSF.
Integracin de JSF y EJB.
Desarrollo Final de Capa de Lgica de Negocio.
Implementacin e Implantacin.
Instalacin de Servidores.
Alojamiento de Aplicacin Web.
Pruebas de funcionamiento.
- 98 -
- 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 -
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.
Robustez.
Portabilidad.10
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 -
- 103 -
- 104 -
- 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 -
- 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:
- 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 -
- 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.
- 112 -
- 113 -
- 114 -
- 115 -
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.
- 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 -
SGM PRO
MODULO
PLANIFICACIN
MODULO
REPORTE
FALLAS
MODULO DE
GESTION
- 120 -
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
- 121 -
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. 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:
Cantidad:
Relacionado
con
las
necesidades de la empresa.
Depende de los requerimientos
Frecuencia:
del usuario.
Rango de entradas vlidas:
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:
Frecuencia:
- 124 -
Mensajes
de
error:
1.5.Interfaces de Usuario.
Aplicacin web.
Cantidad:
Frecuencia:
- 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:
Frecuencia:
Mensajes
de
error:
2.5.Interfaces de Usuario.
- 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:
Cantidad:
Frecuencia:
Demanda alta.
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
error:
3.5.Interfaces de Usuario.
- 128 -
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:
Cantidad:
Frecuencia:
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:
Frecuencia:
Nmero de acceso a
la aplicacin
Mensajes
de
error:
4.5.Interfaces de Usuario
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:
Cantidad:
Una a la vez.
Frecuencia:
Demanda alta.
Rango
de
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:
Frecuencia:
Mensajes
error:
- 131 -
5.5.Interfaces de Usuario.
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:
Cantidad:
Una a la vez.
- 132 -
Frecuencia:
Demanda media.
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:
Mensajes
de
error:
6.5.Interfaces de Usuario.
- 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:
Cantidad:
Una a la vez.
Frecuencia:
Alta demanda.
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:
Frecuencia:
Mensaje de Error:
Ninguno
- 134 -
7.5.Interfaces de Usuario.
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:
Cantidad:
Frecuencia:
Demanda Media.
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:
Frecuencia:
Media
Mensaje de Error:
8.5.Interfaces de Usuario.
9. Requerimiento 9.
Como gerente quiero que se permita establecer bsquedas de estrategias, tcnicos,
equipos o fallas.
9.1.Introduccin.
- 136 -
Cantidad:
Frecuencia:
Demanda Alta.
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:
Frecuencia:
Demanda Alta
Mensaje de Error:
- 137 -
9.5.Interfaces de Usuario.
Fuente:
Cantidad:
Frecuencia:
Demanda Alta.
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:
- 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.
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 -
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.
- 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 -
- 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
- 144 -
- 145 -
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.
- 147 -
A partir de esta se crean dos mdulo: uno tipo web y el otro, tipo EJB.
- 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.
Una vez realizado esto se genera la capa de acceso a datos con las siguientes clases:
- 149 -
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:
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 -
- 151 -
- 152 -
- 153 -
- 154 -
el
siguiente
path
C:\Program
Files\glassfish-
(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 -
- 156 -
- 157 -
- 158 -
- 159 -
- 160 -
- 161 -
CAPITULO VI.
6. RESULTADOS Y DISCUSIN.
6.1.HIPTESIS.
6.1.1.
INTRODUCCIN.
- 162 -
PARMETRO
Lneas de cdigo
CONCEPTO
Cantidad de lneas de cdigo para la ejecucin de
una tarea especfica.
Reusabilidad
23
Generacin de Cdigo
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 -
Modularidad
Compatibilidad
Generacin automtica de
documentacin
Escalabilidad.
Mantenibilidad.
10
Presentacin.
- 164 -
6.1.3.
PARMETRO
Reusabilidad
CONCEPTO
Poder usar partes o componentes de un software
determinado en otro proyecto.
Generacin de Cdigo
Modularidad
Mantenibilidad.
Presentacin.
- 165 -
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
componentes.
Facilidad de
integracin.
DESCRIPCIN
Creacin de capa de
acceso a datos.
Creacin de capa de
lgica de negocio.
Lneas de cdigo.
Cdigo no utilizable.
Complejidad.
- 166 -
DESCRIPCIN
Modelo Vista
Controlador
Diseo
estructurado
Capacidad de
descomposicin
Comprensin
DESCRIPCIN
Propiedad deseable de un sistema, una red o un
proceso, que indica su habilidad para reaccionar y
adaptarse sin perder calidad
Disponibilidad de
Documentacin
Cdigo Entendible.
Adaptabilidad a nuevos
requerimientos
- 167 -
DESCRIPCIN
Se refiere al uso de plantillas de interfaz de usuario
preelaboradas, que permitan ahorrar tiempo en el desarrollo
de interfaces.
Componentes AJAX
Validaciones
realizar
validaciones
para
ejecutar
mens
6.1.4.
CRITERIOS DE EVALUACIN.
Cualitativa
Bajo
Medio
Medio
Medio
Alto
Bajo
Porcentajes
0%
25%
Alto
50%
75%
100%
- 168 -
6.1.5.
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 -
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)
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 -
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)
FACILIDAD DE INTEGRACIN.
- 172 -
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)
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 -
PROPUESTA
PESO
MXIMO
PORTABILIDAD
INDEPENDENCIA DE
COMPONENTES
FACILIDAD DE
INTEGRACIN
TOTAL
11
12
58,33%
91.67%
100%
PORCENTAJE DE
REUSABILIDAD
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)
- 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)
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 -
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 -
TRADICIONAL
PROPUESTA
Prototipo 1
Prototipo 2
50%
100%
Metodologa Tradicional
(Prototipo 1)
Metodologa Propuesta
(Prototipo 2)
1,5
1
0,5
0
Metodologa
Tradicional (Prototipo
1)
Metodologa
Propuesta (Prototipo
2)
- 177 -
6.1.5.2.2.
- 178 -
TRADICIONAL
PROPUESTA
Prototipo 1
Prototipo 2
0%
25%
INDICADOR
CRITERIO DE EVALUACIN
PORCENTAJE
Metodologa Tradicional
(Prototipo 1)
2
1
1,5
1
Metodologa Propuesta
(Prototipo 2)
0,5
0
Metodologa
Tradicional (Prototipo
1)
Metodologa
Propuesta (Prototipo
2)
LINEAS DE CDIGO.
- 179 -
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.
- 180 -
- 181 -
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)
CODIGO NO UTILIZABLE.
Excesivo Mucho
0%
25%
Poco
Muy Poco
Nada
50%
75%
100%
- 183 -
Adems genera cdigo no utilizable en la capa de negocios con un total de 15 lneas por
entidad:
- 184 -
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)
- 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:
- 186 -
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)
- 187 -
PROPUESTA
PESO
MXIMO
Lneas de cdigo.
Cdigo no utilizable.
Complejidad.
Total
11
11
20
55,00%
55,00%
100%
INDICADORES
Porcentaje de generacin de
cdigo
- 188 -
4
3,5
3
2,5
Lneas de Cdigo
1,5
1
0,5
Cdigo no utilizable
Complejidad
0
Metodologa
Tradicional (JSP y
JDBC)
Metodologa
Propuesta (JSF y EJB)
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)
- 189 -
6.1.5.2.6.
INTERPRETACIN.
PROPUESTA
Prototipo 2
4
100%
- 190 -
Metodologa Tradicional
(Prototipo 1)
Metodologa Propuesta
(Prototipo 2)
1,5
1
0,5
0
Metodologa
Tradicional (Prototipo
1)
Metodologa
Propuesta (Prototipo
2)
DISEO ESTRUCTURADO
- 191 -
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
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 -
- 193 -
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
6.1.5.3.4.
COMPRENSIN.
- 194 -
cdigo java, esto hace que la comprensin del funcionamiento sea muy difcil, como se
muestra en la figura.
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.
- 195 -
PROPUESTA
Prototipo 2
4
100%
Metodologia Tradicional
1,5
1
Metodologia Propuesta
0,5
0
Metodologia
Tradicional
Metodologia
Propuesta
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
2,5
Diseo Estructurado
2
1,5
Capacidad de
Descomposicin
Comprensin de Cdigo
1
0,5
0
Metodologa
Tradicional
Metodologa
Propuesta
MODULARIDAD
100
80
60
100%
40
56,25%
METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA
20
0
METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA
- 197 -
6.1.5.3.5.
INTERPRETACIN.
ESCALABILIDAD.
- 198 -
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
DISPONIBILIDAD DE DOCUMENTACIN.
- 199 -
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
- 200 -
6.1.5.4.3.
CDIGO ENTENDIBLE.
- 201 -
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
- 202 -
- 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
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
MANTENIBILIDAD
100
80
60
40
75%
20
75%
METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA
0
METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA
- 205 -
6.1.5.4.5.
INTERPRETACIN.
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 -
- 207 -
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
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.
- 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
- 210 -
- 211 -
Backbean equipoEstrategia.calcular
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
- 212 -
VALIDACIONES.
- 213 -
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
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 -
- 216 -
TRADICIONAL
Prototipo 1
2
50%
PROPUESTA
Prototipo 2
4
100%
- 217 -
1,5
1
Metodologia Propuesta
0,5
0
Metodologia
Tradicional
Metodologia
Propuesta
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
1
0,5
0
Metodologa
Tradicional
Metodologa Propuesta
PRESENTACION
100
80
60
93,75%
40
56,25%
METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA
20
0
METODOLOGA
TRADICIONAL
METODOLOGA
PROPUESTA
- 219 -
6.1.5.5.5.
INTERPRETACIN.
6.1.6.
6.1.6.1. HIPTESIS.
DETERMINACIN DE VARIABLES.
Operacionalizacin Conceptual.
Tabla VI.LXXII: Operacionalizacin Conceptual.
VARIABLE
Metodologa
para
construccin
de
TIPO
la
Independiente
CONCEPTO
Conjunto
de
etapas
una
formalmente estructuradas,
la
interesados parmetros de
integracin
de
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
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
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
- 223 -
Porcentaje General
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
81%
Metodologa Propuesta
60%
Metodologa
Tradicional
Metodologa Tradicional
Metodologa
Propuesta
6.1.6.2.1.
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:
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
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 -
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: para la obtencin de los datos que se muestran en la tabla, se utilizo el software
SPSS el cual es un programa estadstico informtico.
Resultados.
Valores esperados.
- 228 -
- 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 -
- 242 -
- 243 -
- 244 -
GLOSARIO.
Administrador
Aplicacin
Arquitectura
Atributo
Bean
Cliente
Concurrencia
Cookies
Diseo
Framework
Hardware
sus
componentes
electromecnicos y mecnicos.
elctricos,
electrnicos,
- 245 -
Implementacin
Ingeniera
Interfaz
Internet
Conjunto
descentralizado
de
redes
de
comunicacin
Java
Javascript
Middleware
Persistencia
- 246 -
Protocolo
Proxy
Requisitos
Necesidad
documentada
sobre
el
contenido,
forma
Servlets
Software
Threads
Web
- 247 -
BIBLIOGRAFA.
1. CORONEL, E., Desarrollando soluciones con Java y MySQL., Editorial
macro., 2009., Pp. 428.
3. ROZANSKI, U., Enterprise Java Bean 3.0 con Eclipse y JBoss., Barcelona,
Editorial Alfaomega, MARCOMBO S.A., 2009., Pp. 563.
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
- 249 -