Arquitectura de software

La arquitectura de software es el conjunto de estructuras necesarias para razonar sobre un sistema de software y la disciplina de crear dichas estructuras y sistemas. Cada estructura comprende elementos de software, relaciones entre ellos y propiedades de ambos elementos y relaciones. ^{[1] [2]}

La arquitectura de un sistema de software es una metáfora , análoga a la arquitectura de un edificio. ^[3] Funciona como los planos para el sistema y el proyecto de desarrollo, que la gestión del proyecto puede utilizar posteriormente para extrapolar las tareas necesarias que deben ejecutar los equipos y las personas involucradas.

La arquitectura de software consiste en tomar decisiones estructurales fundamentales que son costosas de cambiar una vez implementadas. Las decisiones de arquitectura de software incluyen opciones estructurales específicas a partir de las posibilidades en el diseño del software . Existen dos leyes fundamentales en la arquitectura de software: ^{[4] [5]}

1. Todo es un intercambio
2. "El por qué es más importante que el cómo"

"Architectural Kata" es un trabajo en equipo que se puede utilizar para producir una solución arquitectónica que se ajuste a las necesidades. Cada equipo extrae y prioriza las características arquitectónicas (también conocidas como requisitos no funcionales ) y luego modela los componentes en consecuencia. El equipo puede utilizar el modelo C4 , que es un método flexible para modelar la arquitectura lo suficiente. Tenga en cuenta que la comunicación sincrónica entre los componentes arquitectónicos los entrelaza y deben compartir las mismas características arquitectónicas. ^[6]

La documentación de la arquitectura del software facilita la comunicación entre las partes interesadas , captura decisiones tempranas sobre el diseño de alto nivel y permite la reutilización de componentes de diseño entre proyectos. ^{[7] : 29–35}

El diseño de la arquitectura de software se suele comparar con el diseño de aplicaciones de software. Mientras que el diseño de aplicaciones se centra en el diseño de los procesos y los datos que respaldan la funcionalidad requerida (los servicios que ofrece el sistema), el diseño de la arquitectura de software se centra en el diseño de la infraestructura dentro de la cual se puede realizar y ejecutar la funcionalidad de la aplicación de modo que la funcionalidad se proporcione de una manera que cumpla con los requisitos no funcionales del sistema .

Las arquitecturas de software se pueden clasificar en dos tipos principales: arquitectura monolítica y distribuida , cada una tiene sus propias subcategorías. ^[5]

La arquitectura de software tiende a volverse más compleja con el tiempo. Los arquitectos de software deberían utilizar " funciones de adecuación " para mantener la arquitectura bajo control de forma continua . ^[5]

Las opiniones varían en cuanto al alcance de las arquitecturas de software: ^[8]

• Estructura del sistema macroscópico : se refiere a la arquitectura como una abstracción de nivel superior de un sistema de software que consiste en una colección de componentes computacionales junto con conectores que describen la interacción entre estos componentes. ^[9]
• Lo importante, sea lo que sea , se refiere al hecho de que los arquitectos de software deben preocuparse por aquellas decisiones que tienen un alto impacto en el sistema y sus partes interesadas. ^[10]
• Lo que es fundamental para comprender un sistema en su entorno ^[11]
• Aspectos que la gente percibe como difíciles de cambiar : dado que el diseño de la arquitectura se lleva a cabo al comienzo del ciclo de vida de un sistema de software, el arquitecto debe centrarse en las decisiones que "tienen que" ser correctas la primera vez. Siguiendo esta línea de pensamiento, los problemas de diseño arquitectónico pueden volverse no arquitectónicos una vez que se pueda superar su irreversibilidad. ^[10]
• Un conjunto de decisiones de diseño arquitectónico : la arquitectura de software no debe considerarse simplemente un conjunto de modelos o estructuras, sino que debe incluir las decisiones que conducen a estas estructuras particulares y la lógica detrás de ellas. ^[12] Esta idea ha dado lugar a una importante investigación sobre la gestión del conocimiento de la arquitectura de software . ^[13]

No existe una distinción clara entre la arquitectura de software, el diseño y la ingeniería de requisitos (ver Campos relacionados a continuación). Todos ellos forman parte de una "cadena de intencionalidad" que va desde las intenciones de alto nivel hasta los detalles de bajo nivel. ^{[14] : 18}

