¿Qué es arquitectura de software?

 Escribir sobre arquitectura de software, que destila la experiencia de muchas personas, presupone que:

1. Tener una arquitectura de software razonable es importante para el desarrollo exitoso de un sistema de software, y
2. Existe un cuerpo de conocimiento suficiente sobre arquitectura de software para llenar un libro.

Hubo un tiempo en el que ambas suposiciones necesitaban ser justificadas. Hoy en día, parece haber poca controversia sobre ambos objetivos..

El principio básico de la arquitectura de software es que todo sistema de software se construye para satisfacer los objetivos empresariales de una organización, y que la arquitectura de un sistema es un puente entre esos objetivos (a menudo abstractos) y el sistema final (concreto) resultante. Aunque el camino de los objetivos abstractos a los sistemas concretos puede ser complejo, la buena noticia es que las arquitecturas de software pueden diseñarse, analizarse y documentarse utilizando técnicas conocidas que apoyan el logro de estos objetivos empresariales. La complejidad puede ser domada y hecha manejable.

Qué es y qué no es la arquitectura de software

Existen muchas definiciones de arquitectura de software, fácilmente accesibles con una búsqueda en la web, pero la que más nos gusta es esta:

La arquitectura de software de un sistema es el conjunto de estructuras necesarias para razonar sobre el sistema. Estas estructuras comprenden elementos de software, relaciones entre ellos y propiedades de ambos.

Esta definición contrasta con otras que mencionan las decisiones "tempranas", "principales" o "importantes" del sistema. Si bien es cierto que muchas decisiones arquitectónicas se toman temprano en el proceso, no todas lo son, especialmente en proyectos con desarrollo ágil o en espiral. También es cierto que muchas decisiones tomadas al inicio no son lo que consideraríamos arquitectónicas. Además, no siempre es fácil determinar si una decisión es "principal". A veces, solo el tiempo lo revela. Y dado que decidir sobre una arquitectura es una de las responsabilidades más importantes del arquitecto, necesitamos saber cuáles decisiones forman parte de una arquitectura.

En cambio, las estructuras son relativamente fáciles de identificar en el software y constituyen una herramienta poderosa para el diseño y análisis del sistema.

Así que aquí estamos: la arquitectura trata de estructuras que permiten razonar.

Veamos algunas de las implicaciones de nuestra definición.

La arquitectura es un conjunto de estructuras de software

Esta es la primera y más obvia implicación de nuestra definición. Una estructura es, simplemente, un conjunto de elementos unidos por una relación. Los sistemas de software están compuestos por muchas estructuras, y ninguna de ellas puede reclamar ser la arquitectura. Las estructuras pueden agruparse en categorías, y estas categorías proporcionan maneras útiles de conceptualizar la arquitectura. Las estructuras arquitectónicas pueden organizarse en tres categorías útiles, que desempeñarán un papel importante en el diseño, documentación y análisis de arquitecturas:

1. Estructuras de componentes y conectores
2. Estructuras de módulos
3. Estructuras de asignación

Aunque el software contiene un suministro casi interminable de estructuras, no todas son arquitectónicas. Por ejemplo, el conjunto de líneas de código fuente que contienen la letra “z”, ordenadas por longitud de menor a mayor, es una estructura de software. Pero no es una muy interesante, ni tampoco arquitectónica.

Una estructura es arquitectónica si apoya el razonamiento sobre el sistema y sus propiedades. Este razonamiento debe centrarse en un atributo del sistema que sea importante para algunos de los interesados. Estos atributos incluyen propiedades como:

• La funcionalidad que el sistema logra,
• La capacidad del sistema para seguir funcionando de manera útil frente a fallos o intentos de ataque,
• La facilidad o dificultad de realizar cambios específicos en el sistema,
• La capacidad del sistema para responder a solicitudes de los usuarios,
• Y muchas más.

Por lo tanto, el conjunto de estructuras arquitectónicas no está fijado ni es limitado. Lo que se considera arquitectónico depende de lo que sea útil para razonar en tu contexto y para tu sistema.

La arquitectura es una abstracción

Dado que la arquitectura consiste en estructuras, y las estructuras se componen de elementos y relaciones, se deduce que una arquitectura incluye los elementos de software y cómo estos se relacionan entre sí. Esto significa que la arquitectura omite, de manera específica e intencionada, cierta información sobre los elementos que no es útil para razonar sobre el sistema. Por lo tanto, una arquitectura es, ante todo, una abstracción de un sistema que selecciona ciertos detalles y suprime otros.

En todos los sistemas modernos, los elementos interactúan entre sí a través de interfaces que dividen los detalles de un elemento en partes públicas y privadas. La arquitectura se ocupa del lado público de esta división; los detalles privados de los elementos—aquellos relacionados exclusivamente con la implementación interna—no son considerados arquitectónicos.

Esta abstracción es esencial para manejar la complejidad de una arquitectura: simplemente no podemos, ni queremos, lidiar con toda la complejidad todo el tiempo. Queremos—y necesitamos—que la comprensión de la arquitectura de un sistema sea varios órdenes de magnitud más sencilla que entender cada detalle de ese sistema.

No puedes retener todos los detalles de un sistema, incluso de tamaño modesto, en tu mente; el propósito de la arquitectura es hacer que no sea necesario hacerlo.

Arquitectura versus diseño

La arquitectura es diseño, pero no todo diseño es arquitectura. Es decir, muchas decisiones de diseño no están determinadas por la arquitectura—ya que, después de todo, esta es una abstracción—y dependen del criterio y buen juicio de los diseñadores posteriores e incluso de los implementadores.

Todo sistema de software tiene una arquitectura de software

Todo sistema tiene una arquitectura, porque todo sistema tiene elementos y relaciones. Sin embargo, esto no significa que la arquitectura sea conocida por alguien. Tal vez todas las personas que diseñaron el sistema se hayan ido hace tiempo, la documentación se haya perdido (o nunca se haya producido), el código fuente haya desaparecido (o nunca se haya entregado) y todo lo que tengamos a mano sea el código binario en ejecución.

Esto revela la diferencia entre la arquitectura de un sistema y la representación de esa arquitectura. Dado que una arquitectura puede existir de manera independiente de su descripción o especificación, esto destaca la importancia de la documentación de la arquitectura.

No todas las arquitecturas son buenas arquitecturas

Nuestra definición es neutral respecto a si la arquitectura de un sistema es buena o mala. Una arquitectura puede tanto apoyar como dificultar el cumplimiento de los requisitos importantes de un sistema.

Asumiendo que no aceptamos el ensayo y error como la mejor manera de elegir una arquitectura para un sistema—es decir, seleccionar una arquitectura al azar, construir el sistema a partir de ella y luego modificarla improvisadamente con la esperanza de obtener buenos resultados—esto resalta la importancia del diseño de arquitectura y de la evaluación de arquitectura.

La arquitectura incluye el comportamiento

El comportamiento de cada elemento forma parte de la arquitectura en la medida en que este comportamiento pueda ayudarte a razonar sobre el sistema. El comportamiento de los elementos refleja cómo interactúan entre sí y con el entorno. Esto claramente está incluido en nuestra definición de arquitectura y tiene un impacto en las propiedades que exhibe el sistema, como su rendimiento en tiempo de ejecución.

Algunos aspectos del comportamiento están por debajo del nivel de preocupación del arquitecto. Sin embargo, en la medida en que el comportamiento de un elemento influya en la aceptabilidad del sistema en su conjunto, este comportamiento debe considerarse parte del diseño arquitectónico del sistema y documentarse como tal.

Arquitecturas de sistemas y de empresas

Dos disciplinas relacionadas con la arquitectura de software son la arquitectura de sistemas y la arquitectura empresarial. Ambas tienen preocupaciones más amplias que el software y afectan a la arquitectura de software mediante el establecimiento de restricciones dentro de las cuales un sistema de software, y su arquitecto, deben operar.

Arquitectura de sistemas

La arquitectura de un sistema es una representación del sistema en la que hay un mapeo de la funcionalidad en componentes de hardware y software, un mapeo de la arquitectura de software en la arquitectura de hardware, y una consideración de la interacción humana con estos componentes. Es decir, la arquitectura de sistemas se ocupa de la totalidad del hardware, el software y los humanos.

Por ejemplo, la arquitectura de sistemas influirá en:

• La funcionalidad asignada a diferentes procesadores,
• Los tipos de redes que conectan esos procesadores.

La arquitectura de software determinará cómo se estructura esta funcionalidad y cómo interactúan los programas de software que residen en los distintos procesadores.

Una descripción de la arquitectura de software, mapeada a los componentes de hardware y redes, permite razonar sobre cualidades como el rendimiento y la confiabilidad. Una descripción de la arquitectura de sistemas permitirá razonar sobre cualidades adicionales como:

• Consumo de energía,
• Peso,
• Dimensiones físicas.

Al diseñar un sistema en particular, es común que haya una negociación entre el arquitecto de sistemas y el arquitecto de software sobre la distribución de la funcionalidad y, en consecuencia, las restricciones impuestas a la arquitectura de software.