Architecture Logicielle des IHMs

Transcription

1 Architecture Logicielle des IHMs Eric Lecolinet - ENST - Page 1 Conception Logicielle! Modèle conceptuel modèle de fonctionnement du système idéalement : correspond au modèle mental de l utilisateur! Exemple de feedback Page 2

2 Langages de spécification! Problème spécifier de manière non ambiguë le comportement en particulier pour travail en équipe! génération de code éventuelle avec certains systèmes! Langages de description de syntaxe UAN : User Action Notations PPS: Propositional Production Systems! Exemple PPS Color ( Black, White, Red ) Input (.MouseDown,.MouseMove,.MouseUp ) // noter le point.mouseup, Shift ->!DoMultipleSelect, InSelectMode Page 3 Page 4

3 Page 5 Principe de séparation! Principe de base de conception des IHMs! Pas toujours réalisable en toute rigueur si manipulation directe / forte interactivité exemple : traitement de texte! Partage de données entre GUI et NF modèle MVC, variables actives Page 6

4 Conception itérative / participative! Conception itérative cycle en spirale cycle en étoile conception analyse implémentation évaluation! Conception participative les utilisateurs prennent un rôle actif dans la conception utilisateurs Page 7 Modèles d architecture logicielle! Structure générique de conception! Décrire flux de données utilisateur <--> application étapes de transformation des données identification et agencement des composants logiciels Page 8

5 Modèle Langage! Vue linguistique de l interaction analogie : IHM <=> dialogue entre individus! 3 composantes : Lexicale: vocabulaire d entités d entrée-sortie exple: primitives et objets graphiques de base, sons... Syntaxique: construction des phrases exple: sélection et modification d un objet (dessin, texte...) Sémantique: signification des phrases concepts et objets du domaine d application Page 9 Modèle de Seeheim! Inspiré du modèle langage (groupe de travail SIGGRAPH en 1985)! Cadre de pensée, forme générique! Contrôleur = notion plutôt floue, centralisation du traitement Page 10

6 Modèle Arch! Extension de Seeheim Pieds de l arche : composants imposés par réalité Interaction : objets d une boîte à outils (Toolkit) Présentation : abstraction de la boîte à outils (-> boîte à outils virtuelle) Page 11 Modèle multi-agents! Vision: système interactif = ensemble d agents spécialisés qui réagissent à / produisent des événements! Agent = système de traitement doté d une mémoire d un état d un processeur (éventuellement simulé) de récepteurs-émetteurs d événements Page 12

7 Communication par envoi de messages! Message = couple sélecteur = opérateur du destinataire données = paramètres de cet opérateur! Encapsulation : séparation entre: spécifications externes (filtre ou port d entrée) implémentation interne Page 13 Caractéristiques et réalisation! Réalisation langage objets, généralement «statiques» : Java, C++, C# parfois plus «dynamiques» : Objective-C (MacOSX) ou même en C (X-Window)! Envoi de message se réduit généralement à de l appel de méthode! Caractéristiques organisation modulaire (souvent hiérarchique) gestion décentralisée réutilisabilité : héritage, composition, décoration peu de classes, beaucoup d instances Page 14

8 ! Limitation de l envoi de message par appel de méthode a) le destinataire et la méthode doivent être connus par avance b) pas de distribution (un seul programme sur une seule machine) c) pas de vrai parallélisme (un thread de gestion des événements)! Autres techniques langages objets «dynamiques» (Objective C / Cocoa) mécanismes de réflexion (Java) : capacité des objets à s auto-décrire prise en charge par le système ou le toolkit graphique exple: X-Window Page 15 Widgets! Widget = objet graphique ou «control» ou «component»! Exemples de toolkits à widgets Smalltalk : MVC (historique) Objective C : Next, MacOSX Java : AWT, SWT, Swing C++ : Visual C++, Borland C++, Qt, ILOG Views C : Motif, Gtk Page 16

