software aus komponenten - systeme, adaptionen und probleme dr. welf löwe und markus noga lehrstuhl...
TRANSCRIPT
Software aus Komponenten -Systeme, Adaptionen und Probleme
Dr. Welf Löwe und Markus Noga
Lehrstuhl Prof. GoosInstitut für Programmstrukturen
Universität Karlsruhe
Dr. Welf Löwe und Markus Noga 2
Gliederung: Teil I - Grundlagen
Einführung– Motivation– Definition, – Konzepte für Komponenten (klassische, kommerzielle, akademische)
Industrielle Komponentensysteme der 1. Generation– CORBA – (D)COM – Enterprise JavaBeans
Anpassungsprobleme – Daten und Funktion– Interaktion
• Kommunikation• Synchronisation• Protokolle
– Lebendigkeit
Dr. Welf Löwe und Markus Noga 3
Teil II – Weiterführende Konzepte
Lösung der Anpassungsprobleme (aus Teil I, 3.2) durch:– Klassische Komponentensysteme– XML Technologien– Architektursysteme und –sprachen (Darwin, Unicon, Rapide,
ACME)– Erweiterungen des objekt-orientierten Paradigmas– Aspekt-orientiertes Programmieren, Adaptives Programmieren– Kalküle für Komponentensysteme– Metaprogrammieren und Metaprogrammiersysteme– Invasive Komposition
Dr. Welf Löwe und Markus Noga 4
Material & Kontakte
Auf der Website zur Vorlesung: http://i44www.unfo.uni-karlsruhe.de/~lehre/Folien– Laufende Veranstaltung (SS 2001)– Elke Pulvermüller (WS 2000)– Uwe Assmann (SS 1999)
Weitere Informationen bei– noga|[email protected]– Tel. 608-8351 oder -4762
Dr. Welf Löwe und Markus Noga 5
Literatur
C. Szyperski. Component software. Beyond object-oriented computing. Addison-Wesley. Guter Überblick. Software - Tools and Techniques. Special Edition on Componentware, 1998. Springer. Guter Kurzüberblick, insbes. der Artikel von Michael Stal.R. Orfali, D. Harkey: Client/Server Programming with Java and Corba. Wiley & Sons. Leicht zu lesen.F. Griffel. Componentware. dpunkt-Verlag. Umfassendes Material, aber etwas anstrengender zu lesen.CORBA. Communications of the ACM, Oct. 1998. Neue Entwicklungen.Sametinger: Software Reengineering with Reusable Components. Springer 1998. Überblick, aber mehr auf abstraktem NiveauGamma et al: Entwurfsmuster. Addison-Wesley. Das unentbehrliche Handwerkszeug des Softwareklempners.W. Pree: Metapatterns. ACM Press. Strukturierung von Entwurfsmustern.W. Pree: Softwareentwicklung mit Frameworks. dpunkt-Verlag.
Dr. Welf Löwe und Markus Noga 6
Standards
Common Object Request Broker Architecture (CORBA). OMG spec., http://www.omg.org/technology/documents/formal/corbaiiop.htm, 2001.The Component Object Model Specification. Microsoft, http://www.microsoft.com/com/resources/comdocs.asp, 1999.Enterprise JavaBeans. Sun, http://java.sun.com/products/ejb/, 2001.Extensible Markup Language (XML) 1.0. W3C Recommendation, http://www.w3.org/TR/1998/REC-xml-19980210, 1998.Simple Object Access Protocol (SOAP) 1.1. W3C Note, http://www.w3.org/TR/SOAP/, 2000.Web Services Description Language (WSDL) 1.1, W3C Note, http://www.w3.org/TR/wsdl, 2001.Universal Description, Discovery and Integration (UDDI) http://www.uddi.org/specification.html, 2000.
Dr. Welf Löwe und Markus Noga 7
I.1.1 – Warum Entwicklung mit Komponenten?
Wiederverwendung von Teillösungen: Lösungsannäherung statt neuer ProblemlösungLeichte Konfigurierbarkeit des konstruierten Systems: Varianten, Versionen, ProduktfamilienOutsourcing von TeilproblemenBündelung von Kräften (bei nicht marktdivergierenden Systemeigenschaften)Kostenreduktion
Bewährt in anderen Ingenieursdisziplinen– Maschinenbau (z.B. DIN 2221), – Elektrotechnik, – Architektur
Dr. Welf Löwe und Markus Noga 8
Beispiel: Kostenreduktion
Größe von Klassenbibliotheken– JDK 1.1: circa 1,650 Klassen– JDK 1.2: circa 4,000 Klassen
Je mächtiger, desto höher die Einarbeitungszeit
Reuse rates 0% 25% 50%Time [m.m.] 81,5 45 32# Developers 8 6 5Costs per l.o.c. [DM] 70 37 28Lines per m.m. 165 263 370Savings [DM] - ~ 400.000 ~ 560.000Savings - ~ 45% ~ 60%
From: C. Jones, The Impact of Reusable Modules and Functions, inProgramming Productivity, Mc Graw Hill, 1986
Dr. Welf Löwe und Markus Noga 9
Weitere Ziele
Verbesserung der Produktqualität– Höhere Effektivität durch Konzentration auf Optimierungen– Höhere Verlässlichkeit (Haftungsfrage unklar)– Verlängerung der Lebensdauer – Flexibilisierung
Verbesserungen am Softwareprozess– Höhere Produktivität – Schneller Prototypenbau– Simulation von Architekturen
Dokumentation– Klare Systemstrukturen
Dr. Welf Löwe und Markus Noga 10
Ursprünge
NATO Conference on Software (Garmisch 68) prägte die Begriffe:– Software crisis– Software engineering
McIlroy:– Jede reife Industrie basiert auf Komponenten– Komponenten erlauben Massenproduktion– Systeme werden beherrschbar durch Zusammenbau aus
Komponenten – Später erfand McIlroy bei Bell Labs UNIX pipes,
bis heute das meisteingesetzte Komponentensystem!
Wo stehen wir heute?
Dr. Welf Löwe und Markus Noga 11
Reale Komponentensysteme
LEGOHohlblöckeICsHardware-Busse
Was unterscheidet sie von Methoden der Software-Konstruktion?
Dr. Welf Löwe und Markus Noga 12
Komponenten und Komposition
Entwurf von Komponenten nach Geheimnisprinzip (information hiding) – Explizite Spezifikation von Schnittstellen– Implementierung bleibt verborgen
Komposition– Zusammensetzen von Komponenten nach lokalen
Entwurfsprinzipien, die globale funktionale und nichtfunktionale Eigenschaften zusichern
– Adaption von Komponenten, wenn nötig• Interne Adaption von Komponenten an ihren
Wiederverwendungskontext• Externe Adaption: Anpassung der Schnittstellen für die
Zusammenarbeit
Dr. Welf Löwe und Markus Noga 13
Reale Komponentensysteme
System Schnittstellen Komposition AdaptionLEGO Noppen Stecken -
Hohlblöcke Form, Profil Mörtel Behauen
ICs und Busse
Pins, Signal- Spezifikation
Stecken, Löten
Wandler, Puffer etc.
Dr. Welf Löwe und Markus Noga 14
I.1.2 – Definition von Komponenten
A software componentis a unit of composition with contractually specified interfaces and explicit context dependencies only. It can be deployed independently and is subject to composition by third parties.
Szyperski (ECOOP Workshop WCOP 1997)
A reusable software component is a logically cohesive, loosely coupled module that denotes a single abstraction.
Booch
A software component is a static abstraction with plugs.
Nierstrasz/Dami
Dr. Welf Löwe und Markus Noga 15
Weitere Definitionen
Software components are defined as prefabricated, pretested, self-contained, reusable software modules - bundles of data and procedures - that perform specific functions.
MetaGroup (OpenDoc)
Reusable software components are self-contained, clearly identifyable pieces that describe and/or perform specific functions, have clear interfaces, appropriate documentation, and a defined reuse status.
Sametinger
Dr. Welf Löwe und Markus Noga 16
Komponenten - Unsere Definition
Programmeinheiten mit standardisierter Basiskommunikation– Abstrakt (nur Schnittstelle), generisch oder konkret (mit Implementierung)– Klassen und Module sind Komponenten, Objekte nicht!
Entworfen mit standardisierten Verträgen zur Komposition:– Export-Schnittstelle sichert semantische Eigenschaften zu– Import-Schnittstelle definiert Voraussetzungen zur ihrer Garantie
• Explizit oder• Implizit (als Parameter von Konstruktoren oder anderen Methoden)
– Keine implizites WissenKomponenten sind wiederverwendbarKomponenten können aus Komponenten zusammengesetzt sein
Dr. Welf Löwe und Markus Noga 17
Komposition
Instanziieren generischer KomponentenZusammensetzen von Komponenten laut Verträgen:– Über Funktionen und Daten– Über Kommunikation, Synchronisation und Protokolle– Problem der globalen Lebendigkeit?– Wie erreicht man nichtfunktionale Eigenschaften?
Mangelnde Passung erfordert Adaption der Komponenten:– Externe Adaption durch Wrappercode– Interne Adaption:
• Offenes Einsetzen• Invasiver Austausch nicht-funktionaler Aspekte (z.B.
Basiskommunikation tauschen, Synchronisation einfügen etc.)
Dr. Welf Löwe und Markus Noga 18
Eigenschaften von Komponenten
Können aus Spezifikation generiert werden (generische Komponenten)Unterscheidung funktionaler und nicht-funktionaler Aspekte– Funktion und Daten, – Kommunikation und Synchronisation, – Verteilung, – Persistenz, etc.
Können dynamisch geladen und ersetzt werden – Programme können Komponenten mit Reflektion betrachten und
deren Dienste feststellen– Ignorieren unbekannter funktionaler Aspekte
Dr. Welf Löwe und Markus Noga 19
Einige Kommunikationsarten
Normaler ProzeduraufrufCallbacks und EventsFernaufruf (remote procedure call, remote method invokation)– Einpacken der Objekte in Byte-Strom, Verschicken, Auspacken– Kann in heterogenen Systemen eingesetzt werden– Z.B. Java RMI, CORBA etc.
Gemeinsamer SpeicherUni- oder bidirektionale FIFOs (z.B. pipes, sockets)Blackboards, strukturierte Blackboards (Linda Tupelspace)Transaktionsdienste (Datenbank)Migration von Code (z.B. Java Applets)
Dr. Welf Löwe und Markus Noga 20
Beispiel: Callbacks und Events
Aufrufer übergibt Prozedurvariable oder Verweis auf Objekte (anonymous classes in Java, Callback-Service in Corba)Rückruf durch Rahmenwerk, Bibliothek oder Server
Ereignisse (events) zur asynchronen Kommunikation– Technisch über Rückruf gelöst– Reihenfolge meist nicht zugesichert
dynamisch variierbarer EmpfängerEreignisquellen sind meist DiensteZ.B. in Java Beans, Corba Event Service
Dr. Welf Löwe und Markus Noga 21
I.1.3 Klassische Konzepte
Betrachtung als Komponentensysteme und Diskussion von Problemen bei:– UNIX – XML - Lösungen– Module– Klassen und Vererbung– Rahmenwerke (Frameworks)
Dr. Welf Löwe und Markus Noga 22
UNIX
Basiskommunikation: Byte-Ströme von Quelle zu Senke– Einfach und flexibel– In einem Rechner: Pipes– In Rechnernetzen: Sockets
Komponenten sind eigenständige Programme– Schnittstellen: Standardeingabe, Standardausgabe– Generierung: durch make etc.
Komposition mit Pipes in Shells und SkriptsprachenAdaption:– Interne nicht unterstützt– Externe durch eigenständige Komponenten, meist programmierbare
Filter (awk, cut, grep, sed, etc.)
Dr. Welf Löwe und Markus Noga 23
Probleme
Komponenten haben jeweils nur einen Ein- und AusgangEinschränkung auf Ketten von Filtern (Pipelines)– Allgemeinerer Einsatz von Pipes und Sockets möglich. – Programme in C/C++ können so außerhalb des Modells agieren. – Komposition mit Werkzeugen wie Shells, Skripte dort unmöglich.
Einschränkung auf asynchrone Protokolle ohne RückkanalAdaption schwierig– Formale Modellierung der Daten fehlt– Standardwerkzeuge beherrschen maximal reguläre Muster
Allgemeine Probleme mit Skripten:– Schlecht skalierbar– Schlecht wartbar
Dr. Welf Löwe und Markus Noga 24
XML Lösungen
XML Baum- bzw. Termsprache– Leicht zu Parsen– Baum und und Graphstrukturen Explizit über Syntax bzw. Namen
Komponenten sind weiterhin eigenständige ProgrammeSOAP (Simple Object Access Protokol) als Kommunikationsmethode– Meist http basierte Kommunikation
XML als Austauschformat, XSLT zur Datenanpassung – Pfadsprache zur Musterbeschreibung und regelbasierte Musterersetzung– andere Graphersetzungssysteme denkbar, nicht Standard
UNIX als Komponentensystem kann subsumiert werden
Dr. Welf Löwe und Markus Noga 25
Module (à la Parnas)
Every module hides an important design decision behind a well-defined interface which does not change when the decision changes.
David ParnasEigenschaften
– Feste Schnittstellen– Kapselung, Geheimnisprinzip (information hiding)– Statische Bindung: Keine dynamische Erzeugung
Durchdringt viele moderne Sprachen (Modula, Ada, Java, C/C++ usw.)Betrachtung als Komponentensystem:
– Basiskommunikation: Prozeduraufruf– Schnittstellen: Prozeduren mit Parametern, globale Variable– Generierung: sprachspezifisch für generische Module– Adaption explizit und manuell
Dr. Welf Löwe und Markus Noga 26
Probleme
Sprachabhängigkeit der– Basiskommunikation– Spezifikation von Daten und Prozeduren– Synchronisation
Protokolle nicht spezifiziertFehlende Werkzeuge für– Komposition– Adaption– Verteilung
Heterogene, verteilte Lösungen erfordern viel Handarbeit!
Dr. Welf Löwe und Markus Noga 27
Objektorientierte Klassensysteme
Klassen sind Module– Haben mehrere zur Laufzeit erzeugte Instanzen (Objekte) – Objekte haben Zustände (evtl. persistent)
Vererbung und Untertypbeziehungen– Polymorphie – Späte Bindung von Aufrufen
Betrachtung als Komponentensystem:– Basiskommunikation: Polymorphe Methodenaufrufe, Variable– Schnittstellen: Polymorphe Methoden, Objekt- und Klassenvariable– Generierung: sprachspezifisch, oft mit generischen Klassen– Adaption: durch Vererbung oder Delegation
Dr. Welf Löwe und Markus Noga 28
Generische oder Abstrakte Klassen
Generische/abstrakte Klasse
Instanz
System Implementierung
Dr. Welf Löwe und Markus Noga 29
Probleme
Sprachabhängigkeit der– Basiskommunikation– Spezifikation von Daten und Prozeduren– Synchronisation
Protokolle nicht spezifiziertAdaption durch Spracheigenschaften eingeschränkt(Kontravarianz oder Invarianz bei Vererbung) Fehlende Werkzeuge zur Verteilung
Heterogene, verteilte Lösungen erfordern viel Handarbeit!
Dr. Welf Löwe und Markus Noga 30
Rahmenwerke (Frameworks)
Rahmenwerke sind KlassensystemeSie bestimmen Kontrollfluss und Kommunikation einer Anwendung Parametrisierung durch KlassenRahmenwerke als Komponentensysteme:– Basiskommunikation: Methodenaufrufe– Schnittstellen: Hot spots - Mengen von polymorphen Methoden– Generierung: Instantiierung der Parameterklassen oder
Implementierung der abstrakten Klassen gemäß den Einschränkungen des Rahmens
– Adaption: durch Vererbung oder Delegation
Dr. Welf Löwe und Markus Noga 31
Rahmenwerke
Parameterklassen Instanzen
System Implementierung
Implementierung
Dr. Welf Löwe und Markus Noga 32
Probleme
Oft sprachabhängigKeine Wiederverwendung in fremdem Kontext(Grund: sehr gute Normierung/Standardisierung)Rahmen legt Möglichkeiten im Voraus fest:– Adaption– Verteilung– Heterogene Lösungen
Dr. Welf Löwe und Markus Noga 33
Copyright © 1997 by Rational Software Corporation
Course CourseOffering
Student Professor
Modellierung mit UML Komponentendiagramm
Course.dll
People.dll
Course
User
Register.exeBilling.exe
BillingSystem
Dr. Welf Löwe und Markus Noga 34
Probleme
Semantik sehr flexibelNichts ist definiert, also keine Anpassung nötigProblem der ImplementierungProbleme je nach Implementierungssprache oder -system
Dr. Welf Löwe und Markus Noga 35
I.1.4 Kommerzielle Komponentensysteme
Komponentensystem (Plattform, Rahmenwerk) definiert Standards für Komponenten: Schnittstellen, Protokolle, Kommunikations- und Implementierungsbasisstellt Grundvoraussetzungen für Einsatz der Komponenten sicherreguliert Interaktionen zwischen den KomponentenBeispiele:– Corba– (D)COM– (Enterprise) JavaBeans– IBM SOM– OpenDoc
Dr. Welf Löwe und Markus Noga 36
(D)COM, CORBA und JavaBeans
Basiskommunikation: – Normale Prozeduraufrufe an Kommunikationssystem– Weiterleitung über normale Aufrufe und Fernaufrufe
Standardisierte Schnittstellen – set/get Properties, – IUnknown (COM), QueryInterface (Corba)– Namensdienste etc.
Generierung: aus Klassen und DefinitionssprachenNur externe Adaption:– Für verteilte Systeme (marshaling) – Für gemischtsprachliche Systeme (IDL)
Dr. Welf Löwe und Markus Noga 37
Komponenten in kommerziellen Systemen
Objekte, die in einen Softwarebus gesteckt werden könnenMit dem Bus und einer Menge von standardisierten Schnittstellen bilden sie ein Komponentensystem (Plattform)
Softwarebus
Dr. Welf Löwe und Markus Noga 38
CORBA
Offener Standard, siehe http://www.corba.orgUnabhängig von Sprache und VerteilungInterface definition language IDLQuellcode oder binär
ClientJava
ServerC++
ClientC
IDL Stub IDL skeletonIDL Stub
Object Request Broker (ORB), Trader, Services
Object adapter
Dr. Welf Löwe und Markus Noga 39
(D)COM
Microsoft proprietär, siehe http://www.activex.org Ähnelt CORBARein binärer Standard
ClientVBasic
ServerC++
ClientC++
COM stub COM skeletonCOM stub
Monikers, Registry
Dr. Welf Löwe und Markus Noga 40
JavaBeans
Offener Standard, siehe http://www.javasoft.comSprachabhängig: nur JavaUnabhängig von Verteilung (durch RMI)Quellcode oder Bytecode
Java Bean
Java Bean
Java Bean
Event InfoBus, RMI
Bean Container
Dr. Welf Löwe und Markus Noga 41
Probleme
Unterschiedliche Basiskommunikation der Systeme, – z.B. können Corba Komponenten nicht direkt COM Komponenten
verwenden– Wrapping mit zusätzlicher Indirektion oder – Invasive Änderung der Komponente nötig (unmöglich bei
Binärlösung)
Keine formale Definition von Protokollen– Komponenten mit gleichen Schnittstellen i.a. nicht
wiederverwendbar– Lösung Standardisierung:
• Schnittstellenidentifikation ist eindeutig (COM)• Reflektion
Dr. Welf Löwe und Markus Noga 42
I.1.5 Akademische Konzepte
ArchitektursystemeAspektorientiertes ProgrammierenMetaprogrammieren und Invasive Programmadaptation als Technik zur Komposition
Dr. Welf Löwe und Markus Noga 43
Architektursysteme
Z.B. Unicon, DarwinBasiskommunikation:– Prozeduraufrufe an sog. Tore (communication ports)– Art der Kommunikation zwischen Komponenten ist transparent
Schnittstellen: – Tore, an die Konnektoren angreifen– Explizite Anwendung von Konnektoren pro Kommunikation
(in objektorientierten Systemen wird Kommunikationen gemeinsam durch Vererbung verändert)
– Schnittstellen bleiben zur Laufzeit erhaltenInterne Adaption: durch VererbungExterne Adaption: Klebe- oder Wrappercode durch Konnektoren
Dr. Welf Löwe und Markus Noga 44
Architektursysteme
Komponente
KomponentePort 2
Komponente
Port 1
PortPort
Konnektoren spalten Kommunikation aus Komponenten ab
Dr. Welf Löwe und Markus Noga 45
Probleme
Keine StandardisierungKünstliche Unterscheidung von Konnektoren und KomponentenKeine Wiederverwendung von KonnektorenSchnittstellen von Komponenten und Konnektoren im laufenden Code
Dr. Welf Löwe und Markus Noga 46
Aspekttrennung & Komposition
Strom Gas
WasserDaten
Trenne diePläne für
verschiedene Aspekte
und webe sie zu einem System
zusammen
Austausch der Aspekte unabhängig voneinander
Dr. Welf Löwe und Markus Noga 47
Aspect-orientierted programming (AOP)
Siehe Kiczales et al: Aspect-oriented Programming. LNCS ECOOP 1998Verallgemeinerung von Architektursystemen:
– Architektursysteme sind spezielle Aspektsysteme: Ihre beiden Aspekte sind anwendungsspezifische Funktionalität und Kommunikation
– Weitere Aspekte: Synchronisation, Verteilung, Persistenz etc.Transparenz durch aspektbeschreibende Sprachen
Basiskommunikation: ein AspektGenerierung: Weben aus AspektspezifikationenSchnittstellen: Join points, an denen Aspekte verwoben werdenAdaption:
– Interne Adaption: Aspekte bilden Teile von Komponenten, d.h. interne Adaption durch Austausch von Aspekten
– externe Adaption: Weben von Klebecode um Komponenten herum
Dr. Welf Löwe und Markus Noga 48
Aspekte eines Programms(Algorithmus und Animation)
/** The black code is the algorithmic aspect *//* * The red code is the animation aspect. */import java.io.*;public class Hanoi extends java.util.Observable implements java.util.Observer { public Hanoi() { addObserver( new PrintObserver() );} protected void compute( int n, String s, String t, String h ) { if(n > 1){ compute( n - 1, s, h, t ); } setChanged(); notifyObservers( new displayPack( s, t ) ); if(n > 1){ compute( n - 1, h, t, s ); } }
/** The black code is the algorithmic aspect */
import java.io.*;public class Hanoi {
public Hanoi() {…} protected void compute( int n, String s, String t, String h ) { if(n > 1){ compute( n - 1, s, h, t ); }
if(n > 1){ compute( n - 1, h, t, s ); } }
Dr. Welf Löwe und Markus Noga 49
Aspekte als Sichten
System
Aspekt 1 Aspekt 2 Aspekt 3
Abstraktion=
Aspekt
Konkretisierung=
Weben
Dr. Welf Löwe und Markus Noga 50
Probleme
Orthogonale Aspekte– Keine Interaktionen zwischen den Aspekten– Weben einfach
Nicht-orthogonale Aspekte– Z.B. Funktionalität und Synchronisation, Funktionalität und
Verteilung, Protokolle und Synchronisation etc.– Getrennte Spezifikation unmöglich– Weben unklar
Aspekt als Sicht– Abstraktion von Systemeigenschaften– Umkehrungsfunktion nicht immer
• Eindeutig• Widerspruchsfrei mit anderen Aspekten
Dr. Welf Löwe und Markus Noga 51
Invasive Komposition
Webepunkte sind statisch eindeutig berechenbare ProgrammstellenKomponenten kapseln Entwurfsentscheidungen hinter Kompositionsschnittstellen mit wohldefinierten WebepunktenProgrammtransformatoren (auch Kompositionsoperatoren) erkennen und transformieren Webepunkte einer Kompositionsschnittstelle. Klassifikation:– Kein Komponentensystem!– Technik zur Komposition von allen Systemen funktioniert.
Dr. Welf Löwe und Markus Noga 52
Invasive Komposition
Standard-Webepunkte, z.B. für wrapping: Method.begin und Method.end
Method m (){
abc.. cde..
return;}
Method.begin
Method.end
Method m
Method.begin
Method.end
Dr. Welf Löwe und Markus Noga 53
Transformation eines Webepunktes
Wrapping eines Test-Aspekts
Method m (){ print(„enter m“) abc.. cde.. print(„exit m“) return;}
Method.begin
Method.end
Method m (){
abc.. cde..
return;}
Method.begin
Method.end
Dr. Welf Löwe und Markus Noga 54
Mehrfache Bindung eines Webepunktes
DruckaspektMethod m
Method.end
Transaktions-
aspekt
Method.begin
Dr. Welf Löwe und Markus Noga 55
Deklarierte Webepunkte
Z.B. Kommunikationstore: Ansprache von Torobjekten (port objects)
Method m (){
portOut.out(d); portIn.in(e);
}
OUT port
IN port Method m
portOut.out
portIn.in
Dr. Welf Löwe und Markus Noga 56
Transformationen für Tore
m (){ … portOut.out(d); portIn.in(e); …}
OUT portIN port
m (){
/*** ports */ e = x(d); }m (){ /*** ports */ setChanged(d); notifyObservers(d); listen_to(e);}
Dr. Welf Löwe und Markus Noga 57
Einfache Bindung von Toren
Method m
call
portIn.in
Method x
portOut.out
call
Dr. Welf Löwe und Markus Noga 58
Transformation mit Kompositoren
Ein Kompositor ist ein Metaprogramm:– Programmtransformator – Bindet ungebundene Webepunkte an Code
Aufgaben– Erkennen von Webepunkten– Transformation durch Manipulation von Webepunkten
(Binden der Webepunkte, Weben, weaving)– Codegenerierung
Dr. Welf Löwe und Markus Noga 59
Vergleich der Komponentensysteme
System Kommunikation Schnittstellen Generierung Adaption
Module Aufrufe Prozeduren Je nach Sprache
Je nach Sprache
Frameworks Polymorphe Aufrufe
Methoden Generische Klassen
Vererbung, Delegation
CORBA & Co. RMI Methoden (nach IDL)
- Wrapper
Architektur-systeme
Aufrufe an Tore Tore - Konnektoren
AOP Aspekt (beliebig)
Join points Weben Weben
Dr. Welf Löwe und Markus Noga 60
Historische Ansätze
Netscape ONE:– HTML, Java, JavaScript– Internet foundation classes (Java Klassen für Netzwerk)– Internet inter-ORB protocol (IIOP, Konnektoren basierend auf
CORBA)– Transport und applikationsspezifischer Protokolle
IBM Visual Age und ComponentBroker– Entwicklungsumgebung auf VisualAge-Basis – CBToolkit (Komponenten auf CORBA IDL basierend)– CBConnector (Verknüpfung und Management)
Dr. Welf Löwe und Markus Noga 61
Weitere historische Ansätze
IBM System Object Model (SOM)– Sprachunabhängiges Binärformat mit Versionen– Binäre Aufwärtskompatibilität (“release order”, Erhalt alter Offsets in Komponenten)– Unterstützung von Metadaten (Reflexion, Introspektion, Intercession):
wie in Smalltalk können Klassen über Klassen nachdenken und Code transformieren– Mehrfachvererbung von Code
Apple OpenDoc: Aktive strukturierte Dokumente (setzt auf IBM SOM auf)– “compound document“, “document parts”– Teile: ”native data“ / andere Teile– Open Scripting Architecture basierend auf AppleScript– Structured files mit Bento (ähnlich zu Microsofts COM/OLE)
• Dokument-Versionen von Dokumentbäumen mit Deltatechnik• Flexibles Speichermodell für Datenströme und Einzeldateien• Annotationen für Modifikationen an Dateien
– Mittlerweile in Corba integriert
Dr. Welf Löwe und Markus Noga 62
Probleme der bisherigen Systeme
Fehlen von Standards für Anwendungsbereiche:– Verbindungsstandards nicht genug – Wie einen Standard erreichen? Marktmacht Microsoft, Corba Facilities, ...
Bessere Verträge für höhere Sicherheitsansprüche an Komponenten– erweiterte Verträge: Protokolle (Corba IIOP), – Spezifikation von nicht-funktionalen Eigenschaften Zeit- und Speicherbedarf
Dienstvermittlung: – Semantikerkennung unmöglich – Standardisierung, aber Versionen zerstören Konsistenz
Wasserkopfprobleme (besonders bei Corba deutlich)Technische Probleme
– Speicherbereinigung (garbage collection)– Problem der Syntaktisch Fragilen Basisklassen: bei Versionsänderungen – Persistenzprobleme: müssen bereits ausgelieferte Komponenten nachübersetzt
werden– Austauschformate: Standard oder XML Lösungen– Objekt-Mobilität, -Migration: Senden kleiner Objekte statt Referenzen
Dr. Welf Löwe und Markus Noga 63
Probleme des Systementwurfs
Bisherige Entwurfskonzepte nicht auf Komponenten-Software übertragbar
– Top-down Entwurf bei vorgegebenen Komponenten?– Verfeinerung auf nicht vollständig spezifizierten Komponenten (Aspekte
fehlen, generische Komponenten, Komponenten vor invasiver Kopplung)– unabhängige Erweiterungen, viele Quellen– Globale Lebendigkeit
Managementprobleme– Qualitätssicherung bei anzupassenden Komponenten– Softwareprozeß
Rechtliche Probleme– Urheberrecht an Komponenten– Haftung bei Fehlern