ARCADIA ( Architecture Analysis & Design Integrated Approach ) es un método de ingeniería de arquitectura de sistemas y software basado en actividades de ingeniería centradas en la arquitectura y basadas en modelos .
En el ciclo de desarrollo de un sistema, las prácticas anteriores se centraban más en la definición de requisitos , su asignación a cada componente del sistema y la trazabilidad asociada. Los enfoques actuales se centran más bien en el análisis funcional , el diseño del sistema , la justificación de las opciones arquitectónicas y los pasos de verificación. Además, el diseño tiene en cuenta no solo el punto de vista funcional , sino también otros puntos de vista que afectan a la definición y el desglose del sistema. Por ejemplo, las restricciones relacionadas con la integración del sistema, la gestión de la línea de productos , la seguridad , el rendimiento y la viabilidad . Por lo tanto, la ingeniería de sistemas no se trata solo de la gestión de los requisitos del sistema, sino que es una actividad de diseño compleja.
Como respuesta a este desafío, Thales creó en 2007 el método ARCADIA, colocando la arquitectura y la colaboración en el centro de las prácticas de ingeniería de sistemas.
La visión de ARCADIA fue romper los "muros" entre las diferentes especializaciones de ingeniería, incluidos arquitectos , equipos de desarrollo, especialistas, equipos IVVQ (Integración, Verificación, Validación y Calificación), clientes y socios externos.
El método ARCADIA está a punto de estandarizarse como norma experimental AFNOR . [1] Se publicó el 7 de marzo de 2018.
El método ARCADIA se aplica al diseño de sistemas complejos y críticos , y más generalmente a arquitecturas que están sujetas a múltiples restricciones funcionales y no funcionales , incluyendo software, arquitecturas electrónicas, eléctricas y procesos industriales. Define un conjunto de prácticas que guían el análisis de necesidades y el diseño para satisfacer un requisito operativo. Al mismo tiempo es adaptable a los procesos y restricciones vinculados a varios tipos de ciclos de vida como el enfoque de abajo hacia arriba , la reutilización de aplicaciones, el desarrollo incremental, iterativo y parcial.
ARCADIA es un método de ingeniería estructurado para identificar y comprobar la arquitectura de sistemas complejos. Fomenta el trabajo colaborativo entre todos los interesados durante muchas de las fases de ingeniería del sistema. Permite iteraciones durante la fase de definición que ayudan a los arquitectos a converger hacia la satisfacción de todas las necesidades identificadas.
Aunque los requisitos textuales se mantienen como soporte para parte de la captura de las necesidades del cliente, ARCADIA favorece el análisis funcional como la principal forma de formalizar la necesidad y el comportamiento de la solución. Esto incluye aspectos operativos, funcionales y no funcionales, junto con la definición resultante de la arquitectura, basada en este análisis funcional y justificada en función de él.
ARCADIA se basa en los siguientes principios generales:
El método ARCADIA se implementa a través de Capella , una herramienta de modelado que cumple con las restricciones de implementación a gran escala en un contexto operativo. Capella está disponible de forma gratuita en la comunidad de ingeniería en código abierto.
El método ARCADIA:
Una de las dificultades que se encuentran con frecuencia en el desarrollo de sistemas complejos proviene de la superposición de varias cadenas funcionales parcialmente independientes que utilizan recursos compartidos (incluidos, entre otros, los recursos informáticos). El método ARCADIA y las herramientas subyacentes se utilizan para identificar las cadenas funcionales, sus escenarios de superposición y el rendimiento deseado, junto con su soporte por parte de la arquitectura. A partir del primer nivel de análisis del sistema, se asegura la trazabilidad a lo largo de la definición del proceso y se verifica cada diseño arquitectónico propuesto frente al rendimiento y las limitaciones esperadas.
Las propiedades no funcionales esperadas de la solución del sistema también se formalizan en "puntos de vista". Cada punto de vista captura las restricciones que el sistema debe enfrentar o cumplir (eventos temidos, amenazas de seguridad, expectativas de latencia, restricciones de la línea de productos o de reutilización, problemas de consumo de energía o de costos, etc.). Luego, el modelo de arquitectura se analiza automáticamente para verificar que cumple con estas restricciones, gracias a reglas especializadas dedicadas (computación de rendimiento, consumo de recursos, barreras de seguridad, etc.). Este análisis se puede realizar muy temprano en el ciclo de desarrollo, detectando problemas de diseño lo antes posible ("validación temprana").
En resumen, el enfoque de caracterización por vistas (o "puntos de vista") verifica que la arquitectura propuesta sea capaz de proporcionar las funciones requeridas con el nivel deseado de rendimiento, seguridad, confiabilidad, masa, escalabilidad, entornos, interfaces, etc., asegurando la consistencia de las decisiones de ingeniería, porque todas las partes interesadas en la ingeniería comparten la misma información de ingeniería y pueden aplicar sus propias vistas y verificaciones a ellas, a fin de asegurar la definición común.
A continuación se describen las vistas de primer nivel utilizadas para elaborar y compartir el modelo de arquitectura:
El primer paso se centra en el análisis de las necesidades y objetivos del cliente, las misiones y actividades previstas, mucho más allá de los requisitos del sistema/sw. Se espera que esto garantice una buena adecuación de la definición del sistema/sw con respecto a su uso operativo real y defina las condiciones de IVVQ. Los resultados de este paso consisten principalmente en una "arquitectura operativa" que describe y estructura esta necesidad, en términos de actores/usuarios, sus capacidades y actividades operativas, escenarios de uso operativo que dan parámetros de dimensionamiento, restricciones operativas que incluyen seguridad, protección, ciclo de vida, etc.
El segundo paso se centra ahora en el sistema/SW en sí, con el fin de definir cómo puede satisfacer la necesidad operativa anterior, junto con su comportamiento y cualidades esperadas: funciones del sistema/SW que se deben soportar e intercambios relacionados, restricciones no funcionales (seguridad, protección...), rendimientos asignados a los límites del sistema, reparto de funciones e interacciones entre el sistema y los operadores. También se comprueba la viabilidad (incluidos los costes, el calendario y la preparación tecnológica) de los requisitos del cliente y, si es necesario, se proporcionan medios para renegociar su contenido. Para ello, se esboza una primera arquitectura del sistema/SW (modelo de diseño arquitectónico) a partir de la necesidad funcional del sistema/SW; a continuación, se examinan los requisitos en relación con esta arquitectura para evaluar su coste y consistencia. Los resultados de este paso consisten principalmente en la descripción de la necesidad funcional del sistema/SW, la interoperabilidad y la interacción con los usuarios y los sistemas externos (funciones, intercambios más restricciones no funcionales) y los requisitos del sistema/SW.
Tenga en cuenta que estos dos pasos, que constituyen la primera parte de la construcción de la arquitectura, "especifican" el diseño posterior y, por lo tanto, deben aprobarse/validarse con el cliente.
El tercer paso tiene como objetivo identificar las partes del sistema/SW (en adelante, componentes), sus contenidos, relaciones y propiedades, excluyendo los problemas técnicos o tecnológicos o de implementación. Esto constituye la arquitectura lógica del sistema/SW. Para que este desglose de componentes sea estable en los pasos siguientes, se tienen en cuenta todas las restricciones [no funcionales] principales (seguridad, rendimiento, IVV, costo, no técnicas, etc.) y se comparan entre sí para encontrar el mejor compromiso entre ellas. Este método se describe como "basado en puntos de vista", siendo los puntos de vista la formalización de la forma en que estas restricciones afectan a la arquitectura del sistema/SW. Los resultados de este paso consisten en la arquitectura lógica seleccionada: definición de componentes e interfaces, incluida la formalización de todos los puntos de vista y la forma en que se tienen en cuenta en el diseño de los componentes. Dado que la arquitectura debe validarse en función de las necesidades, también se producen vínculos con los requisitos y los escenarios operativos.
El cuarto paso tiene las mismas intenciones que la construcción de la arquitectura lógica, excepto que define la arquitectura "final" del sistema/SW en este nivel de ingeniería, lista para desarrollarse (por niveles de ingeniería inferiores). Por lo tanto, introduce la racionalización, los patrones arquitectónicos, los nuevos servicios técnicos y componentes, y hace que la arquitectura lógica evolucione de acuerdo con la implementación, las restricciones técnicas y tecnológicas y las opciones (en este nivel de ingeniería). Obsérvese que el mismo método "basado en puntos de vista" que para la construcción de la arquitectura lógica se utiliza para la definición de la arquitectura física. Los resultados de este paso consisten en la arquitectura física seleccionada: los componentes que se van a producir, incluida la formalización de todos los puntos de vista y la forma en que se tienen en cuenta en el diseño de los componentes. También se producen vínculos con los requisitos y los escenarios operativos.
El quinto y último paso es una contribución a la construcción de la EPBS (Estructura de Desglose del Producto Final), aprovechando los beneficios del trabajo arquitectónico anterior, para hacer cumplir la definición de los requisitos de los componentes y preparar un IVVQ seguro. Aquí se resumen y verifican todas las opciones asociadas con la arquitectura del sistema/SW elegida, y todas las hipótesis y restricciones impuestas a los componentes y la arquitectura para que se ajusten a las necesidades y restricciones. Los resultados de este paso son principalmente un "contrato de integración de componentes", que recopila todas las propiedades esperadas necesarias para cada componente que se desarrollará.
La siguiente figura muestra una visión global que resume el proceso técnico recomendado, presentando los tres elementos del tríptico de ingeniería y sus actividades de producción a lo largo del proceso de definición y diseño.
Como parte del Proyecto Clarity, se publicará un libro sobre el método ARCADIA. Actualmente, se puede descargar un documento introductorio en el sitio web de Capella. [2]
El método ARCADIA fue presentado en diversos eventos:
