Universidad Simón Bolívar
Ingeniería de Software

Arquitectura de capas



Lecturas recomendadas

Las siguientes lecturas se recomiendan para aquellos estudiantes que tengan cierto dominio del proceso de diseño.

Buschmann, sección 2.2, vp. 31-51 es una excelente introducción a la arquitectura de capas en general  y su aplicación a los Sistemas de Información. Sin embargo, sus ejemplos presuponen un cierto conocimiento del modelo ISO/OSI de capas en la comunicación en Redes de Computadoras.

El capítulo 22 del texto de Larman, presenta también las nociones básicas de una arquitectura de capas, enfatizando las consecuencias para el caso del sistema de punto de venta. Presupone un dominio de la noción de patrones de diseño.

Fowler, (capítulo 12, vp. 239-256) presenta algunas consideraciones adicionales de las arquitecturas de capas para Sistemas de Información, que escapan del aclcance de este curso por lo que pueden considerarse una lectura suplementaria.

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: 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:

  2. 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.
     
  3. Arquitectura bottom-up de capas:

  4. 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 bottom-up 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.
     
  5. Arquitectura bidireccional de capas

  6. 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?

  2. Mencionar el criterio Presentación-Dominio de Aplicación-Repositorio de Sistemas de Información.
     
  3. Determinar el número de capas

  4. En términos simplistas, a más capas más flexibilidad pero menor desempeño. [Discutir]
     
  5. Típicamente las capas más internas ofrecen menos servicios.

  6. Esto ayuda la reutilización de capas ("pirámide invertida de reuso").
     
  7. El grado de encapsulamiento de las capas.

  8. A mayor encapsulamiento, menor dependencia externa sobre la estructura de una capa.
     
  9. Estructura interna de cada capa.

  10.  
  11. ¿Cuánta información pasar de una capa a otra?

  12. 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 (Publish-Subscribe) que encapsula la idea del callback.  Este patrón de diseño lo estudiaremos más adelante.
     

  13. Diseñe la estrategia de manejo de errores.

  14. 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]:

Arquitectura de capas en Sistemas de Información

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): Las diferencias entre estas arquitecturas las pospondremos hasta que nos corresponda estudiar el proceso de diseño de un software. Por los momentos, seguiremos RPM en presuponer que apuntamos a una arquitectura de tres capas.

Esta página fue creada por el Prof. Alejandro Teruel el 15 de septiembre de 2000.
Ultima actualización: 21 de mayo de 2001.
Por favor dirija sus comentarios al Prof. Alejandro Teruel.