Transcript Software aus Komponenten SS 2001 Foliensatz 1

Software aus Komponenten Systeme, Adaptionen und Probleme
Dr. Welf Löwe und Markus Noga
Lehrstuhl Prof. Goos
Institut für Programmstrukturen
Universität Karlsruhe
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
2
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
3
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
4
Literatur
C. Szyperski. Component software. Beyond object-oriented computing. AddisonWesley. 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 Niveau
Gamma 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
5
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
6
I.1.1 – Warum Entwicklung mit
Komponenten?
Wiederverwendung von Teillösungen:
Lösungsannäherung statt neuer Problemlösung
Leichte Konfigurierbarkeit des konstruierten Systems:
Varianten, Versionen, Produktfamilien
Outsourcing von Teilproblemen
Bü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
7
Beispiel: Kostenreduktion
Reuse rates
Time [m.m.]
# Developers
Costs per l.o.c. [DM]
Lines per m.m.
Savings [DM]
Savings
0%
81,5
8
70
165
-
25%
45
6
37
263
~ 400.000
~ 45%
50%
32
5
28
370
~ 560.000
~ 60%
From: C. Jones, The Impact of Reusable Modules and Functions, in
Programming Productivity, Mc Graw Hill, 1986
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
Dr. Welf Löwe und Markus Noga
8
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
9
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
10
Reale Komponentensysteme
LEGO
Hohlblöcke
ICs
Hardware-Busse
Was unterscheidet sie von
Methoden der SoftwareKonstruktion?
Dr. Welf Löwe und Markus Noga
11
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
12
Reale Komponentensysteme
System
Schnittstellen Komposition
Adaption
LEGO
Noppen
Stecken
-
Hohlblöcke
Form, Profil
Mörtel
Behauen
ICs und
Busse
Pins, SignalSpezifikation
Stecken,
Löten
Wandler,
Puffer
etc.
Dr. Welf Löwe und Markus Noga
13
I.1.2 – Definition von Komponenten
A software component
is 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
14
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
15
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 Wissen
Komponenten sind wiederverwendbar
Komponenten können aus Komponenten zusammengesetzt sein
Dr. Welf Löwe und Markus Noga
16
Komposition
Instanziieren generischer Komponenten
Zusammensetzen 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
17
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
18
Einige Kommunikationsarten
Normaler Prozeduraufruf
Callbacks und Events
Fernaufruf (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 Speicher
Uni- 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
19
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änger
Ereignisquellen sind meist Dienste
Z.B. in Java Beans, Corba Event Service
Dr. Welf Löwe und Markus Noga
20
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
21
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 Skriptsprachen
Adaption:
– Interne nicht unterstützt
– Externe durch eigenständige Komponenten, meist programmierbare
Filter (awk, cut, grep, sed, etc.)
Dr. Welf Löwe und Markus Noga
22
Probleme
Komponenten haben jeweils nur einen Ein- und Ausgang
Einschrä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ückkanal
Adaption 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
23
XML Lösungen
XML Baum- bzw. Termsprache
– Leicht zu Parsen
– Baum und und Graphstrukturen Explizit über Syntax bzw. Namen
Komponenten sind weiterhin eigenständige Programme
SOAP (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
24
Module (à la Parnas)
Every module hides an important design decision behind a well-defined
interface which does not change when the decision changes.
David Parnas
Eigenschaften
– 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
25
Probleme
Sprachabhängigkeit der
– Basiskommunikation
– Spezifikation von Daten und Prozeduren
– Synchronisation
Protokolle nicht spezifiziert
Fehlende Werkzeuge für
– Komposition
– Adaption
– Verteilung
Heterogene, verteilte Lösungen erfordern viel Handarbeit!
Dr. Welf Löwe und Markus Noga
26
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
27
Generische oder Abstrakte Klassen
Generische/abstrakte Klasse
System
Instanz
Implementierung
Dr. Welf Löwe und Markus Noga
28
Probleme
Sprachabhängigkeit der
– Basiskommunikation
– Spezifikation von Daten und Prozeduren
– Synchronisation
Protokolle nicht spezifiziert
Adaption 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
29
Rahmenwerke (Frameworks)
Rahmenwerke sind Klassensysteme
Sie bestimmen Kontrollfluss und Kommunikation einer
Anwendung
Parametrisierung durch Klassen
Rahmenwerke 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
30
Rahmenwerke
Parameterklassen
System
Instanzen
Implementierung
Implementierung
Dr. Welf Löwe und Markus Noga
31
Probleme
Oft sprachabhängig
Keine 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
32
Modellierung mit UML
Komponentendiagramm
Register.exe
Billing.exe
Billing
System
People.dll
User
Course.dll
Course
Student
Course
Professor
Course
Offering
Copyright © 1997 by Rational Software
Corporation
Dr. Welf Löwe und Markus Noga
33
Probleme
Semantik sehr flexibel
Nichts ist definiert, also keine Anpassung nötig
Problem der Implementierung
Probleme je nach Implementierungssprache oder -system
Dr. Welf Löwe und Markus Noga
34
I.1.4 Kommerzielle Komponentensysteme
Komponentensystem (Plattform, Rahmenwerk) definiert
Standards für Komponenten: Schnittstellen, Protokolle,
Kommunikations- und Implementierungsbasis
stellt Grundvoraussetzungen für Einsatz der Komponenten
sicher
reguliert Interaktionen zwischen den Komponenten
Beispiele:
–
–
–
–
–
Corba
(D)COM
(Enterprise) JavaBeans
IBM SOM
OpenDoc
Dr. Welf Löwe und Markus Noga
35
(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 Definitionssprachen
Nur externe Adaption:
– Für verteilte Systeme (marshaling)
– Für gemischtsprachliche Systeme (IDL)
Dr. Welf Löwe und Markus Noga
36
Komponenten in kommerziellen Systemen
Objekte, die in einen Softwarebus gesteckt werden können
Mit dem Bus und einer Menge von standardisierten Schnittstellen bilden
sie ein Komponentensystem (Plattform)
Softwarebus
Dr. Welf Löwe und Markus Noga
37
CORBA
Offener Standard, siehe http://www.corba.org
Unabhängig von Sprache und Verteilung
Interface definition language IDL
Quellcode oder binär
Client
Java
Client
C
Server
C++
IDL Stub
IDL Stub
IDL skeleton
Object adapter
Object Request Broker (ORB), Trader, Services
Dr. Welf Löwe und Markus Noga
38
(D)COM
Microsoft proprietär, siehe http://www.activex.org
Ähnelt CORBA
Rein binärer Standard
Client
VBasic
Client
C++
Server
C++
COM stub
COM stub
COM skeleton
Monikers, Registry
Dr. Welf Löwe und Markus Noga
39
JavaBeans
Offener Standard, siehe http://www.javasoft.com
Sprachabhängig: nur Java
Unabhängig von Verteilung (durch RMI)
Quellcode oder Bytecode
Java
Bean
Java
Bean
Java
Bean
Bean Container
Event InfoBus, RMI
Dr. Welf Löwe und Markus Noga
40
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
41
I.1.5 Akademische Konzepte
Architektursysteme
Aspektorientiertes Programmieren
Metaprogrammieren und Invasive Programmadaptation als
Technik zur Komposition
Dr. Welf Löwe und Markus Noga
42
Architektursysteme
Z.B. Unicon, Darwin
Basiskommunikation:
– 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 erhalten
Interne Adaption: durch Vererbung
Externe Adaption: Klebe- oder Wrappercode durch
Konnektoren
Dr. Welf Löwe und Markus Noga
43
Architektursysteme
Port 1
Komponente
Port
Komponente
Port
Port 2
Komponente
Konnektoren spalten Kommunikation aus Komponenten ab
Dr. Welf Löwe und Markus Noga
44
Probleme
Keine Standardisierung
Künstliche Unterscheidung von Konnektoren und
Komponenten
Keine Wiederverwendung von Konnektoren
Schnittstellen von Komponenten und Konnektoren im
laufenden Code
Dr. Welf Löwe und Markus Noga
45
Aspekttrennung & Komposition
Daten
Strom
Wasser
Gas
Trenne die
Plä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
46
Aspect-orientierted programming (AOP)
Siehe Kiczales et al: Aspect-oriented Programming. LNCS ECOOP
1998
Verallgemeinerung 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 Aspekt
Generierung: Weben aus Aspektspezifikationen
Schnittstellen: Join points, an denen Aspekte verwoben werden
Adaption:
– 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
47
Aspekte eines Programms
(Algorithmus und Animation)
/** 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 );
}
}
/** 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 );
}
}
Dr. Welf Löwe und Markus Noga
48
Aspekte als Sichten
Aspekt 1
Aspekt 2
Aspekt 3
Abstraktion
=
Aspekt
Konkretisierung
=
Weben
System
Dr. Welf Löwe und Markus Noga
49
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
50
Invasive Komposition
Webepunkte sind statisch eindeutig berechenbare
Programmstellen
Komponenten kapseln Entwurfsentscheidungen hinter
Kompositionsschnittstellen mit wohldefinierten
Webepunkten
Programmtransformatoren (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
51
Invasive Komposition
Standard-Webepunkte, z.B. für wrapping: Method.begin
und Method.end
Method m (){
Method.begin
Method.begin
abc..
cde..
Method.end
}
Method m
Method.end
return;
Dr. Welf Löwe und Markus Noga
52
Transformation eines Webepunktes
Wrapping eines Test-Aspekts
Method m (){
Method.begin
abc..
cde..
Method.end
}
return;
Method.begin
Method.end
Method m (){
print(„enter m“)
abc..
cde..
print(„exit m“)
return;
}
Dr. Welf Löwe und Markus Noga
53
Mehrfache Bindung eines Webepunktes
Method.begin
Druckaspekt
Method m
Method.end
Transaktionsaspekt
Dr. Welf Löwe und Markus Noga
54
Deklarierte Webepunkte
Z.B. Kommunikationstore:
Ansprache von Torobjekten (port objects)
Method m (){
OUT port
portOut.out(d);
portIn.in(e);
IN port
portOut.out
Method m
portIn.in
}
Dr. Welf Löwe und Markus Noga
55
Transformationen für Tore
m (){
OUT port
IN port
m (){
…
portOut.out(d);
portIn.in(e);
…
}
/*** ports */
e = x(d);
}
m (){
/*** ports */
setChanged(d);
notifyObservers(d);
listen_to(e);
}
Dr. Welf Löwe und Markus Noga
56
Einfache Bindung von Toren
portOut.out
Method m
portIn.in
call
Method x
call
Dr. Welf Löwe und Markus Noga
57
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
58
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
Methoden
(nach IDL)
-
Wrapper
CORBA & Co. RMI
Architektursysteme
Aufrufe an Tore Tore
-
Konnektoren
AOP
Aspekt
(beliebig)
Weben
Weben
Join points
Dr. Welf Löwe und Markus Noga
59
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
60
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
61
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
62
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
Dr. Welf Löwe und Markus Noga
63