patrones de diseño.docx

UNIVERSIDAD TECNOLOGICA DEL PERU

FACULTAD : INGENIERIA DE SISTEMAS Y ELECTRONICA

TEMA : PATRONES DE DISEÑO

CURSO : INGENIERIA DE SOFTWARE

DOCENTE : DIAZ GARRAMPIE , DARWIN MANUEL

ALUMNOS : ROJAS GUADALUPE, JONATHAN

AULA : A0303

HORA : MIERCOLES 20:15 - 22:30

2016


1. INTRODUCCION

Los casos de usos se han llegado a convertirse en la base de muchas metodologías de desarrollo orientadas a objetos. Estos generalmente proporcionan el fundamento y el punto de partida para el resto de los procesos de análisis y desarrollo. Un caso de uso es una secuencia de transacciones en un sistema cuya tarea es producir un valor medible de un actor individual del sistema. Uno de los aspectos más importantes de los casos de uso específica la funcionalidad completa de un sistema.

Por otra parte el uso de patrones para el desarrollo de software establece la diferencia entre un buen y un mal diseño orientado a objetos. Un patrón es un fragmento nombrado de información instructiva, que captura la estructura esencial y la visión interna de una familia de soluciones con probado éxito sobre un problema recurrente que surge dentro de un cierto contexto y fuerzas de sistema. En otras palabras, rehusar soluciones que funcionaron bien una vez.


2. PATRONES DE DISEÑO

En programación orientada a objetos se entiende por patrón una solución probada que se puede aplicar con éxito a un determinado tipo de problemas que aparecen repetidamente en el desarrollo de sistemas software.

Los patrones no son una librería. Van más bien en la línea de un esqueleto básico que cada desarrollador luego adapta a sus necesidades y a las peculiares características de su aplicación. Se describen fundamentalmente en forma textual, acompañada de diagramas y de seudo-código.

Definiciones:

“Un patrón es un pedazo de información con nombre, instructivo y significante, que captura la esencia de una familia exitosa y completa de soluciones a un problema recurrente en un contexto dado” Brad Appleton

“Cada patrón es una regla de tres partes, la cual expresa una relación entre un contexto dado, un conjunto de fuerzas que ocurren repetitivamente en ese contexto y cierta configuración de software que permite a esas fuerzas resolverse por si mismas” Richard Gabriel

“Cada patrón es una regla de tres partes, la cual expresa una relación entre un cierto contexto, un problema y una solución. El patrón es, resumiendo, al mismo tiempo una cosa que tiene su lugar en el mundo, y la regla que nos dice cómo crear esa cosa y cuándo debemos crearla. Es al mismo tiempo una cosa y un proceso; al mismo tiempo una descripción de una cosa que tiene vida y una descripción del proceso que la generó” Christopher Alexander, The Timeless Way of Building, 1.979

Un buen patrón debe:–Solucionar un problema: Un patrón captura soluciones, no solo principios abstractos o estrategias

–Es un concepto probado

–La solución no es obvia

–Describe una relación: No solo describen módulos, describen estructuras y mecanismos

–Tiene un componente humano significante: es estético y de utilidad


James Coplien “Estos patrones en nuestras mentes son, más o menos, imágenes

mentales de los patrones en el mundo: son representaciones abstractas de las reglas morfológicas que definen los patrones en el mundo. Sin embargo, son realmente diferentes. Los patrones en el mundo solo existen. Pero esos mismos patrones en nuestras mentes son dinámicos. Tienen fuerza. Son generativos. Nos dicen qué hacer, cómo se pueden generar y, en ciertas circunstancias, que los debemos crear. Cada patrón es una regla que describe que debemos hacer para generar la entidad que los define” Christopher Alexander , The Timeless Way of Building, 1.979

3. DESARROLLO HISTORICO

El término patrón se utiliza inicialmente en el campo de la arquitectura, por Christopher Alexander, a finales de los 70s. Este conocimiento es trasportado al ámbito del desarrollo de software orientado por objetos y se aplica al diseño. De allí es extrapolado al desarrollo en general y a las demás etapas. Algunos libros que marcan el desarrollo del área son:

Alexander, Christopher. A Pattern Language: Towns, Buildings, Construction. 1977

Alexander, Christopher. The Timeless Way of Building. 1979 Gamma et al. Design Patterns: Elementos of Reusable Object-Oriented

Software. 1994 Bushmann et al. Pattern-Oriented Software Architecture: A System of

