Styles interactifs - MVClamontagne/glo3001/09-MVC.pdf · •Isoler la présentation de la logique du système 2. Model-View-Controller ... • Plusieurs composants utilisent une classe

Styles architecturaux

Styles interactifs - MVC

GLO-3001

Architecture logicielle

Luc Lamontagne

Hiver 2010

Model-View-Controller

• Architecture pour les interfaces humain-machine

• Séparation des préocupations• Données• Présentations• Traitements• Gestion des événements

• Isoler la présentation de la logique du système

2


• Problème– Interface utilisateur

– souvent modifiée ou enrichie

– demandes de modification par les utilisateurs

– Différents utilisateurs = différents besoins

– Plusieurs paradigmes d'interface

– Liaison directe de l'interface au système – Complexe !

– Maintenir une grande flexibilité– difficile et coûteux

3


• Modèle proposé par Trygve Reenskaug• Travaux sur Smalltalk à Xerox Parc

• Divise une application interactive en 3 composantes– Le modèle

• Contient les données ainsi que les fonctionnalités du système

– Les vues• Présentent les données du modèle à l'utilisateur

– Les contrôleurs• Gèrent les entrées et les événements du système

4


5


• Structure– Modèle

• Représente le comportement de l’application• Traitement de données, interaction avec la base de données, etc...

• Contient les données manipulées par l’application• Si une base de données, elle est dans cette composante

• Offre des services permettant l’accès aux données exposées• Insertion, suppression, modification, récupération des données

• Offre des services permettant l’exécution de fonctionnalités du système

• Journalisation, authentification, traitement des données

• Peut donner une vue partielle des données• Par ex. Tous les modèles d’autos, ceux par années ou par région.

• Implante un mécanisme de notification des vues et des contrôleurs

– Les vues et les contrôleurs s'enregistrent auprès du modèle afin d'être avertis des modifications de l'état

6


– Vues • Correspond à l’interface avec laquelle l’utilisateur interagit• Présente les résultats retournés par le modèle• Reçoivent les actions de l’utilisateur

• Clic de souris, sélection d’une entrée, boutons

• Génèrent des événements lors de l'interaction avec l'utilisateur

– Les événements sont transmis au contrôleur responsable

• Lors de changement de l'état du modèle, les vues récupèrent et présentent les nouvelles données

• N’effectuent aucun traitement• Plusieurs vues possibles pour un même modèle

• Affichage de statistiques sous forme de tableau vs. graphique

7


– Contrôleurs • Gèrent les événements du système

• Habituellement associés à une vue particulière

– Traduisent les événements en requêtes de services – Requêtes au modèle Fonctionnalités / Modification de l’état

– Requêtes aux vues Modification de la présentation

• Ils sont responsable du comportement visuel de l'application

• Ils déclenchent les fonctionnalités du système qui sont implantées par le modèle

• Ils n’effectuent aucun traitement...• Aucune modification de données

• Aucune logique de l’application

8


• Forces à équilibrer– La même information peut être présentée différemment

– La présentation et le comportement de l'application doivent refléter les changements de l'état des données du système immédiatement

– Les changements de l'interface utilisateur devraient être facile gérer

– La modification ou le remplacement de l'interface utilisateur devrait être facile• Et même possible à l'exécution

– La modification ou le remplacement de l'interface utilisateur ne devrait pas affecter le système

9


• Solution– On divise le système en 3 régions

• Les entrées (les contrôleurs)• Les sorties (les vues)• Les traitements (le modèle)

– Le modèle encapsule les données et les fonctionnalités du système• Il est indépendant du comportement des entrées ou de la représentation des

sorties du système• Il ne gère pas les comportements interactifs de l'application

– Les vues présentent les informations à l'utilisateur• Une vue obtient les données depuis le modèle • Il est possible d'avoir plusieurs vues pour un même modèle

10


– Les contrôleurs reçoivent des entrées et les événements des vues• Chaque vue est associée à un contrôleur • Les événements sont traduis en des appels de services au modèle ou à la vue

associée

