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 tanto de los elementos como de las 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 opciones de arquitectura de software incluyen opciones estructurales específicas de las posibilidades en el diseño del software . Hay dos leyes fundamentales en la arquitectura de software: [4] [5]
Todo es una compensación
"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 componentes arquitectónicos los enreda y deben compartir las mismas características arquitectónicas. [6]
Documentar 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 comúnmente se yuxtapone 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 datos que respaldan la funcionalidad requerida (los servicios ofrecidos por el sistema), el diseño de la arquitectura de software se centra en diseñar la infraestructura dentro de la cual se puede realizar y ejecutar la funcionalidad de la aplicación de manera que la funcionalidad se proporcione de una manera 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 : esto se refiere a la arquitectura como una abstracción de nivel superior de un sistema de software que consta de 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 gran impacto en el sistema y sus partes interesadas. [10]
Lo fundamental para comprender un sistema en su entorno [11]
Cosas que la gente percibe como difíciles de cambiar : dado que el diseño de la arquitectura tiene lugar al comienzo del ciclo de vida de un sistema de software, el arquitecto debe centrarse en decisiones que "tienen que" ser correctas la primera vez. Siguiendo esta línea de pensamiento, las cuestiones de diseño arquitectónico pueden volverse no arquitectónicas 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 llevado a una investigación sustancial sobre la gestión del conocimiento de la arquitectura de software . [13]
No existe una distinción clara entre arquitectura de software versus diseño e ingeniería de requisitos (consulte Campos relacionados a continuación). Todos ellos son 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 atender a una 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 abordan 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 para que los arquitectos reduzcan 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 (ver, por ejemplo, el modelo de vista arquitectónica 4+1 ).
Estilos recurrentes: al igual que la arquitectura de edificios, la disciplina de arquitectura de software ha desarrollado formas estándar de abordar inquietudes recurrentes. Estas "formas estándar" reciben varios nombres en distintos niveles de abstracción. Los términos comunes para 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 debe separarse 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 obligadas a producir diseños que sean 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 representa un ahorro sustancial de costos y una mitigación de riesgos. [20] Se han desarrollado varias técnicas para realizar tales 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 estrategias y decisiones arquitectónicas individuales, se pueden reutilizar en múltiples sistemas cuyas partes interesadas requieren atributos de calidad o funcionalidad similares, ahorrando costos de diseño y mitigando el riesgo de diseño. errores.
Respalda las decisiones tempranas de diseño que afectan el desarrollo, la implementación y la vida útil del mantenimiento de un sistema. [7] : 31 Es importante tomar decisiones tempranas y de alto impacto para evitar excesos en 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 Comunicar sobre sistemas complejos desde el punto de vista de las partes interesadas les ayuda a comprender las consecuencias de sus requisitos declarados y las decisiones de diseño basadas en ellos. La arquitectura brinda la capacidad de comunicar acerca de las decisiones de diseño antes de implementar el sistema, cuando todavía son relativamente fáciles de adaptar.
Ayuda en la gestión de riesgos. La arquitectura de software ayuda a reducir los riesgos y las posibilidades de fallo. [14] : 18
Permite reducir costes . La arquitectura de software es un medio para gestionar riesgos y costos en proyectos de TI complejos. [21]
Historia
La comparación entre diseño de software y arquitectura (civil) se hizo por primera vez a finales de la década de 1960, [22] pero el término "arquitectura de software" no tuvo un uso generalizado hasta la década de 1990. [23] El campo de la informática había encontrado problemas asociados con la complejidad desde su formación. [24] Los desarrolladores resolvieron problemas anteriores de complejidad eligiendo las estructuras de datos correctas , 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íneas . [25]
La arquitectura de software como concepto tiene su origen en las investigaciones de Edsger Dijkstra en 1968 y David Parnas a principios de los años 1970. Estos científicos enfatizaron que la estructura de un sistema de software es importante 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 el trabajo de investigación concentrándose en estilos arquitectónicos ( patrones ), lenguajes de descripción arquitectónica , documentación arquitectónica y métodos formales . [26]
IEEE 1471 -2000, "Práctica recomendada para la descripción de la arquitectura de sistemas intensivos en software", fue el primer estándar formal en el área de la arquitectura de software. Fue adoptada en 2007 por ISO como ISO/IEC 42010:2007 . En noviembre de 2011, IEEE 1471–2000 fue reemplazada por ISO/IEC/IEEE 42010:2011 , "Ingeniería de software y sistemas - Descripción de la arquitectura" (publicada 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 donde el software aporta 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 ISO/IEC 15288 e ISO/IEC 12207 , que abarcan no sólo hardware y software, sino también "humanos, procesos, procedimientos, instalaciones, materiales y entidades naturales". Esto refleja la relación entre arquitectura de software, arquitectura empresarial y arquitectura de soluciones .
Actividades de arquitectura
Son muchas las actividades que realiza un arquitecto de software . Un arquitecto de software normalmente trabaja con gerentes de proyectos, analiza requisitos arquitectónicamente importantes 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
Un presupuesto y un tiempo limitados requieren viabilidad y simplicidad
Hay cuatro actividades principales en el diseño de arquitectura de software. [28] Estas actividades de arquitectura central se realizan de forma iterativa y en diferentes etapas del ciclo de vida inicial del desarrollo de 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 operará un sistema propuesto y determinar los requisitos del sistema. Los aportes o requisitos para la actividad de análisis pueden provenir de cualquier número de partes interesadas e incluir elementos tales como:
Qué hará el sistema cuando esté operativo (los requisitos funcionales).
qué tan bien el sistema funcionará en tiempo de ejecución requisitos no funcionales como confiabilidad, operatividad, eficiencia del rendimiento, seguridad, compatibilidad definida en el estándar ISO/IEC 25010 :2011 [29]
tiempo de desarrollo de requisitos no funcionales como la mantenibilidad y la 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 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, el diseño se crea y mejora. [28] [7] : 311–326
La evaluación de la arquitectura es el proceso de determinar qué tan bien el diseño actual o una parte del mismo 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 arquitectura de software disponibles incluyen el Método de análisis de compensación de arquitectura (ATAM) y TARA. [32] Los marcos para comparar las técnicas se analizan en marcos como SARA Report [20] y Architecture Reviews: Practice and Experience . [33]
La evolución de la arquitectura es el proceso de mantener y adaptar una arquitectura de software existente para cumplir con 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ían su estructura fundamental. Como tal, la evolución de la arquitectura se ocupa de agregar nuevas funciones, así como de mantener la funcionalidad y el comportamiento del sistema existentes.
La arquitectura requiere actividades de apoyo críticas. Estas actividades de soporte se llevan a cabo durante todo el proceso de arquitectura del software central. Incluyen gestión y comunicación del conocimiento, razonamiento de diseño y toma de decisiones, y documentación.
Actividades de apoyo a la arquitectura.
Las actividades de soporte a la arquitectura de software se llevan a cabo durante las actividades centrales de arquitectura de software. Estas actividades de apoyo ayudan a un arquitecto de software a realizar análisis, síntesis, evaluación y evolución. Por ejemplo, un arquitecto tiene que 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. Reciben aportaciones, requisitos funcionales y no funcionales y contextos de diseño de diversas partes interesadas; y proporcionar resultados a las partes interesadas. El conocimiento de la arquitectura de software suele ser tácito y se conserva en la cabeza de las partes interesadas. La actividad de gestión del conocimiento de la arquitectura de software consiste en encontrar, comunicar y retener conocimientos. Como los problemas de diseño de la arquitectura de software son complejos e interdependientes, una brecha de conocimiento en el razonamiento del diseño puede conducir a un diseño de arquitectura de software incorrecto. [27] [34] Ejemplos de actividades de comunicación y gestión del conocimiento incluyen la búsqueda de patrones de diseño, la creación de prototipos, preguntar a desarrolladores y arquitectos experimentados, evaluar los diseños de sistemas similares, compartir conocimientos con otros diseñadores y partes interesadas y documentar la experiencia en una página wiki.
El razonamiento del 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 decisiones mientras se evalúan requisitos arquitectónicos importantes y decisiones de arquitectura de software, y análisis, síntesis y evaluación de la arquitectura de software. 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 del software. El diseño del sistema se describe utilizando varias vistas que frecuentemente 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 visión 4+1 de Kruchten sugiere una descripción de las vistas comúnmente utilizadas para documentar la arquitectura del software; [36] Documentación de arquitecturas de software: vistas y más allá tiene descripciones de los tipos de notaciones que podrían usarse dentro de la descripción de la vista. [1] 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, 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 trabajo 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 muchas ADL para fines especiales, incluidas AADL (estándar SAE), Wright (desarrollado por Carnegie Mellon), Acme (desarrollado por Carnegie Mellon), xADL (desarrollado por UCI), Darwin (desarrollado por el 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 del software comúnmente se organizan 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 a utilizar en una vista que expresa la arquitectura en cuestión desde la perspectiva de un conjunto determinado. de las partes interesadas y sus preocupaciones ( ISO/IEC/IEEE 42010 ). El punto de vista especifica no sólo las preocupaciones formuladas (es decir, las que deben abordarse), sino también la presentación, los tipos de modelos utilizados, las convenciones utilizadas y cualquier regla de coherencia (correspondencia) para mantener una visión 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 generalmente se implementa 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 a un problema que ocurre comúnmente en la arquitectura de software dentro de un contexto determinado. Los patrones arquitectónicos a menudo se documentan como patrones de diseño de software .
Siguiendo la arquitectura de construcción tradicional, un 'estilo arquitectónico software' es un método de construcción específico, 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 se pueden combinar. [37]
Los estilos arquitectónicos son "paquetes" reutilizables de decisiones y restricciones de diseño que se aplican a una arquitectura para inducir las 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 lo mismo, [39] algunos tratan los estilos como especializaciones de patrones. Lo que tienen en común es que tanto los patrones como los estilos son modismos que pueden utilizar los arquitectos, "proporcionan 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 colocan 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 de 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 impactos variables en la velocidad de desarrollo y el costo de mantenimiento. La erosión de la arquitectura del software se produce debido a diversas razones, como violaciones de la arquitectura , acumulación de deuda técnica y vaporización del conocimiento . [42] Un caso famoso de erosión de la arquitectura es el fallo 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 continuos cambios. Debido al mal diseño inicial y la creciente erosión de la arquitectura, Netscape pasó dos años redesarrollando el navegador web Mozilla, demostrando 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 disminuir 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 arquitectónica. Estos enfoques se clasifican principalmente en cuatro categorías: enfoque basado en consistencia, basado en 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 arquitectura de software
La recuperación (o reconstrucción, o ingeniería inversa ) de la arquitectura de software 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 a menudo es 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 imaginada. [44] Existen prácticas para recuperar la arquitectura de software como análisis de programas estáticos . Esta es una 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 o 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 sólo si un programa que satisface, se puede ampliar a un programa que no lo hace. Por ejemplo, el estilo cliente-servidor es arquitectónico (estratégico) porque un programa que se basa en este principio se puede expandir a un programa que no sea cliente-servidor, por ejemplo, agregando nodos de igual a igual .
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.) suelen estar mal definidas y sólo se descubren o mejoran entendido cuando la arquitectura comienza a emerger" y que si bien "la mayoría de las preocupaciones arquitectónicas se expresan como requisitos del sistema, también pueden incluir decisiones de diseño obligatorias" . [28] En resumen, el comportamiento requerido afecta la arquitectura de la solución, lo 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 requisitos y arquitectura.
Otros tipos de 'arquitectura'
Arquitectura informática
La arquitectura informática apunta a la estructura interna de un sistema informático, en términos de componentes de hardware colaborativos 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 libre de servidores. Básicamente, transfiere las responsabilidades de gestión del servidor de los desarrolladores a los proveedores de servicios en la nube. Esto permite a las empresas ejecutar su código backend en la infraestructura de la nube, eliminando la necesidad de administración de servidores físicos. El enfoque basado en eventos de la arquitectura sin servidor se basa en pequeñas funciones específicas de tareas que se ejecutan bajo demanda. 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 aplicó 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 significado común –mucho más amplio–, el término se aplica a la arquitectura de cualquier sistema complejo que puede 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 Zachman Framework , generalmente distinguen 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 Clementes, Paul; Félix Bachmann; Len Bass ; David Garlan; James Ivers; Caña pequeña; Paulo Mersón; 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 .
^ Head First Arquitectura de software . Medios O'Reilly. 2024.ISBN978-1098134358.
^ abcd Fundamentos de la arquitectura de software: un enfoque de ingeniería . Medios O'Reilly. 2020. ISBN978-1492043454.
^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . Medios O'Reilly. 2020.ISBN9781492043423.
^ abcdefghij Bajo, Len; Pablo Clementes; 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 y Shaw (1994). "Introducción a la arquitectura de software" (PDF) . Consultado el 13 de septiembre de 2012 .
^ ab Fowler, Martín (2003). "Diseño - ¿Quién necesita un arquitecto?". Software IEEE . 20 (5): 11–44. doi :10.1109/MS.2003.1231144. S2CID 356506.
^ ISO/IEC/IEEE 42010: Definición de "arquitectura". Iso-arquitectura.org. Recuperado el 21 de julio de 2013.
^ ab Jansen, A.; Bosch, J. (2005). "Arquitectura del software como conjunto de decisiones de diseño arquitectónico". Quinta Conferencia de trabajo IEEE/IFIP sobre arquitectura de software (WICSA'05) . pag. 109. CiteSeerX 10.1.1.60.8680 . doi :10.1109/WICSA.2005.61. ISBN978-0-7695-2548-8. S2CID 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.
^ a b C George Fairbanks (2010). Arquitectura de software suficiente . Marshall y Brainerd.
^ ab ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Ingeniería de software y sistemas - Descripción de la arquitectura" . Consultado el 12 de septiembre de 2012 .
^ Muller, Gerrit (20 de agosto de 2007). "Introducción a la arquitectura de referencia" (PDF) . Sitio de Gaudí . Archivado (PDF) desde el 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: analizando su éxito y eficacia". 2009 Conferencia de trabajo conjunto IEEE/IFIP sobre arquitectura de software y conferencia europea sobre arquitectura de software. IEEE. págs. 141-150. doi :10.1109/WICSA.2009.5290800. ISBN978-1-4244-4984-2. Consultado el 15 de diciembre de 2023 .
^ Conway, Melvin. "Ley de Conway". Página de inicio de Mel Conway . Archivado desde el original el 29 de septiembre de 2019 . Consultado el 29 de septiembre de 2019 .
^ ab Obbink, H.; Kruchten, P.; Kozaczynski, W.; Postema, H.; Corrió, A.; Dominick, L.; Kazmán, 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 .
^ Pobre, Eltjo; van Vliet, Hans (septiembre de 2012). "RCDA: La arquitectura como disciplina de gestión de riesgos y costes". Revista de Sistemas y 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 a 11 de octubre de 1968" (PDF) . Bruselas: OTAN, División de Asuntos Científicos. 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". Software IEEE . 23 (2): 22. doi :10.1109/MS.2006.59. S2CID 2082927.
^ Universidad de Waterloo (2006). "Una muy 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 y 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?". Revista de Sistemas y Software . 81 (12): 2413–2416. doi :10.1016/j.jss.2008.08.025.
^ a b C Christine Hofmeister; Philippe Kruchten; Robert L. Nord; Henk Obbink; Alejandro corrió; Pierre América (2007). "Un modelo general de diseño de arquitectura de software derivado de cinco enfoques industriales". Revista de Sistemas y Software . 80 (1): 106–126. doi :10.1016/j.jss.2006.05.024.
^ abISO/IEC (2011). "ISO/IEC 25010:2011 Ingeniería de software y sistemas - Evaluación y requisitos de calidad de software y sistemas (SQuaRE) - Modelos de calidad de software y sistemas" . Consultado el 8 de octubre de 2012 .
^ Osterwalder y Pigneur (2004). "Una ontología para modelos de negocio electrónico" (PDF) . Creación de valor a partir de modelos de negocio electrónico . págs. 65–97. CiteSeerX 10.1.1.9.6922 . doi :10.1016/B978-075066140-9/50006-0. ISBN9780750661409. S2CID 14177438. Archivado desde el original (PDF) el 17 de noviembre de 2018.
^ Chen, Lianping; Ali Babar, Mahoma; Nuseibeh, Bashar (2013). "Caracterización de requisitos arquitectónicamente significativos". Software IEEE . 30 (2): 38–45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID 17399565.
^ Maderas, E. (2012). “Evaluación de arquitectura industrial mediante 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). "Reseñas de arquitectura: práctica y experiencia". Software IEEE . 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 . Saltador. ISBN978-3-642-02373-6.
^ Tang, A.; Han, J.; Vasa, R. (2009). "Razonamiento del diseño de la arquitectura de software: un caso para mejorar el soporte metodológico". Software IEEE . 26 (2): 43. doi :10.1109/MS.2009.46. hdl :1959.3/51601. S2CID 12230032.
^ Kruchten, Philippe (1995). "Planos arquitectónicos: el modelo de vista '4 + 1' de arquitectura de software" (PDF) . Software IEEE . 12 (6): 42–50. arXiv : 2006.04975 . doi : 10.1109/52.469759. S2CID 219558624.
^ ab Shaw, María; Garlan, David (1996). Arquitectura de software: perspectivas sobre una disciplina emergente . Prentice Hall. ISBN978-0-13-182957-2.
^ Investigación de arquitectura de software de la UCI - Investigación de arquitectura de software de la UCI: estilos arquitectónicos. 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). Equilibrando agilidad y disciplina . Addison-Wesley. ISBN978-0-321-18612-6.
^ abc Li, Ruiyin; Liang, Peng; Solimán, Mohamed; Avgeriou, París (2022). "Comprensión de la erosión de la arquitectura de software: un estudio de mapeo sistemático". Revista de software: evolución y proceso . 34 (3): e2423. arXiv : 2112.10934 . doi :10.1002/smr.2423.
^ Li, Ruiyin; Liang, Peng; Solimán, Mohamed; Avgeriou, París (2021). "Comprender la erosión de la arquitectura: la percepción de los profesionales". La 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 arquitectura de software", Universidad de Lugano, 2008. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
^ ab Amnón H. Edén; Rick Kazman (2003). "Implementación del Diseño de Arquitectura" (PDF) . Archivado desde el original (PDF) el 28 de septiembre de 2007.
^ C. Shekaran; D. Garlan; M. Jackson; NR hidromiel; 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. S2CID 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 requisitos y arquitecturas" (PDF) . Computadora . 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 FinTech. "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, Marcos (2020). Fundamentos de la arquitectura de software: un enfoque de ingeniería . Medios O'Reilly . ISBN 9781492043454.
Len, bajo (2012). Arquitectura de software en la práctica (3ª ed.). Profesional de Addison-Wesley . ISBN 9780321815736.- Este libro cubre los conceptos fundamentales de la disciplina. El tema se centra en lograr los atributos de calidad de un sistema.
Clementes, Paul (2010). Documentar arquitecturas de software: vistas y más (2ª ed.). Profesional de Addison-Wesley . ISBN 9780321552686.- Este libro describe qué es la arquitectura de software y muestra cómo documentarla en múltiples vistas, usando UML y otras notaciones. También explica cómo complementar las vistas de la arquitectura con documentación sobre el comportamiento, la interfaz del software y los fundamentos. Acompañando al libro hay una wiki que contiene un ejemplo de documentación de arquitectura de software.
Campana, 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 Décima Conferencia Internacional de Computación de Objetos Distribuidos Empresariales del IEEE (EDOC'06) . págs. 23–32. doi :10.1109/EDOC.2006.54. ISBN 978-0-7695-2558-7. S2CID 8361936.
Garzás, Javier; Piattini, Mario (2005). "Una ontología para el conocimiento del diseño microarquitectónico". Software IEEE . 22 (2): 28–33. doi :10.1109/MS.2005.26. S2CID 17639072.
Fowler, Martín (septiembre de 2003). "¿Quién necesita un arquitecto?" (PDF) . Software IEEE . 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 de detalle.
Kruchten, Philippe (1995). "Planos arquitectónicos: el modelo de vista '4 + 1' de arquitectura de software" (PDF) . Software IEEE . 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 de conferencias visuales. LeanPub. pag. 689.
Enlaces externos
Wikimedia Commons tiene medios relacionados con la arquitectura de software .
Wikiquote tiene citas relacionadas con la arquitectura de software .
SoftwareArchitectures.com: un recurso independiente de información sobre la disciplina
Arquitectura de software, capítulo 1 de la disertación REST de Roy Fielding
Cuando la buena arquitectura se vuelve mala
El desarrollo impulsado por la arquitectura en espiral: el SDLC basado en el modelo en espiral tiene como objetivo reducir los riesgos de una arquitectura ineficaz
Estudios de casos de la vida real de arquitectura de software