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