GemStone/S
Eine objektorientierte Datenbank

Die ZID Personendatenbank [2] ist eine Teilfunktion einer Datenbank, die sich bereits seit 1993 an der TU Wien im Einsatz befindet. Sie ist, im Gegensatz zu den heute gängigen, relationalen Systemen (z. B. Oracle, MySQL oder PostgreSQL etc.), eine rein objektorientierte Datenbank. Hersteller ist die Firma GemStone Systems [3] mit Sitz in Beaverton, Oregon, der offizielle Produktname lautet "GemStone/S Object Server". Das beigefügte "S" nach "GemStone" deutet bereits auf eine ihrer markantesten Besonderheiten hin: die Datenbank selbst, sowie alle TU-spezifischen Applikationen, sind - bis auf wenige Ausnahmen - in Smalltalk geschrieben worden. Was sind nun die Basistechnologien dieser Datenbank?

Der wesentliche Unterschied zwischen einer GemStone/S und einer relationalen Datenbank ist: in GemStone/S ist jeder Dateneintrag ein Objekt und nicht zwangsläufig ein Tabelleneintrag, daher der Name "Object Server". Mehr noch: alles, was sich begrifflich ansprechen lässt, ist in Smalltalk/GemStone ein Objekt. Ein Objekt kann von einfacher Natur, z. B. eine Zahl, eine Zeichenkette oder ein spezieller Datenspeicher sein, etwa eine Liste, eine (math.) Menge oder auch eine Tabelle. Objekte können andererseits auch Repräsentationen von Lehrpersonen, Studenten, TU-Institutionen oder sogar von Arbeitsabläufen sein.

Unabhängig von seiner Natur hat jedes Objekt (wie im realen Leben auch) Eigenschaften und Fähigkeiten. Eigenschaften charakterisieren ein Objekt näher, sie machen es individuell, Eigenschaften werden in so genannten Instanzvariablen festgehalten. Ein kurzes Beispiel: Objekte, die Institute darstellen, gehören der Kategorie oder Klasse "Organisation" an. Ein konkretes Objekt der Klasse "Organisation" - oft auch als Instanz bezeichnet - kann beispielsweise nach seiner genauen Institutsbezeichnung, nach seinem Vorstand, sowie nach seinen Mitarbeitern gefragt werden. Diese und ähnliche Angaben sind individuelle "Eigenschaften" eines Institutes. Und Objekte haben Fähigkeiten, abgebildet als Methoden, die von anderen Objekten durch Senden von "messages" aufgerufen bzw. genutzt werden können.

Jedes Smalltalk/GemStone Objekt stellt, mitsamt seinen Instanzvariablen und Methoden, eine Art Kapsel dar. Der Kapselinhalt ist in der Regel "Privatsache": Variablen sind von außen entweder überhaupt nicht oder nur über bestimmte, veröffentlichte Methoden manipulierbar, und auch die tatsächliche Implementierung einer Methode bleibt i.d.R. vor der Außenwelt verborgen. Kurz: um Dienstleistungen eines Objektes nutzen können, muss der anfragende "Kunde" (z. B. ein anderes Objekt) lediglich die Nachrichten ("messages") des "Dienstleisters" kennen, nicht aber interne Details über die tatsächliche Ausführung.

Welche Vorteile hat das "Kapsel"-Prinzip? Man kann, wegen der engen logischen Verbindung zwischen Nutzdaten und den darauf anwendbaren Funktionen leichter dafür sorgen, dass ein Objekt zu jeder Zeit richtige und vollständige Daten enthält. Solche Mechanismen findet man in der GemStone/S Datenbank z. B. immer dort, wo neue Objekte erzeugt werden. Ein Objekt beispielweise, welches einen Studenten/eine Studentin repräsentieren soll, hat neben Vor- und Zuname typischerweise auch eine Matrikelnummer und eine Studienkennzahl. Inkorrekt wäre, wenn in der Datenbank plötzlich studentische Einträge ohne Matrikelnummer auftauchten. Durch geschicktes Design kann man Methoden schreiben, die gleichzeitig alle persönlichen Studentendaten setzen und diese auf Plausibilität hin überprüfen. Ein Anwender braucht sich auch hier wieder keine Gedanken über die Datenkonsistenz machen.

