\chapter{Das Modell der Business Conversations}



\label{tbc}



Nachdem in Kapitel \ref{wsp-msa} ein Beispiel f"ur eine kooperative Anwendung

vorgestellt wurde, soll in diesem Kapitel ein Modell f"ur eine Umgebung

kooperativer

Anwendungen dargestellt werden. Dieses Modell wird im folgenden erl"autert.

Au"serdem wird der dynamische Aspekt der Kooperation beschrieben und anhand eines

Beispiels verdeutlicht.



\section{Die Motivation f"ur das Modell}



Kooperative Informationssysteme bestehen in Anlehnung an 

"`Cooperative Information Systems: A Manifesto"' \cite{koopis-mani96} aus

zahlreichen Systemen, die "uber weite und komplexe

Netzwerke verteilt sind. 

Kooperation bedeutet, da"s mehrere Akteure auf ein gemeinsames Ziel hinarbeiten.

Generell verhalten sich 

Akteure kooperativ, wenn sie mit anderen Akteuren ihrer Umgebung Ziele 

teilen, um sie gemeinsam zu erreichen. 

Dazu m"ussen sie Informationen austauschen. 



Nachfolgend sollen auch Computersysteme als Akteure, die bestimmte T"atigkeiten

verrichten, betrachtet werden. Sie k"onnen zum Beispiel einen Bericht drucken

oder Informationen

bereithalten. Dabei kann das erforderliche Informationssystem als Ziel

betrachtet werden. Wenn das Ziel in der Umgebung des Systems mit anderen

Akteuren geteilt wird, und das Informationssystem einen positiven Beitrag zum Erreichen des Ziels

leistet, spricht man von einem {\em kooperativen} Informationssystem.

Zus"atzliche Voraussetzungen sind die M"oglichkeiten zum Informationssaustausch

und da"s andere Systeme auf die Funktionalit"at des Informationssystems

zugreifen k"onnen.



Kooperative Informationssysteme unterst"utzen die "Anderungen der Anforderungen

an das System und  des

Systems selbst "uber lange Zeitr"aume hinweg.

Sie sollen eine Abbildung des

Gesch"aftsmodells eines Unternehmens auf das Systemmodell erm"oglichen. 

In \cite{koopis-mani96} wird f"ur kooperative Informationssysteme eine 

Schichtenarchitektur aus vier Schichten vorgeschlagen.

Die Systemschicht bildet die Basis des Systems. Dar"uber sorgt eine

Systemintegrationsschicht f"ur die Zusammenarbeit verschiedener verteilter

Systeme. Die Arbeitsgruppenschicht und die Unternehmensschicht bilden

organisatorische Aspekte des Unternehmens auf das Informationssystem ab.

Die

Aspekte der Kooperation finden sich in allen vier Schichten des Systems wieder.

Im folgenden wird ein Softwaremodell f"ur die Systemintegrationsschicht

vorgestellt. Es unterst"utzt die Zusammenarbeit autonomer menschlicher oder

maschineller Akteure, indem es einen Rahmen zur Koordination ihrer

langandauernden Aktivit"aten anbietet. Die langandauernden Aktivit"aten zur

Kooperation werden "uber Konversationen (engl. Business Conversations)

modelliert.



Dieses Modell soll h"ohere Modelle der weiteren Systemschichten unterst"utzen.

Dabei handelt es sich in der Arbeitsgruppenschicht um Modelle f"ur

Gesch"aftsprozesse, Workflow-Management oder Unterst"utzung der Gruppenarbeit.

In der Unternehmensschicht beziehen sich die Modelle auf virtuelle Unternehmen,

elektronische Handelssysteme und dezentralisierte Informationsverarbeitung.



Folgt man der Argumentation des Manifesto, soll die Systemintegrationsschicht

den Systemprogrammierer durch die Abstraktion von folgenden Punkten

unterst"utzen:



\begin{enumerate}



\item Kooperation "uber die Zeit. Die Lebensdauer aller maschinellen Akteure 

richtet sich nach der Dauer der Gesch"aftsprozesse, in denen sie eingesetzt

werden. Dabei sind sie unabh"angig

von unterliegenden Systemgr"o"sen wie der Programmiersprache, Lebensdauer der

Betriebssystemprozesse oder Datenbankschemata.



\item Kooperation innerhalb des Raums. Maschinelle Akteure k"onnen

innerhalb einer physikalisch verteilten Umgebung migrieren. Dabei sind sie nicht

von speziellen Systemplattformen oder Organisationsstrukturen abh"angig.



\item Kooperation in mehreren Arbeitsformen. Softwaresysteme sollen f"ur

maschinelle Akteure einheitlich benutzbar sein. Dabei werden die folgenden

Arbeitsformen gleichbehandelt: einfache Stapelverarbeitung,

Transaktionverarbeitung, direkte Manipulation von menschlichen Akteueren mittels

formularbasierter Eingabemasken, rechnerunterst"utzte Zusammenarbeit

menschlicher Akteure, rechnergest"utztes Workflow-Management und automatische

Informationsverarbeitung mittels mobiler Softwareagenten. Ebenfalls sollen

verschiedene Medien auf gleiche Art unterst"utzt werden: E-Mail-Nachrichten,

EDI-Nachrichten, HTTP-Requests, CORBA Object-Requests oder entfernte

Prozeduraufrufe.



\end{enumerate}



Wenn diese Abstraktion gelingt, 

kann sich der Programmierer

auf das {\em was} und {\em wie} des speziellen Problems konzentrieren und 

das {\em wann} (zum Beispiel Stapelverarbeitung, interaktive

Sitzungen oder langandauende Konversationen mit einem Kunden), {\em wo} (zum Beispiel

zentralisierter Hostrechner, Server innerhalbs eines Unternehmens  oder ein

Laptop eines Verkaufsmitarbeiters) und {\em wer} (zum Beispiel Kunde, Verk"aufer,

Workflow-Mangement-System oder Internetagent) vernachl"assigen. Die Applikationen

werden von "uberfl"ussigem Ballast wie Datentransfer, Synchronisation und

Details der Benutzeroberfl"ache befreit, um "Anderungen der Lebensdauer, 

der Systemplattform

oder der Arbeitsform besser als bisher durchf"uhren zu k"onnen.



Die Grundlagen f"ur die ersten beiden Punkte wurden mit dem

plattformunabh"angigen

Tycoon-System und der Entwicklung persistenter, mobiler Threads gelegt. Den

dritten Punkt sollen die folgenden Business Conversations behandeln.




\section{Die Grundlagen des Modells}



\begin{figure}[bt]

\centerline{\epsfbox{bilder/langacti.eps}} 

\caption{Kommunikation nach der Language/Action Perspektive} 

\label{lang-acti} 

\end{figure}



Die Basis f"ur dieses Modell bilden Arbeiten aus dem Bereich des

Computer-Support for Cooperative Work (CSCW) von

Fernando Flores und Terry Winograd und deren Theorie der Sprechakte ({\em

engl.: 

Speech Act Theory, Language/Action Perspective}) \cite{Wino87,FlWi+88}. 

Sie betrachten Sprache als wichtigste Dimension f"ur kooperative

Zusammenarbeit von Menschen.

Eine zentrale These ihres Modells ist, da"s Menschen durch Sprache kooperieren. 

Daraus ergibt sich die {\em Language/Action Perspective} auf die Handlungen der

Menschen. Linguistische Untersuchungen einer Sprache unterscheiden Syntax, 

Semantik und Pragmatik. Die Pragmatik behandelt die Probleme der Benutzung von

Sprache. Ein klassisches Beispiel ist der Satz "`In diesem Raum ist es kalt"'. 

Wenn

ein Herr ihn zu seinem Diener sagt, soll er beim Diener eine Aktion ausl"osen,

zum Beispiel das Fenster zu schlie"sen.



Aus der Perspektive dieses Ansatzes ist die Rolle der Sprache bei der Ausl"osung 

und

Interpretation von Aktionen der wichtigste Aspekt von Untersuchungen.

Eine wichtige Einheit der Kommunikation ist dabei der Sprechakt. Er kann wiederum

in weitere Akte unterteilt werden. 

Die Sprechakte sind alle Teil einer gr"o"seren

Gespr"achsstruktur. Eine wichtige Klasse der Sprechakte sind die einfachen {\em

Conversations for Action}. \cite{Wino87}



Eine

Konversation mit einer Aktion als Ziel koordiniert diese Sprechakte. Durch

Sprechakte vereinbaren die beteiligten 

Kommunikationspartner wechselseitig zuk"unftige Aktionen und bilden eine

gemeinsame Vergangenheit, vor deren Hintergrund neue Sprechakte gebildet und

interpretiert werden.



Das Modell der {\em Business Conversations} bildet einen Rahmen f"ur die

anwendungsnahe Modellierung von Informationssystemen auf der Grundlage solcher

Sprechakte. Es definiert eine Terminologie und eine Semantik, mit der

Informationssysteme aus der Sicht der Sprechakte modelliert und spezifiziert

werden k"onnen. Dabei orientiert es sich begifflich 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.



Kernpunkt des Modells ist die Annahme, da"s die Kommunikationsmuster der

Sprechakte universell sind, d.h. sie sind von Art der Aktoren (Software,

Menschen) und von den verwendeten Kommunikationsmedien und -protokollen (HTTP,

e-Mail, CORBA, \dots) unabh"angig.



Sowohl die Interaktion zwischen menschlichen

Akteuren, 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 in den Rollen Kunde und Dienstleister.

Das Modell basiert auf der Beobachtung, 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 immer dem

skizzierten Ablauf: Erst wird der Kunde beim Dienstleister unverbindlich nach

einer Dienstleistung anfragen. Am Ende dieses Schrittes steht dann die

Verhandlung mit dem Dienstleister, einen gew"ahlten Dienst tats"achlich

verbindlich zu erbringen. Das ist Aufgabe der zweiten Phase, der {\em

"Ubereinkunft}. Das Erbringen der vereinbarten Leistung geschieht in der dritten

Phase. An deren Ende ist aus der Sicht des Dienstleisters die Leistung erbracht.

In der vierten Phase, der {\em R"uckmeldung}, wird der Kunde dem Dienstleister

mitteilen, ob die erbrachte Leistung seinen Anforderungen gerecht geworden ist.

Nur wenn auch diese Phase erfolgreich abgeschlossen ist, ist das gemeinsame Ziel

von Kunde und Dienstleister, und damit das Ziel ihrer Kommunikation, erreicht.

Diese vier Phasen werden in einer Konversation zusammengefa"st.



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 Anfrage und "Ubereinkunft zusammengefa"st werden. Dabei

bleibt jedoch sowohl die Reihenfolge der Phasen als auch der Zyklus

erhalten.



\begin{figure}[bt] 

\centerline{\epsfbox{bilder/tbcworld.eps}} 

\caption{Modellbildung f"ur Informationssysteme} 

\label{IS-Modellierung} 

\end{figure}



Das Modell der {\em Business Conversations} ist komplement"ar zu bereits 

bekannten Modellen

(wie zum Beispiel Mainstream Objects,

Entity-Relationship-Modell), die die Modellierung von

Informationssystemen gestatten (siehe Abb. \ref{IS-Modellierung}). Die Business

Conversations versuchen, durch die Strukturierung von

Dienstleistungsprozessen eine anwendungsn"ahere Modellierung zu unterst"utzen.

Dadurch wird der Abstand zwischen der realen Welt und ihrer Abbildung durch

Computersysteme verkleinert.



Zum Beispiel wurde der WebSiteProfiler mit mehreren Modellen entwickelt. Mit

Hilfe des Entity-Relationship-Modells wurde die Darstellung der Daten in einem

Datenbankschema entworfen. Das Ergebnis dieses Schrittes ist in Abschnitt

\ref{wsp-db} zu sehen. Damit ist die datenzentrierte Darstellung des

WebSiteProfilers gegeben. Jedoch kann mit diesem Ergebnis noch nichts "uber

Programmabl"aufe innerhalb des WebSiteProfilers ausgesagt werden. Antworten auf

die Frage, 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

Mainstream Objects aus Anhang \ref{MainsObj} geben. Damit hat man eine

objektzentrierte Darstellung erhalten. F"ur die Modellierung der Kooperation mit

anderen Systemen wird das Modell der Business Conversations benutzt. 



\section{Die Konzepte des Modells}



\label{Conversations}



Im Modell gibt es zwei Ebenen, die im folgenden getrennt beschrieben werden:



\begin{itemize}



\item Die Ebene der {\em Konversationsspezifikationen}. Auf dieser Ebene wird

die Struktur m"oglicher Konversation beschrieben. Diese Ebene entspricht der

Typebene einer Programmiersprache, mit dem Unterschied, da"s 

Konversationsspezifikationen eine Laufzeitrepr"asentation besitzen.

Konversationsspezifikationen bilden Klassen von Konversationen, ihren

Instanzen.



\item Die Ebene der {\em Konversationsinstanzen}. 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}

Bevor diese beiden Ebenen erl"autert werden, wird zun"achst der generelle Ablauf von

Konversationen erkl"art.



\subsection{Das Verarbeitungsmodell von Konversationen}



In einer Konversation wird jede zielgerichtete Interaktion (also jeder

Sprechakt aus der Language/Action Perspective) mit {\em Dialogen} realisiert. 

Mit Hilfe dieser Dialoge wird Information so strukturiert, da"s der jeweilige

Kommunikationspartner die im Sprechakt enthaltene Information seinem eigenen

Kontext zuordnen kann.



Jeder Dialog beschreibt einen Zustand in der {\em Konversation} zwischen einem

Kunden und einem Dienstleister. Im Gegensatz zur zeitlich ausgedehnten

Konversation besitzt ein Dialog keine nach au"sen sichtbare Zwischenzust"ande.



Zustands"uberg"ange, d.h. das Beginnen eines neuen Dialogs innerhalb einer

Konversation, werden durch die Auswertung und Verarbeitung (die Aktion) einer

Anfrage beim Dienstleister erreicht. 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 Regel, die er mit der Anfrage

assoziiert hat, 

aus und generiert einen neuen (Antwort-)Dialog f"ur den Kunden. Die Menge

der m"oglichen Anfragen, die ein Kunde ausgehend von einem Zustand einer

Konversation an einen Dienstleister richten kann, ist in dem Dialog enthalten,

der den aktuellen Zustand der Konversation repr"asentiert. Es sind genau zwei

Anfragen definiert, die nicht in der Menge der Anfragen enthalten sind, die ein

Dialog 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 Konversation 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.



\item Eine spezielle Anfrage nach dem Abbruch der Konversation. 

Diese Anfrage l"ost ein Kunde implizit aus, wenn er "uber eine von

Dienstleister vorgegebene Zeistspanne 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 mu"s dem Kunden der explizite Abbruch der Konversation 

erlaubt werden.



\end{itemize}



Eine Konversation zwischen einem Kunden und einem Dienstleister wird mit diesen

Mechanismen auf eine Abfolge von Dialogen und Anfragen "ubertragen.



Der Dienstleister gibt jeweils den Dialog vor, auf den der Kunde reagieren

kann. 

Der Kunde ist jedoch immer der {\em Initiator} der Konversation und der

Dienstleister der {\em Akzeptor}. Innerhalb einer Konversation kann der

Dienstleister jedoch in der Rolle eines Kunden eine andere Konversation mit

einem anderen Dienstleister initiieren, wenn das zur Ausf"uhrung seiner Regel

notwendig ist.



\begin{figure}[bt] 

\centerline{\epsfbox{bilder/subconv.eps}} 

\caption{Verfeinerung mittels Sub-Konversationen} 

\label{SubKonv} 

\end{figure}



Mit der Technik der Sub-Konversation ist eine Mischform der

Kunde-Dienstleister-Beziehung m"oglich (Abbildung \ref{SubKonv}). Dabei wird

der Dienstleister $A_{2}$ innerhalb einer Konversation mit einem Kunden $A_{1}$

selbst zum Kunden eines weiteren Dienstleisters $A_{3}$. 



Dialoge ohne einen Folgedialog, d.h. ohne eine m"ogliche ausgehende {\em

Anfrage}, sind {\em finale} Dialoge einer

Konversation.



Jede Konversation besitzt eine definierte Menge von finalen Dialogen, die sie

erreichen kann. Es gibt einen Finaldialog f"ur das erfolgreiche Ende der

Konversation (d.h. sowohl Kunde als auch Dienstleister best"atigen das

erfolgreiche Erreichen des gemeinsamen Ziels) sowie einen expliziten 

finalen Fehlerdialog.



Die Entscheidung, unter welchen Umst"anden welcher Dialog zu welcher Phase 

zugeordnet wird, ist eine Designentscheidung bei der

Anwendungsentwicklung.



Mit diesem definierten Verarbeitungsmodell bleiben beide Teilnehmer der 

Konversation autonome Einheiten. Wenn man diese Abl"aufe mit entfernten

Methodenaufrufen durchf"uhren w"urde, h"atte der Aufrufer Bindungen an Objekte,

die seine Autonomie einschr"anken w"urden. Der Dienstleister m"u"ste sich zum

Beispiel gegen alle m"oglichen Fehler, die beim Aufruf seiner Methoden auftreten

k"onnen, absichern.



\subsection{Konversationsspezifikationen}



\label{conv-spec}



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.

Die Konversationspezifikationen legen fest, welche Form die

Konversationsobjekte sp"ater haben sollen. Sie umfa"st sowohl den statischen

Teil der Beziehung zwischen Kunde und Dienstleister, d.h. die

Datenmodellierung f"ur den Informationsaustausch, als auch den dynamischen Teil

der Beziehung, die Proze"smodellierung f"ur den Informationsaustausch. Beide

Partner k"onnen die Spezifikation daraufhin untersuchen, ob die Konversation

in ihren jeweiligen Kontext und zu ihrer Sicht auf das zu erreichende Ziel pa"st.



\begin{figure}

\centerline{\epsfbox{bilder/tbcmod2.eps}}

\caption{Spezifikationen von Konversationen, Dialogen und Inhalten}

\label{tbcspec}

\end{figure}



\begin{figure}

\centerline{\epsfbox{bilder/tbcinst.eps}}

\caption{Instanzen von Konversationen, Dialogen und Inhalten}

\label{tbcinst}

\end{figure}





Nach diesem Modell enth"alt jede Konversationsspezifikation mehrere abstrakte

Dialogspezifikationen. Eine Dialogspezifikation ist als initialer Dialog

ausgezeichnet, jede Konversation startet mit diesem Dialog. Die abstrakten

Dialogspezifikationen bestehen entweder aus Spezifikationen von

Sub-Konversationen oder von (konkreten)

Dialogen. Mit den Spezifikationen von Sub-Konversationen werden

Konversationsspezifikationen als Dia\-log\-spe\-zi\-fikationen in

anderen Konversationspezifikationen 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 folgenden Dialogs verbunden. 

Die boolesche Variable {\em ellipses} 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 oder einen Datumstyp. Komplexe Inhalte k"onnen mit Records,

Varianten, Auswahllisten oder Listen modelliert werden. Dabei sind auch

Schachtelungen zugelassen. F"ur alle Inhaltstypen existieren Operationen zum

Erzeugen der Spezifikationen. Die Operationen auf den Objekten 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. Sie k"onnen so benannt oder 

verschickt werden. Sie besitzen eine Laufzeitrepr"asentation.



In der Abbildung \ref{Spec-Grammar} ist die Grammatik f"ur die Konstruktion von

Konversationsspezifikationen dargestellt. Die Notation ist aus der Darstellung der

Programmiersprache {\sc Tl} in \cite{Matt93} "ubernommen.



\begin{figure}[btp]

\begin{sl}

\begin{tabbing}

\hspace*{0.5cm}\=\hspace{1cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}

\=\hspace{0.5cm}\=\kill

\>Conversation ::=\\

\>\>{\k CONV} ConvIdentifier {\k WITH} InitialDialog \{ Dialog \} {\k END};\\

\>\\

\>IntialDialog ::=\\

\>\>Dialog;\\

\\

\>Dialog ::= \\

\>\>{\k DIALOG} DialogIdentifier {\k WITH} \{ Request \} $\lbrack$ 

Content  $\rbrack$

 {\k END};\\

\>\\

\>Request ::=\\

\>\>{\k REQUEST} RequestIdentifier {\k TO} DialogIdentifier \{ DialogIdentifier \} \\

\>\>( {\k ELLIPSES} $\mid$ {\k NOELLIPSES} ) {\k END};\\

\\

\>Content ::=\\

\>\>{\k CONTENT} NamedContent \{ NamedContent \} {\k END};\\

\\

\>NamedContent ::=\\

\>\>ContentIdentifier {\k OF} Type;\\

\\

\>Type ::=\\

\>\>BasicType $\mid$ CompoundType;\\

\\

\>BasicType ::=\\

\>\>{\k INT} $\mid$ {\k REAL} $\mid$ {\k STRING} $\mid$ {\k DATE};\\

\\

\>CompoundType ::= \\

\>\>{\k REC} NamedContent \{ NamedContent \} {\k END} $\mid$\\

\>\>{\k VARIANT} NamedContent \{ NamedContent \} {\k END} $\mid$\\

\>\>{\k MCHOICE OF} Type $\mid$\\

\>\>{\k SCHOICE OF} Type $\mid$\\

\>\>{\k SEQ OF} Type;\\

\\

\>ConvIdentifier ::=\\

\>\>identifier;\\

\>DialogIdentifier ::=\\

\>\>identifier;\\

\>ContentIdentifier ::=\\

\>\>identifier;\\

\end{tabbing}

\end{sl}

\caption{Die Grammatik f"ur Konversationsspezifikationen}

\label{Spec-Grammar}

\end{figure}



\subsection{Konversationsinstanzen}



\label{conv-inst}



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 instanziiert 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 Inhaltstyp sind bestimmte Operationen

definiert:

\begin{itemize}



\item Die atomaren Typen k"onnen gelesen und gesetzt werden.



\item In der Liste f"ur eine einfache Auswahl k"onnen die Alternativen gesetzt

werden, man kann alle Alternativen auslesen und eine davon ausw"ahlen. Au"serdem

kann die gew"ahlte Alternative bestimmt werden.



\item In der Liste f"ur mehrere Wahlm"oglichkeiten k"onnen zus"atzlich zu den

Operationen bei einfacher Auswahl Alternativen deselektiert werden.



\item In einem Record-Objekt kann auf die referenzierten Inhaltsobjekte

zugegriffen werden.



\item In einem varianten Record k"onnen au"serdem Teile ausgew"ahlt oder die

Auswahl gelesen werden.



\item Der Listentyp ist nicht direkt in den Dialog eingebunden und wird "uber

Referenzen gesetzt oder gelesen. Au"serdem soll er "uber vielf"altige

Auswahlfunktionen als Massendatentyp benutzt werden.



\end{itemize}



Eine Konversation wird immer zwischen einem Kunden und einem Dienstleister

gef"uhrt. Um Ketten aus Ereignissen und Aktionen \cite{EAK} zu bilden, bekommen

die beiden Partner der Konversation Regeln, mit denen sie auf Ereignisse des

jeweils anderen Partners reagieren und so Aktionen ausf"uhren. 

Menschliche Kunden simulieren diese Regeln,

indem sie den Inhalt der Dialoge lesen und ihre W"unsche eintragen, maschinelle

Kunden besitzen Programmcode, der die Dialoge entsprechend der Vorgaben

behandelt. Die Regeln des Kunden enden immer mit der "Ubermittlung des eventuell

ver"anderten Dialogs zusammen mit einer

Anfrage. Ebenso mu"s der Dienstleister auf die Dialoge und Anfragen des 

Kunden

entsprechend einer Regel 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 die Konversation durchlaufen

(siehe auch Abbildung \ref{rules}).



\begin{figure}[bt]

\begin{center}

\begin{tabular}{rrcl}

Init:&  $(r_{0}, d_{0})$\\

& $\downarrow \quad$ \\

Performer:&  $(r_{n}, d_{n})$ & $\rightarrow$ & $d_{n+1}$ \\

Customer: & $d_{n}$ & $\rightarrow$ & $(d_{n}, r_{n+1})$ \\

\end{tabular}

\end{center}

\caption{Die Regeln als Ereignis-Aktions-Paare}

\label{rules}

\end{figure}



Sub-Konversationen stellen sich zum Zeitpunkt ihrer Ausf"uhrung immer als

Konversationen dar. Dies geht aus dem Diagramm aus Abbildung \ref{tbcinst} durch

die Aggregatbeziehung zwischen der Konversation und der Sub-Konversation hervor.



\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 und Anfragespezifikationen einer

Dia\-log\-spe\-zi\-fikation haben

verschiedene Namen.



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

Identifikation.



\item Jede Konversationsspezifikation hat eine Dialogspezifikation mit dem 

Namen {\em breakdown}. 



Damit bleibt jede Konversation immer 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

rekonstruiert werden.



\item Alle Dialogspezifikationen mit dem Namen {\em breakdown} haben keine

Folgedialoge und deswegen keine Anfragespezifikationen.



Alle finalen Dialogspezifikationen beenden die Konversation.



\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}



Der WebSiteProfiler aus Abschnitt \ref{WSP} soll an dieser Stelle im

Konversationsmodell dargestellt werden. Dabei liegt seine Funktionalit"at nach

wie 

vor fest: Er erstellt verschiedene Statistiken "uber die Nutzung des

WWW-Servers oder f"ugt das

aktuelle Zugriffsprotokoll in die Datenbank ein. Die Visualisierung und

Steuerung durch einen Benutzer wird jetzt mit den Business Conversations

erstellt.



Um den WebSiteProfiler in das Modell einzuf"ugen, mu"s der Programmierer eine

Konversation eines Benutzers mit dem Programm entwerfen und spezifieren. 

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. Jeder gro"se Kasten in der

Abbildung stellt einen Dialog dar, sein Name ist fett gedruckt. In den runden

K"asten steht der Inhalt des Dialogs, die unteren K"astchen bezeichnen die

Anfragen des Dialoges, die zu den entsprechenden Folgedialogen f"uhren. Die 

Nummern in den Dialogen zeigen die Phasen in der Konversation

an, denen sie zugeordnet werden. 



Im

ersten Dialog soll sich der Benutzer bei dem System anmelden. Damit kann

gew"ahrleistet werden, da"s keine unberechtigten Benutzer auf die Daten

zugreifen. Zur Anmeldung bekommt der Benutzer einen Dialog, in dem er seinen Namen

und sein Pa"swort eintragen mu"s. Zus"atzlich zu diese beiden Feldern ist das

Feld f"ur eine Nachricht an den Benutzer als

Inhaltsspezifikation in

der Dialogsspezifikation eingetragen. Wenn der Benutzer zum Beispiel mittels 

Knopfdruck eine 

Anfrage an das System stellt, werden die Dialoginhalte "ubertragen und vom

System ausgewertet. Das System "ubermittelt dem Benutzer daraufhin den

n"achsten 

Dialog. In diesem Beispiel kann die Auswertung auch dazu f"uhren, da"s der

Benutzer wegen der fehlenden Berechtigung abgelehnt wird. Der WebSiteProfiler

mu"s in diesem Fall entscheiden, welcher Dialog anschlie"send "ubermittelt wird.

In allen anderen F"allen steht der Dialog, der auf die Anfrage folgt, fest.



Nach der 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 braucht er keine inhaltlichen Eingaben zu machen. 

Durch seine Auswahl einer Anfrage

wird der entsprechende Folgedialog angezeigt. "Uber die Anfragefolge {\em

verwalten --- Datenbank aktualisieren} wird die Funktion, in der der WebSiteProfiler

