Introduction
L'analyse descendante des cas d'utilisation est la technique permettant de dériver les exigences fonctionnelles pour
les éléments d'analyse (puis de conception). Les résultats de cette activité sont les suivants :
-
étude des opérations des sous-systèmes
-
étude des opérations des sous-systèmes hébergés pour les localisations
-
étude des opérations des sous-systèmes hébergés pour les processus
-
étude des cas d'utilisation pour les sous-systèmes (optionnel)
Cette technique utilise l'activité RUP standard consistant à choisir un ensemble de cas d'utilisation
architecturalement significatifs. Pour chaque cas d'utilisation, le flux d'événements est développé. Il s'agit d'une
description des interactions entre le système et les acteurs système. Les réponses système sont fonctionnelles : les
descriptions ne font aucune référence aux éléments d'architecture. Ensuite, une étape fonctionnelle (qui sera exécutée
par une opération système) est développée en une ou plusieurs étapes structurelles, exécutées par un
sous-système déterminé. Les étapes structurelles sont également associées aux localisations qui les
hébergent et aux processus qui les exécutent. Chaque étape structurelle qui implique plusieurs localisations ou
processus, est décomposée jusqu'à ce qu'elle puisse être exécutée sur une seule localisation, par un seul processus.
Une étape structurelle peut être répliquée sur plusieurs localisations, mais il s'agira à chaque fois d'instances
distinctes. Ces étapes structurelles peuvent potentiellement devenir des opérations sous-système, qui
constituent l'équivalent des opérations système à ce niveau inférieur de décomposition logique.
Les différentes compositions de séquences uniques d'opérations sous-système pour un sous-système donné, contribuant à
la réalisation des opérations système, donnent les cas d'utilisation sous-système (étape optionnelle).
Mappage des localisations de sous-système
Au début d'une analyse descendante des cas d'utilisation, vous êtes face à un système qui peut s'étendre sur plusieurs
localisations (et même les encapsuler) ; le niveau de décomposition en sous-systèmes (et en sous-sous-systèmes) relève
d'une décision architecturale et dépend du domaine et de la complexité du système, entre autres. Toutefois, dans
l'optique de l'analyse des performances, il est important que vous connaissiez la charge de traitement à imposer à une
localisation, et cela passe nécessairement par l'identification des opérations sous-système hébergées par cette
localisation. Par conséquent, il convient de respecter les règles de décomposition suivantes : la décomposition doit
aboutir à un ensemble d'opérations sous-système qui permet de distinguer clairement les différentes localisations. Cela
signifie qu'une opération sous-système ne doit pas s'étendre sur plusieurs localisations. Si une opération
sous-système (par exemple sur le sous-système A) nécessite pour son exécution l'utilisation de ressources d'une autre
localisation, alors ces ressources elles-mêmes doivent être mises à disposition via une opération sous-système, qui
peut être fournie par le sous-système A lui-même sur cette localisation, ou par un autre sous-système.
Bien évidemment, cette condition est réalisable uniquement si le sous-système ne s'étend pas sur plusieurs
localisations. Toutefois, un sous-système peut s'étendre sur plusieurs localisations si ses opérations peuvent être
partionnées comme indiqué ci-dessus—sinon, le sous-système doit être décomposé. Cette discussion concerne les instances
uniques d'un sous-système qui s'étend sur plusieurs localisations. Un sous-système peut toujours être répliqué sur
plusieurs localisations, mais il s'agit d'instances distinctes.
|