Arcadia (ingénierie)
From Wikipedia, the free encyclopedia
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.
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
Contexte d'application
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
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
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
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
| 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 :
 |
 |
ARCADIA vis-à-vis des standards : xAF, SysML, AADL
Les concepts ARCADIA sont compatibles avec les langages d'architecture tels que DODAF / NAF Architecture Frameworks, UML2 et SysML, AADL, etc.
