43. Architektur interaktiver Systeme

Transkript

1 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie 43. Architektur interaktiver Systeme - als Konnektor zwischen GUI und Anwendungslogik Prof. Dr. rer. nat. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden Version , Softwaretechnologie (ST) 1) Benutzungsoberfächen und Anwendungslogik 2) Kopplung von synchronen und formularbasierten Benutzungsoberfächen und Anwendungslogik 3) Kopplung von reaktiven, graphischen Benutzungsoberfächen und Anwendungslogik 4) Controller als Steuerungsmaschinen 5) Implementierung der Konnektoren 6) Swing

2 Teil IV - Objektorientierter Entwurf (Object-Oriented Design, OOD) 2 Softwaretechnologie (ST) 1) 40: Überblick 2) 41: Einführung in die objektorientierte Softwarearchitektur 1) Architekturprinzipien, Architekturstile, Perspektivenmodelle 2) Modularität und Geheimnisprinzip 3) BCD-Architekturstil (3-tier architectures) 3) 42: Verfeinerung mit querschneidender Objektanreicherung 4) 43: Architektur interaktiver Systeme 5) 44: Punktweise Verfeinerung von Lebenszyklen Verfeinerung von verschiedenen Steuerungsmaschinen

3 Literatur 3 Softwaretechnologie (ST) Obligatorisch: [PassiveView] Martin Fowler. Passive View. Strikte Schichtung, aktiver Controller und passiver View. Weitere: F. Buschmann. N. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-orientierte Software-Architektur. Addison-Wesley. Entwurfsmuster und Architekturstile. MVC, Pipes, u.v.m. [Herrmann] M. Veit, S. Herrmann. Model-View-Controller and Object Teams: A Perfect Match of Paradigms. Aspect-Oriented System Development (AOSD) 2003, ACM Press Mike Potel. MVP: Model-View-Presenter The Taligent Programming Model for C+ + and Java. VP & CTO Taligent, Inc. ftp://www6.software.ibm.com/software/developer/library/mvp.pdf html web frameworks STRUTS Web Application Component Toolkit

4 4 Softwaretechnologie (ST) Die Architektur interaktiver Anwendungen ist eines der komplexesten Gebiete der Software- Architektur Um sie zu verstehen, brauchen wir alle Teile des Kurses: Kollaborationen und Konnektoren Schichten Steuerungs- und Protokollmaschinen Sequenzdiagramme Entwurfsmuster Resourcen: GUI/MVCModular.java GUI/MVCModularDirectPlayOut.java Die Bildung kommt nicht vom Lesen, sondern vom Nachdenken über das Gelesene. Carl Carl Hilty, Hilty, Schweizer Schweizer Richter Richter und und Staatsrechtler, Buchautor Buchautor und und christl. christl. Staatsrechts-Philosoph Seine Seine Bücher Bücher beeinflussten auch auch K. K. Adenauer Adenauer

5 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie 43.1 Benutzungsoberfächen (UI) und Anwendungslogik Verschiedene Arten der Kopplung zwischen Benutzer und Software Softwaretechnologie (ST)

6 Controller bildet 4. Schicht zwischen der Benutzungsoberfäche (UI) und der Anwendungslogik 6 Softwaretechnologie (ST) Benutzungsoberfläche (user interface, UI) UI_Form UI_Page UI_Button UI_Menu Play-In- Konnektor Controller-Schicht Play-out- Konnektor Unsichtbare Ablauf- Steuerung (Ereignis- Verwaltung) Fachliche Klassen (Anwendungslogik) A_TeamEditor Datenhaltung D_Teammitglied D_Teambesprechung

7 Arten von Benutzungsschnittstellen (User Interface, UI) 7 Softwaretechnologie (ST) Synchrone UI: die Anwendungslogik ruft die UI auf und wartet auf Eingaben Asynchrone UI: die Anwendungslogik reagiert auf die UI Treiber ist die Anwendungslogik Treiber ist die UI Kommandozeilen-orientiert, textuelle UI (TUI) Graphische UI (GUI) Tangible UI (TUI) Maskenorientiert (screen fow) oder formularorientiert (form fow, FUI) ==> dann muss der Controller die parallele Verarbeitung steuern ==> dann kann der Controller entfallen Verteilte UI (Web UI) ==> dann muss der Controller die verteilte und parallele Verarbeitung steuern