Ein weiterer Vorteil betrifft laufende Ver- bzw. Ausbesserungsarbeiten. Methoden werden von außen durch "messages" aufgerufen, und liefern i.d.R. definierte Ergebnisse. Bleibt die Nachricht und die Art des erwartbaren Resultats gleich, kann dahinter jede erdenkliche Prozedur ablaufen. Findet ein Programmierer/eine Programmiererin bessere, z. B. schnellere Algorithmen, so kann er/sie diese während des Betriebs ändern, er/sie lässt ja die Schnittstelle nach außen unverändert. Üblicherweise erfüllen Methoden in Smalltalk immer nur relativ kleine Teilaufgaben, der Code bleibt oft überschaubar, sodass sich dadurch manchmal Software-Fehler recht rasch beheben lassen.

Vererbung ist weiteres, wichtiges (manchmal auch überschätztes) Merkmal objektorientierter Software-Systeme. Gleichartige Objekte werden in Klassen eingeteilt. Jede Klasse definiert Instanzvariablen und die verfügbaren Methoden, das Verhaltensrepertoire einer Klasse von Objekten sozusagen. Normalerweise müssen Methoden nach und nach ausprogrammiert werden, objektorientierte Programmiersprachen bieten darüber hinaus an, bereits fertige und anwendbare Methoden zu erben und damit wieder zu verwenden.

Vererbung basiert auf Aussagen wie: "Eine SmallInteger ist ein Spezialfall einer Integer Zahl, eine Integer Zahl ist ein Spezialfall einer Zahl, eine Zahl ist eine Art Größenordnung und eine Größenordnung ist eine Art Objekt." Dieser Zusammenhang kann sehr gut auch graphisch, als hierarchische Struktur innerhalb einer Smalltalk/GemStone Klassenbibliothek dargestellt werden:

Man sagt auch: die Klasse "SmallInteger" ist eine Unterklasse (engl. subclass) von "Integer". Oder umgekehrt: die Klasse "Integer" ist die Ober- oder Superklasse (engl. superclass) von "SmallInteger".

Eine SmallInteger Zahl kennt nicht nur eigene Methoden und Instanzvariablen, sondern auch die ihrer direkten Superklasse, die der Klasse Number usw., d. h. sie erbt Funktionalität. Der größte Vorteil des Vererbungsprinzips ist: eine funktionierende Methode kann auf diese Weise weiter bzw. wieder verwendet werden, was den Ent- wicklungsaufwand beträchtlich reduzieren kann.

Was ist Polymorphismus im Bereich Programmierung? Das deutsche Wikipedia-Portal liefert folgende Begriffserklärung [4]: "Polymorphie (griechisch, "Vielge- staltigkeit") ist ein Konzept der Programmierung, das es erlaubt, einem Wert oder einem Namen (z. B. einer Variablen) mehrere Datentypen zuzuordnen." Innerhalb der GemStone/S Datenbank findet man gelegentlich mehrere, gleichnamige Methodenaufrufe. Ein Beispiel:

In Smalltalk ist "+" eine Nachricht und das "+"-Zeichen ist das Symbol für eine Methode, die 20 und 4 addiert und anschließend das Resultat ausgibt. Die Addition lässt sich also bei Datenobjekten der Kategorie "SmallInteger" anwenden. Bemerkenswerterweise wird dieses Nachrichtensymbol auch noch an anderer Stelle verwendet.

Beispiel 1:

Vorhin sind zwei ganze Zahlen addiert worden, in Beispiel 1 sind die Summanden aber Zeichenketten, die jeweils ein Zeichen lang sind. In Zeile 2 sieht man, dass man mit Hilfe der Nachricht "+" sogar "Nicht-Zahlen" verknüpfen kann. Aber die Addition zweier Zahlen und das Aneinanderreihen zweier Zeichenketten sind doch unterschiedliche Vorgänge, oder? Von außen betrachtet sieht es jedenfalls so aus, als würde die Methode hinter dem "+" Symbol ihre Funktion, ihr "Aussehen" den Summanden anpassen. Kurz: die Methode wirkt sozusagen "polymorph".

