Cómo desarrollar una arquitectura software: los lenguajes de patrones

© Copyright Moisés Daniel Díaz.

Qué es una arquitectura software y para qué sirve

El concepto de arquitectura se usa de forma amplia y en campos muy distintos, por lo que su significado es algo ... difuso.

En el campo del software, la arquitectura nos identifica los elementos mas importantes de un sistema así como sus relaciones. Es decir nos da una vision global del sistema.

¿Por qué es esto importante? Porque necesitamos arquitectura para entender el sistema, organizar su desarrollo, plantear la reutilización del software y hacerlo evolucionar.

Cómo determinar los elementos que definen una arquitectura es dificil y muy importante.

Generalmente las metodologias de desarrollo indican principios para identificar y diseñar una arquitectura, aunque por ahora la ayuda real que ofrecen es muy limitada al basarse en principios muy genéricos. En este artículo describiremos algunas técnicas que nos pueden resultar muy útiles para la construcción de arquitecturas software.

Las arquitecturas software no responden únicamente a requisitos estructurales, sino que están relacionadas con aspectos de rendimiento, usabilidad, reutilización, restricciones económicas y tecnológicas, e incluso cuestiones estéticas.

Arquitecturas y Metodologías

Actualmente existen muchas metodologías de desarrollo de software, desde metodos muy 'pesados' y burocráticos, metodos ajustables al proyecto y a las condiciones de desarrollo, hasta metodos 'ligeros' que surgen como respuesta a los excesos 'formales' de otros metodos.

Evidentemente, partiendo de los principios de tantas y diversas metodologías es muy difícil sacar una visión unificada sobre el diseño arquitectónico. Sin embargo sí que podemos destacar una serie de elementos comunes en aquellas que más se centran en este tema.

Y ¿cuáles son esos elementos comunes? El primero es la existencia de una fase en la que se establece o diseña una arquitectura base y el segundo la altísima dependencia que definen entre los casos de uso y la arquitectura, definiendo un caso de uso como una interacción (secuencia de acciones) típica entre el usuario y el sistema.

Desde un punto de vista arquitectónico, no todos los casos de uso tienen la misma importancia, destacando aquellos que nos ayudan a mitigar los riesgos más importantes y sobre todo aquellos que representan la funcionalidad básica del sistema a construir.

Esta arquitectura base estará especificada por diagramas que muestren subsistemas, interfaces entre los mismos, diagramas de componentes, clases, descripciones diversas, y por el conjunto de casos de uso básicos.

Este conjunto de especificaciones nos permiten validar la arquitectura con los clientes y los desarrolladores, y asegurarnos que es adecuada para implementar la funcionalidad básica deseada.

A partir de aquí, lo normal sería desarrollar de forma iterativa el sistema hasta tenerlo funcionalmente completo.

Hasta aquí todo muy bonito y perfecto, verdad?? Ya sabemos lo útil que es una arquitectura software, pero ... seguimos sin tener ni idea de cómo diseñar una.

Tipos de sistemas

Una visión alternativa sería identificar el tipo de sistema que queremos construir. Todos sabemos que no hay dos aplicaciones iguales, pero que existen claros paralelismos entre las aplicaciones construidas para resolver problemas similares.

El fijarnos en aplicaciones del mismo tipo tiene muchas ventajas ya que nos ayuda a entender las necesidades del cliente y las soluciones ya encontradas por otros.

Mientras que usar una metodología tradicional de desarrollo:

  • Te hace centrarte únicamente en parte del problema (el dominio del problema, sus requisitos y su microestructura), obviando cuestiones como rendimiento, seguridad, protocolos de comunicación, restricciones de hardware, software, y económicas, etc.
  • Te proporciona una visión estrecha, ya que frecuentemente el cliente no expone adecuadamente todos sus requisitos porque no los conoce.

Imaginemos que estamos desarrollando un portal web. La experiencia nos dice que a partir de cierto número de páginas, es útil desarrollar un sistema basado en plantillas Xslt, por la disminucion de costes de mantenimiento que ello implica.

Esto es algo que ningun requisito funcional nos daría, y que probablemente tampoco surgiría de forma 'natural' en los modelos de diseño.

A este tipo de soluciones (patrón de diseño) se llega por la experiencia en el desarrollo de sistemas web y por el conocimiento de las tecnologías existentes en el mercado.

Gracias a esta experiencia, desde el inicio del desarrollo de una aplicación, podemos buscar componentes que implementen estas tecnologías o ciertas funcionalidades, y por lo tanto integrar la búsqueda de componentes y su uso dentro del proceso de desarrollo de software.

Identificar el tipo de sistema a construir nos permite examinar la arquitectura de sistemas ya construidos, comprender los requisitos a los que se enfrentan, y constrastarlos con nuestros clientes. Si tenemos en cuenta que en cualquier tipo de sistema (por ejemplo: portales web) existen necesidades similares, muchos de los componentes que se usan en su desarrollo suelen ser los mismos (por ejemplo: parsers Xml, motores de transformación Xslt, componentes de acceso a datos, buscadores, carritos de la compra, gestores de contenidos, etc).

