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 software que tiene que ver con las interfaces y la interaccin con los diferentes tipos de usuarios humanos Estos aspectos tpicamente incluyen el manejo y aspecto de las ventanas, el formato de los reportes, menes, grficos y elementos multimedia en general. La capa del Dominio de la Aplicacin Esta capa rene todos los aspectos del software que tienen que automatizan o apoyan los procesos de negocio que llevan a cabo los usuarios. Estos aspectos tpicamente incluyen las tareas que forman parte de los procesos, las reglas y restricciones que aplican. Esta capa tambin recibe el nombre de la capa de la Lgica de la Aplicacin. La capa del Repositorio Esta capa rene todos los aspectos del software que tienen que ver con el manejo de los datos persistentes, por lo que tambin se le denomina la capa de las Bases de Datos).

RPM toca muy superficialmente los problemas asociados al desarrollo de una capa de Presentacin. Menciona que es conveniente usar un enfoque de prototipaje y que pueden ser tiles los casos reales de uso; sin embargo no proporciona mtodos, principios o lineamientos metodolgicos que apoyen el desarrollo de una metfora de diseo para la interfaz, el diseo lgico de la presentacin o su diseo fsico. RPM tampoco proporciona muchas luces sobre el desarrollo de la capa del Repositorio y tiende a subestimar su complejidad. Una vez elaborado el Modelo de Uso, RPM recomiendo seguir con actividades de anlisis de requerimientos. Para ello se elabora un Modelo Conceptual, en el cual se busca identificar los conceptos importantes del dominio de la aplicacin, abstrayendo todo lo que puedan ser mecanismos o conceptos propios de un diseo o de una implementacin. As, en el ejemplo de un Sistema de Punto de Venta, nos interesan los conceptos como Venta, Recibo, Efectivo, Cheque, Impuesto que tienen que ver con los procesos de negocio que se estn apoyando y no nos interesan conceptos como Men, Ventana,

Tabla relacional, Consulta a Base de Datos que tienen que ver con cmo mejor implementar los conceptos del negocio. La mayora de estos elementos de un Modelo Conceptual terminan agrupndose naturalmente en la capa del Dominio de la Aplicacin. Este enfoque de RPM termina por sesgar la metodologa hacia el desarrollo de la capa del Dominio de la Aplicacin, y en la prctica, tiende a hacer presuponer que el desarrollo de las otras capas se puede ajustar al diseo de la capa del Dominio de Aplicacin, lo cual no es siempre el caso, incluso dentro del mbito de los Sistemas de Informacin. Antes de estudiar el Modelo Conceptual, nos conviene aclarar qu es una arquitectura de capas, su importancia e implicaciones, para tener mayor claridad en los riesgos que corremos al adoptar una metodologa como RPM.

Arquitectura de Capas
Preguntar qu conocen por arquitectura de capas (en Sistemas de Operacin, Redes de Computadores...). Nos limitaremos a manejar la nocin de arquitectura como una forma de estructurar los elementos de un software. En toda arquitectura de capa los elementos agrupados en una misma capa pueden comunicarse entre si; pero existen variantes en cuanto a las comunicaciones permitidas entre elementos de capas diferentes: 1. Arquitectura top-down de capas: Los elementos de una capa i+1 pueden enviar solicitudes de servicio a elementos de la capa inferior i. Tpicamente se produce una cascada de solicitudes, es decir para satisfacer una solicitud a una capa i+2, sta requiere enviar varias solicitudes a la capa i+1; cada una de estas solicitudes a la capa i+1 genera a su vez un conjunto de solicitudes a la capa i y as sucesivamente. Una arquitectura top-down es laxa (o no estricta) si los elementos de una capa i+1 pueden enviar solicitudes de servicio directamente a un elemento de cualquiera de las i capas inferiores. 2. Arquitectura bottom-up de capas: Cada elemento de una capa i puede notificar a elementos de la capa superior i+1 de que ha ocurrido algn evento de inters (ej. manejadores de dispositivos). La capa i+1 puede juntar varios eventos antes de notificar a su vez an elemento de la capa i+2. Una arquitectura bottomup tambien puede ser no estricta si el elemento de la capa i puede notificar a cualquier elemento de cualquier capa superior a la capa i. 3. Arquitectura bidireccional de capas En su forma ms comn involucra dos pilas de N capas que se comunican entre si. El ejemplo ms conocido es el de los protocolos en Redes de Computadores.

Al implementar una arquitectura top-down de capas, se deben tomar en cuenta los siguientes factores: 1. Cul es el criterio de abstraccin para agrupar servicios/clases en una capa? Mencionar el criterio Presentacin-Dominio de Aplicacin-Repositorio de Sistemas de Informacin. 2. Determinar el nmero de capas En trminos simplistas, a ms capas ms flexibilidad pero menor desempeo. [Discutir] 3. Tpicamente las capas ms internas ofrecen menos servicios. Esto ayuda la reutilizacin de capas ("pirmide invertida de reuso"). 4. El grado de encapsulamiento de las capas. A mayor encapsulamiento, menor dependencia externa sobre la estructura de una capa. 5. Estructura interna de cada capa. 6. Cunta informacin pasar de una capa a otra? Tomemos el caso de la arquitectura top-down. Es muy posible que, de acuerdo con el tipo de servicio solicitado, la capa inferior requiera una cantidad de informacin variable. En un modelo puro "empujado" (push), la capa superior est obligada a enviarle toda la informacin que pueda llegar a hacerle falta a la capa inferior en la solicitud. Esto no siempre es posible (piense por ejemplo en una solicitud de servicio a una base de datos que no logra completarse por estar fuera de lnea. Qu se hace: reintentar, abandonar, usar una fuente alterna?). En el modelo contrario, "halado" (pull o por demanda), la capa inferior solicita mayor informacin slo si le hace falta --pero de quin la pida? El modelo de solicitudes top-down presupone un invocador annimo y un invocado conocido. La solucin la proporciona el patrn Editorial-Suscriptor (PublishSubscribe) que encapsula la idea del callback. Este patrn de diseo lo estudiaremos ms adelante. 7. Disee la estrategia de manejo de errores. Este es un aspecto que es frecuentemente obviado, aunque tiene impacto fuerte tanto en el tiempo de procesamiento como en el esfuerzo de programacin. Tpicamente se recomienda manejar el error en el nivel que lo descubri, si esto no es posible, dejar que lo resuelva la capa ms arriba, pero generalmente