Methoden verändern auch noch an anderen Stellen ihr Aussehen: im Abschnitt "Vererbung" ist erwähnt worden, dass Objektsklassen in hierarchischen Beziehungen stehen und dass sog. "subclasses" meist Spezialfälle einer "superclass" sind. Um es mit einem alltäglichen Beispiel zu illustrieren: Hunde und Katzen sind beliebte Haustiere. Haustiere können Laute von sich geben, der "Spezialfall" Hund bellt, während eine Katze z. B. schnurren kann. In objektorientierter Hinsicht muss die Methode "Laut geben" also von den Unterklassen "Hund" bzw. "Katze" weiter spezialisiert werden. Sofern die Oberklasse "Haustier" schon eine Methode "Laut geben" kennt und vererben kann, wird diese in der Unterklasse - z. B. von einer Katze - u.U. sogar vollständig neu geschrieben. Im Fachjargon nennt man den Vorgang des Neuschreibens einer Methode "overriding" [5].

Smalltalk ist die Programmier- bzw. Abfragesprache dieser Datenbank, Smalltalk zählt sicherlich zu den "Ursprachen" der Informatik. Inspiriert von Simula-, LISP- und Logo-Konzepten entstand zwischen 1971 und 1975, unter der Leitung von Alan Kay et al., bei Xerox PARC, erstmals eine vollständige Smalltalk-Entwicklungsumgebung, die schon damals ein Windowing-System anbot. Jahre später schrieb Adele Goldberg ihre legendäre Smalltalk-Bibel "Smalltalk-80, The Interactive Programming Environment".

Die Smalltalk Sprachsyntax [6] ist im Grunde leicht erlernbar. Die Sprache ist "case sensitive", es wird zwischen Groß- und Kleinbuchstaben unterschieden. Jede Programmzeile endet mit einem Punkt, jeder Aufruf folgt einem gleichbleibenden Schema:

Einem Objekt können auch mehrere "Aufträge" hintereinander, getrennt durch Strichpunkte, geschickt werden:

Auch "geschachtelte" Aufrufe sind möglich:

Objekt1 Methode1 ( Objekt2 Methode2 ).

Der Klammerausdruck erzeugt als Resultat ein Objekt, welches seinerseits zu einem Parameter für Methode "Methode1" wird.

Wichtig ist, dass man das Prinzip "Objektorientierung" und damit verbundene Ideen, wie Klassenhierarchien, einigermaßen verstanden hat. Der markanteste Unterschied zu klassischen, prozeduralen Sprachen wie C besteht darin, dass man in Smalltalk geradezu gezwungen wird, sich vor Verfassen einer Codezeile Gedanken zur zugehörigen Klasse zu machen. Oder anders gesagt: in Smalltalk benötigt man Klassen, auch um überhaupt Methoden programmieren zu können. Smalltalk ist damit eine strikt objektorientierte Sprache.

Ein GemStone/S Entwickler muss vor allem wissen, wie neue Klassen deklariert werden. Beispiel 2 zeigt das Erstellen einer neuen Klasse namens "Tier" innerhalb einer GemStone/S Datenbank.

Beispiel 2:

Die Klasse "Tier" wird erzeugt, indem man der "obers- ten" Oberklasse "Object" den Auftrag gibt, eine neue Unterklasse zu bilden (Schlüsselwort "subclass:", gefolgt vom gewünschten Klassennamen), diese mit entsprechenden Instanzvariablen auszustatten (Schlüsselwort "instVarNames:", gefolgt von einem Feld, bestehend aus Variablennamen), und eine Referenz zu dieser neuen Klasse in einer Art "Wörterbuch" einzutragen, um sie dauerhaft im GemStone/S Speicher ("repository") aufbewahren zu können. Erst jetzt werden Methoden formulierbar, die das "Tier" zu einem aktiven Objekt werden lassen.

Kann man in diesem - zugegeben trivialen - Beispiel auch Vererbung zeigen? Ja, man kann. In Beispiel 3 wird eine weitere Unterklasse von "Tier" vereinbart:

Beispiel 3:

