Java Reference
In-Depth Information
!
Arbeitskreis „Komponentenorientierte betriebliche Anwendungssysteme“ der Gesell-
scha für Informatik, 2002: Eine Komponente besteht aus verschiedenartigen (So ware-)
Artefakten. Sie ist wiederverwendbar, abgeschlossen und vermarktbar, stellt Dienste über
wohldefi nierte Schnittstellen zur Verfügung, verbirgt ihre Realisierung und kann in Kom-
bination mit anderen Komponenten eingesetzt werden, die zur Zeit der Entwicklung nicht
unbedingt vorhersehbar ist.
!
Object Management Group, 2005: The component is a modular unit with well defi ned
interfaces that is replaceable within its environment. . . . It has one or more provided and
required interfaces, and its internals are hidden and inaccessible other than as provided
by its interfaces.
!
Handbuch der So ware-Architektur, 2009: Komponenten sind modulare Teile eines Sys-
tems, die ihren Inhalt und somit komplexes Verhalten transparent kapseln und in ihrer
Umgebung als austauschbare Einheiten mit klar defi nierten Schnittstellen au auchen.
Die Liste dieser Zitate soll Ihnen zeigen, wie unterschiedlich der Komponentenbegriff defi -
niert wurde, wenngleich es auch einige Charakterisierungen gibt, die häufi ger vorkommen.
Ich habe keine Defi nition gefunden, weder unter den oben aufgeführten noch unter den
zahlreichen anderen nicht wiedergegebenen, die ich unverä ndert für dieses Buch überneh-
men will, da in keiner Defi nition die für dieses Buch passende Menge an charakteristischen
Merkmalen ausgewä hlt wurde. Ich halte zudem einige der angegebenen Eigenscha en
nicht für wesentlich für ein Komponentensystem. So ist in den Defi nitionen die Rede, dass
Komponenten „contractually specifi ed interfaces“ bzw. „wohldefi nierte Schnittstellen“ oder
„klar defi nierte Schnittstellen“ besitzen müssen. Abgesehen davon, dass für mich nicht
deutlich wird, was darunter zu verstehen sein soll, wird im dritten Teil des Buches deutlich
werden, dass Schnittstellen keine wesentliche Eigenscha von Komponenten sind. Auch
wenn die Wichtigkeit von Schnittstellen immer wieder betont wird, gibt es eine ganze Reihe
von Java-Komponentensystemen, deren Komponenten keine Schnittstellen implementieren
müssen (die Beispielkomponenten des prototypischen Komponenten-Frameworks aus dem
vorigen Kapitel, aber z. B. auch Java Beans und Servlets). Mit Komponenten wird o auch
die Möglichkeit der leichten Wiederverwendbarkeit verbunden, was wohl bedeuten soll,
dass die So ware einer Komponente in ganz unterschiedlichen Anwendungen eingesetzt
werden kann. Wenn auch Wiederverwendung die Grundidee war, als der Begriff Kompo-
nente in den 60er Jahren in die So ware-Welt eingeführt wurde, so steht er nach meiner
Einschätzung bei den meisten Java-Komponentensystemen nicht im Vordergrund. Wenn ich
z. B. einige Eclipse-Plugins betrachte, die ich sehr wohl als Komponenten einschätze, dann
sind diese in einer Eclipse-Umgebung nur für den vorgesehene Einsatz brauchbar. Solche
Plugins werden niemals in einem anderen Kontext verwendet. Bei Eclipse-Plugins geht es
vielmehr um eine spezifi sche Erweiterung der Eclipse-Plattform eines individuellen Benut-
zers. Auch für ein Servlet oder eine EJB-Komponente ist eine Wiederverwendung in einer
anderen Anwendung nicht unbedingt typisch. Weitere in den Zitaten erwähnte Merkmale
von Komponenten, die ich nicht für wesentlich halte, sind, dass sie vermarktbar sein sollen
oder dass eine „composition by third parties“ erfolgen soll. Ein zusätzlicher Mangel einiger
der oben angeführten Aussagen über Komponenten ist ihre Unschärfe. Es werden teilweise
Begriff e verwendet, die Raum für weite Interpretationen geben. So wird davon gesprochen,
dass Komponenten abgeschlossen sind oder eine „more or less opaque boundary“ haben,
was immer das auch bedeuten mag. Ebenso weit interpretierbar ist die Angabe, dass Kom-
ponenten „komplexes Verhalten transparent kapseln“.
