Abschlussbericht

PTAH: Prototypen-Werkstatt Softwaredefinitionswerkzeuge für Anwender 

Abschlussbericht des Teilprojektes B 

"Schließen der pragmatischen Lücke durch aktive 

Systemgestaltung seitens der Anwender“ 

Im Projekt 

„Implizite gesellschaftliche Anforderungen der Informatik an die 

partizipative Modellierung - technologischer Systeme und an Konzepte 

informationspädagogischer Aus- und Weiterbildung“ 

1 Einführung 

Ulrik Schroeder 

Praktische Informatik 

Juli 2000 

Problemlösungsansätze zur Systemgestaltung innerhalb der Informatik fließen 

zunehmend in Bereiche des Lebens und die Arbeitsorganisation ein. Der Umgang mit 

dem PC, das Programmieren von Endgeräten wie Videorekorder oder Handy oder die 

Informationsbeschaffung über das Internet sind typische Beispiele dafür, wie 

Vorgehensweisen, die ursprünglich für Informatiker entwickelt wurden, heute zu 

Alltagshandlungen werden. Die in der Informatik erfolgreichen Konzepte basieren aber auf 

Voraussetzungen, die nicht immer ohne weiteres auf jede Person übertragbar sind, sei es 

aufgrund der zugrundeliegenden Denkweisen oder des vorausgesetzten 

Ausbildungsniveaus. 

Das interdisziplinäre Projekt untersucht die Übertragbarkeit der Informatikmodelle auf 

andere gesellschaftliche Bereiche, insbesondere die Einbettung in die Arbeitsorganisation 

sowie die Notwendigkeit einer Adaption der Pädagogik, um diese Übertragung zu 

ermöglichen. 

2 Einordnung des Teilprojektes in das Gesamtprojekt 

Das Projekt wird im Arbeitsbereich „Arbeit-Bildung-Technik“ vom Zentrum für 

interdisziplinäre Technikforschung gefördert. Der Förderungszeitraum für das gesamte 

Projekt läuft von Oktober 1999 bis März 2002 (ggf. verlängert bis Ende 2002). 

Das Teilprojekt B „Schließen der pragmatischen Lücke durch aktive Systemgestaltung 

seitens der Anwender“ der Praktischen Informatik lief von Oktober 1999 bis Juli 2000, mit 

06.09.00 1

Ulrik Schroeder Praktische Informatik, TU Darmstadt 

dem Ziel, an ausgewählten Beispielen eine neue Softwareentwicklungsmethodik zu 

demonstrieren, die Anwender von Softwaresystemen vom ersten Moment des Projektes 

an der Entwicklung aktiv beteiligt. Durch die sehr kurzfristige Mittelzuteilung war es nicht 

möglich, alle drei Teilprojekte zeitgleich zu initiieren. Stattdessen bot sich an, eine 

gestaffelte Bearbeitung der Teilprojekte durchzuführen, indem das vorliegende Teilprojekt 

die Vision der Prototypgestaltung seitens der Anwender anhand von Referenzbeispielen 

konkretisiert und die dabei ermittelten Anforderungen an den Arbeitsprozess und die 

informationstechnischen Voraussetzungen an die Anwender definiert. Die anschließenden 

Teilprojekte untersuchen die Realisierbarkeit der dargestellten Vision vom Standpunkt der 

Arbeitsgestaltung und der informationspädagogische Prozesse, um auf die neuen 

Herausforderungen geeignet vorzubereiten 

Das Teilprojekt wurde als Vorläufer vor Start der anderen Teilprojekte konzipiert, da es 

über die vorgeschlagene partizipative Software-Technik neue Herausforderungen an 

Nicht-Informatiker stellt. Das Teilprojekt A prüft, ob und wie diese Herausforderungen in 

betrieblichen Prozessen aufgegriffen werden können. Es soll die Anforderungen an den 

partizipativen Software-Entwicklungsprozess auf der Grundlage der kritischen 

Bildungstheorie erforschen und für die Umsetzung in Vorgehensmodellen für die 

Informatik, für die Gestaltung von Lernumgebungen und für die Erstellung von 

Entwicklungswerkzeugen aufbereiten. 

Das Teilprojekt C beschäftigt sich mit der Entwicklung von Konzepten 

informationspädagogischer Weiterbildung und berührt damit Fragestellung der Aus- und 

Weiterbildung für die Anwender der vorgeschlagenen Entwicklungswerkzeuge. 

3 Ziele des Teilprojektes B 

Aktuell sehen alle aktuellen Vorgehensmodelle für objektorientierte Softwareentwicklung 

als Ergänzung eine funktionale Definition der Systemanforderungen in Form von 

Anwendungsfällen (Use Cases [Jacobsen99] bzw. Stories im xP [Beck99]) vor. Erst daran 

schließen die eigentlich objektorientierten Methoden an, um die funktionalen Aspekte zu 

analysieren und die an der Funktionsrealisierung beteiligten Objekte zu identifizieren. 

Daraus resultieren die statischen Klassenmodelle, die die Funktionalität des Systems auf 

Klassen verteilen. Die Klassenstruktur ist die Ausgangsbasis für die Implementierung, die 

sich leicht auf viele Entwickler verteilen und getrennt entwickeln lässt. 

Ein Problem der Analysephase besteht darin, dass die in der Informatik üblichen 

Notationen ungeeignet sind, um die resultierenden Modelle adäquat mit den zukünftigen 

Anwendern des Systems zu diskutieren. Auf der anderen Seite sind Anwender die 

kompetentesten Vertreter der Anwendungsdomäne und müssen exakt Auskunft über die 

benötigte Funktionalität des Systems und den Einsatzkontext geben. 

Als Ausweg schlagen wir vor, die Use Cases bzw. ihre Konkretisierungen, die Szenarien 

oder Stories möglichst lebendig, in der dem Anwender bekannten Weise zu 

dokumentieren. Die „natürlichste“ Repräsentation eines Ablaufes wird durch seine 

Simulation als ausführbares Programm erreicht. Daher schlagen wir vor, Stories der 

Systemverwendung in Form einfacher aber ausführbarer Szenarioprototypen 

durchzuführen. Wir vertreten ferner die These, dass Anwender und Entwickler 

gleichermaßen aktiv bei der Entwicklung der Szenariomodelle beteiligt sein müssen. 

Bislang obliegt einzig dem Entwickler die Hoheit über alle Modelle, während Anwender als 

passive Befragte oder Rezeptoren der präsentierten Modelle fungieren. Um ein 

symmetrischeres Verhältnis zwischen Anwender und Entwickler zu ermöglichen, muss 

2


der Anwender ebenfalls in die Lage versetzt werden, Modelle des Systemablaufs aktiv zu 

gestalten. 

Als Fernziel für zukünftige Projekte kann weitergehend angestrebt werden, dass 

Anwender selbständig ausführbare Systemszenarien gestalten und Entwickler ganz ohne 

Kenntnis der Entwicklungsdomäne das System auf der Basis der ausführbaren 

Spezifikation sowie ihrer Expertise in Entwicklungsmethoden und Architektur, dem Einsatz 

domänenspezifischer Softwarekomponenten oder Frameworks das System entwickeln. 

Die bisher aufgestellte Forderung, dass Informatiker sich immer vollständig in die 

Anwendungsdomäne einarbeiten oder in einer Domäne spezialisieren, ist mit der 

zunehmen Diversifikation von Domänen, die IT-Technik einsetzen und dem damit 

verbundenen Engpass an IT-Spezialisten, die sowohl die Informatiktechnik beherrschen 

als auch Spezialisten in Anwendungsdomänen sind, nicht aufrecht zu halten. 

Die kühne These, dass Anwender Prototypen ihrer Anwendung selbständig gestalten und 

dabei ausführbare Programme graphisch interaktiver, reaktiver Anwendungen selbst 

programmieren, muss Widerspruch auslösen. Besteht doch gerade in der 

Programmierung graphischer Anwendungen ein hoher Aufwand. Noch vor wenigen 

Jahren ergab eine Studie von Myers und Rosson, dass ca. 50 % des Gesamtaufwandes 

eines Softwareprojektes alleine für die Programmierung der graphischen 

Benutzungsschnittstelle notwendig war [MyersRosson92]. Wir vertreten die These, dass 

der rasante Fortschritt der Informatikkonstruktionswerkzeuge bereits heute eine 

Gestaltung interaktiver Anwendungen mit graphischen Benutzungsschnittstellen seitens 

interessierter Anwender ermöglicht. In unserer Lehrveranstaltung „Einführung in das 

Software Engineering“ lernen Studierende anderer Fachbereiche nach einer kurzen 

Einarbeitung und wenigen Vorlesungen über die Denkweise der Objektorientierung in 

wenigen Tagen die Bedienung graphischer User Interface Builder (GUI builder) und sind 

damit in der Lage, graphische Bedienschnittstellen in wenigen Stunden zu 

programmieren. 

Das Projekt ermöglichte eine erste Machbarkeitsstudie der geschilderten Vision, die einen 

Antrag an andere Förderungen vorbereiten sollte. Dabei wurden folgende Fragen 

untersucht: 

• Welche Problemklassen kann man nach dieser Vision spezifizieren? 

• Welche Funktionalität müssen die Werkzeuge für den Anwender bieten? 

• Wie muss die Benutzerführung gestaltet werden, um vollständige Spezifikationen zu 

erhalten? 

• Wenn der Prototyp und die generierte formale Spezifikation vorliegt, kann der 

Entwickler das System dann ohne weiteres fachliches Wissen realisieren? 

Die Untersuchungen wurden anhand kleinerer Systeme durchgeführt, wobei das 

Verhalten fehlender Werkzeuge durch manuelle Ausprogrammierung simuliert werden 

musste. Anhand der dabei erarbeiteten Referenzsysteme können die 

arbeitswissenschaftlichen und pädagogischen Fragestellungen im Anschluss untersucht 

werden, z.B.: 

• Könnte der Anwender mit geeigneten Werkzeugen Prototypen selbst herstellen und 

damit die Anforderungsdefinition selbst übernehmen? Das betrifft 

• die (pädagogische und psychologische) Konzeption der Rollen und Prozesse für 

die Prototypentwicklung und 

06.09.00 3


4 

• die erforderlichen Grundkenntnisse für die Werkzeugbenutzung. 

• Wie müssen die Werkzeuge gestaltet werden um für den Anwender mit 

entsprechender Grundausbildung geeignet zu sein? 

• Wie kann in einer Entwicklungsumgebung eine multimediale Lernumgebung integriert 

werden, um 

• die Konzepte, Denkformen und Methodik der durch den Anwender aktiv 

gesteuerten Softwareentwicklung anzuleiten? 

• des kontinuierlichen Lernens in den Prozess der Use-Case Spezifikation integriert 

werden? 

• Welche Vorbildung (IuK-Grundbildung oder doch Fachinformatiker) ist heute 

notwendig, um die Konzepte und Werkzeuge des Prototyping zu verstehen ? 

• Wie muss die Ausbildung in der Mathematik bzw. IuK-Grundbildung verändert werden, 

um den allgemeinen Zugang zu ermöglichen? 

• Wie kann das kontinuierliche (lebenslange?) Lernen im Umgang mit neuen Medien 

und IuK-Technolgien im Arbeitsprozess gefördert werden? 

• Welche Aufgaben verbleiben für den Moderationsprozess? 

4 Vorgehensweise 