9 Modèles homogènes / hétérogènes! Modèle multi-agents = modèle général : pas d indication sur la manière d organiser un système interactif! Modèles homogènes GUI = graphe de noeuds multi-facettes (ou multi-composantes) modèle PAC toolkits Motif, Qt, Gtk...! Modèles hétérogènes GUI = graphe de noeuds spécialisés modèle MVC toolkits Swing, Amulet, Ubit... Page 17 Modèle PAC (Joelle Coutaz, IMAG)! Modèle homogène multi-agents! Objets interactifs multi-facettes! Structuration PAC Présentation Contrôle Abstraction Page 18

10 Modèle MVC! (voir plus loin) Page 19 Outils de spécification d interfaces! Grammaires langages de description de syntaxe (voir précédemment) production de code éventuelle! Diagrammes de transitions avantage : génération d automates à états finis vérification automatique mais limitée (cf. ergonomie, visibilité...) problème : rapidement complexes! autre technique : réseaux de Pétri Page 20

11 Outils de spécif. / génération d interfaces! Statecharts amélioration des Diagrammes de transition simplification par : groupements et factorisation intérêt pratique : UML et divers outils qui les utilisent! Générateurs d interface UIMS (User Interface Management Systems), model-based tools objectif : génération automatique du code pour partie graphique ET pour contrôle du dialogue intérêt limité en pratique: applications très spécifiques exple bases de données : MS Access, Sybase PowerDesigner prototypes de labo Page 21 Outils de création d interfaces! Outils interactifs de construction d interfaces Interface builders, Application Frameworks par programmation visuelle avantage: prototypage utilisables par des non informaticiens inconvénient: gèrent essentiellement la présentation statique Page 22

12 Outils de création d interfaces (...)! Autres limitations des outils interactifs peu de support pour la manipulation directe génération de code «one way gestion du layout et de la localisation : contraintes ou WYSIWYG? Page 23 Outils de création d interfaces (...)! Mockups prototypes non opérationnels Powerpoint, Flash, Director, etc.! Langages spécialisés prototypes, petits outils, adaptabilité à des plateformes très différentes... Tcl/Tk, XML/UIMS, etc. Page 24

13 Outils de création d interfaces (...)! Toolkits graphiques grande flexibilité difficulté d apprentissage : réservés aux professionnels! Systèmes de fenêtrage niveau 0 : «entrailles» du système graphique... Page 25 Toolkits graphiques! Toolkit bibliothèque de techniques d interaction collection de primitives (fonctions et objets)! Gestion du système de fenêtrage fenêtrage, terminal abstrait, graphique de base événements texte et polices éventuellement : son, vidéo, 3D...! Gestion du dialogue interacteurs : boutons, champs textuels, listes, ascenseurs... composition d objets : fenêtres, menus, conteneurs Page 26

14 Exemple de X Window! Système structuré en couches logicielles gestion du poste de travail : Xlib gestion du dialogue initialement: Intrinsics + Toolkit : actuellement: Swing, Qt, Gtk... Page 27 Programmation par événements! Programmation classique l application a le contrôle utilisateur est au service de l application Page 28

15 Programmation par événements (...)! Interfaces graphiques : c est l inverse l utilisateur garde le contrôle : on peut à tout moment sélectionner, cliquer, changer de fenêtre... application esclave de l utilisateur programmation non modale dialogue multi-fils (multi-threads) simulé par boucle de gestion des événements Page 29 Programmation par événements (...)! Conséquences application toujours prête à réagir programmation par événements! Evénement (ou «message») envoyé à l application ciblée à chaque action élémentaire de l utilisateur Page 30

16 Exemples d événements Evénéments X Window de base: ButtonPress, ButtonRelease: appuyer / relacher un bouton de la souris KeyPress, KeyRelease: appuyer / relacher une touche du clavier MotionNotify: bouger la souris (avec un bouton enfoncé) EnterNotify, LeaveNotify la souris entre dans / sort d une fenêtre Expose: rafraîchir la fenêtre (la fenêtre redevient visible) ResizeRequest: la fenêtre a changé de taille MapNotify, UnmapNotify: la fenêtre apparaît / disparait de l ecran Page 31 Types d événements! Un événement est caractérisé par un type contient des infos complémentaires: par exemple, la position (x, y) de la souris! Technique très générale pas limitée au graphique pour la communication entre applications éventuellement via un réseau (X-Window) Page 32

