Activité :
|
Objet | |
Rôle : Architecte logiciel | |
Fréquence : Une fois par itération | |
Etapes | |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : | |
Plus d'informations : |
Détails sur l'enchaînement des activités : |
Les mécanismes d'analyse fournissent des ensembles conceptuels de services utilisés par les classes d'analyse. Ils offrent une solution pratique aux comportements complexes qui risquent de poser problème, mais qui ne sont pas compris dans l'effort d'analyse. Leur principal objectif consiste à permettre l'enregistrement des exigences des services du système sans se préoccuper du fournisseur de service lui-même.
Nous allons commencer à affiner les informations rassemblées à l'aide des mécanismes d'analyse. Pour cela, effectuez les étapes suivantes :
Identifiez les clients de chaque mécanisme d'analyse. Parcourez tous les clients d'un mécanisme d'analyse spécifique, en recherchant les caractéristiques requises. Par exemple, certaines classes d'analyse peuvent utiliser un mécanisme de persistance, mais leurs exigences peuvent varier : une classe dotée d'un millier d'instances persistantes a des exigences totalement différentes de celles d'une classe qui en compte quatre millions. De la même façon, une classe dont les instances doivent fournir des réponses en sous-millisecondes à des données d'instance requiert une approche différente de celle d'une classe dans laquelle l'accès aux données d'instance s'effectue uniquement via des requêtes ad-hoc et des applications de traitement par lots utilisées pour la génération de rapports.
Identifiez les profils de chaque mécanisme d'analyse. Ces profils peuvent varier et offrir des niveaux de performances très divers, ainsi qu'un encombrement, une sécurité et un coût économique variables. Chaque mécanisme d'analyse est différent ; par conséquent, des caractéristiques différentes s'appliquent à chacun d'entre eux. Un grand nombre de mécanismes requiert une estimation du nombre d'instances à gérer, ainsi que la taille escomptée exprimée en nombre d'octets. Le déplacement de grandes quantités de données via un système donne lieu à d'importantes questions liées aux performances, qu'il faut traiter.
Regroupez les clients en fonction de l'utilisation qu'ils font des profils. Constituez des groupes de clients qui semblent tous avoir besoin d'un mécanisme d'analyse doté d'un profil similaire ; identifiez un mécanisme de conception prenant comme base ce besoin. Grâce à ces regroupements, vous disposez d'une première découpe des mécanismes de conception. Par exemple, le mécanisme d'analyse de"communication interprocessus" peut être mappé au mécanisme de conception de "courtier en demandes d'objets". Si vous utilisez des profils différents, des mécanismes de conception différents émergeront du même mécanisme d'analyse. Le simple mécanisme de persistance utilisé pour l'analyse peut donner lieu à un certain nombre de mécanismes de persistance utilisés pour la conception : persistance mémoire, fichiers, base de données, distribuée, etc. Les mécanismes de conception représentent des mécanismes d'analyse affinés sur la base des différents profils.
Dressez l'inventaire (du bas vers le haut) des mécanismes d'implémentation (voir les concepts de mécanismes de conception et d'implémentation) dont vous disposez :
Déterminez si les mécanismes d'implémentation existants peuvent être utilisés et si de nouveaux mécanismes d'implémentation doivent être élaborés.
Les mécanismes de conception fournissent une abstraction des mécanismes d'implémentation, réduisant ainsi l'écart entre les mécanismes d'analyse et les mécanismes d'implémentation. L'utilisation de mécanismes architecturaux abstraits pendant la conception permet de déterminer le mode de fourniture des mécanismes architecturaux sans aggraver le problème relatif aux détails d'un mécanisme spécifique. Elle permet également de remplacer potentiellement un mécanisme d'implémentation spécifique par un autre sans affecter la conception.
Déterminez les plages de caractéristiques. Examinez les caractéristiques identifiées pour les mécanismes de conception afin de déterminer les plages de valeurs raisonnables, économiques ou réalisables, à utiliser dans le mécanisme d'implémentation potentiel.
Tenez compte du coût d'acquisition des composants achetés. Pour les mécanismes d'implémentation potentiels, tenez compte du coût d'acquisition ou d'achat de licence, de la maturité du produit, des relations avec le fournisseur, du support fourni, etc, en plus des critères purement techniques.
Recherchez les composants appropriés ou construisez-les. Il est fréquent qu'aucun mécanisme d'implémentation ne soit apparemment adapté à certains mécanismes de conception ; cela entraîne une recherche du produit approprié ou l'identification du besoin de développement interne. Il arrive également que certains mécanismes d'implémentation ne soient pas utilisés du tout.
Le choix des mécanismes d'implémentation prend comme base les caractéristiques techniques et non techniques, telles que le coût. Certains choix peuvent être provisoires ; presque tous présentent des risques : les performances, la robustesse et l'évolutivité sont presque toujours des préoccupations et doivent être validées grâce à l'évaluation, les prototypes ou l'insertion dans le prototype architectural.
Dans cette activité, le rôle de l'architecte du logiciel consiste à décider et à valider ces mécanismes : pour cela, il les crée ou les intègre et il vérifie qu'ils remplissent leur rôle, puis il les impose dans le reste de la conception système. Le rôle de l'architecte du logiciel s'associe au rôle du responsable de processus pour documenter les mécanismes et les détails relatifs à leur utilisation dans les recommandations de conception spécifiques au projet. La relation (ou le mappage) des mécanismes d'analyse avec les mécanismes de conception et avec les mécanismes d'implémentation (ainsi que les justificatifs associés) doivent être documentés dans le document d'architecture logicielle. Les mécanismes eux-mêmes représentent des éléments de modèle de conception (tels que les packages, les classes et les sous-systèmes de conception), qui sont détaillés dans l'artefact de modèle de conception comme faisant partie de leurs responsabilités de conception respectives.
RUP (Rational Unified Process)
|