Softwareproduktlinien Teil 6: Komponenten und Frameworks

Transkript

1 Softwareproduktlinien Teil 6: Komponenten und Frameworks Christian Kästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) 1

2 Wie Variabilität modular implementieren? Domain Eng. Feature-Modell Wiederverwendbare Implementierungsartefakte Application Eng. Feature-Auswahl Generator Fertiges Program 2

3 3 Komponenten

4 Komponenten Abgeschlossene modulare Implementierungseinheit mit Schnittstelle (black box), bietet ein Dienst an Wird zusammen mit anderen Komponenten auch von anderen Herstellern zusammengesetzt zu Softwaresystemen (Komposition) Einzeln vermarktbar und lauffähig Kontext (z. B. JavaEE, CORBA, COM+/DCOM, OSGi) und Abhängigkeiten (imports, exports) explizit spezifiziert Klein genug für Erzeugung und Wartung in einem Stück, groß genug um sinnvolle Funktion bieten zu können 4

5 Komponenten vs. Objekte/Klassen Ähnliche Konzepte: Kapselung, Interfaces, Geheimnisprinzip Objekte strukturieren ein Problem Komponenten bieten anwendbare Teilfunktionalität Objekte sind üblicherweise kleiner als Komponenten: Komponenten skalieren OOP Objekte haben häufig viele Abhängigkeiten zu anderen Objekten; Komponenten haben wenig Abhängigkeiten Interfaces von Objekten sind häufig implementierungsnah; Komponenten abstrahieren mehr 5

6 Vision: Märkte für Komponenten Komponenten können gekauft und in eigene Produkte integriert werden Best of Breed: Entwickler kann für jedes Teilsystem den besten/billigsten Anbieter auswählen Anbieter können sich auf Kernkompetenz beschränken und diese als Komponente anbieten 6

7 Komponenten eines Webshops (UML-Notation) Bestellen Großhändler Kunde anlegen Adresse ändern Kundenverwaltung Rechnung drucken Reportgenerator Einkäufe Katalog verwalten Webshop Rechnung schreiben Finanzbuchhaltung Entnehmen Einlagern Lagerhaltung Szenario: Kunde anlegen -> Einkauf -> Rechnung schreiben -> Rechnung drucken 7

8 Produktlinien aus Komponenten Features werden in verschiedenen Komponenten implementiert z. B. die Komponenten Transaktionsverwaltung, Log/Recovery, Pufferverwaltung, Optimierer Komponenten können ggf. Laufzeitvariabilität enthalten Durch Feature-Auswahl werden Komponenten ausgewählt (mapping) Der Entwickler muss Komponenten verbinden (glue code) 8

9 Beispiel: Komponente Farbe in Java package modules.colormodule; //public interface public class ColorModule { public Color createcolor(r:int,g:int,b:int) { public void printcolor(color: Color) {colorprint public void mapcolor(elem: Object, col: Color) { colormapping public Color getcolor(elem: Object) { colormapping //just one module instance public static ColorModule getinstance() { return module; private static ColorModule module = new ColorModule(); private ColorModule() { super(); public interface Color { Facade Pattern Versteckt Implementierungsdetails Gemeinsames Interface für viele Klassen Singleton Pattern Nur eine Instanz des Moduls //hidden implementation class ColorPrinter { class 9ColorMapping { ColorModule.getInstance().createColor( )

10 Produktlinien aus Komponenten Feature-Modell Mapping von Features zu Komponenten Komponentensammlung Component10 Component6 Component2 Component12 Component5 Component1 Component9 Feature-Auswahl als Eingabe Component3 Component7 Component4 Component8 Component11 Component2 Component6 Entwickler baut fertiges Programm aus Komponenten Component9 Component8 Feature-Auswahl Komponentenauswahl Menge von Komponenten Fertiges Program 10

11 Wie Komponenten bestimmen? Markt für beliebige Komponenten funktioniert nicht Zu kleine Komponenten hoher Aufwand Zu große Komp. kaum wiederverwendbar Produktlinien liefern nötige Domänenanalyse Welche Teilfunktionalität wird in welcher Granularität wiederverwendet Systematische Wiederverwendung 11 (Tangram)

12 Exkurs 12

