1 introduccion a los modelos

Introduccin alos patrones

Jordi Pradel i MiquelJos Antonio Raya Martos

PID_00165657

FUOC PID_00165657 Introduccin a los patrones

Ninguna parte de esta publicacin, incluido el diseo general y la cubierta, puede ser copiada,reproducida, almacenada o transmitida de ninguna forma, ni por ningn medio, sea ste elctrico,qumico, mecnico, ptico, grabacin, fotocopia, o cualquier otro, sin la previa autorizacin escritade los titulares del copyright.

FUOC PID_00165657 Introduccin a los patrones

ndice

Introduccin............................................................................................... 5

Objetivos....................................................................................................... 6

1. Concepto de patrn........................................................................... 71.1. Definicin de patrn .................................................................. 71.2. Ventajas del uso de patrones ...................................................... 71.3. Inconvenientes de un uso inadecuado de patrones ................... 81.4. Breve perspectiva histrica ......................................................... 81.5. Estructura de un patrn .............................................................. 91.6. Aplicacin de un patrn ............................................................. 10

1.6.1. Ejemplo .......................................................................... 111.7. Influencia del patrn en el ciclo de vida .................................... 15

2. Tipos de patrones............................................................................... 172.1. Patrones de anlisis ..................................................................... 172.2. Patrones arquitectnicos ............................................................. 182.3. Patrones de asignacin de responsabilidades ............................. 182.4. Patrones de diseo ...................................................................... 192.5. Patrones de programacin .......................................................... 20

3. Frameworks.......................................................................................... 213.1. Ventajas e inconvenientes del uso de frameworks........................ 223.2. Relacin entre frameworks y patrones ......................................... 223.3. Uso de frameworks........................................................................ 223.4. Un ejemplo de framework: Hibernate ......................................... 23

3.4.1. Ventajas .......................................................................... 233.4.2. Inconvenientes ............................................................. 243.4.3. Ejemplo de uso .............................................................. 243.4.4. Hibernate y patrones ..................................................... 26

Resumen....................................................................................................... 27

Ejercicios de autoevaluacin.................................................................. 29

Solucionario................................................................................................ 30

Glosario........................................................................................................ 31

Bibliografa................................................................................................. 32

FUOC PID_00165657 5 Introduccin a los patrones

Introduccin

Los patrones son una herramienta de popularidad creciente en el desarrollode software, ya que nos permiten aplicar las ventajas de la reutilizacin (so-bradamente conocidas en el caso del cdigo) a todos los mbitos del desarrollo(especialmente al anlisis y al diseo). Los patrones nos presentan solucionesya probadas y documentadas que nos pueden ayudar a refinar los artefactosresultantes de las diferentes etapas del ciclo de vida del desarrollo.

Este mdulo introduce al estudiante en el mundo de los patrones aplicadosa las diferentes etapas del ciclo de vida del desarrollo. Primero veremos ques un patrn, daremos una descripcin formal del mismo, estudiaremos suestructura y veremos las ventajas e inconvenientes de la aplicacin de patro-nes al desarrollo de software mediante un pequeo ejemplo. A continuacinharemos una clasificacin de los patrones segn la etapa del ciclo de vida deldesarrollo en que se usan. Veremos algn ejemplo para cada tipo de patrn.

Los frameworks son otra herramienta muy importante en el desarrollo de soft-ware que, al igual que los patrones, nos ayudan a incrementar la calidad delsoftware y, al mismo tiempo, reducir el tiempo de desarrollo. En este mdulohablaremos de los frameworks, de su relacin con los patrones y de cmo nospueden ayudar a aplicar patrones al desarrollo de software.

Hay que tener en cuenta que en este mdulo se utiliza el lenguaje de modela-do UML para la representacin de los diagramas tanto del anlisis como deldiseo.


Objetivos

El objetivo principal de este mdulo es introducir el concepto de patrn y en-tender su aplicacin a lo largo del ciclo de vida del desarrollo del software. Porlo tanto, los objetivos que tienen que haber alcanzado los estudiantes cuandoacaben este mdulo didctico son los siguientes:

1. Entender el concepto de patrn y saber cmo se documenta un patrn.

2. Comprender las principales ventajas del uso de patrones.

3. Aprender a aplicar los patrones a lo largo del ciclo de vida del desarrollo.

4. Conocer una clasificacin de los patrones segn la etapa del ciclo de vidaen que se pueden aplicar.

5. Entender el concepto de framework y su relacin con los patrones.


1. Concepto de patrn

1.1. Definicin de patrn

Segn el Diccionario de uso del espaol de Mara Moliner un patrn es, entreotras acepciones, una "cosa que se toma como modelo o punto de referenciapara medir o valorar otras de la misma especie". Tambin encontramos la ex-presin cortados por el mismo patrn que: "se aplica a cosas y, particularmente,a personas, que se parecen mucho o, sobre todo, que tienen la msima manerade ser (...)".

Gamma, Helm, Johnson y Vlissides [GOF] definen un patrn de la manerasiguiente: "un patrn de diseo da nombre, motiva y explica de manera sis-temtica un diseo general que permite solucionar un problema recurrentede diseo en sistemas orientados a objetos. El patrn describe el problema, lasolucin, cundo se tiene que aplicar la solucin, as como sus consecuencias.Tambin da algunas pistas sobre cmo implementarlo y ejemplos. La solucines una distribucin de objetos y clases que solucionan el problema. La solucinse tiene que personalizar e implementar con el fin de solucionar el problemaen un contexto determinado".

As pues, podramos definir un patrn de la forma siguiente:

