Concepts : Mécanismes
d'analyse
Rubriques
Introduction aux mécanismes
d'analyse
Un mécanisme d'analyse représente un pattern constituant une solution commune
à un problème commun. Les mécanismes d'analyse peuvent présenter des
patterns de structure, de comportement ou les deux. Ils sont utilisés au
cours de l'analyse pour en réduire la complexité et améliorer la
cohérence en fournissant aux concepteurs une représentation abrégée d'un
comportement complexe. Les mécanismes permettent à l'effort d'analyse de se
concentrer sur la transposition des exigences fonctionnelles en concepts
logiciels sans s'enliser dans la spécification du comportement relativement
complexe, mais non significatif, nécessaire à la prise en charge de la
fonctionnalité. Les mécanismes d'analyse émanent souvent de l'instanciation d'un ou
de plusieurs
schémas d'architecture
ou schémas d'analyse.
Les mécanismes d'analyse sont principalement utilisés pour représenter des
"paramètres fictifs" pour une technologie complexe dans les couches intermédiaires
et inférieures de l'architecture. En utilisant les mécanismes comme paramètres fictifs dans
l'architecture, l'effort architectural risque moins d'être
perturbé par les détails du comportement des mécanismes.
Par exemple, le besoin d'avoir des durées de vie d'objet égales à celle des cas
d'utilisation, des durées de vie des processus ou de l'arrêt et du démarrage
système, définit le besoin de persistance des objets.
La persistance est un mécanisme particulièrement complexe et au cours de
l'analyse, nous ne souhaitons pas être perturbé par les détails relatifs au
moyen d'y aboutir. Ceci donne lieu à un mécanisme d'analyse de persistance qui
permet de parler d'objets persistants et de capturer les exigences envers le
mécanisme de persistance sans s'inquiéter de ce qu'il fait exactement et comment
il y parvient.
Les mécanismes d'analyse sont généralement, mais pas nécessairement, non
associés au domaine du problème. En revanche, ce sont des concepts
"informatiques" et de ce fait 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 lié au domaine, ou
correspondent à l'implémentation de coopérations entre classes et/ou
sous-systèmes. Ils peuvent être implémentés en tant
qu'infrastructure,
comme par exemple des mécanismes permettant de traiter la persistance, la
communication entre processus, le traitement des erreurs ou des incidents, la
notification, la messagerie, etc.
Cependant, au fur et à mesure de la définition de
schémas d'analyse
dans divers domaines, leur instanciation partielle ou complète
entraîne l'apparition de ces mécanismes dans les
couches supérieures de l'architecture.
- Persistance
Pour toutes les classes dont les instances peuvent devenir persistantes,
nous devons identifier les éléments suivants :
- Granularité : gamme de taille des objets à maintenir persistants.
- Volume : nombre d'objets à maintenir persistants.
- Durée : période durant laquelle l'objet doit être typiquement conservé.
- Mécanisme d'extraction : mode d'identification unique et d'extraction d'un objet donné.
- Fréquence de mise à jour : les objets sont-ils plus ou moins constants ? Sont-ils mis à jour en permanence ?
- Fiabilité : les objets doivent-ils survivre à une panne du processus, du processeur ou de tout le système ?
- Communication entre processus
Pour tous les éléments de modèle devant communiquer avec des composants
ou des services s'exécutant dans d'autres processus ou unités d'exécution, nous
devons identifier les éléments suivants :
- Latence : avec quelle rapidité les processus doivent-ils communiquer entre eux ?
- Capacité de synchronisation : communication asynchrone.
- Taille de message : une fourchette peut être plus appropriée qu'un seul nombre.
- Protocole, contrôle de flux, mise en mémoire cache, etc.
Autres mécanismes typiques :
- Acheminement des messages
- Contrôle des processus et synchronisation
- Gestion des transactions
- Echange d'informations
- Sécurité
- Redondance
- Rapport d'erreurs
- Conversion de format
Le processus de description des mécanismes d'analyse est le suivant :
- Collecte de tous les mécanismes d'analyse dans une liste
Le même mécanisme d'analyse peut apparaître sous différents noms dans
différentes réalisations de cas d'utilisation chez différents concepteurs.
Par exemple, stockage, persistance, base de données et
référentiel peuvent tous se référer à un mécanisme de persistance.
Ou bien encore, les communications inter-processus, les
transmissions de messages ou les appels distants peuvent tous
se référer à un mécanisme de communication entre processus.
- Etablissement d'une correspondance entre les classes client et les mécanismes d'analyse

Les classes et les sous-systèmes identifiés doivent
être mappés aux 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
nécessite les services de plusieurs mécanismes.
- Identification des caractéristiques des mécanismes d'analyse
Afin de faire un choix parmi une gamme de conceptions potentielles, identifiez
les caractéristiques clés utilisées pour qualifier chaque mécanisme d'analyse.
Ces caractéristiques sont en partie fonctionnelles et en partie relatives à
la taille et aux performances.
-
Modélisation à l'aide de collaborations
Une fois les mécanismes d'analyse identifiés et désignés, ceux-ci
doivent être modélisés via la collaboration d'une "société de classes" (voir
[BOO98]), dont certaines ne délivrent
pas directement une fonctionnalité d'application, mais existent uniquement pour
la prendre en charge. Très souvent, ces "classes de support" se trouvent dans
les couches intermédiaires ou inférieures d'une architecture en couches,
fournissant ainsi un service de support commun à toutes les classes de niveau
application.
Si le mécanisme identifié est suffisamment courant, il se peut que des
patterns existent à partir
desquels le mécanisme peut être instancié, en liant des classes
existantes et en en implémentant de nouvelles comme indiqué par le pattern.
Un mécanisme d'analyse ainsi produit est abstrait et requiert des précisions
supplémentaires via la conception et l'implémentation.
Des mécanismes d'analyse sont documentés dans la rubrique
Artefact : Document d'architecture
logicielle. A mesure que l'architecture logicielle évolue, le document
Artefact : Document d'architecture
logicielle inclut une relation (ou mappage) des mécanismes d'analyse avec
les mécanismes de conception, ceux d'implémentation et la justification
associée de ces choix.
| |
|