Definition der HTML-Generierungsprozesse

Definition des Client / Server Modells

Entwicklung nach OSI

Für die Entwicklung eines Client-Server Systems bietet sich das OSI-Referenzmodell wie kein anderes an. Unter [*] ist bereits das OSI-Modell mit TCP/IP verglichen worden. Eine wesentliche Feststellung ist, daß Applikationen unter TCP/IP die oberen drei Schichten vermengen und nicht dem OSI-Modell folgen. Dies wäre selbstverständlich auch für das Informations- und Hilfesystem möglich gewesen, und wurde auch für schnelles Prototyping so gehandhabt.

Letztlich läßt aber eine Entwicklung unter Heranziehung des OSI-Modells eine planvollere und strukuriertere Lösung mit entsprechender Wiederverwendbarkeit zu. Aus diesem Grund wurde die Sitzungsschicht in Anlehnung an OSI programmiert. Sie kann damit auch Grundlage für andere Problemlösungen sein, und erlaubt den Vollduplexaustausch von Daten ohne den Zugriff auf auf die Transportschicht neu implementieren zu müssen.

Transportschicht TCP

Neben dem Protokoll TCP existieren auch zahlreiche weitere Protokolle der Transportschicht, auf die unter UNIX auch durchaus zugegriffen werden kann. Letztendlich wird in der Regel neben TCP jedoch nur UDP verwendet, das als verbindungsloses Protkoll nur den Austausch von Datagrammen ermöglicht, und daher für Lösung eher ungeeignet ist. Zudem wird durch TCL 7.5 derzeit nur TCP unterstützt, so daß dieses Protokoll als Transportschicht für das Hypertext Informations- und Hilfesystem verwendet werden muß.

Definition eines OSI-Dienstes

Ein Dienst wird formal durch eine Reihe von Dienstelementen ( primitives) oder auch Operationen gekennzeichnet, über die es dem Anwender oder der Instanz möglichen, den Dienst in Anspruch zu nehmen. Diese Dienstelemente sorgen dafür, daß der Dienst eine bestimmte Handlung durchführt, oder daß er auf eine Hnadlung der Partnerinstanz in einer bestimmten Weise reagiert. Innerhalb des OSI-Modells können Dienstelemente in vier Klassen aufgeteilt werden. Diese sind in Tabelle [*] dargestellt.

Dienstelement Bedeutung

Anforderung (request) Eine Instanz möchte einen Dienst dazu veranlassen,

etwas bestimmtes zu tun

Anzeige (indication) Eine Instanz soll über ein Ereignis informiert werden

Antwort (response) Eine Instanz möchte auf ein Ereignis reagieren

Bestätigung (confim) Eine Instanz soll über eine bestätigte Anforderung

informiert werden

Tabelle: Vier Klassen von Dienstelementen

**Tabelle:** Vier Klassen von Dienstelementen
Dienstelement	Bedeutung
Anforderung (request)	Eine Instanz möchte einen Dienst dazu veranlassen,
	etwas bestimmtes zu tun
Anzeige (indication)	Eine Instanz soll über ein Ereignis informiert werden
Antwort (response)	Eine Instanz möchte auf ein Ereignis reagieren
Bestätigung (confim)	Eine Instanz soll über eine bestätigte Anforderung
	informiert werden

