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

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 .

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 .

Por ejemplo, los sistemas que controlaban el vehículo de lanzamiento del transbordador espacial tenían el requisito de ser muy rápidos y muy fiables. Por lo tanto, sería necesario elegir un lenguaje informático en tiempo real apropiado. Además, para satisfacer la necesidad de confiabilidad, se podría elegir tener múltiples copias redundantes y producidas independientemente del programa, y ​​ejecutar estas copias en hardware independiente mientras se verifican los resultados.

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. [4] : 29–35 

Actividades de arquitectura de software.

Alcance

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

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" desde intenciones de alto nivel hasta detalles de bajo nivel. [11] : 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. [4] : 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. [12] Estas descripciones separadas se denominan vistas arquitectónicas (ver, 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 ) fueron impulsados ​​por la funcionalidad requerida y el flujo de datos a través del sistema, pero la idea actual [4] : ​​26–28  es que la arquitectura de un sistema de software está más estrechamente relacionados con sus atributos de calidad , como tolerancia a fallas , compatibilidad con versiones anteriores , extensibilidad , confiabilidad , mantenibilidad , disponibilidad , seguridad, usabilidad y otras características similares . Las preocupaciones de las partes interesadas a menudo se traducen en requisitos sobre estos atributos de calidad, que se denominan 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 arquitectura de software ha desarrollado formas estándar para 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, [11] : 273–277  táctica, [4] : ​​70–72  arquitectura de referencia y patrón arquitectónico . [13] [14] [4] : ​​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 . [15] : 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. [16] 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. [4] : 5–6  Esta abstracción proporciona una serie de beneficios:

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, [19] pero el término "arquitectura de software" no tuvo un uso generalizado hasta la década de 1990. [20] El campo de la informática había encontrado problemas asociados con la complejidad desde su formación. [21] 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 . [22]

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 . [23]

Las instituciones de investigación han desempeñado un papel destacado en el avance de la arquitectura de software como disciplina. Mary Shaw y David Garlan de Carnegie Mellon escribieron un libro titulado Arquitectura de software: perspectivas sobre una disciplina emergente 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 arquitectura de software se dirigen principalmente a estilos arquitectónicos, lenguajes de descripción de arquitectura y arquitecturas dinámicas.

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). [12]

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. [24] Hay cuatro actividades centrales en el diseño de arquitectura de software. [25] 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:

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

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. [25] [4] : ​​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. [29] Los marcos para comparar las técnicas se analizan en marcos como SARA Report [17] y Architecture Reviews: Practice and Experience . [30]

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

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

Puntos de vista de la arquitectura

Modelo de vista arquitectónica 4+1 .

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 planteadas (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 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 se pueden combinar. [34]

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. [35]

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

Algunos tratan los patrones arquitectónicos y los estilos arquitectónicos como lo mismo, [36] 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" [36] o "vocabulario" [34] 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, [37] incluido el método ágil DSDM , que exige una fase de "Fundamentos" durante la cual se colocan los cimientos arquitectónicos "sólo 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 (o "decadencia") de la arquitectura de software se refiere a la brecha observada entre la arquitectura planificada y real de un sistema de software tal como se realiza en su implementación. [38] La erosión de la arquitectura del software ocurre cuando las decisiones de implementación no logran completamente la arquitectura según lo planeado o violan las restricciones o principios de esa arquitectura. [3]

Como ejemplo, consideremos un sistema estrictamente por capas , donde cada capa sólo puede utilizar los servicios proporcionados por la capa inmediatamente inferior. Cualquier componente del código fuente que no respete esta restricción representa una violación de la arquitectura. Si no se corrigen, tales violaciones pueden transformar la arquitectura en un bloque monolítico, con efectos adversos sobre la comprensibilidad, la mantenibilidad y la capacidad de evolución.

Se han propuesto varios enfoques para abordar la erosión. "Estos enfoques, que incluyen herramientas, técnicas y procesos, se clasifican principalmente en tres categorías generales que intentan minimizar, prevenir y reparar la erosión de la arquitectura. Dentro de estas categorías amplias, cada enfoque se desglosa aún más reflejando las estrategias de alto nivel adoptadas para abordar la erosión. Estas son la conformidad de la arquitectura orientada a procesos , la gestión de la evolución de la arquitectura, la aplicación del diseño de la arquitectura, la vinculación de la arquitectura a la implementación, la autoadaptación y las técnicas de restauración de la arquitectura que consisten en recuperación, descubrimiento y reconciliación". [39]

Existen dos técnicas principales para detectar violaciones arquitectónicas: modelos de reflexión y lenguajes de dominio específico. Las técnicas del modelo de reflexión (RM) comparan un modelo de alto nivel proporcionado por los arquitectos del sistema con la implementación del código fuente. También hay lenguajes de dominio específicos que se centran en especificar y verificar restricciones arquitectónicas.

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. [40] 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 , [41] la distinción entre diseño arquitectónico y detallado está definida por el Criterio de Localidad , [41] 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 .

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 aborda el " espacio del problema " o el "qué". [42] 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.) 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" . [25] En resumen, el comportamiento requerido afecta la arquitectura de la solución, lo que a su vez puede introducir nuevos requisitos. [43] Enfoques como el modelo Twin Peaks [44] tienen como objetivo explotar la relación sinérgica entre requisitos y arquitectura.