Un patrn es una plantilla que utilizamos para solucionar un problemadurante el desarrollo del software con el fin de conseguir que el sistemadesarrollado tenga las mismas buenas cualidades que tienen otros siste-mas donde anteriormente se ha aplicado la misma solucin con xito.

El hecho de abstraer los elementos generales de una solucin concreta paraconseguir esta plantilla es lo que nos permite reutilizar esta solucin que ela-boramos para otro sistema en el sistema que estamos desarrollando.

1.2. Ventajas del uso de patrones

Los patrones no nacen de la inspiracin del momento, sino que son el resul-tado de haber solucionado un mismo problema varias veces y haber compro-bado cules son las consecuencias de aplicar una solucin determinada. Deesta manera, los patrones nos permiten aprovechar la experiencia previa a lahora de resolver nuestro problema. Un patrn nos permite lo siguiente:


Reutilizar las soluciones y aprovechar la experiencia previa de otras perso-nas que han dedicado ms esfuerzo a entender los contextos, las solucio-nes y las consecuencias del que nosotros queremos o podemos dedicar.

Beneficiarnos del conocimiento y la experiencia de estas personas median-te un enfoque metdico.

Comunicar y transmitir nuestra experiencia a otras personas (si definimosnuevos patrones).

Establecer un vocabulario comn para mejorar la comunicacin.

Encapsular conocimiento detallado sobre un tipo de problema y sus solu-ciones asignndole un nombre con la finalidad de poder hacer referenciaa stos fcilmente.

No tener que reinventar una solucin al problema.

1.3. Inconvenientes de un uso inadecuado de patrones

El hecho de disponer de un catlogo de soluciones a problemas generales noevita que tengamos que razonar sobre nuestro desarrollo para entender losproblemas que se nos plantean durante el proceso. As, por ejemplo, duranteel diseo, tenemos que saber cul es nuestro objetivo con el fin de valorar sila aplicacin de una solucin concreta es mejor que otra. Es bastante habitualque cuando alguien empieza a trabajar con patrones, asuma que el hecho deaplicar un patrn proporciona, automticamente, la mejor solucin posible,lo cual no siempre es cierto.

Una vez escogido un patrn que parezca adecuado (es decir, que sea aplicableal contexto donde nos encontramos), tenemos que asegurarnos de haber en-tendido correctamente cul es el problema que quiere solucionar y cules sonlas consecuencias de aplicarlo. Un uso poco cuidadoso del patrn nos puedellevar a una solucin final inadecuada, sea porque el patrn no resuelve elproblema a que nos enfrentbamos o porque no hemos sabido valorar correc-tamente las consecuencias de su aplicacin y los inconvenientes superan lasventajas.

1.4. Breve perspectiva histrica

El trmino patrn proviene del mundo de la arquitectura y el urbanismo. Afinales de los aos setenta, Christopher Alexander, junto con otros autores,publican el libro A Pattern Language: Towns, Buildings, Construction (Center forEnvironmental Structure Series) [AIS]. Este libro contiene unos 250 patrones des-critos en un formato especfico y estandarizado que describen aquellos prin-cipios del diseo, la planificacin y la construccin de edificios que, a lo lar-


go de su experiencia, haban detectado que se mantenan sin variaciones encualquier situacin. De esta manera consiguieron transmitir un conocimientoque, hasta entonces, slo se poda adquirir con aos de experiencia.

La mayora de los patrones de Christopher Alexander siguen la representacinsiguiente:

IF you find yourself in CONTEXT

for example EXAMPLES,

with PROBLEM,

entailing FORCES

THEN for some REASONS,

apply DESIGN FORM AND/OR RULE

to construct SOLUTION

leading to NEW CONTEXT and OTHER PATTERNS

Durante los aos ochenta muchos autores empezaron a trabajar en este campobuscando la manera de trasladar los beneficios de los patrones al desarrollode software. A finales de los ochenta y principios de los noventa personas co-mo Ward Cunningham, Kent Beck, Erich Gamma y otros haban empezado arecoger su experiencia en forma de patrones, publicndola con el fin de esta-blecer lenguajes de patrones que funcionaran como los lenguajes de patronescreados por Alexander.

En 1994 se celebr la primera conferencia PLoP1 dedicada a la discusin y me-jora de la publicabilidad de los patrones de diseo. Este mismo ao, la Banda

de los Cuatro (GOF2) finaliz el trabajo que haba empezado el ao 1990 ypublic el libro Design Patterns. Elements of Reusable Object-Oriented Software[GOF], que documentaba, siguiendo un formato estandarizado, un catlogocon los veintitrs patrones de diseo fundamentales que haban encontradodurante estos aos. El libro se convirti rpidamente en un xito de ventasy muchos arquitectos pudieron reconocer en el catlogo las soluciones a lasque haban llegado a ellos mismos, estableciendo por primera vez un lenguajecomn adoptado de manera mayoritaria por la comunidad de desarrolladores.

1.5. Estructura de un patrn

Los elementos de la estructura de un patrn varan segn los autores, si bienhay un conjunto de elementos mnimos comunes a la mayora de ellos.

Los cinco elementos fundamentales que tiene que tener todo patrnson el nombre, el contexto, el problema, la solucin y las consecuenciasde aplicarlo.

(1)Pattern Languages of Programshttp://hillside.net/plop/pastconferences.html

(2)Erich Gamma, Richard Helm,Ralph Johnson y John Vlissides sonconocidos popularmente como laBanda de los Cuatro o, en ingls,Gang of Four.


El nombre nos permite hacer referencia al patrn cuando documentamosnuestro diseo o cuando lo comentamos con otros desarrolladores. Tambinnos permite aumentar el nivel de abstraccin del proceso de diseo, ya quepodemos pensar en la solucin al problema como un todo.