Patterns. 1996 Coplien y Schmidth. Pattern Languages of Program Design. 1995

Algunos eventos importantes en la historia del tema de patrones en Ingeniería de software son:

1987. Ward Cunningham y Kent Beck escriben sus experiencias de enseñar Smalltalk por medio de las ideas de Alexander en Using Pattern Languages for Object-Oriented Programs.

1990. El GoF empiezan la recopilación de patrones de diseño 1991. Jim Coplien publica su recopilación de idioms de C++ en

Advanced C++ Programming Styles and Idioms.

1994. El GoF publica el libro Design Patterns: Elementos of Reusable Object-Oriented Software.


4. TIPOS DE PATRONES

Existen varios tipos de patrones, dependiendo del nivel de abstracción, del contexto particular en el cual aplican o de la etapa en proceso de desarrollo. Algunos de estos tipos son:

De arquitectura De diseño Idioms De análisis Para ambientes distribuidos De negocios De procesos y organizacionales

4.1 PATRONES DE ARQUITECTURA

Son esquemas fundamentales de organización de un sistema software.

Especifican una serie de subsistemas y sus responsabilidades respectivas e incluyen las reglas y criterios para organizar las relaciones existentes entre ellos.

Se recogen aquí ocho patrones estructurales, agrupados en cuatro categorías:

Del caos a la organización Niveles

Tuberías y filtros

Pizarra

Sistemas distribuidos Intermediario o broker

Sistemas interactivos MVC: Modelo-Vista-Controlador

PAC: Presentación, Abstracción, Control

Sistemas adaptables Microkernel

Reflexión

4.2 PATRONES DE DISEÑO

http://polaris.dit.upm.es/~jcduenas/patrones/Reflexion.htm

http://polaris.dit.upm.es/~jcduenas/patrones/Microkernel.htm

http://polaris.dit.upm.es/~jcduenas/patrones/presentacion.htm

http://polaris.dit.upm.es/~jcduenas/patrones/Modelo.htm

http://polaris.dit.upm.es/~jcduenas/patrones/broker.htm

http://polaris.dit.upm.es/~jcduenas/patrones/Pizarra.htm

http://polaris.dit.upm.es/~jcduenas/patrones/Filtros%20y%20tuber%C3%ADas.htm

http://polaris.dit.upm.es/~jcduenas/patrones/Niveles.htm


Son patrones de un nivel de abstracción menor que los patrones de arquitectura. Están por lo tanto más próximos a lo que sería el código fuente final. Su uso no se refleja en la estructura global del sistema.

Características de los patrones de diseño

Son soluciones concretas. Un catálogo de patrones es un conjunto de

recetas de diseño. Aunque existen clasificaciones de patrones, cada uno es

independiente del resto.

Son soluciones técnicas. Dada una determinada situación, los patrones

indican cómo resolverla mediante OO. Hay patrones específicos para un

determinado lenguaje y otros de carácter más general.

Se aplican en situaciones muy comunes. Los patrones de diseño

proceden de la experiencia, y han demostrado su utilidad resolviendo

problemas que aparecen frecuentemente en el DOO.

Son soluciones simples. Indican cómo resolver un problema particular

utilizando un pequeño número de clases relacionadas de forma

determinada. No indican cómo diseñar un determinado sistema sino sólo

aspectos puntuales del mismo.

Facilitan la reutilización de las clases y del propio diseño. Los patrones

favorecen la reutilización de clases ya existentes y la programación de

clases reutilizables. La propia estructura del patrón es reutilizada cada vez

que se aplica.

El uso de un determinado patrón no se refleja claramente en el código. A partir de la implementación es difícil determinar que patrón de diseño se

ha usado.

Referencias a self. Muchos patrones utilizan la delegación de operaciones

y esto provoca el problema del self.


Es difícil reutilizar la implementación de un patrón. Las clases del

patrón son roles genéricos, pero en la implementación aparecen clases

concretas.

Los patrones suponen una sobrecarga de trabajo a la hora de implementar. Se usan más clases, es necesario delegar mensajes, etc.

Se pueden organizar los patrones según familias de patrones relacionados . La clasificación facilita la búsqueda del patrón más adecuado así como su comprensión . Gamma clasifica los patrones según dos criterios fundamentales: su propósito y su alcance [Gamma 95].