Ausgangspunkt der Untersuchung bildete unsere These, dass die Funktionalität und 

Mächtigkeit heutiger Informatikentwicklungsumgebungen bereits ausreichen kann, um 

Anwender Szenarioprototypen mitgestalten zu lassen. Allerdings gibt es heute noch kein 

geschlossenes Werkzeug, das die vorgeschlagene Entwicklungsweise unterstützen 

würde. Im Rahmen dieses kleinen Projektes konnte natürlich kein komplexes 

Entwicklungswerkzeug erschaffen werden. Stattdessen untersuchten wir existierende, 

kommerzielle, visuelle Modellierungsumgebungen und versuchten diese – zum Teil etwas 

zweckentfremdet – einzusetzen, um die Prototypspezifikation mit den verschiedenen 

Werkzeugen partiell abzudecken. 

Die kleinen Systeme, die wir als Referenzbeispiele ausgewählt haben, erlauben die 

Untersuchung wichtiger Fragestellungen. Die im Projekt verfügbaren Mittel wurden 

eingesetzt, um die manuellen Überbrückungen bei der Erstellung der Prototypen zu 

finanzieren und die Ergebnisse anschaulich zu dokumentieren. Dabei wurde identifiziert, 

welche Aktionen durch eine Szenario-Werkstatt integriert unterstützt werden müsste. In 

der parallel durchgeführten Lehrveranstaltung „Virtuelles Softwarelabor“ wurden 

Erweiterungen für einige der eingesetzten Werkzeuge entwickelt, die den Prototyp- 

Designprozess mit den heutigen Entwicklungsumgebungen besser unterstützen und 

nachweisen, dass eine Spezialisierung der Entwicklungsumgebungen die 

Gestaltungsvision realisierbar machen. Außerdem haben wir anhand der 

Referenzbeispiele die Grenzen der Vorgehensweise ausgelotet. 

Die im Rahmen des Projektes ausgewählten Software-Entwicklungsumgebungen, die 

auch Möglichkeiten zur visuellen Modellierung bieten, wurden in Hinsicht ihrer 

Anwendbarkeit für einen Analyseprozess seitens der Anwender bewertet. Die Werkzeuge


umfassen auch zwei visuelle Modellierungsumgebungen, die den UML-basiert 

Entwicklungsprozess unterstützen 

• Rational Rose for Java 2000 [RationalRose], 

• TogetherJ 3.2 [TogetherJ] 

sowie unterschiedliche Java-Programmierumgebungen, die u.a. die visuelle Gestaltung 

der Benutzungsschnittstellen ermöglichen: 

• IBM Visual Age for Java 3.02 Early Adopters Version for Java 2 Support, 

[VisualAge] 

• Inprise Jbuilder 3.0, [Jbuilder] 

• Sun JavaStudio 1.0 [JavaStudio] 

• Sun Forté for Java 1.0 Beta, [Forté] 

• Monasch University BlueJ 1.0.2 [BlueJ]. 

Da die Entwicklungsumgebungen für unterschiedliche Zwecke entworfen sind, bieten sie 

zum Teil recht unterschiedliche Modellierungsmöglichkeiten, die sie auf der anderen Seite 

auch unterschiedlich stark in ihrer Ausdrucksmächtigkeit beschränken. Im Vorfeld muss 

festgehalten werden, dass natürlich keine der untersuchten Umgebungen, den avisierten 

anwenderbetriebenen Analyseprozess optimal unterstützt, da die Werkzeuge 

überwiegend für Informatiker und professionelle Softwareentwicklung konzipiert sind und 

dementsprechend hohe Anforderungen an die Vorkenntnisse der Anwender stellen. Uns 

ging es vielmehr darum nachzuweisen, dass existierende Konzepte vielversprechende 

Ansätze bieten, die aber noch integriert und aufeinander abgestimmt werden müssten. 

Um die Problemklassen interaktiver Softwaresysteme zu klassifizieren wurden mehrere 

Referenzbeispiele erarbeitet. 

• Taschenrechner (kleines Beispiel eines Windows Tools) [Rechner] 

• Bibliotheksverwaltung [Bibliothek] 

• Finanzdienstleistungen (Aktientransaktionsmanagement), [Broker] 

• Gebäudeautomation (Steuerung multimedialer Konferenzräume) [ConGo] 

• Unfallaufnahme der Polizei [Unfallaufnahme] 

• Lernumgebung für Mathematikunterricht am Gymnasium [Imat] 

Die Realisierung der Referenzbeispiele konnte mithilfe der kommerziellen 

Entwicklungswerkzeuge nur unvollständig erfolgen. Daher mussten fehlende Bestandteile 

in Java ausprogrammiert werden. Der größte Aufwand entstand bei der Modellierung 

funktioneller Prototypen mit den rein visuellen Programmierumgebungen, da ihre 

Ausdrucksmächtigkeit zu stark beschränkt ist, sowie vor allem bei der anschaulichen 

Dokumentation der Ergebnisse. 

Die Dokumentation sollte die heute noch ungewöhnliche Vorgehensweise als Prozess der 

Erstellung der Szenarioprototypen nachvollziehbar machen. Daher wurde sie als 

06.09.00 5


Hypertext entworfen und enthält Animationen der resultierenden Prototypen und Verweise 

auf die erstellten Javaprogramme. Im folgenden sind die Ergebnisse auch statisch in 

diesem Dokument dargestellt, eine bessere Nachvollziehbarkeit ist aber durch die online 

Version gegeben [ptah] 1 . 

Aus pädagogischer Sicht ist im folgenden zu untersuchen, welche Informatikgrundbildung 

für die selbständige Modellierung von Use-Case Prototypen gestellt werden muss und 

welcher Lernaufwand dann während der Modellierung entsteht. Dazu sollten die 

Einarbeitungszeiten in die Werkzeuge und das Vorgehen zur Modellierung von 

Anwendungsfall-Prototypen gemessen und protokolliert werden. 

5 Ergebnisse 

5.1 Kriterien für die Auswahl visueller Modellierungswerkzeuge 

Unsere Ausgangsthese besagt, dass das visuelle Komponieren graphischer 

Benutzungsschnittstellen mit modernen Informatikmodellierungswerkzeugen bereits heute 

derart automatisiert ist, dass das Erstellen ohne weitergehende Programmierkenntnisse 

erfolgen kann. Insofern haben wir die für die Referenzbeispiele ausgesuchten 

Entwicklungsumgebungen in erster Linie aufgrund ihrer graphischen 

Benutzungsschnittstellen-Editoren ausgewählt. 

Als schwierigste Frage war zudem zu untersuchen, welches Modell für die Spezifikation 

der Prototyp-Semantik herangezogen werden konnte. Daher entschieden wir uns für 

verschiedene Werkzeuge, die 

• das rein graphische Modellieren im Sinne einer Verschaltung von Grafikkomponenten 

(JavaStudio), 

• das Verbinden von Komponenten mit anschließender Auswahl der Bedeutung der 

Verbindung (VisualAge) und schließlich 

• das Ausprogrammieren der Reaktionen auf von Anwender ausgelöste Ereignisse 

(Forté for Java) . 

Als Nebenbedingung haben wir die Werkzeuge auf diejenigen beschränkt, die Java Code 

erzeugen, damit Anteile der Prototypen in den verschiednen Umgebungen gleichmäßig 

per Hand weiterentwickelt werden konnten und hierfür nicht verschiedene Ausdrucksmittel 

herangezogen werden mussten. Diese Werkzeugauswahl ermöglicht eine Diskussion der 

verschiedenen Erstellungsmöglichkeiten hinsichtlich 

• der Erlernbarkeit des Vorgehens, 

• der Realisierung der Prototypen und damit auch 

• der Grenzen der Ausdrucksmächtigkeit der verschiedenen Ansätze. 

Um die für eine ausführbare Szenario-Prototyprealisierung notwendigen 

Modellierungsschritte zu dokumentieren und das Vorgehen an konkreten Beispielen zu 

1 http://www.pi.informatik.tu-darmstadt.de/ptah-zit/ 

6


demonstrieren, haben wir unterschiedliche Referenzbeispiele ausgewählt und mit den 

verschiedenen Werkzeugen realisiert. Zusätzlich wurden die Beispiele in UML modelliert 

[RationalRose und TogetherJ], um die Übergänge der Ausführung der Szenarioprototypen 

zu den Sequenzdiagrammen der UML zu demonstrieren. 

5.2 Die PTAH 2 Entwicklungsmethodik 

Die folgenden Referenzbeispiele demonstrieren das anwendergesteuerte und 

validationsgetriebene Entwickeln interaktiver Anwendungen mit graphischer 

Benutzungsschnittstelle. Die Beispiele haben unterschiedliche Komplexität. Zunächst 

besprechen wir das Vorgehen und der Vergleich der Werkzeuge an einem einfachen 

Beispiel [Rechner], um anschließend an komplexeren Beispielen die Grenzen des 

Vorgehens und die Vor- und Nachteile der unterschiedlichen Entwicklungsmodelle 

darzustellen. 

Im folgenden stellen wir lediglich einen Teil der Entwicklungsschritte des jeweiligen 

Beispiels vor, um die anhand dieses Beispiels erarbeiteten und demonstrieren 

Untersuchungsergebnisse zu besprechen. Die vollständige Dokumentation der Beispiele 

ist wesentlich besser anhand der Projekt-Website [ptah] zu verfolgen, da dort auch 

Animationen zur Simulation der Programme und ihrer Entwicklungsschritte sowie 

Verweise auf die in Java realisierten Beispielkomponenten in verschiednen 

Entwicklungsstufen integriert sind. 

Als erstes Beispiel untersuchen wir anhand eines Taschenrechners, der die 

Grundrechenarten als einfache Windows-Anwendung realisiert, wie ein Anwender 

selbständig einen ausführbaren Prototypen für exemplarische Anwendungen des 

Programms erstellen kann. Der Taschenrechner wird als Postfix-Rechner realisiert, da 

sich die Angabe des anzuwendenden Operators auf die zuvor eingegebenen Operanden 

einfacher realisieren lässt, als der heute übliche Infix-Rechner, der ein komplizierteres 

internes Speichermodell benötigt. 

Abbildung 1 Postfix-Taschenrechner als graphisch-interaktive Windowsapplikation 

Als einfache Bedienelemente verwenden wir die Tastatur für die Zahleneingabe und als 

aktive Bedienelemente die Enter-Taste, um den im Display eingegebenen Operanden 

einzugeben sowie die Knöpfe +, -, * und /, die die jeweilige arithmetische Operation auf 

die beiden zuletzt eingegebenen Operanden anwenden und das Ergebnis der 

Rechenoperation im Fenster anzeigen. Im Laufe der Entwicklung des Taschenrechners 

hat es sich als praktisch erwiesen, zusätzlich einen Operandenzähler neben der Enter- 

Taste einzuplanen, um dem Anwender anzuzeigen, wie viele Operanden derzeit für 

Rechenoperationen zur Verfügung stehen. Die weiteren Ausbaustufen des Rechners 

deaktivieren zudem die derzeit nicht anwendbaren Funktionstasten, z.B. die + Taste, 

wenn kein oder nur ein Operand eingeben wurden. 

2 PTAH ist kein Akronym, sondern einer der drei Hauptgötter im „neuen Reich“ des alten 

Ägypten (neben Amun und Ra). Nach der Lehre des Ptah-Hotep steht Ptah für das Prinzip 