8 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie 43.2 Kopplung von synchronen Benutzeroberfächen mit der Anwendungslogik Text- und Formularbasierte Oberfächen (Form-Based UI, FUI) sind meist synchron mit der Anwendungslogik gekoppelt Konnektor sehr einfach: Die Anwendungslogik ruft die Oberfäche auf und wartet auf die Eingaben des Benutzers, z.b. das Ausfüllen von Formularen Softwaretechnologie (ST)

9 Synchrone Kopplung zwischen Anwendungslogik, Controllerschicht und FUI 9 Softwaretechnologie (ST) Die Anwendungslogik ruft das formularbasierte UI mit einem leeren Formular auf und warten auf das Ausfüllen des Benutzers (synchron) Die Play-In und Play-Out-Konnektoren sind besonders einfach Formularbasierte Benutzungsoberfläche (FUI) Menu Form Page Button ausfüllen Filled Form Filled Page Play-out: Präsentation Formular (Screen) Controller-Schicht Play-In: Interpretation des Formulars Fachliche Klassen (Anwendungslogik) A_TeamEditor

10 Textbasierte UI mit synchronem Update (ein View) 10 Softwaretechnologie (ST) In Java: Eingabe mit System.in, Ausgabe mit System.out Play-In und Play-Out-Konnektoren sind Prozeduraufrufe an die UI m:domain Tool <<Boundary>> v1:textview askforfilledtext() return FilledText redraw(filledtext)

11 Einfache textuelle Sichten 11 Softwaretechnologie (ST) Textbasierte UI sind spezielle formularbasierte UI In Java: Aufruf der Objekte System.in und System.out class class PersonTool PersonTool { activities activities of of the the tool tool System.out.println( Enter a number\n ); number\n ); int int num num = System.in.read(); Person Person p.number p.number = num; num; foreach foreach (view (view ; tool.getviews()) { view.redraw(p); view.redraw(p); } further further activities activities of of the the tool tool }

12 Textbasierte UI mit synchronem Update (mehrere Text- Views) 12 Softwaretechnologie (ST) Immer alles schön nacheinander (synchron) v1:textview askforfilledtext() m:domain Tool v2:textview return FilledText redraw(filledtext) redraw(filledtext)

13 Screen-Flow 13 Softwaretechnologie (ST) Der Fluss von Daten zwischen AL und FUI wird als Screen Flow bezeichnet und kann durch ein Aktivitätendiagramm mit zwei Swimlanes beschrieben werden Die Initiative liegt in der AL: Der FUI wird jeweils von der AL beauftragt, die Daten einzuholen AL Einloggen Abfrage starten Adress-Objekt anlegen Kontonummer prüfen Versanddetails hinzufügen Bestellung bearbeiten FUI + passwd angeben Versandadresse ausfüllen Kontonummer ausfüllen Versanddetails ausfüllen

14 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie 43.3 Überblick zu reaktiven graphischen Benutzeroberfächen (GUI) Kopplung der GUI und Anwendungslogik durch Controller Bislang war es einfach, aber auch unfexibel Jetzt bringt ein Controller bzw. eine Controllerschicht die Ereignisse, auslösenden Fensterelemente (Sicht) und Tool asynchron zusammen Der Controller beherrscht und kapselt die Interaktion, die Initiative geht von ihm aus View und Tool sind gegenüber ihm passiv Softwaretechnologie (ST)

15 Schichtenarchitektur der reaktiven Benutzungsoberfäche (GUI) 15 Softwaretechnologie (ST) Graphische Benutzungsoberfläche (Fensteroberfläche mit Widget-Hierarchie, graphical user interface, GUI) UI_Window UI_Button UI_Menu Play-In (asynchron) Controller-Schicht Play-out (synchron, aber multiple Sichten und pull-steuerung) Unsichtbare Ablauf- Steuerung (Ereignis- Verwaltung des Laufzeitsystems) Fachliche Klassen (Anwendungslogik Tools) Datenhaltung D_Teammitglied A_TeamEditor D_Teambesprechung

