PAC vs. MVC. Dr. Jörg-Volker Mü ller LINEAS Integral Software GmbH Braunschweig. Komponenten-Architekturen fü r grafische Oberflächen

Transkript

1 PAC vs. MVC Komponenten-Architekturen fü r grafische Oberflächen Dr. Jörg-Volker Mü ller LINEAS GmbH Braunschweig

2 LINEAS GmbH Softwarehaus der LINEAS-Gruppe (6 Firmen, Standorte BS, HH, H, WOB) gegrü ndet Juli 1999 über 12 Jahre Erfahrung in der Software- Entwicklung in den Bereichen Dispositionssysteme Technische Systeme (Telekommunikation, Verkehrstechnik) Standardsoftware (PPS) Datenbanklösungen Zielsetzung: Entwicklung einer leistungsfähigen Basisarchitektur zur Verbesserung der Softwareentwicklung 2

3 LINEAS GmbH Fokus: Lösungen fü r eine vernetzte Welt Datenbankgestü tzte Applikationen untereinander vernetzte Daten verteilte Systeme ständige Verbesserung durch Integration von neuen Abläufen und Strukturen in das Basisprodukt Integral.dX Objekt-orientierte Basisarchitektur Kunden Anwender im Mittelstand Abteilungen von Großunternehmen Partner Realisierung von individuellen Projekten Entwicklung von Produkten auf Basis Integral.dX 3

4 Schlü sselarchitektur Customer Code GUI Reports Diagrams Workflow Model RDB Mapping Ressource Database OODB Mapping? 4

5 Integral.dX - Model Objekt-Orientierte Basisarchitektur 100% pure Java Mapping fü r relationale Datenbanken getypter Zugriff auf Objekte kunde = new Kunde(...); String name = kunde.getname(); generischer Zugriff auf Objekte String name = (String)o.get(Kunde.nameDecl); Meta-Daten zur Laufzeit Kunde.Type.declarations() 5

6 Integral.dX - GUI (halb)automatisch erzeugte Oberflächen Tree-Darstellung zur Navigation Einzelsatz-Editor Tabellen-Editor Auswertung der Meta- Daten Generierung der Oberfläche zur Laufzeit 6

7 Unzulänglichkeiten GUI Architektur zu monolithisch Änderungen schwer einzubauen zu sehr auf Generierung abgestellt kundenspezifische Erweiterungen erfordern u. U. Ä nderungen am generischen Code Verteilung nur an der Datenbank- Schnittstelle möglich (2-tier) Swing 7

8 To Swing or Not To Swing? + mächtig + viele Oberflächenelemente + leicht zu bedienen speicherintensiv komplex langsam sehr groß unnötiger Ballast (Pluggable Look&Feel) niedriges Abstraktionsniveau 8

9 Anforderungen GUI++ Komponenten Komponentenbasiertes System Mix von Standard- und Spezial-Komponenten Wenig Programmieraufwand bei der Konstruktion IDE-Integration Grafischer Aufbau von Oberflächen Multi Client Windows, Motif HTML / WAP PDA (Palm, Psion, WinCE) Thin Client Client/Server (3-tier Architektur) Zero Administration 9

10 Anforderungen Komponenten IDE-Integration Multi Client Thin Client 10

11 java.beans JavaBeans = Komponenten, die auf dem AWT- Toolkit basieren JavaBean Klasse, die bestimmten Kriterien genü gt hat Eigenschaften (Properties) kann Ereignisse melden (Events, ü ber Listener) durch Introspektion Abfrage der Bean- Eigenschaften zur Laufzeit möglich (Meta- Ebene) Java-IDEs arbeiten mit JavaBeans Integration eigener Beans leicht möglich 11

12 java.beans.beancontext (1) Hierarchie von JavaBeans automatischer Zugriff auf den Kontext BeanContext verwaltet die Kinder Integration mit JavaBeans Container Beans implementieren BeanContext Beans implementieren BeanContextChild Container implements BeanContext JavaBean JavaBean implements BeanContextChild 12

13 java.beans.beancontext (2) BeanContextServices Erweiterung von BeanContext liefert Services (= Implementierungen von Interfaces) fü r die Kinder (transitive Suche) Services können hinzugefü gt oder weggenommen werden BeanContextServices bcs = (BeanContextServices)getBeanContext(); BellService bell = (BellService)bcs.getService( this, this, BellService.class, null, null ); bell.ring(); 13

14 Model-View-Controller Model enthält/kennt die Daten kennt C/V nicht benachrichigt View bei Änderungen kann mehrere C/V haben View zeigt Daten an kennt Model Controller steuert die Benutzereingaben kennt Model Controller Model View 14

15 Variante: MVC in Java AWT und Swing verwenden eine modifizierte MVC- Version Component Component = View+Controller Daten per get/set in Model Model 15

16 Anbindung an Daten Model kann den Datenwert enthalten Controller View Typisch in Smalltalk: Model ist Adapter, der die Daten bereitstellt Konsequenz: Mehrstufige Objekt- Hierarchie Hohe Flexibilität (Baukastenkonzept) leicht aufzubauen, schwer abzubauen unü bersichtliche Struktur Daten Model Model (Adapter) Daten 16

17 Beispiel: PersonEditor Editieren von Adressen (Objekt: Person) besteht aus 15 Komponenten 1x JFrame 2x JPanel 5x JLabel 5x JTextField 2x Buttons 17

18 PersonEditor: AWT/Swing Person Editor Frame Monika Mustermann Edit Panel Button Panel Name Label Name TextField Vorname Label Vorname TextField... Speichern Button Abbrechen Button Name Model Vorname Model 18

19 Vor-/Nachteile Passives Model (AWT/Swing) Load/Store notwendig Validierung beim PersonEditor PersonEditor muss alle relevanten Komponenten explizit ansprechen Aktives Model (Smalltalk/Integral.GUI) Adapter verlagert Teil der Logik in Modell (Person) Kenntnis der Komponenten (durch den PersonEditor) nur fü r GUI-Abläufe notwendig ggf. schwerer abzubauen komplexeres Objekt-Geflecht 19

20 PAC - Pattern Presentation Darstellung Benutzereingaben Abstraction hält Daten Control Verbindung A-P Kommunikation nach außen Abstraction Control Presentation 20

21 PAC - Eigenschaften Man spricht von Agenten Agenten bilden eine Hierarchie Bottom Agent Intermediate-Agent (= Container) Top-Agent Agenten kommunizieren über standardisierte Protokolle miteinander (synchronized) Nur fü r größere Komponenten geeignet A A A C Intermediate P C C Intermediate P Intermediate A C C C Bottom P A Bottom P A P Bottom P 21

22 PAC - Literatur Joëlle Coutaz: PAC, an Object Oriented Model for Dialog Design Proceedings Interact 87 ( ) North Holland, 1987 Gaëlle Calvary, Joëlle Coutaz, Laurence Nigay: From Single-User Architectural Design to PAC: a Generic Software Architecture Model Conference on Human Factors in Computing Systems Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal: Pattern-orientierte Software-Architektur Presentation-Abstraction-Control ( ) Addison-Wesley, 1998 Amazon 22

23 PAC redefined - Grundaufbau Wegfall der generischen Kommunikation Agent = Control = Klasse Presentation ist innere Klasse Abstraction ist innere Klasse (oder Instanz-Variablen des Control/Agenten) Control konform JavaBeans (Properties, Events) Container (spezielle Agenten) konform BeanContextServices Presentation Agent (= Control) Abstraction 23

24 PAC redefined - Datenzugriff get/set-philosophie ist immer möglich Zugriff ü ber Services Context (Parent) stellt Services fü r den Zugriff zur Verfü gung Bereitstellung von Services fü r Daten getvalue setvalue addvaluechangedlistener removevaluechangedlistener Aspect (Eigenschaft des Agenten) ist Schlü ssel zum Service Services können wahlweise Speicher oder Adapter sein 24

