stringtranslate.com

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]

Actividades de arquitectura de software

Alcance

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

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 ).

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 .

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:

Historia

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 .

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]

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]

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:

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.

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).

Puntos de vista de la arquitectura

Modelo de vista arquitectónica 4+1 .

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 .

Ingeniería de requisitos

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.

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.

Véase también

Referencias

  1. ^ 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.
  2. ^ "Arquitectura de software". www.sei.cmu.edu . Consultado el 23 de julio de 2018 .
  3. ^ abcd Perry, DE; Wolf, AL (1992). "Fundamentos para el estudio de la arquitectura de software" (PDF) . ACM SIGSOFT Notas de ingeniería de software . 17 (4): 40. CiteSeerX 10.1.1.40.5174 . doi :10.1145/141874.141884. S2CID  628695. 
  4. ^ Arquitectura de software Head First . O'Reilly Media. 2024. ISBN 978-1098134358.
  5. ^ abcd Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  6. ^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 9781492043423.
  7. ^ abcdefghij Bass, Len; Paul Clements; Rick Kazman (2012). Arquitectura de software en la práctica, tercera edición . Boston: Addison-Wesley. ISBN 978-0-321-81573-6.
  8. ^ SEI (2006). "¿Cómo se define la arquitectura de software?" . Consultado el 12 de septiembre de 2012 .
  9. ^ Garlan & Shaw (1994). "Introducción a la arquitectura de software" (PDF) . Consultado el 13 de septiembre de 2012 .
  10. ^ 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.
  11. ^ ISO/IEC/IEEE 42010: Definición de "arquitectura". Iso-architecture.org. Consultado el 21 de julio de 2013.
  12. ^ 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. ISBN  978-0-7695-2548-8. Número de identificación del sujeto  13492610.
  13. ^ 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. ISBN 978-3-642-02373-6.
  14. ^ abc George Fairbanks (2010). Arquitectura de software suficiente . Marshall & Brainerd.
  15. ^ 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 .
  16. ^ 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 .
  17. ^ 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 .
  18. ^ Brooks, Frederick P. Jr. (1975). El mítico mes del hombre: ensayos sobre ingeniería de software . Addison-Wesley. ISBN 978-0-201-00650-6.
  19. ^ 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 .
  20. ^ 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 .
  21. ^ 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.
  22. ^ 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 .
  23. ^ 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.
  24. ^ Universidad de Waterloo (2006). "Una breve historia de la informática" . Consultado el 23 de septiembre de 2006 .
  25. ^ "Introducción al número especial sobre arquitectura de software". IEEE.org . 2006. doi :10.1109/TSE.1995.10003.
  26. ^ Garlan & Shaw (1994). "Introducción a la arquitectura de software" (PDF) . Consultado el 25 de septiembre de 2006 .
  27. ^ 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.
  28. ^ 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.
  29. ^ 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 .
  30. ^ 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.
  31. ^ 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.
  32. ^ 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.
  33. ^ 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.
  34. ^ 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. ISBN 978-3-642-02373-6.
  35. ^ 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.
  36. ^ 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.
  37. ^ ab Shaw, Mary; Garlan, David (1996). Arquitectura de software: perspectivas sobre una disciplina emergente . Prentice Hall. ISBN 978-0-13-182957-2.
  38. ^ UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles. Isr.uci.edu. Recuperado el 21 de julio de 2013.
  39. ^ ab Capítulo 3: Patrones y estilos arquitectónicos. Msdn.microsoft.com. Recuperado el 21 de julio de 2013.
  40. ^ Boehm, Barry; Turner, Richard (2004). Equilibrar la agilidad y la disciplina . Addison-Wesley. ISBN 978-0-321-18612-6.
  41. ^ 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.
  42. ^ 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.
  43. ^ van Gurp, J. y Bosch, J.: 2002, Erosión del diseño: problemas y causas, Journal of Systems and Software 61(2), 105–119.
  44. ^ 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
  45. ^ 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.
  46. ^ 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. ISBN 978-0-8186-5480-0. Número de identificación del sujeto  3129363.
  47. ^ 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. 
  48. ^ 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.
  49. ^ 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

Enlaces externos