Directriz: Capas
Esta directriz presenta las estrategias para dividir un sistema en capas.
Relaciones
Elementos relacionados
Descripción principal

Directrices de capas

Las capas proporcionan una partición lógica de los subsistemas en una serie de conjuntos, con ciertas reglas como por ejemplo, cómo se pueden formar relaciones entre capas. Las capas proporcionan un modo de restringir las dependencias entre subsistemas, con el resultado que el sistema se acopla más holgadamente y, por lo tanto, se mantiene más fácilmente.

Los criterios para agrupar subsistemas siguen unos cuantos patrones:

  • Visibilidad. Los subsistemas sólo pueden depender de subsistemas de la misma capa y de la capa inferior siguiente.
  • Volatilidad.
    • En las capas más altas, coloque elementos que varíen cuando cambien los requisitos de los usuarios.
    • En las capas más bajas, coloque elementos que varíen cuando la plataforma de implementación (hardware, lenguaje, sistema operativo, base de datos, etc.) cambie.
    • En medio, coloque elementos que sean generalmente aplicables a través de amplios gamas de sistemas y entornos de implementación.
    • Añada capas cuando particiones adicionales dentro de estas amplias categorías ayuden a organizar el modelo.
  • Generalidad. Los elementos de modelo abstracto tienden a colocarse en la parte inferior del modelo. Si no es específico de la implementación, tienden a gravitar hacia las capas intermedias.
  • Número de capas. Para sistemas pequeños, son suficientes tres capas. Para sistemas complejos, suelen ser suficientes 5-7 capas. Para cualquier grado de complejidad, más de 10 capas se deben visualizar con la sospecha de que aumenten con el número de capas. A continuación se presentan algunas normas generales:

Número de clases

Número de capas

0 - 10

No son necesarias las capas

10 - 50

2 capas

25 - 150

3 capas

100 - 1000

4 capas

Los subsistemas y paquetes dentro de una capa concreta sólo deben depender de los subsistemas dentro de la misma capa, y la capa inferior siguiente. Si no se pueden restringir las dependencias de este modo se produce la degradación arquitectónica y el sistema es frágil y difícil de mantener.

Las excepciones incluyen casos donde los subsistemas necesitan acceso directo a servicios de capas inferiores: debe tomarse una decisión consciente sobre cómo manejar los servicios primitivos necesarios a través del sistema, como la impresión, enviar mensajes, etc. No tiene demasiado valor restringir los mensajes a capas inferiores si la solución es implementar el paso a través efectivo de una llamada en las capas intermedias.

Patrones de partición

Dentro de las capas superiores del sistema, la partición adicional puede ayudar a organizar el modelo. Las directrices siguientes para la partición presentan diferentes cuestiones a tener en cuenta:

  • Organización del usuario. Los subsistemas se pueden organizar en líneas que reflejan la organización de la funcionalidad en la organización de la empresa (por ej., la partición ocurre a lo largo de las líneas departamentales). Esta partición a menudo ocurre en un estadio temprano del diseño porque un modelo de empresa existente tiene una estructura fuertemente partida organizativamente. Este patrón de organización habitualmente afecta sólo las pocas capas superiores de servicios específicos de la aplicación, y a menudo desaparece a medida que el diseño evoluciona.
    • La partición de las líneas de organización del usuario puede ser un punto de partida interesante para el modelo.
    • La estructura de la organización de usuario no es estable durante un periodo de tiempo prolongado (debido a la reorganización empresarial) y no es una buena base a largo plazo para la partición del sistema. La organización interna del sistema debe permitir que el sistema evolucione y se mantenga independientemente de la organización de la empresa a la que da soporte.
  • Áreas de competencia y/o habilidades. Los subsistemas se pueden organizar para partir las responsabilidades de los componentes del modelo entre diferentes grupos de la organización de desarrollo. Habitualmente, esto se produce en las capas medias e inferiores del sistema, y refleja la necesidad de especialización en habilidades durante el desarrollo y soporte de tecnología de infraestructura compleja. Ejemplos de tales tecnologías incluyen la gestión de la red y la distribución, la gestión de la base de datos, la gestión de la comunicación y el control del proceso, entre otros. La partición a lo largo de las líneas de competencia también puede ocurrir en las capas superiores, donde es necesaria una competencia especial en el dominio del problema para comprender y dar soporte a la funcionalidad clave del negocio; los ejemplos incluyen la gestión de llamadas de telecomunicaciones, comercio de valores, procesamiento de reclamaciones de seguros y control del tráfico aéreo, para mencionar unos cuantos.
  • Distribución del sistema. Dentro de cualquiera de las capas del sistema, las capas se pueden partir, a su vez, "horizontalmente" para reflejar la distribución física de la funcionalidad.
    • Crear particiones para reflejar la distribución puede ayudar a visualizar la comunicación de red que ocurrirá a medida que se ejecuta el sistema.
    • La partición para reflejar la distribución puede, sin embargo, dificultar los cambios del sistema si el modelo de despliegue cambia significativamente.
  • Áreas de privacidad. Algunas aplicaciones, especialmente las que requieren permisos de seguridad para desarrollar y/o dar soporte, requieren particiones adicionales junto con las líneas de privilegio de acceso de seguridad. El software que controla el acceso a las áreas de privacidad lo debe desarrollar y mantener personal con la autorización apropiada. Si el número de personas con este conocimiento del proyecto es limitado, la funcionalidad que requiere permisos especiales debe ser partida en subsistemas que se desarrollarán independientemente de otros subsistemas, y las interfaces de las áreas de privacidad serán el único aspecto visible de estos subsistemas.
  • Áreas de variabilidad. La funcionalidad que es probable que sea opcional, y por lo tanto se entrega sólo en algunas variantes del sistema, se debe organizar en subsistemas independientes que se desarrollan y se entregan independientemente de la funcionalidad obligatoria del sistema.