Développement du modèle dynamique

Nous verrons tout d’abord comment décrire des scénarios mettant en jeu un ensemble d’objets échangeant des messages. Ces interactions peuvent être décrites au moyen de deux types de diagrammes : le diagramme de séquence, qui met l’accent sur la chronologie des messages et le diagramme de commu- nication (appelé collaboration en UML 1.x), qui souligne les relations structu- relles des objets en interaction.Nous détaillerons ensuite la façon de décrire le cycle de vie d’un objet d’une classe particulière, au fil de ses interactions et de son évolution propre. Le diagramme d’états permet en effet une description précise et exhaustive des états d’un objet et des transitions causées par l’arrivée d’événements, y compris les réponses de l’objet. Nous verrons donc comment utiliser efficace- ment les nombreux concepts des diagrammes d’états, ou statecharts.Le développement du modèle dynamique constitue la troisième activité de l’étape d’analyse. Elle se situe sur la branche gauche du cycle en Y. Il s’agit d’une activité itérative, fortement couplée avec l’activité de modélisationstatique, décrite au chapitre précédent. Pour les besoins du livre, nous avons été obligés de les présenter de façon séquentielle, mais dans la réalité elles sont effectuées quasiment en parallèle. Le développement du modèle dyna-Nous avons vu au chapitre 4 qu’un cas d’utilisation décrit un ensemble de scénarios. Lors de l’étape de détermination des besoins fonctionnels, un scénario représente une séquence d’interactions entre le système et ses acteurs. Le système est alors considéré comme une boîte noire.

Un scénario correspond à l’exécution d’un ou de plusieurs enchaînements, joignant le début du cas d’utilisation à une fin normale ou non. Il est clair que la combinatoire des enchaînements fait exploser le nombre de scénarios potentiels ! Nous ne pourrons donc pas tous les décrire. Il faudra faire des choix, essayer de trouver le meilleur rapport « qualité/prix », c’est-à-dire l’ensemble minimal de scénarios permettant de couvrir toutes les actions/ réactions du système. Cela revient à définir une famille de scénarios qui empruntent au moins une fois toutes les branches d’exécution du cas d’utili- sation. Conformément à ce que nous vous avons expliqué au chapitre 4, le diagramme d’activité qui restitue ces chemins fournit un outil très efficace pour trouver les scénarios suffisants.Au niveau logique, l’envoi d’un signal et l’appel d’une opération sont simi- laires. Ils impliquent tous deux une communication qui transmet de l’informa- tion par valeur d’un émetteur à un récepteur pour le faire réagir. La différence fondamentale entre les deux réside dans l’asynchronisme du signal, qui est éga- lement unidirectionnel. L’appel d’opération, au contraire, est une communica- tion synchrone pendant laquelle le flot de contrôle passe temporairement de l’appelant à l’appelé. L’appelant perd le flot de contrôle pendant l’exécution de l’opération et le récupère à la fin de celle-ci. On peut considérer l’appel d’opéra- tion comme un signal avec un paramètre de retour implicite vers l’appelant.

D’une manière générale, la plupart des auteurs considèrent qu’en analyse, le diagramme de séquence est plus apte à représenter un scénario dans le contexte d’un cas d’utilisation, et qu’en conception, le diagramme de commu- nication se prête mieux à la représentation des itérations et des branchements complexes, ainsi que des flots de contrôle parallèles• regrouper plusieurs scénarios sur un même diagramme s’ils constituent des variantes très proches. C’est notamment le cas pour les scénarios d’exception qui se greffent généralement sur les diagrammes de séquence représentant les cas nominaux. Utilisez des notes textuelles en marge des diagrammes pour indiquer les branchements, ou les nouvelles notations UML 2 avec les cadres et les opérateurs alt ou opt. Néanmoins, si les variantes sont trop différentes, ne les regroupez pas car cela nuirait forte- ment à la lisibilité ;