Architecture logicielle

Transcription

1 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 " M1 informatique, option IHM, UNSA Architecture logicielle Philippe Renevier Philippe.Renevier@unice.fr Avec l aide de Laurence Nigay (

2 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 "9 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

3 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ": Architecture, Plan Architecture logicielle(aspects génériques) définition processuset style d architecture Modèlesfonctionnels: Seeheim, Arch Modèlesà agents : MVC, ALV, PAC Modèlehybride: PAC-Amodeus

4 !"#$%&'()*+$,-.#.+#!$*/. 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é)

5 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ;" Architecture : aspects génériques... Localisation dansle processus de développement spécificationsexternes(ihm) spécificationsinternesdétaillées Tension et compromisentre contraintes centréessurl utilisateur centréessurla technologie Spec. externes Architecture globale Spec. internes détaillées utilisateur Compromis Technologie

6 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ;; Architecture : aspects génériques... Processus Processusde conception d unearchitecture : à la fois ascendant et descendant maisdes étapesparfaitementidentifiées

7 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ;= Architecture : aspects génériques Décompositionfonctionnelle F1 F2 F3 2. Décompositionstructurelleselonun style C1 C2 3. Allocation des fonctionsaux composants F1 C1 F2 C2 F3

8 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ;> Architecture : aspects génériques Allocation des composantsaux processus P1 F1 C1 F2 C2 F3 5. Allocation des processusaux processeurs

9 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ;? Architecture : aspects génériques... Style d architecture Exemples Pipes and filters (pipe-line) Machines abstraitesen couches Organisations orientésobjet Un style définit un vocabulaired éléments des contraintesde configuration de ceséléments unesémantiquepour interpréteruneconfiguration permetl analysede propriétés Emergence de patterns ou solutions canoniques

10 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ;@ Architecture : Modèles fonctionnels Fondement Noyau fonctionnel IHM Seeheim: modèleséminal Contrôle du dialogue API Interface avec le noyau fonctionnel Présentation Noyau fonctionnel

11 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ;A 2. Architecture : Modèles fonctionnels Arch : Seeheimrévisé Contrôle du dialogue Interface avec le noyau fonctionnel Présentation Logique Noyau fonctionnel Physique Interaction

12 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 ;9 Architecture : Modèles fonctionnels Arch Modifiabilité réparationsémantique protocolehaut niveau PortabilitéIHM boîteà outilsabstraite Extensibiliténiveauinteraction Objets d interactiondédiés Interface avec le noyau fonctionnel Noyau fonctionnel Contrôle du dialogue Contrôleur de dialogue couche extension de toolkit Adaptateur de toolkit Présentation Interaction Toolkit

13 !"#$%&'()*+$,-.#.+#!$*/. 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 uneexpertise estcapable d émettreet de réagirà des événements Un agent en contact direct avec l utilisateur = un interacteur Quelquefois agent = interacteur

14 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 =" Architecture : Modèles à agents... Motivations Modularité et parallélisme conception itérative(modifiabilité) dialogue à plusieursfils miseen œuvredes collecticiels Correspondance avec l approche à objets catégoried agents(réactifs) -> classe événement-> méthode encapsulation : l agent(l objet) estseulà modifier directement son état mécanismede sous-classe-> modifiabilité

15 !"#$%&'()*+$,-.#.+#!$*/. 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 M M M M M M C C C V V V V V V Aspects réalisation Un agent : 3 objets Smalltalk (1 par facette) Hiérarchie de Models, de Views, de Controllers C C C

16 !"#$%&'()*+$,-.#.+#!$*/. 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épendancesentrea et V A L L V1 V2 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

17 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4# Architecture, Préambule : MVC Smalltalk[Goldberg et Robson1983] 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

18 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4# MVC : meilleure conception Séparer dans le code les données (le Modèle), La ou les Vues, Le Contrôle, Exemple : Excel, widgetsswing, bonnes applications web (.Net avec les datasetset les pages aspx, JSP/Servlets/EJBs etc ) Jeux avec plusieurs vues caméra, Etc

19 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4# 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

20 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4# Les classes Observer / Observable Observer "Fred" Observer "Arthur" Observable 1. Arthur 2. Martin 1. Arthur 7:.%(./$;+(. 7:.%(./$;+(. Observer "Martin"

21 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4# 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(); +'+'#.:+# ;<'-+.-(# =-#+$).(

22 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4# 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

23 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4# java.util.observable Exemple class Timer extends java.util.observable { private long zzz = 1000; :.;#'<;.(=*<>.;#?'$=.%+# private long Timer(long zzz) { C<;.(=*<>. this.zzz = zzz; } public void run () throws InterruptedException { zero = System.currentTimeMillis(); while (true) { C%#1(D=$.%+#>.;#'<;.(=*+.-(;4#E*# setchanged(); *11.>>.#-1?*+.FGH notifyobservers(new Long(System.currentTimeMillis() - zero)); Thread.sleep(zzz); } } }

24 !"#$%&'()*+$,-.#.+#!$*/. 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

25 !"#$%&'()*+$,-.#.+#!$*/. 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)

26 !"#$%&'()*+$,-.#.+#!$*/. 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!"61"7.#$* 8(59#-:)(7*+(*;%<7(#$.$-"#* *!8;!"#$%&'(0'(/1-.,$!"#$%&'(2.,%$*-3%./, 2"3.)*4"#5$-"##('* * 24!"61"7.#$* =#$(%.5$-"#*+(*>.7*2-?(.)** *!=>2

27 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 >" Règles Heuristiques Ensemble de règlesheuristiquespour construire la hiérachie d'agents PAC du Contrôleur de Dialogue dans PAC-Amodeus à partir d une maquette Source Modèled architecturedes systèmes interactifs, chapitre 7.

28 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 >; R2 : Vue multiple Agent vuemultiple d'une"œuvre" Environnement Wall Environment Zone Region Preferences Wall Place Route. Movable Object x Static Object Environment Zone Point Region Preferences? Wall Anchor x (m): Place Anchor y (m): Route Mouse x (m): 12. Movable Object Mouse y (m): 15 x Static Object Length (m): Point? Chaleur Anchor x (m): Anchor y (m): Mouse x (m): 12 Mouse y (m): 15 Length (m):

29 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 >= R2 : Vue multiple Agent vuemultiple d'une"œuvre" Un superagentgarantitla cohérencevisuelle superagent vue multiple agent vue agent vue agent vue

30 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 >> PAC et MVC : vue multiple A C C V1 C P C P M V2

31 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 >? D autres Heuristiques R1: fenêtre= un agent R3: Palette de concepts Unepalette de classes de concept = un agent Unebarrede 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

32 !"#$%&'()*+$,-.#.+#!$*/. 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 : Cimentsyntaxique Agent cimentpour "analyse syntaxiquedistribuée

33 !"#$%&'()*+$,-.#.+#!$*/. 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

34 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 >9 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.

35 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678 >: Corollaire de R11 Un objet d interactionnon implémentépar la plate-forme -> un agent Un espace de travail -> un agent Un objet mur -> un agent

36 !"#$%&'()*+$,-.#.+#!$*/. 0 '1+$'%#23!4#5678?< Délégation sémantique Usage de la délégationsémantiquepour performance. Dansl'exempledu robot mobile, le A de l'agentmur contient la modélisation de murdansles termes du domaine (mètres, non pas pixels). Eviteles appelsau NF pendant le tracé du mur. Systèmede cache. x Wall 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 Environment Zone Region Preferences? Rubber Banding as the wall is resized