die neuen Eintr"age des Zugriffsprotokolls gem"a"s dem Datenbankschema aus

Abschnitt \ref{wsp-db} in seine Datenbank "ubernimmt, aufgerufen. Als Ergebnis 

wird im Inhaltsfeld {\em Nachricht} des

Folgedialogs die Anzahl der "ubernommenen Daten angezeigt. Bei den anderen

beiden 

Dialogen {\em Neue Statistiken } und {\em Archiveinsicht} werden noch keine 

Funktionen des WebSiteProfilers ausgef"uhrt. Sie

kommen erst einen Dialogschritt sp"ater ins Spiel, wenn der Benutzer weitere

Angaben gemacht hat. In dem Dialog, mit dem das System seine Ergebnisse

pr"asentiert, hat der Benutzer die Wahl, weitere Statistiken erstellen

zu lassen 

oder nicht. Durch die Schleife in der Spezifikation sind langandauernde Konversationen 

m"oglich. 



In jedem Dialog erh"alt der

Kunde die M"oglichkeit, Konversationen mit der Anfrage {\em abbrechen} zu

beenden. Ebenso kann der Dienstleister die Konversation beenden, in dem er dem

Kunden den finalen Dialog {\em breakdown} "ubermittelt. Wenn die Konversation

erfolgreich beendet wurde, wird der Dialog {\em terminated} an den Kunden 

zugestellt.



Auf der Basis dieser Spezifikation wird jetzt f"ur jede durchzuf"uhrende

Konversation eine Instanz erzeugt, mit der sie durchgef"uhrt

wird. 



Ein Beispiel f"ur eine Formulierung einer Dialogspezifikation aus der Abbildung

\ref{wspkonvspec} findet man in der Abbildung \ref{ergebnissedialogspec}.



\begin{figure}[bt]



\begin{sl}



\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 WITH}\\

\>\>{\k REQUEST}\\

\>\>\>Weitere Statistiken {\k TO} Taetigkeitswahl {\k

NOELLIPSES} \\

\>\>{\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{sl}



\caption{Formulierung der Spezifikation f"ur den Dialog mit

Ergebnisstatistiken}

\label{ergebnissedialogspec}

\end{figure}



