Desarrollo de Software Basado en Reutilizacion

Desarrollo desoftware basadoen reutilizacin

Macario Polo Usaola

PID_00184467

CC-BY-NC-ND PID_00184467 Desarrollo de software basado en reutilizacin

Los textos e imgenes publicados en esta obra estn sujetos excepto que se indique lo contrario a una licencia deReconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 Espaa de Creative Commons. Podis copiarlos, distribuirlosy transmitirlos pblicamente siempre que citis el autor y la fuente (FUOC. Fundacin para la Universitat Oberta de Catalunya),no hagis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es


ndice

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

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

1. Introduccin a la reutilizacin...................................................... 71.1. Un poco de historia .................................................................... 91.2. Reutilizacin de conocimiento: patrones de diseo ................... 121.3. Beneficios y costes de la reutilizacin ........................................ 13

1.3.1. El impacto positivo de la reutilizacin en el procesode mantenimiento ......................................................... 14

1.3.2. Los costes de reutilizar .................................................. 15

2. Reutilizacin en diseo de software orientado a objetos........ 172.1. Introduccin ................................................................................ 182.2. Abstraccin, encapsulacin y ocultamiento ............................... 212.3. Herencia y polimorfismo ............................................................ 23

3. Reutilizacin a pequea escala: soluciones tcnicas dereutilizacin........................................................................................ 263.1. Introduccin ................................................................................ 263.2. Una historia ilustrativa ............................................................... 263.3. Libreras ....................................................................................... 28

3.3.1. Libreras de enlace esttico ............................................ 293.3.2. Libreras de enlace dinmico ......................................... 293.3.3. Otras libreras ................................................................. 31

3.4. Clases ........................................................................................... 313.5. Patrones arquitectnicos ............................................................. 32

3.5.1. Arquitectura multicapa .................................................. 333.5.2. Arquitectura de pipes and filters (tuberas y filtros) ......... 343.5.3. Arquitecturas cliente-servidor ........................................ 353.5.4. Arquitecturas P2P (peer-to-peer, de igual a igual) ............ 36

3.6. Patrones de diseo ...................................................................... 373.6.1. Patrones de Gamma ...................................................... 383.6.2. Patrones de Larman ....................................................... 473.6.3. El patrn modelo-vista-controlador .............................. 52

3.7. Componentes .............................................................................. 523.7.1. Ingeniera del software basada en componentes ........... 533.7.2. Componentes y clases ................................................... 583.7.3. Desarrollo de componentes ........................................... 59

3.8. Frameworks.................................................................................... 59


3.8.1. Framework para la implementacin de interfaces deusuario ............................................................................ 60

3.8.2. Frameworks de persistencia para mapeo objeto-relacional ........................................................................ 61

3.8.3. Framework para el desarrollo de aplicaciones web ......... 633.9. Servicios ....................................................................................... 65

3.9.1. Introduccin a los servicios web ................................... 653.9.2. Desarrollo de servicios web ........................................... 663.9.3. Desarrollo de clientes .................................................... 683.9.4. Tipos de datos ................................................................ 69

4. Reutilizacin a gran escala / Soluciones metodolgicas dereutilizacin........................................................................................ 704.1. Introduccin ................................................................................ 704.2. Ingeniera del software dirigida por modelos ............................. 70

4.2.1. Diferentes aproximaciones: metamodelos propios ymetamodelos estndares ................................................ 72

4.2.2. UML como lenguaje de modelado en MDE .................. 764.2.3. Soporte automtico ........................................................ 80

4.3. Lenguajes de dominio especfico (DSL: domain-specificlanguages) ..................................................................................... 824.3.1. Definicin de DSL ......................................................... 83

4.4. Lnea de producto de software ................................................... 844.4.1. Ingeniera de dominio ................................................... 864.4.2. Ingeniera del software para lneas de producto

basada en UML .............................................................. 924.5. Programacin generativa ............................................................ 93

4.5.1. Ingeniera de dominio ................................................... 954.5.2. Tecnologas ..................................................................... 96

4.6. Fbricas de software .................................................................... 102

Resumen....................................................................................................... 104

Actividades.................................................................................................. 105

Ejercicios de autoevaluacin.................................................................. 107

Solucionario................................................................................................ 109

Glosario........................................................................................................ 128

Bibliografa................................................................................................. 130

CC-BY-NC-ND PID_00184467 5 Desarrollo de software basado en reutilizacin

Introduccin

Todo el que haya programado alguna vez habr sentido, en algn momento,la necesidad de recuperar alguna funcin o algn bloque de cdigo que tenaescrito de algn proyecto previo para incorporarlo en el que le est ocupandoen ese momento. Las posibilidades que nos dan el Copy & Paste nos permitenaprovechar de esta manera el esfuerzo que dedicamos en momentos anteriores.

Sin embargo, esta utilizacin de elementos predesarrollados no casa comple-tamente con el concepto de reutilizacin en el sentido de la ingeniera delsoftware, donde reutilizar tiene un significado ms relacionado con:

1) La encapsulacin de funcionalidades (previamente desarrolladas y proba-das) en elementos que, posteriormente, podrn ser directamente integradosen otros sistemas.

2) El desarrollo de estas funcionalidades mediante mtodos de ingeniera desoftware.

3) El aprovechamiento del conocimiento y la experiencia producidos durantedcadas de prctica en la construccin de software.

Este mdulo se estructura en cuatro partes: en la primera se presenta una vi-sin general de la reutilizacin, ponindose algunos ejemplos y haciendo unbreve repaso por su historia. Las aportaciones a la reutilizacin de la orienta-cin a objetos, que ha desempeado un papel importantsimo en este campo,se describen e ilustran en la segunda parte. Algunas soluciones tcnicas, mu-chas de ellas evoluciones casi naturales de la orientacin a objetos, se presen-tan en la tercera parte. La cuarta y ltima parte se enfoca ms a solucionesmetodolgicas para desarrollo de software, que toman la reutilizacin comoun valor esencial.


Objetivos

Al finalizar este curso, el alumno debe:

1. Ser consciente de la conveniencia de reutilizar software y de desarrollarsoftware reutilizable.

2. Conocer las principales tcnicas para desarrollo de software reutilizable.

3. Conocer tcnicas para integrar software reutilizable en los proyectos nue-vos.

4. Conocer metodologas que permitan el desarrollo de proyectos que haganun uso intensivo de la reutilizacin.


1. Introduccin a la reutilizacin

La primera vez que se introdujo de forma pblica y relevante la idea de la re-utilizacin del software fue en 1968, en un clebre congreso sobre ingenieradel software que organiz el Comit de Ciencia de la OTAN. En este encuen-tro, adems de acuarse tambin el trmino ingeniera del software, el ingenierode Bell Laboratories, M.D. McIlroy, afirm que La industria del software seasienta sobre una base dbil, y un aspecto importante de esa debilidad es laausencia de una subindustria de componentes. En un contexto tecnolgicomucho ms primitivo que el actual, McIlroy asimilaba un componente a unarutina o conjunto de rutinas reutilizable: explicaba que en su empresa utili-zaban ms de un centenar de distintas mquinas de procesamiento de infor-macin, pero que casi todas ellas necesitaban una serie de funcionalidades encomn (rutinas para convertir cadenas a nmeros, por ejemplo) que tenanque implementar una y otra vez.

En el contexto actual de la ingeniera del software, todo el mundo entiendeque un componente se corresponde con un fragmento reemplazable de unsistema, dentro del cual se encuentran implementadas un conjunto de funcio-nalidades. Un componente se puede desarrollar aislado del resto del mundo.

Un botn de un editor visual de aplicaciones es un pequeo componente que permite,por ejemplo, que el usuario lo pulse, y que ofrece al desarrollador, por un lado, unainterfaz pblica para que este le adapte su tamao a la ventana, le cambie el color, el textoque muestra, etctera; y por otro, la posibilidad de colocar diferentes instancias de esemismo botn en la misma o en otras aplicaciones, evitando la tediosa tarea de programarsu cdigo cada vez que quiera hacer uso de l.

Para que un componente sea, en efecto, reutilizable, debe encapsular su fun-cionalidad, y debe ofrecerla al exterior a travs de una o ms interfaces queel propio componente debe implementar. As, cuando el sistema en el queincluimos el componente desea utilizar una de las funcionalidades que esteofrece, se la pide a travs de la interfaz. Pero, del mismo modo, el componen-te puede tambin requerir otras interfaces para, por ejemplo, comunicar losresultados de su cmputo. En el ejemplo de la figura siguiente se muestra uncomponente Termostato que recibe datos de dos sensores (uno de temperatu-ra y otro de humedad): estos le comunican peridicamente su informacin atravs de las dos interfaces que les ofrece el componente (ITemperatura e IHu-medad). Este, en funcin de los parmetros recibidos, ordena a travs de algnelemento que implementa la interfaz IActuador que se suba o se baje la tempe-ratura (operacin cambiarTemperatura) o que se expulse agua a la estancia paraincrementar la humedad.

La conferencia se organiz en la ciudad deGarmish (Alemania), del 7 al 11 de octubre de1968. Sus actas se han escaneado y procesado

mediante OCR y se encuentran publicadasen Internet: http://homepages.cs.ncl.ac.uk/

brian.randell/NATO/nato1968.PDF


Supongamos que el componente de la figura de arriba no respondiese con laprecisin requerida ante ciertos cambios atmosfricos: por ejemplo, incremen-ta o decrementa la temperatura solamente cuando la diferencia con la medidaanterior es superior a 2 grados. En este caso, es posible que encontremos otrocomponente del mismo o de otro fabricante para que podamos construir unaversin nueva del sistema sin demasiado esfuerzo: en la siguiente ilustracin,el viejo termostato es sustituido por un Termostato 2.0 adquirido a un distintoproveedor. Para que esta nueva versin del componente pueda integrarse per-fectamente en nuestro sistema, debe ofrecer y requerir exactamente las mis-mas interfaces.

La ingeniera del software basada en componentes (CBSE: component-basedsoftware engineering) se ocupa del desarrollo de sistemas software a partir decomponentes reutilizables, como en el sencillo ejemplo que acabamos de pre-sentar. Pero la CBSE, sin embargo, es solo una de las lneas de trabajo de la co-munidad cientfica y de la industria del software para favorecer la reutilizaciny, de este modo, evitar la reinvencin continua de la rueda o, en nuestro en-torno, impedir el anlisis, el diseo, la implementacin y la prueba de la mis-ma solucin, desarrollndola una y otra vez en mil y un proyectos distintos.

Ved tambin

Ved la asignatura Ingeniera delsoftware de componentes y sis-temas distribuidos del grado deIngeniera Informtica.

De este modo, la reutilizacin1 abarata los costes del desarrollo: en primer lu-gar, porque no se necesita implementar una solucin de la que ya se dispone;en segundo lugar, porque aumenta la productividad, al poder dedicar los re-

cursos a otras actividades ms en lnea con el negocio2; en tercer lugar, porqueprobablemente el elemento que reutilizamos ha sido suficientemente proba-

(1)Krueger la define como el pro-ceso de crear sistemas software apartir de software preexistente, enlugar de crearlos empezando decero.


do por su desarrollador, con lo que los testers podrn dedicarse a probar otras

partes ms crticas del sistema3, obteniendo entonces unos niveles de calidadmucho ms altos que si el sistema se desarrolla desde cero.

1.1. Un poco de historia

La introduccin en los aos ochenta del paradigma orientado a objetos supu-so un avance importantsimo en cuanto a reutilizacin de software: en efecto,una clase bien construida encapsula en s misma una estructura y un compor-tamiento que pueden aprovecharse en otros proyectos; adems, un conjuntode clases que colaboran entre s para servir algn propsito pueden agruparseen libreras, que luego, si se desea, se importan para utilizarlas ms de una vez.

En los aos noventa se desarrollaron libreras que permitan la programacindirigida por eventos, libreras de uso compartido y libreras de enlace dinmi-co. Las Microsoft foundation classes (MFC, clases fundamentales de Microsoft)de los aos noventa agrupaban gran cantidad de clases de uso comn en unaserie de libreras de enlace dinmico, que el programador poda utilizar paraconstruir tipos muy diversos de aplicaciones.

(2)Imaginemos que, para cada apli-cacin visual que fuese necesarioque construir, se debiese escribir elcdigo necesario para implemen-tar un botn corriente.

(3)Aunque tambin tendrn queprobar la integracin del elementoreutilizado con el resto del sistema.

Consulta recomendada

C.W.Krueger (1992). Soft-ware Reuse. ACM Compu-ting Surveys (nm. 24, pgs.131-183).

Tambin en los aos noventa se comienzan a desarrollar los primeros com-ponentes, aptos para ser integrados en aplicaciones sin demasiado esfuerzo.Algunas compaas construyen y venden lo que se dio en llamar componen-tes COTS (commercial off-the self), que no eran sino componentes cerrados ypuestos a la venta junto a la especificacin de sus interfaces y sus manualesde integracin y utilizacin.

Se construyen tambin libreras que encapsulan funcionalidades de comuni-caciones, que permiten, por ejemplo, la comparticin de una misma instanciapor otros objetos situados en mquinas remotas. En este sentido, cada grancompaa de software desarroll su propia tecnologa de comunicaciones.

As, por ejemplo, Sun desarrolla RMI (remote method invocation) y Microsoft hace lo pro-pio con DCOM (distributed component object model), dos sistemas incompatibles pero quepersiguen el mismo propsito. Ambos modelos de objetos distribuidos comparten unasencilla idea: la elaboracin de un protocolo para compartir objetos y transmitir mensa-jes entre objetos remotos.

Ved tambin

Ved los componentes COTS enla asignatura Ingeniera de re-quisitos del grado de IngenieraInformtica.

Estos modelos no son, al fin y al cabo, nada muy distinto de un socket queenva por su canal ristras de bytes con la informacin codificada de algunamanera. Lamentablemente, los formatos de estas ristras de bytes eran distintosen RMI y en DCOM, por lo que un objeto Java no poda comunicarse (al menosdirectamente) con un objeto Microsoft.

Ved tambin

Ved RMI y DCOM en la asigna-tura Ingeniera del software decomponentes y sistemas distri-buidos del grado de IngenieraInformtica.


Supongamos que dos compaas distintas desarrollan una sencilla calculadora remotaempezando desde cero. Ambas calculadoras implementan y ofrecen va de acceso remotoa las operaciones aritmticas bsicas, como suma (x : int, y : int) : int. Cada compaaofrecer acceso a su calculadora imponiendo un formato diferente: la primera puede de-cirle al cliente que, cuando desee invocar una operacin, enve por un socket una ristra debytes con el formato operacin#parametro1#parametro2, mientras que la segunda quizsutilice el smbolo @ como carcter de separacin y, adems, una almohadilla al final.Obviamente, una ristra de bytes para invocar al primer servicio no sirve para llamar alsegundo, que devolver un error. Los desarrolladores de RMI y DCOM no imponan evi-dentemente un formato tan simple, sino otros ms complejos, que, no obstante, perma-necen transparentes para el desarrollador, que los utiliza a travs de las correspondienteslibreras, que son las que codifican los mensajes.

Este problema de incompatibilidades se soluciona parcialmente en los prime-ros aos de este siglo con la introduccindelosserviciosweb.

Un servicio web no es ms que una funcionalidad que reside en unsistema remoto y que se hace accesible a otros sistemas a travs de unainterfaz que, normalmente, se ofrece a travs de protocolo http.

Las invocaciones a los servicios ofrecidos por la mquina remota (que actade servidor) viajan desde el cliente en un formato estandarizado de paso demensajes llamado SOAP (simple object access protocol, protocolo simple de ac-ceso a objetos) para cuya descripcin, por fortuna, se pusieron de acuerdo Mi-crosoft, IBM y otras grandes empresas. SOAP utiliza notacin XML y, aunqueuna invocacin a la operacin remota suma (x : int, y : int) : int nosea exactamente como se muestra en la figura siguiente (en la que se solicitala suma de los nmeros 5 y 8), la idea no es muy diferente.

Gracias a esta estandarizacin, podemos utilizar una funcionalidad ofrecidaen una mquina remota sin importarnos en qu lenguaje ni en qu sistemaoperativo se est ejecutando. Desde cierto punto de vista, un servicio web esun componente remoto que nos ofrece una interfaz de acceso en un formatoestandarizado.

La reutilizacin que permiten los servicios web es muy evidente, pues se inte-gran en la aplicacin, sin necesidad de hacer instalacin alguna, las funciona-lidades que un tercero ha desarrollado. Lo nico que el desarrollador necesitaser una clase que constituir el punto de acceso al servidor (un proxy) que:

Ved tambin

Ved los servicios web en laasignatura Ingeniera del soft-ware de componentes y sistemasdistribuidos del grado de Inge-niera Informtica.

1) codifique adecuadamente las llamadas al servicio remoto4;

2) se las enve;

(4)Es decir, que las traduzca a ris-tras de bytes en formato SOAP.


3) reciba los resultados (tambin en formato SOAP), y

4) los descodifique a un formato entendible por la aplicacin.

Adems, el usuario del servicio web5 tampoco debe preocuparse de implemen-tar el citado proxy, ya que cualquier entorno de desarrollo moderno lo cons-truye a partir de la especificacin de la interfaz del servicio, que tambin seofrece en un formato estandarizado llamado WSDL (web service description lan-guage, lenguaje de descripcin de servicios web).

(5)Es decir, el desarrollador que in-tegra un servicio web en su aplica-cin.

A partir de la utilizacin ms o menos masiva de servicios web se empieza ahablar de arquitectura orientada a servicios (SOA: service oriented architecture)que, bsicamente, consiste en el desarrollo de aplicaciones utilizando un n-mero importante de funcionalidades expuestas como servicios que, no obs-tante, no tienen por qu ser obligatoriamente servicios web.

Ved tambin

Ved SOA en la asignatura In-geniera del software de compo-nentes y sistemas distribuidosdel grado de Ingeniera Infor-mtica.

De aqu se ha avanzado rpidamente a la computacin en la nube (cloud com-puting), mediante la que se ofrecen multitud de servicios (ejecucin de aplica-ciones, servicios de almacenamiento, herramientas colaborativas, etctera) alos usuarios, que los utilizan de manera totalmente independiente de su ubi-cacin y, por lo general, sin demasiados requisitos de hardware.

Web recomendada

En Wikipedia hay una di-sertacin muy comple-ta sobre cloud computing:http://en.wikipedia.org/wi-ki/Cloud_computing

Otra lnea interesante respecto de la reutilizacin se encuentra en la fabrica-

cinindustrialdelsoftware, tanto en los llamados mercados de masas6 como

en los mercados de cliente7. En algunos entornos se ha dado un paso ms y seaplican tcnicas de lneas de producto a la fabricacin de software: el desarro-llo de software mediante lneas de producto de software (en lo sucesivo, LPS)surge hace en torno a una dcada (aunque es ahora cuando est cobrando msinters) con el objetivo de flexibilizar y abaratar el desarrollo de productos desoftware que comparten un conjunto amplio de caractersticas (common fea-tures o caractersticas comunes).

Las lneas de producto llevan aos aplicndose en otros entornos industriales,como la fabricacin de vehculos en cadenas de montaje. Las diferentes ver-siones de un mismo modelo de coche difieren en ciertas caractersticas de suequipamiento (presencia o ausencia de aire acondicionado, elevalunas elctri-cos, etc.), lo cual no impide que todos ellos compartan las mismas cadenas demontaje y produccin, imitando as a las industrias de productos manufactu-rados que se pusieron en marcha a partir de la Revolucin Industrial, en elsiglo XIX, y que Charles Chaplin parodi en el filme Tiempos modernos.

Ms recientemente, las lneas de producto se utilizan tambin para el desarro-llo y construccin de telfonos mviles, que, adems del conjunto bsico defuncionalidades, ofrecen diferentes tamaos de pantalla, presencia o ausen-cia de bluetooth, varias resoluciones de la cmara, etctera. Por lo general, eldesarrollo de productos de software ms o menos similares mediante LPS per-

