Architecture Logicielle pour les IHM C Dumas Cedric

Architecture Logicielle pour les IHM C. Dumas Cedric. Dumas@emn. fr contrat Creative Commons Paternité-Pas d'Utilisation Commerciale. Partage des Conditions Initiales à l'Identique 2. 0 France License

Introduction • Constat – Conception d’IHM : difficile, donc nécessairement itérative – Itérativité implique modifiabilité du logiciel • Savoir-faire artisanal : acceptable pour maquettes, systèmes prospectifs (pas de besoin liés à la mise en production) • Complexité et taille croissantes des IHM – collecticiels, multimodalités, RV, RA, Universal Access, etc. . . • Outils de développement des IHM : utiles mais imparfaits – boîtes à outils : niveau d’abstraction trop bas, absence de structuration – squelettes d’applications : rétro-conception (reverse engineering) nécessaire pour réutiliser – générateurs d’IHM : le syndrôme de l’ABS (faux sentiment de sécurité) • Conséquence : besoin de cadre de pensée, c. -à-d. de modèles d’architecture

Architecture Conceptuelle • Sert à la (retro)conception

Architecture Logicielle • IEEE 1471 standard (2000) « The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution » • Autrement dit : – Une architecture : ensemble organisé de composants + des relations + des principes directeurs – Une architecture est le résutat d’un processus – L’environnement : participants (culture en qualité logicielle, outils, requis commercial… – Finalité d’une architecture • • • communication (précision et non ambiguïté de la description) rétro-conception d’un système existant évaluation (selon des critères qualité) • Dictinction entre architecture et description d’architecture Maier (2001) « architecture is a concept of a system » – Une architecture est un concept d’un système : elle existe bien que non observable – Une description d’architecture : représentation de ce concept pour une finalité donnée. C’est une entité concrète.

Architecture Logicielle • Bass (1998) « The architecture of a computing system is a set of structures which comprise software components, the externally visible properties of these components and the relationships among them » • Autrement dit : – Plusieurs points de vue sur une architecture (cf. Architecture en bâtiment) Un point de vue : une structure, sa représentation pour une finalité donnée – Propriétés d’un composant : description du comportement attendu • Services fournis ou requis, Performance, Protocole de communication – Propriétés observables de l’extérieur : un composant est • une unité d’abstraction, une unité de déploiement • un service, un module, un bibliothèque, un processus, un procédure, un objet, un agent, etc. , sont des composants – Relations -> connexion -> connecteurs (appel procédural, RMI, socket, etc. ) Composant Connecteur Composant

Architecture Conceptuelle • Sert à la (retro)conception

Architecture Conceptuelle • Sert à la (retro)conception • Séparation entre la sémantique et son utilisation – portabilité (device independant) – réutilisabilité – plusieurs interfaces (flexibilité, plateformes, etc) – personnalisation(designer, utilisateur) • Communication entre l’application et la présentation : contrôleur de dialogue – 3 composants maintenant. . .

le modèle de Seeheim 1985 Application Interface Model vue de la sémantique i est fournie pour l’interface Dialog Control Presentation Component User Application (niveau sémantique) (niveau syntaxique) (niveau lexical) bypass régule les communications • Modélise les interfaces jusque 1985 apparence de entre l’application et l’interface et E/S • optimisation Pas de du séparation en composant utilisateur feedback etours visuels, dessins et à main levée, etc) logiques implémentation

modèle Arch - Slinky 1992 • Plus de couches régulation des tâches • Plus conceptuel séquencement de l’interaction liés au modèle de tâches modèle • utilisateur modèle système adaptation aux toolkits de la plateforme visée Bienversus adapté pour la structure fonctionnelle réorganisation des données Semantic enhancement Awt, Xvt, Swing, Views Contrôleur de Dialogue Possibly adapted Domain Objects Adaptateur • Functionnal Core Adapter (Virtual Application Layer) Logical Presentation Objects transfert de modifiable structure de données portable explicites (versus efficacité) Domain Objects Domaine • Application Functionnal Core • Domain-specific component application noyau fonctionnel Présentation • Logical Presentation Component (Virtual Toolkit) Physical Interaction Objects presentation widgets look and feel Interaction • Interaction Toolkit Component • Physical Presentation Component