La arquitectura del software exhibe lo siguiente:

Multitud de partes interesadas: los sistemas de software deben satisfacer las necesidades de una gran variedad de partes interesadas, como gerentes de negocios, propietarios, usuarios y operadores. Todas estas partes interesadas tienen sus propias preocupaciones con respecto al sistema. Equilibrar estas preocupaciones y demostrar que se tienen en cuenta es parte del diseño del sistema. ^{[7] : 29–31} Esto implica que la arquitectura implica abordar una amplia variedad de preocupaciones y partes interesadas, y tiene una naturaleza multidisciplinaria.

Separación de preocupaciones : la forma establecida por los arquitectos para reducir la complejidad es separar las preocupaciones que impulsan el diseño. La documentación de la arquitectura muestra que todas las preocupaciones de las partes interesadas se abordan modelando y describiendo la arquitectura desde puntos de vista separados asociados con las diversas preocupaciones de las partes interesadas. ^[15] Estas descripciones separadas se denominan vistas arquitectónicas (consulte, por ejemplo, el modelo de vista arquitectónica 4+1 ).

Impulsado por la calidad: los enfoques clásicos de diseño de software (por ejemplo, la Programación Estructurada de Jackson ) estaban impulsados ​​por la funcionalidad requerida y el flujo de datos a través del sistema, pero la visión actual ^{[7] : 26–28} es que la arquitectura de un sistema de software está más estrechamente relacionada con sus atributos de calidad , como tolerancia a fallas , compatibilidad con versiones anteriores , extensibilidad , confiabilidad , mantenibilidad , disponibilidad , seguridad, usabilidad y otras similares . Las preocupaciones de las partes interesadas a menudo se traducen en requisitos sobre estos atributos de calidad, que se denominan de diversas formas requisitos no funcionales , requisitos extrafuncionales, requisitos de comportamiento o requisitos de atributos de calidad.

Estilos recurrentes: al igual que la arquitectura de edificios, la disciplina de la arquitectura de software ha desarrollado formas estándar para abordar problemas recurrentes. Estas "formas estándar" reciben diversos nombres en distintos niveles de abstracción. Los términos comunes para las soluciones recurrentes son estilo arquitectónico, ^{[14] : 273–277} táctica, ^{[7] : 70–72} arquitectura de referencia y patrón arquitectónico . ^{[16] [17] [7] : 203–205}

Integridad conceptual: término introducido por Fred Brooks en su libro de 1975 The Mythical Man-Month para denotar la idea de que la arquitectura de un sistema de software representa una visión general de lo que debería hacer y cómo debería hacerlo. Esta visión debería estar separada de su implementación. El arquitecto asume el papel de "guardián de la visión", asegurándose de que las adiciones al sistema estén en línea con la arquitectura, preservando así la integridad conceptual . ^{[18] : 41–50}

Restricciones cognitivas: Una observación hecha por primera vez en un artículo de 1967 por el programador informático Melvin Conway de que las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones. ^[19] Fred Brooks lo presentó a una audiencia más amplia cuando citó el artículo y la idea en The Mythical Man-Month , llamándolo Ley de Conway .

La arquitectura de software es una abstracción "intelectualmente comprensible" de un sistema complejo. ^{[7] : 5–6} Esta abstracción proporciona una serie de beneficios:

• Proporciona una base para el análisis del comportamiento de los sistemas de software antes de que se haya construido el sistema. ^[3] La capacidad de verificar que un futuro sistema de software satisface las necesidades de sus partes interesadas sin tener que construirlo realmente representa un ahorro de costos sustancial y una mitigación de riesgos. ^[20] Se han desarrollado varias técnicas para realizar dichos análisis, como ATAM o mediante la creación de una representación visual del sistema de software.
• Proporciona una base para la reutilización de elementos y decisiones. ^{[3] [7] : 35} Una arquitectura de software completa o partes de ella, como las estrategias y decisiones arquitectónicas individuales, se pueden reutilizar en múltiples sistemas cuyas partes interesadas requieren atributos de calidad o funcionalidades similares, ahorrando costos de diseño y mitigando el riesgo de errores de diseño.
• Apoya las decisiones de diseño tempranas que impactan el desarrollo, la implementación y la vida útil de mantenimiento de un sistema. ^{[7] : 31} Tomar las decisiones tempranas y de alto impacto correctas es importante para evitar sobrepasar el cronograma y el presupuesto .
• Facilita la comunicación con las partes interesadas, contribuyendo a un sistema que satisfaga mejor sus necesidades. ^{[7] : 29–31} Comunicarse sobre sistemas complejos desde el punto de vista de las partes interesadas les ayuda a comprender las consecuencias de sus requisitos establecidos y las decisiones de diseño basadas en ellos. La arquitectura brinda la capacidad de comunicar sobre las decisiones de diseño antes de que se implemente el sistema, cuando aún son relativamente fáciles de adaptar.
• Ayuda a gestionar los riesgos. La arquitectura del software ayuda a reducir los riesgos y las posibilidades de fallos. ^{[14] : 18}
• Permite la reducción de costes . La arquitectura de software es un medio para gestionar los riesgos y los costes en proyectos informáticos complejos. ^[21]

