En el texto fundacional de la AS, Perry y Wolf establecen el razonamiento sobre estilos de
arquitectura como uno de los aspectos fundamentales de la disciplina. Un estilo es un concepto
descriptivo que define una forma de articulación u organización arquitectónica. El conjunto de los estilos cataloga las formas básicas posibles de estructuras de software, mientras que las formas complejas se articulan mediante composición de los estilos fundamentales.
Sucintamente descriptos, los estilos conjugan elementos (o “componentes”, como se los llama
aquí), conectores, configuraciones y restricciones. Al estipular los conectores como elemento de juicio de primera clase, el concepto de estilo, incidentalmente, se sitúa en un orden de discurso y de método que el modelado orientado a objetos en general y UML en particular no cubren satisfactoriamente. La descripción de un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es hacerlo en un lenguaje de descripción arquitectónica o en lenguajes formales de especificación. A diferencia de los patrones de diseños, que son centenares, los estilos se ordenan en seis o siete clases fundamentales y unos veinte ejemplares, como máximo. Es digno de señalarse el empeño por subsumir todas las formas existentes de aplicaciones en un conjunto de dimensiones tan modestas. Las arquitecturas complejas o compuestas resultan del agregado o la composición de estilos más básicos. Algunos estilos típicos son las arquitecturas basadas en flujo de datos, las peer-to-peer, las de invocación implícita, las jerárquicas, las centradas en datos o las de intérprete-máquina virtual.
Hemos tratado el tema de las definiciones, los catálogos de estilos, las propiedades de cada uno, el lugar de los estilos en la AS y su relación con los patrones de diseño y con la estrategia
arquitectónica de Microsoft en un documento separado, en torno del cual se podrán discutir las
cuestiones relacionadas con ellos.
Lenguajes de descripción arquitectónica (ADL)
Los lenguajes de descripción de arquitecturas, o ADLs, ocupan una parte importante del trabajo arquitectónico desde la fundación de la disciplina. Se trata de un conjunto de propuestas de variado nivel de rigurosidad, casi todas ellas de extracción académica, que fueron surgiendo desde comienzos de la década de 1990 hasta la actualidad, más o menos en contemporaneidad con el proyecto de unificación de los lenguajes de modelado bajo la forma de UML. Los ADL difiere sustancialmente de UML, que al menos en su versión 1.x se estima inadecuado en su capacidad para expresar conectores en particular y en su modelo semántico en general para las clases de descripción y análisis que se requieren. Los ADLs permiten modelar una arquitectura mucho antes que se lleve a cabo la programación de las aplicaciones que la componen, analizar su adecuación, determinar sus puntos críticos y eventualmente simular su comportamiento. Los ADLs son bien conocidos en los estudios universitarios de AS, pero muy pocos arquitectos de industria parecen conocerlos y son menos aún quienes los utilizan como instrumento en el diseño arquitectónico de sus proyectos. Hay unos veinte ADLs de primera magnitud y tal vez unos cuarenta o cincuenta propuestos en ponencias que no han resistido el paso del tiempo o que no han encontrado su camino en el mercado. Se han analizado esos lenguajes descriptivos en un documento aparte, en el cual se invita asimismo a su discusión.
Frameworks y Vistas
En el desarrollo de software, un framework es una estructura conceptual y tecnológica de soporte definida, normalmente con artefactos o módulos de software concretos, con base en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros programas para ayudar a desarrollar y unir los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio
Son diseñados con la intención de facilitar el desarrollo de software, permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. Por ejemplo, un equipo que usa Apache Struts para desarrollar un sitio web de un banco, puede enfocarse en cómo los retiros de ahorros van a funcionar en lugar de preocuparse de cómo se controla la navegación entre las páginas en una forma libre de errores. Sin embargo, hay quejas comunes acerca de que el uso de frameworks añade código innecesario y que la preponderancia de frameworks competitivos y complementarios significa que el tiempo que se pasaba programando y diseñando ahora se gasta en aprender a usar frameworks.
Fuera de las aplicaciones en la informática, puede ser considerado como el conjunto de procesos y tecnologías usados para resolver un problema complejo. Es el esqueleto sobre el cual varios objetos son integrados para una solución dada.
Después de todo, un framework no debe ser consciente de todos estos requerimientos sin tener que ser intrusivo con las aplicaciones que permite dentro de sí mismo. A esto le sumamos la capacidad de extenderse sin prejuicios para diversificar la expresión del programa mismo.
Básicos
No es más que una base de programación que atiende a sus descendientes (manejado de una forma estructural y/o en cascada) posibilitando cualquier respuesta ante las necesidades de sus miembros, o secciones de una aplicación (web, de este modo).
Arquitectura
Dentro de este aspecto, podemos basarnos en el modelo MVC (Controlador => Modelo => Vista) ya que debemos fragmentar nuestra programación. Tenemos que contemplar estos aspectos básicos en cuanto a la implementación de nuestro sistema:
- Controlador:
Con este apartado podemos controlar el acceso (incluso todo) a nuestra aplicación, esto pueden ser: archivos, scripts o programas; cualquier tipo de información que permita la interfaz. Así, podremos diversificar nuestro contenido de forma dinámica, y estática (a la vez); pues, sólo debemos controlar ciertos aspectos (como se ha mencionado antes).
- Modelo:
Este miembro del controlador maneja las operaciones lógicas, y de manejo de información (previamente enviada por su ancestro) para resultar de una forma explicable, y sin titubeos. Cada miembro debe ser meticulosamente llamado, en su correcto nombre y en principio, con su verdadera naturaleza: el manejo de información, su complementación directa.
- Vista:
Al final, a este miembro de la familia le corresponde dibujar, o expresar la última forma de los datos: la interfaz gráfica que interactúa con el usuario final del programa (GUI). Después de todo, a este miembro le toca evidenciar la información obtenida hasta hacerla llegar con el controlador. Solo (e inicialmente), nos espera demostrar la información.
Estructura
Dentro del controlador, modelo o vista podemos manejar lo siguiente: datos. Depende de nosotros como interpretar y manejar estos 'datos'. Ahora, sabemos que el único dato de una dirección estática web es: conseguir un archivo físico en el disco duro o de internet, etc. e interpretado o no, el servidor responde.
El modelo, al igual que el controlador y la vista, maneja todos los datos que se relacionen consigo (solo es el proceso medio de la separación por capas que ofrece la arquitectura MVC). Y sólo la vista, puede demostrar dicha información. Con lo cual ya hemos generado la jerarquía de nuestro programa: Controlador, Modelo y Vista.
Lógica
Al parecer, debemos inyectar ciertos objetos dentro de sus parientes en esta aplicación, solo así compartirán herencia y coherencia en su aplicación.
Rápidamente, para una aplicación web sencilla debemos establecer estos objetos:
- Una base (MVC)
- Controlador: éste debe ser capaz de manejar rutas, archivos, clases, métodos y funciones.
- Modelo: es como un script habitual en el servidor, solo que agrupado bajo un 'modelo' reutilizable.
- Vista: como incluyendo cualquier archivo en nuestra ejecución, muy simple.
- Un sistema
- Ruteador: con él podemos dividir nuestras peticiones sin tantas condicionales.
- Cargador
