Tesis Grado Ingenieria Informatica

Tesis de grado en Ingeniera en Informtica
Utilizacin de programacin orientada a aspectos en aplicaciones enterprise
Tesista: Nicols Martn Paez Directora: Lic. Rosita Wachencha zer !echa: No"iem#re $%%&
Resumen
Las aplicaciones enterprise son aplicaciones ' e dan soporte a los procesos de negocio de na organizacin. (omo tales) se caracterizan por mane*ar grandes "ol+menes de in,ormacin persistente) la c al es accedida en ,orma conc rrente por "arios s arios mediante di"ersas inter,aces de s ario. -stas aplicaciones de#en e"ol cionar de ,orma rpida ante los cam#ios del negocio) pro"ocando el menor impacto posi#le. -sta necesidad de rpida e"ol cin o#liga a ' e estas aplicaciones de#an c mplir con ciertos atri# tos t.cnicos / de calidad como escala#ilidad) manteni#ilidad) transaccionalidad) etc. La implementacin de dichos atri# tos res lta ser de di,cil mod larizacin c ando se tilizan las t.cnicas tradicionales de programacin. -s a' donde la programacin orientada a aspectos entra en * ego. -sta t.cnica de programacin s rgida a ,ines de los 0%1 / con importante crecimiento en los +ltimos a2os) # sca ,acilitar la mod larizacin de a' ellas inc m#encias trans"ersales ' e res ltan de di,cil mod larizacin con las t.cnicas tradicionales de programacin. -l o#*eti"o del presente tra#a*o es analizar la tilizacin de la programacin orientada aspectos en las aplicaciones enterprise) proponiendo sol ciones #asadas en aspectos para las pro#lemticas caractersticas de dichas aplicaciones / mostrando s re,erencia. so mediante el desarrollo de na aplicacin de
Nicols M. Paez
2 - 110
Agradecimientos
3 mi mam 4il"ia / a mi hermano 5ermn por s apo/o incondicional / s aliento contin o.
3 (ot/) por s paciencia in,inita d rante esta larga carrera.
3 Rosita) directora de este tra#a*o) por s con,ianza en mi / s paciencia.
3 (arlos por s s comentarios constr cti"os.
3 Marcio) a !ran) a (aro / a todo el e' ipo de Nardolandia) por las e6periencias compartidas.
3 los pro,esores) compa2eros) amigos / colegas) ' e de na tra#a*o.
otra ,orma han cola#orado en este
Nicols M. Paez
3 - 110
7ndice
(apit lo 8: 8ntrod ccin............................................................................................................................. & Pro#lemtica.......................................................................................................................................... & 9#*eti"o................................................................................................................................................. & 3lcance.................................................................................................................................................. : 9rganizacin de la tesis.........................................................................................................................: Notas para el lector................................................................................................................................ 0 Notaciones........................................................................................................................................ 0 Trad cciones.....................................................................................................................................0 ;erramientas tilizadas.....................................................................................................................0 Material adicional............................................................................................................................. 0 (apit lo 88: Programacin orientada a aspectos.......................................................................................<% 8ntrod ccin.........................................................................................................................................<% -l pro#lema.....................................................................................................................................<% Desarrollo de so,t=are orientado a aspectos...................................................................................<$ -lementos del paradigma.................................................................................................................... <> ?oinpoint......................................................................................................................................... <> Poinc t............................................................................................................................................ <@ 3d"ice.............................................................................................................................................<@ Declaraciones de intertipo.............................................................................................................. <A 3specto........................................................................................................................................... <A 4ol cin 39P al e*emplo planteado...............................................................................................<& ;erramientas 39P...............................................................................................................................<: Tipos de herramientas.....................................................................................................................<: 3spect?) el g.nesis.......................................................................................................................... $< 4pring !rame=orB) el promotor..................................................................................................... $$ -stado del arte..................................................................................................................................... $$ Usos de 39P...................................................................................................................................$$ Los r m#os de la com nidad.......................................................................................................... $$ (apit lo 888: 3plicaciones enterprise....................................................................................................... $> 8ntrod ccin.........................................................................................................................................$> 3tri# tos de calidad.............................................................................................................................$@ Disponi#ilidad.................................................................................................................................$A Desempe2o Cper,ormanceD..............................................................................................................$A -scala#ilidad...................................................................................................................................$A (on,ia#ilidad CRelia#ilit/D..............................................................................................................$& Manteni#ilidad Cmodi,ia#ilit/D....................................................................................................... $& Re sa#ilidad................................................................................................................................... $& Eeri,ica#ilidad Ctesta#ilit/D.............................................................................................................$: Usa#ilidad....................................................................................................................................... $: 4eg ridad........................................................................................................................................ $: 8nteropera#ilidad.............................................................................................................................$0 (onsideraciones so#re los atri# tos de calidad.............................................................................. $0 Re' isitos t.cnicos.............................................................................................................................. $0 Persistencia..................................................................................................................................... F% Transaccionalidad........................................................................................................................... F% Distri# cin.................................................................................................................................... F< (onc rrencia...................................................................................................................................F< Monitoreo....................................................................................................................................... F$
Nicols M. Paez 4 - 110
3r' itect ra......................................................................................................................................... F$ Patrones de dise2o.......................................................................................................................... F> 9rientacin a ser"icios....................................................................................................................F@ Tecnologas..........................................................................................................................................FA (apt lo 8E: ;acia las aplicaciones enterprise con 39P.........................................................................F: 8ntrod ccin.........................................................................................................................................F: 8nc m#encias trans"ersales................................................................................................................. F: 8ntentos de mod larizacin..................................................................................................................F0 4er"idores de aplicaciones / componentes.....................................................................................F0 !rame=orBs de aplicacin.............................................................................................................. >% Gi#liotecas enterprise......................................................................................................................>> 39P 3lliance..................................................................................................................................>@ Mitos / le/endas..................................................................................................................................>@ 39P considered harm, l................................................................................................................ >A 39P "iola el encaps lamiento........................................................................................................>: Dep rar aplicaciones con 39P es di,cil........................................................................................>: 39P / Patrones de Dise2o............................................................................................................. >: La piedra en el zapato..................................................................................................................... >0 39P / 3spect? no son sinnimos...................................................................................................@% Pros / contras seg+n la ind stria.................................................................................................... @% Proceso de adopcin....................................................................................................................... @< 3r' itect ra #ase sin 39P.................................................................................................................. @$ (apt lo E: 8nc m#encias t.cnicas.......................................................................................................... @@ (onsideraciones preliminares..............................................................................................................@@ Monitoreo / a ditora.......................................................................................................................... @@ Pro#lemtica................................................................................................................................... @@ 4ol cin 39P................................................................................................................................. @& Persistencia.......................................................................................................................................... @& Transaccionalidad................................................................................................................................@0 Pro#lemtica................................................................................................................................... @0 4ol cin 39P................................................................................................................................. A% (aching................................................................................................................................................A< Pro#lemtica................................................................................................................................... A< 4ol cin 39P................................................................................................................................. A$ Mane*o de e6cepciones........................................................................................................................AF Pro#lemtica................................................................................................................................... AF 4ol cin 39P................................................................................................................................. A> 3 tenticacin / a torizacin............................................................................................................... AA Pro#lemtica................................................................................................................................... AA 4ol cin 39P................................................................................................................................. A& Distri# cin) conc rrencia / sincronizacin....................................................................................... A: Pro#lemtica................................................................................................................................... A: 4ol cin 39P................................................................................................................................. A0 9tras inc m#encias............................................................................................................................. &% Res miendo......................................................................................................................................... &< (apt lo E8: 8nc m#encias del negocio................................................................................................... &$ (onsideraciones preliminares..............................................................................................................&$ -l dominio / la lgica de negocio.................................................................................................. &$ 8mplementacin de aspectos del negocio........................................................................................&$ (aso de est dio: Ganco H....................................................................................................................&F 8nc m#encias trans"ersales en el negocio del GancoH....................................................................... &> 5eneralizando las reglas de negocio................................................................................................... &:
-l rol de los aspectos........................................................................................................................... &: Res miendo......................................................................................................................................... :% (apit lo E88: La ,oto completa................................................................................................................ :< 3r' itect ra -nterprise 39PI(ompati#le.......................................................................................... :< ;erramientas 39P seleccionadas...................................................................................................:$ (aso de est dio: Ganco H Gis............................................................................................................. :F (asos de so / reglas de negocio....................................................................................................:F 4ol cin tradicional Csin 39PD.......................................................................................................:@ 4ol cin 39P................................................................................................................................. :0 (omparacin de sol ciones............................................................................................................ 0@ (apit lo E888: (oncl siones.................................................................................................................... 00 3p.ndice 8: ;erramientas 39P............................................................................................................. <%< 3spect.N-T....................................................................................................................................... <%< 4pring 39P....................................................................................................................................... <%$ 3p.ndice 88: Patrones de dise2o.............................................................................................................<%> ModelIEie=I(ontroller..................................................................................................................... <%> Transaction 4cript..............................................................................................................................<%> Domain model................................................................................................................................... <%> 4er"ice La/er.....................................................................................................................................<%> Datamapper........................................................................................................................................<%> Data Trans,er 9#*ect......................................................................................................................... <%@ Dependenc/ 8n*ection........................................................................................................................ <%@ Gi#liogra,a............................................................................................................................................ <%A
Nicols M. Paez
6 - 110
(apit lo 8: 8ntrod ccin

Pro#lemtica
La e"ol cin de la in,ormtica / de las telecom nicaciones en las +ltimas dos d.cadas ha colocado a los sistemas in,ormticos en n rol preponderante dentro de las organizaciones) llegando incl so en alg nos casos a prod cir cam#ios radicales en el negocio. -sta sit acin se ha "isto potenciada por el a ge de internet) dando origen a n e"os modelos de negocio) donde los sistemas in,ormticos ,orman parte del corazn del negocio. -ntre las organizaciones ms representati"as de estos cam#ios) p eden citarse los sitios de remate / compra en lnea) como eGa/ / 3mazon. -n este conte6to) los departamentos de sistemas se han "isto ,orzados a responder de ,orma inmediata a los cam#ios del negocio) lo c al ha planteado n interesante desa,o a ' ienes de#en dise2ar las aplicaciones) /a ' e decisiones errneas en el dise2o) p eden res ltar m / costosas en el mediano / largo plazo c ando na aplicacin de#a e"ol cionar. -stas aplicaciones ' e dan soporte a los procesos de negocio de na organizacin han sido denominadas aplicaciones enterprise C3-D. -l desa,o ' e proponen estas aplicaciones enterprise a los pro,esionales de sistemas tam#i.n ha tenido reperc sin en los m#itos acad.micos) donde ha imp lsado n e"as reas de in"estigacin relacionadas a la ingeniera de so,t=are. (omo resp esta a este n e"o escenario planteado por las aplicaciones enterprise) es ' e en los +ltimos a2os han s rgido n e"as tendencias) como los m.todos de desarrollo gil / la orientacin a ser"icios. -ntre estas n e"as tendencias se enc entran las t.cnicas a"anzadas de separacin de inc m#encias) las c ales pretenden o,recer herramientas para lograr na me*or mod larizacin de la aplicaciones. -sta temtica ha despertado el inter.s de "arios re,erentes de la ind stria / del m ndo acad.mico) dando origen a la com nidad de desarrollo de so,t=are orientado a aspectos C3spectI oriented 4o,t=are De"elopment) 394DDJ394DK. Una de las t.cnicas ms pop larizadas dentro de este rea de in"estigacin es la programacin orientada a aspectos C3spectIoriented Programming) 39PD. M+ltiples tra#a*os han prop esto el so de 39P para la resol cin de ciertas pro#lemticas ' e a,ectan a las aplicaciones enterprise como seg ridad) mane*o de e6cepciones / persistencia. Los tra#a*os ms destacados en este sentido son los de Rod ?ohnson / Rena d Pa=laB.
9#*eti"o
-l o#*eti"o de la presente tesis es analizar la tilizacin de la programacin orientada a aspectos en el desarrollo de aplicaciones enterprise) repasando / e6tendiendo lo prop esto por ?ohnson /
Nicols M. Paez - 110
Pa=laB) pero centrandonos tecnolgicamente en la plata,orma .N-T. 3 lo largo del tra#a*o se analizarn las pro#lemticas de las 3- en las ' e el so de 39P podra res ltar #ene,icioso. L ego del anlisis) se plantear el caso de na aplicacin hipot.tica para mostrar como implementar so#re plata,orma .N-T las prop estas desarrolladas.
3lcance
-l tra#a*o est centrado en las dos pro#lemticas ' e se consideran distinti"as de las aplicaciones enterprise: los atri# tos t.cnicos C/ de calidadD / la lgica de negocio. L eda e6plcitamente , era de alcance el anlisis de las c estiones relacionadas a la capa de presentacin e interaccin con el s ario como as tam#i.n la in,l encia de 39P en el proceso de desarrollo de so,t=are.
9rganizacin de la tesis
-l presente tra#a*o est estr ct rado en res midamente a contin acin: na serie de capt los) c /o contenido se descri#e
<. Introduccin: descri#e la pro#lemtica en,rentada / o#*eti"os del presente tra#a*o. $. Programacin orientada a aspectos: introd ce al lector en el paradigma de la programacin orientada aspectos) presentado los conceptos centrales) s s #ene,icios / limitaciones. 3l mismo tiempo se presentan alg nas herramientas destacadas ' e implementan el paradigma / se hace n #re"e res men del estado del arte en la materia. F. Aplicaciones enterprise: trata so#re las aplicaciones enterprise) caracterizndolas / descri#iendo las ar' itect ras / tecnologas ms implementacin. >. Hacia las aplicaciones enterprise con AOP: prepara el terreno para comenzar a atacar el o#*eti"o principal de la tesis) se identi,ica la tilidad ' e podra tener 39P en el desarrollo de las 3- / se analizan alg nos mitos / le/endas so#re 39P. -l capt lo ,inaliza descri#iendo la ar' itect ra de #ase so#re la ' e se plantear el resto del tra#a*o. @. Incumbencias tcnicas: analiza las inc m#encias t.cnicas caractersticas de las 3-. Para cada inc m#encia identi,icada se mencionan las sol ciones act ales / se propone Ic ando aplicaI na sol cin #asada en 39P. A. Incumbencias del negocio: analiza las inc m#encias del negocio so#re na aplicacin tilizadas en la act alidad para s
concreta) proponiendo el so de 39P para el modelado de ciertas inc m#encias de negocio. &. La foto completa: descri#e de ,orma completa la pro#lemtica de na 3-) para la c al se plantea na sol cin tradicional / otra sol cin #asada en 39P.
Nicols M. Paez ! - 110
:. Conclusiones: descri#e los res ltado del tra#a*o de in"estigacin) las concl siones e6tradas del mismo / alg nas posi#le lneas de in"estigacin.
3dicionalmente a los capt los mencionados) el tra#a*o o,rece cierto contenido adicional en ,orma de ap.ndices para a' ellos lectores ' e deseen pro, ndizar so#re temas ' e no hacen al c erpo principal de conocimiento de la tesis.
Notas para el lector

3 contin acin se hacen alg nas aclaraciones ' e p eden res ltar de tilidad para el lector del presente tra#a*o.
Notaciones
3 lo largo del tra#a*o se mostrar cdigo en leng a*e (M / ?a"a) por ser los principales leng a*es tilizados en la act alidad para el desarrollo de aplicaciones enterprise. 3 la hora de mostrar cdigo 39P) se tilizar na notacin gen.rica) con el ,in de ' e res lte clara e int iti"a para el lector. Para com nicar c estiones de dise2o se tilizar la notacin prop esta por el leng a*e ni,icado de modelado) pero dado ' e no ha/ na e6tensin +nica estandarizada para la representacin de aspectos) se ha decidido tilizar na notacin adIhoc.
Traducciones
4e ha decidido no trad cir alg nos t.rminos) principalmente a' ellos re,erentes a terminologa espec,ica de 39P. -sto se de#e a ' e e6iste escasa doc mentacin en castellano) / a"ent rarse a na trad ccin no res lta apropiado.
Herramientas utilizadas
Para la redaccin de este tra#a*o se tiliz el pa' ete de o,icina 9pen 9,,ice. Los diagramas , eron realizados con Rational 4o,t=are Modeler. La aplicacin de re,erencia , e desarrollada tilizando el entorno de desarrollo Microso,t Eis al 4t dio $%%@ Team De"eloper -dition. Los gr,icos de la aplicacin de re,erencia , eron realizados con Paint.N-T.
Material adicional
Tanto el presente te6to) como el cdigo , ente del caso de est dio / alg nos materiales complementarios tilizados /No generados d rante la ela#oracin de esta tesis p ede encontrarse en la sig iente #icacin: http:NN===.,i. #a.arNOnpaez.
Nicols M. Paez " - 110
(apit lo 88: Programacin orientada a aspectos

8ntrod ccin
El problema
Desde s s comienzos los leng a*es de programacin han e"ol cionado pro"e/endo cada "ez me*ores t.cnicas de mod larizacin. 4in d da la programacin orientada a o#*etos CP99D ha sido na de las t.cnicas de mod larizacin ms potentes) pero a pesar de ello sig en e6istiendo ciertas incumbencias CconcernsD ' e ni la P99 ni las t.cnicas precedentes de programacin han logrado mod larizar de manera e,ecti"a. La di,ic ltad de mod larizar estas inc m#encias) se de#e a ' e las t.cnicas tradicionales de programacin pro"een la posi#ilidad de descomponer el pro#lema de ac erdo a na +nica dimensin Cla dominanteD) permitiendo n e,ecti"a mod larizacin de las inc m#encias de dicha dimensin a costa de sacri,icar na # ena mod larizacin de las inc m#encias de las dems dimensiones. -ste pro#lema ha sido denominado Pla tirana de la descomposicin dominanteQ JTarr00K / como consec encia del mismo las inc m#encias de las dimensiones no dominantes ad' ieren na nat raleza trans"ersal ' e les otorga el nom#re de incumbencias transversales CcrossIc tting concerns) (((D. (omo consec encia directa de estos ((( aparecen dos ,enmenos no deseados. -l primero de ellos es denominado cdigo disperso Ccode scatteringD / se da c ando e6isten in"ocaciones a n m.todo esparcidas por toda la aplicacin. -l seg ndo de estos ,enmenos es el llamado cdigo mezclado Ccode tanglingD / se da c ando na clase tiene cdigo ' e nada tiene ' e "er con s esencia) lo c al dismin /e s cohesin / "iola no de los principios #sicos del dise2o de o#*etos: el principio de +nica responsa#ilidad. -ntre las consec encias de estos dos ,enmenos se c entan acoplamiento) di,ic ltad de mantenimiento) menor claridad del cdigo / todas las dems consec encias de mod larizacin. Para comprender me*or esta pro#lemtica "eamos n e*emplo. 4 pongamos na simple na po#re
aplicacin de #anca electrnica donde los clientes de n #anco p eden cons ltar el estado de s s c entas) realizar trans,erencias de ,ondos / administrar s s datos personales. 3dicionalmente consideremos los sig ientes dos re' isitos) consec encia de las polticas operacionales del #anco.
Los datos del cliente / de s s c entas slo p eden ser modi,icados por s arios con los
10 - 110
Nicols M. Paez
correspondientes permisos.
Toda modi,icacin de datos realizada en la aplicacin de#e ser a ditada de*ando constancia de la modi,icacin realizada / del momento de la modi,icacin.
Figura 1: Diagrama de clases del dominio de banca electrnica
La ,ig ra < m estra n posi#le diagrama de clases simpli,icado para el mencionado conte6to. (omo es de esperar si tilizamos n en,o' e orientado a o#*etos) tendremos na clase Cliente / na *erar' a de clases CuentaBancaria ' e contempla los distintos tipos de c enta. Tanto la clase Cliente como CuentaBancaria) tienen m.todos verificarPermisos / auditarCambios) ' e claramente e6ceden la esencia de cada clase. Tal como est planteada esta sol cin) los dos m.todos en c estin estn e6presando la e6istencia de dos inc m#encias trans"ersales: a torizacin / a ditoria<. ;asta el momento) estas inc m#encias trans"ersales no representan ma/or pro#lema) pero s pongamos ' e na "ez terminada la aplicacin) nos piden alg nos cam#ios.
Modi,icar la ,orma en ' e se a ditan los datos de#ido a ' e se re' iere ms detalle de in,ormacin.
(ontemplar n n e"o tipo de c enta) PlazoFijo)con na poltica distinta de permisos.
Por como est planteada esta sol cin) estos cam#ios implicaran la modi,icacin de las clases Cliente / CuentaBancaria para re,le*ar los cam#ios en la a ditoria. 3l mismo tiempo de#era agregarse na n e"a clase PlazoFijo) la c al tam#i.n de#era contemplar las c estiones de la "eri,icacin de permisos / a ditoria. Gien) aplicados estos cam#ios) la sol cin sig e , ncionando) pero ha/ alg nas c estiones a
< 4i #ien la sol cin planteada p ede no ser la ms ptima) s simplicidad permite poner de rele"ancia la e6istencia de las inc m#encias trans"ersales.
considerar.
3 pesar ' e ning no de los re' isitos de cam#io menciona#a e6plcitamente al cliente) la clase Cliente de#i ser modi,icada.
-l agregado de n n e"o concepto del dominio Cplazo ,i*oD) nos implic no slo la creacin de na n e"a clase) sino ' e adems se de#i contemplar c estiones adicionales como lo son la a ditoria / la a torizacin.
Los dos p ntos anteriores ponen de rele"ancia na "ez ms) la nat raleza trans"ersal de la a torizacin / la a ditoria.
;a#iendo entendido las des"enta*as de la sol cin planteada en c anto al mane*o de las inc m#encias trans"ersales no podra hacer so de alg nas t.cnicas de dise2o) como patrones o prcticas de re,actoring) con el ,in de lograr na sol cin ' e mane*e de me*or ,orma las inc m#encias trans"ersales. Una de las t.cnicas de ,acti#le aplicacin es la orientacin a aspectos.
Figura 2: Incumbencias transversales en las clases del dominio de banca electrnica
Desarrollo de software orientado a aspectos
-l desarrollo de so,t=are orientado a aspectos constit /e n rea de in"estigacin centrada en lograr na e,ecti"a mod larizacin de inc m#encias. Dentro de este rea e6isten "arios en,o' es la ma/ora de los c ales son presentados en J!ilman%>K. -ntre estos en,o' es se enc entran 3daptati"e programming) (omposition !ilters) M ltidimensional 4eperation o, (oncerns) 4 #*ectI9riented Programming / 3spectI9riented Programming) entre otros. (ada no de estos en,o' es o,rece distintos mecanismos para la separacin / composicin de inc m#encias. (oncept almente e6isten dos paradigmas para la separacin de las inc m#encias) no sim.trico / otro asim.trico J;arrison%$K.
Nicols M. Paez
12 - 110
-l paradigma simtrico plantea) ' e para lograr na e,ecti"a separacin de inc m#encias) es necesario romper con la tirana de la descomposicin dominante. Para ello todas las inc m#encias son modeladas como componentes de primera clase) todos con la misma estr ct ra / donde ning no es ms #sico ' e otro. Podra decirse ' e el estandarte de este paradigma es el en,o' e planteado por la t.cnica denominada Multidimensional Separation of Concerns. -l paradigma asimtrico por s parte) hace na di,erenciacin entre las inc m#encias dominantes Ctam#i.n llamadas centrales o , ncionalesD las c ales modela mediante componentes #ase ' e l ego son comp estos con las inc m#encias no dominantes Ctam#i.n llamadas aspectos) no centrales o sec ndariasD. (omo se "io en el e*emplo de la seccin anterior) las inc m#encias no centrales en n paradigma asim.trico) tienen generalmente na nat raleza trans"ersal. -l e6ponente ms representati"o de este paradigma es la programacin orientada a aspectos Caspect oriented programming) 39PD. -l t.rmino programacin orientada a aspectos s rgi de n tra#a*o de 5regor Riczalez / s e' ipo en el centro de in"estigacin de Hero6) en Palo 3lto) hacia ,ines de los 0%1 JRiczales0&K. -l principal o#*eti"o de 39P es lograr na e,ecti"a mod larizacin de los ((( de manera transparente Co#li"io sD / soportando distintas ,ormas de cuantificacin. Desde el p nto de "ista de 39P) na aplicacin consiste en Ccomponentes #aseD) ms n con* nto de inc m#encias dominantes ,cilmente mod lariza#les n con* nto de inc m#encias trans"ersales de di,cil mod larizacin
CaspectosD. La mezcla de los componentes #ase / los aspectos da como res ltado la aplicacin ,inal. Dicha mezcla se realiza por medio de n proceso denominado entretejido C=ea"ingD. La asimetra entre los componentes #ase / los aspectos pone de mani,iesto en en,o' e asim.trico de 39P en lo ' e a separacin de inc m#encias respecta. -s importante destacar las dos propiedades de 39P mencionadas en el prra,o anterior: la transparencia / la c anti,icacin. La transparencia tiene ' e "er con la posi#ilidad de introd cir aspectos en el cdigo #ase de ,orma transparente) de manera tal ' e ' ien "ea el cdigo #ase no p eda predecir la e6istencia de los aspectos. -sta propiedad p ede res ltar pol.mica) pero es * stamente na de las propiedades ' e disting en a 39P de las t.cnicas predecesoras. Por s parte) la c anti,icacin #rinda la posi#ilidad de e6presar en nciados CstatementsD del tipo: En todo programa P cuando se d! la condicin C ejecutar la accin A" -l programa P no es ms ' e n programa tradicional constit ido por componentes #ase)
mientras ' e la accin 3 es parte de n aspecto ' e ser entrete*ido con el programa P en el p nto indicado por la condicin (. La c anti,icacin p ede ser esttica) si la condicin ( trata so#re la estr ct ra del programa P) o #ien dinmica) si la condicin ( tiene ' e "er con alg+n s ceso de la e*ec cin de P. 3l mismo tiempo) la c anti,icacin esttica p ede ser de ca*a negra Cc anti,icacin
so#re los elementos de la inter,ase p+#lica del programa PD o de ca*a #lanca Cc anti,icacin so#re la estr ct ra interna del programa PD.
-lementos del paradigma

Joinpoint
(omo /a lo hemos mencionado) n aspecto es na a#straccin ' e permite mod larizar na inc m#encia trans"ersal. Los p ntos en la e*ec cin de los componentes #ase donde es posi#le el entrete*ido de aspectos son denominados joinpoints. 3lg nos e*emplos de *oinpoints son: na llamada a n m.todo) la creacin de na instancia) el mane*o de na e6cepcin) la e*ec cin de n ciclo) el retorno de n m.todo) la asignacin de n "alor a na "aria#le) la modi,icacin de n atri# to) entre otros. -l modelo de *ointpoints de na herramienta 39P) de,ine los tipos de c anti,icaciones ' e dicha herramienta soporta / por consig iente la potencia de la herramienta.
1 public class Foo 2 { 3 private int cantidadDeLlamadas; 4 public Foo() 5 { 6 try { ! "ystem#out#println($Foo#ne%()$); & ' 1( catc)(*+,-ception e) 11 { 12 .untime,-ception re / ne% .untime,-ception(e); 13 t)ro% re; 14 ' 15 ' 16 public void doFoo() 1 { 1! "ystem#out#println($Foo#doFoo()$); 1& cantidadDeLlamadas 0/ 1; 2( ' 21 public static void main("trin123 ar1s) 22 { 23 Foo 4oo / ne% Foo(); 24 4oo#doFoo(); 25 ' 26 '
Figura #: cdigo de ejem$lo con varios join$oints
-n el ,ragmento de cdigo de la ,ig ra F e6isten los sig ientes *oinpoints. Nmero de l nea @ <% <$
Nicols M. Paez
!oinpoint -*ec cin del m.todo !oo.ne=CD Mane*o de na e6cepcin del tipo 89-6ception Llamada al m.todo R ntime-6ception.ne=C-6ceptionD
14 - 110
Nmero de l nea <F <& <0 $F $>
!oinpoint Lanzado de na e6cepcin del tipo R ntime-6ception -*ec cin del m.todo !oo.do!ooCD Modi,icacin del atri# to !oo.cantidadDeLlamadas Llamada al m.todo !oo.ne=CD Llamada al m.todo !oo.do!ooCD
Poincut
3 n con* nto de,inido de *oinpoints se lo llama pointcut. 3 di,erencia de los *ointpoints) los pointc ts) son de,inidos por el programador. 3lg nos pointc ts simples podran ser todas las e*ec ciones del constr ctor de na determinada clase) todas las llamadas al m.todo Po% de la clase &at' ' e reci#a como parmetro n @ o el lanzado de na e6cepcin de la clase (untimeE)ce$tion. Todas las herramientas 39P #rindan n con* nto de designadores de pointc ts ' e en con* nto con el so de e6presiones reg lares permiten la de,inicin de los pointc ts. La sig iente ta#la m estra alg nos designadores de pointc ts de aspect*. "esignador de pointcuts (allCHD ;andlerCHD (,lo=CHD TargetCHD argsCHD 3nnotationCHD #ipo de !oinpoints Llamadas a m.todos N constr ctores de la clase H Mane*adores de e6cepciones de la clase H C#lo' es catchD ?oinpoints en el conte6to del *ointpoint H ?oinpoints c /o o#*eti"o in"ol cre a instancias de clase H ?oinpoint ' e reci#an arg mentos de la clase H ?oinpoint ' e contengan la anotacion H
N9T3: -n la ma/ora de las herramientas H s ele ser na e6presin reg lar

*abla 1: Designadores de $ointcuts de +s$ect,
Advice
-l cdigo del aspecto ' e se e*ec ta asociado a n determinado pointc t es denominado advice. (oncept almente los ad"ices contienen el comportamiento del aspecto. Los ad"ices p ede ser #sicamente de F tipos.
Ge,ore: se e*ec tan pre"ios a la e*ec cin del *oinpoint asociado.

15 - 110
Nicols M. Paez
3,ter: se e*ec tan desp .s de la e*ec cin del *oinpoint asociado. 3ro nd: se e*ec tan antes / desp .s del *oinpoint asociado) p diendo incl so reemplazar la e*ec cin del *oinpoint.
Declaraciones de intertipo
9tro elemento de 39P) m chas "eces pasado por alto) es la declaracin de intertipos Ctam#i.n llamada introd ccin o mi6inD ' e permite e6tender la estr ct ra de n componente #ase mediante el agregado de miem#ros Cm.todos / atri# tosD e inter,ases. La declaracin de n intertipo ,orma parte de n aspecto / es dicho aspecto el ' e de,ine c ales sern los componentes #ase ' e se e6tendern con el intertipo. ;a/ ' e destacar ' e las e6tensiones realizadas por n intertipo no son "isi#les$ para los componentes #ase) ni tampoco para el propio componente ' e ha sido e6tendido. Pongamos n e*emplo para entender esta sit acin: s pongamos ' e para poder persistir o#*etos en na #ase de datos es necesario ' e todo o#*eto implemente la inter,ase -bjetoPersistente) la c al de,ine n m.todo para o#tener el identi,icador del o#*eto a tilizarse como cla"e primaria en la #ase de datos. Utilizando 39P podra de,inirse n aspecto ' e con na declaracin de intertipo se encarg e de las sig iente c estiones.

