\documentstyle[german,twocolumn]{article}
\input{trendsstyle_v2.tex}
\begin{document}
\setlength{\topmargin}{-2.0cm}
\setlength{\textheight}{25.0cm}

\title{Buchbesprechung\\
 \glqq Object-Oriented Software-Composition\grqq{}\\
 von Oscar Nierstrasz und Dennis Tsichritzis}

\author{Alexander Fronk\\
  Lehrstuhl f"ur Software-Technologie\\
  Universit"at Dortmund\\
  e-mail: fronk@ls10.informatik.uni-dortmund.de}
%\date{}
\maketitle

%----------------------------------------------------------------
\baselineskip12pt

Neben einer Einleitung in die Thematik besteht das Buch aus vier
Teilen, die sich jeweils verschiedenen Anwendungsbereichen widmen:
\emph{Nebenl"aufigkeit und Verteilung, Spezifikation und Komposition,
  Software-Informationsmanagement, Frameworks und Applikationen}.
Jeder Teil besteht seinerseits aus jeweils zwei bis drei Artikeln. Der
Leser erwartet -- glaubt er dem Titel -- "uber Komponenten und ihre
Komposition informiert zu werden und wie sich diese Begriffe in den
genannten Bereichen umsetzen lassen. Die Artikel sind
Forschungsberichte, die schnell in die entsprechenden Spezialgebiete
abdriften. Das zeigt zwar die Tragweite der Komponenten-orientierten
Software-Komposition, der Leser verliert jedoch schnell den
Zusammenhang zum postulierten Thema.

Betrachtet man die Artikel n"aher, so stellt man fest, da"s sie eher
die Notwendigkeit motivieren, vom (engen) objekt-orientierten
Begriffsdenken auf einen flexibleren und skalierbaren
Komponentenbegriff zu kommen, um insb.  die Wiederverwendung von
Software zu verbessern. Der Leser stellt ebenfalls fest -- und die
Autoren weisen in ihrer Einleitung darauf hin --, da"s der
Komponentenbegriff je nach Anwendungsgebiet definiert werden (k"onnen)
mu"s.  Gleichzeitig geben sie aber eine Definition an (\glqq static
abstraction with plugs\grqq{}), die lediglich eine Abstraktion des
Komponentenbegriffs mit Eigenschaften bedeutet und erst mit Leben
gef"ullt werden mu"s. Es macht wenig Sinn, eine solche generische
Begriffsbildung vorzunehmen. Die technologisch und methodisch
schwierige Umsetzung des Komponentenbegriffs wird durch diese
Verallgemeinerung keineswegs vereinfacht. Vorschl"age zur
Komponentenbildung, die auf Erfahrungen beruhen (wie sie Vicki de Mey
in ihrem Artikel gibt), sind sicherlich hilfreicher.

Die Artikel im einzelnen:

