Arquitectura de software
La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la
versión revisada el 13 de mayo de 2019; las comprobaciones requieren
8 ediciones .
La arquitectura de software es un conjunto de las decisiones más importantes sobre la organización de un sistema de software. La arquitectura incluye:
- la elección de los elementos estructurales y sus interfaces, con la ayuda de los cuales se compone el sistema, así como su comportamiento en el marco de la cooperación de los elementos estructurales;
- conectar elementos seleccionados de estructura y comportamiento en sistemas cada vez más grandes;
- un estilo arquitectónico que guía a toda la organización: todos los elementos, sus interfaces, su colaboración y su conexión [1] [2] .
Documentar la arquitectura de software (SW) simplifica el proceso de comunicación entre desarrolladores, permite registrar las decisiones de diseño tomadas y brindar información sobre las mismas al personal operativo del sistema [3] , reutilizar componentes y plantillas de proyectos
en otros.
No existe una definición generalmente aceptada de "arquitectura de software". Así, el sitio del Instituto de Ingeniería de Software da más de 150 definiciones de este concepto [4] [5] .
Resumen
El campo de la informática, desde sus inicios, ha enfrentado desafíos relacionados con la complejidad de los sistemas de software. Anteriormente, los desarrolladores resolvían los problemas de complejidad eligiendo las estructuras de datos correctas, desarrollando algoritmos y aplicando el concepto de separación de poderes. Aunque el término "arquitectura de software" es relativamente nuevo en la industria del desarrollo de software, los principios fundamentales del campo han sido aplicados indiscriminadamente por los pioneros del desarrollo de software desde mediados de la década de 1980. Los primeros intentos de comprender y explicar la arquitectura de software de un sistema estaban llenos de imprecisiones y carecían de organización, a menudo solo un diagrama de bloques conectados por líneas. En la década de 1990 se intentó definir y sistematizar los principales aspectos de esta disciplina. Durante este tiempo se desarrolló un conjunto inicial de patrones de diseño, estilos de diseño, mejores prácticas, lenguajes de descripción y lógica formal [6] .
Una idea fundamental de la disciplina de la arquitectura de software es la idea de reducir la complejidad del sistema a través de la abstracción y separación de poderes. Hasta la fecha, todavía no hay acuerdo sobre una definición clara del término "arquitectura de software".
Como disciplina en evolución actual sin reglas claras sobre la forma "correcta" de construir un sistema, el diseño de arquitectura de software sigue siendo una mezcla de ciencia y arte. El aspecto "arte" es que cualquier sistema comercial implica una aplicación o una misión. Desde la perspectiva de un usuario de la arquitectura de software, la arquitectura de software proporciona una dirección para avanzar y resolver problemas relacionados con la especialidad de cada usuario, por ejemplo, una parte interesada, un desarrollador de software, un equipo de soporte de software, un mantenedor de software, un especialista en implementación de software, un probador, y también los usuarios finales. En este sentido, la arquitectura de software en realidad reúne diferentes perspectivas sobre un sistema. El hecho de que estos diferentes puntos de vista puedan combinarse en una arquitectura de software es un argumento a favor de la necesidad y conveniencia de crear una arquitectura de software incluso antes de la etapa de desarrollo del software [7] [8] [9] .
Historia
La arquitectura de software como concepto comenzó con el trabajo de investigación de Edsger Dijkstra en 1968 y David Parnassus a principios de la década de 1970. Estos académicos enfatizaron que la estructura de un sistema de software es importante y que construir la estructura correcta es fundamental. El estudio de este campo ha crecido en popularidad desde principios de la década de 1990 con trabajos de investigación sobre estilos arquitectónicos (patrones), lenguajes de descripción de arquitectura, documentación de arquitectura y métodos formales.
Las instituciones de investigación juegan un papel importante en el desarrollo de la arquitectura de software como disciplina. Mary Shaw y David Garlan de la Universidad Carnegie Mellon escribieron un libro titulado "Arquitectura de software: perspectivas sobre una nueva disciplina en 1996" en el que presentan conceptos de arquitectura de software como componentes, conectores, estilos, etc. En la Universidad de California, el Irvine Institute for Software Research investiga principalmente estilos arquitectónicos, lenguajes de descripción de arquitectura y arquitecturas dinámicas.
El primer estándar de arquitectura de software es IEEE 1471: ANSI/IEEE 1471-2000: Pautas para describir sistemas predominantemente de software. Fue adoptado en 2007 bajo el nombre ISO ISO/IEC 42010:2007.
Lenguajes de descripción de la arquitectura
Los lenguajes de descripción de arquitectura (ADLS) se utilizan para describir la arquitectura del software. Varias organizaciones han desarrollado varios ADLS diferentes, incluido AADL (estándar SAE), Wright (desarrollado en la Universidad Carnegie Mellon), Acme (desarrollado en la Universidad Carnegie Mellon), xADL (desarrollado en UCI), Darwin (desarrollado en Imperial College London) , DAOP-ADL (desarrollado en la Universidad de Málaga), y ByADL (Universidad de L'Aquila, Italia). Elementos comunes a todos estos lenguajes son los conceptos de componente, conector y configuración. Además, además de los lenguajes especializados, el lenguaje de modelado unificado UML se usa a menudo para describir la arquitectura .
Vistas
Una arquitectura de software generalmente contiene varias vistas que son similares a los diferentes tipos de dibujos en la construcción de edificios. En una ontología definida por ANSI/IEEE 1471-2000, las vistas son instancias de puntos de vista, donde existe un punto de vista para describir una arquitectura desde el punto de vista de un conjunto determinado de partes interesadas.
La vista arquitectónica consta de 2 componentes:
- Elementos
- Relaciones entre elementos
Las vistas arquitectónicas se pueden dividir en 3 tipos principales [10] :
- Vistas modulares (vistas de módulos ing. ): muestran el sistema como una estructura de varios bloques de software.
- Componentes y conectores (esp. vistas de componentes y conectores ): muestra el sistema como una estructura de elementos que se ejecutan en paralelo (componentes) y cómo interactúan (conectores).
- Asignación (ing. vistas de asignación ): muestra la ubicación de los elementos del sistema en entornos externos.
Ejemplos de vistas modulares:
- Descomposición (ing. vista de descomposición ): consta de módulos en el contexto de la relación "es un submódulo"
- Uso (ing. vista de usos ): consta de módulos en el contexto de la relación "usos" (es decir, un módulo usa los servicios de otro módulo)
- Vista de nivel (ing. vista en capas ): muestra una estructura en la que los módulos relacionados por funcionalidad se combinan en grupos (niveles)
- Vista de clase/generalización (eng. c lass/vista de generalización ): consta de clases relacionadas a través de la relación "heredada de" y "es una instancia"
Ejemplos de tipos de componentes y conectores:
- Vista de proceso (eng. vista de proceso ): consiste en procesos conectados por operaciones de comunicación, sincronización y/o exclusión
- Vista paralela (ing. vista de concurrencia ): consta de componentes y conectores, donde los conectores son "flujos lógicos"
- Tipo de intercambio de datos (ing. vista de datos compartidos (repositorio) ): consta de componentes y conectores que crean, guardan y reciben datos persistentes
- Vista cliente-servidor (eng. vista cliente-servidor ): consiste en clientes y servidores que interactúan, así como conectores entre ellos (por ejemplo, protocolos y mensajes comunes)
Ejemplos de tipos de alojamiento:
- Implementación (ing. vista de implementación ): consta de elementos de software, su ubicación en medios físicos y elementos de comunicación
- Implementación (ing. vista de implementación ): consta de elementos del programa y su correspondencia con las estructuras de archivos en varios entornos (desarrollo, integración, etc.)
- Asignación de trabajo (ing. vista de asignación de trabajo ): consta de módulos y una descripción de quién es responsable de implementar cada uno de ellos
Aunque se han desarrollado varios lenguajes para describir la arquitectura de software, actualmente no hay acuerdo sobre qué conjunto de vistas se debe adoptar como referencia. El lenguaje UML se creó como un estándar "para modelar sistemas de software (y no solo)".
Patrones arquitectónicos
Se aplican varios patrones arquitectónicos para satisfacer el sistema diseñado con diferentes atributos de calidad. Cada plantilla tiene sus propios objetivos y desventajas.
Ejemplos de patrones arquitectónicos:
- Patrón en capas. El sistema está dividido en niveles, que se muestran uno encima del otro en el diagrama. Cada nivel solo puede convocar al nivel 1 debajo de él. Así, el desarrollo de cada nivel se puede realizar de forma relativamente independiente, lo que aumenta la modificabilidad del sistema. Las desventajas de este enfoque son la complicación del sistema y la disminución del rendimiento.
- Patrón de corredor. Cuando hay una gran cantidad de módulos en el sistema, su interacción directa entre sí se vuelve demasiado complicada. Para solucionar el problema, se introduce un intermediario (por ejemplo, un bus de datos), a través del cual los módulos se comunican entre sí. De este modo, se incrementa la interoperabilidad de los módulos del sistema. Todas las desventajas provienen de la presencia de un intermediario: reduce el rendimiento, su indisponibilidad puede hacer que todo el sistema sea inaccesible, puede convertirse en objeto de ataque y en un cuello de botella del sistema.
- Patrón "Modelo-Vista-Controlador" (Patrón Modelo-Vista-Controlador). Porque Dado que los requisitos para la interfaz cambian con mayor frecuencia, es necesario modificarla con frecuencia, manteniendo la interacción correcta con los datos (leer, guardar). Para ello, en el patrón Modelo-Vista-Controlador (MVC), la interfaz se separa de los datos. Esto le permite cambiar las interfaces, así como crear diferentes versiones de las mismas. En MVC, el sistema se divide en:
- El modelo que almacena los datos.
- Una vista que muestra un dato e interactúa con el usuario
- Un controlador que media entre las vistas y el modelo.
Sin embargo, el concepto MVC también tiene sus inconvenientes. En particular, debido a la complicación de la interacción, la velocidad del sistema disminuye.
- Patrón cliente-servidor (Patrón Cliente-Servidor). Si existe un número limitado de recursos que requieren acceso restringido por parte de un gran número de consumidores, entonces es conveniente implementar una arquitectura cliente-servidor. Este enfoque aumenta la escalabilidad y la disponibilidad del sistema. Pero al mismo tiempo, el servidor puede convertirse en un cuello de botella en el sistema; si no está disponible, todo el sistema deja de estar disponible.
Frameworks básicos para la arquitectura de software
Existen los siguientes marcos (frameworks de arquitectura de software en inglés ) relacionados con el campo de la arquitectura de software:
- 4+1
- RM-ODP (Modelo de Referencia de Procesamiento Distribuido Abierto)
- Marco de modelado orientado a servicios (SOMF)
Los ejemplos de arquitectura como Zachman Framework, DoDAF y TOGAF caen bajo el dominio de las arquitecturas empresariales.
Véase también
Notas
- ↑ Kruchten, Philippe . El proceso unificado racional: una introducción, Addison-Wesley, 1998
- ↑ Rumbaugh, J. , Jacobsen, I. y Booch, G. Manual de referencia del lenguaje de modelado unificado. Lectura, Massachusetts: Addison-Wesley, 1999
- ↑ Documentación de arquitecturas de software: vistas y más allá, 2010 , P.1.1. Visión general.
- ↑ Documentación de arquitecturas de software: vistas y más allá, 2010 , P.1.2. Atributos de Arquitectura y Calidad.
- ↑ Arquitectura de software: glosario Archivado el 5 de enero de 2013 en Wayback Machine , Software Engineering Institute
- ↑ ¿Cuál es su definición de arquitectura de software ? recursos.sei.cmu.edu. Consultado el 23 de octubre de 2019. Archivado desde el original el 28 de febrero de 2020.
- ↑ ISO/IEC/IEEE 42010: Definición de "arquitectura" . www.iso-arquitectura.org. Consultado el 23 de octubre de 2019. Archivado desde el original el 7 de abril de 2017. (indefinido)
- ↑ M. Fowler. Diseño - ¿Quién necesita un arquitecto? // Software IEEE. — 2003-9. - T. 20 , n. 5 . — P. 11–13 . -doi : 10.1109/ MS.2003.1231144 . Archivado desde el original el 23 de octubre de 2019.
- ↑ Una introducción a la arquitectura de software . Consultado el 23 de octubre de 2019. Archivado desde el original el 6 de mayo de 2021. (indefinido)
- ↑ Len Bass, Paul Clements, Rick Kazman. Arquitectura de software en la práctica (3.ª edición) (Serie SEI en ingeniería de software). - 3ª edición (5 de octubre de 2012). - 2012. - 640 págs. — ISBN 978-0321815736 .
Literatura
- Pablo Clemente; Félix Bachmann; bajo de Len; David Garlán; James Ivers; poco de caña; Pablo Merson; Roberto Norte; Judith Stafford. Documentación de arquitecturas de software: vistas y más allá. - Segunda edicion. - Addison-Wesley Professional, 2010. - ISBN 978-0-13-248861-7 .
- Len Bass, Paul Clements, Rick Kazman: Arquitectura de software en la práctica, tercera edición . Addison Wesley, 2012, ISBN 978-0321815736 (Este libro, ahora en su tercera edición, cubre con elocuencia los conceptos fundamentales de la disciplina. El tema se centra en lograr los atributos de calidad de un sistema).
Enlaces