Ein Haustier ist offenbar ein Spezialfall von einem Tier. Warum? Weil es, im Gegensatz zu einem frei lebenden, meist einen Namen trägt, einem Besitzer/einer Besitzerin "gehört" und sich sogar eine Adresse angeben lässt, wo es "wohnt". Sobald die Klasse "Haustier" existiert, kann man konkrete Objekte erzeugen, wie in Beispiel 4.

Beispiel 4:

Nach seiner generellen Vereinbarung in Zeile 1, wird die Variable "einHaustier" erst in Zeile 2 zu einem Objekt der Klasse "Haustier". Auch hier unterscheidet sich Smalltalk wieder von anderen Programmiersprachen, die an ähnlicher Stelle einen Variablennamen samt Typenvereinbarung verlangt hätten (Stichwort "late binding").

Und wo merkt man Vererbungsmechanismen? Schon in Zeile 2: hier wird der Variablen "einHaustier" durch das Symbol ":=" ein Wert, genauer ein Objekt zugewiesen. Das Objekt gehört offenbar der Klasse "Haustier" an und kann mit der Nachricht "new" erzeugt werden. Es ist eine Methode, die vorhin (in Beispiel 3) nicht extra angegeben worden ist, die dahinterliegende Methode "new" muss also geerbt worden sein.

Mit dem Objekt "einHaustier" kann bereits "gearbeitet" werden: man kann z. B. dessen Eigenschaften festlegen: Frau Rosalinde soll die Besitzerin einer Katze na- mens Minka sein und - falls Minka entlaufen sein sollte - soll man feststellen können, wo die Katze eigentlich zuhause ist. In Beispiel 3 sind "accessing methods" erstellt worden, die nun genutzt werden können, z. B. die Methoden "name:", "besitzer:" usw.

Beispiel 5:

Beispiel 6:

In Beispiel 5 werden Eigenschaften des konkreten Haustiers festgelegt und in Beispiel 6 abgefragt. Ab jetzt könnte man die Klassen "Tier" und "Haustier" weiter "modellieren" und beispielsweise mit weiteren Methoden ausstatten, die deren Verhalten festlegen.

Was fällt noch auf? Obwohl nicht eigens definiert, versteht das Haustier-Objekt auch die Abfrage "art", ein weiteres Beispiel für Vererbung. Methodennamen haben imperativen Charakter, sie muten wie Befehle an. Durch geschickte Namenswahl kann man oft den Sinn und Zweck einer Methode erraten, ohne den Quellcode lesen zu müssen.

Wie sieht eine typische Smalltalk-IDE aus? Um zu einer VisualWorks IDE zu gelangen, wird eine Virtuelle Maschine ("visual") gestartet. Als Parameter wird dem Aufruf der Name eines sog. "Images" ("workingWithGemstone.im") mitgegeben, in dem sich die komplette Smalltalk-Klassenbibliothek sowie selbst geschriebene Anwendungen befinden können:

Zunächst wird nach diesem Aufruf das sog. VisualWorks-"Transcript"-Window geöffnet. Es ist jenes Fenster, über welches in erster Linie Smalltalk-System- meldungen oder Ergebnisse ausgegeben werden. Das weitaus wichtigere Werkzeug ist aber der sog. Smalltalk-Klassen-Browser, mit dem man Zugriff auf alle vorhandenen Klassendefinitionen und deren Methoden erhält:

Im Grunde ist der "GemStone/S Object Server" nichts anderes als eine Smalltalk-IDE, ergänzt mit "Multiuser"-Funktionen.

In der GemStone/S Datenbank am ZID gibt es mehr als 95 Klassendefinitionen und mehr als 1 Million "lebende" Objekte. Mit "lebend" sind Objekte gemeint, die aktuelle Daten enthalten und die wiederauffindbar sind, d. h. referenzierbar sind. Die Klassennamen sind meistens selbsterklärend und beziehen sich i.d.R. auf Begriffe oder Arbeitsabläufe innerhalb des ZID oder der TU Wien. Relativ häufig verwendet wird die Klasse "Person". Im Folgenden soll anhand dieser Klasse beispielhaft gezeigt werden, auf welche Art diverse Klassen in Beziehung zueinander stehen.

Beispiel 7 zeigt die Definition der Klasse "Person". Die Vereinbarung unterscheidet sich von der in Beispiel 2 gezeigten in einigen Punkten.

