Softwarekomposition und Metaprogrammierung

1. Softwarekomposition und Metaprogrammierung • Einführung • Ansätze zur Komposition • Subjekt-orientiertes Programmieren SOP • Erweiterungen des objekt-orientierten Paradigmas (composition filters) • Kalküle für Komponentensysteme (N-Kalkül) • Metaobjekt-Komposition • Template Metaprogramming • Invasive Komposition • Konzepte: Webepunkte, Kompositionsschnittstelle • Anwendungsbeispiele • Werkzeuge und Architekturen (COMPOST)

2. Literatur • /ben/papers/unpacked/Metaprogramming • SOP: http://www.research.ibm.com/sop/sophome.htm • LambdaN: Dami, Laurent. Software Composition. Dissertation Universität Genf. 1997 • Mulet, P., Malenfant, J., Cointe, P. Towards a Methodology for Explict Composition of MetaObjects. OOPSLA 98. • Aksit, M., Bergmans, L., Vural, S. An object-oriented langauge-database integration model: The composition-filters approach. ECOOP 92. LNCS 615, Springer. • Template Metaprogramming:http://home.t-online.de/home/Ulrich.eisenecker/gpref.htm • GenVoca: Batory, Don. Subjectivity and GenVoca Generators. In Sitaraman, M. (ed.). Proceedings of the Fourth Int. Conference on Software Reuse, April 23-26, 1996, Orlando Florida. IEEE Computer Society Press, pages 166-175 • IPD-Literatur am Ende der Folien

3. Problem und Ziel der Komposition • Problem • Nicht alle Systemeigenschaften als separate Komponenten erfassbar • Wartbarkeit, Erweiterbarkeit und Wiederverwendbarkeit leiden • Ziel • Klare Trennung aller Systemeigenschaften in Entwurf und Umsetzung • Verwebung in einzelnen Schritten(im Gegensatz zum monolithischen Weber à la AOP) • Lösung • Komposition (mit Metaoperatoren)

4. Komposition: Ausdrücke statt Weber Druckaspekt Persistenz Algorithmus Op Op Op Op Op Op Druckaspekt Persistenz- aspekt Druckaspekt

5. Systembau als Kompositionsterm C1 C1 C3 A A.p1 A A A A A.p1 A B.p1 B.p1 C1 C2 C2 B.p2 C.p2 B.p2 B A A.p1 A.p2 A.p2 C.p1 C.p1 A A A A C2 C2 C C C C C1 C1 C1 B B B B C3

6. Systembau als Kompositionsterm C1 D=C4 C1 A.p1 A A A B.p1 A A.p1 A A B.p1 C2 C3 C2 C3 A.p2 B.p2 A.p2 B.p2 C.p1 C.p2 C.p1 C.p2 D A A C2 C2 C C C1 C1 B B C3 C2

7. Voraussetzungen zur Komposition • Flexible Komposition von Code und Daten möglich. • Kompositionsoperatoren (Kompositoren) sind Programmtransformatoren (Codetransformator, Optimierer, Übersetzer, Metaprogramm, Metaoperator) Optimierer, Transformator op: Code  Code Metaprogramm, Metaoperator code: Code  Code Übersetzer op: SpracheA  SpracheB

8. 7.1 Einige Ansätze zur Komposition • Subjekt-orientiertes Programmieren SOP • OOP-Erweiterungen (composition filters) • Kalküle für Komponentensysteme (N-Kalkül) • Metaobjekt-Komposition • Template Metaprogramming

9. 7.1.1 Subjekt-orientiertes Programmieren • Verfechter: Ossher, Harrision (IBM) • Idee • Teile von Klassen als Subjekte beschreiben • Subjekte durch Mischregeln auf Klassen abbilden • Subjekte • Operationen (generische Methoden) • Klassen und Instanzvariable • Umsetzung der Operationen in konkreten Klassen(Realisierung mittels Generator) • Beschreibung mit eingebettetem C++ • Mischregeln • Beschreibung mit einfacher Operatorsprache

10. Beispiel • Ein einfaches Subjekt Subject: PAYROLL Operations: print() Classes : Employee() with InstanceVariables: _emplName; Mapping : Class Employee, Operation Print() implemented by &Employee::Print() // others... • Mischen nach Regeln • Zielklassen erhalten Operationen der beteiligten Subjekte

