Enlace:
|
'Cómo desarrollar una arquitectura software: los lenguajes de patrones'
Moisés Daniel Díaz Toledano. www.moisesdaniel.com
1.- Qué es
una arquitectura software y para qué sirve.
2.-
Arquitecturas y Metodologías.
3.- Tipos
de Sistemas.
4.-
Lenguajes de Patrones.
5.-
Nuevos Diseños.
1.- Qué es una arquitectura
software y para qué sirve.
|
|
|
|
Blowball 1943 wood engraving, M.C. Escher |
Cubic Space Filling, M.C. Escher |
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.
2.- Arquitecturas y Metodologías.
|
|
|
Drawing Hands 1948 Lithograph, M.C. Escher |
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.
3.- Tipos de sistemas.
|
|
|
|
Ant 1943 Lithograph, M.C. Escher |
Mumified Frog 1946 Mezzotint, M.C. Escher |
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.
4.- Lenguajes de patrones.
|
|
|
Plane Filling II 1957 Lithograph, M.C. Escher |
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
q
clientes ultra ligeros,
q
uso de protocolos sin estado,
q
centralizacion del software de
ejecucion en servidores de tal forma que la aplicación es compartida por todos
los usuarios,
q
la distribucion de información es
ordenes de magnitud a la grabacion de la misma,
q
la gran mayoria de las
transacciones en este tipo de sistemas son muy simples,
q
el sistema es el responsable de
construir el interfaz del usuario de una forma mucho mas acuciada que en otros
sistemas,
q
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.
5.- Nuevos diseños.
|
|
|
Metamorphosis II 1940 woodcut in black, green
and brown, printed from 20 blocks on 3 combined sheets, M.C. Escher |
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:
q
Conferenrias y
documentos sobre Lenguajes de Patrones:
o
http://jerry.cs.uiuc.edu/~plop/
q
‘Diseño de
Aplicaciones Web usando los Patrones de Diseño J2EE’:
o
http://www.moisesdaniel.com/es/wri/disaplicj2ee.html
o
http://www.programacion.com/java/articulo/corej2ee_patterns/
q
‘Arquitectura de
los Sistemas de Información Empresariales’:
o
http://www.moisesdaniel.com/wri/eisarc.html
q
‘Patterns of
o
http://www.amazon.com/exec/obidos/tg/detail/-/0321127420/104-0277958-9523132?v=glance