17 Gestion des événements! Principe général Etape 1 : créer les widgets principaux Etape 2 : lancer la boucle de gestion des événements! L application se met en attente des événements et devient esclave de l utilisateur Page 33 Boucle de gestion des événements! Boucle infinie qui: récupère les événements appelle les fonctions du programme! Deux stratégies protocole non embarqué protocole embarqué (tous les toolkits récents) Page 34

18 Protocole non embarqué! Principe le programmeur écrit cette boucle! au moins en partie... while (True) { event = GetNextEvent() switch(event->type) { case EVENT_E1 sur window_w1: foo_e1_w1(); break; case EVENT_E2 sur window-w2: foo_e2_w2(); break; }... Page 35 Protocole non embarqué (...)! En réalité c est bien plus complexe! car il faut prendre en compte : les combinaisons d événements et sur plusieurs widgets!! A titre d exemple modéliser un bête clic souris sur un bouton, un menu, une liste, etc.! Conclusion forte complexité forte interdépendance entre objets graphiques --> «plat de spaghettis» Page 36

19 Protocole embarqué! Principe le contrôle du dialogue est «embarqué» dans les widgets la boucle de gestion des événements est prédéfinie! Le programmeur doit seulement : associer des fonctions de callback aux widgets appelées automatiquement par la boucle de gestion des événements Page 37 Protocole embarqué (...)! Avantages simplicité, modularité! Notion d objet graphique réactif protocole embarqué --> orienté objet! Inconvénients moindre contrôle, affichage asynchrone! Attention multi-fils simulé par la boucle de gestion des événements conséquence...? Page 38

20 Exemple: Motif en langage C static void MaFonction(Widget w, XtPointer cld, XtPointer cad) { }...; Widget boite, bouton,...; /* creer un objet graphique */ bouton = XmCreatePushButton(boite, bouton,null,0); XtManageChild(bouton); /* y associer un callback (sera appelee quand on clique sur le bouton) */ XtAddCallback(bouton, XmNactivateCallback, MaFonction, NULL);...etc... /* lancer la boucle de gestion des evenements */ XtAppMainLoop(app); /* plus rien n est exécuté après cette ligne! */ Page 39 Contrôle asynchrone! Principe délégation du traitement de la GUI vers le Noyau fonctionnel! Problème l interface perd la main tant que le callback s exécute Page 40

21 Contrôle asynchrone! Conséquences immobilisation, perte de contrôle, plus de rafraîchissement si fonctions de callback longues ou «infinies»! Exemple recherche de pages avec un navigateur Web impossible de cliquer sur «stop»! Page 41 Contrôle asynchrone Autres cas problématiques! Noyau Fonctionnel contrôlé par une boucle infinie exemple: serveur de base de données! Application distribuée plusieurs interfaces qui communiquent via un réseau! Noyau Fonctionnel préexistant exemple: gestionnaire de fichiers Page 42

22 Contrôle asynchrone (...)! Solutions processus, threads («vrai» multi-fils) plusieurs exécutables! Problèmes synchronisation : toujours délicate threads : toolkits pas toujours multi-threads processus, plusieurs exécutables : notification du NF vers la GUI Page 43 Communication du NF vers la GUI! Evénements non graphiques arrivée d une donnée sur un pipe, une socket traitée comme un événement graphique exemples: Qt, X-Window/Motif! Evénements ad-hoc le NF envoie des événements «clients» à la GUI exemple: ClientMessage de X-Window Page 44

23 Communication du NF vers la GUI! Partage de données variables actives zones tampon partagées (clipboard) Cut and Paste, Drag And Drop également pour synchronisation de programmes! Cas clinique: Time Outs mise à jour à intervalle de temps régulier également pour les animations Page 45 Conclusions sur les Toolkits! Avantages Portabilité informatique (matérielle, logicielle) Souplesse d utilisation Extensibilité, flexibilité Intégration de critères ergonomiques! Inconvénients apprentissage effort de développement important pas d indication sur l architecture logicielle seul développeur = programmeur Page 46

24 Page 47