Modelo arquitectónico de software

Un modelo arquitectónico (en software ) contiene varios diagramas que representan propiedades estáticas o dinámicas (de comportamiento) del software en diseño. ^{[ 1 ] [ 2 ] [ 3 ]} Los diagramas representan diferentes puntos de vista del sistema dentro del alcance de análisis apropiado. Estos diagramas se crean utilizando estándares disponibles cuyo objetivo principal es ilustrar un conjunto específico de compensaciones inherentes a la estructura y el diseño de un sistema o ecosistema. Los arquitectos de software utilizan modelos arquitectónicos para facilitar la comunicación y obtener retroalimentación de sus pares.

Algunos elementos clave en un modelo arquitectónico de software incluyen:

• Rich : Respecto al punto de vista en cuestión, debe haber información suficiente para describir la zona en detalle. La información no debe ser incompleta ni vaga. El objetivo es minimizar los malentendidos, no perpetuarlos. Véanse las notas a continuación sobre la "preocupación principal".
• Riguroso : El arquitecto ha aplicado una metodología específica para crear este modelo en particular, y el modelo resultante tiene una apariencia determinada. Una prueba de rigor podría establecer que si dos arquitectos, en ciudades diferentes, describieran lo mismo, los diagramas resultantes serían prácticamente idénticos (con la posible excepción de la disposición visual, hasta cierto punto).
• Diagrama : En general, un modelo puede referirse a cualquier abstracción que simplifique algo con el fin de abordar un punto de vista particular. Esta definición subclasifica específicamente los "modelos arquitectónicos" dentro del subconjunto de descripciones de modelos que se representan como diagramas.
• Estándares : Los estándares funcionan cuando todos los conocen y los utilizan. Esto permite un nivel de comunicación que no se puede lograr cuando cada diagrama es sustancialmente diferente de otro. El Lenguaje Unificado de Modelado (UML) es el estándar más citado.
• Preocupación principal : Es fácil caer en el exceso de detalles al incluir muchas necesidades diferentes en un solo diagrama. Esto debe evitarse. Es mejor dibujar varios diagramas, uno para cada punto de vista, que un "megadiagrama" con un contenido extremadamente rico. Recuerde esto: al construir casas, el arquitecto entrega muchos diagramas diferentes. Cada uno se utiliza de manera distinta. Con frecuencia, el paquete final de planos incluirá diagramas junto con el plano de planta varias veces: plano de estructura, plano eléctrico, plano de calefacción, plano de plomería, etc. Esto garantiza que la información proporcionada sea solo la necesaria. Por ejemplo, un subcontratista de plomería no necesita los detalles que un electricista necesitaría saber.
• Ilustrar : La idea detrás de la creación de un modelo es comunicar y obtener retroalimentación valiosa. El objetivo del diagrama debe ser responder una pregunta específica y compartir esa respuesta con otros para:
  1. ver si están de acuerdo
  2. guiar su trabajo.
• Regla general: sepa qué es lo que quiere decir y a quién pretende influir con ello.
• Conjunto específico de compensaciones : La metodología del método de análisis de compensaciones de arquitectura (ATAM) describe un proceso mediante el cual la arquitectura de software puede ser revisada por pares para determinar su idoneidad. ATAM parte de una noción básica: no existe un diseño que sirva para todas las ocasiones. Se puede crear un diseño genérico, pero luego es necesario adaptarlo a situaciones específicas según los requisitos del negocio. En efecto, se realizan compensaciones. El diagrama debe hacer visibles esas compensaciones específicas. Por lo tanto, antes de que un arquitecto cree un diagrama, debe estar preparado para describir, con palabras, qué compensaciones intenta ilustrar en este modelo.
• Compromisos inherentes a la estructura y el diseño : Un componente no es un compromiso. Los compromisos rara vez se representan gráficamente en un diagrama. Son los principios fundamentales que dan origen a los modelos de diseño. Cuando un arquitecto desea describir o defender un compromiso específico, puede utilizar el diagrama para fundamentar su postura.
• Sistema o ecosistema : El modelado, en general, puede realizarse en diferentes niveles de abstracción. Resulta útil modelar la arquitectura de una aplicación específica, incluyendo sus componentes e interacciones. También es conveniente modelar los sistemas de aplicaciones necesarios para un proceso de negocio completo (como el ciclo de pedido a cobro). Sin embargo, no suele ser útil considerar el modelo de un único componente y sus clases como arquitectura de software. En ese nivel, el modelo, si bien valioso en sí mismo, ilustra mucho más el diseño que la arquitectura.

• Marco de modelado orientado a servicios (SOMF)

• La publicación Software Architecture Definitions del SEI contiene una lista de definiciones de arquitectura utilizadas por autores clásicos y modernos.
• El modelo arquitectónico contiene la definición de un modelo arquitectónico procedente de la base de datos de Ingeniería de Software Orientada a Objetos de la Universidad de Ottawa.
• El Método de Análisis de Compromisos Arquitectónicos (ATAM, por sus siglas en inglés) es un método mediante el cual se puede evaluar la idoneidad y el ajuste de la arquitectura a los requisitos.