der Formgebung, der Schaffung all der mannigfachen, unendlich differenzierten Körper 

und Gebilde, die die Schöpfung hervorbringt 

06.09.00 7


Dieses Beispiel ist zugeschnitten auf die Ausdrucksmöglichkeiten von JavaStudio und 

wird zum Vergleich ebenfalls in Forté und VisualAge realisiert. Dieses Beispiel nutzen wir, 

um die PTAH-Vorgehensweise ausführlich zu beschreiben und abschließend einige von 

uns im Projekt entwickelte Hilfsmittel vorzustellen. 

5.2.1 PTAH Vorgehensweise bei der Erstellung des Rechners 

Schritt 1 der Entwicklung des Taschenrechners besteht darin, sich über die gewünschten 

Funktionen des Programms klar zu werden. Dazu listet der Anwender zunächst 

ungeordnet auf, was mit dem Programm durchgeführt werden kann. Im Fall des 

Taschenrechners beschreibt er, dass er Zahlen eingeben und mit diesen rechnen möchte. 

Als Rechenoperationen denken wir zunächst nur an die Addition, Subtraktion, 

Multiplikation und Division. Zu einem späteren Zeitpunkt können weitere 

Rechenoperationen (Trigonometrie, Quadrieren, Wurzelziehen, Logarithmen etc.) 

hinzugefügt werden. 

Schritt 2: Um die nur grob und informal skizzierten Rechnerverwendungen zu 

konkretisieren, zeichnen wir ein Bild, wie die Bedienung funktionieren soll. 

Schritt 3: Jetzt gehen wir daran, die funktionalen Anforderungen an das Programm zu 

strukturieren. Dazu überlegt sich der Anwender typische Verwendungsfälle des 

gewünschten Programms. Die erste Verwendung besteht darin, zwei Zahlen zu addieren. 

Als konkretes Beispiel legen wir fest, dass die Eingabe der Zahl 2 gefolgt von der Eingabe 

der Zahl 3 und anschließendem Auslösen der Addition den Wert 5 als Resultat der 

Addition in der Taschenrechneranzeige ergeben soll. Eine derart konkrete Beschreibung 

eines typischen Anwendungsfalls bezeichnen wir als Szenario, in diesem Fall das 

Additions-Szenario. 

Schritt 4: Diese textuelle Beschreibung des Anwendungsszenarios setzen wir als 

ausführbaren Prototypen um. Dazu erstellen wir mit JavaStudio zunächst eine 

Benutzungsschnittstelle, die die für dieses Szenario benötigten Bedienelemente enthält. 

Die Erstellung dieser prototypischen GUI kostete in JavaStudio ca. 3 Minuten Aufwand, 

da lediglich Standardelemente per Mausklick auf dem Fenster platziert und direkt bei ihrer 

Anordnung mit der Eingabe der Eigenschaften (z.B. Text der Beschriftung der Knöpfe) 

konfiguriert werden. Genaugenommen ist die GUI bereits „überdimensioniert“, da sie 

8


bereits Bedienelemente für die Subtraktion, die Multiplikation oder das Löschen der 

Anzeige enthält. 

Die visuelle Konstruktion beginnt mit der Konfiguration des Hauptfensters, in dem der 

Rechner laufen soll. Jegliche Anpassung der graphischen Elemente erfolgt in einem 

geführten Dialog und benötigt keine Programmierkenntnisse. 

Für das Fenster kann dessen Größe, Farbe, Titel etc. festgelegt werden. Während der 

Konstruktionsphase kann man sich ein Raster einblenden, an dem sich die auf dem 

Fenster platzierten Elemente ausrichten lassen. Als nächstes wählt der Anwender aus 

den bereitgestellten Bedienelementen eine „TextArea“ aus, die die Anzeige des 

Taschenrechners realisieren wird. 

Diese wird per Maus auf dem Hauptfenster platziert und wieder per Menü konfiguriert. 

Als weitere Eigenschaften werden Größe, Schriftart und Farbe der Anzeige festgelegt. 

06.09.00 9


Nach diesen Aktionen besteht unser Taschenrechner aus einem Hauptfenster mit 

Anzeigefeld in den festgelegten Größen und Farben. 

Als nächstes wählt der Benutzer eine Taste oder Knopf, den er unterhalb der Anzeige 

anordnet und mit enter beschriftet. Dabei lassen sich weitere Eigenschaften des 

Knopfes festlegen. 

Für die weiteren Bedienelemente reicht es, den bereits angeordneten enter-Knopf zu 

kopieren und beim Anordnen mit anderer Beschriftung („+“ und „C“) zu konfigurieren. 

10


Als Andeutung, dass weitere Bedienelemente für diesen ersten Szenarioprototyp nicht 

realisiert werden bringen wir zusätzlich die Beschriftung „etc“ an. 

Schritt 5: Jetzt sieht der Prototyp bereits so aus, wie der Taschenrechner, verhält sich 

aber noch nicht, wie erwünscht, da die Knöpfe noch keine Funktionalität aufweisen. 

Genau in der Art, wie die Semantik der Systeme beschrieben wird, unterscheiden sich die 

Entwicklungsumgebungen. In unserer ersten Realisierung mit JavaStudio definieren wir 

die Wirkung des Drückens des enter-Knopfes und des Additionsknopfes, indem die 

betroffenen Komponenten in einer Art Schaltung miteinander verbunden werden. 

JavaStudio bietet dafür ein Design-Fenster, in dem alle auf dem Hauptfenster 

angebrachten Komponenten per Icon und Beschriftung repräsentiert werden. Je nach Art 

der Komponente hat das Icon verschiedene Anschlussstücke, die miteinander verbunden 

werden können. Ein Ausgangsanschlussstück eines Icons löst zum Beispiel beim Drücken 

eines Knopfes ein Ereignis aus, das durch die Verbindung zu dem Eingang des 

Anzeigefeldes den dargestellten Text setzen kann. 

06.09.00 11


Da wir keine echte Rechnersemantik spezifizieren müssen, sondern lediglich das 

Verhalten des abgesprochenen Szenarios (2 + 3 = 5), reicht es, beim Drücken des enter 

-Knopfes die Anzeige zu löschen (in der im ersten Fall die 2, danach die 3 per Tastatur 

eingetragen wird) und beim Drücken des Additionsknopfes in der Anzeige den Wert 5 

erscheinen zu lassen. Dafür reicht es, den Ausgang des enter und des C-Knopfes 

zusammenzufassen und auf den „clear text“-Eingang der Anzeige zu schalten. Der 

Ausgang des Additionsknopfes wird mit dem Auslöseeingang einer Konstante (nicht 

visuelle Komponente) verbunden, deren Wert beim Auslösen durch Verbinden ihres 

Ausgangs mit dem „set text“-Eingang des Anzeigefeldes dargestellt wird. 

Mit diesem in ca. 5 Minuten produzierten Prototypen lässt sich das Szenario 2 + 3 = 5 (als 

Stellvertreter einer Testspezifikation für die einfache Arithmetik mit 2 Operanden) sofort 

durchspielen, ohne einen Compiler aufrufen zu müssen. In der Online-Dokumentation 

dieses Beispiels sieht man den Szenario-Prototypen in Aktion als eine Animation sowie 

den Prototypen als Applet zum Selbstdurchspielen des Szenarios. 

Schritt 6: Der Szenario-Prototyp zusammen mit den Verwendungsdaten (was muss der 

Benutzer eingeben und welche Ergebnisse erwartet er als Reaktion auf die Interaktion) 

spezifiziert genau das folgende Sequenzdiagramm, das aus dem Prototypen generiert 

werden kann 

12


Bedienung verdeutlicht, wie schnell man an die Grenzen der Semantikbeschreibung mit 

dem JavaStudio-„Verdrahtungsmodus“ stößt. Daher zeigen wir im folgenden das gleiche 

PTAH-Vorgehen unter Verwendung einer professionellen Java-Entwicklungsumgebung 

mit GUI-builder. 

Die ersten Schritte verlaufen analog zur PTAH-Spezifikation mit JavaStudio. Wir erstellen 

für jedes der gewünschten Szenarien zunächst GUI-Prototypen, die die für das Szenario 

benötigten Bedienelemente enthalten. Im folgenden betrachten wir bereits eine 

weiterentwickelte Version des Taschenrechners, der bereits alle Komponenten der 

endgültigen GUI enthält (und damit gleichzeitig für alle Szenarien dient). Das Auswählen, 

anordnen und konfigurieren der Bedienelemente erfolgt ähnlich wie in JavaStudio. 

5.2.2.1 Semantikspezifikation 

Wenn wir uns zunächst auf die einfache Version des Rechnerszenarios "2 + 3 = 5" 

beschränken, lässt sich der Prototyp innerhalb von ca. 5 Minuten realisieren. Allerdings 

muss in Forté die Reaktion auf das Aktivieren eines der Bedienelemente über den 

Eigenschaftseditor eingegeben werden. Zunächst wählen wir dazu im Layout-Editor die zu 

konfigurierende Komponente aus und gibt im assoziierten Eigenschaftseditor als Methode 

für die reaktion auf das Auslösen des Knopfes einen Methodennamen an. 

Um den auszuführenden Code zu programmieren, wechseln wir in der Programmiereditor 

und geben an, dass das Betätigen des enter-Knopfes die Anzeige des Rechners löscht 

(setText( null ) ). 

Da wir als Semantikspezifikation den Übergang zur Programmiersprache benötigen, liegt 

es nahe, anstelle der Konstanten für das Verhalten des Prototypen Ausdrücke für das 

Rechnen anzugeben. Dazu wählen wir bei der erweiterten Version des Rechners wieder 

die Komponente, für deren Aktivierung wir die Semantik in Java angeben wollen 

06.09.00 15


In diesem Moment erhalten wir den Eigenschaftseditor in einem zweiten Fenster. Mithilfe 

dieses Editors können wir Tabellengesteuert die Eigenschaften des Add-Knopfes 

verändern. Auf diese Weise geben wir dem Element z.B. seine Beschriftung " + " oder den 

Text, der erscheinen soll, wenn die Maus auf dem Knopf verweilt (ToolTipText). 

Allerdings muss man die Bedeutung der Eigenschaften kennen (also fast die 

Repräsentation der Komponente in Java kennen). 

Den gleichen Editor verwenden wir weiter, um die Semantik des Knopfes anzugeben. 

Dazu wählen wir den Reiter „Events“ und wählen den ersten Eintrag 

„actionPerformed“ (wieder aufgrund unserer Kenntnis, dass genau dieses Ereignis 

beim Drücken des Knopfes ausgelöst wird). 

16


Wir tragen als Reaktion auf das Drücken des Add-Knopfes den Namen einer Methode ein, 

die aufgerufen wird, sobald das Ereignis während der Programmausführung durch den 

Benutzer ausgelöst wird. Forté generiert den notwendigen Code, um die Methode beim 

Knopf anzumelden, damit dieser Aufruf immer automatisch erfolgt. Außerdem generiert 

Forté den Rahmen für diese Methode. Der Inhalt (also der Code der schließlich 

ausgeführt wird), muss aber noch in Java eingegebene werden. Durch Klicken des 

soeben eingegebenen Methodennamens im Eigenschaftseditor öffnet sich der 

Programmiereditor an der mit der Methode assoziierten Stelle. Die generierten und damit 

für den Spezifizierer unveränderlichen Code-Stellen werden ausgegraut dargestellt. Ein 