El propósito refleja lo que realiza el patrón . Los patrones pueden tener propósito de creación, estructural o de conducta. Los patrones con propósito de creación conllevan el proceso de creación de objetos. Los patrones estructurales tratan de la composición de clases u objetos. Los patrones de conducta describen las formas en que las clases u objetos interactúan o distribuyen responsabilidades.

El alcance indica si el patrón aplica principalmente a clases u objetos. Los patrones de clases tratan de relaciones entre clases y sus subclases. Estas relaciones se establecen a través de la relación de herencia, por consiguiente son estáticas y definidas en tiempo de compilación. Los patrones de objetos tratan de relaciones entre objetos que pueden ser cambiadas en tiempo de ejecución y son más dinámicas. Casi todos los patrones utilizan la herencia de alguna forma. Pero son los patrones de clases los que se focalizan en las relaciones de clase.

Los patrones con propósito de creación y alcance de clase difieren parte de la creación de objetos a subclases mientras que los patrones con propósito de creación y alcance de objeto difieren ésta a otros objetos. Los patrones estructurales y alcance de clase utilizan la herencia para componer clases, mientras que los patrones estructurales y alcance de objeto describen formas de ensamblado de objetos. Los patrones de conducta con alcance de clase utilizan herencia para describir algoritmos y flujos de control mientras que los patrones de conducta con alcance de objeto describen como un grupo de objetos cooperan para realizar una actividad que un objeto no puede realizar por sí solo.

La tabla 1 muestra la clasificación propuesta por Gamma de algunos de los patrones más utilizados actualmente [Gamma 95]

Creación Estructural De Conducta

Clase Método de Fabricación

Adaptador (clases)

Interprete


Plantilla

Objeto FábricaAdaptador (objetos)

Cadena de Responsabilidad

Constructor Puente Comando

Prototipo Composición Iterador

Singleton Decorador Intermediario

Fachada Observador

Flyweight Estado

Apoderado Estrategia

Visitante

Memoria

Tabla 1. Clasificación de Patrones de Diseño

EJEMPLO DE PATRONES DE DISEÑO

Como ejemplo de patrón de diseño se mostrará el patrón intermediario.

Patrón Intermediario

Este patrón define un objeto que encapsula como un conjunto de objetos interaccionan. El intermediario facilita el acoplamiento mínimo, evitando que los objetos participantes se tengan que referenciar entre ellos explícitamente , con lo que se permite variar su interacción independientemente. Los objetos participantes solo conocen al intermediario.

El desarrollo orientado a objetos potencia el reparto de conducta entre objetos. Tal reparto puede resultar en una arquitectura donde existen múltiples conexiones entre los objetos. En el peor de los casos cada objeto debería conocer a todos los demás. Esto dificulta la reutilización. Se puede evitar esta situación, encapsulando la conducta colectiva en un objeto llamado intermediario. Un intermediario es responsable de controlar y coordinar las interacciones de un grupo de objetos. Esto puede ser útil como se verá en el ejemplo de interacciones entre elementos gráficos.

La estructura del patrón siguiendo la notación OMT para el diagrama de clases es como sigue:


Figura 1. Patrón Intermediario

Un ejemplo de utilización de este patrón es la implementación de cajas de dialogo en una interfaz gráfica . Una caja de dialogo utiliza una ventana para presentar una colección de elementos gráficos tales como botones, menús o campos de entrada. Frecuentemente existen dependencias entre los elementos gráficos en el dialogo. Por ejemplo un botón esta inhabilitado cuando cierto campo de entrada esta vacío. Seleccionando una entrada de una lista de opciones llamada una caja tipo lista podría cambiar los contenidos de un campo de entrada. Se puede encapsular esta conducta en un intermediario, llamado en el ejemplo Director_Dialogo.

Es importante resaltar los siguientes aspectos:

Cada objeto de las clases participantes es decir los objetos gráficos de tipo List_Box o Entry _Field solo conoce a su intermediario concreto .

Siempre que un objeto gráfico requiera comunicarse con otro ha de hacerlo a través de su intermediario (Director_Dialogo).

Figura 2. Ejemplo del Patrón Intermediario

5. PATRONES Y COMPONENTES

Cabría aquí preguntarse por la diferencia entre patrones de diseño y componentes . Encontramos en el mercado una serie de productos que incorporan un conjunto de elementos, denominados componentes y que permiten construir de forma rápida partes de la aplicación, en particular la interfaz de usuario. La disponibilidad inmediata de botones, ventanas, menús desplegables, etc hacen que la construcción de una interfaz gráfica sea desde