(6)El mismo producto se puedevender varias veces lo que se lla-man economas de escala-, copian-do los prototipos mecnicamente.

(7)Cada producto es nico y el be-neficio se consigue a travs de lareutilizacin sistemtica.

Nota

En ingls, a las LPS se las cono-ce como software product lines,software product architectures ysoftware product families (SPL,SPA y SPF respectivamente).

Ved tambin

Veremos las LPS en detalle enel apartado Ingeniera delsoftware para lneas de pro-ducto basada en UML 87 deeste mdulo.


mite aprovechar casi al mximo los esfuerzos dedicados a la construccin delas common features (caractersticas comunes) reutilizando estas y dedicandolos recursos a la implementacin de las variable features (caractersticas propiaso variables) de cada producto y a su ensamblado.

1.2. Reutilizacin de conocimiento: patrones de diseo

Cuando en ingeniera de software se habla de reutilizacin, no debemos creerque esta consiste solamente en volver a utilizar funcionalidades predesarrolla-das y empaquetadas en clases, componentes o servicios. Tambin puede reuti-lizarse el conocimiento y la experiencia de otros desarrolladores. Efectivamen-te, existen multitud de problemas que se presentan una y otra vez cuando sedesarrolla un producto software.

La gestin de la persistencia de objetos, por ejemplo, se presenta cada vez que se construyeuna aplicacin que vaya a manipular informacin conectndose a una base de datos.

Como ingenieros de software, debemos ser capaces de identificar estas situa-ciones que se presentan frecuentemente y que han sido ya, con toda probabili-dad, resueltas con antelacin por otras personas de manera eficiente. Este tipode conocimiento, en el que se describen problemas que aparecen de manerams o menos frecuente, y que incluyen en su descripcin una o ms buenasmaneras de resolverlo, conforma lo que se llama un patrn. Un patrn, en-tonces, describe una solucin buena a un problema frecuente, como ese quehemos mencionado de la gestin de la persistencia.

Ved tambin

Ved la asignatura Anlisis y di-seo con patrones del grado deIngeniera Informtica.

Revisitando el ejemplo del componente Termostato que se ha reemplazado porotro, a veces ocurre que el nuevo componente no puede integrarse directa-mente en el sistema: en la vida real, a veces es preciso colocar un poco deestopa o algn adhesivo entre dos tuberas que se deben conectar y que nollegan a encajar perfectamente. En el caso de la sustitucin de componenteso servicios, el problema es muy parecido: disponemos de un componente oservicio que nos ofrece las funcionalidades que requerimos, pero las interfacesofrecidas y esperadas no coinciden con el contexto en el que queremos inte-grarlo. Este es un problema recurrente que puede solventarse aplicando glue

code8 quizs mediante un adaptador, que es la solucin que propone el patrnWrapper. El proxy que se citaba en el epgrafe anterior, y que decamos que seutiliza para conectar el sistema a un servicio web externo, es tambin la solu-cin que se propone en el patrn de diseo proxy para conectar un sistema aotro sistema remoto.

(8)Literalmente cdigo-pegamen-to, que correspondera a esa esto-pa o a ese adhesivo.


Todo este conocimiento producido durante aos de investigacin y desarrolloen ingeniera del software puede reutilizarse y, de hecho se recopila y se ha-ce pblico, en catlogos de patrones. El ms famoso es el de Gamma, Helm,Johnson y Vlissides, pero todos los aos se celebran, en diversos lugares delmundo, conferencias sobre patrones: la PLoP (Conference on Pattern Langua-ges of Programs) a nivel internacional, la EuroPLoP en Europa o la KoalaPLoPen Oceana. Para publicar un patrn en estas conferencias, el autor debe de-mostrar que el problema es importante y que se presenta con frecuencia, y de-be presentar al menos tres casos distintos en los que se haya aplicado la mis-ma solucin: de esta manera, se demuestra que la solucin ha sido utilizadasatisfactoriamente ms de una vez, y ofrece a la comunidad la posibilidad dereutilizar ese conocimiento.

1.3. Beneficios y costes de la reutilizacin

Existen dos enfoques bien distintos en cuanto a reutilizacin: el enfoqueopor-tunista aprovecha elementos software construidos en proyectos anteriores,pero que no fueron especialmente desarrollados para ser reutilizados; en unenfoque ms planificado o proactivo, los elementos se construyen pensandoen que sern reutilizados, lo que puede significar, en el momento de su desa-rrollo, mayor inversin de recursos, puesto que se debe dotar al elemento desuficiente generalidad.

Nuestro enfoque en este material se centra en la reutilizacinproac-tiva.

De forma general, la reutilizacin permite:

Disminuir los plazos de ejecucin de proyectos, porque se evita construirnuevamente funciones, funcionalidades o componentes.

Disminuir los costes de mantenimiento, que se discute ms extensamentea continuacin.

Aumentar la fiabilidad, siempre que se utilicen elementos reutilizables pro-cedentes de suministradores seguros.

Aumentar la eficiencia, sobre todo si se reutiliza software desarrollado bajoel enfoque planificado o proactivo, porque los desarrolladores implemen-tarn versiones optimizadas de algoritmos y de estructuras de datos. Enun desarrollo nuevo, en el que la reutilizacin surgir ms adelante quizspor un enfoque oportunista, la presin de los plazos de entrega impide,en muchos casos, mejorar u optimizar los algoritmos.


La primera edicin del libroDesign patterns se public en1994. Ha sido traducido amultitud de idiomas, entreellos el castellano: E. Gam-ma; R. Helm; R. Johnson; J.Vlissides (2002). Patrones dediseo: elementos de softwareorientado a objetos reutiliza-bles. Addison Wesley.


Aumentar la consistencia de los diseos y mejorar la arquitectura del sis-tema, especialmente cuando se utilizan frameworks o bibliotecas bien es-tructuradas que, en cierta manera, imponen al ingeniero de software unbuen estilo de construccin del sistema.

Invertir, porque el gasto ocasionado en dotar a un elemento de posibili-dades de reutilizacin se ver recompensado con ahorros importantes enel futuro.

1.3.1. El impacto positivo de la reutilizacin en el proceso demantenimiento

Un trabajo de Kung y Hsu de 1998 asimila la tasa de llegadas de peticiones demantenimiento al modelo de ecologa de poblaciones de May. En un ecosiste-ma cerrado en el que solo hay predadores y presas, el aumento de predadoressupone una disminucin del nmero de presas, lo que implica que, al habermenos alimento, disminuya el nmero de predadores y aumente nuevamenteel de presas. Con el avance del tiempo, estos altibajos van tendiendo hacia unpunto de equilibrio.

Modelo de Kung y Hsu

En el modelo de Kung y Hsu, los errores en el software son presas que son devoradaspor las acciones de mantenimiento correctivo, que son los predadores. La introduccinde un sistema supone la introduccin masiva de errores, que se consumen en la etapade crecimiento, al ser corregidos por los reportes de los usuarios. En la madurez apenasdan presas de la primera generacin; sin embargo, las peticiones de perfectivo (adicinde nuevas funcionalidades) introduce nuevos errores (nuevas presas, por tanto), que sonconsumidas por las correcciones que realizan los programadores.

El proceso de mantenimiento es uno de los procesos principales del ciclo devida del software. Comienza una vez que el sistema ha sido instalado y puestoen explotacin. En su caracterizacin, Kung y Hsu identifican cuatro etapasen la vida de un sistema:

Introduccin, que tiene una duracin relativamente breve. Durante esteperiodo, los usuarios aprenden a manejar el sistema y envan al equipo demantenimiento peticiones de soporte tcnico, con objeto de aprender autilizarlo por completo.

Crecimiento. En esta etapa disminuye el nmero de peticiones de soporteporque los usuarios ya conocen bien el sistema y no necesitan ayuda tc-nica. Sin embargo, los usuarios comienzan a encontrar errores en el siste-ma y envan peticiones de mantenimiento correctivo.

Madurez. Las correcciones que se han ido realizando durante la etapa decrecimiento han disminuido el nmero de peticiones de mantenimientocorrectivo, y el sistema tiene ahora muy pocos errores. Los usuarios, sin

Lectura adicional

H.-J.Kung;Ch. Hsu (1998).Software Maintenance Life Cy-cle Model. International Confe-rence on Software Maintenance(pgs. 113-121). IEEE Com-puter Society.

Lectura adicional

R.M.May (1974). Biologi-cal Populations with Nono-verlapping Generations: Sta-ble Points, Stable Cycles, andChaos. Science (vol. 4164,nm. 186, pgs. 645-647).


embargo, que ya conocen el sistema, demandan nuevas funcionalidadesque se traducen a peticiones de mantenimiento perfectivo.

Declive. Con el paso del tiempo, nuevos sistemas operativos y nuevos en-tornos favorecen la sustitucin del sistema por uno nuevo, o su migracinhacia plataformas ms modernas, lo que puede dar lugar bien a la retiradadel sistema o bien a su migracin, que implicar la presentacin de peti-ciones de mantenimiento adaptativo.

Al servir una peticin de mantenimiento, el ingeniero de software debe, enprimer lugar, ubicar el rea del cdigo que debe ser modificada, entender lalgica de la aplicacin y sus conexiones con sistemas externos (tareas que son,por lo general, las ms costosas), implementar el cambio y realizar las pruebasque sean necesarias, lo que incluir pruebas de regresin para comprobar quela modificacin no ha introducido errores que antes no existan.

La reutilizacin de software supone una disminucin del mantenimiento co-rrectivo, ya que la probabilidad de encontrar errores en una funcin utilizadaen varios proyectos anteriores es muy pequea. Tambin disminuye los cos-tes de mantenimiento perfectivo (adicin de funcionalidades), porque resultams sencillo entender un sistema en el que muchos de sus elementos son ca-jas negras que ofrecen correctamente una funcionalidad determinada y que,por tanto, no es necesario examinar.

1.3.2. Los costes de reutilizar

La reutilizacin de software tiene siempre unos costes asociados. Meyer indicaque, al menos, estos son los siguientes:

Costedeaprendizaje (al menos la primera vez).

Costedeintegracinenelsistema. Por ejemplo, en el caso de la reutili-zacin de componentes, muchas veces es preciso escribir adaptadores para


B.Meyer (1997). Object-orien-ted software construction (2.ed.). Prentice Hall Professio-nal Technical Reference.


conectar adecuadamente el componente en el sistema que se est desarro-llando.

Obviamente, el enfoque proactivo en el desarrollo de software para que estesea reutilizable tiene tambin unos costes asociados. Una visin cortoplacistadesaconsejara dedicar esfuerzos especiales a la construccin de componentesensamblables o de elementos de software genricos (hablaremos de todo estoms adelante). Griss (1993) aconseja el desarrollo de modelos de clculo delROI (return of investment, retorno de la inversin) para convencer a la direccinde la conveniencia de tratar la reutilizacin como un activo importante.

Ved tambin

Ved la reutilizacin de compo-nentes en el apartado Com-ponentes.

Lectura adicional

MartinL.Griss (1993).Software reuse: from libraryto factory. IBM.Software Jour-nal (vol. 4, nm. 32, pgs.548-566).


2. Reutilizacin en diseo de software orientado aobjetos

Bertrand Meyer define la construccin de software orientado a objetos comola:

Construccin de sistemas software en forma de colecciones estructuradas de, posible-mente, implementaciones de tipos abstractos de datos.

Los tipos abstractos de datos (TAD) describen matemticamente el conjuntode operaciones que actan sobre un determinado tipo de elemento. Cada ope-racin se describe algebraicamente en trminos de:

1) las transformaciones que realiza sobre las ocurrencias del tipo de dato;2) los axiomas de la operacin, y3) las precondiciones necesarias para que la operacin pueda ejecutarse.

Puesto que son abstractos y siguen el principio de abstraccin, los TAD exhi-ben una vista de alto nivel de las posibilidades de manipulacin de informa-cin que permite el tipo de dato, mostrando al exterior la parte que interesay escondiendo los detalles que no interesa mostrar. As, se hace tambin galade la encapsulacin y del ocultamiento de la informacin.

Como en otras reas del desarrollo de software, los TAD describen loque sucede o debe suceder, pero no cmo sucede.

Ocurre lo mismo, por ejemplo, en el anlisis funcional: el ingeniero de software identificalos requisitos del sistema y puede representarlos en un diagrama de casos de uso. En estecaso, se indican las funcionalidades que debe servir el sistema, pero sin entrar en losdetalles de cmo servirlas.

Junto a otros principios fundamentales del desarrollo de software (como elmantenimiento de la alta cohesin y del bajo acoplamiento), la abstraccin,la encapsulacin y el ocultamiento de la informacin son tres herramientasesenciales del diseo de software en general, no solo del orientado a objetos.Pero la orientacin a objetos aporta tambin las posibilidades que brindan laherencia y el polimorfismo. En este apartado se presentan las principales ca-ractersticas que ofrece la orientacin a objetos en aras de permitir y fomentarla reutilizacin del software.

Ved tambin

Repasad los TAD y la orienta-cin a objetos en las asigna-turas Diseo de estructuras dedatos y Diseo y programacinorientada a objetos del gradode Ingeniera Informtica.


2.1. Introduccin

En la mayora de los libros de introduccin a las estructuras de datos, se utili-zan estructuras de almacenamiento de informacin (listas, pilas, colas, rbo-les, grafos) como ejemplos habituales.

Una pila, por ejemplo, se corresponde con una estructura de datos en la que los elementosse van colocando uno encima de otro, y de la que podemos sacar elementos en ordeninverso al que han sido colocados: de este modo, la estructura de datos Pila abstrae elcomportamiento de una pila real, como la pila que se crea cuando se friegan los platos, yluego cuando se van tomando en orden inverso para poner la mesa: se sigue una polticaLIFO (last-in, first-out: ltimo en entrar, primero en salir) para gestionar sus elementos.

Cuando se programa el cdigo de la pila en el ordenador, se puede representarla estructura de datos mediante un array esttico, un vector dinmico, unalista enlazada, etctera; sin embargo, a los diseadores y a los usuarios del TADpila les interesa tan solo la descripcin de su comportamiento, sin que intereseofrecer los detalles de su implementacin. De esta manera, el TAD pila es unaabstraccin de la estructura real pila que, adems, encapsula sus detalles deestructura y funcionamiento.

En la especificacin del TAD pila que se da en la figura anterior, la pila trabajacon elementos genricos de tipo E que, en la prctica, pueden ser nmerosenteros o reales, letras, cadenas de caracteres, o estructuras ms complejas, co-mo personas, cuentas corrientes, abstracciones del objeto real plato o, incluso,otras pilas. Todas las pilas (almacenen el tipo de elemento que almacenen) se


comportan exactamente igual: si se coloca un elemento en la cima, ese mis-mo elemento ser el primero en salir, independientemente de que apilemosnmeros o letras.

El comportamiento que describimos en el TAD pila es entonces un comporta-miento genrico: el lenguaje C++ es uno de los pocos que permiten la imple-mentacin de TAD genricos, como la pila que se muestra en la figura siguien-te, en la que se define, mediante una template (plantilla) de C++, una pila queacta sobre un tipo de dato genrico T. Si en el cdigo instanciamos una pilade int y otra del tipo persona, el compilador genera una versin en cdigoobjeto de la pila de enteros y otra de la pila de personas.

Otros lenguajes de programacin orientados a objetos no permiten la defini-cin de plantillas, aunque s dejan la descripcin de pilas de cualquier tipo deelemento mediante la herencia. Es el caso de C# y de las primeras versionesde Java, cuyo tipo Object representa a cualquier tipo de objeto. En estos doslenguajes, todos los objetos son tambin instancias del tipo genrico Object,por lo que se puede implementar una pila de objetos en la que ser posiblealmacenar cualquier cosa, como cadenas, enteros o reales, pero tambin Ter-mostatos o IActuadores como los que mostrbamos en el apartado anterior.

Nota

A partir de la versin 5 de Javase pueden utilizar los generics,que permiten crear plantillassimilares a C++:

public class Pila

Ved tambin

Veremos la programacin ge-nrica en el apartado Fbricasde software.


Del mismo modo, haciendo uso de la herencia se puede definir un tipo dedato Apilable, que represente los objetos que, en el dominio del problema quese est resolviendo, puedan colocarse en la Pila:


2.2. Abstraccin, encapsulacin y ocultamiento

En nuestro contexto, la abstraccin es el mecanismo que utiliza el ingenierode software para representar conceptos del mundo real utilizando alguna no-tacin que, en algn momento y de alguna manera (tal vez mediante variospasos intermedios), pueda ser procesada y traducida a algn formato entendi-ble por un ordenador.

Como se ha sugerido en prrafos anteriores, la orientacin a objetos surge co-mo una evolucin de los tipos abstractos de datos: de acuerdo con Jacobson(uno de los padres del UML) y colaboradores, tanto un TAD como una claseson abstracciones definidas en trminos de lo que son capaces de hacer, no decmo lo hacen: son, entonces, generalizaciones de algo especfico, en las quela encapsulacin juega un papel fundamental. En el diseo de una tienda vir-tual, por ejemplo, se utilizan conceptos (abstracciones) como Carrito, Productoo Venta, que pueden representarse utilizando una notacin abstracta (comoUML), incluyendo las relaciones entre dichas abstracciones.


I.Jacobson;M.Christerson;P.Jonsson;G.vergaard(1992). Object-Oriented Soft-ware Engineering. A use caseapproach. Addison-Wesley.


A la hora de implementar el Carrito, el Producto y la Venta, el programadordeber considerar, por ejemplo, si la coleccin de productos contenidos en elcarrito la va a representar con un vector, con una tabla de dispersin (hash) ocon una estructura de datos de otro tipo. Independientemente de la estructurade datos seleccionada, el programador debe conseguir por ejemplo que, si seaaden dos unidades de un producto que ya estaba contenido en el carrito(el producto con referencia 56789, por ejemplo), tan solo se incremente el n-mero de unidades. La forma con la que el programador consiga ese comporta-miento no forma parte del principio de abstraccin (porque es un detalle de-masiado concreto sobre el funcionamiento de los carritos en la tienda virtual).Por el contrario, este comportamiento que el programador ha implementado(y que desde el punto de vista de la abstraccin no nos interesa) s que se co-rresponde con el principio de encapsulacin: digamos que no sabemos cmofunciona la operacin, pero s sabemos que funciona.

En orientacin a objetos, una clase es una plantilla de estructura y comporta-miento que se utiliza para crear objetos. La parte de estructura se utiliza pararepresentar el estado de los objetos de esa clase (es decir, de sus instancias),mientras que la de comportamiento describe la forma con la que puede al-terarse o consultarse el estado de dichos objetos, o solicitarles que ejecutenalgn servicio sobre otros. A nivel prctico, la estructura se compone de unconjunto de campos o atributos, mientras que el comportamiento se describemediante una serie de operaciones o mtodos. Por lo general, la estructura deuna clase (es decir, su conjunto de campos) permanece oculta al resto de ob-


jetos, de manera que solo el propio objeto es capaz de conocer directamentesu estado: cada objeto muestra al exterior solo aquello que el propio objetoest interesado en mostrar.

En la siguiente figura, cada objeto de clase A conoce una instancia B; las ins-tancias de B poseen un estado que viene determinado por un campo privado(es decir, oculto al exterior) llamado fechaDeAlta; sin embargo, B exhibe a Auna porcin de su estado (la antigedad en aos), que hace accesible median-te la operacin pblica getAntiguedad(), y que probablemente se calcular enfuncin de la fecha del sistema y de la fecha de alta.

Del mismo modo, cuando un objeto A quiere hacer algo sobre otro objeto B, Asolo podr actuar utilizando los elementos de B que el propio B le permita: esdecir, B ofrece a A un conjunto de servicios (operaciones o mtodos pblicos)que son un subconjunto de las operaciones incluidas e implementadas en B.B, por tanto, es el objeto que tiene realmente la responsabilidad de controlarsus cambios de estado: A puede intentar desapilar un elemento de una pilavaca, pero la propia instancia de Pila ha de ser responsable de decir, de algunamanera (quizs mediante el lanzamiento de alguna excepcin), que de ellano puede desapilarse porque no tiene elementos, de manera que su estadopermanezca inalterable.

2.3. Herencia y polimorfismo

Supongamos que la tienda virtual oferta dos tipos de productos: productosconvencionales, que requieren un almacn y de los que hay un nmero de-terminado de unidades en stock, y productoselectrnicos, que se vendenpor descargas y que no tienen necesidad de almacenamiento fsico. Es muyprobable que ambos tipos de productos compartan un conjunto amplio de

caractersticas9 y parte del comportamiento10. El producto fsico, sin embargo,aporta a su estructura (es decir, a su conjunto de campos) el nmero de unida-des que se tienen en el almacn, mientras que el producto descargable aporta,por ejemplo, el nmero de descargas que ha tenido.

As pues, la tienda manipular Productos que podrn ser Fsicos o Descargables.Puesto que ambos tienen en comn parte de la estructura y del comporta-miento, es posible definir, en un diseo orientado a objetos, una superclaseProducto en la que ubicaremos todos aquellos elementos comunes a las dossubclases que, en este caso, sern Fsico y Descargable.

(9)Por ejemplo: referencia, descrip-cin, proveedor, precio y tipo deIVA.

(10)Los dos se dan de alta y de ba-ja, los dos se venden, se puedemodificar el precio de ambos, et-ctera.


En la figura anterior se representa la estructura de la clase Producto, en la quese han ubicado todos los elementos comunes a los dos tipos de productosque vende la tienda. El hecho de que aparezca en cursiva el nombre de lasuperclase y en redonda los de las subclases denota que Producto es una claseabstracta, mientras que Fsico y Descargable son clases concretas: es decir, en latienda existen Productos, pero han de ser o bien Fsicos o bien Descargables, nopudiendo existir Productos como tales.

La figura ilustra la capacidad de reutilizacin que ofrece la herencia: la defini-cin genrica (de estructura y de comportamiento) que se da en la superclasese reutiliza completamente en las subclases que, en este ejemplo, aportan algode estructura a lo heredado.

Obsrvese, por otro lado, que la operacin vender() de Producto aparece (al igualque el nombre de la clase contenedora) tambin en cursiva, lo que denota quese trata de una operacin abstracta: puesto que es diferente vender un produc-to fsico de un producto descargable (en el primero se decrementa el stock; enel segundo se incrementan las descargas), es preciso dar una implementacindiferente en las subclases a la operacin abstracta que se est heredando.

Producto, adems, tiene una serie de operaciones concretas (setPrecio(), getPre-cio() y getPrecioConIVA()), que se comportan exactamente igual con todos losproductos, sean fsicos o descargables: en este caso, la herencia nos permitereutilizar ya no solo parte de la estructura, sino tambin parte del comporta-miento, a travs de las operaciones heredadas.

Adems, la inclusin de la operacin abstracta vender() en Producto nos permi-

te manejar, por ejemplo, colecciones de productos genricos11 y ejecutar so-bre ellos la operacin vender(). En tiempo de ejecucin, y en funcin del tipoconcreto de cada Producto contenido en la coleccin, se decide cul de las dos

(11)En tiempo de ejecucin, estarnobviamente instanciados a produc-tos concretos de los subtipos fsicoy descargable, ya que no puedenexistir instancias reales de la claseabstracta producto.


versiones de la operacin vender() debe ejecutarse: si la instancia es del subtipoFsico, la operacin vender() ser de Fsico; si es del subtipo Descargable, Vender()ser de Descargable.

El carrito contiene una lista de productos genricos. En tiempo de ejecucin, cada producto est instanciado a uno de los dos subtipos concretos. Al ejecutar vender en el carrito,se llama a la operacin abstracta vender(unidades:int) de cada producto. Se ejecuta una u otra versin de vender en funcin del tipo concreto de cada producto.

La operacin vender(unidades:int) es una operacin polimrfica, pues tiene

muchas formas12. Como se ilustra en el caso de la figura anterior, el polimor-fismo permite hacer referencia a distintos comportamientos de distintos ob-jetos, pero que se encuentran designados por el mismo mensaje (vender, eneste caso).

Polimorfismo

Cuando una instancia enva un estmulo a otra instancia, pero sin que aquella est segurade a qu clase pertenece la instancia receptora, se dice que tenemos polimorfismo.

(12)En este ejemplo realmente so-lo dos, pero podra haber ms ver-siones diferentes de la operacin sihubiera ms subtipos de Producto.


Jacobson;M.Christerson;P.Jonsson;G.vergaard(1992). Object-Oriented Soft-ware Engineering. A use caseapproach. Addison-Wesley.


3. Reutilizacin a pequea escala: soluciones tcnicasde reutilizacin

3.1. Introduccin

Como se coment en las primeras lneas del primer apartado, la necesidad deproducir software reutilizable se puso de manifiesto en el mismo congreso enel que se emple por primera vez, hace ms de cuarenta aos, el trmino inge-niera del software. Esta coincidencia permite tomar conciencia de la importan-cia que, desde el nacimiento mismo de esta disciplina, tiene la reutilizacinde software y los esfuerzos llevados a cabo para poder establecer mtodos quepermitan su produccin industrial.

Escribir una y otra vez las mismas rutinas o funciones es una prctica que de-bera ser evitada a toda costa: la investigacin y el desarrollo en ingeniera delsoftware ha llevado a la implementacin de diferentes tipos de soluciones pa-ra favorecer la reutilizacin. Tras presentar un fragmento muy ilustrativo dela reutilizacin de software de hace solo 20 aos, este apartado revisa las so-luciones de reutilizacin ms prximas a la implementacin de cdigo: libre-ras, clases, patrones arquitectnicos, patrones de diseo, componentes, fra-meworks y servicios.

3.2. Una historia ilustrativa

dBase fue un sistema gestor de bases de datos muy popular a finales de losaos ochenta y principios de los noventa y que fue desarrollado y comerciali-zado por la empresa Ashton-Tate. Adems de permitir la creacin de tablas endices, dBase incorporaba un lenguaje de programacin con el que se podanimplementar de manera relativamente sencilla aplicaciones para gestionar suspropias bases de datos, lo que inclua la posibilidad de crear pantallas (a lasazn, basadas en texto y no en grficos) con mens, formularios de mante-nimiento de registros, obtencin de listados, impresin, etctera.

Uno de los problemas de dBase es que sus programas eran interpretados y nocompilados, por lo que los desarrolladores deban entregar a sus clientes elcdigo fuente de los programas que escriban, con el consiguiente perjuicioen cuanto a la conservacin de sus derechos de autor y propiedad intelectual.Sabedores de esta desventaja, la empresa Nantucket Corporation (posterior-mente adquirida por Computer Associates) cre en 1985 el sistema Clipper,que era, en sus principios, un compilador del lenguaje de dBase que generabaejecutables en formato binario, lo que impeda el acceso al cdigo fuente delos programas.

dBase III Plus es uno de los libros sobrebibliotecas y rutinas para reutilizacin de

cdigo ms vendido en aquellos aos. Puedeencontrarse ms informacin en Wikipedia:

http://es.wikipedia.org/wiki/DBase.


De la mano de sus fabricantes, Clipper evolucion de manera paralela a dBa-se, incorporando, con el tiempo, nuevas funciones y mejoras respecto de lasofrecidas por el sistema interpretado de Ashton-Tate. De esta manera, se llega que cualquier programa escrito en dBase poda ser compilado por Clipper;adems, los programas que estaban escritos directamente para Clipper permi-tan la inclusin en su cdigo de llamadas a funciones adicionales que, graciasa que Clipper estaba implementado en Ensamblador y en C, podan residiren ficheros separados y que no eran, entonces, ejecutables desde el entornode dBase. Clipper traduca los programas dBase a ficheros objeto con exten-sin .obj.

Contraportada de El libro del ClipperSummer87, publicado en 1989 por la editorialRa-Ma. Explicaba, por ejemplo, los mtodos de

compilacin y enlace.

Para construir el fichero que finalmente pudiera ser ejecutado por el sistemaoperativo de que se tratase, era preciso enlazar o linkar el programa objetocon los ficheros externos en los que residan las funciones auxiliares utilizadaspor el programador. A estos ficheros externos (que se almacenaban en discocon extensin .lib) se los llamaba libreras o bibliotecas (libraries) y ofrecan alprogramador funciones de uso comn. Las libreras estndares distribuidas conClipper eran CLIPPER.LIB, EXTEND.LIB y OVERLAY.LIB, y ofrecan funciones

como abs13, aCopy14 u Overlay15.

Sin embargo, cualquier programador de C poda implementar funciones adi-cionales en otras libreras que, previo enlace, podan ser utilizadas en cualquier

programa16. Una de estas libreras no estndares que goz de cierto xito eraFiveWin, del fabricante espaol FiveSoftware, y que se utiliz para migrar lasprimitivas aplicaciones Clipper (desarrolladas para terminales basados en tex-to) hacia el entonces emergente sistema de Microsoft Windows, que ya ofrecaa los usuarios un entorno grfico de ventanas.

(13)Para calcular el valor absoluto, yque resida en CLIPPER.LIB.

(14)Utilizada para copiar arrays yque se encontraba en EXTEND.LIB.

(15)Permita puentear al sistemaoperativo para gestionar ms efi-cazmente la memoria del ordena-dor, entonces muy limitada, y quese encontraba en OVERLAY.LIB

(16)En la figura siguiente se repre-senta, con trazo ms grueso, unalibrera no estndar que incluyefunciones financieras que se utili-zan en el programa1.prg.


