Architecture logicielle

!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
M1 informatique, option IHM, UNSA
Architecture logicielle
Philippe Renevier
[email protected]
Avec l’aide de
Laurence Nigay (http://iihm.imag.fr/nigay/)
"
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Architecture, 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
• Complexité et taille croissantes des IHM
• Outils de développement des IHM : utiles mais imparfaits
– boîtes à outils : niveau d’abstraction trop bas, absence de structuration
– squelettes d’applications : reverse enginering 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
"9
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Architecture, Plan
• Architecture logicielle (aspects génériques)
– définition
– processus et style d’architecture
• Modèles fonctionnels : Seeheim, Arch
• Modèles à agents : MVC, ALV, PAC
• Modèle hybride : PAC-Amodeus
":
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
;<
1. Architecture : aspects génériques
• Définition : ensemble organisé d’unités de calcul (composants et connecteurs) +
description des interactions entre ces unités
Composant
•
•
•
•
Connecteur
Composant
Une architecture exprime ce qui est important
L’importance dépend du contexte et du but
Contexte (taille, durée de vie, domaine applicatif, culture en qualité logicielle, ...)
But
– communication (précision et non ambiguïté de la description)
– reverse-engineering d’un système existant
– évaluation (selon des critères qualité)
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
;"
Architecture : aspects génériques ...
• Localisation dans le processus
de développement
utilisateur
Spec.
externes
– spécifications externes (IHM)
– spécifications internes détaillées
• Tension et compromis entre
contraintes
– centrées sur l’utilisateur
– centrées sur la technologie
Compromis
Architecture
globale
Spec. internes
détaillées
Technologie
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Architecture : aspects génériques ...
• Processus
• Processus de conception d’une architecture : à la
fois ascendant et descendant
• mais des étapes parfaitement identifiées
;;
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
;=
Architecture : aspects génériques ...
• 1. Décomposition fonctionnelle
F1
F2
F3
• 2. Décomposition structurelle selon un style
C1
C2
• 3. Allocation des fonctions aux composants
C1
F1
C2
F2
F3
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
;>
Architecture : aspects génériques ...
• 4. Allocation des composants aux processus
P1
C1
F1
C2
F2
F3
• 5. Allocation des processus aux processeurs
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Architecture : aspects génériques ...
• Style d’architecture
• Exemples
– Pipes and filters (pipe-line)
– Machines abstraites en couches
– Organisations orientés objet
• Un style définit
–
–
–
–
un vocabulaire d’éléments
des contraintes de configuration de ces éléments
une sémantique pour interpréter une configuration
permet l’analyse de propriétés
• Emergence de patterns ou solutions canoniques
;?
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
;@
Architecture : Modèles fonctionnels
• Fondement
Noyau fonctionnel
IHM
• Seeheim : modèle séminal
Contrôle
du dialogue
API
Interface avec le
noyau fonctionnel
Noyau fonctionnel
Présentation
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
;A
2. Architecture : Modèles fonctionnels
• Arch : Seeheim révisé
Contrôle
du dialogue
Interface avec le
noyau fonctionnel
Noyau fonctionnel
Présentation
Physique
Logique
Interaction
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
;9
Architecture : Modèles fonctionnels
• Arch
• Modifiabilité
– réparation sémantique
– protocole haut niveau
• Portabilité IHM
Contrôle
du dialogue
Interface avec le
noyau fonctionnel
Présentation
Noyau fonctionnel
– boîte à outils abstraite
• Extensibilité niveau interaction
– Objets d’interaction dédiés
Interaction
Contrôleur de dialogue
couche extension de toolkit
Adaptateur de toolkit
Toolkit
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Architecture : Modèles à agents
• Un système interactif = une collection d’unités de calcul
spécialisés (agents)
• Un agent
– a un état
– a une expertise
– est capable d’émettre et de réagir à des événements
• Un agent en contact direct avec l’utilisateur = un
interacteur
• Quelquefois agent = interacteur
=<
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Architecture : Modèles à agents ...
• Motivations
• Modularité et parallélisme
– conception itérative (modifiabilité)
– dialogue à plusieurs fils
– mise en œuvre des collecticiels
• Correspondance avec l’approche à objets
– catégorie d’agents (réactifs) -> classe
– événement -> méthode
– encapsulation : l’agent (l’objet) est seul à modifier directement
son état
– mécanisme de sous-classe -> modifiabilité
="
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
=;
Architecture : Modèles à agents ...
• MVC (Smalltalk)
• Model : la compétence abstraite de l’agent (son NF)
• View : le rendu perceptible de l’agent (son comportement
en sortie)
• Controller : son comportement en entrée
V
M
V
V
M
M
C
V
M
M
M
C
C
C
C
C
V
V
Aspects réalisation
• Un agent : 3 objets Smalltalk
(1 par facette)
• Hiérarchie de Models, de
Views, de Controllers
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
==
Architecture : Modèles à agents ...
•
•
•
•
ALV [Hill]
Abstraction : le M de MVC
View : le V+C de MVC
Link : expression des dépendances entre A et V
L
V1
L
V2
A
Aspects réalisation
• Link = langage dédié à
contraintes (Rendez-vous)
• A et V hiérarchie d’objets
• A unique et partagée = le NF
du système interactif
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Architecture, Préambule : MVC
• Smalltalk [Goldberg et Robson 1983]
• Cause : difficultés de conception des applications
fortement interactives
• Réponse : modularisation
– Model : modélisation (données et comportement)
– View : représentation manipulable de l'objet
– Control : interprétation des entrées
9
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
MVC : meilleure conception
• Séparer dans le code
– les données (le Modèle),
– La ou les Vues,
– Le Contrôle,
• Exemple :
– Excel,
– widgets Swing,
– bonnes applications web (.Net avec les datasets et les pages
aspx, JSP/Servlets/EJBs etc…)
– Jeux avec plusieurs vues caméra,
– Etc…
9
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
MVC : meilleure conception
• Plusieurs vues possibles synchronisées,
• Plusieurs contrôles possibles (exemple : clavier,
souris, joypad),
• Données isolées (BD, fichiers, etc…)
• Bien entendu :
– Nécessité de définir des interfaces communes entre le
modèle, la vue et le contrôleur,
– Java fournit en standard un certain nombre d’outils…
9
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
9
Les classes Observer / Observable
Observer
"Arthur"
Observer
"Fred"
Observable
Observable
Observable
1.
Arthur
7 :.%(./$;+(.
1. Arthur
2. Martin
7 :.%(./$;+(.
Observer
"Martin"
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Observer / Observable
Exemple : un timer
class Test {
Timer timer;
Test() {
timer = new Timer();
Toto toto = new Toto();
timer.addObserver(toto);
}
public static void main(String[] args)
Test t = new Test();
t.timer.run();
}
}
+'+'#.:+#
;<'-+.-(#
=-#+$).(
{
9
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
java.util.Observer
Toto est un observateur
class Toto implements java.util.Observer {
public void update(Observable o,
Object arg) {
System.out.println("Temps : "
+ ((Timer)o).getSeconds()
+ " secs");
}
}
:'-;#<.;#'=;.(>*+.-(;#?'$>.%+#
1';;@?.(#-%.#)@+A'?.#-1?*+.BCD
9
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
java.util.Observable
Exemple
class Timer extends java.util.Observable {
private long zzz = 1000;
:.;#'<;.(=*<>.;#?'$=.%+#
private long zero;
@+(.#?A-%.#;'-;0B>*;;.#?.#
Timer(long zzz) {
C<;.(=*<>.
this.zzz = zzz;
}
public void run () throws InterruptedException {
zero = System.currentTimeMillis();
C%#1(D=$.%+#>.;#'<;.(=*+.-(;4#E*#
while (true) {
*11.>>.#-1?*+.FGH
setChanged();
notifyObservers(new
Long(System.currentTimeMillis()
- zero));
Thread.sleep(zzz);
}
}
}
9
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
PAC : Un modèle hiérarchisé d’agent
• [Coutaz 88]
• Trois facettes :
– Présentation (C + V de MVC), le V de ALV
– Abstraction (M de MVC)
– Contrôle : communication entre agent et expression des
dépendances (liaison) entre A et P (le L de ALV)
• Hiérarchisation :
– Arbre : relation père-fils
– Heuristique de conception
– Communication par message
=?
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
=@
Architecture : Modèles à agents
• PAC
Aspects réalisation
• Aucune recommandation
• dépend de la plate-forme
d’accueil
• 1 agent = 1 module C, 1 objet,
1 objet par facette (comme
MVC ou ALV)
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
><
Modèle hybride : Modèle PAC-Amodeus
!"#$%&'()%*+(*,-.'"/)(*
!,
!"#$%&'
3/,3$4%0$5&
3$B(*(CD$.#EF*/.%+G#H8I
0+.1$.$()%*+)*
2"3.)*4"#5$-"##('*
*
024
!"#$%&'(0'(/1-.,$
2"3.)*4"#5$-"##('*
*
24
!"#$%&'($'
)*+&$,%-%./,
!"61"7.#$*
8(59#-:)(7*+(*;%<7(#$.$-"#*
*
!8;
!"#$%&'(2.,%$*-3%./,
!"61"7.#$*
=#$(%.5$-"#*+(*>.7*2-?(.)**
*
!=>2
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Règles Heuristiques
• Ensemble de règles heuristiques pour construire
la hiérachie d'agents PAC du Contrôleur de
Dialogue dans PAC-Amodeus à partir d’une
maquette
• Source Modèle d’architecture des systèmes
interactifs, chapitre 7.
>"
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
>;
R2 : Vue multiple
• Agent vue multiple d'une "œuvre"
Wall
Environnement
Chaleur
Environment Zone Region Preferences
Wall
Place
Route
.
Movable Object
x
Static Object
Point Region Preferences
Environment Zone
Wall
Place
Route
.
Movable Object
x
Static Object
Point
Anchor x (m):
Anchor y (m):
Mouse x (m): 12
Mouse y (m): 15
Length (m):
Anchor x (m):
Anchor y (m):
Mouse x (m): 12
Mouse y (m): 15
Length (m):
?
?
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
>=
R2 : Vue multiple
• Agent vue multiple d'une "œuvre"
• Un superagent garantit la cohérence visuelle
superagent
vue multiple
agent
vue
agent
vue
agent
vue
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
>>
PAC et MVC : vue multiple
A
C
P
C
V1
C
P
C
V2
M
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
D’autres Heuristiques
• R1 : fenêtre = un agent
• R3 : Palette de concepts
– Une palette de classes de concept = un agent
– Une barre de menu = un agent
• R4 : zone d’édition
– Une zone d’édition = un agent
– Condition : être suffisamment complexe
• R5 : correspondance agent / concept
– Un concept complexe = un agent
>?
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Heuristiques de liaison
• R6 : d’une fenêtre à une autre
– Les deux sont sous le même agent parent commun
• R9 : Ciment syntaxique
– Agent ciment pour "analyse syntaxique distribuée”
>@
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
>A
R9 : Ciment syntaxique
• Agent ciment pour
"analyse syntaxique
distribuée"
• Un superagent cimente
les actions distribuées
superagent
ciment
agent
agent
agent
action
de l'utilisateur
action
de l'utilisateur
action
de l'utilisateur
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
Heuristiques de simplification
• R10 : un agent fils unique peut être regroupé avec
son père
– Attention à la modularité / réutilisation / évolution
• R11 : un agent dont la fonction est réalisée par un
objet de la boîte à outils graphique devient un
composant de la présentation de son père.
>9
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
>:
Corollaire de R11
• Un objet d’interaction non implémenté par la
plate-forme -> un agent
Un espace de travail -> un agent
Un objet mur -> un agent
!"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678
?<
Délégation sémantique
• Usage de la délégation sémantique pour
performance.
– Dans l'exemple du robot mobile, le A de l'agent mur
contient la modélisation
– de mur dans les termes
du domaine (mètres,
non pas pixels).
Environment Zone Region Preferences
?
Wall
.
x
• Evite les appels au NF
pendant le tracé du mur.
– Système de cache
Place
Route
Movable Object
Static Object
Point
Anchor x (m): 12
Anchor y (m): 10
Mouse x (m): 13
Mouse y (m): 2
Length (m): 8.1
Updated Values as the mouse moves
Rubber Banding as the wall is resized