un punto de vista técnico una tarea relativamente sencilla. Los problemas de interacción con el usuario y el nivel de usabilidad tienen que ver con problemas de diseño más complejos que con la construcción 'física' de la interfaz.

La diferencia fundamental con un patrón es que el componente es una combinación fija de objetos, que se puede instanciar mediante el arrastre desde un icono que lo representa y que se incorpora inmediatamente a la aplicación que se está construyendo. Esto significa que se trata de clases que combinan un conjunto de otras formando macroobjetos pero que están integradas en la librería de clases suministrada con el producto. De esta manera, se pueden ir implementando nuevos componentes a los cuales se asociarán íconos que los identifiquen y que permitan utilizarlos de la misma manera que los suministrados originalmente con el producto.

Los patrones, por su lado, no forman parte de ninguna librería de clases . Sólo son modelos de combinación que pueden utilizarse en el momento que se presenta un problema similar al que pretende dar solución el patrón correspondiente. A lo sumo, y en una instalación muy bien organizada, podrían almacenarse en una base de datos a la cual accedemos cuando nos enfrentamos a las diversas decisiones de diseño durante las fases de análisis y de diseño.

6. DESCRIPCION DEL PATRON Y PLANTILLA DE PATRONES

Dependiendo del autor, del nivel de abstracción y de la publicación misma se han presentado varios formatos para encapsular la información de un patrón. Los puntos más significativos que debe contener un patrón son:

Nombre: Significativo y corto, fácil de recordar y asociar a la información que sigue

Problema: Un enunciado que describe las metas y objetivos buscados y el contexto

Contexto: Define las precondiciones en las cuales ocurren el problema y su solución

Fuerzas: Descripción de las fuerzas y restricciones relevantes en el problema y como interactúan o entran en conflicto

Solución: Las relaciones estáticas y reglas dinámicas que describen cómo solucionar el problema

Ejemplos: Uno o más ejemplos que ilustren el contexto, el problema y su solución

Contexto Resultante: El estado en el cual queda el sistema después de aplicar el patrón y las consecuencias de hacerlo

Racionalidad: Una explicación justificada de los pasos o reglas en el patrón

Relaciones: relaciones estáticas y dinámicas del patrón con otros

Usos conocidos: Describe ocurrencias del patrón conocidas y su aplicación dentro de los sistemas existentes


La propuesta de Gamma (1995), por ejemplo, propone que los elementos esenciales de un patrón son los siguientes:

1. Un nombre del patrón. Es una forma abreviada que pueda darnos una idea del problema al que se aplica, sus soluciones y consecuencias. Al asignar un nombre, estamos facilitando la tarea de diseño puesto que nos comunicamos a un mayor nivel de abstracción. Es bastante difícil encontrar nombres adecuados que sirvan a este propósito.

2. El problema describe cuando aplicar el patrón. Aquí se explica el problema y su contexto. Un añadido útil es el de las condiciones de aplicabilidad del patrón.

3. La solución describe los elementos que constituyen el diseño, sus relaciones, responsabilidades y colaboraciones. Se insiste mucho en que esta solución es como una plantilla que provee una descripción abstracta de un problema de diseño y cómo una disposición general de elementos (en este caso clases y objetos) puede resolverlo.

4. Las consecuencias son los resultados y compromisos de aplicar el patrón

Estos son los elementos esenciales, pero cuando se trata de realizar una descripción concreta de un patrón, la plantilla propuesta estará compuesta por una serie de secciones que permiten una estructura más detallada que la ofrecida por la enumeración de los elementos esenciales.

Siguiendo a Gamma, encontramos la siguiente lista y descripción de secciones dentro de la plantilla que describe cada patrón. Este formato estructurado es útil puesto que permite la separación semántica de lo que podría haber sido un texto completo y permite además su almacenamiento en una base de datos para su posterior acceso si deseamos aumentar su reutilización.

Contexto: Conjunto de entornos bajo los cuales existe el patrón.

Problema: Describe los problemas de diseño que se ha encontrado el desarrollador.

Causas: Lista los razones y motivos que afectan al problema y la solución. La lista de causas ilumina las razones por las que uno podría haber elegido utilizar el patrón y proporciona una justificación de su uso.

Solución: Describe brevemente la solución y sus elementos en más detalle. La sección de la solución contiene dos sub-secciones:

o Estructura: Utiliza diagramas de clases UML para mostrar la estructura