Las metodogías que gestionen de forma directa las cuestiones arquitectónicas y estructurales, podrán producir no solo productos de mayor calidad, sino a un menor coste y en menos tiempo. Esto se debe a que los riesgos arquitectónicos del proyecto son menores y están mucho mas controlados, y que al poder integrar una visión orientada a componentes, las posibilidades de reutilizar software ya desarrollado son mucho mayores, con las ventajas que ello implica.

Construir una arquitectura es tanto una actividad donde desarrollar ideas nuevas como una oportunidad de usar la experiencia acumulada, siendo casi siempre responsabilidad del desarrollador crear un producto de calidad y por tanto conocer el tipo de sistema a construir. Afortunadamente para esto último, los lenguajes de patrones nos pueden proporcionar una inestimable ayuda.

Lenguajes de patrones

Los 'Lenguajes de Patrones' se pueden definir del siguiente modo: "La especificación de una serie de elementos (patrones) y sus relaciones (patrones) de modo que nos permiten describir buenas soluciones a los diferentes problemas que aparecen en un contexto específico".

El objetivo de los patrones de diseño es el de capturar buenas prácticas que nos permitan mejorar la calidad del diseño de un sistema, determinando elementos que soporten roles útiles en dicho contexto, encapsulando complejidad, y haciéndolo más flexible.

Por otro lado, con frecuencia se dice que la función define a la forma, es decir, que la estructura o la arquitectura de cualquier sistema está muy relacionada con lo que dicho sistema tiene que hacer.

Esta es la razón por la que los sistemas con objetivos similares comparten también una arquitectura común, unos procesos bién definidos, y un conjunto de elementos similares (patrones de diseño). Similar funcionalidad y servicio, similar estructura.

Cuando desarrollamos un sistema que se encuadra dentro de cierto tipo, es muy útil consultar lenguajes de patrones que traten el dominio en el que estamos. Un lenguaje de patrones nos sirve como referencia conceptual del dominio del problema, ya que éstos parten como solucion a un conjunto de casos de uso, e interacciones con actores específicos. Además constituyen también un marco conceptual en el diseño de la arquitectura de nuestros sistemas, ya que como la función define a la forma, sintetizan por lo general soluciones arquitectónicas y estructurales bién probadas y muy útiles dentro del tipo de problemas que modelan.

De alguna forma, los patrones nos permiten identificar y completar los casos de uso basicos expuestos por el cliente, comprender la arquitectura del sistema a construir asi como su problemática, y buscar componentes ya desarrollados que cumplan con los requisitos del tipo de sistema a construir (es decir nos permiten obtener de una fiorma sencilla la arquitectura base que buscamos duran la fase de diseño arquitectónico).

Desafortunadamente los lenguajes de patrones tampoco son la panacea, y presentan muchas lagunas. Sobre todo, hay que recordar que todo este movimiento de documentación de diseño se origina a mediados de los noventa y que aún siendo mucho el trabajo realizado, no existe todavía ninguna estandarización sobre cómo abordar el desarrollo de estos lenguajes, ni ninguna clasificación que los relacione.

Bajo mi punto de vista un lenguaje de patrones que modele un tipo de sistema debe de ser descrito incluyendo la siguiente informacion:

  • Caracteristicas basicas que lo definen y diferencian. Por ejemplo: un sistema web se caracteriza por
    • clientes ultra ligeros,
    • uso de protocolos sin estado,
    • centralizacion del software de ejecucion en servidores de tal forma que la aplicación es compartida por todos los usuarios,
    • la distribucion de información es ordenes de magnitud a la grabacion de la misma,
    • la gran mayoria de las transacciones en este tipo de sistemas son muy simples,
    • el sistema es el responsable de construir el interfaz del usuario de una forma mucho mas acuciada que en otros sistemas,
    • etc.
  • Definicion de los actores principales que participan en dicho sistema asi como sus casos de uso básicos, descritos evidentemente de forma generica.
  • Especificacion de los principales componentes funcionales del sistema asi como las relaciones entre ellos.
  • Arquitectura logica y flujos de información, que estructuran los diferentes subsistemas, el intercambio de información de los mismos, etc. Por ejemplo: arquitecturas reflexivas, modelo-vista-controlador, etc.
  • Arquitectura de componentes. Consiste en mapear los componentes funcionales en la arquitectura lógica de la aplicación.
  • Arquitectura física. Especificación del despliegue de los componentes.

Estos lenguajes deberian ademas tener una vision orientada a la construccion de software y a constituirse como elementos integrables en el proceso de desarrollo de las aplicaciones.

Nuevos diseños

Mucho he hablado sobre la reutilizacion de la experiencia ya acumulada y documentada, sin embargo es digno recalcar que en un campo tan cambiante como el del software todo necesita evolucionar, y nada es definitivo.

La necesidad de innovar y reflexionar seguirá siendo un elemento muy importante en el desarrollo de las aplicaciones.

Sin embargo, como dijo Isaac Newton "Si he llegado a ver más lejos que otros, es porque me subí a hombros de gigantes". Aprovechemos tan buen consejo, y construyamos e innovemos usando la experiencia que otros nos han legado.

Referencias

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP