% Paper Modellierung 99
% Holm Wegner, Patrick Hupe, Florian Matthes
% 04-Nov-1998

\documentclass[10pt]{article}

\usepackage[german]{babel}
\usepackage{a4wide}
\usepackage[latin1]{inputenc}
\usepackage{sts}
%\usepackage{sts-named}
\usepackage{palatino}

\parskip 0.4\baselineskip
\parindent 0pt
%\pagestyle{empty}

\begin{document}

\title{Ein bruchloser "Ubergang von der Proze"smodellierung zu kooperativen Software-Architekturen}
\author{Patrick Hupe \and Florian Matthes \and Holm Wegner}
\date{{\small Arbeitsbereich Softwaresysteme (STS)\\
Technische Universit"at Hamburg-Harburg\\
D-21071 Hamburg\\
\{pa.hupe,f.matthes,ho.wegner\}@tu-harburg.de}
}

\maketitle

%-----------------------------------------------------------------------
\begin{abstract}
%
\noindent
Ein bekanntes Problem beim OOAD-Proze"s ist der systematische "Ubergang
von Proze"sbeschreibungen (Anwendungsf"allen, \engl{Use Cases}) der Analysephase
zu objektorientierten Entw"urfen und Systemrealisierungen. In diesem
Artikel stellen wir zusammenfassend die Beitr"age des Modells der
\engl{Business Conversations} vor, die in den vergangenen drei Jahren
in unserer Gruppe zur L"osung dieses Problems entwickelt wurden. Das
Modell der \engl{Business Conversations} formalisiert die
langandauernde und zielgerichtete Interaktion zwischen Kunden und
Dienstleistern in verteilten Systemen. Kunden und Dienstleister sind
hierbei entweder menschliche Benutzer oder Softwaresysteme. Das Modell
erg"anzt die Notationen der UML und unterst"utzt einen bruchlosen
"Ubergang von der Proze"smodellierung bis hin zur objektorientierten
Realisierung von Softwaresystemen. Die Realisierung wird durch ein
\engl{framework} unterst"utzt, das eine Abstraktion von den Details der
Interaktion mit kooperierenden Systemen und Benutzern erlaubt. Wir
illustrieren das Modell und den Entwicklungsproze"s anhand eines
Anwendungsbeispiels aus einem Kooperationsprojekt mit der SAP AG.
\end{abstract}

%------------------------------------------------------------------------
\section{Motivation}

Die Wandlung von abgeschlossenen, monolithischen und zentralisierten
Informationssystemen hin zu offenen, integrativen und verteilten
L"osungen erfordert
Konzepte, Methoden und Modelle f"ur den Entwurf solcher sich rapide
entwickelnden Systeme, um die Auswirkungen der "Anderungen in der
realen Welt auf die Systeme beschreiben und ihnen folgen zu k"onnen
\cite{CACM98}.

In dieser Arbeit stellen wir ausgehend von einer Untersuchung der
g"angigen objektorientierten Analyse- und Designmethodik
\cite{Booc94,JCJ*92,Rumb*91}
im Umfeld von UML \cite{Fow97} Defizite bei der Modellierung von
Gesch"aftsprozessen fest. Durch Kombination mit der systematischen
Entwicklung von Konversationen f"ur die \engl{Business Conversations}
gelangen wir zu einem bruchlosen Entwicklungsproze"s.

Vor dem Hintergrund der Analyse und
Entwicklung von betrieblichen Informationssystemen
und der Analyse und Umsetzung von Gesch"aftsprozessen  haben wir das in
\cite{Matt97a,Matt97b} vorgestellte Modell der \engl{Business Conversations}
entwickelt.  Es erlaubt die Abstraktion von Details
der Kooperation "uber die \e{Zeit}, den \e{Raum} und in verschiedenen
\e{Modalit"aten}. Die Grundlage ist f"ur die ersten beiden Belange die
Nutzung von Persistenz- und Mobilit"atsabstraktionen sowie f"ur letzteres
das medien- und aktorenunabh"angige Kooperationsmodell.

Wir stellen zun"achst die beobachteten Defizite in
Abschnitt~\ref{Problem} vor.  Um unsere L"osungen vorstellen zu
k"onnen (Abschnitt~\ref{Loesung}), schildern wir in Abschnitt~\ref{BC}
das Modell der \engl{Business Conversations}.
In Abschnitt \ref{Beispiel} schildern wir die praktische Umsetzung
anhand eines realen Projekts, einem Hotelreservierungssystem, das
in Zusammenarbeit mit der SAP AG prototypisch zum Untersuchen dieser Konzepte
entwickelt wurde. Abschnitt~\ref{Conclusio} fa"st zum Schlu"s die Erkenntnisse
noch einmal zusammen.

%------------------------------------------------------------------------

\section{Defizite g"angiger Modellierungstechniken}
\label{Problem}

Ausgangspunkt der Systemanalyse bilden Gesch"aftsproze"smodelle zur
Beschreibung der durch das System zu erbringenden Dienste.
Ereignis-Proze"s-Ketten (EPK) und Anwendungsf"alle in UML haben sich in
der Praxis als ein wichtiges und erfolgreich eingesetztes Mittel zur
Gesch"afts\-proze"smodellierung erwiesen.

%P1
Das gr"o"ste Defizit der EPK ist die starke Trennung von Daten-,
Funktions- und Proze"ssicht. Objektorientierte Notationen wie UML
"uberwinden die Trennung von Funktionen und Daten,
jedoch sind die Proze"sbeschreibungen nur informell mit dem
Objektmodell verbunden \cite{Booc96}.
Es existiert kein formales Verfahren zur Entwicklung der
Zustandsdiagramme und des Objektmodells aus den die
Anforderungsanalyse ausmachenden Anwendungsf"allen und den Akteuren.
In der Regel mu"s hier \glqq kochrezeptartig\grqq\ vorgegangen werden.
Bei OMT wird zumindest die Ableitung der Klassen direkt aus den
Akteuren vorgeschlagen \cite{Rumb*91};
eine Beschreibung der Interaktionen l"a"st sich so aber
noch nicht gewinnen.

Weiterhin gilt es grunds"atzlich festzuhalten, da"s
es keine "uber die Anwendungsf"alle hinausgehende Modellierung der
Interaktion zwischen Benutzer und System gibt: Zum Beispiel zerf"allt
ein f"ur Kunde und Unternehmen zusammenh"angender Gesch"aftsproze"s wie
die Auftragsabwicklung in eine gro"se Zahl von unabh"angig voneinander
modellierten aufeinanderfolgenden Anwendungsf"alle (Anfrage, Angebot,
Bestellung, Lieferung, Bezahlung, Mahnung, \ldots).

%P2
Als weitere H"urde stellt sich der Schritt innerhalb der Entwurfsphase
beim "Ubergang vom idealen Objektmodell zum realen Objektmodell dar.
Bereits an dieser Stelle ist der Entwickler gezwungen, stereotype
\glqq Hilfsklassen\grqq\ zur Visualisierung, Verwaltung von Sitzungen,
Ereignisverwaltung etc.\ einzuf"uhren, die keinerlei Anwendungssemantik
tragen und den Entwurf insgesamt erschweren.

%P3
Durch beide Defizite f"uhren selbst kleine Proze"s"anderungen zu weitreichende
Konsequenzen im Systementwurf.  Falls zum Beispiel als Ergebnis einer
Gesch"aftsproze"soptimierung (\engl{business process reeingineering})
Proze"sschritte in der Auftragsabwicklung reorganisiert werden, hat dies zur
Folge, da"s zahlreiche Hilfsklassen angepa"st werden m"ussen.
Ungl"ucklicherweise unterst"utzen die Anwendungsfalldiagramme den Entwickler bei
dieser Aufgabe in keiner Weise.


%------------------------------------------------------------------------

\section{Proze"smodellierung mit \engl{Business Conversations}}
\label{BC}

Bevor wir in Abschnitt~\ref{Loesung} die L"osungsans"atze erl"autern,
stellen wir in diesem Abschnitt das Modell der
\engl{Business Conversations} knapp und im Zusammenhang vor.
Ausf"uhrliche Darstellungen finden sich in \cite{Matt97a,Matt97b}
sowie \cite{Joha97,Wegn98}.

Auf den linguistischen Arbeiten der Sprechakttheorie von \n{Austin}
und \n{Searle} \cite{Aust62,Sear69} basierend versuchten Arbeiten im Umfeld der
computerunterst"utzten Gruppenarbeit (\engl{computer supported cooperative
work}, CSCW), Sprechakte, die im Rahmen von Gesch"aftsprozessen auftreten, zu
identifizieren und zu klassifizieren.
In \cite{Wino87} und \cite{FGHW88} wird im
\engl{language/action}-Ansatz  daf"ur eine wesentliche Art des Sprechakts
genannt: \engl{Conversations for Actions} (CfA).
Der zentrale Gedanke dabei ist, da"s zwei Partner zum Zwecke der
Erledigung ihres gemeinsamen Anliegens eine Reihe von Sprechakten vollf"uhren;
mit anderen Worten: eine \e{Konversation f"uhren}.
Dem Kooperationsmodell der \engl{Business Conversations} liegt die CfA zugrunde.
Dabei vereinbaren die Partner wechselseitig k"unftige Aktionen, die direkt an
die ge"au"serten Sprechakte der jeweiligen Partner gekoppelt sind.

Das Interaktionsmuster der Sprechakte ist daher \e{universell} in dem Sinne,
da"s es unabh"angig von der Art der Akteure (Software oder Menschen)
und den von ihnen verwendeten Kommunikationsmedien und -protokollen
ist (Medienunabh"angigkeit).
Die Interaktion zwischen zwei menschlichen Akteuren, zwischen einem
Menschen und einem maschinellen Akteur und auch zwischen zwei
maschinellen Akteuren ist innerhalb des Modells transparent
(Aktorenunabh"angigkeit).

Das Modell der \engl{Business Conversations} geht von der Interaktion zwischen
zwei Partnern aus, von denen der eine in der Rolle des \e{Kunden}
und der andere in der des \e{Dienstleisters} handelt.
Die Interaktion zwischen beiden Akteuren kann in einen Zyklus mit vier Phasen
unterteilt werden (siehe Abbildung~\ref{Phasen}) und folgt stets
diesem Verlauf:

\abbildung{0.4}{Phasen}{Struktur eines kundenorientierten Gesch"aftsprozesses}

Im ersten Schritt, der \e{Anfragephase}, fragt der Kunde unverbindlich
beim Dienstleister nach einer Dienstleistung an.  Die Phase endet mit
der Annahme der Anfrage.  Die Initiative geht dabei immer vom Kunden
aus.
Mit Annahme der Anfrage beginnt die zweite, die
\e{"Ubereinkunftsphase}.  In ihr erfolgt die Verhandlung zwischen
Kunde und Dienstleister "uber die genauen Modalit"aten des zu
erbringenden Dienstes.  Am Ende steht die "Ubereinkunft.
Nach der "Ubereinkunft beginnt die \e{Leistungsphase}, in der der
Dienstleister die vereinbarte Leistung erbringen mu"s.  Sie endet aus
Sicht des Dienstleisters mit der Erf"ullung der Leistung.
Die vierte Phase, die \e{R"uckmeldephase}, dient dem Kunden dazu, dem
Dienstleister mitzuteilen, ob die zuvor erbrachte Leistung seinen
Anforderungen und Erwartungen entspricht.

Um eine Br"ucke zwischen den abstrakten Modellen und den
softwaretechnischen Realisierungs\-m"oglichkeiten schlagen zu
k"onnen, ist eine Formalisierung des eigentlichen Inhalts der Konversationen
und deren genauen Ablaufs n"otig.
Wir verwenden dazu im folgenden zwei getrennte Beschreibungsebenen f"ur
Konversationen:
Die Ebene der \e{Konversationsspezifikationen}, auf der die Struktur
von m"oglichen Konversationen beschrieben wird und die der Typebene
einer Programmiersprache entspricht, sowie die Ebene der
\e{Konversationsinstanzen}. Dies ist die der konkreten Konversationen,
die zwischen zwei konkreten Akteuren stattfinden. Analog zu
Programmiersprachen ist jede Konversationsinstanz Auspr"agung ihres
Typs, der Konversationsspezifikation.

Das Modell sieht die Gliederung jeder Konversation in einzelne
\e{Dialogschritte} vor, wobei nach der Er"offnung der Konversation
durch die initiale Anfrage des Kunden in jedem Schritt ein formal
spezifizierter \e{Dialog}, den man als Abstraktion eines Formulars
sehen kann, vom Dienstleister an den Kunden geschickt wird, der Kunde
diesen inspiziert und den Inhalt ggf.\ ver"andert und ihn schlie"slich
unter Angabe einer aus einer Menge von f"ur diesen Dialog angegebenen
\e{Anfragen} zur"uckschickt.  Dies geschieht solange, bis beide
Partner "ubereinkommen, da"s die Konversation beendet ist.

Eine Konversationsspezifikation definiert neben ihren Namen alle in
einer Konversation m"oglichen Dialoge; dazu erh"alt jeder Dialog einen
innerhalb der Konversationsspezifikation eindeutigen Namen sowie eine
formale, strukturierte Beschreibung des Inhalts durch ein simples
Typ\-system, ferner eine Menge von Anfragen f"ur jeden Dialog, aus der
eine als Antwort des Kunden gefordert wird; jede Anfrage hat dazu einen
innerhalb des
Dialoges eindeutigen Namen. Schlie"slich enth"alt die Spezifikation zu jedem
Dialog die Menge aller m"oglichen Folgedialoge
(dazu werden zu jeder Anfrage, die der Dialog enth"alt, die
Namen der erlaubten Folgedialoge angegeben).

Abgesehen von dem Typsystem f"ur die Dialoginhalte l"a"st sich eine
Konversationsspezifikation als Spezifikation eines
nichtdeterministischen endlichen Automaten (NFA) und der Ablauf einer
Konversation als Interpretation desselben betrachten.
Dabei bilden die Dialoge die Zust"ande und die Anfragen des Kunden die
Eingaben des Automaten, wobei der Nichtdeterminismus des Automaten durch
die M"oglichkeit mehrerer Folgedialoge eines Dialoges auf eine Anfrage zum
Ausdruck kommt.
Die Zustands"uberg"ange werden also im Rahmen der Spezifikation durch die
Auswahl der Anfrage durch den Kunden und die Auswahl des Folgedialoges durch
den Dienstleister festgelegt.

Die Spezifikation des Inhalts eines Dialoges wird durch ein einfaches
Typsystem geleistet. Es sieht neben Basisdatentypen wie
\k{boolean}, \k{integer}, \k{real}, \k{string}, \k{date}, \k{time} und \k{currency}
zusammengesetzte Typen wie \k{records}, \k{variants}, \k{single}- und
\k{multiple-choice} sowie \k{sequences} vor.
Dabei werden alle Komponenten des Inhalts sowie alle \ky{record}- und
\ky{variant}-Komponenten durch Namen gekennzeichnet, um den Zugriff zu
erm"oglichen.
Die \ky{record}- und \ky{variant}-Typen dienen zum Aufbau von komplexeren,
strukturierten Typen. Dabei sind alle Typen orthogonal kombinierbar.
Die \ky{choice}-Typen, deren Instanzen sich wertm"a"sig nicht von den
entsprechenden Typen unterscheiden, dienen dazu, die \e{m"ogliche} Wertemenge
einzuschr"anken. Die Wertemengen sind nicht Teil der Spezifikation, sondern
werden erst zur Laufzeit den Instanzen zugewiesen.
Durch die Bereitstellung solcher Typen wird die
Visualisierung von Datenstrukturen unterst"utzt, etwa (je nach
Kardinalit"at) durch \engl{checkboxes, radiobuttons} oder geeignete
Auswahllisten.
Der \ky{sequence}-Typ dient zur Definition und Benutzung von
Massendaten.

Der Aufbau einer vollst"andigen Konversationsspezifikation l"a"st sich
durch ein Klassendiagramm veranschaulichen (vgl.\
Abbildung~\ref{ClassDiagramConvSpec}), das auch die Grundlage f"ur ein
\engl{framework} zur agentenbasierten Realisierung kooperativer
Informationssysteme bildet \cite{Wegn98,Matt97a}.

\abbildung{0.5}{ClassDiagramConvSpec}%
          {Objektorientierte Modellierung von Konversationsspezifikationen}

Durch die Einf"uhrung der Typen \k{convspec}, \k{dialogspec} und
\k{contentspec} sind alle Spezifikationen selbst Objekte erster Klasse in
ihrem eigenen Typsystem, d.h.\ Spezifikationen k"onnen wiederum Inhalte sein,
die innerhalb von
Konversationen verwendet werden k"onnen. So wird es besonders einfach,
Meta-Dienste zu realisieren, wenn diese selbst
\engl{Business Conversations} zur Interaktion verwenden.

%------------------------------------------------------------------------

\section{L"osungsbeitrag zu einem bruchlosen Softwareentwicklungsproze"s}
\label{Loesung}

\subsection{Einbettung von Anwendungsf"allen in kundenorientierte Gesch"aftsprozesse}

Um die zuvor beschriebenen Probleme zu l"osen, ist es hilfreich,
einen Schritt zur"uckzutreten und zun"achst das Gesamtbild der
Anwendungsf"alle (\engl{use cases}) zu betrachten.

%L1
In der UML-Modellierung der Anwendungsf"alle sind die darunterliegenden
Gesch"aftsprozesse
nicht mehr zu erkennen. Sie werden vielmehr durch nicht
zusammenh"angende F"alle beschrieben (beispielsweise \glqq Anmelden beim
System\grqq, \glqq Buchen eines Zimmers\grqq, \glqq Abfrage der
Kreditkartennummer\grqq, \glqq Best"atigung der Buchung\grqq\ etc.).
Durch Zusammenf"uhren der inhaltlich zu
einem Proze"s geh"orenden F"alle zu einer
\e{Konversationsspezifikation} stellen wir zun"achst die Bez"uge
untereinander (wieder) her.  Eine semantische Strukturierung wird zus"atzlich
durch eine Zuordnung zu den einzelnen Phasen
(vgl.\ Abbildung~\ref{Phasen}) vorgenommen.
Komplexe Szenarien mit mehr als zwei Akteuren lassen sich
gem"a"s der in \cite{Matt97a,Joha97,Wegn98} genannten
Strukturierungsprinzipien (Koordination, \engl{Broker},
Subkonversationen, sekund"are Konversationen) durch mehrere
Konversationsspezifikationen beschreiben.

Das Erstellen einer Konversationsspezifikation umfa"st dann die Definition
der einzelnen Dialoge und der dazwischen m"oglichen "Uberg"ange
(Anfragen).  Einzelne Anwendungsf"alle lassen sich dabei auf
einen oder mehrere Dialoge abbilden.
An dieser Stelle mu"s das bei der Anforderungsermittlung gesammelte Wissen
(Dom"anenwissen) "uber die Gesch"aftsprozesse verwendet werden, um
die einzelnen Dialoge, ihre Bedeutung und die enthaltenen Informationen
festzulegen \cite{Ripp98}.
Zu jedem Dialog werden die Inhalte in Form von strukturierten,
hierarchischen Dokumenten spezifiziert \cite{Joha97}. Dies gew"ahrleistet eine
aktoren- und medienunabh"angige (und so auch implementierungsunabh"angige)
Modellierung der semantischen Inhalte der Interaktion.%
\footnote{In Zukunft k"onnte sich XML als geeignete Austauschform etablieren.}

Um eine Trennung der Anwendungslogik von dem die Kooperation in Raum,
Zeit und verschiedenen Modalit"aten unterst"utzenden \engl{framework} zu
erreichen, wird sie in \e{Regeln} isoliert, die -- gem"a"s der
Sichtweise als NFA -- die Zustands"uberg"ange entscheiden \cite{Wegn98}.
Dabei ist zwischen Kunden- und Dienstleisterregel zu unterscheiden.

Mit dem Zusammenfassen von Anwendungsf"allen zu
Konversationsspezifikationen und dem anschlie"sende Herunterbrechen der
Bearbeitung der einzelnen Anfragen und Dialoge auf Regeln entsteht so
ein sehr fein granulares Modell f"ur die im System vorkommenden
Ereignisse.\footnote{Diese entsprechen im "ubrigen genau den in den EPK
modellierten Ereignissen \cite{Ripp98}.}
Die fein granularen Dialoge, Anfragen und Regeln sowie die Akteure
bilden jetzt den Ausgangspunkt f"ur die Identifizierung und den sp"ateren
Entwurf der eigentlichen
Gesch"aftsobjekte (\engl{business objects}), auf denen die Systeme
(z.B. ein Buchungssystem als Dienstleister) arbeiten \cite{Ripp98}.
Ab hier werden die Gesch"aftsobjekte mit der bekannten Vorgehensweise
weiter spezifiziert (Objektmodell) und die Modellierung durch weitere Diagramme
(Zustandsdiagramme etc.) erg"anzt.

Abbildung~\ref{Bruecke} verdeutlicht das Ineinandergreifen der
Entwicklungsschritte von UML und \engl{Business Conversations}.

\abbildung{0.5}{Bruecke}{Die Br"ucke zwischen Anwendungsf"allen und
Objektmodell}

%........................................................................

\subsection{Abstraktion von Interaktionsdetails durch ein \engl{framework}}

Dem zweiten in Abschnitt~\ref{Problem} angesprochenen Problem beim "Ubergang von idealen zum realen
Objektmodell l"a"st sich auf einer mehr technischen Ebene begegnen:
Durch Verwendung eines geeignet entworfenen und implementierten
\engl{frameworks} zur Repr"asentation von Konversationsspezifikationen und
Konversationen (Dialogen, Anfragen und Inhalten), zur Abwicklung der
Kommunikation zwischen Akteuren gem"a"s der Spezifikation sowie zur
Verwaltung verschiedener, paralleler Konversationen (Sitzungen etc.)
und der geordneten Regelausf"uhrung entf"allt im typischen
dialogorientierten Anwendungsfall betrieblicher Prozesse der Entwurf
und die Implementierung von Hilfsklassen (vgl.\ Abschnitt~\ref{Problem})
h"aufig ganz oder reduziert sich zumindest drastisch.
Konkret erlaubt die Benutzung der \engl{frameworks}, die in
\cite{Joha97,Wegn98} entwickelt und beschrieben wurden, die Abstraktion
von \e{Persistenz}, \e{Mobilit"at}, \e{Sitzungsverwaltung}, \e{Medien-} und
\e{Aktorenabh"angigkeiten} sowie die \e{orts-} und \e{migrationstransparente}
Nutzung von beliebigen Diensten.
Durch die Entwicklung eines \e{generischen Kunden}, der in der Lage
ist, Konversationen zu visualisieren
\cite{Wegn98,Ripp98,Zade98}, entf"allt ferner der ansonsten nicht
unerhebliche Aufwand der Realisierung einer graphischen
Benutzungsoberfl"ache.
Durch diese Abstraktionen bzw.\ Entkopplung reduziert sich der Aufwand der
Entwicklung erheblich und erm"oglicht die volle Konzentration auf die
Anwendungslogik.

%........................................................................

\subsection{Unterst"utzung f"ur kooperierende verteilte Informationssysteme}

Bei einer weitergehenden Betrachtung stellt sich heraus, da"s die
Verschiebung der Sichtweise
von Anwendungsf"allen als asymmetrische Sicht auf
eine Benutzer-System-Beziehung
hin zu
einer symmetrischen Sicht auf eine Akteur-Akteur-Beziehung
(bzw.\ Kunde-Dienstleister)
zu einer weitaus besseren Modellierungsf"ahigkeit f"ur den Entwurf von
kooperativen Informationssystemen f"uhrt \cite{Matt97b}.
Die symmetrische Sicht, das abstrakte Interaktionsprotokoll und die
weitgehende Entkoppelung von technischen Implementierungsdetails
verbessert die M"oglichkeiten zur unabh"angigen Evolution der beteiligten
Systeme.
Da nach \cite{CACM98,DDJ+97} kooperative Informationssysteme
als verteilte Systeme
betrachtet werden k"onnen, in denen autonome Akteure ihre langandauernden
Aktivit"aten koordinieren, um ein gemeinsames Ziel zu erreichen, stellt
unser Modell eine daf"ur gut passende Entwicklungsmethodik bereit.

%------------------------------------------------------------------------

\section{Beispiel: \engl{Hotel-Front-Office-System}}
\label{Beispiel}

Um die Vorteile des oben geschilderten Vorgehens zu verdeutlichen,
schildern wir anhand eines tats"achlich realisierten Projektes
die Umsetzung.
Die Aufgabe bestand darin, ein umfangreiches \engl{Hotel-Front-Office-System}
zur Hotelzimmerreservierung prototypisch zu entwerfen und zu implementieren
und wurde als Kooperationsprojekt mit der SAP AG durchgef"uhrt \cite{Ripp98}.

Die Analyse besteht nach der Anforderungsermittlung aus der Aufstellung von
Anwendungs\-f"allen, die durch die "ublichen Dokumente wie Aktorenkataloge
etc.\ vervollst"andigt werden. Typische Anwendungsf"alle etwa sind
\glqq Suche Gesch"aftspartner\grqq, \glqq Suche verf"ugbare Produkte\grqq\ oder
\glqq Erstelle Angebot im Anfragekontext\grqq.
Ausgehend davon werden f"ur alle Anwendungsf"alle die zur
Abwicklung des Gesch"aftsprozesses n"otigen Interaktionen zwischen
Benutzer und System durch eine Folge von HTML-Formularen beschrieben.
Verkn"upft wurden diese jeweils durch eine Reihe von m"oglich Folgeformularen,
die durch \engl{submit-buttons} erreichbar sind.
Diese Formulare dienen zun"achst lediglich zur Spezifikation der Interaktionen.%
\footnote{Nebenbei bilden sie durch ihre \glqq Anfa"sbarkeit\grqq\ auch
eine gute Grundlage f"ur die Diskussion mit den k"unftigen Anwendern des
Systems.}  Durch informelle Zuordnung zu den einzelnen Phasen des
Interaktionsmodells der \engl{Business Convesations} und die o.g.\
Verkn"upfungen der Formulare ergibt sich so automatisch eine
\e{Konversationsspezifikation}.  Dabei wird der Benutzer als Kunde und
das System als Dienstleister betrachtet.  Jeder Anwendungsfall kann so
auf eine Konversationsspezifikation abgebildet werden; dabei stellt
jedes HTML-Formular einen Dialog und jeder \engl{submit-button} eine
Anfrage im Sinne der \engl{Business Conversations} dar.  Die
Formularfelder eines Formulars bilden die Inhaltsspezifikation.

Die zentrale Idee ist nun, aus diesen HTML-Formulare einerseits maschinell
Konversationsspezifikationen zu gewinnen, die von einem wie oben beschriebenen
\engl{framework} genutzt werden k"onnen, um die Konversation abzuwickeln,
und andererseits, die Formulare zur generischen Visualisierung der ablaufenden
Konversationen auf der Seite des Benutzers zu verwenden.
Das Vorgehen ist in Abbildung~\ref{Vorgehen} illustriert.

\abbildung{0.4}{Vorgehen}%
          {Vorgehen bei der Wiederverwendung der HTML-Formulare}

Aufbauend auf dem im Rahmen von \cite{Wegn98} entwickelten
\engl{Tycoon Business Conversations}-System (TBC) wurde dazu ein
\e{generischer Kunde} entwickelt, der unter Verwendung eines SGML-Parsers
aus den HTML-Formularen eine Konversationsspezifikation generiert und
ferner als Kunde im Sinne des TBC-Systems unter Benutzung der
Spezifikation und der HTML-Formulare als HTTP-Server agiert, um die
Konversation mit einem menschlichen Benutzer zu f"uhren.  Durch die
Generizit"at dieses Ansatzes sind auf der Kundenseite auch keine Regeln
zu implementieren, da alle Entscheidungen vielmehr von dem menschlichen
Benutzer getroffen werden.
In Abbildung~\ref{Umsetzung} ist der Ablauf der Umsetzung auf
technischer Ebene dargestellt. Hier ist gut zu erkennen, wie nach
dem Aufbau einer Sitzung  die Dienstleisterseite -- unabh"angig von der
Realisierung der Kundenseite -- Dialoge und Anfragen austauscht.%
\footnote{Die auf der Dienstleisterseite vorhandenen Regel-Aufrufe
sind der "Ubersichtlichkeit halber nicht mit dargestellt.}
Die \e{generische Kundenregel} sorgt in Verbindung mit dem parallel
laufenden HTTP-Server f"ur die "Ubersetzung von Dialogen in HTML-Formulare
und umgekehrt von Formularen zur"uck in Dialoge und Anfragen.

\abbildung{0.4}{Umsetzung}{Technische Umsetzung der Interaktion "uber das HTTP}

Auf der anderen Seite, der Dienstleisterseite, die das
Zimmer-Reservierungssystem darstellt, geben die durch die
Konversationsspezifikation vorgegebenen Regeln einen fein
strukturierten Rahmen f"ur die Entwicklung der eigentlichen
Anwendungslogik.  Entwurf und Implementierung des Objektmodells f"ur
die Funktionalit"at des Hotel-Zimmer-Reservierungssystems k"onnen g"anzlich von
sekund"aren Aspekten wie Visualisierung, Sitzungen, Nebenl"aufigkeit
etc.\ abstrahieren.  Die Regeln stellen sehr \glqq kleine\grqq\
Transitionen dar, die sich mit wenig Aufwand implementieren lassen
(z.B. \glqq ein Zimmer aus der Liste der angebotenen Zimmer im Detail
darstellen\grqq,
\glqq die Buchung genau des angezeigten Zimmers best"atigen\grqq\ etc.).

\abbildung{0.4}{Hotelarchitektur}{Kooperierende Informationssysteme}

Die Gesamtarchitektur des entwickelten Systems ist abschlie"send in
Abbildung~\ref{Hotelarchitektur} skizziert.

%-----------------------------------------------------------------------

\section{Conclusio}
\label{Conclusio}

Wir haben eine zielgerichtete Herangehensweise zur Modellierung von
Gesch"aftsprozessen auf Basis von UML und den \engl{Business Conversations}
aufgezeigt.
Die genannten Defizite bei der Modellierung mit UML, namentlich der Bruch
zwischen Anwendungsf"allen und Objektmodell in der Analysephase einerseits
und der "Ubergang vom idealen zum realen Objektmodell in der Entwurfsphase
andererseits, haben wir durch Verwendung des Modells und der zugeh"origen
Methodik der \engl{Business Conversations} verringert.
Somit sind wir zu einem Entwicklungsproze"s gelangt, der die Modellierung
von Gesch"aftsprozessen durchg"angig von der Analyse bis zur Implementation
beschreibt.

Die Vorteile dieser Modellierungstechnik sind:
%
die Verwendung der verbreiteten Modellierungssprache UML,
die f"ur alle relevanten Modellierungsaspekte
ad"aquate Darstellungsmittel (Diagramme) bereitstellt;
%
die Verwendung der Konversationsspezifikationen der
\engl{Business Conversations}, die im Gegensatz zu EPK
\e{(Ereignis-Proze"s-Ketten)} zusammengeh"orige Prozesse von Kunde
und Dienstleister in einer gemeinsamen Ablaufspezifikation beschreiben,
was bei der Evolution von Gesch"aftsprozessen unn"otigen Abstimmungsaufwand
vermeidet;
%
die symmetrische Sicht der \engl{Business Conversations} auf
Akteur-Akteur-Beziehungen statt durch Anwendungsf"alle implizierten
Akteur-System-Beziehungen. Diese erm"oglicht eine elegante und
zielgerichtete Modellierung beim
Entwurf von \e{kooperativen Informationssystemen}, da
solche Kooperationsbeziehung besser als Akteur-Akteur denn als
Akteur-System Beziehungen verstanden werden;
%
die Verwendung eines \engl{frameworks} zur Unterst"utzung
\engl{Business Conversations}, das den "Ubergang vom idealen
zur realen Objektmodell in der Entwurfsphase stark vereinfacht, da es
die meisten zur Kommunikation und Kooperation n"otigen
Basismechanismen bereits enth"alt und generische
Visualisierungskomponenten bereitstellt.
Die Abstraktion des \engl{frameworks} von Aktoren und Modalit"aten und
deren technischer Realisierung schafft zudem die n"otige Flexibilit"at
f"ur die unabh"angige Weiterentwicklung (Evolution) der den kooperativen
Informationssystemen zugrundeliegenden Kunde- und
Dienstleistersystemen.

Das bisherige in \cite{Wegn98} beschriebene System ist in \m{Tycoon-2}
implementiert. F"ur den Einsatz in weiteren Anwendungsprojekten wird es
zur Zeit in \m{Java} re-implementiert.  Neben dem im Beispiel in
Abschnitt~\ref{Beispiel} illustrierten \engl{broker}-Muster bestehend
aus Kunde, \engl{broker} und Dienstleister untersuchen wir in anderen
Anwendungsprojekten weitere Konversationsmuster
(z.B. Koordinator) zwischen kooperierenden Informationssystemen.

%-----------------------------------------------------------------------
\bibliographystyle{alpha}
\bibliography{STS,Literatur}

\end{document}