11. Mischregeln in SOP • Fest vorgegebene Kompositionsoperatoren • Korrespondenzregeln: • Equate (Zuweisung Methoden-Implementierung = Subjektteil) • Correspond (Delegation) • Kombinationsregeln • Replace (Überschreiben) • Join (Verbinden von Subjektteilen) • Korrespondenz- und Kombinationsregeln • Merge = Join; Equate • Override • Anwendungen aus C++ leicht erweiterbar (klar wegen Sichten und Erweiterungsoperatoren) • Mischmodell kaum erweiterbar!

12. 7.1.2 LambdaN-Kalkül (N) • Erster Kalkül zur Codekomposition • Erweiterung des Lambda-Kalküls • Benannte Argumente • Namensabhängige Reduktionsregeln • Zweck • Mehrfachdefinition von Funktionen • Einfache Vereinigung ihres Codes • Mischregeln • Umbenennung von Parametern • Vereinigung von Ausdrücken

13. Beispiel f = lambda a b . let x = a+b in record(x) . f = lambda x y z . let r = x+z in let s = y*x in record(r+s) . Umbenennung (rename) f = lambda a b . let t = a+b in record(t) . Vereinigung (union) f = lambda x y z a b . let r = x+z in let s = y*x in let t = a+b in record(r+s,t) . f(x=1,y=2,z=3) f(a=1,b=2) LambdaN vereinigte datenunabhängige Slices f(x=1,y=2,z=3,a=1,b=2)

14. 7.1.3 Metaobjekt-Komposition • Klasseneigenschaften als Metaobjekt darstellen (tracing, counting, verbose, persistent,..) • Kombination durch Aggregation auf Metaebene • Der eigentliche Code einer Klasse ergibt sich aus • den Methoden • dem Code der Metaobjekte(auf irgendeine Weise komponiert; de facto beschränkt auf Prozedurein-/ausgang) • Simulation mit LambdaN möglich

