Visuelle Spezifikation, Modellierung und Animation im Systementwurf

Visuelle Spezifikation, Modellierung und
Animation im Systementwurf
Christian Geiger, Wolfgang Müller
C-LAB
Fürstenallee 11
33098 Paderborn
chris@c-lab.de,wolfgang@c-lab.de
Zusammenfassung
Wir betrachten Ansätze visueller Notationen im Systementwurf. Neben einer kurzen
Vorstellung einiger UML-Sprachen zur Verhaltensbeschreibung betrachten wir insbesondere
die Verwendung visueller Programmiersprachen im Systementwurf. Hierbei
fokussieren wir auf die ursprünglich am Xerox PARC entwickelte vollständig visuelle
Programmiersprache Pictorial Janus, die an unserem Institut weiterentwickelt wird.
Durch die inhärente Animation der Ausführung des visuellen Programmes und die
Möglichkeit, die Formgebung der visuellen Objekte unabhängig von ihrer Semantik zu
wählen, stehen mächtige Mittel zur endbenutzerorientierten Spezifikation und Illustration
von Systemprototypen zur Verfügung. Der letzte Teil dieses Beitrags beschreibt die
zusätzliche endbenutzerorientierte 3D-Visualisierung und den Ansatz einer vollständig
dreidimensionalen visuellen Programmiersprache.
1 Einleitung
In jüngster Zeit werden immer mehr Sprachen, Methoden und Werkzeuge mit dem Attribut
visuell versehen. Betrachtet man die einzelnen Ansätze näher, so stellt man fest, daß sich
von dieser Bezeichnung nicht immer genau auf den Inhalt schließen läßt. So stellt Visual
Basic überwiegend eine Sprache zur Implementierung von graphischen Benutzungsoberflächen
dar. Während Visual C++ eine fensterbasierte Benutzungsoberfläche mit Visualisierungskomponenten
zur Entwicklung von C++-Programmen bezeichnet, realisiert VisualAge
im Prinzip eine Kombination beider Funktionalitäten. Das eigentliche Programm wird
in diesen Entwicklungsumgebungen meist als Text eingegeben und manipuliert. Anders
verhält es sich bei visuellen Programmiersprachen. Hier bilden graphische Konstrukte (Token)
Bestandteile zur Eingabe bzw. Manipulation eines Programms. Visuelle Modellierung
im Kontext des Systementwurfes bezeichnet i.W. die Verwendung graphischer Diagramme
in der Spezifikationsphase. Visuelle Darstellungen umfassen dabei alle Arten zwei- und
dreidimensionaler Darstellungen, was die Verwendung von Text nicht ausschließt.
Betrachtet man den heutigen Entwurf komplexer Systeme so fällt auf, daß eine Vielzahl von
domänen- und anwendungsspezifischen graphischen Notationen Anwendung findet. Im objektorientierten
Softwareentwurf kam es zur Entwicklung von unzähligen Darstellungsformen.
Die populärsten Vertreter sind hier sicherlich Booch, Coad, Jacobson, Martin/Odell,
Shlaer/Mellor und Rumbaugh. Die Situation änderte sich jedoch vor kurzem grundlegend,

da sich drei der führenden Experten auf diesem Gebiet (Booch, Jacobson und Rumbaugh)
auf die Zusammenlegung ihrer Sprachen zu einer gemeinsamen Notation einigten und diese
Unified Modeling Language (UML) nannten [Fow97].
Im Hardwareentwurf finden vorwiegend tabellen- und diagrammorientierte Notationen Anwendung.
Hier läßt sich z.Zt. kein Standardisierungsstreben für graphische Notationen ausmachen.
Es ist zu erwarten, daß auch hier die UML-Standardisierung starken Einfluß nehmen
wird.
Betrachtet man die verschiedenen Beschreibungsformen so stellt man fest, daß sie meist
die allerersten Phasen des Systementwurfs, die funktionale Spezifikation und vorherige
Aktionen, nicht optimal unterstützen. Des weiteren fördern diese Darstellungen nicht unbedingt
die Rückkopplung zum Endbenutzer bzw. Kunden, da dieser Personenkreis selten
dazu neigt, Funktionalität aus abstrakten Diagrammen ablesen zu können. Da intensive
Rückkopplungen zum Kunden zur frühen Behebung von Entwurfsfehlen absolut notwendig
sind, werden Pflichtenhefte in wesentlichen Teilen durch textuelle Ausführungen beschrieben
und oft versucht, mittels Prototypen graphischer Benutzungsoberflächen, Kunden die
Funktionalität eines Programmen näher zu bringen.
Wir streben in unseren Arbeiten eine frühzeitige Rückkopplung des Entwicklers mit dem
Benutzer durch animierte Endbenutzerrepräsentationen an. Durch eine Verschmelzung der
Spezifikationssprache mit der Animationsdarstellung erreichen wir eine Reduzierung der
zeitintensiven und fehlerträchtigen Transformationen zwischen Programm und Endbenutzerrepräsentation.
Wir verwenden hierbei die am Xerox PARC entwickelte vollständig visuelle
Programmiersprache Pictorial Janus als Basis und fokussieren die Anwendung auf
die frühen Phasen des Systementwurfs.
Der nachfolgende Beitrag ist wie folgt gegliedert. Wir gehen zunächst kurz auf visuelle
Sprachen im Systementwurf ein und stellen dort unterschiedliche Vertreter dieser Klasse
vor. Danach skizzieren wir den Idealfall des kundenorientierten Systementwurfs und diskutieren
die Vorteile eines von Pictorial Janus ausgehenden Entwurfs bevor wir eine Strategie
zur Umsetzung von PJ-Spezifikationen in imperative Programme vorstellen. Obwohl
hier die Integration einer kundenorientierten 3D-Animation durch Verwendung einer dedizierten
Animationsbibliothek vereinfacht wird, stellt deren Realisierung auch hier einen
noch immer nicht zu unterschätzenden Aufwand dar. Abschließend skizzieren wir kurz
den hieraus entstandenen Ansatz einer dreidimensionalen visuellen Programmiersprache
mit inhärenter Animation: SAM (Solid Agents in Motion) .
2 Visuelle Sprachen im Systementwurf
Lange Zeit reduzierte man die Vorteile visueller Sprachen auf den Satz “Ein Bild sagt mehr
als 1000 Worte”. Neuere Arbeiten nehmen hier einen realistischeren Standpunkt ein, da
diese Aussage für den individuellen Betrachter meist nicht die gleichen “1000 Worte” sind
[Pet95]. Im allgemeinen kann man feststellen, daß in den meisten Fällen präzise Erläuterungen
durch Text eindeutiger repräsentiert werden, während sich visuelle Mittel besser zur
Strukturierung und Darstellung komplexere Zusammenhänge nutzen lassen [Mue96]. Visuelle
Sprachen eignen sich besonders gut für den Entwurf komplexer paralleler Systeme,
bei denen nebenläufig arbeitende Einheiten miteinander kommunizieren, was der mehrdimensionalen
Darstellung entgegen kommt.