abstrayendo el tipo de error para que sea comprensible en trmino de los servicios de la capa superior. Todo patrn tiene ventajas y desventajas: en el caso de la arquitectura de capas ya las hemos mencionado [dejar que los estudiantes las resuman]:

Ventajas o Reutilizacin de capas; o Facilita la estandarizacin o Dependencias se limitan a intra-capa o Contencin de cambios a una o pocas capas Desventajas o A veces no se logra la contencin del cambio y se requiere una cascada de cambios en varias capas; o Prdida de eficiencia; o Trabajo innecesario por parte de capas ms internas o redundante entre varias capas; o Dificultad de disear correctamente la granularidad de las capas.

Existen tres propuestas de arquitecturas de capas para Sistemas de Informacin, donde las capas a veces reciben el nombre de niveles (en Ingls tiers):

Arquitectura de dos capas; Arquitectura de tres capas; Arquitectura de cuatro capas.

Dos capas En la actualidad muchos sistemas de informacin estn basados en arquitecturas de dos capas, denominadas:

Nivel de aplicacin; Nivel de la base de datos.

Existen herramientas de amplio uso que presuponen esta estructura (p. ej. Visual Basic + Access/SQL server). Estas arquitecturas fueron las primeras en aprovecharse de la estructura cliente-servidor (aplicacin en los clientes, base de datos como servidor). Las desventajas de dos niveles son bien conocidas:

El nivel de las aplicaciones se recargan, entremezclando aspectos tpicos del manejo de la interfaz con las reglas del negocio; Las reglas del negocio quedan dispersas entre el nivel de aplicacin y los "stored procedures" de la base de datos; La aplicacin queda sobrecargada de informacin de bajo nivel si hay que extraer los datos de varias bases de datos, posiblemente con estructuras diferentes.

El nivel de aplicacin puede ser demasiado pesado para el cliente.

Tres capas Por estas razones, existe una fuerte y bien avanzada tendencia a adoptar una arquitectura de tres capas:

Aplicacin [ojo!] Dominio de la aplicacin; Repositorio.

La mayora de estos sistemas buscan conservar la tecnologa de BD relacional para la capa del repositorio e introducir la tecnologa OO para el dominio de la aplicacin. Para la capa de presentacin existe una pelea entre tecnologa HTML (Java-enabled) vs. generadores GUI. Qu contiene el dominio de la aplicacin? En terminologa ms clsica de BD los tres niveles pueden equipararse, a grosso modo, con:

Esquema externo; Esquema conceptual; Esquema interno o de almacenamiento.

La ventaja es que ahora la aplicacin puede describirse nicamente en relacin a la semntica de la aplicacin, sin tener que preocuparse sobre cmo est implementado ese dominio (ubicacin y estructura fsica de la data). ****Un punto interesante es dnde ubicar el nivel del dominio de la aplicacin, en el lado del cliente o en el lado del servidor? Hay ventajas y desventajas asociadas con cada alternativa, al estudiante interesado le recomiendo el excelente anlisis del Fowler (seccin 12.2.1, vp. 243-245). Cuatro capas Los desarrollos ms recientes empiezan a experimentar con una capa adicional (para 2000 no haba visto evidencia de esto en Venezuela):

Presentacin; Aplicacin; Dominio de la aplicacin; Repositorio

La idea bsica es separar todo lo que es programacin GUI de la aplicacin per se (y por ende tiende a usar frameworks para GUI como MFC). El nivel de la presentacin no hace clculos, consultas o actualizaciones sobre el dominio --de hecho nisiquiera tiene visibilidad sobre la capa del dominio. La capa de la

aplicacin es la encargada de accesar la capa del dominio, simplificar la informacin del dominio convirtindolo a los tipos de datos que entiende la interfaz: enteros, reales, cadenas de caracteres, fecha y clases contenedoras (container, collection). Una forma de organizar esta nueva capa de la aplicacin es considerarla una fachada al dominio. Cada aplicacin presenta una fachada diferente (y simple) del dominio a la interfaz. Las ventajas de las cuatro capas se encuentra nuevamente en el texto de Fowler(seccin 12.3.1, vp. 249-250). En la seccin siguiente del mismo texto se argumenta que el patrn Proxy puede aplicarse a la capa de la aplicacin, de forma de tener una parte de la capa en el cliente y otra en el servidor. Los detalles pueden consultarse all. Finalmente resulta interesante discutir el acoplamiento entre la capa del dominio y la capa del repositorio. Por falta de tiempo, prefiero posponer este acoplamiento hasta la prxima clase. ***De hecho, en el libro de Larman el diagrama de clases que se presenta como parte del modelo conceptual es el diagrama conceptual del dominio de la aplicacin.