Modèles

d’architecture
logicielle
Modèles d'architecture

 Les modèles d'architecture définissent l'organisation

logicielle d'un système interactif.
 Le principe de base de tous ces modèles est la
séparation entre le noyau fonctionnel qui implémente
les concepts propres à un domaine d'application
particulier et l'interface qui présente ces concepts à
l'utilisateur et qui lui permet de les manipuler.
 Depuis les années 1970, différents modèles de ce type
ont été proposés. On peut les classer en deux
catégories :
 Modèles linguistiques
 modèle à base d'agents.
 I.Modèles linguistiques

 Les modèles linguistiques se basent sur une approche

linguistique de l'interaction, inspirée des architectures de
compilateurs.
1. Aspects lexicaux : ces aspects désignent tout ce qui peut être
assimilé à un vocabulaire d'entrée (clic, glisser), ou de sortie
(ensembles d'icônes).
2. Aspects syntaxiques : ils peuvent désigner des grammaires
d'entrée représentant les séquences d'actions valides, ou les
aspects spatiaux et temporels de l'affichage.
3. Aspects sémantiques : ils correspondent à la partie
fonctionnelle de l'application, qui détermine en dernier lieu le
sens d'une action et génère les erreurs.
 I.1 Modèle de Seeheim (1985)
 Seeheim est le premier modèle
d'architecture largement accepté qui
part d'une approche linguistique.
 I.1 Modèle de Seeheim (1985)
 La présentation est la couche en contact direct
avec les entrées et les sorties. Elle interprète les
actions de l'utilisateur (dispositifs physiques) et
génère les sorties (affichage) au niveau lexical.
 Le contrôleur de dialogue gère le séquencement
de l'interaction en entrée et en sortie. Il maintient
un état lui permettant de gérer les modes
d'interaction et les enchaînements d'écrans.
 L'interface du noyau fonctionnel est la couche
adaptative entre le système interactif et le noyau
fonctionnel. Elle convertit les entrées en appels du
noyau fonctionnel et les données abstraites de
l'application à des objets présentables à
l'utilisateur.
 I.2 modèle Arch - Slinky (1992)
Contrôleur de Dialogue
• Gestion des évènements
• Séquencement des actions

Adaptateur Présentation
• Functionnal Core Adapter
(Virtual Application Layer)

Interaction
Noyau Fonctionnel • Interaction Toolkit Component
•Application Functionnal Core • Physical Presentation Component
• Domain-specific component
Exemple pour une application de
traitement d’image
Contrôleur de Dialogue
• Gestion des évènements
• Listeners Swing

Adaptateur •Présentation
•ImageIcon + String ImageIcon
•CurrentIndex •JFrame + JPanel
•Layout managers

Noyau Fonctionnel Interaction

• JSlider + JList + JMenu + JPanel
ImageLibrary • look & feel
ImageItem
II. Modèles à agent

 En décomposant les interfaces en objets de même

nature, les modèles à agents sont proches des
langages à programmation objets et des interfaces à
manipulation directe modernes.
 II.1 Architecture MVC
 Le modèle MVC (Modèle, Vue, Contrôleur) [Krasner et al.,
1988] a été introduit comme architecture de référence
dans l'implémentation des interfaces utilisateurs de
l'environnement Smalltalk.
 L'approche de MVC inspirera toute une lignée de modèles
à base d'agents, dont les principales motivations sont la
modifiabilité et la conception itérative, ainsi que la
compatibilité avec les langages à objets.
 MVC décompose les systèmes interactifs en une hiérarchie
d'agents. Un agent MVC consiste en un modèle muni
d'une ou plusieurs vues et d'un ou plusieurs contrôleurs:
 Architecture MVC
 Le Modèle (Model) est responsable de la gestion de l'état du système
(son contenu actuel, la valeur de ses données).

 Il offre également les méthodes et fonctions permettant de gérer,

transformer et manipuler ces données.

 Le modèle peut informer les vues des changements intervenus dans

ses données. La communication de ces changements intervient en
général sous la forme d'événements qui seront gérés par des
contrôleurs.

 Les informations gérées par le modèle sont indépendantes de la

manière dont elles seront affichées. En fait, le modèle doit pouvoir
exister indépendamment de la représentation visuelle des données.
 Architecture MVC
 La vue (View) se charge de la représentation visuelle des informations.

 Elle utilise les données provenant du modèle pour afficher les

informations. La vue doit être informée des modifications intervenues
dans certaines données du modèle (celles qui influencent l'affichage).

 Plusieurs vues différentes peuvent utiliser le même modèle (plusieurs

représentations possibles d'un même jeu de données).

 La vue intercepte certaines actions de l'utilisateur et les transmet au

contrôleur pour qu'il les traite (souris, événements clavier, …).

 Le contrôleur peut également modifier la vue en réaction à certaines

actions de l'utilisateur (par exemple afficher une nouvelle fenêtre).
 Architecture MVC
 Le contrôleur (Controller) est chargé de réagir aux différents
événements qui peuvent survenir.
 Les événements sont constitués soit par des actions de l'utilisateur
(presser sur une touche, cliquer sur un bouton, fermer une fenêtre, ...)
ou par des directives venant du programme lui-même (un
changement intervenu dans un autre composant, l'écoulement d'un
certain temps, etc...).
 Le contrôleur définit le comportement de l'application (comment
elle réagit aux interactions).
 Dans les applications simples, le contrôleur gère la synchronisation
entre la vue et le modèle (rôle de chef d'orchestre).
 Le contrôleur est informé des événements qui doivent être traités et
sait d'où ils proviennent.
 Le contrôleur peut agir sur la vue en modifiant les éléments affichés.
Architecture MVC
The end.