Arquitectura en el Diseño del software

En los años 1960 ya se acercaba el concepto de arquitectura de software en los círculos de investigación (por ejemplo, por Edsger Dijkstra). No obstante, toma popularidad en los años 1990 tras reconocerse la denominada crisis del software y como tema de interés de la incipiente disciplina de la ingeniería del software.

¿Qué es arquitectura?

Es la representación que capacita al ingeniero del software para:

• Analizar la efectividad del diseño para la consecución de los requisitos fijados.
• Considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios en el diseño es relativamente fácil.
• Reducir los riesgos asociados a la construcción del software.

En el diseño arquitectónico, un componente del software puede ser tan simple como un módulo de programa, pero también puede ser algo complicado como incluir base de datos y software intermedio (middleware) que permiten la configuración de una red de clientes y servidores.

El diseño de la arquitectura del software tiene en cuenta 2 niveles de la pirámide, el diseño de datos y el diseño arquitectónico. El diseño de datos nos facilita la representación de los componentes de datos de la arquitectura. El diseño arquitectónico se centra en la representación de la estructura de los componentes del software, sus propiedades e interacciones.

¿Por qué es importante la arquitectura?

• Facilitan la comunicación entre todas las partes interesadas en el desarrollo de un sistema basado en computadora.
• Destaca decisiones tempranas de diseño que tendrán un profundo impacto en todo el trabajo de ingeniería del software.
• Constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes.

Arquitecturas más comunes

Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:

Descomposición Modular. Donde el software se estructura en grupos funcionales muy acoplados.

Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones.

Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). 

Una capa solamente tiene relación con la siguiente.

Otras arquitecturas afines menos conocidas son:

• Modelo Vista Controlador.
• En pipeline.

Entre pares.

• En pizarra.
• Orientada a servicios.
• Dirigida por eventos.
• Máquinas virtuales

Modelos o vistas

Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.

Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:

• La visión estática: describe qué componentes tiene la arquitectura.
• La visión funcional: describe qué hace cada componente.
• La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí.

Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. 

El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista. 

Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible).