Document

Kapitel 9
Prototyp
9.1
Überblick
Für eine Überprüfung der Funktionsweise und der Umsetzbarkeit der entwickelten Konzepte wurde ein Prototyp implementiert: Das Benutzersystem wurde in der Skriptsprache Tcl/Tk und das
Verarbeitungssystem in der objektorientierten Programmiersprache C++ programmiert. Durch
die Verwendung dieser Werkzeuge wird eine plattformunabhängige Einsetzbarkeit der Software
erreicht, da diese Sprachen für nahezu alle Betriebssysteme, wie UNIX und Microsoft Windows95, verfügbar sind. Für die persistente Speicherung der Daten, die z.B. bei der Ausführung
eines insert Befehls erzeugt werden, wird das Datenbanksystem INGRES PD V8.9 verwendet,
das auf dem Internet frei verfügbar ist. Dieses System verfügt über C-basierte Schnittstellen, die
für die Kommunikation zwischen dem Prototypen und dem Datenbanksystem benutzt werden.
Um das Laufzeitverhalten der Software beurteilen zu können, wurde ein Test-Szenario entwickelt,
das auf mehreren Transaktionen und zahlreichen Regeln basiert. Die Testergebnisse zeigen, dass
der Prototyp eine akzeptable Performance aufweist.
Bevor nun auf den Entwurf, die Implementierung und das Laufzeitverhalten näher eingegangen
wird, sollen einige Anforderungen erläutert werden, die an den Prototypen gestellt wurden.
9.2
Anforderungen
Mit der Entwicklung des Prototypen wurde das Ziel verfolgt, die theoretisch erarbeiteten Konzepte auf ihre Umsetzbarkeit in eine Software zu überprüfen. Daher sind für den Prototypen in
Form von zahlreichen Anforderungen die Leistungsmerkmale festgelegt worden, die das SoftwareSystem zu erfüllen hat. Eine der vorrangigen Anforderungen bestand darin, dass sich der Prototyp plattformunabhängig, also auf verschiedenen Betriebssystemen, installieren und einsetzen
lässt. Diese Forderung resultiert aus der Anforderung nach der Unternehmens- und Branchenunabhängigkeit1 , die an den Entwurf der Konzepte gestellt wurde.
Die restlichen Anforderungen lassen sich in zwei Klassen gliedern: Anforderungen an das Benutzersystem und Anforderungen an das Verarbeitungssystem. In den folgenden Abschnitten werden
einige dieser Kriterien näher erläutert.
1
vgl. Abschnitt 4.1.
318
KAPITEL 9. PROTOTYP
9.2.1
Benutzersystem
Eine wichtige Anforderung, die die Entwicklung der Konzepte besonders beeinflusst hat, bestand darin, dass ALFRED auf prinzipiell jedes (passive) Datenbanksystem aufgesetzt werden kann. Diese Eigenschaft wird dadurch erfüllt, dass eine erweiterte Schichten-Architektur2
gewählt wurde, die sich aus einem Benutzersystem und einem Verarbeitungssystem zusammensetzt. Das Benutzersystem besteht aus mehreren Benutzerschnittstellen, über die der Zugang
zum System erfolgt. Jede dieser Schnittstellen basiert auf einem Menüsystem, das graphikorientiert und auf der Fenstertechnik zu realisieren ist, wenn es den heutigen Anforderungen an
ein modernes Front-End entsprechen soll. Der Entwurf und die Implementierung einer solchen
Benutzeroberfläche erfordern die Beachtung einer Reihe von wichtigen Richtlinien, damit eine
hohe Benutzungsfreundlichkeit, -akzeptanz sowie eine effiziente Interaktion zwischen Benutzer
und System gewährleistet sind. Einige Beispiele dafür sind ([Shn87], S. 60ff.):
• Konsistenz
In Menüs, Eingabeaufforderungen und Hilfesystemen sollten gleiche Terminologien verwendet werden. Zusätzlich muss sichergestellt sein, dass bei der Ausführung von ähnlichen
Aktionsfolgen auch ähnliche Situationen erreicht werden, in denen in Abhängigkeit der
Aktionsfolgen, bspw. mit der Ausgabe von Meldungen, reagiert wird.
• Informatives Feedback
Für jeden auszuführenden Befehl sollte das System Status- und Ergebnismeldungen ausgeben. Aus diesen Mitteilungen kann der Benutzer ersehen, ob seine Befehle verarbeitet
werden, und ob die Ausführung erfolgreich beendet oder aufgrund von Fehlern abgebrochen
wurde. Bei Befehlssequenzen, die eine lange Verarbeitungszeit erfordern, ist es zusätzlich
hilfreich, wenn das System Zwischenmeldungen generiert und ausgibt.
• Fehlerbehandlung
Die Benutzeroberfläche sollte so konzipiert sein, dass der Benutzer keine (schwerwiegenden) Fehler machen kann. Da i. allg. Fehler auftreten, sollte das System diese erkennen
und eine möglichst einfache Fehlerbehandlung anbieten, in der z.B. der Benutzer seine Eingaben überarbeiten kann. Zusätzlich sollte sichergestellt sein, dass fehlerhafte Befehle zu
keinem Zustandswechsel innerhalb des Systems führen. Falls doch, müssen entsprechende
Recovery-Massnahmen durchgeführt werden.
• Recovery
Die Benutzeroberfläche sollte eine Funktionalität unterstützen, mit der Befehle und Befehlssequenzen zurücksetzbar sind. Damit wird dem Benutzer die Angst genommen, mit
dem System zu arbeiten.
• Benutzergesteuerter Dialog
Der Benutzer und das System sollten häufig miteinander kommunizieren. Dies kann aber
durch unerwartete Systemreaktionen, lange Dateneingabesequenzen, Schwierigkeiten beim
Aufruf von Funktionen oder bei der Auslösung gewünschter Aktionen beeinträchtigt werden. Solche Eigenschaften sind beim Entwurf von Benutzeroberflächen zu vermeiden.
Neben diesen Richtlinien gibt es auch noch solche Anforderungen zu berücksichtigen, die sich
auf die zu unterstützenden Funktionalitäten des Menüsystems beziehen:
2
vgl. Kapitel 5.
9.2. ANFORDERUNGEN
319
• Datenbanken
Der Systemadministrator muss in dem zugrundeliegenden Datenbanksystem Datenbanken
erzeugen und verwalten können. Zusätzlich muss es das Menüsystem zulassen, dass sich
der Benutzer für die Bearbeitung seiner Aufgaben an einer Datenbank anmelden kann.
• Datendefinitionen
Für den Systemadministrator müssen Befehle zur Verfügung stehen, mit denen sich (neue)
Benutzer einrichten und verwalten lassen. Diese Forderung beinhaltet auch, dass Privilegien und Zugriffsrechte auf die in einer Datenbank existierenden Elemente, wie Objekttypen und Datenbankprozeduren, vergeben bzw. entzogen werden. Für die Realisierung von
konzeptionellen Datenmodellen müssen Befehle verfügbar sein, mit denen sich Entitätstypen und Beziehungstypen implementieren lassen. Ferner müssen Funktionalitäten zur
Verfügung stehen, mit denen Programme, Datenbankprozeduren und Regeln definiert und
verwaltet werden können.
• Datenmanipulationen
Für einen Zugriff auf die in einer Datenbank gespeicherten Daten müssen Befehle, wie
select, insert, update und delete, unterstützt werden.
• Administration
Die Administration von Benutzern und Datenbankobjekten erfordert die Berücksichtigung
gewisser Abhängigkeiten. So müssen z.B. beim Löschen eines Objekttypen die Zugriffsrechte der Benutzer aktualisiert, Regeln, die bezüglich dieses Typen definiert sind, entfernt
und Regeln, die in ihren Aktionskomponenten darauf zugreifen, manipuliert werden. Das
Menüsystem sollte daher Funktionalitäten beinhalten, mit denen der Systemadministrator
bei solchen Aufgaben unterstützt und beim Auftreten von Problemen informiert wird.
• Simulationen
Für eine Überprüfung des im System definierten aktiven Verhaltens muss das Menüsystem die Definition und Ausführung von Simulationen zulassen. So sollte es möglich sein,
Situationen und Zustände zu spezifizieren, von denen aus eine Simulation gestartet wird.
Die Ausführung darf aber zu keinem Zustandswechsel in einer Datenbank führen. Für eine
Überprüfung des definierten Verhaltens sind bei der Verarbeitung einer Simulation verschiedene Daten zu protokollieren (, z.B. welche Befehle ausgeführt wurden, wann und
welche Regeln verarbeitet wurden und auf welche Objekttypen zugegriffen wurde). Die
Auswertung der Daten sollte graphisch erfolgen und mehrere Stufen der Detailliertheit
unterstützen.
• Hilfesystem
Zur Unterstützung des Benutzers ist es wichtig, ein Hilfesystem zu integrieren, über das
z.B. beim Problem der Befehlsspezifikation hilfreiche Informationen abgefragt werden
können. Zudem sollte sich dieses System beim Erkennen von Fehlern automatisch aktivieren und detaillierte Meldungen zur Korrektur ausgeben. In gewissen Situationen ist es
nützlich, wenn das System mehrere Alternativen anbietet, aus denen der Benutzer eine
auswählen kann.
Für die Definition eines reaktiven Verhaltens muss die entwickelte ARDL3 realisiert werden. Da
durch einen ersten Prototypen vor allem die erarbeiteten Konzepte für die korrekte Ausführung
von Befehlen, Transaktionen und Regeln überprüft werden sollen, ist es nicht erforderlich, dass
die gesamte Regelsprache umgesetzt wird. Es wurde daher festgelegt, welche Regeltypen definiert
werden können und verarbeitet werden müssen:
3
vgl. Kapitel 6.
320
KAPITEL 9. PROTOTYP
• Strukturen
Im System müssen Regeln mit einer EA-, ECA- oder ECAA-Struktur definiert werden
können.
• Inhalte
Die Definition einer Regel beinhaltet u.a. die Spezifikation der Komponenteninhalte. Vom
System müssen die folgenden Ereignisse, Bedingungen und Aktionen unterstützen werden:
– Ereignisse
Die Ereigniskomponenten sind primitiv und basieren auf Datenmanipulations-Ereignissen, Transaktions-Ereignissen oder abstrakten Ereignissen.
– Bedingungen
Die Bedingungskomponenten sind primitiv und basieren auf TRUE, FALSE oder Prädikaten.
– Aktionen
Die Reaktion auf eine erkannte Situation besteht in der Verarbeitung einer primitiven
oder komplexen Aktion, die auf einer Sequenz von primitiven Aktionen basiert.
• Semantiken
Im System müssen Regeln mit folgenden Semantiken definiert und verarbeitet werden
können:
– Auslösungszeitpunkte pre und post
– Granularitäten instance und set
– Prioritäten
– Kopplungsmodus immediate
9.2.2
Verarbeitungssystem
Die an das Verarbeitungssystem gestellten Anforderungen lassen sich so zusammenfassen, dass
die im Menüsystem spezifizierten Befehle und Transaktionen unter Berücksichtigung der dabei
ausgelösten Regeln im Verarbeitungssystem semantisch korrekt ausgeführt werden. Für die Verarbeitung solcher Abläufe ist es aber nicht notwendig, dass alle Subsysteme und Module, wie
das Regelanalysesystem4 , realisiert werden. Bei den zu implementierenden Modulen handelt es
sich um:
• Modul ’AFPN Generation’
Dieses Modul erzeugt für jeden vom Benutzer eingegebenen Befehl ein Petri-Netz (AFPN),
das die Grundlage für die Verarbeitung darstellt.
• Modul ’Primitive Event Detection’ (PED)
Der ’PED’ hat die Aufgabe, das vom Modul ’AFPN Generation’ erzeugte Netzwerk auf
primitive Ereignisse zu überprüfen. Falls dabei Ereignisse erkannt werden, ist das PetriNetz gegebenenfalls um Plätze und Transitionen zu erweitern, damit eine Verknüpfung
mit dem Ereignissystem5 aufgebaut werden kann.
4
5
vgl. Abschnitt 5.3.3.
vgl. Abschnitt 7.5.5.
9.3. ENTWURF
321
• Modul ’Complex Event Detection’ (CED)
Dieses Modul ist für die Erkennung von Ereignissen verantwortlich und überprüft, ob durch
ein signalisiertes Ereignis Regeln ausgelöst werden.
• Modul ’Net Processing’ (NP)
Die Verarbeitung des Netzwerks, in dem der benutzerdefinierte Befehl und die ausgelösten
Regeln dargestellt sind, ist Aufgabe dieses Moduls.
• Modul ’ARFPN Generation’
Die ausgelösten Regeln werden durch dieses Modul instanziiert und entsprechend der definierten Semantiken in das zu verarbeitende Petri-Netz integriert. Zusätzlich entfernt die
’ARFPN Generation’ aus dem Netz die instance-basierten Regeln nach ihrer Ausführung.
• Modul ’Transaction Management’ (TM)
Dieses Modul hat die Aufgabe, Transaktionen zu erzeugen und zu verwalten sowie die
(tatsächliche) Ausführung von Befehlen und Regeln zu koordinieren.
• Modul ’Transaction Execution’ (TE)
Befehle, die im zugrundeliegenden Datenbanksystem verarbeitet werden müssen, werden
von diesem Modul entsprechend transformiert und an das System übergeben.
• Subsystem ’Repository’
Das ’Repository’ speichert Informationen über die im System definierten Datenbankelemente und Regeln. Diese Daten werden von der ’AFPN Generation’ u.a. zur Erzeugung
eines repräsentativen Petri-Netzes verwendet.
Auf die Implementierung von weiteren Modulen, wie dem Modul ’Lock Management’ (LM), das
Sperren für Objekttypen und Datensätze erzeugt und verwaltet, kann verzichtet werden, da der
Prototyp für einen ’single user’-, ’single tasking’-Betrieb realisiert wird.
9.3
Entwurf
Die Implementierung eines Prototypen mit dem oben erläuterten Anforderungsprofil erfordert,
dass Konzepte erarbeitet werden, auf deren Basis das Benutzersystem und das Verarbeitungssystem programmiert werden können. Die entwickelten Konzepte werden im folgenden genauer
betrachtet.
9.3.1
Benutzersystem
Das Benutzersystem von ALFRED soll den heutigen Anforderungen an ein modernes FrontEnd entsprechen. Daher wurde eine Benutzerschnittstelle entworfen, die graphikorientiert ist
und auf der Fenstertechnik basiert. Aufgrund der zu unterstützenden Funktionalitäten wurde
ein Menü entwickelt, das sich aus sieben Einträgen zusammensetzt:
• Datenbankmenü
Dieses Menü besteht aus Befehlen, mit denen Datenbanken erzeugt und gelöscht werden
können. Zusätzlich beinhaltet es Befehle, mit denen sich der Benutzer an einer Datenbank
an- und abmelden kann.
322
KAPITEL 9. PROTOTYP
• Datendefinitionsmenü
Das Datendefinitionsmenü setzt sich aus Befehlen zusammen, mit denen Objekttypen,
Sichten, Regeln, Regelmengen, Datenbankprozeduren, Programme und Benutzer erzeugt,
manipuliert und gelöscht werden können.
• Datenmanipulationsmenü
Dieses Menü enthält Befehle, mit denen auf die Datensätze einer Datenbank zugegriffen
werden kann. Zudem beinhaltet es mehrere Befehle, mit denen sich die Zustände von
Regeln ändern sowie Datenbankprozeduren und Programme aufrufen lassen.
• Transaktionsmenü
Die Befehle, mit denen Transaktionen erzeugt, manipuliert, gelöscht und ausgeführt werden
können, sind in diesem Menü zusammengefasst.
• Simulationsmenü
Dieses Menü enthält Befehle zur Erzeugung und Ausführung von Simulationen.
• Regelinformationsmenü
Das Regelinformationsmenü enthält Befehle zur Abfrage von Informationen aus der existierenden Regelbasis.
• Hilfemenü
Dieses Menü soll den Benutzer bei der Arbeit mit ALFRED unterstützen, indem er sich
z.B. über die Syntax von Befehlen informieren kann.
Um die potentielle Gefahr der fehlerhaften Eingabe zu verringern, sollten die Fenster zur Spezifikation der auszuführenden Befehle Konstrukte aufweisen, aus denen sich einzelne oder mehrere
Einträge auswählen lassen. Ein Beispiel dafür sind systemgenerierte Auswahllisten. Eine Eingabe
über die Tastatur sollte nur dann erfolgen, wenn dies unumgänglich ist.
Für das Menüsystem von ALFRED wurde eine Vielzahl von Fenstern konzipiert, die vor allem
für die Spezifikation von Befehlen, die Ausgabe von Meldungen und die Durchführung von Auswahlentscheidungen verwendet werden. Um dem Benutzer ein einheitliches Aussehen zu bieten,
basiert der Entwurf dieser Fenster auf folgenden Richtlinien:
• Jedes Dialogfenster setzt sich aus einem Eingabe- und einem Aktionsbereich zusammen:
– Eingabebereich
Der Eingabebereich befindet sich links im Fenster und wird vom Benutzer für die
Spezifikation der auszuführenden Befehle verwendet. Dazu werden u.a. Listboxen,
Felder und Schaltflächen benutzt, mit denen weitere Fenster geöffnet werden können.
– Aktionsbereich
Der Aktionsbereich befindet sich rechts im Fenster und enthält bis zu drei Schaltflächen:
∗ Mit Ok werden die eingegebenen Befehle zur Ausführung an das Verarbeitungssystem übergeben. Danach wird das Dialogfenster geschlossen.
∗ Mit Cancel werden die Eingaben des Benutzers verworfen und das Fenster wird
geschlossen. Der Befehl wird nicht verarbeitet.
∗ Die Schaltfläche Apply weist im Vergleich zu Ok eine erweiterte Funktionalität auf.
Nach der Übergabe des Befehls an das Verarbeitungssystem werden die Eingaben
des Benutzers aus dem Fenster entfernt, damit sich ein neuer Befehl dieses Typs
spezifizieren lässt.
9.3. ENTWURF
323
• Einige Befehle sind so komplex, dass ihre Spezifikation auf mehrere Fenster verteilt wurde.
Dabei wurde besonders darauf geachtet, dass logisch zusammenhängende Befehlsteile in
einem Fenster dargestellt sind. Über Schaltflächen, die im Eingabebereich positioniert sind,
werden die anderen Fenster geöffnet.
• In bestimmten Situationen ist die Ausführung gewisser Befehle nicht sinnvoll und wird
daher vom System auch nicht zugelassen. Solche Befehle sind grau dargestellt.
9.3.2
Verarbeitungssystem
Das Verarbeitungssystem stellt den eigentlichen Kern des Prototypen dar, da hier sowohl die
vom Benutzer spezifizierten Befehle als auch die ausgelösten Regeln unter Berücksichtigung
der Semantiken ausgeführt werden. Die Implementierung dieses Teilsystems erfordert daher die
Verwendung einer geeigneten Entwurfsmethode. Der Auswahl einer solchen Methode ist eine
entscheidende Bedeutung zuzuweisen, da sie sowohl ein Vorgehen definiert als auch eine Notation
bereitstellt. Dabei sollte
• das Vorgehen möglichst flexibel und
• die Notation einfach, gut verständlich und durch eine hohe Ausdruckskraft gekennzeichnet
sein, damit sich komplexe Zusammenhänge korrekt und vollständig beschreiben lassen.
Zwei wichtige Entwurfstypen sind das strukturierte Design (SD) und das objektorientierte Design
(OOD), die Booch wie folgt definiert ([Boo94], S. 608, 614):
Definition 9.1 (Strukturiertes Design)
Eine Designmethode, die den Prozess der algorithmischen Zerlegung umfasst. Die algorithmische Zerlegung ist ein Prozess der Zerlegung eines Systems in Bestandteile, die jeweils
kleinere Schritte in einem grösseren Prozess repräsentieren. Die Anwendung der strukturierten Design-Methoden führt zu einer Zerlegung, die sich auf den Steuerfluss eines Systems
konzentriert.
Definition 9.2 (Objektorientiertes Design)
Eine Designmethode, die den Prozess der objektorientierten Zerlegung und eine Notation
für die Darstellung der logischen und physikalischen sowie der statischen und dynamischen
Modelle des zu entwickelnden Systems umfasst. Diese Notation verwendet normalerweise
Klassendiagramme, Objektdiagramme, Moduldiagramme und Prozessdiagramme.
Auf der Basis eines Vergleichs wurde entschieden, das Verarbeitungssystem von ALFRED objektorientiert zu entwerfen, da mit einer solchen Zerlegungsart laut Booch mehrere signifikante
Vorteile verbunden sind:
”Die objektorientierte Zerlegung schafft durch die Wiederverwendung gemeinsamer
Mechanismen kleinere Systeme, wodurch erhebliche Einsparungen bezüglich der verwendeten Ausdrucksmittel erzielt werden. Objektorientierte Systeme sind außerdem
leichter zu ändern und können dadurch einfacher weiterentwickelt werden, da ihr
Entwurf auf stabilen Zwischenformen beruht. Tatsächlich reduziert die objektorientierte Zerlegung das Risiko bei der Erstellung komplexer Software-Systeme erheblich,
324
KAPITEL 9. PROTOTYP
weil diese dahingehend entworfen werden, daß sie sich inkrementell aus kleineren
Systemen weiterentwickeln. Darüber hinaus zielt die objektorientierte Zerlegung direkt auf die inhärente Komplexität ab, indem sie hilft, intelligente Entscheidungen
hinsichtlich der Aufteilung von Problemen, die bei umfangreichen Arbeitskonditionen
gegeben sind, zu treffen.” ([Boo94], S. 34).
Für ein objektorientiertes Design werden in der Literatur mehrere Methoden vorgeschlagen.
Beispiele dafür sind OMT ([Rum91]), Catalysis ([DW98]), Fusion ([CB94]) und die Methode
von Booch ([Boo94]). Ein Vergleich dieser Ansätze hat gezeigt, dass die Methode von Booch
geeignet ist, da das Schwergewicht auf den Entwurf gelegt wird. Zudem ist dieser Ansatz durch
eine hohe Praxisorientiertheit gekennzeichnet und leicht verständlich.
Das entwickelte objektorientierte Modell des Verarbeitungssystems besteht aus einer Vielzahl
von Klassen, mit denen die zu implementierenden Module repräsentiert sind. Zur Erläuterung
wird die Modellierung der einzelnen Module nun genauer betrachtet. Eine ausführlichere Beschreibung wird in [Blu99] gegeben:
• Modul ’AFPN Generation’
Dieses Modul wird durch die Klasse afpn repräsentiert. Eine wichtige Methode dieser
Klasse ist run(), die für einen zu verarbeitenden Befehl ein repräsentatives Petri-Netz
erzeugt. Der Algorithmus dieser Methode lässt sich wie folgt beschreiben:
Begin net with a place and a BEG_ARFPN-transition
If it’s ‘‘execute transaction’’
Load transaction from repository
Append a place and a BOT-transition
For each command
Append a place and a P_BOT-transition
Append a place and the command-transition
Append a place and a P_EOT-transition
End for
Append a place and a EOT-transition
Append a CHOICE-place
Append a AOT-transition on TRUE-branch
Append a COT-transition on FALSE-branch
Else if it’s a simple command
Append a place and a P_BOT-transition
Append a place and the command-transition
Append a place and a P_EOT-transition
Append a CHOICE-place
Append a P_AOT-transition on TRUE-branch
Append a P_COT-transition on FALSE-branch
end if
Append a place and a END_ARFPN-transition
Create a token and put it into the first place
Return pointer to first place as result.
9.3. ENTWURF
325
• Modul ’PED’
Im objektorientierten Modell ist dieses Modul durch eine Klasse repräsentiert, die als ped
bezeichnet wird. Für die Erkennung primitiver Ereignisse beinhaltet diese Klasse die Methode run(). Ist ein Ereignis erkannt worden, wird das Netzwerk gegebenenfalls um eine
Transition und einen Platz erweitert. Zudem wird die ereignissignalisierende Transition
über eine Kante mit dem entsprechenden PEP des Ereignissystems verbunden. Der Algorithmus dieser Methode lautet:
For all transitions in the petri-net
If it’s a transaction-transition
Check for rules triggered by transaction-transitions
Else if it’s a command-transition
Check for rules triggered by command-transitions
End if
If place after transition is a CHOICE-place
Check next transition for true-out-branch
Check next transition for false-out-branch
End if
Goto next transition
End for.
• Module ’NP’ und ’CED’
Diese beiden Module, mit denen die Marken durch die Netzwerke des Ereignissystems und
des zu verarbeitenden Befehls bewegt werden, sind nicht explizit dargestellt. Beim Entwurf
wurde entschieden, die Funktionalitäten dieser Module in die Petri-Netze zu verschieben,
in dem mehrere Klassen von Plätzen und Transitionen entworfen wurden. Da durch die
Konzeption von rekursiven Methoden das Verschieben der Marken sichergestellt ist, bedarf
es keiner weiteren Klassen, die den Fluss der Marken überwachen und steuern.
Für die Modellierung der statischen Struktur und des dynamischen Verhaltens der zu
verarbeitenden Petri-Netze wurden mehrere Klassen und Subklassen entwickelt. Einige
Beispiele dafür sind:
1. Klasse place
Eine Instanz dieser Klasse repräsentiert einen Platz, der versucht, eine Marke an
eine Transition weiterzugeben. Diese Dynamik wird durch den Aufruf der Methode
fire trans() erreicht, die auf folgendem Algorithmus basiert:
For all outgoing transitions
Get the transition
If transition can fire
Return 0
Else
Find next transition
End if
End for
Return 1 if no transition has fired.
Zu dieser Klasse wurden auch noch einige Subklassen entworfen, die ein anderes
Verhalten aufweisen:
326
KAPITEL 9. PROTOTYP
– Klassen passive place und eoe place
Die Plätze dieser beiden Klassen versuchen nicht, eine Marke weiterzusenden,
sondern warten darauf, von einer Transition aufgefordert zu werden.
– Klasse choice place
Diese Klasse repräsentiert die CHOICE Plätze, die eine Marke in Abhängigkeit
eines Wahrheitswertes über eine Kante bewegen. Dieser Wert ist in der Marke
gespeichert.
– Klasse pep place
Diese Subklasse repräsentiert die PEP im Ereignissystem. Diese Plätze geben eine
Marke nur dann an die verbundene Vervielfältigungstransition RT weiter, wenn
die aktuelle Transaktion den Status running hat. Damit ist sichergestellt, dass
keine Regeln mehr verarbeitet werden, wenn die (aktuelle) Transaktion aufgrund
eines Fehlers bereits abgebrochen wurde.
2. Klasse transition
Diese Klasse repräsentiert Transitionen, die nach den bekannten Regeln gefeuert werden. Das Feuern wird durch einen Eingangsplatz initiiert, der versucht, seine Marke
an die Transition zu übergeben. Dadurch wird die Methode fire token() aufgerufen, die bei jedem Eingangsplatz der Transition anfragt, ob er markiert ist. Unter der
Annahme, dass die Transition feuerbar ist, wird von jedem dieser Plätze eine Marke
angefordert, die dem Modul ’TM’ (Klasse tmgr, s.u.) zur Verarbeitung übergeben
wird. Als Ergebnis wird eine neue Marke erzeugt und zurückgegeben, die nun so
oft vervielfältigt wird, wie es Ausgangsplätze gibt. Der Algorithmus dieser Methode
lautet:
Check if every incoming place has a token to deliver
If true
Get a token from every incoming place
Insert token in token-list
Call transaction-manager to process the transition
If the transaction-manager returns a token
For each outgoing place
Create a copy of the token
Send the copy to the outgoing place
End for
Delete the token received from transaction-manager
Return 0 (Firing ok)
Else
Return 1 (couldn’t fire)
End if
End if.
Zu dieser Klasse wurden mehrere Subklassen definiert, die sich zum Teil durch ein
davon abweichendes Verhalten auszeichnen. Zwei Beispiele dafür sind die Klassen
replication trans, mit der die Vervielfältigungstransitionen RT repräsentiert, und
bot trans, mit der die BOT Transitionen beschrieben werden.
3. Klasse token
Die Objekte dieser Klasse stellen die Marken dar, die durch die zu verarbeitenden Petri-Netze bewegt werden. Sie speichern verschiedene Daten, die u.a. für die
Ausführung von Befehlen und Auswertung von Bedingungen benötigt werden. Die
Methoden dieser Klasse erfüllen daher vor allem die Funktion der Wertzuweisung
und die der Aktualisierung von Variablenwerten.
9.3. ENTWURF
327
• Modul ’ARFPN Generation’
Dieses Modul hat die Aufgabe, die ausgelösten Regeln zu instanziieren und in das zu
verarbeitende Netzwerk des Benutzerbefehls zu integrieren. Dazu wird die Regel vom EOE
Platz bis zum EOR Platz kopiert und unter Beachtung der definierten Semantiken eingefügt.
Diese Aufgabe realisiert die Methode run(), die auf folgendem Algorithmus basiert:
Get rule-informations from PEP
For each rule after replication-transition
If EOE-place has a token
Make a copy of the rule
Move token to EOE of the copied rule
End if
End for
Connect rules with priorities and coupling-modes
If granularity is instance
Set the record counter in the last place of all copied rules
For each record
Make a copy of the token of every rule
Fire the first transition of the first rule
End for
Else if granularity is set
Fire the first transition of the first rule
End if.
• Module ’TM’ und ’TE’
Im Transaktionssystem werden die als Transitionen dargestellten Befehle und Bedingungen
verarbeitet. Das objektorientierte Modell umfasst daher einige Klassen, die die Aufgaben
der Module ’TM’ und ’TE’ repräsentieren:
– Klasse tmgr
In dieser Klasse werden die Transaktionen verwaltet und verarbeitet, die für die
Ausführung der benutzerdefinierten Befehle und ausgelösten Regeln unter Verwendung von Listenstrukturen erzeugt werden. Die Verarbeitung erfolgt mit Hilfe mehrerer Methoden. Ein Beispiel dafür ist commit transaction(), mit der die in einer
Transaktion durchgeführten Datenmanipulationen auf Datenbankebene festgeschrieben werden. Der Algorithmus dafür lautet:
For all relations in CURRENT-data
For all records in relation
if record-state is ‘‘deleted’’
delete record from database
else if record-state is ‘‘changed’’
delete record from database
insert record into database
else if record-state is ‘‘inserted’’
insert record into database
end if
End for all records
End for all relations.
328
KAPITEL 9. PROTOTYP
– Klasse transaction
Die Objekte dieser Klasse repräsentieren die Transaktionen, die in der Klasse tmgr
verwaltet werden. Damit in den Transaktionen zu jeder Zeit die aktuellen Attributwerte der Datensätze vorliegen, umfasst die Klasse mehrere wichtige Methoden. Ein
Beispiel dafür ist merge record curr data(), mit der die Datensätze einer übergeordneten Transaktion mit denjenigen einer davon abhängigen Transaktion verschmolzen werden. Der Algorithmus dieser Methode lässt sich wie folgt angeben:
Find concerned relation in CDS
If found
Find corresponding record in this relation
If found
If record is to delete
Set record state to deleted
Else if record is to change
Set new values
Set record state to changed
End if
Set flag: record could be merged
End if
End if
If record could not be merged
Merge the record in ODS
End if.
– Klasse trans rel
In dieser Klasse werden die Datensätze, auf die bei der Verarbeitung einer Transaktion zugegriffen wird, in Form einer Listenstruktur verwaltet. Die Methoden dieser
Klasse ermöglichen es z.B. einen neuen Datensatz in eine Liste einzufügen oder einen
bestimmten Datensatz aus einer Liste zu ermitteln.
– Klasse record
Die Objekte dieser Klasse beschreiben die Datensätze, die durch die Befehle einer
Transaktion selektiert, eingefügt, manipuliert oder gelöscht werden. Insgesamt werden
für jeden Datensatz drei Versionen gespeichert:
∗ RET
Diese Struktur beinhaltet die Attributwerte der Datensätze, die aus einer Datenbank selektiert wurden.
∗ OLD
In dieser Struktur sind die alten Attributwerte der Datensätze gespeichert, auf
die bei der Verarbeitung von update oder delete Befehlen zugegriffen wurde.
∗ NEW
In dieser Struktur sind die neuen (aktuellen) Attributwerte der Datensätze gespeichert, die entweder neu eingefügt oder manipuliert wurden.
Die Methoden dieser Klasse werden verwendet, um Attributwerte zu selektieren und
zu manipulieren.
• Subsystem ’Repository’
Das ’Repository’ setzt sich u.a. aus einem Daten- und einem Regel-Repository zusammen,
die im objektorientierten Modell durch zwei Klassen repräsentiert sind:
9.4. IMPLEMENTIERUNG
329
– Klasse data rep
Das Daten-Repository speichert Informationen über die existierenden Datenbanken
und der darin enthaltenen Elemente, wie Objekttypen, Datenbankprozeduren, Programme, Benutzer, Privilegien und Zugriffsrechte. Für die Verwaltung dieser Daten werden Listenstrukturen verwendet. Die grundlegenden Funktionen, wie Daten
einfügen, manipulieren und suchen, werden durch Methoden realisiert.
– Klasse rule rep
Das Regel-Repository speichert Informationen über die im System definierten Regeln.
Beispiele dafür sind Strukturen, Ereignisse, Bedingungen, Aktionen und Semantiken.
Der Aufbau dieser Klasse ist analog zu der des Daten-Repository. Auch hier erfüllen
die Methoden die grundlegenden Operationen.
Neben diesen Klassen, mit denen die Module repräsentiert sind, beinhaltet das objektorientierte
Modell einige weitere Klassen, die für die Verwaltung und Steuerung der Module benötigt werden.
Zwei Klassen, die es hier besonders zu erläutern gilt, sind subsys und bilist:
• Klasse subsys
Diese Klasse verwaltet die Module des Verarbeitungssystems. Die Instanziierung eines solchen Klassenobjektes bewirkt, dass die Module erzeugt und initialisiert werden. Da alle diese Module einen Zugriff auf das gleiche Objekt haben, ist sichergestellt, dass ein Modul auf
ein anderes zugreifen kann. Eine wichtige Methode dieser Klasse ist execute command(),
mit der die Verarbeitung eines benutzerdefinierten Befehls eingeleitet wird. Der entsprechende Algorithmus lautet:
Write message to log-file: STARTED
Build AFPN by calling afpn.run()
If net exists
Detect primitive events by calling ped.run()
If no error has occured
Fire the token from the first place of the net
Write message to log-file: TERMINATED
Delete net
Else if error
Error-message
End if
Else if no net exists
Error-message
End if.
• Klasse bilist
Diese Klasse repräsentiert den abstrakten Datentyp doppelt verkettete Ringliste. Diese Listenstruktur wird von mehreren anderen Klassen, wie z.B. data rep und tmgr, zur Verwaltung verwendet.
9.4
Implementierung
Für eine Realisierung des Prototypen wurden die entwickelten Entwürfe implementiert. Dazu
wurde für das Benutzersystem eine graphische Benutzeroberfläche auf der Basis der Skriptsprache Tcl/Tk programmiert, die sich dem Benutzer in Form eines Menüsystems präsentiert. Das
330
KAPITEL 9. PROTOTYP
Menüsystem besteht aus mehreren Menüs, die Befehle beinhalten, die logisch zusammenhängen.
Das Verarbeitungssystem wurde in C++ realisiert.
9.4.1
Benutzersystem
Für die prototypische Implementierung des Benutzersystems wurden mehrere Werkzeuge auf
ihre Eignung hin untersucht. Drei Beispiele dafür sind:
• Borland Delphi
Dieses Werkzeug ist eine objektorientierte Erweiterung der Programmiersprache Pascal für
Windows-basierte Systeme. Borland Delphi unterstützt eine Vielzahl von Entwicklungsaktivitäten, die interaktiv genutzt werden können.
• Microsoft Access
Microsoft Access ist ein Windows-basiertes relationales Datenbankmanagementsystem, das
zusätzlich über eine Entwicklungsumgebung verfügt, mit der graphische Benutzeroberflächen realisiert werden können.
• Tcl/Tk
Tcl/Tk (tool command language/toolkit) ist ein Werkzeug, das an der University of Berkeley entwickelt wurde ([Out84]). Tcl ist eine interpretierte Skriptsprache, mit der Applikationen erzeugt werden können. Tk stellt eine Erweiterung zu Tcl dar, das Funktionalitäten zum Erstellen von X-Windows-kompatiblen Benutzeroberflächen beinhaltet. Tcl
und Tk sind als C-Bibliotheken implementiert und sowohl für UNIX- als auch Windowsbasierte Systeme auf dem Internet frei verfügbar (FTP-Sites: ftp.neosoft.com/pub/tcl und
ftp.neosoft.com/pub/tk).
Um entscheiden zu können, welches Werkzeug die gestellten Anforderungen am besten erfüllt,
wurde ein Vergleich durchgeführt. Dabei hat sich gezeigt, dass Tcl/Tk der Vorzug zu geben ist, da
dieses Werkzeug als einziges die Anforderung nach der Plattformunabhängigkeit erfüllt. Gestützt
wird diese Entscheidung auch dadurch, dass diese Skriptsprache Schnittstellen zu C und C++
enthält. So besteht die Möglichkeit, das objektorientierte Modell des Verarbeitungssystems in
C++ zu programmieren und mit der graphischen Oberfläche zu kombinieren.
Für die Erstellung der graphischen Benutzeroberfläche wurde das Werkzeug Xf verwendet, das
an der Technischen Universität Berlin entwickelt wurde. Mit Xf lassen sich Tcl/Tk-basierte
Applikationen interaktiv konstruieren und testen. Auch dieses Werkzeug ist auf dem Internet frei
verfügbar (FTP-Site: ftp.neosoft.com/pub/tcl). Für die Implementierung des Benutzersystems
wurden somit die folgenden Werkzeuge benutzt: Tcl V8.0, Tk V8.0 und Xf V3.1.
Um einen Eindruck der graphischen Benutzeroberfläche und der damit verbundenen Arbeitsweise
zu vermitteln, werden im folgenden das Datenbank-, Datendefinitions- und Datenmanipulationsmenü näher betrachtet.
9.4.1.1
Datenbankmenü
Das System wird gestartet durch den Befehl alfred. Auf dem Bildschirm erscheinen die graphische Benutzeroberfläche und das Fenster Log on, über das sich der Benutzer anmeldet (vgl. Abb.
9.1). Dazu wählt er aus der Liste der Benutzer, die das System anhand der im ’Repository’ gespeicherten Informationen selbständig erzeugt, einen Eintrag aus und gibt zusätzlich ein Kennwort
9.4. IMPLEMENTIERUNG
331
ein. Mit dem Klicken auf die Schaltfläche Ok überprüft das System die Zugangsberechtigung und
aktiviert den Menüpunkt Data base, wenn die Eingaben korrekt sind. Das Datenbankmenü beinhaltet insgesamt fünf Einträge, von denen sich vier auf Datenbanken beziehen (vgl. Abb. 9.2).
Neben Quit, mit dem das Programm beendet wird, besteht dieses Menü aus:
• Create
Über diesen Eintrag wird ein Fenster geöffnet, in dem der Befehl create data base spezifiziert wird. Mit diesem Befehl erzeugt der Systemadministrator eine neue Datenbank.
• Connect
Das Klicken auf diesen Eintrag öffnet ein Fenster, über das ein connect data base Befehl
spezifiziert wird. Damit meldet sich der Benutzer an einer Datenbank an (vgl. Abb. 9.3).
• Disconnect
Für die Abmeldung von einer Datenbank klickt der Benutzer auf diesen Eintrag.
• Destroy
Mit destroy wird ein Fenster geöffnet, mit dem der Systemadministrator eine Datenbank
löschen kann.
Um sich an einer Datenbank anmelden zu können, muss folglich auf Connect geklickt werden,
wodurch jenes Fenster geöffnet wird, das die Abbildung 9.3 zeigt. Für die Verarbeitung eines
solchen Befehls sind insgesamt drei Eingaben zu spezifizieren:
• Datenbank
In der ersten Liste muss der Name der Datenbank markiert werden, mit der gearbeitet
werden soll.
• Benutzer
Aus der zweiten Liste ist der Name des Benutzers zu selektieren, für den die Datenbank
geöffnet werden soll.
• Kennwort
Im Feld der Klausel with password ist ein Kennwort einzugeben, das für die Überprüfung
der Zugangsberechtigung benötigt wird.
Das Fenster in Abbildung 9.3 zeigt, dass sich der Benutzer admin an der Datenbank kunden db
anmelden möchte. Wird der Befehl erfolgreich ausgeführt, aktiviert das System die restlichen
Menüpunkte.
9.4.1.2
Datendefinitionsmenü
Das Datendefinitionsmenü fasst Befehle zusammen, mit denen u.a. Objekttypen, Sichten, Regeln,
Regelmengen, Datenbankprozeduren und Benutzer definiert werden können (vgl. Abb. 9.4).
Jeder Menüeintrag ist mit einem Pfeil gekennzeichnet, der auf ein Untermenü hinweist.
Im folgenden wird beschrieben, wie ein Objekttyp und eine Regel zu definieren sind. Dazu wird
noch einmal das Beispiel der Auftragsabwicklung6 aufgegriffen:
6
vgl. Abschnitte 2.3.2.1, 2.3.2.2 und Kapitel 8.
332
KAPITEL 9. PROTOTYP
Abbildung 9.1: Fenster Log on
Abbildung 9.2: Datenbankmenü.
Abbildung 9.3: Fenster Connect data base.
9.4. IMPLEMENTIERUNG
333
Abbildung 9.4: Datendefinitionsmenü.
• Objekttyp
Es wird angenommen, dass das konzeptionelle Datenmodell (vgl. Abb. 9.5) bis auf den
Entitätstypen WARE im Prototypen umgesetzt ist. In WARE werden die Artikel zusammengefasst, die von den Kunden bestellt werden können. Dazu umfasst dieser Entitätstyp
mehrere Attribute:
– Im Attribut wnr wird eine laufende Nummer erfasst, über welche die Eindeutigkeit
der Artikel sichergestellt wird.
– Im Attribut bezeichnung werden die Artikelnamen gespeichert.
– Im Attribut farbe werden die Farben der Artikel angegeben.
– Im Attribut groesse werden die Grössen der Artikel erfasst.
– Die Hersteller der Artikel werden im Attribut hersteller gespeichert.
– Die im Lager verfügbaren Bestände werden im Attribut bestand gespeichert.
– Die Preise der Artikel werden im Attribut preis erfasst.
Die Erzeugung dieses Entitätstypen beinhaltet nicht nur die Spezifikation der Attribute, sondern auch die Definition von Integritätsbedingungen und Beziehungen zu anderen
Objekttypen:
– Integritätsbedingungen
Kein Datensatz enthält einen Nullwert. Die Eindeutigkeit der erfassten Artikel ergibt sich aus dem Attribut wnr sowie aus der Attributkombination von bezeichnung,
groesse, farbe und hersteller. Als Primärschlüssel wird das Attribut wnr verwendet. Zudem ist sicherzustellen, dass in den Attributen bestand und preis keine
negativen Zahlenwerte vorkommen.
334
KAPITEL 9. PROTOTYP
MITARBEITER
(1,1)
bearbeitet
(0,n)
KUNDE
(1,1)
erteilt
(1,n)
(1,1)
umfasst
(0,1)
AUFTRAGSABLEHNUNG
umfasst
(1,1)
AUFTRAGSBESTÄTIGUNG
(1,n)
AUFTRAGSLIEFERSCHEIN
(1,1)
AUFTRAGSRECHNUNG
(0,1)
RECHNUNGSERINNERUNG
(0,3)
AUFTRAGSMAHNUNG
(1,1)
BESTELLUNGSBESTÄTIGUNG
(0,n)
BESTELLUNGSREKLAMATION
(1,1)
AUFTRAG
(1,1)
(1,1)
umfasst
(1,1)
umfasst
(1,1)
umfasst
(1,1)
umfasst
beinhaltet
(1,n)
AUFTRAGSARTIKEL
(0,n)
ist
(1,1)
liefert
(1,n)
WARE
(1,1)
ist
(1,n)
BESTELLUNGSARTIKEL
(1,n)
beinhaltet
(1,1)
(1,1)
LIEFERANT
(1,1)
erteilt
(1,n)
BESTELLUNG
(1,1)
umfasst
(1,1)
umfasst
(1,1)
umfasst
(1,1)
BESTELLUNGSRECHNUNG
Abbildung 9.5: Datenmodell der Auftragsabwicklung.
9.4. IMPLEMENTIERUNG
335
– Beziehungen
Der Entitätstyp WARE steht mit drei anderen Typen in Beziehung (vgl. Abb. 9.5). So
existiert z.B. eine (1,1)-(0,n) Beziehung zu AUFTRAGS ARTIKEL, in welchem die von
den Kunden bestellten Artikel gespeichert sind. Des weiteren besteht eine (1,1)-(1,n)
Beziehung zu LIEFERANT, worin die Daten der Lieferanten abgelegt sind. Eine dritte
Beziehung der Art (1,1)-(0,n) existiert zu BESTELLUNGS ARTIKEL, in der die Artikel
gespeichert sind, die bei den Lieferanten bestellt wurden.
Für die Definition des Objekttypen WARE muss im Datendefinitionsmenü der Eintrag
Object type gewählt werden. Es erscheint ein Untermenü, das die Einträge Create, Alter
und Destroy enthält (vgl. Abb. 9.4). Durch Klicken auf den ersten Eintrag öffnet das System das Fenster Create object type (vgl. Abb. 9.6). Dieses Fenster setzt sich aus mehreren
Elementen zusammen:
– Objekttypname
Der Name des Objekttypen wird im Feld der Klausel Create object type spezifiziert. In Abbildung 9.6 enthält dieses Feld den Eintrag WARE.
– Attribute
Für die Definition der Attribute stehen die Schaltflächen add und del zur Verfügung:
∗ Schaltfläche add
Über diese Schaltfläche wird das Fenster Add attributes geöffnet (vgl. Abb. 9.7).
Dieses Fenster besteht u.a. aus zwei Feldern und zwei Listen. Die Attributnamen
können dabei entweder durch das Markieren eines Eintrags in der oberen Liste
oder über die Tastatur eingegeben werden. Der Datentyp des Attributes ist durch
das Auswählen eines Elementes aus der unteren Liste zu definieren.
∗ Schaltfläche del
Wurde bei der Spezifikation irrtümlich ein falsches Attribut definiert, kann dieses
dadurch gelöscht werden, dass in der Attributliste des Fensters Create object type
der entsprechende Eintrag markiert wird. Danach ist auf del zu klicken.
– Integritätsbedingungen
Für die Definition von Integritätsbedingungen muss im Fenster Create object type
auf Integrity constraints geklickt werden. Auf der Benutzeroberfläche erscheint
ein Fenster, das Abbildung 9.8 zeigt. In diesem Fenster lassen sich vier Arten von
Integritätsbedingungen spezifizieren:
∗ Not Null-Integritätsbedingungen
Durch Klicken auf die obere Schaltfläche add wird ein Fenster geöffnet, das die
Attribute des Objekttypen in Form einer Liste anzeigt. Durch Markieren eines
Listenelementes und Klicken auf Ok oder Apply wird für das ausgewählte Attribut
eine Not Null-Integritätsbedingung definiert. Die so spezifizierten Bedingungen
werden in einer Liste im Fenster Integrity constraints gezeigt (vgl. Abb. 9.8).
Wurde für ein Attribut irrtümlicherweise eine solche Integritätsbedingung spezifiziert, kann diese gelöscht werden, wenn das entsprechende Listenelement markiert
und auf del geklickt wird.
∗ Schlüssel-Integritätsbedingungen
Für die Definition dieser Integritätsbedingungen stehen ebenfalls zwei Schaltflächen zur Verfügung. Die Spezifikation erfolgt dabei analog zu den Not NullIntegritätsbedingungen. Der einzige Unterschied besteht darin, dass in der Attributliste mehrere Einträge markiert werden können, die zusammen einen Schlüssel
bilden. Abbildung 9.8 zeigt, dass für WARE zwei Schlüssel definiert wurden, wobei
K-IC2 auf vier Attributen basiert.
336
KAPITEL 9. PROTOTYP
Abbildung 9.6: Fenster Create object type.
Abbildung 9.7: Fenster Add attributes.
9.4. IMPLEMENTIERUNG
337
Abbildung 9.8: Fenster Integrity constraints.
∗ Primärschlüssel-Integritätsbedingungen
Für die Festlegung eines Primärschlüssels ist auf die Schaltfläche select zu
klicken. So wird ein Fenster geöffnet, das die zuvor definierten Schlüssel in einer Liste anzeigt. Durch Markieren eines Eintrags und Klicken auf Ok wird für
den ausgewählten Schlüssel eine Primärschlüssel-Integritätsbedingung definiert,
die im Fenster Integrity constraints angezeigt wird (vgl. Abb. 9.8).
∗ Benutzerdefinierte Integritätsbedingungen
Benutzerdefinierte Integritätsbedingungen werden in dem Fenster User defined
IC spezifiziert, das über die untere Schaltfläche add geöffnet wird (vgl. Abb.
9.9). Da diese Bedingungen auf Prädikaten basieren, umfasst das Fenster einige
Listen, in denen die Attribute des Objekttypen, vier arithmetische und sechs Vergleichsoperatoren angegeben sind. Durch Markieren eines Listenelementes wird
dieses in das darüberliegende Feld eingefügt. Nach der Definition werden diese
Bedingungen im Fenster Integrity constraints angezeigt (vgl. Abb. 9.8).
In ALFRED werden die Integritätsbedingungen durch Regeln repräsentiert, die das
System automatisch erzeugt. Dieser Mechanismus wurde in der hier beschriebenen
ersten Version des Prototpyen nicht realisiert.
– Beziehungstypen
Für die Spezifikation von Beziehungen muss im Fenster Create object type auf die
Schaltfläche Relationships geklickt werden, wodurch ein gleichnamiges Fenster geöffnet wird (vgl. Abb. 9.10). Über add wird das Fenster Add relationships geöffnet, in
338
KAPITEL 9. PROTOTYP
Abbildung 9.9: Fenster User defined IC.
welchem die Beziehungen des definierten Objekttypen zu anderen Typen spezifiziert
werden:
∗ In der Klausel Relationship ist der Name der Beziehung einzugeben.
∗ In der Klausel in relation to wird der Objekttyp spezifiziert, zu dem eine Beziehung hergestellt werden soll. Dazu ist aus der Liste der entsprechende Eintrag
zu markieren.
∗ Die Kardinalitäten der Beziehung werden durch Klicken auf die entsprechenden
Radiobuttons eingegeben.
∗ Zuletzt ist festzulegen, wie reagiert werden soll, wenn die spezifizierte Beziehung verletzt wird. Dazu stehen insgesamt vier Reaktionsarten zur Verfügung,
die ebenfalls als Radiobuttons dargestellt sind.
Abbildung 9.11 zeigt, wie eine (1,1)-(0,n) Beziehung zwischen den Objekttypen WARE
und AUF ARTIL (AUFTRAGS ARTIKEL) spezifiziert wird. Als Reaktionsart wurde restrict gewählt, wodurch die verletzenden Befehle abgebrochen und zurückgesetzt
werden.
In ALFRED werden die Beziehungen durch Regeln realisiert. Dazu wurde ein Konzept
erarbeitet ([Blu97]), das aber in diesem Prototypen keine Anwendung findet.
– Regeln
Bei der Definition eines Objekttypen können auch Regeln definiert werden. Zu diesem
Zweck enthält das Fenster Create object type die Schaltfläche Rules.
• Regeln
Nachdem die Erzeugung eines Objekttypen beschrieben worden ist, soll nun die Definition
einer Regel genauer betrachtet werden. Dazu wird angenommen, dass für die Implementierung der Auftragsbearbeitung noch die Regel AB3 zu definieren ist. Zur Erinnerung sei
erwähnt, dass mit dieser Regel eine Neubestellung von Artikeln ausgelöst wird, wenn nach
der Manipulation eines Artikels dessen Bestand den Schwellenwert 100 unterschreitet. Um
den Abteilungsleiter des Lagers darüber zu informieren, wird ihm eine Meldung gesendet.
Die Regel AB3 lässt sich in der ARDL wie folgt definieren:
9.4. IMPLEMENTIERUNG
Abbildung 9.10: Fenster Relationships.
Abbildung 9.11: Fenster Add relationships.
339
340
KAPITEL 9. PROTOTYP
RULE AB3
ON post update WARE instance
IF (:NEW.WARE.bestand < 100)
DO message to AL LAGER (’:NEW.WARE.bezeichnung bestellen.’)
IS active
PRIORITY 0
EC-COUPLING immediate
CA-COUPLING immediate.
Für die Definition dieser Regel kann im Datendefinitionsmenü auf Rule und dann auf
Create geklickt werden, wodurch das Fenster Create rule erscheint (vgl. Abb. 9.12). Der
Eingabebereich dieses Fensters besteht aus zwei Feldern und drei Schaltflächen, über die
andere Fenster geöffnet werden. Im Feld der Klausel Create rule ist der Name der zu
erzeugenden Regel einzugeben. Das andere Feld, das sich im unteren Teil des Fensters
befindet, dient nur der Information, da dort der Name der Datenbank angegeben ist, in
der die Regel definiert wird. Für die Spezifikation der Struktur, der Komponenteninhalte
und der Ausführungssemantiken stehen drei Schaltflächen zur Verfügung:
– Allgemeine Regeldaten
Über die Schaltfläche Rule generalities wird ein Fenster geöffnet (vgl. Abb. 9.13),
über das sich die Regel zu Regelmengen zuordnen lässt. Zusätzlich wird der Zustand
spezifiziert:
∗ Regelmengen
Für die Zuordnung der Regel zu einer Regelmenge ist auf add zu klicken. Es
erscheint ein Fenster, in dem die bereits im System definierten Mengen in Form
einer Liste angezeigt werden. Durch das Markieren eines Listenelementes und
klicken auf Apply oder Ok wird die Regel in eine Menge eingefügt. Der Name der
ausgewählten Regelmenge erscheint dann in der Liste des Fensters Rule generalities. Die Abbildung 9.13 zeigt, dass AB3 der Menge UD-RU zugewiesen ist, in der
die benutzerdefinierten Regeln zusammengefasst sind. Wurde irrtümlicherweise
eine falsche Regelmenge spezifiziert, kann diese Zugehörigkeit durch das Markieren des entsprechenden Listenelementes und Klicken auf del gelöscht werden.
∗ Regelzustand
Der Regel kann entweder ein aktiver oder passiver Zustand zugewiesen werden.
Für AB3 wurde ein aktiver Zustand definiert (vgl. Abb. 9.13).
– Regelstruktur und -inhalte
Die Regelstruktur und auch die Inhalte der Komponenten werden im Fenster Rule
structure definiert, das über die gleichnamige Schaltfläche im Fenster Create rule
geöffnet wird (vgl. Abb. 9.14):
∗ Struktur
Die Regelstruktur legt der Benutzer durch Klicken auf eine der drei Radiobuttons
fest. In Abhängigkeit der gewählten Struktur können gewisse Schaltflächen, über
welche die Spezifikation der Komponenteninhalte erfolgt, inaktiv sein. So ist z.B.
in der Abbildung 9.14 die untere Schaltfläche grau, da für AB3 eine ECA-Struktur
gewählt wurde. In den Feldern, die sich unter den Schaltflächen befinden, werden
die Komponenteninhalte nach ihrer Spezifikation angezeigt.
9.4. IMPLEMENTIERUNG
341
Abbildung 9.12: Fenster Create rule.
Abbildung 9.13: Fenster Rule generalities.
∗ Ereignis
Für die Definition der Ereigniskomponente ist auf die Schaltfläche Rule event
zu klicken. Auf der Benutzeroberfläche erscheint dann das in Abbildung 9.15
gezeigte Fenster. Dieses Fenster hat im Eingabebereich drei Schaltflächen, über
die weitere Fenster zur Spezifikation von sprachlichen, primitiven und komplexen
Ereignissen geöffnet werden. Da die Regel AB3 durch ein DatenmanipulationsEreignis ausgelöst wird, ist auf die mittlere Schaltfläche zu klicken.
Auf der Oberfläche erscheint das Fenster Primitive rule event, in dem die unterstützten Ereignistypen als Schaltflächen dargestellt sind (vgl. Abb. 9.16). Durch
Klicken auf Data manipulation event wird ein Fenster geöffnet, das die Abbildung 9.17 zeigt. Der Eingabebereich dieses Fensters setzt sich aus drei Teilen
zusammen:
· Auslösungszeitpunkte
Im linken Bereich sind die beiden Auslösungszeitpunkte pre und post als
Radiobuttons dargestellt. Da die Überprüfung der Artikelbestände immer
nach einer Manipulation durchgeführt werden muss, ist für AB3 der Zeitpunkt
post markiert worden (vgl. Abb. 9.17).
342
KAPITEL 9. PROTOTYP
Abbildung 9.14: Fenster Rule structure.
Abbildung 9.15: Fenster Rule event.
9.4. IMPLEMENTIERUNG
Abbildung 9.16: Fenster Primitive rule event.
Abbildung 9.17: Fenster Data manipulation events.
343
344
KAPITEL 9. PROTOTYP
· Datenmanipulations-Ereignisse
Im mittleren Bereich sind die vier Datenmanipulations-Ereignisse select,
insert, update und delete dargestellt. Sobald ein Radiobutton markiert ist,
erscheinen in der dazugehörigen Liste die Objekttypen, die in der Datenbank
existieren. Durch das Markieren eines Listenelementes wird für das Ereignis
ein Objekttyp festgelegt.
· Granularitäten
Im rechten Bereich sind die Granularitäten set und instance repräsentiert,
mit denen die Häufigkeit der Regelverarbeitung in Abhängigkeit der involvierten Datensätze festgelegt wird. Für AB3 wurde die Granularität instance
markiert (vgl. Abb. 9.17).
Nachdem das Ereignis spezifiziert und im Fenster Data manipulation events auf
Ok geklickt wurde, erscheint das Ereignis im Feld der Klausel is triggered by
event der Fenster Primitive rule event und Rule structure.
∗ Bedingung
Für die Definition einer Bedingung ist im Fenster Rule structure auf die Schaltfläche Rule condition zu klicken. Das System öffnet ein Fenster, in dem entschieden werden muss, ob eine sprachliche, primitive oder komplexe Bedingung
eingegeben werden soll. Dieses Fenster (vgl. Abb. 9.18) hat den gleichen Aufbau
wie Rule event.
Über die Schaltfläche Primitive condition wird ein Fenster geöffnet, in welchem die unterstützten primitiven Bedingungstypen dargestellt sind (vgl. Abb.
9.19). Da für AB3 ein Prädikat zu spezifizieren ist, muss hier auf Predicate
condition geklickt werden. Das Fenster, das dadurch erscheint, hat den gleichen Aufbau wie User defined IC, das im Zusammenhang mit benutzerdefinierten
Integritätsbedingungen erläutert wurde (vgl. Abb. 9.9).
Sobald die Bedingung eingegeben und bestätigt wurde, wird sie in den Fenstern
Primitive rule condition und Rule structure in der Klausel checks condition
angezeigt.
∗ Aktion
Die Aktionskomponente wird spezifiziert, wenn im Fenster Rule structure auf die
Schaltfläche Rule action geklickt wird. Auf der Oberfläche erscheint dann das
Fenster Rule action (vgl. Abb. 9.20). Auch hier muss sich der Benutzer entscheiden, ob er eine sprachliche, primitive oder komplexe Aktion definieren möchte.
Durch Klicken auf die mittlere Schaltfläche wird ein Fenster geöffnet, das die
primitiven Aktionstypen darstellt (vgl. Abb. 9.21). Da durch die Regel AB3 eine
Nachricht an den Abteilungsleiter des Lagers gesendet werden soll, ist die Schaltfläche Message action zu wählen. Das System öffnet das dazugehörige Fenster
(vgl. Abb. 9.22), in dem der Benutzer, die Wichtigkeit der Nachricht und die
Meldung selbst spezifiziert werden.
– Regelsemantiken
Die Regelsemantiken sind in einem separaten Fenster zusammengefasst, das über die
Schaltfläche Rule semantics im Fenster Create rule aufgerufen wird (vgl. Abb. 9.23).
Der Eingabebereich dieses Fensters besteht aus mehreren Elementen, über die sich
für die Regel eine Priorität und in Abhängigkeit der gewählten Struktur ein oder
mehrere Kopplungmodi definieren lassen:
∗ Priorität
Die Priorität der Regel wird im Feld der Klausel has priority angegeben.
Zulässige Werte sind ganze Zahlen im Bereich von −1000 bis +1000. Der Wert
9.4. IMPLEMENTIERUNG
345
Abbildung 9.18: Fenster Rule condition.
Abbildung 9.19: Fenster Primitive rule condition.
Abbildung 9.20: Fenster Rule action.
346
KAPITEL 9. PROTOTYP
Abbildung 9.21: Fenster Primitive rule action.
Abbildung 9.22: Fenster Message action.
9.4. IMPLEMENTIERUNG
347
Abbildung 9.23: Fenster Rule semantics.
0, der für die Regel AB3 eingegeben wurde, stellt den Standardwert dar.
∗ Kopplungsmodi
In Abhängigkeit der gewählten Regelstruktur sind die entsprechenden Schaltflächen für die Definition der Kopplungen aktiviert. Standardmässig ist für jede
Kopplung der Modus immediate angegeben, so dass die Regel sofort nach der
Auslösung verarbeitet wird. Soll für eine Kopplung ein anderer Modus definiert
werden, ist auf die Schaltfläche Coupling mode zu klicken. Es wird dann ein Fenster geöffnet, in dem die unterstützten Modi in Form einer Liste gezeigt werden
(vgl. Abb. 9.24).
9.4.1.3
Datenmanipulationsmenü
Für die Selektion und Manipulation von Datensätzen ist das Datenmanipulationsmenü zu verwenden (vgl. Abb. 9.25). Dieses Menü beinhaltet Befehle, die sich in drei Gruppen gliedern
lassen:
• Datenmanipulationsbefehle
Dieser erste Bereich besteht aus den vier Befehlen select, insert, update und delete,
mit denen sich Datensätze selektieren und manipulieren lassen.
• Regelbefehle
Dieser Bereich umfasst zwei Befehle, mit denen die Zustände der Regeln geändert werden
können. Mit enable rule wird der Zustand einer passiven Regel auf aktiv gesetzt. Mit
dem zweiten Befehl, disable rule, erhält eine aktive Regel einen passiven Zustand.
348
KAPITEL 9. PROTOTYP
Abbildung 9.24: Fenster Coupling modes.
• Prozedur- und Programmbefehle
Der dritte Teil des Menüs setzt sich aus Befehlen zusammen, mit denen Datenbankprozeduren und Programme ausgeführt werden.
Um zu veranschaulichen, wie Datensätze aus einer Datenbank selektiert und dem Benutzer
angezeigt werden, wird im folgenden angenommen, dass ein Benutzer wissen möchte, welche
Artikel in WARE gespeichert sind. Dazu klickt er im Datenmanipulationsmenü auf den Eintrag
select. Auf der graphischen Oberfläche erscheint das Fenster Select from object type (vgl. Abb.
9.26), wo nun der auszuführende Befehl zu spezifizieren ist:
• Objekttyp
In der Klausel Select from ist der Name des Objekttypen zu spezifizieren, auf den sich
der Befehl bezieht. Hierfür ist in der darunterliegenden Liste der entsprechende Eintrag zu
markieren.
• Attribute
Für die Festlegung der zu selektierenden Attributwerte ist auf die Schaltfläche add zu
klicken. Es erscheint ein Fenster, das die Attribute des zuvor gewählten Objekttypen anzeigt. Zudem enthält diese Liste den Eintrag <all>, womit alle Attribute eines Objekttypen bezeichnet sind.
• Bedingung
In der Klausel where condition wird die Bedingung angegeben, die von den Datensätzen
zu erfüllen ist. Dazu muss auf die Schaltfläche condition geklickt werden, wodurch ein
entsprechendes Fenster geöffnet wird. In Abbildung 9.26 ist diese Klausel leer, da alle
Datensätze von WARE ausgegeben werden sollen.
Sobald der Benutzer seine Eingaben bestätigt hat, wird der Befehl im Verarbeitungssystem
ausgeführt. Für die Ausgabe der selektierten Datensätze wird ein Fenster geöffnet, das Abbildung
9.27 zeigt.
9.4.2
Verarbeitungssystem
Das Verarbeitungssystem von ALFRED wurde mit der Programmiersprache C++ implementiert. Diese Sprache wurde vor allem deswegen verwendet, weil sich die graphische Benutzeroberfläche, die in Tcl/Tk realisiert ist, problemlos integrieren lässt. Da einige Funktionen des
Menüsystems auf Teile des Verarbeitungssystems, wie das ’Online-Repository’, zugreifen, war es
9.4. IMPLEMENTIERUNG
Abbildung 9.25: Fenster Datenmanipulationsmenü.
Abbildung 9.26: Fenster Select from object type.
Abbildung 9.27: Fenster Selected data from WARE.
349
350
KAPITEL 9. PROTOTYP
notwendig, diese beim Tcl-Interpreter zu registrieren. So wurde z.B. für die Ausführung eines
Benutzerbefehls der folgende Code programmiert:
Tcl_CreateCommand(
interp,
"execute_command",
(Tcl_CmdProc *) execute_command,
(Tcl_ClientData *) NULL,
(Tcl_DeleteCmdProc *) NULL);
Für die persistente Speicherung von Daten wird das Datenbanksystem INGRES PD V8.9 verwendet, das auf dem Internet frei verfügbar ist. Auf dieses System wird von drei Klassen zugegriffen:
• Klasse data rep
Für die Initialisierung des ’Online-Daten-Repository’ werden von dieser Klasse die entsprechenden Daten aus der Datenbank system gelesen.
• Klasse rule rep
Diese Klasse greift auch auf die Daten der Datenbank system zu, damit das ’Online-RegelRepository’ aufgebaut werden kann.
• Klasse tmgr
Diese Klasse repräsentiert das implementierte Transaktionssystem und muss einen Zugriff
auf die im Datenbanksystem gespeicherten Daten haben. So ist es z.B. erforderlich, dass
die Daten, die bei der Verarbeitung einer Transaktion manipuliert wurden, am Ende im
Datenbanksystem festgeschrieben werden. Um diese Zugriffe zu ermöglichen, müssen die
Befehle der ADML in EQUEL-Befehle (Embedded Query Language for INGRES) transformiert werden. Diese Transformation erfolgt mit Hilfe von Treiberprogrammen, die in C
programmiert sind und in das Programm bei der Übersetzung eingebunden werden.
Die Module, die EQUEL-Befehle enthalten, müssen vor dem Übersetzen mit dem EQUELPrecompiler übersetzt werden. Dadurch werden die Befehle (beginnend mit ’##’) von einem
normalen C-Code ersetzt. Beim Binden des Programms muss die Bibliothek libq angegeben
werden, die ein Bestandteil von INGRES PD V8.9 ist.
Das folgende Beispiel zeigt eine Sequenz von EQUEL-Befehlen, die einen neuen Datensatz in
die Relation WARE der Datenbank kunden db einfügen. Zuerst werden einige EQUEL-Variablen
deklariert. Anschliessend werden diesen Variablen gewisse Werte zugewiesen. Zum Schluss wird
der Datensatz in die Relation WARE eingefügt:
##
##
##
##
char
char
char
char
db_name[20]
rel_name[20]
att_list[100]
val_list[100]
strcpy(db_name,"kunden_db");
strcpy(rel_name,"WARE");
strcpy(att_list,"wnr,bezeichnung,farbe,groesse,hersteller,bestand,preis");
strcpy(val_list,"10,Hose,blau,32,Lewis,1500,79.90");
9.5. LAUFZEITVERHALTEN
351
## INGRES kunden_db
## PARAM APPEND TO rel_name (att_list, val_list)
## EXIT.
9.5
Laufzeitverhalten
Für eine Beurteilung des Prototypen wurden Aufwandsabschätzungen und Laufzeitanalysen
durchgeführt. Ziel dieser Untersuchungen war es, Aussagen über das Laufzeitverhalten formulieren zu können und Hinweise auf Optimierungsmöglichkeiten der Module zu erhalten. Die
Analysen konzentrierten sich vor allem auf zwei Punkte:
• Module
Für eine Beurteilung der Performance des Prototypen wurden die implementierten Module
darauf analysiert, welche Zeit sie für die Bearbeitung ihrer Aufgaben benötigen. Aus diesen
Resultaten können sich Hinweise der Optimierung ergeben.
• ALFRED vs. INGRES
Es ist offensichtlich, dass die Verarbeitung von Befehlen und Regeln in ALFRED mehr
Zeit benötigt, als wenn die Befehle direkt in INGRES ausgeführt werden. Um aber beurteilen zu können, ob sich die Entwicklung der Konzepte aus Sicht der Performance
rechtfertigen lässt, wurde ein Vergleich zwischen ALFRED und INGRES durchgeführt. Es
muss aber darauf hingewiesen werden, dass diese Ergebnisse nur zu einem geringen Teil
in eine Gesamtbewertung einfliessen dürfen, da die Systeme nicht die gleichen Funktionalitäten unterstützen. So beinhaltet INGRES z.B. kein Transaktionssystem, und es lassen
sich gewisse Integritätsbedingungen, wie z.B. Primärschlüssel-Integritätsbedingungen, nicht
implementieren.
Die Grundlage der Analysen stellt ein Test-Szenario dar, das auf der Verarbeitung von Transaktionen und Regeln basiert:
• Transaktionen
Die Transaktionen enthalten im Durchschnitt 50 Datenmanipulationsbefehle, die sich auf
mehrere Relationen einer Datenbank beziehen. Daten werden selektiert, eingefügt, manipuliert und gelöscht.
• Regeln
Aufgrund der geringen aktiven Funktionalitäten, die vom Prototypen unterstützt werden,
konnten nur Regeln definiert werden, die sich vor allem für die folgenden Aufgaben einsetzen lassen:
– Integritätsbedingungen
Ein Teil der Regeln wurde definiert, um Not Null- und benutzerdefinierte Integritätsbedingungen sicherzustellen. Schlüssel- und Primärschlüssel-Integritätsbedingungen
konnten nicht realisiert werden, da dafür Bedingungen zu spezifizieren sind, die auf
select Befehlen basieren. Solche Bedingungen werden aber vom Prototypen nicht
unterstützt.
– Verhinderung der Aktualisierung von Attributwerten
Ein anderer Teil der Regeln wird verwendet, um die Aktualisierung von Attributwerten zu verhindern. So wurde z.B. festgelegt, dass Primärschlüsselattribute nicht
manipuliert werden dürfen.
352
KAPITEL 9. PROTOTYP
– Verhinderung der Löschung von Datensätzen
Andere Regeln stellen sicher, dass keine Datensätze aus einer Relation gelöscht werden.
– Zugriffsberechtigungen
Eine weitere Aufgabe der Regeln stellt die Überprüfung von Zugriffsberechtigungen
dar. So wird bspw. kontrolliert, ob ein Benutzer das Recht hat, eine Transaktion
auszuführen oder nicht.
Die im Rahmen dieses Test-Szenarios definierten Regeln weisen entweder eine ECA- oder
EA-Struktur auf und werden durch Datenmanipulations- oder Transaktions-Ereignisse
ausgelöst. Bei der Definition der Ereigniskomponenten wurden sowohl die Auslösungszeitpunkte pre und post als auch die Granularitäten set und instance verwendet. Die
Bedingungen sind primitiv und wurden auf der Basis von Prädikaten gebildet. Die Aktionskomponenten sind primitiv oder komplex und bestehen hauptsächlich aus MeldungsAktionen, mit denen der Benutzer z.B. über die Verletzung einer Integritätsbedingung
informiert wird. Da mehrere Regeln durch das gleiche Ereignis ausgelöst werden, wurden
Prioritäten benutzt, um die Reihenfolge der Verarbeitung eindeutig festzulegen. Bei der
Definition der Kopplungen wurde nur der Modus immediate angegeben, so dass die Regeln
unmittelbar nach der Auslösung verarbeitet werden.
Bei der Implementierung des Prototypen wurden mehrere Methoden erstellt und integriert,
mit denen u.a. zeitbasierte Meldungen generiert und ausgegeben werden. Diese Daten wurden
nicht nur für Analysezwecke, sondern auch für eine Überprüfung der korrekten Verarbeitung
von Transaktionen und Regeln verwendet. Die Tabelle 9.1 zeigt die Resultate, die sich bei der
Verarbeitung einer Test-Transaktion ergaben:
• Test-Transaktion
Diese Transaktion besteht aus insgesamt 60 Befehlen, die vom Prototypen in 29.4 Sekunden
verarbeitet wurden. Die Ausführung eines Befehls beträgt im Schnitt eine halbe Sekunde,
worin die Zeit für die Verarbeitung von durchschnittlich 10 Regeln inbegriffen ist.
• Regeln
Insgesamt wurden 711 Regeln ausgelöst und verarbeitet, wofür 11.8 Sekunden benötigt
wurden. Dies entspricht 40% der Zeit, die für die Verarbeitung der Test-Transaktion erforderlich war.
• Erzeugte Transaktionen
Für die Ausführung der Test-Transaktion wurden 1861 Transaktionen erzeugt, verwaltet
und verarbeitet. Davon hat das System insgesamt 1799 Transaktionen für die Verarbeitung
von Regeln generiert.
Es fällt auf, dass mehr ACTION-Transaktionen als INSTRUCTION-Transaktionen erzeugt wurden. Dies ist damit zu begründen, dass jede ECA-Regel als ECAA-Regel modelliert ist,
wobei das Teilnetz der SONST-Aktionskomponente leer ist. Wird bei der Auswertung einer Bedingung festgestellt, dass sie verletzt ist, erzeugt das System für die Verarbeitung
dieser leeren Aktionskomponente eine ACTION-Transaktion, die kurze Zeit später wieder
terminiert wird.
• Module
Die Analyseergebnisse enthalten auch Angaben zu einigen Modulen, die eine Bewertung
ihres Laufzeitverhaltens erlauben:
9.5. LAUFZEITVERHALTEN
353
Anzahl
Gemessene Zeiten in Sek.
Mittelwert
Standardabweichung
Module
’AFPN Generation’
1
0.490
’PED’
1
1.150
60
0.010
1
29.400
60
0.484
0.233
491
0.065
0.177
431
0.006
0.017
Condition-Transaktionen
657
0.014
0.010
Action-Transaktionen
711
0.016
0.016
11.850
3.644
’ARFPN Generation’
0.005
Transaktionen
Root-Transaktionen
Befehle
Instruction-Transaktionen
für Transaktionsbefehle
für Regelaktionen
Total
1861
Regeln
711
ECA-Regeln
EA-Regeln
60
657
54
Tabelle 9.1: Ergebnisse einer Test-Transaktion
– Modul ’AFPN Generation’
Das Modul ’AFPN Generation’ erzeugt für die Test-Transaktion ein Petri-Netz mit
etwa 180 Plätzen und Transitionen und benötigt dazu eine knappe halbe Sekunde.
Darin inbegriffen ist die Zeit, die für das Lesen der benutzerdefinierten Transaktion
aus dem ’Online-Daten-Repository’ erforderlich ist.
– Modul ’PED’
Der ’PED’ benötigt für die Erkennung von über 60 primitiven Ereignissen, der Erweiterung des Netzes um Plätze und Transitionen sowie der Erstellung der Verbindungen
zum Ereignissystem mehr als 1 Sekunde.
– Modul ’ARFPN Generation’
Das Modul ’ARFPN Generation’ instanziiert durchschnittlich 10 Regeln pro Aufruf
und benötigt dafür etwa 0.1 Sekunde, inbegriffen der Zeit für die Integration der
erstellten Regelinstanzen.
Neben der Analyse des Prototypen wurde auch ein Vergleich mit INGRES durchgeführt. Dazu
wurden einzig die Verarbeitungszeiten der Datenmanipulationsbefehle protokolliert. Das Ergebnis dieser Untersuchung lässt sich so zusammenfassen, dass die Test-Transaktionen von INGRES
rund 10 Mal schneller als von ALFRED verarbeitet werden. Dieses Resultat ist jedoch stark zu
354
KAPITEL 9. PROTOTYP
relativieren, da für den Vergleich dieser Systeme nicht dieselben Voraussetzungen geschaffen
werden konnten. So werden z.B. im Unterschied zu INGRES die Befehle in ALFRED transaktionsbasiert verarbeitet, was eine Verschlechterung der Performance bewirkt.
Anhand der Auswertungsergebnisse lassen sich nicht nur einige Aussagen über das Laufzeitverhalten formulieren, sondern auch Optimierungsmöglichkeiten aufzeigen:
• Laufzeitverhalten
Der Prototyp zeigt ein gutes Laufzeitverhalten, wie die gemessenen Zeiten für die Verarbeitung der Test-Transaktionen zeigen. Durch eine Optimierung der Datenstrukturen,
Algorithmen und der auszuführenden Netzwerke könnte die Performance des Systems noch
gesteigert werden. Dies gilt besonders für den ’PED’, da dieses Modul, im Verhältnis zu
anderen Systemkomponenten, relativ viel Zeit benötigt.
• Optimierungen
Aus den Untersuchungsergebnissen lassen sich Möglichkeiten der Optimierung folgern. Vier
Beispiele dafür sind:
– Regelanzahl
Da im Prototypen nur primitive Ereignisse und Bedingungen spezifiziert werden
können, muss eine grössere Anzahl von Regeln definiert und verarbeitet werden, als
es durch die Unterstützung von komplexen Komponenten nötig wäre. So könnten
z.B. die Regeln, mit denen Not Null-Integritätsbedingungen implementiert sind, zu
einigen wenigen Regeln zusammengefasst werden. Dadurch reduziert sich bei 10 solchen Bedingungen die Anzahl der zu verarbeitenden Transitionen um 90%. Dies hat
beträchtliche Auswirkungen auf die Laufzeit und führt damit zu einer besseren Performance.
– Petri-Netze
Bei der Modellierung der Petri-Netze stand nicht der Aspekt des Laufzeitverhaltens
im Vordergrund. So enthalten z.B. die Petri-Netze der ECA-Regeln auch eine leere
SONST-Aktionskomponente, die durch eine BOA und EOA Transition dargestellt ist. Damit die nutzlose Erzeugung von ACTION-Transaktionen verhindert wird, könnten die
CHOICE Plätze mit Hilfe einer DUMMY Transition direkt mit den EOR Plätzen verbunden
werden. Ähnliche Optimierungsmöglichkeiten bestehen auch an anderen Stellen der
Petri-Netze.
– Datenstrukturen
Die verwendeten Listen-Datenstrukturen sind durch ihre Einfachheit gekennzeichnet
und eignen sich daher besonders für die Implementierung eines Prototypen. Durch
die Verwendung effizienter Datenstrukturen und Suchalgorithmen, wie z.B. Hashing,
ist insbesondere bei grossen Datenbeständen eine Verbesserung der Performance anzunehmen.
– Programmierung
Das primäre Ziel eines Prototypen besteht nicht darin, ein unter Performance-Aspekten möglichst leistungsfähiges System zu entwickeln. Ein Prototyp dient vor allem
der Überprüfung der Umsetzbarkeit entwickelter Konzepte. Die Implementierung des
Prototypen ist daher aus Performance-Sicht nicht als optimal anzusehen. Folglich ist
zu vermuten, dass sich ein relativ grosses Optimierungspotential in den Datenstrukturen und Algorithmen befindet.
Zusammenfassend lässt sich festhalten, dass die Entwicklung der Konzepte für eine datenbankunabhängig einsetzbare aktive Schicht sinnvoll ist, da regelbasierte Abläufe auf der Basis von
9.5. LAUFZEITVERHALTEN
355
ARFPN ausgeführt werden können. Zudem lassen sich diese Modelle auch für andere Anwendungen, wie zur Ereigniserkennung, verwenden. Durch die Struktur des Ereignissystems und
Regelwaldes7 ist eine effiziente Ereigniserkennung und Regelauslösung möglich. Dies wird durch
das Laufzeitverhalten des Moduls ’ARFPN Generation’ gestützt.
Obgleich mit der Ausführung regelbasierter Abläufe einige Performance-Einbussen verbunden
sind, hat sich gezeigt, dass der Prototyp für einfache Anwendungen gut eingesetzt werden kann
und dabei eine akzeptable Performance aufweist.
7
vgl. Abschnitt 7.5.5.