15. Beispiel Metaobjekt- Methoden Metaobjekt-Klassen Normale Klasse Class c { Procedure p() { fetch_from_db(self); print("enter p"); p_counter++; /* algorithm */ // counting: nothing print("exit p"); store_to_db(self); } } precode persistence postcode composing c precode verbosity postcode counting precode postcode p Algorithmus

16. 7.1.4 Kompositionsfilter (composition filters) • Älterer Ansatz, ähnelt Metaobjekt-Komposition(Schachtelung von Code um Objekte und Methoden) • Idee: Botschaften zwischen Objekten werden gefiltert • Beispiele für Filter • Botschaften verschlucken • Botschaften delegieren (Vererbung, Delegation) • Mit anderen Objekten synchronisieren (Synchronisationsprotokolle) • Objekt(e) modifizieren (Anpassung) • Dynamische Anpassung durch Filtertausch möglich • Sehr mächtiges Konzept, besonders zur Anpassung

17. 7.1.5 Template Metaprogramming/GenVoca • Templates in C++ • Parametrisierte Typausdrücke • Auswertung bei Übersetzung • Idee: Nutze Templates zur Komposition • Nachteil: Unlesbare Programme (Zweckentfremdung!) • Umsetzung auch denkbar mit • statisch ausgewertetem Lambda-Kalkül • offener Programmiersprache (z.B. OpenC++) • GenVoca (Batory) • Mehrfach-Parametrisierung mit geschachtelten Template-Parametern(Konfiguration in mehreren Dimensionen) • Hauptsächlich für innere Anpassung

18. Beispiel // Statisch ausgewerteter SWITCH als Typ template <int Tag,class aCase> struct SWITCH { typedef aCase::next nextCase; // Statische Berechnung in MS VC++ erzwingen enum { tag = aCase::tag, nextTag = nextCase::tag, found = (tag == Tag || tag == DEFAULT) }; // Statische Auswertung bei Übersetzung typedef IF<(nextTag == intimate::NilValue), intimate::NilCase, SWITCH<Tag,nextCase> > ::RET nextSwitch; typedef IF<(found != 0), aCase::statement, nextSwitch::RET> ::RET RET; };

19. Generische Klassen (templates) und Rahmenwerke (frameworks) Formale Parameterklasse Parameterklasseninstanz Template class Hook class

20. GenVoca: Komposition durch Schachtelung von generischen Klassen Template T< T1< T2<T3> ,T4<T5> > > T3 T2 T5 T4 T T1 Alle Ti sind unabhängig voneinander austauschbar, d.h. konfigurierbar! (statische Komposition)

21. Komponentensicht T3 T5 T2 T4 T1 T Komponenten werden intern adaptierbar, da innere Einheiten unabhängig von äusseren ausgetauscht werden können

22. 7.2. Invasive Softwarekomposition • Invasive Komposition adaptiert und erweitert Komponenten an Webepunkten durch Programmtransformation • Allgemeiner Mechanismus • Anwendungsgebiete • Anpassung • Sichtenorientierte Entwicklung • Aspektorientierte Entwicklung • Webepunkte sind Ansatzpunkte für Adaption und Erweiterung • Implizit (z.B. durch Sprachsyntax definiert) • Deklariert (explizit als Kompositionsschnittstelle ausgewiesen)

23. Implizite Webepunkte • Beispiel: Methodeneintritt/austritt für Umwicklung (wrapping), z.B. zum Umwickeln eines Test-Aspekts m (){ abc.. cde.. } Method.entry Method.entry Method.exit Method.exit

24. Deklarierte Webepunkte • Die Kompositionsschnittstelle einer Komponente besteht aus ihren explizit deklarierten Webepunkten • Deklaration von Webepunkten durch Spracherweiterungen oder z.B. • Standardisierte Namenspräfixe • Vererbungsbeziehungen • Standardisierte Kommentar-Marken Deklarationen

25. Webepunkte für Kommunikation (Tore) • Deklaration durch Aufruf abstrakter Kommunikationsmethoden m (){ // Aufruf e = p(d); } m (){ out(d); in(e); } Ausgabetor Eingabetor m (){ // Ereignis notifyObservers(d); e = listen_to(); }

26. Invasive Komposition mit Kompositoren Invasiv transformierter Code • Kompositoren sind Transformatoren, Optimierer, Übersetzer, Metaoperatoren, Metaprogramme Erkennen (ungebundener) Webepunkte Konsistentes Transformieren zu gebundenen Webepunkten Kompositor

27. Komposition beseitigt die Kompositionsschnittstellen Funktionale Schnittstelle Kompositionsschnittstelle mit Webepunkten Invasive Komposition

28. Einsatz klassischer Übersetzerbautechnik • Programmanalyse zur Prüfung von Vorbedingungen • Attributierte Grammatiken • Typprüfungen • Datenflußanalyse • Abstrakte Interpretation • Programmtransformation • Globale Musterersetzung (Ersetzungssysteme) • Lokale Musterersetzung • Elimination

29. 7.2.2. Geheimnisprinzip der invasiven Komposition • Kompositon nur auf der Kompositionsschnittstelle • Dann kapselt die Schnittstelle die Komponente • Austausch gegen eine Variante wird möglich • Entspricht dem Geheimnisprinzip in • Modulen • Rahmenwerken • Architektursprachen • AOP • Aber wesentlich flexibler

30. Konstruktionsprozeß mit invasiver Komposition Altsystem Auswahl von Webepunkten Deklaration von Webepunkten Komponiertes, verwebtes System System mit Komponenten und Webepunkten Invasive Komposition

31. 7.2.3 Invasive Komposition, Code-Vererbung und Delegation Buchhandlung Kunde CORBA-Kompositor DCOM-Kompositor Kunde Buchhandlung Kunde Buchhandlung CORBA-Verbindung DCOM-Verbindung

32. Kunde import Buchhandlung; public class Kunde { public bestelle(String server) { // allocate new server Buchhandlung bh= holeBuchhandlung(server); // call the services bh.sucheAus(); bh.kaufe(); } } Buchhandlung public class Buchhandlung { public Buchhandlung() { } public void sucheAus() { System.out.println( "suche aus.." ); } public void kaufe() { System.out.println( "kaufe" ); } } Beispiel Kunde/Buchhandlung

33. Kunde import Buchhandlung; public class Kunde { public bestelle(String server) { // allocate new server Buchhandlun bh = holeBuchhandlung(server); // call the services bh.sucheAus(); bh.kaufe(); } } CORBA Kunde import org.omg.CORBA.* import Buchhandlung; public class Kunde extends CORBA.client { public Kunde(String server) { // Initialisiere CORBA Broker ORB orb = ORB.init( args,new Properties()); // Ermittle den Buchhändler Buchhandlung bh = orb.string_to_object(server); // Bestellung bh.schaueNach(); bh.order(); } } Invasive Anpassung an CORBA Enthaltene Webepunkte

34. Vererbung und Delegation sind Kompositoren K Passe invasiv an Delegiere Vererbe K-privat K K K-Unterklasse

35. Erweiterungsoperatoren für Klassen (z.B. SOP) sind Kompositoren K Physikalische Sicht als Verschmelzung der logischen Sichten K + K + Jede Komponente behält ihre logische Sicht

36. Ziele der Modifikation • Vererbung einsetzen für • seiteneffektfreie konsistente Komposition • Delegation einsetzen für • dynamischen Austausch • Invasive Komposition einsetzen für • unvorgesehene Erweiterungen (Sichtenkonzept) • aspektorientierte Entwicklung (invasives Einmischen wie in AOP) • Anpassung ohne Delegation (invasive Anpassung) • transparenten Komponentenwechsel (erfordert deklarierte Webepunkte)

37. 7.3. Das Kompositionssystem COMPOST • COMPOST ist eine Java-Bibliothek mit Programmtransformationen • Komponenten bestehen aus Java-Klassen mit Kompositionsschnittstelle (deklarierte Webepunkte) • Kompositoren sind herkömmliche Java-Methoden • Meta-Programmierung (Reflektion und Transformation) dient für Erkennung und Manipulation von Webepunkten [Aßmann98] [Aßmann/Ludwig99] • statisch mit einem Metamodell der Programmiersprache • Komponenten, Kompositoren, Webepunkt existieren als Metaobjekte (Component, Composer, WeavePoint)

38. Der Software-Herstellungsprozeß in COMPOST Client.coc (Java+Webepunkte) Server.coc (Java+Webepunkte) Kompositionsprogramm in Java und COMPOST Komposition/ Konfiguration Client.java GlueCode.java Server.java Übersetzer Übersetzung

39. Anbindung an Entwicklungsumgebungen Benutzer Kompositionen COMPOST Werkzeug Interaktive Werkzeuge JBuilder, Together

40. Spezifikation von Weben durch Graphersetzungssysteme Generierung von Webern mit Hilfe des Generators für Graphersetzungssysteme OPTIMIX (EARS, XGRS) [Aßmann95b, 99]

41. COMPOST und aufbauende Arbeiten Aspekt-orientierte Programming Unterstützung des Entwurfsprozesses Sanierung (Reengineering) Synchronisations- sprachen Automatisierte Entwurfsmuster Adaptive Programming Entweben von adaptiven Programmen Interaktive Komposition Architektur- sprachen Normalisierer Entwebe- operatoren Kontrollfluß Webe- operatoren Adapter Konnektoren Hilfsschicht COMPOST Datenmodell (Metamodell)

42. Das COMPOST System • Stellt invasive Kompositoren als Java-Programme dar • Erlaubt stapelverarbeitende und interaktive Komposition • Macht Webeschritte durch Kompositoren explizit • Stellt Aspekt-Weber als Graphersetzungssysteme dar • COMPOST wird mit sich selbst komponiert

43. 7.4 Fortschritte mit invasiver Komposition • Invasive Komposition adaptiert und erweitert Komponenten an Webepunkten durch Programmtransformation • Sichtenbasierte Erweiterung von Komponenten • Aspektkomposition • Flexible Anpassung von Komponenten • Modularer Austausch mit Geheimnisprinzip

44. Sprachunabhängige Komposition

45. Fortschritte • Methodik ist sprachunabhängig • Übertragung der Techniken aus dem Übersetzerbau • Spezifikationstechniken (Graphersetzung, Termersetzung) • Analysetechniken • Generierungstechniken • Methodik zur Aufarbeitung von Altsystemen geeignet • Einsatz zur Produktion von Produktfamilien • Methodik liefert die Basis zur Entwicklung abstrakterer und ausdrucksstärkerer Kompositionssprachen • Kompositoren bilden die Maschinensprache der Komposition

46. Fortschritte gegenüber... • Objektorientierten Systemen • Kompositoren verallgemeinern Delegation und Vererbung • Invasive Anpassung entfernt überflüssige Schnittstellen • Erweiterungsmechanismen ermöglichen Sichtenkonzept • Aspekt-orientiertem Programmieren • Invasive Komposition benötigt keine Spezialsprachen • Invasive Komposition systematisiert den Webeprozeß • Graphersetzungssysteme beschreiben Webevorgänge

47. Veröffentlichungen • http://i44www.info.uni-karlsruhe.de/~assmann/compost.html • [Alt/Aßmann/vanSomeren94] Alt, M., Aßmann, U., van Someren, H. Cosy compiler phase embedding with the CoSy compiler system. CC94, LNCS 786 • [Aßmann95a] Aßmann, U. On edge eddition rewrite systems and their relevance to program analysis. Graph-grammar Conference 1994, LNCS 1073 • [Aßmann95b] Aßmann, U. Generierung von Programmoptimierungen mit Graphersetzungssystemen. Dissertation. Universität Karlsruhe, GMD-Berichte 262, Oldenbourg. • [Aßmann96] Aßmann, U. How To Uniformly Specify Program Analysis and Transformation. CC96, LNCS 1060 • [Goos/Aßmann98] Goos, G., Aßmann, U. Systematic Software Construction. Workshop Universal Design Theory, Karlsruhe, Shaker Verlag. • [Aßmann98] Aßmann, U.: Meta-programming composers in 2nd generation component systems. IFIP WG 2.4 Systems Implementation, Feb. 98, Berlin. • [Aßmann99] Aßmann, Ludwig: How to introduce connections into classes with static metaprogramming. Coordination 99, Amsterdam. LNCS. • [Aßmann99b] Aßmann, U. How to transform and optimize programs with OPTIMIX. Graph-grammar handbook, Vol. II, ed Rozenberg, Kreowski 1999 • [Aßmann99c] Aßmann, U. Graph rewrite systems for program optimization. Under revision by TOPLAS.

48. Literatur • Technische Berichte • Aßmann, U., Genssler, T., Bär, H.: Meta-programming grey-box connectors. • Aßmann, U., Heberle, A., Ludwig, A., Löwe, W., Neumann, R.: Design patterns and language constructs. • Aßmann, U.: Aspect-oriented programming with design patterns as meta-programming operators. Techn. Bericht 17/97 Fak. InformatikVerwandte Arbeiten am Institut • Zimmer, W.: Frameworks und Entwurfsmuster. Dissertation. Jan. 1997, Universität Karlsruhe. • Schulz, B., Genßler, T., Mohr, B., Zimmer, W.: On the Computer Aided Introduction of Design Patterns into Object-Oriented Systems, Proceedings of the 27th TOOLS, Sept. 1998, IEEE CS Press. • Ludwig, A. Behandlung von partieller Konformität bei polymorphen Methodenaufrufen. Diplomarbeit Universität Karlsruhe, 1997. • Frigo, J., Neumann, R., Zimmermann, W. Mechanical Generation of robust libraries. TOOLS 97.

49. 7.5. Komposition: Was haben wir gelernt? • Was zeichnet Kompositionssysteme als Komponentensysteme aus? • Wie erfüllen sie unsere Kriterien aus der Einleitung?

50. Komposition: Ziele erfüllt? • Erhöhung Wiederverwendung • Produktqualität • Qualitätsverbesserung • Effektivität durch Konzentration auf Optimierungen • Verlässlichkeit • Verlängerung Lebensdauer • Flexibilisierung • Verbesserungen am Softwareprozess • Produktivität • Schneller Prototypenbau • Simulation von Architekturen • Dokumentation • Klare Systemstrukturen • Ja, sehr stark • ja • ja, einfache Spezifikationen • ja • Ja • ja • ja • ja • ja • ja, weil Aspekte, die Effizienz beeinflussen, weggelassen werden können • nein • ja • ja