básica de la solución. Los diagramas de secuencias UML de esta sección presentan los mecanismos dinámicos de la solución. Hay una explicación detalladas de los participantes y las colaboraciones.

o Estrategias: Describe diferentes formas en las que se podría implementar el patrón.

Consecuencias: Aquí se describen las compensaciones del patrón, esta sección se enfoca en los resultados de la utilización de un patrón en particular o de su estrategia, y anota los pros y los contras que podrían resultar de la aplicación del patrón.

Patrones Relacionados: Esta sección lista otros patrones relevantes en el catálogo de patrones J2EE u otros recursos externos, como los patrones de diseño GoF. Por cada patrón relacionado, hay una breve descripción de su relación con el patrón que se está describiendo.

7. INTERCEPTING FILTER

Contexto

El mecanismo de manejo de peticiones de la capa de presentación recibe muchos tipos diferentes de peticiones, cada uno de los cuales requiere varios tipos de procesamiento. Algunas peticiones simplemente requieren su reenvio al componente manejador apropiado, mientras que otras peticiones deben ser modificadas, auditadas, o descomprimidas antes de su procesamiento posterior.

Problema:

Se requiere un pre-procesamiento y un post-procesamiento de unas peticiones o respuestas de un cliente Web.

Cuando una petición entra a una aplicación Web, normalmente debe pasar varios test de entrada antes del estado de procesamiento principal. Por ejemplo,

¿Se ha autentificado el cliente? ¿Tiene el cliente una sesión válida? ¿La dirección IP del cliente es de una red conocida? ¿Viola alguna restricción el path de la petición? ¿Qué codificación usa el cliente para enviar los datos? ¿Soportamos el tipo de navegador del cliente?

Algunos de estos chequeos son tests, que resultan en una respuesta de si o no que determina si continuará el procesamiento. Otros chequeos manipulan el stream de datos entrantes a una forma aceptable para el procesamiento.


La solución básica consiste en un serie de chequeos condicionales, si cualquiera de ellos falla la petición se aborta. Las sentencias if/else anidadas son una estrategia estándar, pero esta solución tiene fragilidad de código y un estilo de programación de copiar-y-pegar, porque el flujo del filtrado y la acción de los filtros se compila dentro de la aplicación.

La clave para solventar este problema de una forma flexible y no obstrusiva es tener un mecanismo simple para añadir y eliminar componentes de procesamiento, en el que cada componente completa una acción de filtrado específica.

Causas

Procesamiento común, como un chequeo del esquema de codificación de datos o la información de login de cada petición, completo por cada petición.

Se desea la centralización de la lógica común. Se debería facilitar la adición o eliminación de sevicios sin afectar a los

componentes existentes, para que se puedan utilizar en gran variedad de combinaciones, como

o Logging y autentificación. o Depuración y transformación de la salida para un cliente

específico o Descomprensión y conversión del esquema de codificación de la

entrada.

Solución

Crear filtros conectables para procesar servicios comunes de una forma estándar sin requerir cambios en el código principal del procesamiento de la petición. Los filtros interceptan las peticiones entrantes y las respuestas salientes, permitiendo un pre y post-procesamiento. Podemos añadir y eliminar estos filtros a discrección, sin necesitar cambios en nuestro código existente.

Podemos, en efecto, decorar nuestro procesamiento principal con una veriedad de servicios comunes, como la seguridad, el logging, el depurado, etc. Estos filtros son componentes independientes del código de la aplicación principal, y pueden añadirse o eliminarse de forma declarativa. Por ejemplo, se podría modificar un fichero de configuración de despliegue para configurar una cadena de filtros. Cuando un cliente pide un recurso que corresponde con este mapeo de URL configurado, se procesa cada filtro de la cadena antes de poder invocar el recurso objetivo.

Estructura

La siguiente figura representa el diagrama de clases del patrón Intercepting Filter.


La siguiente figura representa el diagrama de la secuencia del patrón Intercepting Filter.


MainServlet.java

package intercepting_filter;

import javax.servlet.*;

import javax.servlet.http.*;

import java.io.*;

import java.util.*;

