Principes et conseils : Reconnaissance Analyse et contrôle d'architecture
Rubriques
Introduction
Dans plusieurs activités du RUP, nous sondons la nécessité d'examiner le modèle de conception émergent, nous évaluons les divers aspects qualité et ensuite, si nécessaire nous modifions le modèle. Il est également essentiel de pouvoir maintenir l'intégrité architecturale d'un système, une fois qu'il est en cours d'implémentation, afin de garantir que les contraintes en termes d'architecture et de conception ne soient enfreintes, et que le système tel qu'il est implémenté continue à s'aligner sur la vision architecturale. Ces points de contrôle majeurs interviennent dans les activités suivantes du RUP : Réviser l'architecture, Réviser la conception
et
Réviser le code.
Un problème différent, néanmoins commun, survient pendant la synthèse architecturale et de conception, dans les activités suivantes : Analyse d'architecture
(voir
Développer
la présentation de l'architecture
et
Atouts disponibles de l'étude) et
Intégrer les éléments de conception existants. On conseille à l'architecte logiciel de rechercher les opportunités de réutiliser les atouts de code et de conception existants, en les intégrant dans le modèle de conception, après une phase de génération de code, si cela est nécessaire. A moins que les atouts réutilisés ne soient pourvus d'une certification de qualité, l'architecte logiciel souhaitera les soumettre au même examen minutieux que pour la conception et le code nouvellement créés.
Dans les deux cas, par voie de conséquence, les besoins de l'architecte logiciel sont identiques pour l'analyse statique :
- Pour utiliser une application codée (ou un de ses fragments), découvrez sa structure symbolique et récupérez la, idéalement dans un modèle de conception, sous la forme du langage UML. Le rétablissement des artefacts navigables de documentation a aussi une valeur significative permettant à l'architecte logiciel de voir comment le code est réellement structuré, lorsque la documentation n'existe pas ou si elle est périmée
- Afin d'analyser un modèle de conception, il faut recueillir les aspects métrologiques en termes de qualité, (telles que le couplage) cités dans l'
Artefact : plan des mesures
et vérifier leur conformité avec l'
Artefact: Document d'architecture logicielle
et avec les
Principes et conseils de conception
- Pour prendre connaissance des modifications significatives d'architecture ou de conception et permettre une intervention en termes de corrections, si cela est nécessaire. Le caractère significatif d'une modification est basé sur des critères définis par l'architecte logiciel
En théorie, ces besoins pourraient être satisfaits par une analyse ; en pratique, pour des systèmes plus grands et plus complexes, un certain type d'aide automatisée est essentiel.
Les chapitres suivants décrivent ces sujets de manière élaborée et fournissent des exemples de support d'outils.
Reconnaissance et rétablissement de l'architecture
Eléments de base
Dans le développement de Greenfield, l'architecture logicielle émerge des exigences, du contexte en termes de domaine et de conventions (incluant les formes et les mécanismes); l'artefact
Spécifications supplémentaires
joue un rôle majeur dans la définition de l'architecture. Ce processus de formation de l'architecture logicielle est parfois désigné par le terme "reconnaissance", du fait que la définition de correspondance des exigences par rapport à l'architecture est rarement directe et mécanique.
Ici, nous utilisons néanmoins le terme reconnaissance dans un sens différent, pour décrire le processus qui consiste à aider l'architecte logiciel à comprendre une application existante ou un fragment d'application codé. Le rétablissement est une démarche plus ambitieuse : par l'intermédiaire du rétablissement, l'architecte logiciel ne cherche pas uniquement à comprendre une application, mais il tente également d'en extraire un modèle, idéalement de manière compatible avec le modèle de conception. On peut ensuite fusionner ces modèles et par cette phase de transformation, générer une nouvelle
application, éventuellement pour une
plate-forme différente.
Reconnaissance
Au niveau des activités :
l'Analyse d'architecture
(voir
Développer une présentation de l'architecture
et les
Atouts disponibles de l'étude) et
Intégrer les éléments de conception existants. L'architecte logiciel recherche les possibilités de réutiliser la conception et les ressources du code existant. Par exemple, une organisation peut comporter plusieurs Architectures de référence
dans sa base d'actifs ; idéalement, ceux-ci sont complets et disposent d'une documentation et de modèles à jour. Cependant, on trouve souvent plus que du code source et s'il existe une documentation d'architecture, ce n'est pas la documentation en cours.
Souvent, l'architecte logiciel ne peut pas traiter ce code comme une boîte noire (même lorsque les interfaces sont clairement définies), mais il doit impérativement en comprendre la structure.
Ce processus bénéficie d'un support important, par la capacité à créer automatiquement des représentations du code qui peuvent être explorées. L'architecte logiciel peut ensuite "reconnaître" visuellement les formes et anti formes du code. L'outil appelé Rational Software Architect fournit un exemple de ce type d'aide, où la capacité à reconnaître l'architecture remplit automatiquement les diagrammes du domaine, tels que la structure des packages, les éléments internes aux classes, les arbres d'héritage et les collaborations des applications Java.
Pour plus d'informations, voir le chapitre
Documentation du Rational Software Architect.
Rétablissement et transformation
Quand les atouts réutilisables sont complets, et qu'ils disposent de modèles, il est possible d'associer ces modèles aux modèles spécifiques au projet et de procéder ensuite à l'implémentation de la plate-forme, en utilisant des techniques de transformation. Lorsque seul le code existe, il est néanmoins possible de le réutiliser, même avec une approche basée sur la transformation, en intégrant le code produit à partir de la transformation au code existant.
L'architecte logiciel dispose d'un pouvoir et d'une souplesse plus importants, en utilisant le rétablissement de l'architecture : la capacité de rétablissement générera un modèle d'application, riche sur le plan sémantique qui pourra être utilisé pour la génération du code aussi bien que pour la navigation.
En pratique, le code issu de la génération de code qui retrouve une représentation simple est souvent la solution ; la restitution du modèle au même niveau que celui d'un modèle de conception indépendant de la plate-forme
est en général difficile à automatiser dans son intégralité.
Il s'agit essentiellement d'une transformation de
PSM
vers
PIM
(voir le chapitre
Concepts: Développement contrôlé par le modèle (MDD)
et Architecture contrôlée par le modèle® (MDA®)); le (fragment) PIM récupéré est ensuite combiné au modèle de conception (qui est lui-même un PIM) utilisant une fusion de modèles (voir le chapitre [OMG03]) type de transformation.
Analyse des Architectures
Les modèles navigables permettent à l'architecte logiciel de vérifier la qualité de l'architecture par un contrôle. Cela peut cependant s'avérer pénible et long. Le contrôle de conformité des normes et règles ainsi que le regroupement des éléments métrologiques sont susceptibles de générer des erreurs. L'architecte logiciel doit favoriser autant que possible l'automatisation de ce processus et de ce fait, investir plus de temps à la recherche et à l'application des solutions ;
l'automatisation permet à l'architecte logiciel d'expérimenter cette opération, de poser la question "que se passe t'il si"
et de vérifier rapidement le résultat.
Que peut-on automatiser ?
L'analyse d'architecture automatisée peut :
- Rechercher des patterns et anti patterns (structures pathologiques) de l'architecture
- Réaliser les mesures de diverses structures et rendre compte des
éléments métrologiques
- Vérifier l'état de conformité par rapport aux contraintes définies par l'architecte logiciel (voir contrôle d'architecture)
L'utilisation de
formes
est dictée par les normes du projet et de l'organisation ; le caractère rationnel de leur utilisation est décrit dans le document d'architecture du logiciel (si elles ont une signification architecturale) ou dans les principes et conseils de conception. Par l'analyse automatisée, l'architecte logiciel peut rapidement vérifier l'utilisation des formes et tester le contenu du document d'architecture du logiciel et des principes et conseils de conception. Les anti formes sont des structures de conception altérées sur le plan architectural qui affaiblissent l'architecture, en la rendant par exemple moins robuste, plus complexe et plus difficile à maintenir.
Les mesures à réaliser sont évoquées dans l'artefact : Plan de mesures (certains éléments métrologiques peuvent être trouvés dans la section
Principes et conseils : métrologie). Le plan de mesures décrit également la manière dont les éléments métrologiques sont utilisés, par exemple, s'il est opportun d'utiliser des valeurs supérieures ou inférieures ou s'il existe une tendance à respecter. Il est également utile de s'appuyer sur l'analyse métrologique pour identifier les zones sensibles, zones où les changements rapporteraient une amélioration significative à l'ensemble des éléments métrologiques. Cela n'a rien d'étonnant qu'ils soient souvent associés aux facteurs d'altération de la structure. L'architecte logiciel dispose ensuite d'une base objective d'amélioration qui lui permet d'effectuer des modifications ou de déléguer des actions de suivi qui seront testées, une fois terminées.
Quelle est la cible de l'analyse ?
La cible de l'analyse peut varier tout au long du cycle de vie, selon l'approche de développement choisie. Quand un projet utilise une approche de transformation (de génération), la cible sera normalement le modèle de conception, en supposant que l'application générée soit toujours synchronisée avec la conception. Lorsque l'on créé et l'on maintient séparément un
Artefact : modèle d'implémentation, ou que le code est réutilisé, il faut opérer un décalage sur le code, pour s'assurer qu'il retiendra l'intégrité architecturale telle qu'elle est décrite dans le document d'architecture du logiciel et dans les principes et conseils de conception.
Ce type d'analyse (ou modèle d'implémentation) peut ne pas récupérer un modèle explicite de conception à partir du code, à des fins d'analyse ; il est néanmoins concerné par des questions d'architecture et de conception (manifestes dans le code) et non par des normes d'encodage.
Un exemple de ces concepts et capacités
En plus de sa capacité à récupérer la documentation des applications Java, et par la reconnaissance de l'architecture, l'outil appelé Rational Software Architect peut identifier et se positionner par rapport à un ensemble de formes prédéfinies, susceptibles d'indiquer des zones potentiellement sensibles au niveau de l'architecture. Ces formes incluent entre autres les éléments suivants :
- Le Butterfly
- Le Breakable
- Le Hub
- Le Tangle
Le Butterfly
Un butterfly est un élément, tel qu'une classe, qui a beaucoup de relations avec d'autres éléments dépendants, sur lesquels se répercutera une modification du butterfly. Si les relations sont directes, ces éléments sont des butterflies locaux. Le Rational Software Architect peut également suivre la trace des relations, alors qu'elles s'exécutent en cascade dans une application et déterminer si les modifications d'un élément pourraient impacter non seulement leurs unités dépendantes directes, mais leurs dépendances à leur tour, et ainsi de suite à travers l'application entière. Ce type d'élément avec ses multiples dépendances indirectes s'appelle un butterfly global. Le butterfly local est illustré ci-dessous. Le diagramme montre également que les relations ne sont pas exclusivement des dépendances UML ; par exemple, un élément est dépendant d'un autre élément lorsqu'il réalise cet état ; une modification de l'élément d'indication impactera l'élément qui perçoit cette modification.
Un butterfly local
Le Breakable
Un breakable est un élément qui a beaucoup de dépendances, c'est à dire qu'il a beaucoup de relations de dépendance par rapport à un autre élément. Une modification effectuée sur n'importe lequel de ces éléments affectera le breakable. Comme pour les butterflies, si les relations sont des relations directes, ces éléments s'appellent des breakables locaux, et des breakables globaux si un grand nombre de relations indirectes impactent l'élément. Un breakable global est vulnérable aux changements à plusieurs niveaux de l'application et il indique un manque de modularité. L'illustration ci-dessous décrit un breakable local.
Un breakable local
Le Hub
Un hub est un élément qui conjugue les caractéristiques d'un butterfly
et un breakable. Il prend également des formes locales et globales. La présence des hubs globaux indique un faible partitionnement, ce qui a pour effet de rendre le logiciel extrêmement sensible aux changements ; les changements tendent à onduler dans l'application entière.
Le Tangle
Un tangle est un groupe important d'éléments dont les relations sont si compliquées qu'un changement de l'une d'elles pourrait se répercuter sur l'ensemble. De telles structures
sont la source d'une instabilité majeure.
Grâce à l'outil Rational Software Architect, l'architecte logiciel peut rapidement reconnaître ces zones sensibles et collaborer avec le concepteur pour les rectifier.
Pour plus d'informations, voir la
documentation du Rational Software Architect.
Synchronisation
Les résultats de ces analyses sont précieux sur n'importe quel jalon de revue, en tant que preuve objective et quantifiable de la qualité d'architecture et de conception, ou comme dans le chapitre
Mettre à jour l'organisation du modèle de conception
(dans l'activité : intégrer les éléments de conception existants) quand des modifications architecturales significatives sont effectuées.
Contrôle d'architecture
La vision de l'architecte logiciel est comprise dans le document d'architecture du logiciel et le chapitre Principes et conseils de conception indique au concepteur un certain nombre de conseils pratiques.
Même lorsque cette vision est partagée par tout le personnel, elle est parfois obscurcie par les exigences quotidiennes liées au projet. Compte tenu des échéances à respecter, la situation peut être difficile et l'architecte logiciel ne participe habituellement pas à chaque décision.
Donc, la question du contrôle se pose : quand le responsable de projets doit définir des seuils et des limites qu'il surveillera (voir le chapitre Activité : surveiller l'état d'avancement du projet), l'architecte logiciel accomplit une tâche analogue concernant l'implémentation et la conception du logiciel émergent.
Le contrôle d'architecture donne la capacité à l'architecte logiciel de créer des règles permettant d'appliquer les contraintes architecturales. L'architecte logiciel peut par exemple définir une règle qui émettrait un avertissement, à chaque réalisation d'une interface donnée. La simple expression de cette règle sans le support d'outils nécessiterait une révision plus ou moins constante, afin d'intercepter toute violation des règles. Grâce au processus d'automatisation, les règles peuvent être encodées, et ainsi intercepter les violations des règles, durant l'analyse d'architecture. Cela peut encore se produire et un environnement de contrôle avancé intègre l'encodage des règles dans le processus de production des codes et de conception, évitant ainsi qu'ils soient détruits dés la première intrusion ; même sous cette forme, cela améliore considérablement le processus manuel de révision.
L'outil Rational Software Architect intègre ce type de fonction pour les applications Java :
l'architecte logiciel peut définir des règles et effectuer des analyses afin de vérifier leur conformité.
Pour plus d'informations, voir le chapitre
Documentation du Rational Software Architect.
|