DE102004043788A1

DE102004043788A1 - Programm Generator

Info

Publication number: DE102004043788A1
Application number: DE102004043788A
Authority: DE
Inventors: Ingo Franz; Steffen Linke
Original assignee: Individual
Current assignee: Individual
Priority date: 2003-09-11
Filing date: 2004-09-08
Publication date: 2005-04-14
Also published as: US20050060685A1

Abstract

Eine Vorrichtung zum Erstellen ausführbarer Programme, enthaltend eine Benutzeroberfläche zur Eingabe eines einem Programm zugrunde liegenden Models, einen Generator zur Erzeugung von individuellem Programmcode aus dem Modell, eine Zustandsmaschine zur Ausführung des auf dem Programmcode basierenden Programms, und vordefiniertem Programmcode in Form von wenigstens einer Basisklasse oder sonstigem vordefinierten Code zur Bereitstellung von wiederkehrenden Algorithmen, ist dadurch gekennzeichnet, dass die Benutzungsoberfläche derart ausgebildet ist, dass die Eingabe ausführbarer Befehle zumindest teilweise in graphischer Form erfolgt, Teile des vordefinierten Programmcodes für die Zustandsmaschine als Einsprung in den Programmcode dienen, das dem Programm zugrunde liegende Modell graphische Symbole enthält, die instanziierte Klasse repräsentieren, und das dem Programm zugrunde liegende Modell graphische Symbole enthält, durch welche die Zustandsmaschine unmittelbare Schnittstellen zwischen Instanzen und Programmnutzern realisiert.

Description

Die Erfindung betrifft eine Vorrichtung zum Erstellen ausführbarer Programme enthaltend: Vorrichtung zum Erstellen ausführbarer Programme enthaltend

(a) eine Benutzeroberfläche zur Eingabe eines einem Programm zugrunde liegenden Models,
(b) einen Generator zur Erzeugung von individuellem Programmcode aus dem Modell,
(c) eine Zustandsmaschine zur Ausführung des auf dem Programmcode basierenden Programms, und
(d) vordefinierten Programmcode in Form von wenigstens einer Basisklasse oder sonstigen vordefinierten Code zur Bereitstellung von wiederkehrenden Algorithmen.

Unter einem Modell wird allgemein ein Abbild der zu verwaltenden, simulierten Realität verstanden. Das kann die graphische Darstellung von Verwaltungsabläufen, Grundlagen für die Rechnungserstellung oder dergleichen sein. Diese Darstellung bedient sich graphischer Elemente, wie zum Beispiel Pfeile, Kästchen, Kreise etc. Ein Modell kann die Realität aber auch unmittelbar per Lochkarte, Binärcode oder Programmiersprachentext (Programmcode) darstellen. Diese Art der Darstellung in Form von Programmierung ist unübersichtlich. Im folgenden wird unter Modellierung ausschließlich die graphische Darstellung eines Modells in einem Koordinatensystem verstanden. Dabei können auch Textelemente verwendet werden.
Eine Benutzeroberfläche ist zum Beispiel ein Bildschirm, an welchem das Modell mit Tastatur und Maus erstellt, angezeigt und verändert wird. Programmcode ist ein Text in einer Programmiersprache, z.B. Pascal, C, Java oder dergleichen. Mit einem Generator kann Programmcode erstellt werden. Der Generator kann im Gegensatz zu einem einfachen Editor einen Textteil „automatisch" erzeugen. Bei einem Editor wird der Textteil manuell per Tastatur oder dergleichen als solcher eingegeben.
Eine Zustandsmaschine ist ein endlicher Zustandautomat (Finit State Machine). Dieser Algorithmus wird genutzt, um die Abfolge von Programmschritten (Aktionen) in einer Tabelle zu definieren, in der die möglichen Eingabedaten zu festgesetzten Programmzuständen zugeordnet werden und für jede Zuordnung die auszuführenden Aktionen und der sich daraus ergebene Folgezustand definiert werden können.
Zur Erstellung von Programmen für Datenverarbeitungsanlagen werden üblicherweise Programmiersprachen, z.B. C, Pascal oder Java verwendet. Der Programmierer muss die Befehle dieser Programmiersprachen kennen. Je nach Sprache muss er sich also umfangreiche Kenntnisse aneignen. Das Programm wird dabei in Form eines Textes erstellt, der als Listing und in Form von Tabellen ausgegeben werden kann. Eine besondere Herausforderung ist es dabei, die unterschiedlichen Schnittstellen zum Anwender und zu der Vielzahl an Peripheriegeräten zu programmieren. Komplexe Programme werden dabei sehr unübersichtlich. Auch ist der Programmierer auf die Eigenschaften der verwendeten Programmiersprache begrenzt. Vorteile einer anderen Programmiersprache können im allgemeinen nicht genutzt werden.
Der Programmierer veranschaulicht häufig zunächst die zu programmierenden Abläufe in Form einer Graphik. Diese Graphik kann per Handskizze erstellt werden oder aber auch Rechner-unterstützt. Außer der Darstellung der Programm-Abläufe am Bildschirm oder auf dem Papier leistet die Graphik jedoch keinen Beitrag zur Programmierung. Anhand des Modells wird dann der Programmcode erstellt. Zu diesem Zweck gibt der Programmierer den erforderlichen Text ein. Durch Debugging können ggf. Fehler erkannt werden. Dies ist aufwendig. Es ist weiterhin bekannt, Konfigurationsmöglichkeiten vorzusehen, mit denen das Programmverhalten auch nach der Programmierung beeinflusst werden kann.
Der Programmierungsprozess lässt sich allgemein in vier Ebenen unterteilen: Zunächst muss die Datenhaltung (Persistenz) organisiert werden. Hier werden die Datenformate für die benötigten Daten festgelegt. Weiterhin werden die Strukturen definiert, in denen die Daten z.B. in einem Festspeicher abgelegt werden. Ferner werden die Beziehungen der Daten untereinander definiert.
In einer weiteren Ebene wird die Fachlogik, einschließlich der Geschäftslogik und der fachlichen Realisierung programmiert. Dabei werden die erforderlichen Objekte, z.B. Adresskomponenten, Personen, Rechnungsempfänger oder dergleichen, definiert. Objekte umfassen allgemein einen Namen, entsprechend der Objektbezeichnung, Attribute, entsprechend den Objekteigenschaften und Methoden, entsprechend der möglichen, ausführbaren Handlungen.
In einer dritten Ebene wird die Ablaufsteuerung einschließlich der Dialogführung und der Prozesssteuerung programmiert. Die Ablaufsteuerung bestimmt, wann welche Vorgänge erfolgen. Es wird festgelegt, welches Fenster nach welchem Vorgang geöffnet wird, welche Rechenoperationen durch welchen Knopfdruck ausgelöst werden, etc. Solche Ablaufsteuerungen werden häufig in Flussdiagrammen dargestellt.
Auf der letzten Ebene wird die Präsentation einschließlich des Layouts und des Designs programmiert. Dabei werden die Farben und Größen von Fenstern, Schriftarten, Lage und Form von Buttons, Hintergründe, akustische Effekte etc. festgelegt.

Als CMS (Content Management System), z.B. ColdFusion, Designer Werkzeuge, z.B. Dreamweaver und HTML-Editoren sind Programme bekannt, welche die Möglichkeit bieten, die Programmierebene des Layouts visuell zu erstellen. Über die Visualisierung lassen sich auch Abläufe realisieren. Die Abläufe ergeben sich jedoch direkt aus den zur Verfügung gestellten Buttons und Links an der Oberfläche. Es erfolgt also eine Programmbeeinflussung durch Konfigurierung. Eine echte Modellierung von Abläufen erfolgt nicht. Datenbank-Zugriffe und fachliche Objekte müssen in der Programmiersprache ausprogrammiert werden. Hierzu ist die Erstellung von Programmcode erforderlich. Diese Programme sind nur für Anwendungen im Internet geeignet.

Es sind weiterhin integrierte Entwicklungsumgebungen (IDE) bekannt. Solche integrierten Entwicklungsumgebungen unterstützen den Programmierer ebenfalls bei der Programmierung des Layouts. Auch hier müssen Datenbank-Zugriffe und fachliche Objekte ausprogrammiert werden. Die Objekte, die genutzt werden sollen, lassen sich anzeigen. Für deren Nutzung ist aber auch die Erstellung von Programmcode erforderlich. Eine Unterstützung der Ablaufsteuerung erfolgt nicht.