Visuelle Darstellungen werden im Systementwurf zur Dokumentation, Spezifikation/Programmierung
und Analyse eingesetzt. In der Spezifikation finden visuelle Mittel
meist nur in der ersten Skizzierung ihre Anwendung. Die erste funktionale Spezifikation
(bzw. Pflichten- oder Lastenheft) ist heutzutage i. W. textorientiert. Graphiken werden
hier oft nur zur näheren Erläuterung des Textes eingesetzt. In den weiteren Entwurfsphasen
dienen graphische Darstellungen insbesondere zur Strukturierung des hierarchischen Entwurfs
in Form von Struktur- oder Blockdiagramme sowie zur Datenspezifikation und für
Verhaltensbeschreibungen. Visuelle Notationen im Systementwurf sind meist Mischformen
aus diagramm-, icon- und tabellenorientierter Darstellung [Shu88] wobei die diagrammbasierten
Elemente oft überwiegen.
Ein Diagramm wird allgemeinen durch einen (un)gerichteten Graphen dargestellt. Knoten
und Kanten werden mehr oder weniger ausführlichere Beschriftungen bzw. Programmfragmente
hinzugefügt. Fortgeschrittene Darstellungsformen basieren auf Hypergraphen
oder Harels Higraphs (Hierarchical Graphs)[Har88], die auf dem Prinzip von
Venn-Diagrammen 1 beruhen. In Higraphs können Knoten zu Superknoten zusammengefaßt
werden, was graphisch durch das Enthaltensein der Knoten im Superknoten dargestellt
wird. Wird eine Kante vom/zum Superknoten gezogen so verbindet diese Kante alle im Superknoten
enthaltene Knoten. Diese Art der Darstellung erlaubt strukturiertere und manchmal
sehr effiziente Darstellungen wie die 2 Variationen der 3-Clique in Abb. 1 zeigen.
Eine der berühmtesten Anwendung von Higraphs sind Statecharts, die besonders bei der
Spezifikation und Modellierung paralleler Systeme und im Hardwareentwurf Anwendung
finden.
A
B C
A B C
Abbildung 1: 2 verschiedene Darstellungen einer 3-Clique
Im folgenden stellen wir einige der heutzutage populärsten Diagrammdarstellungen zur
Verhaltensbeschreibung vor. Da alle in der UML (Unified Modeling Language) enthalten
sind, verwenden wir zur Darstellung die UML-Notationen und Bezeichnungen. Anschließend
gehen wir auf die weniger verbreitete visuelle Programmiersprache Pictorial Janus
ein.
2.1 Unified Modelling Language
Die Unified Modeling Language (UML) Version 1.1 ist die Vereinigung verschiedener diagrammorientierter
Darstellungen, die im Zuge von der populärsten objektorientierten Entwurfsmethoden
entwickelt wurden [Fow97]. UML wurde vor kurzem von der Object Management
Group (OMG) adaptiert und hat große Chancen, sich zu einem weit akzeptierten
Standard im Hard- und Softwarebereich zu entwickeln.
1 Venn-Diagramme sind aus der Mengenlehre bekannt. Sie wurden 1790 von Venn eingeführt und gehen auf
die von Euler verwendeten Euler-Kreise zurück.

