Estructuras de alto nivel de un sistema 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]
Todo es un intercambio
"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]
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]
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
Características
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 ).
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 .
Motivación
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 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 .
Actividades de arquitectura
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]
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.
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.
Actividades de apoyo a la arquitectura
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.
Temas de arquitectura de software
Descripción de la arquitectura del software
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.
Lenguajes de descripción 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.
Marcos de arquitectura
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.
Estilos y patrones arquitectónicos
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:
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.
Arquitectura de software y desarrollo ágil
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.
Erosión de la arquitectura del software
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]
Recuperación de la arquitectura del software
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 .
Campos relacionados
Diseño
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 .
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.
Otros tipos de '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.
^ abc Clements, Paul; Felix Bachmann; Len Bass ; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford (2010). Documentación de arquitecturas de software: vistas y más allá, segunda edición . Boston: Addison-Wesley. ISBN 978-0-321-55268-6.
^ "Arquitectura de software". www.sei.cmu.edu . Consultado el 23 de julio de 2018 .
^ Arquitectura de software Head First . O'Reilly Media. 2024. ISBN978-1098134358.
^ abcd Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN978-1492043454.
^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN9781492043423.
^ abcdefghij Bass, Len; Paul Clements; Rick Kazman (2012). Arquitectura de software en la práctica, tercera edición . Boston: Addison-Wesley. ISBN978-0-321-81573-6.
^ SEI (2006). "¿Cómo se define la arquitectura de software?" . Consultado el 12 de septiembre de 2012 .
^ Garlan & Shaw (1994). "Introducción a la arquitectura de software" (PDF) . Consultado el 13 de septiembre de 2012 .
^ ab Fowler, Martin (2003). "Diseño: ¿Quién necesita un arquitecto?". IEEE Software . 20 (5): 11–44. doi :10.1109/MS.2003.1231144. S2CID 356506.
^ ISO/IEC/IEEE 42010: Definición de "arquitectura". Iso-architecture.org. Consultado el 21 de julio de 2013.
^ ab Jansen, A.; Bosch, J. (2005). "Arquitectura de software como un conjunto de decisiones de diseño arquitectónico". 5.ª Conferencia de trabajo IEEE/IFIP sobre arquitectura de software (WICSA'05) . pág. 109. CiteSeerX 10.1.1.60.8680 . doi :10.1109/WICSA.2005.61. ISBN978-0-7695-2548-8. Número de identificación del sujeto 13492610.
^ Ali Babar, Mahoma; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans (2009). Gestión del conocimiento de la arquitectura de software . Dordrecht Heidelberg Londres Nueva York: Springer. ISBN978-3-642-02373-6.
^ abc George Fairbanks (2010). Arquitectura de software suficiente . Marshall & Brainerd.
^ ab ISO/IEC/IEEE (2011). «ISO/IEC/IEEE 42010:2011 Ingeniería de sistemas y software – Descripción de la arquitectura» . Consultado el 12 de septiembre de 2012 .
^ Muller, Gerrit (20 de agosto de 2007). "A Reference Architecture Primer" (PDF) . Sitio de Gaudí . Archivado (PDF) del original el 19 de diciembre de 2011. Consultado el 13 de noviembre de 2015 .
^ Angelov, S.; Grefen, P.; Greefhorst, D. (2009). "Una clasificación de arquitecturas de referencia de software: análisis de su éxito y eficacia". Conferencia de trabajo conjunto IEEE/IFIP de 2009 sobre arquitectura de software y Conferencia europea sobre arquitectura de software. IEEE. págs. 141–150. doi :10.1109/WICSA.2009.5290800. ISBN .978-1-4244-4984-2. Recuperado el 15 de diciembre de 2023 .
^ Conway, Melvin. "Ley de Conway". Página de inicio de Mel Conway . Archivado desde el original el 2019-09-29 . Consultado el 2019-09-29 .
^ ab Obbink, H.; Kruchten, P.; Kozaczynski, W.; Postema, H.; Ran, A.; Dominick, L.; Kazman, R.; Hilliard, R.; Tracz, W.; Kahane, E. (6 de febrero de 2002). "Informe de revisión y evaluación de la arquitectura de software (SARA)" (PDF) . Consultado el 1 de noviembre de 2015 .
^ Poort, Eltjo; van Vliet, Hans (septiembre de 2012). "RCDA: la arquitectura como disciplina de gestión de riesgos y costes". Journal of Systems and Software . 85 (9): 1995–2013. doi :10.1016/j.jss.2012.03.071.
^ P. Naur; B. Randell, eds. (1969). "Ingeniería de software: Informe de una conferencia patrocinada por el Comité Científico de la OTAN, Garmisch, Alemania, 7-11 de octubre de 1968" (PDF) . Bruselas: División de Asuntos Científicos de la OTAN. Archivado (PDF) desde el original el 7 de junio de 2003. Consultado el 16 de noviembre de 2012 .
^ P. Kruchten; H. Obbink; J. Stafford (2006). "El pasado, presente y futuro de la arquitectura de software". IEEE Software . 23 (2): 22. doi :10.1109/MS.2006.59. S2CID 2082927.
^ Universidad de Waterloo (2006). "Una breve historia de la informática" . Consultado el 23 de septiembre de 2006 .
^ "Introducción al número especial sobre arquitectura de software". IEEE.org . 2006. doi :10.1109/TSE.1995.10003.
^ Garlan & Shaw (1994). "Introducción a la arquitectura de software" (PDF) . Consultado el 25 de septiembre de 2006 .
^ ab Kruchten, P. (2008). "¿Qué hacen realmente los arquitectos de software?". Journal of Systems and Software . 81 (12): 2413–2416. doi :10.1016/j.jss.2008.08.025.
^ abc Christine Hofmeister; Philippe Kruchten; Robert L. Nord; Henk Obbink; Alexander Ran; Pierre America (2007). "Un modelo general de diseño de arquitectura de software derivado de cinco enfoques industriales". Journal of Systems and Software . 80 (1): 106–126. doi :10.1016/j.jss.2006.05.024.
^ ab ISO/IEC (2011). «ISO/IEC 25010:2011 Ingeniería de sistemas y software – Requisitos y evaluación de la calidad de sistemas y software (SQuaRE) – Modelos de calidad de sistemas y software» . Consultado el 8 de octubre de 2012 .
^ Osterwalder y Pigneur (2004). "Una ontología para los modelos de comercio electrónico" (PDF) . Creación de valor a partir de modelos de comercio electrónico . pp. 65–97. CiteSeerX 10.1.1.9.6922 . doi :10.1016/B978-075066140-9/50006-0. ISBN .9780750661409. S2CID 14177438. Archivado desde el original (PDF) el 17 de noviembre de 2018.
^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Caracterización de requisitos arquitectónicamente significativos". IEEE Software . 30 (2): 38–45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID 17399565.
^ Woods, E. (2012). "Evaluación de arquitectura industrial utilizando TARA". Revista de sistemas y software . 85 (9): 2034–2047. doi :10.1016/j.jss.2012.04.055. S2CID 179244.
^ Maranzano, JF; Rozsypal, SA; Zimmerman, GH; Warnken, GW; Wirth, PE; Weiss, DM (2005). "Revisiones de arquitectura: práctica y experiencia". IEEE Software . 22 (2): 34. doi :10.1109/MS.2005.28. S2CID 11697335.
^ Babar, MA; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). Gestión del conocimiento de la arquitectura de software: teoría y práctica (eds.), primera edición . Springer. ISBN978-3-642-02373-6.
^ Tang, A.; Han, J.; Vasa, R. (2009). "Razonamiento de diseño de arquitectura de software: un caso para mejorar el soporte metodológico". IEEE Software . 26 (2): 43. doi :10.1109/MS.2009.46. hdl :1959.3/51601. S2CID 12230032.
^ 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.
^ ab Shaw, Mary; Garlan, David (1996). Arquitectura de software: perspectivas sobre una disciplina emergente . Prentice Hall. ISBN978-0-13-182957-2.
^ UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles. Isr.uci.edu. Recuperado el 21 de julio de 2013.
^ ab Capítulo 3: Patrones y estilos arquitectónicos. Msdn.microsoft.com. Recuperado el 21 de julio de 2013.
^ Boehm, Barry; Turner, Richard (2004). Equilibrar la agilidad y la disciplina . Addison-Wesley. ISBN978-0-321-18612-6.
^ abc Li, Ruiyin; Liang, Peng; Soliman, Mohamed; Avgeriou, Paris (2022). "Comprensión de la erosión de la arquitectura de software: un estudio de mapeo sistemático". Journal of Software: Evolution and Process . 34 (3): e2423. arXiv : 2112.10934 . doi :10.1002/smr.2423.
^ Li, Ruiyin; Liang, Peng; Soliman, Mohamed; Avgeriou, París (2021). "Entender la erosión de la arquitectura: la percepción de los profesionales". 29.ª Conferencia Internacional IEEE/ACM sobre Comprensión de Programas (ICPC). págs. 311–322. doi :10.1109/icpc52881.2021.00037.
^ van Gurp, J. y Bosch, J.: 2002, Erosión del diseño: problemas y causas, Journal of Systems and Software 61(2), 105–119.
^
Lungu, M. "Recuperación de la arquitectura del software", Universidad de Lugano, 2008. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
^ de Amnon H. Eden; Rick Kazman (2003). "Implementación del diseño arquitectónico" (PDF) . Archivado desde el original (PDF) el 28 de septiembre de 2007.
^ C. Shekaran; D. Garlan; M. Jackson; NR Mead; C. Potts; HB Reubenstein (1994). "El papel de la arquitectura de software en la ingeniería de requisitos". Actas de la Conferencia Internacional IEEE sobre Ingeniería de Requisitos . págs. 239–245. doi :10.1109/ICRE.1994.292379. ISBN978-0-8186-5480-0. Número de identificación del sujeto 3129363.
^ Remco C. de Boer, Hans van Vliet (2009). "Sobre la similitud entre requisitos y arquitectura". Revista de Sistemas y Software . 82 (3): 544–550. CiteSeerX 10.1.1.415.6023 . doi :10.1016/j.jss.2008.11.185.
^ Bashar Nuseibeh (2001). "Tejiendo juntos requisitos y arquitecturas" (PDF) . Computer . 34 (3): 115–119. doi :10.1109/2.910904. Archivado (PDF) desde el original el 7 de septiembre de 2012.
^ Empresa, DashDevs | Desarrollo de software de tecnología financiera. "Cómo utilizar la arquitectura sin servidor | DashDevs". Cómo utilizar la arquitectura sin servidor | DashDevs . Consultado el 28 de agosto de 2023 .{{cite web}}: |last=tiene nombre genérico ( ayuda )
Lectura adicional
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.
Enlaces externos
Wikimedia Commons tiene medios relacionados con Arquitectura de software .
Wikiquote tiene citas relacionadas con 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