El contexto nos indica qu condiciones se tienen que dar para que el patrnsea aplicable.

El problema nos indica qu resuelve el patrn. Este problema podra ser unproblema concreto o la identificacin de una estructura problemtica (porejemplo, una estructura de clases poco flexible).

La solucin describe los elementos que forman parte del patrn, as como susrelaciones, responsabilidades y colaboraciones. La solucin no es una estruc-tura concreta, sino que, como hemos indicado anteriormente, es como unaplantilla que podemos aplicar a nuestro problema. Algunos patrones presen-tan varias variantes de una misma solucin.

Las consecuencias son los resultados y los compromisos derivados de la apli-cacin del patrn. Es muy importante que las tengamos en cuenta a la horade evaluar nuestro diseo, ya que es lo que nos permite entender realmenteel coste y los beneficios de la aplicacin del patrn.

1.6. Aplicacin de un patrn

Cmo sabemos cundo tenemos que aplicar un patrn? Seguiremos el pro-ceso siguiente:

1) Identificar el problema que queremos resolver. Lo primero que hay que te-ner claro es cul es el problema que estamos intentando resolver. Es posibleque tengamos que descomponer un problema complejo en diferentes subpro-blemas para tratarlos de manera individual.

2) Plantear posibles soluciones al problema. Estas soluciones las plantearemosde manera independiente al catlogo de patrones disponible. El hecho de plan-tear las soluciones antes de consultar el catlogo nos permitir tener un cono-cimiento ms profundo del problema en el momento de seleccionar los pa-trones del catlogo.

3) Identificar aquellos patrones que resuelven el problema que hemos identi-ficado. Habr que acudir a nuestro catlogo de patrones buscando qu patro-nes podran resolver el problema que nos hemos planteado.

4) Descartar aquellos patrones cuyo contexto no sea compatible con el con-texto en que nos encontramos. Para que la aplicacin de un patrn sea benefi-ciosa, nos tenemos que asegurar de que no slo soluciona el problema que nosinteresa, sino que, adems, lo hace en un contexto compatible con el nuestro.


Por ejemplo, no nos sirve de nada un patrn arquitectnico que nos ayudaa estructurar una aplicacin cuando la arquitectura es centralizada si nuestraarquitectura es distribuida.

5) Valorar las consecuencias de cada solucin. De cada una de las solucionesque hemos preseleccionado, nos tenemos que plantear las consecuencias desu aplicacin. Con respecto a las soluciones basadas en patrones, tenemos laventaja de que las consecuencias generales han sido estudiadas y documenta-das previamente formando parte de la descripcin del patrn. Para el resto desoluciones, tendremos que estudiar las consecuencias con el riesgo de hacerun estudio incompleto y sin la ayuda de experiencia previa. Finalmente, si unpatrn tiene varias variantes, tenemos que valorar las consecuencias de cadauna de stas.

6) Escoger y aplicar una solucin. Una vez valoradas las consecuencias, yadisponemos de un criterio bien fundamentado para escoger la solucin msadecuada y, por lo tanto, podemos proceder a su aplicacin.

Como se puede ver, el proceso de aplicacin de un patrn no se dife-rencia sustancialmente de cualquier proceso de toma de decisiones anteun problema. En el caso de los patrones, sin embargo, nos ahorramosel estudio de las variantes, de sus consecuencias, y tenemos una gua ala hora de elaborar una solucin al problema.

1.6.1. Ejemplo

Supongamos que, diseando nuestro sistema, nos encontramos con un requi-sito segn el cual durante el alta de un usuario hay que enviar una notifica-cin por correo electrnico a la direccin que el usuario indique. Aplicando elprincipio de inversin de dependencias, empezamos a disear esta clase iden-tificando las operaciones que necesitamos:

Ved tambin

Podis ver el principio de in-versin de dependencias enel apartado 2.7 del mdulo 2,"Catlogo de patrones".


Este problema ya lo tuvimos que resolver en el pasado en otro proyecto y nosplanteamos que quizs podemos reutilizar la solucin que obtuvimos:

Nos encontramos, sin embargo, con un problema: las operaciones que quere-mos utilizar no son exactamente las mismas que ofrece la clase que queremosreutilizar.

Ante este problema se nos ocurren dos soluciones alternativas:

a) Implementar la clase ControladorAltaUsuario utilizando las operacionesque le ofrece la clase MailMessage, de tal manera que el controlador dependadirectamente de MailMessage.

b) Modificar la clase MailMessage para aadir las operaciones de ServidorCo-rreo. De esta manera, se reutiliza la clase, pero cambiando su implementacin.

Hay alguna otra manera de solucionar este problema? Consultamos el cat-logo y encontramos un patrn que resuelve nuestro problema:

Nombre: Adaptador

Contexto: existe una clase que nos proporciona una funcionalidad quequeremos aprovechar.

Problema: las operaciones que nos ofrece la clase que queremos reutilizarno son exactamente las que queremos utilizar.

Solucin: aadir una clase Adaptador que ofrezca las operaciones que es-pera la clase Cliente, pero que delegue la implementacin a la clase quequeremos reutilizar:


Consecuencias: Permite al Adaptador redefinir parte del comportamiento de Adaptada.

Un mismo Adaptador puede funcionar con diferentes subclases de laclase Adaptada. El Adaptador tambin puede aadir funcionalidad atoda la jerarqua de herencia al mismo tiempo.

Podemos sustituir la clase Adaptada por otra implementacin desarro-llando un nuevo Adaptador.

Una vez hemos visto que hay un patrn que parece, a priori, aplicable a nues-tro problema, lo primero que tenemos que hacer es verificar que el contextodel patrn se adecua a nuestra situacin. Estamos ante la situacin en la que"existe una clase que nos proporciona una funcionalidad que queremos apro-vechar"? En este caso, es bastante claro que s.