UML definiert Entwicklungs-, Fallstudien-, Paket-, Klassen-, Aktivitäts-, Sequenz-,
Kollaborations- und Zustandsdiagramme. Wir werden uns im folgenden auf die kurze Skizzierung
der letzten vier zur Verhaltensbeschreibung eingesetzten Formen beschränken.
Aktion1
Aktion2
[Bedingung2]
[Bedingung1]
Aktion3
Objekt1:Klasse1
neu()
aktiviere
return
Objekt2:Klasse2
kill
OK
Objekt3:Klasse3
check
g
C
h
i
E
A B
f
D
Abbildung 2: UML Aktivitäts- , Sequenz- und Zustandsdiagramme
Aktivitätsdiagramme sind die UML-Variante von klassischen Kontrollflußdiagrammen. Sie
beschreiben die imperative Sichtweise eines Algorithmus. Knoten stellen Variablenzuweisungen,
Prozeduraufrufe oder allgemeine Aktionen dar. Meist wird das Aufspannen und
Zusammenführen von parallelen Kontrollflüssen (Fork/Join) unterstützt. Abb. 2 zeigt ein
Aktivitätsdiagramm. Start und Ende werden durch einen schwarzen Punkt mit und ohne
Kreis gebildet. Fallunterscheidungen werden durch mehrere ausgehende Kanten dargestellt,
die mit den entsprechenden Bedingungen für die Alternativen markiert sind.
Sequenzdiagramme stellen den zeitlichen Ablauf zwischen kommunizierenden parallelen
Objekten dar. Der Berechnungsablauf jedes Objektes wird durch eine von oben nach unten
führende Zeitlinie skizziert. Ein Pfeil ausgehend von der Zeitlinie eines Objektes bezeichnet
den Aufruf einer Methode eines anderen Objektes oder das Senden einer Nachricht
zu diesem Objekt. Abb. 2 zeigt ein einfaches UML-Sequenzdiagramm mit 3 Objekten.
Ausgefüllte Pfeile bezeichnen Methodenaufrufe während asynchrone Nachrichten durch
halbierte Pfeile und Terminierung durch X dargestellt werden.
Kollaborationsdiagramme sind i.W. eine Mischform aus Sequenz- und Aktivitätsdiagrammen
und sollen aus diesem Grund nicht näher vorgestellt werden.
Letztendlich sei hier noch auf die heutzutage sehr populären Zustandsdiagramme eingegangen.
Zustandsdiagramme sind gerichtete (manchmal hierarchische) Graphen. Die Knoten
definieren Zustände und Kanten Zustandsübergänge. Die Kanten werden normalerweise
mit einem Ausdruck der Form ”E(B)/A” beschriftet. Dies beschreibt, daß der Übergang
ausgeführt wird, falls ein Ereignis E eintritt und die Bedingung B erfüllt ist. Beim Übergang
wird dann die spezifizierte Aktion A ausgeführt. Dieses Verhalten ist unter dem Namen
Mealy-Automat bekannt. Werden Aktionen Zuständen zugeordnet so bezeichnet man
das Model als Moore-Automat. UML unterstützt beide Varianten in Verbindung mit hierarchischen
statechart-basierten Zustandsdiagrammen. Statecharts erweitern die klassischen
Zustandsdiagrammen um Hierarchie (Higraphs), Nebenläufigkeit und einen Broadcast-
Mechanismus. Abb. 2 zeigt ein sehr einfaches UML Zustandsdiagramm. Der Einfachheit
halber enthalten hier die Kantenbeschriftungen nur Ereignisse. Das Bild zeigt eine hierarchischen
Zustand E mit zwei parallelen Automaten jeweils mit den Zuständen (A,B) und
(D). Die durch schwarze Punkte gekennzeichneten Initialzustände B und D werden bei i
eingenommen. g bezeichnet den Übergang von allen in E enthalten Unterzuständen zu C.

2.2 Pictorial Janus
Pictorial Janus (PJ) wurde 1989 von Kahn und Saraswat am Xerox PARC [KS90] im
Kontext von Studien zur Handskizzenerkennung als vollständig visuelle Programmiersprache
entwickelt. PJ ist eine deklarative, parallele, regelbasierte, diagrammorientierte 2D-
Programmiersprache. Zeichnungen, die wohldefinierten topologisch- syntaktischen Regeln
entsprechen stellen korrekte PJ-Programme dar. Ein PJ-Programm besteht aus einem Netzwerk
kommunizierender Agenten, die auf dem Grundprinzip des Pattern Matching durch
Regelauswahl Berechnungen ausführen. Die geschlossene Kontur ist das Grundprimitiv
von PJ. PJ-Basisobjekte sind aus geschlossenen Konturen zusammengesetzt. Abb. 3(a) gibt
eine Überblick über die Menge der Basisobjekte.
7
Konstante
+
Funktion
Listenelement
>
Relation
1
0 0
0
1
Link Kanal
0
Agent Regel
1
Abbildung 3: (a) PJ Basisobjekte (b) Verschiedene Repräsentationen
PJ ist topologisch vollständig. Dies bedeutet, daß ein PJ-Programm bei Verzerrung und
Rotation der Einzelobjekte seine Bedeutung beibehält, d.h. man kann Konturen beliebig
verformen, ohne daß sich das Programm verändert. Dies hat den Vorteil, daß man den
Basisobjekten die Form ihrer Verwendung geben kann. Diese Eigenschaft kann ideal zur
Illustration eines Programms eingesetzt werden. Abb. 3 (b) zeigt vier verschiedene Darstellungen
eines Listenobjekts. Im folgenden stellen wir die einzelnen PJ-Objekte kurz vor.
Ein Port ist eine geschlossene Kontur ohne Inhalt Externe/Interne Ports berühren andere
Konturen von Außen bzw. Innen. Ein interner Port dient als Verknüpfungspunkt (Repräsentant)
für die Kontur, in der er enthalten ist. Eine leere Liste besteht aus einer Kontur
mit einem internen Port. Kopf bzw. Listenobjekt einer nicht-leeren Liste besitzen externe
Ports, mit denen weitere Listenobjekte oder Konstanten verbunden sind. Eine Konstante
entspricht in der Darstellung einem Listenobjekt, dessen Kontur eine Zeichenkette oder eine
Zahl umschließt. Das Kombinieren von Listenobjekten erfolgt durch Links. Ein Link
wird durch eine ungerichtete Linie dargestellt und verbindet i.d.R. interne mit externen
Ports. Funktionen sind geschlossene Konturen mit einem Bezeichner und einem internen
und n externen Ports. Relationen besitzen zwei externe Ports und enthalten ein Relationssymbol.
Ein Agent wird durch eine geschlossene Kontur repräsentiert mit einer beliebige
Anzahl externer Ports und keinem internen Port. Kanäle (channels) verbinden zwei externe
Agentenports in der Richtung, in die eine Nachricht gesendet wird. Innerhalb der Agentenkontur
befinden sich Regeln, die das Verhalten des Agenten definieren oder alternativ dazu
ein Aufrufpfeil, der auf einen anderen Agenten zeigt, dessen Regeln beim Aufruf instantiiert
werden. Eine Regel entspricht in der Darstellung dem umschließenden Agenten. Alle
Elemente, die mit den externen Ports der Regel verknüpft sind, definieren die Vorbedingungen.
Die Elemente innerhalb definieren das zu erzeugende Verhalten.
Abb. 4 zeigt ein Pictorial Janus Programm mit einem Agenten, der die Funktionalität einer
binären logischen UND-Operation nachbildet. Die vier einzelnen Regeln spezifizieren
1

die funktionalen Abhängigkeiten der vier möglichen Eingangsbelegungen zum Wert am
Ausgang.
1
0
0
0
0
0
&
Abbildung 4: Logisches UND
Das Programm wird in PJ nicht nur als statische Zeichnung beschrieben. Die Ausführung
eines Programms ist als Animation definiert. PJ ist eine der sehr wenigen visuellen
Sprachen in der die genaue Ursache und Wirkung jedes Einzelschritts der Berechnung
vollständig durch eine kontinuierliche Animation visualisiert wird und die Darstellung zu
jedem Zeitpunkt ein gültiges Programm ist. Das Berechnungsmodell basiert auf dem Pattern
Matching Prinzip. Im einzelnen heißt das in Verbindung mit der Animation, daß
1. die Regeln mit den aktuellen Daten am Eingang verglichen werden und ggf. eine
Regel, deren Bedingung erfüllt ist, selektiert wird,
2. die selektierte Regel inklusive der Inhalte auf die Größe des Agenten skaliert solange
vergrößert wird bis die Vorbedingung die aktuellen Daten überdeckt,
3. Regel und überdeckte Daten sich in Luft auflösen und die in der Regel definierten
Aktionen übrig bleiben und schließlich
4. die so neu erzeugten Objekte auf ihre Normalgröße vergrößert werden.
Abb. 5 zeigt die Animation des PJ Programms von Abb. 4.
3 Kundenorientierter Systementwurf
Die Einzelaktivitäten im Systementwurf werden grob in Spezifikation, Implementierung
und Analyse unterteilt. Je nach Eigenschaften des zu implementierenden Systems lassen
sich diesen Aktivitäten verschiedene Unteraktivitäten zuordnen wie z.B. Partitionierung in
Hardware- und Softwarekomponenten. Die frühen Phasen des Systementwurfs sind durch
die Anforderungsanalyse und -spezifikation bestimmt. Hier bedarf es eines intensiven Informationsaustauschs
des Kunden mit dem/den Systementwickler/n, um zunächst einmal
0
1
1
1
0
1

1
4
1
1
1
1
0
0
0
0
0
0
1
0
1
0
0
0
0
0 0
0
0
0
&
0
1
1
1
0
&
1
1
1
1
0
1
2
5
1
1
1
1
0
0
0
1
0
0
1
0
0
0
0
0
0
0
0
1
1
1
0
1
0
1
&
0
0
0
0
0
0
0
1
1
0
1
0
0
&
0
1
1
1
&
1
1
0
1
1
1
0
0
1
1
0
1
0
0
0
0
0
1
1
1
0
1
0
1
Abbildung 5: PJ Animation
&
1
1
0
1
0
1 0
1 0
1
1
0
0
1
0
0
1
0
0
0
0
0
&
0
1
1
1
0
0 0
zu einer Vertragsgrundlage zu gelangen, die normalerweise durch die Anforderungsspezifikation
- auch Pflichten- oder Lastenheft genannt - implementiert wird. Ausgehend von der
Anforderungsspezifikation versucht der Entwickler, das geforderte System zu implementieren.
Die Praxis zeigt aber, daß es sinnvoll ist, den Endkunden in den weiteren Entwicklungsprozeß
von Zeit zu Zeit mit einzubeziehen, um die Abweichungen des Endproduktes
bzgl. der Vorstellungen des Kunden zu minimieren. Die Abweichungen können ihre Ursache
in der unterschiedlichen Interpretation von einzelnen Punkten der Anforderungen, in
widersprüchlichen Anforderungen, in technisch nicht zu realisierenden Anforderungen o.ä.
haben. Repenning stellte deshalb in [RS95] den kollaborativen Entwurf, der den Kunden in
allen Phasen miteinbezieht, vor. Abb. 6 zeigt die leicht modifizierte Form seines iterativen
Model der Interaktion zwischen Kunde und Entwickler.
Kunde Entwickler
Anforderung
Beobachten
Verhandeln
0
&
3
6
Beobachten
Implementieren
Analysieren
Abbildung 6: Kollaborativer Systementwurf
Das Model basiert auf dem Prinzip der gegenseitigen Beobachtung. Zunächst versucht der
Entwickler, die Anforderungen des Kunden zu verstehen. In einer nachfolgenden gemeinsamen
Verhandlung werden diese dann auf die zu realisierenden Anforderungen reduziert,
die anschließend vom Entwickler zu implementieren sind. Im Idealfall beobachtet der Kun-
&
1
1
1
0
1
1
0
0

