Rubriques

Introduction aux mécanismes d'analyseHaut de la page

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.

Exemples de mécanismes d'analyse Haut de la page

  • 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

Description des mécanismes d'analyseHaut de la page

Le processus de description des mécanismes d'analyse est le suivant :

  1. 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.

  2. Etablissement d'une correspondance entre les classes client et les mécanismes d'analyse
  3. Diagramme décrit dans le contenu.

    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.

  4. 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.

  5. 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.



RUP (Rational Unified Process)   2003.06.15