El paso siguiente ser estudiar las consecuencias de las tres soluciones que he-mos encontrado:

a) Modificar la clase ControladorAltaUsuario.

Aadimos una dependencia hacia la clase MailMessage de manera que sila queremos sustituir por otra implementacin, tendremos que volver amodificar ControladorAltaUsuario.

Como no estamos aplicando un patrn, no tenemos experiencia que nospueda garantizar que esta solucin no tenga consecuencias de las cualesen este momento no somos conscientes.

b) Modificar la clase MailMessage.

Perdemos la capacidad de reutilizacin de la clase, ya que no compartimosel cdigo entre los dos sistemas donde hemos utilizado MailMessage. Porlo tanto, en lo sucesivo, tendremos que mantener dos versiones diferentes


de la clase MailMessage y las mejoras que introduzcamos en un sistemano se podrn trasladar automticamente al otro.

Como en el caso anterior, podra haber consecuencias que no hayamostenido en cuenta.

c) Adaptador.

La solucin es ms compleja, ya que introduce una interfaz y una clasenueva.

Las consecuencias ya documentadas del patrn: reutilizamos la implemen-tacin que ya tenemos sin cerrarnos la posibilidad de sustituirla por otraen el futuro. Podemos redefinir la funcionalidad de la clase con el fin deconseguir que nos ofrezca exactamente lo que queramos.

Finalmente, tenemos que escoger una de las soluciones. Tenemos que aplicarel patrn? Depende. Para escoger la solucin ms adecuada nos tenemos quehacer preguntas como:

a) Es preciso que nuestro sistema sea independiente de la clase que reutiliza-remos? Hay muchas clases que tengan la necesidad de enviar mensajes de co-rreo por medio de esta clase? Si reutilizamos MailMessage directamente modi-ficando ControladorAltaUsuario para que utilice las operaciones actuales, uncambio en estas operaciones (que podra ser provocado por la otra aplicacin)afectar a nuestro sistema y, posiblemente, habr que modificarlo.

b) Tenemos que mantener la clase reutilizada independiente de nuestro sis-tema? Si aadimos nuestras operaciones a MailMessage, el mantenimiento deesta clase ser ms complicado, ya que tendremos que mantener dos versionesde una misma clase ligeramente diferentes.

La solucin que escogeremos depender de las respuestas a estas preguntas.Supondremos que queremos mantener nuestro sistema y la clase MailMessageindependientes entre s. En este caso, aplicaremos el patrn Adaptador con elresultado siguiente:


La clase cliente del patrn es ControladorAltaUsuario, que es quien utilizar laclase adaptada MailMessage. Para adaptar esta clase a la interfaz esperada (Ser-vidorCorreo), hemos creado el adaptador AdaptadorServidorCorreo; en estecaso, hemos modificado ligeramente la estructura del patrn original, ya queel adaptador implementa una interfaz en lugar de extender una clase.

1.7. Influencia del patrn en el ciclo de vida

La primera aplicacin de los patrones que se hizo en el campo de la ingenieradel software fue durante la etapa de diseo. Eran, pues, patrones que docu-mentaban soluciones de diseo a problemas de diseo; de hecho, an hoy enda, sta es la etapa del ciclo de vida donde es ms comn el uso de patronesy donde encontraremos el mayor nmero de patrones.

Los patrones son aplicables a cualquier tarea donde se puedan identifi-car soluciones genricas a un cierto problema. En concreto, a todas lasetapas del ciclo de vida de la ingeniera del software se puede aplicarel concepto.

Algunos de los casos en los que se han aplicado los patrones con xito sonlos siguientes:

Modelosdeanlisis. Durante la etapa de anlisis nos encontramos conproblemas consistentes en decidir qu modelo representa mejor los con-ceptos y restricciones del mundo real que estamos modelando. Hay mu-chos puntos en los que nos enfrentamos a problemas de modelizacin queya han sido resueltos con anterioridad y los llamados patrones de anlisisnos pueden ayudar. Algunos ejemplos pueden ser la representacin de lasasociaciones de las cuales queremos conocer informacin histrica o lamodelizacin de sistemas que trabajen con reglas de contabilidad.

Ejemplo

Recordemos que el mbito ori-ginal de los patrones no era nisiquiera la ingeniera del soft-ware.


Arquitecturadesoftware. A modo de primeros pasos en la etapa de dise-o (o como etapa diferenciada segn el ciclo de vida que se siga) habr quedefinir la arquitectura global del software que se desarrollar. En este con-texto tambin habr que solucionar ciertos problemas con posibles solu-ciones genricas y se han documentado varios patrones que llamamos ar-quitectnicos que nos pueden ser tiles. Por ejemplo, el patrn de arquitec-tura en capas nos propone una manera de organizar internamente nuestraarquitectura para minimizar la complejidad del sistema resultante.

Asignacinderesponsabilidades. Durante el diseo (sobre todo en susfases iniciales) tenemos que llevar a cabo la asignacin de responsabilida-des a las clases que forman el sistema. Por ejemplo, el patrn Creador nosda un criterio general para decidir qu clase tendr la responsabilidad decrear instancias de otra clase.

Diseodesoftware. Durante la etapa de diseo es cuando los patronesson ms utilizados. Hay un amplio abanico de patrones de diseo documen-tados que nos permiten solucionar problemas de diseo frecuentes consoluciones comunes ya conocidas. Por ejemplo, tal como hemos visto an-teriormente, el patrn Adaptador nos da una solucin al problema con-creto de reutilizar una clase sin utilizar exactamente la interfaz que ofrece.