de die Implementierungs- und Analysephase und versucht seine Anforderungen zu verfeinern.
Die große Schwierigkeit in der Umsetzung dieses Models besteht allerdings darin,
daß der Kunde sich mit der Implementierungs- und Analysephase auseinandersetzen muß
und hier das Problem hat, die Implementierung - respektive das Programm - in seiner Funktionalität
zu verstehen. Der Entwickler ist hier häufig mit dem Problem konfrontiert, dem
Kunden die Funktionalität des Programms erklären zu müssen. Dies geschieht oft mithilfe
von graphischen Benutzungsoberfächen, die Teilfunktionalität simulieren. Wenn dies
nicht ausreicht, muß auf die aufwendigere Technik des animierten Programmcodes zurückgegriffen
werden, wobei Schlüsselereignisse (in der Regel Ausgabeoperationen) im Code
Animationssequenzen an der Oberflächen auslösen. Hierbei muß i.W. eine Bibliothek von
Animationssequenzen inklusive der graphischen Objekte entwickelt und zum eigentlichen
Programm hinzugebunden werden [Bro88]. Da dieser Ansatz in der Regel zu aufwendig ist
und es oft das Erlernen einer zusätzlichen Sprache bedarf, wird häufig hier auf die Rückkopplung
mit dem Benutzer verzichtet.
Unser Ansatz basiert auf der Verwendung einer visuellen Programmiersprache zur Unterstützung
des kollaborativen Entwurfs in den frühen Entwicklungsphasen. Wir verwenden
hier als erste Basis PJ, da bei diesem Ansatz die Programmiersprache, Sprache zur Darstellung
der endbenutzerorientierten Sicht des Programms und Sprache zur Definition der
funktionalen Animation in einer Sprache vereint sind. So muß der Entwickler nicht häufige
(fehlerbehaftete) Übersetzungen zwischen mehreren Programmiersprachen durchführen.
Das folgenden Kapitel geht genauer darauf ein, wie PJ in die ersten Phases des heute noch
vorwiegend textbasierten Entwicklungsprozeß integriert werden kann.
4 Integrativer Visueller/Textueller Entwurf
Programmiertechnisch gesehen muß im Systementwurf eine grobe Anforderungsspezifikation,
die vorwiegend beschreibt, was gemacht werden soll, schrittweise in eine Implementierung
in eine Programmiersprache überführt, die ausführt, wie etwas realisiert ist.
Letzteres ist typischerweise eine Implementierung in einer imperativen Programmiersprache
wie C/C++ oder Java. Wir beschränken uns bei der Anforderungsspezifikation auf die
Spezifikation der reinen Funktionalität eines zu entwickelnden Systems.
Pictorial Janus 2D
Pictorial Janus 2D + 3D
Entwurf Illustration
Text/Pictorial Janus 2D + 3D
Text 3D
Abbildung 7: Von der visuellen Spezifikation zur animierten textuellen Implementierung
Als Beispiel verwenden wir ein System aus dem Bereich rechnerintegrierter Produktion:
ein Farbsortierspeicher zur Lackierung von Autokarossen (siehe Abb. 8). Zur Vermeidung
ständiger Farbwechsel an der Lackierlinie einer Lackierstraße werden die Rohkarossen in

Warteschlangen vorsortiert, um Blöcke gleicher Farbe zu bilden. Da der Farbsortiervorgang
im Kontext des Gesamtsystems erfolgt, also auch die Termintreue der Aufträge ein
Optimierungskriterium darstellt, kann die den Sortiervorgang steuernde Ein- bzw. Auslagerung
der Karossen nicht eine vollständige Vorsortierung der Karosse in Blöcke maximaler
Größe als Optimierungsziel Steuerstrategie besitzen. Theoretisch betrachtet fällt die Einund
Auslagerung in die Klasse der NP-vollständigen Probleme. In der Praxis wird die Einund
Auslagerung mit sehr einfachen Heuristiken, meist unter Verwendung von Prioritätsregeln,
gelöst. Eine Beschreibung des Systems und einer effizienten Heuristik findet man
in [S. 96]
Abbildung 8: Farbsortierspeicher einer Lackierlinie
Das (ausführbare) PJ Programm bildet den Ausgangspunkt unseres Entwurfsprozesses. Die
in der Anforderungsspezifikation enthaltenen parallelen Systemeinheiten dürften in den
meisten Fällen 1:1 auf ein Netzwerk kommunizierender PJ Agenten übertragen werden
können. Ähnliches gilt für die in den Anforderungen enthaltenen Ein/Ausgabefunktionen.
Jede Funktion wird in eine Regel des entsprechenden Agenten überführt.
Abbildung 9: Funktionale PJ Beschreibung
Eine erste Implementierung einer Lackierlinie in PJ kann im Prinzip durch eine direkte Umsetzung
der Skizze von Abb. 8 erfolgen. Die Funktionalität der Ein- und Auslagerung inklusive
der zugehörigen Strategien werden zunächst durch ein einfaches Ein/Ausgabeverhalten