Bei Prozessmodellierungs-Tools und Workflow-Tools werden Werkzeuge verwendet, mit welchen die Ablaufsteuerung modellierbar ist. Zu diesem Zweck werden eine Vielzahl graphischer Symbole bereitgestellt (Sequens, Loop, Compare, Paralleler Ablauf, Switch, Operation, Nachricht, Assign...). Es erfolgt die Modellierung von klassischen Ablaufdiagrammen. Die Modelle werden von einem Server interpretiert. Der Server kommuniziert über programmierbare Schnittstellen mit Datenbanken. Möglichkeiten zur Modellierung von Layout, Fachlogik oder Datenhaltung existieren nicht.

Unter dem Begriff „CaseTools" sind objektorientierte Modellierungswerkzeuge bekannt. Dabei wird Programmcode ausschließlich für die Fachlogik erzeugt. Case Tools unterstützen den Anwender bei der Erstellung von UML-Diagrammen (UML Unified Modelling Language). CaseTools unterstützen nicht alle UML-Diagramme, sondern lediglich Klassen- und Sequenz Diagramme. Sie sind daher für die Programmierung von Ablaufsteuerung, Datenhaltung und Layout nur bei großem Aufwand verwendbar.

Unter dem Begriff „MDA" (Model Driven Architecture) wurde von der sogenannten OMG (Objekt Management Group) ein Standard entwickelt. MDA beschreibt das Zusammenwirken der aus der UML-Sprache generierten Module und macht diese kompatibel. Weiterhin definiert der Standard ein fest konfigurierbares Framework zur Programmierung von Anwendungen. Eine Laufzeitumgebung besteht nicht. Zum Erstellen eines fertigen Programms muss nach der Modellierung eine Implementierung erfolgen. Erst nach der Implementierung des Programms nach diesem Standard endet der Entwicklungsprozess. Testmöglichkeiten während der Modellierung sind nicht vorgesehen. Der MDA-Standard sieht das Zusammenwirken des Programms mit weiteren Fremdkomponenten vor. Dabei müssen zum Beispiel Schnittstellen definiert werden und das Plattform-unabhängige Modell muss an die Konzepte der technischen Ablaufplattform angepasst werden. Zur Entwicklung von Programmen nach dem MDA-Standard werden die jeweiligen Klassen modelliert. Unter einer Klasse versteht man den Programmcode, der ein Objekt mit Name, Attributen und Methoden repräsentiert.

Bei der Modellierung nach dem MDA-Standard wird also generierter Code zur Verfügung gestellt. Zusätzlich müssen Schnittstellen definiert werden, über welche dieser Code angesprungen werden kann. Die anspringenden, zusätzlichen Programme sind zwar konfigurierbar, aber die Konfiguration greift nicht direkt auf die Modellierung der Fachlogik zu, sondern muss beim Ändern der Fachlogik angepasst werden. Jede Änderung des Modells muss von Hand im ausführenden Framework angepasst werden. Eine Modellierung des Layouts ist nicht vorgesehen. Eine Datenbankmodellierung im klassischen Sinne, z. B. Entität-Relationship-Modell, sowie ein explizite OR-mapping (Zuordnung von Objektorientierter Programmierung zu Relationalen Datenbanktabellen) ist nicht vorgesehen. MDA stellt also eine Mischung aus anhand eines Modells generiertem Code und durch Konfiguration beeinflussbaren Code dar, wobei die Konfiguration nicht Bestandteil der Modellierung ist. Zum Aufrufen dieses Codes müssen dann Frameworks, Bibliotheken und Fremd-Komponenten genutzt werden, die in einem separaten Entwicklungsprozess erstellt werden müssen.

Offenbarung der Erfindung

Es ist Aufgabe der Erfindung die Erstellung von ausführbaren Programmen zu erleichtern und eine Vorrichtung zu schaffen, mit welcher vollständige, ablauffähige Programme erstellt werden können. Erfindungsgemäß wird diese Aufgabe bei einer Vorrichtung der eingangs genannten Art dadurch gelöst, dass

(e) die Benutzungsoberfläche derart ausgebildet ist, dass die Eingabe ausführbarer Befehle zumindest teilweise in graphischer Form erfolgt,
(f) Teile des vordefinierten Programmcodes für die Zustandsmaschine als Einsprung in den Programmcode dienen,
(g) das dem Programm zugrunde liegende Modell graphische Symbole enthält, die instanziierte Klasse repräsentieren, und
(h) das dem Programm zugrunde liegende Modell graphische Symbole enthält, durch welche die Zustandsmaschine unmittelbare Schnittstellen zwischen Instanzen und Programmnutzern realisiert.

Unter instanziierten Klassen werden hier, wie in der Objekt-orientierten Programmierung üblich, abgeschlossene Adressbereiche von Programmdaten und Programmcode im Speicher verstanden. Programmnutzer umfassen dabei sowohl Anwender, als auch andere Programme.

Mit einer derartigen Vorrichtung ist es möglich, Programme ausschließlich auf graphischer Basis zu erstellen. Ablaufsteuerung und Fachlogik werden modelliert, d.h. graphisch programmiert. Das bedeutet, dass kein Text in Form von Befehlen oder ähnlichem an der Tastatur eingetippt werden muss. Der Programmierer braucht weder komplexe Programmiersprachen erlernen, noch benötigt er besondere Fertigkeiten bei der Eingabe von Texten. Er arbeitet vielmehr mit der Maus oder anderen Mitteln, mit welchen Befehle in graphischer Form eingegeben werden können. Die Befehle werden jedoch nicht nur in graphischer Form eingegeben. Vielmehr wird die Graphik auch direkt in ein ablauffähiges Programm umgesetzt. Dafür wird vorprogrammierter Programmcode verwendet, der als Einsprung dienen kann. Durch die direkte Instanziierung der Klassen z.B. im Arbeitsspeicher und das unmittelbare Zusammenwirken mit der Zustandmaschine ist das Programm zu jedem Zeitpunkt lauffähig. Es kann während der Entwicklung getestet werden. Der Programmierer braucht keine Schnittstellen zu programmieren.

Zur Realisierung spezifischer Aufgaben können aber auch Textbestandteile, z.B. Bezeichnungen für graphische Elemente oder Formeln eingegeben werden. Es können auch Möglichkeiten zur manuellen Eingabe von Programmcode vorgesehen sein.

Vorzugsweise sind auch die Zustände und Zustandsübergänge der Zustandsmaschine in graphischer Form eingebbar. Dadurch wird dem Programmierer die größtmögliche Übersicht über die Zusammenhänge ermöglicht. Es wird erreicht, dass auch die Reihenfolge von Befehlen in Abhängigkeit von zuvor ausgeführten Befehlen modelliert werden kann.

Es können Speichermittel zum persistenten Speichern von Daten vorgesehen sein und die instanziierten Klassen können Mittel zum persistenten Zugriff auf diese Daten umfassen. Persistentes Speichern ist das dauerhaft speichern, z.B. in einem Festspeicher. Dann kann mit dem Programm auch eine Datenbank verwaltet werden.

Es können weiterhin Mittel zur graphischen Gestaltung der Oberfläche des ausführbaren Programms vorgesehen sein. Dann wird nicht nur ein ablauffähiges Programm erzeugt, sondern auch eine ansprechende Oberfläche. Vorzugsweise umfassen die Mittel zur graphischen Gestaltung Eingabemittel, mittels welcher Präsentationselemente der graphischen Gestaltung graphisch eingebbar sind. Solche Präsentationselemente sind zum Beispiel Tabellen, Texte oder Bilder.

In einer besonders bevorzugten Ausbildung der Erfindung sind Mittel zum Speichern des dem Programm zugrundeliegenden Modells in einer zusammenhängenden Struktur, insbesondere in einer einzigen Datei vorgesehen. Solche Dateien sind leicht zu kopieren oder zu senden und daher leicht zu handhaben. Sämtliche bisherigen Programmierleistungen sind aus dieser Datei abrufbar.

Vorzugsweise sind die persistenten Daten verknüpft und das Modell umfasst graphische Symbole, welche die Verknüpfungen repräsentieren.

Zum Erstellen ausführbarer Programme wird erfindungsgemäß ein Verfahren mit den Schritten ausgeführt:

(a) Erstellen einer Graphik, welche ein einem Programm zugrundeliegendes Modell repräsentiert durch Eingabe ausführbarer Befehle zumindest teilweise in graphischer Form,
(b) Erzeugen von individuellem Programmcode aus dem Modell,
(c) Ausführen des auf dem Programmcode basierenden Programms mit einer Zustandmaschine und
(d) Ausführen vordefinierten Programmcodes in Form von wenigstens einer Basisklasse oder sonstigen vordefiniertem Code zur Bereitstellung von wiederkehrenden Algorithmen,
(e) Einspringen in den vordefinierten Programmcode über eine Zustandsmaschine,
(f) Bilden von instanziierten Klassen mittels der graphischen Symbole, und
(g) Eingeben von graphischen Symbolen zur Realisierung von unmittelbaren Schnittstellen zwischen Instanzen und Programmnutzern.

Durch dieses Verfahren werden alle vier Ebenen – Layout, Ablaufsteuerung, Fachlogik und Datenhaltung – in einer Struktur berücksichtigt. Die Anwendung wird vollständig erstellt. Die Mechanismen der Codegenerierung aus objektorientierter Modellierung (Fachlogik) werden mit den Prinzipien von endlichen Zustandsautomaten (Ablaufsteuerung) und deren Modellierung verbunden. Die Verwendung von offenen Schnittstellen erlaubt die Verwendung bereits bestehender Datenbestände oder professioneller Layouts.

Ausgestaltungen der Erfindungen sind Gegenstand der Unteransprüche. Ein Ausführungsbeispiel ist nachstehend unter Bezugnahme der beigefügten Zeichnungen näher erläutert.

Kurze Beschreibung der Zeichnungen

1 ist eine schematische Darstellung der Zusammenhänge der einzelnen Komponenten einer Vorrichtung zur graphischen Erstellung von ausführbaren Programmen

2 ist eine schematische Darstellung der Entwicklungsdatei im Detail

3 zeigt eine typische Oberfläche zur Modellierung der Fachlogik am Beispiel eines Programms zur Rechnungserstellung

4 zeigt die Oberfläche aus 3 mit Editor zur Eingabe und/oder Bearbeitung einer Methode am Beispiel eines Programms zur Rechnungserstellung

5 zeigt eine Oberfläche zur Modellierung der Ablaufsteuerung am Beispiel eines Programms zur Rechnungserstellung

6 zeigt eine Oberfläche zur Modellierung der Datenhaltung am Beispiel eines Programms zur Rechnungserstellung

7 zeigt einen fertig modellierten Dialog zur Eingabe von Daten

8 zeigt einen fertig modellierten Dialog in dem der Nutzer eine Auswahl an Ereignissen treffen kann.

9 zeigt einen fertig modellierten Dialog zur Eingabe von Verbrauchswerten und zum Auslösen einer Berechnung.

10 zeigt einen fertig modellierten Dialog zur Anzeige eines berechneten Wertes.

11 zeigt die Oberfläche aus 3 mit weiteren Elementen der Fachlogik.

12 zeigt die Oberfläche aus 3 mit Editor zur Eingabe und/oder Bearbeitung einer Methode

12a zeigt die Oberfläche aus 5 mit weiteren Elementen zur Ablaufsteuerung.

13 zeigt einen weiteren fertig modellierten Dialog in dem der Nutzer eine Auswahl an Ereignissen treffen kann.

14 zeigt einen fertig modellierten Dialog in dem der Nutzer eine Auswahl an Ereignissen und aus angezeigten Daten treffen kann.

15 zeigt einen fertig modellierten Dialog in dem der Nutzer ein Ereignis auslösen kann, ein Wert eingegeben werden kann und in dem ein Wert angezeigt wird.

16 zeigt einen fertig modellierten Dialog in welchem Werte aus verschiedenen Entitäten angezeigt werden, die in einer Beziehung zueinander stehen, angezeigt werden.

17 stellt eine Basisklasse in der Programmiersprache Java dar.

18a bis c stellt eine Entwicklungsdatei im XML-Format dar.

Beschreibung des Ausführungsbeispiels

Das Ausführungsbeispiel umfasst einen Personal Computer 10 mit der üblichen Hardware und Peripherie, einschließlich Bildschirm, Tastatur, Maus und Anbindung an ein Netzwerk. Auf dem Computer ist ein Betriebssystem, z.B. Windows, ein Compiler und eine Datenbank installiert. Die zur graphischen Erstellung eines ausführbaren Programms erforderlichen Strukturen auf dem Computer 10 sind in 1 dargestellt.

Zunächst ist ein allgemein mit 12 bezeichnetes Designer-Programm und ein ausführendes Programm 14 vorgesehen. Zur Entwicklung eines neuen Programms werden diese beiden Programme aufgerufen. Die bei der Entwicklung entstehenden Strukturen werden in Form eines vorläufigen oder endgültigen Entwicklungsergebnisses in einer Entwicklungsdatei 16 gespeichert. Die Entwicklungsdatei 16 wird mit dem Designerprogramm 12 erstellt.

Im Designer 12 werden dem Anwender für die 4 Ebenen der zu erstellenden Anwendung jeweils mehrere Zeichenflächen zur modularen Modellierung bereitgestellt Das Designerprogramm 12 umfasst eine Oberfläche 18 zur Erstellung des Layouts, eine Oberfläche 20 zur Erstellung der Ablaufsteuerung, eine Oberfläche 22 zur Erstellung der Fachlogik und eine Oberfläche 24 für die Datenhaltung. Die einzelnen Elemente der Modellierung entsprechen den Inhalten der Entwicklungsdatei. In den 3 bis 6 sind die wichtigsten Oberflächen des Designers 12 teilweise im Detail dargestellt. Anhand der Entwicklungsdatei wird durch einen Generator 15 Programmcode generiert, der später von dem ausführbaren Programm 14 ausgeführt wird.

Die mit Bezugszeichen 49 bezeichneten Kästchen in 1 zeigen, dass das ausführende Programm 14, also die Zustandsmaschine in unterschiedlichen Architekturen für verschiedene Plattformen hergestellt werden kann.

Das mit Bezugszeichen 47 bezeichnete Kästchen in 1 stellt den Zugriff der Zustandsmaschine auf eine Datenbank und andere externe Systeme, sowie den Austausch zwischen der Datenbank und Back-Office-Systemen dar.

Auf einer ersten Ebene, die in 3 dargestellt ist, wird die Fachlogik der Anwendung modelliert. Dort werden Instanzen direkt modelliert.

Es werden allgemein zwei modellierbare Objekttypen unterschieden: Objekt und Entität. Objekte können Eigenschaften (Attribute) vom Typ Integer, String, Float, Time, Date und Fremddefinierte enthalten.

In 3 ist ein Beispiel für eine Oberfläche zur Erstellung der Fachlogik dargestellt. Die Oberfläche umfasst ein Menü 26, eine Zeichenfläche 28, Buttons 30 bis 48, ein Eingabefeld 50 und Anzeigefelder 52 bis 58 zur Anzeige von Informationen. Wie u.a. mit dieser Oberfläche ein ausführbares Programm erstellt wird, ist am Beispiel eines Programms zur Rechnungserstellung illustriert. Eine Gesamtrechnung soll aus einer Stromrechnung, einer Wasserrechnung und einer Gasrechnung bestehen. Strom, Wasser und Gas sind durch Einheitspreis und Verbrauch gekennzeichnet. Es müssen also zunächst die Objekte mit ihren Attributen und einer Methode zum Berechnen des Rechnungsbetrages angelegt werden.

Das Objekt wird angelegt indem der Button 30 angeklickt wird. Dann kann mit der Maus auf der Zeichenfläche 28 ein Rechteck, z.B. das Rechteck 60 oder 62 erstellt werden. Jedes dieser Rechtecke dieser oder anderer Zeichenflächen kann ausgewählt werden. Dies kann zum Beispiel durch einen Doppelklick erfolgen. Bei Auswahl eines solchen Rechtecks kann der Anwender in einem Bereich der Oberfläche Eingaben vornehmen. Solche Eingaben sind für spezifischen Informationen des jeweiligen Elements vorgesehen. Dort kann beispielsweise der Objektname in Feld 50 eingetragen werden. Für das durch ein Rechteck 62 repräsentierte Objekt wird hier der Name „Wasser" eingetragen. Statt Objekten können auch Access oder Entitäten durch Anklicken der Buttons 32 oder 34 erstellt werden.