16 Schichtenarchitektur der reaktiven Benutzungsoberfäche (GUI) 16 Softwaretechnologie (ST) Graphische Benutzungsoberfläche (Fensteroberfläche mit Widget-Hierarchie, graphical user interface, GUI) UI_Window UI_Button UI_Menu Controller- Schicht Play-In (asynchron) In-Controller Out-Controller Play-out (synchron, aber multiple Sichten und pull-steuerung) Unsichtbare Ablauf- Steuerung (Ereignis- Verwaltung des Laufzeitsystems) Fachliche Klassen (Anwendungslogik Tools) Datenhaltung D_Teammitglied A_TeamEditor D_Teambesprechung

17 Tool, Controller und Views in strikter Schichtung 17 Softwaretechnologie (ST) mehrere push-observer => Änderungen (play-in, asynchron ausgelöst) Sicht 1 (View) Sicht 2 (View) In-Controller1 GUI-Kollaboration In-Controller2 Benachrichtigung vieler Sichten über Änderungen (play-out, viele pull Observer) Out-Controller2 Out-Controller1 Methodenaufrufe => Änderungen (play-in) Fachliche Klassen (Tools)

18 Controller sind Konnektoren zwischen Tool und View 18 Softwaretechnologie (ST) Meist existiert ein Hauptobjekt in der Kollaboration, womit der Controller einen Konnektor darstellt Sicht 1 (View) Sicht 2 (View) Play-In-Konnektor GUI-Konnektor Play-Out-Konnektor In-Controller1 In-Controller2 Out-Controller1 Out-Controller2 Methodenaufrufe => Änderungen (play-in) Fachliche Klasse (Tools)

19 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie 43.4 Controller als Steuerungsmaschinen in Konnektoren Im Entwurfsmuster PassiveView bestehen die Controller aus Steuerungsmaschinen, die die Ereignisse der GUI in die Ereignisse der Anwendungslogik übersetzen und umgekehrt Die Controllerschicht ist aktiv; View und Tool bleiben passiv Softwaretechnologie (ST)

20 Implementierung der Controller als Steuerungsmaschinen 20 Softwaretechnologie (ST) Ein Ein Controller-Konnektor Controller-Konnektor wird wird durch durch eine eine Steuerungsmaschine Steuerungsmaschine implementiert, implementiert, die die die die Ereignisse Ereignisse auf auf der der Fensterhierarchie Fensterhierarchie (UI) (UI) in in die die Aufrufe Aufrufe an an die die Tools Tools der der Anwendungslogik Anwendungslogik übersetzt übersetzt (u.u.) (u.u.) Ereignisse auf der Fensterhierarchie (UI) Button-Pressed, WindowClosed, MenuItemSelected, etc. Aufrufe an die Anwendungslogik: Erzeugen von Kommandoobjekten Schreiben auf Materialien (Domänenobjekte) Aufrufen von Tools und Workfows Ein Ein In-Controller In-Controller übersetzt übersetzt die die Ereignisse Ereignisse des des UI UI in in die die Ereignisse Ereignisse der der AL. AL. Ein Ein Out-Controller Out-Controller übersetzt übersetzt die die Ereignisse Ereignisse der der AL AL in in die die Ereignisse Ereignisse der der UI. UI. Beide Beide können können kombiniert kombiniert sein. sein.

21 Input-Controller mit drei Zuständen 21 Softwaretechnologie (ST) Die entstehende Steuerungsmaschine steuert View und Tool an ( beherrscht sie) Getriggert wird sie durch die Ereignisse viewchanged (update). Sie löst pulldata und writetotool aus <<Steuerungsmachine>> In-Controller viewchanged() Data pull() view.pulldata() tool.writetotool(dat a) inconsistent / tool.writetotool(data) tool new viewchanged()/ data = view.pulldata() all consistent

22 Paare von Controller-Steuerungsmaschinen 22 Softwaretechnologie (ST) In- und Out-Steuerungsmaschinen bilden Elemente einer oder mehrerer In- und Out- Kollaborationen <<Steuerungsmachine>> In-Controller <<Steuerungsmachine>> Out-Controller viewchanged() Data pull() view.pulldata() tool.writetotool(dat a) toolchanged() view.update() Data tool.pull() inconsistent viewchanged()/ data = view.pulldata() / tool.writetotool(data) tool new inconsistent toolchanged(data) / data = tool.pull() new data arrived / foreach view: view.update() - all consistent all consistent

