Modèles d`architecture Principe de base Modèle de l`arche
Transcription
Modèles d`architecture Principe de base Modèle de l`arche
Principe de base Séparation interface / noyau fonctionnel : utilisateur interface noyau fonctionnel système interactif Modèles d’architecture Variations sur ce principe : – Modèle de Seeheim – Modèle-Vue-Contrôleur (MVC) – Présentation-Abstraction-Contrôle (PAC) Remarque : ces modèles ne sont pas limités à l'interaction graphique Modèle de l’arche (Seeheim) Présentation (lexical) – gestion des périphériques – affichage – style d'interaction Contrôleur de dialogue (syntaxique) – traitement et séquencement du dialogue Adapteur de domaine (sémantique) – vue de l'application par l'interface – vue de l'interface par l'application Service(s) minimum utilisateur présentation contrôleur de dialogue adapteur de domaine Le noyau fonctionnel doit fournir un minimum de services pour pouvoir implémenter correctement l’interface J-D. Fekete décrit trois de ces services (IHM 1996) – la notification – la prévention des erreurs – l’annulation Une fois de plus, cette liste n’est pas exhaustive… domaine, noyau fonctionnel 1 3 services indispensables (1/3) Notification : possibilité pour un module externe d’être prévenu lorsque l’état du noyau sémantique change Exemple d’utilisation : visualisation d’un système de fichiers 3 services indispensables (2/3) Prévention des erreurs : possibilité de savoir si un appel de fonction est licite dans un certain contexte Exemples d’utilisation – retour d’information pour la manipulation directe Mise en œuvre – modularité : le noyau fonctionnel n’est pas censé connaître le mode de présentation – on veut éviter le polling (attente active) – variables actives (Tcl), callbacks, etc. – notification synchrone ou asynchrone ? 3 services indispensables (3/3) Annulation : possibilité de revenir à des états antérieurs du noyau sémantique Exemple d’utilisation – voir Word, Photoshop, etc. Mise en œuvre – but : éviter la simulation au niveau de l’interface – historique, mécanisme de rollback – menus grisés Mise en œuvre – pas avec des exceptions (c’est trop tard…) – fonction de test (accepte, refuse, nsp) Modèle-Vue-Contrôleur (MVC) Origine : – modèle issu de Smalltalk-80 – adopté par de nombreuses boîtes à outils (Java AWT, Microsoft MFC, …) Principe : – le modèle correspond aux données de l'application (structures et fonctions) – la vue présente des informations à l'utilisateur à partir des données du modèle – le contrôleur se charge de l'interaction avec l'utilisateur 2 Cycle standard d’interaction MVC Implémentation de MVC dans Smalltalk-80 3 classes abstraites définissent les comportements génériques des composants MVC Modèle Class Model état et comportement de l'application accès/modification notification Contrôleur Vue gestion des entrées présentation dispositifs d'entrée (ex : clavier, souris) dispositifs de sortie (ex : écran) – mécanismes permettant la gestion des dépendants – mécanismes de diffusion des notifications Class View – traite l’interaction avec le modèle et le contrôleur – traite l’interaction avec les vues parentes et filles Class Controller Mise en œuvre de MVC Modèle asymétrique – une paire Contrôleur/Vue est associée à un seul Modèle – un modèle peut se voir associé plusieurs paires Contrôleur/Vue Listes de dépendants et notification – les paires Contrôleur/Vue d’un modèle sont enregistrées dans une liste de « dépendants » – lorsque le modèle change, tous les dépendants sont notifiés – permet le contrôle et la manipulation d’un modèle et d’une vue – assure qu’un unique contrôleur gère les événements utilisateur à un moment donné Conclusion sur MVC Avantages – – – – – vues multiples synchronisées vues et contrôleurs modulaires développement de composants ré-utilisables propagation naturelle du « look and feel » cohérence interne et externe des interfaces Inconvénients – complexité de communication entre les composants (principalement entre C et V) 3 Modèles à agents Présentation-Abstraction-Contrôle (PAC) Un système interactif peut être vu comme une collection d'agents Un agent PAC incarne une compétence à un niveau d’abstraction donné composé de trois facettes : Présentation (le V+C de MVC) Un agent – a un état – a une expertise – est capable d'émettre et de réagir à des événements Un interacteur est un agent en contact direct avec l'utilisateur Remarque : ces agents sont réactifs, pas cognitifs (IA) Présentation-Abstraction-Contrôle (PAC) L'interface est une structure hiérarchique d’agents PAC, de l’application à l’utilisateur application P P C A P P C A P C C C Abstraction (le M de MVC) – représente l’expertise de l’agent Contrôle (pas d’équivalent dans MVC) – fait le lien entre A et P (pas de communication directe) – gère les relations avec les autres agents de la hiérarchie Comparaison MVC/PAC Distinction entrées/sorties dans MVC mais pas dans PAC – MVC offre une meilleure souplesse/réutilisation possible de composants d’interaction sur des vues différentes, mais nécessite une communication accrue entre les objets Vue et Contrôleur A P A A – définit le comportement perceptible de l’agent (entrée/sortie) P C A C A Distinction entre "modèle" et "communication entre la vue et le modèle" – cette distinction n’est pas faite dans MVC : risque d’amalgame au niveau du modèle – dans PAC, distinction entre Abstraction et Contrôle dispositifs d'interaction 4