Data - Goethe-Universität Frankfurt

Wiederverwendung von Softwareelementen: Das Java Repository
Seite 1 von 6
Wiederverwendung von Software-Elementen: Das Java Repository
FACHTAGUNG SOFTWARE-MANAGEMENT '97: 29. - 31. Oktober 1997, München
Peter Buxmann, Frank Rose und Wolfgang König
Institut für Wirtschaftsinformatik
Johann Wolfgang Goethe-Universität
Frankfurt am Main
Tel. 069/7982-3318
Fax. 069/7982-8585
E-mail: { [email protected], [email protected], [email protected])
Zusammenfassung
Die weltweite Entwicklung von Java-Applets und -Klassen eröffnet ein enormes Potential für die Wiederverwendung
dieser Software-Elemente mit dem Internet als einer großen "Klassenbibliothek". Das Hauptproblem der Nutzung von
Klassenbibliotheken besteht häufig darin, die richtigen Klassen für bestimmte Problemstellungen zu finden. Zur
Unterstützung der Suche, Evaluation und anschlie ßendem Austausch von Java -Elementen wurde das Java Repository
(http://java.wiwi.uni -frankfurt.de) entwickelt, das in diesem Beitrag vor dem Hintergrund der Wiederverwendung
vorgestellt wird.
Abstract
The emergence of the programming language Java offers new opportunities for the reuse of Java software elements. The
Internet can serve as a class library. One main problem that arises in the use of software repositories is usually the search
for an appropriate class or problem solution. The Java Repository (http://java.wiwi.uni -frankfurt.de) has been developed
in order to support search, evaluation, and the exchange of Java software elements over the Internet.
1. Einleitung
Mit der Entwicklung der Programmiersprache Java [Gosling 95] wurde das Internet um die M öglichkeit erweitert,
weltweit Anwendungen und Dienste zur Verfügung zu stellen. Seit ihrer Einführung Mitte 1995 nahm die Verbreitung
der Sprache ständig zu. Es entstehen weltweit User-Gruppen, und Gremien beschäftigen sich mit der Standardisierung
der Sprache. W ährend Java zu Beginn überwiegend zur graphischen Gestaltung von Webseiten genutzt wurde, so hat
sich inzwischen die Situation grundlegend verändert. Unternehmen entwickeln mit Java Individual- und
Standardanwendungen, prominente Beispiele sind die Software für den Internet-Auftritt der Bank 24 sowie das OfficePaket der Firma Corel.
Die weltweite Entwicklung von Java-Applets und -Klassen (Java -Elemente) und deren Verfügbarkeit im World Wide
Web eröffnet ein enormes Potential für die Wiederverwendung dieser Elemente. Das Internet kann hierbei als eine große
"Klassenbibliothek" angesehen werden. Das Hauptproblem der Nutzung von Klassenbibliotheken besteht meist darin, die
richtigen Klassen für bestimmte Problemstellungen zu finden. Zur Unterstützung der Suche, Evaluation und
anschlie ßendem Austausch von Java -Elementen wurde das Java Repository (http://java.wiwi.uni-frankfurt.de) entwickelt.
Das Ziel dieses Beitrages besteht darin, diesen Intermediär für Java-Elemente vorzustellen sowie Möglichkeiten und
Grenzen der Wiederverwendung vor dem Hintergrund der "Klassenbibliothek Internet" zu diskutieren.
Im zweiten Kapitel werden zunächst Grundlagen der Wiederverwendung mit einem Schwerpunkt auf Java -Elementen
dargestellt. Gegenstand des dritten Kapitels ist die Vorstellung des Java Repository. Im vierten Kapitel werden
schließlich offene Probleme und Fragen behandelt.
2. Wiederverwendung von Java Software-Elementen
file://C:\Download\java-papers\JavaRep\html\papers\SwMgmtMuOkt97.htm
23.08.2002
Wiederverwendung von Softwareelementen: Das Java Repository
Seite 2 von 6
Unter Wirtschaftlichkeitsaspekten ist die Wiederverwendung von Software -Elementen seit langer Zeit eine wichtige
Anforderung an die Software -Entwicklung. Man versteht darunter allgemein das Benutzen bereits fr üher erstellter
Software-Elemente für die Entwicklung neuer Software [Endres 88, 86]. Die Vorteile der Wiederverwendung liegen auf
der Hand, so brauchen bereits verfügbare Software-Elemente nicht neu entwickelt und getestet werden [Sneed 87, 85-86]
("das Rad nicht jedes Mal neu erfinden"). Ermöglicht wird diese Wiederverwendung dadurch, daß
l
l
l
Software keinem Verschleiß unterliegt,
die Kopierkosten vernachläßigbar gering sind und
viele der durch Software gelösten Problemstellungen sich auf die gleichen Lösungsstrategien zurückführen lassen
[Heß 93, 8-9].
Häufig wird das Thema der Wiederverwendung in engem Zusammenhang mit objektorientierter Programmierung
genannt. Problematisch wird diese Argumentationskette immer dann, wenn eine direkte Kausalität zwischen
Objektorientierung und Wiederverwendbarkeit hergestellt wird. So erwecken manche Autoren den Eindruck, als wenn
gerade die Objektorientierung es erst ermöglich hätte, daß Software-Elemente in anderen Anwendungen
wiederverwendet werden. Diese Argumentation greift zu kurz, da bereits in der traditionellen Programmierung
Bibliotheken existiert haben, die wiederverwendbare Funktionen enthielten.
Ein wesentlicher Vorteil des objektorientierten Konzeptes in bezug auf die Wiederverwendung besteht in den
Möglichkeiten der Vererbung, des Polymorphismus sowie der Verkapselung von Daten und Methoden [Meyer 87].
Dadurch läß t sich ein höherer Abstraktionsgrad und eine eindeutigere Trennung von Nutzung und Implementierung der
Klassen erreichen. Insbesondere in Verbindung mit der M öglichkeit zur Modifikation einzelner Teilfunktionalitäten auf
Subklassenebene sind Objektklassen einfacher ohne umfangreiche Code -Redundanzen wiederzuverwenden [König/Wolf
1993].
Diese M öglichkeiten der Wiederverwendung stehen natürlich auch Java-Elementen offen. Von noch größ erer Bedeutung
ist jedoch die weltweite Verfügbarkeit von Problemlösungen im World Wide Web. Mittlerweile finden sich im World
Wide Web Informationen zu allen denkbaren Themengebieten, und die Anzahl der verfügbaren Informationen steigt
weiterhin exponentiell. Zukünftig wird es dort wahrscheinlich auch fast alle denkbaren kommerziellen Services geben
sowie - so unsere Vermutung - Java -Elemente zu einer Vielzahl von Anwendungen und Problemstellungen. Die
Ausnutzung dieses Potentials stellt eine große Chance und zugleich Herausforderung für die Zukunft dar und kann zu
einer grundlegenden Änderung der zuk ünftigen Softwareproduktion führen. Wie bei den meisten Bibliotheken, stellt sich
stets das Problem, den richtigen Softwarebaustein für eine gegebene Problemstellung zu finden. Im Internet wird dieses
Problem trotz leistungsfähiger Suchmaschinen vermutlich mit der Anzahl vorhandener Java -Problemlösungen sowie der
insgesamt wachsenden Menge an Informationen eher zu- als abnehmen. Als ein Service zur Unterstützung der Suche und
Auswahl von Problemlösungen wurde das Java Repository entwickelt.
3. Das Java Repository
Das Java Repository (http://java.wiwi.uni -frankfurt.de) sammelt und verbreitet Klassen und Applets, die über das World
Wide Web verfügbar sind, und stellt sie Nutzern zur Verfügung. Damit erfüllt das Java Repository die klassische
Intermediärsfunktion [Buxmann 97]. Hat ein solcher Intermediär einen vollkommenen Marktüberblick, d. h. kann er alle
relevanten am Markt verfügbaren Software-Elemente anbieten, so müssen die Nachfrager nur noch mit dem Intermediär
und nicht mehr mit allen Anbietern Kontakt aufnehmen.
Eine wesentliche Voraussetzung für eine systematische Wiederverwendung von Software-Elementen ist eine
Unterstützung bei der Suche nach geeigneten Bausteinen [Heß 93, 16-19]. Diese Suche wird im Java Repository durch
zwei Sichten auf die registrierten Einträge unterstützt: Die programmiertechnische Sicht fokussiert mit den verwendeten
Methoden und Techniken die Belange des Programmierers, die anwendungsbezogene Sicht ist demgegenüber stärker auf
den Anwender ausgerichtet. Das Browsen innerhalb jeder Sicht wird durch vielfältige Sortier- und Suchmöglichkeiten
unterstützt. Durch Schlagwortsuche wird zusätzlich ein direkter Zugriff auf entsprechende Java-Elemente ermöglicht.
file://C:\Download\java-papers\JavaRep\html\papers\SwMgmtMuOkt97.htm
23.08.2002
Wiederverwendung von Softwareelementen: Das Java Repository
Seite 3 von 6
Abb. 1: Suche im Java Repository über Kategorien und direkte Schlagwortsuche
Sind geeignete Java -Klassen oder Applets gefunden, so m üssen sie auf ihre Einsetzbarkeit in der konkreten
Problemstellung untersucht werden. Die vom Java Repository bereitgestellte Beschreibung der Ressourcen sowie das
Rating und die Kommentierung durch andere Anwender leisten einen Beitrag zur Beurteilung der Bausteine. Alle Nutzer
des Repository haben die M öglichkeit, registrierte Software -Elemente nach einem standardisierten Verfahren zu
bewerten und zu kommentieren. Die so gesammelten Informationen werden zusammen mit der Software präsentiert und
können dem Nachfrager bei der Auswahl geeigneter Software -Elemente Hilfestellung geben.
Ziel der Bewertungs- und Kommentarmöglichkeit ist zum einen, dem potentiellen Nutzer einer Software bereits vor
deren Einsatz oder Erwerb Anhaltspunkte über die Qualität zu geben. Kritisch ist dabei zu beurteilen, daß die
Bewertungen von allen Nutzern, gleich welcher Qualifikation oder Intention, abgegeben werden können und so leicht ein
nicht objektives Bild entstehen kann. Die Kommentierung und Weiterleitung der Kommentare an die Anbieter der im
Repository verfügbaren Ressourcen dagegen stellte sich als eine geeignete Möglichkeit heraus, den Kontakt zwischen
Anbietern und Nachfragern herzustellen und dem Programmierer wertvolle Hinweise für weitere Entwicklungen zu
geben.
file://C:\Download\java-papers\JavaRep\html\papers\SwMgmtMuOkt97.htm
23.08.2002
Wiederverwendung von Softwareelementen: Das Java Repository
Seite 4 von 6
Abb. 2: Darstellung der Bewertung und Kommentierung eines Applet im Java Repository
Das Java Repository wurde realisiert auf einer Sun Ultra Sparc 2, die Anwendung selbst wurde auf Basis einer OracleDatenbank mit Webserver entwickelt (Oracle RDBMS 7.3 mit Webserver 2.1, vgl. die Darstellung der technischen
Infrastruktur in Abbildung 3). In der Datenbank werden Informationen über den Autor, Adresse sowie zum Teil der
Quellcode der Java-Elemente verwaltet. Alle HTML -Seiten zur Navigation und Darstellung werden mit Hilfe von ca. 100
PL/SQL-Prozeduren dynamisch aus der Datenbank generiert.
Zur zukünftigen Unterstützung finanzieller Transaktionen wurde das Ecash-System der Mark-Twain-Bank
(http://www.marktwain.com) implementiert [Kalakota 96] [Lynch 96] [Wayner 96]. Hierbei tritt das Java Repository als
Intermediär zwischen Anbieter und Nachfrager von/nach Java-Elementen auf. Die Zahlungen werden dabei mit Hilfe von
Ecash vom Käufer über das Java Repository direkt an den Anbieter geleitet; dieser zusätzliche Service des Java Market
ist sowohl für Anbieter als auch Nachfrager kostenlos und optional.
Abb. 3: Technische Realisierung des Java Repository
Das Java Repository besteht seit April 1996 und enthält zur Zeit etwa 650 Java-Elemente für unterschiedliche
Problemstellungen. Während anfangs Applets zur Realisierung von Grafikanimationen dominierten, ist in der letzten Zeit
ein Trend zu kommerziell orientierten Applets und Applikationen zu beobachten. So enthält das Java Repository
beispielsweise 55 Ressourcen in den Kategorien "Finance" bzw. "Economics". Die zunehmende Anzahl der SoftwareElemente sowie die Einführung einiger in diesem Abschnitt dargestellten Dienste führte auch zu einer zunehmenden
Nutzung des Java Repository. In der folgenden Abbildung ist die auf den Monat aggregierte durchschnittliche Anzahl
von Zugriffen auf die Homepage pro Tag dargestellt.
file://C:\Download\java-papers\JavaRep\html\papers\SwMgmtMuOkt97.htm
23.08.2002
Wiederverwendung von Softwareelementen: Das Java Repository
Seite 5 von 6
Abb. 4: Durchschnittliche Anzahl von Zugriffen auf die Homepage des Java Repository pro Tag
4. Ausblick: Kommerzielle Wiederverwendung von
Software im Internet
Die Anzahl der Java-Programmierer und die bereits vorhandenen Java -Elemente bilden ein vielversprechendes Potential
für die Wiederverwendung dieser Klassen und Applets. So wie im World Wide Web nahezu alle möglichen
Informationen verfügbar sind, wird es zukünftig auch für eine Vielzahl von Problemstellungen Java-Elemente geben.
Diese Anwendungen werden - wie die Informationen im World Wide Web - dezentral ohne Vorgabe durch eine zentrale
Instanz erstellt und angeboten. Diese dezentrale Struktur ermöglicht erst die Vielfalt der verfügbaren Java-Elemente. Auf
der anderen Seite verursacht diese dezentrale Struktur jedoch auch Probleme. In der überwältigenden Vielzahl von
Angeboten ist eine gezielte Suche nach Problemlösungen nur schwer und mit hohem Zeitaufwand möglich, zudem
besteht keine einheitliche Darstellung und Dokumentation der verfügbaren Software, und es findet keine zertifizierte
Qualitätssicherung statt.
Das Java Repository unterstützt im aktuellen Entwicklungsstand den Nutzer - wie im dritten Abschnitt dargestellt lediglich bei der Suche und vorläufigen Evaluation von Java-Elementen. Um die Potentiale der Wiederverwendung von
Java -Elementen aus dem Internet jedoch noch weiter ausschöpfen zu können, sind an ein solches Repository zusätzliche
Anforderungen zu stellen, die ähnlich sind wie Anforderungen an klassische Werkzeuge zur Wiederverwendung
[Appelfeller 95], [Heß 93], [Zendler 96] und häufig eine zentrale Organisation benötigen, z.B.
l
l
l
l
l
l
eine Erweiterung der gespeicherten Informationen auf Ergebnisse der Analyse- und Entwurfsphase, die auch
semantische Aspekte sowie Beziehungstypen zwischen den Elementen enthält, wie etwa uses, used-by oder partof (einschließlich der Nutzung von Frameworks) [Booch 94] [Rumbaugh 91],
ein von zentraler Stelle durchgeführter Source-Code Review, der einzelne im Repository registrierten SoftwareElemente nach fest definierten Qualitätsmaßstäben bewertet,
eine Dokumentation der Schnittstellen aller Elemente, anhand derer auch ohne Kenntnis der Implementierung
über die Wiederverwendbarkeit entschieden werden kann,
die rechtliche Problematik den Entwicklern die ihnen zustehenden Erträge zu sichern, ist noch nicht gelöst, auch
wenn bereits Lösungsansätze exisitieren [Endres 92],
Import- und Exportschnittstellen und Integration mit Case-Tools sowie
umfangreiche Reports und Statistiken zur durchgeführten Wiederverwendung der Softwarelemente.
Die Liste der Anforderungen zeigt, da ß viele dieser Maßnahmen zentral geplant und durchgeführt werden müssen, um
eine Wiederverwendung von Software -Elementen aus dem Internet wie mit einem unternehmensinternen SoftwareRepository zu unterstützen. Dabei haben wir die Erfahrungen gemacht, daß diese Aufgaben nicht immer dezentralisiert
werden können. So wurde in der Anfangsphase versucht, einen zentralen Dokumentationsstandard auf der Basis des
objektorientierten Entwicklungswerkzeugs OEW für Java einzuführen. Die Entwickler der Java -Elemente wurden
aufgefordert, neben der "normalen" Registrierung auch eine Dokumentation ihrer Klassen mit diesem Werkzeug zu
erzeugen und bereitzustellen. Die Erfahrung zeigte jedoch, daß die meisten Entwickler nicht bereit waren, diesen
file://C:\Download\java-papers\JavaRep\html\papers\SwMgmtMuOkt97.htm
23.08.2002
Wiederverwendung von Softwareelementen: Das Java Repository
Seite 6 von 6
Aufwand in Kauf zu nehmen, solange sie dafür nicht einen direkten zusätzlichen Nutzen oder eine Entschädigung sahen.
Bei dem nicht-kommerziellen Betrieb des Java Repository war der Aufwand einer Nachdokumentation der Software für
den Betrieb des Repository nicht zentral durchführbar, so daß die Dokumentation für den Anbieter optional ist.
Einen möglichen Ausweg aus diesem Dilemma stellt die Kommerzialisierung des Betriebes eines solchen Repository im
Internet dar. Ein bei kommerziellen Intermediären üblicher Ansatz ist, daß dem Intermediär ein Prozentsatz des zwischen
Anbieter und Nachfrager gehandelten Umsatz-Volumens zusteht. Dieser Betrag könnte für die Finanzierung weiterer
zentraler Dienste eingesetzt werden, die wiederum zu einer Steigerung der Attraktivität führt und dadurch mehr
Nachfrager anlocken kann, was wiederum einen Anreiz für Entwickler darstellt.
Obwohl diese wünschenswerten weiteren Funktionalitäten heute noch nicht zur Verfügung stehen, erhielten wir eine
Vielzahl von Reaktionen, die uns bereits auf dem heutigen Status Quo von der nutzbringenden Wiederverwendung
berichteten. Dieses positive Feedback spiegelt sich auch in den stetig zunehmenden Nutzungszahlen des Java Repository
wider, die sich wie Abbildung 4 aus Kapitel 3 zeigte von Mai 1996 bis heute etwa vervierfacht hat.
Literaturverzeichnis
[Appelfeller 95]
[Bailey 96]
[Boehm 81]
[Booch 94]
[Brands 95]
[Buxmann 97]
[Endres 88]
[Endres 92]
[Frakes 95]
[Gosling 95]
[Heß 93]
[Jones 94]
[Kalakota 96]
[König 93]
[Lynch 96]
[Meyer 87]
[Rumbough 91]
[Sarkar 96]
[Sneed 87]
[Wayner 96]
[Zendler 96]
Appelfeller, W.: Wiederverwendung im objektorientierten Softwareentwicklungsprozeß,
dargestellt am Beispiel der Entwicklung eines Lagerlogistiksystems, Frankfurt 1995
Bailey, J.: The Emergence of Electronic Market Intermediaries, in: Proceedings of the 17th
International Conference on Information Systems, Cleveland 1996, S. 391-399
Boehm, B.: Wirtschaftliche Software-Produktion, Wiesbaden 1981
Booch, G.: Objekt-Oriented Analysis and Design with Applications, Redwood 1994
Brands, S.: Electronic Cash on the Internet, Proceedings of the Internet Society 1995
Symposium on Network and Distributed Systems Security, San Diego, California, USA
Buxmann, P.; König, W.; Rose, F.: Aufbau eines elektronischen Handelsplatzes für JavaApplets, in: Krallmann, H. (Hrsg.): Wirtschaftsinformatik 1997, S. 35 -47
Endres, A.: Software -Wiederverwendung: Ziele, Wege und Erfahrungen, in: InformatikSpektrum 11 (1988), S. 85 -95
Endres, A.: Der rechtliche Schutz von Software: Aktuelle Fragen und Probleme, in:
Informatik-Spektrum 15 (1992), S. 89 -100
Frakes, W.; Fox, C.: Sixteen Questions about Software Reuse, in: Communications of the
ACM, 6 (1995), S. 75-87
Gosling, J.; McGilton, H.: The Java Language Environment - A White Paper, Sun
Microsystems Computer Company, Oktober 1995
He ß, H.: Wiederverwendung von Software, Wiesbaden 1993
Jones, T.: Economics of Sotware Reuse, in: IEEE Computer, 1994
Kalakota, R; Whinston, A.: Frontiers of Electronic Commerce, Addison Wesley, 1996
König, W.; Wolf, S.: Objektorientierte Software-Entwicklung - Anforderungen an das
Informationsmanagement, in: Scheer, A.-W.: Handbuch Informationsmanagement,
Wiesbaden, 1993
Lynch, D.; Lundquist, L.: Digital Money, John Wiley & Sons Inc., New York, 1996
Meyer, B.: Reusability: The Case for Object-oriented Design, IEEE Software, 4 (1987), S.
50-64
Rumbaugh, J. et al.: Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs
1991
Sarkar, M.; Butler, B.; Steinfeld, C.: Intermediaries and Cybermediaries: A Continuing Role
for Mediating Players in the Electronic Marketplace,
(http://shum.cc.huji.ac.il/jcmc/vol1/issue3/sarkar.html, March, 27 th 1997)
Sneed, H. M.: Software Management, Köln 1987
Wayner, P.: Digital Cash: Commerce on the Net, Boston et al. 1996
Zendler, A.: Kommerzielle Werkzeuge zur Administration von wiederverwendbaren
Software-Dokumenten, in: Wirtschaftsinformatik 2 (1996), S. 147-159.
file://C:\Download\java-papers\JavaRep\html\papers\SwMgmtMuOkt97.htm
23.08.2002