Software aus Komponenten - IPD Goos

Prof. Dr. G. Goos Software aus Komponenten 1 

Software aus Komponenten 

Prof. Dr. Gerhard Goos 

Fakultät für Informatik 

Universität Karlsruhe 

Karlsruhe, Germany 2004 

c○ Gerhard Goos, Dirk Heuzeroth, 

Elke Pulvermüller, Volker Kuttruff 

2004 

http://www.info.uni-karlsruhe.de/

Organisation 

• Vorlesung: 

◮ 1. Dienstag 14:00 – 15:30, -101, wöchentlich 

◮ 2. Mittwoch 14:00 – 15:30, -101, vierzehntägig 

• Übungen: 

◮ Mittwoch 14:00 – 15:30, -101, vierzehntägig, erstmals 28.04.2004 

• Übungsleiter: Dr. Dirk Heuzeroth, Mamdouh Abu-Sakran, Volker Kuttruff 

• Adressen: 

◮ Allgemeines Verfügungsgebäude, 2. OG 

◮ ggoos@ipd.info.uni-karlsruhe.de 

◮ heuzer@ipd.info.uni-karlsruhe.de, msakran@ipd.info.uni-karlsruhe.de, 

kuttruff@fzi.de 

• Sprechstunden: 

◮ Goos: Dienstags 16:00 – 17:00 

◮ Heuzeroth, Abu-Sakran, Kuttruff: Mittwochs 16:00 – 17:00 

• Vorlesungsseite: 

http://www.info.uni-karlsruhe.de/lehre/2004SS/swk 

Prof. Dr. G. Goos Software aus Komponenten 2

Grundlagen 


1.2 Komponentenbegriffe 


Real Component Systems 

Real Component Systems 

LEGO 

Reale Komponentensysteme 

bricks 

• LEGO 

LEGO 

IC 

• Hohlblöcke 

bricks 

• ICs 

IC 

• Hardware-Busse Hardware-Bus 

Hardware-Bus 

• Was unterscheidet Difference to siesoftware von Methoden construction? der Software-Konstruktion? 

Difference to software construction? 

Gerhard Goos, Software from Components, Overview 9

Reale Komponentensysteme 


System Schnittstellen Komposition Anpassung 

LEGO Noppen Zusammen- - 

stecken 

Ziegel Form, Profil Mörtel Stücke abbrechen 

ICs, Bus Anschluß-Signal- Zusammen- Signale konvertieren, 

Spezifikation stecken, Löten filtern, puffern, . . . 

Software Signaturen Aufruf Daten, Funktionen, 

Protokolle Umwickeln Protokolle, ...

Komponenten, Komposition und Adaption 

• Entwurf nach Geheimnisprinzip (information hiding) 

◮ explizite Spezifikation von Schnittstellen 

◮ Implementierung bleibt verborgen 

• Komposition 

◮ Zusammensetzen von Komponenten nach lokalen Entwurfsprinzipien, 

die globale funktionale und nicht-funktionale Eigenschaften zusichern 

◮ Adaption von Komponenten, wenn nötig 

interne Adaption von Komponenten an ihren 

Wiederverwendungskontext 

externe Adaption: Anpassung der Schnittstellen für die 

Zusammenarbeit 


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

Andere 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 identifiable pieces that describe and/or perform 

specific functions, have clear interfaces, appropriate documentation, and a 

defined reuse status. 

Sametinger

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 dafür 

Explizit oder 

Implizit (Parameter von Konstruktoren oder Methoden) 

◮ Kein implizites Wissen 

• Komponenten sind wiederverwendbar 

• Komponenten können aus Komponenten zusammengesetzt sein 


Komponentenbegriffe 


• Drei Ebenen 

1. Eine Komponente ist eine Kollektion von Programmfragmenten mit 

einem Bauplan, um für eine bestimmte Aufgabe eine ausführbare 

Programmeinheit zu erzeugen. 

2. Eine Komponente ist ein Modul. Es gibt jeweils genau eine davon. 

3. Eine Komponente ist ein großes, in sich abgeschlossenes Teilsystem, 

welches eine bestimmte Aufgabe erledigt. 

• Beobachtung 

◮ 1. ist andere Formulierung unserer Definition. 

◮ 2. und 3. sind technisch äquivalent 

◮ Aber: Allein 3. garantiert ökonomische Skalierbarkeit.

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, usw. 

• können dynamisch geladen und ersetzt werden 

◮ Programme können Komponenten mit Reflexion betrachten und deren 

Dienste feststellen 

◮ Ignorieren unbekannter funktionaler Aspekte 

Reflexion: Die Fähigkeit eines Programmes, seinen Zustand zur 

Laufzeit zu inspizieren und seine Funktionalität zu bestimmen. 


Komposition 


• Ausfalten generischer Komponenten (homogen/heterogen) 

• Zusammensetzen von Komponenten gemäß Verträgen: 

◮ über Funktionen und Daten 

◮ über Kommunikation, Synchronisation und Protokolle 

◮ Problem der globalen Lebendigkeit (Verklemmungsfreiheit)? 

◮ Wie gehen nicht-funktionale Eigenschaften ein? 

• Mangelnde Passung erfordert Adaption (Anpassung) der Komponenten: 

◮ Externe Adaption durch ” 

Klebecode“ (glue code) 

◮ Interne Adaption: 

Offenes Einsetzen 

Invasiver Austausch nicht-funktionaler Aspekte (z.B. 

Basiskommunikation tauschen, Synchronisation einfügen usw.)

Exkurs: Generische Komponenten 


• Beispiel: Auf einem Graphen mit Adjazenzmatix A = (a ij ), 

betrachte folgende Probleme für i ≠ j: 

◮ Existiert ein Pfad von i nach j? 

◮ Länge des kürzesten Pfades von i nach j? 

◮ Maximaler Fluß von i nach j? 

(die Kapazitäten sind durch a ij gegeben) 

• Der generische Floyd-Warshall-Algorithmus löst alle drei Probleme 

◮ ∀k ∈ [1, n] : a kk := c 

∀k ∈ [1, n]: 

∀i ∈ [1, n]: 

∀j ∈ [1, n]: 

a ij := a ij σ (a ik τ a kj ) 

• Übung: Bestimme die Konstante c und die Operationen σ, τ für alle 

Probleme. Welche algebraischen Eigenschaften müssen σ, τ aufweisen? 

• Übung: Schreibe eine Schablone (template) in C++, die mit 

entsprechenden Parametern die Probleme löst. 

◮ Bemerkung: Dieses Beispiel ist nicht OO-spezifisch. Können Sie es in Pascal oder C 

lösen?

Exkurs: Generische Komponenten II 

• Verallgemeinerung und Schlußfolgerungen: 

◮ Eine generische Komponente besteht aus (einer oder mehreren) 

‘‘generischen’’ Klassen, die durch Datentypen, Operationen, 

Implementierungen , . . . parametrisierbar ist 

◮ Die generische Klasse wird ausgefaltet, indem sie mit Exemplaren der 

Parameter versorgt wird. 

◮ Beispiele 

Schablonen in C++ (zu allgemein, unsystematisch definiert) 

Generische Pakete in Ada 

Generische Klassen in Eiffel, Sather, ..., (Pizza, Java 1.5, C# 2.0) 

◮ elementare Hauptanwendung: Behälter (Keller, Listen, ...) 

◮ Problem: Viele Operationen der generischen Klasse werden auf 

Parameter angewendet. Sicherstellen, daß die Operationen existieren? 

Lösung: beschränkte Polymorphie (bounded polymorphism) 


generisch vs. generativ 


Generatives Programmieren ist ein Softwareentwicklungsparadigma, das für 

eine gegebene Anforderungsspezifikation Software-Systemfamilien 

modelliert und aus dem Konfigurationswissen sowie elementaren, 

wiederverwendbaren Implementierungskomponenten automatisch bei 

Bedarf ein maßgefertigtes und optimiertes Zwischen- oder Endprodukt 

erzeugt. 

Generische Komponente ist eine parametrisierte Komponente.

Wiederholung: Entwurf mit Verträgen 


• Problem: Programmeinheiten (Klassen, Methoden, . . . ) kommunizieren 

◮ Schnittstellen müssen syntaktisch und semantisch passen 

• Lösung: Einführen von Zusicherungen (i. a. Formeln im Prädikatenkalkül), 

die die benötigten Eigenschaften beschreiben 

◮ Vorbedingung: muß vom Aufrufer erfüllt werden, damit der Aufruf 

funktionieren kann 

◮ Nachbedingung: kann der Aufrufer nach der Rückkehr verwenden 

(sofern die Vorbedingung erfüllt war) 

◮ Klasseninvariante: Zusicherung über den Zustand einer Datenstruktur 

vor und nach jeder Manipulation ( ” 

Grundzustand der DS“)

Wiederholung: Entwurf mit Verträgen II 


• Solche Zusicherungen heißen Verträge (contracts, Bertrand Meyer, Eiffel) 

zwischen Aufrufer und Aufgerufenen 

• Grundlegende OO-Entwurfstechnik: Zunächst nur Verträge zwischen 

Klassen und ihren Methoden definieren 

◮ deckt nur funktionale Eigenschaften ab 

• wendet Standardtechniken der Verifikation ( ” 

Hoare Logik“) auf 

Programmieren im Großen an 

◮ amüsant: ” 

Entwurf mit Verträgen“ wird von Praktikern geschätzt und 

großflächig eingesetzt, aber ‘‘Verifikation’’ gilt als nicht praktikabel; 

allein der Namenswechsel macht den Unterschied.

Wiederholung: Entwurf mit Verträgen III 

• Beschränkungen: Allgemeinheit vs. Spezialfälle 

◮ Ein Programm erfüllt seine Verträge, wenn die Zusicherungen für alle 

gültigen Eingaben erfüllt werden 

(ebenfalls durch Zusicherungen geregelt) 

◮ Aber: Jeder Test einer Zusicherung zur Laufzeit sichert die 

Vertragserfüllung nur für diesen speziellen Aufruf 

◮ also: Verträge müssen statisch (von Hand) geprüft werden 

◮ Tests zur Laufzeit prüfen nur Spezialfälle 

inakzeptabel für verläßliche Systeme 

akzeptabel, wenn ein Fehlschlag keine Schäden anrichtet 

(abgesehen von Verzögerungen) 


Einige Kommunikationsarten 


• Normaler Prozeduraufruf 

• Rückruf (callback) und Ereignisse 

• Fernaufruf (remote procedure call, remote method invocation) 

◮ Einpacken der Objekte in Byte-Strom, Verschicken, Auspacken 

◮ kann in heterogenen Systemen eingesetzt werden 

Z.B. Java RMI, CORBA usw. 

• Gemeinsamer Speicher (synchronisiert mit Semaphoren, . . . ) 

• uni- oder bidirektionale FIFOs (z.B. pipes, sockets) 

• Anschlagtafeln (blackboards, strukturierte Anschlagtafeln (Linda 

Tupelraum) 

• Transaktionsdienste (Datenbank) 

• Migration von Code (z.B. Java Applets)


Beispiel: Rückruf und Ereignisse: Konzepte 

Example: Callbacks and Events I 

abstract solution 

goal: communication client-server whenever a situation 

(event, state change) arises at the server requiring action 

• Ziel: Kommunikation zwischen Dienstnehmer und Dienstgeber, wenn eine 

Situation by the client (Ereignis, Zustandsübergang) im Dienstgeber Aktivität des 

Dienstnehmers erfordert 

abstract solution: introduce event server between client and 

• abstrakte Lösung: Ereignisdienst als Zwischenschicht einführen 

server 

event 

client 

server 

server 

◮ Dienstnehmer abonniert relevante Ereignisse beim Dienstgeber 

client notifies event server in advance about all events of interest 

relevant“ durch Nebenbedingungen weiter einschränkbar 

“interest” ” 

◮ Dienstgeber may benachrichtigt constraint by Dienstnehmer mentioning additional über conditions Ereignisse (mit 

Nutzdaten) 

server notifies event server about all incoming events (state 

changes) including additional information 

◮ Ereignis kann keinen, einen, oder beliebig viele Dienstnehmer erreichen 

event server may notify zero, one or several clients about the event 

◮ Synchrone oder asynchrone Benachrichtigung 

notification by event server may be synchronous or asynchronous 

◮ Ereignisdienst oft im Dienstgeber integriert (Ereignisschleife) 

event server often integrated into the server (“event loop”) 

Gerhard Goos, Software from Components, Overview 22

Beispiel: Rückruf und Ereignisse II 


• Aufrufer übergibt Prozedurvariable oder Verweis auf Objekte (anonyme 

Klasse in Java, Rückruf-Dienst in Corba, delegate in C#, .Net) 

◮ Rückruf durch Rahmensystem, Bibliothek oder Dienstgeber 

◮ Zuerst eingesetzt zur Anbindung von Programm und 

Benutzerschnittstelle 

• Ereignisse 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

Echtzeitbedingungen 


Vorlesung betrachtet o.B.d.A. keine Echtzeitsysteme 

• Echtzeitbedingungen lassen sich in einem Automaten separat zu den 

Zustandsübergängen (funktionaler Automat) des betrachteten Systems 

spezifizieren und mit diesem bei Bedarf zusammenfügen (Dissertation 

Lötzbeyer). 

⇒ Zeitbedingungen lassen sich in die Komponentenschnittstelle 

aufnehmen. 

• Wichtig für die Analyse: Scharfe Unterscheidung zwischen Eingabewerten, 

Ausgabewerten und lokalen Variablen in einer Komponente, d. h. 

transiente Parameter nicht zugelassen 

⇒ Komponente kann zu einer Menge von Zuweisungen 

ausgabeparameter := f(eingabewert) 

abstrahiert werden.

1.3 Vorgehensweisen 


1.3.1 Merkmalsanalyse 

1.3.2 Produktlinien

1.3.1 Merkmalsanalyse 


• Merkmalsanalyse (Feature Analysis) modelliert Systemfamilien 

◮ identifiziere Variationspunkte 

◮ zähle Alternativen auf 

◮ bilde Hierarchien (momentan starr) 

• Arten der Variation 

◮ innerhalb eines Systems zur Laufzeit 

◮ zwischen einzelnen Läufen eines Systems 

◮ zwischen Mitgliedern der Systemfamilie 

• Darstellung als Merkmalsdiagramme (feature diagrams) 

◮ Untermenge regulärer Ausdrücke (kein Kleene’scher Stern) 

◮ graphische Darstellung als Baum 

◮ redundante Repräsentation → Normalformen 

• Abbildung auf Sprachmechanismen 

• Abgrenzung zu Aspekten?

Merkmalsmodellierung 

• Zweck: 

◮ Beschreibung des Anforderungsraumes eines bestimmten Bereichs 

(Domäne). 

◮ Eine spezifische Implementierung kann man auffassen als eine ” 

Instanz 

des Merkmalsmodells“ oder eine Menge von Merkmalen, die einzelne 

Fähigkeiten eines Systems oder eine Menge von Systemen beschreiben. 

◮ Kommunikationsmedium zwischen Anwendern und Entwicklern. 

• Merkmale sind Attribute eines Systems, die direkt den Endanwender 

betreffen. Ein Merkmal ist damit ein bedeutender oder unverkennbarer, für 

den Anwender sichtbarer Aspekt, eine Qualität oder Charakteristik eines 

Software-Systems oder einer Menge von Software-Systemen. 

• Merkmal, Belang und Aspekt sind Synonyme. 

• Merkmalsmodell 

◮ ist Ergebnis einer Merkmalsanalyse 

◮ erfaßt das Verständnis des Endanwenders von den allgemeinen 

Fähigkeiten der Anwendungen in einem Bereich 

◮ erfaßt die gemeinsamen Merkmale und Unterschiede der Anwendungen 

in einem Bereich (Familie von Anwendungen) 


Merkmalsmodelle 

• Es gibt verschiedene Ansätze und Notationen: 

◮ Die wichtigste ist FODA. 

◮ Weitere (Erweiterungen oder Variationen): Czarnecki/Eisenecker, Stan 

Jarzabek, Jan Bosch, Jacobson/Griss, Coleman, Matthias Clauss, etc. 

• Elemente eines Merkmalsmodells sind nach Kang, Cohen, Hess, Novak, 

Peterson: 

◮ Merkmalsdiagramm 

◮ Kompositionsregeln 

◮ Belange und Entscheidungen 

◮ Systemmerkmalskatalog 


Elemente von Merkmalsdiagrammen 


Definition von Merkmalen 


Name: [ FROM < Quellname > ] 

Description (Beschreibung): < Textuelle Beschreibung des Merkmals > 

Consists Of (Besteht aus) [ { optional | alternative } ] 

Source (Quelle): < Informationsquelle > 

Type (Bindezeit): { compile-time | load-time | runtime } 

Cross-tree Constraints (Composition rules): 

[ Mutually Exclusive With: < Merkmalsnamen > ] 

[ Mandatory With: < Merkmalsnamen >] 

• Belange und Entscheidungen: Entscheidung - Beschreibung - Begründung 

• Systemmerkmalskatalog: Tabelliere Merkmale und Merkmalswerte 

existierender Systeme

Merkmalsdiagramm mit Korrelation 


Quelle: Lars Geyer, Universität Kaiserslautern

1.3.2 Programmfamilien und Produktlinien 


We consider a set of programs to constitute a family whenever it is 

worthwhile to study programs from the set by first studying the common 

properties of the set and then determining the special properties of the 

individual family members. (Parnas, 1976) 

A software product line is a set of software-intensive systems sharing a 

common, managed set of features that satisfy the specific needs of a 

particular market segment or mission and that are developed from a common 

set of core assets in a prescribed way (Clements, 2002)

Produktlinien als Beispiel erfolgreicher Wiederverwendung 


Produktlinien: 

• Fest definierte Anwendungsdomäne 

⇒ ermöglicht umfassende Domänenanalyse: 

◮ Merkmalsanalyse liefert Gemeinsamkeiten und Variabilitäten der 

Mitglieder der Produktlinie. 

⇒ ◮ Menge geeigneter Komponenten 

◮ generische Architektur: Beschreibung der Zusammensetzung aller 

Mitglieder der Produktlinie durch Variabilitäten, 

d. h. Menge der Komponenten, die ein konkretes Mitglied bilden, 

wird nach fest vorgegebenem Verfahren anhand konkreter Werte 

gebildet. 

Eine Architektur gibt also die Menge der Komponenten und deren 

Zusammensetzung zu einem konkreten System an. 

⇒ Vermeidung von Paßfehlern 

• erfordert präzise Planung, um Variabilitäten zu erfassen. 

• erfordert Konfiguration, um Variabilitäten passend zu belegen.

Produktfamilien 



Der Entwicklungsprozeß 



Prozeßschritte 



Konstruktion eines Mitglieds einer Produktlinie 



Einschränkungen 

• funktioniert nicht oder nur teilweise mit COTS: 

◮ COTS passen i. a. nicht in generische Architektur, weil COTS nicht 

aus der Domänenanalyse hervorgehen. (vgl. Folie 9) 

• Merkmale beschreiben hauptsächlich funktionales Verhalten 

⇒ Interaktionsverhalten ist schlecht oder überhaupt nicht durch Merkmale 

faßbar und damit nicht konfigurierbar 

⇒ Architektur sollte konfigurierbar sein 

• Evolution bzgl. neuer Anforderungen ist sehr aufwendig: 

◮ Anpassung der Produktlinienarchitektur statt einzelner Produkte 


Konsequenzen 


• Wiederverwendung funktioniert im Falle von Produktlinien 

• Die Einschränkung bzgl. COTS ist praktisch irrelevant, 

denn nach (Lampson, 2003) funktionieren COTS ohnehin nicht 

(vgl. Folie 18). 

• Interaktionsanpassungen erfordern Architekturevolution: 

Änderung der Interaktion zwischen Komponenten bedeutet im allgemeinen 

eine Änderung der Zusammensetzung des Systems oder beeinflußt diese. 

⇒ Änderung von Interaktionsbeziehung impliziert Änderung der 

Architektur. 

• Neue Anforderungen erfordern komplette Überarbeitung der Produktlinie

1.4 Umgebungssysteme 


1.4.1 UML 

1.4.2 Versionsverwaltung: CVS 

1.4.3 Erweiterbare integrierte Entwicklungsumgebungen: 

Eclipse

1.4.1 Modellieren mit UML Komponenten-Diagrammen 


Billing.exe 

Billing 

System 

Register.exe 

Course.dll 

Course 

People.dll 

User 

Student 

Professor 

Course 

Course 

Offering 

Copyright © 1997 by Rational Software 

Corporation

Probleme mit UML 


• Semantik sehr flexibel 

• Nichts ist definiert, also keine Anpassung nötig 

• Problem der Implementierung 

• Probleme je nach Implementierungssprache oder -system 

Aber: 

• Ein Großteil aller DV-Probleme (80%?) folgen in ihrer Programmstruktur 

dem Aufbau von Datenstrukturen, die sich mit UML gut modellieren 

lassen. 

• löst UML 2.0 (Ende 2004?) die Probleme besser?

1.4.2 Versionsverwaltung: CVS 


CVS: Concurrent Versions System 

Motivation und Begriffe: 

• Programme werden weiterentwickelt, d. h. die Entwickler modifizieren evtl. 

simultan die zugehörigen Dateien. 

• Modifikation einer Datei ergibt eine neue Revision. 

Revisionen sind numeriert. 

• Eine Kollektion von Dateien mit bestimmten Revisionsnummern faßt man 

zu einer Version des Systems/Produkts zusammen. 

Beispiel: Version 2.3 bestehe aus der Revision 1.42 von Datei A und der 

Revision 2.15 von Datei B

Versionsverwaltung: Aufgaben 


• Aufgabe: Rückgriff auf frühere Revisionen, z.B. Meldung eines Fehlers, 

der sich auf diese bezieht. 

Naive Lösung: Manuelle Verwaltung der Revisionen z.B. durch Kopieren 

der Dateien und Namenskonventionen 

Problem: fehleranfällig und speicherintensiv 

• Aufgabe: Koordinieren simultaner Änderungen 

Naive Lösung: Sperren der Datei, Bearbeiten der Datei, Entsperren der 

Datei (lock-modify-unlock model) 

Probleme: 

◮ Verwaltung der Sperren aufwendig und unübersichtlich. 

◮ Stehlen von Sperren kann notwendig werden. 

⇒ Funktioniert nur, wenn Entwickler nahe beieinander sitzen 

⇒ Automatisierung durch Versionsverwaltungssystem notwendig

Versionsverwaltung: Hintergründe 

• Warum interessiert uns das? 

◮ Entwicklung großer Systeme (aus Komponenten) bedeutet Arbeit im 

Team 

◮ Komponente ist Menge von Programmfragmenten, die wir verwalten 

müssen. 


Versionsverwaltung: CVS konkret (1) 


CVS-Ansatz: copy-modify-merge model (CVS: http://www.cvshome.org) 

• Revisionen werden in zentraler Ablage (engl. repository ) verwaltet: 

◮ Ablage ist durch Baum im Dateisystem realisiert. 

◮ Erstellen einer zentralen Ablage im Verzeichnis /public/cvs: 

cvs -d /public/cvs init 

◮ Importieren vorhandener Quellen aus dem Verzeichnis 

/home/arthur/myproj: 

cd /home/arthur/myproj 

cvs -d /public/cvs import -m "initial import into CVS" myproj 

arthur-soft start 

Die Syntax des import-Befehls ist allgemein: 

cvs -d repository-root-dir import -m "log msg" projname 

vendortag releasetag


• Anfordern einer Arbeitskopie des Projekts 

(engl. checking out working copy ): 

◮ Kein Entwickler darf direkt in der zentralen Ablage arbeiten, sondern 

nur auf einer Kopie der Dateien. 

◮ Die Arbeitskopie enthält alle Projektdateien der angefragten (meist 

aktuellen) Version. 

Die aktuelle Version wird von CVS automatisch HEAD genannt und 

enthält die aktuellen Revisionen. 

◮ cvs -d /public/cvs checkout myproj 

• Bearbeiten der Dateien der Arbeitskopie (modify phase): 

◮ Jeder Entwickler bearbeitet die Dateien seiner Arbeitskopie separat mit 

seinem Lieblingseditor. 

◮ Entwickler dürfen auch neue Dateien erstellen. 

Neue Dateien müssen die Entwickler dem Verwaltungssystem 

bekanntmachen: 


cvs add newfile.ext 



• Änderungen in die Ablage eintragen (commit phase): 

◮ cvs commit 

◮ Kann fehlschlagen, weil andere Entwickler Änderungen an den selben 

Dateien vorgenommen und bereits in die Ablage eingetragen haben. 

Daher: 

◮ Konsolidierungsphase (merge phase): 

Mischen der Änderungen aus der Ablage mit den eigenen: 

cvs update 

Bemerkung: Auch um Arbeitskopien zu aktualisieren verwaltet CVS alle 

Änderungen einer Datei seit ihrer Entstehung als Differenzen/Deltas. Auf 

Dateiebene verwendet CVS zu diesem Zweck das RCS (revision control system). 

Manuelles Anpassen der Dateien, die CVS während des Aktualisierens 

(update) entsprechend kennzeichnet. 

Die in Konflikt stehenden Textpassagen kennzeichnet CVS ebenfalls 

deutlich. 

Prüfen, ob sich das System in der eigenen Arbeitskopie fehlerfrei 

übersetzen und ausführen läßt. 

Erneuter Versuch, die Änderungen in die Ablage einzubringen: 

cvs commit 


CVS: Weitere Funktionen (1) 


• Hilfe erhalten: 

◮ allgemein zu cvs: cvs --help 

◮ zu speziellem CVS-Befehl, z. B.: cvs add -H 

• Dateien löschen: 

cvs delete filename 

cvs commit filename 

• Status der Arbeitskopie erfragen: 

cvs status 

Dies liefert auch die Revisionsnummern der einzelnen Dateien. 

• Änderungen anschauen: 

◮ Änderungen zwischen Arbeitskopie und zentraler Ablage: 

cvs diff -c filename 

◮ Änderungen zwischen zwei Revisionen: 

cvs diff -r1.1 -r1.5 filename 

• Änderungshistorie anschauen: 

cvs history 

• Protokollnachrichten anschauen: 

◮ alle Dateien der Arbeitskopie: 

cvs log 

◮ bestimmte Datei: 

cvs log filename


• Zugriff auf entfernte Ablagen (accessing remote repositories): 

◮ Zugriff per rsh/ssh: 

cvs -d :ext:arthur@cvs.server.org:/public/cvs checkout 

◮ Zugriff über den CVS-Server-Prozeß: 

cvs -d :pserver:arthur@cvs.server.org:/public/cvs login 

cvs -d :pserver:arthur@cvs.server.org:/public/cvs checkout 

• Beobachten: Sich benachrichtigen lassen, wenn andere Entwickler 

bestimmte Dateien in der Ablage bearbeiten/ändern. 

◮ In CVSROOT/loginfo eintragen, daß man eine EMail erhalten möchte, 

wenn jemand ein cvs commit ausführt. 

◮ Watches: Eintrag in CVSROOT/notify und ggf. Einträge in CVSROOT/users 

vornehmen. 

• Versionen kennzeichnen: Alle Revisionen des Arbeitsverzeichnisses in der 

Ablage mit einer symbolischen Marke (Versionskennzeichnung) versehen. 


cvs -d /public/cvs tag marke 




• Verzweigungen (Branches): Beispielsweise sinnvoll, wenn man einen Fehler 

in einer alten Version korrigiert. 

◮ Aufspalten der Historie bei der alten Version: 

1 Arbeitskopie der alten Version beschaffen: 

cvs checkout -d myproj_old_release -r Release-2003_12_06 myproj 

2 Verzweigung markieren: 

cvs tag -b Release-2003_12_06_bugfix_branch 

Schritt 1 und 2 kann man abkürzen durch: 

cvs rtag -b -r Release-2003_12_06 Release-2003_12_06_bugfix_branch myp 

3 Arbeitsverzeichnis für die Verzweigung einrichten: 

cvs checkout -d myproj_branch -r Release-2003_12_06-bugfix_branch 

◮ Änderungen an den Dateien in diesem Verzeichnis durchführen. 

◮ Änderungen in die zentrale Ablage übernehmen: cvs commit 

◮ Diesen Punkt markieren, damit man bei weiteren Fehlerkorrekuren auf 

der Verzweigung von hier ab in den Stamm integriert und nicht vom 

Beginn des Zweiges auch die schon integrierten Fehlerkorrekturen: 

cvs tag Release-2003_12_06-bugfix_branch-fix1


(Verzweigungen: Fortsetzung) 

◮ Zweig mit Stamm zusammenführen (merging branch to trunk)): 

1 Aktuellen Stand des Stamms aus der Ablage in die Arbeitskopie 

übertragen (dabei Sondermarken mit -A löschen): 

cvs update -d -A 

2 Verzweigung in den Stamm integrieren: 

cvs update -d -j Release-2003_12_06_bugfix_branch 

3 Integriertes Arbeitsverzeichnis (nach Prüfung) in die zentrale Ablage 

eintragen: cvs commit 


• CVS konfigurieren: 

◮ Umgebungsvariablen: 


CVSROOT ist das Wurzelverzeichnis der zentralen Ablage. 

Setzt man CVSROOT = /public/cvs, dann kann man in allen o.g. 

Beispielen auf die Angabe von -d /public/cvs beim Aufruf von cvs 

verzichten. 

CVSEDITOR: Editor zum Eintragen von Protokollierungsnachrichten 

(engl. log messages). 

Beispiel: CVSEDITOR=’emacs -nw’ 

CVSUMASK: Zugriffsberechtigungen für die Dateien in der zentralen 

Ablage festlegen. 

Beispiel: CVSUMASK = 003 

CVS RSH gibt an, wie sich CVS mit einem entfernten Rechner 

verbinden soll, auf dem eine Ablage liegt. 

Beispiel: CVS RSH = ssh 

◮ Konfigurationsdateien: 

.cvsignore legt von CVS zu ignorierende Dateien fest. 

Beispiel: Eintragen von *.class in .cvsignore 

Globale Einstellungen in .cvsrc. 

Beispiel: update -d legt fest, daß update immer mit der Option -d 

ausgeführt wird und damit auch neue Verzeichnisse aktualisiert 

werden. 

• Graphische Oberflächen: WinCVS, WebCVS 


1.4.3 Erweiterbare integrierte Entwicklungsumgebungen 

• Interessant aus zwei Gründen: 

1 Verwaltung großer Projekte: 

◮ mehrsprachig 

◮ inkrementelle Übersetzung wichtig 

◮ Projekt- und Konfigurationsverwaltung 

◮ Testverwaltung 

◮ . . . 

⇒ Einheitliche Verwaltung einer Vielzahl von Werkzeugen 

2 Komponentenarchitektur der Entwicklungsumgebung: Einsetzen von 

Komponenten, um die Funktionalität der Entwicklungsumgebung zu 

erweitern 

• Speziell: Eclipse 

◮ Basisplattform stellt Infrastruktur für die Interaktion von 

Erweiterungskomponenten, sogenannten Plug-ins. 

◮ Plug-ins für verschiedene Übersetzer, Editoren, Konfigurations- und 

Build-Werkzeuge, etc. 


Erweiterungsmechanismus in Eclipse 


• Erweiterungspunkte (extention points) definieren Stellen, zum Einhängen 

von Erweiterungen. 

• Eine Erweiterung (extention) definiert, welchen Erweiterungspunkt sie wie 

erweitert. Erweiterungen werden von Erweiterungskomponenten definiert 

und implementiert. 

• Erweiterungspunkte und Erweiterungen sind in XML-Dateien (den 

sogenannten Manifest-Dateien) beschrieben, die zu den jeweiligen 

Komponenten gehören. 

Grund: Man kann die Abhängigkeiten der Komponenten prüfen, ohne 

deren Code laden zu müssen. 

Der Code wird bei der ersten Benutzung (Aktivierung) der 

Komponente geladen. 

• Technik: 

◮ Ein Erweiterungspunkt definiert eine Schnittstelle. 

◮ Eine Erweiterung liefert eine Implementierung für diese Schnittstelle. 

◮ Die zu einem Erweiterungspunkt verfügbaren Erweiterungen verwaltet 

eine Registratur (Registry ). Die Registratur wird beim Start der 

Entwicklungsumgebung im Speicher angelegt.

Eclipse Metapher 


• Sicht: Eine Repräsentation des Datenmodells/Programms oder die damit 

in Zusammenhang stehenden Daten. Eine Sicht hat ein eigenes Fenster 

im Arbeitsbereich. 

• Perspektive: Eine Menge von in einer bestimmten Weise auf dem 

Bildschirm in Fenstern angeordneten Sichten (auf das Datenmodell / 

Programm oder die damit in Zusammenhang stehenden Daten, wie z.B. 

Programmausgaben). 

• Beispiel: Eclipse bietet eine CVS-Perspektive, die u. a. den 

Verzeichnisbaum der Arbeitskopie und die Revisionsnummern der 

einzelnen Dateien in einem Fenster darstellt.

Eclipse: Java Perspektive 


1.5 Klassische Ansätze 

◮ UNIX 

◮ Module 

◮ Klassen und Vererbung 

◮ Rahmensysteme (framework) 

• betrachtet als Komponentensysteme 

mit Diskussion der Probleme 


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 usw. 

• Komposition mit Pipes in Shells und Skriptsprachen 

• Adaption: 

◮ externe Adaption durch eigenständige Komponenten, meist 

programmierbare Filter (awk, cut, grep, sed, usw.) 

◮ interne Adaption nicht unterstützt

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 


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

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! 


Objektorientierte Klassensysteme 

• Klassen sind Module 

◮ können mehrere zur Laufzeit erzeugte Objekte haben 

◮ Objekte haben Zustände (evtl. persistent) 

• Vererbung und Untertypbeziehungen 

◮ Polymorphie 

◮ Späte Bindung von Aufrufen ( ” 

faule Auswertung“) 

• Betrachtung als Komponentensystem: 

◮ Basiskommunikation: (Polymorphe) Methodenaufrufe, Variable 

◮ Schnittstellen: Polymorphe Methoden, Objekt- und Klassenvariable 

◮ Generierung: sprachspezifisch, oft mit generischen Klassen 

◮ Adaption: durch Vererbung oder Delegation 


Generische oder Abstrakte Klassen 


generic/abstract class 

instance 

system 

implementation

Probleme 

• Sprachabhängigkeit der 

◮ Basiskommunikation 

◮ Spezifikation von Daten und Prozeduren 

◮ Synchronisation 

• Protokolle nicht spezifiziert 

• Adaption durch Spracheigenschaften eingeschränkt 

(Kontravarianz oder Kovarianz bei Vererbung) 

• Fehlende Werkzeuge zur Verteilung 

• Heterogene, verteilte Lösungen erfordern viel Handarbeit! 


Rahmensysteme (Frameworks) 

• Rahmensysteme sind Klassensysteme mit ” 

Rahmen“ 

◮ Der Rahmen bestimmt, welche zusätzlichen Klassen mit welchen 

Eigenschaften hinzugefügt werden müssen, um ein lauffähiges System 

zu erhalten. 

◮ Der Rahmen spezifiziert also auch einen Bauplan für das Gesamtsystem 

• Das Rahmensystem bestimmt Ablauf und Kommunikation einer 

Anwendung 

• Parametrisierung durch Klassen 

• Rahmensysteme als Komponentensysteme: 

◮ Basiskommunikation: Methodenaufrufe 

◮ Schnittstellen: Brennpunkte (hot spot) — Mengen von polymorphen 

Methoden 

◮ Generierung: Instantiierung der Parameterklassen oder Implementierung 

der abstrakten Klassen gemäß den Einschränkungen des Rahmens 

◮ Adaption: durch Vererbung oder Delegation 


Rahmensysteme 


parameter classes 

instances 

system 

implementation 

implementation

Probleme 


• Oft sprachabhängig 

• Keine Wiederverwendung in fremdem Kontext 

(Grund: zu starke Standardisierung) 

• Rahmen legt Möglichkeiten im voraus fest: 

◮ Adaption 

◮ Verteilung 

◮ Art der Kommunikation 

◮ Heterogene Lösungen

1.6 Industrielle Komponentensysteme 

• Komponentensystem (Plattform, Rahmensystem) 

◮ definiert Standards für Komponenten: Schnittstellen, Protokolle, 

Aufgaben kommerzieller Systeme 

Kommunikations- und Implementierungsbasis 

◮ stellt Grundvoraussetzungen (Corba, (D)COM, für Einsatz der EJB) Komponenten sicher 

◮ reguliert Interaktionen zwischen den Komponenten 

• Busse Daten- garantieren und Hardware-Interoperabilität 

Interface-Beschreibung 

• Komponentensysteme 

Referenz- und Wertesemantik 

liefern Äquivalent für Software: 

◮ Objekte, die in einen Softwarebus gesteckt werden können 

Kommunikation (Nachrichten und RMI) 

◮ Mit dem Bus und einer Menge von standardisierten Schnittstellen 

bilden Verteilung, sie ein Komponentensystem Persistenz, Heterogenität (Plattform) 

Softwarebus 

Dr. Welf Löwe und Markus Noga 2 


CORBA, (D)COM, .Net, EJB, WebServices 

• Basiskommunikation: 

◮ Normale Prozeduraufrufe an Kommunikationssystem 

◮ Weiterleitung über normale Aufrufe und Fernaufrufe 

• Standardisierte Schnittstellen 

◮ set/get Properties, 

◮ QueryInterface (Corba), IUnknown (COM), EJBHome (EJB) 

◮ Namensdienste usw. 

• Generierung: aus Klassen und Definitionssprachen 

• Nur externe Adaption: 

◮ Für verteilte Systeme (Weiterleiten von Aufrufen über Fernaufrufe, 

marshaling) 

◮ Für gemischtsprachliche Systeme (IDL) 


CORBA 


CORBA 

• Offener Standard, siehe http://www.corba.org 

• Unabhängig von Sprache und Verteilung 

open standard, see http://www.corba.org 

• Schnittstellendefinitionssprache (interface definition language) IDL 

independent from programming language and distribution 

• Komponenten als Quellcode oder binär 

interface definition language IDL 

source code or binary components 

client 

Java 

IDL stub 

client 

C 

IDL stub 

server 

C++ 

IDL skeleton 

object adapter 

Object Request Broker (ORB), Trader, Services

(D)COM 

(D)COM 

• Microsoft proprietär, siehe http://www.activex.org 

Microsoft proprietary, see http://www.activex.org 

• ähnelt CORBA, aber einige Einschränkungen 

similar to CORBA 

• rein binärer Standard 

only binary standard 

client 

VBasic 

COM stub 

client 

C++ 

COM stub 

server 

C++ 

COM skeleton 

monikers, registry 

Gerhard Goos, Software from Components, Overview 42 


(Enterprise) JavaBeans 


JavaBeans 

• Offener Standard, siehe http://www.javasoft.com 

• sprachabhängig: nur Java 

open standard, see http://www.javasoft.com 

• unabhängig von Verteilung (durch RMI) 

• 

language 

Quellcode 

dependent: 

oder Bytecode 

Java only 

independent from distribution (by RMI) 

components in source or byte code 

Java 

Bean 

Java 

Bean 

Java 

Bean 

Bean Container 

Event InfoBus, RMI

.Net 


• Alle Komponenten abgebildet auf Zwischensprache CLR (common 

language runtime) 

• kommt dem Bild des Softwarebus am nächsten 

• sprachunabhängig (aber Verweis-Arithmetik verboten) 

• viele Elemente durch ECMA-Norm festgelegt 

Aber 

◮ auf Verwendung von Windows zugeschnitten 

◮ unter Kontrolle von Microsoft 

⇒ Weiterentwicklung von den Geschäftsinteressen von Microsoft, nicht 

von denen der Kunden, abhängig

Einsatz von XML (WebServices) 

• Allgemeine Idee: 

◮ Ersetze UNIX’ Byteströme durch strukturierte Daten (Bäume) 

◮ Lasse mehrere benannte Ein- und Ausgaben zu 

◮ Erlaube syntaktische und semantische Datentransformationen 

• Komponenten sind eigenständige Programme oder Teile davon 

• XML als Austauschformat 

• XSLT für Datenanpassungen 

◮ Pfadsprache zur Musterbeschreibung, regelbasierte Ersetzung 

◮ andere Graphersetzungssysteme denkbar, nicht Standard 

• SOAP (Simple Object Access Protocol) als Basiskommunikation 

◮ Transport meist über HTTP 

• UNIX als Komponentensystem kann subsumiert werden 


1.7 Grundsätzliche Ansätze (akademisch) 

• Überlegungen: 

◮ Funktionaliltät gegeben, dann Weg zum Zusammenschließen finden 

⇒ Systemmodellierung notwendig: Nachweis, daß wir das 

Anwendungsproblem lösen! 

Paßfehler beim Zusammenschalten überbrücken 

⇒ Probleme müssen auf mehreren Ebenen gelöst werden: 

1 Problemebene (Anforderungen)/Modellierung: Simulation des 

Systems 

2 Architektur: Zerlegung in Komponenten und deren Interaktionen, 

Überbrücken von Paßfehlern 

3 Implementierung: Abbildung auf konkrete Sprache(n) 


Paßfehler 

• Paßfehler: Software-Komponenten machen inkompatible Annahmen über 

die Interaktion mit ihrer Umgebung 

• Syntaktische Paßfehler: Vom Übersetzer erkennbar, z. B. unterschiedliche 

Signaturen von Dienstdeklaration und Dienstaufruf. 

• Daten-/Strukturpaßfehler [Jackson1975]: Format und/oder Kodierung der 

zu kommunizierenden Daten auf Sender- und Empfängerseite sind 

unterschiedlich. 

• Architekturpaßfehler: 

◮ Mechanismuspaßfehler: Der für den Datentransfer vom Empfänger 

erwartete Mechanismus entspricht nicht dem vom Sender verwendeten 

Mechanismus. 

◮ Antriebspaßfehler [vgl. Garlan et. al. 1995]: Inkompatible Annahmen 

darüber, wer eine Interaktion initiiert. 

◮ Aktivitätspaßfehler [vgl. Garlan et. al. 1995]: Inkompatible Annahmen 

darüber, welche Interaktionspartner aktiv (Träger von Aktivität) und 

welche passiv sind. 

◮ Protokollpaßfehler [vgl. Garlan et. al. 1995]: Die Reihenfolge von 

Dienstanforderungen widerspricht dem in der Komponente 

vorgesehenen Ablauf. 

• Semantische Paßfehler: Falsche Annahmen über die erbrachte 

Funktionalität. 


Beispiel: Antriebspaßfehler 


public class Producer { 

private Consumer consumer = null; 

private int pNum = 0; 

} 

public Producer(Consumer c) { 

consumer = c; 

} 

public void produce() { 

Product p = new Product(pNum); 

System.out.println(p + " produced."); 

consumer.consume(p); 

} 

public class Consumer { 

private Producer producer; 

} 

public Consumer(Producer p) { 

prodcuer = p; 

} 

public void consume() { 

Product p = producer.produce(); 

System.out.println(p + " consumed."); 

}

Architektur 


Bewerkstelligung von Interaktionsanpassungen: 

• Man muß Abstraktionen finden für: 

◮ Schnittstellenkonsistenz 

◮ Protokollkonsistenz 

◮ Architekturkompatibilität 

• Die gesuchte Abstraktion heißt ein Konnektor (Garlan et al, 1993): Ein 

Konnektor kapselt die Interaktion zwischen Komponenten. Er verbindet 

die Interaktionspunkte, genannt Tore, von Komponenten. 

• Tor: Stelle in einer Komponente, an der die Komponente eine Eingabe 

von außen erwartet oder eine Ausgabe nach außen tätigen möchte. 

(Formalisierung später.)

Architektur: Probleme 


Problem: Explizite Konnektoren zur Laufzeit 

verringern meist die Systemleistung. 

Lösung: Eliminiere explizite Konnektoren, wenn möglich. 

Beispiel: Interaktion zwischen Symbolentschlüßler und Zerteiler in einem 

Übersetzer. 

Ausgangssituation: Symbolentschlüßler produziert Symbolstrom. 

Symbolstrom ist eine Datenstruktur, auf die der Zerteiler zugreift. 

Der Symbolstrom ist damit ein expliziter Konnektor. 

Konnektorelimination: Zerteiler ruft direkt den Symbolentschlüßler auf, 

um sich jeweils das nächste Symbol liefern zu lassen. Die Daten werden 

somit nach Bedarf des Zerteilers vom Symbolentschlüßler erzeugt. 

Ansätze: 

• Alle Konnektoren zu einem Software-Bus zusammenfassen 

• Aspektorientiertes Programmieren (AOP) 

• Invasive Komposition.

Modellierung 


Ziel: Ausführbare Systemmodellierung, um zu prüfen, daß das modellierte 

System das gegebene Problem löst 

Ansatz: Definiere die dynamische Semantik des Modells formal. 

Beispiel: Das Architektursystem Rapide. Dynamische Semantik ist durch 

abstrakte Ereignisinteraktion definiert.

1.8 Probleme und generelle Lösungen 


• Wie baue ich große Systeme in einer heterogenen Welt? 

A vision of software components working smoothly together, without regard 

to details of any component’s location, platform, operating system, 

programming language, or network hardware and software. 

Jon Siegel, Object Management Group (OMG), 1989 

⇒ Realisierung des Software-Bus: Man braucht Mechanismen zur 

Transparenz von 

◮ Sprachen (IDL) 

◮ Plattformen 

◮ Betriebssystemen 

◮ Ausführungsort: 

Global eindeutige Referenz 

Stellvertreterobjekte (stub/skeleton) 

Wiederverwendbare Dienste zum Ermitteln von Komponenten und 

deren Eigenschaften (z.B. für dynamische Komposition): 

· Namensdienst 

· Makler 

· Persistenz (Objekte aus Datenbank holen) 

· Reflexion (Schnittstellen erfragen) 

Objektverwaltung (Lebenszyklus) 

⇒ Anpassungen: Paßfehlerüberbrückung

Sprachtransparenz: Ziel 

• Ein Komponentensystem ist sprachtransparent, wenn für die Verwendung 

einer Komponente belanglos ist, in welcher Sprache sie implementiert ist. 

• Problem: Heterogenität mehrsprachiger Systeme 

◮ Aufrufkonzept 

Prozedur, Koroutine, Nachrichten 

◮ Aufrufrepräsentation 

Übergabekonventionen: Register, Stapel, ... 

Wer alloziert, wer räumt ab? 

◮ Datentypen 

Werte, Referenzen 

Arrays, Unions, Records 

Ko-/kontravariante Vererbung 

◮ Datenrepräsentation 

Breite und Kodierung primitiver Typen 

Layout zusammengesetzter Typen 

◮ Laufzeitumgebung 

Speicherverwaltung, Lebenszyklus 


Sprachtransparenz: Ansatz 

• Allgemeine Alternativen: 

◮ Direktes Anpassen: 

Konvertierung von jeder Sprache in jede andere 

⇒ Aufwand O(n 2 ) bei n Sprachen 

◮ Anpassen an Austauschformat: 

Bei n Sprachen n Abbildungen auf ein Austauschformat 

⇒ Aufwand O(n) 

◮ Standardisieren: Keine Anpassung, aber restriktiv. 

Aufwand O(1) für Erstellung des Standards. 

• In industriellen Komponentensystemen: 

◮ Aufrufkonzept 

standardisiert auf Prozedur (Fernaufruf) 

◮ Aufrufrepräsentation 

standardisiert auf C 

◮ Datentypen 

Anpassung an Austauschformat (IDL) 

◮ Datenrepräsentation 

Anpassung an Austauschformat (IDL) 

◮ Laufzeitumgebung 

standardisiert als Dienste 


Sprachtransparenz: Umsetzung 


• Interface Definition Language (IDL) oder Common Type System (CTS) 

◮ Sprachunabhängiges Typsystem 

◮ Obermenge gängiger Sprachen 

◮ Beschreibt Daten und Schnittstellen von Komponenten 

• Standardisierte Sprachbindungen (language bindings) 

◮ Umsetzung von IDL-Konzepten mit Sprachmitteln 

◮ Werkzeug: sprachspezifische IDL-Übersetzer 

• Vorgehen zum Bau einer Komponente: 

◮ Beschreibe Schnittstellen in IDL 

◮ Erzeuge Gerüst in gewünschter Sprache mit IDL-Übersetzer 

◮ Fülle Gerüst mit Implementierung

Sprachtransparenz: CORBA IDL 


Interface Definition Language 

Typen 

Typen 

Referenz- 

Referenz- 

Objekte 

Objekte 

Objekte 

Objekte 

Wertobjekte 

Wertobjekte 

Nicht-Objekte 

Nicht-Objekte 

Basistypen 

Basistypen 

Konstruktoren 

Konstruktoren 

Any 

Any 

Bool 

Bool 

Enum 

Enum 

Ints (short,..) 

Ints (short,..) 

Reals Typen (float..) 

Reals Typen (float..) 

Char, string, 

Char, string, 

octet 

octet 

Struct 

Struct 

Sequence 

Sequence 

Union 

Union 

Array 

Array 

Dr. Welf Löwe und Markus Noga 14

Sprachtransparenz: Sprachbindung 

• Bijektive Abbildung: IDL ↔ spezielles Typsystem 

• Vorgehen: Strukturelle Induktion 

◮ Definiere Abbildung für alle primitiven Typen 

◮ Definiere Abbildung für alle Typkonstruktoren 

◮ Fertig 

• Leistet Transparenz von 

◮ byte order 

◮ Wortbreiten 

◮ Speicherlayout 

◮ Speicherverwaltung 

◮ Referenzen 

• Wo nötig Anpasser erzeugen (Kopien minimieren) 


Sprachtransparenz: .NET Common Type System 


Ortstransparenz: Ziel 

• Ein Komponentensystem ist ortstransparent, wenn für die Verwendung 

einer Komponente belanglos ist, wo sie sich befindet. 

• Problem: Heterogenität verteilter Systeme 

◮ Werte weitgehend unproblematisch 

◮ Gültigkeitsbereiche von Referenzen 

Thread / Prozeß, 

Rechner 

Kommunikationspartner 

Netz 

Zeitschranken (Speicherbereinigung, garbage collection) 

◮ Zugriffsarten auf Referenzen 

Speicherzugriff auf Felder 

Lokale Aufrufe 

Fernaufrufe 


Ortstransparenz: Ansatz 


• Weltweit eindeutige Referenzen (GUUID, URI, etc.) 

◮ Z.B. Rechneradresse + lokale Referenz 

◮ Umsetzungstabelle für lokale Referenzen 

Keine lokale Freigabe extern bekannter Komponenten 

Konsistente Änderung lokaler Adressen extern unsichtbar 

• Fernzugriff über transparente Stellvertreter (Proxies) 

◮ Implementiert alle Schnittstellen der Komponente 

◮ Aufrufe an Stellvertreter stets lokal 

◮ Weitergeleitet an Komponente durch Fernaufrufe 

Daher: Feldzugriffe nur über Zugriffsfunktionen 

Rechner 1 Rechner 2 

Komponente 

Objekt 

? 

Komponente 

Skelett 

RPC 

Stell− 

vertreter 

Konnektor

Ortstransparenz: Umsetzung (1) 

• Erzeuge Stellvertreter aus IDL 

◮ stub: eigentlicher Stellvertreter 

Ablauf IDL-Codegenerierung 

Leitet lokale Aufrufe als Byteströme über das Netz 

◮ skeleton: macht Komponente für Fernaufrufe zugänglich 

Dekodiert Byteströme und setzt sie in lokale Aufrufe um 

IDL 

IDL 

Interface 

Interface 

IDL- 

IDL- 

Compiler 

Compiler 

Server 

Server 

Implementation 


Server 

Server 

Skeleton 

Skeleton 

Client 

Client 

Stub 

Stub 

Client 

Client 




Repository 

Compiler 

Compiler 

Objektadapter/ 

Objektadapter/ 

BOA 

BOA 

Server 

Server 

Client 

Client 

Dr. Welf Löwe und Markus Noga 15 


Ortstransparenz: Umsetzung (2) 


• Komponentenbehälter: Zentraler Eintrittspunkt (pro Rechner) 

◮ Allgemeine Infrastruktur für Fernaufrufe 

Kommunikationsprotokoll 

Authentifizierung (wer ist X?) 

Autorisierung (was darf X?) 

Lebenszyklus von Komponenten 

Elementare Dienste 

• Weiterleitung von Aufrufen: 

Local 

Remote 

Client XStub 

Container Container 

XSkeleton 

X

Ortstransparenz: Statische Methodenaufrufe 

• Methoden der Teilnehmer sind statisch bekannt, dynamisch nur 

Verbindungsaufbau durch Anmeldung erforderlich. 

◮ Aufruf durch Stummel und Skelette, 

◮ Keine Suche nach Diensten (in der Ablage), 

◮ Keine Suche nach Dienstobjekten, 

◮ Schnell 

• Statische Typprüfung durch Übersetzer möglich 

• Da der Aufruf an die Skelette durch den Objekt-Adapter geht, erscheint 

dem Klienten das Dienstobjekt durchgängig lebendig (transparentes 

Leben) 


Ortstransparenz: Dynamischer Aufruf (Request Broking) 

• Dynamischer Aufruf (dynamische Abfrage) 

◮ Komponenten dynamisch ausgetauscht oder nachträglich eingebracht 

◮ Neuübersetzung entfällt 

◮ Beispiel: Plugins für Browser, Zeichenprogramme etc. 

• Beschreibung der Komponentensemantik zur Suche 

◮ Object Interface 

◮ Informationen 

Metadaten (beschreibende Daten) 

Schnittstellendaten 

Verzeichnisse von Komponenten (interface repository , 

implementation repository ) 

• Such-Vermittler 


Ortstransparenz: Ermitteln von Interaktionspartnern 


• Finden von Schnittstellen: Schnittstellenablage. Verwaltung der 

registrierten Schnittstellen 

• Finden von Objekten: Objektablage. Eine Schnittstelle kann von 

verschiedenen Objekten realisiert sein, finde eines davon. 

• Dienste: 

◮ Namensauflösung: Namensdienst 

◮ Vermittler (Makler, Trader ) 

◮ Persistenz (Objekte aus Datenbank/von Platte holen) 

◮ Reflexion (Schnittstellen/Eigenschaften ermitteln) 

• Dienste bilden die Grundfunktionalität des Laufzeitsystems. Sie stellen die 

von Komponenten allgemein benötigte Funktionalität bereit und sind 

selbst Komponenten. 

• Motivation 

◮ Standardisierung 

◮ Wiederverwendung

Ortstransparenz: Namensauflösung — Namensdienst 


• Henne-Ei-Problem: 

◮ Woher kennt eine Komponente andere Komponenten? 

◮ Durch vom Aufrufer übergebene Referenzen. 

◮ Woher kennt der Aufrufer die Komponente? 

• Lösung 

◮ Führe (menschenlesbare) Namen für Komponenten ein 

◮ Stelle Dienst zur Namensauflösung bereit 

Bindet Namen an Komponenten 

Namen sind keine Komponenten (Corba-Jargon: Pseudoobjekte) 

Bindung erfolgt in einem Namensraum (scope, naming context) 

Auffinden des Namensdienstes ist Behälterfunktion 

Komponenten registrieren sich mit Name und Referenz 

Auffinden weiterer Komponenten über Namen 

Component 

NameService 

+resolve(in name : string(idl)) : Component 

+register(in comp : Component, in name : string(idl)) 

X 

Container 

+getNameService() : Component

Ortstransparenz — Namensdienst: Ablauf 


Systemabhängiger 

Name 

Erzeuge Name 

Suche / Erzeuge 

Namensraum 

Corba-Name 

Corba- 

Namensraum 

Binde 

Komponente 

(Corba-Objekt) 

Suche Name

Ortstransparenz: Vermittler/Makler 

• Erweitere das Auffindungsproblem: 

◮ Name unbekannt 

◮ Eigenschaften bekannt 

• Lösung 

◮ Stelle Dienst zur Vermittlung bereit 

Auffinden des Vermittlers über Namensdienst 

Komponenten registrieren sich mit Eigenschaften und Referenz 

Auffinden weiterer Komponenten über Vermittler 

◮ Standardisiere Eigenschaften (Terminologie, Ontologie) 

Funktionale Eigenschaften: Domänenmodell 

Nichtfunktionale Eigenschaften: Dienstgüte, ... 


Ortstransparenz — Makler: Ablauf 


Geschäftsprozessdienste: Makler 

Makler handeln mit 

Diensten (services, 

service types) 

Makler 

Vermittlermuster 

Exportiere 

Funktionalität 

Importiere 

Funktionalität 

Dienst 

Interagiere 

Kunde 


Ortstransparenz — Makler: Dienstangebote 


• Dienstangebot: Paar aus eindeutiger Referenz und Eigenschaften 

• Eigenschaften 

◮ von Maklern genutzt für Anfragen nach Diensten 

◮ Dynamische Eigenschaften (!) 

• Zum Vergleich spezielle Anfragesprache 

(standard constraint language) 

◮ boolesche Ausdrücke über Eigenschaften 

◮ numerische und Stringvergleiche 

• Findet ein Makler keinen passenden Dienst 

◮ kann er Nachbarn beauftragen (Entwurfsmuster Zuständigkeitskette, 

chain of responsibility ) 

◮ Dazu ist ein Graph aus Maklern aufgebaut 

◮ Filtern beim Weitergeben der Dienstsuchanfrage

Ortstransparenz — Maklergraph: Dienst-Hüpfen (hopping) 


Dienst-Hüpfen (hopping) 

Makler 1 

Fluß der 

Eigenschaften 

der Dienstanfrage 

Angebote der Makler 

Policies, die die Werte 

der Eigenschaften der 

Dienstanfrage verändern 

Makler 2 

Makler 4 

Makler 3 


Ortstransparenz — Makler: Schnittstellen 

• Schnittstellen 

◮ Lookup (Anfragen stellen) 

◮ Offer Iterator 

◮ Register (zum Export und Zurückziehen von Diensten) 

◮ Link (Aufbau des Maklernetzes) 

◮ Proxy (Stellvertreter-Objekte, die Makler vertreten) 

Stellvertretung für andere Makler 

Erlaubt Kapselung von Altsystemen 

◮ Admin (Eigenschaften von Dienste) 

Lookup.Query( 

in ServiceTypeName,in Constraint, in PolicySeq, 

in SpecifiedProps, in howMany, 

out OfferSequence, out offerIterator 

) 


Ortstransparenz — Makler: Maklerarten 


Maklerarten 

Lookup 

Lookup 

Register 

LookupRegister Admin 

Anfragemakler 

(query trader) 

Einfacher 

Makler 

(simple trader) 

Selbständiger 

Makler 

(standalone 

trader) 

Lookup Register Admin 



Sozialer Makler 

(linked trader) 

Stellvertreter 

Makler 

(proxy trader) 

Komplett- 

Makler 

(full-service 

trader) 

Link 

Proxy 

Link 

Proxy 


Ortstansparenz: Persistenz 

• Verändere das Auffindungsproblem: 

◮ Eigenschaften bekannt 

◮ Instanz möglicherweise passiviert (Datenbank) 

• Lösung 

◮ Stelle Dienst zur Vermittlung bereit 

Auffinden der Instanz über Schlüssel 

Bei Bedarf aktivieren (Objekt erzeugen) 

Bei Nutzungsende erneut passivieren 

◮ Nutzen 

Alle Objekte erscheinen permanent lebendig 

Handhabung des Objektlebenszyklus vereinfacht 

• Alternative 

◮ Auch denkbar: verallgemeinerte Referenzen 

◮ Aber: erfordert Änderungen der Basisplattform 


Ortstransparenz: Reflexion 

• Mit Reflexion können die Schnittstellen einer (unbekannten) Komponente 

zur Laufzeit ermittelt und verwendet werden. 

• Motivation 

◮ Automatische Konfiguration 

◮ Einsatz in Entwicklungsumgebungen 

• Probleme 

◮ Inkompatibilitäten: bereits duch Sprachtransparenz ausgeräumt 

◮ Noch offen: Standardisierter Zugriff auf Schnittstellen 

• Ansatz 

◮ IDL ist bereits standardisiert 

◮ Standardisiere Laufzeitrepräsentation 

◮ Standardisiere Zugriff darauf 

• Umsetzung 

◮ Beschreibe abstrakten Syntaxbaum für IDL in IDL 

◮ Mache Definitionstabelle im Behälter zugänglich 


Reflexion: Metadaten 


Metadaten 

Meta: griech. darüber, jenseits 

Metadaten: Daten über Daten 

• µɛτα: griech. – Datenbeschreibung 

darüber, jenseits 

• Metadaten: – Modellierung Daten über Daten 

◮ Datenbeschreibung 

– Können reflexiv sein 

◮ Modellierung Reflektion: Programm greift auf 

◮ Können Metadaten reflexivzusein 

• Reflexion: Selbstmodifikation Programm greift (intercession) 

auf Metadaten kann Erkenntnisse zu nutzen 

• Selbstmodifikation kann 

Erkenntnisse nutzen 

Metadaten 

Metadaten 

Beschreiben 

Daten, 

Daten, 

Code 

Code 

Ändern 

Zugriff 

Metaebene 

(Konzeptebene) 

Realität 


Reflexion und Selbstmodifikation 


Reflexion: 

for all c in self.classes do 

generate_class_start(c); 

for all a in c.attributes do 

generate_attribute(a); 

done; 

generate_class_end(c); 

done; 

Selbstmodifikation: 

for all c in self.classes do 

helpClass = makeClass(c.name+"help"); 

for all a in c.attributes do 

helpClass.addAttribute(copyAttribute(a)); 

done; 

self.addClass(helpClass); 

done; 

Reflexion bietet Zugriff auf Typinformationen 

für ein Programm. Es wird 

dabei nicht geändert. 

Selbstmodifikation ändert das laufende Programm 

anhand reflektierter Information.


Reflexion: Ausspähen (Introspection) 

Ausspähen (Introspection) 

• falscher Sprachgebrauch: gemeint ist inspection 

• Spezialfall der Reflexion: über fremde Komponenten 

• Bestimmen Bestimmen semantikbehafteter semantikbehafteter Eigenschaften Eigenschaften 

• wichtig für den Web-Komponenten-Supermarkt 

Spezialfall der Reflektion: über fremde Komponenten 

Wichtig für den Web-Komponenten-Supermarkt. 

Metadaten 

Metadaten 

Metaebene 

(Konzeptebene) 

Zugriff 

Beschreiben 

Realität 

Daten, 

Daten, 

Code 

Code 

Daten, 

Daten, 

Code 

Code 

Ändern

Ortstransparenz: Objektverwaltung 

• Client/Server-Ansatz: Objektlebenslebenszyklus 

◮ Client fragt nach einer Komponente: Server verwaltet 

Programmstücke/Komponenten: Eine Komponente (ein 

Programm/eine Implementierung/eine Klasse) ist bereit, wenn der 

Server die Fabrik zur Erzeugung von Instanzen der Komponente 

erzeugt hat. 

◮ Client fragt nach einer Komponenteninstanz: 

Objekt nicht auf Server vorhanden: Server verwendet Fabrik, um 

neues Objekt zu erzeugen. 

Objekt auf Server vorhanden: 

· Objekt im Speicher: Verwende dieses Objekt. 

· Objekt auf Platte: Lade und aktiviere das Objekt. 

◮ Server deaktiviert eine Komponenteninstanz → Nachricht an 

Objektverwalter 

◮ Server deaktiviert eine Komponente → Nachricht an 

Komponenten/-objektverwalter 


Ortstransparenz — Objektverwaltung Überblick (1) 


Ortstransparenz — Objektverwaltung Überblick (2) 


Ortstransparenz — Objektverwaltung: Serverseite 


Serverseite 

• Anfrage nach Komponente und dessen Instanz. 

• Instanz wird neu erzeugt. 

• Instanz und Komponente werden nach Verwendung deaktiviert. 

Server / Object Implementation 

impl_is_ 

ready 

object_is_ 

ready 

deactivate_ 

obj 

deactivate_ 

impl 

BOA 

IDL 

Skeleton 

ORB Kern 


Synchronisation und Transaktionsschutz 

• Synchronisation: Sperren 

◮ Einzelne oder Mengen von Sperren 

◮ Innerhalb von oder ohne Transaktionen 

• Transaktionen (Standard-Datenbanktechnik): 

◮ Einfache/Flache Transaktionen 

begin 

rollback 

commit (two-phase-commit) 

◮ Geschachtelte Transaktionen 

◮ Beispiele 

Bankkonten als Komponenten 

· Operationen Abheben, Einzahlen 

· Überweisung ist Transaktion über zwei Komponenten 

Webseiten 

· Bidirektionale Verweise 

· Wie erziele ich Konsistenz? 


Eigenschaftsdienst 


• Mechanismus für dynamische Erweiterungen 

• Eigenschaften (properties) sind Tupel von Strings (name, value) 

• Dienst verwaltet Eigenschaften von Komponenten 

komponente1: ("makelbar" , "ja") 

("kategorie", "geschäftsdienst") 

• Konzept bekannt: 

◮ assoziative Arrays 

◮ LISP property lists 

◮ Java property classes 

• Iteratoren für Eigenschaftswerte 

• Verfeinerung PropertySetDef 

◮ Definierte Semantik für: readonly, fixed_readonly, . . . 

• Schnittstelle: define_property, define_properties, get_property_value, 

get_properties, delete_property, . . .

Anpassungen: Komposition 


• Generische Komponenten ausprägen (mit Argumenten für generische 

Parameter) 

• Zusammensetzen von Komponenten laut Verträgen: 

◮ über Funktionen und Daten 

◮ über Kommunikation, Synchronisation und Protokolle 

◮ Problem der globalen Lebendigkeit? 

◮ Wie erreicht man nicht-funktionale Eigenschaften? 

• Mangelnde Passung erfordert Adaption der Komponenten: 

◮ Externe Adaption durch Umwickeln 

◮ Interne Adaption: 

Offenes Einsetzen 

Invasiver Austausch nicht-funktionaler Aspekte (z.B. 

Basiskommunikation tauschen, Synchronisation einfügen etc.)

Anpassungen: Paßfehler überbrücken 


• Datenformate konvertieren 

• Auflösen von Datenstrukturpaßfehlern [Jackson1975]: Gemeinsame 

kleinste gemeinsame Teilstruktur wählen. 

• Interaktionsmechanismen anpassen: Umwickeln oder invasiv modifizieren 

[Heuzeroth2004] 

• Antrieb invasiv anpassen: Programminversion 

[Jackson1975,Heuzeroth2004] 

• Aktivitätspaßfehler: Aktivitäten sequentialisieren 

• Protokollpaßfehler: Protokollanpassung durch Adapter [Yellin und 

Strom1994]

Zusammenfassung der Aufgaben 

Gesamtaufgabe: Zusammenspiel von Komponenten in einer heterogenen Welt 

organisieren 

• Sprachtransparenz 

• Ortstransparenz 

◮ eindeutige Referenzen 

◮ Stellvertreter 

◮ Dienste zum Auffinden/Vermitteln: Namensdienste, Makler, Persistenz, 

Behälterdienste, DB-Zugriff, Reflexion 

• Anpassungen

Software aus Komponenten - IPD Goos

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?