1. Patrón Arquitectónico
1.1. Buschmann et al. (1996) define patrón como una regla que consta de tres partes, la cual expresa una relación entre un contexto, un problema y una solución. En líneas generales, un patrón sigue el siguiente esquema: Contexto. Es una situación de diseño en la que aparece un problema de diseño Problema. Es un conjunto de fuerzas que aparecen repetidamente en el contexto Solución. Es una configuración que equilibra estas fuerzas. Ésta abarca: Estructura con componentes y relaciones Comportamiento a tiempo de ejecución: aspectos dinámicos de la solución, como la colaboración entre componentes, la comunicación entre ellos, etc.
1.1.1. Caracteristicas
1.1.1.1. La lógica de negocio debe estar separada del acceso de datos.
1.1.1.1.1. hfhxfhhfxhdxhxdhxdh
1.1.1.2. Alcance: aplican con problemas de diseño específico.
1.1.1.3. El estado del sistema debe presentarse en múltiples formas.
1.1.1.4. Abstracción: son fragmentos arquitectónicos parametrizados que pueden ser pensados como una pieza concreta de diseño
1.1.1.5. Relación Un único patrón puede ser aplicado a los lineamientos de múltiples estilos.
2. Estilo Arquitectónico
2.1. Shaw y Garlan (1996) definen estilo arquitectónico como una familia de sistemas de software en términos de un patrón de organización estructural, que define un vocabulario de componentes y tipos de conectores y un conjunto de restricciones de cómo pueden ser combinadas. Buschmann et al. (1996) definen estilo arquitectónico como una familia de sistemas de software en términos de su organización estructural. Expresa componentes y las relaciones entre estos, con las restricciones de su aplicación y la composición asociada, así como también las reglas para su construcción.
2.1.1. Caracteristicas
2.1.1.1. Abstracción: son muy abstractos para producir un diseño concreto del sistema
2.1.1.2. Sistemas intensivos en GUI
2.1.1.3. Alcance: aplican a un contexto de desarrollo
2.1.1.4. Sistema altamente distribuido
2.1.1.5. Relación Un sistema diseñado de acuerdo a las reglas de un único estilo puede involucrar el uso de múltiples patrones
3. La arquitectura de software es una disciplina emergente que con sus herramientas ayuda a abstraer, conceptualizar y modelar de manera óptima estilos y patrones para aplicarla en la construcción de software.
3.1. Importancia de la arquitectura del software
3.1.1. Creamos una base sólida para el proyecto.
3.1.2. Conseguiremos que la plataforma creada sea escalable.
3.1.3. Aumenta el rendimiento de la plataforma.
3.1.4. Reduce considerablemente los costes y evita duplicaciones del código.
3.1.5. La arquitectura de software es una manera de garantizarte una buena IT, puesto que el arquitecto debe conservar durante toda la creación, una visión general del producto, de forma que pueda bajar a pequeñas partes del código y saber enlazarlas con el resto. Debe mantener una línea lógica y en ocasiones incluso, dar la cara para asegurar resultado exitosos.
3.1.6. El arquitecto, al tener esta visión global del proceso e incluso del producto final, sabe en qué aspectos se puede ahorrar gastos. De forma que reutiliza procesos y comparte los datos para optimizar al máximo cada proceso evolutivo, buscando a su vez la mayor perfección posible.
3.1.7. Ya que el código es propio, es mucho más visible y se tiene pleno conocimiento sobre él, de forma que será mucho más fácil encontrar problemas y por lo tanto soluciones, en definitiva tenemos un mantenimiento mucho más eficaz.
3.1.8. Este conocimiento, a la par nos permite la implementación de cambios en los sistemas de manera más rápida.
3.1.9. Incrementa la calidad de la plataforma.
3.1.10. Ayuda en las tareas más complejas.
3.1.11. Nos permite hacer la plataforma de manera más rápida.
3.1.12. Permite una mayor adaptabilidad. Por ejemplo a la hora de modificar características técnicas en front end, o implementar motores de reglas. Son tareas más sencillas de adaptar cada una a su debido tiempo, ya que por otro lado el arquitecto de software establece prioridades.
3.1.13. Ayuda a la gestión de riesgos reduciendo el porcentaje de fracasos.
3.1.14. Reduce los tiempos de creación y de entrega de los proyectos.
3.1.15. Da prioridad a los conflictos. Permite comunicación entre las partes y decisiones de diseño previas a su implementación, de forma que sea más fácil un diseño especializado.
4. ADL
4.1. Es un lenguaje descriptivo de modelado el cual su principal interés es la estructura de alto nivel del software antes que los detalles finos de desarrollo e implementación de los módulos que lo conforman. Aun no existe una definición generalizada de los lenguajes, pero comúnmente debe pensarse que que estos lenguajes proporcionan un modelo explícito de componentes, conectores y sus respectivas configuraciones (Reynoso 2004, p 4)
4.1.1. Acme
4.1.1.1. Es un lenguaje de descripción de arquitectura de software (ADL) simple y genérico que se puede usar como un formato de intercambio común para herramientas de diseño de arquitectura y / o como base para desarrollar nuevas herramientas de diseño y análisis arquitectónico
4.1.2. DARWIN
4.1.2.1. Es un lenguaje de descripción arquitectónica como su nombre lo indica, Darwin está orientado más que nada al diseño de arquitecturas dinámicas y cambiantes, soporta notación gráfica. Existe una herramienta (Software Architects Assistant) que permite trabajar visualmente con lenguaje Darwin
4.1.3. C2 o Chiron-2
4.1.3.1. es un estilo de arquitectura de software que se ha impuesto como estándar en el modelado de sistemas que requieren intensivamente paso de mensajes y que suelen poseer una interfaz gráfica dominante.
4.1.4. Rapide
4.1.4.1. Rapide usa un Lenguaje de Definición de Arquitectura Ejecutable (EADL: Executable Architecture Definition Language, en el inglés).
4.1.5. Jacal
4.1.5.1. El objetivo principal de Jacal es lo que actualmente se denomina “animación” de arquitecturas. Esto es, poder visualizar una simulación de cómo se comportaría en la práctica un sistema basado en la arquitectura que se ha representado.