Aunque suene a leyenda urbana, el amigo de un amigo, le dijo a su profesor de Arquitectura de Computadoras, "Gracias Arquitecto..!", al momento de aprobar el curso, quizás suene a broma, pero cuando hablamos de Arquitecturas de software no estamos tan alejados de la verdad. Los desarrolladores, tenemos muchas cosas en común, demasiadas diría yo, pero en si en el fondo, poseemos algo de arquitectos, y también aquel pequeño gran defecto de querer construir todo desde cero, desechando aquello que ya esta construido, impulsado quizás por un complejo megalomaniaco no resuelto, a lo mejor, quien sabe. Primer Paso: Entornos físicos de implementación. En cualquier escenario de implementación de alguna aplicación, se tiene que tener en cuenta las siguientes premisas: Conocer el entorno físico en donde se alojara la aplicación, Conocer las restricciones del entorno que jugaran en contra de la aplicación. Transmitir que determinado diseño de software requerirá ciertos atributos del entorno físico. Cuando hablamos de entornos físicos de una aplicación, los desarrolladores tenemos que tener en cuenta varios factores, no solamente las premisas anteriores, si no cosas como: Tipo de aplicación que el cliente requiere implementar, escalabilidad, rendimiento, directivas de la organización, etc. Aquí es donde el desarrollador, genera la primera idea que dará vida a la aplicación, su Arquitectura. Un Paso al costado: Arquitecturas de Aplicaciones. Definitivamente, la palabra arquitectura no se usa de manera nativa en el mundo de la informática, es una forma puramente conceptual, que usa en distintos campos de la ciencia, por lo que tratar generar un axioma es, digamos, un poco ambiguo. Digamos que en el desarrollo de aplicaciones, una arquitectura define los elementos principales y sus interrelaciones, para así generar una visión global del sistema a desarrollador. ¿Por que es necesario una arquitectura?, pues pongámoslo de esta manera, y así se pensó, cuando se plasmo la idea de arquitectura, derivándolo de la construcción de edificaciones. Necesitamos una arquitectura, para comprender las partes que interactuarán en el sistema, así como organizar el desarrollo, pensar en la reutilización de código y lógicamente en el crecimiento futuro del sistema, aquello que denominamos escalabilidad. Aquí llegamos a cierto punto ineludible, la definición de elementos que conforman una arquitectura, es en cierto punto una tarea un tanto compleja y muy importante. Algunas metodologías de Software incluyen pautas para la especificación de arquitecturas, pero lógicamente son muy genéricas, y debido a que los puntos para generar una arquitectura no solo depende a un modelo de estructura, si no a aspectos de performance, reutilización, economía, etc. En la otra orilla tenemos a las metodologías de software, un tema ampliamente divulgado y también tocado en algunos artículos anteriores, por otros autores, estas metodologías van desde las que son excesivamente "burocráticas", por decirlo de alguna manera, como las metodologías clásicas, hasta las que se adaptan al proyecto y a los requerimientos del usuario, como la muy conocida XP, que surgen como un grito de liberación, en respuesta a la "ecuanimidad", por decirlo de alguna otra manera, de las metodologías clásicas. En el circuito típico del desarrollo tenemos fases, marcadas del desarrollo y la mas importante es el desarrollo de la Arquitectura, y una de las partes fundamentales seria identificar que tipo de sistema queremos construir, ya que al definir una arquitectura, estamos "estandarizando" el sistema que vamos a desarrollar, y en contra de las metodologías de desarrollo, que solo se centran en requerimientos, el problema en si a atacar y resolver, requisitos para la solución del mismo, etc., obviando parte importante como rendimiento, performance, seguridad, etc. Digamos entonces que la definición de una arquitectura es el planeamiento tecnológico que se hace para el buen desarrollo de una aplicación. Un Caso Real. Si tenemos que desarrollar un sistema Web, por ejemplo, tenemos mil y un maneras de realizarlo, y sin poner énfasis en la tecnología que usemos, podemos identificar muchos "problemas" comunes en todos los sistemas Web, como los mantenedores generales de tablas, si son demasiadas tablas a las que dar mantenimiento, los desarrolladores, podemos realizar una plantilla de pagina que genere código de mantenimiento para todas las tablas, lo que se conoce como arquitectura reflexiva, esto es algo que ninguna metodología nos la ofrece, la poseemos por experiencia o por errores pasados, he aquí el hecho que el desarrollo de arquitecturas sea mas bien un arte que una ciencia. Ahora si podemos fundir una metodología nos de flexibilidad para crear modelos arquitectónicos de desarrollo, no solamente tendremos un producto final de calidad, si no se reducirán los riesgos que corre cualquier proyecto, al tener que replantear modelos justo a la mitad o en el peor de los casos, casi al final del desarrollo. Patrones. Y he aquí una de los grandes aportes que se han hecho al desarrollo de aplicaciones, los patrones, son mas que la generalización de soluciones para muchos problemas con que tienen cosas en común, dicho de una manera mas concreta es un "conjunto de elementos y sus relaciones que permiten describir buenas soluciones en un ámbito especifico", como lo han descrito innumerables autores. Debido a esto, tememos que los sistemas pueden compartir una arquitectura en común, siempre y cuando sus objetivos sean también comunes. Pero a pesar de que la prometida integración que promete el lenguaje de patrones, hay aun mucho por hacer, la estandarización lleva tiempo y muchos "muertos" en el camino. Definitivamente, tanto como el buen diseño de una arquitectura y el buen uso del lenguaje de patrones, es una cualidad que se adquiere con el tiempo y la experiencia, y como toda experiencia en la vida, esta basada en el principio ensayo-error, lo bueno es que se tiene un banco de información muy variado, como para caer en errores clásicos al momento del desarrollo. En la Parte II de este artículo veremos, casos prácticos de modelamiento tomando plantillas ya existentes y asimilándolas a un caso en especial.     Otros Artículos del Autor: Fecha Publicación: Model View Controller (MVC) Marzo 24 del 2004 XML como definición y manejo de datos Agosto 8 del 2003 WEB SERVICES Diciembre 27 del 2002