Kommentar weist darauf hin, an welcher Stelle der Code für die Reaktion programmiert 

werden muss. 

Um die Addition der zuletzt auf dem Stack gespeicherten Operanden durchzuführen, 

holen wir die Operanden vom Stack (pop( )-Operation), wandeln sie in eine 

Gleitpunktzahl um ( doubleValue( ) ) und speichern das Ergebnis der Addition in der 

Variable sum. Diesen neu errechneten Wert speichern wir als nächstes auf dem Stack 

(push( ) ). Damit ist das Resultat zugleich der nächste zur Verfügung stehende 

Operand für folgende Rechenschritte. Wenn nicht mehr zumindest zwei Operanden zur 

Verfügung stehen, werden die Knöpfe für die Rechenoperationen abgeschaltet. Am Ende 

zeigen wir das Ergebnis in der Anzeige des Taschenrechners an. 

06.09.00 17


An dieser Beschreibung wird deutlich, dass zur Realisierung dieser Operation das Modell 

des Rechners und die Namen all seiner Komponenten bekannt sein müssen, damit ich die 

Rechensemantik spezifizieren kann. Der resultierende Rechnerprototyp ist damit aber ein 

voll funktionstüchtiger Taschenrechner und nicht nur für die zuvor genannten Szenarien 

nützlich. Eine "Fehlbedienung" kann entsprechend abgefangen werden. Der Prototyp und 

eine Animationssequenz seiner Bedienung ist in der Online-Version [ptah] 3 dieses 

Berichtes einzusehen. 

5.2.3 PTAH-Rechnerspezifikation mit VisualAge 

Forté erzwingt die rein programmiersprachliche Angabe der Semantik des 

Szenarioprototypen. VisualAge bietet eine Zwischenversion der Spezifikationsmöglichkeit. 

Ähnlich zu JavaStudio lässt sich zumindest ein großer Teil der Semantik visuell durch 

Verbinden von Komponenten angeben. Allerdings gibt es wesentlich weitergehende 

Auswahlmöglichkeiten, welche Bedeutung eine Verbindung von Komponenten haben soll. 

Allerdings erfordert das Ausnutzen der unterschiedlichen Ausdrucksmöglichkeiten 

erheblich weitergehende Vorstellungen von Ablauf der Ereignisbehandlung in Java, da sie 

in VisualAge auf professionelle Java-Programmierer zugeschnitten ist. 

Die ersten Schritte verlaufen analog zur PTAH-Spezifikation mit JavaStudio oder Forté 

Wir erstellen für jedes der gewünschten Szenarien zunächst GUI-Prototypen, die die für 

das Szenario benötigten Bedienelemente enthalten. Für das Additionsszenario erstellen 

wir angeleitet durch den Class-Wizard und anschließend per Drag and Drop im visuellen 

GUI-Erstellungsmodus den Rechnerprototypen 

3 http://www.pi.informatik.tu-darmstadt.de/ptah-zit 

18


Als letzter Schritt der „actionPerformed“-Verbindung zwischen enter-Knopf und 

Anzeigefeld erfolgt die Auswahl, welche Aktion des Anzeigefeldes ausgelöst werden soll. 

Aus den verfügbaren Optionen wählen wir das Setzen des angezeigten Textes. Welcher 

Text im Anzeigefeld gesetzt werden soll, lässt sich wieder per Menü eintragen. Der Wert 

muss allerdings als Resultat einer Methode (enterAction_Value( ) ) eingetragen 

werden. 

Der rein visuell spezifiziert Additionsszenarioprototyp realisiert das gewünschte Verhalten. 

Allerdings muss für das Setzen des Wertes 5 entweder als Resultat der Addition der Wert 

im generierten Java Code der Methode plusAction_Value( ) eingetragen werden 

oder durch Doppelklick der Verbindung und Auswahl „Set parameters ...“ der Wert per 

Dialog spezifiziert werden. In beiden Fällen ist das Vorgehen nicht genauso einfach, wie 

die reine Verdrahtung bei JavaStudio, dafür aber entsprechend ausdrucksstärker. 

20


Analog zum Vorgehen mit Forté ist auch in VisualAge der Übergang zum Programmieren 

in Java fließend. Daher lässt sich gemischt visuell und programmiersprachlich der 

gesamte Rechnerprototyp realisieren. Für das einfache Additionsszenario müssen 

allerdings mindestens zwei "Speicherplätze" für die beiden Operanden angegeben 

werden, um deren Werte beim Drücken des Additionsknopfes aufzuaddieren und im 

Anzeigefeld darzustellen. Bereits diese Aktion erfordert beim visuellen Programmieren 

mehr Aufwand, als das Ausprogrammieren in Java, da man sich ein Modell überlegen 

muss, wie die Operanden gespeichert werden, die in der anschließend ausgelösten 

Rechenoperation verarbeitet werden. Beim Ausprogrammieren in Java, steht dem 

Programmierer für diesen Zweck die Standardklasse java.util.Stack zur Verfügung. 

5.2.4 Entwicklung des Taschenrechners mit BlueJ 

BlueJ ist eine Java-Programmierumgebung für Lernende der Programmiersprache Java 

und unterstützt die Erstellung und das Verstehen von Java Klassenstrukturen. BlueJ 

erlaubt die graphische Darstellung und das Editieren von Klassenstrukturen. Das 

Ausprogrammieren der generierten Klassenrahmen erfolgt im integrierten Texteditor und 

verlangt Java-Programmierkenntnis. Für PTAH ist das interaktive Austesten der Klassen 

interessant, nicht die Art der Erstellung der Anwendung. Im Gegensatz zu den 

Entwicklungsumgebungen JavaStudio, Forté und VisualAge eignet sich BlueJ daher nicht 

direkt als unterstützendes Werkzeug für die PTAH-Entwicklungsmethodik. Wir haben 

dennoch das Rechnerbeispiel in BlueJ entwickelt, um andere Übergänge, die das 

Verstehen von Informatiksystemen erleichtern zu demonstrieren und dabei zu diskutieren, 

welche Aspekte in eine PTAH-Entwicklungsumgebung integriert werden müssten. 

5.2.4.1 Das Rechnerbeispiel 

Angenommen die Klassenstrukturen der gewünschten Anwendung wurden durch die 

PTAH-Prototypen ermittelt. Als Resultat generieren unsere Werkzeuge UML- 

Sequenzdiagramme und damit auch die in der Anwendung benötigten Klassendefinitionen 

(lediglich die Schnittstellen und die durch die Sequenzdiagramme spezifizierte Semantik 

der Methoden). Dann kann BlueJ die resultierenden Klassenstrukturen darstellen und 

erlaubt das interaktive, fragmentarische Austesten der Klassen. 

Wir verzichten in diesem Beispiel auf die graphisch-interaktive Benutzungsschnittstelle 

des Taschenrechners und vereinfachen damit unsere Anwendung auf eine einzige 

06.09.00 21


Klasse, die die Rechnerfunktionalität realisiert. Um die Darstellung der Klassenstrukturen 

zu demonstrieren, haben wir zusätzlich die Schnittstellenspezifikation dieser Funktionalität 

als StackrechnerInterface programmiert. 

BlueJ stellt beide Klassen in UML Notation im Klasseneditor grafisch dar: Die Klasse 

Stackrechner erbt von der Schnittstellendefinition StackrechnerInterface. 

Nachdem diese Klassenstruktur angegeben wurde, kann man die generierten Klassen 

(bislang ohne Methoden) ausprogrammieren. Anschließend lassen sich die Klassen ohne 

zusätzliche Einbindung in ein Hauptprogramm oder eine grafische Bedienoberfläche 

austesten. Dazu erzeugt man sich ein Objekt des Stackrechners per Mausklick. 

Auf diesem Stackrechner-Objekt lassen sich alle in der Klasse implementierten 

Methoden aufrufen. Auf diese Weise kann man z.B. das Additionsszenario per Hand 

durchspielen. 

22


Ein anschließender Aufruf der Methode top( ) liefert das gewünschte Resultat. 

BlueJ demonstriert, wie das interaktive Austesten bestehender Applikationen graphisch 

unterstützt werden kann. Im Gegensatz zum hier gewählten Ansatz wollen wir in der 

PTAH-Umgebung Objekte nicht als Ovale darstellen, sondern stattdessen ihr durch die 

GUI-Prototypen spezifizierten Darstellungen repräsentieren. Außerdem ist es notwendig, 

die Beziehungen zwischen Objekten zu visualisieren, um ein Szenario durch das Aufrufen 

der Methoden nachzuspielen. 

5.2.5 Zusammenfassung der PTAH Vorgehensweise 

Am Beispiel der Entwicklung eines Taschenrechners wurde die PTAH Vorgehensweise 

der Spezifikation der Software durch den Anwender demonstriert: 

1. Der Anwender überlegt sich typische Verwendungsfälle und konkretisiert diese 

exemplarisch 

2. Er zeichnet Skizzen des Ablaufs für jedes der Szenarien und beschreibt das 

Systemverhalten informell 

06.09.00 23


24 

3. Anschließend realisiert er diese Skizzen als GUI-Prototypen mit einem grafischen 

Konstruktionseditor (Visual GUI Builder) durch Platzieren der benötigten 

Steuerungselemente in einem Fenster 

4. Dann spezifiziert er die Semantik für genau diesen Anwendungsfall mit konkreten 

Daten ebenfalls visuell, durch Verbinden und konfigurieren der grafischen 

Bedienoberflächenelemente sowie Verwendung bereitgestellter vorgefertigter 

Komponenten (GUI und Logik) 

5. Ggf. kommentiert er den Prototypen durch Anbringen von Annotationen auf gelben 

Zetteln (PostItBean), die er genau wie andere grafische Komponenten per Maus 

auf dem Fenster platzieren kann. 

6. Ggf. ergänzt er die Szenarien mit der schrittweisen Kommentierung jedes 

Durchführungsschritts, das auch den Kontext des Systemeinsatzes beschreibt 

(StateDisplayBean) 

7. Schließlich führt er das Szenario mit konkreten Werten mit seinem Prototypen aus 

und nimmt den Ablauf durch das Capture&Replay-Framework GUITesting auf 

8. Die Szenarioprototypen liefert er zusammen mit den Logdateien des Capture- 

Frameworks und den informellen Beschreibungen der Szenarien an das 

Entwicklungsteam aus 

In der Regel werden diese 8 Schritte durch den Anwender nicht alleine durchlaufen, 

sondern bereits von Entwicklern begleitet, die auf Bedarf beim Design der Prototypen 

helfen (aber vor Ort und zusammen mit dem Anwender) und insbesondere neue 

Komponenten für die grafische Komposition bereitstellen, falls diese nicht in der PTAH 

Komponentenbibliothek noch nicht existieren. Auf diese Wiese sollen nach und nach 

weitere nützliche Komponenten zur visuellen Prototypspezifikation entstehen. 

Insbesondere wäre zu untersuchen, ob domänenspezifische Spezifikationsbibliotheken 

entwickelt werden können, die große Teile der zu erstellenden Benutzungsoberflächen 

und der Anwendungslogik 

Zur Unterstützung dieser Vorgehensweise haben wir das Testspezifikationsgenerierungs- 

Framework GUITesting und eine Reihe PTAH-Komponenten zur visuellen Spezifikation 

entwickelt, die im im Zusammenhang mit den folgenden Referenzbeispielen beschrieben 