13 Bewertung Produktlinien aus Komponenten In der Industrie üblich (Beispiel Heimelektronik mit Koala-Komponenten von Phillips) Produktlinien zum Domain Engineering, zur Organisation der Entwicklung, Systematische (geplante) Wiederverwendung von Komponenten Keine vollständige Automatisierung, hoher Entwicklungsaufwand (glue code) im Application Engineering Keine freie Feature-Auswahl 13

14 Diskussion Modularität Komponenten verstecken interne Implementierung Idealerweise kleine Interfaces Feature-Kohäsion aber Grobe Granularität Seitenwechselstrategien, Suchalgorithmen, Locking im B-Baum, oder VARCHAR als Komponente? Farben oder gewichtete Kanten im Graph als Komp.? Funktionalität ggf. schwer als Komponente zu kapseln Transaktionsverwaltungskomponente? 14

15 Services Ähnlich zu Komponenten: kapseln Teilfunktionalität (Dienste) i.d.r. verteiltes Szenario Bus-Kommunikation, Web Services, SOAP, REST Produktlinien durch Verbinden von Services, i.d.r. mit scripting (glue code) Viele Werkzeuge verfügbar (teils Managementgerecht ) 15

16 16 Frameworks

17 Frameworks Menge abstrakter und konkreter Klassen Abstrakte Struktur, die für einen bestimmten Zweck angepasst/erweitert werden kann vgl. Template Method Pattern und Strategy Pattern Wiederverwendbare Lösung für eine Problemfamilie in einer Domäne Punkte an denen Erweiterungen vorgesehen sind: hot spots (auch variation points, extension points) Umkehrung der Kontrolle, das Framework bestimmt die Ausführungsreihenfolge Hollywood Prinzip: Don t call us, we ll call you. 17

18 Plug-ins Erweiterung eines Frameworks Spezielle Funktionen bei Bedarf hinzufügen Üblicherweise getrennt kompiliert; third-party Beispiele: programme, Graphikprogramme, Media- Player, Webbrowser 18

