DE19907328C2 - Verfahren und System zur visuellen Programmierung - Google Patents
Verfahren und System zur visuellen ProgrammierungInfo
- Publication number
- DE19907328C2 DE19907328C2 DE19907328A DE19907328A DE19907328C2 DE 19907328 C2 DE19907328 C2 DE 19907328C2 DE 19907328 A DE19907328 A DE 19907328A DE 19907328 A DE19907328 A DE 19907328A DE 19907328 C2 DE19907328 C2 DE 19907328C2
- Authority
- DE
- Germany
- Prior art keywords
- visual programming
- computer according
- visual
- tree
- operands
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/323—Visualisation of programs or trace data
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
Description
Die vorliegende Erfindung betrifft ein Verfahren zur visuellen Programmierung sowohl von Algo
rithmen, als auch von übergeordneten Programmeinheiten, welches verschiedene Phasen des
Programm-Lebenszyklus dadurch unterstützt, daß es Abhängigkeiten und Beziehungen innerhalb
eines Programmsystems visualisiert, d. h. sichtbar macht. Das Verfahren soll die textuelle Pro
grammierung mit ihren in dieser Hinsicht bekannten Nachteilen ersetzen.
Dem heutigen Stand der Softwaretechnik liegt weitgehend die Annahme zugrunde, daß textuelle
Programmiersprachen ohne Alternative sind. Dies zeigen die Verbreitung der Programmierspra
chen in der industriellen Praxis, aber auch fortgesetzte Neuentwicklungen von Sprachen. In soge
nannten Programming Workbenches zur fortschrittlichen, computer-gestützten Programmierung
spielen Compiler, die programmiersprachlichen Quellcode in Maschinencode transformieren, nach
wie vor eine zentrale Rolle, wenn auch der Programmierer nicht mehr direkt mit dem Quellcode in
Berührung kommt, sondern stattdessen meist mithilfe eines Struktur-Editors den Abstrakten Syn
taxbaum des Programms editiert (siehe S. 532 in Ian Sommerville: "Software Engineering", Addi
son-Wesley, 5. Auflage, 1996).
In der Patentliteratur sind folgende Varianten dieser computer-gestützten textuellen Kodierungs
verfahren vertreten (Stand 29. Januar 1998). Ein Verfahren für die direkte Manipulation des Ab
strakten Syntaxbaumes wird beispielsweise angegeben in Microsoft: "Method and System for ge
nerating a Computer Program", EP 00651325 (1994). Der Struktur-Editor wird hierbei über Kom
mandos bedient, die von der Zielsprache unabhängig sind. Ein Verfahren, das den Gesamtentwurf
unterstützt, ist beschrieben in Hitachi: "Verfahren zum automatischen Erzeugen eines Quel
lenprogramms", DE 35 03 119 (1985). Hierbei werden separate Diagramme für die Modulstruktur,
den Prozeßfluß und die Daten erstellt, die unmittelbar und automatisch in Quellcode umgesetzt
werden. In Hitachi: "Visual Programming Method", US 5664129 (1997), werden Operations- und
Operandennamen aus einer Übersichtsanzeige entnommen und tabellarisch zu einem Programm
zusammengefügt. In der Programmtabelle werden Ausgabewerte von Operationen als Eingabe
werte darauffolgender Operationen durch Linienverbindungen visualisiert. Die Beschreibung der
Datentypen erfolgt textuell. Aus der Programmtabelle kann direkt textueller Quellcode erzeugt
werden. Verfahren, die den Gesamtentwurf durch die Generierung von Schablonen unterstützen,
die anschließend manuell weiterzuverarbeiten sind, sind IBM: "Object-oriented System for genera
ting Target Language Code", EP 00706125 (1995), Honda: "Method for generating a Program",
EP 00696000 (1995) und AT "System for generating Software Source Code Components", EP 00219993.
Schließlich existieren Verfahren, traditionell hergestellte Software nachträglich durch
automatisch generierte Diagramme und Statistiken transparent zu machen, z. B. AT "Method
and Apparatus for displaying hierarchical information of a large Software System", EP 00650118
(1994) und AT "Apparatus for visualizing Program Slices", EP 00714064 (1995). Ein
Verfahren, ein Programm zur Laufzeit durch Monitoring der Objekte transparent zu machen, ist
beschrieben in IBM: "Visualizing object-oriented Software", EP 00689132 (1995). Diesen
Verfahren ist gemeinsam, daß sie die traditionelle textuelle Programmierung unterstützen, sie
aber nicht durch visuelle Methoden ablösen.
Voll visualisierte Programmiermethoden gibt es für einige eingeschränkte Anwendungsbereiche,
wie z. B. für die Spezifikation von Entscheidungsbäumen oder von ähnlichen hierarchischen Struk
turen. In Ford: "Verfahren und System zur Verarbeitung und On-Line-Darstellung von Multimedia-
Information in einer Baumstruktur", DE 43 32 193 A1, wird mit rein graphischen Mitteln ("rubber
banding") ein Entscheidungsbaum editiert, der die Maschinendiagnose mittels Frage-Antwort-Ver
zweigung unterstützt. Ebenfalls graphisch ("drag-and-drop") wird das Diagnosewissen in Form
von Texten, Graphiken, Videos etc. den Knoten des Entscheidungsbaumes zugeordnet. In Bell:
"Visual Programming of Telephone Network Call Processing Logic", WO 92/11724, wird mittels
einer graphischen Benutzeroberfläche eine Baumstruktur editiert, welche die Dienstelemente
eines hierarchisch strukturierten Telekommunikationsdienstes sowie deren Ausführungsreihenfol
ge wiedergibt. Der Dienst kann anschließend ausgeführt werden, indem die zuvor erzeugte Baum
struktur automatisch interpretiert wird. Derartige Verfahren, die ein Programmieren im weiteren
Sinne beinhalten, werden typischerweise für Konfigurationsaufgaben eingesetzt. Sie besitzen im
Allgemeinen nicht die Möglichkeit, Operationen und Operanden frei zu definieren und diese dann
innerhalb eines Kontrollflusses frei miteinander zu verknüpfen. Sie sind daher auch nicht geeignet,
textuelle Programmiersprachen zu ersetzen.
Seit Anfang der achtziger Jahre gibt es dagegen Bestrebungen einer Minderheit von Software-In
genieuren, Programmiersprachen zu visualisieren und damit anschaulich zu machen. So entstand
der Bereich der "Visuellen Programmiersprachen und Programmierumgebungen". Auch das erfin
dungsgemäße Verfahren ist diesem Bereich zuzuordnen. Eine Übersicht zum Stand der Technik
bis einschließlich Februar 1996 ist zu finden in Jörg Poswig: "Visuelle Programmierung - Compu
terprogramme auf graphischem Weg erstellen", Hanser-Verlag, 1996. Eine laufend aktualisierte
Bibliographie aller wesentlichen, in internationalen Fachzeitschriften veröffentlichten Forschungs
arbeiten zum Thema "Visuelle Programmierverfahren" führt das im Academic-Press-Verlag, Lon
don, erscheinende Journal of Visual Languages and Computing (Web-Dokument http://www.
cs.orst.edu/~burnett/vpl.html). Nach dem Klassifizierungsschema, das dieser Bibliographie zu
grundeliegt, kann das erfindungsgemäße Verfahren den Merkmalen "VPL-II.A.6 imperative" und
"VPL-V.A general-purpose" zugeordnet werden. Diese Merkmalskombination weist keines der
dort angeführten Verfahren auf (Stand 16. Februar 1998).
Besondere Bedeutung für die Praxis hat die Kategorie der "imperativen Sprachen" (VPL-II.A.6),
die auf dem Zuweisungs- und Kontrollflußprinzip beruhen und in der Lage wären, praxisrelevante
Programmiersprachen wie C und C++ zu visualisieren. In dieser Kategorie werden lediglich meh
rere Arbeiten zur Graphmanipulationssprache PROGRES angeführt, z. B. Andreas Schuerr:
"PROGRES: A VHL-Language Based on Graph Grammars", Lecture Notes in Computer Science
532, Springer-Verlag (1991), S. 641-659. Graph-basierte Sprachen sind grundsätzlich auf be
stimmte Anwendungsbereiche beschränkt und damit nicht "universell".
In der Gruppe der "universellen Sprachen" (VPL-V.A) dominieren die Datenfluß-Verfahren (VPL-
II.A.3) mit ihrer jeweiligen Visualisierung des unterliegenden Datenflußgraphen, z. B. Braine, L.,
Clack, C.: "Object-Flow", in 1997 IEEE Symposium on Visual Languages, Capri, Italy, Sept. 1997.
Im Gegensatz zu den imperativen Sprachen, stellen die Datenflußsprachen keine syntaktischen
Elemente zur Sequentialisierung von Anweisungen zur Verfügung und entfernen sich daher sehr
von dem in der Praxis üblichen Programmierstil. Die Akzeptanz der textuellen Datenflußsprachen
für den professionellen Einsatz ist entsprechend gering. Ein visuelles Verfahren dieser Art, das
dennoch eine gewisse praktische Bedeutung erlangt hat, ist das kommerziell vertriebene Entwick
lungswerkzeug "PROGRAPH CPX" (siehe [Poswig]).
Weitere Verfahren, die in der Gruppe der "universellen Sprachen" (VPL-V.A) aufgeführt werden,
sind die "funktionalen Sprachen" (VPL-II.A.5), die große Ähnlichkeit mit den Datenflußsprachen
besitzen, insbesondere, was die Abwesenheit des Kontrollflusses betrifft. In der Praxis konnten
sie sich als textuelle Verfahren im Allgemeinen nicht durchsetzen (Ausnahme LISP). Gegenstand
der Visualisierung ist hier jeweils die Ein-Ausgabe-Relation einer Funktion. Siehe beispielsweise
Erwig, M.: "DEAL - A Language for Depicting Algorithms", in IEEE Symposium on Visual Langua
ges, St. Louis, USA, Oct. 1994.
Die in der Gruppe der "universellen Sprachen" (VPL-V.A) aufgeführten "logischen Sprachen"
(VPL-II.A.7) basieren auf der Implikation und der Anwendung von Schlußregeln. Gegenstand der
Visualisierung sind hier logische Ausdrücke und ihre Transformation. Siehe beispielsweise Agusti,
J. et al.: "Towards Specifying with Inclusions", in Mathware and Soft Computing, 1997. Wie im Fall
der "funktionalen Sprachen" handelt es sich hier um Sprachen, die sich einerseits als textuelle
Verfahren in der Praxis nicht durchsetzen konnten (Ausnahme Prolog) und deren Visualisie
rungen sich andererseits noch weitgehend im Experimentierstadium befinden.
In der Gruppe der "universellen Sprachen" (VPL-V.A) sind weiterhin "formular- und tabellen-ba
sierte" (VPL-II.A.4) Verfahren vertreten, siehe z. B. DuPuis, C., Burnett, M.: "An Animated Turing
Machine Simulator in Forms/3", Oregon State University, Dept. of Computer Science, TR 97-60-
08, July 1997. In dieser Arbeit wird gezeigt, daß "Forms/3" ein universelles Verfahren ist, jedoch
darauf hingewiesen, daß dies nicht für die bisher kommerziell verwerteten Verfahren gilt.
Zusammenfassend kann zum Stand der Technik festgestellt werden, daß es sich bei den bekann
ten visuellen oder graphisch unterstützten Programmiermethoden um stark eingeschränkte Ver
fahren handelt, entweder hinsichtlich ihrer Visualisierung oder hinsichtlich ihres Anwendungsbe
reichs. Bei den in der Praxis eingesetzten Verfahren, welche die textuelle Programmierung unter
stützen, gilt hinsichtlich ihrer Visualisierung, (1) daß jeweils unterschiedliche und separate Baum
darstellungen für Algorithmen, Datenstrukturen, Modulstrukturen, Vererbungsbeziehungen, usw.
benutzt werden, (2) daß für Datenstrukturen separate Baumdarstellungen benutzt werden, wobei
Visualisierungen für das Traversieren komplexer Datenstrukturen gänzlich fehlen und (3) daß
Beziehungen zwischen funktionalen Einheiten und Datenstrukturen in der Regel nicht visuell, son
dern über Namensverweise ausgedrückt werden. Die wissenschaftlich orientierten visuellen Ver
fahren konzentrieren sich im Wesentlichen auf Bereiche mit naheliegender Visualisierung, wie
z. B. für Datenfluß, Graphmanipulation und Mengendiagramm. Die imperative Programmierung
wird dagegen wegen der ihr innewohnenden Notwendigkeit der Zeigerprogrammierung weitgeh
end ausgeklammert. Entsprechend fehlen auch hier Ansätze beispielsweise zur Visualisierung
von Traversen auf komplexen Datenstrukturen. Bezeichnend für den Stand der Softwaretechnik
ist daher, daß praktisch einsetzbare integrierte visuelle Gesamtdarstellungen für Programm
systeme bis heute fehlen.
Nach Aussagen in [Poswig] "haben visuelle Sprachen allgemein nicht die theoretische Mächtigkeit
einer universellen Programmiersprache" (S. 32) und sollten diesen Anspruch auch nicht hegen,
denn "visuelle Programmiersprachen sind nur dann erfolgreich, wenn sie speziell für einen An
wendungsbereich ausgelegt sind" (S. 42). Diagramm-basierte visuelle Programmierung - das ist
jene, um die es bei der vorliegenden Erfindung geht - hat meist als Grundlage die sogenannten
Nassi-Shneiderman-Diagramme oder Flußdiagramme, doch wird dieser Zweig der Programmie
rung mit visuellen Ausdrücken als bedeutungslos angesehen (S. 33). Darüberhinaus wird es "als
extremer Standpunkt gewertet, eine textuelle Programmiersprache direkt in ein graphisches Gegenstück
umzusetzen" (S. 53). Deshalb "sollte man bei der Entwicklung einer visuellen Program
miersprache nicht versuchen, eine textuelle Sprache eins zu eins zu visualisieren" (S. 66).
Der Erfindung liegt daher die Aufgabe zugrunde, ein visuelles Programmierverfahren- und
-system anzugeben, welches ohne die visuelle Programmierung auf einen speziellen Anwen
dungsbereich zu beschränken unter Beibehaltung der in der Praxis bewährten Paradigmen aus
dem Gebiet der textuellen Programmierung, wie imperativer und objektorientierter Program
mierstil, eine vollständige Visualisierung sowohl des Kontrollflusses, als auch der Struktur der
Operationen und Operanden sowie der Traversierung komplexer Operanden, ermöglicht.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zur visuellen Programmierung nach
Anspruch 1 und ein System nach Anspruch 70, gelöst, wobei sich weitere zweckmäßige Ausführungsformen der vorliegenden
Erfindung aus den Unteransprüchen ergeben.
Hierdurch wird auch eine Visualisierung ermöglicht, die einheitlich ist, indem sie ein visuelles
Programm in einer einzigen Graphik unter Verwendung einer einheitlichen Struktur darzustellen
erlaubt. Hierbei ist jedem visuellen Programm ein Speicherabbild zugeordnet, bei dem die
visuellen Programmbausteine durch Speicherobjekte und die visualisierten Beziehungen
zwischen den Programmbausteinen durch Verweise zwischen den Speicherobjekten repräsentiert
sind.
Es hat sich nämlich überraschenderweise gezeigt, daß sich - entgegen den zitierten Expertenmei
nungen - alle wesentlichen Elemente einer textuellen objekt-orientierten Programmiersprache
(hier gezeigt am Beispiel von C++) auf einfache graphische Elemente abbilden lassen, die zu
einer integrierten Gesamtdarstellung eines Softwaresystems zusammengefügt und daraus
automatisch in objekt-orientierten Quellcode übersetzt werden können. Insbesondere können
dabei (a) die in textuellen Programmiersprachen syntaktisch uneinheitlichen Baumstrukturen von
z. B. arithmetisch-logischen Ausdrücken, verschachtelten Blockstrukturen, Funktions-, Klassen-
und Vererbungshierarchien, Modul-, Komponenten- und Ebenenhierarchien auf einheitliche Weise
(hier gezeigt anhand einer Terrassendarstellung für Bäume) und durchgängig vom Funktionsargu
ment bis hin zum Gesamtsystem dargestellt werden. Ebenso ist es möglich, (b) mit denselben
graphischen Mitteln wie in (a) auch die Operanden zu erfassen, und zwar sowohl unter dem Ge
sichtspunkt der Strukturierung, als auch unter dem der Traversierung, als auch unter dem des dif
ferenzierten Zugriffs in Form von Argument-, Zuweisungs- und Elementbeziehungen. Auch Gül
tigkeitsbereich und Lebensdauer können dargestellt werden. Schließlich können (c) die Bezieh
ungen durch eine gitterartige Verknüpfung der beiden Baumstrukturen nach (a) und (b) visualisiert
werden, so daß sich für das Gesamtsystem eine Art "integriertes Schaltbild" mit Chip-Charakter
ergibt. Neben den Merkmalen "VPL-V.A general-purpose" und "VPL-II.A.6 imperative" besitzt das
erfindungsgemäße Verfahren folgende weitere Merkmale nach dem Klassifizierungsschema des
Journal of Visual Languages and Computing: "VPL-II.A.9 object oriented", "VPL-II.B.1
diagrammatic", "VPL-II.A abstraction (data, procedural)", "VPL-III.B control flow", "VPL.III.C data
types and structures", "VPL-III.D documentation" und "VPL-III.F exception handling".
Ein wesentliches Ziel der Erfindung ist die Visualisierung von (a) Nachbarschafts- und Enthalten
seinsbeziehungen einerseits und von (b) Benutzungs- oder Kommunikationsbeziehungen ander
erseits. Dabei spielen Formen, Farben, Winkel und Abmessungen der benutzten Geometrie eine
untergeordnete Rolle. Verschiedene geometrische Ausführungen sind denkbar. Hier wird exem
plarisch für die Visualisierung von Beziehungen nach (a) eine Terrassendarstellung für Baum
strukturen gewählt, die aufgrund ihrer Kompaktheit vorteilhaft erscheint. Die Beziehungen nach (b)
werden, ebenfalls exemplarisch, durch eine Gitterstruktur visualisiert, die wegen ihrer Übersicht
lichkeit bevorzugt wird. Darüberhinaus ist das Verfahren unabhängig von der Zielsprache, in
welche die visuellen Programmelemente automatisch übersetzt werden können. Grundsätzlich ist
die Übersetzung direkt in den Maschinencode eines konkreten Prozessors möglich. Hier wird als
Zielsprache exemplarisch die objekt-orientierte Programmiersprache C++ gewählt, die aufgrund
des Abbildungsmaßstabes und der Portabilität vorteilhaft erscheint. Weiterhin ist die hier getroffe
ne Auswahl der Programmbausteine willkürlich. Das Verfahren ist ebenso anwendbar auf einen
erweiterten oder eingeschränkten Satz von Programmelementen. Hier werden exemplarisch Bau
steine ausgewählt, die einerseits für den Programmieralltag sinnvoll erscheinen, andererseits die
Mächtigkeit des visuellen Verfahrens zeigen.
An graphischen und textuellen Grundelementen für das Verfahren werden benötigt:
Rechtecke (Typ H), die in horizontaler sequentieller Anordnung weitere Rechtecke des Typs H enthalten können, sowie selbst wieder in horizontaler sequentieller Anordnung in anderen Recht ecken des Typs H enthalten sein können. Die Anordnung soll disjunkt sein und festgelegte horizontale Abstände einhalten. Die Höhe und Breite der Rechtecke soll von der Höhe und Breite der darin enthaltenen Rechtecke abhängen und dabei festgelegte Randabstände einhalten. Die Abstände sollen so gewählt sein, daß einerseits eine gewisse Kompaktheit der Gesamtstruktur gegeben ist, andererseits die erhaltene Klammerstruktur ausreichend visualisiert ist. Die so erhal tene Anordnung wird "horizontale Verschachtelung" genannt. Die beteiligten Rechtecke nennen wir "H-Boxen". H-Boxen einer minimalen, definierten Größe, die selbst keine weiteren H-Boxen enthalten, nennen wir "atomare H-Boxen" (siehe Fig. 1).
Rechtecke (Typ H), die in horizontaler sequentieller Anordnung weitere Rechtecke des Typs H enthalten können, sowie selbst wieder in horizontaler sequentieller Anordnung in anderen Recht ecken des Typs H enthalten sein können. Die Anordnung soll disjunkt sein und festgelegte horizontale Abstände einhalten. Die Höhe und Breite der Rechtecke soll von der Höhe und Breite der darin enthaltenen Rechtecke abhängen und dabei festgelegte Randabstände einhalten. Die Abstände sollen so gewählt sein, daß einerseits eine gewisse Kompaktheit der Gesamtstruktur gegeben ist, andererseits die erhaltene Klammerstruktur ausreichend visualisiert ist. Die so erhal tene Anordnung wird "horizontale Verschachtelung" genannt. Die beteiligten Rechtecke nennen wir "H-Boxen". H-Boxen einer minimalen, definierten Größe, die selbst keine weiteren H-Boxen enthalten, nennen wir "atomare H-Boxen" (siehe Fig. 1).
Rechtecke (Typ V), die in vertikaler sequentieller Anordnung weitere Rechtecke des Typs V ent
halten können, sowie selbst wieder in vertikaler sequentieller Anordnung in anderen Rechtecken
des Typs V enthalten sein können. Die vertikalen Abstände, sowie die Berandung soll analog zur
horizontalen Verschachtelung vorgenommen werden. Die so erhaltene Anordnung wird "vertikale
Verschachtelung" genannt. Die beteiligten Rechtecke nennen wir "V-Boxen". V-Boxen einer
minimalen, definierten Höhe, die selbst keine weiteren V-Boxen enthalten, nennen wir "atomare V-
Boxen". V-Boxen werden horizontal gedehnt dargestellt. Ihre Breite hängt ab von der Breite einer
ihnen zugeordneten horizontalen Verschachtelung (siehe Fig. 2).
Rechtecke (Typ E), die in vertikaler sequentieller Anordnung genau eine horizontale Verschach
telung und darunter genau eine (eventuell leere) vertikale Verschachtelung enthalten. Derartige
Rechtecke nennen wir "Einheiten". Die Breite der innersten V-Boxen der vertikalen Verschachte
lung einer Einheit entspricht dabei der Breite der darüberliegenden horizontalen Verschachtelung
dieser Einheit. Jede Einheit soll selbst wieder H-Box sein, sodaß Einheiten in der horizontalen
Verschachtelung einer übergeordneten Einheit auftreten können. Eine solche Anordnung von Ein
heiten nennen wir "Hierarchie" (siehe Fig. 3).
Linien, die H-Boxen der horizontalen Verschachtelung einer Einheit mit V-Boxen der vertikalen
Verschachtelung derselben oder einer übergeordneten Einheit in vertikaler Ausrichtung verbinden.
Diese Linien können am oberen oder unteren Ende oder an beiden Enden mit Pfeilspitzen
versehen sein. Derartige Linien nennen wir "Pfeile". Pfeile treffen eine V-Box jeweils von oben und
enden an ihrer Oberkante. Eine V-Box kann an jedem Punkt der Oberkante getroffen werden.
Eine H-Box wird von unten getroffen und endet am linken oder am rechten Ende ihrer Unterkante.
Einen Pfeil am linken Ende nennen wir "L-Pfeil", einen Pfeil am rechten Ende nennen wir "R-Pfeil".
Eine atomare H-Box wird nur in der Mitte ihrer Unterkante getroffen (siehe Fig. 4).
Kreise mit kleinem Durchmesser, die ausgewählte Überkreuzungen von Pfeilen mit atomaren V-
Boxen überdecken. Derartige Kreise nennen wir "Kreuzungsmarken" (siehe Fig. 5).
Alphanumerische Zeichenketten, mit denen H-Boxen und V-Boxen - in der Regel in der linken
oberen Ecke - beschriftet werden. Derartige Zeichenketten nennen wir "Namen". Eine Beschrif
tung kann zum Zwecke der Übersichtlichkeit der restlichen Darstellung auch teilweise verdeckt
werden (siehe Fig. 6).
Sonderzeichen, mit denen H-Boxen, in der Regel in der linken oberen Ecke, beschriftet werden.
Ein oder mehrere solcher Sonderzeichen einer Beschriftung nennen wir "Symbol". Symbole
werden gelegentlich auch zur Kennzeichnung von V-Boxen benutzt (siehe Fig. 7).
Fig. 1 zeigt eine horizontale Verschachtelung 1a mit atomaren H-Boxen 2a und nicht-atomaren
H-Boxen 3a.
Fig. 2 zeigt eine vertikale Verschachtelung 1b mit atomaren V-Boxen 2b und nicht-atomaren V-
Boxen 3b.
Fig. 3 zeigt eine Hierarchie von Einheiten 1.
Fig. 4 zeigt Pfeilverbindungen zwischen H- und V-Boxen. Mit 4a ist ein L-Pfeil und mit 4c ist ein
R-Pfeil gekennzeichnet. 4b bezeichnet einen Pfeil, der auf einer atomaren H-Box endet.
Fig. 5 zeigt eine Kreuzungsmarke 5 auf dem Schnittpunkt von einem Pfeil mit einer atomaren V-
Box.
Fig. 6 zeigt die Beschriftung von H- und V-Boxen mit Namen 8.
Fig. 7 zeigt die Beschriftung von H- und V-Boxen mit Symbolen 9.
Im Folgenden wird ausgeführt, wie mithilfe der oben angegebenen graphischen und textuellen
Grundelemente Programmbausteine gebildet werden können, aus denen sich auf streng hierarchi
sche Weise visuelle Computerprogramme zusammensetzen lassen. Fig. 8 zeigt ein Programm
beispiel. Unter den Programmbausteinen befinden sich arithmetisch-logische Ausdrücke, Kontroll
strukturen, Objektklassen, sowie höhere funktionale Einheiten. Für die Beschreibung der Se
mantik dieser Programmbausteine verwenden wir Begriffe der objekt-orientierten Programmier
sprache C++.
Wir unterscheiden einfache und zusammengesetzte Objekte. Ein "zusammengesetztes Objekt"
wird repräsentiert durch eine V-Box, ein "einfaches Objekt" durch eine atomare V-Box. Wir ver
wenden zwei Typen von einfachen Objekten, "Skalare" und "Iteratoren", sowie zwei Typen von zu
sammengesetzten Objekten, "Strukturen" und "Container". Die diesen vier Typen zugeordneten V-
Boxen können durch Farbgebung unterschieden werden. Eine weitere Differenzierung der Ob
jekte erfolgt durch Beschriftung ihrer V-Boxen mit Klassen- und Objektnamen, gegebenenfalls ge
folgt von weiteren Angaben, wie Dimension, Anfangsbelegung, usw. Fig. 9 zeigt ein Beispiel.
Ein "Zugriff" auf ein Objekt wird dargestellt durch einen Pfeil. Ein von dem Objekt ausgehender
Pfeil symbolisiert einen lesenden Zugriff, der den Objektzustand nicht verändert. Ein auf ihm en
dender Pfeil stellt einen schreibenden Zugriff dar, der den Objektzustand verändern kann. Le
sende und schreibende Zugriffe werden durch einen Doppelpfeil gekennzeichnet. Auf ein Objekt
können mehrere Zugriffe nebeneinander erfolgen, denen dann ebensoviele Pfeile zuzuordnen
sind. Die zeitliche Reihenfolge der Zugriffe ist nacheinander von links nach rechts für Pfeile, die
auf derselben horizontalen Verschachtelungsebene beginnen oder enden. Zugriffe aus unter
schiedlicher Tiefe der horizontalen Verschachtelung heraus erfolgen nacheinander von innen
nach außen. Die horizontale Dehnung der V-Boxen visualisiert mit dieser Einschränkung die Zeit
achse. Fig. 10 zeigt ein Beispiel.
Die horizontale Ausdehnung der V-Boxen soll auch den Gültigkeitsbereich, sowie die Lebensdau
er eines Objektes visualisieren. Der Gültigkeitsbereich eines Objektes erstreckt sich jeweils über
die gesamte Breite der horizontalen Verschachtelung einer Einheit. Innerhalb einer Hierarchie von
Einheiten lassen sich somit globale Objekte mit abgestuftem Gültigkeitsbereich definieren, jeweils
global zu allen Untereinheiten der horizontalen Verschachtelung einer Einheit. Gleichzeitig
kennzeichnet das linke Ende einer V-Box die Instanziierung eines Objektes, das rechte Ende sein
Verlöschen, jeweils bestimmt durch die Aktivzeit der Einheit. Eine weitere Differenzierung des
Gültigkeitsbereiches und der Lebensdauer kann durch entsprechende Wahl einer Speicherklasse
erfolgen.
Skalare sind Objekte, deren innere Struktur nicht sichtbar ist. Der Zugriff auf die innere Struktur
erfolgt ausschließlich über Elementfunktionen oder -operatoren. Es können eingebaute Skalare
zur Verfügung gestellt werden, z. B. Integer oder Character. Daraus, sowie mithilfe von Strukturen,
Containern und Iteratoren lassen sich neue Objekte bilden, die wiederum als Skalar definierbar
sind. Fig. 11 zeigt ein Beispiel.
Strukturen sind Objekte, deren innere Struktur offengelegt ist. Sie enthalten in fester Anordnung
eine feste Anzahl von Objekten beliebigen Typs. Eine Struktur kann ohne Einschränkung in
vertikaler Verschachtelung Skalare, Iteratoren, Container und wieder Strukturen enthalten. Zu
griffe auf die Elemente einer Struktur können auch ohne Elementfunktionen oder -operatoren
erfolgen, indem Pfeile direkt auf die Strukturelemente geführt werden. Fig. 12 zeigt ein Beispiel.
Container sind Objekte, die in der Regel eine unbestimmte Anzahl von Objekten homogenen Typs
enthalten, welche in einer regulären Struktur (z. B. Feld, Kette, Baum) zusammengefaßt sind.
Container sind unabhängig vom Datentyp ihrer Elemente definiert. Der Datentyp ihrer Elemente
wird festgelegt, indem in sie genau ein Objekt bestimmten Typs eingesetzt wird. Das eingesetzte
Objekt repräsentiert damit alle Containerelemente. Der Zugriff auf ein Element des Containers
wird durch einen Pfeil bezeichnet, der auf dem repräsentativen Element endet oder von ihm
ausgeht.
Zugriffe auf Containerelemente erfolgen in der Regel innerhalb einer Traverse, welche die regu
läre Struktur des Containers nach einem Schema durchläuft und die Elementpositionen ermittelt.
Durchlaufschema und aktuell erreichte Position innerhalb eines Containers sind hier vom eigentli
chen Container getrennt und zu einem Iterator-Objekt zusammengefaßt. Auch der Iterator ist
unabhängig vom Datentyp der Containerelemente. Jedoch ist der Typ des traversierten Contai
ners Bestandteil des Iteratortyps. Der Klassenname eines Iterators bezeichnet den Algorithmus
einer Traverse auf einem Container bestimmten Typs (nicht Elementtyps). Durch Zugriffe auf den
Iterator mittels seiner Elementfunktionen und -operatoren kann die in ihm verwaltete Position
eines Containerelements entsprechend dem Traversieralgorithmus verändert werden.
Im Allgemeinen können auf einem Container mehrere verschiedene Traversen, sowie auch auf
mehreren Containern verschiedene Traversen gleichzeitig aktiv sein. Die Auswahl und Zuordnung
einer Traverse zu einem Container geschieht für jeden Zugriff separat, indem der Schnittpunkt
von Zugriffspfeil und Iterator mit einer Kreuzungsmarke belegt wird. Die Kreuzungsmarke besitzt
die Funktion eines Dereferenz- oder Inhaltsoperators. Eine Zuordnung ist nur möglich für
Iteratoren, die oberhalb des Containers liegen. Die Zuordnung wird dokumentiert durch Beschrif
tung des Containers mit dem Objektnamen des Iterators auf der Höhe des Zugriffspfeils.
Ohne Iterator erfolgt der Zugriff auf einen Container als Ganzes. In diesem Fall endet der Zugriffs
pfeil auf dem Container. Ohne Iterator erfolgt auch der Elementzugriff für Container wie z. B. Stack
und Queue. In ihrem Fall erfolgt der Zugriff über Elementfunktionen oder -operatoren, wobei der
Zugriffspfeil ebenfalls auf dem Container endet. Fig. 13 zeigt ein Beispiel.
Durch Verschachtelung von Containern können mehrdimensionale Container erzeugt werden.
Entsprechend sind beim Zugriff auf die Elementardaten mehrere Iteratoren nötig. Jedem Contai
ner einer Verschachtelung, der vom Zugriffspfeil durchdrungen wird, ist ein Iterator zuzuordnen
und dieser mit einer Kreuzungsmarke zu belegen. Die einer Verschachtelung von Containern zu
geordneten Iteratoren können als Koordinaten der Container-Elemente betrachtet werden. Fig.
14 zeigt ein Beispiel.
Ein Iterator kann selbst wieder Element eines Containers sein und benötigt seinerseits einen Ite
rator für die Traverse und den Zugriff. Auf diese Weise kann ein Containerelement indirekt adres
siert werden. Die Zuordnungen von Iteratoren zu Containern, die selbst wieder zugeordnete
Iteratoren enthalten, werden wie oben als Kreuzungspunkte auf dem Zugriffspfeil markiert. Da
durch, daß ein Iterator stets oberhalb des ihm zugeordneten Containers liegt, ist die Gesamtzu
ordnung zyklenfrei. Pro Zugriff ist die Zuordnung zwischen Iteratoren und Containern außerdem
bijektiv. Fig. 15 zeigt ein Beispiel.
Wir unterscheiden Speicherklassen, um für Objekte den Gültigkeitsbereich und die Lebensdauer
genauer spezifizieren zu können. Dazu werden die Speicherklassen "STATIC", "DYNAMIC" und
"DISTRIBUTED" eingeführt und als Struktur bzw. als Container repräsentiert, mit entsprechender
Beschriftung ihrer V-Boxen. Dabei gelten folgende syntaktische Einschränkungen: (1) STATIC-,
DYNAMIC- und DISTRIBUTED-Größen können nur auf oberster Ebene einer vertikalen Ver
schachtelung deklariert werden, insbesondere dürfen sie nicht ineinander eingesetzt werden. (2)
STATIC-, DYNAMIC-, sowie DISTRIBUTED-Deklarationen können jeweils nicht mehr als ein Ob
jekt aufnehmen.
Als STATIC vereinbarte Objekte besitzen einen lokalen Gültigkeitsbereich bezogen auf eine Funk
tionale Einheit, aber eine - innerhalb der Prozeßlaufzeit - unbegrenzte Lebensdauer. Sie eignen
sich u. a. für die Initialisierung lokaler Größen. Die Lebensdauer von DYNAMIC-Objekten kann
dagegen beliebig gestaltet werden, was z. B. für die Konstruktion von Containern genutzt werden
kann. Der Gültigkeitsbereich von DYNAMIC-Objekten ist grundsätzlich global. Sie sind für den
Zugriff ohne Einschränkung verfügbar, wenn ihre Position bekannt ist.
Der Zugriff auf STATIC-Größen erfolgt gemäß den Regeln für Strukturen, während auf DYNAMIC-
Größen - wie auf Containerelemente - über Iteratoren zugegriffen wird. Für die Speicherklasse
DYNAMIC gibt es zwei eingebaute Elementfunktionen, 'create' und 'delete'. 'Create' erzeugt ein
Objekt vom Typ des in den DYNAMIC-Container eingesetzten repräsentativen Objekts und liefert
als Returnwert die Position des erzeugten Objekts, die in der Regel einem Iterator zugewiesen
wird. Über diesen Iterator kann das Element auch wieder gelöscht werden, wobei der Iterator als
Argument von 'delete' auftritt. Der Iterator für DYNAMIC ist "eingebaut". Er enthält keine Traver
senfunktion. Dafür verwaltet er aber neben der Position (im Heap) auch die Typangabe des DY-
NAMIC-Elementes. Diese wird für Konsistenzprüfungen herangezogen.
DISTRIBUTED-Objekte besitzen eine von der Systemlaufzeit unabhängige, unbegrenzte Lebens
dauer. Sie werden keinem Prozeß des Systems eindeutig zugeordnet, sind migrationsfähig und
können prinzipiell in einem externen System implementiert sein. Ihr Gültigkeitsbereich ist platt
form-übergreifend global. Der Zugriff erfolgt über Elementfunktionen. Fig. 16 zeigt ein Beispiel.
Wir unterscheiden einfache und zusammengesetzte Ausdrücke. Ein "zusammengesetzter Aus
druck" wird repräsentiert durch eine H-Box, ein "einfacher Ausdruck" durch eine atomare H-Box.
Wir verwenden zwei Typen von zusammengesetzten Ausdrücken, "Funktionen" und "Operatio
nen" (genauer gesagt, die Aufrufe derselben), sowie einfache Ausdrücke als "Argumente" von
Funktionen und Operationen. Die diesen Ausdruckstypen zugeordneten H-Boxen können durch
Farbgebung unterschieden werden. Eine weitere Differenzierung der Funktionen und Operationen
erfolgt durch Beschriftung ihrer H-Boxen mit Funktionsnamen bzw. Operatorsymbolen. Argumente
werden weiter unterschieden in Eingabe-, Ausgabe- und Ein-Ausgabe-Argumente. Argumente
können mit einem Pfeil versehen sein und repräsentieren damit das Objekt, auf dem der Pfeil
endet, als Parameter der Funktion bzw. Operation. Entsprechend ihrer Unterscheidung in
Eingabe-, Ausgabe- und Ein-Ausgabe-Argumente werden sie über eingehende, ausgehende oder
ein-und-ausgehende Pfeile mit den Objekten verbunden. Eingabe-Argumente können auch ohne
Pfeil spezifiziert werden, indem sie (ggf. in abgekürzter Schreibweise) direkt mit dem Wert oder
dem Namen einer Konstanten beschriftet werden. Die Identifizierung eines Argumentes geschieht
über seine Position innerhalb der Argumentfolge einer Funktion oder Operation. Fig. 17 zeigt ein
Beispiel.
Auch ein zusammengesetzter Ausdruck kann Eingabe-Argument einer Funktion oder Operation
sein. Das Ergebnis einer Funktion oder Operation wird jeweils durch die H-Box ihres Aufrufs re
präsentiert und kann durch direktes Einsetzen an der Position eines Funktions- oder Operations
argumentes verwendet werden. Der Datentyp des Ergebnisses muß dabei mit dem Datentyp des
Funktions- oder Operationsargumentes übereinstimmen. Funktionen und Operationen können
fortlaufend ineinander eingesetzt werden und bilden im allgemeinen Fall eine horizontale Ver
schachtelung. Das Ergebnis einer Funktion oder Operation kann auch durch "Zuweisung" verwen
det werden. Dazu wird ein R-Pfeil auf das Objekt geführt, dem das Ergebnis zugewiesen werden
soll.
Die "Elementbeziehung" einer Funktion oder Operation zu einem Objekt wird durch einen L-Pfeil
zwischen dieser Funktion oder Operation und dem Objekt dargestellt. Durch die Pfeilrichtung kann
näher bezeichnet werden, ob das Objekt verändert oder nur gelesen wird oder beides. Im Fall
einer weder lesenden noch schreibenden Beziehung degeneriert der L-Pfeil zu einer ungerich
teten Verbindungslinie.
Die zeitliche Reihenfolge der Objekt-Zugriffe ist nacheinander von links nach rechts für Pfeile, die
auf derselben horizontalen Verschachtelungsebene beginnen oder enden. Dies gilt auch für die L-
und R-Pfeile derselben H-Box. Zugriffe aus unterschiedlicher Tiefe der horizontalen Verschach
telung heraus erfolgen nacheinander von innen nach außen. Fig. 18 zeigt ein Beispiel.
Eine Kontrollstruktur wird repräsentiert durch eine (farblich hervorgehobene) Einheit, welche in
ihrer horizontalen Verschachtelung von links nach rechts folgende H-Boxen enthält: Zunächst
einen "Prolog", welcher beliebig viele Ausdrücke (oder auch höhere Funktionale Einheiten) enthal
ten kann, z. B. für eine Initialisierung. Die letzte (farblich hervorgehobene) Einheit dieses Prologs
muß ein Ausdruck sein. Er stellt die "Pre-Condition" dar. Darauf folgen ein oder mehrere "Cases".
Ein Case wird jeweils repräsentiert durch eine Einheit, welche mit einer "Post-Condition" be
schriftet ist. Diese enthält einen Vergleichsoperator, gefolgt von einer Konstanten (Wert oder
Name; DEFAULT ist der Name einer eingebauten Post-Condition, die dem else- oder default-Fall
entspricht und immer erfüllt wird). Ein Case ist erfüllt, wenn die Berechnung der Konkatenation
von Pre-Condition und Post-Condition den Wahrheitswert 1 ergibt. Die Auswertung der Wahrheits
werte geschieht in der Reihenfolge der Anordnung der Cases. Der erste erfüllte Case innerhalb
der Kontrollstruktur wird ausgeführt.
Wir unterscheiden zwei Case-Typen, "SELECT" und "REPEAT". Beide Typen können gemischt
innerhalb einer Kontrollstruktur auftreten. Nach Ausführung einer SELECT-Einheit wird die Kon
trollstruktur verlassen. Nach Ausführung einer REPEAT-Einheit erfolgt erneut die Bestimmung der
Wahrheitswerte aus der Pre-Condition und den Post-Conditions der Cases mit anschließender
Ausführung eines Case. Die Fig. 19 bis 25 zeigen Beispiele.
Weitere sinnvolle Kontrollstrukturen können "Exceptions" und "Threads" sein, mit denen sich Aus
nahmebehandlung und Parallelität ausdrücken lassen. Jeder sequentiell auszuführenden Folge
von Operationen kann eine Menge von sequentiell auszuführenden Operationenfolgen zugeordnet
werden, welche die Ausnahmebehandlung vornehmen. Ebenso können mehrere sequentiell
auszuführende Operationenfolgen zu einem Block zusammengefaßt werden, der simultan aus
geführt wird. Für diese beiden Strukturen kann eine verdeckte Anordnung von Vorteil sein, die erst
im Bedarfsfall (Editieren, Animation, Views, Navigieren) sichtbar wird.
Die als Funktion dargestellten (farblich hervorgehobenen) "Terminatoren" 'throw', 'break' und
'continue' können in der von C++ her bekannten Bedeutung verwendet werden. Mit ihnen kann
eine Kontrollstruktur verlassen oder modifiziert werden.
Je eine horizontale und vertikale Verschachtelung werden zusammengefaßt zu einer Funktionalen
Einheit. Fig. 26 zeigt ein Beispiel. Die kleinsten Funktionalen Einheiten, mit leerer vertikaler Ver
schachtelung, sind die "Ausdrücke". Höhere Funktionale Einheiten ergeben sich durch horizontale
Verschachtelung niederer funktionaler Einheiten und Ergänzung mit einer vertikalen
Verschachtelung zu einer neuen funktionalen Einheit. Auf diese Weise lassen sich "Blöcke" unter
schiedlicher Hierarchiestufe bilden, "Definitionen von Funktionen und Operationen", "Definitionen
von Klassen und Unterklassen", "Funktionsbibliotheken", "Module" unterschiedlicher Hierar
chiestufe, "Systemkomponenten", "Systemebenen" und "Systeme".
Die in der horizontalen Verschachtelung einer Funktionalen Einheit enthaltenen Funktionalen Sub-
Einheiten kommunizieren über die Objekte der vertikalen Verschachtelung dieser Einheit (oder
jeder übergeordneten Einheit). Im Falle einer Funktionsdefinition sind es die lokalen Objekte, über
welche die Ausdrücke kommunizieren. Fig. 27 zeigt ein Beispiel. Im Falle einer Klassendefinition
sind es die Datenelemente, über welche die Elementfunktionen kommunizieren und die zu den
Elementfunktionen global liegen. Im Falle einer Funktionsbibliothek sind es die globalen Objekte.
Im Falle der obersten Systemebene sind es die Nachrichten-, Sychronisations- oder Verteilten
Objekte, über welche die Prozesse miteinander kommunizieren. Der Zugriff auf diese Objekte
erfolgt immer durch Kleinste Funktionale Einheiten, die über vertikalen Pfeilzugriff sämtliche
Objekte aller übergeordneten Einheiten erreichen können, da diese, von innen nach außen, je
weils in zunehmender Breite untereinanderliegen. Fig. 28 zeigt ein Beispiel.
Die als Funktion dargestellten (farblich hervorgehobenen) "Terminatoren" 'return', 'exit', 'abort',
'terminate' können in der von C++ her bekannten Bedeutung verwendet werden. Mit ihnen kann
eine Funktionale Einheit verlassen werden.
Mit den obengenannten Graphikelementen wurde bisher der Aufruf einer Funktion oder Operation,
sowie die Instanziierung eines Objekts beschrieben. Mit denselben graphischen Mitteln können
auch die "Definitionen" dieser Funktionalen Einheiten beschrieben werden. Dazu führen wir fol
gende eigenständigen Typen Funktionaler Einheiten (mit entsprechender farblicher Kennzeich
nung) ein: die "Funktion", die "Operation", die "Klasse", die "Funktionsbibliothek", sowie nach Be
darf weitere, bis zur Hierarchiestufe des "Systems".
Die Einheiten der Funktion und der Operation werden mit dem "Funktionsnamen" bzw. dem "Ope
ratorsymbol" beschriftet. Er entspricht dem Aufrufnamen bzw. -symbol. Unter den Objekten ihrer
vertikalen Verschachtelung werden die "Aufruf-Parameter" mit einem Pfeilsymbol als IN-, OUT-
oder IN-OUT-Parameter gekennzeichnet. Fig. 8A zeigt ein Beispiel. Der Reihenfolge ihres
Auftretens von oben nach unten entspricht die Aufrufreihenfolge von links nach rechts. Der
"Returnwert" der Funktion oder Operation wird als Argument eines farblich besonders gekenn
zeichneten Terminators übergeben. Es kann mehrere solcher Terminatoraufrufe geben, deren
Argumente auf Konsistenz überprüft werden. Die Spezifikation als Argument ist gleichzeitig die
Typ-Deklaration des Returnwertes.
Eine Klasse wird allgemein als Funktionale Einheit definiert, welche in ihrer horizontalen Ver
schachtelung die Einheiten der "Elementfunktionen" enthält, sowie in ihrer vertikalen Verschachte
lung die "Datenelemente" (global zu den Elementfunktionen). Sie wird mit dem "Klassennamen"
beschriftet, der bei der Instanziierung eines Objekts dieser Klasse verwendet wird. Es folgen in
<<-Klammern die "Konfigurations-Parameter" der Klasse, wie z. B. eine Anfangsbelegung, Größe,
usw., die den Konstruktor-Parametern entsprechen. Fig. 29 zeigt ein Beispiel.
Gemäß den angegebenen Klassentypen wird die Funktionale Einheit der Klasse weiter differen
ziert in SCALAR, CONTAINER und ITERATOR, sowie STRUCTURE. Für Scalare sind keine wei
teren Merkmale vorgesehen. Die Datenelemente eines Scalars sowie eines Iterators sind nur über
Elementfunktionen zugreifbar und sind somit privaten Typs.
Zwischen Container und Iterator muß zunächst eine formale Zuordnung getroffen werden, die es
einem Iterator erlaubt, direkt auf die Datenelemente eines Containers zuzugreifen. Die Zuordnung
erfolgt durch Eintrag des Iterator-Klassennamens in eine dem Container assoziierte Liste. Ebenso
wird dem Iterator der Container-Klassenname zugeordnet. Die Implementierung des eigentlichen
Containers geschieht in der Regel mithilfe der DYNAMIC-Speicherklasse. Die Containerelemente
sind dabei als STRUCTURE-Objekte definiert und enthalten Iterator-Objekte für ihre Verkettung.
Structure-Klassen sind öffentlichen Typs und erlauben den direkten Zugriff auf ihre Elemente über
Zugriffspfeile. Ähnlich wie verschachtelte Container werden sie direkt über Editierfunktionen er
zeugt und können zur Festlegung ihres Gültigkeitsbereiches einer höheren Funktionalen Einheit
zugeordnet werden.
"Freie Funktionen", die nicht Element einer Klasse sind, können in "Funktionsbibliotheken" (Inter
faces) zusammengefaßt werden. Auch sie werden als Funktionale Einheit definiert und enthalten
in ihrer vertikalen Verschachtelung globale Objekte, über welche die Funktionen kommunizieren.
Eine Klasse, die in die horizontale Verschachtelung einer anderen Klasse eingesetzt wird, erbt da
mit alle Funktionen, Operatoren und Datenelemente der umschließenden Klasse. Die Definition
einer Sub-Klasse erfolgt auf derselben Ebene wie die Definition der Funktionen und Operatoren
der umschließenden Klasse. Innerhalb der Sub-Klasse können Funktionen und Operatoren der
Oberklassen neu-definiert und als "virtuell" oder "static" gekennzeichnet werden. Der Zugriff von
Sub-Klassen auf die Datenelemente von Oberklassen kann optional eingeschränkt werden. De
fault-mäßig entsprechen diese Datenelemente globalen (protected) Größen. Das Schema der ho
rizontalen Verschachtelung läßt beliebige einfache Vererbungsbeziehungen zu. Fig. 32 zeigt ein
Beispiel.
Abstraktion und Vergröberung einer funktionalen Einheit ergeben sich durch Verdecken von De
tails innerhalb der ihr zugeordneten H-Box. Blockdiagramme erhält man beispielsweise durch
Weglassen sämtlicher Details bis auf die Beziehungspfeile zu globalen Objekten und die Namens
beschriftung. Die Beziehungspfeile enden in diesem Fall an der Unterkante der funktionalen Ein
heit. Gleichartige Beziehungspfeile lassen sich weiter zu einem repräsentativen Pfeil zusammen
fassen. Fig. 30 zeigt ein Beispiel. Schnittstellen-Diagramme erhält man durch Weglassen
sämtlicher Details einer Funktion oder Operation bis auf die als Parameter gekennzeichneten
Objekte und die Namensbeschriftung. Die Parameter-Objekte können horizontal verkürzt und mit
ihrer Beschriftung angezeigt werden.
Für eine Vergröberung lassen sich Details während des Editiervorgangs willkürlich als relevant
bzw. nicht-relevant kennzeichnen. Bei einer vergröberten Anzeige werden die als nicht-relevant
eingestuften Details verdeckt. Fig. 31 zeigt ein Beispiel.
Fig. 8A zeigt den bekannten rekursiven Algorithmus Quicksort in einer vollständigen Visualisie
rung nach dem hier beschriebenen Verfahren. Der Datenteil enthält fünf Objekte, darunter vier Ite
ratoren, wovon zwei als Eingabeparameter markiert sind. Das zu sortierende Feld von Objekten
des Typs 'int' ist als Ein- und Ausgabeparameter gekennzeichnet. Auf die Iteratoren erfolgen
schreibende und lesende Zugriffe. Das Feld 'v' als Ganzes wird fünfmal als Funktionsargument
übergeben. Zwei lesende Zugriffe auf Feldelemente erfolgen über die Iteratoren 'i' und 'left'. Hier
wird der Vergleich v[i]<v[left] durchgeführt. Der Operationsteil enthält fünf Funktionsaufrufe, davon
zwei rekursive Aufrufe von Quicksort. Die Funktionsargumente bestehen zum Teil aus komplexen
Ausdrücken. Im mittleren Bereich des Operationsteils befinden sich zwei ineinander
verschachtelte Kontrollstrukturen, die äußere repetitiv, mit einem Prolog, der aus einer Addition
besteht. Die innere Kontrollstruktur ist selektiv und führt bei Erfüllen der Vergleichsbedingung zu
einem Aufruf der Funktion 'swap'.
Fig. 8B soll, beispielhaft und unabhängig von einer geometrischen Ausführung, das allgemeine
topologische Prinzip des erfindungsgemäßen Verfahrens verdeutlichen, nach dem ein Algorith
mus visualisiert wird. Es sind erkennbar die Baumstruktur der Operationen 1a, die Baumstruktur
der Operanden 1b, die Hilfslinien 6 zur Dehnung der Operanden längs der Zeitachse, sowie die
Linien 4 zur Darstellung von Argument-, Zuweisungs- und Element-Beziehungen mit ihren Auf
treffpunkten 7 und Kreuzungsmarken 5.
Fig. 9 zeigt die hier verwendeten vier Grundmuster von Objekten, SKALAR, ITERATOR, CON
TAINER und STRUKTUR. Durch Beschriftung mit Klassen- und Objektnamen, teilweise mit An
fangswert, ergeben sich vollständig spezifizierte Objektdeklarationen.
Fig. 10 zeigt die Zugriffsmöglichkeiten für ein verschachteltes Objekt. Die Zugriffe können in je
der Tiefe erfolgen.
Fig. 11 zeigt einen schreibenden und lesenden Zugriff auf einen SKALAR oder ITERATOR.
Fig. 12 zeigt schreibende und lesende Zugriffe auf eine STRUKTUR als Ganzes und auf ihre
Elemente.
Fig. 13 zeigt lesende und schreibende Zugriffe auf einen Container als Ganzes, sowie lesende
und schreibende Zugriffe auf Containerelemente über einen Iterator der Klasse 'inorder'. Der Itera
tor kann selbst gelesen und verändert werden.
Fig. 14 zeigt lesende und schreibende Zugriffe auf verschachtelte Container. Der Zugriff auf den
Baum der Klasse 'tree' erfolgt als Ganzes und somit ohne Iterator. Der Zugriff auf Baumelemente
der Klasse 'array' in Tiefe 1 der Verschachtelung erfolgt über einen Iterator der Klasse 'inorder'.
Der Zugriff auf Feldelemente der Klasse 'char' in Tiefe 2 der Verschachtelung erfolgt über einen
zusätzlichen Iterator der Klasse 'LtoR'. Die Beschriftung neben dem Zugriffspfeil zeigt die Zu
ordnung von Iteratoren zu Containern an.
Fig. 15 zeigt indirekte lesende und schreibende Zugriffe auf einen Container der Klasse 'tree'
und seine Elemente der Klasse 'int'. Der Iterator für den 'tree'-Container ist selbst Element eines
Containers der Klasse 'array' und benötigt daher für den Zugriff seinerseits einen Iterator. Alle be
teiligten, auch eingebettete, Iteratoren werden durch Kreuzungspunkte auf dem Zugriffspfeil mar
kiert. Die Zuordnung geht aus der Beschriftung neben dem Zugriffspfeil hervor.
Fig. 16 zeigt die dynamische Speicherplatzzuweisung für ein Objekt der Klasse 'task' mit Zuwei
sung der Objektposition an einen Iterator. Anschließend erfolgt ein lesender Zugriff auf das dyna
misch erzeugte Objekt über einen Iterator. Das Objekt wird wieder gelöscht durch Aufruf einer
Elementfunktion der DYNAMIC-Speicherklasse.
Fig. 17 zeigt den Aufruf einer Funktion mit Namen 'sort' und mit drei Argumenten, sowie den Auf
ruf des Operators '+' mit zwei Argumenten.
Fig. 18 zeigt eine Verschachtelung von Funktions- und Operationsaufrufen. 'merge' ist als Ele
mentfunktion mit schreibender Wirkung gekennzeichnet. '+=' ist als Elementoperator mit schrei
bender und lesender Wirkung gekennzeichnet. Das Ergebnis der '%'-Operation wird einem Objekt
zugewiesen. Das Argument des Operators '-' ist ein einfacher Ausdruck, ebenso das zweite Ar
gument des Operators '+='.
Fig. 19 zeigt eine Kontrollstruktur (C) mit einer Precondition und einem Case vom Typ SELECT
(S). Die Precondition repräsentiert den Wert eines Objekts, beispielsweise mit Objektnamen 'a',
von dem der Argumentpfeil ausgeht. Falls die Konkatenation 'a==1' aus Pre- und Postcondition
erfüllt ist, wird der Case ausgeführt.
Fig. 20 zeigt eine selektive Kontrollstruktur wie oben, jedoch vor der Precondition mit einem aus
zwei Operationen bestehenden Prolog.
Fig. 21 zeigt eine selektive Kontrollstruktur wie oben, jedoch mit einem zusätzlichen DEFAULT-
Case, der einer else-Anweisung entspricht.
Fig. 22 zeigt eine Verschachtelung von selektiven Kontrollstrukturen, die einer if-then-if-Anwei
sung entspricht.
Fig. 23 zeigt eine selektive Kontrollanweisung mit mehreren Cases, darunter einem DEFAULT-
Case, die einer switch-case-Anweisung entspricht.
Fig. 24 zeigt zwei repetitive Kontrollanweisungen, die einer while- bzw. for-Schleife entsprechen.
Fig. 25 zeigt eine gemischt selektive und repetitive Kontrollstruktur mit Prolog, die einem endli
chen Automaten entspricht. Zu diesem Zweck ist die Kontrollstruktur mit lokalen Objekten zu einer
funktionalen Einheit ergänzt. Die SELECT-Cases entsprechen den Endzuständen des Automaten.
Sie enthalten die Aufrufe der Aktionen, die bei Erreichen eines Endzustands auszuführen sind.
Der DEFAULT-Fall ist repetitiv, führt zum Einlesen eines neuen Ereignisses, beispielsweise aus
einer Datei, und zum anschließenden Rücksprung auf die Precondition. Im Prolog wird das Ereig
nisobjekt initialisiert. Die Automatentabelle besteht aus einem zweidimensionalen Feld mit Elementen
der Klasse 'int', die jeweils dem Folgezustand entsprechen. Die Precondition ermittelt aus
dem neuen Ereignis 'event' und dem alten Zustand 'state' den neuen Zustand 'table[state] [event]'
und weist ihn dem Zustandsobjekt zu.
Fig. 26 zeigt a) eine horizontale Verschachtelung, b) eine vertikale Verschachtelung und c) die
Zusammenfassung von a) und b) zu einer Funktionalen Einheit.
Fig. 27 zeigt verschiedene Argument-, Element- und Zuweisungsbeziehungen zwischen der ho
rizontalen und der vertikalen Verschachtelung einer Funktionalen Einheit.
Fig. 28 zeigt die hierarchische Anordnung von Funktionen zu Moduln, von Moduln zu System
ebenen und von Systemebenen zu einem Gesamtsystem. Die Objekte höherer Funktionaler Ein
heiten sind jeweils global zu allen ihnen untergeordneten Funktionalen Einheiten und erlauben
Zugriffspfeile über mehrere Hierarchiestufen hinweg.
Fig. 29 zeigt die Klassendefinition einer Verketteten Liste mit Namen 'link'. Sie umfaßt eine Kon
struktorfunktion, sowie weitere Funktionen zum Einfügen, Löschen und Ändern von Listenele
menten. Die Datenelemente der Klasse umfassen eine dynamische Speicherdeklaration für
STRUKTUR-Objekte der Klasse 'item', sowie einen Iterator namens 'first'. 'first', sowie der Iterator
'next' dienen der Verkettung der Listenelemente. Die Elementfunktionen von 'list' weisen sowohl
Zugriffe auf ihre lokalen Objekte auf, als auch globale Zugriffe auf die Datenelemente von 'list'.
Fig. 30 zeigt eine Abstraktion der Klassendefinition nach Fig. 29. Von den Elementfunktionen
sind alle Details bis auf ihre globalen Zugriffe auf die Datenelemente verdeckt. Von den Datenele
menten sind die Details der Listenobjekte verdeckt.
Fig. 31 zeigt eine Vergröberung der Klassendefinition nach Fig. 29. Zusätzlich zu den in der
Abstraktion nach Fig. 30 verdeckten Details ist, willkürlich, der Iterator 'first' verdeckt, sowie alle
Zugriffe der Elementfunktionen darauf.
Fig. 32 zeigt eine Klassenhierarchie. Die Basisklasse 'A' besitzt die Elementfunktionen 'f1' und
'f2', sowie einen Container mit Iterator als Datenelemente. Von 'A' sind die Klassen 'B' und 'C'
abgeleitet, die jeweils die Funktion 'f1' neu definieren. Von 'C' sind wiederum die Klassen 'D' und
'E' abgeleitet, die jeweils die Funktionen 'f1' und 'f2' der Oberklassen neu definieren. Alle von 'C'
abgeleiteten Klassen haben Zugriff auf ihre eigenen Datenelemente, wie auch auf die ihrer
Oberklassen.
Das auf dem Bildschirm angezeigte visuelle Programm besitzt im Arbeitsspeicher der Program
mierplattform ein Speicherabbild in Form einer komplexen Datenstruktur. Dieses Speicherabbild
ist gemeinsame Grundlage der unterschiedlichen Funktionen der Programmierumgebung, wie
z. B. das Editieren, die graphische Wiedergabe oder die Übersetzung in eine textuelle Program
miersprache.
Das Speicherabbild des visuellen Programms besitzt, wie das visuelle Programm selbst, eine
Baumstruktur. Jedem Baumelement des visuellen Programms ist dabei ein Speicher-Objekt zuge
ordnet, das gemäß seiner Inklusions- und Nachbarschaftsbeziehungen, sowie seiner Benutzungs-
und Kommunikationsbeziehungen, mit anderen Speicher-Objekten verkettet ist.
Die Objekte des Speicherabbilds sind dabei in Klassen eingeteilt, die den unterschiedlichen Pro
grammbausteinen entsprechen. Unter den Datenelementen jeder dieser Klassen befinden sich
neben den Verkettungsvariablen auch jene Attribute, welche die unterschiedlichen Funktionen der
Programmierumgebung unterstützen, wie z. B. Geometrie-Daten, Farbcodes, Klassen- und Ob
jektnamen, Funktionsnamen und Operationssymbole, arithmetische Konstanten, Dokumentations
texte, Projektdaten und Testwerte.
Die Traversierung des Speicherabbilds erfolgt in der Regel rekursiv mithilfe virtueller Funktionen.
Dabei wird automatisch für jedes besuchte Objekt des Speicherabbilds eine vom Typ des Objekts
abhängige Implementierung einer virtuellen Funktion aufgerufen. Diese greift, abhängig vom be
suchten Objekttyp und der gewünschten Funktion der Programmierumgebung, auf Attribute des
Objekts zu, um ihren Anteil an der jeweiligen Funktion der Programmierumgebung, wie z. B. Edi
tieren oder Übersetzen, beizutragen.
Für die Anwendung des erfindungsgemäßen Verfahrens auf die Konstruktion von Programmen ist
es nötig, verschiedene Arbeitsfunktionen zu unterscheiden, die sich ergänzen und erst in ihrem
systematischen Zusammenwirken die Konstruktion ermöglichen. Alle diese Arbeitsfunktionen ope
rieren auf dem gemeinsamen Speicherabbild des visuellen Programmsystems. Es handelt sich
dabei um die Funktionen des Erstellens und Veränderns des Speicherabbilds, um die Überset
zung des Speicherabbilds in eine textuelle oder andere Programmiersprache, um die Verlagerung
des Speicherabbilds von und zu einem nicht-flüchtigen Speichermedium, um die Generierung gra
phischer Darstellungen aus dem Speicherabbild, um die Dokumentation und die Verwaltung des
Speicherabbilds, um die Navigation durch das Speicherabbild und um die Animation der graphi
schen Darstellung des Speicherabbilds.
Die Aufgabe, das Speicherabbild eines visuellen Programms zu erstellen oder zu verändern, wird
dadurch gelöst, a) daß unmittelbar in dem auf einem Ausgabemedium angezeigten visuellen
Programm mithilfe eines graphischen Eingabewerkzeugs Einfüge-, Änderungs- und
Löschoperationen ausgelöst werden können, b) daß in Abhängigkeit von der Einfüge-, Ände
rungs- und Löschposition innerhalb des visuellen Programms die Menge der möglichen Aktionen
und Eingaben sinnvoll eingeschränkt und dies dem Programmierer angezeigt wird, c) daß in Ab
hängigkeit von der Einfüge-, Änderungs- und Löschposition innerhalb des visuellen Programms
dem Programmierer zusätzliche Hilfsinformationen angezeigt werden und d) daß die Objekte des
Speicherabbilds des visuellen Programms mit Informationen zur Unterstützung des Verfahrens
nach a) bis c) angereichert werden.
Die Erstellung oder Veränderung eines visuellen Programms nach dem hier beschriebenen Ver
fahren erfolgt unmittelbar auf seiner visuellen Darstellung auf dem Bildschirm der Programmier
plattform. Dazu sind für jeden Programmbaustein sogenannte Click-Zonen definiert, in welche
mithilfe einer Rollkugel ("Maus") der Cursor geführt wird und wo durch Betätigung der ver
schiedenen Tasten der Rollkugel neue Programmbausteine eingefügt oder vorhandene gelöscht
oder neu spezifiziert werden können (siehe Fig. 33).
Beim Einfügen in "drag-and-drop"-Technik kann der einzufügende Programmbaustein aus einer
Randleiste des Bildschirms gelöst und entfernt davon zunächst abgelegt werden. Ein anschlie
ßender Click an der Einfügeposition führt zum Einfügen, falls der einzufügende Baustein den Be
dingungen der Einfügeposition genügt. Eine solche Bedingung kann beispielsweise Typkonsistenz
sein oder generelles Verbot des Einfügens für einen Bausteintyp an dieser Position. Im Fehlerfall
wird Hilfsinformation angezeigt.
Bei der Spezifikation eines vorhandenen Programmbausteins führt ein Click in der Zone zur Be
schriftung des Bausteins zur Anzeige eines Fensters mit zulässigen Beschriftungen. Beispiels
weise erscheint bei der Spezifikation eines Containernamens nur die Liste der verfügbaren Con
tainertypen, bei der Spezifikation einer Traverse auf einem Container nur die Traversentypen, die
für diesen Containertyp definiert sind, bei der Spezifikation einer Elementfunktion nur die Namen
derjenigen Funktionen, die für diesen Objekttyp definiert sind, usw. Die Auswahlmöglichkeiten
sind dabei jeweils von der bisherigen Spezifikation abhängig. Die Auswahl eines Listenelements
erfolgt durch Anklicken (siehe Fig. 34).
Die vom Editor selektiv angebotenen Namen für Operanden und Operationen können einerseits
im Zuge der Definition neuer Operanden und Operationen entstehen, andererseits kann der Editor
mit Namenslisten konfiguriert werden, die von außen zugeführt werden. Dazu ist es sinnvoll,
existierende Klassenbibliotheken der Zielsprache durch eine Syntaxanalyse automatisch
auszuwerten und zu klassifizieren.
Die Spezifikation von Beziehungen zwischen Operationen und Operanden kann in "rubber-ban
ding"-Technik erfolgen. Dabei wird der Cursor von der entsprechenden Click-Zone des Operators
bis zum Operanden bewegt, die Taste der Rollkugel beim Start gedrückt und am Ziel losgelassen.
Währenddessen wird die vom Cursor zurückgelegte Strecke farblich markiert. Beim Drücken der
Taste kann zusätzliche Hilfsinformation angezeigt werden, wie z. B. die farblich hervorgehobene
Beschriftung aller zulässigen Zielobjekte an der möglichen Zielposition, mit Einrückung entspre
chend der Schachtelungstiefe.
Die Spezifikation der Zuordnung einer Traverse zu einem Container kann ebenfalls in "rubber
banding"-Technik erfolgen. Dabei ist der Startpunkt des Cursors der Kreuzungspunkt eines Be
ziehungs-Pfeils mit einem Iterator. Der Zielpunkt liegt auf dem Container und wird beim Loslassen
der Taste mit dem Objektnamen des zugeordneten Iterators beschriftet. Der Kreuzungspunkt von
Pfeil und Iterator wird mit einer Kreuzungsmarke belegt.
Jede Spezifikation wird unmittelbar in das Speicherabbild des visuellen Programms übernommen.
Einfügen und Löschen führen ebenfalls zu einer sofortigen Änderung aller Abmessungen und
Positionen der betroffenen Elemente des visuellen Programms. Unter den Attributen eines jeden
Objekts des Speicherabbilds befinden sich seine Koordinaten, seine Abmessungen und seine
Farbe. Zur Ermittlung des Objekts, auf dem sich der Cursor befindet, wird das Speicherabbild
unter Vergleich der Objektkoordinaten mit den Cursorkoordinaten traversiert, bis das Objekt unter
dem Cursor erreicht ist.
Fig. 33 zeigt eine Funktion mit zwei Argumenten und den Click-Zonen A bis F, sowie einen Con
tainer mit Iterator und Elementen vom Typ STRUKTUR mit wiederum zwei Struktur-Elementen
und den Click-Zonen A bis D. Im SPECIFY-Modus führt ein Click in Zone B der Funktion mit an
schließendem Ziehen des Cursors in Zone B eines Objekts zur Definition einer Elementbeziehung
mit entsprechendem L-Pfeil. Ein Click in Zone A der Funktion führt zum Öffnen eines Fensters zur
Eingabe des Funktionsnamens. Falls bereits eine Elementbeziehung zu einem Objekt besteht,
enthält das Fenster nur eine Namensliste von Elementfunktionen dieses Objekts. Ein Click in Zo
ne C der Funktion führt zum Öffnen eines Fensters zur Auswahl bzw. Eingabe von Konstanten.
Zone D der Funktion ist analog zu Zone B für die Definition von Argumentbeziehungen bestimmt,
ebenso Zone F für Zuweisungsbeziehungen. Ein Click in Zone A eines Objekts führt zum Öffnen
eines Fensters zur Auswahl von Klassennamen bzw. zur Eingabe von Objektnamen. Je nach Typ
des Objekts werden nur die verfügbaren SKALAR-, STRUKTUR-, CONTAINER- oder ITERATOR-
Klassen zur Auswahl angeboten. Falls zwischen Iterator und Container bereits eine Zuordnung
besteht, werden nur die für diesen Container definierten Iteratorklassen angeboten. Eine Zuord
nung zwischen Iterator und Container wird festgelegt durch einen Click in Zone C der Überkreu
zung von Iterator und Pfeil, sowie anschließendem Ziehen des Cursors in Zone B des Containers.
Im INSERT-Modus führt, nachdem das einzufügende Programmelement bestimmt ist, ein Click in
die Zonen A + B, E oder F einer Funktion zum Einfügen des Programmelementes an der bezeich
neten Stelle. Ebenso führt ein Click in die Zonen A + B oder D einer vertikalen Verschachtelung
zum Einfügen eines vorher bestimmten Objekts an der bezeichneten Stelle. Im DELETE-Modus
führt ein Click an beliebiger Position eines Programmelementes zum Verschwinden des Pro
grammelementes und beim Loslassen der Maustaste zum endgültigen Löschen.
Fig. 34 zeigt die graphische Benutzeroberfläche des Editors mit einigen visuellen Programmele
menten und einem Auswahlfenster für die Spezifikation der Traverse für einen Container der Klas
se 'cont1'. Dabei enthält die Auswahlliste nur solche Traversen, die für die Containerklasse 'cont1'
definiert sind.
Die Aufgabe, das Speicherabbild eines visuellen Programms in den Quellcode einer textuellen
Programmiersprache zu übersetzen, wird erfindungsgemäß dadurch gelöst, a) daß das Speicher
abbild des visuellen Programms in einer Traverse durchlaufen wird, die der sequentiellen Klam
merdarstellung des Objektbaumes entspricht, b) daß für jedes traversierte Objekt des Speicher
abbildes gemäß seiner Klasse eine Methode aufgerufen wird, die seine Attribute auf syntaktische
Elemente einer Zielsprache oder auf administrative Einheiten eines Betriebssystems abbildet, c)
daß Klassen und ihnen untergeordnete funktionale Einheiten in den Quellcode einer Zielsprache
übersetzt werden, d) daß Module und ihnen übergeordnete funktionale Einheiten in administrative
Einheiten eines Betriebssystems übersetzt werden, und e) daß die Objekte des Speicherabbilds
mit Informationen zur Unterstützung des Verfahrens nach a) bis d) angereichert werden.
Die Übersetzung eines visuellen Programms in den Quellcode einer textuellen Programmierspra
che nach dem hier beschriebenen Verfahren beruht auf einer Traverse, die geeignet ist, die
Baumstruktur des Speicherabbildes auf eine lineare Klammerstruktur abzubilden. Die Traverse
kann sich auch auf einzelne Teilbäume beschränken, die funktionalen Einheiten entsprechen. Die
Traverse wird vorzugsweise rekursiv durchgeführt, wobei virtuelle Methoden aller Objekt-Klassen
des Speicherabbildes an der Rekursion beteiligt sind.
Klassen-, Funktions- und Operationsdefinitionen, sowie untergeordnete Einheiten werden jeweils
in die kontextfreien Satzstrukturen der Zielsprache übersetzt. Dabei wird der Objektbaum der
Operanden entweder auf einen Deklarationsteil abgebildet oder auf Datenelemente einer Klasse.
Der Baum der Operationen wird auf Funktions- oder Operationsaufrufe mit, möglicherweise ver
schachtelten, Ausdrücken als Argumenten abgebildet. Argument-, Element- und Zuweisungsbe
ziehungen werden im einfachsten Fall auf Objektnamen, Element- bzw. Zuweisungssymbole ab
gebildet. Zugriffe auf verschachtelte Strukturen werden auf Pfadbeschreibungen mit möglicher
weise mehreren Komponenten abgebildet. Zugriffe auf Container über Iteratoren werden im all
gemeinen Fall auf eine kontexffreie Klammerungsstruktur abgebildet.
Für die einheitliche Behandlung von Zugriffen auf Container unterschiedlichster Art wird für jeden
Container der []-Operator überladen. Sein Returnwert ist eine Referenz auf das adressierte Con
tainer-Element und kann somit sowohl auf der linken (schreibend) als auch auf der rechten Seite
(lesend) einer Zuweisung stehen. Parameter des []-Operators ist jeweils ein Iterator aus einer Un
terklasse der dem jeweiligen Container zugeordneten Iteratorklasse. Die Kreuzungsmarke visuali
siert die Auswahl des Iterators, der als Parameter für den []-Operator verwendet wird. Der allge
meine Containerzugriff erfolgt somit analog zum herkömmlichen Zugriff auf Feldelemente über
den []-Operator und einen Indexwert. Bei der Parameterübergabe können Konsistenzprüfungen
vorgenommen werden und Maßnahmen zur Verbesserung der Performance, wie z. B. Caching, er
griffen werden.
Module, Komponenten, Systemebenen, Systeme und sonstige höhere funktionale Einheiten, für
die kein direktes Gegenstück in der Zielsprache existiert, werden in administrative Einheiten des
Betriebssystems der Zielplattform übersetzt. Hierzu zählen Verzeichnisstrukturen, die als Produkt
baum des generierten, textuellen Quellprogramms betrachtet werden können, zusammen mit den
ihnen zugeordneten, sogenannten "Make-Files", die administrative Anweisungen zur Strukturie
rung des Systems enthalten. Damit kann der aus den Klassen-, Funktions- und Operationsdefini
tionen generierte Quellcode weiter strukturiert und zu höheren funktionalen Einheiten zusammen
gefaßt werden. Solche Einheiten sind beispielsweise textuelle Funktionsbibliotheken, aber auch
sogenannte "Header-Files" zur Zusammenlegung von Klassendefinitionen, zusammen mit wei
teren Dateien, welche die Definitionen der Elementfunktionen enthalten. Eine weitere hierarchi
sche Anordnung des generierten Quellcodes kann direkt auf die Verzeichnisstruktur abgebildet
werden, wobei für jedes Verzeichnis ein passendes Makefile generiert wird.
Für die Umsetzung der Objekte des Speicherabbilds in strukturierten Quellcode ist es nötig, die
Objekte mit zusätzlichen Informationen anzureichern, die teils direkt vom Benutzer beim Editieren
eingetragen werden, teils während des Editierens oder auch während des Übersetzungsvorgangs
automatisch erzeugt werden. Vom Benutzer werden beispielsweise Klassen- und Funktions
namen, Operationssymbole und Konstanten mithilfe des Editors eingegeben, während Objekt
namen auch automatisch generiert werden können. Die Spezifikation eines Zugriffs auf Container
über Iteratoren durch den Benutzer führt automatisch zur Erzeugung von Strukturinformation über
den gesamten Zugriffsweg, der Verschachtelungen und Einbettungen von Iteratoren enthalten
kann. Diese Information wird beim Übersetzungsvorgang ausgewertet.
Bei der Übersetzung des Speicherabbildes kann, in den generierten Quellcode eingestreut, zu
sätzlicher Code erzeugt werden, der zur Laufzeit auf die Objekte des Speicherabbildes zugreift,
um dort Informationen für Test, Fehlersuche oder Animation abzulegen. Dazu sind die Klassen
der Speicherobjekte mit weiteren Attributen anzureichern.
Im Einzelnen werden die Programmbausteine der in 5.3 exemplarisch angegebenen visuellen
Programmiersprache wie folgt, und ebenfalls exemplarisch, in die Zielsprache C++ übersetzt:
Fig. 35 zeigt ein skalares Objekt mit Klassenamen 'int', Objektnamen 'i' und Anfangswert '0'.
Übersetzung in "int i = 0;".
Fig. 36 zeigt eine Struktur mit Strukturnamen 'date', Objektnamen 'd' und seinen offengelegten
Strukturelementen. Übersetzung in "date d;".
Fig. 37 zeigt eine Struktur mit Strukturnamen 'item' und Objektnamen 'p', deren erstes, unspe
zifiziertes, Strukturelement vom Typ 'STRUCTURE' durch eine Struktur der Klasse 'date' ersetzt
wurde. Übersetzung in die Template-Deklaration "item<date< p;".
Fig. 38 zeigt einen Container mit Klassennamen 'array' und Objektnamen 'a', welcher Objekte
der Klasse 'type' enthält. Übersetzung in die Template-Deklaration "array<type< a;". Eine zusätz
liche Größenangabe in der Spezifikation des Containers kann auf einen weiteren Template-
Parameter abgebildet werden.
Fig. 39 zeigt einen Container mit Klassennamen 'array' und Objektnamen 'a', welcher wiederum
Objekte der Klasse 'array' enthält, die jeweils Objekte der Klasse 'type' enthalten. Übersetzung in
die verschachtelte Template-Deklaration "array<array<type<< a".
Fig. 40 zeigt zwei skalare Objekte mit Objektnamen 'a' und 'b', sowie eine Zuweisung von 'a'
nach 'b'. Übersetzung in "a = b;".
Fig. 41 zeigt zwei skalare Objekte mit den Klassennamen 'cart' bzw. 'polar' und den Objektna
men 'c' bzw. 'p', sowie einer Zuweisung mit Cast-Anpassung. Übersetzung in "c = (cart)p" oder
"c = cart(p).
Fig. 42 zeigt vier skalare Objekte mit den Objektnamen 'a', 'b', 'c' und 'd', sowie den Aufruf einer
Elementfunktion von 'a' mit dem Funktionsnamen 'f'. 'b' und 'c' sind Eingabeparameter von 'f'. Das
Ergebnis des Aufrufs wird an 'd' zugewiesen. Übersetzung in "d = a.f(b,c)".
Fig. 43 zeigt vier skalare Objekte mit den Objektnamen 'a', 'b', 'c' und 'd', sowie den Aufruf eines
Elementoperators von 'a' mit dem Operatorsymbol '*'. 'b' und 'c' sind Eingabeparameter von '*'.
Das Ergebnis der Operation wird an 'd' zugewiesen. Übersetzung in "d = a.operator*(b, c);".
Fig. 44 zeigt vier skalare Objekte mit den Objektnamen 'a', 'b', 'c' und 'd', sowie zwei Aufrufe von
Funktionen mit den Namen 'f bzw. 'g'. 'g' besitzt die beiden Eingabeparameter 'b' und 'c'. 'f'
besitzt den Eingabeparameter 'a', sowie als zweiten Eingabeparameter das Ergebnis des Funk
tionsaufrufs von 'g'. Übersetzung in "d = f(a,g(b,c));".
Fig. 45 zeigt vier skalare Objekte mit den Objektnamen 'a', 'b', 'c' und 'd', sowie einem ver
schachtelten Aufruf von zwei Funktionen mit den Namen 'f und 'g'. Die Eingabeparameter von 'g'
sind 'a' und 'b'. Der Eingabeparameter von 'f' ist das Ergebnis des Funktionsaufrufs von 'g', das
zusätzlich einem Objekt mit Namen 'c' zugewiesen wird. Das Ergebnis des Funktionsaufrufs von
'f' wird einem Objekt namens 'd' zugewiesen. Übersetzung in "d = f(c = g(a,b));".
Fig. 46 zeigt eine Struktur mit dem Objektnamen 's1', welche Strukturelemente mit den Objekt
namen 'a', 'b' und 's2' besitzt. 's2' ist selbst eine Struktur und besitzt die Strukturelemente mit
Namen 'c' und 'd'. Der lesende und schreibende Zugriff auf 'b' wird übersetzt in "s1.b". Der le
sende und schreibende Zugriff auf 'c' wird übersetzt in "s1.s2.c".
Fig. 47 zeigt einen Container mit dem Klassennamen 'tree' und dem Objektnamen 't', der
Objekte der Klasse 'type' enthält. Der lesende und schreibende Zugriff auf den Container als Gan
zes wird übersetzt in "t".
Fig. 48 zeigt einen Container mit dem Klassennamen 'tree' und dem Objektnamen 't', der Objek
te der Klasse 'type' enthält, sowie einen Iterator mit Klassennamen 'itr' und Objektnamen 'i 25024 00070 552 001000280000000200012000285912491300040 0002019907328 00004 24905'. Der
lesende und schreibende Zugriff auf ein Containerelement an der durch 'i' spezifizierten Position
wird übersetzt in "t[i]".
Fig. 49 zeigt einen Container mit Klassennamen 'array' und Objektnamen 'a', welcher Objekte
der Klasse 'tree' enthält, die jeweils Objekte der Klasse 'type' enthalten. Dem äußeren Container
ist ein Iterator mit Klassennamen 'itr1' und Objektnamen 'i' zugeordnet. Dem inneren Container ist
ein Iterator mit Klassennamen 'itr2' und Objektnamen 'k' zugeordnet. Der lesende und schreiben
de Zugriff auf ein Element der Containerverschachtelung an der durch 'i' und 'k' spezifizierten Po
sition wird übersetzt in "a[i][k]".
Fig. 50 zeigt zwei Container mit den Klassennamen 'array' bzw. 'tree' und den Objektnamen 'a'
bzw. 't'. 'a' enthält Iterator-Objekte der Klasse 'itr2', die dem Container 't' zugeordnet sind. Dem
Container 'a' ist ein Iterator mit Klassennamen 'itr1' und Objektnamen 'i' zugeordnet. Der indirekte
lesende und schreibende Zugriff auf ein Element des Containers 't' an der durch den Iterator 'a[i]'
spezifizierten Position wird übersetzt in "t[a[i]]".
Fig. 51 zeigt einen sowohl indirekten als auch verschachtelten Zugriff auf Elemente eines Con
tainers mit Objektnamen 'c4'. Die 'c4' zugeordneten Iteratoren 'i4' sind Elemente der Container
verschachtelung 'c3' und 'c2'. Die diesen Containern zugeordneten Iteratoren 'i3' und 'i2' sind Ele
mente von Strukturen, die in einem Container mit Objektnamen 'c1' enthalten sind. Diesem Con
tainer ist der Iterator 'i1' zugeordnet. Der indirekte und verschachtelte, lesende und schreibende
Zugriff auf ein Element von 'c4' wird übersetzt in "c4[c2[c1[i1].i2][c1[i1].i3]]".
Fig. 52 zeigt eine selektive Kontrollstruktur mit einer Pre-Condition, die dem Wert des Objekts 'a'
entspricht, sowie einem Case-Block vom Typ 'SELECT', in dem ein Aufruf der Funktion '1'
enthalten ist. Übersetzung in "if(a){f(x,y);}".
Fig. 53 zeigt eine repetitive Kontrollstruktur mit einem Prolog zur Initialisierung der Pre-Condi
tion, die dem Wert des Objekts 'a' entspricht, sowie einem Case-Block vom Typ 'REPEAT', in dem
ein Aufruf der Funktion 'g' enthalten ist. Übersetzung in "{x.operator*(y);f(u,v);while(a){g();}}".
Fig. 54 zeigt eine selektive Kontrollstruktur mit einer Pre-Condition, die dem Wert von 'a' ent
spricht, sowie mit Case-Blöcken unterschiedlicher Post-Conditions. Falls die Pre-Condition den
Wert '1' annimmt, wird die Funktion 'f' aufgerufen. Anderenfalls wird die Funktion 'g' aufgerufen.
Übersetzung in "if(a){f();}else{g();}".
Fig. 55 zeigt eine selektive Kontrollstruktur mit einer Pre-Condition, die dem Wert von 'a' ent
spricht, sowie mit Case-Blöcken, die sich im Vergleichsoperator ihrer Post-Conditions unterschei
den. Übersetzung in "if(a<0){f();}else if(a==0){g();}else if(a<0){h();}".
Fig. 56 zeigt eine gemischt selektive und repetitive Kontrollstruktur mit einer Pre-Condition, die
dem Wert von 'a' entspricht, sowie mit zwei Case-Blöcken vom Typ 'REPEAT', nach deren
Ausführung ein Rücksprung auf die Pre-Condition erfolgt. Nach Ausführung des Case-Blockes
vom Typ 'SELECT' wird die Kontrollstruktur verlassen. Übersetzung in "label:switch(a){case 5:f();
goto label;case 9:g();break;default:h();goto label;}".
Fig. 57 zeigt ein Objekt der Speicherklasse 'DYNAMIC' mit Klassennamen 'dyn' und Objektna
men 'd', welches ein Objekt der Klasse 'Type' enthält, sowie einen Iterator mit dem Klassennamen
'itr' und dem Objektnamen 'i'. Übersetzung in "dyn<Type< d;itr<Type< i;". Die dynamische Spei
cherplatzzuweisung für ein Objekt der Klasse 'Type' erfolgt durch den Aufruf von 'create', Ele
mentfunktion von 'd'. Das Ergebnis des Aufrufs ist ein Iteratorwert, der 'i' zugewiesen wird. Über
setzung in "i = d.create();". Die Speicherplatzfreigabe erfolgt durch Aufruf von 'destroy', Element
funktion von 'd', mit Parameter 'i'. Übersetzung in "d.destroy(i);".
Fig. 58 zeigt die Definition einer Funktion namens 'func'. Im Datenteil befinden sich drei Objekte
mit den Klassennamen 'A', 'B' bzw. 'C', sowie den Objektnamen 'a', 'b' bzw. 'c'. 'b' ist als
Eingabeparameter gekennzeichnet. 'c' ist als Ein- und Ausgabeparameter gekennzeichnet und
wird durch die Funktion verändert. Der Rücksprung erfolgt mithilfe des Terminators 'return'. Re
turnwert ist das Objekt 'a'. Übersetzung in "A func(B,C& c){B b(_b);A a; . . . a = c + b;c--; . . .
return(a);}".
Fig. 59 zeigt die Definition einer Klasse namens 'X'. Die Klasse enthält drei Datenelemente mit
den Klassennamen 'A', 'B' bzw. 'C', und den Objektnamen 'a', 'b' bzw. 'c'. Übersetzung in "class
X{A a;B b;C c; public: . . . f1(. . .){. . .} . . . f2(. . .){. . .} . . . f3(. . .){. . .}};".
Fig. 60 zeigt eine Klasse namens 'X' und eine von ihr abgeleitete Klasse namens 'Y'. 'X' enthält
zwei Datenelemente mit den Klassennamen 'A' und 'B', sowie zwei Elementfunktionen mit Namen
'f1' und 'f2'. 'f1' ist als virtuell deklariert. 'Y' enthält ein Datenelement mit dem Klassennamen 'C'
und dem Objektnamen 'c', sowie zwei Elementfunktionen mit Namen 'f1' und 'f2'. 'Y::f1' ist eine
Redefinition der gleichnamigen Elementfunktion von 'X'. Übersetzung in "class X {protected:A a; B
b; public:virtual . . . f1(. . .){. . .} . . . f2(. . .){. . .}};class Y:public X {C c;public: . . . f1(. . .){. . .} . . . f3(. . .){. . .}};".
Fig. 61 zeigt die Definition eines Containers namens 'cont'. 'cont' enthält ein Objekt der Spei
cherklasse 'DYNAMIC' mit Klassennamen 'dyn' und Objektnamen 'd', welches ein Objekt der
Klasse 'B' enthält. Die Klassenbezeichnung 'B' ist als Parameter des Containers gekennzeichnet.
'd' ist für die dynamische Speicherplatzverwaltung ein Iterator der Klasse 'itr' mit Objektnamen 'i'
zugeordnet. 'cont' enthält ein weiteres Datenelement namens 'a', dessen Klassenbezeichnung 'A'
ebenfalls als Parameter von 'cont' gekennzeichnet ist. 'cont' ist für die Traversierung ein Iterator
zugeordnet mit Klassennamen 'iter' und Objektnamen 'i1'. Übersetzung in "template<class A,
class B< class cont{dyn<B< d;itr<B< i;A a; . . . friend . . . iter<B< i1(. . .);};".
Die Aufgabe, das Speicherabbild eines visuellen Programms in einem nicht-flüchtigen Speicher
aufzubewahren und von dort wieder zurück in den Arbeitsspeicher zu befördern, wird erfindungs
gemäß dadurch gelöst, a) daß das Speicherabbild des visuellen Programms als zusammenhän
gendes Objekt mit allen seinen internen Beziehungen vom Arbeitsspeicher in eine objekt-orein
tierte Datenbank verlagert wird, b) daß das Speicherabbild als zusammenhängendes Objekt mit
allen seinen internen Beziehungen aus einer objekt-orientierten Datenbank in den Arbeitsspeicher
verlagert wird, und c) daß das Speicherabbild zur Unterstützung des Verfahrens nach a) und b)
mit zusätzlichen Informationen angereichert wird.
Die Aufbewahrung des Speicherabbildes eines visuellen Programms nach dem hier beschriebe
nen Verfahren nutzt die Fähigkeit objektorientierter oder objekt-relationaler Datenbanken aus,
Objekte nicht nur mit ihren Attributen, sondern auch mit all ihren Beziehungen untereinander
abzuspeichern, sodaß erstens jederzeit eine schnelle Wiederherstellung des Speicherabbilds im
Arbeitsspeicher möglich ist und zweitens die Integration unterschiedlichster Entwicklungsdaten
mit allen ihren internen Beziehungen langfristig erhalten bleibt. Die objekt-orientierte Datenbank
ist damit zentraler Bestandteil der hier beschriebenen Programmierumgebung.
Verschiedene Funktionen der Programmierumgebung können, ganz oder teilweise, unmittelbar
durch Standardfunktionen einer objekt-orientierten bzw. objekt-relationalen Datenbank realisiert
werden, so etwa die Versionsverwaltung, Aufgaben der Statistik und des Archivierens, Namens
verwaltung (durch Invertier- und Suchfunktionen), Team-Arbeit (durch Zugriffssynchronisation,
Locking- und Transaktionsmechanismen), Integration und Editieren mit versuchsweisem Einfügen
(durch Roll-Back- und Integritätsmechanismen), sowie Navigation und Recherche (durch navigie
rende und assoziative Zugriffsmechanismen und Suchanfragen).
Das Speicherabbild eines visuellen Programms kann ganz oder teilweise von bzw. zu der Daten
bank übertragen werden. Die Selektion von Teilen des Speicherabbilds kann aufgrund topologi
scher Kriterien erfolgen, wie etwa bei der Selektion eines Teilbaumes, oder aufgrund einer boole
schen Suchanfrage, die auch eine topologisch nicht zusammenhängende Treffermenge ergeben
kann. Die selektierten Objekte können für eine Anzeige topologisch ergänzt und farblich weiter
aufbereitet werden. Um den selektiven Zugriff auf ein in der Datenbank befindliches Speicherab
bild zu unterstützen, können die Objekte, z. B. durch Indexieren, mit zusätzlichen Informationen
angereichert werden.
Die Aufgabe, das Speicherabbild eines visuellen Programms graphisch wiederzugeben, wird erfindungsmäßig
dadurch gelöst a) daß das Speicherabbild des visuellen Programms, ganz oder
teilweise, in unterschiedlichen Hierarchiestufen, Abstraktionsebenen, Detaillierungsgraden und
Maßstäben wiedergegeben wird, b) daß Beziehungen und Abhängigkeiten zwischen Teilen des
Speicherabbildes graphisch hervorgehoben werden, c) daß Verzweigungsebenen des Speicher
abbildes drei-dimensional geschichtet und in perspektivischer Ansicht dargestellt werden, d) daß
Teile der graphischen Wiedergabe des Speicherabbildes vorübergehend mit Teilen eines fremden
Speicherabbildes graphisch überlagert werden und e) daß die Objekte des Speicherabbilds mit
Informationen zur Unterstützung des Verfahrens nach a) bis d) angereichert werden.
Die graphische Wiedergabe eines visuellen Programms kann in Übersichts- und Detailansichten
erfolgen, die auf verschiedene Fenster einer graphischen Benutzeroberfläche verteilt sein oder
auf anderen graphischen Ausgabemedien dauerhaft ausgegeben werden können. Diese Ansich
ten können durch Hilfsinformationen ergänzt sein, wie z. B. Orientierungsangaben, Beschriftungen
und Dokumentation. Die Wiedergabe kann selektiv erfolgen, indem einzelne Teile der Systemhier
archie hervorgehoben werden, indem Abstraktionen und Vergröberungen angewandt werden und
indem auch durch Maßstabsänderungen Detaillierungsgrad und Umfang der angezeigten System
teile verändert werden.
Die graphische Wiedergabe visualisiert die Beziehungen und Abhängigkeiten zwischen den visu
ellen Programmelementen durch farbliche Hervorhebung relevanter Teile oder Ausblenden nicht
relevanter Teile. Beispiele sind die Hierarchien für Aufruf und Benutzung von Funktionen, sowie
die Verkettung von Funktionsaufrufen über Objekte und von Objekten über Funktionsaufrufe.
Ebenso können Ergebnismengen aus topologie- oder attributbezogenen Suchanfragen sichtbar
gemacht werden. Das Speicherabbild kann hierfür mit geeigneten Attributen angereichert werden.
Weitere Beziehungen ergeben sich aus Nachbarschaften bezüglich einer Entwurfsdimension, wie
z. B. die Fehlerbehandlung, deren funktionale Elemente nach Anwendungs- und Systembezug
sortiert und sichtbar gemacht werden können.
Die graphische Wiedergabe umfaßt auch die Visualisierung des Entwurfsprozesses. Grundlage
hierfür ist eine Zuordnung von Programmelementen zu Leistungsmerkmalen des Programms.
Hierzu muß das Speicherabbild um Attribute zur Kodierung von Leistungsmerkmalen und zur Auf
nahme von Zeitmarken angereichert werden. So kann während des Editiervorgangs dem Pro
grammierer laufend angezeigt werden, welches Leistungsmerkmal editiert wird und welche Pro
grammelemente bisher dafür verwendet wurden. Ebenso ist es möglich, das Speicherabbild ge
mäß der zeitlichen Abfolge des Entwurfsprozesses nach Leistungsmerkmalen durchzublättern.
Analog zum Entwurfsprozeß kann auch mit den verwendeten Entwurfsmustern verfahren werden.
Alle Verzweigungen des Speicherabbildes, die keine zeitliche Aufeinanderfolge beinhalten, kön
nen auch in Form einer dreidimensionalen Schichtung von Funktionsebenen angeordnet und in
perspektivischer Sicht wiedergegeben werden. Dazu gehören die funktionalen Einheiten von
SELECT- und REPEAT-Anweisungen (Cases), parallel auszuführende Anweisungen (Threads)
und Anweisungsfolgen für den Fehlerfall (Exception Handling). Weitere sinnvolle Beispiele sind
funktionale Einheiten ohne Kommunikation über globale Objekte, so etwa Systemebenen.
Für Clipboard-Operationen während des Editierens, für die Integration größerer Systemteile, so
wie für die Gegenüberstellung und den Vergleich von Systemkomponenten sollen Teile der gra
phischen Wiedergabe des Speicherabbildes vorübergehend mit Teilen eines fremden Speicher
abbildes graphisch überlagert werden können. Dadurch können versuchsweise Einfüge- und Er
setzungsoperationen graphisch unterstützt werden, Entwurfsalternativen gegenübergestellt, Ent
wurfsmuster oder wiederverwendbare Komponenten eingepaßt werden.
Die Aufgabe, das Speicherabbild eines visuellen Programms zu dokumentieren, wird erfindungs
gemäß dadurch gelöst, a) daß unmittelbar in dem auf einem Bildschirm angezeigten visuellen
Programm mithilfe eines graphischen Eingabewerkzeugs Operationen zur Eingabe von Dokumen
tationstexten, Kommentaren und andersartiger Information ausgelöst werden können, b) daß in
Abhängigkeit von der Eingabeposition innerhalb des visuellen Programms die eingegebene Do
kumentation einzelnen Programmelementen zugeordnet wird, c) daß die einem Programmelement
zugeordnete Dokumentation während der Bearbeitung des Programms jederzeit lokal zur Ver
fügung steht, d) daß für jede funktionale Einheit die Dokumentation ihrer Programmelemente in
geschlossener Form ausgegeben werden kann, und e) daß die Objekte des Speicherabbilds mit
Attributen zur Unterstützung des Verfahrens nach a) bis d) angereichert werden.
Die Dokumentation eines visuellen Programms wird unmittelbar in das Programm selbst integriert
und steht während des Editierens oder bei graphischen Wiedergaben lokal zur Verfügung. Die
den einzelnen Programmelementen zugeordneten Dokumentationen können für jeden Teilbaum
des Speicherabbilds zu einem Gesamtdokument extrahiert werden, das entsprechend der
Baumstruktur des Speicherabbilds hierarchisch gegliedert ist. Weiterhin kann es mit Übersichts-
oder Detaildarstellungen des visuellen Programms ergänzt werden.
Die Aufgabe, das Speicherabbild eines visuellen Programms zu verwalten, wird erfindungsgemäß
dadurch gelöst, a) daß der der Projektstatus aus der attributiven und topologischen Vollständigkeit
seines Speicherabbildes automatisch ermittelt wird, b) daß der Entstehungsgang des Speicherabbilds
protokolliert wird und der zukünftige Projektverlauf aus dem bisherigen Entstehungsgang
des Speicherabbilds automatisch ermittelt wird, c) daß die Verwaltung von Namens- und Typ-
Information von Operanden und Operationen durch Standardfunktionen einer objekt-relationalen
Datenbank geleistet wird, d) daß die Verwaltung von Versionen, Entwurfsalternativen und Ent
wurfsmustern durch Standardfunktionen einer objekt-relationalen Datenbank geleistet wird und e)
daß die Objekte des Speicherabbildes mit Informationen zur Unterstützung des Verfahrens nach
a) bis d) angereichert werden.
Der Projektstatus einer visuellen Programmentwicklung kann näherungsweise dem Zustand des
Speicherabbildes entnommen werden. Er entspricht in etwa der Vollständigkeit des Speicherabbil
des. Diese kann, attribut- und topologiebezogen, aus dem bereits vorhandenen Speicherabbild
extrapoliert werden. Beispielsweise gehören zu einer Container-Spezifikation die Angabe von
Klassen- und Instanznamen, die Spezifikation der Container-Elemente, ein Iterator, eine Zuord
nung des Iterators zu dem Container, eine Spezifikation der Traverse und des Namens für den Ite
rator, Zugriffspfeile auf den Container, Kreuzungsmarken für Zugriffspfeile und Iterator, Zugriffe
auf den Iterator, usw. Aus der Zusammengehörigkeit der verschiedenen Spezifikationen kann
durch Nachprüfen der Attribute und der Topologie des Speicherabbilds die Vollständigkeit ermittelt
werden. Diese läßt sich auch differenziert nach Ebenen, Klassen, Funktionen, Operanden, Ope
ratoren, Typ- und Namensspezifikationen, Traversen für Container, Zugriffspfeile, Kreuzungs
marken und Dokumentation ermitteln. Als Maßstab für die Vollständigkeit kann auch die Compi
lierbarkeit gewählt werden. Ebenso kann als Statusinformation auch eine attribut- oder topo
logiebezogene Statistik ausgegeben werden.
Der Projektverlauf kann näherungsweise dem Entstehungsgang der Leistungsmerkmale des Spei
cherabbildes entnommen werden. Dieser kann protokolliert werden durch Zuordnung von Zeit-,
Personen- und Planungsdaten zu den funktionalen Einheiten des Speicherabbildes. Hierfür ist das
Speicherabbild mit entsprechenden Attributen anzureichern. Der weitere Projektverlauf kann aus
dem Projektstatus und dem bisherigen Projektverlauf extrapoliert werden. Die Genauigkeit der
automatischen Schätzungen von Projektstatus und Projektverlauf nimmt mit zunehmender Voll
ständigkeit des Speicherabbildes zu.
Die verfügbaren, selbstdefinierten oder importierten, Funktionen, Datenstrukturen, Klassen und
Entwurfsmuster werden gemeinsam verwaltet. Ihre Namens-, Typ- und Struktur-Information kann
in Übersichten angezeigt und direkt in Arbeitsgänge wie Editieren oder Dokumentieren eingeführt
werden. Diese Informationen können nach verschiedenen Kriterien invertiert und sortiert werden.
Dafür kann eine relationale Erweiterung einer objekt-orientierten Datenbank mit ihren Standard
funktionen verwendet werden.
Die Aufgaben der Versionsverwaltung können ebenfalls durch die Standardfunktionen der Daten
bank unterstützt werden. Analog dazu kann auch die Verwaltung von Entwurfsalternativen und
Entwurfsmustern erfolgen.
Die Aufgabe, in der graphischen Wiedergabe des Speicherabbildes eines visuellen Programms zu
navigieren, wird erfindungsgemäß dadurch gelöst, a) daß die Anzeige der Objekte des Speicher
abbilds des visuellen Programms in topologischen und assoziativen Traversen verläuft, b) daß die
Anzeige der Objekte des Speicherabbilds zwischen verschiedenen Abstraktionsebenen, Detaillie
rungsgraden und Maßstäben wechselt, c) daß eine perspektivische Anzeige drei-dimensional an
geordneter Objekte des Speicherabbilds durch allmähliche Richtungsänderung, Annäherung und
Entfernung erfolgt, d) daß Hilfsinformation zur Orientierung, Dokumentation und Verwaltung ange
zeigt wird und e) daß die Objekte des Speicherabbilds mit Informationen zur Unterstützung des
Verfahrens nach a) bis d) angereichert werden.
Die Betrachtung eines visuellen Programms soll nicht nur am stehenden Bild erfolgen, sondern
auch mittels einer scheinbaren Bewegung des Betrachters durch das Speicherabbild, die seinen
Entwurfsüberlegungen oder diversen Funktionszusammenhängen folgt. Die Betrachtung kann in
perspektivischer Sicht auf die funktionalen Einheiten geschehen, insbesondere auf dreidimensio
nal angeordnete Verzweigungsebenen wie z. B. für Cases, Threads und Exceptions. Die Bewe
gung kann in unterschiedlichen, kontinuierlichen Tempi erfolgen, mit Schwenks in der Blickrich
tung, Annäherungen an Details und Entfernungen. Betrachtung und Bewegung können durch
Wechsel der Perspektive, der Abstraktionsebene, des Detaillierungsgrades und der Position auch
sprunghaft verändert werden. Sie können einerseits der Baumstruktur des Speicherabbilds folgen,
andererseits funktionalen Zusammenhängen, wie Kontrollfluß, Aufruf- und Benutzungshierarchien
oder die Treffermenge einer Suchanfrage traversieren. Durch graphische und textuelle Hilfsinfor
mation kann der Betrachter bei seiner Orientierung im System unterstützt werden.
Die Aufgabe, die graphische Wiedergabe des Speicherabbilds eines visuellen Programms zu ani
mieren, wird erfindungsgemäß dadurch gelöst, daß Funktionsabläufe, Zusammenhänge und Ab
hängigkeiten innerhalb des visuellen Programms durch aufeinanderfolgende farbliche oder aku
stische Kennzeichnung hervorgehoben werden.
In der graphischen Wiedergabe eines visuellen Programms kann durch aufeinanderfolgende farb
liche Kennzeichnung beispielsweise der Kontrollfluß deutlich gemacht werden. Dabei können in
jedem Ablaufschritt alle beteiligten Funktionen, Operationen, Zugriffspfeile und Objekte farblich
hervorgehoben werden. Die Animation des Kontrollflusses kann mit oder ohne Ergänzung durch
Laufzeitwerte erfolgen. Im ersten Fall können den Objekten des Speicherabbilds beim Ablauf des
visuellen Programms durch besonders generierte Anweisungen Werte zugewiesen werden, die in
einer anschließenden Animation abgespielt werden können. Diese Anweisungen können optional
bei der Übersetzung des Speicherabbilds in den Quellcode eingestreut werden. Die Animation
wird dabei durch den Datenfall bestimmt und läuft automatisch ab, wobei Laufzeitfehler an ihrem
Entstehungsort angezeigt werden. Im zweiten Fall wird der Kontrollfluß durch Anklicken von
Cases manuell gesteuert.
Die an einem Programmdurchlauf beteiligten Funktionen, Operationen, Zugriffspfeile und Objekte
können auch simultan angezeigt werden. Damit können die aktiven Bereiche eines Programms
sichtbar gemacht werden. Dies kann wieder abhängig von einem konkreten Datenfall geschehen
oder manuell gesteuert durch Anklicken von Cases. Durch wechselnde Anzeige verschiedener
Bereiche kann die Auswirkung verschiedener Datenfälle gegenübergestellt werden. Weitere Bei
spiele für eine simultane Anzeige von Programmelementen sind die Aufruf- und Benutzungshier
archien. Auch Treffermengen zu unterschiedlichen Suchanfragen können so in wechselnder Ab
folge einander gegenübergestellt werden.
Das erfindungsgemäße Verfahren erlaubt, in Anlehnung an den Entwurf integrierter Schaltkreise,
die Anwendung von CAD-Methoden auf den Programmentwurf. Insbesondere ist nicht das lauf
fähige Programm, noch dessen Quellcode, das eigentliche Endprodukt des Verfahrens, sondern
dessen visuelle Spezifikation. Aus ihr kann der Quellcode bei Bedarf automatisch generiert wer
den. Die Arbeitsgrundlage des Ingenieurs ist jedoch in jeder Phase des Programmlebenszyklus
die visuelle Spezifikation nach dem hier beschriebenen Verfahren. Aus ihr können verschiedene
graphische Darstellungen generiert werden, durch die der Ingenieur, seinen Entwurfs- oder sonsti
gen Überlegungen entsprechend, navigieren kann, die er animieren und bearbeiten kann. Die Be
arbeitung wird, kontext-abhängig, durch den hier beschriebenen Editor geführt und so weitestgeh
end gegen Fehler abgesichert. Das Speicherabbild der visuellen Spezifikation wird langfristig mit
allen seinen internen Bezügen und Zusatzinformationen in einer objekt-orientierten Datenbank
abgelegt und ist einer Vielzahl unterschiedlichster Recherchen zugänglich, deren Ergebnisse
wiederum graphisch dargestellt werden können. Teamarbeit am Programm wird teils durch Funk
tionen der Datenbank, teils durch CAD-Funktionen zur Arbeitsorganisation unterstützt.
Gegenüber der textuellen Programmierung besitzt das angegebene Verfahren im Wesentlichen
folgende Vorteile: (1) Dadurch daß Abhängigkeiten zwischen den Programmelementen sichtbar
sind, wird ein visuelles Programm verständlicher. Unbeabsichtigte Abhängigkeiten werden weit
gehend verhindert. (2) Durch die Möglichkeit der Abstraktion und Vergröberung und durch schnel
le Wechsel zwischen Übersichts- und Detailansichten wird ein visuelles Programmsystem
durchschaubarer. (3) Durch die Benutzerführung des visuellen Editors wird der Entwurf schneller
und fehlersicherer. (4) Der Übergang zwischen Spezifikation und Implementierung ist fließend,
ebenso die Übergänge zwischen den Phasen des Programmlebenszyklus, für die das in der
objekt-orientierten Datenbank liegende Speicherabbild eine konsistente Grundlage liefert. Gegen
über anderen bekannten visuellen Programmierverfahren besitzt das angegebene Verfahren den
Vorteil, daß es die imperative, d. h. auf Zuweisungen basierende, Programmierung unterstützt. Da
es außerdem objekt-orientiert und allgemein ist, kann es als unmittelbare Visualisierung der in der
Praxis derzeit gebräuchlichsten Programmiersprache, nämlich C++, verwendet werden.
Claims (72)
1. Verfahren zur visuellen Programmierung eines Computers, dadurch gekennzeichnet, daß
- a) Funktionen und/oder Operationen, welche einfache und/oder ineinander ver schachtelte Funktions- und/oder Operationsaufrufe mit ihren Argumenten aufweisen, gemäß ihren Nachbarschafts- und Inklusionsbeziehungen zueinander durch eine erste Baumstruktur visualisiert werden,
- b) Operanden, welche einfache und/oder ineinander verschachtelte Objekte und/oder Datenstrukturen aufweisen, gemäß ihren Nachbarschafts- und Inklusionsbeziehungen zueinander durch eine zweite Baumstruktur visualisiert werden, und
- c) daß Beziehungen, zwischen den Operationen und/oder Funktionen einerseits und den Operanden andererseits durch graphische Verbindungen zwischen Elementen der er sten Baumstruktur und Elementen der zweiten Baumstruktur visualisiert werden.
2. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 1, dadurch
gekennzeichnet, daß als Operand Argument-, Zuweisungs-, Element- oder andere Bezieh
ungen dienen.
3. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 1 oder 2, da
durch gekennzeichnet, daß ein Operand durch ein Baumelement visualisiert wird, das mit
einem Klassen- und einem Objektnamen beschriftet ist.
4. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 1, 2 oder 3,
dadurch gekennzeichnet, daß ein aus einer festen Anzahl unterschiedlicher Operanden
zusammengesetzter Operand durch ein Baumelement visualisiert wird, das mit einem
Klassen- und einem Objektnamen beschriftet ist und dem die feste Anzahl von Baumele
menten folgt, welche seine unterschiedlichen Elemente repräsentieren.
5. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 4, dadurch gekennzeichnet, daß ein aus einer variablen Anzahl gleichartiger Operan
den zusammengesetzter Operand durch ein Baumelement visualisiert wird, das mit einem
Klassen- und einem Objektnamen beschriftet sein kann und dem ein Baumelement folgt,
welches stellvertretend seine gleichartigen Elemente repräsentiert.
6. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 5, dadurch gekennzeichnet, daß ein Hilfs-Operand für die Traversierung eines aus ei
ner variablen Anzahl gleichartiger Operanden zusammengesetzten Operanden durch ein
Baumelement visualisiert wird, welches die aktuelle Position der Traverse und den Algo
rithmus zur Veränderung der Position repräsentiert und welches mit einem Traversen-
und einem Objektnamen beschriftet ist.
7. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 6, dadurch gekennzeichnet, daß eine graphische Verbindung, die auf oder in dem
stellvertretenden Operanden eines aus einer variablen Anzahl gleichartiger Operanden zu
sammengesetzten Operanden endet, zuvor über Baumelemente geführt wird, welche
Hilfs-Operanden für die Traversierung repräsentieren.
8. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 7, dadurch
gekennzeichnet, daß die graphische Verbindung als Linienverbindung ausgestaltet ist.
9. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 8, dadurch gekennzeichnet, daß eine graphische Verbindung, die über einen Hilfs-
Operanden für die Traversierung geführt wird, der selbst wieder stellvertretender Ope
rand eines aus einer variablen Anzahl gleichartiger Operanden zusammengesetzten Operanden
ist oder darin enthalten ist, zuvor ebenfalls über Baumelemente geführt wird, wel
che Hilfs-Operanden für die Traversierung repräsentieren.
10. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 9, dadurch
gekennzeichnet, daß die graphische Verbindung als Linienverbindung ausgestaltet ist.
11. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 10, dadurch gekennzeichnet, daß ein Operand mit dynamischer Spei
cherplatzzuteilung durch ein Baumelement visualisiert wird, das den stellvertretenden
Operanden eines aus einer variablen Anzahl gleichartiger Operanden zusammengesetzten,
besonders gekennzeichneten Operanden repräsentiert, wobei die Speicherposition des dy
namisch zugeteilten Operanden durch ein weiteres Baumelement visualisiert wird, das ei
nen Hilfs-Operanden für die Traversierung repräsentiert.
12. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 10, dadurch gekennzeichnet, daß ein Operand mit statischer Speicherplatzzuteilung
durch ein Baumelement visualisiert wird, das den Operanden eines aus einer festen An
zahl unterschiedlicher Operanden zusammengesetzten, besonders gekennzeichneten Ope
randen repräsentiert.
13. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 10, dadurch gekennzeichnet, daß ein verteiltes Objekt durch ein Baumelement visuali
siert wird, das den Operanden eines aus einer festen Anzahl unterschiedlicher Operanden
zusammengesetzten, besonders gekennzeichneten Operanden repräsentiert.
14. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 13, dadurch gekennzeichnet, daß ein Baumelement, welches einen Operanden visuali
siert, durch eine graphische Hilfs-Verbindung verlängert wird, so daß graphische Verbin
dungen, die Beziehungen zu dem Baumelement visualisieren, auf dieser graphischen Hilfs-
Verbindung enden können, und daß graphische Verbindungen, die über das Baumelement
zu führen sind, diese graphische Hilfs-Verbindung, schneiden können, wobei der Schnitt
punkt markiert wird.
15. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 14, dadurch
gekennzeichnet, daß mindestens eine graphische Hilfs-Verbindung als Hilfs-Linie ausge
staltet ist.
16. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 14 oder 15,
dadurch gekennzeichnet, daß die graphische Verbindung als Linienverbindung ausgestal
tet ist.
17. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 16, dadurch gekennzeichnet, daß eine graphische Verbindung, die über ein Baum
element geführt wird, das einen Hilfs-Operanden für die Traversierung repräsentiert, an
ihrem Schnittpunkt mit diesem Baumelement mit einer eindeutigen Kennzeichnung des
ihm zugeordneten zusammengesetzten Operanden beschriftet ist.
18. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 17, dadurch
gekennzeichnet, daß die graphische Verbindung als Linienverbindung ausgestaltet ist.
19. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 18, dadurch gekennzeichnet, daß bei einer graphischen Verbindung, die auf einem
Operanden endet, durch weitere Kennzeichnung unterschieden wird, ob dieser Operand
verändert wird oder nicht.
20. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 19, dadurch
gekennzeichnet, daß die graphische Verbindung als Linienverbindung ausgestaltet ist.
21. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 20, dadurch gekennzeichnet, daß bei einer graphischen Verbindung, die auf einem
Operanden endet, durch weitere Kennzeichnung unterschieden wird, ob sie eine Argu
ment-, Zuweisungs-, Element- oder andere Beziehung repräsentiert.
22. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 21, dadurch
gekennzeichnet, daß die graphische Verbindung als Linienverbindung ausgestaltet ist.
23. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 22, dadurch gekennzeichnet, daß eine Operation durch ein Baumelement visualisiert
wird, welches gleichzeitig den Aufruf und den Ergebniswert der Operation repräsentiert
und das mit dem Operationsnamen oder -symbol beschriftet ist.
24. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 23, dadurch gekennzeichnet, daß ein Argument einer Operation durch ein Baumele
ment visualisiert wird, welches dem Baumelement folgt, das die Operation repräsentiert.
25. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 24, dadurch gekennzeichnet, daß ein Baumelement, welches ein Argument einer Ope
ration repräsentiert, mit dem Wert oder dem Namen einer Konstanten beschriftet ist und
damit diese Konstante repräsentiert.
26. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 24, dadurch gekennzeichnet, daß ein Baumelement, welches ein Argument einer Ope
ration repräsentiert, mit dem Baumelement eines Operanden über eine graphische Ver
bindung, verbunden ist und damit diesen Operanden repräsentiert.
27. Verfahren zur visuellen Programmierung eines Computers nach Anspruch 26, dadurch
gekennzeichnet, daß die graphische Verbindung als Linienverbindung ausgestaltet ist.
28. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 24, dadurch gekennzeichnet, daß ein Baumelement, welches ein Argument einer Ope
ration repräsentiert, selbst wieder eine Operation repräsentiert.
29. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 28, dadurch gekennzeichnet, daß die unbedingte und sequentielle Ausführung einer
Folge von Operationen durch ein Baumelement visualisiert wird, dem in derselben Rei
henfolge die Baumelemente folgen, welche die Operationen repräsentieren.
30. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 29, dadurch gekennzeichnet, daß die selektive und sequentielle Ausführung einer Folge
von Operationen durch ein Baumelement visualisiert wird, dem in derselben Reihen
folge die Baumelemente der Operationen folgen und das mit dem Symbol eines Ver
gleichsoperators, gefolgt von einer Konstanten, beschriftet ist.
31. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 30, dadurch gekennzeichnet, daß die iterative und sequentielle Ausführung einer Folge
von Operationen durch ein Baumelement visualisiert wird, dem in derselben Reihenfolge
die Baumelemente der Operationen folgen und das mit dem Symbol eines Ver
gleichsoperators, gefolgt von einer Konstanten, beschriftet ist.
32. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 31, dadurch gekennzeichnet, daß die kontrollierte Ausführung von Folgen von Opera
tionen durch ein Baumelement visualisiert wird, welchem zunächst ein Baumelement
folgt, das eine sequentiell ausgeführte Folge Operationen repräsentiert und welchem so
dann ein oder mehrere Baumelemente folgen, die jeweils eine selektiv oder iterativ auszu
führende Folge von Operationen repräsentieren und das letzte Element der sequentiell
ausgeführten Folge von Operationen in Verbindung mit den Beschriftungen der selektiv
oder iterativ ausgeführten Folgen von Operationen die Selektions- oder Iterationsbedin
gungen repräsentiert.
33. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 32, dadurch gekennzeichnet, daß die parallele Ausführung von Folgen von Operatio
nen durch ein Baumelement visualisiert wird, dem mehrere Baumelemente folgen, welche
die parallel auszuführenden Folgen von Operationen repräsentieren.
34. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 33, dadurch gekennzeichnet, daß daß die Ausnahmebehandlung für eine sequentiell
ausgeführte Folge von Operationen durch ein Baumelement visualisiert wird, dem zu
nächst das Baumelement folgt, welches die sequentiell ausgeführte Folge von Operationen
repräsentiert und dem sodann weitere Baumelemente folgen, welche die Operationenfol
gen der Ausnahmebehandlung repräsentieren.
35. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 34, dadurch gekennzeichnet, daß eine aus Operationen und Operanden zusammenge
setzte Funktionale Einheit durch ein Baumelement visualisiert wird, dem zunächst ein
Baumelement folgt, welches eine Folge von Operationen repräsentiert und dem sodann
ein Baumelement folgt, welches die Menge der Operanden repräsentiert.
36. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 35, dadurch gekennzeichnet, daß in der Folge von Operationen einer Funktionalen
Einheit auch selbst wieder Funktionale Einheiten vorkommen.
37. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 36, dadurch gekennzeichnet, daß Blöcke unterschiedlicher Hierarchiestufe, Kontroll
strukturen, Funktions- und Operationsdefinitionen, Definitionen von Klassen und Un
terklassen, Module unterschiedlicher Hierarchiestufe Komponenten, Systemebenen und
Systeme jeweils durch ein Baumelement visualisiert werden, das eine Funktionale Einheit
repräsentiert.
38. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 37, dadurch gekennzeichnet, daß die Operanden einer Funktionalen Einheit, welche
eine Funktions- oder Operationsdefinition repräsentiert, durch eine Kennzeichnung ihres
Baumelementes als Eingabe-, Ausgabe- oder Ein-Ausgabe-Parameter kenntlich gemacht
werden und die Beendigung der Funktion oder Operation mit Rückgabe eines Ergebnis
wertes durch besondere Kennzeichnung eines Ausdrucks kenntlich gemacht wird.
39. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 38, dadurch gekennzeichnet, daß eine Klassendefinition durch ein Baumelement als
eine Funktionale Einheit aus Operationen und Operanden visualisiert wird, deren Opera
tionenfolge selbst wieder aus funktionalen Einheiten, nämlich denen der Elementfunk
tionen besteht und deren Operandenfolge die Datenelemente repräsentiert und deren
oberstes Baumelement mit dem Klassennamen, sowie mit den Namen von Konfigura
tionsparametern beschriftet ist.
40. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 39, dadurch gekennzeichnet, daß eine abgeleitete Klassendefinition (Unterklasse)
durch ein Baumelement visualisiert wird, das selbst wieder enthalten ist in der Folge der
Elementfunktionen einer Klassendefinition einer Oberklasse und damit alle Elementfunk
tionen dieser Oberklasse erbt oder überlädt, sowie alle Datenelemente dieser Oberklasse
erbt.
41. Verfahren zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 40, dadurch gekennzeichnet, daß eine Abstraktion einer funktionalen Einheit durch
Weglassen von Details visualisiert wird, wobei globale Zugriffspfeile an der Unterkante
der funktionalen Einheit enden, und daß eine Vergröberung durch Weglassen von zuvor
willkürlich als unwichtig gekennzeichneten Details visualisiert wird.
42. Verfahren zur visuellen Erstellung und Veränderung eines Speicherabbildes eines Pro
gramms, das mittels eines Verfahrens zur visuellen Programmierung eines Computers
nach einem der Ansprüche 1 bis 41 erzeugt wurde, dadurch gekennzeichnet, daß
unmittelbar in dem auf einem Ausgabemedium angezeigten visuellen Programm mit hilfe eines Editor-Mittels Einfüge-, Änderungs- und Löschoperationen ausgelöst wer den können,
in Abhängigkeit von der Einfüge-, Änderungs- und Löschposition innerhalb des visu ellen Programms die Menge der möglichen Aktionen und Eingaben sinnvoll einge schränkt und dies dem Programmierer angezeigt wird, und
in Abhängigkeit von der Einfüge-, Änderungs- und Löschposition innerhalb des visu ellen Programms dem Programmierer zusätzliche Hilfsinformationen angezeigt wer den.
unmittelbar in dem auf einem Ausgabemedium angezeigten visuellen Programm mit hilfe eines Editor-Mittels Einfüge-, Änderungs- und Löschoperationen ausgelöst wer den können,
in Abhängigkeit von der Einfüge-, Änderungs- und Löschposition innerhalb des visu ellen Programms die Menge der möglichen Aktionen und Eingaben sinnvoll einge schränkt und dies dem Programmierer angezeigt wird, und
in Abhängigkeit von der Einfüge-, Änderungs- und Löschposition innerhalb des visu ellen Programms dem Programmierer zusätzliche Hilfsinformationen angezeigt wer den.
43. Verfahren nach Anspruch 42, dadurch gekennzeichnet, daß die Objekte des Speicher
abbildes des visuellen Programms mit Informationen zur Unterstützung ihrer Edition
versehen werden.
44. Verfahren nach Anspruch 42 oder 43, dadurch gekennzeichnet, daß als Editor-Mittel ein
Editor-Software-Modul dient.
45. Verfahren nach Anspruch 42, 43 oder 44, dadurch gekennzeichnet, daß als Editor-Mittel
ein graphisches Eingabewerkzeug dient.
46. Verfahren nach einem der Ansprüche 42-45, dadurch gekennzeichnet, daß Namens- und
Typinformation für die Anzeige in Auswahllisten des Editor-Mittels aus existierenden
textuellen Klassenbibliotheken durch Standardverfahren der Syntaxanalyse automatisch
gewonnen und klassifiziert wird.
47. Verfahren nach einem der Ansprüche 42-46, dadurch gekennzeichnet, daß
das Speicherabbild des visuellen Programms vom Editor-Mittel ganz oder teilweise, in unterschiedlichen Hierarchiestufen, Abstraktionsebenen, Detaillierungsgraden und Maßstäben wiedergegeben wird,
Beziehungen und Abhängigkeiten zwischen Teilen des Speicherabbildes graphisch her vorgehoben werden können,
daß Verzweigungsebenen des Speicherabbildes drei-dimensional geschichtet und in perspektivischer Ansicht dargestellt werden können,
daß Teile der graphischen Wiedergabe des Speicherabbildes vorübergehend mit Teilen eines fremden Speicherabbildes graphisch überlagert werden können.
das Speicherabbild des visuellen Programms vom Editor-Mittel ganz oder teilweise, in unterschiedlichen Hierarchiestufen, Abstraktionsebenen, Detaillierungsgraden und Maßstäben wiedergegeben wird,
Beziehungen und Abhängigkeiten zwischen Teilen des Speicherabbildes graphisch her vorgehoben werden können,
daß Verzweigungsebenen des Speicherabbildes drei-dimensional geschichtet und in perspektivischer Ansicht dargestellt werden können,
daß Teile der graphischen Wiedergabe des Speicherabbildes vorübergehend mit Teilen eines fremden Speicherabbildes graphisch überlagert werden können.
48. Verfahren nach Anspruch nach Anspruch 47, dadurch gekennzeichnet, daß die Objekte
des Speicherabbilds während des Editierens automatisch mit einer Kennzeichnung des
Leistungsmerkmals versehen werden, dem sie zugehören und daß Objekte, die demselben
Leistungsmerkmal zugehören, jederzeit graphisch hervorgehoben werden können.
49. Verfahren nach Anspruch 47 oder 48, dadurch gekennzeichnet, daß die Objekte des Spei
cherabbilds während des Editierens automatisch mit einer Zeitmarke versehen werden
und daß Objektmengen, die verschiedenen Leistungsmerkmalen zugehören, jederzeit ge
mäß der graphischen Abfolge des Entwurfsprozesses angezeigt werden können.
50. Verfahren zur Übersetzung eines Speicherabbildes eines Programms, das mittels eines
Verfahrens zur visuellen Programmierung eines Computers nach einem der Ansprüche 1
bis 41 erzeugt wurde, dadurch gekennzeichnet, daß
das Speicherabbild des visuellen Programms in einer Traverse durchlaufen wird, die der sequentiellen Klammerdarstellung des Objektbaumes entspricht,
für jedes traversierte Objekt des Speicherabbildes gemäß seiner Klasse eine Methode aufgerufen wird, die seine Attribute auf syntaktische Elemente einer Zielsprache oder auf administrative Einheiten eines Betriebssystems abbildet,
Klassen und ihnen untergeordnete funktionale Einheiten in den Quellcode einer Ziel sprache übersetzt werden, und
Module und ihnen übergeordnete funktionale Einheiten in administrative Einheiten eines Betriebssystems übersetzt werden.
das Speicherabbild des visuellen Programms in einer Traverse durchlaufen wird, die der sequentiellen Klammerdarstellung des Objektbaumes entspricht,
für jedes traversierte Objekt des Speicherabbildes gemäß seiner Klasse eine Methode aufgerufen wird, die seine Attribute auf syntaktische Elemente einer Zielsprache oder auf administrative Einheiten eines Betriebssystems abbildet,
Klassen und ihnen untergeordnete funktionale Einheiten in den Quellcode einer Ziel sprache übersetzt werden, und
Module und ihnen übergeordnete funktionale Einheiten in administrative Einheiten eines Betriebssystems übersetzt werden.
51. Verfahren nach Anspruch 50, dadurch gekennzeichnet, daß die Objekte des Speicherab
bildes mit Informationen zur Unterstützung ihrer Compilation versehen werden.
52. Verfahren nach Anspruch 50 oder 51, dadurch gekennzeichnet, daß die Definition eines
Containers auf die Definition eines Templates (Klassenschablone mit Typparameter) ab
gebildet wird, wobei der Typ der Containerelemente auf den Typparameter des Temp
lates abgebildet wird.
53. Verfahren nach Anspruch 50, 51 oder 52, dadurch gekennzeichnet, daß die Verschachte
lung von Containern auf die verschachtelte Deklaration von Templates abgebildet wer
den.
54. Verfahren nach einem der Ansprüche 50 bis 53, dadurch gekennzeichnet, daß der Zugriff
auf Containerelemente auf einen Klammeroperator abgebildet wird, dem ein Iterator als
Parameter übergeben wird und der als Ergebnis eine Referenz auf das adressierte Contai
nerelement zurückgibt.
55. Verfahren nach einem der Ansprüche 50 bis 54, dadurch gekennzeichnet, daß eine Kon
trollstruktur abhängig vom Typ ihrer Case-Blöcke und abhängig vom Vergleichsoperator
der Postconditions auf unterschiedliche Kontrollstrukturen der Zielsprache abgebildet
wird.
56. Verfahren zum Abspeichern und Wiederherstellen des Speicherabbildes eines visuellen
Programms, das mittels eines Verfahrens zur visuellen Programmierung eines Computers
nach einem der Ansprüche 1 bis 41 erzeugt wurde, dadurch gekennzeichnet, daß
das Speicherabbild des visuellen Programms als zusammenhängendes Objekt mit allen seinen internen Beziehungen vom Arbeitsspeicher in eine objektorientierte oder ob jektrelationale Datenbank verlagert oder kopiert wird, und
das Speicherabbild als zusammenhängendes Objekt mit allen seinen internen Bezieh ungen aus der objektorientierten oder objektrelationalen Datenbank in den Arbeits speicher verlagert oder kopiert wird.
das Speicherabbild des visuellen Programms als zusammenhängendes Objekt mit allen seinen internen Beziehungen vom Arbeitsspeicher in eine objektorientierte oder ob jektrelationale Datenbank verlagert oder kopiert wird, und
das Speicherabbild als zusammenhängendes Objekt mit allen seinen internen Bezieh ungen aus der objektorientierten oder objektrelationalen Datenbank in den Arbeits speicher verlagert oder kopiert wird.
57. Verfahren nach Anspruch 56, dadurch gekennzeichnet, die Objekte des Speicherabbildes
mit Informationen zur Unterstützung ihrer Datenbankhinterlegung oder ihres Daten
bankzugriffes versehen werden.
58. Verfahren nach Anspruch 56 oder 57, dadurch gekennzeichnet, daß der selektive Zugriff
auf Teile des in der objektorientierten oder objektrelationalen Datenbank liegenden Spei
cherabbilds durch Standard-Suchfunktionen der objektorientierten oder objektrelationa
len Datenbank unterstützt wird.
59. Verfahren nach Anspruch 56, 57 oder 58, dadurch gekennzeichnet, daß die Zugriffskon
trolle für das in der objektorientierten oder objektrelationalen Datenbank liegende Spei
cherabbild durch Standardfunktionen der objektorientierten oder objektrelationalen Da
tenbank unterstützt wird.
60. Verfahren zur Dokumentation des Speicherabbildes eines visuellen Programmes, das mit
tels eines Verfahrens zur visuellen Programmierung eines Computers nach einem der An
sprüche 1 bis 41 erzeugt wurde, dadurch gekennzeichnet, daß
unmittelbar in dem auf einem Bildschirm angezeigten visuellen Programm mithilfe eines Dokumentations-Editor-MittelsOperationen zur Eingabe von Dokumentations texten, Kommentaren und weiterer Informationen ausgelöst werden können,
in Abhängigkeit von der Eingabeposition innerhalb des visuellen Programms die ein gegebene Dokumentation einzelnen Programmelementen zugeordnet wird,
die einem Programmelement zugeordnete Dokumentation während der Bearbeitung des Programms jederzeit angezeigt werden kann, und
für jede funktionale Einheit die Dokumentation ihrer Programmelemente in geschlos sener Form ausgeben kann.
unmittelbar in dem auf einem Bildschirm angezeigten visuellen Programm mithilfe eines Dokumentations-Editor-MittelsOperationen zur Eingabe von Dokumentations texten, Kommentaren und weiterer Informationen ausgelöst werden können,
in Abhängigkeit von der Eingabeposition innerhalb des visuellen Programms die ein gegebene Dokumentation einzelnen Programmelementen zugeordnet wird,
die einem Programmelement zugeordnete Dokumentation während der Bearbeitung des Programms jederzeit angezeigt werden kann, und
für jede funktionale Einheit die Dokumentation ihrer Programmelemente in geschlos sener Form ausgeben kann.
61. Verfahren nach Anspruch 60, dadurch gekennzeichnet, daß die Objekte des Speicherab
bildes mit Attributen zur Unterstützung ihrer Dokumentation versehen werden.
62. Verfahren nach Anspruch 60 oder 61, dadurch gekennzeichnet, daß als Dokumentations-
Editor-Mittel ein Dokumentations-Editor-Software-Modul dient.
63. Verfahren nach Anspruch 60, 61 oder 62, dadurch gekennzeichnet, daß als Dokumenta
tions-Editor-Mittel ein graphisches Eingabewerkzeug dient.
64. Verfahren zur Verwaltung des Speicherabbildes eines visuellen Programms, das mittels
eines Verfahrens zur visuellen Programmierung eines Computers nach einem der An
sprüche 1 bis 41 erzeugt wurde, dadurch gekennzeichnet, daß
der Projektstatus aus der attributiven und topologischen Vollständigkeit seines Spei cherabbildes automatisch ermittelt wird,
der Entstehungsgang des Speicherabbilds protokolliert wird und der zukünftige Pro jektverlauf aus dem bisherigen Entstehungsgang des Speicherabbilds automatisch er mittelt wird,
die Verwaltung von Namens- und Typ-Information von Operanden und Operationen durch Standardfunktionen einer objekt-relationalen Datenbank unterstützt wird, und
die Verwaltung von Versionen, Entwurfsalternativen und Entwurfsmustern durch Standardfunktionen einer objekt-relationalen Datenbank unterstützt wird.
der Projektstatus aus der attributiven und topologischen Vollständigkeit seines Spei cherabbildes automatisch ermittelt wird,
der Entstehungsgang des Speicherabbilds protokolliert wird und der zukünftige Pro jektverlauf aus dem bisherigen Entstehungsgang des Speicherabbilds automatisch er mittelt wird,
die Verwaltung von Namens- und Typ-Information von Operanden und Operationen durch Standardfunktionen einer objekt-relationalen Datenbank unterstützt wird, und
die Verwaltung von Versionen, Entwurfsalternativen und Entwurfsmustern durch Standardfunktionen einer objekt-relationalen Datenbank unterstützt wird.
65. Verfahren nach Anspruch 60, dadurch gekennzeichnet, daß die Objekte des Speicherab
bildes mit Informationen zur Unterstützung ihrer Verwaltung versehen werden.
66. Verfahren nach Anspruch 64 oder 65, dadurch gekennzeichnet, daß die Vollständigkeit
des Speicherabbildes aus der Zusammengehörigkeit von Spezifikationsmerkmalen und
durch Abgleich mit der Topologie und den Attributen des Speicherabbilds ermittelt wird.
67. Verfahren zum Navigieren in der graphischen Wiedergabe eines Speicherabbildes eines
visuellen Programmes, das mittels eines Verfahrens zur visuellen Programmierung eines
Computers nach einem der Ansprüche 1 bis 41 erzeugt wurde, dadurch gekennzeichnet,
daß
die Anzeige der Objekte des Speicherabbilds des visuellen Programms in topologi schen und assoziativen Traversen verläuft,
die Anzeige der Objekte des Speicherabbilds zwischen verschiedenen Abstraktions ebenen, Detaillierungsgraden und Maßstäben gewechselt werden kann,
eine perspektivische Anzeige drei-dimensional angeordneter Objekte des Speicherab bilds durch allmähliche Richtungsänderung, Annäherung und Entfernung erfolgen kann, und
Hilfsinformation zur Orientierung, Dokumentation und Verwaltung angezeigt wer den.
die Anzeige der Objekte des Speicherabbilds des visuellen Programms in topologi schen und assoziativen Traversen verläuft,
die Anzeige der Objekte des Speicherabbilds zwischen verschiedenen Abstraktions ebenen, Detaillierungsgraden und Maßstäben gewechselt werden kann,
eine perspektivische Anzeige drei-dimensional angeordneter Objekte des Speicherab bilds durch allmähliche Richtungsänderung, Annäherung und Entfernung erfolgen kann, und
Hilfsinformation zur Orientierung, Dokumentation und Verwaltung angezeigt wer den.
68. Verfahren nach Anspruch 67, dadurch gekennzeichnet, daß die Objekte des Speicherab
bildes mit Informationen zur Unterstützung der Navigation versehen werden.
69. Verfahren nach Anspruch 67 oder 68, dadurch gekennzeichnet, daß Funktionsabläufe,
Zusammenhänge und Abhängigkeiten innerhalb des visuellen Programms durch aufeinan
derfolgende farbliche oder akustische Kennzeichnung hervorgehoben werden.
70. System zur visuellen Programmierung eines Computers, dadurch gekennzeichnet, daß es
ein Datenverarbeitungssystem mit zumindest einer graphischen Anzeige aufweist, das
programmtechnisch so eingerichtet ist, daß es nach dem Verfahren nach einem der An
sprüche 1 bis 69 arbeitet.
71. System zur visuellen Programmierung eines Computers nach Anspruch 70, dadurch ge
kennzeichnet, daß das Datrenverarbeitungssystem auch eine Datenbankspeichereinheit
aufweist.
72. Computer-Programm mit Programmcode zur Durchführung des Verfahrens nach einem
der Ansprüche 1 bis 69, wenn das Programm auf einem Computer abläuft.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19907328A DE19907328C2 (de) | 1999-02-20 | 1999-02-20 | Verfahren und System zur visuellen Programmierung |
EP00909044A EP1161724A1 (de) | 1999-02-20 | 2000-02-16 | Verfahren und system zur visuellen programmierung |
PCT/DE2000/000477 WO2000049498A1 (de) | 1999-02-20 | 2000-02-16 | Verfahren und system zur visuellen programmierung |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19907328A DE19907328C2 (de) | 1999-02-20 | 1999-02-20 | Verfahren und System zur visuellen Programmierung |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19907328A1 DE19907328A1 (de) | 2000-08-31 |
DE19907328C2 true DE19907328C2 (de) | 2002-10-24 |
Family
ID=7898277
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19907328A Expired - Fee Related DE19907328C2 (de) | 1999-02-20 | 1999-02-20 | Verfahren und System zur visuellen Programmierung |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1161724A1 (de) |
DE (1) | DE19907328C2 (de) |
WO (1) | WO2000049498A1 (de) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8589874B2 (en) | 2007-06-11 | 2013-11-19 | Microsoft Corporation | Visual interface to represent scripted behaviors |
US11003422B2 (en) | 2019-05-10 | 2021-05-11 | Fasility Llc | Methods and systems for visual programming using polymorphic, dynamic multi-dimensional structures |
CN111090419B (zh) * | 2019-11-26 | 2023-04-07 | 广东工业大学 | 一种基于结点入度变化的树结构可视化方法 |
CN113590086B (zh) * | 2020-04-30 | 2023-09-12 | 广东中砼物联网科技有限公司 | 快速开发软件的方法、计算机设备、及存储介质 |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0069600A2 (de) * | 1981-07-10 | 1983-01-12 | Reckitt And Colman Products Limited | Pharmazeutische Präparate |
DE3503119A1 (de) * | 1984-01-30 | 1985-08-01 | Hitachi, Ltd., Tokio/Tokyo | Verfahren zum automatischen erzeugen eines quellenprogramms |
EP0219993A2 (de) * | 1985-10-08 | 1987-04-29 | AT&T Corp. | System zur Erzeugung der Komponenten eines Ursprungscodes |
WO1992011724A1 (en) * | 1990-12-18 | 1992-07-09 | Bell Communications Research, Inc. | Visual programming of telephone network call processing logic |
DE4332193A1 (de) * | 1992-09-28 | 1994-03-31 | Ford Werke Ag | Verfahren und System zur Verarbeitung und On-Line-Darstellung von Multimedia-Information in einer Baumstruktur |
EP0650118A2 (de) * | 1993-10-22 | 1995-04-26 | AT&T Corp. | Verfahren und Gerät zur Anzeige hierarchischer Information eines grossen Softwaresystems |
EP0651325A2 (de) * | 1993-10-29 | 1995-05-03 | Microsoft Corporation | Verfahren und Vorrichtung zur Erzeugung eines Rechnerprogramms |
EP0689132A2 (de) * | 1994-06-23 | 1995-12-27 | International Business Machines Corporation | Visualisierung von objektorientierter Software |
EP0706125A1 (de) * | 1994-09-30 | 1996-04-10 | International Business Machines Corporation | Objektorientierte Vorrichtung und Verfahren zum Generieren des Zielsprachencodes |
EP0714064A1 (de) * | 1994-10-03 | 1996-05-29 | AT&T Corp. | Vorrichtung zur Darstellung von Programmscheiben |
US5664129A (en) * | 1994-08-10 | 1997-09-02 | Hitachi, Ltd. | Visual programming method |
-
1999
- 1999-02-20 DE DE19907328A patent/DE19907328C2/de not_active Expired - Fee Related
-
2000
- 2000-02-16 EP EP00909044A patent/EP1161724A1/de not_active Withdrawn
- 2000-02-16 WO PCT/DE2000/000477 patent/WO2000049498A1/de not_active Application Discontinuation
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0069600A2 (de) * | 1981-07-10 | 1983-01-12 | Reckitt And Colman Products Limited | Pharmazeutische Präparate |
DE3503119A1 (de) * | 1984-01-30 | 1985-08-01 | Hitachi, Ltd., Tokio/Tokyo | Verfahren zum automatischen erzeugen eines quellenprogramms |
EP0219993A2 (de) * | 1985-10-08 | 1987-04-29 | AT&T Corp. | System zur Erzeugung der Komponenten eines Ursprungscodes |
WO1992011724A1 (en) * | 1990-12-18 | 1992-07-09 | Bell Communications Research, Inc. | Visual programming of telephone network call processing logic |
DE4332193A1 (de) * | 1992-09-28 | 1994-03-31 | Ford Werke Ag | Verfahren und System zur Verarbeitung und On-Line-Darstellung von Multimedia-Information in einer Baumstruktur |
EP0650118A2 (de) * | 1993-10-22 | 1995-04-26 | AT&T Corp. | Verfahren und Gerät zur Anzeige hierarchischer Information eines grossen Softwaresystems |
EP0651325A2 (de) * | 1993-10-29 | 1995-05-03 | Microsoft Corporation | Verfahren und Vorrichtung zur Erzeugung eines Rechnerprogramms |
EP0689132A2 (de) * | 1994-06-23 | 1995-12-27 | International Business Machines Corporation | Visualisierung von objektorientierter Software |
US5664129A (en) * | 1994-08-10 | 1997-09-02 | Hitachi, Ltd. | Visual programming method |
EP0706125A1 (de) * | 1994-09-30 | 1996-04-10 | International Business Machines Corporation | Objektorientierte Vorrichtung und Verfahren zum Generieren des Zielsprachencodes |
EP0714064A1 (de) * | 1994-10-03 | 1996-05-29 | AT&T Corp. | Vorrichtung zur Darstellung von Programmscheiben |
Non-Patent Citations (6)
Title |
---|
Agusti, J. et al.: "Towards Specifiying with Inclusions", In: Mathware and Soft Computing, 1997 * |
CLACK, C.: "Object-Flow", In: 1997, IEEE Symposium on Visual Languages, Capri Italy, Sept. 1997 * |
DuPuis, C., Burnett, M.: "An Animated Turing Machine Simulator in Forms/3", Oregon University, Dept. of Computer Science, TR 97-60-08. July 1997 * |
ERWIG, M.: "DEAL - A Language for Depicting Algorithms", In: IEEE Symposium on Visual Languages, St. Louis, USA, Oct. 1994 * |
POSWIG, Jörg: "Visuelle Programmierung - Computerprogramme auf graphischem Weg erstellen", Hanser-Verlag, 1996 * |
PROGRES, A.:VHL-Language Based on Graph Grammars", Lecture Notes in Computer Science 532, Springer-Verlag (1991), S. 641-659 * |
Also Published As
Publication number | Publication date |
---|---|
EP1161724A1 (de) | 2001-12-12 |
WO2000049498A1 (de) | 2000-08-24 |
DE19907328A1 (de) | 2000-08-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69518123T2 (de) | Visualisierung von objektorientierter Software | |
DE69303289T2 (de) | Steuersystem für anzeigemenüzustand | |
DE69310187T2 (de) | Objektorientiertes fachwerksystem | |
DE69310202T2 (de) | Internationales datenverarbeitungssystem | |
DE69310188T2 (de) | Objektorientiertes bestaetigungssystem | |
Trigg et al. | Adaptability and tailorability in NoteCards | |
DE69310201T2 (de) | Objektorientierte applikationsschnittstelle. | |
DE69310934T2 (de) | Ballonhilfssystem. | |
DE69311359T2 (de) | Befehlssystem | |
DE69429247T2 (de) | Verfahren zur wissendarstellung in einem rechner | |
DE60011479T2 (de) | Xml-roboter | |
DE69310214T2 (de) | Dialogsystem | |
DE69304928T2 (de) | Atomares befehlsystem | |
DE69503052T2 (de) | Verbessertes objektorientiertes betriebssystem zum filtrieren von datenobjekten in einem fenster | |
North et al. | Applications of graph visualization | |
DE69516891T2 (de) | Verfahren zum übersetzen von quellkode aus einer computer-hochsprache in eine andere | |
US20080104570A1 (en) | System and method for computer-aided graph-based dependency analysis | |
Mei et al. | Viscomposer: A visual programmable composition environment for information visualization | |
Jensen et al. | Computer tools for coloured Petri nets | |
DE69404438T2 (de) | Objektorientiertes graphisches auswahlsystem | |
DE69624693T2 (de) | Verfahren und vorrichtung zur ausführung eines anwendungsprogramms | |
Pareja-Flores et al. | WinHIPE: An IDE for functional programming based on rewriting and visualization | |
Zadahmad et al. | DSMCompare: domain-specific model differencing for graphical domain-specific languages | |
DE19907328C2 (de) | Verfahren und System zur visuellen Programmierung | |
Dunsmore | Comprehension and visualisation of object-oriented code for inspections |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
D2 | Grant after examination | ||
8380 | Miscellaneous part iii |
Free format text: ALS FIGUR FUER DIE ZUSAMMENFASSUNG DIENT FIGUR 8A (ZEICHNUNGSSEITE 3) DIE FIGUR 8B AUF DER ZEICHNUNGSSEITE 3 ENTFAELLT |
|
8364 | No opposition during term of opposition | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |