Présentation des mécanismes d'analyse
Un mécanisme d'analyse est un pattern qui représente une solution commune à un problème commun. Il peut s'agir de
patterns de structure, de comportement, ou les deux. Ces mécanismes sont utilisés lors de l'analyse pour en réduire la
complexité et améliorer la cohérence en fournissant aux concepteurs une représentation simplifiée d'un comportement
complexe. Grâce à ces mécanismes, l'effort d'analyse peut être concentré sur la traduction des exigences fonctionnelles
en concepts logiciels sans s'enliser dans la spécification d'un comportement relativement complexe, nécessaire mais pas
essentiel pour supporter la fonctionnalité. Les mécanismes d'analyse résultent souvent de l'instanciation d'un ou
plusieurs patterns d'architecture ou d'analyse.
Les mécanismes d'analyse sont essentiellement utilisés pour représenter les 'conteneurs' d'une technologie complexe
dans les couches intermédiaires et inférieures de l'architecture. En les utilisant comme 'conteneurs' dans
l'architecture, il y a moins de chance que l'effort d'architecture soit entravé par les détails du comportement du
mécanisme. Par exemple, la nécessité d'avoir des durées de vie d'objet qui englobent les cas d'utilisation, la durée de
vie des processus ou l'arrêt et le démarrage du système, définit un besoin de persistance de l'objet. La persistance
est un mécanisme particulièrement complexe et nous ne voulons pas être gênés, pendant l'analyse, par les détails
relatifs à la manière dont nous allons répondre aux exigences de persistance. Cela donne lieu à un mécanisme d'analyse
de "persistance" qui nous permet de parler d'objets persistants et de capturer les exigences que nous aurons sur le
mécanisme de persistance sans se préoccuper de ce que ce mécanisme fera ou de savoir comment il fonctionnera.
De manière générale, mais pas nécessairement, les mécanismes d'analyse n'ont pas de lien avec le domaine concerné mais
sont plutôt des concepts de "science informatique". En conséquence, ils occupent généralement les couches
intermédiaires et inférieures de l'architecture. Ils fournissent des comportements spécifiques à une classe ou un
sous-système relatif au domaine ou correspondent à l'implémentation de la coopération entre les classes et/ou les
sous-systèmes. Ils peuvent être implémentés en tant qu'infrastructure
préfabriquée. Pour n'en retenir que quelques-uns, on peut citer les mécanismes permettant de gérer la persistance,
la communication entre processus, les erreurs ou défaillances, les notifications et les messages.
Cependant, au fur et à masure de la création de davantage de patterns d'analyse dans diverses domaines, leur instanciation complète ou
partielle dans les mécanismes d'analyse va entraîner l'apparition de ces derniers dans les couches supérieures de
l'architecture.
-
Persistance
Pour toutes les classes dont les instances peuvent devenir persistantes, il faut identifier :
-
La granularité : Eventail des tailles des objets à conserver comme persistants
-
Le volume : Nombre d'objets à conserver comme persistants
-
La durée : Combien de temps l'objet doit-il généralement être conservé ?
-
Le mécanisme de récupération : Comment un objet donné est-il uniquement identifié et récupéré ?
-
La fréquence de la mise à jour : Les objets sont-ils plus ou moins constants ; sont-ils sans cesse
mis à jour ?
-
La fiabilité : Les objets doivent-ils survivre à une panne du processus, du processeur ou du système
entier ?
-
-
Communication inter-processus
Pour tous les éléments de modèle qui doivent communiquer avec des composants ou des services fonctionnant sur
d'autres processus ou unités d'exécution, il faut identifier :
-
La latence : à quelle vitesse les processus doivent-ils communiquer entre eux ?
-
La synchronisation : Communication asynchrone
-
La taille du message : une plage de valeurs peut s'avérer plus appropriée qu'un seul nombre.
-
Protocole, contrôle du flux, mémoire tampon, etc.
D'autres mécanismes type comprennent :
-
Routage de messages
-
Contrôle de processus et synchronisation
-
Gestion de transaction
-
Echange d'informations
-
Sécurité
-
Redondance
-
Rapport d'erreurs
-
Conversion de format
Le processus de description des mécanismes d'analyse est le suivant :
-
Collecter tous les mécanismes d'analyse dans une liste
Le même mécanisme d'analyse peut apparaître sous plusieurs noms différents pour différentes réalisations de
cas d'utilisation ou différents concepteurs. Par exemple, stockage, persistance, base de
données et référentiel peuvent tous faire référence à un mécanisme de persistance. De même,
communication inter-processus, passage de messages ou appel distant peuvent tous faire
référence à un mécanisme de communication inter-processus.
-
-
Dessiner une mappe des classes client vers les mécanismes d'analyse
-
Les classes et sous-systèmes identifiés doivent être mappés sur les mécanismes d'analyse identifiés : les
flèches indiquent que la classe utilise le mécanisme. Il n'est pas rare qu'une classe client requière les
services de plusieurs mécanismes.
-
Identifier les caractéristiques des mécanismes d'analyse
Pour différencier un certain nombre de conceptions potentielles, vous devez identifier les caractéristiques clés
utilisées pour qualifier chaque mécanisme d'analyse. Ces caractéristiques sont d'un côté la fonctionnalité et de
l'autre la taille et la performance.
-
-
Modéliser en utilisant les collaborations
Une fois les mécanismes d'analyse identifiés et nommés, ils doivent être modélisés via la collaboration d'une
"société de classes" (voir [BOO98])
dont certaines ne délivrent pas directement la fonctionnalité de l'application mais servent uniquement à la
supporter. Ces "classes de support" se trouvent très souvent dans les couches intermédiaires et inférieures de
l'architecture, offrant ainsi un service de support commun à toutes les classes de niveau application.
Si le mécanisme identifié est assez général, il existe peut-être des patterns à partir desquels le mécanisme peut être instancié, en
reliant les classes existantes et en implémentant de nouvelles classes comme requis par le pattern. Un
mécanisme d'analyse ainsi produit est abstrait et devra donc être affiné via la conception et l'implémentation.
Les mécanismes d'analyse sont documentés dans Produit : Document d'architecture logicielle. Comme l'architecture
logicielle évolue, le Produit: Document d'architecture logicielle comprend une relation (ou
mappage) des mécanismes d'analyse vers les mécanismes de conception, les mécanismes d'implémentation et la logique de
ces choix.
|