Otros tipos de 'arquitectura'

Arquitectura de Computadores
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. [45] [ se necesita una mejor fuente ]
Arquitectura de sistemas
El término arquitectura de sistemas se aplicó originalmente a la arquitectura de sistemas que consta 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.

Ver también

Referencias

  1. ^ 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.
  2. ^ "Arquitectura de software". www.sei.cmu.edu . Consultado el 23 de julio de 2018 .
  3. ^ abcd Perry, DE; Lobo, AL (1992). «Fundamentos para el estudio de la arquitectura del software» (PDF) . Notas de ingeniería de software de ACM SIGSOFT . 17 (4): 40. CiteSeerX 10.1.1.40.5174 . doi :10.1145/141874.141884. S2CID  628695. 
  4. ^ abcdefghij Bajo, Len; Pablo Clementes; Rick Kazman (2012). Arquitectura de software en la práctica, tercera edición . Boston: Addison-Wesley. ISBN 978-0-321-81573-6.
  5. ^ SEI (2006). "¿Cómo se define la arquitectura de software?" . Consultado el 12 de septiembre de 2012 .
  6. ^ Garlan y Shaw (1994). "Introducción a la arquitectura de software" (PDF) . Consultado el 13 de septiembre de 2012 .
  7. ^ 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.
  8. ^ ISO/IEC/IEEE 42010: Definición de "arquitectura". Iso-arquitectura.org. Recuperado el 21 de julio de 2013.
  9. ^ 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. ISBN  978-0-7695-2548-8. S2CID  13492610.
  10. ^ 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.
  11. ^ a b C George Fairbanks (2010). Arquitectura de software suficiente . Marshall y Brainerd.
  12. ^ 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 .
  13. ^ 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 .
  14. ^ 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. ISBN 978-1-4244-4984-2. Consultado el 15 de diciembre de 2023 .
  15. ^ Brooks, Frederick P. Jr. (1975). El mes del hombre mítico: ensayos sobre ingeniería de software . Addison-Wesley. ISBN 978-0-201-00650-6.
  16. ^ 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 .
  17. ^ 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 .
  18. ^ 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.
  19. ^ 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 .
  20. ^ 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.
  21. ^ Universidad de Waterloo (2006). "Una muy breve historia de la informática" . Consultado el 23 de septiembre de 2006 .
  22. ^ "Introducción al número especial sobre arquitectura de software". IEEE.org . 2006. doi :10.1109/TSE.1995.10003.
  23. ^ Garlan y Shaw (1994). "Introducción a la arquitectura de software" (PDF) . Consultado el 25 de septiembre de 2006 .
  24. ^ 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.
  25. ^ 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.
  26. ^ 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 .
  27. ^ 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. ISBN  9780750661409. S2CID  14177438. Archivado desde el original (PDF) el 17 de noviembre de 2018.
  28. ^ 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.
  29. ^ 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.
  30. ^ 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.
  31. ^ 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. ISBN 978-3-642-02373-6.
  32. ^ 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.
  33. ^ 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.
  34. ^ ab Shaw, María; Garlan, David (1996). Arquitectura de software: perspectivas sobre una disciplina emergente . Prentice Hall. ISBN 978-0-13-182957-2.
  35. ^ 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.
  36. ^ ab Capítulo 3: Patrones y estilos arquitectónicos. msdn.microsoft.com. Recuperado el 21 de julio de 2013.
  37. ^ Boehm, Barry; Turner, Richard (2004). Equilibrando agilidad y disciplina . Addison-Wesley. ISBN 978-0-321-18612-6.
  38. ^ Terra, R., MT Valente, K. Czarnecki y RS Bigonha, "Recomendar refactorizaciones para revertir la erosión de la arquitectura de software", 16ª Conferencia europea sobre mantenimiento y reingeniería de software, 2012. http://gsd.uwaterloo.ca/sites/ predeterminado/archivos/Full%20Text.pdf
  39. ^ de Silva, L.; Balasubramaniam, D. (2012). "Control de la erosión de la arquitectura de software: una encuesta". Revista de Sistemas y Software . 85 (1): 132-151. doi :10.1016/j.jss.2011.07.036.
  40. ^ 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
  41. ^ 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.
  42. ^ 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. ISBN 978-0-8186-5480-0. S2CID  3129363.
  43. ^ 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. 
  44. ^ 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.
  45. ^ 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 .

Otras lecturas

enlaces externos

Wikimedia Commons tiene medios relacionados con la arquitectura de software .
Wikiquote tiene citas relacionadas con la arquitectura de software .