25 PAC redefined Value Services PersonEditor StringValueService( Name ) FrameAgent Monika Mustermann getservice( StringValueService.class Name ) PanelAgent StringEditAgent Aspect= Name 25

26 PAC redefined Services Services fü r Aktionen zum Auslösen einzelner Aktionen fü r Buttons, MenuItems usw. Aktion kann enabled/disabled werden (ü ber Listener) Services fü r Labels z. B. Zugriff auf Label-Datenbank Labels konfigurierbar (mehrsprachig) Lose Kopplung: Editor muss konkrete Kinder nicht kennen! Kinder mü ssen nichts von der konkreten Anwendung wissen 26

27 Integration in Integral.dX Bereitstellung von Standard-Agenten (unabhängig von Integral.dX!) StringEditAgent, DateEditAgent, usw. Buttons, Labels, CheckBoxes, RadioButtons, Lists, ComboBoxes, Trees, Tables, Panels Bereitstellung von Objekt-Editoren (fü r dx-objekte) generischer Mechanismus fü r Services (Value, Label, Action usw.) AutomaticPanel (fü r dx-objekte) erzeugt Label/Editoren automatisch durch externe Konfiguration (Datenbank) einstellbar Spezielle Agenten sind jederzeit integrierbar! 27

28 Anforderungen Komponenten IDE-Integration Multi Client Thin Client 28

29 Anbindung an IDEs Agent = JavaBean + BeanContext(Child) Properties sind editierbar Integration als JavaBean möglich BeanContext wird (noch?) nicht unterstü tzt Agents werden nicht als GUI-Beans erkannt warten auf BeanContext-Unterstü tzung Glasgow ist seit einem Jahr angekü ndigt 29

30 Anbindung an IDEs (Forts.) IDEs erwarten java.awt.component! Alternativen: 1. Agent erbt von java.awt.component und ü bernimmt die gesamte Funktionalität (nur Design-Time) 2. Agent erbt von JPanel und malt die SwingPresentation in dieses Panel 3. Proxy dazwischen: Agent erbt von Component, speichert die SwingPresentation und leitet alle Aufrufe an diese weiter 4. Agent erbt von BeanContextChildComponentProxy und deligiert nur (4) ist praktikabel, wird aber (noch?) nicht unterstü tzt 30

31 Anforderungen Komponenten IDE-Integration Multi Client Thin Client 31

32 Multi Client Austauschbarkeit der Presentation (gemeinsames Interface) generiert ü ber Factory Method TopAgent ü bernimmt die Ankopplung an die tatsächliche Oberfläche Swing Presentation Presentation Agent (= Control) Abstraction HTML Presentation 32

33 Anforderungen Komponenten IDE-Integration Multi Client Thin Client 33

34 Alternativen Alpha-Terminal 3270 HTML/JavaScript X11/Motif Citrix MetaFrame Remote AWT Näher am HTML-Konzept (seitenorientiert)! 34

35 Thin Client spezielle Presentation sendet Informationen zum Client Client stellt Oberfläche dar Client interagiert mit dem Benutzer bestimmte ausgezeichnete Elemente (z. B. Buttons) sorgen fü r Rü ckmeldung an Server Server kann neue Werte hochladen oder Oberfläche komplett austauschen Client kann mehrere Seiten halten (vom Server abrufbar) Client kann fü r die jeweilige Architektur optimiert werden 35

36 Anforderungen Komponenten IDE-Integration Multi Client Thin Client 36

37 Fazit Komponentenstruktur sehr gute Kombinierbarkeit leicht erweiterbar um eigene Komponenten Mischung generierte/individuelle Oberfläche IDE-Integration geplant Multi-Client-fähig Thin Client Client bleibt unverändert Zugriff auf Daten von ü berall Look-and-feel des Clients hochoptimierte Oberfläche (wenn nötig) Lose Kopplung Hoher Zusammenhalt 37