Feature-orientierte Entwicklung
von
rollenbasierten Systemen
zur
kooperativen Entscheidungsfindung
Dissertation
zur Erlangung des Grades eines
Doktors der Naturwissenschaften
der Technischen Universita¨t Dortmund
an der Fakulta¨t fu¨r Informatik
von
Martin Karusseit
Dortmund
2009
Tag der mu¨ndlichen Pru¨fung: 15.12.2009
Dekan: Prof. Dr. Peter Buchholz
Gutachter: Prof. Dr. Bernhard Steffen
Prof. Dr. Dietmar Jannach
Danksagung
Ich mo¨chte mich besonders bei meinem Doktorvater Prof. Dr. Bernhard Steffen
und Prof. Dr. Ing. Tiziana Margaria bedanken, die mir nach meinem Studi-
um der Elektrotechnik und mehrja¨hriger Ta¨tigkeit in der Wirtschaft den Weg
zuru¨ck an die Technische Universita¨t Dortmund aufgezeigt haben. Durch ihr
weitreichendes und fundiertes Wissen in ihren Fachgebieten haben sie mich
wa¨hrend meiner Promotion unterstu¨tzend begleitet. Die fachlichen Diskussio-
nen und Anregungen waren mir immer eine große Hilfe.
Des Weiteren mo¨chte ich mich bei Prof. Dr. Dietmar Jannach bedanken, der
sich bereit erkla¨rt hat, Zweitgutachter fu¨r meine Arbeit zu sein und mir hilf-
reiche Anregungen in der Fertigstellungsphase der Dissertation gegeben hat.
Weiterer Dank gilt Prof. Dr. Kern-Isberner fu¨r die Leitung meiner Pru¨fungs-
kommission und Dr. Oliver Ru¨thing, der einerseits das wissenschaftliche Mit-
glied in der Pru¨fungskommission ist und sich andererseits fu¨r hilfreiche fachli-
che Gespra¨che Zeit genommen hat.
Die Umsetzung eines so großen Projektes, wie es der OCS mit seiner Dienst-
familie darstellt, ist nur mit der Unterstu¨tzung eines motivierten Teams zu
bewa¨ltigen. Ich mo¨chte mich daher bei meinem ehemaligen OCS-Team Hol-
ger Willebrandt, Markus Korte, Marc von Renteln, Eugen Reinke, Sebastian
Hundt und Dominik Brink fu¨r die jahrelange erfolgreiche Zusammenarbeit be-
danken. Des Weiteren bedanke ich mich bei Markus Bajohr, der mit seinem
fundierten Wissen im Bereich der Netzwerktechnik, die Umsetzung der OCS-
Clusters durchgefu¨hrt hat. Einen besonderen Dank auch an Ben Lindner fu¨r
die sehr gute Zusammenarbeit zu Beginn des OCS Projektes.
Ich mo¨chte mich ebenfalls bei dem gesamten Team des Lehrstuhls fu¨r Pro-
grammiersysteme der Technischen Universita¨t Dortmund fu¨r die angenehme
Arbeitsatmospha¨re bedanken.
Danke an Springer Heidelberg, insbesondere an Herrn Alfred Hofmann, Frank
Holzwarth und Ursula Barth, die ein sehr angenehmes Arbeitsklima seitens
des Projektpartners geschaffen haben.
Ich bedanke mich bei Bettina, Claudia, Oliver, Thomas und Volker fu¨r das
Auffinden des Fehlerteufels, der gerade wa¨hrend der zahlreichen Nachtarbeiten
einen leichten Einzug in die Vorversionen dieser Arbeit gefunden hatte.
Abschließend mo¨chte ich mich fu¨r die unermessliche Unterstu¨tzung bei mei-
ner Frau Michaela, meinem Sohn Tobias und meiner Tochter Stella herzlich
bedanken. Sie haben oftmals auf mich verzichten mu¨ssen und haben mich in
schwierigen Situationen mit ihrer großen Liebe unterstu¨tzt und Kraft gegeben.
Zusammenfassung
Effiziente Entscheidungsfindungen spielen eine wirtschaftlich bedeutende Rolle
in Bezug auf den Arbeitsaufwand und die entstehenden Kosten. Mit steigen-
der Anzahl der Entscheidungstra¨ger treten terminliche und organisatorische
Engpa¨sse auf, die durch die globale Verteilung der Personen und die daraus re-
sultierende Zeitzonenproblematik versta¨rkt werden. Im wissenschaftlichen und
industriellen Bereich ist die Verwaltung und Koordination der Begutachtungs-
prozesse von Artikeln fu¨r die Leitung und die Beteiligten des Prozesses mit
einem enormen zeitlichen Aufwand verbunden. Das OCS 1-Projekt realisiert
web-basierte Begutachtungssysteme, welche die (wiederkehrenden) Prozesse
automatisieren und die relevanten Daten und Ergebnisse unabha¨ngig von Zeit
und Ort transparent zur kooperativen Zusammenarbeit zur Verfu¨gung stellen.
In dieser Arbeit wird ein auf der Modellgetriebenen Softwareentwicklung (
MDSD 2) basierende Feature-orientierte Vorgehenweise fu¨r die Softwareent-
wicklung und ein darauf aufbauender Rollen-basierter Zugriffskontrollmecha-
nismus im Rahmen einer konkreten praktischen Umsetzung vorgestellt. Die auf
Basis des ABC 3 konzipierten graphbasierten Ansa¨tze verfolgten bereits En-
de der Neunzigerjahre eine Service-orientierte Softwareentwicklung und zeig-
ten eine Lo¨sung fu¨r die Umsetzung komplexer Anwendungen fu¨r ausfu¨hrbare
Gescha¨ftsprozesse auf, die erst spa¨ter, etwa durch die im Jahre 2002 eingefu¨hrte
Sprache fu¨r Gescha¨ftsprozesse WS-BPEL, in den Fokus intensiver Forschung
und einer breiten o¨ffentlichen Beachtung gelangten. Das Feature-orientierte
Konzept ist technologieunabha¨ngig und wurde im Rahmen des OCS-Projekts
erprobt. Die Begutachtungssysteme finden ihren Einsatz im internationalen
wissenschaftlichen Bereich von Konferenzen, Journals und Workshops. Dort
werden sie eingesetzt, um den gesamten Begutachtungsprozess fu¨r wissen-
schaftliche Artikel abzubilden. Die Begutachtungssysteme sind web-basierte
Applikationen, die alle relevanten Daten, z.B. einer Konferenz, online perso-
1Online Conference Service
2Model-Driven Software Development
3Agent Building Center: Eine graphbasierte Entwicklungsumgebung
nalisiert zur Verfu¨gung stellen. Durch die Gruppierung der Dienstfunktiona-
lita¨ten in Features und die Modellierung derselben als Graphen, wird eine
hohe Agilita¨t des Systems in Bezug auf neue Kundenanforderungen erreicht,
was sich in der bislang zehnja¨hrigen Erfahrung bewa¨hrt hat. Mittels der Ve-
rifikation der Graphmodelle des OCS, die den Kontrollfluß (Gescha¨ftslogik)
repra¨sentieren, wird gewa¨hrleistet, dass neu erstellte bzw. modifizierte Gra-
phmodelle stets konsistent zu den urspru¨nglichen Anforderungen bleiben. Das
entwickelte Benutzer/Rollen/Rechte-Modell verleiht den Systemen eine Flexi-
bilita¨t bzgl. der Zugriffsrechte und Personalisierung der Dienstfunktionalita¨ten.
Der erfolgreiche Einsatz der Konzepte hat sich durch die bis heute jahrelange
Verwendung der realisierten Begutachtungssysteme OCS, OJS 4, LNCS 5 und
Transactions besta¨tigt.
4Online Journal Service
5Lecture Notes in Computer Science
Inhaltsverzeichnis
I Motivation und Hintergrund 1
1 Einleitung 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Entscheidungssystem . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Begutachtungsprozess . . . . . . . . . . . . . . . . . . . 7
1.2.2 Allgemeine Anforderungen . . . . . . . . . . . . . . . . . 12
1.2.3 Online Conference Service (OCS): Anforderungen . . . . 13
1.3 Eigener Beitrag . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Aufbau der Dissertation . . . . . . . . . . . . . . . . . . . . . . 19
2 Verwandte Arbeiten 21
2.1 Begutachtungssysteme . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.1 Vorstellung verwandter Systeme . . . . . . . . . . . . . . 22
2.1.2 Analyse und Diskussion . . . . . . . . . . . . . . . . . . 25
2.2 Sicherheit von Web-Applikationen . . . . . . . . . . . . . . . . . 32
2.2.1 WS-Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.2 XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.3 Policies im OCS . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.4 Vergleich der Ansa¨tze . . . . . . . . . . . . . . . . . . . . 40
2.3 Patterns fu¨r Begutachtungsprozesse . . . . . . . . . . . . . . . . 42
2.3.1 Vorstellung der Pattern . . . . . . . . . . . . . . . . . . . 43
2.3.2 Vergleich mit OCS . . . . . . . . . . . . . . . . . . . . . 46
I
INHALTSVERZEICHNIS II
2.3.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
II Verwendete Technologien 51
3 Frameworks 53
3.1 ABC/jABC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1.1 Modellierung und Validierung . . . . . . . . . . . . . . . 55
3.1.2 Ausfu¨hrbare Gescha¨ftsprozesse . . . . . . . . . . . . . . . 58
3.2 EWIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4 Realisierte Konzepte 63
4.1 Feature-orientierter Ansatz . . . . . . . . . . . . . . . . . . . . . 63
4.1.1 Feature Beschreibung . . . . . . . . . . . . . . . . . . . . 64
4.1.2 Feature-basiertes Design . . . . . . . . . . . . . . . . . . 66
4.2 Rollen/Rechte Management . . . . . . . . . . . . . . . . . . . . 71
4.2.1 Das Benutzer/Rollen-Rechtemodell . . . . . . . . . . . . 73
4.2.2 Zugriffsrechte zur Laufzeit . . . . . . . . . . . . . . . . . 76
4.2.3 Personalisiertes Rechtemanagement . . . . . . . . . . . . 78
4.2.4 Validierung des Zugriffskontrollmechanismus . . . . . . . 82
4.3 Bidding- und Verteilungsmechanismus . . . . . . . . . . . . . . 84
4.4 Konfigurierbarer Bewertungsworkflow . . . . . . . . . . . . . . . 92
III Das Entscheidungssystem OCS 99
5 Workflows und Features 101
5.1 Konferenzphasen . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.2 Lebenszyklus eines Artikelobjektes . . . . . . . . . . . . . . . . 104
5.3 OCS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6 Architektur und Technologie 115
INHALTSVERZEICHNIS III
6.1 Client-Server-Architektur des OCS . . . . . . . . . . . . . . . . 115
6.2 Schichtenmodell des OCS . . . . . . . . . . . . . . . . . . . . . . 117
7 Dienstfamilie 121
7.1 Management Overview System (MOS) . . . . . . . . . . . . . . 122
7.2 Online Journal Service (OJS) . . . . . . . . . . . . . . . . . . . 123
7.3 Proceeding Production Service (PPS) . . . . . . . . . . . . . . . 124
7.4 Lecture Notes in Computer Science (LNCS) . . . . . . . . . . . 126
7.5 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
IV Analyse und Erfahrungen: OCS im Einsatz 129
8 Design-Entscheidungen 131
8.1 Technologische Ebene . . . . . . . . . . . . . . . . . . . . . . . . 133
8.2 Feature Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9 Einsatz der Entscheidungssysteme 137
10 Fallstudie: Verwendung des OCS 141
10.1 Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
10.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
10.2.1 Benutzungsstatistik . . . . . . . . . . . . . . . . . . . . . 145
10.2.2 Feature-Statistik . . . . . . . . . . . . . . . . . . . . . . 147
10.2.3 Konferenzstatistik . . . . . . . . . . . . . . . . . . . . . . 150
10.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
V Zusammenfassung und Ausblick 155
11 Zusammenfassung und Ausblick 157
11.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 157
11.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Abbildungsverzeichnis
1.1 Vereinfachter OCS-Begutachtungsprozess . . . . . . . . . . . . . 10
2.1 Beispiel WS-Policy policy . . . . . . . . . . . . . . . . . . . . . 35
2.2 Verarbeitung einer Anfrage in XACML . . . . . . . . . . . . . . 36
2.3 Beispiel einer XACML Policy . . . . . . . . . . . . . . . . . . . 37
2.4 ReadArticleList SLG - in vereinfachter Form . . . . . . . . . . 38
2.5 FormulaBuilder - Graphische Modellierung der Policy 1 . . . . . 39
2.6 ReadArticleList Feature ist Policy 1 konform . . . . . . . . . 40
2.7 Verstoß der Policy 1 im gea¨nderten ReadArticleList Feature . 41
3.1 Das ABC mit geladenem OCS-SLG und SIB-Palette . . . . . . . 55
3.2 Generierter Java Quellcode der Gescha¨ftslogik. . . . . . . . . . . 59
3.3 Generierter Java Quellcode zur Instanziierung der SIBs. . . . . . 60
4.1 Features im OCS: Benutzersicht . . . . . . . . . . . . . . . . . . 65
4.2 Struktur eines Hauptgraphen: Gezeigt am Beispiel des OCS . . 67
4.3 SLG des Article Feature: Hierarchische Struktur des Feature . . 68
4.4 Struktur eines Sub-Features: Das Submit Article Feature . . . . . 70
4.5 Role Management Service im OCS: Das Graph-Modell . . . . . 72
4.6 Das Benutzer/Rollen/Rechte Modell . . . . . . . . . . . . . . . 74
4.7 Benutzer/Rollen-Management: SLG . . . . . . . . . . . . . . . . 81
4.8 Benutzer/Rollen-Management: Temporal logische Formel . . . . 83
4.9 Benutzer/Rollen-Management: Validierung . . . . . . . . . . . . 84
V
ABBILDUNGSVERZEICHNIS VI
4.10 Bidding Feature - Auswahlliste fu¨r Gutachter . . . . . . . . . . 86
4.11 Bidding-Matrix - Anzeige der Benutzerwahl . . . . . . . . . . . 87
4.12 Solver-Input - Zielfunktion, Restriktionen, Variablendeklaration 89
4.13 Solver-Output - Lo¨sung der Zielfunktion . . . . . . . . . . . . . 90
4.14 Bidding-Matrix - Lo¨sungsvorschlag des lp-solve . . . . . . . . . 90
4.15 Bidding-Matrix - Lo¨sungsvorschlag mit 35%-iger Abweichung . . 91
4.16 Reportformular - Konfiguration des Formulars . . . . . . . . . . 92
4.17 Reportformular - Radio Buttons Element . . . . . . . . . . . . . 94
4.18 Reportformular - Gerendertes Formular . . . . . . . . . . . . . . 95
4.19 Reportform - Kategorienzuweisung . . . . . . . . . . . . . . . . 96
4.20 JAXB - Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . 97
5.1 OCS - Kontrollflussdiagramm der Konferenzphasen . . . . . . . 102
5.2 Artikelzusta¨nde im Begutachtungsprozess . . . . . . . . . . . . . 105
6.1 Client-Server-Architektur des OCS . . . . . . . . . . . . . . . . 116
6.2 Schichtenmodell des OCS . . . . . . . . . . . . . . . . . . . . . . 117
7.1 Architektur: MOS, OCS, OJS, PPS . . . . . . . . . . . . . . . . 121
10.1 Fallstudie - Prozentuale Benutzung der Konferenzen: ta¨glich . . 145
10.2 Fallstudie - Vergleich FASE’02 und FASE’08: ta¨glich . . . . . . 146
10.3 Fallstudie - Prozentuale Benutzung der Konferenzen: stu¨ndlich . 147
10.4 Fallstudie - Vergleich FASE’02 und FASE’08: stu¨ndlich . . . . . 148
11.1 Agiles Prozessorientiertes Design . . . . . . . . . . . . . . . . . 158
11.2 Component-, Model-Based Design, and XMDD . . . . . . . . . 160
Tabellenverzeichnis
1.1 Vordefinierte Rollen im OCS . . . . . . . . . . . . . . . . . . . . 9
2.1 Feature-Vergleich der Begutachtungssysteme (Stand Juli 2009) . 26
2.2 Legende zu Tabelle 2.1 . . . . . . . . . . . . . . . . . . . . . . . 27
4.1 Auszug einiger OCS Features . . . . . . . . . . . . . . . . . . . 75
9.1 Einsatz der Dienstfamilie - Veranstaltungen . . . . . . . . . . . 140
10.1 Fallstudie - Eckdaten der analysierten Dienste . . . . . . . . . . 143
10.2 Fallstudie - FASE und TACAS Historie . . . . . . . . . . . . . . 144
10.3 Fallstudie - Statistik der Feature . . . . . . . . . . . . . . . . . . 149
10.4 Fallstudie - Globale Daten der Konferenzen . . . . . . . . . . . . 150
VII
Teil I
Motivation und Hintergrund
1
Kapitel 1
Einleitung
1.1 Motivation
Effiziente Entscheidungsfindungen sind in allen Bereichen der Gesellschaft und
der Industrie von ho¨chster Bedeutung. Entscheidungen werden in der Regel von
mehreren Personen bzw. Gruppen gemeinsam getroffen, was in Abha¨ngigkeit
von der Anzahl der Involvierten eine steigende Komplexita¨t der Terminfin-
dung und der Koordination zufolge hat. Die Aspekte der globalen Verteilung
der beteiligten Personen, die dadurch auftretenden Zeitzonen und die verschie-
denartigen Arbeitscharaktere bilden weitere Randbedingungen fu¨r die Komple-
xita¨t einer gemeinsamen Entscheidungsfindung und einer daraus resultierenden
Verzo¨gerung von Fristen.
Internetbasierte Software-Anwendungen sind pra¨destiniert fu¨r die systemge-
stu¨tzte Steuerung derartiger kooperativer Gescha¨ftsprozesse, wie Kommissions-
, Komitee-, oder Ausschusssitzungen. Sie vereinigen wichtige Merkmale in Be-
zug auf eine unterstu¨tzende Entscheidungsfindung und Echtzeitverhalten. Ins-
besondere die Bereitstellung der zugrunde liegenden Informationen unabha¨ngig
von Zeit und Ort (24x7 Verfu¨gbarkeit) und die Bedienbarkeit mittels eines
ga¨ngigen Internet-Browsers sind hier hervorzuheben. Arbeitsaufteilungen und
deren Zeitplanung, Kommunikationskomponenten und Konfliktbehandlungen
ko¨nnen in die Web-Anwendung integriert, und neu entwickelte Funktiona-
lita¨ten dem Benutzer auf einfache Weise personalisiert zuga¨nglich gemacht
werden. Daten und Ergebnisse sind vom Benutzer zu jeder Zeit zentralisiert
editierbar. Derartige CSCW (Computer Supported Cooperative Work) An-
3
KAPITEL 1. EINLEITUNG 4
wendungen dienen der Automatisierung von (wiederkehrenden) Abla¨ufen, was
zu einer effizienteren und insbesondere Kosten sparenden Abwicklung von
Gescha¨ftsprozessen fu¨hrt. Es ist nicht mehr erforderlich, die zu diskutieren-
den Dokumente aufwendig per Post oder Email zu versenden und zu verwal-
ten. Die Reisekosten fu¨r Treffen ko¨nnen auf wenige Termine reduziert und der
eigene Zeit- und Arbeitsaufwand minimiert werden. Mittels der “virtuellen”
Konferenz werden die Aspekte der Vorbereitungsphase einer “physikalisch”
stattfindenden Konferenz abgedeckt.
Einen klassischen Anwendungsfall stellen Begutachtungssysteme (peer review
systems) fu¨r Dokumente und Papiere im wissenschaftlichen Umfeld dar. Der
Umfang einer solchen Begutachtung setzt sich im Durchschnitt aus 150 zu
begutachtenden Papieren zusammen, die an ein Komitee von 20 - 30 Teilneh-
mern homogen zur Begutachtung zu verteilen sind, wobei pro Beitrag minde-
stens drei Gutachter aus dem Komitee ausgewa¨hlt werden. Der resultierende
Verwaltungs- und Koordinationsaufwand stellt fu¨r die Leiter eine große und
insbesondere fu¨r eine einzelne Person nur schwer lo¨sbare Herausforderung dar.
So ist es von gro¨ßter Wichtigkeit, im Vorfeld einer Konferenz eine gute Basis
fu¨r den Begutachtungsprozess zu schaffen, um eine ada¨quate Auswahl an Do-
kumenten und somit eine Qualita¨tssicherung der Konferenz zu gewa¨hrleisten.
Ende der neunziger Jahre hielten die ersten wenigen internetbasierten Begut-
achtungssysteme ihren Einzug in die Wissenschaftsgemeinde und revolutio-
nierten das Arbeiten fu¨r Organisatoren und Teilnehmer von wissenschaftlichen
Konferenzen. Dienten diese Systeme damals zur Abbildung der eigentlichen Be-
gutachtungsprozesse, unterstu¨tzen sie heutzutage den gesamten Ablauf einer
Konferenz (siehe Kapitel 1.2).
Der Online Conference Service (OCS 1) [LMS01, MK02, DDB+04, HBTE+05,
KM05, KM06, KMW08, OCS08], dessen Konzepte und Entwicklung den Kern
dieser Arbeit darstellen, reiht sich mit in die Gruppe der ersten Systeme ein,
die im Bereich der Begutachtung von wissenschaftlichen Arbeiten eine Vor-
reiterstellung einnehmen. OCS war eines der ersten State of the Art Systeme
fu¨r Begutachtungsprozesse, das den Begutachtungsworkflow mitbestimmt und
andere Begutachtungssysteme in ihrer Realisierung beeinflusst hat. Mit der
Konzeption und Umsetzung des OCS war ich Ende der Neunzigerjahre in die
Entstehungszeit der ersten Begutachtungssystemen involviert und hatte einen
direkten Bezug zum Kunden. Die umfassende Vertrautheit der Praxis, die ich
durch die Projektleitung, Programmierung, Serverbetreuung der Live-Systeme
1Die Leitung des OCS-Projektes wird am Lehrstuhl fu¨r Programmiersysteme an der
TU Dortmund durch Prof. Dr. B. Steffen und den Verfasser dieser Arbeit, Dipl. Ing. M.
Karusseit, durchgefu¨hrt.
KAPITEL 1. EINLEITUNG 5
und den Support der Dienstbenutzer erlangen konnte, haben die realisierten
Begutachtungssysteme, insbesondere den OCS, u¨ber die Jahre zu etablierten
Systemen herangewachsen lassen. Der OCS wird von Springer Heidelberg als
Begutachtungssystem fu¨r die LNCS-Reihe eingesetzt und erfu¨llt im Produkti-
onsbetrieb ho¨chste Anforderungen an Stabilita¨t.
OCS ist eine web-basierte Anwendung, die alle no¨tigen Gescha¨ftsprozesse und
Funktionalita¨ten eines Online-Entscheidungssystems in sich vereint. OCS bil-
det eine Dienstfamilie mit dem Online Journal Service (OJS) [HBTE+05],
dem Management Overview Service (MOS), Proceeding Production Service
(PPS) [Hol06], den Lecture Notes in Computer Science (LNCS) Proposal Ser-
vice, und den LNCS Transactions (siehe Kapitel 7).
Der OCS blickt nun auf eine zehnja¨hrige Geschichte zuru¨ck, in der er erfolg-
reich fu¨r die Vorbereitung von Konferenzen und Journals eingesetzt wurde.
Durch die stetig wachsende Anzahl von mehr als 30.000 Benutzern und den
daraus resultierenden und teilweise implementierten A¨nderungs- und Erwei-
terungswu¨nschen kann sich der OCS an ein weites Spektrum von Begutach-
tungsprozessen verschiedener Kommunities anpassen.
Ich arbeite seit 1999 mit dem Springer Verlag Heidelberg [Hei09c] als Projekt-
partner zusammen, der die Dienste fu¨r die bei LNCS [Hei09d] publizierenden
Tagungen einsetzt. Seit 2003 bietet Springer den OCS offiziell als Konferenz-
system an [Hei09b], das von 2007 an von Springer SBM 2 in Dordrecht, Nie-
derlande, gehostet wird.
Web-basierte Applikationen wie der OCS sind sehr komplexe Systeme, die
auf einer verteilten mehrschichtigen Softwarearchitektur beruhen (siehe Kapi-
tel 6.1 und 6.2). Aufgrund der stetig wachsenden Komplexita¨t der Systeme
ist es von großem Interesse, ein ada¨quates Entwicklungskonzept zu verwen-
den, um A¨nderungen oder Integrationen einerseits schnell und unkompliziert
durchfu¨hren und andererseits das gea¨nderte System auf dessen Funktion vali-
dieren zu ko¨nnen. Des Weiteren verwalten Begutachtungssysteme sensible Da-
ten, auf die mehrere Hundert Benutzer pro Konferenz in Abha¨ngigkeit ihrer
Rechte Zugriff erhalten. Es ist daher von zentraler Bedeutung, einen geeig-
neten Zugriffskontrollmechanismus zu verwenden, der unautorisierte Zugriffe
verhindert.
Der OCS ist ein Feature-basiertes System, das modular und komponentenba-
siert aufgebaut ist. Der Kontrollfluss (Gescha¨ftslogik) des OCS ist als gerich-
tete Graphen modelliert, wobei die Knoten die Dienstfunktionalita¨ten oder
Dienste selbst und die Kanten die U¨berga¨nge von Knoten zu Knoten darstel-
2Springer Science+Business Media
KAPITEL 1. EINLEITUNG 6
len. Diese Graphen ko¨nnen bereits zur Designzeit einer Applikation mittels
eines Modelcheckers auf zentrale Eigenschaften hin u¨berpru¨ft werden. Hierfu¨r
werden atomare Eigenschaften (Propositionen) an die Knoten der Graphen
annotiert. Die Verifikation der Systembeschreibung (Graphmodell) wird gegen
eine Spezifikation durchgefu¨hrt. Diese Spezifikation wird als temporal logische
Formel in CTL (Computation Tree Logic) geschrieben, die auf den annotierten
Propositionen aufbaut. Der Modelchecker u¨berpru¨ft diese Grapheigenschaften
und zeigt vorhandene Inkonsistenzen auf. Ein einfaches Beispiel ist die U¨ber-
pru¨fung des Zugriffs auf Seiten des internen Bereichs einer Applikation, der
nur mit einer erfolgreichen Authentifizierung zugelassen werden darf.
Diese Arbeit stellt ein neuartiges Konzept in der Entwicklung von komplexen,
Web-basierten Entscheidungssystemen vor, das bereits fru¨hzeitig den Service-
orientierten und modellgetriebenen Gedanken in sich vereinte. Die einheitliche
Vorgehensweise verfolgt neben der vereinfachten Entwicklung von komplexen
Anwendungen, in der ein Anwendungsexperte von Beginn an involviert wird,
die kontinuierliche Weiterentwicklung [Web99] der Anwendung. Die zentralen
Unterschiede zu anderen Entscheidungssystemen sind
• die Agilita¨t und Anpassbarkeit in Hinsicht auf die Modifikation eines
bestehenden Dienstes,
• die einfache Erweiterbarkeit durch einen modularen graphbasierten
Ansatz und
• die Zuverla¨ssigkeit und Sicherheit des Gesamtsystems durch den Ein-
satz von Model Checking [Ste91, MOSS99] und eines eigenen Zugriffs-
kontrollmechanismus, der ebenfalls mittels Model Checking verifizierbar
ist.
Diese Eigenschaften sind fu¨r die Softwareentwicklung von großer Bedeutung.
Softwaresysteme mu¨ssen auf neue Kundenanforderungen schnell und sicher
reagieren ko¨nnen. Schnell in der Hinsicht, dass ein Entwickler die entsprechen-
den Stellen im Quellcode findet und sicher in der Art, dass die Modifikationen
lauffa¨hig sind und keine bestehenden Dienstfunktionalita¨ten negativ beeinflus-
sen. Sind Anfragen zu sensiblen Daten zu bedienen, wie es bei Entscheidungs-
systemen vorrangig der Fall ist, ist es um so wichtiger, den gesicherten Zugriff
nach einer Modifikation zu gewa¨hrleisten. So wa¨re es zum Beispiel ein extre-
mes Problem, wenn nach einer A¨nderung die Autoren Zugriff auf die nicht
anonymisierten Gutachten erhalten und somit die Namen derer erfahren, die
ihren Artikel beurteilt haben.
KAPITEL 1. EINLEITUNG 7
Des Weiteren vergleicht diese Arbeit die Konzepte mit anderen Arbeiten aus
dem technischen und wissenschaftlichen Themengebiet (siehe Kapitel 2). Der
Fokus wird auf das Begutachtungssystem OCS und dessen Dienstfamilie gelegt,
es werden insbesondere der technologieunabha¨ngige Feature-orientierte Ent-
wicklungsansatz und ein darauf basierender flexibler, rollenbasierter Zugriffs-
kontrollmechanismus ero¨rtert. Weiterfu¨hrend werden Analysen, Erfahrungen
und Fallstudien aufgezeigt, die durch den Einsatz des OCS erforscht wurden.
Eine detailliertere Beschreibung der Inhalte und der Struktur dieser Arbeit
werden in den Kapiteln 1.3 und 1.4 aufgezeigt.
1.2 Entscheidungssystem
Ein Entscheidungssystem bildet Modelle zur Entscheidungsfindung ab, die in
Form eines Softwaresystems den Entscheidungsprozess unterstu¨tzen. Ein Ein-
satzgebiet von Entscheidungssystemen ist die Begutachtung von wissenschaft-
lichen Arbeiten. Begutachtungssysteme und deren Prozesse unterliegen einer
Reihe von Kriterien, Randbedingungen und Anforderungen, die im Folgenden
na¨her betrachet werden.
1.2.1 Begutachtungsprozess
Der generelle Ablauf einer Begutachtung fu¨r Artikel 3 besteht aus den folgen-
den vier Hauptphasen:
1. Einreichungsphase
2. Verteilungsphase der zu begutachtenden Artikel
3. Begutachtungsphase
4. Diskussions- und Entscheidungsphase
Ziel eines solchen Prozesses ist es, aus einer Menge von Artikeln unter Beru¨ck-
sichtigung verschiedener Gesichtspunkte ada¨quate Artikel zu selektieren. Die
angenommenen Artikel werden von den Autoren auf einer Konferenz vorge-
3Ein Artikel bezeichnet im wissenschaftlichen Umfeld das Ergebnis einer Forschungsarbeit
oder Fallstudie in schriftlicher Form.
KAPITEL 1. EINLEITUNG 8
tragen und in Form eines Tagungsbandes 4 oder Journals 5 vero¨ffentlicht. Die
Entscheidung u¨ber Akzeptanz oder Ablehnung eines Artikels trifft das Pro-
grammkomitee auf Basis von Gutachten. Das Programmkomitee setzt sich aus
dem Komiteeleiter und den Gutachtern zusammen. Die Kriterien der verschie-
denen Kommunities fu¨r die Akzeptanz eines Artikels stimmen nicht immer
vollsta¨ndig u¨berein. Zu den gemeinsamen Kriterien za¨hlen:
• die Einhaltung von Fristen, z.B. die der Einreichungsfrist,
• die Verwendung des vorgegebenen Formats (Stilvorgabe und Seitenzahl
des Artikels),
• die U¨bereinstimmung mit dem Fokus der Konferenz,
• und der innovative Anspruch an den Artikel.
Die wesentlichen Unterschiede liegen in den fu¨r die Entscheidung zugrunde lie-
genden Informationen, die in Form von Gutachten von den Komiteemitgliedern
verfasst werden. Die Vorlagen fu¨r die Gutachten weisen in den einzelnen Kom-
munities unterschiedliche Fragestellungen und Auswertungsfunktionen auf.
Konkreter Anwendungsfall
Es gibt eine Reihe von Anwendungsfa¨llen die einen Begutachtungsprozess wi-
derspiegeln. Im Folgenden wird ein konkreter in der Praxis mehrfach bewa¨hrter
Prozess einer Begutachtung am Anwendungsbeispiel des OCS vorgestellt.
Im OCS gibt es vordefinierte Rollen, die unterschiedliche Rechte und Sichten
auf die Features des Dienstes definieren. Die Namen der Rollen und deren
Funktionen sind in Tabelle 1.1 beschrieben.
Der OCS verfu¨gt u¨ber ein rekonfigurierbares Rollen/Rechte-System, das die
Modifikation der vordefinierten Rollen erlaubt und den PC Chair in die Lage
versetzt, neue Rollen zu definieren. Durch diese Flexibilita¨t kann der OCS
speziell auf Kommunities mit abweichenden Rollen angepasst werden.
Abbildung 1.1 zeigt vereinfacht den Haupt-Begutachtungsprozess des OCS und
die in ihm involvierten Rollen. Der Begutachtungsprozess startet bei Konferen-
zen mit dem Call for Papers. Der Aufruf beinhaltet die no¨tigen Daten wie Kon-
ferenzname, Homepage, Themengebiete, Deadlines, Bedingungen, Tagungsort
4Ein Tagungsband beinhaltet Informationen u¨ber die Konferenz, das Fachgebiet, die Or-
ganisatoren und die Artikel.
5Journals sind Zeitschriften die eine Auswahl (“special sections”) von bereits vero¨ffent-
lichten Artikeln in einem Fachgebiet vero¨ffentlichen.
KAPITEL 1. EINLEITUNG 9
Author Reicht ein oder mehrere Artikel zur Konferenz ein.
CoAuthor Ist Mitverfasser eines Artikels.
PC Member Ist fu¨r die Begutachtung von Artikeln zusta¨ndig und
bestimmt mit, welche Artikel angenommen bzw.
abgelehnt werden.
SubReviewer Eine optionale Rolle, die den PC Member bei der
Erstellung von Gutachten unterstu¨tzt.
PC Chair Diese Rolle leitet und koordiniert die Computerunter-
stu¨tzte Konferenz.
Administrator U¨bernimmt die technische Verwaltung des Dienstes.
Tabelle 1.1: Vordefinierte Rollen im OCS
und die Kontaktdaten der Organisatoren. Autoren werden dazu aufgefordert,
Forschungsergebnisse, Tool-Pra¨sentationen oder Fallstudien in vorgegebener
schriftlicher Form einzureichen.
Nach einer erfolgreichen Registrierung u¨ber den OCS ko¨nnen die Autoren ih-
ren Artikel elektronisch in das Entscheidungssystem hochladen. Der Dienst
stellt hierfu¨r ein Einreichungsformular zur Verfu¨gung, das die Metadaten und
eine druckbare elektronische Version (u¨berwiegend PDF) des Artikels verlangt.
Zu den Metadaten geho¨ren in erster Linie der Titel des Artikels, Namen und
Kontaktdaten aller Autoren, das Themengebiet und eine Zusammenfassung
des Artikelinhaltes (Abstract). Optional kann dieser Einreichungphase des
Artikels die Einreichung von Abstracts vorgeschaltet werden, die nur die Meta-
daten beno¨tigt. Dieses dient den Organisatoren der Konferenz dazu, fru¨hzeitig
einen ersten U¨berblick u¨ber die potentiellen Autoren und deren Einreichun-
gen zu erlangen. Insbesondere die Zuordnung der Artikel zu den Gutachtern
kann bereits in der Einreichungsphase geschehen und eventuelle Lu¨cken an
Fachkompetenz durch Aquirierung von zusa¨tzlichen Gutachtern ausgeglichen
werden (vgl. Schritt 1 “submit article” in Abb. 1.1).
Nach Beendigung der Einreichungsphase beginnt die Verteilungsphase fu¨r
den Leiter der Konferenz, dem PC Chair (vgl. Schritt 2 “delegate article”
in Abb. 1.1). Er erha¨lt zu jeder Einreichung vom Dienst automatisch eine
Benachrichtigung via Email zugesandt und kann direkt auf den neuen Artikel
reagieren. Die Verteilung der Artikel an die PC Member kann entweder manuell
geschehen oder unter Verwendung der automatisierten Verteilungskomponente
des OCS (siehe Kapitel 4.3). Bei einer durchschnittlichen Einreichungsanzahl
von 150 Artikeln und einer Begutachteranzahl von drei pro Artikel, ergeben
sich 450 Verteilungen. Zum Beispiel hatte die Konferenz Tools and Algorithms
KAPITEL 1. EINLEITUNG 10
Abbildung 1.1: Vereinfachter OCS-Begutachtungsprozess
for the Construction and Analysis of Systems 2009 (TACAS 2009) 6 eine An-
zahl von 131 Artikeln und eine daraus resultierende Verteilungszahl von 441,
bedingt durch die Verteilung von mehreren Artikeln an vier Gutachter. Die in
China stattfindende Konferenz Advanced Data Mining And Applications 2009
(ADMA) geho¨rt mit 322 Artikeln, 1169 Verteilungen und 795 Benutzern zu
den gro¨ßeren Konferenzen.
Die Begutachtungsphase (vgl. Schritt 3 “write report” in Abb. 1.1) beginnt,
sobald die Artikel verteilt werden und die entsprechenden PC Members eine
Benachrichtigung via Email vom OCS erhalten. Die PC Member sehen sich die
ihnen zugewiesenen Artikel an und entscheiden, ob sie diese begutachten wol-
len oder nicht. Ein Grund der Ablehnung kann die fehlende Fachkompetenz in
der Thematik des Artikels oder der wissenschaftliche Kontakt mit den Auto-
ren sein, was unter Umsta¨nden einen Einfluss auf das Ergebnis des Gutachtens
6TACAS 2009 ist eine Hauptkonferenz der European Joint Conferences on Theory and
Practice of Software (ETAPS)
KAPITEL 1. EINLEITUNG 11
zufolge ha¨tte. Im Falle der Ablehnung informiert der OCS den PC Chair und
bietet den Artikel zur erneuten Zuweisung an. Optional kann der PC Member
seine zugewiesenen Artikel an SubReviewer weiterleiten. Mittels der Gutachten
der SubReviewer schreibt der PC Member anschließend sein eigenes Gutachten.
Dieses ist ein verbreiteter Vorgang, da PC Members unter Umsta¨nden in meh-
reren Programmkomitees involviert sind und im Durchschnitt pro Konferenz
10-20 Artikel begutachten mu¨ssen. Aufgrund das zeitgleich viele Gutachten zu
schreiben sind, ist es auch im Sinne des PC Chairs, dass der PC Member bei
fehlender Kompetenz selber einen ada¨quaten SubReviewer mit entsprechender
Facherfahrung sucht und in den Begutachtungsprozess involviert.
Nachdem die Gutachten eingegangen sind, ero¨ffnet der PC Chair dieDiskussi-
ons- und Entscheidungsphase, in der u¨ber die Auswahl der Artikel entschie-
den wird. OCS stellt fu¨r jeden Artikel ein Diskussionsforum zur Verfu¨gung, auf
das die PC Member in Abha¨ngigkeit ihrer Themengebiete Zugriff haben. Die
Teilnehmer eines Diskussionsforums erhalten bei jeder neuen Nachricht im Fo-
rum eine Mitteilung via Email. Die Email entha¨lt fu¨r den Teilnehmer ein Ticket
fu¨r den direkten Zugang zum Forum. Das Ticket ist nur einmalig verwendbar
und bietet einen schnellen und direkten Zugriff. Die Diskussion (vgl. Schritt
4 “discussion” in Abb. 1.1) u¨ber die Annahme oder Ablehnung eines Artikels
la¨sst sich unterteilen in die lokale und globale Diskussion:
• Lokale Diskussion: Die PC Members, die einen Report zu einem Ar-
tikel geschrieben haben, und der PC Chair diskutieren den Artikel. Die
PC Members vergleichen ihre Gutachten und ero¨rtern ein gemeinsames
Ergebnis.
• Globale Diskussion: Nach der lokalen Diskussion existiert meist eine
noch zu große Anzahl von Artikeln die wu¨rdig wa¨ren, bei der Tagung
vorgetragen und letztendlich vero¨ffentlicht zu werden. Nun erhalten alle
PC Member Zugriff auf alle Reports und Diskussionsforen. Ziel ist es,
aus den zur Akzeptanz vorgeschlagenen Artikeln diejenigen zu filtern,
die tatsa¨chlich auf der Tagung vorgetragen werden sollen.
Der PC Chair schreibt nach Festlegung der Entscheidung ein Gesamtgutachten
fu¨r die angenommenen und abgelehnten Artikel (vgl. Schritt 5 “write final
report” in Abb. 1.1). Die Autoren erhalten via Email den Hinweis, dass die
Gutachten anonym online zuga¨nglich sind. Autoren mit einem akzeptierten
Artikel mu¨ssen eventuelle A¨nderungen und Verbesserungsvorschla¨ge einpflegen
sowie die endgu¨ltige Version des Artikels samt Quelldateien hochladen (vgl.
Schritt 6 “submit final version” in Abb. 1.1).
KAPITEL 1. EINLEITUNG 12
Die akzeptierten Artikel werden anschließend in einem Tagungsband von ei-
nem Verlag vero¨ffentlicht und bilden die Grundlage fu¨r die Tagung, an der das
Komitee, die Vortragenden (Autoren der Artikel) und weitere interessierte Per-
sonen teilnehmen. Zu den vorbereitenden Gescha¨ftsprozessen einer Konferenz
geho¨rt daru¨ber hinaus die Registrierung als Teilnehmer, die Buchung eines
Hotels und eventuelle des Fluges und Beantragung eines Visums. In Kapitel 5
wird na¨her auf diese Details eingegangen.
1.2.2 Allgemeine Anforderungen
Die allgemeinen Anforderungen an ein Entscheidungssystem ha¨ngen von den
Einsatzbedingungen und der Komplexita¨t des Systems ab. Sind große hetero-
gene Benutzergruppen zu bedienen, mit ha¨ufig wechselnden oder wachsenden
Anforderungen der Dienstfunktionalita¨ten ist ein flexibler Ansatz in Bezug auf
Softwaredesign und Softwarearchitektur zu wa¨hlen. Ein weiterer Aspekt ist der
Bereich der Verwendung. Es muss analysiert werden, fu¨r welche Technologien
und Softwareplattformen die zu entwickelnde Anwendung zu konzipieren ist.
Eventuelle Anwendungsgebiete ko¨nnen sein
• Desktop-Anwendungen,
• internetbasierte Applikationen, oder
• mobile Anwendungen fu¨r Handys oder PDAs.
Die Anforderungen an ein Softwaresystem ko¨nnen in die zwei Kategorien der
Benutzersicht und der Realisierung und Softwarearchitektur aufgeteilt wer-
den. Fu¨r Entscheidungssysteme, insbesondere fu¨r Begutachtungssysteme, las-
sen sich die nachstehenden allgemeinen Anforderungen aus der Benutzersicht
zusammenfassen:
• Intuitive Bedienbarkeit der grafischen Benutzeroberfla¨che (GUI 7).
• Globaler Zugriff auf das System und deren Daten.
• Kurze Wartezeiten (Latenzzeiten) von der Anforderung neuer Da-
ten bis zu deren Visualisierung.
• Transparenz des Prozesses der getroffenen Entscheidungen.
7Graphical User Interface
KAPITEL 1. EINLEITUNG 13
• Entscheidungsunterstu¨tzung durch Diskussions-, Bewertungs-, und
Auswertungskomponenten.
• Anpassbarkeit auf verschiedene Kommunities.
• Zentralisierte Darstellung relevanter Daten.
• Verfu¨gbarkeit des Dienstes (24x7).
• Sicherheit von sensiblen Daten.
Unter Beru¨cksichtigung dieser allgemeinen Anforderungen aus der Sicht eines
Dienstbenutzers lassen sich die folgenden allgemeinen Anforderungen an die
Realisierung und Softwarearchitektur spezifizieren:
• Internetbasierte Applikation zur globalen Bereitstellung von Gescha¨fts-
prozessen.
• Heterogenes verteiltes System fu¨r die Realisierung des Gesamtsy-
stems.
• Modularita¨t und Wiederverwendbarkeit von Softwarekomponen-
ten und Diensten.
• Erweiterbarkeit und Modifizierbarkeit des Softwaresystems.
• Plattformunabha¨ngigkeit zur Installation auf unterschiedlichen Be-
triebssystemen.
• Verfu¨gbarkeit des System.
Die Anforderungen bilden die Basis fu¨r die Evaluierung der geeigneten Pro-
grammiersprache, des Softwaredesigns, der Softwarearchitektur und der zu ver-
wendenden Software-Bibliotheken.
1.2.3 Online Conference Service (OCS): Anforderungen
Die im Kapitel 1.2.2 dargestellten Anforderungen sind in den gut konzipier-
ten Softwaresystemen von Bedeutung. An den OCS wurden daru¨ber hinaus
folgende erga¨nzende Anforderungen und Leistungsmerkmale gestellt, die zur
Entstehungszeit des OCS, im Jahre 1999, maßgeblich fu¨r das System waren:
KAPITEL 1. EINLEITUNG 14
• Konfigurierbarkeit zur Laufzeit und die dadurch flexible Anpassung
des Dienstes an die Bedu¨rfnisse unterschiedlicher Konferenzen. Dieses
beinhaltet die Bereiche GUI, Zugriffsrechte, Personalisierung und A¨nde-
rung des Gescha¨ftsprozesses durch Ein- bzw. Ausschaltung von Dienst-
funktionalita¨ten.
• Dokumentenmanagement fu¨r die Verwaltung der eingereichten Arti-
kel und Gutachten. Von zentraler Bedeutung ist die online konfigurierba-
re Benutzeroberfla¨che, die es ermo¨glicht, Formulare fu¨r die Einreichung
von Gutachten online zu erstellen (siehe Kapitel 4.4). Von großem Inter-
esse ist ebenfalls die Versionierung mittels derer die Historie von der er-
sten bis zur finalen Artikelversion nachvollzogen werden kann. Das ist fu¨r
die Gutachter notwendig, um die u¨berarbeiteten Artikelversionen auf die
im Gutachten festgelegten A¨nderungshinweise hin u¨berpru¨fen zu ko¨nnen.
• Flexible Erweiterbarkeit des Entscheidungssystems durch neue Dienst-
funktionalita¨ten oder Teildienste. Integrationen und Modifikationen der
Gescha¨ftslogik und der Businessobjekte sollen einfach und u¨bersichtlich
durchgefu¨hrt werden ko¨nnen.
• Zugriffskontrollmechanismus fu¨r die Identifizierung und Authentifi-
zierung von Benutzern des Dienstes. Dieses basiert auf einem Benutzer-
und Rollensystem (siehe Kapitel 4.2).
• Personalisierung der Benutzersicht auf die Dienstfunktionalita¨ten und
die sensiblen Daten. Die Benutzer erhalten in Abha¨ngigkeit von ihren
Zugriffsrechten 8 und der Konferenzphase den Status der im Begutach-
tungsprozess befindlichen Beitra¨ge sowie eine fu¨r sie maßgeschneiderte
Sicht auf den Dienst.
• Fristenmanagement fu¨r die Verwaltung und U¨berwachung von Deadli-
nes zur Einhaltung des geplanten Begutachtungszeitraumes. Sind Fristen
fu¨r die Erfu¨llung von Aufgaben abgelaufen, erhalten die Gutachter eine
Benachrichtigung. Dieses kann das Verfassen eines Gutachtens sein, oh-
ne dessen die na¨chste Phase des Begutachtungsprozesses nicht eingeleitet
werden kann. Des Weiteren u¨berwacht das Fristenmanagement die ein-
zelnen Phasen der Konferenz, die zu Beginn der Konferenz durch den PC
Chair mit Zeitfristen annotiert werden. Dadurch sind automatische Pha-
senu¨berga¨nge mo¨glich, bei denen zuvor erlaubte Ta¨tigkeiten, wie z.B. das
8Zugriffsrechte erteilen dem Besitzer des Rechtes die Erlaubnis, bestimmte Funktiona-
lita¨ten zu nutzen.
KAPITEL 1. EINLEITUNG 15
Einreichen eines Beitrages, den Benutzern automatisch entzogen werden
ko¨nnen.
• Konfliktbehandlung ermo¨glicht das Kennzeichnen eines Konfliktes zwi-
schen einem potentiellen Gutachter und den Autoren eines Artikels. Ein
Konflikt besteht, wenn der Gutachter dem Autor perso¨nlich nahe steht
oder abgeneigt ist, oder selbst Autor des Artikels ist. Die Konflikte wer-
den im gesamten Dienst zur Filterung von den zur Anzeige aufbereiteten
Daten beru¨cksichtigt. Somit wird gewa¨hrleistet, dass Benutzer mit Kon-
flikten nicht an vertrauliche Daten gelangen.
• Die Verteilungskomponente unterstu¨tzt den PC Chair wa¨hrend der
Delegierung von Begutachtungen. Verteilungen ko¨nnen geplant, von den
PC Members selbst vorgeschlagen, oder mit einem Verteilungsalgorith-
mus unter Verwendung eines Lo¨sungsverfahrens fu¨r lineare Probleme au-
tomatisch bestimmt werden.
• Die Benutzerverwaltung bietet eine Managementkomponente fu¨r Be-
nutzerdaten an. Unter anderem ko¨nnen Benutzer angelegt und entfernt
werden. Benutzerprofile und Accountdaten sind modifizierbar.
• Die Kommunikationskomponente des OCS verfu¨gt u¨ber eine Email-
und Forenfunktionalita¨t. Automatische Dienstemails werden u¨ber vorge-
schriebene Emailtemplates realisiert, die zur Laufzeit mit den relevanten
Daten gefu¨llt werden. Der PC Chair ist in der Lage, Mitteilungen an alle
Empfa¨nger einer oder mehrerer Rollen zu schreiben. Die Foren dienen
als Diskussionsplattform zur Bestimmung der akzeptierten Artikel.
• Die Entscheidungkomponente in Form der Evaluationsmatrix bietet
eine U¨bersicht u¨ber die Begutachtungen und ermittelt eine Rangliste der
Artikel, auf Basis eines gewichteten Mittelwertes. Dieser Mittelwert wird
aus den Bewertungen, die von den Gutachtern in ihren Reports bestimmt
wurden, berechnet.
• Verifizierbarkeit ist mit die wichtigste Anforderung an den OCS. Bei
einem System, das sta¨ndiger Weiterentwicklung unterworfen ist, ist eine
automatische U¨berpru¨fung der Funktionalita¨ten von großem Interesse.
Ende der Neunzigerjahre existierten kaum standardisierte Frameworks fu¨r die-
se Art von Anforderungen. Es war die Zeit, als der Boom um die IT-Branche
begann, und proprieta¨re web-basierte Lo¨sungen ins Leben gerufen wurden und
den Markt u¨berschwemmten. Die IT erkannte das Potential, komplexe Anwen-
dungen als Web-Applikationen zu realisieren.
KAPITEL 1. EINLEITUNG 16
Als Entwicklungsumgebung fu¨r das Projekt OCS wurde das Agent Building
Center (ABC) [SM99, SMCB96] der Firma METAFrame verwendet. Die mo-
dellgetriebene Vorgehensweise des ABC hatte sich bereits im IN 9 Bereich [IT92,
ITU93] etabliert und wurde fu¨r die Modellierung von Testszenarien fu¨r große
Telefonanlagen erfolgreich eingesetzt [NMH+01, NSM+01]. Das Konzept des
ABC sieht eine vereinfachte, fu¨r den Anwendungsexperten versta¨ndliche Form
der Gescha¨ftsmodellierung vor. Die direkte Einbindung von Anwendungsexper-
ten in die Realisierung war und ist ein wesentlicher Aspekt des ABC [MS04a].
Andere Umgebungen fu¨r die Modellierung von Gescha¨ftsprozessen wie LEU
[DGSZ94, Bra01] oder MOKASSIN [HG98, Bra01] richteten sich an Benutzer,
die tiefere Kenntnisse in der Programmierung haben mussten. Das ARIS 10-
Konzept [Sei02], basierend auf der verbreiteten Modellierungssprache EPK 11,
beinhaltete die Modellierung von Gescha¨ftsprozessen, aber zum damaligen
Zeitpunkt nicht die Generierung der ausfu¨hrbaren Gescha¨fztsprozesse. Heutzu-
tage wird dieses durch die Einbindung von UML 12 nur indirekt gelo¨st. Mittler-
weile existieren standardisierte Prozessbeschreibungs- und Ausfu¨hrungsspra-
chen. Hierzu za¨hlt die im Jahre 2002 von der BPMI 13 vero¨ffentlichte gra-
fischen Notation BPMN 14 [WM08], die seit 2006 offizieller OMG-Standard
fu¨r die Modellierung von Gescha¨ftsprozessen ist. Die erstellten Modelle lassen
sich in Ausfu¨hrungssprachen wie z.B. der BPML 15 oder BPEL4WS 16 imple-
mentieren. XPDL 17 ist eine weitere Prozessbeschreibungssprache, die von der
WfMC 18 entwickelt wird.
Mittels des ABC ließen sich schon zur Entstehungszeit des OCS web-basierte
Anwendungen strukturiert entwickeln, indem die Gescha¨ftslogik der Anwen-
dung durch gerichtete Graphen modelliert wurde. A¨nderungen und Erweite-
rungen an der Logik lassen sich noch heute auf einfache Weise am Kontroll-
flussgraphen durchfu¨hren. Die Realisierung und Wartung von Systemen mittels
des ABC stellt ein einheitliches Vorgehen dar [MS09, SN07] und unterstu¨tzt
Entwicklungs- und Anwendungsexperten gleichermaßen. Des Weiteren lassen
sich die Graphen mit temporal logischen Formeln auf ihre Gu¨ltigkeit u¨ber-
9intelligent networks
10Architektur Integrierter Informationssysteme von Prof. August-Wilhelm Scheer seit 1993
entwickelt.
11Ereignisgesteuerte Prozesskette von Prof. August-Wilhelm Scheer
12Unified Modelling Language
13Business Process Management Initiative
14Business Process Modeling Notation
15Business Process Modeling Language
16Business Process Execution Language for Web Services
17XML Process Definition Language
18Workflow Management Coalition
KAPITEL 1. EINLEITUNG 17
pru¨fen. Mit dem Model Checking la¨sst sich bereits zur Modellierungsphase
die geplante Anwendung testen. Mittlerweile wurde das ABC vom JavaABC
(jABC) [Nag09] abgelo¨st. Diese Neuentwicklung des ABCs auf Basis von JA-
VA [mic09l] entstand am Lehrstuhl fu¨r Programmiersysteme der TU Dort-
mund. Das jABC/ABC wird im Kapitel 3.1 detaillierter beschrieben.
Der OCS ist in der objektorientierten Programmiersprache Java entwickelt
und basiert auf der Servlet-Technologie. Die Visualisierung der angeforderten
Daten wird u¨berwiegend mittels HTML umgesetzt. OCS baut auf dem Model
View Controller (MVC) Konzept auf, das eine Applikation in die drei Bereiche
• Datenmodell,
• Pra¨sentationsebene,
• Programmsteuerung
trennt.
Ziel dieses Konzeptes ist es, Modifikationen und Erweiterungen zu erleichtern.
Des Weiteren ko¨nnen Bereiche ausgetauscht oder in anderen Projekten durch
ihre Kapselung wiederverwendet werden.
Durch die Verwendung des ABCs wird das MVC Konzept um eine Schicht
erweitert. Diese Koordinationsschicht spiegelt die graphische Modellierungs-
ebene des ABC wider. Dieser erweiterte Ansatz des MVC-Modells wird als
Lightweight Process Coordination approach [MS04b] bezeichnet. Das Konzept
Aggressive model-driven development (AMDD) [MS04a, MS08] beruht auf dem
erweiterten MVC Konzept und ermo¨glicht Personen ohne tiefere Kenntnisse
u¨ber die Diensttechnik, Anwendungen zu entwerfen.
Die fu¨r die Umsetzung des OCS verwendeten Konzepte, Architekturen und
Technologien werden spa¨ter in dieser Arbeit genauer gezeigt.
1.3 Eigener Beitrag
Die von mir konzipierten und realisierten Entscheidungssysteme bilden die
Basis fu¨r meine Arbeit. Es wurden dabei grundsa¨tzliche Konzepte und Vorge-
henweisen im Bereich der Entwicklung von Begutachtungssystemen entworfen,
die im Fokus stehen. Meine Anteile an den im Rahmen meiner Dissertation
vorgestellten Ergebnissen umfassen insbesondere die folgenden Bereiche:
KAPITEL 1. EINLEITUNG 18
• Enwicklungskonzept: Die Umsetzung und Beschreibung eines Ent-
wicklungskonzeptes zur Umsetzung von agilen web-basierten Begutach-
tungssystemen, wie es der OCS repra¨sentiert, ist ein zentraler Punkt in
dieser Arbeit. Der konzipierte Feature-orientierte Ansatz (siehe Kapi-
tel 4.1) fußt auf dem graphbasierten Konzept des ABCs und stellt die
Dienstkomponenten in Form von Features in Beziehung. Die dadurch er-
zielte Benennung und Gruppierung der Dienstfunktionalita¨ten, und die
daraus folgende strukturierte Hierarchie der Features ist der Grundstein
fu¨r die Personalisierung der Begutachtungssysteme, die mittels eines eige-
nen Zugriffskontrollmechanismus (siehe Kapitel 4.2) realisiert wurde. Die
Repra¨sentation des Kontrollflusses einer Applikation durch graphbasier-
te Modelle ermo¨glicht auf einfache Weise visuell auf neue bzw. gea¨nderte
Anforderungen zu reagieren. Diese Vorgehensweise hat sich bereits im
Bereich der Entscheidungssysteme bei den Projekten OCS, OJS, LN-
CS und Transactions etabliert (siehe Kapitel 7) und wurde in [KM05]
vero¨ffentlicht.
• Personalisierung: Die Konzeption und Realisierung eines Zugriffskon-
trollmechanismus und dessen Integration in die Entscheidungssysteme ist
ein weiterer wesentlicher Punkt. Der Mechanismus stellt einen sicheren
Umgang mit sensiblen Daten dar und geht einher mit der graphbasierten
Konzeption der Systeme. Eine Erweiterung des Mechanismus durch den
Ansatz eines direkten Benutzer/Rechte-Modells bewirkte eine Steigerung
der Flexibilita¨t im Bezug auf die Vergabe von Rechten. Der Zugriffskon-
trollmechanismus und dessen Erweiterung werden im Kapitel 4.2 na¨her
vorgestellt und wurde in [KM06] vero¨ffentlicht.
• Komponenten-Realisierung: Des Weiteren war ich verantwortlich fu¨r
die Konzeption und Realisierung der fu¨r die Begutachtungssysteme zu-
grunde liegenden Features. Basierend auf diese Features kann auf einfa-
che Weise mittels des graphbasierten Ansatzes neue Dienste erstellt bzw.
vorhandene erweitert werden. In dieser Arbeit wird auf die Konzepte
und Umsetzung zweier Features detaillierter eingegangen. Sie haben ei-
nerseits zu einer wesentlichen Arbeitserleichterung der Konferenzleitung
und andererseits zur flexiblen Anpassbarkeit an verschiedene Kommuni-
ties beigetragen:
– Der Bidding-Mechanismus, vorgestellt im Kapitel 4.3. Dieses Fea-
ture realisiert eine Verteilungskomponente, die auf Basis der linea-
ren Optimierung Lo¨sungen fu¨r Verteilungsprobleme bestimmt. Die
Komponente hat sich bereits in vielen wissenschaftlichen Konferen-
zen bewa¨hrt, indem sie die Konferenzleitung wa¨hrend der Planung
KAPITEL 1. EINLEITUNG 19
und Durchfu¨hrung der Verteilung von Artikeln an die Gutachter
unterstu¨tzt hat.
– Die XML-basierten, konfigurierbaren Bewertungskomponente, mit
deren Hilfe Begutachtungsformulare online erstellt und Auswertungs-
formeln definiert und integriert werden ko¨nnen (siehe Kapitel 4.4).
Diese Flexibilita¨t der Anpassbarkeit von Formularen ist ein wichti-
ges Kriterium, um Anforderungen der Wissenschaftsgemeinden zu
erfu¨llen.
• Validierung und Fallstudien: Der temporal logische Ansatz fu¨r die
graphbasierte Modellierung des OCS, wurde den bekannten Ansa¨tzen
XACML und WS-Policy gegenu¨bergestellt (siehe Kapitel 2.2) und in
[KMW08] vero¨ffentlicht. Fallstudien u¨ber den Einsatz und die Verwen-
dung des OCS wurden ebenfalls durchgefu¨hrt (siehe Kapitel 10) und
in [MK02] vero¨ffentlicht. Anhand der Fallstudien lassen sich die reali-
sierten Features auf deren Verwendung hin analysieren und getroffene
Designentscheidungen u¨berpru¨fen bzw. neue bestimmen.
1.4 Aufbau der Dissertation
Im Folgenden wird die Struktur der Dissertation, die in 6 Teile aufgeteilt
wurde, erla¨utert.
Teil I dient zur Einfu¨hrung in diese Arbeit. Nach dem einleitenden Kapitel 1
wird im Kapitel 2 das technische und wissenschaftliche Umfeld in einer Studie
vorgestellt. Die Anwendung OCS und dessen Konzepte werden mit anderen
existierenden Systemen verglichen.
Teil II beschreibt die fu¨r die Entwicklung des OCS verwendeten Technologien
und dient als Basis fu¨r die darauf folgenden Teile der Dissertation. In Kapitel 3
werden die fu¨r den OCS eingesetzten Frameworks erla¨utert und die Verifikation
von Graphmodellen eingefu¨hrt. Das Kapitel 4 stellt die realisierten Konzepte
fu¨r eine flexible konfigurierbare web-basierte Softwareentwicklung dar, was eine
Vorstellung der Verifikation an einem konkreten Beispiel beinhaltet.
Teil III geht auf das Entscheidungssystem OCS im Einzelnen ein. In Kapitel 5
werden Gescha¨ftsprozesse und die wichtigsten Features beschrieben. Kapitel 6
stellt das Design und die Architektur des Dienstes vor. Die Dienstfamilie des
OCS und die Analyse verschiedener in der Dienstfamilie verwendeter Techno-
logien werden im Kapitel 7 beschrieben.
Teil IV widmet sich der Darstellung von Erfahrungen im Bereich der Ent-
KAPITEL 1. EINLEITUNG 20
wicklung einer komplexen Web-Applikation. Design-Entscheidungen und de-
ren Auswirkungen werden in Kapitel 8 aufgezeigt, der bisherige Einsatz des
Dienstes in Kapitel 9 dokumentiert, und die Verwendung des OCS durch eine
Fallstudie in Kapitel 10 ero¨rtert.
Teil V entha¨lt mit Kapitel 11 eine Zusammenfassung der vorgestellten Arbeit
und gibt einen Ausblick auf mo¨gliche Erweiterungen.
Kapitel 2
Verwandte Arbeiten
In diesem Kapitel wird ein Bezug der in dieser Arbeit vorgestellten Themen
zu verwandten Arbeiten im wissenschaftlichen und technischen Bereich auf-
gezeigt. Kapitel 2.1 gibt einen U¨berblick u¨ber andere Begutachtungssysteme
(peer review systems) und stellt Unterschiede zum OCS heraus. Der eigene
Entwicklungsansatz fu¨r Web-Applikationen wird im Hinblick auf die Zugriffs-
sicherheit auf sensible und vertrauenswu¨rdige Daten unter Verwendung von
Policies und Model Checking in Kapitel 2.2 mit den Technologien WS-Policy
und XACML verglichen. Kapitel 2.3 zeigt Vorgehensmuster (Patterns) fu¨r die
Durchfu¨hrung von Begutachtungen auf und setzt diese mit den Vorgehenswei-
sen des OCS in Beziehung.
2.1 Begutachtungssysteme
Seit Ende der neunziger Jahre sind eine Reihe von webbasierten Begutach-
tungssystemen entwickelt und fu¨r internationale Konferenzen eingesetzt wor-
den. Einige von ihnen wurden in einer Zusammenfassung u¨ber Conference Ma-
nagement Software verglichen [Sno09], von denen heute nur noch wenige ihren
Einsatz finden. Im Bereich der wissenschaftlichen Begutachtungssysteme kom-
men stetig neue Systeme mit mehr oder weniger großem Erfolg auf den Markt.
Im Folgenden wird neben dem Online Conference Service der Fokus auf die in
der Wissenschaftsgemeinde bekannten Systeme ConfMaster [Pre09b] [Pre09c],
Continue [Kri09], Conference Reviewing System (CRS) [Sof09], CyberChair
[Sta01] [vdS09a]/ CyberChairPRO [vdS09b], EasyChair [Vor09], Editor’s As-
sistant (EDAS) [Sch09], Editorial Manager [Ari09], OpenConf [Gro09] und
START V2 Conference Manager [GG09] gelegt. In Kapitel 2.1.1 werden die
21
KAPITEL 2. VERWANDTE ARBEITEN 22
erwa¨hnten Begutachtungssysteme kurz vorgestellt, um sie anschließend in Ka-
pitel 2.1.2 auf zentrale Features hin zu diskutieren.
2.1.1 Vorstellung verwandter Systeme
Dieses Kapitel dient zur kurzen Einleitung der relevanten Systeme.
ConfMaster
Zwischen 1997 bis 2000 wurde das Begutachtungssystem ConfMan [Pre09a,
Pre09b] von Ketil Lund, Pal Halvorsen und Thomas Preuss entwickelt. Im Jahr
2003 wurde ConfMaster auf Basis von ConfMan implementiert und von Pro-
fessor Thomas Preuss herausgegeben. Die Entwicklung und das Design wurden
hauptsa¨chlich von Bastian Bo¨ing durchgefu¨hrt. ConfMaster [Pre09b] ist eine
Web-basierte Applikation, die auf der LAMP 1 Plattform aufbaut. Das Unter-
nehmen Coniant [Pre09c] bietet den Dienst fu¨r Konferenzen auf firmeneigenen
Servern kommerziell an.
Continue
Die erste Version des Begutachtungssystems wurde von Shriram Krishnamur-
thi entwickelt und erstmalig im Jahr 2002 fu¨r Konferenzen eingesetzt. In der
Zwischenzeit ist die neue Version Continue 2.0 [Kri09] im Einsatz, die auf
eine Ajax-basierte Architektur beruht. Momentan ist Arjun Guha verantwort-
lich fu¨r die Weiterentwicklung des Systems. Das Begutachtungssystem wird
kostenlos angeboten und gehostet.
CRS
Das Conference Reviewing System CRS [Sof09] wird seit 2002 von dem Un-
ternehmen RedWhale Software kommerziell fu¨r Konferenzen angeboten. Ent-
wickelt ist die Applikation mit der ASP 2 Technologie und wurde Skript-basiert
umgesetzt. Konferenzen werden auf den firmeneigenen Servern von RedWhale
verwaltet und gepflegt.
1Das Akronym LAMP steht fu¨r die Kombination der freie Software Linux, Apache, My-
SQL und Perl, wobei das P auch fu¨r PHP oder Python stehen kann.
2ASP steht fu¨r Active Server Pages
KAPITEL 2. VERWANDTE ARBEITEN 23
CyberChair/CyberChairPRO
CyberChair [vdS09a] wurde im Jahr 1996 das erste Mal eingesetzt. Entwickler
des Begutachtungsystems ist Richard van de Stadt. CyberChair basiert auf
der Vero¨ffentlichung [Nie00] von O. Nierstrasz, in der Pattern fu¨r die erfolg-
reiche Entscheidungsfindung u¨ber die Annahme bzw. Ablehnung von Konfe-
renzbeitra¨gen definiert wurden. Auf die Vero¨ffentlichung wird in Kapitel 2.3
na¨her eingegangen. CyberChair ist eine freie Software, die von 1996 bis 2000
entwickelt und gepflegt wurde, bis die neue kommerzielle Version CyberChair-
PRO [vdS09b] fertiggestellt war. Das System ist in der Skriptsprache Python
implementiert.
EasyChair
Professor Andrei Voronkov begann im Jahre 2002 mit der Entwicklung von
EasyChair [Vor09], einem Konferenzsystem, das mittlerweile eines der meist
verwendeten Systeme im wissenschaftlichen Bereich ist. Fu¨r die Umsetzung
von EasyChair wurde der Entwicklungsansatz LAMP verwendet. Die Benut-
zung des Begutachtungsystems fu¨r Konferenzen ist kostenlos und wird auf
EasyChair eigenen Rechnern an der Universita¨t Manchester am Fachbereich
Computer Science betrieben. Es handelt sich um ein Skript basiertes System,
das die beno¨tigten Funktionalita¨ten fu¨r den Benutzer in einfachster Form be-
reitstellt.
EDAS
EDAS [Sch09] steht fu¨r Editor’s Assistent und wurde von Professor Henning
Schulzrinne Ende der neunziger Jahre entwickelt. EDAS ist ein kommerzielles
System, das auf dem LAMP Modell aufbaut und somit wie EasyChair Skript-
basiert ist. Die Konferenzen werden von zwei kommerziellen Rechenzentren
gehosted, eines ist in Dallas, Texas und das andere in San Diego, Kalifornien
ansa¨ssig. Das System wurde neben Konferenzen und Workshops, ebenfalls fu¨r
Journals verwendet. EDAS kann auf einen Datenbestand von 100.000 Begut-
achtern und Autoren zuru¨ckgreifen.
Editorial Manager
Editorial Manager [Ari09] ist ein Manuskriptverwaltungssystem fu¨r wissen-
schaftliche Zeitschriften von der Firma Aries (Deutschland), die eine Toch-
KAPITEL 2. VERWANDTE ARBEITEN 24
tergesellschaft der Aries GmbH aus den USA ist. Editorial Manager wird in
mehreren Verlagen verwendet, wie im Springer Verlag Heidelberg. Neben dem
OCS, der fu¨r die Konferenzreihen zusta¨ndig ist, wird bei Springer der Editorial
Manager fu¨r die Zeitschriftenverwaltung eingesetzt.
OpenConf
OpenConf [Gro09] ist ein Peer-Review Management System, das seit 2002 exi-
stiert und von der Zakon Group in den USA vertrieben wird. Es wird eine in
den Funktionalita¨ten eingeschra¨nkte Version kostenlos angeboten. Die kom-
merzielle Version ist um einige Features reicher und wird u¨ber Lizenzen erwor-
ben. Zusa¨tzlich zu den Lizenzen kann optional das Hosting der Konferenzen
eingekauft werden. Fu¨r die Entwicklung der Software kamen die Skriptsprache
PHP und die MySQL Datenbank zum Einsatz. OpenConf wurde bereits fu¨r
zahlreiche internationale Tagungen eingesetzt.
Open Conference/Journal System
Es sei auch das Open Conference Systems [Pro09] erwa¨hnt, eine freie Skript
basierte Konferenzmanagement-Software, die von Public Knowledge Project
[Sys09] herausgegeben wird. Dieses System dient zur Erstellung des Web-
Auftritts einer Konferenz und die Web-Vero¨ffentlichung von wissenschaftlichen
Artikeln. Es beinhaltet einen Einreichungsmechanismus und eine Diskussions-
komponente fu¨r die Nachbesprechung im Anschluss einer Konferenz, allerdings
wird der Begutachtungsprozess fu¨r Konferenzen nicht unterstu¨tzt.
START V2
Rich Gerber und Paolo Gai entwickelten die erste Version START V1 [GG09]
zwischen 1998 und 2000. Diese Version wird bis heute kostenlos angeboten
und kann auf eigenen Servern installiert werden. Die neue Version START
V2 [GG09] entstand ab dem Jahre 2001 und wird seit dem mittels des Un-
ternehmens Softconf.com, dessen Inhaber Rich Gerber und Paolo Gai sind,
weiterentwickelt und kommerziell angeboten. Wie bei OpenConf wird auch
hier die Nutzung u¨ber Lizenzen geregelt und die Software kann entweder auf
eigenen Servern installiert oder ein Hosting der Konferenz zusa¨tzlich gebucht
werden. START V2 bietet eine Vielzahl von Features an und ist wie der OCS
fein-granular konfigurierbar. Beide START Versionen basieren auf der Skript-
sprache Perl.
KAPITEL 2. VERWANDTE ARBEITEN 25
2.1.2 Analyse und Diskussion
Dieses Kapitel geht auf Technische Aspekte und die Features der vorgestellten
Dienste ein und stellt einen Vergleich dar.
Der OCS war durch seinen Entwicklungsansatz und den Zugriffskontrollme-
chanismus bereits im Jahre 2000 das flexibelste Begutachtungssystem in Be-
zug auf die Konfiguration des Dienstaussehens, des Workflows, der Rollende-
finition und der Anpassbarkeit auf verschiedene Wissenschaftsgemeinden. Der
OCS gab den Dienstbenutzern eine große Anzahl von Features an die Hand
[MK02], die das kooperative Arbeiten immens erleichterten. Die konzipierte
und umgesetzte Forum-Komponente auf Basis eines integrierten News-Servers
unterstrich zusa¨tzlich die Vorreiterstellung. OCS und OJS setzten Akzente
in der Strukturierung und Komfortabilita¨t des Begutachtungsprozesses. Hat
OCS maßgeblich den Begutachtungsworkflow fu¨r Konferenzen mitbestimmt
und andere Dienste in ihrer Feature-Entwicklung beeinflusst, so war der OJS
federfu¨hrend im Bereich der Journals.
Meine Recherche hat ergeben, dass fu¨r die meisten Dienste keine Vero¨ffent-
lichungen existieren, auf die referenziert werden ko¨nnte. Neben dem OCS
verfu¨gen nur CyberChair und Continue u¨ber Vero¨ffentlichungen. Das Wissen
u¨ber die einzelnen Dienste wurde auf Basis von Informationen von Interne-
tauftritten, Evaluierung von Demodiensten, eigener Erfahrung durch die Be-
nutzung der Dienste wa¨hrend wissenschaftlicher Konferenzen und durch Dis-
kussionen mit anderen Anwendern erlangt.
Mittlerweile haben sich die Konkurrenzdienste im Bereich der Begutachtungs-
systeme vom Funktionalita¨tsumfang her angena¨hert. Unterschiede lassen sich
heutzutage bzgl. der Umsetzung der Systeme, der Flexibilita¨t und der Aus-
pra¨gung der einzelnen Features bestimmen. Die im vorangegangenen Kapitel
kurz vorgestellten Dienste werden mit dem OCS auf Basis des aktuellen Stan-
des hinsichtlich der nachstehenden Kriterien analysiert und diskutiert:
• Dienstfunktionalita¨ten und deren Flexibilita¨t.
• Agilita¨t und Erweiterbarkeit der Systeme.
• Validierung der betrachteten Dienste.
Die Kriterien werden einerseits untermauert durch die verwendeten Architek-
turen, Technologien und Vorgehensweisen, andererseits durch die in Tabelle 2.1
aufgelisteten und fu¨r den Vergleich der Dienste betrachteten Features. Die Ta-
belle 2.2 dargestellte Legende gibt einen U¨berblick der verwendeten Synonyme.
K
A
PITEL
2.
V
ERW
A
N
D
TE
A
R
BEITEN
26
Features CM Co CRS CC EC EDAS EM OC OCS SV
Flexible Rollenkonfiguration + ? - - - - + - + -
Bidding + + + + + + - + + +
Diskussionskomponente + + + + + + - + + +
Berechnung der Review-Verteilung - ? - + - - - - + -
Tagungsbanderstellung - ? - + + - - + + -
Double blind mode + - + + + + - + + +
Anonymisierte PC member - - + - - - - - + -
Konfigurierbare Reportformulare - ? + - + - + - + +
Integrierter Demodienst - - - - + - - - + -
Feature-orientierter Support - - - - - - - - + -
Sub-Delegierungen + - + + + + + - + -
Konfigurierbare E-Mail-Vorlagen + - - - + + + - + -
Zentraler Dienstzugang - ? + ? + + + - (+) -
Tabelle 2.1: Feature-Vergleich der Begutachtungssysteme (Stand Juli 2009)
KAPITEL 2. VERWANDTE ARBEITEN 27
Synonym Bedeutung
CM ConfMaster
Co Continue
CRS Conference Reviewing System
CC CyberChair/CyberChairPRO
EC EasyChair
EDAS Editor’s Assistent
EM Editorial Manager
OC OpenConf
OCS Online Conference Service
SV START V2
? nicht bekannt
- nicht vorhanden
+ vorhanden
(+) noch nicht produktiv geschaltet
Tabelle 2.2: Legende zu Tabelle 2.1
Dienstfunktionalita¨ten und deren Flexibilita¨t
Unterschiede zwischen den Systemen sind in der Anzahl und der Flexibilita¨t
bzw. Auspra¨gungen der Dienstfunktionalita¨ten der Systeme festzustellen. Tab-
belle 2.1 zeigt eine Auswahl an Features auf, die u¨berwiegend die Flexibilita¨t ei-
nes Systems repra¨sentieren und als Basis fu¨r den Vergleich der Systeme dienen.
OCS ist nach 10 ja¨hriger Existenz eines der flexibelsten Systeme im Bereich
der Begutachtungssysteme. Im Folgenden werden die erlangten Kenntnisse aus
Tabelle 2.1 genauer diskutiert.
OCS ermo¨glicht dem Konferenzleiter den Dienst online zu konfigurieren, ange-
fangen bei dem Look&Feel der Dienstseiten bis hin zur Erstellung neuer Be-
gutachtungsformulare oder zusa¨tzlicher Rollen, die nicht im Pool der vor-
definierten Rollen existieren, aber fu¨r den Workflow der Wissenschaftsgemein-
de essentiell sind. OCS verfu¨gt u¨ber ein flexibles Rollen- und Rechte-System
mittels dessen auch zur Laufzeit der Konferenz Rollen neu erzeugt, mo-
difiziert, zugewiesen und Benutzern entzogen werden ko¨nnen. Wird
die erstellte Vergleichstabelle der Begutachtungssysteme betrachtet, dann ist
unter dem Feature Flexible Rollenkonfiguration zu erkennen, dass neben OCS
nur ConfMaster und Editorial Manager einen Rollenansatz realisiert haben,
diese erreichen aber nicht die Flexibilita¨t des im OCS verwendeten Konzeptes.
Die Recherche hat ergeben, dass nur der OCS die Mo¨glichkeit zur zusa¨tzlichen
Rollendefinition zur Laufzeit realisiert hat und neue Rollen in dem Begutach-
KAPITEL 2. VERWANDTE ARBEITEN 28
tungsprozess einbinden kann. Zugriffe auf Objekte im Dienst, wie z.B. Artikel
oder Reports, sind im Vergleich zu den anderen Diensten feingranularer ein-
stellbar (siehe Kapitel 4.2).
Features wie das Bidding 3 und die Diskussionskomponente (siehe Ta-
belle 2.1) sind nur sehr rudimenta¨r in den anderen Systemen vorhanden. Der
Editorial Manager verzichtet ga¨nzlich als einziger auf diese Art von Featu-
res. Dieses ha¨ngt damit zusammen, dass der Dienst fu¨r Journals ausgelegt ist.
Im Online Journal Service (OJS), einem der OCS-Dienstfamilie angeho¨rigen
Journaldienst (siehe Kapitel 7.2), ist dieses ebenfalls nicht im Basis-Workflow
enthalten, kann allerdings zugeschaltet werden. Die Mo¨glichkeit der flexiblen
Aktivierung von Features hat sich im Rahmen von Konferenzen und Journals
in der Vergangenheit bewa¨hrt. Die hohe Anzahl von bereits realisierten Featu-
res und deren Verwendbarkeit zur Erweiterung eines bestehenden Workflows
stellt einen wesentlichen Anteil der Flexibilita¨t fu¨r die eigenen Entscheidungs-
systeme dar. Das Bidding (siehe Kapitel 4.3) wie die Diskussionskomponente
sind als sehr flexible Komponenten fu¨r die gesamte Dienstfamilie des OCS um-
gesetzt worden. Das Bidding-Feature des OCS verfu¨gt u¨ber eine Verteilungs-
komponente, die sich von den anderen realisierten Verteilungsmechanismen
abgrenzt. Das Feature beru¨cksichtigt viele Randbedingungen fu¨r die Berech-
nung einer optimalen Verteilung der Begutachtungsauftra¨ge, wie die
vom Gutachter oder Konferenzleiter spezifizierten Konflikte, die Pra¨ferenzen,
die der Gutachter fu¨r jeden einzelnen Artikel gesetzt hat, die Zugriffsrechte
auf den entsprechenden Artikel und die bereits vorhandenen Zuteilungen von
Artikeln zur Begutachtung. Eine homogene Verteilung kann mittels eines vom
OCS verwendeten Algorithmus fu¨r die Lo¨sung lineare Gleichungen berechnet
werden. Eine Funktionalita¨t fu¨r die Berechnung von homogenen Verteilungen
der Begutachtungsauftra¨ge wird ebenfalls von CyberChair angeboten (siehe
Tabelle 2.1 Feature Berechnung der Review-Verteilung).
Die automatische Erstellung von Konferenzba¨nden (proceedings) (siehe
Tabelle 2.1 Feature Tagungsbanderstellung) wird von CyberChair, EasyChair,
und OpenConf unterstu¨tzt. Dies bedeutet, dass die Ergebnisse der Konferenz
online zu einem Paket zusammengefu¨gt werden. Der OCS geht mit Hilfe sei-
nes PPS (Proceeding Production Service) noch einen Schritt weiter. Der PPS
erlaubt es online den kompletten Tagungsband zu erstellen, hierzu geho¨rt die
Gliederung des Bandes, das Vorwort, diverse Listen der Beteiligten und In-
dexe. Der PPS generiert die fu¨r den Verlag und Druck beno¨tigten Archive
entweder aus den LaTeX Sourcen oder aus dem PDF eines jeden Beitrags. Die
3Begutachter ko¨nnen ihre Favoriten, die sie gerne begutachten wollen, wa¨hlen bzw. Ar-
tikel kennzeichnen, die sie nicht bearbeiten wollen, da sie den Autoren beispielsweise gut
kennen oder in dem entsprechenden Fachgebiet keine grundlegenden Erfahrungen haben.
KAPITEL 2. VERWANDTE ARBEITEN 29
Sourcen werden bereits wa¨hrend der Einreichungsphase durch Kompilierung
auf ihre Richtigkeit und Vollsta¨ndigkeit u¨berpru¨ft. Zur besseren Kontrolle des
Tagungsbandes wird neben dem Archiv eine PDF-Version des Konferenzban-
des erstellt, mittels dessen Fehler direkt ersichtlich sind und dementsprechende
Korrekturen vorgenommen werden ko¨nnen.
Das blind review 4 und double-blind review 5 wird in den meisten Diensten
unterstu¨tzt (siehe Tabelle 2.1 Feature Double blind mode). Der zusa¨tzlich
anonyme Begutachtungsprozess (siehe Tabelle 2.1 Feature Anonymisierte
PC Member) in Bezug auf die Identita¨t der Gutachter ist allerdings nur bei
CRS und OCS beru¨cksichtigt. Die Namen und Email-Adressen der Begutach-
ter werden im OCS anonym behandelt und ko¨nnen im gesamten Begutach-
tungsprozess nur von der Konferenzleitung erkannt werden. Sind Artikel von
Gutachtern eingereicht worden, ist die Anonymita¨t unter den Gutachtern sehr
wichtig um die Gleichbehandlung aller Artikel zu gewa¨hrleisten.
Konfigurierbare Begutachtungsformulare (siehe Kapitel 4.4) werden in
den Diensten CRS, EasyChair, Editorial Manager, START nur rudimenta¨r an-
geboten (siehe Tabelle 2.1). OCS hebt sich dadurch hervor, dass die ga¨ngigen
Interaktionselemente, wie z.B. Textfelder, Checkboxen, Fileuploads definiert
sind und beliebig zu einem Begutachtungsformular online kombiniert werden
ko¨nnen. Somit ist ein eigenes fu¨r die jeweilige Konferenz zugeschnittenes For-
mular online konfigurierbar. Des Weiteren wird die Erstellung einer Formel
unter der Verwendung der definierten Elemente und deren hinterlegten Wer-
te angeboten. Mehrere unterschiedliche Formulare fu¨r die Gutachten und die
Gesamtgutachten der Konferenzleiter sind in einer Konferenz definierbar.
Im Gegensatz zu allen betrachteten Systemen verfu¨gt jede Konferenzinstanz
des OCS u¨ber einen eigenen Demodienst, der das Abbild des Konferenz-
dienstes darstellt. Sobald der Konferenzleiter den Dienst konfiguriert hat, kann
mittels des Demodienstes einerseits die durchgefu¨hrte Konfiguration getestet
und andererseits die Funktionsweise des originalen Dienstes kennengelernt wer-
den. Das gesamte Komitee erha¨lt Zugriff und kann ein Beispielszenario eines
Begutachtungsprozesses durchlaufen. Selbst zur Laufzeit der Konferenz ko¨nnen
die Konferenzdaten in den Demodienst eingespielt und eventuelle Tests durch-
gefu¨hrt werden. EasyChair verfu¨gt seit einiger Zeit nun auch u¨ber ein solches
Feature (siehe Tabelle 2.1 Feature Integrierter Demodienst).
Ein weiterer wesentlicher Aspekt fu¨r die gute Unterstu¨tzung der Wissenschafts-
gemeinde ist die Hilfestellung (support) bei auftretenden Fragen. Der OCS ist
4Die Autoren erfahren nicht, wer die Gutachten u¨ber ihren Artikel geschrieben hat.
5Erweitert blind review in der Hinsicht, dass die Gutachter die Namen der Autoren nicht
kennen.
KAPITEL 2. VERWANDTE ARBEITEN 30
das einzige Begutachtungssystem, das dem Benutzer mittels einer Hilfekom-
ponente online zielgerichtet auf jeder Dienstseite unterstu¨tzt. Diese Kom-
ponente lehnt sich an den Zugriffskontrollmechanismus an und bereitet die
Hilfestellung personalisiert anhand der jeweiligen aktiven Rolle auf. Weiter-
hin wird eine FAQ angeboten. Daru¨ber hinaus ist der direkte Support durch
Personen, die fundiertes Wissen u¨ber die Abla¨ufe des OCS aufweisen, gewa¨hr-
leistet. Der Vergleich zu diesem Feature ist ebenfalls in der Tabelle 2.1 Feature
Feature-orientierter Support dargestellt.
Damit der Begutachtungsprozess in sich transparent wird, ist es notwendig alle
Gescha¨ftsprozesse in einem Dienst aufzunehmen, was gewa¨hrleistet, dass nichts
am Dienst und dem Komitee vorbei erarbeitet wird. Sub-Delegierungen
stellt ein solches Feature dar, das mittlerweile auch von vielen der anderen
Dienste eingesetzt wird (siehe Tabelle 2.1).
Das E-Mail-Feature ist ebenfalls ein wichtiger Punkt im Vergleich der Syste-
me. Konfigurierbare E-Mail-Vorlagen machen den Dienst flexibler in der
Anpassung auf neue bzw. verschiedene Konferenzen. Es weisen neben OCS die
Anwendungen ConfMaster, EasyChair, EDAS und Editorial Manager dieses
Feature auf (siehe Tabelle 2.1).
Der zentrale Dienstzugang (Single Point of Entry oder Single Sign on) bie-
tet den Benutzern, die in mehreren Konferenzen involviert sind eine Erleich-
terung in Hinblick auf die Authentifizierung, um an alle relevanten Dienste zu
gelangen. CRS, EasyChair, EDAS, Editorial Manager und OCS besitzen die-
ses Feature, wobei es fu¨r den OCS noch nicht im Produktiveinsatz war(siehe
Tabelle 2.1).
Agilita¨t und Weiterentwicklung
Der OCS, ist wie die vorgestellten Systeme, plattformunabha¨ngig. Wa¨hrend
OCS in der objektorientierten Programmiersprache Java implementiert ist,
sind die u¨brigen Systeme u¨berwiegend Skript-basiert entwickelt worden. Zum
gro¨ßten Teil basieren die Dienste auf dem LAMP Modell (siehe Kapitel 2.1.1)
und sind in den Skriptsprachen Perl, PHP oder Python realisiert. Durch den
Feature-orientierten Ansatz und die graphbasierte Modellierung des Kontroll-
flusses, der auf seine Korrektheit mittels formaler Methoden verifizierbar ist,
hebt sich der OCS gegenu¨ber den anderen Systemen in dem betrachteten Kri-
terium hervor. Softwaresysteme werden sta¨ndig Vera¨nderungen unterzogen,
die durch neue Anforderungen, gea¨nderte Anwendungskontexte oder neuen
Technologien beeinflusst werden. Gescha¨ftsprozesse und Anforderung von Kun-
den sind in diesem Rahmen die ausschlaggebenden Punkte. Ein System muss
KAPITEL 2. VERWANDTE ARBEITEN 31
schnell auf gea¨nderte Gescha¨ftsabla¨ufe reagieren ko¨nnen. Diese Agilita¨t ist auf
einfachste Weise durch den Einsatz der graphbasierten Modellierung gewa¨hr-
leistet. Der Kontrollfluss ist visuell nachvollziehbar und kann graphisch modifi-
ziert werden. Dadurch wurde konsequent eine MDA und SOA Vorgehensweise
praktiziert. Es lassen sich Dienstfunktionalita¨ten realisieren, die Doma¨nen-
u¨bergreifend einsetzbar und aus der Sicht der Wirtschaftlichkeit wiederver-
wendbar sind.
Validierung
A¨nderungen und Erweiterungen an Softwaresystemen geho¨ren zum Alltags-
gescha¨ft und verursachen hohe Kosten durch Qualita¨tssicherung. Die Validie-
rung von Arbeitsabla¨ufen auf Graphebene ist ein ada¨quates Mittel, um diese
Kosten zu senken und eine Gewa¨hrleistung der Dienstfunktionalita¨ten nach
durchgefu¨hrten Modifikationen zu haben, was nicht ga¨nzlich alle Tests u¨ber-
flu¨ssig macht.
Neben dem Model Checking Ansatz beim OCS wird nur noch bei Continue
ein Validierungsverfahren eingesetzt, das sich allerdings vom Grundgedanken
des OCS-Verfahrens stark unterscheidet. OCS wird modelgetrieben entwickelt.
Wa¨hrend der Entwicklungsphase werden die Gescha¨ftsprozesse als Graphen
modelliert und auf dieser Basis die Temporal Logischen Formel fu¨r das Model
Checking parallel spezifiziert. So kann der entstehende Dienst bereits zur De-
signzeit validiert werden, ohne eine Implementierung vorgenommen zu haben.
Die Vorgehensweise stellt einen direkten Bezug zu den Komponenten der Ap-
plikation her. Der Ansatz fu¨r Continue setzt bei dem fertigen Dienst an [LK04].
Es werden Graphmodelle auf Basis der Dienstsourcen erstellt. Das so entste-
hende abstrakte Modell wird dann mittels Model Checkings validiert. Hier-
bei stellt sich die Frage, ob das automatisch generierte Modell ada¨quat zum
zugrunde liegenden Dienst ist und eine sichere Aussage u¨ber die Richtigkeit
getroffen werden kann.
Dahingegen existieren keine Modellierungstools fu¨r die Skript basierten Syste-
me, mittels derer ohne detailliertere Programmierkenntnisse A¨nderungen bzw.
Erweiterungen sicher und validierbar durchzufu¨hren sind.
Fazit
Wa¨hrend der Gegenu¨berstellung des OCS mit den betrachteten Systemen hat
sich herausgestellt, dass der OCS nach wie vor das flexibelste System ist (siehe
Tabelle 2.1). Die langja¨hrige Erfahrung und die Umsetzung der Bedu¨rfnis-
KAPITEL 2. VERWANDTE ARBEITEN 32
se von wissenschaftlichen Gemeinschaften, die den Dienst verwenden, haben
einen großen Teil dazu beigetragen. Sind Funktionalita¨ten, die im OCS existie-
ren, auch in anderen Diensten vorhanden, wie z.b. der Biddingmechanismus
oder die konfigurierbaren Begutachtungsformulare, so konnte festgestellt wer-
den, dass diese fu¨r den OCS konsequenter in ihrer Funktionalita¨t und dadurch
flexibler konzipiert und realisiert wurden.
EasyChair ist zum heutigen Stand eines der meist verwendeten Begutach-
tungssysteme im wissenschaftlichen Bereich. Dieses ist mitunter darauf zuru¨ck-
zufu¨hren, dass EasyChair von Beginn an kostenlos angeboten wurde und einen
fu¨r den Benutzer einfachen Workflow anbietet. Wollten die Benutzer zur Ent-
stehungszeit der Web-Applikationen alles selbst konfigurieren, steht heutzutage
die Einfachheit und der geringe Konfigurationsaufwand im Vordergrund.
OCS hat sich aufgrund der verwendeten Konzepte und Funktionalita¨ten bei
Springer als das Begutachtungssystem durchgesetzt. Fu¨r Konferenzen mit ei-
nem Publikationsvorhaben in der fu¨hrenden Publikationsreihe der Informatik
LNCS wird die Benutzung kostenlos angeboten [Hei09b]. Der OCS und die
Dienstfamilie werden weiterhin erfolgreich eingesetzt. Durch die konsequente
Einhaltung des Feature-orientierten Ansatzes und regelma¨ßiger Beru¨cksichti-
gung von Benutzerru¨ckmeldungen (feedback) wuchs der OCS zu einem vielsei-
tigen Begutachtungssysten heran.
2.2 Sicherheit von Web-Applikationen
Der Schutz von sensiblen und vertrauenswu¨rdigen Daten und Ressourcen
nimmt eine zentrale Stellung im Bereich der kooperativen Softwaresysteme ein.
Entscheidungen werden u¨ber bzw. mit zu schu¨tzenden Dokumenten getroffen,
die u¨ber web-basierte Softwaresysteme zur gemeinsamen Arbeit verfu¨gbar sind.
Web-basierte Systeme bearbeiten hunderte von parallelen Anfragen von ver-
schiedenen Nutzern oder sammeln Daten von verteilten Diensten, wodurch die
Anforderungen an die Zugriffskontrollen immer komplexer werden. Eine hohe
Leistungsfa¨higkeit und Ausfallsicherheit von Kontrollmechanismen wird durch
das Definieren von Policies unterschiedlichster Ausdruckssta¨rke erzielt. Policies
sind Regeln, die Anforderungen und das Verhalten an ein System beschrei-
ben. Eine Policy wa¨re zum Beispiel: “Nur authentifizierte Benutzer du¨rfen
den internen Bereich der Applikation einsehen.” Durch die stetig wachsen-
de Komplexita¨t von Systemen und die daraus resultierende Komplexita¨t der
Zugriffsrechte ist es fu¨r Administratoren und Dienstentwickler umso wichti-
ger, auf ein leistungsfa¨higes und u¨berschaubares Framework zuru¨ckgreifen zu
KAPITEL 2. VERWANDTE ARBEITEN 33
ko¨nnen, das die Erstellung von Policies unterstu¨tzt. Eine wichtige Anforde-
rung fu¨r ein solches Framework ist die Anpassbarkeit und Kombinierbarkeit
von Policies, um gegenwa¨rtigen Web-Diensten, deren Gescha¨ftsprozessen und
Architekturen, die stetig im Wandel stehen, gerecht zu werden.
Die Fa¨higkeit, Policies zu schreiben und zu verwalten, reicht allerdings nicht
aus, um eine fundierte und zuverla¨ssige Zugriffskontrolle zu gewa¨hrleisten. Viel
wichtiger ist es sicherzustellen, dass die Policies mit der wirklichen Imple-
mentierung des zu sichernden Dienstes u¨bereinstimmen. Mit anderen Worten,
erfu¨llen sie die Sicherheitsaufgaben im realen System? Dieses gilt im Hinblick
auf
• neue Policies,
• existierende Policies, wenn der zu sichernde Dienst gea¨ndert wurde,
• modifizierte Policies auf unvera¨nderten Gescha¨ftsprozessen,
• A¨nderungen der Policies bei gleichzeitiger Modifikation des zu sichernden
Dienstes.
Letzteres stellt die gro¨ßte Herausforderung an die Gewa¨hrleistung der Funktio-
nalita¨t des Zugriffskontrollmechanismus fu¨r komplexe Anwendungen dar. Eine
Methodik, basierend auf formalen Methoden, die den Zusammenhang und die
U¨bereinstimmung zwischen dem Modell des Dienstes und der Implementierung
des Dienstes herstellt, ist somit unerla¨sslich.
Im Folgenden werden die bekannten Policy Beschreibungssprachen XACML
und die Web Services Policy (WS-Policy) kurz vorgestellt und mit dem auf
Basis des jABC konzipierten Ansatzes fu¨r das im OCS verwendete Zugriffs-
kontrollkonzept verglichen.
2.2.1 WS-Policy
DasWeb Services Policy Framework ist eine Spezifikation desW3C 6 [BNB+06,
WCL+05]. Es beschreibt ein Rahmenwerk zur Erstellung von Policies und Po-
licy Assertions, das die Eigenschaften, Fa¨higkeiten und Anforderungen von
Web Services beschreibt. WS Policy ist eine Syntax mittels derer Policy Asser-
tions als disjunktive und konjunktive Verknu¨pfungen zu einer Policy zusam-
mengesetzt werden. Dabei kann es sich um Eigenschaften der Kommunikati-
onsfa¨higkeiten eines Web Services handeln, oder die Anforderungen an einen
6World Wide Web Consortium
KAPITEL 2. VERWANDTE ARBEITEN 34
anderen Web Service, die dieser fu¨r eine Zusammenarbeit zu erfu¨llen hat. An-
wendungsbereiche von Web Services werden Domains genannt. Das Ziel von
WS Policy ist die Beschreibung von allgemeinen und unabha¨ngigen Policies, die
mittels des WS Policy Framework an domainspezifische Anwendungsbereiche
gekoppelt werden. Hierzu werden verschiedene Erweiterungen des Frameworks
verwendet, z.B. WS-SecurityPolicy [GDLHBH05] fu¨r die Richtlinien zur siche-
ren Kommunikation, WS-PolicyAssertions [MHBK03] fu¨r die Anforderungen
an die Textverschlu¨sselung, etc. oder WS-MetadataExchange [CBBa06] um
Metadaten eines Web Service zu spezifizieren. Ein Beispiel ko¨nnen zwei Web
Services sein, die bestimmen mu¨ssen, welcher Verschlu¨sselungsmechanismus
fu¨r ihre Kommunikation verwendet werden soll. Einer von ihnen ko¨nnte ei-
ne Verschlu¨sselung mit geringer Sicherheitsstufe fordern und unverschlu¨sselte
Anfragen ablehnen, wobei der andere Service nur eine begrenzte Auswahl an
Verschlu¨sselungsalgorithmen bietet.
Mit Hilfe von WS Policy ko¨nnen solche Anforderungen und Fa¨higkeiten be-
schrieben und verwendet werden, um passende Kommunikationsparameter ab-
zuleiten. Mittels Policy Assertions werden solche Eigenschaften definiert. Meh-
rere Policy Assertions werden zu Policy Alternativen zusammengefasst, indem
die Assertions mit <wsp:All> oder <wsp:ExactlyOne> Elementen umschlos-
sen werden. <wsp:All> definiert, dass alle Assertions erfu¨llt sein mu¨ssen, wobei
<wsp:ExactlyOne> genau eine gu¨ltige Assertion verlangt. Die Policy Alternati-
ven schließen sich gegenseitig aus und werden ausgedru¨ckt in einer disjunktiven
Normalform (Normal Form Policy Expression). Des weiteren werden Policy
Expressions mittels Policy Attachments mit Policy Scopes assoziiert, die eine
Sammlung von Policy Subjects darstellen. Subjects sind Einheiten, Ressourcen,
die durch die Policy beeinflusst werden.
Abbildung 2.1 (aus [BNB+06]) zeigt eine Policy in geku¨rzter Form, die WS-
Security Policy verwendet.
2.2.2 XACML
Die eXtensible Access Control Markup Language (XACML) [Mos05] ist 2003
erschienen. Der OASIS [OAS09] Standard wurde erstellt fu¨r die Spezifikati-
on von Policies und Eigenschaften auf Basis von XML. Dieser Standard wird
eingesetzt, um Bedingungen (constraints) fu¨r den Zugriff auf Ressourcen zu
definieren. Die Bedingungen selbst werden in Form von Attributen und Da-
tentypen beschrieben und mittels generischer Funktionen u¨berpru¨ft. Neben der
Policy gibt es Policy Sets, die durch kombinatorische Angaben (wie all, at least
one, . . . ) zu sogenannten Policy Sets kombiniert werden ko¨nnen.
KAPITEL 2. VERWANDTE ARBEITEN 35
01 <wsp:Policy xmlns:sp= "http://schemas.xmlsoap.org/ws/2005/07/
securitypolicy"
02 xmlns:wsp= "http://schemas.xmlsoap.org/ws/2004/09/policy" >
03 <sp:TransportBinding>
04 <wsp:Policy>
05 <sp:AlgorithmSuite>
06 <wsp:Policy>
07 <wsp:ExactlyOne>
08 <sp:Basic256Rsa15 />
09 <sp:TripleDesRsa15 />
10 </wsp:ExactlyOne>
11 </wsp:Policy>
12 </sp:AlgorithmSuite>
13 <sp:TransportToken>
14 <wsp:Policy>
15 <sp:HttpsToken RequireClientCertificate= "true " />
16 </wsp:Policy>
17 </sp:TransportToken>
18 <!-- Details omitted for readability -->
19 </wsp:Policy>
20 </sp:TransportBinding>
21 </wsp:Policy>
Abbildung 2.1: Beispiel WS-Policy policy
Abbildung 2.2 (aus [Gri04]) zeigt die Komponenten von XACML und deren
Zusammenhang. Eine eingehende Anfrage (request) wird von dem Policy En-
forcement Point (PEP) in eine XACML Anfrage transformiert, die Informatio-
nen u¨ber den Anfragenden, seine Berechtigungen und die angefragte Ressource
zusammenfasst (vgl. Schritt “(1)” in Abb. 2.2). PEP kommuniziert mit dem
Policy Information Point (PIP), der Nutzerinformationen und Kontextinfor-
mationen verwaltet (vgl. Schritt “(2)” in Abb. 2.2).
Die vom PIP kommenden Informationen werden in die XACML Anfrage ein-
gearbeitet und diese anschließend an den Policy Decision Point (PDP) weiter-
geleitet (vgl. Schritt “(3)” in Abb. 2.2). Dieser entscheidet unter Beru¨cksichti-
gung von Policies von dem Policy Store (vgl. Schritt “(4)” in Abb. 2.2) u¨ber
Annahme oder Ablehnung der Anfrage. Wenn zutreffende Policies vorhanden
sind, werden diese u¨berpru¨ft und PEP leitet die Authentifizierungsentschei-
dung weiter (vgl. Schritt “(5)” und “(6)” in Abb. 2.2).
Das Root-Element eines XACML Dokumentes ist eines der folgenden Elemen-
te: <Rule>, <Policy> und <PolicySet>. Eine Policy besteht aus einer oder
mehreren Regeln (rules) und einem Kombinationsalgorithmus fu¨r die Ergeb-
nisse der Regeln. Policies wiederum ko¨nnen Bestandteil von Policy Sets sein,
die aus mehreren <Policy> und <PolicySet> Elementen zusammengesetzt
sein ko¨nnen. Fu¨r die Bestimmung eines eindeutigen Ergebnisses ko¨nnen auch
<PolicySet> Kombinationsstrategien definiert werden. Kombinationsalgorith-
men fu¨r Regeln und Policies sind:
KAPITEL 2. VERWANDTE ARBEITEN 36
Abbildung 2.2: Verarbeitung einer Anfrage in XACML
• Deny-overrides Sobald eine Regel oder Policy Deny festsetzt, ist das
Gesamtergebnis Deny.
• Permit-overrides Sobald eine Regel oder Policy Permit festsetzt, ist
das Gesamtergebnis Permit.
• First applicable Die erste einsetzbare Regel oder Policy die gefunden
wird bestimmt das Gesamtergebnis.
• Only-one-applicable Dieser Kombinationsalgorithmus kann das Er-
gebnis von genau einer Policy eines Policy Sets abha¨ngig machen. Ist
genau eine Policy anwendbar, ist der Algorithmus abgeschlossen. Wenn
mehrere Policies zutreffen, ist das Ergebnis Indeterminate. Sobald kei-
ne passende Policy gefunden wird, wird NotApplicable gemeldet. Dieser
Algorithmus kann nur fu¨r Policy Sets verwendet werden und ist nicht ge-
eignet fu¨r nur eine Regel.
Die Verwendbarkeit einer Regel oder Policy ist abha¨ngig von dem <Target>
Element. Dieses spezifiziert, fu¨r welche Subjekte, Ressourcen oder Kontexte
die Regel oder Policy definiert wurde. Das Target ist das erste Element, das
u¨berpru¨ft wird, wenn eine Policy bearbeitet wird. Wenn das Target mit einer
Anfrage u¨bereinstimmt, ist die Evaluierung der Policy abgeschlossen, andern-
falls wird das Target der na¨chsten Policy u¨berpru¨ft.
Abbildung 2.3 (aus [Mos05]) zeigt ein Beispiel fu¨r eine Policy. Es beinhaltet
eine Regel (Zeile 12–31), deren Bedeutung in <Description> beschrieben ist
KAPITEL 2. VERWANDTE ARBEITEN 37
01 <?xml version="1.0" encoding="UTF-8"?>
02 <Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"
03 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
04 xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:policy:schema:os
05 http://docs.oasis-open.org/xacml/access_control-xacml-2.0-policy-schema-os.xsd"
06 PolicyId="urn:oasis:names:tc:example:SimplePolicy1"
07 RuleCombiningAlgId="identifier:rule-combining-algorithm:deny-overrides">
08 <Description>
09 Medi Corp access control policy
10 </Description>
11 <Target/>
12 <Rule RuleId= "urn:oasis:names:tc:xacml:2.0:example:Simple Rule1" Effect="Permit">
13 <Description>
14 Any subject with an e-mail name in the med.example.com domain
15 can perform any action on any resource.
16 </Description>
17 <Target>
18 <Subjects>
19 <Subject>
20 <SubjectMatchMatchId="urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match">
21 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">
22 med.example.com
23 </AttributeValue>
24 <SubjectAttributeDesignator
25 AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
26 DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"/>
27 </SubjectMatch>
28 </Subject>
29 </Subjects>
30 </Target>
31 </Rule>
32 </Policy>
Abbildung 2.3: Beispiel einer XACML Policy
(Zeile 13–16). Das leere <Target> Element in Zeile 11 kennzeichnet, dass die
Policy sich auf jede Ressource bezieht.
2.2.3 Policies im OCS
Bevor die aufgezeigten Ansa¨tze in Kapitel 2.2.4 diskutiert werden, wird zu-
vor kurz auf die eigene Vorgehensweise eingegangen, die detaillierter in den
Kapiteln 3.1, 4.1 und 4.2 beschrieben ist.
Policies im OCS definieren das Zusammenarbeiten von Dienstkomponenten be-
ziehungsweise Diensten und ihren Abha¨ngigkeiten. Die Gescha¨ftsprozesse des
OCS werden als gerichtete Graphen modelliert. Abbildung 2.4 zeigt eine ver-
einfachte Darstellung des fu¨r das Anzeigen der Artikelliste verantwortlichen
Gescha¨ftsprozesses. Die Knoten (SIBs 7) des Kontrollflussgraphen (SLG 8)
7Service Independent Building Block
8Service Logic Graph
KAPITEL 2. VERWANDTE ARBEITEN 38
sind Funktionalita¨ten eines Dienstes, die selbst Dienste sein ko¨nnen (siehe Ka-
pitel 3.1.1). Die Funktionalita¨ten in Form von SIBs sind im Falle des OCS
in Java geschrieben und durch den komponentenbasierten Ansatz auch pro-
jektu¨bergreifend wiederverwendbar.
Eine einfache Policy fu¨r den rollenbasierten Zugriff auf die Artikelliste lautet:
Nur Nutzer die als Konferenzleiter in dem OCS angemeldet sind
du¨rfen alle Artikel lesen.
Abbildung 2.4: ReadArticleList SLG - in vereinfachter Form
In der Abbildung 2.4 ist der Kontrollfluss fu¨r die Anzeige von allen Arti-
keln durch die Kennzeichung Policy 1 hervorgehoben. Die Implementierung
des SIBs CheckReadAllArticles u¨berpru¨ft, ob der Benutzer das erforderliche
Recht hat, den SIB LoadAllArticles auszufu¨hren.
Mit dem jABC Plugin FormulaBuilder [JMS06] ko¨nnen Policies als logische
Bedingungen graphisch modelliert werden, die mittels des GEAR [BMRS08,
BMRS06] Model Checkers gegen den Kontrollflussgraphen einer Anwendung
gepru¨ft werden. Abbildung 2.5 zeigt Policy 1 als Formelgraphen.
Der temporale Operator DIAB (diamond backward) verha¨lt sich wie ein EX
Operator mit umgekehrtem Transitionspfeil. Wir nennen dieses Verhalten EXB,
KAPITEL 2. VERWANDTE ARBEITEN 39
Abbildung 2.5: FormulaBuilder - Graphische Modellierung der Policy 1
das besagt, dass mindestens ein Vorga¨nger SIB (Knoten) existiert, mit dem Na-
men, der ru¨ckwa¨rts u¨ber einen branch (Kante) mit der Benennung erreichbar
ist.
Der in Abbildung 2.5 gezeigte Formelgraph wird in CTL [CGP01] Syntax u¨ber-
setzt:
((’ShowArticles => EXB[ok] ’LoadAllArticles) ∧
(’LoadAllArticles => EXB[permitted] ’CheckReadAllArticles))
Diese Bedingung wird anschliessend intern fu¨r den GEAR Model Checker in
den modalen µ-Kalku¨hl [CGP01] u¨bersetzt.
Abbildung 2.6 zeigt, dass der Graph die Bedingung erfu¨llt. Alle SIBs, die Po-
licy 1 erfu¨llen, sind gru¨n und mit einem Kasten markiert worden.
KAPITEL 2. VERWANDTE ARBEITEN 40
Abbildung 2.6: ReadArticleList Feature ist Policy 1 konform
Abbildung 2.7 wiederum zeigt einen Graphen, bei dem die ok Kante zwischen
LoadAllArticles und ShowArtiles auf LoadDelegatedArticles umgebogen
wurde. Der Graph ist mit der Policy 1 nicht la¨nger konform und die SIBs,
die die Policy verletzen, werden gekennzeichnet.
2.2.4 Vergleich der Ansa¨tze
XACML und WS Policy sind beides Sprachen zur Beschreibung von Policies,
die es erlauben, aus einfachen, komplexe Policies zusammenzusetzen. Mittels
XACML werden Autorisierungsentscheidungen getroffen und die Zugriffe auf
Dienste und Ressourcen gesteuert. WS-Policy hingegen verwendet einen all-
gemeineren Ansatz und beno¨tigt separate doma¨nenspezifische Erweiterungs-
module zur Erstellung von Policies. XACML Policies arbeiten auf Attribute
von Anfragen und sind direkt von der Semantik der verwendeten Datentypen
abha¨ngig. Dem gegenu¨ber arbeitet WS-Policy mit spezialisierten Bedingungen
(Assertions), die in verschiedenen Spezifikationen definiert sind. Dieses hat
zur Folge, dass es fu¨r Anwendungen, welche WS-Policy einsetzen, schwierig
zu entscheiden ist, ob zwei Policies vergleichbar, gleichbedeutend oder wider-
spru¨chlich sind, oder ob eine Behauptung eine andere inkludiert.
XACML, wie auch WS-Policy beru¨cksichtigen nur lokale Policies, die Bedin-
KAPITEL 2. VERWANDTE ARBEITEN 41
Abbildung 2.7: Verstoß der Policy 1 im gea¨nderten ReadArticleList Feature
gungen fu¨r eine bestimmte Stelle in einem Prozess definieren. In Bezug auf
Prozesse, wie es fu¨r Web Anwendungen der Fall ist, ist der Aspekt der globa-
len Policies von großer Bedeutung. Sie ermo¨glichen Teile eines Gesamtprozesses
in Beziehung zu setzen, um deren Eigenschaften und Abha¨ngigkeiten zu defi-
nieren.
Ein anderer sehr wichtiger Punkt fu¨r den erfolgreichen Einsatz von Policies ist
der Zusammenhang zwischen den geschriebenen Policies und der eigentlichen
Implementierung der Anwendung, fu¨r die sie definiert wurden. WS-Policy sagt
nicht aus, wie Policies auf Dienste angewendet werden sollen. Der XACML An-
satz definiert hingegen den Policy Enforcement Point 2.2, der mittels Policies
Anfragen auf Dienste oder Ressourcen u¨berpru¨ft. Dieses wird im OCS mit ei-
nem eigenen Zugriffskontrollmechanismus umgesetzt, der in den Kapiteln 2.2.3
und 4.2 na¨her beschrieben ist.
Die Mo¨glichkeit, Policies zu definieren und diese auf einen Dienst anwenden zu
ko¨nnen, ist allerdings nur ein Schritt, die Sicherheit sensibler Daten zu gewa¨hr-
leisten. Der zentralere Aspekt fu¨r die Sicherstellung der Funktionalita¨t eines
ada¨quaten Zugriffskontrollmechanismus, wie er fu¨r den OCS konzipiert wurde,
ist die Validierung der Policies. Die Validierung geschieht im direkten Bezug
auf die Gescha¨ftsprozesse einer Anwendung, die graphisch die Komponenten
der Implementierungen darstellen. Somit ko¨nnen Policies auf der Implemen-
KAPITEL 2. VERWANDTE ARBEITEN 42
tierung einer Applikation verifiziert werden. Weder WS-Policy, noch der ori-
ginale Ansatz des XACML zeigen eine Mo¨glichkeit der Validierung der Policy
und die daraus folgende Garantie auf Gu¨ltigkeit der definierten Policies. Aus
jahrelanger Erfahrung im Bereich der Softwareentwicklung gesehen, ist es ein
schwieriges Unterfangen, Policies ohne geeignete automatisierte Validierungs-
mechanismen zu pru¨fen. Die Komplexita¨t der Policies steigt mit der Zunahme
an Dienstfunktionalita¨ten. Software-Applikationen sind von Natur aus einem
stetigen Wandel unterzogen, der notwendige Pru¨fungen der Konformita¨t der
Policies mit sich fu¨hrt. Es ist sehr schwierig, große Regelsa¨tze manuell zu ver-
walten und diese gu¨ltig zu halten. Insbesondere die Bearbeitung von großen
XML Dateien, wie die XML-basierten Ansa¨tze XACML und WS-Policy aufzei-
gen, bilden fu¨r Menschen eine große Herausforderung. Sicherlich ko¨nnen XML
Dateien auf ihre Wohlgeformtheit hin gegen ein XML-Schema oder eine XML-
DTD 9 gepru¨ft werden. Dieses hat aber keinen Aussagecharakter in Bezug auf
die Gu¨ltigkeit der Policies auf der zu sichernden Applikation.
XACML und WS-Policy haben umfassende Spezifikationen und Richtlinien fu¨r
das Definieren und Verwenden von Policies. Allerdings beno¨tigen Ansa¨tze wie
in [HB08] komplexe Transformationen und Verschlu¨sselungen fu¨r die Policies,
um diese mittels Model Checking validieren zu ko¨nnen.
Es ist entscheidend wichtig, eine integrierte Lo¨sung fu¨r die Entwicklung von
Applikationen zu besitzen die es ermo¨glicht, von Beginn einer Entwicklung an
kontinuierlich Policies zu u¨berpru¨fen und im Verlauf der Entwicklung anzupas-
sen, ohne die Gu¨ltigkeit der Policies zu verlieren. Diese Vorgehensweise hat sich
in der Umsetzung, Weiterentwicklung und Pflege des Entscheidungssystems
OCS und seiner Dienstfamilie bewa¨hrt. Insbesondere kurzfristig aufgetretene
A¨nderungswu¨nsche wa¨hrend bereits laufender Konferenzen konnten mit dem
vorgestellten Konzept schnell umgesetzt, validiert und fu¨r die Konferenznutzer
sicher zur Verfu¨gung gestellt werden.
2.3 Patterns fu¨r Begutachtungsprozesse
Aufgrund der großen Anzahl von zu begutachtenden Artikeln und den ge-
genu¨berstehenden kleinen Programmkomitees sind effiziente Begutachtungs-
prozesse von großem Interesse. Vorteile durch die Optimierung von Begutach-
tungsprozessen sind:
9Die Dokumenttypdefinition (Document Type Definition), wie das XML-Schema, legen
die Struktur eines Dokuments fest.
KAPITEL 2. VERWANDTE ARBEITEN 43
• Kostenminimierung durch Wegfall von unno¨tigem Zeitaufwand durch
nicht organisierte Diskussionstreffen.
• Die begrenzte Zeit der Gutachter, die in der Regel einer wissenschaftli-
chen Kommunitie angeho¨ren und in diesem Rahmen ehrenamtlich Gut-
achten verfassen.
• Die homogene Verteilung der Begutachtungsaufgaben an die Gutachter.
• Die Auswahl der wirklich besten Artikel aus der Menge der Einreichun-
gen, dieses impliziert die Begutachtung von Artikeln durch Experten in
dem jeweiligen Fachgebiet.
• Gleichbehandlung aller Beitra¨ge, was eine strikte Einhaltung des Begut-
achtungsprozesses fu¨r jeden einzelnen Beitrag voraussetzt. Dies gilt auch
fu¨r Beitra¨ge von Komiteemitgliedern.
Bereits Ende der Neunzigerjahre wurden Erfahrungen aus durchgefu¨hrten Be-
gutachtungsprozessen fu¨r Konferenzen gesammelt und Konzepte fu¨r eine effek-
tive Vorgehensweise niedergeschrieben. In dem bekannten Artikel Identify the
Champion [Nie00] sind mehrere Pattern spezifiziert, die eine Optimierung und
eine Verbesserung der Diskussion u¨ber Annahme oder Ablehnung von Artikeln
darstellen, die in verschiedenen Konferenzen eingesetzt wurden. Das Begutach-
tungssystem CyberChair [Sta01] [vdS09a] basiert ga¨nzlich auf die in [Nie00]
beschriebenen Pattern. Um derartige Basis-Pattern im OCS abzudecken, hat
es sich als gu¨nstig erwiesen, flexible Features zu entwickeln. Die Pattern werden
im nachfolgenden Kapitel 2.3.1 vorgestellt, um sie anschließend in Kapitel 2.3.2
im Hinblick auf den OCS zu analysieren und die Erkenntnisse in Kapitel 2.3.3
aufzuzeigen.
2.3.1 Vorstellung der Pattern
Das grundlegende Ziel ist es, Gutachter so fru¨h wie mo¨glich im Begutachtungs-
prozess als Befu¨rworter (“champion”) von Artikeln zu manifestieren, die sich
fu¨r die Annahme des Artikels wa¨hrend des Programmkomiteetreffens einsetzen
wu¨rden. Diese Treffen dienen zur Bestimmung der Artikel, die zur Konferenz
zugelassen werden. Im Folgenden werden diese Pattern in geku¨rzter Form be-
schrieben, um sie mit den heutigen Erfahrungen, die ich mit dem OCS und
dessen Dienstfamilie gesammelt habe, zu diskutieren.
KAPITEL 2. VERWANDTE ARBEITEN 44
Pattern: Identify the Champion
Dieses Pattern behandelt das grundsa¨tzliche Problem einer Konferenz mit ei-
ner großen Anzahl von Einreichungen und der begrenzten Zeit fu¨r die Ent-
scheidungsfindung. Wie sollte der Begutachtungsprozess entworfen sein, damit
wa¨hrend des Programmkomiteetreffens die besten Artikel akzeptiert werden?
Als Lo¨sung wird jeder Gutachter dazu aufgefordert sich festzulegen, ob er fu¨r
einen Artikel wa¨hrend des Programmkomiteetreffens ein Befu¨rworter ist, oder
nicht. Das Ziel ist es, die Diskussion u¨ber die Annahme oder Ablehnung auf
Artikel mit Befu¨rwortern zu fokussieren, da davon ausgegangen wird, dass die-
se Artikel eine gro¨ßere Wahrscheinlichkeit haben angenommen zu werden, als
diejenigen ohne Verteidiger. Dieses Pattern ist Voraussetzung fu¨r die nachste-
henden Patterns.
Pattern: Experts Review Papers
Um die besten Artikel selektieren zu ko¨nnen ist es wichtig, eine Strategie fu¨r die
Verteilung der Artikel an das Programmkomitee (engl. program committee) zu
verfolgen. Eine gute Beurteilung und Selektion kann nur durch einen Experten
des jeweiligen Fachgebietes durchgefu¨hrt werden. Ein einfacher Weg ist es,
die Fachgebiete und Kompetenzen der Gutachter als Themengebiete fu¨r die
Einreichungen festzulegen und die Autoren im Call for Paper 10 (CFP) dazu
aufzufordern, ihre Artikel diesen Fachgebieten zuzuordnen.
Pattern: Champions Review Papers
Dieses Pattern ist konkurrierend zu Experts Review Papers in dem Sinne,
dass auch hier kompetente Gutachter zu bestimmen sind. Das Ziel ist es, die
Chance eines jeden Artikels zu maximieren, einen Befu¨rworter zu erhalten.
Die Gutachter werden dazu aufgefordert, selbst Artikel fu¨r die Begutachtung
auszuwa¨hlen. Ein Weg ist es, im CFP die Autoren zu einer Absichtserkla¨rung
fu¨r eine Artikeleinreichung aufzufordern, indem sie mindestens eine Woche
vor der eigentlichen Einreichungsfrist des Artikels den Titel, Autoren, Kon-
taktadressen und Schlagwo¨rter schicken. Mittels dieser Informationen ko¨nnen
dann die Gutachter die gewu¨nschten Artikel wa¨hlen. Womit die Zuteilungen
bereits feststehen, sobald die Einreichungsfrist der Artikel abgelaufen ist und
ohne Zeitverlust mit der Begutachtung der Artikel begonnen werden kann.
Pattern: Make Champions Explicit
Dieses Pattern besagt, dass bereits vor dem Programmkomiteetreffen dieje-
10Es handelt sich um ein Beitragsaufruf, mit dem zur Einreichung einer wissenschaftlichen
Arbeit zur Vero¨ffentlichung aufgefordert wird.
KAPITEL 2. VERWANDTE ARBEITEN 45
nigen Gutachter bestimmt werden, die Befu¨rworter von Artikeln sein wer-
den. Eine zur Auswahl vorgegebene Bewertung wie “strong accepted” oder
“good paper” ko¨nnen unterschiedlich interpretiert werden. Eine hohe Beno-
tung sagt nicht zwangsla¨ufig aus, dass der Gutachter auch Befu¨rworter des
Artikels ist und diesen in der Diskussion verteidigen wird. Die vordefinierten
Begutachtungsformulare sollen explizit den jeweiligen Gutachter fragen, ob
dieser Befu¨rworter des Artikels ist oder nicht.
Pattern: Identify the Conflicts
Es wird davon ausgegangen, dass alle oder fast alle Gutachten eingegangen
sind und Vorbereitungen fu¨r ein reibungsloses Programmkomiteetreffen durch-
gefu¨hrt werden mu¨ssen. Es ist wichtig, im Vorfeld des Treffens die umstrittenen
Artikel zu eruieren. Das Ziel einer Rangliste und Klassifizierung der Artikel ist
es, das Komiteetreffen zu strukturieren, indem Artikel in Gruppen mit dem
selben Diskussionsgrund zusammengefasst werden. Eine einfache und effektive
Vorgehensweise ist die Gruppierung der Artikel entsprechend ihrer ho¨chsten
und niedrigsten Punktzahl mittels einer Kennung aus zwei Buchstaben A-D,
wodurch sich die Gruppen AA, AB, AC, AD, BB, BC, BD, CC, CD, DD er-
geben. Diese lassen sich durch die Vereinigung von AA mit AB, CC mit CD
und mit DD zu sieben Gruppen zusammenlegen, was zu einer Vereinfachung
der Diskussion fu¨hrt.
Pattern: Identify Missing Champions
Da PC-Treffen sehr aufwendig und kostenintensiv, nicht wiederholbar und
die Entscheidungsprozesse sehr stark von der Identifikation der Befu¨rworter
abha¨ngig sind, ist es von sehr großem Interesse, potentielle Probleme im Vor-
feld festzustellen. Gutachten ko¨nnen zu spa¨t oder erst kurzfristig geschrieben
sein. Befu¨rworter ko¨nnen verspa¨tet zur Diskussion kommen, oder nicht erschei-
nen. Die Teilnahme und Vorbereitung aller Befu¨rworter und die Einreichung al-
ler Gutachten muss fru¨hzeitig abgesichert werden. Potentielle Befu¨rworter, die
nicht an dem PC-Treffen teilnehmen ko¨nnen, mu¨ssen im Vorfeld durch andere
bzw. zusa¨tzliche Gutachter ersetzt werden, das kann auch unter Umsta¨nden
die Erstellung von neuen Gutachten nach sich ziehen.
Pattern: Champions Speak First
Nachdem die Pattern Make Champions Explicit, Identify the Conflicts, Identify
Missing Champions eingesetzt wurden, ist es nun an der Zeit, das Programm-
komiteetreffen durchzufu¨hren. Es ist wichtig, schnellstmo¨glich die Befu¨rworter
der Artikel zu identifizieren, da ansonsten sehr viel Zeit fu¨r Diskussionen u¨ber
KAPITEL 2. VERWANDTE ARBEITEN 46
Artikel verschwendet wird, die keine Chance haben, akzeptiert zu werden. Ei-
nige grundlegende Regeln fu¨r die Diskussion sind zu bestimmen, um einen
fokussierten Ablauf zu gewa¨hrleisten. Die Artikel sollen in Gruppen diskutiert
werden, entsprechend des Pattern Identify the Conflicts. Da das Treffen in er-
ster Linie dem Akzeptieren von Artikeln dienen soll und nicht der Ablehnung,
ist es wichtig, von einem Befu¨rworter des Artikels eine kurze Zusammenfas-
sung zu erhalten, bevor Gegner des Artikels sprechen. Sollte kein Befu¨rwor-
ter existieren, wird geraten, festzustellen warum niemand vorhanden ist. Falls
kein Befu¨rworter ausgemacht wird, kann der Artikel schnell abgelehnt wer-
den. Ebenfalls wird geraten jedem Teilnehmer des Treffens Kopien von allen
Gutachten zu geben, unter Beru¨cksichtigung von Konflikten. Somit ko¨nnen
Gutachter die Diskussionen u¨ber Artikel besser verfolgen in denen sie nicht
direkt involviert sind.
Pattern: Consensus on PC Papers
Der Fokus dieses Patterns liegt auf der Vorgehensweise fu¨r die Bewertung
von Artikeln die von Programmmitgliedern geschrieben wurden. Artikel von
Porgrammmitgliedern du¨rfen nicht bevorzugt behandelt werden. Eine Konfe-
renz, die den Anschein erweckt, dass Artikel von Programmmitgliedern leichter
akzeptiert werden als die von anderen Autoren, wird nicht als serio¨s angese-
hen. Ein Artikel eines Komiteemitgliedes muss fu¨r seine Akzeptanz minde-
stens einen Verfechter haben und darf von keinem Experten abgelehnt werden.
Die Entscheidungsfindung ist unter Ausschluß des Komiteemitgliedes durch-
zufu¨hren.
2.3.2 Vergleich mit OCS
Der OCS ist entwickelt worden, um alle Beteiligten an einer Konferenz zu un-
terstu¨tzen. Angefangen bei dem Einreichungsmechanismus fu¨r die Autoren bis
hin zur Erstellung des Tagungsbandes durch den Leiter der Konferenz. Der
OCS spiegelt den gesamten Begutachtungsprozess von wissenschaftlichen Ar-
beiten wider und dient zur Vorbereitung der eigentlichen “physikalisch” statt-
findenden Konferenz. Um den Anforderungen an einer effizienten und optima-
len Unterstu¨tzung zu gewa¨hrleisten, wurden im OCS Features entwickelt, die
den Begutachtungsprozess durch vordefinierte Prozesse abbilden und teilweise
automatisieren.
Der OCS ist ein online konfigurierbares, Web-basiertes Begutachtungssystem,
das in Bezug auf das Design der Seiten, der Workflows und der Inhalte von
Formularen fu¨r verschiedenste Konferenzanforderungen anpassbar ist. Durch
KAPITEL 2. VERWANDTE ARBEITEN 47
die konfigurierbaren Begutachtungsformulare, welche in Kapitel 4.4 beschrie-
ben werden, lassen sich Elemente definieren und mit Werten hinterlegen, die
fu¨r die Berechnung einer Note verwendet werden ko¨nnen. Die fu¨r die Berech-
nung beno¨tigte Formel ist ebenfalls frei definierbar. Konferenzen, die nicht das
vordefinierte Gutachtenformular verwenden wollen, ko¨nnen so ihr individuel-
les Formular erstellen. Mit dieser Funktionalita¨t ko¨nnen die Pattern Identify
the Champion und Make Champions Explicit durch direktes Fragen, ob der
Gutachter den Artikel wa¨hrend des Komiteetreffens verteidigen wu¨rde, erfu¨llt
werden. Eine weitere Mo¨glichkeit ist die Befragung jedes Gutachters in den
Foren. Jeder Artikel verfu¨gt u¨ber ein eigenes Forum, das in erster Linie von
den Gutachtern des jeweiligen Artikels zur Diskussion verwendet wird.
Im OCS ko¨nnen beliebige Artikelkategorien spezifiziert werden, um die Artikel
in Gruppen zu gliedern. Diese sind in der Regel Themengebiete von Experten,
die Mitglieder in dem Programmkomitee der Konferenz sind. Durch die von
den Autoren wa¨hrend der Einreichung durchgefu¨hrten Einstufung der Artikel
in die Kategorien, sind die Artikel an Experten zur Begutachtung zuweisbar.
Dieses Vorgehen entspricht dem Pattern Experts Review Papers.
Das Pattern Champions Review Papers ist im OCS durch die Features “Ab-
stract Submission” und “Bidding” realisiert. Autoren reichen mindestens eine
Woche vor der eigentlichen Artikeleinreichung eine Zusammenfassung ihres
Artikels ein und bekunden ihr Vorhaben, einen Artikel zur Konferenz einzurei-
chen. Mit dem “Bidding” Feature bieten die Gutachter anschließend unter Ver-
wendung der Zusammenfassungen und weiteren Artikeldaten auf die Artikel.
In dem Entscheidungssystem Online Journal Service (OJS), der der Dienst-
familie des OCS angeho¨rt, besteht die weitere Mo¨glichkeit mit dem Feature
“Nomination” Herausgeber (Editoren) dazu aufzufordern, eine Liste von Gut-
achtern im Dienst zu spezifizieren. Dies ist hilfreich, da sich die Editoren in
den Fachgebieten auskennen und Kontakt zu entsprechenden Experten haben.
Das Pattern Identify the Conflicts unterscheidet sich von dem des OCS. Das
OCS Feature “Evaluation Matrix” zeigt die Artikel in einer Rangliste an, die
durch den gewichteten Mittelwert der Noten der Gutachten bestimmt wird.
Zusa¨tzlich wird eine Varianz der Gutachten bezu¨glich eines Artikels berech-
net, die die U¨bereinstimmung der Gutachternoten aufzeigt. In Abha¨ngigkeit
der Platzierung des Artikels und dessen Varianz ko¨nnen die Artikel in die Grup-
pen “discussion”, “accepted”, “proposed accepted”, “proposed rejected” oder
“rejected” eingeordnet werden. Entscheidungen u¨ber Artikel mit einer gerin-
gen Varianz, was ein Konsens der Gutachter bedeutet, ko¨nnen schnell getroffen
werden. Eine hohe Varianz zeigt den Bedarf einer Diskussion auf, unabha¨ngig
davon ob es sich um einen Artikel mit hoher oder niedriger Platzierung in der
KAPITEL 2. VERWANDTE ARBEITEN 48
Rangliste handelt. Dadurch ko¨nnen auch schlechter eingestufte Artikel noch
eine Chance zur Annahme erhalten, was bei der alleinigen Beru¨cksichtigung
der Rangliste nicht der Fall wa¨re.
Programmkomiteetreffen von Konferenzen werden heutzutage u¨berwiegend mit-
tels Kommunikationsmedien wie Foren, Email oder Chat durchgefu¨hrt. Die
Problematik des Patterns Identify Missing Champions ist nicht mehr so re-
levant, wie sie es noch vor einigen Jahren war. Der OCS stellt hierfu¨r eine
Forumkomponente zur Verfu¨gung mit dessen Hilfe Komiteetreffen entweder
ga¨nzlich online stattfinden oder zumindest vorbereitet werden ko¨nnen. Komi-
teemitgliedern kann gezielt Zugriff auf die Foren gegeben werden. Das Kommu-
nitie ATPN 11, diskutiert z.B. die Artikel mittels der Forumkomponente und
bereitet so das eigentliche Programmkomiteetreffen vor. Diese Vorgehensweise
hat den Vorteil, dass die Teilnahme aller Gutachter eines Artikels am Treffen
nicht zwingend notwendig ist.
Im OCS diskutieren erst die Gutachter eines Artikels u¨ber dessen Annahme
oder Ablehnung, wie es im Pattern Champions Speak First beschrieben ist. Die
Reihenfolge wer die Diskussion anfa¨ngt, z.B. die Befu¨rworter des Artikels, kann
vom Konferenzleiter im Forum angefordert werden. Falls es zu keinem Kon-
sens kommt, kann die Diskussion auf zusa¨tzliche oder alle Mitglieder erweitert
werden.
Ein generelles Problem stellen die Artikel von Programmkomiteemitgliedern
dar, die im Pattern Consensus on PC Papers behandelt werden. Der OCS
bietet eigens fu¨r diese Art von Problem neben den Prozessen des blind re-
view und double-blind review, zusa¨tzlich den anonymen Begutachtungsprozess
in Bezug auf die Identita¨t der Gutachter an. Diese werden im OCS anonym
behandelt und erfahren weder die Verfasser der anderen Beurteilungen, noch
die Teilnehmer an einer Diskussion.
2.3.3 Fazit
Die in den Pattern Identify the Champion, Experts Review Papers, Cham-
pions Review Papers, Make Champions Explicit und Champions Speak First
gezeigten Vorgehensweisen sind im OCS vorhanden und anwendbar, wie in
Kapitel 2.3.2 beschrieben.
Der OCS setzt die Pattern Identify the Conflicts, Identify Missing Champions
und Consensus on PC Papers dahingegen anders um, wie bereits in Kapi-
tel 2.3.2 aufgezeigt. Durch die Berechnung der Varianz, welche die U¨berein-
11ATPN steht fu¨r Application and Theory of Petri Nets
KAPITEL 2. VERWANDTE ARBEITEN 49
stimmung der Gutachter in Bezug auf deren Benotung darstellt, ist die Fest-
stellung von Konflikten im OCS effizienter als der Lo¨sungsvorschlag im Pat-
tern Identify the Conflicts. Konflikte ko¨nnen direkt erkannt werden. Durch die
Verwendung der Diskussionsforen des OCS kann entweder das Programmko-
miteetreffen “virtuell” stattfinden oder das “physikalische” Treffen vorbereitet
werden. Die Foren stellen fu¨r das Pattern Identify Missing Champions eine ko-
stensparende und effiziente Lo¨sung dar. Ein PC-Mitglied, das nicht am Treffen
teilnimmt, kann vorab die Artikel, die es begutachtet hat mit den entspre-
chenden Gutachtern diskutieren. Die im OCS konfigurierbare Anonymita¨t der
Gutachter wa¨hrend des Begutachtungsprozesses, spiegelt eine Lo¨sung des Pat-
tern Consensus on PC Papers wider. Kombiniert mit dem double-blind review
ko¨nnen Artikel von PC-Mitgliedern begutachtet werden. Die PC-Mitglieder
erfahren nicht, wer der Autor des Artikels ist, noch wer die Gutachten ge-
schrieben hat. Der gesamte Begutachtungsprozess, inbegriffen die Diskussio-
nen, erfolgt anonym. Dies hat zur Folge, dass keine Ausnahmeregelungen fu¨r
die PC Einreichungen notwendig sind und alle Artikel eine Gleichbehandlung
erfahren.
Bedingt durch die flexiblen Features des OCS ist der Ansatz aus dem Arti-
kel Identify the Champion [Nie00] mit dem OCS ebenso umsetzbar, wie die
Anforderungen verschiedener Kommunities. Sind Anforderungen von Kommu-
nities aus mehreren Fachbereichen, wie zum Beispiel der Informatik, Medizin
oder Erziehungswissenschaften zu erfu¨llen, ist die Agilita¨t des System von sehr
großer Bedeutung, da die Anspru¨che an die Systemfunktionalita¨ten differieren.
Diese Art von (fru¨hzeitiger) Bestimmung von Befu¨rwortern findet nicht in allen
Kommunities ihre Anwendung. Fakt ist, das Kommunities unterschiedlichste
Auffassungen daru¨ber haben, wie fu¨r ihre Konferenz der Begutachtungsprozess
zu erfolgen hat. Es haben sich Vorgehensweisen in den Kommunities gefestigt,
die aus der Sicht der jeweiligen Konferenz den optimalen Begutachtungspro-
zess darstellt. Eine Flexibilita¨t des Begutachtungssystems in Bezug auf die
Anpassbarkeit des Begutachtungsprozesses, ist daher aus mehrja¨hriger Erfah-
rung essentiell wichtig.
Teil II
Verwendete Technologien
51
Kapitel 3
Frameworks
Dieses Kapitel stellt das Entwicklungswerkzeug ABC und das fu¨r die Entwick-
lung von web-basierten Applikationen implementierte ABC-Module Extended
Web Info Service (EWIS) vor.
3.1 ABC/jABC
Das 1995 von der Firma METAFrame entwickelte Agent Building Center
(ABC) [SM99] ist eine graphbasierte Entwicklungsumgebung, die den Prozess
der Umsetzung von Softwareprojekten effektiv unterstu¨tzt und das Arbeiten
einer Gruppe von Entwicklern vereinfacht. Mittlerweile wurde das ABC von
dem in Java programmierten jABC abgelo¨st, das ga¨nzlich losgelo¨st von der
Programiersprache C++ ist und Funktionalita¨ten als Plugins zur Verfu¨gung
stellt. Neben dem Springer-OCS Projekt wurden die Frameworks unter an-
derem erfolgreich fu¨r die Projekte Electronic Tool Integration (ETI) [MBK97,
Bra01, Mar05, MRSL07], CTI 1 [Nie03, MSR05], Teaching Management Plat-
form for Universities (TEMPLUS) [Gso04] und IKEA [HMM+06] eingesetzt.
Das ABC basiert auf dem Lightweight Process Coordination Ansatz [MS04b],
der das bekannte Model View Controller (MVC) Konzept um eine Schicht
erweitert. Diese Koordinationsschicht spiegelt die graphische Modellierungs-
ebene des ABC wider und ermo¨glicht eine abstrahierende und flusszentrierte
Sichtweise auf den Gescha¨ftsprozess. Auf diesem erweiterten Konzept baut das
Aggressive model-driven development (AMDD) [MS04a] auf. Das AMDD ver-
setzt Personen ohne tiefere Kenntnisse u¨ber die Diensttechnik oder Program-
1Computer Telephony Integration
53
KAPITEL 3. FRAMEWORKS 54
miersprache in die Lage, Gescha¨ftsprozesse zu modellieren oder bestehende
zu modifizieren. Hierbei handelt es sich um die Applikationsexperten, welche
nachstehend genauer spezifiziert werden.
Bei dem Entwicklungsprozess von Web-basierten Applikationen, wie es beim
OCS der Fall ist, sind verschiedene Aufgaben zu erfu¨llen, die unterschiedlich-
ste Qualifikationen voraussetzen. Die an einer Projektdurchfu¨hrung beteiligten
Personen lassen sich in die folgenden Rollen klassifizieren:
• System-Ingenieur - Analysiert die Aufgabe und erstellt Lo¨sungsansa¨tze,
die mit dem Kunden diskutiert und zur Umsetzung freigegeben werden.
Er ist fu¨r die Erfu¨llung des spezifizierten Lo¨sungsansatzes und dessen
Integration verantwortlich.
• OO-Programmierspezialist - Design und Implementierung der OO-
Business-Objekte. Er ist verantwortlich fu¨r die Business-Objekte, die als
Basis fu¨r die SIBs der Anwendung dienen.
• SIB-Entwickler - Sein Aufgabenbereich besteht aus der Implementie-
rung der fu¨r die Anwendung beno¨tigten SIBs unter Verwendung der
Software-Komponenten des OO-Spezialisten.
• Applikationsexperte - Spezifiziert, modelliert mit Hilfe der vom SIB-
Entwickler implementierten SIBs die Gescha¨ftsprozesse als SLGs.
• GUI-Designer - Erstellt die Bedienungsoberfla¨che der Applikation, die
z.B. in der Sprache HTML 2, JSP 3 oder JSF 4 realisiert wird.
Mit diesem Konzept kann die Entwicklung einer Applikation strukturiert auf
die vorgestellten Rollen aufgeteilt und dadurch eine Trennung der Verantwort-
lichkeiten erzielt werden (vgl. [MS06, Mar07]). Der graphbasierte Ansatz (siehe
Kapitel 3.1.1) vereinfacht das Design und die Modellierung des Kontrollflusses.
Der Applikationsexperte beno¨tigt daher keine IT-Kenntnisse, um einen Dienst
zu modellieren bzw. in Bezug auf sich a¨ndernde Gescha¨ftsprozesse anzupassen.
Der modellierte Kontrollflussgraph visualisiert den Workflow der Applikation
und dient somit bereits zur Designphase als Grundlage zur Diskussion des
Projektes mit dem Gescha¨ftspartner (Kunden). Der Kontrollflussgraph stellt
im Prinzip ein Aktivita¨tsdiagramm dar, wie es in der Modellierungssprache
UML 5 [Fow03] bekannt ist.
2Hypertext Markup Language
3JavaServer Pages
4Java Server Faces
5UML steht fu¨r Unified Modelling Language und dient fu¨r die Anforderungsanalyse von
KAPITEL 3. FRAMEWORKS 55
3.1.1 Modellierung und Validierung
Abbildung 3.1: Das ABC mit geladenem OCS-SLG und SIB-Palette
Die Gescha¨ftslogik wird mittels des ABC’s durch gerichtete Kontrollflussgra-
phen modelliert. Abbildung 3.1 zeigt das ABC mit geo¨ffnetem Service Logic
Graph des OCS und die dem Projekt zugeho¨rige SIB-Palette. Die Service In-
dependent Building Blocks (SIBs) sind Softwarebausteine mit einem einfachen
Aufbau. Ein SIB ist durch zwei wesentliche Merkmale gekennzeichnet. Da ist
zum einen die Spezifikation des SIBs, welche die notwendigen Informationen
fu¨r die Modellierungsebene beinhaltet und zum anderen die Implementierung
des SIBs. Die Implementierung der SIBs ist fu¨r den OCS in Java geschrieben
und definiert die Aktionen, die ein aufgerufener SIB durchfu¨hrt, wie z.B. das
Lesen von Benutzerdaten aus einer Datenbank.
Ein gerichteter Kontrollflussgraph besteht aus einer beliebigen Anzahl von
Knoten, die mittels Kanten verbunden werden. Die Knoten entsprechen den
Anwendungen mittels verschiedener Diagrammtypen, wie Aktivita¨tsdiagramme, Zustands-
diagramme, Klassendiagramme, etc.
KAPITEL 3. FRAMEWORKS 56
in Abbildung 3.1 verwendeten SIBs und die Kanten den verbindenden Pfeilen,
die jeweils von einem zum anderen SIB zeigen und so den Kontrollfluss bestim-
men. Ein weiteres Modellierungselement ist das Makro, welches Kontrollfluss-
graphen oder andere Makros entha¨lt. Es dient zur Kapselung von Teilgraphen,
womit der Umgang mit oft verwendeten Graphen vereinfacht und zentralisiert
wird. Die in Abbildung 3.1 gezeigte SIB-Palette stellt eine SIB-Bibliothek dar,
die neben den spezifischen SIBs der Applikation eine große Vielfalt von bereits
implementierten und durch den Einsatz in verschiedenen Projekten erprobten
und somit robusten Bausteinen zur Verfu¨gung stellt.
SIBs sind wiederverwendbare Bausteine, die nicht nur in der eigenen Doma¨ne,
fu¨r die sie urspru¨nglich entwickelt wurden, sondern auch Doma¨nen-u¨bergrei-
fend zum Einsatz kommen. Viele SIBs sind parametrisierbar und somit flexibel
einsetzbar.
Das im ABC erstellte Modell der Gescha¨ftslogik ist entkoppelt von der dar-
unter liegenden Implementierung der eigentlichen Funktionalita¨ten der Appli-
kation. Insbesondere ist dieses gerichtete Graphmodell bereits zur Designzeit
validierbar mittels formaler Methoden, z.B. mittels Model Checking, wodurch
festgelegte Policies, Regeln und Bedingungen fru¨hzeitig in der Designphase des
Kontrollflusses u¨berpru¨ft werden ko¨nnen, ohne das es einer Implementierung
der SIBs bedarf.
Als temporale Logik kommt CTL 6 [CGP01] zum Einsatz. Spezifikationen in
Form von CTL-Formeln ko¨nnen mit dem FormulaBuilder [JMS06] graphisch
im ABC modelliert werden. Die graphbasierten Formeln werden automatisch
nach CTL u¨berfu¨hrt und dem Model Checker GEAR [BMRS07a, BMRS07b]
u¨bergeben. GEAR u¨bersetzt die CTL-Formel ins µ-Kalku¨hl [EJS93] und fu¨hrt
die Validierung gegen das Graphmodell durch.
Die Computation Tree Logic, welche fu¨r die Beschreibung der gewu¨nschten
Systemeigenschaften verwendet wird, wird nachstehend genauer vorgestellt.
Sei AP eine Menge von atomaren Propositionen, wie z.B. die Annotationen an
den Knoten des Graphmodells, die die Eigenschaften der Komponenten (SIBs)
des SLGs beschreiben.
Definition 3.1.1 CTL Syntax
Fu¨r p ∈ AP sind die CTL Formeln definiert als:
φ ::= p | ¬φ | φ ∨ φ | EX[φ] | E[φ U φ] | A[φ U φ]
6Computation Tree Logic
KAPITEL 3. FRAMEWORKS 57
Die Semantik einer CTL-Formel wird definiert relativ zu einem KTS 7, ein
Transitionssystem mit Aktionsbezeichnungen an den Kanten und atomare Pro-
positionen an den Knoten. Pfade in einem KTS repra¨sentieren die mo¨glichen
Ausfu¨hrungssequenzen eines Systems.
Definition 3.1.2 Pfad
Ein unendlicher Pfad ist eine Sequenz von Zusta¨nden s0, s1, s2, · · · , so dass gilt
(si, a, si+1) ∈→ fu¨r a ∈ Act. Sω kennzeichnet die Menge aller unendlichen
Pfade. Der (i+1)-te Zustand auf einem Pfad pi ∈ Sω wird mit pi[i] bezeichnet.
PK(s) = {pi ∈ Sω|pi[0] = s} bezeichnet die Pfade die vom Zustand s im Kripke
Transitionssystem K starten.
Die Semantik von CTL-Formeln wird induktiv u¨ber ihren Aufbau definiert:
Definition 3.1.3 CTL Semantik
Sei K = (S,Act,→, I) ein Kripke Transitionssystem mit atomaren Propositio-
nen AP, p ∈ AP ist eine atomare Proposotion, s ∈ S ist ein Zustand und φ, ψ
sind CTL Formel. Die Erfu¨lltheitsrelation |= wird definiert durch:
s |= p gdw p ∈ I(s)
s |= ¬φ gdw s |= φ nicht erfu¨llt ist
s |= φ ∨ ψ gdw s |= φ oder s |= ψ
s |= EX[φ] gdw ∃ pi ∈ PK(s).pi[1] |= φ
s |= E[φ U ψ] gdw ∃ pi ∈ PK(s).∃ j ≥ 0.pi[j] |= ψ∧
∀ 0 ≤ k < j.pi[k] |= φ
s |= A[φ U ψ] gdw ∀ pi ∈ PK(s).∃ j ≥ 0.pi[j] |= ψ∧
∀ 0 ≤ k < j.pi[k] |= φ
Weitere Operatoren ko¨nnen abgeleitet werden:
• φ⇒ ψ ≡ ¬φ ∨ ψ und φ ∧ ψ ≡ ¬(¬φ ∨ ¬ψ)
• AX[φ] ≡ ¬EX[¬φ]
• EF[φ] ≡ E[true U φ] und AF[φ] ≡ A[true U φ]
• EG[φ] ≡ ¬AF[¬φ] und AG[φ] ≡ ¬EF[¬φ]
7Kripke Transition System
KAPITEL 3. FRAMEWORKS 58
Neben den u¨blichen logischen Konektoren ¬ und ∨ entha¨lt CTL die tempora-
len Operatoren X und U. Formeln mit diesen Operatoren werden durch einen
Pfadquantor E oder A eingeleitet, der anzeigt ob die Formel auf einem oder
allen ausgehenden Pfaden gelten soll.
• X (next-time) bezieht sich auf den na¨chsten Zustand
• F (finally) bezieht sich auf den Zustand der eventuell erreicht wird
• G (generally) bezieht sich auf den gesamten Pfad
• φ U ψ (until) φ muss solange gelten bis ψ gilt, oder ψ gilt direkt ohne
vorheriges Vorkommnis von φ
Wir interpretieren SLGs als Kripke Transitionssysteme, wobei die SIBs ei-
nes SLGs die Knoten und deren Verzweigungen die Kanten des KTS sind.
Die atomaren Propositionen in den Formeln ko¨nnen eine Existenz von ei-
nem SIB selbst, die Werte von SIB-Parametern und die Erreichbarkeit von
SIBs/Diensten u¨ber den Verzweigungen sein.
Der temporale Operator DIAB (diamond backward) verha¨lt sich wie ein EX
Operator mit umgekehrtem Transitionspfeil. Wir nennen dieses Verhalten EXB,
das besagt, dass mindestens ein Vorga¨nger SIB (Knoten) existiert mit dem Na-
men, der ru¨ckwa¨rts u¨ber einen branch (Kante) mit der Benennung erreichbar
ist.
3.1.2 Ausfu¨hrbare Gescha¨ftsprozesse
Mittels des ABCs und eines integrierten Code-Generators lassen sich Graph-
modelle, wie in Abbildung 3.1 dargestellt, automatisiert in eine Programmie-
rungssprache u¨berfu¨hren. Im Falle des OCS, der in Java implementiert ist, wird
fu¨r das Modell automatisch eine Java-Implementierung erstellt. Die Vorgehens-
weise entspricht der einer Adjazenzliste, die von einer Laufzeitumgebung inter-
pretiert und ausgefu¨hrt wird (siehe Kapitel 3.2). Abbildung 3.2 zeigt einen Aus-
schnitt einer Java-Klasse, die einen Kontrollflussgraphen beschreibt. Das Mo-
dell wurde auf die durch einen Pfeil in Beziehung stehenden SIBs herunterge-
brochen. So wird z.B. der graphische Zusammenhang zwischen den SIBs Crea-
teBody und SendAndStoreMimeMessage als addBranch (‘‘CreateBody’’,
‘‘created’’, ‘‘SendAndStoreMimeMessage’’); definiert und der leichtge-
wichtigen Prozess-Engine EWIS u¨bergeben. Der Kontrollfluss bestimmt sich
aus der Position der Argumente der Methode. Somit wird von CreateBody u¨ber
die Kante created zu SendAndStoreMimeMessage gegangen.
KAPITEL 3. FRAMEWORKS 59
package de.metaframe.ewis.application.editorial.services;
/*
* Generated automatically by Web Info Service Compilation utility
* of the Agent Building Center.
*/
public class ConferenceLogic extends de.metaframe.ewis.Logic
{
public ConferenceLogic ()
throws javax.servlet.ServletException
{
super ();
addBranch ("AccessDBEntryInfo", "dflt", "VectorContains_lockedUsers");
addBranch ("CreateBody", "created", "SendAndStoreMimeMessage");
addBranch ("OpenConnection", "connected", "GetAllInvolvedForumUsers");
addBranch ("PreparePostingNotification", "not_send", "LoopOverUserlist");
addBranch ("PreparePostingNotification", "send", "FillTemplate");
addBranch ("FillTemplate", "filled", "CreateNewMimeMessage");
addBranch ("VectorContains_lockedUsers", "false", "CheckPostingNotification");
addBranch ("VectorContains_lockedUsers", "true", "LoopOverUserlist");
addBranch ("CloseConnection", "closed", "NOOP2");
addBranch ("AddEmailHeaders", "added", "CreateBody");
addBranch ("SendAndStoreMimeMessage", "not_delivered", "LoopOverUserlist");
addBranch ("SendAndStoreMimeMessage", "partially_delivered", "LoopOverUserlist");
addBranch ("SendAndStoreMimeMessage", "delivered", "LoopOverUserlist");
addBranch ("CreateNewMimeMessage", "created", "AddEmailHeaders");
addBranch ("GetAllInvolvedForumUsers", "ok", "LoopOverUserlist");
addBranch ("SetUserPostedFlag", "dflt", "OpenConnection");
addBranch ("LoopOverUserlist", "next", "AccessDBEntryInfo");
...
Abbildung 3.2: Generierter Java Quellcode der Gescha¨ftslogik.
Alternativ ko¨nnte die Adjazenzliste bei kurzlebigen und langlebigen Prozessen
auch in der Datenbank verwaltet werden. Um Leistungseinbußen bei kurzlebi-
gen Prozessen, wie es bei der Navigation von Web-Applikationen der Fall ist,
zu umgehen, mu¨sste Prefetching betrieben werden, d.h. die Adjazenzliste muss
im Speicher vorgehalten werden.
Zusa¨tzlich zu der Java-Abbildung des Workflows wird eine weitere Java-Klasse
generiert, die die Instanziierungen der in dem Graphmodell eingesetzten SIBs
definiert. Die fu¨r die Modellierung geschriebenen SIB Spezifikationen sind
parametrisierbar, d.h. SIBs sind wiederverwendbar und Doma¨nen u¨bergrei-
fend einsetzbar. Die Werte der definierten Parameter werden an die SIB-
Implementierung als Argumente des Konstruktors u¨bergeben. In Abbildung 3.3
ist ein Ausschnitt des Inhaltes einer solchen generierten Klasse aufgezeigt. Wird
der SIB CreateBody aus dem Beispiel zuvor betrachtet, so ist dieser in Abbil-
dung 3.3 in der Zeile addSIB ‘‘CreateBody’’,
new de.metaframe.ewis.application.mailmgmt.sib.CreateBody (
‘‘filledbody’’, ‘‘message’’)); wiederzufinden. Spezifiziert wird einer-
seits der Klassenname des SIBs und der Aufruf der Klasse mit den im Modell
KAPITEL 3. FRAMEWORKS 60
gesetzten Parametern, was zur Instanziierung zur Laufzeit beno¨tigt wird.
package de.metaframe.ewis.application.editorial.services;
/*
* Generated automatically by Web Info Service Compilation utility
* of the Agent Building Center.
*/
public class ConferenceSIBContainer extends de.metaframe.ewis.sib.SIBContainer
{
public ConferenceSIBContainer ()
throws javax.servlet.ServletException
{
super ();
addSIB ("OpenConnection",
new de.metaframe.ewis.application.mailmgmt.sib.OpenConnection
("mailcommconnectionuser", "mailtransportsession","mailconnection1"));
addSIB ("CreateBody",
new de.metaframe.ewis.application.mailmgmt.sib.CreateBody
("filledbody", "message1"));
addSIB ("CheckFeaturePermitted", new CheckFeaturePermitted ("F-FORUM"));
addSIB ("CalculateForbiddenNewsgroups", new CalculateForbiddenNewsgroups ());
addSIB ("CheckUserProfile",
new CheckOrSetUserState ("check", "session", "editorialuser",
"incompleteProfile", "yes"));
addSIB ("IncompleteProfileBranch", new IncompleteProfileBranch ());
addSIB ("GetNavbarFeatures", new GetNavbarFeatures ());
addSIB ("SwitchActiveNavbarButton", new SwitchActiveNavbarButton ("forums"));
addSIB ("AddCallContextError",
new de.metaframe.ewis.application.sib.AddCallContextError ("invalid_ticket"));
addSIB ("UserLockedHandling", new UserLockedHandling ());
...
Abbildung 3.3: Generierter Java Quellcode zur Instanziierung der SIBs.
3.2 EWIS
Die Extended Web Info Service (EWIS) Plattform erweitert das ABC um
Funktionalita¨ten, die fu¨r die Entwicklung von Web-basierten Applikationen
beno¨tigt werden. Dazu geho¨ren unter anderem die Projekte ewis base und
ewis comm. Ewis comm gibt den Applikationsexperten eine vollsta¨ndige SIB-
Bibliothek fu¨r die Modellierung von Email- oder News-Kommunikation an die
Hand, die von mir konzipiert und entwickelt wurde. Ewis base ha¨lt eine Viel-
zahl von implementierten und validierten Basis-SIBs bereit, die in drei SIB-
Gruppen eingeteilt werden.
• Interaktion-SIBs: Zu dieser Gruppe geho¨ren die SIBs, die z.B. eine
HTML-Seite anzeigen, die sogenannten ShowSIBs. Sobald im Kontroll-
fluss ein ShowSIB aufgerufen wird, ha¨lt der Kontrollfuss an und wartet
KAPITEL 3. FRAMEWORKS 61
auf eine Interaktion des Dienstbenutzers. Sobald eine Aktion ausgefu¨hrt
wurde, wird der Kontrollfluss entsprechend weiter abgearbeitet bis der
na¨chste ShowSIB erreicht wird.
• Aktion-SIBs:Diese Art von SIBs werden nacheinander abgearbeitet, sie
befinden sich i.d.R. im Graphen zwischen zwei ShowSIBs. Die SIBs lesen
Daten aus der Datenbank, bereiten diese auf oder verarbeiten eingehende
Daten.
• Transfer-SIBs: EWIS stellt mehrere Datenkontexte zur Verfu¨gung zwi-
schen denen unter Verwendung der Transfer-SIBs Objekte kopiert werden
ko¨nnen.
EWIS verfu¨gt u¨ber eine eigene Laufzeitumgebung mit einer leichtgewichti-
gen Prozess-Engine, die auf Basis der generierten Java-Klasse des Graphmo-
dells den Workflow der Applikation verwaltet und steuert. EWIS baut auf der
Servlet-Technologie [mic09f] auf, d.h. dass die Instanzen der Java-Klassen in
einem Web-Container ausgefu¨hrt werden, wie es bei dem Web-Server Tom-
cat [Fou09c] bzw. JBoss [Hat09] der Fall ist. Des Weiteren verwaltet EWIS
mehrere Datenkontexte, die es ermo¨glichen, die Daten zwischen den einzelnen
SIBs zu transferieren. Die Hauptkontexte werden nachstehend aufgezeigt.
• Container Context: Gespeicherte Objekte sind aus allen Servlets einer
Applikation zuga¨nglich.
• Service Context: Auf den Service Context ko¨nnen alle Sessions des
Services zugreifen.
• Session Context: Eine Session ist nur einem Dienstbenutzer zugeord-
net. Sich in dem Session Context befindliche Objekte sind nur von der
selben Session aus zuga¨nglich.
• Call Context: Der Call Context existiert immer nur zwischen zwei In-
teraktion SIBs und dient zur Thread-Sicherheit.
EWIS wurde in Bezug auf den OCS und seiner Dienstfamilien unter ande-
rem durch eine neue Softwarekomponente fu¨r das Verwalten von Multipart-
Uploads 8 und einer Encoding-Komponente 9 erweitert.
8Das Hochladen von Texten und Dateien in einer Anfrage (Request).
9Es werden Sonderzeichen fu¨r die richtige Darstellung in spezifische HTML-Zeichen ko-
diert.
Kapitel 4
Realisierte Konzepte
Dieses Kapitel stellt die entwickelten Konzepte, die bereits erfolgreich in Pro-
jekten des OCS eingesetzt wurden, vor. Zu den prima¨ren Ansa¨tzen geho¨ren der
Feature-orientierte Entwicklungsansatz und das zur Laufzeit rekonfigurierbare
Rollen/Rechte Management, die zum Erfolg des OCS maßgeblich beigetragen
haben. Die Features Bidding- und Verteilungsmechanismus und Konfigurier-
barer Bewertungsworkflow werden detaillierter betrachtet, da sie repra¨sentativ
sowohl zur Vereinfachung der Arbeitsabla¨ufe fu¨r den Konferenzleiter beigetra-
gen haben, als auch die Flexibilita¨t des Systems und die Wiederverwendbarkeit
darstellen.
4.1 Feature-orientierter Ansatz
Es gibt unterschiedliche Herangehensweisen fu¨r die Entwicklung einer Web-
basierten Applikation. In diesem Kapitel wird der Feature-orientierte Ansatz
beschrieben, der fu¨r die Umsetzung des OCS verwendet wurde. Der OCS ist
ein Beispiel fu¨r die Entwicklung einer komplexen und rekonfigurierbaren Web-
basierten Anwendung. Damit die Komplexita¨t eines Softwaresystems wa¨h-
rend der Entwicklungsphase und spa¨teren Pflege beherrschbar bleibt, werden
Dienstfunktionalita¨ten als Kontrollflussgraphen modelliert und zu Features zu-
sammengefasst. Dieses Vorgehen bestimmt einen strukturierten und validierba-
ren Entwicklungsansatz fu¨r die Umsetzung von komplexen Software-Projekten.
Dienstfunktionalita¨ten werden gekapselt und sind im selben Dienst sowie in der
Produktlinie wiederverwendbar [Cza04]. Kombiniert mit dem MDD 1 auf Gra-
phebene des ABC ko¨nnen auf einfache Weise Services, die die Dienstfunktiona-
1Model-Driven Development
63
KAPITEL 4. REALISIERTE KONZEPTE 64
lita¨ten (Features) der Produktlinie repra¨sentieren, zu einem Dienst orchestriert
werden, was wiederum dem SOA Gedanken entspricht. Hierarchien nehmen
hier eine zentrale Rolle ein, die es ermo¨glichen, Applikationen auf verschie-
denen Abstraktionsebenen zu modellieren ohne dabei die Ausfu¨hrbarkeit zu
verlieren. Bei BPEL wurde erst spa¨t erkannt [KKL+05], dass eine Hierarchie
fu¨r komplexe Prozessketten bzw. Gescha¨ftsabla¨ufe fu¨r die U¨bersichtlichkeit,
Versta¨ndlichkeit und vor allem fu¨r die Wiederverwendbarkeit von entscheiden-
der Bedeutung sind. MDA 2 ist ein Framework fu¨r MDD [SVC06], was dem
Entwickler ermo¨glicht Applikationen zu spezifizieren ohne sich auf Technologi-
en festzulegen. Die Herausforderung ist es, solche Techniken in einfacher Form
dem Anwendungsexperten zuga¨nglich zu machen, um Gescha¨ftsprozesse auch
in Hinblick auf Produklinien zu modellieren. Der in [BM09] vorgestellte Ansatz
auf Basis von UML und MDA verwendet nicht die Abstraktionsebene fu¨r das
Versta¨ndnis von Anwendungsexperten.
4.1.1 Feature Beschreibung
Im Folgenden wird der Begriff Feature eingefu¨hrt, der eine zentrale Rolle fu¨r
die Beschreibung des Entwicklungskonzeptes und das spa¨ter zu erla¨uternde
Rollen/Rechte Management einnimmt. Der Begriff Feature wurde erstmalig
durch den technischen Report [KCH+90] definiert und ist heutzutage sehr ge-
bra¨uchlich, wenn es sich um die Spezifikationen von Leistungsmerkmalen einer
Software oder Hardware handelt. Gerade im Bereich des Marketing und der
Werbung werden potentielle Kunden von Produkten mit dem Begriff Feature
konfrontiert, an denen Produktlinien definiert werden ko¨nnen.
In dieser Arbeit wird ein Feature wie folgt definiert:
• Ein Feature ist eine Teilfunktionalita¨t eines Gesamtsystems.
• Jedes Feature erweitert den Funktionsumfang des Gesamtsystems.
• Ein Feature kann andere Features inkludieren bzw. von anderen abha¨ngen.
• Features werden bestimmt durch externe Sichten auf das System, wie die
eines Benutzers/Kunden oder Dienstanbieters.
• Die Granularita¨t wird bestimmt durch Marketing- oder Provisioning-
Zwecke.
2Model-Driven Architecture
KAPITEL 4. REALISIERTE KONZEPTE 65
Im OCS werden Dienstfunktionalita¨ten in Features klassifiziert. Solche Dienst-
funktionalita¨ten ko¨nnen einerseits dienst-spezifische Gescha¨ftsprozesse, wie das
Einreichen von Papieren, andererseits die Zugriffe auf Sourcen oder verwendete
Dienste sein, wie CVS, Mail oder Datenbanken.
Features werden Rollen zugeordnet, die wiederum einem Dienstbenutzer zuge-
wiesen sind und diesem Zugriff auf die entsprechenden Dienstfunktionalita¨ten
geben. Die Rollen ko¨nnen fein-granular konfiguriert und dadurch konferenzspe-
zifische Anforderungen realisiert werden. Eine derartige spezifische Anforde-
rung ko¨nnte der zweistufige Begutachtungsprozess sein, der es den Gutachtern
ermo¨glicht, die Begutachtungsaufgabe an Reviewer weiterzuleiten, um deren
Gutachten in das eigene einfließen zu lassen.
Abbildung 4.1: Features im OCS: Benutzersicht
Abblidung 4.1 vermittelt einen U¨berblick u¨ber die Verwendung der Features
und deren Hierarchie im OCS aus der GUI-Sicht eines Dienstbenutzers. Ist
ein Benutzer im Dienst angemeldet, so sieht dieser die Navigationsleiste auf
der linken Seite und die Informationsseite der Applikation, die die eigentli-
chen Informationen entha¨lt, rechts daneben. Mittels der Navigationsleiste ist
es einerseits mo¨glich, zwischen den Rollen des Benutzers oder zwischen den
Haupt-Features zu wechseln. Hierzu za¨hlen unter anderem die Features Artic-
les, Setup, Users, Roles, etc. Der momentane Benutzer hat mit seiner selektier-
ten Rolle PC Chair das Hauptfeature Articles gewa¨hlt, das graphisch auf der
KAPITEL 4. REALISIERTE KONZEPTE 66
Seite hervorgehoben ist. Die zugeordnete Informationseite zeigt die Hauptseite
des Article Features an, die List of Articles Seite. Diese Seite beinhaltet
Links zu einigen Sub-Features von Articles, wie Substitute Submission, read
article und remove article. Sub-Features sind kleine Funktionalita¨ten die im
Zusammenspiel mit anderen Sub-Features ein Haupt-Feature definieren.
4.1.2 Feature-basiertes Design
Im Feature-basierten Entwicklungsansatz wird das Design einer Applikation in
einzelne Schichten unterteilt. Die Features werden hierarchisch in Beziehung
gesetzt, wobei die Umsetzung in Komponenten und in Bezug auf den Kon-
trollflussgraphen des ABC in Makros realisiert ist. Eine Verschachtelung von
Makros, und somit der Feature des Dienstes, zeigt die Wiederverwendbarkeit
und die Beziehungen zwischen den Features auf. Jedes Makro ist fu¨r sich ge-
nommen ein SLG, der die Leistungsmerkmale eines Features modelliert. Die
Realisierung eines Features wird verwirklicht durch die Kombination von SIBs
und Makros in SLGs und in Makros selbst.
Das mit dieser Vorgehensweise konzipierte Entscheidungssystem OCS umfasst
mittlerweile eine SLG-Struktur mit u¨ber 2500 Knoten und 3500 Kanten. Das
Entscheidungssystem ist von seinem Implementierungsumfang, beruhend auf
der großen Anzahl der Features und deren Flexibilita¨t, ein umfangreiches Soft-
waresystem. Derartig große Softwareprojekte bringen von Haus aus eine große
Komplexita¨t mit sich, wodurch die U¨berschaubarkeit des Projektes abnimmt.
Mittels des hier vorgestellten Feature-basierten Ansatzes werden Funktiona-
lita¨ten gekapselt und graphbasiert in Beziehung gestellt, was zu einer Struk-
turierung und U¨berschaubarkeit der Dienstkomponenten fu¨hrt. In Abbildung
4.2 ist der Hauptgraph des OCS dargestellt, der durch seine abstrakte Sicht
auf die Applikation recht einfach und u¨bersichtlich ist.
Dieser SLG visualisiert die oberste Kontrollflussschicht der Anwendung und
setzt deren Hauptfunktionalita¨ten (Haupt-Features) mittels eines gerichteten
Graphen in Beziehung. Grundlegend la¨sst sich dieser SLG in die fu¨r eine per-
sonalisierte Web-Anwendung klassischen drei Bereiche unterteilen:
1. Initialisierung: Wa¨hrend der Initialisierung des Dienstes wird das Ma-
kro InitService durchlaufen. Dieses Makro beinhaltet den Initialisierungs-
kontrollfluss z.B. fu¨r die Instanziierung von Gescha¨ftsobjekten und Da-
tenbankadministratoren sowie fu¨r die Registrierung an Diensten wie Da-
tenbank, News, Email oder CVS. Des Weiteren werden Dienst-spezifische
Konfigurationsdaten, wie z.B. der Name der Anwendung, Kontaktadres-
KAPITEL 4. REALISIERTE KONZEPTE 67
sen oder das Aussehen der GUI, in Dienst-Kontexte hinterlegt. Ob die
Initialisierung direkt beim Starten des WebServers oder erst beim ersten
Aufruf des Dienstes geschehen soll, wird im Deployment-Descriptor 3 der
Anwendung spezifiziert.
Abbildung 4.2: Struktur eines Hauptgraphen: Gezeigt am Beispiel des OCS
2. O¨ffentlicher Bereich: Im O¨ffentlichen Bereich befinden sich die Fea-
tures, auf die ohne eine vorherige Authentifizierung zugegriffen werden
darf. Hierzu geho¨ren die Features Registration, ForgottenPwd und Show-
GeneralPages die als Makros im SLG wieder zu finden sind. Im Makro
ShowGeneralPages sind allgemeine Dienstseiten gekapselt, wie z.B. die
Informationen zu dem Dienst oder Kontaktinformationen.
3Eine auf Servlet-basierende Web-Anwendung beno¨tigt einen Deployment-Deskriptor,
eine XML-basierte Datei, unter anderem fu¨r die Konfiguration eines Servlets.
KAPITEL 4. REALISIERTE KONZEPTE 68
3. Interner Bereich: Nur registrierte Benutzer ko¨nnen sich in den inter-
nen Bereich einloggen. Nach erfolgreicher Authentifizierung stehen dem
Benutzer in Abha¨ngigkeit seiner Zugriffsrechte die Features (Makros) im
Graphen zur Verfu¨gung, auf die eine Kante zeigt, die vom SIB UpdateNav
ausgeht, wie z.B. das Article, User oder Logout Feature.
Wie in Abbildung 4.2 gezeigt, ist jedes Feature auf Graph-Ebene durch ein
Makro realisiert, das alle Funktionalita¨ten und Arbeitsabla¨ufe des jeweiligen
Haupt-Features repra¨sentiert. Die Abbildung 4.3 stellt das geo¨ffnete Makro
bzw. das Graphmodell von dem Article Feature vor.
Abbildung 4.3: SLG des Article Feature: Hierarchische Struktur des Feature
Zu sehen ist ein SLG der aus den Elementen SIBs, den Sub-Makros und den
Koordinationselementen (hier Kanten) modelliert wurde. Aus der Dienstbenut-
KAPITEL 4. REALISIERTE KONZEPTE 69
zersicht finden sich die Haupt-Features in der Navigationleiste und die Sub-
Features in der Kontextseite wieder, siehe Abbildung 4.1.
In Abha¨ngigkeit der zu konzipierenden Web-Applikation ko¨nnen Features in
feingranulare Sub-Features unterteilt werden, die selbst als SLGs modelliert
sind, wie in Abbildung 4.3 fu¨r das Haupt-Feature Article zu sehen. Das Sub-
Feature besteht aus einem einfachen Kontrollfluss und koordiniert Aufrufe in
Bezug auf die Sub-Features. Die Verfeinerungstiefe der Stufen ist nicht vorge-
geben, wodurch jedes Sub-Feature ebenfalls durch Makros strukturierbar ist.
Die Feature-u¨bergreifende Verwendung ist erlaubt und erwu¨nscht, um einer-
seits ein hohes Maß an Wiederverwendbarkeit zu erzielen, andererseits Red-
undanzen von Funktionalita¨ten, sprich Implementierungen, zu vermeiden. An
dem Article Feature ist die Benutzung von Sub-Features aus anderen Haupt-
Features zu erkennen. Geho¨ren z.B. die Sub-Features SubmitArticle, ModifyAr-
ticle und SubmitFinalArticleVersion zum Article Feature, sind Reportlist und
DelegateArticle den Features Role bzw. Delegation zuzuordnen.
Die na¨chste Ebene der Design-Struktur weist die Umsetzung der Sub-Features
auf, die ebenfalls als Makro realisiert sind. Diese Ebene beschreibt die Gescha¨fts-
logik der Sub-Features. Abbildung 4.4 zeigt diese Ebene anhand des SubmitAr-
ticle Sub-Features des OCS auf, das die Einreichung von Konferenzbeitra¨gen
modelliert. Im Wesentlichen wird der Kontrollfluss fu¨r den Benutzer durch die
drei Interaktions-SIBs, zu erkennen an der auf sich selbst zeigenden Kante
(Schleife), bestimmt. Der Einreichungsprozess kann in die folgenden Abschnit-
te unterteilt werden:
1. Das durch den SIB PreShowArticleSubmitForm instanziierte Einreichungs-
formular wird von ShowSubmitArticle in Form einer HTML-Seite dem
Dienstbenutzer angezeigt. Sobald dieser den Request absendet, werden
die ausgefu¨llten Pflichtfelder und die Artikeldatei zum WebServer hoch-
geladen.
2. Nachfolgende SIBs u¨berpru¨fen die auf der Server-Seite eingehenden Da-
ten und bereiten diese fu¨r die Besta¨tigung der selbigen durch den Benut-
zer auf.
3. ShowConfirmArticle zeigt die am Server eingegangenen Daten an und
wartet auf die Besta¨tigung der Richtigkeit. Nach Freigabe der Daten
durch den Dienstbenutzer wird der Kontrollfluss weiter abgearbeitet.
4. Der weitere Workflow generiert Objekte, fu¨llt diese mit Daten und leitet
diese an die Persistenzschicht, z.B. Datenbank, weiter. Die Konferenzlei-
ter werden u¨ber die Einreichung eines neuen Beitrages und der Dienst-
KAPITEL 4. REALISIERTE KONZEPTE 70
benutzer (Autor) u¨ber die erfolgreiche bzw. fehlerhafte Einreichung per
Email informiert.
5. ShowSubmitArticleAcknowledgement zeigt abschliessend dem Einreicher
des Beitrages eine Besta¨tigungsseite an, die nochmals die Daten zur Ein-
reichung anzeigt.
Abbildung 4.4: Struktur eines Sub-Features: Das Submit Article Feature
Die vorgestellte feingliedrige Strukturierung von Features stellt gleichzeitig die
Basis fu¨r ein personalisiertes Rollen/Rechtesystem dar, das die Zugriffe auf
die einzelnen Features steuert. So kann das betrachtete Feature Submit Ar-
ticle explizit der Rolle des Autors zugewiesen werden, um Inhabern dieser
Rolle das Recht zu verleihen, einen Beitrag (Artikel) einzureichen. Die Un-
tergliederung von Features ist darauf ausgelegt, verschiedene Anforderungen
in verschiedenen Kontexten zu erfu¨llen. Sub-Features und ihre Granularita¨t
KAPITEL 4. REALISIERTE KONZEPTE 71
werden bestimmt durch Konfigurationsanforderungen und dem Aufbau des
Rollen/Rechtesystems. Im OCS ko¨nnen mit diesem Konzept Zugriffe auf sen-
sible Daten und Funktionalita¨ten des Dienstes gezielt vergeben bzw. entzogen
werden. Die genaue Vorgehensweise wird in Kapitel 4.2 beschrieben.
4.2 Rollen/Rechte Management
Ein kontrollierter Zugriff auf die Dienstfunktionalita¨ten und die vom Dienst
verwalteten Daten ist ein, wenn nicht der wichtigste Punkt fu¨r die Entwicklung
von sicheren Applikationen. Sensible Daten mu¨ssen jederzeit vor unautorisier-
ten Zugriffen geschu¨tzt werden. Hierzu wurde ein Rollen-basiertes Rechtema-
nagement entwickelt, das fu¨r den OCS konzipiert wurde und in anderen, seiner
Dienstfamilie angeho¨rigen, Applikationen ebenfalls erfolgreich eingesetzt wird.
Dieses Management zeichnet sich durch seine hohe Flexibilita¨t aus, das fu¨r
dynamische Rollen und Rechteabha¨ngigkeiten realisiert wurde, wie es z.B. im
OCS der Fall ist. Dessen Rechtezuordnungen stellen eine ho¨here Dynamik als
in anderen Standard RBAC 4 [FK92]-Anwendungen dar. Eine Rolle besteht
aus einer Gruppierung von Rechten, die dem jeweiligen Benutzer dieser Rolle
die spezifischen Zugriffe und Aktionen auf Funktionalita¨ten des Dienstes oder
der Objekte erlauben.
Das Rollen/Rechte Management ist, wie die meisten Funktionalita¨ten der Ap-
plikation, ebenfalls als ein Feature realisiert. Im Hauptgraph (siehe Abbil-
dung 4.2) des OCS ist dieses Feature als Makro mit der Benennung Roles
wiederzufinden. Die Abbildung 4.5 zeigt den SLG des Makros, auf dessen Funk-
tionalita¨ten nachstehend na¨her eingegangen wird.
Der Kontrollflussgraph ist in die drei Bereiche Create Role, Modify Role
undDelete Role unterteilt, die, ausgehend von dem Interaktions-SIB ShowRo-
leRightsMatrix, erreichbar sind. Dem Benutzer des Features Roles wird mittels
des SIBs ShowRoleRightsMatrix eine HTML-Seite angezeigt, dessen Inhalt die
Auflistung aller im Dienst existierenden Rollen ist. Diese Auflistung entha¨lt
sowohl vordefinierte Rollen als auch Rollen die zur Laufzeit der Applikati-
on online angelegt wurden. Der Zugriffskontrollmechanismus des OCS basiert
auf dem Rollen/Rechtesystem und steuert die Zugriffe auf die Features und
Sub-Features des Dienstes. Das Rollen/Rechtesystem ist selbst als ein Feature
entwickelt und wird ebenfalls u¨ber den Zugriffskontrollmechanismus verwaltet.
Der in Abbildung 4.5 mit Create Role gekennzeichnete Teilgraph spiegelt
den Kontrollfluss fu¨r die Erstellung einer neuen Rolle wider. Der Interaktions-
4Role Based Access Control
KAPITEL 4. REALISIERTE KONZEPTE 72
Abbildung 4.5: Role Management Service im OCS: Das Graph-Modell
SIB ShowDefineRole zeigt ein Formular an, mittels dessen der Name und eine
kurze Beschreibung der neu anzulegenden Rolle anzugeben ist. Des Weiteren
wird eine Liste von auswa¨hlbaren Rechten angeboten. Die der Rolle zugewie-
senen Rechte legen den Zugriff auf die Features bzw. der Sub-Features fest
und haben einen direkten Einfluss auf die Benutzersicht bzgl. des Dienstes.
Nach Beta¨tigung des Save Buttons werden die Daten u¨bertragen und der
Aktions-SIB CheckDefineRoleForm ausgefu¨hrt, der die Definition der neuen
Rolle auf Abha¨ngigkeiten u¨berpru¨ft und Fehler aufzeigt. Ist die Definition der
Rolle wohlgeformt, wird diese von CreateRole als ein neuer Eintrag in der Role-
Tabelle der Persistenzschicht abgelegt. Der Prozess wird, bei erfolgreicher Er-
stellung der neuen Rolle, mit der Anzeige der Liste aller Rollen inklusive aller
Neuen angezeigt.
Der Teildienst Modify Role wird u¨ber die Kante modify role erreicht, wenn
ein Benutzer den Modify Role Button einer Rolle benutzt. Der na¨chste aus-
zufu¨hrende SIB GetRole, der ein Rollen-Objekt instanziiert und die entspre-
chenden Daten aus der Datenbank liest, reicht die Rolle an ShowModifyRo-
le weiter, der diese editiert. Nach Modifikation der Rolle und Absenden des
Requests wird die Rolle eingelesen und die Modifikationen mittels CheckMo-
KAPITEL 4. REALISIERTE KONZEPTE 73
difyRoleForm u¨berpru¨ft. Im Fehlerfall wird die vera¨nderte Rolle unter Angabe
der aufgetretenen Fehler zur Korrektur erneut angezeigt. Im Falle der erfolg-
reichen Validierung der A¨nderungen wird das Role-Objekt in der Datenbank
gespeichert. Benutzer, die zu diesem Zeitpunkt mit der alten Rollendefinition
arbeiten, behalten diese zum Schutz vor Inkonsistenzen im Kontrollflussver-
halten bis zur Abmeldung bei. Erst fu¨r eine erneute Anmeldung wird die neue
Rollendefinition wirksam. Zusa¨tzlich ko¨nnen die Inhaber der modifizierten Rol-
len u¨ber die A¨nderung der Rolle per Email informiert werden. Abschließend
wird automatisch zur Rollenu¨bersicht gegangen.
Der dritte Teildienst Delete Role ist fu¨r die Lo¨schung von ausgewa¨hlten
Rollen zusta¨ndig. Fu¨r die Lo¨schung von Rollen gelten die folgenden Randbe-
dingungen:
1. Vordefinierte Basis-Benutzerrollen, d.h. die mit dem Dienst ausgeliefer-
ten Rollen du¨rfen nicht gelo¨scht werden.
2. Es du¨rfen nur neu angelegte Benutzerrollen gelo¨scht werden, die keinem
Benutzer zugewiesen sind. Betroffene Benutzer werden sonst aufgelistet
und der Lo¨schvorgang abgebrochen.
Das Rollen/Rechtesystem ist sehr flexibel, da es sich zur Laufzeit um neue
Rollen erweitern la¨sst, bestehende Rollen ko¨nnen rekonfiguriert werden und
die Zuordnungen der Rollen zu Dienstbenutzern sind frei wa¨hlbar.
4.2.1 Das Benutzer/Rollen-Rechtemodell
Nach der Vorstellung der Strukturierung der Features und des Rollen/Rechte-
systems auf Graphebene, stellt dieses Kapitel die beiden Themen in Bezie-
hung. Die mit den Features bzw. Sub-Features modellierten Funktionalita¨ten
des Dienstes spezifizieren Dienstkomponenten, die einem Dienstbenutzer zur
Verwendung freigeschaltet werden ko¨nnen. Das Benutzer/Rollen-Rechtemodell
(siehe Abbildung 4.6), stellt den Zusammenhang zwischen Benutzern, Rollen
und den Features (Dienstkomponenten) her. Auf diese Modell wird im Folgen-
den na¨her eingegangen.
Definition 4.2.1 legt die Relation zwischen Benutzern und Rollen fest und be-
schreibt die Struktur der Rollen untereinander.
Definition 4.2.1 (Benutzer/Rollen Relation)
• Ein Benutzer ist mindestens einer Rolle zugeordnet.
KAPITEL 4. REALISIERTE KONZEPTE 74
• Eine Rolle kann mehreren Benutzern zugewiesen sein.
• Es ist immer nur eine Rolle zu einem Zeitpunkt fu¨r eine Benutzerinstanz
aktiv.
• Rollen sind unabha¨ngig voneinander.
Die genauen Rollen/Rechte Abha¨ngigkeiten werden in der Definition 4.2.2 auf-
gezeigt.
Definition 4.2.2 (Rollen/Rechte Relation)
• Eine Rolle ist eine Ansammlung von Rechten.
• Ein Recht gibt die Erlaubnis fu¨r den Zugriff auf ein Objekt oder ein
Feature.
• Ein Recht ist eindeutig, d.h. es existiert kein weiteres Recht mit den
selben Eigenschaften.
• Rechte werden in Feature-Kategorien gruppiert.
• Eine Rolle kann Rechte verschiedener Feature-Kategorien enthalten.
Abbildung 4.6: Das Benutzer/Rollen/Rechte Modell
KAPITEL 4. REALISIERTE KONZEPTE 75
Beschreibung der Rechte Synonym
Zugriff auf Artikellisten: eigene, zugewiesene oder alle Artikel F-ART-06
Speicherung von eigenen Notizen F-ART-07
Modifikation der Artikel F-ART-10
Lo¨schung der Artikel F-ART-12
Einreichung einer Zusammenfassung eines Artikels (abstract) F-ART-16
Modifikation der Zusammenfassung (abstract) F-ART-17
Einreichung der Artikelversion zur Zusammenfassung F-ART-19
Verwaltung der hochgeladenen Artikeldateien F-ART-21
Delegierung eines Begutachtungsauftrages F-DEL-01
Annahme oder Ablehnung eines Begutachtungsauftrages F-DEL-02
Erstellung und Sendung von Emails F-MAIL-05
Tabelle 4.1: Auszug einiger OCS Features
Die Abbildung 4.6 stellt die Zusammenha¨nge grafisch dar. Die aufgezeigten
Benennungen F-ART oder F-ROLE sind Feature-Kategorien, die Features
gruppieren, welche Dienstfunktionalita¨ten entsprechen. Das Benennungssche-
ma basiert auf eindeutigen Namen und ist wie folgt aufgebaut:
F-<FeatureKategorie>-<SubFeatureID>.<Filter>
• Die FeatureKategorie bezeichnet einen Hauptdienst der Applikation,
der als eigener SLG realisiert ist.
• Die SubFeatureID referenziert einen dem Hauptdienst zugeordneten
Dienst, der als eigener SLG oder SIB umgesetzt wurde.
• Das Suffix Filter ist optional und dient zur feingranularen Spezifizierung
einer Berechtigung.
Der beschriebene Aufbau la¨sst sich einfach an der Feature-Kategorie Article
verdeutlichen, welche mit dem Synonym ART bezeichnet wird. Die einzelnen
Sub-Features einer Feature-Kategorie erhalten eindeutige Namen, indem dem
Haupt-Feature eine fortlaufende Nummerierung angeha¨ngt wird (siehe Abbil-
dung 4.6). Zum Beispiel verleiht das Feature F-ART-03 das Recht, neue Bei-
tra¨ge einzureichen. Zur Laufzeit wird u¨berpru¨ft, ob der Dienstbenutzer dieses
Recht hat, bevor der Einreichungsmechanismus zur Verfu¨gung gestellt wird.
Die Tabelle 4.1 zeigt einen Ausschnitt weiterer Rechte.
KAPITEL 4. REALISIERTE KONZEPTE 76
Ein Beispiel fu¨r die Verwendung von Filter ist die Erlaubnis, Artikel lesen
zu du¨rfen, F-ART-05. Die Erlaubnis sagt nur aus, dass der Teildienst, der
einen Artikel zum Lesen bereit stellt, verwendet werden darf, aber nicht welche
der Artikel anzuzeigen sind. Hier wird mittels des Filters unterschieden, ob
nur die eigenen Artikel (F-ART-05.own), nur die delegierten Artikel (F-ART-
05.delegated) oder alle Artikel (F-ART-05.all) gelesen werden du¨rfen.
4.2.2 Zugriffsrechte zur Laufzeit
Zur Laufzeit der Applikation sind alle Features, die auf der Modellierungsebe-
ne definiert worden sind, existent. Die Inhalte einer Seite und somit auch die
Funktionalita¨ten des Dienstes sind von der Rolle, mit der sich ein Benutzer
in den Dienst angemeldet hat, abha¨ngig. Die Rolle beschreibt die Dienstfunk-
tionalita¨ten und die darauf erlaubten Aktionen, die ein Benutzer sehen bzw.
ausfu¨hren darf. Im Folgenden wird detaillierter auf die Bestimmung der Zu-
griffsrechte zur Laufzeit eingegangen. Die Darstellung wird am Beispiel des
OCS vorgenommen.
Nach dem erfolgreichen Anmeldevorgang wird der Benutzer in den internen
Bereich der Anwendung geleitet. Aufgrund seiner Rolle wird die Sicht auf den
Dienst in dem Sinne personalisiert, dass die Navigationsleiste die dem Benutzer
zugeordneten Rollen und die ihm erlaubten Feature-Links beinhaltet. Jeder
Feature-Eintrag in der Navigationleiste fu¨hrt zu einem Hauptfeature, wobei die
Sub-Features selbst bzw. deren Verlinkung in der Informationsseite zu finden
sind. Dieses Vorgehen lehnt sich an die in Kapitel 4.1.2 beschriebenen Feature-
Struktur an.
Die Zugriffsrechte zur Laufzeit ha¨ngen von mehreren Aspekten ab. Es ko¨nnen
z.B. Einreichungen gruppiert werden, um Benutzern gezielt Zugriff auf Ar-
tikelkategorien zu gewa¨hren. Konflikte ko¨nnen zwischen einem Benutzer und
Artikel spezifiziert werden und stellen einen eingeschra¨nkten Zugriff auf die Ar-
tikel dar. Diese Aspekte entsprechen einer Filterung der im Dienst vorhandenen
Artikel. Der Ablauf von Konferenzen ist in Phasen unterteilt und unterliegt
Zeitvorgaben, Rollen vergeben Berechtigungen, und Zugriffe auf Objekte sind
zustandsbehaftet. Die Zugriffsrechte auf Objekte im Dienst sind somit dyna-
misch und ko¨nnen sich jederzeit a¨ndern. Fu¨r den OCS lassen sich die folgenden
Punkte festhalten, die die Zugriffsrechte bestimmen:
• Die Rechte der Rolle des Benutzers (user).
• Die Zugriffsrechte, die abha¨ngig von dem Status des Objektes sind.
KAPITEL 4. REALISIERTE KONZEPTE 77
• Die Konferenzrestriktionen, die z.B. von den Konferenzzeitfristen ab-
ha¨ngen. Nach Ablauf einer Zeitvorgabe, z.B. der Zeitraum in dem die
Artikeleinreichung mo¨glich war, werden die entsprechenden Rechte zur
Verwendung des Features entzogen.
Diese Art von Rechten bestimmen die Zugriffe bzw. Aktionen auf Objekte. Die
Menge der Rechte sind zu Beginn einer Konferenz festgelegt und somit statisch
zur Laufzeit des Dienstes. Die im Dienst verwalteten Objekte sind zustandsbe-
haftet, die in Abha¨ngigkeit ihres jeweiligen Status verschiedene Zugriffsrechte
voraussetzen. Die Status-basierten Rechte der Objekte sind zur Laufzeit der
Applikation festgelegt. Die Zuordnung zwischen Rollen und Benutzern und
die Zuweisung von Rechten zu Rollen sind zur Laufzeit konfigurierbar. Dieses,
unter Beru¨cksichtigung der Mo¨glichkeit, neue Rollen zu erstellen, macht das
Konzept sehr flexibel und im Hinblick auf die Rechtevergabe sehr dynamisch.
Dieses projiziert sich ebenfalls auf die Benutzersicht. Funktionalita¨ten werden
entweder automatisch durch den Dienst (z.B. U¨bergang zur na¨chsten Phase)
oder manuell durch den Konferenzleiter ein- bzw. ausgeschaltet. Durch die An-
zahl der vorgestellten Aspekte und der daraus folgenden Dynamik der Rechte,
wird die Autorisierung fu¨r einen Zugriff fu¨r jede Anfrage neu berechnet und
u¨berpru¨ft:
1. Berechnung der Benutzerrechte Perm (Permissions) unter Beru¨cksichti-
gung der Rollenrechte, der Objektrechte und der Konferenzrestriktionen:
Perm = (roleperm ∩Objectperm) \ conferencerestr
2. U¨berpru¨fung, ob die berechneten Rechte die no¨tigen Zugriffsrechte fu¨r
das entsprechende Objekt haben:
Accessperm ⊆ Perm
3. Bei erfolgreicher Pru¨fung wird dem Benutzer erlaubt, die durch das Recht
spezifizierte Aktion auf dem Objekt durchzufu¨hren.
Beispiel: Lesezugriff auf einen Artikel
Das Beispiel beinhaltet die Berechnung des Zugriffsrechtes fu¨r das Feature
F-ART-05, das einem Benutzer das Lesen von Artikeln erlaubt. Zu beru¨ck-
sichtigen sind die Rechte des Benutzers, die Restriktionen der Konferenz und
die beno¨tigten Rechte des Objektes. Die Benutzerrechte werden nach der An-
meldung aus der Datenbank gelesen und bleiben fu¨r die Session unvera¨ndert.
KAPITEL 4. REALISIERTE KONZEPTE 78
Die Konferenzrestriktionen und die Objektzugriffsrechte werden in Dateien
definiert.
Ein Konferenzstatus ist gu¨ltig zwischen zwei Zeitfristen (deadlines). Jeder Kon-
ferenzstatus spezifiziert Restriktionen, die Dienstfunktionalita¨ten bis zum Ab-
lauf der Zeitfrist verbieten. Das Entscheidungssystem verfu¨gt u¨ber mehrere
Deadlines, die gleichzeitig die Phasen des Entscheidungssystems repra¨sentie-
ren. Als Beispiel wird die Definition der single report deadline gezeigt, die
Features auflistet, die bis zum Ablauf der Deadline verboten sind:
SingleReportDeadline =
F-ART-03, F-ART-16, F-ART-17, F-ART-19
Der Artikelstatus basiert auf einer Zustandsmaschine, die in Abha¨ngigkeit ei-
nes Ereignisses in den na¨chsten Zustand, wie created, abstract, submitted oder
delegated u¨bergeht (Transition). Die erlaubten Berechtigungen im Status De-
legated (der Artikel wurde zur Begutachtung weitergeleitet), sind wie folgt
definiert:
Delegated =
F-ART-05, F-ART-06, F-ART-07,
F-ART-10, F-ART-12, F-ART-21, F-BID-01,
F-DEL-01, F-DEL-02, F-MAIL-05
Es wird davon ausgegangen, dass die SingleReportDeadline die na¨chste ablau-
fende Deadline ist, der Status des Artikels Delegated aufweist, den ein Benutzer
beabsichtigt zu lesen, und dass die Rolle des Benutzers das Leserecht F-ART-
05 erlaubt. Wird die SingleReportDeadline und der Artikelstatus zusammen
mit dem Recht des Benutzers, den Artikel laut seiner Rolle lesen zu du¨rfen
betrachtet, so wird dem Benutzer der Artikel zum Lesen freigegeben. Das ist
daran zu erkennen, dass der Konferenzstatus das Lese-Feature nicht verbietet
und der Artikelstatus Delegated F-ART-05 erlaubt.
4.2.3 Personalisiertes Rechtemanagement
Der in diesem Kapitel betrachtete Ansatz ist eine Erweiterung des Benutzer/
Rollen-Rechtemodells, das in Kapitel 4.2.1 vorgestellt wurde. Das existierende
Modell weist eine Flexibilita¨t der Rechtevergabe in Bezug auf Rollen auf. Die
Bu¨ndelung von Rechten mittels Rollen, die zur Laufzeit modifiziert und er-
stellt werden ko¨nnen ist ein ada¨quates Mittel zur Verwaltung und Zuweisung
von Rechten fu¨r Konferenzen. In Konferenzen sind die Rechte der Benutzer
einer Rolle u¨ber den Begutachtungsprozess anna¨hernd gleich. Die Erfahrung
hat gezeigt, dass in manchen Situationen eine noch ho¨here Flexibilita¨t von
KAPITEL 4. REALISIERTE KONZEPTE 79
No¨ten ist, um alle Anforderungen komfortabel erfu¨llen zu ko¨nnen. Dieses wur-
de ersichtlich beim Online Journal Service (OJS), der Web-Applikation fu¨r die
Unterstu¨tzung von Herausgebern wissenschaftlicher Zeitschriften. Der Dienst
geho¨rt zur Dienstfamilie des OCS und basiert auf gemeinsamen Funktiona-
lita¨ten wie Article, Delegation und dem Report Feature. Unterschiede treten
im Entscheidungsprozess und in der Laufzeit auf. Der Entscheidungsprozess
des OJS weist einen asynchronen Begutachtungsprozess in der Hinsicht auf,
dass die Einreichungen einen eigenen Prozess durchlaufen, anders als bei der
synchronen Evaluation beim OCS, in der alle Beitra¨ge konkurrierend involviert
sind. Fu¨r die Entscheidungsfindung wird ein zum OCS verfeinertes Prozessma-
nagement eingesetzt, das eine beliebige Anzahl von Begutachtungsdurchga¨ngen
von u¨berarbeiteten Artikeln (Revisionen) verwaltet. Dieser Workflow bringt ei-
ne gro¨ßere Anzahl von leitenden Rollen mit sich (Editor, Editor in Chief, Guest
Editor, Editorial Office, ...). Aufgrund der viel la¨ngeren Laufzeit eines Journals
im Vergleich zu den drei bis vier Monaten einer Konferenz kommt es gewo¨hnli-
cherweise zu A¨nderungen der perso¨nlichen bzw. beruflichen Situation einzelner
Benutzer, was Auswirkungen auf ihre Rechte im laufenden Dienst hat. Dieses
verlangt nach einer individuellen Anpassung der erlaubten Sichten und Aktio-
nen des Benutzers an den Dienst mittels eines feingranularen Managements
fu¨r Rollen und Rechte.
Das Benutzer/Rollen-Rechtemodell wurde um eine weitere Schicht erweitert,
die Benutzerrechte verwaltet. Individuelle Rechte von Einzelnen konnten somit
hinzugefu¨gt bzw. entzogen werden, ohne die gesamte Rolle zu modifizieren. Die
im Folgenden detaillierter beschriebene Erweiterung wurde als Feature reali-
siert und konnte so auf einfache Weise ebenfalls in den OCS integriert werden
und erwies sich dort als sehr nu¨tzlich. Ein Beispiel ist der Ablauf der Einrei-
chungsfrist fu¨r Artikel. Soll z.B. einigen Autoren gezielt das Einreichungsrecht
F-ART-03 nach Ablauf der Deadline verliehen werden, damit diese weiterhin
Beitra¨ge hochladen ko¨nnen. Dieses war zuvor nur mo¨glich, indem der gesamten
Rolle und somit allen Autoren das Recht eingera¨umt wu¨rde.
Personalisierung: Benutzer/Rechte-Management
Die Personalisierung mittels Benutzerrechten ist als erweiterndes Konzept zum
bestehenden Benutzer/Rollen-Management entstanden. Das Konzept vereinigt
die globale Definition von Rechten u¨ber Rollen mit der Flexibilita¨t des indivi-
duellen Rechtemanagements eines Benutzers. Die Benutzer/Rollen Definition
lautet:
Definition 4.2.3 (Benutzer/Rechte Relation)
KAPITEL 4. REALISIERTE KONZEPTE 80
• Ein Recht kann einem oder mehreren Benutzern erteilt werden.
• Ein Recht kann explizit einem Benutzer entzogen werden, d.h. dieses wird
als Restriktion vermerkt.
• Ein Benutzer kann mehreren Rechten aus verschiedenen Feature-Kate-
gorien zugeordnet sein.
Die Zuordnung bzw. der Entzug eines Rechtes geschieht immer mit Bezug auf
eine Rolle, sodass die individuelle Vergabe der Rechte fu¨r jede Rolle verfeinert
werden kann. Diese Vorgehensweise stellt eine erho¨hte Flexibilita¨t der Einstel-
lungen dar. Unter Beru¨cksichtigung der neuen Relation hat sich die Berechnung
des Rechtes fu¨r einen Zugriff oder die Benutzung einer Dienstfunktionalita¨t wie
folgt gea¨ndert:
Perm = ((roleperm ∪ userperm) ∩Objectperm)
\userrestr \ conferencerestr
Accessperm ⊆ Perm
Die in Kapitel 4.2.2 eingefu¨hrte Formel ist um die Permissions und Restriktio-
nen des Benutzers (user) erweitert worden. Realisiert ist die Erweiterung, wie
alle Dienste in der OCS-Familie als ein eigener SLG, der dem Feature Users
zugeordnet ist. Der SLG des personalisierten Rechtemanagements wird in Ab-
bildung 4.7 gezeigt. In dem Graphen ist sehr gut die Verwendung des Wizard-
basierten Datenaustausches zwischen den verschiedenen Kontexten (siehe Ka-
pitel 3.2) zu erkennen. Objekte werden in der Dienstfamilie in einem Kontext
gehalten, der der jeweils eindeutigen Anfrage (Request) zugeordnet ist und
dadurch die Threadsicherheit gewa¨hrleistet. Der Benutzer kann parallel mit
mehreren Browser-Fenstern auf denselben Workflow zugreifen.
Der Dienst besteht aus vier Teilfunktionalita¨ten:
• Der mit user’s roles gekennzeichnete Teilgraph zeigt eine Liste von
Rollen (ShowUserRoleList), die einem Benutzer zugewiesen sind. Die In-
formation u¨ber die Rollenzuordnung wird aus der Datenbank mittels
des SIBS UserRoleList gelesen und dem Wizard mit dem SIB Con-
text2Wizard u¨bergeben, der Objekte Kontext-u¨bergreifend im Cache ha¨lt.
Context2PreShow schreibt die Objekte in einen separaten Kontext, der
alle beno¨tigten Objekte fu¨r das Fu¨llen der HTML-Seite beinhaltet.
KAPITEL 4. REALISIERTE KONZEPTE 81
• Der Teilgraph user’s permissions stellt den Kontrollfluss von der Aus-
wahl der Rolle, fu¨r die Benutzerrechte spezifiziert werden sollen, bis
hin zur Anzeige der Seite durch ShowUserPermissions dar. Der SIB
UsersPermissionList liest die Benutzerrechte und zeigt die Benutzer-
spezifischen Rechte und Restriktionen mit den Rechten der ausgewa¨hlten
Rolle an.
• Die Berechtigungen und Restriktionen ko¨nnen nun modifiziert werden.
Nach dem Absenden des Formulars werden die Daten Server-seitig u¨ber-
pru¨ft und mittels des SIBs ShowConfirm zur Besta¨tigung angezeigt. Der
Workflow confirmation wird mit der Besta¨tigung abgeschlossen.
• Zum Abschluss werden alle Berechtigungen und Restriktionen in der Da-
tenbank gespeichert, dieses wird von stores permissions durchgefu¨hrt.
Abbildung 4.7: Benutzer/Rollen-Management: SLG
Der Zugriff auf ein Feature wird graphbasiert mit dem SIB CheckFeaturePer-
mitted modelliert und zur Laufzeit u¨berpru¨ft. Die aktuellen Rechte des Benut-
zers werden zusa¨tzlich dynamisch mittels der expliziten Benutzerberechtigun-
KAPITEL 4. REALISIERTE KONZEPTE 82
gen gefiltert. Der SIB CheckFeaturePermitted vergleicht vor einem Zugriff die
nach der Filterung u¨bergebliebene Menge von Rechten mit den erforderlichen
Features des Objektes.
Es wurde ein hohes Maß an Flexibilita¨t und Einfachheit bei der Konfigurati-
on von Berechtigungen mit einer minimalen Erho¨hung des Pru¨fvorgangs zur
Laufzeit erzielt. In der Praxis konnte so einem Editor im OJS individuell das
Recht fu¨r die beno¨tigte Sicht auf die Begutachtungsverteilung gegeben werden,
ohne der Rolle Editor und somit allen Rolleninhabern diese Sicht zu geben.
Es ist einfacher und komfortabler auf Basis einer allgemein definierten Rolle,
Rechte an Benutzer zu verleihen und gezielt einem Benutzer das Recht zu ent-
ziehen, bestimmte Informationen u¨ber seinen Artikel zu sehen, ohne andere
Dienstbenutzer zu beeinflussen. Es ist weiterhin mo¨glich, zentralisiert Rechte
u¨ber eine Rolle an die Inhaber zu vergeben bzw. zu entziehen. Ein Ansatz die
Rechtevergabe ga¨nzlich u¨ber direkte Benutzer/Rechte-Relationen zu realisie-
ren, wa¨re mit einem extremen Wartungsaufwand verbunden, da jede A¨nderung
einer Rolle dann fu¨r jeden betroffenen Benutzer durchgefu¨hrt werden mu¨sste.
4.2.4 Validierung des Zugriffskontrollmechanismus
Wie das zugrunde liegende Rollen/Rechte-Management, spielt die Erweite-
rung des Zugriffsmechanismus eine ebenso wichtige und zentrale Rolle im Um-
gang mit vertrauensvollen Daten und den hierzu konzipierten Dienstfunktiona-
lita¨ten. Umso gro¨ßer ist die Bedeutung des Wissens, den Kontrollflussgraphen
als sicher in Bezug auf die Erfu¨llung von Bedingungen (constraints) model-
liert zu haben. Hierzu wird der Benutzer/Rechte-Graph ebenfalls einer Model
Checking Validierung unterzogen und kann bei erneuten A¨nderungen schnell
auf seine Richtigkeit hin u¨berpru¨ft werden.
Der in Abbildung 4.7 dargestellte und bereits ero¨rterte Kontrollflussgraph des
Benutzer/Rechte-Managements, weist die drei Interaktions-SIBs ShowUser-
List, ShowListPermissions und ShowConfirm auf. Diese SIBs zeigen HTML-
Seiten mit vertrauenswu¨rdigen Rechtezuweisungen an. Der Inhalt dieser Sei-
ten und die inkludierte Mo¨glichkeit zu Modifikationen der Rechtezuweisungen
muß vor unautorisierten Zugriffen geschu¨tzt werden. Es ist zu u¨berpru¨fen, ob
der zugreifende Benutzer die beno¨tigten Rechte fu¨r das entsprechende Feature
und die damit zusammenha¨ngenden Informationen besitzt. Die U¨berpru¨fung
der Zugriffsvoraussetzungen werden im Graphmodell mit dem SIB CheckFea-
turePermitted vor jedem Interaktions-SIB modelliert und zur Laufzeit beru¨ck-
sichtigt.
Fu¨r das Model Checking werden die drei SIBs, die jeweils eine HTML-Seite
KAPITEL 4. REALISIERTE KONZEPTE 83
zur Interaktion mit dem Dienstbenutzer anzeigen, zur Gruppe des ShowSIB
geza¨hlt. Fu¨r die Validierung werden alle ShowSIB mit der atomaren Proposi-
tion ShowSIBs im SLG annotiert.
Der na¨chste Schritt ist die Definition der temporal logischen Formel, die die
Eigenschaften beschreibt, dass direkt vor jedem ShowSIB der SIB CheckFea-
turePermitted vorkommen muss und die verbindende Kante permitted lautet
(siehe Abb. 4.7).
Abbildung 4.8: Benutzer/Rollen-Management: Temporal logische Formel
Die temporallogische Formel la¨sst sich ihrerseits mittels des FormulaBuilders
[JMS06] als Graph modellieren (siehe Abbildung 4.8) und zu CTL Syntax
u¨bersetzen:
’ShowSIB => ![permitted]! CheckFeaturePermitted ∨
’ShowFeatureDescription
In der Formel ist der SIB ShowFeatureDescription von der eigentlichen Sicher-
stellung von unautorisierten Zugriffen ausgeschlossen worden, da er in diesem
Zusammenhang als unkritisch angesehen wird.
Mittels des Model Checkers GEAR [BMRS06] wird diese temporallogische For-
mel gegen den Kontrollflussgraphen gepru¨ft. In Abbildung 4.9 wird das Ergeb-
nis der Validierung grafisch dargestellt. In diesem fehlerhaften SLG ist der
Pfad vom SIB UserPermissionList u¨ber die Kante permitted zum SIB ShowU-
serPermissions als Fehlerpfad hervorgehoben. Dies begru¨ndet sich darin, dass
laut definierter Formel nur der SIB CheckFeaturePermission mit ShowUser-
Permissions u¨ber die Kante permitted verbunden sein darf, um die beno¨tigte
Zugriffsu¨berpru¨fung sicherzustellen.
KAPITEL 4. REALISIERTE KONZEPTE 84
Abbildung 4.9: Benutzer/Rollen-Management: Validierung
4.3 Bidding- und Verteilungsmechanismus
Das Feature Bidding za¨hlt mit zu den wichtigsten Funktionalita¨ten des OCS.
In der Phase der Verteilungen der Begutachtungsaufgaben minimiert dieses
Feature den Arbeits- und Koordinationsaufwand der Konferenzleiter drastisch.
Wird die mit dem OCS durchgefu¨hrte Konferenz Advanced Data Mining And
Applications 2009 (ADMA) betrachtet, so zeigt sich mit 322 Artikeln, 1169
Verteilungen und 795 Benutzern die Gro¨ße der Konferenz. Eine ada¨quate Ver-
teilung von Begutachtungsaufgaben in diesen Gro¨ßenordnungen stellt die Kon-
ferenzleiter vor eine sehr große Herausforderung, die manuell nur mit einem
immensen Zeit- und Arbeitsaufwand zu bewa¨ltigen wa¨re. Der Bidding- und
Verteilungsmechanismus wurde realisiert, um diesen Aufwand so gering wie
mo¨glich zu halten und gleichzeitig die beste, auf die Konferenz abgestimmte,
KAPITEL 4. REALISIERTE KONZEPTE 85
Verteilung zu gewa¨hrleisten.
Eine gute Verteilung sollte die folgenden Punkte beachten:
• Alle Gutachter haben dieselbe Arbeitsauslastung.
• Artikel werden von Experten begutachtet.
• Mindestens drei Gutachter beurteilen einen Artikel.
Der Zeitrahmen fu¨r die Erstellung der Gutachten wird in der Regel von einer
gemeinsamen Deadline bestimmt. Ein ausgeglichener Arbeitsaufwand stellt
den Gutachtern das gleiche Zeitfenster fu¨r jeden Artikel zur Verfu¨gung und
gewa¨hrleistet jedem Artikel dieselbe zeitliche Aufmerksamkeit. Eine Ausnahme
stellen Gutachter mit vielen SubReviewern dar, an die weiterdelegiert werden
kann. Die Begutachtung von Artikeln durch Experten bzw. Gutachtern mit
Wissen in dem Themenbereich des jeweiligen Beitrages, ist ein wichtiger Be-
standteil fu¨r die gerechte Bewertung eines Artikels. Nicht außer Acht gelassen
werden darf das Interesse eines Gutachters an einem Artikel. Zwangszuwei-
sungen sind fu¨r den Begutachter nicht immer erfreulich und ko¨nnen u.U. die
Beurteilung beeinflussen oder zu einer Ablehnung des Artikels fu¨hren. Letzt-
endlich finden die Begutachtungen ehrenamtlich statt ohne jegliche Bezahlung.
Um eine repra¨sentative Beurteilung und Entscheidungsfindung zu gewa¨hrlei-
sten, werden Artikel von mindestens drei Gutachtern beurteilt.
Das Bidding Feature zeigt die Zuordnungen zwischen Artikeln und Gutachtern
in einer Matrix an und unterstu¨tzt die Konferenzleiter in folgender Weise:
1. Die Gutachter stimmen fu¨r die zu begutachtenden Artikel:
• B (“bid”): Sehr großes Interesse an der Begutachtung des Artikels.
• I (“indifferent”): Geringes Interesse, aber bei einer Zuteilung
wu¨rde die Begutachtung durchgefu¨hrt werden.
• U (“unable”): Zu geringes Fachwissen, um eine sichere Beurtei-
lung abgeben zu ko¨nnen.
• R (“rejected”): Ablehnung der Begutachtung des Artikels.
• C (“conflict”): Der Gutachter hat einen Konflikt mit den Autoren
des Artikels. D.h. er kennt die Autoren und wu¨rde eventuell bei der
Bewertung beeinflusst sein.
2. Berechnung der Arbeitsauslastung des einzelnen Gutachters auf Basis
der mit B gewa¨hlten Artikel.
KAPITEL 4. REALISIERTE KONZEPTE 86
3. Berechnung einer Verteilung der Begutachtungsaufgaben mittels lp solve
[Ber09], ein externes Programm zur Lo¨sung von linearen Optimierung-
problemen.
4. Automatische Verteilung der Aufgaben an die Gutachter per Mausklick.
Diese Vorgehensweise wird dem Konferenzleiter empfohlen, damit der Auf-
wand minimal gehalten wird. Das Feature ist sehr flexibel, so dass Schritt 1.
nicht stattfinden muss, um eine gleichma¨ssige Verteilung mit Schritt 3. zu er-
zielen. Allerdings ko¨nnen Gutachter ohne Schritt 1. keinen direkten Einfluss
auf die Verteilung nehmen und die Grundlage fu¨r das Delegieren an Fachkom-
petenzen des Themenbereiches des jeweiligen Artikels wa¨re nicht automatisch
beru¨cksichtigt. Die Konferenzleiter ko¨nnen die Delegierungen auch ohne die be-
schriebenen Schritte durchfu¨hren, indem diese manuell die Artikel/Gutachter-
Beziehung setzen. Des Weiteren ist jederzeit eine manuelle A¨nderung der Ver-
teilungsplanung und unter Beru¨cksichtigung der dadurch auftretenden neuen
Konstellationen erneute Berechnung der optimalen Lo¨sung mo¨glich.
Abbildung 4.10: Bidding Feature - Auswahlliste fu¨r Gutachter
Im Folgenden wird der Workflow des Bidding Features an einem kleinen Bei-
spiel erla¨utert. Abbildung 4.10 zeigt die Liste, mittels derer die Gutachter fu¨r
die einzelnen Artikel stimmen ko¨nnen. Die Wahl aller Gutachter wird in der
Bidding-Matrix (siehe Abbildung 4.11) angezeigt. Die mit B gekennzeichneten
Zellen der Matrix stellen die von den Gutachtern bevorzugten Artikel dar. Das
Addieren der Gutachtenwu¨nsche ergibt einerseits die Anzahl der Gutachten
pro Artikel, andererseits die zu schreibenden Gutachten pro Gutachter, was
deren Arbeitsauslastung entspricht. Abbildung 4.11 stellt die auf die Wu¨nsche
der Gutachter ausgerichtete momentane geplante Verteilungssituation dar. Die
entsprechenden Checkboxen der Favoriten sind selektiert. Das betrachtete Bei-
spiel setzt drei Gutachter pro Artikel voraus (siehe letzte Spalte (3)). Die Spal-
te Sum zeigt die momentane Anzahl pro Artikel an, wobei die Arbeitsauslastung
in der letzten Spalte zu sehen ist.
KAPITEL 4. REALISIERTE KONZEPTE 87
Abbildung 4.11: Bidding-Matrix - Anzeige der Benutzerwahl
Anders als in diesem vereinfachten Beispiel sind die Randbedingungen in der
Praxis erheblich komplexer. In den bereits erwa¨hnten Konferenzen TACAS
und ADMA weist die Bidding-Matrix 3799 bzw. 39508 Zellen auf, was ohne
einen Automatismus nicht mehr zu handhaben ist.
Zur Berechnung einer optimalen Lo¨sung fu¨r die Verteilung von Artikeln an
Gutachter bietet sich die lineare Optimierung an. Sie wird fu¨r die Bestimmung
des Maximums bzw. Minimums einer linearen Funktion verwendet. Hierzu ist
die Zielfunktion und die dazugeho¨rigen Restriktionen zu erstellen, was letzt-
endlich Eingaben fu¨r das Programm zur Bestimmung der Lo¨sung sind. Im OCS
ist die Zielfunktion wie folgt definiert:
Artikel
∑
i
Gutachter
∑
j
Ki , j Xi , j = MIN (4.1)
Der Koeffizient Ki , j wird bestimmt durch die im Dienst spezifizierten Kon-
flikte zwischen Gutachtern und Artikeln, der Arbeitsauslastung des Gutachters
und der Artikelauswahl des Gutachters. Die zu bestimmenden Variablen Xi , j
spezifizieren die Zuordnung eines Begutachtungsauftrages zwischen einem Ar-
tikel und einem Gutachter.
Die Restriktionen werden durch unterschiedliche Gleichungen, Ungleichungen
definiert. Gewollte bzw. ungewollte Delegierungen zwischen Artikeln und Gut-
achtern werden durch die Gleichungen 4.2 festgelegt.
XArtikel , Gutachter = 1 (Gesetzte Zuweisung)
XArtikel , Gutachter = 0 (V erbotene Zuweisung)
(4.2)
Fu¨r zu bestimmende Delegierungen wird der Wertebereich der Variablen ange-
geben. Die vorgegebenen Werte der Variablen sind 0 und 1 und werden mittels
KAPITEL 4. REALISIERTE KONZEPTE 88
der Formeln 4.3 definiert.
XArtikel , Gutachter ≥ 0
XArtikel , Gutachter ≤ 1
(4.3)
Die in der Gleichung 4.4 definierte Restriktion dient zur Festlegung der genauen
Anzahl der Gutachter fu¨r einen Artikel und dadurch zu einer vorgegebenen
Anzahl von Gutachten pro Artikel.
Gutachter
∑
j
XArtikelj = Gutachten pro Artikel (4.4)
Der letzte Restriktionstyp beru¨cksichtigt die Arbeitsauslastung jedes einzelnen
Gutachters. Da eine Reihe von Konstellationen auftreten ko¨nnen, zu denen
keine Lo¨sung berechnet werden kann, wird eine Benutzereingabe einer Abwei-
chung von der gewu¨nschten Anzahl von Artikeln pro Gutachter zugelassen.
Aufgrund dieser Abweichung sind die Ungleichungen 4.5 definiert zu:
Artikel
∑
i
XGutachteri ≥ untere Arbeitslast
Artikel
∑
i
XGutachteri ≤ obere Arbeitslast
(4.5)
Soll auf Basis der in Abbildung 4.11 dargestellten Begutachtungswu¨nsche der
Gutachter eine gerechte und ada¨quate Verteilung automatisch berechnet wer-
den, ist im ersten Schritt mittels der erla¨uterten Gleichungen die Eingabedatei
fu¨r den lp solve zu generieren (siehe Abbildung 4.12).
Hierzu werden alle Eintra¨ge aus der Biddingmatrix beru¨cksichtig. Es wird z.B.
das Bidding von Gutachter G1 fu¨r Artikel 001 mit der Gleichung X 001 1 = 1
festgelegt und der Konflikt zwischen G3 und 001 geht als Bedingung mit
X 001 3 = 0 in die Optimierung ein. Durch die U¨bernahmen der in der
Biddingmatrix spezifizierten Randbedingungen ist es mo¨glich, eine zusa¨tzli-
che Verteilung durchzufu¨hren. Das inkrementelle Anpassen einer berechneten
Verteilung ist in der Praxis von gro¨ßter Bedeutung, da sonst der komplette
Verteilungsprozess zuru¨ckgenommen werden mu¨sste. Dieses wa¨re fu¨r die Wis-
senschaftsgemeinde, insbesondere die Gutachter, nicht akzeptabel. ≥ und ≤
KAPITEL 4. REALISIERTE KONZEPTE 89
min: 11 X_001_1 + 20 X_001_2 + 10 X_001_4 + 20 X_002_1 + 20 X_002_2 + 30 X_002_3 +
20 X_002_4 + 30 X_003_1 + 30 X_003_2 + 21 X_003_3 + 10 X_003_4 + 11 X_004_2 +
21 X_004_3 + 10 X_004_4;
X_001_1 = 1;
X_001_2 > 0; X_001_2 < 1;
X_001_3 = 0;
X_001_4 > 0; X_001_4 < 1;
X_002_1 > 0; X_002_1 < 1;
X_002_2 > 0; X_002_2 < 1;
X_002_3 > 0; X_002_3 < 1;
X_002_4 > 0; X_002_4 < 1;
X_003_1 > 0; X_003_1 < 1;
X_003_2 > 0; X_003_2 < 1;
X_003_3 = 1;
X_003_4 > 0; X_003_4 < 1;
X_004_1 = 0;
X_004_2 = 1;
X_004_3 = 1;
X_004_4 > 0; X_004_4 < 1;
X_001_1 + X_001_2 + X_001_3 + X_001_4 = 3;
X_002_1 + X_002_2 + X_002_3 + X_002_4 = 3;
X_003_1 + X_003_2 + X_003_3 + X_003_4 = 3;
X_004_1 + X_004_2 + X_004_3 + X_004_4 = 3;
X_001_1 + X_002_1 + X_003_1 + X_004_1 > 3;
X_001_1 + X_002_1 + X_003_1 + X_004_1 < 3;
X_001_2 + X_002_2 + X_003_2 + X_004_2 > 3;
X_001_2 + X_002_2 + X_003_2 + X_004_2 < 3;
X_001_3 + X_002_3 + X_003_3 + X_004_3 > 3;
X_001_3 + X_002_3 + X_003_3 + X_004_3 < 3;
X_001_4 + X_002_4 + X_003_4 + X_004_4 > 3;
X_001_4 + X_002_4 + X_003_4 + X_004_4 < 3;
int X_001_1, X_001_2, X_001_3, X_001_4, X_002_1, X_002_2,
X_002_3, X_002_4, X_003_1, X_003_2, X_003_3, X_003_4, X_004_1, X_004_2, X_004_3, X_004_4;
Abbildung 4.12: Solver-Input - Zielfunktion, Restriktionen, Variablendeklara-
tion
entsprechen in der lp solve Syntax > und <. In der ersten Zeile der Datei wird
die Zielfunktion definiert, gefolgt von den Restriktionen mit denen das Mini-
mum (min:) zu berechnen ist. Die letzte Zeile definiert den Typ der einzelnen
Variablen, hier Integer.
Im na¨chsten Schritt wird dem Solver die Eingabedatei u¨bergeben. Der Solver
wird als Thread gestartet und blockiert den eigentlichen Workflow nicht. Das
Ergebnis der Optimierung wird in ein vorgegebenes Format als eine Datei
gespeichert, siehe Abbildung 4.13.
Die Datei entha¨lt die Variablen der Zielfunktion mit den entsprechenden be-
rechneten Werten, die durch Restriktionen auf 0 oder 1 festgelegt wurden. Eine
1 bedeutet eine Delegierung. Das Ergebnis wird in Abbildung 4.14 dargestellt.
Es ist ersichtlich, dass eine ausgeglichene Verteilung erzielt wurde. Jeder Ar-
tikel ist laut Vorgabe an drei Gutachter verteilt worden und die Arbeitsaus-
KAPITEL 4. REALISIERTE KONZEPTE 90
X_001_1 1
X_001_2 1
X_001_3 0
X_001_4 1
X_002_1 1
X_002_2 1
X_002_3 1
X_002_4 0
X_003_1 1
X_003_2 0
X_003_3 1
X_003_4 1
X_004_1 0
X_004_2 1
X_004_3 1
X_004_4 1
Abbildung 4.13: Solver-Output - Lo¨sung der Zielfunktion
Abbildung 4.14: Bidding-Matrix - Lo¨sungsvorschlag des lp-solve
lastung unter den Gutachtern ist identisch. Konflikte wurden wa¨hrend der
Berechnung beachtet und die Biddings in ihrer Gewichtung eingeplant. So
wurden B vor I und I vor U beru¨cksichtigt. Die Konstellation von der Anzahl
der Artikel und Gutachter zur Anzahl der Zuweisungen von drei Gutachtern
pro Artikel war in diesem Beispiel trotz zweier Konflikte lo¨sbar.
Abbildung 4.15 hingegen zeigt eine durch das Einfu¨gen des Konfliktes zwischen
Artikel 001 und Gutachter G4 vera¨nderte Konstellation. Unter denselben An-
nahmen, dass jeder Artikel von drei Gutachtern beurteilt wird, findet lp solve
keine Lo¨sung fu¨r dieses Problem. In diesem Fall kommt die Abweichung zum
Tragen, indem einen prozentuale Abweichung u¨ber die GUI der Konferenz an-
gegeben wird, die sich in den Restriktionen 4.5 auswirken. Die untere und
obere Auslastung wird entsprechend der Abweichung nach unten bzw. oben
korrigiert. Fu¨r das betrachtete Beispiel wird eine Lo¨sung bei einer 35%-igen
Abweichung erreicht.
Die berechneten Verteilungsvorschla¨ge ko¨nnen manuell angepasst und zwi-
KAPITEL 4. REALISIERTE KONZEPTE 91
Abbildung 4.15: Bidding-Matrix - Lo¨sungsvorschlag mit 35%-iger Abweichung
schengespeichert werden. Das Feature ermo¨glicht eine inkrementelle Anpas-
sung der Planung und den wiederholenden Einsatz der Verteilungsberechnung
auf Basis der vera¨nderten Randbedingungen. Sobald die Verteilung feststeht,
kann die Zuweisung automatisiert durchgefu¨hrt werden. Jeder Gutachter wird
per Email u¨ber die neuen Begutachtungsaufgaben informiert und die einzel-
nen Zuweisungen als eine neue Aufgabe in der Arbeitsliste (tasklist) des ent-
sprechenden Gutachters hinterlegt. Bereits existierende Delegierungen werden
ebenfalls in der Bestimmung einer optimalen Verteilung beru¨cksichtigt, sodass
auch in der Begutachtungsphase mittels des Bidding Features zusa¨tzliche Ver-
teilungen erfolgen ko¨nnen.
Der in [Tay08] vorgestellte Ansatz fu¨hrt die Verteilung von Begutachtungs-
aufgaben ebenfalls auf ein lineares Optimierungsproblem zuru¨ck, allerdings
beru¨cksichtigt die beschriebene Vorgehensweise keine Begutachtungsvorschla¨ge
(biddings) von den eigentlichen Gutachtern. Die Konferenzleiter schlagen un-
ter Angabe von Gewichtungen Zuweisungen zwischen Artikeln und Gutach-
tern vor. Dieses verursacht eine zusa¨tzliche Belastung der Konferenzleitung
und entspricht nicht dem eigenen Ansatz, der die Konferenzleitung wa¨hrend
der Verteilung der Begutachtungsaufgaben entlastet und die Gutachter in die
Bestimmung einer optimalen Verteilung integriert. Werden komplexere Konfe-
renzen mit einer großen Anzahl von Artikeln und Gutachtern betrachtet fu¨hrt
der Ansatz aus [Tay08] bei einer kleinen Konferenzleitung zu einem immensen
Aufwand. Des Weiteren stellt die berechnete Verteilung mathematisch zwar
eine optimale Lo¨sung dar, allerdings stoßen Zwangszuweisungen von Begut-
achtungsaufgaben aus eigener Erfahrung oftmals auf Ablehnung, was im Um-
kehrschlußss zu einer erneuten Verteilung fu¨hren kann.
KAPITEL 4. REALISIERTE KONZEPTE 92
4.4 Konfigurierbarer Bewertungsworkflow
Gutachten dienen innerhalb von Konferenzen zur Beurteilung und Diskussion
von Artikeln. Die Gutachten werden auf der Basis definierter Beurteilungs-
formulare durchgefu¨hrt, die einem fu¨r die Konferenz vorgeschriebenen Muster
entsprechen. Die wiederkehrende Anforderung der Anpassungen der Begutach-
tungsformulare legte den Grundstein fu¨r das Design und die Umsetzung eines
in seiner Konfiguration flexiblen Begutachtungssystems, dessen Formulare in
Hinsicht auf die Elemente und Formeln zur Berechnung von Benotungen frei
konfigurierbar sind. Elemente wie zum Beispiel check boxes oder radio buttons
ko¨nnen mit Werten hinterlegt und in die Formel zur Berechnung einer Note
einbezogen werden.
Die Abbildung 4.16 zeigt die Konfigurationsseite zur Erstellung bzw. Modifi-
kation von Begutachtungsformularen (report forms).
Abbildung 4.16: Reportformular - Konfiguration des Formulars
Das Formular besteht aus den Basiselementen Formularname, einer Beschrei-
bung des Formulars, der Benotung (score) und der Selbsteinscha¨tzung des Be-
gutachters (confidence). Die Selbsteinscha¨tzung bezieht sich auf die fachliche
Kompetenz des Gutachters im Bezug auf das Thema des zu begutachtenden
Artikels. Wa¨hrend der Bestimmung der Gesamtnote eines Artikels, die in der
Regel von drei Gutachten abha¨ngig ist, gehen die einzelnen Benotungen der
Gutachter gewichtet nach ihrer Fachkompetenz ein.
KAPITEL 4. REALISIERTE KONZEPTE 93
Zur Erstellung eines Begutachtungsformulars stehen verschiedene Formular-
elemente zur Verfu¨gung:
• Text: Beliebige Informationen ko¨nnen in textlicher Form im Formular
platziert werden.
• Text Area: Der Dienstbenutzer kann einen la¨ngeren Text eingeben,
wobei die La¨nge des Textes definiert werden kann.
• Radio Buttons: Aus einer Menge von z.B. vorformulierte Antworten
kann eine ausgewa¨hlt werden.
• Check Boxes: Mehrere Selektierungen sind mo¨glich, wodurch z.B. ein
Gutachter eine Frage mit mehreren Auswahlmo¨glichkeiten beantworten
kann.
• Select Element: Ermo¨glicht eine Auswahl eines Elements aus einer
Liste.
• File Element: Dieses Element ha¨ngt eine Datei an das Begutachtungs-
formular an. Der Typ des Files und dessen Gro¨ße sind definierbar.
Durch Kombination der obigen Elemente wird das Formular erstellt. Das For-
mular kann sich u¨ber mehrere Seiten erstrecken und die einzelnen Elemente
beliebig oft in einem Formular verwendet werden. Die Elemente selbst sind
fu¨r ihre jeweilige Anwendung konfigurierbar. Sie ko¨nnen als required markiert
werden, um die Verwendung des Elementes durch den Gutachter verpflichtend
zu machen. Dieses ko¨nnte eine Antwort auf eine Qualita¨tsfrage des Artikels
oder die Eingabe der schriftlichen Beurteilung des Artikels in einem Text-
feld sein. Eine Einreichung des ausgefu¨llten Formulars wird nur zugelassen,
sobald alle verpflichtenden Elemente bearbeitet wurden. Die Annotation con-
fidential kennzeichnet ein Element als vertraulich und ist in Bezug auf das
Rollen/Rechte-Management nur fu¨r Benutzer verfu¨gbar, deren Benutzerrollen
dieses Feature beinhalten.
In Abbildung 4.17 wird das Element Radio Buttons gezeigt, das in der momen-
tanen Verwendung fu¨r die Erstellung des Score-Abschnittes in dem Begutach-
tungsformular zum Einsatz kommt. Das Label ist der Name, unter dem das de-
finierte Element im Begutachtungsformular erscheint. Die Instruction gibt dem
Benutzer, der das Formular ausfu¨llt, Hinweise und Anweisungen. Die Anzahl,
Benennung und Wertzuweisung kann frei gewa¨hlt werden. Eine Vorselektion
eines Eintrages sowie die Ausrichtung des Textes kann konfiguriert werden.
KAPITEL 4. REALISIERTE KONZEPTE 94
Abbildung 4.17: Reportformular - Radio Buttons Element
Ein wichtiger Aspekt ist die eindeutige interne Benennung des Elementes (Na-
me). Die Werte der Elemente sind in der konfigurierbaren Berechnungsformel
fu¨r den Score bzw. Confidence verwendbar. Durch diese Vorgehenweise ist es
mo¨glich, die Benotung des Artikels von mehreren Elementen eines Formulars
abha¨ngig zu machen.
Eine HTML-Repra¨sentation eines Begutachtungsformulars zeigt Abbildung 4.18
auf. Dieses Standardformular besteht aus jeweils zwei Radio Buttons und Text
Area Elementen. Die Markierung * hebt die Pflichtelemente hervor, die vom
Gutachter bearbeitet werden mu¨ssen. Das Element Comments for PC Eyes
only ist ein vertrauliches Feld, dessen Inhalt nur ausgewa¨hlten Rollen der Kon-
ferenz angezeigt wird. In diesem Fall dient es fu¨r zusa¨tzliche Bewertungen, die
fu¨r andere Gutachter, aber auf keinen Fall fu¨r die Autoren bestimmt sind.
Im Falle des OCS existieren zwei Typen von Begutachtungsformularen, die je-
KAPITEL 4. REALISIERTE KONZEPTE 95
weils neu oder auf Basis von vordefinierten Formularen erstellt werden ko¨nnen:
• Single Report: Die vom PC Member verfasste Beurteilung.
• Final Report: Die abschliessende Beurteilung auf Basis der Single Re-
ports und des PC-Meetings bzw. der Forendiskussion.
Abbildung 4.18: Reportformular - Gerendertes Formular
Von beiden lassen sich beliebig viele Reportformulare realisieren. Die Bezie-
hung der Formulare zu den Artikeln wird durch die Assoziation zwischen dem
KAPITEL 4. REALISIERTE KONZEPTE 96
Reportformular und einer oder mehrerer Artikelkategorien hergestellt. Auf-
grund der Einteilungen der Artikel kann zu jeder Gruppe von Artikeln ein
eigenes Begutachtungsformular definiert und verwendet werden, siehe Abbil-
dung 4.19.
Abbildung 4.19: Reportform - Kategorienzuweisung
Jeder Kategorie wurde ein eigenes Single Report-Formular zugeteilt, wobei ein
gemeinsames Formular fu¨r den Final Report verwendet wird.
Die Realisierung der Begutachtungsformulare basiert auf XML 5. XML ist ei-
ne Auszeichnungssprache zur strukturierten Beschreibung von Daten in einer
lesbaren Form, z.B. als ASCII 6. Das W3C 7 [Con09] gab 1998 eine XML-
Spezifikation heraus, die XML standardisierte. XML-Dateien lassen sich mit-
tels einer DTD 8 oder einer XSD 9 auf ihre Wohlgeformtheit validieren. Die
Definitionen spezifizieren die Struktur und die erlaubten Elemente fu¨r eine
XML-Datei. Fu¨r dieses Feature wurde das XML Schema verwendet, da es un-
ter anderem im Gegensatz zur DTD mehr und komplexere Datentypen bietet.
Fu¨r die Bearbeitung der XML-Dateien wird das Framework JAXB-2.x 10 ein-
gesetzt [mic09h] [mic09i]. Dieses ermo¨glicht einerseits XML-Dokumente als
Java-Objekte abzubilden (unmarshal) und andererseits Java-Objekte wieder-
um in XML zu u¨berfu¨hren (marshal). Abbildung 4.20 (aus [mic09i]) zeigt die
Arbeitsweise von JAXB.
5Extensible Markup Language
6American Standard Code for Information Interchange
7World Wide Web Consortium
8Document Type Definition
9XML Schema Definition
10Java Architecture for XML Binding
KAPITEL 4. REALISIERTE KONZEPTE 97
Abbildung 4.20: JAXB - Funktionsweise
Als vorbereitender Schritt werden mit Hilfe des Binding Compilers (xjc) aus
dem XML Schema die Java-Klassen (.java) generiert. Diese Klassen stellen die
Java-Repra¨sentation des XML Schemas dar. Die Klassen mu¨ssen anschließend
kompiliert werden (javac), um fu¨r das JAXB-Framework zur Laufzeit der Ap-
plikation zur Verfu¨gung zu stehen. XML-Dokumente die in Bezug auf das Sche-
ma wohlgeformt sind, ko¨nnen mittels dem JAXB Binding Framework durch
Instanzen der zuvor generierten Java-Repra¨sentationen des XML Schemas ab-
gebildet werden. Modifikationen ko¨nnen nun an der Java-Repra¨sentation des
XML-Dokuments durchgefu¨hrt werden. Basierend auf den Java-Repra¨senta-
tionen lassen sich mit JAXB die entsprechenden XML-Dokumente erzeugen.
Im OCS werden die Gutachten als XML-Dokumente in der Datenbank persi-
stent gehalten. Ist ein Gutachten zu manipulieren, wird dieses aus der Daten-
bank gelesen und mittels JAXB zu Java-Objekten transformiert. Um das Gut-
achten zu editieren, wird mit einem XSLT 11-Stylesheet das XML-Dokument
nach HTML u¨bersetzt. Die auf der GUI-Ebene durchgefu¨hrten A¨nderungen
werden an die Java-Repra¨sentation weitergeleitet. Die Java-Objekte werden
zur Speicherung mittels JAXB nach XML transformiert und in der Datenbank
gespeichert.
11 Extensible Stylesheet Language Transformation
Teil III
Das Entscheidungssystem OCS
99
Kapitel 5
Workflows und Features
Dieses Kapitel dient zur detaillierteren Vorstellung der Workflows und Featu-
res des betrachteten Referenzsystems OCS. Fu¨r bzw. durch den OCS sind unter
anderem die eingefu¨hrten Konzepte (siehe Kapitel 4) entstanden und finden in
der Praxis ihren Einsatz. Der Online Conference Service ist ein Web-basiertes
Entscheidungssystem fu¨r die Begutachtung von wissenschaftlichen Artikeln,
das die an einer Konferenz beteiligten Personen in jeder Phase einer Kon-
ferenz in ihrer gemeinschaftlichen Arbeit unterstu¨tzt und sich wiederholende
Gescha¨ftsprozesse automatisiert. Die fu¨r eine Begutachtung im Rahmen einer
Konferenz verantwortlichen Personen werden unter dem Begriff Programm-
komitee zusammengefasst. Die Komiteemitglieder stellen Benutzer des OCS’s
dar, die im OCS unterschiedliche Rollen bekleiden ko¨nnen. Diese sind fu¨r das
Komitee insbesondere die Rollen PC Chair und PC Member. Wobei die Rolle
PC Chair die Konferenzleiter und die PC Member Rolle die Gutachter der
Konferenz repra¨sentieren. Ferner existieren weitere vordefinierte Rollen wie
Author, CoAuthor, SubReviewer und Administrator (siehe Tabelle 1.1). De-
ren Aufgabenbereiche werden im Laufe des Kapitels am Gescha¨ftsprozess des
OCS na¨her erla¨utert.
Einem Dienstbenutzer ko¨nnen mehrere Rollen zugeordnet sein. Diese verleihen
ihm in Abha¨ngigkeit der jeweiligen aktiven Rolle eine personalisierte Sicht auf
den OCS, dessen Funktionalita¨ten und der zu bearbeitenden Objekte, wie z.B.
einen Artikel. Die Konfiguration und Zuordnung der Rollen sowie die direkte
Rechtevergabe auf Ressourcen kann mittels des Rollen/Rechtesystems feingra-
nular eingestellt und wa¨hrend der laufenden Konferenz manipuliert werden
(siehe Kapitel 4.2).
101
KAPITEL 5. WORKFLOWS UND FEATURES 102
5.1 Konferenzphasen
Das in Abbildung 5.1 dargestellte Kontrollflussdiagramm gibt einen verein-
fachten U¨berblick der im OCS existierenden Konferenzphasen.
Call For Papers
Proceeding Preparation
Conference Installation Conference Setup User Registration
Article Submission
Abstract Submissionfull paper?
Bidding Distribution Computation
Paper Distribution Reviewing
SubDistribution
yes
no
bidding?
forward?
yes
no
SubReviewing
Discussion
no
yes
delegations?
Notification to Authors
Final Article Submission
revised?
no
no
yes
yes
Abbildung 5.1: OCS - Kontrollflussdiagramm der Konferenzphasen
KAPITEL 5. WORKFLOWS UND FEATURES 103
Eine Konferenz beginnt neben der Organisation von Tagungsra¨umen und der
Zusammenstellung der zu buchenden Hotels mit dem Call For Paper (CFP).
Dieses ist der Aufruf an Personen, ihre Forschungsergebnisse in Form eines Ar-
tikels zur Konferenz einzureichen. Angesprochen werden in der Regel Forscher
aus dem akademischen und industriellen Bereich. Nach dem fru¨hzeitigen Ver-
senden bzw. Aushang des CFP durch die Konferenzorganisatoren, in dem alle
relevanten Konferenzinformationen insbesondere die Internetadresse des ver-
wendeten Begutachtungssystems bekannt gegeben wird, beginnt die Installa-
tion und Einrichtung des Begutachtungssystems. Die Installation des Systems
erfolgt in der Regel drei bis vier Wochen vor Beginn der Einreichungsphase
und wird von dem jeweiligen Anbieter vorgenommen. Dies ist im Falle des
OCS, der fu¨r die LNCS-Reihe zur Verfu¨gung gestellt wird, der Springer Verlag
Heidelberg.
Die Konfiguration der Konferenz wird in der Phase Conference Setup vom
PC Chair mit Hilfe des Setup-Features durchgefu¨hrt. Der Dienst wird in Bezug
auf sein Verhalten und Aussehen auf die zu unterstu¨tzende Konferenz ange-
passt. Zeitfristen (deadlines), Rollen, Reportformulare und artikelspezifische
Seiten ko¨nnen konfiguriert werden. Des Weiteren wird eine minimale Regi-
strierung des Komitees durchgefu¨hrt, dessen Mitgleider die ihre Registrierung
zum Dienst vervollsta¨ndigen und besta¨tigen mu¨ssen. Die geta¨tigten Konfigu-
rationen sind u¨ber die Conference Setup Phase hinaus manipulierbar.
Wa¨hrend der User Registration Phase wird das Registrieren der PC Mem-
bers durch den PC Chair und die Selbstregistrierung der Authors zusammen-
gefasst. Eine selbsta¨ndige Registrierung ist im OCS mit der Zuweisung der
Rolle Author verbunden. Diese Rolle beinhaltet eine eingeschra¨nkte Sicht auf
die Dienstfunktionalita¨ten. Alle anderen Rollen mu¨ssen vom PC Chair explizit
an Benutzer vergeben werden.
In der Phase Abstract Submission und Article Submission ist es den regi-
strierten und authentisierten Autoren erlaubt, ihre Beitra¨ge einzureichen. Bei-
de Phasen werden durch das Article-Feature abgedeckt. Die Einreichung kann
entweder direkt in Form des vollsta¨ndigen Artikels oder durch eine kurze Arti-
kelzusammenfassung (abstract) geschehen. Die Abstract Submission zieht die
Article Submission nach sich und dient den Konferenzleitern zur Einscha¨tzung
des Konferenzumfanges und zur ersten Planung der Begutachtungsverteilung.
Die Abstract Submission Phase ist u¨ber das Setup der Konferenz ein bzw. aus-
schaltbar, indem das entsprechende Dienst-Feature fu¨r die Rolle Author ak-
tiviert bzw. deaktiviert wird. Durch die Aktivierung oder Deaktivierung von
Features unter Verwendung des bereits ero¨rterten Rollen/Rechtesystems la¨sst
sich der Kontrollfluss zur Laufzeit vera¨ndern, wobei die Features zu Beginn
KAPITEL 5. WORKFLOWS UND FEATURES 104
der Konferenz existieren und wa¨hrend der Konferenz statisch sind.
Die Bidding und Distribution Computation Phasen dienen zur Planung
und Festlegung der Artikelverteilungen an die Gutachter und sind optionale
Features, die mittels des Setup-Features dem Workflow hinzugeschaltet werden
ko¨nnen. Die Gutachter stimmen fu¨r die Artikel, die sie begutachten wollen und
geben Desinteresse oder Konflikte an. Die Paper Distribution Phase weist
den Gutachtern die Begutachtungsaufgaben zu. Die drei Phasen werden vom
Bidding-Feature realisiert (siehe Kapitel 4.3).
Sobald die Artikel zugewiesen sind, beginnt die Reviewing Phase, die die Be-
gutachtung der Artikel darstellt. Gutachter verfassen ihre Gutachten entweder
alleine oder sie bauen ihr Gutachten auf Gutachten von SubReviewern auf.
Die Weiterleitung ist optional und beinhaltet die Phasen SubDistribution
und SubReviewing. Die Entscheidung u¨ber die Annahme oder Ablehnung
eines Artikels findet in der Discussion Phase statt, die aus dem Forum und
Evaluation Feature besteht. Diese kann entweder mittels der Artikelforen oder
physikalisch stattfinden. Beim PC-Treffen wird die Diskussion durch die Eva-
luationMatrix unterstu¨tzt. Die einzelnen Ergebnisse werden durch Statusa¨nde-
rungen der Artikel im Dienst eingepflegt und die jeweilige Entscheidung in der
Matrix graphisch hervorgehoben.
Fu¨r Artikel, die sich im Zustand angenommen oder abgelehnt befinden, startet
die Notification to Author Phase. Konferenzleiter schreiben ein Gutachen,
das das Gesamtergebnis der Begutachtung beinhaltet. In der Regel findet dieser
Prozess fu¨r die akzeptierten und abgelehnten Artikel jeweils gleichzeitig statt.
Autoren, deren Artikel angenommen wurden, reichen ihre u¨berarbeitete Ar-
tikelversion ein, die bei Erfu¨llung der Gutachterauflagen zur Vero¨ffentlichung
zugelassen wird.
In der Proceeding Preparation Phase wird der Tagungsband erstellt und
an dem Verlag zum Druck weitergeleitet. Hier kommt das Proceeding-Feature
zum Tragen, das den PPS [Hol06] widerspiegelt (siehe Kapitel 7.3).
5.2 Lebenszyklus eines Artikelobjektes
Im Folgenden wird detaillierter auf das Artikelobjekt, das die zentrale Rol-
le im Begutachtungsprozess einnimmt, eingegangen. Die Zugriffe auf die ge-
meinschaftlich zu bearbeitenden Objekte, wie z.B. die Artikel, sind zustand-
sabha¨ngig. D.h. der Zustand eines Artikels a¨ndert sich zur Laufzeit der Kon-
ferenz dynamisch, in Abha¨ngigkeit von auftretenden Ereignissen (events), die
wa¨hrend der im Kapitel 5.1 beschriebenen Konferenzphasen stattfinden. Der
KAPITEL 5. WORKFLOWS UND FEATURES 105
Lebenszyklus des Artikelobjektes in Form von Zusta¨nden und deren U¨berga¨ngen
(translations) ist in Abbildung 5.2 dargestellt.
created
delegated
under review
modified
submitted
full paper submitted
abstract
abstract submitted
full paper
submitted
some reports available
paper distributed
proposed accepted
discussion
proposed rejected
accepted
task accepted
report submitted
all reports submitted
rejected
paper distributed
paper distributed
paper distributed
paper
distributed
modified
task rejected and
delegations = 0
task rejected and
delegations > 0
discussion opened
proposed rejected
proposed rejected
proposed accepted
proposed accepted
discussion discussion
proposed accepted
proposed rejected
proposed
rejected acceptedproposed accepted
rejected
final report available
final report
submitted
final report
submitted
rejected
modified
final version submitted
revised version
final version
submitted
report submitted
rejected
rejected
rejected
all reports available
discussion
opened
Abbildung 5.2: Artikelzusta¨nde im Begutachtungsprozess
KAPITEL 5. WORKFLOWS UND FEATURES 106
Die einzelnen Zusta¨nde sind in dem Zustandsdiagramm mit einem Rechteck
dargestellt, wobei die Zustandsu¨berga¨nge von einem Zustand in den na¨chsten
durch einen Pfeil repra¨sentiert werden, der durch das auslo¨sende Ereignis des
U¨berganges annotiert ist. Die Ereignisse sind Aktionen von Dienstbenutzern,
die mittels Dienstfunktionalita¨ten durchgefu¨hrt werden. Die dynamisch wech-
selnden Zusta¨nde bestimmen die erlaubten Aktionen auf einen Artikel. Jedem
Zustand werden mittels einer Propertydatei Features zugeordnet (siehe Kapi-
tel 4.2.2). Der Zugriffskontrollmechanismus des OCS vergleicht dieses Feature
mit den beno¨tigten Features fu¨r eine Aktion, d.h. fu¨r die Verwendung einer
Dienstkomponente, um z.B. den Artikel zu manipulieren, mit den erlaubten
Features des Dienstbenutzers.
Sobald ein Autor mit der Einreichung seines Artikels beginnt, wird ein Artikel-
objekt instanziiert, das den Zustand created aufweist. Wird die Einreichung
vom Autor abgeschlossen, ist der Zustand des Artikels entweder abstract oder
submitted. Dieses ist abha¨ngig davon, ob es sich bei der Einreichung nur um
eine Anku¨ndigung oder einen vollsta¨ndigen Artikel handelt.
Die Verteilung eines Artikels zur Begutachtung fu¨hrt in den Zustand delega-
ted, dieser beinhaltet die Features fu¨r das Schreiben von Gutachten. Aktionen
durch den PC Member bestimmen die U¨berga¨nge von delegated zu under
review, anschliessend zu some reports available und all reports availa-
ble. Die Zusta¨nde zeigen die Akzeptanz des Gutachtenauftrages, die teilweise
und schlussendlich die komplette Einreichung aller Reports auf und geben un-
terschiedliche Aktionen frei. Ab some reports available ist es bereits fu¨r
den PC Chair mo¨glich, den Artikelzustand auf discussion zu setzen, sodass
die Gutachter mit den bislang eingereichten Gutachten die Diskussion begin-
nen ko¨nnen. Gutachter mit einem ausstehenden Gutachten hingegen erlangen
erst Zugriff auf das Artikelforum, wenn sie ebenfalls ihr Gutachten eingereicht
haben. Dadurch wird eine eventuelle Beeinflussung durch das Lesen der sich
bereits im Dienst befindenden Gutachten vermieden.
Vom all reports available ausgehend ist der PC Chair in der Lage, den Zu-
stand auf discussion, proposed accepted oder proposed rejeced zu set-
zen. Die Zusta¨nde accepted und rejected bilden das jeweilige Endergebnis
der Diskussion. Wa¨hrend der Diskussionphase kann der PC Chair zwischen den
Zusta¨nden discussion, proposed accepted, proposed rejected, accepted
oder rejected wechseln. Dadurch wird direkt die momentane Diskussionssi-
tuation in der EvaluationMatrix fu¨r das Programmkomitee visualisiert.
Nach Einreichung des final reports durch den PC Chair nimmt der Artikel den
Zustand final report available an. Abschließend wird der Zustand auf final
version submitted gesetzt, nachdem der Autor seine u¨berarbeitete Artikel-
KAPITEL 5. WORKFLOWS UND FEATURES 107
version hochgeladen hat. Das erneute Einreichen einer verbesserten Version
vera¨ndert nicht den Artikelstatus.
Die Beschreibung hat die Zustandsu¨berga¨nge fokussiert auf einen Begutach-
tungsdurchgang eines Artikels aufgezeigt. Im Lebenszyklus eines Artikels tre-
ten auch Ereignisse auf, die zu keiner Vera¨nderung des Zustands oder zu einer
Ru¨cksetzung in einen fru¨heren Zustand fu¨hren (siehe Abbildung 5.2).
5.3 OCS Features
Die Gescha¨ftsprozesse des OCS sind graphbasiert (siehe Kapitel 3.1.1) mo-
delliert. Die Funktionalita¨ten der Gescha¨ftslogik, die fu¨r ein bestimmtes Ob-
jekt realisiert wurden, sind zu einem Hauptfeature (siehe Kapitel 4.1) grup-
piert. Features repra¨sentieren die Kategorien der Dienstfunktionalita¨ten, die
fu¨r einen Benutzer zur Laufzeit u¨ber eine Navigationsleiste verfu¨gbar sind (sie-
he Abbildung 4.1). Im Folgenden werden die wichtigsten Hauptfeatures und
deren Funktionalita¨ten kurz vorgestellt.
Article
Der Begutachtungsprozess eines Konferenzbeitrages beginnt mit der Einrei-
chung eines Artikel und endet mit dem Hochladen der finalen Artikelversion.
Das Artikel-Feature stellt eine Reihe von Gescha¨ftsprozessen und deren Kom-
ponenten zur Bearbeitung und Verwaltung der Artikel zur Verfu¨gung. Die
Einreichung umfasst die Teilprozesse (SubFeatures) Abstract Submission, Mo-
dify Abstract, Article Submission, Modify Article, Submit Article, Submit Final
Version und Modify Final Version. Artikel ko¨nnen heruntergeladen, gelesen,
modifiziert, gespeichert, gesichert, wieder eingespielt und gelo¨scht werden. Die
Teilprozesse lassen sich feingranular Rollen zuordnen. So ist z.B. das Lesen
von Artikeln mit einem zusa¨tzlichen Filter versehen, der ermo¨glicht, zwischen
eigenen, delegierten und involvierten Artikeln zu differenzieren. Des Weiteren
verwaltet es die Artikelzusta¨nde und ist zusta¨ndig fu¨r die Zustandsa¨nderungen
und ihre Plausibilita¨tspru¨fung.
Bidding
Das Bidding-Feature unterstu¨tzt die Konferenzleiter bei der Verteilung von
Begutachtungsaufgaben. Es ko¨nnen einerseits Gutachterwu¨nsche in Form ei-
ner Artikelwahl beru¨cksichtigt, andererseits unter Verwendung des externen
KAPITEL 5. WORKFLOWS UND FEATURES 108
Programms lp solve eine Verteilung berechnet werden. Die detaillierte Be-
schreibung ist in Kapitel 4.3 zu finden.
Conflict
Dieses Feature verwaltet die Konflikte zwischen den Artikeln und den Dienst-
benutzern. Konflikte treten auf, wenn z.B. ein Gutachter einen Autor sehr gut
kennt, dann darf dieser kein Gutachten bzgl. des Artikels schreiben oder die
Begutachtung verfolgen. Die Gefahr der Beeinflussung wa¨re gegeben. Konflik-
te ko¨nnen von den Konferenzleitern jederzeit und von den Gutachtern in der
Bidding-Phase gesetzt werden. Die in der Konfliktmatrix festgelegten Konflik-
te finden Beru¨cksichtigung bei der Sicht auf den Dienst und der Erlaubnis,
Dienstfunktionalita¨ten zu verwenden. In erster Linie wird der Zugriff auf die
relevanten Gutachten, die Eintra¨ge in der EvaluationMatrix und die betroffe-
nen Foren verweigert.
Deadline
Um einen zeitlich gesicherten Ablauf der Konferenz zu gewa¨hrleisten, ko¨nnen
Zeitfristen fu¨r Aufgaben hinterlegt und u¨berwacht werden. Es lassen sich un-
ter anderem Zeitfristen fu¨r die Artikel- und Report-Einreichungen spezifizie-
ren. Das Feature wirkt unterstu¨tzend fu¨r den Konferenzleiter, der durch eine
Mitteilung per Email u¨ber den Ablauf einer Frist informiert wird. Dieser kon-
taktiert den betroffenen Dienstbenutzer perso¨nlich. Die Erfahrung hat gezeigt,
das automatisch gesendete Emails an Dienstbenutzer wenig Erfolg haben, da
sie einfach zu unperso¨nlich wirken.
Delegation
Das Delegation Management setzt sich zusammen aus den Gescha¨ftsprozes-
sen zur Zuteilung der Begutachtungsaufgaben und der DelegationMatrix ei-
ner Monitoring-Komponente fu¨r Delegierungen. Die jeweiligen Deadlines einer
Delegierung ko¨nnen modifiziert, und abgelehnte Begutachtungsaufgaben neu
verteilt werden. Jede Delegierung unterliegt zwei Deadlines, der Decision und
Task -Deadline. Die erste Deadline ist der Zeitpunkt, bis wann der Gutachter
die Aufgabe besta¨tigt haben soll und die Zweite zeigt die Zeit auf, bis zu der
das Gutachten eingereicht sein muss. Die Deadlines werden vom Deadline Ma-
nagement u¨berpru¨ft und im Falle einer Zeitu¨berschreitung die Konferenzleiter
benachrichtigt. Die Weiterleitung des Begutachtungsauftrages (SubReviewing)
KAPITEL 5. WORKFLOWS UND FEATURES 109
an Subreviewer wird ebenfalls von diesem Feature abgedeckt.
Email
Dieses Feature ermo¨glicht das Verfassen und Senden von Emails. Hierzu ko¨nnen
Textbausteine sowie Emailvorlagen definiert werden. Die Benutzung von Tags
erleichtert zusa¨tzlich das Schreiben von Emails. Mails ko¨nnen gleichzeitig an
eine Gruppe von Dienstbenutzern gesendet werden, z.B. an alle PC Member,
Autoren oder nur an alle Autoren der akzeptierten Artikel. Durch die erwa¨hn-
ten Tags ist es mo¨glich, eine Emailvorlage individuell fu¨r jeden Empfa¨nger
automatisiert mit Daten, wie z.B. den Namen, zu fu¨llen und diese zu ver-
senden. Des Weiteren ist ein Email-Monitoring vorhanden, das die eigenen
geschriebenen und empfangenen Emails verwaltet. Daru¨ber hinaus werden die
vom Dienst automatisch versendeten Emails gespeichert und sind fu¨r den PC
Chair einsehbar und notfalls erneut versendbar.
Evaluation
Die EvaluationMatrix ist die zentrale Seite des Features wa¨hrend der Ent-
scheidungsfindung, die fu¨r das Komitee einsehbar ist. Gutachter haben einen
Lesezugriff auf die Informationen, wobei die Konferenzleiter Modifikationen
der angezeigten Daten vornehmen ko¨nnen. Die relevanten Daten wie Artikel-
daten, die Benotungen der Gutachter, der gewichtete Mittelwert der Beno-
tungen und die daraus resultierende Rangliste der Artikel, werden mittels des
Evaluation-Features berechnet und visualisiert. Die Artikelforen ko¨nnen zur
Diskussion geo¨ffnet bzw. geschlossen und die Benotungen vom PC Chair u¨ber
das Feature modifiziert werden. Anhand der berechneten Varianz, die die U¨ber-
einstimmung bzw. Abweichung der Benotungen anzeigt, ist der Diskussions-
bedarf unter den Gutachtern fu¨r eine Entscheidungsfindung zu erkennen. Der
PC Chair setzt anhand der Diskussionsergebnisse den entsprechenden Artikel-
status und stellt dadurch den aktuellen Entscheidungsstatus dar, der farblich
visualisiert hervorgehoben wird. Wa¨hrend der Diskussion kann der Zustand
des Artikels zwischen mehreren Status wechseln (siehe Abbildung 5.2). Sobald
ein Artikel den Status accepted oder rejected aufweist, kann der Artikel mit
dem Report-Feature weiterbearbeitet werden, das dem PC Chair das Schreiben
eines abschliessenden Gutachtens freischaltet. Durch die zentralisierte Darstel-
lung der beno¨tigten Informationen und der Gruppierung der Artikel und deren
grafische Hervorhebung ist der jeweilige Status der Entscheidungsfindung fu¨r
jeden Artikel schnell ersichtlich.
KAPITEL 5. WORKFLOWS UND FEATURES 110
Forum
Sind große Abweichungen der Beurteilungen eines Artikels vorhanden, besteht
Diskussionsbedarf. Jeder Artikel verfu¨gt im OCS u¨ber ein eigenes Forum des-
sen Zugriff automatisch gesteuert wird. Wird ein Forum vom PC Chair fu¨r
einen Artikel geo¨ffnet, erhalten nur die Gutachter Zugriff, die ein Gutachten
fu¨r ihn verfasst und bereits eingereicht haben. Die Diskussionsleitung ist Aufga-
be der PC Chairs, die ebenfalls Zugriff erhalten. Wird keine U¨bereinstimmung
erzielt, kann ein PC Chair gezielt Gutachtern, die nicht direkt in der Begutach-
tung des Artikels involviert waren, Zugriff auf das Forum geben. Die zugrunde
liegende Seite zur Diskussion entha¨lt neben den Forenbeitra¨gen, die relevan-
ten Artikeldaten zuzu¨glich der geschriebenen Gutachten, was einen schnellen
Gesamtu¨berblick verschafft. Zur Vermeidung von unno¨tigem Zeitaufwand fu¨r
das Anmelden am Dienst und das Navigieren zum relevanten Forum wurde ein
Ticketsystem realisiert, das es ermo¨glicht, einen direkten Zugang auf ein Forum
zu erhalten. Der OCS versendet dieses Ticket an die involvierten Gutachter,
sobald ein neuer Beitrag im Forum existiert. Sind die lokalen Diskussionen zu
jedem Artikel abgeschlossen, kann der PC Chair gezielt die Foren der Arti-
kel, die zur Annahme vorgeschlagen sind, fu¨r das gesamte Komitee freigeben.
Es gibt in der Regel mehr Artikel, die es verdient ha¨tten auf der Konferenz
vorgestellt zu werden, als die Anzahl der akzeptierten Artikel. Es wird global
diskutiert, welche der potentiellen Beitra¨ge, letztendlich angenommen werden.
History
Dieses Feature fu¨hrt eine Historie u¨ber durchgefu¨hrte Aktionen auf Objekte
im OCS, diese sind unter anderem Article, Role oder Report. Die Eintra¨ge
der Historie lassen sich nach verschiedenen Gesichtspunkten filtern. Im Falle
der Artikel besteht die Filterung aus der Artikel-ID, der Benutzer-ID und der
Historie-Nachricht (Article has been removed oder Role has been modified.),
die den Eintrag spezifiziert. Diese Filterkriterien ko¨nnen zum Zwecke der Fil-
terung kombiniert werden. Mit der Historie kann sich ein U¨berblick von den
durchgefu¨hrten Aktionen bzgl. ausgewa¨hlter Objekte verschafft werden.
Production
Das Production-Feature stellt den kompletten Gescha¨ftsprozess fu¨r die Erstel-
lung eines Tagungsbandes in Form einer separaten Web-Applikation bereit,
die in Kapitel 7.3 beschrieben ist. Als Grundlage fu¨r den Tagungsband dienen
die Daten der akzeptierten Artikel. Hierzu za¨hlen die Endversionen, inklusive
KAPITEL 5. WORKFLOWS UND FEATURES 111
der Sourcen und den Metadaten. Zur Erstellung eines Autorenindexes und fu¨r
die Auflistung der am Entscheidungsprozess beteiligten Personen (PC Chairs,
PC Members, Organisatoren etc.) werden zusa¨tzlich Benutzerdaten beno¨tigt.
Der erstellte Tagungsband wird i.d.R. an den Springer Verlag Heidelberg zum
Druck und zur Vero¨ffentlichung weitergeleitet.
Report
Das Report Management bietet Gescha¨ftsprozesse zur Verwaltung und Bear-
beitung von Begutachtungen. Ein eigenes Framework (siehe Kapitel 4.4) wurde
fu¨r die Erstellung individueller Begutachtungsformulare realisiert und bietet
den Konferenzleitern die Web-basierte Konfiguration der auf die Konferenz
abzustimmenden Formulare an. Des Weiteren bietet diese Feature, vergleich-
bar mit dem Article-Feature, die Einreichung, das Lesen, die Modifikation oder
Lo¨schung eines Reports an. Die Aktionen werden u¨ber das Rollen und Rechte-
system gesteuert und ko¨nnen feingranular zugeordnet werden. Hervorzuheben
sind die anonymous modus und view confidential content SubFeatures. Diese
bewirken einerseits eine Anonymita¨t zwischen den PC Members und ande-
rerseits die kontrollierte Anzeige der als sicherheitsrelevant gekennzeichneten
Elemente eines Begutachtungsformulares.
Role
Rollen geben Benutzern Rechte, Dienstfunktionalita¨ten zu verwenden, Objek-
te zu bearbeiten oder Dienstinformationen einzusehen. Sie ko¨nnen neu ange-
legt, modifiziert oder gelo¨scht werden. Eine Rolle besteht aus einer Auswahl
von Feature und SubFeatures, die die Gescha¨ftsprozesse der Applikation re-
pra¨sentieren. Diese Feature bilden zusammen mit dem User Management das
Rollen/Rechte Management (siehe Kapitel 4.2), das das Konzept der flexiblen
Zugriffskontrolle widerspiegelt.
Setup
Die unterstu¨tzte schrittweise Konfiguration des Entscheidungssystems wird
durch das Feature Setup verko¨rpert. Das Setup fu¨hrt durch einen Workflow,
der eine Auswahl von Features konfiguriert und diese in Bezug auf die An-
forderungen einer Konferenz flexibel anpasst. Hierzu za¨hlen das Aussehen der
Dienstseiten, Logos, Zeitfristen (deadlines), Reportformulare, Anzahl der Gut-
achter pro Artikel, Artikelkategorien, Vorschriften zur Einreichung und das
KAPITEL 5. WORKFLOWS UND FEATURES 112
Copyright, Formate der Artikel, Rollen, Vorregistrierung des Komitees, etc.
Des Weiteren sind alle vom Dienst automatisch zu versendenden Email als
Vorlagen online modifizierbar. Der OCS kann u¨ber das Setup in verschiedenen
Modi betrieben werden:
• Setup Mode: Der Dienst steht ausschließlich den Konferenzleitern fu¨r
die Konfiguration desselben zur Verfu¨gung.
• Demo Mode: Das Komitee kann den Dienst mit den durchgefu¨hrten
Konfigurationen testen. Dieses beeinflusst nicht den Originaldienst, da
auf einer Kopie gearbeitet wird.
• Productive Mode: Der Dienst wird freigeschaltet, d.h. die Komiteemit-
glieder erhalten ihre Zugangsdaten und ko¨nnen ihr Profil vervollsta¨ndi-
gen. Autoren sind in der Lage, sich zu registrieren und ihre Beita¨ge ein-
zureichen.
Service Status Report
Der Status Report beinhaltet einen U¨berblick u¨ber die Situation der Konferenz.
Die Inhalte dieses Reports ko¨nnen mittels des Setup Features konfiguriert und
per Email automatisch zugeschickt werden. Es sind Handlungsbedarf sowie
Fortschritte durch den Report ersichtlich.
Staff
Die Mitarbeiter (Staff) bestehen aus anderen Dienstnutzern, die zu dem Per-
sonenkreis geho¨ren, mit dem direkt zusammengearbeitet wird. Der PC Chair
bzw. PC Member sind in der vordefinierten Rollenkonfiguration in der Lage,
einen eigenen Staff anzulegen. Dieses hat den Vorteil, diverse Listen auf die
Anzahl der Personen des eigenen Staffs zu beschra¨nken.
Tasklist
Die Tasklist ist eine Liste von Aufgaben, die der jeweilige Benutzer zu erledi-
gen hat. Der Benutzer sieht in dieser Liste die Informationen seiner Aufgaben
und die als na¨chstes durchzufu¨hrende Aktion. Die Tasklist eines PC Mem-
bers entha¨lt die ihm zugewiesenen Artikel mit der Aufgabe, einen Report zu
schreiben bzw. der Mo¨glichkeit, diesen an einen SubReviewer weiterzuleiten.
KAPITEL 5. WORKFLOWS UND FEATURES 113
User
Das User-Feature verwaltet die Benutzer des Dienstes. Benutzer ko¨nnen an-
gelegt, editiert, gesperrt, freigeschaltet oder gelo¨scht werden. Des Weiteren
integriert es die Verwaltung der Rollen und Kategorienzuordnung sowie die
Benutzer-spezifischen Rechtezuweisungen. Die Registrierungskomponenten ba-
sieren ebenfalls auf dem im Forum-Feature verwendeten Ticketsystem. Ein
Autor erha¨lt nach erfolgreicher Selbstregistrierung ein Ticket via Email zuge-
schickt, mit dem er sein Benutzerkonto freischalten und besta¨tigen muss.
Die vorgestellten Features sind graphbasiert mittels des ABC’s als Makros
realisiert. Durch den modularen Ansatz konnten die Makros in verschiedenen
Web-Applikationen wiederverwendet werden. Die Applikationen geho¨ren zur
Dienstfamilie des OCS, die in Kapitel 7 vorgestellt werden.
Kapitel 6
Architektur und Technologie
Dieses Kapitel stellt die zur Entwicklung des Entscheidungssystems verwende-
ten Konzepte und Technologien vor. Architekturen des OCS werden aufgezeigt
und Zusammenha¨nge sowie Abha¨ngigkeiten beschrieben.
6.1 Client-Server-Architektur des OCS
Das Entscheidungssystem OCS basiert auf einer Client-Server-Architektur, die
exemplarisch in Abbildung 6.1 dargestellt wird. Der Client (Frontend) ist ein
ga¨ngiger Browser, mit dem der Dienstbenutzer Anfragen (requests) generiert
und an einen Webserver (Backend) zur Verarbeitung u¨bergibt. Als Webserver
wird fu¨r den OCS der Apache HTTP Server [Fou09b] eingesetzt. Der Webser-
ver leitet diese Anfrage an einen Applikationsserver weiter, der unter Verwen-
dung von weiteren verteilten Systemen (z.B. Datenbank, Dateisystem, SAN 1,
Versionsverwaltungssystem, ...) die beno¨tigten Daten zusammenstellt, um an-
schließend dynamisch die angeforderte Web-Seite (response) zu generieren.
Der OCS basiert auf der Java-Servlet-Technologie. Ein Servlet ist eine server-
seitige Java-Anwendung, die in einem Servlet-ContainerApache Tomcat [Fou09c]
ausgefu¨hrt wird. Hierzu muss eine Java-Klasse implementiert werden, die von
der Klasse javax.servlet.http.HttpServlet ableitet. Im OCS wurde die
Initialisierungsmethode init() u¨berschrieben, um z.B. die Gescha¨ftsprozesse,
Datenbankadministratoren, die EWIS-Laufzeitumgebung (EWIS, siehe Kapi-
tel 3.2) zu initialisieren. Des Weiteren wurde die Methode destroy() u¨ber-
schrieben, um ein gesichertes Beenden der existierenden Verbindungen zu an-
1Storage Area Network
115
KAPITEL 6. ARCHITEKTUR UND TECHNOLOGIE 116
Abbildung 6.1: Client-Server-Architektur des OCS
deren Anwendungen, wie z.B. der Datenbank, zu gewa¨hrleisten und Datenver-
lust zu vermeiden. Um eingehende Daten bearbeiten zu ko¨nnen, ist mindestens
eine der Methoden doGet, doPOST oder service zu u¨berschreiben. Um das
Servlet ausfu¨hren zu ko¨nnen, beno¨tigt der Servlet-Container den Deployment
Descriptor, eine XML-Datei namens web.xml, die Konfigurationen und Para-
meter fu¨r das entsprechende Servlet beinhaltet. Um die Anwendung starten zu
ko¨nnen, werden alle beno¨tigten kompilierten Klassen, insbesondere die Servlet-
Klasse, HTML-Seiten, Bilder, etc. in ein Archiv (.war) zusammengefu¨gt und
dem Apache Tomcat u¨bergeben. Das Starten und Beenden kann entweder u¨ber
die Kommandozeile oder eine Web-Schnittstelle erfolgen.
Wie in der Abbildung 6.1 angedeutet, sind die einzelnen Gescha¨ftsprozesse mit-
tels des ABC als Graphen modelliert. Die Prozesse definieren den Kontrollfluss
des Dienstes, der sich auf die unterschiedlichen Kontexte auswirkt. So ist ein
Prozess zusta¨ndig fu¨r das Lesen aus der Datenbank, ein anderer schreibt die
Daten in die Datenbank, wiederum ist ein anderer Prozess fu¨r die A¨nderung ei-
ner Rolle zusta¨ndig. Koordiniert werden diese Prozesse (hier Makros) von einer
u¨bergeordneten Schicht, die im Fall des OCS ebenfalls als Graph modelliert ist.
Diese Struktur und die genaue Vorgehensweise ist in Kapitel 4.1.2 beschrieben.
Die Erstellung eines Gesamtsystems aus zugrunde liegenden Gescha¨ftsprozes-
sen folgt dem SOA Konzept, das eine schnelle, flexible und einfache A¨nderung
KAPITEL 6. ARCHITEKTUR UND TECHNOLOGIE 117
von Gescha¨ftsabla¨ufen als Ziel hat.
6.2 Schichtenmodell des OCS
Der OCS ist ein verteiltes System, dessen Services sich auf mehreren Servern
verteilen, und sich dem Benutzer als ein ganzheitliches System pra¨sentiert. Die
Verwendung eines solchen Konzepts unter der Beru¨cksichtigung redundanter
Ausfu¨hrungen wichtiger Komponenten fu¨hrt zu einer
• hohen Leistungssteigerung,
• besseren Skalierbarkeit und
• sehr hohen Ausfallsicherheit (24x7).
Der OCS wurde als eine fu¨nf schichtige Web-Applikation entwickelt, dessen
Aufbau in Abbildung 6.2 dargestellt wird.
Abbildung 6.2: Schichtenmodell des OCS
Die Schichten lassen sich, wie in der Abbildung dargestellt, in Server-seitige
und Client-seitige Schichten gruppieren. Der Web Access-Layer repra¨sentiert
die Schnittstelle zwischen beiden Gruppen und steuert deren Kommunikation.
Im Folgenden werden die einzelnen Schichten na¨her beschrieben:
KAPITEL 6. ARCHITEKTUR UND TECHNOLOGIE 118
1. Persistency-Layer: Die Persistenzschicht bildet die unterste Schicht.
Sie ist zusta¨ndig fu¨r die Speicherung der Gescha¨ftsobjekte in einer Da-
tenbank sowie fu¨r die Datenhaltung in einem Versionierungssystem oder
Dateisystem. Fu¨r die Datenbankanbindung wurde JDBC 2 [mic09j] ver-
wendet, eine Java-basierte Schnittstelle fu¨r relationale Datenbanken. Mit
JDBC wird eine Anbindung an Datenbanken verschiedener Hersteller
ermo¨glicht. So kann OCS sowohl auf PostgreSQL [Com09] als auch Oracle
[Ora09]-Datenbanken arbeiten.
2. Business Object-Layer:Diese Schicht beinhaltet die Gescha¨ftsobjekte.
In dem Projekt OCS geho¨ren hierzu unter anderem die Objekte Artikel,
Benutzer, Rollen, Assoziationen zwischen den Objekten sowie Admini-
stratorklassen. Die Schicht ist losgelo¨st von den Applikationen, so dass
die Objekte applikationsu¨bergreifend eingesetzt werden ko¨nnen.
3. Coordination-Layer: Die Koordinationsschicht stellt den Kontrollfluss
einer Applikation dar. Im ABC wird der Ablauf eines Prozesses oder einer
Anwendung als Kontrollflussgraph (SLG) modelliert, der die Gescha¨ftslo-
gik einer Applikation repra¨sentiert. Die im SLG verwendeten SIBs arbei-
ten auf den im Business Object-Layer realisierten Objekten und stellen
diese in Beziehung.
4. Web Access-Layer: Diese Schicht ist fu¨r die Kommunikation zwischen
einem Dienstbenutzer (Client) und der Applikation verantwortlich. Sie
setzt sich einerseits aus dem Web-Server, der die Anfragen an die Ap-
plikationsserver weiterleitet und andererseits aus der Laufzeitumgebung
(EWIS), die mithilfe der Koordinationsschicht die Gescha¨ftslogik durch-
la¨uft, zusammen. Die durch die Abarbeitung der fu¨r die Anfrage rele-
vanten Gescha¨ftslogik erzielte Antwort wird dem Client u¨bertragen und
entsprechend der GUI angezeigt.
5. GUI-Layer: Die grafische Benutzeroberfla¨che stellt die Kommunikati-
onsschnittstelle zum Dienstbenutzer in Form eines Browsers dar. Es wer-
den Dienstinformationen bzw. Formulare als HTML-Seiten angezeigt.
Der Browser dient als Eingabe- und Ausgabeinstrument, das fu¨r den
OCS ohne jegliche Zusatzsoftware auskommt. Das ermo¨glicht das welt-
weite Arbeiten unter Verwendung eines rudimenta¨ren Browsers.
Anhand der spezifizierten Schichten la¨sst sich ein organisiertes und paralleles
Vorgehen bei der Entwicklung einer Applikation verfolgen. Arbeiten ko¨nnen
2Java Database Connectivity
KAPITEL 6. ARCHITEKTUR UND TECHNOLOGIE 119
auf unterschiedliche Experten aufgeteilt werden. So sind die Programmierex-
perten fu¨r die Umsetzung der Schicht 1, Schicht 2 und der Laufzeitumgebung
(Schicht 4) zusta¨ndig. Die SIB-Experten schreiben auf Basis der Gescha¨fts-
objekte Dienstfunktionalita¨ten, die als Bibliotheken dem Anwendungsexperten
zur Verfu¨gung stehen. Anwendungexperten erstellen den Kontrollflussgraphen
der Anwendung, was keinerlei Programmierkenntnisse voraussetzt. Der HTML-
Designer entwickelt die HTML-Seiten unter Beru¨cksichtigung der Program-
mierschnittstelle der Objekte, die die anzuzeigenden Informationen kapseln.
Das Schichtenmodell des OCS basiert auf dem Model View Controller (MVC)
Konzept, das sich aus einem Datenmodell, einer Pra¨sentationsebene und der
Programmsteuerung zusammensetzt. Die Schichten Persistency-Layer und Busi-
ness Object-Layer des OCS entsprechen dabei dem Datenmodell. Die Pro-
grammsteuerung wird von dem Coordination-Layer und dem Web Access-
Layer repra¨sentiert. Die Pra¨sentationsebene erstreckt sich u¨ber die Schichten
Web Access-Layer und GUI-Layer.
Die Einfu¨hrung eines Coordination-Layer als Erweiterung des Ansatzes des
MVC-Modells wird als Lightweight Process Coordination approach [MS04b] be-
zeichnet. Das Konzept Aggressive model-driven development (AMDD) [MS04a]
beruht auf dem erweiterten MVC Konzept und ermo¨glicht Personen ohne
tiefere Kenntnisse u¨ber die Diensttechnik und Programmiersprachen, Anwen-
dungen zu entwerfen. Darauf basiert das eXtreme Model-Driven Design Para-
digma (XMDD) [KJMS09], welches durch die erzielte Abstraktionsebene der
Modellierung der Gescha¨ftsabla¨ufe Applikationsexperten und Gescha¨ftsleute
gleichermaßen kontinuierlich in den gesamten Lebenszyklus eines Systems in-
volviert.
Der OCS ist in der Programmiersprache Java [INC09] geschrieben, eine ob-
jektorientierte Sprache, deren Konzept, die Plattformunabha¨ngigkeit der im-
plementierten Anwendungen, auf nahezu allen Rechnerplattformen erfu¨llt ist.
Die entwickelten Java-Klassen (.java) werden mittels eines Compilers in Java-
Bytecode (.class) u¨bersetzt. Die Plattformunabha¨ngigkeit wird durch die JVM 3
erzielt, einem Interpreter, der fu¨r die jeweilige Plattform implementiert wird
und dort den Bytecode ausfu¨hrt. Die Firma Sun Microsystems [mic09l] bietet
die JVMs fu¨r verschiedene Kombinationen von Hardware- und Betriebssyste-
men an.
3Java Virtual Machine
Kapitel 7
Dienstfamilie
Dieses Kapitel stellt die Dienstfamilie des OCS vor. Sie besteht zum Teil aus
Diensten, die aus den Konzepten und somit aus dem OCS heraus entstanden
sind und unabha¨ngig vom OCS genutzt werden. Zum anderen Teil der Dienst-
familie geho¨ren diejenigen, die direkt mit dem OCS arbeiten. Es sind Features
des OCS, die als eigene Dienste realisiert wurden. Die Abbildung 7.1 zeigt den
Zusammenhang des Gesamtsystems OCS.
MOS
PPS
OJS 1OCS n. . .
. . .OCS 1 OJS n
Abbildung 7.1: Architektur: MOS, OCS, OJS, PPS
Die folgenden Kapitel befassen sich jeweils mit einem Dienst der OCS-Dienst-
familie, beschreiben deren Einsatzbereich und gehen kurz auf die verwendete
121
KAPITEL 7. DIENSTFAMILIE 122
Technologie ein.
7.1 Management Overview System (MOS)
Das Management Overview System ist ein zentraler Zugriffspunkt (Single
Point of Entry) auf die Dienstinstanzen des OCS und OJS. Abbildung 7.1
zeigt den Zusammenhang auf. Der MOS gibt den OCS bzw. OJS-Benutzern
(PC Chair, PC Member, Author, etc.) und den MOS-Administratoren einen
direkten Zugriff auf die Instanzen. OCS, OJS-Benutzer erhalten nach erfolgrei-
cher Authentifizierung eine Tabelle von OCS-Instanzen, in denen der Benutzer
involviert ist, d.h. u¨ber einen Account verfu¨gt. Von dieser Seite kann direkt
auf die gelisteten Instanzen zugegriffen werden, ohne eine erneute Authenti-
fizierung durchfu¨hren zu mu¨ssen. Das Ausloggen aus der jeweiligen Instanz
fu¨hrt automatisch zuru¨ck zur U¨bersichtsliste der Konferenzen. Des Weiteren
gibt der MOS dem Administrator eine Verwaltungskomponente zur Hand, die
u¨berwiegend die bereits existierenden Komponenten einer OCS-Instanz direkt
verwendet. Die Verwaltungsfunktionalita¨ten sind mit Java Server Pages (JSP)
realisiert.
Ein weiterer wesentlicher Bestandteil ist die Synchronisierung von Daten. MOS
wurde als eigene Web-Anwendung konzipiert, die auf einer eigenen Datenbank
basiert. Fu¨r die Persistenzschicht wird das Framework Hibernate [BHRS07]
eingesetzt. A¨nderungen, die an Objekten im MOS oder in einer OCS-Instanz
durchgefu¨hrt werden, sind zwischen dem MOS und den OCS-Instanzen zu syn-
chronisieren. Der Abgleich der Objekte findet mittels der OpenSource Lo¨sung
JMS 1 [mic09k] statt. Als JMS-Provider wird Apache ActiveMQ [Fou09a] ein-
gesetzt. Die Kommunikation zwischen dem MOS und den Dienstinstanzen er-
folgt ausschließlich u¨ber JMS und ist asynchron. Hierzu erha¨lt jede Dienstin-
stanz und der MOS eine eigene Queue. Im Falle einer A¨nderung im OCS
schreibt dieser eine Message in die Queue des MOS, der diese konsumiert.
In die Queue der OCS-Instanzen darf nur der MOS schreiben, der auf die-
sem Wege A¨nderungen an die OCS-Instanzen propagieren kann. Sollte eine
OCS-Instanz oder MOS selbst nicht online sein, so werden die Messages der
entsprechenden Queue persistent gehalten. Sobald der Dienst wieder online ist,
meldet sich dieser erneut an dem MOS an und konsumiert die in seiner Queue
befindenden Nachrichten vom JMS-Provider.
Diese Lo¨sung des u¨bergeordneten Dienstes ist unter dem Aspekt der Verwen-
dung der zugrunde liegenden Architektur der OCS bzw. OJS-Instanzen ent-
1Java Messaging Service
KAPITEL 7. DIENSTFAMILIE 123
standen. In Bezug auf die Arbeitsweise und Kernfunktionalita¨ten sollten keine
Vera¨nderungen erfolgen. Dadurch ist gewa¨hrleistet, dass die Instanzen weiter-
hin autark fungieren ko¨nnen, mit der Option, diese in den MOS aufzunehmen.
D.h. Instanzen die bei verschiedenen Kunden installiert sind, ko¨nnen in den
MOS eingebunden werden. Die Anbindung an einen MOS erfolgt u¨ber die Kon-
figuration des jeweiligen Deployment Descriptors (web.xml Datei) einer OCS
bzw. OJS-Instanz.
7.2 Online Journal Service (OJS)
Der OJS ist ein Web-basiertes Entscheidungssystem zur Begutachtung und
Auslese von Artikeln, die in einer wissenschaftlichen Zeitschrift (Journal) ver-
o¨ffentlicht werden. Journal-Vero¨ffentlichungen sind aus wissenschaftlicher Sicht
von hohem Wert, allerdings im selben Maße oft schwierig zu verwirklichen. Ei-
ner der Gru¨nde ist, dass die Journals nur eine begrenzte Anzahl von Ausgaben
im Jahr mit einer geringen Anzahl von Beitra¨gen aufweisen. Eine andere Ein-
schra¨nkung kann sein, dass es fu¨r das Themengebiet eines Autors im Vergleich
zu der Anzahl der Konferenzen sehr wenige Journals gibt.
Im Vergleich zum OCS, dessen Instanz im Schnitt drei bis vier Monate pro
Konferenz aktiv ist, dauert die Entscheidungsfindung u¨ber Annahme oder Ab-
lehnung eines Journal-Beitrages mitunter bis zu einem Jahr und la¨nger. Einer
der Gru¨nde ist die Anzahl der Revisionen des Beitrages, die ein Autor auf-
grund von Gutachten durchfu¨hrt. In Abha¨ngigkeit von dem Bekanntheitsgrad
des Journals ist ein Begutachtungsdurchlauf als strenger einzuordnen im Ver-
gleich zu einer Konferenz. Das soll allerdings die Bedeutung von Konferenzen
nicht schma¨lern. So kann es vorkommen, das auch nach mehrmaliger Verbesse-
rung und Einreichung der u¨berarbeiteten Version, der Artikel letztendlich fu¨r
das Journal abgelehnt wird.
Der OJS ist auf der Basis der OCS-Technologie realisiert worden, d.h. er ist
ebenfalls mittels des ABC und unter Verwendung der EWIS-SIB-Bibliotheken
als eine Web-basierte Anwendung modelliert und als Java-Servlet realisiert
worden. Der Feature-basierte Ansatz wurde umgesetzt und darauf aufbauend
das Benutzer/Rollen-System u¨bernommen. Der OJS verfu¨gt u¨ber den gesam-
ten Umfang an Features, die fu¨r den OCS implementiert wurden. Unterschied
zum OCS ist einerseits der Verzicht auf Features, wie die Diskussionforen oder
das Bidding mit automatischer Verteilung der Begutachtungsaufgaben, ande-
rerseits ein abgewandelter und erweiterter Workflow durch neue Features.
Der Workflow startet mit der Einreichung der Beitra¨ge durch die Autoren.
KAPITEL 7. DIENSTFAMILIE 124
Das Editorial Office (Leitung der Konferenz) kann diese direkt zur Begutach-
tung an die Reviewer (Gutachter von Beitra¨gen) weiterleiten oder sich erst
Vorschla¨ge fu¨r Reviewer von Editors (Herausgeber) einholen. Ein Editor kennt
die Wissensgemeinschaft und kann entsprechend Mitglieder als Reviewer vor-
schlagen. Das Vorschlagen der Reviewer und die U¨bernahme der selbigen zur
Verteilung der Begutachtungsaufgaben erfolgt u¨ber das Feature Nomination.
Die Reviewer begutachten die delegierten Artikel und schreiben ein Gutachten.
Nachdem alle Gutachten eingegangen sind, entscheiden die Editors anhand der
Gutachten, welche Artikel zur Vero¨ffentlichung akzeptiert werden sollen. Die
akzeptierten Artikel werden unterschieden in direkt akzeptierte Artikel und
in vielleicht akzeptierte Artikel. Im Falle eines vielleicht akzeptierten Artikels
durchla¨uft die vom Autor eingereichte, verbesserte Version des Artikels (revised
version) den Begutachtungsprozess erneut. Ein Durchlauf des Begutachtungs-
prozesses endet mit dem Versenden von abschließenden Gesamtgutachten an
die Autoren.
7.3 Proceeding Production Service (PPS)
Nach Abschluss der Entscheidungsfindung und der Einreichung der letzten
u¨berarbeiteten Version der akzeptierten Artikel, liegen die Quelldaten (z.B. in
LaTeX) und eine druckbare Version (z.B als PDF) von jedem Artikel vor. In
diesem Konferenzstatus beginnt die Proceedings-Phase (siehe Abbildung 5.1).
Es ist fu¨r den Workshop oder die Konferenz ein Tagungsband zu erstellen, der
von einem Verlag gedruckt und vero¨ffentlicht wird. Derartige Tagungsba¨nde
dienen einerseits als U¨bersichtsmaterial fu¨r die an der Tagung teilnehmenden
Personen, andererseits stellt sie der Verlag zum Kauf zur Verfu¨gung. Interes-
senten sind meist Wissenschaftler, die in dem selben Themengebiet forschen
und der industrielle Bereich, der den neusten Stand der Forschung verfolgt um
diesen eventuell gewinnbringend im eigenen Unternehmen einfließen zu lassen.
Die folgenden Elemente bilden einen Tagungsband:
• Der Titel des Tagungsbandes.
• Die Reihennummer des Bandes (volume number).
• Die Einleitung und Danksagung.
• Die angenommenen Artikel.
• Auflistungen aller Gutachter und der Organisatoren.
KAPITEL 7. DIENSTFAMILIE 125
• Das Inhaltsverzeichnis.
• Der Autorenindex.
Der PPS wurde realisiert, um den Organisator der Konferenz bei der Erstel-
lung des Tagungsbandes zu unterstu¨tzen. PPS liest die relevanten Daten von
der OCS- oder OJS-Instanz ein und verwaltet diese in der eigenen Datenbank.
Die Web-Applikation fu¨hrt den Anwender durch die relevanten Schritte zur
Anfertigung des Tagungsbandes. Die Gliederung des Bandes erfolgt durch die
Einordnung der Artikel in thematische Gebiete, wobei der Titel eines Arti-
kels und die Namen der Autoren die Beschriftung eines Gliederungspunktes
sind. Diese Einteilung der Artikel wird anschließend durch das Einfu¨gen von
U¨berschriften (Kapiteln) verfeinert. Die grafische Repra¨sentation fu¨gt dafu¨r ein
neues Textfeld ein, in dem die U¨berschrift eingegeben wird. PPS bietet jeder-
zeit die Mo¨glichkeit, die Proceedings als PDF-Vorschau zu generieren. Dadurch
sind auf einfache Weise die Struktur und eventuelle Fehler in der Formatierung
zu erkennen. Zusa¨tzlich ko¨nnen Latex-Sourcen der Artikel mittels der Doku-
mentenklasse des Verlages auf ihre Gu¨ltigkeit hin u¨berpru¨ft werden. Sobald
die Erstellung des Tagungsbandes abgeschlossen ist, kann vom PPS ein Archiv
mit allen beno¨tigten Daten fu¨r den Verlag erstellt werden, wobei das Archiv
einem durch den Verlag vorgeschriebenen Format entspricht.
Die Kernkomponenten des PPS wurden graphbasiert im jABC modelliert und
mit dessen Code-Generator Plugin in Java-Klassen konvertiert, die eine Bi-
bliothek zur Tagungsbanderstellung darstellen. Die Ausfu¨hrung der Kernkom-
ponenten wurde mittels des GWT 2 [Goo09] umgesetzt, ein Framework fu¨r
Web-Anwendungen, das im Mai 2006 von Google vero¨ffentlicht wurde. Fu¨r
jede Kernkomponente ist ein GWT-Servlet implementiert, das die Kernkom-
ponenten auf RPC 3-Methoden abbildet. GWT ermo¨glicht die Entwicklung
von AJAX 4 [All09]-Anwendungen, ein Konzept zur asynchronen Datenu¨bert-
ragung zwischen dem Server und dem Browser (Client). Somit ko¨nnen gezielt
Daten einer HTML-Seite nachgeladen werden ohne diese komplett neu laden zu
mu¨ssen. Mittels GWT lassen sich AJAX-Anwendungen in Java implementieren
und durch einen GWT eigenen Compiler nach AJAX-fa¨higes JavaScript u¨ber-
setzten. Als GUI werden AJAX-basierte HTML-Seiten verwendet, die u¨ber die
GWT-Servlets die definierten RPC-Methoden aufrufen und somit Zugriff auf
die Funktionalita¨ten der Kernkomponenten haben. Die Modellierung der Ver-
bindungen der Seiten wurde mit dem jABC Plugin JEEWAB durchgefu¨hrt,
2Google Web Toolkit
3Remote Procedure Call
4Asynchronous JavaScript and XML
KAPITEL 7. DIENSTFAMILIE 126
das das HTML-Geru¨st und den Deployment Descriptor generiert. Die Daten-
bankschicht basiert auf dem Hibernate Framework.
7.4 Lecture Notes in Computer Science (LN-
CS)
Der LNCS Dienst wurde auf Basis der OCS-Technologie realisiert und setzt
u¨berwiegend auf dessen Features auf. Konzipiert wurde der Dienst zur Ent-
scheidungsfindung u¨ber die Zulassung eines Projektes zur Publikation. Ein
Projekt kann z.B. eine Konferenz, ein Journal oder ein Workshop sein. Ein
Organisator reicht seinen Vorschlag beim Verlag zur Publikation ein.
Die Rolle Editor in Chief verwaltet und koordiniert den Begutachtungspro-
zess. Eingehende Vorschla¨ge bzw. Anfragen werden mittels dieser Rolle u¨ber
ein Formular in den Dienst eingepflegt. Es werden verschiedene Metadaten zum
Projekt eingegeben, wie der Name des Ansprechpartners, der mit der Rolle
Organizer im Dienst angelegt wird, oder die Internetseite des Projektes (Ho-
mepage der Konferenz). Diese Informationen sind fu¨r den LNCS Series Editor
bestimmt, um sich ein Bild u¨ber den Vorschlag zu machen. Durch die Benach-
richtigung der entsprechenden LNCS Series Editor verteilt der Editor in Chief
die Anfragen auf Vero¨ffentlichung. Zeitgleich wird der Status des Beitrages auf
discussion gesetzt und automatisch ein Forum zur Diskussion geo¨ffnet. Die Fo-
ren dienen den Reihenherausgebern zur Entscheidungsfindung u¨ber Annahme
oder Ablehnung der Anfrage. Fu¨r die flexible Koordination und Verwaltung
der Zuweisung des Vorschlages und der Vergabe der entsprechenden Zugriffe
auf das Forum, wurde das im OCS bestehende Feature Conflict eingesetzt.
Dieses zeigt die Flexibilita¨t und die daraus resultierende Wiederverwendbar-
keit der Features in anderen Kontexten auf. Das Ergebnis der Diskussion wird
dem Organizer u¨ber den Dienst unter Verwendung von konfigurierbaren Email-
Templates zugeschickt.
7.5 Transactions
Der Transactions Dienst gliedert sich ebenfalls in die Dienstkategorie der
Entscheidungssysteme ein und verfolgt auch den Feature-orientierten Ansatz.
Er beinhaltet Dienstfunktionalita¨t des OCS und OJS und erweitert den Um-
fang an Features durch eigene Applikationsspezifische Features. Mittels des
ABC werden die Features, die in Form von Makros vorliegen, zu einen Kon-
KAPITEL 7. DIENSTFAMILIE 127
trollflussgraphen modelliert, der die Gescha¨ftslogik des Transactions-Dienstes
repra¨sentiert.
Im Transactions-Dienst ist ein Editor in Chief zusta¨ndig fu¨r die Konfiguration
des Dienstes und dessen Leitung. Er leitet die von dem Autoren eingereich-
ten Forschnungsergebnisse an die Editors (Herausgeber) weiter. Diese verfassen
entweder ihr eigenes Gutachten, oder schreiben eine Zusammenfassung von den
Reviewer -Gutachten, an die sie weiterdelegieren ko¨nnen. Reviewer sind aus-
schließlich fu¨r das Verfassen von Gutachten zusta¨ndig. Die Diskussion bzgl. der
Annahme eines Beitrages wird vom Editor in Chief und den Editors gefu¨hrt.
Es sei erwa¨hnt, dass es nicht nur einen Editor in Chief geben muss. Aufgrund
der Diskussion kann der Beitrag in den Status accepted, proposed accepted oder
rejected gesetzt werden. Nach dem Setzen des Artikels in einen der Zusta¨nde
wird automatisch die Funktionalita¨t fu¨r das Schreiben der Abschlussgutachten
freigegeben. Das Verfassen eines Abschlussgutachtens hat in Abha¨ngigkeit des
Artikelstatus folgende Auswirkung auf den weiteren Prozess:
• accepted : Der Autor darf eine u¨berarbeitete Artikelversion als Endversion
seiner Arbeit einreichen.
• proposed accepted : Der Autor reicht die u¨berarbeitete Version seines Ar-
tikels ein, die erneut den Begutachtungsprozess durchla¨uft. Die Wieder-
holung dieses Prozesses endet, sobald der Artikel den Zustand accepted
oder rejected einnimmt.
• rejected : Der Artikel ist abgelehnt. Die Autoren ko¨nnen die Gutachten
zu ihrem Artikel einsehen.
Ein weiterer wichtiger Punkt bei dem Begutachtungsprozess des Transactions-
Dienstes sind die individuellen Zeitfristen. Im OCS ist eine Synchronisierung
der Begutachtungsphasen fu¨r alle Artikel zwingend notwendig, da die Artikel
in einem konkurrierenden Verha¨ltnis stehen und Entscheidungsfindungen alle
Artikel betreffen. Im Transactions-Dienst hingegen kann die Zeitfrist, die die
Beendingung des gesamten Begutachtungsprozesses spezifiziert, entweder fu¨r
einen einzelnen Artikel oder fu¨r eine Artikelkategorie festgelegt werden.
Teil IV
Analyse und Erfahrungen: OCS
im Einsatz
129
Kapitel 8
Design-Entscheidungen
Dieses Kapitel entha¨lt eine kurze Zusammenfassung der angewandten Tech-
nologien und diskutiert eine Auswahl von Dienstfunktionalita¨ten (siehe auch
Kapitel 5.3), die im Laufe der Jahre das Einsatzspektrum der Entscheidungs-
systeme erweitert haben. Eine detailliertere Darstellung der fu¨r den OCS ver-
wendeten Technologien kann in den Kapiteln 3 und 6 nachgeschlagen werden.
Die Geburtsstunde des OCS war 1999 in der Firma METAFrame Technolo-
gies. Als Entwicklungsumgebung wurde das firmeneigene Entwicklungswerk-
zeug ABC [SM99, SMCB96] (siehe Kapitel 1.2.3 und 3.1) eingesetzt. Das
ABC war bereits Ende der neunziger Jahre mit Hilfe von EWIS (siehe Ka-
pitel 3.2) in der Lage, graphbasiert Web-Applikationen zu modellieren und
den Kontrollfluss auf Basis der Graphen zu generieren und auszufu¨hren. Dabei
wird ein WAR-Archiv der Web-Anwendung erstellt, das in einem Webcontainer
(z.B. Tomcat) ausfu¨hrbar ist. Das ABC repra¨sentiert ein einheitliches Werk-
zeug zur modellbasierten Entwicklung von komplexen Web-Anwendungen auf
Ebene von Gescha¨ftsabla¨ufen [MS09, SN07, MS04a, KJMS09], dessen Model-
le ausfu¨hrbar und validierbar sind [KM05, KM06, KMW08]. Die Mo¨glichkeit
der modellgetriebenen Softwareentwicklung (MDA) und die daraus folgende
strukturierte Vorgehensweise der Konzeption (SOA) erfu¨llte die an der Ap-
plikation gestellten Anforderungen, wie Modularita¨t und Wiederverwendbar-
keit sowie die Erweiterbarkeit und die einhergehende Modifizierbarkeit des Sy-
stems (siehe Kapitel 1.2.2). Die vereinfachte Form der Abbildung von komple-
xen Gescha¨ftsprozessen auf die leicht versta¨ndliche graphbasierte Darstellungs-
form ermo¨glicht die Involvierung von Nicht-Programmierern in den Prozess der
U¨bertragung der Gescha¨ftsabla¨ufe in die IT-Welt. Dieser wesentliche Aspekt
wurde von anderen Entwicklungsumgebungen wie LEU [DGSZ94, Bra01] oder
MOKASSIN [HG98, Bra01] nicht verfolgt. Das ARIS -Konzept [Sei02] fokus-
131
KAPITEL 8. DESIGN-ENTSCHEIDUNGEN 132
sierte sich durch die Verwendung der Modellierungssprache EPK [HW08] auf
die Modellierung von Gescha¨ftsprozessen, bot aber keine Mo¨glichkeit fu¨r die
Ausfu¨hrung derselben. Des Weiteren lassen sich die Graphen des ABC mit
temporallogischen Formeln auf ihre Gu¨ltigkeit u¨berpru¨fen. Mit dem Model
Checking la¨sst sich bereits zur Modellierungsphase die geplante Anwendung
testen.
Steckten die Technologien und Architekturen fu¨r die Realisierung von komple-
xen Web-Applikationen Ende der Neunzigerjahre noch in den Kinderschuhen
oder wurden diese teilweise erst spa¨ter konzipiert, so hat man heute eine na-
hezu freie Auswahl im kommerziellen sowie im Open Source Bereich. Die Vor-
gehensweise der Softwareentwicklung hat sich u¨ber die Jahre gewandelt. So
musste noch vor einigen Jahren aufgrund von fehlender Software-Bibliotheken
und Standards vieles von Grund auf selbst entwickelt werden. Es waren im-
mer mehr proprieta¨re Lo¨sungen vorzufinden. Ein Beispiel ist die fu¨r den OCS
entwicklete Datenbankschicht, die direkt auf Basis der Datenbankschnittstelle
JDBC 1 [mic09j] realisiert wurde, wobei die Datenbankinteraktionen in den
Gescha¨ftsobjekten und Administratoren gekapselt wurden. Heutzutage wird
dem Entwickler mit der JPA 2 [BHRS07] [mic09e] eine Lo¨sung an die Hand
geben, welche die Applikation von der Datenbankschicht entkoppelt und die
Datebankkommunikation kapselt. Die Einfu¨hrung von Standards durch Ar-
beitsgemeinschaften, wie z.B. der OMG oder W3C, und die Wiederverwendung
von existierender Software erleichtert die Arbeit der Entwickler. Paradigmen
wie MDA und SOA haben einen entscheidenden Anteil an der aktuellen Soft-
wareentwicklung. Die heutige Verfu¨gbarkeit von Architekturen, Frameworks
und Sprachen wie z.B. Java EE [mic09d], .Net [Mic09b], Spring [OLW+08],
JBoss Seam [JBo09], JSF [mic09g], BPEL oder LDAP [Zo¨r08] [LU06], stellen
eine große Bandbreite von direkt verwendbaren Konzepten und Technologien
bereit.
Die Integration von Nicht-Programmierern und Endnutzern in die Anwen-
dungsentwicklung ist zu einem zentralen Punkt in der heutigen Softwareent-
wicklung geworden. Ein Beispiel fu¨r die einfache Unterstu¨tzung von Endnut-
zern sind Mashups [ZRN08, DLHPB09]. Mashup bezeichnet die Zusammenstel-
lung von existierenden Web-Inhalten oder Web-Applikationen. Hierzu dienen
Mashup-Editoren wie z.B. IBM Damia [SAM+08], Microsoft Popfly [Mic09a],
Yahoo Pipes [Yah09] oder Intel MashMaker [EG07], die den Benutzer wa¨hrend
der Kombination von existierenden Web-Applikationen grafisch durch Graph-
modelle oder Flussdiagramme unterstu¨tzen.
1Java Database Connectivity
2Java Persistence API
KAPITEL 8. DESIGN-ENTSCHEIDUNGEN 133
8.1 Technologische Ebene
Auf technologischer Ebene wurden im Laufe der Zeit A¨nderungen einerseits
aufgrund von neuen oder vera¨nderten Java-Bibliotheken, andererseits eines
zu hohen Wartungsaufwandes bzw. Vereinfachung des Installationsvorganges
durchgefu¨hrt. Nicht zu vergessen sind die fu¨r einen Benutzerdienst wichti-
gen konstruktiven Benutzervorschla¨ge (user feedback) fu¨r Verbesserungen oder
neue Features, die ebenfalls ihre Beru¨cksichtigung fanden.
Wa¨hrend der Entwicklung, Wartung und Weiterentwicklung wurde darauf ge-
achtet, dass der Dienst mit den neuesten Releases z.B. von Java, Java Servlet
und Tomcat arbeitet, um auf dem neuesten Stand zu bleiben und so neue
Bibliotheken verwenden zu ko¨nnen. Dadurch war gewa¨hrleistet, dass selbst
geschriebene Komponenten durch standardisierte Bibliotheken ersetzt werden
konnten, um so den eigenen Wartungsaufwand zu minimieren. Allerdings hatte
die Umstellung auf neue Releases bzw. die Aktualisierungen oder der Wechsel
des Betriebsystems zufolge, dass die vom Dienst genutzte Drittanbietersoftware
und die eigens dafu¨r implementierten Schnittstellen Anpassungen unterzogen
werden mussten. Betroffen waren z.B. die Speicherung der Dateien des Arti-
kels im Versionsverwaltungssystem CVS 3 oder die Diskussionskomponente auf
Basis eines Newsservers (INN2 4). Der Ru¨ckbau dieser Komponenten fu¨hrte
zur Verringerung des Wartungsaufwandes und in erster Linie zur erheblichen
Vereinfachung der Dienstinstallation.
Ein Beispiel fu¨r die Vera¨nderung der Technologie ist die Ersetzung von ei-
genen Implementierungen durch neue Bibliotheken, wie die implementierte
Komponente fu¨r das Lesen einer hochgeladenen Datei. Ende der neunziger
Jahre gab es noch keine freie Bibliothek, die multipart Anfragen ga¨nzlich
verarbeiten konnte. Diese Art von Anfragen u¨bertragen neben den einfachen
HTML-Elementen, Dateien, die der Dienstbenutzer per Browser mitschickt.
Die eigene Implementierung wurde im Hinblick auf die weitere Kompatibilita¨t
durch die spa¨ter erschienene Bibliothek Apache Commons FileUpload ersetzt.
Bei Neuentwicklungen von Diensten des OCS wurden ebenso neue Technolo-
gien wie z.B. Hibernate, GWT oder JSP eingesetzt.
Die komplexeren Features wie die Tagungsbandkomponente (PPS) (siehe Ka-
pitel 7.3) oder das Verwaltungsmanagement (MOS) (siehe Kapitel 7.1) mit zen-
tralem Zugriffspunkt (Single Point of Entry) auf die OCS- und OJS-Instanzen,
wurden als eigene Web-Anwendungen entwickelt. Fu¨r die Entwicklung wurden
verschiedene Vorgehensweisen verfolgt um die geeignetsten Technologien fu¨r
3Concurrent Versions System
4InterNetNews
KAPITEL 8. DESIGN-ENTSCHEIDUNGEN 134
den OCS zu evaluieren.
8.2 Feature Ebene
Aus der Sicht der Funktionalita¨ten wurde der Dienst im Laufe der Zeit durch
neue und gea¨nderte Features erweitert bzw. modifiziert.
Um die Support-Leistungen der Konferenzleitung zu minimieren wurde ne-
ben einer FAQ-Seite und einer Willkommensseite mit integrierter Workflow-
Anzeige, ein Help-Feature umgesetzt. Dieses Feature ist personalisiert in dem
Sinne, dass es dem Benutzer eine Hilfefunktion in Abha¨ngigkeit seiner Rechte
zeigt und fu¨r den Benutzer eine individuelle Hilfe anbietet.
Ein mitunter simples und heutzutage ga¨ngiges Feature war die fru¨he Einfu¨hrung
einer Komponente zur automatischen Einholung eines neuen Passwortes. Die
Konferenzleitung hatte zuvor einen erheblichen Support-Aufwand durch das
Vergessen von Passwo¨rtern.
Die Einfu¨hrung einer Ticketkomponente unterstu¨tzt die Diskussion im OCS,
durch Benachrichtigung aller, in einem Forum involvierten, Benutzer. Die-
ses beschleunigt den Diskussionsfluss, da die Diskussionsbeteiligten direkt per
Email u¨ber den Eingang einer neuen Nachricht erfahren und sie mittels des
mitgeschickten Tickets einen direkten Zugriff auf das relevante Forum erhal-
ten. Dadurch entfa¨llt das wiederholte Anmelden am Dienst. Daru¨ber hinaus
wird das Ticketsystem fu¨r die eigensta¨ndige Registrierung eingesetzt. Autoren
registrieren sich unter Zuhilfenahme der sich im o¨ffentlichen Bereich lokalisier-
ten Registrierungsseite. Um Missbrauch zu vermeiden erha¨lt der Benutzer ein
Ticket per Email, mit dem die Registrierung besta¨tigt werden muss.
Das Bidding-Feature, das im Kapitel 4.3 ausfu¨hrlich beschrieben wurde, war,
wie die Erfahrung besta¨tigt hat, eine wichtige Design-Entscheidung, die eine
erhebliche Arbeitsentlastung fu¨r die Konferenzleitung darstellt.
Um die Einbeziehung der Co-Autoren und der SubReviewer zu ermo¨glichen,
wurden die Grundfunktionalita¨ten erweitert. Co-Autoren sind dadurch von
Beginn an im Workflow integriert und ko¨nnen eingreifen, falls der Autor ver-
hindert ist. Ein weiterer Vorteil sind die dadurch bereits im Dienst existieren-
den Daten der Co-Autoren, die fu¨r die Erstellung des Tagungsbandes beno¨tigt
werden.
Durch die Umsetzung des SubDelegation Features wurden die Weiterdelegie-
rungen der Begutachtungsaufgaben von PC Membern an SubReviewer mit in
den Konferenzprozess aufgenommen. Sub-Delegierungen mu¨ssen nicht mehr
KAPITEL 8. DESIGN-ENTSCHEIDUNGEN 135
kompliziert am Dienst vorbei geschehen. Die SubReviewer sind somit bereits
im Dienst registriert und deren Daten ko¨nnen ebenfalls ohne gro¨ßeren Aufwand
fu¨r den Tagungsband verwendet werden.
Eine zusa¨tzliche Flexibilita¨t hat der OCS durch die Erweiterung des Benut-
zer/ Rollen-Rechtemodells (siehe Kapitel 4.2.1) mit dem personalisierten Rech-
temanagement (siehe Kapitel 4.2.3), sowie durch die konfigurierbaren Begut-
achtungsformulare (siehe Kapitel 4.4) und die konfigurierbaren Foren erhalten.
Durch die Konfigurierbarkeit dieser und weiteren Dienstfunktionalita¨ten ist es
mo¨glich, das Entscheidungssystem an die unterschiedlichsten Anforderungen
online anzupassen.
Grundlegende A¨nderungen am Kontrollfluss ko¨nnen graphbasiert durchgefu¨hrt
werden, wobei das umgesetzte Feature-basierte Konzept durch seine Struktu-
rierung und Klassifizierung der Features zu einer Vereinfachung beitra¨gt. Mit
dem entwickelten Service Status Report Feature (siehe Kapitel 5.3) und dem
History Feature (siehe Kapitel 5.3) wurde der Konferenzleitung gezielt ein
Monitoring-Werkzeug an die Hand gegeben, um den Verlauf der Konferenz
besser nachvollziehen zu ko¨nnen.
Kapitel 9
Einsatz der
Entscheidungssysteme
Die in dieser Arbeit beschriebenen Entscheidungssysteme finden ihre Ver-
wendung im wissenschaftlichen Bereich. Prima¨re Aufgabe ist es, mit defi-
nierten Prozessen bei Entscheidungsfindungen zielgerecht in Form einer Web-
Anwendung alle beteiligten Personen zu unterstu¨tzen. Es ist und soll nicht die
Aufgabe eines Entscheidungssystems sein, den Verantwortlichen die Entschei-
dungen abzunehmen. Es schla¨gt lediglich eine eventuelle Konstellation in Form
einer Rangliste vor, die auf Basis der Benotungen, der verfassten Gutachten
errechnet wird. Die Entscheidungen treffen in letzter Instanz die Verantwortli-
chen selbst. Dieses ist im Bereich der Konferenzen das Programmkomitee, das
sich aus den PC Chairs (Konferenzleitung) und den PC Members (Gutachtern)
zusammensetzt.
Im Folgenden wird auf die Einsatzbereiche der beschriebenen Entscheidungs-
systeme OCS, OJS, Transactions und LNCS eingegangen. Deren Aufgaben
umfassen die Vorbereitung von Workshops, Konferenzen und Fachzeitschriften
(Journals) sowie die eigentliche Entscheidungsfindung eines Verlages, die Er-
gebnisse in Form eines Buches oder einer Fachzeitschrift zu vero¨ffentlichen. So
genu¨gt z.B. nicht jede Konferenz den Anspru¨chen zur Vero¨ffentlichung, die ein
Verlag intern festlegt. Hierzu geho¨ren unter anderem die fachliche Ausrichtung
und die Qualita¨t der Veranstaltung aus denen die Artikel hervorgehen. Der
wirtschaftliche Aspekt, der sich durch das Publizieren von qualitativ hochwer-
tigen Konferenzen oder Journals durch die Verkaufszahlen widerspiegelt, ist
ebenfalls nicht zu vernachla¨ssigen.
Der OCS, Transactions und LNCS werden auf einem Springer-eigenen Server-
137
KAPITEL 9. EINSATZ DER ENTSCHEIDUNGSSYSTEME 138
Cluster von Springer SBM 1 in Dordrecht gehostet. Der OCS wird fu¨r Kon-
ferenzen angeboten [Hei09b], die zur Publikation beim Springer Verlag Hei-
delberg angenommen sind. Fu¨r die Entscheidungsfindung, wer bei Springer
LNCS [Hei09d] oder LNBIP 2 [Hei09d] publiziert, wird der LNCS-Dienst (sie-
he Kapitel 7.4) eingesetzt. Konferenzen, Workshops, etc. stellen Anfragen, die
mittels des Dienstes diskutiert werden. Der Transactions Dienst wiederum wird
vom Springer Verlag fu¨r die LNCS Transactions Subline [Hei09a] eingesetzt.
Transactions sind vergleichbar mit Journals, mit dem Unterschied, dass Tran-
sactions keine vorgeschriebenen Vero¨ffentlichungsintervalle aufzeigen und der
Workflow differiert.
Des Weiteren existiert ein Referenz-Cluster des von SBM Springer in Betrieb
genommenen Hochverfu¨gbarkeitsclusters (HA-Cluster) des OCS am Lehrstuhl
fu¨r Programmiersysteme der TU Dortmund. Dieses dient zur Entwicklung und
fu¨r die Testphasen von Release-Kandidaten, bevor diese auf das Live-Cluster
gespielt werden. Am Lehrstuhl selbst werden OCS- sowie OJS-Dienste geho-
stet, die fu¨r Konferenzen und Journals eingesetzt werden, wodurch ein geplan-
tes Release einem Test unter realen Bedingungen unterzogen werden kann.
Das OCS Server-Cluster ist als Hochverfu¨gbarkeitscluster (HA-Cluster) kon-
zipiert worden, um eine maximale Ausfallsicherheit zu gewa¨hrleisten. Dieses
wurde mitunter durch Redundanz von Hardware und Software erreicht. Swit-
ches, Verkabelungen und die Server fu¨r die Datenbanken, den Webzugriff und
das Filesystem wurden redundant ausgelegt. Daten der Datenbanken oder des
Filesystems werden auf einem SAN Storage abgelegt, das gesichert ist. Die
Fileserver werden von einer Clustersoftware verwaltet und die Datenbanken
repliziert. Beim Ausfall eines Applikationsserver, auf denen die Dienstinstan-
zen laufen, wird automatisch ein sich im Standby befindender Server akti-
viert, der die Aufgaben des ausgefallenen Servers u¨bernimmt. Fu¨r die Admi-
nistration, das Monitoring und die Hochverfu¨gbarkeit wird das System Ma-
TRICS 3 [BM08, BM06, BMS06] eingesetzt, das ebenfalls auf das modellge-
triebene Konzept basiert.
Die Entscheidungssysteme wurden bislang fu¨r 168 internationale Veranstal-
tungen mit insgesamt u¨ber 30.000 Benutzern eingesetzt. Der gro¨ßte Anteil ist
dem OCS zuzuordnen, der die Vorbereitung und ggf. Nachbearbeitung von
Konferenzen unterstu¨tzt. Die Journals, die teilweise auf einer Auslese von an-
genommen Artikel der ausgewa¨hlten Konferenzen aufbauen, werden hingegen
mittels des OJS umgesetzt. Die Artikel werden mit anderen auserlesenen Arti-
1Springer Science+Business Media, Dordrecht, Niederlande
2Lecture Notes in Business Information
3Management Tool for Remote Intelligent Configuration of Systems
KAPITEL 9. EINSATZ DER ENTSCHEIDUNGSSYSTEME 139
keln nochmals diskutiert, um diese in einem Journal (special issue) zu vero¨ffent-
lichen. Verwaltete Konferenzen sind z.B. TACAS 4 eine in der Wissenschafts-
gemeinschaft bekannte Veranstaltung der ETAPS 5, ATPN 6, oder ADMA 7,
eine in China stattfindende Konferenz. Eine U¨bersicht der bislang durch die
Dienstfamilie unterstu¨tzten Veranstaltungen ist in Tabelle 9.1 zusammenge-
stellt.
4Tools and Algorithms for the Construction and Analysis of Systems
5European Joint Conferences on Theory and Practice of Software
6International Conference on Application and Theory of Petri Nets
7International Conference on Advanced Data Mining And Applications
KAPITEL 9. EINSATZ DER ENTSCHEIDUNGSSYSTEME 140
Jahr Konferenzen - Journals - Workshops
2000 TACAS
2001 CHARME, EMODELS, SoftwareTrends, SPIN, STTT, TACAS
2002 CAV, ESOP, FASE, FMICS, IDPT, SPIN, STTT
2003 CC, CHARME, FASE, FME, FOSSACS, STTT, STTT-CHARME,
STTT-FASE, TACAS
2004 AVOCS, CC, CPN, ESOP, FASE, FOSSACS, ICECCS, ICWE,
ISOLA, SMTT, SPIN, STTT, STTT-FASE, STTT-FML, STTT-
SMTT, STTT-VMCAI, TACAS, TOOLTACAS, STTT-TACAS,
VMCAI
2005 ATPN, CALCO, CC, DARPA, ESOP, FASE, FM, FOSSACS,
FMICS, FMICS-HB, ISOLA, LNCS-ISOLA, Perf-QUANT-STTT-
ISOLA, SPIN, STTT, STTT-CPN, STTT-FASE, STTT-FMICS,
STTT-ISOLA, TACAS, TCS-ISOLA, TOOLTACAS, TSDPS, WRAC
2006 ATAV, ATPN, CC, ESOP, FASE, FM, FMICS, FOSSACS, FRCSS,
ISOLA, ISOLA-TRACKS, LNCS, LNBIP, MDA, PEPM, SEW, SC
SPIN, STTT, STTT-SFB614, STTT-SPIN, TACAS, TGC, WRAC
2007 ATPN, CALCO, CS, DASC, DHMS, FASE, FMICS, FOSSACS,
ISOLA, JODS, PLOP, ROUGHSETS, SEFM, SEW, SPIN, STTT,
STTT-FMICS, STTT-HVC, STTT-SPIN, STTT-TACAS, STTT-
T3UC, STTT-WQVV, SWSC-BOOK, TACAS, TOE, TOPNOC
2008 AAIM, ATPN, BICC, EUROHAPTICS, FASE, FMICS, ICECCS,
ICSOC, ISOLA, PCM, SAFECERT, SEW, SSSPR, STTT,
STTT-GRABATS, STTT-TTCN, TACAS, WASA
2009 AdHocNow, ADMA, ALT, COCOA, DPM-SETOP, DS, EUROSSC,
HAID, ICA, ICONIP, ICSR, ISAAC, ISCLS, ISOLA-BIO, ISOLA-
MED, IWSOS, PN, PReMI, ProvSec, PRIMA, RSFDGrC,
SAFECERT, SAGA, SEFM-NGN, SMTEB, STTT, STTT-VSTTE,
STTT-WSE, TACAS, TAMODIA, ...
Tabelle 9.1: Einsatz der Dienstfamilie - Veranstaltungen
Kapitel 10
Fallstudie: Verwendung des OCS
Ein System, das Tausenden von Benutzern zur Verfu¨gung steht und diese bei
ihrer kooperativen Zusammenarbeit unterstu¨tzt lebt von der Zufriedenheit
der Benutzer. Die Ru¨ckmeldungen (feedback) der Benutzer nehmen, neben den
eigenen Erfahrungen, eine zentrale Stellung in der Kunden-orientierten Ent-
wicklung von Systemen ein. Um einen genaueren Einblick in die Benutzung
eines Systems zu erlangen, insbesondere der einzelnen Dienstfunktionalita¨ten
(Features), reichen diese Informationen mit unter nicht aus. Sollen Aussagen
explizit u¨ber die Nutzung der Features gemacht werden bedarf es einer ge-
naueren Untersuchung. Es lassen sich durch die Analyse Ru¨ckschlu¨sse auf die
zentralen Features und die eventuelle Notwendigkeit der Modifikation dersel-
bigen oder des Workflows ziehen. Dieses kann der Falls sein, wenn ein Feature
durch einen sehr hohen Benutzungsgrad, die ihm untergeordneten Features
blockiert und sich somit als Engpass herausstellt.
Die Betrachtung der einzelnen Features ist insofern wichtig, da diese die Palet-
te von wiederverwendbaren Komponenten repra¨sentieren. Eine Verbesserung
eines Features la¨sst sich somit auch in allen Diensten, in denen es verwen-
det wurde, auf einfache Weise u¨bernehmen bzw. in neuen Diensten durch den
Feature-orientierten Ansatz leicht hinzufu¨gen.
Ein weiterer wichtiger Aspekt ist der Vergleich von verschiedenen Konferenzen
im Bezug auf die Verwendung der Features und somit der Workflows. Dieses
gibt einen Einblick in die Allgemeingu¨ltigkeit von Workflows. Diese Art von
Studie erzeugt Fakten u¨ber die Einfu¨hrung neuer oder gea¨nderter Features.
So lassen sich Design-Entscheidungen durch den Vergleich von Fallstudien auf
ihren Erfolg hin u¨berpru¨fen. Des Weiteren zeigt die Studie Arbeitsprofile, was
fu¨r den Aspekt des Supports entscheidend ist.
141
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 142
Dieses Kapitel dient einerseits zur Analyse der Nutzung der Features und an-
dererseits zur Untersuchung des Systems in Bezug auf die Ergonomie. Es wird
eine aktuelle Studie vorgestellt, die auf die im Jahr 2002 durchgefu¨hrte und
publizierte [MK02] Bezug nimmt.
10.1 Hintergrund
Betrachtet wird die Verwendung der Features am Anwendungsfallbeispiel OCS.
Die Ergebnisse von drei Konferenzen werden untereinander verglichen und der
fru¨heren Studie gegenu¨bergestellt. Dabei sollen Kenntnisse u¨ber vera¨nderte
Workflows und bestehende bzw. neue Features erlangt werden.
Zur Laufzeit der Konferenzen werden Aktivita¨ten des Dienstes in ein festgeleg-
tes Format gespeichert. Dieses sogenannte Logfile entha¨lt verschiedene Arten
von Eintra¨gen, die dem nachstehenden Muster entsprechen:
<date and time><logtype><operation description><operation id>
Dabei steht
• <date and time> fu¨r den Ausfu¨hrungszeitpunkt der Operation,
• <logtype> spezifiziert den Typ des Protokollierungseintrages,
• <operation description> beschreibt die durchgefu¨hrte Operation und
• <operation id> kennzeichnet die Operation.
Der nachstehende Logfile-Eintrag weist einen Zugriff auf das User Features des
OCS auf.
25.06.09 15:59 DEBUG executing code of SIB ShowUserList
Der Eintrag ist vom Typ DEBUG und ha¨lt die Ausfu¨hrung eines SIB fest, der fu¨r
die Darstellung der Benutzerliste zusta¨ndig ist. Diese Art von Informationen
bilden die Daten fu¨r die Untersuchung des OCS.
Neben dem Typ DEBUG existierenden noch eine Reihe von Log-Eintra¨gen,
die allerdings nicht fu¨r diese Fallstudie relevant sind. Aufgrund dessen werden
die Rohdaten in zwei Schritte fu¨r die eigentliche Auswertung aufbereitet.
Im ersten Schritt werden alle relevanten Log-Eintra¨ge des Typs DEBUG extra-
hiert um aus deren Informationen die stu¨ndlichen, wo¨chentlichen und gesamten
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 143
Aufrufe eines jeden SIBs zu berechnen. Im zweiten Schritt werden die bereits
berechneten Daten ausgewertet. SIBs werden einem Feature zugeordnet und
im CSV 1-Format wie folgt gespeichert:
Weekly,Mo,Di,Mi,Do,Fr,Sa,So,Total
Feature articles,823,628,559,1240,1631,426,695,6002
Feature bidding,45,46,62,87,29,38,35,342
Feature forum,1341,1154,1014,1354,437,216,464,5980
In dem Beispiel sind die wo¨chentlichen Zugriffe auf die Features Articles, Bid-
ding und Forum aufgelistet, die zur Auswertung und grafischen Aufbereitung
beno¨tigt werden.
10.2 Ergebnisse
Analysiert werden die Dienste FASE 2 2008 (ETAPS Konferenz), ICA 2009 3
und TACAS 2009 (ETAPS Konferenz). Tabelle 10.1 beinhaltet die Eckdaten
der Dienste, die auf dem Springer-eigenem OCS-Cluster gehostet wurden.
 
Data \ Conferences FASE'08 ICA'09 TACAS'09 total 
Chairs 2 7 2 11 
Committee ( PCC & PCM) 30 51 29 110 
SubReviewers 61 15 88 164 
Authors | Submissions 153 134 131 418 
CoAuthors 216 203 231 650 
Users 460 359 479 1298 
Period [d] 108 101 113   
Logfile [MB] 408 451 613 1472 
 
 
Tabelle 10.1: Fallstudie - Eckdaten der analysierten Dienste
Die Fallstudie umfasst die in der Tabelle 10.1 gelisteten Konferenzen mit ins-
gesamt 1298 Benutzern und 418 eingereichten Artikeln. Werden die ETAPS-
Konferenzen FASE und TACAS na¨her betrachtet so haben sich die Einrei-
1Comma-Separated Values
211th International Conference on Fundamental Approaches to Software Engineering
38th International Conference on Independent Component Analysis and Signal Separa-
tion
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 144
chungen bei FASE von 2002 bis heute verdreifacht und die Anzahl der Dienst-
benutzer versiebenfacht. Tabelle 10.2 zeigt diesen Sachverhalt. Die mit einem
Trennstrich markierten Felder weisen Konferenzen auf, die nicht mit dem OCS
durchgefu¨hrt wurden.
FASE TACAS
Jahr Einreichungen Benutzer Einreichungen Benutzer
2000 - - 140 157
2001 - - 129 147
2002 56 71 - -
2003 97 112 154 180
2004 98 181 145 242
2005 101 184 167 308
2006 137 241 161 305
2007 141 581 204 660
2008 153 488 174 601
2009 - - 131 533
Tabelle 10.2: Fallstudie - FASE und TACAS Historie
Die Zunahme der Dienstbenutzer ist von mehreren Kriterien abha¨ngig:
• Die zunehmende Gro¨ße des Komitees.
• Die Anzahl der Submissions und die daraus folgende Anzahl an Autoren
und CoAutoren.
• Die Anzahl der SubReviewer, die hinzukommen, falls die Weiterdelegie-
rung von Gutachten aktiv ist.
Die CoAutoren wurden vorher nur mit deren Namen angegeben und nicht als
ein Dienstbenutzer gefu¨hrt. Heutzutage ko¨nnen diese von den Autoren regi-
striert werden und explizit das Recht zum Einloggen erhalten, um wie der
eigentliche Autor zu agieren, wobei die Rechte fein justierbar sind. Dasselbe
gilt im Bereich der SubReviewer, die ebenfalls als Benutzer im Dienst aufge-
nommen wurden, damit der Prozess der Weiterdelegierung transparent fu¨r die
Konferenzleitung wird. In Tabelle 10.2 ist die Einfu¨hrung des SubReviewing
im Jahre 2003 und die Aktivschaltung des CO-Author-Workflows im Jahre
2006 deutlich an den im darauffolgendem Jahr gestiegenen Benutzerzahlen zu
erkennen.
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 145
10.2.1 Benutzungsstatistik
Die Benutzung des Dienstes und somit die Arbeitsprofile der Benutzer der
jeweiligen Konferenz lassen sich anhand von Benutzersitzungen aufzeigen, die
durch die erfolgreichen Anmeldevorga¨nge (logins) reflektiert werden. TACAS
ist mit 6779 Logins die aktivere Konferenz im Vergleich zu FASE mit 4022
und ICA mit 3980 Logins (siehe Tabelle 10.4). Die Abbildung 10.1 stellt die
aktiven Benutzersitzungen pro Wochentag prozentual dar.
Logins(daily, percentual per conference)
0
5
10
15
20
25
%
FASE2008 18,1 18,6 11,4 10,9 23,2 12,1 5,7
ICA2009 22,9 21,5 17,6 11,2 13,6 4,8 8,4
TACAS2009 19,6 13 12,4 21,5 18,8 5,7 9
Monday Tuesday Wednesday Thursday Friday Saturday Sunday
 
Abbildung 10.1: Fallstudie - Prozentuale Benutzung der Konferenzen: ta¨glich
FASE und ICA stimmen von der Tendenz des Verlaufs der ta¨glichen Logins
bis auf den Dienstag u¨berein. TACAS folgt ebenfalls dem Verlauf mit einer
Ausnahme am Donnerstag mit entgegengesetztem Trend. Die meisten Benut-
zersitzungen gab es am Montag mit 2965 und am Freitag mit 2749. Dieses
zeigt eine Arbeitsweise, die den Montag fu¨r die Nacharbeitung des Wochen-
endes und zur Vorbereitung der anfangenden Woche nutzt. Der Freitag dient
dabei zur Nacharbeitung der Woche und Vorbereitung des Wochenendes. Aus
der Erfahrung bekannt ist der Freitag ein beliebter Tag fu¨r Deadlines, wie z.B.
der letzte Tag fu¨r die Einreichung der Artikel. Dieses beeinflusst mitunter die
Spitzen im Diagramm. Es ist ein hohes Maß an Aktivita¨t am Wochenende fest-
zustellen (Samstag 1067 und Sonntag 1170), was fu¨r Samstag wie Sonntag ein
gutes Drittel im Vergleich zum aktivsten Tag dem Montag ist. Die Wochen-
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 146
endaktivita¨t bewegt sich somit zwischen 13,2 % und 17,8 %. Diese zeigt die
Notwendigkeit eines Systems, das 24x7 Verfu¨gbarkeit aufweist. Der Support
kann auf Basis einer solchen Studie und den Erfahrungen geplant werden.
Die Abbildung 10.2 stellt die Konferenzen FASE’02 und FASE’08 gegenu¨ber.
Logins(daily, percentual per conference)
0
5
10
15
20
25
30
%
FASE2002 14,9 12,6 28,3 25,4 13,8 2,6 2,4
FASE2008 18,1 18,6 11,4 10,9 23,2 12,1 5,7
Monday Tuesday Wednesday Thursday Friday Saturday Sunday
 
Abbildung 10.2: Fallstudie - Vergleich FASE’02 und FASE’08: ta¨glich
Die ta¨gliche Darstellung zeigt fu¨r FASE’02 eine Glockenkurve, wobei der Mon-
tag mehr Aktivita¨t als der Dienstag aufweist. Die Aktivita¨ten von FASE’08
zeigt ein unterschiedliches Verhalten auf. Fa¨llt die Hauptaktivita¨t von FA-
SE’02 auf den Mittwoch und Donnerstag, so sind die Haupttage fu¨r FASE’08
am Anfang und Ende der Arbeitswoche zu finden. Auffa¨llig ist die um mehr als
das Dreifache gestiegende Arbeitsbereitschaft am Wochenende der aktuelleren
Konferenz mit 17.8 % zu 5 % im Jahre 2002. Dieses kann auf die Vera¨nderung
des Komitees zuru¨ckgefu¨hrt werden.
Die in Abbildung 10.3 gezeigte stu¨ndliche Verteilung der Konferenzen FA-
SE’08, ICA’09 und TACAS’09 weist im Zeitraum von 9 Uhr bis 20 Uhr mit
65,6 % die meisten Aktivita¨ten auf. Dieser Zeitraum ist mit den um eine Stun-
de verschobenen Arbeitszeiten in Europa vergleichbar. Die hohe Aktivita¨ten in
den Abend- und Nachtstunden ist auf Forscher aus anderen Zeitzonen, wie z.B.
den USA, zuru¨ckzufu¨hren. Wird der Zeitraum von 1 Uhr bis 9 Uhr Morgens be-
trachtet, finden 14,2 % der Gesamtaktivita¨ten in der europa¨ischen Nacht statt.
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 147
Der Zeitraum von 20 Uhr bis 1 Uhr bestimmt 20,2 % der Gesamtaktivita¨ten.
Logins(hourly, percent)
0
2
4
6
8
10
12
%
FASE2008 2,9 1,8 1,8 1,3 1 1,2 1,5 1,8 2,6 6 6,4 6,9 5,9 4,6 5,9 9,8 6,2 6 5,5 6,1 4,6 3,4 3,5 3,3
ICA2009 3 2,6 1,8 1,5 1,7 1,6 1,4 2,2 3,1 5,5 5,5 5 4,7 6 6,6 6,7 5,7 6,7 6,6 5,5 4,8 4,8 4,3 2,7
TACAS2009 3,1 1,9 1,8 1,6 1,2 1,6 1,1 1,7 2,7 5,5 7,2 6,3 4,6 5,1 6 6,5 6,9 7 4,5 3,3 4,7 6,3 5,3 4,1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
 
Abbildung 10.3: Fallstudie - Prozentuale Benutzung der Konferenzen: stu¨ndlich
Werden die stu¨ndlichen Auswertungen von FASE’08 mit FASE’02 verglichen,
siehe Abbildung 10.4, ist ein a¨hnlicher Verlauf der Aktivita¨ten festzustellen.
Allerdings sind die Aktivita¨ten am spa¨ten Abend und in der Nacht fu¨r FASE’08
ausgepra¨gter, da das im Jahre 2002 reine europa¨ische Komitee heutzutage
5 Mitglieder aus den USA und eins aus Kanada beinhaltet. Waren es 2002
1745 Logins wa¨hrend der Konferenzlaufzeit sind es 2008 aufgrund der ho¨heren
Benutzerzahlen 4022 gewesen.
10.2.2 Feature-Statistik
Im Folgenden wird auf die Verwendung der Dienst-Features eingegangen. An-
hand dieser Statistik kann erkannt werden, ob und wie oft ein Feature zum
Einsatz kam. Die Tabelle 10.3 beinhaltet die Auswertung der Features der be-
trachteten Konferenzen. Dabei steht PCC fu¨r PC Chair, PCM fu¨r PC Member,
SR fu¨r SubReviewer und A for Author. Es werden die gesamten Zugriffe auf
ein Feature, die prozentuale Anteil und die durchschnittliche Benutzung eines
Features von einem Benutzer aufgelistet. Die Nullwerte in der Tabelle besagen,
dass ICA sowohl das Bidding sowie das Forum Feature nicht benutzt hat. ICA
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 148
Logins(hourly, percent) 
0
2
4
6
8
10
12
%
FASE2002 1 0,8 1,1 1 0,2 0,5 0,4 0,4 5,2 5,7 7,9 6,1 7,2 9,3 7,4 7,7 9,2 8,5 6,4 3,7 3,4 1,7 1,4 3,8
FASE2008 2,9 1,8 1,8 1,3 1 1,2 1,5 1,8 2,6 6 6,4 6,9 5,9 4,6 5,9 9,8 6,2 6 5,5 6,1 4,6 3,4 3,5 3,3
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
 
Abbildung 10.4: Fallstudie - Vergleich FASE’02 und FASE’08: stu¨ndlich
hat ein reines reales PC-Treffen (PC Meeting) unter Verwendung des Evalua-
tion-Features durchgefu¨hrt.
Nachstehend werden einige der aufgelisteten Feature aufgrund ihrer Ergebnisse
diskutiert.
Das Article-Feature ist mit im Durchschnitt 34,8 % aller Zugriffe auf die drei
Konferenzen das meist genutzte Feature der betrachteten Entscheidungsdien-
ste. Es wird gefolgt vom Forum mit 30 % und der Tasklist mit 16,5 %. Im
Vergleich zu FASE’02 ist die durchschnittliche Nutzung des Article-Features
durch einen Benutzer (apu) von 78 auf 15 Zugriffe gesunken. Dieses liegt mit
unter an der Einfu¨hrung des Bidding-Features.
Das Bidding-Feature erleichtert die Verteilung der Begutachtungsaufgaben
und reduziert die Last der Konferenzleiter und des Article Feature, da der
im Article-Feature eingeordnete Delegierungsworkflow nur noch teilweise zum
Einsatz kommt. Das Feature wurde von FASE’08 und TACAS’09 erfolgreich
eingesetzt.
Das Evaluation-Feature wurde mit 4,1 % am ha¨ufigsten von TACAS einge-
setzt, was als Konsequenz aus der regen Diskussionsbereitschaft von 28,9 %
zu sehen ist. Die Zwischen- und Endergebnisse der Diskussion werden von der
Konferenzleitung in die Evaluationmatrix u¨bertragen. Dieses geschieht durch
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 149
FASE2008 ICA2009 TACAS2009 Feature Roles 
users total % apu users total % apu users total % apu 
Articles PCC,PCM,A 183 2823 24,2 15 185 4352 51,2 24 160 6002 29 38 
Bidding PCC, PCM 30 243 2,1 8 51 0 0 0 29 342 1,7 12 
Conflicts PCC 2 20 0,2 10 7 43 0,5 6 2 69 0,3 35 
Delegation PCC, PCM 30 172 1,5 6 51 217 2,6 4 29 430 2,1 15 
Email PCC 2 31 0,3 16 7 110 1,3 16 2 137 0,7 69 
Evaluation PCC,PCM 30 358 3,1 12 51 142 1,7 3 29 852 4,1 29 
Forum PCC,PCM 30 3628 31,1 121 51 0 0 0 29 5980 28,9 206 
Preferences PCC, PCM 30 243 2,1 8 51 269 3,2 5 29 288 1,4 10 
Profile PCC,PCM,A 183 243 2,1 1 185 367 4,4 2 160 381 1,8 2 
Reports PCC,PCM 30 862 7,4 29 51 412 4,8 8 29 1730 8,4 60 
Roles PCC 2 33 0,3 17 7 55 0,7 8 2 62 0,3 31 
Setup PCC 2 96 0,8 48 7 268 3,2 38 2 135 0,7 68 
Staff PCC, PCM 30 186 1,6 6 51 249 2,9 5 29 246 1,2 8 
Tasklist PCM, SR 117 2242 19,2 19 59 1314 15,5 22 169 3072 14,9 18 
Users PCC 2 475 4,1 238 7 699 8,2 100 2 942 4,6 471 
total     11655 100 554   8497 100 241   20668 100 1072 
apu indicates the average usage per user    u = users  
 
Tabelle 10.3: Fallstudie - Statistik der Feature
das Setzen des Artikels in den entsprechenden Status. In Abha¨ngigkeit der in
2002 berechneten Benutzung des Evaluation-Features und die hohe Akzeptanz
des Features wurde die Forumkomponente als ein Hauptfeature in das Ent-
scheidungssystem integriert. Diese Design-Entscheidung hat zur Verbesserung
der Ergonomie beigetragen.
Der hohen apu-Werte des Forum-Features kennzeichnet dieses als besonders
wichtig fu¨r die Konferenzen FASE und TACAS. Die Gesamtzugriffszahlen von
FASE mit 3628 und TACAS mit 5980 weisen auf eine rege Diskussion zur
Festlegung der angenommenen bzw. abgelehnten Artikel hin. Mit einem apu-
Wert von 121 fu¨r FASE und 206 fu¨r TACAS geho¨rt das Forum-Feature mit zu
den meist genutzten Features.
Das User-Feature ist fu¨r den PC Chair ein ha¨ufig verwendetes Feature. Die
Studie von 2002 zeigte fu¨r FASE’02 einen apu-Wert von 635 und fu¨r die eben-
falls analysierte Konferenz ESOP’02 von 1072. Dies war der Anlass die Nach-
frage fu¨r ein neues Passwort zu automatisieren. Die in spa¨terer Kombination
mit dem Ticketsystem, das direkte Einstiege in das System ermo¨glicht, ließ
die Benutzung des User-Features von 13,3 % (in 2002) auf heutige 4,1 % sin-
ken. Fu¨r die PC Chairs stellt dies eine erhebliche Arbeitserleichterung dar,
weil diese als alleinigen Benutzer des Features angesehen werden ko¨nnen. Die
eventuelle Beinflussung durch die Administratorrolle ist aufgrund des sehr ge-
ringen Aktivita¨ten zu vernachla¨ssigen. Die Einfu¨hrung des Ticketsystem hat
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 150
den Workflow im ergonomischen Sinne aufgewertet.
Die TACAS Konferenz erweist sich bei der Verwendung des Setup-Features
(apu 68) und Role-Features (apu 31)als die aktivere Konferenz in Bezug auf
die Anpassung des Dienstes an die Konferenz. Die Auswertung der beiden
Features zeigt bei allen drei Konferenzen die Ausnutzung des flexiblen, zur
Laufzeit konfigurierbaren Ansatzes des Entscheidungssystems.
10.2.3 Konferenzstatistik
Nach der Veranschaulichung der Benutzungs- und Feature-Statistik wird in
diesem Kapitel kurz auf die globalen Ergebnisse der Konferenzen eingegangen.
In Tabelle 10.4 sind die wesentlichen Daten zur Diskussion zusammengefasst.
Data FASE'08 ICA'09 TACAS'09 
Logins 4022 3980 6779 
Automatic Emails 3029 615 3302 
Uploads 281 333 448 
Downloads 913 1146 1761 
SubReports 95 28 119 
Reports 364 346 407 
Final Reports 118 134 131 
News (post) 387 0 448 
News (read) 3241 0 5532 
News total use 3628 0 5980 
Pwd.  Changes 6 20 11 
Users 494 366 579 
PWD Index[%] 1,2 5,5 1,9 
 
 
Tabelle 10.4: Fallstudie - Globale Daten der Konferenzen
TACAS war eine sehr umfangreiche und aktive Konferenz, die mit 6779 Logins
vor FASE mit 4022 und ICA mit 3980 liegt. An der sehr hohen Benutzung des
Forum-Features zeigt sich eine rege Diskussion bei der Festlegung u¨ber An-
nahme oder Ablehnung der begutachteten Artikel. Mit 448 Postings und einer
Gesamtnutzung des Features von 5980 Zugriffen liegt TACAS vor FASE (387,
3628). Auffa¨llig ist die hohe Anzahl von 1761 Artikel die heruntergeladenen
wurden. Dies kann mit der Einreichung von neueren Versionen eines Artikels
durch die Autoren zusammenha¨ngen, die erneut von den Gutachter herun-
tergeladen worden sind. Mit 579 Benutzern ist TACAS ebenfalls die gro¨ßte
Konferenz vor FASE (494) und ICA (366). Die hohe Anzahl von 3302 versen-
deten Emails umfassen neben den Benachrichtigungen an den PC Chair u¨ber
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 151
den bevorstehenden Ablauf einer Konferenzphase, hauptsa¨chlich die Warnun-
gen u¨ber verstrichene Begutachtungstermine seitens der Gutachter. 119 Sub-
Reports besta¨tigen die Akzeptanz des Workflows zur Weiterdelegierung der
Gutachten.
Auffa¨llig sind 407 Reports bei TACAS mit 131 Artikeln im Vergleich zu ICA
mit 346 Reports fu¨r 153 Artikel. Dieses bedeutet eine ho¨here Anzahl von Gut-
achtern pro Artikel auf Seiten von TACAS. Bei ICA wurde die Weiterdele-
gierung mit 28 an der Zahl nur gering eingesetzt. Die geringe Anzahl von
615 Benachrichtigungsemails (Automatic Emails) weist auf eine organisierte
Begutachtungsphase hin, in der sich die Gutachter an die Termine fu¨r die Ab-
gabe der Gutachten gehalten haben. Die Diskussion u¨ber die Artikel wurde
ga¨nzlich wa¨hrend des Komiteetreffens (PC meeting) durchgefu¨hrt.
FASE verfu¨gt mit 153 Artikel u¨ber die meisten Einreichungen, vor ICA mit 134
und TACAS mit 131 Artikeln. Die hohe Anzahl der automatisch veschickten
Emails zeigt wie bei TACAS eine vielfache U¨berschreitung von Begutachtungs-
terminen auf. An den hohen Werten bzgl. des Forum-Features ist auch hier eine
rege Diskussion festzustellen.
10.3 Fazit
Wie zu Beginn dieses Kapitels erwa¨hnt, lassen sich aus der Durchfu¨hrung einer
solchen Studie verschiedene Erkenntnisse gewinnen. Dieses ist unter anderem
die Auslastung eines Konferenzdienstes durch die Anzahl der Dienstbenutzer
und die daraus notwendige Dimensionierung des Server-Clusters. Die Anzahl
der Dienstbenutzer liegt im Durchschnitt bei 500 Benutzern pro Konferenz,
wie in Tabelle 10.2 zu sehen ist, und durch weitere a¨hnlich dimensionierte
Konferenzen besta¨tigt wird. Die Erho¨hung der Anzahl der Benutzer ha¨ngt mit
steigenden Einreichungszahlen und die direkte Integration von Co-Autoren
(im Jahr 2006) und SubReviewern (im Jahr 2003) in den Begutachtungspro-
zess zusammen, was an den gestiegenden Benutzerzahlen des darauffolgendem
Jahr zu erkennen ist. Zum anderen wird durch die Auswertung der ta¨glichen
und wo¨chentlichen Benutzung der Konferenzendienste aufgezeigt, wie notwen-
dig eine durchgehende 24x7 Verfu¨gbarkeit der Dienste ist. Das wird einerseits
durch die Aktivita¨tsverteilung u¨ber den Tag mit 65,6 % von 9 Uhr bis 20
Uhr, mit 20,2 % von 20 Uhr bis 1 Uhr und mit 14,2 % von 1 Uhr bis 9 Uhr
und andererseits durch eine Wochenendaktivita¨t von 13,2 % bis 17,8 % der
Gesamtwochenaktivita¨t untermauert.
Eine weitere Erkenntnis ist die Akzeptanz der Features und eventuell ein-
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 152
hergehenden A¨nderungen von Design-Entscheidungen. Eine wichtige Stellung
nimmt die Beobachtung ein, wie der Dienst auf unterschiedliche Weise ein-
gesetzt wird. Features ko¨nnen anhand der Anzahl von Benutzungen festge-
macht und im Hinblick auf die Wichtigkeit klassifiziert werden. So wird die
Einfu¨hrung des Workflows zur Weiterdelegierung der Gutachten an SubRe-
viewer mit einer Gesamtzahl von 242 SubReports besta¨tigt und von den PC
Membern sehr gescha¨tzt.
Ein weiteres zentrales Feature ist das Forum-Feature, das im Jahre 2000 von
mir auf Basis eines News-Servers 4 und dem Protokoll NNTP 5 als Graphmo-
dell umgesetzt und in den OCS integriert wurde. Die Integration einer Diskus-
sionkomponente in ein Begutachtungssystem revolutionierte den Prozess der
Entscheidungsfindung u¨ber Annahme bzw. Ablehnung der eingereichten Arti-
kel und nahm lange Zeit eine Vorreiterstellung ein. Stellten die PC-Meetings
zur Feststellung der zu akzeptierenden Artikel einen sehr hohen Kostenfak-
tor und Zeitaufwand dar, konnte die Entscheidungsfindung fortan integriert
im OCS stattfinden. Zugriffe auf die einzelnen Foren, jeder Artikel hat sein
Eigenes, konnten gezielt freigeschaltet werden, wobei der Dienst bereits auto-
matisch die jeweiligen Rechte setzte. Die Umsetzung einer integrierten Kompo-
nente zur virtuellen Durchfu¨hrung von PC-Meetings senkte den Kosten- und
Zeitaufwand fu¨r das Komitee und fu¨hrte zu einer beschleunigten und zielge-
richteten Entscheidungsfindung. Das Forum-Feature erfreute sich sehr schnell
gro¨ßter Beliebtheit [MK02] und wird weiterhin fu¨r das virtuelle PC-Meeting
eingesetzt, siehe Tabelle 10.3. Kommunities, die ihre PC-Meetings nach wie vor
physikalisch durchfu¨hren, verwenden das Forum-Feature um Vorentscheidun-
gen zu treffen, die Grundlage eines verschlankten physikalischen PC-Meetings
sind. Der große Nutzen und Erfolg hatte dazu beigetragen, dass die Idee einer
integrierten Diskussionskomponente durch die Entwickler anderer Begutach-
tungssystemen aufgegriffen wurde und sich zum Standard-Feature entwickelte.
Die aufgezeigte Umstrukturierung der Feature-Hierarchie im OCS in Bezug auf
das Forum-Feature hat einen weiteren Schritt in Richtung einer guten Ergo-
nomie des OCS bedeutet. Das Forum-Feature wurde zu einem Haupt-Feature
umgewandelt, so dass es in Kombination mit dem eingefu¨hrten Ticketsystem zu
den meist genutzten Feature geworden ist. Dieses ist durch einem apu 6-Wert
von 121 fu¨r FASE und 206 fu¨r TACAS in Tabelle 10.3 dokumentiert. Der apu-
Wert ist von 39 fu¨r FASE’02 auf 121 fu¨r FASE’08 gestiegen, was eine Erho¨hung
der Benutzung des Forum-Features unterstreicht. Ein anderes Beispiel fu¨r die
Akzeptanz einer solchen Studie ist die Benutzung des User-Features von 13,3
4INN: InterNetNews
5Network News Transfer Protocol
6Durchschnittliche Benutzung eines Features pro Benutzer.
KAPITEL 10. FALLSTUDIE: VERWENDUNG DES OCS 153
% in FASE’02, die durch eine daraufhin stattgefundene Umsetzung einer auto-
matischen Passwortvergabe auf 4,1 % in FASE’08 gesunken ist. Dieses stellte
sich u¨ber die Jahre als Arbeitserleichtung fu¨r die PC Chairs heraus.
Durch das Wissen, wie sich ein System in anderen Kontexten verha¨lt bzw.
eingesetzt wird, kann es fu¨r ein weites Spektrum gezielt entwickelt und an
verschiedene Gescha¨ftsprozesse angepasst werden.
Teil V
Zusammenfassung und Ausblick
155
Kapitel 11
Zusammenfassung und Ausblick
11.1 Zusammenfassung
In dieser Arbeit wurde insbesondere eine graphbasierte und Feature-orientierte
Vorgehensweise fu¨r die Software-Entwicklung im Rahmen einer konkreten prak-
tischen Umsetzung vorgestellt, die unabha¨ngig von der fu¨r das zu konzipierende
und realisierende Projekt verwendeten Technologie ist. Der Online Conference
Service ist 1999 auf Basis des beschriebenen Konzeptes Service-orientiert ent-
wickelt worden und kam erstmalig 2000 in direkter Kooperation mit Sprin-
ger Heidelberg fu¨r eine internationale Konferenz zum Einsatz (siehe Tabel-
le 9.1). Im Laufe der Jahre vergro¨ßerte sich der Umfang an Dienstfunktiona-
lita¨ten sta¨ndig, bis der OCS 2003 eines der flexibelsten Begutachtungssyste-
me war, das sich an verschiedene Konferenzanforderungen anpassen konnte.
Das vorgestellte Konzept basiert auf dem modellgetriebenen Ansatz des ABC
und wurde bereits Ende der neunziger Jahre entwickelt. Das Konzept stell-
te zu dieser Zeit einen neuartigen Ansatz fu¨r die Realisierung von komplexen
Web-Anwendungen im Bereich von Begutachtungssystemen dar. Die realisier-
te Service-orientierte Vorgehensweise ermo¨glicht Gescha¨ftsprozesse von Unter-
nehmen hierarchisch als Features zu strukturieren und in Form von Graphen
abzubilden, die direkt den Kontrollfluss der Anwendung repra¨sentieren. Auf
diese Weise entstehen u¨bersichtliche, in Haupt-Features und Unter-Features ge-
kapselte Prozessketten, die ausfu¨hrbar sind. Durch die vollautomatische Code-
Generierung des ablauffa¨higen Kontrollflusses ist gewa¨hrleistet, dass die Mo-
delle der Gescha¨ftprozesse mit der Code-Repra¨sentation jederzeit konform
sind, was die Agilita¨t in Bezug auf die Anpassung bestehender Graphmodelle
und respektive der Ausfu¨hrungsebene hervorhebt. Die modellgetriebene und
agile Vorgehensweise unterstu¨tzt den gesamten Entwicklungsprozess und Le-
157
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 158
benszyklus einer Applikation, wie in Abbildung 11.1 (aus [MS06]) dargestellt.
Abbildung 11.1: Agiles Prozessorientiertes Design
Kundengespra¨che bzgl. der Gescha¨ftsabla¨ufe ko¨nnen anhand der Graphebene
erfolgen und auftretende A¨nderungen der Prozesse direkt auf der Ebene einge-
pflegt werden. Sind Modifikationen auf Basis von existierenden Dienstkompo-
nenten durchzufu¨hren, so ist der neue Gescha¨ftsablauf nach der Generierung
der Code-Repra¨sentation direkt ausfu¨hrbar und steht fu¨r die Kundenpra¨senta-
tion und die Installation direkt zur Verfu¨gung. Sind hingegen neue Dienste fu¨r
die Umsetzung des gea¨nderten Gescha¨ftsprozesses zu implementieren, dient die
graphbasierte Modellierung des neuen Workflows als Grundlage zur Kommu-
nikation und Diskussion mit dem Kunden und spa¨ter mit dem SIB-Entwickler,
was mit einer deutlichen Vereinfachung der Anwendungsentwicklung durch die
Visualisierung der Gescha¨ftsprozesse und der direkten Code-Generierung ein-
hergeht. Die vom Kunden (Applikationsexperten) orchestrierten Gescha¨ftspro-
zesse zeigen dem SIB-Entwickler (Programierexperte) einerseits die zu realisie-
renden Dienste (SIBs) auf, andererseits sind die Dienste bereits zu einem Kon-
trollfluss orchestriert, was dem Entwickler die Zusammenha¨nge der Services
darstellt. Kunden werden direkt in den Entwicklungsprozess der Applikationen
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 159
eingebunden und in die Lage versetzt, Gescha¨ftsprozesse ohne Programmier-
kenntnisse zu modellieren und bedingt durch die A¨nderung von Gescha¨fts-
abla¨ufen bzw. Firmenstrukturen, existierende Graphmodelle selbsta¨ndig zu
modifizieren, um die Prozesse der Applikation an die neuen Gegebenheiten ein-
fach und schnell zu adaptieren. Aus mehrja¨hriger Erfahrung ist es von großer
Bedeutung Kunden mit in die Appliaktionsentwicklung einzubeziehen, um die
selbsta¨ndige Erstellung und vor allem Anpassung von Gescha¨ftsmodellen zu
ermo¨glichen und das bereits direkt zur Modellierungsphase der Applikation.
Modellierte Gescha¨ftsprozesse werden fu¨r den Auftraggeber versta¨ndlicher, was
die Kommunikation zwischen der Gescha¨ftswelt und den IT-Experten deutlich
vereinfacht.
Andere Prozessorientierte Ansa¨tze, wie das 1993 von Prof. August-Wilhelm
Scheer eingefu¨hrte ARIS 1-Konzept [Sei02] basierend auf der verbreiteten Mo-
dellierungssprache eEPK 2, setzen UML-Werkzeuge fu¨r die Code-Generierung
ein. Im Vergleich zum eigenen Ansatz war fu¨r die ARIS-Modelle auf der Ebene
der Gescha¨ftsprozesse keine direkte vollsta¨ndige Transformation in eine Code-
Repra¨sentation als ausfu¨hrbaren Kontrollfluss vorgesehen. Heutzutage verfu¨gt
der ARIS UML Designer, der das ARIS-Konzept an UML anbindet, zwar u¨ber
ein Plugin fu¨r die Verwendung des Code-Generator Frameworks openArchitec-
tureWare [oT09] [And06], allerdings ist ein solcher Ansatz von zu technischer
Natur, um Kunden bzw. Gescha¨ftspartner ohne Programmierkenntnisse in den
Entwicklungsprozess zu integrieren. Derartige UML-basierte Ansa¨tzen, zu de-
nen auch Werkzeuge wie Together oder Rational Software Architect geho¨ren,
verwenden Code-Generator-Frameworks wie openArchitectureWare oder An-
droMDA [Tea09a](angelehnt an OMG’s Model Driven Architecure) zur Ge-
nerierung von Sourcecode. Der u¨berwiegende Teil des generierten Codes ist
unvollsta¨ndig (nur Code-Rahmen) und muss von Entwicklern implementiert
werden, was mit dem Problem des RTE 3 einhergeht. A¨nderungen die direkt
am generierten Sourcecode durchgefu¨hrt werden, sind in das entsprechende
Modell einzuarbeiten, um eine Konsistenz zwischen Modell und Sourcecode
zu gewa¨hrleisten. Das in Abbildung 11.2 (aus [SJWM09]) dargestellt Bild b)
illustriert dieses Szenario. In komplexen Anwendungen mit verschiedenen Mo-
dellen, wie es bei UML der Fall ist, stellt sich ein permanenter Abgleich als ein
sehr großer Aufwand und oftmals schwer zu realisierender Prozess dar.
Der Fokus der eigenen Vorgehenweise der Softwareentwicklung liegt in der Ein-
fachheit und der Versta¨ndlichkeit komplexe Anwendungen auf Gescha¨ftspro-
zessebene durch Graphmodelle abzubilden, schnell an neue Gescha¨ftsabla¨ufe
1Architektur Integrierter Informationssysteme
2erweiterte Ereignisgesteuerte Prozesskette von Prof. August-Wilhelm Scheer
3Roundtrip Engineering
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 160
zu adaptieren (Agilita¨t) und durch direkte vollautomatische Code-Generierung
(ohne manuelles Eingreifen in den generierten Code) eine ausfu¨hrbare Appli-
kation zu erstellen bzw. A¨nderungen in eine bereits existierende Anwendung
schnell und sicher (Verfikation der Graphmodelle) einzupflegen. Die Ansa¨tze
OTA 4 [SJWM09, MS09, SN07] und XMDD 5 [SJWM09, MS08] stehen fu¨r die
Umsetzung derartiger Anforderungen, zu deren Erforschung Projekte wie der
OCS in Form einer Fallstudie maßgeblich beigetragen haben. OTA zeigt den
gesamten Entwicklungsprozess vereinfacht als ein Modell auf, das fu¨r Applikati-
onsexperten und Gescha¨ftsleute (Nicht-IT-Experten) gleichermaßen versta¨nd-
lich und transparent ist. XMDD ist eine extreme Ausrichtung des MDD 6,
die alle Gescha¨ftsprozesse einer Applikation auf der Modellierungsebene be-
schreibt. Des Weiteren gewa¨hrleistet der Ansatz die Konsistenz zwischen dem
Modell und dem generierten Sourcecode, was ein wesentlicher Aspekt fu¨r ei-
ne agile, Modellgetriebene Softwareentwicklung ist (siehe Abbildung 11.2 Bild
c)).
Abbildung 11.2: Component-, Model-Based Design, and XMDD
A¨nderungen bzgl. der Gescha¨ftsprozesse werden ausschließlich auf Modellie-
rungsebene durchgefu¨hrt, wodurch das RTE hinfa¨llig wird. Der generierte
Sourcecode stimmt zu jeder Zeit mit dem Modell u¨berein und ist konsistent.
Diese Vorgehensweise in Kombination mit dem Feature-orientierten Ansatz
machten den OCS zu einem sehr agilen System in Bezug auf die Adaption des
Gescha¨ftsprozesses. Das Bild a) in Abbildung 11.2 zeigt die Vorgehenweise bei
dem Component Based Design. Es existieren Modelle aus denen jeweils eine
4The One-Thing-Approach
5eXtreme Model-Driven Design
6Model-Driven Design
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 161
Komponente generiert wird, wobei die Modelle nicht miteinander verbunden
sind. Die Umsetzung der Applikation findet auf Basis der Bibliotheken von
Komponenten statt und nicht auf der Modellierungsebene, was dem heutigen
Konzept der Softwareentwicklung entsprechen wu¨rde.
Durch den vorgestellten Zugriffskontrollmechanismus [KM06], der sich naht-
los in das Feature-orientierte Konzept [KM05] einfu¨gt, ko¨nnen Zugriffe auf
die Dienstkomponenten auf einfache Weise gesteuert und die Benutzersichten
personalisiert werden. Dieses realisierte Rollen/Rechte Management, das fu¨r
dynamische Rollen und Rechteabha¨ngigkeiten realisiert wurde, zeichnet sich
durch seine hohe Flexibilita¨t aus. Die Rechtezuordnungen in Begutachtungs-
systemen, insbesondere fu¨r Journals, erfordern eine ho¨here Dynamik als in
anderen Standard RBAC-Anwendungen [FK92]. Auf eine hierarchische Struk-
turierung der Rollen, wie sie in [SCFY96] vorgestellt wird, ist aufgrund der sich
dynamisch a¨ndernden Zugriffsrechte in Begutachtungssystemen bei der Reali-
sierung des Zugriffskontrollmechanismus von der Hierarchie abgesehen worden.
Eine Hierarchisierung ha¨tte zufolge gehabt, dass fu¨r jede zusa¨tzliche Rolle bzw.
fu¨r jede spezielle Anpassung einer Rolle fu¨r eine Einzelperson, der Umfang der
Hierarchie zunimmt, was letztendlich zu einer Komplexita¨t der Verschachte-
lungen in der Hierarchiestruktur gefu¨hrt ha¨tte, die schwer zu konfigurieren und
warten wa¨re. Das Rollen/Rechte Management wurde XACML 7 [Mos05] und
WS-Policy [BNB+06, WCL+05] gegenu¨bergestellt [KMW08] und aufgezeigt,
wie zentral eine Verifikation von Policies (constraints) fu¨r die Gu¨ltigkeit von
Rechtesysteme ist.
Die Verifikation eines Graphmodells wird mittels eines Modelcheckers durch-
gefu¨hrt, der ein Modul des ABC ist. Der Kontrollfluss (Gescha¨ftslogik) des
OCS ist als gerichtete Graphen modelliert, die auf zentrale Eigenschaften hin
u¨berpru¨ft werden ko¨nnen [KM05, KM06, KMW08]. Hierfu¨r werden atomare
Eigenschaften (Propositionen) an die Knoten der Graphen annotiert. Die Veri-
fikation der Systembeschreibung (Graphmodell) wird gegen eine Spezifikation
durchgefu¨hrt. Diese Spezifikation wird als temporal logische Formel in CTL
(Computation Tree Logic) geschrieben (siehe Kapitel 2.2.3), die auf den anno-
tierten Propositionen aufbaut. Der Modelchecker u¨berpru¨ft diese Grapheigen-
schaften und zeigt vorhandene Inkonsistenzen auf.
Die Umsetzung des OCS und seiner Dienstfamilie [KM06] (siehe Kapitel 7)
unter Einhaltung der beschriebenen Vorgehensweisen verfolgte bereits En-
de der Neunzigerjahre eine Service-orientierte Softwareentwicklung und zeig-
te eine Lo¨sung fu¨r die Umsetzung komplexer Anwendungen fu¨r ausfu¨hrbare
Gescha¨ftsprozesse auf, die erst spa¨ter, etwa durch die im Jahre 2002 eingefu¨hr-
7eXtensible Access Control Markup Language
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 162
te Sprache fu¨r Gescha¨ftsprozesse WS-BPEL, in den Fokus intensiver Forschung
und einer breiten o¨ffentlichen Beachtung gelangten. IBM, BEA Systems und
Microsoft realisierten die XML-basierte Sprache WS-BPEL [GKA+07], die zur
reinen Orchestrierung von Web Services dient. BPEL basiert auf den Sprachen
XLANG [Mic09c] von Microsoft und WSFL 8 [Wes09] von IBM. Im Gegen-
satz zum ABC mit seiner fu¨r Web-Dienste konzipierten EWIS-Umgebung, die
zur Laufzeit mit einer eigenen, leichtgewichtigten Prozess-Engine den Work-
flow steuert und Benutzerinteraktionen zula¨sst, sah WS-BPEL keine direkten
Interaktionen mit Menschen vor. Erst die Erweiterung WS-BPEL4People rea-
lisiert die Interaktion des Menschen im Jahre 2005 unter Verwendung von
WS-HumanTask [FAAD07], die seit 2007 zur Standardisierung bei OASIS 9
vorliegt. Damit Sub-Prozesse von BPEL unterstu¨tzt werden ko¨nnen ist die
Erweiterung BPEL-SPE [KKL+05] 2005 eingefu¨hrt worden. Hierarchien von
Prozessketten waren bereits seit Entwicklungsbeginn des OCS kontinuierlich
durch Einhaltung des Feature-orientierten Ansatzes existent. Im industriellen
Bereich hat sich BPEL zu einem Standard zur Beschreibung von ausfu¨hrba-
ren Gescha¨ftsprozessen etabliert. Als Schnittstelle und zur Beschreibung der
Funktionalita¨ten von Web Services wird WSDL 10 verwendet. Zum Nachrich-
tenaustausch kommt SOAP 11 [Erl04] zum Einsatz. Im Gegensatz zum ABC,
das ein einheitliches Entwicklungskonzept aufweist, das die Gescha¨ftswelt mit
der IT-Welt verbindet, verfu¨gt BPEL u¨ber kein eigenes Modellierungswerk-
zeug und keine eigene Laufzeitumgebung (process engine). Die im Jahre 2002
von der BPMI 12 vero¨ffentlichte grafische Notation BPMN 13 [WM08], ist seit
2006 offizieller OMG-Standard fu¨r die Modellierung von Gescha¨ftsprozessen.
Die erstellten Modelle lassen sich in Ausfu¨hrungssprachen wie der BPML 14
oder BPEL4WS 15 exportieren, wobei sich BPML nicht gegen BPEL durchset-
zen konnte. XPDL 16 ist eine weitere Prozessbeschreibungssprache, die von der
WfMC 17 entwickelt wird. Ru¨ckblickend la¨sst sich in Bezug auf die Entwick-
lung und industrielle Standardisierung von BPEL und der Standardisierung
von BPMN feststellen, dass der Ansatz bestehend aus graphbasierter Feature-
orientierter Modellierung von hierarchischen ausfu¨hrbaren Prozessketten auch
nach vielen Jahren nichts an seiner Aktualita¨t eingebu¨ßt hat. Das schnelle An-
8Web Services Flow Language
9Organization for the Advancement of Structured Information Standards
10Web Service Description Language
11Simple Object Access Protocol
12Business Process Management Initiative
13Business Process Modeling Notation
14Business Process Modeling Language
15Business Process Execution Language for Web Services
16XML Process Definition Language
17Workflow Management Coalition
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 163
passen von laufenden Diensten durch den Feature-orientierten Ansatz hat sich
in vielen Fa¨llen bewa¨hrt, so konnten bestehende Workflows auf einfache Wei-
se modifiziert sowie neue Gescha¨ftsprozesse eingepflegt werden. Kommunities
stellten oftmals zu Beginn der Konferenz Anforderungen fu¨r neue Features, die
umgesetzt und in den laufenden Dienst eingebaut wurden. Hierzu za¨hlt z.B.
das Feature fu¨r die Anonymisierung der PC Member, das in dieser Arbeit vor-
gestellt wurde. Diese Anforderung wurde erstmalig von dem Kommittee der
Konferenz ATPN an den OCS gestellt. PC Members sollten im Dienst nicht
erkennen ko¨nnen, von wem etwas begutachtet oder im Forum diskutiert wur-
de. Der eigentliche Begutachtungsprozess zwischen den PC Members verla¨uft
anonymisiert. Die A¨nderungen betrafen mehrere Features des Entscheidungs-
systems, die rechtzeitig zur Begutachtungsphase eingespielt werden konnten.
Die Vorstellung der Patterns aus Identify the Champion von Oscar Nierstrasz
[Nie00], die ein Vorgehensmuster fu¨r eine effiziente Entscheidungsfindung be-
schreiben und der anschliessende Vergleich mit den Vorgehensweisen des Ent-
scheidungssystems OCS wiesen U¨bereinstimmungen auf. Durch die Flexibilita¨t
der Features der eigenen Entscheidungssyteme sind diese Patterns ebenso um-
setzbar, wie die verschiedenen Anspru¨che an die Systemfunktionalita¨ten durch
die Kommunities. Bereits im Jahr 2003 war mit dem OCS ein Begutachtungs-
system im Einsatz, das zu diesem Zeitpunkt bereits den Service-orientierten
Ansatz verfolgte, der erst spa¨ter vomMainstream aufgegriffen wurde. Insbeson-
dere die Agilita¨t und der Funktionsumfang des Systems sind hervorzuheben.
Die Gegenu¨berstellung der heutigen bekannten Begutachtungssysteme hat ge-
zeigt, dass mittlerweile die zentralen Features auch in andere Systeme Einzug
gehalten haben, wobei es signifikante Unterschiede in Bezug auf Umsetzung
und Auspra¨gung gibt. OCS hat, bedingt durch den parallel entstandenen OJS,
bereits fru¨hzeitig (zur Entstehungszeit) die meisten der heutigen ga¨ngigen Fea-
tures zur Verfu¨gung gestellt und nahm eine Vorreiterstellung ein, was die Ent-
wicklung einiger Systeme beeinflusst hat. Durch das Feature-orientierte graphi-
sche Konzept konnten die jeweils entwickelten Features im OCS sowie im OJS
eingesetzt werden. Dieses fu¨hrte zu einer gro¨ßeren Anzahl von wiederverwend-
baren Komponenten, die ihren Einsatz ebenso in den spa¨ter realisierten Ent-
scheidungssystemen LNCS und Transactions fanden. Mit dem Dienst LNCS
wird u¨ber die Zulassung eines Projektes, wie z.B. einer Konferenz oder Jour-
nals, zur Publikation entschieden. Der Dienst Transactions spiegelt den Ent-
scheidungsworkflow u¨ber die Reihe Transactions bei Springer wider. Der OCS
wurde Kunden-orientiert entwickelt. Dieses hatte zur Folge, dass durch die
damaligen Anforderung der Kunden jedes Detail selbst einstellen zu ko¨nnen,
die Komplexita¨t der Konfiguration zu nahm. In den letzten Jahren hat ein
Umdenken bei den Kunden stattgefunden, dass Konfigurationen bzw. Einstel-
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 164
lungen bzgl. des Begutachtungssystems und dessen Workflows nur noch mini-
malistischer Natur sein sollen. Die Adaption des Begutachtungssystems auf die
spezifischen Anforderungen der verschiedenen Konferenzen ist durch die Aus-
wahl vordefinierter Standardkonfigurationen, inklusive der Konfigurationen der
Vorga¨ngerkonferenzen, erwu¨nscht. Beim OCS wurde im Gegensatz zu den an-
deren Begutachtungssystemen ein Modellgetriebener, Service-orientierter An-
satz [SMN+07, MS04a, KM05, KM06] verfolgt, der neuartig war und heute
sehr verbreitet und aktuell ist. Konzepte und Technologien waren im Vergleich
zu heute rar oder mitunter noch nicht existent. Dieses fu¨hrte zu einem robusten
und komplexen System, das beim Springer Verlag Heidelberg fu¨r die publizie-
renden Konferenzen in der Fachreihe LNCS seit 2000 als Begutachtungssystem
in Kooperation mit dem Lehrstuhl fu¨r Programmiersysteme angeboten [Hei09b]
wird. Im Jahr 2007 wurde die Verwaltung des OCS von Springer u¨bernommen
und seitdem von Springer SBM 18 in Dordrecht, Niederlande, gehostet.
Steckten die Technologien und Architekturen fu¨r die Realisierung von komple-
xen Web-Applikationen Ende der Neunzigerjahre noch in den Kinderschuhen
oder wurden diese teilweise erst spa¨ter konzipiert, so hat man heute eine nahezu
freie Auswahl im kommerziellen sowie im Open Source Bereich. Das bedeutete
fu¨r den OCS, dass Komponenten damals von Grund auf selbst implementiert
werden mussten. Z.B. wurde die Datenbankschicht direkt auf Basis der Daten-
bankschnittstelle JDBC 19 [mic09j] realisiert, wobei die Datenbankinteraktio-
nen in den Gescha¨ftsobjekten und Administratoren gekapselt wurden. Diese
dienten zur Implementierung der einzelnen Gescha¨ftsprozesselemente (SIB),
aus denen die Gescha¨ftslogik der Anwendung graphbasiert modelliert wird.
Fu¨r die GUI kam WML [WML09] in Verbindung mit Velocity [Apa09] zum
Einsatz. Die Personalisierung ist mittels des in dieser Arbeit beschriebenen Zu-
griffskonzepts durchgefu¨hrt und die Gescha¨ftslogik mittels des ABC und EWIS
als ausfu¨hrbarer Kontrollflussgraph modelliert und zu Servlets generiert wor-
den.
Mit dem OCS ist u¨ber die Jahre eine Produktlinie [KM06] entstanden, die
auf Basis von innovativen Konzepten aufgebaut wurden. Diese waren Ende
der Neunzigerjahren vo¨llig neuartig und haben sich u¨ber die Jahre durch das
Aufkommen von a¨hnlichen, in dieser Arbeit aufgezeigten, Ansa¨tzen besta¨tigt
und sind zur heutigen Zeit weiterhin aktuell. Die vorgestellten Konzepte fu¨r
die Softwareentwicklung bestehend aus der Modellierung und Ausfu¨hrung von
Gescha¨ftsprozessen kombiniert mit der Verifikation (breits zur Designzeit) und
der automatischen Generierung der ausfu¨hrbaren Applikation stellt eine ein-
18Springer Science+Business Media
19Java Database Connectivity
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 165
heitliche Vorgehensweise dar, die sich in Forschungs- und Industrieprojekten
als erfolgreich erwiesen hat.
11.2 Ausblick
Der heutige Trend der Software-Entwicklung geht versta¨rkt in Richtung Mo-
dellierung und Orchestrierung von Web Services zur Erstellung von neuen
Applikationen. Das Denken in Services und die Synergien von bestehenden
bzw. wiederverwendbaren Diensten spiegeln den Grundgedanken der Service-
orientierten Softwareentwicklung wider.
Bestehende Anwendungen von Drittanbietern ob kommerziell oder Open Sour-
ce werden zu einem System orchestriert. Mittlerweile ko¨nnen mit der heutigen
Drittanbietersoftware die damaligen proprieta¨ren Komponenten realisiert wer-
den, hierzu geho¨ren Lo¨sungen von Drittanbietern fu¨r z.B. Foren, DMS 20 oder
CMS 21. Es existieren Software-Bibliotheken und APIs 22, die eine Entwick-
lung von Applikationen massgeblich vereinfachen. Zum Beispiel wird mit der
JPA 23 [BHRS07] [mic09e] dem Entwickler eine API an die Hand gegeben,
die die Applikation von der Datenbankschicht entkoppelt. Dieses musste zur
Entstehungszeit des OCS aufwa¨ndig realisiert werden. Die heutige Verfu¨gbar-
keit von Architekturen, Frameworks und Sprachen wie z.B. Java EE [mic09d],
.Net [Mic09b], Spring [OLW+08], JBoss Seam [JBo09], JSF [mic09g], BPEL
oder LDAP [Zo¨r08] [LU06], stellen eine große Bandbreite von direkt verwend-
baren Konzepten und Technologien bereit. War noch vor einigen Jahren die
eigentliche Konzipierung der Entwicklung von Software eine große Herausfor-
derung, die die Realisierung des Gesamtpaketes bedeutete, so besteht heute
die Schwierigkeit darin, die ada¨quaten Konzepte und die passenden Technolo-
gien fu¨r die geplante Software-Applikation aus der Palette von existierenden
Lo¨sungen zu selektieren.
Die Modellierung von Gescha¨ftsprozessen, die beim OCS und seiner Dienstfa-
milie bereits vor Jahren konsequent verfolgt wurden, hat heute in den ga¨ngigen
Entwicklungsumgebungen Einzug erhalten. Neue Entscheidungssysteme wer-
den entwickelt, die existierende Technologien verwenden und auf eine breite
Palette von vorhandenen Lo¨sungen zuru¨ckgreifen ko¨nnen. Die Entwickler er-
halten heutzutage Entwicklungswerkzeuge an die Hand, die fu¨r den Benutzer
ein Gesamtpaket an Technologien zur Entwicklung von Software bereitstellen.
20Dokumenten-Management-System
21Content-Management-System: Inhaltsverwaltungssystem
22Application Programming Interface: Programmierschnittstelle
23Java Persistence API
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 166
Der OCS befindet sich seit 10 Jahren (erstmalig fu¨r TACAS 24 im Jahre 2000)
erfolgreich im Einsatz fu¨r wissenschaftliche Konferenzen. Er wurde stetig wei-
terentwickelt und wuchs zu einem robusten und flexiblen System heran. Der
OCS ist ein komplexes Begutachtungssystem geworden, in dem u¨ber die Jah-
re Kundenanforderungen und Benutzerru¨ckmeldungen in Form von Features
beru¨cksichtigt wurden. Wollten die Benutzer zur Entstehungszeit des Dienstes
alles selbst konfigurieren, so geht der Trend heutzutage in Richtung Einfachheit
ohne aufwa¨ndige Konfigurationen vornehmen zu mu¨ssen. Die heutige Softwa-
reentwicklung basiert auf Standards, es werden standardisierte Technologien
eingesetzt und bereits existierende WebServices in die eigene Entwicklung in-
tegriert, was Entwicklung und Wartung vereinfacht.
Zur Zeit wa¨chst eine neue Generation des OCS heran, welche die vorgestell-
ten Konzepte dieser Arbeit mit neusten Technologien vereint. Zu den grund-
legenden Konzepten geho¨ren weiterhin der Feature-orientierte und Modell-
getriebene Ansatz, mit dem die Gescha¨ftswelt auf einfache Weise auf die In-
formatik, insbesondere die Softwareentwicklung, projiziert werden kann. Le-
benszyklen von Gescha¨ftsobjekten und der Gescha¨ftsprozesse werden model-
liert. Dieses basiert auf einer Abstraktionsebene, die fu¨r Anwendungsexper-
ten ohne tiefgreifende Programmierkenntnisse versta¨ndlich und anwendbar ist.
Services werden entkoppelt entwickelt und bilden durch Orchestrierung die
Gescha¨ftsprozesse ab. Es werden gezielt Standards eingesetzt, wie z.B. ein
Dokumentenmanagementsystem eines Drittanbieters, was eine Wartung des
eigenen Systems erleichtern soll und den Entwicklungsaufwand minimiert. Des
Weiteren wird der Aspekt der Einfachheit in Bezug auf die Konfiguration und
die Ergonomie der Konferenzen beru¨cksichtigt. Informationen sollen noch kom-
pakter dargestellt werden und Standardworkflows in Form von vordefinierten
Konfigurationen, auch der vorangegangenen Konferenz, verfu¨gbar sein. Zum
Einsatz kommen Technologien wie das Web-Framework Tapestry [Kol08], Apa-
che DS als LDAP-Server zur Authentifizierung und JPA zur Entkopplung der
Datenbankschicht. Die JCR-API 25 dient dem einheitlichen und standardi-
sierten Zugriff auf Dokumentenmanagementsysteme, wobei die Implementie-
rung Apache Jackrabbit verwendet wird. Als Diskussionskomponente wird die
Drittanbietersoftware jForum [Tea09b] eingesetzt, die mittels des REST 26-
Ansatzes [Fie00] angebunden wird. Als Softwarearchitektur wird auf Java EE
aufgebaut.
Neben der Einfu¨hrung neuer Standards und der Anpassung der Ergonomie,
wa¨re die Erweiterung des Forum-Features durch eine integrierte Komponen-
24Tools and Algorithms for the Construction and Analysis of Systems
25Java Content Repository
26Representational State Transfer
KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 167
te fu¨r eine Videokonferenz ein weiterer Schritt in Richtung eines virtuellen
PC Meetings. Dieses wu¨rde den Trend heutige PC Meetings kaum noch phy-
sikalisch stattfinden zu lassen weiterhin unterstu¨tzen und den Aufwand fu¨r
derartige Treffen minimieren.
Literatur
[And06] Thomas Andres. AGILITA¨T durch ARIS Gescha¨ftsprozess-
management, chapter Vom Gescha¨ftsprozess zur Anwendung:
Modellgetriebene Entwicklung betriebswirtschaftlicher Softwa-
re, pages 231–242. Springer Berlin Heidelberg, 2006.
[BHRS07] Robert F. Beeger, Arno Haase, Stefan Roock, and Sebastian
Sanitz. Hibernate - Persistenz in Java-Systemen mit Hibernate
und der Java Persistence API. dpunkt.verlag, 2007.
[BM06] Markus Bajohr and Tiziana Margaria. Matrics: A service-
based management tool for remote intelligent configuration of
systems. ISSE, 2(2):99–111, 2006.
[BM08] Markus Bajohr and Tiziana Margaria. High service availability
in matrics for the ocs. In ISoLA, pages 572–586, 2008.
[BM09] Alexandre Braganc¸a and Ricardo Machado. A model-driven ap-
proach for the derivation of architectural requirements of soft-
ware product lines. Innovations in Systems and Software Engi-
neering, 5(1):65–78, March 2009.
[BMRS06] Marco Bakera, Tiziana Margaria, Clemens Renner, and Bern-
hard Steffen. Game-based model checking for reliable autonomy.
In SMC-IT’06, 2nd IEEE Int. Conf. on Space Mission Challen-
ges for Information Technology, Workshop on Autonomous and
Autonomic Systems. IEEE Computer Society, 2006.
[BMRS07a] M. Bakera, T. Margaria, C. Renner, and B. Steffen. Property-
driven functional healing: Playing against undesired behavior.
In 10th CONQUEST, 2007.
[BMRS07b] M. Bakera, T. Margaria, C. Renner, and B. Steffen. Verificati-
on, diagnosis and adaptation: Tool supported enhancement of
169
LITERATUR 170
the model-driven verification process. In Wrksh. on Formal Me-
thods in Avionics, Space and Transport (ISOLA), pages 85–98.
Revue des Nouvelles Technologies de l’Information (RNTI-SM-
1), 2007.
[BMRS08] Marco Bakera, Tiziana Margaria, Clemens D. Renner, and
Bernhard Steffen. Model Checking with the JavaABC Fra-
mework - From METAGame to GEAR. In QEES’08, Intern.
Symposium on Quality Engineering for Embedded Systems - In
conjunction with the ECMDA 2008. IEEE CS, 2008.
[BMS06] Markus Bajohr, Tiziana Margaria, and Bernhard Steffen. Ser-
vice based enabling service availability in the matrics: A model-
driven approach. In ISoLA, pages 317–324, 2006.
[BNB+06] Siddharth Bajaj, Nataraj Nagaratnam, Don Box, Dave Chap-
pell, and Francisco Curbera. Web services policy 1.2 - frame-
work (ws-policy). Technical report, W3C, April 2006.
[Bra01] Volker Braun. A Coarse-granular Approach to Software Deve-
lopment allowing Non-Programmers to Build and Deploy Relia-
ble, Web-based Applications. PhD thesis, Dissertation, Techni-
sche Universita¨t Dortmund, Lehrstuhl fu¨r Programmiersysteme,
Dortmund, Deutschland, 2001.
[CBBa06] Francisco Curbera, Keith Ballinger, Bobby Bissett, and
Don Box and. Web services metadata exchange (ws-
metadataexchange). Technical report, BEA Systems Inc., Com-
puter Associates International, Inc., International Business Ma-
chines Corporation, Microsoft Corporation, Inc., SAP AG, Sun
Microsystems, webMethods, August 2006.
[CGP01] Emund M. Clarke, Orna Grumberg, and Doron A. Peled. Model
Checking. MIT Press, 2001.
[Cza04] Krzysztof Czarnecki. Overview of generative software develop-
ment. In UPP, pages 326–341, 2004.
[DDB+04] Michael Dimov, Minye Dong, Youssef Belkhadir, Micha-
el Drazek, Jaouad El Jerroudi, Christian Kuete-Tsatedem,
Daniel Pierlings, Mohammed Said, Dennis Saßmannshau-
sen, Holger Willebrandt, and Jing Zhou. Eureka 1 -
LITERATUR 171
entscheidungs-unterstu¨tzung: Rollengerecht, effizient, koopera-
tiv, allgegenwa¨rtig. Technical report, PG EUREKA I - Techni-
sche Universita¨t Dortmund, Lehrstuhl fu¨r Programmiersysteme,
September 2004.
[DGSZ94] Guido Dinkhoff, Volker Gruhn, Armin Sallmann, and Micha-
el Zielonka. Business process modelling in the workflow-
management environment leu. In ER ’94: Proceedings of the13th
International Conference on the Entity-Relationship Approach,
pages 46–63, London, UK, 1994. Springer-Verlag.
[DLHPB09] Giusy Di Lorenzo, Hakim Hacid, Hye-young Paik, and Boua-
lem Benatallah. Data integration in mashups. SIGMOD Rec.,
38(1):59–66, 2009.
[EG07] Robert J. Ennals and Minos N. Garofalakis. Mashmaker: mas-
hups for the masses. In SIGMOD ’07: Proceedings of the 2007
ACM SIGMOD international conference on Management of da-
ta, pages 1116–1118, New York, NY, USA, 2007. ACM.
[EJS93] E. Allen Emerson, Charanjit S. Jutla, and A. Prasad Sistla.
On model-checking for fragments of mu-calculus. In CAV ’93:
Proceedings of the 5th International Conference on Computer
Aided Verification, pages 385–396, London, UK, 1993. Springer-
Verlag.
[Erl04] Thomas Erl. Service-Oriented Architecture. Prentice Hall, 2004.
[FAAD07] Mark Ford, Ashish Agrawal, Mike Amend, and Manoj Das. Web
services human task (ws-humantask), version 1.0. Technical re-
port, Active Endpoints Inc., Adobe Systems Inc., BEA Systems
Inc., International Business Machines Corporation, Oracle Inc.,
SAP AG., June 2007.
[Fie00] Thomas Fielding. Architectural styles and the design of network-
based software architectures. PhD thesis, 2000. Chair-Taylor an,
Richard N.
[FK92] David Ferraiolo and Richard Kuhn. Role-based access con-
trol. In In 15th NIST-NCSC National Computer Security Con-
ference, pages 554–563, 1992.
[Fow03] Martin Fowler. UML konzentriert. Addison Wesley Verlag,
2003.
LITERATUR 172
[GDLHBH05] Martin Gudgin, Giovanni Della-Libera, Phillip Hallam-Baker,
and Maryann Hondo. Web services security policy language
(ws-securitypolicy) version 1.1. Technical report, International
Business Machines Corporation, Microsoft Corporation, RSA
Security Inc., VeriSign Inc, July 2005.
[GKA+07] Yaron Goland, Neelakantan Kartha, Alexandre Alves, Assaf Ar-
kin, Sid Askary, Ben Bloch, Francisco Curbera, Sterling, Die-
ter Ko¨nig, Vinkesh Mehta, Satish Thatte, Danny van der Rijn,
Prasad Yendluri, and Alex Yiu. Web services business process
execution language version 2.0. Technical report, WS-BPEL
TC OASIS, April 2007.
[Gri04] P. Griffin. Introduction to xacml. Technical report, Bea Sy-
stems, February 2004.
[Gso04] Claudia Gsottberger. Ein Framework zur modularisierten und
pattern-basierten Entwicklung von zuverla¨ssigen, personalisier-
ten, web-basierten Applikationen. PhD thesis, Dissertation,
Technische Universita¨t Dortmund, Lehrstuhl fu¨r Programmier-
systeme, Dortmund, Deutschland, 2004.
[HB08] Graham Hughes and Tevfik Bultan. Automated verification of
access control policies using a sat solver. Int. J. Softw. Tools
Technol. Transf., 10(6):503–520, 2008.
[HBTE+05] Abdelazziz Ait Ben Haddou, Dominik Brink, Omar
Zaouaoui Elidrissi Taieb Elfakiri, Mikhail Farnassov, Hol-
ger Hopf, Markus Korte, Philipp Langer, Ganna Ostapchuk,
Alexander Powolozki, Abdelmounaim Ramadane, and Marc
von Renteln. Eureka 2 - entscheidungs-unterstu¨tzung: Rollen-
gerecht, effizient, kooperativ, allgegenwa¨rtig. Technical report,
PG EUREKA II - Technische Universita¨t Dortmund, Lehrstuhl
fu¨r Programmiersysteme, July 2005.
[HG98] Otthein Herzog and Andreas Gu¨nter, editors. KI-98: Advan-
ces in Artificial Intelligence, 22nd Annual German Conference
on Artificial Intelligence, Bremen, Germany, September 15-17,
1998, Proceedings, volume 1504 of Lecture Notes in Computer
Science. Springer, 1998.
[HMM+06] Martina Ho¨rmann, Tiziana Margaria, Thomas Mender, Ralf Na-
gel, Michael Schuster, Bernhard Steffen, and Hong Trinh. The
LITERATUR 173
jabc appraoch to collaborative development of embedded app-
lications. In CCE’06, Int. Worksh. on Challenges in Collabo-
rative Engineering - State of the Art and Future Challenges on
Collaborative Design, 2006.
[Hol06] Holger Willebrandt. Service-orientierte Entwicklung ei-
ner Applikation zur Konfiguration und Erzeugung von Ta-
gungsba¨nden. Master’s thesis, Diplomarbeit, Technische Uni-
versita¨t Dortmund, Lehrstuhl fu¨r Programmiersysteme, Dort-
mund, Deutschland, November 2006.
[HW08] Stefan Huth and Thomas Wieland. Gescha¨ftsprozessmodellie-
rung mittels software-services auf basis der epk. In Service-
orientierte Architekturen, pages 61–76. Springer-Verlag, 2008.
[IT92] ITU-T. Recommendation Q.1203. ”Intelligent Network - Global
Functional Plane Architecture”. Technical report, Standardiza-
tion Sector of ITU, October 1992.
[ITU93] ITU. General recommendations on telephone switching and si-
gnaling - intelligent network: Introduction to intelligent network
capability set 1, Recommendation Q.1211. Technical report,
Standardization Sector of ITU, Geneva, March 1993.
[JMS06] Sven Jo¨rges, Tiziana Margaria, and Bernhard Steffen. Formu-
labuilder: A tool for graph-based modelling and generation of
formulae. In Proc. ICSE ’06, pages 815–818. ACM Press, 2006.
[KCH+90] Kyo Kang, Sholom Cohen, James Hess, William Novak, and
A. S. Peterson. Feature-oriented domain analysis (foda) fea-
sibility study. Technical report, Software Engineering Institu-
te, Carnegie Mellon University Pittsburgh, Pennsylvania 1521,
1990.
[KJMS09] Christian Kubczak, Sven Jo¨rges, Tiziana Margaria, and Bern-
hard Steffen. extreme model-driven design with jabc. In R. Vo-
gel (ed.) Proc. of the Tools and Consultancy Track of the Fifth
European Conference on Model-Driven Architecture Foundati-
ons and Applications (ECMDA-FA), volume WP09-12 of CTIT
proceedings, pages 78–99, P.O. Box 217, 7500 AE Enschede,
The Netherlands, University of Twente, Centre for Telematics
and Information Technology (CTIT), 2009.
LITERATUR 174
[KKL+05] Matthias Kloppmann, Dieter Ko¨nig, Frank Leymann, Gerhard
Pfau, and Alan Rickayzen. Bpel-spe - ws-bpel extension for sub-
processes. Technical report, IBM and SAP, September 2005.
[KM05] Martin Karusseit and Tiziana Margaria. Feature-based Mo-
delling of a Complex, Online-Reconfigurable Decision Support
Service. In WWV ’05, 1st Int. Worksh. Automated Specif. and
Verification of Web Sites, March 2005. ENTCS 1132.
[KM06] Martin Karusseit and Tiziana Margaria. A web-based runtime-
reconfigurable role management service. In WWV ’06: Pro-
ceedings of the 2nd Int’l. Workshop on Automated Specification
and Verification of Web Systems, pages 53–60, Washington, DC,
USA, 2006. IEEE Computer Society.
[KMW08] Martin Karusseit, Tiziana Margaria, and Holger Willebrandt.
Policy expression and checking in xacml, ws-policies, and the
jabc. In TAV-WEB ’08: Proceedings of the 2008 workshop on
Testing, analysis, and verification of web services and applica-
tions, pages 20–26, New York, NY, USA, 2008. ACM.
[Kol08] Alexander Kolesnikov. Tapestry 5 - Building Web Applications.
Packt Publishing, 2008.
[LK04] Daniel R. Licata and Shriram Krishnamurthi. Verifying in-
teractive web programs. In ASE ’04: Proceedings of the 19th
IEEE international conference on Automated software enginee-
ring, pages 164–173, Washington, DC, USA, 2004. IEEE Com-
puter Society.
[LMS01] B. Lindner, T. Margaria, and B. Steffen. Ein personalisier-
ter internetdienst fu¨r wissenschaftliche begutachtungsprozes-
se. GI-VOI-BITKOM-OCG-TeleTrusT Konferenz Elektroni-
sche Gescha¨ftsprozesse (eBusiness Processes), 2001.
[LU06] Oliver Liebel and John Martin Ungar. OpenLDAP. Galileo
Press, 2006.
[Mar05] T. Margaria. Web services-based tool-integration in the eti plat-
form. SoSyM, 4(2):141–156, 2005.
[Mar07] Tiziana Margaria. Service is in the eyes of the beholder. IEEE
Computer - Innivative Technology for Computer Professionals,
40(11):33–37, 2007.
LITERATUR 175
[MBK97] T. Margaria, V. Braun, and J. Kreileder. Interacting with eti:
A user session. STTT, 1(1-2):49–63, 1997.
[MHBK03] Hiroshi Maruyama, Maryann Hondo, Don Box, and Chris Kaler.
Web services policy assertions language (ws-policyassertions)
version 1.1. Technical report, BEA Systems, Inc, International
Business Machines Corporation, Microsoft Corporation, SAP
AG, May 2003.
[MK02] Tiziana Margaria and Martin Karusseit. Community usage of
the online conference service: an experience report from three
cs conferences. In I3E ’02: Proceedings of the IFIP Conference
on Towards The Knowledge Society, pages 497–511, Deventer,
The Netherlands, The Netherlands, 2002. Kluwer, B.V.
[Mos05] Tim Moses. extensible access control markup language (xacml)
- version2.0. Technical report, OASIS, Februar 2005.
[MOSS99] Markus Mu¨ller-Olm, David .A. Schmidt, and Bernhard Steffen.
Model-Checking: A Tutorial Introduction. Proc. SAS, pages
330–354, September 1999.
[MRSL07] T. Margaria, H. Raffelt, B. Steffen, and M. Leucker. The learnlib
in fmics-jeti. In Proc. ICECCS 2007, 12th IEEE Int. Conf.
on Engineering of Complex Computer Systems, number 2 in
Proc. ICECCS, Auckland (NZ), July 2007. IEEE Computer Soc.
Press.
[MS04a] Tiziana Margaria and Bernhard Steffen. Aggressive model dri-
ven development for the management of service evolution. In In
Annual Review of Communication, Int. Engineering Consorti-
um, IEC, volume 57, 2004.
[MS04b] Tiziana Margaria and Bernhard Steffen. Lightweight coarse-
grained coordination: a scalable system-level approach. Int. J.
Softw. Tools Technol. Transf., 5(2):107–123, 2004.
[MS06] Tiziana Margaria and Bernhard Steffen. Service Engineering:
Linking Business and IT. IEEE Computer - Innovative Tech-
nology for Computer Professionals, 39(10):45–55, 2006.
[MS08] T. Margaria and B. Steffen. Agile IT: Thinking in User-Centric
Models. In Proc. ISoLA 2008, CCIS N.17, pages 493–505. Sprin-
ger, 2008.
LITERATUR 176
[MS09] Tiziana Margaria and Bernhard Steffen. In Handbook of Re-
search on Business Process Modeling, chapter Business Process
Modelling in the jABC: The One-Thing Approach. IGI Global,
2009.
[MSR05] Tiziana Margaria, Bernhard Steffen, and Manfred Reitenspieß.
Service-Oriented Design: The Roots. In ICSOC 2005: 3rd
ACMSIGSOFT/SIGWEB Int. Conf. on Service-Oriented Com-
puting, LNCS N.3826, pages 450–464, Amsterdam, December
2005. Springer Verlag.
[Nag09] Ralf Nagel. Technische Herausforderungen modellgetriebener
Beherrschung von Prozesslebenszyklen aus der Fachperspektive:
Von der Anforderungsanalyse zur Realisierung. PhD thesis, Dis-
sertation, Technische Universita¨t Dortmund, Lehrstuhl fu¨r Pro-
grammiersysteme, Dortmund, Deutschland, 2009.
[Nie00] Oscar Nierstrasz. Identify the champion. In N. Harrison, B. Foo-
te, and H. Rohnert, editors, Pattern Languages of Program De-
sign, volume 4, pages 539–556. Addison Wesley, 2000.
[Nie03] Oliver Niese. An Integrated Approach to Testing Complex Sy-
stems. PhD thesis, Dissertation, Technische Universita¨t Dort-
mund, Lehrstuhl fu¨r Programmiersysteme, Dortmund, Deutsch-
land, 2003.
[NMH+01] Oliver Niese, Tiziana Margaria, Andreas Hagerer, Markus Na-
gelmann, Bernhard Steffen, Georg Brune, and Hans dieter Ide.
An automated testing environment for CTI systems using con-
cepts for specification and verification of workflows. In Annual
Review of Communication, volume 54, pages 927–936. Int. En-
gineering Consortium, Chicago (USA), 2001.
[NSM+01] Oliver Niese, Bernhard Steffen, Tiziana Margaria, Andreas Ha-
gerer, Georg Brune, and Hans-Dieter Ide. Library-based design
and consistency checking of system-level industrial test cases.
In Fundamental Approaches to Software Engineering, volume
2029/2001, pages 233–248. Springer Verlag, 2001.
[OCS08] OCS-Team. OCS Introduction, 2008. Lehrstuhl fu¨r Program-
miersysteme, TU Dortmund (Hrsg.).
LITERATUR 177
[OLW+08] Richard Oates, Thomas Langer, Stefan Wille, Torsten Lueckow,
and Gerald Bachlmayr. Spring & Hibernate. Carl Hanser Ver-
lag, 2008.
[SAM+08] David E. Simmen, Mehmet Altinel, Volker Markl, Sriram Pad-
manabhan, and Ashutosh Singh. Damia: data mashups for in-
tranet applications. In SIGMOD ’08: Proceedings of the 2008
ACM SIGMOD international conference on Management of da-
ta, pages 1171–1182, New York, NY, USA, 2008. ACM.
[SCFY96] Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, and
Charles E. Youman. Role-based access control models. Com-
puter, 29(2):38–47, 1996.
[Sei02] Heinrich Seidlmeier. Prozessmodellierung mit ARIS. vieweg,
Wiesbaden 2002.
[SJWM09] Bernhard Steffen, Sven Jo¨rges, Christian Wagner, and Tizia-
na Margaria. Maintenance, or the 3rd dimension of extreme
model-driven design. ICSM 2009 - 25th IEEE International
Conference on Software Maintenance, to appear, 2009.
[SM99] Bernhard Steffen and Tiziana Margaria. METAFrame in Prac-
tice: Design of Intelligent Network Services. In Correct System
Design - Recent Insights and Advances, LNCS N.1710, pages
390–415. Springer-Verlag, Heidelberg, Germany, October 1999.
[SMCB96] Bernhard Steffen, Tiziana Margaria, Andreas Claßen, and Vol-
ker Braun. The metaframe’95 environment. In Proc. CAV’96,
LNCS, pages 450–453. Springer, 1996.
[SMN+07] Bernhard Steffen, Tiziana Margaria, Ralf Nagel, Sven Jo¨rges,
and Christian Kubczak. Model-driven development with the
jabc. Lecture Notes in Computer Science, 4383:92–108, May
2007.
[SN07] Bernhard Steffen and Prakash Narayan. Full life-cycle support
for end-to-end processes. Computer, 40(11):64–73, 2007.
[Sta01] Richard Van De Stadt. Cyberchair: A web-based groupware
application to facilitate the paper reviewing process. available
at www.cyberchair.org, 2001.
LITERATUR 178
[Ste91] Bernhard Steffen. Data Flow Analysis as Model Checking.
In TACS ’91: Proceedings of the International Conference
on Theoretical Aspects of Computer Software, pages 346–365.
Springer-Verlag, 1991.
[SVC06] Thomas Stahl, Markus Voelter, and Krzysztof Czarnecki.
Model-Driven Software Development: Technology, Engineering,
Management. John Wiley & Sons, 2006.
[Tay08] Camillo J. Taylor. On the optimal assignment of conference pa-
pers to reviewers. Technical report, No. MS-CIS-08-30, Univer-
sity of Pennsylvania Department of Computer and Information
Science, January 2008.
[WCL+05] Sanjiva Weerawarana, Francisco Curbera, Frank Leymann,
Tony Storey, and Donald F. Ferguson. Web Services Platform
Architecture : SOAP, WSDL, WS-Policy, WS-Addressing, WS-
BPEL, WS-Reliable Messaging, and More. Prentice Hall PTR,
March 2005.
[Web99] Herbert Weber. Continuous engineering of information and
communication infrastructures (extended abstract). In FA-
SE ’99: Proceedings of the Second Internationsl Conference on
Fundamental Approaches to Software Engineering, pages 22–29,
London, UK, 1999. Springer-Verlag.
[WM08] Stephen A. White and Derek Miers. BPMN Modeling and Re-
ference Guide. Future Strategies Inc., Lighthouse Pt, FL, City,
2008.
[Zo¨r08] Stefan Zo¨rner. LDAP fu¨r Java-Entwickler. entwickler.press,
2008.
[ZRN08] Nan Zang, Mary Beth Rosson, and Vincent Nasser. Mashups:
who? what? why? In CHI ’08: CHI ’08 extended abstracts on
Human factors in computing systems, pages 3171–3176, New
York, NY, USA, 2008. ACM.
Web Referenzen
[All09] OpenAjax Alliance. Asynchronous JavaScript and XML, July 2009.
http://de.wikipedia.org/wiki/Ajax (Programmierung).
[Apa09] Apache. Apache Velocity Project, July 2009.
http://velocity.apache.org/.
[Ari09] Aries. Editorial Manager, July 2009. www.editorialmanager.de.
[Ber09] Michel Berkelaar. lp solve, July 2009.
http://lpsolve.sourceforge.net.
[Com09] Open Source Community. PostgreSQL, July 2009.
http://www.postgresql.org/.
[Con09] W3C World Wide Web Consortium. Die Homepage des W3C, July
2009. http://www.w3.org/.
[Fou09a] Apache Software Foundation. Apache ActiveMQ, July 2009.
http://activemq.apache.org/.
[Fou09b] Apache Software Foundation. Apache HTTP Server, July 2009.
http://httpd.apache.org.
[Fou09c] Apache Software Foundation. Apache Tomcat, July 2009.
http://tomcat.apache.org.
[GG09] Rich Gerber and Paolo Gai. START V2 Conference Manager, July
2009. http://www.softconf.com.
[Goo09] Google. GWT - Google Web Toolkit, July 2009.
http://code.google.com/webtoolkit/.
[Gro09] Zakon Group. OpenConf, July 2009. http://www.openconf.com.
179
WEB REFERENZEN 180
[Hat09] Red Hat. JBoss Applikation Server, July 2009.
http://www.jboss.com.
[Hei09a] Springer Verlag Heidelberg. LNCS Transactions Subline, July
2009. http://www.springer.com/computer/lncs?SGWID=0-164-6-
546809-0.
[Hei09b] Springer Verlag Heidelberg. OCS als Springer Konferenzsystem, Ju-
ly 2009. http://www.springer.com/computer/lncs?SGWID=0-164-
6-447109-0.
[Hei09c] Springer Verlag Heidelberg. Springer Homepage, July 2009.
http://www.springer.com.
[Hei09d] Springer Verlag Heidelberg. Springer LNCS Homepage, July
2009. http://www.springer.com/computer/ lncs?SGWID=0-164-
12-72397-0.
[INC09] SUN MICROSYSTEMS INC. The Java Programming Language,
July 2009. http://java.sun.com.
[JBo09] JBoss. JBoss Seam, July 2009.
http://www.jboss.com/products/seam/.
[Kri09] Shriram Krishnamurthi. Continue, July 2009.
http://continue2.cs.brown.edu/.
[Mic09a] Microsoft. Microsoft Popfly, 2009. http://www.popfly.com.
[Mic09b] Microsoft. .Net Framework, July 2009.
http://www.microsoft.com/NET/.
[Mic09c] Microsoft. XLANG, July 2009. http://msdn.microsoft.com/en-
us/library/aa577463(BTS.10).aspx.
[mic09d] Sun microsystems. Java EE, July 2009.
http://java.sun.com/javaee/.
[mic09e] Sun microsystems. Java Persistence API, July 2009.
http://java.sun.com/javaee/technologies/persistence.jsp.
[mic09f] SUN microsystems. Java Servlet Technology, July 2009.
http://java.sun.com/products/servlet/.
[mic09g] Sun microsystems. JavaServer Faces, July 2009.
http://java.sun.com/javaee/javaserverfaces/.
WEB REFERENZEN 181
[mic09h] SUN microsystems. JAXB - Java API for XML Processing, July
2009. http://java.sun.com/webservices/technologies/.
[mic09i] SUN microsystems. JAXB Article, July 2009.
http://java.sun.com/developer/technicalArticles/WebServices/jaxb/.
[mic09j] SUN microsystems. JDBC - Java Database Connectivity, July 2009.
http://java.sun.com/javase/technologies/database/.
[mic09k] SUN microsystems. JMS - Java Message Service, July 2009.
http://java.sun.com/products/jms/.
[mic09l] SUN microsystems. SUN Homepage, July 2009. www.sun.com.
[OAS09] OASIS. OASIS Homepage, July 2009. http://www.oasis-
open.org/home/index.php.
[Ora09] Oracle. Database, July 2009. http://www.oracle.com/database.
[oT09] oAW Team. openArchitectureWare framework, 2009.
http://www.openarchitectureware.org/.
[Pre09a] Thomas Preuss. Confman, July 2009.
http://www.ifi.uio.no/confman/ABOUT-ConfMan/.
[Pre09b] Thomas Preuss. ConfMaster, July 2009.
http://www.confmaster.net.
[Pre09c] Thomas Preuss. Coniant: ConfMaster, July 2009.
http://www.coniant.net.
[Pro09] Public Knowledge Project. Open Conference Systems, July 2009.
http://pkp.sfu.ca/ocs.
[Sch09] Henning Schulzrinne. Editorial’s Assistent: EDAS, July 2009.
http://www.edas.info.
[Sno09] R. Snodgrass. Summary of conference management software, July
2009. http://www.acm.org/sigs/sgb/summary.html.
[Sof09] RedWhale Software. Conference Reviewing System: CRS, July 2009.
http://www.conferencereview.com.
[Sys09] Open Conference/Journal System. Public Knowledge Project, July
2009. http://pkp.sfu.ca, 2009.
WEB REFERENZEN 182
[Tea09a] AndroMDA Team. AndroMDA Gode-Generator Frameword, 2009.
http://www.andromda.org/.
[Tea09b] JForum Team. JForum, July 2009. http://www.jforum.net/.
[vdS09a] Richard van de Stadt. CyberChair, July 2009.
www.borbala.com/cyberchair/.
[vdS09b] Richard van de Stadt. CyberChairPRO, July 2009.
http://www.borbala.com.
[Vor09] Andrei Voronkov. EasyChair, July 2009. http://www.easychair.org.
[Wes09] Ajamu Wesley. Web Services Flow Language (WSFL), July 2009.
http://www.ibm.com/developerworks/webservices/library/ws-
wsfl1/.
[WML09] WML. Website Meta Language, July 2009. http://thewml.org/.
[Yah09] Yahoo. Yahoo Pipes, 2009. http://pipes.yahoo.com.