Programacin. Una vez fijada una tecnologa y un lenguaje de programa-cin, encontraremos problemas que requieren soluciones que no puedenser genricas al diseo o a etapas anteriores, sino que han sido originadaspor el lenguaje de programacin escogido y, por lo tanto, dependen de l.

Los llamados patrones de programacin3 son, pues, patrones que nos dansoluciones especficas a un lenguaje de programacin. Como ejemplo, haypatrones que nos guan en el uso de interfaces en Java.

(3)En ingls, idiom.


2. Tipos de patrones

Hay muchas posibles taxonomas de los patrones de la ingeniera del softwa-re, cada una segn criterios diferentes. Nosotros tipificaremos los patrones de-pendiendo de la etapa del ciclo de vida en que se utilizan, ya que es una de lastipificaciones ms aceptadas y, al mismo tiempo, tiles.

ste no se considerar, sin embargo, un criterio estricto, ya que la fronteraentre una etapa y otra no siempre es clara. As, por ejemplo, algunos patronesque nosotros clasificaremos como de arquitectura son considerados por mu-chos autores patrones de diseo.

Distinguiremos los tipos de patrones siguientes:

Patrones de anlisis Patrones arquitectnicos Patrones de asignacin de responsabilidades Patrones de diseo Patrones de programacin

En esta asignatura haremos hincapi en los patrones de asignacin de respon-sabilidades y de diseo, pero tambin veremos algunos patrones de anlisis yde arquitectura.

2.1. Patrones de anlisis

Los patrones de anlisis son aquellos patrones que documentan solu-ciones aplicables durante la realizacin del diagrama esttico de anli-sis para resolver los problemas que surgen: nos proporcionan manerasprobadas de representar conceptos generales del mundo real en un dia-grama esttico del anlisis.

Lo podemos ver ms claro con un ejemplo: supongamos que estamos desarrollando unsistema de gestin de una estacin meteorolgica. En el diagrama esttico de anlisis te-nemos una clase Termmetro que tendr que tener la informacin sobre la temperaturamedida. Podemos pensar en utilizar un atributo de tipo entero que represente este dato,pero nos faltara una informacin muy importante para interpretar el valor de este atri-buto: en qu escala est representada esta temperatura? Qu quiere decir una tempera-tura de 100? Son grados centgrados, Fahrenheit, Kelvin? As pues vemos que el atributoentero es claramente insuficiente.


El patrn de anlisis Cantidad [FOW] nos permite solucionar este tipo de pro-blema: tenemos que aadir una clase Temperatura que tenga la responsabili-dad de saber los grados y la escala en que estn.

2.2. Patrones arquitectnicos

Los patrones arquitectnicos son aquellos que se aplican en la defini-cin de la arquitectura de software y que, por lo tanto, resuelven pro-blemas que afectarn al conjunto del diseo del sistema.

Por ejemplo, en la definicin inicial de la arquitectura de nuestro sistema nos encontra-mos con el problema de que su complejidad nos obliga a trabajar a diferentes niveles deabstraccin. Queremos que los componentes de presentacin no tengan que interactuardirectamente con los servicios tcnicos a un nivel bajo como la base de datos.

El patrn arquitectnico en capas soluciona este problema proponiendo quecada componente se asigne a una capa con un cierto nivel de abstraccin:presentacin, dominio y servicios tcnicos, de tal manera que cada capa slodepende de la siguiente. As, los componentes de presentacin trabajarn asu propio nivel de abstraccin y delegarn cualquier otra tarea en la capa dedominio.

2.3. Patrones de asignacin de responsabilidades

Los patrones de asignacin de responsabilidades se utilizan durante laetapa de diseo. Pero este tipo de patrones resuelve problemas duranteuna tarea muy concreta del diseo orientado a objetos: la asignacin deresponsabilidades a las clases software.

Este tipo de patrones de diseo se diferencia claramente de los patrones de di-seo generales en que los problemas que resuelven no son especficos para unasituacin o sistema concreto, sino que son problemas comunes a cualquierasignacin de responsabilidades. Por lo tanto, estos patrones, en realidad, con-sisten en pautas que nos ayuden a hacer una asignacin de responsabilidadessiguiendo los principios de diseo ms bsicos.

Todos los patrones de asignacin de responsabilidades comparten una estruc-tura muy parecida. Responden a la pregunta: "Qu clase tendr que tener laresponsabilidad R para que el diseo siga unos principios de diseo slidos?".Cuando iniciamos el diseo, partiendo del modelo conceptual del anlisis,creamos un modelo de clases del diseo. En este momento, empezamos a asig-nar responsabilidades que colaborarn para implementar el comportamientodel sistema.

Ejemplo

Larman, autor de la familia depatrones GRASP [LAR], que esel ejemplo ms importante depatrones de asignacin de res-ponsabilidades, documenta losprincipios de diseo en formade patrones. As, por ejemplo,para Larman existen los patro-nes Alta cohesin y Bajo aco-plamiento.


Supongamos que tenemos el modelo parcial siguiente:

Qu clase tendr la responsabilidad de calcular el total de una factura? Segnel patrn de asignacin de responsabilidades Experto, ser la clase que tengala informacin necesaria para hacer este clculo. En nuestro ejemplo, la claseFactura tiene la informacin de las lneas de factura que forman una factura yser la experta escogida. Para calcular el total de la factura, sin embargo, estaexperta tendr que sumar el total de cada lnea. Qu clase tendr la respon-sabilidad de calcular este total de lnea? De nuevo, segn el patrn Experto, laclase que tiene la informacin necesaria es LineaFactura. Por lo tanto, nuestromodelo del diseo queda de la manera siguiente:

2.4. Patrones de diseo