nachgebildet. Abb. 9 zeigt eine erste funktionale Beschreibung einer Lackierlinie. Von links
nach rechts sortiert der erste Agent die Rohkarossen nach Farben nach einer äußerst einfachen
Strategie mit zwei Farben, bei der rote Lackieranforderungen in die obere Warteschlange
und grüne in die untere Schlange sortiert werden. Die Auslagerung der roten
Karossen erfolgt in Dreierblöcken und die der grüneninZweierblöcken.
Der nächste Schritt gilt der Anpassung der individuellen Konturen der PJ-Objekte hinsichtlich
einer endbenutzerverständlichen Darstellung. Dies gilt vorwiegend den Darstellung der
Agenten und Datenelementen (Listenobjekten). An dieser Stelle im Prozeß kann die erste
ausführbare durch PJ realisierte Spezifikation hinsichtlich der Ein/Ausgabefunktionalität
der einzelnen Funktionseinheiten mit dem Kunden durch Animation evaluiert werden. Im
Einzelfall ist es an dieser Stelle sinnvoll, der 2D-Animation eine 3D-Animation hinzuzufügen.
Hier unterstützt die funktionale Darstellung die Integration einer zusätzlichen
Sichtweise. Nach unseren Erfahrungen ist es sinnvoll, die von den Regeln erzeugten Nachrichten
zur Triggerung der 3D-Animation zu verwenden. Dies erlaubt eine halbautomatische
Anbindung der 3D-Animation, da hier eine 1:1 Zuordnung zwischen 2D- und 3D-
Objekten stattfinden kann [Ch.96].
Abbildung 10: Verschiedene benutzergerechte Repräsentationen
In den nächsten Phasen wird die visuelle PJ Beschreibung schrittweise in eine imperatives
textuelles Programm übertragen. Zunächst bedarf es der Identifizierung der Schnittstellen
jedes PJ Agenten. Dies umfaßt i.W. die Festlegung einer genauen Signatur für jeden
Agenten, da PJ als nichttypisierte Sprache in ein typisiertes Programm transformiert
werden muß. Hiernach sind die Regeln der einzelnen PJ-Agenten in Programmsegmente
zu übertragen. Das jeweilige Segment kann jetzt als Template zur weiteren Verfeinerung
der abstrakten Ein/Ausgabefunktion dienen. Das bedeutet, daß im weiteren die abstrakte
Ein/Ausgabefunktion durch einen detaillierten Algorithmus ersetzt wird.
Das Beispiel in Abb. 11 zeigt deutlich, daß der Übergang zu einer textuellen algorithmischen
Beschreibung in diesem Anwendungsbereich manchmal sinnvoller ist. Der linke graphische
Agent definiert in diesem Beispiel noch eine wesentlich einfachere Strategie als die

g
r
Storage
0
3
=
1
1
0
+
-
1
0
0
bd
+
1
1
+
1
0
> 0
< 15
1
-
0
1
bl
color
bodies
blocks
queue
communication
.
.
.
case {Stored} < {AverageFill} andthen {Not {Stored} == {Jobnumber}}
then
{PrintVS "RandController − start up"}
Reply = wait(1)
else
case {FillIn} < {MinFillIn} andthen {Not {Stored} == {Jobnumber}}
then
{PrintVS "RandController − fillIn toosmall"}
Reply = wait(1)
else
{Elines getEline(ENr Eline)}
{Eline filled(ElineFill)}
case ElineFill
then Reply = wait(1)
else Reply = doDisl(Feeder Eline)
end
end
end
Abbildung 11: Komplexe visuelle und textuelle Strategie
die der rechte Agent in textueller Form beschreibt.
Als letzter Schritt werden die Rahmen der einzelnen Regeln inklusive der Vorbedingung in
proprietären Programmcode umgesetzt. Auch hier kann für die wesentlichen Teile eine 1:1
Umsetzung vorgenommen werden. Legt man eine Umsetzung in die Programmiersprache
C/C++ zugrunde, so kann ein Regelsatz in eine SWITCH-Anweisung und jede Regel in eine
CASE-Anweisung übertragen werden. Schließlich besteht die Möglichkeit, den Bedingungen
zur Regelauswahl noch komplexere Entscheidungskriterien in Form komplexerer
Algorithmen beizufügen. Durch diese Umsetzung bleibt die Struktur des ursprünglichen
Programms weitgehend erhalten. Somit kann eine vorher entwickelte 3D-Animation zur
Kundenpräsentation relativ mühelos in die fertige Implementierung eingebunden werden.
Dies erlaubt es einem Kunden, die endgültige Implementierung gegen die erste PJ Spezifikation
bzgl. ihrer Funktionalität zu validieren.
An dieser Stelle ist es wichtig zu erwähnen, daß es sich hier im Kern um eine manuelle Umsetzung
handelt, die aber in den meisten Teilen strukturiert und damit auch halbautomatisch
vollzogen werden kann.
4.1 Implementierung
Unsere Untersuchungen haben gezeigt, daß das Mittel der Animation von Berechnungsschritten
nur sinnvoll und effizient in Verbindung mit einer hochgradig interaktiven Animationsumgebung
eingesetzt werden kann. Zu diesem Zweck wurde am C-LAB die PJ-
Spezifikations- und Animationsumgebung JIM (Janus In Motion) entwickelt [M. 96]. Hier
hat sich gezeigt, daß sich Animation nur richtig einsetzen läßt, wenn in der Animation
Funktionalität wie Rückwärtslauf, schneller Vorlauf, Wiederholung in Verbindung mit klassischer
Debbuggingfunktionalität wie Breakpoints, schrittweise Ausführung, interaktive
Programmanipulation usw. gekoppelt ist und so in jeder Phase in das (visuelle) Programm
korrigierend eingegriffen werden kann.
Da JIM durch die Beschränkung auf eine 2D visuelle Programmiersprache limitiert war,
koppelten wir JIM für eine intuitivere konkrete Repräsentation mit einer interaktiven
Echtzeit-3D-Animation, die auf einer speziell entwickelten Bibliothek für interaktive 3D-
Animationen basiert [Gei98]. Dennoch stellt auch hier die Erstellung einer zusätzlichen

