Concepto: Arquitectura de software
La arquitectura de software representa la estructura o las estructuras del sistema, que consta de componentes de software, las propiedades visibles externamente y las relaciones entre ellas.
Relaciones
Descripción principal

Introducción

La arquitectura de software es un concepto fácil de entender y que la mayoría de los ingenieros aprecian intuitivamente, sobre todo los que tienen un poco de experiencia, pero resulta difícil definirlo con precisión. En concreto, es difícil dibujar una línea precisa entre el diseño y la arquitectura, la arquitectura es un aspecto de diseño que se concentra en algunas características específicas.

En An Introduction to Software Architecture, David Garlan y Mary Shaw sugieren que la arquitectura es un nivel de diseño que se centra en aspectos: "Beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives." (Más allá de los algoritmos y estructuras de datos de la computación; el diseño y la especificación de la estructura general del sistema emergen como una clase nueva de problema. Los aspectos estructurales incluyen la estructura global de control y la organización general; protocolos de comunicación, sincronización y acceso de datos; asignación de funciones para diseñar elementos; distribución física, composición de elementos de diseño; ajuste y rendimiento; y selección entre otras alternativas de diseño). [GAR93]

Pero la arquitectura es algo más que una estructura; el IEEE Working Group on Architecture la define como "the highest-level concept of a system in its environment" (el concepto de más alto nivel de un sistema en su entorno) [IEP1471]. También incluye el "ajuste" con la integridad del sistema, con las restricciones económicas, con las preocupaciones estéticas y con el estilo. No se limita a un enfoque interior, si no que tiene en cuenta el sistema en su totalidad dentro del entorno de usuario y el entorno de desarrollo, un enfoque exterior.

En RUP, la arquitectura de un sistema de software (en un punto determinado) es la organización o la estructura de los componentes importantes del sistema que interactúan mediante interfaces, con componentes compuestos de interfaces y componentes cada vez más pequeños.

Descripción de la arquitectura

Para poder hablar y razonar sobre la arquitectura de software, antes debe definir una representación arquitectónica, una manera de describir aspectos importantes de una arquitectura. En RUP, esta descripción se captura en el Documento de arquitectura de software.

Vistas de la arquitectura

Hemos decidido representar la arquitectura de software en varias vistas de la arquitectura. Cada vista de la arquitectura trata un conjunto concreto de problemas, específico de interesados en el proceso de desarrollo: usuarios, diseñadores, gestores, ingenieros de sistemas, mantenedores, etc.

Las vistas capturan las principales decisiones de diseño estructural y muestran cómo se descompone la estructura de software en componentes y cómo se conectan los componentes mediante conectores para producir formas útiles [PW92]. Estas elecciones de diseño deben estar unidas a los Requisitos, funcionales y suplementarios y otras restricciones. Aunque, a su vez, añaden más restricciones a los requisitos y a las próximas decisiones de diseño en un nivel inferior.

Un conjunto típico de vistas de la arquitectura

La arquitectura se representa mediante un número diferente de vistas de la arquitectura, que, esencialmente, son extractos que ilustran los elementos "significativos arquitectónicamente" de los modelos. En RUP, se empieza en un conjunto típico de vistas, llamado el "modelo de vista 4+1" [KRU95]. Consta de:

Las vistas de la arquitectura se muestran en el Documento de arquitectura de software. Puede visualizar vistas adicionales para expresar diferentes preocupaciones especiales: vista de interfaz de usuario, vista de seguridad, vista de datos, etc. En sistemas simples, puede omitir algunas de las vistas contenidas en el modelo de vista 4+1.

Atención en la arquitectura

Aunque las vistas de arriba pueden representar el diseño completo de un sistema, la arquitectura trata únicamente algunos aspectos específicos:

  • La estructura del modelo: los patrones organizativos, por ejemplo, la Creación de capas.
  • Los elementos esenciales: guiones de uso críticos, clases principales, mecanismos comunes, etc., en oposición a todos los elementos presentes en el modelo.
  • Unos cuantos casos de ejemplo clave que muestran los flujos de control principales en el sistema.
  • Los servicios, para capturar aspectos de la línea de productos, modularidad y características opcionales.

