4.4 Diseño para sistemas distribuidos

En todas las aplicaciones, salvo en las más pequeñas, el primer paso para diseñar un sistema consiste en dividir el sistema en un pequeño número de componentes. Cada uno de los componentes principales de un sistema se llama subsistema. Cada subsistema abarca aspectos del sistema que comparten alguna propiedad común.

Un subsistema no es ni una funcion ni un objeto, sino un paquete de clases, asociaciones, operaciones, sucesos y restricciones interrelacionados, y que tienen una interfaz razonablemente bien definida y pequeña con los demás subsistemas. Normalmente, un subsistema se identifica por los servicioes que proporciona. Un sevicio es un grupo de funciones relacionadas que comparten algún propósito común, tal como el procesamiento de entrada-salida, dibujar imaneges o efectuar cálculos aritméticos. Un subsistema define una forma coherente de examinar un aspecto del problema.

Cada subsistema posee una interfaz bien definida con el resto del sistema. Ésta especifica la forma de todas las interacciones y el flujo de informacion entre los limites de subsistemas, pero no especifica cómo está implementado internamente el subsistema. Cada subsistema se puede diseñar, entonces, independientemente, sin afectar a los demás.

Los subsistemas deberían definirse de tal manera que la mayoría de las interacciones se produzcan dentro de y no entre los limites de distintos subsistemas, con objeto de reducir las dependencias existentes entre ellos. Todo sistema debería dividirse en un pequeño número de subsistemas. Cada subsistema, a su vez, debe descomponerse en subsistemas propios aún más pequeños. Los subsistemas de más bajo nivel se denominan módulos.

La relación entre dos subsistemas puede ser cliente-proveedor o punto a punto. En las primeras, el cliente debe conocer la interfaz del proveedor, pero éste no necesita conocer las interfaces de aquellos porque todas las interacciones son iniciadas por los clientes, empleando la interfaz del proveedor. En una relación entre pares, cada subsistema puede llamar a los demás. Una comunicacion desde un subsistema hacia otro no va necesariamente seguida por una respuesta inmediata. Las interacciones entre pares son más complejas porque los subsistemas deben conocer las interfaces del otro. Hay ciclos de comunicaciones que son difíciles de entender y proclives a sutiles errores de diseño. Hay que buscar descomposiciones cliente-proveedor siempre que sea posible, porque una interacción monodireccional es mucho más fácil de construir, comprender y modificar que una interacción bidireccional.