Durch Anklicken auf Button 36 kann dem Objekt eine Eigenschaft, d.h. ein Attribut zugeordnet werden. Der Name dieses neuen Attributs – hier „wverbrauch" – wird in ein Feld 64 eingetragen. Weiterhin erhält das Attribut einen Anfangswert – hier „000" – , der in einem Feld 66 eingetragen werden kann. In einem Auswahlfeld 68 kann festgelegt werden, von welchem Typ das Attribut ist. Im vorliegenden Beispiel ist der Wasserverbrauch eine ganze Zahl, d.h. der Typ ist „Integer". Es können aber auch Datum, Zeit oder dergleichen als Typen festgelegt werden.

Auf diese Weise können die Objekte, im vorliegenden Fall Gas, Wasser, Strom und Rechnung definiert werden. Das Objekt Rechnung hat die Attribute „Basis", entsprechend einer Grundgebühr, „Betrag", entsprechend dem Ergebnis der Berechnung des Rechnungsbetrags und eine Methode.

An Objekten können Methoden definiert werden. Entitäten zeigen auf Datenbank Tabellen. An ihnen können Finder definiert werden, welche Datensätze einer Tabelle in die Instanzen im Arbeitsspeicher laden. Die Datensätze erfüllen die durch den Finder definierten Auswahlkriterien. An Objekten und Entitäten können vordefinierte Methoden aufgerufen werden. So können z. B. „create" oder „delete" als Methode an einer Entität aufgerufen werden, um Datensätze zu erstellen oder zu löschen. Entitäten besitzen automatisch Attribute, welche anhand der Spalten (Columns) der Tabelle, auf die sie zeigen, abgeleitet werden. Diese Attribute sind n-dimensional (z. B. Array).

Methoden und Finder sind ausführbar und besitzen Rückgabewerte. Das bedeutet, dass nach der Ausführung der Methode ein Wert für die weitere Verarbeitung vorliegt. Bei einer Methode ist das zum Beispiel das Ergebnis einer Rechenvorschrift. Bei einem Finder ist es zum Beispiel die Anzahl der gefundenen Datensätze, welche die mit dem Finder definierten Eigenschaften erfüllen und in den Arbeitsspeicher geladen wurden. Durch das Anlegen von Access-Pfeilen zwischen Objekten wird definiert, von welchen dieser ausführbaren Methoden oder Finder auf andere Objekte zugegriffen werden kann. Objekte können außerdem Fremdlogik importieren oder verwenden. Eine solche Fremdlogik sind zum Beispiel CORBA-Objekte, oder anderer externer Programmcode.

Die Methoden und Finder können mit einem zusätzlichen Editor editiert werden. Die Methoden können durch Sequenzdiagramme modelliert werden. Die Finder können durch die graphische Auswahl logischer, modell-bezogener Bedingungen modelliert werden. Neben den obigen Objekten können zusätzliche vordefinierte Objekte genutzt werden (z.B. emailObjekt) und werden dem Programmierer als fertige Objekte zur Nutzung bereitgestellt.

Die Methode wurde im vorliegenden Beispiel durch Anklicken des Buttons 42 erstellt. Dann wird, wie in 4 dargestellt, im Bereich 70 der Oberfläche der Name der Methode „Rechnung ()" eingegeben. In einem Editor 72 kann eine Formel eingegeben werden, nach welcher der Rechnungsbetrag berechnet werden soll. Im vorliegenden Fall ist das die Summe aus dem Produkt aus jeweiligem Einheitspreis und dem jeweiligen Verbrauch für Strom, Gas und Wasser. Diese Werte wurden zuvor als Attribute der übrigen Objekte definiert. Die Methode „Rechnung ()" hat also den Rückgabewert „betrag".

Mit den Buttons 38 und 44 können Objekte und Methoden wieder gelöscht werden. Mit den Buttons 40 und 46 können Änderungen vorgenommen werden. Durch Anklicken des Buttons 32 können Zugriffe (Access) zwischen den Objekten hergestellt werden. So greift das Objekt „Rechnung" im vorliegenden Beispiel auf die übrigen Objekte zu.

Durch Auswahl im Menü 26 kann nun die Oberfläche zur Modellierung der Ablaufsteuerung aufgerufen werden. Bei der Ablaufmodellierung kann der Programmierer die Zustände der Anwendung festlegen. Solche Zustände sind in der Regel Dialoge. Ein Dialog ist zum Beispiel ein Fenster, in welchem ein Wert abgefragt und eingegeben werden kann. Ein solches Fenster ist beispielsweise in 7 dargestellt. Weiterhin kann definiert werden, welche Daten woher gelesen werden müssen, bevor dieser Zustand erreicht wird. Das entspricht den Input-Parametern eines Dialogs. Außerdem kann definiert werden, welche Daten wohin geschrieben werden müssen, wenn der Zustand erreicht ist. Das entspricht den Output-Parametern eines Dialogs. Die Definitionen beziehen sich auf die in der Fachlogik definierten Objekte und Entitäten, auf die sonstigen zur Verfügung gestellten Objekte, und die Programmnutzer.

Über Ereignisse wird außerdem definiert, welcher Folgezustand eintreten soll, d.h. für die jeweiligen Ereignisse kann modelliert werden, zu welchem Zustand ein Übergang stattfinden soll. Ein solches Ereignis ist zum Beispiel das Anklicken eines Buttons oder das Berechnen eines Wertes. Nach dem Ausführen von Aktionen kann dazu der Rückgabewert der Ausführung herangezogen werden. Dazu werden die Rückgabewerte der Methoden und Finder angeboten. Bei der Modellierung wird ein Ereignis, z.B. ein Button, durch den man zu einem neuen Dialogfeld gelangt, durch einen Pfeil repräsentiert.

Zur Modellierung der Ablaufsteuerung wird im vorliegenden Beispiel über das Menü 26 die in 5 dargestellte Oberfläche aufgerufen. Auch hier wird modelliert, d.h. durch Eingabe von graphischen Symbolen programmiert. Dazu ist eine Zeichenfläche 80 vorgesehen.

Es können mittels Buttons 82, 84 und 86 Dialoge, Ereignisse und Switche erstellt werden. Ein Switch ist ein graphischer Knoten im Modell. Der Knoten beschreibt verschiedene Möglichkeiten von Folgezuständen, welche in Abhängigkeit des Rückgabewertes von Methoden bzw. Findern eingenommen werden. Die Dialoge werden in Feld 88 mit einem Namen versehen. Ähnlich wie bei den Objekten erhalten die Komponenten der Ablaufsteuerung Namen in Feld 88. Über den Button 89 werden die Parameter eines Dialoges angelegt. Die Ereignisse können über den Button 91 bearbeitet werden.

Im vorliegenden Beispiel wurde der Startdialog „Start" angelegt. Mit diesem Dialog wird die Anwendung gestartet. Weiterhin können die Preise geändert werden. Hierfür ist der Dialog 96 vorgesehen. Zur Eingabe des Verbrauchs ist der Dialog 98 vorgesehen. Dieser Dialog umfasst die Eingabefelder „sverbrauch" (Stromverbrauch), „wverbrauch" (Wasserverbrauch) und „gverbrauch"(Gasverbrauch). Das zugehörige Fenster des Programms während der Ausführung ist in 7 dargestellt. In diesem Fenster wird dem Benutzer das Ereignis „Verbrauch-Rechnung" zur Verfügung gestellt. Das Ereignis ist mit 120 bezeichnet. Weiterhin wird zu diesem Ereignis ein Objekt (Rechnung) eingegeben und die Methode „rechnung" (4) eingegeben. Dies erfolgt in den Feldern 102 und 104.

Bereits zu diesem Zeitpunkt kann die Anwendung – auch ohne weitere Erstellung von Layout oder Datenhaltung exportiert, generiert, compiliert und ausgeführt werden. Das Modellierungsergebnis wird in der Entwicklungsdatei gespeichert.

Die Datei wird ohne Eingabe von Programmbefehlen oder sonstigem Programmcode automatisch erstellt. Sie kann in beliebiger, geeigneter Notation, auch in einer Notation, die nicht-öffentlich ist, erstellt werden. Die Entwicklungsdatei 12 unterliegt dem Schema nach 2.

Kästchen in 2 bezeichnen allgemein Elemente der Datei. Pfeile bezeichnen die Beziehungen zwischen den einzelnen Elementen. Die Pfeile sind mit der Angabe der Kardinalitäten versehen. Objekte sind mit 1 bezeichnet. Sie können eine beliebige Anzahl an Attributen 25 in der Entwicklungsdatei 16 enthalten. Dies umfasst auch den Fall n=0, d.h. kein Attribut. Die Kardinalität der Beziehung ist mit „1:n" unterhalb des mit 31 bezeichneten Pfeils angegeben. Das bedeutet ein Objekt kann jede beliebige Zahl n an Attributen aufweisen. In umgekehrter Richtung, dargestellt durch Pfeil 33, wird jedoch gezeigt, dass jedes Attribut Inhalt genau eines Objekts sein kann. Dies wird durch die Kardinalität 1:1 angegeben.