Las vistas de la arquitectura son, esencialmente, abstracciones o simplificaciones de todo el diseño, en las que las características importantes pasan a ser más visibles y se dejan de lado los detalles. Estas características son importantes cuando se razona sobre:

  • La evolución del sistema, el paso al siguiente ciclo de desarrollo.
  • La reutilización de la arquitectura, o partes de ella, en el contexto de una línea de productos.
  • La evaluación de calidades suplementarias, como rendimiento, disponibilidad, portabilidad y seguridad.
  • La asignación de trabajo de desarrollo a equipos y subcontratistas.
  • Las decisiones sobre la inclusión de componentes asequibles.
  • La inserción en un sistema más amplio.

Patrones de arquitectura

Los patrones de arquitectura son formatos preparados que resuelven problemas arquitectónicos recurrentes. Una infraestructura de la arquitectura (middleware) es un conjunto de componentes sobre los que puede construir una cierta clase de arquitectura. Muchas de las principales dificultades arquitectónicas deberían resolverse en la infraestructura, normalmente destinada a un dominio específico: mandato y control, MIS, sistema de control, etc.

Ejemplos de patrones de arquitectura

[BUS96] agrupa patrones de arquitectura en función de las características de los sistemas en los que son más aplicables; una de las categorías trata temas de estructura más generales. La tabla muestra las categorías que se presentan en [BUS96] y los patrones que contienen.

Categoría Patrón
Estructura Capas
Conductos y filtros
Pizarra
Sistemas distribuidos Intermediario
Sistemas interactivos Modelo-Vista-Controlador
Presentación-Abstracción-Control
Sistemas adaptables Reflejo
Microkernel

Dos de ellas se presentan aquí más detalladamente, para clarificar estas ideas; si desea obtener un tratamiento completo, consulte [BUS96]. Los patrones se presentan con el siguiente formato, muy utilizado:

  • Nombre del patrón
  • Contexto
  • Problema
    • Fuerza la descripción de diferentes aspectos del problema que se deberían tener en cuenta
  • Solución
    • Fundamentos
    • Contexto resultante
    • Ejemplos
Nombre del patrón

Capas

Contexto

Un sistema grande que requiere descomposición.

Problema

Un sistema que debe manejar asuntos en diferentes niveles de abstracción.  Por ejemplo: asuntos de control de hardware, asuntos de servicios comunes y asuntos específicos del dominio. No sería nada deseable escribir componentes verticales que manejen asuntos en todos los niveles. Habría que manejar el mismo asunto (posiblemente de manera incoherente) varias veces en componentes distintos.

Fuerzas

  • Las partes del sistema deberían ser sustituibles.
  • Los cambios de los componentes no deberían extenderse.
  • Las responsabilidades similares deberían agruparse juntas.
  • El tamaño de los componentes: puede que sea necesario descomponer los componentes complejos.
Solución

Estructure los sistemas en grupos de componentes que formen capas unos encima de otros. Haga que las capas superiores utilicen únicamente los servicios de las capas de abajo (nunca los de las capas de arriba). Intente utilizar únicamente los servicios de la capa inmediatamente inferior (no se salte capas, a no ser que las capas intermedias sólo sean de paso por los componentes).

Ejemplos:

1. Capas genéricas

Diagrama descrito en el contenido.

Una arquitectura de capas estricta indica que los elementos de diseño (clases, paquetes, subsistemas) sólo utilizan los servicios de la capa inmediatamente inferior.  Los servicios pueden incluir manejo de sucesos, manejo de errores, acceso a bases de datos, etc. Contiene mecanismos más palpables, en oposición a las llamadas de nivel de sistema operativo bruto documentadas en la capa inferior.

2. Capas del sistema empresarial

Diagrama descrito en el contenido.

El diagrama anterior muestra otro ejemplo de creación de capas, donde hay capas específicas de la aplicación vertical, capas horizontales y capas de infraestructura. Tenga en cuenta que el objetivo es tener "tubos de estufa" empresariales muy cortos y promover la similitud entre las aplicaciones.  Sino, puede tener a varias personas resolviendo el mismo problema, potencialmente diferente.

Consulte el apartado Directriz: Creación de capas para obtener más información sobre este patrón.

Nombre del patrón

Pizarra

Contexto

Un dominio en el que no hay ningún enfoque cerrado (algorítmico) conocido o viable para resolver un problema. Por ejemplo, sistemas de vigilancia, reconocimiento de voz y sistemas AI.

Problema

Para solucionar un problema que no puede solucionar ninguno de los agentes individuales, deben cooperar varios agentes de resolución de problemas (agentes de conocimiento). El resultado del trabajo de los agentes individuales debe ser accesible para todos los demás agentes, de manera que puedan evaluar si pueden contribuir a encontrar una solución y enviar el resultado de su trabajo.

Fuerzas

  • La secuencia en la que los agentes de conocimiento pueden contribuir a resolver el problema no es determinante y puede variar en función de las estrategias de resolución de problemas.

  • La entrada de agentes diferentes (el resultado o soluciones parciales) puede tener diferentes representaciones.

  • Los agentes no se conocen directamente, pero pueden evaluar las contribuciones enviadas por los demás.

Solución

Una serie de agentes de conocimiento tienen acceso a un almacén de datos compartidos llamado Pizarra. La Pizarra proporciona una interfaz para inspeccionar y actualizar su contenido. El objeto / módulo de Control activa a los agentes siguiendo una estrategia. Tras ser activado, un agente inspecciona la pizarra para ver si puede contribuir a resolver el problema. Si el agente decide que puede contribuir, el objeto de control permite a los agentes poner la solución parcial (o final) en la pizarra.

Ejemplo:

Diagrama descrito en el contenido.

Este diagrama muestra la vista estructural o estática modelada con UML; formaría parte de una colaboración con parámetros, que después se vincula a parámetros reales para crear instancias del patrón.

Estilo de la arquitectura

Una arquitectura de software, o simplemente una vista de la arquitectura, puede tener un atributo llamado estilo de la arquitectura, que reduce el conjunto de formatos posibles para escoger e impone un cierto grado de uniformidad con la arquitectura. El estilo puede definirse mediante un conjunto de patrones, o mediante la elección de componentes o conectores específicos como bloques de compilación básicos. Para un sistema dado, el estilo se puede capturar como parte de la descripción de la arquitectura en una guía de estilo de la arquitectura, que se proporciona a través del producto de trabajo Directrices específicas del proyecto en RUP. El estilo desempeña un papel principal en la comprensibilidad y la integridad de la arquitectura.

Anteproyecto de arquitectura

La representación gráfica de una vista de la arquitectura se llama anteproyecto de arquitectura. Para las diferentes vistas que se describen arriba, los anteproyectos constan de los siguientes diagramas de lenguaje unificado de modelado [UML01]:

  • Vista lógica. Diagramas de clase, máquinas de estado y diagramas de objeto
  • Vista de proceso. Diagramas de clase y diagramas de objeto (tareas contenedoras, procesos y hebras)
  • Vista de implementación. Diagramas de componentes
  • Vista de despliegue. Diagramas de despliegue
  • Vista de guión de uso. Diagramas de guión de uso que representan guiones de uso, actores y clases de diseño ordinarias; diagramas de secuencia que representan objetos de diseño y su colaboración

El proceso de arquitectura

En RUP, la arquitectura es principalmente un resultado del análisis y el flujo de trabajo de diseño. A medida que el proyecto reactiva este flujo de trabajo, de iteración e iteración, la arquitectura evoluciona hasta que está perfeccionada y pulida. Dado que todas las iteraciones incluyen integración y pruebas, la arquitectura es bastante robusta cuando se entrega el producto. Esta arquitectura es uno de los focos principales de las iteraciones de la fase de Elaboración, al final de cual la arquitectura suele tener su línea base.