~\\
Die beiden Artikel im Teil II, \emph{Nebenl"aufigkeit und Verteilung},
beschreiben bestehende Probleme und L"osungsans"atze des
objekt-orientierten Paradigmas mit dieser Thematik.

In seinem Beitrag \emph{Nebenl"aufigkeit in objekt-orientierten
Programmiersprachen} zeigt Michael Papathomas, da"s verschiedene
Ans"atze existieren, Nebenl"aufigkeit in OO-Sprachen zu
integrieren. Er wei"st darauf hin, da"s die Entwicklung solcher
Sprachen zwar der Wiederverwendung von Software(-Komponenten) in
gr"o"serem Stil dient und da"s dieses Ziel in die Sprachentwicklung
einflie"sen mu"s. Dabei spricht er jedoch stets von
Objekten. Komponente also gleich Objekt?

Mit \emph{Interpretation of Object-Oriented Applications} besch"aftigt
sich Dimitri Konstantas. Er stellt den wichtigen Vorteil der
Wiederverwendung von Software-Moduln heraus, den objekt-orientiertes
Design und entsprechende Entwicklungsmethoden bieten. Wegen ihrer
Vielzahl und der damit verbundenen Orthogonalit"at werden M"oglichkeiten
gesucht, Interoperabilit"at von Modulen aus verschiedenen
Sprachen zu unterst"utzen. Modul gleich Objekt gleich
Komponente?

~\\
Im Teil III, \emph{Spezifikation und Komposition}, werden theoretische
Aspekte der Thematik beleuchtet.

Oscar Nierstrasz zeigt in \emph{Regular Types for Active Objects}
einen Forschungsaspekt im Bereich der Typtheorie objekt-orientierter
Programmiersprachen auf, der im Gegensatz zu anderen Ans"atzen
Nebenl"aufigkeit und Aspekte der Aufgabendelegation und Kommunikation
zwischen zustandsbasierten Objekten behandelt. Dabei geht er
beispielsweise der Frage nach, welche Dienste ein Objekt in welchem
Zustand anbietet.

Der Artikel \emph{A Temporal Perspective of Composite Objects}
besch"aftigt Constantin Arapis mit der Frage, welche M"oglichkeiten
f"ur das System-Design existieren, die zeitliche Reihenfolge von
Nachrichten von und an Objekte zu beschreibe; den Leser hingegen
besch"aftigt der Artikel mit der Suche nach der Auswirkung auf
Komponenten-orientiertes Denken. Da hilft auch sein Ansatz kaum
weiter, die Problematik f"ur kooperierende Objekte in \glqq
part-of\grqq{}-Beziehung mit temporaler Aussagenlogik in den Griff zu
bekommen. Arapis definiert die \glqq temporale Komponente\grqq{} einer
oo-Design-Methode als die Sammlung von Begriffen und Konzepten zur
Beschreibung temporaler Aspekte des Objektverhaltens. Komponenten
einer Klasse sind Instanzen von Klassen, die in der umgebenden Klasse
verwendet werden. Die Komposition betrachtet das Zusammenspiel, die
Kommunikation dieser Objekte.

Das Kompatibilit"atsproblem versucht Laurent Dami in \emph{The
  $\lambda_N$-Calculus} durch ein Interaktionsprotokoll zwischen
Software-Komponenten zu l"osen . Durch die Erweiterung des
$\lambda$-Kalk"uls tragen Subtypisierungen dazu bei, Kompatibilit"at
modellieren zu k"onnen. Anbei wird eine Erweiterung zur Erfassung
nebenl"aufiger Konstrukte vorgeschlagen. Die erstgenannte Erweiterung
erm"oglicht es, Objekte im $\lambda$-Kalk"ul codieren zu k"onnen. Auch
hier wird der Leser im Unklaren dar"uber gelesen, wie eine Komponente
zu erkennen und ihre Komposition zu verstehen ist.

~\\
Teil IV, \emph{Software Information Management}, gibt Einblick in die
Problematik der Konzepte und Tools zur Wiederverwendung von Software.

Software-Repositories als Schl"usselkomponente bei der Erstellung von
Software durch Wiederverwendung werden von Panos Constantopoulos und
Martin D"orr in ihrem Artikel \emph{Component Classification in the
  Software Information Base} diskutiert. Ihrer Meinung nach
unterst"utzen objekt-orientierte Sprachen die Entwicklung
wiederverwendbarer Klassen, die hier als Komponenten bezeichnet
werden. Die Autoren stellen ein Repositiory-System vor, mit dessen
Hilfe entstehende Probleme wie Repr"asentation der Klassen,
Darstellung struktureller und beschreibender Information, der
Beziehung zwischen den Klassen, die Auswahl und das Verst"andnis der
Klassen sowie ihre Evolution gel"ost werden k"onnen. Komposition wird
hier als Akt der Wiederverwendung verstanden.

Die Handhabung der Klassenevolution in objekt-orientierten Systemen
betrachtet Eduardo Casais etwas genauer und schl"agt eine ad"aquate
Methode vor, die g"angigen Probleme der objekt-orientierten
Entwicklung zu l"osen. Auch hier nimmt das Design und die Entwicklung
von Software-Komponenten (aber was sind solche) eine wichtige Rolle f"ur
das Ziel der Wiederverwendung ein.

