Conceptos arquitectónicos. Imagínense una casa mal diseñada con un prototipo arquitectónico inadecuado. La arquitectura de edificios y casas cercanos a la cordillera Argentina no son iguales a cualquiera que se encuentre en la zona este (cerca del Atlántico), donde las probabilidades de sismos o terremotos es muy poco probable (casi nula, diría yo). Edificios sismorresistentes o no. Esa es la cuestión. Con el software pasa algo similar. Para distintos escenarios, distintas arquitecturas. Cada arquitectura tiene lo suyo. Ventajas y desventajas.

¿Quien tiene en su memoria uno de mis últimos post (Diseño de sistemas. Conceptos)?

Primero, le agradeceré por haber leído y estar al tanto de las actualizaciones del blog (mas si es un lector recurrente). En segundo lugar, este post vendría a ser su complemento.

Decíamos que el diseño es muy importante. Si. ¿Y que hay del diseño arquitectónico?

Un diseño de arquitectura siempre es uno de los factores más críticos en el desarrollo de cualquier software.

Por supuesto que existen muchas técnicas que nos guían y nos ayudan a estandarizar estos puntos críticos. Los patrones son una de estas tantas técnicas que nos solucionan problemas comunes.

Si estas leyendo esto seguramente sabrás, o por lo menos oíste hablar, de los patrones de diseño (¡Hola Singleton!, ¿Te conocerán?).

Dichos patrones ayudan a estandarizar soluciones a problemas que suceden a menudo. Son reutilizables, identificando buenas estructuras para poder aplicarlas en otros desarrollos.

Tal y como nos referíamos a los patrones de diseño (y patrones de arquitectura, tema de este post), también existen patrones de codificación.

Los patrones de arquitectura nos brindan un esquema organizativo de la estructura de un sistema de software. A su vez, organizan las relaciones entre los subsistemas existentes en todo desarrollo.

Existen varios patrones de arquitectura posibles.

 

Arquitectura por capas

La jerarquía es un punto clave en este tipo de arquitecturas. Cada capa provee ciertos servicios a la capa superior y consume los de la capa inferior. De típico organigrama de cualquier empresa, ¿no?, o acaso nuestro jefe ¿no nos solicita información? Todo hacia arriba. Desde la base hasta la punta de la pirámide. Todo se construye desde la capa inferior.

Desde ya, existen variantes. Puede que una capa tenga la característica de consumir y brandar servicios solamente a capas adyacentes, o solamente a sus capas superiores.

 

Una de las ventajas es el grado de abstracción, permitiendo dividir un problema complejo.

A su vez, es viable una comunicación bidireccional entre capas adyacentes permitiendo el intercambio de información.

En cuanto a las desventajas, podría existir un alto acoplamiento entre las capas (y las buenas prácticas de diseño nos indican que es importante llegar a un nivel de acoplamiento mínimo. Ya lo hemos visto). Si un cambio modifica también otras capas, ya se torna muy costoso.

Otra cosa para destacar es la excesiva cantidad de capas que suelen diseñarse. Ni pocas ni muchas. Las necesarias para resolver el problema.

Siguiendo con la arquitectura de capas, conocemos 3 típicas organizaciones en sistemas software:

 

Sistemas de 2 capas:

La llamada Cliente-Servidor. Uno consume y el otro brinda el servicio. Así de fácil aunque suene redundante.

Es una forma de descentralización, saliendo de la arquitectura monolítica. Aunque no del todo descentralizada, porque el servidor, aquí, es quien centraliza toda la información. De esta manera, todas las gestiones que se realizan pasan por el servidor.

 

Sistemas de 3 capas:

Por suerte existe la posibilidad de implementar otra capa, para que la información no este centralizada en una sola capa, y que esto provoque algún tipo de congestión. Se distribuye el trabajo de manera tal que esta abstraído del resto de los niveles.

Existen la capa de presentación (la que ve el usuario, brindándole la vista de los datos), la capa de negocio (donde esta la lógica y reglas de la aplicación. Capa de comunicación entre la capa de presentación y la siguiente capa, desde donde se obtienen los datos) y la capa de datos (donde residen los datos, obviamente; formada, muchas veces, por mas de una base de datos).

 

Sistemas de 4 capas:

Existe también una cuarta capa. La idea aquí es agregar una capa intermedia entre la capa de presentación y la capa de negocio. Esta capa denominada capa de servicios tiene la función de proveer una interfaz para el acceso a la capa de negocios.

Con el avenimiento de los smartphones y tablets, es cada vez más común que una aplicación pueda ser accedida por distintos “periféricos externos”. Asi, es bueno transparentar la capa de negocios con una interfaz simple.

Este post busca introducirlos en este concepto tan importante. Por supuesto que faltan muchos tipos de diseños arquitectónicos, pero el objetivo principal es que uno entienda ciertos conceptos basicos y utilizarlos luego en sistemas mas avanzados.

Una respuesta a “Diseño Arquitectónico. ¿Y que más?”

  1. Bien! Como siempre aportando a la comunidad estudiantil ;)