Ein Objekt 1 der Entwicklungsdatei 16 kann beliebig viele Methoden 11 beinhalten. Dies ist dargestellt durch Pfeil 35. Eine Methode 11 ist immer Inhalt eines Objekts 1. Dies ist dargestellt durch Pfeil 39. Ein Objekt 1 der Entwicklungsdatei 16 kann beliebig viele Accesses 5 beinhalten. Dies ist dargestellt durch Pfeil 37. Eine Spalte Tabelle 17 der Entwicklungsdatei 16 kann beliebig viele Accesses 5 beinhalten. Ein Access 5 beinhaltet immer ein Objekt 1 oder eine Entität 17. Dies ist dargestellt durch Pfeile 41 und 43. Ein Access 5 ist immer Inhalt einer Entität 17 oder eines Objekts 1. Eine Entität 17 der Entwicklungsdatei 16 kann beliebig viele Tabellen 31 beinhalten. Eine Tabelle 31 kann Inhalt mehrerer Entitäten 17 sein. Eine Entität 17 der Entwicklungsdatei 16 kann beliebig viele Finder 23 beinhalten. Ein Finder 23 ist immer Inhalt einer Entität 17. Eine Tabelle 31 der Entwicklungsdatei 16 kann beliebig viele Spalten 21 beinhalten. Eine Spalte 21 ist immer Inhalt einer Tabelle 31. Eine Tabelle 31 der Entwicklungsdatei 16 kann beliebig viele Relationen 29 beinhalten. Durch die Angabe von Relationen kann der Anwender bestimmen, dass Beziehungen zwischen den Tabellen bestehen. Eine Relation ist eine Beziehung zwischen Dateneinträgen verschiedener Tabellen, z.B. Kunde – Adresse. Eine Relation 29 beinhaltet immer eine Tabelle 31. Eine Relation 29 ist immer Inhalt einer Tabelle 1. Ein Dialog 3 der Entwicklungsdatei 16 kann beliebig viele Ereignisse 7 beinhalten. Ein Ereignis 7 ist immer Inhalt eines Dialogs 3. Ein Ereignis 7 der Entwicklungsdatei 16 kann mehrere Executes 19 beinhalten. Ein Execute ist eine Verknüpfung eines Ereignisses mit einem auführbaren Element, zum Beispiel einer Methode oder einem Finder. Ein Execute 19 ist immer Inhalt eines Ereignisses 7. Ein Execute 19 der Entwicklungsdatei 16 kann eine Methode 11 oder einen Finder 23 beinhalten. Eine Methode 11 kann Inhalt beliebig vieler Execute 19 sein. Ein Finder 23 kann Inhalt beliebig vieler Execute 19 sein. Ein Switch 13 der Entwicklungsdatei 16 ist immer Inhalt eines Ereignisses 7. Ein Switch 13 der Entwicklungsdatei 16 kann beliebig viele Rückgabewerte 27 beinhalten. Ein Rückgabewert 27 beinhaltet einen Dialog 3. Ein Dialog 3 kann Inhalt beliebig vieler Rückgabewerte 27 sein. Ein Rückgabewert 27 kann Inhalt beliebig vieler Switches 13 sein. Ein Dialog 3 der Entwicklungsdatei 16 kann beliebig viele Parameter 9 beinhalten. Ein Parameter 9 ist Inhalt eines Dialogs 3. Eine Entität 17 der Entwicklungsdatei beinhaltet die Spalte 21 indirekt über die Tabelle 31, die sie beinhaltet. Ein Parameter 9 beinhaltet ein Attribute 25 eines Objekts 1 oder eine Spalte 21 einer Entität 17. Die Spalte 21 wird indirekt über die Entität 17 referenziert. Ein Attribut 25 kann Inhalt beliebig vieler Parameter 9 sein. Eine Spalte 21 kann Inhalt beliebig vieler Parameter 9 sein. Ein Layout 15 kann einen Dialog 3 beinhalten. Ein Layout 15 kann die Parameter 9 eines Dialoges 3 beinhalten. Ein Layout 15 kann die Ereignisse 7 eines Dialoges 3 beinhalten. Ein Layout 15 kann weitere Layout-spezifische Elemente beinhalten. Ein Parameter 9 kann eine Richtung haben.

Das mit dem Designer 12 entwickelte Programm in Form eines graphisch dargestellten Modells wird in der Entwicklungsdatei 16 gespeichert. Mit einem weiteren Programm, dem Generator 15, wird dann lauffähiger Programmcode erstellt. Der Generator, in 1 mit 15 bezeichnet, kann ein eigenes Programm sein, oder ein Teil des ausführenden Programms. Er interpretiert in erster Linie die fachlogischen Teile der Entwicklungsdatei. Dies erfolgt vor der Laufzeit des erstellten Programms. Dabei werden die einzelnen Codestrukturen, zum Beispiel Klassen von Objekten, zur späteren Instanziierung, „automatisch" erzeugt. Es entsteht hier ein ausführbares Programm in einer Programmiersprache. In einem alternativen Ausführungsbeispiel wird der vom Generator erzeugte Programmcode von einem Server ausgeführt. Dann befindet sich das ausführende Programm 14 auf dem Server.

Das ausführende Programm 14 zieht die Entwicklungsdatei 16 zur Ausführung der Anwendung heran. Über die Entwicklungsdatei 16 wird so die Kommunikation zwischen den beiden Programmen 12 und 14 realisiert. Das ausführende Programm 14 kann für verschiedene Plattformen, z.B. Solaris, Windows, etc. und für verschiedene Architekturen, z.B. J2EE, vorliegen.

Die Interpretation der Entwicklungsdatei erfolgt nach folgendem Verfahren: Es erfolgt zunächst eine Parsierung, bei welcher die in der Entwicklungsdatei 16 gespeicherten Informationen in eine Programmiersprache übersetzt wird. Der proprietäre Code der Entwicklungsdatei 16 wird dabei aufgelöst und in die jeweilige Programmiersprache parsiert. Hierbei werden modellbezogene Schlüsselwörter zur Verfügung gestellt, mit denen speziell auf die Elemente der Fachlogik zugegriffen werden kann. Zum Beispiel:

wird im Fall von Entität zu:

oder

wird im falle java zu

Es versteht sich, dass auch jede beliebige andere Sprache mit anderen Befehlen verwendet werden kann, je nachdem, in welcher Form die Erfindung vom Anwender verwirklicht wird.

Außerdem werden die Suchbedingungen der modellierten Finder parsiert und in die verwendete QueryLanguage, also in die verwendete Suchsprache übersetzt.

Nach der Parsierung wird eine Basisklasse zum Aufrufen der generierten Instanzen dem ausführenden Programm zur Verfügung gestellt. Eine Basisklasse ist ein Abschnitt vorprogrammierten Programmcodes. Die Basisklasse bietet allgemeine Methoden zum Setzen und Lesen von Attributen, sowie zum Ausführen von Methoden und Findern an. Weiterhin enthält die Basisklasse Attribute, die den Zustand der Instanz einer Klasse durch das ausführende Programm abfragbar macht. Sie besitzt eine Methode zum Setzen der Objekte, welche in der Modellierung durch Zugriffspfeile von diesem Objekt erreicht wird. Zusätzlich können vordefinierte Methoden von der Basisklasse angeboten werden.

Ein Beispiel für eine Basisklasse in der Programmiersprache Java ist in 17 dargestellt. Sie kann über den Java-eigenen Mechanismus der Reflection vom Classloader geladen werden.

Die einzelnen Zeilen des Beispiels für eine Basisklasse sind mit 401 bis 420 bezeichnet. In den Zeilen, die mit 403 bis 406 bezeichnet sind, befinden sich interne Variablen zur Beschreibung des Zustandes der abgeleiteten instanziierten Klassen. In der mit 408 bezeichneten Zeile ist eine abstrakte Methode zum Setzen von Attributwerten durch die Zustandsmaschine an abgeleiteten instanziierten Klassen dargestellt. Zeile 410 zeigt eine abstrakte Methode zum Setzen von zugreifbaren Objekten (MemberObjects) durch die Zustandsmaschine an abgeleiteten instanziierten Klassen. Zeilen 412 bis 416 zeigen eine Methode zum Abfragen von Attributwerten durch die Zustandsmaschine. Diese Methode wird durch die instanziierten Klassen überschrieben. Dies gilt für alle abstrakten Methoden. Zeilen 417 bis 418 zeigen eine abstrakte Methode zum Ausführen von Methoden und Findern mittels des als Methoden-Parameter übergebenen Namens der auszuführenden Methode oder des Finders.

Außerdem können an der Basisklasse allgemeine Methoden zur Nutzung durch die generierten Instanzen, sowie durch die Zustandsmaschine zur Verfügung gestellt werden.

In C++ ist ein eigener Classloader anhand der Entwicklungsdatei zu generieren. Der Classloader instanziiert dann zur Laufzeit die speziellen Klassen. Der Anwender braucht daher die Klassen nicht zu kennen. Er arbeitet direkt mit den Instanzen im Speicher. In C ist eine solche Basisklasse durch aggregierte Strukturdefinitionen zu deklarieren.

Nach der Erstellung der Basisklasse können schließlich die Klassen der modellierten Instanzen direkt durch den Generator 15 erzeugt werden. Dies erfolgt durch eine Iteration über die Objekte der Entwicklungsdatei. Dabei werden die Imports/Includes erzeugt, der Klassenrumpf erzeugt und anschließend der Objekttyp (Objekt oder Entität) gelesen.

Bei der Interpretation der Entwicklungsdatei werden folgende Aktionen in beliebiger Reihenfolge durchgeführt:

• Generieren der Deklaration der Referenzen auf die MemberObjekte der Entwicklungsdatei, dazu Iterator über die Accesses der Entwicklungsdatei um den speziellen Klassennamen zu erzeugen.
• Generieren von Attributen. Dazu werden bei Entitäten Tabellen der Entwicklungsdatei durchsucht, um die Attribute zu erzeugen, welche den Spalten entsprechen. Die Attribute werden aus der Entwicklungsdatei gelesen. Bei Entitäten werden die Attribute in Form von Arrays, Collections oder anderen Mehrfach-Platzhaltern deklariert.
• Generieren der „setAttributeByName"-Methode, welche anhand des übergebenen Parameters die Attribute der generierten Klasse setzt. Eine „set"-Methode ist allgemein eine Methode, die Werte setzt. Im vorliegenden Fall setzt sie den Wert eines Attributes anhand des im Paramter übergebenen Namens des Attributs.
• Generieren der „getAttributeByName"-Methode, welche anhand des übergebenen Parameters den Attributewert der generierten Klasse zurückgibt. Eine „get"-Methode ist allgemein eine Methode, die Werte zurückgibt. Dadurch kann die Zustandsmaschine, d.h. das ausführende Programm, die Attribute einer instanziierten Klasse abfragen, ohne die Klasse zur Compilierungszeit zu kennen. Analog arbeitet die „setAttributeByName"-Methode zum Setzen der Attribute.
• Generieren von setObjectByName zum Setzen der Memberobjekte anhand ihres Namens. Die Instanziierten Klassen, welche über Access zugreifbar sind, werden in dieser Methode der entsprechenden Membervariablen zugewiesen. Mit anderen Worten: Diese Methode dient zum Setzen der internen Variablen mit den Zeigern auf die über Access modellierten Entitäten und/oder Objekte.
• Generieren von Methoden. Hierfür wurde der Code bereits parsiert und liegt in der jeweiligen Sprache vor.
• Generieren von vordefinierten Methoden. Das sind zum Beispiel „store" oder „clear" zum Zwischenspeichern von Daten bzw. zum Reinitialisieren von Objekten oder bei Entitäten „save", „create", „load" und „delete" zum Speichern, Anlegen, Laden und Löschen von Tabelleneinträgen.
• Lesen von Informationen aus der Entwicklungsdatei zum Generieren der datenbankbezogenen Abfrage-Sprache.
• Generieren von Relatoren und Separatoren zum Anlegen und Löschen persistenten Verknüpfungen zwischen Entitäten, falls auf der Datenbank-Ebene eine Beziehung zwischen zwei Entitäten modelliert wurde. Relatoren und Separatoren sind also Methoden einer Entität zum Setzen bzw. Auflösen von persistenten Beziehungen zwischen zwei Entitäten.
• Generieren von Findern
• Generieren von FinderFromRelation
• Generieren der allgemeinen Ausführmethode „execute", welche durch die Zustandsmaschine genutzt werden kann, um Methoden an instanziierten Klassen aufzurufen. Die „execute"-Methode wird derart generiert, das in einer Abfrage der als Parameter übergebene String mit den Methoden der Klasse verglichen wird, und bei Übereinstimmung die entsprechende Methode aufgerufen wird. Dabei müssen sowohl Finder, als auch Methoden, als auch vordefinierte Methoden der Basisklasse berücksichtigt werden.

Im Anschluss an die Interpretation der Entwicklungsdatei erfolgt eine automatische Compilierung, Linkung und Deployment durch einen SkriptLauf durch den Generator 15, das ausführende Programm 14 oder den Designer 12. Es liegt dann ein ausführbares Programm vor, welches durch den Interpreter, d.h. durch den Zustandsautomaten ausgeführt wird.

Beim erstmaligen Aufruf werden folgende Schritte durchgeführt:

• Datenbank-Verbindung initial erzeugen
• Objekte und Relationen initial erzeugen
• Datenbank-Tabellen initial erzeugen, falls sie noch nicht vorhanden sind
• Verbindungs-Tabellen erzeugen, falls sie noch nicht vorhanden sind
• Start-Dialog als aktuellen Dialog setzen

Bei allen Aufrufen werden folgende Schritte durchgeführt:

• Requestparameter lesen. Das sind die Inputparameter des aktuellen Dialogs aus der Entwicklungsdatei
• neue Objekte und Relationen für den Dialog anlegen, wenn sie in der Entwicklungsdatei vorgesehen sind
• Ausgelöstes Ereignis aus dem Request lesen
• wenn ein Ereignis vorliegt (außer bei Programmstart): • Execute (falls vorhanden) Dazu eventuell vom Programmnutzer ausgewählte Daten übergeben, bzw. anhand der vom Benutzer ausgewählten Daten den entsprechenden Zustand der Entitäten herbeiführen (z.B. Laden eines ausgewählten Tabelleneintrags in die entsprechenden Entitäten). • Transition lesen • Switch lesen (falls vorhanden) • neuen Dialog setzen
• Neuen Dialog erstellen. Dazu werden Layout-Informationen zu dem Dialog gelesen und anhand der gelesenen Reihenfolge die Ausgangs-Attribute für den Dialog ausgelesen und dargestellt, die Eingangs-Attribute für den Dialog dargestellt und die Ereignisse dargestellt.

Im Ergebnis entsteht ein Programm, welches die in den 7 bis 10 dargestellten Dialoge und Fenster vorsieht. In 8 ist das Start-Fenster dargestellt. Dies entspricht Rechteck 94 in 5. Es sind drei Handlungen möglich. Anklicken des Buttons 110 und berechnen des Rechnungsbetrags entsprechend dem Pfeil 112 in 5. Anklicken des Buttons 114 und Eingeben von Verbrauchsdaten entsprechend dem Pfeil 116 in 5 Anklicken des Buttons 118 und Eingabe von Preisen entsprechend dem Pfeil 122 in 5.

Bei Anklicken von Button 118 wird das in 7 dargestellte Fenster geöffnet. Nun können die Preise eingeben oder geändert werden. Mit anderen Worten: über die Dialog-Parameter können die Attribut-Werte der Instanzen im Speicher für die Objekte geändert werden. Hierzu sind Eingabefelder 124, 126 und 128 vorgesehen. Es können alternativ auch Dialog-Parameter definiert werden, welche als Input-Parameter eine Zuweisung zwischen den Attributen einer Entität und denen eines Objektes durchführen. Mit Anklicken des Buttons 130 gelangt man zurück zum Startmenü. Dies entspricht der umgekehrten Richtung von Pfeil 122 in 5. Weitere Möglichkeiten sind nicht vorgesehen. Daher sind keine weiteren Pfeile an Dialogfeld 96 in 5 modelliert.

Bei Anklicken von Button 114 in 8 wird das in 9 dargestellte Fenster geöffnet. Nun können Verbrauchswerte eingegeben oder geändert werden. Hierzu sind Eingabefelder 132, 134 und 136 vorgesehen. Diese entsprechend den drei Input-Parametern „sverbrauch", „wverbrauch" und „gverbrauch", die für den Dialog 98 in 5 modelliert wurden. Durch Anklicken des Buttons 138 wird der Rechnungsbetrag berechnet und in einem neuen Fenster entsprechend 10 angezeigt. Dies entspricht dem Pfeil 120 in 5. Weitere Möglichkeiten, zum Beispiel ein Button zum zurückgelangen in das Start-Menü sind nicht modelliert. Mit dem Ereignis 120 wird die Berechnung „Verbrauch-Rechnung", die im Editor eingegeben wurde, durchgeführt. Anschließend wird der Dialog „Rechnung" 100 in 5 aufgerufen. Dort wird der Rechnungsbetrag angezeigt. Das Dialogfeld ist in 10 dargestellt. Dieses Fenster kann nicht verlassen werden, da kein entsprechender Pfeil modelliert wurde, der von diesem Dialog abgeht. Es ist entsprechend kein Button vorgesehen.

Durch Anklicken des Buttons 110 in 8 wird lediglich der Rechnungsbetrag ausgegeben, ohne zuvor Daten einzugeben.

Neben der beschriebenen Modellierung von Fachlogik und Ablaufsteuerung wird die Datenhaltung ebenfalls modelliert. Die Datenhaltung umfasst Tabellen mit Spalten (Columns) In den Spalten sind Daten der Typen integer, string, float, date, time, binary large Objekts gespeichert. Die Tabellen können angelegt werden. Es können auch bereits bestehende Tabellen genutzt werden. Durch die Angabe von Relationen kann der Anwender bestimmen, dass Beziehungen zwischen den Tabellen bestehen. Eine Relation ist eine Beziehung zwischen Dateneinträgen verschiedener Tabellen, z.B. Kunde – Adresse.

Es können auch Anzahlen (Kardinalitäten) für diese Beziehungen angegeben werden. Eine solche Anzahl ist zum Beispiel die Anzahl der speicherbaren Adressen pro Kunde. Darüber hinaus können auch komplexe Datenbank-Modelle entwickelt werden, die beispielsweise Datenbank-Trigger als ausführbare Elemente der Fachlogik zur Verfügung stellen. Ein Datenbank-Trigger löst Aktionen zum Beispiel nach einem erfolgten Zugriff auf definierte Tabellenspalten, oder bestimmten Werten aus. Die Trigger können von der Ablaufsteuerung als Elemente der Fachlogik genutzt werden. Auch Transaktionselemente wie Commit oder Rollback können integriert werden.

Über das Menü 26 gelangt man zu der in 6 dargestellten Oberfläche zur Modellierung der Datenhaltung. Damit kann in obigem Programm zu vorhandenen Kunden die monatliche Rechnung gespeichert werden. Es wird also durch Anklicken eines Buttons 140 jeweils eine Tabelle 142 „KUNDE" und eine Tabelle 144 „RECHNG" angelegt, falls sie nicht bereits existiert. Diese sind jeweils durch ein Feld in der Zeichenfläche 146 repräsentiert. Zu der Tabelle 142 gehört die Spalte „string name" , welches eine Zeichenkette aufnehmen kann und zur Tabelle 144 die Spalten „Integer betrag" und „Integer monat", welche ganzzahlige Werte (= Integer) annehmen. Um die Rechnungen den einzelnen Kunden zuzuordnen, wird eine Beziehung zwischen den Tabellen angelegt. Dies ist durch einen Pfeil 148 dargestellt. Die zugehörige Relation „RECHNG-KUNDE" wird im Feld 150 angezeigt und über den Button 149 angelegt.

In der Fachlogik werden nun die Objekte „Kunde" und „Rechnung" vom Typ Entität angelegt. Diese zeigen auf die jeweiligen Tabellen. Das Modell aus 3 verändert sich daher auf die in 11 gezeigte Weise. Neben den Objekten „Rechnung", „Gas", „Wasser" und „Strom" wurden noch die Entitäten 152 und 154 angelegt.

Um die Kunden anzeigen zu können, wird ein Finder „findall()" 156 an dem Kunden 152 angelegt. Da keine Bedingung zum Suchen in der „Kunde"-Tabelle an dem Finder definiert wurde, werden alle Einträge gefunden. Außerdem soll der berechnete Betrag für den entsprechenden Kunden in die „RECHNG"-Tabelle 144 eingetragen werden. Dazu wird ein Access (Zugriff) „Rechng-Kunde" 145 durch den Button 32 in der Zeichenfläche 163 erzeugt. Der Zugriff besteht von der Entität „Rechng" 154 auf die Entität „Kunde" 152.

Weiterhin wird ein Objekt „Action" 164 erzeugt. Das Objekt hat die Methode „assign ()". Diese Methode wird genutzt, um die Beziehung zwischen Kunde und Rechnung direkt aufzubauen, ohne über überflüssige Dialoge zu gehen. Dazu werden die Methoden „assign" und „show" angelegt. Die Methode wird wie oben beschrieben separat per Editor 166 eingegeben. Dies ist in 12 dargestellt. „assign ()" sorgt dafür, dass ein Rechnungseintrag angelegt und mit dem aktuellen Kunden verbunden wird. Auf gleiche Weise kann die Methode „show ()" eingegeben werden. Hier wird dann eingegeben:
Kunde.index=index;
Kunde.load();
Rechng.fromKunde();

Es versteht sich, dass dieser in Codeform eingegebene Text keine vollständige Programmierung darstellt, sondern nur eine vereinfachte Möglichkeit der Eingabe von Methoden und wiederkehrenden Zuweisungen, welche auch in einer Auswahl Liste Angeboten und im Dialog mit einem execute verknüpft werden könnten. Die eigentliche Erstellung des später ausgeführten Programmcodes erfolgt durch Interpretation des Modells durch den Generator und das ausführende Programm (die Zustandsmaschiene). Darüber hinaus ist es optional möglich, z.B. zur Berechnung von Formeln, Programmcode von Hand zu erstellen.

„show()" lädt den vom Dialog ausgewählten Kunden und findet alle Rechnungen für diesen Kunden. Außerdem wird der im Editor 72 in 4 eingegebene Code der „Rechnung()"-Methode geändert. Es wird hinzugefügt:
Rechng.betrag[0] = betrag;

Mit anderen Worten: der aktuelle Rechnungsbetrag wird in die gespeicherte Tabelle eingetragen.

Durch diese Hinzufügung wird der Rechnungsbetrag unmittelbar nach der Berechnung entsprechend der editierten Formel in die Entität 154 eingefügt. In der Dialogmodellierung wird davon ausgegangen, dass die „Kunde"-Tabelle 142 bereits gefüllt vorliegt.

Vom Start-Dialog 94, entsprechend dem Fenster in 8, wird ein Ereignis angelegt, bei dessen Auftreten der „findall"-Finder der Entität „Kunde" 152 aufgerufen wird. Die Ablaufsteuerung verändert sich also in der in 12a dargestellten Weise gegenüber 5. Das neue Startfenster 94 ist in 13 dargestellt. Vom Kunden-Dialog 168, dargestellt in 14, aus wird nun bei dem Ereignis „Kunde-Verbrauch" entsprechend Pfeil 170 die vordefinierte Methode „load" der Entität „Kunde" 142 aufgerufen. Dies erfolgt durch Betätigen des Buttons 180. Die Entität „Kunde" ist also mit dem aktuell per Tick 184 ausgewählten Kundendatensatz gefüllt. Nun kann wie zuvor im Dialog Verbrauch 98 dargestellt in 9 über den Button 138 die mit dem Ereignis 120 verknüpfte Methode „rechnung()" angestoßen werden. Durch die erwähnte Erweiterung der Methode „rehnung()" ist nun die Entität Rechng() 154 mit dem berechneten Wert gefüllt. Außerdem kann im Dialog Rechnung 100 der Monat der Rechnung eingegeben werden, da dieser als zusätzlicher Dialog-Parameter modelliert wurde. Dadurch kann bei dem Ereignis „Rechnung-Start" 112 (12) die Methode „assign()" des Objekts „Action" aufgerufen werden. Die Methode „assign()" erstellt eine persistente Beziehung zwischen dem ausgewählten Kunden und der Rechnung. Dabei erzeugt „create()" den Eintrag mit dem Monat und dem berechneten Wert in der Rechnungstabelle. „relKunde" erzeugt den Eintrag zwischen dem ausgewählten Kunden und der Rechng in die Beziehungstabelle.

Nach der Berechnung kann nun die Rechnung für einen Kunden angezeigt werden. Dazu wird ein weiteres Fenster „RechAnz" 172 erzeugt. Dies ist in 16 dargestellt. Über das Ereignis „Kunden-RechAnz", das durch den Pfeil 174 repräsentiert ist, gelangt man dorthin. In dem Fenster „Kunden" (14) wird ein entsprechender Button 182 angezeigt. Bei Auslösen des Ereignisses, d.h. bei Anklicken des Buttons, wird die Methode „show()" aufgerufen, um die speziellen Rechnungen für den per Tick 184 ausgewählten Kunden anzuzeigen. Dabei wird entsprechend der Dialog-Parameter-Definitionen des Dialogs RechAnz 172 der Name des Kunden, der Monat und der Betrag der Rechnung ausgegeben. In der Methode „show()" wird dazu zunächst der ausgewählte Kunde geladen. Dies erfolgt per
Kunde.index=index

Anschließend wird der relationsbasierte Finder „findFromKunde()" aufgerufen.

Die entsprechende Entwicklungsdatei hat in XML eine Form, in welcher das Entwicklungsergebnis gespeichert werden kann. Ein Beispiel für eine Entwicklungsdatei ist in 18a bis c dargestellt.

Die mit 203 bis 265 bezeichneten Zeilen, repräsentieren die Entitäten und Objekte der Fachlogik. Die Zeilen 240 bis 244 repräsentieren z. B. die Entität „Kunde" 152. Die Zeilen 240 – 244 repräsentieren z. B. den Zeiger der Entität Kunde 152 auf die Tabelle KUNDE 142. Die Zeile 243 repräsentiert z. B. den Finder findall 156 der Entität Kunde 152. Die Zeilen 212 – 216 repräsentieren z. B. das Objekt Wasser 62. Die Zeilen 214 – 215 repräsentieren z. B. die Attribute des Objektes Wasser 62. Die Zeilen 222 – 239 repräsentieren z. B. das Objekt Rechnung 162. Die Zeilen 226 – 239 repräsentieren z. B. die Methode des Objektes Rechnung 162. Die Zeilen 266 – 286 repräsentieren die Accesses der Fachlogik. Die Zeilen 278 – 280 repräsentieren z. B. den Access Rechng-Kunde 145. Die Zeilen 289 – 311 repräsentieren die Dialoge der Ablaufsteuerung. Die Zeilen 298 – 302 repräsentieren z. B. den Dialog Preise 96. Die Zeile 299 repräsentieren z. B. den Input-Dialog-Parameter gpreis des Dialog Preise 96. Die Zeile 291 repräsentieren z. B. den Output-Dialog-Parameter betrag des Dialog Rechnung 100. Die Zeilen 313 – 319 repräsentieren die Ereignisse (Events) der Ablaufsteuerung. Die Zeile 314 repräsentiert z. B. das Ereignis Verbrauch-Rechnung 120. Die Zeilen 323 – 329 repräsentieren die Tabellen der Datenhaltung. Die Zeilen 327 – 329 repräsentieren z. B. die Tabelle KUNDE 142. Die Zeile 328 repräsentiert z. B. die Spalte "name" der Tabelle KUNDE 142. Die Zeilen 330 – 332 repräsentieren die Relationen der Datenhaltung. Die Zeilen 330 – 332 repräsentieren z. B. die Relation RECHNG-KUNDE 148.

Die gezeigten Dialoge und Fenster der fertigen Anwendung arbeiten mit einem Standard Layout. Zur Erstellung der individuellen Layoutkomponente werden Zeilenorientierte Präsentationsschnittstellen, z.B. HTML, sowie eine Pixel-orientierte Schnittstelle, z.B. Delphi vorgesehen.

Dem Programmierer wird zu jedem Dialog die Möglichkeit gegeben, globale Einstellungen vorzunehmen. So können Bilder und Texte verschiedener Schrifttypen vor ausgewählten Hintergründen platziert werden. Auf die in der Ablaufsteuerung definierten Dialogparameter und Ereignisse kann zugegriffen werden, um sie in der fertigen Anwendung darzustellen.

Wenn die Anwendung als Batch oder Dienst ohne UserInterface realisiert wird, wird die Layoutkomponente 18 des Designerprogramms 12 ersetzt durch die Interface-Definitionen.

Neben der Zustandsmaschine, die zur Ausführung der Anwendung die Entwicklungsdatei interpretiert, ist eine Konfigurationsmaschine vorgesehen. Die Konfigurationsmaschine liest ebenfalls die Entwicklungsdatei. Weiterhin dient sie zum Importieren und Exportieren von Daten in und aus Fremdsystemen, zum Ändern von Default-Werten und anderen Laufzeiteinstellungen.

Claims

Vorrichtung zum Erstellen ausführbarer Programme enthaltend (a) eine Benutzeroberfläche zur Eingabe eines einem Programm zugrunde liegenden Models, (b) einen Generator zur Erzeugung von individuellem Programmcode aus dem Modell, (c) eine Zustandsmaschine zur Ausführung des auf dem Programmcode basierenden Programms, und (d) vordefinierten Programmcode in Form von wenigstens einer Basisklasse oder sonstigen vordefinierten Code zur Bereitstellung von wiederkehrenden Algorithmen, dadurch gekennzeichnet, dass (e) die Benutzungsoberfläche derart ausgebildet ist, dass die Eingabe ausführbarer Befehle zumindest teilweise in graphischer Form erfolgt, (f) Teile des vordefinierten Programmcodes für die Zustandsmaschine als Einsprung in den Programmcode dienen, (g) das dem Programm zugrunde liegende Modell graphische Symbole enthält, die instanziierte Klasse repräsentieren, und (h) das dem Programm zugrunde liegende Modell graphische Symbole enthält, durch welche die Zustandsmaschine unmittelbare Schnittstellen zwischen Instanzen und Programmnutzern realisiert.
Eine Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass das dem Programm zugrunde liegende Modell zusätzlich graphische Symbole enthält, welche die Zustände und Zustandsübergänge der Zustandsmaschine repräsentieren.
Eine Vorrichtung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass über die graphische Oberfläche am jeweiligen Zustand eine unmittelbare Zuordnung zwischen den Eingabe/Ausgabe Daten eines Programmnutzers und den Attributen der instanziierten Klassen definierbar ist.
Eine Vorrichtung nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass über die graphische Oberfläche am Zustandsübergang eine unmittelbare Zuordnung von den Ereignissen, welche ein Programmnutzer auslösen kann, zu den Methoden der instanziierten Klassen, welche beim Zustandsübergang ausgeführt werden sollen, definierbar ist.
Vorrichtung nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass Speichermittel zum persistenten Speichern von Daten vorgesehen sind und die instanziierten Klassen Mittel zum persistenten Zugriff auf diese Daten umfassen.
Vorrichtung nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass Mittel zur graphischen Gestaltung der Oberfläche des erstellten Programms vorgesehen sind.
Vorrichtung nach Anspruch 6, dadurch gekennzeichnet, dass die Mittel zur graphischen Gestaltung Eingabemittel umfassen, mittels welcher Präsentationselemente der graphischen Gestaltung graphisch eingebbar sind.
Vorrichtung nach einem der vorgehenden Ansprüche, gekennzeichnet, durch Mittel zum Speichern des dem Programm zugrundeliegenden Modells in einer zusammenhängenden Struktur, insbesondere in einer einzigen Datei.
Vorrichtung nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass die persistenten Daten verknüpft sind, und das Modell graphische Symbole umfasst, welche die Verknüpfungen repräsentieren.
Verfahren zum Erstellen ausführbarer Programme mit den Schritten (a) Erstellen einer Graphik, welche ein einem Programm zugrundeliegendes Modell repräsentiert durch Eingabe ausführbarer Befehle zumindest teilweise in graphischer Form, (b) Erzeugen von individuellem Programmcode aus dem Modell, (c) Ausführen des auf dem Programmcode basierenden Programms mit einer Zustandmaschine und (d) Ausführen vordefinierten Programmcodes in Form von wenigstens einer Basisklasse oder sonstigen vordefiniertem Code zur Bereitstellung von wiederkehrenden Algorithmen, (e) Einspringen in den vordefinierten Programmcode über eine Zustandsmaschine, (f) Bilden von instanziierten Klassen mittels der graphischen Symbole, und (g) Eingeben von graphischen Symbolen zur Realisierung von unmittelbaren Schnittstellen zwischen Instanzen und Programmnutzern.