El enlace esttico produca programas ejecutables de gran tamao, lo que po-da suponer problemas de gestin de memoria con los sistemas operativos mscomunes en aquellos aos, como MS-DOS.

3.3. Libreras

El concepto de librera se ajusta bastante bien a la idea que, respecto de ellas,se ha presentado en el epgrafe anterior dedicado a dBase y Clipper.

En efecto, una librera es un conjunto reutilizable de funciones que seagrupan normalmente en un solo fichero.

Si el formato de la librera y el entorno operativo lo permiten, los desarrolla-dores pueden incluir en sus programas llamadas a las funciones ofrecidas enla librera.

En general, cada librera agrupa un conjunto cohesionado de funciones, como por ejem-plo: libreras de funciones matemticas y trigonomtricas, libreras para la creacin degrficos, libreras para funciones de bsqueda en textos mediante expresiones regulares,etctera.

Existen dos enfoques importantes a la hora de hacer uso de las funciones con-tenidas en una librera, y que vienen motivados por el hecho de que las libre-ras residen en ficheros externos al sistema que se est desarrollando: el enlaceesttico y el enlacedinmico.


3.3.1. Libreras de enlace esttico

En los primitivos sistemas de libreras, como los que se han ilustrado con elejemplo de Clipper, todos los programas que se desarrollaban y que hicieranuso de, por ejemplo, la funcin abs deban ser enlazados (para generar el eje-cutable) junto a la librera clipper.lib. Este hecho causaba desventajas impor-tantes en cuanto al uso del disco y de la memoria, pues todo el cdigo objetode la librera era combinado, durante el proceso de enlazado, con el cdigoobjeto del programa, lo que produca programas de tamao muy grande: si losprogramas programa1 y programa2 usaban la funcin abs, sus dos ejecutablescorrespondientes incluan la librera completa.

3.3.2. Libreras de enlace dinmico

La solucin al problema anterior consiste en la implementacin de libreras deenlace dinmico (dynamic-link libraries o DLL), que no requieren el enlazadodel cdigo escrito por el programador con el cdigo incluido en la librera.Ahora, cuando un ejecutable necesita llamar a una funcin de librera, se la


pide al sistema operativo, que guarda un registro de todas las DLL con sus fun-ciones. De este modo, dos programas que requieran usar la misma funcin notienen cdigo duplicado, sino que comparten un nico ejemplar de la librera.

En la siguiente figura se ilustra este concepto: ambos programas utilizan (com-parten) las libreras de funciones matemticas y de manejo de grficos, y elprograma1 es el nico que utiliza las funciones financieras. Como se observa,las libreras residen en ficheros separados que no se enlazan para generar losejecutables.

Sin embargo, la introduccin de libreras de enlace dinmico supuso tambinla aparicin de problemas nuevos que, con el enlace esttico, no se presenta-ban: as, la instalacin de una nueva aplicacin en el sistema poda reemplazaruna versin antigua de una DLL por una ms moderna, sucediendo en oca-siones que esta nueva versin era incompatible con otros programas previa-mente instalados. Si en la figura anterior se instala un nuevo programa3 enel sistema que instala tambin una versin nueva de la librera Grficos.dll yesta es incompatible con los dos programas preexistentes, estos podran dejarde funcionar.

Anlogamente, la desinstalacin de una aplicacin puede suponer la elimina-cin de sus libreras de enlace dinmico asociadas. Si el sistema operativo nolleva un control adecuado de las aplicaciones que hacen uso de las libreras re-gistradas, o si ha habido instalaciones o desinstalaciones manuales, es posible


que se eliminen libreras requeridas por otras aplicaciones. La figura siguienteilustra esta situacin: por un error en el registro de libreras, la eliminacindel programa2 conlleva tambin la eliminacin de Grficos.dll, por lo que esprevisible que el programa1 deje de funcionar o tenga comportamientos ines-perados.

3.3.3. Otras libreras

El trmino librera o biblioteca se utiliza normalmente para hacer referencia alibreras o bibliotecas de funciones, pero pueden referirse a cualquier tipo dealmacn esttico de recursos reutilizables, como archivos de imgenes o desonidos.

3.4. Clases

La creciente implantacin de la orientacin a objetos, con las capacidades pa-ra la abstraccin que permiten la herencia, el polimorfismo y la encapsula-cin de comportamiento y datos en una misma unidad, favoreci la aparicinde diversos tipos de elementos reutilizables: para el desarrollo de un nuevoproyecto, una compaa puede reutilizar los diseos hechos para un proyec-to desarrollado con anterioridad; puede tambin reutilizar clases que ofrezcanun conjunto de servicios que, nuevamente, puedan ser tiles; y puede, en ter-cer lugar, reutilizar el cdigo fuente para, mediante algunas modificaciones,adaptarlo al nuevo desarrollo.

Puesto que la documentacin tcnica del proyecto, en muchos casos, no evo-luciona acorde con la implementacin a la que dio lugar, la reutilizacin puray simple del diseo de un sistema encierra el riesgo grave de reutilizar un di-seo que contenga defectos que se detectaron con el producto ya implemen-tado, y que fueron corregidos solo sobre el cdigo fuente: como indica Meyer,la sola reutilizacin del diseo puede llevar a reutilizar elementos incorrectosu obsoletos. Para este autor, la reutilizacin de diseos debe llevarse a cabocon un enfoque que elimine la distancia entre diseo e implementacin, detal manera que el diseo de, por ejemplo, una clase, pueda ser considerado


como una clase a la que le falta algo de implementacin; y viceversa: graciasa los mecanismos de abstraccin, una clase implementada puede considerarseun elemento de diseo ms.

La reutilizacin del cdigo fuente, por otro lado, tiene la ventaja de que per-mite al reutilizador modificarlo para adaptarlo a sus necesidades reales; sinembargo, al entregar todo el detalle de la lgica del sistema se est violandoel principio de ocultamiento de informacin, y el desarrollador puede estartentado de, al no llegar a entender exactamente la poltica de privacidad opublicidad de las operaciones, alterar el cdigo, introduciendo efectos colate-rales no deseados.

El elemento bsico de reutilizacin en orientacin a objetos es la clase. Nor-malmente, se agrupa en un paquete (package, en UML) un conjunto cohesio-nado de clases reutilizables.

Un paquete de UML es un mecanismo utilizado para agrupar elementosde cualquier tipo (casos de uso, clases, diagramas de secuencia de uncierto caso de uso, una mezcla de casos de uso y clases, otros paquetes,etctera).

Nota

No siempre se desea poner adisposicin de terceros el c-digo de las aplicaciones: re-curdese que una de las razo-nes que llevaron a NantucketCorporation a crear Clipperfue que los programadores dedBase se vean obligados a en-tregar su cdigo.

Si bien los paquetes de clases son los ms interesantes desde el punto de vistade la reutilizacin: el paquete java.util ofrece un conjunto muy amplio de cla-ses e interfaces para manejar colecciones, eventos, fechas y horas, internacio-nalizacin y otras pocas ms; java.io contiene clases para manejar la entraday salida.

3.5. Patrones arquitectnicos

La arquitectura (o diseo arquitectnico) de un sistema se corresponde con sudiseo al ms alto nivel. Al plantear la arquitectura de un sistema se prescindede los detalles, enfocando la atencin en aquellos elementos generales que,merced al principio de abstraccin, llevan a cabo una o ms tareas de compu-tacin. As como un diseo arquitectnico equivocado llevar probablementeal fracaso del proyecto, uno bueno permite:

Reconocer relaciones de alto nivel entre sistemas o subsistemas.

Nota

Dentro del JDK, Java ofreceuna amplia API con paquetesformados por clases e inter-faces relacionadas para unaenorme variedad de usos utili-tarios, que permite a los desa-rrolladores hacer de este unuso para construir aplicacio-nes Java. El API para la ver-sin 7 de Java SE se encuen-tra en docs.oracle.com/java-se/7/docs/api/.


Favorecer la reutilizacin y la ampliacin de sistemas o subsistemas yaexistentes.

Hacer un aporte fundamental para entender y describir, a alto nivel, unsistema complejo.

3.5.1. Arquitectura multicapa

En un diseo arquitectnico multicapa, el sistema se descompone en capas(tiers o layers), en cada una de las cuales se ubica un conjunto ms o menosrelacionado de responsabilidades. En rigor, una capa debe conocer solo a susadyacentes. La figura siguiente muestra el diseo de un sistema con tres capas:una primera capa de presentacin, en la que se ubican las clases que utiliza elusuario para interactuar con el sistema, y que estarn constituidas por venta-nas; una segunda capa de dominio, en la que residen las clases que se encuen-tran en el enunciado del problema, y que son las que tienen la responsabili-dad real de resolverlo; una tercera capa de persistencia, en la que se ubican lasclases que se encargan de gestionar la persistencia de las instancias de clasesde dominio. Hay, adems, una cuarta capa en la que residen otros sistemasexternos con los que este se comunica pero que, en rigor, est fuera del alcancedel sistema objeto de estudio.

Arquitectnicamente, las capas pueden representarse como paquetes de UML.Las relaciones de dependencia representan habitualmente relaciones de uso:en la figura siguiente, la capa de presentacin conoce a dominio; ya que do-minio es la capa que contiene las clases que verdaderamente resuelven el pro-blema (y que tienen la mayor parte de la complejidad y, probablemente, elmayor inters en ser reutilizadas) interesa que el dominio est poco acopladoal resto de capas: por ello, se desacopla el dominio de la presentacin mediante

Ved tambin

Ved tambin los patrones en elapartado 3.6. En particular enel apartado 3.6.2. encontrarisel patrn Fabricacin pura queexplica las clases DAO de la fi-gura.


un susbsistema de servicios (que incluir observadores, patrn que se ver msadelante), y se desacopla (mediante indirecciones, fachadas, fabricaciones pu-ras, proxies, etctera) de las capas de persistencia y comunicaciones (patronestodos ellos que tambin se explican ms adelante).

3.5.2. Arquitectura de pipes and filters (tuberas y filtros)

Los diseos arquitectnicos de pipes and filters se pueden representar como