werden. 

5.3 Dokumentation weiterer Referenzbeispiele 

5.3.1 Bibliotheksverwaltung 

Die Bibliotheksverwaltung ist ein deutlich komplexeres Anwendungsbeispiel, das vor 

einigen Jahren als Software Engineering Projekt im Praktikum der Praktischen Informatik 

von einer Gruppe von 6 Studierenden über ein Jahr entwickelt wurde. Anhand dieses 

Beispiels, das aufgrund der allgemeinen Verständlichkeit der Anwendung (Verwalten von 

Büchern und Leihvorgängen etc.) ebenfalls ohne ausführliche Einführung und 

Dokumentation von jedem Leser verstanden und überschaut wird, können wir die 

Möglichkeiten und Grenzen der Entwicklungsumgebungen deutlich herausarbeiten.


In dem "Suchen"-Fenster kann der Benutzer links die Suchkriterien ausfüllen. Als Kriterien 

gibt es Autor, Titel, Stichwörter und Kategorie. Wenn der Benutzer auf "Suchen" drückt, 

werden auf der rechten Seite die Suchergebnisse angezeigt. 

Es kann ein Buch ausgewählt und durch Drücken von "Ausleihen" ausgeliehen werden. 

Es wird dann eine Meldung angezeigt, ob die Ausleihe erfolgreich war. 

Szenario 2: Der Login-Vorgang ist derselbe wie bereits beschrieben. Jedoch wird anstelle 

des "Suchen"-Fensters das Fenster zum "Stöbern" angezeigt (das muss dann vorher 

ausgewählt werden können oder man hat Konfigurationseinstellungen für das Programm). 

In diesem Fenster gibt es nur eine Liste mit den verfügbaren Kategorien. Durch 

Auswählen einer Kategorie werden die enthaltenen Unterkategorien bzw. die enthaltenen 

Bücher angezeigt. Dieses Fenster bietet ebenfalls die Funktion "Ausleihen" und zusätzlich 

die Funktion "Information": 

06.09.00 27


Die skizzierten Szenarien haben wir vergleichend mit JavaStudio, Forté und VisualAge als 

Szenarioprototypen visuell entworfen. Die Einzelschritte der Entwicklung und die 

animierte Darstellung der Verwendung der Prototypen sind auf der PTAH-Website 

ausführlich dokumentiert. Insbesondere diskutieren wir dort die unterschiedlichen Modi 

der visuellen Semantikspezifikation. Anhand des Beispiels konnten wir die in den 

folgenden Abschnitten dokumentierten Beobachtungen machen und 

Entwicklungsergebnisse erzielen. 

5.3.1.1 Bibliotheksszenarien mit JavaStudio 

Das Login zum System kann in anderen Systemen leicht wiederverwendet werden. Wir 

speichern den visuell „programmierten“ Login-Dialog als neue Komponente, die sich in 

anderen Anwendungen ohne weitere Programmierung direkt einbinden lässt. Um die 

notwendigen Anpassungen vorzunehmen, gibt es für diese Komponente die Möglichkeit, 

menügeführt z.B. den Titel des Fensters, dessen Größe oder Farben oder die 

Beschriftung der Knöpfe anzupassen. 

Die Semantik benötigt keine weiteren Angaben, da die Komponenten Textfeld und Knopf 

ihr Verhalten selbst mitbringen 

Der einfache Erstellungsmodus begrenzt die Anwendbarkeit von JavaStudio für 

Szenarien, die mehrere Fenster involvieren. Das Drücken eines Knopfes kann kein 

anderes Fenster öffnen. Dies muss in JavaStudio daher über mehrere voneinander 

unabhängige Prototypen simuliert werden, deren Übergang außerhalb des Prototypen 

kommentiert werden muss. 

28


5.3.1.2 Bibliotheksszenarien mit Forté 

Die Realisierung der Szenarien mit Forté erforderte für die Spezifikation der Semantik 

wieder den Übergang zur Java-Programmierung. Allerdings unterstützt die 

Entwicklungsumgebung den Übergang vom visuellen zum textuellen Programmieren sehr 

gut, da für jede Komponente, z.B. ein Knopf, zunächst mit der Maus angegeben werden 

kann, dass man eine Reaktion auf das Drücken des Knopfes angeben möchte. Daraufhin 

wird eine Methode in der richtigen Klasse generiert und auch der Aufruf dieser Methode in 

der Anwendung automatisch verankert. Durch Klicken der Komponente führt die 

Umgebung den Anwender an die richtige Stelle in der Klassendefinition und ein 

Kommentar weist daraufhin, an welcher Stelle schließlich die Semantik eingegeben 

werden muss. Diese Angabe erfolgt dann aber in der Programmiersprache Java. 

Diese Unterstützung nimmt dem Anwender bereits den größten Teil des 

Programmierverstehens ab, da die Schwierigkeit eher darin liegt zu erlernen, wie man 

Reaktionen auf Ereignisse in das Programm einbindet. Es ist erheblich leichter, nur das 

Öffnen eines anderen Fensters oder eines Datei-Auswahldialoges in Java 

aufzuschreiben, als die Konventionen der Ereignisbehandlung zu kennen. 

Zunächst wählen wir dazu im Layout-Editor die zu konfigurierende Komponente aus und 

geben im assoziierten Eigenschaftseditor als Methode für die Reaktion auf das Auslösen 

des Knopfes einen Methodennamen an. 

Um den auszuführenden Code zu programmieren, wechseln wir in der Programmiereditor 

und geben an, dass das Betätigen des enter-Knopfes die Anzeige des Rechners löscht 

(setText( null ) ). Der Editor führt und zumindest genau an die Stelle, an der der Code 

eingegeben werden muss und die für die Schnittstelle benötigten Angaben sind 

unveränderlich. Lediglich der Java-Code für die Reaktion auf das Auslösen des Knopfes 

muss noch in Java angegeben werden. 

In diesem Beispiel haben wir als Unterstützung der Kommunikation zwischen Anwender 

und Entwickler eine Komponente entwickelt, die es dem Anwender ermöglicht, an 

beliebigen Stellen seiner Anwendung Kommentare anzubringen. Diese PostItBean 

(benannt nach der analogen Verwendung der gelben Zettel) lässt sich wie die 

06.09.00 29


Komponenten grafischer Benutzungsschnittstellen mit der Maus auf dem Fenster der 

Anwendung platzieren. 

5.3.1.2.1 Komponente "Gelber Zettel" zum Anbringen von Notizen 

Die Komponente (JavaBean) realisiert so etwas wie einen gelben Zettel, auf dem Notizen 

angebracht werden können und der an der GUI befestigt werden kann. Diese 

Komponente gehört nicht zum eigentlichen Programm, sondern liefert Informationen über 

den GUI Prototypen. Gelbe Zettel können genutzt werden, um zu notieren, das bestimmte 

Aspekte im Prototypen weggelassen wurden oder nicht in der Form realisiert werden 

konnte, wie eigentlich vorgesehen. Gelbe Zettel können auch genutzt werden, um nichtfunktionale 

Anforderungen am Prototypen anzubringen oder um generelle Anregungen, 

Wünsche etc. anzubringen. Sie können außerdem die Diskussion der Prototypen 

zwischen verschiedenen Anwendern und/oder Entwicklern unterstützen. 

Beim Durchspielen des Szenarios fällt unser Anwenderin Anne z.B. auf, dass sie die 

Informationen zur Verfügbarkeit der Bücher nicht sofort wahrgenommen hat. Sie öffnet 

den bereits an der GUI platzierten gelben Zettel, um eine Notiz über zu verbessendes 

Layout anzubringen. Der Zettel signalisiert ihr, dass bereits 2 Anmerkungen zum 

Programm bestehen. 

Im Kommentierdialog kann Anne die bestehenden Anmerkungen lesen und/oder selbst 

Ihre Anmerkungen aufnehmen. Alle Anmerkungen werden mit Kürzel und Datum 

abgelegt. Die Komponente kann noch weiterentwickelt werden, um z.B. verschiedene 

Filter für die Anzeige der Kommentare zu definieren oder verschiedene Sortierkriterien 

oder auch Strategien (darf jeder alle Kommentare ändern/löschen oder nur seine eigenen) 

anzugeben. 

5.3.1.3 Bibliotheksszenarien mit VisualAge 

Anhand des mit VisualAge modellierten Beispiels erläutern wir in der Online-Version 

ausführlich die Vorgehensweise des Implementierens der Semantik durch Verbinden 

30


Um weitere Aktien ins Depot einzukaufen soll eine Liste verfügbarer Wertpapiere (gewählt 

nach Börsenplatz, Filter, ...) dargestellt werden. Zu jedem ausgewählten Wertpapier kann 

die zu erwerbende Stückzahl angegeben werden. Das Programm ermittelt daraus die 

Gesamtkosten. Umgekehrt kann auch der Gesamtpreis eingegeben werden und das 

Programm ermittelt daraus die zu erwerbende Stückzahl. 

Um Teile aus dem Depot zu verkaufen, muss der entsprechende Posten im Depot 

ausgewählt (markiert) werden und über die Funktion verkaufen ein Folgedialog initiiert 

werden, in dem die Stückzahl, ggf. der Börsenplatz und weitere Daten ausgewählt werden 

können. Hierfür fertigt der Anwender eine weitere Skizze an: 

34


Diese Szenarien wurden im Projekt wieder vergleichend mit JavaStudio und VisualAge 

entwickelt. Bei der JavaStudio-Lösung, die im Rahmen der Lehrveranstaltung „Virtuelles 

Softwarelabor“ als Abschlusspraktikum realisiert wurde, zeigte sich wieder deutlich, dass 

der Verdrahtungsmodus zwar schnell erlernbar ist, um kleine Interaktionsmöglichkeiten zu 

realisieren, dass realisitische Anwendungen auf diese Weise aber nur sehr umständlich 

zu simulieren sind. 

Während der Entwicklung der PTAH-Prototypen für die Broker-Anwendung mit VisualAge 

haben wir einige hilfreiche Spezifiktaionskomponenten entwickelt, die wir im 

Zusammenhang diese Beispiels vorstellen wollen. 

5.3.2.1 Das Daten-Bean 

Eigentlich reicht es für Szenarioprototypen, die im Ablauf vorkommenden Werte fest in 

den Prototypen einzuprogrammieren. Schwierigkeiten bereitet allerdings das Anzeigen 

von Listen. In unserem Beispiel wollen wir die im Depot verwalteten Wertpapiere in einer 

Liste (Textfeld mit mehreren Zeilen) anzeigen. 

Wir haben uns zur Erleichterung der schrittweisen Beispielentwicklung ein Daten-Bean 

geschrieben, dass die Namen und die Werte aller Aktien als Konstanten vorhält. Dieses 

Beispiel zeigt, wie die Konfiguration in einem Szenario darzustellender Werte über die 

Eingabe in Eigenschaftseditoren hinaus für Anwender erleichtert werden kann, indem 

Daten in einer Klasse beschrieben werden, die dann durch Verbindung mit der 

Darstellungskomponente den entsprechneden Wert zur Anzeige zur Verfügung stellt. 

Alternativ können auch Verbindungsbeans zu Datenbanken oder Tabellenkalkulationsdaten 

hergestellt werden können. Auf diese Weise können Anwender bei der Spezifikation 

ihrer Szenarien die Beispieldaten mit ihren gewohnten Werkzeugen (Texteditor, ...) 