La comparación entre el diseño de software y la arquitectura (civil) se hizo por primera vez a finales de los años 1960, ^[22] pero el término "arquitectura de software" no se utilizó ampliamente hasta los años 1990. ^[23] El campo de la informática había encontrado problemas asociados con la complejidad desde su formación. ^[24] Los problemas anteriores de complejidad fueron resueltos por los desarrolladores eligiendo las estructuras de datos adecuadas , desarrollando algoritmos y aplicando el concepto de separación de preocupaciones . Aunque el término "arquitectura de software" es relativamente nuevo en la industria, los principios fundamentales del campo han sido aplicados esporádicamente por los pioneros de la ingeniería de software desde mediados de los años 1980. Los primeros intentos de capturar y explicar la arquitectura de software de un sistema fueron imprecisos y desorganizados, a menudo caracterizados por un conjunto de diagramas de caja y línea . ^[25]

La arquitectura de software como concepto tiene sus orígenes en la investigación de Edsger Dijkstra en 1968 y David Parnas a principios de la década de 1970. Estos científicos enfatizaron que la estructura de un sistema de software importa y que lograr la estructura correcta es fundamental. Durante la década de 1990 hubo un esfuerzo concertado para definir y codificar aspectos fundamentales de la disciplina, con un trabajo de investigación centrado en estilos arquitectónicos ( patrones ), lenguajes de descripción de la arquitectura , documentación de la arquitectura y métodos formales . ^[26]

Las instituciones de investigación han desempeñado un papel destacado en la promoción de la arquitectura de software como disciplina. Mary Shaw y David Garlan de Carnegie Mellon escribieron un libro titulado Software Architecture: Perspectives on an Emerging Discipline en 1996, que promovía conceptos de arquitectura de software como componentes , conectores y estilos. Los esfuerzos del Instituto de Investigación de Software de la Universidad de California en Irvine en la investigación de la arquitectura de software se dirigen principalmente a los estilos arquitectónicos, los lenguajes de descripción de la arquitectura y las arquitecturas dinámicas.

IEEE 1471-2000 , "Práctica recomendada para la descripción de la arquitectura de sistemas con uso intensivo de software", fue el primer estándar formal en el área de la arquitectura de software. Fue adoptado en 2007 por ISO como ISO/IEC 42010:2007 . En noviembre de 2011, IEEE 1471-2000 fue reemplazado por ISO/IEC/IEEE 42010:2011 , "Ingeniería de sistemas y software: descripción de la arquitectura" (publicado conjuntamente por IEEE e ISO). ^[15]

Mientras que en IEEE 1471 , la arquitectura de software se refería a la arquitectura de "sistemas intensivos en software", definidos como "cualquier sistema en el que el software contribuye con influencias esenciales al diseño, construcción, implementación y evolución del sistema en su conjunto", la edición de 2011 va un paso más allá al incluir las definiciones de sistema de ISO/IEC 15288 e ISO/IEC 12207 , que abarcan no solo hardware y software, sino también "seres humanos, procesos, procedimientos, instalaciones, materiales y entidades naturales". Esto refleja la relación entre la arquitectura de software, la arquitectura empresarial y la arquitectura de soluciones .

Son muchas las actividades que lleva a cabo un arquitecto de software . Normalmente, trabaja con gerentes de proyectos, analiza requisitos arquitectónicamente significativos con las partes interesadas, diseña una arquitectura de software, evalúa un diseño, se comunica con diseñadores y partes interesadas, documenta el diseño arquitectónico y más. ^[27]

