Rubriques

Introduction aux mécanismes d'analyse Début de page

Un mécanisme d'analyse est un pattern qui constitue une solution standard à un problème courant. Les mécanismes d'analyse peuvent inclure des patterns de structure, des patterns de comportement ou bien les deux. Ils permettent de simplifier l'analyse et d'obtenir davantage de cohérence en offrant aux concepteurs une représentation condensée de comportements complexes. Ces mécanismes permettent de concentrer l'analyse sur la retranscription des exigences fonctionnelles sous forme de concepts logiciels, sans pour autant piétiner dans la spécification d'un comportement relativement complexe qui est nécessaire à la prise en charge des fonctionnalités mais n'en est pas le point central. Les mécanismes d'analyse résultent en général de l'instanciation d'un ou plusieurs schémas d'architecture ou d'analyse. 

Les mécanismes d'analyse permettent essentiellement de représenter les "paramètres fictifs" des technologies complexes dans les couches intermédiaires et inférieures de l'architecture. Grâce à l'emploi de ces mécanismes comme "paramètres fictifs" dans l'architecture, la conception de l'architecture est moins susceptible d'être détournée par les détails du comportement du mécanisme. Par exemple, lorsque des cas d'utilisation étendus sur toute la durée de vie des objets, des durées de processus, ou des procédures d'arrêt et de lancement du système sont nécessaires, cela implique le besoin d'objets persistants. La persistance est un mécanisme particulièrement complexe. Au cours de l'analyse, il n'est pas utile de troubler l'utilisateur avec les détails relatifs à la façon dont il va pouvoir obtenir la persistance ; c'est pourquoi, le mécanisme d'analyse "de persistance" permet de parler d'objets persistants et d'identifier les exigences en termes de mécanisme de persistance sans que l'utilisateur n'ait à se soucier de ce que le mécanisme de persistance effectue réellement ni de la façon dont il fonctionne.

En règle générale, les mécanismes d'analyse n'ont aucun rapport avec le domaine du problème (mais pas nécessairement), ce sont plutôt des "concepts" informatiques. Aussi, ils occupent généralement les couches intermédiaires et inférieures de l'architecture. Ils transmettent à une classe ou à un sous-système lié au domaine des comportements spécifiques, ou correspondent à la mise en oeuvre d'une coopération entre les classes et/ou les sous-systèmes. En outre, ces mécanismes peuvent être implémentés en tant que canevas, c'est le cas notamment pour les mécanismes de gestion de la persistance, la communication entre les processus, le traitement des erreurs, les notifications ou encore la messagerie. 

Cependant, au fur et à mesure que les schémas d'analyse sont établis dans différents domaines, l'instanciation complète ou partielle de ces mécanismes d'analyse déplace les mécanismes vers les couches supérieures de l'architecture.

Exemples de mécanismes d'analyse Début de page

  • Persistance

    Pour toute classe dont les instances doivent être persistantes, il faut identifier les éléments suivants :
    • Granularité : fourchette de dimensions des objets dont il faut maintenir la persistance.
    • Volume : nombre d'objets dont il faut maintenir la persistance.
    • Durée : durée pendant laquelle la persistance de l'objet doit être maintenue.
    • Mécanisme de récupération : façon dont l'objet en question est identifié et récupéré.
    • Fréquence de mise à jour : évaluation de la constance des objets ; ceux-ci sont-ils mis à jour en permanence ?
    • Fiabilité : vérification de la survie des objets en cas d'échec de processus, de processeur ou du système.

  • Communication entre les processus

    Pour tout élément de modèle qui doit communiquer avec des composants ou des services s'exécutant au sein d'un autre processus ou d'une autre unité d'exécution, il faut identifier les paramètres suivants :
    • Temps d'attente : vitesse à laquelle les processus doivent communiquer entre eux.
    • Synchronisation : communication asynchrone.
    • Taille des messages : une fourchette est certainement plus appropriée qu'une valeur fixe.
    • Protocole, contrôle du débit, mise en mémoire tampon, etc.

Autres mécanismes courants :

  • Routage des messages
  • Contrôle du processus et synchronisation
  • Gestion des transactions
  • Echange des informations
  • Sécurité
  • Redondance
  • Rapports d'erreurs
  • Conversion de formats

Description des mécanismes d'analyse Début de page

