facultad matemática, física y computación ingeniería
Post on 15-Jul-2022
9 Views
Preview:
TRANSCRIPT
Universidad Central “Marta Abreu” de Las Villas.
Facultad Matemática, Física y Computación
Ingeniería Informática
“Patrones de diseño para acceder a
servicios web de datos”.
Autor: Eduardo Fernández Pérez
Tutor: MSc. Yoan Pacheco Cárdenas
Curso Académico: 2013-2014
“Año 56 de la Revolución”
Hago constar que el presente trabajo fue realizado en la Universidad Central “Marta Abreu”
de Las Villas como parte de la culminación de los estudios de la especialidad de Ciencia de
la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines
que estime conveniente, tanto de forma parcial como total y que además no podrá ser
presentado en eventos ni publicado sin la autorización de la Universidad.
Firma del Autor
Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos
de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un
trabajo de esta envergadura referido a la temática señalada.
Firma del tutor Firma del jefe del Laboratorio
PENSAMIENTO
DEDICATORIA
AGRADECIMIENTO
RESUMEN
Resumen
Guardar en memoria cache el resultado de una consulta realizada por un servicio web a la
fuente de datos disminuye la cantidad de accesos a base de datos y el tiempo de respuesta al
cliente. Los patrones de diseño para acceder a datos pretenden contribuir a la solución de
este problema mediante distintas estrategias independientes de cacheo. Nuestro trabajo
propone modificaciones a varios de estos patrones existentes en la literatura, para lograr la
integración de estos en un en un único patrón de comportamiento con el objetivo de crear
diferentes estrategias de cacheo de datos en un servicio web. Además se implementó una
aplicación cliente que servirá de guía a arquitectos y desarrolladores de software que
quieran acceder a datos mediante servicios Web.
ABSTRACT
Abstract
Save to cache the result of a query by a Web service data source decreases the amount of
database accesses and the response time to the customer. Design patterns for data access are
intended to contribute to solving this problem through various independent caching
strategies. Our work proposes amendments to several of these patterns in the literature, to
achieve an integration of these into a single pattern of behavior in order to create different
strategies for caching data in a web service. Also a client application that will guide
architects and software developers who want to access data using Web services is
implemented.
TABLA DE CONTENIDOS
INTRODUCCIÓN .................................................................................................................. 1
CAPÍTULO 1. PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE
DATOS Y CACHEO DE DATOS ......................................................................................... 5
1.1 Patrones de Diseño ................................................................................................... 5
1.1.1 Categorías de los Patrones de Diseño ............................................................... 8
1.1.2 Patrones enfocados a la arquitectura ................................................................. 8
1.2 SOA Arquitectura orientada a servicios ................................................................... 9
1.2.1 Etapas en la evolución de SOA ....................................................................... 10
1.2.2 Arquitectura de capas en SOA ........................................................................ 11
1.2.3 Capa de acceso a datos .................................................................................... 14
1.2.4 Servicio de acceso a datos .............................................................................. 16
1.3 Tendencias y tecnologías actuales en los Servicios Web ....................................... 17
1.3.1 Servicios Web SOAP ...................................................................................... 17
1.3.2 Servicio Web REST ........................................................................................ 19
1.3.3 Fundamentación del Entorno de Desarrollo, Lenguaje, Gestor de Base de
Datos y Tecnología utilizados ....................................................................................... 21
1.4 Cacheo de Datos ..................................................................................................... 23
1.4.1 Tipos de Cacheo de Datos .............................................................................. 23
1.4.2 Ventajas y desventajas del Cacheo ................................................................. 24
1.5 Conclusiones parciales ........................................................................................... 24
TABLA DE CONTENIDOS
CAPÍTULO 2. PATRONES DE CACHÉ ........................................................................ 26
2.1 Patrones de acceso a datos ..................................................................................... 26
2.1.1 Data Accessor ................................................................................................. 27
Aplicabilidad ............................................................................................................. 27
Estructura .................................................................................................................. 28
2.1.2 Cache Accessor ............................................................................................... 29
Aplicabilidad ............................................................................................................. 29
Estructura .................................................................................................................. 29
2.1.3 Demand Cache ................................................................................................ 31
2.1.4 Primed Cache .................................................................................................. 31
Aplicabilidad ............................................................................................................. 32
Estructura .................................................................................................................. 32
2.1.5 Cache Search Sequence .................................................................................. 33
Aplicabilidad ............................................................................................................. 33
Estructura .................................................................................................................. 34
2.1.6 Cache Collector ............................................................................................... 34
Aplicabilidad ............................................................................................................. 34
Estructura .................................................................................................................. 35
2.2 Integración de los Patrones de Acceso a Datos ...................................................... 36
TABLA DE CONTENIDOS
2.3 Requisitos a considerar .......................................................................................... 37
2.3.1 Requisitos funcionales .................................................................................... 37
2.3.2 Requisitos no funcionales ............................................................................... 38
2.4 Diagrama de casos de uso del sistema ................................................................... 38
2.4.1 Descripción de los casos de uso del sistema ................................................... 39
2.5 Conclusiones parciales ........................................................................................... 41
CAPÍTULO 3. DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN ....................... 42
3.1 Modelo de componentes ........................................................................................ 42
3.2 Diagrama de clases ................................................................................................. 43
3.3 Diagrama de Secuencias ........................................................................................ 45
3.4 Principios de Diseño .............................................................................................. 48
3.5 Diagrama de Despliegue ........................................................................................ 50
3.6 Conclusiones parciales ........................................................................................... 51
CAPÍTULO 4. PRUEBAS Y ANÁLISIS DE FACTIBILIDAD ..................................... 52
4.1 Pruebas ................................................................................................................... 52
4.2 Planificación basada en uno de los métodos de estimación ................................... 54
4.2.1 Estimación basada en casos de uso ................................................................. 54
4.2.2 Conclusiones ................................................................................................... 65
4.3 Conclusiones parciales ........................................................................................... 65
TABLA DE CONTENIDOS
Conclusiones ......................................................................................................................... 66
Recomendaciones ................................................................................................................. 67
Referencias Bibliográficas .................................................................................................... 68
Manual del desarrollador ...................................................................................................... 69
INTRODUCCIÓN 1
INTRODUCCIÓN
Con el advenimiento de dispositivos móviles y la computación en la nube las restricciones
de acceso a datos a través de la web han aumentado. Cada día son necesarios datos de
mayor calidad en menos tiempo, para lo cual actualmente se investigan procesos, técnicas,
algoritmos y operaciones encaminados a mejorar la calidad de los datos existentes. De esta
forma se obtienen beneficios en la calidad de datos como el ahorro de costes directos
evitando tener información duplicada y por lo tanto evitar el envío replicado a un mismo
cliente con lo cual también se disminuye el tiempo de respuesta.
Los servicios web juegan un papel importante en este contexto pues permiten a distintas
aplicaciones de software desarrolladas en lenguajes de programación diferentes, y
ejecutadas sobre cualquier plataforma, acceder a datos en redes de ordenadores como
Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.
Entre estos estándares de encuentra el XML (Extensible Markup Language) que es el
formato estándar para el intercambio de datos.
Disminuir la cantidad de accesos a la fuente de datos y el tiempo de respuesta enviados por
un servicio a las aplicaciones traerá beneficios al proveedor y al cliente del mismo.
Formalizar una solución a este problema mediante patrones de diseño servirá de guía a
desarrolladores y arquitectos de software pues se facilitará la reutilización de diseños y
arquitecturas de software exitosos en este contexto, por tanto nos planteamos el siguiente
problema de investigación:
¿Qué patrones diseño pueden utilizarse para acceder a servicios web de datos de modo que
se disminuya la cantidad de accesos a la fuente de datos y el tiempo de respuesta al cliente?
Objetivo general de la investigación:
INTRODUCCIÓN 2
Proponer modificaciones a los patrones de diseño existentes en la literatura para acceder a
datos, de modo que un servicio de datos disminuya la cantidad de estos solicitados a las
fuentes y el tiempo de respuesta a los clientes.
Para cumplir con el objetivo general se plantean los siguientes Objetivos específicos:
1. Identificar los patrones de diseño existentes en la literatura científica que disminuyan
la cantidad de datos solicitados a la fuente de datos y el tiempo de respuesta a los
clientes.
2. Proponer modificaciones a los patrones de diseño identificados que acceden a datos,
de modo que se consiga disminuir la cantidad de información solicitada a la fuente
de datos por un servicio web y el tiempo de respuesta a los clientes.
3. Desarrollar un ejemplo que use nuestra propuesta de solución y que sirva de guía a
arquitectos y desarrolladores de software
Para la solución del objetivo general y los específicos nos trazamos las siguientes
Preguntas de investigación:
1. ¿Qué patrones de diseño de los existentes en la literatura científica disminuyen la
cantidad de datos solicitados a la fuente de datos y el tiempo de respuesta a los
clientes?
2. ¿Qué modificaciones se pueden hacer a patrones de diseño que acceden a datos de
modo que se disminuyan los datos solicitados y la cantidad de datos enviados por
un servicio web de datos al cliente?
Como Justificación del proyecto tenemos la siguiente:
INTRODUCCIÓN 3
Disminuir la cantidad de datos solicitados y el tiempo de respuesta enviados a las
aplicaciones traerá beneficios al proveedor del servicio enviando datos de mayor calidad en
menos tiempo. De este modo los clientes consumirán menos ancho de banda, disminuyendo
así sus costos por el uso del servicio. Nuestra propuesta ayuda a cumplir con las
restricciones de memoria y procesamiento de las tecnologías móviles así como del
almacenamiento de datos en la nube. Ambas precisan enviar datos de calidad a los clientes
y con tiempo de respuesta cada vez menor.
Para darle solución al problema científico se plantea la siguiente Hipótesis de
investigación:
Integrando los patrones de diseño para el acceso a datos mediante servicios web
optimizaríamos el flujo de datos entre el cliente y el proveedor del servicio, de modo que el
tiempo de respuesta y la cantidad accesos a la fuente disminuirán.
La estructura de la tesis es la siguiente:
Capítulo I. Patrones de diseño, Servicios Web de Acceso a datos y Cacheo de Datos
Se introducirá el tema relacionado con los patrones de diseños destacando su arquitectura y
enfoques arquitectónicos. Seguidamente se hace una introducción a la arquitectura
orientada a servicios profundizando en las capas y servicios de acceso a datos. Hablaremos
de tendencias y tecnologías actuales en los servicios web, así como el cacheo de datos.
Capítulo II. Patrones de caché
Analizaremos los patrones de acceso a datos existentes en la literatura científica,
integrándolos finalmente en un solo patrón de acceso. Consideraremos los requisitos de la
integración de los patrones y estableceremos el diagrama de caso de uso del sistema.
INTRODUCCIÓN 4
Capítulo III. Descripción de la propuesta de solución
Se comenzara describiendo la propuesta de solución con el modelo de componente, luego
será mostrado el diagrama de clase. El diagrama de secuencia establecerá la función de los
principales casos de usos del sistema. Serán mencionados los principios de diseños
utilizados en la solución de la problemática y será visto el despliegue estático del sistema
mediante el diagrama de despliegue.
Capítulo IV. Pruebas y análisis de factibilidad
Se realizarán las pruebas del sistema encaminadas al tiempo de respuesta mediante
diferentes estrategias de cacheo de datos. Se hará la planificación basada en uno de los
métodos de estimación
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 5
CAPÍTULO 1. PATRONES DE DISEÑO, SERVICIOS WEB DE
ACCESO DE DATOS Y MEMORIA CACHÉ DE
DATOS
En el siguiente capítulo se realizará una caracterización de los patrones de diseño,
particularmente su estructura, las categorías de patrones, así como sus ventajas y
desventajas. Se enfocarán los patrones relacionados con los Servicios Web y SOA.
También serán vistos los tipos de servicios web en una arquitectura SOA, sus principales
estándares y las características de los servicios de acceso a datos. Serán mostradas las
tendencias y tecnologías en los servicios web actuales enfatizando en SOAP y REST, se
fundamentara el entorno de desarrollo, lenguaje, gestor de base de datos y tecnologías
utilizadas. Por último se tratará la memoria caché, sus tipos, ventajas y desventajas.
1.1 Patrones de Diseño
Según (Alexander, 1979) los patrones no son principios abstractos que requieran su
redescubrimiento para obtener una aplicación satisfactoria, ni son específicos a una
situación particular o cultural; son algo intermedio. Un patrón define una posible solución
correcta para un problema de diseño dentro de un contexto dado, describiendo las
cualidades invariantes de todas las soluciones. "Cada patrón describe un problema que
ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo
que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a
pensarla otra vez."
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 6
Uno de los principales componentes de los patrones es su estructuración las cuales están
estandarizadas de forma que se expresen uniformemente y puedan constituir efectivamente
un medio de comunicación uniforme entre diseñadores. Las más utilizadas dentro de estos
estándares es la de (Gamma, 1997) la cual consta de los siguientes apartados:
Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la
comunidad (normalmente se expresan en inglés para evitar confusiones).
Clasificación del patrón: está dada por su categoría (creacional, estructural,
comportamiento…).
Intención: ¿Qué problema pretende resolver el patrón?
También conocido como: Otros nombres de uso común para el patrón, aquí saldría
el alias del patrón o su españolización en caso de llevarlo al español lo cual no es
recomendable a la hora de nombrarlo.
Motivación: Escenario de ejemplo para la aplicación del patrón.
Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
Estructura: Diagramas de clases oportunos para describir las clases que intervienen
en el patrón.
Participantes: Enumeración y descripción de las entidades abstractas (y sus roles)
que participan en el patrón.
Colaboraciones: Explicación de las interrelaciones que se dan entre los
participantes.
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 7
Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la
aplicación del patrón.
Implementación: Técnicas o comentarios oportunos de cara a la implementación
del patrón.
Código de ejemplo: Código fuente ejemplo de implementación del patrón.
Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
Patrones relacionados: Referencias cruzadas con otros patrones
Los patrones de diseño pretenden:
Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y
solucionados anteriormente.
Formalizar un vocabulario común entre diseñadores.
Estandarizar el modo en que se realiza el diseño.
Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando
conocimiento ya existente.
Asimismo, no pretenden:
Imponer ciertas alternativas de diseño frente a otras.
Eliminar la creatividad inherente al proceso de diseño.
Los patrones están organizados en categorías las cuales favorecen la agrupación de patrones
con características comunes.
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 8
1.1.1 Categorías de los Patrones de Diseño
En la Tabla 1 se muestran las categorías básicas de los Patrones de diseño. Existen tres
grupos, estos son los creacionales, estructurales y de comportamiento (Freeman, 2004).
Tabla 1 Categorías de los Patrones de Diseño.
Creacionales Estructurales Comportamiento
Abstract Factory Adapter Chain of Responsability
Builder Bridge Command
Factory Method Composite Interpreter
Prototype Decorator Iterator
Singleton Facade Mediator
Flyweigth Mementor
Proxy Observer
State
Strategy
Template Method
Visitor
Además de esta tres categorías existen otras, como nuestro trabajo se enfoca en patrones
para el acceso a datos en una arquitectura orientada a servicios (SOA) a continuación
mostramos los patrones arquitectónicos.
.
1.1.2 Patrones enfocados a la arquitectura
Existen tres niveles de patrones fundamentales entre los cuales se encuentran (Mestras,
2004):
Bajo nivel: Patrones elementales específicos de un lenguaje de programación.
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 9
Nivel Medio: Patrones de diseño.
Alto Nivel: Los patrones de arquitectura son formas predefinidas de resolver
problemas de arquitectura. La arquitectura de un sistema de software casi nunca se
limita a un solo patrón o estilo.
En la Tabla 2 se muestran los principales estilos de patrones arquitectónicos.
Tabla 2 Estilos de patrones arquitectónicos. Note SOA como un estilo de comunicación.
Categorías Estilos
Comunicación SOA (Servicie Oriented Arquitecture)
Bus de Mensajes
Distribución Cliente/Servidor
3-Capas
N-Capas
Estructuras Basado en Componentes
Orientado a Objetos
Arquitectura de Capas
Otras Dirigido por eventos
Modelo-Vista-Controlador
El estilo arquitectónico a seguir será SOA el cual se trata en el siguiente epígrafe.
1.2 SOA Arquitectura orientada a servicios
SOA es un tipo de arquitectura tecnológica que cumple con los principios de la orientación
a servicios. Cuando se implementa a través de la plataforma tecnológica de servicios web,
SOA brinda el potencial para soportar y proveer estos principios a lo largo de los procesos
de negocio y los dominios de automatización de una empresa(Erl, 2005).
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 10
1.2.1 Etapas en la evolución de SOA
Una vez que se decide implementar SOA, es muy típico pasar por todas estas fases en el
camino de evolución hacia la madurez SOA. (Roncero, 2007).
1) Creación de los Servicios dentro de la organización. Estos Servicios incluyen
funcionalidades reutilizables, accesibles de manera estándar y que pueden formar
parte de procesos de negocio.
2) Orquestación de los Servicios previamente creados, mediante la definición de
Procesos que utilizarán dichos servicios disponibles en la organización.
3) Construcción de nuevos servicios según sean necesarios para la orquestación de
los nuevos Procesos y reutilización de los Servicios ya existentes en distintos
Procesos.
4) Enterprise Service Bus (ESB). Una vez que el número de procesos orquestados es
importante, la organización descubre que es difícil controlarlos y es difícil escalar
procesos existentes, y en ese momento es cuando las organizaciones realmente
descubren que es muy complicado gestionar y escalar una Arquitectura SOA si se
carece de un ESB.
5) Monitorización de los Procesos en SOA. Una vez se definen los primeros
procesos SOA, surge la necesidad de tener visibilidad en quién está utilizando
estos servicios, qué tiempos de respuesta se están ofreciendo, etc. Este punto será
tenido en cuenta en distintos momentos en el camino hacia la madurez SOA.
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 11
SOA es también visto como una arquitectura basada en n-capas a continuación
mostraremos la referenciada por IBM, pero estas capas varían de acuerdo a la necesidad del
problema a resolver.
1.2.2 Arquitectura de capas en SOA
La arquitectura SOA que propone IBM es lo suficientemente sólida para convertirse en un
auténtico estándar. Tanto, que muchas organizaciones definen su propia visión de SOA
indicando en qué se parece o en qué se diferencia de la que propone IBM Figura 1.2 (IBM,
2009).
Figura 1.2 La arquitectura de referencia IBM define 9 capas.
1. Sistemas operacionales (Operational Layer): Es el inventario de todas las
aplicaciones existentes y que proporcionan la lógica de negocio o núcleo de la
empresa. Aplicaciones hechas a medida, aplicaciones comerciales, sistemas
legacy, bases de datos, etc.
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 12
2. Capa de componentes de servicio (Service Components Layer): Es la
implementación de un servicio y según IBM debe cumplir con SCA (Service
Componente Architecture) y con SDO (Service Data Objects).
3. Capa de servicios (Services Layer): Esta capa contienen los servicios de
negocio. Están implementados con una tecnología estándar independiente de la
plataforma. Tiene un descriptor WSDL que igualmente es estándar y define la
interfaz del servicio (con qué parámetros se invoca y cuáles devuelve). Se pueden
crear servicios compuestos, combinando otros servicios más simples.
4. Capa de procesos de negocio (Business Process Layer): En esta capa se ubican
los servicios compuestos, formados por la combinación de servicios más
sencillos. También se encuentran los procesos BPM (coreografías de servicios)
que modelan casos de uso específicos y procesos de negocio de la organización.
Cada proceso es un flujo de tareas automáticas o humanas (tienen que ser
realizados por una persona).
5. Capa de consumidores (Consumers Layer): Aquí se encuentran todos los
posibles consumidores de los servicios. Debido a las características de múltiples
canales de los propios servicios y dado la cantidad de dispositivos existentes
actualmente para acceder a los mismos, los consumidores pueden ser de tipo
heterogéneo: aplicaciones de oficina, aplicaciones con interfaz web de internet,
usuarios finales con sus Smartphone, etc. Es importante recalcar que los servicios
son “agnósticos” respecto a la forma de su consumo o a la presentación que se le
haría al usuario final. Todos los servicios están dados de alta en el registro de
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 13
servicios a fin de que los consumidores puedan localizar el servicio que necesiten
y sean independientes de la localización física del servicio.
6. Capa de integración (Integration Layer): Esta es una capa de infraestructura
que proporciona las capacidades de mediación, enrutado y transporte de la
petición del cliente hasta el servicio concreto. Estas capacidades se implementan
mediante un Enterprise Service Bus (ESB).
7. Capa de calidad del servicio (QoS Layer): Esta capa proporciona la capacidad
de realizar los requerimientos no funcionales necesarios, por ejemplo,
monitorización de los servicios, trazas, alertas de no cumplimiento del nivel de
servicio acordado (SLA), etc., asegurando que se cumplen los niveles mínimos de
escalabilidad, disponibilidad y seguridad necesarios. Desde el punto de vista de
negocio, proporciona la funcionalidad de Business Actitivity Monitor (BAM), es
decir, el estado en tiempo real del proceso desde el punto de vista de negocio.
Esto se hace mediante el desarrollo dentro del proceso de KPI (Key Performance
Monitor) que son recogidos por el BAM y mostrados al usuario.
8. Capa de información (Information Architecture Layer): En esta capa se
recolecta información susceptible de forma datamarts y data wharehouses para su
posterior análisis.
9. Capa de Gobierno (Governance Layer): Cubre todos los aspectos relativos al
ciclo de vida de los servicios. Incluidos los aspectos de seguridad, capacidad y
rendimiento.
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 14
Visto en esta ejemplificación de capas para una arquitectura SOA la capa de acceso a datos
es la relacionada con la Capa de componentes de servicio, aunque utiliza las fuentes de
datos de la capa operacional. A continuación se enfatizara sobre esta capa de forma general
cuando se utilizada en una aplicación tradicional.
1.2.3 Capa de acceso a datos
En la actualidad cuando se habla de acceder a datos existen interfaces que nos permiten el
acceso a las fuentes de datos, las principales dedicadas a esta función son:
ODBC: (Open Database Connectivity) hace posible accede a cualquier dato desde
cualquier aplicación sin importar que gestor de base de datos se use.
JDBC: (Java Database Connectivity) permite la ejecución de operaciones sobre
base de datos con el lenguaje de programación Java.
ADO.NET: Conjunto de componentes del software usado para acceder a datos y
servicios de datos.
OLE DB: (Object Linking and Embedding for Databases) para tener acceso a
diferentes fuentes de información de manera uniforme.
En una aplicación tradicional el mecanismo de acceso a datos con las interfaces
mencionadas serian como se muestra en la siguiente Figura 1.3
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 15
Figura 1.3 Arquitectura de acceso a datos.
Esta arquitectura no es aplicable para un ambiente SOA por las siguientes razones:
Su rendimiento de escalabilidad es por debajo del nivel exigido.
o Los servicios son reutilizables diseñados inicialmente para 50 usuarios, sin
embargo en un ambiente SOA es posible llegar hasta unos 500 usuarios.
Retrasos de despliegue.
o Un despliegue pequeño se convierte en un gran problema cuando el número
de servicios aumenta.
Para una mejor práctica de acceso a datos en una arquitectura SOA se recomienda
desacoplar la lógica de la entidad así como de la fuente de datos, optimizar el uso de los
ambientes heterogéneos, abordar los problemas de rendimientos de acceso a datos
persistentes y dinamizar el acceso de datos con técnicas de integración de datos. Por estas
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 16
razones cuando se quiere trabajar con una arquitectura orientada a servicios se recomienda
desarrollar un servicio de acceso a datos.
1.2.4 Servicio de acceso a datos
En un ambiente SOA la capa de acceso a datos pasara a verse como un servicio de datos el
cual accede a los mismos como un servicio web Figura 1.4
Figura 1.4 De la capa de acceso a dato a servicios de acceso a datos
De esta manera se logran servicios de acceso a datos mejores, escalables, fáciles de
desplegar y reutilizables. Una de las razanos de asumir SOA es la de compartir servicios
frente a un conjunto de aplicaciones y acceder a los datos de una manera optimizada la cual
no sería posible utilizando la capa de acceso a datos.
Service Data Objects es una tecnología que permite que los datos heterogéneos sean
accedidos de una manera uniforme. La especificación de esta fue desarrollada en el año
2004 y aprobada por la comunidad Java con JSR 235. La versión 2.0 de la especificación
fue presentada en noviembre del 2005 como parte de la arquitectura de componentes de
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 17
servicios. Service Data Objects denotan estructuras de datos que facilitan la comunicación
entre gradas estructurales y entidades proveedoras de servicios. Requieren el uso de una
estructura de árbol con un nodo de raíz y suministran mecanismos trasversales de amplitud
y profundidad que permite que clientes o programas naveguen por determinados elementos.
La forma más habitual de implementar esta arquitectura es mediante Servicios Web, una
tecnología basada en estándares e independiente de la plataforma, con la que SOA puede
descomponer aplicaciones monolíticas en un conjunto de servicios e implementar esta
funcionalidad en forma modular.
1.3 Tendencias y tecnologías actuales en los Servicios Web
Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su
complejidad a la hora de dar una adecuada definición que englobe todo lo que son e
implican. Una posible sería hablar de ellos como un conjunto de aplicaciones o de
tecnologías con capacidad para interactuar en la Web. Estas aplicaciones o tecnologías
intercambian datos entre sí con el objetivo de ofrecer servicios. Los proveedores ofrecen
sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a
estos procedimientos a través de la Web. A continuación entraremos en detalle de algunas
tendencias y tecnologías referentes a los Servicios Web.
1.3.1 Servicios Web SOAP
SOAP por sus siglas en inglés (Simple Object Access Protocol), es un protocolo estándar
que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de
intercambio de datos XML los cuales tienen la siguiente estructura Figura 1.5(W3C, 2007).
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 18
Figura 1.5 Estructura de datos XML en SOAP
La estructura de datos XML para este protocolo se compone de las siguientes partes(Erl,
2005):
Envelope: elemento raíz, contiene declaraciones de namespaces y atributos
adicionales.
Header: contiene atributos relacionados con el procesamiento por el servidor o los
intermediarios.
Body: contiene la carga útil "payload" del mensaje, para ser procesada por el
servidor.
El protocolo SOAP tiene tres características principales:
Extensibilidad (seguridad con extensiones aplicadas en el desarrollo).
Neutralidad (SOAP puede ser utilizado sobre cualquier protocolo de transporte
como HTTP, SMTP, TCP o JMS).
Independencia (SOAP permite cualquier modelo de programación).
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 19
Los procedimientos SOAP pueden ser utilizados de la siguiente forma. Un mensaje SOAP
podría ser enviado a un sitio Web que tiene habilitado un servicio, para realizar la búsqueda
de algún precio en una base de datos, indicando los parámetros necesitados en la consulta.
El sitio podría retornar un documento formateado en XML según muestra la Figura 1.5,
ejemplo, precios, localización, características. Teniendo los datos de respuesta en un
formato estandarizado, este puede ser integrado directamente en un sitio Web o aplicación
externa.
La arquitectura SOAP consiste de muchas capas de especificación: para el formato del
mensaje, subyacentes enlaces de protocolo de transporte, modelo de procesamiento de
mensajes, y extensibilidad del protocolo. Por estas razones es recomendable utilizarlo en
servicios complejos y de gran envergadura.
Para la implementación de servicio más simples se recomienda usar REST el cual será
tratado en el siguiente epígrafe.
1.3.2 Servicio Web REST
REST por sus siglas en inglés (Representacional State Transfer) es una técnica de
arquitectura de software para sistemas hipermedia distribuidos como la World Wide Web.
Esta técnica se usa para cualquier interfaz web simple que utilice XML y HTTP sin las
abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes
como el protocolo de servicio web SOAP (Leonard Richardson, 2007).
Con REST la web ha disfrutado de una escalabilidad con resultado de una serie de diseños
claves como:
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 20
Protocolo cliente/servidor sin estado, cada mensaje HTTP contiene toda la
información necesaria para comprender la petición. Como resultado, ni el cliente ni
el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes.
Operaciones bien definidas aplicadas a todos los recursos de información, HTTP
en sí define un conjunto pequeño de operaciones.
o POST: Actualiza un recurso sobre el servidor. El recurso es contenido en el
cuerpo del pedido de POST. Post es análogo a una declaración de
actualización de SQL.
o GET: Recupera un recurso del servidor. El recurso es especificado con una
URL para delinear el pedido de los parámetros de solicitud. GET es análogo
a una declaración seleccionar de SQL.
o PUT: Añade un recurso sobre el servidor. El recurso es contenido en el
cuerpo del pedido de POST. El lanzamiento es análogo a un declaración de
Insertar de SQL
o DELETE: Elimina un recurso sobre el servidor. El recurso es especificado
en el URL solamente. El Eliminar es análogo a una declaración de eliminar
en SQL.
Sintaxis universal para identificar los recursos. En un sistema REST, cada recurso
es direccional únicamente a través de su URI.
Uso de hipermedias, tanto para la información de la aplicación como para las
transiciones de estado de la aplicación, la representación de este estado en un
sistema REST son típicamente HTML o XML. Como resultado de esto, es posible
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 21
navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin
requerir el uso de registros u otra infraestructura adicional.
1.3.3 Fundamentación del Entorno de Desarrollo, Lenguaje, Gestor de Base de
Datos y Tecnología utilizados
En el desarrollo de la presente investigación se utilizó el siguiente entorno de desarrollo:
NetBeans IDE 7.1.2: por ser un entorno de desarrollo integrado libre gratuito sin
restricciones de uso, este es una herramienta para escribir, depurar, y ejecutar
programas. Además soporta todo tipo de aplicaciones Java como J2SE, web
services, EJB y aplicaciones móviles.
El lenguaje utilizado es Java ya que es de propósito general, concurrente, orientado a
objetos y basado en clases el cual fue diseñado específicamente para tener tan pocas
dependencias de implementación como fuese posible.
Las fuentes de datos se gestionan con el Gestor de Base de Datos PostgreSQL aunque el
desarrollador puede utilizar cualquier otro para gestionar las fuentes de datos. PostgreSQL
este es relacional orientado a objetos, libre y de código abierto. Una de las principales
características de este gestor es su alta concurrencia, esta nos permite que mientras un
proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos.
Cada usuario obtiene una visión consistente de lo último a lo que se ha actualizado. Esto
nos sería de gran utilidad en un servicio ya que este pudiera estar disponible de manera
permanente sin interrupciones.
Además se utilizaron las siguientes tecnologías para desarrollar un servicio web de acceso a
datos, las cuales se escriben a continuación:
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 22
Apache Tomcat: contenedor de Java Servlet es usado como servidor web
autónomo en entornos con alto nivel de tráfico y alta disponibilidad. Dado que
Tomcat fue escrito en Java, funciona en cualquier sistema operativo que disponga
de la máquina virtual de Java por esta razón es el más indicado debido a que el
lenguaje a tratar es Java.
Java Runtime Environment: es un conjunto de utilidades que permite la ejecución
de programas Java, este es accedido por el servidor web de Java Tomcat en el
momento que es desplegado un servicio web.
Servicio Web tipo REST: será el utilizado para la realización de este proyecto ya
que cumple con los estándares necesarios para la solución de una aplicación sencilla
como anteriormente se había comentado.
Jersey: es un framework utilizado para implementar servicios web de código
abierto, este suministra un juego de anotaciones que son usadas para definir un
servicio web. Un ejemplo de estas anotaciones son @Patch, @Context, @GET,
@Produces entre otras.
JSON: es un formato ligero para el intercambio de datos, es un subconjunto de la
notación literal de objetos de JavaScript que no requiere el uso de XML. Además
representa mejor la estructura de los datos y requiere menos codificación y
procesamiento
Para hacer el tiempo medio de acceso a datos menor, cuando se accede por primera vez a
una fuente de datos se hace una copia en el caché, de esta forma los accesos siguientes se
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 23
realizan a dicha copia. En esto consiste el cacheo de datos lo cuál será tratado a
continuación.
1.4 Cacheo de Datos
La caché es un sistema especial de almacenamiento de alta velocidad. Puede ser tanto un
área reservada de la memoria principal como un dispositivo de almacenamiento de alta
velocidad independiente.
1.4.1 Tipos de Cacheo de Datos
Hay dos tipos de caché frecuentemente usados en las computadoras personales(Behrouz A.
Forouzan, 2003):
Memoria caché: llamada también a veces almacenamiento caché o RAM caché, es
una parte de memoria RAM estática de alta velocidad (SRMA) más rápida que la
RAM dinámica (DRAM) usada como memoria principal. La memoria caché es
efectiva dado que los programas acceden una y otra vez a los mismos datos o
instrucciones. Guardando esta información en SRAM, la computadora evita acceder
a la lenta DRAM. Cuando se encuentra un dato en el caché, se dice que se ha
producido un acierto, siendo un caché juzgado por su tasa de aciertos (hit rate). Los
sistemas de memoria caché usan una tecnología conocida por caché inteligente en la
cual el sistema puede reconocer cierto tipo de datos usados frecuentemente. Las
estrategias para determinar qué información debe de ser puesta en el caché
constituyen uno de los problemas más interesantes en la ciencia de las
computadoras.
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 24
Caché de disco: trabaja sobre los mismos principios que la memoria caché, pero en
lugar de usar SRAM de alta velocidad, usa la convencional memoria principal. Los
datos más recientes del disco duro a los que se ha accedido (así como los sectores
adyacentes) se almacenan en un buffer de memoria. Cuando el programa necesita
acceder a datos del disco, lo primero que comprueba es el caché del disco para ver
si los datos ya están ahí. El caché de disco puede mejorar drásticamente el
rendimiento de las aplicaciones, dado que acceder a un byte de datos en RAM
puede ser miles de veces más rápido que acceder a un byte del disco duro.
1.4.2 Ventajas y desventajas del Cacheo
Debemos considerar como nuestra aplicación interactuará con la caché, las caché en un
principio suelen estar vacías. En algún momento el sistema accederá a la fuente de datos
para llenarlas lo cual varía según la estrategia determinada. En un principio la caché puede
ser una gran ventaja cuando nos enfrentamos a constantes consultas de datos ya que el
tiempo de respuesta disminuye considerablemente en los aciertos, pero el mal uso de la
cache sería un problema aun mayor que el de su inexistencia, ya que una caché mal poblada
sobrecargada o dejaría de ser útil. La caché debe ser poblada solo con los datos necesarios,
por un lado solo bastaría un identificador para acceder a un objeto de una fuente de dato. Si
llenáramos la cache con datos innecesarios la estaríamos sobrecargando lo cual sería un
sobrepeso en la aplicación que afectaría considerablemente su rendimiento(Nock, 2003).
1.5 Conclusiones parciales
En el presente capitulo se realizó un estudio de los patrones de diseños, donde se vio su
estructuración y categorización de acuerdo a sus propósitos. Se enfocaron los patrones de
CAPÍTULO 1.” PATRONES DE DISEÑO, SERVICIOS WEB DE ACCESO DE DATOS Y
MEMORIA CACHÉ DE DATOS” 25
diseños a la arquitectura donde se destacó SOA como una arquitectura que cumple con los
principios de la orientación a servicios. Fueron abordadas las capas de acceso a datos y
como en SOA estas pasarían a verse como un servicio de acceso a datos. Se analizaron las
distintas tecnologías y tendencias actuales en los servicios web destacándose REST como
la más óptima para la solución de nuestro problema. Finalmente se trató el tema
relacionado con la caché de datos, donde se vio la importancia de la memoria caché y la
desventaja que traería su mal uso.
CAPÍTULO 2.” PATRONES DE CACHÉ” 26
CAPÍTULO 2. PATRONES DE CACHÉ
En el siguiente capítulo se dará una introducción a los patrones de acceso a datos, haciendo
hincapié en los relacionados con la memoria caché. Algunos de estos serán propuestos a
una integración mediante el patrón Strategy con el objetivo de integrarlos en un solo patrón.
Serán propuestos los requisitos funcionales y no funcionales del sistema siendo útiles estos
para la creación de los casos de usos del sistema. De esta forma quedaría detallada la
estructura y funcionalidad de una biblioteca para acceder a datos mediante patrones de
diseños.
2.1 Patrones de acceso a datos
Los desarrolladores de software de las empresas enfrentan los mismos problemas de acceso
de datos sin considerar su dominio en la aplicación. Éstos son algunos ejemplos de los
problemas comunes que surgen cuando se quieren diseñar componentes de acceso de datos
(Nock, 2003):
Las aplicaciones tienen que funcionar en productos de base de datos múltiples.
Las interfaces de usuarios tienen que esconder semántica de la base de datos.
La inicialización de recurso de la base de datos es lento.
Los detalles de acceso de datos hacen que la aplicación sea difícil de desarrollar y
mantener.
Las aplicaciones tienen que almacenar los datos a los que acceden frecuentemente.
Múltiples usuarios tienen que acceder a los mismos datos simultáneamente.
CAPÍTULO 2.” PATRONES DE CACHÉ” 27
Hay soluciones comunes para estos problemas. Algunas de estas soluciones son instintivas
y han sido descubiertas por separado por miles de desarrolladores. Los otros son más
obscuros, y han sido solucionados solamente en accesos de datos más robustos.
Los patrones de acceso de datos describen las estrategias genéricas para solucionar
problemas de diseño comunes como éstos. A continuación serán mostrados una serie de
patrones de acceso a datos cumpliendo con en el criterio planteado en los objetivos
específicos que son disminuir la cantidad de datos enviados y el tiempo de respuesta en el
acceso a los datos:
DataAccessor
CacheAccessor
DemandCache
PrimedCache
CacheSearchSequence
CacheCollector
2.1.1 Data Accessor
Encapsula los detalles de acceso de datos físicos en un solo componente, sacando a la luz
solamente las operaciones lógicas. La clave de aplicación, mantiene conocimientos sobre el
modelo de datos subyacente.
Aplicabilidad
Este patrón es necesario utilizarlo cuando:
CAPÍTULO 2.” PATRONES DE CACHÉ” 28
Se quiere ocultar el modelo de datos físico y la complejidad de acceso de datos de la
lógica de aplicación. Hace guardar la lógica de la aplicación más limpia y con
mayor calidad los procesos del modelo.
Encapsula todo el modelo de datos y los detalles de acceso de datos, se interesa solo
en un concepto de dominio dentro de un componente. Agrupa todos los accesos
para una tabla o juego de tablas relacionadas así se hace más fácil pronosticar el
efecto.
Oculta contradicciones del modelo de datos u oscuros códigos de la aplicación.
Algunos modelos de datos de legado no gravan semántica. Encapsula estos detalles
dentro de un componente impidiéndole de contaminar el código de la aplicación.
Estructura
La interfaz de DataAccessor define el concepto abstracto de acceso de datos en relación con
las operaciones lógicas que el código de la aplicación usa. Se define estas operaciones de
ser suficientemente extensivo con el propósito de que las aplicaciones pueden hacer el
trabajo útil sin forzar a aplicaciones a usar conceptos anormales o modos indirectos. Se
puede adaptar para que la semántica de la operación lógica guarde el código de aplicación
lo más sencillo posible. Hay que tener cuidado de no sacar a la luz cualquier semántica
física en estas operaciones lógicas. Permite que el código de la aplicación dependa de
físicos expuestos, haciéndolo difícil de cambiar después. No se necesita definir el juego
entero de las operaciones lógicas como una interfaz. Es común separar pregunta lógica,
actualización, resultado fijó, y las operaciones de transacción en interfaces múltiples como
se muestra en la Figura 2.1.
CAPÍTULO 2.” PATRONES DE CACHÉ” 29
Figura 2.1 DataAccessor
2.1.2 Cache Accessor
Aplicabilidad
Es necesario la utilización de este patrón cuando:
La aplicación tienen que leer un juego específico de los datos muchas veces y
acceder a la base de datos física repetidamente degrada el rendimiento.
Los datos almacenados cambian muy poco. Las actualizaciones frecuentes requieren
la interacción de base de datos física adicional.
Estructura
La clase de CacheAccessor define el punto de entrada para las operaciones de acceso de
datos del cliente mientras Cache pone en funcionamiento el mecanismo de almacenamiento
del caché verdadero, sus operaciones consultan los datos almacenados. Nótese como
CacheAccessor delega las operaciones de base de datos a un componente de DataAccessor
como se ve en la Figura 2.2.
CAPÍTULO 2.” PATRONES DE CACHÉ” 30
Figura 2.2 CacheAccessor
En el diagrama de secuencia Figura 2.3 se muestra un cliente que hace público la operación
de escritura a un CacheAccessor. Además de escribir a la base de datos física, el
CacheAccessor también debe asegurar que Cache refleje los datos cambiados.
Figura 2.3 Diagrama de secuencia de CacheAccessor
CAPÍTULO 2.” PATRONES DE CACHÉ” 31
2.1.3 Demand Cache
Este patrón es similar al CacheAccessor su diferencia se muestra en el diagrama de
secuencia Figura 2.4. Cuando un cliente solicita una información determinada este accede a
la memoria caché en busca de estos datos. Si los datos son encontrados son devueltos al
cliente, de lo contrario lo busca en la memoria física, los gurda en memoria caché y se los
retorna al cliente. La próxima vez que un cliente solicite los mismos datos su acceso será
más rápido ya que los datos buscados se encuentran guardados en memoria caché.
Figura 2.4 diagrama de secuencia de DemandCache
2.1.4 Primed Cache
Precarga la caché explícitamente con un juego pronosticado de los datos. Un caché
precargada es útil para los datos que son leídos frecuentemente y de manera previsible.
CAPÍTULO 2.” PATRONES DE CACHÉ” 32
Aplicabilidad
En ocasiones poblar la caché con grandes cantidades de datos no es viable porque requiere
uno importante monto de almacenamiento principal lo cual disminuye la velocidad de
inicialización del sistema. Poblar la caché con todos los datos no es necesario porque la
mayoría de los datos son necesitados en cualquier momento. Es posible pronosticar un
subconjunto pequeño y relevante de los datos para preparar en previsión de los clientes en
pedidos futuros. Este subconjunto debe ser usado eficientemente en el almacenamiento de
la caché.
Estructura
Su estructura es similar a CacheAccessor la clase CacheAccessor define el punto de entrada
para las operaciones de acceso de datos de los clientes. El Cache pone en funcionamiento el
mecanismo de almacenamiento de caché y DataAccessor es responsable de hacer público
las operaciones de la base de datos física. La clase Key es fundamental para poder realizar
el acceso a los datos físicos ya que esta contiene la o las identificaciones necesarias para
hacer el filtrado de las búsquedas, estas establecen la relación de la columna con elemento,
KeyFactory es una interfaz para construir estos identificadores, como se muestra en la
Figura 2.5.
CAPÍTULO 2.” PATRONES DE CACHÉ” 33
Figura 2.5 PrimedCache
2.1.5 Cache Search Sequence
Inserta anotaciones en la caché para optimizar el número de las operaciones que requieren
futuras búsquedas.
Aplicabilidad
Una operación de lectura lógica requiere una secuencia de operaciones de lectura de caché
múltiples, reflejando una relación jerárquica o una búsqueda gradual que empieza con los
criterios específicos. Las secuencias de buscar que requieren caché múltiple leerá las
operaciones optimizado al grado de reducir el número de operaciones de caché, esto
perceptiblemente mejora el rendimiento del sistema.
CAPÍTULO 2.” PATRONES DE CACHÉ” 34
Estructura
Este patrón es similar a CacheAccessor la diferencia radica en la adición de la clase de
CacheSearchSequence que sostiene el estado de una secuencia de caché asociada a las
operaciones leídas, ver Figura 2.6.
Figura 2.6 CacheSearchSequence
2.1.6 Cache Collector
Se deshace de anotaciones cuya presencia en cache atenten contra el rendimiento.
Aplicabilidad
El tamaño en la caché aumenta constantemente hasta que consume una cantidad importante
del almacenamiento en memoria. El impacto de usar demasiado almacenamiento para caché
es que puede dificultar el rendimiento de sistema. Con este patrón la aplicación elimina los
datos en la cache cuando su presencia deja de ser eficaz y hace sitio para los datos más
relevantes.
CAPÍTULO 2.” PATRONES DE CACHÉ” 35
Estructura
CacheCollector, CacheEntry y CacheEntryFactory son interfaces que definen los varios
conceptos abstractos para las estrategias de colección de caché sin determinar los
algoritmos específicos o las reglas y permiten aislar la lógica de colección dentro de su
propio componente, ver Figura 2.7.
Figura 2.7 CacheCollector
Una vez mostrados estos patrones propuestos nótese que los mismos guardan una relación
con CacheAccessor. En el siguiente epígrafe se realizara un análisis teniendo en cuenta las
clases generales y específicas de todos los patrones para llegar a integrarlos en un solo
patrón compuesto.
CAPÍTULO 2.” PATRONES DE CACHÉ” 36
2.2 Integración de los Patrones de Acceso a Datos
Se integraron los patrones Data Accessor, Cache Accessor, Demand Cache y Primed
Cache en un patrón compuesto basado en el patrón strategy. Los patrones Cache Search
Sequence y Cache Collector no fueron integrados a esta versión de la solución, pero se
encuentran dentro de los objetivos de futuras versiones.
El patrón compuesto es capaz de leer datos a demanda, precargar la caché, realizar lectura
mixta de datos y realizar lectura directa, es decir leer datos a demanda y precargar la caché.
En la figura 2.8 se observan las clases principales, las cuales son DemandCache, encargada
de leer datos a demanda, PrimedCache para la precarga de datos, DemandPrimedCache que
realiza la lectura mixta y NoCacheReader para leer directamente de la fuente de datos.
Estas clases heredan de la clase base CacheAccessor, que contiene referencias a las
interfaces IPrime e IReader. IPrime es implementada por las clases Primed y NoPrime.
Ambas clases sobrescriben el método prime() que en el caso de Primed precarga la caché y
en NoPrime no lo hace. Primed y NoPrime son dos estrategias de precarga de caché. La
interfaz IReader es implementada por las clases CacheReader, Demand y DirectReading.
Ellas sobrescriben el método read() que en el caso de CacheReader realiza una lectura
directa de caché. En la clase Demand la lectura de datos se realiza bajo demanda, es decir,
primero se intenta leer de la cache, si la información no es encontrada ahí se intentará leer
de la base de datos, por ultimo DirectReading leerá directamente de la base de datos de
manera tradicional. Las clases CacheReader, Demand y DirectReading representan tres
estrategias de lectura de la caché.
CAPÍTULO 2.” PATRONES DE CACHÉ” 37
Figura 2.8 Clases principales del patrón compuesto
2.3 Requisitos a considerar
En el proceso de diseño del sistema son planteados los requisitos funcionales y no
funcionales con que debería funcionar dicho sistema. Una vez definido los requisitos
funcionales se podrían definir los casos de uso del mismo.
2.3.1 Requisitos funcionales
Estos requisitos nos indican las responsabilidades del sistema de una forma clara, son
aquellos que especifican una acción que debe ser capaz de realizar el sistema, sin
considerar restricciones físicas; requisito que especifica comportamiento de entrada/salida
de un sistema (Jacobson, 2000). A partir del análisis de la funcionalidad del sistema se
detectaron los siguientes requisitos funcionales:
RF 1 Lectura bajo demanda
RF 2 Lectura precargada
RF 3 Lectura bajo demanda y precargada
RF 4 Lectura directa
CAPÍTULO 2.” PATRONES DE CACHÉ” 38
2.3.2 Requisitos no funcionales
Los requisitos no funcionales son aquellos que especifican propiedades del sistema, como
restricciones del entorno o de implementación, rendimiento, dependencias de la plataforma,
mantención, extensibilidad o fiabilidad. Estos especifican restricciones físicas sobre un
requisito funcional. En este trabajo se tienen los siguientes:
Requisitos del sistema por parte del servidor:
Servidor web apache Tomcat 7.
Sistema gestor de base de datos en un principio preferentemente PostgreSQL.
Máquina virtual de java (Java Runtime Environment 1.6) en el sistema operativo.
Requisitos del sistema por parte del cliente:
Contar con un navegador web Mozilla Firefox 4.0 o superior, aunque también se
pudieran utilizar otros como Internet Explorer, Chrome y Opera.
Requisitos de rendimiento:
El tiempo de respuesta accediendo a la memoria caché deberá ser menor que el
tiempo de respuesta al acceder directamente a la fuente de datos
2.4 Diagrama de casos de uso del sistema
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un
resultado importante. Los casos de uso representan los requisitos funcionales. Todos los
casos de uso juntos constituyen el modelo de casos de uso (Jacobson, 2000). Los diagramas
de casos de uso muestran el comportamiento del sistema a partir de los usuarios que
CAPÍTULO 2.” PATRONES DE CACHÉ” 39
interactúan con él. Describe gráficamente quién utiliza el sistema y la forma en que los
usuarios esperan interactuar con él Figura 2.9.
Figura 2.9 Diagrama de casos de uso
2.4.1 Descripción de los casos de uso del sistema
En las siguientes tablas se describen de forma detallada en qué consisten los casos de uso
del sistema:
Tabla 3 Descripción del caso de uso: Lectura bajo demanda
Caso de Uso: Lectura bajo demanda
Actor: Usuario, Desarrollador o Sistema
Propósito: Lee datos de la caché, de no existir accede a la fuente de datos y los
guarda en la caché para luego devolverlo al cliente
Resumen: El caso de uso se inicia cuando un actor realiza un lectura (doRead) a la
caché mediante una estrategia de demanda (Demand) la cual verifica si
existen los datos, de no existir este los pide bajo demanda a la fuente de
datos. El cliente no podrá precargar (doPrime) la caché de este, lo cual
CAPÍTULO 2.” PATRONES DE CACHÉ” 40
no es permitido en esta estrategia (NoPrime) ver Figura 2.8
Tabla 4 Descripción del caso de uso: Lectura precargada
Caso de Uso: Lectura precargada
Actor: Usuario, Desarrollador o Sistema
Propósito: Precarga la cache para cuando el cliente lee sobre esta no tenga que
acceder a la fuente de datos.
Resumen: El caso de uso se inicia cuando un actor precarga (doPrime) los datos
mediante una estrategia de precarga (Prime), una vez precargada lee
(doRead) directamente de la cache (CacheReader) ver figura 2.8
Tabla 5 Descripción del caso de uso: Lectura bajo demanda y precargada
Caso de Uso: Lectura bajo demanda y precargada
Actor: Usuario, Desarrollador o Sistema
Propósito: Leer datos de la caché bajo demanda y precargar datos de la fuente
Resumen: El caso de uso se inicia cuando un actor realiza una lectura (doRead) a la
caché mediante una estrategia de demanda (Demand) también podrá
realizar una precarga (doPrime) precargando los datos en la caché
(Prime) ver Figura 2.8
Tabla 6 Descripción del caso de uso: Lectura directa
CAPÍTULO 2.” PATRONES DE CACHÉ” 41
Caso de Uso: Lectura directa
Actor: Usuario, Desarrollador o Sistema
Propósito: Realizar la lectura directa de la fuente de datos.
Resumen: El caso de uso se inicia cuando un actor realiza una lectura (doRead)
directa a la fuente de datos mediante una estrategia de lectura directa
(DirectReading) El cliente no podrá realizar la precarga (doPrime), lo
cual no es permitido en esta estrategia (NoPrime) ver figura 2.8
2.5 Conclusiones parciales
En el presente capitulo fueron expuestos los patrones relacionados con el acceso a datos,
teniendo en cuenta los relacionados con la memoria caché. De estos patrones fueron
seleccionados aquellos que acceden a las fuentes de datos con el objetivo de integrarlos en
un patrón de comportamiento basado en estrategias de cacheo (Strategy), en esta
integración se encontraron los patrones Data Accessor, Cache Accessor, Demand Cache y
Primed Cache. Una vez integrados fueron identificados los requisitos funcionales basados
en diferentes estrategias para acceder a datos, definidos estos realizamos los casos de usos
del sistema con sus descripciones correspondientes.
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 42
CAPÍTULO 3. DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN
En el presente capítulo se describirá la propuesta de solución del sistema mediante el
modelo de componente y diagramas de clases. También se abordaran los principales
diagramas de secuencias para los principales casos de usos del sistema. Se abordara la
justificación del principio de diseño utilizado y mostraremos el diagrama de despliegue.
3.1 Modelo de componentes
Un diagrama de componente muestra la organización y las dependencias entre un conjunto
de componentes. Los diagramas de componentes se utilizan para modelar la vista de
implementación estática de un sistema (Grady Booch, 2005). En la siguiente Figura 3.1 se
muestra la arquitectura del sistema mediante su diagrama de componentes.
Figura 3.1 Diagrama de Componentes
A continuación describimos la relación entre los distintos componentes de la arquitectura
anterior. Inicialmente un cliente accede a través del navegador web, aplicación desktop o
cualquier software que sea capaz de invocar el servicio de cacheo desplegado en el servidor
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 43
web Tomcat. Dependiendo de la estrategia de cacheo que seleccione el cliente se accederá a
la base de datos, gestionada por PostgreSQL.
3.2 Diagrama de clases
Los diagramas de clases se utilizan para modelar la vista estática de diseño de un sistema.
Esta vista soporta principalmente los requisitos funcionales de un sistema, los servicios que
el sistema debe proporcionar a sus usuarios finales (Grady Booch, 2005).
A continuación se muestra y describe el diagrama de clase de la estructura del sistema.
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 44
Figura 3.2 Diagrama de clases
En el diagrama de clases anterior Figura 3.2 se muestra la estructura del sistema el cual está
compuesto por dos paquetes CacheStrategy y DataAccess. En el primer paquete se
encuentra la estructura integrada de los patrones de cacheo en un patrón Strategy el cual
nos permite decidir la estrategia a tomar para realizar el acceso a los datos. Este paquete usa
el paquete DataAccess, que contiene las clases necesaria para realizar el acceso a los datos
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 45
existentes en la fuente de datos. DBAccessor es una interfaz implementada por
ConcreteDBAccessor encargada de realizar la conexión con el gestor de base de datos en
caso de que los datos no se encuentren cacheados. DBAccessor hace uso de Key quien es
un identificador de datos necesario para realizar la consulta en el momento que se ejecuta la
conexión con la base de datos. DBAccessor es utilizada únicamente por las clases Primed
y Demand quienes son encargadas de precargar y demandar los datos respectivamente de
una base de datos, sin embargo no ocurre lo mismo con Key ya que esta es utilizada por
todos para tener la identificación de los datos que se quiere acceder.
3.3 Diagrama de Secuencias
Un diagrama de secuencia destaca la ordenación temporal de los mensajes. Esto una señal
visual clara del flujo de control a lo largo del tiempo (Grady Booch, 2005).
Los siguiente diagramas de secuencia está estructurados por una arquitectura vista-modelo-
controlador donde el Cliente iniciara los casos de usos mediante una interfaz gráfica, como
modelo tenemos la caché y las fuentes de datos, por último la parte controladora estaría a
cargo del servicio de cacheo, las estrategias de cacheo y la clase para realizar la conexión a
las fuentes de datos. Seguidamente serán mostrados los principales diagramas de
secuencias de la aplicación
A continuación en la figura 3.3 se muestra el diagrama de secuencia relacionado con el caso
de uso lectura directa.
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 46
Figura 3.3 Diagrama de secuencia: Lectura directa
El caso de uso es iniciado cuando un cliente selecciona una funcionalidad en la interfaz
gráfica donde es ejecutado un recuso para acceder a datos mediante una lectura directa a la
fuente de datos. Los datos serán buscados directamente mediante el acceso de
ConcreteDBAccessor a la base de datos, una vez encontrado los datos serán retornados al
cliente como se describe en el diagrama de secuencia anterior Figura 3.3.
A continuación en la figura 3.4 se muestra el diagrama de secuencia relacionado con el caso
de uso lectura bajo demanda.
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 47
Figura 3.4 Diagrama de secuencia: Lectura bajo demanda
El caso de uso es iniciado cuando un cliente selecciona una funcionalidad en la interfaz
gráfica la cual ejecutará un recurso para acceder a datos bajo demanda en el servicio web,
los datos serán buscados en la memoria caché de encontrarse allí serán devueltos al cliente,
de lo contrario ConcreteDBAccessor accederá a la base de datos en la búsqueda de estos,
una vez encontrados los datos serán retornados al cliente siguiendo los pasos mostrados en
el anterior diagrama de secuencia Figura 3.4.
A continuación en la figura 3.5 se muestra el diagrama de secuencia relacionado con el caso
de uso lectura precargada.
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 48
Figura 3.5 Diagrama de secuencia: Lectura precargada
El caso de uso en iniciado cuando un cliente selecciona una funcionalidad en la interfaz
gráfica la cual ejecuta un recurso para precargar los datos en el servicio web, primeramente
la estrategia de precarga (PrimedCache) solicitara los datos mediante ConcreteDBAccessor
a la base de datos, una vez obtenidos los datos estos serán guardados en memoria caché. La
próxima vez que el cliente decida acceder a los datos ya estos se encuentran precargados en
la memoria cache como es mostrado en el anterior diagrama de secuencia Figura 3.5
3.4 Principios de Diseño
Para diseñar la propuesta de solución se tuvieron en cuenta los siguientes principios de
diseño:
Reutilización de soluciones probadas
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 49
Mediante el uso de patrones de diseño existentes para el acceso a datos y para la integración
de diferentes estrategias aprovechamos el conocimiento existente en estas áreas de modo
que reutilizamos técnicas que han sido probadas por otros desarrolladores.
Identificar los aspectos de la aplicación que varían y sepáralos de los que no lo hace
para poder cumplir el principio de la reutilización de código.
Aplicando el primer principio de diseño que vimos anteriormente separamos lo que varía de
lo que no lo hace. Es decir tenemos varias estrategias de lectura y precarga las cuales
estarían separadas por dos interfaces IReader e IPrime. Cumpliendo con esto tenemos dos
comportamientos uno en cada interfaz, para leer read() y el otro para precargar prime() de
esta forma se aíslan los comportamiento y se encapsulan.
Mantener la flexibilidad programando para una interfaz, no para una clase.
Una vez definido los comportamientos y especificadas las interfaces las cuáles nos darán la
presentación de los comportamientos a otras clases. De esta forma estaríamos cumpliendo
con el segundo principio de diseño consiguiendo flexibilidad ya que lo que se quiere es
agregarle comportamiento a las subclases de CacheAccessor. Diseñar una interfaz significa
diseñar un comportamiento que será sobrescrito por las clases que lo implementan, así de
esta manera podemos utilizar polimorfismo y hacer que la instancia de la superclase pueda
referirse a cualquiera de sus subclases, en tiempo de ejecución, por lo que hicimos una
interfaz IPrime e IReader con sus clases concretas correspondientes.
Anteponer la composición a la herencia.
Una vez aislado el comportamiento y construidas las interfaces se aplicó el último de los
principios, integrar los comportamientos con CacheAccessor. Hicimos una composición
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 50
donde CacheAccessor tiene un comportamiento de leer doRead() y de precargar
doPrime(), las cuales son heredados por las subclases, y son instanciadas en su constructor
con el comportamiento deseado.
De esta forma queda diseñado el patrón Strategy el cual define una familia de algoritmos,
encapsulados cada uno, e intercambiables. Strategy hace que los algoritmos varíen
independientemente del cliente que los esté usando (Freeman, 2004) ver paquete
CacheStrategy Figura 3.2.
3.5 Diagrama de Despliegue
Un diagrama de despliegue muestra la configuración de nodos que participan en la
ejecución y de los componentes que residen en ellos. Los diagramas de despliegue se
utilizan para modelar la vista de despliegue estática de un sistema. La mayoría de las veces,
esto implica modelar la topología del hardware sobre el que se ejecuta el sistema. Los
diagramas de despliegue fundamentalmente diagramas de clases que se ocupan de modelar
los nodos de un sistema (Grady Booch, 2005).
CAPÍTULO 3. “DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN” 51
Figura 3.6 Diagrama de despliegue
Como se muestra en la Figura 3.6 mediante el protocolo HTTP se establece un conexión de
uno o varios clientes con un servidor web que tiene desplegado un servicio web. La
conexión entre el servidor y el gestor de base de datos es mediante el protocolo TCP/IP.
3.6 Conclusiones parciales
En el presente capitulo fue expuesto el modelo de componente del sistema donde como
componentes principales tendríamos un cliente el cuál invoca el servicio web desplegado en
un servidor Tomcat que accederá a una fuente de datos. El diagrama de clase fue
estructurado por dos paquetes principales CacheStrategy donde se encontraría la
integración propuesta en el capítulo anterior la cual no variara en la utilización de nuestra
librería de acceso de datos y el paquete DataAccess, este un poco más flexible ya que el
gestor de base de datos pudiera ser otro cambiando así la conexión. Fueron descritos los
diagramas de secuencias principales del sistema para el caso de la lectura directa, lectura
bajo demanda y lectura precargada. Se establecieron los principios de diseños y se
construyó el diagrama de despliegue mostrando los nodos que participan en la ejecución.
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 52
CAPÍTULO 4. PRUEBAS Y ANÁLISIS DE FACTIBILIDAD
En el presente capitulo se realizaran pruebas de rendimiento en cuanto al tiempo de
respuesta del servicio mediante la consola de Mozilla Firefox. Posteriormente se analizará
la factibilidad del sistema mediante el proceso para el cálculo de costo y tiempo basado en
los casos de uso para las funcionalidades desarrolladas.
4.1 Pruebas
Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las
entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su
funcionamiento interno.
Se realizaron pruebas para determinar si el tiempo de acceso a datos cumplía con el
planteamiento de la hipótesis de la investigación. Para poder realizar estas pruebas se hizo
uso dentro de la consola web del Mozilla Firefox del monitor de red como se muestra en la
figura 4.1.
Figura 4.1 Consola web del navegador Mozilla Firefox
Se realizaron 20 accesos a los datos mediante estrategias de acceso directo a la fuente y con
estrategias de caché como se muestra en la Tabla 7.
Tabla 7 Tiempo de iteraciones en cada estrategia.
No iteraciones Acceso directo Acceso con caché
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 53
1 123 ms 10 ms
2 187 ms 57 ms
3 162 ms 9 ms
4 112 ms 23 ms
5 108 ms 16 ms
6 117 ms 40 ms
7 96 ms 11 ms
8 108 ms 8 ms
9 93 ms 13 ms
10 122 ms 41 ms
11 94 ms 8 ms
12 122 ms 8 ms
13 112 ms 49 ms
14 118 ms 12 ms
15 140 ms 27 ms
16 161 ms 11 ms
17 117 ms 8 ms
18 95 ms 9 ms
19 113 ms 8 ms
20 150 ms 33 ms
Promedio 122,5 ms 20.05 ms
Como resultado de estas iteraciones el tiempo medio de acceder directamente a los datos en
nuestro ejemplo fue de 122,5 ms y el tiempo promedio de acceso a estos en caché fue de
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 54
20.05 ms, por lo tanto se llega a la conclusión que el acceso a datos con patrones de cacheo
es aproximadamente 83,7 % más rápido que el acceso sin estos.
4.2 Planificación basada en uno de los métodos de estimación
La planificación es un proceso de toma de decisiones para alcanzar un futuro deseado,
teniendo en cuenta la situación actual y los factores internos y externos que pueden influir
en el logro de los objetivos (M and Patricia, 2009).
4.2.1 Estimación basada en casos de uso
Este método de estimación de proyectos de software fue desarrollado en 1993 por Gustav
Karner de Rational Software y está basado en una metodología orientada a objetos, dándole
el nombre de "estimación de esfuerzos con casos de uso". Surgió como una mejora al
método de puntos de función pero basando las estimaciones en el modelo de casos de uso,
producto del análisis de requerimientos. Según su autor, la funcionalidad vista por el
usuario (modelo de casos de uso) es la base para estimar el tamaño del software.
Estimación del Esfuerzo Basada en Casos de Uso.
Cálculo de Puntos de Casos de Uso sin Ajustar (UUCP).
Este valor se calcula a partir de la siguiente ecuación:
UUCP = UAW + UUCW donde,
UUCP: Puntos de Casos de Uso sin ajustar
UAW: Factor de Peso de los Actores sin ajustar
UUCW: Factor de Peso de los Casos de Uso sin ajustar
Determinación del factor de peso de los actores sin ajustar (UAW)
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 55
Este valor se calcula mediante un análisis de la cantidad de Actores presentes en el sistema
y la complejidad de cada uno de ellos. La complejidad de los actores se establece, teniendo
en cuenta en primer lugar, si se trata de una persona o de otro sistema, y en segundo lugar,
la forma en que el actor interactúa con el sistema como aparece en la Tabla 8 Factores de
peso de los actores
Tabla 8 Factores de peso de los actores.
Tipo de
actor
Descripción Factor
de peso
Número
de
actores
Resultado
Simple Otro sistema que interactúa con el
sistema a desarrollar mediante una
interfaz de programación (API,
Aplication Programming Interface)
1 0 0
Promedio Otro sistema que interactúa con el
sistema a desarrollar mediante un
protocolo o una interfaz basada en
texto.
2 0 0
Complejo Una persona que interactúa con el
sistema mediante una interfaz
gráfica.
3 1 3
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 56
Total 3
De esta manera tenemos que UAW = 3
Determinación del factor de peso en los casos de uso sin ajustar (UUCW)
Este valor se calcula mediante un análisis de la cantidad de Casos de Uso presentes en el
sistema y la complejidad de cada uno de ellos. La complejidad de los casos de uso se
establece teniendo en cuenta la cantidad de transacciones efectuadas en el mismo, donde
una transacción se entiende como una secuencia de actividades atómicas, es decir, se
efectúa la secuencia de actividades completa, o no se efectúa ninguna de las actividades de
la secuencia como se muestra en la Tabla 9.
Tabla 9 Factores de peso de los casos de uso.
Tipo de caso
de uso
Descripción Factor
de peso
Número de
Casos de Uso
Resultado
Simple 1-3 Transacciones 5 1 5
Promedio 4-7 Transacciones 10 2 20
Complejo Mayor de 8
Transacciones.
15 1 15
Total 40
UUCW = 40
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 57
Por tanto:
UUCP = UAW + UUCW
UUCP = 3 + 40
UUCP = 43
Cálculo de Puntos de Casos de Uso ajustados
Seguidamente de calcular los Puntos de Casos de Uso sin ajustar, se debe ajustar este valor
mediante la siguiente ecuación:
UCP = UUCP x TCF x EF donde,
UCP: Puntos de Casos de Uso ajustados
UUCP: Puntos de Casos de Uso sin ajustar
TCF: Factor de complejidad técnica
EF: Factor de ambiente
Determinación del factor de complejidad técnica (TCF)
La Tabla 10 muestra la cuantificación de un conjunto de factores que determinan la
complejidad técnica del sistema. Cada uno de los factores se cuantifica con un valor de 0 a
5, donde 0 significa un aporte irrelevante y 5 un aporte muy importante.
Tabla 10 Factores de complejidad técnica.
Número
de factor
Descripción Peso Valor Factor Comentario
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 58
T1 Sistema
Distribuido
2 0 0 El sistema no es distribuido; es
totalmente centralizado.
T2 Tiempo de
respuesta
1 5 5 El sistema debe responder
rápidamente a los pedidos de los
usuarios pero no es algo que sea
100% seguro.
T3 Eficiencia por
el usuario
1 4 4 Los usuarios tienen que ser
eficientes, ya que estos pudieran
ser desarrolladores de software.
T4 Proceso
interno
complejo
1 3 3 No existe un procesamiento
complejo, no se efectúan
operaciones complejas.
T5 Reusabilidad 1 5 5 El código es lo más reutilizable
posible.
T6 Facilidad de
instalación
1 5 5 El proceso de instalación es
complejo ya que se está
brindando una biblioteca que
tiene sus restricciones a la hora
de ser utilizada
T7 Facilidad de 1 3 3 Una vez instalado en una
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 59
uso aplicación será usado por esta,
por lo que se considera de uso
fácil
T8 Portabilidad 2 4 8 A los usuarios del sistema no les
interesa cambiar de SO
T9 Facilidad de
cambio
1 5 5 El sistema debe ser fácil de
cambiar ya que se le pudieran
insertar nuevas estrategias para
realizar lectura.
T10 Concurrencia 1 5 5 Pueden existir varios clientes
trabajando con el servicio en un
instante.
T11 Objetivos
especiales de
seguridad
1 4 4 Esta es trazada por el
desarrollador quien decide qué
tipo de recurso se accederá.
T12 Acceso directo
a terceras
partes
1 4 4 La aplicación es accesible a
cualquiera de los usuarios
T13 Facilidades
especiales de
1 3 3 Se hace necesario el
entrenamiento a usuarios finales,
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 60
entrenamiento
a usuarios
finales
especialmente a los
desarrolladores, ya que estos
establecen los recursos.
Total 54
El Factor de complejidad técnica se calcula mediante la siguiente ecuación:
TCF = 0.6 + 0.01 * ∑ (Peso i x Valor asignado i)
TCF = 0.6 + 0.01* 54
TCF = 1.14
Determinación del factor ambiente (EF)
Las habilidades y el entrenamiento del grupo involucrado en el desarrollo tienen un gran
impacto en las estimaciones de tiempo. Estos factores son los que se contemplan en el
cálculo del Factor de ambiente, como se puede observar en la ¡Error! No se encuentra el
origen de la referencia.
Tabla 11 Factores de ambiente.
Número
del factor
Descripción Peso Valor Factor Comentario
E1 Familiaridad
con el modelo
del proyecto
1 5 5 Es bastante familiarizado con
el modelo del proyecto ya que
a partir de este se ha logrado
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 61
usado. la implementación.
E2 Experiencia en
la aplicación
1 4 4 Con el conocimiento del
lenguaje a utilizar se ha
adquirido experiencia durante
el período de trabajo.
E3 Experiencia
OO.
1 4 4 Se considera cierto grado de
experiencia en la
programación orientada a
objetos (OO), debido a que
esta se impartió en primer
año.
E4 Capacidad del
analista líder.
0.5 0 0 No existe analista líder.
E5 Motivación. 1 4 4 Exista motivación para el
desarrollo del proyecto ya
que está encaminado al
trabajo de diploma
E6 Estabilidad de
los
requerimientos.
2 5 10 Aunque el sistema se
encuentra sujeto a cambios, el
mismo brinda las
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 62
funcionalidades esenciales
que dan cumplimiento a los
objetivos que iniciaron su
realización.
E7 Personal media
jornada.
-1 3 -3 Se trabajará a medio tiempo
ya que se le dedica tiempo a
la investigación y a la
elaboración de la
documentación
E8 Dificultad en
lenguaje de
programación.
-1 0 0 Como el lenguaje empleado
fue Java, se consideran pocas
dificultades en su empleo.
Total 24
El factor de ambiente se calcula mediante la siguiente ecuación:
EF = 1.4 – 0.03 * ∑ (Peso i x Valor asignado i)
EF = 1.4 – 0.03 * 24
EF = 0.68
Cálculo de los Puntos de Casos de Uso Ajustados:
UCP = UUCP * TCF * EF
UCP = 43 * 1.14 * 0.68
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 63
UCP = 33.333
Cálculo del esfuerzo
El esfuerzo en horas-hombre viene dado por:
E = UCP * CF donde:
E: esfuerzo estimado en horas-hombre.
UCP: Puntos de casos de uso ajustados.
CF: Factor de conversión (20 horas-hombre por defecto).
E = 33.333 * 20
E = 666,672
Para la obtención de una estimación más exacta de la duración del proyecto, se hace
necesario agregar a la estimación del esfuerzo obtenida por los Puntos de Casos de Uso, las
estimaciones de esfuerzo de las restantes actividades que se llevaron a cabo durante el
desarrollo del software; así la distribución del esfuerzo entre dichas actividades está dada
por la aproximación asignada en la ¡Error! No se encuentra el origen de la referencia.
Tabla 12 Distribución genérica del esfuerzo.
Actividad Porcentaje
Análisis 20.00%
Diseño 30.00%
Programación 35.00%
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 64
Pruebas 10.00%
Sobrecarga(otras actividades) 5.00%
Con este criterio y tomando como entrada la estimación de tiempo calculada a partir de los
Puntos de Casos de Uso, se pueden calcular las demás estimaciones para obtener la
duración total del proyecto. Ver Tabla 13 Distribución real del esfuerzo.
Tabla 13 Distribución real del esfuerzo.
Actividad Porcentaje
Análisis 380.95
Diseño 571.43
Programación 666.67
Pruebas 190.48
Sobrecarga(otras actividades) 95,24
Total 1904.77
Cálculo del esfuerzo total:
ETotal = 1904.77 horas /hombre
Cálculo del tiempo de desarrollo:
TDesarrollo = ETotal/CHTotal: Cantidad de hombres =1
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 65
TDesarrollo =1904.77 /1
TDesarrollo = 1904.77 horas
Considerando que se trabajan 8 horas diarias:
TDesarrollo = TDesarrollo/8 horas/día
TDesarrollo= 1904.77 horas/8 horas/día
TDesarrollo= 238 días aproximadamente
Cálculo del costo:
CostoTotal = ETotal * 2 * TH TH: Tarifa horaria (= 1.031)
CostoTotal =1904.77 * 2 * 1.031
Costo Total = 3928
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
el acceso mediante patrones de acceso a memoria caché reducían considerablemente el
CAPITULO 4. “PRUEBAS Y ANÁLISIS DE FACTIBILIDAD” 66
tiempo de respuesta un 83,7 %. También fueron realizadas las planificaciones basadas en el
método de estimación de caso de usos.
CONCLUSIONES 67
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
cache, el cual sirve de guía a arquitectos y desarrolladores de software.
RECOMENDACIONES 68
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 69
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.
W3C. 2007. SOAP [Online].
ANEXOS 70
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.
Figura A2 Creación del rol en Tomcat
ANEXOS 71
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
continuación el NetBeans será configurado para utilizar el servidor anteriormente instalado.
ANEXOS 72
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
usuario, contraseña y damos clic en finalizar figura A6.
ANEXOS 73
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
daremos clic en siguiente figura A7.
ANEXOS 74
Figura A7 Creación de un nuevo proyecto
Seguidamente definimos el nombre del proyecto y su localización figura A8.
ANEXOS 75
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
from Patterns como se muestra en la figura A10.
ANEXOS 76
Figura A10 Creación de un nuevo recurso
Luego seleccionamos las especificaciones del recurso donde seleccionaremos el paquete
donde estará localizado y el nombre del recurso como se muestra en la figura A11.
ANEXOS 77
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, luego seleccionamos 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
como se muestra en la figura A13.
ANEXOS 78
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.
ANEXOS 79
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
mediante el método de toJson() es convertido en un String figura A16.
ANEXOS 80
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
todas las categorías disponibles de noticias, otro que precarga los autores de noticias.
ANEXOS 81
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.
Figura A18 Datos obtenidos formateados
top related