• Aucun résultat trouvé

Instruments modifiant des paramètres de formes

Partie IV Utilisation de Malai et de Malan : études de cas

9.8 Instruments

9.8.2 Instruments modifiant des paramètres de formes

Nous présentons dans cette section les instruments modifiant des paramètres des formes tels que la couleur de fond, l’épaisseur ou le paramètre stipulant si la bordure d’une forme doit être affichée. N’apportant que peu d’éléments intéressant, l’instrument supprimant les formes et la loupe sont définis dans l’annexe C.4, page 226.

Pinceau

(a) Diagramme de classes (b) Composant graphique Swing

Fig. 9.16: Composant graphique de la palette de couleurs

Le pinceau est un instrument permettant de modifier la couleur d’un objet. Cet instrument possède une palette de couleurs permettant se sélectionner la couleur à appliquer choisir une couleur parmi un ensemble proposé. La figure 9.16b est un exemple d’une palette de couleurs qui consiste en un panneau composé d’un ensemble de rectangles colorés sélectionnables symbo-lisant les couleurs proposées. Le diagramme de classes de la figure 9.16a décrit cette palette de couleurs (classe PaletteCouleurs) qui possède : un ensemble de CouleurUI correspondant aux différentes couleurs de la palette (relation couleurs) ; l’éventuelle couleur sélectionnée (relation sélection).

(a) Diagramme de classes (b) Liaison entre l’interaction et l’action

Fig. 9.17: Partie statique du pinceau

Comme le décrit le diagramme de classes de la figure 9.17a, les classes PinceauBord et PinceauFond, utilisées dans l’éditeur pour modifier les couleurs de la bordure et de fond de formes, héritent de la classe abstraite Pinceau. Celle-ci possède un composant graphique de type PaletteCouleurs. Le pseudo-code ci-dessous décrit les liaisons du pinceau. Un pinceau prend en entrée une interaction de type SimpleClic pour : modifier la couleur des formes sélectionnées (ac-tion ModifierCouleur) lorsque la cible du simple clic est du type CouleurUI (ligne 4) ; se désac-tiver lorsque le point du simple clic est en-dehors de la palette (ligne 7). Pour les PinceauFond et PinceauBord, les actions générées sont respectivement ModifierCoulIntérieure et Modifier-CoulBord.

9.8 Instruments 2 SimpleClic s c −> ModifierCouleur a c t i o n { 3 c o n d i t i o n : 4 p a l . o b j e t i s CouleurUI && p i n c e a u . p a l e t t e . c o u l e u r s . c o n t a i n s ( s c . c i b l e ) 5 } 6 SimpleClic s c −> DésactiverInstrument a c t i o n { 7 c o n d i t i o n : ! p i n c e a u . p a l e t t e . c o u l e u r s . c o n t a i n s ( s c . c i b l e ) 8 } 9 } Sélectionneur de pinceau

(a) Diagramme de classes (b) Liaison entre l’interaction et l’action

Fig. 9.18: Partie statique du sélectionneur de pinceau

Cet instrument a pour but d’activer le pinceau PaletteCouleurBord ou PaletteCouleur-Fond via, respectivement, les boutons coulBord et coulPaletteCouleur-Fond (cf. figure 9.18a).

L’unique liaison définie pour cet instrument est établie entre l’interaction SimpleClic et l’ac-tion ActiverInstrument (cf. figure 9.18b). La condil’ac-tion de cette liaison, définie dans le pseudo-code suivant, stipule que l’activation du pinceau ne peut s’effectuer qui si le clic simple est réalisé sur un des deux boutons de l’instrument. L’instrument paramètre l’action ActiverInstrument pour qu’elle active la palette correspondant au bouton cliqué.

1 L i a i s o n s SélectionneurPinceau s e l e c t {

2 SimpleClic c l i c −> ActiverInstrument a c t i o n {

3 c o n d i t i o n : c l i c . o b j e t==s e l e c t . c o u l B o r d | | c l i c . o b j e t==s e l e c t . coulFond

4 }

5 }

Instrument pour la modification de l’épaisseur