Beispiel 7:

Als Erstes fällt auf: die Klasse "Person" kennt sog. Klassenvariablen (Abschnitt "classVars"). Es sind Speicher, auf die alle Personenobjekte zumindest lesend zugreifen können. Auf diese Weise kann man Informationen "global" verteilen. Ein weiterer Unterschied zu Beispiel 2 ist: in dieser Klasse ist erstmals festgelegt, welcher Art die Instanzvariablen sein dürfen. Diese Einschränkungen stehen im Abschnitt "constraints", einer GemStone/S Erweiterung. Eine Zeile daraus, z. B.

besagt, dass eine Person (neben Titel, Vor- und Zuname usw.) auch einen sog. "licenceCache" hat, der vom Typ "LicenceSet" sein muss. Was ist in so einem "Lizenz Cache" verzeichnet? Die Antwort lautet: alle, von einer Person gekauften bzw. gemieteten Campus- oder Studenten-Softwarelizenzen. Auch ein "LicenceSet" ist eine Objektsklasse, die ihrerseits nur Elemente der Klasse "Licence" enthalten darf.

Umgangsprachlich kann man diese Art von Klassen- bzw. Objektsbeziehungen auch so formulieren: eine Person kann einen Titel tragen, sie hat einen oder mehrere Vor- bzw. einen Zunamen sowie einen Geburtstag, sie kann Software-Lizenzen und/oder TU-Zugänge ("accounts") gemietet haben und sie kann entweder TU-, Drittmittel- oder Projektmitarbeiter/in sein (siehe "roles"). Damit werden vor allem statische, zeitlich praktisch unveränderliche Beziehungen zwischen Objekten beschrieben. Je weiter man diesen "ist"- und "hat"-Beziehungen folgt, umso netz- artiger werden die Zusammenhänge zwischen den Gem- Stone/S Objekten. Georg Gollmann hat diesen Umstand anlässlich einer "European Smalltalk User Group" Konferenz 2004 folgendermaßen graphisch dargestellt:

Innerhalb der GemStone/S Datenbank gibt es auch "dynamische" Beziehungen. Das sind im Wesentlichen temporäre Zusammenhänge, die während bestimmter Arbeitsabläufe entstehen. Wir wissen: Objekte erfüllen immer relativ kleine Aufgaben, deren Dienste können aber von anderen Objekten genutzt werden. Dienste eines Objektes können von außen durch "messages" genutzt werden. Und um einen größeren Auftrag erledigen zu können, müssen in der GemStone/S Datenbank oft mehrere Objekte miteinander kommunizieren, kurz: "messages" zwischen unterschiedlichen GemStone/S Objekten hin- und hergeschickt werden. Im Fachjargon heißt diese Art von Kommunikation bzw. das Aufrufen von Methoden auch "message passing".

Bezüglich der Aufgaben, die die GemStone/S Datenbank an der TU Wien übernimmt, kann man sagen: ihr Aufgabenbereich lässt sich unterteilen in abteilungsinterne und in TU/ZID-weit angebotene Dienste.

Die GemStone/S Datenbank ist für Abteilung Standardsoftware (STS) das zentrale Werkzeug. Mit ihrer Hilfe wird der Vertrieb von Campus- bzw. Studenten- Software-Lizenzen abgewickelt. Eine öffentliche Schnittstelle der Datenbank ist übrigens im Lehrmittelzentrum (LMZ), gleich neben der Kassa, zu sehen. Abbildung 4 zeigt die Benutzeroberfläche zum GemStone/S Verkaufssystem. Mit einem Handscanner liest der/die Verkäufer/in die Matrikelnummer vom Studentenausweis ein, der Verkaufs-PC kontaktiert die GemStone/S Datenbank, die die Bezugsberechtigung prüft und gleichzeitig Buch führt über die getätigten Einkäufe des/der Studenten/in.