;acer ' e todas las clases ' e de#an persistirse implementen la inter,az -bjetoPersistente" 3gregar la implementacin del m.todo re' erido por la inter,az -bjetoPersistente en todas las clases ' e de#an persistirse.
3hora) dado n o#*eto ' e al ' e se le ha agregado el mencionado aspecto para implementar la inter,az -bjetoPersistente) si alg+n o#*eto ' isiera tratarlo como directamente "isi#le para los componentes #ase.
Aspecto
n -bjetoPersistente) de#era
pre"iamente castearlo a dicho tipo) /a ' e lo agregado por las declaraciones de intertipos no es
;a#iendo introd cido todos los elementos caractersticos de 39P estamos en condiciones de de,inir el concepto de alto ni"el ' e con* ga todos los elementos) el aspecto. Un aspecto es una entidad que modulariza una incumbencia transversal mediante la definicin de un con unto de pointcuts! advices " declaraciones de intertipo# (omo "eremos ms adelante dependiendo de la herramienta tilizada) p ede ' e la de,inicin de n aspecto se haga enteramente en n archi"o , ente) tal como oc rre con na clase en *a"a) o #ien ' e los ad"ices e introd cciones de de,inan en
$ No son "isi#les sin hacer n casteo e6plcito.
n archi"o , ente / los poinc ts en
n archi"o de
con,ig racin de la aplicacin ,inal.

Solucin A P al e!emplo planteado
;a#iendo introd cido los elementos caractersticos del paradigma) estamos en condiciones de plantear na sol cin 39P a la pro#lemtica de #anca electrnica. (omo m estra la ,ig ra >) se rem e"en los m.todos auditarCambios / verficarPermisos de las clases de dominio re #icando la lgica de estos m.todos en los aspectos +uditor / +utorizador" La ,ig ra @ m estra la de,inicin del aspecto 3 ditor con n pointc t ' e identi,ica todas las llamadas a settersF de las clases Cliente) CuentaBancaria / descendientes s s descendientes. 3sociado a dicho pointc t de,ine na ad"ice de tipo a,ter) dentro del c al de#era codi,icarse la registracin de los cam#ios. La ,ig ra A m estra la de,inicin del aspecto +utorizador con dos pointc ts: no ' e identi,ica todas las llamadas a m.todos de las clases PlazoFijo / otro ' e identi,ica las llamadas a m.todos de las Cliente) CuentaBancaria / descendientes de estas) ' e no est.n incl idas en el poinc t anterior. 3sociado a cada pointc t ha/ "eri,icacin de permisos. Para ' e los aspectos pre"iamente descriptos p edan c mplir con s cometido es necesario ' e los mismos tengan acceso a la in,ormacin de conte6to) la c al s ele estar disponi#le mediante arte,actos pro"istos por el leng a*e 39P. n ad"ice de tipo #e,ore) dentro del c al de#era codi,icarse la
Figura .: Diagrama de la solucin +-P del dominio de banca electrnica
F 4e s ele llamar setters a los m.todos ' e permiten la modi,icacin de atri# tos de na clase.
public aspect 5uditor { pointcut puntos55uditar()8 call(9 <liente0#set9) == call( 9 <uenta>ancaria0#set9); after()8 puntos55uditar(){ A9 9 5BuC iria la re1istraciDn de los cambiosE los cuales se 9 podrCan acceder usando la in4ormaciDn de conte-to 9A ' '
Figura 0: Fragmento de cdigo del as$ecto +uditor
public aspect 5utori6ador { pointcut puntos57eri4icar1()8 call( 9 :la6oFi;o#9(##)); pointcut puntos57eri4icar2()8 call(9 <liente0#9(##)) == call( 9 <uenta>ancaria0#9(##)) ?? @puntos57eri4icar1(); before()8 puntos57eri4icar1(){ A9 9 5BuC iria la veri4icaciDn de permisos para todas las clases 9 e-cepto :la6oFi;o 9A ' before()8 puntos57eri4icar2(){ A9 9 5BuC iria la veri4icaciDn de permisos 9 para la :la6oFi;o 9A '
' Figura /: Fragmento de cdigo del as$ecto +utorizador
;erramientas 39P
Tipos de "erramientas
Gsicamente / m / a grandes rasgos podemos decir ' e e6isten dos tipos de herramientas 39P) di,erenciadas principalmente por el modelo de entrete*ido) el c al p ede ser esttico o dinmico. Las herramientas 39P de entretejido est$tico son los compiladores) pre compiladores / post compiladores. -stas herramientas toman como entrada los aspectos / los componentes #ase en ,orma de cdigo , ente o #inario / generan como salida cdigo #inario con los aspectos / los componentes #ase /a entrete*idos. -n general los componentes #ase se escri#en en alg+n leng a*e orientado a
Nicols M. Paez
1! - 110
o#*etos) mientras ' e los aspectos se escri#en en n e"os leng a*es con soporte de aspectos ' e generalmente son na e6tensin al leng a*e orientado a o#*etos de los componentes #ase. -ste es el caso de 3spect?>Jaspect*K) 3spect.N-T JaspectnetK / 3spect(SS JaspectcSSK) entre otros. Las herramientas 39P de entretejido din$mico son generalmente ,rame=orBs desarrollados en n leng a*e orientados a o#*etos / estn #asados en pro6ies dinmicos. La de,inicin del aspecto consta de dos partes. Por n lado se de,ine el ad"ice) e6tendiendo na clase #ase pro"ista por el ,rame=orB de aspectos. Por otro lado se realiza la de,inicin de los pointc ts) la c al s ele hacerse por medio de metadata) ' e m chas "eces reside en archi"os HML. Por lo general si n aspecto consta de ms de n ad"ice) es necesario crear na clase por cada ad"ice. -stos ,rame=orBs pro"een na clase ' e , nciona como na ,#rica de o#*etos / ' e es el p nto de acceso a la , ncionalidad del ,rame=orB. La ,ig ra & m estra las clases tpicas de n ,rame=orB 39P) ha/ ' e destacar ' e la clase Pro)1 s ele ser creada en tiempo de e*ec cin. -sta ,#rica de o#*etos interpreta los pointc ts de,inidos en la metadata / en #ase a eso a la hora de crear n o#*eto detecta si de#en agregarse aspectos al o#*eto creado) en c /o caso crea n pro6/ con el con* nto de ad"ices ' e aplicarn al o#*eto en c estin / de" el"e na re,erencia al pro6/ en l gar de na re,erencia directa el o#*eto pedido. -l diagrama de sec encia de la ,ig ra : il stra este proceso.
Figura 2: Clases t3$icas de un frame%or4s +-P"
> 3 partir de la "ersin <.$ 3spect? tam#i.n soporta otras ,ormas de =ea"ing.
Nicols M. Paez 1" - 110
Figura 5: Creacin de un objeto as$ectizado $or un frame%or4 +-P
De esta ,orma todas las llamadas al o#*eto con aspectos son interceptadas por el pro6/ ' e da inter"encin a los ad"ices) los c ales act+an antes /No desp .s de la e*ec cin del o#*eto en c estin. -*emplos de herramientas de este tipo son: 4pring!rame=orB JspringK) ?#oss39P J*#ossaopK) Loom.N-T JloomK / Naspect JnaspectK.
Figura 6: 7ecuencia de ejecucin de un advice de ti$o before
;a/ n serie de c estiones ' e caracterizan a cada tipo de herramienta.
Mientras ' e las herramientas de entrete*ido esttico #rindan la posi#ilidad de detectar

20 - 110
Nicols M. Paez
errores en la de,inicin de los pointc ts d rante el desarrollo Ctiempo de compilacinD) el so de herramientas de entrete*ido dinmico o#liga a esperar hasta el momento de e*ec cin para detectar dichos errores.
Dado ' e la gran ma/ora de herramientas de entrete*ido dinmico son ,rame=orBs) s c r"a de aprendiza*e es m cho ms amena ' e la de las herramientas de entrete*ido esttico) /a ' e estas s elen re' erir del aprendiza*e de n n e"o leng a*e.
3nalizando las herramientas e6istentes) pareciera ' e las de entrete*ido esttico son ms completas desde el p nto de "ista concept al ' e las de entrete*ido dinmico.
Desde el p nto de "ista de implementacin) res lta m cho ms simple implementar na herramienta de entrete*ido dinmico ' e na de entrete*ido esttico.
4i #ien hasta el momento hemos hecho re,erencia a slo dos tipos de entrete*ido Iesttico / dinmicoI en tecnologas #asadas en m' inas "irt ales) e6isten distintas "ariantes de estos tipos de entrete*ido. -n el caso de ?a"a) el entrete*ido dinmico p ede implementarse en tiempo de e*ec cin o tam#i.n en tiempo de carga) para lo c al se reemplaza el cargador de clases de la m' ina "irt al) por n cargador de clases ' e realiza el tra#a*o adicional del entrete*ido. -n estos casos el cargador de clases reemplaza lo ' e hemos denominado ,#rica de o#*etos. -ntre las herramientas 39P e6istentes en la act alidad se destacan 3spect*) ?#ossI39P / 4pring!rame=orB) a n' e ms all de estas tres e6iste na cantidad importante de herramientas casi todas ellas e6tensiones a leng a*es 99 JaspectcSSK) JLoom.N-TK) JaspectDN5K) JNaspectK) JaspectMK. 4in d da) gran parte del camino de la e"ol cin de 39P lo ha marcado 3spect?) siendo la primer herramienta esta#le / la de ma/or di, sin en la act alidad. 3l mismo tiempo ha/ ' e destacar el aporte de 4pring!rame=orB) promo"iendo el so de 39P en am#ientes enterprise. -s por esto ' e a contin acin haremos na #re"e rese2a de estas dos herramientas.
AspectJ# el $%nesis
3spect? Jaspect*K s rgi como consec encia del tra#a*o de 5regor Riczales / s e' ipo en HP3R(. 3 partir de la creciente acti"idad de la com nidad ,ormada en torno a 3spect?) en $%%< aspect? pas a la r#ita del pro/ecto -clipse JeclipseK. Tal "ez por ser la primer herramienta 39P) ha marcado en gran parte el r m#o de la com nidad 394D. 3spect? es na e6tensin a ?a"a. Desde el p nto de "ista de la implementacin) en n comienzo , e n pre compilador) pero act almente es n compilador ' e genera ?a"a G/te (ode totalmente compati#le con la ?EM de 4 n Micros/stems. -n el a2o $%%@) 3spect? se , sion con aspect=erBz) incorporando "arias , ncionalidades de este +ltimo relacionadas al entrete*ido dinmico. La ma/ora de los li#ros so#re 39P en la act alidad tratan so#re 3spect?.
Nicols M. Paez
21 - 110
Sprin$ &ramewor'# el promotor
4pring!rame=orB es n desarrollo de cdigo a#ierto creado por Rod ?ohnson para ,acilitar el desarrollo de aplicaciones enterprise inicialmente en ?a"a / act almente tam#i.n en .N-T. -ste ,rame=orB consta de "arios md los) no de los c ales es 4pring39P. 4pring39P tiliza entrete*ido dinmico / p ede tilizarse independientemente de los otros md los. Un p nto interesante de 4pring!rame=orB) es ' e "arios de s s md los hacen so del mod lo 39P. -n el caso de la implementacin ?a"a) ha tenido n gran ni"el de adopcin con"irti.ndose en el estndar de ,acto para alg nas compa2as. La "ersin $.% a dado integracin con 3spect?. -n c anto a la implementacin .N-T) el md lo 39P de 4pring) es la implementacin 39P ms completa) esta#le / tilizada de 39P en la act alidad. n paso interesante hacia la
-stado del arte

(on s s escasos <% a2os 39P es a+n paradigma en desarrollo) n hecho ' e da c enta de la * "ent d de 39P es ' e al momento de redaccin de este tra#a*o no e6isten ms de $% li#ros so#re el tema@.
(sos de A P
4i #ien en la act alidad casi no ha/ d das respecto de los conceptos de 39P) toda"a se sig e de#atiendo si 39P es n paradigma) na t.cnica de programacin o na estrategia de dise2o. 9tra c estin ' e a+n no est clara) tiene ' e "er con los sos de 39P) si #ien desde s s comienzos 39P , e conce#ida para mod larizar ((() no ha/ n ac erdo so#re si es "lido s c al' ier (((. ;a/ a tores ' e slo consideran "lido s otros proponen s ms all de la mod larizacin de (((.
)os rumbos de la comunidad
so para
so para ((( no , ncionales) al tiempo ' e
so para todo (((. Tampoco ,altan los ' e proponen el so de 39P para c estiones
Podra decirse ' e en la act alidad se disting en tres lneas de tra#a*o en la com nidad 39P. La primera de ellas / la ms antig a) est relacionada con las herramientas de programacin. Dentro de esta lnea estn los gr pos de desarrollo de las herramientas pre"iamente mencionadas) ' e tra#a*an en la me*ora de las mismas. Por otro lado) e6isten gr pos tra#a*ando en n e"as herramientas de distinta ndole) intentando s perar alg nas limitaciones de las herramientas act ales. La seg nda) relacionada a la ingeniera de so,t=are / denominada Pearl/ aspectsQ) tra#a*a so#re la identi,icacin / especi,icacin de aspectos en etapas tempranas del ciclo de desarrollo de so,t=are
@ ! ente: amazon.com
como capt ra de re' erimientos) modelado de negocio / ar' itect ra. -l desarrollo de esta lnea de in"estigacin es , ndamental para ,acilitar la adopcin de 39P en am#ientes ind striales. Dentro de esta lnea de in"estigacin) ha/ tra#a*os so#re herramientas de modelado) "arias de las c ales han prop esto distintas e6tensiones a UML) pero lamenta#lemente ning na ha predominado so#re las dems. !inalmente la tercera) tra#a*a so#re posi#les aplicaciones de 39P dentro de distintas reas del desarrollo de so,t=are. -s * stamente dentro de esta lnea de tra#a*o donde se enc adra esta tesis.
Nicols M. Paez
23 - 110
(apit lo 888: 3plicaciones enterprise

8ntrod ccin
3nte todo na aplicacin enterprise) es na aplicacin ' e da soporte a alg+n proceso de negocio. -ntre las caractersticas de ests aplicaciones se destacan J!o=ler%FK:
Mane*o de grandes volmenes de informacin relacionada al negocio ' e de#e ser persistida. -sta in,ormacin podra incl ir datos de stocB de prod ctos) clientes) pro"eedores) transacciones comerciales) etc.
Dicha informacin suele ser accedida en forma concurrente por "arios s arios. La necesidad de los s arios de acceder a la in,ormacin o#liga a ' e estas aplicaciones c enten con varias interfaces de usuario distintas ' e permitan presentar la mencionada in,ormacin de la manera ms con"eniente para cada s ario. Tomando como e*emplo la in,ormacin de las "entas del mes de na compa2a) seg ramente la misma ser "is alizada en ,orma distinta por n empleado del sector de "entas ' e por n gerente.
-s m / com+n ' e estas aplicaciones de#an integrarse con otras aplicaciones de la organizacin) desarrolladas en m chos casos con di,erentes tecnologas. Por e*emplo en el caso de los #ancos es m / com+n la presencia de aplicaciones (9G9L ' e interact+an con aplicaciones en tecnologas ms act ales como *a"a / .N-T.
-l mane*o sim ltneo de las pro#lemticas antes mencionadas) s mado a la comple*idad propia de las reglas de negocio) re"iste a estas aplicaciones de na complejidad ' e se e6pande desde los re' erimientos hasta la operacin) pasando por el dise2o) la implementacin / la pr e#a. 3l mismo tiempo esta comple*idad s ele crecer en ,orma e6ponencial con el tama2o de la aplicacin.
Las caractersticas pre"iamente mencionadas so#re las aplicaciones enterprise) son com nes a na gran cantidad de aplicaciones. Dependiendo de la pro#lemtica partic lar de cada aplicacin) cada na de las caractersticas mencionadas toma distinta rele"ancia. 3 grandes rasgos podramos decir ' e e6isten F grandes gr pos de aplicaciones enterprise. -l primer gr po est constit ido por las aplicaciones de gestin general. Dentro de este gr po se enc entran los -RPs Cdel ingl.s) -nterprise Reso rce ManagersD / los (RMs Cdel ingl.s) ( stomer Relationship ManagersD. -stas aplicaciones generalmente constit /en el n+cleo de sistemas de na organizacin #rindando soporte a la gran ma/ora de s s procesos) o#ligando a todos los dems
sistemas a interact ar con ellos) directa o indirectamente. -*emplos concretos son: 43P) Peopleso,t) 4ie#el / !inancials a ni"el m ndial / 5.minis) Tango / (alipso a ni"el nacional. -l seg ndo gr po) est ,ormado por aplicaciones de gestin partic lar ' e complementan a las aplicaciones del primer gr po / se encargan de alg na pro#lemtica p nt al de la organizacin. 5eneralmente) ests aplicaciones son tilizadas slo por n gr po de s arios de la organizacin) por e*emplo todos los pertenecientes al sector de logstica. -n este gr po #ien podran #icarse aplicaciones de rec rsos h manos / 4!3 Cdel ingl.s) 4ales !orce 3 tomationD. !inalmente) en el tercer gr po se enc entran las aplicaciones de G$( Cdel ingl.s) G siness to ( stomerD. -stas aplicaciones a di,erencia de las anteriores) son aplicaciones de internet) a#iertas al p+#lico) por lo ' e la cantidad de s arios p ede ser "arios rdenes de magnit d ma/or ' e en los otros dos gr pos mencionados. -n el caso de las denominadas empresas .(9M) estas aplicaciones son la #ase del negocio) mientras ' e en las empresas ms tradicionales Cno .(9MD estas aplicaciones representan n complemento al negocio) o,reciendo n canal alternati"o de contacto con los clientes. (omo e*emplo de aplicaciones .(9M podemos mencionar 3mazon / Mercado Li#re. -l sig iente c adro res me alg nas caractersticas distinti"as de estos tipos de aplicaciones. Caracter stica Cantidad de usuarios (olumen de informacin Necesidad de escalar )nterface de usuario %estin general Proporcional a la organizacin 3lto Media Prod cti"a %estin puntual Proporcional a n sector Ga*o Ga*a Prod cti"a &'C M ndial 3lto 3lta 3tracti"a
*abla 2: Caracter3sticas distintivas de los distintos ti$os de +E
-l hecho de ' e estas aplicaciones est.n estrechamente ligadas a procesos del negocio) impone so#re las mismas la o#ligacin de c mplir con ciertos atri# tos de calidad / re' isitos t.cnicos Cal con* nto de estos dos gr pos se los s ele llamar re' isitos no , ncionalesD.
3tri# tos de calidad

-n m chos casos los atri# tos de calidad pasan inad"ertidos para los s arios de la aplicacin) pero s a sencia s ele impactar negati"amente tanto en el negocio como en percepcin ' e tienen los s arios de la aplicacin. Un claro e*emplo de esto es el tiempo de resp esta: mientras ' e la aplicacin responda dentro de los parmetros de tiempo esperados por los s arios) ser raro esc char a s ario alg no haciendo re,erencia al tiempo de resp esta de la aplicacin) pero si) por el contrario) la aplicacin tarda demasiado en responder a las interacciones de los s arios) sern com nes las ' e*as
respecto de este hecho. 3 contin acin "eremos los atri# tos de calidad caractersticos de las aplicaciones enterprise.
Disponibilidad
4eg+n JGass%FK) la disponibilidad est relacionada con los desper,ectos C,ail reD del sistema / s s consec encias. Un desper,ecto se prod ce c ando el sistema de*a de pro"eer ser"icio de ac erdo con las especi,icaciones. 3dems) dicho desper,ecto de#e ser o#ser"a#le por los s arios del sistema) /a sean h manos otras aplicaciones. -ntre las inc m#encias de este atri# to se enc entran el cmo se detectan los desper,ectos) c n ,rec entemente oc rren) ' . s cede con el sistema c ando se prod ce n desper,ecto) c nto tiempo p ede estar el sistema , era de operacin / cmo p eden pre"enirse) entre otros. Res lta importante hacer la distincin entre desper,ectos / ,allas C,a ltsD. Un ,alla se con"ierte en n desper,ecto c ando es o#ser"a#le para n s ario. Tpicamente la disponi#ilidad es de,inida como d * tiempo medio entre fallas + ,tiempo medio entre fallas - tiempo medio de reparacin. -l tiempo calendarizado ' e el sistema est , era de ser"icio no es considerado al calc lar la disponi#ilidad.
Desempe*o +performance,
-l desempe2o es
no de los atri# tos ms comple*os) de#ido a s relacin con los dems
atri# tos / a la gran cantidad de ,actores ' e a#arca. 4eg+n JGass%FK el desempe2o tiene ' e "er con el tiempo de respuesta) o sea) el tiempo ' e le ins me al sistema responder a los e"entos e6ternos Cestm los del s ario) llamadas a , nciones) procesamiento de pedidos de otras aplicaciones) etc.D. 3l mismo tiempo) para Martin !o=ler J!o=ler%FK la c estin no es tan simple / sostiene ' e el desempe2o p ede "erse como el tiempo de resp esta del sistema o tam#i.n como la cantidad de tra#a*o ' e el sistema p ede realizar en n cierto lapso de tiempo Ct/roug/putD. Dos medidas relacionadas al desempe2o son: eficiencia * desempe0o + cantidad de recursos capacidad * m$1imo t/roug/put
Escalabilidad
La escala#ilidad es na medida de como el agregado de rec rsos a,ecta al desempe2o del sistema. Un sistema es escala#le) si el agregado de rec rsos prod ce na me*ora en el desempe2o del sistema. -n #ase a esto la escala#ilidad podra medirse como: escalabilidad * diferencia de desempe0o+ cantidad de recursos agregados
;a/ dos tipos de escala#ilidad: "ertical / horizontal. La primera) consiste en a mentar la potencia de los rec rsos e6istentes) mientras ' e la seg nda) en agregar ms rec rsos.
-onfiabilidad +.eliabilit/,
-n JG schmann0@K se de,ine la con,ia#ilidad como la ha#ilidad del sistema para mantener s , ncionalidad a pesar de ,allas) so incorrecto / sit aciones inesperadas. -s posi#le disting ir dos aspectos de la con,ia#ilidad: Por n lado) la tolerancia a fallas # sca aseg rar el correcto comportamiento ante ,allas / la capacidad interna del sistema de a to corregirlas. Por otro lado) la robustez) est relacionada con la proteccin de la aplicacin ante el so
incorrecto) las entradas de datos degenerados / la oc rrencia de errores inesperados) permitiendo ' e la aplicacin permanezca en n estado de,inido. 3 di,erencia de la tolerancia a ,allas) la ro# stez no espera ' e el sistema tenga la capacidad de reponerse ante la oc rrencia de errores) sino ' e slo pretende garantizar ' e la aplicacin permanezca en n estado de,inido.
Mantenibilidad +modifiabilit/,
La manteni#ilidad tiene ' e "er con el costo de cam#io / tiene dos inc m#encias:
T' . p ede cam#iarU Los cam#ios p eden ser de distinta ndole) , ncionalidad #rindada por la aplicacin) plata,orma so#re la ' e aplicacin e6iste Chard=are) sistema operati"o) etcD) am#iente en el c al la aplicacin se e*ec ta Caplicaciones con las ' e interact a) protocolos de com nicacin) etcD / atri# tos de calidad) entre otros. 3 s "ez los cam#ios p eden ser agregados) s presiones o modi,icaciones de alg+n aspecto.
Tc ndo p ede ser hecho el cam#io / ' i.n de#e hacerloU Tiempo atrs todo cam#io en na aplicacin) re' era de por n programador ' e tra#a*ase so#re cdigo , ente con la consig iente) compilacin / desplieg e. -n la act alidad los cam#ios p eden ser realizados s arios) administradores o programadores. 3l mismo tiempo los cam#ios p eden hacerse d rante la e*ec cin) la con,ig racin) el desplieg e o la programacin.
Todo cam#io tiene asociado n costo de tiempo / dinero) los c ales p eden ser c anti,icados. La manteni#ilidad estar determinada en gran medida por la ,orma en ' e sea descomp esta la aplicacin / por las t.cnicas de programacin tilizadas.
.eusabilidad
-l re so es na de los temas ms rec rrentes en el desarrollo de so,t=are dado ' e tericamente permite red cir el costo / el time to marBet. De ac erdo a JG schmann0@K la re sa#ilidad p ede analizarse desde dos "istas complementarias.
Nicols M. Paez
2 - 110
Por na lado la re sa#ilidad como la capacidad de reutilizar arte,actos de so,t=are /a e6istentes como #i#liotecas) ,rame=orBs / componentes. Por el otro) la re sa#ilidad como la posi#ilidad de crear arte,actos para ' e p edan ser reutilizados por otros) en sit aciones similares.
0erificabilidad +testabilit/,
( anto ms grande / comple*o es n sistema) ms importante / di,ic ltosa es s pr e#a / ma/ores son las consec encias de no hacerla correctamente. La "eri,ica#ilidad re,iere a la ,acilidad con la ' e p ede demostrarse el correcto , ncionamiento del so,t=are) mediante s pr e#a. 4i #ien de ac erdo a JGass%FK) la pr e#a representa n >%V del costo total del sistema) en el caso de las 3-) el no hacerla p ede implicar n costo m cho ma/or) de#ido a los per* icios ' e el , ncionamiento incorrecto pro"o' e al negocio.
(sabilidad
4eg+n Len Gass JGass%FK) la sa#ilidad #rinda na medida de c n ,cil es para los s arios del sistema completar na tarea. 3l mismo tiempo J;ohmann%FK sostiene ' e tradicionalmente la sa#ilidad ha sido asociada a la inter,az de s ario) lo c al tiene per,ecto sentido /a ' e la impresin ' e tienen los s arios so#re c n sa#le es el sistema es tra".s de la inter,az de s ario. Para la sa#ilidad es importante ' e la inter,az de s ario sea clara / ,cil de sar. 3dicionalmente ha/ c estiones de sa#ilidad ' e estn ms all de la inter,az de s ario como por e*emplo #rindar al s ario la posi#ilidad de cancelar operaciones) deshacer operaciones o re tilizar datos pre"iamente ingresados. Una de las razones ms importantes para c idar la sa#ilidad es el dinero. -st por dems pro#ado ' e la in"ersin en sa#ilidad se rec pera m / rpido / con creces en la "ida de c al' ier aplicacin. 3lg nos de los #ene,icios de la sa#ilidad son los ' e se en meran a contin acin.

Red ccin de los costos de entrenamiento. Red ccin de los costos de soporte. Red ccin en el costo de los errores. 8ncremento en la prod cti"idad de los s arios. 8ncremento en la satis,accin del cliente.
Se$uridad
La seg ridad es na medida de la ha#ilidad del sistema para e"itar sos no a torizadosW al mismo tiempo de permitir el so a ' ienes legtimamente tienen permiso para sarlo. Todo intento de ' e#rar la seg ridad es considerado n ata' e o amenaza. -stas amenazas
Nicols M. Paez 2! - 110
p eden tomar distintas ,ormas) encontrndose entre las ms com nes) el acceso no a torizado a datosN, ncionalidades / el intento de impedir el acceso a s arios legtimos. La seg ridad p ede ser caracterizada por na serie de propiedades.
3 tenticacin: es el mecanismo ' e permite identi,icar a los s arios de la aplicacin. 5eneralmente es implementada en la inter,az de s ario para poder accionar los mecanismos de a torizacin) a ditoria / personalizacin. Para lle"ar a ca#o la a tenticacin es necesario ' e el s ario pro"ea alg+n tipo de credencial) tpicamente s nom#re de s ario / na contrase2a.
3 torizacin: es la inc m#encia ' e identi,ica las acciones ' e tiene permitidas realizar cada s ario.
3 ditora: es la propiedad de la aplicacin de registrar toda acti"idad realizada) de manera de poder sa#er ' i.n / c ndo realiz cada accin.
1nteroperabilidad
-n m chos casos las aplicaciones no estn aisladas) sino ' e ,orman parte de n todo en el c al de#en interact ar con otros sistemas. -n este conte6to la interopera#ilidad es la capacidad de na aplicacin de poder interactuar con aplicaciones independientemente de su tecnolog a. Para lograr este cometido s elen tilizarse sol ciones #asadas patrones de dise2o / estndares a#iertos.
-onsideraciones sobre los atributos de calidad
Ms all de la de,inicin e identi,icacin de los atri# tos de calidad de n sistema) e6isten na serie de c estiones no menores a considerar ' e se mencionan a contin acin. 3l intentar implementar estos atri# tos de calidad es posi#le ' e nos encontremos ' e mientras ' e alg nos atri# tos se complementan entre s) otros res ltan ser incompati#les. Un caso de atri# tos complementarios podra ser disponi#ilidad / escala#ilidad) mientras ' e como atri# tos incompati#les podran mencionarse desempe2o / con,ia#ilidad. 9tra c estin a considerar) es la ,orma de medir los atri# tos de calidad. 3lg nos como el desempe2o) p eden medirse sin grandes complicaciones mientras la aplicacin est e*ec tndose) midiendo el tiempo de resp esta. Pero para otros atri# tos) ms a#stractos) como la sa#ilidad) la ,orma de medicin no es tan int iti"a.
Re' isitos t.cnicos

3dicionalmente a los atri# tos de calidad) las 3- c entan con ciertos atri# tos t.cnicos) alg nos de las c ales son consec encia de la implementacin de los atri# tos de calidad mientras ' e otros s rgen directamente a partir de necesidades del negocio.
Nicols M. Paez
2" - 110
Persistencia
La persistencia de la in,ormacin es na de las pro#lemticas centrales de estas aplicaciones / por ello es ' e las ar' itect ras act ales plantean na capa de la aplicacin encargada e6cl si"amente de la persistencia 4in d da alg na) el estndar de ,acto en la act alidad para la persistencia de in,ormacin en 3-) son las #ases de datos relaciones) mientras ' e para la codi,icacin de la lgica de negocio se tilizan tecnologas de o#*etos. -sto nos pone en la sit acin de almacenar o#*etos en ta#las) pro#lemtica ' e por s rec rrencia /a ha sido caracterizada con n nom#re propio: diferencia de impedancia Cimpedance mismatchD J3m#ler%>K. -n este conte6to ha#lar de persistencia implica:

De,inir el mapeo de datos entre o#*etos / ta#las. Dde,inir las clases ' e se encargarn de lle"ar a ca#o el mapeo pre"iamente de,inido) lo ' e implicar la manip lacin de sentencias 4LL.
(olocar las llamadas necesarias a las clases pre"iamente de,inidas para persistir los o#*etos en la #ase de datos / rec perarlos de la misma na "ez persistidos.
3 estos p ntos mencionados) se les de#e s mar la comple*idad ' e implica el mane*o del ciclo de "ida de los o#*etos) tanto el memoria como en la #ase de datos. -6isten m+ltiples tra#a*os ' e han tratado esta pro#lemtica JGro=nK) J3m#ler%$K) J3m#ler%%K / J!o=ler%FK.
Transaccionalidad
Una transaccin es na sec encia de tra#a*o) ' e a#arca na serie de operaciones / ' e c enta con n comienzo / n ,in claramente delimitados J!o=ler%FK. Tanto al comienzo de la transaccin) como al ,inal de la misma) el sistema est en estado "lido) o sea) si d rante la e*ec cin de la transaccin) algo ,alla o la transaccin es cancelada) el sistema de#er retornar al estado pre"io al comienzo de la transaccin. -n las aplicaciones enterprise e6isten dos tipos de transacciones: de negocio / del sistema. Las transacciones de negocio son a' ellas ' e tienen sentido para el negocio / por consig iente para los s arios de la aplicacin. Por s parte las transacciones del sistema s elen ser ms gran lares ' e las transacciones de negocio / generalmente no tienen sentido directo para el s ario. Una pro#lemtica corriente en las 3-) es lidiar con la di,erencia de gran laridad entre am#os tipos de transacciones) /a ' e por lo general na transaccin de negocio a#arca "arias transacciones del sistema. Las transacciones son el principal mecanismo conc rrencia. Las transacciones Iindependientemente de s tipoI se caracterizan por c atro propiedades.
tilizado en las 3- para el mane*o de la
Atomicidad) cada operacin de#e completarse e6itosamente para ' e la transaccin p eda
30 - 110
Nicols M. Paez
completarse) de lo contrario todo el tra#a*o de#e deshacerse) esto nos lle"a a na sit acin de todo o nada.
Consistencia) todo rec rso in"ol crado de#e estar en comienzo como al ,inal de la transaccin.
n estado consistente tanto al
Aislamiento CisolationD) el res ltado de na transaccin no de#e ser "isi#le a ning na otra transaccin hasta ' e la misma no sea completada.
"urabilidad Cd ra#ilit/D) el res ltado de permanente.
na transaccin de#e ser hecho en ,orma
Las transacciones ' e c mplen con estas c atro propiedades se conocen como transacciones 3(8D C3tomicit/) (onsistenc/) 8solation) D ra#ilit/D. Poniendo las transacciones en el conte6to de las 3-) n s ario realiza acciones en la aplicacin) donde cada accin del s ario in"ol cra n con* nto de operaciones por parte de la aplicacin) las c ales generalmente ,orman parte de na misma transaccin.
Distribucin
3 lo largo del tiempo las 3- han pasado por distintos modelos de procesamiento) desde las ar' itect ras main,rames de procesamiento centralizado con terminales #o#as para entrada / salida de datos) pasando por ar' itect ras clienteIser"idor / llegando en la act alidad hasta las ar' itect ras distri# das) donde la misma aplicacin se e*ec ta en "arios nodos ,sicos. -n alg nas ocasiones la distri# cin es consec encia de ' e el negocio se enc entra ,sicamente distri# do) mientras ' e en otras ocasiones la distri# cin es necesaria para poder #rindar ciertos atri# tos de calidad como ser alta disponi#ilidad. -s interesante hacer notar ' e el hecho de ' e m chas 3- sean distri# das ha generado la creencia de ' e la distri# cin es na condicin necesaria para ' e na aplicacin sea considerada enterprise. -sto es incorrecto) /a ' e la distri# cin es na consec encia de los re' isitos imp estos por el negocio so#re las aplicaciones enterprise / de ning na manera na condicin necesaria ni m cho menos s ,iciente para determinar el carcter enterprise de na aplicacin.
-oncurrencia
(omo /a hemos mencionado) las 3- s elen tener "arios s arios conc rrentes) lo c al pro"oca ' e la aplicacin no solo de#a soportar con n # en desempe2o "arias sesiones de s arios) sino ' e ademas de#a controlar el acceso conc rrente a datos del sistema) aseg rando s consistencia todo el tiempo. P ede darse ' e dos o ms s arios intenten modi,icar n mismo registro al mismo tiempo) lo c al podra ocasionar inconsistencias en los datos de la aplicacin. Para e"itar estas sit aciones e6isten "arias estrategias de dise2o) las c ales se enc entran en s gran ma/ora doc mentadas en J!o=ler%FK.
Monitoreo
-sta , ncionalidad es necesaria para tener "isi#ilidad so#re el comportamiento de las aplicaciones en el am#iente prod cti"o) /a ' e en la ma/ora de los casos el acceso a dicho am#iente se enc entra por dems restringido. 5eneralmente) el monitoreo pro"ee in,ormacin +til para las sig ientes c estiones.
4al d de la aplicacin: Test la aplicacin , ncionando correctamenteU) Tha/ alg+n pico de procesamientoU) Test la aplicacin corriendo en n hard=are adec adoU
3seg rar el c mplimiento de los ac erdos de los ni"el de ser"icio comprometidos. (onocimiento del negocio: Tc ales son las , ncionalidades ms tilizadas de la aplicacinU) Ten ' . momento los s arios tilizan ms la aplicacinU) Tes posi#le optimizar alg+n proceso del negocioU) Tha/ alg+n c ello de #otella en el proceso de negocioU
3dicionalmente d rante el desarrollo el monitoreo sir"e como na herramienta ms para la dep racin de la aplicacin.
3r' itect ra
-n lo ' e a ar' itect ra lgica respecta) la ar' itect ra en capas Cla/ersDJG schmann0@K se ha con"ertido en n estndar de ,acto para estas aplicaciones. Dicha ar' itect ra propone estr ct rar la aplicacin agr pando s s componentes en capas. Los componentes dentro de na misma capa de#en ser cohesi"os / tener el mismo ni"el de a#straccin. 3l mismo tiempo cada capa desconoce la capa s perior mientras ' e hace so de las , ncionalidades pro"istas por la capa in,erior. -n JTro=#ridge%FK se mencionan alg nas "ariantes / re,inamientos de este patrn m / com nes en las aplicaciones enterprise) pero sin d da la "ariante ms adoptada es la de tres capas. Dicha "ariante propone descomponer la aplicacin en na capa de presentacin) na de lgica de negocio / na de acceso a datos. -ntre las "enta*as ' e pro"ee la di"isin en capas se enc entran el desacoplamiento de las mismas / la posi#ilidad de distri# irlas ,sicamente. Relacionado a la distri# cin ,sica de las capas ha/ ' e mencionar ' e generalmente s ele hacerse ser"idores de aplicaciones. tilizando , ncionalidades pro"istas por los
Nicols M. Paez
32 - 110
Figura 18: Estructura gen!rica en ca$as de +E
La capa de presentacin se encarga de la interaccin con el s ario) mientras ' e la de lgica de negocio como s nom#re lo indica contiene todas las reglas del negocio. !inalmente la capa de acceso a datos) encaps la la interaccin con el repositorio de in,ormacin) generalmente na #ase de datos relacional. -n alg nos casos se propone na capa trans"ersal denominada de in,raestr ct ra operacional ' e agr pa a' ellos componentes de so com+n en todas las capas) como ser: mane*o de e6cepciones) monitoreo / seg ridad) entre otros. -6isten "ariantes espec,icas de la ar' itect ra de F capas para las distintas tecnologas J?eziersBi%FK) J?ohnson%$K) J3shmore%>K / JNilsson%AK. Ga*ando el ni"el de a#straccin) dentro de cada capa es n estndar en la act alidad la tilizacin de programacin orientada a o#*etos. -sto se de#e a ' e la P99 pro"ee potentes mecanismo de encaps lamiento / mod larizacin ' e res ltan m / con"enientes para el mane*o de la comple*idad inherente de las 3-. ? nto con la P99 es m / com+n por esto das el so de patrones de dise2o.
Nicols M. Paez
33 - 110
Figura 11: 9ariante mu1 difundida de ar:uitectura en ca$as
Patrones de dise*o
Desde hace /a "arios a2os) es m / com+n en todo desarrollo de so,t=are orientado a o#*etos) el so de patrones de dise2o. De ac erdo a (hristo,er 3le6ander J3le6ander&&K: P...cada patrn descri#e n pro#lema ' e oc rre na / otra "ez en n estro entorno) as como la sol cin a ese pro#lema) de tal modo ' e se p eda aplicar esta sol cin n milln de "eces) sin hacer lo mismo dos "eces.Q 4i #ien este a tor se re,era a patrones de ci dades / edi,icios) s de,inicin , e tomada por -rich 5amma / compa2a) ' ienes escri#ieron el li#ro , ndacional de patrones de dise2o de so,t=are J5amma0@K. 3lg nas c estiones interesantes so#re los patrones son las sig ientes.

Los patrones no se in"entan) sino ' e se desc #ren. La de,inicin de n patrn consta > elementos: n nom#re) n pro#lema al c al se s pone el patrn aplica) na sol cin ' e indica como resol"er el pro#lema / n con* nto de consec encias) s rgidas de la aplicacin del patrn.
-l so de patrones permite esta#lecer n leng a*e com+n para la com nicacin / al mismo tiempo ele"a el ni"el de a#straccin de la con"ersacin.
Nicols M. Paez
34 - 110
-6isten tres tipos de patrones de dise2o) dependiendo de s
ni"el de a#straccin. Los
patrones de ar' itect ra) son patrones de alto ni"el ' e tratan de como estr ct rar los md los de la aplicacin. Los patrones de dise2o propiamente dichos) tratan de dise2o de clases. !inalmente los denominados idioms) tratan de patrones partic lares de n leng a*e o tecnologa. Los patrones en nciados en la p #licacin original de 5amma J5amma0@K son de so general. (on el correr del tiempo han ido s rgiendo ,amilias de patrones espec,icos de cada dominio. -n partic lar) el li#ro de Martin !o=ler J!o=ler%FK se ha con"ertido en na de las p #licaciones de re,erencia en lo ' e a patrones enterprise respecta. Eeamos alg nos de los patrones ms com+nmente tilizados en cada capa. -n la capa de presentacin s ele tilizarse el patrn Model2(ie32Controller Co alg nas de s s "ariantes como MEP) ,rontIcontroller / pageIcontrollerD. -ste es n patrn de alto ni"el ' e propone na descomposicin estr ct ral de la aplicacin en tres partes) tal como s nom#re lo re,le*a: Modelo) Eista / (ontrolador. -n c anto a la capa de negocio) e6isten #sicamente F patrones para organizar la lgica: #ransaction Script) #ableModule / "omain Model. -n m chos casos es com+n encaps lar la lgica de negocio tilizando aplicando el patrn service la4er) lo ' e deri"a en ' e la capa de negocio sea di"idida en dos s #capas: na capa de de ser"icios de negocio / otra de lgica de negocio. Los ser"icios de negocio act an como na ,achada so#re la lgica s #/acente) realizando che' eos de seg ridad / administrando el conte6to transaccional. -n la capa de acceso a datos s elen tilizarse los patrones como #able"ata%ate3a4 /
"atamapper. -l primero se s ele tilizar c ando la lgica de negocio est organizada en #ase a Transaction 4cripts) mientras ' e el so del seg ndo es ms com+n c ando el negocio est #asado en Domain Model. 3lg nos otros patrones de so com+n son "ata #ransfer 5bject) "ependenc4 )njection / (alue 5bject. Capa Presentacin 6gica de negocio Acceso a datos Patrones ModelIEie=I(ontroller) !ront (ontroller) Page (ontroller Domain Model) Transaction script) Ta#leMod le) 4er"ice la/er Datamapper) 3cti"e record) Ta#leDataa=a/
*abla #: Patrones de uso com;n en +$licaciones Enter$rise
-n no de los ap.ndices ha/ ms in,ormacin so#re los patrones a' mencionados.

rientacin a servicios
;asta a' hemos "isto las generalidades de las aplicaciones enterprise / s s caractersticas t.cnicas ms importantes en la act alidad) pero ms all de esto) es , ndamental no perder de "ista el conte6to organizacional en el c al de#en enca*ar estas aplicaciones. -s moneda corriente ' e los procesos de negocio de na organizacin in"ol cren a ms de na aplicacin) necesitando de la coordinacin de n con* nto de aplicaciones. -ste ,enmeno ha dado origen a n n e"o paradigma denominado orientacin a ser"icios. 3corde a este n e"o paradigma) cada aplicacin est constit ida por n con* nto de ser"icios) donde cada ser"icio implementa na , ncin del negocio) posi#ilitando ' e la implementacin de n proceso de negocio pase a ser na or' estacin de ser"icios. Para ' e na aplicacin p eda considerarse orientada a ser"icios) de#e c mplir con ciertos principios de dise2o. 4eg+n J-rl%@K) no e6iste na de,inicin o,icial de dichos principios) pero a pesar de ello e6iste sig ientes.

n con* nto de principios ampliamente aceptados entre los ' e se enc entran los
Todo ser"icio e6pone n contrato ,ormal para s interaccin. Los ser"icios estn desacoplados entre s. Los ser"icios son a#stractos a la lgica s #/acente. Los ser"icios son a tnomos. Los ser"icios no tienen estado.
De ac erdo a J-ndrei%>K la orientacin a ser"icios pro"ee los sig ientes #ene,icios.

Posi#ilidad de re tilizacin de los acti"os e6istentes. Red ccin de costos a partir de n ma/or re so. Ma/or ,acilidad de integracin. Me*or TimeIToIMarBet.
Tecnologas
-n c anto a tecnologas) act almente el terreno est claramente di"ido entre ?a"a / Microso,t.N-T. 4i #ien estas dos tecnologas parecen ser antagnicas) res ltan ser m / similares. 3m#as tecnologas estn #asadas en m' inas "irt ales ' e soportan el paradigma de programacin orientada a o#*etos / pro"een al menos desarrollo / na e6tensa #i#lioteca de clases. 4i #ien am#as tecnologas p eden tilizarse para di"ersos tipos de aplicaciones) se enc entran , ertemente orientadas al desarrollo de aplicaciones de enterprise. Dentro de este conte6to) e6isten en estas plata,ormas componentes denominados ser"idores de aplicaciones. -stos ser"idores son
n leng a*e de programacin)
n entorno integrado de
aplicaciones ' e permiten alo*ar otras aplicaciones a las c ales les #rindan ciertos ser"icios entre los c ales p eden mencionarse: soporte transaccional) mane*o de sesiones) distri# cin de o#*etos) etc. 3dems de estos ser"icios) los ser"idores de aplicaciones permiten alcanzar ciertos atri# tos de calidad como ser escala#ilidad / disponi#ilidad) pero al mismo imponen ciertas restricciones so#re la ,orma de programacin / la ar' itect ra de las aplicaciones. La ,ig ra <$ m estra los principales #lo' es constit ti"os de estas dos tecnologas Cha/ #lo' es ' e han sido omitidos por no contar con no anlogo en la otra tecnologaD.
Figura 12: Princi$ales blo:ues de las tecnolog3as ,ava 1 "<E*
Nicols M. Paez
3 - 110
(apt lo 8E: ;acia las aplicaciones enterprise con 39P

8ntrod ccin
Dado ' e el o#*eti"o de 39P es ,acilitar la mod larizacin de los ((() es de esperar ' e s aporte a las 3- sea en ese sentido) es por ello ' e comenzaremos este capt lo identi,icando las inc m#encias trans"ersales ms com nes en las 3-. L ego "eremos como es ' e las mismas son atacadas en la act alidad en las 3- / ,inalmente "eremos como sera el proceso de comenzar a tilizar 39P para atacarlas. 3ntes de entrar de lleno en el tema de este capt lo es necesario hacer alg nas aclaraciones preliminares. 4i #ien es posi#le ha#lar de inc m#encias trans"ersales en las distintas etapas del proceso de desarrollo Canlisis) dise2o) implementacin) etc.D tal como lo plantean m+ltiples tra#a*os J4o saKJ39R-KJ-arl/3spectsK slo nos concentraremos en las inc m#encia trans"ersales a ni"el de implementacin Ccdigo , enteD. 3simismo nos encontramos ' e las inc m#encias tran"ersales a ni"el de implementacin p eden "ariar en #ase a la tecnologa tilizada. Un e*emplo de esto es la administracin de memoria) la c al representa n clara inc m#encia trans"ersal en ( / (SS) hecho ' e no oc rre en ?a"a / .N-T) donde la administracin de la memoria est a cargo de la plata,orma de e*ec cin. Dado ' e las tecnologas predominantes en el desarrollo de aplicaciones enterprise en la act alidad son ?a"a / .N-T) n estro anlisis de las inc m#encias trans"ersales ser alrededor de estas dos tecnologas.
8nc m#encias trans"ersales

3 simple "ista en toda aplicacin nos encontramos con dos tipos de inc m#encias:
incumbencias dominantes) ' e generalmente se logran mod larizar sin ma/ores incon"enientes tilizando las t.cnicas tradicionales de programacin) /a ' e constit /en la dimensin dominante del pro#lema. -n el caso de las aplicaciones enterprise estas inc m#encias pertenecen a la capa de lgica de negocio / por ello las denominaremos inc m#encias del negocio. Dado ' e generalmente estas inc m#encias son partic lares de cada aplicacin) s anlisis lo postergaremos hasta el capt lo A donde analizaremos n caso concreto.
Nicols M. Paez
3! - 110
incumbencias no dominantes) relacionadas generalmente a los atri# tos de calidad / re' isitos t.cnicos de la aplicacin. Dado ' e estas inc m#encias no pertenecen a la dimensin dominante) s mod larizacin p ede res ltar di,ic ltosa tilizando las t.cnicas tradicionales de programacin. 4i #ien e6isten #i#liotecas espec,icas ' e implementan cada na de estas inc m#encias) res lta ' e las llamadas a dichas #i#liotecas se enc entran dispersas por todo el cdigo) generando los conocidos ,enmenos de cdigo mezclado / cdigo disperso) e"idenciando na nat raleza trans"ersal. -n el caso de la 3-) m chas de estas inc m#encias son llamadas ser"icios enterprise. -stas inc m#encias sern tratadas en el capt lo @ / en general nos re,eriremos a ellas como inc m#encias t.cnicas.
-n el caso de la 3-) e6isten en la act alidad "arias prop estas para la mod larizacin de las inc m#encias no dominantes) m chas de las c ales c entan con n importante grado de adopcin. -n la sig iente seccin analizaremos alg nas de estas prop estas.
8ntentos de mod larizacin

Servidores de aplicaciones / componentes
Tanto *a"a como .N-T o,recen como parte de s s ar' itect ras de re,erencia componentes denominados ser"idores de aplicaciones ' e #rindan n entorno de e*ec cin / na serie de ser"icios para las aplicaciones ' e son desplegadas en ellos. Los ser"idores de aplicaciones #rindan sol ciones a "arias de las pro#lemticas enterprise mencionadas en el capit lo F Cdistri# cin) escala#ilidad / alta disponi#ilidad) entre otrosD / es por ello ' e en la act alidad casi todas las 3- dependen de alg+n ser"idor de aplicaciones. Un caso partic lar de ser"idor de aplicaciones son los ser"idores de componentes) los c ales #rindan alg nos ser"icios enterprise adicionales como mane*o de transacciones / distri# cin de componentes) entre otros. 3l mismo tiempo permiten ' e los componentes desplegados en ellos hagan so de los mencionados ser"icios en ,orma declarati"a) dismin /endo as el es, erzo de desarrollo / la cantidad de cdigo relacionado a in,raestr ct ra. -n el caso de *a"a) los ser"idores de componentes son conocidos como contenedores -?G) mientras ' e en el caso de .N-T el ser"idor de componentes es (omponent 4er"ices Ctam#i.n conocido como (9MSD. 4i #ien con el so de ser"idores de componentes se ,acilita la implementacin de alg nas
inc m#encias trans"ersales) e6isten alg nas limitaciones. Una de las des"enta*as ' e tiene el so de ser"idores de componentes es ' e s elen imponer n modelo de programacin #astante intr si"o ' e s ele di,ic ltar la pr e#a de los componentes / a menta de manera considera#le el es, erzo de desplieg e de la aplicacin. 9tras de las des"enta*as mencionadas en J?ohnson%>K es ' e los ser"icios
#rindados por los ser"idores de componentes son limitados) en el sentido de ' e no es posi#le agregar ser"icios adicionales desarrollados por el programador.
&ramewor's de aplicacin
9tra herramienta de so m / com+n el desarrollo de 3- son los ,rame=orBs de aplicacin Ca$$lication frame%or4s +F=. Un ,rame=orB es n s #Isistema) parcialmente completo ' e de,ine la ar' itect ra de na ,amilia de sistemas) pro"e/endo los #lo' es #sicos para s creacin / especi,icando los p ntos de e6tensin / adaptacin JG schmann0@K. Un ,rame=orB para n dominio espec,ico de aplicaciones es n ,rame=orB de aplicacin. 3lg nos de los #ene,icios del so de estos ,rame=orBs son los sig ientes.
Productividad: los 3! estandarizan la ,orma de resol"er los pro#lemas) permitiendo ' e a la hora de resol"er n n e"o pro#lema no de#a empezarse desde cero.
Ma4or foco en la lgica central de la aplicacin: los e' ipos de desarrollo p eden concentrarse en la , ncionalidad principal de la aplicacin) de*ando en manos del 3! las c estiones t.cnicas no , ncionales ' e cas almente s elen ser inc m#encias trans"ersales no dominantes.
Predictibilidad: las sol ciones #asadas en la ar' itect ra prede,inida por el 3!) red cen el riesgo / a mentan la predicti#ilidad del proceso de desarrollo / de la aplicacin ,inal.
-ntre los ser"icios ' e s elen #rindar los 3! para 3- se enc entran:

(on,ig racin de la aplicacin / de s s o#*etos. Mane*o de transacciones. 4impli,icacin de la interaccin con la capa de acceso a datos. Mane*o de errores.
3 modo de e*emplo "eamos alg nos 3! para desarrollo de aplicaciones enterprise.

Enterprise Development Application Framework (EDAF)
7"A8 es n 3! desarrollado por el gr po de Prcticas / Patrones de Microso,t (orporation en el a2o $%%>) con el o#*eti"o de ,acilitar el desarrollo de aplicaciones enterprise orientadas a ser"icios / #asadas en estndares de la ind stria. -l desarrollo de -D3! , e g iado por los sig ientes principios de dise2o:

4eparacin de la inter,az de ser"icios de la implementacin interna de los mismos. 4eparacin de la lgica de negocio de las inc m#encias no , ncionales como a ditoria / monitoreo) entre otros.
4eparacin de la lgica de negocio de la tecnologa de com nicacin) permitiendo ' e n mismo ser"icio de negocio p eda ser accedido por "a de distintas tecnologas de
Nicols M. Paez
40 - 110
com nicacin. La ,ig ra <F) m estra la ar' itect ra prop esta por -D3!) la c al consiste en na "ariante de la ar' itect ra de F capas) donde la capa de presentacin interact+a con la inter,az de ser"icio. La capa de inter,az de ser"icio act+a como ,rontera) rechazando pedidos in"lidos o no a torizados. L ego ha/ na capa ' e contiene lgica trans"ersal) como a ditora / transaccionalidad / opera antes C/ desp .sD de la e*ec cin de la lgica de negocio.
Figura 1#: Estructura de ca$as $ro$uesta $or ED(+
3 grandes rasgos el procesamiento de n pedido consisten en: <. -l ,l *o comienza con n mensa*e en"iado por la capa cliente para la e*ec cin de na accin de negocio. $. -l mensa*e es mane*ado por n adaptador asociado al canal de com nicacin. -l adaptador crea n conte6to para el procesamiento del mensa*e / lo pasa al pipeline correspondiente. F. -l pipeline) consiste en na cadena de handlers / n o#*eti"o. Una "ez e*ec tados los handlers) ' e generalmente realizan operaciones relacionadas a inc m#encias trans"ersales) se da paso a la e*ec cin del o#*eti"o) ' e siempre consiste en na accin de negocio. Los handlers) act+an como interceptores en el proceso de e*ec cin) / p eden e*ec tarse antes /No desp .s del o#*eti"o. 4i #ien -D3! pro"ee ciertos handlers de aplicacin. so com+n) tam#i.n es posi#le desarrollar los propios. -stos handlers estn pensados para mane*ar la lgica trans"ersal de la
Nicols M. Paez
41 - 110
Figura 1.: Proceso de ejecucin de una $eticin ED(+
La estrategia plateada por -D3! para el mane*o de las inc m#encias trans"ersales) tilizando handlers en el pipeline de e*ec cin) , e l ego adoptada por 9indo3s Communication 8oundation J=c,K ' e es no de los #lo' es , ndacionales de la "ersin F.% de la plata,orma .N-T. W(!) al ig al ' e -D3!) pro"ee tiempo)#rinda n con* nto de handlers Cen el caso de =c, son llamados #eha"iorsD ' e implementan ciertas inc m#encia tpicas como a ditora) seg ridad / transaccionalidad. 3l mismo n modelo de programacin e6tensi#le) permitiendo ' e el programador p eda desarrollar s s propios handlers. 4i #ien la tilizacin de n pipeline de e*ec cin con handlers para aplicar , ncionalidades trans"ersales) tiene na gran similit d con lo ' e hacen las herramientas 39P #asadas en pro6ies dinmicos) tanto -D3! como W(! tienen ciertas limitaciones para el mane*o de inc m#encias trans"ersales) en comparacin con las herramientas 39P. -n primer l gar) el en,o' e de -D3!NW(! #rinda sol cin para inc m#encias trans"ersales a ni"el de ser"iciosA) pero no para las inc m#encias trans"ersales de grano ms ,ino ' e p eden a,ectar a los o#*etos ' e son tilizados dentro de los ser"icios. -n t.rminos de 39P: con -D3!NW(! es posi#le aplicar aspectos a ser"icios pero no a o#*etos. -n seg ndo l gar) a n' e no menos importante) -D3!NW(! no #rinda la posi#ilidad de e6presar gen.ricamente a ' . ser"icios se pretende aplicar aspectos) sino ' e es necesario en merarlos no a no. -n t.rminos de 39P: el mecanismo de c anti,icacin de -D3!NW(! es m / limitado en comparacin con los modelos de pointc ts pro"istos por las herramientas 39P. Por +ltimo con W(! no es posi#le e6tender la estr ct ra de los ser"icios. -n t.rminos 39P) -D3!NW(! no soporta declaraciones de intertipo. 4i #ien en los prra,os anteriores se hizo re,erencia e6plcita a W(!) los mismo pro#lemas aplican en ma/or o menor medida a todas las herramientas ' e san n modelo handlers no orientado a
A -n este caso el t.rmino ser"icio hace re,erencia a n o#*eto sin estado) ' e #rinda , ncionalidad de grano gr eso.
aspectos.
Contenedores livianos
-n el a2o $%%> Rod ?ohnson p #lic el li#ro P?$-- De"elopment =itho t -?GQ J?ohnson%>K en el c al a,irma ' e slo n pe' e2o porcenta*e de las 3- re' ieren realmente de la tilizacin de n ser"idor de componentes&. 3 partir de esta a,irmacin) ?ohnson propone / detalla a lo largo del mencionado li#ro el so de contenedores li"ianos como na alternati"a ,acti#le para la gran ma/ora de las 3-. Los contenedores li"ianos son n tipo partic lar de 3! ' e se caracterizan por los sig ientes moti"os.

Promo"er la orientacin a o#*etos / las # enas prcticas de dise2o. Proponer n modelo de desarrollo no intr si"o) imponiendo mnimos re' isitos a los o#*etos ' e contienen.
Pro"eer na serie de , ncionalidades Cser"icios enterpriseD para los o#*etos ' e contienen) entre las ' e se enc entran el mane*o del ciclo de "ida / resol cin de dependencias.
Grindar soporte de ciertas caractersticas 39P.
?ohnson sostiene ' e mientras ' e los ser"idores de componentes o,recen na cantidad limitada de , ncionalidades enterprise e imponen n modelo de programacin intr si"o) tilizando contenedores li"ianos en con* nto con 39P) es posi#le contar con prcticamente los mismas , ncionalidades) con n modelo de programacin no intr si"o / con la posi#ilidad de e6tender dichas , ncionalidades o incl so agregar n e"as.
Figura 10: &dulos de 7$ring Frame%or4
-stas ideas de ?ohnson t "ieron n gran impacto en la com nidad de desarrolladores ?a"a) pro"ocando n adopcin masi"a de contenedores li"ianos) en partic lar de 4pring !rame=orB. ! e tal
& ?ohnson se re,iere en partic lar a contenedores -?G
la magnit d este impacto ' e s
in,l encia se "io re,le*ada en las sig iente "ersin de las
especi,icaciones de los contenedores -?G. 3dicionalmente ha/ ' e destacar ' e en la act alidad 4pring.39P C no de los md los de 4pring!rame=orBD se enc entra entre las herramientas 39P ms tilizadas. 4i #ien los contenedores li"ianos s rgieron como na alternati"a a los ser"idores de componentes *a"a Ccontenedores -?G) considerados contenedores pesadosD en la act alidad s ho/ en da con "ersiones para plata,orma .N-T. -ntre los contenedores li"ianos act ales se destacan 4pring !rame=orB C*a"a / .N-TD / Windsor (astle C.N-TD) am#os pro"een "arias , ncionalidades tpicas en 3-) ' e p eden ser tilizadas declarati"amente. La ma/ora de estas , ncionalidades han sido implementadas integrando #i#liotecas espec,icas mediante el so de interceptores. ;a/ ' e mencionar ' e a pesar de ' e estos 3! #rindan soporte de 39P) en m chos casos se opta por tilizar e6plcitamente interceptores en l gar de las a#stracciones o,recidas por 39P. 3 pesar del e6tendido so de contenedores li"ianos) el so de s s capacidades 39P es escaso) lo c al p ede ' e se de#a al desconocimiento de los programadores del paradigma 39P) ' e incl so ha#iendo esc chado de 39P) pre,ieren el so directo de interceptores en l gar de tra#a*ar con las a#stracciones de,inidas por 39P.
2ibliotecas enterprise
so se ha e6tendido
tam#i.n a .N-T) al p nto ' e tanto 4pring!rame=orB como Pico(ontainer) s rgidos en *a"a) c entan
Las #i#liotecas) a di,erencia de los ,rame=orBs) no imponen restricciones so#re la ,orma de desarrollar) o sea) c ando no tiliza n ,rame=orB) est tomando na estr ct ra #ase en la c al Pench ,aQ componentes propios sig iendo las reglas imp estas por el ,rame=orB. Por s parte el so de na #i#lioteca #rinda la posi#ilidad de estr ct rar la aplicacin como no g ste / simplemente in"ocar Co Pench ,arQD la , ncionalidad #rindada por la #i#lioteca c ando as se lo re' iera. 3l mismo tiempo las #i#liotecas implementan , ncionalidades m cho ms p nt ales ' e los ,rame=orBs. La contra de c al' ier #i#lioteca es ' e si #ien s , ncionalidad se enc entra #ien mod larizada) las llamadas a la #i#lioteca p eden llegar a dispersarse por todo el cdigo de la aplicacin. -6isten en la act alidad "arias #i#liotecas de gran tilidad en el desarrollo de 3-. -n partic lar en los desarrollos con tecnologa .N-T) se destaca el so de PMicroso,t -nterprise Li#rar/Q) la c al es n #i#lioteca de cdigo a#ierto desarrollada por el e' ipo de Prcticas / Patrones de Microso,t) ' e agr pa n con* nto de #i#liotecas tilitarias las c ales implementan cada na) na inc m#encia com+n en 3- como ser logging) caching o mane*o de e6cepciones. La +ltima "ersin de la -nterprise li#rar/ ha incorporado n n e"a #i#lioteca llamada Polic/
Nicols M. Paez
44 - 110
8n*ection 3pplication GlocB) ' e permite insertar interceptores Cllamados handlersD en las llamadas a ciertos o#*etos para implementar inc m#encias trans"ersales / de esta ,orma permitir el so de otras #i#liotecas) e"itando el cdigo disperso / entremezclado ' e estas s elen generar. 4i #ien en cierto p nto el Polic/ 8n*ection 3pplication. GlocB) podra llegar a #rindar las mismas , ncionalidades ' e na herramienta 39P #asada en pro6ies dinmicos) el ni"el de a#straccin pro"isto por el mismo es m cho ms r dimentario) /a ' e carece de la semntica 39P. 3l mismo tiempo n p nto destaca#le es ' e trae na serie de interceptores /a implementados entre los ' e se enc entran Logging) (aching) mane*o de e6cepciones / a torizacin
A P Alliance
-n el a2o $%%F n con* nto de personalidades relacionadas al mo"imiento de la orientacin a aspectos) entre las ' e se encontra#an 5regor Riczales) Rod ?ohnson / Rena d Pa=laB) , ndaron el pro/ecto 39P 3lliance JaopallianceK. La moti"acin de estos indi"id os se de#i a la e6istencia de m+ltiples herramientas 39P) ' e por ha#er s rgido principalmente de am#ientes e6perimentales) res lta#an tener ciertos p ntos de incompati#ilidad al intentar ser tilizadas en am#ientes espec,icos Cpartic larmente am#ientes ?$--D. -s por esto ' e el pro/ecto de,ini los sig ientes o#*eti"os.

-"itar la reprogramacin de las herramientas 39P) permitiendo s re so. 4impli,icar la adaptacin de las herramientas 39P e6istentes para n am#iente determinado Ctpicamente ?$--D.
4impli,icar el re so de aspectos contando con na 3P8 com+n. 4impli,icar la implementacin de herramientas de desarrollo ' e deseen integrarse con 39P.
-l pro/ecto ha tenido n .6ito relati"o) /a ' e a > a2os de s , ndacin) en el sitio o,icial JaopallianceK) solo p eden encontrarse n #orrador del =hite paper , ndacional JPa=laB%FK / la especi,icacin de na 3P8 39P en ?a"a) para ser implementada por herramientas 39P #asadas en pro6ies. 4i #ien esta 3P8 ha sido implementada por "arias herramientas Cincl so con tecnologas distintas a *a"aD no todas la han implementado. Una ,alencia de la 3P8 de,inida por 39P 3lliance es ' e no es lo s ,icientemente a#stracta) /a ' e hace mencin e6plcita reiteradamente a interceptores ' e no son n concepto propio de 39P) sino na mera c estin de implementacin) de la c al el programador de#era estar a*eno.
Mitos / le/endas
;a#iendo p esto de rele"ancia la necesidad de contar na herramienta ' e permita na me*or mod larizacin de las inc m#encias trans"ersales / antes de e6poner cmo es ' e con 39P p ede lograrse) es necesario hacer alg nas aclaraciones preliminares / dar por tierra con alg nos mitos / pre* icios so#re 39P) "arios de los c ales han sido tratados por Ramni"as Laddad JLaddad%AK.
A P considered "armful
Una de las o#*eciones ms importantes al so de 39P se enc entra doc mentada en el pol.mico artc lo P39P considered harm, lQ J4toerzer%>K el c al compara el so de 39P con el so de la cla s la 59T9) repasando los arg mentos planteados por Di*Bstra en s 4tatement considered harm, lQJDi*BstraA:K. Di*Bstra plantea#a ' e el ,amoso escrito P5o to so de la cla+s la 59T9
di,ic lta#a el entendimiento del ,l *o de e*ec cin del sistema por parte de los programadores. 4eg+n 4toerzer los ad"ices son en cierto sentido similares a procedimientosNm.todos) pero al mismo tiempo tienen ciertas propiedades ' e al ig al ' e el 59T9) di,ic ltan el entendimiento de la sec encia de e*ec cin del sistema.
-n primer l gar) el cdigo ' e e6pone los *oinpoints no tiene conocimiento de los ad"ices ' e se e*ec tarn en dichos *oinpoints Cpropiedad de transparenciaD. 4i #ien en ocasiones los entornos de desarrollo tienen la propiedad de mostrar los *oinpoints a,ectados por ad"ices) esto no es na propiedad de la herramienta 39P en si misma. -sto hace ' e en cierto p nto los ad"ices sean incl so peores ' e el 59T9) /a ' e el 59T9 al menos es "isi#le en el cdigo) mientras ' e los ad"ices son a#sol tamente transparentes.
-n seg ndo l gar) los *oinpoints a,ectados por n pointc t no siempre p eden determinarse estticamente) p es en el caso de los pointc ts dinmicos) los *oinpoints a,ectados dependen de los "alores ' e toman los *oinpoint d rante s e*ec cin. 4i #ien con la P99 / el polimor,ismo oc rre algo similar Iel en sentido de ' e ante n m.todo polimr,ico) no es posi#le sa#er ' e cdigo se e*ec tar realmente) hasta el momento de la e*ec cinI la com nidad 99 ha desarrollado n con* nto de reglas / # enas prcticas so#re como tilizar / como no) la rede,inicin de m.todos.
-n c anto al primer p nto) tal como lo ha mani,estado Riczales) a di,erencia del 59T9) los entornos de desarrollo #rindan in,ormacin so#re los p ntos donde se aplicarn aspectos / si #ien esto implica na dependencia del entorno de desarrollo) ho/ en da el desarrollo de c al' ier aplicacin real es casi impensado sin el so de entornos de desarrollo integrados) dado el gran es, erzo ' e re' erira recordar la sinta6is tanto de las #i#liotecas propias como de las pro"istas por la plata,orma. -n c anto al seg ndo p nto) 39P mediante el soporte de pointc ts dinmicos permite ele"ar el ni"el de a#straccin / al ig al ' e oc rre con el polimor,ismo en P99) las a#straccin es in"ersamente proporcional al conocimiento del ,l *o de e*ec cin: c anto ma/or es el ni"el de a#straccin) ms di,ic ltoso es esta#lecer el ,l *o de e*ec cin del sistema. -s interesante tam#i.n la posicin de Rod GodBin al respecto de estas o#*eciones. Para .l la me*or herramienta para entender n sistema es n # en dise2o. 39P me*ora la mod larizacin ,acilitando el entendimiento del sistema) incl so sin contar con herramientas integradas al entorno de
desarrollo. La prctica de mirar el cdigo , ente para entender el sistema) no aplica en el caso de las grandes aplicaciones) donde na # ena mod larizacin res lta m cho ms importante. 3l mismo tiempo en J-lrad%<K) ;arold 9ssher cons ltado respecto de si 39P di,ic lta el entendimiento de la aplicacin) a,irma ' e las inc m#encias estn presentes en toda aplicacin) mezcladas de na otra ,orma / ' e representan la principal , ente de comple*idad. Los en,o' es orientados a aspectos permiten ' e las inc m#encias trans"ersales implcitas sean e6tradas / e6plicitadas) posi#ilitando a los programadores ' e "ean con ' . estn lidiando. Por s parte Ramni"as Laddad) en s artc lo P39P m/ths and realitiesQJLaddad%AK) identi,ica esta pro#lemtica con el mito Plos aspectos osc recen el ,l *o del programaQ. 3nte este mito Laddad a,irma ' e #ien "ale la pena sacri,icar cierta claridad del ,l *o del programa a cam#io de ele"ar el ni"el de a#straccin) lo c al permite n mapeo ms directo entre los re' isitos) el dise2o / el cdigo) e"itando ' e las inc m#encias trans"ersales se pierdan dispersas en el cdigo. 3l mismo tiempo) esta p.rdida de claridad p ede ser mitigada en con el desarrollo. Ea/amos a n caso concreto) analicemos el cdigo del m.todo -*ec tar de la clase Trans,erencia en el sig iente ,ragmento de cdigo.
public abstract class <uenta>ancaria { public abstract void debitar(double monto); public abstract void acreditar(double monto); ' public class <uenta<orriente extends <uenta>ancaria { public void debitar(double monto) { ### ' public void acreditar(double monto) { ### ' ' public class <a;aDe5)orro extends <uenta>ancaria { public void debitar(double monto) { ### ' public void acreditar(double monto) { ### ' ' public class Frans4erencia { private <uenta>ancaria cuenta+ri1en; private <uenta>ancaria cuentaDestino; public void e;ecutar(){ ori1en#debitar(monto); destino#acreditar(monto); ' '
so de herramientas integradas al entorno de
-l cdigo mostrado slo hace so de 99) pero dado ' e se ha tilizado herencia no es posi#le sa#er mirando el cdigo ' e cdigo se e*ec tar al in"ocar a los m.todos debitar / acreditar. X si #ien tampoco es posi#le sa#er si d rante la e*ec cin inter"endr alg+n aspecto) si tilizaramos n entorno desarrollo con soporte de 39P como -clipse) el mismo entorno nos indicara de la inter"encin de los aspectos. Por la tanto) si la 99 / el polimor,ismo tam#i.n osc recen el ,l *o de e*ec cin / a pesar de
ello son tilizados en pos de me*orar la mod larizacin) lo mismo de#eramos considerar para 39P.
A P viola el encapsulamiento
-sta es otra de las o#*eciones planteadas com+nmente al
so de 39P / s ele res ltar
consec encia de "er 39P desde na ptica orientada a o#*etos. Para entender por' . es errnea esta a,irmacin es necesario en primer l gar de*ar en claro ' e es lo ' e se pretende encaps lar. Lo ' e ' eremos encaps lar son las distintas inc m#encias. -n ocasiones al tra#a*ar con 99) na clase de#e lidiar con ms de na inc m#encia / al mismo las inc m#encias trans"ersales estn dispersas por "arias clases) ante lo c al no podra decir ' e las inc m#encias trans"ersales no estn encaps ladas. -n cam#io) para 39P las inc m#encias trans"ersales son encaps ladas por los aspectos) haciendo ' e las clases c enten con na me*or cohesin) /a ' e no de#en lidiar con las inc m#encias trans"ersales. Por s p esto ' e seg+n esta concepcin) la aplicacin est constit ida por la totalidad de las inc m#encias) las modeladas con clases / tam#i.n las modeladas con aspectos. 3l mismo tiempo) es cierto ' e alg nas herramientas 39P permiten inter,erir en los miem#ros pri"ados de las clases) lo c al "iolara el encaps lamiento) pero tam#i.n es cierto ' e ha/ leng a*es 99 ' e permiten de,inir atri# tos p+#licos) lo c al tam#i.n "iola el encaps lamiento. -l hecho de ' e las herramientas permitan hacer ciertas cosas no implica ' e las mismas sean parte del paradigma. (omo oc rre en todo conte6to) al sar c al' ier herramienta siempre en necesaria na c ota de criterio.
Depurar aplicaciones con A P es dif3cil
-sta a,irmacin es identi,icada como mito en JLaddad%AK) donde se sostiene ' e la dep racin siempre es di,cil mientras ' e no se c ente con herramientas apropiadas / 39P no es la e6cepcin. (iertamente la dep racin p ede ser n "erdadero pro#lema dependiendo de la herramienta 39P tilizada) llegando a ser n ,actor de gran in,l encia a la hora de elegir na herramienta 39P. -n el caso de las herramientas 39P #asadas en pro6ies) la dep racin no es demasiado distinta a la dep racin en tecnologas orientadas a o#*etos. Por s parte) en el caso de las herramientas 39P de entrete*ido esttico la dep racin ciertamente s ele ser #astante ms comple*a / representa n claro desa,i para la e"ol cin de 39P. 4i #ien en el caso partic lar de 3spect?) el pl gIin de -clipse 3?DT ,acilita la dep racin poni.ndola al ni"el de la dep racin de *a"a p ro) no oc rre lo mismo con todas las herramientas 39P / esto ha moti"ado "arias lineas de in"estigacin J-idelman%AK) J-add/%@K.
A P / Patrones de Dise*o
-ste tema ha sido tratado en m+ltiples p #licaciones JLaddad%FK) JMiles%@K) JLesiecBi%@K) J-rdod/%AK) pero a pesar de ello) e6iste el mito de ' e p ede o#"iarse el so de 39P si se tilizan patrones de dise2o. La realidad es ' e si #ien los patrones de dise2o o,recen sol ciones gen.ricas a
pro#lemas rec rrentes / la ma/ora de los programadores ' e tilizan tecnologas orientadas a o#*etos estn ,amiliarizados con s e*emplo:

so) los patrones de dise2o presentan alg nas des"enta*as como por
-n ocasiones a,ectan a ms de na clase. 3 "eces son intr si"os. 4 re tilizacin Ca ni"el cdigo , enteD es di,cil. so de 39P p ede
(omo lo dem estran las p #licaciones pre"iamente mencionadas) el
enri' ecer la implementacin de patrones de dise2o) s perando las des"enta*as mencionadas) dismin /endo s comple*idad) ,acilitando s re so / a mentando el grado de ,le6i#ilidad. 8ncl so en alg nos caso) el so de 39P p ede llegar a reemplazar el so de ciertos patrones de dise2o como se s giere en J8s#erg%@K. 4i #ien la gran ma/ora de las p #licaciones so#re esta temtica tratan so#re la implementacin de patrones de dise2o de o#*etos mediante el so de 39P) alg nas p #licaciones tam#i.n proponen el so de patrones de dise2o de aspectos como por e*emplo Pimplicit protocolQ) Panchor protocolQ JPa=laB%@K) Director / Gorder(ontrol JMiles%@K !inalmente) ms all de lo antes mencionado) en cada dise2o el programador de#er decidir Ien #ase a ciertos ,actores del conte6to del pro#lema a resol"erI si sa n patrn tradicional) na "ariante 39P) n patrn 39P o simplemente na sol cin adIhoc.
)a piedra en el zapato
Posi#lemente el pro#lema ms serio ' e en,renta la programacin orientada a aspectos en la act alidad est dado por la ,ragilidad de los modelos de pointc ts de las herramientas 39P. Los pointc ts identi,ican los p ntos de la aplicacin en los ' e inter"endrn los aspectos. -l pro#lema con las herramientas act ales radica en ' e generalmente la de,inicin de los pointc ts se hace tilizando Cpse doDe6presiones reg lares para identi,icar *oinpoints en el cdigo de la aplicacin. -sto hace ' e los pointc ts dependan de cmo se estr ct ra el cdigo so#re el ' e act arn los aspectos. De esta ,orma si el programador decide por e*emplo cam#iar el nom#re de n m.todo) p ede ' e ciertos poinc ts P' eden sin e,ectoQ. Del mismo modo) si el programa e"ol ciona p ede ' e los pointc ts a,ecten a n e"os *oinpoints) por na simple coincidencia de nom#res a pesar de ' e concept almente no de#ieran. -ste pro#lema ha sido analizado en n tra#a*o llamado P9n the e6istence o, the 394DI-"ol tion Parado6QJTo r=.%FK. Dicho tra#a*o destaca el hecho de ' e las herramientas 39P han p esto gran .n,asis en a mentar la mod laridad de las aplicaciones) de*ando de lado las capacidades de e"ol cin de la mismas.
Nicols M. Paez
4" - 110
4i #ien tanto en *a"a como en .N-T este pro#lema p ede mitigarse con el agregado de metadata en ,orma de anotaciones) esto por s solo no res lta na sol cin ptima ni m cho menos) a n' e) constit /e n elemento ms para la constr ccin de posi#les sol ciones. 9tra posi#le ,orma de mitigacin com+nmente citada) es la tilizacin de estndares de desarrollo para la estr ct racin del cdigo / la nomenclat ra. De#ido al gran impacto ' e tiene este pro#lema en la e"ol cin del paradigma) "arios tra#a*os han planteado alg nas posi#les sol ciones. -n JRoppen%>K se propone el so de na herramientaCP(Di,,D para detectar las di,erencias de pointc ts a medida ' e n sistema e"ol ciona. -n J(/ment%>K se plantea n herramienta 39P #asada en pointc ts semnticos CsetpointD ' e parece ser m / prometedora.
A P / AspectJ no son sinnimos
4i #ien 3spect? es claramente la herramienta 39P ms importante / ha e*ercido
na gran
in,l encia en el paradigma 39P) alg nas de las propiedades de 3spect? e6ceden el paradigma. M / com+nmente los conceptos del paradigma 39P / las propiedades de 3spect? se mimetizan) a p nto tal ' e "arios a tores s elen hacer re,erencia a propiedades de 3spect? como si , eran conceptos de 39P. Un caso tpico de este ,enmeno se da c ando ciertos a tores mencionan entre las sos de 39P) el ,orzado de polticas) lo c al es na de la tilidades especi,icas de 3spect?. -sta , ncionalidad de ,orzado de polticas tiene ' e "er con la posi#ilidad ' e o,rece 3spect? de declarar ciertos pointc ts como errores de compilacin. Eeamos n e*emplo concreto: no podra de,inir como poltica de dise2o ' e ning na clase perteneciente a la capa de presentacin p ede in"ocar directamente a clases en la capa de acceso a datos. Utilizando la sentencia declare error) de 3spect? no podra de,inir n pointc t ' e identi,i' e las llamadas de clases de presentacin a clases de acceso a datos / asociar a dicho pointc t na sentencia declare error.
public aspect 5spectoFor6adorDe:oliticas { pointcut en:resentacion() 8 within(presentacion##9); pointcut en:ersistencia() 8 within(persistencia##9); pointcut llamada:ersistencia() 8 call(9 persistencia##9(##)) ?? @ en:ersistencia(); declare error 8 llamada:ersistencia() ?? en:resentacion()8 $5cceso a datos en la presentacion$; ' Figura 1/: ejem$lo de forzado de $ol3ticas con +s$ect,
4i #ien este so de 3spect? p ede res ltar m / +til) no constit /e #a*o ning+n p nto de "ista na propiedad de 39P.
Pros / contras se$4n la industria
De ac erdo al est dio realizado por 3llison D cB JD cB%AK so#re el so de 39P en desarrollos
ind striales) la principal "enta*a de 39P es ' e Ppermite hacer e6actamente lo ' e no ' iere) de ,orma rpida) limpia / poderosaQ. 3l mismo tiempo el incon"eniente ms destacado seg+n dicho est dio) es Pla di,ic ltad de dep racin / la imposi#ilidad de sa#er a simple "ista en ' e partes del cdigo inter"endr n aspectoQ.
Proceso de adopcin
Ron GodBin han de,inido n proceso de c atro ,ases para lograr na e6itosa adopcin de 39P JGodBin%AK) generando e6periencias positi"as / mane*ando el riesgo ' e implica el so de na n e"a tecnologa: <. Aprendizaje 4 e1perimentacin: preg ntas tpicas de esta etapa son PT' e p edo hacer con aspectosUQ / PTcmo los hago , ncionarUQ. 4e elige alg na herramienta / se crean aspectos de e6ploracin ' e #rindan in,ormacin so#re la aplicacin d rante s e*ec cin) casos representati"os son el logging / s s deri"ados pro,iling / tracing. -stos aspectos son a#sol tamente transparentes tanto para la aplicacin como para el e' ipo de desarrollo. Una acti"idad importante para esta etapa es pro#ar los aspectos ' e s elen pro"eer los t toriales de las distintas herramientas 39P. $. :esolucin de problemas reales: en esta ,ase las preg ntas centrales son PT(mo p ede 39P a/ darmeUQ) PTcmo p edo integrar 39P en el tra#a*o cotidianoUQ / PTcmo hacer para ' e el resto del e' ipo adopte 39PUQ. -l ,oco son aspectos t.cnicos / relacionados a atri# tos de calidad como mane*o de e6cepciones) transacciones) cach. / sincronizacin) los c ales p eden o no ' e sean transparentes el e' ipo de desarrollo. F. )ntegracin en el dominio: el comienzo de esta ,ase representa n p nto de in,le6in) las c estiones centrales pasan a ser cmo hacer cola#orar aspectos / clases / cmo integrar 39P en el proceso de desarrollo. 4e tilizan aspectos para modelar inc m#encias del dominio. Todo el e' ipo de desarrollo est al tanto de los aspectos. >. :euso: es el m6imo ni"el de mad rez) ha#iendo tilizado 39P en al menos F pro/ectos) estamos en condiciones de e6traer los aspectos com nes) de,iniendo inter,ases esta#les / componentizandolas en na #i#lioteca de aspectos. 3l mismo tiempo ha/ ciertos principios ' e de#en respectarse a lo largo de todas las etapas.

La adopcin de#e ser incremental dentro de cada etapa. Primero re sar / l ego crear) # scar sol ciones e6istentes ' e p edan re sarse o e6tenderse en l gar de siempre intentar crear n e"as sol ciones.
8n"ertir en sorpresas placenteras) es importante ' e las primeras e6periencias con 39P sean e6itosas para poder ,acilitar el proceso de adopcin.
Nicols M. Paez
51 - 110
3prender con teora / prctica) #alancear la escrit ra de cdigo con la lect ra de artc los de de re,erencia.
Figura 12: Proceso de ado$cin de +-P $ro$uesto $or Bod4in
-n el est dio de D cB pre"iamente mencionado la ma/ora de los entre"istados res ltaron estar en la ,ase < de adopcin) mientras ' e ning no esta#a en ,ase F o >. 3dicionalmente a las ,ases prop estas por GodBin) para poder hacer pleno so de 39P) es necesario hacer alg nas modi,icaciones en las distintas disciplinas del proceso de desarrollo principalmente en lo ' e respecta a modelado de dominio / la capt ra de re' isitos.
3r' itect ra #ase sin 39P

-n los sig ientes dos capt los se analizarn la inc m#encias trans"ersales presentes en las 3- / dado ' e la trans"ersalidad de presente tra#a*o. -sta ar' itect ra ser modi,icada en el capt lo &) c ando se analice el caso de est dio) / se considere el papel de 39P a ni"el de ar' itect ra. na inc m#encia p ede "ariar dependiendo de como se arme la ar' itect ra) res lta necesario de*ar en claro la ar' itect ra #ase ' e se as me en lo ' e resta del
Nicols M. Paez
52 - 110
Figura 15: vista lgica de la ar:uitectura base
La ,ig ra <: m estra la ar' itect ra as mida) la c al consta de @ capas:
Presentacin: m estra la in,ormacin al patrn ModelIEie=I(ontroller.
s ario / capta la interaccin del mismo
con"irti.ndola en estm los hacia el resto de aplicacin. 4e enc entra estr ct rada en #ase al
Servicios: esta capa de,ine las , ncionalidades ' e o,rece la aplicacin) por lo c al en ocasiones tam#i.n es llamada capa de aplicacin. (ada ser"icio de esta capa o,rece n con* nto de operaciones con sentido para el negocio. (apa operacin coordina la interaccin de n con* nto de o#*etos del dominio) al mismo tiempo ' e se encarga de la interaccin con los ser"icios de in,raestr ct ra. (a#e destacar ' e los ser"icios de esta capa carecen de estado.
"ominio: agr pa los o#*etos del dominio ' e representan los conceptos / reglas del negocio. Los o#*etos de esta capa re,le*an el estado del negocio / por ello constit /en el corazn de la aplicacin.
Nicols M. Paez
53 - 110
Persistencia: esta capa se encarga de la persistencia de los o#*etos del dominio en n repositorio permanente) ' e sal"o contadas e6cepciones) es na #ase de datos relacional. -st representada por clases ' e act+an como repositorios de o#*etos.
)nfraestructura: pro"ee , ncionalidades de carcter t.cnico) ' e son
tilizadas por las
dems capas de la aplicacin. 4i #ien en la ,ig ra <: esta capa se m estra desconectada del resto de las capas) es solo por na c estin de claridad) /a ' e todas las capas hacen so de esta. Las , ncionalidades #rindadas por esta capa s elen denominarse ser"icios enterprise o de in,raestr ct ra. -sta ar' itect ra est #asada en la prop esta de ?imm/ NilssonJNilsson%AK) con alg nas sal"edades) por e*emplo: la capa de in,raestr ct ra / persistencia han sido separadas) por considerar a esta +ltima capa ms amplia e importante.
Nicols M. Paez
54 - 110
(apt lo E: 8nc m#encias t.cnicas

(onsideraciones preliminares
-n este capit lo analizaremos las inc m#encias trans"ersales relacionadas a la implementacin de atri# tos de calidad / re' isitos t.cnicos ' e s elen estar presentes en toda 3- / ' e com+nmente son conocidas como ser"icios enterprise. 3ntig amente gran parte de estas inc m#encias eran denominadas re' isitos no , ncionales) lo c al dem estra claramente ' e no ,orman parte de la dimensin dominante del pro#lema. -n c anto a la implementacin de estas inc m#encias) es con"eniente en la ma/ora de los casos tilizar na herramienta 39P entrete*ido dinmico C#asada en pro6ies dinmicosD) /a ' e esto posi#ilitara Pagregar /No ' itar aspectosQ en ,orma declarati"a modi,icando simplemente archi"os de con,ig racin) sin necesidad de "ol"er a compilar toda la aplicacin. -s por esto ' e en los e*emplo de cdigo de aspectos mostrados en este capt lo se tilizar na notacin gen.rica simpli,icada / ,cilmente adapta#le a la notacin de c al' ier herramienta 39P #asada en pro6ies. 3l mismo tiempo ha/ ' e tener en c enta ' e las herramientas 39P #asadas en pro6ies re' ieren ' e los o#*etos a los ' e se les pretende agregar aspectos) sean instanciados tilizando alg na clase de la propia herramienta 39P) para posi#ilitar la creacin del pro6/. 4i #ien esto p ede res ltar intr si"o en m chos casos) no lo es el caso de las 3-) /a ' e el so de ,#ricas de o#*etos de na prctica com+n. Las inc m#encias ' e se analizarn en este capt lo generalmente son implementadas a ni"el de la capa de ser"icios con el ,in de dismin ir s in,l encia trans"ersal) pero en la ma/ora de los casos esta estrategia no res lta lo s ,icientemente e,ecti"a) /a ' e la trans"ersalidad no es eliminada) sino simplemente re #icada. Para cada na de las inc m#encias identi,icadas) daremos na #re"e descripcin poniendo de rele"ancia s nat raleza trans"ersal) comentaremos las ,ormas ms tpicas de implementacin act ales / propondremos) c ando "alga la pena) na implementacin #asada en 39P.
Monitoreo / a ditora
Problem5tica
-l monitoreo #rinda "isi#ilidad so#re el , ncionamiento de la aplicacin. -6isten #sicamente tres t.cnicas de monitoreo cada na con n ,in espec,ico: logging) tracing / pro,iling.
Nicols M. Paez
55 - 110
-l logging es dep racin. -n s
na de las t.cnicas ms
tilizadas para entender el comportamiento de
na
aplicacin. D rante la ,ase de desarrollo el logging s ele sarse en ocasiones como herramienta de ,orma ms #sica el logging consiste en escri#ir en n archi"o de te6to Co simplemente en la salida estndarD mensa*es descri#iendo las operaciones realizadas por la aplicacin. -l tracing es n logging partic lar) donde se hace logging de la e*ec cin de determinadas operaciones. -l pro,iling tiene ' e "er con recolectar in,ormacin so#re el tiempo ' e ins me la e*ec cin de cada operacin. Por s parte la a ditora es na inc m#encia relacionada a la seg ridad del sistema) pero ' e desde el p nto de "ista de implementacin est m / cercana al monitoreo) /a ' e am#as inc m#encias re' ieren de la recoleccin de in,ormacin d rante la e*ec cin de la aplicacin. La a ditora) a di,erencia del monitoreo) recolecta in,ormacin espec,ica del negocio / s ele almacenarla en na #ase de datos.
usin1 "ystem; usin1 <ommon#Lo11in1; namespace >ancoG#Dominio
{
public class <a;aDe5)orro 8 <uenta
protected static *Lo1 Hlo11er / Lo1Iana1er#JetLo11er(typeo4(<a;aDe5)orro)); public override void Debitar(decimal monto)
{
Hlo11er#*n4o($*ntentando <a;aDe5)orro8$ 0 t)is#Kumero 0 $#Debitar8$ 0 monto#Fo"trin1()); i4 (monto L t)is#"aldo) t)ro% ne% "aldo*nsu4iciente,-ception(t)is#"aldoE monto); t)is#"aldo M/ monto; Hlo11er#*n4o($<ompletado <a;aDe5)orro8$ 0 t)is#Kumero 0 $#Debitar8$ 0 monto#Fo"trin1());
' '
' Figura 16: Clase de dominio con cdigo de logging"
-n la act alidad en las aplicaciones enterprise) para la recoleccin de la in,ormacin de monitoreo / a ditora s elen tilizarse #i#liotecas de logging como las pro"istas por el pro/ecto 3pache Logging 4er"ices J3P4K. Las #i#liotecas de logging se encargan e6itosamente de la p #licacin de la in,ormacin recolectada) pero el so de dichas #i#liotecas prod ce cdigo disperso / ) tal como p ede "erse en el ,ragmento de cdigo de la ,ig ra <0.
Solucin A P
La nat raleza trans"ersal del logging C/ s s deri"adosD es tan clara) ' e ha con"ertido a esta inc m#encia en el e*emplo introd ctorio a 39P / como tal) ha sido ha sido tratada en "arias p #licaciones JLaddad%FK) JLesiecBi%FK / JMiles%@K. Dado ' e la p #licacin de la in,ormacin a log ear est #ien mod larizada por #i#liotecas espec,icas) el aspecto de logging de#er encargarse de la recoleccin de la in,ormacin a p #licar / de in"ocar a la correspondiente #i#lioteca de logging eliminando as el cdigo disperso / mod larizando completamente esta inc m#encia. Dependiendo de los ,ines ' e persiga el logging Ca ditoria) trace) pro,iling) de# gging) etcD la in,ormacin a p #licar p ede ser distinta) al ig al ' e la ,orma de interaccin con la #i#lioteca de logging. Para soportar esta pro#lemtica se propone la *erar' a de ad"ices mostrada en la ,ig ra $%.
Figura 28: +dvices $ara monitoreo 1 auditor3a
3 la hora de incl ir esta inc m#encia en n aplicacin concreta) solo ha#r ' e de,inir los pointc ts en los ' e de#er act ar el aspecto / esta#lecer los parmetros de con,ig racin de la li#rera de logging. -l cdigo de la ,ig ra $< de,ine ' e se apli' e el ad"ice 3 ditoria3d"ice a todas las llamadas a m.todos de la clase ( enta / s s descendientes
Naspect name/$5uditoria$L Nadvice type/$5spectos<omunes#5uditoria5dvice$AL Npoincut matc)/$call$ class/$<uenta0$ met)od/$9$ AL NAaspectL Figura 21: Definicin del as$ecto de auditoria $ara el dominio bancario
Persistencia
-n ms de na ocasin) di"ersos a tores se han re,erido a la persistencia como n e*emplo tpico de inc m#encia trans"ersal / por consig iente se ha planteado s J4oares%$K) JRashid%$K) JMiles%@K.
implementacin como aspecto
-n JRashid%$K se plantea ' e la persistencia no slo p ede ser mod larizada sando 39P) sino ' e tam#i.n es posi#le lograrlo con n alto grado de re so) llegando al p nto e6tremo de poder desarrollar la aplicacin ignorando la nat raleza persistente de los datos. Dada la importancia ' e tiene la persistencia de la in,ormacin en el caso de las 3-) res lta di,cil pensar ' e na aplicacin p eda desarrollarse ignorando la e6istencia de la #ase de datos. (omo /a hemos mencionado las 3- s elen contar con na capa de persistencia ' e encaps la la interaccin con la #ase de datos / res el"e el pro#lema de la di,erencia de impedancia. Dependiendo del dise2o ' e se adopte en dicha capa de persistencia) la trans"ersalidad de la persistencia p ede llegar a red cirse de ,orma considera#le. Un claro e*emplo de esto es el soporte de persistencia ' e o,recen los contenedores -?G. 9tras de las herramientas ' e o,rece na interesante sol cin a la persistencia de o#*etos es el ,rame=orB ;i#ernate) el c al se ha con"ertido en n estndar de ,acto) principalmente en el m ndo *a"a. 4i #ien la tilizacin de sol ciones como las mencionadas pareciera no de*ar l gar para el so de 39P) res lta ' e am#as sol ciones internamente hacen so de t.cnicas m / cercanas a las tilizadas por las herramientas 39P. ;i#ernate por e*emplo) c ando carga n o#*eto desde la #ase de datos) agrega n interceptor para detectar los cam#ios posi#les cam#ios / persistir dichos cam#ios al ,inalizar la sesin. -n el ,ragmento de cdigo de la ,ig ra $$ se "e como la interaccin con la #ase de datos / el mane*o del ciclo de "ida de los o#*etos est en manos de o#*etos denominados (e$ositorios. Dichos repositorios encaps lan la interaccin con alg+n ,rame=orB de persistencia como ;i#ernate / ele"an el ni"el de a#straccin pro"e/endo m.todos con la semntica del dominio. Res miendo) e6isten act almente sol ciones para la persistencia en 3- ' e o,recen n grado acepta#le de mod laridad) haciendo innecesario el so 39P) a n' e ha/ ' e destacar la tilidad de 39P para la implementacin de dichas sol ciones. Un tema m / relacionado a la persistencia es el mane*o de transacciones) pero dada s importancia merece na anlisis partic lar) el c al haremos en la sig iente seccin.
Nicols M. Paez
5! - 110
usin1 "ystem; usin1 >ancoG#Dominio; namespace >ancoG#"ervicios
{
public class "ervicioFran4erencia
public Frans4erencia Frans4erirFondos(strin1 ori1enE strin1 destinoE decimal monto)
i4 (monto N/ () t)ro% +peracionKo7alida,-ception(); <uenta cuenta+ri1en / Hrepositorio<uentas#+btener<uenta(ori1en); <uenta cuentaDestino / Hrepositorio<uentas#+btener<uenta(destino); i4 (cuenta+ri1en // null) t)ro% ne% <uentaKo7alida,-ception(); i4 (cuentaDestino // null) t)ro% ne% <uentaKo7alida,-ception(); >anco banco / ne% >anco(); Frans4erencia trans4erencia / banco#Frans4erirFondos(cuenta+ri1enEcuentaDestinoEmonto); return trans4erencia;
' '
' Figura 22: &anejo de $ersistencia mediante (e$ositorios private *.epositorio<uentas Hrepositorio<uentas;
Transaccionalidad
Problem5tica
(omo mencionamos en el capt lo F)
na transaccin de negocio p ede implicar "arias
transacciones del sistema. Por poner n e*emplo) na trans,erencia de ,ondos de na c enta a otra) representa na transaccin a ni"el negocio) pero representa al menos dos transacciones a ni"el sistema) na por cada c enta implicada en la tras,erencia. -sta di,erencia de grano entre los dos tipos de transacciones) pro"oca ' e la delimitacin / administracin de na transaccin de negocio ad' iera na nat raleza trans"ersal.
Nicols M. Paez
5" - 110
public Frans4erencia Frans4erirFondos(<uenta cuenta+ri1enE <uenta cuentaDestinoE decimal monto)
>anco banco / ne% >anco(); Frans4erencia trans4erencia / null; usin1 (Fransaction"cope scope / ne% Fransaction"cope())
{ trans4erencia / banco#Frans4erirFondos(cuenta+ri1enE cuentaDestinoE monto); Hrepositorio<uentas#5ctuali6ar(cuenta+ri1en); Hrepositorio<uentas#5ctuali6ar(cuentaDestino); scope#<omplete();

'
' return trans4erencia;

Figura 2#: Im$lementacin de una transaccin de negocio
Solucin A P
La rec rrencia de esta pro#lemtica en las 3-) es no de los principales moti"os para el so de ser"idores de componentes / contenedores li"ianos) /a ' e los mismos #rindan soporte declarati"o de transacciones) e"itando as na gran cantidad de cdigo disperso. 3lg nas herramientas como 4pring !rame=orB / ?#oss han implementado el soporte declarati"o de transacciones tilizando 39P) posicionando esta inc m#encia * nto con el monitoreo como las dos inc m#encias ms com+nmente implementadas con 39P en la act alidad.
namespace 5spectos<omunes
public class Fransaccion5dvice 8 *5round5dvise
{
private Fransaction"cope+ption Hscope+ption; public ob;ect *nvoOe(*Iet)od*nvocation invocation)
{
ob;ect resultado / null; usin1(Fransaction"cope scope / ne% Fransaction"cope(Hscope+ption))
{ resultado / invocation#:roceed(); scope#<omplete(); ' ' '

' Figura 2.: +dvice $ara el manejo de transacciones return resultado;
Una ,orma simple de aplicar transaccionalidad con 39P es identi,icando los m.todos transaccionales con ciertas anotaciones / l ego de,inir los poinc ts del aspecto transaccional en #ase a
Nicols M. Paez
60 - 110
dichas anotaciones:.
Naspect name/$Fransaction$L Nadvice type/$5spectos<omunes#Fransaccion5dvice$L Nproperty name/$"cope+ption$ value/$.,PQ*,.,D$ AL NAadviceL Npoincut met)od5nnotation/$Fransaccional$ AL NAaspectL Figura 20: Definicin del as$ecto de manejo de transacciones
-l ,ragmento de cdigo de la ,ig ra $@ aplica el ad"ice Transaccion3d"ice a todos las clases con m.todos ' e contengan la anotacin *ransaccional.
2Fransaccional3 public Frans4erencia Frans4erirFondos(<uenta cuenta+ri1enE <uenta cuentaDestinoE decimal monto)
{
>anco banco / ne% >anco(); Frans4erencia trans4erencia / null;
'
trans4erencia / banco#Frans4erirFondos(cuenta+ri1enE cuentaDestinoE monto); Hrepositorio<uentas#5ctuali6ar(cuenta+ri1en); Hrepositorio<uentas#5ctuali6ar(cuentaDestino); return trans4erencia;

Figura 2/: Im$lementacin de una transaccin de negocio con transaccionalidad declarativa
(aching
Problem5tica
(on el ,in de me*orar el desempe2o de las aplicaciones s ele # scarse minimizar la cantidad de tiempo / rec rsos in"ertidos en la resol cin de cons ltas / realizacin de clc los. Para ello se tilizan estrategias de cach.. 3 di,erencia de otras inc m#encias) el cach. p ede encontrarse en todas las capas de la aplicacin: en la capa de persistencia para minimizar los accesos a la #ase de datosW en la capa de negocio) para e"itar la e*ec cin de alg+n algoritmo / en la capa de presentacin) para e"itar redi# *ar in,ormacin ' e no ha "ariado desde la +ltima cons lta. Pero ms all de en ' . capa se tilice el cach.) la ,orma de tilizarlo es siempre la misma. 4i #ien los ser"idores de aplicaciones s elen #rindar , ncionalidades de cach.) s entremezclado. so tiene ciertas limitaciones / generalmente genera cdigo
: 4i #ien en t.cnologia .N-T las anotaciones son llamadas 3tri# tos) se ha tilizado el t.rmino anotaciones pro"eniente de *a"a) por res ltar ms claro.
public class .epositorio<uentas 8 *.epositorio<uentas
{
public *ListN<uentaL +btener<uentas:or<liente(<liente cliente)
strin1 consulta / $4rom <uenta c %)ere c#<liente#*d/$ 0 cliente#*d; *ListN<uentaL cuentas / <ac)e#Jet(consulta) as *ListN<uentaL; i4 (cuentas // null)
{
cuentas / Iapper#FindN<uentaL(consulta); <ac)e#51re1ar(clienteE valor);
'
return cuentas; ' ' Figura 22: >so t3$ico de Cac'! en la ca$a de $ersistencia
Solucin A P
Dada la claridad de la nat raliza trans"ersal de esta inc m#encia / el #a*o acoplamiento con las partic laridades de cada dominio) res lta m / e"idente la con"eniencia de encaps larla en n aspecto. Una "ez ms / similarmente a lo ' e oc rre con logging) el aspecto de (ach. , ncionar como integrador entre los componentes de la aplicacin / la #i#lioteca de (ach..
{
public class <ac)e5dvice 8 *5round5dvise
public ob;ect *nvoOe(*Iet)od*nvocation invocation)
{
<lave<ac)e clave / ne% <lave<ac)e(invocation#"tatic:artE invocation#5r1uments); ob;ect valor / <ac)e#Jet(clave); i4 (valor // null)
{ '
valor / invocation#:roceed(); <ac)e51re1ar(claveE valor);

return valor; ' ' Figura 25: +dvice Cac'! '
-l ,ragmento de cdigo de la ,ig ra $0 aplica el (ache3d"ice a todas las llamadas m.todos c /o nom#re comience con P9#tenerQ / pertenezcan a clases c /o nom#re comience con PRepositorioQ. 4i #ien el cdigo no lo m estra generalmente tam#i.n s elen de,inirse por con,ig racin los parmetros de , ncionamiento de la #i#lioteca de cach..
Naspect name/$<ac)e$L Nadvice type/$5spectos<omunes#<ac)e5dvice$ AL Npoincut matc)/$call$ class/$.epositorio9$ met)od/$+btener9$ AL NAaspectL Figura 26: +s$ecto Cac'! a$licado a los m!todos -btener de los re$ositorios
9tra t.cnica tilizada para me*orar desempe2o es la carga tard a. -sta t.cnica es m / tilizada por los ,rame=orBs de persistencia para cargar o#*etos desde la #ase de datos) #a*o demanda) e"itando cargar in,ormacin ' e no res lta necesaria. Lo interesante es ' e para la implementacin de esta t.cnica alg nas herramientas tilizan 39P.
Mane*o de e6cepciones
Problem5tica
-l mane*o de e6cepciones es na pro#lemtica presente en toda aplicacin. -n las tecnologas orientadas a o#*etos el mismo s ele hacerse mediante el so de #lo' es tr/IcatchI,inall/ / la cla s la thro=. ( ando na aplicacin est corriendo en n am#iente de prod ccin es importante estar al tanto de la sit aciones e6cepcionales ' e oc rran) lo c al hace imprescindi#le contar n # en mane*o de e6cepciones. -n ,orma general e6isten dos tipos de e6cepciones: las t.cnicas / las del dominio. Las e6cepciones t.cnicas) tienen ' e "er con desper,ectos en la in,raestr ct ra de la aplicacin como ser ,alta de conecti"idad) ,allos en el hard=are) etc. Por s parte las e6cepciones de dominio tienen ' e "er con la "iolacin de alg na regla del dominio. 3 s "ez) el comportamiento de la aplicacin ante estos tipos de e6cepciones es distinto. 3nte e6cepciones t.cnicas es posi#le ' e la aplicacin reintente realizar la operacin ,allida / en caso de no lograrlo seg ramente m estre al s ario n mensa*e del estilo: PLa operacin re' erida no p edo completarse) por ,a"or contacte al ser"icio de a/ da.Q. 3l mismo tiempo) ante e6cepciones de dominio generalmente la aplicacin no reintenta) sino ' e directamente m estra al s ario n mensa*e indicndole la regla ' e ha sido "iolada. Gsicamente podramos decir ' e el mane*o de e6cepciones a#arca F c estiones: la deteccin de las e6cepciones) s p #licacin / ,inalmente s propagacin. La deteccin de la e6cepciones en el caso de las e6cepciones t.cnicas es hecha en ocasiones tilizando t.cnicas como el dise0o por contratos JMe/er0$K. -sta t.cnica) pop larizada por Gertrand Me/er) permite especi,icar la com nicacin entre componentes mediante la de,inicin de contratos los c ales especi,ican las o#ligaciones m t as / los res ltados esperados esperados de la com nicacin. La "eri,icacin de los contratos se hace por medio de aserciones) las c ales son e6presiones lgicas ' e
de#en ser "erdaderas) en caso de ser ,alsas) la asercin ,alla / se genera na e6cepcin. 4eg+n el dise2o por contratos) e6isten F tipos de aserciones: precondiciones) postcondiciones e in"ariantes. 4i #ien esta t.cnica #ene,icia la calidad / el re so) a ni"el de implementacin) el cdigo ' eda minado de aserciones) o de llamadas a ,rame=orBs de dise2o por contratos como (ontract>? Jcontract>*K. -n c anto a la p #licacin / propagacin de las e6cepciones) son comportamientos ' e se codi,ican dentro de los #lo' es catc') pero p ede oc rrir ' e ante na misma e6cepcin) dependiendo del conte6to en ' e oc rra) las acciones de p #licacin / propagacin a e*ec tar sean distintas) de manera tal ' e p eda no ha#er dos #lo' es catc' ig ales. De esta ,orma en los #lo' es tr/ se codi,ica el comportamiento normal de la aplicacin) mientras ' e en los #lo' es catch) se codi,ican los distintos comportamientos e6cepcionales. (omo consec encia de esto) oc rre ' e dentro de n mismo m.todo nos encontremos con al menos $ comportamientos Cel normal / el e6cepcionalD. -l ,ragmento de cdigo de la ,ig ra F% m estra m estra en el mane*o de na e6cepcin / la "eri,icacin de dos precondiciones del m.todo *ransferirFondos.
public Frans4erencia Frans4erirFondos(<uenta cuenta+ri1enE <uenta cuentaDestinoE decimal monto)
i4 (cuenta+ri1en // null) t)ro% ne% <uentaKo7alida,-ception(); i4 (cuentaDestino // null) t)ro% ne% <uentaKo7alida,-ception(); i4 (@cuenta+ri1en#Ioneda#,Buals(cuentaDestino#Ioneda)) t)ro% ne% +peracionKo7alida,-ception($Ionedas distintas$); try
{ cuenta+ri1en#Debitar(monto); cuentaDestino#5creditar(monto);
Frans4erencia trans4erencia / ne% Frans4erencia(cuenta+ri1enE cuentaDestinoE monto);
Hrepositorio+peraciones#.e1istrar+peracion(trans4erencia); ' catc) (,-ception e) { Lo11er#,rror($,rror al trans4erir 4ondos$E e-); t)ro% ne% +peracionFallida,-ception(e-); ' return trans4erencia;
' Figura #8: &anejo de e)ce$ciones
Solucin A P
-6isten alg nos tra#a*os ' e han tratado el mane*o de e6cepciones con 39P. -n partic lar ha/ n tra#a*o realizado por (ristina Lopes / Martin Lipper JLopes%%K) ' ienes tomando como caso de est dio n ,rame=orB para el desarrollo de aplicaciones de negocio) lograron red cir nota#lemente la cantidad de #lo' es catch) tilizando 39P para mane*ar los cinco tipos de e6cepciones ms re,erenciados en #lo' es catch. -sto res lt en na red ccin de > "eces la cantidad de cdigo
Figura #1: +dvices $ara integracin de bibliotecas de dise?o $or contratos
relacionado al mane*o de e6cepciones. -n lo ' e hace a la deteccin de e6cepciones) res lta #ene,icioso tilizar la t.cnica de dise2o por contratos) lo ' e ha moti"ado alg nas prop estas para implementar dicha t.cnica tilizando 39P JDiotale"i%>K. 8ncl so la #i#lioteca de aspectos de 3spect? trae n con* nto de aspectos ' e #rindan soporte para esta t.cnica. La ,ig ra F< m estra n posi#le dise2o para ,acilitar el so de #i#liotecas de dise2o por contrato mediante el so de 39P.
{
public class 5r1KoKulo5dvice 8 :recondicion
{ ' '
'
public void >e4ore("ystem#.e4lection#Iet)od*n4o met)odE ob;ect23 ar1sE ob;ect tar1et) 5dministradorDe<ontractos#5se1urarKoKulos(ar1s);
Figura #2: +dvice verificador de $recondicin de argumentos no nulos
-l cdigo de la ,ig ra FF m estra la con,ig racin del ad"ice ' e "eri,ica arg mentos no n los) indicando ' e dicho ad"ice se apli' e a todos los m.todos ' e reci#an como arg mento na instancia de la clase Cuenta o descendientes.
Nicols M. Paez
65 - 110
Naspect name/$5r1umentoKoKulo5dvice$L Nadvice type/$5spectos<omunes#5r1KoKulo5dvice$ AL Npoincut ar1s/$<uenta0$ AL NAaspectL Figura ##: +$licacin del advice verificador de argumentos no nulos a todos los join$oint :ue reciben como argumento objetos Cuenta
-n c anto a la p #licacin / propagacin de las e6cepciones) "arias herramientas 39P #rindan en s s #i#liotecas aspectos para el mane*o de estas pro#lemticas.
Nob;ect name/$e-ceptionRandlin15dvice$ type/$"prin1#5spects#,-ceptions#,-ceptionRandler5dviceE "prin1#5op$L Nproperty name/$e-ceptionRandlers$L NlistL NvalueLon 5rit)metic,-ception %rap "ystem#*nvalid+peration,-ceptionNAvalueL NAlistL NApropertyL NAob;ectL Figura #.: Configuracin del advice de manejo de e)ce$ciones de 7$ring
-n partic lar el soporte de mane*o de e6cepciones #rindado por 4pring res lta m / interesante. 4pring #rinda n 3d"ice para el mane*o de e6cepciones / n leng a*e espec,ico para especi,icar el comportamiento de dicho ad"ice en ,orma declarati"a) pero si #ien esto res lta m / interesante ha/ ' e mencionar ' e no es posi#le de,inir los pointc ts so#re los ' e se pretende ' e act . el ad"ice) /a ' e el mismo aplica a tomticamente so#re todos los o#*etos a los ' e 4pring les ha agregado aspectos.
3 tenticacin / a torizacin
Problem5tica
-stos dos pro#lemticas relacionadas a la seg ridad de las aplicaciones) estn m / relacionadas entre s) /a ' e para permitir el so Ca torizacinD de cierta , ncionalidad)primero se de#e identi,icar ' ien es el s ario Ca tenticacinD ' e pretende hacer so de la misma. 3l mismo tiempo estas pro#lemticas estn presentes en todas las capas de la aplicacin) pero en partic lar en la capa de presentacin) /a ' e es el p nto de acceso a la , ncionalidad de la aplicacin. 3simismo estas inc m#encias determinan en gran medida las "istas a las ' e el s ario podr acceder. 5eneralmente) el s ario presenta s credenciales en alg na "ista de la aplicacin) ' e se encarga de a tenticarlo tilizando n componente espec,ico. L ego de ello la plata,orma de e*ec cin se encarga de crear n conte6to de e*ec cin conteniendo la identidad del s ario / e"itando ' e este de#a a tenticarse constantemente. -sta es mod larizacin. na sol cin acepta#le desde el p nto de "ista de la
Nicols M. Paez
66 - 110
Por otro lado) la implementacin de la a torizacin s ele ser m cho ms tra#a*osa) por' e si #ien los permisos ' e tiene el s ario s elen almacenarse en el conte6to de e*ec cin * nto con la identidad del mismo) dichos permisos de#en ser constantemente cons ltados por cada accin ' e el s ario realiza en la aplicacin) lo ' e prod ce los mencionados ,enmenos de cdigo disperso / entremezclado.
public *ListN<uentaL +btener<uentas(strin1 numero<liente)
{
i4 (@F)read#<urrent:rincipal#*s*n.ole($Q"Q5.*+HR+I,>5KS*KJ$))
'
' return t)is#Hrepositorio<uentas#+btener<uentas:or<liente(numero<liente); Figura #0: verificacin de $ermisos $ara realizar una consulta de cuentas
t)ro% ne% Qnaut)ori6ed5ccess,-ception($:rivile1ios insu4icientes# Q"Q5.*+HR+I,>5KS*KJ reBuerido$);
4i #ien las tecnologas act ales #rindan mecanismos declarati"os de a torizacin) oc rre ' e generalmente los mismos son de grano gr eso / centrados en la capa de presentacin o de ser"icios.
Solucin A P
-sta inc m#encia es otra de las ' e se enc entra en el Top @ de las inc m#encias implementadas con 39P. -l tema es a#ordado de ,orma interesante en JLaddad%FK / tam#i.n ha/ implementaciones con n importante grado de adopcin como ser el ,rame=orB 3(-58 JacegiK #asado en 4pring.
Nicols M. Paez
6 - 110
{
public class 5utT5dvice 8 *>e4ore5dvice
public void >e4ore(Iet)od*n4o met)odE ob;ect23 ar1sE ob;ect tar1et)
{
strin1 permiso / Jet:ermiso(met)od); i4 (@strin1#*sKull+r,mpty(permiso))
{
i4 (@F)read#<urrent:rincipal#*s*n.ole(permiso))
' ' '
Lo11er#*n4o($*ntento de acceso no autori6ado$ 0 met)od#Declarin1Fype#Kame 0 met)od#Kame); t)ro% ne% Qnaut)ori6ed5ccess,-ception($:rivile1ios insu4icientes#$ 0 permiso 0 $reBuerido#$);
protected strin1 Jet:ermiso(Iet)od*n4o met)od){###' ' Figura #/: fragmento de cdigo de un advice de autorizacin
(on 39P la implementacin de la a torizacin p ede red cirse a la de,inicin de
Ge,ore3d"ice) ' e tomando ciertos parmetros de con,ig racin) se encarg e de "eri,icar los permisos. -l cdigo de la ,ig ra F& aplica el ad"ice +ut@+dvice a todas las clases del componente BancoA"7ervicios / al mismo tiempo de,ine ' e para e*ec tar el m.todo -btenerCuentas de la clase 7ervicioBomeBan4ing es necesario contar con el permiso U4U3R89Y;9M-G3NR8N5.
Naspect name/$5utori6acion$L Nadvice type/$5spectos<omunes#5utT5dvice$L Nproperty name/$:ermisos$L Nitem name/$"ervicioRome>anOin1#+btener<uentas()$ value/$Q"Q5.*+HR+I,>5KS*KJ$AL NApropertyL NAadviceL Npoincut assembly/$>ancoG#"ervicios$AL NAaspectL Figura #2: a$licacin de advice de autorizacin a las clases de servicio del BancoA
-n lo ' e a tenticacin respecta) podra aplicarse na estrategia anloga a la mostrada) pero en general las tecnologas act ales #rindan sol ciones acepta#les desde el p nto de "ista de la mod larizacin haciendo ' e no "alga la pena el desarrollo de sol ciones #asadas en 39P.
Distri# cin) conc rrencia / sincronizacin

Problem5tica
-n ocasiones las 3- se e*ec tan distri# idas /a sea por ' e el negocio se enc entra distri# ido o #ien por razones t.cnicas como alta disponi#ilidad / escala#ilidad. -6isten en la act alidad "arias
tecnologas de distri# cin ' e "an desde (or#a hasta We# ser"icios pasando RM8 / N-T Remoting. -l so de ar' itect ra lgicas en capas permite ' e las mismas sean distri# idas ,sicamente en distintos nodos. 5eneralmente la distri# cin ,sica pone a la capa de presentacin en el rol de cliente / a la capa de negocio el rol de ser"idor. La capa ser"idor se encarga de mane*ar los pedidos de la capa cliente) creando n hilo de e*ec cin por cada pedido) generando sit aciones de conc rrencia. -s crtico para las 3- garantizar ' e el acceso conc rrente a los datos no genere inconsistencia en los mismos. Uno de los mecanismos ms com nes para el mane*o de sit aciones conc rrentes en las 3-) son las transacciones / ' e como /a se "io) res lta con"eniente el so de 39P para s implementacin. 3l mismo tiempo res lta ' e no todas la sit aciones conc rrentes p eden mane*arse con transacciones / por ello es necesario tilizar los mecanismos de sincronizacin para garantizar ' e n dato no sea modi,icado por ms de n hilo de e*ec cin al mismo tiempo. 4i #ien en ocasiones es posi#le mane*ar estas sit aciones directamente en la #ase de datos) en otros casos) las mismas de#en mane*arse en la capa de negocio) tilizando sem,oros / dems arte,actos tpicos de programacin conc rrente o #ien haciendo so de las herramientas espec,icas de cada leng a*e. Por e*emplo en ?a"a es posi#le tilizar el modi,icador s1ncronized en la declaracin de m.todos) e"itando la e*ec cin conc rrente del mismo. Por s parte .N-T permite de,inir #lo' es de e6cl sin m t a mediante el so de la cl s la loc4) tal como lo m estra la ,ig ra F:.
public override void Debitar(decimal monto)
{
i4 (monto L t)is#"aldo) t)ro% ne% "aldo*nsu4iciente,-ception(t)is#"aldoE monto); locO (t)is)
{ '
t)is#"aldo M/ monto;
' '
Figura #5: sincronizacin de la modificacin de saldo
Solucin A P
-n primer l gar ha/ ' e destacar ' e si #ien la pro#lemtica de distri# cin ha sido planteada como n aspecto en alg nos tra#a*os) en el caso partic lar de las 3- dicha pro#lemtica se ha res elto de ,orma acepta#le Cen lo ' e a mod larizacin respectaD mediante el so de los mecanismos nati"os de las tecnologas enterprise / ciertos patrones de dise2o. Una sit acin similar oc rre con la conc rrencia /a ' e tanto los ser"idores de aplicaciones como motores de #ase de datos se encargan se mane*ar pedidos conc rrentes creando distintos hilos de e*ec cin para cada no.
-n c ando a la sincronizacin) la sit acin es distinta) /a ' e el
so de los arte,actos
caractersticos de programacin conc rrente genera m cho cdigo disperso dando l gar al so de 39P tal como se ha planteado en di"ersos tra#a*os. Por e*emplo en J-rdod/%AK se plantea n con* nto de patrones implementados con 3spect?) mientras ' e en JNilsson%AK se propone na interesante sol cin #asada en 4pring.39P. -l ,ragmento de cdigo de la ,ig ra F0 m estra n ad"ice para el mane*o de secciones de e6cl sin en tecnologa .N-T.
{
public class "ync5dvice 8 *5round5dvise
public ob;ect *nvoOe(*Iet)od*nvocation invocation)
{
ob;ect resultado; locO(invocation#Far1et)
{ resultado / invocation#:roceed(); ' return resultado;
' '
'
Figura #6: +dvice de sincronizacin
La ,ig ra >% m estra como aplicar el ad"ice de sincronizacin a todos los m.todos de la clase Cuenta ' e tengan la anotacin 71nc"
Naspect name/$"incroni6ador$L Nadvice type/$5spectos<omunes#"ync5dvice$ AL Npoincut class/$<uenta$ met)od5nnotation/$"ync$ AL NAaspectL Figura .8: +$licacin del advice de sincronizacin a los m!todos con anotacin 71nc
9tras inc m#encias

4i no compara las inc m#encias tratadas en este capt lo con las tratadas en el capt lo F) a simple "ista enc entra ' e ms de na inc m#encia no ha sido tratada. -sto se de#e a ' e "arias de las inc m#encias relacionadas a atri# tos de calidad no se trad cen directamente a cdigo sino ' e se "en re,le*adas en el dise2o de la aplicacin. Por e*emplo) el hecho de ha#er planteado na ar' itect ra en capas ,acilita la manteni#ilidad / escala#ilidad de la aplicacin. 3l mismo tiempo oc rre ' e alg nas inc m#encias cali,icadas com+nmente como trans"ersales) no lo son en el caso de las aplicaciones enterprise Cla persistencia por e*emploD) o no "ale la pena modelarlas con 39P) /a sea por ' e dichas inc m#encias tienen n impacto menor o #ien por' e
Nicols M. Paez
0 - 110
modelarlas con 39P podra res ltar m / di,ic ltoso. Dos inc m#encias con las ' e se da esta sit acin son la encriptacin / la lgica de reintentos. 4i #ien la lgica de reintentos p ede considerarse na inc m#encia trans"ersal res lta ' e en las 3- es la in,raestr ct ra la ' e se encarga de la misma) de ,orma transparente para el programador. -n c anto a la encriptacin) la misma se s ele tilizar principalmente a la hora de transmitir in,ormacin con,idencial / res lta ' e na "ez ms es la in,raestr ct ra la ' e se encarga de esta inc m#encia a partir de seteos de con,ig racin.
Res miendo...
3 lo largo de este capt lo hemos analizado distintas inc m#encias t.cnicas de las 3-) la ma/ora de las c ales res lta con"eniente implementarlas con aspectos. Los aspectos res ltantes act+an en la ma/ora de los casos como integradores de #i#liotecas. 3l mismo tiempo el hecho de ha#er planteado la implementacin de estos aspectos con na herramienta 39P de entrete*ido dinmico hace ' e los mismos p edan ser re tilizados en distintas aplicaciones con el mnimo es, erzo de de,inir los pointc ts en el archi"o de con,ig racin / sin necesidad de tocar el cdigo , ente.
Nicols M. Paez
1 - 110
(apt lo E8: 8nc m#encias del negocio

(onsideraciones preliminares
El dominio / la l$ica de ne$ocio
;a#iendo analizado las inc m#encias t.cnicas) ' e en cierta ,orma podramos llamar sec ndarias) es hora de analizar las inc m#encias del negocio) ' e si #ien son la parte distinti"a / ms comple*a de las aplicaciones enterprise) no es com+n ' e se las modele como aspectos. 5eneralmente en las inc m#encias de negocio de las aplicaciones enterprise p ede disting irse:
Lgica del dominio) la c al es com+n a todas las aplicaciones centradas en el dominio en c estin. -sta lgica est constit ida por los conceptos centrales del dominio. 4i tomamos el dominio #ancario) nos encontraremos con conceptos como c enta) cliente / transaccin.
Lgica del negocio) la c al es propia de cada aplicacin / est constit ida por reglas del negocio partic lares de cada organizacin. 4ig iendo dentro del dominio #ancario) podremos encontrarnos con reglas partic lares del Ganco H como: Ptodas las transacciones ' e s peren cierto monto de#en ser a torizadas por la casa centralQ.
Mientras ' e la lgica del dominio s ele ser Crelati"amenteD esta#le) las reglas del negocio s elen ser ms "oltiles. 3l mismo tiempo estas reglas s elen a,ectar a "arias entidades del dominio) lo c al di,ic lta s modelado. Las inc m#encias del dominio se modelan en la capa de dominio logrando n # en ni"el de mod larizacin con el so de 99. Por s parte las reglas del negocio s elen ser ms di,ciles de modelar) lo c al ha dado l gar a di,erentes estrategias. 4i las reglas son simples) se las s ele mane*ar en la capa de dominio) modelndolas con o#*etos del dominio. -n el caso de reglas ms comple*as 0) es com+n mo"erlas a la capa de ser"icios) o #ien tilizar motores de reglas. Todas estas estrategias para modelar las reglas del negocio tienen en ma/or o menor medida cierta nat raleza trans"ersal) lo c al genera na oport nidad para el so de 39P.
1mplementacin de aspectos del ne$ocio
3 di,erencia de los aspectos tratados en el capit lo anterior) a los aspectos del negocio res lta con"eniente implementarlos tilizando herramientas 39P de entrete*ido esttico ' e act+en a ni"el de cdigo , ente Co cdigo de m' ina "irt alD como compiladores) pre procesadores / pos compiladores)
0 -nti.ndase reglas comple*as a a' ellas ' e in"ol cran a "arios o#*etos del dominio e interacciones con aplicaciones remotas
/a ' e las modi,icaciones en el negocio no se Papagan / prendenQ d rante la e*ec cin de la aplicacin) sino ' e de#en estar siempre presentes. 3l mismo tiempo si se tilizara na herramienta 39P #asada en pro6ies dinmicos) se podra llegar a correr el riesgo de ' e por n desc ido de con,ig racin) se modi,icara lgica de la aplicacin. 3dicionalmente) desde n p nto de "ista de componentes) tanto los aspectos del negocio como las clases) podran con"i"ir en na misma nidad. Dado ' e las inc m#encias de negocio dependen de cada aplicacin) para el desarrollo de este capt lo tomaremos na aplicacin de e*emplo) so#re la ' e plantearemos ciertas pro#lemticas trans"ersales) ' e na "ez analizadas) intentaremos modelar como aspectos. 3 lo largo de este capt lo) pasaremos por alto todas las inc m#encias ' e no ,ormen parte de la lgica de negocio) /a ' e las hemos tratado en el capt lo anterior / al mismo tiempo nos distraeran del o#*eti"o de este capt lo: analizar las inc m#encias del negocio. -l e*emplo ' e tilizaremos a lo largo de este capt lo es el de na aplicacin de #anca
electrnica personal ' e /a ha sido mencionada en capt los anteriores.
(aso de est dio: Ganco H

-sta hipot.tica aplicacin permite a los clientes de n ,icticio Ganco H) cons ltar el saldo de s s c entas / realizar mo"imientos de ,ondos entre c entas. (omo es de esperar) para poder acceder a estas , ncionalidades es necesario ' e el s ario inicie na sesin identi,icndose con s DN8 / s cla"e personal.
Figura .1: Funcionalidades ofrecidas v3a %eb $or el Banco A a sus clientes
-l diagrama de la ,ig ra >$ m estra las clases de la capa de dominio del Ganco H. 3 simple "ista parece ' e todas las inc m#encias han sido ,elizmente mod larizadas) lo c al es #astante predeci#le dado ' e todos los conceptos del dominio pertenecen a la dimensin dominante del pro#lema. La ,ig ra >F m estra n escenario simpli,icado de trans,erencia de ,ondos) partiendo desde la capa de ser"icios / considerando la ar' itect ra #ase descripta en el capt lo >. Decimos ' e este
escenario es simpli,icado por no tener en c enta la interaccin con los ser"icios de in,raestr ct ra como ser transacciones / a ditoria) dos inc m#encias in,alta#les en toda aplicacin #ancaria.
Figura .2: clases del dominio del Banco A
Figura .#: Escenario de transferencia de fondos
8nc m#encias trans"ersales en el negocio del GancoH

;a#iendo e6p esto la , ncionalidad #sica del dominio) ' eda a la "ista ' e el dominio podra per,ectamente ser re tilizado por c al' ier aplicacin de #anca electrnica. 3hora es momento de centrarnos en las partic laridades del negocio del Ganco H. Para ello intentaremos modelar las sig ientes dos reglas de negocio espec,icas de dicho #anco. <. No de#e ser posi#le realizar d.#itos de c entas c /o tit lar tenga de das con la 3!8P. $. Todas las operaciones ' e s peren cierto monto) de#en ser in,ormadas al Ganco (entral de la Rep+#lica 3rgentina. 3l intentar modelar estas reglas se plantean las sig ientes c estiones.

No res lta e"idente ' . o#*eto del dominio de#era tomar estas responsa#ilidades. -stas reglas son espec,icas del Ganco H / no del dominio #ancario. -stas reglas son m cho ms "oltiles ' e las reglas del dominio) / como tales) es m cho ms pro#a#le ' e s ,ran modi,icaciones.
De intentar modelar estas reglas en la capa de dominio) de#eramos decidir ' e o#*eto de#era tomar s responsa#ilidad. Una opcin sera asignar la responsa#ilidad a alg no de los o#*etos e6istentes) pero ello signi,icara "iolar el principio de responsa#ilidad +nica. Una alternati"a distinta podra ser agregar n e"os o#*etos ' e tomaran e6cl si"amente estas n e"as responsa#ilidades) pero en ese caso las llamadas a estos o#*etos se esparciran por el todo el cdigo de la aplicacin) di,ic ltando la e"ol cin de la aplicacin / restando claridad al cdigo.
{
public override void Debitar(decimal monto)
i4 (monto L "aldo) t)ro% ne% "aldo*nsu4iciente,-ception(t)is#"aldoE monto); i4 (>anco#Jet:ro-y54ip()#FieneDeuda(t)is)) t)ro% ne% +peracionFallida,-ception($<uenta con deudas de 54ip$);
"aldo M/ monto; '

' Figura ..: regla 1 im$lementada en la clase CajaDe+'orro" El mismo fragmento de cdigo deber3a agregarse a los otros ti$os de cuenta
9tra alternati"a sera modelar estas reglas en la capa de ser"icios) lo c al es concept almente m / disc ti#le. 3l mismo tiempo) aseg rar ' e estas reglas sean "eri,icadas en cada interaccin de o#*etos del dominio) podra generar cdigo disperso / alto acoplamiento) dos ,enmenos no deseados. -sta +ltima sit acin tam#i.n oc rrira en caso de modelar estas reglas con n motor de reglas. Para el caso partic lar de la regla $) na sol cin ha#it al es el so del patrn -bserver) pero el
so de dicho patrn tiene las sig ientes consec encias.
-l o#*eto o#ser"ado Cen este caso la trans,erenciaD de#e reci#ir na re,erencia al o#*eto o#ser"ador Cen este caso el Ganco(entralD.
(ada "ez ' e ha/ n cam#io de estado) el o#*eto o#ser"ado de#e noti,icar a todos los o#ser"adores) esto o#liga a ' e el cdigo de noti,icacin sea in"ocado desde m+ltiples l gares del o#*eto o#ser"ado.
-l o#*eto o#ser"ador) se s scri#e al o#*eto o#ser"a#le / no a e"entos espec,icos) lo c al res lta na complicacin c ando n o#*eto o#ser"a#le tiene ms de n e"ento interesante so#re el c al noti,icar.
public class Frans4erencia 8 +peracion
{
public void ,;ecutar()
t)is#Fec)aRora / DateFime#Ko%;
+ri1en#Debitar(Ionto); Destino#5creditar(Ionto);
:ro-y>anco<entral pro-y>anco<entral / >anco#Jet:ro-y>anco<entral(); i4 (Ionto L pro-y>anco<entral#IontoLimite) pro-y>anco<entral#Koti4icarFrans4erencia(t)is);
' '
Figura .0: Im$lementacin de la regla 2 en la clase *ransferencia
;a#iendo analizado estas sit aciones) encontramos ' e ning na de las alternati"as o,rece na # ena mod larizacin. Eeamos entonces si con 39P podemos me*orar la sit acin. Respecto de la regla <) podramos incl irla en na inc m#encia PReg laciones de 3,ipQ) la c al claramente c enta con na nat raleza trans"ersal. Para atacar esta inc m#encia modelaremos na aspecto llamado (egulaciones+fi$ / ' e en n principio contar con n solo ad"ice) de tipo #e,ore) encargado de la "alidacin de la regla <.
aspect .e1ulaciones5F*:
pointcut debitos(<uenta>ancaria c)8 tar1et(c) ?? call (Debitar); be4ore debitos(<uenta>ancaria c) { i4 (>anco#Jet:ro-y54ip()#FieneDeuda(c)) t)ro% ne% +peracionFallida,-ception($<uenta con deudas de 54ip$);
'
'
Figura ./: Im$lementacin +-P de la regla 1
Por s parte) respecto de la regla $) aplicando na razonamiento anlogo) podramos plantear n

aspecto encargado de concentrar las reglas imp estas por el Ganco (entral / agregar al mismo n a,terad"ice ' e tome a s cargo la noti,icacin al Ganco (entral. -l diagrama de la ,ig ra >: m estra na sol cin 39P para la implementacin de las reglas < / $. (omo p ede apreciarse) la e6istencia de los aspectos para las clases es totalmente transparente) pero no al re".s) cosa ' e ha sido disc tida por alg nos. ;a/ a tores ' e arg mentan ' e para lograr na real separacin de inc m#encias) los aspectos tam#i.n de#en ser independientes de las clases so#re las ' e act+an.
aspect .e1ulaciones><.5
{
pointcut trans4erencias(Frans4erencia t)8 tar1et(t) ?? call (,;ecutar); a4ter trans4erencias(Frans4erencia t) { i4 (t#Ionto L >anco#Jet:ro-y>anco<entral()#IontoLimite) pro-y>anco<entral#Koti4icarFrans4erencia(t);
' '
Figura .2: Im$lementacin +-P de la regla 2
Un hecho ' e se desprende del diagrama de la ,ig ra >: / ' e p ede res ltar llamati"o es ' e el aspecto (egulacionesBC(+ aplica slo so#re la clase *ransferencia" 3nte esto alg ien podra tentarse de eliminar el aspecto / mo"er la lgica directamente a la clase *ransferencia. -sta estrategia no sera con"eniente por "arios moti"os.
La regla del Ganco (entral aplica so#re todas las operaciones) no solo las trans,erencia / si #ien en el dominio planteado solo ha/ trans,erencias) nada ' ita ' e p edan agregarse otros tipos de operaciones) lo c al nos lle"ara a replicar el cdigo de la regla en la n e"a clase de operacin. -n el caso de la sol cin 39P) ante esta misma sit acin de e"ol cin planteada) a lo s mo ha#ra ' e modi,icar n pointc t del aspecto.
La decisin de delegar la responsa#ilidad de la regla en dominio #ancario.
n aspecto est moti"ada
principalmente por' e se trata de na regla espec,ica del negocio del Ganco H / no del
Nicols M. Paez
- 110
Figura .5: solucin con as$ectos
5eneralizando las reglas de negocio

-le"ando n poco el ni"el de a#straccin) podemos clasi,icar las reglas de negocio "istas en dos gr pos m / gen.ricos.
Ealidaciones) ' e act+an como pre condiciones) modi,icando el ,l *o de e*ec cin. 3 ni"el cdigo , ente rememoran la pro#lemtica del dise2o por contratos tratada en el capt lo anterior / al ig al ' e ese caso) 39P res lta na e6celente alternati"a de implementacin. La regla < pertenece claramente a este gr po.
Noti,icaciones) ' e act+an como disparadores de otras reglas del negocio) p diendo incl so coordinar la interaccin entre ciertos o#*etos de negocio / aplicaciones e6ternas. 4i #ien en ocasiones se implementan tilizando patrones como -bservador) generalmente 39P constit /e na me*or alternati"a. Dentro de este gr po se enc entra la regla $.
9#"iamente) esta clasi,icacin es e6tremadamente gen.rica) pero * stamente nos da na idea del tipo de reglas de negocio ' e p eden implementarse con 39P.
-l rol de los aspectos

-n las sol ciones pre"iamente planteadas) los aspectos son los encargados de modelar cierta
Nicols M. Paez
! - 110
lgica del negocio. Un en,o' e di,erente sera plantear a los aspectos como simples coordinadores) a#stra/endolos del negocio / de*ando en manos de otros o#*etos la aplicacin de la lgica de negocio correspondiente. 4ig iendo este +ltimo criterio) otra posi#le sol cin para la regla $) sera tilizar la "ersin 39P del patrn -bservador) delegando en n aspecto) la administracin de los o#ser"adores / la noti,icacin de cam#ios de estado. De esta ,orma) la clase *ransaccin permanecera inalterada) el aspecto de#era noti,icar al o#*eto Pro)1BancoCentral de c al' ier transaccin / ,inalmente dicho o#*eto de#era disting ir las transacciones de s correspondiera. -sta estrategia de so de aspectos) es similar a la planteada en el capt lo anterior) donde los aspectos act+an como simples coordinadores ' e se encargan de detectar p ntos interesantes en la e*ec cin de la aplicacin / delegan las decisiones en otros o#*etos. Pasando en limpio) podemos decir ' e a la hora de dise2ar n aplicacin con 39P) los aspectos p eden * gar dos roles.
inter.s / noti,icar al Ganco (entral c ando
Aspectos coordinadores o integradores: los aspectos son tilizados como na herramienta para integrar inc m#encias trans"ersales ' e son modeladas por clases. -stos aspectos en la ma/ora de los casos slo tienen pointc ts / ad"ices. Los ad"ices slo tienen na lgica limitada para delegar el tra#a*o en las clases ' e modelan las inc m#encias de la aplicacin.
Aspectos inteligentes: los aspectos son tilizados para modelar inc m#encias trans"ersales) /a sean de negocio o t.cnicas. 3dems de los pointc ts / ad"ices) los aspectos tienen m.todos / atri# tos relacionados a las inc m#encias ' e modelan. (ada ad"ice del aspecto tiene lgica de la inc m#encia ' e modela el aspecto.
La decisin de ' e estrategia tilizar depende principalmente del tipo de la inc m#encia a modelar. 5eneralmente al modelar inc m#encias t.cnicas se tilizan los aspectos como integradores de in,raestr ct ra. Por s parte) al modelar inc m#encias del negocio) el criterio no es tan claro. Por e*emplo) al modelar reglas de negocio tilizando n motor de reglas) los aspectos tendrn n rol de integradores. Pero de no tilizar n motor de reglas) tendremos ' e analizar de ' e tipo de regla se trate. Lle"ando esta disc sin a otro plano) podramos decir ' e el so de herramientas 39P de entrete*ido dinmico predispone al so de aspectos coordinadores) mientras ' e las herramientas de entrete*ido esttico son ms a,ines a los aspectos inteligentes.
Nicols M. Paez
" - 110
Res miendo...
Toda 3- tiene reglas partic lares ' e m chas "eces s elen implementarse directamente en la capa de dominio) lo c al en ocasiones p ede , ncionar #ien) pero a cam#io le ' itan claridad al dominio / restan ,le6i#ilidad a dichas reglas) /a ' e las reglas s elen ser m cho ms "oltiles ' e la lgica del dominio. -l modelar dichas reglas con aspectos p ede a/ dar a lograr na me*or separacin de inc m#encias #rindando na ma/or ,le6i#ilidad a dichas reglas / e"itando la d plicacin de cdigo. Las reglas candidatas a modelarse como aspectos) son a' ellas ' e implican la e*ec cin de alg na lgica adicional o sec ndaria desde el p nto de "ista del dominio. (omo /a ha sido mencionado por alg nos a tores) la tilizacin de aspectos para modelar inc m#encias del negocio) re' iere ciertas modi,icaciones en las acti"idades del proceso de desarrollo.
Nicols M. Paez
!0 - 110
(apit lo E88: La ,oto completa

-n los dos capt los anteriores "imos como implementar las inc m#encias trans"ersales de las 3- tilizando 39P. -n el presente capt lo) "eremos la ,oto completa del so de 39P en las -3) e6poniendo n caso de est dio so#re la plata,orma .N-T. Para c mplir con este cometido comenzaremos presentado na ar' itect ra enterprise 39PIcompati#le para la plata,orma .N-T. L ego) tomando na "ez ms el e*emplo del Ganco H) plantearemos na sol cin tradicional / otra #asada en 39P / analizaremos s s di,erencias.
3r' itect ra -nterprise 39PI(ompati#le

-n este p nto no hemos de in"entar la r eda n e"amente) /a ' e la ar' itect ra #ase descripta en el capt lo > representa n # en p nto de partida. Por ello) simplemente realizaremos alg nas modi,icaciones de cara a ,acilitar la incl sin de aspectos.
Figura .6: ar:uitectura ente$rise +-PCCom$atible
La ,ig ra >0 m estra la ar' itect ra 39P prop esta) ' e a di,erencia de la ar' itect ra #ase del
Nicols M. Paez
!1 - 110
capt lo >) slo tiene n componente adicional) el !rameo=orB 8o(<% S 39P. Dicho componente) ademas de ,acilitar la resol cin de dependencias a partir de la t.cnica de in"ersin de control) permite integrar transparentemente las #i#liotecas / , ncionalidades de la in,raestr ct ra a partir de s s posi#ilidades 39P.
Figura 08: (elaciones entre clases 1 as$ectos de la ar:uitectura base
3lg nos p ntos a tener en c enta so#re esta ar' itect ra son lo sig ientes.
Tal como est planteada) esta ar' itect ra as me ' e la todas las capas corren en n mismo proceso. De ser necesario distri# ir la capas en distintos procesos sera necesario hacer alg nos a* stes.
4lo la capa de presentacin tiene conocimiento e6plcito de !rame=orB 8o(. 4i #ien se ha tomado como #ase la plata,orma .N-T esta ar' itect ra aplica per,ectamente a ?a"a.
4i #ien la aplicacin a desarrollar tiene na presentacin =e#) la ar' itect ra tam#i.n aplica para el caso de na presentacin de escritorio.
Herramientas A P seleccionadas
(omo lo hemos planteado a lo largo de esta tesis) para implementar na aplicacin #asada en esta
<% 8o(: in"ersion o, control
Nicols M. Paez !2 - 110
ar' itect ra de re,erencia son necesarias $ herramientas 39P) na de entrete*ido dinmico) #asada en pro6ies dinmicos Cpara implementar las inc m#encias t.cnicasD / otra de entrete*ido esttico. 3ntes de entrar en detalle so#re las herramientas elegidas) es necesario destacar ' e el o#*eti"o de este tra#a*o est centrado la tilizacin del paradigma 39P / no en las herramientas 39P. -sta aclaracin es m / necesaria /a ' e en la act alidad e6iste cierta distancia entre lo prop esto por el paradigma / lo ' e o,recen alg nas herramientas. -s en parte por ello ' e todo lo e6p esto hasta el momento) , e presentado tilizando na notacin gen.rica de na herramienta 39P ,icticia. -n c anto a la herramienta de entrete*ido dinmico) se ha optado por 4pring 39P) de#ido principalmente a s amplio soporte al paradigma 39P / a s #i#lioteca de aspectos) a n' e ha/ alg nos otros hechos interesantes para destacar como por e*emplo s esta#ilidad / s orientacin a las aplicaciones enterprise. -n c anto a la herramienta de entrete*ido esttico) la c estin es ms comple*a) /a ' e este tipo de herramientas son ms escasas. -n el caso de .N-T oc rre ' e "arios de los pro/ectos relacionados a herramientas de este tipo) han sido a#andonados o a+n no c entan con "ersiones esta#les. -sta sit acin ha acotado el espectro de e"al acin a seleccionada 3spect.N-T. 4i #ien 3spect.N-T no implementa la totalidad del paradigma 39P Ccarece de declaraciones de intertipos entre otras cosasD) o,rece na serie de caractersticas m / interesantes ' e la #ican por encima de las dems herramientas de s tipo. -ntre estas caractersticas ca#e mencionar s esta#ilidad) s plan de e"ol cin / s integracin con el principal entorno integrado de desarrollo .N-T CEis al 4t dioD. -ste +ltimo p nto res lta de na gran importancia) considerando ' e se planea tilizar la herramienta para implementar aspectos del negocio. nas pocas herramientas) de las ' e ,inalmente res lto
(aso de est dio: Ganco H Gis

3l caso del Ganco H presentado parcialmente a lo largo de este tra#a*o) lo presentaremos ahora de ,orma completa para poder as aplicar todo lo desarrollado en los capt los anteriores.
-asos de uso / re$las de ne$ocio
Tal como lo m estra la ,ig ra @<) la aplicacin o,rece las sig ientes > , ncionalidades de cara al cliente.
Trans,erir ,ondos: permite al cliente realizar n mo"imiento de ,ondos entre dos c entas #ancarias de s propiedad. -l monto no p ede ser negati"o como tampoco p eden trans,erirse ,ondos de na c enta a si misma) ni tampoco se de#en admitir trans,erencias entre c entas de distinta moneda.
Pagar prestacin: permite al cliente pagar las prestaciones #rindadas por n con* nto de
!3 - 110
Nicols M. Paez
empresas con las ' e el Ganco H tiene ac erdos.
(ons ltar mo"imientos: el cliente p ede cons ltar en la aplicacin los mo"imientos de s s c entas.
(ons ltar saldo: el cliente p ede cons ltar los saldos de s s c entas #ancarias.
Figura 01: Casos de uso del Banco A
(omo es de esperar en aplicaciones de este tipo) para realizar c al' ier operacin es necesario ' e el s ario acredite s identidad ante la aplicacin ingresando s DN8 / cla"e de acceso. Ms all de estas , ncionalidades percepti#les directamente por el s ario) ha/ ciertas reglas de negocio ' e la aplicacin de#e implementar) las c ales se detallan a contin acin. <. Toda operacin ' e s pere cierto monto de#er ser noti,icada al Ganco (entral. $. No de#e ser posi#le realizar operaciones so#re c entas c /os tit lares tengan de das con las 3,ip. F. 3nte el tercer intento consec ti"o de ingreso ,allido al sistema por parte de n cliente) dicho cliente de#er ' edar #lo' eado de ,orma permanente sin poder acceder al sistema. >. -6iste n lmite diario del monto total por el c al n cliente p ede realizar operaciones. @. La aplicacin de#e de*ar constancia de todas las acciones realizadas por el cliente. -l sig iente diagrama m estra las clases del dominio de este pro#lema) ' e constit /en la #ase de c al' ier aplicacin ' e ata' e la pro#lemtica planteada. Dicho diagrama no contempla las reglas partic lares del Ganco H. Ms all de las , ncionalidades / reglas mencionadas) es de esperar ' e c al' ier sol cin
prop esta contemple las inc m#encia t.cnicas: mane*o de e6cepciones) transacciones a torizacin / a ditora.
Figura 02: Dominio base del Banco A
Solucin tradicional +sin A P,
Partiendo del dominio #ase representado en el diagrama de la ,ig ra @$) tra#a*aremos ahora so#re las reglas < a @ Cpartic lares del Ganco HD para encontrar na primera sol cin al Ganco H) sin tilizar 39P. Las reglas < / $) /a las hemos analizado en el capt lo anterior. -n este caso se ha optado por implementar am#as reglas en la capa de dominio) /a ' e ponerlas en la capa de ser"icios sera concept almente incorrecto por' e la capa de ser"icios slo de#e coordinar o#*etos de dominio. -s la clase -$eracin la encargada de interact ar con las inter,aces de 3,ip / del Ganco (entral para lle"ar a ca#o la reglas < / $. La des"enta*a de esta sol cin radica en ' e el cdigo relacionado a estas reglas ' edar esparcido por todas las clases de la *erar' a operacin. La regla F) es consec encia de polticas de seg ridad / res lta m / com+n en aplicaciones de este tipo. 4i #ien esta regla tiene cierta relacin con la clase Cliente) la misma e6cede las responsa#ilidades de dicha clase. -s por ello ' e hemos creado na n e"a clase Controlador+ccesos encargada de esta n e"a responsa#ilidad. 3l mismo tiempo agregamos a la clase Cliente n atri# to para indicar si el cliente est #lo' eado. Por +ltimo decidimos de*ar en manos del ser"icio de a tenticacin la coordinacin entre las clases Cliente / Controlador+ccesos. La regla > pide limitar el monto diario de operaciones del cliente. No res lta e"idente como modelar esta regla. La estrategia adoptada en este caso) , e asignar dicha responsa#ilidad a la clase operacin) de manera ' e a la hora de e*ec tar c al' ier operacin) sea la misma instancia de la clase operacin la encargada de hacer c mplir esta regla. -sta sol cin tiene la misma contra ' e la sol cin adoptada para las reglas < / $.
La regla @ nos pide de*ar constancia de todas las acciones realizadas por el cliente) esto claramente es a ditoria. Dado ' e toda accin ' e p ede realizar n cliente est e6presada por n m.todo de la capa de ser"icios) implementaremos la a ditoria a ni"el de los ser"icios. La misma estrategia adoptaremos para las inc m#encias t.cnicas / de calidad partic larmente mane*o de transacciones) cach. / seg ridad) /a ' e implementarlas en la capa de dominio podra res ltar #astante ms comple*o / al mismo tiempo impondra na dependencia del dominio con la in,raestr ct ra. ;a/ ' e destacar ' e el agregado de n e"os atri# tos t.cnicos / de calidad p ede re' erir de la modi,icacin del cdigo de los ser"icios.
public override void ,;ecutar()
{
i4 (@+ri1en#Ioneda#,Buals(Destino#Ioneda)) t)ro% ne% +peracionKo7alida,-ception($Ionedas distintas$); i4 (Ha4ip#FieneDeuda(Destino#Fitular) == Ha4ip#FieneDeuda(+ri1en#Fitular)) t)ro% ne% <liente"uspendido:orDeudas,-ception();
7eri4icarLimiteDiario(Hori1en#FitularE Ionto); +ri1en#Debitar(Ionto); Destino#5creditar(Ionto);

Hbanco<entral#Koti4icar+peraciDn(t)is); Fec)aRora / DateFime#Ko%;
Kumero / "ecuencia;
' Figura 0#: Fragmento de la clase *ransferencia con la im$lementacin de las reglas 1 2 1 ."
Respecto al diagrama de la ,ig ra @@) ca#e aclarar ' e si #ien se m estra la dependencia entre la clase operacin / las inter,aces de 3,ip / Ganco(entral) en realidad la dependencia se e6tiende a cada na de las clases descendientes de operacin) /a ' e cada s #clase de operacin de#er interact ar con las mencionadas inter,aces al rede,inir el m.todo a#stracto -*ec tar. -sta sit acion p ede apreciarse en el ,ragmento de cdigo de la clase *ransferencia en la ,ig ra @F) donde las lneas resaltadas estarn presentes en la clase Pago como tam#i.n en c al' ier otra clase de operacin ' e se pretenda agregar.
Nicols M. Paez
!6 - 110
public <liente 7alidar<liente(strin1 dniE strin1 clave)
{
<liente cliente / null; try
{ cliente / .epositorio<lientes#+btener:orDni(dni);
i4 (cliente @/ null)
i4 (cliente#,sta>loBueado) t)ro% ne% <liente>loBueado,-ception(); i4 (cliente#,s<lave<orrecta(clave))
{
Hlo11er#*n4o($5utenticaciDn cuenta8$ 0 dni); return cliente;
Hcontrolador5ccesos#.e1istrar5cceso,-itoso(cliente);
'
else
{ '
Hlo11er#*n4o($*ntento 4allido de autenticaciDn cuenta8$ 0dni);
Hcontrolador5ccesos#.e1istrar*ntento5ccesoFallido(cliente); ' ' {

Hlo11er#*n4o($<liente bloBueado$); t)ro%; Hlo11er#*n4o($*ntento 4allido de autenticaciDn cuenta8$ 0 dni); catc) (<liente>loBueado,-ception e-)
'
catc) (,-ception e-)
{ '
Hlo11er#,rror($+peracion 4allida$E e-); t)ro% ne% +peracionFallida,-ception(e-);
return null;
'
Figura 0.: Fragmento del servicio de autenticacin con la im$lementacin de las reglas # 1 0
Nicols M. Paez
! - 110
Figura 00: Dominio e)tendido con reglas del Banco A
Los sig ientes diagramas m estran las relaciones de las tres clases de la capa de ser"icios. (laramente p ede o#ser"arse ' e adems de la coordinacin de los o#*etos de dominio) los ser"icios tam#i.n se encargan de la interaccin con la in,raestr ct ra) lo c al no slo esta#lece na dependencia entre los ser"icios / las inc m#encias t.cnicas sino ' e adems genera cdigo d plicado.
Figura 0/: De$endencias del servicio de autenticacin
Nicols M. Paez
!! - 110
Figura 02: De$endencias del servicio de banca $ersonal
Figura 05: De$endencias del 7ervicio de Consulta
Solucin A P
La sol cin 39P) al ig al ' e la sol cin tradicional) parte del dominio #ase) so#re este modela las reglas < a @. -n c anto a las reglas < / $) la estrategia a tilizar es la misma ' e en el capt lo anterior: crear n aspecto por cada na de estas reglas. Dado ' e estas dos reglas son reglas del negocio) los aspectos encargados de modelarlas los implementaremos con 3spect.N-T) la herramienta 39P de entrete*ido
Nicols M. Paez !" - 110
esttico de,inida por n estra ar' itect ra. 3 contin acin se p ede apreciar n ,ragmento de cdigo de estos aspectos) en este caso escritos con la sinta6is de 3spect.N-T.
25spectDescription($.e1ulaciones bancarias decretadas por la 5dministracion Federal de *n1resos :ublicos$)3 public class .e1ulaciones54ip 8 5spect
{
25spect5ction($Ube4ore Ucall 9+peracion#,;ecutar(##)$)3 static public void 7eri4icarDeudas()
{
+peracion operacion / Far1et+b;ect as +peracion; i4 (FieneDeuda(operacion#5ctor)) t)ro% ne% <uenta"uspendida,-ception(); ' ' static public bool FieneDeuda(<liente cliente) {####' Figura 06: Im$lementacin +-P de la regla 2
25spectDescription($.e1ulaciones bancarias decretadas por el >anco <entral de la .epublica 5r1entina$)3 public class .e1ulaciones>anco<entral 8 5spect
{
25spect5ction($Ua4ter Ucall 9+peracion#,;ecutar(##)$)3 static public void Koti4icar+peraciDn()
{
+peracion operacion / Far1et+b;ect as +peracion; i4 (operacion#Ionto L HpisoKoti4icacion)
{ '
.e1istrar+peracion(operacion); '
private static void .e1istrar+peracion(+peracion operacion){####'
'
Figura /8: Im$lementacin +-P de la regla 1
La regla F) si #ien tiene cierta relacin con la seg ridad del sistema) no tiene na nat raleza trans"ersal como s elen tener las inc m#encias relacionadas a la seg ridad. La estrategia tilizada en la sol cin tradicional) p ede parecer con"eniente a alg nos lectores) pero tam#i.n podra arg mentarse ' e concept al no es del todo correcta) /a ' e de*a en manos del ser"icio la aplicacin de regla. 3l mismo tiempo) como /a hemos mencionado) esta regla es partic lar del negocio del Ganco H / por ende no sera tampoco correcto modelarla en el dominio. -s por esto ' e hechando mano de 39P) proponemos modelar esta regla con n aspecto ControladorDe+ccesos c /o cdigo se e6pone en la ,ig ra A<.
Nicols M. Paez
"0 - 110
25spectDescription($7eri4ica los accesos del cliente al sistema$)3 public class <ontroladorDe5ccesos 8 5spect
private static void .e1istar(<liente clienteE int numeroDe*ntento) {###' 25spect5ction($Uinstead Ucall 9<liente#,s<lave<orrecta(strin1) ?? Uar1s(ar12(3)$)3 static public bool 7alidar*ntentoDe5cceso(strin1 clave)
<liente cliente / Far1et+b;ect as <liente; i4 (cliente#,sta>loBueado) t)ro% ne% <liente>loBueado,-ception(); bool intento<orrecto / cliente#,s<lave<orrecta(clave); i4 (intento<orrecto)
.e1istar(clienteE ();
else
int intentos / Hre1istro2cliente3;
intentos00; .e1istar(clienteE intentos); i4 (intentos#,Buals(3)) cliente#>loBuear(); '

return intento<orrecto;
' '
Figura /1: Im$lementacin +-P de la regla #
La regla >) nos pide limitar el monto diario de operaciones del cliente. La estretegia a seg ir en este caso es la misma ' e la tilizada para las reglas < / $) crear n aspecto encargado de realizar esta "eri,icacin. Dado ' e tanto las reglas < / > hacen re,erencia a "eri,icaciones pre"ias a la e*ec cin de na operacin) se podra ha#er optado por na estrategia distinta) agr pando todas las "eri,icaciones pre"ias CprecondicionesD en n solo aspecto ' e de,ina n ad"ice por cada precondicin. De ,orma anloga podramos plantear otro aspecto para concentrar las noti,icaciones o pos condiciones. 4i #ien am#as estrategias permiten na separacin entre las inc m#encias del dominio / las del negocio) esta +ltima estrategia mezcla en n mismo aspecto distintas reglas del negocio. !inalmente la regla @ hace re,erencia a na de las inc m#encias trans"ersales ms reconocidas Ca ditoraD) pero a pesar de ' e el so de 39P es claramente con"eniente) se plantea el dilema de so#re ' . o#*eto aplicar el aspecto. Dado ' e se # sca de*ar constancia de todas las acciones realizadas por el cliente en la aplicacin / considerando ' e todas las acciones posi#les estn disponi#les mediante la capa de ser"icios) res lta s ,iciente aplicar el aspecto de a ditoria so#re los o#*etos de la capa de ser"icios. 3l mismo tiempo como esta regla no hace al negocio en s) sino ' e res lta como n
Nicols M. Paez
"1 - 110
re' isito no , ncional) la implementaremos con la herramienta 39P de entrete*ido dinmico.

25spectDescription($7eri4ica Bue las operaciones reali6adas por un cliente en un dia no e-cedan un cierto lCmite prestablecido$)3 public class <ontroladorDeLimiteDiario 8 5spect
{
25spect5ction($Ube4ore Ucall 9+peracion#,;ecutar(##)$)3 static public void 7eri4icarLimiteDiario()
{
+peracion operacion / Far1et+b;ect as +peracion; decimal contador / (; 4oreac) (<uenta>ancaria cuenta in operacion#5ctor#<uentas)
*ListN+peracionL operaciones / repositorio+peraciones#+btener+peraciones(cuenta#Kumero); 4oreac) (+peracion operacion.eali6ada in operaciones)
{
i4 (operacion.eali6ada#Fec)aRora#Date#,Buals(DateFime#Ko%#Date))
contador 0/ operacion.eali6ada#Ionto; ' '

i4 (operacion#Ionto 0 contador L/ HlimiteDiario) t)ro% ne% LimiteDiario5lcan6ado,-ception();
'
' Figura /2: Im$lementacin +-Pde la regla .
public class 5uditoria5dvice 8 *Iet)od*nterceptor
private *Lo1 Hlo11er / Lo1Iana1er#JetLo11er($5uditoria$); public ob;ect *nvoOe(*Iet)od*nvocation invocation)
Hlo11er#*n4o(JetIensa;e:re*nvocacion(invocation));
ob;ect resultado / invocation#:roceed();
Hlo11er#*n4o(JetIensa;e:os*nvocacion(invocation)); '
return resultado;
'
protected strin1 JetIensa;e:re*nvocacion(*Iet)od*nvocation invocation){##' protected strin1 JetIensa;e:os*nvocacion(*Iet)od*nvocation invocation){##' Figura /#: Im$lementacin +-P de la regla 0
-l diagrama de la ,ig ra A> m estra los o#*etos / aspectos ' e constit /en la capa de negocio la sol cin 39P para la pro#lemtica planteada por el Ganco H. -l diagrama de la ,ig ra A@ m estra los o#*etos de la capa de ser"icios / s relacin con los aspectos de in,raestr ct ra. -n c anto a las inc m#encias t.cnicas) las mismas se implementaron a ni"el de la capa de
Nicols M. Paez "2 - 110
ser"icios / se tiliz para s implementacin los aspectos mostrados en el capt lo @. ;a/ ' e destacar ' e el agregado de n e"as inc m#encias t.cnicas no re' iere de la modi,icacin del cdigo e6istente de la aplicacin) sino ' e simplemente #astara con desarrollar los aspectos correspondientes / agregarlos en la con,ig racin de la aplicacin.
Figura /.: clases del domino e)tendidas con as$ectos del negocio del Banco A
Figura /0: Clases de la ca$a de servicios con as$ectos de infraestructura
;a/ alg nas c estiones relacionadas a la implementacin de la sol cin 39P ' e "ale la pena mencionar. La sol cin 39P implementada para el Ganco H consta de A assem#lies<< representados en la ,ig ra AA * nto con s s dependencias.
<< -l assem#l/ es la nidad de desplieg e de cdigo de m' ina "irt al de la plata,orma .N-T
Nicols M. Paez "3 - 110
Figura //: +ssemblies de la solucin +-P $revio al entretejido
3spect.N-T , nciona como n pos compilador Co procesador de assem#liesD) en el sentido ' e na "ez compilados los assem#lies con las clases / los aspectos) 3spect.N-T se encarga de procesar el assem#l/ ' e contiene las clases entrete*iendo los aspectos en los p ntos de,inidos por los pointc ts. -n el caso de n estra sol cin) los aspectos implementados con 3spect.N-T se enc entran en el assem#l/ BancoA"(eglas. 3l analizar so#re ' e assem#l/ se har el entrete*ido de los aspectos) a primera "ista na podra tentarse de decir BancoA"Dominio) pero este no es n estro caso. -sto se de#e a ' e la "ersin tilizada de 3spect.N-T slo soporta poinc ts de tipo llamada CcallD / si miramos la de,inicin de pointc ts de n estros aspectos) "eremos ' e s s pointc ts hacen re,erencia a las llamadas a o#*etos del dominio. 4i #ien las llamadas a o#*etos del dominio podran estar en "arios assem#lies) en n estro caso partic lar) las llamadas a o#*etos de dominio ' e nos interesan se enc entran en el assem#l/ BancoA"7ervicios / es * stamente so#re ese assem#l/ ' e se realizar el entrete*ido. (omo res ltado del entrete*ido realizado se o#tiene n n e"a "ersin del assem#l/ original con los aspectos incl idos) lo c al cam#ia la relacin de los assem#lies de n estra sol cin.
Nicols M. Paez
"4 - 110
Figura /2: ssemblies de la solucin +-P luego del entretejido
Un p nto para destacar de este +ltimo diagrama respecto al anterior es ' e e6iste na n e"a dependencia entre el assem#l/ de ser"icios / el de las reglas) lo c al es consec encia del proceso de entrete*ido entre ser"icios / aspectos. 9tro p nto destaca#le de la sol cin 39P es ' e no e6iste ning na dependencia con el assem#l/ de in,raestr ct ra ' e contiene la implementacin de los aspectos t.cnicos. -sto se de#e a ' e los aspectos t.cnicos s elen ser lo s ,icientemente gen.ricos como para aplicar a di,erentes sol ciones / al mismo tiempo res lta ' e se enc entran implementados con na herramienta 39P de entrete*ido dinmico ' e permite la de,inicin de los pointc ts a partir del archi"o de con,ig racin de la aplicacin. (a#e mencionar ' e no siempre ' e se tilice 39P para la implementacin de los aspectos t.cnicos se lograr este ni"el de desacoplamiento /a ' e en ocasiones en necesario ' e los aspectos t.cnicos tengan cierto conocimiento de los componentes so#re los ' e se espera ' e act+en.
-omparacin de soluciones
;a#iendo e6p esto am#as sol ciones res lta interesante comparar alg nos ,ragmentos de cdigo de cada na de ellas. La ,ig ras A: / A0 m estran el cdigo del m.todo Ejecutar de la clase Pago de la sol cin tradicional / de la sol cin 39P respecti"amente.
Nicols M. Paez
"5 - 110
{
i4 (Ionto N/ () t)ro% ne% +peracionKo7alida,-ception($,l monto no puede ser ne1ativo$); i4 (Ha4ip#FieneDeuda(Hcuenta#Fitular)) t)ro% ne% <uenta"uspendida,-ception();
7eri4icarLimiteDiario(Hcuenta#FitularE Ionto); Hcuenta#Debitar(Ionto); numero / Hprestacion#:a1ar(Hcodi1oE Ionto); Fec)aRora / DateFime#Ko%;

' Hbanco<entral#Koti4icar+peraciDn(t)is); Figura /5: &!todo Ejecutar de la clase Pago de la solucin tradicional
La lneas resaltadas en el cdigo de la sol cin tradicional se enc entran d plicadas en todas las clases de la *erar' a -$eracin) lo c al e6presa cierta trans"ersalidad. Por s parte el cdigo de la sol cin 39P rem e"e dichas lneas encaps lando las inc m#encias e6presadas por las mismas en los correspondientes aspectos) c /o cdigo se "i en las ,ig ras @0)A% / A$.
i4 (Ionto N/ () t)ro% ne% +peracionKo7alida,-ception($,l monto no puede ser ne1ativo$);
Hcuenta#Debitar(Ionto); Hprestacion#:a1ar(Hcodi1oE Ionto); '

Fec)aRora / DateFime#Ko%; Figura /6: &!todo Ejecutar de la clase Pago de la solucin +-P
Una sit acin similar oc rre si se compara el cdigo de las clases de la capa de ser"icios de las ,ig ras &% / &<. Las lneas resaltadas de la ,ig ra &% son consec encia de las inc m#encias trans"ersales: mane*o de e6cepciones) a ditora / transacciones. Por s parte la sol cin 39P modela las mencionadas inc m#encias trans"ersales con aspectos) lo c al simpli,ica nota#lemente el cdigo de la ,ig ra &% remo"iendo las lneas resaltadas.
Nicols M. Paez
"6 - 110
public :a1o :a1ar:restacion(strin1 numero<uentaE strin1 id:restacionE strin1 codi1oE decimal monto)
i4 (F)read#<urrent:rincipal // null) t)ro% ne% "ecurity,-ception($Qsuario no autenticado$); :a1o pa1o / null; <uenta>ancaria cuenta / Hrepositorio<uentas#+btener<uenta(numero<uenta); i4 (cuenta // null) t)ro% ne% <uentaKo7alida,-ception(); :restacion prestacion / Hrepositorio:restaciones#+btener:restacion(id:restacion); i4 (prestacion // null) t)ro% ne% +peracionKo7alida,-ception($:restacion ine-istente#$); try
{
usin1 (Fransaction"cope scope / ne% Fransaction"cope())
pa1o / ne% :a1o(cuentaE prestacionE codi1oE monto);
pa1o#.epositorio+peraciones / Hrepositorio+peraciones; pa1o#>anco<entral / Hbanco<entral; pa1o#54ip / Ha4ip; pa1o#,;ecutar(); Hrepositorio+peraciones#.e1istrar+peracion(pa1o); scope#<omplete(); Hlo11er#*n4o($:a1o completado#$ 0 pa1o#Fo"trin1());
' ' catc) (LimiteDiario5lcan6ado,-ception e-) { Hlo11er#*n4o($*ntento de operacion no valida$E e-); t)ro%; ' catc) (<uentaKo7alida,-ception e-) { Hlo11er#*n4o($*ntento de operacion no valida$E e-); t)ro%; ' catc) (+peracionKo7alida,-ception e-) { Hlo11er#*n4o($*ntento de operacion no valida$E e-); t)ro%; ' catc) (,-ception e-) { Hlo11er#,rror($*ntento de operacion 4allido$E e-); t)ro% ne% +peracionFallida,-ception; ' return pa1o; '
Figura 28: &!todo PagarPrestacion de la clase 7ervicioBancaPersonal de la solucin tradicional
Nicols M. Paez
" - 110
public :a1o :a1ar:restacion(strin1 numero<uentaE strin1 id:restacionE strin1 codi1oE decimal monto)
:a1o pa1o / null; <uenta>ancaria cuenta / Hrepositorio<uentas#+btener<uenta(numero<uenta); i4 (cuenta // null) t)ro% ne% <uentaKo7alida,-ception(); :restacion prestacion / Hrepositorio:restaciones#+btener:restacion(id:restacion); i4 (prestacion // null) t)ro% ne% +peracionKo7alida,-ception($:restacion ine-istente#$); pa1o / ne% :a1o(cuentaE prestacionE codi1oE monto);
pa1o#,;ecutar(); Hrepositorio+peraciones#.e1istrar+peracion(pa1o);
' return pa1o; Figura 21: &!todo PagarPrestacion de la clase 7ervicioBancaPersonal de la solucin +-P
(a#e destacar ' e en el caso de la sol cin 39P) podra agregarse la "eri,icacin de ciertos in"ariantes de ,orma transparente para la aplicacin) a partir de com#inar el so de 39P con na herramienta de dise2o por contractos.
Nicols M. Paez
"! - 110
(apit lo E888: (oncl siones

-l o#*eti"o principal de este tra#a*o era analizar la con"eniencia de la tilizacin de 39P en el desarrollo de aplicaciones enterprise) proponiendo na sol cin 39P a a' ellas pro#lemticas en las ' e el so de 39P res lte #ene,icioso. De cara a este o#*eti"o se identi,icaron dos tipos de inc m#encias claramente di,erenciadas en las 3-W las del negocio / las t.cnicasI / se analiz el so de 39P en relacin a cada no de estos tipos de inc m#encias) a partir de lo c al s rgieron los sig ientes c estiones para destacar.
5ran parte de las inc m#encias t.cnicas c entan con na nat raleza trans"ersal ' e las con"ierte en e6celentes candidatos a ser implementadas con 39P.
-l
so de 39P permite
na clara separacin de inc m#encias) permitiendo ' e las
inc m#encias del negocio p edan implementarse independientemente de las inc m#encia t.cnicas) ,acilitando as el ,oco en el negocio.
La implementacin de las inc m#encias t.cnicas tilizando na herramientas de entrete*ido dinmico) permite el agregado de inc m#encias t.cnicas de ,orma prcticamente trasparente para la aplicacin. 3l mismo tiempo el so de na herramienta de entrete*ido esttico para la implementacin de los aspectos del negocio aseg ra ' e el c mplimiento de las reglas del negocio) e"itando ' e la aplicacin de las mismas dependa de la con,ig racin de la aplicacin como oc rre en el caso de las herramientas de entrete*ido dinmico.
Las inc m#encias t.cnicas implementadas con aspectos res ltan altamente re tiliza#les en distintas aplicaciones. 3simismo ' eda claro ' e la implementacin de inc m#encias t.cnicas tilizando 39P re' iere de n es, erzo m cho menor ' e na implementacin tradicional.
Tal como en la programacin orientada a o#*etos el programador p ede decidir ' e n m.todo o na clase no p edan ser e6tendidos o rede,inidos Cen .N-T mediante la cla s la sealed / en ?a"a mediante el la cla s la finalD) res lta necesario en la programacin orientada a aspectos poder especi,icar ' e no se le agreg en aspectos a na clase dada. 4i #ien esta pro#lemtica no se "io en el e*emplo e6p esto) la misma , e detectada d rante la implementacin de la aplicacin de re,erencia. -sta necesidad se "e acent ada por el hecho de ' e a partir de la clara separacin de inc m#encias es posi#le ' e sean distintos programadores los ' e se encarg en de las inc m#encias t.cnicas / de las inc m#encias del negocio.
Nicols M. Paez
"" - 110
(omo o#*eti"o sec ndario) se prop so el desarrollo de na aplicacin de re,erencia so#re la plata,orma .N-T. -ste o#*eti"o se c mpli satis,actoriamente con la implementacin del caso de est dio / permitiendo d rante s desarrollo detectar alg nas c estiones interesantes.
Las herramientas 39P para la plata,orma .N-T estn herramientas para la plata,orma ?a"a.
n paso atrs respecto de las
-s necesario ' e las herramientas p edan integrarse con los entornos de desarrollo para #rindar soporte) principalmente) a dos c estiones: dep racin / traza#ilidad del cdigo , ente. Respecto de este +ltimo p nto) res lta indispensa#le ' e al "is alizar el cdigo) el entorno de desarrollo indi' e a' ellas porciones de cdigo ' e se enc entran a,ectadas por n aspecto Cesta , ncionalidad e6iste en -clipse para el caso de 3spect?) pero en el caso de .N-T no ha/ nada similarD.
Tal como se espera#a) la sol cin 39P permiti eliminar gran cantidad de cdigo trans"ersal) me*orando la mod larizacin de las inc m#encias) a mentado la cohesin / dismin /endo nota#lemente el acoplamiento.
-n c anto a la lgica de negocio) el
so de aspectos permiti separar claramente las
inc m#encias del dominio de las inc m#encias espec,icas de la organizacin. 3 contin acin se en meran alg nas c estiones a#iertas ' e no han sido tratadas en este tra#a*o / ' e #ien podran ser o#*eto de , t ras in"estigaciones.
-l so de 39P en la capa de presentacin de toda aplicacin ' e re' iera de inter,ases de s ario interacti"as) es na pro#lemtica ' e a+n no ha sido plenamente desarrollada.
La e6plotacin de las posi#ilidades o,recidas para 39P por la plata,orma .N-T F.@ a partir de la incorporacin del soporte para leng a*es dinmicos) es ine6plorada. na linea de tra#a*o a+n
!inalmente ca#e mencionar ' e las t.cnicas a"anzadas de separacin de inc m#encias son na temtica relati"amente n e"a / a sente a+n ho/ en la ma/ora de los planes de est dio) lo c al con"ierte a dicha temtica en n interesante o#*eto de in"estigacin para tesis de grado / posgrado.
Nicols M. Paez
100 - 110
3p.ndice 8: ;erramientas 39P

3spect.N-T
-sta herramienta de entrete*ido esttico) desarrollada en la Uni"ersidad de 4an Perters# rgo) por el e' ipo liderado por Eladimir 4a,ono") consta de tres componentes: n con"ertidor de metaleng a*e Co pre procesadorD) n =ea"er / n ,rame=orB.
cdigo fuente aspectos
Aspect.NET ML Convertidor
cdigo intermedio aspectos compilador Aspect.NET weaver cdigo intermedio clases aplicacin
cdigo fuente clases
Aspect.NET Framework
Figura 22: Com$onentes de +s$ect"<E*
La de,inicin de n aspecto en 3spect.N-T se hace tilizando n metaleng a*e. -l con"ertidor de metaleng a*e) se encarga de la trad ccin a cdigo (M) generando na clase por cada aspecto / agregando a dicha clase determinadas anotaciones ' e sern tilizadas posteriormente por el =ea"er para realizar el entrete*ido. Tam#i.n e6iste la posi#ilidad de de,inir aspectos) a partir de clases) heredando de la clase +s$ect / agregndo ciertas anotaciones pro"istas por 3spect.N-T. La de,inicin de n aspecto en el metaleng a*e de 3spect.N-T consta de > partes:
Un enca#ezado opcional) ' e le indica al con"ertidor el nom#re de la clase ' e representar el aspecto.
Datos) ' e son simplemente atri# tos del aspecto / sern trad cidos como tales a (M. Md los) ' e son simplemente m.todos del aspecto./ sern trad cidos como tales a (M. Reglas) ' e especi,ican como de#e realizarse el entrete*ido. (ada regla consiste en na condicin / na accin. La condicin es tilizada por el =ea"er para determinar los *oinpoints donde aplicar la accin.
Nicols M. Paez
101 - 110
;aciendo n mapeo de los t.rminos de 3spect.N-T a los conceptos de 39P) podemos decir ' e las acciones * egan el rol de ad"ices) mientras ' e las condiciones res ltan e' i"alentes a poinc ts. La "ersin act al de 3spect.N-T C$.<D solo #rinda soporte para de,inir condiciones Cpoinc tsD identi,icando llamadas a m.todos) a n' e esto ser ampliado en , t ras "ersiones. -l ,rame=orB de 3spect.N-T #rinda integracin con el Eis al 4t dio) permitiendo al programador inter"enir en el proceso de entrete*ido eligiendo e6actamente en ' e *oinpoints de los ' e c mplen con la condiciones de,inidas por los aspectos) se aplicarn las acciones. 3 di,erencia de lo ' e oc rre con 3spect?) todos los miem#ros de n aspecto en 3spect.N-T de#en de,inirse como miem#ros de clase. Un hecho interesante so#re 3spect.N-T es ' e est #asado en Phoeni6 JPhoeni6K) ,rame=orB ' e constit /e la plata,orma #ase para la , t ra generacin de compiladores Microso,t / ' e como tal #rinda soporte para constr ccin de compiladores / herramientas de anlisis / optimizacin de cdigo. 3l tra#a*ar con 3spect.N-T no desarrolla la aplicacin tradicionalmente tilizando el
compilador de (M. L ego escri#e los aspectos seg+n de,ine 3spect.N-T. !inalmente se realizar el entrete*ido tomando como entrada el cdigo #inario de la aplicacin / de los aspectos. -sto dar como res ltado na n e"a aplicacin con aspectos incl idos.
4pring 39P
4pring 39P es el md lo de 4pring!rame=orB ' e #rida capacidades de programacin orientada a aspectos complementando las , ncionalidades o,recidas por el resto de los md los del ,rame=orB. -6iste dos implementaciones del ,rame=orB) na para ?a"a / otra para .N-T ' e como es de esperar tienen alg nas di,erencias. -n lo ' e respecta al md lo de 39P) la di,erencia ms nota#le est dada por el hecho de ' e la "ersin ?a"a #rinda cierta integracin con 3spect?. Todo el ,rame=orB 4pring es n desarrollo de cdigo a#ierto) lle"ado adelante por la empresa 8nter,ace $<. 4pring 39P.N-T est completamente implementado (M) sin hacer so alg no de 3P8s no
mane*adas ni de modi,icaciones en los assem#lies. Todo el entrete*ido es dinmico / como tal se hace en tiempo de e*ec cin) lo c al lo hace compati#le con c al' ier am#iente (LR. 3l ig al ' e "arias herramientas 39P #asadas en pro6ies dinmicos) la de,inicin de n aspecto se hace en dos partes: por n lado se de#en de,inir los ad"ices) a partir de implementar na determinada inter,ace ' e depende del tipo de ad"ice ' e se pretenda implementar / por otro lado se de,inen mediante con,ig racin Cgeneralmente en HMLD los pointc ts so#re los ' e cada ad"ice aplicar. 4pring 39P soporta todos los conceptos de,inidos por el paradigma 39P / de#emos destacar las posi#ilidad de e6tensin ' e #rinda) las c ales llegan incl so a permitir la de,inicin de n e"os tipos de
ad"ice / pointc ts.
Nicols M. Paez
103 - 110
3p.ndice 88: Patrones de dise2o

3 contin acin se descri#e #re"emente alg nos de los patrones de dise2o ms tilizados en las aplicaciones enterprise.
ModelIEie=I(ontroller
-ste es no de los patrones ms di, ndido. Pertenece a la categora estiloNpatrn de ar' itect ra. 4 rgi en los a2os &% implementado para 4malltalB / ho/ en da tiene na gran in,l encia en lo ' e respecta al dise2o de la capa de presentacin de las aplicaciones enterprise. Gsicamente el patrn a/ da a estr ct rar aplicaciones ' e re' ieran de inter,ases de s ario interacti"as.
Transaction 4cript
-ste patrn propone organizar toda la lgica asociada a na operacin del s ario en n +nico procedimiento) interact ando directamente con la #ase de datos. 4 ele tililizarse c ando la lgica del negocio de la aplicacin es relati"amente simple.
Domain model
Propone estr ct rar la lgica de la aplicacin en torno a clases ' e representan conceptos del negocio. -n el dise2o de dichas clases se tilizan , ertemente los conceptos de orientacin a o#*etos para as o#tener n modelo cercano a la realidad. Las clases no slo encaps lan datos sino tam#i.n comportamiento ' e e6presa las reglas del dominio.
4er"ice La/er
Permite de,inir la ,rontera de la aplicacin a tra".s de n con* nto de operacin ' e p eden ser in"ocadas tanto desde aplicacin tomando a s na capa de presentacin como desde otra aplicacin. -ncaps la toda la cargo ciertas c estiones de in,raestr ct ra) como la administracin de
transacciones / delega a las capa in,eriores la resol cin de la lgica de negocio.
Datamapper
-ste patrn pertenece a la capa de persistencia. (apa mapper act a como ne6o entre o#*etos en memoria / s representacin en la #ase de datos) siendo respensa#le de la trans,erencia de datos entre am#os l gares.
Nicols M. Paez
104 - 110
Data Trans,er 9#*ect

9,rece na sol cin para distri# cin de o#*etos. Un Data Trans,er 9#*ect CDT9D es n o#*eto serializa#le ' e p ede "ia*ar ,cilmente a tra".s de la red / ' e contiene generalmente in,ormacin perteneciente a "arios o#*etos de dominio.
Dependenc/ 8n*ection
-ste patrn ,acilita la resol cin de depencias entre o#*etos a partir de la introd ccin de na clase Ensamblador) ' e , ncionando de ,orma similar a na ,#rica de o#*etos) se encarga a partir de in,ormacin de con,ig racin) de resol"er las dependencias) permiti.ndonos adicionalmente separar inter,az de implementacin.
Para ms in,ormacin so#re patrones en general "er J5amma0@K / en partic lar para el caso de patrones para aplicaciones enterprise "er J!o=ler%FK.
Nicols M. Paez
105 - 110
Gi#liogra,a

J3cegiK 3cegi 4ec rit/) http:NN===.acegisec rit/.orgN) "eri,icado el %$N<<N$%%&. J3le6ander&&K (. 3le6ander) 4. 8shiBa=a) M. 4il"erstein) M. ?aco#son) 8. !iBsdahlIRing) 4. 3ngel) 3 Pattern Lang age:To=ns) G ildings) (onstr ction ) 96,ord Uni"ersit/ Press) N e"a XorB) <0&&) 84GN: 84GN: %<0@%<0<00.
J3m#ler%%K 4. 3m#ler) The Design o, a Ro# st Persistence La/er ,or Relational Data#ases) ===.am#/so,t.comNdo=nloadsNpersistenceLa"er.pd, ) "eri,icado %$N<<N$%%&.
J3m#ler%>K 4. 3m#ler) The 9#*ectIRelational 8mpedance Mismatch) http:NN===.agiledata.orgNessa/sNimpedanceMismatch.html) "eri,icado %$N<<N$%%&.
J3op3llianceK 39P 3lliance) http:NNaopalliance.so rce,orge.netN) "eri,icado %$N<<N$%%&. J39R-K 3spectI9riented Re' irements -ngineering) http:NN===.cs.toronto.ed NcserNaore.html) "eri,icado el %$N<<N$%%&.
J394DK 3spectI9riented 4o,t=are De"elopment) http:NN===.aosd.netN) "eri,icado %$N<<N$%%&.
J3P4K 3pache Logging 4er"ices) http:NNlogging.apache.orgN) "eri,icado %$N<<N$%%&. J3shmore%>K D. 3shmore) The ?$-- architect1s hand#ooB: ho= to #e a s ccess, l technical architect ,or ?$-- applications) DET Press $%%>) 84GN: %I0&$I0@>:0I0.
J3spectMK %$N<<N$%%&.
3spectM)
http:NN===.castlepro*ect.orgNaspectsharpNinde6.html)
"eri,icado
J3spectcSSK 3spect(SS) http:NN===.aspectc.org) "eri,icado %$N<<N$%%&. J3spectDN5K 3spectDN5) http:NNaspectdng.tigris.orgN) "eri,icado %$N<<N$%%&. J3spect*K 3spect?) http:NN===.eclipse.orgNaspect*) "eri,icado %$N<<N$%%&. J3spectNetK 3spectDN5) http:NNaspectdng.tigris.org ) "eri,icado %$N<<N$%%&. JGass%FK L. Gass) P. (lements) R. Razman) 4o,t=are 3rchitect re in Practice) 4econd -dition) 3ddison Wesle/ $%%F) 84GN: %IF$<I<@>0@I0.
JGodBin%AK R. GodBin) 39PZWorB: Ne6t steps =ith aspects) http:NN===.i#m.comNde"eloper=orBsN*a"aNli#rar/N*I aop=orB<ANinde6.htmlU4YT3(T[<%@35H%$\4Y(MP[-DUMreso rces) "eri,icado %$N<<N$%%&.
Nicols M. Paez
JGro=nK R. Gro=n) G. WhitenacB) (rossing (hasms: 3 pattern lang age ,or o#*ectI
106 - 110
RDGM4 integration) http:NN===.Bsc.comNarticle@.htm) "eri,icado %$N<<N$%%&.
JG schmann0@K !. G schmann) R. Me nier) ;. Rohnert) P. 4ommerlad) M. 4tal) PatternI 9riented 4o,t=are 3rchitect re: 3 s/stem o, patterns) ?ohn Wile/ \ 4ons Ltd) 84GN: %I >&<I0@:A0I&.
J(ontract>*K
(ontract>?:
Desing
#/
contract
,or
?a"a)
http:NN===.contract>*.orgNcontract>*) "eri,icado %$N<<N$%%&.
J(/ment%>K 3. (/ment) R. 3ltman) 4etPoint: Un en,o' e semntico para la resol cin de pointc ts en 39P) Tesis de Licenciat ra en (iencias de la (omp tacin) !ac ltad de (iencias -6actas / Nat rales) Uni"ersidad de G enos 3ires) No"iem#re $%%>.
JDi*BstraA:K -. Di*Bstra) 5o To (onsidered ;arm, l) Letter to (omm nications o, the 3(M C(3(MD) "ol. << no. F) March <0A:) pp. <>&I<>:.
JDiotale"i%>K !. Diotale"i) (ontract en,orcement =ith 39P: 3ppl/ Design #/ contract to *a"a so,t=are de"elopment =ith 3spect?) http:NN===.i#m.comNde"eloper=orBsNli#rar/N*I ceaopN) "eri,icado el %$N<<N$%%&.
JD cB%AK) 3. D cB) 8mplementation o, 39P in nonIacademic pro*ects) @th 8nternational (on,erence on 3spectI9riented 4o,t=are De"elopment) 8nd str/ TracB Proceedings) Gonn 5erman/ March $%%A.
J-add/%@K M. -add/) 3. 3ho) W. ; ) P. McDonald / ?. G rg er) De# gging Wo"en (ode) (ol m#ia Uni"ersit/) Ne= XorBW Microso,t (orporation) Redmond) $%%@.
J-arl/3spectsK -arl/ 3spects) http:NN===.earl/Iaspects.netN) "eri,icado %$N<<N$%%&. J-clipseK -clipse) http:NN===.eclipse.orgN) "eri,icado el %$N<<N$%%&. J-idelman%AK 3. -idelman) ;acia na me*or e6periencia de de# gging en desarrollos 39P) Tesis de grado en 8ngeniera 8n,ormtica) !ac ltad de 8ngeniera) Uni"ersidad de G enos 3ires) No"iem#re $%%A.
J-lrad%<K T. -lrad) M. 3Bsit) 5. Riczales)R. Lie#erherr);. 9sser) Disc sing aspects o, 39P) (omm nications o, the 3(M) Eol me >> ) 8ss e <% C9cto#er $%%<D Pginas: FF a F:) $%%<.
J-ndrei%>K M. -ndrei) ?. 3ng) 3. 3rsan*ani) 4. (h a) P. (omte) Patterns: 4er"iceI 9riented 3rchitect re and We# 4er"ices) 8GM RedGooBs $%%>.
J-rdod/%AK D. -rdod/) Un !rame=orB para la "is alizacin de patrones de dise2o distri# idos / conc rrentes implementados con programacin orientada a aspectos: 3(E! C3spect al (omponent Eis alization !rame=orBD) Tesis de grado en 8ngeniera 8n,ormtica) !ac ltad de 8ngeniera) Uni"ersidad de G enos 3ires) Dicime#re $%%A.
Nicols M. Paez
10 - 110
J-rl%@K T. -rl) 4er"iceI9riented 3rchitect re: (oncepts) Technolog/ and Design) Prentice ;all PTR $%%@) 84GN: %I<FI<:@:@:I%.
J-"ans%FK -. -"ans) DomainIDri"en Design: TacBling (omple6it/ in the ;eart o, 4o,t=are) 3ddison Wesle/ $%%F) 84GN: %IF$<I<$@$<I@.
J!ilman%>K R. !ilman) T. -lrad) 4. (larBe) M. 3Bsit) 3spectI9riented 4o,t=are De"elopment) 3ddisonIWesle/ $%%>) 84GN: %F$<$<0&A&
J!o=ler%FK M. !o=ler) D. Rice) M !oemmel) -. ;ieatt) R Mee) R 4ta,,ord) Patterns o, -nterprise 3pplication 3rchitect re) 3ddison Wesle/ $%%$) 84GN: %IF$<I<$&>$I%.
J5amma0@K -. 5amma) R ;elm) R. ?ohnson) ?. Elissides) Design Patterns: -lements o, Re sa#le 9#*ectI9riented 4o,t=are ) 3ddisonIWesle/) <00@) 84GN: %$%<AFFA<$ .
J;arrison%$K W. ;arrison) ;. 9ssher) P. Tarr) 3s/mmetricall/ "s. 4/mmetricall/ 9rganized Paradigms !or 4o,t=are (omposition) 8GM Research Report) Dicem#er $%%$.
J;ohmann%FK L. ;ohmann) Ge/ond 4o,t=are 3rchitect re: (reating and 4 staining Winning 4ol tions) 3ddison Wesle/ $%%F) 84GN: %I$%<I&&@0>I:.
J8s#erg%@K W. 8s#erg) 39PZ=orB: Design =ith pointc ts to a"oid pattern densit/) http:NN===.i#m.comNde"eloper=orBsN*a"aNli#rar/N*Iaop=orB&Ninde6.html) %$N<<N$%%&. "eri,icado
J?#oss3opK %$N<<N$%%&.
?#oss39P)
http:NNla#s.*#oss.comNportalN*#ossaopNinde6.html)"eri,icado
J?eziersBi%FK -. ?eziersBi) 3pplication 3rchitect re ,or .N-T: Desinging 3pplications and 4er"ices) Microso,t Press $%%F) 84GN: %&F@A<:F&$.
J?ohnson%$K R. ?ohnson) ?. ;oeller. -6pert 9neIonI9ne ?$-- Desing and De"elopment) Wro= Press $%%$) 84GN
J?ohnson%>K R. ?ohnson) ?. ;oeller. -6pert 9neIonI9ne ?$-- De"elopment =itho t -?G) Wile/ P #lishing 8nc. $%%>) 84GN %I&A>@I@:F<I@.
JRiczales0&K 5. Riczales) ?. 8r=in) ?. Lamping) ?. Loingtier) (. Eideira Lopes) (. Maeda and 3. MendheBar. 3spectI9riented Programming) -(99P <00& .
JLaddad%FK R. Laddad) 3spect? in action) Practical 3spectI9riented Programming) Manning P #lications $%%F) 84GN <I0F%<<%I0FIA.
JLaddad%AK R. Laddad) 39PZWorB: 39P m/ths and realities) Ge/ond h/pe and mis nderstandings) "eri,icado %$N<<N$%%&. http:NN===.i#m.comNde"eloper=orBsN*a"aNli#rar/N*Iaop=orB<@N)
Nicols M. Paez
JLesiecBi%FK N. LesiecBi) ?. 5radecBi) Mastering 3spect?) 3spectI9riented Programming