Los patrones de diseo son aquellos que se aplican para resolver proble-mas concretos de diseo que no afectarn al conjunto de la arquitecturadel sistema.

No clasificaremos en este grupo los patrones de asignacin de responsabilidad,aunque tambin se utilizan en la etapa de diseo.

El ejemplo que hemos visto anteriormente de aplicacin del patrn de diseoAdaptador es un buen ejemplo de aplicacin de un patrn de este grupo.

Ved tambin

Podis ver el ejemplo del pa-trn de diseo Adaptador enel apartado 1.6.1 de este m-dulo.


2.5. Patrones de programacin

Un patrn de programacin es un patrn que describe cmo se pue-den implementar ciertas tareas utilizando un lenguaje de programacinconcreto.

Por lo tanto, los patrones de programacin resuelven problemas que o bienson especficos de un lenguaje de programacin o bien son genricos, perotienen una buena solucin conocida que es especfica de un lenguaje de pro-gramacin.

Por ejemplo, durante el anlisis y diseo hemos utilizado en nuestros modelosuna enumeracin llamada Colores que puede tomar los valores Rojo, Azul yVerde. Cuando implementamos el sistema en Java (versin 1.4) nos encontra-mos con el problema de que no tiene soporte para enumeraciones. El patrnde programacin "Enumeraciones en Java" nos permite resolver este problemacreando una clase Color con constructor protegido que tendr tres atributosestticos, uno para cada valor posible:

public class Color {

public static final Color ROJO = new Color();

public static final Color VERDE = new Color();

public static final Color AZUL = new Color();

protected Color() {}

}

Ahora podremos utilizar esta clase de la manera siguiente:

if(color == Color.ROJO)

...

En la asignatura nos centraremos en los patrones de ms alto nivel y, por lotanto, no veremos los patrones de programacin.


3. Frameworks

Un framework es un conjunto de clases predefinidas que tenemos queespecializar y/o instanciar para implementar una aplicacin o subsiste-ma ahorrando tiempo y errores. El framework nos ofrece una funciona-lidad genrica ya implementada y probada que nos permite centrarnosen lo especfico de nuestra aplicacin.

No debemos confundir un framework con una biblioteca4 de clases. Un frame-work es un tipo especial de biblioteca que define el diseo de la aplicacin quelo utilizar.

(4)En ingls, library.

Un framework comparte el control de la ejecucin con las clases que lo uti-

lizan siguiendo el "principio de Hollywood5": el framework implementar elcomportamiento genrico del sistema y llamar a nuestras clases en aquellospuntos donde haya que definir un comportamiento especfico.

Como un framework tiene que llamar a nuestras clases, definir la interfaz queespera que tengan estas clases. As, para utilizar un framework tendremos queimplementar el comportamiento especfico de nuestra aplicacin respetandolas interfaces y colaboraciones definidas en l.

(5)En ingls, "Don't call us. We'll callyou" (no hace falta que nos llames,nosotros te llamaremos).


En este caso, por ejemplo, nuestra aplicacin utiliza un framework mediante la herencia(de la clase Cc hacia C2) y la implementacin de una interfaz (Ca implementa l1) que esutilizada por el framework (por C2 y C3). De esta manera, el framework llevar el controlde la ejecucin llamando a las clases Ca y Cc de nuestra aplicacin cuando convenga.

3.1. Ventajas e inconvenientes del uso de frameworks

Cuando utilizamos un framework, reutilizamos un diseo ahorrando tiempo yesfuerzo. Por otra parte, dado que el control es compartido entre la aplicaciny el propio framework, un framework puede contener mucha ms funcionalidadque una biblioteca tradicional.

Otra ventaja del uso de frameworks es que nos dan una implementacin parcialdel diseo que queremos reutilizar.

El principal inconveniente del uso de framework es la necesidad de un procesoinicial de aprendizaje. Para reutilizar el diseo del framework, primero lo tene-mos que entender completamente.

3.2. Relacin entre frameworks y patrones

La principal diferencia entre un patrn y un framework es que el framework esun elemento de software, mientras que el patrn es un elemento de conoci-miento sobre el software. Por lo tanto, la aplicacin de un patrn partir deuna idea, pero no de una implementacin; de hecho, el patrn se tendr queimplementar desde cero adaptndolo al caso concreto. En cambio, la aplica-cin de un framework partir de un conjunto de clases ya implementadas cuyafuncionalidad extenderemos sin modificarlas.

Desde el punto de vista de los patrones, un framework puede implementar paranosotros un conjunto de patrones. Es decir, que el diseo que reutilizamospuede estar basado en patrones reconocidos igual que si lo hubiramos hechonosotros. En este caso, entender los patrones en los cuales se basa un frameworknos ayudar a entender su funcionamiento y a poder utilizarlo eficazmente.

3.3. Uso de frameworks

El uso de frameworks afecta a nuestro proceso de desarrollo de software.Dado que estamos reutilizando un diseo previo, tenemos que acomo-dar nuestro sistema al diseo que queremos reutilizar.

Aunque eso pueda parecer una limitacin, la capacidad de plantear nuestrodiseo en trminos de un diseo aplicado previamente con xito por los crea-dores del framework nos ayudar a garantizar la calidad de este diseo.


3.4. Un ejemplo de framework: Hibernate

Cuando desarrollamos un sistema que almacena sus datos en una base de datosrelacional, es habitual encontrarse con el problema de sincronizar los datosde los objetos que tenemos en memoria con los datos de la base de datosrelacional. Este problema es la causa de que muchas aplicaciones informticasno puedan sacar todo el provecho de la tecnologa orientada a objetos, ya quetienen que trabajar directamente con el modelo de datos relacional.