23 Controller als bidirektionale Inout-Konnektoren 23 Softwaretechnologie (ST) In- und Out-Controller können auch zusammengelegt sein (z.b. in Spring) Die entstehende Steuerungsmaschine steuert View und Tool an ( beherrscht sie) Getriggert wird sie durch die Ereignisse viewchanged und toolchanged <<Steuerungsmachine>> Controller viewchanged() Data pull() toolchanged() <<provided>> Data view.pull() tool.writetotool(data) view.update() Data tool.pull() <<required>> Play-In view changed /tool.writetotool(data) tool changed /data = tool.pull() views updating viewchanged()/ data = view.pull() all consistent toolchanged() views pulling Play-Out foreach view: view.pull() /foreach view: view.update() -

24 Prinzipieller Aufbau von InOut-Controllern 24 Softwaretechnologie (ST) Die Steuerungsmaschine des InOut-Controllers kennt viele verschiedene Ereignisse des UI und kann sie in spezifschen Zuständen behandeln <<Steuerungsmachine>> Controller viewchanged() Data pull() toolchanged() <<provided>> Data view.pull() tool.writetotool(data) view.update() Data tool.pull() <<required>> Exit MenuItem Selected MenuItemSelected( FileSave) /tool.writetotool(data) Button pressed ButtonPressed( Count ) all consistent Window closed ButtonPressed( Close ) tool changed toolchanged() views pulling /data = tool.pull() /foreach view: view.update() - views updating

25 Implementierung der Controller 25 Softwaretechnologie (ST) Die Controllerschicht wird realisiert entweder als Konnektor mit einer Steuerungsmaschine Menge von In-/Out-Konnektoren mit kommunizierenden Steuerungsmaschinen Oder einer Menge von bidirektionalen Konnektoren Controller können kombiniert (InOut-Controller), oder auch als Paare von kommunizierenden Steuerungsmaschinen auftreten: Der Input-Controller ist eine Steuerungsmaschine, die die Ereignisse auf der Fensterhierarchie in die Aufrufe an die Anwendungslogik übersetzt Der Output-Controller ist eine Steuerungsmaschine, die die Ereignisse in der Anwendungslogik in die Aufrufe an die Fensterhierarchie übersetzt

26 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie 43.5 Implementierung mit Konnektoren Softwaretechnologie (ST)