Ein Tool zur grafischen Repr"asentation von Objektbeziehungen sowie
die dazu notwendigen Voraussetzungen beschreibt Xavier Pintado in
seinem Artikel "uber den \emph{Affinity Browser}. Damit soll ein
Beitrag zur Visualierung, also auch zum besseren Verst"andnis von
Klassen, ihrer Hierarchien, Interaktionen von Komponenten etc.
geleistet werden. Die Wiederverwendung, Fehlerbeseitigung, das Tuning
etc. f"ur gro"se objekt-orientierte Systeme soll damit unterst"utzt werden.

~\\
Das Buch schlie"st in Teil V, \emph{Frameworks and Applikations}, mit
Beispielen zur Umsetzung der Erkenntnisse der ersten vier Teile und
bildet mit Teil I einen Rahmen um einige wesentliche Aspekte der
Software-Technologie.

Mit visueller Komposition von Software-\linebreak Applikationen f"uhrt Vicki de
Mey in den letzten Teil des Buches ein. Sie stellt ein Framework und
einen darauf aufbauenden Prototypen zur visuellen Komposition offener
Applikationen aus schnittstellen-kompatiblen Software-Komponenten vor.
Dabei werden interaktiv grafisch repr"asentierte Software-Komponenten
zu lauff"ahigen Anwendungen zusammengestellt. de Mey zeigt hier eine
konkrete Anwendung im Multimedia-Bereich auf, die die Ideen der
komponenten-orientierten Software-Entwicklung umsetzt. Abschlie"send
gibt sie Vorschl"age zur Umsetzung der Begriffe Komponente,
Komposition und Visualisierung in konkrete software-technische Einheiten.

Simon Gibbs betrachtet den Nutzen der objekt-orientierten Technologie
im Bereich der Multimedia-Programmierung. Er betrachtet die Begriffe
der Komponente und ihrer Komposition f"ur diesen Bereich und stellt
ein Multimedia-Framework sowie eine darauf basierende Anwendung vor,
die diese Begriffe umsetzt. Eine Komponente ist f"ur Gibbs die
Kapselung von Soft- und Hardwareprozessen, die Medienstr"ome
produzieren, konsumieren oder transformieren. Ihre Schnittstellen
dienen auch hier der Kommunikation. Komposition bedeutet f"ur ihn das
Zusammensetzen schnittstellen-kompatibler Komponenten, soda"s ein
Netzwerk aus erzeugenden, transformierenden und verbrauchenden
Komponenten eine Anwendung bildet.

Im letzten Artikel \emph{Gluons and the Cooperation between Software
  Components} zeigt Xavier Pintado einen Ansatz zur Standardisierung
von Regeln bzgl. der Interaktion bzw. dem Erkennen von
Interaktionsmustern von Komponenten, soda"s die
Interaktionsprotokolle, die in speziellen, Gluonen genannte Objekte
gekapselt werden, wiederverwendet werden k"onnen und die Kooperation
von Software-Komponenten dadurch standardisiert werden. Das
vorgestellte Entwicklungs-Framework f"ur den speziellen Bereich der
Finanzsoftware erm"oglicht die dynamische Komposition, d.h. neue
Komponenten k"onnen in ein bestehendes System integriert und zur
Laufzeit komponiert werden.







~\\
\textbf{Fazit}: Die Artikel verdeutlichen einige Probleme des
objekt-orientierten Paradigmas in verschiedenen Bereichen. Ein je nach
Kontext -- wie Teil V zeigt -- defnierter Komponentenbegriff ist nur
thematisch sehr begrenzt f"ur Wiederverwendung geeignet. Das Lesen des
Buches gibt aber einen guten Einblick in den L"osungsversuch, einen
kontextbezogenen Komponentenbegriff zur Software-Komposition
heranzuziehen.

%----------------------------------------------------------------
~\\
\texttt{Oscar Nierstrasz, Dennis Tsichritzis}\\
\emph{Object-Oriented Software-Composition}\\
\texttt{Prentice Hall, 1995}\\

%----------------------------------------------------------------

\end{document}

