La descripción de la arquitectura de software es el conjunto de prácticas para expresar, comunicar y analizar arquitecturas de software (también llamada representación arquitectónica), y el resultado de la aplicación de dichas prácticas a través de un producto de trabajo que expresa una arquitectura de software ( ISO/IEC/IEEE 42010 ).
Las descripciones de arquitectura (AD) también se denominan a veces representaciones de arquitectura , especificaciones de arquitectura [1] o documentación de arquitectura de software .
La descripción de la arquitectura define las prácticas, técnicas y tipos de representaciones que utilizan los arquitectos de software para registrar una arquitectura de software. La descripción de la arquitectura es en gran medida una actividad de modelado ( modelo arquitectónico de software ). Los modelos de arquitectura pueden adoptar diversas formas, incluidos texto, dibujos informales, diagramas u otros formalismos ( lenguaje de modelado ). Una descripción de la arquitectura empleará a menudo varios tipos de modelos diferentes para abordar de forma eficaz una variedad de audiencias, las partes interesadas (como usuarios finales, propietarios de sistemas, desarrolladores de software, ingenieros de sistemas, administradores de programas) y una variedad de preocupaciones arquitectónicas (como funcionalidad, seguridad, entrega, confiabilidad, escalabilidad).
A menudo, los modelos de una descripción de arquitectura se organizan en múltiples vistas de la arquitectura de modo que "cada [vista] aborde preocupaciones específicas de interés para diferentes partes interesadas del sistema". [2] Un punto de vista de arquitectura es una forma de ver un sistema ( RM ODP ). Cada vista en una descripción de arquitectura debe tener un punto de vista que documente las preocupaciones y las partes interesadas a las que está dirigido, y los tipos de modelos, notaciones y convenciones de modelado que utiliza ( ISO/IEC/IEEE 42010 ).
El uso de múltiples vistas, si bien es eficaz para comunicarse con diversas partes interesadas y registrar y analizar diversas preocupaciones, plantea posibles problemas: dado que las vistas normalmente no son independientes, la posibilidad de superposición significa que puede haber redundancia o inconsistencia entre las vistas de un solo sistema. [3] Se pueden utilizar varios mecanismos para definir y gestionar correspondencias entre vistas para compartir detalles, reducir la redundancia y hacer cumplir la coherencia.
Un malentendido común sobre las descripciones de arquitectura es que las AD solo abordan "cuestiones técnicas", pero las AD deben abordar cuestiones relevantes para muchas partes interesadas. Algunas cuestiones son técnicas; muchas otras no lo son: las AD se utilizan para ayudar a los arquitectos, sus clientes y otros a gestionar los costes, los plazos y los procesos. Un malentendido relacionado es que las AD solo abordan los aspectos estructurales de un sistema. Sin embargo, esto rara vez satisface a las partes interesadas, cuyas preocupaciones suelen incluir cuestiones estructurales, de comportamiento, estéticas y otras "extrafuncionales".
Las primeras descripciones de arquitectura utilizaban imágenes y diagramas informales y texto asociado. Las descripciones informales siguen siendo las representaciones más utilizadas en la industria. [4] Las influencias en la descripción de la arquitectura vinieron de las áreas de ingeniería de software (como la abstracción de datos y la programación en general) y del diseño de sistemas (como SARA [5] ).
El trabajo sobre programación a gran escala, como los lenguajes de interconexión de módulos (MIL), se centró en la expresión de las propiedades a gran escala del software: [6] módulos (incluidos programas, bibliotecas, subrutinas y subsistemas) y relaciones entre módulos (dependencias e interconexiones entre módulos). Este trabajo influyó tanto en el pensamiento arquitectónico sobre los lenguajes de programación (por ejemplo, Ada) como en las notaciones de diseño y arquitectura (como los diagramas de Buhr y los mapas de casos de uso y las características arquitectónicas codificadas de UML: paquetes, subsistemas, dependencias) y gran parte del trabajo sobre lenguajes de descripción de arquitectura. Además de los MIL, bajo la influencia del trabajo maduro en las áreas de Requisitos y Diseño dentro de la Ingeniería de Software, se "tomaron" varios tipos de modelos de la ingeniería y el diseño de software para aplicarlos a la descripción de arquitecturas. Estos incluían modelos de funciones y actividades del Análisis Estructurado SADT , técnicas de modelado de datos (entidad-relación) y técnicas orientadas a objetos.
Perry y Wolf [1] citaron el precedente de la arquitectura de edificios sobre el papel de las vistas múltiples: "Un arquitecto de edificios trabaja con el cliente por medio de una serie de vistas diferentes en las que se enfatiza algún aspecto particular del edificio".
Perry y Wolf postularon que la representación de las arquitecturas debería incluir: {elementos, forma y lógica} , distinguiendo tres tipos de elementos (y por tanto tres tipos de vistas):
Perry y Wolf identificaron cuatro objetivos o usos para las descripciones de arquitectura (llamadas "especificaciones de arquitectura" en su artículo):
Tras el artículo de Perry y Wolf, surgieron dos escuelas de pensamiento sobre la descripción de la arquitectura de software [ cita requerida ] :
Existen varios mecanismos comunes que se utilizan para la descripción de la arquitectura. Estos mecanismos facilitan la reutilización de estilos de descripción exitosos para que puedan aplicarse a muchos sistemas:
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, las técnicas de modelado que se utilizarán en una vista para expresar la arquitectura en cuestión desde la perspectiva de un conjunto dado de partes interesadas y sus preocupaciones ( ISO/IEC 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.
Algunos ejemplos de puntos de vista incluyen:
El término tipo de vista se utiliza para referirse a categorías de vistas similares que comparten un conjunto común de elementos y relaciones. [4]
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) y ByADL (Universidad de L'Aquila, Italia). Los primeros ADL enfatizaban los sistemas de modelado en términos de sus componentes, conectores y configuraciones. Los ADL más recientes (como ArchiMate y SysML) han tendido a ser lenguajes de "amplio espectro" capaces de expresar no solo componentes y conectores sino una variedad de preocupaciones a través de múltiples sublenguajes. Además de los lenguajes de propósito especial, los lenguajes existentes como UML se pueden utilizar como ADL "para el análisis, diseño e implementación de sistemas basados en software, así como para modelar procesos de negocios y similares".
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. Los marcos de interés en la arquitectura de software incluyen:
Representado en el muy influyente artículo de Kruchten de 1995 sobre el "modelo de vista 4+1" , este enfoque enfatizó las diferentes partes interesadas y preocupaciones que se deben modelar. [2]
En segundo lugar, reflejado en el trabajo de CMU y en otros lugares, la noción de que la arquitectura era la organización de alto nivel de un sistema en tiempo de ejecución y que la arquitectura debería describirse en términos de sus componentes y conectores: "la arquitectura de un sistema de software define ese sistema en términos de componentes computacionales e interacciones entre esos componentes". [7]
Durante los años 1990 y 2000, gran parte del trabajo académico sobre las ADL se llevó a cabo dentro del paradigma de los componentes y conectores. Sin embargo, estas ADL han tenido muy poco impacto en la industria. [8] Desde los años 1990, ha habido una convergencia en los enfoques hacia la descripción de la arquitectura, con IEEE 1471 en 2000 codificando las mejores prácticas: respaldando, pero no exigiendo, múltiples puntos de vista en una AD.
Desarrollando el aspecto racional de la fórmula original de Perry y Wolf, ha surgido una tercera escuela de pensamiento, que documenta las decisiones y las razones de las decisiones como una forma esencial de concebir y expresar una arquitectura de software. [9] Este enfoque trata las decisiones como elementos de primera clase de la descripción de la arquitectura, haciendo explícito lo que a menudo estaba implícito en representaciones anteriores.
Las descripciones de arquitectura sirven para diversos propósitos, entre ellos ( ISO/IEC/IEEE 42010 ):