Arquitectura de capas en Sistemas de Información

Arquitectura de capas en Sistemas
de Información
Introducción
La metodología RPM presentada por C. Larman presupone una estructura de
tres capas que es típica de los Sistemas de Información. Estas tres capas son:

La capa de la Presentación
Esta capa reúne todos los aspectos del software que tiene que ver con
las interfaces y la interacción con los diferentes tipos de usuarios
humanos Estos aspectos típicamente incluyen el manejo y aspecto de
las ventanas, el formato de los reportes, menúes, gráficos y elementos
multimedia en general.

La capa del Dominio de la Aplicación
Esta capa reúne todos los aspectos del software que tienen que
automatizan o apoyan los procesos de negocio que llevan a cabo los
usuarios. Estos aspectos típicamente incluyen las tareas que forman
parte de los procesos, las reglas y restricciones que aplican. Esta capa
también recibe el nombre de la capa de la Lógica de la Aplicación.

La capa del Repositorio
Esta capa reúne todos los aspectos del software que tienen que ver con
el manejo de los datos persistentes, por lo que también se le denomina
la capa de las Bases de Datos).
RPM toca muy superficialmente los problemas asociados al desarrollo de una
capa de Presentación. Menciona que es conveniente usar un enfoque de
prototipaje y que pueden ser útiles los casos reales de uso; sin embargo no
proporciona métodos, principios o lineamientos metodológicos que apoyen el
desarrollo de una metáfora de diseño para la interfaz, el diseño lógico de la
presentación o su diseño físico.
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 análisis de requerimientos. Para ello se elabora un Modelo Conceptual, en
el cual se busca identificar los conceptos importantes del dominio de la
aplicación, abstrayendo todo lo que puedan ser mecanismos o conceptos
propios de un diseño o de una implementación. 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 están apoyando y no nos interesan conceptos como Menú, Ventana,
Tabla relacional, Consulta a Base de Datos que tienen que ver con cómo mejor
implementar los conceptos del negocio. La mayoría de estos elementos de un
Modelo Conceptual terminan agrupándose naturalmente en la capa del
Dominio de la Aplicación.
Este enfoque de RPM termina por sesgar la metodología hacia el desarrollo de
la capa del Dominio de la Aplicación, y en la práctica, tiende a hacer
presuponer que el desarrollo de las otras capas se puede ajustar al diseño de
la capa del Dominio de Aplicación, lo cual no es siempre el caso, incluso dentro
del ámbito de los Sistemas de Información.
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 metodología como RPM.
Arquitectura de Capas



Preguntar qué conocen por arquitectura de capas (en Sistemas de
Operación, Redes de Computadores...).
Nos limitaremos a manejar la noción 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. Típicamente 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 algún evento de interés (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 más común involucra dos pilas de N capas que se
comunican entre si. El ejemplo más 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. ¿Cuál es el criterio de abstracción para agrupar servicios/clases en una
capa?
Mencionar el criterio Presentación-Dominio de Aplicación-Repositorio de
Sistemas de Información.
2. Determinar el número de capas
En términos simplistas, a más capas más flexibilidad pero menor
desempeño. [Discutir]
3. Típicamente las capas más internas ofrecen menos servicios.
Esto ayuda la reutilización de capas ("pirámide 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. ¿Cuánta información 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 información variable. En un modelo puro "empujado" (push),
la capa superior está obligada a enviarle toda la información 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 línea. ¿Qué se hace: reintentar, abandonar, usar una fuente
alterna?).
En el modelo contrario, "halado" (pull o por demanda), la capa inferior
solicita mayor información sólo si le hace falta --¿pero de quién la pida?
El modelo de solicitudes top-down presupone un invocador anónimo y
un invocado conocido.
La solución la proporciona el patrón Editorial-Suscriptor (PublishSubscribe) que encapsula la idea del callback. Este patrón de diseño lo
estudiaremos más adelante.
7. Diseñe 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 programación. Típicamente se
recomienda manejar el error en el nivel que lo descubrió, si esto no es
posible, dejar que lo resuelva la capa más arriba, pero generalmente
abstrayendo el tipo de error para que sea comprensible en término de
los servicios de la capa superior.
Todo patrón tiene ventajas y desventajas: en el caso de la arquitectura de
capas ya las hemos mencionado [dejar que los estudiantes las resuman]:


Ventajas
o Reutilización de capas;
o Facilita la estandarización
o Dependencias se limitan a intra-capa
o Contención de cambios a una o pocas capas
Desventajas
o A veces no se logra la contención del cambio y se requiere una
cascada de cambios en varias capas;
o Pérdida de eficiencia;
o Trabajo innecesario por parte de capas más internas o
redundante entre varias capas;
o Dificultad de diseñar correctamente la granularidad de las capas.
Existen tres propuestas de arquitecturas de capas para Sistemas de
Información, donde las capas a veces reciben el nombre de niveles (en Inglés
tiers):



Arquitectura de dos capas;
Arquitectura de tres capas;
Arquitectura de cuatro capas.
Dos capas
En la actualidad muchos sistemas de información están basados en
arquitecturas de dos capas, denominadas:


Nivel de aplicación;
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 (aplicación 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
típicos del manejo de la interfaz con las reglas del negocio;
Las reglas del negocio quedan dispersas entre el nivel de aplicación y
los "stored procedures" de la base de datos;


La aplicación queda sobrecargada de información de bajo nivel si hay
que extraer los datos de varias bases de datos, posiblemente con
estructuras diferentes.
El nivel de aplicación 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:



Aplicación [ojo!]
Dominio de la aplicación;
Repositorio.
La mayoría de estos sistemas buscan conservar la tecnología de BD relacional
para la capa del repositorio e introducir la tecnología OO para el dominio de la
aplicación. Para la capa de presentación existe una pelea entre tecnología
HTML (Java-enabled) vs. generadores GUI.
¿Qué contiene el dominio de la aplicación? En terminología más clásica 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 aplicación puede describirse únicamente en
relación a la semántica de la aplicación, sin tener que preocuparse sobre cómo
está implementado ese dominio (ubicación y estructura física de la data).
****Un punto interesante es dónde ubicar el nivel del dominio de la aplicación,
¿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 análisis del Fowler (sección 12.2.1, vp. 243-245).
Cuatro capas
Los desarrollos más recientes empiezan a experimentar con una capa adicional
(para 2000 no había visto evidencia de esto en Venezuela):




Presentación;
Aplicación;
Dominio de la aplicación;
Repositorio
La idea básica es separar todo lo que es programación GUI de la aplicación per
se (y por ende tiende a usar frameworks para GUI como MFC). El nivel de la
presentación no hace cálculos, consultas o actualizaciones sobre el dominio -de hecho nisiquiera tiene visibilidad sobre la capa del dominio. La capa de la
aplicación es la encargada de accesar la capa del dominio, simplificar la
información del dominio convirtiéndolo 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 aplicación es considerarla una
fachada al dominio. Cada aplicación 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(sección 12.3.1, vp. 249-250). En la sección
siguiente del mismo texto se argumenta que el patrón Proxy puede aplicarse a
la capa de la aplicación, 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 próxima 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
aplicación.