Agent Based Models • Modèles basés sur des agents • Système interactif = ensemble d’unités computationelles (agents) • Agent – – capacité à réagir et à gérer des événements caractérisé par un état possède une capacité d’expertise (rôle) relation utilisateur interacteur / objet d’interactif • Système interactif = agents réactifs (<> agents cognitifs) MVC, PAC, Clock, C 2, etc. . . • Modèle même principe que les précédents, avec une granularité plus fine (par collections)

modèle MVC 1987 (Smalltalk) représentation graphique View ouput devices Model Controller application semantics noyau fonctionnel gestion de l’interaction en entrée input devices user

PAC 1987 (Joëlle Coutaz) • Presentation combine Input/Output ( MVC) • Control pilote le dialogue et la cohérence entre le modèle et sa représentation ( MVC) • Communication entre agents ( MVC) • Pas lié à un environnement de programmation ( MVC), approche objet tout de même • Plus conceptuel encore (moins dépendant de l’implémentation) que MVC Presentation Abstraction Control

MVC en Java ? • JText. Field (text. Field) • JText. Area (text. List) +JScroll. Pane text. Field. add. Action. Listener(new Action. Listener() { public void action. Performed(Action. Event e) { // Append the text. Field's text to text. List. append(text. Field. get. Text()); text. List. append("n"); text. Field. set. Text(""); // Reset the text. Field } }); // ENTER key causes an Action. Event

MVC en Swing • JText. Field (text. Field) • JText. Area (text. List) • JText. Area (avg. Field) • solutions ? – listener text. Field vers avg. Field – listener text. List vers avg. Field – listener contenant la mise à jour des deux éléments text. List et avg. Field – MVC dans tout ça ? où est le modèle ?

MVC rules

list. View public class List. View extends JText. Area { public List. View(int n) {. . . } public void changed (Vector v) { // copie du vector dans le JText. Area } }

Int. Vector. Model public class Int. Vector. Model { protected Vector data = new Vector(); // gestion de la liste (add. Element, get. Data, etc. . . ) public void add. Element(int i) { data. add. Element(new Integer(i)); fire. Change(); } public Vector get. Data() { return data; }

public class Int. Vector. Model {. . . protected Event. Listener. List change. Listeners = new Event. Listener. List(); // gestion des événements public void add. Change. Listener(Change. Listener x) {. . . } public void remove. Change. Listener(Change. Listener x) {. . . } protected void fire. Change() { // Create the event: Change. Event c = new Change. Event(this); // Get the listener list Object[] listeners = change. Listeners. get. Listener. List(); // Process the listeners last to first for (int i = listeners. length. . . ) {. . . listeners[j]. state. Changed(c); . . . } }

Int. Vector. To. Listview. Adaptor private static class Int. Vector. To. Listview. Adaptor implements Change. Listener { Int. Vector. Model model; List. View view; public Int. Vector. To. Listview. Adaptor( Int. Vector. Model m, List. View v) { model = m; view = v; } public void state. Changed(Change. Event e) { view. changed(model. get. Data()); } }

La fenêtre principale public class First. MVC extends JFrame { [. . . ] List. View list. View = new List. View(5); // vue Text. Field avg. View = new Text. Field(10); // vue Int. Vector. Model model = new Int. Vector. Model(); // modèle Text. Field controller = new Text. Field(10); // contr. dans le constructeur First. MVC(). . . Int. Vector. To. Listview. Adaptor MV 2 = new Int. Vector. To. Listview. Adaptor(model, list. View); model. add. Change. Listener(MV 2);

et dans le constructeur. . . JPanel control. Panel = new JPanel(); control. Panel. add(controller); JPanel view. Panel = new JPanel(); view. Panel. add(avg. View); view. Panel. add(List. View);

MVC en Java • Modèle de façon générale : Observer/Observable dans java. util • MVC dans Swing : – JComponent = model + delegate – delegate = V + C

Observer Design Pattern • One to many

Premiers éléments de réponse à la question 1

Découpage de la question 1 • 2 vues – JLabel – JSlider • 7 contrôleurs – 6 JButtons – JSlider • 1 modèle – Gestion d’un entier

découpage JButton JLabel JButton Modèle JSlider

découpage Observable JButton Attach(Observer) Notify() Update() JLabel Modèle set. Valeur(int) get. Valeur() JSlider Observer valeur JSlider

Exo 1 Model import java. util. Observable; public class Exo 1 Model extends Observable { public int valeur=0; static int MIN_VALUE=0; static int MAX_VALUE=999; public Exo 1 Model() { valeur = 0; } public void set. Valeur(int x) { if (x < MIN_VALUE) x=MIN_VALUE; if (x > MAX_VALUE) x=MAX_VALUE; valeur = x; // notification des modifications dans la classe Observer set. Changed(); notify. Observers(); } public int get. Valeur() { return valeur; } }

JLabel (vue 1) public class Exo 1 Vue extends JLabel implements Observer { public Exo 1 Vue(String text) { super(text); } public void set. Vue(int text){ set. Text(String. value. Of(text)); } public void update(Observable obs, Object obj) { Exo 1 Model mod = (Exo 1 Model) obs; // prendre la bonne habitude de tester la compatibilité des types if (obs instanceof Exo 1 Model) set. Vue(mod. get. Valeur()); } }

JSlider (vue 2) public class Exo 1 Controller. Slider extends JSlider implements Observer { // set. Value et get. Value sont les accesseurs de JSlide pour récupérer/modifier la valeur du slider Exo 1 Model model = null; public Exo 1 Controller. Slider(Exo 1 Model mod) { model = mod; // initialisation des valeurs du slide […] // gestion d'évènements add. Change. Listener( new Change. Listener() { public void state. Changed(Change. Event chev) { model. set. Valeur(get. Value()); }; }); } public void update(Observable obs, Object obj) { Exo 1 Model mod = (Exo 1 Model) obs; // prendre la bonne habitude de tester la compatibilité des types if (obs instanceof Exo 1 Model) set. Value(mod. get. Valeur()); } }

JButton (controlleur 1) public class Exo 1 Controller. Boutons extends JButton { int base_value=0; Exo 1 Model model=null; void set. Base(int i) { base_value=i; } int get. Base() { return base_value; } public Exo 1 Controller. Boutons(Exo 1 Model mod, int bv) { model=mod; // base_value contient le pas de l'incrément des boutons set. Base(bv); // on construit le titre String base_str = Integer. to. String(bv); if (bv > 0) base_str = "+"+base_str; set. Text(base_str); add. Action. Listener( new Action. Listener() { public void action. Performed(Action. Event e) { model. incremente(base_value); } }); }

class Exo 1 Fenetre extends JFrame{ Exo 1 Model model = new Exo 1 Model(); public Exo 1 Fenetre(){ set. Title("TP MVC - Exo 1"); JPanel p = new JPanel(); p. set. Layout(new Border. Layout()); get. Content. Pane(). add(p); // initialisation des boutons JPanel q = new JPanel(); q. set. Layout(new Grid. Layout (3, 2)); p. add(q, Border. Layout. WEST); // boutons des unités Exo 1 Controller. Boutons cb; cb = new Exo 1 Controller. Boutons(model, 1); q. add(cb); […] // initialisation de la vue Exo 1 Vue vue = new Exo 1 Vue("0"); p. add(vue, Border. Layout. CENTER); // intialisation du slider Exo 1 Controller. Slider cslider = new Exo 1 Controller. Slider(model); p. add(cslider, Border. Layout. EAST); // ajout des connections entre le modèle et les vues pour que ces dernières soient mises à jour model. add. Observer(cslider); model. add. Observer(vue); }