Pour décrire les mécanismes d'analyse, procédez comme suit :

  1. Dressez la liste exhaustive des mécanismes d'analyse.

    Il est probable qu'un même mécanisme d'analyse apparaisse sous des noms différents en fonction des réalisations de cas d'utilisation ou des concepteurs. Par exemple, les noms stockage, persistance, base de données, et référentiel peuvent tous renvoyer à un mécanisme de persistance. De même, communication entre les processus, transmission de messages, ou appel à distance peuvent faire référence à un mécanisme de communication entre les processus.

  2. Représentez sous forme de plan les relations entre les classes client et les mécanismes d'analyse.
  3. Diagramme illustrant les relations entre les classes et les mécanismes d'analyse

    Les classes et les sous-systèmes identifiés doivent être mis en correspondance avec les mécanismes d'analyse : les flèches indiquent que la classe en question fait appel au mécanisme. Il n'est pas rare qu'une classe client requière les services de plusieurs mécanismes.

  4. Identifiez les caractéristiques des mécanismes d'analyse.

    Pour pouvoir distinguer les différents mécanismes d'analyse au sein d'un ensemble de conceptions potentielles, vous devez identifier les caractéristiques de chacun. Ces caractéristiques concernent d'une part les fonctionnalités et d'autre part la taille et les performances.

  5. Créez des modèles par le biais de collaborations.

    Une fois les mécanismes d'analyse identifiés et nommés, l'étape finale consiste à les modéliser via la collaboration d'une "société de classes" (voir [BOO98]). Certaines sociétés de classes ne fournissent pas les fonctionnalités de l'application proprement dites mais permettent d'assurer leur maintenance. Bien souvent, ces "classes de support" se situent au niveau des couches intermédiaires ou inférieures d'une architecture en couches, offrant ainsi un service de maintenance commun à toutes les classes quel que soit leur niveau dans l'application.

    Si le mécanisme identifié n'est pas trop spécifique, il existe peut-être des patterns à partir desquels le mécanisme peut-être instancié ; pour cela, il suffit de lier les classes existantes et d'en mettre en oeuvre de nouvelles, conformément aux exigences du pattern. Le mécanisme d'analyse ainsi produit est abstrait et doit être affiné au cours des phases de conception et d'implémentation.

Les mécanismes d'analyse sont documentés dans l'artefact Document d'architecture logicielle. Au fur et à mesure que l'architecture du logiciel évolue, l'artefact Document d'architecture logicielle établit des relations (mappage) entre les mécanismes d'analyse, les mécanismes de conception et les mécanismes d'implémentation, tout en justifiant chacune de ces associations.

Application des mécanismes d'analyse Début de page

Patterns et transformations Début de page

Arrière-planDébut de page