In dieser Datenbank sind alle STS-Kunden und Produkte verzeichnet, sie ist ein internes Dokumentationsystem, Fallverfolgungssystem für Wartungsvertrags-Unter- stützungsfälle und Abrechnungssystem in einem, sie erfasst das STS-Inventar und bildet das STS-eigene Bestellwesen ab. Die Funktion des Bestellwesens ist seit 2004 im Einsatz. Es ermöglicht STS-Mitarbeiter/innen das problemlose, unbürokratische Absetzen von Bestellungen für Neuerwerbungen, Ersatzteile, Seminare, Bücher etc. und ist mit dem nachträglich eingeführten SAP-System gekoppelt. Abbildung 5 zeigt den "Workflow" eines Bestellvorgangs.

Eingetroffene Waren, die den Wareneingang erfolgreich passiert haben, werden im GemStone/S Bestellsystem "abgelegt". "Abgelegt" bedeutet i.d.R., dass diese Anlage-, Verbrauchsgüter etc. von der Datenbank automatisch ins eigene Inventarsystem übernommen werden. Mit dieser Funktion verfügt der STS-Leiter, Herr DI Albert Blauensteiner, stets über eine tagesaktuelle Budgetübersicht und kann Abschreibekalkulationen und Anlagenbewertungen praktisch auf "Knopfdruck" durchführen lassen. Er ist damit zu jeder Zeit über aktuelle Kostenverläufe informiert und hat damit die Basis für präzise budgetäre Planungen.

Die GemStone/S Datenbank ist nicht nur ein reiner Datenspeicher, sie ist - wie vorhin gezeigt - ein wichtiges, zentrales Verwaltungsinstrument und Entwicklungssystem zugleich. Ihre primäre Schnittstelle ist ein Web-Server, der - natürlich auch in Smalltalk geschrieben - integrierter Bestandteil der Datenbank ist. Der Zugriff ist damit für die meisten Benutzer mittels Web-Browser möglich, wobei die Verbindungen durch SSL ("Secure Socket Layer") geschützt werden. Es sind zwei unterschiedliche Zugänge via Web-Browser möglich: die eine Variante erfordert einen expliziten Datenbank-Login, wodurch eine so genannte "Private Session" eröffnet wird. "Private Sessions" sind i.d.R. Mitarbeiter/innen der Abteilung STS vorbehalten. Zugänge ohne Login, die mehr oder weniger öffentlich sein sollen, können auch anders verifiziert werden, z. B. durch das TU-Passwort. Mit dem TU-Passwort kann man beispielsweise eigenen "White Pages"-Einträgen weitere Informationen hinzufügen, eine Funktion, die von der GemStone/S Datenbank bereit gestellt wird. Jeder Benutzer sieht beim Zugriff eine andere GemStone/S Oberfläche, deren Aussehen hängt von der jeweiligen Funktion und Rolle des/der Mitarbeiter/in ab. Abbildung 6 zeigt das sog. "Graphical User Interface (GUI)" eines GemStone-Entwicklers.

Die eigentlichen Entwicklungswerkzeuge sind über die "Developers:"-Zeile erreichbar. Es gibt einen "Workspace", in dem Smalltalk-Code quasi "ausprobiert" werden kann. Die in den vorherigen Beispielen gezeigten Abfragen, Berechnungen und Klassenvereinbarungen können kopiert und direkt im "Workspace" eingetragen werden.

Die Code-Zeilen werden praktisch zur Laufzeit übersetzt bzw. interpretiert, man kann dadurch leicht und rasch Smalltalk-Code auf dessen Brauchbarkeit hin untersuchen, bevor dieser Teil einer Methode wird. Das Ergebnis eines beliebigen Aufrufs ist - wie in Smalltalk üblich - selbst wieder ein Objekt und wird in einem separatem Browser-Fenster dargestellt.

Hinter der Verknüpfung "Class Relationships" kann ein Entwickler feststellen, welche statischen Beziehungen zwischen ausgewählten GemStone/S-Klassen bestehen. Möchte man z. B. wissen, mit welchen anderen Klassen die Klasse "Person" in Beziehung steht, so erhält man folgende graphische Darstellung:

