La vérification de conformité architecturale (en anglais, architecture conformance checking) regroupe l'ensemble des vérifications statiques et dynamiques d'une implémentation d'un logiciel à partir de son architecture. Un humain peut détecter visuellement des violations en comparant deux modèles représentant une architecture. Ce procédé n'est pas sans faille puisqu'il peut nécessiter une grande concentration, une certaine difficulté et impliquer des erreurs en fonction de la complexité du modèle. Le modèle peut être constitué de multiples vues augmentant sa complexité. La vérification de conformité automatisée (entendre par là, une vérification informatique) est un choix préférable dans ce genre de cas.
Contexte Définition de l'érosion logicielle L'architecture logicielle est soumise constamment à des pressions sur les exigences et les technologies utilisées tout en continuant à délivrer un niveau de performance acceptable pour les utilisateurs finaux. L'érosion logicielle est l'écart entre l'architecture prévue et son implémentation finale qui change selon ces différentes pressions. Souvent, les modifications faites durant le développement d'un système provoquent des dommages sur l'intégralité de sa structure et violent ses principes de design.
Causes d'une érosion logicielle L'érosion peut survenir à cause de plusieurs facteurs incluant : L'inconscience des développeurs logiciels puisqu'ils ne font pas toujours tous attention à respecter l'architecture établie au début du projet ; Les exigences contradictoires qui arrivent de façon imprévues au début du développement. Cela survient souvent quand la technologie choisie n'est pas maitrisée ; Les difficultés techniques qui peuvent survenir pendant l'implémentation lorsque les développeurs se rendent compte qu'un choix technologique ne parviendra pas à atteindre les objectifs désirés. La pression des deadlines qui sont fréquentes dans le développement logiciel.
Résolutions Plusieurs stratégies existent pour tenter de contrôler l'érosion : la minimiser, la prévenir et la réparer. La plus utilisée est la stratégie qui tente de minimiser l'érosion. Elle peut être implémentée par plusieurs techniques incluant la documentation, l'analyse et la surveillance de la conformité de l'architecture. La stratégie pour prévenir l'érosion vise à complètement l'éradiquer. Quant à la réparation, elle est utilisée pour déterminer si une implémentation est conforme à son architecture en réparant les dommages causés par l'érosion et réconciliant l'implémentation avec son architecture.
Pour chaque stratégie, il existe un second niveau de catégories classifiant plus précisément les différentes solutions : Minimiser Processus orienté conformité de l'architecture inclut le processus d'ingénierie logicielle qui assure la conformité de l'architecture pendant le développement et la maintenance du système. Gestion de l'évolution de l'architecture couvre les méthodes disponibles dans la gestion de l'évolution des spécifications logicielles en parallèle avec son implémentation. Mise en application des principes architecturales qui incorpore des méthodes et des outils pour transformer des modèles architecturaux en implémentation. Prévenir Liaison de l'architecture vers son implémentation inclut les mécanismes qui associent les modèles architecturaux avec le code source et supporte la capacité de gérer la conformité architecturale à l'exécution. Adaptation automatique des technologies permet aux systèmes de se reconfigurer eux-mêmes pour s'aligner avec leurs architectures après un changement sur leurs implémentations. Réparer Restauration de l'architecture implique d'extraire l'implémentation architecturale du code source. Techniques pour découvrir les architectures sont utiles pour susciter l'architecture voulue à partir des propriétés du système. Méthodes pour réconcilier l'écart entre l'implémentation et l'architecture voulue par le système.
Critères importants Vérification statique ou dynamique Les vérifications statiques sont effectuées sans exécuter le code. Elles sont faites pendant la compilation d'un système ou pendant sa phase de maintenance où l'application n'est plus connectée à son environnement de production. Elles peuvent être liées à la structure du code et les aspects de l'intégrité de la communication.
Il existe trois approches principales pour les vérifications statiques : La réflexion par modèles : Cette approche compare deux modèles du logiciel entre eux. Typiquement, entre une architecture visée du logiciel et une architecture basée sur le code source. La comparaison requiert un mapping entre les deux modèles pour effectuer la comparaison. Le mapping doit se faire manuellement par un développeur. Les règles de conformité entre les éléments de l'architecture : Les règles permettent d'autoriser ou d'interdire les relations entre deux composants de l'architecture. Elles peuvent mettre en évidence les violations comme la réflexion par modèles mais par contre le mapping est fait automatiquement. Les règles d'accès des composants : L'approche met en place de simples ports pour chaque composants et spécifie les composants qui sont autorisés à y accéder.
Les vérifications dynamiques ont deux objectifs : vérifier l'exécution et la cohérence entre l'architecture du système et la spécification définie. Elles sont utilisées comme une protection contre les fautes potentielles à l'exécution. Cette protection est implémentée par un moniteur pour pouvoir réagir aux différentes violations. Les vérifications dynamiques sont effectuées pendant que le système s'exécute et nécessitent donc l'accès à l'état d'exécution des opérations. Ces opérations sont validées par des contraintes architecturales dépendantes d'une solution souvent externe.
Ces deux types de vérifications peuvent être utilisés de façon complémentaire pour de la vérification de conformité entre une architecture et son implémentation.
Rapprochement entre l’architecture et son implémentation Les vérifications de conformité se base sur un mapping entre l'architecture et son implémentation. Ce rapprochement est nécessaire pour lancer les vérifications. Il en existe différentes catégories qui sont toutes utilisées par différentes solutions :
Les conventions de nommage à partir de l'architecture sur l'implémentation du programme. Cette technique peut être étendue par des annotations pour enrichir l'information sur l'architecture en faisant correspondre l'information avec l'implémentation correspondante. Combiner l'architecture et son implémentation dans une seule spécification. L'architecture fait partie intégrante de l'implémentation. Elle est développée dans l'application cible. Cependant, cette approche demande une plateforme d'exécution permanente. Spécifier les informations de mapping dans une spécification externe (à la fois de l'architecture et son implémentation). Elle demande un projet séparé pour avoir un mapping explicite pour toutes les fonctionnalités architecturales.
Principales approches / Solutions existantes PandArch Principe PandArch est un framework de vérifications de conformité entre l'architecture et l'implémentation d'un logiciel. Cette solution est designée pour être connectable, automatisée, personnalisable, non intrusive et extensible. Grâce à ces principes, elle vise à limiter les problèmes connus de vérifications en limitant l'impact sur les performances du logiciel cible, quand les vérifications sont actives. L'objectif principal de ce framework est de rendre la vérification de conformité dynamique d'architectures une option viable pour les développeurs.
La réalisation de PandArch a été motivée par plusieurs principes importants : Connectable : L'application cible peut s'exécuter avec ou sans le framework. Quand la solution n'est pas attachée à l'application, les fichiers compilés ne sont pas manipulés, Automatisée : La génération des règles de conformité et leurs vérifications sont automatisées, Non intrusive : Le code source de l'application cible reste inchangé, Les métriques sur la performance : L'impact sur les performances de l'application cible est minimalisé le plus possible, Extensible : Le framework peut s'accommoder des modifications sur les règles de conformité.
Objectifs Vérifier la conformité des fonctionnalités dynamiques par rapport à une implémentation n'est pas toujours possible quand le système est déployé dans son environnement de production. De plus, les routines de maintenance modifient les prérequis et les opérations peuvent alors causer une déviation du comportement de l'application en production.
PandArch vient proposer une solution pour la détection de violations à l'exécution d'un programme avec ses motivations sur la minimalisation des impacts sur l'application cible. La conformité des fonctionnalités dynamiques inclut l'instanciation à l'exécution, l'invocation de méthodes réflectives, les liaisons dynamiques, la qualité des services, etc. Fonctionnement La vérification de conformité entre l'architecture et l'implémentation d'un logiciel nécessite l'utilisation d'un système de surveillance pour reconstruire une vue de l'architecture à l'exécution de l'application cible. L'architecture extraite est utilisée pour les vérifications de conformité.
L'exécution du mécanisme de vérification architecturale de conformité se base sur une spécification de l'architecture. Cette spécification contient les annotations de mapping entre l'architecture et l'implémentation du logiciel cible. Les contraintes architecturales et les informations sur ce mapping sont extraites à partir de la compilation de cette spécification, et elles sont utilisées par le générateur de règles pour créer l'ensemble des règles de conformité.
Parallèlement à cela, le vérificateur de conformité prendra l'ensemble des règles de conformité. Il les validera pendant les évènements d'exécution survenant à l'exécution du programme. Ce processus peut alors produire une série de violations pour notifier l'architecte des dérivations présentes dans l'implémentation à partir de l'architecture.
Card Principe Card (de l'anglais Controlling Architectural Degradation) est un outil pour identifier l'érosion de l'architecture d'un programme Java. Cette solution a été développée pour être automatisée et accessible. Elle n'a pas besoin de spécifications, de descriptions architecturales et elle peut se suffire à elle-même, aucune dépendance n'est nécessaire. Elle utilise un langage de modélisation répandue et couramment utilisé par les développeurs, l'UML 2.0.
Il existe quelques fonctionnalités importantes dans Card : Un ensemble de règles définissant la conformité entre les diagrammes de classes et les diagrammes de séquences de l'UML 2.0 et l'implémentation Java. Le concept d'une spécification maitre, qui peut être soit le modèle soit l'implémentation. Une extension Eclipse qui implémente la vérification de conformité comme définit dans les règles de l'architecte.
Objectifs L'érosion architecturale est un problème bien connu et il existe déjà plusieurs approches pour prévenir, minimiser ou réparer ces érosions, principalement basé sur la concept de conformité. Cependant, la plupart de ces approches demande une rigueur stricte sur la spécification de l'architecture du logiciel cible avec l'utilisation d'un ou plusieurs outils. Des interventions manuelles sont aussi nécessaire pour le processus de vérification qui limite sa potentielle utilisation en milieu d'entreprise.
Les objectifs de Card tentent de résoudre tous ces problèmes en proposant un outil pour identifier l'érosion architecturale d'un programme comme solution envisageable par les entreprises. Fonctionnement