angeben und aus dem Prototypen heraus ansprechen, indem sie lediglich Verbindungen 

zwischen dem DatenBean und der Anzeigkomponente herstellen. 

Dabei werden anstelle der fest einprogrammierten Aktiennamen die Texte aus 

entsprechenden Attributen des Datenobjektes ersetzt. 

06.09.00 35


5.3.2.2 Programmieren von Arithmetik in Java 

Analog lassen sich weitere Spezifikationsbeans einfach in VisualAge integrieren. In 

unserem Aktienbeispiel möchte der Anwender z.B. spezifizieren, dass sich der 

Gesamtpreis durch Multiplikation des aktuellen Preises mit der Stückzahl ergibt. Ohne 

Erweiterung müsste man hierfür den Übergang zur Java-Programmierung wählen. Bei 

derart einfachen Beziehungen ist dies auch zumutbar, da die Relation visuell spezifiziert 

und der dafür auszuführende Javacode von der Entwicklungszmgebung generiert wird. 

lediglich die Formel (Multiplikation der beiden als Funktionsargumente übergebenen 

Werte) müsste als Ausdruck in Java formuliert werden. Dies ist sehr leicht erlernbar, da 

die Formulierung von Ausdrücken der normalen mathematischen Schreibweise sehr 

ähnlich ist. 

In unserem Beispiel erstellen wir zunächst visuell die Verbindung zwischen dem Feld 

aktueller Preis und Gesamtpreis mit der Methode actionPerformed( ) (grüner Pfeil), 

die ausgelöst wird, wenn in das Aktuellpreisfeld ein Wert eingegeben wird. Als Argument 

der Methode spezifizieren wir den Wert, der im Textfeld Stückzahl steht (violette 

Verbindung zum grünen Pfeil). Analog gehen wir vor, um Änderungen im Feld Preislimit 

zu behandeln (zweite im Bild dargestellte Verbindung). 

36


5.3.3 Multimediaraumsteuerung: ConGo 

Das Multimedia-Konferenzraumsteuerungsprogramm ConGo wurde im Jahr 1998 im 

Rahmen des Software Engineering Praktikums der Praktischen Informatik von 7 

Studierenden im Auftrag der Instituts für Sicherheitstechnik SIT der GMD in Darmstadt 

entwickelt. Es handelt sich um ein relativ komplexes Anwendungsprogramm mit 

aufwendiger Architektur. Dieses Beispiel wurde gewählt, um nachzuweisen, dass auch 

aufwändige Beispiele, deren Analyse bei der realen Projektdurchführung von 7 

Studierenden fast ein halbes Jahr in Anspruch genommen hat, ebenfalls im PTAH- 

Vorgehen nachvollzogen werden kann. Allerdings erforderte die Bearbeitung mehr 

Einsatz als dies mit Projektmitteln möglich gewesen wäre, daher wurde das 

Referenzbeispiel wieder im Rahmen der Vorlesung und Übung „virtuelles Softwarelabor“ 

als Abschlussarbeit realisiert. 

Die Aufgabe bestand darin, für einen Multimedia-Konferenzraum eine Steuerung zu 

entwickeln, die es Vortragenden ermöglicht, verschiedene Präsentationsmedien 

einzusetzen. Die Ansteuerung der Geräte soll für den Anwender transparent geschehen. 

Auch das Einbringen neuer Geräte soll vom Programm unterstützt werden. Wichtigstes 

Designkriterium ist die einfache Bedienung am besten vom eigenen Laptop des 

Vortragenden aus. Daher wurden verschiedene Szenarien definiert, die über grafische 

und geführte Bedienfolgen vom Congo Client unterstützt werden. Der Congo Server 

analysiert die verfügbaren Geräte und realisiert die Verschaltung. 

5.3.3.1 Typische Anwendungsfälle für Multimediaraumsteuerungen 

• Projizieren von Folien 

• Zeigen von Dias 

• Projizieren des Computerbildschirms (zum Beispiel für eine PowerPoint 

Präsentation) 

• Abspielen von Audiodaten 

• Zeigen eines Videos 

• Audiokonferenz mit externen Konferenzteilnehmern 

• Aufbauen einer Videoschaltung zu externen Konferenzteilnehmern 

• Audioprotokoll einer Konferenz 

• Videoprotokoll einer Konferenz 

Die Software Congo prüft für jedes Szenario, welche Geräte im Raum zur Verfügung 

(angeschlossen, betriebsbereit, ...) stehen und welche Ein- und Ausgabemedien für den 

Vortrag benutzt oder zusammengeschaltet werden können und bietet hierfür spezifische 

Formulare (geführte Dialoge) an. Auf diese Weise reduziert Congo den Funktionsumfang 

der Geräte auf die meistgenuzten Basisfunktionen und erlaubt deren einfache Bedienung 

via Maus von einem Rechner aus. 

Im folgenden besprechen wir hiervon lediglich den Anwendungsfall "Zeigen eines Videos". 

06.09.00 39


3. dort statt Mikrofon den Videorecorder auswählen 

4. im Nachbarfenster die Lautsprecher "Groß" auswählen 

5. Szenario aktivieren, um die Geräte zu reservieren und die gewählte Konfiguration 

anzusteuern 

06.09.00 41


42 

6. Wiedergabe starten: das Video wird projiziert und über die Lautsprecher im Raum 

wiedergegeben 

7. auf Zwischenfrage: "Moment, ich konnte den letzten Satz nicht verstehen ..." die 

Vorführung anhalten 

8. Zurückspulen 

9. Lautstärke verstellen 

10. Testlauf, ob die Lautstärke jetzt o.k. ist 

11. Pause und Nachfrage 

12. Weiterabspielen 

13. Vorführung anhalten (fertig) 

14. Logout 

Das Szenario ist ein gutes Beispiel dafür, dass in Prototypen zusätzliche Semantik 

integriert werden muss. Es genügt nicht, allein die graphische Oberfläche zu modellieren: 

Wenn beispielsweise der "Play"-Knopf gedrückt wird, passiert auf der GUI überhaupt 

nichts. Der Anwender, der das System spezifizieren soll, muss hier zum Ausdruck bringen 

können: "jetzt läuft das Band". Genau für derartige Anforderungen haben wir das 

StateDisplayBean entwickelt, das in jeden Szenario-Prototypen intergriert werden 

kann, um jeden Schritt der Durchführung des Szenarios zu begleiten, dabei Erläuterungen 

des Einsatzkontextes zu geben und Anweisungen, welcher Schritt (Interaktion) als 

nächstes auszuführen ist. 

5.3.3.4 Die Kontexterläuterungskomponente StateDisplay 

In einer PTAH-Entwicklungsumgebung sollten dem Anwender Komponenten zur 

Erleichterung der visuellen Spezifikation in Form von Beans zur Verfügung stehen. Dies 

können insbesondere Funktionalitäts-Komponenten, etwa zum Modellieren sequentieller 

Abläufe, sein (dokumentiert im Beispiel IMAT). 

Wir haben den Prototyp des Referenzbeispiels ConGo! um eine Kommentar-Bean 

ergänzt, welche den aktuellen Status des Szenarios anzeigt. Daher haben wir sie auf den 

Namen StateDisplay getauft. Wie bereits im Abschnitt zur Erläuterung des 

Referenzbeispiels erwähnt, ist die Darstellung zusätzlicher Semantik in diesem Fall ein 

erhebliches Problem. Woran erkennt man beim Durchlaufen des Szenarios, das eine


Audiowiedergabe läuft oder dass jemand aus dem Publikum eine Frage stellt? Bei dem 

erweiterten Prototyp wird dies durch die StateDisplay-Bean folgendermaßen dargestellt. 

Die StateDisplay-Bean ist ein zusätzliches Fenster, das während des Ablaufs des 

Szenarioprototyps ständig angezeigt wird. Der aktuelle Zustand wird dabei im 

StateDisplay-Bean durch eine natürliche Zahl kodiert. Den Text, der in einem bestimmten 

Zustand angezeigt werden soll, kann man über die Methode setMessage(int, String) 

setzen. Dies wird für das ConGo!-Szenario in der initialize( )-Methode erledigt, also durch 

Java-Code. Für die PTAH-Entwicklungsumgebung müsste hier ein zusätzlicher Editor die 

textuell-grafische Spezifikation des Ablaufes unterstützen. 

Das Umschalten zwischen den Zuständen erfolgt visuell. Hierfür stellt die Bean zwei 

Methoden zur Verfügung. Mit goToStateIfNext( int ) wird in den durch die Integer-Zahl 

angegebenen Zustand gesprungen, falls sich die StateDisplay-Bean gerade in dem 

Zustand unmittelbar davor befindet. Ansonsten erfolgt keine Änderung. 

Beispielsweise ist von dem "+"-Knopf der Tonsteuerung aus eine Linie zur StateDisplay- 

Bean gezogen, durch die bei einem "actionPerformed" auf dem Knopf der Methodenaufruf 

