Qué es la arquitectura de software

Todo el mundo tiene una clara imagen mental cuando hablamos de arquitectura de aquella disciplina que se encarga de la planificación y diseño para la construcción de edificios y espacios de esparcimiento (como parques o monumentos), sin embargo, la arquitectura es referida al diseño y planificación a un nivel superior de una estructura a un nivel abstracto y a la toma de decisiones antes de pasar a su realización.

La arquitectura, referida al software, es un concepto que surge ya en los años 60 y se refiere a una planificación basada en modelos, patrones y abstracciones teóricas, a la hora de realizar una pieza de software de cierta complejidad y como paso previo a cualquier implementación. De esta forma se dispone de una guía teórica detallada que nos permite entender cómo van a encajar cada una de las piezas de nuestro producto o servicio.

Por tanto, en arquitectura llamamos patrón a cualquier solución general y reutilizable para problemas recurrentes en ingeniería del software en un contexto dado, son similares a los patrones usados en la programación, pero orientados específicamente a la estructura a un nivel superior y más genérico.

Importancia de la arquitectura de software

La arquitectura nos permite planificar a priori nuestro desarrollo y elegir el mejor conjunto de herramientas para llevar a cabo nuestros proyectos, es por tanto un paso crítico antes siquiera de pasar a programar ya que determinará en gran medida el ritmo del desarrollo e incluso los factores económicos y humanos durante el proceso. Por tanto, a la hora de elegir un patrón de arquitectura siempre es necesario pensar en una serie de cuestiones que determinan el uso final que vamos a darle a nuestro software:

• Coste – ¿Cuánto estamos dispuestos a invertir en el desarrollo y mantenimiento de nuestro sistema? Como hemos visto hay ciertos patrones más complejos, que requieren más infraestructura y cuyo desarrollo puede ser más irregular, por tanto, hemos de saber cuánto estamos dispuestos a invertir primero en el desarrollo de nuestra aplicación.
• Tiempo de desarrollo – Igualmente, y muy relacionado con lo anterior, debemos de preguntarnos cuanto tiempo disponemos para desarrollar el producto, y cómo de cerca se encontraría la fecha de entrega o de salida al mercado.
• Número de usuarios – Sin duda uno de los ítems críticos a la hora de desarrollar el producto es preguntarnos qué tipo de producto es y cuantos usuarios soporta ¿Funciona a través de web? ¿Es stand-alone? ¿Debe de soportar cargas elevadas por diseño?, estas preguntas pueden declinarnos a elegir patrones más o menos distribuidos, pasando, por ejemplo, de uno menos distribuido como el de capas al más distribuido o broker.
• Nivel de aislamiento – Otro factor importante a tener en cuenta es si nuestro producto funciona de forma aislada al resto de productos del usuario o si debe de integrarse o permitir integraciones de terceros. Algunas arquitecturas, como la de capas, son más cerradas y podrían dificultar estas integraciones si lo escogemos sobre otras.

En ocasiones, y cuando tenemos estos hechos bien planteados y razonados, elegir un patrón de arquitectura también puede ser una cuestión de familiaridad, comodidad o simple preferencia, por eso es aconsejable probarlos, para intentar también familiarizarse con ellos y con el diferente flujo de trabajo que proponen.

Patrones de arquitectura de software

Patrón cliente-servidor

El patrón cliente servidor es muy usado sobre todo en el diseño de webs y servicios online, y se basa en el concepto de la existencia de un servidor (que proporciona el servicio) y una serie de clientes, que piden al servidor y reciben una respuesta del mismo.

Ventajas

• Centralización – Todos los recursos disponibles se hayan centralizados en un único punto, lo que hace más sencillo su administración y más difícil para un cliente el uso de acciones dañinas.
• Escalabilidad – Al funcionar de manera independiente es más sencillo mejorar cada pieza de forma separada o añadir nuevos nodos a la red creada.
• Mantenimiento simplificado – Al funcionar de manera independiente y con separación clara de responsabilidades, es más sencillo mantener cada una de las piezas e incluso poder transladar con sencillez el servidor a nuevo hardware/software si fuera necesario.

Desventajas

• Disponibilidad – Al depender de un servidor para satisfacer las peticiones de los clientes se requiere que este esté activo y disponible en cada momento, una caída del servidor o incluso una congestión debido a la cantidad de peticiones de clientes resulta en una pérdida de funcionalidad absoluta del servicio.
• Requisitos – Debido a que debe satisfacer un gran número de peticiones, el software y el hardware del servidor son determinantes a la hora de usar este patrón, y usar alguno deficiente impactará negativamente en el funcionamiento de nuestro sistema.
• Distribución – El cliente no posee físicamente el producto ni tiene acceso a los recursos utilizados, cualquier caída del servidor implicará que el cliente no pueda acceder a su trabajo en curso.

Patrón de capas

En este patrón se subdivide la estructura del programa en un número de capas que representan una subtarea, cada una perteneciendo a un nivel de abstracción diferente. Cada capa está diseñada para proporcionar un servicio a la siguiente capa de mayor nivel. Generalmente se utilizan las siguientes capas:

Ventajas

• Capacidad de testeo – Al tener cada capa por separado la implementación del testing es muy elevada respecto a otros patrones, ya que es posible realizar tests sobre cada capa de manera separada.
• Facilidad de desarrollo – Debido a la alta distribución es mucho más sencillo coordinar un equipo para su desarrollo, ya que cada miembro o equipo tiene claro el objetivo de cada capa y sólo es necesario crear una interfaz clara de comunicación entre ellas.

Desventajas

• Rendimiento – Debido a que cada funcionalidad está en una capa diferente normalmente este patrón sufre de menor rendimiento que otros debido a que cualquier petición debe de atravesar de forma individual cada capa de diseño.
• Escalabilidad – Debido a que cada capa depende de la anterior y de la interfaz entre ellas, modificar un software que utilice este patrón puede ser tedioso y costoso ya que para modificar cualquiera de las capas es necesario hacer cambios en todas las anteriores, esto puede solucionarse subdividiendo las capas en módulos, pero de cualquier manera implica mayor esfuerzo respecto a otros patrones.

Patrón master-slave

Este patrón consiste en dos grupos, el primero es llamado el maestro (master) y el otro el grupo de esclavos (slaves). Los esclavos realizan la tarea propuesta por el maestro, computan los resultados y los envían de nuevo a este, quien los presenta, almacena o procesa. Esto se realiza así para tener una parte que autoriza y dirige los cálculos necesarios y otras partes que lo procesan de manera agnóstica a estas decisiones.

Ventajas

• Gestión centralizada – Este patrón destaca para el diseño de tareas multi-tarea ya que permite dividir las tareas en diferentes módulos que pueden ser ejecutados de forma independiente.
• Control – Al partir todas las tareas de un único nodo orquestador, se mantiene mayor control ya que las tareas se ejecutan de manera independiente y reciben el contexto y su procesamiento final de un único punto de la ejecución.
• Escalabilidad – Al ser todas las tareas ejecutadas independientes las unas de las otras es posible escalar fácilmente el sistema de forma que añadir nuevos nodos esclavos se termine traduciendo en un más que posible aumento del rendimiento.

Desventajas

• Implementación – Por como este sistema debe de funcionar, independientemente unas tareas de otras, no siempre es posible implementarlo para todos los proyectos, debido a que para ello debe de existir la posibilidad de dividirlo en módulos que puedan actuar aislados de la ejecución principal del programa.
• Dependencia – En muchos casos una implementación de este patrón implica una fuerte dependencia con el sistema en el que se haya implementado que en muchas ocasiones hace difícil portarlo a otras máquinas distintas.

Patrón modelo-vista-controlador (MVC)

Este famoso patrón, también conocido como patrón MVC, divide una aplicación interactiva en tres partes diferenciadas:

• Modelo: Contiene la funcionalidad central y los datos.
• Vista: Muestra la información al usuario, siempre es posible definir una o más vistas para una misma aplicación.
• Controlador: Maneja la entrada del usuario. Esto se hace para separar las representaciones internas de la información de las formas en que se presenta y se acepta la información del usuario. De esta manera se desacopla los componentes y permite una reutilización eficiente del código.

Este patrón es muy popular en el desarrollo de aplicaciones web, tanto en el caso de la parte trasera (back-end) y la frontal (front-end), siendo el patrón base de muchos frameworks conocidos como son el caso de Angular y en algún lenguaje como Java con el framework Spring.

Ventajas

• Fácil colaboración – Al separar fuertemente responsabilidades es posible desarrollar muchas nuevas características sin necesidad muchas veces de tocar todas las piezas implicadas, de forma que la colaboración entre diferentes desarrolladores se amplifica notablemente.
• Aplicaciones multi-vista – Al aislar las vistas del resto de la lógica de la aplicación es posible presentar las mismas funcionalidades en diferentes vistas que pueden dirigirse incluso a diversos dispositivos distintos.

Desventajas

• Complejidad – Es un patrón complejo que requiere que los desarrolladores implicados tengan muy claros los conceptos de responsabilidad asignados a cada una de las tres partes implicadas.
• Lento en ocasiones – En comparación a otros patrones desarrollar para este puede implicar tocar muchas y diversas piezas y tener que seguir un flujo de trabajo cerrado que a veces dificulta meter cambios que para cualquier otro desarrollo basado en otro patrón serían nimios.

Patrón broker

Este patrón se utiliza para estructurar sistemas distribuidos con componentes desacoplados. Estos componentes pueden interactuar entre sí mediante la invocación de servicios remotos de forma que publicitan sus capacidades, solicitan un servicio y un componente, llamado broker, se encarga de coordinar la comunicación entre los componentes. Es por tanto posible ver su similitud con el patrón master-slave.

Ventajas

• Escalabilidad – Al igual que el patrón master-slave al ser todas las tareas ejecutadas independientes las unas de las otras es posible escalar facilmente el sistema y sólo es necesario disponer de nuevos servidores que puedan procesar las peticiones del broker.
• Rendimiento – Al ser un gran número de nodos conectados a lo que simplemente actúa como un puente con el cliente el rendimiento puede mantenerse siempre en altas escalas ya que es posible redistribuir si es necesario y procesar grandes cargas de peticiones en momentos de saturación

Desventajas

• Coste – Evidentemente para implementar este sistema es necesario tener un gran número de servidores, que deben de ser mantenidos independientemente, con diferentes piezas de software distribuidas entre ellos.
• Mantenimiento – A diferencia de un sistema centralizado, este sistema distribuido implica que cualquier falla debe de poder deberse a cualquier pieza, igualmente realizar tareas de mantenimiento en la máquina broker, por ejemplo, puede implicar tiempos sin disponibilidad de servicio.

Conclusiones

La arquitectura del software es una fase de planificación crítica a la hora de comenzar cualquier proyecto para cualquier pieza de software, ya que nos proporciona una hoja de ruta clara sobre el camino a seguir en el desarrollo, dándonos instrucciones sobre qué componentes formarán parte de nuestro producto, cómo se distribuirán y cuál será la forma en la que se comuniquen entre sí.

Por todo lo anterior, elegir uno de los patrones anteriores sobre cualquier otro será determinante a la hora de, como ya vimos en la primera sección, determinar el tiempo de desarrollo, el coste del sistema y la capacidad para atender las peticiones de los usuarios, y el coste de cambiar de patrón durante el propio desarrollo (si fuera posible) podrá ser tan costoso que el producto podría pasar a un estado de no-viabilidad.

Un buen analista software dedicará un tiempo considerable a realizar entrevistas con los clientes, valorar la disponibilidad de recursos, tanto materiales como humanos, de su equipo y el tiempo de desarrollo estimado que puede permitirse para dicho producto. Invirtiendo este tiempo, que a vista del profano puede resultar innecesario y extremadamente lento, se acelerará el desarrollo y se evitarán problemas futuros que serán de difícil solución si parten de un error de base.

Si quieres saber más sobre arquitecturas, qué problemas resuelven y cómo podemos implementarlas no dejes de echar un vistazo a nuestros cursos disponibles AcademiaPlanetavirtual502  donde podrás ver en profundidad interesantes propuestas que te ofrecerán nuevas herramientas y opciones para tus futuros desarrollos.