Arquitectura de capas en Sistemas de Informacin

Introduccin
La metodologa RPM presentada por C. Larman presupone una estructura de tres capas que es tpica de los Sistemas de Informacin. Estas tres capas son: La capa de la Presentacin Esta capa rene todos los aspectos del soft are que tiene que !er con las interfaces " la interaccin con los diferentes tipos de usuarios #umanos Estos aspectos tpicamente inclu"en el mane$o " aspecto de las !entanas% el formato de los reportes% menes% gr&ficos " elementos multimedia en general.

La capa del Dominio de la Aplicacin Esta capa rene todos los aspectos del soft are que tienen que automati'an o apo"an los procesos de negocio que lle!an a ca(o los usuarios. Estos aspectos tpicamente inclu"en las tareas que forman parte de los procesos% las reglas " restricciones que aplican. Esta capa tam(i)n reci(e el nom(re de la capa de la Lgica de la *plicacin. La capa del Repositorio Esta capa rene todos los aspectos del soft are que tienen que !er con el mane$o de los datos persistentes% por lo que tam(i)n se le denomina la capa de las +ases de ,atos-.

RPM toca mu" superficialmente los pro(lemas asociados al desarrollo de una capa de Presentacin. Menciona que es con!eniente usar un enfoque de prototipa$e " que pueden ser tiles los casos reales de uso. sin em(argo no proporciona m)todos% principios o lineamientos metodolgicos que apo"en el desarrollo de una metfora de diseo para la interfaz, el diseo lgico de la presentacin o su diseo fsico. RPM tampoco proporciona muc#as luces so(re el desarrollo de la capa del Repositorio " tiende a su(estimar su comple$idad. /na !e' ela(orado el Modelo de /so% RPM recomiendo seguir con acti!idades de anlisis de requerimientos. Para ello se ela(ora un Modelo Conceptual% en el cual se (usca identificar los conceptos importantes del dominio de la aplicacin% a(stra"endo todo lo que puedan ser mecanismos o conceptos propios de un dise0o o de una implementacin. *s% en el e$emplo de un Sistema de Punto de 1enta% nos interesan los conceptos como 1enta% Reci(o% Efecti!o% C#eque% Impuesto que tienen que !er con los procesos de negocio que se est&n apo"ando " no nos interesan conceptos como Men% 1entana% 2a(la relacional% Consulta a +ase de ,atos que tienen que !er con cmo me$or

implementar los conceptos del negocio. La ma"ora de estos elementos de un Modelo Conceptual terminan agrup&ndose naturalmente en la capa del ,ominio de la *plicacin. Este enfoque de RPM termina por sesgar la metodologa #acia el desarrollo de la capa del ,ominio de la *plicacin% " en la pr&ctica% tiende a #acer presuponer que el desarrollo de las otras capas se puede a$ustar al dise0o de la capa del ,ominio de *plicacin% lo cual no es siempre el caso% incluso dentro del &m(ito de los Sistemas de Informacin. *ntes de estudiar el Modelo Conceptual% nos con!iene aclarar qu) es una arquitectura de capas% su importancia e implicaciones% para tener ma"or claridad en los riesgos que corremos al adoptar una metodologa como RPM.

Arquitectura de Capas
Preguntar qu) conocen por arquitectura de capas 3en Sistemas de 4peracin% Redes de Computadores...-. 5os limitaremos a mane$ar la nocin de arquitectura como una forma de estructurar los elementos de un soft are. En toda arquitectura de capa los elementos agrupados en una misma capa pueden comunicarse entre si. pero e6isten !ariantes en cuanto a las comunicaciones permitidas entre elementos de capas diferentes: 7. Arquitectura top-down de capas: Los elementos de una capa i87 pueden en!iar solicitudes de ser!icio a elementos de la capa inferior i. 2picamente se produce una cascada de solicitudes% es decir para satisfacer una solicitud a una capa i89% )sta requiere en!iar !arias solicitudes a la capa i87. cada una de estas solicitudes a la capa i87 genera a su !e' un con$unto de solicitudes a la capa i " as sucesi!amente. /na arquitectura top:do n es laxa (o no estricta- si los elementos de una capa i87 pueden en!iar solicitudes de ser!icio directamente a un elemento de cualquiera de las i capas inferiores. 9. Arquitectura bottom-up de capas: Cada elemento de una capa i puede notificar a elementos de la capa superior i87 de que #a ocurrido algn e!ento de inter)s 3e$. mane$adores de dispositi!os-. La capa i87 puede $untar !arios e!entos antes de notificar a su !e' an elemento de la capa i89. /na arquitectura (ottom: up tam(ien puede ser no estricta si el elemento de la capa i puede notificar a cualquier elemento de cualquier capa superior a la capa i. ;. Arquitectura bidireccional de capas En su forma m&s comn in!olucra dos pilas de 5 capas que se comunican entre si. El e$emplo m&s conocido es el de los protocolos en Redes de Computadores.

*l implementar una arquitectura top-down de capas% se de(en tomar en cuenta los siguientes factores: 7. <Cu&l es el criterio de a(straccin para agrupar ser!icios=clases en una capa> Mencionar el criterio Presentacin:,ominio de *plicacin:Repositorio de Sistemas de Informacin. 9. ,eterminar el nmero de capas En t)rminos simplistas% a m&s capas m&s fle6i(ilidad pero menor desempe0o. ?,iscutir@ ;. 2picamente las capas m&s internas ofrecen menos ser!icios. Esto a"uda la reutili'acin de capas 3Apir&mide in!ertida de reusoA-. B. El grado de encapsulamiento de las capas. * ma"or encapsulamiento% menor dependencia e6terna so(re la estructura de una capa. C. Estructura interna de cada capa. D. <Cu&nta informacin pasar de una capa a otra> 2omemos el caso de la arquitectura top:do n. Es mu" posi(le que% de acuerdo con el tipo de ser!icio solicitado% la capa inferior requiera una cantidad de informacin !aria(le. En un modelo puro Aempu$adoA 3 pus -% la capa superior est& o(ligada a en!iarle toda la informacin que pueda llegar a #acerle falta a la capa inferior en la solicitud. Esto no siempre es posi(le 3piense por e$emplo en una solicitud de ser!icio a una (ase de datos que no logra completarse por estar fuera de lnea. <Eu) se #ace: reintentar% a(andonar% usar una fuente alterna>-. En el modelo contrario% A#aladoA 3pull o por demanda-% la capa inferior solicita ma"or informacin slo si le #ace falta ::<pero de qui)n la pida> El modelo de solicitudes top:do n presupone un in!ocador annimo " un in!ocado conocido. La solucin la proporciona el patrn Editorial:Suscriptor 3Pu(lis#: Su(scri(e- que encapsula la idea del call!ac". Este patrn de dise0o lo estudiaremos m&s adelante. F. ,ise0e la estrategia de mane$o de errores. Este es un aspecto que es frecuentemente o(!iado% aunque tiene impacto fuerte tanto en el tiempo de procesamiento como en el esfuer'o de programacin. 2picamente se recomienda mane$ar el error en el ni!el que lo descu(ri% si esto no es posi(le% de$ar que lo resuel!a la capa m&s arri(a% pero generalmente

a(stra"endo el tipo de error para que sea comprensi(le en t)rmino de los ser!icios de la capa superior. 2odo patrn tiene !enta$as " des!enta$as: en el caso de la arquitectura de capas "a las #emos mencionado ?de$ar que los estudiantes las resuman@: 1enta$as o Reutili'acin de capas. o Gacilita la estandari'acin o ,ependencias se limitan a intra:capa o Contencin de cam(ios a una o pocas capas ,es!enta$as o * !eces no se logra la contencin del cam(io " se requiere una cascada de cam(ios en !arias capas. o P)rdida de eficiencia. o 2ra(a$o innecesario por parte de capas m&s internas o redundante entre !arias capas. o ,ificultad de dise0ar correctamente la granularidad de las capas. E6isten tres propuestas de arquitecturas de capas para Sistemas de Informacin% donde las capas a !eces reci(en el nom(re de ni!eles 3en Ingl)s tiers-: *rquitectura de dos capas. *rquitectura de tres capas. *rquitectura de cuatro capas. Dos capas En la actualidad muc#os sistemas de informacin est&n (asados en arquitecturas de dos capas% denominadas: 5i!el de aplicacin. 5i!el de la (ase de datos. E6isten #erramientas de amplio uso que presuponen esta estructura 3p. e$. 1isual +asic 8 *ccess=SEL ser!er-. Estas arquitecturas fueron las primeras en apro!ec#arse de la estructura cliente:ser!idor 3aplicacin en los clientes% (ase de datos como ser!idor-. Las des!enta$as de dos ni!eles son (ien conocidas: El ni!el de las aplicaciones se recargan% entreme'clando aspectos tpicos del mane$o de la interfa' con las reglas del negocio. Las reglas del negocio quedan dispersas entre el ni!el de aplicacin " los Astored proceduresA de la (ase de datos. La aplicacin queda so(recargada de informacin de (a$o ni!el si #a" que e6traer los datos de !arias (ases de datos% posi(lemente con estructuras diferentes. El ni!el de aplicacin puede ser demasiado pesado para el cliente. Tres capas

Por estas ra'ones% e6iste una fuerte " (ien a!an'ada tendencia a adoptar una arquitectura de tres capas: *plicacin ?o$oH@ ,ominio de la aplicacin. Repositorio. La ma"ora de estos sistemas (uscan conser!ar la tecnologa de +, relacional para la capa del repositorio e introducir la tecnologa 44 para el dominio de la aplicacin. Para la capa de presentacin e6iste una pelea entre tecnologa I2ML 3Ja!a:ena(led- !s. generadores K/I. <Eu) contiene el dominio de la aplicacin> En terminologa m&s cl&sica de +, los tres ni!eles pueden equipararse% a grosso modo, con: Esquema e6terno. Esquema conceptual. Esquema interno o de almacenamiento. La !enta$a es que a#ora la aplicacin puede descri(irse nicamente en relacin a la sem&ntica de la aplicacin% sin tener que preocuparse so(re cmo est& implementado ese dominio 3u(icacin " estructura fsica de la data-. LLLL/n punto interesante es dnde u(icar el ni!el del dominio de la aplicacin% <en el lado del cliente o en el lado del ser!idor> Ia" !enta$as " des!enta$as asociadas con cada alternati!a% al estudiante interesado le recomiendo el e6celente an&lisis del Go ler 3seccin 79.9.7% !p. 9B;:9BC-. Cuatro capas Los desarrollos m&s recientes empie'an a e6perimentar con una capa adicional 3para 9MMM no #a(a !isto e!idencia de esto en 1ene'uela-: Presentacin. *plicacin. ,ominio de la aplicacin. Repositorio La idea (&sica es separar todo lo que es programacin K/I de la aplicacin per se 3" por ende tiende a usar framewor"s para #$% como MGC-. El ni!el de la presentacin no #ace c&lculos% consultas o actuali'aciones so(re el dominio ::de #ec#o nisiquiera tiene !isi(ilidad so(re la capa del dominio. La capa de la aplicacin es la encargada de accesar la capa del dominio% simplificar la informacin del dominio con!irti)ndolo a los tipos de datos que entiende la interfa': enteros% reales% cadenas de caracteres% fec#a " clases contenedoras 3container, collection-. /na forma de organi'ar esta nue!a capa de la aplicacin es considerarla una fac ada al dominio. Cada aplicacin presenta una fac#ada diferente 3" simpledel dominio a la interfa'. Las !enta$as de las cuatro capas se encuentra

nue!amente en el te6to de Go ler3seccin 79.;.7% !p. 9BN:9CM-. En la seccin siguiente del mismo te6to se argumenta que el patrn &rox' puede aplicarse a la capa de la aplicacin% de forma de tener una parte de la capa en el cliente " otra en el ser!idor. Los detalles pueden consultarse all. Ginalmente resulta interesante discutir el acoplamiento entre la capa del dominio " la capa del repositorio. Por falta de tiempo% prefiero posponer este acoplamiento #asta la pr6ima clase. (((,e #ec#o% en el li(ro de Larman el diagrama de clases que se presenta como parte del modelo conceptual es el diagrama conceptual del dominio de la aplicacin.