10! - 110
in ?a"a) Wile/ P #lishing 8nc. $%%F) 84GN %I>&<I>F<%>I>.
JLesiecBi%@K
N.
LesiecBi)
-nhance
design
patterns
=ith
3spect?)
http:NN===.i#m.comNde"eloper=orBsNli#rar/N*Iaop=orB@N) "eri,icado el %$N<<N$%%&.
JLoomK
L99M.N-T)
http:NN===.dcl.hpi. niIpotsdam.deNresearchNloomN)
"eri,icado
%$N<<N$%%&.
JLopes%%K (. Eideira Lopes) M. Lippert) 3 st d/ on -6ception Detection and ;andling sing 3spectI9riented Programming) 8(4- $%%%.
JMe/er0$K G. Me/er) 3ppl/ing Design #/ (ontract) (omp ter) Eol me $@) 9ct #re <00$) Pginas >%I@<) <00$) 844N: %%<:I0<A$
JMiles%@K R. Miles) 3spect? (ooB#ooB) 91Reill/ $%%@) 84GN: %I@0AI%%A@>IF. JNaspectK Naspect) http:NN===.p zzle,rame=orB.comNWiBi-ngineNWiBiPageEie=er.asp6U8D[:F) "eri,icado %$N<<N$%%&.
JNilsson%AK ?. Nilsson) 3ppl/ing DomainIDri"en Design and Patterns) 3ddisonIWesle/ $%%A) 84GN: %IF$<I$A:$%I$.
JPa=laB%FK R. Pa=laB) The 39P 3lliance: Wh/ did =e get inU) ? lio $%%F) http:NNaopalliance.so rce,orge.netN=hiteYpaperN ) "eri,icado el %$N<<N$%%&.
JPa=laB%@K R. Pa=laB) L 4eint rier) ?.P. Retaill.) !o ndations o, 39P ,or ?$-De"elopment) 3Press $%%@) 84GN: <I@0%@0I@%&IA.
JPhoeni6K Phoeni6) https:NNconnect.microso,t.comNPhoeni6N "eri,icado el %$N<<N$%%&. JRashid%$K 3. Rashid) R. (hitch/an) Persistence as an 3spect) Proceedings o, the $nd international con,erence on 3spectIoriented so,t=are de"elopment) Goston) Massach setts) Pages: <$% ] <$0 $%%F) 84GN:<I@:<<FIAA%I0
J4oares%$K 4. 4oares) -. La reano) P. Gor#a) 8mplementing distri# tion and persistence =ith 3spect?) 99P4L3 $%%$) 3(M Press pginas <&>I<0%.
J4o sa%>K 5. 4o sa) 4. 4oares) P. Gor#a) ?. (astro) 4eparation o, crossc tting concers ,rom Re' irements to Design: 3dapting an Use case dri"en approach) 8n Proc. -arl/ 3spects WorBshop at 394D $%%>.
J4pringK 4pring !rame=orB) http:NN===.spring,rame=orB.com) "eri,icado %$N<<N$%%&. J4toerzer%>K M. 4toerzer) T. 4Botiniotis) (. (onstantinides) 39P considered harm, l) <st - ropean 8nteracti"e WorBshop on 3spect 4/stems C-8W34D) $%%>.
JRoppen%>K (. Roppen) M. 4toerzer) P(Di,,: 3ttacBing the !ragile Pointc t Pro#lem) <st - ropean 8nteracti"e WorBshop on 3spect 4/stems C-8W34D) $%%>.
Nicols M. Paez
10" - 110
JTarr00K P. Tarr) ;. 9ssher) 4. 4 tton) W. ;arrison) N Degrees o, separation: M ltiI Dimensional 4eparation o, (oncerns) Proceedings o, the <000 8nternational (on,erence on 4o,t=are -ngineering) Los 3ngeles) (ali,ornia) U43) <000.
J#o$r%&03K T. #o$r%&' (. )ric*a$' +. ,-.els' /n t*e 01istence o2 t*e 3/45-06ol$tion

Parado1' 3/45 7or8s*op on 4o2t%are-engineering' )oston' U43' 2003
JTro=#ridge%FK D. Tro=#ridge) D. Mancini) D L icB) 5. ;ohpe) ? Ne=BirB) D La"igne) -nterprise 4ol tion Patterns Using Microso,t.N-T Eersin $.%) Microso,t Press
JW(!K Windo=s (omm nication !o ndations) http:NN=c,.net,6F.comN) "eri,icado %$N<<N$%%&.
Nicols M. Paez
110 - 110

Tesis Grado Ingenieria Informatica

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Grado Ingenieria Informatica

Cargado por

Copyright:

Formatos disponibles

Tesis de grado en Ingeniera en Informtica

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

3 mi mam 4il"ia / a mi hermano 5ermn por s apo/o incondicional / s aliento contin o.

3 (ot/) por s paciencia in,inita d rante esta larga carrera.

3 Rosita) directora de este tra#a*o) por s con,ianza en mi / s paciencia.

3 (arlos por s s comentarios constr cti"os.

3 los pro,esores) compa2eros) amigos / colegas) ' e de na tra#a*o.

otra ,orma han cola#orado en este

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

(apit lo 8: 8ntrod ccin

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Notas para el lector

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

(apit lo 88: Programacin orientada a aspectos

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Figura 1: Diagrama de clases del dominio de banca electrnica

(ontemplar n n e"o tipo de c enta) PlazoFijo)con na poltica distinta de permisos.

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Figura 2: Incumbencias transversales en las clases del dominio de banca electrnica

Desarrollo de software orientado a aspectos

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

-lementos del paradigma

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Nmero de l nea <F <& <0 $F $>

N9T3: -n la ma/ora de las herramientas H s ele ser na e6presin reg lar

Ge,ore: se e*ec tan pre"ios a la e*ec cin del *oinpoint asociado.

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

n archi"o , ente / los poinc ts en

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

con,ig racin de la aplicacin ,inal.

Figura .: Diagrama de la solucin +-P del dominio de banca electrnica

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Figura 2: Clases t3$icas de un frame%or4s +-P"

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Figura 5: Creacin de un objeto as$ectizado $or un frame%or4 +-P

Figura 6: 7ecuencia de ejecucin de un advice de ti$o before

;a/ n serie de c estiones ' e caracterizan a cada tipo de herramienta.

Mientras ' e las herramientas de entrete*ido esttico #rindan la posi#ilidad de detectar

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Sprin$ &ramewor'# el promotor

-stado del arte

so para ((( no , ncionales) al tiempo ' e

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

(apit lo 888: 3plicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

*abla 2: Caracter3sticas distintivas de los distintos ti$os de +E

3tri# tos de calidad

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

no de los atri# tos ms comple*os) de#ido a s relacin con los dems

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Re' isitos t.cnicos

Utilizacin de programacin orientada a aspectos en aplicaciones enterprise

Ge,ore: se eec tan pre"ios a la eec cin del *oinpoint asociado.