• Aucun résultat trouvé

Introduction du chapitre 5 157 Choix conceptuels opérés

SOMMAIRE Titre Consulter les messages émis

5.3. Les diagrammes d’interaction

Les diagrammes d’interaction modélisent les coopérations qui peuvent exister ou naître entre les objets du système. La notion d’objet fait référence à la programmation orientée objet (Ducournau et al., 1998). Cette méthode définit les objets comme étant des structures de données symbolisant des entités du monde réel dans le monde logique, pour faciliter la réalisation du programme informatique auquel on souhaite aboutir. Les objets peuvent être considérés comme des représentants concrets de structures abstraites ou de plus grandes familles que l'on va appeler classes. L'objet est en fait ce qu’on appelle une instance, un exemplaire ou la représentation d'une classe. Dans le cas présent, un smartphone peut être considéré comme un représentant de la grande classe des ordinateurs, ou si on veut aller plus loin de celle des appareils électroniques ou des machines. Cet exemple permet en même temps d’introduire deux concepts fondamentaux de la programmation orientée objet : un objet peut hériter des propriétés (attributs et méthodes) d’un objet parent (ce qu'on appelle l'héritage) et être dotés (polymorphisme) de propriétés supplémentaires ou de modifier celles qu’il possède déjà (Dutoit et al., 1993).

5.3.1. Les diagrammes de séquence

Définitions et apports des diagrammes de séquence

Le diagramme de séquence permet de représenter les collaborations entre objets selon un point de vue temporel. Ce diagramme met l'accent sur la chronologie des envois de messages. Il privilégie ainsi la représentation temporelle à la représentation spatiale, et est plus apte à modéliser les aspects dynamiques du système. Les diagrammes de séquence permettent en fait de décrire COMMENT les objets du système interagissent entre eux (en s'échangeant des messages) et avec les acteurs au cœur du système. Le formalisme des diagrammes de séquence permet de représenter les périodes d'activité des objets c'est-à-dire le temps pendant lequel un objet effectue une action, soit directement, soit par l'intermédiaire d'un autre objet lui servant de sous-traitant.

Selon S. Lund et K. Stølen (2006), un diagramme de séquence est constitué d'un cadre qui représente l'environnement du système spécifié (ici une activité relative à l’application) et d’une ou plusieurs lignes de vie, symbolisant les composants du système. Les flèches représentent les messages envoyés entre les lignes de vie, ou entre une ligne de vie spécifique et le système dans sa globalité. L’élément de base du diagramme de séquence est l’événement, qui correspond à un message dont le genre détermine s’il s’agit d’un message transmis ou reçu. Autrement dit c'est, un signal avec une adresse de transmission et un destinataire.

Mise en œuvre dans l'application

Les diagrammes relatifs aux cas d’utilisation du citoyen (Fig. 5.15) et de l’administrateur (Fig. 5.16) ont été schématisés pour accroître la lisibilité des actions attendues. À travers les interactions du citoyen et de l’administrateur, l’application offrira une interface permettant d’interagir avec les objets « contacts téléphoniques » (pour valider les numéros de téléphone) et avec la classe « évènements » (pour leur déclaration, leur enregistrement puis leur diffusion). Chaque étape demande une attention particulière pour pouvoir anticiper les messages éventuels à afficher (validation ou saisie incorrecte). Des écrans complémentaires ont aussi été envisagés pour orienter et guider de façon optimale et économique les utilisateurs du système dans leur navigation.

Source : Kouadio (2016)

Figure 5.16 : Diagramme de séquences de l’administrateur.

Administrateur Ecran Menu Administrateur Accès Messages Ecran des messages Accés accordé Détail Message Message détaillé Diffusion message Message diffusé Ouverture Ouverture confirmée Navigation administrateur Menu rincipal Confirmation  Numéros

5.3.2. Le diagramme de vue d’ensemble

Définitions et apports du diagramme de vue d'ensemble

Ce diagramme (aussi appelé diagramme de vue globale d’interaction) permet de déconstruire les scénarios complexes qui exigeraient de multiples usages de conjonctions telles que « si », « sinon » et « alors » pour gérer dans la programmation les situations conditionnelles. Sa mise en œuvre s’illustre par la combinaison d’éléments issus du diagramme d'activité avec ceux du diagramme de séquence pour afficher le flux d'exécution du programme (OMG, 2015). Il met l’accent sur le flux général de contrôle dans lequel chaque nœud peut représenter soit un diagramme d'interactions (séquence, communication, chronogramme) désigné également par le terme Interactions associé à une estimation

de son temps d’exécution, soit une action spécifique de référence déterminante appelée

InteractionUses déclenchant une autre Interaction ou la fin du processus modélisé (Fig. 5.17). Il s'agit

en fait d'un diagramme d'activités spécifique qui est utilisé en faisant abstraction des messages et des lignes de vies, pour rendre compte à la fois de l'organisation des participants à l'interaction et du comportement du système suite à chacune de leurs actions.

a) b)

Source : OMG (2015)

a : Interactions ; b : InteractionUse

Figure 5.17 : Notations graphiques utilisées par le diagramme global d’interaction.

Comme le diagramme de séquence gère les enchaînements linéaires des messages (étant centré sur les interactions entre participants) et puisque le diagramme d'activités porte sur les enchainements non linéaires des actions de chaque participant, ce diagramme de vue globale sert au final à modéliser les enchaînements non linéaires des messages (Bennama et Bouabana-Tebibel, 2009).

Mise en œuvre dans l'application

Dans le cadre d’Al’in le diagramme de vue globale d’interaction a contribué à distinguer, tout en les connectant, les actions relevant du « citoyen capteur » (qui déclare l’événement) de l’administrateur (au centre du système expert) et du « citoyen récepteur » de l’alerte. On a une vue sur le fonctionnement du dispositif à réaliser à la fois sur les plans humains et logiciels (Fig. 5.18), mais aussi sur certaines contraintes auxquelles il faudra faire face. Il s’agit entres autres des délais de réactivité de l’utilisateur devant un menu, une information que lui présente le système ou une question qu’il lui pose, temps de réponse du système en cas de traitements immédiats distants (insertions de données, contacts d’ordinateur ou de serveurs) technicité (algorithmes de traitements à envisager).

Source : Kouadio (2016)

Documents relatifs