L’instrument ModificateurEpaisseur est dédié à la modification de l’épaisseur de formes. Cet instrument se fonde sur un instrument de type TextBox, comme l’illustre le diagramme de classes de la figure 9.19a. Cet exemple d’instrument met en avant la difficulté d’utiliser un modèle instrumental avec des composants graphiques déjà existants : le TextBox, tiré de notre modèle de composants graphiques (cf. figure B.1, page 216), est un composant graphique standard disponible sur la plupart des plates-formes d’IHM. Celles-ci définissent déjà un modèle d’interaction pour ce composant graphique qui peut différer d’une plate-forme à une autre. Il n’est donc pas nécessaire de redéfinir une interaction pour l’utiliser ; c’est le passage de l’interface concrète à l’interface finale qui doit définir le lien entre le TextBox et le composant graphique

(a) Diagramme de classes (b) Liaison entre l’interaction et l’action

Fig. 9.19: Parties statique de l’instrument ModificateurEpaisseur

correspondant de la plate-forme d’IHM sélectionnée. Les liaisons ne s’établissent donc pas en utilisant les interactions du composant graphique qui dépendent de la plate-forme d’IHM choisie, mais avec une interaction fondée sur l’évènement engendré par ces interactions : par exemple, la liaison de l’instrument ModificateurEpaisseur stipule que l’interaction TexteModifié crée une action ModifierEpaisseur (cf. figure 9.19b, page 164). TexteModifié ne définit pas la manière dont l’utilisateur interagit avec le TextBox, mais se fonde sur l’évènement ChangementValeur correspondant au résultat de cette interaction.

La liaison de la figure 9.19b, page 164 est décrite par le pseudo-code ci-dessous. La condition de cette liaison stipule que la nouvelle valeur du champ de texte doit être un nombre supérieur à 0 (ligne 3). 1 L i a i s o n s ModificateurEpaisseur ep { 2 TexteModifié tm −> ModifierEpaisseur a c t i o n { 3 c o n d i t i o n : i s I n t e g e r ( tm . t e x t e ) && t o I n t e g e r ( tm . t e x t e )>0 4 } 5 }

9.9 Conclusion

Nous avons présenté dans ce chapitre une étude de cas dédiée à la conception d’un édi-teur de dessins vectoriels. L’étude se focalise principalement sur la facette interactive (actions, instruments et interactions) définie avec le modèle conceptuel Malai. Ce modèle a notamment montré qu’il pouvait décrire aussi bien des interactions et des instruments classiques (double clic, glisser-déposer, etc.) que complexes (mouvements contrôlés par la voix, interaction bimanuelle,

etc.).

Cette étude de cas a mis en avant le fait que le modèle Malai ne décrit pas en détail certaines informations, comme celles concernant la mise à jour d’une action par un instrument. Une des prochaines étapes pour compléter Malai consiste à définir un langage dédié à la description des actions, de la mise à jour d’une action par un instrument, du feed-back intérimaire, etc. Ce langage sera défini à partir du pseudo-code utilisé dans ce chapitre et le suivant.

Chapitre 10

L’agenda

Sommaire 10.1 Introduction . . . 167 10.2 Données sources . . . 168 10.3 Interface . . . 168 10.4 Présentations . . . 170 10.4.1 Présentation abstraite . . . 170 10.4.2 Présentation concrète . . . 170 10.5 Correspondances de schémas . . . 171 10.5.1 Données sources vers présentation abstraite . . . 171 10.5.2 Présentation abstraite vers présentation concrète . . . 173 10.6 Actions . . . 175 10.6.1 Action spécifique aux correspondances de schémas . . . 176 10.6.2 Gestion des évènements . . . 177 10.6.3 Gestion des horaires d’évènements . . . 178 10.6.4 Gestion des descriptions d’évènements . . . 179 10.7 Instruments . . . 180 10.7.1 Main . . . 180 10.7.2 Le modificateur d’horaires . . . 182 10.7.3 Modificateur de descriptions . . . 182 10.7.4 Sélectionneur de la semaine à afficher . . . 183 10.8 Autre présentation concrète . . . 184 10.9 Conclusion . . . 185

10.1 Introduction

10.1 Introduction

Les applications gérant les emplois du temps, comme Google calendar1et Lightning2, sont des SI largement utilisés se fondant, pour la plupart, sur le principe de la manipulation directe : un calendrier contient des évènements éditables de manière directe et indirecte. Ce type de SI est notamment au centre de l’étude de cas utilisée dans [Beaudoux et al., 2009] pour présenter l’environnement AcT (cf. section 3.6).