3D-Animation selbst mit speziellen Werkzeugen immer noch einen im Entwurfsprozeß
nicht unerheblichen Aufwand dar.
5 Eine 3D-visuelle Programmiersprache
Unsere jüngsten Ergebnisse zeigen, daß das die Funktionalität eines zu entwerfenden Systems
und seine 3D-Illustration nicht unbedingt durch zwei getrennte Mittel beschrieben
und somit ständig bei der Implementierung ein Paradigmenwechsel vollzogen werden muß.
Das Ergebnis ist die erste uns bekannte visuelle Programmiersprache, die 3D-Graphik und
Animation als Sprachkonzepte verwendet. Eine 3D-visuelle Programmiersprache verwendet
3D-Graphik und Animation als Sprachkonstrukte bzw. für die Programmausführung
und unterscheidet sich so von Programmiersprachen oder seit langem bekannte (teilweise
visuelle) Notationen zur Erzeugung von 3D-Animationen.
5.1 Sprachkonzepte
SAM (Solid Agents in Motion) basiert auf den Grundkonzepten des Berechnungsmodels
von Pictorial Janus, das hinsichtlich praktischer Anwendungsbereiche grundlegend modifiziert
wurde. Ein SAM-Programm läßt sich als Menge parallel agierender und zustandsbehafteter
Objekte (oder Agenten) beschreiben, die durch Nachrichten kommunizieren. Das
Verhalten der SAM-Agenten wird durch einfache Produktionsregeln beschrieben, die lokale
Aktionen ausführen. Eine lokale Aktion ändert die unmittelbare Umgebung des Agenten
und hat keinen direkten Einfluß auf andere Agenten (bis auf zwei besondere lokale Aktionen
zum Erzeugen und Zerstören von Agenten)
Die Kommunikation in SAM erfolgt (analog zu PJ) über benannte Ports. Jeder Agent besitzt
Ausgangsports, von denen Nachrichten zu anderen Agenten versendet werden und
Eingangsports, die ankommende Nachrichten speichern. Nachrichten können an einen einzelnen
Agenten, an Agenten mit bestimmten Ports (groupcast) oder alle Agenten geschickt
werden (broadcast).
Eine SAM-Regel ist eine Produktionsregel und besteht aus Vorbedingungen und einer Konklusion.
Bedingungen in Regeln bestehen aus Statusabfragen, Typüberprüfungen an Eingangsports
und arithmetischen Ausdrücke. Eine Statusbedingung besagt, daß der Agent
sich in einem bestimmten Zustand befinden muß. Befindet sich der Agent in dem gefordertem
Zustand, so gilt die Bedingung als erfüllt. Wird keine Statusbedingung angegeben, ist
der Zustand des Agenten nicht relevant.
Typ-Bedingungen sind an die jeweils benannten Ports gebunden. Sie geben an, welche
Nachrichten sich an diesem Port befinden müssen, damit die Regel ausgeführt werden darf.
Neben vordefinierten Typen (wie String, Int, Koordinate) können auch beliebige Typ verwendet
oder die Typüberprüfung abgeschaltet werden. Sind alle Vorbedingungen einer Regel
erfüllt, werden die Konklusionen ausgewertet. Der Konklusionsteil einer Regel ist eine
Liste von Aktionen, die sequentiell ausgeführt werden. Aktionen können dabei lokale Aktionen
sein oder das Senden von Nachrichten an andere Agenten bzw. an sich selbst. Zur
Zeit sind als lokale Aktionen Statusänderungen, einfache 3D-Animationen (Skalierung,
Translation, Farbinterpolation, Translation) und das Erzeugen und Löschen von Agenten
möglich. SAM wurde jedoch so entwickelt, daß das Hinzufügen neuer Datentypen und

Aktionen möglichst einfach erfolgen kann. So sind neue Aktionen wie das Abspielen von
Sounddateien, MPEG-Filmen oder das Starten externer Prozesse mit geringem Aufwand
realisierbar.
5.2 Visuelle Repräsentation
Ein SAM-Agent wird durch eine transparente Kugel dargestellt, deren Farbe den Zustand
des Agenten visualisiert. Die Ports sind kleine Kegel auf der Oberfläche des Agenten, die
zum Kugelmittelpunkt zeigen (bei Eingangsports) bzw. von ihm weg (bei Ausgangsport).
Die Farbe der Ports erlaubt eine Identifizierung z.B. in den Regeln des Agenten. Die Regeln
eines Agenten befinden sich im Inneren des Agenten. Die Visualisierung der Agentenregeln
erfolgt nur z.T. analog zu PJ. Eine Regel beschreibt den Agenten und die notwendigen
Daten der Vorbedingungen als Nachrichten an den zugehörigen Ports. Vergleichsoperationen
und Rechenoperationen werden nicht visuell repräsentiert, sondern interaktiv textuell
dargestellt. Bewegt sich der Mauszeiger über eine Regel, wird der entsprechende Text eingeblendet.
Der Aktionsteil einer Regel wird als Sequenz aufeinander folgender Aktionen
repräsentiert. Die Aktionenliste wird durch eine Kette von Zylindern verschiedener Farben
dargestellt, welche die jeweilige Aktion repräsentieren.
Abbildung 12: Agent, Regel, Aktionsliste und Andocken einer Nachricht in SAM
5.3 Visuelle Ausführung
Die visuelle Regelausführung besteht aus zwei Abschnitten: dem Regeltest und der
Ausführung der Konklusion. Wird eine Regel ausgeführt, vergrößertsiesich(wieinPJ)
bis sie die Größe des Agenten und bis sich ihre Prämissen mit den aktuellen Nachrichten
des Agenten überdecken. Anschließend erfolgt eine Abarbeitung der Aktionen. Die Darstellung
dieser sequentiellen Abarbeitung erfolgt durch einen scheibenförmigen Scanner,
der die aktuell bearbeitete Aktion überstreicht. Jede lokale Aktion wird ausgeführt und
verändert den Agenten ggf. (z.B. bei lokalen Animationen). Im Falle einer Sendoperation
werden erst alle zu versendenden Nachrichten bereits am Ausgangsport gesammelt und danach
erst versendet. Die jeweiligen Aktionen (Vergrößern der Regel, Scannen der Konklusionen,
Zustandswechsel, Erzeugen und Versenden der Nachrichten) erfolgt durch einfache
3D-Animationen (entsprechend: Skalierung, Translation, Farbinterpolation). Während der
visuellen Programmausführung läßt sich zwischen der gegeben abstrakten Repräsentation
und einer anwendungsspezifischen konkreten Sicht umschalten.

