Autor: Efrain Uc Salvador

2019
- Investigación diferentes patrones

2
 - Investigación diferentes patrones

Patrones De Diseño Para

Desarrollo Web.

Contenido
Introducción............................................................................................................................................ 4
Antecedentes ......................................................................................................................................... 4
Concepto de patrón de diseño. ............................................................................................................. 5
Arquitectura de las aplicaciones Web. .................................................................................................. 6
Modelo de dos Capas. ....................................................................................................................... 7
Modelo de tres Capas. ....................................................................................................................... 8
Patrón "Modelo-Vista-Controlador" ....................................................................................................... 9
PATRONES CREACIONALES. ........................................................................................................... 11
PATRONES DE COMPORTAMIENTO. .............................................................................................. 11
PATRONES ESTRUCTURALES. ....................................................................................................... 11
Bibliografia. .......................................................................................................................................... 12

3
 - Investigación diferentes patrones

Introducción.

El diseño es un modelo del sistema, realizado con una serie de principios y técnicas, que
permite describir el sistema con el suficiente detalle como para ser implementado. Pero
los principios y reglas no son suficientes, en el contexto de diseño podemos observar que
los buenos ingenieros tienen esquemas y estructuras de solución que usan numerosas
veces en función del contexto del problema. Este es el sentido cabal de la expresión "tener
un mente bien amueblada", y no el significado de tener una notable inteligencia. Estos
esquemas y estructuras son conceptos reusables y nos permiten no reinventar la rueda. Un
buen ingeniero reutiliza un esquema de solución ante problemas similares.

Antecedentes

El concepto de "patrón de diseño" que tenemos en Ingeniería del Software se ha tomado

prestado de la arquitectura. En 1977 se publica el libro "A Pattern Language:
Towns/Building/Construction", de Christopher Alexander, Sara Ishikawa, Murray Silverstein,
Max Jacobson, Ingrid Fiksdahl-King y Shlomo Angel, Oxford University Press. Contiene
numerosos patrones con una notación específica de Alexander.
Alexander comenta que “Cada patrón describe un problema que ocurre una y otra vez
en nuestro entorno, para describir después el núcleo de la solución a ese problema, de
tal manera que esa solución pueda ser usada más de un millón de veces sin hacerlo
siquiera dos veces de la misma forma”. El patrón es un esquema de solución que se aplica
a un tipo de problema, esta aplicación del patrón no es mecánica, sino que requiere de
adaptación y matices. Por ello, dice Alexander que los numerosos usos de un patrón no
se repiten dos veces de la misma forma.

La idea de patrones de diseño estaba "en el aire", la prueba es que numerosos

diseñadores se dirigieron a aplicar las ideas de Alexander a su contexto. El catálogo más
famoso de patrones se encuentra en “Design Patterns: Elements of Reusable Object-
Oriented Software”, de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides,
1995, Addison-Wesley, también conocido como el libro GOF (Gang-Of-Four).

Siguiendo el libro de GOF los patrones se clasifican según el proposito para el que han
sido definidos:
 Creacionales: solucionan problemas de creación de instancias. Nos ayudan a
encapsular y abstraer dicha creación.
 Estructurales: solucionan problemas de composición (agregación) de clases y
objetos.
 De Comportamiento: soluciones respecto a la interacción y responsabilidades entre
clases y objetos, así como los algoritmos que encapsulan.
Según el ámbito se clasifican en patrones de clase y de objeto:

4
 - Investigación diferentes patrones

Creación Estructural De Conducta

Método de Adaptador Interprete
Clase
Fabricación (clases) Plantilla
Cadena de
Responsabilidad,
Adaptador
Comando (orden),
(objetos),
Fábrica, Iterador,
Puente,
Constructor, Intermediario,
Objeto Composición,
Prototipo, Observador,
Decorador,
Singleton Estado,
Fachada,
Estrategia,
Flyweight
Visitante,
Memoria

Concepto de patrón de diseño.

"Una arquitectura orientada a objetos bien estructurada está llena de patrones. La calidad
de un sistema orientado a objetos se mide por la atención que los diseñadores han
prestado a las colaboraciones entre sus objetos. Los patrones conducen a arquitecturas
más pequeñas, más simples y más comprensibles". (Grady Booch)
Los patrones de diseño son descripciones de clases cuyas instancias colaboran entre
sí. Cada patrón es adecuado para ser adaptado a un cierto tipo de problema. Para
describir un caso debemos especificar:
 Nombre
 Propósito o finalidad
 Sinónimos (otros nombres por los que puede ser conocido)
 Problema al que es aplicable
 Estructura (diagrama de clases)
 Participantes (responsabilidad de cada clase)

5
 - Investigación diferentes patrones
 Colaboraciones (diagrama de interacciones)
 Implementación (consejos, notas y ejemplos)
 Otros patrones con los que está relacionado.

Ventajas de los patrones:

La clave para la reutilización es anticiparse a los nuevos requisitos y cambios, de modo
que los sistemas evolucionen de forma adecuada. Cada patrón permite que algunos
aspectos de la estructura del sistema puedan cambiar independientemente de otros
aspectos. Facilitan la reusabilidad, extensibilidad y mantenimiento.

Un patrón es un esquema o micro arquitectura que supone una solución a problemas

(dominios de aplicación) semejantes (aunque los dominios de problema pueden ser muy
diferentes e ir desde una aplicación CAD a un cuadro de mando empresarial). Interesa
constatar una vez más la vieja distinción entre dominio del problema (donde aparecen las
clases propias del dominio, como cuenta, empleado, coche o beneficiario) y el dominio de
la solución o aplicación (donde además aparecen clases como ventana, menú, contenedor
o listener). Los patrones son patrones del dominio de la solución.

También conviene distinguir entre un patrón y una arquitectura global del sistema. Por
decirlo en breve, es la misma distancia que hay entre el diseño de un componente (o
módulo) y el análisis del sistema. Es la diferencia que hay entre el aspecto micro y el
macro, por ello, en ocasiones se denomina a los patrones como "micro arquitecturas".
En resumen, un patrón es el denominador común, una estructura común que tienen
aplicaciones semejantes. Esto también ocurre en otros órdenes de la vida. Por ejemplo, en
nuestra vida cotidiana aplicamos a menudo el esquema saludo-presentación-mensaje-
despedida en ocasiones diversas, que van desde un intento de ligar hasta dar una
conferencia (si todavía no cree que existan patrones o que no son útiles intente ligar con el
esquema despedida-mensaje-presentación-saludo, a ver qué ocurre).

Arquitectura de las aplicaciones Web.

Una aplicación
Web es proporcionada por un servidor Web y utilizada por usuarios que se Conecta
n desde cualquier punto vía clientes Web (browsers o navegadores). La arquitectura de
un Sitio Web tiene tres componentes principales:
 Un servidor Web
 Una conexión de red
 Uno o más clientes
El servidor Web distribuye páginas de información formateada a los clientes que las
solicitan. Los requerimientos son hechos a través de una conexión de red, y para ello se
usa el protocolo HTTP. Una vez que se solicita esta petición mediante el protocolo HTTP y
la recibe el servidor Web, éste localiza la página Web en su sistema de archivos y la envía
de vuelta al navegador que la solicitó.

6
 - Investigación diferentes patrones

Las aplicaciones Web están basadas en el modelo Cliente/Servidor que gestionan

servidores web, y que utilizan como interfaz páginas web.
Las páginas Web son el componente principal de una aplicación o sitio Web. Los browsers
piden páginas (almacenadas o creadas dinámicamente)
con información a los servidores Web. En algunos ambientes de desarrollo
de aplicaciones Web, las páginas contienen código HTML y scripts dinámicos, que son
ejecutados por el servidor antes de entregar la página.
Una vez que se entrega una página, la conexión entre el browser y el servidor Web se
rompe, es decir que la lógica del negocio en el servidor solamente se activa por la
ejecución de los scripts de las páginas solicitadas por el browser (en el servidor, no en el
cliente). Cuando el browser ejecuta un script en el cliente, éste no tiene acceso directo a
los recursos del servidor. Hay otros componentes que no son scripts, como
los applets (una aplicación especial que se ejecuta dentro de un navegador) o
los componentes ActiveX. Los scripts del cliente son por lo general código JavaScript o
VBSscript, mezclados con código HTML.
La colección de páginas son en una buena parte dinámicas (ASP, PHP, etc.), y están
agrupadas lógicamente para dar un servicio al usuario. El acceso a las páginas está
agrupado también en el tiempo (sesión). Los componentes de una aplicación Web son:
1. Lógica de negocio.
 Parte más importante de la aplicación.
 Define los procesos que involucran a la aplicación.
 Conjunto de operaciones requeridas para proveer el servicio.
2. Administración de los datos.
 Manipulación de BD y archivos.
3. Interfaz
 Los usuarios acceden a través de navegadores, móviles, PDAs, etc.
 Funcionalidad accesible a través del navegador.
 Limitada y dirigida por la aplicación.
Las aplicaciones web se modelan mediante lo que se conoce como modelo de capas, Una
capa representa un elemento que procesa o trata información. Los tipos son:
 Modelo de dos capas: La información atraviesa dos capas entre la
interfaz y la administración de los datos.
 Modelo de n-capas: La información atraviesa varias capas, el más habitual es el
modelo de tres capas.

Modelo de dos Capas.

Gran parte de la aplicación corre en el lado del cliente (fat client).

Las capas son:
 Cliente (fat client): La lógica de negocio está inmersa dentro de la aplicación que
realiza el interfaz de usuario, en el lado del cliente.

7
 - Investigación diferentes patrones
 Servidor: Administra los datos.
Las limitaciones de este modelo son.
 Es difícilmente escalable
 Número de conexiones reducida
 Alta carga de la red.
 La flexibilidad es restringida
 La funcionalidad es limitada.

Modelo de tres Capas.

Esta diseñada para superar las limitaciones de las arquitecturas ajustadas al modelo de
dos capas, introduce una capa intermedia (la capa de proceso) Entre presentación
y los datos, los procesos pueden ser manejados de forma separada a la interfaz de
usuari o y a los datos, esta capa intermedia centraliza la lógica de negocio, haciendo
la administración más sencil a, los datos se pueden integrar de múltiples fuentes,
las aplicaciones web actuales se ajustan a este modelo.
Las capas de este modelo son:
1. Capa de presentación (parte en el cliente y parte en el servidor)
 Recoge la información del usuario y la envía al servidor (cliente)
 Manda información a la capa de proceso para su procesado
 Recibe los resultados de la capa de proceso
 Generan la presentación
 Visualizan la presentación al usuario (cliente)
2. Capa de proceso (servidor web)
 Recibe la entrada de datos de la capa de presentación
 Interactúa con la capa de datos para realizar operaciones
 Manda los resultados procesados a la capa de presentación
3. Capa de datos (servidor de datos)
 Almacena los datos
 Recupera datos
 Mantiene los datos
 segura la integridad de los datos

8
 - Investigación diferentes patrones

Patrón "Modelo-Vista-Controlador"

Descripción.

Para el diseño de aplicaciones con sofisticados interfaces se utiliza el patrón de diseño

Modelo-Vista-Controlador. La lógica de un interfaz de usuario cambia con más frecuencia
que los almacenes de datos y la lógica de negocio. Si realizamos un diseño ofuscado, es
decir, un pastiche que mezcle los componentes de interfaz y de negocio, entonces la
consecuencia será que, cuando necesitemos cambiar el interfaz, tendremos que modificar
trabajosamente los componentes de negocio. Mayor trabajo y más riesgo de error.
Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de
mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor
medida en la lógica de negocio o de datos.
Elementos del patrón:
 Modelo: datos y reglas de negocio
 Vista: muestra la información del modelo al usuario
 Controlador: gestiona las entradas del usuario

9
 - Investigación diferentes patrones
Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un
ejemplo clásico es el de la información de una base de datos, que se puede presentar de
diversas formas: diagrama de tarta, de barras, tabular, etc. Veamos cada componente:
1. El modelo es el responsable de:
o Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo
sea independiente del sistema de almacenamiento.
o Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de
regla puede ser: "Si la mercancía pedida no está en el almacén, consultar el
tiempo de entrega estándar del proveedor".
o Lleva un registro de las vistas y controladores del sistema.
o Si estamos ante un modelo activo, notificará a las vistas los cambios que en
los datos pueda producir un agente externo (por ejemplo, un fichero bath que
actualiza los datos, un temporizador que desencadena una inserción, etc).

2. El controlador es responsable de:

o Recibe los eventos de entrada (un clic, un cambio en un campo de texto,
etc.).
o Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción
W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una
de estas peticiones a las vistas puede ser una llamada al método
"Actualizar()". Una petición al modelo puede ser
"Obtener_tiempo_de_entrega( nueva_orden_de_venta )".

3. Las vistas son responsables de:

o Recibir datos del modelo y los muestra al usuario.
o Tienen un registro de su controlador asociado (normalmente porque además
lo instancia).
o Pueden dar el servicio de "Actualización()", para que sea invocado por el
controlador o por el modelo (cuando es un modelo activo que informa de los
cambios en los datos producidos por otros agentes).
Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los datos) es
la navegación web, que responde a las entradas del usuario, pero no detecta los cambios
en datos del servidor.

El diagrama de secuencia:
Pasos:
1. El usuario introduce el evento.
2. El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque
también puede llamar directamente a la vista).
3. El modelo (si es necesario) llama a la vista para su actualización.
4. Para cumplir con la actualización la Vista puede solicitar datos al Modelo.

10
 - Investigación diferentes patrones
5. El Controlador recibe el control.

PATRONES CREACIONALES.

Patrones creacionales: Resuelven problemas relacionados con la creación de instancias

de objetos. Por ejemplo, el patrón Singleton se encarga de que sólo pueda existir una
instancia de la clase a la que es aplicado.

El patrón de diseño singleton (instancia única) está diseñado para restringir la creación
de objetos pertenecientes a una clase o el valor de un tipo a un único objeto.

PATRONES DE COMPORTAMIENTO.

Patrones de comportamiento: Permiten resolver problemas relacionados con el

comportamiento de la aplicación, normalmente en tiempo de ejecución. Por ejemplo,
el patrón Strategy proporciona diferentes métodos (o algoritmos) para resolver un
mismo problema, pudiendo decidir en tiempo de ejecución cuál de ellos utilizar.

PATRONES ESTRUCTURALES.

Patrones estructurales: Se centran en problemas relacionados con la forma de

estructurar las clases. Por ejemplo, el patrón Compositor permite trabajar con listas de
objetos (u objetos compuestos) como si de un solo objeto se tratase.

11
 - Investigación diferentes patrones
Bibliografia.

https://es.slideshare.net/MarioMartinez36/isuu-47932998

https://programacionwebisc.wordpress.com/2-1-arquitectura-de-las-aplicaciones-web/

http://di002.edv.uniovi.es/~dflanvin/docencia/dasdi/teoria/Transparencias/06.%20Arquitec
tura%20Web.pdf

http://www.tamps.cinvestav.mx/~vjsosa/clases/sd/Arquitectura_MVC.pdf

12