Die integrierte Entwicklungsumgebung VisualWorks und die zugehörige
Programmiersprache Smalltalk werden mit ihren Stärken und
Schwächen vorgestellt.
Inhalt
Einführung Anforderungen für eine effiziente Softwareentwicklung Die Programmiersprache Smalltalk: VisualWorks als Smalltalk-Entwicklungsumgebung VisualWorks als integrierte Entwicklungsumgebung Browser Canvas Tool, Image Editor und Menu Editor ChangeSet Profiling ReportGenerator Datenbankanbindung Zusätzliche Rahmenwerke BusinessGraphics DLL and C Connect VisualWave Nützliche Einstiegspunkte im World Wide Web in Verbindung mit Smalltalk Zusammenfassung Abkürzungsverzeichnis Referenzen
Die integrierte Entwicklungsumgebung VisualWorks von ObjectShare Inc. für die Programmiersprache Smalltalk gibt es für die Plattform Linux in zwei verschiedenen Varianten:
Beide Versionen unterscheiden sich vom Funktionsumfang und der Leistungsfähigkeit nicht. Neben der geänderten Lizenz kann einzig und allein das VisualWorks-Signet, das beim Start kurzzeitig angezeigt wird, in der nichtkommerziellen Version nicht geändert werden.
Die Lizenz der nichtkommerziellen Version schränkt aus meiner Sicht den Privatanwender und Hobby-Linux-Enthusiasten nicht ein. Er kann und darf seine Entwicklungen, solange er dies nicht kommerziell durchführt, auch anderen zugänglich machen.
Weiterhin kann die nichtkommerzielle Version zur Produkt-Evaluation durch einen professionellen Anwender verwendet werden. (Hierfür gibt es auch die Möglichkeit, eine spezielle Evaluierungsversion bei der deutschen Niederlassung anzufordern.)
Die Möglichkeit zum Download der Non-Commercial Version besteht auf der zugehörigen Downloadseite, weiterhin sind die Installationsdateien mit einigen Hinweisen auch auf der Tagungs-CD-ROM zu finden.
Im Folgenden werden zunächst allgemeine Anforderungen für eine effiziente Softwareentwicklung beschrieben. Anschließend wird ein Überblick über die Programmiersprache Smalltalk gegeben. Danach wird VisualWorks als Smalltalk-Entwicklungsumgebung vorgestellt. Es schließt sich ein Abschnitt über VisualWorks als integrierte Entwicklungsumgebung an. In diesem werden wesentliche Werkzeuge für die Softwareentwicklung im Zusammenhang mit VisualWorks vorgestellt.
Sowohl der Heimanwender als auch der professionell tätige Programmierer möchte bei der Softwareentwicklung effizient arbeiten und sich auf sein spezielles Problem konzentrieren können. Er hat kein Interesse daran, jedesmal von neuem z. B. Datenstrukturen für eine einfach verkettete lineare Liste mit den zugehörigen Funktionen wie zum Einfügen eines Elementes in die Liste neu zu erstellen. Vielmehr möchte er Bestehendes wiederverwenden. (Ein einfaches Duplizieren von Quelltext ist hiermit nicht gemeint!) Es sind (zum Teil sehr) umfangreiche Bibliotheken erstellt worden, die derartige Datenstrukturen und Funktionen bereitstellen. Es wird jedoch nicht immer der Fall sein, dass die Funktionalität, die in einer Bibliothek bereitgestellt wird, vollständig den eigenen Wünschen entspricht. Dann ist leichte Anpassbarkeit an die eigenen Bedürfnisse gefordert. Wird eine Bibliothek im Quelltext mitgeliefert, so ist dies deutlich einfacher bzw. wird dadurch erst möglich.
Neben der Möglichkeit der Wiederverwendung möchte der Softwareentwickler auch Rahmenwerke (Frameworks) nutzen. Hier sind jedoch mehrere kleine einem einzigen Allround-Rahmenwerk vorzuziehen. So ist der Einarbeitungsaufwand kleiner, einzelne Bereiche bleiben überschaubar. Als klassisches Beispiel ist ein Rahmenwerk für die Oberflächengestaltung zu nennen. Der Programmierer braucht sich dann z.B. um das Neuzeichnen eines Fensters oder das "Verfolgen" des Mauszeigers nicht zu kümmern.
Weiterhin wünscht sich ein Softwareentwickler Werkzeuge, die ihn bei seiner Arbeit unterstützen und seine Kreativität nicht beeinflussen. Werkzeuge können, grob gesagt, in zwei Kategorien eingeteilt werden. Werkzeuge, um
Auf weitere mögliche Kategorien oder Unterscheidungsmöglichkeiten soll an dieser Stelle nicht weiter eingegangen werden.
Greifen verschiedene Werkzeuge ineinander und unterstützen sich gegenseitig, so ist dies offensichtlich von Vorteil; die Idee der integrierten Entwicklungsumgebung (engl. Integrated Development Environment, IDE) wurde geboren. Die speziellen Leistungsmerkmale der IDE VisualWorks werden in einem Absatz weiter unten beschrieben.
Neben der verwendeten Softwareentwicklungsumgebung (welche im einfachsten Fall aus einer Shell, einem Editor und weiteren eigenständigen Programmen wie Compiler, Linker, etc. besteht) spielen unter anderem folgende weitere Faktoren eine wichtige Rolle:
E. W. Dijkstra formuliert bereits 1972 in [Dijkstra72]:
Als es noch keine Rechner gab, war auch das Programmieren noch kein Problem, als es dann ein paar leistungsschwache Rechner gab, war das Programmieren ein kleines Problem und nun, wo wir gigantische Rechner haben, ist auch das Programmieren zu einem gigantischen Problem geworden. In diesem Sinne hat die elektronische Industrie kein einziges Problem gelöst, sondern nur neue geschaffen. Sie hat das Problem geschaffen, ihre Produkte zu nutzen.
Die Programmiersprache Smalltalk wurde am Palo Alto Research Center (PARC) von Xerox entwickelt. In der Version Smalltalk-80 wurde sie einer breiteren Öffentlichkeit vorgestellt. Die Spezifikation ist in [GoldbergRobson83] nachzulesen.
Smalltalk ist eine rein objektorientierte Programmiersprache. Einfach alles ist ein Objekt und wird auf eine uniforme Art und Weise behandelt. Auch die Zahl 3 oder der Buchstabe a ist ein Objekt und damit Instanz (Exemplar) der jeweils zugehörigen Klasse. Diese kann genauso den eigenen Bedürfnissen angepasst werden wie eine applikationsspezifische Klasse. Es gibt keine »primitiven Dinge«, die maschinenspezifisch auf eine andere Art und Weise behandelt werden. Weiterhin ist auch eine Klasse wiederum ein Objekt mit einer zugehörigen Klassendefinition und kann dadurch (auch dynamisch) modifiziert werden. Die Sprache bietet die Möglichkeit zur Metaprogrammierung, das System kann sein eigenes Verhalten modifizieren. Ein Überblick hierzu gibt dieses online verfügbare Dokument beim PARC, die Möglichkeiten für Smalltalk werden in [FooteJohnson89] näher beschrieben.
Nachdem nun schon die ganze Zeit von Objektorientierung die Rede war, soll dieser Gedanke in ein paar Worten näher erläutert werden. Detaillierte Informationen mit Beispielen in Smalltalk befinden sich z.B. in [Smith91]. Kerngedanken der Objektorientierung nach [Budd91]sind:
Smalltalk hat eine sehr einfache (»arme«) Syntax. Sie kann formal mit allen Einzelheiten in ca. 25 Regeln beschrieben werden. (Vergleichbare Programmiersprachen mit »reicher« Syntax haben zum Teil mehrere hundert solcher formalen Regeln). Aufgrund dieser einfachen Syntax kann die Sprache sehr schnell (in ca. ein bis zwei Stunden) erlernt werden. Die notwendige Ausdruckskraft für mächtige Programme erhält der Programmierer durch eine sehr umfangreiche Klassenbibliothek. Sie ermöglicht es, auf (sehr) hohem Abstraktionsniveau Softwareentwicklung zu betreiben. Im Allgemeinen werden z.B. (Multi-)Mengen, Hash-Tabellen, Listen, etc. zur Verfügung gestellt.
Kontrollstrukturen wie if-then-else (in Smalltalk durch die Nachricht ifTrue:ifFalse: realisiert) oder while-Schleifen sind genauso als »normale« Methoden realisiert und nicht als reservierte Wörter in der Sprachdefinition enthalten. Benötigt ein Programmierer eine neue Kontrollstruktur für sein spezielles Problem, so kann er diese analog zu den bereits vorhandenen einfach erstellen. Er ist nicht auf die in der Sprache vordefinierten Kontrollstrukturen beschränkt; er ist nicht gezwungen, auf Hilfskonstruktionen zurückzugreifen. Auch dadurch ist die Abstraktion im Smalltalk-Programm im allgemeinen sehr hoch.
Eine einzelne Methode umfasst oft nur ein bis drei Zeilen und kann so sehr leicht analysiert werden. Andererseits bedeutet dies aber auch, dass ein komplizierter Algorithmus über mehrere Methoden verteilt implementiert und dadurch nicht »auf einen Blick« zu übersehen ist. Eine einzelne Methode implementiert im Allgemeinen einen abgeschlossenen Aspekt des Algorithmus und kann dann auch in ähnlichem Zusammenhang wiederverwendet werden. Kent Beck als einer der »Smalltalk-Gurus« vertritt in [Beck97] die Auffassung, dass eine bestimmte Anweisung (abgesehen von ganz elementaren Dingen wie der Zuweisung eines Objekts an eine Variable) innerhalb einer Applikation höchstens einmal vorkommen darf:
Ich reduziere guten Programmierstil auf eine einzige einfache Regel: In einem Programm in gutem Stil wird alles höchstens einmal geschrieben. Dies hilft nicht viel dabei, guten Quelltext zu erstellen, ist aber ein sehr gutes Analysewerkzeug.
Zu kleinen Einheiten schreibt er weiter:
Guter Quelltext hat als Invariante: nur kleine Methoden und Objekte. Nur durch die Zerlegung eines Systems in viele kleine Stücke für Zustand und Funktionalität kann der Programmierer hoffen, die Regel »alles höchstens einmal« zu erfüllen. Ich treffe auf großen Widerstand gegen diese Regel, vor allem von erfahrenen Entwicklern. Aber nichts anderes hilft mir bei der Systemanalyse so sehr, wie die Zerlegung in noch mehr Teile. Bei der Zerlegung muss man darauf achten, den Gesamteindruck effizient zu vermitteln.
Werden diese Regeln verletzt, so muss nach Becks Meinung der Quelltext einer unter Umständen tiefgreifenden Umgestaltung (Refaktorierung) unterzogen werden. Der Refaktorierungsansatz ist in [Opdyke92] näher beschrieben, ein zugehöriges Werkzeug ist der RefactoringBrowser.
Ziel der Sprachentwickler war es, die Syntax so zu gestalten, dass ein Programm wie ein »normaler Text« zu lesen ist.
Auf die konkrete Syntax der Programmiersprache Smalltalk wird nicht weiter eingegangen. Dies würde den Rahmen dieses Beitrags sprengen. Einführungen sind online z.B. an der Universität Magdeburg (in deutsch) oder auf dem Swiki-Server der Informatik der University of Illinois at Urbana Champaign unter Tutorials and courses zu finden. Ein weiterer guter Startpunkt ist die Sammlung Cetus-Links: Smalltalk.
Seit 1998 gibt es den ANSI-Standard X3J20 für Smalltalk und die zugehörige Klassenbibliothek. Damit soll die Austauschbarkeit von Applikationen zwischen verschiedenen Smalltalk-Entwicklungsumgebungen erleichtert werden. Der Standard sowie eine Übersicht über verschiedene Smalltalk-Entwicklungsumgebungen sind beim Smalltalk Industry Council zu finden.
Für den Smalltalk-Entwicker, der VisualWorks verwendet, sind zwei Ansatzpunkte besonders wichtig:
Ein derartiges Image ist eine Ansammlung von Objekten. Wie bereits gesagt, sind auch Klassen- und Methodendefinitionen Objekte und damit in einem Image verfügbar und für den Programmierer manipulierbar. Dies beinhaltet auch das Erzeugen neuer Objekte (als Instanzen einer Klasse) und das Zerstören von nicht mehr benötigten Objekten.
Die virtuelle Maschine (VM; engl. object engine, OE) setzt Smalltalk-Anweisungen in Anweisungen für das Wirtssystem um. Durch diesen Zwischenschritt sind Smalltalk-Applikationen von Anfang an zwischen verschiedenen Betriebssystemen portabel. Einzig und allein eine VM ist für eine neue Plattform nötig. Von VisualWorks werden neben Linux unter anderem auch Sun Solaris, HP-UX, PowerMacintosh und MS-Windows 95/98/NT als Plattform unterstützt. Für MS-Windows und PowerMacintosh stehen ebenfalls nichtkommerzielle Versionen bei ObjectShare zur Verfügung.
Der Ablauf während der Entwicklung ist folgender: Der Smalltalk-Quelltext wird durch einen Compiler in sogenannten Bytecode übersetzt. Dieser wird dann von der VM interpretiert. Sowohl Quelltext als auch der zugehörige Bytecode werden im Image gespeichert.
Am Rande sei erwähnt, dass Squeak als alternative Entwicklungsumgebung die Möglichkeit hat, C-Code aus Smalltalk-Quelltext zu produzieren, und ebenfalls für Linux verfügbar ist.
In VisualWorks ist der Compiler selbst (wie alle anderen im folgenden erwähnten Werkzeuge auch) in Smalltalk realisiert. Die zugehörigen Klassen- und Methodendefinitionen befinden sich im Quelltext einschließlich umfangreicher Kommentare in der mitgelieferten Bibliothek. Diese können als Muster und Ausgangspunkt für eigene Entwicklungen dienen. Denkbar ist es z.B., innerhalb von VisualWorks Unix-Shellskripte oder SQL-Datenbankabfragen mit den vorhanden Werkzeugen zu entwickeln, und diese dann eben nicht von der virtuellen Maschine sondern von der Shell oder dem Datenbankmanagementsystem abarbeiten zu lassen.
Weitere Vorteile:
Der Übersetzungsvorgang läuft inkrementell für einzelne Methoden- oder Klassendefinitionen ab. Sobald eine Eingabe als »fertig« markiert (»akzeptiert«) wird, bearbeitet der Compiler diese eine Definition. Dies benötigt nur sehr wenig Zeit, das Warten auf den Compiler und/oder Linker entfällt damit vollständig. Weiterhin erhält der Programmierer sofort Hinweise auf mögliche Syntaxfehler, falls z.B. eine Variable nicht deklariert wurde, oder es zu einer aufgerufenen Methode (bislang) keine Implementierung gibt. Es besteht dann die Möglichkeit, die fehlende Definition generieren zu lassen oder einen Tippfehler halbautomatisch korrigieren zu lassen. Schließlich gibt es auch die Möglichkeit, den Fehler einfach zu ignorieren. Dies ist von Vorteil, wenn mittels Rapid Prototyping ein erster Entwurf einer Applikation erstellt werden soll. Die Behandlung eines Spezialfalls kann bei der Entwicklung zunächst zurückgestellt werden, der zugehörige Methodenaufruf kann jedoch sehr wohl schon eingefügt werden. Beim Ablauf der Applikation ist dann nur sicherzustellen, dass dieser Fall (zunächst) nicht auftritt. Im weiteren Verlauf der Entwicklung braucht dann »nur noch« die zugehörige Methode erstellt werden. Eingegebener Quelltext kann sofort getestet und bei Bedarf modifiziert werden. Der klassische Edit-Compile-Link-Debug-Zyklus ist aufgebrochen.
Die Fehlersuche wird deutlich vereinfacht. So kann mit Hilfe der einfach eingefügten Nachricht self halt. jederzeit der Debugger aufgerufen werden. (self referenziert in Smalltalk das Objekt, welches die aktuelle Nachricht erhalten hat und nun ein spezielles Verhalten zeigen soll; mittels einer Nachricht wird ein Objekt aufgefordert, eine bestimmte Methode auszuführen, d.h. ein bestimmtes Verhalten zu zeigen.) Im Debugger ist im allgemeinen die gesamte Aufrufhistorie sichtbar, die Belegung von Variablen ist überprüfbar. Dies ist noch nichts Neues. Interessant ist jedoch, dass im Debugger auch die Variablenbelegung modifiziert werden kann. Weiterhin kann ein Fehler in der Implementierung einer aufgerufenen Methode behoben und der Programmablauf anschließend an der gleichen Stelle fortgesetzt werden. Im Extremfall kann die gesamte Entwicklung im Debugger durchgeführt werden. Dies läuft dann so ab, dass ein konkreter Anwendungsfall (use case) durchgespielt wird. Neue Methoden werden erst unmittelbar vor ihrer Verwendung implementiert, bestehende Methoden werden bei Bedarf angepasst bzw. erweitert. Jede Codeänderung bzw. neu erstellter Quelltext wird vom Compiler sofort übersetzt und steht dann zur Ausführung bereit.
Der Compiler ist in Zusammenarbeit mit der virtuellen Maschine in der Lage, den Bytecode auf Geschwindigkeit zu optimieren.
Durch das Parcel-Konzept können zusammenwirkende Klassen und Methoden zu einer Einheit (»Paket«) zusammengefasst werden. In dieser Einheit kann der Quelltext bequem und »ohne etwas zu vergessen« von einem Image in ein anderes Image transportiert werden. Insbesondere können in einem Paket weitere Pakete angegeben werden, die für die Implementierung zwingend notwendig sind. Auf diese Weise sind Abhänigkeiten zwischen verschiedenen Paketen leicht zu beherrschen.
Wie bereits zu Anfang festgestellt, sind Werkzeuge zur Unterstützung der Softwareentwicklung essentiell. VisualWorks stellt unter anderem die folgenden Werkzeuge zur Verfügung:
Mit den AdvancedTools (in der nichtkommerziellen Version direkt mitgeliefert) stehen weiterhin u.a. zur Verfügung:
Wichtig für den Entwickler ist, dass sich die Werkzeuge den eigenen Bedürfnissen leicht anpassen lassen, da sie jeweils im Quelltext mitgeliefert werden.
Genauso wichtig sind Rahmenwerke, die ebenfalls in der Klassenbibliothek von VisualWorks mitgeliefert werden. Als wichtigstes ist hier das Rahmenwerk für Benutzeroberflächen zu nennen. Es beruht auf dem Entwicklungsmuster (design pattern) Model-View-Controller (MVC). Hierdurch wird die Funktionalität der Applikation von der Oberflächengestaltung und Behandlung von Benutzerinteraktion getrennt. Das Muster MVC wird z.B. in [GHJV95] genau beschrieben. Eine Smalltalk-spezifische Erklärung befindet sich in [ABW98] oder in [Howard95]. Eine nicht mehr ganz aktuelle Beschreibung ist online verfügbar.
Mit den Browsern wird in der umfangreichen Klassenbibliothek gesucht, Methoden- und Klassendefinitionen werden angezeigt und erstellt bzw. modifiziert. Im folgenden Bild ist die Methode factorial zur Fakultätsbestimmung einer ganzen Zahl dargestellt:
Zu bemerken ist, dass die farbliche Markierung von Kommentaren (blau) und lokalen Variablen (grün) durch den Benutzer anpassbar ist und durch das Hilfsmittel ColorEditing bereitgestellt wird, es wurde also ein mit VisualWorks mitgeliefertes Werkzeug den eigenen Bedürfnissen angepasst.
Neben dieser elementaren Art des Quelltextanzeige besteht die Möglichkeit, alle Aufrufstellen einer Methode bzw. sämtliche (polymorphen) Implementierungen einer Nachricht anzusehen. Alle Stellen, an denen z.B. die Nachricht update:with:from: gesendet wird, werden im »Senders-Browser« dargestellt, dies ist das zugehörige Bild. In diesem ist die Quelltextdarstellung so, wie sie von VisualWorks vorgesehen ist, also ohne Verwendung von ColorEditing.
Eine der polymorphen Implementierungen der Methode ifTrue: ist im folgenden Bild dargestellt.
Es handelt sich hierbei um die Implementierung einer Kontrollstruktur. Jeder Wahrheitswert (wahr oder falsch) ist Instanz einer Unterklasse von Boolean und soll auf die Nachricht ifTrue: reagieren können. Hierfür wird in der Oberklasse Boolean nur die Existenz einer derartigen Methode gefordert, das konkrete Verhalten muss in den Unterklassen False (für den Wahrheitswert falsch) und True (für den Wahrheitswert wahr) implementiert werden.
Bereits an dieser Stelle sei gesagt, dass es zur Überprüfung solcher Forderungen »Existenz einer Methode, welche das Verhalten für eine bestimmte Nachricht spezifiziert« mindestens die beiden folgenden Werkzeuge gibt:
In der Klasse False ist folgende Implementierung zu finden:
ifTrue: alternativeBlock "Since the condition is false, answer the value of the false alternative, which is nil. This method is typically not invoked because ifTrue:/ifFalse: expressions are compiled in-line for literal blocks." ^nil
In der Klasse True ist entsprechend Folgendes zu finden:
ifTrue: alternativeBlock "Answer the value of alternativeBlock. This method is typically not invoked because ifTrue:/ifFalse: expressions are compiled in-line for literal blocks." ^alternativeBlock value
Dies Beispiel der verschiedenen Implementierungen von ifTrue: zeigt die typische Verwendung der Polymorphie in Smalltalk.
Alle Browser bieten die Möglichkeit zum Pretty Printing, d.h. Quelltext wird in eine ansprechende äußere Form gebracht. Richtlinien zur (ansprechenden) Formatierung von Quelltext können so sehr leicht und einfach realisiert werden. Auch hier bietet sich (natürlich) die Möglichkeit, eigene Wünsche durch Anpassung zu realisieren.
Das Canvas Tool dient mit seinen Begleitern Image Editor und Menu Editor zur einfachen Gestaltung von graphischen Benutzeroberflächen (graphical user interface, GUI).
In der im Bild links dargestellten Palette stehen verschiedene Widgets (Oberflächenelemente) zur Auswahl. Mittels drag and drop werden diese in die zu erstellende Oberfläche (im Fenster Unlabeled Canvas dargestellt) eingefügt.
Die Widgets werden durch VisualWorks bereitgestellt und sind vollständig in Smalltalk implementiert. Auch hier ist der gesamte zugehörige Quelltext in der VisualWorks-Klassenbibliothek zu finden. Dem Programmierer steht es frei, weitere Widgets für seinen persönlichen Bedarf zu erstellen oder anzupassen. Eine sehr detaillierte Anleitung befindet sich z.B. in [Howard95]. Eigenschaften und Attribute eines Widgets werden mit Hilfe des Properties Tool festgelegt.
Das Smalltalk-Archiv an der University of Illinois at Urbana Champaign stellt ebenfalls weitere Widgets bereit.
Die Darstellung und die Art und Weise der Bedienung eines Oberflächenelements wird in VisualWorks durch Policies geregelt. Hierdurch wird das Look & Feel (Erscheinungsform) einer Oberfläche nachgebildet. Nachdem die verschiedenen Policies ebenfalls in der Klassenbibliothek zu finden sind, ist es z.B. möglich, die Smalltalk-Applikation unter Linux genauso aussehen zu lassen, wie auf einem Macintosh.
Das Canvas Tool kann auf Wunsch sehr viele der für das Funktionieren der Benutzeroberfläche nötigen Methoden automatisch erzeugen. Diese Methoden haben dann zwar noch keinen Rumpf, es können jedoch keine Laufzeitfehler auftreten. Die Methodenrümpfe, welche das spezielle Verhalten festlegen, z.B. die Wirkung eines Mausklicks auf einen Knopf, müssen vom Programmierer erstellt werden. Es besteht jedoch nicht die Gefahr, dass eine Methode vergessen oder irrtümlich ein falscher Name verwendet wird.
Zur Gestaltung von Icons und sonstigen Bildern steht der pixelorientierte Image Editor zur Verfügung. Mit ihm können Icons aller Art sowie Graphiken für die Verwendung innerhalb der Benutzeroberfläche erstellt werden. Mit Hilfe der Capture-Funktion können Graphiken aus anderen Programmen bei Bedarf übernommen werden.
Zur Erstellung von allen Arten von Menüs dient der Menu Editor. Im folgenden Bild wird gerade das Fenstermenü des VisualWorks Launchers (der Schaltstelle für VisualWorks) bearbeitet. Auch hier erkennt man erneut, dass alle Elemente von VisualWorks durch den Anwender seinen eigenen Bedürfnissen angepasst werden können.
Die Spezifikation sämtlicher GUI-Elemente und Einstellungen erfolgt mittels »normaler« Smalltalk-Methoden. So ist der Entwickler nicht auf die angesprochenen Werkzeuge beschränkt. Vielmehr kann auch rein textbasiert eine Oberfläche definiert werden. Ob dies jedoch von Vorteil ist, muss jeder einzelne für sich selbst entscheiden.
Es besteht die Möglichkeit, die Oberfläche auch dynamisch zu modifizieren. So ist es möglich, in der eigenen Applikation dem Endanwender die Möglichkeit zu geben, die Oberfläche der Applikation seinen Wünschen anzupassen oder je nach Können und Zugriffsberechtigung verschiedene Funktionen dem Anwender (nicht) zur Verfügung zu stellen.
Für GUI-Elemente steht mit dem Resource Finder ein weiterer (spezialisierter) Browser zur Verfügung.
Jede Änderung innerhalb des Smalltalk-Entwicklungssystems sowie die Auswertung von Smalltalk-Anweisungen werden durch VisualWorks in einem sogenannten ChangeSet mitgeschrieben. Dies hat vor allem die drei folgenden Vorteile:
Im Falle eines Systemabsturzes (im weiteren Sinne) geht nichts verloren.
Für einen Systemabsturz im weiteren Sinne gibt es neben Stromausfall und Absturz des Betriebssystems (unter Linux praktisch nicht relevant) auch die Möglichkeit, dass das Smalltalk-System nicht mehr vernünftig bedienbar ist. Hierzu kann es kommen, wenn eine Systemklasse durch den Programmierer modifiziert wurde und dabei eine Auswirkung nicht bedacht wurde. Beispielsweise ist es denkbar, dass der Debugger den speziellen Bedürfnissen angepasst werden soll, und nun beim Aufruf des Debuggers ein Fehler auftritt. Dieser Fehler ruft nun einen neuen Debuggeraufruf hervor, der nun seinerseits den Aufruf-Fehler produziert, was einen erneuten Debuggeraufruf zur Folge hat, usw... Nach dem Neustart von VisualWorks können nun alle durchgeführten Änderungen (auch die noch nicht explizit mit dem Image abgespeicherten) restauriert werden.
Eine primitive Versionsverwaltung ist möglich.
Man kann verschiedene Varianten einer oder mehrerer Methoden vergleichen und bequem zwischen diesen hin- und herschalten. Genauso lässt sich auch die Evolution einer Klasse während der Entwicklung verfolgen. Entfernt man eine Methode aus dem System, weil man der Meinung ist, sie nicht mehr zu benötigen, und stellt sich dies als falsch heraus, so kann sie einfach wiederhergestellt werden.
Der ChangeSet liefert Unterstützung bei der Quelltext-Verwaltung. Der Entwickler kann sehr leicht feststellen, welche Klassen und Methoden er bearbeitet hat.
Es kann sowohl der Zeit- also auch der Speicherbedarf eines Testlaufs ermittelt werden. Als Beispiel soll hier die hundertfache Berechnung der Fakultäten von 1 bis 500 dienen. Hierzu wird die folgende Anweisung ausgeführt:
self profile: [100 timesRepeat: [(1 to: 500) collect: [ :i | i factorial]]]
Als Ergebnis erhält man (ohne die mögliche Angabe eines Schwellwerts zur selektiven Anzeige):
10634 samples, 1 milliseconds per sample, 114.079 seconds process time, 114.815 seconds real time. ** Tree ** 100.0 [] in TimeProfiler>>unboundMethod 100.0 Interval>>collect: 100.0 Interval>>do: 99.9 [] in Interval>>collect: 99.9 [] in [] in TimeProfiler>>unboundMethod 99.9 Integer>>factorial 93.0 LargeInteger>>* 6.0 primitives 0.9 SmallInteger>>* 0.9 Integer>>productFromInteger: 0.7 Integer>>digitMultiply:neg: 0.3 SmallInteger>>digitAt: 0.2 primitives 0.1 SmallInteger>>digitLength 0.1 LargePositiveInteger>>compressed 0.1 primitives 0.0 LargeInteger>>digitLength 0.0 Integer class>>new:neg: 0.1 ArithmeticValue>>negative 0.0 LargePositiveInteger>>compressed 0.0 LargeInteger>>digitLength 0.0 primitives 0.0 primitives 0.0 primitives 0.0 primitives 0.0 primitives 0.1 primitives ** Totals ** 93.0 LargeInteger>>* 6.0 Integer>>factorial 0.3 SmallInteger>>digitAt: 0.2 Integer>>digitMultiply:neg: 0.1 SmallInteger>>digitLength 0.1 ArithmeticValue>>negative 0.1 LargePositiveInteger>>compressed 0.1 LargeInteger>>digitLength 0.1 Interval>>do: 0.0 Integer class>>new:neg: 0.0 [] in [] in TimeProfiler>>unboundMethod 0.0 Integer>>productFromInteger: 0.0 SmallInteger>>* 0.0 [] in Interval>>collect:
Man sieht durch die Einrückung, wie die verschiedenen Methoden voneinander aufgerufen werden. Weiterhin erkennt man im am Ende aufgeführten kumulativen Ergebnis, wo es sich lohnen könnte, als Erstes mit der Optimierung zu beginnen.
Mit Hilfe des ReportGenerators lässt sich zum einen für eine Ansammlung von Klassen eine Dokumentation erstellen. Zum anderen können Konsistenzüberprüfungen durchgeführt werden.
Die erstellte Dokumentation beschreibt alle vorhandenen Methoden innerhalb einer Klasse. Hierzu werden die Methodenkommentare verwendet. Weiterhin werden von Unterklassen zu implementierende Methoden aufgeführt. Als Kennzeichen dient das bereits oben erwähnte self subclassResponsibility.. Außerdem werden die Oberklasse, etc. aufgeführt.
Die möglichen Überprüfungen beinhalten einfache Tests, z.B. ob alle referenzierten Variablen auch deklariert sind. Genauso können komplexere Tests durchgeführt werden: ob für eine gesendete Nachricht eine Implementierung vorhanden ist oder umgekehrt, ob es Methoden gibt, die überflüssig sind, weil sie nicht aufgerufen werden, usw.
Die Konsistenzüberprüfungen können mit Hilfe von SmallLint(ähnlich dem Lint-Checker für die Programmiersprache C) verfeinert werden. Hier wird der Programmierer unter anderem auf »klassische Smalltalk-Fehler« hingewiesen. Als Beispiel sei hierfür der Ausdruck 3 + 4 * 5 genannt. Entsprechend der Smalltalk-Syntax liegt implizit die Klammerung ((3 + 4) * 5) vor. Gemeint war aber vermutlich (3 + (4 * 5)). Ursache für das Problem ist die arme Syntax von Smalltalk. Die arithmetischen Funktionen + und * sind nicht in der Syntax der Programmiersprache festgelegt, sondern als herkömmliche Funktionen (Methoden) implementiert. Mit Hilfe einer polymorphen Implementierung können dann jedoch auch andere Objekte als Zahlen durch die Nachricht + verknüpft werden. (Die Frage der Semantik (Bedeutung) dieser Verknüpfung ist gesondert zu lösen!)
Vor allem im kommerziellen Bereich ist die Anbindung an eine Datenbank wichtig. Die Vor- und Nachteile einer Datenbank sowie die verschiedenen Datenbank-Kategorien sollen hier nicht weiter untersucht werden.
An dieser Stelle sei Gemstone als Beispiel für eine objektorientierte Datenbank mit direkter Schnittstelle zu VisualWorks genannt. Die nichtkommerzielle Version für Linux kann maximal zwei Klienten gleichzeitig bedienen und steht zum freien Download mit Dokumentation bereit. Nur am Rande sei erwähnt, dass das Datenbankmanagementsystem Gemstone/S für Smalltalk seinerseits in Smalltalk implementiert ist.
Weiterhin steht mit der ObjectLens ein Rahmenwerk für die Anbindung relationaler Datenbanken zur Verfügung. Mit dem Data Modeller werden Entsprechungen zwischen Tabellen der Datenbank und Smalltalk-Klassen definiert. Außerdem gibt es ein Werkzeug, mit dem Ein- bzw. Ausgabemasken für einzelne bzw. Kombinationen von mehreren Datensätzen leicht mittels Drag-and-Drop bzw. Mausklick erstellt werden können. Für Linux sind die Anbindungen an Oracle und Sybase von besonderem Interesse, da beide Datenbanken ebenfalls für Linux zur Verfügung stehen. Diese Anbindungen gibt es auch in einer nichtkommerziellen Version und stehen damit zum freien Download bereit.
Von mehreren Anbietern gibt es zusätzliche Rahmenwerke für Aufgaben im Zusammenhang mit Persistenz von Daten.
Im Folgenden werden einige weitere Rahmenwerke für VisualWorks genannt, welche es ebenfalls als nichtkommerzielle Versionen gibt.
Zur Darstellung von Geschäftsgraphiken (Torten- und Balkendiagramme, etc.) wird das Rahmenwerk BusinessGraphics bereitgestellt. Mit ihm lassen sich (fast alle) Geschäftsgraphiken durch simplen Methodenaufruf erzeugen. Der Programmierer braucht nur festzulegen, welche Diagrammart aus welchen Daten zu berechnen ist. Alles andere wird vom Rahmenwerk automatisch geleistet.
Nicht immer wird eine Applikation vollständig in Smalltalk geschrieben. Gründe hierfür können (neben anderen) die folgenden sein:
Zugriff auf eine Fremdbibliothek komplexer Spezialfunktionen.
Zeitprobleme bei sehr komplexen und umfangreichen Berechnungen. Für die meisten Anwendungen ist die Geschwindigkeit von VisualWorks mehr als ausreichend, nachdem in den letzten Jahren die Hardware auch immer leistungsfähiger geworden ist. Für umfangreiche Simulationsläufe z.B. kann es sich jedoch lohnen, die eigentlichen Simulationsberechnungen auszulagern, um Rechenzeit zu sparen.
In beiden Fällen soll auf externe Funktionalität zugegriffen werden. Hierfür steht mit DLL and C Connect ein weiteres Werkzeug für den Programmierer zur Verfügung. Es wird zunächst die Schnittstelle einer (dynamisch zu ladenden) Bibliothek (DLL) oder Funktion innerhalb von VisualWorks angegeben. Hierzu wird als eine Möglichkeit eine Interface-Klasse aus einem C-Header-File automatisch generiert. Soll nun die externe Prozedur bzw. Funktion aufgerufen werden, so sind die als Parameter zu übergebenden Werte aus Smalltalk-Objekten zu erzeugen. (Auch hierfür steht ein Rahmenwerk bereit.) Das evtl. vorhandene Funktionsergebnis wird nach dem Aufruf der Funktion auf analoge Art und Weise in ein Smalltalk-Objekt zurückverwandelt. Während die externe Funktionalität genutzt wird, kann optional die Smalltalk-Applikation weitere Dienste verrichten; der Aufruf ist nicht notwendigerweise blockierend.
In vielen Szenarien besteht der Wunsch, eine Applikation über ein Netzwerk mehrbenutzerfähig zu machen. Neben der Möglichkeit, mit Hilfe von Distributed Smalltalk verteilte Anwendungen zu erstellen, besteht die Möglichkeit, mit einem herkömmlichen Browser wie Netscape Communicator o.ä. auf einen Applikationsserver zuzugreifen. VisualWave stellt hierfür ein Rahmenwerk bereit. Die Smalltalk-Applikation arbeitet dann mit einem HTTP-Server zusammen. Der Anwender interagiert mit der Applikation via HTTP-Protokoll durch einen Browser.
Die Entwicklungsversion VisualWave Developer ist ebenfalls in einer nichtkommerziellen Version zum Download verfügbar.
Im Folgenden werden weitere, bislang noch nicht erwähnte nützliche Einstiegspunkte im World Wide Web in Verbindung mit Smalltalk bzw. VisualWorks genannt.
Die Programmiersprache Smalltalk ermöglicht es, Applikationen auf sehr hohem Abstraktionsniveau zu erstellen. Die sehr umfangreiche VisualWorks-Klassenbibliothek unterstützt hierbei. VisualWorks ist eine ausgereifte Softwareentwicklungsumgebung, welche die Effizenz des Entwicklers erhöhen kann.
S. R. Alpert, K. Brown, B. Woolf: The Design Patterns Smalltalk Companion; Addison-Wesley, 1998
K. Beck: Smalltalk Best Practice Patterns; Prentice Hall, 1997
T. Budd: An Introduction to Object-Oriented Programming; Addison-Wesley, 1991
E. W. Dijkstra: The Humble Programmer; Communications of the ACM, Volume 15, Number 10, 1972
B. Foote, R. E. Johnson: Reflective Facilities in Smalltalk-80; OOPSLA 1989, Online-Version
E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object Oriented Software; Addison-Wesley, 1995
A. Goldberg, D. Robson: Smalltalk-80, The Language and its Implementation; Addison-Wesley, 1983
T. Howard: The Smalltalk Developer's Guide to VisualWorks; SIGS Books, 1995
W. F. Opdyke: Refactoring Object-Oriented Frameworks; PhD Thesis, University of Illinois at Urbana-Champaing, 1992, Online-Version
D. N. Smith: Concepts of Object-Oriented Programming; McGraw-Hill, 1991