grafos en los que los nodos se corresponden con filtros17 y los arcos se corres-

ponden con tuberas (pipes)18.

Cada filtro lee cadenas de datos de sus entradas, las transforma (las filtra) yproduce salidas, que deja en las tuberas para que sean ledas por otros filtros.Los filtros son independientes (no comparten su estado con otros filtros) y noconocen ni a sus filtros predecesores ni sucesores.

Un filtro es un elemento que simplemente recibe informacin, la trans-forma y la deja en algn lugar, desentendindose en ese momento.

La arquitectura de pipes and filters se utiliza, por ejemplo, en el desarrollo decompiladores:

Algunas caractersticas de estas arquitecturas son:

(17)Elementos o componentes quetoman entradas y producen sali-das.

(18)Mecanismos de comunicacinentre los nodos.


Es fcil comprender el funcionamiento general del sistema.

Es fcil reutilizar filtros.

El mantenimiento es relativamente sencillo.

Tambin es relativamente sencillo realizar algunos tipos de anlisis espe-cializados, como la identificacin de deadlocks y cuellos de botella.

Es fcil hacer ejecuciones concurrentes, poniendo cada filtro a ejecutarseen un proceso separado.

Sin embargo, son difcilmente aplicables a sistemas interactivos, sirviendocasi exclusivamente para sistemas en lot.

3.5.3. Arquitecturas cliente-servidor

Los sistemascliente-servidor consisten en aplicaciones cuya lgica se encuen-tra distribuida entre dos mquinas remotas: el cliente y el servidor, que se co-munican a travs de algn tipo de middleware. Al construir el sistema, es con-veniente entenderlo como dos sistemas: el cliente se interpreta como un actorque acta sobre el servidor, y el servidor como un actor que acta sobre elcliente:

Con esta consideracin, cada uno de los dos subsistemas puede tener un dise-o arquitectnico diferente, si bien ser necesario que los desarrolladores deambos determinen las responsabilidades que residirn en el cliente y culesresidirn en el servidor. En funcin de esta distribucin, pueden darse diferen-tes situaciones, como por ejemplo las cinco que se muestran a continuacin:

Nota

Los sistemas en lot tambin seconocen como batch.


middleware

middleware

middleware

middleware

middleware

Sistema depresentacinremota(por ejemplo.telnet)

Sistema depresentacindistribuida(por ejemplo,pginas ASP,JSP, etc.)

Sistema dedatos distribuidos(por ejemplo,sistema degestin de unaempresa conmltiplessucursales)

Sistema delgicadistribuida(por ejemplo,un simuladorde prstamos)

Sistema remotode gestin dedatos (porejemplo, uncliente de basede datos)

Lgica depresentacin

Cliente

Lgica depresentacin

Cliente

Lgica de presentacin

Lgica de negocioLgica de datos

Cliente


Lgica de negocio

Cliente


Lgica de negocio

Cliente

Lgica dedatos

Servidor

Lgica de datos

Servidor


Lgica de negocioLgica de datos

Servidor

Lgica de negocio

Lgica de datos

Servidor

Lgica de negocio

Lgica de datos

Servidor

3.5.4. Arquitecturas P2P (peer-to-peer, de igual a igual)

En este caso, dos sistemas iguales se relacionan entre s. A muy alto nivel, unsistema P2P puede entenderse como un sistema que se relaciona con otrossistemas que son como l: obsrvese, en la figura, que el nombre del sistema(Sistema P2P) coincide exactamente con el nombre del actor con el que secomunica:


En realidad, los dos sistemas pueden ser diferentes, pero deben comunicarseentre s ofreciendo e implementando las mismas interfaces. Estas, junto consu implementacin, pueden incluirse en un componente reutilizable que seintegre en diferentes tipos de clientes P2P. Con una notacin algo libre, aun-que tipo UML, podemos representar esto de la siguiente forma:

Para implementar las interfaces y permitir la comunicacin entre los pares sepuede reutilizar Gnutella, un protocolo para compartir archivos entre paresque es P2P puro: no hay servidor central y todos los nodos tienen exacta-mente las mismas funciones dentro de la red. Gnutella define la sintaxis de losmensajes para que un nodo se enlace a una red ya existente, busque archivosdentro de la red y descargue archivos.

3.6. Patrones de diseo

Los patrones de diseo son soluciones buenas a problemas de diseo de soft-ware que se presentan frecuentemente. De hecho, para que una solucin sepueda considerar un patrn, debe haber sido probada con xito en ms deuna ocasin. La solucin, adems, se debe describir de forma suficientementegeneral como para que sea reutilizable en contextos diferentes.

Como se ver, muchos patrones requieren la aplicacin de niveles sucesivosde indireccin (es decir, en lugar de enviar el mensaje directamente al objetointeresado, se le enva a un intermediario) que, en muchos casos, pueden apa-rentar ser demasiado artificiales. Por lo general, todos los patrones persiguenel diseo de sistemas con alta cohesin y bajo acoplamiento, lo que produ-ce elementos software ms reutilizables. A veces, sin embargo, la utilizacinexagerada de patrones puede dar lugar a diseos muy complejos, difciles deseguir y entender, lo que puede dificultar su mantenimiento.

El conjunto de patrones ms conocido es el de Gamma y colaboradores, que en1995 publicaron un clebre libro titulado Design Patterns: Elements of ReusableObject-Oriented Software, del que se han imprimido multitud de ediciones yha sido traducido a numerosos idiomas. Otros autores, como Craig Larman,han publicado tambin libros muy exitosos de ingeniera del software en los

Nota

En la asignatura Anlisis y dise-o con patrones del grado deIngeniera Informtica ya sedescriben muchos de estos pa-trones. En este texto intenta-mos presentarlos con un pun-to de vista ms orientado a lareutilizacin.


que incluyen sus propios catlogos de patrones: en el caso de Larman, a estospatrones se los conoce como patrones GRASP (general responsibility assignmentsoftware patterns, patrones generales de asignacin de responsabilidades).

3.6.1. Patrones de Gamma

En su libro Gamma, y otros presentan 23 patrones agrupados en tres catego-ras:

Patronesdecreacin, que pretenden resolver el problema de cmo crearobjetos complejos.

Patronesestructurales, que describen soluciones acerca de cmo unir ob-jetos para que formen estructuras complejas.

Patronesdecomportamiento, que presentan algoritmos y mecanismospara comunicar objetos.

A continuacin se describen algunos de ellos.

Patrn de creacin abstract factory (fbrica abstracta)

Supongamos que debemos crear un sistema de software para jugar a diferentestipos de juegos de mesa: damas, ajedrez, parchs y trivial. Adems de sus pro-pias reglas y polticas de gestin del turno, cada juego tiene un tipo diferentede tablero y unas piezas distintas. Aprovechando esta estructura comn de losjuegos, podemos crear una estructura de clases abstractas para representar lostres juegos en general:

El nmero de especializaciones de estas clases abstractas depender del nme-ro de juegos y de las caractersticas especficas de cada juego:


A la hora de crear un objeto de, por ejemplo, clase Ajedrez, ser preciso instan-ciar un tablero de ajedrez, varias piezas (peones, alfiles, etctera) de colores di-versos y su poltica concreta de gestin del paso del turno entre los jugadores.El patrn abstract factory nos ayuda a resolver la siguiente pregunta:

A quin asignar la responsabilidad de crear una familia de objetos complejos?

La respuesta es asignrsela a una clase externa que fabrique los objetos. Habruna fbrica abstracta y tantas especializaciones concretas como familias deobjetos haya:

Cada fbrica concreta es responsable de crear todos los objetos correspondien-tes a la familia de objetos a la que est asociada. La FabricaAjedrez, por ejem-plo, brega solamente con los subtipos de Tablero, Pieza y GestionDelTurno quele corresponden:


La implementacin del mtodo crearJuego() en, por ejemplo, FabricaAjedrez serde este estilo:

public Juego crearJuego() { Juego resultado=new Ajedrez(); resultado.setTablero(new TableroAjedrez()); resultado.setPiezas(buildPiezas()); resultado.setTurno(new TurnoAjedrez()); return resultado;}

Patrn de creacin builder (constructor)

El builder proporciona una solucin diferente al mismo problema planteadoen el abstract factory. En esencia, la diferencia radica en que ahora uno delos objetos de la familia es el responsable de crear el resto de objetos. Si enel ejemplo asignamos a la clase juego las responsabilidades de construir losobjetos, el cdigo de la clase puede tomar esta forma:


public abstract class Juego { private Tablero tablero; private Vector piezas; private GestionDelTurno turno;

public Juego() { this.tablero=crearTablero(); this.piezas=crearPiezas(); this.turno=crearTurno(); }

protected abstract Tablero crearTablero(); protected abstract Vector crearPiezas(); protected abstract GestionDelTurno crearTurno();}

El cdigo anterior muestra tambin un ejemplo del patrn de comportamientotemplate method (mtodo-plantilla): obsrvese que, desde una operacin con-creta (el constructor Juego()) de una clase abstracta (Juego), se est llamando atres operaciones declaradas como abstractas en la propia clase (crearTablero(),crearPiezas() y crearTurno()). El patrn mtodo-plantilla describe el comporta-miento genrico de una jerarqua de objetos, pero dejando a las subclases laresponsabilidad concreta de ejecutar las operaciones: en el constructor, se diceque lo primero que hay que hacer es crear el tablero, luego las piezas y luego elsistema de gestin del turno; sin embargo, deja a las clases concretas (ajedrez,damas, parchs y trivial) la responsabilidad concreta de cmo hacerlo.

Patrn de creacin singleton (creacin de una nica instancia)

En ocasiones es necesario garantizar que, para alguna clase, puede crearse unmximo de una instancia: puede interesar, por ejemplo, dotar al sistema de unnico punto de acceso a una base de datos externa, de manera que este puntode acceso gestione las mltiples conexiones que puedan establecerse.

Para garantizar que se crea una sola instancia de este punto de acceso (que,por otra parte, puede entenderse como un patrn proxy o un patrn broker, agente de base de datos, de Larman), la clase que lo implementa puede serun singleton. Por lo general, un singleton tiene:

Un campo esttico del mismo tipo que la clase singleton que, por ejemplo,se llama yo.

Un constructor de visibilidad reducida (privado o protegido).

Un mtodo pblico esttico para recuperar la nica instancia existentede la clase que, por ejemplo, puede llamarse getInstancia. Al llamar a estemtodo, se pregunta si existe yo (es decir, si es distinto de null): si yo sque es distinto de null, el mtodo devuelve la instancia; si no, se llama alconstructor (que s que es visible para getInstancia), con lo que se construyeyo y despus se devuelve la instancia recin creada.


El conjunto de mtodos de negocio que corresponda, que no tienen porqu ser estticos.

El siguiente cdigo muestra un ejemplo de un agente de base de datos single-ton que, a pesar de ser nico, es capaz de gestionar hasta 1.000 conexionessimultneas a la base de datos: cuando un cliente necesita ejecutar una ope-racin sobre la base de datos, en lugar de crear l mismo su propia conexin,recupera el agente (llamando a getInstancia); una vez que tiene la referencia alagente, el cliente puede pedirle a este que le devuelva la conexin.

Patrn estructural adapter (adaptador)

Este patrn se aplica cuando una clase cliente desea utilizar otra clase servidoraque, sin embargo, le ofrece una interfaz diferente de la que espera el cliente.Lo veremos con cierto detalle en la seccin de componentes.

Patrn estructural composite (compuesto)

En ocasiones, un objeto est formado por objetos que, a su vez, poseen ensu interior objetos que son de la clase del objeto original. En el procesadorde textos Microsoft Word, por ejemplo, es posible agrupar varios objetos de


dibujo en un grupo; este grupo se maneja como un nico objeto, y puedeser tambin agrupado junto a otros objetos, de forma que un grupo puedecontener, mezclados, objetos simples y grupos. La siguiente figura muestracuatro objetos sencillos dibujados con Word (a); en el lado izquierdo de (b)creamos un grupo a partir de dos objetos, que ya se muestran agrupados en ellado derecho; en el lado izquierdo de (c), creamos un nuevo grupo formadopor el grupo creado anteriormente y un nuevo objeto simple, cuyo resultadose muestra a la derecha.

Todos estos objetos de dibujo pueden responder, por ejemplo, a una operacinsetGrosor(pixels:int), que asigna el grosor que se pasa como parmetro a las lneasque conforman el dibujo, o a rellenar (color:Color) para rellenar la figura conel color que se establezca. Para manejar de manera uniforme todo el grupo defiguras se puede utilizar el patrn Composite, en el que las figuras simples ycompuestas se representan de esta manera:

Se est diciendo que las figuras pueden ser figuras simples (cuadrados, crculos,aspas o caras sonrientes) o figuras compuestas (grupos); estas, a su vez, estnformados por figuras que tambin pueden ser simples o compuestas. Como seobserva, todas las subclases son concretas, lo que significa que implementanlas dos operaciones abstractas que se muestran en la superclase. Las figurassimples darn a las operaciones la implementacin que corresponda; la im-


plementacin de estas operaciones en grupo, sin embargo, consistir en llamara la misma operacin en todas las figuras a las que conoce, que son accesiblesa travs de la relacin de agregacin:

public void setGrosor(int grosor) { for (Figura f : elementos) f.setGrosor(grosor);}

En tiempo de ejecucin se decidir, en funcin del tipo de los objetos conte-nidos en el grupo, qu versin de la operacin debe ejecutarse.

Patrn estructural faade (fachada)

Una fachada representa un punto de acceso nico a un subsistema. Si en unaaplicacin multicapa disponemos de varias ventanas en la capa de presenta-cin y de varias clases en la capa de negocio, puede ser conveniente crear unafachada que represente el punto de acceso nico desde la capa de presentacina la de dominio. Cuando un objeto de presentacin le quiere decir algo a unode dominio, no se lo dir directamente, sino que le har la peticin a la facha-da, que la encaminar al objeto de dominio que corresponda.

Patrn estructural proxy

Un proxy representa un sustituto de algo que, por lo general, ser un sistemao dispositivo externo. En lugar de permitir que cualquier parte del sistema ac-ceda directamente al sistema externo, colocamos un proxy intermedio que sersu nico punto de acceso. Podemos considerar que una fachada es un proxyde acceso a un subsistema, y es cierto; cuando utilizamos una clase intermediapara acceder a un sistema o dispositivo externo (un servidor o un escner, porejemplo), lo llamaremos proxy. Los proxies, en muchas ocasiones, son ademsclases singleton.

La siguiente figura completa uno de los diseos arquitectnicos que mostr-bamos al hablar de los estilos arquitectnicos cliente-servidor con dos proxies:uno en el sistema cliente para acceder al servidor; otro en el servidor para co-municar con los clientes. El servidor, adems, ofrece sus servicios a travs deuna fachada (que, por otro lado, ha de implementar algn tipo que permitala comunicacin remota); el cliente escucha al servidor a travs de un listener,que puede entenderse como una fachada ms simplificada.


Patrn de comportamiento chain of responsibility (cadena de res-ponsabilidad)

Este patrn se utiliza para desacoplar al objeto emisor de una peticin delobjeto que debe recibirla. La idea pasa por tener una cadena de objetos quepasen la peticin hasta que aparezca un objeto que sea capaz de atenderla.

La solucin se modela como una superclase abstracta con una operacin abs-tracta que se corresponde con la peticin; esta clase, adems, conoce a un ob-jeto de su mismo tipo, al que se llama sucesor. Todas las subclases concretasimplementan la operacin: las que pueden atender la peticin, la atienden;las que no, la derivan al sucesor, que estn heredando de la superclase.

Patrn de comportamiento mediator (mediador)

A veces, un cambio en un objeto cualquiera de una familia de objetos debe sernotificado a todo el resto de objetos. Supongamos que tenemos cinco clasescuyas instancias deben estar al tanto de los cambios de estado que se producenen los objetos de las otras cuatro. Una solucin posible es estructurar el sistemade tal manera que todas las clases se conozcan entre ellas, como se muestraen esta figura:

Este diseo, sin embargo, es difcil de comprender, de mantener y de probar,y tiene un altsimo acoplamiento que, probablemente, lo haga muy propensoa fallos. El patrn mediador aconseja la creacin de una clase que reciba lasnotificaciones de los cambios de estado y que las comunique a las interesadas:


El patrn admite variantes que aprovechan la herencia: si, por ejemplo, loscambios de estado de A solo interesan a B, C y D, los de B solo a A, C y D,los de C solo a D y E, y los dems no interesan, se puede replantear el diseode esta manera:

Patrn de comportamiento observer (observador)

Si en el patrn anterior se resolva el problema de cmo notificar cambios enmltiples objetos a otros mltiples objetos, el patrn observador da una solu-cin a cmo notificar los cambios de estado de un nico objeto a un conjuntode objetos que lo estn observando.

La solucin consiste en la creacin de una clase intermedia (el observador),a la que suscriben los objetos interesados en observar al objeto observable.Cuando este experimenta un cambio de estado, lo comunica al observador,que lo notifica a los objetos que mantiene suscritos.

El patrn alta cohesin (uno de los patrones de Larman), que se presenta msadelante, incluye un ejemplo del patrn observador.


Patrn de comportamiento state (estado)

Este patrn delega en una clase asociada aquellas operaciones cuyo compor-tamiento depende de su estado. Supongamos que la operacin retirar() de unacuenta corriente depende de si su estado es positivo o negativo: la operacinpuede implementarse en la propia clase cuenta y, antes de efectuar la retirada,preguntar si el saldo es suficiente para afrontar el importe que desea retirarse.Mediante el patrn estado, se crea una clase abstracta estado con dos especia-lizaciones: positivo y negativo. Cuando a la clase cuenta le llega una llamadaa retirar(), esta invoca a la operacin retirar de su estado asociado, que estarinstanciado a una de las dos subclases.

Patrn de comportamiento template-method (mtodo plantilla)

Este patrn se utiliza para representar de manera general el comportamientode una determinada operacin: en una clase abstracta se crea una operacinconcreta que llama a operaciones abstractas y concretas.

Mostrbamos un ejemplo de cdigo al presentar el patrn builder, que corres-ponde a la siguiente clase en UML:

3.6.2. Patrones de Larman

Larman presenta nueve patrones que ayudan al ingeniero de software a deter-minar a qu objeto se le debe asignar cada responsabilidad. El autor explica

que las responsabilidades de los objetos son de dos tipos: de conocer19 y de

hacer20.

(19)Sus propios datos, los de obje-tos relacionados, y otras cosas quepuede derivar o calcular.

(20)Puede hacer algo el propio ob-jeto, puede iniciar una accin enotro objeto o puede coordinar ycontrolar actividades entre objetos.


Patrn experto

Este patrn nos dice que la responsabilidad debe asignarse a la clase expertaen la informacin: es decir, a aquella clase que tiene la informacin necesariapara realizar la responsabilidad.

Patrn creador

Este patrn dice que se debe asignar a la clase A la responsabilidad de crearinstancias de B cuando:

A agrega o contiene objetos de B A registra objetos de B A utiliza ms estrechamente objetos de B A tiene la informacin de inicializacin necesaria para crear instancias de B

Patrn bajo acoplamiento

El acoplamiento indica el grado en que una clase est relacionada con otras:cuanto mayor sea el acoplamiento, mayor dependencia de la clase respectode cambios en las otras. Adems, en diversos estudios experimentales se hacomprobado que el alto acoplamiento es el mejor indicador de la propensina fallos de una clase.

Ms que un patrn, el mantenimiento del bajo acoplamiento es unprincipio general de diseo de software, incluyendo diseo de softwareorientado a objetos.

La clase A est acoplada a B cuando:

A tiene un atributo de tipo B. A invoca a algn mtodo de B. En algn mtodo de A se declara una

Desarrollo de Software Basado en Reutilizacion

Documents

Transcript of Desarrollo de Software Basado en Reutilizacion