Définitions des messages (stimuli)

Les Diagrammes d'interaction sont controlés par des évènements. Un évènement donne naissance à une nouvelle opération. Les évènements sont des stimuli qui sont envoyés d'un objet à l'autre et initalise une opération.

Les stimuli sont dessinés come des flèches horizontales, entre le bloc qui envois le stimuli et le bloc qui le reçoit. La plupart des diagrammes démarrent sur un stimuli extérieur, venant de la frontière du système. Ainsi en partant de notre description de service nous pouvons concevoir le service sur le diagramme.

conception.DI3Le service Dépose Article Par exemple:

Dépose d'Article

• Quand un client dépose un Article il est mesuré par le système. Les mesures permettent d'identifier le type de (bouteille, cannette, boite) déposé. Si ce type est accepté, le total client est incrémenté en fonction de ce type, puis le total quotidien pour le type. Si l'article n'est pas accepté un message "ARTICLE REFUSE" est allumé sur la machine.
• Quand le client presse le bouton reçu, l'imprimante imprime la date, puis le total de ce client est calculé et les informations suivantes imprimées sur le reçu : nom nombre déposés valeur de l'article total Finalement la somme totale que doit recevoir le client est imprimée, sur le reçu.

De cette description dessinons le diagramme de la figure 1.10.

Le service démarre quand le client dépose un article dans le panneau client. Le bloc Panneau Client est activé par des mécanismes extérieurs à notre système.

Le service débute quand le client dépose un article dans une des entrées du panneau client. Le bloc Panneau Client est activé par des détecteurs extérieur à notre système. Le client peut alors déposer un certain nombre de Bouteille, Boite et Canette. Ce qui est matérialisé par la boucle DO WHILE qui se termine quand le client demande son reçu. Dans la boucle nous comparons les mesures de l'article aux différents articles remboursés, ainsi nous vérifions si l'article est accepté. Si il l'est on incrémente l'attribut qui note le nombre d'articles de ce type que le client à déposé. Et l'on incrémente le total quotidien pour ce type d'article. Remarquez que ces incrémentations sont réalisées par l'objet BaseDeReçu. Une fois que le client a pressé le bouton reçu. Dépose article reçoit un stimuli lui demandant d'imprimer le reçu. l'impression du reçu commence par l'impression de la date et du logo. Puis Dépose article fournit un canal(File) à BaseDeReçu qui prépare les informations a imprimer dans ce canal. La somme totale est calculée et ajoutée dans le canal. Le canal est en suite imprimé. L'objet BaseDeReçu est libéré. L'objet Dépose Article est libéré.

Le diagramme ne montre que la situation où tout ce passe bien. Naturellement il faut aussi prendre en compte tout les cas d'erreur, comme le bouton reçu est pressé alors qu'aucun article n'a été déposé. Quand vous réalisez la conception d'un service, vous devez définir tous les stimuli que l'objet doit être capable de recevoir. La définition comprend le nom et les paramètres de chaque stimulus. C'est un des points les plus cruciaux du développement. Comme le développement peut-être mené par plusieurs personnes, le même stimulus d'un même objet peut-être défini par plusieurs personnes. Le but est de réutiliser un maximum les stimuli. Il devient ainsi plus simple de concevoir l'intérieur des objets comme les stimuli définissent les services que doit rendre l'objet pour les autres objets. Quand on défini un stimuli on doit garder à l'esprit les choses suivantes:

• Moins il y a de paramètres plus la réutilisabilité augmente. Si le nombre de paramètres est réduit, le stimuli sera plus facile à comprendre et cela augmente les chances que les stimuli crées soit identiques à ceux défini par d'autres et donc ainsi plus réutilisables. Un stimulus avec trop de paramètres devrait être redéfini ou divisé en plusieurs stimuli. Le point est signalé par Johnson et Foot qui indiquent aussi d'autres règles pour une conception orienté réutilisation.
• Les stimuli qui entraînent les mêmes comportements doivent porter le même nom, indépendamment du type et du nombre de paramètres ainsi que du type de l'objet receveur. Il n'y ainsi pas de conflit par multiplicité de noms. Si deux stimuli ont le même nom il est plus facile de détecter leurs similarités.
• Le nom du stimulus doit refléter la distribution des responsabilités entre les différents blocs. Rendre chaque objet le plus indépendant possible est un des principes fondamentaux du génie logiciel.
• le stimuli doit mettre en valeur clairement l'échange d'informations. Le nom doit être choisi soigneusement. Donner des noms est une des techniques les plus délicates de la programmation, il existe d'ailleurs souvent des règles pour cela. Les noms indiques une intuition sémantique sur le rôle ou la fonction de la chose qui le porte, cette intuition aide à la compréhension et permet de trouver rapidement les stimuli réutilisables.
• Création et destruction d'instance sont des stimuli ordinaires.

La description d'un service est normalement divisé en parcourt de Base et parcourt alternés. Le parcourt de base est la séquence la plus importante du service. Il est toujours conçu en premier. Les parcours alternés constituent l'ensemble des autres séquences, en particulier la gestion des pannes. Une fois le parcourt de base entièrement conçu, on passe aux parcourt alternés. Le but est d'en concevoir un maximum. En effet plus il y a de parcourt alternés prévus, décrits, conçus, plus on a de chance d'obtenir un modèle de conception robuste.

Un stimuli peut avoir plusieurs sémantiques par exemple communication intra et inter processus. Un stimuli intra-processus est un appel normal à l'intérieur du processus. Ces stimuli sont appelés en général message. Un message correspond à un message Smalltalk/objectiveC, l'invocation d'une opération en EIFFEL ou C++ . C'est le mode naturel de communication des langages objets. Un stimuli inter processus est souvent appelé un signal. Les signaux sont synchrones ou asynchrones, l'exécution du processus continue après l'envois du signal. En ADA le mécanisme de rendez-vous entre tâches est synchrone. Une des tâches devra attendre l'autre. Les concepts de messages ou de signaux décrit ici sont génériques, ils doivent être adaptés à votre cas et à l'environnement de programmation. Si par exemple vous utilisez ADA, utiliser le terme rendez-vous. conception.flechesDes types de stimuli différents sont dessinés différemment. On dessinera les messages et les signaux avec un convention différente voir Figure 1.11messages en flèches pleines et signaux en flèches creuses. Si nécessaire la sémantique des stimuli peut changer d'un projet à l'autre. Des modes de synchronisation ou de time-out peuvent être spécifiés si nécessaire. Mais ici encore, utilisez de préférence les primitives qu'offre le langage de programmation ou le système d'exploitation de l'environnement d'implémentation.

Les signaux sont des éléments essentiellement temps réel (cf. temp réel). Dans la suite de ce chapitre nous utiliserons uniquement des messages.