Instructions: Reconnaissance, analyse et contrôle de l'architecture
Ces instructions expliquent comment procéder à la reconnaissance, à l'analyse et au contrôle de l'architecture en utilisant un environnement de modélisation RSA pour un projet.
Relations
Eléments connexes
Description principale

Introduction

Dans différentes tâches du processus RUP, nous avons souligné le besoin d'examiner le modèle de conception émergent, d'émettre des jugements sur différents aspects de qualité et, si nécessaire, de modifier le modèle. Il est aussi important d'être capable de conserver l'intégrité architecturale d'un système une fois qu'il a été implémenté, afin de s'assurer que les contraintes liées à l'architecture et à la conception soient respectées et que le système, tel qu'il est implémenté, corresponde toujours à la vision architecturale. Dans RUP, ces points de contrôle importants ont lieu dans les Tâches : Réviser l'architecture, Réviser la conception et Réviser le code.

Un autre problème apparaît lors de la synthèse de l'architecture et de la conception ; dans les Tâches : Analyse architecturale (voir aussi Développer une vue d'ensemble de l'architecture et Evaluer les actifs disponibles) et Incorporer les éléments de conception existants, l'architecte logiciel doit rechercher les opportunités de réutilisation des actifs de code et de conception existants en les ajoutant au modèle de conception, après avoir eu recours, si nécessaire, à l'ingénierie inverse. A moins que les actifs réutilisés ne soient accompagnés d'une sorte de "certification de qualité", l'architecte logiciel leur fera subir le même examen approfondi que celui de la conception et du code nouvellement créés.

Dans les deux cas, les besoins directs de l'architecte logiciel sont identiques pour cette analyse statique. Il doit :

  • Prendre une application codée (ou un fragment de l'application), découvrir sa structure symbolique et traduire cela idéalement dans un modèle de conception, sous une forme UML. Rassembler des artefacts documentaires visualisables permet aussi à l'architecte logiciel de voir la façon dont le code est réellement structuré lorsque la documentation n'existe pas ou est dépassée.
  • Etre capable d'analyser tous les modèles de conception, de collecter les métriques de qualité (comme le couplage) qui sont référencées dans l'Artefact : Plan de mesure et vérifier leur compatibilité avec l'Artefact : Document d'architecture logicielle et les principes de conception
  • Etre tenu au courant des changements concernant l'architecture ou la conception, de façon à ce que les modifications soient effectuées, si nécessaire. Leur importance est jugée en fonction des critères établis par l'architecte logiciel.

En théorie, on peut répondre à ces besoins grâce à l'inspection ; en pratique, pour les systèmes plus complexes et plus grands, une assistance automatisée est essentielle. Les sections suivantes traitent de ces sujets et fournissent des exemples de prise en charge des outils.

Reconnaissance et récupération de l'architecture

Généralités

Lors d'un nouveau développement, l'architecture logicielle émerge des exigences, du contexte du domaine et des conventions (qui incluent les patterns et les mécanismes) ; l'artefact Spécification supplémentaire joue un rôle important dans le choix de l'architecture. Ce processus consistant à modeler l'architecture logicielle est parfois appelé "reconnaissance" car la transformation des exigences en architecture ne se fait généralement pas de manière directe et mécanique. Toutefois, nous utilisons ici le mot reconnaissance dans un sens différent, afin de décrire le processus qui vise à aider l'architecte logiciel à comprendre une application ou un morceau d'application existant déjà sous une forme codée. La récupération architecturale est plus ambitieuse : l'architecte logiciel ne cherche en effet pas seulement à comprendre une application, mais aussi à extraire un modèle de cette application, idéalement à un niveau d'abstraction compatible avec le modèle de conception. Il est alors possible de fusionner ces modèles et, grâce à la transformation, de générer une nouvelle application, peut-être pour une plateforme différente.

Reconnaissance

Dans les tâches : Analyse architecturale (voir aussi Développer une vue d'ensemble de l'architecture et Evaluer les actifs disponibles) et Incorporer les éléments de conception existants, l'architecte logiciel cherche les possibilités de réutilisation des actifs de conception et de code. Par exemple, une organisation peut avoir plusieurs architectures de références dans sa base d'actifs, idéalement complétées par une documentation et des modèles de pointe. Cependant, il y a souvent plus que du code source et il est rare qu'il y ait une documentation architecturale.

Dans de nombreux cas, l'architecte logiciel ne peut pas traiter le code d'une boîte noire (même si les interfaces sont clairement définies) mais doit comprendre sa structure. La capacité de générer automatiquement des descriptions de code affichables facilite grandement ce processus. L'architecte logiciel peut alors "reconnaître" visuellement les patterns et les antipatterns dans le code. On trouve un exemple de ce type d'assistance dans l'outil Rational Software Architect, où la fonction reconnaissance de l'architecture remplira automatiquement les diagrammes de rubrique, comme la structure de package, les éléments internes de classe, les arbres d'héritage et les collaborations pour les applications Java. Pour plus d'informations, voir la documentation manuel d'aide Rational Software Architect.

Récupération et transformation

Lorsque les actifs réutilisables sont accompagnés de modèles, il est possible de combiner ces modèles avec les modèles spécifiques au projet, puis de procéder à une implémentation spécifique à la plateforme en utilisant les techniques de transformation. Lorsqu'il n'existe que du code, il est parfois possible de le réutiliser, même avec une approche basée sur la transformation, en intégrant le code produit par la transformation au code existant.

L'architecte logiciel jouit d'un grand pouvoir et d'une grande flexibilité en utilisant la récupération d'architecture : la fonction récupération génère un modèle de l'application riche d'un point de vue sémantique, pouvant être utilisé pour la génération de code, ainsi que pour l'affichage. En pratique, il est facile de procéder à une ingénierie inverse pour transformer le code en une simple représentation visuelle ; ramener ce type de modèle au même niveau qu'un modèle de conception indépendant de la plateforme est en général difficile à automatiser entièrement.

Il s'agit essentiellement de la transformation d'un modèle spécifique à la plateforme en un modèle indépendant de la plateforme (voir aussi Concept : Développement guidé par modèle (MDD) et Architecture guidée par modèle (MDA )) ; le modèle indépendant de la plateforme obtenu (un fragment) est ensuite associé au modèle de conception (qui est aussi un modèle indépendant de la plateforme) en utilisant le type de transformation fusion de modèle (voir aussi [OMG03]).

Analyse des architectures

Le fait d'avoir des modèles affichables permet à l'architecte logiciel de vérifier la qualité architecturale par le biais de l'inspection. Cependant, cela peut être fastidieux et long. De plus, vérifier le respect des standards et des règles et rassembler les métriques de cette façon entraînent des erreurs. L'architecte logiciel doit chercher à automatiser ce processus au maximum et donc passer plus de temps à trouver et à appliquer des solutions ; l'automatisation lui permet de tester, de faire des suppositions et de vérifier le résultat rapidement.

Que peut-on automatiser ?

L'analyse architecturale automatisée peut :

  • Rechercher des patterns et des antipatterns (les structures pathologiques) dans l'architecture.
  • Réaliser des mesures sur différentes structures et établir des métriques
  • Vérifier le respect des contraintes par l'architecte logiciel (voir aussi le contrôle de l'architecture)

Le pattern est dicté par les standards du projet et de l'organisation et la façon de les utiliser est consignée dans le Document d'architecture logicielle (s'ils ont une importance architecturale) ou dans les principes de conception. Grâce à l'analyse automatisée, l'architecte logiciel peut contrôler rapidement l'utilisation du pattern afin de vérifier que le but du Document d'architecture logicielle et des principes de conception est atteint. Les antipatterns sont des structures d'architecture et de conception pathologiques qui affaiblissent l'architecture en la rendant moins robuste, plus complexe ou plus difficile à conserver par exemple.

Les mesures à réaliser sont énumérées dans le Produit : Plan de mesure (vous trouverez certaines des métriques suggérées dans les Instructions : Métriques). Le plan de mesure décrit aussi la façon d'utiliser une métrique, par exemple si des valeurs supérieures ou inférieures sont préférables ou si c'est la tendance qui est importante ; il est donc utile que l'analyse des métriques identifie aussi les "points chauds", c'est-à-dire les endroits dans l'architecture où des changements entraîneraient une nette amélioration de métriques collectées. De manière assez logique, ces dernières seront souvent associées à des pathologies dans la structure. L'architecte logiciel cherche donc l'amélioration, peut faire des changements ou déléguer les actions complémentaires qui peuvent être testées une fois terminées.

Quelle est la cible de l'analyse ?

La cible de l'analyse peut varier au cours du cycle de vie, selon l'approche de développement choisie. Lorsqu'un projet utilise une approche transformationnelle (générationnelle), la cible sera normalement le modèle de conception, en admettant que l'application générée soit toujours synchronisée avec la conception. Lorsqu'un Artefact : Modèle d'implémentation est créé et conservé à part, ou lorsque le code est réutilisé, concentrez-vous sur les changements apportés au code, pour vous assurer qu'il conserve une intégrité architecturale lorsqu'il est comparé au document d'architecture logicielle et aux principes de conception.

Ce type d'analyse (dans un modèle d'implémentation) peut ne pas reconstituer un modèle de conception explicite à partir du code pour des raisons d'analyse ; il est néanmoins concerné par les questions d'architecture et de conception (car elles sont évidente dans le code), mais pas par les standards de codification.

Exemple de ces concepts et de ces fonctions

L'outil Rational Software Architect, en plus de sa capacité à rassembler des informations pour les applications Java grâce à la reconnaissance architecturale, peut aussi identifier et indiquer un ensemble de patterns pré-définis qui peuvent indiquer des points problématiques potentiels dans l'architecture. Ces patterns incluent, entre autres :

  • Le Butterfly
  • Le Breakable
  • Le Hub
  • Le Tangle
Le Butterfly

Un Butterfly est un élément, comme une classe, qui a de nombreuses relations avec d'autres éléments dépendants, qui seraient affectés si le Butterfly changeait. Si les relations sont directes, ces éléments sont appelés Local Butterflies. Rational Software Architect peut aussi tracer l'arborescence des relations qui structurent une application et déterminer si les changements apportés à un élément peuvent affecter les éléments dépendants directs, mais aussi leurs propres éléments dépendants et ainsi de suite dans l'application entière. Un élément avec de nombreuses dépendances indirectes est appelé Global Butterfly. Vous trouverez ci-dessous une illustration de Local Butterfly. Le diagramme indique aussi que les relations ne sont pas forcément des dépendances UML : par exemple, un élément est dépendant d'un autre lorsqu'il le réalise ; un changement dans l'élément de définition affectera l'élément qui le réalise.

Une classe comportant quatre éléments dépendants : deux avec des dépendances d'utilisation, un avec une relation de généralisation et un avec une relation de réalisation

Local Butterfly

Le Breakable

Un Breakable est un élément qui a de nombreuses dépendances, c'est-à-dire qu'il a de nombreuses relations lorsqu'il dépend d'un autre élément. Un changement apporté à un de ces éléments l'affectera. Comme avec les Butterflies, lorsque ces relations sont directes, ces éléments sont appelés des Local Breakables, et des Global Breakables si de nombreuses relations indirectes influencent l'élément. Un Global Breakable est susceptible de changer dans de nombreuses parties de l'application et indique un manque de modularité. Vous trouverez ci-dessous un Local Breakable.

Une classe comportant quatre éléments dépendants : deux avec des relations de dépendance, un avec une relation de généralisation et un avec une relation de réalisation.

Local Breakable

Le Hub

Un Hub est un élément qui combine les caractéristiques d'un Butterfly et d'un Breakable. Il a aussi des formes local et global. La présence de Global Hubs indique un mauvais partitionnement, rendant le logiciel extrêmement sensible aux changements, ces derniers ayant tendance à se répercuter dans l'application toute entière.

Le Tangle

Un Tangle est un grand groupe d'éléments dont les relations sont si imbriquées qu'un changement dans l'une d'elle pourrait affecter toutes les autres. Ces structures entraînent une grande instabilité.

L'architecte logiciel, en utilisant l'outil Rational Software Architect, peut identifier ces points chauds rapidement et travailler avec le concepteur pour les modifier. Pour plus d'informations, voir aussi manuel d'aide la documentation Rational Software Architect.

Calendrier

Les résultats de ces analyses sont valables à chaque jalon de revue, en tant que preuve quantifiable et objective de la qualité de l'architecture et de la conception, ou quand, comme dans Mettre à jour l'organisation du modèle de conception (dans la Tâche : Incorporer les éléments de conception existants) il y a des changements architecturaux importants.

Contrôle architectural

La vision de l'architecte logiciel est consignée dans le Document d'architecture logicielle et le concepteur peut trouver des conseils pratiques dans les principes de conception. Même lorsque cette vision est partagée par tout le personnel, elle est parfois obscurcie par les exigences quotidiennes liées au projet. Avec les délais à respecter, il faut parfois trancher et l'architecte logiciel ne peut pas prendre part à toutes les décisions. La question du contrôle se soulève alors : lorsque le responsable de projet doit définir des limites et les contrôler (Tâche : Contrôler le statut du projet), au même moment, l'architecte logiciel doit effectuer une tâche analogue pour la conception et l'implémentation du logiciel en cours de création.

Le contrôle architectural permet à l'architecte logiciel de créer des règles pour renforcer les contraintes architecturales. Par exemple, l'architecte logiciel peut définir une règle entraînant une alerte sur chaque réalisation d'une interface donnée. La simple expression de cette règle sans l'aide d'un outil impliquerait une revue plus ou moins constante pour repérer les failles. Avec l'automatisation, les règles peuvent être codées de façon à ce que le non respect de l'ensemble des règles puisse être repéré pendant l'analyse de l'architecture. Cela a encore lieu après l'automatisation et un environnement de contrôle avancé encoderait les règles dans le processus de conception et de production de code, leur évitant d'être cassés ; en dépit de cela, le processus de revue manuelle est fortement amélioré.

L'outil Rational Software Architect inclut cette fonction pour les applications Java : l'architecte logiciel peut établir un ensemble de règles, puis exécuter des analyses pour vérifier qu'elles sont respectées. Pour plus d'informations, voir aussi manuel d'aide la documentation Rational Software Architect.