"Solution type à un problème récurrent qui s'est avérée efficace dans un contexte donné" (définition donnée par le glossaire), le concept de pattern est assez général : l'application (instanciation) d'un pattern tel que défini ici, peut nécessiter de nombreuses modifications au niveau du modèle, en fonction de la spécificité et de l'envergure du problème à résoudre. Dès lors, l'application des patterns, et donc l'instanciation des mécanismes, sont réalisées par le biais d'une transformation de modèle. Par exemple, dans Sécurité (l'un des mécanismes décrits précédemment), tout pattern constituant la base d'un mécanisme de sécurité est susceptible d'être nomade et doit être modifié différemment selon qu'il s'agisse d'un type d'élément modèle ou d'un type d'élément ordinaire. Un profil UML peut également inclure la définition d'un pattern de sécurité , qui constitue un moyen standard d'identifier les stéréotypes, les valeurs référencées et les contraintes, et qui permet de déterminer et d'imposer une technologie, une discipline, un domaine spécifiques ainsi que d'autres éléments relatifs à la modélisation. Ce concept s'apparente, par essence, à une plateforme (voir Concepts : Développement dirigé par modèle (Model-Driven Developement - MDD) et architecture dirigée par modèle (Model-Driven Architecture - MDA®) ; l'idée d'une ou plusieurs transformations mettant en oeuvre des "patterns généraux" est donc applicable dans ce cas.

La relation entre un pattern (général) et une transformation peut être illustrée comme suit :

Diagramme représentant la transformation en tant qu'élément dérivé d'un pattern général (qui peut donc être utilisé dans le cadre de l'implémentation)

Cependant, l'expérience démontre qu'un pattern renvoie à quelque chose de plus limité. Il s'agit d'une sorte de transformation (appliquée à un modèle source, laquelle application génère un modèle modifié). Cependant, cette modification peut être élaborée et est appliquée localement (en une ou plusieurs étapes). Les modèles source et cible restent globalement au même niveau d'abstraction et peuvent même parfois être considérés comme un seul et même modèle. Par exemple, vous pouvez appliquer à un modèle de conception un modèle sous forme de collaboration paramétrée, et, à condition que le modèle ne soit pas spécifique à la technologie employée, toujours considérer le résultat comme un modèle de conception. Nous retrouvons ce concept dans RUP, lorsque nous évoquons les schémas d'analyse, schémas de conception et schémas d'implémentation (langues). Ici, la relation entre le schéma et la transformation (maintenant représentée sous forme de classe abstraite) peut être visualisée comme suit :

Diagramme illustrant la notion de pattern, telle que nous l'avons résumée, c'est-à-dire une sous-classe de la transformation d'une classe abstraite.

Cette utilisation plus spécifique des patterns est détaillée plus loin dans cette rubrique.

En tant qu'architectes logiciels, notre objectif est de continuer à travailler à un niveau d'abstraction élevé et, après avoir identifié et caractérisé les mécanismes d'analyse requis et les patterns (généraux ou spécifiques) sur lesquels ils reposent, nous voulons les implémenter via une transformation automatique. Enfin, à mesure que nous progressons dans le processus d'analyse et de conception, nous espérons automatiser le plus possible la transformation du modèle avant de passer à la génération du code à partir de nos modèles UML, et ce toujours à un niveau d'abstraction élevé, et ne pas nous limiter à un simple reflet de ce code.

Approche de la transformation Début de page

Dans la rubrique Concepts : Développement dirigé par modèle (Model-Driven Development - MDD) et architecture dirigée par modèle (Model Driven Architecture - MDA®), nous abordons différentes approches relatives à la transformation (Voir Modalités d'exécution d'une transformation). Pour donner un exemple concret, Rational Software Architect prend en charge une approche fondée sur la combinaison d'un mappage de types (permettant de déterminer, par exemple, dans quelle mesure les classes du modèle source, leurs attributs, opérations et relations influent sur les éléments cible) et d'un marquage du modèle source, tous deux définis par des profils.

Cette approche admet l'idée selon laquelle le modèle source ne comprend généralement pas assez d'informations pour diriger complètement la transformation via un mappage de types. Software Architect peut ajouter des marques au modèle source, notamment des stéréotypes définis dans un profil, en vue de compléter la définition de la transformation. Ces marques, qui constituent les concepts de la plateforme cible, ne font pas partie du modèle source mais se superposent à celui-ci. Les règles qui régissent la transformation dépendent de la sélection de la plateforme cible, par exemple, d'un profil associé, et du mappage entre les types employés par la source et ceux utilisés par la cible.

Une fois les règles de transformation établies et la source marquée, la transformation proprement dite peut débuter. Rational Software Architect va même plus loin et autorise la définition de paramètres de transformations. Vous pouvez par exemple, spécifier les éléments d'information inclus dans le profil ou les marques qui ne doivent pas être pris en compte. La modification des modèles de façon systématique présente un autre avantage : le système génère et enregistre une copie de la transformation.Ceci permet d'assurer le suivi des informations entre le modèle source et le modèle cible.

Par exemple, Rational Software Architect matérialise le concept général de transformation à travers les transforms et les patterns. Les définitions ci-dessous sont celles sur lesquelles s'appuie Rational Software Architect.

TransformDébut de page

Un transform est "une transformation optimisée en vue d'un traitement par lot, principalement à travers des métamodèles, des modèles et des niveaux d'abstraction.". L'application d'un transform génère dans la plupart des cas un modèle clairement distinct, par exemple, un modèle de code textuel issu d'un modèle UML. Il s'agit d'un passage significatif qui inclut, en outre, des changements au niveau de la notation.

PatternDébut de page

Un pattern est "une transformation optimisée pour une élaboration interactive, par morceaux, principalement dans un seul métamodèle, de niveau d'abstraction équivalent, et bien souvent, au sein du même modèle.". D'après cette définition, le résultat de l'application d'un pattern sur un modèle UML reste un modèle UML (bien qu'un peu plus élaboré) et est identifié au même niveau d'abstraction.

La relation entre la transformation, le pattern et le transform permet d'affiner notre diagramme comme suit :

Diagramme incluant un transform comme sous-classe de la transformation.

Cette approche plus rigoureuse a également pour conséquence de faire des profils et des transformations qui en découlent des entités importantes. L'objectif de l'architecte logiciel est d'avoir la possibilité de réutiliser le travail préparatoire effectué en vue des transformations et d'en tirer ainsi le meilleur profit. Il est recommandé de créer des bibliothèques de transformations de sorte que les transformations uniques restent exceptionnelles. Ce type de bibliothèque doit permettre d'effectuer des recherches et d'être parcourues en fonction des propriétés associées aux transformations, afin de donner à l'architecte logiciella possibilité, par exemple, de mettre aisément ces bibliothèques en relation avec les caractéristiques des mécanismes d'analyse requis.

Pour plus d'informations sur la performance des transformations via Rational Software Architect, voir les tutoriels et exemples Rational Software Architect suivants :

  • Tutoriel - Application du pattern XYZ
  • Tutoriel - Extension de patterns
  • Exemple - Modèle d'application de pattern
  • Exemple - Pattern
  • Exemple - Pattern à étendre
  • Tutoriel - Conception : Transformation d'un modèle en code
  • Tutoriel - Conception : Transformation d'un modèle en modèle
  • Exemple - Application de transforms
  • Exemple - Construction de votre premier transform
  • Exemple - Elaboration d'un modèle en vue de la modélisation de transforms
  • Exemple - Création d'un transform générateur de texte
  • Exemple - Déploiement d'un transform pour d'autres utilisateurs Rational Software Architect

 

RUP (Rational Unified Process)   2003.06.15