Es responsabilidad del arquitecto de software hacer coincidir las características arquitectónicas (también conocidas como requisitos no funcionales ) con los requisitos comerciales. Por ejemplo: ^[5]

• Tener una alta satisfacción del cliente requiere disponibilidad, tolerancia a fallos, seguridad, capacidad de prueba, recuperabilidad, agilidad y rendimiento en el sistema.
• Realizar fusiones y adquisiciones (M&A) requiere extensibilidad, escalabilidad, adaptabilidad e interoperabilidad.
• El presupuesto y el tiempo limitados requieren viabilidad y simplicidad.
• Un tiempo de comercialización más rápido requiere mantenibilidad, capacidad de prueba y capacidad de deploración.

Hay cuatro actividades fundamentales en el diseño de la arquitectura de software. ^[28] Estas actividades fundamentales de la arquitectura se realizan de forma iterativa y en diferentes etapas del ciclo de vida inicial del desarrollo del software, así como a lo largo de la evolución de un sistema.

El análisis arquitectónico es el proceso de comprender el entorno en el que funcionará un sistema propuesto y determinar los requisitos para el sistema. Los datos o requisitos para la actividad de análisis pueden provenir de cualquier número de partes interesadas e incluir elementos como:

• Qué hará el sistema cuando esté operativo (los requisitos funcionales)
• qué tan bien el sistema ejecutará los requisitos no funcionales en tiempo de ejecución, como confiabilidad, operabilidad, eficiencia de rendimiento, seguridad y compatibilidad definidos en la norma ISO/IEC 25010 :2011 ^[29]
• tiempo de desarrollo de requisitos no funcionales como la mantenibilidad y transferibilidad definidos en la norma ISO 25010:2011 ^[29]
• Requisitos comerciales y contextos ambientales de un sistema que pueden cambiar con el tiempo, como preocupaciones legales, sociales, financieras, competitivas y tecnológicas ^[30]

Los resultados de la actividad de análisis son aquellos requisitos que tienen un impacto medible en la arquitectura de un sistema de software, llamados requisitos arquitectónicamente significativos. ^[31]

La síntesis o el diseño arquitectónico es el proceso de creación de una arquitectura. Teniendo en cuenta los requisitos arquitectónicamente significativos determinados por el análisis, el estado actual del diseño y los resultados de cualquier actividad de evaluación, se crea y mejora el diseño. ^{[28] [7] : 311–326}

La evaluación de la arquitectura es el proceso de determinar en qué medida el diseño actual o una parte de él satisface los requisitos derivados durante el análisis. Una evaluación puede ocurrir siempre que un arquitecto esté considerando una decisión de diseño, puede ocurrir después de que se haya completado una parte del diseño, puede ocurrir después de que se haya completado el diseño final o puede ocurrir después de que se haya construido el sistema. Algunas de las técnicas de evaluación de la arquitectura de software disponibles incluyen el método de análisis de compensaciones de la arquitectura (ATAM) y TARA. ^[32] Los marcos para comparar las técnicas se discuten en marcos como el Informe SARA ^[20] y las Revisiones de arquitectura: práctica y experiencia . ^[33]

La evolución de la arquitectura es el proceso de mantenimiento y adaptación de una arquitectura de software existente para satisfacer los cambios en los requisitos y el entorno. Como la arquitectura de software proporciona una estructura fundamental de un sistema de software, su evolución y mantenimiento necesariamente afectarán su estructura fundamental. Por lo tanto, la evolución de la arquitectura se ocupa de agregar nuevas funciones, así como de mantener la funcionalidad existente y el comportamiento del sistema.

La arquitectura requiere actividades de soporte críticas. Estas actividades de soporte se llevan a cabo durante todo el proceso de arquitectura de software central e incluyen la gestión y comunicación del conocimiento, el razonamiento y la toma de decisiones sobre el diseño, y la documentación.

Las actividades de soporte de la arquitectura de software se llevan a cabo durante las actividades básicas de la arquitectura de software. Estas actividades de soporte ayudan al arquitecto de software a realizar análisis, síntesis, evaluación y evolución. Por ejemplo, un arquitecto debe recopilar conocimientos, tomar decisiones y documentar durante la fase de análisis.

• La gestión y comunicación del conocimiento es el acto de explorar y gestionar el conocimiento que es esencial para diseñar una arquitectura de software. Un arquitecto de software no trabaja de forma aislada. Obtiene entradas, requisitos funcionales y no funcionales y contextos de diseño de varias partes interesadas; y proporciona resultados a las partes interesadas. El conocimiento de la arquitectura de software a menudo es tácito y se retiene en las cabezas de las partes interesadas. La actividad de gestión del conocimiento de la arquitectura de software consiste en encontrar, comunicar y retener el conocimiento. Como los problemas de diseño de la arquitectura de software son intrincados e interdependientes, una brecha de conocimiento en el razonamiento de diseño puede conducir a un diseño incorrecto de la arquitectura de software. ^{[27] [34]} Algunos ejemplos de actividades de gestión y comunicación del conocimiento incluyen la búsqueda de patrones de diseño, la creación de prototipos, la consulta a desarrolladores y arquitectos experimentados, la evaluación de los diseños de sistemas similares, el intercambio de conocimientos con otros diseñadores y partes interesadas y la documentación de la experiencia en una página wiki.
• El razonamiento de diseño y la toma de decisiones es la actividad de evaluar las decisiones de diseño. Esta actividad es fundamental para las tres actividades principales de la arquitectura de software. ^{[12] [35]} Implica reunir y asociar contextos de decisión, formular problemas de decisión de diseño, encontrar opciones de solución y evaluar compensaciones antes de tomar decisiones. Este proceso ocurre en diferentes niveles de granularidad de decisión mientras se evalúan requisitos arquitectónicos significativos y decisiones de arquitectura de software, y análisis, síntesis y evaluación de la arquitectura de software. Algunos ejemplos de actividades de razonamiento incluyen comprender los impactos de un requisito o un diseño en los atributos de calidad, cuestionar los problemas que un diseño podría causar, evaluar posibles opciones de solución y evaluar las compensaciones entre soluciones.
• La documentación es el acto de registrar el diseño generado durante el proceso de arquitectura de software. El diseño del sistema se describe utilizando varias vistas que con frecuencia incluyen una vista estática que muestra la estructura del código del sistema, una vista dinámica que muestra las acciones del sistema durante la ejecución y una vista de implementación que muestra cómo se coloca un sistema en el hardware para su ejecución. La vista 4+1 de Kruchten sugiere una descripción de las vistas comúnmente utilizadas para documentar la arquitectura de software; ^[36] Documenting Software Architectures: Views and Beyond tiene descripciones de los tipos de notaciones que podrían usarse dentro de la descripción de la vista. ^[1] Algunos ejemplos de actividades de documentación son escribir una especificación, registrar un modelo de diseño de sistema, documentar una justificación del diseño, desarrollar un punto de vista y documentar vistas.

La descripción de la arquitectura de software implica los principios y prácticas de modelado y representación de arquitecturas, utilizando mecanismos como lenguajes de descripción de arquitectura, puntos de vista de arquitectura y marcos de arquitectura.

Un lenguaje de descripción de arquitectura (ADL) es cualquier medio de expresión utilizado para describir una arquitectura de software ( ISO/IEC/IEEE 42010 ). Desde la década de 1990 se han desarrollado muchos ADL de propósito especial, incluidos AADL (estándar SAE), Wright (desarrollado por Carnegie Mellon), Acme (desarrollado por Carnegie Mellon), xADL (desarrollado por UCI), Darwin (desarrollado por Imperial College London ), DAOP-ADL (desarrollado por la Universidad de Málaga), SBC-ADL (desarrollado por la Universidad Nacional Sun Yat-Sen ) y ByADL (Universidad de L'Aquila, Italia).

Las descripciones de la arquitectura de software se organizan comúnmente en vistas , que son análogas a los diferentes tipos de planos realizados en la arquitectura de edificios . Cada vista aborda un conjunto de preocupaciones del sistema, siguiendo las convenciones de su punto de vista , donde un punto de vista es una especificación que describe las notaciones, el modelado y las técnicas de análisis que se utilizarán en una vista que exprese la arquitectura en cuestión desde la perspectiva de un conjunto determinado de partes interesadas y sus preocupaciones ( ISO/IEC/IEEE 42010 ). El punto de vista especifica no solo las preocupaciones enmarcadas (es decir, que se abordarán), sino también la presentación, los tipos de modelos utilizados, las convenciones utilizadas y cualquier regla de coherencia (correspondencia) para mantener una vista coherente con otras vistas.

Un marco de arquitectura captura las "convenciones, principios y prácticas para la descripción de arquitecturas establecidas dentro de un dominio específico de aplicación y/o comunidad de partes interesadas" ( ISO/IEC/IEEE 42010 ). Un marco se implementa generalmente en términos de uno o más puntos de vista o ADL.

Un patrón arquitectónico es una solución general y reutilizable para un problema que se presenta con frecuencia en la arquitectura de software dentro de un contexto determinado. Los patrones arquitectónicos suelen documentarse como patrones de diseño de software .

Siguiendo la arquitectura de construcción tradicional, un 'estilo arquitectónico de software' es un método específico de construcción, caracterizado por las características que lo hacen notable" ( estilo arquitectónico ).

Un estilo arquitectónico define: una familia de sistemas en términos de un patrón de organización estructural; un vocabulario de componentes y conectores, con restricciones sobre cómo pueden combinarse. ^[37]

Los estilos arquitectónicos son "paquetes" reutilizables de decisiones de diseño y restricciones que se aplican a una arquitectura para inducir cualidades deseables elegidas. ^[38]

Existen muchos patrones y estilos arquitectónicos reconocidos, entre ellos:

• Pizarra
• Patrón de corredor
• Cliente-servidor (2 niveles, 3 niveles , n niveles , la computación en la nube exhibe este estilo)
• Basado en componentes
• Centrado en los datos
• Impulsado por eventos (o invocación implícita )
• Patrón de intérprete
• Arquitectura en capas (o multicapa )
• Amo-esclavo
• Arquitectura de microservicios
• Modelo-vista-controlador
• Aplicación monolítica
• De igual a igual (P2P)
• Tuberías y filtros
• Complementos
• Arquitectura reactiva
• Transferencia de estado representacional (REST)
• Basado en reglas
• Orientado al servicio
• Arquitectura sin nada compartido
• Arquitectura basada en el espacio
• Arquitectura sin servidor

Algunos tratan los patrones arquitectónicos y los estilos arquitectónicos como si fueran lo mismo, ^[39] otros tratan los estilos como especializaciones de los patrones. Lo que tienen en común es que tanto los patrones como los estilos son expresiones idiomáticas que utilizan los arquitectos, "ofrecen un lenguaje común" ^[39] o "vocabulario" ^[37] con el que describir clases de sistemas.

También existe la preocupación de que la arquitectura de software conduzca a un diseño demasiado grande desde el principio , especialmente entre los defensores del desarrollo de software ágil . Se han desarrollado varios métodos para equilibrar las ventajas y desventajas del diseño inicial y la agilidad, ^[40] incluido el método ágil DSDM que exige una fase de "Fundamentos" durante la cual se establecen los cimientos arquitectónicos "suficientes". IEEE Software dedicó un número especial a la interacción entre agilidad y arquitectura.

La erosión de la arquitectura de software se refiere a una brecha gradual entre la arquitectura prevista y la implementada de un sistema de software a lo largo del tiempo. ^[41] El fenómeno de la erosión de la arquitectura de software fue sacado a la luz inicialmente en 1992 por Perry y Wolf junto con su definición de arquitectura de software. ^[3]

La erosión de la arquitectura del software puede ocurrir en cada etapa del ciclo de vida del desarrollo del software y tiene diferentes impactos en la velocidad de desarrollo y el costo de mantenimiento. La erosión de la arquitectura del software ocurre debido a varias razones, como violaciones arquitectónicas , la acumulación de deuda técnica y la vaporización del conocimiento . ^[42] Un caso famoso de erosión de la arquitectura es el fracaso del navegador web Mozilla. ^[43] Mozilla es una aplicación creada por Netscape con una base de código compleja que se volvió más difícil de mantener debido a los cambios continuos. Debido al mal diseño inicial y la creciente erosión de la arquitectura, Netscape pasó dos años rediseñando el navegador web Mozilla, mostrando lo importante que es gestionar la erosión de la arquitectura para evitar grandes esfuerzos de reparación, pérdidas de tiempo y costos.

La erosión de la arquitectura puede reducir el rendimiento del software, aumentar sustancialmente los costos evolutivos y degradar la calidad del software. Se han propuesto varios enfoques y herramientas para detectar la erosión de la arquitectura. Estos enfoques se clasifican principalmente en cuatro categorías: enfoque basado en la consistencia, basado en la evolución, basado en defectos y basado en decisiones. ^[41] Además, las medidas utilizadas para abordar la erosión de la arquitectura contienen dos tipos principales: medidas preventivas y correctivas. ^[41]

La recuperación de la arquitectura de software (o reconstrucción, o ingeniería inversa ) incluye los métodos, técnicas y procesos para descubrir la arquitectura de un sistema de software a partir de la información disponible, incluida su implementación y documentación. La recuperación de la arquitectura suele ser necesaria para tomar decisiones informadas ante la documentación obsoleta o desactualizada y la erosión de la arquitectura: decisiones de implementación y mantenimiento que divergen de la arquitectura prevista. ^[44] Existen prácticas para recuperar la arquitectura de software como el análisis de programas estáticos . Esto es parte de los temas cubiertos por la práctica de inteligencia de software .

La arquitectura es diseño , pero no todo diseño es arquitectónico. ^[1] En la práctica, el arquitecto es quien traza la línea entre la arquitectura de software (diseño arquitectónico) y el diseño detallado (diseño no arquitectónico). No existen reglas ni pautas que se ajusten a todos los casos, aunque ha habido intentos de formalizar la distinción. Según la Hipótesis de Intensión/Localidad , ^[45] la distinción entre diseño arquitectónico y detallado está definida por el Criterio de Localidad , ^[45] según el cual una afirmación sobre el diseño de software es no local (arquitectónica) si y solo si un programa que la satisface puede expandirse a un programa que no la satisface. Por ejemplo, el estilo cliente-servidor es arquitectónico (estratégico) porque un programa que se construye sobre este principio puede expandirse a un programa que no sea cliente-servidor, por ejemplo, agregando nodos peer-to-peer .

La ingeniería de requisitos y la arquitectura de software pueden considerarse enfoques complementarios: mientras que la arquitectura de software se centra en el " espacio de la solución " o el "cómo", la ingeniería de requisitos se ocupa del " espacio del problema " o el "qué". ^[46] La ingeniería de requisitos implica la obtención , negociación , especificación , validación , documentación y gestión de requisitos . Tanto la ingeniería de requisitos como la arquitectura de software giran en torno a las preocupaciones, necesidades y deseos de las partes interesadas .

Existe una superposición considerable entre la ingeniería de requisitos y la arquitectura de software, como lo demuestra, por ejemplo, un estudio sobre cinco métodos de arquitectura de software industrial que concluye que "las entradas (objetivos, restricciones, etc.) generalmente están mal definidas y solo se descubren o entienden mejor cuando la arquitectura comienza a surgir" y que, si bien "la mayoría de las preocupaciones arquitectónicas se expresan como requisitos en el sistema, también pueden incluir decisiones de diseño obligatorias" . ^[28] En resumen, el comportamiento requerido impacta la arquitectura de la solución, que a su vez puede introducir nuevos requisitos. ^[47] Enfoques como el modelo Twin Peaks ^[48] tienen como objetivo explotar la relación sinérgica entre los requisitos y la arquitectura.

Arquitectura de computadoras

La arquitectura de computadoras se centra en la estructura interna de un sistema informático, en términos de componentes de hardware que colaboran entre sí, como la CPU (o procesador), el bus y la memoria .

Arquitectura sin servidor

La arquitectura sin servidor es un paradigma de computación en la nube que a menudo se malinterpreta como una arquitectura sin servidor. Básicamente, traslada las responsabilidades de administración de servidores de los desarrolladores a los proveedores de servicios en la nube. Esto permite a las empresas ejecutar su código de backend en la infraestructura de la nube, eliminando la necesidad de administración física del servidor. El enfoque impulsado por eventos de la arquitectura sin servidor se basa en pequeñas funciones específicas de la tarea que se ejecutan a pedido. Estas funciones se conocen como Función como servicio (FaaS) y ofrecen rentabilidad a través de un modelo de facturación de pago por uso y escalamiento dinámico de recursos basado en la demanda de la aplicación. ^{[49] [ se necesita una mejor fuente ]}

Arquitectura de sistemas

El término arquitectura de sistemas se ha aplicado originalmente a la arquitectura de sistemas que constan tanto de hardware como de software . La principal preocupación que aborda la arquitectura de sistemas es entonces la integración de software y hardware en un dispositivo completo y que funcione correctamente. En otro sentido común, mucho más amplio, el término se aplica a la arquitectura de cualquier sistema complejo que pueda ser de naturaleza técnica, sociotécnica o social.

Arquitectura empresarial

El objetivo de la arquitectura empresarial es "traducir la visión y la estrategia empresarial en una empresa eficaz". Los marcos de arquitectura empresarial , como TOGAF y el marco Zachman , suelen distinguir entre diferentes capas de arquitectura empresarial. Aunque la terminología difiere de un marco a otro, muchos incluyen al menos una distinción entre una capa empresarial , una capa de aplicación (o información ) y una capa tecnológica . La arquitectura empresarial aborda, entre otras cosas, la alineación entre estas capas, normalmente con un enfoque de arriba hacia abajo.

• Richards, Mark (2020). Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media . ISBN 9781492043454.
• Len, Bass (2012). Arquitectura de software en la práctica (3.ª ed.). Addison-Wesley Professional . ISBN 9780321815736.- Este libro cubre los conceptos fundamentales de la disciplina. La temática se centra en lograr atributos de calidad de un sistema.
• Clements, Paul (2010). Documentación de arquitecturas de software: vistas y más allá (2.ª ed.). Addison-Wesley Professional . ISBN 9780321552686.- Este libro describe qué es la arquitectura de software y muestra cómo documentarla en múltiples vistas, utilizando UML y otras notaciones. También explica cómo complementar las vistas de arquitectura con documentación de comportamiento, interfaz de software y fundamentos. Junto con el libro hay una wiki que contiene un ejemplo de documentación de arquitectura de software.
• Bell, Michael (2008). Bell, Michael (ed.). Modelado orientado a servicios: análisis, diseño y arquitectura de servicios . Wiley. doi :10.1002/9781119198864. ISBN 9780470255704.
• Shan, Tony; Hua, Winnie (octubre de 2006). "Mecanismo de arquitectura de soluciones". 2006 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC'06) . págs. 23–32. doi :10.1109/EDOC.2006.54. ISBN 978-0-7695-2558-7.S2CID8361936  .​
• Garzás, Javier; Piattini, Mario (2005). "Una ontología para el conocimiento del diseño microarquitectónico". IEEE Software . 22 (2): 28–33. doi :10.1109/MS.2005.26. S2CID  17639072.
• Fowler, Martin (septiembre de 2003). "¿Quién necesita un arquitecto?" (PDF) . IEEE Software . 20 (5). doi :10.1109/MS.2003.1231144. S2CID  356506.
• Kazman, Rick (mayo de 2003). "Arquitectura, diseño, implementación" (PDF) . Instituto de Ingeniería de Software . Archivado (PDF) desde el original el 21 de septiembre de 2015.- Sobre la distinción entre diseño arquitectónico y diseño detallado.
• Kruchten, Philippe (1995). "Architectural Blueprints – The '4+1' View Model of Software Architecture" (PDF) . IEEE Software . 12 (6): 42–50. arXiv : 2006.04975 . doi :10.1109/52.469759. S2CID  219558624. Archivado (PDF) desde el original el 13 de junio de 2006.
• Pautasso, Cesare (2020). Arquitectura de software: notas visuales de clase. LeanPub. pág. 689.

Wikimedia Commons tiene medios relacionados con Arquitectura de software .

Wikiquote tiene citas relacionadas con Arquitectura de software .

• Explicación sobre IBM Developerworks
• Recopilación de definiciones de arquitectura de software en el Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon (CMU)
• Asociación Internacional de Arquitectos de TI (IASA Global), anteriormente conocida como Asociación Internacional de Arquitectos de Software (IASA)
• SoftwareArchitecturePortal.org – sitio web del Grupo de trabajo 2.10 de IFIP sobre arquitectura de software
• SoftwareArchitectures.com – un recurso independiente de información sobre la disciplina
• Arquitectura de software, capítulo 1 de la tesis REST de Roy Fielding
• Cuando la buena arquitectura se vuelve mala
• Desarrollo impulsado por arquitectura en espiral: el SDLC basado en el modelo en espiral tiene como objetivo reducir los riesgos de una arquitectura ineficaz.
• Casos prácticos de arquitectura de software en la vida real