Universidad Gerardo Barrios

Lic. Carla Milagro López

Asignatura: Ing. De Software 2

Tarea: Patrones de Diseño Web

Responsable: Odil de Jesús Paredes Ticas.

Usts031214

Principios básicos de la usabilidad web. Hablamos de usabilidad web -concepto clave para diseñadores- al referirnos a facilidad de acceso, ubicación y navegación Cómo diseñar una página web es uno de los aspectos más importantes de un sitio web y las técnicas para que pueda ser entendible y sencillo de explorar por parte del usuario resultan determinantes. La usabilidad web se centra en la necesidad del usuario de tener accesibilidad web, ubicación y navegación dentro de una página web. Que

todo sea claro y estructurado para no complicar al visitante y tener el riesgo de perderlo en pocos segundos. El diseñador web es un personaje clave en la creación del sitio web, ya que no debe actuar no con la estética o el gusto subjetivo como prioridades, sino más bien pensar en el usuario.

Principios de usabilidad web El contenido de Internet tiene sus propias características con respecto a otros medios y apuesta por textos más resumidos y atractivos. El diseño debe contar con una navegación simple y clara, unos textos precisos y una estructura “amigable” para la mayoría de los usuarios. LOS PRINCIPALES CONCEPTOS EN TORNO A LA USABILIDAD WEB SON LOS SIGUIENTES:

::. Visibilidad: Es importante que el usuario pueda reconocer los diferentes elementos de manera sencilla, sin mayor esfuerzo. ::. Consistencia: Una información debe ser reiterada de diferentes

formas pero debe ser siempre la misma. Tiene que haber una definición en torno a los patrones de la página web y la experiencia del usuario para no crear confusión.

::. Compatibilidad: El sitio web debe adecuarse a la forma de pensar del usuario promedio, del cliente potencial y el público meta. En estética y funcionalidad, los procesos deben adaptarse a las expectativas de los visitantes.

::. Eficiencia: Debes reducir el trabajo del usuario en todos los niveles, facilitar el camino para que pueda encontrar la información que desea o que pueda retroceder en caso de hallar un resultado indeseado. Hay que predecir los posibles pasos a seguir del visitante y prevenir los errores. Un buen consejo es siempre tener en cuenta quiénes serán los usuarios habituales de la página web y así enfocar el diseño en ese camino, tomando en cuenta su experiencia y nivel de conocimiento.

Errores de usabilidad web Sin importar la cantidad de visitas que puede tener un sitio web o las ganancias que obtenga por determinado servicio o producto, es fácil detectar algunos problemas para el uso del usuario promedio.

ALGUNAS DE ESTAS FALLAS DE USABILIDAD WEB SON LAS SIGUIENTES: Login ocultos: Es suficientemente complicado lograr interesar a un

usuario para que se registre en una página web, por lo que no tener un acceso visible para usuario y contraseña

Pop-ups: Prácticamente todos los navegadores tienen bloqueadores de

pop-ups, por lo que las ventanas emergentes han pasado a ser una molestia y no son la mejor manera de presentar contenido.

Links invisibles: La navegación es una importante, por lo que no

encontrar los enlaces necesarios para movilizarse a través de la página web puede traer problemas importantes.

Sobrecarga visual: Muchas veces, más es menos. El “ruido” visual es

uno de los problemas comunes que los diseñadores provocan o deben resolver de acuerdo con la necesidad del cliente.

::. Menú desplegable: Ocultar opciones en un menú desplegable

ahorra espacio pero complica la navegación de los usuarios, ya que requiere un esfuerzo para fijar la posición del cursor y seleccionar esa opción.

LAS 10 REGLAS PARA DISEÑAR INTERFACES DE USUARIO A continuación te enumero las 10 comprobaciones heurísticas que propone Nielsen para evaluar la usabilidad y que te recomiendo que lleves a cabo, con una breve explicación de mi cosecha y algunos ejemplos.

Principio # 1. “Visibilidad del estatus del sistema” Es de vital importancia que tu usuario esté permanentemente informado sobre lo que está pasando cuando interactúa en tu web, ya que “por detrás” sucede un montón de cosas que no ve, y que le pueden producir incertidumbre en muchas situaciones. Esto parece obvio, pero lo cierto es que todavía se cometen errores graves de esta naturaleza, ¡incluso en webs de importantes empresas! Visibilidad del estado del sistema En esta imagen, tomada del proceso de subida de fotos a Facebook, vemos cómo una barra de proceso animada nos permite “visualizar” que la imagen está subiendo y que “todo va bien”. Debes proporcionar al usuario un feedback constante. Ésa es la función que cumplen, por ejemplo: Las barras de proceso que nos indican cómo avanza la subida de un archivo. Los mensajes que nos confirman que “el formulario se ha enviado correctamente”. Una animación que nos indica que algo está siendo procesado sin incidencias. Por favor, no dejes nunca a tu usuario pensando “¿qué estará pasando ahora?”.

Principio # 2. “Consistencia entre el sistema y el mundo real” El sistema tiene que “hablar” al usuario en su mismo lenguaje. Y esto no se refiere sólo al texto, sino también a elementos como: Las imágenes. El orden en que se hacen las cosas. La forma en que se presenta la información.

Consigue que la relación entre el hombre y la máquina sea natural. Internet no es otra realidad, es parte de la vida de las personas, y eso significa que el usuario rechaza, consciente o inconscientemente, interactuar bajo unos códigos de comunicación y de conducta distintos a los suyos. “Ser original”, “innovar” o “hacer cosas diferentes” no significa que debas imponer a tus usuarios un enfoque que rompa sus esquemas “porque es más creativo”… salvo que seas un artista y en eso consista tu trabajo, pero recuerda que estamos hablando de interfaces de usuario. Cuanto más claro, mejor.

Principio # 3. “El usuario es libre y tiene el control”

No fuerces al usuario a seguir un camino determinado, ya sea por un mal diseño o incluso de forma deliberada, porque a ti te interese. Evita a toda

costa los “callejones sin salida”.

El usuario tiene que poder navegar libremente, encontrar con facilidad “salidas” y “rutas alternativas”, y tener todas las facilidades que necesite para

“hacer” y “deshacer”. Si el usuario siente que tiene el control, su experiencia de uso será correcta;

si siente lo contrario, no tardará en marcharse. Principio #4. “Consistencia y estándares”

Tu sitio web debe seguir un estándar consistente en todas sus páginas. Es

decir, no puedes hacer por ejemplo que el menú funcione de manera diferente en distintas partes de tu web, ni cambiarlo de ubicación porque te parece que “queda mejor”. No puedes usar distintos diseños para la misma

cosa en distintos apartados (forma, color), ni una terminología variable. Si en

tu tienda online el carrito se llama “cesta” y tiene un icono verde en la home, no puede llamarse “carro” y tener un icono rojo en la ficha de producto;

tampoco puede estar unas veces en una esquina y otras en otra. Sé consistente en las decisiones que tomes.

Es muy frecuente encontrar errores de este tipo en Internet, especialmente

en webs veteranas que han ido sufriendo modificaciones con el paso del tiempo.

Es un error relativamente frecuente incurrir en inconsistencias graves por supeditar la funcionalidad a meras cuestiones estéticas. Los que más saben

(por ejemplo, Amazon o Google), nunca lo hacen. Saca tus conclusiones.

Principio # 5. “Prevención de errores”

No esperes a que el usuario cometa un error que sabes que va a cometer, para mostrarle después un mensaje de aviso. La mayor parte de los errores

son previsibles, y debes resolverlos de antemano. Esto lo puedes hacer:

Incluyendo información contextual preventiva en el punto problemático. Suprimiendo condiciones que son proclives a inducir a error.

Pidiendo confirmación al usuario. Haciendo comprobaciones en tiempo real.

Dos ejemplos típicos de formulario:

Un campo que cambia de color para recordarte que lo has dejado en

blanco. Una comprobación en tiempo real que te dice que la segunda contraseña

que has puesto no coincide con la primera, antes de dar a “enviar”.

Principio # 6. “Mejor reconocer que memorizar”

El usuario debe tener siempre toda la información a mano, y no verse obligado a usar su memoria para seguir el hilo de la interacción. Pónselo fácil para que no tenga que estar memorizando cómo volver a la página anterior o

cómo encontrar aquel producto que ya ha visto y le interesaba:

Si el usuario tiene que “recordar” cómo se hace algo en tu web en lugar de “saberlo” intuitivamente, tienes un problema.

Si el usuario tiene que recordar decisiones que ha tomado previamente porque no le muestras esa información cuando la necesita (por ejemplo en

un proceso de compra), su experiencia de uso se empobrece considerablemente, y tendrás muchos más abandonos en la web.

Principio # 7. “Flexibilidad y eficiencia de uso”

Algunos usuarios ya conocen tu web y realizan siempre las mismas acciones.

¿Tienes “aceleradores” que les permitan realizar de forma más rápida y directa esas acciones frecuentes?

Un buen interfaz de usuario tiene la flexibilidad necesaria para comportarse

“a la medida” de usuarios novatos y usuarios expertos.

Ejemplos:

Un “atajo” en la home a la página que más visitan tus usuarios, saltando pasos intermedios.

Mostrar los últimos artículos por los que se ha interesado el usuario en su última visita, o en la visita en curso, ya que probablemente querrá volver a

consultarlos.

Debes recordar que estos “aceleradores” no deben confundir a los novatos. Algunas webs ocultan automáticamente estas opciones cuando el visitante es nuevo, lo que sin duda es un síntoma de que sus propietarios “juegan en otra

liga” en materia de usabilidad. ¡Bien por ellos!

Principio # 8. “Diseño estético y minimalista”

El diálogo que el interfaz mantiene con el usuario no debe contener información irrelevante o de rara utilidad. Dice Nielsen que:

“Cada unidad extra de información en un diálogo compite con las unidades

relevantes de información y reduce la visibilidad relativa de éstas.”

Dicho de otra manera, cada palabra de más está oscureciendo las palabras que son realmente importantes.

Mi recomendación es que no limites este principio al texto, sino que lo apliques también al diseño visual. El diseño debe apoyar la función, no

“oscurecerla” ni “decorarla” (en mi humilde opinión, insisto, fundamentada por la experiencia).

Principio # 9. “Ayuda al usuario a reconocer, diagnosticar y recuperarse de

los errores”

Prevención de errores usabilidad

En el proceso de creación de un usuario en WordPress, vemos dos buenas prácticas importantes: (1) se nos avisa de un error en tiempo real, antes de enviar el formulario; (2) un texto junto al campo que debemos rellenar nos ofrece instrucciones y sugerencias justo donde y cuando las necesitamos.

Los mensajes de error tienen que estar escritos en un lenguaje que el usuario

pueda entender -desde luego no con tecnicismos- y deben siempre sugerir una solución o un camino de salida.

Por ejemplo, un ERROR 404 (página no encontrada), que es el más frecuente en cualquier web, debería ser sustituido por una pantalla amistosa donde se dijera algo como: “Vaya, la página que buscas no está aquí. Puede que esté en otro sitio, o que simplemente no exista. Por favor, utiliza este buscador

*buscador+ o haz clic en el enlace para volver a la página principal *enlace+”.

Principio # 10. “Ayuda y documentación”

Por supuesto, es preferible que el sistema pueda usarse de manera intuitiva sin tener que acudir a “unas instrucciones”. No obstante, el usuario

necesitará en ocasiones ayuda y documentación.

Es preciso que esta información sea fácil de encontrar, y sobre todo que esté orientada a las tareas concretas que realiza el usuario, antes que a cuestiones

teóricas o demasiado genéricas.

Un buen ejemplo es la lista de preguntas frecuentes (normalmente abreviado en inglés como FAQ), que puedes encontrar en la “ayuda” de plataformas

sociales como Twitter o Youtube.

La idea es evitar que el usuario tenga que leer contenidos de ayuda que no le interesan antes de llegar al texto que realmente va a resolver su problema.

Diseño web líquido o fluido.

Con el auge del acceso a internet a través de tablets, smartphones, smartTVs,

etc. ha surgido el problema de que las páginas web deben mostrarse en pantallas

de muy diferente tamaño. Conseguir que la misma página web se vea bien en

dispositivos muy distintos es algo que no es sencillo de resolver.

na primera aproximación

o intento de resolver este

problema es el

denominado diseño líquido o

fluido. Se dice que una página

web tiene diseño líquido cuando

la anchura de sus elementos está

definida utilizando porcentajes. Supongamos que tenemos una cabecera cuyo

ancho fijamos en el 100 %, una columna lateral cuyo ancho fijamos en el 25 % y

una parte principal de contenidos cuyo ancho fijamos en el 75%. El resultado será

que al visualizarse en distintos dispositivos la anchura de los elementos será un

porcentaje de la anchura disponible. Veamos algunos ejemplos:

Dispositivo Dimensiones pantalla en pixeles

Ancho que tomará la columna lateral

(25 %)

Ancho que tomará la parte principal

(75%)

Un TV Full HD 1.920 x 1080 px 480 px 1440 px

Un ordenador portátil

1280 x 800 px 320 px 960 px

Tablet Samsung Galaxy Tab

800 x 1280 px 200 px 600 px

iPhone 640 x 960 160 px 480 px

U

Parece una solución ideal. Ahora el tamaño de la página web se ajustará a la

pantalla y no se desaprovechará ninguna parte de las pantallas grandes ni

aparecerán barras de scroll lateral en las pantallas pequeñas. ¿Qué ocurre en la

práctica? En la práctica esta solución no es ideal ni mucho menos. Nos

encontramos que ocurre lo siguiente: en las pantallas grandes, un párrafo que en

una pantalla de un ordenador mediano se ve en 5 líneas se verá quizás en una sola

línea ya que el ancho disponible es muy grande.

El efecto es una línea muy larga que resulta desagradable de leer. Por el contrario,

cuando un párrafo consta de una sola línea corta, en una pantalla muy grande se

verá en el lateral izquierdo mientras que a su derecha queda un gran espacio en

blanco. En general, el diseño fluido dará lugar a una deformación de contenidos

que quedan muy a lo largo o demasiado cortos, y la impresión general es mala.

En las pantallas pequeñas como las de un smartphone, el diseño fluido hará que la

página web “se comprima” para ocupar el ancho disponible que es muy poco.

Cuando la pantalla es realmente pequeña, el efecto que se genera es de

“miniaturización” o que todo se ve “diminuto”, tan pequeño que prácticamente no

se puede leer. Por ello en la práctica es más habitual establecer estas anchuras

principales en pixeles antes que en porcentajes.

La solución a obtener una correcta visualización en páginas web puede

pasar por distintas vías:

1. Utilizar lo que se denomina “responsive design” que se podría traducir

como “diseño sensible al dispotivo” aunque muchas veces en español se

habla simplemente de “diseño responsive”. Esta técnica trata de usar un

único HTML y CSS pero mediante la detección del dispositivo en que se

va a visualizar la página, ofrecer un diseño adecuado para cada tipo de

dispositivo (esto obliga a escribir diferentes reglas según el tipo de

dispositivo en que se vaya a visualizar la web).

2. Utilizar diferentes dominios para el acceso con dispositivos pequeños o

dispositivos grandes. Por ejemplo el dominio http://www.iberia.com/

está destinado a dispositivos de pantallas medianas o grandes mientras

que http://iberia.mobi/ está destinado a tablets, smartphones y

similares. Los diseños son distintos: más simples para los dispositos

pequeños. Puede utilizarse la detección de dispositivo para redirigir del

dominio principal al .mobi.

3. Definir ancho en pixeles, que como indicamos al hablar de medidas CSS

podría considerarse una medida híbrida entre relativa y absoluta y es la

que suele ofrecer un mejor resultado “intermedio”.

4. Utilizar otras técnicas

5. En general cuando hablamos de las diferentes técnicas que se pueden

emplear hay algunas propiedades CSS que suelen resultar útiles y que

son: max-widht, min-width, max-height y min-height.

Patrón de diseño web híbrido

Se habla de diseño híbrido cuando en una web se combinan áreas con ancho fijo y otras con ancho variable. El resultado final es realmente una web de diseño líquido que conserva las proporciones en determinadas áreas.

Hasta ahora teníamos dos opciones para construir un sitio web disponible en dispositivos móviles. O recortábamos el diseño (responsive design, RWD) o el contenido (adaptive content). Difícilmente se ha optado por aplicar las dos opciones al mismo tiempo.

El RWD, la escuela más extendida, utiliza funciones de los estilos CSS para redibujar el contenido de una página web en función de la anchura detectada de la pantalla. Los menús se convierten en una lista de opciones desplegables, titulares y cuerpo de texto se amoldan al ancho disponible y el resto de las secciones cuelgan al final de la página.

Es la solución que utilizan generalmente los blogs, que tienen escasa complejidad en la arquitectura de su información y se adaptan bien a la capacidad de una pantalla de dispositivo móvil.

RESS tomará lo mejor de RWD y ‘adaptive content’ para que el mejor contenido encaje sin presión en el espacio de transmisión óptimo. Los sitios que utilizan adaptive content, mucho más complejos y escasos, detectan desde el servidor el tipo de dispositivo desde el que se conecta el usuario y mantienen o reducen en algunos grados la información a la que el usuario podrá acceder.

Por ejemplo, si el contenido cuenta con hojas de cálculo o aplicaciones para descargar, no tiene sentido que un usuario desde un teléfono móvil las descargue. No podrá usarlas o lo hará con muchas dificultades en una pantalla tan reducida. Es mejor que sepa que desde el sitio web consultado en un terminal de sobremesa podrá descargarlas, pero sin la opción de verlas en el teléfono.

La dificultad estriba en determinar qué y cómo se filtra el contenido. Quién decide qué se trasmitirá a un teléfono móvil. Si existe frustración y en qué grado por parte de usuarios que buscan un contenido que no encontrarán.

Los problemas de las pantallas retina y HiDPI

Más allá de los problemas de arquitectura de la información que puede generar un diseño RWD ante menús que abren submenús y páginas con media docena de

secciones, los sitios responsive adolecen de falta de usabilidad y, generalmente asociada, falta de accesibilidad.

Para obtener el mejor rendimiento de las fotografías y que no se muestren borrosas, el truco en las pantallas retina y HiPDI supone duplicar su tamaño y después, mostrarlas encajadas al 50%. Es decir, todo el aparato gráfico del sitio web pesa el doble y los navegadores de los dispositivos móviles, aunque no tengan estas pantallas de alta calidad, lo precargarán cuando se visita la URL.

Todo ello sin olvidar que las hojas de instrucciones CSS multiplican su tamaño, añadiendo todas las excepciones para cada anchura de pantalla, y que son frecuentes los apoyos extraordinarios con Ajax, que resultarían innecesarios en un terminal de sobremesa y añaden inaccesibilidad al producto final.

¿Y esto que está usted leyendo?

Estrategia del contenido.com está diseñado en HTML5 estándar, semántico y accesible, con estilos CSS3 proporcionales. Hablando en plata, significa que cada bloque de contenido forma una parcela autónoma en la página, de manera que dando dos toques con el dedo en cada área, ésta se amplía a la anchura de la pantalla del dispositivo. Y el diseño no se rompe, puesto que siempre las medidas son proporcionales. Por lo tanto, no utilizamos RWD ni adaptive content.

¿Nunca? Pues, no. El documento que sirve para agregadores que mejoran la experiencia de lectura en dispostivos móviles (Flipboard, Readability o Feedly) sólo ofrece información seleccionada. En estos dispositivos no hay referencias del texto, comentarios, archivos que los usuarios puedan descargar o presentaciones. Tampoco hay más fotografías que la principal, cuando existe.

La idea es que la lectura sea fácil. Si se desea más, deberá visitarse desde un dispositivo de sobremesa. En otras palabras, se reduce la velocidad de acceso del usuario a la página web a la mitad y se dobla el volumen de transferencia, afectando a los bonos de conexión a Internet.

Pero, además, si el contenido es extenso y variado (por ejemplo con texto largo, despiece, galería fotográfica, un par de vídeos, calendario de publicaciones, categorías y enlaces, sección de mapas…) es fácil que el usuario pierda en la posición en pantalla accidentalmente y le cueste recuperarla. Cuanto más contenido y más RWD, mayor será la intolerancia del usuario a este tipo de problemas de acceso a la información.

El paso intermedio entre contenido adecuado y el diseño ajustado. El programador Lucas Wroblewski, haciéndose eco de las dificultades de trasladar arquitecturas de

la información extensas a un dispositivo móvil, planteó a finales de 2011 una solución gráfica: Responsive Web Design + Server Side Component System (RESS) que empieza a triunfar en el diseño web de sitios complejos y que pronto podría ser una opción en algunos de los CMS más populares.

A grandes rasgos opera detectando, desde el servidor web y en el encabezado de la llamada URL, el tipo de dispositivo que realiza la conexión, enviando únicamente los archivos que éste requiere para una composición óptima de la página. Las fotografías, en su tamaño justo, y los archivos CSS más adecuados. El método reduce la velocidad de carga de una página a la mitad, aunque implica que en el momento de la creación del contenido deben construirse respuestas distintas para cada posible dispositivo. Dave Olsen ha publicado un ejemplo del método RESS con utilizando Detector y Mustache.

La apuesta de la estrategia de contenidos consiste en ir un poco más allá dentro de RESS. Ya que se procede a la detección del dispositivo para servirle los elementos gráficos más adecuados, también debe ser posible la entrega del contenido óptimo

para el teléfono móvil o la tableta, utilizando los criterios de contenido funcional y contenido de consulta, y la simplificación de adaptive content.

Hacerlo, en sitios grandes y complejos, evita la programación de sitios duplicados con dominio .mobi, en subdirectorios de tipo m.xxxx.xx y RWD que resulten inútiles. Sólo se necesita ajustar los gestores de contenidos.

Diseño web para móviles.

Crear una web especial para móviles y tablets

Programar una web con versión específica para móviles y/o tablets es una nueva estrategía de marketing que beneficia a las empresas, atrayendo tráfico adicional

de usuarios móviles. Es por esto que los negocios online han comenzado a fijar sus objetivos en el comercio móvil o M-commerce como otra opción rentable. Sin embargo tanto las webs corporativas, como catálogos y tiendas on line, deben centrarse en las preferencias particulares de los usuarios móviles y el tamaño reducido que supone este tipo de pantallas. Hay diversos factores importantes a considerar a la hora de diseñar y desarrollar una web

para M-commerce (comercio móvil):

- Los usuarios móviles generalmente tienen prisa o poco tiempo y aprovechan breves espacios de tiempo para navegar por el móvil, por tanto el proceso de compra y navegación lo hemos estudiado para que sea realmente sencillo y breve, de tal forma que puede comprar rápidamente o contactar con ustedes. Se debe mostrar un diseño y metodología similar al sitio general, sin olvidar las dimensiones reducidas de los dispositivos móviles, quedrán tener los mismos contenidos pero con una grata experiencia de navegación y compra.

Diseno-web-movil-adaptativo

- El cliente no tiene desventajas al usar la versión móvil, si un producto o servicio se encuentra en la versión general también se encontrará en la versión móvil, es más la versión móvil, para añadir satisfacción, se les puede ofrecer otras ventajas como información exclusiva, imágenes de calidad, etc.

- Que sea compatible con diferentes tamaños de pantalla y formatos, lo que se conoce como Responsive Web Design, donde el diseño de la web se adapta dinámicamente segun el tamaño de pantalla o bien la orientación de la misma (verticual/horizontal).

Diseño Web Adaptativo en inglés, Responsive Web Design (RWD)

Este diseño es un ejemplo de las mejores prácticas en cuanto a diseño de web móviles. En vez de crear una web distinta para un tamaño de pantalla específico,

un Diseño Web adaptativo, ofrece una única web que se adapta interactivamente ajustando sus capas para acomo darse a cualquier tamaño de pantalla. Esto permite que el proceso de actualización y mantenimiento de la página sea más eficiente

en cuanto a costes y resulta una experiencia para sus visitantes más atractiva.

De forma adicional, permite añadir elementos que solo verán los visitantes móviles, o desactivar ciertos componentes que no necesitan ver. Para web móviles con un propósito más específico, también es posible proveer al usuario de una web móvil completamente diferenciada e incluso una App (aplicación) móvil para Iphone, Ipad, Android, etc, si tiene un número significativo de clientes en dispositivos móviles.

Patrón de diseño

Los patrones de diseño son la base para la búsqueda de soluciones a problemas

comunes en el desarrollo de software y otros ámbitos referentes al diseño de

interacción o interfaces.

Un patrón de diseño resulta ser una

solución a un problema de diseño.

Para que una solución sea

considerada un patrón debe poseer

ciertas características. Una de ellas

es que debe haber comprobado su

efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que

debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de

diseño en distintas circunstancias.

Objetivos de los 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.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Los patrones creacionales son patrones que abstraen el proceso de instanciación. Procuran independizar el sistema de cómo sus objetos son creados, compuestos y representados. Encapsulan conocimientos sobre clases concretas usadas por el sistema. Dentro de los patrones creacionales encontramos a: Abstract Factory

Aborda el problema de la creación de familias de objetos, ofrece una interfaz para la creación de familias de productos relacionados o dependientes sin especificar las clases concretas a las que pertenecen. Este patrón se conoce también como Kit o toolkit.

Se usa cuando:

Un sistema debe ser independiente de cómo se crean, componen y representan sus productos.

Un sistema debe ser configurado con una familia de productos entre varias. Una familia de objetos producto relacionados está diseñada para ser usada

conjuntamente y es necesario hacer cumplir esa restricción. Se quiere proporcionar una biblioteca de clases de productos y sólo se

quiere revelar sus interfaces, no sus implementaciones.

Este patrón esta recomendado para situaciones en las que tenemos una familia de productos concretos y prevemos la inclusión de distintas familias de productos en un futuro. Algunas consecuencias del uso de Abstract Factory son:

Aísla las clases concretas. Facilita el intercambio de familias de productos. Promueve la consistencia entre productos. Una desventaja es que es difícil dar cabida a nuevos tipos de productos.

Motivación

Un caso relativamente común de uso de este patrón se da en la creación de familias de interfaces gráficos en las cuales los elementos (productos) de la interfaz se mantienen constantes (por ejemplo labels, botones, cajas de texto,…) pero el dibujado de dichos elementos puede delegarse en distintas familias de forma que, en función de la fábrica seleccionada obtenemos unos botones u otros. Participantes AbstractFactory: declara una interfaz para las operaciones que crean objetos de productos abstractos. ConcreteFactory: implementa las operaciones para crear productos de objetos concretos. AbstractProduct: declara una interfaz para un tipo de objeto de producto. ConcreteProduct: define un objeto producto para que sea creado por la fabrica correspondiente. Client: usa las interfaces AbstractFactory y AbstractProduct. Colaboraciones Normalmente se crea una instancia de alguna ConcreteFactory para la creación de los objetos ConcreteProduct. Esto es en tiempo de inicialización. AbstractFactory delega la creación de productos concretos (ConcreteProduct) en las ConcreteFactory. Factory Method Se le conoce como Constructor Virtual, su nombre en español es Método de Fábrica, este patron consiste en utilizar una clase constructora abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): es dedicado a la construcción de objetos de un subtipo de un tipo determinado. Intención

Define la interfaz de creación de un cierto tipo de objeto, permitiendo que las subclases decidan qué clase concreta necesitan instanciar. Aplicabilidad Se usa patron Factory Method cuando:

Una clase no puede anticipar la clase de objetos que debe crear. Se necesita que las subclases especifiquen los objetos a ser creados.

Estructura

Las clases principales en este patrón son el creador y el producto. El creador necesita crear instancias de productos, pero el tipo concreto de producto no debe ser forzado en las subclases del creador, porque entonces las posibles subclases del creador deben poder especificar subclases del producto para utilizar.

Patrones de comportamiento.

Los patrones de diseño software de comportamiento son aquellos que están relacionados con algoritmos y con la asignación de responsabilidades a los objetos. Describen no solamente patrones de objetos o de clases, sino que también engloban patrones de comunicación entre ellos. Al igual que los otros tipos de patrones, se pueden clasificar en función de que trabajen con clases (Template Method, Interpreter) u objetos (Chain of Responsability, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor).

La variación de la encapsulación es la base de muchos patrones de comportamiento. Cuando un aspecto de un programa cambia frecuentemente, estos patrones trabajan con un objeto que encapsula dicho aspecto, teniendo que definir por tanto, una clase abstracta que describe la encapsulación del objeto.

A continuación, definiremos algunos de los patrones de diseño software comportamiento más habituales.

Command

El patrón de diseño software de comportamiento Command permite realizar una operación sobre un objeto sin conocer realmente las instrucciones de esta operación ni el receptor real de la misma. Esto se consigue encapsulando la petición como si fuera un objeto, con lo que además se facilita la parametrización de los métodos.

Las principales aplicaciones del patrón de comportamiento Command serían:

- Facilitar la parametrización de las acciones a realizar. - Implementar estructuraas de CallBack, especificando qué órdenes

queremos que se ejecuten efrente a qué situaciones. - Independizar los enventos de "petición" y "ejecución". - Dar un soporte factible a la operación "deshacer". - Desarrollar sistemas utilizando órdenes de alto nivel que se construyen con

primitivas.

Las entidades participantes en el esquema general de este patrón de diseño software de comportamiento son:

Iterator: Interfaz que se usará para recorrer el contenedor y acceder a los objetos o elementos que albergue, de tal modo que no sea necesario conocer los detalles de la estructura, siendo capaces de manejarla de todos modos.

ConcreteIterator: Clase que implementa la interfaz propuesta por el Iterator. Mantendrá la posición actual en el recorrido de la estructura almacenándola en el aggregate, sabiendo así cual será el siguiente objeto en el recorrido.

Aggregate: Es la interfaz que se usará para la fabricación de iteradores. ConcreteAggregate: Implementa la estructura de datos y el método de

fabricación de iteradores que crea un iterador específico para su estructura.

Los principales agentes de este patrón son:

Command: Declara la interface para la ejecucion de la operacion. ConcreteCommand: Define la relación entre el objeto Receiver y una acción,

además de implemetar el método básico Execute() al invocar las operaciones correspondientes en Receiver.

Client: Crea un objeto ConcreteCommand y lo relaciona con su Receiver. Invoker: Envía las solicitudes al objeto Command.

Receiver: Es la clase que gestiona la ejecución de las operaciones asociadas a la solicitud. Cualquier clase puede ser receptora.

Patrones estructurales.

Los patrones de diseño estructurales están enfocados en la gestión de la forma en la que las clases y los objetos se combinan para dar lugar a estructuras más complejas. Al igual que en las otros tipos de patrones, podemos hablar de patrones estructurales asociados a clases (Adapter) y asociados a objetos (Bridge, Composite, Decorator, Facade, Flyweight, Proxy). Los primeros utilizan la herencia mientras que los segundos se basan en la composición. Los patrones estructurales asociados a objetos describen formas de componer los objetos para conseguir nuevas funcionalidades. La flexibilidad de la composición de estos objetos surge de la posibilidad de cambiar dicha composición en tiempo de ejecución, lo que es imposible con la composición estática tradicional de clases.

El patrón Adapter convierte la interfaz de una clase en la que otra necesita, permitiendo que clases con interfaces incompatibles trabajen juntas.

Por lo tanto, el uso de este patrón estructural está indicado cuando se quiere usar una clase ya implementada y su interfaz no es similar con la necesitada o cuando se desea crear una clase reusable que coopere con clases no relacionadas o que tengan interfaces compatibles.

Sin embargo, hay que hacer distinción entre si queremos adaptar un objeto o una clase o interfaz completa. Un adaptador de clase adapta la clase Adaptee a la interfaz de la clase Target, trabajando con una clase adaptada concreta. Por ello, una clase adaptadora no funcionará cuando se desee adaptar, además de la clase objetivo, todas sus subclases. Sin embargo, un adaptador de objetos permite que un único Adapter trabaje con muchos Adaptees. De este modo, el Adapter también puede agregar funcionalidad a todos los Adaptees de una sola vez.

Los participantes de este patrón serían los siguientes:

Client: Es el principal agente en la formación de objetos para la interfaz Target.

Target: Interfaz del dominio específico que usa el Client. Adaptee: Es la interfaz ya existente que necesita adaptarse. Adapter: Es quien adapta la interfaz del Adaptee a la interfaz Target.

Intención

Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo

no podría utilizarla.

Motivacion

Necesitamos reutilizar clases ajenas paranuestro sistema, pero aunque la

funcionalidad de estas clases es la que deseamos, la interfaz no es compatible. Si

no podemos o no queremos modificar las clases a reutilizar, necesitamos hacerlas

compatibles con nuestro sistema.

Aplicabilidad

Se quiere utilizar una clase que llame a un método a través de una interface, pero

quieres utilizarlo con una clase que no implementa ese interface. Modificar esa

clase que implementa el interface no es

una opción por un par de razones:

1. No tienes el código fuente de la clase.

2. La clase es una clase de propósito

general, y es inapropiado para ella

implementar un interface par un

propósito específico.

Se quiere determinar dinámicamente

que métodos de otros objetos llama un

objeto.

Se quiere realizarlo sin que el objeto

llamado tenga conocimientos de la otra clase de objetos.

En el mundo de objetos, la creación de instancias es muy importante, pero tan importante como la creación, es la manera en la que instancias de objetos se comunican entre sí. Un diseño estandarizado y bien pensado puede facilitar mucho

las cosas durante el desarrollo de un sistema grande. En ocasiones nos ponemos a realizar nuestras soluciones a la medida, pero generalmente estas solucionen decaen en construcciones extrañas que serán difíciles de entender para futuros desarrolladores, e incluso para nosotros mismos una vez que dejemos de ver el código.

Los patrones son una herramienta de diseño muy poderosa, pero hay que saberla utilizar. El tiempo y la experiencia suelen ser los mejores acompañantes para un diseñador de software, porque sólo el tiempo le dará el colmillo para utilizar sus herramientas adecuadamente.

Con mucha frecuencia el diseño de un dominio inicia con nociones sumamente intuitivas. Conforme el diseño se va destilando y mejorando, se agregan soluciones específicas de software (como patrones), que lo pueden ir complicando (con el propósito de hacerlo más manejable). Generalmente los patrones estructurales entran en la jugada en etapas medias del diseño, y muchísimas veces son el resultado de refactorización (refactoring).