Hinter der Verknüpfung "System Categories" steckt das vermutlich wichtigste Werkzeug: der GemStone/S Klassen-Browser. Er zeigt alle existierenden Klassendefinitionen, welche unterteilt sind in GemStone/S Kernel- Klassen, in Klassen, die entweder STS-spezifische Funktionen (Kategorie "IU_Infoproject") oder TU/ZID-weite Dienste bereitstellen (Kategorie "ZID DB"). Außerdem gibt es Klassen, die die eigentlichen Daten darstellen. Daten können in "Arrays", in "Sets" oder in "Bags" u.ä. dauerhaft gespeichert werden, die Klassendefinitionen dazu findet man in der Kategorie "Collections". Eine praktische Zusatzfunktion bietet die Detailansicht einer Klasse:

Man kann sich die sog. Ober- bzw. Unterklassen ("superclasses" bzw. "subclasses") auflisten lassen und bekommt dadurch u.a. Hinweise, welche zusätzlichen Funktionen eine Klasse - wegen Vererbung - sonst noch erfüllen kann. Über den Menüpunkt "Method List" kann ein/e Entwickler/in nach Methoden suchen. Er/Sie kann damit feststellen, welche Klasse eine bestimmte Methode implementiert bzw. wie oft der Methodenname im System ingesamt vorkommt (siehe Abschnitt "Polymorphismus").

GemStone/S Entwicklungszyklen lehnen sich stark an Empfehlungen der "eXtreme Programming (XP)" Fachleute [9] an. Eine dieser Empfehlungen lautet: "Bevor Du tatsächlich Code-Zeilen schreibst, nimm die vorgegebene "User Story" und entwickle daraus zunächst nur Tests. Diese Tests sollen genau das tun, was der spätere Benutzer tun möchte/tun will. Beginne erst danach mit dem eigentlichen Entwicklunsprozess, die Software wird fertig sein, wenn sie alle Tests erfolgreich absolviert."

Die GemStone/S Datenbank enthält eine Klasse "TestCase", mit der diverse Testfälle formuliert werden können. Erfüllt eine Datenbank-Teilfunktion alle geforderten Aufgaben, so sieht das so aus:

Zu den wichtigsten TU-weiten GemStone/S Diensten gehört sicherlich die ZID Personendatenbank. Diese ist - wie bereits erwähnt - eine Teilfunktion und übernimmt eine Art Verteilerrolle: die eigentlichen Daten werden in der zentralen Verwaltung (z. B. Namen von TU-Angestellten und Studierenden) oder in der Telefonanlage (z. B. Nebenstellendurchwahl) generiert, anschließend von der GemStone/S Datenbank importiert und an die "White Pages" weitergegeben. Die genaue Funktion der Personendatenbank erläutert Herr DI Georg Gollmann in seinem ZIDline-Artikel vom Oktober 2002 [2].

Darüber hinaus unterstützt die Datenbank auch die Verwaltung von ZID-Accounts und sie ist gleichzeitig Authentifizierungsserver für eine Reihe von Web- Anwendungen an der TU Wien. Anwender dieser Gem- Stone/S Funktion ersparen sich damit das Entwickeln eigener, aufwendiger Authenfizierungsmechanismen. Detaillierte Informationen dazu finden sich in [7] und [8].

Smalltalk ist eine flexible, moderne Programmiersprache. Sie wird heute in Österreich kaum verwendet oder gelehrt, was verwunderlich ist, wenn man bedenkt, dass einige Java-Konzepte aus der Smalltalk-Welt stammen, so zu Beispiel das Konzept der Virtuellen Maschinen. Heute gibt es Smalltalk-IDE für UNIX, MacOS, WinXP und natürlich Linux, eine Anwendung entwickelt unter WinXP läuft somit auch unter Linux.

Hinsichtlich der Verbreitung stellt sich die Situation in Deutschland ähnlich dar, an folgenden Stellen wird erfolgreich mit Smalltalk/VisualWorks gearbeitet: die Firma Carl Zeiss in Oberkochen entwickelt damit ihre Messsoftware "Calypso" [13]. Am Standort Dresden steuert der Intel-Konkurrent AMD "Wafer" Fertigungsprozesse teilweise mit Smalltalk-basierender Software. Der Heise-Verlag hat in den letzten Jahren einige Artikel zu Smalltalk veröffentlicht [14].