– L'architecture Model-View-Controller permet plusieurs vues simultanées du même modèle

– Nécessite un mécanisme de notification (Observer)• Tout changement du modèle doit se refléter dans toutes les vues qui

dépendent des données modifiées• Lors d'un changement de l'état des données, le modèle notifie toutes les vues

attachées qu'un changement a eu lieu• Les vues récupèrent alors les nouvelles données et mettent à jour la

présentation

11


12


13


• Initialisation du système

14


• Traitement des événements– L’événement est capté par un contrôleur

• Une vue ou le système en est la source

15


• Implantation1. Séparer les interactions humain-machine des

fonctionnalités de l'application• Analyser l’application et distinguer

– Les fonctionnalités du système

– Les comportements interactifs du système

2. Concevoir le modèle• Encapsuler les données et les fonctionnalités requises

• Fournir une interface suffisamment complète – Accès aux services

– Accès aux données exposées

16


3. Implémenter le mécanisme de propagation des modifications• Observer

– Le modèle = Le sujet (Observable) – Les vues et les contrôleurs = Observateurs (Observers)

• Toutes les procédures de services du modèle qui modifient son état doivent déclencher la notification des observateurs enregistrés

• Mode Push vs Pull– Le mode push offre l'avantage de permettre de cibler la nature de la

modification

4. Concevoir et implanter les vues• Procédure d’affichage et de rafraîchissement • Procédure d’acquisition des données du modèle• Procédure d'initialisation

– Attache la vue au modèle – Crée le contrôleur pertinent

• Procédures de notification (callback)– Optimisation possible Retardement des mises à jour

17


5. Concevoir et implanter les contrôleurs• Spécifier le comportement du système en réponse aux

événements et aux actions de l'utilisateur• Procédure d'initialisation

– Attache le contrôleur au modèle et à la vue associée

• Procédure de notification (handler ou callback)– Le contrôleur réagit aux changements d'état du modèle

6. Concevoir et implanter la relation Vue-Contrôleur• Une vue crée sont contrôleur lors de l'initialisation• Prévoir la possibilité d’utiliser des contrôleurs interchangeables

– Le patron Factory permet d'utiliser différents contrôleurs – Contrôleurs implantant des comportements différents pour une même

vue» Novice, Expert, Lecture-seule, …

18


7. Implanter la procédure de démarrage du système

• Procédure d’initialisation– Initialise le modèle

– Crée et initialise les différentes vues

– Lance la boucle de traitement des événements

19


• Exemple en Java – Swing• Plusieurs composants utilisent une classe spécifique

pour contenir les données• Boutons (JButton) ButtonModel pour les données

• Curseurs (JSlider) BoundedRangeModel pour les données

• Listes (JList) ListModel pour les données ListSelectionModel pour gérer les sélections

• Tableaux (JTable) TableModel et TableColumnModel pour les données ListSelectionModel pur gérer les sélections

20


• Plusieurs variantes du MVC…

21


• Web MVC

22

FrontController

Contrôleur

Vue Modèle


• Web MVC– Ajout d’un front controller

• Gère toutes les requêtes HTTP au serveur• Souvent un servlet en Java• Choisi un contrôleur et lui délègue la requête

– Contrôleur• Effectue les opérations sur le modèle• Mise à jour de la vue pour chaque requête

– Pas d’observateur (stateless)

– Modèle• Même rôle que dans le MVC standard

23

FrontController

Contrôleur

Vue Modèle


• Web MVC

24


• Web MVC

25


• Avantages– Permet d'avoir plusieurs vues pour un même

modèle

– Permet la synchronisation des vues• Les changements du modèle sont propagés à toutes les

vues

– Permet de remplacer les vues et les contrôleurs• Même à l'exécution

– Facilite le transfert de l'application vers une plate-forme différente

26


• Inconvénients– Augmente la complexité– Peut générer des cascades d'événements et de mises à jour– Peut générer un nombre très élevé de mises à jour des vues– La séparation vue-contrôleur est rarement exploitée– Implique un couplage fort des vues et des contrôleurs au modèle

• Des modifications de l'interface du modèle amènent des modifications de toutes les vues et contrôleurs

– Accès inefficace aux données par les vues• Parfois plusieurs appels au modèle sont nécessaires• En mode pull, les vues doivent accéder à toutes les données, même celles qui

n'ont pas été modifiées

– Peut être difficile à mettre en place avec certaines bibliothèques graphiques de haut niveau

27

Model-View-Controller - Exemple

• Système de gestion de la température d’une pièce– Le modèle

• Encapsule la gestion de la température de la pièce• Offre des services de lecture et d’écriture de la température en Celsius et en

Fahrenheit

– Les vues• Formulaire permettant d’augmenter et de diminuer la température• Formulaire présentant des jauges de la température dans les deux unités de

mesure

– Les contrôleurs• Classes internes aux vues

– On n’exploite pas la possibilité d’avoir différents contrôleurs pour une même vue– Approche de Java Swing

28

Model-View-Controller - Exemple/**

* Model

*/

public class TemperatureModel extends Observable {

private double temperatureFarenheit = 32.0;

public double getFahrenheit() {

return this.temperatureFarenheit;

}

public void setFahrenheit(double farenheit) {

if (farenheit < 32) {

farenheit = 32;

}

if (farenheit > 95) {

farenheit = 95;

}

this.temperatureFarenheit = farenheit;

setChanged();

notifyObservers();

}

// ...

29


// ...

public double getCelsius() {

return (temperatureFarenheit - 32.0) * 5.0 / 9.0;

}

public void setCelsius(double celcius) {

setFahrenheit(celcius * 9.0 / 5.0 + 32.0);

}

}

30


/**

* Form

*/

public class TemperatureFormView extends javax.swing.JFrame implements Observer {

private TemperatureModel model;

public TemperatureFormView() {

initComponents();

}

/*

* Initialization

*/

public void init(TemperatureModel model) {

this.model = model;

model.addObserver(this); // Connect to the view

update(model, null);

}

/*

* Callback

*/

public void update(Observable o, Object arg) {

setValeur(getModel().getFahrenheit());

}

// ...

31

Model-View-Controller - Exemple// ...

private void initComponents() {

// ... //

}

// Code for dispatching events from components to event handlers

private class FormListener implements InputMethodListener, MouseListener {

public void inputMethodTextChanged(InputMethodEvent evt) {

if (evt.getSource() == textFieldValeur) {

TemperatureFormView.this.textFieldValeurInputMethodTextChanged(evt);

}

}

public void mouseClicked(MouseEvent evt) {

if (evt.getSource() == buttonAugmenter) {

TemperatureFormView.this.buttonAugmenterMouseClicked(evt);

}

else if (evt.getSource() == buttonDiminuer) {

TemperatureFormView.this.buttonDiminuerMouseClicked(evt);

}

}

// ... //

}

// ...

32


// ...

private void textFieldValeurInputMethodTextChanged(InputMethodEvent evt) {

getModel().setFahrenheit(getValeur());

}

private void buttonAugmenterMouseClicked(MouseEvent evt) {

getModel().setFahrenheit(getModel().getFahrenheit() + 1.0);

}

private void buttonDiminuerMouseClicked(MouseEvent evt) {

getModel().setFahrenheit(getModel().getFahrenheit() - 1.0);

}

}

33


public class Main {

public static void main(String[] args) {

setLAF();

TemperatureModel model = new TemperatureModel();

TemperatureFormView viewF = new TemperatureFormView();

viewF.init(model);

viewF.setVisible(true);

TemperatureGaugesView viewT = new TemperatureGaugesView();

viewT.init(model);

viewT.setVisible(true);

TemperatureSliderView viewS = new TemperatureSliderView();

viewS.init(model);

viewS.setVisible(true);

}

}

34

Documents

Styles interactifs - MVClamontagne/glo3001/09-MVC.pdf · •Isoler la présentation de la logique du système 2. Model-View-Controller ... • Plusieurs composants utilisent une classe