27 Ein einfacher MVC-Konnektor (als Team mit inneren Klassen) 27 Softwaretechnologie (ST) class class MVCConnector<Tool,View,Controller>{ MVCConnector<Tool,View,Controller>{ List<myView> List<myView> views; views; mytool mytool Tool; Tool; mycontroller mycontroller controller; controller; // // Phase Phase 1: 1: creation creation of of layers layers MVCConnector<View,Tool,View,Controller> MVCConnector<View,Tool,View,Controller> () () { views views = = new new ArrayList<myViews>(); ArrayList<myViews>(); Tool Tool = = new new mytool(); mytool(); connector connector = = new new mycontroller(); mycontroller(); } class class myview myview extends extends View View { // // Inherit Inherit the the View View methods methods } class class mytool mytool extends extends Tool Tool { // // Inherit Inherit the the Tool Tool methods methods } class class mycontroller mycontroller extends extends Controller Controller { // // phase phase 2: 2: wirenet() wirenet() { { registerview(); registerview(); registertool(); registertool(); } registerview() registerview() {.... } registertool() registertool() {.... } // // Phase Phase 3: 3: dynamics dynamics run() run() {.... Controller Controller state state machines machines.... } } } MVCModular.java

28 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie MVC Frameworks (Controller Frameworks) Softwaretechnologie (ST)

29 MVC-Frameworks 29 Softwaretechnologie (ST) Die Struktur einer Controllerschicht kann sich von Anwendungsklasse zu Anwendungsklasse sehr unterscheiden. Ein MVC-Framework gibt eine Struktur der Controllerschicht vor, defniert Protokolle für die Ereignismeldung und den Datenaustausch vor und kann durch den Entwickler erweitert werden. MVC Frameworks benötigen Konfguration und Plugins Oft folgt man dem Prinzip Convention over confguration : Konventionen über Dateiverzeichnisse und Konfgurationsdateien vereinfachen dem MVC- Framework das Auffnden von Controller-, View-, Anwendungsklassen, sowie Hinweise zu ihrer Verdrahtung Konfgurationsdateien meist in XML oder Java-Property-Lists Berühmte Beispiele: Java: Spring, Struts Ruby: Ruby on Rails Groovy: Grails

30 MVC Frameworks kennen Plugins 30 Softwaretechnologie (ST) Configuration File Configuration Hook UI-ExtensionPoint C-ExtensionPoint A-ExtensionPoint UI-Package C-Package A-Package

31 Spring Framework 31 Softwaretechnologie (ST) Spring ist das im Praktikum im WS verwendete MVC-Framework Webbasiert, d.h. Controllerschicht ist auf Client und Server verteilt implementiert Konfgurierbar durch XML-Dateien und Java Property Files Erweiterbar Das Salespoint-Framework nutzt als Konnektor zum GUI das Konnektor- Framework SPRING Main controller, subcontroller Web-MVC Frameworks brauchen starke Schichtung Bietet sehr viele verschiedene Pakete, nicht nur für Web-UIs

32 Spring Konfguration 32 Softwaretechnologie (ST) Spring übernimmt das Management der Verteilung Das Zusammenspiel zwischen Browser, Server und Anwendungslogik auf dem Server DispatcherServlet DispatcherServlet. properties Configuration Hook UI-ExtensionPoint C-ExtensionPoint A-ExtensionPoint UI-Package C-Package A-Package

33 Struktur des String Controllers in Web- Systemen (Server Side) 33 Softwaretechnologie (ST) Der Spring Controller ist ein komposites Programm auf dem Server: das Spring-DispatcherServlet enthält einen FrontController, der das ankommende Ereignis interpretiert (Steuerungsmaschine) und an untergeordnete Controller bzw. Steuerungsmaschinen weiter leitet

34 Controller sind Konnektoren zwischen Tool und View 34 Softwaretechnologie (ST) Im Folgenden gibt es ein Hauptobjekt, den Konnektor, der View, Controller und Tool verdrahtet Sicht 1 Sicht 2 Sicht 3 Sicht 4 Java FX html+javascript html XSWT Play-In-Connector applet Play-Out-Connector Browser Web - http Servlet Front-Controller In-Controller2 Out-Controller1 Out-Controller2 Fachliche Klasse (Tool) Methodenaufrufe => Änderungen (play-in)

35 Server-seitiger Spring-Controller 35 Softwaretechnologie (ST) In- und Out-Controller können auch verteilt sein (z.b. in Spring) Die Steuerungsmaschine ist verteilt auf client und server Getriggert wird sie durch die Ereignisse viewchanged und toolchanged <<Steuerungsmachine>> Spring Controller viewchanged() push(data) toolchanged() <<provided>> tool.writetotool(data) view.update() <<required>> Seite geändert Play-In push(data)/http.get(data) Web - http tool changed writetotool(data) App is computing viewchanged()/ data = view.pull() Play-Out all consistent /Return = http.get(data) view update toolchanged()

36 Spring Codegenerierung 36 Softwaretechnologie (ST) Spring wandet (sog. Metadaten) in Code um Attribute parameterisieren Schablonen ( templates ): Template-gesteuerte Codegenerierung Siehe auch Xdoclet, xdoclet.sf.net Attribut- Code-Regeln Code- Schablonen Spring Code- Attribute Methoden einer Klasse Attribut- Parser Schablonen- Expandierer Hilfs-Code für Web-Mapping Funktionaler Kern

37 @RequestMapping 37 Softwaretechnologie (ST) Ein REST-Webservice bildet URL (Web-Dateinamen) auf aktive Methoden eines Webservice-Objekts <relative URL> ) Wird die URL im Browser aufgerufen, wird die Methode aufgerufen und ihr Resultat als String im JSON-Format zurückgegeben Webserver /showproduct /layintobasket /showproduct /layintobasket /order ) otto:katalog zeigeprodukt() legeproduktinwarenkorb() bestelle()

