Arcadia (ingénierie)

Un article de Wikipédia, l'encyclopédie libre.

ARCADIA (ARCHITECTURE ANALYSIS & DESIGN INTEGRATED APPROACH) est une méthode d’ingénierie et de définition des architectures systèmes, logicielles, et matérielles, basée sur les modèles.

Méthode d’ingénierie et de définition des architectures systèmes, logicielles et matérielles.

Historique[modifier | modifier le code]

Historiquement, dans le cycle de développement d'un système, l'accent était mis sur la définition des exigences, leur allocation à chaque composant du système et la traçabilité associée plutôt que sur l'analyse fonctionnelle, la conception du système, la justification des choix architecturaux et des étapes de vérification. De plus, cette conception doit prendre en compte non seulement le point de vue fonctionnel, mais aussi d'autres points de vue, qui influent largement sur le découpage et la définition du système (contraintes d'intégration ou liées à la gestion en ligne de produits, aux contraintes de sécurité, de performance, de faisabilité, etc.). L'ingénierie des systèmes ne se résume donc pas à la gestion des exigences du système, mais passe avant tout par une activité de conception avancée de celui-ci.

La méthode ARCADIA a été définie par Thales en 2007 en réponse à cette problématique en plaçant l'architecture et la collaboration au centre de l'ingénierie des systèmes.

Cette vision permet notamment de briser les silos entre les différentes ingénieries de spécialité (Architectes, Équipes de développement, Spécialistes, Équipes IVVQ, Client, Partenaires externes, etc.) et ainsi favoriser la collaboration entre ces dernières.

Normalisation[modifier | modifier le code]

La méthode ARCADIA est en passe d'être normalisée auprès de l'AFNOR comme norme expérimentale[1]. Elle a été publiée le .

Contexte d'application[modifier | modifier le code]

La méthode ARCADIA s'applique à la conception des systèmes complexes et des systèmes critiques, et plus généralement d’architectures soumises à des contraintes fonctionnelles et non fonctionnelles multiples (y compris architectures logicielles, électroniques, électriques, processus industriels, etc.). Elle définit un ensemble de pratiques guidant l’analyse du besoin et la conception en vue de répondre à un besoin opérationnel et est conçue pour être adaptable aux processus et contraintes liées à de multiples cycles de vie : approche ascendante, réutilisation d'applicatifs, incrémentale, itérative, partielle, etc.

Objectifs et moyens d'action[modifier | modifier le code]

ARCADIA est une méthode structurée d'ingénierie destinée à définir et à valider l’architecture de systèmes complexes. Elle favorise le travail collaboratif de tous les intervenants, souvent nombreux, de la phase d’ingénierie (ou de définition) du système. Elle permet d’effectuer dès la phase de définition les itérations qui vont permettre de faire converger l’architecture vers l’adéquation à l’ensemble des besoins identifiés.

Si les exigences textuelles sont toujours présentes et utilisées comme contribution principale à l’expression du besoin en entrée de l’ingénierie, ARCADIA se place comme support majeur de l'ingénierie et de sa maîtrise, reposant sur une formalisation de l’analyse du besoin de nature opérationnelle, fonctionnelle et non fonctionnelle (fonctions attendues du système, chaînes fonctionnelles...), puis de la définition/justification de l'architecture à partir de cette analyse fonctionnelle.

Les principes généraux d’ARCADIA sont les suivants:

  • Tous les intervenants de l’ingénierie partagent la même méthode, les mêmes informations, la même description du besoin et du produit sous forme d’un modèle partagé ;
  • Chaque ensemble de contraintes (par exemple : sécurité, performances, coût, masse, etc.) est formalisé dans un "point de vue" par rapport auquel l’architecture proposée sera vérifiée ;
  • Les règles de vérification anticipée de l’architecture sont établies de manière à pouvoir vérifier au plus tôt l’architecture proposée ;
  • La co-ingénierie entre les différents niveaux d’ingénierie est soutenue par l’élaboration conjointe de modèles, et les modèles des différents niveaux et métiers sont déduits/validés/reliés les uns par rapport aux autres.

La méthode ARCADIA est outillée au travers de l’outil de modélisation Capella qui répond aux contraintes de déploiement en vraie grandeur dans un contexte opérationnel. Capella est mis gratuitement à disposition de la communauté ingénierie sous le mode Open Source.

Particularités de la méthode[modifier | modifier le code]

La méthode ARCADIA :

  • Couvre l’ensemble des activités structurantes de l’ingénierie, depuis la capture du besoin client opérationnel, jusqu’à l’intégration vérification validation (IVV) ;
  • Prend en compte les niveaux d’ingénierie multiples et leur collaboration efficace (système, sous-système, logiciel, matériel, etc.) ;
  • Intègre la co-ingénierie avec les ingénieries de spécialités (sécurité, sûreté, performances, interfaces, logistique…) et d’IVV ;
  • Est basée sur l’utilisation de modèles, non seulement descriptifs, mais aussi susceptibles de valider la définition et les propriétés de l’architecture, et constituant le support majeur à la co-ingénierie des équipes concernées ;
  • A passé avec succès le test de l’applicabilité sur des projets en taille réelle et situation opérationnelle contrainte, puisque actuellement[Quand ?] en déploiement sur plusieurs dizaines de grands projets dans plusieurs divisions et pays de Thales.

Approche méthodologique[modifier | modifier le code]

Points de vue
Points de vue
Collaboration
Collaboration

L’une des difficultés fréquemment rencontrée dans le développement de systèmes complexes vient de la mise en œuvre simultanée (superposition) de plusieurs chaînes fonctionnelles partiellement indépendantes utilisant des ressources partagées (notamment mais pas seulement, des ressources de calcul). La méthode ARCADIA et les outils sous-jacents permettent d’identifier les chaînes fonctionnelles, leurs scénarios de superposition, et les performances recherchées, dès le premier niveau d’analyse du système ; ils en assurent la traçabilité tout au long du processus de définition, et vérifient, pour chaque conception proposée, que l’architecture de traitement de ces chaînes fonctionnelles est capable des objectifs de performances, y compris en situation de partage de ressources, et d’itérer si la vérification n’est pas satisfaisante.

Les propriétés non fonctionnelles attendues sont par ailleurs formalisées dans des 'points de vue' traduisant les contraintes associées, et analysant l'architecture solution selon ces contraintes et des règles de savoir-faire métier. Cette analyse peut se faire très tôt dans le cycle de développement, détectant les problèmes de conception au plus tôt ("early validation").

Plus généralement l’approche de caractérisation par points de vue (ou "viewpoints") transverses permet de vérifier que l’architecture proposée est capable d’assurer les fonctions requises avec le niveau de performance recherché, mais aussi qu’elle peut répondre aux autres exigences dites non fonctionnelles (sécurité, sûreté de fonctionnement, masse, évolutivité, environnements, interfaces, etc.), mais tout aussi impératives.

Enfin, pour garantir la cohérence des décisions d'ingénierie, tous les intervenants de l'ingénierie partagent les mêmes informations, la même description du besoin et du produit, sous la forme d'un ensemble de modèles partagés.

Présentation de la démarche et principaux concepts[modifier | modifier le code]

Phase d'ingénierie Concept Définition
Analyse Opérationnelle "ce que les utilisateurs du système doivent accomplir" Analyse de la problématique des utilisateurs opérationnels en identifiant les acteurs devant interagir avec le système, leurs activités, et les échanges entre eux.
Analyse du Besoin Système "ce que le système doit réaliser pour les utilisateurs" Analyse Fonctionnelle externe pour identifier en réponse les fonctions du système nécessaires à ses utilisateurs (ex : "calculer l'itinéraire optimal", "détecter et localiser la menace"), sous contrainte des propriétés non fonctionnelles demandées.
Architecture Logique "comment le système va fonctionner pour répondre aux attentes" Analyse Fonctionnelle interne du système : quelles sont les sous-fonctions à réaliser et assembler pour réaliser les fonctions "utilisateur" identifiées lors de la phase précédente, identification des composants logiques réalisant ces sous-fonctions internes, en y intégrant les contraintes non fonctionnelles qu’on a choisi de traiter à ce niveau.
Architecture Physique "comment le système va être construit" Cette phase a le même objectif que l’architecture logique excepté qu’elle définit l’architecture finale du système, telle qu'elle doit être réalisée. Elle ajoute les fonctions requises par l’implémentation et les choix techniques, fait apparaître des composants comportementaux (ex : composants logiciel) qui réalisent ces fonctions. Ces composants comportementaux sont ensuite implémentés à l’aide de composants d’implémentation (ex : carte processeurs) qui offrent la ressource matérielle nécessaire.
"End-Product Breakdown Structure" (EPBS) et Contrats d'Intégration "ce qui est attendu du fournisseur de chaque composant" Cette phase déduit de l’architecture physique les conditions que devra remplir chaque composant pour satisfaire aux contraintes et choix de conception de l’architecture, réalisés dans les phases précédentes.

L’ensemble des éléments constitutifs de l’ingénierie et élaborés lors de l’application de la méthode sont formalisés, partagés et exploités par le biais de modèles à chaque niveau d’ingénierie ; pour chacun d’entre eux, les figures ci-dessous synthétisent son contenu en accord avec les phases décrites précédemment :

Phases d'ingénierie ARCADIA
Décomposition en phase d'ingénierie

ARCADIA vis-à-vis des Standards: xAF, SysML, AADL[modifier | modifier le code]

Les concepts ARCADIA sont compatibles avec les langages d'architecture tels que DODAF / NAF Architecture Frameworks, UML2 et SysML, AADL etc.

Communication[modifier | modifier le code]

Au travers du projet Clarity, un ouvrage dédié à la méthode a été rédigé et publié en 2017[2]. Un document d'introduction est disponible en téléchargement sur le site web de Capella[3].

La méthode ARCADIA a été présentée lors de divers événements :

Conférence Titre de la présentation Date Lieu
MODELS'16 ARCADIA in a nutshell[4] 02/10/2016 Saint-Malo
INCOSE International Symposium Implementing the MBSE Cultural Change: Organization, Coaching and Lessons Learned[5] 14/07/2015 Seattle
INCOSE International Symposium From initial investigations up to large-scale rollout of an MBSE method and its supporting workbench: the Thales experience[6] 14/07/2015 Seattle
EclipseCon France Systems Modeling with the ARCADIA method and the Capella tool[7] 24/06/2015 Toulouse
Model-Based System Engineering (MBSE) Symposium The Challenges of Deploying MBSE Solutions[8] 28/10/2014 Canberra
Model-Based System Engineering (MBSE) Symposium Arcadia and Capella on the Field: Real-World MBSE Use Cases[9] 27/10/2014 Canberra
EclipseCon France Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering[10] 19/06/2014 Toulouse
MDD4DRES ENSTA Summer school Feedbacks on System Engineering – ARCADIA, a model-based method for Architecture-centric Engineering[11] 01/09/2014 Aber-Wrac'h
EclipseCon North America Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering[12] 20/03/2014 San Francisco
Complex Systems Design & Management (CSDM) ARCADIA: Model-Based Collaboration for System, Software and Hardware Engineering[13] 04/12/2013 Paris
Congrès Ingénierie grands programmes et systèmes complexes La modélisation chez Thales : un support majeur à la collaboration des acteurs dans l’ingénierie des grands systèmes[14] 10/06/2013 Arcachon
MAST Toward integrated multi-level engineering - Thales and DCNS advanced Practices[15] 04/06/2013 Gdańsk
CSDM Modelling languages for Functional Analysis put to the test of real life[16] 2012 Paris
ICAS Method and tools to secure and support collaborative architecting of constrained systems[17] 2010 Nice
CSDM Model-driven Architecture building for constrained Systems[18] 2010 Paris
INCOSE’08 Symposium Method & Tools for constrained System Architecting[19] 2008 Utrecht

Références[modifier | modifier le code]

  1. « Norme PR XP Z67-140 | Norm'Info », sur norminfo.afnor.org (consulté le )
  2. (en)« Model-based System and Architecture Engineering with the Arcadia Method », sur elsevier.com (consulté le )
  3. (en) « Document d'introduction à la méthode ARCADIA », sur polarsys.org (consulté le )
  4. (en) « ARCADIA in a nutshell », sur models2016.irisa.fr (consulté le )
  5. (en) « Implementing the MBSE Cultural Change: Organization, Coaching and Lessons Learned », sur events.incose.org (consulté le )
  6. (en) « From initial investigations up to large-scale rollout of an MBSE method and its supporting workbench: the Thales experience », sur events.incose.org (consulté le )
  7. (en) « Systems Modeling with the ARCADIA method and the Capella tool » [archive du ], sur eclipsecon.org (consulté le )
  8. (en) « The Challenges of Deploying MBSE Solutions », sur sesa.org.au (consulté le )
  9. (en) « Arcadia and Capella in the Field », sur sesa.org.au (consulté le )
  10. (en) « Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering », sur eclipsecon.org (consulté le )
  11. (en) « Feedbacks on System Engineering – ARCADIA, a model-based method for Architecture-centric Engineering », sur mdd4dres.org (consulté le )
  12. (en) « Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering » [archive du ], sur eclipsecon.org (consulté le )
  13. (en) « Model-Based Collaboration for System, Software and Hardware Engineering », sur polarsys.org (consulté le )
  14. (en) « La modélisation chez Thales : un support majeur à la collaboration des acteurs dans l’ingénierie des grands systèmes » [archive du ], sur avantage-aquitaine.com (consulté le )
  15. (en) « Toward integrated multi-level engineering - Thales and DCNS advanced Practices », sur lanyrd.com (consulté le )
  16. (en) « Modelling languages for Functional Analysis put to the test of real life », sur springer.com (consulté le )
  17. (en) « Method and tools to secure and support collaborative architecting of constrained systems », sur icas.org (consulté le )
  18. (en) « Model-driven Architecture building for constrained Systems », sur cesames.net (consulté le )
  19. (en) « Method & Tools for constrained System Architecting », sur wiley.com (consulté le )

Liens externes[modifier | modifier le code]