19 Web Portal Webapplikation- Frameworks wie Struts, die grundlegende Konzepte vorgeben und vorimplementieren Entwickler konzentrieren sich auf Anwendungslogik statt Navigation zwischen Webseiten 19 <?php class WebPage { function getcssfiles(); function getmoduletitle(); function hasaccess(user u); function printpage();?> <?php class ConfigPage extends WebPage { function getcssfiles() { function getmoduletitle() { return Configuration ; function hasaccess(user u) { return user.isadmin(); function printpage() { print <form><div> ;?>

20 Eclipse Eclipse als Framework für IDEs Nur sprachspezifische Erweiterungen (Syntax Highlighting, Compiler) müssen implementiert werden Der gemeinsame Teil (Editoren, Menüs, Projekte, Verzeichnisbaum, Copy & Paste & Undo Operationen, CVS, uvm.) ist durch das Framework vorgegeben Framework aus vielen kleineren Frameworks 20

21 Eclipse JDT WTP SAPinst Workbench Build Debug Edit JUnit Refactor Launch Platform Ant IDE Cheat Sheets Search Debug Team Help Update Views Resources Console Editors Forms Text Editors Compare J2EE Web Control Items Component Messages Resourcepool Dialogs Weitere Erweiterungen Table Script Meta-Dialogs Prerequisite C. Rich Client Platform Workbench Help JFace 21 Core Runtime OSGi SWT

22 Weitere Framework-Beispiele Frameworks für graphische Benutzeroberflächen, z.b. MacApp, Swing, SWT, MFC Multimedia-Frameworks, z.b. DirectX Instant Messenger-Frameworks, z.b. Miranda, Trillian,... Compiler-Frameworks, z.b. Polyglot, abc 22

23 Framework-Implementierung: Mini-Beispiel Familie von Dialogen, bestehend aus Textfeld und Button 90% des Quelltexts sind gleich Main Methode Initialisierung von Fenster, Textfeld und Button Layout Schliessen des Fensters 23

24 Taschenrechner public class Calc extends JFrame { private JTextField textfield; public static void main(string[] args) { new Calc().setVisible(true); public Calc() { init(); protected void init() { JPanel contentpane = new JPanel(new BorderLayout()); contentpane.setborder(new BevelBorder(BevelBorder.LOWERED)); JButton button = new JButton(); button.settext("calculate"); contentpane.add(button, BorderLayout.EAST); textfield = new JTextField(""); textfield.settext("10 / 2 + 6"); textfield.setpreferredsize(new Dimension(200, 20)); contentpane.add(textfield, BorderLayout.WEST); button.addactionlistener(/* code zum berechnen */); this.setcontentpane(contentpane); this.pack(); this.setlocation(100, 100); this.settitle("my Great Calculator"); // code zum schliessen des fensters 24 Quelltext für alle Varianten fast gleich, nur roter Quelltext unterscheidet sich (hot spots)

25 White-Box Frameworks Erweiterung durch überschreiben und hinzufügen von Methoden (vgl. Template Method Pattern) Interna des Framework müssen verstanden werden -> schwierig zu lernen Flexible Erweiterung Viele Subklassen nötig -> ggf. unübersichtlich Status direkt verfügbar durch Superklasse Keine Plug-ins, nicht getrennt kompilierbar 25

26 Taschenrechner als Whitebox-Framework public abstract class Application extends JFrame { protected abstract String getapplicationtitle(); //Abstrakte Methoden protected abstract String getbuttontext(); protected String getinititaltext() {return ""; protected void buttonclicked() { private JTextField textfield; public Application() { init(); protected void init() { JPanel contentpane = new JPanel(new BorderLayout()); contentpane.setborder(new BevelBorder(BevelBorder.LOWERED)); JButton button = new JButton(); button.settext(getbuttontext()); contentpane.add(button, BorderLayout.EAST); textfield = new JTextField(""); textfield.settext(getinititaltext()); textfield.setpreferredsize(new Dimension(200, 20)); contentpane.add(textfield, BorderLayout.WEST); button.addactionlistener(/* buttonclicked(); */); this.setcontentpane(contentpane); this.pack(); this.setlocation(100, 100); this.settitle(getapplicationtitle()); // code zum schliessen des fensters protected String getinput() { return textfield.gettext(); 26

27 Taschenrechner als Whitebox-Framework public abstract class Application extends JFrame { protected abstract String getapplicationtitle(); //Abstrakte Methoden protected abstract String getbuttontext(); protected String getinititaltext() {return ""; protected void buttonclicked() { private JTextField textfield; public Application() { init(); protected void public init() class { Calculator extends Application { JPanel contentpane protected String = new getbuttontext() JPanel(new BorderLayout()); { return "calculate"; contentpane.setborder(new protected String getinititaltext() BevelBorder(BevelBorder.LOWERED)); { return "(10 3) * 6"; JButton protected button = new void JButton(); buttonclicked() { button.settext(getbuttontext()); JOptionPane.showMessageDialog(this, "The result of "+getinput()+ contentpane.add(button, " is BorderLayout.EAST); "+calculate(getinput())); textfield protected = new JTextField(""); String getapplicationtitle() { return "My Great Calculator"; textfield.settext(getinititaltext()); public static void main(string[] args) { textfield.setpreferredsize(new Calculator().setVisible(true); Dimension(200, 20)); contentpane.add(textfield, BorderLayout.WEST); button.addactionlistener(/* buttonclicked(); */); this.setcontentpane(contentpane); this.pack(); public this.setlocation(100, class Ping extends 100); Application { this.settitle(getapplicationtitle()); protected String getbuttontext() { return "ping"; // code zum protected schliessen String des getinititaltext() fensters { return " "; protected void buttonclicked() { /* */ protected String getinput() protected { return String textfield.gettext(); getapplicationtitle() { return "Ping"; public static void main(string[] args) { new Ping().setVisible(true); 27

28 Black-Box Frameworks Einbinden des anwendungsspezifischen Verhalten durch Komponenten mit speziellem Interface (plug-in) vgl. Strategy Pattern, Observer Pattern Nur das Interface muss verstanden werden einfacher zu lernen, aber aufwendiger zu entwerfen Flexibilität durch bereitgestellte Hot Spots festgelegt, häufig Design Pattern Status nur bekannt wenn durch Interface verfügbar Insgesamt besser wiederverwendbar (?) 28

29 Taschenrechner public class Application extends JFrame { private JTextField textfield; private Plugin plugin; public Application(Plugin p) { this.plugin=p; p.setapplication(this); init(); protected void init() { JPanel contentpane = new JPanel(new BorderLayout()); contentpane.setborder(new BevelBorder(BevelBorder.LOWERED)); JButton button = new JButton(); if (plugin!= null) button.settext(plugin.getbuttontext()); else button.settext("ok"); contentpane.add(button, BorderLayout.EAST); textfield = new JTextField(""); if (plugin!= null) textfield.settext(plugin.getinititaltext()); textfield.setpreferredsize(new Dimension(200, 20)); contentpane.add(textfield, BorderLayout.WEST); if (plugin!= null) button.addactionlistener(/* plugin.buttonclicked(); */); this.setcontentpane(contentpane); public String getinput() { return textfield.gettext(); public interface Plugin { String getapplicationtitle(); String getbuttontext(); String getinititaltext(); void buttonclicked() ; void setapplication(application app); 29

30 public class Application extends JFrame { private JTextField textfield; private Plugin plugin; public Application(Plugin p) { this.plugin=p; p.setapplication(this); init(); protected void init() { JPanel contentpane = new JPanel(new BorderLayout()); contentpane.setborder(new BevelBorder(BevelBorder.LOWERED)); Taschenrechner JButton button = new JButton(); if (plugin!= null) button.settext(plugin.getbuttontext()); else button.settext("ok"); contentpane.add(button, BorderLayout.EAST); textfield = new JTextField(""); if (plugin!= null) textfield.settext(plugin.getinititaltext()); textfield.setpreferredsize(new public class CalcPlugin Dimension(200, implements20)); Plugin { contentpane.add(textfield, privateborderlayout.west); Application application; if (plugin!= null) public void setapplication(application app) { this.application = app; button.addactionlistener(/* public String getbuttontext() plugin.buttonclicked(); { return "calculate"; */); this.setcontentpane(contentpane); public String getinititaltext() { return "10 / 2 + 6"; public void buttonclicked() { JOptionPane.showMessageDialog(null, "The result of " public String getinput() { return textfield.gettext(); + application.getinput() + " is " + calculate(application.gettext())); public String getapplicationtitle() { return "My Great Calculator"; public interface Plugin { String getapplicationtitle(); String getbuttontext(); String getinititaltext(); void buttonclicked() ; void setapplication(application app); class 30CalcStarter { public static void main(string[] args) { new Application(new CalcPlugin()).setVisible(true);

31 public class Application extends JFrame implements InputProvider { private JTextField textfield; private Plugin plugin; public Application(Plugin p) { this.plugin=p; p.setapplication(this); init(); protected void init() { public interface InputProvider { JPanel contentpane = new JPanel(new BorderLayout()); String getinput(); Weitere Entkopplung moeglich contentpane.setborder(new BevelBorder(BevelBorder.LOWERED)); JButton button = new JButton(); if (plugin!= null) button.settext(plugin.getbuttontext()); else button.settext("ok"); contentpane.add(button, BorderLayout.EAST); textfield = new JTextField(""); if (plugin!= null) textfield.settext(plugin.getinititaltext()); textfield.setpreferredsize(new public class CalcPlugin Dimension(200, implements20)); Plugin { contentpane.add(textfield, privateborderlayout.west); InputProvider application; if (plugin!= null) public void setapplication(inputprovider app) { this.application = app; button.addactionlistener(/* public String getbuttontext() plugin.buttonclicked(); { return "calculate"; */); this.setcontentpane(contentpane); public String getinititaltext() { return "10 / 2 + 6"; public void buttonclicked() { JOptionPane.showMessageDialog(null, "The result of " public String getinput() { return textfield.gettext(); + application.getinput() + " is " + calculate(application.getinput())); public String getapplicationtitle() { return "My Great Calculator"; public interface Plugin { String getapplicationtitle(); String getbuttontext(); String getinititaltext(); void buttonclicked() ; void setapplication(inputprovider app); class 31CalcStarter { public static void main(string[] args) { new Application(new CalcPlugin()).setVisible(true);

32 Plugins laden Typisch für viele Frameworks: Plugin-Loader sucht in Verzeichnis nach DLL/Jar/XML Dateien testet ob Datei ein Plugin implementiert prüft Abhängigkeiten initialisiert Plugin Häufig zusätzlich GUI für Plugin-Konfiguration Beispiele: Eclipse (plugin-verzeichnis + Jar) Miranda (plugins-verzeichnis + DLL) Alternativ: Plugins in Konfigurationsdatei festlegen oder StarterProgramm generieren 32

33 Beispiel Plugin Loader (benutzt Java Reflection) public class Starter { public static void main(string[] args) { if (args.length!= 1) System.out.println("Plugin name not specified"); else { String pluginname = args[0]; try { Class<?> pluginclass = Class.forName(pluginName); new Application((Plugin) pluginclass.newinstance()).setvisible(true); catch (Exception e) { System.out.println("Cannot load plugin " + pluginname + ", reason: " + e); 33

34 Mehrere Plugins vgl. Observer Pattern Mehrere Plugins laden und registrieren Bei Ereigniss alle Plugins informieren Für unterschiedliche Aufgaben: spezifische Plugin-Interfaces public class Application { private List<Plugin> plugins; public Application(List<Plugin> plugins) { this.plugins=plugins; for (Plugin plugin: plugins) plugin.setapplication(this); public Message processmsg (Message msg) { for (Plugin plugin: plugins) msg = plugin.process(msg);... return msg; 34

35 Frameworks fuer Produktlinien Domain Eng. Feature-Modell Mapping von Features zu Plugins Framework + Plugins Application Eng. 35 Feature-Auswahl Feature-Auswahl als Eingabe Pluginauswahl (und ggf. Startkonfiguration generieren) Anwendung = Framework mit passenden Plugins

36 Frameworks für Produktlinien Bewertung Vollautomatisierung möglich Modularität Praxiserprobt Erstellungsaufwand und Laufzeit-Overhead für Framework/Architektur Vorplanung nötig, Frameworkdesign erfordert Erfahrung Schwierige Wartung, Evolution Grobe Granularität oder riesige Interfaces Plugin für Transaktionsverwaltung, VARCHAR oder gewichtete Kanten? 36

37 37 Querschneidende Belange

38 Querschneidende Belange Engl. crosscutting concerns Behauptung: Nicht alle Belange (Features) in einem Programm können mittels Objekten (Komponenten, Plugins) modularisiert werden Belange sind semantisch zusammenhängende Einheiten Aber ihre Implementierung ist manchmal verstreut, vermischt und repliziert im Code

39 Weitere Querschneidende Belange class DatabaseApplication //... Datenfelder //... Logging Stream //... Cache Status public void authorizeorder( Data data, User currentuser,...){ // prüfe Autorisierung // Objekt sperren für Synchronisation // Aktualität des Puffers prüfen // Start der Operation loggen // eigentliche Operation ausführen // Ende der Operation loggen // Sperre auf Objekt freigeben public void startshipping( OtherData data, User currentuser,...){ // prüfe Autorisierung // Objekt sperren für Synchronisation // Aktualität des Puffers prüfen // Start der Operation loggen // eigentliche Operation ausführen // Ende der Operation loggen // Sperre auf Objekt freigeben Code für verschiedene Belange vermischt Code repliziert Im Beispiel Operationen modular, aber Sperren, Logging, Puffer und Authentifizierung nicht

40 Scattering und Tangling Verstreuter Code (code scattering) Code, der zu einem Belang gehört, ist nicht modularisiert, sondern im gesamten Programm verteilt Häufig kopierter Code (auch wenn es je nur ein einzelner Methodenaufruf ist) Oder stark verteilte Implementierung von (komplementären) Teilen eines Belangs Vermischter Code (code tangling) Code, der zu verschiedenen Belangen gehört, ist in einem Modul (oder einer Methode) vermischt

41 Eine Frage der Größe l Beispiel: Example: Zeitmanagement Session expiration von Sessions in im Apache Tomcat Server als the Bestandteil Apache der Tomcat Session-Verwaltung Server

42 Probleme querschneidender Belange Belange verschwinden in der Implementierung Was gehört alles zu einem Belang? Bei Wartungsaufgaben muss der ganze Quelltext durchsucht werden Schwierige Arbeitsteilung Für unterschiedliche Belange kann es unterschiedliche Experten geben; alle müssen am gleichen Code-Fragment arbeiten Geringere Produktivität, schwierige Evolution Beim Hinzufügen neuer Funktionalitäten muss sich der Entwickler um diverse andere Belange kümmern, die erstmal nur ablenken (Lesbarkeit, Erfassbarkeit)

43 Alternative Implementierung (Command Pattern) class SecureSystem extends System private User currentuser; public void login() { /*... */ public void executeoperation(operation o) { if (o instanceof AuthorizeOrder) if (!currentuser.isadmin()) denyaccess(); else o.execute(); if (o instanceof StartShipping) { if (!o.haswriteaccess()) denyaccess(); else o.execute(); Authentifizierung wurde modularisiert Dadurch sind aber die anderen Belange (hier Operationen) nicht mehr modular

44 Weiterer Versuch Methodenaufrufe Belange wie Sperren, Logging, Puffer und Authentifizierung werden in eigene Module ausgelagert Scattering und Tangling nur noch von Methodenaufrufen Übersichtlicher, aber immer noch explizite Aufrufe im Code -> Viele Extension Points in Framework nötig; große Interfaces für Komponenten class BusinessClass public void importantoperation( Data data, User currentuser,...){ checkauth(currentuser); startsynchronization(); checkcache(); logstart(); // eigentliche Operation ausfuehren logend(); endsynchronization();

45 Weiterer Versuch Middleware Middleware kann sich um querschneidende Belange kümmern; Entwickler implementiert nur noch eigentliche Operationen (inversion of control) Beispiel: Enterprise Java Beans stellen zur Verfügung: verteilte Objekte, Persistenz, Transaktionsverwaltung, Authentifizierung und Autorisierung, Synchronisation Aufwendige Architektur Nicht alle Belange von Middleware erfassbar, insbesondere Belange der Businesslogik

46 Tyrannei der Dominanten Dekomposition Viele Belange können modularisiert werden, jedoch nicht immer gleichzeitig Problemstellung nur in einer Richtung modularisierbar Im Graph können Farben modularisiert werden dann sind die Datenstrukturen (Node, Edge) verteilt Entwickler wählen eine Dekomposition aus (z.b. Operationen, Authentifizierung, Datenstrukturen), aber einige andere Belange schneiden quer Gleichzeitige Modularisierung entlang verschiedener Dimensionen nicht möglich

47 Exkurs: Expression Problem Frage: Wie weit kann man Datenstrukturen und Methoden abstrahieren, so dass man beide unabhängig erweitern kann ohne bestehenden Code zu ändern (oder sogar ohne neucompilieren des bestehenden Codes) mehrfach, in beliebiger Reihenfolge und ohne (nicht-triviale) Code-Replikation

48 Ausdrücke (expressions) Aufgabe: Mathematische Ausdrücke werden in einer Baumstruktur gespeichert und können ausgerechnet und ausgegeben werden * + 1,73 5 ln 50

49 Implementierung 1: Daten-zentriert Rekursive Klassenstruktur (Composite Pattern) Für jede Operation eine Methode in jeder Klasse definiert «interface» Term +eval() +print() Number Plus Product Ln -value +eval() +print() -term1 -term2 +eval() +print() -term1 -term2 +eval() +print() -term +eval() +print()

50 Problem von Implementierung 1 Ausdrücke sind modular Neue Operationen, z. B. drawtree oder simplify, können nicht einfach hinzugefügt werden Alle bestehenden Klassen müssen angepasst werden! Operationen sind querschneidend zu den Ausdrücken

51 Implementierung 2: Methoden-zentriert Nur eine Methode accept pro Klasse Methoden werden mit dem Visitor-Pattern implementiert «interface» Term +accept(in Visitor) «interface» Visitor +visitnumber() +visitsum() +visitproduct() Number Sum Product PrintVisitor EvalVisitor -value +accept(in visitor) -term1 -term2 +accept(in visitor) -term1 -term2 +accept(in visitor) +visitnumber() +visitsum() +visitproduct() +visitnumber() +visitsum() +visitproduct() (Ln Klasse aus Platzgründen ausgelassen)

52 Codebeispiel Methoden-zentriert interface Term { void accept(visitor v); class Number { float value; void accept(visitor v) { v.visitnumber(this); class Sum { Term term1, term2; void accept(visitor v) { v.visitsum(this); class Product { Term term1, term2; void accept(visitor v) { v.visitproduct(this); interface Visitor { void visitnumber(number n); void visitsum(sum s); void visitproduct(product p); class PrintVisitor { void visitnumber(number n) { System.out.print(n.value); void visitsum(sum s) { System.out.print('('); s.term1.accept(this); System.out.print('+'); s.term2.accept(this); System.out.print(')'); void visitproduct(product p) { s.term1.accept(this); System.out.print('*'); s.term2.accept(this); // Main: // term.accept(new PrintVisitor());

53 Problem von Implementierung 2 Operationen sind modular Neue Ausdrücke, z. B. Min oder Power können nicht einfach hinzugefügt werden Für jede neue Klasse müssen alle Visitor-Klassen angepasst werden Ausdrücke sind querschneidend zu den Operationen

54 Expression Problem Nur sehr schwer möglich Ausdrücke und Operationen darauf gleichzeitig zu modularisieren (komplizierte Lösungen mit Java 1.5 Generics existieren) Daten-zentrierter Ansatz Neue Ausdrücke können direkt hinzugefügt werden: modular Neue Operationen müssen in alle Klassen eingefügt werden: nicht modular Methoden-zentrierter Ansatz Neue Ausdrücke können als weiterer Visitor hinzugefügt werden: modular Für neue Klassen müssen alle bestehenden Visitors erweitert werden: nicht modular

55 Expression Problem Grafisch Daten-zentriert Methoden-zentriert (Visitor) plus power plus power eval eval print print (a) (b) plus power ln plus power ln eval eval print print simplify simplify (c) (d) Ausblick: Neue Sprachansätze Ausblick: Feature-Interaktionen

56 Typische Beispiele für querschneidende Belange Logging: Meldung nach jeder Methode Caching/Pooling: Code bei jedem Erzeugen eines Objektes Synchronisierung/Locking: Erweiterung vieler Methoden mit lock/unlock-aufrufen Features in Produktlinien!

57 Dilemma Es ist nicht immer möglich alle Belange zu modularisieren (Tyrannei ) Ein Grundmaß an verstreutem und vermischtem Code in OOP-Implementierungen ist normal Einige Belange sind immer orthogonal zu anderen: querschneidende Belange Features in Produktlinien sind häufig betroffen

58 58 Preplanning Problem

59 Preplanning Problem Erweiterungen sind nicht ad-hoc möglich, sondern müssen voraus geplant werden Es müssen explizit Erweiterungsmöglichkeiten vorgesehen werden Extension Points in Frameworks Interfaces/Parameter in Komponenten Ohne passenden Extension Point keine modulare Erweiterung möglich

60 Preplanning Problem - Beispiel Stack-Methoden sollen synchronisiert werden Modulare Erweiterung mittels Subklasse oder Delegation Basis-Code class Stack { /*... */ class Main { public static void main( String[] args) { Stack stack = new Stack(); stack.push('foo'); stack.push('bar'); stack.pop(); Spätere ungeplante Erweiterung class LockedStack extends Stack { private void lock() { /*... /* private void unlock() { /*... /* public void push(object o) { lock(); super.push(o); unlock(); public Object pop() { lock(); Object result = super.pop(); unlock(); return result;

61 Preplanning Problem - Beispiel II Problem: Instantiierung des Stacks im Basiscode muss angepasst werden Keine Möglichkeit ohne Änderung des Basiscode (nichtmodular) Alternative Design Pattern: Factory statt direkter Instantiierung (erlaubt modulare Erweiterung) Framework mit passendem Extension Point Erweiterungsmöglichkeiten müssen antizipiert werden (preplanning) oder nachträglich dem Basiscode hinzugefügt werden (nicht-modular)

62 Zusammenfassung Modularisierung von Features mit Komponenten und Frameworks Keine Vollautomatisierung, Laufzeitoverhead, grobe Granularität Grenzen bei querschneidenen Belangen und feiner Granularität Modularität erfordert Planung Nicht für alle Produktlinien geeignet (z.b. Graphbibliothek, eingebettete Datenbanken) 62

63 Ausblick Neue Programmierkonzepte Analyse Objekt-Orientierung und deren Grenzen Feature-Orientierung Aspekt-Orientierung 63

64 Literatur C. Szyperski: Component Software: Beyond Object- Oriented Programming. Addison-Wesley, 1998 [Standardwerk Komponentenorientierte Softwareentwicklung] R. Johnson and B. Foote, Desiging reusable classes, Journal of Object-Oriented Programming, 1(2):22-35, 1988 [OOP Wiederverwendung, insb. Frameworks] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison-Wesley, 2003 [Architekturgetriebene Produktlinien, typischerweise Frameworks] 64