5.4 Beispiel
Ein Beispiel eines sehr einfachen SAM-Programmes ist eine Applikation, die aus drei
Agenten besteht. Der erste Agent sendet als initiale Aktion eine Nachricht an den zweiten
Agenten sendet und den Zyklus wiederholt. Befindet sich der zweite Agent im Status
bereit, schickt er eine weitere Nachricht an einen dritten Agenten und wechselt in den
Status warten. Erhält der dritte Agent eine Nachricht, führt er eine Reihe von Aktionen
aus (Translation, Nachricht erzeugen, Rotation, Translation). Anschließend sendet er eine
Nachricht an Agent 2, der in Status bereit wechselt und dem Agent 1 eine Antwort
sendet. Eine konkrete Darstellung modelliert die Marsmission, in der die Erde (Agent 1)
eine Anforderung für eine Aufnahme an die Raumsonde Pathfinder sendet. Diese leitet den
Befehl an das Fahrzeug Sojourner weiter, das sich zum Felsen Yogi bewegt (Translation) ,
ein Photo schießt (Nachricht generieren), wendet (Rotation) und zu seinem Ausgangspunkt
zurückkehrt (Translation). Die Nachricht wird an Pathfinder gesendet, der diese an die Erde
funkt und auf eine neue Anforderung wartet (Status bereit). Abb. 13 zeigt die abstrakte und
konkrete Sicht der Animation.
Abbildung 13: Abstrakte und konkrete Sicht eines SAM-Programmes
6 Schlußbemerkung
Wir stellen in diesem Beitrag einen integrierten visuellen/textuellen Ansatz zur Unterstützung
des kollaborativen kundenorientierten Entwurfsprozesses vor. Wir gehen hierbei
als Basis von der vollständig visuellen funktionalen Programmiersprache Pictorial Janus
(PJ) aus, die es erlaubt, ein Programm in endbenutzerorientierter Sicht graphisch darzustellen
und zu animieren. Funktionale Programmier- und Animationssprache bilden in
PJ eine Einheit. Wir skizzierten die Vorgehensweise, wie funktionale visuelle Programme
in imperative textuelle Programme transformiert werden können. Abschließend stellten wir
eine 3D-Programmiersprache vor, die die Konzepte von PJ bzgl. 3D-Animation überträgt
und optimiert.
Trotz all dieser Vorteile in der Benutzung ist uns hier dennoch bewußt, daß es sich bzgl. der
Verwendung von PJ noch um einen sehr akademischen Ansatz handelt, da PJ auf der Klasse
der parallel logischen Programmiersprachen basiert, die in der Praxis nicht so häufig

Anwendung finden. Im Zuge einer möglichen Weiterentwicklung neuerer Programmiersprachen
in Richtung funktionaler Beschreibungsmittel ist ein Einsatz von PJ-Konzepten
zur Spezifikation und Animation von Multiagentensystemen in Zukunft denkbar. Wir sehen
PJ-basierte Ansätze hier auch nicht als Ersatz sondern vielmehr als Ergänzung zu anderen
existierenden visuellen und textuellen Sprachen - speziell in frühen Phasen des Entwurfsprozeßes.
Danksagung
Die hier vorgestellte Arbeit besteht aus einer Summe von Teilprojekten. Wir bedanken uns
insbesondere bei Marita Dücker, Ralf Hunstock, Georg Lehrenfeld, Waldemar Rosenbach
und Christoph Tahedl, die an der Konzeptionierung und Implementierung der einzelnen
Teilprojekte wesentlich beteiligt waren.
Literatur
[Bro88] M.H. Brown. Algorithm Animation. MIT Press, Cambridge, MA, 1988.
[Ch.96] Ch. Geiger and R. Hunstock and G. Lehrenfeld and W. Mueller and J. Quintanilla and
A. Weber. Visual Modeling and 3D-Representation with a Complete Visual Programming
Language- A Case Study in Manufacturing. In: IEEE Symposium on Visual Languages,
Boulder, Colorado, USA, October 1996.
[Fow97] M. Fowler. UML DISTILLED. Addison-Wesley, 1997.
[Gei98] C. Geiger. Prototyping interactive animated objects. In: B. Preim P. Lorenz, Hrsg., Simulation
& Visualisierung, Magdeburg, March 1998. SCS.
[Har88] D. Harel. On Visual Formalisms. Communications of the ACM, 31(5):514–530, 1988.
[KS90] K. Kahn und V.A. Saraswat. Complete Visualizations of Concurrent Programs and their
Executions. In: 1990 IEEE Workshop on Visual Languages, Oct. 1990.
[M. 96] M. Duecker and G. Lehrenfeld and W. Mueller and C. Tahedl. Specification and Analysis of
Concurrent Systems in a Complete Visual Environment. In: European Simulation Multiconference
(ESM96), Budapest, Ungarn, 1996.
[Mue96] W. Mueller. Executable Graphics for VHDL-based Systems Design. Dissertation, Universität-GH
Paderborn, Nov 1996.
[Pet95] M. Petre. Why Looking Isn’t Always Seeing: Readership Skills and Graphical Programming.
Communications of the ACM, 37(10), 1995.
[RS95] A. Repenning und T. Summer. Agentsheets: A Medium for Creating Domain-Oriented Visual
Languages. IEEE Computer, 28(3), March 1995.
[S. 96] S. Voß, S. Spieckermann. Simulation von Farbsortierspeichern in der Automobilindustrie.
In: Simulation und Animation für Planung, Bildung und Präsentation, Magdeburg, 1996.
[Shu88] N. C. Shu. Visual Programming. Van Nostrand Reinhold, New York, 1988.