"goToStateIfNext( 7 )" erfolgt. Wenn sich die Bean im Zustand 6 (Message: "Lautstärke 

erhöhen...") befindet und der "+"-Knopf gedrückt wird, so springt sie in den Zustand 7 

("Das sollte genügen. Wiedergabe erneut starten..."). Falls der "+"-Knopf zu einem 

anderen Zeitpunkt (in einem anderenn Zustand) gedrückt wird, hat dies dann keine 

Wirkung. 

Zusätzlich gibt es die Möglichkeit eines unbedingten Sprungs mit goToState( int ), wovon 

im Beispiel allerdings in unserem Referenzbeispiel kein Gebrauch gemacht wird. Die 

Abfolge der Zuständen mit den dazugehörigen Texten und den Übergangsereignissen ist 

für das Referenzbeispiel in dem folgenden Diagramm dargestellt. 

06.09.00 43


Wie man sieht, können einzelne Ereignisse mehrere Zustandsübergänge auslösen. Vom 

Wiedergabe-Knopf etwa gehen drei Verbindungen zum StateDisplay-Bean aus. Wenn 

allerdings dieselbe Komponente zwei aufeinanderfolgende Übergänge auslösen soll, 

kommt es zu Problemen. 

5.3.4 Verkehrsunfallaufnahme 

Zurzeit laufendes Software Engineering Projekt, das im Auftrag der Firma tim (Traffic 

information management) in Kooperation mit der Hessischen Straßen- und 

Verkehrsverwaltung sowie der Polizei entwickelt wird. Es handelt sich um ein 

webbasiertes Programm zur Aufnahme von Unfallanzeigen durch die Polizei sowie der 

44


Visualisierung von Unfalldaten, das eingebettet ist in ein System zur Sicherheit im 

Straßenverkehr (stim - safety ) ist. 

Im Rahmen einer effizienten Verkehrssicherheitsarbeit wird es zukünftig verstärkt darauf 

ankommen, Verkehrs- und Unfalldaten zeitnah bereitzustellen und qualitativ hochwertig 

zu aggregieren. Im wesentlichen beinhaltet dies, straßen- und netzbezogene 

Verkehrssicherheitsdefizite zu identifizieren, auf Plausibilität zu prüfen, gezielt 

Bewertungsgrundlagen bereitzustellen und für Entscheidungsprozesse Informationen auf 

der Grundlage grafischer Darstellungen transparent aufzubereiten. Die Hauptziele eines 

derartigen Informationsmanagements lassen sich dahingehend zusammenfassen, bei 

aufgabenunabhängig variabler Informationstiefe und Informationsschärfe die Flexibilität 

bei der Bearbeitung zu erhöhen, Arbeitsabläufe zu verkürzen bzw. die Anzahl der 

Arbeitsschritte zu reduzieren und bei der Ergebnispräsentation Sachverhalte verständlich, 

überschaubar und eindeutig darzustellen. Durch eine öffentlichkeitsgerechte und im 

Internet verfügbare Aufbereitung sollen Verkehrsteilnehmer sensibilisiert werden. 

Bisher steht dafür nur ein unzureichendes Instrumentarium zur Verfügung. Für eine 

Bewertung des Unfallgeschehens bzw. die darauf aufbauende Visualisierung 

sicherheitsspezifischer Informationen müssen die Daten aufwendig und oft mit größerem 

Zeitverzug weiterverarbeitet werden. Infolge der technischen Randbedingungen und der 

Komplexität vieler Aufgabenstellungen (Verknüpfung mehrerer Datenbestände) ist eine 

online-Bearbeitung bisher nicht möglich. Es fehlen Konformität und Schnittstellen zur 

aktuellen Entwicklung der Straßeninformationsbank Hessen 

Für den Aufbau eines Informations- und Managementsystems zur Verarbeitung und 

Visualisierung von Unfalldaten ergeben sich insbesondere folgende Anforderungen: 

• Übernahme, Plausibilitätsprüfung und Abspeicherung der Unfalldaten in einer 

Datenbank einschließlich Fortführung und Korrekturmöglichkeiten. 

• Statistische Auswertung der Unfalldatenbank (Listen, Unfallkenngrößen, 

Berechnungen...) differenziert nach Anforderungen von Straßen- und 

Verkehrsverwaltung sowie Polizei. 

• Visualisierung des Unfallgeschehens (Unfalldiagramme, Unfallsteckkarten). 

• Geocodierung und Darstellung der Unfälle mit einem geografischen 

Informationssystem. 

• Konzeption zur Datensicherheit. 

• Internet-Technologie 

Aus diesen Anwendungsfällen haben wir uns einige Szenarien ausgesucht, die direkte 

Benutzerinteraktion erfordern (im Gegensatz zur Konsistenzanalyse der Daten in der 

Datenbank). Dies betrifft vor allem die Unfallaufnahme und Visualisierung der Unfalldaten. 

Das Layout des bisherigen Formulars für Verkehrsunfallanzeigen (Papierversion) soll 

dabei als Vorgabe übernommen werden. Aus diesen Verkehrsunfallanzeigen lassen sich - 

sofern diese vollständig ausgefüllt sind - Unfallort, Unfallzeitpunkt und Unfalltyp auslesen. 

Somit ist es möglich, Unfälle und Unfallhäufungspunkte (mit einem entsprechenden 

Mapping-Tool) auf einer Straßenkarte darzustellen, und durch Anklicken eines 

Unfallpunktes auf dieser Straßenkarte die entsprechenden Daten zum jeweiligen Unfall zu 

bekommnen. 

06.09.00 45


Um sich zunächst einen Überblick über das zu realisierende System zu geben, 

beschreiben die Anwender typische Anwendungsfälle (Use Cases) mit den vier Aktoren 

Administrator, Benutzer, Polizist und Verkehrssachbearbeiter. 

Aus diesen Use Cases haben wir konkrete Szenarien mit skizziert und mit JBuilder 

realisiert 

46 

1. Ein Polizist nimmt eine neue Unfallanzeige auf 

2. Eine bestehende (unvollständige) Anzeige wird weiter bearbeitet 

3. Auswahl gespeicherter Unfallanzeigen anhand verschiedener Kriterien


4. Plausibilitätsprüfung während der Eingabe 

5. Kategorisierung von Unfällen (Verkehrssachbearbeiter) 

6. Benutzerverwaltung (Adminstrator) 

7. Anzeigen von Unfallsteckkarten 

8. Auswahl von Unfallanzeigen durch Klicken in der Karte 

Die einzelnen Entwicklungsstufen und Realisierung der Szenarien sind in der Online- 

Version nachzulesen. Das Beispiel erbrachte gegenüber den anderen Studien keine 

neuen Erkenntnisse, da die ursprünglich beabsichtigte Beteiligung realer Anwender 

06.09.00 47


(Polizisten) bei der Erstellung der Prototypen aus Zeitgründen bei der Polizei nicht 

zustande kam. 

Die Beispiele wurden mit Jbuilder implementiert. Ähnlich wie bei dem Vorgehen mit Forté 

muss zur Angabe der Semantik Java-Code programmiert werden, der mithilfe eines 

Konfigurationsmenüs als Reaktion auf das Auslösen eines Ereignisses durch ein 

Interaktionselement, das grafisch erstellt werden kann, integriert wird. 

5.3.5 Mathematik-Lernprogramm IMAT 

Das Beispiel IMAT sollte die Möglichkeit ausloten, inwieweit Anwender selbständig nicht 

nur Szenarioprototypen entwickeln können, sondern das gesamte Softwaresystem nach 

der PTAH-Vorgehensweise selbständig realisieren. Als Beispiel haben wir den Fall eines 

Mathematiklehrers gewählt, der zur Unterstützung des Mathematikunterrichts ein 

Programm zur Definition, Analyse und Visualisierung mathematischer Funktionen 

benötigt. 

Wir haben diesen Fall gewählt, da 

• das Anwendungsgebiet mathematische Funktionen eine Spezifikation erfordert, die 

relativ nahe an den Ausdrucksmitteln heutiger Programmiersprachen liegt. 

• ein Mathematiklehrer im Umgang mit dem Rechner und den Ausdrucksmitteln und der 

Modellierung einigermaßen vertraut ist. 

Die Umsetzung des Beispiels erfolgte wiederum im Rahmen der Lehrveranstaltung 

„virtuelles Softwarelabor“. Während der Realisierung entwickelten wir weitere PTAH- 

Komponenten als Erweiterung der VisualAge-Programmierumgebung, um das rein 

visuelle Spezifizieren weitergehend zu unterstützen. 

5.3.5.1 Die Sequenzkomponente 

Häufig soll als Reaktion auf ein durch Benutzerinteraktion ausgelöstes Ereignis mehrere 

Aktionen des Programms folgen. Grundsätzlich kann man dies in VisualAge dadurch 

realisieren, dass von der Ereignisquelle – z.B. einem Menüpunkt „Integrate“ – mehrere 

Verbindungen zu anderen Komponenten – z.B. einem Anzeigefeld, der 

Statusanzeigezeile und einem neu zu öffnenden Fenster – hergestellt werden. Der 

Nachteil dieser Modellierung besteht darin, dass dabei nicht notwendigerweise die 

Sequenz, also die Reihenfolge, in der diese Aktionen ausgeführt werden sichtbar wird. 

48


Wenn man stattdessen die Reihenfolge explizit machen möchte, z.B. weil bestimmte 

Initialisierungen vor dem Öffnen eines neuen Fensters erfolgen müssen, benötigt man ein 

entsprechendes Ausdrucksmittel. Wir haben hierfür die Anweisungskomponente 

Pinstruction entwickelt, die eine Aktion auslöst und eine optionale Verbindung zur 

automatisch danach ausgelösten Interaktion anbietet. Die im oberen Diagramm 

dargestellte Interaktion mit der Anweisungskomponente macht die Reihenfolge der 

Ereignisbehandlung explizit: 

06.09.00 49


5.3.5.2 Die bedingte Ausführungskomponente 

Eine weitere praktische visuelle” Programmierkomponente ermöglicht das Auslösen einer 

Reaktion auf eine Benutzerinteraktion in Abhängigkeit einer Bedingung. Welche Reaktion 

erfolgt wird entschieden, indem zunächst eine Bedingung ausgewertet und anschließend 

die reagierende Komponente bestimmt wird. Das PifThenElse haben wir verwendet, 

um im Prototypen einen geführten Dialog mit dem Anwender zu realisieren (Wizard), der in 

Abhängigkeit gesetzter Auswahlwerte (z.B. RadioButtons) unterschiedliche 

Folgedialoge auswählt. Um einen derartigen Wizard visuell zu spezifizieren, muss das 

Drücken des OK-Knopfes in Abhängigkeit der eingestellten Konfiguration unterschiedliche 

Folgeinteraktionen auslösen. 

50


Die IfThenElse-Komponente bietet zwei Eingänge (das Auslösen der Aktion und die 

dann auszuwertende Bedingung) und drei Ausgänge für die beiden alternativ 

auszulösenden Reaktionen und die optionale Folgeaktion. 

06.09.00 51


5.3.5.3 Auswertung von Ausdrücken 

Es gibt zahlreiche Anwendungen bei der Erstellung von Szenario-Prototypen, bei denen 

ein Ausdruck ausgewertet werden muss, der dann z.B. als Argument für eine Methode, 

die auf ein Ereignis reagiert verwendet wird. Im Taschenrechnerbeispiel haben wir für 

bestimmte Szenarien z.B. die Resultatwerte als Konstanten für die Darstellung im 

Anzeigefeld eingesetzt, um uns die Realisierung echter Rechenoperationen zu ersparen. 

Im IMAT Szenarioprototyp sollen z.B. der Funktionsname und die Funktionsdefinition mit 

den Werten „f“ und „2x 2 - 2“ verglichen werden. Um diesen Vergleich visuell zu 

spezifizieren, benötigt man zum einen die Darstellung von Konstanten (im Bild StringF 

und StringX_2_2X) und zum anderen die visuell verwendbare Vergleichsoperation 

(PEquality). Wir haben mehrer solcher Ausdrucks-Komponenten realisiert, die das 

visuelle Rechnen mit arithmetischen und logischen Werten ermöglichen. 

52


5.3.5.4 Vorgefertigte GUI Komponenten 

Schließlich ist es iin einer PTAH Entwicklungsumgebung sinnvoll wiederverwendbare 

Dialog-Komponenten bereitzustellen. Diese können entweder zu komplexeren 

Benutzungsoberflächen zusammengesetzt werden (anlog zu den beritstehenden 

primitiven Grafikelementen) oder aber vollständig direkt als Szenarioprototyp verwendet 

werden, indem evtl. nur eine kleine Konfiguration zur Anpassung an den aktuellen Kontext 

erfolgt. Wir haben derartige Komponenten bereits für den Login-Dialog besprochen. Für 

das IMAT Beispiel haben wir eine „WizardBean“ entwickelt, die Anwender visuell in ihr 

Programm einbinden und per menügeführtem Dialog konfigurieren können. Die 

Darstellung dieser Komponente ist für die Papierfassung zu komplex und sollte online 

betrachtet werden.[IMAT] 

5.4 Zusammenfassung der Projektergebnisse 

Das Vorgehen, visuell programmierte Prototypen als Spezifikation für Szenarien zu 

entwickeln, hat sich bewährt. Anhand der Beispiele konnte nachgewiesen werden, dass 

die rein visuelle Modellierung von Szenarioprototypen machbar ist, allerdings mit den 

heutigen Werkzeuge auch auf Grenzen stößt. 

Die Grenzen lassen sich ausweiten, wenn wir die Entwicklungsmodelle von JavaStudio 

bis hin zu Forté und VisualAge stufenlos in einer Entwicklungsumgebung vereinigt 

werden. Als Einstieg für Anwender ist der einfache Verdrahtungsmodus von JavaStudio 

geeignet, um schnell einfache Prototypen zu erstellen. Sobald verfeinerte Szenarien 

ausgearbeitet werden sollen, empfiehlt sich der Übergang zu einem vereinfachten 

VisualAge Modus. Hierbei sollten im Gegensatz zum professionellen 

Entwicklungsunterstützung nur wenige Verbindungsmöglichkeiten per Menü ausgewählt 

werden können, die zudem in der Sprache der Anwender benannt werden müssen (nicht 

„actionPerformed“ wie bisher, sondern „Drücken des Knopfes löst aus ...“) 

Neben der Integration der unterschiedlichen Entwicklungsmodi müssen vor allem auch 

geeignete graphische Komponenten entwickelt werden, die sich als Ausgangsmaterial zur 

Anpassung in einer Komponentenbibliothek finden. Wenn bereits ganze 

Anwendungsfenster, z.B. organisiert nach Domänen, existieren, fällt die Erstellung von 

Prototypen umso leichter. Wir haben im Laufe der verschiedenen Studien zahlreiche 

derartige Komponenten entwickelt und nachgewiesen, dass diese zur visuellen 

Modellierung selbst in heutige Werkzeuge integriert werden können. 

Schließlich muss das Vorgehen durch Lektionen und Tutorien begleitet werden. Im 

Rahmen einer Diplomarbeit haben wir einen aktiven Assistente entwickelt, der den 

Anwender während der visuellen Modellierung begleitet und auf Nachfrage Hilfestellung, 

Erläutrungen oder Lernmöglichkeiten für die aktuelle Arbeitssituation bietet 

[Gleichmann99]. 

In weiteren Projekten muss untersucht werden 

• Ob sich spezielle Komponenten für Szenenprototypen entwickeln lassen. Im 

Gegensatz zur derzeit untersuchten Komponententechnologie zielen die Komponenten 

nicht auf den Einsatz durch professionelle Softwareentwickler ab, die die Verbindungen 

in einer Programmiersprache ausprogrammieren, sondern müssen sich durch 

Metaphern wie Drag and Drop komponieren und in geführten Interaktionen anpassen 

lassen. 

• Welche Schlüsselqualifikationen müssen Anwender mitbringen, um im spielerischen 

Umgang anhand von Beispielfällen, Vorgänge ihrer Arbeit zu modellieren. Welche 

06.09.00 53


54 

Vorkenntnisse im Umgang mit informatischen Werkzeuge sind notwendig und welche 

Denkweisen müssen verinnerlicht sein? 

6 Projektpräsentationen 

Ludwigsburg, 10.01.2000 

Ulrik Schroeder, Vorstellung der PTAH-Modellierungsmethodik im Rahmen eines 

Berufungsvortrags 

Oldenburg, 12.01.2000 

Ulrik Schroeder, Vorstellung der PTAH-Modellierungsmethodik im Rahmen eines 

Berufungsvortrags 

Dallas, 05.06.2000 

Ulrik Schroeder, Konferenzbeitrag „PTAH: Validation-Driven Design“, auf der 

World Conference for Integrated Design and Process Technology (IDPT 2000) 

University of Colorado in Boulder, August 2000 

Ulrik Schroeder: Eingeladener Fachvortrag im Center for Lifelong Learning and 

Design 

TU Darmstadt, WS 1999/2000 

Ulrik Schroeder: insgesamt 3 doppelstündige Vorlesungen über 

validationsgetriebene Anforderungsanalyse im Rahmen der Vorlesung „virtuelles 

Softwarelabor“ 

Ulrik Schroeder: insgesamt 1 doppelstündige Vorlesungen über 

validationsgetriebene Anforderungsanalyse im Rahmen der Vorlesung „Software 

Engineering“ 

Ulrik Schroeder: einführender Vortrag über validationsgetriebene 

Anforderungsanalyse im Rahmen des Praktikums der Praktischen Informatik 

7 Literatur 

[Andelfinger95] Andelfinger, Urs: Diskursive Anforderungsanalyse und Validierung. 

Ein Beitrag zum Reduktionsproblem bei Systementwicklungen in 

der Informatik. Dissertation, TU Darmstadt. Darmstadt, 1995. 

[Beck99] Beck, Kent: eXtreme Programming explained – Embrace Change, 

Addison Wesley, Reading MA, 1999.


[Burkhart97] Burkhardt, Rainer: UML – Unified Modeling Language. Addison 

Wesley, Reading MA, 1997. 

[Floyd89] Floyd, Christiane: Softwareentwicklung als Realitätskonstruktion. In: 

Lippe, Wolfram (Hrsg.): Software-Entwicklung: Konzepte, Erfahrung, 

Perspektiven, S. 1-20. Springer-Verlag, Berlin, Heidelberg, New 

York, 1989 

[Floyd94] Floyd, Christiane: Software-Engineering – und dann? Informatik- 

Spektrum, 17(1):29-38, 1994 

[Fischer98a] Fischer, Gerhard, Nakakoji K., Ostwald J. (1998): Domain-Oriented 

Design Environments – A New Understanding of Design and its 

Computational Support, MIT Press, 1998 

[Fraikin00] Fraikin, F., Leonhardt, Th. (2000): Top-Down Testen auf der Basis 

von Sequenzdiagrammen , Diplomarbeit, Praktische Informatik, 

Februar 2000. 

[Jacobson92] Jacobson, Ivar: Object Oriented Software Engineering. A Use Case 

Driven Approach. Addison Wesley Longman, Harlow, England, 

1992. 

[Jacobson99] Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified 

Software Development Process. Addison Wesley Longman, 

Reading, Massachusetts 1999. 

[KeilSlawik94] Keil-Slawik: Software-Entwicklung. Die Gestaltung des 

Unsichtbaren. Paderborn, 1994. 

[MyersRosson92] B.A. Myers and M.B. Rosson; Survey on user interface 

programming. In SIGCHI’92: Human Factors in Computing Systems, 

May 1992. 

[OMG97] Object Management Group (OMG): UML Press Kit: 

http://www.omg.org/news/pr97.htm 

06.09.00 55


[Owis99] http://www.otw.de/ 

[Rational99] http://www.rational.com/products/rs/index.jtmpl 

[Schefe99] Schefe, Peter: Softwaretechnik und Erkenntnistheorie. Informatik- 

Spektrum 22, April 1999. 

[Schroeder00] Schroeder, Ulrik: PTAH: Validation Driven Software Design. 

Integrated Design & Process Technology, IDPT 2000, Dallas TX, 

Juni 2000. 

[Wirfs-Brock90] Wirfs-Brock, Rebecca and Wilkerson, Brian and Wiener Lauren 

(1990): Designing Object-Oriented Software, Prentice Hall; Juni 

1990, ISBN: 0136298257 

8 Eingesetzte Software 

[RationalRosel] http://www.rational.com/products/rs/index.jtmpl 

56 

Rational Rose 2000 for Java: Professionelles CASE Werkzeug zur 

visuellen Modellentwicklung für die objektorientierte 

Softwareentwicklung mittels UML 

[BlueJ] http://www.pscit.monash.edu.au/bluej/


1.02, Monash University 

Ausbildungsprogrammierumgebung für Java, die das Austesten 

einzelner Objekte ermöglicht und diese visualisiert 

[VisualAge] http://www.software.ibm.com/ad/vajava/ 

[TogetherJ] 

Professionelle integrierte Softwareentwicklungsumgebung inklusive 

weitreichender CASE Funktionalität und Möglichkeit zur visuellen 

Programmierung von Benutzungsschnittstellen 

Professionelles CASE Werkzeug zur visuellen Modellierung 

objektorientierter Software und Reengineering von Java Klassen 

06.09.00 57


[JavaStudio] 

[Forté] 

[Jbuilder] 

58 

objektorientierter Software und Reengineering von Java Klassen 

Experimentelle visuelle Entwicklungsumgebung mit graphischen 

Komponenten zur einfachen visuellen Komposition durch Nicht- 

Programmierer. Die Entwicklung seitens Sun ist eingestellt. 

http://java.sun.com/ 

Professionelle integrierte Java Entwicklungsumgebung inklusive 

mächtigem GUI Builder zur visuellen Komposition graphischer 

Benutzungsoberflächen. 

http://www.borland.de/jbuilder/index.html 

Professionelle integrierte Programmierumgebung u.a. mit visueller 

Konstruktion von GUIs, aber keiner Unterstützung visuellen 

Programmierens zur Spezifikation der Semantik..


9 Online Material und Referenzbeispiele 

[ptah] Projekt-Website: http://www.pi.informatik.tu-darmstadt.de/ptah-zit/ 

Enthält dynamische Darstellung der Projektergebnisse 

[Rechner] http://www.pi.informatik.tu-darmstadt.de/ptah-zit/bsp/rechner 

Ein graphisch bedienbarer Taschenrechner, wie er von einem 

Anwender selbständig visuell programmiert werden kann. Dieses 

erste kleine Beispiel, dient der Darstellung der resultierenden 

Testsequenzdiagramme, die in der Diplomarbeit [Fraikin00] als 

Beispiel zur Generierung einer Testumgebung verwendet wurde. 

Das Beispiel wurde mit JavaStudio, Forté, VisualAge und TogetherJ 

erstellt. 

[Bibliothek] http://www.pi.informatik.tu-darmstadt.de/ptah-zit/bsp/bibliothek 

Das Programm dient der Verwaltung von Buchbeständen, die 

ausgeliehen werden können. 

Modelliert wurde das Beispiel mittels RationalRose, Forté, 

VisualAge und JavaStudio. 

[Broker] http://www.pi.informatik.tu-darmstadt.de/ptah-zit/bsp/broker 

Javaprogramm zum matchen von Optionsangeboten und 

Nachfragen (Put/Call) sowie der Anzeige aktueller Depotbestände. 

Das Beispiel wurde in JavaStudio entwickelt und zeigt die starken 

Einschränkungen diese Modellierungsansatzes. 

[ConGo] http://www.pi.informatik.tu-darmstadt.de/ptah-zit/bsp/congo 

Programm zur Konfiguration und Steuerung eines Multimedia- 

Konferenzraums. Realisiert wurde das Szenario „Vorführen eines 

Videos zur Unterstützung eines Vortrags“. 

Das Programm wurde mit JavaStudio, VisualAge und Rational Rose 

modelliert. Für VisualAge wurde eine Komponente zur 

Unterstützung der visuellen Spezifikation der Semantik entwickelt, 

die in diesem Beispiel demonstriert wird. 

[Unfallanzeige] http://www.pi.informatik.tu-darmstadt.de/ptah-zit/bsp/Unfallanzeige/ 

Programm zur webbasierten Aufnahme und Visualisierung von 

Unfalldaten durch die Polizei. 

Das Programm wurde mit Jbuilder und TogetherJ modelliert. 

[IMAT] http://www.pi.informatik.tu-darmstadt.de/ptah-zit/bsp/imat 

Programm, das von einem Mathematiklehrer zur Illustration und 

Einsatz im Schulunterricht entwickelt wurde. Das Beispiel wurde 

06.09.00 59


60 

Einsatz im Schulunterricht entwickelt wurde. Das Beispiel wurde 

mittels VisualAge entwickelt und demonstriert die Erweiterungen 

des Modellierungswerkzeuges, um mächtigere visuelle 

Ausdrucksmittel zur Spezifikation der Semantik.

Abschlussbericht

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?