% PARTOF texte:da/tex/a_home.tex
\chapter{Das Modell der {\em Business Conversations}}
\label{tbc}

In Kapitel \ref{koopis} sind die allgemeinen Grundlagen f"ur kooperative
Informationssysteme beschrieben worden. Dieses Kapitel stellt das
Kooperationsmodell vor, welches in den folgenden Kapiteln die Grundlage der
Kooperation mobiler Agenten bildet. Dabei wird anhand eines Beispiels
verdeutlicht, wie insbesondere dynamische Aspekte der Kooperation durch das
verwendete Modell erfa"st werden.

\section{Grundlagen des Modells}

Das hier beschriebene Kooperationsmodell folgt dem Kooperationsleitbild,
das bereits in Abschnitt \ref{koopleitbild} dargestellt wurde.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/langacti.eps}}
\caption{Kommunikation nach der Language/Action Perspektive}
\label{lang-acti}
\end{figure}

Das Modell der {\em Business Conversations} bildet einen Rahmen f"ur die
anwendungsnahe Modellierung von Informationssystemen auf der Grundlage von
Sprechakten. Es definiert eine Terminologie und eine Semantik, mit der
Informationssysteme aus der Sicht von Sprechakten modelliert und spezifiziert
werden k"onnen. Dabei orientiert es sich begrifflich an der Dom"ane der
Gesch"aftsprozesse und erfa"st neben den statischen Aspekten eines Dienstes
gleicherma"sen die dynamische Interaktion von Kunde und Dienstleister "uber die
Zeit.

Basis des Modells ist die Annahme, da"s die Kommunikationsmuster der
Sprechakte universell sind, d.h. sie sind von Art der Akteure (Software,
Menschen) und von den verwendeten Kommunikationsmedien und -protokollen
unabh"angig.

Sowohl die Interaktion zwischen menschlichen Aktueren, als auch die Interaktion
zwischen Menschen und maschinellen Akteuren oder gar die Interaktion zwischen
zwei maschinellen Akteuren ist innerhalb des Modells transparent.

Das Modell der {\em Business Conversations} beschreibt die zielgerichtete
Kommunikation zwischen zwei Akteuren, die in den Rollen Kunde und Dienstleister
handeln.

Dabei basiert das Modell auf der Theorie der {\em Conversations for Action
(CfA)}\footnote{Siehe Abschnitt \ref{koopleitbild}}, da"s eine Kommunikation
mit dem Ziel einer Aktion zwischen einem Kunden und einem Dienstleister in einen
Zyklus mit vier Phasen unterteilt werden kann. Diese Phasen sind in der
Abbildung \ref{lang-acti} zu sehen.

Die Beziehung zwischen einem Kunden und einem Dienstleister folgt danach immer
dem dort skizzierten Ablauf: Im ersten Schritt wird der Kunde beim Dienstleister
unverbindlich nach einer Dienstleistung anfragen.
Am Ende dieses Schrittes steht dann, in der {\em "Ubereinkunfts}-Phase,
die Verhandlung mit dem Dienstleister, einen gew"ahlten Dienst tats"achlich
verbindlich zu erbringen. Das Erbringen der vereinbarten Leistung geschieht in
der dritten Phase, an deren Ende aus der Sicht des Dienstleisters die geforderte
Leistung erbracht ist. In der vierten Phase, der {\em R"uckmeldung}, wird der
Kunde dem Dienstleister mitteilen, ob die erbrachte Leistung seinen
Anforderungen entspricht.

Nur wenn auch diese Phase erfolgreich abgeschlossen ist, ist das gemeinsame Ziel
von Kunde und Dienstleister, und damit das Ziel ihrer Kommunikation, erreicht.
Der Austausch von Sprechakten innerhalb dieser vier Phasen wird unter dem
Begriff der {\em Konversation} zusammengefa"st, der sich damit immer auf einen
konkreten Gegenstand, die Dienstleistung oder Aktion, bezieht.

Der Zyklus kann durch den Verzicht auf einzelne Phasen vereinfacht werden,
wenn die betrachtete Kunde-Dienstleister-Beziehung dies erlaubt. Zum Beispiel
k"onnen die Phasen {\em Anfrage} und {\em "Ubereinkunft} zusammengefa"st werden.
Dabei bleibt jedoch sowohl die Reihenfolge der Phasen als auch der Zyklus
erhalten.

\subsection{Einordnung}

Das Modell der {\em Business Conversations} erg"anzt bereits etablierte
Modelle (wie z.B. Mainstream Objects, Entity-Relationship-Modell), welche die
Modellierung von Informationssystemen nach {\em innen} gestatten (siehe Abb.
\ref{IS-Modellierung}). Diese Modelle k"onnen aus der Sicht einer Anwendung als
systemnahe Modelle bezeichnet werden. Sie strukturieren Systemkomponenten {\em
bottom-up} und daten- bzw. objektzentriert, d.h. auf Objekt oder
Entit"atsebene.

Die Business Conversations hingegen stellen den kooperativen Charakter eines
Informationssystems in den Vordergrund. Durch die Betrachtung der von dem
System nach {\em au"sen} erbrachten Dienstleistungsprozesse wird eine
{\em anwendungs}nahe Modellierung des Systems unterst"utzt.
Hierdurch wird der Abstand zwischen der realen Welt und ihrer Abbildung durch
Informationssysteme verkleinert. Das Modell versucht nicht,
Informationssysteme auf der Ebene von Objekten oder Klassen zu
beschreiben. Vererbungs-, Aggregations- oder Generalisierungsbeziehungen von
Objekten innerhalb des betrachteten Informationssystems m"ussen durch andere,
auf diesen Zweck spezialisierte Modelle beschrieben werden.

\begin{figure}[btp]
\centerline{\epsfbox{bilder/tbcworld.eps}}
\caption{Modellbildung f"ur Informationssysteme}
\label{IS-Modellierung}
\end{figure}

Das Informationssystem ``WebSiteProfiler'' zum Beispiel, das in Kapitel
\ref{wsp-msa} detailliert vorgestellt wird, ist unter Verwendung mehrere Modelle
entworfen worden. Mit Hilfe eines Entity-Relationship-Modells wurde die
Darstellung der Daten in einem Datenbankschema beschrieben. Das Ergebnis dieses
Schrittes ist in Abschnitt \ref{wsp-db} zu sehen. Damit ist eine datenzentrierte
Darstellung des WebSiteProfilers erreicht. Jedoch kann mit diesem Ergebnis noch
nichts "uber Programmabl"aufe innerhalb des WebSiteProfilers ausgesagt werden.
Antworten auf die Fragen, ob und wie mehrere Benutzer mit dem System
gleichzeitig arbeiten k"onnen, welche Aufgaben nebenl"aufig ausgef"uhrt werden
k"onnen oder welche Reihenfolge in einzelnen Funktionen eingehalten werden mu"s,
kann man mit dem Modell der {\em Mainstream Objects} aus Anhang \ref{MainsObj}
geben. Dieses Modell bietet eine objektzentrierte Darstellung des Systems. F"ur
die Modellierung der kooperativen Eigenschaften der Anwendung, die die
Integration des Systems in einen Gesamtzusammenhang erlauben, wird das Modell
der Business Conversations benutzt.

\section{Konzepte des Modells}
\label{Conversations}

Ein integraler Bestandteil des {\em Business Conversation}-Modells ist ein
vereinbartes Verarbeitungsmodell, das die Interaktion zwischen zwei
Partnern definiert und ihre jeweiligen Rollen innerhalb der Interaktion, d.h.
innerhalb eines Gespr"achs, festlegt. Dieses Verarbeitungsmodell mu"s von beiden
Gespr"achspartnern eingehalten werden, um den korrekten Fortgang des Gespr"achs
zu gew"ahrleisten.

\subsection{Das Verarbeitungsmodell von Konversationen}
\label{verarbeitungsmodell}
In einer Konversation wird jede zielgerichtete Interaktion (d.h. jeder
m"ogliche Sprechakt der {\em Language/Action Perspective}) mit {\em Dialogen}
realisiert. Mit Hilfe dieser Dialoge werden Informationen so strukturiert, da"s
der jeweilige Kommunikationspartner die im Sprechakt enthaltene Information
seinem eigenen Ausf"uhrungskontext zuordnen kann.

Dialoge verhalten sich wie Formulare in der realen Welt: ihre
Struktur ist festgelegt und durch den Verwendungszweck bedingt. In den durch die
Struktur gesetzten Grenzen k"onnen sie allerdings von allen beteiligten
Partnern genutzt werden, sei es durch Ausf"ullen der vorgegebenen Freifelder
oder durch Inspektion des vorhandenen Inhalts. Durch Formulare werden von der
ausgebenden Seite m"ogliche Folgeaktionen impliziert, die mit dem Formular in
direktem Zusammenhang stehen. Auf diese Weise repr"asentiert ein Formular einen
bestimmten Punkt in einer l"angeren Beziehung zwischen zwei Partnern, der
Schl"usse auf g"ultige Fortsetzungen der Beziehung in die Zukunft erm"oglicht.

Jeder Dialog beschreibt daher einen Zustand in einer {\em Konversation} zwischen
einem Kunden und einem Dienstleister. Im Gegensatz zur zeitlich ausgedehnten
Konversation besitzt ein Dialog keine nach au"sen sichtbaren Zwischenzust"ande.

Zustands"uberg"ange, d.h. der Beginn eines neuen Dialogs innerhalb einer
Konversation, werden durch Auswertung und Verarbeitung (die {\em Aktion}) einer
Anfrage des Kunden beim Dienstleister durchgef"uhrt.

Dabei ist der Kunde derjenige Akteur, welcher den Zeitpunkt des
Zustands"uberganges bestimmt: indem er eine Anfrage an den Dienstleister
stellt, f"uhrt dieser seine mit der Anfrage assoziierte Bearbeitungsregel aus
und generiert einen neuen (Antwort-)Dialog f"ur den Kunden.

Die Menge der m"oglichen Anfragen, die ein Kunde ausgehend aus einem Zustand
einer Konversation an einen Dienstleister richten kann, ist durch den Dialog
bestimmt, welcher den aktuellen Zustand der Konversation repr"asentiert. Dies
entspricht in der Formularanalogie der M"oglichkeit, in einem
vorgegebenen Formular einen Kundenwunsch ankreuzen zu k"onnen.

Es sind dar"uber hinaus genau zwei Anfragen definiert, die nicht in der Menge
der Anfragen enthalten sind, die ein Dialog explizit vorgibt:

\begin{itemize} 

\item Die initiale Anfrage: Ein Kunde mu"s eine Konversation mit einem
Dienstleister beginnen k"onnen, ohne sich vorher bereits in einer
Konversationsbeziehung mit ihm zu befinden. In diesem Fall kann der Kunde genau
eine Anfrage an den Dienstleister stellen, n"amlich die nach der Er"offnung der
Konversation. Die Spezifikation dieser Anfrage und der zug. initiale Dialog wird durch $S_{0}$ bezeichnet und ist Teil des {\em Business Conversation}-Systems.

\item Eine spezielle Anfrage nach dem Abbruch der Konversation:
Diese Anfrage l"ost ein Kunde implizit aus, wenn er eine von
Dienstleister vorgegebene Zeitspanne lang keine Anfrage an den
Dienstleister stellt. Tats"achlich ist dies keine wirklich vom Kunden stammende
Anfrage, sondern wird vom System des Dienstleisters im Namen des Kunden
generiert. Au"serdem ist dem Kunden der explizite Abbruch der Konversation
erlaubt. Die Spezifikation dieser Anfrage bzw. des Dialogs wird durch $S_{Exc}$ bezeichnet und ist ebenfalls Teil des {\em Business Conversation}-Systems.

\end{itemize}

\begin{figure}[bt]
\begin{center}
\begin{tabular}{rrll}
Kunde (initial):&{\sl $d_{0}$}&${\rightarrow}_{f_{0}}$& $(d_{0}, r_{0})_{\in S_{0}}$
\\
&  \quad \\
Dienstleister:&  $(d_{n}, r_{m})_{\in S_{k} \cup S_{Exc}}$ & ${\rightarrow}_{f_{n,m}}$ &
${d_{p}}_{\in S_{k} \cup S_{Exc}}$ \\
Kunde: & ${d_{n}}_{\in S_{k} \cup S_{Exc}}$ & ${\rightarrow}_{f_{n}}$ & $(d_{n}, r_m)_{\in
S_{k} \cup S_{Exc}}$ \\
\end{tabular}
\end{center}
\caption{Das Verarbeitungsmodell als Ereignis-Aktions-Paare} \label{rules}
\end{figure}

Eine Konversation zwischen einem Kunden und einem Dienstleister wird mit diesen
Mechanismen auf eine festgelegte Abfolge von Dialogen und Anfragen "ubertragen.
Der Dienstleister gibt dabei jeweils einen Dialog vor, den der Kunde erh"alt und
so bearbeiten kann. Der Kunde ist jedoch immer der {\em Initiator} einer Konversation und der Dienstleister der {\em Akzeptor}.

Auf diese Weise werden Ketten aus Ereignissen und Aktionen \cite{DHL90}
gebildet. Die beiden Partner der Konversation definieren Bearbeitungsregeln, mit
denen sie auf die Ereignisse des jeweils anderen Partners reagieren und
dadurch Aktionen ausf"uhren. Abbildung \ref{rules} zeigt das formalisierte
Verarbeitungsmodell. 

Die g"ultigen Transitionen einer Konversation, wie sie durch die Regeln implementiert wird, ist durch eine zugeh"orige Spezifikation bestimmt (siehe auch Abschnitt \ref{kspecs}).  

\begin{figure}
F"ur das Verarbeitungsmodell ist eine Spezifikation $S_l$ definiert durch die Dialogmengen $D, D^\ast$, die Menge von Anfragen $R$ und die Transitionsrelation E. 

\begin{quote}
$S_{l} := (D, R, E, d_{0}, D^\ast)$
\end{quote}
mit
\begin{quote}
$E \subseteq D \times R \times D$,$d_{0} \in D$,$D^\ast \subseteq D $ 
\end{quote}
\end{figure}

Der ausgezeichnete Dialog $d_0$ ist der Startdialog einer Konversation und die Menge $D^\ast$ bezeichnet die Menge der finalen Dialoge einer Konversation. 

Menschliche Akteure simulieren Kundenregeln, indem sie den Inhalt der Dialoge
$d_{i}$ lesen und gem"a"s ihren W"unschen ver"andern. Maschinelle Kunden besitzen einen Programmkode f"ur die Regeln, der die Dialoge entsprechend der kodierten Vorschrift interpretiert bzw. manipuliert.
Die Regeln ${f_{i}}$ des Kunden enden immer mit der "Ubermittlung des eventuell
ver"anderten Dialogs zusammen mit einer Anfrage $r_{k}$. 

Ebenso mu"s der Dienstleister auf die Dialoge und Anfragen des Kunden entsprechend einer Regel ${f_{i,k}}$ reagieren. Seine Aktion endet immer damit, da"s er einen neuen Dialog, den er bei Bedarf vorher mit inhaltlichen Vorgaben gef"ullt hat, an den Kunden "ubermittelt. Durch die wechselseitige Ausf"uhrung einer Kundenregel und einer Dienstleisterregel wird jede Konversation gem"a"s der zugrundeliegenden Spezifikation $S_{j}$ systematisch entwickelt.

Innerhalb einer Konversation kann ein Dienstleister, dann jedoch in der Rolle eines Kunden, eine weitere Konversation mit einem anderen Dienstleister initiieren, sofern das zur Ausf"uhrung seiner Bearbeitungsregel notwendig ist. Dieses f"uhrt zum Konzept der {\em sekund"aren Konversation}.

\subsection{Sekund"are Konversationen und Subkonversationen}

Mit der Technik der sekund"aren Konversation ist eine Mischform der Beziehung
zwischen Kunde und Dienstleister m"oglich (siehe Abbildung \ref{SubKonv}). Dabei
wird der Dienstleister $A_{1}$ innerhalb einer Konversation mit einem Kunden
$A_{2}$ selbst zum Kunden eines weiteren Dienstleisters $A_{3}$.

\begin{figure}[thb]
\centerline{\epsfbox{bilder/subconv.eps}}
\caption{Verfeinerung mittels sekund"aren Konversationen}
\label{SubKonv}
\end{figure}

Synchrone sekund"are Konversationen unterbrechen die initiierende prim"are
Konversation f"ur die Dauer ihrer Ausf"uhrung. Sie bilden damit eine
eingeschobene Konversation, bei der ein impliziter Rollenwechsel des Akteurs
stattfindet. Wird eine sekund"are Konversation asynchron ausgef"uhrt, ist keine
Unterbrechung der prim"aren Konversation notwendig. Eine asynchrone sekund"are
Konversation verh"alt sich wie eine prim"are, kann jedoch die "ubergeordnete
Konversation {\em verz"ogern}, wobei die Atomarit"at der Bearbeitungsregel
aufgehoben wird.

Subkonversation erlauben einem Kunden $A_{1}$ die direkte Kommunikation mit einem
Dienstleister $A_{3}$ , obwohl die Konversationsbeziehung zwischen dem Kunden
$A_{1}$ nur zu einem Dienstleister $A_{2}$  besteht. Die Konversation zwischen
$A_{1}$ und $A_{3}$ wird dabei im Namen von $A_{2}$ gef"uhrt, so da"s dieser
die M"oglichkeit besitzt, in den Konversationsablauf einzugreifen.

\subsection{Finale Dialoge}

Jede Konversation besitzt eine definierte Menge von {\em finalen} Dialogen, die
sie erreichen kann. Jeder Dialog ohne einen Folgedialog, d.h. ohne eine
m"ogliche ausgehende {\em Anfrage}, ist ein finaler Dialog der Konversation.
Die Konversationsbeziehung zwischen den beteiligten Partnern wird bei Erreichen
eines solchen Dialogs beendet.

Das Modell definiert einen Finaldialog f"ur das erfolgreiche Ende jeder
Konversation (d.h. sowohl Kunde als auch Dienstleister best"atigen das
erfolgreiche Erreichen des gemeinsamen Ziels) sowie einen finalen Fehlerdialog.
Dieser Fehlerdialog ist implizit von jedem Dialog einer Konversation
aus erreichbar, ohne da"s dies in der Spezifikation vermerkt werden mu"s. Dieser
Dialog bietet die M"oglichkeit, Ausnahmebehandlungen in den Bearbeitungsregeln
f"ur Konversationen vorzusehen. Eine solche Ausnahme kann von beiden Partnern
jederzeit in einer Konversation ausgel"ost werden. Die entsprechende zugeh"orige
Anfrage, mit der der Kunde den "Ubergang in einen Ausnahmezustand anzeigt, wird
durch das Modell definiert.

Die Entscheidung, unter welchen Umst"anden welcher Dialog welcher Phase aus
Abbildung \ref{lang-acti} zugeordnet wird, ist eine Designentscheidung bei der
Anwendungsentwicklung. Das Phasenmodell kann von einer Anwendung genutzt
werden, um Punkte innerhalb einer Konversation mit dem Partner zu
vereinbaren, mit deren Erreichen beide Partner verbindliche Aussagen
"uber den Gespr"achsverlauf treffen.

Das Modell der Business Conversations verwendet zwei Beschreibungsebenen f"ur
Konversationen, die im Folgenden getrennt vorgestellt werden:

\begin{itemize}

\item Die Ebene der {\em Konversationsspezifikationen}: Auf dieser Ebene wird
die Struktur m"oglicher Konversation definiert. Diese Ebene entspricht der
Typebene einer Programmiersprache, mit dem Unterschied, da"s
Konversationsspezifikationen eine Laufzeitrepr"asentation besitzen.
Konversationsspezifikationen bilden Fabriken (engl. {\em factories}), welche die
Erzeugung von Konversationen, ihren Instanzen, steuern.

\item Die Ebene der {\em Konversationensinstanzen}: Gegenstand dieser Ebene
sind konkrete Konversationen, die zwischen einem Kunden und einem Dienstleister
stattfinden. Konversationen sind immer konform zu einer zugeh"origen
Konversationsspezifikation. Sie werden anhand dieser Spezifikation erzeugt und
sind an ein Kunde-Dienstleister-Paar gebunden.

\end{itemize}

\subsection{Konversationsspezifikationen}
\label{kspecs}

Die Abbildung \ref{tbcspec} zeigt ein Modell f"ur Spezifikationen von
Konversationen. Das Diagramm ist in der Notation der Mainstream Objects, die im
Anhang \ref{MainsObj} erl"autert wird, dargestellt. Alle Begriffe aus dem Modell
werden im Glossar im Anhang \ref{tbc-glossar} in ihrer deutschen und englischen
Schreibweise erl"autert.

Konversationsspezifikationen legen fest, welche Struktur Konversationsobjekte
im Falle einer Instantiierung haben sollen. Sie umfa"st dabei sowohl den
statischen Teil einer Konversation, d.h. die Datenmodellierung f"ur den
Informationsaustausch, als auch den dynamischen Teil der Beziehung zwischen
Kunden und Dienstleistern, die Proze"smodellierung.

Spezifikationen sind inspizierbar, d.h. beide Partner k"onnen untersuchen, ob
die Konversation in ihren jeweiligen Kontext und zu ihrer Sicht des
Kooperationsziels pa"st.

\begin{figure}
\centerline{\epsfbox{bilder/tbcmod2.eps}}
\caption{Spezifikationen von Konversationen, Dialogen und Inhalten}
\label{tbcspec}
\end{figure}

Nach diesem Modell enth"alt jede Konversationsspezifikation mehrere abstrakte
Dialogspezifikationen. Eine Dialogspezifikation ist als initialer Dialog
ausgezeichnet, jede Konversation beginnt mit diesem Dialog\footnote{Aussagen
zur initialen Anfrage siehe Abschnitt \ref{verarbeitungsmodell}.}. Die
abstrakten Dialogspezifikationen bestehen entweder aus Spezifikationen von
Sub-Konversationen oder von (konkreten) Dialogen. Mit den Spezifikationen von
Sub-Konversationen werden Konversationsspezifikationen als Dialogspezifikationen
in anderen Konversationsspezifikationen wiederverwendet. Dazu k"onnen sie auf
geeignete Art und Weise mit dem {\em Modifier} ver"andert werden.
Dialogspezifikationen bestehen aus Inhaltsspezifikationen und Spezifikationen
f"ur Anforderungen. Jede Anforderungsspezifikation ist "uber die {\em
replies-with Beziehung} mit der Spezifikation des nachfolgenden Dialogs
verbunden. Die Markierung {\em ellpises} zeigt an, da"s sich die Aktion, die
beim Dienstleister auf die Auswertung des Dialoges folgt, "uber mehrere Dialoge,
deren Spezifikation nicht sichtbar ist, hinziehen kann.

Die Inhalte k"onnen auf verschiedene Art und Weise spezifiziert werden. Zum
einen gibt es einfache Basistypen wie ganze Zahlen, rationale Zahlen,
Zeichenketten, einen Datumstyp und einen Spezifikationsobjekttyp. Komplexe
Inhalte k"onnen mit Records, Varianten, Auswahllisten oder Sequenzen modelliert
werden, wobei auch verschachtelte Inhalte zugelassen sind. F"ur alle
Inhaltstypen existieren Operationen zum Erzeugen der entsprechenden
Spezifikationsobjekte. Die Operationen auf den Spezifikationsobjekten sind in
der Abbildung aus Gr"unden der "Ubersichtlichkeit nicht dargestellt.

Auf der Ebene der Konversationsspezifikationen k"onnen Meta-Dienste erstellt
werden, die auf diesen Spezifikationsobjekten operieren. In erster Linie sind
das grafische Editoren oder Anzeiger, Modellverifikatoren, Spezifikationsmakler
und "ahnliches mehr. Wichtiger Nutzen der Spezifikationen ist ihre
"Uberpr"ufbarkeit, durch die eine gesicherte maschinelle Abwicklung von
Konversationen unter Beibehaltung der Autonomie der Partner erm"oglicht wird.

Alle Spezifikationen sind Objekte erster Klasse, sowohl in der
Implementationssprache als auch im eigenen Typsystem. Sie k"onnen somit benannt,
gespeichert oder verschickt werden und besitzen eine Laufzeitrepr"asentation.

In Anhang \ref{Spec-Grammar} findet sich die Grammatik f"ur die Konstruktion
von Konversationsspezifikationen gem"a"s dem dargestellten Modell aus Abbildung
\ref{tbcspec}.

\subsection{Konversationsinstanzen}
\label{conv-inst}

\begin{figure}
\centerline{\epsfbox{bilder/tbcinst.eps}}
\caption{Instanzen von Konversationen, Dialogen und Inhalten}
\label{tbcinst}
\end{figure}

Die Abbildung \ref{tbcinst} zeigt den Aufbau von Instanzen von Konversationen
und den Zusammenhang mit Spezifikationen.

\begin{figure}[bt]
\centerline{\epsfbox{bilder/cont-ins.eps}}
\caption{Instanzen der Inhaltsspezifikation}
\label{cont-inst}
\end{figure}

Von einer Konversationsspezifikation k"onnen beliebig viele Konversationen
instantiiert werden. Jede Konversation befindet sich zu einem Zeitpunkt in einem
Quadranten der Ellipse aus Abbildung \ref{lang-acti}. Sie erlaubt den Zugriff
auf den aktuellen Dialog ({\em current-dialog Beziehung}) und enth"alt eine
Liste von vergangen Dialogen, die durch {\em History-Element Objekte}
dargestellt werden. Mit den abstrakten Dialogen werden wie bei den
Spezifikationen Subkonversationen und konkrete Dialoge modelliert. Jeder Dialog
wird durch eine Dialogspezifikation inhaltlich vorgegeben. Aus dem Dialog heraus
ist der Inhalt, der aus der Spezifikation erzeugt wurde, erreichbar. Die
Objektstruktur f"ur die Instanzen der Inhaltsspezifikationen sind in der
Abbildung \ref{cont-inst} zu sehen. F"ur jeden Inhalttyp sind bestimmte
Operationen definiert:

\begin{itemize}

\item Der Zustand der Objekte atomarer Typen kann gelesen und gesetzt werden.

\item In Listenobjekten f"ur eine einfache Auswahl ({\em single choice}) k"onnen
die Alternativen gesetzt werden, man kann alle Alternativen auslesen und genau
eine davon ausw"ahlen. Au"serdem kann die gew"ahlte Alternative bestimmt werden.

\item In Listenobjekten f"ur mehrere Wahlm"oglichkeiten ({\em multiple choice})
enth"alt der Zustand beliebig viele Selektionen. Zus"atzlich zu den Operationen
bei Listenobjekten mit einfacher Auswahl k"onnen gew"ahlte Alternativen wieder
deselektiert werden.

\item In einem Record-Objekt k"onnen die aggregierten Inhaltsobjekte
"uber ihren Namen referenziert werden.

\item In einem varianten Record-Objekt k"onnen zus"atzlich gekapselte Varianten
ausgew"ahlt oder die Auswahl gelesen werden.

\item Die durch Objekte des Sequenztyps aggregierten Objekte sind nicht direkt
in das Dialogobjekt eingebunden. Stattdessen stellen Sequenz-Objekte
Methoden f"ur den Zugriff auf Massendatenbest"ande durch Klienten zur
Verf"ugung. Die Erzeugung von Sequenzobjekten erfordert die Konkretisierung der
von der Objektschnittstelle geforderten abstrakten Zugriffsfunktionen auf
den Datenbestand, der von der Sequenz repr"asentiert werden soll.

\end{itemize}

\section{Invarianten des Modells}

Die folgenden Invarianten sollen Interpretationsm"oglichkeiten innerhalb des Modells
einschr"anken. Ziel ist es, m"oglichst viele Punkte eindeutig festzulegen.

\begin{enumerate}

\item Alle Dialogspezifikationen einer Konversationsspezifikation haben
verschiedene Namen. Alle benannten Inhaltsspezifikationen einer
Dialogspezifikation haben verschiedene Namen. Alle Anfragespezifikationen einer
Dialogspezifikation haben verschiedene Namen.

Die Namen der Objekte dienen in ihren jeweiligen Sichtbarkeitsbereichen als
Schl"ussel zur Identifikation.

\item Jede Konversationsspezifikation hat eine finale Dialogspezifikation mit
dem Namen {\em breakdown}.

Damit bleibt jede Konversation auch in Ausnahmef"allen in einem gesicherten
Zustand. Es kann keine unvorhergesehenen Konfigurationen geben.

\item Jede Dialogspezifikation mit dem Namen {\em breakdown} hat benannte
Inhaltsspezifikationen mit den Namen {\em lastDialog}, {\em reason}.

Damit kann aus der Abbruchsituation sp"ater der Grund f"ur den Abbruch, sowie
der letzte erfolgreich bearbeitete Dialog, rekonstruiert werden.

\item Alle finalen Dialogspezifikationen haben keine Folgedialoge und deswegen
keine Anfragespezifikationen.

Wird ein solcher finaler Dialog in einer Konversation erreicht, so wird diese
bei beiden Partnern beendet.

\end{enumerate}

\section{Ein Anwendungsbeispiel}

\label{wsp-beispiel}

\begin{figure}[bt] 
\centerline{\epsfbox{bilder/wsp-tbc.eps}} 
\caption{Konversationsspezifikation f"ur den WSP} 
\label{wspkonvspec} 
\end{figure}

Die Kooperationsschnittstelle des WebSiteProfilers, der im Abschnitt \ref{WSP}
n"aher beschrieben wird, soll an dieser Stelle die Verwendung des
Konversationsmodells illustrieren. Seine Funktionalit"at, soweit f"ur diesen
Abschnitt erforderlich, besteht im Wesentlichen in der Erstellung verschiedener
Statistiken "uber die Nutzung von WWW-Servern im Internet.

Um den WebSiteProfiler in das Modell einzuf"ugen, mu"s der Programmierer eine
Konversation eines Benutzers mit dem Programm entwerfen und spezifizieren.
Dabei tritt der WebSiteProfiler in der Rolle des Dienstleisters auf.

Eine denkbare Dialogfolge und ihre Umsetzung in eine Konversationsspezifikation
ist in der Abbildung \ref{wspkonvspec} aufgezeigt.

Der initiale Dialog der spezifizierten Konversation dient der Autorisierung
m"oglicher Benutzers des Informationssystems.

In diesem Dialog sind Objekte zur Aufnahme seines Namens und des zugeh"origen
Pa"swortes vorgesehen. Zus"atzlich zu diesen beiden Objekten ist ein Objekt f"ur
Nachrichten an den Benutzer als Inhaltsspezifikation in der Dialogsspezifikation
eingetragen.

Die aus diesem Dialog m"ogliche Anfrage des Kunden ist lediglich: {\sl
``anmelden''}\footnote{Implizite Anfragen und Ausnahmen werden in diesem
Beispiel nicht ber"ucksichtigt.}.

Dabei wird der in der Spezifikation enthaltene Nichtdeterminismus durch die
f"ur diesen Dialog angegebene Bearbeitungsregel des WebSiteProfiles, abh"angig
vom Zustand der Inhaltsobjekte, aufgel"ost.

Nach erfolgreicher Anmeldung kann der Benutzer ausw"ahlen, ob er neue
Statistiken erstellen, das Archiv einsehen oder die aktuelle
Zugriffsprotokolldatei in die Datenbank "ubernehmen m"ochte. In diesem Dialog
sind keine Inhaltsobjekte vorgesehen.

In dem Dialog ``Neue Statistiken'', der aus dem Dialog ``T"atigkeitswahl'' mit
der Anfrage ``neue Statistiken ansehen'' erreicht wird, kann der Kunde die
Parameter seiner gew"unschten Auswertung eintragen. Dabei "andert dieser
destruktiv den Zustand der benannten Inhaltsobjekte. Diese Inhaltsobjekte werden
vom Dienstleister, anhand der Dialogspezifikation ``Neue Statistiken'', erzeugt.

Die Ergebnisse einer Auswertung werden dem Kunden im Dialog ``Ergebnisse''
pr"asentiert, der wiederum durch den Kunden ausgewertet werden mu"s.

W"ahlt der Kunde in diesem Dialog die Anfrage ``beenden'', so endet die
Konversation bei beiden Partnern. Andernfalls wird sie im Zustand
``T"atigkeitswahl'' fortgesetzt.

Durch die Schleife in der Konversationsspezifikation sind
langandauernde Beziehungen zwischen einem Kunden und einem Dienstleister
modellierbar.

In jedem Dialog hat der Kunde die M"oglichkeit, die Konversation mit der
system"ubergreifend definierten Anfrage {\em ``breakdown''} zu beenden. Auch der
Dienstleister kann seinerseits die Konversation vorzeitig beenden. Zu diesem
Zweck mu"s er dem Kunden den ebenfalls system"ubergreifend definierten, finalen
Dialog {\em ``breakdown''} "ubermitteln.

Wenn die Konversation erfolgreich abgeschlossen wurde, wird der Dialog
``terminated'' an den Kunden zugestellt.

Auf der Basis dieser Spezifikation wird jetzt f"ur jede durchzuf"uhrende
Konversation eine Instanz erzeugt. Diese Konversationsinstanz bindet einen
speziellen Kunden mit einem speziellen WebSiteProfiler und einer eigenen
Vergangenheit. Jeweils eine solche Konversationsinstanz befindet sich auf der
Seite des Kunden und auf der Seite des Dienstleisters. Die zur Instantiierung
notwendige Spezifikation mu"s ebenfalls auf beiden Seiten vorhanden sein.

Ein Beispiel f"ur eine Formulierung einer Dialogspezifikation aus der Abbildung
\ref{wspkonvspec} findet man in der Abbildung \ref{ergebnissedialogspec}.

\begin{figure}[bt]
\begin{xple}
\begin{tabbing}
\hspace*{1cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
\>{\k DIALOG} Ergebnisse {\k STAGE} 3 {\k WITH}\\
\>\>{\k REQUEST}\\
\>\>\>Weitere Statistiken {\k TO} Taetigkeitswahl {\k NOELLPISES} \\
\>\>{\k END} \\
\>\>{\k REQUEST} Beenden {\k TO} Beendet {\k NOELLIPSES} {\k END}\\
\\
\>\>{\k CONTENT} Ergebnisliste {\k OF}\\
\>\>\>{\k SEQ OF}\\
\>\>\>\>{\k SEQ OF}\\
\>\>\>\>\>{\k REC}\\
\>\>\>\>\>\>unit {\k OF INT}\\
\>\>\>\>\>\>count {\k OF INT}\\
\>\>\>\>\>{\k END}\\
\>\>{\k END}\\
\>{\k END}\\
\end{tabbing}
\end{xple}

\caption{Spezifikation f"ur den Dialog mit Ergebnisstatistiken}
\label{ergebnissedialogspec}
\end{figure}
