CAPÍTULO 4. PRUEBAS Y ANÁLISIS DE FACTIBILIDAD
4.2 Planificación basada en uno de los métodos de estimación
4.2.2 Conclusiones
Considerando los resultados arrojados respecto a la factibilidad del software después del
estudio realizado en este capítulo el mismo implicará un esfuerzo total de 1904.77 horas
/hombre, para un tiempo de desarrollo de 238 días aproximadamente, se contarán con un
hombres para su realización, lo que implica un costo de $3928 para una tarifa horaria de
$1.031.
4.3 Conclusiones parciales
Se realizaron las pruebas de rendimiento en cuanto al tiempo de respuesta demostrando que
tiempo de respuesta un 83,7 %. También fueron realizadas las planificaciones basadas en el
Conclusiones
Se identificaron patrones existentes en la literatura científica relacionados con la reducción de accesos a la fuente de datos y el tiempo de respuesta al cliente, los
cuales guardan el resultado de una consulta en la memoria caché, estos son el Cache
Accessor, Demand cache y Primed cache.
Se propusieron modificaciones a estos patrones integrándolos en un patrón Strategy, brindándole la funcionalidad al desarrollador de software de elegir la estrategia a
tomar para el acceso a datos de una fuente mediante un servicio web.
Finalmente se desarrolló un ejemplo que desde un cliente Web implementado en Ajax invoca un Web Service que devuelve JSON y usa las distintas estrategias de
Recomendaciones
Agregarles comportamientos de escritura, actualización y eliminación a los patrones de acceso a datos.
Integrarle a la biblioteca de clases los patrones Cache Search Sequence y Cache Collector con el objetivo de optimizar la funcionalidad de la cache y la limpieza de
la misma cuando los datos estén obsoletos.
Validar la solución propuesta con otras existentes en la literatura científica, como memCache.
Referencias Bibliográficas
ALEXANDER, C. 1979. The Timeless Way of Building.BEHROUZ A. FOROUZAN, S. C. F. 2003. Foundations of Computer Science: From Data Manipulation to Theory of Computation.
ERL, T. 2005. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR.
FREEMAN, E. F. E. 2004. Head First Design Patterns, O'Reilly. GAMMA, E. 1997. Design Patterns.
GRADY BOOCH, J. R., IVAR JACOBSON 2005. El lenguaje unificado de modelado. IBM. 2009. Capas del modelo conceptual de soa [Online]. Available:
icomparable.blogspot.com.
JACOBSON, B. 2000. El proceso unificado de desarrollo de software.
LEONARD RICHARDSON, S. R. 2007. RESTful Web Service.
M, J. & PATRICIA 2009. Verificación y validación. Ingeniería de programación. MESTRAS, J. P. 2004. Patrones de diseño orientado a objetos.
NOCK, C. 2003. Data Access Patterns, Addison Wesley. RONCERO, Ó. 2007. SOA: Qué es realmente.
Manual del desarrollador
El siguiente manual es un ejemplo que usa nuestra propuesta de solución y que sirve de
guía a arquitectos y desarrolladores de software. A continuación se mostrará cómo se utiliza
la biblioteca de clases para acceder a datos.
Instalación del servidor Tomcat
Seleccionamos la versión del servidor según la arquitectura de del sistema operativo como
se muestra en la figura A1 y lo descomprimimos en un directorio determinado, por ejemplo
C:\TomCat\apache-tomcat-7.0.53.
Figura A1 Versiones del servidor según la arquitectura del sistema operativo
Seguidamente accedemos al directorio apache-tomcat-7.0.32/conf/tomcat-users.xml donde
crearemos un rol de administración con usuario y contraseña. Comentamos todas las líneas
del archivo y agregamos las siguientes, lo cual se ve en la figura A2 donde hemos creado
un rol nombrado tomcat con contraseña tomcat y nombre de usuario tomcat.
Una vez definido el rol pasamos a la ejecución del servidor podemos iniciar el servidor con
el comando ubicado en, apache-tomcat-7.0.32/bin/startup.sh. Abrimos el navegador web e
insertamos la siguiente url, http://localhost:8080. Si todo sale bien, no mostrara la siguiente
página Figura A3.
Figura A3 Página inicial del servidor Apache Tomcat
Configuración del servidor Apache Tomcat en NetBeans
Para realizar pruebas de aplicaciones web el NetBeans utiliza el servidor Glassfish, a
Primeramente se va a la paleta Service, dando clic derecho sobre Servers donde se muestra
la opción de añadir un servidor web Figura A4.
Figura A4 Agregando un nuevo servidor
Luego seleccionamos la instancia del servidor Apache Tomcat y damos clic en siguiente
figura A5.
Figura A5 Selección del servidor Apache Tomcat
Seguidamente insertamos la dirección donde se encuentra localizado el servidor, agregamos
Figura A6 Configuración del servidor
Creación de una aplicación web en NetBeans
Después de configurar el ambiente de desarrollo, construiremos la base de la aplicación
web, donde será añadido las clases del servicio web RESTful. A continuación creamos un
nuevo proyecto seleccionando Java Web y dentro de esta Web Application, finalmente
Figura A7 Creación de un nuevo proyecto
Figura A8 Nombre y localización del proyecto
Para finalizar especificamos el servidor anteriormente configurado, la versión de Java EE y
el nombre del contexto, damos clic en finalizar para concluir con la configuración de la
aplicación web figura A9.
Figura A9 Configuración del servidor
Creación del servicio web RESTful
Una vez creada una aplicación web pasaremos a adicionarle un servicio RESTful,
primeramente daremos clic derecho en nuevo y seleccionaremos RESTful Web Services
Figura A10 Creación de un nuevo recurso
Luego seleccionamos las especificaciones del recurso donde seleccionaremos el paquete
Figura A11 Especificación del recurso
En la figura A11 se pude ver como es marcada la opción de usar Jersey, esta biblioteca es
añadida cuando damos clic derecho en Libraries dentro del proyecto y seleccionamos
Add Library, luegoseleccionamos jersey 1.8 (JAX-RS RI) y lo añadimos figura A12.
Figura A12 Añadiendo Jersey
Una vez realizado estos pasos hemos creado un servicio web RESTful con un recurso. El
desarrollador web definirá la cantidad de recursos necesarios para darle solución su
problemática.
Integración de los paquetes CacheStrategy y DataAccess
A continuación para darle funcionalidad a nuestra biblioteca de clases con patrones de
acceso son agregados los paquetes CacheStrategy y DataAccess a la estructura del proyecto
Figura A13 Integración de CacheStrategy y DataAccess
Ejemplo
En el siguiente ejemplo un desarrollador tiene una base de datos que almacena noticias y
quiere acceder a estas con una estrategia de lectura bajo demanda. Primeramente creará un
nuevo recurso nombrado Service1Noticias, al cual se podrá acceder con la URI:
http://localhost:8080/GetSomeRest/resources/service1/noticias, la estructura de este recurso
es la siguiente:
Los atributos de la clase de la clase tienen unas instancias de CacheAccessor del paquete
CacheStrategy y DBAccessor del paquete DataAccessor, así como una variable de tipo
String que guardara la url del gestor de la base de datos, con para establecer la conexión con el gestor y cache que guardara la caché figura A14.
Figura A14 Nombre y atributos del recurso
En el constructor de la clase es construido el recurso especificando la tabla, en la url se
pone las características necesarias del gestor para poder establecer la conexión. Se establece
la conexión y se construye una instancia de DemandCache ya que la estrategia de acceso es
bajo demanda como es mostrado en la figura A15.
Figura A15 Constructor del recurso
El GET será ejecutado en el momento que el navegador intérprete la URI anteriormente mencionada. Lo principal visto aquí es el momento donde se ejecuta el comportamiento de
lectura doRead() al cual se le pasa una llave vacía ya que se quiere el retorno de todas la noticias y no una en especifica. El resultado es retornado en una lista enlazada la cual
Figura A16 Estructura del GET
Una vez interpretada la URI por el navegador se obtendrá una cadena de datos sin
formatear los cuáles mostraran el resultado de la consulta ejecutada por el recurso del
servicio web mostrándose esto en la figura A17.
Figura A17 Datos obtenidos sin formatear
El desarrollador es el encargado luego de darle un formato agradable en la aplicación
cliente, un ejemplo de este mismo recurso con un resultado formateado sería el que se
muestra en la figura A18. Donde además del recurso mostrado en el ejemplo anterior, se
crearon otros recursos mostrándose cinco en total, para precargar las categorías mostrando
Además se le agrega una opción de caché que en caso de estar marcada usara estrategias de
demanda y en el caso contrario accederá con la estrategia de lectura directa.