GemStone/S
Eine objektorientierte Datenbank
Thomas Mikulka
2002 kam es an der TU Wien zu einer grundlegenden Umstellung des "White
Pages Service" [1]. Neu am geänderten Konzept war u.a. die Verwendung einer
ausgelagerten ZID Personendatenbank, die die Quelle aller "White Pages"-Einträge
sein sollte. Schon wieder ein neuer Datenbank-Server? Nein, im Gegenteil!
Hinter dem Begriff "Personendatenbank" steckt tatsächlich eine weitere
Teilfunktion einer erfolgreichen und höchst ungewöhnlichen Datenbank. Ein
Überblick.
Basistechnologien und Funktionsprinzip
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?
Objektorientierung
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.
Instanzen, Instanzvariablen, Methoden
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.
Kapselung
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
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:
Abbildung 1 - Klassenhierarchien
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.
Polymorphismus
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:
20 + 4. 24
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:
"a" class. String
"a" + "b". ab
"a" class whichClassIncludesSelector: "+". SequenceableCollection
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
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".
Semantik und Syntax
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:
Objekt Methode [Parameter].
Einem Objekt können auch mehrere "Aufträge" hintereinander, getrennt durch
Strichpunkte, geschickt werden:
Objekt Methode1 [Parameter1];
Methode2 [Parameter2];
Methode3 [Parameter3].
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:
Object subclass: "Tier"
instVarNames: #( gattung art nahrung lebensraum
)
inDictionary: UserGlobals.
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:
Tier subclass: "Haustier"
instVarNames: #( name besitzer adresse )
inDictionary:
UserGlobals.
Haustier compileAccessingMethodsFor: #( name besitzer adresse ).
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:
| einHaustier |
einHaustier := Haustier new.
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:
einHaustier name: "Minka";
besitzer: "Rosalinde";
adresse: "Gartengasse
12";
art: "Felis domestica";
gattung: "Felis".
Beispiel 6:
einHaustier art. Felis domestica
einHaustier name. Minka
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.
Smalltalk-Entwicklungsumgebungen
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:
mi@gandalf:~> $VISUALWORKS/bin/linux86/visual $HOME/workingWithGemstone.im
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:
Abbildung 2 - VisualWorks Klassen-Browser
Im Grunde ist der "GemStone/S Object Server" nichts anderes als eine Smalltalk-IDE,
ergänzt mit "Multiuser"-Funktionen.
GemStone/S an der TU Wien
Datenstrukturen
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.
Statische, vernetzte Klassen- bzw. Objektsbeziehungen
Beispiel 7 zeigt die Definition der Klasse "Person". Die Vereinbarung unterscheidet
sich von der in Beispiel 2 gezeigten in einigen Punkten.
Beispiel 7:
Object subclass: "Person"
instVarNames: #( title firstName lastName licenceCache accounts roles birthday )
classVars: #( NameTree RemovalLog SpecialUserMap UserMap )
classInstVars: #()
poolDictionaries: #[]
inDictionary: IU_Infoproject
constraints: #[ #[ #title, String],
#[ #firstName, String],
#[ #lastName, String],
#[ #licenceCache,
LicenceSet],
#[ #accounts, AccountList],
#[ #roles, Collection],
#[ #birthday, Integer] ]
instancesInvariant: false
isModifiable: false
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.
#[ #licenceCache, LicenceSet],
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:
Abbildung 3 - Klassenbeziehungen nach Georg Gollmann
Dynamische Beziehungen
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".
Abteilungsinterne Dienste
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.
Abbildung 4 - GemStone/S Verkaufssystem
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.
Abbildung 5 - Bestellwesen, "Workflow"
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.
Benutzerschnittstelle & Entwicklerwerkzeuge
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.
Abbildung 6 - Entwickler GUI
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.
Abbildung 7 - GemStone/S Workspace
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:
Abbildung 8 - Statische Klassenbeziehungen
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:
Abbildung 9 - Klassen-Detailansicht
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").
Abbildung 10 - GemStone/S Methodensuche
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:
Abbildung 11 - Unit Tests in GemStone/S
ZID/TU-weite Dienste
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].
Resumee
Smalltalk
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.
GemStone/S
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.
Literaturangaben
[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/
[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.
[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/
[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/