ARCADIA ( Arco hitecture A nálisis y D iseño que NTEGRADO Un nfoque) es un sistema y software de método de arquitectura de la ingeniería, basado en la arquitectura-céntrica y de ingeniería basados en modelos actividades.
Historia
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 componente del sistema y la trazabilidad asociada. Los enfoques actuales se centran más bien en el análisis funcional , el diseño de sistemas , la justificación de las opciones arquitectónicas y los pasos de verificación. Además, el diseño tiene en cuenta no sólo el funcional punto de vista, sino también otros puntos de vista, que afectan a la definición y el desglose del sistema. Por ejemplo, las limitaciones 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 administrar los requisitos del sistema, sino que es una actividad de diseño compleja.
Como respuesta a este desafío, Thales creó el método ARCADIA en 2007, colocando la arquitectura y la colaboración en el centro de las prácticas de ingeniería de sistemas.
La visión de ARCADIA era romper los "muros" entre las diferentes especializaciones de ingeniería, incluidos arquitectos , equipos de desarrollo, especialistas, equipos IVVQ , clientes y socios externos.
Normalización
El método ARCADIA está a punto de ser estandarizado como norma experimental AFNOR . [1] Ha sido publicado el 7 de marzo de 2018.
Contexto
El método ARCADIA se aplica al diseño de sistemas complejos y críticos y , en general, arquitecturas que están sujetas a múltiples restricciones funcionales y no funcionales , incluidas arquitecturas de software, electrónicas, eléctricas y procesos industriales. Define un conjunto de prácticas que orientan el análisis y el diseño de necesidades para cumplir con un requisito operativo. Al mismo tiempo, es adaptable a los procesos y restricciones vinculados a varios tipos de ciclos de vida, como el enfoque ascendente , la reutilización de aplicaciones, el desarrollo incremental, iterativo y parcial.
Objetivos y medios de acción
ARCADIA es un método de ingeniería estructurado para identificar y verificar la arquitectura de sistemas complejos. Promueve el trabajo colaborativo entre todas las partes interesadas 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.
Incluso si los requisitos textuales se mantienen como soporte para parte de la captura de 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 y justificada en contra de este análisis funcional.
ARCADIA se basa en los siguientes principios generales:
- Todos los interesados en ingeniería comparten el mismo lenguaje, conjunto de métodos de artefactos e información de ingeniería, descripción de la necesidad y el producto en sí como modelo compartido;
- Cada conjunto de restricciones (por ejemplo, seguridad, desempeño, costo, masa, etc.) se formaliza en un "punto de vista" contra el cual se verificará cada arquitectura candidata;
- Se establecen reglas de verificación de la arquitectura y se cuestiona el modelo contra ellas, para verificar que la definición de la arquitectura cumple con las expectativas, lo antes posible en el proceso;
- La co-ingeniería entre los diferentes niveles de ingeniería se apoya en el desarrollo conjunto de modelos. Los modelos de varios niveles de la arquitectura y las compensaciones se deducen, validan y / o conectan entre sí.
El método ARCADIA está diseñado 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 ingenieros en código abierto.
Resumen de funciones
El método ARCADIA:
- Cubre todas las actividades de ingeniería estructuradas, desde la captura de las necesidades operativas del cliente hasta la validación de la verificación de la integración del sistema (IVV);
- Toma en cuenta múltiples niveles de ingeniería y su colaboración efectiva (sistema, subsistema, software, hardware, etc.);
- Integra la co-ingeniería con la ingeniería de especialidad (seguridad, protección, rendimiento, interfaces, logística ...) e IVV;
- Brinda la capacidad no solo de compartir modelos descriptivos sino también de validar colaborativamente las propiedades de la definición y la arquitectura;
- Se ha probado en el campo en aplicaciones industriales a gran escala y actualmente se implementa en docenas de proyectos importantes en varios países y divisiones de Thales.
Enfoque metodológico
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 cadenas funcionales, sus escenarios superpuestos y el rendimiento deseado, junto con su soporte por la arquitectura. Comenzando con el primer nivel de análisis del sistema, aseguran la trazabilidad a lo largo de la definición del proceso y verifican cada diseño arquitectónico propuesto con el desempeño esperado y las restricciones.
Las propiedades no funcionales que se esperan 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, línea de productos o restricciones de reutilización, consumo de energía o problemas de costos, y más). Luego, el modelo de arquitectura se analiza automáticamente para verificar que cumple con estas restricciones, gracias a reglas especializadas dedicadas (cálculo del 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").
Como 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, masa, interfaces. , etc., asegurando la coherencia de las decisiones de ingeniería, porque todos los interesados en ingeniería comparten la misma información de ingeniería y pueden aplicarles sus propios puntos de vista y verificaciones, a fin de asegurar la definición común.
Presentación del enfoque y conceptos clave
Las vistas de primer nivel utilizadas para elaborar y compartir el modelo de arquitectura se describen a continuación:
- "Definir el problema: análisis de las necesidades operativas del cliente",
El primer paso se centra en analizar las necesidades y objetivos del cliente, las misiones y actividades esperadas, mucho más allá de los requisitos del sistema / software. Se espera que esto garantice una buena adecuación de la definición del sistema / software 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.
- "Formalización de los requisitos del sistema / software - Análisis de la necesidad del sistema / software",
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 esperados: funciones del sistema / SW que deben ser soportadas e intercambios relacionados, restricciones no funcionales (seguridad, seguridad ...), actuaciones asignadas a los límites del sistema, compartición de roles e interacciones entre el sistema y los operadores. También verifica la viabilidad (incluido el costo, el cronograma y la disponibilidad de la tecnología) de los requisitos del cliente y, si es necesario, brinda los medios para renegociar sus contenidos. Para hacer esto, se esboza una primera arquitectura temprana de sistema / SW (modelo de diseño arquitectónico), a partir de la necesidad funcional del sistema / SW; luego, los requisitos se examinan con esta arquitectura para evaluar su costo y consistencia. Los resultados de este paso consisten principalmente en la descripción de la necesidad funcional del sistema / software, 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 / software.
Tenga en cuenta que estos dos pasos, que constituyen la primera parte del edificio de Arquitectura, "especifican" el diseño posterior y, por lo tanto, deben ser aprobados / validados con el cliente.
- "Desarrollo de Arquitectura de Sistema / SW - Arquitectura Lógica",
El tercer paso tiene como objetivo identificar las partes del sistema / SW (en adelante, componentes), sus contenidos, relaciones y propiedades, excluyendo la implementación o problemas técnicos / tecnológicos. Esto constituye la arquitectura lógica del sistema / SW. Para que este desglose de los componentes sea estable en los siguientes pasos, todas las limitaciones importantes [no funcionales] (seguridad, protección, rendimiento, IVV, costo, no técnicas, etc.) se tienen en cuenta y se comparan entre sí para que para encontrar el mejor compromiso entre ellos. Este método se describe como "impulsado por puntos de vista", siendo los puntos de vista la formalización de la forma en que estas restricciones impactan en la arquitectura del sistema / software. 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 contra la necesidad, también se producen vínculos con los requisitos y los escenarios operativos.
- "Desarrollo de Arquitectura de Sistema / SW - Arquitectura Física",
El cuarto paso tiene las mismas intenciones que la construcción de arquitectura lógica, excepto que define la arquitectura "final" del sistema / SW en este nivel de ingeniería, lista para desarrollar (por niveles de ingeniería inferiores). Por lo tanto, introduce racionalización, patrones arquitectónicos, nuevos servicios y componentes técnicos, y hace que la arquitectura lógica evolucione de acuerdo con la implementación, las limitaciones y opciones técnicas y tecnológicas (en este nivel de ingeniería). Tenga en cuenta que el mismo método "basado en puntos de vista" que para la construcción de 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 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 requisitos y escenarios operativos.
- "Formalizar requisitos de componentes - Contratos de desarrollo e IVVQ",
El quinto y último paso es una contribución a la construcción de EPBS (estructura de desglose del producto final), aprovechando los beneficios del trabajo arquitectónico anterior, para hacer cumplir la definición de requisitos de componentes y preparar un IVVQ seguro. Todas las opciones asociadas al sistema / arquitectura SW elegida, y todas las hipótesis y restricciones impuestas a los componentes y la arquitectura para adaptarse a las necesidades y restricciones, se resumen y verifican aquí. Los resultados de este paso son principalmente "contrato de integración de componentes" recopilado todas las propiedades necesarias esperadas para cada componente a desarrollar.
La siguiente figura muestra una vista 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.
Comunicación
Como parte del Proyecto Claridad, se publicará un libro sobre el método ARCADIA. Actualmente, se encuentra disponible un documento introductorio para descargar en el sitio web de Capella. [2]
El método ARCADIA se presentó en varios eventos:
Conferencia | Título | Fecha | Lugar |
---|---|---|---|
MODELOS'16 | ARCADIA en pocas palabras [3] | 10/02/2016 | Saint Malo |
Simposio Internacional INCOSE | Implementación del cambio cultural MBSE: organización, entrenamiento y lecciones aprendidas [4] | 14/07/2015 | Seattle |
Simposio Internacional INCOSE | Desde las investigaciones iniciales hasta el lanzamiento a gran escala de un método MBSE y su banco de trabajo de apoyo: la experiencia de Thales [5] | 14/07/2015 | Seattle |
EclipseCon Francia | Modelado de sistemas con el método ARCADIA y la herramienta Capella [6] | 24/06/2015 | Toulouse |
Simposio de ingeniería de sistemas basados en modelos (MBSE) | Los desafíos de implementar soluciones MBSE [7] | 28/10/2014 | Canberra |
Simposio de ingeniería de sistemas basados en modelos (MBSE) | Arcadia y Capella en el campo [8] | 27/10/2014 | Canberra |
EclipseCon Francia | Arcadia / Capella, una solución de modelado probada en campo para la ingeniería de arquitectura de sistemas y software [9] | 19/06/2014 | Toulouse |
Escuela de verano MDD4DRES ENSTA | Comentarios sobre la ingeniería de sistemas: ARCADIA, un método basado en modelos para la ingeniería centrada en la arquitectura [10] | 09/01/2014 | Aber Wrac'h |
EclipseCon Norteamérica | Arcadia / Capella, una solución de modelado probada en el campo para la ingeniería de arquitectura de sistemas y software [11] | 20/03/2015 | San Francisco |
Diseño y gestión de sistemas complejos (CSDM) | ARCADIA: Colaboración basada en modelos para la ingeniería de sistemas, software y hardware [12] | 12/04/2013 | París |
Congrès Ingénierie grandes programas y complejos de sistemas | La modélisation chez Thales: un apoyo mayor a la colaboración de acteurs dans l'ingénierie des grands systèmes [13] | 06/10/2013 | Arcachon |
MÁSTIL | Hacia una ingeniería multinivel integrada: prácticas avanzadas de Thales y DCNS [14] | 06/04/2013 | Gdańsk |
CSDM | Lenguajes de modelado para análisis funcional puestos a prueba en la vida real [15] | 2012 | París |
ICAS | Método y herramientas para asegurar y apoyar la arquitectura colaborativa de sistemas restringidos [16] | 2010 | Lindo |
CSDM | Construcción de arquitectura basada en modelos para sistemas restringidos [17] | 2010 | París |
INCOSE; 08 Simposio | Método y herramientas para la arquitectura de sistemas restringidos [18] | 2008 | Utrecht |
Ver también
- Metamodelado
- Ingeniería basada en modelos
Referencias
- ^ "Norme PR XP Z67-140 | Norm'Info" . norminfo.afnor.org (en francés) . Consultado el 1 de febrero de 2018 .
- ^ "Documento introductorio de ARCADIA" . Consultado el 23 de octubre de 2015 .
- ^ "ARCADIA en pocas palabras" . Consultado el 6 de octubre de 2016 .
- ^ "Implementación del cambio cultural MBSE: organización, coaching y lecciones aprendidas" . Archivado desde el original el 3 de marzo de 2016 . Consultado el 23 de octubre de 2015 .
- ^ "Desde las investigaciones iniciales hasta el lanzamiento a gran escala de un método MBSE y su banco de trabajo de apoyo: la experiencia de Thales" . Archivado desde el original el 3 de marzo de 2016 . Consultado el 23 de octubre de 2015 .
- ^ "Modelado de sistemas con el método ARCADIA y la herramienta Capella" . Archivado desde el original el 14 de septiembre de 2015 . Consultado el 23 de octubre de 2015 .
- ^ "Los desafíos de implementar soluciones MBSE" . Consultado el 23 de octubre de 2015 .
- ^ "Arcadia y Capella en el campo" . Consultado el 23 de octubre de 2015 .
- ^ "Arcadia / Capella, una solución de modelado probada en campo para la ingeniería de arquitectura de sistemas y software" . Archivado desde el original el 21 de octubre de 2015 . Consultado el 23 de octubre de 2015 .
- ^ "Comentarios sobre Ingeniería de Sistemas - ARCADIA" . Consultado el 22 de octubre de 2015 .
- ^ "Arcadia / Capella, una solución de modelado probada en campo para la ingeniería de arquitectura de sistemas y software" . Archivado desde el original el 3 de marzo de 2016 . Consultado el 23 de octubre de 2015 .
- ^ "Colaboración basada en modelos para la ingeniería de sistemas, software y hardware" . Consultado el 23 de octubre de 2015 .
- ^ "La modélisation chez Thales: un apoyo mayor a la colaboración de acteurs dans l'ingénierie des grands systèmes" (PDF) . Archivado desde el original (PDF) el 3 de marzo de 2016 . Consultado el 23 de octubre de 2015 .
- ^ "Hacia una ingeniería multinivel integrada: prácticas avanzadas de Thales y DCNS" . Consultado el 23 de octubre de 2015 .
- ^ Voirin, Jean-Luc (2013). "Lenguajes de modelado para el análisis funcional puestos a prueba en la vida real". Diseño y gestión de sistemas complejos . págs. 139–150. doi : 10.1007 / 978-3-642-34404-6_9 . ISBN 978-3-642-34403-9.
- ^ "Método y herramientas para asegurar y apoyar la arquitectura colaborativa de sistemas restringidos" . Consultado el 23 de octubre de 2015 .
- ^ "Construcción de Arquitectura impulsada por modelos para sistemas restringidos" . Archivado desde el original el 3 de marzo de 2016 . Consultado el 23 de octubre de 2015 .
- ^ Voirin, Jean-Luc (2008). "Método y herramientas para la arquitectura de sistemas restringidos". Simposio Internacional INCOSE . 18 : 981–995. doi : 10.1002 / j.2334-5837.2008.tb00857.x .
enlaces externos
- Página web dedicada al método
- Foro oficial
- Thales, fundador del método