Die erste Klasse von Dienstelementen ist das Anforderungselement ( request). Damit wird eine bestimmte Arbeit begonnen, zum Beispiel der Aufbau einer Verbindung oder die Versendung von Daten. Die Partnerinstanz bekommt über eine Anzeige (indication die Anforderung signalisiert. In OSI-Schreibweise erhält damit durch CONNECT.request die Partnerinstanz (peer) ein CONNECT.indication und beantwortet dies durch CONNECT.response, was beim Versender der Anforderung ein CONNECT.confirm auslöst(*).

Jeder bestätigende (confirmed Dienst verfügt über alle vier Dienstprimitive. Unbestätigte (unconfirmed) Dienste kennen lediglich eine Antwort und eine Anzeige. Weitere Dienste können im OSI-Modell auch über weniger Dienstprimitive verfügen, aber niemals über mehr. Die vier vorgestellten Primitive sind für das Modell erschöpfend. Ein Dienst besteht aus einem Satz von Operationen bzw. Dienstelementen.

Zur Transparenz des Dienstekonzeptes, soll ein Beispiel für einen verbindungsorientierten Dienst mit acht Dienstelementen angeführt werden, und zwar die telefonische Bestellung einer Pizza:

CONNECT.request - Eine Telefonnummer des Pizza-Service wählen
CONNECT.indication - Das Telefon läutet dort
CONNECT.response - Der Inhaber nimmt das Telefon ab
CONNECT.confirm - Es wird vernommen, daß jemand an das Telefon geht
DATA.request - Aufgeben der Pizzabestellung
DATA.indication - Pizzadienst nimmt Bestellung entgegen
DATA.request - Pizzadienst stellt Lieferung in 20 Minuten in Aussicht
DATA.indication - Aufnahme der Lieferinformation
DISCONNECT.request - Auflegen des Bestellers
DISCONNECT.indication - Auflegen des Pizza-Lieferanten

Dienste und Protokolle haben unterschiedliche Bedeutung und Konzepte. Währen ein Dienst die Sammlung der Dienstelemente einer Schicht ist, die der über ihr liegenden Schicht zur Verfügung gestellt werden, ist ein Protokoll das Regelgefüge, welches das Format und die Bedeutung der von den Partnerinstanzen innerhalb einer Schicht ausgetauschten Rahmen, Pakete oder Nachrichten festlegt. Mit Protokollen führen Schichten ihre Dienste aus, Dienste sind die Schnittstelle für den Dienstnutzer. Von außerordentlicher Wichtigkeit ist es, daß die Protokolle auf beiden Partnerinstanzen absolut identisch sind. Dies macht bei der Vielzahl von Betriebssystemen und Technologien die Wichtigkeit der einheitlichen Normung deutlich.

Definition der Sitzungsschicht

Implementationen nach OSI

Tabelle [*] stellt alle OSI-Sitzungsdienstelemente der Sitzungsschicht dar. Nicht alle Dienstelemente wurden implementiert, da sie für Lösung des Problems nicht benötigt werden und den TCL-Quellcode überfrachtet hätten. Folgende Elemente wurden mit allen Primitiven des OSI-Modells implementiert:

S-CONNECT
S-RELEASE
S-U-ABORT
S-P-ABORT
S-DATA
S-U-EXCEPTION-REPORT
S-P-EXCEPTION-REPORT

Der Bezeichner ,,S`` kennzeichnet, daß es sich um die Sitzungschicht handelt. ,,U`` und ,,P`` stehen für ,,User`` und ,,Provider`` und kennzeichnen den Ursprung von Aktionen eines Dienstelementes. Für die Sitzungsschicht wird damit ein Service Access Point (SSAP) definiert, der genau diese Dienstelemente beinhaltet.

Dienstprimitive

REQUEST

INDICATION

RESPONSE

CONFIRM

OSI-Sitzungsdienstelemente

S-CONNECT X X X X CONNECT ACCEPT, REFUSE

S-RELEASE X X X X FINISH DISCONNECT, NOT FINISHED

S-U-ABORT X X ABORT (ABORT ACCEPT)

S-P-ABORT X (ABORT)

S-DATA X X DATA-TRANSFER

S-EXPEDITED-DATA X X EXPEDITED DATA

S-TYPES-DATA X X TYPED DATA

S-CAPABILITY-DATA X X X X CAPABILITY DATA CAPABILITY DATA ACK

S-TOKEN-GIVE X X GIVE TOKENS

S-TOKEN-PLEASE X X PLEASE TOKENS

S-CONTROL-GIVE X X GIVE TOKENS CONFIRM (GIVE TOKENS ACK)

S-SYNC-MAJOR X X X X MAJOR SYNC POINT MAJOR SYNC POINT ACK

S-SYNC-MINOR X X X X MINOR SYNC POINT MINOR SYNC POINT ACK

S-RESYNCHRONIZE X X X X RESYNCHRONIZE RESYNCHRONIZE ACK

S-ACTIVITY-START X X ACTIVITY START

S-ACTIVITY-END X X X X ACTIVITY END ACTIVITY END ACK

S-ACTIVITY-DISCARD X X X X ACTIVITY DISCARD ACTIVITY DISCARD ACK

S-ACTIVITY-INTERUPT X X X X ACTIVITY INTERRUPT ACTIVITY INTERRUPT ACK

S-ACTIVITY-RESUME X X ACTIVITY RESUME

S-U-EXCEPTION-REPORT X X EXCEPTION REPORT

S-P-EXCEPTION-REPORT X (EXCEPTION REPORT)

Tabelle: Dienstelemente der Sitzungsschicht mit ihren SPDUs

**Tabelle:** Dienstelemente der Sitzungsschicht mit ihren SPDUs
		Dienstprimitive
		REQUEST
			INDICATION
				RESPONSE
					CONFIRM

OSI-Sitzungsdienstelemente

S-CONNECT	X	X	X	X	CONNECT	ACCEPT, REFUSE
S-RELEASE	X	X	X	X	FINISH	DISCONNECT, NOT FINISHED
S-U-ABORT	X	X			ABORT	(ABORT ACCEPT)
S-P-ABORT		X			(ABORT)
S-DATA	X	X			DATA-TRANSFER
S-EXPEDITED-DATA	X	X			EXPEDITED DATA
S-TYPES-DATA	X	X			TYPED DATA
S-CAPABILITY-DATA	X	X	X	X	CAPABILITY DATA	CAPABILITY DATA ACK
S-TOKEN-GIVE	X	X			GIVE TOKENS
S-TOKEN-PLEASE	X	X			PLEASE TOKENS
S-CONTROL-GIVE	X	X			GIVE TOKENS CONFIRM	(GIVE TOKENS ACK)
S-SYNC-MAJOR	X	X	X	X	MAJOR SYNC POINT	MAJOR SYNC POINT ACK
S-SYNC-MINOR	X	X	X	X	MINOR SYNC POINT	MINOR SYNC POINT ACK
S-RESYNCHRONIZE	X	X	X	X	RESYNCHRONIZE	RESYNCHRONIZE ACK
S-ACTIVITY-START	X	X			ACTIVITY START
S-ACTIVITY-END	X	X	X	X	ACTIVITY END	ACTIVITY END ACK
S-ACTIVITY-DISCARD	X	X	X	X	ACTIVITY DISCARD	ACTIVITY DISCARD ACK
S-ACTIVITY-INTERUPT	X	X	X	X	ACTIVITY INTERRUPT	ACTIVITY INTERRUPT ACK
S-ACTIVITY-RESUME	X	X			ACTIVITY RESUME
S-U-EXCEPTION-REPORT	X	X			EXCEPTION REPORT
S-P-EXCEPTION-REPORT	X				(EXCEPTION REPORT)

Definition von Sitzungen

Eine Sitzung ist einer Transportverbindung sehr ähnlich, sie sind jedoch nicht identisch. Wenn in der Sitzungsschicht eine Anforderung für den Sitzungsaufbau eintrifft, muß eine Transportverbindung aufgebaut werden, die die Sitzungsverbindung trägt. Sobald die Sitzung beendet ist, wird auch die Transportverbindung abgebaut. Das bedeutet, daß die Sitzung eins zu eins auf eine Transportverbindung abgebildet wird. Es sind aber auch andere Abbildungen möglich. Eine Transportverbindung kann kontinuierlich bestehen, Sitzungen werden jedoch nur bei Bedarf aufgebaut. Es ist durchaus möglich und zulässig über die gleiche Transportverbindung mehrere Sitzungen zu führen. Als Sitzungen werden Verbindungen bezeichnet, die es ermöglichen, Verbindungen aufzubauen und mit diesen geordnet Daten für Benutzerprozesse zu übertragen.

Problematik von OSI mit RPC

Der rechnerferne Prozeduraufruf (RPC) fügt sich nicht besondes gut in das OSI-Referenzmodell ein, und ist daher auch nicht in mehreren Schichten aufgebaut. Er wird zwischen Sitzungsschicht und Anwendungsschicht eingeordnet. RPCs greifen in die Authorität der oberen drei Schichten ein. Eine genauere Einordnung hängt deshalb von der Art der über RPCs ausführbaren Funktionen ab.

Anlehnung an die Darstellungsschicht

Dienstprimitive

REQUEST

INDICATION

RESPONSE

CONFIRM

OSI-Sitzungsdienstelemente

P-CONNECT X X X X Einrichtung einer Darstellungsstruktur

P-RELEASE X X X X Geordneter Abbau

P-U-ABORT X X Abrupter Abbau durch Benutzer

P-P-ABORT X Abrupter Abbau durch Anbieter

P-DATA X X Übertragung von normalen Daten

P-EXPEDITED-DATA X X Übertragung von beschleunigten Daten

P-TYPES-DATA X X Übertragung von Außerbanddaten

P-CAPABILITY-DATA X X X X Übertragung von Steuerinformationen

P-TOKEN-GIVE X X Ein Token an den Partner übergeben

P-TOKEN-PLEASE X X Ein Token vom Partner anfordern

P-CONTROL-GIVE X X Alle Token an den Partner übergeben

P-SYNC-MAJOR X X X X Hauptsynchronisierungspunkt einfügen

P-SYNC-MINOR X X X X Nebensynchronisierungspunkt einfügen

P-RESYNCHRONIZE X X X X Zurückgehen an früheren Synchronisationspunkt

P-ACTIVITY-START X X Aktivität beginnen

P-ACTIVITY-END X X X X Aktivität beenden

P-ACTIVITY-DISCARD X X X X Aktivität abbrechen

P-ACTIVITY-INTERUPT X X X X Aktivität aussetzen

P-ACTIVITY-RESUME X X Ausgesetzte Aktivität wiederaufnehmen

P-U-EXCEPTION-REPORT X X Ausnahmebedingung des Benutzers berichten

P-P-EXCEPTION-REPORT X Ausnahmebedingung des Anbieters berichten

P-ALTER-CONTEXT X X X X Wechsel des Kontext

Tabelle: Verbindungsorientierte Dienstelemente der Darstellungsschicht

**Tabelle:** Verbindungsorientierte Dienstelemente der Darstellungsschicht
		Dienstprimitive
		REQUEST
			INDICATION
				RESPONSE
					CONFIRM

OSI-Sitzungsdienstelemente

P-CONNECT	X	X	X	X	Einrichtung einer Darstellungsstruktur
P-RELEASE	X	X	X	X	Geordneter Abbau
P-U-ABORT	X	X			Abrupter Abbau durch Benutzer
P-P-ABORT		X			Abrupter Abbau durch Anbieter
P-DATA	X	X			Übertragung von normalen Daten
P-EXPEDITED-DATA	X	X			Übertragung von beschleunigten Daten
P-TYPES-DATA	X	X			Übertragung von Außerbanddaten
P-CAPABILITY-DATA	X	X	X	X	Übertragung von Steuerinformationen
P-TOKEN-GIVE	X	X			Ein Token an den Partner übergeben
P-TOKEN-PLEASE	X	X			Ein Token vom Partner anfordern
P-CONTROL-GIVE	X	X			Alle Token an den Partner übergeben
P-SYNC-MAJOR	X	X	X	X	Hauptsynchronisierungspunkt einfügen
P-SYNC-MINOR	X	X	X	X	Nebensynchronisierungspunkt einfügen
P-RESYNCHRONIZE	X	X	X	X	Zurückgehen an früheren Synchronisationspunkt
P-ACTIVITY-START	X	X			Aktivität beginnen
P-ACTIVITY-END	X	X	X	X	Aktivität beenden
P-ACTIVITY-DISCARD	X	X	X	X	Aktivität abbrechen
P-ACTIVITY-INTERUPT	X	X	X	X	Aktivität aussetzen
P-ACTIVITY-RESUME	X	X			Ausgesetzte Aktivität wiederaufnehmen
P-U-EXCEPTION-REPORT	X	X			Ausnahmebedingung des Benutzers berichten
P-P-EXCEPTION-REPORT	X				Ausnahmebedingung des Anbieters berichten
P-ALTER-CONTEXT	X	X	X	X	Wechsel des Kontext

Tabelle [*] stellt die Dienstelemente der Darstellungschicht dar, beinhaltet jedoch nicht die Primitive der verbindungsunabhängigen Datenübertragungen, da diese Art der Übertragung für die vorliegende Arbeit nicht von Bedeutung ist. Vollständige Informationen hierzu gibt Tanenbaum [AT92][S. 579].

Da für die Kommunikation zwischen Server und Client RPCs geplant sind, läßt dies keinen Raum für die Implementation der Darstellungsschicht. Dennoch bietet diese Schicht eine gute Vorlage, für eine Gestaltung von RPCs, die die Funktionalität nachempfinden. Tatsächlich entspricht die Anmeldung an einem Server, der Austausch von Kommandos und Funktionswerten in weiten Teilen auch der Darstellungsschicht.

Auch die Anpassung der Umgebung für einen Klienten mit Hilfe von RPCs steht funktional nicht im Widerspruch zu den Definitionen von ISO für diese Ebene, wie im folgenden Abschnitt dargestellt wird, denn RPCs können ebensogut die Aufgaben übernehmen, für die ansonsten die Dienstelemente der Darstellungschicht zuständig wären.

Definition des Kontext

Die Bedeutung des lat. Begriffes Kontext wird allgemein als (innerer) Zusammenhang verstanden. Eine genauere Interpretation eines Sachverhaltes allein anhand des Begriffes ist nicht möglich, da dessen Verwendung zu vielfältigen Themen, eine eindeutige Begriffsbestimmung nicht zuläßt. Zu nennen im Software-Zusammenhang wäre hier als typisches Beispiel der Kontext nach der Norm X.500 (*) , welcher die Position eines Objektes im Verzeichnisbaum angibt.

Hinsichtlich dieser Definitionsproblematik ist eine genaue Festlegung der Bedeutung des hier verwendeten Kontext-Begriffes erforderlich. Der in dieser Diplomarbeit verwendete Kontext ist ebenfalls nicht zu verwechseln mit dem Kontext eines Anwendungsprogrammes (user context) oder dem Kontext eines Kernels (kernel context) der sich auf Speicherbereiche und deren Zugriffsmodi bezieht(*), sondern richtet sich einzig und allein auf den Kontext der Darstellungschicht (presentation layer) des OSI-Modells, beschrieben auch durch Tanenbaum [AT92, S. 575,] und illustriert unter [*].

Die Darstellungsschicht ist seit der Einführung des OSI-Modells in großen Ausmaße weiterentwickelt worden, nachdem diese Schicht lange Zeit auf der Suche nach ihrer eigentlichen Aufgabe gewesen ist. Ursprünglich war sie nur als Stelle angesehen worden, an der Konvertierungen durchgeführt werden konnten, beispielsweise so, daß ASCII- mit EBCDIC-Rechnern kommunizieren konnten. Mittlerweile entschloß man sich, der Darstellungsschicht alle Aufgaben, einschließlich Konvertierung, Verschlüsselung und Komprimierung zu übertragen, so daß sie zutreffender als ,,Repräsentationsschicht`` bezeichnet werden könnte. Eine ISO-Norm zur Lösung dieser Aufgaben heißt abstrakte Sytnaxnotation1 (ASN.1).

Die vier Hauptaufgaben der Darstellungschicht sind damit:

Die Möglichkeit zur Ausführung der Sitzungsdienstelemte zu geben
Daten zwischen interner und externer Form zu konvertieren
Möglichkeiten zur Spezifikation komplexer Datenstrukturen zu bieten
Die benötigten Datenstrukturen zu verwalten

Diese Aufgaben machen deutlich, daß sich die Darstellungschicht des VDM Datenbankmanagers sowohl in 1. und 2. auf den TCL-Code als auch in 3. und 4. auf den Hochsprachen- bzw. VDM-Anteil erstreckt. Sitzungsdienstelemete betreffen die in TCL implementierte Sitzungschicht, als auch die implementierte Konvertierung von MIME-Elementen. Alle weiteren Tools zur Klassenbibilothek beruhen in der Darstellungschicht auf TCL.

Viele der Dienstelemente der OSI-Darstellungschicht sind mit denen der OSI-Sitzungsschicht identisch. Der Aufruf von P-CONNECT.request von einer Anwendungsinstanz bewirkt, daß von der Darstellungsschicht S-CONNECT.request ausgelöst wird. Tatsächlich werden fast alle Dienstelemente der Darstellungsschicht an die Sitzungschicht übergeben, und umgekehrt. Augenmerk ist jedoch auf die Primitive P-ALTER-CONTEXT der Darstellungsschicht zu legen, wie Tabelle [*] zeigt.Die für bestimmte Anwendungen eingesetzten Datenstrukturen können in Gruppen zusammengefaßt werden, welche als Kontext bezeichnet werden.

Der Kontext, der den Zustand des VDM Datenbankmanagers beschreibt, besteht aus nachfolgend dargestellter Gruppe(*), die als Zeichenketten bzw. Zeichenketten-Sets im Hochsprachencode des Datenbankmanagers enthalten sind. Zu den einzelnen Elementen dieser Gruppen sind diejenigen TCL-Kommandos, welche für die Einstellung dieses Kontexts verantwortlich sind, als auch die Kommandos, auf welche sich diese Einstellungen auswirken, benannt:

adttypes
Das Kommando
select adttypes [adts]
stellt die Selektion von ADTs der Klassenbibilothek ein bzw. hebt diese wieder auf, sofern keine adts angegeben werden. Auswirkungen treten auf den Befehl
adtdocu
auf, welcher in Abhängigkeit der selektierten ADTs Dokumentation der Bibliothek liefert.
special_impl
Die Bedeutung von
select specialimpl [impls]
ist dem vorangegangenen Kommando ähnlich, die Auswirkungen beziehen sich jedoch auf
impdocu adt
special_ops
select specialops
zählt in seiner Bedeutung zu den vorangegangenen Befehlen select adttypes und select specialimpl. Die Auswirkungen betreffen
oprdocu adt impl
filter_adts
Filterung von ausgewählten ADTs durch
select filteradts adts
beeinflußt die Ausgabe durch
partialexport
filter_impl
Implementationsfilter durch
select filterimpl impls
Auswirkung auf
partialexport
filter_oper
Filterung von Operationen durch
select filteroper opers
Auswirkung auf
partialexport
filter_comp
Filter von Komponenten durch
select filtercomp comps
Auswirkung auf
partialexport
filter_params
Filter für in der Klassenbibliothek hinterlegte Parameter
select filterparam
der in seiner Funktion identisch ist mit Befehl operparams des Datenbankmanagers. Die Auswirkungen betreffen
partialexport
operationtype
Der Operationtypus der Klassenbibliothek wird mittels
operationtype type
eingestellt und kann derzeit als Wertebereich C, C++ oder A++ (für die automatische Speicherverwaltung) annehmen. Es sind jedoch auch weitere Werte vorstellbar, die mit den Inhalten der Klassenbibliothek wachsen. Auswirkung treten auf für alle Kommandos, die mit den Elmenten adttypes, special_impl, und special_ops in Zusammenhang stehen.

Es ist ohne weiteres ersichtlich, daß im Multisessionbetrieb die Einstellung eines speziellen Operationstyps durch einen Benutzer des Datenbankmanagers diesen Status dauerhaft verändert. Würde dieser Benutzer, noch bevor er die nachfolgenden, in diesem Zusammenhang stehenden Folgebefehle abgesetzt hat, durch einen anderen Benutzer unterbrochen, der den Operationstyp anderweitig verändert, so wäre ein willkürliches Resultat das Ergebnis. Ebenso erginge es dem unterbrechenden Benutzer, der sich auf eine Initialisierung des Datenbankmanagers mit den Standardwerten verläßt.

VDM-Spezifikation

Die Einstellung des Kontexts wird nachfolgend in VDM spezifiziert, wobei nicht auf eine vollständige Definition des Datenbankmanagers Wert gelegt, sondern der Schwerpunkt auf der Definition und den Methoden zur Kontexteinstellung des Datenbankmanagers liegt. Die konkrete Definition des Kontexts für das aktuelle Projekt selbst, ist in DSL spezifiziert und im Anschluß wiedergegeben.

Der Leser wird gebeten, den Tree DBCONTEXT wie folgt als C++ Klasse zu abstrahieren, in welcher sämtliche Methoden gekapselt sind. Wesentliche Inhalte dieser Klasse sind der ContextCounter, welcher für implizit erzeugte Sitzungen verwendet wird, CurrentContext als Index des aktuellen Kontexts, DefaultContext als Standardinitialisierung und Tree bestehend aus der gültigen Gruppe, sowie ApplicationContext als Synonym für die Einstellungen der Klasse DBMANAGER .

Die in der Klasse DBMANAGER für unterschiedliches Verhalten verantwortlichen ADTs, wurden in der ursprünglich vorliegenden Version nicht gruppiert. Gemäß der Anforderungen in [*] wurde die Klasse DBMANAGER lediglich um die Klasse DBCONTEXT erweitert, und der gesamte Quellcode ansonsten im wesentlichen unverändert belassen. Aus diesem Grund liegt eine Gruppierung erst in DBCONTEXT vor, welcher Referenzen dieser ADTs bei der Konstruktion mitgeteilt werden. Der Kontext des Datenbankmanagers wird durch eine Manipulation der ADTS über diese Referenzen umgeschaltet. Da Referenzen dieser Art in VDM nicht modelliert werden können, ist ApplicationContext des Trees DBCONTEXT vom Leser mit jenen ungruppierten Variablen der Klassen DBMANAGER gleichzusetzen. Eine lückenlose und identische formale Definition des Kontextwechsels in VDM wäre themenfremd gewesen, hätte die Modellierung des gesamten Datenbankmanagers erfordert und den Text an dieser Stelle überfrachtet.

Domaingleichungen

:: ContextCounter CurrentContext DefaultContext ApplicationContext ContextMap

=

=

= Context

= Context

=

::

:

:

:

:

:

:

:

:

:

:

=

=

=

Operationen

Konstruktion der Kontextverwaltung

Kontextzähler initialisieren mit 0
Aktueller Kontext ist 0
Der Applikationskontext (die Referenz) wird registriert
Der Standardkontext (ist aktueller Kontext) enthält Vorgabewerte

  make-DBCONTEXT(appcontext) =   

        		  reload-DBCONTEXT(mk-DBCONTEXT(mk-INTG(0),mk-INTG(0),  

        		 ¯
        		 		  emptycontext(),appcontext,[INTG(0)    emptycontext()]))    

         type Context    DBCONTEXT

Übernahme des Applikationskontext

Die (möglicherweise geänderten) Einstellungen des Datenbankmanagers werden in den aktuellen Standardkontext übernommen
Die Kontext-Tabelle (oder MAP) wird aktualisiert mit dem Standardkontext

  update-DBCONTEXT(dbcontext) =   

        		  let mk-DBCONTEXT(,currcontext,defcontext,appcontext,contextmap) =   

        		 ¯
        		 		 dbcontext in   

        ¯¯
        		 		  let defcontext = appcontext   

        		 		  let contextmap            = contextmap + [currcontext      defcontext]   

         type DBCONTEXT    DBCONTEXT

Setzen des Applikationskontext
- Der Standardkontext ist (siehe Invariante) immer identisch mit dem durch CurrentContext selektiertem Eintrag der Kontext-MAP
- Der Applikationskontext wird durch den Standardkontext gesetzt
- Der Standardkontext ist nur bei der Initialisierung mit dem Kontext 0 identisch, und wird durch Wechsel des Kontexts mit Einträgen der Kontext-Tabelle getauscht
```
  reload-DBCONTEXT(dbcontext) =    

        		  let mk-DBCONTEXT(,,defcontext,appcontext,) =  

        		 ¯
        		 		  DBCONTEXT in   

        ¯¯
        		 		  let appcontext = defcontext   

         type DBCONTEXT    DBCONTEXT   
```

Erzeugen eines definierten Anfangszustandes

Vorbestimmung des Operationstyps für die Hochsprache C

 emptycontext() =    

        		  mk-Context( { }, { }, { }, { }, { }, { }, { }, { }, { }, { }, c)    

         type    Context

Kontext Existenzübrprüfung

  exists(CID,dbcontext) =    

        		  CID    dom s-ContextMap(dbcontext)   

         type INTG DBCONTEXT    BOOL

Wechsel des Kontexts

Ein Wechsel zu einem bereits gewählten Kontext ist unnötig
Der aktuelle Applikationskontext muß gesichert werden
Die Identifikation des aktuellen Kontexts wird geändert
Der in der Kontext-Tabelle gesicherte Kontext wird wiederhergestellt
Setzen des Applikationskontext
Prämisse: Der Zielkontext muß existieren

  switch(CID,dbcontext) =   

        		  if s-CurrentContext(dbcontext)    

        		 ¯
        		 		  then mk(dbcontext)   

        		 		  else    

        		 		 ¯
        		 		 		  let reload-DBCONTEXT(,currcontext,defcontext,  

        		 		 		 ¯
        		 		 		 		  contextmap) =    

        		 		 		 ¯
        		 		 		 		  update-DBCONTEXT(dbcontext) in    

        		 		 		 		 ¯
        		 		 		 		 		  let currcontext = CID   

        		 		 		 		 		  let defcontext = contextmap(currcontext)   

         type INTG DBCONTEXT    DBCONTEXT

  pre-switch(CID,dbcontext) =   

        		  exists(CID,dbcontext)   

         type INTG DBCONTEXT    BOOL

Implizites erzeugen eines Kontext

Implizit (ohne Kontext-Identifikation) erzeugte Kontext werden mit negativen Ganzzahlen identifiziert(*).
Dekrementieren des Kontextzählers für implizite Erzeugung
Hinzufügen eines neuen Kontext durch Vereinigung(*)

  create(dbcontext) =   

        		  let mk-DBCONTEXT(contextcnt,,,contextmap) = dbcontext in   

        		 ¯
        		 		  let contexcnt = contextcnt -1   

        		 		  let contextmap = contextmap    [contextcnt    emptycontext()]   

         type DBCONTEXT    DBCONTEXT

Explizites Erzeugen eines Kontext

Erzeugen eines neuen Kontext mit Identifikation(*)
Prämisse: Die Kontext-Identifikation ist nicht bereits vergeben

  create(CID,dbcontext) =   

        		  let mk-DBCONTEXT(,,,,contextmap) = dbcontext in   

        		 ¯
        		 		  contextmap = contextmap + [mk-INTG(CID)    emptycontext()]   

         type NAT0 DBCONTEXT    DBCONTEXT

  pre-create(cid,dbcontext) =   

        		     exists(cid,dbcontext)   

         type NAT0 DBCONTEXT    BOOL

Entfernen eines Kontext

Wenn der zu löschender Kontext der aktuelle ist, zuvor Wechsel zum Standardkontext 0
Entfernen des Kontext aus der Kontext-MAP

  release(CID,dbcontext) =   

        		  if CID = s-CurrentContext(dbcontext)    

        ¯¯
        		 		  then let dbcontext = switch(INTG(0),dbccontext)   

        ¯
        		  let mk-DBCONTEXT(,,,,contextmap) = dbcontext in    

        		 ¯
        		 		  contextmap = contextmap    CID   

         type INTG DBCONTEXT    DBCONTEXT

  pre-release(CID,dbcontext) =    

        		     exists(CID,dbcontext) OR CID    mk-INTG(0)   

         type INTG DBCONTEXT    BOOL

Ermitteln aller vergebenen Kontext-Identifikationen

  list(dbcontext) =   

        		  dcl cids := {} type INTG -set   

        		  for all cid    dom s-ContextMap(dbcontext) do    

        		 ¯
        		 		  let cids = cids    {cid}   

        		  cids   

         type DBCONTEXT    INTG -set

Ermitteln der aktuellen Kontext Identifikation

  cid(dbcontext) = s-CurrentContext(dbcontext)   

         type DBCONTEXT    INTG

Ermitteln des aktuellen Kontext

  current(dbcontext) = s-DefaultContext(dbcontext)   

         type DBCONTEXT    Context

Konsistenzbedingung

Es existiert der Standardkontext 0
Der Kontext-Zähler ist null oder negativ
Der Standardkontext ist der aktuelle Kontext
Der Kontext der Applikation entspricher dem Standardkontext

  inv-DBCONTEXT((contextcnt,currcontext,defcontext,  

        		 appcontext,contextmap))  =   

        ¯
        		  (0    dom contextmap) AND   

        		  (contextcnt    mk-INTG(0)) AND   

        		  (defcontext = contextmap(currcontext)) AND   

        		  (appcontext = defcontext)   

         type inv-DBCONTEXT:DBCONTEXT    BOOL

DSL-Spezifikation

Abschließend ist der Anteil der formalen Definition, der für die vorliegende Arbeit verwendet wurde, als Auszug von Inhalten der Datei dbm.vdm, welche die Definitionen des Datenbankmanagers in Form der Domain Specification Language enthält, wiedergegeben. Als Metasprache ist dies die (aus erwähnten Gründen nur ungefähre) maschinenlesbare Umsetzung der VDM Spezifikation des vorangegangenen Abschnitts.

=

:: :

:

:

:

:

:

:

:

:

:

=

Implementation

=

=

=

Definition von Benutzeragenten

Als Benutzeragent wird der Codeabschnitt des Servers definiert, der durch das Umschalten des Kontext eingegrenzt wird, über eine eigenständige Umgebung verfügt, und insbesondere die Bearbeitung von Fehlern auf diesen Bereich reduziert. Für jeden Anmeldevorgang wird ein Benutzeragent eingerichtet, der den Klienten für die gesamte Lebensdauer betreut. Er ist damit aus Sicht des Klienten der einzigste Ansprechpartner auf Serverseite.

[ Inhalt ] [ Index ]

Definition der HTML-Generierungsprozesse

Systemdefinition

VDM Class Library

	:: ContextCounter CurrentContext DefaultContext ApplicationContext ContextMap

	=

	=

	= Context

	= Context

	=


	::




	:
	:
	:
	:
	:
	:
	:
	:
	:
	:

	=
	=

	=