38 Was haben wir gelernt? 38 Softwaretechnologie (ST) GUI-Programme koppeln die GUI mit der Anwendungslogik mit Hilfe des Konnektor- Musters Der Controller-Konnektor aktiviert die Views und die Anwendungs-Tools Der Kontrollfuß eines GUI-Programms wird nie explizit spezifziert, sondern ergibt sich aus den Aktionen des Benutzers Die Views reagieren auf Ereignisse im Screenbuffer, die von der Ablaufsteuerung gemeldet werden Der Controller auf Widget-Veränderungen im View und Änderungen im Tool Der Controller wird als Steuerungsmaschine implementiert und steuert alles (aktiver Konnektor) Das MVC-Framework Spring enthält eine stark geschichtete GUI- Anwendungskopplung Enthält einen kompositen Controller (komposite Steuerungsmaschine) Regelt den Verkehr zwischen Browser, Server, Servlet, Webservice-Methoden

39 The End 39 Softwaretechnologie (ST) Diese Folien sind eine stark überarbeitete Version der Vorlesungsfolien zur Vorlesung Softwaretechnologie von Prof. H. Hussmann. used by permission. Verbreitung, Kopieren nur mit Zustimmung der Autoren. Wieso muss ein Konnektor zwischen GUI und Anwendungslogik vermitteln?

40 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie 43.A.1 Benutzungsoberfächen (UI) und Anwendungslogik Verschiedene Arten der Kopplung zwischen Benutzer und Software Softwaretechnologie (ST)

41 Schichtenarchitektur, grob 41 Softwaretechnologie (ST) Benutzungsoberfläche (UI) - Teile des KontextTools UI_Window UI_Button UI_Menu Fachliche Klassen (Anwendungslogik AL) A_Teammitglied A_Teambesprechung Ablaufsteuerung Datenhaltung M_TeamMitglied z.b. relationale Datenbank M_Teambesprechung

42 Formularbasierte UI mit XML 42 Softwaretechnologie (ST) v1:formview HTML und XML bieten standardisierte Formate für Formulare an, die von Browsern dargestellt, interpretiert, und ausgefüllt werden können Die Play-In und Play-Out-Konnektoren transportieren XML-Dokumente askforfilledform(html) m:domain Tool v2:formview return FilledForm:HTML redraw(filledform:html) redraw(filledform:html)

43 Formularbasierte UI mit XML übers Web 43 Softwaretechnologie (ST) HTML und XML können vom Client zum Server übertragen werden Kanalprotokoll http oder https Client Server Client v1:formview askforfilledform(html) m:domain Tool v2:formview return FilledForm:HTML via http redraw(filledform:html) via http redraw(filledform:html) via http

44 Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie 43.A.2 Phasen der reaktiven graphischen Benutzeroberfächen (GUI) Kopplung der GUI und Anwendungslogik durch Controller Bislang war es einfach, aber auch unfexibel Jetzt bringt ein Controller bzw. eine Controllerschicht die Ereignisse, auslösenden Fensterelemente (Sicht) und Tool asynchron zusammen Der Controller beherrscht und kapselt die Interaktion, die Initiative geht von ihm aus View und Tool sind gegenüber ihm passiv Softwaretechnologie (ST)

45 Controller sind Konnektoren zwischen Tool und View (gefaltet) 45 Softwaretechnologie (ST) Konnektoren, die Ports verbinden, abstrahieren die Kollaborationen Sicht 1 (View) Sicht 2 (View) Anwendungslogik (Tool)

46 Widgets und Datenstrukturen in asynchronen GUI 46 Softwaretechnologie (ST) Fensterstrukturen sind hierarchisch (Einkapselung von Widgets) Datenstruktur in Anwendung wird den Widget-Hierarchien zugeordnet Screen-Buffer zeigt die Widget-Struktur bitweise (paint()) Pro View ein Controller View 1 - Widget Tree 1 (Fenster-Struktur) Observer (play-in) Controller- Schicht Observer (play-out) Tool: Datenstruktur in Anwendungslogik (und Datenbank) Screen Buffer View 2 - Widget Tree 2 (Fenster-Struktur) Controller Controller

