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 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.
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.
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 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
la documentation Rational Software Architect.
|