Wer Smalltalk lernen und die Geheimnisse dieser Sprache kennenlernen möchte, der kann entweder bei Georg Heeg ein Seminar besuchen [16] oder sich ein Buch kaufen oder ausborgen. An der TU Bibliothek verfügbar sind z. B. [10, 11].

Die unbestrittene Smalltalk-Kompetenz an der TU Wien ist Herr DI Georg Gollmann (DW 42022, E-Mail: gollmann@zid.tuwien.ac.at).

Für Lehr- und Lernzwecke gibt es glücklicherweise frei verfügbare Smalltalk-Entwicklungswerkzeuge (mit entsprechender Dokumentation), z. B. [18, 19]. Diese Smalltalk-IDE bieten alles, was Entwickler/innen brauchen können: Klassen-Browser, "Workspaces", Debugger und gute Dokumentation, besonders für VisualWorks.

Der "GemStone/S Object Server" kann ebenfalls - z. B. zu Evaluierungszwecken oder zur persönlichen Weiterbildung - frei bezogen werden: http://www.gemstone.com/products/smalltalk/.

Die Dokumentation ist nicht Bestandteil des "Object Servers", sie muss eigens geholt werden. Der "Object Server" wird üblicherweise mit einer 30-Tage-Demolizenz geliefert, eine namentliche Registierung ist erforderlich.

Die GemStone/S Datenbank ist ein überaus flexibles, stabiles Produkt, das heute von sehr großen Unternehmen, wie z. B. der "Orient Overseas Container Line" [20] verwendet wird. Die Flexibilität wird - wie gezeigt - durch objektorientierte Betrachtungsweisen erreicht. An der TU Wien hat sie jedenfalls bewiesen, dass sie auch nach 9 Jahren noch immer erweiterbar ist [2]. Eine gutes Zeichen für zukünftige Aufgaben.

[1] Klasek, Johann: White Pages Service, ZIDline Nr. 7, Oktober 2002, S. 11ff.

[2] Gollmann, Georg: ZID Personendatenbank, ZIDline Nr. 7, Oktober 2002, S. 16f.

[3] GemStone Systems, 1260 NW Waterhouse Ave., Suite 200, Beaverton, Oregon 97006, http://www.gemstone.com/

[4] Wikipedia: Polymorphie (Programmierung), Oktober 2006, http://de.wikipedia.org/wiki/Polymorphie_%28Programmierung%29

[5] Hunt, John: Smalltalk and Objectorientation, An Introduction, Springer Verlag, Berlin 1997, ISBN: 3540761152

[6] GemStone/S Programming Guide, Version 6.0, GemStone Systems, December 2001

[7] Gollmann, Georg: Authenfizierungsservice, ZIDline Nr. 7, Oktober 2002, S. 35f.

[8] Gollmann, Georg: Dateninfrastruktur, http://sts.tuwien.ac.at/go/Dateninfrastruktur.html

[9] Wells, Don: Extreme Programming: A gentle introduction. http://www.extremeprogramming.org/

[10] Johannes Brauer: "Grundkurs Smalltalk, Objektorientierung von Anfang an", Vieweg Verlag, Wiesbaden: 2004 (2., verb. Aufl.), ISBN: 3-528-15818-2

[11] Beck, Kent: Kent Beck"s guide to better smalltalk, Cambridge Univ. Pr., Cambridge: 1999 (1. Aufl.)

[12] Smalltalk Industry Council (STIC): Why Smalltalk, http://www.whysmalltalk.com/

[13] http://www.zeiss.de/Calypso-fuer-alle

[14] http://www.heise.de/ct/inhverz/search.shtml?T=Smalltalk&Suchen=suchen

[15] Vorlesungen u.a. zum Thema Smalltalk: http://brauer.nordakademie.de/sites/main.html

[16] Seminare Fa. Georg Heeg Köthen bzw. Dortmund: http://www.heeg.de/

[17] Die Smalltalk-"Online"-Referenz ist: "Why Smalltalk", http://www.whysmalltalk.com/

[18] VisualWorks 7.x von CinCom: http://www.cincomsmalltalk.com/userblogs/cincom/blogView

[19] Squeak: http://www.squeak.org/

[20] http://www.oocl.com/, http://www.gemstone.com/pdf/OOCL_SuccessStory.pdf