14. Que dit-on de l’IHM ?
(c) 2015, Occello Audrey, POO/IHM - 14 -
Pour les utilisateurs (Socio ergo)
• "Le produit c’est l’IHM" (J. Raskin)
Pour ceux qui développent les produits (AL)
• "80% du code des systèmes interactifs est consacré à l'interface
utilisateur" (L. Nigay)
Pour ceux qui financent les produits (Marketing)
• "63% des gros projets informatiques connaissent des
dépassements de coûts" (S. Greenberg)
15. Les défauts des informaticiens
(c) 2015, Occello Audrey, POO/IHM - 15 -
Focus sur les fonctions du système
Traitement de l’interface en dernier
IHM = coté "cosmétique" du produit
Hypothèse que tous les utilisateurs leur ressemblent
Pas de communication avec des utilisateurs
16. Risques
(c) 2015, Occello Audrey, POO/IHM - 16 -
Rejet pur et simple par les utilisateurs
Coût d'apprentissage/formation
Perte de productivité (hésitations, coup d’oeil à la doc)
Utilisation incomplète
Coût de maintenance (évolutivité de l’IHM)
Perte de crédibilité (réputation % satisfaction des clients)
Perte de parts de marché
17. Utile vs utilisable
(c) 2015, Occello Audrey, POO/IHM - 17 -
Réaliser des logiciels utiles et utilisables
• Adéquation entre les fonctionnalités proposées et les besoins des
utilisateurs : capacité fonctionnelle pour l’utilisateur d'atteindre ses
buts de haut niveau
• Adéquation entre l’interface et les utilisateurs : facilité
d’apprentissage et d’utilisation
• L'utilisabilité sert à poser la frontière entre
l'utilité potentielle et l'utilité réelle
18. Comment ? Cette année…
(c) 2015, Occello Audrey, POO/IHM - 18 -
http://atelierihm.unice.fr/ens eignements/pooihm/
Plan et orientation pédagogique du module
•IHM en SWING - initiation au savoir faire :
accent sur l’usage – application DEVINT
•IHM pour applications mobile : initiation
à Android – TP fil rouge
• IHM web : initiation pour le projet SI3
Intervenants et fonctionnement
Cours : Am Dery
Suivis projets et TP : C. Camilieri, O. ….,
Mode d’évaluation :
1 rapport MVC, 1 devoir sur table, 2 démonstrations argumentées
19. Cycle de vie et périmètre du module
(c) 2015, Occello Audrey, POO/IHM - 19 -
Analyse des besoins
Conception
Conception logicielle
Codage
Tests Unitaires
Tests d’intégration
Tests U tilisateurs
Evaluation
ergonomique
Périmètre du module
POO/IHM
DEVINT
20. Compétences et périmètre du module
(c) 2015, Occello Audrey, POO/IHM - 20 -
Des interfaces flexibles
• Sensibilisation à la conception d’IHM, considérations architecturales,
développement modulaire d’IHM, initiations aux librairies et Frameworks
Des interfaces utilisables
• Conception centrée utilisateurs avec prise en compte des usages, mise en place de
protocoles d’évaluations
Des interfaces adaptées au support visé
• Acquisition de connaissances à la pointe de la technologie : RWD,
Crossplatform, interfaces tactiles, interfaces collaboratives, Ingénierie des
modèles
Des interfaces réparties
Applications du futur
23. (c) 2015, Occello Audrey,
POO/IHM
- 23 -
Widgets génériques pour le maquettage
http://www.jankoatwarpspeed.com/post/2009/12/24/sketching-wireframing-kit.aspx
24. (c) 2015, Occello Audrey,
POO/IHM
- 24 -
Widgets génériques pour le maquettage
http://www.jankoatwarpspeed.com/post/2009/12/24/sketching-wireframing-kit.aspx
Les outils "dédiés" aux maquettes
permettent de concevoir une IHM
indépendamment des toolkits du marché
Objectifs : vérifier l’utilisabilité et
l’acceptation des utilsateurs
26. •Organiser le code (rangement) Simplifier (diviser pour régner)
•Organiser le travail Faciliter les évolutions
•Ré-utiliser (modifier une partie)
:modularité, évolutivité, flexibilité
Séparation possible
–Code pour IHM
–Code «Métier»
•Exemple
–IHM différente pour une Gestion d’un stock de chaussures ou de bibelots ?
–Linux sous gnome ou kde, le système change-t-il ?
•Objectif : éviter de tout modifier si on change la partie fonctionnelle ou la partie
IHM
Architecture Logicielle et IHM :
Pourquoi ?
29. Des architectures logicielles :
modèles à agents : PAC & MVC
utilisateur utilisateur
Le modèle MVC (Modèle, Vue, Contrôleur)
Smalltalk [Goldberg and Robson, 1981].
modifiabilité + conception itérative +
compatibilité avec les langages à objets.
MVC les systèmes interactifs = une hiérarchie
d'agents.
Un agent MVC =
un modèle,
une ou plusieurs vues,
et un ou plusieurs contrôleurs
30. Le modèle MVC
modèle = noyau fonctionnel de l'agent
Le modèle notifie les vues à chaque fois que son état est
modifié par le noyau ou par ses contrôleurs.
La vue (constituée d'objets graphiques)
maintient une représentation du modèle pour l'utilisateur,
mise à jour à chaque notification d'état.
Le contrôleur reçoit et interprète les événements utilisateur,
les répercutant sur le modèle (modification de son état) ou
sur la vue (retour instantané).
35. Une IHM c’est quoi ?
La structure
Le comportement
La structure sert à disposer l’information
C’est la partie "visible" de l’IHM (elle inclut la possibilité
d’interagir)
Le comportement sert à déclencher des réactions
face aux actions de l’utilisateur
Les actions de l’utilisateurs sont traduites en des stimuli
que l’on appelle événements
(c) 2015, Occello Audrey, POO/IHM - 35 -
36. (c) 2015, Occello Audrey,
POO/IHM
- 36 -
Des éléments graphiques simples prêts à l’emploi (widgets)
• Définition d’un élément graphique avec une dimension, une position
• et un type de contrôle associé permettant de saisir ou d’afficher de l’information
et d’activer des fonctionnalités
Des éléments graphiques composés (conteneurs) :
• Définition d’un regroupement - éléments graphiques qui contiennent d’autres
éléments graphiques
Du formattage :
• Définition de l’organisation (placement des éléments les unes par rapport aux
autres) - En ligne, en tableau, avec des contraintes, etc
Des bouts d’écran :
• Définition de l’affichage à l’écran (dessiner les éléments graphiques) et gestion du
redimensionnement
Des événements pour écouter les actions de l’utilisateur (appuie sur des
touches clavier /souris, mouvement de la souris/Wiimote, …)
StructureCompor-
tement
38. Ce que vous allez utiliser de Java
et de ces concepts
• L’API java : pour découvrir la librairie
• L’héritage : pour construire vos composants
• Les exceptions : pour signaler les erreurs
• Les threads : pour avoir une interface fluide
• Les inner classes : pour gérer les réactions
Quelques flashback ou look forward
avant de commencer le vif du sujet
39. Les packages les plus importants
Les bibliothèques graphiques
• java.awt.* - 1ère boite à outil de java
Éléments de base : Component(et Graphics) - Container et Layout
(LayoutManager)
• java.swing.* - extension (d’abord JFC puis intégré depuis jdk 1.2)
faire que tout fonctionne de manière identique partout
Les événements
• java.awt.event.* et java.swing.event
La réflexivité
• java.reflect.* - les classes qui décrivent les concepts de java
41. L’héritage
introspection et réflexivité java
java.lang.reflect.*
des classes: Object
AccessibleObject
Constructor
Field
Method
Array
InvocationTargetException
Modifier
ReflectPermission
une interface : Member
Exemple : Complétion des IDEs
42. Les classes internes
Autre « forme d’héritage » avec masquage de
l’implémentation (y compris au package)
Qui permet la définition des «callbacks» à la volée
Utile pour la programmation événementielle
Se définit :dans une classe, dans une méthode, entre { } ou en paramètre (anonyme)
L’inner a accès aux éléments de la classe qui l’inclut
Création d’une instance d’une inner classe
–<Instance de NomDeClasse>.new <Inner>( )
–Ex : Bebete.Etat result = bebete.new Etat();
Avec Bebete une classe contenant une classe interne Etat et bebete une
instance de la classe Bebete
L’Inner dans un bloc d’instruction
•Ne peut pas être utilisée en dehors de la méthode
•Utile pour personnaliser des objets sans créer de classe (masquer l’implémentation).
43. Exemple de classe interne pour l’IHM
• Allez voir une Horloge avec un minuteur
• http://manu.e3b.org/Java/Tutoriels/HeritagePolymorphisme/Anonymes/A
nonymes.htm
44. Les processus légers ou threads
La classe Thread
new Thread(<une instance
Runnable>);
–Méthode start( ) qui lance le
processus
–Méthode yield( ) pour passer la
main (via le scheduler)
•Pour être plus rapide et Pour ne pas bloquer un processus (interface).
Utilisation de l’interface
Runnable
–Méthode public void run( )
import java.util.concurrent.*;
public void run() {
try {
while(! canceled) {
// Old-style:
// Thread.sleep(100);
// Java SE5/6-style:
TimeUnit.MILLISECONDS.sleep(100);
}
} catch(InterruptedException e) {
System.err.println("Interrupted");
}
}
Cf. cours internet et réseaux
et cours appli. concurrentes
45. Exemples
• Vous pouvez aller regarder
• Un cours en ligne
http://lifc.univfcomte.fr/lifc2/~dhoutaut/enseignements/IUP/java_thread_1.pdf
• Et la partie du tutorial java consacrée à ce point :
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html
47. Des éléments graphiques : Component
Définition d’un élément graphique avec
une dimension, une position
Des Coordonnées
(Origine coin supérieur gauche, x (width) vers
la droite et y (height) vers le bas)
Des morceaux d’écrans : Graphics
Contexte graphique
Permet de dessiner
–Changer de crayon : couleur, formes
géométriques, images, chaînes de caractères
- Automatiquement redimensionnés,
réaffichés
ON S’INTERESSE A LA STRUCTURE
Des éléments graphiques
Contenant Container :
qui contiennent d’autres éléments
graphiques organisés
Du Formattage : LayoutManager
Définition de l’organisation
En ligne, en tableau, avec des
contraintes,etc
49. ON GERE LES INTERACTIONS
OBSERVER OBSERVABLE /
LISTENERS
50. Principe
• Un effet de bord fréquent de la partition d’un
système en une collection de classes coopérantes est
la nécessité de maintenir la consistance entre les
objets reliés entre eux.
• On ne veut pas obtenir la consistance en liant
étroitement les classes, parce que cela aurait comme
effet de réduire leur réutilisabilité.
51. Principe
Définir une dépendance de “1” à
“n” entre des objets telle que
lorsque l’état d’un objet change,
tous ses dépendants sont
informés et mis à jour
automatiquement
52. Quand l’appliquer
• Lorsqu’une abstraction possède deux aspects dont l’un dépend
de l’autre.
– L’encapsulation de ces aspects dans des objets séparés permet de les
varier et de les réutiliser indépendamment.
– Exemple : Modèle-Vue-Contrôleur
• Lorsqu’une modification à un objet exige la modification des
autres, et que l’on ne sait pas a priori combien d’objets devront
être modifiés.
• Lorsqu’un objet devrait être capable d’informer les autres
objets sans faire d’hypothèses sur ce que sont ces objets,
53. PATTERN :Observer Observable
• Le pattern “Observer” décrit
– comment établir les relations entre les objets dépendants.
• Les objets-clés sont
– la source
• Peut avoir n’importe quel nombre d’observateurs dépendants
• Tous les observateurs sont informés lorsque l’état de la source
change
– l’observateur.
• Chaque observateur demande à la source son état afin de se
synchroniser
55. Implémentations Java du pattern
Une classe et une interface : class Observable {... } et
interface Observer
Un objet Observable doit être une instance de la classe qui
dérive de la classe Observable
Un objet observer doit être instance d’une classe qui
implémente l’interface Observer
void update(Observable o, Object arg);
Des listeners : ajouter des listerners, notifier les listeners avec
des évenements, réagir aux événements
56. Et la suite ?
• Zoom sur la librairie
• Zoom sur les événements
• Zoom sur l’architecture
ATTENTION Cours interactifs
57. Listeners Supported by Swing
Components
• http://java.sun.com/docs/books/tutorial/uisw
ing/events/intro.html