47 Programme mit asynchronen GUI laufen in 3 Phasen 47 Softwaretechnologie (ST) 1)Aufbau der Schichten: Aufbau der Datenstrukturen 1)Aufbau der Anwendungslogik 2)Aufbau der Controllerschicht (Aufbau der Konnektoren) 3)Aufbau der Widget-Schicht (widget hierarchies): Hierarchischer Aufbau der Fensteroberfäche durch Konstruktoraufrufe an Widgets und Einfügen in Fensterhierarchie (widget embodiment) 2)Netzaufbau 1)Vernetzung der Fensteroberfäche mit der Anwendungslogik über die Controller- Konnektoren, um Reaktionen der Anwendungslogik zu ermöglichen 1)a) Play-Out-Kollaboration: Anschluß des GUI-Reaktionscodes auf Veränderungen der Toolstruktur (View wird pull-observer des Controller, indirekt des Tools, Vorbereitung des Play-Out) 2)b) Play-In-Kollaboration: Anschluß des Tool-Reaktionscode auf Benutzereingaben (Controller ist push-observer der Widgets, Vorbereitung des Play-In) 3)Reaktionsphase (Reaktive, asynchrone Phase) s. nächste Folie

48 Zusammenspiel der Widget-Struktur und der Anwendungslogik 48 Softwaretechnologie (ST) 3) Reaktionsphase (Reaktive, asynchrone Phase) Play-In: bei der die Benutzeraktionen vom System (Ereignisverwaltung) als Ereignisobjekte ins Programm gegeben werden Event notification: Ereignismeldung, dass Benutzer etwas getan hat Data transmission: etwaiger Transfer der Daten Play-Out: Bei der in der Anwendungslogik durchgeführten Aktionen die Fensteroberfäche auf den neuesten Stand gebracht wird Event notification: Ereignismeldung, dass Anwendung etwas getan hat Data transmission: Transfer der Daten zum GUI Visualization: Neuzeichnen des GUI Der Steuerfuß eines GUI-Programms wird nie explizit spezifziert, sondern ergibt sich aus den Aktionen des Benutzers oder des Tools Die Controllerschicht hat die Kontrolle über das Verhalten reagiert auf die Ereignisse im View und im AnwendungsTool (reaktives System) steuert Redraw und Aktionen auf Tool

49 1) Aufbauphase Schichten: Aufbau der Widget-Struktur und fachl. Tool 49 Softwaretechnologie (ST) Verschiedene Techniken für den Aufbau der Datenstrukturen: Rich Client: Durch Konstruktoraufrufe und Additionen von Unterwidgets zu Oberwidgets (encapsulation) rein in Java-AWT/Swing, mit expliziter Konstruktion der Widget-Hierarchien App: App-Frameworks wie Android oder ios Web: z.b. Durch einen HTML-Baum, der von einem Brauser interpretiert wird (für Webanwendungen) Durch einen XML-Baum, der von einem XML-Parser eingelesen und als Objekt-Struktur im Speicher abgelegt wird (XUL - Firefox, XAML - Vista) Durch einen HTML-Baum, der bei Veränderungen inkrementell im Brauser nachgeladen wird (Web 2.0, Ajax) Client Server Tool View 1 - Widget Tree 1 in Anwendungslogik in html / Ajax (und Datenbank) Screen Buffer

50 Phase 2) Netzaufbauphase: Aufbau der Verbindung 50 Softwaretechnologie (ST) Die Netzaufbauphase verbindet mit Kollaborationen GUI, Input-Controller und AL für Play-In (In-Connector) AL, Output-Controller und GUI für Play-Out (Out-Connector) View 1 - Widget Tree 1 (Fenster-Struktur) Controllerschicht Tool in Anwendungslogik (und Datenbank) register as play-in Observer Play-in collaboration Screen Buffer In-Controller register as play-out-observer Out-Controller Play-out collaboration

51 Phase 3) Life Überblick MVC Dynamik 51 Softwaretechnologie (ST) Tool ist passiv. Der Controller interpretiert die Eingaben und schreibt das Tool entsprechend View ist weitg. passiv. Controller benachrichtigt View, wenn sich was im Tool geändert hat In-Controller ist ein Observer, der wenig Daten (Events) zu transferieren hat, kann also als push- Observer oder pull-observer implementiert werden; meist push-observer Out-Controller muss u.u. große Datenmengen transferieren und wird meist als pull-observer realisiert View 1 - Widget Tree 1 (Fenster-Struktur) Controllerschicht Play-in collaboration Tool in Anwendungslogik (und Datenbank) Screen Buffer widget- Observer Play-in durch push- oder pull-observer In-Controller Out-Controller Play-out collaboration Play-out durch pull-observer

