Chapitre III : Modèles & architectures

1. Le Contrôleur de dialogue ( définition & rôle).

1. Qu'est-ce que le dialogue ?
2. Le contrôleur de Dialogue
3. Caractéristiques d'un contrôleur de dialogue
2. Les Modèles d'architecture:
1. Architecture fondamentale
2. Le modèle de Seeheim
3. Le modèle à agents
4. Le modèle MVC
5. Le modèle PAC
 1. Le Contrôleur de dialogue
1.1. Qu'est-ce que le dialogue ?

• Définition 1 : Le dialogue est l'ensemble des échanges entre un utilisateur et

une machine.
Le terme échange regroupe ici des notions telles que les manipulations
avec un écran tactile ou l’utilisation d'un microphone, d'un scanner, etc.

• Définition 2 : Le dialogue est l'ensemble des interactions produites par un

humain sur un ordinateur.
Une interaction est une action qui provoque une réaction perceptible. Elle
regroupe des notions telles que les clics souris, la frappe de touches, les
pressions sur un écran tactile, etc. Cette définition est la plus courante en
matière d'IHM.
 1. Le Contrôleur de dialogue
1.1. Qu'est-ce que le dialogue ?

• Définition 3 : Le dialogue est l'utilisation du

langage naturel pour travailler sur un ordinateur.
• Cette définition restrictive ne s'applique qu'au
domaine de recherche sur le langage naturel.
Le but de cette recherche est de parvenir à
travailler avec une machine par l'intermédiaire
d'ordres énoncés dans la langue de tous les
jours, l'ordinateur répondant également dans
cette langue.
• Il peut se faire de plusieurs façons : écrite,
orale ou les deux à la fois.
 1. Le Contrôleur de dialogue
1.2. Le contrôleur de Dialogue
• Nous appelons Contrôleur de Dialogue le module (ou l'ensemble des modules)
dédié au dialogue. Ce module a deux rôles principaux : l’analyse et le contrôle du
dialogue.

a. L'analyse du dialogue
• On distingue trois types d'analyse : lexicale (gestion des E/S, affichage,
interaction), syntaxique (traitement et séquencement du dialogue) et
sémantique (analyse des concepts manipulables par l'application).
• La plupart des modèles d'application que nous verrons plus loin associent
chacune des analyses à un module, parfois même les regroupe dans un seul.
 1. Le Contrôleur de dialogue
1.2. Le contrôleur de Dialogue
b. Le contrôle du dialogue
• Le contrôle correspond à la validité des déclenchements des opérations
qui dépend du contexte (les données, les traitements antérieurs, etc.).
• Le contrôle du dialogue signifie également la gestion des enchaînements
des opérations suite aux interactions de l'utilisateur.
• En résumé le contrôleur de dialogue a pour fonction de vérifier la validité
des interactions et de gérer les enchaînements de traitements qui en
découlent.
 1. Le Contrôleur de dialogue
1.2. Le contrôleur de Dialogue
b. Le contrôle du dialogue
• Exemple:
Un bouton non grisé signifie que son déclenchement est possible et inversement
un bouton grisé signifie que son déclenchement est impossible. Dans les deux
cas, l'interface a été informée de la présentation à donner au bouton. Le
contrôleur a pu décider de cette information en fonction des données et des
opérations antérieures (puisque le contrôleur est chargé principalement de gérer
les enchaînements de tâches).
Le fait d'avoir achevé une opération permet d'en exécuter d'autres et ceci doit se
répercuter à l'écran par exemple en rendant un menu, un bouton ou une zone
de saisie accessibles. Il est donc intéressant que le contrôleur connaisse les
enchaînements nécessaires pour atteindre les buts.
 1. Le Contrôleur de dialogue
1.3. Caractéristiques d'un contrôleur de dialogue
• Le développement des TIC a permis à un public de plus en plus nombreux,
mais surtout de plus en plus varié, de manipuler des logiciels.
• La diversité de ce public a obligé les concepteurs à prendre en compte tous
les types de public au sein d'une même application alors qu'auparavant
c'était le public qui s'adaptait au logiciel.
• La gestion du dialogue homme-machine est donc devenu un travail à part
entière et doit respecter certaines propriétés d'ordre général qui
permettent de définir un bon contrôleur de dialogue.
• En plus des critères classiques du génie logiciel, i.e. extensibilité,
réutilisabilité, etc. un contrôleur de dialogue doit répondre aux critères
suivants:
 1. Le Contrôleur de dialogue
1.3. Caractéristiques d'un contrôleur de dialogue
Flexibilité : à cause de la diversité de compétence du public, le contrôleur doit pouvoir fournir
des types de dialogue différents en fonction du type du public.
Par exemple un débutant n'utilisera que les menus alors qu'un expert utilisera de
préférence les raccourcis clavier ou les touches de fonction.
Adaptabilité : le contrôleur de dialogue doit être capable de s'adapter au niveau et au style de
son interlocuteur. Deux types de solutions sont possibles : soit plusieurs styles sont
directement implémentés dans le système et celui-ci en choisit un en fonction de l'utilisateur,
soit il n'y a que des règles de style et c'est en fonction de l'utilisateur que le contrôleur les
applique ou non.
Exemple: systèmes tutoriels intelligents qui sont capable de reconnaître le niveau des
élèves et se mettre à leur niveau, donc s’adapter.
Intégrité : le contrôleur de dialogue doit être capable de protéger le système contre des accès
ou des modifications non autorisés. C'est une des propriétés fondamentales d'un contrôleur
de dialogue.
 1. Le Contrôleur de dialogue
1.3. Caractéristiques d'un contrôleur de dialogue
Recouvrement : il doit être possible de récupérer des erreurs faites durant une session de dialogue
avec relativement peu d'efforts. Exemple:
La fonction défaire/refaire (Undo/Redo) que l'on trouve de plus en plus dans les IHM est
l'exemple le plus frappant.
La fonction qui permet de conserver l’historique des actions qui ont été exécutées depuis le
début d’une session. Il est donc possible dans certains cas de défaire une action et
d'annuler toutes celles qui ont suivi.
Partage : à partir d'une même structure de contrôle de dialogue, il doit être possible de travailler
simultanément sur plusieurs tâches d'une même application. On parle alors de dialogues multi-fil.
Robustesse : elle représente l'aptitude du contrôleur de dialogue à fonctionner dans des conditions
anormales. Ceci implique la gestion des erreurs prévisibles telles que les erreurs d'intention et
d'exécution et celle des erreurs imprévisibles telles que les interruptions de tâches, etc.
2.Modèles d'architecture
 2.Modèles d'architecture
• Une architecture logicielle (Modèles d'architecture) décrit d’une manière
symbolique et schématique les différents élément d’un ou plusieurs systèmes
informatiques, leurs interrelations et leurs interactions.

• Principe fondamental : séparation entre interface et noyau fonctionnel

(ensemble des services propres à une application).

• Différents modèles :
• Modèle fondamentale
• modèle de Seeheim
• Modèle-Vue-Contrôleur (MVC)
• Présentation-Abstraction-Contrôle (PAC)
• Etc.
 2.1. Architecture fondamentale

• Le noyau fonctionnel : Il doit fournir un minimum des services dans le cadre d'une
interface :
Notification : possibilité pour un module externe d'être prévenu lorsque l'état du
noyau sémantique change (données et traitements),
Prévention des erreurs : possibilité de savoir si un appel de fonction est licite dans
un certain contexte, (pas avec des exceptions (c'est trop tard !), fonctions de test
(accepté, refusé))
Annulation : possibilité de revenir à des états antérieurs du noyau sémantique
(annulation d'une transaction en BD, Historique).
 2.2. Le modèle de Seeheim
Le modèle de Seeheim est le premier modèle qui a mis en valeur le contrôleur de
dialogue par l'intermédiaire de la séparation d'une application en trois modules.
Rôle historique: modèle logicielle permettant de remplacer les interfaces
textuelles en interfaces graphiques sans changer le noyau fonctionnel.
Ce modèle a pour but de distinguer la gestion du dialogue de la sémantique de
l'application.
Il est composé de trois modules qui sont greffés sur le noyau applicatif. Chacun
de ces modules est distinct des autres et possède des rôles bien déterminés.
2.2. Le modèle de Seeheim

Définit le comportement du système

tel qu’il est perçu par l’utilisateur.

Médiateur entre l’interface du noyau

fonctionnel et la présentation

Décrit la sémantique de l’application du

point de vue de l’interface utilisateur.
 2.2. Le modèle de Seeheim

La présentation: qui est responsable de la gestion purement lexicale de

l'application (i.e. gère les E/S, affichage, interaction). Son rôle est de :
Gérer la présentation et l'affichage des entités manipulées. Elle doit donc
répondre aux critères d'ergonomie et de facilité d'apprentissage
(utilisabilité) d'une application. Sa qualité influence en partie l'utilité de
l'application puisque c'est par elle que transitent tous les résultats.
Gérer les événements physiques d'entrée/sortie. Elle est chargée de
“traduire les informations entre le format du monde réel extérieur et celui
du monde informatique intérieur”.
La présentation est donc chargée de la gestion de la représentation externe
de l'application.
 2.2. Le modèle de Seeheim
Le contrôleur de dialogue qui est le médiateur entre l'utilisateur et l'application,
c'est-à-dire entre la présentation et l'interface de l'application. Son rôle est de :
contrôler les échanges au niveau syntaxique (traitement et séquencement du
dialogue), et gérer la dynamique du dialogue.
responsable de la coordination entre l'affichage (présentation) et l'état
d'avancement des traitements.
L'interface de l'application qui est une couche reliant les fonctions et données
du noyau fonctionnel aux données et actions de l'interface. Elle a pour rôle de :
relier le noyau fonctionnel et le module de contrôle du dialogue en faisant
appel aux procédures de l'application.
convertir les informations issues du contrôleur de dialogue en concepts
manipulables par l'application. L'interface de l'application doit également
savoir comment sont structurés les services de l’application et comment les
utiliser. En d'autres termes, elle doit connaître la sémantique de l'application.
 2.2. Le modèle de Seeheim

L'implémentation de ce modèle présente des difficultés puisque les rôles des

modules ne sont pas suffisamment explicites.
Il ne correspond pas dans l'absolu au modèle de programmation objet et
événementiel puisque ces derniers prônent une répartition du contrôle entre
les objets qui sont manipulés.
C'est pourquoi ce modèle a donné naissance à plusieurs modèles que nous
verrons plus loin ainsi qu'à des versions “améliorées” (exemples : “Seeheim
modifié”, “Seeheim étendu”).
 2.3. Le modèle à agents
Introduction aux Agents / SMA
Un Agent est une entité
• Qui agit d’une façon autonome pour atteindre les objectifs pour lesquels il a été conçu.
• Peut communiquer avec d’autres agents
• Doté de capacités semblables aux être vivants
• Un agent peut être un processus, un serveur, un robot, un être humain, etc…

Proprieties d’un Agent

Réactivité : Percevoir l’environnement et répondre, en temps réel, aux changements
Pro activité : Capacité de prendre l’initiative / comportement orienté but
Sociabilité: Capacité d’interagir avec d’autres agents ou utilisateurs
Autonomie : Capacité d’agir sans l’intervention humaine directe
 2.3. Le modèle à agents

Un système multi-agent (SMA) est un

système distribué :
Composé d'un ensemble d'agents
distribués,
Situés dans un certain environnement
et Interagissant selon certaines
organisations.
Un SMA permet de résoudre des
problèmes complexes en exploitant
l’intelligence collective des agents qui le
composent
 2.3. Le modèle à agents
Discipline du SMA
 2.3. Le modèle à agents
Modèles à base d’agents
• Le modèle de Seeheim a l'inconvénient majeur d'être un système centralisé.
• Le modèle multi-agent est un système réparti en fonction des agents qui le
composent. Son fonctionnement est basé sur le principe des stimuli-réponses et les
communications entre agents s'établissent au moyen d'événements.
• Un agent est composé :
• de récepteurs qui reçoivent les événements issus des autres agents. Les
récepteurs peuvent être accompagnés de filtres afin de n'être sensibles qu'à
certains types d'événements,
• d'émetteurs qui transmettent des événements typés au système et non pas à un
agent particulier,
• de mémoires pour enregistrer les événements détectés et pour mémoriser l'état
de l'agent,
• d'un processeur qui traite les événements.
 2.3. Le modèle à agents
Fonctionnement général d'un système multi-agent

• Un événement est détecté et capté par tous les agents dont les récepteurs actifs
à cet instant sont capables de l'intercepter.
• Cet événement est ajouté à la file d'attente de chaque agent qui l'a détecté.
• Quand vient son tour, le traitement de l'événement provoque un changement
d'état de l'agent qui peut alors à son tour émettre de nouveaux événements.
• Grâce à ce type de fonctionnement, il est possible de travailler en dialogue multi-
fil en associant à chaque fil un agent spécifique à une partie du dialogue. On
dispose ainsi d'un système, supportant le parallélisme, à contrôle réparti et non
plus centralisé dans un seul composant.
 2.3. Le modèle à agents
Mise en œuvre d’un modèle à agents

• Les caractéristiques des systèmes multi-agent permettent une bonne implémentation en

langage orienté objet.
• Un type d'agent correspond une classe dont les attributs représentent les mémoires des
agents ; les opérations de traitement des événements sont stockées sous la forme de
méthodes, et la communication par événements est remplacée par l'envoi de messages.
• La faculté d'instanciation et d'héritage des langages objet permet de créer
dynamiquement des agents, donc d'avoir un système évolutif, ainsi que de spécialiser
des agents par rapport à d'autres agents. Cette similitude entre langage objet et multi-
agent provient des propriétés de modularité et de coopération des langages objet. Un
objet est considéré en effet comme une entité autonome tout comme l'est un agent. Par
ailleurs la communication par messages (ou par événements pour les agents) permet de
faire dialoguer entre elles des entités.
• Le concept d'agent a été utilisé dans plusieurs modèles, par exemple MVC et PAC.
 2.4. Le modèle MVC

• MVC est le modèle multi-agent utilisé par

Smalltalk (Langage de programmation).
• Le but de ce modèle est d'avoir un système qui
soit composé d'un ensemble de triplets
autonomes et pouvant communiquer entre
eux.
• Il impose la séparation entre données,
traitements et présentation.
 2.4. Le modèle MVC
Il est composé de trois éléments qui sont :
Le Modèle : est la structure de données que l'on veut représenter à l'écran et
qui est composée d'objets.
La Vue : est la représentation externe du Modèle. C'est par elle que
l'utilisateur perçoit le Modèle (inputs) et que le Modèle reflète ses
changements (outputs). Grâce à la séparation des données et de leur
représentation, un Modèle peut avoir plusieurs vues différentes alors qu'une
Vue ne peut être associée qu'à un seul Modèle.
Le Contrôleur: qui régule les interactions entre la Vue et le Modèle. Il est
chargé de gérer les actions de l'utilisateur sur la Vue. Lorsque l'utilisateur
manipule la Vue, le Contrôleur informe le Modèle des interactions faites. Ce
dernier modifie alors son état et informe la Vue du nouvel aspect qu’elle doit
prendre suite à cette modification.
 2.4. Le modèle MVC

Principes :
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.
Un client envoie une requête à l'application,
celle-ci est analysée par le contrôleur, qui
demande au modèle approprié d'effectuer les
traitements, puis renvoie la vue adaptée si le
modèle ne l'a pas déjà fait.
 2.4. Le modèle MVC

Application web à base MVC:

Contrôleur:
Gestion des évènements
Traitement des requêtes GET/POST

Modèle Vue
Gestion des données Interface utilisateur
Requêtes SQL HTML, JavaScript, XML
Lecture/écriture des fichier
 2.4. Le modèle MVC
Le modèle MVC permet a priori de travailler de manière modulaire impliquant
ainsi une relative clarté et réutilisabilité dans le code de l'application.
Utilisé dans des plusieurs plateformes, par exemple: Excel, Swing, applications
web (.Net, aspx, JSP/Servlets/EJBs etc…),…
Avantage:
• vues multiples synchronisées,
• vues et contrôleurs modulaires,
• développement de composants réutilisables,
• cohérence interne et externe des interfaces.
• Séparer dans le code: les données (le Modèle), la ou les Vues, le Contrôle,

Inconvénient: complexité de communication entre les composants

 2.4. Le modèle MVC
Exemple: une application java basée sur le modèle MVC pour afficher un objet de
type Etudiant.

Le modèle:
public class Student {
private String id;
private String name;

public String getId() { return id; }

public void setId(String id) { this.id = id; }

public String getName() { return name; }

public void setName(String name) { this.name = name; }

}
 2.4. Le modèle MVC

La vue:

public class StudentView {

public void printStudentDetails(String studentName, String studentId){
System.out.println("Student: ");
System.out.println("Name: " + studentName);
System.out.println("ID: " + studentId);
}
}
 2.4. Le modèle MVC
Le contrôleur:
public class StudentController {
private Student model;
private StudentView view;
public StudentController(Student model, StudentView view){
this.model = model;
this.view = view;}
public void setStudentName(String name){model.setName(name);}
public String getStudentName(){return model.getName();}
public void setStudentId(String id){model.setId(id);}
public String getStudentId(){return model.getId();}
public void updateView(){
view.printStudentDetails(model.getName(), model.getId());}
}
 2.4. Le modèle MVC
La classe principale (avec méthode main):
public class MVCStudentModel {
public static void main(String[] args) {
//fetch student record based on his id from the database
Student model = retriveStudentFromDatabase();
//Create a view : to write student details on console
StudentView view = new StudentView();
StudentController controller = new StudentController(model, view);
controller.updateView();
//update model data
controller.setStudentName("Amina");
controller.updateView();}
private static Student retriveStudentFromDatabase(){
Student student = new Student();
student.setName("Amine");
student.setId("20");
return student;}
}
 2.5. Le modèle PAC
PAC (Présentation Abstraction Contrôle) est un
modèle multi-agent dont chaque agent est
responsable d'un aspect spécifique des
fonctionnalités de l'application et se compose de
trois composants: présentation, abstraction et
Un agent PAC
contrôle.
• La Présentation (le V+C de MVC) qui est l'image que perçoit l'utilisateur de l’agent.
correspond à la Représentation Externe de l’agent,
définit le comportement perceptible de l'agent et l'interaction avec l'utilisateur,

• L'Abstraction (le M de MVC) qui est l'ensemble des concepts et des fonctions de
l’agent.
définit donc les fonctionnalités sémantiques de l’agent,
représente l'expertise de l'agent, gère les données à représenter,
 2.5. Le modèle PAC

Le Contrôle (pas d'équivalent dans MVC), il maintient la cohérence entre la

Présentation et l'Abstraction.
Il établit un lien entre ces deux parties tout en jouant un rôle d'arbitre pour
résoudre les conflits, les synchronisations, les rafraîchissements, etc.,
Il a rôle de traducteur puisque les trois composants s'échangent des informations
qui peuvent avoir des formats différents.
correspondance entre l’Abstraction et la Présentation (cohérence des
représentations avec les données internes, conversion des actions de l'utilisateur
en opérations du noyau fonctionnel) et gère les relations avec les autres agents PAC
de la hiérarchie.

Un objet PAC interactif simple est composé d'une image qui définit le comportement
visible par l'utilisateur (Présentation) des fonctions qu'il utilise (Abstraction), et d'un
module pour gérer la connexion entre ces deux modules (Contrôle).
 2.5. Le modèle PAC

Une application basée sur le modèle PAC est

constituée d'un ensemble d'agents PAC structurés
hiérarchiquement et de manière récursive (Figure).
Un agent PAC peut ainsi être décomposé en un
ensemble d'agents PAC.
Dans la figure, l'objet le plus haut dans
l'arborescence correspond aux trois parties
principales de l'application, les sous-niveaux étant
des objets intermédiaires et les feuilles étant les
objets directement manipulables les plus
élémentaires que l'on puisse avoir. Un objet père
hérite des Présentations de ses fils et non l'inverse.

Un Agent PAC Complexe

2.5. Le modèle PAC
 2.5. Le modèle PAC

L'exemple classique d'une architecture PAC est un

système de contrôle du trafic aérien.
Un agent PAC prend les entrées d'un système
radar sur l'emplacement d'un 747 entrant et
utilise le composant Présentation pour peindre
une image de ce spot sur l’écran.
Un autre agent prend indépendamment des
informations sur un DC-10 qui décolle et peint
également ce spot sur l’écran.
Un autre encore prend des données
météorologiques et peint des nuages, tandis
qu'un autre suit le bombardier ennemi entrant et
peint une tache rouge.
Etc.
 Références

• Jean-Claude Tarby. Gestion Automatique du Dialogue Homme-Machine à partir

de Spécifications Conceptuelles. Interface homme-machine [cs.HC]. Université
des Sciences Sociales - Toulouse I, 1993.
• Philippe Renevier, "Architecture logicielle", cours M1 informatique-option IHM,
UNSA
• Christian Nguyen, "Les interfaces graphiques: Principes et normes" cours de
département d'informatique, Université de Toulon et du Var
• https://www.tutorialspoint.com/software_architecture_design/interaction_orien
ted_architecture.htm