public class MainServlet extends HttpServlet {

private static final String CONTENT_TYPE = "text/html";

//Initialize global variables

public void init() throws ServletException {

}

//Process the HTTP Get request

public void doGet(HttpServletRequest request, HttpServletResponse response) throws

ServletException, IOException {

response.setContentType(CONTENT_TYPE);

UNIVERSIDAD TECNOLOGICA DEL PERU PrintWriter out = response.getWriter();

out.println("<html>");

out.println("<head><title>MainServlet</title></head>");

out.println("<body bgcolor=\"#c0c0c0\">");

out.println("<p>The servlet has received a GET. This is the reply.</p>");

out.println("</body>");

out.println("</html>");

out.close();

}

//Clean up resources

public void destroy() {

}

}

ScanFilter.java




import java.io.*;

import java.util.*;

public class ScanFilter extends HttpServlet implements Filter {

UNIVERSIDAD TECNOLOGICA DEL PERU private FilterConfig filterConfig;

public void init(FilterConfig filterConfig) throws ServletException {

this.filterConfig = filterConfig;

}

//Process the request/response pair

public void doFilter(ServletRequest request, ServletResponse response,

FilterChain filterChain) {

try {

String contentType = request.getContentType();

System.out.println("El tipo de contenido es :");

System.out.println(contentType);

//if (contentType.startsWith("multipart/form-data")) {

//

// Por ejemplo, un procesamiento del fichero o escaneo para

//comprobar si tiene virus antes de subirlo a sevidor}

//}

filterChain.doFilter(request, response);

} catch (ServletException sx) {

filterConfig.getServletContext().log(sx.getMessage());

UNIVERSIDAD TECNOLOGICA DEL PERU } catch (IOException iox) {

filterConfig.getServletContext().log(iox.getMessage());

}

}



}

}

ServletFilter.java




import java.io.*;

import java.util.*;

public class ServletFilter extends HttpServlet implements Filter {

private FilterConfig filterConfig;

//Handle the passed-in FilterConfig

public void init(FilterConfig filterConfig) throws ServletException {

this.filterConfig = filterConfig;

}


//Process the request/response pair

public void doFilter(ServletRequest request, ServletResponse response,

FilterChain filterChain) {

try {

System.out.println("Paso por el filtro SevletFilter");

filterChain.doFilter(request, response);

} catch (ServletException sx) {

filterConfig.getServletContext().log(sx.getMessage());

} catch (IOException iox) {

filterConfig.getServletContext().log(iox.getMessage());

}

}



}

}

mainservlet.html

<html>

<head>

<title>

MainServlet

</title>

UNIVERSIDAD TECNOLOGICA DEL PERU</head>

<body bgcolor="#c0c0c0">

<form action="mainservlet" method="get">

<p>press Submit to invoke servlet MainServlet</p>

<p><input type="submit" name="Submit" value="Submit">

<input type="reset" value="Reset"></p>

</form>

</body>

</html>

web.xml

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">

<servlet>

<servlet-name>mainservlet</servlet-name>

<servlet-class>intercepting_filter.MainServlet</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>mainservlet</servlet-name>

<url-pattern>/mainservlet</url-pattern>

</servlet-mapping>

UNIVERSIDAD TECNOLOGICA DEL PERU <filter>

<filter-name>servletfilter</filter-name>

<filter-class>intercepting_filter.ServletFilter</filter-class>

</filter>

<filter-mapping>

<filter-name>servletfilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<filter>

<filter-name>scanfilter</filter-name>

<filter-class>intercepting_filter.ScanFilter</filter-class>

</filter>

<filter-mapping>

<filter-name>scanfilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

</web-app>

8. BIBLIOGRAFIA


http://www.fdi.ucm.es/profesor/jpavon/poo/2.14pdoo.pdf

http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf

http://www.utnianos.com.ar/foro/tema-dise%C3%B1o-de-sistemas-megapack-apuntes-resumenes-pdfs-finales-y-mas

http://www.ctr.unican.es/asignaturas/MC_OO/Doc/OO_08_I2_Proceso.pdf

http://www.justdocument.com/download/38332136572/competente-en-css-y-html-patrones-de-diseno/;jsessionid=97F059E55A47C3BEECCE88F2298D6C16

https://en.wikipedia.org/wiki/Design_Patterns

http://www.nebrija.es/areas/icsoftware/courses/iswii/course0304/tema3/ejemplo.html



https://en.wikipedia.org/wiki/Design_Patterns




http://www.ctr.unican.es/asignaturas/MC_OO/Doc/OO_08_I2_Proceso.pdf





http://www.fdi.ucm.es/profesor/jpavon/poo/2.14pdoo.pdf

patrones de diseño.docx

Documents