Cette seconde étude de cas se concentre sur la conception d’un agenda usuel. Au travers de ce SI, un utilisateur doit pouvoir : créer et supprimer des évènements ; changer leurs horaires ; modifier la description d’évènements ; naviguer dans l’agenda. Les données manipulées par ce SI sont multiples : il peut s’agir par exemple d’un agenda personnel ou d’emplois du temps d’étudiants qu’un responsable des études doit organiser. Cette dernière proposition est celle visée par cette étude de cas. Cette dernière se focalise sur les liens entre les données et les présentations abstraite et concrète, qui nécessitent des calculs non triviaux pour notamment définir la position des évènements de l’agenda. La figure 10.1 décrit les liens entre les données et leurs présentations. La présentation abstraite (AgendaCanvas) est créée à partir d’emplois du temps d’étudiants (flèche ¬). De même, la présentation concrète (AgendaCanvasUI) est créée à partir de la présentation abstraite (flèche ­). Les actions modifient la présentation abstraite (flèche ±) qui répercute ensuite les modifications à la présentation concrète (flèche ­). Les données sources peuvent être synchronisées à partir de la présentation abstraite (flèche²) par une correspondance de schémas inverse à la numéro ¬. L’agenda personnel est donné à titre indicatif pour illustrer le fait que plusieurs modèles de données sources peuvent être utilisés pour un même modèle de présentation et d’instrument.

EmploiDuTemps AgendaPersonel AgendaCanvas Présentation abstraite AgendaCanvasUI Présentation concrète

Fig. 10.1: Liens entre les données sources et les présentations cibles

Ce chapitre s’organise de la manière suivante : la section 10.2 est consacrée à la présentation du schéma des données sources définissant un emploi du temps d’un étudiant ; la section 10.3 présente l’interface de l’agenda ; la section 10.4 détaille les présentations abstraite et concrète ; la section 10.5 définit les correspondances de schémas Malan entre les données sources et la présentation abstraite, et entre cette dernière et la présentation concrète ; les sections 10.6 et 10.7 sont dédiées respectivement à la définition des actions et des instruments, tous décrits via le modèle Malai ; la section 10.9 conclut ce chapitre en analysant les avantages et les limites de notre approche pour la réalisation de cette étude de cas.

1http ://www.google.com/calendar

2

10.2 Données sources

Les données sources de l’agenda, dont le schéma est défini dans la figure 10.2, décrivent un emploi du temps d’un étudiant. Un emploi du temps (classe EmploiDuTps) se compose de ressources et de semaines. Une ressource désigne : un enseignant décrit par son nom et son prénom ; une matière possédant un intitulé et faisant référence aux enseignants concernés ; une plage horaire possédant une date de début et une date de fin ; une salle (amphithéâtre ou laboratoire) pourvue d’une capacité et d’un nom. Une semaine est décrite par : l’année à laquelle elle se réfère ; le numéro de division et le nom de la promotion de l’étudiant ; le numéro de la semaine ; les cinq jours de cours (du lundi au vendredi). Une journée se compose d’enseignements, c.-à-d. de cours magistraux (classe Cours), de travaux pratiques (classe TP), et de travaux dirigés (classe TD). Un enseignement concerne une matière, est assuré par un enseignant, a lieu dans une salle, et se déroule sur une ou deux plages horaires consécutives. Si aucun enseignant n’est précisé pour un enseignement, le premier enseignant de la matière de l’enseignement (association Matiere.enseignants) est considéré.

Fig. 10.2: Schéma des données sources de l’agenda

10.3 Interface

L’interface de l’agenda, dont la structure est représentée par le diagramme de classes de la figure 10.3a, consiste en une fenêtre (classe Window) contenant une instance AgendaUI et un champ de texte pour le changement de semaine (TextBox). Les classes Window et TextBox sont issues du modèle de composants graphiques de la figure B.1, page 216. L’agenda dispose des

10.3 Interface

instruments suivant : ModificateurHoraire permet de modifier les horaires des évènements ; ChoixSemaine permet de sélectionner la semaine à présenter ; Main est un instrument dédié à la manipulation directe des évènements.

(a) Diagramme de classes de l’interface

(b) Interface en Swing

Fig. 10.3: Interface de l’agenda

La figure 10.3b présente l’interface finale s’exécutant sur la plate-forme Swing. Elle montre la présence d’un champ de texte au nord et de la présentation concrète de l’agenda au centre. Cette dernière contient des évènements présentant leurs descriptions, leur type à un horaire donné. Les évènements de chaque jour sont disposés de manière horizontale. L’évènement sélectionné dispose de deux poignées, visibles aux extrémités droite et gauche sous la forme de deux ou quatre points alignés, permettant de modifier sa date de début et de fin.