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