Hibernate es un framework de persistencia de objetos Java a bases de datos re-lacionales que nos permite aadir, de manera transparente, la capacidad depersistencia a las clases que diseemos. Esta estructura nos ofrece una seriede mecanismos por los cuales podemos trabajar con objetos persistentes de labase de datos desde un punto de vista orientado a objetos con soporte, por lotanto, de conceptos como asociaciones, herencia, polimorfismo, composiciny uso de colecciones. Hibernate tambin define un lenguaje de consultas pro-pio denominado Hibernate query language, que nos permite hacer consultas conla capacidad de SQL con algunas extensiones para soportar el uso de objetos.

Para desarrollar una aplicacin con Hibernate es imprescindible haber hechoel modelo relacional y el diseo de las clases. Partiendo de este punto defini-remos la correspondencia entre clases Java y tablas del modelo relacionalesmediante un lenguaje basado en XML. Entonces slo hay que configurar c-mo se conectar a la base de datos a fin de que Hibernate se ocupe de maneratransparente de sincronizar el modelo de datos orientado a objetos en memo-ria y el modelo relacional del servidor de base de datos.

3.4.1. Ventajas

Permite trabajar sobre bases de datos relacionales utilizando toda la po-tencia de la orientacin a objetos. Esta caracterstica propicia reducir lacomplejidad del desarrollo con el consiguiente aumento de productividad,fiabilidad y mantenibilidad.

Incluye numerosas mejoras de rendimiento respecto de otras solucionescomo la carga de datos bajo peticin (que evita cargar datos que finalmenteno se consulten), la optimizacin transparente de consultas SQL (gracias

al conocimiento que tiene el framework de los diferentes SGBDR6) o el uso

de una memoria cach7.

Permite cambiar de dialecto SQL (y, por lo tanto, de fabricante de bases dedatos) sin tener que modificar el cdigo.

(6)Sistema Gestor de Bases de Da-tos Relacionales.

(7)en ingls, cache.


3.4.2. Inconvenientes

El principal inconveniente de Hibernate es la necesidad de un proceso inicialde aprendizaje tanto con respecto a su modelo de programacin como a lainterfaz especfica que nos ofrece.

3.4.3. Ejemplo de uso

Queremos disear una aplicacin de gestin de datos sobre personas con elsiguiente diseo de clases del dominio:

Nuestro modelo relacional es muy sencillo:

create table Persona (

nombre varchar (32),

direccin varchar (80) not null,

email varchar(80) not null,

primary key (nombre)

)

Para adaptar nuestro diseo a Hibernate tenemos que definir la corresponden-cia entre clases i tablas mediante el documento XML siguiente:


A continuacin habr que modificar el comportamiento del controlador a finde que utilice el framework:

public class ControladorGestionPersonas {

public void altaPersona(String nombre, String

direccin, String email) {

Session session = HibernateUtil.currentSession();

Transaction tx = session.beginTransaction();

Persona p = new Persona();

p.setDireccion(direccion);

p.setEmail(email);

p.setNombre(nombre);

session.save(p);

tx.commit();

HibernateUtil.closeSession();

}

public Iterator consultaPersonas() {

List resultado = new LinkedList;

Session session = HibernateUtil.currentSession();

Transaction tx = session.beginTransaction();

Query query = session.createQuery("from Persona");

for (Iterator it = query.iterate(); it.hasNext();) {

Persona p = (Persona) it.next();

resultado.add(p);

}

return resultado.iterator();

}

Como se puede ver, la clase Persona no har falta modificarla, ya que Hiber-nate se encarga de la persistencia de manera transparente llamando a las ope-raciones de Persona que haga falta. Con respecto al controlador, aunque tieneuna parte de cdigo especfica para la persistencia, la proporcin de esta partecon respecto al conjunto del cdigo es muy pequea.

Como hemos visto, el uso de Hibernate es mucho menos intrusivo que el uso,por ejemplo, de sentencias SQL dentro del cdigo. Por otra parte, nos permitetrabajar en un nivel de abstraccin mucho ms alto y nos evita tener que estarpendientes de liberar recursos una vez utilizados, obtener conexiones, etc.


3.4.4. Hibernate y patrones

Hay que destacar que el propio Hibernate utiliza patrones de diseo en suconstruccin, como, por ejemplo, el patrn Representante. Adems, la comu-nidad de usuarios de esta estructura ha definido todo un catlogo de patronesde programacin especficos para Hibernate.

As pues, queda patente que la relacin entre un framework y los patrones esdoble: por una parte, ayudan a que el framework est mejor diseado y, por laotra, el uso del framework genera un nuevo catlogo de patrones propio.


Resumen

Los patrones se han convertido en una herramienta muy importante en el de-sarrollo de software porque nos permiten obtener las ventajas de la reutiliza-cin en contextos diferentes a la reutilizacin de cdigo.

Se ha estudiado el concepto general de patrn, cmo se documenta un patrny cmo se puede aplicar esta herramienta a las diferentes etapas del ciclo devida del desarrollo. Hemos visto las ventajas y los peligros derivados de unmal uso de los mismos.

Tambin se ha visto una clasificacin de patrones segn la etapa del ciclo devida del desarrollo en el que son aplicables. Esta clasificacin nos ser til paralocalizar rpidamente y relacionar entre s los diferentes patrones del catlogoque se recoger en el mdulo correspondiente.

Finalmente, hemos visto el concepto de framework y su relacin con el anlisisy diseo orientados a objetos con patrones, as como un ejemplo prctico deutilizacin del framework Hibernate.


Ejercicios de autoevaluacin

1)Enumerad las ventajas del uso de patrones.