52 Die Dynamik der Phase 3 ( Life ) 52 Softwaretechnologie (ST) Phase Phase 3 3 (Dynamik) (Dynamik) trennt trennt zwischen zwischen Ereignisverarbeitung Ereignisverarbeitung und und Datentransport Datentransport Die Die Konnektoren Konnektoren setzen setzen pushpushoder oder pull-observer-muster pull-observer-muster ein ein Phase Phase 3 3 behandelt behandelt Verteilung Verteilung (Web) (Web) mit mit unterschiedlichen unterschiedlichen Controller- Controller- Architekturen Architekturen Frameworks Frameworks geben geben die die Architektur Architektur vor vor (z.b. (z.b. Spring, Spring, Grails, Grails, Ruby Ruby on on Rails) Rails)

53 Gesamte MVC-Dynamik (indirektes Play-In und Play-Out) 53 Softwaretechnologie (ST) Tool ist völlig passiv, wird vom Controller geschrieben View is ebenfalls passiv, wird vom Controller aktiviert und gelesen Play-Out Observers indirektem play-out: greift indirekt über den Observer auf das Tool zu (update, data-pull) Der Controller kontrolliert, was passiert Steuert die Datenübertragung beim pull und beim push 2) register as play-in Observer View 1 - Widget Tree 1 (Fenster-Struktur) 2) register as play-out Observer Controller 1 (pro Sicht) 2) register as play-out Observer Tool in Anwendungslogik (und Datenbank) Screen Buffer 3i) notify 3i) update-pull Play-in collaboration In-Controller 3i) push-write Out-Controller 3o a) update (redraw) 3o b) pull Play-out collaboration 3o a) update 3o b) pull

54 Play-In mit passivem View und pull-in-controller; Passives Play-Out mit indirektem pull-out-view [PassiveView] 54 Softwaretechnologie (ST) v1:view register() c1:controller m:application Tool register() register() c2:controller register() v2:view notify(event) update() pull Play-In pull() writetotool() Play-Out 1 update/redraw() pull() update() pull() update/redraw() pull() Play-Out 2 update() pull()

55 Variante: Play-In mit aktivem View und push-in-controller; Passives Play-Out mit pull-out-view 55 Softwaretechnologie (ST) v1:view register() c1:controller m:application Tool register() register() c2:controller register() v2:view itemchanged(data) update(data) Push-Play-In writetotool() Play-Out 1 redraw() pull() update() pull() update() pull() Play-Out 2 redraw() pull()

56 Achtung! Hinweis auf Praktikum 56 Softwaretechnologie (ST) Zu Beginn des WS gibt es eine weitere Vorlesung über Implementierung von Interaktiven Systemen, die dieses Thema weiterführt

57 Was haben wir gelernt? 57 Softwaretechnologie (ST) GUI-Programme laufen in 3 Phasen: 1) Aufbau der Fensterfronten (widget hierarchies) durch Konstruktoraufrufe und Additionen (embodiment) (auch im Browser) 2) Netzaufbau, Aufbau der Controller-Kollaborationen Vorbereitung Play-Out: Anschluß des View-Reaktionscodes als jdk-observer des Tools Vorbereitung Play-In: Anschluß des Controller als widget-observer der Views 3) Reaktionsphase, bei der die Benutzeraktionen vom System als Ereignisobjekte ins Programm gegeben werden: der Controller als Listener benachrichtigt und ausgeführt werden (Play-In) die Views bzw. der Controller als Listener des Tools benachrichtigt werden (Play-Out) Der Kontrollfuß eines GUI-Programms wird nie explizit spezifziert, sondern ergibt sich aus den Aktionen des Benutzers Die Views reagieren auf Ereignisse im Screenbuffer, die von der Ablaufsteuerung gemeldet werden Der Controller auf Widget-Veränderungen im View und Änderungen im Tool Der Controller wird als Steuerungsmaschine implementiert und steuert alles (aktiver Konnektor) Das MVC-Framework Spring enthält eine stark geschichtete GUI- Anwendungskopplung Enthält einen kompositen Controller (komposite Steuerungsmaschine) Regelt den Verkehr zwischen Browser, Server, Servlet, Webservice-Methoden