2)Indicad dos causas por las cuales el uso de un patrn se puede considerar inadecuado.

3)El uso de patrones es exclusivo de la ingeniera del software?

4)Cules son los elementos fundamentales del framework de un patrn?

5)Qu aporta el uso de patrones al proceso de toma de decisiones durante, por ejemplo,el diseo de software?

6)Qu diferencia hay entre un patrn de anlisis y un patrn de diseo?

7)Explicad en qu consiste el llamado "principio de Hollywood".

8)Indicad una ventaja y un inconveniente del uso de frameworks.


Solucionario

1)Reutilizar soluciones previas, beneficiarnos del conocimiento de otros, comunicar y trans-mitir la experiencia, establecer un vocabulario comn, encapsular conocimiento y no tenerque reinventar una solucin a un problema.

2)Porque no resuelva el problema al cual nos enfrentbamos o porque no hemos valoradocorrectamente las consecuencias de su utilizacin y los inconvenientes superan a las ventajas.

3)No; de hecho, el trmino patrn proviene del mundo de la arquitectura y el urbanismo.

4)Nombre, contexto, problema, solucin y consecuencias de aplicacin.

5)El proceso viene a ser el mismo, pero nos ahorramos el estudio de las consecuencias de laaplicacin del patrn y tenemos una gua a la hora de elaborar una solucin para el problema.

6)La diferencia fundamental reside en la etapa del ciclo de vida del desarrollo donde seutilizan uno y otro.

7)Este principio hace referencia al hecho de que el control de ejecucin del sistema es com-partido entre un framework y la aplicacin que lo utiliza. Consiste en el hecho de que elframework es quien llama a nuestras clases en aquellos puntos donde haya que definir uncomportamiento especfico.

8)Una ventaja es que nos dan una implementacin parcial del diseo que queremos reuti-lizar. Un inconveniente es que, para reutilizar este diseo, primero lo tenemos que entendercompletamente y, por lo tanto, es necesario un periodo inicial de aprendizaje.


Glosario

adaptador m Patrn de diseo que nos permite reutilizar una clase previamente existenteempleando un conjunto de operaciones diferente al que la clase proporciona.

arquitectura en capas f Patrn arquitectnico que nos propone organizar nuestra arqui-tectura en un conjunto de capas que trabajan a diferentes niveles de abstraccin.

asignacin de responsabilidades f Tarea de diseo en la que se decide qu clase se tieneque encargar de cada responsabilidad dentro de un sistema orientado a objetos.

biblioteca de clases f Conjunto de clases reutilizables y relacionadas entre s.

cantidad f Patrn de anlisis que permite modelar una cantidad indicando la escala enla que est medida.

ciclo de vida m Conjunto de etapas del desarrollo de software por las cuales se pasa enun orden establecido previamente.

consecuencias de aplicacin de un patrn f pl Elemento de la descripcin de unpatrn que indica los resultados y compromisos derivados de la aplicacin del patrn.

contexto m Elemento de la descripcin de un patrn que indica qu condiciones se tienenque dar para que el patrn sea aplicable.

diagrama esttico de anlisis m Diagrama de clases que representa los conceptos delmundo real que nuestro sistema conoce y manipula.sin. modelo conceptual

experto m Patrn de asignacin de responsabilidades que propone asignar una responsa-bilidad a la clase que tenga la informacin necesaria para llevarla a cabo.

framework m Conjunto de clases que tenemos que especializar y/o instanciar para imple-mentar una aplicacin o subsistema.

GRASP m Principal familia de patrones de asignacin de responsabilidades documentadapor Craig Larman.

Hibernate m Framework de persistencia de objetos Java en bases de datos relacionales.

modelo conceptual m sin. diagrama esttico de anlisis

patrn de programacin m Patrn especfico para una tecnologa concreta, tpicamenteun lenguaje de programacin.

patrn m Plantilla que utilizamos para solucionar un problema durante el desarrollo desoftware.

patrn de programacin m sin. modismo


Bibliografa

[AIS] Alexander, C. y otros (1977). A Pattern Language: Towns, Buildings, Construction.Nueva York: Oxford University Press.

[GOF] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. (1995). Design Patterns: Elementsof Reusable Object-Oriented Software. Massachusetts: Addison Wesley Professional.

[FOW] Fowler, M. (1997). Analysis Patterns: Reusable Object Models. Massachusetts: AddisonWesley Professional.

[LAR] Larman, C. (2003). UML Y PATRONES. Una introduccin al anlisis y diseo orientadoa objetos y al proceso unificado. Madrid: Prentice Hall.

[POSA] Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M. (1996).Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, Inglaterra: John Wiley& Sons Ltd.

Introduccin a los patronesIntroduccinObjetivosndice1. Concepto de patrn1.1. Definicin de patrn1.2. Ventajas del uso de patrones1.3. Inconvenientes de un uso inadecuado de patrones1.4. Breve perspectiva histrica1.5. Estructura de un patrn1.6. Aplicacin de un patrn1.6.1. Ejemplo

1.7. Influencia del patrn en el ciclo de vida

2. Tipos de patrones2.1. Patrones de anlisis2.2. Patrones arquitectnicos2.3. Patrones de asignacin de responsabilidades2.4. Patrones de diseo2.5. Patrones de programacin

3. Frameworks3.1. Ventajas e inconvenientes del uso de frameworks3.2. Relacin entre frameworks y patrones3.3. Uso de frameworks3.4. Un ejemplo de framework: Hibernate3.4.1. Ventajas3.4.2. Inconvenientes3.4.3. Ejemplo de uso3.4.4. Hibernate y patrones

ResumenEjercicios de autoevaluacinSolucionarioGlosarioBibliografa

1 introduccion a los modelos

Documents